Database Normalization

Database normalization is a systematic approach used to organize a relational database in a

way that reduces data redundancy and improves data integrity. The goal of normalization is to
divide a large table into smaller, more manageable and related tables, while ensuring that
relationships between the data are maintained and anomalies (such as update, insert, and delete
anomalies) are avoided.

Key Concepts in Database Normalization

1. Data Redundancy: This occurs when the same piece of data is stored in multiple places.
Normalization reduces redundancy, which in turn minimizes the risk of data
inconsistency.
2. Data Integrity: It ensures that data is accurate and consistent throughout the database.
With a properly normalized database, you avoid problems like having different values for
the same piece of information in various places.
3. Functional Dependency: This is a relationship that describes how one attribute uniquely
determines another attribute. It plays a key role in the normalization process.
4. Normalization Forms: There are several stages, or "normal forms," of database
normalization, each addressing specific issues in database structure.

Normalization Forms (NF)

1. First Normal Form (1NF)

● A table is in 1NF if:

o All data is stored in atomic form (i.e., each field contains only a single value, not
sets or lists).
o There are no repeating groups or arrays in any column.
● Example: If you have a table with a column that stores a list of phone numbers, splitting
the phone numbers into separate rows or columns would bring the table into 1NF.

2. Second Normal Form (2NF)

● A table is in 2NF if:

o It is in 1NF.
o All non-key attributes are fully functionally dependent on the primary key (i.e.,
no partial dependency).
o Example: If a table contains a composite primary key (two or more columns), and
some attributes depend only on part of that key, the table needs to be split so that
each non-key attribute is dependent on the whole primary key.
3. Third Normal Form (3NF)

● A table is in 3NF if:

o It is in 2NF.
o There are no transitive dependencies (i.e., non-key attributes depend only on the
primary key, not on other non-key attributes).
● Example: If you have a table where an attribute like "City" depends on another attribute
"ZIP Code," you would move the "City" attribute to a separate table to eliminate this
transitive dependency.

4. Boyce-Codd Normal Form (BCNF)

● A table is in BCNF if:

o It is in 3NF.
o For every functional dependency X→YX \to YX→Y, XXX should be a superkey.
o Example: If a non-candidate key column is functionally determining another
column, even in 3NF, the table may still violate BCNF and need further
decomposition.

5. Fourth Normal Form (4NF)

● A table is in 4NF if:

o It is in BCNF.
o It contains no multivalued dependencies (where one attribute in a table
determines multiple values of another attribute independently of other attributes).
● Example: If a student can enroll in multiple courses, and a course can have multiple
instructors, you should create separate tables to avoid multiple values in a single field.

6. Fifth Normal Form (5NF)

● A table is in 5NF if:

o It is in 4NF.
o It cannot be decomposed further without losing data or introducing redundancy.
● Example: Complex relationships involving many-to-many dependencies between
attributes can be normalized further into 5NF.

Benefits of Database Normalization

● Reduces Data Redundancy: By eliminating duplicate data, normalization ensures that

information is stored in only one place.
● Improves Data Integrity: Since there’s only one source for each piece of data, the
chances of inconsistent data are reduced.
● Prevents Anomalies:
 oUpdate Anomalies: Ensures that changes to data are made in one place and
automatically reflected throughout the database.
o Insert Anomalies: Prevents the insertion of inconsistent or incomplete data.
o Delete Anomalies: Ensures that deleting data doesn’t accidentally remove needed
information.
● Efficient Database Management: Normalized databases are easier to manage and scale
as they grow in complexity.

When to Denormalize

Sometimes, for performance reasons, databases are denormalized. This involves reintroducing
some redundancy to speed up read operations. However, this trade-off can lead to increased
complexity in maintaining data integrity. Therefore, normalization is a standard starting point in
database design, with denormalization used selectively in cases where performance gains are
critical.

In summary, normalization is a critical database design principle aimed at organizing data

efficiently and ensuring data consistency by breaking down large tables into smaller, related
ones.

ENTITY RELATIONSHIP MODELING

Entity Relationship Modeling (ER Modeling) is a diagrammatic technique used to represent

the structure of a database in terms of entities, attributes, and the relationships between them. ER
Modeling helps in designing the database schema visually before it is implemented, enabling the
developer to better understand the logical structure of the system. It forms the foundation of
relational databases.

The primary components of an ER Model include entities, relationships, and attributes. These
elements are usually represented in a diagram called an Entity Relationship Diagram (ERD).

Key Concepts in ER Modeling

1. Entity

An entity represents a real-world object, concept, or thing that has a distinct existence in the
system you are modeling. In a database, an entity typically corresponds to a table.

● Entity Types: These are the general categories or classes of objects. For example, in a
university database, "Student" and "Course" would be entity types.
 ● Entity Instance: A single, specific occurrence of an entity type. For instance, "John Doe"
is an instance of the "Student" entity.

Entities are typically shown as rectangles in an ER diagram.

2. Attributes

Attributes represent properties or characteristics of an entity. In a database, they correspond to

columns in a table.

● Simple Attribute: Attributes that cannot be further divided (e.g., StudentID,

FirstName).
● Composite Attribute: Attributes that can be subdivided into smaller attributes (e.g.,
FullName can be divided into FirstName and LastName).
● Multivalued Attribute: Attributes that can have multiple values (e.g., PhoneNumbers if a
person can have more than one contact number).
● Derived Attribute: Attributes whose values can be calculated or derived from other
attributes (e.g., Age could be derived from the DateOfBirth attribute).

Attributes are represented as ovals in an ER diagram and connected to their respective entities.

3. Relationships

A relationship defines how two or more entities are associated with each other. In databases, this
corresponds to the foreign key relationship between tables.

● Binary Relationship: Involves two entities. For example, a "Student" enrolls in a

"Course."
● Unary Relationship (Recursive Relationship): An entity is related to itself. For
example, an "Employee" manages other "Employees."
● Ternary Relationship: Involves three entities. For example, a "Doctor" treats a
"Patient" at a specific "Hospital."

Relationships are represented as diamonds in an ER diagram, with lines connecting the entities
involved.

4. Cardinality

Cardinality specifies the number of instances of one entity that can or must be associated with
each instance of another entity.

● One-to-One (1:1): A single instance of one entity is related to a single instance of

another entity (e.g., a person has one passport).
● One-to-Many (1
 ): A single instance of one entity is related to many instances of another entity (e.g., one
department has many employees).

● Many-to-Many (M

): Many instances of one entity are related to many instances of another entity (e.g., a
student can enroll in multiple courses, and a course can have multiple students).

Cardinality is often depicted on the connecting lines between entities in the ER diagram.

5. Keys

In ER modeling, keys are attributes or sets of attributes that uniquely identify instances of an
entity.

● Primary Key: A unique identifier for an entity instance (e.g., StudentID).

● Foreign Key: An attribute in one entity that links to the primary key of another entity,
establishing a relationship between them.

Components of an ER Diagram

1. Entities: Represented by rectangles.

2. Attributes: Represented by ovals connected to their respective entities.
3. Relationships: Represented by diamonds with lines connecting the entities they
associate.
4. Cardinality Constraints: Shown as numbers or symbols on the connecting lines to
indicate whether the relationship is one-to-one, one-to-many, or many-to-many.

Example of an ER Diagram

For a university database:

● Entities: Student, Course, Professor

● Attributes:
o Student: StudentID (Primary Key), Name, DOB, Email
o Course: CourseID (Primary Key), CourseName, Credits
o Professor: ProfessorID (Primary Key), Name, Department
● Relationships:
o EnrolledIn: A Student is enrolled in Courses (many-to-many relationship).
o Teaches: A Professor teaches multiple Courses (one-to-many relationship).

Types of ER Models

1. Conceptual ER Model: Focuses on high-level structure, representing entities and

relationships without specifying database constraints or data types.
 2. Logical ER Model: More detailed, including attributes, keys, and entity relationships.
Typically used in database design.
3. Physical ER Model: Focuses on how the logical ER model will be implemented in a
specific database management system (DBMS), including table structures, columns, and
relationships.

Advantages of ER Modeling

● Clear Visual Representation: ER diagrams provide a clear and intuitive visual

representation of the database structure.
● Improved Database Design: It helps in planning and understanding the relationships
between entities before actual database implementation.
● Helps in Communication: It serves as a blueprint for developers, business analysts, and
stakeholders to discuss and refine database design.

Limitations of ER Modeling

● Complexity with Large Systems: ER diagrams can become large and complex when
modeling large systems with many entities and relationships.
● Limited in Capturing Data Constraints: While ER models are good for representing
relationships and structure, they do not fully capture all data constraints or business rules.

Enhanced ER Models (EER)

The Enhanced Entity Relationship (EER) model extends the traditional ER model by adding
concepts such as:

● Specialization/Generalization: Hierarchical relationships between a parent entity and

one or more child entities (e.g., "Employee" can be specialized into "Manager" and
"Technician").
● Aggregation: Treats a relationship between entities as a higher-level entity for use in
other relationships.
● Subclasses/Superclasses: Allows entities to inherit properties from other entities.

Entity Relationship Modeling is essential in the database design process, providing a structured
way to visualize and implement a logical database schema, ensuring data consistency, and laying
the groundwork for database systems.
RECURSIVE RELATIONSHIP

A recursive relationship (also called a unary relationship) occurs when an entity in a database
is related to itself. This means that instances of the same entity type can be related to other
instances of that same entity type.

Key Characteristics of a Recursive Relationship

● Same entity: Both ends of the relationship involve the same entity.
● Self-referencing: The relationship refers back to the same entity, allowing instances
within it to be associated with one another.
● Cardinality: Like any relationship, recursive relationships can have different
cardinalities, such as one-to-one, one-to-many, or many-to-many.

Example of Recursive Relationships

1. Employee Manages Employee (One-to-Many)

Consider an "Employee" entity in an organization where one employee can manage other
employees. In this case, the relationship "manages" is recursive because it relates employees to
other employees.

● Entity: Employee
● Relationship: Manages
● Description: An employee (manager) can manage other employees (subordinates).
● Cardinality: One-to-many (one employee manages many other employees).

In an ER diagram:

● The entity Employee will appear only once, but the manages relationship will loop back
to the same entity.
● One employee (manager) can be related to many subordinates (one-to-many
relationship).

2. Course Prerequisite Course (One-to-One)

Another example could be in a university database, where a "Course" can have a prerequisite
course.

● Entity: Course
● Relationship: Prerequisite
● Description: A course can be a prerequisite for another course.
● Cardinality: One-to-one (one course is a prerequisite for only one other course).

In an ER diagram:
 ● The entity Course will have a relationship named Prerequisite that connects to itself.

3. Person is a Friend of Another Person (Many-to-Many)

In a social network database, a person can be friends with multiple other people.

● Entity: Person
● Relationship: Is Friend Of
● Description: A person can have multiple friends, and those friends can also be friends
with each other.
● Cardinality: Many-to-many (a person can have many friends, and each friend can have
many other friends).

In an ER diagram:

● The entity Person will be connected by a friend relationship to other instances of the
Person entity.

Recursive Relationship Types

1. One-to-One (1:1): Each entity instance is related to one other instance of the same entity.
For example, an employee supervises one other employee.
2. One-to-Many (1

): One instance of an entity is related to multiple instances of the same entity. For
example, a manager supervises many employees.

3. Many-to-Many (M

): Multiple instances of an entity are related to multiple other instances of the same entity.
For example, people are friends with multiple other people in a social network.

Modeling Recursive Relationships in ER Diagrams

In an Entity Relationship Diagram (ERD), recursive relationships are represented by:

● A single entity rectangle connected by a relationship line that loops back to the entity
itself.
● Depending on the cardinality (one-to-one, one-to-many, or many-to-many), symbols like
crow's feet (for many) may be used to depict the cardinality constraints.

For example, in the Employee manages Employee relationship, the Employee entity would
have a relationship called manages, with one part of the relationship connecting back to the
entity itself, and the cardinality symbols (1

) would indicate that one employee can manage many others.

Handling Recursive Relationships in Databases

To implement recursive relationships in a relational database:

● One-to-Many Example: In an employee table, you would add a foreign key column
(e.g., ManagerID) that references the primary key (e.g., EmployeeID) of the same table.
This foreign key creates the self-referencing relationship where one employee can
manage other employees.

Table Structure:

scss
Copy code
Employee (EmployeeID, Name, ManagerID)

● Many-to-Many Example: For recursive many-to-many relationships, you would

typically create a separate junction table that contains two columns, both referencing the
primary key of the same entity.

Table Structure:

scss
Copy code
Person (PersonID, Name)
Friends (PersonID1, PersonID2) -- Both columns are foreign keys
referencing PersonID in the Person table

Advantages of Recursive Relationships

● Efficient representation: Recursive relationships allow you to model complex

hierarchical or network structures (such as organizational hierarchies or social networks)
without introducing additional entities.
● Compact design: Recursive relationships keep the ER model simple by avoiding
redundancy and allowing self-referencing within an entity.

Common Uses of Recursive Relationships

● Employee Management: In HR systems, where employees report to other employees.

● Hierarchical Structures: Representing product categories or organizational hierarchies.
● Bill of Materials: In manufacturing databases, where a component can be made up of
other sub-components.
● Social Networks: Modeling friendships, followers, or connections within a social
network.

Challenges with Recursive Relationships

 ● Complex Queries: Recursive relationships may result in complex queries when you need
to navigate through the hierarchy or find relationships between multiple levels (e.g.,
finding all subordinates of a manager).
● Data Integrity: Enforcing data integrity, such as ensuring that a person cannot be a
friend to themselves or that an employee cannot be their own manager, requires careful
handling of constraints in the database design.

In summary, recursive relationships are an essential concept in ER modeling when dealing with
entities that have a relationship with themselves. They are particularly useful for representing
hierarchical or network structures and allow for more sophisticated database designs.