Codd's fourth rule requires a dynamic online catalog based on the relational model. What does that require, and how do relational engines satisfy it today?

## What the rule demands Codd's fourth rule: *the database description is represented at the logical level in the same way as ordinary data, so that authorised users can apply the same relational language to its interrogation as they apply to regular data.* The catalog (also called the data dictionary or system catalog) is the database's description of itself: which tables exist, their columns and data types, primary and foreign keys, check constraints, indexes, views, routines, and who is granted what. The rule requires three properties. **Relational representation.** Metadata is stored as rows in tables, the same shape as user data. This is really the information rule (Rule 1) applied to metadata: information about the database is still information, so it must be values in tables, not a proprietary binary header only the engine can decode. **Dynamic and online.** The catalog is the live, authoritative description, updated as part of schema change. There is no window where the catalog disagrees with reality, and no separate export step. Contrast this with a hand-maintained data dictionary in a wiki or spreadsheet, which drifts the moment someone ships a schema change. **Queried with the same language.** No special metadata API, no vendor utility required. The same declarative query language answers 'which tables have a column named customer_id' as answers 'which customers ordered last month'. And the same authorisation applies: a user sees catalog entries for objects they are entitled to see. ## How engines implement it Two layers exist in practice: - **Native system catalogs** — each engine's own internal tables describing objects, exposed under a system schema. Rich and complete, but shaped differently in every product. - **INFORMATION_SCHEMA** — a standard set of views over those catalogs with standard names and columns, so a tool can enumerate tables, columns and constraints portably across engines. This pairing is why generic tooling works at all. Object-relational mappers validate mappings, migration tools detect drift, IDEs autocomplete column names, data-catalog and lineage products crawl schemas, and permission audits enumerate grants — all by querying metadata as ordinary data. None of that would be portable if each engine required a bespoke metadata call. ## Where reality departs from the rule - **Read-mostly.** The rule speaks of interrogation; in practice catalogs are effectively read-only to users. You change structure through schema statements, and the engine updates the catalog transactionally as a side effect. Allowing arbitrary direct updates to catalog rows would let a user create a description that no longer matches the stored data. Some engines physically permit superuser catalog writes, and doing so is a well-known route to an unrecoverable database. - **Not fully uniform.** INFORMATION_SCHEMA covers standard objects; anything vendor-specific — partitioning details, storage options, extension objects — is visible only through native catalogs. Portable introspection therefore covers the common core, not everything. - **Statistics and physical metadata** live alongside the logical catalog and are engine-specific by nature. ## Why it is worth caring about Rule 4 is the rule that makes a database *self-describing*, and self-description is what makes automation possible. A concrete review test: if answering 'what does this database contain, and who can read it' requires a document maintained by a human, the system is being used as if it failed Rule 4 even though it satisfies it. The catalog is the single source of truth about structure; documentation and diagrams are derived artefacts that can drift, and treating them as authoritative is the practical failure mode. A second consequence is security-flavoured. Because catalog access is governed by the same authorisation rules as data, metadata is not automatically public: an unprivileged user may legitimately be unable to see that a table exists. Introspection tooling therefore needs appropriate grants, and granting broad catalog access to expose a discovery feature is a real decision with a real blast radius.