Entity Relationship Data Model Slides by: Shree Jaswal
Topics: Conceptual Modeling of a database, The Entity-Relationship (ER) Model, Entity Types, Entity Sets, Attributes, and Keys, Relationship Types, Relationship Sets, Weak Entity Types Generalization, Specialization and Aggregation, Extended Entity-Relationship (EER) Model.
Which Chapter? Which Book? Chapter 7: Conceptual data modeling using entities and relations, Elmasri and Navathe, Fundamentals of Database Systems, 6th Edition, PEARSON Education Chapter 2: Introduction to Database Design, Raghu Ramkrishnan and Johannes Gehrke, Database Management Systems,TMH Chapter 2: Introduction to Relational Model, Korth, Slberchatz,Sudarshan, Database System Concepts, 6th Edition, McGraw Hill
Overview of Database Design Process Two main activities: Database design Applications design Focus in this chapter on database design To design the conceptual schema for a database application Applications design focuses on the programs and interfaces that access the database Generally considered part of software engineering
ER modeling
Example COMPANY Database We need to create a database schema design based on the following (simplified) requirements of the COMPANY Database: The company is organized into DEPARTMENTs. Each department has a name, number and an employee who manages the department. We keep track of the start date of the department manager. A department may have several locations. Each department controls a number of PROJECTs. Each project has a unique name, unique number and is located at a single location.
Example COMPANY Database (Contd.) We store each EMPLOYEE s social security number, address, salary, sex, and birthdate. Each employee works for one department but may work on several projects. We keep track of the number of hours per week that an employee currently works on each project. We also keep track of the direct supervisor of each employee. Each employee may have a number of DEPENDENTs. For each dependent, we keep track of their name, sex, birthdate, and relationship to the employee.
ER Model Concepts Entities and Attributes Entities are specific objects or things in the mini-world with an independent existence that are represented in the database. For example the EMPLOYEE John Smith, the Research DEPARTMENT, the ProductX PROJECT Attributes are properties used to describe an entity. For example an EMPLOYEE entity may have the attributes Name, SSN, Address, Sex, BirthDate A specific entity will have a value for each of its attributes. For example a specific employee entity may have Name='John Smith', SSN='123456789', Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55 Each attribute has a value set (or data type) associated with it e.g. integer, string, subrange, enumerated type,
Types of Attributes Simple Each entity has a single atomic value for the attribute. For example, SSN or Sex. Composite The attribute may be composed of several components. For example: Address(Apt#, House#, Street, City, State, ZipCode, Country), or Name(FirstName, MiddleName, LastName). Composition may form a hierarchy where some components are themselves composite. Multi-valued An entity may have multiple values for that attribute. For example, Color of a CAR or PreviousDegrees of a STUDENT. Denoted as {Color} or {PreviousDegrees}.
Types of Attributes In general, composite and multi-valued attributes may be nested arbitrarily to any number of levels, although this is rare. For example, PreviousDegrees of a STUDENT is a composite multi-valued attribute denoted by {PreviousDegrees (College, Year, Degree, Field)} Multiple PreviousDegrees values can exist Each has four subcomponent attributes: College, Year, Degree, Field
Example of a composite attribute
Entity Types and Key Attributes Entities with the same basic attributes are grouped or typed into an entity type. For example, the entity type EMPLOYEE and PROJECT. An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type. For example, SSN of EMPLOYEE.
Entity Types and Key Attributes A key attribute may be composite. VehicleTagNumber is a key of the CAR entity type with components (Number, State). An entity type may have more than one key. The CAR entity type may have two keys: VehicleIdentificationNumber (popularly called VIN) VehicleTagNumber (Number, State), aka license plate number. Each key is underlined
Stored versus Derived Attributes Two (or more) attributes are related Example AGE and Birth_date Age is the derived attribute which can be derived from the stored attribute birth_date Attributes can also be derived from related entities Eg:- Number_of_employees in a department
NULL Values A particular entity may not have an applicable value for an attribute (flat number for a bungalow ) This can be because the value is either missing or unknown Unknown can either be because the value exists but is currently missing(height) or when the value is not known(eg:- home_phone of a person)
Complex attributes {Address_phone({phone(area_code,phone_number)},Addr ess(street_address(number,street,apartment_number),ci ty,state,zip))} If a person can have more than one residence and each residence can have a single address and multiple phones
Representations of attributes
Displaying an Entity type In ER diagrams, an entity type is displayed in a rectangular box Attributes are displayed in ovals Each attribute is connected to its entity type Components of a composite attribute are connected to the oval representing the composite attribute Each key attribute is underlined Multivalued attributes displayed in double ovals See CAR example on next slide
Entity Set Each entity type will have a collection of entities stored in the database Called the entity set Previous slide shows three CAR entity instances in the entity set for CAR Same name (CAR) used to refer to both the entity type and the entity set Entity set is the current state of the entities of that type that are stored in the database
Entity type describes the schema Schema is also called Intention For example, Employee(EmpNo Number(4) Not NULL, EName Char(20), Age Number(2), Dept Char(4) ) Collection of entities of a particular entity type is grouped as entity set Entity set is called as Extention Example Relation: Employee at time= t2 after adding more records EmpNo EmpName Age Dept 1001 Jason 23 SD 1002 William 24 HR
Initial Design of Entity Types for the COMPANY Database Schema Based on the requirements, we can identify four initial entity types in the COMPANY database: DEPARTMENT PROJECT EMPLOYEE DEPENDENT Their initial design is shown on the following slide The initial attributes shown are derived from the requirements description
Refining the initial design by introducing relationships The initial design is typically not complete Some aspects in the requirements will be represented as relationships ER model has three main concepts: Entities (and their entity types and entity sets) Attributes (simple, composite, multivalued) Relationships (and their relationship types and relationship sets)
Relationships and Relationship Types A relationship relates two or more distinct entities with a specific meaning. For example, EMPLOYEE John Smith works on the ProductX PROJECT, or EMPLOYEE Franklin Wong manages the Research DEPARTMENT. Relationships of the same type are grouped or typed into a relationship type. For example, the WORKS_ON relationship type in which EMPLOYEEs and PROJECTs participate, or the MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs participate. The degree of a relationship type is the number of participating entity types. Both MANAGES and WORKS_ON are binary relationships.
Relationship types, sets and instances A relationship set R is a set of relationship instances r i,where each r i associates n individual entities (e 1,e 2,e 3, e n ) and each e j in r i is a member of entity type E j, 1 j n Each of the entity types E 1,E 2, E n participates in R
Relationship instances of the WORKS_FOR N:1 relationship between EMPLOYEE and DEPARTMENT
Relationship instances of the M:N WORKS_ON relationship between EMPLOYEE and PROJECT
Relationship type vs. relationship set Relationship Type: Is the schema description of a relationship Identifies the relationship name and the participating entity types Also identifies certain relationship constraints Relationship Set: The current set of relationship instances represented in the database The current state of a relationship type
Relationship type vs. relationship set Previous figures displayed the relationship sets Each instance in the set relates individual participating entities one from each participating entity type In ER diagrams, we represent the relationship type as follows: Diamond-shaped box is used to display a relationship type Connected to the participating entity types via straight lines
Relationship Degree, Role Names, recursive relationships Degree:- Number of participating entity types. WORKS_FOR is Binary relationship Supplier selling parts for a product is ternary relationship The University might need to record which teachers taught which subjects in which courses.
Refining the COMPANY database schema by introducing relationships By examining the requirements, six relationship types are identified All are binary relationships( degree 2) Listed below with their participating entity types: WORKS_FOR (between EMPLOYEE, DEPARTMENT) MANAGES (also between EMPLOYEE, DEPARTMENT) CONTROLS (between DEPARTMENT, PROJECT) WORKS_ON (between EMPLOYEE, PROJECT) SUPERVISION (between EMPLOYEE (as subordinate), EMPLOYEE (as supervisor)) DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)
Discussion on Relationship Types In the refined design, some attributes from the initial entity types are refined into relationships: Manager of DEPARTMENT -> MANAGES Works_on of EMPLOYEE -> WORKS_ON Department of EMPLOYEE -> WORKS_FOR In general, more than one relationship type can exist between the same participating entity types MANAGES and WORKS_FOR are distinct relationship types between EMPLOYEE and DEPARTMENT Different meanings and different relationship instances.
Recursive Relationship Type An relationship type participates in entity type with distinct roles Example: the SUPERVISION relationship EMPLOYEE participates twice in two distinct roles: supervisor (or boss) role supervisee (or subordinate) role Each relationship instance relates two distinct EMPLOYEE entities: One employee in supervisor role One employee in supervisee role
Displaying a recursive relationship In a recursive relationship type. Both participations are same entity type in different roles. For example, SUPERVISION relationships between EMPLOYEE (in role of supervisor or boss) and (another) EMPLOYEE (in role of subordinate or worker). In ER diagram, need to display role names to distinguish participations.
Cardinality ratios for binary relationship Specifies the maximum number of relationship instances that an entity can participate in.
Constraints on Relationships Constraints limit the possible combinations of entities that may participate in the corresponding relationship set. Constraints on Relationship Types (Also known as ratio constraints) Cardinality Ratio (specifies maximum participation) One-to-one (1:1) MANAGES EMPLOYEE:DEPARTMENT One-to-many (1:N) or Many-to-one (N:1) EMPLOYEES:DEPARTMENT Many-to-many (M:N) EMPLOYEE:PROJECTS
Many-to-one (N:1) Relationship
Many-to-many (M:N) Relationship
Participation Constraints and Existence Dependencies Specifies whether the existence of an entity depends on its being related to another entity via the relationship type. (minimum cardinality constraint) There are two types Total:- every entity in employee set must be related to department via works_for Partial:- some or part of employee entities are related to department via manages.
Attributes of Relationship types A relationship type can have attributes: For example, HoursPerWeek of WORKS_ON Its value for each relationship instance describes the number of hours per week that an EMPLOYEE works on a PROJECT. A value of HoursPerWeek depends on a particular (employee, project) combination Most relationship attributes are used with M:N relationships In 1:N relationships, they can be transferred to the entity type on the N-side of the relationship
Weak Entity Types An entity that does not have a key attribute A weak entity must participate in an identifying relationship type with an owner or identifying entity type Entities are identified by the combination of: A partial key of the weak entity type The particular entity they are related to in the identifying entity type Example: A DEPENDENT entity is identified by the dependent s first name, and the specific EMPLOYEE with whom the dependent is related Name of DEPENDENT is the partial key DEPENDENT is a weak entity type EMPLOYEE is its identifying entity type via the identifying relationship type DEPENDENT_OF
Notation for Constraints on Relationships Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1, or M:N Shown by placing appropriate numbers on the relationship edges. Participation constraint (on each participating entity type): total (called existence dependency) or partial. Total shown by double line, partial by single line. NOTE: These are easy to specify for Binary Relationship Types.
Example Design an E-R schema for a database to store info about professors, courses and course sections indicating the following: The name and employee ID number of each professor The salary and email address(es) for each professor How long each professor has been at the university The course sections each professor teaches The name, number and topic for each course offered The section and room number for each course section Each course section must have only one professor Each course can have multiple sections
University DB Case Study Maintain the following information about undergrad students: Name, address, student number, date of birth, year of study, degree program (BA, BSc, BCS), concentration (Major, Honours, etc) and department of concentration. Note: An address is composed of a street, city, province and postal code; the student number is unique for each student
University Case Study (cont d) Maintain information about departments Name, code (CS, Phy), office phone, and faculty members Maintain information about courses: Course number (3753), title, description, prerequisites. Maintain information about course sections: Section (A, B, C), term (X1), slot #, instructor
University Case Study (cont d) Maintain information about faculty: Name, rank, employee number, salary, office number, phone number and email address. Note: employee number is unique Maintain a program of study for the current year for each student: i.e. courses that each student is enrolled in
University Case Study (cont d) Students are enrolled for sections 1 course has many sections Teacher can teach any number of sections Courses can be prerequisite for other courses A faculty heads a department. Department has any number of faculties.
Number Term Section N Enrolled M Student Address Number Street City Slot N Has N Teaches 1 Name DOB Province Postal Code 1 Salary Name Number N Prereq Faculty Number Office Title Description Course M Start Date 1 Head N Member Phone Email N End Date 1 1 Code Rank Offer 1 Dept Name Phone
Alternative (min, max) notation for relationship structural constraints: Specified on each participation of an entity type E in a relationship type R Specifies that each entity e in E participates in at least min and at most max relationship instances in R Default(no constraint): min=0, max=n (signifying no limit) Must have min max, min 0, max 1 Derived from the knowledge of mini-world constraints Examples: A department has exactly one manager and an employee can manage at most one department. Specify (0,1) for participation of EMPLOYEE in MANAGES Specify (1,1) for participation of DEPARTMENT in MANAGES An employee can work for exactly one department but a department can have any number of employees. Specify (1,1) for participation of EMPLOYEE in WORKS_FOR Specify (0,n) for participation of DEPARTMENT in WORKS_FOR
The (min,max) notation for relationship constraints Read the min,max numbers next to the entity type and looking away from the entity type
Discussion of n-ary relationships (n > 2) In general, 3 binary relationships can represent different information than a single ternary relationship If needed, the binary and n-ary relationships can all be included in the schema design In some cases, a ternary relationship can be represented as a weak entity if the data model allows a weak entity type to have multiple identifying relationships
Example of a ternary relationship
EER Modelling
EER Modelling The enhanced entity relationship (EER) model (or extended entity relationship model) in computer science is a high-level or conceptual data model incorporating extensions to the original entity relationship (ER) model, used in the design of databases.
Types of Constraints on Specialization and Generalization Constraints on sub classes Attribute defined User defined Disjointness constraints Disjoint Overlap Completeness constraints Partial specialization Total specialization
Constraints on Specialization and Generalization We have four types of specialization/generalization: Disjoint, total Disjoint, partial Overlapping, total Overlapping, partial Note: Generalization usually is total because the superclass is derived from the subclasses.
Specialization / Generalization Hierarchies, Lattices and Shared Subclasses A subclass may itself have further subclasses specified on it Forms a hierarchy or a lattice Hierarchy has a constraint that every subclass has only one superclass (called single inheritance) In a lattice, a subclass can be subclass of more than one superclass (called multiple inheritance) In a lattice or hierarchy, a subclass inherits attributes not only of its direct superclass, but also of all its predecessor superclasses A subclass with more than one superclass is called a shared subclass
Specialization & generalization hierarchies and lattices
Specialization / Generalization Hierarchies, Lattices and Shared Subclasses Can have specialization hierarchies or lattices, or generalization hierarchies or lattices In specialization, start with an entity type and then define subclasses of the entity type by successive specialization (top down conceptual refinement process) In generalization, start with many entity types and generalize those that have common properties (bottom up conceptual synthesis process) In practice, the combination of two processes is employed
Categories (UNION TYPES) All of the superclass/subclass relationships we have seen thus far have a single superclass A shared subclass is subclass in more than one distinct superclass/subclass relationships, where each relationships has a single superclass (multiple inheritance) In some cases, need to model a single superclass/subclass relationship with more than one superclass Superclasses represent different entity types Such a subclass is called a category or UNION TYPE
Categories (UNION TYPES) Example: Database for vehicle registration, vehicle owner can be a person, a bank (holding a lien on a vehicle) or a company. Category (subclass) OWNER is a subset of the union of the three superclasses COMPANY, BANK, and PERSON A category member must exist in at least one of its superclasses Note: The difference from shared subclass, which is subset of the intersection of its superclasses (shared subclass member must exist in all of its superclasses).
Aggregation Consider the ternary relationship works_on Suppose we want to record managers for tasks performed by an employee at a branch
Aggregation (Cont.) Relationship sets works_on and manages represent overlapping information Every manages relationship corresponds to a works_on relationship However, some works_on relationships may not correspond to any manages relationships So we can t discard the works_on relationship
Eliminate this redundancy via aggregation Treat relationship as an abstract entity Allows relationships between relationships Abstraction of relationship into new entity Without introducing redundancy, the following diagram represents: An employee works on a particular job at a particular branch An employee, branch, job combination may have an associated manager
E-R Diagram With Aggregation