Conceptual Modeling and Entity-Relationship Diagrams Chapter 3: Elmasri/Navathe

Conceptual Modeling andEntity-Relationship Diagrams

Chapter 3: Elmasri/Navathe

3753 X2 - 2004 2

Outline

• Phases of Database Design

• Conceptual Modeling

• Abstractions in Conceptual Design

• Example Database Requirements

• Deconstructing the E-R Diagram– Entities, Attributes and Relationships– Participation, Cardinality and Keys

3753 X2 - 2004 3

Phases of Database Design

Requirements Analysis

Conceptual Design

Data Model Mapping

Physical Design

Application Domain

Database Requirements

Conceptual Schema

Implementation Schema

Physical Schema

DBMSIndependent

DBMSDependent

3753 X2 - 2004 4

A Data Modeling Process

• Steps in the data modeling process– Plan project– Determine requirements– Specify entities– Specify relationships– Determine identifiers– Specify attributes– Specify domains– Validate model

3753 X2 - 2004 5

Planning the Project

• Obtaining project authorization and budget

• Building the project team

• Planning the team’s activities

• Establishing tools, techniques, and standards for consistent results

• Defining the project’s scope

3753 X2 - 2004 6

Determining System Requirements

• Sources for data modeling requirements– User interviews and user activity observations– Existing forms and reports– New forms and reports– Existing manual files– Existing computer files/databases– Formally defined interfaces (XML)– Domain expertise

• The result of the requirements determination will be a repository of notes, diagram, forms reports, files, etc., that can be used to develop the data model

3753 X2 - 2004 7

Specifying Entities

• An entity is something that the users want to track; something the users want to keep data about

• Entities – can be physical things or logical concepts– are identifiable; you can tell one from another– are things described by nouns, not characteristics

described by adjectives

3753 X2 - 2004 8

Specifying Relationships

• Includes:– Identity of the parent and child entities– Relationship type– Minimum and maximum cardinalities– Name of the relationships

• Two techniques:– Examine whether a relationship exists between every

combination of two entities – Locate relationships from requirement documents

• A combination of the two approaches may be used

3753 X2 - 2004 9

Determining Identifiers

• Identifier is an attribute or group of attributes that uniquely identifies an entity instance

• If there is difficulty specifying an identifier, maybe: – it should be part of a different entity– it is a subtype or category of a common entity– it needs one or more identifying relationships

3753 X2 - 2004 10

Specifying Attributes and Domains

• Find attributes on forms, reports, existing files, etc., and add them to entities

• Determine whether the attribute has already defined a domain– If so, the attribute is based upon that domain– If not, a new domain is defined

• Review the domains and make adjustments as necessary• Domain property inheritance: when the domain properties change,

all the attribute properties change as well• Domains may be used to enforce data standards promoting

compatible data types and systems• Once all attributes have been specified the model should be

reviewed for missing entities

3753 X2 - 2004 11

Validating Model

• Data model is a model of humans’ models, not a model of reality

• A data model is wrong if it does not accurately reflect the ways the users think about their world

• Data models are validated through a series of reviews – Normally, a team review is followed by user reviews

• E-R model as well as prototypes of forms and reports may be used to communicate to users features of the data model

3753 X2 - 2004 12

Creating Data Models From Forms and Reports

• Example: Single entities

3753 X2 - 2004 13

Example: Identifying Connection Relationships

3753 X2 - 2004 14

Example: Repeating Groups

3753 X2 - 2004 15

Example: Repeating Groups

3753 X2 - 2004 16

Example: Nested Groups

3753 X2 - 2004 17

Example: Non-Identifying Connection Relationships

• Example: 1:1

3753 X2 - 2004 18

Example: Non-Identifying Connection Relationships

3753 X2 - 2004 19

Example: 1:N

3753 X2 - 2004 20

Example: 1:N

3753 X2 - 2004 21

Example: 1:N

3753 X2 - 2004 22

Example: N:M

3753 X2 - 2004 23

Example: Assignment Relationship

3753 X2 - 2004 24

Example: Assignment Relationship

3753 X2 - 2004 25

Example: Category Relationship

3753 X2 - 2004 26


3753 X2 - 2004 27


3753 X2 - 2004 28

Sales-Order Model

3753 X2 - 2004 29

Example: Sales Order

3753 X2 - 2004 30

Example: Sales Order

• Figure 3-16(c) shows an alternative design that allows an item to appear more than once on a given order

3753 X2 - 2004 31

Conceptual Design

• Similar to the analysis phase in software development– produce a description of the data– capture the semantics of the data

• Description in a high-level model– close to the user’s view of the world– abstract concepts– means of communication between the user and the

developer

3753 X2 - 2004 32

Reasons for Conceptual Modeling

• Independent of DBMS.• Allows for easy communication between

end-users and developers.• Has a clear method to convert from high-

level model to relational model.• Conceptual schema is a permanent

description of the database requirements.

3753 X2 - 2004 33

Abstractions in Conceptual Design

• An abstraction is a mental process where we select some set of properties of an object and exclude others.

• 3 types of abstractions– classification– aggregation– generalization

3753 X2 - 2004 34

Classification

• Define a class of real-world objects with common properties

Month

DecemberFebruaryJanuary …

3753 X2 - 2004 35

Aggregation

• Define a new class from a set of other classes that represent component parts

Car

Tires Steering Wheel Engine Gas pedal

3753 X2 - 2004 36

Generalization

• Defines a subset relationship between elements of 2 or more classes

Faculty Staff

Employee

Person

Student

3753 X2 - 2004 37

Entity-Relationship Model

• Most popular conceptual model for database design

• Basis for many other models

• Describes the data in a system and how that data is related

• Describes data as entities, attributes and relationships

3753 X2 - 2004 38

Database requirements

• We must convert the written database requirements into an E-R diagram

• Need to determine the entities, attributes and relationships.– nouns = entities– adjectives = attributes– verbs = relationships

3753 X2 - 2004 39

Academic Teaching Database

Design an E-R schema for a database to store info about professors, courses and course sections indicating the following:

• The name and employee ID number of each professor• The salary and email address(es) for each professor• How long each professor has been at the university• The course sections each professor teaches• The name, number and topic for each course offered• The section and room number for each course section• Each course section must have only one professor• Each course can have multiple sections

Professor

Name

First

Last

Course

Employee ID Start Date Years Teaching

Name

Room

Topic

teaches1 N Section

Section ID

Part of

1

N

Number

Email

Visual View of the Database

Salary

3753 X2 - 2004 41

The Pieces

• Objects– Entity (including weak entities)– Attribute– Relationship

• “Structural” Constraints– Cardinality– Participation

3753 X2 - 2004 42

Entities

• Entity – basic object of the E-R model– Represents a “thing” with an independent

existence– Can exist physically or conceptually

• a professor, a student, a course

• Entity type – used to define a set of entities with the same properties.

3753 X2 - 2004 43

Entity and Entity Types

EntityNumber: 3753Name: Database Management SystemsTopic: Introduction to DBMSs

Entity TypeCourse

Number Topic

Name

3753 X2 - 2004 44

Attributes

• Each entity has a set of associated properties that describes the entity. These properties are known as attributes.

• Attributes can be:– Simple or Composite– Single or Multi-valued– Stored or Derived– NULL

3753 X2 - 2004 45

Attributes (cont’d)

Simple Professor Start Date

Composite Professor Name

First

Last

3753 X2 - 2004 46


Single Professor Employee ID#

Multi-Valued Professor Email

3753 X2 - 2004 47


Stored Professor Start Date

Derived Professor Years Teaching

3753 X2 - 2004 48


• NULL attributes have no value– not 0 (zero) – not a blank string

• Attributes can be “nullable” where a null value is allowed, or “not nullable” where they must have a value.

3753 X2 - 2004 49

Primary Keys

• Employee ID is the primary key

• Primary keys must be unique for the entity in question

Professor Employee ID

3753 X2 - 2004 50

Relationships

• defines a set of associations between various entities

• can have attributes to define them

• are limited by:– Participation– Cardinality Ratio

3753 X2 - 2004 51

Relationships (cont’d)

Section Coursepart of

3753 X2 - 2004 52

Participation

• Defines if the existence of an entity depends on it being related to another entity with a relationship type.– Partial– Total

Section Coursepart of

3753 X2 - 2004 53

Concepts and Notations (cont)Relationship

• A relationship R among n entity types E1,E2, .. En defines a set of associations (relationship set) among entities from these types.

• A relationship has its type and set (instances).• Each instance in R is an association of

entities, where the association includes exactly one entity from each participating entity type.

• The reference from entity to another should be represented in the ER model as a relationship not as attributes.

3753 X2 - 2004 54

Concepts and Notations (cont)• In ER diagram, relationship types are displayed as

diamond-shaped boxes, which are connected by straight lines to the rectangular boxes representing the participating entity types.

e1 •e2 •e3 •e4 •e5 •

.

.

.

• d1

• d2

• d3

.

.

.

r1

r2

r3

r4

r5

DEPARTMENT

EMPLOYEE WORKS_FOR

3753 X2 - 2004 55

Concepts and Notations (cont)Degree of relationship type: it is the number of

participating entity type (binary, ternary, .).

Ex: the next figure is a ternary relationship.

s1 •s2 •s3 •..

• j1

• j2

• j3

.

.

.

r1

r2

r3

r4

r5

PROJECT

SUPPLIER SUPPLY

p1 •p2 •p3 •

.

.

PART

3753 X2 - 2004 56

Constraints on Relationship Types

• Cardinality Ratio: it specifies the number of relationship instances that an entity can participate in.

– There is three types:• 1:1 (one-to-one) relationship.• 1:N (one-to-many) relationship.• M:N (many-to-many) relationship.

3753 X2 - 2004 57


• 1:1 (one-to-one) relationship:

e1 •e2 •e3 •e4 •e5 •

.

.

.

• d1

• d2

• d3

.

.

.

r1

r2

r3

r4

r5

DEPARTMENT

EMPLOYEE

MANGES

3753 X2 - 2004 58


• 1:N (one-to-many):

e1 •e2 •e3 •e4 •e5 •

.

.

.

• d1

• d2

• d3

.

.

.

r1

r2

r3

r4

r5

DEPARTMENT

EMPLOYEE

WORKS_FOR

3753 X2 - 2004 59


• M:N (many-to-many):

e1 •e2 •e3 •e4 •e5 •

.

.

.

• p1

• p2

• p3

.

.

.

r1

r2

r3

r4

r5

PROJECT

EMPLOYEE

WORKS_ON

3753 X2 - 2004 60


• Types of participation constraints:

1. Total participation (Mandatory):– Every entity must be related to an instance

in the relationship..– It is represented in the ER by a double line

connecting the participating entity type to the relationship.

– It is also called the existence dependency.– The “Works-For” relationship illustrates

how Employee is total participated in the relationship.

3753 X2 - 2004 61


• Types of participation constraints:

2. Partial participation (Optional):– Part (some) of the entities are related to

some instances in the relationship.– It is represented in the ER by a single line

connecting the entity to the relationship.– Employee is partially participated in

“Manages”.

3753 X2 - 2004 62

Attributes of Relationship Types

• Relationship types can also have attributes (e.g. “Works-On” may have attributes as hours, start_date, ..etc).

3753 X2 - 2004 63

Cardinality

• The number of relationships that an entity may participate in.– 1:1, 1:N, N:M, M:1

Section Coursepart of1N

3753 X2 - 2004 64

Weak entity

• Weak entities do not have key attributes of their own.

• Weak entities cannot exist without another a relationship to another entity.

• A partial key is the portion of the key that comes from the weak entity. The rest of the key comes from the other entity in the relationship.

• Weak entities always have total participation as they cannot exist without the identifying relationship.

3753 X2 - 2004 65

Weak Entity (cont’d)

Section

Course

part of

Number

Section ID

Identifying Relationship

Professor

Name

First

Last

Course

Employee ID Start Date Years Teaching

Name

Room

Topic

teaches1 N Section

Section ID

Part of

1

N

Number

Email

Review of the E-R Diagram

Salary

3753 X2 - 2004 67

University DB Case Study

• Maintain the following information about undergrad students:– Name, address, student number, date of

birth, year of study, degree program (BA, BSc, BCS), concentration (Major, Honours, etc) and department of concentration.

• Note: An address is composed of a street, city, province and postal code; the student number is unique for each student

3753 X2 - 2004 68

University Case Study (cont’d)

• Maintain information about departments– Name, code (CS, Phy), office phone, and faculty

members

• Maintain information about courses:– Course number (3753), title, description,

prerequisites.

• Maintain information about course sections:– Section (A, B, C), term (X1), slot #, instructor

3753 X2 - 2004 69

University Case Study (cont’d)

• Maintain information about faculty:– Name, rank, employee number, salary, office

number, phone number and email address.– Note: employee number is unique

• Maintain a program of study for the current year for each student:– i.e. courses that each student is enrolled in

3753 X2 - 2004 70

ER conventions

Entity

Weak Entity

Attribute

MultivaluedAttribute

Derived Attribute

Key Attribute

Relation

1 N 1:N Relation

Total Participation

(Mandatory)

Partial Participation

(Optional)Composite Attribute

3753 X2 - 2004 71

Extended E-R Model

• E-R model is sufficient for traditional database applications

• Nontraditional applications (CAD, multimedia) have more complex requirements

• Can extend traditional E-R diagrams with semantic data modeling concepts

3753 X2 - 2004 72

IS-A Relationship (cont’d)

Employee

Staff Faculty

Teaching Assistant

S.I.N.

Student #Rank

d

Position

Name

3753 X2 - 2004 73

Specialization & Generalization

• Specialization– process of taking an entity and creating

several specialized subclasses

• Generalization– process of taking several related entities

and creating a general superclass

• We will talk mainly of specialization, but most information will also apply to generalization

3753 X2 - 2004 74

Specialization constraints

• Specializations can be predicate-defined or attribute-defined (otherwise called user-defined)

• Disjointness constraint – specialization is disjoint or overlapping

• Completeness constraint – specialization is total or partial

3753 X2 - 2004 75

Predicate-defined subclass

• An attribute value is used to determine the members of a subclass

• Not all members of every subclass can be determined by the attribute value

• In the following example, the Pension Plan type can be used to determine faculty from staff, but has no effect on students or those who opted out of the pension plan.

3753 X2 - 2004 76

Predicate-defined subclass

Employee

Staff Faculty

S.I.N.

Rank

d

Position

Pension Plan Type

Note: not all employees included

3753 X2 - 2004 77

Attribute-defined subclass

• There is one defining attribute for all subclasses

• Each member of the superclass can be assigned to the appropriate subclass based on this one attribute

3753 X2 - 2004 78

Attribute-defined subclass

Employee

Staff Faculty

S.I.N.

Rank

d

Rank

Jobtype

Students

Year

Jobtype

“Staff”

“Faculty”

“Student”

3753 X2 - 2004 79

User-defined subclass

• When there is no condition to automatically determine membership in a subclass, it must be done at the discretion of the user.

3753 X2 - 2004 80

Disjointness constraint

• Specifies that an entity can be a member of at most one subclass

• There can be no overlap between the subclasses

• We use the notation of a d in a circle to symbolize that the subclasses are disjoint

3753 X2 - 2004 81

Disjoint constraint

Employee

StaffFaculty

Teaching Assistant

S.I.N.

Student #Rank

d

Position

Name

3753 X2 - 2004 82

Overlap

• Entities are able to belong to more than one subclass

• Notation is an o inside of a circle

3753 X2 - 2004 83

Overlap

Employee

Staff Faculty

S.I.N.

Rank

o

Rank

Jobtype

Students

Year

A staff member mayalso be a student

3753 X2 - 2004 84

Completeness Constraint

• May be total or partial• for total, every entity in the superclass

must belong to a subclass• for partial, entities in the superclass do not

need to be part of any subclass• notation for total and partial are the same

as in a regular E-R diagram – single and double lines

3753 X2 - 2004 85

Partial

Employee

Staff Faculty

S.I.N.

Rank

o

Rank

Jobtype

Students

Year

3753 X2 - 2004 86

Total

Employee

Staff Faculty

S.I.N.

Rank

o

Rank

Jobtype

Students

Year

3753 X2 - 2004 87

Hierarchies and Lattices

• Hierarchies– a tree-like structure where each subclass

belongs to only one superclass– everything we have seen so far is a hierarchy

• Lattices– a graph-like structure where a subclass can

belong to more than one superclass

3753 X2 - 2004 88

Lattice

Person

Teaching Assistant

StudentEmployee

o

name

course

student #

salary

3753 X2 - 2004 89

3753 X2 - 2004 90

مثال

HOTEL-INVOICE INVOICE-DETAILHAS 1 N

INVOICE NUMBERCUSTOMER

NAME

ARRIVAL DATE

TOTAL

ITEM COST

ITEM DATE

ITEM CATEGORY

3753 X2 - 2004 91

Example 2


INVOICE NUMBER

ARRIVAL DATE

TOTAL

ITEM COST

ITEM DATE

ITEM CATEGORY

HAS

1

N

INVOICE-CUSTOME

CUSTOMER NAME

3753 X2 - 2004 92

Example 3


INVOICE NUMBER

ARRIVAL DATE

TOTAL

CATEGORY TOTAL

ITEM DATE

ITEM CATEGORY

HAS

1

N

INVOICE-DETAIL-SUB

SUB-CATEGORY

NAME

CATEGORY COST

3753 X2 - 2004 93

Example 3

FISHING-LICENSE

License number

namecitystreet

state

telephone

COMMERCIAL-LICENSE SPORT-LICENSE

dVessel numbername

type

taxid

numberyearsatthisaddress

prioryearlicensenumber

3753 X2 - 2004 94

Example 4

3753 X2 - 2004 95

Continue example 4

CUSTOMERSALES PERSON

SALES-ORDER

ORDER-LINE-ITEM ITEM

HASHAS

CONTAIN

HAS

NAMEADDRESS

STATE

CITY

ZIP

PHONE

SALESPERSONNAME

SALESPERSONCODE

SALESORDERNUMBER

DATE

SUBTOTAL

TAXTOTAL

LINE NUMBER

QUANTITY

UNIT PRICEEXTENDED

PRICE

ITEM NUMBER

UNIT PRICE DESCRIPTION

Documents

Conceptual Modeling and Entity-Relationship Diagrams Chapter 3: Elmasri/Navathe