Chapter 3 Data Modeling Using the Entity-Relationship (ER) Model
Chapter Outline <ul><li>Overview of Database Design Process </li></ul><ul><li>Example Database Application (COMPANY) </li>...
Overview of Database Design Process <ul><li>Two main activities: </li></ul><ul><ul><li>Database design </li></ul></ul><ul>...
Overview of Database Design Process
Example COMPANY Database <ul><li>We need to create a database schema design based on the following (simplified)  requireme...
Example COMPANY Database (Contd.) <ul><ul><li>We store each EMPLOYEE’s social security number, address, salary, sex, and b...
ER Model Concepts <ul><li>Entities and Attributes </li></ul><ul><ul><li>Entities are specific objects or things in the min...
Types of Attributes (1) <ul><li>Simple </li></ul><ul><ul><li>Each entity has a single atomic value for the attribute. For ...
Types of Attributes (2) <ul><li>In general, composite and multi-valued attributes may be nested arbitrarily to any number ...
Example of a composite attribute
Entity Types and Key Attributes (1) <ul><li>Entities with the same basic attributes are grouped or typed into an entity ty...
Entity Types and Key Attributes (2) <ul><li>A key attribute may be composite.  </li></ul><ul><ul><li>VehicleTagNumber is a...
Displaying an Entity type <ul><li>In ER diagrams, an entity type is displayed in a rectangular box </li></ul><ul><li>Attri...
Entity Type CAR with two keys and a corresponding Entity Set
Entity Set <ul><li>Each entity type will have a collection of entities stored in the database </li></ul><ul><ul><li>Called...
Initial Design of Entity Types for the  COMPANY  Database Schema <ul><li>Based on the requirements, we can identify four i...
Initial Design of Entity Types: EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
Refining the initial design by introducing  relationships <ul><li>The initial design is typically not complete </li></ul><...
Relationships and Relationship Types (1) <ul><li>A  relationship  relates two or more distinct entities with a specific me...
 
 
 
Relationship type vs. relationship set (1) <ul><li>Relationship Type: </li></ul><ul><ul><li>Is the schema description of a...
Relationship type vs. relationship set (2) <ul><li>Previous figures displayed the relationship sets </li></ul><ul><li>Each...
Refining the COMPANY database schema by introducing relationships <ul><li>By examining the requirements, six relationship ...
<ul><li>Relationship Types </li></ul><ul><li>Each entity type  E1, E2, …, En  is said to participate in the relationship t...
Discussion on Relationship Types <ul><li>In the refined design, some attributes from the initial entity types are refined ...
Recursive Relationship Type <ul><li>An relationship type whose with the same participating entity type in  distinct roles ...
<ul><li>Two types of entities: </li></ul><ul><ul><li>Strong entity : can exist independently (or can uniquely identify its...
A  weak entity type  is an entity which does not have any key attributes Employee Department Works-for Dependents Dependen...
Weak Entity Types <ul><li>An entity that does not have a key attribute </li></ul><ul><li>A weak entity must participate in...
Constraints on Relationships <ul><li>Constraints on Relationship Types </li></ul><ul><ul><li>(Also known as ratio constrai...
Relationships <ul><li>The  role name  signifies the role that a participating entity from the entity type plays in each re...
Cardinality Ratio <ul><li>Specifies the number of relationship instances that an entity can participate in. Common cardina...
An employee works for  one  company, and a company has  many  employees working for it. EMPLOYEE WORKS-FOR COMPANY N 1
A department has  one  manager and an Employee manages  one  department. DEPARTMENT Manage EMPLOYEE 1 1
An employee works on  many  projects, and a project has  many  employees working on it. EMPLOYEE WORKS-ON PROJECT M N
Participation Constraints <ul><li>Specifies whether the  existence  of an entity depends on it being related to another en...
An employee cannot exist  without  participating in the WORKS-FOR relationship; a department cannot exist without employee...
A person  may buy  a car and car  may be bought  by a person Partial participation PERSON Buys CAR 1 N
A professor  may manage  a department ( partial participation ), but a department  must be managed  by a professor ( total...
Structural Constraints on Relationships <ul><li>Cardinality ratio: ( 1:1, 1:N, M:N ) </li></ul><ul><li>Participating const...
Attributes of Relationship types <ul><li>A relationship type can have attributes: </li></ul><ul><ul><li>For example, Hours...
Attributes of Relationship Types EMPLOYEE DEPARTMENT Works-for 1 N  Start-Date We may keep a  start date  attribute to rec...
Attributes of Relationship Types continued ... Department Manager Manages 1 N  Start-Date We may put a start date as an at...
Notation for Constraints on Relationships <ul><li>Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1, or M:N </li...
Cardinality Constraint (2) <ul><li>General format: </li></ul><ul><li>0    min_card    max_card  </li></ul><ul><ul><li>In...
Cardinality Constraint (3) <ul><li>Definition:  </li></ul><ul><ul><li>If every entity in E involves  at least one  relatio...
Cardinality Constraint (4) <ul><li>Employees has a partial participation. </li></ul><ul><li>Departments has a total partic...
Representing 1-to-1, 1-to-m, m-to-m Relationships  R E (0, 1) (0, 1) F one-to-one: R E (0, m) (0, n) F many-to-many: R E (...
Recursive Relationship Type is:  SUPERVISION (participation role names are shown)
Alternative (min, max) notation for relationship structural constraints: <ul><li>Specified on each participation of an ent...
Summary of notation for ER diagrams
<ul><li>A  stored  attribute is a one whose value is explicitly stored in the database. </li></ul><ul><ul><li>e.g. name, b...
Null Values <ul><li>An attribute may have  null  as its value. </li></ul><ul><li>Null may mean </li></ul><ul><ul><li>not a...
Alternative diagrammatic notation <ul><li>ER diagrams is one popular example for displaying database schemas </li></ul><ul...
UML class diagrams <ul><li>Represent classes (similar to entity types) as large rounded boxes with three sections: </li></...
UML class diagram for COMPANY database schema
Other alternative diagrammatic notations
Relationships of Higher Degree <ul><li>Relationship types of degree 2 are called binary </li></ul><ul><li>Relationship typ...
Discussion of n-ary relationships (n > 2) <ul><li>In general, 3 binary relationships can represent different information t...
Example of a ternary relationship
Discussion of n-ary relationships (n > 2) <ul><li>If a particular binary relationship can be derived from a higher-degree ...
Another example of a ternary relationship
Displaying constraints on higher-degree relationships <ul><li>The (min, max) constraints can be displayed on the edges – h...
Data Modeling Tools <ul><li>A number of popular tools that cover conceptual modeling and mapping into relational schema de...
Some of the Currently Available Automated Database Design Tools Data modeling, design/reengineering Visual Basic/C++ Visio...
Extended Entity-Relationship (EER) Model (in next chapter) <ul><li>The entity relationship model in its original form did ...
Chapter Summary <ul><li>ER Model Concepts: Entities, attributes, relationships </li></ul><ul><li>Constraints in the ER mod...
Upcoming SlideShare
Loading in...5
×

Slide 3- 1 Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei

1,888

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,888
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
91
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Slide 3- 1 Copyright © 2007 Ramez Elmasr and Shamkant B. Navathei

  1. 2. Chapter 3 Data Modeling Using the Entity-Relationship (ER) Model
  2. 3. Chapter Outline <ul><li>Overview of Database Design Process </li></ul><ul><li>Example Database Application (COMPANY) </li></ul><ul><li>ER Model Concepts </li></ul><ul><ul><li>Entities and Attributes </li></ul></ul><ul><ul><li>Entity Types, Value Sets, and Key Attributes </li></ul></ul><ul><ul><li>Relationships and Relationship Types </li></ul></ul><ul><ul><li>Weak Entity Types </li></ul></ul><ul><ul><li>Roles and Attributes in Relationship Types </li></ul></ul><ul><li>ER Diagrams - Notation </li></ul><ul><li>ER Diagram for COMPANY Schema </li></ul><ul><li>Alternative Notations – UML class diagrams, others </li></ul>
  3. 4. Overview of Database Design Process <ul><li>Two main activities: </li></ul><ul><ul><li>Database design </li></ul></ul><ul><ul><li>Applications design </li></ul></ul><ul><li>Focus in this chapter on database design </li></ul><ul><ul><li>To design the conceptual schema for a database application </li></ul></ul><ul><li>Applications design focuses on the programs and interfaces that access the database </li></ul><ul><ul><li>Generally considered part of software engineering </li></ul></ul>
  4. 5. Overview of Database Design Process
  5. 6. Example COMPANY Database <ul><li>We need to create a database schema design based on the following (simplified) requirements of the COMPANY Database: </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>Each department controls a number of PROJECTs. Each project has a unique name, unique number and is located at a single location. </li></ul></ul>
  6. 7. Example COMPANY Database (Contd.) <ul><ul><li>We store each EMPLOYEE’s social security number, address, salary, sex, and birthdate. </li></ul></ul><ul><ul><ul><li>Each employee works for one department but may work on several projects. </li></ul></ul></ul><ul><ul><ul><li>We keep track of the number of hours per week that an employee currently works on each project. </li></ul></ul></ul><ul><ul><ul><li>We also keep track of the direct supervisor of each employee. </li></ul></ul></ul><ul><ul><li>Each employee may have a number of DEPENDENTs. </li></ul></ul><ul><ul><ul><li>For each dependent, we keep track of their name, sex, birthdate, and relationship to the employee. </li></ul></ul></ul>
  7. 8. ER Model Concepts <ul><li>Entities and Attributes </li></ul><ul><ul><li>Entities are specific objects or things in the mini-world that are represented in the database. </li></ul></ul><ul><ul><ul><li>For example the EMPLOYEE John Smith, the Research DEPARTMENT, the ProductX PROJECT </li></ul></ul></ul><ul><ul><li>Attributes are properties used to describe an entity. </li></ul></ul><ul><ul><ul><li>For example an EMPLOYEE entity may have the attributes Name, SSN, Address, Sex, BirthDate </li></ul></ul></ul><ul><ul><li>A specific entity will have a value for each of its attributes. </li></ul></ul><ul><ul><ul><li>For example a specific employee entity may have Name='John Smith', SSN='123456789', Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55‘ </li></ul></ul></ul><ul><ul><li>Each attribute has a value set (or data type) associated with it – e.g. integer, string, subrange, enumerated type, … </li></ul></ul>
  8. 9. Types of Attributes (1) <ul><li>Simple </li></ul><ul><ul><li>Each entity has a single atomic value for the attribute. For example, SSN or Sex. </li></ul></ul><ul><li>Composite </li></ul><ul><ul><li>The attribute may be composed of several components. For example: </li></ul></ul><ul><ul><ul><li>Address(Apt#, House#, Street, City, State, ZipCode, Country), or </li></ul></ul></ul><ul><ul><ul><li>Name(FirstName, MiddleName, LastName). </li></ul></ul></ul><ul><ul><ul><li>Composition may form a hierarchy where some components are themselves composite. </li></ul></ul></ul><ul><li>Multi-valued </li></ul><ul><ul><li>An entity may have multiple values for that attribute. For example, Color of a CAR or PreviousDegrees of a STUDENT. </li></ul></ul><ul><ul><ul><li>Denoted as {Color} or {PreviousDegrees}. </li></ul></ul></ul>
  9. 10. Types of Attributes (2) <ul><li>In general, composite and multi-valued attributes may be nested arbitrarily to any number of levels, although this is rare. </li></ul><ul><ul><li>For example, PreviousDegrees of a STUDENT is a composite multi-valued attribute denoted by {PreviousDegrees (College, Year, Degree, Field)} </li></ul></ul><ul><ul><li>Multiple PreviousDegrees values can exist </li></ul></ul><ul><ul><li>Each has four subcomponent attributes: </li></ul></ul><ul><ul><ul><li>College, Year, Degree, Field </li></ul></ul></ul>
  10. 11. Example of a composite attribute
  11. 12. Entity Types and Key Attributes (1) <ul><li>Entities with the same basic attributes are grouped or typed into an entity type. </li></ul><ul><ul><li>For example, the entity type EMPLOYEE and PROJECT. </li></ul></ul><ul><li>An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type. </li></ul><ul><ul><li>For example, SSN of EMPLOYEE. </li></ul></ul>
  12. 13. Entity Types and Key Attributes (2) <ul><li>A key attribute may be composite. </li></ul><ul><ul><li>VehicleTagNumber is a key of the CAR entity type with components (Number, State). </li></ul></ul><ul><li>An entity type may have more than one key. </li></ul><ul><ul><li>The CAR entity type may have two keys: </li></ul></ul><ul><ul><ul><li>VehicleIdentificationNumber (popularly called VIN) </li></ul></ul></ul><ul><ul><ul><li>VehicleTagNumber (Number, State), aka license plate number. </li></ul></ul></ul><ul><li>Each key is underlined </li></ul>
  13. 14. Displaying an Entity type <ul><li>In ER diagrams, an entity type is displayed in a rectangular box </li></ul><ul><li>Attributes are displayed in ovals </li></ul><ul><ul><li>Each attribute is connected to its entity type </li></ul></ul><ul><ul><li>Components of a composite attribute are connected to the oval representing the composite attribute </li></ul></ul><ul><ul><li>Each key attribute is underlined </li></ul></ul><ul><ul><li>Multivalued attributes displayed in double ovals </li></ul></ul><ul><li>See CAR example on next slide </li></ul>
  14. 15. Entity Type CAR with two keys and a corresponding Entity Set
  15. 16. Entity Set <ul><li>Each entity type will have a collection of entities stored in the database </li></ul><ul><ul><li>Called the entity set </li></ul></ul><ul><li>Previous slide shows three CAR entity instances in the entity set for CAR </li></ul><ul><li>Same name (CAR) used to refer to both the entity type and the entity set </li></ul><ul><li>Entity set is the current state of the entities of that type that are stored in the database </li></ul>
  16. 17. Initial Design of Entity Types for the COMPANY Database Schema <ul><li>Based on the requirements, we can identify four initial entity types in the COMPANY database: </li></ul><ul><ul><li>DEPARTMENT </li></ul></ul><ul><ul><li>PROJECT </li></ul></ul><ul><ul><li>EMPLOYEE </li></ul></ul><ul><ul><li>DEPENDENT </li></ul></ul><ul><li>Their initial design is shown on the following slide </li></ul><ul><li>The initial attributes shown are derived from the requirements description </li></ul>
  17. 18. Initial Design of Entity Types: EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT
  18. 19. Refining the initial design by introducing relationships <ul><li>The initial design is typically not complete </li></ul><ul><li>Some aspects in the requirements will be represented as relationships </li></ul><ul><li>ER model has three main concepts: </li></ul><ul><ul><li>Entities (and their entity types and entity sets) </li></ul></ul><ul><ul><li>Attributes (simple, composite, multivalued) </li></ul></ul><ul><ul><li>Relationships (and their relationship types and relationship sets) </li></ul></ul><ul><li>We introduce relationship concepts next </li></ul>
  19. 20. Relationships and Relationship Types (1) <ul><li>A relationship relates two or more distinct entities with a specific meaning. </li></ul><ul><ul><li>For example, EMPLOYEE John Smith works on the ProductX PROJECT, or EMPLOYEE Franklin Wong manages the Research DEPARTMENT. </li></ul></ul><ul><li>Relationships of the same type are grouped or typed into a relationship type . </li></ul><ul><ul><li>For example, the WORKS_ON relationship type in which EMPLOYEEs and PROJECTs participate, or the MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs participate. </li></ul></ul><ul><li>The degree of a relationship type is the number of participating entity types. </li></ul><ul><ul><li>Both MANAGES and WORKS_ON are binary relationships. </li></ul></ul>
  20. 24. Relationship type vs. relationship set (1) <ul><li>Relationship Type: </li></ul><ul><ul><li>Is the schema description of a relationship </li></ul></ul><ul><ul><li>Identifies the relationship name and the participating entity types </li></ul></ul><ul><ul><li>Also identifies certain relationship constraints </li></ul></ul><ul><li>Relationship Set: </li></ul><ul><ul><li>The current set of relationship instances represented in the database </li></ul></ul><ul><ul><li>The current state of a relationship type </li></ul></ul>
  21. 25. Relationship type vs. relationship set (2) <ul><li>Previous figures displayed the relationship sets </li></ul><ul><li>Each instance in the set relates individual participating entities – one from each participating entity type </li></ul><ul><li>In ER diagrams, we represent the relationship type as follows: </li></ul><ul><ul><li>Diamond-shaped box is used to display a relationship type </li></ul></ul><ul><ul><li>Connected to the participating entity types via straight lines </li></ul></ul>
  22. 26. Refining the COMPANY database schema by introducing relationships <ul><li>By examining the requirements, six relationship types are identified </li></ul><ul><li>All are binary relationships( degree 2) </li></ul><ul><li>Listed below with their participating entity types: </li></ul><ul><ul><li>WORKS_FOR (between EMPLOYEE, DEPARTMENT) </li></ul></ul><ul><ul><li>MANAGES (also between EMPLOYEE, DEPARTMENT) </li></ul></ul><ul><ul><li>CONTROLS (between DEPARTMENT, PROJECT) </li></ul></ul><ul><ul><li>WORKS_ON (between EMPLOYEE, PROJECT) </li></ul></ul><ul><ul><li>SUPERVISION (between EMPLOYEE (as subordinate), EMPLOYEE (as supervisor)) </li></ul></ul><ul><ul><li>DEPENDENTS_OF (between EMPLOYEE, DEPENDENT) </li></ul></ul>
  23. 27. <ul><li>Relationship Types </li></ul><ul><li>Each entity type E1, E2, …, En is said to participate in the relationship type R. </li></ul><ul><li>A relationship type is represented as diamond-shaped box which is connected by straight lines. </li></ul>
  24. 28. Discussion on Relationship Types <ul><li>In the refined design, some attributes from the initial entity types are refined into relationships: </li></ul><ul><ul><li>Manager of DEPARTMENT -> MANAGES </li></ul></ul><ul><ul><li>Works_on of EMPLOYEE -> WORKS_ON </li></ul></ul><ul><ul><li>Department of EMPLOYEE -> WORKS_FOR </li></ul></ul><ul><ul><li>etc </li></ul></ul><ul><li>In general, more than one relationship type can exist between the same participating entity types </li></ul><ul><ul><li>MANAGES and WORKS_FOR are distinct relationship types between EMPLOYEE and DEPARTMENT </li></ul></ul><ul><ul><li>Different meanings and different relationship instances. </li></ul></ul>
  25. 29. Recursive Relationship Type <ul><li>An relationship type whose with the same participating entity type in distinct roles </li></ul><ul><li>Example: the SUPERVISION relationship </li></ul><ul><li>EMPLOYEE participates twice in two distinct roles: </li></ul><ul><ul><li>supervisor (or boss) role </li></ul></ul><ul><ul><li>supervisee (or subordinate) role </li></ul></ul><ul><li>Each relationship instance relates two distinct EMPLOYEE entities: </li></ul><ul><ul><li>One employee in supervisor role </li></ul></ul><ul><ul><li>One employee in supervisee role </li></ul></ul>
  26. 30. <ul><li>Two types of entities: </li></ul><ul><ul><li>Strong entity : can exist independently (or can uniquely identify itself) </li></ul></ul><ul><ul><li>Weak entity : existence depends on the existence of other (strong) entity or entities </li></ul></ul><ul><li>Examples: </li></ul><ul><ul><li>An employee is a strong entity but the dependents of the employee could be weak entities </li></ul></ul><ul><ul><li>An account in a bank is a strong entity but a transaction could be a week entity </li></ul></ul>
  27. 31. A weak entity type is an entity which does not have any key attributes Employee Department Works-for Dependents Dependent Fname Sex Birthdate Relationship identifying relationship
  28. 32. Weak Entity Types <ul><li>An entity that does not have a key attribute </li></ul><ul><li>A weak entity must participate in an identifying relationship type with an owner or identifying entity type </li></ul><ul><li>Entities are identified by the combination of: </li></ul><ul><ul><li>A partial key of the weak entity type </li></ul></ul><ul><ul><li>The particular entity they are related to in the identifying entity type </li></ul></ul><ul><li>Example: </li></ul><ul><ul><li>A DEPENDENT entity is identified by the dependent’s first name, and the specific EMPLOYEE with whom the dependent is related </li></ul></ul><ul><ul><li>Name of DEPENDENT is the partial key </li></ul></ul><ul><ul><li>DEPENDENT is a weak entity type </li></ul></ul><ul><ul><li>EMPLOYEE is its identifying entity type via the identifying relationship type DEPENDENT_OF </li></ul></ul>
  29. 33. Constraints on Relationships <ul><li>Constraints on Relationship Types </li></ul><ul><ul><li>(Also known as ratio constraints) </li></ul></ul><ul><ul><li>Cardinality Ratio (specifies maximum participation) </li></ul></ul><ul><ul><ul><li>One-to-one (1:1) </li></ul></ul></ul><ul><ul><ul><li>One-to-many (1:N) or Many-to-one (N:1) </li></ul></ul></ul><ul><ul><ul><li>Many-to-many (M:N) </li></ul></ul></ul><ul><ul><li>Existence Dependency Constraint (specifies minimum participation) (also called participation constraint) </li></ul></ul><ul><ul><ul><li>zero (optional participation, not existence-dependent) </li></ul></ul></ul><ul><ul><ul><li>one or more (mandatory participation, existence-dependent) </li></ul></ul></ul>
  30. 34. Relationships <ul><li>The role name signifies the role that a participating entity from the entity type plays in each relationship instance. </li></ul>
  31. 35. Cardinality Ratio <ul><li>Specifies the number of relationship instances that an entity can participate in. Common cardinality ratios for binary relationship types are 1:1,1:N, and M:N. </li></ul>
  32. 36. An employee works for one company, and a company has many employees working for it. EMPLOYEE WORKS-FOR COMPANY N 1
  33. 37. A department has one manager and an Employee manages one department. DEPARTMENT Manage EMPLOYEE 1 1
  34. 38. An employee works on many projects, and a project has many employees working on it. EMPLOYEE WORKS-ON PROJECT M N
  35. 39. Participation Constraints <ul><li>Specifies whether the existence of an entity depends on it being related to another entity via the relationship type. There is total and partial participation. </li></ul>
  36. 40. An employee cannot exist without participating in the WORKS-FOR relationship; a department cannot exist without employees. EMPLOYEE WORKS-FOR DEPARTMENT N 1 Total or existence dependency
  37. 41. A person may buy a car and car may be bought by a person Partial participation PERSON Buys CAR 1 N
  38. 42. A professor may manage a department ( partial participation ), but a department must be managed by a professor ( total participation ). PROFESSOR DEPARTMENT 1 N Manages
  39. 43. Structural Constraints on Relationships <ul><li>Cardinality ratio: ( 1:1, 1:N, M:N ) </li></ul><ul><li>Participating constraints ( total or partial ) </li></ul>
  40. 44. Attributes of Relationship types <ul><li>A relationship type can have attributes: </li></ul><ul><ul><li>For example, HoursPerWeek of WORKS_ON </li></ul></ul><ul><ul><li>Its value for each relationship instance describes the number of hours per week that an EMPLOYEE works on a PROJECT. </li></ul></ul><ul><ul><ul><li>A value of HoursPerWeek depends on a particular (employee, project) combination </li></ul></ul></ul><ul><ul><li>Most relationship attributes are used with M:N relationships </li></ul></ul><ul><ul><ul><li>In 1:N relationships, they can be transferred to the entity type on the N-side of the relationship </li></ul></ul></ul>
  41. 45. Attributes of Relationship Types EMPLOYEE DEPARTMENT Works-for 1 N Start-Date We may keep a start date attribute to record for each employee the date he or she started work for a certain department.
  42. 46. Attributes of Relationship Types continued ... Department Manager Manages 1 N Start-Date We may put a start date as an attribute to Department or Manager ; provided that we do not keep historical data.
  43. 47. Notation for Constraints on Relationships <ul><li>Cardinality ratio (of a binary relationship): 1:1, 1:N, N:1, or M:N </li></ul><ul><ul><li>Shown by placing appropriate numbers on the relationship edges. </li></ul></ul><ul><li>Participation constraint (on each participating entity type): total (called existence dependency) or partial. </li></ul><ul><ul><li>Total shown by double line, partial by single line. </li></ul></ul><ul><li>NOTE: These are easy to specify for Binary Relationship Types. </li></ul>
  44. 48. Cardinality Constraint (2) <ul><li>General format: </li></ul><ul><li>0  min_card  max_card </li></ul><ul><ul><li>Interpretation : </li></ul></ul><ul><ul><ul><li>Each entity in E may involve between min_card and max_card relationships in R. </li></ul></ul></ul>R E (min_card, max_card)
  45. 49. Cardinality Constraint (3) <ul><li>Definition: </li></ul><ul><ul><li>If every entity in E involves at least one relationship in R (i.e., min_card >= 1), E is said to have total participation in R </li></ul></ul><ul><ul><li>If min_card = 0, E is said to have partial participation in R </li></ul></ul>
  46. 50. Cardinality Constraint (4) <ul><li>Employees has a partial participation. </li></ul><ul><li>Departments has a total participation. </li></ul>manages Employee (0, 1) (1,1) Department
  47. 51. Representing 1-to-1, 1-to-m, m-to-m Relationships R E (0, 1) (0, 1) F one-to-one: R E (0, m) (0, n) F many-to-many: R E (0, m) (0,1) F one-to-many: R E 1 m F
  48. 52. Recursive Relationship Type is: SUPERVISION (participation role names are shown)
  49. 53. Alternative (min, max) notation for relationship structural constraints: <ul><li>Specified on each participation of an entity type E in a relationship type R </li></ul><ul><li>Specifies that each entity e in E participates in at least min and at most max relationship instances in R </li></ul><ul><li>Default(no constraint): min=0, max=n (signifying no limit) </li></ul><ul><li>Must have min  max, min  0, max  1 </li></ul><ul><li>Derived from the knowledge of mini-world constraints </li></ul><ul><li>Examples: </li></ul><ul><ul><li>A department has exactly one manager and an employee can manage at most one department. </li></ul></ul><ul><ul><ul><li>Specify (0,1) for participation of EMPLOYEE in MANAGES </li></ul></ul></ul><ul><ul><ul><li>Specify (1,1) for participation of DEPARTMENT in MANAGES </li></ul></ul></ul><ul><ul><li>An employee can work for exactly one department but a department can have any number of employees. </li></ul></ul><ul><ul><ul><li>Specify (1,1) for participation of EMPLOYEE in WORKS_FOR </li></ul></ul></ul><ul><ul><ul><li>Specify (0,n) for participation of DEPARTMENT in WORKS_FOR </li></ul></ul></ul>
  50. 54. Summary of notation for ER diagrams
  51. 55. <ul><li>A stored attribute is a one whose value is explicitly stored in the database. </li></ul><ul><ul><li>e.g. name, birth-date. </li></ul></ul><ul><li>Derived -attributes: whose values are computed from other attributes. </li></ul><ul><ul><li>Age from Birthdate </li></ul></ul><ul><ul><li>Annual Salary from Monthly Salary </li></ul></ul><ul><ul><li>NoOfEmployees ==> Count number of employees in the Employee table. </li></ul></ul>
  52. 56. Null Values <ul><li>An attribute may have null as its value. </li></ul><ul><li>Null may mean </li></ul><ul><ul><li>not applicable (college degree) </li></ul></ul><ul><ul><li>Unknown </li></ul></ul><ul><ul><ul><li>Missing (height of Smith) </li></ul></ul></ul><ul><ul><ul><li>Not known (home phone for Smith). </li></ul></ul></ul>
  53. 57. Alternative diagrammatic notation <ul><li>ER diagrams is one popular example for displaying database schemas </li></ul><ul><li>Many other notations exist in the literature and in various database design and modeling tools </li></ul><ul><li>Appendix A illustrates some of the alternative notations that have been used </li></ul><ul><li>UML class diagrams is representative of another way of displaying ER concepts that is used in several commercial design tools </li></ul>
  54. 58. UML class diagrams <ul><li>Represent classes (similar to entity types) as large rounded boxes with three sections: </li></ul><ul><ul><li>Top section includes entity type (class) name </li></ul></ul><ul><ul><li>Second section includes attributes </li></ul></ul><ul><ul><li>Third section includes class operations (operations are not in basic ER model) </li></ul></ul><ul><li>Relationships (called associations) represented as lines connecting the classes </li></ul><ul><ul><li>Other UML terminology also differs from ER terminology </li></ul></ul><ul><li>Used in database design and object-oriented software design </li></ul><ul><li>UML has many other types of diagrams for software design (see Chapter 12) </li></ul>
  55. 59. UML class diagram for COMPANY database schema
  56. 60. Other alternative diagrammatic notations
  57. 61. Relationships of Higher Degree <ul><li>Relationship types of degree 2 are called binary </li></ul><ul><li>Relationship types of degree 3 are called ternary and of degree n are called n-ary </li></ul><ul><li>In general, an n-ary relationship is not equivalent to n binary relationships </li></ul><ul><li>Constraints are harder to specify for higher-degree relationships (n > 2) than for binary relationships </li></ul>
  58. 62. Discussion of n-ary relationships (n > 2) <ul><li>In general, 3 binary relationships can represent different information than a single ternary relationship (see Figure 3.17a and b on next slide) </li></ul><ul><li>If needed, the binary and n-ary relationships can all be included in the schema design (see Figure 3.17a and b, where all relationships convey different meanings) </li></ul><ul><li>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 (and hence multiple owner entity types) (see Figure 3.17c) </li></ul>
  59. 63. Example of a ternary relationship
  60. 64. Discussion of n-ary relationships (n > 2) <ul><li>If a particular binary relationship can be derived from a higher-degree relationship at all times, then it is redundant </li></ul><ul><li>For example, the TAUGHT_DURING binary relationship in Figure 3.18 (see next slide) can be derived from the ternary relationship OFFERS (based on the meaning of the relationships) </li></ul>
  61. 65. Another example of a ternary relationship
  62. 66. Displaying constraints on higher-degree relationships <ul><li>The (min, max) constraints can be displayed on the edges – however, they do not fully describe the constraints </li></ul><ul><li>Displaying a 1, M, or N indicates additional constraints </li></ul><ul><ul><li>An M or N indicates no constraint </li></ul></ul><ul><ul><li>A 1 indicates that an entity can participate in at most one relationship instance that has a particular combination of the other participating entities </li></ul></ul><ul><li>In general, both (min, max) and 1, M, or N are needed to describe fully the constraints </li></ul>
  63. 67. Data Modeling Tools <ul><li>A number of popular tools that cover conceptual modeling and mapping into relational schema design. </li></ul><ul><ul><li>Examples: ERWin, S- Designer (Enterprise Application Suite), ER- Studio, etc. </li></ul></ul><ul><li>POSITIVES: </li></ul><ul><ul><li>Serves as documentation of application requirements, easy user interface - mostly graphics editor support </li></ul></ul><ul><li>NEGATIVES: </li></ul><ul><ul><li>Most tools lack a proper distinct notation for relationships with relationship attributes </li></ul></ul><ul><ul><li>Mostly represent a relational design in a diagrammatic form rather than a conceptual ER-based design </li></ul></ul><ul><ul><li>(See Chapter 12 for details) </li></ul></ul>
  64. 68. Some of the Currently Available Automated Database Design Tools Data modeling, design/reengineering Visual Basic/C++ Visio Enterprise Visio Data modeling, business logic modeling Enterprise Application Suite Sybase Conceptual modeling up to code maintenance Xcase Resolution Ltd. UML Modeling & application generation in C++/JAVA Rational Rose Rational (IBM) Mapping from O-O to relational model Pwertier Persistence Inc. Data, process, and business component modeling Enterprise Modeling Suite: Erwin, BPWin, Paradigm Plus Platinum (Computer Associates) Data modeling, object modeling, process modeling, structured analysis/design System Architect 2001 Popkin Software Database modeling, application development Developer 2000/Designer 2000 Oracle Database administration, space and security management DB Artisan Database Modeling in ER and IDEF1X ER Studio Embarcadero Technologies FUNCTIONALITY TOOL COMPANY
  65. 69. Extended Entity-Relationship (EER) Model (in next chapter) <ul><li>The entity relationship model in its original form did not support the specialization and generalization abstractions </li></ul><ul><li>Next chapter illustrates how the ER model can be extended with </li></ul><ul><ul><li>Type-subtype and set-subset relationships </li></ul></ul><ul><ul><li>Specialization/Generalization Hierarchies </li></ul></ul><ul><ul><li>Notation to display them in EER diagrams </li></ul></ul>
  66. 70. Chapter Summary <ul><li>ER Model Concepts: Entities, attributes, relationships </li></ul><ul><li>Constraints in the ER model </li></ul><ul><li>Using ER in step-by-step conceptual schema design for the COMPANY database </li></ul><ul><li>ER Diagrams - Notation </li></ul><ul><li>Alternative Notations – UML class diagrams, others </li></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×