Data Dictionaries, Repositories & Cloud (IaaS/PaaS/SaaS/DBaaS)

Where the database keeps its own metadata

Three related-but-distinct repositories of metadata complete the physical picture:

- A data dictionary documents the data elements of a database (table names, column types, lengths, keys, constraints) — the database's metadata. A passive data dictionary is maintained manually and can drift out of date (but may carry extra business context like definitions and stewardship). - A system catalog is a system-created database describing all database objects plus user-access information, maintained automatically by the DBMS — it is the active data dictionary, always consistent with the current structure and queryable via SQL (Postgres exposes it through information_schema and the pg_catalog views). - An information repository is far broader: it stores metadata about the organization's data and its data-processing resources, spanning the whole application portfolio and development environment (CASE-tool metadata, version control, configuration management) on top of the production catalog. Its engine supports five functions: object management, relationship management, dynamic extensibility, version management, and configuration management. A comprehensive repository is essential for data warehousing.

So the nesting is: data dictionary (one database's data elements) ⊆ system catalog (all objects + access, auto-maintained) ≪ information repository (the whole information-processing environment).

Where the database physically runs: the cloud

Cloud computing provisions computing services on demand from centralized resources over the public Internet or a private network, converting fixed infrastructure costs into variable usage fees. The service models differ in *who manages what* — more provider responsibility means less customer control:

- IaaS (Infrastructure-as-a-Service) — the provider supplies hardware + systems software (servers, storage, a DBMS); you still manage high availability, security, and DBMS updates. Most control, most management. - PaaS (Platform-as-a-Service) — adds tools/services above the infrastructure to boost development productivity; the provider handles infrastructure management. - DBaaS (Database-as-a-Service) — a PaaS specialized for the database platform; the provider handles configuration, patching, and disaster recovery, and you focus on schema and application design (e.g. Amazon RDS, Azure SQL). - SaaS (Software-as-a-Service) — a complete application; the provider manages everything beneath it. Least control, least management.

Worked example: classify a deployment

A team rents Postgres on Amazon RDS — they design tables, write queries, and tune indexes, but never touch the OS, never patch the engine, and let the provider handle backups and failover. That is DBaaS (a PaaS model). Had they instead rented a bare VM and *installed and patched* Postgres themselves, that would be IaaS: same database, but the management line sits in a different place — which is exactly what the service models are about.

The trade: cloud removes the up-front hardware investment, adds elasticity, and rents the provider's availability/security expertise — at the cost of ceding control of critical resources, vendor lock-in, dependence on the public Internet, and the difficulty of monitoring SLA compliance (the monitoring tools are usually the provider's own).