A database schema is often described as a set of relation schemas plus the constraints over them. What exactly belongs to that database schema, what belongs to the database instance at a given moment, and how does that differ from what SQL calls a schema?

## Building the database schema out of relation schemas A single **relation schema** gives a relation's name and its heading - the set of attributes, each with a domain. A **database schema** is then the set of all relation schemas in the database, plus the constraints declared over them. The constraint half is what candidates most often omit, and it is where the interesting content lives. Constraints come in two shapes: - **Intra-relational** constraints, which can be evaluated by looking at one relation alone: domain constraints (the attribute's permitted value set), key constraints (some attribute set uniquely identifies a tuple), and check-style conditions over tuples of that relation. - **Inter-relational** constraints, which involve more than one relation. The canonical case is **referential integrity**: an attribute in one relation may only hold values that appear as key values in another relation, or be absent. Theory also permits general assertions spanning several relations, which engines support only partially. Because inter-relational constraints exist, the schema is genuinely a property of the database as a whole. You cannot decide whether a state is legal by inspecting one relation in isolation. ## What the database instance is A **database instance** is a set containing one instance for each relation schema in the database schema - a complete snapshot of the data at one instant. It is **legal** only if every constraint in the database schema holds simultaneously across all of those relation instances. That 'simultaneously' is what makes correctness a whole-database property. A referencing tuple pointing at a key value that is not present anywhere makes the *database* illegal, even though each relation, examined alone, looks fine. ## A checklist of what sits on each side On the **schema** side: relation names; attribute names and their domains; whether an attribute may be absent; key declarations; referential constraints; check conditions; default value definitions; view definitions, which are named derived relations and therefore part of the definition; and the definitions of any stored procedural or trigger logic. On the **instance** side: the tuples themselves, in every relation - and nothing else that carries meaning. The rows in a lookup table are instance data even though they feel definitional, which is why teams have to decide deliberately whether reference data ships with migrations or with data loads. Auxiliary structures such as indexes are a third category: their *definitions* are part of the stored database definition, while their contents are derived from the instance and carry no information not already in it. The practical test is simple: if losing it means the definitions are gone, it belongs to the schema and should live in version control; if losing it means data is gone, it belongs to the instance and needs backup and recovery. ## The word 'schema' is overloaded, and the overload matters SQL uses schema for a **namespace object**: a container inside a database that groups tables, views, routines and so on, gives them a qualified name, and acts as a unit for access control and name resolution. Teams use these namespaces to separate concerns - one for the application's core tables, one for staging, one per module or tenant. That is a completely different concept from the theoretical intension. A single SQL namespace contains many relation schemas; a database's overall schema in the theoretical sense spans all of its namespaces. Both meanings are legitimate and both are in daily use, so the professional move is to notice the ambiguity out loud and say which one you mean. In an interview, defining the theoretical sense first and then noting the namespace sense demonstrates exactly the precision the question probes for. A third informal usage adds to the confusion: 'the schema' is often shorthand for the migration files themselves - the versioned artefacts that produce the definitions. That is fine as long as everyone understands the artefact is not the concept. ## Why the distinction pays off Separating definition from state gives you a clean rule for almost every operational question. Definitions are code: reviewed, versioned, migrated forward, coordinated with the applications that depend on them. State is data: written by transactions, sized by growth, protected by backups, restored by recovery. When a change touches both - adding a constrained attribute and populating it - you can see immediately that it is two kinds of change bundled into one step, which is exactly why such changes need careful sequencing.