Schema-Evolution

Jede größere Sammlung von Daten hat einen festen Bauplan. Er legt fest, welche Angaben es gibt und in welcher Form sie gespeichert werden. Bei einer Kundenliste könnte das heißen: Name als Text, Alter als ganze Zahl, Geburtsdatum als Datum. Diesen Bauplan nennt man Schema. Schema-Evolution ist die Frage, wie man ihn später ändert, obwohl schon Millionen Einträge existieren und Programme darauf zugreifen. Sie ist also kein Zustand, sondern ein Vorgang über Jahre hinweg.

Warum kein Bauplan für immer hält

Kein Team kennt am ersten Tag alle Angaben, die später gebraucht werden. Ein Onlineshop startet ohne Feld für die Handynummer und braucht es zwei Jahre später doch. Ein Gesetz verlangt plötzlich, dass man den Zeitpunkt einer Einwilligung speichert. Solche Änderungen sind der Normalfall, nicht die Ausnahme.

Das Heikle daran ist der laufende Betrieb. Man kann eine Datenbank mit Kundendaten nicht einfach für drei Tage abschalten. Ändert man das Schema unvorsichtig, brechen Programme ab oder lesen Werte falsch. Im schlimmsten Fall gehen Daten verloren, weil eine Spalte gelöscht wurde, die noch jemand brauchte. Deshalb gilt Schema-Evolution als eine der riskantesten Routineaufgaben in der Softwareentwicklung.

Für KI-Systeme kommt ein eigener Grund dazu. Modelle werden auf großen Datensammlungen trainiert, die über Jahre gewachsen sind. Wenn ein Feld auf halber Strecke seine Bedeutung ändert, lernt das Modell aus widersprüchlichem Material. Solche Fehler fallen oft erst auf, wenn die fertige KI seltsame Ergebnisse liefert.

Vorwärts und rückwärts kompatibel

Der zentrale Begriff heißt Kompatibilität. Rückwärtskompatibel ist eine Änderung, wenn neue Programme die alten Daten noch lesen können. Vorwärtskompatibel ist sie, wenn alte Programme mit den neuen Daten klarkommen, indem sie unbekannte Felder einfach ignorieren. Wer beides einhält, kann alte und neue Programmversionen gleichzeitig laufen lassen.

Aus dieser Regel folgen sehr praktische Faustregeln. Ein neues Feld hinzufügen ist meist harmlos, solange es einen Standardwert hat. Ein Feld löschen oder umbenennen ist gefährlich. Den Typ zu ändern, etwa von Text auf Zahl, gilt als besonders riskant. Deshalb benennt man Felder in der Praxis oft nicht um, sondern legt ein neues an und lässt das alte eine Weile mitlaufen.

Größere Umbauten laufen deshalb in Etappen. Zuerst wird das neue Feld angelegt und parallel befüllt. Dann stellen die Programme nacheinander auf das neue Feld um. Erst wenn nachweislich niemand mehr das alte liest, wird es entfernt. Datenformate wie Avro oder Protobuf und Tabellenformate wie Apache Iceberg unterstützen das, indem sie zu jedem Datensatz die Version des Schemas mitspeichern.

Wo Schema-Evolution im Alltag auftaucht

Sichtbar wird das Thema meist indirekt. Wenn eine App nach einem Update Daten nachlädt oder eine Bank ihr Onlinebanking über ein Wochenende abschaltet, steckt oft eine Schema-Änderung dahinter. Auch Meldungen über verzögerte IT-Projekte bei Behörden handeln häufig davon: Alte Datenbestände lassen sich nicht ohne Weiteres in ein neues Schema überführen.

In der Berufswelt begegnet man dem Begriff bei Werkzeugen für Datenbankmigrationen, etwa Flyway oder Liquibase. Sie verwalten Änderungen am Schema wie Programmcode, mit Versionsnummern und der Möglichkeit, einen Schritt zurückzunehmen. In Datenplattformen großer Firmen überwacht ein sogenannter Schema-Registry-Dienst, ob eine geplante Änderung die Kompatibilitätsregeln verletzt.

Ein häufiger Irrtum ist, dass moderne Systeme ohne festes Schema das Problem lösen. Manche Datenbanken erlauben es tatsächlich, beliebige Felder zu speichern. Die Struktur verschwindet damit aber nicht, sie wandert nur in den Programmcode. Dort ist sie schlechter dokumentiert und Fehler fallen später auf. Schema-Evolution wird also nicht überflüssig, sondern nur unsichtbarer.