Download presentation
Presentation is loading. Please wait.
Published byEvelyn Grant Modified over 9 years ago
1
Natural vs. Generated Keys
2
Definitions Natural key—a key that occurs in the data, that uniquely identifies rows. AKA candidate key. Generated key—a key that is generated at the time data is inserted into the database, that did not occur naturally 2
3
Postulate: In a normalized data model, every row has a natural key Proof: 3NF requires that the value of every attribute be ffd by the primary key. By construction, primary keys uniquely identify instances and are unique. Therefore, each row has a different value for the primary key and is hence unique. Result: There is no reason to add a primary key to normalized data in order to make rows unique. They already are. 3 Question: does 3NF require that there be a single- attribute primary key?
4
Generated Keys In some organizations, programmers have the idea that a generated key should be included in every relation, a misunderstanding of the relational approach. Often they will say “it’s to make rows unique” or “to provide a unique identifier.” This is terribly wrong! That’s a fine idea for an Excel spreadsheet but it shows a misunderstanding of what a relation is and what a tuple is. Tuples are naturally unique because each one corresponds to a distinct instance of an entity type in the real world. You don’t have to add anything to make them unique. If your database design is correct, you have unique rows even if you haven’t added a key to each row. 4
5
Making the Point Again, Again Each row corresponds to an occurrence of a entity instance Each entity instance is unique; that’s why it is tracked as an instance Therefore, every row is different from every other row without adding anything to it 5 Question: what if entity instances are not unique? How do we track them in a database?
6
Claim That’s Made for Generated Keys Some think that generated keys allow more flexibility For example, in our EMP table, can we allow a person’s name to change? If we use a generated key, then the name can change and all other associated data will still be associated with the correct person What do you think of this statement? Can you use telephone number as the primary key? Why or why not? Can primary keys ever change in value? And what if the primary key is a foreign key in another table? 6
7
SQL and Primary Keys SQL allows primary keys to change; they are just a value that changes What about foreign keys? Can they change? In the CREATE TABLE statement, you state ON UPDATE or ON DELETE CASCADE, RESTRICT, NO ACTION, SET NULL or SET DEFAULT. For ON DELETE, DELETE can also be an action 7
8
Benefits of Natural Keys: Assures proper attention to the data model, because unique values must be identified Tables have fewer columns Avoid storage of meaningless data The key value itself may have value to an application, hence will avoid retrieval of the row itself 8
9
When to Use Generated Keys Sometimes you have a compound key that is very long Lots of queries will be very complicated and tables with foreign keys will copy most of another table As a guideline, the only time to use a generated key is when the natural key has at least three columns A special case of this rule is the case where the whole row would have to be a composite key without a generated key Example: internal person 9
10
Another Case for Generated Keys Suppose we don’t have any kind of single or composite identifier that is always present Database systems generally don’t allow for part of a designated composite key to be null Even though it’s legitimate, because of database system limitations, you may have to use generated keys if you don’t have a common identifier without any null parts, ever 10
11
The Bottom Line Don’t use generated keys. Ever. Unless you absolutely have to. 11
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.