Inmon vs. Kimball: Eine Überprüfung der Unterschiede in analytischen Perspektiven

Teilen Sie dies…Facebook Facebook

Facebook

Pinterest

Twitter

Linkedin

Die Welt der Daten und Analysen entwickelt sich ständig weiter. In den einfacheren Tagen bestand die typische Datenorganisation aus einigen Dateien, Anwendungs- oder Transaktionsdatenbanken, Data Warehouses und Reporting-Data-Marts. Da Datenquellen, Volumen, Generierungsgeschwindigkeiten und der Erfassungsprozess im Laufe der Jahre gewachsen sind, muss sich die heutige Computerumgebung mit extrem großen Datensätzen befassen – allgemein als ‚Big Data‘ bezeichnet –, die Muster, Trends und mehr aufdecken, auf denen Organisationen Entscheidungen treffen können.

Die meisten Unternehmen verfügen heute über viele, wenn nicht sogar alle Komponenten, die in der in Abbildung 1 dargestellten Referenzarchitektur hervorgehoben sind – Anwendungen, Systeme und Quellen, Datenübertragung, Unternehmensdatenschicht, Datendienste, Analysen und Berichte sowie erweiterte Datenverarbeitung.

Abbildung 1 – Komplexe Referenzarchitektur

Da Data Warehouse und Marts als eine von 28 möglichen Komponenten dargestellt werden, ist es auf den ersten Blick schwierig zu verstehen, wie sie in das Bild passen. Die meisten Unternehmen beschäftigen sich derzeit jedoch mit mehr als einem Data Warehouse – sie müssen eine komplexe Umgebung wie die in Abbildung 1 dargestellte zusammenhängend verwalten.

Kimball- und Inmon-Architekturen bieten Frameworks, die bei der Entwicklung komplexer Referenzarchitekturen helfen.

Kurze Auffrischung der beiden Ansätze

Bevor Sie die Kimball- oder Inmon-Muster anwenden, sollten Sie die Unterschiede zwischen den beiden Ansätzen überprüfen. Überprüfen Sie die visuellen Darstellungen der einzelnen in Abbildung 21 und Abbildung 32 .

Die Arbeit von Kimball und Inmon – den Gründern der jeweiligen Modelle – forderte sich gegenseitig heraus. Während beide Ansätze überwiegend vom Entwicklungszyklus eines Datenmodells bestimmt werden, basieren die Modelle auf einem zielgerichteten Fokus entweder eines Bottom-up- oder eines Top-Down-Ansatzes. Diese Spannungen spielten sich bei der Entwicklung der gesamten Datenspeicher- und Analyseumgebungen ab.

Abbildung 2 – Visual Kimball

Abbildung 3 – Visuelle Inmon-Ansicht

Der Kimball-Ansatz zeigt an, dass Data Warehouses und Data Marts von Geschäftsprozessen und Geschäftsfragen bestimmt werden. Die offensichtliche Gefahr besteht darin, dass nützliche Daten nicht unbedingt kategorisiert oder erfasst werden müssen, da sie nicht in den zu definierenden Geschäftsprozess passen.

Der Inmon-Ansatz bezeichnet die Erstellung eines Enterprise Data Warehouse mit logischen Modellen, die für jede Entität rund um ein Thema entwickelt wurden, z. B. Zähler, Rechnung und Asset. Die Herausforderung besteht darin, dass die Hauptthemen zwar eine Differenzierung darstellen können, die sie unterstützenden Einheiten jedoch Gemeinsamkeiten darstellen können, die verloren gehen können.

Beispielsweise können der Standort eines Zählers, wie er durch einen Servicestandort dargestellt wird, die Rechnungsadresse, die in der Rechnung dargestellt wird, und der Bestands- oder Bereitstellungsort eines Assets gemeinsame Attribute aufweisen. Selbst unter Inmon besteht die Gefahr, dass der Servicestandort, die Rechnungsadresse, das Asset, der Inventarstandort und der Asset-Bereitstellungsstandort als fünf verschiedene Objekte dargestellt werden, da davon ausgegangen wird, dass sie verschiedene Branchen in der Organisation mit unterschiedlichen Data Marts unterstützen.

Sowohl der Inmon- als auch der Kimball-Ansatz werden von dem Zyklus angetrieben, das konzeptionelle Datenmodell zu entwickeln und dann die Datenmodelle in einer physischen Form zu implementieren. Dieser Zyklus kann agilere Entwicklungsansätze unterstützen, wird jedoch aufgrund der Linearität der Forschung (basierend auf dem Prozess- oder Unternehmensthema), der Entwicklung des konzeptionellen Modells (basierend auf den Daten) am ehesten mit einem wasserfallartigen Entwicklungsansatz übereinstimmen im Prozess oder im Unternehmensthema) und die Entwicklung des physischen Modells.

Der nächste Schritt

Ein agiler Prozess könnte es schwierig machen, Zyklen in diese Art von Entwicklungsaktivität zu injizieren. Die Herausforderung für jede Organisation wird darin bestehen, die Lehren aus den Ansätzen von Inmon und Kimball zu ziehen und sie in einem neuen Kontext anzuwenden.

Weitere Details zur Anwendung der Patterns in einer komplexen Umgebung finden Sie im zweiten Teil dieser Blogserie – bleiben Sie dran!

In der Zwischenzeit lesen Sie unseren aktuellen Beitrag zur erfolgreichen Implementierung von Enterprise Information Management (EIM).