Relations, Tuples, Attributes and Domains

The relational model has exactly four structural terms. A relation is a set of tuples, a tuple is one fact, an attribute is a named column and a domain is the set of values that column may hold.

Concept

The relational model describes all data with four terms. Every later idea — keys, constraints, algebra, normalisation — is built from them, so they are worth learning precisely rather than approximately.

Formal termEveryday termMeaning
RelationTableA set of tuples sharing the same attributes.
TupleRow or recordOne complete fact about one thing.
AttributeColumn or fieldA named property, with a type.
DomainData type, extendedThe set of atomic values an attribute may take.
                    attributes
            +----------+--------+-------+
            | roll_no  | name   | marks |   <- relation schema
            +----------+--------+-------+
   tuple -> |    21    | Meera  |   87  |
   tuple -> |    22    | Ravi   |   91  |   <- relation instance
   tuple -> |    23    | Anitha |   78  |
            +----------+--------+-------+

   degree      = number of attributes  = 3
   cardinality = number of tuples      = 3

Degree and cardinality

TermCountsChanges when
Degree (arity)Attributes — the widthThe schema changes. Rare.
CardinalityTuples — the heightData changes. Constantly.
Note that cardinality here means the number of rows in a relation. In the ER model the same word meant the ratio of a relationship. Two unrelated meanings, both examined, so read the question carefully.

Domains

A domain is the set of permitted atomic values for an attribute, together with its meaning. It is more than a data type.

AttributeData typeDomain
marksIntegerIntegers from 0 to 100
genderCharacterThe set { M, F, O }
pincodeCharacter(6)Exactly six digits
dobDateDates in the past

Atomic means indivisible from the point of view of the model: the DBMS never looks inside the value. Storing "9840012345, 9840099887" in one column breaks atomicity, and it is exactly what first normal form forbids.

The properties of a relation

Six properties follow from a relation being a set of tuples. They are examined directly.

  1. Each tuple is unique. A set has no duplicate members, so no two tuples of a relation are identical. This is why every relation must have a key.
  2. Tuples are unordered. There is no first row. Any order you see is an accident of storage, which is why sorting must be requested explicitly.
  3. Attributes are unordered. Columns are identified by name, not position.
  4. Attribute names are unique within a relation.
  5. Every value is atomic. No lists, no repeating groups, no nested tables.
  6. Every value comes from the attribute domain, or is null.
  These two are THE SAME RELATION

   +----+-------+          +-------+----+
   | id | name  |          | name  | id |
   +----+-------+          +-------+----+
   | 21 | Meera |          | Ravi  | 22 |
   | 22 | Ravi  |          | Meera | 21 |
   +----+-------+          +-------+----+

  Rows reordered, columns reordered. Same set of tuples,
  same attribute names, therefore the same relation.

Where practice departs from theory

Real products relax two of these properties, and knowing which two is a good interview answer.

PropertyTheoryPractice
No duplicate tuplesImpossible — a relation is a setTables without a primary key can hold duplicate rows. Products work with multisets, not strict sets.
Attributes unorderedIdentified by name onlyColumns have a defined position, and a query that selects every column relies on it.
Tuples unorderedNo row order at allTrue in practice too — never rely on the order rows come back in without asking for it.

Example

-- Illustration only: the definition makes the four terms concrete.
-- students is the RELATION
--   roll_no, first_name, marks are ATTRIBUTES
--   the type and check together express the DOMAIN
--   each stored row is a TUPLE

-- students ( roll_no    INT          PRIMARY KEY
--          , first_name VARCHAR(50)  NOT NULL
--          , marks      INT          CHECK ( marks BETWEEN 0 AND 100 ) )

-- degree = 3, always
-- cardinality = however many students exist right now

Common mistakes

  • Swapping degree and cardinality. Degree is columns, cardinality is rows.
  • Treating a domain as just a data type. The domain includes the permitted range and the meaning.
  • Assuming rows come back in insertion order. They may today and may not tomorrow.
  • Storing a list in one column. It breaks atomicity and every operation on that column.
  • Believing a table can never hold duplicate rows. A relation cannot; a table without a key can.

Exam and interview questions

  1. Define relation, tuple, attribute and domain.
  2. Differentiate degree and cardinality.
  3. List the six properties of a relation and explain why tuples must be unique.
  4. What does atomic mean, and which normal form depends on it?
  5. Name two ways real products depart from the strict relational definition.

Practice

  1. For a table with columns isbn, title, author, price and eight rows, state the degree and cardinality.
  2. Write the domain, not just the type, for: pincode, percentage, gender, mobile number.
  3. Explain in three sentences why unordered tuples is a useful property rather than a limitation.

Conclusion

A relation is a set of tuples over named attributes drawn from domains. Degree counts attributes, cardinality counts tuples, and the six properties — especially uniqueness and atomicity — are the foundation that keys, constraints and normalisation are built on.

Written by Lorens Mishra

Software Engineer Notes Management System Administrator

Continue reading

All DBMS notes →

Discussion

0 comments
Sign in to join the discussion.

No comments yet. Be the first to say something.