Relations and Functions

Relations are not only abstract sets of ordered pairs. They appear in foreign-key links, join tables, dependency graphs, and state-transition systems used all over software engineering.

An equivalence relation groups objects into classes using three properties: reflexive, symmetric, and transitive.

Function composition means applying one function and then another. A function has an inverse only when each output comes from exactly one input.

A function can fail by hitting two inputs with the same output, by missing outputs in the codomain, or by doing both.

A function gives **exactly one output** for each input in its domain. The key is checking repeated inputs carefully.

A partial order is reflexive, antisymmetric, and transitive. Unlike equivalence relations, not every pair must be comparable.

In a poset, **least** and **greatest** are stronger than **minimal** and **maximal**. Least means below everything; minimal only means nothing is strictly below it.

A relation can be **reflexive**, **symmetric**, **antisymmetric**, or **transitive**. The skill is recognizing what each word really asks you to check.

Aggregation questions are about partitioning rows into groups, then summarizing each group carefully. The common traps are filtering at the wrong stage, forgetting how `NULL` behaves, and accidentally duplicating rows before aggregating.

Index and query-plan interview questions are mostly about search-space pruning. Good indexes cut down candidate rows quickly; bad selectivity, tiny tables, or the wrong leading columns can erase that advantage.

SQL joins are concrete relation operations. Interview questions about joins usually reduce to three ideas: which rows survive, when rows duplicate, and when missing matches turn into `NULL` values.

Database design questions are relation questions wearing engineering clothes. Keys identify tuples, foreign keys connect relations, and functional dependencies explain when one set of attributes determines another.