In den vorangegangenen Blog-Beiträgen haben wir festgestellt, dass „in der schönen neuen Welt der Datenmodellierung“ das Datenbank-Schema vom konzeptionellen Schema kaum mehr zu unterscheiden ist. Jede Entität ist eine Tabelle, Denormalisierungen finden nicht statt, horizontales und vertikales Splitting ist erledigt.

Bleibt nun das mächtige Konstrukt der Generalisierung vs. Spezialisierung  in der Datenmodellierung zu betrachten.

In dem Blogeintrag „Sind relationale Datenbanken ein alter Hut oder wie sieht Datenmodellierung heute aus?“ wurde die Trennung der Datenmodellierung in die Schichten nach ANSI diskutiert. Wir waren der Meinung, dass der Übergang vom konzeptionellen Schema in das Datenbank-Schema in vielen Fällen automatisch „in einem Guss“ erfolgen kann.

Aber wofür ist diese Trennung der Datenmodellierung eigentlich gut?

Relationale Datenbanken gibt es nun schon seit gefühlten Ewigkeiten, da stellt sich manchmal die Frage, ob sich bei der Datenmodellierung eigentlich noch was Neues tut, oder ob das alles „ein alter Hut“ ist. In diesem Beitrag wird deshalb geklärt, was bei der Datenmodellierung eigentlich zu tun ist und ob relationale Datenbanken  noch zeitgemäß sind.

Beim Aufbau und später auch beim Betrieb eines Data Warehouse Systems hat ein OLAP Modell verschiedene Vorteile. Zum einen bietet ein Modell einen guten Überblick über die oft große Anzahl an Elementen und deren Zusammenhänge, zum anderen ist es eine gute Basis für die Kommunikation mit den Fachbereichen.

Übersicht für Data Warehouse und BI
Im Gespräch mit Kunden über unsere BI-Lösungen begegne ich häufig dem gleichen Phänomen. Es besteht ein großer Wunsch nach Übersicht über die komplette BI-Lösung. Nicht nur über die Datenmodelle, das ist unstrittig. Sondern vielmehr bei Modellen zur Datengenese. Liegt hier doch ein wesentlicher Teil komplexer Logik, dessen Verständnis sich direkt auf die Lebensdauer der Lösung auswirkt. Je besser die Logik der ETL- bzw. ELT-Prozesse verstanden ist, desto länger braucht es, bis ein Re-Design nötig wird. Gleichzeitig besteht eine gewisse Furcht vor Mehraufwänden. Der Wunsch nach Übersichtlichkeit steht in direktem Konflikt mit den knappen Ressourcen. So stehen viele BI-Verantwortliche vor dem Dilemma, entweder heute mehr zu investieren oder später die komplette Lösung neu bauen zu müssen.

Das ist eine schwierige Entscheidung, die zu fällen sich vermeiden lässt. Ein gutes Modell für Data Warehouse und BI muss mehr bieten als nur die Übersicht. Es muss gleichzeitig auch seinen Teil zum Entwicklungsfortschritt beitragen. Das Modell ist somit nicht nur Selbstzweck, wird das Modell weggelassen, ist auch der nächste Schritt mehr Aufwand.  Wenn wir ein Datenmodell erstellen, erhalten wir neben der Übersicht auch die DDL für das Datenbankschema. Ohne Modell müssen wir es von Hand pflegen.

Um die Verwendung und Verfolgung von Attributen über die verschiedenen Ebenen einer Data Warehouse Infrastruktur zu ermöglichen, ist Data Lineage als Konzept in Business Intelligence Systemen unabdingbar. Ausgehend von den Attributen des fachlichen Datenmodells über die Spalten des physischen Datenbankmodells der operativen Systeme werden die Informationen von der Ladeschicht, über die Data Warehouse Schicht bis zur Data Mart Schicht per Data Lineage verfolgt. Diese Konzepte und Mechanismen und die Anforderungen an eine Werkzeugunterstützung lassen sich nahezu 1:1 auf die Traceability-Anforderungen eines Requirements Engineering & Management anwenden.

Liebe Freunde der MID,