Chapter 2 – Data Models

Good database design will get you through poor

programming better than good programming will get you
through poor database design….
 Data Models
• Data Model: A collection of concepts to
describe the structure of a database, and
certain constraints that the database should
obey.
• Data Model Structure and Constraints:
Constructs are used to define the database structure
Constructs typically include  elements  (and their data types) 
as well as groups of elements (e.g. entity, record, table), and
relationships among such groups
Constraints specify some restrictions on valid data; these 
constraints must be enforced at all times.
 Data Models
• A description of a particular collection of data,
using a given data model is called a schema.
• For example, in a relational model, the schema for an
entity (called a relation) specifies its name, plus name and
type of each column.
E.g. Student(sid: string, name: string, login: string, dob: date,
gpa: real)
• A DBMS allows a user to define the data to be stored in
terms of a data model.
• Database Instance: The actual data stored in a database at
a particular moment in time. Also called database state
(or occurrence).
Example of a database state
 The Importance of Data Models
• Data model
– Relatively simple representation, usually graphical,
of complex real-world data structures
– Communications tool to facilitate interaction
among the designer, the applications programmer,
and the end user
• Good database design uses an appropriate
data model as its foundation
• End-users have different views and needs for
data
• Data model organizes data for various users
Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
Types of Data Models
• A semantic data model is a high-level data model that
makes it easier for a user to provide a good initial
description of data in the enterprise.
• A widely used semantic data model is called the Entity –
Relationship (ER) model.
• Entity-Relationship model
– Allows a pictorial representation of the data involved
• Relational model
– Main concept: relation, basically a table with rows
and columns.
Types of Data Models

• Other data models:

– object-oriented model
– object-relational model
– Older models: network model and hierarchical model
• The choice of a DBMS depends on the data structures
obtained from analysis. Data structures may be
presented in one of several ways: as relations,
hierarchies, networks, object-oriented, etc. Most DBMS
fall into one of these design types.
•  For this course, we will be focusing on relational
databases (RDBs).
 Data Model Basic Building Blocks
• Entity is anything about which data are to be
collected and stored
• Attribute is a characteristic of an entity
• Relationship describes an association among
(two or more) entities
– One-to-many (1:M) relationship
– Many-to-many (M:N) relationship
– One-to-one (1:1) relationship
Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
 A Hierarchical Structure

Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
Hierarchical Structure—Characteristics

• The hierarchical model depicts a set of one-

to-many (1:M) relationships between a
parent and its children segments.
• Each parent can have many children
• Each child has only one parent
1.The Hierarchical Model
• Advantages
1. It promotes data sharing.
2. Parent/Child relationship promotes conceptual
simplicity.
3. Database security is provided and enforced by
DBMS.
4. It is efficient with 1:M relationships.
The Hierarchical Model
• Disadvantages
1. Complex implementation requires knowledge of
physical data storage characteristics.
2. There are implementation limitations (no multi-parent
or M:N relationships).
3. There is no data definition or data manipulation
language in the DBMS.
4. There is a lack of standards.
2.The Network Model
• Created to
– Represent complex data relationships more effectively
– Improve database performance
– Impose a database standard
• Was standardized by the Conference on Data
Systems Languages (CODASYL) and strongly
influenced DB systems thru’ the 1960s
• Basic structure resembles hierarchical model
• Collection of records in 1:M relationships
 A Network Data Model

Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
The Network Data Model
• Advantages
1. Conceptual simplicity is at least equal to that of the
hierarchical model.
2. It handles more relationship types, such as M:N and multi-
parent.
3. Data access is more flexible than in hierarchical and file
system models.
4. There is conformance to standards.
5. It includes data definition language (DDL) and data
manipulation language (DML) in DBMS.
The Network Data Model
• Disadvantages
1. System complexity limits efficiency—still a navigational
system.
2. Navigational system yields complex implementation,
application development, and management.
3. Structural changes require changes in all application programs.

• As information needs grew and as more sophisticated

databases and applications were required, the network model
became too cumbersome.
3.The Entity Relationship Model
• Widely accepted and adapted graphical tool for data
modeling
• ER model of real world, components:
– Entities (objects)
– Relationships between entities
• ER models are normally represented in an Entity
relationship diagram (ERD)
– Uses graphic representations to model DB components
• 3 types of relationships: 1:M, M:N and 1:1.
• uses the term connectivity to label relationship types
• Two ER notations: Chen notation and Crow’s Foot
notation (see next 2 slides).
Relationships: The Basic Chen ERD

Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
Relationships: The Basic Crow’s Foot ERD

Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
The Entity Relationship Model
• Advantages
– Exceptional conceptual simplicity
– Visual representation
– Effective communication tool
– Integrated with the relational data model
• Disadvantages
– Limited constraint representation
– Limited relationship representation
– No data manipulation language
 4. The Relational Model
• Problems with early databases
– Navigating the records requires complex
programs
– There is minimal data independence
– No theoretical foundations
• Then, in 1970, E. F. Codd wrote “A
Relational Model of Data for Large Shared
Databanks” and introduced the relational
model
The Relational Model—Basic Structure
• Information is stored as tuples or records in
relations or tables
• There is a sound mathematical theory of relations
• Table (relations)
– Matrix consisting of intersecting rows and columns
– Related to each other by sharing a common
characteristic (attribute)
• Relational schema
– Visual representation of relational database’s entities,
attributes within those entities, and relationships
between those entities
Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
The Relational Model Attributes

• Example of data in the relational model

Customer- customer- customer- customer- account-
id name street city number

192-83-7465 Johnson Alma Palo Alto A-101

019-28-3746 Smith North Rye A-215

192-83-7465 Johnson Alma Palo Alto A-201

321-12-3123 Jones Main Harrison A-217

019-28-3746 Smith North Rye A-201

A Sample Relational Database
 Linking Relational Tables

Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
 A Relational diagram

Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
The Relational Model
• Advantages
– Structural independence (Changes in a table’s structure
do not affect data access or application programs)
– Tabular view improves conceptual simplicity
– Easier database design, implementation, management,
and use
– Ad hoc query capability is based on SQL.
– Powerful RDBMS isolates end-user from physical-level
details
• Disadvantages
– Substantial hardware and system software overhead
– Can facilitate poor design and implementation
5.The Object Oriented Model
• Semantic data model (SDM) developed by
Hammer and McLeod in 1981
• In object-oriented data model (OODM),
both data and their relationships are
contained in a single structure known as an
object.
• the OODM is the basis for the object-
oriented database management system
(OODBMS).
 Object Oriented Data Model—
Basic Structure

• Object: abstraction of a real-world entity

• Attributes describe the properties of an object
• Objects that share similar characteristics are
grouped in classes
• Classes are organized in a class hierarchy
• Inheritance is the ability of an object within the
class hierarchy to inherit the attributes and
methods of classes above it
 The Object Oriented Model
• An OODM reflects a very different way to define and
use entities.
• An object is described by its factual content
– Like relational model’s entity
• An object includes information about relationships
between the facts within the object, as well as
information about its relationships with other objects.
– Unlike relational model’s entity
• Therefore, the facts within the object are given
greater meaning.
 A Comparison of OO Model
and ER Model

Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
 A Comparison of OO Model
and ER Model
• Object representation of the INVOICE includes all
related objects within the same object box.
• 1 and M indicate the relationship of the related
objects to INVOICE. For example, 1 next to
CUSTOMER indicates each INVOICE is related to only
one CUSTOMER and M next to LINE indicates each
INVOICE contains many LINEs.
• ER model uses 3 separate entities and 2 relationships
to represent this simple invoice problem.
The Object Oriented Model
• The OODM is said to be a semantic data model
because semantic indicates meaning.
• Subsequent OODM development has allowed an
object to also contain all operations that can be
performed on it.
• Because objects include data, various types of
relationships and operational procedures, the object
becomes self-contained, thus making the object a
basic building block for autonomous structures.
 Developments that
Boosted OODM’s Popularity
• Growing costs put a premium on code reusability
• Complex data types and system requirements
became difficult to manage with a traditional
RDBMS
• Ever-increasing computing power made it possible
to support the increasingly sophisticated
transaction & information requirements and the
large computing overhead required

Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
The Object Oriented Model
• Advantages
– Visual presentation includes semantic content
– Database integrity
– Both structural and data independence
• Disadvantages
– Slow pace of OODM standards development
– Complex navigational data access
– Steep learning curve
– Lack of market penetration

Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
 6. Extended Relational Data Model (ERDM)

• Semantic data model developed in response to

increasing complexity of applications
• ERDM adds many of OO model’s features within
the simpler relational database structure.
• ERDM gave birth to a new generation of relational
databases supporting OO features such as objects
(data and methods), extensible data types based
on classes and inheritance.
• Hence a DBMS based on the ERDM is often
described as an object/relational database
management system (O/RDBMS)
• Primarily geared to business applications
The Development of Data Models

Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
 Database Models and the Internet
• The use of complex objects received a boost with the
Internet revolution.
• Extensible Markup Language (XML) emerged as the
standard for efficient and effective exchange of structured,
semi-structured, and unstructured data.
• Organizations using XML data soon realized the need to
manage large amounts of unstructured data such as WP
documents, Web pages, e-mails, diagrams, etc., found in
most of today’s organizations.
• To address this need, XML databases have emerged to
manage unstructured data within the XML format.
• And O/R DBMSs have added support for XML-based
documents within their relational data structure.
 DBMS TYPES
Based on the data model used:
• Hierarchical – Pre-historic – IMS
• Network – Historic –IDMS, ADABAS, led to Object-Oriented
• RELATIONAL- current – 95% of the market – Oracle, Informix,
SQL Server, Progress, IBM DB2, etc.
• Object- ORIENTED Current – lot of HuHa but very narrow
market, mainly CAD AND Engineering – Objectivity, Versant,
Jasmine
• Object – Relational- Current / Future – SQL3, Informix UDO,
Oracle-10i, IBM DB2.
 Data Abstraction

• To illustrate data abstraction, consider a car design:

– A car designer begins by drawing the concept of the car
that is to be produced.
– Next, engineers design the details that help transfer the
basic concept into a structure that can be produced.
– Finally, the engineering drawings are translated into
production specifications to be used on the factory floor.
• Thus the process of producing the car begins at a
high level of abstraction and proceeds to an ever-
increasing level of detail.
 Levels of Data Abstraction
• Designing a usable database follows the same basic
process: a DB designer starts with an abstract view of
the overall data environment and adds details as the
design comes closer to implementation.
• In early 1970s, the American National Standards
Institute (ANSI) Standards Planning and
Requirements Committee (SPARC) defined a
framework for data modeling based on degrees of
data abstraction.
• The ANSI/SPARC Architecture defines 3 levels of data
abstraction: External, Conceptual, and Internal.
 Levels of Data Users
Abstraction
…
• Many views, single
conceptual (logical) schema
and internal schema. View 1 View 2 … View n
– Views describe how individual
users see the data (External
schema). Conceptual Schema
– Conceptual schema defines
logical structure. (Also called Internal Schema
Logical schema)
– Internal schema describes
storage details such as files DB
and indexes used.
ANSI-SPARC Three-Level
Architecture
Levels of Data Abstraction
• The External model is the end users’ view of the data
environment.
• The Conceptual model is used, graphically
represented by an ERD, to integrate all external views
into a single view. The conceptual model represents a
global view of the entire database as viewed by the
entire organization.
• Once a specific DBMS has been selected, the
internal model maps the conceptual model to the
DBMS. The internal model is the representation of
the database as “seen” by the DBMS.
Differences between Three Levels of
ANSI-SPARC Architecture
 Mappings
• Mappings translate information from one level
to the next
– External/Conceptual
– Conceptual/Internal
• These mappings provide data independence
• Physical data independence
– Changes to internal level shouldn’t affect
conceptual level
• Logical data independence
– Conceptual level changes shouldn’t affect external
levels
 Data Independence:The Big
Breakthrough of the Relational Model
• A Simple Idea: Applications
should be insulated from how View 1 View 2 View 3
data is structured and stored
Conceptual Schema
• Logical data independence:
Protection from changes in
Internal Schema
logical structure of data.
• Physical data independence:
Protection from changes in DB
physical structure of data.
Data Independence and the ANSI-
SPARC Three-Level Architecture
Objectives of Three-Level Architecture
• All users should be able to access same data.
• A user’s view is immune to changes made in
other views.
• Users should not need to know physical
database storage details.
• DBA should be able to change database
storage structures without affecting the
users’ views.
Objectives of Three-Level Architecture
• Internal structure of database should be
unaffected by changes to physical aspects of
storage.
• DBA should be able to change conceptual
structure of database without affecting all
users
• Proposed to support DBMS characteristics of:
• Program-data independence.
• Support of multiple views of the data.
Degree of Abstraction
 Business Rules
• When database designers select or determine the
entities, attributes, and relationships that will be
used to build a data model, they might start by
gaining a thorough understanding of what types of
data are in an organization, how the data are used,
and in what time frames they are used.
• From a database point of view, the collection of data
becomes meaningful only when it reflects properly
defined business rules.
 Business Rules (continued)
• Brief, precise, and unambiguous description
of policies, procedures, or principles within
a specific organization’s environment
• Apply to any organization that stores and
uses data to generate information
• Description of operations that help to
create and enforce actions within that
organization’s environment
Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
 Business Rules (continued)
• Describe characteristics of the data as
viewed by the company
• Must be rendered in writing

• Must be kept up to date

• Sometimes are external to the organization
• Must be easy to understand and widely
disseminated
Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
 Business Rules (continued)
• Examples of business rules are as follows:
– A customer may generate many invoices.
– An invoice is generated by only one customer.
– A training session cannot be scheduled for fewer than 10
employees or for more than 30 employees.

• Note that business rules establish entities,

relationships, and constraints. For example,
– First two rules establish two entities (CUSTOMER and
INVOICE) and a 1:M relationship between those 2 entities.
– Third rule establishes a constraint (>= 10 people and <= 30
people), two entities (EMPLOYEE and TRAINING), and a
relationship between EMPLOYEE and TRAINING.
 Sources of Business Rules
• Company managers
• Policy makers
• Department managers
• Written documentation
– Procedures
– Standards
– Operations manuals
• Direct interviews with end users
Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
 Importance of Business Rules
• Promote creation of an accurate data model
• Standardize company’s view of data
• Constitute a communications tool between users
and designers
• Allow designer to understand the nature, role,
and scope of data
• Allow designer to understand business processes
• Allow designer to develop appropriate
relationship participation rules and constraints

Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
 Summary
• A good DBMS will perform poorly with a poorly
designed database
• A data model is a (relatively) simple abstraction of a
complex real-world data-gathering environment
• Basic data modeling components are:
– Entities
– Attributes
– Relationships
• Hierarchical model - Depicts a set of one-to-many
(l:M) relationships between a parent and its children

Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel
 Summary (continued)
• Network model attempts to deal with many of the
hierarchical model’s limitations
• Relational model:
– Current database implementation standard
– Much simpler than hierarchical or network design
• Object is basic modeling structure of object oriented
model
• Data modeling requirements are a function of different
data views (global vs. local) and level of data abstraction
• The ANSI/SPARC Architecture defines 3 levels of data
abstraction: external, conceptual, and internal.
• Levels of abstraction provide data independence.
Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel