ITEC 3220A Using and Designing Database Systems

ITEC 3220AUsing and Designing Database Systems

Instructor: Gordon TurpinCourse Website: www.cse.yorku.ca/~gordon/itec3220S07 Office: CSEB3020

2

Supertypes and Subtypes

• Generalization hierarchy: depicts relationships between higher-level supertype and lower-level subtype entities

• Supertype:Supertype: contains the shared attributes

• Subtype:Subtype: contains the unique attributes• Inheritance:Inheritance:

– Subtype entities inherit values of all attributes of the supertype

– An instance of a subtype is also an instance of the supertype

3

Supertypes and Subtypes (Cont’d)

Supertype/ subtype relationships

SUPERTYPE

Attributes shared by all entities

SUBTYPE1

Attributes unique to subtype2

SUBTYPE2

Attributes unique to subtype1

General entity type

And so forth

Specialized version of supertype

4

Supertypes and Subtypes (Cont’d)

• Disjoint relationships– Unique subtypes– Non-overlapping– Indicated with a ‘G’

• Overlapping subtypes– An instance of the supertype

could be more than one of the subtypes

– Indicated with a ‘Gs’

5

Generalization Hierarchy with Overlapping

Subtypes

Chapter 5

Logical Database Design and Normalization of Database

Tables

7

In this chapter, you will learn:

• How to transform ERD into relations• What normalization is and what role it plays

in database design• About the normal forms 1NF, 2NF, 3NF, BCNF,

and 4NF • How normal forms can be transformed from

lower normal forms to higher normal forms• Normalization and E-R modeling are used

concurrently to produce a good database design

• Some situations require denormalization to generate information efficiently

8

Transforming ERD into Relations

• Step one: Map regular entities– Each regular entity type in an ER

diagram is transformed into a relation– The name given to the relation is

generally the same as the entity type– Each simple attribute of the entity

type becomes an attribute of the relation and the identifier of entity becomes the primary key of the corresponding relation

9

Example

Student_ID Student_Name Other_Attributes

STUDENT

10

Transforming ERD into Relations (Cont’d)

• Step two: Map weak entities– Create a new relation and include all

of the simple attributes as the attributes of this relation. Then include the primary key of the identifying relation as a foreign key attribute in this new relation. The primary key of the new relation is the combination of this primary key of the identifying relation and the partial identifier of the weak entity type.

11

Example

EMPLOYEE Has DEPENDENT

Employee_ID Employee_NameDependent_Name

Gender

Date_of_birth

Employee_ID

Employee_Name

EMPLOYEE

DEPENDENT

Dependent_Name

Employee_ID

Date_of_birth

Gender

12


• Step three: Map binary relationship– Map Binary one-to-many relations

• First create a relation for each of the two entity types participating in the relationship, using the procedure described in step one.

• Next, include the primary key attribute of the entity on the one-side of the relationship as a foreign key in the relation that is on the many-side of the relationship.

13

Example

M

Order_DateOrder_ID

Customer

Customer_NameCustomer_ID

Submits Order

1

(1,1)(0,N)

Customer_ID

Customer_Name

Customer

Order

Order_ID Order_Date

Customer_ID

14


• Step three: Map binary relationship (Cont’d)– Map binary one-to-one relationships

• First, two relationships are created one for each of the participating entity types.

• Second, the primary key of one of the relations is included as a foreign key in the other relation.

15

Example

LocationCentre_Name

Nurse

Nurse_NameNurse_ID

In_charge Care Centre

1

(1,1)(0,1)

1

Nurse_ID Nurse_NameNurse

Centre_Name

Location Nurse_in_charge

Care Centre

16


• Step Four: Map composite Entities– First step

• Create three relations: one for each of the two participating entities, and the third for the composite entity. We refer to the relation formed from the composite entity as the composite relation

– Second step• Identifier not assigned: The default primary key

for the composite relation consists of the two primary key attributes from the other two relations.

• Identifier assigned: The primary key for the composite relation is the identifier. The primary keys for the two participating entity types are included as foreign keys in the composite relation.

17

Example

1

Order

Order Line

Order_DateOrder_ID

Quantity

Product Price

Description

Product_ID

(1,N)

M

M

1

(1,1)

(1,1)

(0,N)

18

Example

Order_ID Order_Date

Product_ID

Description

Standard_Price

Product_ID

Order_ID Quantity

Order

Order Line

Product

19

Example

Customer_ID Customer_NameCustomer

Shipment_No

Vendor_ID

Customer_ID

Date

Amount

Shipment

Vendor Vendor_ID

Address

M

AddressVendor_ID

Customer

NameCustomer_ID

Shipment Vendor

Shipment_No Amount

Date

1 M 1

20


• Step Five: Map unary relationship– Map unary one-to-many relationship

• The entity type in the unary relationship is mapped to a relation using the procedure described in Step one. Then a foreign key attribute is added within the same relation that references the primary key values. A recursive foreign key is a foreign key in a relation that references the primary key values of that same relation.

21

Example

Manages

Employee_ID BirthdateName

Employee

1

M (1,1)

(0,N)

Employee_ID

Name

Birthdate

Manager_ID

Employee

22


• Step six: Map ternary relationship– Convert a ternary relationship to a

composite entity– To map a composite entity that links

three regular entities, we create a new composite relation. The default primary key of their relation consists of the three primary key attributes for the participating entities. Any attributes of the composite entity become attributes of the new relation

23

Example

1 1

(1,1)

(0,N)

(1,1)(0,N)

(0,N)

(1,1)M

M

1

Treatment

Physician Patient

Physician_ID Physician_NamePatient_ID Patient_Name

DescriptionTreatment_

Code

Patient Treatment

Time

Date

Results

M

24

Example

Patient_ID Patient_Name

Treatment_Code

Description

Physician_ID

Physician_Name

Patient_ID

Physician_ID

Treatment_Code

Date Time Result

Patient

Physician

Treatment

Patient Treatment

25


• Step seven: Map supertype/subtype relationships1. Create a separate relation for the supertype

and for each of its subtype2. Assign to the relation created for the

supertype the attributes that are common to all members of the supertype, including the primary key

3. Assign to the relation for each subtype the primary key of the supertype, and only those attributes that are unique to that subtype

4. Assign one attribute of the supertype to function as the subtype discriminator

26

Example

Employee_Name

Address

Date_HiredEmployeeEmployee_Number

Employee_Type

SalariedEmployee

HourlyEmployee

Gs

Hourly_Rate Stock_OptionAnnual_Salary

27

Example

Employee_Number

Employee_Name

Address

Employee_Type

Date_Hired

S_Employee_Number

Annual_Salary

Stock_Option

H_Employee_Number

Hourly_Rate

Employee

Hourly_Employee

Salaried_Employee

28

Database Tables and Normalization

• Table is the basic building block in database design

• Normalization is the process for assigning attributes to entities– Reduces data redundancies– Helps eliminate data anomalies– Produces controlled redundancies to link tables

• Normalization stages– 1NF - First normal form– 2NF - Second normal form– 3NF - Third normal form– 4NF - Fourth normal form

29

Need for Normalization

30

Anomalies In the Table

• PRO_NUM intended to be primary key

• Table displays data anomalies– Update

• Modifying JOB_CLASS

– Insertion• New employee must be assigned project

– Deletion• If employee deleted, other vital data lost

31

Conversion to 1NF

• Step 1: Eliminate the Repeating Groups– Present data in a tabular format,

where each cell has a single value and there are no repeating groups

– Eliminate repeating groups by eliminating nulls, making sure that each repeating group attribute contains an appropriate data value

• Step 2: Identify the Primary Key– Primary key must uniquely identify

attribute value

32

Dependency Diagram (1NF)

33

1NF Summarized

• All key attributes defined• No repeating groups in table• All attributes dependent on

primary key• All relational tables satisfy 1NF

requirements

34

Conversion to 2NF

• Start with 1NF form:• Write each key component on

separate line• Write original key on last line• Each component is new table• Write dependent attributes after

each keyPROJECT (PROJ_NUM, PROJ_NAME)EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR)ASSIGN (PROJ_NUM, EMP_NUM, HOURS)

35

2NF Conversion Results

36

2NF Summarized

• In 1NF

• Includes no partial dependencies– No attribute dependent on a portion

of primary key

• Still possible to exhibit transitive dependency– Attributes may be functionally

dependent on nonkey attributes

37

Conversion to 3NF

• Create separate table(s) to eliminate transitive functional dependencies – For every transitive dependency, write its

determinant as a PK for a new table– Identify the Dependent Attributes

PROJECT (PROJ_NUM, PROJ_NAME)ASSIGN (PROJ_NUM, EMP_NUM, HOURS)EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS)JOB (JOB_CLASS, CHG_HOUR)

38

3NF Summarized

• In 2NF

• Contains no transitive dependencies

39

Boyce-Codd Normal Form (BCNF)

• Every determinant in the table is a candidate key– Determinant is an attribute

whose value determines other values within a row

– 3NF table with one candidate key is already in BCNF

40

3NF Table Not in BCNF

41

Decomposition of Table Structure to Meet BCNF

42

Decomposition into BCNF

43

An Example

GRADE( Student_ID, Student_Name, Address, Major, Course_ID, Course_Title, Instructor_Name, Instructor_Office, Grade)

44

Normalization and Database Design

• Normalization should be part of the design process

• E-R Diagram provides macro view• Normalization provides micro view of

entities– Focuses on characteristics of specific entities– May yield additional entities

• Difficult to separate normalization from E-R diagramming

• Business rules must be determined

45

Higher-Level Normal Forms

• Fourth Normal Form (4NF)

– Table is in 3NF

– Has no multiple sets of multivalued dependencies

46

Conversion to 4NF

Stud-ID Course Service

1126 1212F Red Cross

1126 1620F United Way

1126 1320F


1126 1212F

1126 1620F

1126 1320F

1126 Red Cross

1126 United Way


1126 1212F Red Cross

1126 1620F United Way

1126 1320F

Multivalued Dependencies

Set of Tables in 4NF

Stud-ID Course

1126 1212F

1126 1620F

1126 1320F

Stud-ID Service

1126 Red Cross

1126 United Way

47

Denormalization

• Normalization is one of many database design goals

• Normalized table requires – Additional processing– Loss of system speed

• Normalization purity is difficult to sustain due to conflict in:– Design efficiency– Information requirements– Processing

48

Exercise

Part_No

Description Vendor_Name

Address Unit_Cost

1234 Logic Chips Fast ChipsSmart Chips

Cupertino

Phoenix

10.00

8.00

5678 Memory Chips

Fast Chips

Quality ChipsSmart Chips

Cupertino

Austin

Phoenix

3.00

2.00

5.00

Part Supplier Data

49

Exercise(Cont’d)

• Convert the table to a relation in first normal form (Named Part Supplier)

• List the functional dependency in the Part Supplier and identify a candidate key

• For the relation Part Supplier, identify the followings: an insert anomaly, a delete anomaly, and a modification anomaly.

• Draw a relation schema and show the functional dependencies

• Develop a set of 3NF relations from Part Supplier

50

Chapter 5 Review

• How to transform ERD into relations

• Definitions: 1NF, 2NF, 3NF, BCNF, and 4NF

• How normal forms can be transformed from lower normal forms to higher normal forms

ITEC 3220A Using and Designing Database Systems

Documents

Transcript of ITEC 3220A Using and Designing Database Systems