If A-> B and D is a set of attributes, then AD >BD holds. This is a
rule
Answers
Answer:
A functional dependency (FD) is a relationship between two attributes, typically between the PK and other non-key attributes within a table. For any relation R, attribute Y is functionally dependent on attribute X (usually the PK), if for every valid instance of X, that value of X uniquely determines the value of Y. This relationship is indicated by the representation below :
X ———–> Y
The left side of the above FD diagram is called the determinant, and the right side is the dependent. Here are a few examples.
In the first example, below, SIN determines Name, Address and Birthdate. Given SIN, we can determine any of the other attributes within the table.
SIN ———-> Name, Address, Birthdate
For the second example, SIN and Course determine the date completed (DateCompleted). This must also work for a composite PK.
SIN, Course ———> DateCompleted
The third example indicates that ISBN determines Title.
ISBN ———–> Title
Rules of Functional Dependencies
Consider the following table of data r(R) of the relation schema R(ABCDE) shown in Table 11.1.
Table-R-Functional-Dependency-example
Table 11.1. Functional dependency example, by A. Watt.
As you look at this table, ask yourself: What kind of dependencies can we observe among the attributes in Table R? Since the values of A are unique (a1, a2, a3, etc.), it follows from the FD definition that:
A → B, A → C, A → D, A → E
It also follows that A →BC (or any other subset of ABCDE).
This can be summarized as A →BCDE.
From our understanding of primary keys, A is a primary key.
Since the values of E are always the same (all e1), it follows that:
A → E, B → E, C → E, D → E
However, we cannot generally summarize the above with ABCD → E because, in general, A → E, B → E, AB → E.
Other observations:
Combinations of BC are unique, therefore BC → ADE.
Combinations of BD are unique, therefore BD → ACE.
If C values match, so do D values.
Therefore, C → D
However, D values don’t determine C values
So C does not determine D, and D does not determine C.
Looking at actual data can help clarify which attributes are dependent and which are determinants.
Inference Rules
Armstrong’s axioms are a set of inference rules used to infer all the functional dependencies on a relational database. They were developed by William W. Armstrong. The following describes what will be used, in terms of notation, to explain these axioms.
Let R(U) be a relation scheme over the set of attributes U. We will use the letters X, Y, Z to represent any subset of and, for short, the union of two sets of attributes, instead of the usual X U Y.
Axiom of reflexivity
This axiom says, if Y is a subset of X, then X determines Y (see Figure 11.1).
Ch-11-Axion-Reflexivity
Figure 11.1. Equation for axiom of reflexivity.
For example, PartNo —> NT123 where X (PartNo) is composed of more than one piece of information; i.e., Y (NT) and partID (123).
Axiom of augmentation
The axiom of augmentation, also known as a partial dependency, says if X determines Y, then XZ determines YZ for any Z (see Figure 11.2 ).
Ch-11-Axiom-of-Augmentation-300x34
Figure 11.2. Equation for axiom of augmentation.
The axiom of augmentation says that every non-key attribute must be fully dependent on the PK. In the example shown below, StudentName, Address, City, Prov, and PC (postal code) are only dependent on the StudentNo, not on the StudentNo and Grade.
StudentNo, Course —> StudentName, Address, City, Prov, PC, Grade, DateCompleted
This situation is not desirable because every non-key attribute has to be fully dependent on the PK. In this situation, student information is only partially dependent on the PK (StudentNo).
Explanation:
mark me as BRAINLIEST