Datenbanken sind die Grundlagen von BI-Analysen und bilden den zentralen Teil eines Data Warehouses. Sie speichern die unternehmensweite Sammlung von integrierten Daten und halten sie für Analysezwecke bereit. Die Speicherung der Daten erfolgt meist entweder in einem relationalen oder in einem multidimensionalen Datenbanksystem.
In diesem Artikel werden ein paar wichtige Aspekte zu Grundlagen der Datenbanktechnik vorgestellt. Dies sind in erster Linie Datenmodelle als abstrakte Abbildungen von Realitätsausschnitten. Sie beschreiben die Bedeutung und Repräsentation von Daten.
Besonders eng an die Realität angelehnt sind semantische und logische Datenmodelle, die unabhängig von der technischen Implementierung auf den Speichermedien sind. Bei den semantischen Modellen ist der Entity-Relationship-Ansatz einer der populärsten Kandidaten, bei den logischen Modellen das relationale Datenmodell. Letzteres wird aufgrund seiner Bedeutung etwas ausführlicher behandelt.
Im BI-Umfeld und speziell in Data Warehouses und Data Marts spielen multidimensionale Datenräume eine große Rolle. Sie weisen eine engere Analyserichtung aus und werden oft als so genannte Star- und Snowflake-Schemata umgesetzt. Diese Modellierungstechniken sollen abschließend vorgestellt werden.
Datenbanken und Datenmodelle
Ein Datenbanksystem besteht aus einer Datenbasis und einem Datenbank-Managementsystem (DBMS). Die Datenbasis oder Datenbank beinhaltet dabei die eigentlichen Daten, das DBMS ermöglicht es dem Nutzer, auf die Datenbasis zuzugreifen. Das DBMS kontrolliert dabei alle lesenden und schreibenden Zugriffe auf die Datenbank. Als externe Schnittstelle stellt das DBMS eine Datenmanipulationssprache zur Verfügung, mit der Abfragen formuliert und Daten eingefügt oder verändert werden können.
Weitere wichtige Aufgaben des DBMS sind unter anderem die Unterstützung des Datenschutzes, die Prüfung von Integritäts- und Konsistenzbedingungen und das Recovery nach Systemabstürzen.
Datenschutz wird gewährleistet, indem beispielsweise nicht jeder alle Daten lesen darf. Mit Integritäts- und Konsistenzbedingungen werden Vorgaben formuliert, denen alle Datensätze bestimmter Satztypen genügen müssen. Beispielsweise darf die Summe aller bezahlten Gehälter einen bestimmten Höchstbetrag nicht überschreiten. Für ein Recovery sorgt ein DBMS nach Systemabstürzen oder Fehlern, indem wieder ein korrekter Datenbankzustand hergestellt wird.
Bei der Einführung eines Datenbanksystems muss man einen Realitätsausschnitt so abbilden, dass er mit einem DBMS verwaltet werden kann. Zwei Fragen sind hier entscheidend. Erstens: Was soll man beschreiben, also welche Objekte der Realwelt und welche Beziehungen zwischen den Objekten sind relevant. Und zweitens: Wie sollen die Objekte und Beziehungen dargestellt werden.
Antworten auf diese Fragen gibt das Datenmodell. Ein Datenmodell als theoretische Grundlage für ein Datenbanksystem bestimmt, auf welche Art und Weise Daten in einem Datenbanksystem gespeichert und manipuliert werden. Es definiert damit die Infrastruktur für ein bestimmtes Datenbanksystem.
Grundsätzlich können Datenmodelle semantisch, logisch oder physisch ausgerichtet sein. Physische Datenmodelle sind techniknah orientiert und spezifizieren, wie Daten physisch abgespeichert werden. Diese Sicht interessiert Anwender wenig. Für sie sind logische und semantische Sichten wichtiger. Logische Datenmodelle beschreiben alle Daten auf logischer Ebene, unabhängig von ihrer Speicherung. Die größte Nähe zur Realität haben die semantischen Modelle. Sie bilden die Daten in einer völlig technikneutralen Ebene ab.
Entity Relationship Modell
Eines der bekanntesten semantischen Datenmodelle ist das Entity Relationship Modell (ERM) von Peter Chen. Es wurde in den siebziger Jahren entwickelt und im Laufe der Zeit modifiziert und erweitert.
Das ERM dient zum einen in der konzeptionellen Phase der Anwendungsentwicklung der Verständigung zwischen Anwendern und Entwicklern, zum anderen in der Implementierungsphase als Grundlage für das Design der Datenbank. Mit ERM lassen sich operative Datenstrukturen gut modellieren. Auch mehrdimensionale Datenstrukturen, die in diesem Beitrag weiter unten vorgestellt werden, können damit gut abgebildet werden.
Im ER-Modell werden die Objekte der Modellwelt als „Entities“ und die Beziehungen der Objekte als „Relationships“ bezeichnet. Beide können Attribute aufweisen, die sie näher spezifizieren. Beispielsweise kann mit der Entity „Kunde“ das Attribut „Name“ und „Wohnort“ verknüpft sein. Allgemein üblich ist eine grafische Darstellung mit Rechtecken für die Entitites und deren Verbindung über Rauten für die Beziehungen. Die folgende Abbildung zeigt ein einfaches Modell einer CD-Kundendatenbank.
Die in einem Oval dargestellten Attribute sind über Kanten mit den Entities beziehungsweise Relationships verbunden. Die Kardinalitäten werden an den Beziehungskanten eingetragen. Die Kardinalität ist die mögliche Anzahl der an einer Beziehung beteiligten Entität. Zum Beispiel kann ein Kunde mehrere CDs kaufen (m) und eine bestimmte CD kann von mehreren Kunden gekauft werden (n).
Allerdings gibt es unterschiedliche Varianten des ER-Ansatzes mit unterschiedlicher Notation. Auf diese und weitergehenden Informationen zum ER-Modell kann an dieser Stelle nicht eingegangen werden. Ein ausführlicheres Beispiel mit Erläuterungen finden Sie hier.
Relationale Datenmodelle
Das bekannteste und „modernste“ Datenmodell ist das relationale. Es ist einfach und leicht verständlich und stärker an den Bedürfnissen der Nutzer ausgerichtet. Zudem erlaubt es eine bessere Realisierung von Datenunabhängigkeit.
Erstmals wurde das relationale Datenbankmodell 1970 von Edgar Codd vorgeschlagen - heute ist es ein etablierter Standard zum Speichern von Daten. Das zugehörige Datenbank-Managementsystem (DBMS) wird als relationales Datenbank-Managementsystem (RDBMS) bezeichnet. Als Datenmanipulationssprache zum Abfragen und Manipulieren der Daten wird die Structured Query Language (SQL) eingesetzt.
Relationale Datenmodelle basieren auf Relationen mit einem Namen und dazugehörigen Attributen. Die Relationen werden in Form zweidimensionaler Tabellen mit eindeutigen Bezeichnungen abgebildet. Jeder Datensatz ist eine Zeile (Tupel) in der Tabelle. Die Zeilen sind eindeutig über einen oder mehrere Primärschlüsssel identifizierbar. Die Attributswerte bilden die Spalten der Tabelle.
Das Relationenschema legt dabei die Anzahl und den Typ der Attribute für eine Relation fest. Die Abbildung illustriert die Relation R mit den Attributen A1 bis An in den Spalten und den in Zeilen angeordneten Werten.
Entity Relationship Modelle lassen sich leicht in relationale Modelle überführen. Dabei wird jeder Enititätstyp und jeder komplexe Beziehungstyp (n:m-Beziehung) im Relationenmodell zu einer eigenen Relation. Die folgende Tabelle stellt die Begriffe aus beiden Modellen gegenüber.
|
Relationales Datenmodell |
Entity Relationship Model (ERM) |
|
|
Wertebereich (Domäne, Domain) |
Wertebereich (Domäne, Domain) |
Wertebereich (Domäne, Domain) |
|
Kopfzeile |
Relationstyp/Relationsformat |
Entitätstyp |
|
Spaltenüberschrift |
Attribut |
Attribut |
|
Inhalt |
Relation |
Entitätsmenge(-set) |
|
Inhalt |
Fremdschlüssel |
Beziehung (Relationship) |
|
Zeile |
Tupel |
Entität |
|
Zelle |
Attributwert |
Attributwert |
Redundanzen und Normalformen
In der Praxis werden relationale Datenbanken selten aus einem bereits existierenden Modell wie dem Entity Relationship Modell entwickelt. Oft ist es so, dass das erforderliche Datenmodell oder Teile davon aus bestehenden Berichtsstrukturen oder anderen Dokumenten generiert werden. Dabei werden oft große Tabellen definiert oder einfach Tabellen intuitiv festgelegt. Der Nachteil ist, dass dabei oft redundante Informationen gespeichert werden und die Datenbasis redundant wird.
Mit Redundanz ist das mehrfache Speichern identischer Attributswerte ein und derselben Objektausprägung gemeint. Wird beispielsweise in einer Mitarbeiterdatenbank der Name des Mitarbeiters zusammen mit der Abteilung und der Abteilungsnummer gespeichert, ist die Datenbank redundant. Das folgende Beispiel demonstriert, dass identische Werte von Abteilung und Abteilungsnummer mehrfach vertreten sein können.
|
Mitarbeiter-Nr |
Name |
Abteilung |
Abt.nummer |
|
1 |
Müller |
Entwicklung |
12 |
|
2 |
Meier |
Vertrieb |
15 |
|
3 |
Klose |
Entwicklung |
12 |
|
4 |
Baumann |
Vertrieb |
15 |
Redundanzen gefährden die Konsistenz der Datenbasis und können zu so genannten Anomalien führen. Ändert sich beispielsweise die Abteilungsnummer, müssen mehrere Tupel gleichzeitig geändert werden. Dies ist nicht nur aufwändig, sondern birgt die Gefahr der Inkonsistenz. (Update-Anomalie). Verlassen alle Mitarbeiter eine Abteilung, geht auch die Information verloren, welche Abteilungsnummer der Abteilung zugeordnet ist (Deletion-Anomalie).
Um Anomalien zu verhindern, gibt es eine Vielzahl von Vorschriften und Prinzipien. Ein weit verbreitetes Verfahren, Redundanzen und Inkonsistenzen zu vermeiden, ist die Normalisierung.
Primärschlüssel und Erste Normalform
Die Normalformenlehre geht auf den Erfinder der relationalen Datenbank, Edgar Codd, zurück. Er entwickelte mathematische Regeln, die relationale Datenbanken in redundanzfreie oder zumindest redundanzärmere Datenstrukturen überführen. Im Kern besteht dieser Prozess in drei Normalisierungsschritten.
Die Definition der Ersten Normalform lautet:
Eine Tabellenzeile darf nur einen Attributwert enthalten (technisch: Der Attributwert muss atomar sein). Kommen in einer Tabelle Wiederholungsgruppen vor, so muss für jeden Wert der Wiederholungsgruppe eine eigene Tabellenzeile geschaffen werden.
Als Beispiel verwenden wir eine Reisekostentabelle.
|
Rechnungsnummer |
Datum |
Name, Vorname, Straße, PLZ, Ort |
Kostenart |
Anzahl Einzelvergütung |
Um die Tabelle in die Erste Normalform zu überführen, müssen die Mehrfachbelegungen der Felder eliminiert werden. Also müssen „Name“, „Vorname“, „Straße“, „PLZ“ und „Ort“ in eigene Spalten gesetzt werden.
|
Rechnungsnummer |
Datum |
Name |
Vorname |
Straße |
PLZ |
Ort |
Kostenart |
Anzahl Einzelvergütung |
Besondere Beachtung verdienen die fett gedruckten Spalten Rechnungsnummer und Kostenart. Sie bilden den so genannten Primärschlüssel dieser Tabelle, das bedeutet, dass jedes Tupel eindeutig durch Rechnungsnummer und Kostenart identifiziert wird. Die Rechnungsnummer alleine genügt nicht als Primärschlüssel, da zu jeder Rechnungsnummer mehrere Kostenarten gehören können.
Mit Hilfe dieses Primärschlüssels lassen sich nun Verknüpfungen zwischen verschiedenen Tabellen herstellen.
Zweite und Dritte Normalform
Die Definition der Zweiten Normalform lautet:
Eine Relation ist in der Zweiten Normalform, wenn sie in der Ersten Normalform ist und alle Nicht-Schlüsselattribute funktional vom gesamten Schlüssel abhängen.
Damit muss ausgeschlossen sein, dass bereits Schlüsselteile bestimmte Attribute der Relation identifizieren können. Somit ist aus jenen Attributen, die nur von einem Teil des zusammengesetzten Primärschlüssels abhängen, eine neue Tabelle zu erzeugen.
In der Reisekostentabelle sind die Attribute „Datum“, „Name“, „Vorname“, „Straße“, „PLZ“ und „Ort“ nur funktional abhängig vom Attribut „Rechnungsnummer“ und völlig unabhängig vom Attribut „Kostenart“.
Das Attribut „Einzelvergütung“ ist dagegen nur funktional abhängig von der „Kostenart“ und hat nichts mit der „Rechnungsnummer“ zu tun. Lediglich das Attribut „Anzahl“ ist vom zusammengesetzten Primärschlüssel voll funktional abhängig.
Datenfelder, die von einem Schlüsselkandidaten nicht vollständig funktional abhängig sind, werden in weiteren Tabellen untergebracht. Der Teil des Schlüsselkandidaten, von dem ein ausgelagertes Datenfeld funktional abhängig ist, wird Primärschlüssel der neuen Tabelle. Als Ergebnis erhalten wird die drei folgenden Tabellen.
|
Rechnungsnummer |
Datum |
Name |
Vorname |
Straße |
PLZ |
Ort |
|
Rechungsnummer |
Kostenart |
Anzahl |
|
Kostenart |
Einzelvergütung |
Die Definition der Dritten Normalform lautet:
Eine Relation ist in der Dritten Normalform, wenn Sie in der Zweiten Normalform ist und zusätzlich keine funktionalen Abhängigkeiten zwischen Nicht-Schlüsselattributen existieren.
Somit darf lediglich der Primärschlüssel der Relation die Attribute identifizieren. In der Tabelle „Reise“ sind die Attribute „Vorname“, „Straße“ und „PLZ“ abhängig vom Attribut „Name“, nicht vom Primärschlüssel. Außerdem ist „Ort“ abhängig von „PLZ“. Diese abhängigen Datenfelder werden in weitere Tabellen ausgelagert. Da ein Name nicht eindeutig ist, wird jedem Angestellten eine Personalnummer zugeordnet. Diese ist Primärschlüssel der neuen Tabelle „Personal“.
Die folgende Tabellen sind das Ergebnis des Dritten Normalisierungsschritts, der zugleich Endergebnis der gesamten Normalisierung ist.
Multidimensionale Modelle
In BI-Analysen werden oft multidimensionale Datenräume betrachtet, wie sie OLAP-Analysen zu Grunde liegen. Eine beispielhafte Fragestellung für solche Analysen wäre etwa: Welcher Umsatz wurde mit Produkt 1 (1. Dimension) in der Region Ost (2. Dimension) im Jahr 2005 (3. Dimension) gemacht. Dabei werden die drei Dimensionen Produkt, Region und Zeit abgefragt.
Die resultierende Datenstruktur bildet im dreidimensionalen Fall einen Würfel, den Cube. Die folgende Abbildung zeigt den Cube für das erwähnte Beispiel.
Mehrdimensionale Datenräume sind durch mehrere Aspekte gekennzeichnet. Vor allem Fakten, Dimensionen und Hierarchisierung spielen eine Rolle.
Fakten oder „Measures“ sind in der Regel Zahlen wie Umsatzerlöse, Mengen oder Kosten, die im Mittelpunk der Datenanalyse stehen. Sie stehen im Inneren des Datenwürfels. Es handelt sich meist um betriebswirtschaftliche Kennzahlen, die die Aufgabe haben, Zusammenhänge in verdichteter, quantitativer Form wiederzugeben. Dabei kann es sich um Basisgrößen (atomare Werte) oder abgeleitete Zahlen (berechnete Werte) handeln.
Die Dimensionen sind deskriptiver Natur und stellen im dreidimensionalen Fall die Achsen des Würfels dar. Sie bilden die unterschiedlichen qualitativen Gesichtspunkte ab. Eine Visualisierung erfolgt im zweidimensionalen Fall als Tabelle (Matrix) und im dreidimensionalen Fall als Würfel.
Bei mehr als drei Dimensionen lassen sich die Daten als Hyperwürfel veranschaulichen. Der 4-dimensionale Hyperwürfel wird auch als Tesseract bezeichnet. Mehr Informationen dazu gibt das Dokument „Der n-dimensionale Hyperwürfel“, eine Java-Animation liefert anschauliche Beispiele.
Hierarchisierungen schließlich sind vertikale, hierarchische Beziehungen innerhalb von Dimensionen. Dies ermöglicht die Betrachtung unterschiedlicher Verdichtungsstufen der Daten. Beispielsweise kann die Dimensionsausprägung „Mitarbeiter“ hierarchisiert werden in „Filiale“, „Region“, „Land“ und „Gesamt“.
Multidimensionale Datenräume – ein Beispiel
Die folgende Abbildung illustriert die eben vorgestellten Konzepte noch einmal anhand eines konkreten Beispiels.
Die Dimension „Studienausrichtung“ umfasst die Elemente „SOZ“ (Soziologie), „EuWi“ (Europäische Wirtschaft), „VWL“ (Volkswirtschaftslehre), „BWL“ (Betriebswirtschaftslehre) und „WI“ (Wirtschaftsinformatik). Die Dimension „Zeit“ besteht aus den einzelnen Semestern, die Dimension „Studienabschnitt“ aus den Elementen „Grundstudium“ (GS) und „Hauptstudium“ (HS).
Durch das kartesische Produkt der Dimensionselemente aller an einem Würfel beteiligten Dimensionen entsteht die Gesamtzahl der Zellen des Würfels mit jeweils einem konkreten Datenwert.
Ferner enthält die Grafik zwei Beispiele für Hierarchisierung. So können etwa die Studierendenzahlen in einzelnen Studiengängen auf Fakultäts- bzw. Universitätsebene aggregiert werden.
Jeder Datenwürfel unterliegt spezifischen Integritätsbedingungen. Entlang der Knoten in Dimensionshierarchien gelten individuelle Konsolidierungsvorschriften, z.B. werden Studierendenzahlen der einzelnen Studiengänge zu Zahlen auf Fakultätsebene addiert. Es können dabei beliebig komplexe Berechnungsregeln hinterlegt sein.
Das Star-Schema
Eine besondere Form des multidimensionalen Datenmodells ist das Star-Schema. Das Schema hat sich zur Abbildung multidimensionaler Datenstrukturen in relationalen Datenbanken zum Standard entwickelt und wird vor allem in Data Warehouses und OLAP-Anwendungen eingesetzt.
Das Star-Schema versucht, die große Anzahl an Tabellen, wie sie im relationalen Modell typisch sind, zu minimieren. Die Bezeichnung Star-Schema rührt daher, dass die Tabellen sternenförmig angeordnet werden.
Dabei müssen zwei verschiedene Arten von Tabellen unterschieden werden. Im Zentrum steht die Faktentabelle, um die sich mehrere Dimensionstabellen gruppieren. Beide werden durch Rechtecke symbolisiert. Die Faktentabelle dient zur Speicherung der Zahlen oder abgeleiteten Größen, also etwa Umsätze oder Kosten. Aus Würfelperspektive enthält sie den Würfelkern. Die Dimensionstabellen enthalten die qualitativen Daten zur Visualisierung der Dimensionen und Dimensionshierarchien.
Die einzelnen Zeilen einer Dimensionstabelle werden durch eine minimale Attributkombination, dem Primärschlüssel, identifiziert. Zur Herstellung der Beziehung zwischen den Dimensionstabellen und der zugehörigen Fakttabellen werden die Primärschlüssel der Dimensionstabellen in die Fakttabelle als Fremdschlüssel aufgenommen und bilden dort wiederum zusammen den Primärschlüssel der Fakttabelle. Die folgende Abbildung verdeutlicht dies.
Die folgende Abbildung zeigt ein konkretes Beispiel zum Star-Schema.
Ziel des Star-Schemas ist nicht die Normalisierung, sondern eine Optimierung auf effiziente Leseoperationen. Beim Star-Schema liegen die Dimensionstabellen deshalb denormalisiert vor: Es existieren funktionale Abhängigkeiten zwischen Nicht-Schlüsselattributen, so dass die dritte Normalform verletzt wird. Diese Verletzung nimmt man aber in Kauf, denn die Datenstruktur ermöglicht einebessere Verarbeitungsgeschwindigkeit zu Lasten der Datenintegrität und des Speicherplatzes.
Das Snowflake-Schema
Eine Verbesserung ist durch das dem Star-Schema verwandte Snowflake-Schema möglich. Beim Snowflake-Schema bleibt die Faktentabelle unverändert, die Dimensionen werden jedoch verfeinert, indem sie klassifiziert oder normalisiert werden.
Letztendlich werden die Dimensionstabellen dabei um die Attribute erweitert. Damit wird jede Ausprägung einer Dimension in einer eigenen Tabelle dargestellt. Durch diese Weiterverzweigung des Datenmodells entsteht die Form einer Schneeflocke, was dem Entwurfsmuster den Namen verleiht.
Ein Schneeflockenschema führt also zu kleineren und besser strukturierten Datenmengen. Dies hat jedoch auch Nachteile: Bedingt durch die feinere Strukturierung sind die Daten zwar weniger redundant als in einem Star-Schema, die Zusammenhänge sind jedoch komplexer. So müssen die mehrstufigen Dimensionstabellen wieder über Join-Abfragen verknüpft werden. Dies führt unter Umständen zu längeren Abfragezeiten.
Die folgende Abbildung zeigt das oben vorgestellte Star-Schema der Profitabilitätsanalyse von Organisationseinheiten als Snowflake-Schema.
Der Übergang von der Star-Modellierung zur Snowflake-Modellierung ist fließend. Beide Modelle werden auch kontrovers diskutiert, ein einheitliches Konzept ist mit beiden Modellen nicht verbunden.
Von beiden Modellen existieren diverse Varianten und Abarten wie das Dimension Modelling nach Kimball, Fact/Constellation Schemata oder das Simple Star und Multiple Star Schema, die alle hier nicht weiter behandelt werden können.
Relativ bedeutend sind Galaxien. Galaxien sind Ansammlungen von Star-Schemata, wie sie in Data Marts zu unterschiedlichen Analysezwecken auftreten. Da diese Ansammlung oft auf strukturidentischen Dimensionstabellen beruht ist die mehrfache Verwendung einzelner Dimensionstabellen aus Konsistenzgründen zu empfehlen. Eine Galaxie integriert damit mehrere Star-Schemata und bietet damit viele Vorteile - wie eine geringe Anzahl von Join-Operationen oder einen geringeren Wartungsaufwand des Data Warehouses.
Fazit
Datenbanken bilden die Grundlage von E-Business-Anwendungen, wobei vorzugsweise relationale Datenbanken zum Einsatz kommen. Relationale Datenbanken erlauben eine redundanzarme, optimierte Speicherung von Daten.
Eine zentrale Rolle in der BI, insbesondere in Data Marts und bei OLAP-Analysen, spielen multidimensionale Datenmodelle. Sie lassen sich im 3-dimensionalen Fall als Würfel veranschaulichen und bieten effiziente und leicht anwendbare Auswertungsverfahren.
Die Modellierung multidimensionaler Daten erfolgt innerhalb des relationalen Datenmodells oft mit Star- und Snowflake-Modellierungsvarianten. Sie erlauben eine performanceoptimierte Modellierung multidimensionaler Datenräume, verletzen zum Teil aber die strikten, theoretischen Anforderungen an relationale Systeme. (ala)