The Relational

Database Model
and Normalization
The Relational Database
Management System (RDBMS)
is a database management
system that is based on the
relational model as introduced by…
 EDGAR
“ ” TED

FRANK
CO 1923 - 2003

DD
Dr. Edgar Frank Codd was born
on the 19th of August in the year 1923 in
Portland, Dorset, England.
development of the relational model is
acknowledged; this model paved the way
His

for the development of the relational

database, a common format for storing
and retrieving computer data.
The Relational Database
Management System (RDBMS)
Every model should be according to
the Codd rules or it satisfies Codd Rules.
But in practice, no DBMS satisfies all
these rules. Normalization is a step-wise
formal process that allows us to
decompose database tables in such a way
that both data redundancy and update
anomalies are minimized. Relational
model and normalization are two
important aspects of the database
Relational Model (RM)
Represents the
database as a
collection of
relations. A The table names and
relation is column names are
nothing but a helpful to interpret the
table of values. meaning of values in
Every row in the each row. The data are
table represents represented as a set of
a collection of relations. In the
related data relational model, data
values. These are stored as tables.
rows in the table However, the physical
Relational Model Concepts in DBMS
Attribute - Each column in a Table. Attributes are the
properties which define a relation. e.g., Student_Rollno,
NAME, etc.

Tables – In the Relational model the, relations are saved in

the table format. It is stored along with its entities. A table
has two properties rows and columns. Rows represent
records and columns represent attributes.

Tuple – It is nothing but a single row of a table, which

contains a single record.

Relation Schema - A relation schema represents the name

Relational Model Concepts in DBMS
Cardinality - Total number of rows present in the Table.
Column - The column represents the set of values for a
specific attribute.
Relation instance – Relation instance is a finite set of tuples
in the RDBMS system. Relation instances never have
duplicate tuples.
Relation key – Every row has one, two, or multiple
attributes, which is called relation key.
Attribute domain – Every attribute has some pre-defined
Parts of Relation
Table is also called a
Relation.
Custome CustomerN Status
rID101 ame
Google Active
Primary Columns or
Domain
Total # of column is
Key Ex:
DegreeRows orInactive
102 Attributes
Apple
NOT NULL
Total # of rows is
Tuple
103 AmazonCardinality Active
Parts of Relation
Domain
Primary Ex: NOT NULL Table is also called a
Key Relation.
Custome CustomerN Status
rID101 ame
Google Active
102 Apple Inactive Rows or
Total # of rows is
103 Active Tuple
Amazon Cardinality

Columns or
Total # of column is
Attributes
Degree
Relational Integrity Constraints
Relational Integrity Constraints - in DBMS are
referred to conditions which must be present for a
valid relation. These Relational constraints in DBMS
are derived from the rules in the mini-world that the
database represents.
 There are many types of Integrity Constraints in DBMS.
Constraints on the Relational database management system
are mostly divided into three main categories:
ial
ys
nts
rity
ein are
MS a
yeptof of
reign
the
ant
ples
on that
be
to in
ips.
rity
tppens
fers to
e
of a
elation.
mple…
e…
 There are many types of Integrity Constraints in DBMS.
Constraints on the Relational database management system
are mostly divided into three main categories:
Domain Key Referential
Constraints Constraints Integrity
Domain constraints can be
violated if an attribute value
An attribute that can
uniquely identify a tuple in a
Constraints
Referential Integrity
constraints in DBMS are
does not appear in the relation is called the key of based on the concept of
corresponding domain or it the table. The value of the Foreign Keys. A foreign
is not of the appropriate attribute for different tuples key is an important
data type. in the relation has to be attribute of a relation that
unique. should be referred to in
Domain constraints specify other relationships.
that within each tuple, the Referential integrity
value of each attribute must constraint state happens
be unique. This is specified where a relation refers to
as data types which include a key attribute of a
standard data types different or same relation.
See example… See example…
integers, real numbers,
 are mostly divided into three main categories:
E.F. Codd’s 12 Rules for Relational Database

There are twelve rules formulated by E.F.

Codd for RDBMS in 1970. If an RDBMS
satisfies all these twelve rules, then full
benefits of the relational database results
can be obtained. Here are Codd’s 12 rules for
Relational Database:
E.F. Codd’s 12 Rules for Relational Database

• Information • High-level update,

Representation insert, delete
• Guaranteed Access • Physical data
• Systematic Treatment independence
of Null Values • Logical data
• Database Description independence
rule • The distribution rule
• Comprehensive data • Non-subversion
 Types of Keys
Key: A key is a data item which exclusively identifies a record.
Different types of keys are listed below:

Super key – A super key for an entity is a set of one or more attributes
whose combined value uniquely identifies the entity in the entity set.
For example, for an entity set of Employees, the set of attributes can
be considered to be a super key, if we assume that there are no two
employees with the same attributes.

Primary key – The primary key uniquely identifies each record in a

table and must never be the same for two records.
 Types of Keys
Composite key - When a record cannot be uniquely identified y a
single field, in such cases a composite key is used. A composite
key is a group of fields that are combined, to uniquely identify a
record.

Alternate key/Secondary Key - A secondary key is an attribute or

combination of attributes that may not be a candidate key but
classifies the entity set on a particular characteristic.

Foreign key- In a relation, the column whose data values

Example:
ID Name Last Name Salary Phone no. Email
Super Key:
401 Klent Fadriquel 20 000 091235 KF@05
- It is like a 402 Raiza Rayo 40 000 091355 RR@15
superset. 403 James Mijares 58 000 098573 JM@57
- Uniquely identify 404 Honey Mangao 38 000 091247 HM@85
a tuple. 405 Alvin Galos 15 000 095628 AG@87
406 Mark Gonzales 24 000 095712 MG@91
- Accepts Null
407 Joshua Marceno 17 500 095752 JM@15
Values. 408 Hiraya Patnon 38 000 099814 HP@66
- May contain 409 Carl Sotomil 26 500 091824 CS@11
extraneous 410 John Joseph Gatarin 60 000 095395 JJ@76

attributes.

Super keys:
[ID] [ID,
Name]
Example:
ID Name Last Name Salary Phone no. Email
Candidate Key:
401 Klent Fadriquel 20 000 091235 KF@05
- Minimal super 402 Raiza Rayo 40 000 091355 RR@15
keys are 403 James Mijares 58 000 098573 JM@57
candidate keys. 404 Honey Mangao 38 000 091247 HM@85
405 Alvin Galos 15 000 095628 AG@87
406 Mark Gonzales 24 000 095712 MG@91
[ID] [Name, 407 Joshua Marceno 17 500 095752 JM@15
Phone] 408 Hiraya Patnon 38 000 099814 HP@66
[Last Name] 409 Carl Sotomil 26 500 091824 CS@11
[Email] 410 John Joseph Gatarin 60 000 095395 JJ@76
Example:
ID Name Last Name Salary Phone no. Email
Primary Key:
401 Klent Fadriquel 20 000 091235 KF@05
- To denote a 402 Raiza Rayo 40 000 091355 RR@15
candidate key. 403 James Mijares 58 000 098573 JM@57
- Should be unique 404 Honey Mangao 38 000 091247 HM@85
and does not 405 Alvin Galos 15 000 095628 AG@87
406 Mark Gonzales 24 000 095712 MG@91
have null values. 407 Joshua Marceno 17 500 095752 JM@15
408 Hiraya Patnon 38 000 099814 HP@66
From the chosen 409 Carl Sotomil 26 500 091824 CS@11
Candidate keys, [ID] 410 John Joseph Gatarin 60 000 095395 JJ@76

is a unique attribute
that does not have
duplication in the
tuple nor null
values.
Example:
ID Name Last Name Salary Phone no. Email
Alternate Key:
401 Klent Fadriquel 20 000 091235 KF@05
- The candidate 402 Raiza Rayo 40 000 091355 RR@15
key other than 403 James Mijares 58 000 098573 JM@57
the primary key. 404 Honey Mangao 38 000 091247 HM@85
- All the keys which 405 Alvin Galos 15 000 095628 AG@87
406 Mark Gonzales 24 000 095712 MG@91
are not primary 407 Joshua Marceno 17 500 095752 JM@15
keys. 408 Hiraya Patnon 38 000 099814 HP@66
409 Carl Sotomil 26 500 091824 CS@11
[Name, Phone] 410 John Joseph Gatarin 60 000 095395 JJ@76

[Last Name]
[Email]
 Example:
ID Name Last Name Salary Phone no. Email
Unique Key:
401 Klent Fadriquel 20 000 091235 KF@05
- A key that have 402 Raiza Rayo 40 000 091355 RR@15
unique values 403 James Mijares 58 000 098573 JM@57

able: and support null

404 Honey Mangao 38 000 091247 HM@85
values. 405 Alvin Galos 15 000 095628 AG@87
406 Mark Gonzales 24 000 095712 MG@91
407 Joshua Marceno 17 500 095752 JM@15
[Name, Phone] 408 Hiraya Patnon 38 000 099814 HP@66
Composite Key:
409 Carl Sotomil 26 500 091824 CS@11
- A key that is
410 John Joseph Gatarin 60 000 095395 JJ@76
comprised more
than one
attribute.

[Name, Phone]
[Name, ID, Email]
Example:
Foreign Key: REFERENTIAL INTEGRITY - where the
- A key that deals two insertion in one table is depending on the
values to be validated in the other table.
tables and offers
Referential Integrity. Department Table:
Employee Table:
ID Name Last Name Salary Phone no. Email Dept_Code Dept_Name
401 Klent Fadriquel 20 000 091235 KF@05 401 MECH
402 Raiza Rayo 40 000 091355 RR@15 402 TOS
403 James Mijares 58 000 098573 JM@57 403 HYDRAU
404 Honey Mangao 38 000 091247 HM@85 404 CEM
405 Alvin Galos 15 000 095628 AG@87
405 GEOTECH
406 Mark Gonzales 24 000 095712 MG@91
406 ARKI
407 Joshua Marceno 17 500 095752 JM@15
407 CHEM
408 Hiraya Patnon 38 000 099814 HP@66
408 ECE
409 Carl Sotomil 26 500 091824 CS@11
410 John Joseph Gatarin 60 000 095395 JJ@76 409 BIO
410 STEEL
Integrity Constraints
An integrity constraint is a condition that can be
applied to a database schema to restrict the data
according to the need. If the condition is satisfied, then
only it can be stored in the database. These integrity
constraints can be applied to the database when the
DBA of end users defines the database of the schema.
The DBMS checks these constraints when a database
application is run. The purpose of these constraints is to
ensure that there should not be any loss in data
consistency due to changes made to the database by
the authorized users.
Domain Constraints
A domain is a set of atomic values. By atomic we
mean that each value in the domain is invisible as far
as the relational model is concerned. Domain
constraints specify that the values of each attribute (A)
must be an atomic value from the domain (A). Domain
constraints are the most elementary form of integrity
constraint. They are tested easily by the system
whenever a new data item is entered into the database.
Normalization
Normalization is a process of organizing data in a
database to reduce redundancy and improve data consistency.
Primary keys are really important in organizing information in a
database. They help to make sure that every row in a table has
a unique identification so that nothing gets mixed up or lost.
It is a technique to organize the contents of the table for
transactional databases and data warehouses(removing
redundancy). This includes creating tables and establishing
relationships between those tables according to rules designed
both to protect data and make the database more flexible by
eliminating two factors:
Goals for Normalization
When we normalize the database,
we have four goals:
Building a database in which
you can access and
manipulate the data quickly 04
and efficiently without
compromising the integrity of
the data in storage
Organizing the data such
that, when you modify it,
you make changes in one 02 03 Minimizing the amount of
duplicate data, called
place.
redundancy, stored in a
database.

Arrangement of data into

01 logical groupings in such a
way each group describes a
small part of the whole.
 Advantages of Normalization

It avoids It permits
It makes the It It makes
biasing the
database reduces the
the operation
more the need database
database s needed
informative to free from
design in for data
for users restructu certain
favor of access to
including re the addition,
certain be
different database updation
queries simpler
users and as new and
at the than they
making kinds of deletion
interfere would
different data are anomalies.
Types of Normal Form
Normally, there are five types
of normal form.
• First Normal Form (1NF)
• Second Normal Form (2NF)
• Third Normal Form (3NF)
• Boyes Cord Normal Form
(BCNF)
• Fourth Normal Form (4NF)
Types of Normal Form
First Normal
1NF requires that each column in a table contains atomic
Form
values(1NF)
and that each row is uniquely identified. This means
that a table cannot have repeating groups or arrays as
columns, and each row must have a unique primary key.

Example:
A table is in 1NF if each column contains atomic values
and each row is uniquely identified. For example, a table that
lists customers and their phone numbers.
Types of Normal Form
First Normal
Example:
FormThis
(1NF)violates 1NF because the Phone Numbers column
contains repeating groups.
To normalize this table to 1NF, we can split the Phone
Numbers column into separate rows and add a separate
primary key column.
Types of Normal Form
Second Normal Form
2NF builds on 1NF by requiring that each non-primary key
(2NF)
column in a table is fully functionally dependent on the
primary key. This means that a table should not have partial
dependencies, where a non-primary key column depends on
only part of the primary key.

Example:
A table is in 2NF if each non-primary key column is fully
functionally dependent on the primary key. For example, a
table that lists orders and their line items:
Types of Normal Form
Second Normal Form
Example:
(2NF)
This violates 2NF because the Customer Name column
depends on only part of the primary key (Customer ID). To
normalize this table to 2NF, we can split it into two tables.
Types of Normal Form
Third Normal Form
3NF builds on 2NF by requiring that each non-primary key
(3NF)
column in a table is not transitively dependent on the primary
key. This means that a table should not have transitive
dependencies, where a non-primary key column depends on
another non-primary key column.

Example:
To explain 3NF further, let's consider an example of a table
that lists customer orders.
Types of Normal Form
Third Normal Form
In this example, the non-primary key column "Customer
(3NF)
City" is transitively dependent on the primary key. That is, it
depends on "Customer ID", which is not part of the primary key,
instead of depending directly on the primary key "Order ID". To
bring this table to 3NF, we can split it into two tables .

Now, the "Customer City" column is no longer

transitively dependent on the primary key and is instead
Types of Normal Form
Boyce-Codd Normal Form
BCNF is a stricter form of 3NF that applies to tables
(BCNF)
with more than one candidate key. BCNF requires that
each non-trivial dependency in a table is a
dependency on a candidate key. This means that a
table should not have non-trivial dependencies, where
a non-primary key column depends on another non-
primary key column. BCNF ensures that each table in a
database is a separate entity and eliminates
redundancies.
Types of Normal Form
Boyce-Codd Normal Form
Example:
(BCNF)
A table is in BCNF if each determinant is a candidate key.
In other words, every non-trivial functional dependency in the
table must be on a candidate key. For example, consider a
table that lists information about books and their authors.
Types of Normal Form
Boyce-Codd Normal Form
Example:
In this example, the functional dependency between
(BCNF)
"Author ID" and "Author Name" violates BCNF because it is not
on a candidate key. To bring this table to BCNF, we can split it
into two tables.

Now, the "Author Name" and "Author Nationality" columns

Types of Normal Form
Fourth Normal Form (4NF)
4NF builds on BCNF by requiring that a table should not
have multi-valued dependencies. A multi-valued dependency
occurs when a non-primary key column depends on a
combination of other non-primary key columns. For example, a
table that lists customer orders with a primary key of order ID
and non-primary key columns for customer ID and order items
violates 4NF because order items depend on both order ID and
customer ID.
Types of Normal Form
Fourth Normal Form (4NF)
For example, a table that lists orders and their products,
with columns for order ID, product ID, and product details,
violates 4NF because the product details depend on the
combination of order ID and product ID.

Example
Consider the following table of orders and products.
Types of Normal Form
Fourth Normal Form (4NF)
In this table, the product name and description depend on
both the order ID and product ID, creating a multi-valued
dependency. To bring the table into 4NF, we can split it into
three tables.
The Relational
Database Model
and Normalization
END.
 Domain
Constraints

The example shown demonstrates creating a domain

constraint such that CustomerName is not NULL.
 Key
Constraints
Example:
In the given table, CustomerID is a key attribute
of the Customer Table. It is most likely to have a single
key for one customer, CustomerID = 1 is only for the
CustomerName = “Google”.