Database Systems

Week 5: Entity relationship

model and entity-relationship
diagrams
The Entity Relationship (ER) Model
• ER model forms the basis of an ER diagram
• ERD represents a conceptual database as viewed by the end user
• ERDs depict the database’s main components:
• Entities: A “thing” or “object” in the real world that is distinguishable from
other objects.
• Attributes: A property of an entity
• Relationships: An association among several entities.
The Entity Relationship (ER) Model
• Peter Chen introduced the ER data model in 1976; the graphical
representation of entities and their relationships in a database
structure quickly became popular because it complemented the
relational data model concepts.
• The relational data model and ERM combined provide the foundation
for tightly structured database design.
• Crow's foot notation, the beginning of which dates back to an
article by Gordon Everest (1976).
The Entity Relationship (ER) Model
The Entity Relationship (ER) Model
The Entity Relationship (ER) Model
• Increasingly complex real-world problems demonstrated a need for a
data model that more closely represented the real world.
• In the object-oriented data model (OODM), both data and its
relationships are contained in a single structure known as an object.
• In turn, the OODM is the basis for the object-oriented database
management system (OODBMS).
Evolution of Data Models
 Evolution of Data Models

Study Table 2.2 for advantages

and disadvantages of these
famous data models.
Entities
• Refers to entity set and not to single entity occurrence
• Corresponds to table and not to row in relational environment
• In both Chen and Crow’s Foot models, entity is represented by
rectangle containing entity’s name
• Entity name, a noun, is usually written in capital letters
Attributes
• Characteristics of entities
• Sometimes referred to as properties
• In Chen model, attributes are represented by ovals and are connected
to entity rectangle with a line
• Each oval contains the name of attribute it represents
• In Crow’s Foot model, attributes are written in attribute box below
entity rectangle
Attributes
Primary Keys
• Underlined in the ERD
• Key attributes are also underlined in frequently used table structure
shorthand
• For example, a CAR entity may be represented by

CAR (CAR_VIN, MOD_CODE, CAR_YEAR, CAR_COLOR)

The Entity Relationship (E-R) Model
• Classes of Attributes
• A simple attribute cannot be subdivided.
• Examples: Age, Gender, and Marital status
• A composite attribute can be further subdivided to yield additional attributes.
• Examples:
• ADDRESS  Street, City, State, Zip
• PHONE NUMBER  Area code, Exchange number
• NAME  last, first, Middle
The Entity Relationship (E-R) Model
• Classes of Attributes
• A single-valued attribute can have only a single value.
• Examples:
• A person can have only one CNIC number.
• A manufactured part can have only one serial number.
• A student can only have one GPA
• Multivalued attributes can have many values.
• Examples:
• A person may have several college degrees.
• A household may have several phones with different numbers
• Cars can have multiple colors
• Multivalued attributes are shown by a double line connecting to the entity.
The Entity Relationship (E-R) Model
• Multivalued Attribute in Relational DBMS
• relational DBMS cannot implement multivalued attributes.
• Possible courses of action for the designer
• create several new attributes, one for each of the original multivalued attribute’s
components (Figure 4.4).
• Create a new entity composed of the original multivalued attribute’s components (Figure
4.5).
Multivalued Attributes
Multivalued Attributes
Resolving Multivalued Attribute Problems
The Entity Relationship (E-R) Model
• A derived attribute is not physically stored within the database; instead, it is
derived (calculated) by using an algorithm.
• Example: AGE can be derived from the data of birth and the current date.
• Could be stored in DB if you understand the trade-off and decide it is worth it
Derived Attributes
The Entity Relationship (E-R) Model
• Cardinality
• Cardinality expresses the specific number of entity occurrences associated
with one occurrence of the related entity.
Crow’s Foot Symbols
Existence Dependence
• Existence dependence
• Exist in database only when it is associated with another related entity
occurrence
• Means FK cannot be null
• Existence independence
• Entity can exist apart from one or more related entities
• Sometimes refers to such an entity as strong or regular entity
Relationship Strength
• Weak (non-identifying) relationships
• Exists if PK of related entity does not contain PK component of parent entity
(related PK is only the FK)
• Strong (Identifying) Relationships
• Exists when PK of related entity contains PK component of parent entity
Weak (Non-Identifying) Relationships
Weak (Non-Identifying) Relationships
Strong (Identifying) Relationships
Weak Entities
• Weak Entities
• A weak entity is an entity that
• Is existence-dependent and
• Has a primary key that is partially or totally derived from the parent entity in the
relationship.
• Hence the weak entity is the dependent entity involved in a strong (identifying)
relationship
• The existence of a weak entity is indicated by a double rectangle. (in Chen
notation)
• The weak entity inherits all or part of its primary key from its strong
counterpart.
Weak Entities
Relationship Participation
• Optional participation
• One entity occurrence does not require corresponding entity occurrence in
particular relationship
• Mandatory participation
• One entity occurrence requires corresponding entity occurrence in particular
relationship
Relationship Participation
Relationship Participation
Relationship Participation
Relationship Degree
• Indicates number of entities or participants associated with a
relationship
• Unary relationship
• Association is maintained within single entity
• Binary relationship
• Two entities are associated
• Ternary relationship
• Three entities are associated
Three Degrees of Relationships
Three Degrees of Relationships
Three Degrees of Relationships
Three Degrees of Relationships
Composite Entities
Composite Entities
Relationship Degree
Recursive Relationships
• Relationship can exist between occurrences of the same entity set
• Naturally found within unary relationship
Recursive Relationships
Recursive Relationships
Recursive Relationships
Recursive Relationships
Recursive Relationships
Composite Entities
• Also known as bridge entities
• Composed of primary keys of each of the entities to be connected
• May also contain additional attributes that play no role in connective
process
Developing an ER Diagram
• Database design is an iterative rather than a linear or sequential
process
• begins with a general narrative (problem description)
• Iterative process
• E-R model is created and presented for review.
• process repeated until the end users and designers agree
Developing an ER Diagram
• Building an ERD usually involves the following activities:
• Create detailed narrative of organization’s description of operations
• Identify business rules based on description of operations
• Identify main entities and relationships from business rules
• Develop initial ERD
• Identify attributes and primary keys that adequately describe entities
• Revise and review ERD
Database Design Challenges: Conflicting
Goals
• Database design must conform to design standards – avoidance of
redundancy / protection against inconsistency.
• High processing speeds are often a top priority in database design –
may lead to fewer tables than would be ideal design.
• Quest for timely information might be focus of database design.