Database Design

David Kelleher

www.davidk.net

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

Bad – Is Not 2NF

Playing Card Entity

Card Rank

Card Suit

Point Value

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

Model with many-to-many relationships

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.

Third Normal Form

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

Indexes Save the Day!

•Where clause

• Order By clause

• Joins

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.

Delete Anomalies

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.

Database Design

David Kelleher

www.davidk.net