Relational Model & Normalization

1.1
Relational Model
• The relational model is a conceptual framework used in database management
systems (DBMS) to organize and manage data.
• It was first proposed by Edgar F. Codd in 1970 to improve the working of DBMS
to handle large volume of data.
• He applied the rules of mathematics to solve the problem of earlier database
model like data integrity and data redundancy.
• The relational model represents data as collections of tables, also known as
relations.
• Each table consists of rows and columns, where each column represents a
specific attribute or characteristic of the data, and each row represents a unique
record or instance of that data.

1.2
Relational Database Terminologies
• Some important terminologies used in relational model are as follows:
• Relation/tables
• Tuples/ Rows/Records: Data for one item or transaction
• Attributes/ Fields: named column of a relation, characteristics or properties
• Domain: collection of all possible values of attributes
• Cardinality : total number of tuples is called cardinality of relation
• Degree: total number of attributes is called degree of relation

1.3
1.4
Advantage of Relational Model
1.Data Integrity: The model enforces data integrity by defining constraints and rules
that ensure the accuracy and consistency of data within and between tables. These
constraints can include uniqueness, referential integrity, and data type constraints.
2.Flexibility: The relational model allows for flexible querying and manipulation of
data through a structured query language (SQL). SQL provides a standard syntax for
interacting with relational databases, enabling users to retrieve, insert, update, and
delete data with ease.
3.Scalability: The model is scalable, meaning it can handle large amounts of data and
complex relationships between tables. It allows for efficient storage and retrieval of
data, even as the database grows in size.
4.Data Independence: The relational model provides a level of abstraction between
the physical representation of data and its logical structure. This allows for changes
in the underlying storage or indexing mechanisms without affecting the way data is
accessed or manipulated.
1.5
Keys
• In database management systems (DBMS), keys are attributes or combinations
of attributes that are used to uniquely identify rows within a table.
• Keys play a crucial role in establishing relationships between tables and
ensuring data integrity.
• In real world applications, number of tables required for storing the data is
huge, and the different tables are related to each other as well.
• Also, tables store a lot of data in them. Tables generally extends to thousands
of records stored in them, unsorted and unorganized.
• Now to fetch any particular record from such dataset, you will have to apply
some conditions Keys are defined to easily identify any row of data in a table.

1.6
Types of keys

1.7
• Let's try to understand about all the keys using a simple example.
• Let’s take a simple Student Table, with fields student_id, name, phone and age.

1.8
Super Key
• Super Key is defined as a set of attributes within a table that can uniquely
identify each record within a table.
• Super Key is a superset of Candidate key.
• In the Student table above super key would include student_id, (student_id,
name), phone etc.
• student_id: is unique for every row of data, hence it can be used to identity
each row uniquely.
• (student_id, name): now name of two students can be same, but
their student_id can't be same hence this combination can also be a key.
• Phone: phone number for every student will be unique, hence
again, phone can also be a key.

1.9
Candidate Key
• Candidate keys are defined as the minimal set of fields which can uniquely
identify each record in a table.
• There can be more than one candidate keys for a table.
• A candidate key can be a combination of more than one columns(attributes).
• In our example, student_id and phone both are candidate keys for
table Student.

1.10
Primary Key
• Primary key is a candidate key that is most appropriate to become the primary
key for any table. It is a key that can uniquely identify each record in a table.
• Properties of Primary Key:
• A primary key must be Unique
• Each table can have one and only one primary key
• A primary key cannot accept Null value
• Primary key support auto increments
• For the table Student we can make the
student_id column as the primary key.

1.11
Composite Key
• Key that consists of two or more attributes that uniquely identify any record in
a table is called Composite key.
• In the below picture we have a Score table which stores the marks scored by a
student in a particular subject.
• In this table student_id and subject_id together will form the primary key,
hence it is a composite key.

1.12
Secondary or Alternative key
• The candidate key which are not selected as primary key are known as
secondary keys or alternative keys.
Foreign key
• A key that take reference between from primary key that exist in same or another
table.
• A foreign key establishes a relationship between two tables by referencing the
primary key of another table.
• It represents the relationship between the rows in the referencing table (child
table) and the referenced table (parent table).
• The foreign key column in the child table contains values that exist as primary key
values in the parent table or are NULL.
• It ensures referential integrity by enforcing constraints such as cascading updates
or deletes.
1.13
Employee [Referencing Table]

Department [Referenced Table]

1.14
Referential Integrity
• Referential integrity is the state of a database in which all values of all foreign
keys are valid.
• A referential integrity constraint is also known as foreign key constraint
• The table from which the values are derived is known as Referenced Table and
the Table in which values are inserted accordingly is known as Referencing Table,
In other words, we can say that the table containing the foreign key is called the
Referencing /child table, and the table containing the Primary key/candidate
key is called the referenced or parent table.
• There are three referential integrity constraint/rules;
Insert Constraints
Delete Constraints
Update Constraints

1.15
• When an SQL operation (insert, delete, update) attempts to change data in such a way that
referential integrity will be compromised, a foreign key (or referential) constraint could be
violated.
• The database manager handles these types of situations by enforcing a set of rules that are
associated with each referential constraint.
• Referential integrity constraints are rules applied to foreign keys in a database to ensure the
consistency and integrity of relationships between tables.
• Referential constraint in Referenced Table:
1. Insert Constraint: Value can be inserted in Referenced Table it will not violate integrity
2. Delete Constraint: Value can/cannot be deleted in Referenced Table if the value is lying in referencing Table
we cannot delete because it cause violation if value is not present in referencing table we can delete.
3. Update Constraint: Value can/cannot be updated from referenced Table if the value is lying in referencing
Table we cannot update because it cause violation if value is not present in referencing table we can update.
• Referential constraint in Referencing Table:
1. Insert Constraint: Value can or cannot be inserted in Referencing Table if the value is not lying in referenced
Table we cannot insert because it cause violation if value is present in referenced table we can insert.
2. Insert Constraint: Value can be deleted in Referencing Table it will not create any violation.
3. Delete Constraint: Value cannot be updated from referencing Table if its value is lying in Referenced Table
and other than referencing values it can updated.

1.16
Solutions
• We can delete, update the value from the referenced table if the value is lying
in the referencing table without violating the constraint and insert, update the
value from the referencing table if the value is lying in the referenced table
without violating the constraint
1. CASCADE:
• When a row in the parent table (referenced table) is updated or deleted, the
corresponding rows in the child table (referencing table) are also updated or
deleted automatically.
• This constraint propagates the changes made to the primary key values in
the parent table to the related foreign key values in the child table.
• For example: if a DepNo is updated in the “Department" table, all related
employe in the “Employe" table with the same DepNo would be
automatically updated.

1.17
2. SET NULL:
• When a row in the parent table is updated or deleted, the foreign key values in
the child table are set to NULL.
• This constraint allows for null values in the foreign key column of the child
table, indicating that there is no valid relationship with the parent table.
• For example, if a DepNo is deleted from the “Department" table, the DepNo in
the related rows of the “Employee" table would be set to NULL.
3. NO ACTION/RESTRICT:
• This constraint prevents any update or deletion in the parent table if there
are related rows in the child table.
• It restricts the modification or deletion of rows in the parent table that
would violate the referential integrity constraint.
• For example: if an attempt is made to delete a DepNo from the
“Department" table who has related employes in the “Employee" table, the
deletion operation would be restricted.
1.18
 Referenced Table Referencing Table

INSERT: No violation INSERT: May cause Violation

DELETE: May cause Violation DELETE: No violation
Solutions:
• On Delete Cascade
• On Delete Null
• On Delete No action
UPDATE: May cause Violation UPDATE: May cause Violation
Solutions:
• On Update Cascade
• On Update No action

1.19
Convert ERD into Relational Model
• ER Model, when conceptualized into diagrams, gives a good overview of entity-
relationship, which is easier to understand. ER diagrams can be mapped to
relational schema, that is, it is possible to create relational schema using ER
diagram.

Rule 1: Strong Entities and Simple Attributes:

• An entity type within ER diagram is turned into a table. You may preferably
keep the same name for the entity or give it a sensible name.
• Each attribute turns into a column (attribute) in the table. The key attribute of
the entity is the primary key of the table which is usually underlined.

1.20
Rule 1: Strong Entities and Simple Attributes:
PK
Person-id Name Last Email Phon
name e
P1 Ali Ahmad [email protected] 123

P2 Noor Fatima [email protected] 456

 Persons Table. Person-id, name, last P3 Hasnain ail [email protected] 786

om
name, email, phone are Table
Columns (Attributes).

1.21
Rule 2: Strong Entities and Composite Attributes:
• Only simple attribute of composite attribute turns into a column (attribute)
in the table, composite attribute cannot part itself in relational model.
PK
Employe- Name street city country
id
E1 Ali Ahmad Gujranwala Pakistan

E2 Noor Fatima Lahore Pakistan

E3 Hasnain ail Karachi Pakistan

1.22
Rule 3: Strong Entities and Multi-valued Attributes:
• For multi-valued attribute, take the attribute and turn it into a new entity or table of its own
In simple words. 1. Create a table for the simple attribute with PK. 2. Add the primary (id)
column of the parent entity as a foreign key and multi-valued attribute within the new table
Person-id

PK FK
Person-id Name Person-id Phone

P1 Ali P1 123

P2 Noor P2 456

P3 Hasnain P1 786

1.23
Translating relationship set into table
• A relationship within ER diagram is also turned into a table, contain descriptive
attributes and participants primary keys as attribute of relationship table.
• Primary key in relationship table always a non-descriptive attribute.
Date

FK FK
Works
Employee-id Department-id Date
E1 D2 15-06-2023
E2 D1 10-06-2021
E1 D3 09-06-2020

1.24
Relationship set with cardinality constraints
• Relationships can be handled using a few different approaches, depending on the
cardinality ratio of the relationship.
• Most generally, we can create a table to represent the relationship. This kind of
table is known as a cross-reference table, and acts as an intermediary in a three-
way join with the two (or more) tables whose entities participate in the
relationship.
• we will see, some cardinality ratios permit simpler solutions;
• One-to-one
• One-to-many
• Many-to-many

1.25
One-to-one
• In most cases, it will be preferable to borrow the primary key from one table as
a foreign key in the other table.
• Using this approach, you could borrow from either side; For example, a one-to-
one relationship, manages, between employee and factory.

1.26
• Primary key: Either E-ID or F-ID
• Reducible: Yes
PK FK FK,PK PK
E-ID NAME SALARY E-ID F-ID F-ID NAME CITY

E1 Ali 50,000 E1 F2 F1 ABC Lahore

E2 Noor 40,000 E2 F1 F2 XYZ Sialkot

PK FK
F-ID NAME CITY E-ID

Total No. of Tables: 3

F1 ABC Lahore E2
Minimum No. of Table: 2
F2 XYZ Sialkot E1
1.27
One-to-Many
• In one-to-many relationship rows on the “many” side of the relationship can be
associated with at most one row from the “one” side, we can choose to capture
the relationship by storing the primary key of the “one” side table in the
“many” side table.
• Table that have same primary keys merge those tables.
• For example, a one-to-many relationship, works between employee and
projects.

1.28
• Primary key: P-ID
• Reducible: Yes
PK FK PK, FK PK
E-ID NAME SALARY E-ID P-ID Allowance P-ID NAME DURATION

E1 Ali 50,000 E1 p1 10,000 P1 JKL 5 MONTHS

E2 Noor 40,000 E1 p2 20,000 P2 PQR 6 MONTHS

PK FK
P-ID NAME DURATION E-ID Allowance

Total No. of Tables: 3 P1 JKL 5 MONTHS E1 10,000

Minimum No. of Table: 2
P2 PQR 6 MONTHS E1 20,000

1.29
Many-to-Many
• Many-to-many relationships are the most general type of relationship; The
challenge for many-to-many relationships is how to represent a connection
from a record in one table to multiple records in the other table.
• The traditional solution is to create a cross-reference table.

1.30
• Primary key: S-ID, C-ID (composite)
• Reducible: NO
PK
PK FK FK PK
S-ID NAME Address E-ID P-ID Allowance C-ID NAME Credit hour

S1 Ali Gujranwala S1 C2 10,000 C1 OOP 4

S2 Noor Gujranwala S2 C2 20,000 C2 DLD 3

S1 C1

Total No. of Tables: 3

1.31
1.32
CODD’s 12 RULES OF RELATIONAL DATABASE
• A relational database management system (RDBMS) is a database management
system (DBMS) that is based on the relational model as introduced by E. F.
Codd.
• A short definition of an RDBMS a DBMS in which data is stored in the form of
tables and the relationship among the data is also stored in the form of tables.
• E.F. Codd, the famous mathematician has introduced 12 rules (0-12)for the
relational model for databases commonly known as Codd's rules.
• The rules mainly define what is required for a DBMS for it to be
considered relational, i.e., an RDBMS.

1.33
1.34
• Rule 0: The foundation Rule
For any system that is advertised as, or claimed to be, a relational database
management system , that system must be able to manage database entirely
through its relational capabilities
• Rule 1: The Information Rule
All information in the database is to be represented in one and only one way.
All information in an RDB is represented as values in the tables.
This is achieved by values in column and rows of tables.
All information including table names, column names and column data types
should be available in same table within the database. The basic requirement
of the relational model.

1.35
• Rule 2: Guaranteed Access Rule
Each unique piece of data should be accessible by: table name + primary
key(row) + attribute(column).
All data are uniquely identified and accessible via this identity.
Most RDBMS do not make the definition of the primary key mandatory and are
deficient to that extent .
• Rule 3: Systematic Treatment of Null Values
"Null values (distinct from the empty character string or a string of blank
characters and distinct from zero or any other number) are supported in fully
relational DBMS for representing missing information and inapplicable
information in a systematic way, independent of data type.“
This is distinct to zero or empty strings

1.36
 • NULL may mean: Missing data, Not applicable
• Should be handled consistently - Not Zero or Blank
• Primary keys — Not NULL
• Separate handling of missing and/or non applicable data.

• Rule 4: Dynamic Online Catalog Based on Relational Model

The data base description is represented at the logical level in the same way as-
ordinary data, so that authorized users can apply the same relational language
to its interrogation as they apply to the regular data.
Catalog (data dictionary) can be queried by authorized users as part of the
database.

1.37
• Rule 5: Comprehensive Data Sublanguage
A relational system may support several languages and various modes of
terminal use . However, there must be at least one language whose statements
are expressible, per some well-defined syntax, as character strings and that is
comprehensive in supporting all the following items :
• View Definition
• Data Manipulation (alter, delete, insert)
• Integrity Constraints (primary key, foreign key, null values)
• Authorization(GRANT,REVOKE)
• Transaction boundaries (commit, rollback etc.)
• Every RDBMS should provide a language to allow the user to query the
contents of the RDBMS and also manipulate the contents of the RDBMS.

1.38
• Rule 6: View Updating Rule
View = ”Virtual table”, temporarily derived from base tables.
Example: If a view is formed as join of 3 tables, changes to view should be
reflected in base tables.
All theoretically possible view updates should be possible. It allow the update
of simple theoretically updatable views, but disallow attempts to update
complex views.
• Rule 7: Possible For High-level Insert, Update And Delete
The capability of handling a base relation or a derived relation as a single
operand applies not only to the retrieval of data but also to the insertion,
update and deletion of data.
This rule states that insert, update, and delete operations should be supported
for any retrievable set rather than just for a single row in a single table.It also
perform the operation on multiple row simultaneously .
1.39
• Rule 8: Physical Data Independence
Application programs and terminal activities remain logically unimpaired
whenever any changes are made in either storage representations or access
methods.
Changes to the physical level (how the data is stored, whether in arrays or
linked lists etc.) must not require a change to an application based on the
structure.
• Rule 9: Logical Data Independence
Application programs and terminal activities remain logically unimpaired when
information-preserving changes of any kind that theoretically permit un-
impairment are made to the base tables.
Changes to the logical level (tables, columns, rows, and so on) must not require
a change to an application based on the structure.

1.40
• Rule 10: Integrity Independence
Integrity constraints specific to a particular relational data base must be
definable in the relational data sub-language and storable in the catalog, not in
the application programs.
Alterations to integrity constraints should not affect application programs. This
simplifies the programs.
• Rule 11: Distribution Independence
The data manipulation sub language of an RDBMS must enable application
programs and queries to remain logically unchanged whether & whenever data
is physically centralised or distributed.
Distribution independence implies that user should not have to be aware of
whether a database is distributed at different sites or not.

1.41
• Rule 12: The Non-subversion Rule
If the relational system provides a low-level (record-at-a-time) language, that
low level cannot be used to subvert or bypass the integrity Rules and
constraints expressed in the higher level relational language (multiple-records-
at-a-time).

1.42