Database Management Systems. Chapter 2 Part 2

Transcription

1 Database Management Systems Chapter 2 Part 2 Introduction to Database Design Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Class Hierarchies Classify entities sets into Super-class and Subclass. Super-class: Subclasses: Hourly_Emps and Contract_Emps. A subclass entity ISA super-class entity. All attributes of super-class entity set are inherited by the subclass entity set. A subclass entity set has its specific attributes. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 2

2 ISA (`is a ) Hierarchies hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 3 Exercise: Hierarchy Examples In a university database system, Person includes Student, and Employee. Employee includes Faculty, Staff and Student_Assistant. Student includes Graduate_Student, Undergraduate_Student, and Student_Assistant. In a bank system, both checking account and saving accounts are Accounts. At Ford, Vehicle includes Car and Truck. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 4

3 ISA (`is a ) Hierarchies Overlap constraints determine whether two subclasses are allowed to contain the same entity. By default, the answer is Disallowed. Example: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? (Allowed/disallowed) If the answer is Allowed, there should be a statement like A OVERLAPS B. hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 5 Exercise: Overlap? In a university, will a Employee be a Student? In a university, will a Staff be a Faculty member? Who is Faculty? Who is Staff? Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 6

4 ISA (`is a ) Hierarchies Covering constraints determine whether the entities in the subclasses collectively include all entities in the super-class. By default, the answer is No. Example: Does every entity also have to be an Hourly_Emps or a Contract_Emps entity? (Yes/no) If the answer is Yes, there should be a statement like A AND B COVER C. (A and B are subclasses, C is super-class). hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 7 Exercise: Covering All? In a university, is there someone who is not student, faculty, or staff? Yes or No? Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 8

5 ISA (`is a ) Hierarchies Specialization: Entities of super-class are specialized into subclasses. Generalization: Entities of subclasses are generalized by super-class. Reasons for using ISA: To avoid duplicate attributes. To add descriptive attributes specific to a subclass. To identify some entities that participate in a relationship. Example: Only senior employees could be managers. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 9 Aggregation Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships (dashed box). Used when we have to model a relationship involving (entitity sets and) a relationship set. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 10

6 Example Sponsors relationship set describes the association that Projects entity is sponsored by one or more Departments. And a department that sponsors a project assigns employees to monitor the sponsorship. Monitors relationship set associates a Sponsors relationship with an entity. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 11 Aggregation Treated as an entity set Monitors until pid started_on pbudget since did d budget Projects Sponsors Departments Each Department sponsors at least one project. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 12

7 Exercise: Aggregation A job-applicant is interviewed by companies. Some interviews result in a job offer. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 13 Conceptual Design Using the ER Model Design choices: Should a concept be modeled as an entity or an attribute? Should a concept be modeled as an entity or a relationship? Identifying relationships: Binary or ternary? Aggregation? Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 14

8 Entity vs. Attribute Should address be an attribute of or an entity (connected to by a relationship)? Depends upon the use we want to make of address information, and the semantics of the data: If we have several addresses per employee, address must be an entity (since attributes cannot be setvalued). If the structure (city, street, etc.) is important, e.g., we want to retrieve employees in a given city, address must be modeled as an entity (since attribute values are atomic). Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 15 Entity vs. Attribute (Contd.) Works_In4 does not allow an employee to work in a department for two or more periods. from to Works_In4 did d budget Departments Similar to the problem of wanting to record several addresses for an employee: We want to record several values of the descriptive attributes for each instance of this relationship. Accomplished by introducing new entity set, Duration. from Works_In4 Duration did to d budget Departments Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 16

9 Entity vs. Relationship First ER diagram OK if a manager gets a separate discretionary budget for each dept. What if a manager gets a discretionary budget that covers all managed departments? Redundancy: dbudget stored for each dept managed by manager. Misleading: Suggests dbudget associated with department-mgr combination. ISA Managers Manages2 d budget Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 17 since since dbudget Manages2 dbudget did did Departments d budget Departments This fixes the problem! Binary vs. Ternary Relationships p age Covers Dependents Bad design policyid Policies cost If A policy cannot be owned jointly by two or more employees. (Key constraint? But one dependent only for each policy?) Every policy must be owned by some employee. (Total participation constraint? But each policy covers at least one dependent?) Dependents is a weak entity set. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 18

10 Binary vs. Ternary Relationships The additional constraints in the 2nd diagram: Key constraint and Total participation of Policies entity. Key constraint and Total participation of Weak entity Dependents. Bad design policyid Covers Policies cost p p age Dependents Weak Entity age Dependents Purchaser Beneficiary Better design Policies Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke policyid cost 19 Exercise Professors teach Sessions in Classrooms. A prof. teaches several sessions, or may not teach. Each session is taught by at least one prof. Several sessions could be scheduled in one classroom, however, only one classroom is assigned to each session. Students take Sessions in Classrooms. A student should take at least one session. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 20

11 Binary vs. Ternary Relationships (Contd.) An example in the other direction: a ternary relation Contracts relates entity sets Parts, Departments and Suppliers, and has descriptive attribute qty. No combination of binary relationships is an adequate substitute: S can-supply P, D needs P, and D deals-with S does not imply that D has agreed to buy P from S. How do we record qty? Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 21 Aggregation vs. ternary relationship Monitors is a distinct relationship, with a descriptive attribute (a ternary relationship works if there is no attribute of until) Also, we can say that each sponsorship is monitored by at most one employee (a ternary relationship does not work). pid Monitors until started_on since d pbudget did budget Projects Sponsors Departments Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 22

12 Exercise: Aggregation vs. Ternary A job-applicant is interviewed by companies. Some interviews result in a job offer. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 23 Summary of Conceptual Design Conceptual design follows requirements analysis, Yields a high-level description of data to be stored ER model popular for conceptual design Constructs are expressive, close to the way people think about their applications. Basic constructs: entities, relationships, and attributes (of entities and relationships). Some additional constructs: weak entities, ISA hierarchies, and aggregation. Note: There are many variations on ER model. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 24

13 Summary of ER (Contd.) Several kinds of integrity constraints can be expressed in the ER model: key constraints, participation constraints, and overlap/covering constraints for ISA hierarchies. Some foreign key constraints are also implicit in the definition of a relationship set. Some constraints (notably, functional dependencies) cannot be expressed in the ER model. Constraints play an important role in determining the best database design for an enterprise. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 25 Summary of ER (Contd.) ER design is subjective. There are often many ways to model a given scenario! Analyzing alternatives can be tricky, especially for a large enterprise. Common choices include: Entity vs. attribute, entity vs. relationship, binary or n- ary relationship, whether or not to use ISA hierarchies, and whether or not to use aggregation. Ensuring good database design: resulting relational schema should be analyzed and refined further. FD information and normalization techniques are especially useful. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 26