The document discusses database design principles including normalization. It explains the concepts of entities, attributes, primary keys, and functional dependencies. The three normal forms - 1st, 2nd, and 3rd normal form are introduced to avoid data redundancies and anomalies. Relationships between entities should be modeled to have each entity dependent only on its primary key. Indexes, foreign key constraints, and other techniques can help address issues like performance and referential integrity.

1. Database Design
David Kelleher
www.davidk.net

2. Database Design
Database Model: Entities and Attributes
Implemented (MySQL): Tables and Fields or Columns

3. 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

4. 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

5. 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

6. First Normal Form
• Each attribute contains only 1 value
• Entities cannot have repeating groups of data

7. 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

8. 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

9. 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.

10. 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

11. 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

12. 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

13. Second Normal Form
Bad – Is Not 2NF
Playing Card Entity
Card Rank
Card Suit
Point Value

14. 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

15. 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

16. Third Normal Form
• Attributes must be functionally dependent on the
primary key, and not on any other attributes

17. 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

18. Model with many-to-many relationships

19. 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.

20. Third Normal Form

21. 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.

22. 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

23. Indexes Save the Day!
• Where clause
• Order By clause
• Joins

24. 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.

25. Delete Anomalies

26. 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

27. 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.

28. 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.

29. Database Design
David Kelleher
www.davidk.net