Database Schema

A schema is the constitution of a database: the formal definition of what data exists, what type each piece is, and the rules that govern how it relates. Change it casually and every system built on it feels the tremor; design it well and years of software stand on it uncomplaining. Most expensive data problems are, at root, schema problems.

What It Is

A database schema defines the structure of stored data: tables (or collections), the columns and their types, the constraints (what must be present, what must be unique, what format), the relationships and keys connecting tables, and the indexes that make access fast. It is the contract between the database and every program using it — and like all contracts, changing it after the fact is expensive: schema migrations (see separate entry) must transform both structure and, often, the data itself, while the system keeps running. Schema design is where data integrity is won or lost: constraints enforced by the schema are guaranteed; integrity left to application code is hoped for.

Why It Matters to You

Executives meet the schema at the moments that matter: in due diligence (a well-designed schema maps recognisably to the business — you can see patients, orders, consents; an arbitrary one means the data model never understood the domain), in integration (two systems exchange data at the boundary of their schemas — every mismatch is mapping work forever), and in governance (reporting, retention and deletion obligations under PDPA and its cousins are only enforceable when the data's structure makes them expressible). The question that never hurts: 'show me the main tables' — comprehensibility is a quality signal in itself.

When You'll Meet It

In system due diligence, integration projects, and data-governance reviews. If the schema cannot be explained to you in ten minutes, that is a finding, not a failure of your attention.