Modeling Your Data Chapter 2 cs542 The slides for this text are organized into chapters. This lecture covers Chapter 2. Chapter 1: Introduction to Database Systems Chapter 2: The Entity-Relationship Model Chapter 3: The Relational Model Chapter 4 (Part A): Relational Algebra Chapter 4 (Part B): Relational Calculus Chapter 5: SQL: Queries, Programming, Triggers Chapter 6: Query-by-Example (QBE) Chapter 7: Storing Data: Disks and Files Chapter 8: File Organizations and Indexing Chapter 9: Tree-Structured Indexing Chapter 10: Hash-Based Indexing Chapter 11: External Sorting Chapter 12 (Part A): Evaluation of Relational Operators Chapter 12 (Part B): Evaluation of Relational Operators: Other Techniques Chapter 13: Introduction to Query Optimization Chapter 14: A Typical Relational Optimizer Chapter 15: Schema Refinement and Normal Forms Chapter 16 (Part A): Physical Database Design Chapter 16 (Part B): Database Tuning Chapter 17: Security Chapter 18: Transaction Management Overview Chapter 19: Concurrency Control Chapter 20: Crash Recovery Chapter 21: Parallel and Distributed Databases Chapter 22: Internet Databases Chapter 23: Decision Support Chapter 24: Data Mining Chapter 25: Object-Database Systems Chapter 26: Spatial Data Management Chapter 27: Deductive Databases Chapter 28: Additional Topics cs542 1

Discussion of the Model: Good Design/ Bad Design Part II Discussion of the Model: Good Design/ Bad Design cs542

Design : The Obvious Use meaningful and descriptive names (it’s for the human after all) Keep as simple as possible Avoid redundant constructs Express all constraints, if possible, as then DBMS will help enforce them cs542 3

Conceptual Design Using 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 lot of data semantics can (and should) be captured. Some constraints cannot be captured in ER diagrams. cs542 3

Entity vs. Attribute Should address be an attribute of Employees or an entity (connected to Employees by a relationship)? cs542

Entity vs. Attribute Should address be an attribute of Employees or a related entity ? Answer: Depends upon how we want to use address information and its semantics : If we have several addresses per employee, address must be an entity (since attributes cannot be set-valued). 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). cs542

Entity vs. Attribute Reminder : Do not introduce un-necessary entities (and complexity) if not needed for your application ! cs542

Entity vs. Attribute from to name Employees ssn lot dname did budget Works_In4 Departments cs542 5

Entity vs. Attribute Does Works_In allow an employee to work in a department for two or more periods??? from to name Employees ssn lot dname did budget Works_In Departments cs542 5

Entity vs. Attribute (Contd.) Works_In does not allow an employee to work in a department for two or more periods à no multi-valued attributes in ER ! from to name Employees ssn lot dname did budget Works_In Departments cs542 5

Entity vs. Attribute (Contd.) Works_In4 does not allow an employee to work in a department for two or more periods. from to name Employees ssn lot dname did budget Works_In4 Departments What do ? 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. cs542 5

Entity vs. Attribute from to name Employees ssn lot dname did budget Works_In4 Departments name dname budget did ssn lot Employees Works_In4 Departments Duration from to cs542 5

Entity vs. Relationship? since dbudget name dname ssn lot did budget Employees Manages2 Departments cs542 6

Entity vs. Relationship since dbudget name dname ssn lot did budget Employees Manages2 Departments What if a manager gets a separate discretionary budget for each dept ? OK ! cs542 6

Entity vs. Relationship since dbudget name dname ssn lot did budget Employees Manages2 Departments What if a manager gets a discretionary budget that covers all managed depts? Redundancy: dbudget stored for each dept managed by manager. Misleading: Suggests dbudget associated with department-mgr combination. cs542 6

Entity vs. Relationship since dbudget Discretionary budget of manager that covers all managed depts? name dname ssn lot did budget Employees Manages2 Departments name ssn lot since dname Employees did budget Manages2 Departments ISA Managers dbudget cs542 6

Binary vs. Ternary Relationships name Employees ssn lot pname age Covers Dependents Policies policyid cost cs542 7

Binary vs. Ternary Relationships name Employees ssn lot pname age Covers Dependents Policies policyid cost What if each policy is owned by just 1 employee? What if each dependent should be tied to only 1 covering policy? cs542 7

Binary vs. Ternary Relationships age pname Dependents Covers name Employees ssn lot Policies policyid cost Bad design! name Employees ssn lot pname age Dependents What additional constraints in 2nd diagram? Purchaser Beneficiary policyid cost Policies Better design? cs542 7

Binary vs. Ternary Relationships name Employees ssn lot pname age Covers Dependents Bad design Policies policyid cost name Employees ssn lot pname age Dependents Purchaser Beneficiary Even Better Design policyid cost Policies cs542 7

Binary vs. Ternary Relationships Previous example illustrated when two binary relationships better than one ternary relationship. New Example: How about we want to model Contracts between the entity sets Parts, Departments and Suppliers, Where D has agreed to buy parts P from supplier S according to a given contract (i.e. a certain quantity of parts of type P). 9

Binary vs. Ternary Relationships How about ternary relation Contracts : entity sets Parts, Departments and Suppliers, and has descriptive attribute qty. qty sid pnum Suppliers contract Parts Department did 9

Binary vs. Ternary Relationships What about following binary relationships : S “can-supply” P, D “needs” P, and D “deals-with” S ? No combination of binary relationships is an adequate substitute: Together 3 binary relationships don’t imply that D has agreed to buy P from S. Also, how could we record qty? cs542 9

Summary of ER There are often many ways to model a given scenario! Not one correct ER design 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, aggregation. Ensuring good database design: Resulting relational schema should be analyzed and refined further. FD information and normalization techniques useful. cs542 13