DATABASE LOGICAL

DESIGN - I

Chandra S. Amaravadi

1

2

WHAT IS DESIGN?

prod#, ss#, descr, cust name, cc#, price

One way to think about design is as grouping attributes into tables

? ?

3

DESIGN OBJECTIVESThe objective of database design is to develop a set ofwell structured tables so that:

Data is in the most efficient form No uncontrolled redundancies User needs satisfied Database can be easily implemented

The output of design are a set of well structured/normalized tables.

ILL STRUCTURED TABLES

EMPLOYEE

4

eid name title dt. promoted

2356 Armstrong Analyst 4/14/09

3286 Nickerson Sr. Analyst 5/1/12; 2/5/14

EXAMPLE OF

Ill structured tables are problematic. why?

DESIGN CONCEPTS

ANOMALY:

Insertion

Deletion

Update

An inconsistency in the database that results from either

adding records, deleting them or updating them. Three

types of anomalies:

5

DESIGN CONCEPTS..

INSERTION ANOMALY:

An insertion anomaly occurs if when trying to add a record, it cannot

be added without additional information or it may need to be

added in multiple places instead of in one location.

DELETION ANOMALY:

A deletion anomaly occurs, if when we try to delete a record,

we have to perform the deletion a number of times, or if we

lose information we did not intend to lose.

6

DESIGN CONCEPTS..

UPDATE ANOMALY/MODIFICATION ANOMALY:

An update anomaly occurs, if when we try to update a record,

instead of making the update in one location, we need to update

in multiple locations.

Are anomalies common in the file processing approach?

7

EMPLOYEES

ILLUSTRATION OF ANOMALIES

8

empID name dept. salary course dt completed

100 Jeff Simpson Mktg. 48K SPSS 06/19/14

100 Jeff Simpson Mktg. 48K Survey 06/19/13

140 Alan Beeton Acctg. 52K Tax Acct 12/08/12

110 Chris Lucero IS 43K SPSS 01/22/13

110 Chris Lucero IS 43K C++ 04/22/15

190 Lorenzo Davis Fin. 55K    

150 Susan Martin Mktg. 42K SPSS 06/19/13

150 Susan Martin Mktg. 42K Java 08/12/14

ANOMALIES..

1. Insert Tom White, ID 130, Finance, 60K

2. Delete Employee with ID 140

3. Employee with ID 100 gets a 10% salary increase

9

10

WELL STRUCTURED TABLE

10

no repeating groups

redundancies minimized

anomalies minimized

all attributes dependent on pkey

full functional dependency

A Well structured table may be defined in a number of ways:

METHODS OF DESIGN

ER diagrams (using thumb rules)

Normalization theory

FD approach

brute force

11

Design can be carried out with:

DESIGN FROM ER CHARTS,USING THUMB RULES

12

3. In the case of M:N, put each eclass into a separate table;

put the relationship itself into a third table with Pkey

consisting of Pkeys from the M and N sides.

In the case of 1:M, put each eclass into separate

tables; Include the Pkey from the one side

as a foreign key on the M side.

2.

In the case of 1:1, put each eclass into a separate

table, with a cross-reference key in either.

1.

DESIGN FROM ER:

13

Following are the rules for converting an ER diagram into a design

PRODUCT WARRANTYHAS

DESIGN FROM ER..

Prod# Descr War# Eff_Dt

Warranty

War# Eff_dt ???

Products

Prod# Descr ???

14

In the case of 1:1, put each eclass into a separate

table and ____________________.

DESIGN FROM ER..

CUSTOMER

ORDERS

Places

Cust# Name

PRODUCTSAre for

Customer

Cust# Name

Orders

Ord# Ord_dt ????

Ord# Ord_dt

15

In the case of 1:M, put each eclass into

a separate table and ___________.

ORDERS PRODUCTSAre for

DESIGN FROM ER..

Ord# Ord_dt Prod# Descr.

Orders

ord# ord_dt

Products

prod# descr

Orders for Products

??? ???? qty

Qty

16

In the case of M:N, put each _____ into a separate table and place the ___________ into a separate table with keys from ___ side and __ side

DISCUSSIONDEVELOP DESIGNS FOR THE FOLLOWING SITUATIONS

CAR

DRIVER

assigned

EMPLOYEES

PROJECT

has

COMPANY

SUPPLIER

supplies

car# model

SS# name proj# mgr

SS# title

s# location.

name addr.

17

THREE WAY AND HIGHER

EMPLOYEES

DEPT

HAS

emp# ti

d# name

18

How can we do designwith degree >= 3?

PROJECTS

proj#

cost

DESIGN WITH NORMALIZATION

19

DESIGN USING NORMALIZATION

Use normalization theory if: Data relationships complex

No planning/ER done

Maintenance

Alternative to ER approach

20

Normalization: The process of designing well-structured tables.

DESIGN CONCEPTS FUNCTIONAL DEPENDENCIES

21

DESIGN CONCEPTS..

A relationship between two or more attributes such that if we know one

attribute we can uniquely determine other attributes.

Functional dependency:

a --> b, c.. ; “a determines b, c..”,

; “b,c.. are dependent on a”

22

FD test: For each value of a there is one and only one value of b.

DESIGN CONCEPTS..

Functional dependency (FD):

relationship between attributes (L -> R unless specified)

a b, c, d is referred to as a functional dependency diagram

Each value of a is associated with one value of b; one c…

For a given value of “b” (or “c”..) there can be many values of “a”

23

a b : a determines b, b is dependent on aa b : a does not determine b, no relationship (normally omitted) a b : there are multiple values of b for each a.

24

FD DIAGRAM EXAMPLES

pp# name of issuing countryflt# name of captainstudent id GPAplayer id team name

pp# visa#’sGPA student id City name Hotel id

price descr.gpa descr.

Please note that FD is valid only in the first group; second group indicates need foradditional keys (may result in partial functional dependencies)

FULL FD RULE

relational Database Rule (Full functional dependency):

All attributes must be fully dependent on the primary key

a b c

25

Then they can be placed in a table with ____ as pkey.

FD WHEN DATA IS GIVEN

ename --> phone#?

phone# --> ename?

ename title?

employee dependents?

EMPLOYEES

26

ename phone# title dependents

Casey 621-2876 Engineer Tracy, Tom

Hugh 621-3875 Manager Null

Chris 621-4534 Secretary Ann, Angie

Franklin 621-2876 Engineer Pat

When data is given, perform FD test:

27

a b c

a1 b1 c1

a1 b1 c2

a2 b2 c3

FD WHEN DATA IS GIVEN..

a --> b?

a c?

b c?

FD WHEN DATA IS NOT GIVEN

A flight (flt#) arrives or departs at one gate (gate#)

A flight (flt#) can have one captain (captain name)

A flight (flt#) can have one or more co-pilots (co-pilot name)

A flight (flt#) can go to multiple destinations (dest. name)

A flight (flt#) uses one or more altitudes (alt)

A flight (flt#) has one or more attendants (attdt_name)

A flight (flt#) has many crew members (cr_name)

A flight (flt#) lands at one or more airports (a_code)

When data is not given, make case by case assumptionsand perform FD test. (Assumptions already given here):

Note: FDs are split into pairs here for explanatory purposes

28

29

FD WHEN DATA IS NOT GIVEN..

Cust places multiple orders A flight has multiple pilots, but a single captain. Each pet has a single owner Each actor has an agent and one current project he/she is working on relationship between ss# and user name for an online store? User name, ss#, web site, company name, cust. credit card#

When data is not given, make case by case assumptionsand perform FD test. (Assumptions already given here):

Examples of FDs:

SS# ---> Name, age, sex etc.

Distance,Class --> Airfare.

ISBN# --> Book title, price etc.

DETERMINANTS & CANDIDATE KEYS

The LHS of the FD is called a determinant, and is a candidate key.

A candidate key is a key that can be used a pkey (usually LHS)

Supposea bc -> b

30

What are the determinants? candidate keys? design?

THE FD APPROACH

Suppose we have

A --> B, C, D

What will normalization yield?What is the foreign key here?

31

FUNCTIONAL DEPENDENCY RULES1. Reflexive rule

x -- > x

e.g. ISBN# --> ISBN#

2. Union rule

If x -> y and x --> z then

x--> yz

e.g. ISBN# --> title and ISBN# --> price then

ISBN# --> title, price

32

3. Transitivity rule

If x--> y and y --> z then x--> z

e.g. if VIN --> Model and Model --> Engine size then

VIN --> Engine size;

FUNCTIONAL DEPENDENCY RULES..

4. Substitution rule

If x -> y and yz --> w then

xz --> w

e.g. if model --> processor and

processor, buswidth --> speed then

model, buswidth --> speed

33

equip#, p# equip#, p# What rule is this?

p# descrP# price

=> p# descr, price

What rule is this?

34

If part# descr serial# part#

Then serial# descr

What rule is this?

FUNCTIONAL DEPENDENCY RULES..

a -> b and b cthen a c

What rule is this?

a -> b and a cthen a ???

What rule is this?

FUNCTIONAL DEPENDENCY RULES..

Suppose the following FDs hold,

a e b, c, df a

Then what is the primary key of the table b, c, d, e, f?

35

FUNCTIONAL DEPENDENCY DIAGRAMS

DRAWING FD DIAGRAMS

List all attributes (horizontally) placing candidate key leftmost

Take each attribute (after candidate key) and find out its determinant

if data is given, do the FD test with the data.

if no data is given, make assumptions on a case by case basis.

For each value of an attr, how many of the other attr. are there?

If FD exists, draw single arrow

if no FD do not draw the relationship

if there are multiple values for each a, then draw a double arrow

36

The first step in design using FD approach is to draw an FD diagram:

NORMALIZATION PROCESS

Identify and diagram the functional dependencies

Group functional dependencies according to their determinants

Place each set of FDs (along with determinants) in a separate table.

Use determinants as the pkeys.

Add appropriate foreign keys based on the application.

THE FUNCTIONAL DEPENDENCY APPROACH

37

38

F.D. diagram:

bid location, mgr_nm, # of emp., mgr_join_dt.

AN EXAMPLE OF FD APPROACHDraw FD between a bank id (bid), location, manager (mgr_nm), # of employees andManager join date (mgr_join_dt)

Group FDs according to common determinants:

bid location, mgr_nm, # of emp.mgr_nm mgr_join_dt

Develop design using notation below:

Bank(bid, location, mgr_nm, #of emp)Manager(mgr_nm, mgr_join_dt)

Check for cross reference keys

FOR DISCUSSION

ord#: Unique identifier for order (an order can be for many parts)ord dt: date of orderp#: unique number for partsqty: # of a certain part that is ordered c# : container for finished parts (one container per part)#fin: # of finished partsdie#: Die used to manufacture parts (one die per part)shelf#: the shelf where the die is located

39

Draw an FD diagram and develop a design for the following situation:

Strauble-Dytisa

REVIEW OF CONCEPTS

Basic Concepts Description

Ill structured table that is poorly designed; or has redundancies or more than one value at row-column intersection

Well structured Table that is well designed; has no redundancies and atomic values at row-column intersection

Anomaly An inconsistency during a database activity insert, delete or update

Insertion anomaly An insertion anomaly occurs if when trying to add a record, it cannot be added without additional information or it may need to be added in multiple places instead of in one location.

Deletion anomaly A deletion anomaly occurs, if when we try to delete a record, we have to perform the deletion a number of times, or if we lose information we did not intend to lose.

Update anomaly An update anomaly occurs when making an update to a table, we have to update the same data in multiple places.

Primary key An attribute whose value is unique within an entity class (table) e.g. SS#, Part# etc.

41

REVIEW OF CONCEPTS

Basic Concepts Description

Functional dependency A relationship between two or more attributes such that if we know a, we can uniquely determine b

Fd test For each value of a there is one and only one b

Full FD All attributes are fully functionally dependent on pkey

Determinant LHS of a Functional Dependency (taken as candidate key)

Candidate key A key that can serve as the primary key

Foreign key/Cross-reference key

A key that serves as reference between two tables

42