Surrogate Keys Ray Lockwood

Size: px

Start display at page:

Download "Surrogate Keys Ray Lockwood"

Aldous Miller
5 years ago
Views:

1 Data Modeling and Implementation Surrogate Keys Pg 1 Surrogate Keys Ray Lockwood Points: A Surrogate Key is the primary key and links tables together. A Surrogate Key is usually a system generated integer. A Surrogate Key doesn't contain a fact about the object being modeled. A Primary Key shouldn't change when the facts about an object change. A Surrogate Key increases a database s referential integrity. Keys Link Tables Together Keys are the mechanism that link tables together. Because a table is a logical structure, its keys are logical, too. A key is a logical link between tables. Since a key is a logical device, we have some freedom in choosing its values. A example of a physical link is the memory pointer of the network database. Natural Keys In a database of country songs, we could choose AlbumName as a primary key: Primary Key Album: AlbumName Artist YearReleased Cowboy Country Billie Nelson 1989 Cryin Bob Bob Smittie 1984 Foreign Key Song: AlbumName SongTitle Length Cowboy Country Country Shuffle 3:14 Cowboy Country Country Blues 3:05 Cryin Bob Cryin Over My Pickup Truck 3:12 Cryin Bob Cryin Over My Dog 3:08 Cryin Bob Cryin Over My Beer 3:10 AlbumName is a Natural Key because this attribute occurs naturally in the table. A Natural Key is not only a linking device, it also contains a fact about an object. A Natural Key is a consequence of the table s data. AlbumName is a natural key because it contains data about the object. Song is an ID dependent entity. Album Song In choosing AlbumName as the primary key of Album, we're using a piece of data about the entity as the linking construct. This is a Natural Key.

2 Data Modeling and Implementation Surrogate Keys Pg 2 Problem with Natural Keys The problem with using an object's data as a key is two-fold: 1. What happens if we need to change the value of a natural key, perhaps to correct a misspelling? We'd have to change all the foreign keys, too. (Foreign keys produce a form of redundancy). 2. What happens if the natural key turns out to be non-unique? According to Relational rules, a key value can never change, so a misspelling can't be corrected. However, most DBMS's support key value changes through a feature called cascading updates: all foreign key values in child rows are automatically changed if the primary key value in the parent is changed, so links are undisturbed. I ran into the uniqueness problem in a table of manufacturer s part numbers. We used MfrPartNum as the primary key in this table. After it had been used for a couple of years, the database wouldn't let a clerk enter a particular new part. This part happened to have the same part number as a different manufacturer s unrelated part already in the database. The key we chose wasn't under our control. We relied on outside actors to insure uniqueness of our keys, and that caused us problems. Referential Integrity and Foreign Key Constraint Referential Integrity means assuring that the connections between tables remain valid. One important type of rule for referential integrity is called the Foreign Key Constraint. Foreign Key Constraint means that values in the foreign key column of a child table will always contain only values from the primary or candidate key attributes in the parent table. There must be no dangling pointers; this means there must be no row with a foreign key value that points to a non-existent primary key value in another table. In simpler terms, there will be no orphan rows in child tables. In our Country Music Database, if the key of a row of the Album table is changed, it must also be changed for corresponding rows in the Song table, too. This weakens referential integrity. Since we have to accept natural keys as they are, we don t have control over them. Cascading Deletes: when a parent row is deleted, all its children in other tables are deleted, too. Cascading Updates: when the primary key value in a parent row is changed, foreign keys in the children are changed to match. Relying on keys we have no control over to be unique and unchanging is risky. Referential means linking tables together using keys. Referential Integrity means assuring that linkages between tables are always correct. A Foreign Key Constraint prevents orphan rows in child tables.

3 Data Modeling and Implementation Surrogate Keys Pg 3 Surrogate Keys To avoid referential integrity problems, it s better for a key to be strictly a linking mechanism; its better if a key doesn't contain data about the object modeled by its table. In other words, keys shouldn't contain a fact about a real-world object. A key that doesn't contain real-world data is called a Surrogate Key (also called an Artificial Key as opposed to a Natural Key). is an alias for an object. If we can t put real-world data into a key, what is the alternative? We use a systemgenerated integer (usually an auto-increment integer) to set a value for our surrogate key. A Surrogate Key Becomes a Fact Outside Its Native Database Surrogate keys abound: Your social security num, driver s license num, phone num, automobile serial num, and Winn-Dixie reward num. These are system-generated identifiers that happen to be visible to users of the system. They're surrogate keys only within the database in which they were generated. Outside that database, they're a fact about an entity. Within the Social Security Administration database, your SSN is a surrogate key under the control of the database owner. In the rest of the world your SSN is a fact about you. Most surrogate keys are generated for the DBMS to use internally and aren't visible outside the database. In our Country Music database, instead of using Song Title, we can add an auto-increment integer column as a surrogate primary key. Tables linked to Album will use this surrogate key for linking, but this value has no meaning outside the database. Surrogate Keys Improve Referential Integrity A key is a linking construct; a surrogate key is a pure linking construct. The advantage of a surrogate key is that it's under the control of the database designer and not the outside world. Social Security number is a surrogate key assigned by the Social Security Administration for their own use. Keys can be pure linking devices, and not contain a fact about an object. A surrogate is a substitute for something else. Surrogate keys are system generated. is a surrogate only within the database which created it. If a surrogate key is visible outside the database, it becomes a fact about an object. Surrogate keys are almost always unseen by the outside world. is under the control of the database owner. A person might change his name, address, occupation, and correct the date of his birth; but his SSN will never change unless the people who own the SSN database decide to change it. As a result, this surrogate key a more reliable way for the Social Security folks to link their tables together than if they chose a natural key. Surrogate Keys Improve Efficiency The data type for surrogate keys is chosen for efficiency, and the integer type is the most efficient to search. This fact, plus the fact they can be auto-incremented, means that surrogate keys are generally integers. is almost always an auto-incremented integer.

4 Data Modeling and Implementation Surrogate Keys Pg 4 Example Here are our Country Music database tables again: Album: AlbumName Artist YearReleased Cowboy Country Billie Nelson 1989 Cryin Bob Bob Smittie 1984 Song: AlbumName SongTitle Length Cowboy Country Country Shuffle 3:14 Cowboy Country Country Blues 3:05 Cryin Bob Cryin Over My Pickup Truck 3:12 Cryin Bob Cryin Over My Dog 3:08 Cryin Bob Cryin Over My Beer 3:10 To change the name of the album Cowboy Country to Kowboy Kountry, then in addition to the Name attribute, we'd have to change all the corresponding foreign key values in the Song table. Here are the same two tables using the surrogate key AlbumID as the primary key of Album. The value of AlbumID is a system generated auto-increment integer: Surrogate Primary Key Just another attribute Album: AlbumID Name Artist YearReleased 001 Cowboy Country Billie Nelson Cryin Bob Bob Smittie 1984 Song: AlbumID SongTitle Length 001 Country Shuffle 3: Country Blues 3: Cryin Over My Pickup Truck 3: Cryin Over My Dog 3: Cryin Over My Beer 3:10 Now we can change the album name in only one place, the Album table, without disturbing the linkage between tables. The surrogate key is a pure linking construct. It carries no fact about an entity it has the single purpose of linking rows of one table to those of another. This is more robust and efficient than using a natural primary key. Now, the Name attribute is just another fact about an object, and not a linking device. is a pure linking construct that s all it does.

5 Data Modeling and Implementation Surrogate Keys Pg 5 Disadvantage In our original Country Music Database, we could look at the Song table alone and read album names that went with song titles. With the surrogate primary key, we can't do this. We have to perform a join to see the album names that go with song titles. Weigh the advantage against this disadvantage before deciding to use a surrogate key. A disadvantage of surrogate keys is that more joins may be necessary to get information from child tables. A Note about Normalization Data that's duplicated in foreign keys is a type of data redundancy that means repeated data that's hard to maintain if the data changes. Because keys are never meant to change, this is not a pathological redundancy addressed by normalization. It's a reflection that the rows in the child table belong to the rows in the parent table. Data repeated in foreign keys reflects the relationship between tables. Disadvantages of Surrogate Keys Disadvantage 1 Surrogate key values have no meaning to the user. They don t have much meaning to the database designer either. They make tables hard to read during casual inspection. Surrogate keys make your data more cryptic, and a step away from the Relational goal of making the database closer to information than to data. As a result, you have to join tables to look up the facts the surrogate keys represent. This is a performance hit if an application has to join tables where it wouldn t have if we used natural keys. Disadvantage 2 When data is shared among different databases, the uniqueness of surrogate keys is not assured. If you have two independent databases and wish them read each other s data, it s likely that surrogate key values of one database will be duplicated in the other. This can cause meaningless connections between the same kinds of data in the different databases. This was the problem in the parts inventory database earlier. Two unrelated parts from different manufacturers happened to have the same part number. These part numbers, though natural keys in our database, are really surrogate keys in the manufacturers databases. When combined, a collision occurred. If you design databases that might one day be combined, you can plan ahead and assign different numeric ranges for the surrogate keys. Surrogate keys make data look more cryptic on casual inspection. Tables linked by surrogate keys may require more joins. It is potentially more difficult for different databases to share data. Databases intended to share data should draw surrogate keys from different pools. Some database designers use GUID or UUID values generated by the operating system as surrogate keys. Globally Unique ID Universally Unique ID

6 Data Modeling and Implementation Surrogate Keys Pg 6 Surrogate Keys Are Widely Used The advantages of using surrogate keys usually outweigh their disadvantages. Most database designers use surrogate primary keys for many and sometimes all the table Using surrogate keys is a good practice. If a good natural key exists, use it. If not, use a surrogate key. Summary Surrogate keys: Don't introduce normalization problems in a table. Improve referential integrity because they're pure linking constructs. Improve join performance. But: Make tables more cryptic when casually viewing them. May require more joins for certain queries. Can cause problems when connecting different databases together.

ER Modeling ER Diagram ID-Dependent and Weak Entities Pg 1

ER Modeling ER Diagram ID-Dependent and Weak Entities Pg 1 ER Diagram ID-Dependent and Weak Entities Ray Lockwood Points: An ID-dependent entity is an entity whose identifier (key) includes the identifier