Ein Schema definiert die Datenorganisation in einer Datenbank. Es legt Tabellen, Spalten, Datentypen, Einschränkungen und Beziehungen fest. Das Schema ist der Bauplan, die Datenbank das Gebäude. Ein gut gestaltetes Schema vereinfacht Abfragen und gewährleistet Datenkonsistenz. Ein schlecht gestaltetes Schema hingegen führt zu Problemen, die später schwer zu beheben sind. Änderungen am Schema nach der Datenverfügbarkeit erfordern Migrationen, die Anwendungen beeinträchtigen und Daten beschädigen können.

Schemata existieren auf verschiedenen Ebenen. Das konzeptionelle Schema beschreibt die Geschäftsobjekte und ihre Beziehungen. Das logische Schema fügt Details hinzu: Tabellen, Spalten und Schlüssel. Das physische Schema spezifiziert die Speicherung: Dateigruppen, Indizes und Partitionen. Jede Ebene dient einem anderen Zweck. Geschäftsanalysten verstehen das konzeptionelle Schema. Entwickler arbeiten mit dem logischen und physischen Schema. In manchen Datenbanken wird das Schema strikt durchgesetzt, in anderen ist es flexibel. Dokumentendatenbanken haben oft gar kein festgelegtes Schema. Die Anwendung definiert die Struktur. Diese Flexibilität beschleunigt die Entwicklung, verlagert aber die Verantwortung auf die Anwendung. Ohne Schema-Durchsetzung gelangen fehlerhafte Daten leicht hinein. Die Datenbank akzeptiert, was die Anwendung sendet. Ein Schema ist ein Vertrag. Es legt fest, wie die Daten aussehen und welchen Regeln sie folgen. Ein Verstoß gegen den Vertrag führt zum Verlust aller darauf basierenden Strukturen.

Schemakomponenten

• Tabellen – Entitäten im Datenmodell
• Spalten – Attribute mit Datentypen
• Schlüssel – Primär- und Fremdschlüssel
• Einschränkungen – Regeln für gültige Daten
• Indizes – Strukturen für die Abfrageleistung
• Ansichten – gespeicherte Abfragen, dargestellt als Tabellen

Ein Schema ist ein Plan. Ohne ihn ist die Datenbank ein unstrukturierter Datenhaufen.