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
Example: Category Relationship
3753 X2 - 2004 27
Example: Category Relationship
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
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
Attributes (cont’d)
Single Professor Employee ID#
Multi-Valued Professor Email
3753 X2 - 2004 47
Attributes (cont’d)
Stored Professor Start Date
Derived Professor Years Teaching
3753 X2 - 2004 48
Attributes (cont’d)
• 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
Constraints on Relationship Types
• 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
Constraints on Relationship Types
• 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
Constraints on Relationship Types
• 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
Constraints on Relationship Types
• 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
Constraints on Relationship Types
• 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
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
HOTEL-INVOICE INVOICE-DETAILHAS 1 N
INVOICE NUMBER
ARRIVAL DATE
TOTAL
ITEM COST
ITEM DATE
ITEM CATEGORY
HAS
1
N
INVOICE-CUSTOME
CUSTOMER NAME
3753 X2 - 2004 92
Example 3
HOTEL-INVOICE INVOICE-DETAILHAS 1 N
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
Top Related