Meine Datenbank gehört mir!

Inhaltsverzeichnis

Datenbanken gemeinsam zu nutzen erscheint sinnvoll – schließlich sind Daten das neue Öl. Das widerspricht aber einer wesentlichen Grundlage für moderne Softwareentwicklung – der Modularisierung.

Wenn man objektorientierte Klassen als einzige Module für ein System annimmt, entstehen jedoch schnell Probleme. Nehmen wir an, ein System hätte eine Million Zeilen Code (Lines of Code, LoC). Eine Klasse mit 1000 LoC wäre schon recht groß – aber selbst dann hätte das System 1000 Module. Also sind grobgranularere Module als Klassen notwendig. Microservices können solche grobgranularen Module sein. Oder einige Klassen werden zu einem Modul zusammengefasst. Die Schnittstelle eines solchen Moduls kann eine einzelne Fassade-Klasse bilden, sodass die Interna versteckt sind. Es gibt viele weitere Möglichkeiten, grobgranulare Module umzusetzen – beispielsweise als Bibliotheken oder mit Modulkonzepten der jeweiligen Programmiersprachen.

Bei der Definition des Begriffs "Modul" hat David Parnas eine wichtige Rolle gespielt. Ein wesentliches Paper in diesem Zusammenhang ist "Information Distribution Aspects of Design Methodology" von 1971. Darin argumentiert er, dass ein guter Entwickler alle Informationen über ein Modul, die ihm zur Verfügung stehen, bei der Implementierung seines eigenen Codes nutzen wird. Sein Code trifft also Annahmen darüber, wie andere Module umgesetzt sind. Je mehr solcher Annahmen er über den Code trifft, desto schwieriger wird es, die benutzten Module zu ändern. Sie müssen schließlich alle Annahmen auch weiterhin erfüllen. Um Module änderbar zu halten, muss man also möglichst wenig Informationen über die Module nach außen geben, sodass nur wenige Annahmen bei der Nutzung getroffen werden können. Man spricht von "Information Hiding" – dem Verstecken von Informationen.

Information Hiding

Zu dem Zeitpunkt, als Parnas das Paper geschrieben hat, sind Informationen vor allem über Dokumentation verbreitet worden. Das Paper argumentiert außerdem, dass bestimmte Entscheidungen nur innerhalb eines Moduls erkennbar sein sollen. Dazu zählt die Art und Weise, im jeweiligen Modul bekannt sein sollte,wie ein Modul Daten speichert.

Heute ist Information Hiding der Grund, warum objektorientierte Klassen Instanzvariablen nicht nach außen exponieren, sondern verbergen. So kann eine Klasse die Implementierung der Datenspeicherung ändern, da keine Informationen über diese nach außen dringen.

Module haben keine gemeinsame Datenbank!

Information Hiding für solche grobgranulareren Module kann nicht bedeuten, dass Instanzvariablen versteckt werden. Schließlich bestehen sie aus mehreren Klassen. Information Hiding, das auf Klassen beschränkt ist, macht also in diesem Kontext keinen Sinn.

Grobgranulare Module speichern typischerweise Daten in der Datenbank. Daher kann man aus Information Hiding ableiten, dass grobgranulare Module wie Microservices ihr eigenes Datenbankschema haben sollten, weil sonst andere Module direkt auf die Datenbankschema zugreifen und so Annahmen über die Datenspeicherung in der Datenbank treffen. Das schränkt die Änderbarkeit der Datenmodellierung erheblich ein. Wie also Klassen keine Instanzvariablen exponieren dürfen, sollten grobgranulare Module keine Datenbankschemata exponieren. Auch Kopplung über Datenbankmechanismen wie Views führen oft zu einer engen Kopplung und denselben Problemen.

Leider wird diese Regel oft nicht eingehalten. Das führt zu großen Datenbankschemata, weil die Anforderungen mehrerer Module zu erfüllen sind. Außerdem sind die Schemata oft kaum änderbar, weil zu viele Module beeinflusst werden. Meiner Erfahrung nach gibt es viel zu viele Systeme, bei denen die Datenbankschemata viel zu komplex sind und Änderungen am System wie auch an der Datenbank de facto unmöglich machen – oft versteht auch niemand das System mehr.

Dabei lässt sich eigentlich aus der Definition von Modulen schon ablesen, dass Datenspeicherung in Modulen versteckt sein sollte. Information Hiding auf dieser Ebene durchzusetzen und so zu änderbaren und verständlichen Datenmodellen zu kommen, hat meiner Meinung nach ein erhebliches Potenzial, die Entwicklung komplexer Projekte erheblich zu vereinfachen.

tl;dr

Systeme sollten in grobgranulare Module mit getrennten Datenbankschemata aufgeteilt werden. Die gemeinsame Nutzung von Datenbankschemata ist ein Hauptgrund für die mangelnde Änderbarkeit vieler Systeme und vieler Datenbankschemata.

PS: Danke an die innoQ-Kollegen Jan Friderici, Stefan Tilkov und Michael Vitz für die Diskussion über eine frühe Version des Blog-Post! ()