0% found this document useful (0 votes)
8 views28 pages

Relational Database

The document provides an overview of key concepts in database systems, including relational algebra, normalization, ER diagrams, SQL, data organization, hashing, indexing, and database security. It emphasizes the importance of understanding these topics for practical application, particularly in preparation for exams. The document also outlines the normalization process, detailing the different normal forms and their rules to ensure data integrity and reduce redundancy.

Uploaded by

nwanzepencil
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views28 pages

Relational Database

The document provides an overview of key concepts in database systems, including relational algebra, normalization, ER diagrams, SQL, data organization, hashing, indexing, and database security. It emphasizes the importance of understanding these topics for practical application, particularly in preparation for exams. The document also outlines the normalization process, detailing the different normal forms and their rules to ensure data integrity and reduce redundancy.

Uploaded by

nwanzepencil
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

SUMMARY OF

DATABASE SYSTEMS:

RELATIONAL ALGEBRA

ER DIAGRAMS

NORMALIZATION

STRUCTURED QUERY LANGUAGE

DATA ORGANIZATION/REPRESENTATION

HASHING AND INDEXING

DATABASE SECURITY

NOTE:

MAKE SURE YOU READ TO UNDERSTAND.


DON’T CRAM ANYTHING HERE. LEARN HOW
EVERTHING WORKS BECAUSE THE EXAM
WILL MOSTLY BE ABOUT CARRYING OUT
EXERCISES WITH EITHER SQL,
RELATIONAL ALGEBRA OR SOMETHING
ELSE. TRY TO PRACTICALIZE AS MUCH AS
POSSIBLE!!!!!

0
PREFACE

I’m going to start with an introduction to relational databases, then I will focus on these topics
(as they will most likely come out in the exam): Relational Algebra, Concept of
Normalization, ER Diagrams, SQL, Data Organization, Hashing & Indexing and also
Database Security.
In data science, we like to overcomplicate things by giving big names to simple things. So
revising for exams can be a bit frustrating because you have no idea what’s going on.
Just calm down and remember that everything here was created by a human being just like
you.
Instead of saying table, data scientists say relation. Instead of row, they say tuple. Instead
of column, they say attribute. Instead of overall structure, they say schema. Normalization…
😕 is actually difficult. But still, it’s not quantum mechanics or rocket science, databases are
not as complex as you think, but not as easy as GST101 either.
Relax, try your best and God will give you success in the name of Jesus.

1
DATABASE TERMINOLOGY
Introduction
At the most basic level, computers store data as 0s and 1s. But once you zoom out to a
higher level, data can be anything—numbers, text (strings), images, videos, files, or anything
that can be saved on a computer or hard drive.

A database is simply a collection of data that’s organised in a way that makes it easy to
access, update, and manage.

In this course, we’re focusing on relational databases. In a relational database, data is stored
in tables, and these tables are connected to each other using specific fields.

Relations

In relational databases, relations are just another name for tables. Each table is designed to
store information about one specific subject or type of data.

For example, imagine a table you use to store your friends’ contact details. Each row holds
information about one friend. That entire table is called a relation.

Tuples

Tuples are the rows in a table. Each row (or tuple) represents one complete record or item.
Using the friends’ contact table again, a single tuple might contain one friend’s name, phone
number, and email address.
Attributes

Attributes are the columns in a table. Each attribute represents a specific type of
information that every record in the table must have.

In the friends’ contact table, examples of attributes would be Name, Phone Number, and
Email Address.

2
Database Keys

Keys are attributes (or sets of attributes) used to uniquely identify records and define
relationships between tables in a relational database.

Primary Key: The primary key is the table’s ID card, it is a unique identifier for entries in a
table, it never repeats, and is never empty. For example;

Students Table
StudentID Name Level
101 Ada 200
102 Bola 300

The primary key here is StudentID.

Secondary Key: A secondary key is used for searching and filtering, not for identification.
It can repeat. Think of it as a lookup key, not an ID. For example;

Students Table
StudentID Name Department
101 Ada CS
102 Bola CS
103 Chidi IT
The secondary key here is department.
Foreign Key: A foreign key is an attribute or set of attributes in one relation that references
the primary key of another relation. A foreign key is a link between tables. For example;
Students Table
StudentID Name
101 Ada
102 Bola

Enrollments Table
EnrollmentID StudentID Course
1 101 Math
2 102 Physics

Primary Key: EnrollmentID


Foreign Key: StudentID

• [Link] references [Link]


• You cannot insert a student ID that doesn’t exist in Students.

3
RELATIONAL ALGEBRA
To manipulate and retrieve data from a database, we use Structured Query Language.

The basis of SQL, and other query languages, is defined by a mathematical query language
called relational algebra.

The operations in relational algebra take in one or more relations and give a relation(table)
as output.

1. Selection (σ): This retrieves tuples (rows) from a relation. It is made up of those tuples
that meet a certain condition. For example:

Food table:
ID FOOD COST
1 Bread 1500
2 Ice cream 4000
3 Yam 1500

σ (COST = 1500) R
ID FOOD COST
1 Bread 1500
3 Yam 1500

2. Projection (π): This retrieves attributes (columns) from a relation. It also eliminates
repetitions. For example:

Food table
ID FOOD COST
1 Bread 1500
2 Ice cream 4000
3 Yam 1500

π (FOOD, COST) R
FOOD COST
Bread 1500
Ice cream 4000
Yam 1500

3. Union (∪): This retrieves all the tuples from two relations (tables) combined together –
just like Union in set. Both relations must have the same number of fields, with matching
data. Any duplicate tuples following the union are removed.

4
Food_Stuff
ID FOOD COST
1 Fish 2000
2 Eggs 250
3 Yam 1500

Snacks
ID FOOD COST
4 Coke 500
5 Cheese balls 500
6 Chocolate 1500

Food_Stuff ∪ Snacks
ID FOOD COST
1 Fish 2000
2 Eggs 250
3 Yam 1500
4 Coke 500
5 Cheese balls 500
6 Chocolate 1500

4. Intersection (∩): This is similar to set intersection, it only retrieves the tuples from two
relations that appear in both relations (tables). For example:

Tall_Men
NAMES AGE
Clinton 22
Chubi 23
Solomon 24
Paul 21
Wisdom 20

Handsome_Men
NAMES AGE
Pascal 23
Raphael 21
Clinton 22
Onyeka 20
Chubi 23

Tall_Men ∩ Handsome_Men
NAMES AGE
Clinton 22
Chubi 23

5
5. Set Difference (-): This operation returns or results in a relation (table) that has the
tuples in relation A that are not in relation B. In a way, subtracting/ removing rows that
are in the second table from the first table.

For example:

All_Laptops
ID PRODUCT PRICE
1 HP Pavilion 14 650,000
2 Dell XPS 13 720,000
3 Lenovo Thinkpad 550,000
4 Dell Alienware M18 7,100,00
5 Apple MacBook Pro 1,950,000
6 HP Victus 15 1,500,000
7 Acer Predator 3,100,000
8 ASUS ROG 2,600,000
9 HP Elitebook G4 440,000
10 Dell Inspiron 15 760,000

Gaming_Laptops
ID PRODUCT PRICE
4 Dell Alienware M18 7,100,00
6 HP Victus 15 1,500,000
7 Acer Predator 3,100,000
8 ASUS ROG 2,600,000

All_Laptops – Gaming_Laptops
ID PRODUCT PRICE
1 HP Pavilion 14 650,000
2 Dell XPS 13 720,000
3 Lenovo Thinkpad 550,000
5 Apple MacBook Pro 1,950,000
9 HP Elitebook G4 440,000

6. Rename(ρ): Rename is a unary operation used for renaming attributes of a relation. For
example : Ρ(a/b)R will rename the attribute ‘b’ of the relation by ‘a’.

7. Cross Product (x): Cross-product between two relations. Let’s say Tabl A and Table B,
so the cross product between the two relations (tables) will result in all the attributes of
table A followed by each attribute of table B. Each record of table A will pair with every
record of table B. For example:

6
Students
ID Name
1 John
2 Jane

Courses
Code Subject
CS1 Math
CS2 Science

Cross Product (Students × Courses)


ID Name Code Subject
1 John CS1 Math
1 John CS2 Science
2 Jane CS1 Math
2 Jane CS2 Science
You can read up the remaining relational algebra operations, but I just wanted to keep it
simple.

7
THE CONCEPT OF NORMALIZATION

Database normalization is the process of organizing data in a relational database to reduce


redundancy, avoid anomalies, and ensure data integrity by decomposing tables
according to well-defined rules called normal forms.
Normalization is about not repeating the same data unnecessarily and not mixing
unrelated facts in one table. The goal is simple:

• Store each fact once


• Put data in the right place
• Make updates, inserts, and deletes safe and predictable

🔹 FIRST NORMAL FORM (1NF)


A relation is in First Normal Form (1NF) if:

• All attributes contain atomic (indivisible) values


• There are no repeating groups or multi-valued attributes

Each cell in a table should hold one value only — not a list, not a set, not comma-separated
values. If you see something like: “Math, Physics, Chemistry” in one column — that’s not
1NF. For example;

❌ Not in 1NF
StudentID Name Courses
1 Ada Math, Physics
2 Bola Chemistry

✅ In 1NF
StudentID Name Course
1 Ada Math
1 Ada Physics
2 Bola Chemistry

Each cell now contains exactly one value.

🔹 SECOND NORMAL FORM (2NF)


A relation is in Second Normal Form (2NF) if:

• It is in 1NF
• Every non-prime attribute is fully functionally dependent on the whole primary
key (Only if the primary key is composite.)

Every column must depend on the entire key, not just half of it. For example;

8
❌ Not in 2NF

Primary Key = (StudentID, CourseID)

StudentID CourseID StudentName CourseName


1 C101 Ada Math
1 C102 Ada Physics

Problems:

• StudentName depends only on StudentID


• CourseName depends only on CourseID

✅ In 2NF (Decomposed)

Students

StudentID StudentName
1 Ada

Courses

CourseID CourseName
C101 Math
C102 Physics

Enrollments

StudentID CourseID
1 C101
1 C102

Now every attribute depends on the whole key.

🔹 THIRD NORMAL FORM (3NF)

A relation is in Third Normal Form (3NF) if:

• It is in 2NF
• No non-prime attribute is transitively dependent on the primary key

No column should depend on another non-key [Link] other words: 👉 “The key
determines everything — directly.” For example;

9
❌ Not in 3NF

Primary Key = StudentID

StudentID StudentName DeptID DeptName


1 Ada D01 Computer Science

Problem:

• DeptName depends on DeptID


• DeptID depends on StudentID
• That’s a transitive dependency

✅ In 3NF (Decomposed)

Students

StudentID StudentName DeptID


1 Ada D01

Departments

DeptID DeptName
D01 Computer Science

No column depends on another non-key column anymore.

🔹 FOURTH NORMAL FORM (4NF)

A relation is in Fourth Normal Form (4NF) if It is in 3NF and It has no non-trivial


multivalued dependencies. A table should not store two or more independent multi-
valued facts about the same entity. If two columns vary independently, they don’t belong
in the same table. For example;

❌ Not in 4NF
Lecturer Subject Language
Dr. Obi Math English
Dr. Obi Math French
Dr. Obi Physics English
Dr. Obi Physics French

Problem:
• Subjects and languages are independent
• Causes massive repetition

10
✅ In 4NF (Decomposed)

LecturerSubjects
Lecturer Subject
Dr. Obi Math
Dr. Obi Physics

LecturerLanguages
Lecturer Language
Dr. Obi English
Dr. Obi French

Each table now handles one independent fact.

🔹 FIFTH NORMAL FORM (5NF)


A relation is in Fifth Normal Form (5NF) if:

• It is in 4NF
• Every join dependency is implied by candidate keys
→ Meaning: the table can’t be further decomposed without losing information,
unless the decomposition is logically necessary.

5NF happens when a table stores multiple many-to-many relationships at once, and
those relationships are independent.

If the table:
• Can be split into smaller tables
• Those tables can be joined back perfectly
• And the split removes redundancy

Then the table is not in 5NF and must be decomposed.

❌ Not in 5NF
Scenario
A company records:

• Which suppliers supply which parts


• Which parts are used in which projects
• Which suppliers work on which projects

11
All in one table:

❌ Single Table
Supplier Part Project
S1 P1 J1
S1 P2 J1
S2 P1 J1
S2 P1 J2

This table mixes three independent relationships:


1. Supplier ↔ Part
2. Supplier ↔ Project
3. Part ↔ Project

This creates:
• Redundancy
• Update anomalies
• Artificial combinations
• Logical ambiguity

✅ In 5NF (Proper Decomposition)

1) Supplier–Part
Supplier Part
S1 P1
S1 P2
S2 P1

2) Supplier–Project
Supplier Project
S1 J1
S2 J1
S2 J2

3) Part–Project
Part Project
P1 J1
P2 J1
P1 J2

You get exactly the original valid combinations — no fake rows, no loss, no duplication.

12
Quick Summary of Normalization

Normal Form Main Rule


1NF Atomic values only
2NF No partial dependency
3NF No transitive dependency
4NF No independent multivalued facts
5NF No unnecessary join dependencies

NORMAL TEST REMEDY (NORMALIZATION)


FORM
1NF The relation should have no non- Form a name relation for each non-
atomic attributes or nested atomic attribute or nested relation.
relations.
2NF For relations where the primary key Decompose and set up a new
contains multiple attributes, no non- relation for each partial key with its
key dependent attributes.
attributes should be functionally Make sure to keep a relationship
dependent on a part of the primary with the original primary key and
key. any attributes that are fully
functionally dependent on it.
3NF The relation should not have a non- Decompose and set up a relation
key attribute functionally that includes the non-key
determined by another non-key attribute(s) that functionally
attribute (or by a set of non-key determine(s) another non-key
attributes) i.e., there should be attribute (s).
no transitive dependency of a non-
key attribute of the primary key.
4NF The relation should not have a Decompose the table into two
multi-value dependency means it subtables.
occurs when two attributes of a
table are independent of each other
but both depend on a third attribute.
5NF The relation should not have join Decompose all the tables into as
dependency means if a table can be many as possible numbers in order
recreated by joining multiple tables to avoid dependency.
and each of the tables has a subset
of the attributes of the table, then
the table is in Join Dependency.

13
ENTITY RELATIONSHIP DIAGRAMS (ERDs)
An entity relationship diagram is a visual representation of the structure of a database. It
illustrates how entities (such as people, objects, or concepts) relate to one another within a
system. Entity relationship diagrams are essential for designing databases, ensuring data is
organized efficiently, and facilitating clear communication among stakeholders.

It’s best to learn how to draw one, rather than learning history and many other long
explanations.

How to Draw an ER Diagram:


Here are the steps you can follow to draw an ER diagram clearly and accurately. By following
these steps, you can create a clear and organized diagram that accurately represents the
structure of your database.

Step 1. Identify the Entities


Entities are the things or objects that have data stored about them. They are the primary
subjects in the system you’re modeling, such as a Person, Place, Event, or Object.

Imagine you’re creating an ER diagram for a University Database. In this case, some
entities might be:

• Student
• Course
• Instructor
• Department
How to identify entities:

• Look at the system or domain you’re modeling and ask, “What are the important
objects or concepts that need their own data?”
• Entities are usually represented by rectangles in an ER diagram.

Step 2. Define the Attributes


Attributes are the details or characteristics that describe the entities. They provide more
information about an entity. Each entity can have one or more attributes.

14
For the Student entity, you might define the following attributes:

• StudentID (a unique identifier for each student)


• Name
• Email Address
• Date of Birth
Attributes are represented by ovals connected to their respective entities.

How to define attributes:

• Consider what information you would need to describe the entity. For example,
for a Course entity, you might have attributes like CourseID, Title, and Credits.
• Attributes are often written inside ovals and connected to the corresponding
entity with a line.

Step 3. Establish Relationships


Relationships describe how entities are linked to one another. A relationship represents an
association between two or more entities. For example:

• A Student enrolls in a Course.


• An Instructor teaches a Course.
How to establish relationships:

• Look for interactions or connections between entities. Ask yourself, “How do


these entities relate to each other?”

• For example, a Student and a Course are related through the Enrolls In
relationship.

• Relationships are represented by diamonds and connected to entities using


lines.

15
Step 4. Specify Cardinality
Cardinality defines the number of instances of one entity that can be associated with
instances of another entity. There are several types of cardinality relationships:

• One-to-One (1:1): One instance of Entity A is associated with one instance of


Entity B.
• One-to-Many (1:M): One instance of Entity A is associated with multiple
instances of Entity B.
• Many-to-Many (M:N): Multiple instances of Entity A can be associated with
multiple instances of Entity B.
Example:

• A Student can enroll in many Courses, but each Course can have many
Students. This is a Many-to-Many relationship.
• For a Student and Instructor, one instructor can teach many students, but each
student only has one Instructor for a particular course. This is a One-to-Many
relationship.
How to specify cardinality:

• Cardinality is typically shown by placing annotations like crow’s feet (for “many”),
or using numbers (e.g., 1, N, or M) near the relationship lines.

Cardinality

16
Step 5. Add Primary Keys
A primary key uniquely identifies each instance of an entity. It’s important to choose an
attribute (or set of attributes) that uniquely identifies each record in the database. Example:

• StudentID might be the primary key for the Student entity because each student
has a unique ID.
• CourseID might be the primary key for the Course entity because each course
has a unique identifier.
How to add primary keys:
• Underline the attribute(s) that act as the primary key in each entity.

Step 6. Draw the Diagram


At this point, you’ve gathered all the necessary components: entities, attributes,
relationships, cardinalities, and primary keys. Now it’s time to draw the ER diagram.
How to draw the diagram:
• Draw a rectangle for each entity.
• Add ovals for each attribute and connect them to the appropriate entity.
• Use diamonds to represent relationships and connect them to the related
entities with lines.
• For cardinality, add symbols like crow’s feet or numbers on the relationship lines.
• Underline primary keys.

Step 7. Review and Refine


Once you’ve drawn the diagram, it’s essential to review it for clarity and completeness.

• Check if all entities and relationships are correctly represented.


• Ensure that all primary keys are correctly underlined.
• Verify that cardinalities accurately represent the relationships.
• Simplify any overly complex parts of the diagram for better readability.
If you still don’t understand entity relationship diagrams after reading this section
twice, then save yourself the stress and watch BOTH these videos. BOTH!!!:
[Link]

[Link]

17
STRUCTURED QUERY LANGUAGE (SQL)
In this section, I will skip DDL, DML and the rest. Our exam won’t be about defining and
explaining the categories of SQL queries, but rather about using them to create and
manipulate tables(relations) in a database. However, I will include the different SQL queries
and what category they fall into later.
SQL is just a language that we use to do stuff in actual databases (like the one we have in
our xampp), it’s quite similar to relational algebra that we did before. It is a simple easy like
language, with keywords for each database operation. I have colour coded tge keywords,
attributes (tables) and data below. These are the most used queries in SQL;
NOTE: SQL KEYWORDS, Tables, Attributes, & Values, use this font.

1. SELECT: Fetch data


SELECT * FROM Students; -- Get all columns
SELECT name, age FROM Students WHERE age > 18; -- Get specific
columns with condition
2. INSERT: Add data
INSERT INTO Students (id, name, age) VALUES (1, 'John', 20);
3. UPDATE: Modify data
UPDATE Students SET age = 21 WHERE id = 1;
4. DELETE*: Remove specific rows
DELETE FROM Students WHERE id = 1;
5. TRUNCATE: Remove all rows (resets auto-increment)
TRUNCATE TABLE Students;
6. CREATE*: Make a table
CREATE TABLE Students (id INT, name VARCHAR(50));
7. DROP: Delete a table
DROP TABLE Students;

Here’s an example of how the queries work;


1. CREATE TABLE
CREATE TABLE Employees (
ID INT PRIMARY KEY,
Name VARCHAR(50),
Age INT,
Dept VARCHAR(20)
);

Employees
ID Name Age Dept
_Table is created, no data_

18
2. INSERT
INSERT INTO Employees (ID, Name, Age, Dept) VALUES
(1, 'John', 25, 'HR'),
(2, 'Jane', 30, 'IT'),
(3, 'Joe', 28, 'HR');

Employees
ID Name Age Dept
1 John 25 HR
2 Jane 30 IT
3 Joe 28 HR

3. SELECT
SELECT * FROM Employees WHERE Dept = 'HR';

Result:
ID Name Age Dept
1 John 25 HR
3 Joe 28 HR

Employees (no change)


ID Name Age Dept
1 John 25 HR
2 Jane 30 IT
3 Joe 28 HR

4. UPDATE
UPDATE Employees SET Age = 31 WHERE ID = 2;

Employees
ID Name Age Dept
1 John 25 HR
2 Jane 31 IT
3 Joe 28 HR

5. DELETE
DELETE FROM Employees WHERE ID = 3;

Employees
ID Name Age Dept
1 John 25 HR
2 Jane 31 IT

19
6. TRUNCATE
TRUNCATE TABLE Employees;

Employees
ID Name Age Dept
_Table is empty_

These are just a few of them, make sure you read up all the SQL syntax in the main pdf for
this course, because it might come out. SQL is easy to understand 😊

Important: The empty tables are normal written as {NULL}. I just drew out an empty
table to show that the structure still exists, also if you were to drop a table, it will seize
to exist.
CATEGORIES OF SQL QUERIES
It would be good if we remember the syntax of at least five of these queries in each
category, it might come out in the exam.
DDL (Data Definition Language):

Command Description Syntax

CREATE Create database or its objects CREATE TABLE table_name


(table, index, function, views, (column1 data_type, column2
store procedure, and triggers) data_type, ...);

DROP Delete objects from the DROP TABLE table_name;


database
ALTER Alter the structure of the ALTER TABLE table_name ADD
database COLUMN column_name data_type;
TRUNCATE Remove all records from a TRUNCATE TABLE table_name;
table, including all spaces
allocated for the records are
removed
COMMENT Add comments to the data COMMENT 'comment_text' ON
dictionary TABLE table_name;
RENAME Rename an object existing in RENAME TABLE old_table_name TO
the database new_table_name;

DQL (Data Query Language):

Command Description Syntax


SELECT It is used to retrieve data SELECT column1, column2, ...FROM
from the database table_name WHERE condition;

20
DML (Data Manipulation Language):
Command Description Syntax
INSERT Insert data into a INSERT INTO table_name (column1, column2,
table ...) VALUES (value1, value2, ...);

UPDATE Update existing UPDATE table_name SET column1 = value1,


data within a table column2 = value2 WHERE condition;

DELETE Delete records DELETE FROM table_name WHERE condition;


from a database
table
LOCK Table control LOCK TABLE table_name IN lock_mode;
concurrency
CALL Call a PL/SQL or CALL procedure_name(arguments);
JAVA subprogram
EXPLAIN Describe the EXPLAIN PLAN FOR SELECT * FROM
PLAN access path to table_name;
data

DCL (Data Control Language):


Command Description Syntax
GRANT Assigns new privileges to GRANT privilege_type
a user account, allowing [(column_list)] ON
access to specific [object_type] object_name TO
database objects, actions, user [WITH GRANT OPTION];
or functions.
REVOKE Removes previously REVOKE [GRANT OPTION FOR]
granted privileges from a privilege_type [(column_list)]
user account, taking away ON [object_type] object_name
their access to certain FROM user [CASCADE];
database objects or
actions.

TCL (Transaction Control Language):


Command Description Syntax
BEGIN Starts a new transaction BEGIN TRANSACTION
TRANSACTION [transaction_name];
COMMIT Saves all changes made during COMMIT;
the transaction
ROLLBACK Undoes all changes made ROLLBACK;
during the transaction
SAVEPOINT Creates a savepoint within the SAVEPOINT savepoint_name;
current transaction

21
DATA ORGANIZATION/ REPRESENTATION
Data organization refers to the systematic arrangement of data in a structured format,
making it easy to retrieve, analyze, and interpret. I’m not going to explain anything here,
because we will just be given data to represent in different ways. We will learn Frequency
Distribution, Tally, Bar Chart, Histogram, and Pie Chart.
Example:
The test scores of some cyber security students are; 20, 16, 27, 23, 24, 12, 15, 18, 19, 16,
21, 22, 23, 17, 21, 24, 23, 25, 18, 30.
Frequency Distribution
Range Frequency
10-15 2
16-20 6
21-25 9
26-30 2
Total 19

Tally
Range Frequency Tally
10-15 2 ||
16-20 6 |||| |
21-25 9 |||| ||||
26-30 2 ||
Total 19 |||| |||| ||||

Bar Chart

Frequency
10
9
8
7
6
5
4
3
2
1
0
10 - 15 16 - 20 21 - 25 26 - 30

Frequency

22
Histogram

Frequency
10

0
10 - 15 16 - 20 21 - 25 26 - 30

Pie Chart

SCORES10 - 15
26 - 30
10.53% 10.53%

37.9o 37.9o

113.7o
170.5 o 16 - 20
31.58%

21 - 25
47.37%

The Bar Chart and Histogram were plotted directly from the frequency distribution table.
While for the Pie Chart, we use the total amount of frequencies and this formula;

𝒇
Angle = ( ) × 𝟑𝟔𝟎∘
𝑻
Where 𝑓 is frequency, and 𝑇 is total.

23
2
Angle(10 - 15) = × 360∘
19
720
Angle(10 - 15) =
19
Angle(10 - 15) = 𝟑𝟕. 𝟗∘

6
Angle(16 - 20) = × 360∘
19
2160
Angle(16 - 20) =
19
Angle(16 - 20) = 𝟏𝟏𝟑. 𝟕∘

9
Angle(21 - 25) = × 360∘
19
3240
Angle(21 - 25) =
19
Angle(21 - 25) = 𝟏𝟕𝟎. 𝟓∘

2
Angle(26 - 30) = × 360∘
19
720
Angle(26 - 30) =
19
Angle(26 - 30) = 𝟑𝟕. 𝟗∘

If you sum all the angles, it gives you 360o.

24
HASHING AND INDEXING
WHAT IS INDEXING?
Indexing, as the name suggests, is a technique or mechanism generally used to speed up
access of data. The index is a type of data structure that is used to locate and access data in
a database table quickly. Indexes can easily be developed or created using one or more
columns of a database table.
Indexing is just a smart way to find data faster in a database. Think of it like the index at the
back of a textbook—instead of flipping through every page, you go straight to what you need.
In a database, an index is a special structure that helps the system quickly locate data in a
table. These indexes are created using one or more columns, so when you search using
those columns, the database doesn’t have to scan everything—it jumps straight to the result.

In a Relational Database (SQL), you can implement indexing using SQL


commands:
• Single-column index:
CREATE INDEX idx_student_name ON students (name);

This creates an index on the name column to speed up searches based on student
names.
• Create a compound index (multiple columns):
CREATE INDEX idx_student_name_age ON students (name, age);

This index is useful for queries that filter by both name and age.

WHAT IS HASHING?
Hashing, as name suggests, is a technique or mechanism that uses hash functions with
search keys as parameters to generate address of data record. It calculates direct location
of data record on disk without using index structure.
Hashing takes a search key (what you searched for) and runs it through a hash function,
which turns the key into a special value called a hash. That hash value points directly to
where the data is stored on disk, so the system doesn’t need to use an index or search
through records.
A good hash functions only uses one-way hashing algorithm and hash cannot be converted
back into original key. In simple words, it is a process of converting given key into another
value known as hash value or simply hash.

25
In a Relational Database (SQL), you can implement Hashing by;

1. Using Built-in Hash Functions


Most relational database management systems (RDBMS) provide built-in functions to
generate hash values.
• SQL Server: Use the HASHBYTES function, which supports algorithms like
SHA2_256 and SHA2_512.
• MySQL: The PASSWORD() and OLD_PASSWORD() functions were used for
authentication purposes, but modern applications should use more robust,
language-side hashing libraries (like bcrypt) before storing the hash in the
database.
• Other Databases (Snowflake, DB2): Use functions
like HASH or HASH_SHA256 as provided by the specific platform's SQL dialect.
Example: Calculating a Hash in SQL Server
To generate a hash value for a single column or a combination of columns, you can use
the HASHBYTES function. Note that input values need to be converted to a character or
binary type.
SELECT HASHBYTES('SHA2_256', CAST(Col1 AS VARBINARY(8000)) +
CAST(Col2 AS VARBINARY(8000))) AS HashedValue FROM MyTable;

2. Implementing Hash Indexes


Databases use hash tables internally for operations like JOIN and GROUP BY, and you
can also create a hash index on a specific column to speed up equality lookups
(e.g., WHERE column = value). Hash indexes are not suitable for range queries
(e.g., WHERE column > value).
Example: Creating a Hash Index in PostgreSQL
CREATE INDEX idx_books_barcode ON books USING HASH (barcode);

I don’t really understand the implementation of hashing and indexing at a more in-depth
level. Just accept the information as it is. May we pass our exams in Jesus’ Name.

26
DATABASE SECURITY
Database Security is quite broad, so I’ll explain general information a bit, then we jump to
Hashing and Indexing.
Data security refers to the prevention of data from unauthorized users. It is only allowed to
access the data to the authorized users. In the database, the DBA (Database Administrator)
or head of the department can access all the data. Some users are only allowed to retrieve
data, whereas others are allowed to retrieve and modify the data.

Data security is basically about keeping data away from people who shouldn’t have access
to it and making sure only the right users can see or use it. In a database, the DBA or maybe
the head of a department usually has full access, while other users are given limited rights—
some can only view the data and others can view and edit it. To keep everything safe, data
security focuses on the CIA triad, which means confidentiality (only authorized people can
see the data), integrity (the data shouldn’t be changed wrongly), and availability (authorized
users should be able to access it when they need it). This is done using things like encryption,
strong access controls, regular checks, system updates, activity monitoring, and the idea of
least privilege, where users only get the access they actually need.

Data integrity is concerned whether data contained in the database is both correct and
consistent. For this purpose, the data stored in the database must satisfy certain procedures
(rules). DBMS provides different ways to implement such types of constraints (rules). The
rules/constraints here are the primary, secondary and foreign keys that we discussed earlier.
They are what ensure the correctness of data.

Data integrity just means making sure the data is correct and makes sense. The
information stored in a database should not be wrong, mixed up, or contradict itself. To make
this happen, the database follows some basic rules. A DBMS helps by enforcing these rules
automatically. For example, primary keys make sure each record is unique, foreign keys
make sure related data actually matches, and other keys help keep things organized. These
rules stop mistakes like duplicate records or wrong links, so the data stays clean, accurate,
and trustworthy

I can’t really imagine how questions from this topic will be like. Let us just understand
the differences between Data Security and Data Integrity, then pray to God Almighty
as he is the Omniscient God that knows all.

27

You might also like