1. DATA MODELS Siti Nurbaya Ismail Senior Lecturer
Faculty of Computer & Mathematical Sciences
Universiti Teknologi MARA Kedah (e): sitinurbaya{at}kedah{dot}uitm {dot}edu{dot}my (u):

2. Chapter 2: Data Models
2.0 DATA MODELS 2.1 The Importance of Data Models 2.2 Data Model Basic Building Blocks 2.3 Business Rules 2.4 The Evolution of Data Models 2.5 Degrees of Data Abstraction

3. 2.0 Data Models 2.1 The Importance of Data Models
Relatively simple 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
Implementation of data model in specific database system
Data Model
Database Model

4. 2.0 Data Models 2.2 Data Model Basic Building Blocks
Entity
anything about which data are to be collected and stored
Attribute
characteristic of an entity
Relationship
describes an association among entities
Constraint
restriction placed on the data

5. 2.0 Data Models 2.2 Data Model Basic Building Blocks
Entity
Attribute
Relationship
Constraint

6. 2.0 Data Models 2.3 Business Rules
Brief, precise, and unambiguous descriptions of policies, procedures, or principles within a specific 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

7. 2.0 Data Models 2.3 Business Rules
Must be rendered in writing
Must be kept up to date
Sometimes are external to the organization
Must be easy to understand and widely disseminated
Describe characteristics of the data as viewed by the company:
corresponds to a table (ERD)
Entities
associations between entities
Relationships
characteristics of entities
Attributes
describe the relationship classification
Connectivity
limitations on the type of data accepted
Constraints

8. 2.0 Data Models 2.3 Business Rules: Discovering Business Rules
Sources of Business Rules
Company managers
Policy makers
Department managers
Written documentation
Procedures
Standards
Operations manuals
Direct interviews with end users

9. 2.0 Data Models 2.3 Business Rules: Business Rules Example
One student can register many subjects
A painter can paint many paintings; each paining is painted by one painter. A gallery can have many paintings. A painting can be exhibited by a gallery.

10. 2.0 Data Models 2.3 Business Rules:
Translating Business Rules into Data Model Components
Standardize company’s view of data
Act as a communications 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

11. 2.0 Data Models 2.3 Business Rules: Discovering Business Rules
Generally;
Nouns translate into entities
Verbs translate into relationships among entities
Relationships are bi-directional
Fact finding techniques:
The formal process of using techniques such as interview and questionnaire to collect facts about system, requirements and preferences.
To captures the essential facts necessary to build the required database
What facts are collected?
Captured facts about the current and/or future system

12. 2.0 Data Models 2.3 Business Rules: Fact Finding Techniques
Examining documents
Interviewing
Observation the organization in operations
Research
Questionnaire
5 commonly used fact finding techniques

13. The Evolution
of Data Models

14. 2.0 Data Models 2.4 The Evolution of Data Models
Hierarchical Database Model
Represented by a group of records that relates to each others by a pointer  Root & Child
Network Database Model
Based on set theory, a set consists a collection of records  Owner & Member
Relational Database Model
Based on the mathematical concept of relational
Object-Oriented Model
Based on object oriented concepts
Hierarchical Database Model
Represented by a group of records that relates to each others by a pointer
Network Database Model
Based on set theory, a set consists a collection of records
Relational Database Model
Based on the mathematical concept of relational
Object-Oriented Model
Based on object oriented concepts

15. 2.0 Data Models 2.4 The Evolution of Data Models
Developed in the 1960s to manage large amounts of data for complex manufacturing projects
Basic logical structure is represented by an upside-down “tree” or by a group of records that relates to each others by a pointer
The uppermost record is a Root/Parent
The lower record in a hierarchy is a Child
Depicts a set of one-to-many (1:M) relationships between a parent and its children segments
Each parent can have many children
Each child has only one parent
Can only support 1:1 and 1:M relationships where a child can only have one parent
Hierachical Database Model

16. 2.0 Data Models 2.4 The Evolution of Data Models
Hierachical Database Model

17. Data Models The Evolution of Data Models
Hierachical Database Model
Abu
Johor
3000
Samad
Kedah
2500
A001
A002
A003
Nut
Washer
Hammer
Bolt
Root
A004
Zaitun
Melaka
4500

18. Data Models The Evolution of Data Models
Hierachical Database Model
Root Segment
Source:

19. 2.0 Data Models 2.4 The Evolution of Data Models
Advantages
of Hierachical Database Model
Disadvantages
of Hierachical Database Model
Many of the hierarchical data model’s features formed the foundation for current data models
Its database application advantages are replicated, albeit in a different form, in current database environments
Generated a large installed (mainframe) base, created a pool of programmers who developed numerous tried-and-true business applications
Complex to implement
Difficult to manage
Lacks structural independence
Implementation limitations
Lack of standards

20. 2.0 Data Models 2.4 The Evolution of Data Models
Develop in 1970 in Conference on Data Systems Languages (CODASYL), by Database Task Group (DBTG)
Created to:
Represent complex data relationships more effectively
Improve database performance
Impose a database standard
Resembles hierarchical model
Collection of records in 1:M relationshops
Network Database Model

21. 2.0 Data Models 2.4 The Evolution of Data Models
Set
Relationship
Composed of at least two record types
Owner
Equivalent to the hierarchical model’s parent
Member
Equivalent to the hierarchical model’s child
A parent can have many child records
A child can have more than one parent record
Network Database Model

22. 2.0 Data Models 2.4 The Evolution of Data Models
Network Database Model

23. Data Models The Evolution of Data Models
Network Database Model
Abu
Samad
Zaitun
Johor
Kedah
Melaka
3000
2500
4500
A001
A002
A003
Nut
Washer
Hammer
Bolt
A004
CUSTOMER
PRODUCT
INVOICE

24. Data Models The Evolution of Data Models
Network Database Model
Source:

25. 2.0 Data Models 2.4 The Evolution of Data Models
Disadvantages
Too cumbersome / difficult to handle
The 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
Many database old-timers can recall the interminable information delays
Network Database Model

26. 2.0 Data Models 2.4 The Evolution of Data Models
Developed by Codd (IBM) in 1970, considered ingenious but impractical in 1970
Conceptually simple, based on mathematical concept of relational
Backwards, computers lacked power to implement the relational model
Today, microcomputers can run sophisticated relational database software
Relational Database Management System (RDBMS)
Performs same basic functions provided by hierarchical and network DBMS systems, in addition to a host of other functions
Most important advantage of the RDBMS is its ability to hide the complexities of the relational model from the user
Relational Model

27. 2.0 Data Models 2.4 The Evolution of Data Models
Relational Model
Matrix consisting of a series of row/column intersections
Related to each other through sharing a common entity characteristic
Table (relations)
Representation of relational database’s entities, attributes within those entities, and relationships between those entities
Relational diagram
Stores a collection of related entities
Resembles a file
Relational Table
How data are physically stored in the database is of no concern to the user or the designer
This property became the source of a real database revolution
Relational table is purely logical structure

28. 2.0 Data Models 2.4 The Evolution of Data Models
Example of table structure/relational table
Relational Model

29. 2.0 Data Models 2.4 The Evolution of Data Models
Example of table with data/relational table
Relational Model

30. 2.0 Data Models 2.4 The Evolution of Data Models
Example of table relationship/relational diagram
Relational Model
Relationship: An employee has one department.
One department has many employee.
EMPLOYEE
DEPARTMENT
has 1 M

31. 2.0 Data Models 2.4 The Evolution of Data Models
Rise to dominance due in part to its powerful and flexible query language
Structured Query Language (SQL) allows the user to specify what must be done without specifying how it must be done
SQL-based relational database application involves:
User interface
A set of tables stored in the database
SQL engine
Relational Model

32. 2.0 Data Models 2.4 The Evolution of Data Models
Entity Relationship (E-R) Model
Introduced by Chen in 1976
Widely accepted and adapted graphical tool for data modeling
Graphical representation of entities and their relationships in dB structure
Entity Relationship Diagram (ERD)
Uses graphic representations to model database components
Entity is mapped to a relational table
Relational Model

33. 2.0 Data Models 2.4 The Evolution of Data Models
Example of ERD
Relational Model
Chen
Crow’s Foot

34. 2.0 Data Models 2.4 The Evolution of Data Models
Modeled both data and their relationships in a single structure known as an object
OO data model (OODM) is the basis for the OO database management system (OODBMS)
Object Oriented Model

35. 2.0 Data Models 2.4 The Evolution of Data Models
Object described by its factual content
Like relational model’s entity
Includes information about relationships between facts within object, and relationships with other objects
Unlike relational model’s entity
Subsequent OODM development allowed an object to also contain all operations
Object becomes basic building block for autonomous structures
Object Oriented Model

36. 2.0 Data Models 2.4 The Evolution of Data Models
Object is an abstraction of a real-world entity
Attributes describe the properties of an object
Objects that share similar characteristics are grouped in classes
Classes are organized in a class hierarchy
Inheritance is the ability of an object within the class hierarchy to inherit the attributes and methods of classes above it
Object Oriented Model

37. 2.0 Data Models 2.4 The Evolution of Data Models
A comparison of the OO model and the ER model
Object Oriented Model

38. 2.0 Data Models A 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

39. 2.0 Data Models A Summary
Semantic data - data is organized in such a way that it can be interpreted meaningfully without human intervention

40. 2.0 Data Models A Summary

41. Degrees of Data Abstraction

42. 2.0 Data Models 2.5 Degrees of Data Abstraction
Way of classifying data models
Data abstraction:
hides extraneous information regarding data storage away from database user
Many processes begin at high level of abstraction and proceed to an ever-increasing level of detail
Designing a usable database follows the same basic process
The major purpose of a database system is to provide users with an abstract view of the system.
The system hides certain details of how data is stored and created and maintained
Complexity should be hidden from database users.

43. 2.0 Data Models 2.5 Degrees of Data Abstraction
American National Standards Institute (ANSI) Standards Planning and Requirements Committee (SPARC)
Three Level ANSI-SPARC Architecture
Defined a framework for data modeling based on degrees of data abstraction(1970s):
The famous “Three Level ANSI-SPARC Architecture”
External
Conceptual
Internal

44. 2.0 Data Models 2.5 Degrees of Data Abstraction: Data Abstraction Levels

45. Data Models Three Level ANSI-SPARC Architecture
View 1
View 2
View n
Conceptual Schema
Internal Schema
Database
User n
User 2
User 1 …
-user’s view
External Model
1. External level
ERD
Conceptual Model
-designer’s view
-h/w independent
-s/w independent
2. Conceptual level
-DBMS’s view
-h/w independent
-s/w dependent
Internal Model
3. Internal level
-h/w dependent
-s/w dependent
Physical Model
Physical data
organization

46. 2.0 Data Models 2.5 Degrees of Data Abstraction: External Model
End users’ view of the data environment
Requires that the modeler subdivide set of requirements and constraints into functional modules that can be examined within the framework of their external models
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 ensure security constraints in the database design
Simplifies application program development

47. 2.0 Data Models 2.5 Degrees of Data Abstraction: Conceptual Model
Global view of the entire database  concept of the dB
Describe what data is stored in the dB and relations among the data
Data as viewed by the entire organization  logical structure  communication tool between users and designer
Basis for identification and high-level description of main data objects, avoiding details  use as basic database bluprint
Most widely used conceptual model is the entity relationship (ER) model
Provides a relatively easily understood macro level view of data environment
Software and Hardware Independent
Does not depend on the DBMS software used to implement the model
Does not depend on the hardware used in the implementation of the model
Changes in either hardware or DBMS software have no effect on the database design at the conceptual level

48. 2.0 Data Models 2.5 Degrees of Data Abstraction: Internal Model
Representation of the database as “seen” by the DBMS
Describes how the data is stored in the dB
Maps the conceptual model to the DBMS
Internal schema depicts a specific representation of an internal model
Physical representation of the dB on the computer
Software Dependent and Hardware Independent
Depend on the DBMS software used to implement the model
Does not depend on the hardware used in the implementation of the model

49. 2.0 Data Models 2.5 Degrees of Data Abstraction: Internal Model
The Physical Model
Operates at lowest level of abstraction, describing the way data are saved on storage media such as disks or tapes
how the data is stored in the database
Software and Hardware Dependent
Requires that database designers have a detailed knowledge of the hardware and software used to implement database design

50. 2.0 Data Models 2.5 Degrees of Data Abstraction

54. 2.0 Data Models Summary
A data model is a (relatively) simple abstraction of a complex real-world data environment
Basic data modeling components are:
Entities
Attributes
Relationships
Constraints
Data modeling requirements are a function of different data views (global vs. local) and level of data abstraction

55. 2.0 Data Models Summary Hierarchical Database Model
Represented by a group of records that relates to each others by a pointer  Parent & Child  1:1 & 1:M
Network Database Model
Based on set theory, a set consists a collection of records  Owner & Member  1:1& 1:M & M:N
Relational Database Model
Based on the mathematical concept of relational
Object-Oriented Model
Based on object oriented concepts
Hierarchical Database Model
Represented by a group of records that relates to each others by a pointer
Network Database Model
Based on set theory, a set consists a collection of records
Relational Database Model
Based on the mathematical concept of relational
Object-Oriented Model
Based on object oriented concepts

56. Exercise 1
It is important to understand business rules when designing a database.
Define business rules.
(1 mark) 
State TWO (2) reasons the importance of business rules in database design.
(2 marks) 
Give ONE (1) example of business rules.

57. Exercise 2
Briefly explain the hierarchical and network database model, and what is the difference between those two database models? (6 marks)

58. Exercise 3
What is the different between external, conceptual and internal model? (7 marks)

59. Exercise 4
What is a conceptual model and why it is important in database design? (4 marks)