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 Account Has 11 Student Account Has 1..1

Traditional ERD Notations Student Account Faculty Course Has 11 Enroll MM Advise M 1 Teach M 1

UML ERD Notations Student Account Faculty Course Has 1..1 Teach 1..*1..1 Enroll 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 M 1

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, Address Derived attributes Keys: Key attribute uniquely determines an entity. –Candidate key, primary key, composite key

UML Notations Student SID {PK} Sname Fname Lname Address Street City State Zip Phone[1..3] Sex DateOfBirth /Age

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

Student SID Sname FnameLname Phone DateOfBirth Age

Attributes on Relationship Online Shopping Cart Customer ShoppingCart Product Has 1 M M M CID Cname Addr CartIDDate PID Pname Price

Order Form

Online Shopping Cart Customer ShoppingCart Product Has 1 M M M CID Cname Addr CartIDDate Qty PID Pname 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 1 M M M CID Cname Addr CartIDDate Qty PID Pname Price

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: –SSNEnameSexDOB –S1PeterM1/1/75 –S2PaulM12/25/80 –S3MaryF7/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