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.
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. It's like building a Lego house, where each piece symbolizes a unit of information. The way these pieces connect forms a coherent structure. Armstrong's Axioms guide how to link data effectively, ensuring a strong and logical foundation.
The axioms, introduced by William W. Armstrong, consist of primary and secondary rules that define how functional dependencies work in databases.
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.
These are additional rules derived from the primary axioms, and they help in combining or breaking down functional dependencies.
If Y is part of X, then X → Y.
Example: If you own a car, you automatically own the tires that come with it.
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.
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.
Derived from the primary axioms, these rules simplify dependency understanding:
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.
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.
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.
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.
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.
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.
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.
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.
University Database Example:
Consider a university database with attributes: StudentID, Name, Address
Since a set always determines its subset, we can say:
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 Address:
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:
By transitivity, we can conclude:
StudentID → Address
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.
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.
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 (X → Y). 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.
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:
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:
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.
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:
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:
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.
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.
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.
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.
FD (Functional Dependency) in DBMS is a relationship between two attributes where one attribute uniquely determines another in a database table.
FD (Functional Dependency) describes relationships between attributes in a table. Types include:
Normalisation in DBMS is the process of organising database tables to reduce redundancy and dependency, improving data integrity and efficiency.
A database in DBMS is an organised collection of data that is stored, managed, and accessed electronically, typically in tables or other structures.