Zusammenfassung
Relationale Datenbanksysteme als heutige Standard-Datenbanktechnik mit sehr weiter Verbreitung spielen im Umfeld analyseorientierter Informationssysteme und Data Warehouse eine wichtige Rolle, da Unternehmen in diesem Bereich breites Know-How zur Verfügung steht und eine erprobte Technik vorhanden ist.98 Im Bereich der Online Transaction Processing (OLTP)-Systeme finden daher relationale Datenbanksysteme eine sehr breite Verwendung.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
Vgl. Gluchowski (1997b) S. 48.
Vgl. Hahne (1999) S. 152.
Vgl. Codd (1970).
Das ERM findet als spezielle Ausprägung eines Informationsstrukturmodells in der Praxis häufig Anwendung, vgl. hierzu Gabriel/Rohrs (1995), S. 104ff.
In der Literatur wird oft nicht sauber zwischen den Ebenen des Schemas und der Instanz unterschieden. Kemper/Eickler begründen dies damit, da aus dem Kontext ersichtlich sei, welche Ebene angesprochen ist, vgl. Kemper/Eickler (1996), S. 53. Lang/Lockemann differenzieren Schema und Instanz über die Definition von Relationstypen und Relationen, vgl. Lang/Lockemann (1995), S. 44.
Zum Teil wird auch noch gefordert, dass diese Menge nicht leer ist. Vgl. etwa Kandzia/Klein (1993) S.35.
Kandzia/Klein fordern zusätzlich noch die Surjektivität der Wertebereichsfunktion. Vgl. Kandzia/Klein (1993) S. 36.
Vgl. Paredaens et. al. (1989) S. 9.
Dieser Vorgehensweise von Codd folgen auch Kemper/Eickler, vgl. Kemper/Eickler (1996) S. 53, sowie Gabriel/Rohrs, vgl. Gabriel/Röhrs (1995) S. 120.
Vgl. Kandzia/Klein (1993), S. 39. sowie Kemper/Eickler (1996), S. 69. Die Diskussion, welche Operationen als elementar anzusehen sind, wird in der theoretischen Betrachtung unter dem Stichwort der Äquivalenz von Operationenmengen und der Angabe einer „minimalen“ Operatorenmenge geführt, vgl. Kandzia/Klein (1993) S. 77ff.
Vgl. Lang/Lockemann (1995), S. 55.
Vgl. Gabriel/Rohrs (1995), S. 132.
Wird etwa eine where-clause in einer SQL-Abfrage betrachtet, so tritt ein wesentlicher Unterschied zwischen der Datenbanksprache SQL und der formalen Spezifikation in der Relationenalgebra deutlich zu Tage: In der SQL-Abfrage muss durch Angabe des Schlüsselwortes distinct die Duplikateliminierung explizit aktiviert werden. SQL weicht noch in vielen weiteren Punkten von dem formal definierten Relationenmodell ab und soll daher im folgenden nur zur Veranschaulichung benutzt werden. Zu einer detaillierten kritischen Analyse der Anfragesprache SQL vergleiche Date (1983).
Vgl. Lang/Lockemann (1995), S. 51f.
Vgl. Vossen (1999), S. 303f.
Die Definition folgt Kandzia, der ebenfalls beide Interpretationen der Umbennung berücksichtigt, vgl. Kandzia/Klein (1993) S. 43. Bei Kemper/Eickler erfolgt darüber hinaus eine Definition der Umbenennung von Relationen, vgl. Kemper/Eickler (1996) S. 68f.
Abweichend von der Literatur wird der natürliche join auch manchmal als inner join bezeichnet, um ihn von den Inklusionsverknüpfungen der verschiedenen outer joins zu differenzieren, so etwa in den Datenbanksystemprodukten Access und SQL Server der Firma Microsoft. In der SQL-Syntax kann der inner join dann auch abkürzend durch join bezeichnet werden, das ist jedoch ein Aspekt der Implementierung und nicht der formalen Definition der Operatoren der Relationenalgebra auf logischer Modellebene.
Vgl. Vossen (1999), S. 303. Insbesondere ergibt das natürliche Produkt mit einer leeren Relation wieder eine leere Relation, vgl. Kandzia/Klein (1993), S. 42.
Vgl. Lang/Lockemann (1995), S. 64f.
Ein ausführliches Beispiel zur Übersicht über die verschiedenen Join-Typen ist in Kemper/Eickler (1996), S. 74 dargestellt.
Kandzia/Klein (1993), S.96.
Vgl. Codd (1972).
Eine detaillierte Auseinandersetzung mit der in der Sprache SQL inhärenten Problematik findet sich bei Date (1983).
Diese Funktionen fehlen im SQL-Standard, obwohl mit der ursprünglichen Definition von SE-QUEL2 diese Unterstützung vorgesehen war, vgl. Chamberlin et. al. (1976)
Vgl. Kemper/Eickler (1996), S. 76.
Vgl. Kandzia/Klein (1993), S: 48f. Codd hat bereits bei der Vorstellung des Relationenmodells ein solches Kalkül angegeben.
Vgl. Kemper/Eickler (1996), S. 77.
Die beiden Kalküle haben die gleiche Ausdruckskraft, beim wertebereichsorientierten Kalkül sind die Variablen nicht an Tupel, sondern an andere Wertebereiche gebunden. Intensiv werden die beiden Relationenkalküle in Kandzia/Klein (1993) diskutiert.
Vgl. Schöning (1995), S. 52 allgemein zu freien Variablen in der Prädikatenlogik sowie speziell Kemper/Eickler (1996), S. 79 zu freien Tupelvariablen des Relationenkalküls.
Leider gibt es keine allgemein anerkannte einheitliche Festlegung der Syntax des Relationenkalküls, fast jeder Autor notiert diese anders, obwohl der Inhalt die gleiche Bedeutung hat.
In der Datenbankliteratur werden diese Grundbausteine auch Atome genannt, vgl. Kemper/Eickler (1996), S. 79; in Abiteboul/Hull/Vianu (1995) sind Terme etwas eingeschränkter definiert, die hier verwendete Definition folgt der allgemeinen Festlegung in der Prädikatenlogik.
Die Darstellung folgt dem Aufbau der Prädikatenlogik, vgl. Schöning (1995), S. 52; ähnlich die Darstellung bei Kemper/Eickler (1996), S. 81; Lang und Lockemann führen die explizite Regel des Abschlusses als fünfte Regel ein, die besagt, dass genau die durch diese Regeln erzeugbaren Ausdrücke Formeln sind, vgl. Lang/Lockemann (1995), S. 71.
Sowohl der dargestellte tupelorientierte als auch der nicht dargestellte domänenorientierte Relationenkalkül sind gleich ausdrucksstark wie die Relationenalgebra, vgl. Kandzia/Klein (1993), S. 76ff. für einen ausführlichen Beweis und eine eingehende Diskussion der Ausdruckskraft von Relationenalgebra und Relationenkalkülen.
Vgl. Kemper/Eickler (1996), S. 83.
Vgl. Kandzia/Klein (1993), S. 130.
Vgl. zu dieser ausführlichen Klassifikation von Konsistenzbedingungen Gabriel/Röhrs (1995), S.291ff.
Vgl. Paredaens et. al. (1989), S. 61.
Kandzia/Klein (1993), S. 136.
Vgl. Paredaens et. al. (1989), S. 66.
Diese Axiome werden auch als Armstrong-Axiome bezeichnet. Vgl. Lang/Lockemann (1995), S. 310.
Diese Eigenschaft und weitere Folgerungen davon werden sehr ausführlich in Paredaens et. al. (1989), S.78ff. dargestellt. Einen recht anschaulichen Beweis findet man in Kandzia/Klein (1993), S.151Í.
Vgl. Gabriel/Röhrs (1995), S. 120f.
Das NF2-Modell wird ausführlich von Lang und Lockemann diskutiert, vgl. Lang/Lockemann (1995), S. 97ff. Eine umfassende formale Darstellung findet sich ebenfalls bei Vossen, vgl. Vossen (1999), S. 373ff. Gärtner geht dediziert auf das NF2-Modell im Kontext mehrdimensionaler Datenstrukturen ein, vgl. Gärtner (1997) S. 196ff.
Zum Begriff der vollen funktionalen Abhängigkeit siehe auch Gabriel/Röhrs (1995), S. 125.
Vgl. Paredaens et. al. (1989), S. 146.
Vgl. Gabriel/Röhrs (1995), S. 126.
Vgl. Paredaens et. al. (1989), S. 115. Der Zusammenhang zwischen Prim-Attributen, Schlüsseln und zweiter Normalform wird bei Kemper und Eickler aufgearbeitet, vg. Kemper/Eickler (1996), S. 144ff.
Vgl. Kemper/Eickler (1996), S. 146.
Vgl. Gabriel/Röhrs (1995), S. 128.
Paredaens diskutiert diese Normalformen unter dem Oberbegriff der vertikalen Dekomposition, vgl. Paredaens et. al. (1989), S. 113ff. (diese unterscheiden sich von horizontalen Dekompositionen, die dort ebenfalls dikutiert werden) und gibt auch Transformationsalgorithmen zur Überführung von Schemata in die verschiedenen Normalformen an. Bei Abiteboul, Hull und Vianu werden ebenfalls Algorithmen für die Umwandlung in BCNF sowie dritte Normalform angegeben, vgl. Abiteboul et. al. (1995), S. 251ff.
Vgl. Raden (1996).
Vgl. Nußdorfer (1998a), S. 24.
Vgl. Nußdorfer (1998b), S. 18.
Siehe hierzu auch Abschnitt 4.2.3.3.
Der Begriff des Würfels kommt der Vorstellung des mehrdimensionalen Datenraumes als ein Quader aufgespannt von den Dimensionen mit den Beschriftungen der Dimensionselemente, deren Zellen die Datenwerte beinhalten, nahe. Obwohl nicht alle Dimensionen die gleiche Anzahl an Elementen aufweisen, wird trotzdem der Begriff Würfel statt Quader benutzt, da sich dieser bereits allgemein durchgesetzt hat.
In dieser Abbildung wird die ERwm-eigene Notation verwendet, die für alle Arten von Tabellen eines Star Schemas eigene Symbole kennt, somit insbesondere Dimensions- und Faktentabellen differenziert werden. Diese werden durch die Symbole ■ für Faktentabellen (fact table) und ◆ für Dimensionstabellen (dimension table) repräsentiert (Vgl. Platinum (1998b), S.37ff.)) Wichtige Anwendungsgebiete von ERwin sind Data Warehouse-Projekte, und hier werden oftmals Star Schemata modelliert. ERwin bietet eine eigene dimensionale Sicht sowie Regeln hierzu an.
Vgl. z. B. McGuff (1996) S. 5 oder McGuff (1998).
Die Star Schema-Darstellung von ERwin kennt eigene DW-Tabellentypen (Tabellentypen) und ist eine alternative Sicht zur physischen Darstellung. Je nach Position der Tabellen an den entsprechenden Beziehungen unterscheidet ERwin die verschiedenen Tabellentypen.
Zur Problematik der Schlüsselerstellung vgl. Nußdorfer (1998b), S. 20f. sowie Raden (1996), S. 4–6.
Vgl. Nußdorfer (1998a), S. 20f.
Sowohl in einigen Modellierungsansätzen, etwa ADAPT von Bulos (vgl. Bulos (1996)), wie auch in einigen OLAP-Produkten und mehrdimensionalen Datenbanken, wie z. B. Essbase (ehemals Arbor Software, mittlerweile Hyperion), wird die Zeitdimension daher gesondert definiert (vgl. Hahne (1998)S.27ff.).
Einige Data Warehouse-Systemprodukte ermöglichen nur Baumstrukturen und können Hierarchie-Strukturen wie Wälder nicht verarbeiten. Dabei ist oft der Dimensionsname selbst der oberste Knoten; vgl. Hahne (1998) S. 28.
Ist die Granularität der Zeitdimension auf Tagesniveau, kommen auch noch die Einträge für jeden Tag hinzu. Tagesbezogene Attribute können jedoch in verschiedenen Jahren unterschiedlich sein und sind daher problematisch, wenn die Jahre nicht in der gleichen Dimension mit modelliert sind.
Vgl. Hahne/Schelp (1997) S. 25ff. und Schelp (2000) S. 246ff.
In dieser Darstellung einer Dimensionstabelle sind noch keine Tupel, die die Aggregate beschreiben, vorhanden. Diese werden erst dann benötigt, wenn auch in der Faktentabelle Aggregate gespeichert werden. Dies wird ausführlich in den Abschnitten 4.2.2 und 4.2.4 diskutiert.
Vgl. McGuff(1996), S.8.
Vgl. Nußdorfer (1998a), Seite 20f.
Mit dem Begriff der Tiefe, wie er in Abschnitt 4.2.1.5 noch eingeführt wird, kann dies dadurch ausgedrückt werden, dass die Blattelemente eine unterschiedliche Tiefe haben.
McGuff spricht in diesem Fall von dem pattern (Dimensions-Muster) des split-and-join; vgl. McGuff (1996) S.U.
Für eine detaillierte Auseinandersetzung mit der graphentheoretischen Betrachtung von Dimensionsstrukturen vgl. Hahne/Schelp (1997).
Vgl. Pohlers (1993), S. 168.
Vgl. Ottmann/Widmayer (1990), S. 251 f. Dieser Begriff wird oft für Bäume definiert, lässt sich aber problemlos auf allgemeine gerichtete Graphen verallgemeinern.
Vgl. Hahne (1998) S. 48ff.
Das OLAP-Council wurde 1995 gegründet und ist im World Wide Web unter der URL http://www.olapcouncil.orgzu erreichen. Für eine einheitliche Begriffsdefinition vgl. OLAP Council (1998).
Vgl. OLAP Council (1998).
Zur unterschiedlichen Verwendung der Begriffe Höhe und Tiefe vgl. Hahne (1998) S. 15ff.
Vgl. Raden (1996) S. 8 für eine exemplarische nicht-verallgemeinerte Darstellung.
Zur Syntax von SQL vgl. Vossen (1999) S. 345ff.
Daher hat auch die Optimierung der Performance für die Generierung von Aggregaten im Star Schema einen sehr hohen Stellenwert. In der Literatur werden einige Strategien und Algorithmen zur schnellen Aggregatberechnung angegeben, vgl. hierzu u. a. Agarwal et. al. (1996), Deshpande/Agarwal/Naughton/Ramakrishnan (1996) sowie Sarawagi/Agrawal/Gupta (1996).
Vgl. Kimball (1996) S. 38.
Diese Problematik trifft sehr viele Data Warehouse-Systemprodukte. Auch in speziellen OLAP-Datenbanken kann dieses Modell oft nur mit einem Kniff abgebildet werden. Hierzu müssen die Dimensionen um sog. Dummy-Elemente erweitert werden.
Erfolgt die Aggregatberechnung mit SQL in der gleichen Weise wie die dynamische Kalkulation, sind für die Berechnung von n Fakten in einer Tabelle im allgemeinen 2n SQL-Anweisungen notwendig die wiederum über eine group-by-Klausel die verdichteten Werte berechnen, vgl. Lehner/Teschke/Wedekind (1997). Für die Berechnung aller dieser Teilsummen, die so in SQL nicht möglich ist, wurde in der Literatur eine Cube-Operator eingeführt, der dies als Erweiterung von SQL realisiert, vgl. Gray/Bosworth/Layman/Pirahesh (1996).
Dieser Fall ist ausführlich in Hahne (1999), S. 156, dargestellt.
Bei einigen OLAP-Produkten wird per se die Dimension selbst schon als oberster Knoten betrachtet, so etwa in der Essbase-Datenbank von Arborsoft (mittlerweile Hyperion). In diesen Systemen gibt es also in jeder Dimension genau ein Wurzelelement. Dieses Unterscheidungsmerkmal verschiedener OLAP-Produkte wird auch in Hahne (1998) aufgeführt.
Diese Regel findet ihre Ausnahme, wenn auf semantischer Ebene Tool-gestützt diese Informationen (Metadaten) vorgehalten werden und auswertbar sind.
Die Zahlenwerte für die verkaufte Menge und den Umsatzerlös haben dabei in der Darstellung in der Tabelle nur exemplarischen Charakter.
Vgl. Raden (1996).
Auf alphanumerische level-Attribute wird in Abschnitt 4.2.4.3 noch näher eingegangen.
Der Begriff der Heterarchie im Kontext der mehrdimensionalen Datenmodellierung wird in Hahne/Schelp (1997) eingeführt.
Vgl. Kimball (1996), S. 98ff.
Vgl. Kimball (1996), S. 98ff.
Die in dieser Arbeit dargestellten Modelle wurden mit dem Werkzeug ERwin entwickelt. Dieses Tool hat eine eigene Notationsform für die verschiedenen Tabellentypen eines dimensionalen Modells. Die Symbole für Faktentabellen und Dimensionstabellen wurden bereits angeführt. Das Symbol für eine herausgebrochene Dimensionstabelle in ERwin ist ◇.
Zu den temporalen Aspekten von Strukturbrüchen in Dimensionen vgl. Abschnitt 4.2.3.4.
Andernfalls müssten die komplett historisierten Einträge in der Kunden-Dimensionstabelle erfolgen, d. h. ein neuer Kundeneintrag vorgenommen werden, vgl. Kimball (1996) S. 105f.
Vgl. Gluchowski (1997a), S. 63.
Der im englischsprachigen Raum benutzte Begriff des parents wird im deutschsprachigen Raum nicht gabz korrekt mit dem Begriff Vater übersetzt. Präziser wird daher in der Literatur auch von einem direkten bzw. unmittelbaren Vorgänger gesprochen, vgl. Ottmann/Widmayer (1990), S. 249ff. sowie Pohlers (1993), S. 169.
Vgl. Hahne (1999), S. 155.
Vgl. Gluchowski (1997a), S. 64.
In der Dimensionstabelle ist auch gut erkennbar, dass bei dieser Art der Modellierung von Beziehungen eine „Rolle“ in ERwin explizit definiert werden muss. In obiger Dimensionstabelle heißt die Rolle „Übergeordnete_Kostenstelle“ und die wird auch als Foreign Key in die Tabelle migriert. Mit dem Verfahren des Forward-Engineering generiert ERwin aus diesem Modell die DDL in SQL spezifisch für das Ziel-Datenbanksystem automatisch.
Das Skript ist sehr komplex, nicht unabhängig von der Kenntnis der zu berücksichtigenden Tiefe zu schreiben, und die Ergebnismenge ist aufgrund des union-Operators nicht weiter sortierbar.
Vgl. Hahne/Schelp (1997) S. 26f.
In Hahne/Schelp (1997) wird die Operation des roll-up dergestalt eingeführt, dass zu einer gegebenen Selektion von Dimensionselementen genau die durch den roll-up selektiert werden, die Parent-Element zu irgendeinem zuvor gewählten Element sind. Im Beispiel liefert der roll-up von (40,45,452) die Menge (40,45,46) als Ergebnis. Vgl. Hahne/Schelp (1997), S. 45f.
Dieser Ansatz führt zu einer Datenredundanz in der Faktentabelle, die ein potentielles Risiko der Dateninkonsistenz in sich birgt. Die Gewährleistung der Datenkonsistenz innerhalb des Datenbankmodells liegt hierbei auf der Ebene des ETL-Prozesses (ETL = Extract, Transform and Load).
Der Begriff der Galaxie geht auf McGuff zurück, vgl. McGuff (1998), Teil 9, S. 1f.
ALEA ist ein Produkt der MIS AG.
Vgl. Kimball (1996), S. 143ff.
Vgl. Nußdorfer (1998a), S. 28.
Vgl. Kimball (1996), S. 42ff.
Vgl. Kimball (1996), S. 42f.
Vgl. Kimball (1996), S. 147ff.
Vgl. Hahne (1999) S. 151.
Dieser hohe Freiheitsgrad wird in verfügbaren OLAP-Produkten im allgemeinen nicht ermöglicht, da Berechnungsregeln über die hierarchische Anordnung von Elementen in einer Dimension, so auch in der Kennzahlendimension, implizit zu Verdichtungswegen herangezogen wird. Diese Metadaten können aber trotzdem in den Kommentaren der Tabellendefinition über Erwin rein nachrichtlich mit modelliert werden. Die Einträge in den Freitextfeldern zur Tabellendefintion könnnen in ERwin, sofern dies gewünscht und selektiert wird, beim Generieren des Modells automatisch in die Comment-Einträge der generierten DDL übertragen werden. Vgl. Platinum (1998a), S.32ff.
Vgl. Kimball (1996), S. 12f.
Vgl. Hahne (1998), S. 24.
Vgl. Kimball (1996), S. 45.
Kimball drückt dies durch ratio of the sums instead of the sum of the ratios aus, vgl. Kimball (1996), S. 44. Damit ist angedeutet, dass Verhältniszahlen auf aggregierter Ebene das Verhältnis der aggregierten Werte widerspiegeln.
Auf die besondere Rolle der Zeitdimension wurde schon mehrfach in dieser Arbeit hingewiesen, etwa in Kapitel 4.2.1.
Vgl. Chamoni/Stock (1998), S. 516ff.
Vgl. Kimball (1996), S.100ff.
Vgl. Nußdorfer (1998a), S. 20ff.
In der Diskussion temporaler Datenbanken erfolgten auch zahlreiche Vorschläge für Erweiterungen des Relationenmodells zur Berücksichtigung temporaler Aspekte. Für eine Übersicht dieser Varianten von Erweiterungen des Relationenmodells sowie eine Klassifizierung der Modelle anhand von 26 Kriterien vgl. McKenzie/Snodgrass (1991).
Vgl. Gluchowski (1998), S. 17ff.
Vgl. Edelstein (1995), S. 1ff.
Insbesondere aufgrund der speziellen Anforderungen analytischer Systeme an eine relationale Datenhaltungskomponente, modelliert in Form des Star Schemas, hat zu einer neuen Gattung von Benchmarks geführt, vgl. hierzu auch Gluchowski/Hahne (1998).
Die Summe der Lagerendbestände je Monat ist im allgemeinen verschieden von dem Jahresendbestand des Lagers.
Vgl. Gabriel/Röhrs (1995) S. 121.
Vgl. Lang/Lockemann (1995) S. 308ff. für eine formale Darstellung sowie etwas kompakter in Gabriel/Röhrs (1995) S. 123ff.
Vgl. Gabriel/Röhrs (1995) S. 128, Lang/Lockemann (1995) S. 322ff. oder in einer etwas anderen Darstellung Kemper/Eickler (1996) S. 146ff.
Vgl. Hahne/Schelp (1997), S.35f.
Der hier verwendete Partitionierungs-Begriff ist zu differenzieren von dem Datenbanksystem-Begriff der Partitionierung von Tabellen, die sich auf die physische Modellebene bezieht. Diese Form der Partitionierung verteilt einzelne „Cluster“ der Tabelle in getrennte physikalische Bereiche, um damit im Rahmen einer Parallelisierung Performance-Gewinne zu erzielen. Eine so definierte Partitionierung von Dimensionstabellen macht nur bei extrem großen Dimensionen wirklich Sinn. Der Fokus liegt bei diesem Modellierungsansatz auf der physischen Modellebene in der Aufteilung von großen Faktentabellen in viele kleine Einheiten, um diese effizient parallel auswerten zu können. Unterschieden werden Verfahren, die auf einer Verteilungslogik basieren, und sogenannte Round-Robin-Verfahren, die eine zufällige Gleichverteilung anstreben.
Vgl. Raden (1996), S. 12.
Vgl. Kimball (1996), S. 95ff.
Die Normalisierung von Dimensionstabellen hat aufgrund ihrer negativen Implikationen auf die Performance von Abfragen gegenüber dem Ansatz der Partitionierung nur eine geringe praktische Bedeutung. Vielfach wird vereinfachend etwas unsauber nur von der Normalisierung gesprochen, aber im strengen Sinne die Partitionierung gemeint.
Vgl. Hahne (1999), S. 163ff. für eine Darstellung auch des Falles der Aggregation über verschiedene Ebenen in zwei Dimensionen.
Vgl. Raden (1996), S. 13.
Vgl. Stanford Technology Group (1995), S. 14.
Die im Kontext relationaler Datenbanksysteme auftretenden Metadaten in Form des Data Dictionaries sind hierfür nicht ausreichend, ein spezielles System mit der Kenntnis der Zusammenhänge von Faktentabellen und Aggregattabellen im Star Schema wird für die differenzierte Gestaltung von Aggregattabellen im Star Schema benötigt. Dieses ist keine allgemeine Funktionalität von Metadatenbanksystemen, sondern eine ganz spezielle metadatenbasierte Detaillösung, in derem Zusammenhang vielfach von ROLAP-Servern gesprochen wird, da diese genau diese Funktionalität implementieren.
Vgl. Nußdorfer (1998b), S. 20.
Dieses rührt sicherlich daher, dass diese Form auf physischer Modellebene die meisten Vorteile bietet, denn über einen einartributigen numerischen Schlüssel kann sehr gut indiziert werden.
Vgl. Gyssens/Lakshmanan (1996) für ein konzeptionelles Datenmodell, das angelehnt an das Relationenmodell ebenfalls Algebra und Kalkül mit gleicher Ausdruckskraft formal definiert.
Die Primärschlüssel-Attribute migrieren dabei mit dem gleichen Namen in das Fremdschlüssel-Attribut
Oftmals wird die Zeitdimension in eine Jahresdimension und eine Dimension der Monate getrennt modelliert. Letztere hat dann als obersten Knoten z. B. einen Knoten „Jahr Gesamt“.
Dabei wird nicht gefordert, dass es nur ein Terminal-Attribut geben darf, vgl. Lehner et. al. (1998), S.5.
Bei Lehner et. al. (1998) werden schwache funktionale Abhängigkeiten für die Definition von Hierarchien ausgeschlossen, da durch diese die Summierbarkeit nicht mehr gegeben ist. Vgl. Lehner et. al. (1998), S. 6.
Da die in der Relationenalgebra definierten Operatoren wie auch die in Standard-SQL abbildbaren Operationen sehr eingeschränkt sind, wurden in der Literatur Erweiterungen des Relationenmodells um spezielle Operatoren zur Berechnung von verdichteten Werten vorgeschlagen, vgl. z. B. Chatziantoniou/Ross (1996) sowie Özsoyoğlu/Özsoyoğlu/Matos (1987) für eine formale Erweiterung von Relationenalgebra und Relationenkalkül um Aggregat-Funktionen, die ebenfalls wieder gleich ausdrucksstark sind.
Die Normalformenlehre des Relationenmodells hat den Ansatz, Anomalien insbesondere durch Update-Operationen zu vermeiden.
Vgl. Lehner et. al. (1998). Der dort verwendete Begriff der Konsolidierung für Aggregation kommt aus dem Bereich der statistischen Datenbanken, die in weiten Teilen ähnliche Aspekte wie im OLAP betrachten, dafür aber zum Teil andere Begriffe verwenden. Für eine Gegenüberstellung der Gemeinsamkeiten und Unterschiede von OLAP und statistischen Datenbanken vgl. Shoshani (1997).
Zusätzlich wird noch das von Lenz/Shoshani (1997) postulierte Kriterium der Vollständigkeit für Dimensionen gefordert, vgl. Lenz/Shoshani (1997), S. 8f.
Vgl. Lehner et. al. (1998), S. 7ff.
Rights and permissions
Copyright information
© 2002 Springer Fachmedien Wiesbaden
About this chapter
Cite this chapter
Hahne, M. (2002). Mehrdimensionalität im Relationenmodell. In: Logische Modellierung mehrdimensionaler Datenbanksysteme. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-322-89790-9_4
Download citation
DOI: https://doi.org/10.1007/978-3-322-89790-9_4
Publisher Name: Deutscher Universitätsverlag, Wiesbaden
Print ISBN: 978-3-8244-2159-6
Online ISBN: 978-3-322-89790-9
eBook Packages: Springer Book Archive