Data Modeling and Relational Database Design

ISYS 650

Conceptual Database Design Methodology

• Identify entity types.• Identity relationship types between the entity

types.• Identify and associate attributes with entity or

relationship types.• Determine attribute domains.• Determine candidate keys and primary key.• Validate conceptual model:

– Check for redundancy, support required transactions, review the model with user

Entity Type

• A collection of entities that share common properties or characteristics.

• An entity type represents a collection of entities.

• In an ERD, it is given a singular name.

• Diagrammatic representation:– A rectangle labeled with the name of the entity

Relationship Type

• Relationship: Interaction between entity types.– It is an association representing an interaction

among the instances of one or more entity types that is interest to the organization.

• It has a verb phrase name:– Faculty teach Course, Faculty advise Student– Customer open Account, Customer purchase

Product.

Binary Relationship types and instances

a) Relationship type

b) Relationship instances

Binary Relationship

• A relationship involves two entity types.

• Three kinds of Binary Relationship - – 1:1– 1:M– M:M

Interpretation of an M:M Relationship

Peter

Paul

John

Woody

Alan

Mary

Linda

Nancy

Mia

Pia

A boy may date 0, 1, or many girls.

A girl may date 0, 1, or many boys.

Note: “Many boys date many girls” is not a correct interpretation.

Boy Girl

Cardinality Constraint

• A cardinality constraint specifies the number of instances of entity type A that can (or must) be associated with each instance of entity type B.

• Participation constraint– Full participation (Mandatory)– Partial participation (Optional)

Notations

Other Notations

UML Notations:– 0..1, 1..1– 0..*, 1..*– 3..5

• Traditional:

Student AccountHas1 1

Student AccountHas

1..11..1

Traditional ERD Notations

Student Account

Faculty Course

Has1 1

EnrollM MAdvise

M

1

TeachM1

UML ERD Notations

Student Account

Faculty Course

Has1..11..1

Teach

1..*1..1

Enroll

0..* 0..*Advise

0..*

1..1

Other Notations

Student Account

Faculty Course

Has

Teach

Enroll

0..*Advise

Recursive Relationship

• A relationship type where the same entity type participates more than once in different roles.

• Examples:– Employee – Supervise -- Employee– Student -- Tutor– Student– Faculty – Evaluate -- Faculty

Employee

Supervise

Supervisor

Supervisee

Employee

Supervise

M1

Attributes• Properties of an entity or a relationship.• Simple and composite attributes

– Address:Street address, City, State, ZipCode– Street Address: Number, Street, Apt#– Phone#: Area Code, number

• Single-valued and multi-valued attributes– Student’s Major attribute– Faculty’s DegreeEarned attribute– Vehicle’s Color attribute– Others: PhoneNumber, EmailAddress

• Derived attributes• Keys: Key attribute uniquely determines an entity.

– Candidate key, primary key, composite key

UML Notations

StudentSID {PK}Sname Fname LnameAddress Street City State ZipPhone[1..3]SexDateOfBirth/Age

SID {PK}Sname( Fname, Lname)Address( Street, City, State, Zip){Phone}SexDateOfBirth[Age]

Student

SID Sname

Fname Lname

Phone DateOfBirth

Age

Attributes on Relationship Online Shopping Cart

Customer ShoppingCart

Product

Has

Has

1 M

M

M

CID CnameAddr CartID Date

PIDPname

Price

Order Form

Online Shopping Cart

Customer ShoppingCart

Product

Has

Has

1 M

M

M

CID CnameAddr CartID Date

Qty

PIDPname

Price

Attributes on Relationship

• Examples:– Student/Course: Grade– Order/Product: Quantity

N-ary Relationship

• Doctor – Patient – Ailment

• Police – Criminal – Crime

• AirCraft – Bomb – Target

• Note: There is no deterministic relationship (1:1 or 1:M) between any two of these entities.

Examples of relationships of different degrees (cont.)

c) Ternary relationship

Note1: a relationship can have attributes of its own.Note2: This ternary relationship exists only if there is no binary relationship between these three entities.

Entities can be related to one another in more than one way

Examples of multiple relationships

Employees and departments

Example: Auction site: User and Auction Item

Properties of a Relation

• Simple attribute– No composite, no multivalued attribute

• Each relation must have a primary key:– Simple or composite key– May have other keys (candidate keys)– Key cannot be null– Cannot be duplicated

Integrity Constraints

• Domain constraints

• Entity integrity:– Primary key cannot be null, cannot be

duplicated

• Referential integrity

• Other constraints

Relational Database Design • Entity: Create a table that includes all simple

attributes– Composite

• Multi-valued attribute: Create a table for each multi-valued attribute– Key + attribute

• Relationship: – 1:1, 1:M

• Relationship table: for partial participation to avoid null values• Foreign key

– M:M: relationship table– N-ary relationship: relationship table– Recursive relationship

• Attribute of relationship

Online Shopping Cart

Customer ShoppingCart

Product

Has

Has

1 M

M

M

CID Cname EmailAddr CartID Date

Qty

PID PnamePrice

Recursive Relationship

Note: Partial participation

Ternary Relationship

Third Normal Form

• The database designed according to these rules will meet the 3NF requirements.

Normalized Database

• A normalized database is a database where in each relation the non key fields are functionally dependent on the key, the whole key, and nothing but the key.

Function Dependency

• Relationship between attributes

• X -> Y– The value of X uniquely determines the value

of Y.– Y is functionally dependent on X.– A value of X is associated with only one value

of Y.

Example• Employee table:

– SSN Ename Sex DOB– S1 Peter M 1/1/75– S2 Paul M 12/25/80– S3 Mary F 7/4/72

• Function Dependencies:– SSN -> Ename, SSN ->Sex, SSN -> DOB– SSN -> Ename, Sex, DOB

• Any other FD:– Ename -> SSN ?– Ename -> Sex ?– DOB -> SSN ?

• What is the key of Employee table:– SSN

• Observations:– All non-key fields are functionally dependent on SSN.

– There is no other FD.

– The only FD is the key dependency.

– There is no data duplication in the Employee table.

If we mix a multivalue attribute with regular attributes in one table

• Employee Table:– SSN, Ename, Sex, DOB, Phone– Assuming an employee may have more than 1

phone.

• Key: SSN or SSN + Phone

• Duplication ?

• Problem: Some non-key fields depend on part of the key– SSN + Phone -> Ename, Sex, DOB– SSN -> Ename, Sex, DOB

If we mix two entities with M:M relationship in one table

• StudentCourse table:– SID, Sname, GPA, CID, Cname, Units

• Key: SID + CID

• Duplication?

• Problem: Some non-key fields depend on part of the key– SID+CID -> Sname, GPA, Cname, Units– SID -> Sname, GPA– CID-> Cname, Units

If we mix two entities with 1:M relationship in one table

• FacultyStudent table:– Faculty Advise Student: 1:M relationship– FID, Fname, SID, Sname, SAddress

• Key: SID

• Duplication?

• Problem: Not nothing but the key– SID -> FID, Fname– FID -> Fname

Third Normal Form

• Every non-key field is:– Fully functionally dependent on the key, and– Not transitively dependent on the key.

• The database does not have duplication due to mixing: – Multi-value attribute with single-value attributes– Entity types with relationship