Data Modeling Using the

Entity-Relationship (ER)
Model
From Fundamentals of Database
Systems by Elmasri/Navathe
Database Design

 Requirements collection and analysis

 Document data requirements
 Functional requirements
 User-defined operations (or transactions – including
retrievals and updates)
 Conceptual Design
 Using a high level conceptual data model
 Concise description of the data requirements
 Entities, relationships and constraints
Database Design (cont’d)
 Conceptual Design (cont’d)
 Not concerned with implementation/storage details
 (High-Level) Confirm that conceptual schema meets the
identified functional requirements
 Logical Design (data model mapping)
 Map conceptual schema to an implementation data model
(e.g., relational database model)
 Physical Design
 Specify internal storage structures, indices, access paths
and file organizations
ER Model
 Describes data as
 Entities
 Relationships
 Attributes
 Types of Attributes
 Simple (Atomic) vs Composite Attributes
 Single-Valued vs Multi-Valued Attributes
 Stored vs Derived Attributes
 Complex Attributes (nested composite/multi-valued)
 () composite attribute components
 {} multi-valued
Example: Person can have more than one residence, and each residence
can have a single address and multiple phones. Both phone and address
are themselves composite attributes.
NULL values

 Used when a particular entity may not have

an applicable value for an attribute
 e.g., apartment number in address
 Or missing/not-known information
 Sales data for a dept that has not been submitted
 Home phone
Intension (entity type describes the schema or intension)
Extension of the entity type (collection of entities of a particular
entity type grouped into an entity set)
Key Attributes of an Entity Type

 Key (uniqueness constraint on attributes)

 Key attribute The attribute whose values are
distinct for each entity in the entity set
 Composite key
 Combination of several attribute values form a key
 Note: such a key must be minimal
 May have more than one key
 Constraint on all extensions of the entity type
Entity Type
 Strong Entity Types
 Entity types that have a key attribute

 Weak Entity Type

 Entities that do not have key attributes of their own

 Entities are identified by being related to another entity type

(identifying or owner entity type) in combination with one of their

attribute values
 Normally has a partial key (set of attributes that can uniquely

identify weak entities that are related to some owner entity)

 e.g. if we assume no two dependents have same name, “name”
attribute is a partial key
 In order to identify uniquely we need to have the primary key of
the owner entity
 (e.g. dependents – name)
Value Sets (Domains) of Attributes

 Each simple attribute is associated with a

value set (or domain of values)
 Specify the set of values that may be
assigned to that attribute
 e.g. value set for name attribute: set of strings of
alphabetic characters separated by blank chs.
 Not displayed in ER diagrams
 Specified using data types: basic (integer etc.) or
additional (date/time etc.)
Relationships

 Implicit relationships between entity types are

represented as “relationships” in the ER
model
 A relationship type R among n entity types
E1, E2, …, En defines a set of associations –
or a relationship set – among entities from
these entity types
 Each of the individual entities is said to
participate in the relationship
Relationships (cont’d)
 Degree of a relationship type is the number of
participating entity types
 A relationship type of degree of two is called binary
 of three is called ternary
 Role Names:
 Each entity type that participates in a relationship plays a
particular role in the relationship
 Recursive Relationship
 Same entity type participates more than once in a
relationship with different roles (e.g., supervision
relationship)
Constraints on Relationship Types
 Cardinality Ratios for Binary Relationships
 Specifies the maximum number of relationship instances
that an entity can participate in
 e.g., 1:1, 1:N, M:N
 Participation Constraints
 Specifies the minimum number of relationship instances
that each entity can participate in (minimum cardinality
constraint)
 Total Participation (Existence Dependencies)
 Partial Participation
 Structural constraints of a relationship type
(Cardinality ratio and participation constraints)