Chaps3&4-1
CSE 4701
Chapters 3 & 4 5e, 7 & 8 6e: The ER Model
Prof. Steven A. Demurjian, Sr. Computer Science & Engineering Department
The University of Connecticut191 Auditorium Road, Box U-155
Storrs, CT [email protected]
http://www.engr.uconn.edu/~steve(860) 486 - 4818
A large portion of these slides have been adapted from the AWL web site for the textbook.
The remainder of these slides are being used with the permission of Dr. Ling Lui, Associate Professor, College of Computing, Georgia Tech.
Chaps3&4-2
CSE 4701
Information System Design
Chaps3&4-3
CSE 4701
Data vs. Information
Chaps3&4-4
CSE 4701
The ER Model and its extensions ER Diagrams- Notation Example Database Application (COMPANY) ER Model Concepts
Entities and Attributes Entity Types, Value Sets, and Key Attributes Relationships and Relationship Types Weak Entity Types Roles and Attributes in Relationship Types
Relationships of Higher Degree Extended Entity-Relationship (EER) Model Notation is based on :
R. Elmasri and S.B. Navathe, “ Fundamentals of Database Systems,” Ed. 3., Addison Wesley, 2000, Chapters 3 and 4.
Chaps3&4-5
CSE 4701
Summary of ER-Diagram NotationMeaning
ENTITY TYPE
WEAK ENTITY TYPE
RELATIONSHIP TYPE
IDENTIFYING RELATIONSHIP TYPE
ATTRIBUTE
KEY ATTRIBUTE
MULTIVALUED ATTRIBUTE
COMPOSITE ATTRIBUTE
DERIVED ATTRIBUTE
TOTAL PARTICIPATION OF E2 IN R
CARDINALITY RATIO 1:N FOR E1:E2 IN R
STRUCTURAL CONSTRAINT (min, max) ON PARTICIPATION OF E IN R
Symbol
E1 R E2
E1 RN E2
R(min,max)
E
N
Chaps3&4-6
CSE 4701
Example COMPANY Database Requirements of the Company (Oversimplified for
Illustrative Purposes) Company is Organized into Departments
Each Department has a Name, Number and an Employee Who Manages the Department
We Track of the Start Date of the Department Manager Each Department Controls a Number of Projects
Each Project has a Name, Number and is Located at a Single Location
Chaps3&4-7
CSE 4701
Example COMPANY Database (Cont.) 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 Track of the Number of Hours Per Week that an
Employee Currently Works on Each Project We Track of the Direct Supervisor of Each Employee
Each Employee May have a Number of Dependents For Each Dependent, We Track of their Name, Sex,
Birthdate, and Relationship to Employee
Chaps3&4-8
CSE 4701
ER Diagram for the Company Database
Chaps3&4-9
CSE 4701
ER Model Concepts: Entities and Attributes Entities - Specific Objects or Things in the Mini-world
that are Represented in the Database EMPLOYEE John Smith Research DEPARTMENT Productx PROJECT
Attributes are Properties Used to Describe an Entitye.g., an EMPLOYEE Entity may have a Name, SSN, Address, Sex, Birthdate
A Specific Entity (Instance) has a Value for Each of its Attributes Specific Employee Entity May Have Name=‘John
Smith’, SSN=‘123456789’, Address=‘731 Fondren, Houston, TX’, Sex=‘m’, Birthdate=‘09-jan-55’
Chaps3&4-10
CSE 4701
Three Types of Attributes Simple: Single Atomic Value for the Attribute
SSN or Sex or State or Salary or ... Composite: Attribute Composed of Many Components
Address (Apt#, House#, Street, City, State, Zipcode, Country) or Name(Fname, MI, Lname)
Composition May form a Hierarchy where Some Components are Themselves Composite
Multi-Valued: Entity may have Multiple Values for That Attribute - Like an Set Type CAR {Color} or STUDENT {Previousdegrees}
Composite and Multi-valued Attributes may be Nested Arbitrarily to any Number of Levels (Rare) Previousdegrees of a STUDENT is a Composite
Multi-valued Attribute Denoted by {Previousdegrees(college, Year, Degree, Field)}
Chaps3&4-11
CSE 4701
Entities with Attribute Values
Chaps3&4-12
CSE 4701
Entity Types and Key Attributes Entities with the Same Basic Attributes Are Grouped
or Typed into an Entity Type EMPLOYEE Entity Type or PROJECT Type
Attribute of Entity Type for which Each Entity Must Have a Unique Value is Called a Key Attribute SSN of EMPLOYEE, ISBN of BOOK
A Key Attribute may be Composite VIN is a Key of the CAR Entity Type
An Entity Type may have More than One Key CAR Entity Type May Have Two Keys:
VIN Vehicletagnumber (Number, State) aka License Plate
Chaps3&4-13
CSE 4701
car1
((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1989, (red, black))car2
((ABC 123, NEW YORK), WP9872, Nissan Sentra, 2-door, 1992, (blue))car3
((VSY 720, TEXAS), TD729, Chrysler LeBaron, 4-door, 1993, (white, blue))
.
.
.
CARRegistration(RegistrationNumber, State), V_ID, Make, Model, Year, (Color)
Entity Type CAR with Attributes
Chaps3&4-14
CSE 4701
Two Other Entity Types
Chaps3&4-15
CSE 4701
Relationships and Relationship Types A Relationship Relates Two or More Distinct Entities
With a Specific Meaning EMPLOYEE John Smith Works on the Productx
PROJECT EMPLOYEE Franklin Wong Manages the
Research DEPARTMENT Relationship - Instance Level
Relationships of the Same Type are Grouped or Typed Into a Relationship Type WORKS_ON Relationship Type in Which
Employees and Projects Participate MANAGES Relationship Type in Which
Employees and Departments Participate Analogous to Reference or List in Programming
Chaps3&4-16
CSE 4701
The WORKS_ON Relationship
Chaps3&4-17
CSE 4701
Relationships and Relationship Types Degree of a Relationship Type is the Number of
Participating Entity Types Both MANAGES and WORKS_ON are Binary
Relationships What is a possible Ternary Relationship?
More Than One Relationship Type Can Exist With the Same Participating Entity Types MANAGES and WORKS_FOR are Distinct
Relationships Between EMPLOYEE and DEPARTMENT Entity Types
Relationships are Directional SUPPLIES: SUPPLIER to PARTS SUPPLIERS: PARTS to SUPPLIER
Chaps3&4-18
CSE 4701
E-R Diagrams
EMPLOYEE PROJECT
Responsibility
Duration
Budget
ProjectName
Project NoEmployee No EmployeeName
SalaryTitle
WORKS ON
Address
CityApt. #
Street #
NoEmp
Location
Chaps3&4-19
CSE 4701
Weak Entity Types Entity that Does Not have a Key Attribute 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 Particular Entity they Are Related to in the
Identifying Entity Type Example:
A DEPENDENT Entity is Identified by Dependent’s First Name and Birthdate, and the EMPLOYEE That the Dependent is Related to
DEPENDENT is a Weak Entity Type With EMPLOYEE as its Identifying Entity Type Via the Identifying Relationship Type DEPENDENT_OF
Chaps3&4-20
CSE 4701
ER Model and Data Abstraction Abstraction Classification
Aggregation
Identification Generalization
ER Model Concept Entity Type - a Grouping of Member Entities Relationship Type - a Grouping of Member
Relationships Relationship Type is an Aggregation of (Over) Its
Participating Entity Types Weak Entity Type and Attribute Key ????????
Chaps3&4-21
CSE 4701
Constraints on Aggregation Cardinality Constraints on Relationship Types
AKA Ratio Constraints Maximum Cardinality
One-to-One One-to-Many Many-to-Many
Minimum Cardinality (AKA Participation or Existence Dependency Constraints) Zero (Optional Participation, Not Existence-Dependent) One or More (Mandatory, Existence-Dependent)
Chaps3&4-22
CSE 4701
e1
e2
e3
e4
e5
e6
e7
EMPLOYEE
r1
r2
r3
r4
r5
r6
r7
WORKS_FOR
d1
d2
d3
DEPARTMENT
One-to-many(1:N) or Many-to-one (N:1)
Chaps3&4-23
CSE 4701
e1
e2
e3
e4
e5
e6
e7
r1
r2
r3
r4
r5
r6
r7
d1
d2
d3
r8
r9
MANY-TO-MANY(M:N)
Chaps3&4-24
CSE 4701
One-to-One WORKS_ON Relationship
WORKS_ONRelationship
Instances
EMPLOYEE Set PROJECT Set
Chaps3&4-25
CSE 4701
EMPLOYEE PROJECT
Responsibility
Duration
Budget
ProjectName
Project NoEmployee No EmployeeName
SalaryTitle
WORKS ON1 1
One-to-One Relationship Each Instance of One Entity Class E1 Can Be
Associated with Exactly One Instance of Another Entity Class E2 and Vice Versa.
Example: Each Employee Can Work in Exactly One Project
and Each Project Employs Exactly One Employee
Chaps3&4-26
CSE 4701
One-to-Many WORKS_ON Relationship
Chaps3&4-27
CSE 4701
EMPLOYEE PROJECT
Responsibility
Duration
Budget
ProjectName
Project NoEmployee No EmployeeName
SalaryTitle
WORKS ON1N
Many-to-One Relationship Each Instance of One Entity Class E1 can be
Associated with Zero or More Instances of Another Entity Class E2, but Each Instance of E2 can be Associated With at Most 1 Instance of E1
Example : Each Employee Can Work in Exactly One Project
Each Project Can Employ Many Engineers
Chaps3&4-28
CSE 4701
Many-to-Many WORKS_ON Relationship
Chaps3&4-29
CSE 4701
EMPLOYEE PROJECT
Responsibility
Duration
Budget
ProjectName
Project NoEmployee No EmployeeName
SalaryTitle
WORKS ONN M
Many-to-Many Relationship Each Instance of One Entity Class Can Be Associated
with Many Instances of Another Entity Class, and vice versa
Example: Each Employee Can Work in Many Projects
Each Project Can Employ Many Employees
Chaps3&4-30
CSE 4701
Structural Constraints Structural Constraints on a Relationship are One Way
to Express the Semantics of a Relationship Cardinality Ratio (of a Binary Relationship): 1:1, 1:N,
N:1, or M:N Shown by Placing Apropos Number on the Link
Participation Constraint (on Each Entity Type): Total (Called Existence Dependency) or Partial Shown By Double Lining The Link
NOTE: Easy to Specify for Binary Relationship Types Do Not Be Misled by Obscure Notations to
Specify Above Constraints for Higher Order Relationships
Chaps3&4-31
CSE 4701
Alternative (min, max) Notation Alternative (Min, Max) Notation for Relationship
Structural Constraints Introduces Limits Specified on Each Participation of an Entity Type E in
a Relationship Type R Specifies That Each Entity E in Participates in at Least
Min and at Most Max Relationship Instances in R Default (no Constraint): Min = 0, Max = n Must Have Min max, Min 0, Max 1
Derived From the Knowledge of Mini-World Constraints
Chaps3&4-32
CSE 4701
Examples: Alternative (min, max) Notation 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 Dept. 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
Chaps3&4-33
CSE 4701
Examples: Alternative (min, max) Notation
What does it mean to put m:n:p on the three arms of the relationship? It is essentially meaningless. The (min,max) notation “looking away” from the entity is the best to use.
(1,1)(0,1)
(1,N)(1,1)
Chaps3&4-34
CSE 4701
Relationships of Higher Degree Relationship Types of Degree 2 Are Called Binary Relationship Types of Degree 3 Are Called Ternary
There is a Concrete Relationship Instance that Involves all Three Entity Types
These are Not Separate Relationships! Relationship Types of Degree N Are Called N-ary
Again - Concrete n-Participation Relationship In General, an N-ary Relationship is Not Equivalent to
N Binary Relationships Rather - it is more Analogous to the Grouping of
N-Binary Relationships into a N-ary Relationship
Chaps3&4-35
CSE 4701
Ternary Relationships
Chaps3&4-36
CSE 4701
Ternary Relationships
Chaps3&4-37
CSE 4701
Ternary vs. Binary Relationships
Chaps3&4-38
CSE 4701
Constraints on Higher Order Relationships
What does it mean to put m:n:p on the three arms of the relationship ?
How do you set up the instance level diagram between actual suppliers, projects, and parts?
mn
p
Chaps3&4-39
CSE 4701
Higher Order (min,max) Examples
A Teacher can offer min 1 and max 2 OfferingsA Course may have 1 to 3 OfferingsA Student may enroll in from 1 to 5 Offerings
(1,5)
(1,3)(1,2)
Chaps3&4-40
CSE 4701
s1
s2
SUPPLIER
p1
p2
p3
PART
r1
r2
r3
r4
r5
r6
r7
SUPPLY
j1
j2
j3
PROJECT
Ternary Relationships - Instances
Chaps3&4-41
CSE 4701
Modified Earlier Example
Chaps3&4-42
CSE 4701
Another ER Diagram - Bank Example
Chaps3&4-43
CSE 4701
ER Data Modeling Tools Many Popular Existing Tools Advantages:
Documentation of Application Requirements User Interface - Mostly Graphics Editor Support
Disadvantages: Poor Diagramming
To Avoid Layout Algorithms and Aesthetics of Diagrams, They Prefer Boxes and Lines and Typically Only Represent (Primary-foreign Key) Relationships Among Resulting Tables
Lack of Built-in Methodology Support Poor Tradeoff Analysis/User-driven Design Preferences Poor Design Verification/Suggestions for Improvement
Chaps3&4-44
CSE 4701
Data modeling, design and reengineering Visual Basic and Visual C++
Visio EnterpriseVisio
Data modeling, business logic modelingEnterprise Application SuiteSybase
Conceptual modeling up to code maintenanceXcaseResolution Ltd.
Mapping from O-O to relational modelRW MetroRogue Ware
Modeling in UML and generation in C++ and JAVATogether has support for limited ER Design
Rational RoseTogether Control Center
RationalTogether/Borland
Mapping from O-O to relational modelPwertierPersistence Inc.
Data, process, and business component modelingPlatinum Enterprice Modeling Suite: Erwin, BPWin, Paradigm Plus
Platinum Technology
Data modeling, object modeling, process modeling, structured analysis/design
System Architect 2001Popkin Software
Database modeling, application developmentDeveloper 2000 and Designer 2000
Oracle
Database administration and space and security management
DB Artisan
Database Modeling in ER and IDEF1XER StudioEmbarcadero Technologies
FUNCTIONALITYTOOLCOMPANY
Current ER Modeling Tools
Chaps3&4-45
CSE 4701
ER Design Topics Clear Distinction of the Usage of Entity and Attribute,
As Well As Entity and Relationship Clear Understanding of Complications in ER
Modeling Recursive Relationship Multiple Relationships Between Two Entity Types Participation Constraints (Existence Constraints) Strong and Weak Entities Relationships Among More than two Entity Types Connection Traps Simplification Techniques
Chaps3&4-46
CSE 4701
Interactions of Entity/Relationships Types In a Recursive Relationship two Entities of the Same
Entity Type Are Related SUPERVISION Relationship Type Relates One
EMPLOYEE (in the Role of Supervisee) to Another EMPLOYEE (in the Role of Supervisor)
Similarly, the Same Entity Type May Play Different Roles in Different Relationships Employee Plays the Role
A Relationship Type Can Have Attributes HoursPerWeek of WORKS_ON Value for Relationship Instance Describes # of
hrs/week an EMPLOYEE Works on a PROJECT
Chaps3&4-47
CSE 4701
Recursive Relationships
EMPLOYEE
MANAGES
1 N
Manager Subordinate
PART
CONTAIN
M N
Made-up of Consists of
Chaps3&4-48
CSE 4701
Understanding Multiple Relationships
EMPLOYEE PROJECT
ResponsibilityDuration
Budget
ProjectName
Project NoEmployee No EmployeeName
SalaryTitle
WORKS ON
N M
MANAGES
1 1
Chaps3&4-49
CSE 4701
Strong and Weak Entity Types Strong Entities:
Instances of the Entity Class Can Exist on their Own, Without Participating in any Relationship
Also Called Non-obligatory Membership
Weak Entities: Each Instance of the Entity
Class Has to Participate in a Relationship in Order to Exist
Keys Are Imported From Dependent Entity
Also Called Obligatory Membership
Special Type of Total Participation
Course
number-of- sessions
instructorsession#
1
n
C-S
Session
Chaps3&4-50
CSE 4701
Higher Order Relationships
SUPPLIERPROJECT
DateAmount
Budget
ProjectName
Project NoSupplier No Supplier
Name
LocationCredit SUPPLY
NM
PART
LPart No
PartName
QTY
WGT
Three way relationships
Chaps3&4-51
CSE 4701
Connection Traps A N-ary Relationship cannot be Replaced by
a Number of Binary Relationships (Loss of Information)
(Supplier,Project,Part)< > (Project,Supplier)+(Supplier,Part)+(Project,Part)
So, (a) < > (b)! There are no Easy Solutions to this
Problem!
Chaps3&4-52
CSE 4701
Connection Traps - Example 2 Example: Each Division Has Multiple Depts. and Many
Employees , Each Employee Works for One Dept. in a Div., and Each Dept. is Within a Div. and Has Many Employees
Be Careful in Defining and Interpreting Relationships For Example, Consider the Following Diagram
Can We Find, for Any Given Emp., Which Dept. He is in? Conversely, Can We Find, for a Given Dept., Which Emps.
are in that Dept.?
DIVISION
DEPARTMENT EMPLOYEE
1
N
1
N
INCLUDESDEPT
INCLUDESEMP
Chaps3&4-53
CSE 4701
Example 2 - One Solution Change the Relationship Definition Division to Dept. and Dept. to Employee Replaces
Division to Dept. and Division to Employee
DIVISION
DEPARTMENT
EMPLOYEE
1
N 1
N
INCLUDESDEPT
INCLUDESEMP
Chaps3&4-54
CSE 4701
Many-to-Many Simplification Technique Cannot do by Simple Creation of two 1:N
Relationships Between the Two Entity Classes N:M Relationship Does Not Indicate a Dependence
Between Instances of the Two Entity Classes 1:N Relationship Forces a Dependency
Consider N:M Between EMPLOYEE and PROJECTN M
EMPLOYEE PROJECTWORKS ON
EMPLOYEE PROJECT
WORKS ON N
M EMPLOYS
1
1
WRONG
Chaps3&4-55
CSE 4701
Many-to-Many Simplification Technique Treat the Relationship as an Entity Class Define Suitable Relationships Among Three Entities This Simplification is not Necessary for Mapping into
the Relational Model, but is Important for Mapping into Other Models (Relational/Implementation)
EMPLOYEE PROJECTWORKS ONN M
EMPLOYEE PROJECT
EMP--EMP1
M
EMP--PROJ
EMPLOYMENT M
1
Chaps3&4-56
CSE 4701
What are Problems with ER Notation? Historically, ER Model 1st Proposed in 1976
P. Chen, ''The Entity-Relationship Model - Toward a Unified View of Data,'' ACM Trans. on Database Systems, Vol. 1, No. 1, March 1976.
However, ER Model in this Original Form Did Not Support the Generalization Abstraction (Inheritance)
In Databases, Inheritance 1st Proposed in 1977 J. Smith and D. Smith, ''Database Abstractions:
Aggregation and Generalization,'' ACM Trans. on Database Systems, Vol. 2, No. 2, June 1977.
Thus, Extended ER Evolved through 1980s with the Focus on “Semantic Data Models”
M. Hammer and D. McLeod, ''Database Descriptions with SDM: A Semantic Data Model,'' ACM Trans. on Database Systems, Vol. 6, No. 3, Sept. 1981.
Chaps3&4-57
CSE 4701
Enhanced ER Model Object-Oriented Extensions to E-R Model EER Concepts
Specialization Attribute Inheritance Generalization Subclasses Superclasses Constraints on Specialization and Generalization Categorization
Chaps3&4-58
CSE 4701
Specialization/Attribute Inheritance An Entity Type E1 is a Specialization of
another Entity Type E2 if E1 has the Same Properties of E2 and Perhaps Even More.
E1 IS-A E2
MANAGER
EMPLOYEE
EMPLOYEE
Employee No EmployeeName
Salary
Title Address
MANAGER
Employee No EmployeeName
Salary
Title Address
Expense Act. Condo
Chaps3&4-59
CSE 4701
Generalization Abstracting the Common Properties of Two
or More Entities to Produce a “Higher-level” Entity
ENGINEER SECRETARY SALESPERSON
Employee NoEmployee Name
SalaryTitle
Address
Employee NoEmployee Name
SalaryTitle
Address
Employee NoEmployee Name
SalaryTitle
Address
ProjectOffice Office
SpecialtyCarRegion
EMPLOYEE Employee NoEmployee Name
SalaryTitle
Address
Chaps3&4-60
CSE 4701
Generalization
ENGINEER SECRETARY SALESPERSON
EMPLOYEE
Employee No EmployeeName
Salary
Title Address
Project Office Specialty Office CarRegion
d
Chaps3&4-61
CSE 4701
Constraints
disjoint, total
disjoint, partiald
d
o
o
overlapping, total
overlapping, partial
Part
Manufactured_Part
Purchased_Part
o
PartNo Description
SupplierName ListPrice
BatchNo
M_date
DrawingNo
Chaps3&4-62
CSE 4701
Total and Partial Disjoint
EMPLOYEE
Employee No EmployeeName
Salary
Title Address
SECRETARYENGINEER
Project Office Specialty Office
SALESPERSON
CarRegion
dd
HOURLY_EMP
SALARIED_EMP
Hourly Rate
Salary
Chaps3&4-63
CSE 4701
Total Overlapping
PART
Part No PartName
QTY
WGT
o
MANUFACTURED_PART PURCHASED_PART
Batch No Drawing No Price
Chaps3&4-64
CSE 4701
Categories A Category is a Subclass
of a Union of Two or More Entity Types.
The Concept of Category Superclass
Relationship with Two or More Superclasses
A Category Can Be Total or Partial
PERSON BANK COMPANY
OWNER
u
REG_VEHICLE
CAR TRUCK
u
OWNS
N
M
OWNER and REG_VEHICLE
are both categories
Chaps3&4-65
CSE 4701
Enhanced ER Constructs and Notation
Chaps3&4-66
CSE 4701
Chaps3&4-67
CSE 4701
Chaps3&4-68
CSE 4701
Chaps3&4-69
CSE 4701
Chaps3&4-70
CSE 4701
UML for System Modeling UML is a Language for Specifying, Visualizing,
Constructing, and Documenting Software Artifacts What Does a Modeling Language Provide?
Model Elements: Concepts and Semantics Notation: Visual Rendering of Model Elements Guidelines: Hints and Suggestions for Using
Elements in Notation References and Resources
Web: www.rational.com/uml/documentation.html “The Unified Modeling Language Reference
Manual”, Addison-Wesley, 1999. “UML Toolkit”, Eriksson and Penker, John Wiley
& Sons, Inc, New York, 1998.
Chaps3&4-71
CSE 4701
Use-Case Diagrams
Chaps3&4-72
CSE 4701
Class Diagram
Chaps3&4-73
CSE 4701
Class Diagram (part 2 - Under Item)
Chaps3&4-74
CSE 4701
Object Diagram Captures Instances and Links
Chaps3&4-75
CSE 4701
Component Diagram Captures the Physical Structure of the Implementation
Chaps3&4-76
CSE 4701
Deployment Diagram Captures the Topology of a System’s Hardware
Chaps3&4-77
CSE 4701
Sequence Diagram
Chaps3&4-78
CSE 4701
Statechart Diagram Captures Dynamic Behavior (Event-Oriented)
Chaps3&4-79
CSE 4701
Activity Diagram Captures Dynamic Behavior (Activity-Oriented)
Chaps3&4-80
CSE 4701
Concluding Remarks Database Design is one Aspect of the Overall Software
Engineering Process Software Specification Software Architecture Database Requirements and Model UML Use-Cases Detailed Design (Classes, etc.)
The ER Model and EER Model are Excellent Conceptual Modeling Vehicles What is the Data? What are Data Dependencies? How will Data be Used?