Data Models

By Bob Larson



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

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

Data Model Basic Building Blocks 


Anything about which data will be collected/stored Characteristic of an entity 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 


A restriction placed on the data

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    Brief. precise and unambiguous descriptions of policies.

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 12 Member Equivalent to the hierarchical model s child .

Network Model Terms  Schema   Conceptual organization of entire database As viewed by the database administrator Defines database as seen by the application programs Enables database administrator to define schema components Allows applications to define database components to be used Defines the environment in which data can be managed Works with the data in the database  Subschema   Schema Data Definition Language (DDL)   Subschema Data Definition Language (DDL)   Data Management Language (DML)   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 How data are physically stored is of no concern to the user or the designer   Purely logical structure  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 20 relationships in a database structure .

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 .

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

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 Typically scientific or engineering apps  Primarily geared to business applications   Object/relational database management system (O/RDBMS)  DBMS based on the ERDM 25 .

Object Role Modeling (ORM) 26 .

Nijssen and Dr. Terry Halpin first joint papers in 1989  Evolved from the Natural language Information Analysis Method     Capable of capturing many business rules typically unsupported in other popular data modeling notations Software tool support include Microsoft Visio for Enterprise Architects. M.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 Mid-1970s G. 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 .

avoiding details 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.

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 37 conceptual model .

The Physical Model  Lowest level of abstraction  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 Can change the physical model without affecting the internal model  Software and hardware dependent   Physical independence  38 .

Degrees of Data Abstraction .Summary 39 .

Fin 40 .