Catalog

TTM and the Catalog

While the concept of DBMS's having a catalog is almost universally accepted, TheThirdManifesto has precious little to say about it. Some ramblings to explore why this is so, and perhaps inevitably so ...

Definition

"The catalog" is usually understood to be a database in which information about other databases is recorded (this does not preclude the possibility that the catalog also contains similar information about itself). However, the scope covered by that term "information" may differ vastly between systems. The detailed nature of what is to be recorded may differ as well. That makes it unrealistic to try and prescribe in detail what could be called a "logical schema for the catalog". That does not mean no reasonable "common ground" can be found regarding what should reasonably be findable in the catalog for a given D. An overview.

Types-and-operators systems

> The mere existence of a type, and the details of all its possreps.

> Technical details about the implementation of the type.

> If the system supports the IM, the sub-/supertype relationships between those types.

> The inventory of operators available for operating on values of those types

> Technical details about the implementation of those operators.

Below we mention some issues that make it an iffy proposition to try and prescribe in detail what a catalog should look like in a D.

> Type names. Types are named sets of values. And it's only obvious that a type's existence should be documented in the catalog. So the catalog should keep a record of existing types and their name. So a type name should appear as a value of an attribute in a tuple in a catalog relvar defining types. So there should be a type for that name. But prescribing what type that should be, amounts to prescribing what should and should not be a valid name in a particular D. Not something TTM wants to do.

> The notion of separation of the physical from the logical in order to give the implementer the freedom to offer whatever features he likes at the physical level, makes it by definition impossible to prescribe anything regarding the nature of what a catalog should contain for physical implementation details. By way of example, one system could have its type and/or operator implementations packaged as entry points in a jar or dll on the local file system. Another system could be using a shared types server for that purpose.

Logical descriptions of the database

> The definitions of the database relvars, This concerns base relvars as well as virtual relvars, if the system supports the latter.

> The definitions of all constraints applicable to those relvars

Details of the security system

> Identity of the users who are allowed to access the system

> Details of the authentication procedures and credentials per user

> Details of who is allowed to do what on/to the database

Administrative data

> Statistics about data volumes and distribution of values used in the database

Details of the physical design of the database

> Storage volumes, locations of physical files, ...

> Inventory of data record types and indexes recorded in those files

> If storage is relegated to an underlying SQL system, connection details of that SQL engine

(Ab)Using the catalog

The mere fact of having information about physical implementation details recorded in the catalog, combined with the catalog having to be available for querying, by definition opens a backdoor to break said separation. It means that user programs, almost by definition, always have a means at their disposal to "introspect" into the physical details of the system they're working with. Maintaining the logical/physical separation is also a matter of the user not using the catalog for such purposes.

Updating the catalog

It is common for database systems to make the DBA use a separate language for the purpose of creating and maintaining the structure of databases. In such a scenario, "updating the catalog" is not an action performed directly by the DBA, but is in a sense merely a byproduct of the DBA using this DDL language. Not all systems work this way though, and it turns out to be perfectly possible to expose the catalog directly as an updateable database (updateable just like any other "regular" user database, that is).