Chapter 2

Data Models
©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.
 Learning Objectives
• About data modeling and 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 their level of
abstraction

2
Data Modeling & Data
Models (cont…)

3
 Data Modeling & Data
Models

Data model
• Represent data structures and their
characteristics, relations, constraints,
transformations, and other constructs with the
purpose of supporting a specific problem domain
• Blueprint with all the instructions to develop a
4
database that meets all end-user requirements.
Importance of Data Models

5
Data Model Basic Building
Blocks

6
 Business Rules

Brief, precise, and

unambiguous Enable defining the
description of a basic building
policy, procedure, or blocks
principle

Examples:
Describe main and • A customer may
distinguishing generate many
characteristics of the invoices
data • An invoice is
generated by only
one customer
7
 Business Rules (cont…)
Reminder:
Business rules establish the basic building blocks of the data
model (e.g. entities, attributes, relationships, and constraints)
More examples:
• Relationships:
• A customer may rent many bicycles.
• One bicycle is rented by only one customer.
• Constraints:
• A student may register for a maximum of four subjects.
• A training session cannot be scheduled for fewer than
10 employees or for more than 20 employees.
8
 Business Rules (cont…)
Discovering Business Rules (Sources and Business
Rules)

9
 Business Rules (cont…)
Importance of Identifying Business Rules
• Help standardize company’s view of data
• Communications tool between users and
designers
• Allow designer to:
• Understand the nature, role, scope of data, and
business processes
• Develop appropriate relationship participation
rules and constraints
• Create an accurate data model
10
 Business Rules (cont…)
Translating Business Rules into Data Model
Components
• Nouns translate into entities
• Verbs translate into relationships among entities
• Example: A customer may generate many
invoices
• “Customer” and “invoice” are objects of
interest, hence, they can form entities
• The relationship between the customer and
invoice is “generate”
11
 Business Rules (cont…)
Translating Business Rules into Data Model
Components
• Relationship is bi-directional.
• Examples:
• A customer may generate many invoices
• An invoice is generated by only one customer
• 1:M relationship, customer is the “1” side, and
invoice is the “many” side

12
 Business Rules (cont…)
Translating Business Rules into Data Model
Components
• Rule of thumb:
• How many instances of B are related to one instance of
A?
• How many instances of A are related to one instance of
B?
• Example:
• How many books can one author write?
• How many authors can one book be written by?
• M:N relationship
13
 Business Rules (cont…)
Naming Conventions
• Entity names - Required to:
• Be descriptive of the objects in the business
environment
• Use terminology that is familiar to the users
• Attribute name - Required to be descriptive of the
data represented by the attribute
• Proper naming:
• Facilitates communication between parties
• Promotes self-documentation
14
 Exercise!!
Entity vs. attributes
Car_price Painter Painter_name Employee_na Employee_ID
me
Painting Student_nam Birth_date Subject_nam Matric_num
e e
Painting_ID Plat_number Subject_ID Car Subject_unit

Subject Engine_numb Student Phone_num Employee

er
Painter_email Date_joined Painting_desc Painting_pric Employee_po
ription e sition

15
 Exercise!!
Write business rules from basic data
model as shown in the figures.

Answer:
An agent can serve many customers.
Each customer is served by one agent.
(i) The relational diagram

(ii) Linking relational tables

16
 The Evolutions of Data Models

Emerging
Hierarchic
File XML hybrid model (Big
al& Relational OO & O/R
system DBMS data,
network
NoSQL)

1960 - 1970s 1985 – 1990s 2009

1969

17
 The Evolutions of Data Models (cont…)
Hierarchical Model
• Represented by an upside-down tree which
contains segments
• Depicts a set of one-to-many (1:M) relationships

Hierarchical database model by Wikipedia (WP:CC BY-SA) 18

 The Evolutions of Data Models (cont…)
Hierarchical Model
Advantages
• Promotes data sharing
• Parent/child relationship
promotes conceptual
simplicity and data integrity
• Database security is
provided and enforced by
DBMS
• Efficient with 1:M
relationships
Disadvantages
• Requires knowledge of
physical data storage
characteristics
• Navigational system
requires knowledge of
hierarchical path
• Changes in structure
require changes in all
application programs
• Implementation limitations
• No data definition
• Lack of standards
19
 The Evolutions of Data Models (cont…)
Network Model
• Represent complex data relationships
• Improve database performance and impose a
database standard
• Depicts both one-to-many (1:M) and many-to-
many (M:N) relationships

20
 The Evolutions of Data Models (cont…)
Network Model

Network model by Wikipedia (WP:CC BY-SA) 21

 The Evolutions of Data Models (cont…)
Network Model
• Network database model is seldom used today.
• Standard database concepts that emerged with
the network model are still used until today.
• Examples: schema, sub-schema, data
manipulation language (DML), schema data
definition language (DDL)

22
 The Evolutions of Data Models (cont…)
Network Model

Schema Subschema
• Conceptual • Portion of the
organization of database seen
the entire by the
database as application
viewed by the programs that
database produce the
administrator desired
information
from the data
within the
database

23
 The Evolutions of Data Models (cont…)
Network Model

• Environment in which data can

Data be managed and is used to
work with the data in the
manipulation database
• Deals with data manipulation
language includes SQL statements
such as SELECT, INSERT,
(DML) UPDATE

Schema data • Enables the database

administrator to define the
definition schema components
• How the data should be
language reside in the database.
Example : CREATE, ALTER
(DDL)
24
 The Evolutions of Data Models (cont…)
Network Model

Advantages Disadvantages

• Conceptual simplicity • System complexity limits

• Handles more relationship efficiency –still a
types navigational system
• Data access is flexible • Navigational system yields
• Data owner/member complex implementation,
relationship promotes data application development,
integrity and management
• Conformance to standards • Structural changes require
changes in all application
• Includes data definition
programs
language (DDL) and data
manipulation language
(DML)
25
 The Evolutions of Data Models (cont…)
Relational Model

26
 The Evolutions of Data Models (cont…)
Relational Model
• RDBMS = relational database management
system
• Performs basic functions provided by the
hierarchical and network DBMS systems
• Makes the relational data model easier to
understand and implement
• Hides the complexities of the relational model
from the user
• Examples: Oracle, DB2, Microsoft SQL Server,
and MySQL 27
 The Evolutions of Data Models (cont…)
Relational Model

Figure 2.2 - A Relational Diagram 28

 The Evolutions of Data Models (cont…)
Relational Model

Figure 2.1 – Linking relational tables 29

 The Evolutions of Data Models (cont…)
Relational Model

Advantages Disadvantages

• Structural independence • Requires substantial

is promoted using hardware and system
independent tables software overhead
• Tabular view improves • Conceptual simplicity
conceptual simplicity gives untrained people
• Ad hoc query capability is the tools to use a good
based on SQL system poorly
• Isolates the end user from • May promote information
physical-level details problems as individual
• Improves implementation and departments can
and management easily develop their own
simplicity applications
30
 The Evolutions of Data Models (cont…)
Relational Model (SQL-Based Relational Database
Application)
End-user • Allows end user to interact
with the data
interface

Collection of • Each table is independent

from another
tables stored in • Rows in different tables are
related based on common
the database values in common attributes

SQL engine • Executes all queries

31
 The Evolutions of Data Models (cont…)
The Entity Relationship Model
• With a fast development of the relational database, a more
effective database design tool is required.
• Graphical representation of entities and their relationships
in a database structure
• Entity relationship diagram (ERD)
• Uses graphic representations to model database
components
• Entity instance or entity occurrence
• Rows in the relational table
• Connectivity: Term used to label the relationship types
32
 The Evolutions of Data Models (cont…)
The Entity Relationship Model

Figure 2.3 - The ER Model Notations 33

 The Evolutions of Data Models (cont…)
The Entity Relationship Model

Advantages Disadvantages

• Visual modeling yields • Limited constraint

conceptual simplicity representation
• Visual representation • Limited relationship
makes it an effective representation
communication tool • No data manipulation
• Is integrated with the language
dominant relational • Loss of information
model content occurs when
attributes are removed
from entities to avoid
crowded displays 34
 The Evolutions of Data Models (cont…)
The Object-Oriented Data Model (OODM)
• Object-oriented database management
system(OODBMS)
• Based on OODM
• Object: Contains data and their relationships with
operations that are performed on it
• Basic building block for autonomous structures
• Abstraction of real-world entity
• Attributes - Describe the properties of an object

35
 The Evolutions of Data Models (cont…)
The Object-Oriented Data Model (OODM)
• Class: Collection of similar objects with shared
structure and behavior organized in a class
hierarchy
• Class hierarchy: Resembles an upside-down
tree in which each class has only one parent
• Inheritance: Object inherits methods and
attributes of parent class
• Unified Modeling Language (UML)
• Describes sets of diagrams and symbols to
graphically model a system 36
 The Evolutions of Data Models (cont…)
The Object-Oriented Data Model (OODM)

Figure 2.4 - A Comparison of OO, UML, and ER Models

37
 The Evolutions of Data Models (cont…)
The Object-Oriented Data Model (OODM)

Advantages Disadvantages

• Semantic content is • Slow development of

added standards caused
• Visual representation vendors to supply their
includes semantic own enhancements
content • Compromised widely
• Inheritance promotes accepted standard
data integrity • Complex navigational
system
• Learning curve is steep
• High system overhead
slows transactions 38
 The Evolutions of Data Models (cont…)
Object/Relational & XML
• Extended relational data model (ERDM)
• Supports OO features and complex data
representation
• Object/Relational Database Management
System (O/R DBMS)
• Based on ERDM, focuses on better data
management
• Extensible Markup Language (XML)
• Manages unstructured data for efficient and
effective exchange of all data types 39
 The Evolutions of Data Models (cont…)
Big Data
• Aims to:
• Find new and better ways to manage large amounts
of web and sensor-generated data
• Provide high performance and scalability at a
reasonable cost
• Characteristics
• Volume – amounts of data being stored
• Velocity – refers to speed and the need to process
data quickly to generate information
• Variety – data comes in multiple different data format
40
 The Evolutions of Data Models (cont…)
Big Data
• The challenges of big data:
• Volume does not allow the usage of
conventional structures
• Expensive
• OLAP tools proved inconsistent dealing with
unstructured data

41
 The Evolutions of Data Models (cont…)
Big Data New Technologies

Hadoop

Big Data Hadoop

Distributed
NoSQL New File
System
Technologies (HDFS)

MapReduc
e

42
 The Evolutions of Data Models (cont…)
NoSQL Databases
• Not based on the relational model
• Support distributed database architectures
• Provide high scalability, high availability, and fault
tolerance
• Support large amounts of sparse data
• Geared toward performance rather than
transaction consistency
• Store data in key-value stores

43
 The Evolutions of Data Models (cont…)
NoSQL Databases

Figure 2.5 - A Simple Key-value Representation 44

 The Evolutions of Data Models (cont…)
NoSQL Databases

Advantages Disadvantages

• High scalability, • Complex programming

availability, and fault is required
tolerance are provided • There is no
• Uses low-cost relationship support
commodity hardware • There is no transaction
• Supports Big Data integrity support
• Key-value model • In terms of data
improves storage consistency, it
efficiency provides an eventually
consistent model
45
 The Evolutions of Data Models (cont…)
Summary

46
Figure 2.6 - The Evolution of Data Models
 The Evolutions of Data Models (cont…)
Summary

Table 2.3 - Data Model Basic Terminology Comparison

47
 Degrees of Data Abstraction

• Framework for data modeling based on data

abstraction levels:
• External model
• Conceptual model
• Internal model
• Physical model

48
Degrees of Data Abstraction (cont…)

Figure 2.7 - Data Abstraction Levels 49

 Degrees of Data Abstraction (cont…)
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

50
 Degrees of Data Abstraction (cont…)
The External Model

Business
Unit 2

Business
Unit 1

51
Figure 2.8 - External Models for Tiny College
 Degrees of Data Abstraction (cont…)
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

52
 Degrees of Data Abstraction (cont…)
The Conceptual Model (Bird eye level, macro view)

53
Figure 2.9 - Conceptual Model for Tiny College
 Degrees of Data Abstraction (cont…)
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
54
 Degrees of Data Abstraction (cont…)
The Internal Model (depends on a DBMS)

55
Figure 2.10 - Internal Model for Tiny College
 Degrees of Data Abstraction (cont…)
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 aims at logical level
• Does not require physical-level details
• However, understanding of physical model is good for
physical-level fine tuning.
• Physical independence: Changes in physical model do not
affect internal model 56
 Degrees of Data Abstraction (cont…)
Summary

Table 2.4 - Levels of Data Abstraction

57