A schema defines how data is organized in a database. It specifies tables, columns, data types, constraints, and relationships. The schema is the blueprint. The database is the building. A well-designed schema makes queries easy and data consistent. A poorly designed schema creates problems that are hard to fix later. Changing a schema after data exists requires migrations that can break applications and corrupt data.

Schemas exist at different levels. The conceptual schema describes the business entities and their relationships. The logical schema adds detail: tables, columns, and keys. The physical schema specifies storage: file groups, indexes, and partitions. Each level serves a different audience. Business analysts understand the conceptual schema. Developers work with the logical and physical ones. In some databases, the schema is enforced strictly. In others, it is flexible. Document databases often have no enforced schema at all. The application defines the structure. That flexibility speeds development but shifts responsibility to the application. Without schema enforcement, bad data enters easily. The database accepts whatever the application sends. A schema is a contract. It says what the data looks like and what rules it follows. Breaking the contract breaks everything built on it.

Schema components

• Tables — entities in the data model
• Columns — attributes with data types
• Keys — primary and foreign keys
• Constraints — rules for valid data
• Indexes — structures for query performance
• Views — saved queries presented as tables

A schema is a plan. Without it, the database is a pile of data with no structure.