INFS601

Data Models
Learning Objectives
In this session, you will learn:
• About data modelling and why data models are important
• Types of Data Models
• How data models can be classified by their level of
abstraction
• ANSI/SPARC three Schema architecture
• What business rules are and how they influence database
design

2
Limitations/disadvantages of File Systems
Data Redundancy: Unnecessarily storing same data at different places

Data inconsistency: different and conflicting versions of same data occur at

different places
Lengthy development times and extensive programming: developers must
design their own file formats. It requires extensive programming.

Limited data sharing: No centralized control of data

Program-Data Dependence: Changing the structure or storage characteristics

of data would require changing the applications that accesses it.

Lecture Slide 3
Data Models
• Model - Abstraction of a real-world object or event
• Data models:
- Collection of related concepts used to describe the
structure of a database, i.e. unique objects, data types,
relationships, and constraints
• Useful for supporting a specific problem domain
• Simple representations of complex real-world data
structures

4
Types of Data Models
• Conceptual data model: models to represent high level
concepts close to how the user perceives the data
- e.g. Entity Relationship Model, Object-Oriented Model

• Logical model: models that can be implemented on a

computer system. Concepts are not too far from physical
data organization (hide data storage details) but yet may
be understood by end users to some extent
- e.g. the hierarchical model, network model, relational model

• Physical model: low level concepts that describe the

physical storage details
5
Conceptual Data Modelling
• Develop preliminary conceptual data model, including
entities and relationships.
• Develop detailed conceptual data model, including all
entities, relationship , attributes and business rules.

6
Logical Data Model
After designing a database using an ER model, how do we
implement it in a DBMS?
We need to transform the ER model to the logical data model
supported by the DBMS that we choose
In general, 3 logical data models exist
• Hierarchical model
• Network model
• Relational model

7
Hierarchical Database Model
DEPARTMENT

EMPLOYEE PROJECT

• Developed in the 1960s to manage large amounts of data for manufacturing

projects
• Files are arranged in a top-down structure that resembles a tree.
• The top file is called the root. The bottom files are called leaves and
intermediate files have one parent and one or several children.
• Data are related in a nested, one-to-many set of relationships.
8
Network Database Model
• Created to represent complex data relationships more effectively than the hierarchical
model
• Improves database performance
• Imposes a database standard
• Each file may be associated with an arbitrary number of files.
• Significant overhead in storage space and maintenance time.

DEPARTMENT

EMPLOYEE PROJECT

9
Network Database Model

10
Hierarchical and Network Models
Hierarchical Models Network Models

• Developed to manage • Created to represent

large amounts of data complex data relationships
for complex effectively
manufacturing projects
• Improved database
• Represented by an performance and imposed a
upside-down tree which database standard
contains segments
(equivalent of a file • Allows a record to have
system’s record type) more than one parent
• Depicts a set of one-to- • Depicts both one-to-many
many (1:M) relationships (1:M) and many-to-many
(M:N) relationships

11
The Relational Model
• Developed by E.F. Codd (IBM) in 1970
• Table (relations)
- Matrix consisting of row/column intersections
- Each row in a relation is called a tuple
• Model was conceptually simple at expense of computer
overhead
• Relational data management system (RDBMS)
- Performs same functions provided by hierarchical model
- Hides complexity from the user
• Relational diagram
- Representation of entities, attributes, and relationships
• Relational table stores collection of related entities
Lecture Slide 12
The Relational Model

Lecture Slide 13
Degrees of Data Abstraction
• Database designer starts with abstracted view, then
adds details
• Defined a framework for data modeling based on
degrees of data abstraction (1970s):
- External
- Conceptual
- Internal
- Physical

Lecture Slide 14
Three-schema Architecture
• The External Schema

- end users’ view of the data environment

- specific representation of an external view: entities,
relationships, processes and constraints

• The Conceptual Schema

- all external views integrated into single global view: combined user views which are
normalised.
- independent of both hardware and software

• The Internal Schema

- Representation of the database as “seen” by the DBMS (maps the conceptual model
to the DBMS)
- Internal schema depicts a specific representation of an internal model
- Depends on specific database software (change in DBMS software requires internal
model be changed) 15
Degrees of Data Abstraction

Lecture Slide 16
 ANSI/SPARC Three Schema Architecture

External User User User

views
View 1 View 2 View 3
Consolidation
Consistency
Completeness
Conceptual
Schema Efficiency
Security
Integrity
Internal
DBMS dependent.
Schema
Programs and
Access Methods

Physical
Data
organisation

17
ANSI/SPARC: American National Standards Institute/Standards Planning and Requirements Committee
Logical Database Design
• Map the conceptual data model into a logical data model
- Hierarchical, Network, Relational
• Analyse in detail the transactions, forms, displays and reports
required by the business functions supported by the database
• Identify data integrity and security requirements

18
Physical Database Design
• Define the logical database design to the chosen DBMS
• Decide on physical organisation of the data
• Access methods, Backup and Recovery, Performance

19
Degrees of Data Abstraction

External view
Conceptual view
Lecture Slide 20
Degrees of Data Abstraction

Internal view

Physical view
BH RH Tony Abbott 150790 Analyst 10 RH Brian Thomas…

01110110011000101000100111000010000100110011100100….

Lecture Slide 21
Terms and Concepts

Schema

• Conceptual organization of the entire database as viewed by the database

administrator

Subschema

• Portion of the database seen by the application programs that produce the
desired information from the data within the database

22
Terms and Concepts
Program-Data Independence: Changing the structure or storage
characteristics of data would not require changing the applications that
accesses it. Only the data dictionary needs to be updated, but not the
applications!

Lecture Slide 23
Data Independence
Data Independence: Capacity to change the schema at one level of a database system without
having to change the schema at the next higher level.

Logical data independence:

• Capacity to change the conceptual schema without having to change external views or
application programs.
‒ Recoding, adding fields (e.g. adding an email address to a student file) in the database should not
affect applications

Physical data independence:

• Capacity to change the internal schema without having to change conceptual (or external) schemas or
application programs.
‒ The application doesn’t need to know how or where the database has stored the data, but just how to ask for it.
‒ Moving a database from one DBMS to another should not have an impact on the application programs that access
the database
‒ Changing the access method should not have an impact on the application programs that access the database

24
ANSI / SPARC
Three Schema Architecture

User User User

External
views View 1 View 2 View 3
Logical Data
Independence

Conceptual
Schema Physical data
independence

Internal
Schema

American National Standards Institute / Standards Planning and Requirements Committee

25
Exercise
Consider each of the following changes to a database. Assuming
that an application program is unaffected by the change indicate
whether it is an example of logical or physical data independence.
1. Move the data to newer, faster storage device.
2. Change from indexed sequential access method (ISAM) to virtual
sequential access method (VSAM)
3. Add a new data item called CARPOOL to an existing EMPLOYEE
record type.
4. Add a new record type called TEXTBOOK to an instructional data
base

Lecture Slide 26
Business Rules
Succinct 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 to create/enforce actions within
an organization’s environment
• Must be in writing and kept up to date
• Must be easy to understand and widely disseminated
Describe characteristics of data as viewed by the
company
Lecture Slide 27
Business Rules-Examples
• A customer may generate many invoices.
• An invoice is generated by only one customer.
• A training session cannot be scheduled for fewer than
10 employees or for more than 30 employees.

Lecture Slide 28
Discovering Business Rules
Sources of business rules:
• Company managers
• Policy makers
• Department managers
• Written documentation
‒ Procedures
‒ Standards
‒ Operations manuals
• Direct interviews with end users

Lecture Slide 29
Translating Business Rules into Data Model
Components
• Nouns translate into entities
• Verbs translate into relationships among entities
• Relationships are bidirectional
• Questions to identify the relationship type
• How many instances of B are related to one instance of A?
• How many instances of A are related to one instance of B?
‒ More about this in the upcoming sessions..

30
Summary
• A data model is a simple representations of complex
real-world data structures
• Types of data models
• Degree of abstraction, ANSI/SPARC three schema
architecture
• Business rules identify and define basic modeling
components

Lecture Slide 31
Homework
• Complete review questions from Coronel/Morris/Rob
text book, Chapter 2.
• Solve the problems from Coronel/Morris/Rob text book,
Chapter 2.
• Reading for next week: Coronel/Morris/Rob, Chapter 3.

Lecture Slide 32