Databases

A database is a collection of related data. By data, we mean known facts that can be recorded and
that have implicit meaning. For example, consider the names, telephone numbers, and addresses
of the people you know. Databases are formed of tables which are used to store multiple
entities. Each entity usually has its own row in a table and fields of that row hold the entity’s
attributes

Relational Database
A relational database is a database which recognises the differences between entities by creating
different tables for each entity. Employee table
EmployeeID Name DepartmentID
1 John Doe 101
2 Jane Smith 102
3 Alice Johnson 101

Flat File
A flat file is a database that consists of a single file. The flat file will most likely be based
around a single entity and its attributes. A simple text file storing data. For example employee:
EmployeeID, Name, Department, Salary
1, John Doe, Sales, 5000
2, Jane Smith, Marketing, 6000
3, Alice Johnson, Sales, 5500

Entities and attributes

An entity is a thing about which data is to be stored, for example: a customer. Attributes are
characteristics or other information about entities, for example: the customer’s name or address

Car
CarID Age Price
Car1 5 years $1,500
Car2 2 years $2,400

Entity identifiers
An entity identifier is an attribute given to each entity which is unique within that table.

Entity description
An example of an entity description is shown below:
Customer (CustomerID, CustomerName, CustomerAddress, CustomerEmail)
The name of the table is shown outside of brackets which contain each of the entity’s attributes
separated by commas.

Primary and foreign keys

A primary key is an attribute that is a unique identifier for every entity in a database table. When
tables are linked by a shared attribute, the attribute must be a primary key in one table and is
called a foreign key in the other.

If it is not possible to form a primary key from just one attribute, it is possible to combine
attributes to form what is called a composite primary key.
The primary key in Pilots is PilotNo and is FlightNo in Flights. The tables are linked by the
shared attribute PilotNo. This makes PilotNo a foreign key in Flights
Secondary Key
A secondary key allows a database to be searched quickly. For example, a patient is unlikely to
remember their patientID but will know their surname. Therefore, a secondary index (secondary
key) is set up on the surname attribute. This makes it possible to order and search by surname
which makes it easier to find specific patients in the database.

Relational Databases
Tables can be related to each other. There are three possible degrees of relationship between
tables in a database: one-to-one, many-to-many and one-to-many.

Entity relationship diagrams

Entity relationship diagrams (or ER diagrams) are used to graphically represent the relationships
between tables in a database. Tables are shown as rectangles and are joined by lines which can
represent different types of relationship.
Database Normalisation
Normalization is the process of organizing a database to reduce redundancy and improve data
integrity. By normalizing a database, data is arranged into tables and columns. A table should
contain only related data. If data is not directly related, a new table for that data should be
created.

Benefits of Normalization
 Minimizes data redundancy (duplicate data).
 Minimizes null values.
 Results in a more compact database.
 Minimizes/avoids data modification issues.
 Simplifies queries.
 The database structure is cleaner and easier to understand.
 You can extend the database without necessarily impacting the existing data.
 Searching, sorting, and creating indexes can be faster, since tables are narrower, and more
rows fit on a data page.
An unnormalized database has the following shortcomings:
1. Update Anomaly
This occurs when data redundancy leads to inconsistency after updates.
When the same piece of information is stored in multiple rows of a table, updating it in one place
but not the others causes inconsistency.
Employee Table:
Employee_ID Name Department Department_Location
1 John Smith IT New York
2 Jane Doe IT New York
3 Mike Ross HR Los Angeles
If the location of the IT department changes to "San Francisco," we must update all rows where
Department = IT.
If we forget to update one row (e.g., for Jane Doe), the table will have inconsistent data, showing
both "New York" and "San Francisco" for the IT department.

2. Insertion Anomaly
This occurs when we cannot insert data into a table because certain fields are dependent on
others, leading to incomplete or irrelevant data.
This happens when a table requires the presence of data that may not yet exist.

Student_Course Table:
Student_I Student_Name Course_ID Course_Name
D
101 Alice Brown C001 Math
102 Bob Green C002 Physics

If we want to insert a new course "Chemistry" without enrolling any students, the table design
requires both Student_ID and Student_Name. This means we cannot add the course unless we
associate it with a student, leading to an insertion anomaly.

3. Deletion Anomaly
This occurs when deleting data unintentionally results in the loss of important information.
When a table stores multiple pieces of information in a single structure, deleting a row may
remove necessary data that has no independent representation.
Project_Employee Table:
Project_ID Project_Name Employee_ID Employee_Name
P001 Alpha 1 John Smith
P002 Beta 2 Jane Doe

If the last employee working on a project (e.g., John Smith) leaves the project, deleting their
record will also delete the project details (P001, Alpha). This is problematic if we still need the
project information even after all employees are removed.

These anomalies are not good for referential integrity.

Referential Integrity in Databases
Referential integrity a concept in relational databases that ensures the relationships between
tables remain consistent. It enforces rules to prevent invalid or orphaned references between
related tables.
Key Concept:
 Primary Key (PK): A unique identifier for a row in a table.
 Foreign Key (FK): A field in one table that references the primary key of another table.
Referential integrity ensures that:
1. A foreign key in one table must either match a primary key in another table or be NULL.
2. Actions such as inserting, updating, or deleting data in the referenced table are restricted
to maintain consistency.

Example of Referential Integrity

Tables:
1. Customers Table (Parent table):
Customer_ID Name Email
(PK)
101 John Smith [email protected]
102 Jane Doe [email protected]
103 Alice Brown [email protected]
 2. Orders Table (Child table with a foreign key Customer_ID referencing Customers):
Order_ID (PK) Customer_ID Order_Date
(FK)
201 101 2025-01-15
202 102 2025-01-16
203 101 2025-01-17

Maintaining Referential Integrity:

1. Insert Rule:
o If you try to insert a row into the Orders table with a Customer_ID that doesn’t
exist in the Customers table (e.g., Customer_ID = 104), it will be rejected.
2. Delete Rule:
o If you try to delete a row in the Customers table (e.g., Customer_ID = 101), it will
result in orphaned rows in the Orders table. To prevent this, referential integrity
rules like ON DELETE CASCADE or ON DELETE RESTRICT can be
applied:
 Cascade: Automatically deletes all related rows in the Orders table.
 Restrict: Prevents deletion until all related rows in Orders are removed.
3. Update Rule:
o If you update a primary key value in the Customers table (e.g., changing
Customer_ID = 101 to Customer_ID = 201), the database ensures the Orders table
updates its foreign key to maintain consistency (if ON UPDATE CASCADE is
set).

Importance of Referential Integrity

 Prevents orphaned records (child records with no parent).
 Ensures data consistency between related tables.
 Protects the logical relationships in the database, making it reliable.