CC – 105 : Information Management – 1

Chapter 3

DATA MODELING CONCEPTS

Objectives:

At the end of this chapter, the students should be able to:

 Understand the concept of data modeling and why data models are important
 Know the basic building blocks of data modeling
 Understand the concept of business rules and how does it affect to the design of a
database
 Know the different types of data modeling used in database design
 Know the levels of data abstraction

 WHAT IS A DATA MODEL?

A data model pertains to the organization data elements and standardizes how the data
elements relate to one another. Data models describe structured data for storage in data
management systems.

A very important aspect about a data model is that when it is implementation – ready, it should
contain at least the following components:

 A description of the data structure that will store the end – user data.
 A set of enforceable rules to guarantee the integrity of the data.
 A data manipulation methodology that supports the real – world data transformations.

 HOW IMPORTANT IS A DATA MODEL?

Data models can facilitate interaction among the designer, the applications programmer, and
the end user. This means that a well – developed data model can even foster improved
understanding of the organization for which the database design is developed.

A comprehensive and optimized data model helps create a simplified, logical database that
eliminates redundancy, reduces storage requirements, and enables efficient retrieval. It also
equips all systems with a ‘single source of truth’ – which is essential for effective operations and
provable compliance with regulations and regulatory requirements.

 BUILDING BLOCKS OF A DATA MODEL

In its basic sense, a data model has the following:

 Entity. It represents a particular type of object in the real world. Because an entity
represents a particular type of object, entities are “distinguishable”—that is, each entity
occurrence is unique and distinct. (e.g. STUDENT )

 Attribute. It is a characteristics of an entity. Attributes are the equivalent of fields in

file systems. (e.g. Student Number, Last Name, First Name )

 Relationship. It describes an association among entities. Data models uses three

types of relationships: one – to – one (1:1), one – to – many (1:M), and many – to –

Prepared by: Christian A. Fajardo, MACE 17

 CC – 105 : Information Management – 1

many (M:M). (e.g. a STUDENT belongs to a SECTION, a STUDENT is enrolled at

many SUBJECTS )

 Constraints. It is a restriction placed on the data. Constraints are important because

they help to ensure data integrity. These are normally expressed in the form of rules.
(e.g. STUDENT passes a SUBJECT if its grade is between 1.00 and 3.00 , a
STUDENT NUMBER should be assigned to one and only one STUDENT )

 THE CONCEPT ON BUSINESS RULES

To properly identify entities, attributes, relationships, and constraints in the database system
you are developing, the first step would be always identifying clearly its business rules.

A business rule is a brief, precise, and unambiguous description of a policy, procedure, or

principle within a specific organization. Keep in mind that from a database point of view, the
collection of data becomes meaningful only when it reflects properly defined business rules.

Examples:

 A STUDENT may enroll many SUBJECTS.

 A STUDENT NUMBER is generated to only one STUDENT.
 A STUDENT is enrolled in one and only one COURSE.

But why business rules are essential to database design? The following reasons may
explain the said query:

 To standardize the company’s view of data.

 To constitute communication between users and designers.
 To allow the designer to understand the nature, role, and scope of the data.

 WHAT ARE THE TYPES OF DATA MODELS?

The following data models basically represent the “schools of thought” as to what a database
is, and what it should do:

 Hierarchical Model. Developed in the 1960s, its basic logical structure is

represented by an upside – down “tree”. The hierarchical structure contains levels, or
segments. It basically depicts a set of one-to-many (1:M) relationships between a
parent and its children segments in which each parent can have many children and
each child has only one parent.

Figure 1. The Hierarchical Data Model Structure

Prepared by: Christian A. Fajardo, MACE 18

 CC – 105 : Information Management – 1

 Network Model. Unlike the hierarchical model, the network model allows a record to
have more than one parent. It was created based from the hierarchical model due to
the following reasons:

 To represent complex data relationships more effectively.

 To improve database performance.
 To impose a database standard.

While the network database model is generally not used today, the definitions of
standard database concepts that emerged with the network model are still used by
modern data models. And these are:

 Schema. Conceptual organization of entire database as viewed by the

database administrator.

 Subschema. Defines database portion “seen” by the application programs

that actually produce the desired information from data contained within the
database

 Data Management Language (DML). It defines the environment in which data

can be managed.

 Data Definition Language (DDL). It enables database administrator to define

schema components.

Figure 2. A Network Model

 Relational Model. Introduced by E. F. Codd on 1970, the relational model foundation

is a mathematical concept known as a relation. To avoid the complexity of abstract
mathematical theory, you can think of a relation (sometimes called a table) as a matrix
composed of intersecting rows and columns.

Each row in a relation is called a tuple. Each column represents an attribute. The
relational model also describes a precise set of data manipulation constructs based
on advanced mathematical concepts.

The relational data model is implemented through a very sophisticated relational

database management system (RDBMS). In addition to a host of other functions
that make the relational data model easier to understand and implement.

The rise to dominance of the relational data model is due in part to its powerful and
flexible query language such as the Structured Query Language or SQL. Structured

Prepared by: Christian A. Fajardo, MACE 19

 CC – 105 : Information Management – 1

Query Language (SQL) allows the user to specify what must be done without
specifying how it must be done.

Figure 3. An Implementation of the Relational Model

 Object – Oriented Model. Object-oriented data model (OODM) is the basis for the
object-oriented database management system (OODBMS). OODM is said to be a
semantic data model in which it describes the meaning of its instances.

Object described by its factual content like the relational model’s entity. It includes
information about relationships between facts within object, and relationships with
other objects unlike the relational model’s entity. Object becomes a basic building
block for autonomous structures.

Figure 4. An Illustration of the OO Data Model

 WHAT ARE THE LEVELS OF DATA ABSTRACTION?

In the early 1970s, the American National Standards Institute (ANSI) Standards Planning
and Requirements Committee (SPARC) defined a framework for data modeling based on degrees
of data abstraction. The ANSI/SPARC architecture (as it is often referred to) defines three levels
of data abstraction: external, conceptual, and internal.

Figure 4. Data Abstraction Levels

Prepared by: Christian A. Fajardo, MACE 20

 CC – 105 : Information Management – 1

 External Model. The external model is the end users’ view of the data environment.
The term end users refer to people who use the application programs to manipulate
the data and generate information.

End users usually operate in an environment in which an application has a specific

business unit focus. Companies are generally divided into several business units, such
as sales, finance, and marketing.

Each business unit is subject to specific constraints and requirements, and each
one uses a data subset of the overall data in the organization. Therefore, end users
working within those business units view their data subsets as separate from or
external to other units within the organization. Because data are being modeled, ER
diagrams will be used to represent the external views.

A specific representation of an external view is known as an external schema

Figure 5. A sample external view for a student registration data model

 Conceptual Model. The conceptual model represents a global view of the entire
database as viewed by the entire organization. That is, the conceptual model
integrates all external views such as entities, relationships, constraints, and processes
into a single global view of the data in the enterprise. Having identified the external
views, a conceptual model is used, graphically represented by an entity – relationship
diagram (ERD), to integrate all external views into a single view.

Also known as a conceptual schema, it is the basis for the identification and high-
level description of the main data objects, avoiding any database model –specific
details.

Figure 6. The Conceptual View of an Enrollment System

Prepared by: Christian A. Fajardo, MACE 21

 CC – 105 : Information Management – 1

The most widely used conceptual model is the ER model. Remember that the ER
model is illustrated with the help of the ERD, which is, in effect, the basic database
blueprint. The ERD is used to graphically represent the conceptual schema.

 Internal Model. Once a specific DBMS has been selected, the internal model maps the
conceptual model to the DBMS. The internal model (also known as the logical
model) is the representation of the database as “seen” by the DBMS. In other words,
the internal model requires the designer to match the conceptual model’s
characteristics and constraints to those of the selected implementation model.

An internal schema depicts a specific representation of an internal model, using

the database constructs supported by the chosen database.

Figure 7. Conversion from the Conceptual Model to Internal Model

 Physical Model. The physical model operates at the lowest level of abstraction,
describing the way data are saved on storage media such as disks or tapes. The
physical model requires the definition of both the physical storage devices and the
(physical) access methods required to reach the data within those storage devices,
making it both software and hardware dependent.

The storage structures used are dependent on the software such as the DBMS
and the operating system and on the type of storage devices that the computer can
handle. The precision required in the physical model’s definition demands that
database designers who work at this level have a detailed knowledge of the hardware
and software used to implement the database design.

***END OF CHAPTER 3***

Prepared by: Christian A. Fajardo, MACE 22