View
227
Download
0
Tags:
Embed Size (px)
Citation preview
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