Entity Relationship Model

Entity Relationship Model
Chapter 1 Entity Relationship Model

Chapter 3 : Objectives Main Phases of Database Design
Characteristics of ER Model Components of ER Model Definitions Classification of Attributes Entity Types Entity Set Key attribute Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Chapter 3 : Objectives (Continued.)
Relationship Types Recursive Relationships: Structural Constraints on Relationship Types: Attributes on Relationship Types Weak Entity Type Problems with ER Models Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Main Phases of Database Design
Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Introduction E-R model facilitates database design by allowing the specification of an “enterprise schema” which represents the overall logical structure of a database. The E-R model is extremely useful in mapping the meanings and interactions of real-world enterprises onto a conceptual schema. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Characteristics of ER Model
Express the logical properties of an enterprise database No physical DBMS Proposed by Dr. Peter Chen Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Components of ER Model Entity, Entity Type, Entity Set Attribute
Key (Identifier) Relationship, Relationship Type, Relationship Set Structural Constraints on relationships Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Definitions Entity: a collection of entities
A Database can be modeled as : a collection of entities relationships among entities. Entity: An object in the real world with an independent existence Is distinguishable from other objects could have a physical existence or a conceptual existence Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Example (Entity) Example: person, company, event, plant
More Specific example: Consider University of Windsor as a large enterprise. Entities : Ritu (Employee) John Smith (Student) … Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Attribute Attribute: the property that describes an entity or a relationship type. Examples: Student : id, fname, lname, yrAdmin Employees: id, fname, lname, position ER : Domain of Attributes: Set of values that may be assigned to that attribute for each entity (set of permitted values) . Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Entity Types A collection of entities that have the same attributes (describes the intension of a database). ER : Example : EMPLOYEES, STUDENTS Entity Type Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Entity Set Entity Set : The collection of all entities of a particular entity type in the database at any point in time. (Extension of the database) Attributes are properties possessed by all members of an entity set . Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Classification of Attributes
1.Simple ~ Composite Simple Attribute : Attribute composed of a single component with an independent existence. Composite Attribute Attribute composed of multiple components, each with an independent existence. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

2. Single-Valued ~ Multi-Valued Single-valued Attribute Attribute that holds a single value for each occurrence of an entity type. Multi-valued Attribute { }, Attribute that holds multiple values for each occurrence of an entity type. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

3. Stored ~ Derived Derived Attribute Attribute that represents a value that is derivable from value of a related attribute, or set of attributes, not necessarily in the same entity type. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

NULL Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Key attribute Key attribute : An attribute of an entity type whose values are distinct for each individual entity in the collection. ER : Student_Id Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Example : COMPANY Database:
1. The company is organized into departments. Each department has a unique name, a unique number, and a particular employee who manages the department. We keep track of the start date when that employee began managing the department. A department may have several locations. 2. A department controls a number of projects, each of which has a unique name, a unique number, and a single location. 3. We store each employee’s name, social security number ,address, salary, sex, and birth date. An employee is assigned to one department but may work on several projects, which are not necessarily controlled by the same department. We keep track of the number of hours per week that an employee works on each project. We also keep track of the direct supervisor of each employee. 4. We want to keep track of the dependents of each employee for insurance purposes. We keep each dependent’s first name, sex, birth date, and relationship to the employee. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Preliminary design of entity types for the COMPANY Database
DEPARTMENT Name, Number, {Locations}, Manager, ManagerStartDate PROJECT Name, Number, Location, ControllingDepartment EMPLOYEE Name(FName, MInit, LName), SSN, Sex, Address, Salary, BirthDate, Department, Supervisor, {WorkOn (Project, Hours)} DEPENDENT Employee, DependentName, Sex, BirthDate, Relationship Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Relationship A relationship is an association among entities. 315
Course Ritu Employee Teaches Relationship Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Relationship Types A relationship type R among n entity types E1 .. En is a set of relationship instances r i where each r i associates n individual entities (e1, e2, …. en) and each entity ej in ri is a member of entity type Ej, 1<=j<=n. Ej is called the participating entity type. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Example An employee works for a department

Example Relationship instances : r1(e1, d1) r2(e2, d2)
Relationship type: WORKS_FOR ER : EMPLOYEE DEPARTMENT WORKS_FOR Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Example ER Diagram? Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Recursive Relationships:
The same entity type participates more than once in a relationship type in different roles. Each role is given a name. Example : Roles are optional – they clarify semantics of a relationship EMPLOYEE SUPERVISION Supervisee(2) Supervisor(1) Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Recursive Relationships

Attributes of Relationship Types
A relationship type can have attributes. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Degree of a relationship
Degree of a relationship: Number of relations taking part in a relationship type. Binary Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Structural Constraints on Relationship Types:
Limit the possible combination of entities Represent business rules established by the user or company. 2 Structural Constraints : Cardinality Ratio Participation Constraint Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Cardinality Ratio Cardinality Ratio : number of relationship instances that an entity can participate in. SHOWN BY PLACING APPROPRIATE NUMBER ON THE LINK. Examples : 1:N, 1:1 , M:N Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Participation Constraint
Participation Constraint: specifies whether the existence of an entity depends on its being related to another entity via the relationship type. SHOWN BY DOUBLE LINING THE LINK - Total (Existence dependency) ER : = - Partial Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Weak Entity Type Definition: A weak entity type is one that meets 2 conditions : 1. It is existence dependent; that is, it cannot exist without the entity with which it has a relationship. 2. It has a (primary) key that is partially or totally derived from the parent entity in the relationship. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Weak Entity Type -don't have key attributes of their own -Partial key
-Identifying Entity Type ER - -Weak entity types always have a total participation constraint with respect to its identifying relationship. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Example :ER for COMPANY database

Alternate ER Diagram Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Example 1 : Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Example 2 Draw an ER diagram to show the relationship between CLUB_MEMBER and LOCKER. Assume that every club member must have a locker, though a locker need not have a club member assigned to it. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Phases of DB Design Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Relational DB Model :Logical View of Data
Logical Model proposed in 1970 by Codd Designer focuses on logical representation rather than physical Use of table advantageous Structural and data independence Related records stored in independent tables Logical simplicity Allows for more effective design strategies Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Definitions A relation is a table with columns and rows.
Only applies to logical structure of the database, not the physical structure. Attribute is a named column of a relation. Attribute Domain is the set of allowable values for one or more attributes. Tuple is a row of a relation : rows represent a single entity Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Definitions Row/column intersection represents single value
Degree is the number of attributes in a relation. Cardinality is the number of tuples in a relation. Relational Database is a collection of normalized relations with distinct relation names. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Properties of a relation
The relation has a name that is distinct from all other relation names in the database schema. Theoretically, ordering of tuples may have no significance. The order of attributes has no significance. Each cell of a relation contains exactly one atomic value. Each attribute has a distinct name. The values of an attribute are all from the same domain. Each tuple is distinct – there are no duplicate tuples. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Examples of relation Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Examples of Attribute Domains

Mathematical Definition of Relation
- Consider two sets, D1 & D2, where D1 = {2, 4} and D2 = {1, 3, 5}. Cartesian product, D1 X D2, is set of all ordered pairs, where first element is member of D1 and second element is member of D2. => D1 X D2 = {(2, 1), (2, 3), (2, 5), (4, 1), (4, 3), (4, 5)} - Any subset of Cartesian product is a relation e.g: R = {(2,1),(4,1)} - Mathematically, r(R) is a subset of the Cartesian product of the domains that define R. => r(R) subsetOf (dom(A1) × dom(A2) ….× dom(An)) Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Definitions Relation Schema R denoted by R(A1,A2, …. An) is made up of a relation name R and a list of attributes A1, A2….An and domain name D1,D2,….Dn pairs. ( Each Ai has a Di ) Relational database schema is a set of relational schemas, each with a distinct name. Relation instance ( relation) r of a relation R(A1,A2,…..An) also denoted by r(R) is a set of n-tuples {t1….tm}where each n-tuple t is a list of n-values t=<v1,v2….vn> where 1≤vi≤n is an element of dom(Ai) R: schema of the relation R is also called the intension of a relation r is also called the extension of a relation Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Relational keys Superkey Candidate Key (K) Primary Key Alternate keys
Foreign Keys Surrogate keys Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Superkey An attribute or set of attributes that uniquely identifies a tuple in a relation. Every relation has at least one super key. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Candidate Key (K) Superkey such that no proper subset of K is a superkey within the relation. K is a minimal superkey. K is a super key of R with the additional property that removing any attribute A from K leaves a set of attributes K’ that is not a superkey of R. In each tuple of a relation R, values of K uniquely identify that tuple (Uniqueness). No proper subset of K has the uniqueness property (irreducibility). Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Primary Key Candidate key selected to identify tuples uniquely within a relation. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Alternate keys Candidate keys that are not selected to be primary key.

Surrogate Key A surrogate key is a system-generated (non-meaningful from a business perspective) primary key for purposes of ensuring uniqueness within a database table. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Foreign Keys A set of attributes FK in a relation R1 is a foreign key of R1 that references relation R2 if it satisfies the following rules : The attributes in FK have the same domain as the primary key attributes in PK of R2 A value of FK in a tuple t1 of R1 either occurs as a value of PK for some tuple t2 in R2 or is null. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Relational Schema of Company Database (with PKs and FKs) :
To be done in class. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Relational Integrity Constraints
Constraints are conditions that must hold on all valid relation instances. There are 4 main types of constraints: Domain Constraint Key constraints Entity Integrity Constraint Referential Integrity Constraint Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Domain Constraint: Specifies that the value of each attribute A in a relation Ri must be an atomic value from the dom(A) Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Entity Integrity Constraint
Specifies that no primary key value can be null. The primary key attributes PK of each relation schema R in S cannot have null values in any tuple of r(R). This is because primary key values are used to identify the individual tuples. => t[PK]  null for any tuple t in r(R) Note: Other attributes of R may be similarly constrained to disallow null values, even though they are not members of the primary key. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Referential Integrity Constraint
A constraint involving two relations (the previous constraints involve a single relation). Used to specify a relationship among tuples in two relations: the referencing relation and the referenced relation. Tuples in the referencing relation R1 have attributes FK (called foreign key attributes) that reference the primary key attributes PK of the referenced relation R2. A tuple t1 in R1 is said to reference a tuple t2 in R2 if t1[FK] = t2[PK]. A referential integrity constraint can be displayed in a relational database schema as a directed arc from R1.FK to R2. Used to maintain consistency among tuples of two relations Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Statement of the RI constraint
The value in the foreign key column (or columns) FK of the referencing relation R1 can be either: (1) a value of an existing primary key value of the corresponding primary key PK in the referenced relation R2, or (2) a null. In case (2), the FK in R1 should not be a part of its own primary key. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Enforcing Referential Integrity (Update Operations on Relations)
INSERT a tuple. DELETE a tuple. MODIFY a tuple. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Update Operations on Relations
Integrity constraints should not be violated by the update operations. Updates may propagate to cause other updates automatically. This may be necessary to maintain integrity constraints. In case of integrity violation, some actions that can be taken: Cancel the operation that causes the violation (REJECT option) Perform the operation but inform the user of the violation Trigger additional updates so the violation is corrected (CASCADE option, SET NULL option) Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

ER-to-Relational Mapping :Step 1
For each regular (strong) entity type E in the ER schema, create a relation R that includes all the simple attributes of E. Include only the simple component attributes of a composite attribute. Choose one of the key attributes of E as primary key for R. If the chosen key of E is composite, the set of simple attributes that form it will together form the primary key of R. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

For each weak entity type W in the ER schema with owner entity type E, create a relation R, and include all simple attributes (or simple components of composite attributes) of W as attributes of R. In addition, include as foreign key attributes of R the primary key attribute(s) of the relation(s) that correspond to the owner entity type(s); this takes care of the identifying relationship type of W. The primary key of R is the combination of the primary key(s) of the owner(s) and the partial key of the weak entity type W, if any. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

For each binary 1:1 relationship type R in the ER schema, identify the relations S and T that correspond to the entity types participating in R. Choose one of the relations—S, say—and include as foreign key in S the primary key of T. It is better to choose an entity type with total participation in R in the role of S. Include all the simple attributes (or simple components of composite attributes) of the 1:1 relationship type R as attributes of S. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

For each regular binary 1:N relationship type R, identify the relation S that represents the participating entity type at the N-side of the relationship type. Include as foreign key in S the primary key of the relation T that represents the other entity type participating in R; this is because each entity instance on the N-side is related to at most one entity instance on the 1-side of the relationship type. Include any simple attributes (or simple components of composite attributes) of the 1:N relationship type as attributes of S. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

For each binary M:N relationship type R, create a new relation S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types; their combination will form the primary key of S. Also include any simple attributes of the M:N relationship type (or simple components of composite attributes) as attributes of S. Notice that we cannot represent an M:N relationship type by a single foreign key attribute in one of the participating relations—as we did for 1:1 or 1:N relationship types—because of the M:N cardinality ratio. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

For each multivalued attribute A, create a new relation R. This relation R will include an attribute corresponding to A, plus the primary key attribute K—as a foreign key in R—of the relation that represents the entity type or relationship type that has A as an attribute. The primary key of R is the combination of A and K. If the multivalued attribute is composite, we include its simple components Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

ER-to-Relational Mapping :Step 7(beyond the scope of 315(I 2008))
For each n-ary relationship type R, where n > 2, create a new relation S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types. Also include any simple attributes of the n-ary relationship type (or simple components of composite attributes) as attributes of S. The primary key of S is usually a combination of all the foreign keys that reference the relations representing the participating entity types. However, if the cardinality constraints on any of the entity types E participating in R is 1, then the primary key of S should not include the foreign key attribute that references the relation E’ corresponding to E .This concludes the mapping procedure. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Example : ER – to – Relational
1 N Parent_Child PERSON SIN Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Example : Course and Section

Existence-Dependency Revisited
Existence-dependency means that one entity cannot exist independent of a related entity. In database terms, existence-dependency can be explained this way: If an entity’s FK cannot contain nulls – that is, the FK entry is mandatory -- the entity is existence-dependent on the related entity. If an entity’s FK can be null, then the entity is existence-independent of the related entity. Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Example : COURSE(CRS_CODE, CRS_DESCRIPTION, CRS_CREDIT)
SECTION (CRS_CODE, SECTION#, YEAR, SEM, CLASS_TIME, ROOM_CODE, PROF_NUM) SECTION cannot exist unless it has a FK CRS_CODE that points to an existing COURSE row. But this condition means that SECTION is existence-dependent on COURSE. Incidentally, in this example SECTION is also a weak ENTITY to COURSE. That’s because a weak entity is defined as one that inherits at least part of its PK from the (parent) COURSE entity and it is existence-dependent on the (parent) COURSE entity. (Note that there are two requirements that must be met before an entity can be classified as weak). Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Example (Contd). COURSE(CRS_CODE, CRS_DESCRIPTION, CRS_CREDIT)
SECTION (CLASS_CODE, CRS_CODE, SECTION#, CLASS_TIME, ROOM_CODE, PROF_NUM ) CLASS_CODE is a surrogate key Let’s assume that the CRS_CODE FK in the SECTION is declared to be “not null.” The SECTION entity is existence-dependent on COURSE. (That’s because it is reasonable to assume that COURSE is mandatory to SECTION, since a section does not appear in the class schedule unless there is a course description for it in the course catalog. Note that the "not null" FK requirement means that the CRS_CODE FK in the CLASS entity is mandatory.) SECTION is not a weak entity (That’s because although the SECTION is existence-dependent on COURSE -- the SECTION entity’s PK does not contain the PK of the COURSE entity.) Ritu Chaturvedi Some figures adapted from Fundamentals of database systems by Elmasri and Navathe and By T. Connolly

Entity Relationship Model

Similar presentations

Presentation on theme: "Entity Relationship Model"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Entity Relationship Model

Similar presentations

Presentation on theme: "Entity Relationship Model"— Presentation transcript:

Similar presentations

About project

Feedback