BUNDANG AIS chapter 9.pptx

7/28/2019 BUNDANG AIS chapter 9.pptx

1/34


2/34

When unnormalized tables are splitand reduced to third normal form(3NF), they must then be linkedtogether by foreign keys.


3/34

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


4/34

Keys in 1:M Associations

a 1:M (or 1:0,M) association exists, theprimary 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 (orless) different items of inventory but each item is supplied by

only one vendor.Business Rule 2.Each vendor supplies the firm with anynumber of inventory items but each item is supplied by onlyone vendor. (See figure 1)


5/34

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


6/34

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

By contrast,

this shows

what the table

structure might

look like if the

designerreversed the

key-

assignment

rule byembedding the


7/34

Keys in M:M Associations

to represent the M:M association betweentables, a link table needs to be created

M:M Business Rule.Each vendor supplies the

firm with any number of inventory items andeach item may be suppplied by any number ofvendors.


8/34

The link table

(Part/Supplier

) contains theprimary keys

for the

records in the

Inventorytable (Part

Num) and the

related

Supplier table

(Supplier

Figure 3-Normalized Database Tables


9/34

Update anomalies can generate

Insertion anomalies can result in

Deletion anomalies can cause the loss of accountingrecords and the

Accountants understand the data normalizationprocess and be able to determine whether a database isproperly normalized.


10/34

It focuses on six primary phases of database design:

1. Identify entities.2. Construct data model showing entity associations.

3. Add primary keys and attributes to the model.

4. Normalize the data model and add foreign keys.

5. Construct the physical database.

6. Prepare the user views.


11/34

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:

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

.what to do


12/34

Key features:

1. The purchasing agent reviews the inventorystatus report (Figure 4) for items that need to

be recorded.

2. The agent selects a supplier and prepares anonline purchase order.

example continuation


13/34

Figure 4-Inventory Status Report


14/34

3. The agent printsa copy of the

purchase order

(Figure 5a) andsends it to the

supplier.

Figure 5a-Purchase Order for Purchases System



15/34

4. The supplier shipsinventory to the

company. Upon its

arrival, the receiving

clerk inspects theinventory and prepares

an online receiving

report (Figure 5b). The

computer systemautomatically updates

the inventory records.

Figure 5b-Receiving Report for Purchases System



16/34

These are things aboutwhich the organizationwishes to capture data.

Two conditions need be met to pass the valid-entitytest:1. An entity must consist of two or more occurrences.

2. An entity must contribute at least one attributethat is not provided through other entities.


17/34

Candidate entities are:

Purchasing Agent

Since we have no information on this point in our brief

description of the system, we will assume no specificdata are captured.

Receiving Clerk

We will assume that no clerk-specific data need be

captured that requires a dedicated table.



18/34

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.



19/34

Inventory Status ReportThis 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.



20/34

Receiving ReportIt is needed to capture transaction specific data that

require additional entities and must be modeled.


Four entities passed:

Inventory

Supplier

Purchase order

Receiving report


21/34

determine the associations between

entities

model associations into an ER (Entity

Relationship) diagram


22/34

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

Inventory entities

2) M:M -association between the Inventory and Supplier

entities3) 1:0,M -association between the Supplier and the

Purchase Order entities

4) 1:1 -association between the Purchase Order and

Receiving Report entities

5) 0,M:M -association between the Receiving Report and

Inventory entities



23/34

Figure 6-Data a Model Showing Entity Associations

This

illustrat

es the

entityassocia

tion in

our

exampl

e.


24/34

Add Primary Keys

assign primary keys to all entities in themodel to uniquely identify records

Add Attributes

every attribute should appear directly orindirectly in one or more user views


25/34

Figure 7-Data Model Showing Primary Keys

This

present

s the

four

entities

in the

modelwith

primary

keys

assigned.


26/34

Figure 8-Data Model Showing Keys and Attributes

The

attributes

assigned to

each entityare derived

from the

user views

of thePurchase

Order and

Receiving

Report and

from the


27/34

remove repeating groups, partialand transitive dependencies

assign foreign keys to be able to linktables


28/34

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 ReportThe 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 DependenciesThe Purchase Order and Receiving Report entities

contain attributes that are redundant with data in

Inventory and Supplier entities.

(see Figure 9)



29/34

Figure 9-Normalized Data Model


30/34

create physical tables populate tables with data


31/34

Figure 10-Normalized Tables


This

illustrates

the 3NF

tablestructures

for the

database.The primary

and foreign

keys linkingthe tables

are

represented

by dottedlines.


32/34

Figure 11-Users View-Purchase Order


33/34

normalized tables should support allrequired views of system users

user views restrict users from haveaccess to unauthorized data


34/34

Prepared by:

BSBA/MA-4A

BUNDANG AIS chapter 9.pptx

Documents

Transcript of BUNDANG AIS chapter 9.pptx