Entity-Relationship (ER) Modeling
Database Design Process
ConceptualModel
LogicalModel
External Model
Conceptual requirements
Conceptual requirements
Conceptual requirements
Conceptual requirements
Application 1
Application 1
Application 2 Application 3 Application 4
Application 2
Application 3
Application 4
External Model
External Model
External Model
Internal Model
Stages in Database Design
• Requirements formulation and analysis
• Conceptual Design -- Conceptual Model
• Implementation Design -- Logical Model
• Physical Design --Physical Model
Database Design Process
• Requirements formulation and analysis– Purpose: Identify and describe the data that
are used by the organization– Results: Metadata identified, Data Dictionary,
Conceptual Model-- ER diagram
Database Design Process
• Requirements Formulation and analysis– Systems Analysis Process
• Examine all of the information sources used in existing applications
• Identify the characteristics of each data element– numeric
– text
– date/time
– etc.
• Examine the tasks carried out using the information• Examine results or reports created using the information
Conceptual ModelingObjective: to produce HIGH-LEVEL DATA MODEL
GOALSGOALS– a complete understanding of the database structure,
meaning (semantics), interrelationships, and constraints– A stable description of the database contents– Usually more expressive and general than data models
of individual DBMSs– Vehicle of communication among database users,
designers, and analysts.
Database Design Process
• Conceptual Model– Merge the collective needs of all applications– Determine what Entities are being used
• Some object about which information is to maintained
– What are the Attributes of those entities?• Properties or characteristics of the entity• What attributes uniquely identify the entity
– What are the Relationships between entities• How the entities interact with each other?
Database Design Process
• Logical Model– How is each entity and relationship
represented in the Data Model of the DBMS• Hierarchic?• Network?• Relational?• Object-Oriented?
Database Design Process
• Physical ( Internal) Model– Choices of index file structure– Choices of data storage formats– Choices of disk layout
Database Design Process
• External Model– User views of the integrated database – Making the old (or updated) applications work
with the new database design
Data Models: History
• Relational Model (1980’s)– Provides a conceptually simple model for data
as relations (typically considered “tables”) with all data visible.
Book ID Title pubid Author id1 Introductio 2 12 The history 4 23 New stuff ab 3 34 Another title 2 45 And yet more 1 5
pubid pubname1 Harper2 Addison3 Oxford4 Que
Authorid Author name1 Smith2 Wynar3 Jones4 Duncan5 Applegate
Subid Subject1 cataloging2 history3 stuff
Book ID Subid1 22 13 34 24 3
Data Models: History
• Object Oriented Data Model (1990’s)– Encapsulates data and operations as
“Objects”
Books(id, title)
Publisher SubjectsAuthors
(first, last)
Intro. to ER Models
• Entity/Relationship approach - one of the most well known modeling methods
• Developed by P.Chen in 1976 - many variations since then
• Data modeling is generally considered the most important component of the systems development process
A Simple ERD:
Consider the following situation
A customer places an order. The order consists of parts.
Customer
Entity
An Organization about which we wish to maintain
information
Places
Relationship
An Association between Entities
Orders
Another Entity
Contain
Another Relationship
Parts
Altogether, a Database
Entity Relationship Diagrams
Entity type
Weak entity type
Relationship type
IdentifyingRelationship type
Attribute
Key attribute
Multivalued attribute
Derived attribute
Composite attribute
ER NOTATION
Relationship degrees specify number of entity types involved
Entity symbols
A special entity that is also a relationship
Relationship symbols
Relationship cardinalities specify how many of each entity type is allowed
Attribute symbols
Entity
• An Entity is an object in the real world (or even imaginary worlds) about which we want or need to maintain information– Persons (e.g.: customers in a business,
employees, authors)– Things (e.g.: purchase orders, meetings,
parts, companies)
Employee
Inappropriate entities
System userSystem user System outputSystem output
Appropriate entities
Figure 3-4
Identifiers (Keys)
• Identifier (Key) - An attribute (or combination of attributes) that uniquely identifies individual instances of an entity type
• Simple Key versus Composite Key• Candidate Key – an attribute that could be
a key…satisfies the requirements for being a key
Characteristics of Identifiers
• Will not change in value
• Will not be null
• No intelligent identifiers (e.g. containing locations or people that might change)
Attributes
• Attributes are the significant properties or characteristics of an entity that help identify it and provide the information needed to interact with it or use it. (This is the Metadata for the entities.)
Employee
Last
Middle
First
Name SSN
Age
Birthdate
Projects
Figure 3-7 – A composite attribute
An attribute broken into component parts
Weak Entities
• Owe existence entirely to another entity
Order-lineContainsOrder
Invoice #
Part#
Rep#
QuantityInvoice#
Figure 3-9a – Simple key attribute
The key is underlined
Figure 3-9b – Composite key attribute
The key is composed of two subparts
Figure 3-8 – Entity with a multivalued attribute (Skill) and derived attribute (Years_Employed)
Derived from date employed and current date
What’s wrong with this?
Multivalued: an employee can have more than one skill
Relationships
• Relationships are the associations between entities. They can involve one or more entities and belong to particular relationship types
Relationships
ClassAttendsStudent
PartSuppliesproject
partsSupplier
Project
Relationships
ClassAttendsStudent
PartSuppliesproject
partsSupplier
Project
Types of Relationships
• Concerned only with cardinality of relationship
TruckAssignedEmployee
ProjectAssignedEmployee
ProjectAssignedEmployee
1 1
n
n
1
m
Chen ER notation
Other Notations
TruckAssignedEmployee
ProjectAssignedEmployee
ProjectAssignedEmployee
“Crow’s Foot”
Degree of Relationships
• Degree of a relationship is the number of entity types that participate in it–Unary Relationship–Binary Relationship–Ternary Relationship
Degree of relationships – from Figure 3-2
One entity related to another of the same entity type
Entities of two different types related to each other Entities of three
different types related to each other
Cardinality of Relationships
• One-to-One– Each entity in the relationship will have exactly one
related entity
• One-to-Many– An entity on one side of the relationship can have
many related entities, but an entity on the other side will have a maximum of one related entity
• Many-to-Many– Entities on both sides of the relationship can have
many related entities on the other side
Cardinality Constraints
• Cardinality Constraints - the number of instances of one entity that can or must be associated with each instance of another entity
• Minimum Cardinality– If zero, then optional– If one or more, then mandatory
• Maximum Cardinality– The maximum number