What do the terms degree and cardinality mean for a relation, and which of the two normally changes while an application is running?

## The two counts A relation is a heading (a set of attributes, each a name plus a domain) and a body (a set of tuples over that heading). - **Degree** (sometimes called arity) = the number of attributes in the heading. `ORDER {order_id, customer_id, placed_at, total}` has degree 4. - **Cardinality** = the number of tuples in the body. If that table currently holds 12 million orders, its cardinality is 12,000,000. Both degenerate cases are legal and occasionally show up in interviews. A relation with cardinality 0 is the empty relation: it still has a heading, so it still has a type, and queries against it return empty results rather than errors. A relation of degree 0 - no attributes at all - is a curiosity of relational theory with exactly two possible values (the body is empty, or contains the single empty tuple), useful for reasoning about identities but not something you create in practice. ## Different lifecycles The reason interviewers pair the terms is to test whether you separate type from value. Degree belongs to the heading, which is part of the relation's *type*. Adding or dropping an attribute produces a relation of a different type, which is why it is a schema change: it is reviewed, versioned, migrated, and it can break every query and application object that referred to the old shape. Degree is stable for long stretches and changes only by deliberate act. Cardinality belongs to the body, which is the relation's *value*. Every insert, delete, or bulk load changes it, potentially thousands of times per second, with no schema change involved. Cardinality is what you graph, alert on, and use when reasoning about growth and storage. ## Why cardinality shows up everywhere in database work Row counts drive nearly every decision an engine makes and every decision an engineer makes about a table: whether a scan or an index lookup is cheaper, how much memory a join needs, how long a maintenance operation will take, whether a table is a candidate for partitioning or archival. When someone says 'that table is large', they are talking about cardinality, not degree. Degree matters too - very wide relations cost more per tuple to read and are often a modelling smell - but it is not the number that moves. ## The overloaded vocabulary 'Cardinality' is used in at least three distinct senses around databases, and mixing them up is a common way to look imprecise: 1. **Relation cardinality** - the number of tuples, the meaning above. 2. **Column (or attribute) cardinality** - the number of *distinct* values an attribute currently takes. A boolean flag is 'low cardinality'; a unique identifier is 'high cardinality'. This is the sense used when discussing selectivity and whether an attribute is worth indexing. 3. **Relationship cardinality** - the multiplicity in a conceptual model: one-to-one, one-to-many, many-to-many. All three are legitimate; the fix is simply to say which one you mean. 'Degree' is comparatively safe, though you will also see 'arity' for the same idea, and in graph or ER contexts 'degree' can mean the number of edges at a node. ## How to say it in an interview One clean sentence covers the definitional part - degree counts attributes, cardinality counts tuples - and the second sentence should be the discriminator: degree is a property of the schema and changes only by migration, cardinality is a property of the current instance and changes with every write. Adding the vocabulary caveat about column cardinality signals you have worked with real tables rather than only textbook ones.