I am doing a database that keeps track of mainframe security access. If someone goes to a certain screen on our mainframe, their ID must pass verification on some behind-the-scenes access "rules". I am documenting what each rule does, what mainframe system the rules are for, and what rules are tied to each other (for instance, if I want to update something on screen "X", I have to have the "X-update" rule as well as the rule or rules that allow(s) me to get to screen X in the first place).
I'm thinking that I would have one table that has:
Rule Name, Description, Owner, System
And one table with:
Rule Name, Rules tied to it
The 1st table would have the key field "Rule Name" as this would be a unique field. However the 2nd table does not have a unique field, because both fields could have duplicate values. This seems to me to be a problem, because I was taught that your tables should have at least one unique field. I could autonumber, but that doesn't really fix the structure. Am I missing something? Is this OK to do? Let me know if more info is needed. Thanks.
I'm thinking that I would have one table that has:
Rule Name, Description, Owner, System
And one table with:
Rule Name, Rules tied to it
The 1st table would have the key field "Rule Name" as this would be a unique field. However the 2nd table does not have a unique field, because both fields could have duplicate values. This seems to me to be a problem, because I was taught that your tables should have at least one unique field. I could autonumber, but that doesn't really fix the structure. Am I missing something? Is this OK to do? Let me know if more info is needed. Thanks.