UNIT 4

Functional Dependency:

In relational database management, functional dependency is a concept that specifies

the relationship between two sets of attributes where one attribute determines the
value of another attribute. It is denoted as X → Y, where the attribute set on the left
side of the arrow, X is called Determinant, and Y is called the Dependent.
OR
Functional dependency in DBMS is an important concept that describes the
relationship between attributes (columns) in a table. It shows that the value of one
attribute determines the other.

Functional Dependency Set:

Functional Dependency set or FD set of a relation is the set of all FDs present in the
relation.
Advantages of functional dependencies:
 They help in reducing data redundancy in a database by identifying and
eliminating unnecessary or duplicate data.

 They improve data integrity by ensuring that data is consistent and accurate
across the database.
 They facilitate database maintenance by making it easier to modify, update, and
delete data.
Armstrong’s axioms/properties of functional dependencies:

Reflexivity: If Y is a subset of X, then X→Y holds by reflexivity rule

Example, {roll_no, name} → name is valid.
Augmentation: If X → Y is a valid dependency, then XZ → YZ is also valid by
the augmentation rule.
Example, {roll_no, name} → dept_building is valid, hence {roll_no, name,
dept_name} → {dept_building, dept_name} is also valid.
Transitivity: If X → Y and Y → Z are both valid dependencies, then X→Z is also
valid by the Transitivity rule.
Example, roll_no → dept_name & dept_name → dept_building, then roll_no →
dept_building is also valid.

Types of Functional Dependencies in DBMS:

1. Trivial functional dependency
2. Non-Trivial functional dependency
3. Multivalued functional dependency
4. Transitive functional dependency
5. Full functional dependency.
6. Partial functional dependency
Anomalies in Relational Model
Anomalies in the relational model refer to inconsistencies or errors that can arise
when working with relational databases, specifically in the context of data insertion,
deletion, and modification. There are different types of anomalies that can occur in
referencing and referenced relations which can be discussed as:

These anomalies can be categorized into three types:

 Insertion Anomalies
 Deletion Anomalies
 Update Anomalies.

How Are Anomalies Caused in DBMS?

Database anomalies are the faults in the database caused due to poor management of
storing everything in the flat database. It can be removed with the process
of Normalization, which generally splits the database which results in reducing the
anomalies in the database.

STUDENT Table
STUD_N STUD_NAM STUD_PHON STUD_STAT STUD- STUD_AG
O E E E COUNTR E
Y

1 RAM 9716271721 Haryana India 20

2 RAM 9898291281 Punjab India 19

3 SUJIT 7898291981 Rajasthan India 18

4 SURESH Punjab India 21

Table 1
STUDENT_COURSE
STUD_NO COURSE_NO COURSE_NAME

1 C1 DBMS

2 C2 Computer Networks

1 C2 Computer Networks
Table 2
Insertion Anomaly: If a tuple is inserted in referencing relation and referencing
attribute value is not present in referenced attribute, it will not allow insertion in
referencing relation.
Example: If we try to insert a record in STUDENT_COURSE with STUD_NO =7, it
will not allow it.
Deletion and Updation Anomaly: If a tuple is deleted or updated from referenced
relation and the referenced attribute value is used by referencing attribute in
referencing relation, it will not allow deleting the tuple from referenced relation.
Example: If we want to update a record from STUDENT_COURSE with STUD_NO
=1, We have to update it in both rows of the table. If we try to delete a record from
STUDENT with STUD_NO =1, it will not allow it.
To avoid this, the following can be used in query:
ON DELETE/UPDATE SET NULL: If a tuple is deleted or updated from
referenced relation and the referenced attribute value is used by referencing attribute
in referencing relation, it will delete/update the tuple from referenced relation and set
the value of referencing attribute to NULL.
ON DELETE/UPDATE CASCADE: If a tuple is deleted or updated from
referenced relation and the referenced attribute value is used by referencing attribute
in referencing relation, it will delete/update the tuple from referenced relation and
referencing relation as well.
How These Anomalies Occur?
Insertion Anomalies: These anomalies occur when it is not possible to insert data
into a database because the required fields are missing or because the data is
incomplete. For example, if a database requires that every record has a primary key,
but no value is provided for a particular record, it cannot be inserted into the database.
Deletion anomalies: These anomalies occur when deleting a record from a database
and can result in the unintentional loss of data. For example, if a database contains
information about customers and orders, deleting a customer record may also delete
all the orders associated with that customer.
Update anomalies: These anomalies occur when modifying data in a database and
can result in inconsistencies or errors. For example, if a database contains information
about employees and their salaries, updating an employee’s salary in one record but
not in all related records could lead to incorrect calculations and reporting.

Removal of Anomalies

These anomalies can be avoided or minimized by designing databases that adhere to

the principles of normalization. Normalization involves organizing data into tables
and applying rules to ensure data is stored in a consistent and efficient manner. By
reducing data redundancy and ensuring data integrity, normalization helps to
eliminate anomalies and improve the overall quality of the database

According to [Link], who is the inventor of the Relational Database, the goals of
Normalization include:
 It helps in vacatingall the repeated data from the database.
 It helps in removing undesirable deletion, insertion, and update anomalies.
 It helps in making a proper and useful relationship between tables.

Advantages Anomalies in Relational Model

Data Integrity: Relational databases enforce data integrity through various

constraints such as primary keys, foreign keys, and referential integrity rules, ensuring
that the data is accurate and consistent.
Scalability: Relational databases are highly scalable and can handle large amounts of
data without sacrificing performance.
Flexibility: The relational model allows for flexible querying of data, making it easier
to retrieve specific information and generate reports.
Security: Relational databases provide robust security features to protect data from
unauthorized access.
Disadvantages of Anomalies in Relational Model
Redundancy: When the same data is stored in various locations, a relational
architecture may cause data redundancy. This can result in inefficiencies and even
inconsistent data.
Complexity: Establishing and keeping up a relational database calls for specific
knowledge and abilities and can be difficult and time-consuming.
Performance: Because more tables must be joined in order to access information,
performance may degrade as a database gets larger.
Incapacity to manage unstructured data: Text documents, videos, and other forms
of semi-structured or unstructured data are not well-suited for the relational paradigm.

Normalization in SQL (1NF - 5NF):

Database normalization is an important process used to organize and structure relational databases.
This process ensures that data is stored in a way that minimizes redundancy, simplifies querying, and
improves data integrity.

What is Normalization in SQL?

Normalization, in this context, is the process of organizing data within a database
(relational database) to eliminate data anomalies, such as redundancy.
In simpler terms, it involves breaking down a large, complex table into smaller and
simpler tables while maintaining data relationships.
Normalization is commonly used when dealing with large datasets.
Some scenarios where normalization is often used.
Data integrity
Imagine a database that contains customer information. Without normalization, if a
customer changes their age, we would need to update it in multiple places, which
would increase the risk of inconsistencies. By normalizing the data, we can have
separate tables linked by a unique identifier that will ensure that the data remains
accurate and consistent.
Efficiency querying
Let’s consider a complex database with multiple related tables that stores redundant
information. In this scenario, queries involving joins become more complicated and
resource-intensive. Normalization will help simplify querying by breaking down data
into smaller tables, with each table containing only relevant information, thereby
reducing the need for complex joins.
Storage optimization
A major problem with redundant data is that it occupies unnecessary storage space.
For instance, if we store the same product details in every order record, it leads to
duplication. With normalization, you can eliminate redundancy by splitting data into
separate tables.

Why is Normalization in SQL Important?

 Normalization plays a crucial role in database design. Here are several reasons why
it’s essential:
 Reduces redundancy: Redundancy is when the same information is stored
multiple times, and a good way of avoiding this is by splitting data into smaller tables.
 Improves query performance: You can perform faster query execution on
smaller tables that have undergone normalization.
 Minimizes update anomalies: With normalized tables, you can easily update
data without affecting other records.
 Enhances data integrity: It ensures that data remains consistent and accurate.

What Causes the Need for Normalization?

If a table is not properly normalized and has data redundancy, it will not only take up
extra data storage space but also make it difficult to handle and update the database.
There are several factors that drive the need for normalization, from data
redundancy(as covered above) to difficulty managing relationships. Let’s get right
into it:
Insertion, deletion, and update anomalies: Any form of change in a table can lead to
errors or inconsistencies in other tables if not handled carefully. These changes can either
be adding new data to a database, updating the data, or deleting records, which can lead to
unintended loss of data.
Difficulty in managing relationships: It becomes more challenging to maintain complex
relationships in an unnormalized structure.
Other factors that drive the need for normalization are partial
dependencies and transitive dependencies, in which partial dependencies can lead to
data redundancy and update anomalies, and transitive dependencies can lead to data
anomalies. We will be looking at how these dependencies can be dealt with to ensure
database normalization in the coming sections.
Different Types of Database Normalization
Database normalization comes in different forms, each with increasing levels of data
organization.
 Image by Author
First Normal Form (1NF)
This normalization level ensures that each column in your data contains only atomic
values. Atomic values in this context means that each entry in a column is indivisible.
It is like saying that each cell in a spreadsheet should hold just one piece of
information. 1NF ensures atomicity of data, with each column cell containing only a
single value and each column having unique names.
Second Normal Form (2NF)
Eliminates partial dependencies by ensuring that non-key attributes depend only on
the primary key. What this means, in essence, is that there should be a direct
relationship between each column and the primary key, and not between other
columns.
Third Normal Form (3NF)
Removes transitive dependencies by ensuring that non-key attributes depend only on
the primary key. This level of normalization builds on 2NF.
Boyce-Codd Normal Form (BCNF)
This is a more strict version of 3NF that addresses additional anomalies. At this
normalization level, every determinant is a candidate key.
Fourth Normal Form (4NF)
This is a normalization level that builds on BCNF by dealing with multi-valued
dependencies.
Fifth Normal Form (5NF)
5NF is the highest normalization level that addresses join dependencies. It is used in
specific scenarios to further minimize redundancy by breaking a table into smaller
tables.

Database Normalization With Real-World Examples

We have already highlighted all the data normalization levels. Let’s further explore
each of them in more depth with examples and explanations.
First Normal Form (1NF) Normalization
1NF ensures that each column cell contains only atomic values. Imagine a library
database with a table storing book information (title, author, genre, and borrowed_by).
If the table is not normalized, borrowed_by could contain a list of borrower names
separated by commas. This violates 1NF, as a single cell holds multiple values. The
table below is a good representation of a table that violates 1NF, as described earlier.

title author genre borrowed_by

John Doe, Jane Doe,

To Kill a Mockingbird Harper Lee Fiction
James Brown

J. R. R.
The Lord of the Rings Fantasy Emily Garcia, David Lee
Tolkien

Harry Potter and the J.K.

Fantasy Michael Chen
Sorcerer’s Stone Rowling

The solution?
In 1NF, we create a separate table for borrowers and link them to the book table.
These tables can either be linked using the foreign key in the borrower table or a
separate linking table. The foreign key in the borrowers table approach involves
adding a foreign key column to the borrowers table that references the primary key of
the books table. This will enforce a relationship between the tables, ensuring data
consistency.
You can find a representation of this below:
Books table

book_id title author genre

(PK)

1 To Kill a Mockingbird Harper Lee Fiction

J. R. R.
2 The Lord of the Rings Fantasy
Tolkien

Harry Potter and the

3 J.K. Rowling Fantasy
Sorcerer’s Stone

Borrowers table

borrower_id (PK) name book_id (FK)

1 John Doe 1

2 Jane Doe 1

3 James Brown 1

4 Emily Garcia 2

5 David Lee 2

6 Michael Chen 3

Second Normal Form (2NF)

This level of normalization, as already described, builds upon 1NF by ensuring there
are no partial dependencies on the primary key. In simpler terms, all non-key
attributes must depend on the entire primary key and not just part of it.
From the 1NF that was implemented, we already have two separate tables (you can
check the 1NF section).
Now, let’s say we want to link these tables to record borrowings. The initial approach
might be to simply add a borrower_id column to the books table, as shown below:

book_id borrower_id
title author genre
(PK) (FK)

To Kill a Harper
1 Fiction 1
Mockingbird Lee
 The Lord of the J. R. R.
2 Fantasy NULL
Rings Tolkien

Harry Potter and

J.K.
3 the Sorcerer’s Fantasy 6
Rowling
Stone

This might look like a solution, but it violates 2NF simply because the borrower_id
only partially depends on the book_id. A book can have multiple borrowers, but a
single borrower_id can only be linked to one book in this structure. This creates a
partial dependency.
The solution?
We need to achieve the many-to-many relationship between books and borrowers to
achieve 2NF. This can be done by introducing a separate table:
Book_borrowings table

borrowing_id book_id borrower_id

borrowed_date
(PK) (FK) (FK)

1 1 1 2024-05-04

2 2 4 2024-05-04

3 3 6 2024-05-04
This table establishes a clear relationship between books and borrowers. The book_id
and borrower_id act as foreign keys, referencing the primary keys in their respective
tables. This approach ensures that borrower_id depends on the entire primary key
(book_id) of the books table, complying with 2NF.
Third Normal Form (3NF)
3NF builds on 2NF by eliminating transitive dependencies. A transitive dependency
occurs when a non-key attribute depends on another non-key attribute, which in turn
depends on the primary key. It basically takes its meaning from the transitive law.
From the 2NF we already implemented, there are three tables in our library database:
Books table

book_id
title author genre
(PK)

1 To Kill a Mockingbird Harper Lee Fiction

J. R. R.
2 The Lord of the Rings Fantasy
Tolkien
 Harry Potter and the
3 J.K. Rowling Fantasy
Sorcerer’s Stone

Borrowers table

borrower_id (PK) name book_id (FK)

1 John Doe 1

2 Jane Doe 1

3 James Brown 1

4 Emily Garcia 2

5 David Lee 2

6 Michael Chen 3

Book_borrowings table

borrowing_id book_id borrower_id

borrowed_date
(PK) (FK) (FK)

1 1 1 2024-05-04

2 2 4 2024-05-04

3 3 6 2024-05-04

The 2NF structure looks efficient, but there might be a hidden dependency. Imagine
we add a due_date column to the books table. This might seem logical at first sight,
but it’s going to create a transitive dependency where:
 The due_date column depends on the borrowing_id (a non-key attribute) from the
book_borrowings table.
 The borrowing_id in turn depends on book_id (the primary key) of the books
table.
The implication of this is that due_date relies on an intermediate non-key attribute
(borrowing_id) instead of directly depending on the primary key (book_id). This
violates 3NF.
The solution?
We can move the due_date column to the most appropriate table by updating the
book_borrowings table to include the due_date and returned_date columns.
Below is the updated table:

borrowing_id book_id borrower_id

borrowed_date due_date
(PK) (FK) (FK)

2024-05-
1 1 1 2024-05-04
20

2024-05-
2 2 4 2024-05-04
18

2024-05-
3 3 6 2024-05-04
10

By placing the due_date column in the book_borrowing table, we have successfully

eliminated the transitive dependency.
What this means is that due_date now directly depends on the combined relationship
between book_id and borrower_id. In this context, book_id and borrower_id are
acting as a composite foreign key, which together form the primary key of the
book_borrowings table.
Boyce-Codd Normal Form (BCNF)
BCNF is based on functional dependencies that consider all candidate keys in a
relationship.
Functional dependencies (FD) define relationships between attributes within a
relational database. An FD states that the value of one column determines the value of
another related column. FDs are very important because they guide the process of
normalization by identifying dependencies and ensuring data is appropriately
distributed across tables.
BCNF is a stricter version of 3NF. It ensures that every determinant (a set of attributes
that uniquely identify a row) in a table is a candidate key (a minimal set of attributes
that uniquely identify a row). The whole essence of this is that all determinants should
be able to serve as primary keys.
It ensures that every functional dependency (FD) has a superkey as its determinant. In
other words, if X —> Y (X determines Y) holds, X must be a candidate key (superkey)
of the relation. Please note that X and Y are columns in a data table.
As a build-up from the 3NF, we have three tables:
Books table

book_id
title author genre
(PK)
1 To Kill a Mockingbird Harper Lee Fiction

J. R. R.
2 The Lord of the Rings Fantasy
Tolkien

Harry Potter and the

3 J.K. Rowling Fantasy
Sorcerer’s Stone

Borrowers table

borrower_id (PK) name book_id (FK)

1 John Doe 1

2 Jane Doe 1

3 James Brown 1

4 Emily Garcia 2

5 David Lee 2

6 Michael Chen 3

Book_borrowings table

borrowing_id book_id borrower_id

borrowed_date due_date
(PK) (FK) (FK)

2024-05-
1 1 1 2024-05-04
20

2024-05-
2 2 4 2024-05-04
18

2024-05-
3 3 6 2024-05-04
10

While the 3NF structure is good, there might be a hidden determinant in the
book_borrowings table. Assuming one borrower cannot borrow the same book twice
simultaneously, the combination of book_id and borrower_id together uniquely
identifies a borrowing record.
 This structure violates BCNF since the combined set (book_id and borrower_id) is not
the primary key of the table (which is just borrowing_id).
The solution?
To achieve BCNF, we can either decompose the book_borrowings table into two
separate tables or make the combined attribute set the primary key.
Approach 1 (decompose the table): In this approach, we will be decomposing the
book_borrowings table into separate tables:
A table with borrowing_id as the primary key, borrowed_date, due_date, and
returned_date.
Another separate table to link books and borrowers, with book_id as a foreign key,
borrower_id as a foreign key, and potentially additional attributes specific to the
borrowing event.
Approach 2 (make the combined attribute set the primary key): We can consider making
book_id and borrower_id a composite primary key for uniquely identifying borrowing
records. The problem with this approach is that it won’t serve its purpose if a borrower
can borrow the same book multiple times.
In the end, your choice between these options depends on your specific data needs and
how you want to model borrowing relationships.
Fourth Normal Form (4NF)
4NF deals with multi-valued dependencies. A multi-valued dependency exists when
one attribute can have multiple dependent attributes, and these dependent attributes
are independent of the primary key. It’s quite complex, but we will be exploring it
deeper using an example.
The library example we’ve been using throughout these explanations is not applicable
at this normalization level. 4NF typically applies to situations where a single attribute
might have multiple dependent attributes that don’t directly relate to the primary key.
Let’s use another scenario. Imagine a database that stores information about
publications. We will be considering a “Publications” table with columns, title, author,
publication_year, and keywords.

publication_id
title author publication_year keywords
(PK)

To Kill a Harper Coming-of-

1 1960
Mockingbird Lee Age, Legal

Fantasy,
The Lord of J. R. R.
2 1954 Epic,
the Rings Tolkien
Adventure

Pride and Jane Romance,

3 1813
Prejudice Austen Social
 Commentary

The table structure above is violating 4NF because:

 The keywords column has a multi-valued dependency on the primary key
publication_id. What this means is that a publication can have multiple keywords, and
these keywords are independent of the publication’s unique identifier.
The solution?
We can create a separate table.
Publication_keywords table

publication_id (FK) keyword

1 Coming-of-Age

1 Legal

2 Fantasy

2 Epic

2 Adventure

3 Romance

3 Social Commentary

The newly created table (Publication_keywords) establishes a many-to-many

relationship between publication and keywords. Each publication can have multiple
keywords linked through the publication_id, which is a foreign key, and each
keyword can be associated with multiple publications.
With this, we have successfully eliminated the multi-valued dependency and achieved
4NF.
Fifth Normal Form (5NF)
5NF is the most complex form of normalization that eliminates join dependencies.
This is a situation where data needs to be joined from multiple tables to answer a
specific query, even when those tables are already in 4NF.
In simpler terms, 5NF ensures that no additional information can be derived by
joining the tables together that wasn’t already available in the separate tables.
Join dependencies are less likely to occur when tables are already normalized (in 3NF
or 4NF), hence the difficulty in creating a clear and straightforward example for 5NF.
However, let’s take a look at this scenario where 5NF might be relevant:
Imagine a university database with normalized tables for “Courses” and “Enrollments.”
Courses table

course_id
course_name department
(PK)

Computer
101 Introduction to Programming
Science

Data Structures and Computer

202
Algorithms Science

Computer
301 Web Development I
Science

Computer
401 Artificial Intelligence
Science

Enrollments table

enrollment_id (PK) student_id (FK) course_id (FK) grade

1 12345 101 A

2 12345 202 B

3 56789 301 A-

4 56789 401 B+

Assuming these tables are already in 3NF or 4NF, a join dependency might exist
depending on how data is stored. For instance, a course has a prerequisite requirement
stored within the “Courses” table as the “prerequisite_course_id” column.
This might seem efficient at first glance. However, consider a query that needs to
retrieve a student’s enrolled courses and their respective prerequisites. In this scenario,
you would need to join the “Courses” and “Enrollments” tables, then potentially join
the “Courses” table to retrieve prerequisite information.
The Solution?
 To potentially eliminate the join dependency and achieve 5NF, we could introduce a
separate “Course Prerequisites” table:
Course_prerequisite table

course_id (FK) prerequisite_course_id (FK)

202 101

301 NULL

401 202

This approach separates prerequisite information and allows efficient retrieval of

enrolled courses and their prerequisites in a single join between the “Enrollments” and
“Course_prerequisites” tables.
Note: We are assuming a student can only have one prerequisite per course.
5NF is a very complex and rare type of normalization, so as someone just starting
their learning journey in data, you might not find an application.

Difference between Lossless and Lossy Join Decomposition

The process of breaking up a relation into smaller sub-relations is called
Decomposition. Decomposition is required in DBMS to convert a relation into a
specific normal form which further reduces redundancy, anomalies, and
inconsistency in the relation.
There are mainly two types of decomposition in DBMS
1. Lossless join Decomposition
2. Lossy join Decomposition

Lossless Join Decomposition

Lossy join Decomposition is a process in which a relation is decomposed into
smaller relations without losing any information. When we rejoin the decomposed
relations, the original relation is perfectly reconstructed without losing data.

Advantages of Lossless Join Decomposition

 Data Integrity: On decomposed tables no loss of any data or information when

re-join them together, it becomes the original table before decomposition.
 Consistency: This decomposition ensures that data will remain accurate and
consistent across the database.
 Normalization: This helps in achieving higher normal forms
like 3NF or BCNF and improving efficiency.

Disadvantage of Lossless Join Decomposition

 Storage Overhead: Storage usage is increased, as sometimes additional

tables and columns are needed.
 Complex Queries: To rejoin the table we decomposed may require
complex SQL queries, and these queries may impact the performance.
Lossy Join Decomposition
In this type of Decomposition the information will be lost if the relations are
decomposed into smaller parts. This means that when the original relation is
decomposed and then later we try to rejoin them back together then some data from
the original relation is not lost and not recoverable, which leads to data
inconsistencies.

Advantages of Lossy Join Decomposition

 Structure is Simple, the result of decomposing the relations will give simple
and smaller sub tables and this helps in reducing the complexity in some cases.
 Redundancy is Less: In some cases where loss of information is acceptable
will help in reducing redundancy in certain cases.

Disadvantage of Lossy Join Decomposition

 Loss of Data: When tables are joined back together then some of the
information will be loosed permanently which can cause problem.
 Inconsistency: as discussed above, due to information loss the data integrity
problem will arise.
 Hard to manage: It can be difficult to maintain data consistency as some
information may loss, which is making harder to manage the database.

Lossless Join and Dependency Preserving Decomposition

Dependency Preserving Decomposition

If we decompose a relation R into relations R1 and R2, All dependencies of R either
must be a part of R1 or R2 or must be derivable from a combination of functional
dependency of R1 and R2.
For Example, A relation R (A, B, C, D) with FD set{A->BC} is decomposed into
R1(ABC) and R2(AD) which is dependency preserving because FD A->BC is a part
of R1(ABC).
Advantages of Lossless Join and Dependency Preserving Decomposition
 Improved Data Integrity: Lossless join and dependency preserving
decomposition help to maintain the data integrity of the original relation by
ensuring that all dependencies are preserved.
 Reduced Data Redundancy: These techniques help to reduce data
redundancy by breaking down a relation into smaller, more manageable
relations.
 Improved Query Performance: By breaking down a relation into smaller,
more focused relations, query performance can be improved.
 Easier Maintenance and Updates: The smaller, more focused relations are
easier to maintain and update than the original relation, making it easier to
modify the database schema and update the data.
 Better Flexibility: Lossless join and dependency preserving decomposition can
improve the flexibility of the database system by allowing for easier
modification of the schema.
Disadvantages of Lossless Join and Dependency Preserving Decomposition
Increased Complexity: Lossless join and dependency-preserving decomposition
can increase the complexity of the database system, making it harder to understand
and manage.
Costly: Decomposing relations can be costly, especially if the database is large and
complex. This can require additional resources, such as hardware and personnel.
Reduced Performance: Although query performance can be improved in some
cases, in others, lossless join and dependency-preserving decomposition can result
in reduced query performance due to the need for additional join operations.
Limited Scalability: These techniques may not scale well in larger databases, as the
number of smaller, focused relations can become unwieldy.