Entity-Relationship Model. Dr. Samaresh Mishra, School of Computer Engineering, KIIT University, Bhubaneswar

Size: px

Start display at page:

Download "Entity-Relationship Model. Dr. Samaresh Mishra, School of Computer Engineering, KIIT University, Bhubaneswar"

Roberta Kelley
5 years ago
Views:

1 Entity-Relationship Model Dr. Samaresh Mishra, School of Computer Engineering, KIIT University, Bhubaneswar

2 Conceptual data modelling motivation, Entities, Entity types, Various types of attributes, Relationships, Relationship types, E/R diagram notation, Extended E/R Model, Examples.

3 To be discussed!!! Entity Sets Relationship Sets Mapping Constraints Keys E-R Diagram Extended E-R Features Design of an E-R Database Schema Reduction of an E-R Schema to Tables

4 An entity is an object of interest to the end user. e.g. a person, a place, a thing or an event Entities are described in the database by a set of attributes. e.g. the name and address of a person. An entity set (type) is a set of entities of the same type that share the same properties or attributes. e.g. set of all persons, companies, trees, holidays

5 Domain A domain can be either explicit (e.g. gender)or implicit (e.g. salary). Association (relationship) STUDENTS enroll in COURSE SUPPLIERS supply PARTS SALESPERSON processes ORDER Entity type Base entity type; Weak entity type

6 Entity set can be abstract or concrete. Set of Holidays (Abstract) Set of students (Concrete) A relationship is an association among several entities. The ER data model is based on the perception of real world that consists of a collection of entities and the relationships among entities.

7 The ER model includes: I. ER diagram (ERD) portraying entity sets, attributes for each entity set, and relationships among entity sets. II. Semantic integrity constraints that reflect the business rules about data not captured in the ER diagram.

8 Summary of Presentation Layer ER diagram notation

9 Attribute Atomic or Simple (e.g. salary) Composite or Molecular (e.g. dob) Stored or Derived(e.g. Age) Single-valued Multi-valued (e.g. skill) Mandatory (value must be assigned) Optional (value need not be assigned, e.g. NULL) Complex (composite and/or multivalued attributes that are nested as meaningful cluster)

10 Pat_No F_Name M_Int Pat_Prefix L_Name Pat_ID Pat_Name Date_of_Birth SSN PATIENT Address Phone Age Medical Profile Blood Height Weight Allergy Type Sugar HDL LDL Triglyceride Cholesterol Code Name Intensity Figure 2.3 A graphical representation of an entity type PATIENT

11 Note : various attribute characteristics in PATIENT: Optional simple/atomic: Date_of_ birth, Address Optional multi-valued: Phone Optional simple/atomic derived: Age Mandatory composite: Pat_Name, Pat_ID Mandatory simple/atomic that serves as a unique identifier: SSN Mandatory composite that serves as a unique identifier: Pat_ID Complex: Medical Profile

12 Example: Attributes Entity Set Relationship Set

13 Different Type of Attributes and Entities Roll_no Simple/single Attribute DD MM YYYY employee Strong Entity set DOB Composite Attribute Skill Multivalued Attribute dependants Weak Entity set Derived Attribute

14 E1 m n R Cardinality Ratio of m:n E2 Chen's Notation E1 R E2 Cardinality Ratio of m:n Crow's Foot Notation E1 R E2 E1 Optionally Related To E2 (Partial Participation of E1 in R) E2 Mandatorily Related to E1 (Total Participation of E2 in R) [Existence Dependency of E2 in R] Inclusive Arc Noninclusive Arc Exclusive Arc Summary of Presentation Layer ER diagram notation

15 List all discernable data elements and treat them as attributes Group these attributes based on apparent commonalities Designate each cluster of attributes as an entity type Review leftover data elements and investigate the possibility that some of them serve as links among the entity types previously identified Designate these links as relationship types

16 Begin by searching for things that can be labeled by singular nouns and call these things entity types Gather properties that appear to belong to individual entity types and label them as attributes of a particular entity type Be sensitive throughout the process to the identification of relationships among the various entity types

18 Employees works in these plants and each employee works in only one plant. Every plant is managed by an employee who works in the same plant; but every employee is not a plant manager nor can an employee manage more than one plant. Company policy dictates that every plant must have a manager. Some employees are assigned to work on projects and in some cases might even be assigned to work on several projects simultaneously. For a project to exist, it must have at least one employee assigned to it. Projects might need several employees depending on their size and scope.

20 A super key of an entity set is a set of one or more attributes whose values uniquely determine each entity. A candidate key of an entity set is a minimal super key Customer-id is candidate key of customer account-number is candidate key of account Although several candidate keys may exist, one of the candidate keys is selected to be the primary key by the database designer.

21 Lname Minit Fname Name Name_tag Address Salary n Works_in 1 Pl_name Pnumber employer Building Emp# worker No_of_employees Gender Date_hired EMPLOYEE manager Mgr_start_dt PLANT Budget No_of_dependents 1 Managed_by managed by 1 1 Responsible Supervisee Assignee Undertaken_by Holder of Supervisor Hours n Controlled 1 Supervised_by 20 n Having 1 m Assigned n Assignment PROJECT Plocation Pr_name 1 Dependent_of Pnumber Held_by_E m Dname Related_how n Depends_on Dependent DEPENDENT Belongs to Participant Birthdate Gender Account Holder 1 Held_by_D m Participates Annual_cost n Account of Hb_name n Usage Hrs_per_wk Account_id BANK BCU_ACCOUNT HOBBY Gi_activity Acct_type Account# Io_activity Balance Figure 3.3 Presentation Layer ER diagram for Bearcat, Incorporated

22 Various Structural Constraint Notations more precise and expressive

23 Explanation participation cardinality ration The pair of finite whole numbers (min, max) is used with each participation of an entity type E in a relationship type R without any reference to other entity types participating in the relationship R where 0 min max and max > 0. The meaning is conveyed here is that each entity e in E participates in at least min and at most max relationships (r 1, r 2, ) in R. In this notation, min = 0 implies partial or optional participation of E in R, and min 1 implies total or mandatory participation of E in R. An employee participates in at least 0 (min=0) (optional participation) and at most m (max=m) Held_by_E relationships, meaning that an employee need not have a BCU account, but may have many BCU accounts. Similarly a BCU account need not belongs to any employee, but can belong to a maximum of one employee.

24 Lname Minit Fname Name Name_tag Address (1, 1) Salary Works_in (100, n) Pl_name Pnumber Building Emp# Gender Date_hired EMPLOYEE (0,1) Mgr_start_dt No_of_employees (1,1) PLANT Budget No_of_dependents Managed_by (0,n) (0,m) (0, 20) (0, 1) (0, n) (0, n) Hours Undertaken_by (1,1) Plocation Supervised_by Assigned (1, m) PROJECT Pr_name Dependent_of Pnumber Held_by_E Dname Related_how (1, 1) Transformed from the Chen s (look across) notation to [min, max] (look here) notation Dependent DEPENDENT (0,1) Birthdate (0, n) Gender (0, n) Annual_cost Held_by_D Participates (0,1) Hb_name (0,m) Hrs_per_wk Account_id BCU_ACCOUNT HOBBY Gi_activity Acct_type Account# Io_activity Balance Figure 3.5 Course-granular Design-Specific ER diagram for Bearcat, Incorporated - Stage 1

25 Deletion Constraints (continued) Set Null Rule (N): If a parent entity in a relationship is deleted and if all child entities related to this parent in this relationship should be retained but no longer referenced to this parent, the set null rule applies. Set Default Rule (D): If a parent entity in a relationship is deleted and if all child entities related to this parent in this relationship should be retained but no longer referenced to this parent but should be referenced to a predefined default parent, the set default rule applies.

26 The Four Deletion Rules Deletion Rule Examples FACULTY FACULTY R prohibits the deletion of Faculty member serving as dissertation chair of one or more students. R (0,n) Diss_chair (1,1) (0,n) Diss_chair (1,1) C C implies that deletion of a faculty members leads to the deletion of all students for whom the faculty member serves as dissertation chair. STUDENT STUDENT The Restrict Rule The Cascade Rule When a parent entity in a relationship is deleted, if all child entities related to this parent in this relationship should not be deleted, then the deletion of the parent should be restricted. When a parent entity in a relationship is deleted, if all child entities related to this parent should be deleted, then the cascade rule applies. N allows a student to exist without a dissertation chair by simply nullifying the relationship of students with the faculty m embers, should the faculty member be deleted. FACULTY (0,n) Diss_chair (1,1) (0,1) N STUDENT FACULTY (0,n) Diss_chair (1,1) D STUDENT D is somewhat similar to N. instead of nullifying the relationship, a student is linked to a predetermined (default) dissertation chair, should the student s current dissertation chair be deleted. The Set Null Rule The Set Default Rule When a parent entity in a relationship is deleted, if all child entities related to this parent in this relationship should be retained but no longer referenced to this parent, the set null rule applies. When a parent entity in a relationship is deleted, if all child entities related to this parent in this relationship should be retained but no longer referenced to this parent, but should be referenced to a predefined default parent, the set default rule applies.

27 Representing Deletion Constraints Using Deletion Rules Lname Minit Fname Name Name_tag Address (1, 1) Salary Works_in Pl_name Pnumber (100, n) Building Emp# R Gender Date_hired EMPLOYEE D R R N (0,1) Mgr_start_dt No_of_employees (1,1) PLANT Budget No_of_dependents Managed_by (0,n) (0,m) (0, 20) (0, 1) (0, n) (0, n) Hours Undertaken_by (1,1) N Plocation Supervised_by Assigned C (1, m) PROJECT Pr_name Dependent_of Pnumber Held_by_E Dname Dependent Related_how (1, 1) C 1. deletion rule on undertaken_by conflicts with the participation constraint of PROJECT 2. Contradicting deletion rules on DEPENDENT DEPENDENT R (0,1) Birthdate (1, n) Gender (0, n) C Annual_cost Held_by_D Participates (0,1) Hb_name (0,m) R Hrs_per_wk Account_id C BCU_ACCOUNT Balance HOBBY Gi_activity Acct_type Account# Io_activity Figure 3.7 Course-granular Design-Specific ER diagram for Bearcat, Incorporated - Stage 2 {deletion constraints added}

28 A plant with employee can not be deleted Lname Minit Fname Name Name_tag Address (1, 1) Salary Works_in Pl_name Pnumber (100, n) Building Emp# R The HR department uses a designated default employee number to replace a supervisor who leaves the company. Gender Date_hired No_of_dependents (0,m) Held_by_E Dname EMPLOYEE (0, 20) Dependent D (0, 1) Supervised_by Related_how R R (0, n) N Dependent_of (1, 1) C (0,1) (0, n) Mgr_start_dt Managed_by Hours Assigned C No_of_employees (1,1) (1, m) Pnumber PLANT (0,n) Undertaken_by (1,1) PROJECT Budget Plocation 1. deletion rule on undertaken_by conflicts with the participation constraint of PROJECT 2. Contradicting deletion rules on DEPENDENT N Pr_name If a plat is closed down, the projects undertaken by that plant cannot be cancelled. The project assignments from a closed plant must be temporarily removed in order to allow the project to be transferred to another plant. DEPENDENT R (0,1) Birthdate (1, n) Gender (0, n) C Annual_cost If an employee is deleted, all BCU accounts of that particular employee must be deleted. Account_id C Held_by_D (0,1) BCU_ACCOUNT Balance Hb_name Participates (0,m) R HOBBY Hrs_per_wk Gi_activity Acct_type Account# Io_activity Figure 3.7 Course-granular Design-Specific ER diagram for Bearcat, Incorporated - Stage 2 {deletion constraints added}

29 An employee currently managing a plant can not be deleted from the database. Lname Name_tag Minit Address Fname Name Emp# Gender EMPLOYEE R Date_hired D R Salary (1, 1) N (0,1) Works_in Mgr_start_dt Pl_name Pnumber (100, n) R No_of_employees PLANT (1,1) Building Budget If a plant is closed down, the employee no longer manages the plant but becomes an employee of another plant. No_of_dependents (0,m) (0, 20) (0, 1) Supervised_by (0, n) (0, n) Managed_by Hours Assigned C (1, m) (0,n) Undertaken_by (1,1) N PROJECT Plocation Pr_name Dependent_of Pnumber If an employee leaves the company, all dependants and BCU accounts of the employee must be removed. Held_by_E Dname Dependent (0,1) Related_how Birthdate (1, 1) DEPENDENT (1, n) C R Gender 1. deletion rule on undertaken_by conflicts with the participation constraint of PROJECT 2. Contradicting deletion rules on DEPENDENT (0, n) C Annual_cost As long as a dependant has a BCU account, deletion of the dependant is not permitted. Account_id C Held_by_D (0,1) c BCU_ACCOUNT Balance Hb_name Participates (0,m) R HOBBY Hrs_per_wk Gi_activity Acct_type Account# Io_activity Figure 3.7 Course-granular Design-Specific ER diagram for Bearcat, Incorporated - Stage 2 {deletion constraints added}

30 Representing Deletion Constraints Using Deletion Rules (continued) As long as an employee is assigned to a project, his or her record cannot be removed from the database. Emp# Gender Fname Date_hired No_of_dependents Minit Lname Name Address EMPLOYEE Name_tag D R R Salary (1, 1) N (0,1) Works_in Mgr_start_dt Managed_by Pl_name Pnumber (100, n) R No_of_employees PLANT (1,1) (0,n) Building Budget If a project is deleted, all assignments of employees to that project must be deleted. If a dependent is deleted, all records of the participation of that dependent in hobbies must be deleted. (0,m) Held_by_E Dname (0, 20) Dependent (0, 1) Supervised_by Related_how (0, n) (0, n) Dependent_of (1, 1) C DEPENDENT Undertaken_by Hours (0,1) Plocation N (1, m) Assigned PROJECT Pr_name C Pnumber Conflicting deletion rules and constraints realigned A hobby with at least one dependent participating in it can not be deleted. (0,1) Birthdate (0, n) Gender Held_by_D (0,1) (0, n) Hb_name C Participates (0,m) R Annual_cost Hrs_per_wk Account_id C C BCU_ACCOUNT Balance HOBBY Gi_activity Acct_type Account# Io_activity Figure 3.8 Course-granular Design-Specific ER diagram for Bearcat, Incorporated - Final

32 Enhanced Entity-Relationship (EER) Model Enhanced Entity-Relationship (EER) modeling is an extension to the ER modeling that incorporates additional constructs Central construct: Superclass/subclass (SC/sc) relationship More specifically: Specialization/generalization Categorization Aggregation Data Modeling & Database Design (EER Modeling) 32

33 Superclass/Subclass Relationship (SC/sc) Inter-Entity Class Relationship (Has-a Relationship) A STORE has a relationship with FURNITURE There are 3 SC/sc relationships A CHAIR is a FURNITURE A TABLE is a FURNITURE A SOFA is a FURNITURE Intra-Entity Class Relationship (Is-a Relationship) A CHAIR is a FURNITURE CHAIR, TABLE, and SOFA are entity types that belongs to entity class FURNITURE Data Modeling & Database Design (EER Modeling) 33

34 Think About It Theoretically, one has three choices of modeling furniture/chair/table/sofa I. Model three separate entity types for chair, table, and sofa, and create three separate relationship types with the entity type STORE II. Model FURNITURE as an entity type with an attribute called furniture_type; then chair, table, and sofa would be values of that attribute III.Model FURNITURE as a superclass/subclass Data Modeling & Database Design (EER Modeling) 34

35 SC/sc Relationships There are two basic kinds of SC/sc relationships Specialization/Generalization: One superclass (SC) is related to one or more subclasses (sc) Categorization: One subclass (sc) is related to one or more superclasses (SC) Data Modeling & Database Design (EER Modeling) 35

36 Properties of SC/sc Relationships An entity that exists in a subclass can be associated with only one superclass entity An entity cannot exist in the database merely by being a member of a subclass; it must also be a member of an associated superclass An entity that is a member of a superclass can be optionally included as a member of any number of its subclasses It is not required that every member of a superclass be a member of a subclass Data Modeling & Database Design (EER Modeling) 36

37 Properties of SC/sc Relationships (continued) Type Inheritance Property: A subclass inherits all the attributes of the superclass to which it is related In addition, it will also inherit all the relationship types in which the superclass participates A subclass may also have its own specific attributes in addition to the attributes inherited Likewise, a subclass may have its own specific relationship(s) with other entity types (i.e., inter-entity class relationships) Data Modeling & Database Design (EER Modeling) 37

38 Note That The cardinality ratio of any SC/sc relationship is always 1:1 The participation of the subclass in a SC/sc relationship is always total A subclass inherits all attributes as well as all relationship types that a superclass possesses (type inheritance property) Data Modeling & Database Design (EER Modeling) 38

39 Specialization and Generalization Specialization is the process of generating subgroups ( sc s) of a generic entity class (SC) by specifying the distinguishing properties (attributes) of the subgroups (top-down approach) Generalization, on the other hand, crystallizes the common properties (attributes) shared by a set of entity types ( sc s) into a generic entity type (SC) (bottom-up approach) Notation: circle + fork (indicating subset) Read: is-a Data Modeling & Database Design (EER Modeling) 39

40 Specialization and Generalization (continued) Completeness Constraint The participation of the superclass in a specialization/ generalization is referred to as the completeness constraint and can assume one of two values: total or partial Total specialization means that every entity of the superclass must participate in this specialization/ generalization relationship (indicated by a solid line from the superclass to the specialization/generalization symbol (i.e., the circle)) Partial specialization means that there may be entities present in the superclass that do not participate in this specialization/generalization (indicated by a dotted line) Data Modeling & Database Design (EER Modeling) 40

41 Specialization and Generalization (continued) Disjointness Constraint Used to specify that the subclasses of a specialization must be: Disjointed (indicated by D ), i.e., an entity of the superclass cannot be a member of more than one subclass Overlapped across subclasses (indicated by O ) We have to specify both: completeness and disjointness constraints! Data Modeling & Database Design (EER Modeling) 41

42 Notation Data Modeling & Database Design (EER Modeling) 42

43 Often attribute(s) in the superclass are used to define the predicate. If all values of the predicate are determined by the same attribute in the superclass, this attribute is referred as the defining attribute and the specialization itself is labeled attribute defined specialization. Example: sport in Fig 4.7 There are cases where the membership of the entity is determined by the end-user individually for each entity, based on some, not necessarily well defined procedure. The specialization is then called a user-defined (or procedure defined) specialization. Data Modeling & Database Design (EER Modeling) 43

44 An EER Model of Vignette 1 Multivalued attribute Subtype discriminator Defining attribute Subtype discriminator is the attribute in supertype entity that determines to which subtype the supertype occurrence is related. Data Modeling & Database Design (EER Modeling) 44

45 An Extension of Vignette 1: Multiple Specializations I. Multiple specialization of the same entity type (SC) II. Specific relationship of a subclass entity type (sc) Multivalued attribute Three independent specializations Three subclasses One subclass Two subclasses Data Modeling & Database Design (EER Modeling) 45

Chapter (4) Enhanced Entity-Relationship and Object Modeling

Chapter (4) Enhanced Entity-Relationship and Object Modeling Objectives Concepts of subclass and superclass and the related concepts of specialization and generalization. Concept of category, which is