Before you can reason about keys, functional dependencies, or normalization, you need a precise vocabulary for what a relation actually is. In relational theory, a relation is not simply a table on a screen — it is a mathematical object defined in terms of sets. A domain is the set of permitted values for an attribute, a tuple is an ordered list of values drawn from those domains, and a relation is a subset of the Cartesian product of the domains involved. Attributes give each position in the tuple a name and a semantic meaning, which is what lets us talk about columns by label rather than by position.
This mathematical grounding matters for the rest of the course because every later result — Armstrong's Axioms, attribute closure, candidate key identification, and the normal forms — is stated and proved in set-theoretic language. If you are comfortable with the ideas of set membership, Cartesian products, n-ary relations, and the distinction between a relation schema (the structure) and a relation instance (the current set of tuples), the formal parts of Module 2 will read as straightforward consequences rather than as arbitrary rules.
As you watch the videos below, keep a running glossary. For each term — domain, tuple, attribute, degree, cardinality, relation, relation schema — write down both the formal definition and the everyday table-based analogy. Notice especially where the practical database vocabulary (table, row, column) lines up with the mathematical vocabulary (relation, tuple, attribute), and where the two differ: tables may tolerate duplicate rows and rely on column order, while a mathematical relation is a set and therefore cannot.
A concise overview from IBM Technology explaining what a relational database is, how data is organized into tables of rows and columns, and how relationships between tables are expressed through keys. Based on its title and description, it is likely to cover the table/row/column vocabulary, primary and foreign keys, and the role of SQL in querying relational data.
It gives you the practical, industry-facing picture of the relational model from a well-known technology producer, which is the concrete counterpart to the set-theoretic definitions — useful for mapping "table, row, column" onto "relation, tuple, attribute."
A lecture from Gate Smashers on tuple relational calculus, a formal query language in which queries are expressed as logical conditions over tuple variables ranging across a relation. Expect worked examples using quantifiers and predicates, with attention to how a tuple variable refers to rows of a named relation.
Tuple calculus is one of the clearest demonstrations that relations are mathematical sets of tuples rather than mere spreadsheets, and this channel is widely used for exam-oriented DBMS instruction with step-by-step examples.
A short set theory lecture introducing n-ary relations — subsets of the Cartesian product of n sets — and their applications, including the use of such relations to model database tables. It should cover the formal definition, the notion of degree, and how attributes correspond to the component sets.
This is the most direct mathematical treatment of the topic's central definition, connecting domains and Cartesian products to the formal notion of a relation in exactly the way the course requires.
Together these three videos build the set-theoretic vocabulary required by MO1: the n-ary relations lecture supplies the formal definition of a relation as a subset of a Cartesian product of domains, the tuple calculus lecture reinforces tuples and attributes as the objects that formal queries quantify over, and the IBM overview anchors those abstractions in the familiar table-row-column language used by real database systems. That shared vocabulary is the prerequisite for the remaining outcomes — you cannot state a functional dependency and classify it as trivial or non-trivial (MO2), apply Armstrong's Axioms (MO3), compute an attribute closure to find candidate keys (MO4), or diagnose redundancy and update anomalies in a schema (MO5) without first being able to speak precisely about attribute sets, tuples, and relation schemas. Treat these videos as the foundation layer; the FD-specific material later in the module assumes you already have it.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
The relational model describes data using a small number of precisely defined pieces. A relation is a set of tuples over a fixed set of attributes; informally, we draw it as a table, where each row is a tuple and each column is an attribute. Each attribute is associated with a domain — the set of permitted values for that column — and the relation schema names the relation and lists its attributes (and their domains). Because a relation is formally a set, there are no duplicate tuples and no inherent ordering of rows; column order is likewise unimportant once attributes are named.
These definitions matter for everything else in this module. Functional dependencies, candidate keys, attribute closure, and normalization are all stated in terms of attributes and the tuples of a relation, so being comfortable moving between the picture (a table) and the formalism (a set of tuples over attributes with domains) is the prerequisite for the rest of the course.
The videos below approach these ideas from a practical, industry-facing angle. As you watch, deliberately translate the vocabulary you hear — table, row, column, field, data type, key — into the formal terms relation, tuple, attribute, domain, and relation schema. Note where the informal presentation differs from the strict set-theoretic definition (for example, treating tables as ordered lists of rows), and be ready to state the formal version yourself.
An introductory overview from IBM Technology explaining what a relational database is: data organized into tables made up of rows and columns, with keys used to relate tables to one another. Based on its title and description, it likely walks through a simple example schema and touches on SQL as the language used to query such data. It is a short, whiteboard-style explainer aimed at newcomers.
It is the most direct match for the core subtopics — tables, rows, and columns — from a well-regarded technical producer, and it gives you the everyday vocabulary you will map onto the formal terms relation, tuple, and attribute.
A comparison video that contrasts relational databases with non-relational (NoSQL) alternatives such as document, key-value, and other flexible-schema stores. Expect discussion of fixed schemas and structured tabular data on the relational side versus looser, schema-on-read structures on the other, along with trade-offs in consistency, flexibility, and typical use cases.
Seeing what the relational model is not sharpens your understanding of what a relation schema actually commits you to — a fixed set of attributes, each drawn from a declared domain.
A tutorial from Lucid Software on building entity relationship diagrams from scratch, covering entities, attributes, and cardinality as stated in its description. It introduces the notation used to sketch what data you intend to store before writing any schema, with attributes attached to entities.
It reinforces the notion of attributes as the named, typed properties that make up a schema, and connects the abstract relation schema to the design diagrams you will encounter when modeling data.
Together these videos build the vocabulary and intuition that MO1 requires: the IBM overview grounds relations, tuples, and attributes in concrete tables, rows, and columns; the relational versus non-relational comparison highlights why a fixed schema with defined domains is a defining feature of the relational model; and the ERD tutorial reinforces attributes as named properties of a schema. None of the videos covers functional dependencies, Armstrong's Axioms, attribute closure, or anomaly analysis (MO2 through MO5) — those are developed in the module readings and exercises — but the precise understanding of attributes, tuples, and relation schemas you take from these videos is exactly the foundation on which those later outcomes are stated and solved.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A functional dependency (FD) is a statement about a relation that says: if two tuples agree on the values of one set of attributes, they must also agree on the values of another set. We write this as X -> Y, read "X functionally determines Y" or "Y is functionally dependent on X." The left-hand side X is called the determinant. For example, in a relation about students, StudentID -> Name asserts that a given StudentID value can never be paired with two different names.
FDs are not facts you discover by staring at one snapshot of data; they are constraints that come from the meaning of the data in the real world the database models. That is why the context matters: an FD is always stated over the attributes of a particular relation schema. This connects directly back to the formal relational vocabulary from earlier in the module — domains, attributes, tuples, and schemas — because an FD is a rule about which tuples are legal in a relation.
As you work through this topic, pay attention to three things. First, the notation and how to read it aloud correctly. Second, the distinction between trivial FDs (where the right-hand side is contained in the left-hand side, such as {A, B} -> A, and which hold automatically) and non-trivial FDs, which carry real information. Third, why any of this matters: FDs are the foundation for keys, for Armstrong's Axioms, for attribute closure, and ultimately for normalization and the elimination of redundancy and update anomalies. The videos below approach these ideas at different levels of depth, so watch them in order and treat the later ones as a preview of where FDs lead.
A focused lecture on functional dependencies in DBMS that, based on its title, walks through the definition of an FD and then works systematically through the common types, including trivial and non-trivial dependencies. At roughly 17 minutes it is the longest and most introductory-paced of the three, so expect notation, terminology, and worked examples drawn from sample relations. This is the video that most directly matches the scope of this topic.
It is the closest match to the subtopic list, covering the definition, notation, and the trivial versus non-trivial distinction in a single continuous explanation, which makes it a good primary viewing before you move on to applications of FDs.
Decomplexify's explanation of Boyce-Codd Normal Form builds up from functional dependencies and keys to the BCNF condition, using concrete example tables throughout. Because BCNF is defined entirely in terms of FDs — every determinant must be a superkey — the video necessarily spends time showing how to read FDs off a relation and why some of them cause trouble. It also illustrates the redundancy and anomalies that motivate the whole subject.
Decomplexify is a widely watched and carefully produced channel, and this video answers the "why do functional dependencies matter?" subtopic better than an abstract treatment can, by showing the concrete problems FDs are used to diagnose.
This video covers Armstrong's Axioms and inference rules alongside a review of functional dependency types, including trivial, non-trivial, and multivalued dependencies. Expect the reflexivity, augmentation, and transitivity rules to be stated and applied to small FD sets to derive new dependencies. Note that the instruction is delivered in Malayalam, so use it mainly if that language suits you or as a visual reference for the rule statements and worked derivations.
It extends the basic FD definitions toward the inference rules you will use later in the module, and reinforces the trivial versus non-trivial classification from a second instructor's perspective.
Together these videos move from definition to application. The StudyTech Hub lecture establishes the notation and terminology that let you state FDs precisely over a relation schema (MO1) and directly addresses the trivial versus non-trivial distinction you must be able to make (MO2). The CHAPTERS video introduces Armstrong's Axioms and shows derivations, supporting the inference work in MO3 and laying the groundwork for computing attribute closures and identifying candidate keys (MO4). The Decomplexify BCNF video supplies the motivation and the evaluative skill behind MO5, demonstrating how analyzing a schema's functional dependencies exposes redundancy and update anomalies. Watch them in the order listed, and keep in mind that the closure algorithm in MO4 is only previewed here — you will practice it directly in the module exercises.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A functional dependency (written X -> Y) says that the values of attribute set X determine the values of attribute set Y: any two tuples that agree on X must agree on Y. Once you can state dependencies formally, you can classify them. A dependency is trivial when the right side is already contained in the left side (for example, {StudentID, Name} -> Name), and non-trivial when it tells you something new about the data. Trivial dependencies always hold by definition; non-trivial ones encode real business rules and are the ones that drive key discovery and normalization.
Armstrong's Axioms give you a sound and complete set of inference rules for reasoning about dependencies: reflexivity (if Y is a subset of X, then X -> Y), augmentation (if X -> Y, then XZ -> YZ), and transitivity (if X -> Y and Y -> Z, then X -> Z). From these three, the commonly used derived rules follow — union, decomposition, and pseudotransitivity. Applying them repeatedly lets you compute the closure of an attribute set (X+), which is the practical tool for testing whether a dependency is implied, identifying candidate keys, checking whether two FD sets are equivalent, and reducing an FD set to a canonical (irreducible) cover.
As you watch the videos below, keep three questions in mind. First, for every example dependency, decide for yourself whether it is trivial or non-trivial before the narrator says so. Second, when a new dependency is derived, name the axiom or derived rule that justifies each step. Third, notice how closure computation is really just Armstrong's Axioms applied mechanically — that connection is what makes the later topics of candidate keys and normalization manageable.
This lecture introduces functional dependency in a DBMS and then walks through the types of dependencies, including trivial, non-trivial, and multivalued dependencies. It also presents Armstrong's Axioms (Armstrong's inference rules), which is the standard set of reflexivity, augmentation, and transitivity rules, typically with worked examples showing how new dependencies are inferred. Note that the narration is in Malayalam with English technical terms and on-screen notation, and the video is chaptered so you can jump to the section you need.
It is the one video here that directly addresses the two core subtopics — the trivial/non-trivial classification and the three Armstrong's Axioms — in a single, clearly chaptered presentation, so it maps most closely to the definitional part of this topic.
This tutorial explains what the closure of an attribute set means and demonstrates the step-by-step procedure for computing X+ from a given set of functional dependencies. It then shows how closures are used to test whether two sets of functional dependencies are equivalent, that is, whether each set implies all the dependencies of the other.
Closure is Armstrong's Axioms put to work algorithmically, so this video shows the practical payoff of the inference rules and gives you the technique used for implication testing and candidate-key identification.
This lecture defines the canonical cover (also called the irreducible set or minimal cover) of a set of functional dependencies and demonstrates the procedure for computing one. The steps shown typically involve decomposing right-hand sides to single attributes, removing extraneous attributes from left-hand sides, and eliminating redundant dependencies — each check relying on closure and the inference rules.
It extends the reasoning skills from the previous video into a complete, repeatable procedure, showing how FD properties are used to simplify a schema's dependency set without losing information.
Together these videos move from definition to application. The first supports MO2 by distinguishing trivial from non-trivial dependencies and supports MO3 directly by presenting reflexivity, augmentation, and transitivity along with the derived inference rules. The second video targets MO4, giving the closure algorithm you need to identify candidate keys and to test whether one FD set implies another, and it reinforces MO3 because every closure step is an application of the axioms. The third video builds on both, using closure-based reasoning to produce a minimal, redundancy-free set of dependencies, which prepares you for the schema evaluation work in MO5 and connects back to the formal relational vocabulary of MO1.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Functional dependencies are more than an abstract piece of relational theory — they are the blueprint you use when deciding what tables a database should have and which attributes belong in each one. A dependency such as StudentID -> Advisor is a statement about the real world: it says that knowing a student determines exactly one advisor. Once you write down the dependencies that hold over your data, the structure of a good schema follows from them in a fairly mechanical way.
When dependencies are ignored, the cost shows up as redundancy and as insertion, deletion, and update anomalies: the same fact stored in many rows, facts that cannot be recorded because no complete row exists yet, and facts that vanish when an unrelated row is deleted. Normalization is the systematic response. Each normal form (2NF, 3NF, BCNF, and beyond) is defined in terms of functional dependencies and keys, and moving a schema into a higher normal form means decomposing relations so that every dependency has a key on its left side. Two properties constrain how you decompose: the decomposition must be lossless (joining the pieces back together recovers exactly the original relation, no spurious tuples) and ideally dependency preserving (every original dependency can still be enforced on a single fragment without a join).
While watching these videos, keep three questions in mind. First, which attribute closures and candidate keys are being computed, and how are they used to justify a split? Second, what specific anomaly does each decomposition eliminate? Third, note carefully the trade-off the first video highlights: BCNF is the stricter condition, but it does not always allow a dependency-preserving decomposition, which is why 3NF remains a practical target in real designs.
This lecture examines whether a BCNF decomposition always preserves functional dependencies, working through normalization examples to show the answer. Based on the title and channel's exam-oriented style, expect worked relations where candidate keys are identified, the schema is split, and the resulting fragments are checked for both losslessness and whether each original dependency can still be enforced.
It directly targets two of the harder subtopics — lossless decomposition and dependency preservation — and the counterexample framing makes the 3NF versus BCNF trade-off concrete rather than a memorized rule.
A single consolidated walkthrough of the normal forms from 1NF through 5NF, including 2NF, 3NF, and BCNF, illustrated with everyday examples rather than purely symbolic relations. The video should show, for each form, which kind of dependency violation it removes and how the schema changes as a result.
Gate Smashers' DBMS series is widely used and consistently accurate on definitions, and this one video gives you the full ladder of normal forms in order, making clear how functional dependencies serve as the foundation for every step.
This talk steps back to ask what normalization actually is and why it matters to people who build and maintain data platforms, rather than drilling procedure. Expect discussion of the motivation — redundancy, anomalies, and maintainability — alongside the presenter's own ranking of the normal forms by practical usefulness.
It supplies the design rationale that complements the mechanical examples, which supports the subtopics on dependencies as design blueprints and on the anomalies that appear when dependencies are ignored.
Together these videos carry the formal machinery of Module 2 into design practice. The normal-forms overview and the practitioner talk both show how redundancy and update anomalies trace back to specific functional dependencies, which is exactly the evaluation skill in MO5, and they reinforce the distinction between dependencies that are harmless and those that violate a normal form (MO2). The BCNF and dependency-preservation lecture depends on identifying candidate keys before any split can be justified, giving you repeated practice with the attribute closure reasoning from MO4 and the derivations from Armstrong's Axioms in MO3. All three keep the relational schema — attributes, keys, and relation structure — at the center, which supports the formal vocabulary established in MO1.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.