--- term: 'Datenbankschema' seoTitle: 'Was ist ein Datenbankschema? Vollständiger Leitfaden' headline: 'Was ist ein Datenbankschema?' slug: datenbankschema category: database shortDefinition: 'Ein Datenbankschema ist ein Bauplan, der festlegt, wie Daten organisiert sind – Klassen, Spalten, Typen und Beziehungen, aber nicht die Daten.' relatedTerms: - data-modeling - visual-database-management - class-level-permissions-clp - database-queries contrastsWith: - data-modeling faq: - question: 'Was ist ein Datenbankschema, einfach erklärt?' answer: 'Der Bauplan einer Datenbank: welche Tabellen oder Klassen existieren, welche Spalten sie haben, den Datentyp jeder Spalte, die Schlüssel und Constraints und wie Datensätze zueinander in Beziehung stehen. Es sind Metadaten – die Struktur, nicht die gespeicherten Daten. Ändern Sie das Schema, ändern Sie, welche Form Daten annehmen dürfen; die Daten selbst leben innerhalb dieser Form.' - question: 'Was ist der Unterschied zwischen Schema, Datenbank und Instanz?' answer: 'Drei Zoomstufen. Die Datenbank ist das ganze System – Engine plus gespeicherte Daten. Das Schema ist ihre formale Struktur, die sich selten und bewusst ändert. Eine Instanz sind die tatsächlichen Daten zu einem Zeitpunkt, die sich mit jedem Schreibvorgang ändern. Ein Schema, eine Datenbank, im Lauf der Zeit unendlich viele Instanzen.' - question: 'Was ist der Unterschied zwischen einem logischen und einem physischen Schema?' answer: 'Das logische Schema ist der Engine-unabhängige Entwurf: Entitäten, Attribute, Beziehungen, Constraints – das, was ein ER-Diagramm zeichnet. Das physische Schema ist, wie dieser Entwurf in einer bestimmten Engine landet: Speicherlayout, Indizes, Partitionen. Eine dritte Schicht, das View- oder externe Schema, legt fest, was jeder Konsument sieht. Derselbe Entwurf, drei Flughöhen.' - question: 'Was enthält ein Schema tatsächlich?' answer: 'Die Schemaobjekte: Tabellen oder Klassen, Spalten mit Datentypen, Primär- und Fremdschlüssel, Constraints wie NOT NULL, UNIQUE und CHECK, Indizes und Views. In manchen Engines hat "Schema" zusätzlich eine zweite Bedeutung – einen benannten Namespace, der diese Objekte gruppiert und Zugriffsberechtigungen trägt, und genau den legt CREATE SCHEMA an.' - question: 'Haben NoSQL-Datenbanken ein Schema?' answer: '"Schemalos" ist eine irreführende Bezeichnung – das Schema existiert immer; die Frage ist, wer es durchsetzt und wann. Relationale Engines arbeiten schema-on-write: Die Struktur wird geprüft, bevor Daten landen. Dokumentenspeicher arbeiten standardmäßig schema-on-read: Die Struktur lebt in den Erwartungen der Anwendung und wird erst bei der Nutzung geprüft. Die meisten Dokumentplattformen unterstützen inzwischen ebenfalls Validierung, womit Strenge zum Regler statt zur Entweder-oder-Frage wird.' - question: 'Was ist eine Schema-Migration?' answer: 'Eine versionierte, skriptgesteuerte Änderung am Schema – eine Spalte hinzufügen, einen Constraint verschärfen – schrittweise und in fester Reihenfolge über alle Umgebungen angewendet. Migrationen sind der Weg, auf dem Schemas sich ohne Chaos entwickeln: Jede Änderung ist überprüfbar, wiederholbar und umkehrbar, und die Schemaversion reist mit der Codebasis, die sie erwartet.' - question: 'Was sind Star- und Snowflake-Schemas?' answer: 'Schemaformen speziell für Analytik. Ein Star-Schema stellt eine zentrale Faktentabelle (Ereignisse, Verkäufe) in die Mitte denormalisierter Dimensionstabellen – wenige Joins, schnelle Aggregation. Ein Snowflake-Schema normalisiert diese Dimensionen in Untertabellen – weniger Redundanz, mehr Joins. Sie optimieren Reporting-Lasten und sind Verwandte, nicht Konkurrenten der transaktionalen Schemas, die Anwendungs-Backends verwenden.' - question: 'Wie definiert man ein Schema auf einem Backend as a Service?' answer: 'Auf zwei einander ergänzenden Wegen: visuell – Klassen und typisierte Spalten, die in einem Dashboard angelegt werden – und per Ableitung, bei der das Speichern des ersten Objekts die Klasse und die typisierten Spalten automatisch erzeugt, mit Standardfeldern wie objectId, createdAt, updatedAt und einer ACL, die die Plattform hinzufügt. Die Härtung für die Produktion friert es dann ein: clientgesteuerte Schemaänderungen aus, jede weitere Entwicklung bewusst über das Dashboard.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Database schema (Wikipedia)' url: 'https://en.wikipedia.org/wiki/Database_schema' - name: 'PostgreSQL — Data Definition documentation' url: 'https://www.postgresql.org/docs/current/ddl.html' - name: 'Introduction to database schemas — Prisma Data Guide' url: 'https://www.prisma.io/dataguide/intro/intro-to-schemas' - name: 'Back4app database hub documentation' url: 'https://www.back4app.com/docs' cta: title: 'Ein Schema, das Sie sehen können' text: 'Auf Back4app ist das Schema eine lebende Oberfläche: Legen Sie Klassen und typisierte Spalten im Dashboard an oder lassen Sie sie vom ersten Speichern ableiten, durchsuchen und entwickeln Sie alles visuell und sperren Sie es mit Berechtigungen auf Klassenebene ab, wenn Sie in Produktion gehen.' linkText: 'Kostenlos starten' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-23' translationKey: database-schema --- **Ein Datenbankschema ist ein Bauplan, der festlegt, wie Daten organisiert sind – Klassen, Spalten, Typen und Beziehungen, aber nicht die Daten.** Der Dreiklang in einer Zeile, den man sich merken sollte: Das *Schema* ist der Bauplan, eine *Instanz* sind die Daten zu einem Zeitpunkt, und die *Datenbank* ist das ganze Gebäude. Baupläne ändern sich selten und bewusst; die Räume füllen sich ständig neu. ## Das Wichtigste in Kürze | Frage | Antwort | | --- | --- | | Was es ist | Struktur als Metadaten: Tabellen/Klassen, typisierte Spalten, Schlüssel, Constraints | | Was es nicht ist | Die Daten – das ist die Instanz, die sich mit jedem Schreibvorgang ändert | | Die drei Flughöhen | Logisch (Entwurf) · physisch (Speicherung) · View (was jeder Konsument sieht) | | "Schemalos"? | Irreführend – schema-on-read verlagert die Durchsetzung nur auf die Abfragezeit | | Wie es sich entwickelt | Migrationen: versionierte, skriptgesteuerte, überprüfbare Änderungen | ## Der Bauplan, aufgeschrieben Ein Schema in seiner Muttersprache – zwei Tabellen, Schlüssel, ein Constraint, ein Index und eine View, also fast das gesamte Vokabular: ```sql CREATE TABLE users ( id bigserial PRIMARY KEY, email text NOT NULL UNIQUE, -- Constraint: keine Duplikate role text NOT NULL DEFAULT 'member' ); CREATE TABLE orders ( id bigserial PRIMARY KEY, user_id bigint NOT NULL REFERENCES users(id), -- Beziehung total numeric(10,2) CHECK (total >= 0), -- Regel, die die Daten einhalten müssen placed timestamptz NOT NULL DEFAULT now() ); CREATE INDEX orders_by_user ON orders (user_id, placed); -- physische Schicht CREATE VIEW recent_orders AS -- View-Schicht SELECT * FROM orders WHERE placed > now() - interval '30 days'; ``` Derselbe Bauplan wächst auf einer schemaflexiblen Plattform aus dem, was Sie speichern – typisierte Spalten, beim ersten Schreiben abgeleitet und sofort im Dashboard sichtbar: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // The schema grows typed columns from what you save const event = new Parse.Object('Event'); event.set('name', 'Launch day'); // String event.set('seats', 120); // Number event.set('startsAt', new Date('2026-09-01T18:00:00Z')); // Date event.set('venue', new Parse.GeoPoint(38.72, -9.14)); // GeoPoint await event.save(); // columns exist, typed, visible in the dashboard ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // The schema grows typed columns from what you save final event = ParseObject('Event') ..set('name', 'Launch day') // String ..set('seats', 120) // Number ..set('startsAt', DateTime.parse('2026-09-01T18:00:00Z')) // Date ..set('venue', ParseGeoPoint(latitude: 38.72, longitude: -9.14)); await event.save(); // columns exist, typed, visible in the dashboard ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // The schema is a typed struct — columns mirror the model struct Event: ParseObject { var objectId: String?; var createdAt: Date? var updatedAt: Date?; var ACL: ParseACL?; var originalData: Data? var name: String? // String column var seats: Int? // Number column var startsAt: Date? // Date column var venue: ParseGeoPoint? // GeoPoint column } var event = Event(); event.name = "Launch day"; event.seats = 120 event.save { _ in } // columns exist, typed, visible in the dashboard ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // The schema grows typed columns from what you save val event = ParseObject("Event").apply { put("name", "Launch day") // String put("seats", 120) // Number put("startsAt", Date()) // Date put("venue", ParseGeoPoint(38.72, -9.14)) // GeoPoint } event.saveInBackground() // columns exist, typed, visible in the dashboard ``` ## Logisch vs. physisch vs. View ```mermaid flowchart LR accTitle: Die drei Schemaschichten accDescr: Das logische Schema hält den Engine-unabhängigen Entwurf aus Entitäten und Beziehungen; das physische Schema bildet ihn mit Indizes und Partitionen auf den Speicher ab; View-Schemas stellen jedem Konsumenten einen zugeschnittenen Ausschnitt bereit. L["Logisches Schema
Entitäten · Beziehungen · Constraints
(das ER-Diagramm)"] P["Physisches Schema
Speicher · Indizes · Partitionen
(die Realität einer Engine)"] V["View-Schemas
zugeschnittene Ausschnitte pro Konsument"] L --> P --> V ``` | Unterscheidung | Dies | vs. das | | --- | --- | --- | | Schema vs. Instanz | Der Bauplan, ändert sich selten | Die Momentaufnahme der Daten, ändert sich ständig | | Logisch vs. physisch | Engine-unabhängiger Entwurf | Engine-spezifische Speicherentscheidungen | | Bauplan vs. Namespace | "Das Schema" Ihrer Anwendung | `CREATE SCHEMA` – ein benannter Objektbehälter mit Berechtigungen | | Schema-on-write vs. on-read | Geprüft, bevor Daten landen (relational) | Bei der Nutzung durchgesetzt (Standard bei Dokumenten) | | Transaktional vs. analytisch | Normalisierte Anwendungsschemas | Star-/Snowflake-Formen für Aggregation gebaut | Die dritte Zeile entschärft eine echte Mehrdeutigkeit, die die meisten Erklärungen überspringen: In manchen Engines benennt das Wort auch einen *Namespace* – einen Behälter für Tabellen mit Berechtigungen –, sodass "das Schema" den Bauplan Ihrer Anwendung oder einen Ordner innerhalb der Datenbank meinen kann, und der Kontext entscheidet. ## Schema-on-write vs. Schema-on-read "Schemalose" Datenbanken haben Schemas – sie stellen sie nur anders in Rechnung. **Schema-on-write** prüft die Struktur, bevor Daten landen: falscher Typ, fehlendes Feld, gebrochene Referenz – an der Tür abgewiesen. **Schema-on-read** nimmt Schreibvorgänge flexibel an und setzt die Erwartungen erst bei der Nutzung durch – schnellere Iteration, und jeder Leser wird zum Prüfer. Die moderne Position ist ein Regler, kein Krieg: Dokumentplattformen ergänzen Validierung, relationale Engines ergänzen JSON-Spalten, und verwaltete Backends teilen die Differenz – Typen werden pro Spalte abgeleitet und durchgesetzt, während neue Spalten ohne Migrationszeremonie entstehen. Die Frage nach der Strenge ist in Wahrheit eine Frage der Zuständigkeit: *Wer* findet den fehlerhaften Datensatz, die Datenbank beim Schreiben oder Ihr Code um 2 Uhr nachts? ## Wie Schemas sich entwickeln Der Bauplan überlebt seinen ersten Entwurf, und **Migrationen** sind der Weg, auf dem er sich ohne Chaos ändert: Jede Schemaänderung ist ein versioniertes Skript – Spalte hinzufügen, nachfüllen, Constraint verschärfen –, in fester Reihenfolge in jeder Umgebung angewendet und geprüft wie der Code, der davon abhängt. Zwei Disziplinen tragen den größten Teil des Werts: Machen Sie Änderungen *abwärtskompatibel* in dem Fenster, in dem alter und neuer Code nebeneinander laufen (hinzufügen, dann migrieren, dann entfernen – niemals an Ort und Stelle umbenennen), und halten Sie die Schemaversion im Repository, damit Code und Struktur gemeinsam reisen. Auf Dashboard-verwalteten Plattformen gilt dieselbe Disziplin mit anderem Werkzeug – entwickeln Sie visuell, aber bewusst, mit abgeschalteten clientgesteuerten Schemaänderungen in der Produktion. ## Typische Anwendungsfälle - **Ein neues Backend entwerfen.** Das Schema ist das Ergebnis der [Datenmodellierung](/glossary/de/datenmodellierung/): Entitäten und Kanten werden zu Klassen, Spalten und Schlüsseln. - **Integrität durchsetzen.** Constraints als ausführbare Regeln – nicht negative Summen, eindeutige E-Mail-Adressen – von der Engine abgefangen, nicht von Fehlerberichten. - **Vertrag im Team.** Das Schema ist das gemeinsame Vokabular von Backend, Frontend und Analytik; ein ER-Diagramm ist Dokumentation, die nicht abdriften kann. - **Fundament für Performance.** Indizes und physisches Layout – das untere Stockwerk des Schemas – entscheiden, welche Abfragen bei Wachstum schnell bleiben. - **Sicherheitsfläche.** Berechtigungen auf Schemaebene regeln, wer pro Klasse was darf – Struktur und Zugriffskontrolle an einem Ort. ## Wie streng sollte Ihr Schema sein? Eine Entscheidungsmatrix | Wählen Sie streng (schema-on-write), wenn… | Wählen Sie flexibel (ableiten + prüfen), wenn… | | --- | --- | | Datenfehler teuer sind (Geld, Bestand) | Sie wöchentlich am Produkt iterieren | | Viele schreiben, ein Vertrag gilt | Ein Team Code und Daten zugleich verantwortet | | Analytik von stabilen Spalten abhängt | Felder tatsächlich pro Datensatz variieren | | Constraints Geschäftsregeln codieren | Regeln ohnehin in serverseitiger Validierung leben | | Migrationen für das Team Routine sind | Migrationszeremonie das Erkunden bremsen würde | Der pragmatische Standard für Anwendungs-Backends: flexibel, solange Sie lernen, gehärtet zum Livegang – leiten Sie das Schema während der Entwicklung ab und frieren Sie es dann ein (keine Schemaänderungen vom Client, Feld-Hinzufügen aus), sobald echte Benutzer kommen. ## Grenzen und Trade-offs - **Das Schema friert Annahmen ein.** Jede Entscheidung über Spaltentyp und Kardinalität ist heute billig und morgen eine Migration – entwerfen Sie für die nächstgrößere Stufe. - **Strenge kostet Iterationstempo.** Jedes Experiment zahlt den Migrationszoll; das ist der Preis der Garantien, kein Mangel. - **Flexibilität kostet die Leser.** Schema-on-read verlagert die Prüfung in jeden Konsumenten; ohne Disziplin wird aus "flexibel" schnell "fünf Formen desselben Datensatzes". - **Die physische Schicht ist unsichtbar, bis sie es nicht mehr ist.** Indizes und Layout ändern nichts an der Korrektheit – nur daran, ob Abfragen Wachstum überstehen. - **Berechtigungen auf Namespace-Ebene sind kein Entwurf.** `CREATE SCHEMA` ordnet Objekte und schirmt sie ab; den Bauplan macht es dadurch nicht gut. ## Das Schema mit Back4app Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Das Schema ist hier eine erstklassige, sichtbare Oberfläche: Definieren Sie Klassen und typisierte Spalten im Dashboard, oder lassen Sie sie vom ersten Speichern ableiten – die Code-Tabs oben legen echte typisierte Spalten an, mit `objectId`, `createdAt`, `updatedAt` und einer ACL, die jede Klasse standardmäßig erhält. Alles, was das Schema deklariert, spiegelt sich sofort in den [automatisch generierten APIs](/glossary/de/automatisch-generierte-apis/), wird von [Berechtigungen auf Klassenebene](/glossary/de/klassenberechtigungen-clp/) bewacht und ist im [visuellen Dashboard](/glossary/visual-database-management/) durchsuchbar – Bauplan, Durchsetzung und Dokumentation als ein einziges Artefakt.