Das Intuitive Datenmodell I

Ich möchte ein neues Datenmodell vorschlagen. Eines, das sich radikal von denen unterscheidet, die Sie täglich in der Softwareentwicklung einsetzen.

Ich möchte ein Datenmodell vorschlagen, dass nur noch Werte kennt und keine Referenzen mehr zwischen diesen Werte. Diese konzeptionelle Reduktion macht es ohne Verlust an breiter Einsetzbarkeit in vielen Fällen einfacher zu handhaben als andere Datenmodelle, eröffnet darüber hinaus aber auch ganz neue Perspektiven auf den Umgang mit Daten.

Motivation
Sie haben das Objektorientierte Datenmodell verinnerlicht, denken täglich in den Bahnen des Relationalen Datenmodells, jonglieren mit XML und haben bestimmt auch von anderen (persistenten) Datenmodellen [1,2] gehört wie dem Hierarchischen oder gar dem Assoziativen Datenmodell.

Diese Datenmodelle haben natürlich alle ihre Berechtigung. Jedes versucht auf seine Weise das Problem zu lösen, Datenzusammenhänge der realen Welt für Software bearbeitbar zu machen. Und das leisten sie grundsätzlich auch.

Sind die existierenden Datenmodelle deshalb aber perfekt? Könnte die Datenmodellierung nicht für manche oder gar viele Fälle einfacher oder flexibler sein? Ich glaube, ja. Ich glaube, wir sind schon so sehr gerade in die Mainstream-Datenmodelle eingetaucht, dass wir den Schmerz, den sie uns manchmal bereiten, nicht mehr spüren. Sie sind ja auch zumindest so leistungsfähig, dass wir am Ende irgendwie alle Datenmodellierungsprobleme lösen. War das dann allerdings so einfach, wie es hätte sein können?

Gewöhnlich beantworten Sie diese Frage von einem Standpunkt innerhalb der Menge der existierenden Datenmodelle. Sie überlegen, ob Sie ein Datenschema mit den vorhandenen Mitteln, den Konzepten des gewählten Datenmodells, auch wirklich gut entworfen haben – oder ob vielleicht ein anderes der verfügbaren Datenmodelle etwas geeigneter gewesen wäre.

Eine verständliche Haltung und die allermeiste Zeit können wir uns auch keine andere leisten. Wir müssen mit den Werkzeugen leben, die wir haben.

Wenn die Antworten dann aber immer wieder schwer fallen, wenn sie immer wieder lauten, „Ja, ich habe es so gut gemacht, wie es das Datenmodell erlaubt, aber irgendwie ist das Ergebnis trotzdem unbefriedigend“, dann kann es Zeit sein, den Standpunkt zu wechseln und über den Tellerrand zu schauen.

Solche Antworten sind es nun, die mich angetrieben haben, über die existierenden Datenmodelle hinaus zu denken. Trotz oder wegen aller Vertrautheit mit der Objektorientierung, RDBMS und XML bin ich immer wieder in Situationen geraten, wo ich diese Datenmodelle als umständlich oder beschränkend empfunden habe. Der Grund: sie leiden alle am selben Problem.

Die Container-Referenz-Dichotomy als Grundproblem
Die existierenden Datenmodelle [1,2] basieren alle auf einer grundlegenden Dichotomie, der zwischen Containern und Referenzen. Sie sind die wiederkehrenden, fundamentalen Konzepte aller Datenmodelle.

Egal, ob Sie objektorientiert oder relation modellieren, Sie müssen sich immer wieder dieselbe Frage stellen: Fasse ich diese und jene Daten zusammen in einen Container oder soll ich sie lieber auf verschiedene Container aufteilen und dann die Container einander referenzieren lassen?

Sind die Container Objekte oder Datensätze? Heißen die Referenzen Objektvariable oder Fremdschlüssel? Das sind Feinheiten. Ihre Frage ist trotzdem dieselbe. Und sie ist nicht leicht zu beantworten, denn eine Entscheidung hat weitreichende Folgen:

• Ob Daten zusammen im selben Container liegen oder nur über Referenzen verbunden sind, hat Einfluss auf die Form des Codes zur Speicherung und zur Abfrage. Das hat wiederum Auswirkung auf die Performance.


• Ob Daten heute zusammen mit anderen in einem Container liegen oder für sich allein, hat Auswirkungen darauf, wie Sie morgen Bezug auf sie nehmen können. Um Daten in neue Zusammenhänge stellen zu können, müssen sie auf den Punkt referenzierbar sein; das sind sie aber nur, wenn sie allein in einem Container stehen. Ihre Entscheidungen für Container und Referenzen haben also Auswirkungen auf die Flexibilität Ihres Datenmodells.

Zur immer wieder zu fällenden Entscheidung zwischen Container und Referenz tritt eine Beschränkung der Schachtelung von Containern. Sie können Daten in Felder/Spalten stecken, die dann zu Klassen/Tabellen zusammenfassen… und das war´s. Sollten Daten in der Realität jedoch in tieferen Hierarchien stecken, dann müssen Sie sie „flachklopfen“, um sie mit den existierenden Datenmodellen abzubilden. Nur XML macht hier eine Ausnahme, hat aber nicht den Stellenwert als Datenmodell, den Objektorientiertes oder Relationales haben.

Bei aller Liebe zu den Mainstream-Datenmodellen empfinde ich sie also zunehmend als beschränkend und umständlich. Sie sind leistungsfähig und etabliert… aber für bestimmte Anwendungsfälle scheinen sie mir inzwischen unzeitgemäß:

• Für eine Softwarewelt, in dem immer mehr flexibel und dynamisch passieren soll – die dynamischen Sprachen wie Ruby oder Python sind dafür nur ein Beisiel –, sind ihre Schemata zu starr.
  
• Für eine Softwarewelt, in der immer mehr ad hoc entwickelt werden soll, weil keine Zeit für lange Planung ist, sind ihre Schemata zu schwer zu entwerfen. Entscheidungen über Datennormalisierung können nur von Fachleuten getroffen werden; der Poweruser ist überfordert.
  
• Für eine Softwarewelt, in der es immer mehr gilt, „Wissen“ aus schon Vorhandenem zu heben (Datamining), bieten existierende Datenmodelle zuwenig Hilfe bei der Vermeidung oder Auflösung von Dateninseln.

Soweit die Probleme mit heutigen Datenmodellen aus meiner Sicht. Verstehen Sie, warum ich mich motiviert gefühlt habe, nach einer Alternative bzw. Ergänzung zu suchen? Gefunden habe ich dann schließlich einen Ansatz, den ich das Intuitive Datenmodell nennen möchte.

Davon mehr im nächsten Artikel dieser Serie.

Ressourcen
[1] UnixSpace, Database Models, http://unixspace.com/context/databases.html
[2] Mike Prestwood, An Introduction to Object Orientation, http://www.prestwood.com/ASPSuite/KB/document_view.asp?qid=100137