AOIT Database DesignLesson 7 Primary Keys and Normalization
Teacher Resource 7.1
Answer Key: Primary Keys WorksheetTable 1: Employee Entity for Midsize CompanyThis is the Employee entity for a company with 700 employees.
Employee
Employee ID Last Name Initials Birth Date
0620 Garcia R. J. 3/20/87
0295 Mancini L. C. 4/21/64
0464 Rodriguez B. J. 12/13/80
What is the unique attribute that can be used as a primary key?
Employee ID.
Would Last Name work as a primary key?
No, there could be many people with the same last name.
If there is an employee ID, why do you still need employee names in the database?
There may be applications that need the name of the employee. For example, you would want to put the employee’s name on a letter addressed to him or her.
Why do you think attributes like Employee ID are sometimes called artificial keys?
The attribute doesn’t have a meaning in the real world. It is created for the sole purpose of having a unique identifier.
Table 2: Product Entity for Software CompanyThis is the Product entity for a software company that has two lines of products.
Product
Name Version Price Description
DrawWrite 6.0 Maintenance support for this version still available
DrawWrite 7.0 $295 Most recent full release of product
DrawWrite 7.0.1 Free upgrade to 7.0 that corrects bugs
SuperShaper 2.0 $317 First version of this product
SuperShaper 2.1 No longer for sale
SuperShaper 2.2 $40 Upgrade to 2.0 with new shapes; requires 2.0
AOIT Database DesignLesson 7 Primary Keys and Normalization
What is the composite primary key?
Name and Version.
Why do you need a composite primary key?
Because the name alone or the version alone do not uniquely identify all instances of the product.
How does looking at the instances of the entity help you figure out the primary key?
It’s easy to spot which attributes are not totally unique.
Why are some of the Price fields in the table blank?
Some of the products are not for sale. Some attributes do not have to have data in them.
Table 3: Dolphin Database Product Entity
Product
Product Name
Item Description
Supplier Supplier Number
Purchase Price
Units in Stock
Units on Order
Cap All cotton; one-size-fits-all
Novelty Items, Inc.
732A $24.50 3.00 0
Screensaver Dolphin photos Dolphin Delights
523B $19.50 1.00 0
Is the product name sufficient for a primary key? Why or why not?
No. There could be several types of caps and screensavers.
The supplier number is the number that the supplier uses to identify its product. Would Supplier Number be a good primary key? Why or why not?
It might not be good enough because different suppliers could use the same supplier number.
What two attributes could you use to make a composite primary key that is sure to be unique?
Supplier and Supplier Number
Would an artificial primary key be simpler and more versatile? Why or why not?
It might be easier to have an artificial key with the first letter of the supplier name plus the supplier number. This would be easier because it would require only one attribute, but it might not be immediately obvious who the supplier is.
Table 4: Dolphin Database Customer Entity
Customer
Last Name
First Name Street Address City State
ZIP Code Phone
Wilson Eileen 467 Ogden St. Olney TX 76374 (940) 555-3753
AOIT Database DesignLesson 7 Primary Keys and Normalization
Is either Last Name or First Name unique?
No.
Would Last Name and First Name together be unique? Why or why not?
No. Customers in different locations could have the same name.
Can Phone Number uniquely define a customer? Why or why not?
No. Family members could have the same phone number.
What is the best solution? Explain why this is a good solution.
Create a Customer ID as the primary key. This is the only way to have a unique identifier for each customer.
However, this creates a type of entity that is notoriously difficult to get right. Using an artificial key is a way to handle the need for a database key, but it’s no guarantee that the data will be right. Many organizations have duplicate records for the same customer in their databases precisely because there really is no foolproof way to know for sure that you have a new unique instance of a customer to add. Matching a new customer’s data with existing customer records is an inexact science. Slight misspellings of names, or transpositions of street address numbers, birth dates, and so on, can cause the system or input person to assign a new customer ID when that customer already exists under another ID.
AOIT Database DesignLesson 7 Primary Keys and Normalization
Teacher Resource 7.2
Presentation 1 Notes: Normalization—First Normal Form
Before you show this presentation, use the text accompanying each slide to develop presentation notes. Writing the notes yourself enables you to approach the subject matter in a way that is comfortable to you and engaging for your students. Make this presentation as interactive as possible by stopping frequently to ask questions and encourage class discussion.
This presentation explains why normalization is necessary and demonstrates how to make an entity conform to first normal form.
AOIT Database DesignLesson 7 Primary Keys and Normalization
A lot of time entities look fine until you start adding data to the database. When you add data, you begin to see the different problems that might arise.
AOIT Database DesignLesson 7 Primary Keys and Normalization
Normalization requires systematically looking at each entity to determine whether it conforms to the criteria for normalization.
In this presentation, you will learn how to normalize entities to first normal form. Then you will have a chance to look at your culminating project database and normalize it to first normal form before you continue with second and third normal forms.
AOIT Database DesignLesson 7 Primary Keys and Normalization
Instrument and Band Camp Dates are examples of repeating elements of data in a single row of data. While these types of elements may be fine for humans to view and understand in a spreadsheet, they can make a computer database inflexible, error-prone, and less useful than expected.
As you probably noted, the column for Instrument can contain more than one instrument name. The way multiple instrument names are recorded and separated is not consistent. The column for Band Camp Dates may contain more than one date. How would we separate the two or more dates that might appear here?
If we wanted to write a query that produces a list of band member names by instrument played, it would be difficult for our query to recognize that Clara plays two instruments, and therefore her name should appear under Clarinet and again under Flute. The query might think that “Flute; Clarinet” is the name of one instrument.
AOIT Database DesignLesson 7 Primary Keys and Normalization
Additional entities would also be created for Band Camp Dates. Student ID would appear in each of them to link the information back to the band member.
AOIT Database DesignLesson 7 Primary Keys and Normalization
These two entities are all first form normal: there are no repeating elements or groups of data elements.
When the primary key from one entity is included in another entity, it sets up a relationship (or connection) between the two. This is the underlying concept of a relational database!
AOIT Database DesignLesson 7 Primary Keys and Normalization
Teacher Resource 7.3
Presentation 2 Notes: Normalization—Second Normal Form
Before you show this presentation, use the text accompanying each slide to develop presentation notes. Writing the notes yourself enables you to approach the subject matter in a way that is comfortable to you and engaging for your students. Make this presentation as interactive as possible by stopping frequently to ask questions and encourage class discussion.
This presentation demonstrates how to make an entity second normal form.
AOIT Database DesignLesson 7 Primary Keys and Normalization
The Customer ID is an artificial primary key created as a unique identifier for each customer.
All of the attributes in this entity give information about the customer, and so they are “dependent” on the Customer ID primary key. The name, address, and phone number all tell you something about the customer.
AOIT Database DesignLesson 7 Primary Keys and Normalization
The composite primary key is OrderID and ProductID.
The Product Supplier attribute is dependent only on the ProductID part of the primary key. The name of the supplier does not depend on the order, but on the product. It is not dependent on OrderID.
If we move the Product Supplier attribute to the Product entity, we can remove this partial dependency.
AOIT Database DesignLesson 7 Primary Keys and Normalization
The Student Phone attribute is uniquely identified by the Student ID primary key. It is not dependent on the Club ID primary key. So, we say the Student Phone attribute is partially dependent.
The solution is to move the Student Phone attribute to the Students entity.
AOIT Database DesignLesson 7 Primary Keys and Normalization
The fee is calculated depending on what club it is and who the student is. Not all students have the same fee for the same club.
The discount is calculated depending on what the club is and who the student is. Not all students have the same discount for the same club.
The total fee is dependent on both what the club is and who the student is. We will talk more about what to do with this total when we get to third normal form.
AOIT Database DesignLesson 7 Primary Keys and Normalization
You may be thinking that your database won’t have any second normal form anomalies because you will create your entities correctly the first time around. You may be right! But you may also be wrong.
For experienced database developers, normalization becomes second nature, and a lot of times they do create entities that are normalized to start out with. However, it’s very important to know the rules and know how normalization works so that you can make sure you don’t run into anomalies in your database once it is up and running.
AOIT Database DesignLesson 7 Primary Keys and Normalization
Teacher Resource 7.4
Presentation 3 Notes: Normalization—Third Normal Form
Before you show this presentation, use the text accompanying each slide to develop presentation notes. Writing the notes yourself enables you to approach the subject matter in a way that is comfortable to you and engaging for your students. Make this presentation as interactive as possible by stopping frequently to ask questions and encourage class discussion.
This presentation explains how to normalize entities to third normal form.
AOIT Database DesignLesson 7 Primary Keys and Normalization
This example has a compound primary key, Tournament and Year, because both the name of the tournament and the year are needed to identify the tournament.
The Winner Date of Birth attribute is dependent only on the winner, which is not the primary key. This is a transitive dependency.
When the table is updated, if one of the winners (like Sara Chu) wins another tournament, there is a risk that she will be entered with a different date of birth. That means the database will have conflicting data.
AOIT Database DesignLesson 7 Primary Keys and Normalization
The solution to the transitive dependencies problem is to create a new entity called Player Dates of Birth. This entity has the winners as the primary key, and the other attribute is Winner Date of Birth.
AOIT Database DesignLesson 7 Primary Keys and Normalization
Since Days to Ship is calculated as the number of days from the order date to the ship date, it is dependent on these two attributes, not on the primary key. This is a transitive dependency.
AOIT Database DesignLesson 7 Primary Keys and Normalization
Sometimes an entity might have a Total Cost attribute that is calculated from the article price and the sales tax. This is a transitive dependency and should be eliminated.
What about an entity with City, State, and ZIP attributes? Do you think the ZIP is a transitive dependency?
AOIT Database DesignLesson 7 Primary Keys and Normalization
This entity has a Total Fee attribute that is calculated by multiplying the fee by the discount. The Total Fee attribute has a transitive dependency on the Fee and Discount attributes. You must eliminate the Total Fee attribute to make this entity third normal form.
AOIT Database DesignLesson 7 Primary Keys and Normalization
When you normalize your culminating project database to third normal form, look closely at each attribute, and ask yourself how it relates to the primary key. If it has to go through some other attribute to get to the primary key, this is a transitive dependency. You may need to create a new entity. Or, if it is a calculated attribute, you can simply eliminate it.
Using the following criteria, assess whether the students met each one.
Met Partially Met
Didn’t Meet
In the Access tables, the primary key for each entity is labeled correctly, including composite primary keys. □ □ □In the Access tables, the instances listed in each table demonstrate that all entities have been put to the test, with at least 10 instances for entities with composite primary keys and at least 8 instances for all other entities. The instances should be different enough from each other to reveal repeating data, partial dependencies, and transitive dependencies.
□ □ □
All entities are third normal form; they have no repeating elements, no partial dependencies, and no transitive dependencies.
□ □ □
The worksheet tables (Student Resources 7.6, 7.8, and 7.10) show a correct process for normalizing each entity that needed revision. If necessary, new entities were created, or attributes were moved to other existing entities.
□ □ □
The Access tables and worksheet tables are well organized, easy to follow, and presentable. □ □ □
AOIT Database DesignLesson 7 Primary Keys and Normalization
Teacher Resource 7.6
Key Vocabulary: Primary Keys and Normalization
Term Definition
anomaly A problem introduced into a database when data is added, deleted, or updated.
artificial identifier A unique identifier that does not have real-world meaning. Examples include a Social Security number, an invoice number, or an employee ID. Sometimes called a surrogate identifier.
composite primary key A key made up of two or more attributes.
entity-relationship model A logical database model that visually represents entities, attributes, and relationships.
first normal form An entity is said to be first normal form when it contains no repeating attributes or groups of attributes.
foreign key A field in a relational database table that matches the primary key column of another table. The foreign key can be used to link the tables.
junction table A table in a relational database that links two or more other tables’ data together and resolves many-to-many relationships. (For example, if a song is on many albums and each album contains many songs, there would be a many-to-many relationship between the album and the song tables. A third table in between them, the junction table, would simply list the album ID and song ID in pairs. It could be named something like “Album Song List.”)
normal forms A set of rules that specify how entities are structured.
normalization A technique for reducing the possibility that a database is subject to anomalies when data is modified.
one-to-many relationship A type of relationship in a database where one record serves as a parent to several other records (e.g., a supervisor can oversee many employees).
one-to-one relationship A type of relationship in a database where one record serves as a parent or child to only one other record (e.g., a song length can be associated with only one measurement of time).
AOIT Database DesignLesson 7 Primary Keys and Normalization
Term Definition
primary key An attribute or combination of attributes in a database that uniquely identifies each instance in the database.
referential integrity A condition that ensures that any pointer values (keys), or references, to parent tables are valid and consistent (i.e., if one table with a foreign key is linked to another, no additional records can be added to the table with the foreign key unless there is a matching record in the linked table). For example, one cannot enter a product name without also supplying a product ID. Further, any changes made in one table will be reflected in all tables up- or downstream from it so that all data will match across the database.
second normal form An entity is said to be second normal form when attributes that are only partially dependent on the primary key have been eliminated. This means that for entities with a composite primary key, every attribute is dependent on all parts of the primary key.
third normal form An entity is said to be third normal form when attributes that have transitive dependencies on nonkey attributes have been eliminated. That is, attributes that are dependent on nonkey attributes, rather than being totally dependent on the primary key, are eliminated.
AOIT Database DesignLesson 7 Primary Keys and Normalization
Teacher Resource 7.7
Bibliography: Primary Keys and NormalizationThe following sources were used in the preparation of this lesson and may be useful for your reference or as classroom resources. We check and update the URLs annually to ensure that they continue to be useful.
