INFORMATION SYSTEMS 3A

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
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 4
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 5
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 6
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 can be a communication It allows the designer to It allows the designer to appropriate relationship
It helps to standardize the
tool between users and understand the nature, role, understand business participation rules and
company’s view of data
designers and scope of the data processes constraints and to create an
accurate data model

Footnote 7
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 8
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 9
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 10
The Relational Model (2 of 4)

Footnote Figure 2.1 Linking Relational Tables 11

The Relational Model (3 of 4)

Footnote Figure 2.2 A Relational Diagram 12

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 13
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 14
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 15
The Entity Relationship Model (3 of 3)

Footnote Figure 2.3 The ER Model Notations 16

Data Models: A Summary

Footnote Figure 2.5 The Evolution of Data Models 17

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

1.External
2. Conceptual
3. 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 18
Degrees of Data Abstraction (2 of 2)

Footnote Figure 2.6 Data Abstraction Levels 19

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 20
The External Model (2 of 3)

Footnote Figure 2.7 External Models for Tiny College 21

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 22
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 23
The Conceptual Model (2 of 2)

Footnote Figure 2.8 Conceptual Model for Tiny College 24

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 25
The Internal Model (2 of 2)

Footnote Figure 2.9 Internal Model for Tiny College 26

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 27
 Database Systems:
Design,
Implementation, and
Management, 14e
Module 3: The Relational
Database Model

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

The relational data model allows

the designer to focus on the The relational model enables you
logical representation of the data to view data logically rather than
and its relationships, rather than physically
on the physical storage details

Logical simplicity tends to yield

This section explores the details
simple and effective database
of table structure and contents
design methodologies

Footnote 29
Tables and Their Characteristics (1 of 3)

A table is perceived as a two-dimensional structure composed of rows and columns

A table is also called a relation

You can think of a table as a persistent A relation whose contents can be permanently saved for future use
representation of a logical relation

The domain is the set of allowable values for an attribute

The primary key (PK) is an attribute or combination of attributes that uniquely identifies any given row

The characteristics of a relational table are summarized in Table 3.1 on the following slide

Footnote 30
 Tables and Their Characteristics (2 of 3)

Table 3.1 Characteristics of a Relational Table

1 A table is perceived as a two-dimensional structure composed of rows and columns

2 Each table row (tuple) represents a single entity occurrence within the entity set

3 Each table column represents an attribute, and each column has a distinct name

4 Each intersection of a row and column represents a single data value

5 All values in a column must conform to the same data format

6 Each column has a specific range of values known as the attribute domain

7 The order of the rows and columns is immaterial to the DBMS

8 Each table must have an attribute or combination of attributes that uniquely identifies each row

Footnote 31
Tables and Their Characteristics (3 of 3)

Footnote 32
Keys

A key consists of one or more attributes that determine other

attributes

Keys are important because they They are also used to establish
are used to ensure that each row relationships among tables and to ensure
the integrity of the data
in a table is uniquely identifiable

Footnote 33
Dependencies

The role of a key is based on the

concept of determination, which
is the state in which knowing the Functional dependence means
The attribute whose value
value of one attribute helps to that the value of one or more
determines another is called the
determine the value of another attributes determines the value of
determinant or the key
•Example: revenue – cost = profit
one or more other attributes

Full functional dependence is

used to refer to functional
The attribute whose value is
dependencies in which the entire
determined by the other is called
collection of attributes in the
the dependent
determinant is necessary for the
relationship

Footnote 34
Types of Keys (1 of 3)

A composite key is a key that is composed of more than one attribute

An attribute that is part of a key is called a key attribute

A superkey is a key that can uniquely identify any row in the table

A candidate key is a minimal superkey; that is, a key that does not contain a subset of attributes that is itself a
superkey

Entity integrity is the condition in which each row in the table has its own known, unique identity

A null is the absence of any data value, and it is never allowed in any part of a primary key

Footnote 35
Types of Keys (2 of 3)
An unknown attribute value
A null could represent any of the A known, but missing, attribute value
following: A “not applicable” condition

A foreign key (FK) is a primary key of one table that has been placed in another
table

Referential integrity is a condition by which a dependent table’s foreign key entry must
have either a null entry or a matching entry in the primary key of the related table

A secondary key is a key that is used strictly for data retrieval purposes and does
not require a functional dependency

Footnote 36
Types of Keys (3 of 3)

Footnote Figure 3.2 An Example of a Simple Relational Database 37

Integrity Rules (1 of 2)
Table 3.4 Integrity Rules
Entity Integrity Description
Requirement All primary key entries are unique, and no part of a primary key may be null.
Purpose Each row will have a known, unique identity, and foreign key values can properly reference primary key
values.
Example No invoice can have a duplicate number, nor can it be null; in short, all invoices are uniquely identified by
their invoice number.
Referential Description
Integrity
Requirement A foreign key may have either a null entry, as long as it’s not part of its table’s primary key, or an entry that
matches the primary key value in a table to which it is related (every non-null foreign key value must
reference an existing primary key value).
Purpose The purpose is to ensure that every reference by a foreign key is a valid reference to the related primary key.
It is possible for an attribute not to have a corresponding value, but it will be impossible to have an invalid
entry; the enforcement of the referential integrity rule makes it impossible to delete a row in one table
whose primary key has mandatory matching foreign key values in another table.
Example A customer might not yet have an assigned sales representative (number), but it will be impossible to have
an invalid sales representative (number).
Footnote 38
Integrity Rules (2 of 2)

Footnote Figure 3.3 An Illustration of Integrity Rules 39

 Questions???

Footnote 40