LECTURE 1: Entity Relationship MODEL

Transcription

1 LECTURE 1: Entity Relationship MODEL

2 Think before doing it! Like most of the software projects, you need to think before you do something. Before developing your database application, you need to collect the requirements, and build a conceptual model. ER model is a widely accepted standard for conceptual DB design.

3 AN Entity Relationship (ER) Diagram Looks Like This ssn lot cost p age Employees Policy Dependents

4 ER Model Key concepts of ER model Entities Relationships Entity: Is an object that exists and that can be distinguished from other objects Hümeyra CS306 Ulak

5 ER Model Entity Has attributes that describe it address id

6 ER Model Entity set: Is the set of entities that share the same properties Instructors Y. Saygın H. Yenigün Courses CS306 MATH204 A.Levi E. Savaş CS308

7 ER Model Entity sets may overlap Example? Employees Managers

8 ER Model Relationships: Relate two or more entities (such as Ali is enrolled in CS306)

9 ER Model Relationships: Relate two or more entities (such as Serafettin is enrolled in CS306) Relationship sets: Collection of all relationship sets with the same properties (all student enrollments) Relationships may also have attributes

10 ER Model sid student Rectangles : Entity sets Ellipses : attributes

11 ER Model c sid student Course cid Rectangles : Entity sets Ellipses : attributes

12 ER Model c sid student Enrolled Course cid Rectangles : Entity sets Diamonds : Relationship Sets Ellipses : attributes

13 ER Model Each entity set has attributes Each attribute has a domain (domain is the set of permitted values) sid student

14 ER Model Each entity set has attributes Each attribute has a domain (domain is the set of permitted values) Each entity set has a key Keys are denoted by underlining the attribute in the ER diagram sid student

15 ER Model c sid student Enrolled Course cid Relationship sets also have attributes

16 ER Model semester c sid student Enrolled Course cid Relationship sets also have attributes We are going to talk about the key in a relationship set later on

17 ER Model semester c sid student Enrolled Course cid Degree of a relationship set is the number of entity sets that participate in a relationship Binary relationship sets involve two entity sets

18 ER Model Ternary relationship sets involve three entity sets customer borrows branch loan

19 ER Model We may have relationships among the entities that belong to the same entity set each entity has a role in such a relationship sid student students helps

20 ER Model We may have relationships among the entities that belong to the same entity set each entity has a role in such a relationship sid student tutor tutee helps

21 ER Model We may have relationships among the entities that belong to the same entity set (each entity has a role in such a relationship) What is the degree of the following relationship set (2 or 1)? sid student tutor tutee helps

22 ER Model eid employer e

23 ER Model eid employer e Reports_to

24 ER Model eid employer e supervisor Reports_to

25 ER Model eid employer e supervisor subordinate Reports_to

26 ER Model Ternary relationship sets customer branch loan

27 ER Model Ternary relationship sets customer borrows branch loan

28 Mapping cardinalities One-to-One relationship (ex: marriage relationship set between husbands and wives) 1-to-1

29 Mapping cardinalities One-to-One (ex: marriage relationship set between husbands and wifes) One-to-Many (example?) 1-to-1 1-to Many

30 Mapping cardinalities One-to-One (ex: marriage relationship set between husbands and wifes) One-to-Many Many-to-One 1-to-1 1-to Many Many-to-1

31 Mapping cardinalities One-to-One (ex: marriage relationship set between husbands and wifes) One-to-Many Many-to-One Many-to-Many 1-to-1 1-to Many Many-to-1 Many-to-Many

32 Consider the works_in relationship If an employee can work in multiple departments and a department can have multiple employees ssn Employees lot since Works_In did d budget Departments What type of relationship is that? 1-to-1 1-to Many Many-to-1 Many-to-Many

33 Consider the manages relationship If an employee can manage multiple departments but a department has only one manager ssn Employees lot since Manages did d budget Departments What type of relationship is that? This is called a key constraint (denoted with an arrow) 1-to-1 1-to Many Many-to-1 Many-to-Many

34 Participation Constraints If every department MUST have a manager, then there is a participation constraint The participation of Departments in Manages is total (otherwise it is partial). since d ssn lot did budget Employees Manages Departments Works_In since

35 Participation Constraints If every department MUST have a manager, then there is a participation constraint The participation of Departments in Manages is total (otherwise it is partial). Participation constraints are denoted with a thick line (for example each department must participate in the manages relationship, therefore this is denoted with a thick line in the relationship) since d ssn lot did budget Employees Manages Departments Works_In since

36 Participation Constraints If every employee MUST work in a department, then there is a participation constraint on employee entity set ssn lot since did d budget Employees Manages Departments Works_In since

37 Participation Constraints Plus, if every department MUST have employee(s) working in that department, then there is a participation constraint on department entity set ssn lot since did d budget Employees Manages Departments Works_In since

38 ISA (`is a ) Hierarchies ssn Employees lot hourly_wages hours_worked contractid Hourly_Emps Contract_Emps

39 ISA (`is a ) Hierarchies ssn Employees lot hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps

40 ISA (`is a ) Hierarchies ssn Employees lot hourly_wages hours_worked ISA contractid Hourly_Emps Contract_Emps Overlap constraints: Can Serafettin be an Hourly Employee as well as a Contract Employee? Covering constraints: Does every Employee also have to be an Hourly Employee or a Contract Employee? Reasons for using ISA: To add descriptive attributes specific to a subclass. To identify entities that participate in a relationship. Specialization vs. generalization

41 Weak Entities A weak entity can be identified uniquely only by considering the primary key of another (owner) entity. ssn lot cost p age Employees Policy Dependents

42 Weak Entities A weak entity can be identified uniquely only by considering the primary key of another (owner) entity. A weak entity set is denoted by a rectangle with thick lines ssn lot cost p age Employees Policy Dependents

43 Weak Entities A weak entity can be identified uniquely only by considering the primary key of another (owner) entity. A weak entity set is denoted by a rectangle with thick lines The relationship between a week entity and the owner entity is denoted by a diamond with thick lines. ssn lot cost p age Employees Policy Dependents

44 Weak Entities A weak entity can be identified uniquely only by considering the primary key of another (owner) entity. What can you say about the constraints on the indentifying relationship? (i.e., participation and key constraints) ssn lot cost p age Employees Policy Dependents

45 Weak Entities 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-tomany relationship set (one owner, many weak entities). Weak entity set must have total participation in this identifying relationship set. ssn lot cost p age Employees Policy Dependents

46 ssn lot Aggregation Employees Used when we have to model a relationship involving (entitity sets and) a relationship set. Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships. pid started_on Projects Monitors pbudget since Sponsors did until d Departments * Aggregation vs. ternary relationship: Monitors is a distinct relationship, with a descriptive attribute. budget Also, can say that each sponsorship is monitored by at most one employee.

47 Example: Draw the ER diagram for the following specifications: There are conferences, universities, and professors. Conferences have s (such as VLDB, ICDE, SIGMOD), and years they are organized. A conference can be organized in different years but a conference can not be organized more than once in a certain year. For example SIGMOD is organized in 2001, 2002, etc, but SIGMOD can not be organized twice in 2001.Universities have s and cities they are located, such as Sabanci Universiy located in Istanbul. Each conference at a specific year is organized by one university, but a university can organize many conferences. Each conference organized at a specific year has a list of PC (Program Committee) members which consists of professors associated with universities. Professors have s and SSNs. A professor is associated with one university, but a university may have many professors.

48 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.

49 Entity vs. Attribute Should address be an attribute of Employees or an entity (connected to Employees 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 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).

50 Entity vs. Attribute (Contd.) ssn lot from to did d budget Works_In2 does not allow an employee to work in a department for two or more periods. 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. Employees ssn Employees lot from Works_In2 Works_In3 Duration did Departments to d budget Departments

51 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! ssn lot Employees Bad design ssn Employees p age Covers Dependents Policies policyid cost p age lot Dependents Purchaser Beneficiary Better design Policies policyid cost

52 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 depts? Redundancy of dbudget, which is stored for each dept managed by the manager. Misleading: suggests dbudget tied to managed dept. ssn Employees ssn Employees since dbudget lot did Manages2 lot did Manages3 d budget Departments d budget Departments apptnum Mgr_Appts since dbudget

53 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.

54 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.

55 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.

56 First Step of the project Form your group Choose your application (among the list in webct or the application you chose) Find an acronym for your project thinking the application in mind Write a max 1 page description for your project. Submit the project description through webct And the first step of your project is done (1% of your overall grade, due Feb 27)

57 Second Step of the project Think about the requirements of your application Write down a list of entities of your application Draw the ER diagram Write down the constraints (key constraints, participation constraints etc) Submit your work through sucourse Second step of your project is done (1% of the overall grade, due 8th of March)

58 Banks Database in Turkey (as ALS, siftah) You are asked to design a database of banks in Turkey. Now Lets think about the requirements What are the entities in our database? What are their attributes? Draw the ER diagram!