Data Models

By
Bob Larson

1
Overview
 Why data models are important
 Basic data-modeling building blocks
 What are business rules and how do
they influence database design
 How the major data models evolved
 How data models can be classified by
level of abstraction

2
Importance of Data Models
 Data models
 Representations, usually graphical, of
complex real-world data structures
 Facilitate interaction among the designer,
the applications programmer and the end
user
 End-users have different views and
needs for data
 Data model organizes data for various
users
3
Data Model Basic Building Blocks
 Entity
 Anything about which data will be collected/stored
 Attribute
 Characteristic of an entity
 Relationship
 Describes an association among entities
 One-to-one (1:1) relationship
 One-to-many (1:M) relationship
 Many-to-many (M:N or M:M) relationship
 Constraint
 A restriction placed on the data
4
Business Rules
 Brief, precise and unambiguous
descriptions of policies, procedures or
principles within the organization
 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

5
Business Rules (continued)
 Must be put in writing
 Must be kept up to date
 Sometimes external to the organization
 Must be easy to understand and widely
disseminated
 Describe characteristics of the data as
viewed by the company

6
Discovering Business Rules
 Company managers
 Policy makers
 Department managers
 Written documentation
 Procedures
 Standards
 Operations manuals
 Direct interviews with end users
7
 Translating Business Rules
to Data Model Components
 Standardize company’s view of data
 Communication 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
 Promote creation of an accurate data model
 Nouns translate into entities
 Verbs translate into relationships among entities
 Relationships are bi-directional 8
The Evolution of Data Models

We will look briefly at each Model Type 9

The Hierarchical Model

 Developed in 1960s to manage large amounts of data for

complex manufacturing projects
 Logical structure represented as an upside-down “tree”
 Hierarchical structure contains levels or segments
 Depicts a set of one-to-many (1:M) relationships
 Between a parent and it’s children segments
 Each parent can have many children
 each child has only one parent
10
Hierarchical Model
 Advantages
 Many features form the foundation for current data
models
 Generated a large installed base of programmers
 Who developed solid business applications
 Disadvantages
 Complex to implement
 Difficult to manage
 Lacks structural independence
 Implementation limitations
 Lack of standards (Company vs Industry or Open)
11
The Network Model

 Resembles hierarchical model

 Difference child can have multiple parents
 Collection of records in 1:M relationships
 Set – Relationship of at least two record types
 Owner – Equivalent to the hierarchical model’s parent
 Member – Equivalent to the hierarchical model’s child
12
 Network Model Terms
 Schema
 Conceptual organization of entire database
 As viewed by the database administrator
 Subschema
 Defines database as “seen” by the application programs
 Schema Data Definition Language (DDL)
 Enables database administrator to define schema components
 Subschema Data Definition Language (DDL)
 Allows applications to define database components to be used
 Data Management Language (DML)
 Defines the environment in which data can be managed
 Works with the data in the database

13
Network Model
 Advantages
 Represents complex data relationships better than
Hierarchical Model
 Improved database performance
 Impose a database “industry” standard
 Conference on Data Systems Languages (CODASYL)
 Database Task Group (DBTG)
 Disadvantages
 Too cumbersome
 Lack of “ad hoc” query capability
 Put heavy pressure on programmers
 Any structural change in the database could produce havoc
in all application programs that drew data from the database
14
The Relational Model

 Conceptually simple – Linked Tables

 Developed by Edgar F. Codd (IBM 1970 )
 Considered ingenious but impractical in 1970
 Computers lacked power to implement the relational model
 Today’s PCs run sophisticated relational databases
15
Relational Model – Tables

 Also called relations

 Matrix of row and column intersections
 Stores a collection of similar entities
 Resembles a file or spreadsheet
 Purely logical structure
 How data are physically stored is of no concern to
the user or the designer
 The source of a real database revolution
16
Relational Model – Relational Diagram
 Representation of
relational database’s
 Entities (Tables)
 Attributes within those
entities (Fields)
 Relationships between
those entities (Links)

17
Relational Model – RDBMS

 Relational Database Management System

 All the system components
 User interface
 Tables
 Method of querying the tables

 Performs same basic functions as

 Hierarchical and
 Network DBMS models
 Plus many other functions
 Most important –hides the complexities of the
relational model from the user
18
The Relational Model – SQL
 Structured Query Language (SQL)
 Allows ad hoc queries – questions of the data
 User can specify what must be done without
specifying how it must be done
 Dominance due in great part to its powerful
and flexible query language
 SQL-based relational database application:
 User interface
 A set of tables stored in the database
 SQL engine
19
Entity Relationship Model (ERM)

 Introduced by Peter Chen in 1976

 Widely accepted and adapted graphical tool for
data modeling
 Graphical representation of entities and their
relationships in a database structure
20
Entity Relationship Model – Terms

 Entity Relationship Diagram (ERD)

 Graphic representations to model database components
 Entity is mapped to a relational table
 Entity instance (or occurrence) – A row in table
 Entity set (table) – Collection of like entities
 Connectivity labels
 Diamond connected to related entities through a relationship line
 Types of relationships 21
ERM Notation Symbols

 Three symbols to represent element relationships

 Ring represents "zero"
 Dash represents "one"
 Crow's foot represents "more" or "many"
 Used in pairs to represent the four types of
relationships
 Ring and dash → zero or one
 Dash and dash → exactly one
 Ring and crow's foot → zero or more
 Dash and crow's foot → one or more
22
The Object Oriented (OO) Model

 Models both data and their relationships in a single structure

known as an object
 Object described by its factual content
 Like relational model’s entity
 Includes info about relationships between facts within object
and relationships with other objects
 Unlike relational model’s entity
23
Object Oriented Model – Terms
 Object-oriented data model (OODM)
 Semantic data model
 Basis of object-oriented database management system
(OODBMS)
 Evolved to allow an object to also contain all operations
 Object – abstraction of a real-world entity
 Basic building block for autonomous structures
 Attributes – properties of an object
 Class - objects that share similar
 Classes are organized in a class hierarchy
 Inheritance – an object within the class hierarchy
inherits the attributes and methods of class
24
Extended Relational Data Model (ERDM)

 Semantic data model

 Developed in response to increasing complexity
of applications
 Based heavily on relational model
 Relational DB response to OODM
 Primarily geared to business applications
 Typically scientific or engineering apps
 Object/relational database management
system (O/RDBMS)
 DBMS based on the ERDM
25
Object Role Modeling (ORM)

26
ORM
 Not to be confused with Object-relational mapping
 Provides a conceptual approach to modeling
 Models the application area or universe of discourse (UoD)
 Relevant set of entities that are being dealt with by quantifiers
 Requires a good understanding of the UoD
 Means of specifying this understanding in a clear, unambiguous
way
 Simplifies design process with natural language and intuitive
diagrams
 Can be populated with examples
 Evolved from the Natural language Information Analysis Method
 Mid-1970s
 G. M. Nijssen and Dr. Terry Halpin first joint papers in 1989
 Capable of capturing many business rules typically unsupported
in other popular data modeling notations
 Software tool support include Microsoft Visio for Enterprise
Architects, CaseTalk, Infagon and NORMA
27
Database Models and the Internet
 Internet drastically changed role and scope of
database market
 Growing need to manage unstructured
information
 The data found in today’s:
 Online documents
 Web pages
 Most modern DBMS incorporate Internet-age
technologies such as Extended Markup
Language (XML) support
28
Data Models: Summary
 Each new data model capitalized on the
shortcomings of previous models
 Common characteristics:
 Conceptual simplicity without compromising the
semantic completeness of the database
 Represent the real world as closely as possible
 Representation of real-world transformations
(behavior) must comply with consistency and
integrity characteristics of any data model

29
Data Models: Summary

30
Degrees of Data Abstraction
 Way of classifying data models
 Many processes begin at high level of
abstraction
 Proceed to an ever-increasing level of
detail
 Designing a usable database follows the
same basic process

31
Degrees of Data Abstraction
 American National
Standards Institute (ANSI)
 Standards Planning and
Requirements Committee
(SPARC)
 Developed standards 1970
 Framework for data
modeling based on degrees
of data abstraction:
 External
 Conceptual
 Internal
 Physical

32
The External Model

 Each end users’ view of the data environment

 Modeler subdivides requirements and constraints into
functional (Business unit’s) modules
 These can be examined within the framework of their
external models 33
External Model – Advantages
 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
 Creation of external models helps to identify
and ensure security constraints in the
database design
 Simplifies application program development

34
The Conceptual Model (1 of 2)

 Global view of the entire database

 Representation of data as viewed by the entire
organization
 Basis for identification and high-level description of
main data objects, avoiding details 35
 The Conceptual Model (2 of 2)

 Software and hardware independent

 Independent of DBMS software
 Independent of hardware to be used
 Changes in either hardware or DBMS
software have no effect on the database
design at the conceptual level
 Most widely used conceptual model
is the Entity Relationship (ER) model
 Provides a relatively easily understood
macro level view of data environment

36
The Internal Model

 The database as “seen” by the DBMS

 Maps the conceptual model to the DBMS
 Depicts a specific representation of an internal model
 Logical independence
 Can change the internal model without affecting the conceptual model
37
 The Physical Model
 Lowest level of abstraction
 Describes the way data are saved on
storage media such as disks or tapes
 Software and hardware dependent
 Requires database designers to have
a detailed knowledge of the hardware
and software used to implement
database design
 Physical independence
 Can change the physical model
without affecting the internal model

38
Degrees of Data Abstraction - Summary

39
Fin…

40