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 06269-3155steve@engr.uconn.edu

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?