Database Schema: Definition, drei Ebenen, Bausteine

Ein Database Schema (Datenbankschema) ist der Bauplan einer Datenbank. Es hält fest, welche Tabellen es gibt, welche Spalten darin stehen, wie die Tabellen über Schlüssel (feste Verweise zwischen Datensätzen) miteinander verbunden sind und welche Regeln die Daten einhalten müssen. Der Begriff meint im Alltag zwei verwandte Dinge: den Bauplan der Datenstruktur und, im SQL-Standard, einen benannten Ordner im Datenbanksystem, in dem Tabellen abgelegt werden.

Was ist ein Database Schema?

Ein Database Schema beschreibt den Aufbau einer Datenbank in einer formalen Sprache. Es legt drei Dinge fest. Erstens den Aufbau: welche Tabellen und Views (gespeicherte Abfragen, die wie eine Tabelle aussehen) existieren und welche Spalten sie tragen. Zweitens die Datentypen und Vorgabewerte pro Spalte, also ob dort eine Zahl, ein Text oder ein Datum steht. Drittens die Verbindungen und Regeln: Primärschlüssel (die eindeutige Kennung eines Datensatzes) und Fremdschlüssel (der Verweis auf einen Datensatz in einer anderen Tabelle) legen die Beziehungen fest, sogenannte Constraints (verbindliche Prüfregeln wie Not Null, Unique, Check) sorgen dafür, dass die Daten sauber bleiben. In klassischen SQL-Datenbanken ist das Schema der Vertrag, an dem Anwendungen, Reports und Datenprodukte hängen.

Die kanonische Gliederung folgt der ANSI/SPARC-Drei-Schichten-Architektur (1975) und trennt drei Ebenen. Das konzeptionelle Schema beschreibt die Fachdomäne in Entitäten und Beziehungen, unabhängig von einer konkreten Technologie; typische Notation ist das Entity-Relationship-Diagramm nach [Peter Chen (1976)](https://dl.acm.org/doi/10.1145/320434.320440). Das logische Schema verfeinert das Bild mit vollständigen Attributen, Primär- und Fremdschlüsseln sowie Kardinalitäten; hier fällt die Muster-Entscheidung zwischen Normalisierung nach [Codd (1970)](https://dl.acm.org/doi/10.1145/362384.362685) und dimensionaler Modellierung nach Kimball. Das physische Schema setzt das logische Modell in einer konkreten Ziel-Datenbank um: DDL, Datentypen, Indizes, Partitionierung, Storage-Layout. Auf einem Lakehouse fließen an dieser Stelle Delta- oder Iceberg-spezifische Physik-Entscheidungen ein (Liquid Clustering, Column Mapping, Deletion Vectors).

Der Begriff hat im SQL-Standard ([ISO/IEC 9075](https://www.iso.org/standard/76583.html)) eine zweite, engere Bedeutung: ein SCHEMA ist dort ein benannter Container für Tabellen, Views, Sequenzen und Prozeduren. In Postgres, DB2 und Oracle wird das Schema mit CREATE SCHEMA angelegt und mit einem Owner versehen; in Databricks Unity Catalog liegt es als mittlere Ebene im Dreischritt catalog.schema.table und trägt Berechtigungen und Metadaten. Diese Namespace-Bedeutung wird im deutschsprachigen Sprachgebrauch häufig mit der strukturellen Bedeutung vermischt; beide Bedeutungen existieren nebeneinander und sollten im Gespräch getrennt werden.

Historisch reicht der Begriff vom Netzwerkmodell (Bachman, 1969) über das relationale Modell (Codd, 1970) und die ANSI/SPARC-Architektur (1975) bis zu den heutigen Lakehouse-Formaten mit versionierter Schema-Evolution. Der Kern hat sich nicht verändert: ein Database Schema fixiert, wie Daten strukturiert sind, damit Anwendungen, Anfragen und Governance sich darauf verlassen können.

Abgrenzung zu Data Modeling, Modell-Mustern und Namespace-Schema

Database Schema wird im Alltag oft mit benachbarten Begriffen gleichgesetzt oder auf ein einzelnes Modellierungs-Muster verkürzt. Die folgende Tabelle sortiert die Beziehungen.

Begriff	Verhältnis zum Database Schema	Kernunterschied
[Data Modeling](/insights/glossar/data-modeling/)	Disziplin, die das Schema erzeugt	Data Modeling entwirft das Modell auf drei Ebenen, das Database Schema ist das physische Artefakt der Umsetzung.
Star-Schema, Snowflake-Schema, [Data Vault](/insights/glossar/data-vault/)	Modell-Muster für den analytischen Bereich	Ausprägungen der dimensionalen oder auditierbaren Modellierung. Ein Star-Schema ist ein Database Schema mit einer bestimmten Struktur (Fakten + Dimensionen), keine eigenständige Kategorie daneben.
Schema als SQL-SCHEMA (Namespace)	Container-Objekt im DBMS	Benannter Namensraum für Tabellen, Views und Sequenzen. Trägt Berechtigungen und Ownership, beschreibt aber nicht die Struktur der Tabellen darin.
DDL / Migrations-Skript	Syntax und Diff-Artefakt	DDL ist die Sprache zur Definition, Migrations-Skripte sind die versionierten Übergänge zwischen zwei Schema-Ständen. Das Schema selbst ist der Zustand.
JSON-, Avro-, Protobuf-Schema	Serialisierungs-Schema	Beschreibt das Layout einer einzelnen Nachricht oder Datei mit Kompatibilitätsregeln, meist in einer Schema-Registry. Verwandter Begriff, aber nicht das Datenbank-Schema.

Zwei Trennlinien sind für die Einordnung besonders wichtig. Die erste liegt zwischen dem Database Schema als Struktur-Beschreibung und dem SQL-SCHEMA als Namespace-Container. In einem Unity-Catalog-Setup ist analytics_gold ein Namespace-Schema (Ebene zwischen Catalog und Table), während die Struktur der Fakten- und Dimensionstabellen darin das eigentliche Database Schema bildet. Die zweite Trennlinie liegt zwischen dem Schema und einem einzelnen Muster: Aussagen wie „Modellierung im Star-Schema" oder „Data-Vault-Ansatz" bezeichnen eine Muster-Wahl auf der logischen Ebene und decken den Begriff nur ausschnitthaft ab.

Beispiel: Gold-Layer eines Lakehouse

Ein DACH-Handelsunternehmen betreibt ein [Data Lakehouse](/insights/lakehouse/data-modeling/) auf Databricks und modelliert den Gold-Layer für Reporting und Self-Service-BI. Das Database Schema entsteht auf allen drei Ebenen und wird sauber getrennt vom Namespace-Schema geführt.

Auf der konzeptionellen Ebene liegt ein ER-Diagramm mit den Entitäten Kunde, Bestellung, Position, Produkt und Zeit. Auf der logischen Ebene folgt die Entscheidung für ein Star-Schema mit der Faktentabelle fact_orders und den Dimensionen dim_customer, dim_product und dim_time. Primärschlüssel sind fachlich stabile Surrogate, Fremdschlüssel verbinden die Fakten mit den Dimensionen, dim_customer ist als [Slowly Changing Dimension](/insights/lakehouse/data-modeling/scd/) Type 2 mit Effective- und End-Date modelliert. Datentypen, Not-Null-Regeln und Default-Werte sind auf dieser Ebene definiert.

Auf der physischen Ebene wird das Schema als Delta-Tabellen im Unity-Catalog-Namespace sales.analytics_gold angelegt. fact_orders trägt Liquid Clustering auf order_date und customer_id, Foreign Keys sind als informative Constraints registriert und liefern dem Query-Optimizer und dem Semantik-Layer Metadaten. Deletion Vectors ermöglichen zeilenweises Löschen für DSGVO-Anfragen. Schema-Evolution (neue Spalten, geänderte Typen) läuft versioniert über dbt-Modelle im Git-Repository; jeder Change ist als Migration nachvollziehbar. Der Dreischritt sales.analytics_gold.fact_orders benennt eindeutig Catalog, Namespace-Schema und Tabelle.

Das gleiche Modell erscheint auf der konzeptionellen Ebene als ER-Diagramm, auf der logischen Ebene als Star-Schema und auf der physischen Ebene als DDL im Delta-Format. Muster-Wahl (Star-Schema), Namespace-Wahl (analytics_gold) und Physik-Entscheidungen (Liquid Clustering, SCD2, Deletion Vectors) bilden zusammen das Database Schema des Gold-Layers.