BigData Tech Series: Flat Database

0

Big-Data-Tech-Series-Teil-2Im Kontext analytischer Datenbanken ist häufig die Rede von „Flat Database“, ein flaches bzw. abgeflachtes Datenbankdesign. Hersteller analytischer, spaltenorientierter Datenbankmanagementsoftware empfehlen für die Informationsanalyse häufig diese Form der Datenstrukturierung. Vielen Unternehmen ist jedoch noch nicht klar, wie Aufbau, Abgrenzung sowie Vor- und Nachteile des Designs aussehen sollen. Ich möchte daher in diesem Teil der BigData Tech Series einen kurzen Überblick darüber geben.

Grundlegend versteht man unter einem Flat Table Design das Zusammenfassen von Fakten und Dimensionen. Die integrierten Dimensionstabellen werden als degenerierte Dimensionen bezeichnet. Theoretisch unterscheidet man zwischen einem abgeflachten und einem flachen Design. Ziel beider Modellierungsvarianten ist es, Komplexität zu verringern und rechenintensive JOIN-Operationen zu vermeiden. So hofft man, die Abfrageperformance zu steigern.

Flat Model und Flattened Model
Das flache Design, das auch unter dem Begriff „Flat Model“ läuft, geht bei Leistungsvorteilen keine Kompromisse ein. Es integriert zu Gunsten der Analysegeschwindigkeit alle Dimensionen in die Faktentabelle. Beim abgeflachten Design (oder „Flattened Model“) werden dagegen nur vereinzelte Dimensionen eingebunden. Dimensionen mit sich verändernden Daten wie bspw. Kontaktinformationen, also Telefonnummern oder E-Mail-Adressen, bleiben eigenständig.

Die Auswahl des Design-Ansatzes ist weniger von der Art des Datenbankmanagementsystems (analytisch/traditionell) abhängig, sondern mehr vom konkreten Speicherformat (spaltenorientiert/zeilenorientiert). Grundsätzlich eignet sich der Einsatz der beiden Variationen nur bei Systemen mit spaltenorientierter Datenhaltung. Dabei werden die Daten attributweise gespeichert und gelesen. Die zusätzlichen Attribute der degenerierten Dimensionen haben daher keine direkten negativen Auswirkungen auf die Abfrageperformance.

Zeilenorientierte Systeme speichern und lesen hingegen in Datensätzen. Dadurch müssen bei einer Abfrage zwangsläufig alle Attribute aller Datensätze durchlaufen werden. Das bedeutet bei einer flachen Modellierung natürlich einen größeren Aufwand, abhängig von der Anzahl der Attribute und ihren Datentypen.

Star-Schema: Wunschkandidat Flat Design
Das Star-Schema stellt bekanntlich die performanteste Lösung klassischer relationaler Datenbanksysteme dar. Es nutzt zur temporären Integration notwendiger Dimensionen JOIN-Operationen. Der Input zeilenorientierter Systeme beim Verarbeiten einer Abfrage wird so minimiert. Bei spaltenorientierten Systemen hat das Star-Schema aber keine Leistungsvorteile. Im Gegenteil: durch die zusätzlichen JOIN-Operationen in Kombination mit der komplexen spaltenweisen Speicherung wächst der Rechenaufwand. Daher ist es – zumindest aus Performancesicht – empfehlenswert, bei nativen Analysen das flache Datenmodell zu verwenden.

Flattened Design als guter Mittelweg
Natürlich spielen im Normalfall bei der Datenmodellierung noch viele weitere Aspekte eine wichtige Rolle. Die Variante des abgeflachten Designs ist daher ein guter Kompromiss: Datenbanktabellen mit häufig wiederkehrenden Veränderungen – gemäß Slowly Changing Dimension – werden als eigenständige Dimension angelegt. Der Grund dafür sind vor allem die rechenintensiven UPDATE-Befehle hinsichtlich des spaltenorientierten Speicherformates. Generell sind die Operationen INSERT, UPDATE und DELETE durch die spaltenweise erfolgende Datenverwaltung deutlich rechen- und damit zeitintensiver.

Beim UPDATE-Befehl muss vor der Aktualisierung des Wertes der entsprechende Datensatz aus den attributweise gegliederten Daten reproduziert werden. Dieser Prozess würde bei einem Flat Table Design deutlich länger dauern, weil sie viele Spalten und Zeilen besitzt. Daher ist es sinnvoll, solche Dimensionen auszulagern. Positiver Nebeneffekt: durch die Auslagerung verringert sich auch der Speicherbedarf.

Aufbau des OLAP-Schemata
Um Daten mit OLAP-Applikationen auswerten zu können, muss man zuerst ein XML-Schemata / Cube erzeugen. Anders als beim Star- oder Snowflake-Schema reicht es dabei nicht aus, die physikalische Struktur der Datenbanktabellen nachzubilden. Wird das flache oder abgeflachte Design verwendet, ist es zusätzlich notwendig, die degenerierten Dimensionen auf der logischen Ebene aus der Faktentabelle zu extrahieren. Ohne diesen Schritt ist es nicht möglich, Analysen an Hand der degenerierten Attribute durchzuführen. Nimmt man als Beispiel die BI-Suite Pentaho, reicht es aus, eine eigenständige Dimension innerhalb der XML-Datei anzulegen. Dabei darf innerhalb der Dimension weder der Primärschlüssel noch der Fremdschlüssel oder die Quelltabelle definiert werden. Der Mondrian-Server, der bei Pentaho für die Verarbeitung der Abfragen verantwortlich ist, erkennt dadurch, dass es sich um eine degenerierte Dimension handelt. Für die Gestaltung des Cubes kann die einfach zu bedienende Pentaho Schema Workbench verwendet werden.

Leistungssteigerer
Das Flat Model und das Flattened Model stellen die beste Lösung dar, was die Abfrageleistung betrifft, die ja die zentrale Prämisse eines solchen Systems darstellt. Bei verschiedenen Tests mit analytischen, spaltenorientierten Systemen hat sich gezeigt, dass die beiden Modelle deutliche Performancevorteile gegenüber dem Star-Schema haben. Diese Aussage trifft bei nativen Abfragen in vollem Umfang zu. Verwendet man spezifische Werkzeuge basierend auf einem entsprechender XML-Schemata, kann aber die nachträgliche logische Auslagerung der degenerierten Dimensionen den Zeitaufwand erhöhen. Da es viele solcher Tools gibt, ist es nicht möglich, eine generelle Aussage zu treffen. Ich empfehle daher, im Einzelfall entsprechende Testszenarien durchzuspielen.

Dieser Artikel könnte Sie auch interessieren:

Tags: , ,

Stefan Müller - Director Business Intelligence & Big Data
Nach mehreren Jahren Tätigkeit im Bereich Governance & Controlling und Sourcing Management ist Stefan Müller bei it-novum gelandet, wo er den Bereich Business Intelligence aufgebaut und in Richtung Big Data weiterentwickelt hat. Stefans Herz schlägt für die Möglichkeiten, die die BI-Suiten von Pentaho und Jedox bieten, er beschäftigt sich aber auch mit anderen Open Source BI-Lösungen. Seine Begeisterung für Business Open Source im Bereich Datenintelligenz gibt Stefan regelmäßig in Fachartikeln, Statements und Vorträgen weiter.
Webprofile von Stefan: Twitter, LinkedIn, XING

Kommentar schreiben

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.