Coronel PPT Ch02
Coronel PPT Ch02
Chapter 2
Data Models
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.
Learning Objectives
▪ In this chapter, you will learn:
▪ 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
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 2
Learning Objectives
▪ In this chapter, you will learn:
▪ How the major data models evolved
▪ About emerging alternative data models and the need
they fulfill
▪ How data models can be classified by their level of
abstraction
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 3
Introduction
▪ Designers, programmers, and end users see data in
different ways
▪ Different views of same data lead to designs that do
not reflect organization’s operation
▪ Data modeling reduces complexities of database
design
▪ Various degrees of data abstraction help reconcile
varying views of same data
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 4
Data Modeling and Data Models
• Data modeling: Iterative and progressive process of
creating a specific data model for a determined problem
domain
▪ Data models: Simple representations of complex
real-world data structures
▪ Useful for supporting a specific problem domain
▪ Model - Abstraction of a real-world object or event
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 5
Importance of Data Models
Are a communication tool
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 6
Data Model Basic Building Blocks
▪ Entity: Unique and distinct object used to collect
and store data
▪ Attribute: Characteristic of an entity
▪ Relationship: Describes an association among
entities
▪ One-to-many (1:M)
▪ Many-to-many (M:N or M:M)
▪ One-to-one (1:1)
▪ Constraint: Set of rules to ensure data integrity
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 7
Business Rules
Brief, precise, and unambiguous description of a
policy, procedure, or principle
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 8
Sources of Business Rules
Company Department
Policy makers
managers managers
Direct
Written
interviews
documentation
with end users
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 9
Reasons for Identifying and Documenting
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
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 10
Translating Business Rules into Data
Model Components
▪ Nouns translate into entities
▪ Verbs translate into relationships among entities
▪ Relationships are bidirectional
▪ Questions to identify the relationship type
▪ How many instances of B are related to one instance of
A?
▪ How many instances of A are related to one instance of
B?
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 11
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
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 12
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 13
Hierarchical and Network Models
Hierarchical Models Network Models
▪ Manage large amounts of data ▪ Represent complex data
for complex manufacturing relationships
projects ▪ Improve database performance
▪ Represented by an upside- and impose a database
down tree which contains standard
segments ▪ Depicts both one-to-many
▪ Segments: Equivalent of a file (1:M) and many-to-many
system’s record type (M:N) relationships
▪ Depicts a set of one-to-many
(1:M) relationships
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 14
Hierarchical Model
Advantages Disadvantages
▪ Promotes data sharing ▪ Requires knowledge of physical
▪ Parent/child relationship promotes data storage characteristics
conceptual simplicity and data ▪ Navigational system requires
integrity knowledge of hierarchical path
▪ Database security is provided and ▪ Changes in structure require
enforced by DBMS changes in all application
▪ Efficient with 1:M relationships programs
▪ Implementation limitations
▪ No data definition
▪ Lack of standards
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 15
Network Model
Advantages Disadvantages
▪ Conceptual simplicity ▪ System complexity limits
▪ Handles more relationship types efficiency
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 16
Standard Database Concepts
Schema
• Conceptual organization of the entire database as viewed by
the database administrator
Subschema
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 17
Standard Database Concepts
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 19
Relational Model
Advantages Disadvantages
▪ Structural independence is ▪ Requires substantial hardware and
promoted using independent system software overhead
tables
▪ Conceptual simplicity gives
▪ Tabular view improves untrained people the tools to use a
conceptual simplicity
good system poorly
▪ Ad hoc query capability is based
on SQL ▪ May promote information
problems
▪ Isolates the end user from
physical-level details
▪ Improves implementation and
management simplicity
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 20
The Relational Model (cont’d.)
▪ Relational data management system (RDBMS) -
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
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 21
The Relational Model (cont’d.)
▪ Relational diagram
▪ Representation of entities, attributes, and relationships
▪ Relational table stores collection of related entities
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 22
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 23
Figure 2.2 - A Relational Diagram
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 24
SQL-Based Relational Database
Application
▪ End-user interface
▪ Allows end user to interact with the data
▪ Collection of tables stored in the database
▪ Each table is independent from another
▪ Rows in different tables are related based on common
values in common attributes
▪ SQL engine
▪ Executes all queries
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 25
The Entity Relationship Model
▪ Graphical representation of entities and their
relationships in a database structure
▪ Entity relationship diagram (ERD)
▪ Uses graphic representations to model database
components
▪ Entity is mapped to a relational table
▪ Entity instance or entity occurrence
▪ Rows in the relational table
▪ Connectivity: Term used to label the relationship
types
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 26
The Entity Relationship Model
(cont’d.)
▪ Relationships are expressed using Chen notation
▪ Relationships are represented by a diamond
▪ Relationship name is written inside the diamond
▪ Crow’s Foot notation used as design standard in this
book
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 27
Entity Relationship Model
Advantages Disadvantages
▪ Visual modeling yields ▪ Limited constraint
conceptual simplicity representation
▪ Visual representation makes it ▪ Limited relationship
an effective communication representation
tool ▪ No data manipulation
▪ Is integrated with the dominant language
relational model ▪ Loss of information content
occurs when attributes are
removed from entities to avoid
crowded displays
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 28
Figure 2.3 - The ER Model Notations
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 29
The Object-Oriented Data Model (OODM)
or Semantic Data Model
▪ Object-oriented database management
system(OODBMS)
▪ Based on OODM - Semantic data model
▪ Object: Contains data and their relationships with
operations that are performed on it
▪ Are self-contained: a basic building-block for
autonomous structures
▪ Abstraction of real-world entity
▪ Attributes - Describe the properties of an object
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 30
The Object-Oriented Data Model (OODM)
▪ Attributes describe the properties of an object
▪ Objects that share similar characteristics are grouped
in classes
▪ 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
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 31
The Object-Oriented (OO) Model
(cont’d.)
▪ Unified Modeling Language (UML)
▪ Describes sets of diagrams and symbols to graphically
model a system
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 32
Object-Oriented Model
Advantages Disadvantages
▪ Semantic content is added ▪ Slow development of
standards caused vendors to
▪ Visual representation includes supply their own
semantic content enhancements
▪ Inheritance promotes data ▪ Compromised widely accepted
integrity standard
▪ Complex navigational system
▪ Learning curve is steep
▪ High system overhead slows
transactions
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 33
Figure 2.4 - A Comparison of OO, UML,
and ER Models
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 34
Object/Relational and 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
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 35
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
▪ Velocity
▪ Variety
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 36
Big Data Challenges
Volume does not allow the usage of
conventional structures
Expensive
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 37
Big Data New Technologies
Hadoop Distributed
Hadoop
File System (HDFS)
MapReduce NoSQL
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 38
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
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 39
NoSQL
Advantages Disadvantages
▪ High scalability, availability, and ▪ Complex programming is
fault tolerance are provided required
▪ Uses low-cost commodity ▪ There is no relationship support
hardware ▪ There is no transaction integrity
▪ Supports Big Data support
▪ 4. Key-value model improves ▪ In terms of data consistency, it
storage efficiency provides an eventually consistent
model
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 40
Figure 2.5 - A Simple Key-value
Representation
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 41
Figure 2.6 - The Evolution of Data Models
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 42
Table 2.3 - Data Model Basic Terminology
Comparison
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 43
Data Models: A Summary
▪ Common characteristics:
▪ Conceptual simplicity with semantic completeness
▪ Represent the real world as closely as possible
▪ Real-world transformations must comply with
consistency and integrity characteristics
▪ Each new data model capitalized on the shortcomings
of previous models
▪ Some models better suited for some tasks
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 44
Degrees of Data Abstraction
▪ Database designer starts with abstracted view, then
adds details
▪ ANSI Standards Planning and Requirements
Committee (SPARC)
▪ Defined a framework for data modeling based on
degrees of data abstraction (1970s):
▪ External
▪ Conceptual
▪ Internal
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 45
The External Model
▪ End users’ view of the data environment
▪ ER diagrams represent external views
▪ External schema: specific representation of an
external view
▪ Entities
▪ Relationships
▪ Processes
▪ Constraints
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 46
Figure 2.7 - Data Abstraction Levels
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 47
The External Model (cont’d.)
▪ Easy to identify specific data required to support each
business unit’s operations
▪ Facilitates designer’s job by providing feedback
about the model’s adequacy
▪ Ensures security constraints in database design
▪ Simplifies application program development
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 48
Figure 2.8 - External Models for Tiny
College
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 49
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
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 50
Figure 2.9 - Conceptual Model for Tiny
College
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 51
The Conceptual Model (cont’d.)
▪ Provides a relatively easily understood macro level
view of data environment
▪ Independent of both software and hardware
▪ Does not depend on the DBMS software used to
implement the model
▪ Does not depend on the hardware used in the
implementation of the model
▪ Changes in hardware or software do not affect database
design at the conceptual level
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 52
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
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 53
Figure 2.10 - Internal Model for Tiny
College
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 54
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
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 55
Table 2.4 - Levels of Data Abstraction
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 56
Summary
▪ A data model is an abstraction of a complex real-
world data environment
▪ Basic data modeling components:
▪ Entities
▪ Attributes
▪ Relationships
▪ Constraints
▪ Business rules identify and define basic modeling
components
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 57
Summary (cont’d.)
▪ Hierarchical model
▪ Set of one-to-many (1:M) relationships between a
parent and its children segments
▪ Network data model
▪ Uses sets to represent 1:M relationships between record
types
▪ Relational model
▪ Current database implementation standard
▪ ER model is a tool for data modeling
▪ Complements relational model
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 58
Summary (cont’d.)
▪ Object-oriented data model: object is basic modeling
structure
▪ Relational model adopted object-oriented extensions:
extended relational data model (ERDM)
▪ OO data models depicted using UML
▪ Data-modeling requirements are a function of
different data views and abstraction levels
▪ Three abstraction levels: external, conceptual, internal
©2015 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 59