Relational Model: Why Its Features Match (i)–(iv)

The relational model (introduced by E. F. Codd) represents data as relations (tables) composed of tuples (rows) and attributes (columns). A key point for this course section is that the model’s “feature” statement is best understood as:

• Why primary keys are not required to define relations (though they are often used for constraints and efficient referencing) → aligns with (i)
• Why the model enables strong data independence (especially logical data independence) compared with many earlier models → aligns with (ii)
• Why relationships among records are explicitly expressed via formal constructs such as attributes and join conditions (and, in SQL, declaratively via foreign keys) → aligns with (iii)
• Why relations naturally scale as tables with potentially many attributes (“dimensions”), and why queries “project”/“join” over these dimensions → aligns with (iv)

A simple conceptual mapping is:
relations give the table abstraction; joins give relational links; constraints/keys (optional in theory, common in practice) govern integrity; and data independence means schema or physical organization changes don’t require rewriting application logic more than necessary.

Note: Your feature statement says “(iv) are tables with many dimensions.” In data modeling terms, this is usually interpreted as “many attributes/dimensions per relation,” not “multidimensional databases” in the OLAP sense.

Relational Model in One Diagram (Relations + Explicit Links)

Key learning terms:

• relation
• tuple
• attribute
• relational join
• data independence

(i) “There is no need for primary key data”

In the relational model, a relation is formally a set of tuples described by attributes. The model does not require that every relation must have a designated primary key for the relation to exist or for relational operations to work.

However, in practice:

• Many database designs introduce keys to support integrity constraints, uniqueness, and efficient referencing.
• But the data model’s core representation—tuples and attributes in relations—does not logically depend on having a primary key column in every relation.

Learning terms:

• primary key
• candidate key
• superkey
• referential integrity

Interpretation for this multiple-choice style claim:

• Correct as stated (in model-definition sense): relations do not require primary keys to be “relations.”
• Not a guarantee for real deployments: operationally, keys are strongly recommended and widely used.

[Callout]
type: "tip" title: "Pro Tip" content: "When evaluating statements about relational model “features,” separate formal model requirements (what relations are) from design best practices (what schemas often include for integrity/performance)."

(ii) “is much more data independence than some other database models”

A major motivation behind Codd’s relational approach is the ability to change:

• the logical schema (what attributes/relations exist and how they relate) and
• the physical schema (how data is stored, indexed, organized on disk)

without forcing application logic to be rewritten for every change. This is what people summarize as data independence.

In relational systems, the query language (and relational algebra semantics) targets the logical relations; the DBMS can often re-optimize execution plans even after reorganizing storage structures.

Learning terms:

• logical data independence
• physical data independence
• schema
• view

Why it can be “more” than other models:
Earlier record-oriented and navigation-based models often bind programs more tightly to physical traversal paths. In contrast, relational queries specify what result is desired (via selection/projection/joins), allowing the system to adapt execution strategies.

[Callout] type: "warning" title: "Common Misconception" content: "Data independence is not “no changes ever break apps.” If you alter relation attributes that an application depends on, you can still break queries. The claim is about reducing coupling to storage paths and enabling schema evolution with fewer required rewrites."

(iii) “are explicit relationships among records”

In relational systems, relationships are explicit in the mathematical sense:

• Relations contain values for attributes.
• To relate records across relations, you use join conditions based on matching attribute values.
• (In SQL-style implementations) you can additionally declare foreign keys so the link is explicitly constrained.

So, compared with navigation-style models where relationships are implicit in how you traverse pointers/records, the relational model expresses relationships as part of the query and/or as declarative constraints.

Learning terms:

• foreign key
• join condition
• selection predicate
• projection

Mermaid view of explicit relational linkage:

(iv) “are tables with many dimensions”

A relation is a table with columns (attributes). If a concept needs many attributes, the relation simply has many attributes—i.e., many “dimensions” in the sense of multiple perspectives/fields.

• Not necessarily “multidimensional arrays” like OLAP cubes
• Yes many columns/attributes (dimensions) and the ability to:
  • project only relevant attributes,
  • join across dimensions from multiple relations, and
  • filter along certain attribute ranges.

Learning terms:

• arity
• degree
• attribute domain

How “many dimensions” helps modeling: you can keep data normalized across relations while still supporting rich queries that combine many attribute dimensions through join and projection.