CS370 Spring 2007 CS 370 Database Systems Lecture 6 Introduction to Database Design

CS370 Spring 2007 A case Study A primary school student writes a composition about a picnic: Today is Sep 9, the weather is fine. My classmates, Ali, Maria and I go to a picnic in park. Our teacher is Mr. Khan Picnic weather destination date Students Name Teacher Name My Initial Design:

CS370 Spring 2007 Questions ? Why “Ali”, “Maria”, “Mr. Khan” are not in the ER diagram ? What do these names tell us ? What are the keys of Student, Picnic & Teacher ? What are the cardinalities of the relationships ?

CS370 Spring 2007 Every student has an ID number, it is better to keep it in the database and use it as a key I bet that there won’t be teachers with the same name; otherwise, I’ll add employee number and use it as a key goes is N:M, why ? A picnic has more than one student participating; also, a student can go to more than 1 picnic. However, this N:M relationship allows a student to go to more than one picnic on the same date leading is N:1, why? Depends on your assumptions –I assume a teacher can only lead 1 picnic on a certain date, so given the teacher name and the date, I can identify a picnic Picnic is made a weak entity. I could have added a PicnicNo, but it would be very awkward. My solution Student StudentNo Nameweather date destination Picnic goes leading Teacher Name

CS370 Spring 2007 E-R Design Decisions The use of an attribute or entity set to represent an object. –Should an address be an attribute or entity? Whether a real-world concept is best expressed by an entity set or a relation set. –Should marriage be an entity or relationship? –Should picnic be an entity or relationship? The use of a ternary relationship versus a pair of binary relationships. –See the borrow-loan-branch example The use of a strong or weak entity set. –See the employee-dependent example

CS370 Spring 2007 E-R Diagram for Company Database EMPLOYEE WORKS_FOR MANAGES CONTROLS Startdate DEPARTMENT WORKS_ON PROJECT Hours DEPENDENTS_OF DEPENDENT SUPERVISION supervisee supervisor FnameMinitLname Name Sex Address Salary Ssn Bdate Number Of Employees Name Number Locations Name Number Location RelationshipBirthdateSexName Can you translate it back into English?

CS370 Spring 2007 Consider representing Part-time and Full-time employees in the company database: –Either you have two entity types will lots of similarity –Or you have a single entity type with redundancy for most of the entities within it ER model is extended to support other features such as generalization (but it won’t be covered in this course!) Limitations of ER model

CS370 Spring 2007 Reduction of an E-R Schema to tables Primary keys allow entity sets and relationship sets to be expressed uniformly as tables which represent the contents of the database. A database which conforms to an E-R diagram can be represented by a collection of tables. Always! Converting an E-R diagram to a table format is the basis for deriving a relational database design from an E-R diagram.

CS370 Spring 2007 Composite key Representing Entity Sets as Tables A weak entity set becomes a table that includes a column for the primary key of the identifying strong entity set A strong/regular entity set reduces to a table with the same attributes. payment loan-no payment-datepayment-nopayment-amount L-17 L-15 L May May May customer customer-name customer-streetcustomer-id Jones Hayes Smith Main North customer-city Harrison Rye Harrison

CS370 Spring 2007 Representing Relationship Sets as Tables depositor A many-to-many relationship set is represented as table with columns for the primary keys of the two participating entity sets, and any descriptive attributes of the relationship set. customer depositor loan loan-no cust-no share% date cust-name

CS370 Spring For 1:N and 1:1 relationships, you can create a table for each relationship +But it is more concise to merge the relationship-table with the entity-table on the “N” side customer cust-no cust-name A12345 B56789 Peter Wong Mary Cheung loan loan-no L-001 L-002 date Sep 2000 Aug 2001 customer borrow loan cust-no cust-name date loan-no cust-no A12345 B56789 indicates who borrowed the loan

CS370 Spring In a 1:N relationship, can we include the key from the “N” side in the table representing the entity in the “1” side? I.e., include Loan_no into the Customer table. Why and Why not? Questions to Think About +How can we express existence constraints on table?

CS370 Spring 2007 Questions to Think About (Cont.) +In a 1:1 relationship, we can include the key from either entity into the table representing the other entity. Suppose the Loan-Customer relationship is 1:1, would you include the Customer_no into Loan or Loan_no into Customer? customer borrow loan cust-no cust-name date loan-no loan loan-no L-001 L-002 date Sep 2000 Aug 2001 cust-no A12345 B56789 customer cust-no cust-name A12345 B56789 Peter Wong Mary Cheung loan-no L-001 L-002 Which one is better?

CS370 Spring 2007 Questions to Think About (Cont.) +How can we express existence constraints on table? customer borrow loan cust-no cust-name date loan-no loan loan-no L-001 L-002 date Sep 2000 Aug 2001 cust-no A12345 Not allowed; must be enforced by DBMS

CS370 Spring 2007 Weak Entities +Since a weak entity has to include the primary key of the identifying entity, the 1:N relationship is already captured. E.g., The payment table already contains information about the Loan (I.e., loan_no) Already indicates the 1:N relationship between loan-no and payment-no payment loan-no payment-datepayment-nopayment-amount L May May May

CS370 Spring 2007 Summary of Symbols Used in E-R Notation

CS370 Spring 2007 Summary of Symbols Used in E-R Notation

CS370 Spring 2007 E-R Diagram for a Banking Enterprise

CS370 Spring 2007 E-R Diagram for Exercise 2.12 E-R Diagram for a Publisher Enterprise