8 A Data Modeling
8 A Data Modeling
Two perspectives
Top-down
Data model is derived from an intimate understanding of the
business.
Bottom-up
Data model is derived by reviewing specifications and business
documents.
The Entity Relationship (ER) Model
ER model forms the basis of an ER diagram
ERD represents conceptual database as viewed by
end user
ERDs depict database’s main components:
Entities
Attributes
Relationships
The Entity Relationship Model
The Entity Relationship Model
Data Model Basic Building Blocks
Entity: a person, place, thing, or event
for which data is collected and maintained
Attribute: a characteristic of an entity
Relationship:
Relationship describes an association
among entities
Entity
Entity – a class of persons, places, objects,
events, or concepts about which we need to
capture and store data.
Named by a singular noun
Persons: agency, contractor, customer,
department, division, employee,
instructor, student, supplier.
Places: sales region, building, room,
branch office, campus.
Objects: book, machine, part, product, raw material, software
license, software package, tool, vehicle.
Events: application, award, cancellation, class, flight, invoice,
order, registration, renewal, requisition, reservation, sale, trip.
Concepts: account, block of time, bond, course, fund, qualification,
stock.
8-7
Attributes
Attribute – a descriptive
property or characteristic of an
entity.
8-8
Attributes
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
Domains
Attributes have domain
Domain is attribute’s set of possible values
Attributes may share a domain
Identifiers (Primary Keys)
Underlined in the ERD
Key attributes are also underlined in frequently used
table structure shorthand
STUDENT(studno, studname, stud_dob)
Types of Attributes
Composite attribute
Simple attribute
Single-value attribute
Multi-valued attribute
Derived attribute
Composite and Simple Attributes
Composite attribute can be subdivided
Simple attribute cannot be subdivided
Single-Valued Attributes
Single-value attribute can have only a single value
Multivalued Attributes
Multivalued attributes can have many values
Multivalued Attributes (continued)
Resolving Multivalued Attribute
Problems
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel
Key fields
Types of relationships
1. One-to-one (1:1)
2. One-to-many (1:M)
3. Many-to-many (M:N)
One-to-one (1:1) relationship
Exists when exactly one of the second entity occurs for each
instance of the first entity
One-to-one (1:1) relationship
EMPLOYEE
EMP_NO EMP_NAME
1 Tim Mc Key
2 Pining Garcia
3 Juan Dela Cruz
4 Juana Change
DEPARTMENT
DEPT_CODE DEPT_NAME EMP_NO
111 CASHIERING 1
222 ACCOUNTING 2
333 INFORMATION 3
SYSTEMS
One-to-many (1:M) relationship
Exists when one occurrence of the first entity can be related to
many occurrences of the second entity, but each occurrence of
the second entity can be associated with only one occurrence of
the first entity
One-to-many (1:M) relationship
DEPARTMENT
DEPT_CODE DEPT_NAME
111 ICT
222 ME
333 EE
STUDENT
STUD_NO STUD_NAME DEPT_CODE
1 Tim Mc Key 111
2 Pining Garcia 111
3 Juan Dela Cruz 333
4 Juana Change 222
Many-to-many (M:N) relationship
Exists when one instance of the first entity can be related to many
instances of the second entity, and one instance of the second
entity can be related to many instances of the first
Connectivity and Cardinality
Connectivity
Used to describe the relationship classification
Cardinality
Expresses minimum and maximum number of entity
occurrences associated with one occurrence of related
entity
Established by very concise statements known as
business rules
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel
Connectivity and Cardinality
(continued)
Relationship Strength
Weak (non-identifying) relationships
Exists if PK of related entity does not contain PK
component of parent entity
Strong (Identifying) Relationships
Exists when PK of related entity contains PK component
of parent entity
Weak (Non-Identifying) Relationships
Strong (Identifying) Relationships
Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel
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 (continued)
Relationship Participation (continued)
Relationship Participation
(continued)
Relationship Participation
(continued)
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
Relationship Degree (continued)
Relationship Degree (continued)
Recursive Relationships
Relationship can exist between occurrences of the
same entity set
Naturally found within unary relationship
Recursive Relationships
(continued)
Recursive Relationships
(continued)
Recursive Relationships
(continued)
Recursive Relationships
(continued)
Recursive Relationships
(continued)
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
Composite Entities (continued)
Composite Entities (continued)
Composite Entities (continued)
Create a Chen’s notation ERD to include the
ff business rules for the ProdCo company.
A department employs many employees, but each employee
is employed by one department.
A division operates many departments, but each department
is operated by one division.
An employee may be assigned many projects,
Create a Crows foot ERD to include the ff
business rules for the ProdCo company.