1

Data Models

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 (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

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 organization’s 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 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

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 (1:M) relationships

Between a parent and it’s 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 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

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

Today’s 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 database’s

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 model’s entity

Includes info about relationships between facts within object and relationships with other objects

Unlike relational model’s 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 today’s:

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 unit’s) 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 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

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

THANK YOU