Data Models and Relational Databases

Chapter 2

Learning ObjectivesIdentify primary and foreign keys for each entity and

relevant relationships in the data model,

Create tables that are properly linked with foreign keys or through relationship table(s),

Examine a table design for any anomalies, and

Normalize a table to the third normal form.

The Database Development Process

Begins with enterprise modeling Setting the range and general contents of organizational databases

Follows with conceptual data modeling Analyzing overall entities’ requirements based on transaction cycles

Involves with logical database design Transforming the conceptual data model into a logical data model

using relational data models

Enterprise ModelingFigure 2-1

Overall REA Model for an Accounting Information System*

Revenue Cycle

Sale

Duality

Cash Receipt

Financing Cycle

Cash Receipt

Duality

Cash Disbursement

Human Resource/Payroll Cycle

Labor Acquisition

Duality

Cash Disbursement

Expenditure Cycle

Purchase

Duality

Cash Disbursement

Conversion (Production) Cycle

Machine Operation

Duality

Finish Goods Inventory

Labor Operation

Duality

Material Issurance

Duality

Financial Reporting System

Cash

Cash

Cash

Data

Data

Data

Data

Data

Labor

MaterialsFinished Goods

Conceptual Data Modeling

(1,N) (1,1)

(0,N)

(1,1)

(1,1)

(1,N)(0,N)

(1,N)(1,N)

(1,1)

(1,1)

(0,N)

(1,N)(1,1)

(1,N)(0,1)

(0,N)

(1,1)

(1,1)

(1,N)

(1,1)

(1,1)(1,N)

(1,1)

(1,1)

(0,N)

(1,N) (1,1)

SaleInventory

Cash(Bank Account)

Cash Receipt

Customer

Outflow

Inflow

Duality

Jesse

Inflow

Outflow

Purchase

Cash Disbursement

Artist/Seller Duality

Outside Participation

Outside Participation

Inside Participation

Inside Participation

Outside Participation

Outside Participation

Inside Participation

Inside Participation

Revenue CycleExpenditure Cycle

Complete REA Diagram for Cherokee’s Revenue Cycle

(1,N)(0,1)

(0,N)

(1,1)

(1,1)

(1,N)

(1,1)

(1,1)(1,N)

(1,1)

(1,1)

(0,N)

(1,N) (1,1)

SaleInventory

Cash(Bank Account)

Cash Receipt

Jesse

Customer

Outflow

Inflow

Insideparticipation

Outsideparticipation

Duality

Outsideparticipation

Insideparticipation

Resource Events Agents

Structure of a Relational DatabaseThe primary construct is called a relation or a table.

Constructed with rows and columns much like a spreadsheet. Each table represents either an entity or a relationship between

entities. Tables must be properly linked to make a relational database.

The columns in a table are called fields. Fields represent the attributes or characteristics of the entity or

relationship.

The rows in a table are called records or tuples. Records represent all the specific data values that are associated with

one instance.

Primary and Foreign KeysPrimary key

The attributes (column) or combination of attributes (multiple columns) that uniquely identifies a specific row in a table.

Foreign keyAn attribute appearing in one table that is a primary key in

another table. Foreign key is used to link tables

Basic Requirements of TablesThe Entity Integrity Rule

The Referential Integrity Rule

Each attribute must be uniquely named.

Values of a specific attribute must be of the same type.

Each attribute (column) of a record (row) must be single-valued.

Steps of Implementing an REA Diagram in a Relational DatabaseStep 1: Create a table for each entity Step 2: Create a table for each many-to-many relationshipStep 3: Examine tables with a one-to-one relationshipStep 4: Identify the attributes and assign the primary key for

each table (note that a relationship table uses two columns as the primary key – concatenated key)

Step 5: Assign non-key attributes to tablesStep 6: Implement relationships using foreign keys

Implementing an REA Diagram in a Relational DatabaseImplement relationships using foreign keys

One-to-One (1:1): Include the primary key of the first entity as the foreign key in the second entity (Note: it does not matter which primary key becomes the foreign key).

One-to-Many (1:N or N:1): Place the primary key of the entity with the maximum cardinality of N as a foreign key in the entity that has a maximum cardinality of 1

Revised REA Data Model

(1,N) (1,1)(1,1)

(1,N) (0,N)

(1,N)

(1,N)

(1,1)(1,N)(1,1)

(1,N)

(0,1)

(1,1) (1,N)

(1,N)

(1,1)

Sale

Inventory

Cash(Bank Account)

Customer

R5

R6

R3

R4

Purchase

Cash Disbursement

Artist/Seller Purchase-Cash Disbursement

Cherokee's Revised REA Data Model

R7

R1

R2

Database Anomalies and NormalizationIf a table is not well-designed, problems (anomalies)

arise.

Three types of anomalies: Update anomaly causes problems when every occurrence of a data

item is not updated. Insert anomaly causes difficulties (sometimes impossibility) to insert

new data into a table without violating the basic integrity rules. Delete anomaly involves unintended loss of data that occurs when

deleting a record in a table.

Customer ID Last Name

First Name Phone No.

Product ID Quantity Unit Selling Price

10001 Blair Diane (408) 255-1129 P-3301 1 $25.99

10001 Blair Diane (408) 255-1129 P-5490 3 $79.99

10001 Blair Diane (408) 255-1129 P-7112 11 $5.99

10201 Sanderson Ted (510) 996-7110 P-5490 2 $79.99

10201 Sanderson Ted (510) 996-7110 P-5498 5 $35.00

10211 Ryan Bird (562) 985-1024 P-3301 7 $25.99

10211 Ryan Bird (562) 985-1024 P-5498 2 $35.00

10211 Ryan Bird (562) 985-1024 P-7119 23 $15.99

Suppose Ted Sanderson changes his phone number. You need to make the change two times. If you fail to change it in both places or change it incorrectly in one place, then the records for Ted will be inconsistent.

This problem is referred to as an update anomaly.

What if there is a new product to add but no customers have purchased it yet? Can we add the new product? Why or why not?

This problem is referred to as an insert anomaly.

What is the primary key for this table?

Customer ID Last NameFirst

Name Phone No.Product

ID QuantityUnit Selling

Price

10001 Blair Diane (408) 255-1129 P-3301 1 $25.99

10001 Blair Diane (408) 255-1129 P-5490 3 $79.99

10001 Blair Diane (408) 255-1129 P-7112 11 $5.99

10201 Sanderson Ted (510) 996-7110 P-5490 2 $79.99

10201 Sanderson Ted (510) 996-7110 P-5498 5 $35.00

10211 Ryan Bird (562) 985-1024 P-3301 7 $25.99

10211 Ryan Bird (562) 985-1024 P-5498 2 $35.00

10211 Ryan Bird (562) 985-1024 P-7119 23 $15.99

Assume that Bird has filed bankruptcy and you decide to delete her record from the table. If Bird is the only customer that purchased item P-7119, deleting Bird’s record will also delete any information pertaining to P-7119. If there are any other requests for this product in the future, the product info will not be available.

This problem is referred to as a delete anomaly.

Customer ID Last NameFirst

Name Phone No.Product

ID QuantityUnit Selling

Price

10001 Blair Diane (408) 255-1129 P-3301 1 $25.99

10001 Blair Diane (408) 255-1129 P-5490 3 $79.99

10001 Blair Diane (408) 255-1129 P-7112 11 $5.99

10201 Sanderson Ted (510) 996-7110 P-5490 2 $79.99

10201 Sanderson Ted (510) 996-7110 P-5498 5 $35.00

10211 Ryan Bird (562) 985-1024 P-3301 7 $25.99

10211 Ryan Bird (562) 985-1024 P-5498 2 $35.00

10211 Ryan Bird (562) 985-1024 P-7119 23 $15.99

NormalizationOne solution to avoid anomalies is to normalize the table

by separating the table into a set of smaller tables.

Normalization is a formal process to determine which attributes should be grouped together in a table. It validates the logical design to avoid any violation of database requirements.

Each entity is stored in a table and we use foreign keys or relationship tables to link the entities together.

Steps in NormalizationStep 1: Remove any repeating groups (First Normal

Form)

Step 2: Remove any partial dependencies (Second Normal Form)

Step 3: Remove any transitive dependencies (Third Normal Form)

Example:Partial Data in a Vendor Table

Vendor# Vendor Name

Vendor Address Contact Name

Phone# Item# Description UnitPrice

2010 AXA, Inc. 22 Heaven Wood Drive

Annie White 234-3435 M-45 Blender $15.99

K-4 iPod $65.00

2011 Sys Co. 2273 Morgan Street

John Doe 655-7512 D-12 LCD projector $560.00

2012 MFS 46 Kings Square, #5

Rachelle Brown

234-7799 M-45 Blender $18.00

K-4 iPod $63.80

2013 Lazard 8 Santa Ana Ed King 734-0109 K-8 DVD player $134.00

2014 XYZ Co. 19 Columbus Lan Lee 878-1888 K-8 DVD player $129.99

Remove repeating groups (1st NF)Vendor# Vendor

NameVendor Address Contact

NamePhone# Item# Description Unit

Price

2010 AXA, Inc. 22 Heaven Wood Drive

Annie White 234-3435 M-45 Blender $15.99

K-4 iPod $65.00

2011 Sys Co. 2273 Morgan Street

John Doe 655-7512 D-12 LCD projector $560.00

2012 MFS 46 Kings Square, #5

Rachelle Brown

234-7799 M-45 Blender $18.00

K-4 iPod $63.80

2013 Lazard 8 Santa Ana Ed King 734-0109 K-8 DVD player $134.00

2014 XYZ Co. 19 Columbus Lan Lee 878-1888 K-8 DVD player $129.99

Vendor Table Inventory Table

The data exists in separate tables

Vendor# Vendor Name

Vendor Address Contact Name

Phone# Item# Description UnitPrice

2010 AXA, Inc. 22 Heaven Wood Drive

Annie White 234-3435 M-45 Blender $15.99

K-4 iPod $65.00

2011 Sys Co. 2273 Morgan Street

John Doe 655-7512 D-12 LCD projector $560.00

2012 MFS 46 Kings Square, #5

Rachelle Brown

234-7799 M-45 Blender $18.00

K-4 iPod $63.80

2013 Lazard 8 Santa Ana Ed King 734-0109 K-8 DVD player $134.00

2014 XYZ Co. 19 Columbus Lan Lee 878-1888 K-8 DVD player $129.99

Vendor Table Inventory Table

We must link the separate tables

Using foreign keys, or

Using a relationship tableif it is M:N relationshipusing a concatenated

key (two columns together as the primary key)

Vendor# Item#

2010 M-45

2010 K-4

2011 D-12

2012 M-45

2012 K-4

Vendor-Item Table

End of Chapter 2