Transcript Data Models

Data Models
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


Attribute


Anything about which data will be collected/stored
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



Subschema


Enables database administrator to define schema components
Subschema Data Definition Language (DDL)


Defines database as “seen” by the application programs
Schema Data Definition Language (DDL)


Conceptual organization of entire database
As viewed by the database administrator
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




Performs same basic functions as




User interface
Tables
Method of querying the tables
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
21
Types of relationships
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)




Object – abstraction of a real-world entity



Basic building block for autonomous structures
Attributes – properties of an object
Class - objects that share similar


Semantic data model
Basis of object-oriented database management system (OODBMS)
Evolved to allow an object to also contain all operations
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


Primarily geared to business applications


Relational DB response to OODM
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)




Simplifies design process with natural language and intuitive diagrams




Can be populated with examples
Evolved from the Natural language Information Analysis Method


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
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
37
model
The Physical Model

Lowest level of abstraction


Software and hardware dependent


Describes the way data are saved on
storage media such as disks or tapes
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
THANK YOU
40