2 - Relational Theory and Functional Dependencies — Module Topics

Mathematical Foundations of Relational Theory

• Sets as the Building Blocks of Relational Theory — Relational theory is grounded in set theory, which provides the mathematical language for defining and manipulating data collections.
• Domains: The Universe of Attribute Values — A domain is a named, finite or infinite set of atomic values from which the actual values appearing in a column of a relation are drawn.
• Tuples: Ordered Lists of Attribute Values — A tuple is a single, ordered sequence of values, one drawn from each corresponding domain, representing a single entity or relationship instance.
• The Formal Definition of a Relation — A relation is formally defined as a subset of the Cartesian product of one or more domains, represented as a set of tuples that all conform to the same attribute structure.
• Attributes: Named Columns with Semantic Meaning — An attribute is a named column of a relation, pairing a human-readable name with a specific domain to give semantic meaning to each position in a tuple.
• The Relational Model as a Mathematical Framework — The relational model, introduced by E.F. Codd, applies these mathematical constructs—sets, domains, tuples, and relations—to provide a rigorous, declarative foundation for database design and querying.

Relations, Tuples, and Attributes

• Relations as Tables — In the relational model, a relation is a mathematical structure represented as a two-dimensional table containing structured data.
• Tuples as Rows — A tuple is a single row within a relation, representing one instance or record of the entity that the relation describes.
• Attributes as Columns — Attributes are the named columns of a relation, each describing a specific property or characteristic of the entity being modeled.
• Domains and Attribute Values — Every attribute in a relation is associated with a domain, which is the complete set of valid values that the attribute may hold.
• The Relation Schema — A relation schema formally defines the structure of a relation by specifying its name and the complete list of its attributes along with their domains.
• How Relations, Tuples, and Attributes Work Together — Relations, tuples, and attributes form an interconnected hierarchy that provides a complete framework for organizing and representing structured data.

Introduction to Functional Dependencies

• What Is a Functional Dependency? — A functional dependency (FD) is a constraint between two sets of attributes in a relation, expressing that the value of one set of attributes uniquely determines the value of another.
• Notation and Terminology — Functional dependencies are expressed using a standard arrow notation, where the left-hand side is called the determinant and the right-hand side is the dependent attribute set.
• Attributes and Relations as the Context for FDs — Functional dependencies are always defined within the context of a specific relation, operating over its attributes and the tuples that populate it.
• Basic Examples of Functional Dependencies — Concrete examples help illustrate how functional dependencies reflect real-world relationships between data attributes in everyday database scenarios.
• Trivial vs. Non-Trivial Functional Dependencies — Not all functional dependencies carry meaningful information — a distinction is made between trivial dependencies, which are always true by definition, and non-trivial ones, which express real constraints.
• Why Functional Dependencies Matter — Functional dependencies serve as the mathematical basis for making principled decisions about relational database schema design, particularly in the normalization process.

Types and Properties of Functional Dependencies

• Trivial Functional Dependencies — A functional dependency is considered trivial when the dependent attribute is already contained within the determinant set, making it always true by definition.
• Non-Trivial Functional Dependencies — A non-trivial functional dependency exists when the dependent attribute is not contained within the determinant set, revealing a meaningful constraint on the data.
• Armstrong's Axiom: Reflexivity — Reflexivity is the first of Armstrong's Axioms and states that if Y is a subset of X, then X functionally determines Y.
• Armstrong's Axiom: Augmentation — Augmentation states that if X functionally determines Y, then adding the same set of attributes Z to both sides preserves the dependency.
• Armstrong's Axiom: Transitivity — Transitivity states that if X determines Y and Y determines Z, then X must also functionally determine Z.
• Derived Rules from Armstrong's Axioms — From the three primary axioms, additional useful inference rules — such as union, decomposition, and pseudotransitivity — can be derived to simplify reasoning about functional dependencies.
• Using Functional Dependency Properties to Reason About Data — Armstrong's Axioms and derived rules provide a complete and sound system for inferring all valid functional dependencies that follow from a given set, enabling systematic analysis of database schemas.

Functional Dependencies and Database Design

• Functional Dependencies as Design Blueprints — Functional dependencies (FDs) serve as the primary analytical tool for understanding how attributes relate to one another within a schema, guiding initial design decisions before a single table is created.
• Inferring Schema Structure from Dependencies — The set of functional dependencies present in a domain directly suggests how relations should be structured, with each dependency pointing toward a natural grouping of attributes.
• Redundancy and Anomalies Caused by Ignored Dependencies — When functional dependencies are not properly respected in a schema, data redundancy and update, insertion, and deletion anomalies emerge as direct consequences.
• Functional Dependencies as the Foundation for Normalization — Normalization is the systematic process of restructuring relations to eliminate redundancy, and each normal form is defined directly in terms of which functional dependencies are or are not permitted within a relation.
• Lossless Decomposition and Dependency Preservation — When splitting a relation into smaller ones to satisfy normalization goals, designers must ensure the decomposition is lossless and, where possible, preserves all original functional dependencies.
• Using Closure and Keys to Validate Schema Decisions — The attribute closure of a set of attributes under a given FD set allows designers to verify candidate keys and assess whether a proposed schema correctly captures all required constraints.