Relations, Tuples & Schema

You've drawn boxes, ellipses and diamonds on paper. Nice.

Now the database asks a rude question: "That's a picture. Where's my table?"

Why & what

A drawing can't store anything. It has to turn into something real — and in a relational database, "real" means one thing only: a table.

That's the surprising part. Everything you drew in Module 2 — students, courses, the enrollment link between them — all of it becomes tables. There is no second shape. No special box for relationships. Just tables.

A relation is a table. Each row in it is a tuple. Each column is an attribute. The table's design — its name and column list — is the schema. The rows sitting in it right now are the instance. Five words for things you already recognise. The only reason to learn the formal words is that interviewers use them.

How it works

Let's turn the Student box from Module 2 into a real table.

1. The box becomes a relation. Student is now a table. In formal language, a relation. Same thing — use whichever word the room uses.
2. Each attribute becomes a column. roll_no, name, email. Three columns.
3. Each real student becomes a tuple. Aisha's row: 101, Aisha, aisha@c.edu. One tuple = one row = one real thing.
4. Count the columns → degree. Three columns, so the degree is 3. This changes only if you redesign the table.
5. Count the rows → cardinality. Three students today, so cardinality is 3. Add one student and it's 4.

Careful with that last word. Cardinality here means "number of rows" — not the 1:N kind from Module 2.2. Same word, two jobs. Which one is meant is always clear from context: rows, or relationships.

Pause here. Your table has 5 columns and 200 rows. What's the degree, and what's the cardinality?

Degree 5, cardinality 200. Columns first, rows second.

Notice: the schema rarely changes — the instance changes all day.

Common confusion

Schema vs instance is the one that costs marks.

• Schema = the design. Student(roll_no, name, email). Written once, changes rarely.
• Instance = the actual rows in the table right now. Changes every time anyone inserts, updates or deletes.

Simple way to hold it: the schema is the empty form, the instance is the filled-in copies. And you already met this idea in 1.3 — the schema lives at the conceptual level, and it's what data independence protects.

One more small thing. In theory, a relation is a set of tuples, so no two rows should be identical and rows have no fixed order. Real SQL is looser — it will happily let you store duplicate rows if you don't stop it. If an interviewer asks "can a relation have duplicate rows," the theory answer is no, and the practical answer is "SQL allows it unless a key prevents it." Saying both scores better than saying either.

Interview angle

1. "What's the difference between a schema and an instance?" — Schema is the structure, instance is the current data. Add that the schema is stable and the instance changes constantly.
2. "Define degree and cardinality of a relation." — Degree = number of columns. Cardinality = number of rows. Worth flagging that "cardinality" also means something different for relationships, so you know both uses.
3. "Can a relation contain duplicate tuples?" — In relational theory, no, because a relation is a set. In real SQL, yes, unless a primary key or unique constraint blocks it.

Quiz: skipped — reinforced above.

Recap

A relation is a table of tuples (rows) and attributes (columns) — its design is the schema, its current rows are the instance, degree counts columns and cardinality counts rows.