0% found this document useful (0 votes)
20 views

8 A Data Modeling

Uploaded by

jonathanablang3
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
20 views

8 A Data Modeling

Uploaded by

jonathanablang3
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 62

Data Modeling

It is a process used to define and analyze


data requirements needed to support the business
processes within the scope of corresponding
information systems in organizations.
It is a technique for organizing and documenting a
system’s data. Sometimes called database modeling
Gathering Information for 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

 Although conceptual model can handle M:N


relationships and multivalued attributes, you
should not implement them in relational DBMS
 Within original entity, create several new
attributes, one for each of the original
multivalued attribute’s components
Can lead to major structural problems in table
 Create new entity composed of original
multivalued attribute’s components
Resolving Multivalued Attribute Problems
(continued)
Resolving Multivalued Attribute
Problems (continued)
Resolving Multivalued Attribute Problems
(continued)
Derived Attributes
Attribute whose value may be calculated (derived)
from other attributes
Need not be physically stored within database
Can be derived by using an algorithm
Derived Attributes (continued)
Derived Attributes (continued)

Database Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel
Key fields

Used to organize, access, and maintain


data structures
Four types of keys
Primary keys
Foreign keys
Candidate keys
Secondary keys
Primary keys

An attribute or combination of attributes


that uniquely identifies each row
Foreign keys

A field in one file that matches a


primary key value in another file
A foreign key need not be unique
Candidate keys

Any field that could serve as primary


key
Also called minimal superkey
Example
License Number, SSS Number
Secondary keys

A field or combination of fields that can


be used to access or retrieve records

Secondary keys do not need to be


unique
Relationships
 A relationship is a logical link between entities based on how they
interact
 Association between entities
 Participants are entities that participate in a relationship
 Relationships between entities always operate in both directions
 Relationship classification is difficult to establish if know only one side
of the relationship
Relationships

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.

 Each sales representative writes many invoices.


 Each invoice is written by one sales representative
 Each sales representative is assigned to one
department
 Each department has many sales representatives
 Each customer may generate many invoices
 Each invoice is generated by one invoice

You might also like