Strathmore University | 2024

DATA
MODELS

Database Systems
 INTRODUCTION

Data models are a description of the structure/organization of a database.

Structure of the database involves :
Data contained in the database and their data types
Relationship between data items: eg students are supervised by lecturers,
lecturers teach courses
Constraints on the data eg student number has eight digits
The purpose of a data model is to represent data and to make the data
understandable

Page 1
 COMPONENTS

1. a structural part, consisting of a set of rules according to which databases

can be constructed;
2. a manipulative part, defining the types of operation that are allowed on the
data. This includes the operations that are used for updating or retrieving
data from the database and for changing the structure of the database;
3. possibly a set of integrity constraints, which ensures that the data is
accurate

Page 2
 DATA MODEL CATEGORIES

In database design phases, data are represented using a certain data

model.
Data models fall into three broad categories:
Object-based models
Record-based models
Physical data models.
The first two are used to describe data at the conceptual and external
levels, the latter is used to describe data at the internal level

Page 3
OBJECT BASED MODELS

Object-based data models use concepts such

as entities, attributes, and relationships.
An entity is a distinct object (a person, place,
thing, concept, event) in the organization
that is to be represented in the database.
An attribute is a property that describes
some aspect of the object that we wish to
record, and a relationship is an association
between entities

Page 4
 PHYSICAL BASED MODELS

Physical data models describe how data is stored in the computer,

representing information such as record structures, record
orderings, and access paths.
There are not as many physical data models as logical data models,
the most common ones being the unifying model and the frame
memory.

Page 5
RECORD BASED MODELS

There are three principal types of record-based

logical data model:
Relational data model
Network data model
Hierarchical data model.

Page 6
RELATIONAL DATA MODEL

Data and relationships are

represented as tables, each of
which has a number of columns
with a unique name.

Page 7
NETWORK DATA MODEL

Data is represented as collections of

records, and relationships are
represented by sets.
Compared with the relational model,
relationships are explicitly modeled
by the sets, which become pointers
in the implementation.
Entities are organized in a graph, in
which some entities can be accessed
through several paths

Page 8
HIERARCHICAL DATA MODEL

Data is represented as collections of

records and relationships are
represented by sets.
However, the hierarchical model
allows a node to have only one
parent.
A hierarchical model can be
represented as a tree graph, with
records appearing as nodes (also
called segments) and sets as edges

Page 9
 ANY
QUESTIONS
 MULTIUSER DBMS
ARCHITECTURES

The common architectures that are used to implement multi-user database

management systems include:
Teleprocessing
File-Server
Client-Server

Page 1
 TELEPROCESSING

One computer with a single CPU and

a number of terminals. Processing
performed within the same physical
computer.
User terminals are typically “dumb”,
incapable of functioning on their
own, and cabled to the central
computer.
.

Page 3
 FILE SERVER
ARCHITECTURE

In a file-server environment, the processing

is distributed about the network, typically a
local area network (LAN)
The file-server holds the files required by
the applications and the DBMS.
However, the applications and the DBMS
run on each workstation, requesting files
from the file-server when necessary.
The file-server acts simply as a shared hard
disk drive
.
Page 3
File Server Architecture

DISADVANTAGES

01 There is a large amount of network traffic.

02 A full copy of the DBMS is required on each workstation.

Concurrency, recovery, and integrity control are more complex

03
because there can be multiple DBMSs accessing the same files.

Page 4
 CLIENT SERVER
ARCHITECTURE
As the name suggests, there is a client process, which requires some resource, and a
server, which provides the resource.
The client (tier 1) is primarily responsible for the presentation of data to the user,
and the server (tier 2) is primarily responsible for supplying data services to the
client.

Page 3
 TWO TIER
ARCHITECTURE
Client (tier 1) manages user interface and runs applications.
Server (tier 2) holds database and DBMS.

Page 3
 THREE TIER
ARCHITECTURE
A new variation of the traditional two-tier client–server model appeared to
solve the problem of enterprise scalability.
This new architecture proposed three layers, each potentially running on a
different platform
The user interface layer, which runs on the end-user’s computer (the client).
The business logic and data processing layer. This middle tier runs on a
server and is often called the application server.
A DBMS, which stores the data required by the middle tier. This tier may run
on a separate server called the database server.

Page 3
 THREE TIER
ARCHITECTURE

Page 3
3 tier architecture

ADVANTAGES

01 The need for less expensive hardware because the client is ‘thin’.

The added modularity makes it easier to modify or replace one tier

02
without affecting the other tiers.

Load balancing is easier with the separation of the core business

03
logic from the database functions.

Page 4
3 tier architecture

ADVANTAGES

Application maintenance is centralized with the transfer of the

04 business logic for many end-users into a single application server.
This eliminates the concerns of software distribution that are
problematic in the traditional two-tier client–server model.

Page 4
 ANY
QUESTIONS
 RELATIONAL MODEL

The relational model is the most widely used data model

It describes a collection of inter-related relations (or tables)

RELATION
A relation is a table in a database with columns and rows
In the relational model, relations are used to hold information about the
objects to be represented in the database.
A relation is represented as a two-dimensional table in which the rows of
the table correspond to individual records and the table columns
correspond to attributes.
Page 11
 RELATIONAL MODEL

ATTRIBUTE

An attribute is a named column of a relation.

For example, the information on branch offices is represented by the
Branch relation, with columns for attributes branchNo (the branch
number), street, city, and postcode.

TUPLE
A tuple is a row of a relation.
For example, the rows or records entered in a table form the tuples.
These are the individual records.

Page 5
RELATIONAL
MODEL

Page 3
 RELATIONAL MODEL

DEGREE
The degree of a relation is the number of attributes it contains
A relation with only one attribute would have degree one and be called
a unary relation, two attributes is called binary, one with three
attributes is called ternary, and after that the term n-ary is usually used.

CARDINALITY

The cardinality of a relation is the number of tuples it contains.

This changes as tuples are added or deleted.

Page 5
RELATIONAL
MODEL

Page 3
 DOMAIN

Domain is the set of allowable values for one or more attributes

It allows the user to define in a central place the meaning and source of values that
attributes can hold.

Page 3
 ALTERNATE
TERMINOLOGY

Page 3
Relational Model

PROPERTIES OF A
RELATION

01 A relation and an attribute must have a distinct name;

Each cell of the relation contains exactly one atomic (single)

02
value;

The order of attributes does not matter;

03

Page 4
Relational Model

PROPERTIES OF A
RELATION

04 The values of an attribute are all from the same domain;

05 Each tuple is distinct; there are no duplicate tuples

The order of tuples has no significance, theoretically. (However, in

06
practice, the order may affect the efficiency of accessing tuples.)

Page 4
 RELATIONAL KEYS

There are no duplicate tuples within a relation, hence we need to

identify one or more attributes uniquely.
These attributes are referred to as relational keys
There are various types of keys

CANDIDATE

An attribute, or set of attributes, in a relation that can uniquely identify any

tuple without referring to any other data
Each relation may have one or more candidate keys
A special candidate key is the primary key

Page 3
 TYPES OF KEYS

PRMARY FOREIGN COMPOSITE

The candidate key that is An attribute, or set of A set of multiple attributes

selected to identify tuples attributes, within one relation that help us uniquely identify
uniquely within the relation. that matches a relational every tuple present in a table.
key of another relation The attributes present in a set
Candidate keys that are not may not be unique whenever
selected to be the primary key we consider them separately.
are called alternate keys Thus, when we take them all
together, it will ensure total
uniqueness.

Page 6
 INTEGRITY
CONSTRAINTS
Every attribute has an associated domain, and there are constraints
(called domain constraints) that form restrictions on the set of values
allowed for the attributes of relations.
Integrity rules, are constraints or restrictions that apply to all
instances of the database
NULL
A null can be taken to mean the logical value ‘unknown’.
It can mean that a value is not applicable to a particular tuple, or it could merely
mean that no value has yet been supplied.
For example, in the Viewing relation, the comment attribute may be undefined
until the potential renter has visited the property and returned his or her
comment to the agency.

Page 3
Fauget University | 2024

TYPES OF CONSTRAINTS

ENTITY INTEGRITY
This applies to the primary key attribute
In a relation, no attribute of a primary key can be null

REFERENTIAL INTEGRITY
If a foreign key exists in a relation, either the foreign key value must
match a candidate key value of some tuple in its home relation or the
origin key value must be wholly null.

Page 9
 CONSTRAINTS

GENERAL CONSTRAINTS
Additional rules specified by the users or database administrators of a
database that define or constrain some aspect of the enterprise.
Example:
A user may place an upper limit of 20 upon the number of staff that
may work at a branch office, as a general constraint that must be
enforced by the DBMS
In this case a branch should not be assigned more than 20 staff
members

Page 9
THANK
YOU