Data Models

1
Data Models

• By
• Bob Larson

2
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

3
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

4
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 (11) relationship
• One-to-many (1M) relationship
• Many-to-many (MN or MM) relationship
• Constraint
• A restriction placed on the data

5
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 organizations
  environment

6
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

7
Discovering Business Rules

• Company managers
• Policy makers
• Department managers
• Written documentation
• Procedures
• Standards
• Operations manuals
• Direct interviews with end users

8
Translating Business Rules to Data Model
Components

• Standardize companys 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

9
The Evolution of Data Models
We will look briefly at each Model Type
10
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 (1M) relationships
• Between a parent and its children segments
• Each parent can have many children
• each child has only one parent

11
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)

12
The Network Model

• Resembles hierarchical model
• Difference child can have multiple parents
• Collection of records in 1M relationships
• Set Relationship of at least two record types
• Owner Equivalent to the hierarchical models
  parent
• Member Equivalent to the hierarchical models
  child

13
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

14
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

15
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
• Todays PCs run sophisticated relational databases

16
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

17
Relational Model Relational Diagram

• Representation of relational databases
• Entities (Tables)
• Attributes within those entities (Fields)
• Relationships between those entities (Links)

18
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

19
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

20
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

21
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

22
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

23
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 models entity
• Includes info about relationships between facts
  within object and relationships with other
  objects
• Unlike relational models entity

24
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

25
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

26
Object Role Modeling (ORM)
27
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

28
Database Models and the Internet

• Internet drastically changed role and scope of
  database market
• Growing need to manage unstructured information
• The data found in todays
• Online documents
• Web pages
• Most modern DBMS incorporate Internet-age
  technologies such as Extended Markup Language
  (XML) support

29
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

30
Data Models Summary
31
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

32
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

33
The External Model

• Each end users view of the data environment
• Modeler subdivides requirements and constraints
  into functional (Business units) modules
• These can be examined within the framework of
  their external models

34
External Model Advantages

• Easy to identify specific data required to
  support each business units operations
• Facilitates designers job by providing feedback
  about the models adequacy
• Creation of external models helps to identify and
  ensure security constraints in the database
  design
• Simplifies application program development

35
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

36
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

37
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

38
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

39
Degrees of Data Abstraction - Summary
40
Fin