CIT365 Database Systems

Data Models

Course Instructor:
Dr. Ikbal Taleb

©2017 Cengage Learning®. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part, except for use as permitted in a license distributed with a
certain product or service or otherwise on a password-protected website or school-approved learning management system for classroom use.
 2

In this lecture, you will learn:

• Why data models are important

• About the basic data-modeling building
blocks
• What business rules are and how they
influence database design
• How the major data models evolved
• How data models can be classified by level of
abstraction

2
2

3
 2

Modeling
• A model is an abstraction (representation) of
a more complex real-world object or event.
• Types of Models
– Physical
– Narrative
– Graphical
– Mathematical

4
 2

Data Models

• Data models are generally

– Relatively simple representations, usually

graphical, of complex real-world data
structures.

5
 2

Importance of Data Models

https://youtu.be/Vn9BUfUCL4I
• End-users have different views and needs for
data
• Data model organizes data for various users
• Facilitate interaction among the designer, the
applications programmer, and the end users

6
 2

Data Models (General Overview)

Real-life Real-World
Oriented Object-Oriented Entity-Relationship
(End Users)
Models
1

SQL Schema

3
Computer
Oriented Network Hierarchical Relational
Models

7
 2

Sample Data Model

(Entity-Relationship)
8
 2

Data Model Basic Building Blocks

• Entity:
• anything about which data are to be collected and stored
E.g: customer, flight routes
• Attribute:
• a characteristic of an entity
• E.g: customer last name, customer first name
• Relationship:
• describes an association among entities
» One-to-many (1:M) relationship
» Many-to-many (M:N or M:M) relationship
» One-to-one (1:1) relationship
• Constraint:
• a restriction placed on the data
9
 2

First Step!

• How to properly identify entities, attributes,

relationships, and constraints?
– The first step is to identify the business rules
of the environment we are modeling.

10
 2

Business Rules

• A business rule is
– a brief, precise, and unambiguous description of a
policy, procedure, or principle within a specific
organization

– Apply to any organization that stores and uses data to

generate information
– Business rules, derived from a detailed description of
an organization’s operations, help to create and
enforce actions within that organization’s operational
environment

11
 2

Sample business rules

• The company needs to record data about its

customers.
(entity)

• Customer data are Customer_ID, First_name,

Last_name, Telephone, Home_address, e_mail.
(attributes)

• A customer may generate many invoices.

• An invoice is generated by only one customer.
(relationship)

• A training session cannot be scheduled for fewer than

10 employees, or for more than 30 employees.
(constraint)

12
 2

Exercise # 1
• Write business rules based on the data stored
in the following tables:

Linked through AGENT_CODE

14
14
 Sources of Business Rules

Company Department
Policy makers
managers managers

Direct
Written
interviews
documentation
with end users

©2017 Cengage Learning®. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part, except for use as permitted in a license distributed with a
certain product or service or otherwise on a password-protected website or school-approved learning management system for classroom use.
15
 2
Translating Business rules into Data
model components
• Generally, nouns translate into entities
• Verbs translate into relationships among
entities
• Relationships are bi-directional
• Example:
– A customer may generate many invoices.
– An invoice is generated by only one customer.

17
 2

• Example:
– A customer may generate many invoices.
– An invoice is generated by only one customer.

0, M
1,1
CUSTOMER generate INVOICE

18
 2

Overview of Data Models

1. Hierarchical
2. Network
3. Relational
4. Object oriented (OO)
5. XML

20
 2

The Relational Model

• Developed by Codd (IBM) in 1970

• Considered ingenious but impractical in 1970
• Conceptually simple
• Computers lacked power to implement the
relational model
• Today, microcomputers can run sophisticated
relational database software

21
 2

The Relational Model (continued)

• Table (relations)
– Matrix consisting of a series of row/column
intersections
– Related to each other through sharing a
common entity characteristic

22
 2
The Relational Model (continued)

23
 2

The Relational Model (continued)

• Relational Table
– Stores a collection of related entities
• Resembles a file
• Relational table is purely logical structure
– How data are physically stored in the
database is of no concern to the user or the
designer
– This property became the source of a real
database revolution

24
 2
The Relational Model (continued)
Relational diagram
Representation of relational database’s entities, attributes within
those entities, and relationships between those entities

25
 2

The Relational Model (continued)

• Dominance due in part to its powerful and flexible

query language
• Structured Query Language (SQL) allows the user to
specify what must be done without specifying how it
must be done
• SQL-based relational database application involves:
– User interface
– A set of tables stored in the database
– SQL engine

27
 2

The Entity Relationship Model

• Widely accepted and adapted graphical tool

for data modeling
• Introduced by Chen in 1976
• Graphical representation of entities and their
relationships in a database structure

28
 2

The Entity Relationship Model (continued)

• Entity relationship diagram (ERD)
– Uses graphic representations to model database
components
– Entity is mapped to a relational table
• Entity instance (or occurrence) is row in table
• Entity set is collection of like entities
• Connectivity labels types of relationships
– Diamond connected to related entities through a
relationship line

29
 Figure 2.3 - The ER Model Notations

©2017 Cengage Learning®. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part, except for use as permitted in a license distributed with a
certain product or service or otherwise on a password-protected website or school-approved learning management system for classroom use.
30
 Exercise # 2
 Draw an ER Diagram for the following scenario:
Scenario 1: (Chen’s notation)
“A customer can make many payments, but each
payment is made by only one customer”.

©2017 Cengage Learning®. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part, except for use as permitted in a license distributed with a
certain product or service or otherwise on a password-protected website or school-approved learning management system for classroom use.
31
 Exercise # 3
 Based on the data stored in the following tables draw
ER Diagram using Crow’s Foot Notation:

Linked through AGENT_CODE

©2017 Cengage Learning®. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part, except for use as permitted in a license distributed with a
certain product or service or otherwise on a password-protected website or school-approved learning management system for classroom use.
33
 Exercise # 4

 Describe the ER Diagram, identify the entities and its

relationships

©2017 Cengage Learning®. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part, except for use as permitted in a license distributed with a
certain product or service or otherwise on a password-protected website or school-approved learning management system for classroom use.
34
 Exercise # 5

 The DealCo relational diagram (above) shows the initial entities and
attributes for the DealCo stores, located in two regions of the country. Base
on the diagram:
a. Identify each relationship type and write all of the business rules.
b. Create the basic Crow’s Foot ERD for DealCo.

©2017 Cengage Learning®. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part, except for use as permitted in a license distributed with a
certain product or service or otherwise on a password-protected website or school-approved learning management system for classroom use.
36
 Exercise # 5 Solution
Identify each relationship type and write all of the business rules.

©2017 Cengage Learning®. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part, except for use as permitted in a license distributed with a
certain product or service or otherwise on a password-protected website or school-approved learning management system for classroom use.
37
 Exercise # 5 Solution (continue)
The Crow’s Foot ERD for DealCo

is location for
REGION STORE

employs

is assigned to
JOB EMPLOYEE

 The Chen model is shown (Note that you always read

the relationship from the “1” to the “M” side.)
©2017 Cengage Learning®. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part, except for use as permitted in a license distributed with a
certain product or service or otherwise on a password-protected website or school-approved learning management system for classroom use.
38
 2
Exercise # 5 Solution (continue)

The Chen ERD for DealCo

1 M
REGION is location for STORE

employs

M
1 M
JOB is assigned to EMPLOYEE

39
 Exercise # 6
 Typically, a patient staying in a hospital receives medications that have been
ordered by a particular doctor. Because the patient often receives several
medications per day, there is a 1:M relationship between PATIENT and
ORDER. Similarly, each order can include several medications, creating a
1:M relationship between ORDER and MEDICATION.

a. Identify the business rules for PATIENT, ORDER, and MEDICATION.

b. Create a Crow's Foot ERD that depicts a relational database model to
capture these business rules.

©2017 Cengage Learning®. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part, except for use as permitted in a license distributed with a
certain product or service or otherwise on a password-protected website or school-approved learning management system for classroom use.
40
 2

Degrees of Data Abstraction (continued)

• American National Standards Institute (ANSI)

Standards Planning and Requirements
Committee (SPARC)
– Defined a framework for data modeling based
on degrees of data abstraction(1970s):
• External
• Conceptual
• Internal

42
 2

Figure 2.6 - The Evolution of Data Models

43
43
 2

Degrees of Data Abstraction (continued)

44
 2

The External Model

• End users’ view of the data environment

• ER diagrams are used to represent the external
views
• External schema: Specific representation of an
external view

45
45
 2
Figure 2.8 - External Models For Tiny
College

46
46
 2

The Conceptual Model

• Represents a global view of the entire database

by the entire organization
• Conceptual schema: Basis for the identification
and high-level description of the main data
objects
• Has a macro-level view of data environment
• Is software and hardware independent
• Logical design: Task of creating a conceptual
data model 47
47
 2
Figure 2.9 - Conceptual Model For Tiny
College

48
48
 2
The Internal Model
• Representing database as seen by the DBMS
mapping conceptual model to the DBMS
• Internal schema: Specific representation of
an internal model
– Uses the database constructs supported by
the chosen database
• Is software dependent and hardware
independent
• Logical independence: Changing internal
model without affecting the conceptual model
49
49
 2
Figure 2.10 - Internal Model for Tiny
College

50
50
 2
The Physical Model

• Operates at lowest level of abstraction

• Describes the way data are saved on storage
media such as disks or tapes
• Requires the definition of physical storage
and data access methods
• Relational model aimed at logical level
– Does not require physical-level details
• Physical independence: Changes in
physical model do not affect internal model
51
51
 2

Table 2.4 - Levels of Data Abstraction

52
52
 2

• For example, a business rule that specifies

that “no pilot can fly more than 10 hours
within any 24-hour period” cannot be
modeled. However, such a business rule can
be enforced by application software.

53