02FunctionalDependencies

Functional dependencies

Outline

Functional dependency ? What is it ?
Functional dependencies versus classes of objects
Functional dependencies versus associations
Derivations of functional dependencies
Armstrong axioms
Other inference rules
Using inference rules

What is a data dependency ?

Data dependency is a constraint/condition imposed on the contents of a database and always valid in every permanent state of a database.

Data dependency is a reflection of the real world constraint in the contents of a database. For example, in the reality it is always true that age of a person is a positive number. It is impossible to have a negative age, well, maybe it is because we cannot travel back in time. A reflection of such real world constraint on the contents of a database is a condition enforced on the contents of a column "age" in a relational table and says that "age" > 0.

What is a functional dependency ?

A functional dependency is a special kind of data dependency saying that each value in a column or a tuple of values in the columns can be associated with only one value in another column or a tuple of values in another columns.

A functional dependency is called "functional" because it is a function that maps the values in a column or a tuple of values in the columns into one value in another column or a tuple of values in another columns.

Consider Let be a relational schema (a header of relational table) R that consists of n columns (attributes) ( A1, ..., An). Assume that X, Y are the nonempty subsets of as schema R, for example X = {A1,A3} and Y = {A5}

We say that a functional dependency X → Y (X functionally determines Y) is valid in a relational schema R if for any contents of a relational table R, it is not possible that R has two rows that agree in the components for all attributes in a set X yet disagree on one or more component for the attributes in a set Y. For example if {A1,A3} → {A5} then it means that every pair of values of attributes A1, A3 is associated in. any state of a relational table R, with only one values of an attribute A5.

For example, if a warehouse is located at one address then warehouse → address (warehouse functionally determines address) and it means that every value in a column warehouse is associated with only one value in a column address.

For example, if at each address there is only one warehouse then address → warehouse (address functionally determines warehouse) and it means that every value in a column address is associated with only one value in a column warehouse.

For example, if at each warehouse the parts of the same sort have only one total quantity then warehouse,part → quantity ( a pair of attributes warehouse, part functionally determine an attribute quantity)and it means that every pair of values in the columns warehouse and part is associated with only one value in a column quantity.

For example, if a car has one owner then registration → driving license (a registration number functionally determines driving license of its owner) and it means that each value in a column registration is associated with one value in a column driving license.

For example, if a students has one first name and one last name and one date of birth then student-number → first-name, last-name-date-of-birth (a student number functionally determines first name, last name and date of birth) and it means that each value in a column student number is associated with one value in a column first name, one value in a column last name and one value in a column date of birth).

Functional dependency ? What is it ?

Let R = ( A₁, ..., A_n) be a relational schema (a header of relational table) and let X, Y be the nonempty subsets of R
We say that a functional dependency X → Y is valid in a relational schema R if
for any contents of a relational table R, it is not possible that R has two rows that agree in the components for all attributes in a set X yet
disagree on one or more component for the attributes in a set Y
Examples
- A warehouse is located at exactly one address: warehouse → address
- An address is related to exactly one warehouse: address → warehouse
- At a warehouse, the parts of the same sort have only one total quantity:
  warehouse,part → quantity
- A car has one owner: registration → driving license
- A student has one first name and one last name and one date of birth:
  student-number → first-name, last-name-date-of-birth

More examples:

A fact that each employee belongs to one department is represented by a functional dependency: employee-number → department-name.

A fact that each manager manages one department is represented by a functional dependency: manager-number → department-name

A fact that each employee has one manager is represented by a functional dependency: employee-number → manager-number

A fact that each student enrols a subject only one time is represented by a functional dependency: student-number,subject-code → enrolment-date

A fact that each employee is located in one building in one office is represented by a functional dependency: employee-number → building-number, office-number

A fact that each office in a building hosts one employee is represented by a functional dependency: building-number, office-number → employee-number

A fact that each office in a building at a campus hosts one employee is represented by a functional dependency: campus-name,building-number, office-number → employee-number

A fact that each department has one manager is represented by a functional dependency: department-name → manager-number

A fact that each department is located in one building is represented by a functional dependency: department-name → building-number

A fact that each department has one manager and it is located in one building is represented by a functional dependency: department-name → manager-number,building-number

Functional dependency ? What is it ?

More examples
- An employee belongs to one department:
  employee-number → department-name
- A manager manages one department: manager-number → department-name
- An employee has one manager: employee-number → manager-number
- A student enrols a subject one time:
  student-number,subject-code → enrolment-date
- An employee is located in one building in one office:
  employee-number → building-number, office-number
- An office in a building hosts one employee:
  building-number, office-number → employee-number
- An office in a building at a campus hosts one employee:
  campus-name,building-number, office-number → employee-number
- A department has one manager: department-name → manager-number
- A department is located in one building: department-name → building-number
- A department has one manager and it is located in one building:
  department-name → manager-number,building-number

An interesting question is how to discover the functional dependencies in a relational table ?

What can first ask a question if it is possible to discover the functional dependencies in a relational schema (a header of relational table) R(A, B, C, D, E) where a schema name and the attributes are single letters ? Of course it is impossible to do it because we do not know the semantics (the meanings) of the names: R, A, B, C, D, E. In the other words we do not have good arguments to claim that for example A → B.

It means that to discover the functional dependencies in a relational table we must use the semantics of a relational table name and the names of attributes.

For example, consider a relational schema (a header of relational table) TRIP(rego#, licence#, tdate) of a relational table that contains information about the trips made by the drivers (licence#) who used the trucks (rego#) on a given day (tdate).

To discover functional dependencies we may ask the following questions:

Is it true in a real world domain described by a relational schema TRIP that a truck be used only one time ? If yes then rego# → tdate, it means that registration number functionally determines trip date, well, it is not true because each truck can be used on many different days.

Is it true that a driver make only one trip ? If yes the licence# → tdate, it means that driving license number functionally determines trip date, well it is not true because each driver can perform many trips on different days).

Can a driver use more than one truck ? If yes then licence# → rego#, it means that driving license number functionally determines registration number, well, it is possible if each driver is assigned to only one truck

Can a truck be used by more than one driver ? If yes then rego# → licence#, it means that registration number functionally determines driving license number, well, it is possible that each truck is used by only one driver.

And so on, and so on, ...

Functional dependency ? What is it ?

How to discover the functional dependencies in a relational table ?
- Is it possible to discover the functional dependencies in a relational schema (a header of relational table) R(A, B, C, D, E) ?
- Of course it is impossible to do it because we do not know the semantics (the meanings) of the names: R, A, B, C, D, E
- To discover the functional dependencies in a relational table we must use the semantics of a relational table name and the names of attributes
- For example consider a relational schema (a header of relational table) TRIP(rego#, licence#, tdate) of a relational table that contains information about the trips made by the drivers (licence#) who used the trucks (rego#) on a given day (tdate)
- Can a truck be used only one time ? If yes then rego# → tdate
- Can a driver make only one trip ? If yes then licence# → tdate
- Can a driver use more than one truck ? If no then licence# → rego#
- Can a truck be used by more than one driver ? If no then rego# → licence#
- And so on ...

Functional dependencies

Outline

Functional dependency ? What is it ?
Functional dependencies versus classes of objects
Functional dependencies versus associations
Derivations of functional dependencies
Armstrong axioms
Other inference rules
Using inference rules

How functional dependencies are related to conceptual modeling ? Is is a different concept ? is it possible to discover the functional dependencies directly from the conceptual schemas ?

Yes, a concept of functional dependency is a different concept from a concept of conceptual schema. Functional dependencies provide information about data dependencies among the values of attributes. Conceptual schema groups the attributes within classes and does say anything about the association between values of the attributes within a class. However it is possible to almost automatically discover some of the functional dependencies from the identifiers of a class of objects.

For example, if an attribute student number is an identifier of a class STUDENT then it means that each student must have a different student number. Then it never happens that two or more students have the same student number and it means that student number when assigned to one student is associated with one first name, one last name, one date of birth and one average of grades. It means that student number functionally determines first name, last name, date of birth and average.

In the same way, if a triple of attributes (first name, last name, date of birth) is an identifier than such triple functionally determines student number and average.

Then, in a general case it is true that identifier functionally determines all other single valued attributes in a class of objects.

Of course these are not the only functional dependencies that can be valid among the attributes of a class of objects. For example, a class of objects ENROLMENT(s#,c#,title,edate) described by student number, course number, course title and enrolment date has an identifier(s#,c#,edate) and still c# → edate, (course number has one title and because of that course number functionally determines enrolment date).

Please also note that student number does not functionally determines language because language is a multivalued attribute, i.e. a student can speak more than one language.

Functional dependencies versus classes of objects

A class of objects STUDENT

Owns

validates (satisfies) the following functional dependencies:
s# → fname
s# → lname
s# → dob
s# → average
fname, lname, dob → s#
fname, lname, dob → average

A set of functional dependencies {s# → fname, s# → lname, s# → dob, s# → average} is equivalent to a functional dependency s# → fname, lname, dob, average.

It means that it is possible to logically derive from a set of functional dependencies {s# → fname, s# → lname, s# → dob, s# → average} a functional dependency s# → fname, lname, dob, average and from a functional dependency s# → fname, lname, dob, average it is possible to logically derive a set of functional dependencies {s# → fname, s# → lname, s# → dob, s# → average}

Indeed if a student has one first name one last name one date of birth and one average then such student must have one quadruple of values [first name, last name, date of birth and average] On the other hand, if a student has one quadruple of values [first name, last name, date of birth and average] then such student must have only one first name because more than first name would indicate more than one quadruple of values. The same applies to last name, date of birth an average.

In the future we shall formulate a set of rules that will allow us to logically derive new valid functional dependencies from the dependencies about which we know that are valid in a relational schema.

In the same way we can show that a set of functional dependencies {fname, lname, dob → s#, fname, lname, dob → average} is equivalent to a functional dependency fname, lname, dob → s#, average.

Functional dependencies versus classes of objects

The functional dependencies:
s# → fname
s# → lname
s# → dob
s# → average
are equivalent to a functional dependency
s# → fname, lname, dob, average
The functional dependencies
fname, lname, dob → s#
fname, lname, dob → average
are equivalent to a functional dependency
fname, lname, dob → s#, average

Functional dependencies

Outline

Functional dependency ? What is it ?
Functional dependencies versus classes of objects
Functional dependencies versus associations
Derivations of functional dependencies
Armstrong axioms
Other inference rules
Using inference rules

The classes of objects DEPARTMENT and CHAIRPERSON and association Has validate/satisfy the following functional dependencies:

name → budget, building#, total-employees

building# → name, budget, total-employees

c# → fname, lname

because the attributes name and building# are the identifiers in a class DEPARTMENT and an attribute c# is an identifier in a class CHAIRPERSON.

If an association DEPARTMENT has Chairperson is one-to-one then each department is associated with one chairperson and because of that each name of a department is associated with one chairperson number, first name and last name. Such conclusion contributes to a functional dependency name → c#, fname, lname.

In the same way we can logically derive a functional dependency building# → c#, fname, lname.

If each chair person is associated with one department then each each chairperson number is associated with one name of department, one building number, one budget and one total number of employees in a department. It means that c# → name, building#, budget, total-employees.

We can say that in a general case the single valued attributes on "one" of association are always functionally dependent on the identifier of a class on the other side of the same association.

Functional dependencies versus associations

The classes of objects DEPARTMENT and CHAIRPERSON and association Has

Owns

validate (satisfy) the following functional dependencies:
name → budget, building#, total-employees
building# → name, budget, total-employees
c# → fname, lname
name → c#, fname, lname
building# → c#, fname, lname
c# → name, building#, budget, total-employees

A rule saying that the single valued attributes on "one" of association are always functionally dependent on the identifier of a class on the other side of the same association applies to one-to-many association.

For example, consider many-to-one association EMPLOYEE Works-on PROJECT. The single valued attributes on one side of association Works-on: title, budget, deadline are functionally dependent on the identifiers (e#), (fname, lname, dob ).

Hence it is true that:

e# → title, budget, deadline

fname, lname, dob → title, budget, deadline

It is NOT TRUE that title → e#, fname, lname, dob, salary because the attributes e#, fname, lname, dob, salary describe a class on "many" side of association. It is consistent with the reality because a project may have many employees involved.

Functional dependencies versus associations

The classes of objects EMPLOYEE and PROJECT and association Works-on

Owns

validate (satisfy) the following functional dependencies:
e# → fname, lname, dob, salary
fname, lname, dob → e#, salary
title → budget, deadline
e# → title, budget, deadline
fname, lname, dob → title, budget, deadline

Functional dependencies versus associations

The classes of objects STUDENT and COURSE and association Enrols

Owns

validate (satisfy) the following functional dependencies:
s# → fname, lname
code → title, credits
title → code, credits
s#, code, edate → score
s#, title, edate → score

Functional dependencies

Outline

Functional dependency ? What is it ?
Functional dependencies versus classes of objects
Functional dependencies versus associations
Derivations of functional dependencies
Armstrong axioms
Other inference rules
Using inference rules

Few slides. ago we discovered a rule saying that if a set of functional dependencies has the same left-hand side then such set of functional dependencies is equivalent to a single functional dependency that has the same left-hand side an all other attributes on the right hand side. For example, if it is true that X → Y1 and X → Y2 and ... X → Yn then it is true that X → Y1,Y2,... Yn. The opposite is also true: if is true that X → Y1,Y2,... Y then it is true that X → Y1 and X → Y2 and ... X → Yn.

To discover more logical derivation rules for functional dependencies consider a relational schema:

EMPLOYEE(e#, ename, department, address, chairperson)

What we know up to now is such that if e# → ename and e# → department then e# → ename, department and the opposite, if e# → ename, department then e# → ename and e# → department.

A logical inference rule saying that if p implies q and q implies r then p implies r (Robinson's principle) can be applied to functional dependencies. It mean that if e# → department and department → address then e# → address.

Using the same rule we can say that if e# → department and department → chairperson then e# → chairperson.

Another simple rule is based on a principle saying that if f(x) is a function of a single variable then any extension over more variables is still a function. For example, if e# → department then e#, ename → department. It leads to a simple rule saying that we can add any attribute to a left-hand side of a valid functional dependency to get another valid functional dependency. For example if e#, ename → department then e#, ename, address → department.

Another interpretation of a rule saying that if X → Y1,Y2,... Y then it is true that X → Y1 and X → Y2 and ... X → Yn can be such that it is always possible to remove an attribute from the right-hand side of a valid functional dependency to get another functional dependency,

It leads to nice formulation of two "symmetrical" rules saying that we can add the attributes to left-hand side of a valid functional dependency and we can remove the attributes from the right-hand side of a valid functional dependency.

An interesting observation that it is always true that e# → e# leads to a concept of so called "trivial functional dependency". A functional dependency e# → e# is always true because if a student number is related to the same student number then such relationship must be on-to-one.

If we apply a derivation rule that allows to add attributes to a left-hand side of a functional dependency than we can find hat it is always true that e#, ename → e#. Every functional dependency X → Y such that Y is included or equal to X is always valid and it is called "trivial functional dependency"

Derivations of functional dependencies

Consider a relational schema (a header of relational table)
EMPLOYEE(e#, ename, department, address, chairperson)
If e# → ename and e# → department then e# → ename, department
If e# → department and department → address then e# → address
If e# → department and department → chairperson then
e# → chairperson
If e# → department then e#, ename → department
If e#, ename → department then e#, ename, address → department
It is always true that e# → e#
Functional dependency e# → e# is called as a trivial functional dependency
It is always true that e#, ename → e#
A functional dependency e#, ename → e# is also called as a trivial functional dependency

Derivations of functional dependencies

A trivial functional dependency is a functional dependency that is always true no matter what its left and right hand sides are
For example,
e# → e#,
department → department
e#, ename → e#,
e#, ename, department → e#, department,
and so on

Now, we summarise the derivation rules for functional dependencies discovered so far. Consider a relational schema R(A, B, C)

(1) Then it is always true that A → A and A, B → A and A, B, C → A (trivial functional dependencies)

(2) It is always true that if A → B then A, C → B (extension of left-hand side)

(3) It is always true that if A → B, C then A → B and A → C (contraction fo the right-hand side)

(4) It is always true that if A → B and B → C then A → C (transitivity)

It is interesting that such system of derivation rules is complete. It means that any functional dependency that it logically implied by a set of valid function dependencies can be derives using the four derivation rule listed above. Unfortunately such system of rules is not minimal. It is possible to find a system of three derivation rules that is complete.

Derivations of functional dependencies

Consider a relational schema R(A, B, C)
It is always true that A → A
It is always true that A, B → A
It is always true that A, B, C → A
If A → B then A, C → B
If A → B, C then A → B and A → C
If A → B and B → C then A → C

Functional dependencies

Outline

Functional dependency ? What is it ?
Functional dependencies versus classes of objects
Functional dependencies versus associations
Derivations of functional dependencies
Armstrong axioms
Other inference rules
Using inference rules

A minimal and complete system of derivation rules forfunctional dependencies invented by William W. Armtrong in 1974 consist of 3 rules only.

Consider Let be a relational schema (a header of relational table) R = (A1, ..., An) where R is a name of the schema and A1, ..., An are the names of attributes (columns in a relational table). Let X, Y, Z be the nonempty subsets of {A1, ..., An}.

Then the following 3 rules form a minimal and complete set of derivation rule (axioms) for functional dependencies.

(i) If Y ⊆ X then X → Y (reflexivity axiom)

The first rule can be used to create trivial functional dependencies for any sets of attributes, It says that a set of attributes Y is included or if it is equal to a set of attributes X then X functionally determines Y, X → Y . The first rule is called "reflexivity axiom".

ii) If X → Y then X, Z → Y, Z (augmentation axiom)

The second rule allows for the derivations of the new and valid functional dependencies from the given and valid functional dependencies. A derivation is performed through addition of the same set of attributes Z to both sides of a given functional dependency. The second rule is commonly known as "augmentation axiom".

(iii) If X → Y and Y → Z then X → Z (transitivity axiom)

The third rule, allows for the derivations of the new and valid functional dependencies from two given and valid functional dependencies such that the right-hand side of the first functional dependency is the same as the left-hand size of the second functional dependency. The third rule is call "transitivity axiom".

The axioms (i),(ii), and (iii) form a minimal and complete set of derivation rules for functional dependencies. A set of rules is minimal because it is impossible remove any of the axioms such that a smaller set of rules obtained after elimination of an axiom is enough to derive all functional dependencies that can be logically inferred from a given set of functional dependencies.

The axions form a complete set because it possible with the given set of axioms to derive all functional dependencies that can be logical inferred from a given set of functional dependencies.

Armstrong axioms

Let R = (A₁, ..., A_n) be a relational schema (a header of relational table) and
let X, Y, Z be the nonempty subsets of {A₁, ..., A_n}
(i) If Y ⊆ X then X → Y (reflexivity axiom)
(ii) If X → Y then X, Z → Y, Z (augmentation axiom)
(iii) If X → Y and Y → Z then X → Z (transitivity axiom)
The axioms (i),(ii), and (iii) form a minimal and complete set of axioms

Functional dependencies

Outline

Functional dependency ? What is it ?
Functional dependencies versus classes of objects
Functional dependencies versus associations
Derivations of functional dependencies
Armstrong axioms
Other inference rules
Using inference rules

It is possible to create from the Armstrong axioms other derivation rules that can be used to create new and valid functional dependencies from a given set of valid functional dependencies.

Let like before R = (A1, ..., An) be a relational schema and let X, Y, Z be the nonempty subsets of {A1, ..., An}.

Then, if X → Y and X → Z then X → Y, Z

It is so called "union rule" saying that if left-hand side of two or more functional dependencies is the same then we can create a new functional dependecy with the same left-hand side and right-hand side being union of right-hand side of functional depndencies involved.

If X → Y and W, Y → Z then W, X → Z

It is so called pseudotransitivity rule which is a generalization of transitivity rule. If we assume that W is an empty set than the pseudotransitivity rule reduces to the transitivity rule. Correctness of pseudo transitivity rule can be quite easily proved with the Armstrong axioms. We can apply augmentation rule to X → Y getting WX → WY. Then we apply transitivity rule to WX → WY and WY → Z obtaining WX→ Z .

If X → Y and Z ⊆ Y then X → Z

It is so called decomposition rule or reduce right hand side rule. it means that we can always remove an attribute from right-hand side of any functional dependency and the result is still valid functional dependency. However, note that a set of attributes on the right-hand side of functional dependency cannot be empty.

If X → Y then X, Z → Y

It is a rule that allows us to extend a right-hand side of any valid functional dependency with any attribute and to still get a valid functional dependency.

It is worth to remember to simple principles governing derivations of functional dependencies. It is allowed to reduce the right-hand side of any functional dependency and it is allowed to extend the left-hand size of any functional dependency and ... NOT the opposite.

Other inference rules

Let R = (A₁, ..., A_n) be a relational schema (a header of relational table) and
let X, Y, Z be the nonempty subsets of {A₁, ..., A_n}
If X → Y and X → Z then X → Y, Z (union rule)
If X → Y and W, Y → Z then W, X → Z (pseudotransitivity rule)
If X → Y and Z ⊆ Y then X → Z (decomposition rule or reduce right hand side rule)
If X → Y then X, Z → Y (extend left hand side rule)

Functional dependencies

Outline

Functional dependency ? What is it ?
Functional dependencies versus classes of objects
Functional dependencies versus associations
Derivations of functional dependencies
Armstrong axioms
Other inference rules
Using inference rules

Using inference rules

Let R = (A, B, C) be a relational schema
Given set of functional dependencies F = {A → B, B → C} valid in R
Is it true that A → C ?
If A → B and B → C then application of transitivity axiom provides A → C

Using inference rules

Let R = (A, B, C) be a relational schema
Given set of functional dependencies F = {A → B, C} valid in R
Is it true that A → B and A → C ?
Reflexivity axiom provides B, C → C
If A → B, C and B, C → C then transitivity axiom provides A → C
Reflexivity axiom provides B, C → B
If A → B, C and B, C → B then transitivity axiom provides A → B

Using inference rules

Let R = (A, B, C) be a relational schema
Given set of functional dependencies F = {A → B, A → C} valid in R
Is it true that A → B, C ?
If A → B then augmentation axiom provides A → A, B
If A → C then augmentation axiom provides A, B → B, C
If A → A, B and A, B → B, C then transitivity axiom provides A → B, C

Using inference rules

Let R = (A, B, C) be a relational schema
Given set of functional dependencies F = {A → B} valid in R
Is it true that A, C → B ?
Reflexivity axiom provides A, C → A
If A, C → A and A → B then transitivity axiom provides A, C → B

In this case, we consider a relational schema STUDENT(s#, fname, lname, dob, average) and we assume that the following functional dependencies are valid in a schema STUDENT:

s# → fname

s# → lname

s# → dob

s# → average

fname, lname, dob → s#

fname, lname, dob → average

Validity of both groups of functional dependencies comes from the identifiers of a class STUDENT considered earlier.

We apply union rule to the first four functional dependencies with a left-hand size s# and we obtain a single functional dependency s# → fname, lname, dob, average. In the same way we merge the last two functional dependencies into fname, lname, dob → s#, average.

Both functional dependencies derived now have two interesting properties. A set of attributes from both left and right-hand side of each functional dependency is the same as a set of attributes of a relational schema STUDENT. We say that it "covers" a relational schema STUDENT.

The second interesting property is such that it is impossible to remove from the left-hand side of both functional dependencies any attribute that we still get a valid functional dependency. in the first case of s# → fname, lname, dob, average we cannot remove s# because left-hand side cannot be empty. in the second case if we remove fname then it is not true that lname, dob → s#, average because it is possible to find two students with the same last name and the same date of birth who have a different student number and an average. If we remove lname then it is not true that fname, dob → s#, average becasue it is possible to find two students with the same first name and date of birth who have a different student number and an average. in the last case, if we remove date of birth then it is not true that fname, lname → s#, average because it is possible to find two students with the same first name and last name who have a different student number and average. It means that we cannot remove any attribute from the left hand side of a functional dependency fname, lname, dob → s#, average and in the same moment preserve validity of a new functional dependency obtained after elimination of an attribute from the left-hand side. In such a case we say that left-hand side of a functional dependency is minimal.

If all attributes of a functional dependency cover a relational schema and left-hand side of a functional dependency is minimal then left-hand side is a minimal key of the relational schema. It means that it is either primary key or candidate key. Such interesting conclusion allows us to find minimal keys directl y from functional dependencies valid in a relational schema. We no longer need to use information about the identifiers.

Using inference rules

A relational schema STUDENT(s#, fname,lname, dob, average) validates (satisfies) the following functional dependencies:
s# → fname
s# → lname
s# → dob
s# → average
fname, lname, dob → s#
fname, lname, dob → average
We proved that if A → B and A → C then A → B, C
Hence,
s# → fname, lname, dob, average and ...
fname, lname, dob → s#, average
Note, that both functional dependencies cover entire relational schema and no other functional dependencies that do not cover entire relational schema validate in the schema e.g. fname → s#

References

T. Connoly, C. Begg, Database Systems, A Practical Approach to Design, Implementation, and Management, Chapter 14.4 Functional Dependencies, Chapter 15.1 More on Functional Dependencies, Pearson Education Ltd, 2015