- data models

8/8/2019 - Data Models

http://slidepdf.com/reader/full/-data-models 1/40

1

Data Models

By

Bob Larson



2

Overview

Why data models are important

Basic data-modeling building blocks

What are business rules and how dot hey influence database design

How t he major data models evolved

How data models can be classif ied bylevel of abstract ion



3

Importance of Data Models

Data models Representat ions, usually graphical, of complex real-world data structures

Facilitate interact ion among t he designer,t he applicat ions programmer and t he enduser

End-users have different views andneeds for data

Data model organizes data for varioususers



4

Data Model Basic Building Blocks

Ent ity Anyt hing about which data will be collected/stored

Attribute Characterist ic of an ent ity

Relat ionship Describes an associat ion among ent it ies

One-to-one (1:1) relat ionship

One-to-many (1:M) relat ionship

Many-to-many (M:N or M:M) relat ionship

Constraint A restrict ion placed on t he data



5

Business Rules

Brief, precise and unambiguousdescript ions of policies, procedures or

princi

ples wit hi

n t he organ

izat ion

Apply to any organizat ion t hat storesand uses data to generate informat ion

Descript ion of operat ions t hat help tocreate and enforce act ions wit hin t hat organizat ions environment



6

Business Rules (cont inued)

Must be put in writ ing

Must be kept up to date

Somet imes external to t he organizat ion Must be easy to understand and widely

disseminated

Describe characterist ics of t he data asviewed by t he company



7

Discovering Business Rules

Company managers

Policy makers

Department managers Written documentat ion

Procedures

Standards Operat ions manuals

Direct interviews wit h end users



8

Translat ing Business Rulesto Data Model Components

Standardize companys view of data

Communicat ion tool between users anddesigners Allow designer to understand t he nature, role and

scope of data

Allow designer to understand business processes

Allow designer to develop appropriate relat ionshippart icipat ion rules and constraints

Promote creat ion of an accurate data model

Nouns translate into ent it ies

Verbs translate into relat ionships among ent it ies

Relat ionships are bi-direct ional



9

The Evolut ion of Data Models

We will look briefly at each Model Type



10

The Hierarchical Model

Developed in 1960s to manage large amounts of data forcomplex manufacturing projects

Logic

al structure represented as an ups

ide-down tree

Hierarchical structure contains levels or segments

Depicts a set of one-to-many (1:M) relat ionships 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 t he foundat ion for current data models

Generated a large installed base of programmers Who developed solid business applicat ions

Disadvantages

Complex to implement

Diff icult to manage

Lacks structural independence

Implementat ion limitat ions

Lack of standards (Company vs Industry or Open)



12

The Network Model

Resembles hierarchical model Difference child can have mult iple parents

Collect ion of records in 1:M relat ionships

Set Relat ionship of at least two record types Owner Equivalent to t he hierarchical models parent

Member Equivalent to t he hierarchical models child



13

Network Model Terms

Schema Conceptual organizat ion of ent ire database As viewed by t he database administrator

Subschema Def ines database as seen by t he applicat ion programs

Schema Data Def init ion Language (DDL) Enables database administrator to def ine schema components

Subschema Data Def init ion Language (DDL) Allows applicat ions to def ine database components to be used

Data Management Language (DML) Def ines t he environment in which data can be managed Works wit h t he data in t he database



14

Network Model

Advantages

Represents complex data relat ionships better t hanHierarchical 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 t he database could produce havoc in all applicat ion programs t hat drew data from t he database



15

The Relat ional Model

Conceptually simple Linked Tables

Developed by Edgar F. Codd (IBM 1970 ) Considered ingenious but impract ical in 1970

Computers lacked power to implement t he relat ional model

Todays PCs run sophist icated relat ional databases



16

Relat ional Model Tables

Also called relat ions

Matrix of row and column intersect ions

Stores a collect ion of similar ent it ies

Resembles a f ile or spreadsheet

Purely logical structure How data are physically stored is of no concern to

t he user or t he designer

The source of a real database revolut ion



17

Relat ional Model Relat ional Diagram

Representat ion of relat ional databases

Ent it ies (Tables)

Attributes wit hin t hose

ent it ies (Fields)

Relat ionships betweent hose ent it ies (Links)



18

Relat ional Model RDBMS

Relat ional Database Management System

All t he system components User interface

Tables

Met hod of querying t he tables

Performs same basic funct ions as

Hierarchical and

Network DBMS models

Plus many ot her funct ions

Most important hides t he complexit ies of t herelat ional model from t he user



19

The Relat ional Model SQL

Structured Query Language (SQL)

Allows ad hoc queries quest ions of t he data

User can specify what must be done wit hout

specifying how it must be done

Dominance due in great part to its powerfuland flexible query language

SQL-based relat ional database applicat ion: User interface

A set of tables stored in t he database

SQL engine



20

Ent ity Relat ionship Model (ERM)

Introduced by Peter Chen in 1976

Widely accepted and adapted graphical toolfor data modeling

Graphical representat ion of ent it ies and t heir

relat ionships in a database structure



21

Ent ity Relat ionship Model Terms

Ent ity Relat ionship Diagram (ERD)

Graphic representat ions to model database components

Ent ity

is mapped to a relat

ional table

Ent ity instance (or occurrence) A row in table

Ent ity set (table) Collect ion of like ent it ies

Connect ivity labels

Diamond connected to related ent it ies t hrough a relat ionship line

Types of relat ionships



22

ERM Notat ion Symbols

Three symbols to represent element relat ionships Ring represents "zero"

Dash represents "one"

Crow's foot represents "more" or "many"

Used in pairs to represent t he four types of

relat ionships 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 bot h data and t heir relat ionships in a singlestructure known as an object

Object described by its factual content Like relat ional models ent ity

Includes info about relat ionships between factswit hin object and relat ionships wit h ot her objects

Unlike relat ional models ent ity



24

Object Oriented Model Terms

Object-oriented data model (OODM)

Semant ic data model

Basis of object-oriented database management system(OODBMS)

Evolved to allow an object to also contain all operat ions Object abstract ion of a real-world ent ity

Basic building block for autonomous structures

Attributes propert ies of an object

Class - objects t hat share similar Classes are organized in a class hierarchy

Inheritance an object wit hin t he class hierarchyinherits t he attributes and met hods of class



25

Extended Relat ional Data Model (ERDM)

Semant ic data model

Developed in response to increasingcomplexity of applicat ions

Based heavily on relat ional model

Relat ional DB response to OODM

Primarily geared to business applicat ions

Typically scient if ic or engineering apps

Object/relat ional database management system (O /RDBMS)

DBMS based on t he ERDM



26

Object Role Modeling (ORM)



27

ORM

Not to be confused wit h Object-relat ional mapping Provides a conceptual approach to modeling Models t he applicat ion area or universe of discourse (UoD)

Relevant set of ent it ies t hat are being dealt wit h by quant if iers Requires a good understanding of t he UoD Means of specifying t his understanding in a clear, unambiguous

way

Simplif ies design process wit h natural language and intuit ivediagrams Can be populated wit h examples

Evolved from t he Natural language Informat ion Analysis Met hod Mid-1970s G. M. Ni jssen and Dr. Terry Halpin f irst joint papers in 1989

Capable of capturing many business rules typically unsupportedin ot her popular data modeling notat ions

Software tool support include Microsoft Visio for Enterprise Architects, CaseTalk, Infagon and NORMA



28

Database Models and t he Internet

Internet drast ically changed role and scope of database market

Growing need to manage unstructured

informat ion The data found in todays:

Online documents

Web pages

Most modern DBMS incorporate Internet-agetechnologies such as Extended MarkupLanguage (XML) support



29

Data Models: Summary

Each new data model capitalized on t heshort comings of previous models

Common characterist ics:

Conceptual simplicity wit hout compromising t hesemant ic completeness of t he database

Represent t he real world as closely as possible

Representat ion of real-world transformat ions

(behavior) must comply wit h consistency andintegrity characterist ics of any data model



30

Data Models: Summary



31

Degrees of Data Abstract ion

Way of classifying data models

Many processes begin at high level of

abstract ion

Proceed to an ever-increasing level of detail

Designing a usable database follows t he

same basic process



32

Degrees of Data Abstract ion

American Nat ionalStandards Inst itute (ANSI)

Standards Planning andRequirements Committee

(SPARC) Developed standards 1970

Framework for datamodeling based on degreesof data abstract ion:

External Conceptual

Internal

Physical



33

The External Model

Each end users view of t he data environment Modeler subdivides requirements and constraints into

funct ional (Business units) modules These can be examined wit hin t he framework of t heir

external models



34

External Model Advantages

Easy to ident ify specif ic data required tosupport each business units operat ions

Facilitates designers job by providing

feedback about t he models adequacy

Creat ion of external models helps to ident ifyand ensure security constraints in t hedatabase design

Simplif ies applicat ion program development



35

The Conceptual Model (1 of 2)

Global view of t he ent ire database

Representat ion of data as viewed by t he ent ireorganizat ion

Basis for ident if icat ion and high-level descript ion 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 eit her hardware or DBMS

software have no effect on t he databasedesign at t he conceptual level

Most widely used conceptual modelis t he Ent ity Relat ionship (ER) model Provides a relat ively easily understood

macro level view of data environment



37

The Internal Model

The database as seen by t he DBMS

Maps t he conceptual model to t he DBMS

Depicts a specif ic representat ion of an internal model

Logical independence

Can change t he internal model wit hout affect ing t he

conceptual model



38

The Physical Model

Lowest level of abstract ion

Describes t he way data are saved onstorage media such as disks or tapes

Software and hardware dependent Requires database designers to have

a detailed knowledge of t he hardwareand software used to implement database design

Physical independence Can change t he physical model

wit hout affect ing t he internal model



39

Degrees of Data Abstract ion - Summary



40

Fin

- data models

Documents