Database Design
Database Model: Entities and Attributes
Implemented (MySQL): Tables and Fields or Columns
Unnormalized Example
Attribute Record #1 Record #2
Car ID 1382 1399
Make & Model Porsche GT3 Bentley Continental GT3
Year of Manufacture 2005 2014
Miles 16,556 16,556
Color White White
Prior Owner #1 Montgomery Burns
Prior Owner #2 Waylon Smithers
Price $79,990 $190,625
Buyer’s Name Marjorie Bouvier Marge Simpson
Buyer’s Phone 555-3283 555-8707
Primary Keys
Uniquely Identifies Record
Be careful.
Social Security Number isn’t a good primary key:
• Could change after identity theft
• Might be reused over time
• Doesn’t exist for all users
• Has privacy issues
Normalization
Model and normalize your entities to avoid redundancies, anomalies, and other errors
"Each of the normal forms is defined in a very cryptic way; even when put into layman’s terms, they can still be confounding." - Larry Ullman
First Normal Form
• Each attribute contains only 1 value
• Entities cannot have repeating groups of data
First Normal Form
Bad – Is Not 1NF
Car Entity
Car ID
Make & Model
Year of Manufacture
Miles
Color
Prior Owner #1
Prior Owner #2
Price
Buyer’s Name
Buyer’s Phone
First Normal Form
Better – Is 1NF
Car Entity
Car ID
Make
Model
Year of Manufacture
Miles
Color
Price
Buyer’s First Name
Buyer’s Last Name
Buyer’s Phone
Prior Owner Entity
Owner ID
Car ID
First Name
Last Name
Functional Dependency
The value of an attribute should be determined by the primary key, and only by the primary key
For example, specific information about a car (make, model, prior owners) can be determined by looking up the VIN number. So those attributes are functionally dependent on the VIN number key.
Functional Dependency
If an entity’s attributes are not functionally dependent on the primary key, these problems occur:
• Repeating, redundant entries in fields
• Update anomalies
Second Normal Form
• If the primary key is a composite key consisting of multiple attributes, other attributes must not be functionally dependent on just a subset of the primary key
http://www.bkent.net/Doc/simple5.htm
Composite Key
The primary key, identifying a specific card, is a
composite of two attributes – the Rank and Suit.
Attribute Record #1 Record #2 Record #3 Record #4
Card Rank Jack Seven Queen Queen
Card Suit Spades Hearts Hearts Diamonds
Point Value 10 7 10 10
Second Normal Form
Better – Is 2NF
Playing Card Entity
Card Rank
Card Suit
Card Rank Entity
Card Rank
Point Value
Note:
The primary key of the playing card entity is
still a composite of the Card Rank ID and
Card Suit
Second Normal Form
Also OK – Is 2NF
Playing Card Entity
Card ID
Rank
Suit
Point Value
MySQL developers usually add surrogate primary keys (“IDs”) to every entity instead of using natural primary keys (real world attributes like VIN numbers)
While that doesn’t solve functional dependency problems,
entities with a single ID primary key always meet the
conditions for second normal form
Third Normal Form
• Attributes must be functionally dependent on the primary key, and not on any other attributes
Find repeating entries & update anomalies:
Attribute Record #1 Record #2
Car ID 1382 1399
Make Porsche Bentley
Model GT3 GT3
Year of Manufacture 2005 2014
Miles 16,556 16,556
Color White White
Price $79,990 $190,625
Buyer’s First Name Marjorie Marge
Buyer’s Last Name Bouvier Simpson
Buyer’s Phone 555-3283 555-8707
Relationships
Many to many relationships are not allowed in MySQL applications.
Create an intermediate entity with one-to-many relationships between the primary keys of the two entities.
Take a Deep Breath…
Don’t worry so much about whether a functional dependency problem is a 2nd normal form issue or a 3rd normal form issue.
Just make sure you fix both types of problems.
Functional Dependency Pledge
“Every non-key attribute must provide a fact about the key, the whole key, and nothing but the key.... so help me Codd*”
*E.F. Codd was the inventor of Relational Databases and normalization
Delete Anomalies
In our car database model, if you delete records from the make, model, or person table, foreign keys would be orphaned in other tables.
Foreign Key Constraints
Foreign key constraints can be created in the database implementation, with two approaches:
• Prevent the delete of a record where its primary key exists as a foreign key in another table.
• Cascade the delete of a record, removing linked records from the other tables
Soft Deletes
Instead of deleting records from a database, you could:
• Add an active attribute. Updating your queries to only select active records will hide the records you no longer want to show.
•Move the records to an archival table.
Inner vs Outer Join
Inner joins are done to select records that have entries linked to records in all joined tables.
Outer joins are done to select all records, whether or not they are linked to the joined tables.
Top Related