Introduction
Armstrong's Axioms are a set of logical rules in Database Management Systems (DBMS) used to decide all possible functional dependencies from a given set.
A functional dependency exists when one attribute in a dataset uniquely determines another attribute. It helps ensure the integrity and quality of data. These rules ensure that data relationships within a database remain consistent and meaningful.
For example, think of a database as a map, where cities are connected by roads. Armstrong's Axioms help you identify all possible routes (functional dependencies) between cities using a given set of connections.
What Are Armstrong's Axioms and Their Purpose?
The axioms, introduced by William W. Armstrong, are:
Primary axioms
These are the core rules in Armstrong's axioms that define how functional dependencies work. They are the foundation for reasoning about dependencies in a database.
1. Reflexivity Rule: Certain facts are self-evident, or in simpler words, obvious.
2. Augmentation Rule: Adding extra context doesn’t change the truth, which says that a longer explanation will not change the fact.
3. Transitivity Rule: Relationships can extend through intermediate steps. This refers to how relationships often have many steps in between and don't necessarily have a direct connection or link with each other.
Secondary axioms
These are additional rules derived from the primary axioms, and they help in combining or breaking down functional dependencies.
- Union Rule: If you can do two separate things individually, you can also do them together.
- Decomposition Rule: If you can handle two things together, you can also handle them separately.
- Pseudo Transitivity Rule: Sometimes, you can connect the dots through an extra link.
- Self-Determination: You always know something about yourself.
- Extensivity: Adding more information to a relationship doesn’t change the fact that the original relationship holds true.
- Composition Rule: If two relationships can be combined, then the combined pieces will give you a new relationship.
Purpose:
- Deriving Functional Dependencies: They derive additional dependencies to enhance understanding of relationships.
- Data Normalization: Axioms are essential for organizing data by eliminating or removing discontinuities.
- Ensuring Consistency: They ensure that all derived relationships are logically similar to the original ones.
Types of Armstrong's Axioms
1. Reflexivity Rule:
If Y is part of X, then X → Y.
Example: If you own a car, you automatically own the tires that come with it.
2. Augmentation Rule:
If X → Y, then XZ → YZ.
Example: If you can unlock a door with one key, you can still unlock it if you hold a second, unrelated key in the same hand.
3. Transitivity Rule:
If X → Y and Y → Z, then X → Z.
Example: If A trusts B and B trusts C, A indirectly trusts C.
These rules provide a small but complete foundation to understand and manipulate data relationships.
Secondary Rules of Armstrong's Axioms
Derived from the primary axioms, these rules simplify dependency understanding:
1. Union Rule:
If X → Y and X → Z, then X → YZ.
Example: If you can send individual emails to two friends, you can also send a group email to both.
2. Composition Rule:
If X→Y and Z→W, then XZ→YW.
Example: If a person determines their phone number, and a phone number determines their address, then a person combined with a phone number determines both the phone number and the address.
3. Decomposition Rule:
If X → YZ, then X → Y and X → Z.
Example: If you carry groceries for two people together, you can also carry them one at a time.
4. Pseudo Transitivity Rule:
If X → Y and WY → Z, then XW → Z.
Example: If your phone knows a number that dials a service, and the service leads to help, your phone indirectly connects you to help.
5. Self determination Rule:
Every set of attributes functionally determines itself.
Example: If you know your name, you always know it yourself. It’s self-evident that any set of attributes will always determine itself.
6. Extensivity Rule:
Adding extra attributes to both sides of a functional dependency doesn’t change the dependency.
Example: If knowing a person's name tells you their phone number, adding their address to that doesn’t change the fact that knowing their name still gives you their phone number.
How to Use These Axioms
Armstrong's axioms help in deriving new functional dependencies, checking the correctness of dependencies, finding keys, and simplifying database schemes. Here, we’ll go through each axiom with a real-world example to see how they work in practice.
Examples of using Armstrong Axioms
1. Example of reflexivity rule and how to use it
This rule is mainly used to simplify functional dependencies by recognizing dependencies which are not that important.
A part of a whole is always contained within the whole. If you own a car, then you obviously own its steering wheel. If a library owns a book, then it also owns the pages of the book.
Consider a university database with attributes:
StudentID, Name, Address
Since a set always determines its subset, we can say:
- {StudentID,Name}→{StudentID}
- {StudentID,Name,Address}→{Name,Address}
2. Example of augmentation rule and how to use it
This rule helps in adding extra details without changing the core truth. It is useful in decision-making, agreements, and logical reasoning.
Adding more details to an already valid statement doesn’t make it false. If you are invited to a party, and you bring a friend, that doesn't change the fact that you were invited. If a person knows how to drive, then knowing multiple routes doesn’t affect their ability to drive.
Given: StudentID→Name
We can augment both sides by adding AddressAddressAddress:
- {StudentID,Address}→{Name,Address}
3. Example of transitivity rule and how to use it
Transitivity is used to simplify dependencies and derive new relationships that are not explicitly given.
If A causes B and B causes C, then A causes C.
If studying hard leads to good grades, and good grades lead to a good job, then studying hard leads to a good job.
Given:
- StudentID→Name
- Name→Address
By transitivity, we can conclude:
StudentID→Address
Why Are Armstrong's Axioms Sound and Complete?
1. Sound:
Every dependency derived using Armstrong’s Axioms is valid for the given data.
Example: If X → Y is derived, then Y will always depend on X, for the given data.
2. Complete:
These axioms are capable of deriving every possible dependency which is logically understood or given by the data set.
Example: If any hidden relationship exists, the axioms ensure it is revealed and understood.
Together, soundness and completeness guarantee that these axioms are reliable and enough for understanding data relationships.
Functional Dependencies
A functional dependency refers to a relationship described between two attributes in a database. It describes how one attribute is related to, and determines another attribute. The functional dependency is represented by an arrow as shown below. The arrow from X to Y signifies that the value of Y depends on the value of X. For two entries having the same value of X, the value of Y will also be the same. Here X is called the determinant.
Functional dependencies help in ensuring data consistency, finding candidate keys and normalization.
Types of functional dependencies
1. Fully functional dependency
A functional dependency is fully functional only if the determinant is a primary key or super key. If we remove even one attribute from the determinant X, the dependent Y will no longer be dependent on X.
If two keys are needed to open a lock, removing one key means the lock won’t open.
Example:
{StudentID, CourseID} → Grade : Grade is fully dependent on studentID and CourseID because both are needed.
But StudentID → Grade : This is wrong because a student takes multiple courses, so without determining the course we cannot determine the grade.
2. Partial functional dependency
A functional dependency is partial if the dependent attribute can still be determined even if one of the attributes is removed from the left side of the dependency, that is, the determinants. We can say that dependent Y is also dependent on a subset of determinant X.
If you have two ingredients to make a dish but removing one still lets you make it, then one ingredient is not necessary.
Example:
{StudentID, CourseID} → Grade : Grade is fully dependent on studentID and CourseID because both are needed.
But CourseID → CourseName : This is partial because a course name is only dependent on the CourseID, and not the entire key including both courseID and studentID.
A partial dependency cannot exist if the primary key has only one attribute, or if the database consists of only two attributes, or if all the attributes in the database are part of the primary key.
3. Transitive functional dependency
If a dependent attribute can derive yet another dependent attribute, then the determinant of the first dependent attribute can also derive the second dependent attribute. If A knows B, and B knows C, then A indirectly knows C.
Example:
StudentID → Name
Name → Address
Therefore, StudentID → Address (By Transitivity)
4. Trivial functional dependency
A trivial functional dependency refers to the reflexivity rule. If Y is a subset of X (X is a set of attributes), then Y is dependent on X automatically.
If you own a set of keys, then you obviously own any one of those keys individually.
Example:
{StudentID, Name} → Name (Trivial because Name is part of the left-hand side)
5. Multi valued dependency
If there are different attributes, and one attribute can determine a set of values for two or more different attributes individually each, it is called a multi-valued dependency. If you have one phone number but use multiple SIM cards, your phone number determines multiple independent SIMs.
Example:
Consider a university where a student can enroll in multiple courses and have multiple hobbies.
StudentID → CourseID
StudentID → Hobby
Advantages and Disadvantages of Armstrong's Axioms
While Armstrong's Axioms provide valuable insights for effective data management, they come with their own set of pros and cons that every database designer should consider. Let's dive into these advantages and disadvantages to better understand their impact.
Advantages:
1. Clear Framework: The axioms provide a systematic way to deduce all functional dependencies.
2. Foundation for Normalization: they are essential for designing well-structured and efficient databases.
3. Enhances Data Integrity: Armstrong’s Axioms ensure that deduced dependencies are in coordination with real-world logic.
4. Reduces Redundancy: They help to eliminate duplicate or unnecessary data relationships which can complicate the understanding of given data.
Disadvantages:
1. Complex for Beginners: The theoretical nature of axioms can be overwhelming if you are a beginner, but gradual use enhances their understanding.
2. Time-Consuming for Large Databases: Deriving dependencies manually is impractical for vast datasets, as it would take very large periods of time.
3. Heavy Reliance on Manual Application: Automation for deriving dependencies in large datasets often requires additional tools or algorithms.
Conclusion
Armstrong's Axioms are a very useful tool of database management, offering a logical blueprint to understand and manage functional dependencies. They may seem theoretical and complex, but their importance in maintaining data consistency, simplifying relationships, and enabling normalization cannot be underestimated. By mastering these axioms, you gain the ability to build reliable and efficient databases, much like a skilled architect who understands the principles of design.
Frequently Asked Questions
1. What is an Axiom Armstrong?
Armstrong's Axioms are a set of rules used to derive all possible functional dependencies in a Database Management System (DBMS), ensuring data consistency and normalisation.
2. What is FD in DBMS?
FD (Functional Dependency) in DBMS is a relationship between two attributes where one attribute uniquely determines another in a database table.
3. What is FD and its types in DBMS?
FD (Functional Dependency) describes relationships between attributes in a table. Types include:
- Fully Functional Dependency: Determinant is a primary key.
- Partial Functional Dependency: A subset of the determinant determines the dependent attribute.
- Transitive Functional Dependency: A chain of dependencies between attributes.
- Trivial Functional Dependency: Dependent attribute is a subset of the determinant.
4. What is Normalisation in DBMS?
Normalisation in DBMS is the process of organising database tables to reduce redundancy and dependency, improving data integrity and efficiency.
5. What is a Database in DBMS?
A database in DBMS is an organised collection of data that is stored, managed, and accessed electronically, typically in tables or other structures.
