CMPT 258 Database Systems The Entity-Relationship Model Part II (Chapter 2)

Change of Office Hours Monday, Thursday 5:30 – 6:30 PM Wednesday 3:30 – 4:30 PM

When: Tuesday, September 22 3:30PM Where: RLC 105 Team based: one, two or three people per team Languages: C/C++ and Java IDEs: Visual Studio, Eclipse, NetBeans Event Schedule 3:30 – 5:30 pm – Contest 5:30 pm – Award Ceremony 5:30 pm – Pizza Party Register your team online or in RLC 203 (Find the registration list on the bulletin board) Contact Dr. Tina Tian for questions.

ISA (‘is a’) Hierarchies As in C++, or other PLs, attributes are inherited. If we declare A ISA B, every A entity is also considered to be a B entity. Employees is specialized into subclasses Hourly-Emp and Contract_EMps are generalized by Employees

ISA (‘is a’) Hierarchies Hourly-Emp and Contract_EMps are generalized by Employees name ssn Employees lot Contract_Emps hourly_wages ISA Hourly_Emps contractid hours_worked

ISA (‘is a’) Hierarchies Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? (Allowed/disallowed) Covering constraints: – Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (Yes/no).

ISA (‘is a’) Hierarchies Overlap constraints: ▫ The subclasses must have disjoint or overlapping sets of entities Disjoint(d) Overlap (0)

ISA (‘is a’) Hierarchies Covering constraints (completeness constraints): ▫ An entity may not belong to any of the subclasses ▫ Every entity in the superclass must be a member of some subclass Partial Total

ISA (‘is a’) Hierarchies Multiple specializations

ISA (‘is a’) Hierarchies Reasons for using ISA: – To add descriptive attributes specific to a subclass. – i.e. not appropriate for all entities in the superclass – To identify entities that participate in a relationship.  i.e., not all superclass entities participate

Aggregation Suppose that we have an entity set called Projects and that each Projects entity is sponsored by one or more departments. A department that sponsors a project might assign employees to monitor the sponsorship. budget did pid started_on pbudget dname Departments Projects Sponsors since N M

Aggregation Used to model a relationship between a collection of entities and relationships. Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships. budget did pid started_on pbudget dname until Departments Projects Sponsors Employees Monitors lot name ssn since

Aggregation Aggregation vs. ternary relationship: why not make Sponsors a ternary relationship? There are really two distinct relationships (monitors and sponsors), each with attribute of its own. Monitors is a distinct relationship, with a descriptive attribute. budget did pid started_on pbudget dname until Departments Projects Sponsors Employees Monitors lot name ssn since

Ternary Relationship Suppose that each department has offices in several locations and we want to record the locations at which each employee works.

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 lot of data semantics can (and should) be captured.

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

Entity vs. Attribute 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 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). Employees ssn name address

Entity vs. Attribute 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). street citya# name ssn Lives_inEmployees addresses

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

Entity vs. Attribute 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. name Employees ssn lot Works_In4 from to dname budget did Departments

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

Entity vs. Relationship Scenario 1: a manager gets a separate discretionary budget for each department. Scenario 2: What if a manager gets a discretionary budget (sum) that covers all managed departments? Manages2 name dname budget did Employees Departments ssn lot dbudget since

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

Entity vs. Relationship This fixes the problem! dname budget did Departments Manages2 Employees name ssn lot since Managersdbudget ISA

Binary vs. Ternary Relationships An example of ternary relationship : ▫a ternary relation Contracts relates entity sets Parts, Departments and Suppliers, and has descriptive attribute qty. Suppliers qty Departments Contract Parts

Binary vs. Ternary Relationships 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? Suppliers qty Departments Contract Parts Suppliers Departments deals-with Parts can-supply needs VS.

Summary of Conceptual Design Conceptual design follows requirements analysis ER model popular for conceptual design ▫Constructs are expressive, close to the way people think about their applications. ▫There are many variations on ER model (both graphically and conceptually) Basic constructs ▫entities, relationships, and attributes (of entities and relationships) Some additional constructs ▫weak entities, ISA hierarchies, and aggregation

Summary of Conceptual Design Several kinds of integrity constraints: ▫key constraints ▫participation constraints ▫overlap/covering for ISA hierarchies. Constraints play an important role in determining the best database design for an enterprise.

Summary of Conceptual Design 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 (functional dependency) information and normalization techniques are especially useful.

Homework 1 Cover page with name and homework number Hard copy preferred Due Sep 24 (Thur) before class

Readings Chapter 3