1. Database Design: Conceptual Modeling with ER Model CENG 351

2. Database Design Process Step 1: Conceptual database design – High level description of the data and the constraint – This step can use ER or similar high level models Step2: Logical database design – Convert database design into a database schema CREATE TABLE Employees (ssn CHAR(11), name CHAR(20), lot INTEGER, PRIMARY KEY (ssn)) CENG 351 lot dname budget did since name Works_In Departments Employees ssn

3. Database Design Process (cont.) Step3: Schema refinement Step 4: Physical database design – Data storage, indexing Step 5: Access Control – Identify which users can access which par of the data CENG 351

4. ER Model Basics: Entity set Entity: Real-world object distinguishable from other objects. – An entity is described (in DB) using a set of attributes. Entity Set: A collection of similar entities. E.g., all employees. – All entities in an entity set have the same set of attributes. – Each entity set has a key that uniquely identifies it. – Each attribute has a domain. – Entity set can be mapped to a relation easily. CENG 351 Employees ssn name lot

5. ER Model Basics: Relationship set Relationship: Association among 2 or more entities. E.g., Steve Jobs works in Grocery department. Relationship Set: Collection of similar relationships. Same entity set could participate in different relationship sets, or in different “roles” in the same set. CENG 351 lot dname budget did since name Works_In Departments Employees ssn Reports_To lot name Employees subor- dinate super- visor ssn

6. ER Model Basics: Relationship Set Relationship sets can also have descriptive attributes (e.g., the since attribute of Works_In). For a given entity pair we cannot have more than one associated descriptive attribute value. E.g.,., an employee-department pair can have one since attribute value. A relationship must be uniquely identified by the entities taking part. Thus, in translating a relationship set to a relation, attributes of the relation must include: – Keys for each participating entity set (as foreign keys):This set of attributes (individual keys) forms superkey for the new relation. – All descriptive attributes of the relationship. CENG 351

7. ER Model Basics: Relationship Set An instance of a relationship set is a set of relationships An example instance may have an employee working in none, one or many departments. Ternary Relationship: A relationship having three entities involved. – E.g., Works_In can have a Locations entity with possible attributes. taking part as well, where a department may have offices in different cites. CENG 351

8. Additional features One would need additional features for the ER diagrams to represent some important properties of entities and their relationships with other entities. Important features that can be shown on the ER diagrams: – Key constraints – Participation constraint – Weak entity – Class hierarchy concept – Aggregation concept CENG 351

9. Key Constraints Many-to-many Mapping: Consider Works_In relationship : An employee can work in many departments; a dept can have many employees One-to-many Mapping: Consider a Manages relationship between entities Employee and Departments. Each dept has at most one manager and each employee can manage more than one department (key constraint on Manages) The Key constraint is represented by an arrow as in the related diagram. CENG 351

10. Key Constraints CENG 351 dname budgetdid since lot name ssn Manages Employees Departments Departments have single manager, employee can manage more than one department!

11. Types of relationship sets CENG 351 Many-to-Many 1-to-1 (one-to-one) 1-to Many (one-to-many) Many-to-1 (Many-to-one)

12. Participation Constraints:Total vs. Partial If every department has a manager – then, this is a participation constraint constraint: the participation of Departments in Manages is said to be total (vs. partial). For total participation implementation in relations, every did value in the corresponding Departments table must appear in a row of the Manages table, with a non-null ssn value, reflecting the situation that every department has a manager. shown with bold line CENG 351

13. Participation constraints (cont.) Diagrammatic representation of key constraint and total participation CENG 351 lot name dname budgetdid name dname budgetdid since Manages Departments Employees ssn

14. Participation Constraints (cont.) Assume the case where each employee works in at least one department and that each department has at least one employee. The example ER diagram shows Manages and Works_In in the same diagram, with correct properties. CENG 351 lot name dname budgetdid since name dname budgetdid since Manages since Departments Employees ssn Works_In

15. Participation Constraints (cont.) Ensure total participation in the corresponding relationship tables is a problem! We have to guarantee that every did value in Departments appears in a tuple of Works_In at least once or possibly more… CENG 351

16. v Chapter 3-16 The (min,max) notation (1,1) (0,1) (1,N) (1,1)

17. Weak Entities Some entities do not have to have a key. It is possible that some entities are dependent on other entities. That is their existence depends on the others… This dependent entity is known as weak entity. A weak entity 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. A weak entity always has a partial key, it can only be uniquely defined if we take its key together with the key of the owner entity. CENG 351

18. Weak Entities (cont.) Assume an example of Employee and Dependents entities with a Policy relationship between tham. Employee is owner entity, Dependent is weak entity, Policy is the identifying relationship set: CENG 351 lot name age pname Dependents Employees ssn Policy cost

19. ISA (`is a’) Hierarchies CENG 351  Some time it is more appropriate to represent entities in an entity set into subclasses, where attributes can be inherited down the hierarchy.  As in object oriented programming tools, attributes are inherited.  If we declare A ISA B, every A entity is also considered to be a B entity.  As an example, consider a Employee entity as a super-class which has two subclasses as hourly and contract entities. In this case, the attributes of Employee should be inherited by the hourly and contract employee entities.

20. ISA (`is a’) Hierarchies Overlap constraints: Can Zeynep be an Hourly_Emps as well as a Contract_Emps entity? (posibility this is not to be allowed to be overlapped. However if had a sub-class such as Senior employee entitiy, that can be have OVERLAP with the sub-class Contract and or Hourly entities. ) Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (allowed using COVER). In some cases this may be required, in some other cases may not. These two issues need to be represented by the programming tool used to implement such properties. CENG 351 Contract_Emps name ssn Employees lot hourly_wages ISA Hourly_Emps contractid hours_worked Subclasses are defined first!

21. ISA (`is a’) Hierarchies Reasons for using ISA : – To add descriptive attributes specific to a subclass. – To identify the set of entities that participate in a particular relationship, e.g. only Senior Employees can be allowed to be Managers of Departments. CENG 351

22. Translating ISA Hierarchies to Relations General approach: – 3 relations: Employees, Hourly_Emps and Contract_Emps. Hourly_Emps: Every employee is recorded in Employees. For hourly emps, extra info recorded in Hourly_Emps (hourly_wages, hours_worked, ssn); must delete Hourly_Emps tuple if referenced Employees tuple is deleted). Queries involving all employees are easy, those involving just Hourly_Emps require a join to get some attributes. Overlap and covering constraints can only be expressed using assertions in case of SQL. CENG 351

23. Aggregation Building a relationship between a collection of entities and relationships Aggregation allows us to indicate a relationship set participate in another relationship set CENG 351

24. Aggregation Suppose: entity set Projects each Projects is sponsored by at least one Departments each Departments that sponsors a Projects might assign employees to monitor sponsorship CENG 351 budget did pid started_on pbudget dname Departments Projects Sponsors Employees lot name ssn since Intuitively…  Monitors should be a relationship set that associates a Sponsors relation (versus a Projects or Departments) with an Employees entity.

25. Aggregation Used when we have to model a relationship involving (entity sets and) a relationship set. Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships. CENG 351 budget did pid started_on pbudget dname until Departments Projects Sponsors Employees Monitors lot name ssn since

26. Aggregation vs. Ternary relation Each relationship in an aggregation may have a different descriptive attribute like since and until. Suppose: No need to record until attribute of Monitors CENG 351 budget did pid started_on pbudget dname Departments Projects Sponsors2 Employees lot name ssn since But suppose we have constraint that: Each sponsorship (of a project by a department) be monitored by at most one employee? Then… one can’t do it with Sponsors2  Need aggregated relationship Sponsors  Then… one can use ternary relationship Sponsors2

27. Aggregation vs. Ternary relation (Contd.) CENG 351  Monitors is a distinct relationship, with a descriptive attribute (until).  Also, can say that each sponsorship is monitored by at most one employee. budget did pid started_on pbudget dname until Departments Projects Sponsors Employees Monitors lot name ssn since

28. 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. – But some constraints cannot be captured in ER diagrams. Need for further refinement of the schema: – Relational schema obtained from ER diagram is a good first step. But ER design is subjective & can’t express certain constraints; so this relational schema may need refinement. CENG 351

29. Entity vs. Attribute Should address be an attribute of Employees or an entity (connected to Employees by a relationship)? Depending upon the purpose 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). CENG 351

30. Entity vs. Attribute (Contd.) According to the conceptual ER model, Works_In2 does not allow an employee to work in a department for two or more periods. CENG 351 name Employees ssn lot Works_In2 from to dname budget did Departments  But we want several values of the descriptive attributes for each instance of this relationship.

31. Entity vs. Attribute (Contd.) In this case, use Duration entity to allow more than one duration per relationship… CENG 351 dname budget did name Departments ssn lot Employees Works_In3 Duration from to

32. Entity vs. Relationship Following ER diagram OK if a manager gets a separate discretionary budget for each dept. CENG 351 Manages2 name dname budget did Employees Departments ssn lot dbudget since

33. Entity vs. Relationship What if a manager gets a discretionary budget which is the sum that covers all depts managed by that employee? Then the previous ER diagram will cause – Redundancy of dbudget, where the same value is stored for each dept managed by the same manager. – Misleading as it suggests dbudget tied to managed dept rather than employee. Instead a separate entity Mgr_Appts can be used with apptnum as key. This way the redundancy is eliminated! CENG 351

34. Entity vs. Relationship CENG 351 Employees since name dname budget did Departments ssn lot Mgr_Appts Manages3 dbudget apptnum

35. Binary vs. Ternary Relationships If each policy is owned by just 1 employee: – Key constraint on Policies would mean policy can only cover 1 dependent! Every policy must be owned by some employee Dependents is a weak entity set Thus, this can be represented as follows: This ternary relationship is a poor or inappropriate design! CENG 351 age pname Dependents Covers name Employees ssn lot Policies policyid cost

36. Binary vs. Ternary Relationships(cont.) Are statement of the same application with more clarity: – A policy cannot be owned by more than one employee, every policy must be owned by some employee (total participation) and – Every policy must cover at least one dependent, dependent is a weak entity set. Use a Beneficiary relationship which is an identifying relationship for the weak entity Dependents, ie. where each dependent will have one policy only… CENG 351

37. Binary vs. Ternary Relationships (cont.) CENG 351 Beneficiary age pname Dependents policyid cost Policies Purchaser name Employees ssn lot Better design With two binary relationships

38. Binary vs. Ternary Relationships (Cont.) The key constraints allow us to combine Purchaser with Policies and Beneficiary with Dependents. Participation constraints lead to NOT NULL constraints. This example illustrated a case when 2 binary relationships were better than a ternary relationship. It is also possible that ternary relationship is more suitable than binary, in some cases: CENG 351

39. 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. CENG 351

40. 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 of these constraints can be expressed in SQL. – 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. CENG 351

41. 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. CENG 351

42. Relationship Set  The current “value” of an entity set is the set of entities that belong to it. Example: the set of all books in our database.  The “value” of a relationship is a set of lists of currently related entities, one from each of the related entity sets. CENG 351

43. Some of the Automated Database Design Tools COMPANYTOOLFUNCTIONALITY Embarcadero Technologies ER StudioDatabase Modeling in ER and IDEF1X DB ArtisanDatabase administration and space and security management OracleDeveloper 2000 and Designer 2000 Database modeling, application development Popkin SoftwareSystem Architect 2001Data modeling, object modeling, process modeling, structured analysis/design Platinum TechnologyPlatinum Enterprice Modeling Suite: Erwin, BPWin, Paradigm Plus Data, process, and business component modeling Persistence Inc.PwertierMapping from O-O to relational model RationalRational RoseModeling in UML and application generation in C++ and JAVA Rogue WareRW MetroMapping from O-O to relational model Resolution Ltd.XcaseConceptual modeling up to code maintenance SybaseEnterprise Application SuiteData modeling, business logic modeling VisioVisio EnterpriseData modeling, design and reengineering Visual Basic and Visual C++

44. Examples A University database contains information about professors (identified by social security number, or SSN) and courses (identified by courseid). Professors teach courses. Each of the following situations concerns the Teaches relationship set. For each situation, draw an ER diagram that describes it (assuming that no further constraints hold). CENG 351

45. Examples (cont’) 1.Professors can teach the same course in several semesters, and each offering must be recorded. 2.Professors can teach the same course in several semesters, and only the most recent such offering needs to be recorded. (Assume this condition applies to all subsequent questions.) 3.Every professor must teach some course 4.Every professor teaches exactly one course (no more, no less). 5.Every professor teaches exactly one course (no more no less), and every course must be taught by some professor. 6.Now assume that certain courses can be taught by a team of professors jointly, but it is possible that no one professor in a team can teach the course. Model this situation introducing additional entity sets and relationship sets if necessary. CENG 351

46. Example (cont’) 1)Professors can teach the same course in several semesters, and each offering must be recorded. CENG 351

47. Example (cont’) 2)Professors can teach the same course in several semesters, and only the most recent such offering needs to be recorded. (Assume this condition applies to all subsequent questions.) CENG 351

48. Example (cont’) 3)Every professor must teach some course CENG 351

49. Example (cont’) 4)Every professor teaches exactly one course (no more, no less). CENG 351

50. Example (cont’) 5)Every professor teaches exactly one course (no more no less), and every course must be taught by some professor. CENG 351

51. Example (cont’) 6)Now assume that certain courses can be taught by a team of professors jointly, but no one professor in a team can teach the course alone. Model this situation introducing additional entity sets and relationship sets if necessary. CENG 351

53. Example A company database needs to store information about employees (identified by ssn, with salary and phone as attributes); departments (identified by dno, with dname and budget as attributes); and children of employees (with name and age as attributes). Employees work in departments; each department must be managed by an employee; a child must be identified uniquely by name when the parent (who is an employee; assume that only one parent works for the company) is known. We are not interested in information about a child once the parent leaves the company. CENG 351

55. ER DIAGRAM FOR A BANK DATABASE v © The Benjamin/Cummings Publishing Company, Inc. 1994, Elmasri/Navathe, Fundamentals of Database Systems, Second Edition