INFORMATION SYSTEMS 2A

PRESENTED BY PROF TANIA PRINSLOO

WEEK 2
 Database Systems:
Design,
Implementation, and
Management, 14e
Module 2: Data Models

Footnote Coronel, Carlos and Morris, Steven, Database Systems: Design, Implementation, and Management, 14 Edition. © 2023 Cengage. All Rights 2
Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 2
Data Modeling and Data Models

Data modeling refers to the process of creating a specific data model for a determined problem domain

Data modeling is an iterative, progressive process

A data model is a relatively simple representation of more complex real-world data structures

Database designers make use of existing data-modeling constructs and powerful database design tools that
diminish the potential for errors in database modeling

Footnote 3
The Importance of Data Models

Data models are a communication tool

Applications are created to manage data and to help transform data into information,
but data is viewed in different ways by different people
A sound data environment requires an overall database blueprint based on an
appropriate data model
When a good database blueprint is available, it does not matter that an applications
programmer’s view of the data is different from that of the manager or the end user
You will be unlikely to create a good database without first creating an appropriate
data model

Footnote 4
Data Model Basic Building Blocks (1 of 2)

An entity is a person, place, thing, concept, or event about which data will be collected
and stored

An attribute is a characteristic of an entity

A relationship describes an association among entities

The following are three different types of relationships:

• One-to-many (1:M or 1..*) relationship

• Many-to-many (M:N or *..*) relationship
• One-to-one (1:1 or 1..1) relationship

Footnote 5
Data Model Basic Building Blocks (2 of 2)

A constraint is a restriction placed on the data

• Constraints help ensure data integrity

Constraints are normally expressed in the form of rules:

• An employee’s salary must have values that are between 6,000 and
350,000
• A student’s final mark must be between 50% and 74% to pass, higher
passes with a distinction, lower fails.
• Each class must have one and only one teacher

Footnote 6
Business Rules

A business rule is a brief, precise, and

They apply to any organization that stores and uses data to
unambiguous description of a policy, procedure, generate information
or principle within a specific organization

Business rules are used to define entities, They must be easy to understand and widely disseminated
attributes, relationships, and constraints

A customer may generate many invoices

Examples of business rules include the following:
An invoice is generated by only one customer

Footnote 7
Discovering Business Rules

The main sources of business rules are company managers, policy makers,
department managers, and written documentation such as company
procedures

Business rules are essential to database design due to the following reasons:
It allows the designer to develop
It allows the designer to appropriate relationship
It helps to standardize the It can be a communication tool It allows the designer to
understand the nature, role, and participation rules and constraints
company’s view of data between users and designers understand business processes
scope of the data and to create an accurate data
model

Footnote 8
Translating Business Rules into Data Model Components

For example, the business rule “a customer may generate many

invoices” contains two nouns and a verb that associates the nouns

Customer and invoice are objects of interest for the

From this business rule, you could environment and should be represented by their
respective entities
deduce the following: There is a generate relationship between customer and
invoice

The rule above is complemented by

the business rule “an invoice is The relationship is one-to-many (1:M)

generated by only one customer”

Footnote 9
Naming Conventions

Entity names should be descriptive of the objects in the business environment

and use technology that is familiar to the users

An attribute name should also be descriptive of the data represented

It is good practice to prefix the name of an attribute with the name or

abbreviation of the entity in which it occurs
• For example, in the CUSTOMER entity, customer’s credit limit may be called CUS_CREDIT_LIMIT

A proper naming convention can help make your model self-documenting

Footnote 10
The Relational Model (1 of 4)

A relation is a two-dimensional structure

The relational model’s foundation is a composed of intersecting rows and columns
mathematical concept known as a
Each row in a relation is called a tuple and each
relation column represents an attribute

The relational data model is implemented The RDBMS performs the same basic functions
through a very sophisticated relational provided by the hierarchical and network DBMS
database management system (RDBMS) systems

The RDBMS manages all of the details, while the users sees a collection of
tables in which the data is stored

Footnote 11
The Relational Model (2 of 4)

Footnote Figure 2.1 Linking Relational Tables 12

The Relational Model (3 of 4)

Footnote Figure 2.2 A Relational Diagram 13

The Relational Model (4 of 4)

• Any SQL-based relational database application involves the following three parts:
• The end user interface – the interface allows the end user to interact with the data
• A collection of tables stored in the database – the tables “present” the data to the end user in a way
that is easy to understand
• SQL engine – the SQL engine executes all queries or data requests

Footnote 14
The Entity Relationship Model (1 of 3)

Complex design activities require conceptual simplicity to yield successful results

Database designers prefer to use a graphical tool

The entity relationship (ER) model (ERM) was developed to do
in which entities and their relationships are just that
pictured

The relational data model and ERM combined to provide the foundation for tightly structured database
design

An entity relationship diagram (ERD) uses graphical representations to model database

components

Footnote 15
The Entity Relationship Model (2 of 3)

The ER model is based on the The following are three ER

following components: notations:
Entity – an entity is represented in the ERD by a Chen notation
rectangle (entity box) Crow’s Foot notation
Attributes – each entity consists of a set of Class diagram notation (part of the Unified
attributes that describes particular Modeling Language (UML))
characteristics of the entity
Relationships – relationships describe
associations among data

Footnote 16
The Entity Relationship Model (3 of 3)

Footnote Figure 2.3 The ER Model Notations 17

Emerging Data Models: Big Data and NoSQL (1 of 3)

Internet of Things (IoT) is a web The IoT has accelerated the rate of data
of Internet-connected devices growth so that about 2.5 quintillion bytes of
exchanging and collecting data data are created daily

Big Data refers to a movement to find new and better ways to manage
large amounts of web- and sensor-generated data and derive business
insight from it

A basic characteristic of Big Data databases can be described as

volume, velocity, and variety, or the 3 Vs

Footnote 18
Emerging Data Models: Big Data and NoSQL (2 of 3)

• Some of the most frequently used Big Data technologies are Hadoop and NoSQL databases:
• Hadoop is a Java-based, open-source, high-speed, fault-tolerant distributed storage and
computational framework
• Hadoop Distributed File System (HDFS) is a highly distributed, fault-tolerant file storage system
designed to manage large amounts of data at high speeds
• MapReduce is an open-source application programming interface (API) that provides fast data
analytics services
• NoSQL is a large-scale distributed database system that stores structured and unstructured data in
efficient ways

Footnote 19
Emerging Data Models: Big Data and NoSQL (3 of 3)

• NoSQL databases have the following general characteristics:

• They are not based on the relational model and SQL
• They support highly distributed database architectures
• They provide high scalability, high availability, and fault tolerance
• They support very large amounts of sparse data
• They are geared toward performance rather than transaction consistency

Footnote 20
Data Models: A Summary

Footnote Figure 2.5 The Evolution of Data Models 21

Degrees of Data Abstraction (1 of 2)

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 three levels of data abstraction are external, conceptual, and
internal

In Figure 2.6, on the following slide, the ANSI/SPARC framework has

been expanded with the addition of a physical model to explicitly
address physical-level implementation details of the internal model

Footnote 22
Degrees of Data Abstraction (2 of 2)

Footnote Figure 2.6 Data Abstraction Levels 23

The External Model (1 of 3)

The external model is the end users’ view of the data environment

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

business unit focus
• End users within those business units view their data subsets as separate from or eternal to other units
within the organization

ER diagrams will be used to represent the external views

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

Footnote 24
The External Model (2 of 3)

Footnote Figure 2.7 External Models for Tiny College 25

The External Model (3 of 3)

• The use of external views that represent subsets of the database has some important advantages:
• It is easy to identify specific data required to support each business unit
• It makes the designer’s job easy by providing feedback about the model’s adequacy
• It helps to ensure security constraints in the database design
• It makes application program development much simpler

Footnote 26
The Conceptual Model (1 of 2)

• The conceptual model represents a global view of the entire database by the entire organization
• Also known as a conceptual schema, it is the basis for the identification and high-level description of
the main data objects
• The most widely used conceptual model is the ER model
• The following are advantages of the conceptual model:
• It provides a bird’s-eye view of the data environment that is easy to understand
• The conceptual model is independent of both software and hardware
• The term logical design refers to creating a conceptual data model

Footnote 27
The Conceptual Model (2 of 2)

Footnote Figure 2.8 Conceptual Model for Tiny College 28

The Internal Model (1 of 2)
The internal model requires a designer to match the conceptual
The internal model is the representation of model’s characteristics and constraints to those of the selected
the database as “seen” by the DBMS implementation model

An internal schema depicts a specific representation of an internal model, using the database
constructs supported by the chosen database

Because the internal model depends on specific database software, it is said to be software
dependent

When you change the internal model without affecting the conceptual model, you have logical
independence

However, the internal model is still hardware independent

Footnote 29
The Internal Model (2 of 2)

Footnote Figure 2.9 Internal Model for Tiny College 30

The Physical Model

The physical model operates at the

lowest level of abstraction, describing
the way data is saved on storage media

The physical model requires the

definition of both the physical storage
devices and the (physical) access
• This means the physical model is both
methods required to reach the data software and hardware dependent
within those storage devices

When you can change the physical

model without affecting the internal
model, you have physical
independence

Footnote 31
 Questions???

Footnote 32