You are on page 1of 34

When unnormalized tables are split and reduced to third normal form (3NF), they must then be linked

together by foreign keys.

Keys in 1:1 Association a true association exists between tables, either (or both) primary keys may be embedded as foreign keys in the related tables

Keys in 1:M Associations a 1:M (or 1:0,M) association exists, the primary key of the 1 side is embedded in the table of the M side
To demonstrate, lets have
Business Rule 1. Each vendor supplies the firm with three (or less) different items of inventory but each item is supplied by only one vendor. Business Rule 2. Each vendor supplies the firm with any number of inventory items but each item is supplied by only one vendor. (See figure 1)

Figure 1-Applying the 1:M Key-Assignment Rule

Figure 2-Reversing the 1:M Key-Assignment Rule

By contrast, this shows what the table structure might look like if the designer reversed the keyassignment rule by embedding the

Keys in M:M Associations to represent the M:M association between tables, a link table needs to be created

M:M Business Rule. Each vendor supplies the firm with any number of inventory items and each item may be suppplied by any number of vendors.

Figure 3-Normalized Database Tables

The link table (Part/Supplier ) contains the primary keys for the records in the Inventory table (Part Num) and the related Supplier table (Supplier

Update anomalies can generate Insertion anomalies can result in

Deletion anomalies can cause the loss of accounting records and the Accountants understand the data normalization process and be able to determine whether a database is properly normalized.

It focuses on six primary phases of database design:


1. 2. 3. 4. 5. 6.

Identify entities. Construct data model showing entity associations. Add primary keys and attributes to the model. Normalize the data model and add foreign keys. Construct the physical database. Prepare the user views.

identify the primary entities of the organization construct a data model of their relationships

Lets have an example with a

Proposal for a new purchasing system: .what to do


Identify the key operational features of the system. Search for the entities that underlie it.

example continuation

Key features:
1. The purchasing agent reviews the inventory

status report (Figure 4) for items that need to be recorded. 2. The agent selects a supplier and prepares an online purchase order.

Figure 4-Inventory Status Report

example continuation
Figure 5a-Purchase Order for Purchases System

3. The agent prints a copy of the purchase order (Figure 5a) and sends it to the supplier.

example continuation
Figure 5b-Receiving Report for Purchases System

4. The supplier ships inventory to the company. Upon its arrival, the receiving clerk inspects the inventory and prepares an online receiving report (Figure 5b). The computer system automatically updates the inventory records.

These are things about which the organization wishes to capture data.

Two conditions need be met to pass the valid-entity test: 1. An entity must consist of two or more occurrences. 2. An entity must contribute at least one attribute that is not provided through other entities.

example continuation

Candidate entities are:


Purchasing Agent Since we have no information on this point in our brief description of the system, we will assume no specific data are captured.
Receiving Clerk We will assume that no clerk-specific data need be captured that requires a dedicated table.

example continuation

Inventory The Inventory entity meets both conditions. We can logically assume that the attributes that define the inventory entity are not provided through other tables.

Supplier The description state that multiple vendors supply inventory. No other entity would logically provide supplier data.

example continuation

Inventory Status Report This user view is derived entirely from existing entities, and provides no additional data that requires a separate entity.

Purchase Order All transaction are unique events that must be captured in the database. While some purchase order data pertain to existing entities (Inventory and Supplier) in the model, other attributes unique to the purchase event will require one or more additional entities.

example continuation

Receiving Report It is needed to capture transaction specific data that require additional entities and must be modeled.

Four entities passed: Inventory Supplier

Purchase order Receiving report

determine the associations between

entities
model associations into an ER (Entity

Relationship) diagram

example continuation

1) 0,M:M -association between the Purchase Order and 2)

3)
4) 5)

Inventory entities M:M -association between the Inventory and Supplier entities 1:0,M -association between the Supplier and the Purchase Order entities 1:1 -association between the Purchase Order and Receiving Report entities 0,M:M -association between the Receiving Report and Inventory entities

Figure 6-Data a Model Showing Entity Associations

This illustrat es the entity associa tion in our exampl e.

Add Primary Keys assign primary keys to all entities in the model to uniquely identify records Add Attributes every attribute should appear directly or indirectly in one or more user views

Figure 7-Data Model Showing Primary Keys

This present s the four entities in the model with primary keys assigne d.

Figure 8-Data Model Showing Keys and Attributes

The attributes assigned to each entity are derived from the user views of the Purchase Order and Receiving Report and from the

remove repeating groups, partial and transitive dependencies assign foreign keys to be able to link tables

example continuation

1. Repeating Group Data in Purchase Order


The attributes Part Number, Description, Order Quantity, and

Unit Cost are repeating group data.

2. Repeating Group Data in Receiving Report


The attributes Part Number, Quantity Received, and

Condition Code are repeating groups in the Receiving Report entity and moved to a entity called Rec Report Item Detail.

3. Transitive Dependencies The Purchase Order and Receiving Report entities contain attributes that are redundant with data in Inventory and Supplier entities.
(see Figure 9)

Figure 9-Normalized Data Model

create physical tables populate tables with data

example continuation Figure 10-Normalized Tables

This illustrates the 3NF table structures for the The primary database. and foreign keys linking the tables are represented by dotted lines.

Figure 11-Users View-Purchase Order

normalized tables should support all required views of system users


user views restrict users from have access to unauthorized data

Prepared by:

BSBA/MA-4A

You might also like