CS/INFO 330 Entity-Relationship Modeling Mirek Riedewald mirek@cs.cornell.edu Announcements Office hour update (see class homepage) First homework assignment will be available from CMS later today Some material will be covered in the next lecture but you can start already Due 9/10 CS/INFO 330 2 Goals of This Lecture Understand ER modeling CS/INFO 330 3 1
Last Lecture Why Store Data in a DBMS? Transactions (concurrent data access, recovery from system crashes) High-level abstractions for data access, manipulation, and administration Data integrity and security Performance and scalability Some introductory remarks about keys etc. We will review this in today s lecture. CS/INFO 330 4 Why ER Modeling? Model business scenario to store all relevant data in DBMS Do this in a systematic way Clear semantics Easy to map to an implementation in a database CS/INFO 330 5 Case Study: Internet Bookshop Your customer: I would like my customers to be able to browse my catalog of books and place orders over the Internet. Currently, I take orders over the phone. I have mostly corporate customers who call me and give me the ISBN number of a book and a quantity; they often pay by credit card. I then prepare a shipment that contains the books they ordered. If I don't have enough How copies do in stock, you I order additional even copies get and started? delay the shipment until the new copies arrive. I want to ship a customer's entire order together. My catalog includes all the books I sell. For each book, the catalog contains its ISBN number, title, author, purchase price, sales price, and the year the book was published. Most of my customers are regulars, and I have records with their s and addresses. New customers have to call me first and establish an account before they can use my website. On my new website, customers should first identify themselves by their unique customer identification number. Then they should be able to browse my catalog and to place orders online. CS/INFO 330 6 2
The Database Design Process Requirement analysis Conceptual design using the entityrelationship (ER) model Schema refinement Normalization Physical tuning CS/INFO 330 7 Overview of Database Design Conceptual design: (ER Model used at this stage) What are the entities and relationships in the enterprise? What information about these entities and relationships should we store in the database? What are the integrity constraints or business rules that hold? Database `schema in the ER Model can be represented pictorially (ER diagrams) Can map an ER diagram into a relational schema CS/INFO 330 8 ER Model Basics Entity: Real-world object distinguishable from other objects Described (in DB) using a set of attributes Entity set: Collection of similar entities E.g., all employees All entities in an entity set have the same set of attributes (until we consider ISA hierarchies) Each entity set has a key Each attribute has a domain CS/INFO 330 9 3
ER Model Basics (Contd.) Works_In d subordinate supervisor Relationship: Association among two or Reports_To more entities E.g., Attishoo works in Pharmacy department Relationship set: Collection of similar relationships An n-ary relationship set R relates n entity sets E1,,En; each relationship in R involves entities e1 E1,, en En Same entity set could participate in different relationship sets, or in different roles in same set CS/INFO 330 10 Key Constraints Consider Works_In Employee can work in many departments Dept can have many employees But: each dept has at most one manager Key constraint on Manages Manages d 1-to-1 1-to-Many Many-to-1 Many-to-Many CS/INFO 330 11 Key Constraints: Examples Example Scenario 1 Inventory database contains information about parts and manufacturers Each part is constructed by at most one manufacturer Example Scenario 2 Customer database contains information about customers and sales persons Each customer has at most one primary sales person What do the ER diagrams look like? CS/INFO 330 12 4
Participation Constraints Does every department have a manager? Participation constraint: the participation of in Manages is said to be total (vs. partial) d Manages Works_In CS/INFO 330 13 Participation Constraints: Examples Example Scenario 1 (Contd.) Each part is constructed by exactly one manufacturer Example Scenario 2 Each customer has exactly one primary sales person CS/INFO 330 14 Weak Entities Can be identified uniquely only by considering the primary key of another (owner) entity Owner entity set and weak entity set must participate in a one-to-many relationship set (one owner, many weak entities) Weak entity set must have total participation in this identifying relationship set cost Partial key p age Policy Dependents CS/INFO 330 15 5
ISA (`is a ) Hierarchies For modeling inheritance A ISA B: Every A entity is also a B entity Superclass (B) vs. subclass (A) Overlap constraints Can Joe be an Hourly_Emps as well as a Contract_Emps entity? (allowed/disallowed) hourly_wages hours_worked Covering constraints Does every entity also have to be an Hourly_Emps or a Contract_Emps entity? (yes/no) Hourly_Emps Reasons for using ISA To add descriptive attributes specific to a subclass. To identify entities that participate in a relationship ISA contractid Contract_Emps CS/INFO 330 16 Specifying Constraints Overlap constraints Default: no overlap Specify overlap explicitly: Contract_Emps OVERLAPS Hourly_Emps Covering constraints Default: no covering Specify coverage explicitly: Hourly_Emps AND Contract_Emps COVER employees hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps CS/INFO 330 17 Aggregation Used to express a relationship among relationships Allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships Example: employee monitors sponsorship Aggregation vs. ternary relationship Monitors is a distinct relationship with a descriptive attribute Can add constraint that each sponsorship is monitored by at most one employee pid Monitors until started_on d p Projects Sponsors CS/INFO 330 18 6
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? Constraints in the ER Model A of data semantics can (and should) be captured Some constraints cannot be captured in ER diagrams (What would be an example?) CS/INFO 330 19 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 ( 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 ( attribute values are atomic) CS/INFO 330 20 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 d Similar to the problem of wanting to record several addresses for an employee 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 to d CS/INFO 330 21 7
Entity vs. Relationship First ER diagram OK if a manager gets a separate discretionary for each dept. What if a manager gets a discretionary that covers all managed depts? Redundancy: d stored for each dept managed by manager Misleading: Suggests d associated with department-mgr combination ISA Managers d d Manages2 CS/INFO 330 22 Manages2 d d This fixes the problem. Binary vs. Ternary Relationships If each policy is owned by just one employee, and each dependent is tied to the covering policy, first diagram is inaccurate What are the additional constraints in the 2nd diagram? Bad design Covers p age Dependents CS/INFO 330 23 policyid cost Policies policyid cost p age Dependents Purchaser Better design Beneficiary Policies Binary vs. Ternary Relationships (Contd.) Previous example: Two binary relationships were better than one ternary relationship An example in the other direction A ternary relation Contracts relates entity sets Parts, 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? CS/INFO 330 24 8
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, attributes (of entities and relationships) Additional constructs: weak entities, ISA hierarchies, aggregation Note: There are many variations on the ER model. CS/INFO 330 25 Summary of ER (Contd.) Several kinds of integrity constraints can be expressed in the ER model Key constraints Participation constraints Overlap/covering constraints for ISA hierarchies Some foreign key constraints are implicit in the definition of a relationship set Some constraints cannot be expressed in the ER model Functional dependencies Constraints play an important role in determining the best database design for an enterprise CS/INFO 330 26 Summary of ER (Contd.) ER design is subjective Often many ways to model a given scenario Analyzing alternatives can be tricky, especially for a large enterprise Common design choices Entity vs. attribute Entity vs. relationship Binary or n-ary relationship Whether or not to use ISA hierarchies Whether or not to use aggregation Ensuring good database design Resulting relational schema should be analyzed and refined further Functional dependency information and normalization techniques especially useful CS/INFO 330 27 9