Data Warehouse Blueprints (eBook)
283 Seiten
Carl Hanser Verlag GmbH & Co. KG
978-3-446-45145-2 (ISBN)
Data-Warehouse-Lösungen mit Blueprints erfolgreich umsetzen
Dieses Buch gibt Ihnen einen Überblick über eine typische Data-Warehouse-Architektur und zeigt anhand von zahlreichen Best Practice-Beispielen, wie Sie die einzelnen Komponenten eines Data Warehouses realisieren und betreiben können. Skalierbarkeit, Performance und Integration sind dabei die wichtigsten Erfolgsfaktoren.
Der kompakte und kompetente Leitfaden für Ihr Projekt
Warum benötigt man eine Staging Area? Wie sollen fehlende oder fehlerhafte Daten beim Ladeprozess behandelt werden? Ist es zweckmäßiger, einen oder mehrere Data Marts zu erstellen? Wo werden die Daten aus verschiedenen Datenquellen integriert und wie sollen sie historisiert werden? Zu diesen und vielen weiteren Fragen erhalten Sie Antworten sowie Tipps und Tricks aus der Praxis.
Wertvolles Know-how aus der Praxis
Profitieren Sie von der langjährigen Erfahrung der Autoren. Die vorgestellten Konzepte und Vorgehensweisen haben sich bereits in zahlreichen Projekten bewährt.
AUS DEM INHALT
• Einleitung
• Architektur
• Datenmodellierung
• Datenintegration
• Design der DWH-Schichten
• Physisches Datenbankdesign
• BI-Anwendungen
• Betrieb
Claus Jordan, Dani Schnider, Joachim Wehner und Peter Welker sind Data-Warehouse-Architekten mit langjähriger Erfahrung aus zahlreichen BI-Projekten in unterschiedlichen Branchen. Ihr Fokus liegt vor allem in der breit gefächerten Oracle-Technologie - von der Datenbank über das Design, ETL, Frontends sowie Performance-Reviews bis hin zum Redesign von Data Warehouses.
Inhalt 5
Geleitwort 14
Über dieses Buch 16
Die Autoren 18
1 Einleitung 20
1.1 Ziele dieses Buches 21
1.2 Struktur dieses Buches 22
1.3 Hinweis zur Anwendung dieses Buches 23
2 Architektur 24
2.1 Data Warehouse-Architektur 24
2.1.1 Aufbau eines Data Warehouse 25
2.1.2 Transformationsschritte 28
2.1.3 Architekturgrundsätze 29
2.2 Architektur BI-Anwendungen 32
2.2.1 Die BI-Plattform zur Integration von Datenquellen 34
2.2.2 Die BI-Plattform zur Vereinheitlichung der Frontends 36
2.3 Datenhaltung 37
2.3.1 Grenzen gängiger DWH/BI-Technologien 38
2.3.2 Datenhaltung im Hadoop-Ecosystem 39
2.3.3 In-Memory-Datenbanken 42
3 Datenmodellierung 46
3.1 Vorgehensweise 46
3.1.1 Anforderungsgetriebene Modellierung 46
3.1.2 Quellsystemgetriebene Modellierung 48
3.1.3 Kombination der Ansätze 49
3.2 Relationale Modellierung 49
3.2.1 Darstellung von relationalen Datenmodellen 50
3.2.2 Normalisierung 50
3.2.3 Stammdaten und Bewegungsdaten 51
3.2.4 Historisierung 51
3.2.5 Relationales Core 53
3.2.6 Corporate Information Factory 54
3.2.7 Data Vault Modeling 54
3.3 Dimensionale Modellierung 56
3.3.1 Implementierung von dimensionalen Modellen 57
3.3.1.1 Relationale Implementierung 58
3.3.1.2 Multidimensionale Implementierung 59
3.3.2 Dimensionen 60
3.3.2.1 Fachliche Attribute 60
3.3.2.2 Technische Attribute 60
3.3.2.3 Hierarchien 61
3.3.2.4 Conformed Dimensions 62
3.3.2.5 Slowly Changing Dimensions 63
3.3.2.6 Zeitdimension 66
3.3.2.7 Bridge Tables 67
3.3.2.8 Spezielle Dimensionen 69
3.3.3 Fakten 70
3.3.3.1 Kennzahlen 70
3.3.3.2 Typen von Fakten 70
3.3.4 Modellierung spezieller Problemstellungen 72
3.3.4.1 Fakten unterschiedlicher Granularität und Rollen 72
3.3.4.2 Gemeinsame Hierarchiestufen in verschiedenen Dimensionen 73
3.3.4.3 Modellierungsgrundsätze für Dimensionen und Fakten 74
3.3.5 Darstellung von dimensionalen Modellen 75
3.3.5.1 ADAPT-Notation 75
3.3.5.2 Entity-Relationship-Diagramme 77
3.3.5.3 Data-Warehouse-Bus-Matrix 77
3.3.6 Dimensionales Core 78
3.4 Tools zur Datenmodellierung 79
3.4.1 Tools für relationale Datenmodellierung 79
3.4.2 Tools für dimensionale Datenmodellierung 80
4 Datenintegration 82
4.1 Data Profiling 83
4.1.1 Probleme mangelnder Datenqualität 83
4.1.2 Einsatz von Data Profiling 84
4.2 ETL 85
4.2.1 Aufgaben der ETL-Prozesse 86
4.2.1.1 Extraktion aus Quellsystemen 86
4.2.1.2 Transformationen 86
4.2.1.3 Laden in die Zieltabellen 87
4.2.2 ETL-Tools 87
4.2.2.1 Funktionalität von ETL-Tools 89
4.2.2.2 ETL oder ELT? 89
4.2.2.3 Positionierung von ETL-Tools 91
4.2.3 Performance-Aspekte 91
4.2.3.1 Mengenbasierte statt datensatzbasierte Verarbeitung 91
4.2.3.2 ELT-Tool statt ETL-Tool 92
4.2.3.3 Reduktion der Komplexität 93
4.2.3.4 Frühzeitige Mengeneinschränkung 94
4.2.3.5 Parallelisierung 95
4.2.4 Steuerung der ETL-Prozesse 97
4.2.4.1 Protokollierung des ETL-Ablaufs 97
4.2.4.2 Restartfähigkeit und Wiederaufsetzpunkte 98
4.3 Extraktion und Delta-Ermittlung 99
4.3.1 Delta-Extraktion im Quellsystem 100
4.3.1.1 Änderungsmarker und Journaltabellen 100
4.3.1.2 Delta-Ermittlung und Pending Commits 101
4.3.1.3 Change Data Capture 102
4.3.2 Voll-Extraktion und Delta-Abgleich im Data Warehouse 103
4.3.2.1 Zwei Versionen des Vollabzugs in der Staging Area 104
4.3.2.2 Vorteil einer Voll-Extraktion für die Delta-Ermittlung 106
4.3.3 Wann verwende ich was? 106
4.4 Fehlerbehandlung 107
4.4.1 Fehlende Attribute 108
4.4.1.1 Filtern von fehlerhaften Datensätzen 108
4.4.1.2 Fehlerhafte Datensätze in Fehlertabelle schreiben 108
4.4.1.3 Singletons auf Attributebene 109
4.4.2 Unbekannte Codewerte 109
4.4.2.1 Filtern von fehlerhaften Datensätzen 110
4.4.2.2 Singletons auf Datensatzebene 110
4.4.2.3 Generierung von Embryo-Einträgen 110
4.4.3 Fehlende Dimensionseinträge 111
4.4.3.1 Filtern von unvollständigen Fakten 112
4.4.3.2 Referenz auf Singleton-Einträge 113
4.4.3.3 Generieren von Embryo-Einträgen 114
4.4.4 Doppelte Datensätze 115
4.4.4.1 Verwendung von DISTINCT 116
4.4.4.2 Nur ersten Datensatz übernehmen 116
4.5 Qualitätschecks 116
4.5.1 Qualitätschecks vor und während des Ladens 117
4.5.2 Qualitätschecks nach dem Laden 118
4.5.3 Qualitätschecks mithilfe von Test-Tools 118
4.6 Real-Time BI 119
4.6.1 Begriffsbestimmung 120
4.6.2 Garantierte Verfügbarkeit von Informationen zu gegebenem Zeitpunkt 120
4.6.3 Verfügbarkeit von Informationen simultan zur Entstehung 121
4.6.4 Verfügbarkeit von Informationen kurz nach ihrer Entstehung 123
4.6.4.1 Events und Batchverarbeitung 124
4.6.4.2 Real-Time-Partitionen 125
4.6.5 Zusammenfassung 126
5 Design der DWH-Schichten 128
5.1 Staging Area 129
5.1.1 Gründe für eine Staging Area 130
5.1.2 Struktur der Stage-Tabellen 131
5.1.3 ETL-Logik für Stage-Tabellen 132
5.1.3.1 Einschränkungen bei der Extraktion 133
5.1.3.2 Transformation 133
5.1.3.3 Sonstige Informationen 134
5.2 Cleansing Area 134
5.2.1 Gründe für eine Cleansing Area 134
5.2.2 Struktur der Cleanse-Tabellen 135
5.2.3 Beziehungen in der Cleansing Area 137
5.2.4 ETL-Logik für Cleanse-Tabellen 139
5.2.4.1 Einschränkungen bei der Extraktion 140
5.2.4.2 Transformation 140
5.2.4.3 Sonstige Informationen 141
5.3 Core-Datenmodell allgemein 141
5.3.1 Aufgaben und Anforderungen an das Core 142
5.3.2 Stammdaten im Core 143
5.3.3 Bewegungsdaten im Core 143
5.3.4 Beziehungen im Core 143
5.3.5 Datenmodellierungsmethoden für das Core 144
5.4 Core-Datenmodell relational mit Kopf- und Versionstabellen 145
5.4.1 Historisierung von Stammdaten mit Kopf- und Versionstabellen 146
5.4.2 Struktur der Stammdatentabellen 147
5.4.2.1 Tabellenspalten und Schlüssel 148
5.4.2.2 Beziehungen (1:n) zwischen Stammdaten 151
5.4.2.3 Beziehungen (m:n) zwischen Stammdaten 152
5.4.3 ETL-Logik für Stammdatentabellen 154
5.4.3.1 Lookups (Schritt 1) 155
5.4.3.2 Outer Join (Schritt 2) 156
5.4.3.3 Neue Datensätze (Schritt 3) 160
5.4.3.4 Schließen einer Version/Fall 1 (Schritt 4) 161
5.4.3.5 Aktualisieren/Fall 2 (Schritt 5) 161
5.4.3.6 Versionieren/Fall 3 und 4 (Schritt 6) 161
5.4.3.7 Singletons 161
5.4.4 Typen von Bewegungsdaten 162
5.4.4.1 Transaction Tables 163
5.4.4.2 Snapshot Tables 163
5.4.4.3 Snapshot Tables versioniert 164
5.4.5 Struktur der Bewegungstabellen 165
5.4.5.1 Tabellenspalten und Schlüssel 166
5.4.5.2 Beziehungen zu Stammdaten 169
5.4.6 ETL-Logik für Bewegungstabellen 172
5.4.6.1 Lookups 173
5.4.6.2 Sonstige Informationen 174
5.4.7 Views für externen Core-Zugriff 174
5.4.7.1 Views für Stammdaten 175
5.4.7.2 Views für Bewegungsdaten 179
5.5 Core-Datenmodell relational mit Data Vault 180
5.5.1 Stammdaten 180
5.5.2 Beziehungen 181
5.5.3 Bewegungsdaten 181
5.5.4 Historisierung 182
5.5.5 Struktur der Tabellen 182
5.5.5.1 Hubtabellen – Tabellenspalten und Schlüssel 182
5.5.5.2 Satellitentabellen – Tabellenspalten und Schlüssel 183
5.5.5.3 Linktabellen – Tabellenspalten und Schlüssel 184
5.5.6 ETL-Logik 185
5.5.7 Views für externen Core-Zugriff auf das Data-Vault-Datenmodell 186
5.5.7.1 Views für Stammdaten (ein Satellite pro Hub bzw. Link) 186
5.5.7.2 Views für Stammdaten (mehrere Satellites pro Hub bzw. Link) 189
5.6 Core-Datenmodell dimensional 192
5.6.1 Star- oder Snowflake-Schema 193
5.6.1.1 Star-Schema 193
5.6.1.2 Snowflake-Schema 194
5.6.2 Historisierung von Stammdaten mit SCD 196
5.6.3 Struktur der Dimensionstabellen (Snowflake) 199
5.6.3.1 Tabellenspalten und Schlüssel 200
5.6.3.2 Beziehungen zwischen Hierarchiestufen 203
5.6.4 ETL-Logik für Dimensionstabellen (Snowflake) 204
5.6.4.1 Lookup 204
5.6.4.2 Weitere Schritte 205
5.6.5 Struktur der Faktentabellen (Snowflake) 205
5.6.6 ETL-Logik für Faktentabellen (Snowflake) 207
5.6.7 n:m-Beziehungen im dimensionalen Core 207
5.7 Marts 209
5.7.1 ROLAP oder MOLAP? 210
5.7.2 Historisierung von Data Marts 211
5.7.3 Star- oder Snowflake-Schema (ROLAP) 212
5.7.4 Struktur der Dimensionstabellen (Star) 213
5.7.4.1 Tabellenspalten und Schlüssel 213
5.7.4.2 Beispiel für Conformed Rollup 216
5.7.4.3 Beispiel für Dimension mit mehreren Hierarchien 217
5.7.5 ETL-Logik für Dimensionstabellen (Star) 218
5.7.5.1 Extraktion aus dem relationalen Core 219
5.7.5.2 Extraktion aus dem dimensionalen Core 226
5.7.6 Struktur der Faktentabellen (Star-Schema) 228
5.7.7 ETL-Logik für Faktentabellen (Star) 229
5.7.8 Multidimensionale Data Marts 229
5.7.8.1 Dimensionen (Cube) 230
5.7.8.2 Fakten (Cube) 231
6 Physisches Datenbankdesign 234
6.1 Indexierung 235
6.1.1 Staging Area 236
6.1.2 Cleansing Area 236
6.1.3 Core 236
6.1.4 Data Marts 237
6.2 Constraints 238
6.2.1 Primary Key Constraints 238
6.2.2 Foreign Key Constraints 239
6.2.3 Unique Constraints 240
6.2.4 Check Constraints 240
6.2.5 NOT NULL Constraints 241
6.3 Partitionierung 241
6.3.1 Grundprinzip von Partitionierung 242
6.3.2 Gründe für Partitionierung 242
6.3.3 Partitionierung in Staging und Cleansing Area 243
6.3.4 Partitionierung im Core 244
6.3.5 Partitionierung in den Data Marts 244
6.4 Datenkomprimierung 245
6.4.1 Redundanz 246
6.4.2 Wörterbuchmethode/Tokenbasierte Reduktion 246
6.4.3 Entropiekodierung 246
6.4.4 Deduplikation 247
6.4.5 Komprimierung bei spaltenorientierter Datenhaltung 247
6.5 Aggregationen 248
6.5.1 Vorberechnete Aggregationen 249
6.5.2 Query Rewrite 249
6.5.3 Einsatz im Data Warehouse 250
7 BI-Anwendungen 252
7.1 Überblick 252
7.2 Standardberichte 255
7.3 Ad-hoc-Analyse 257
7.4 BI-Portale 258
8 Betrieb 260
8.1 Release-Management 260
8.1.1 Kategorisierung der Anforderungen 261
8.1.2 Schnittstellen zu Quellsystemen 262
8.1.3 Umgang mit historischen Daten 264
8.1.4 Datenbankumgebungen 265
8.2 Deployment 267
8.2.1 Manuelles Deployment 267
8.2.2 Filebasiertes Deployment 268
8.2.3 Repository-basiertes Deployment 269
8.2.4 Kombiniertes Deployment 269
8.3 Monitoring 271
8.3.1 Betriebsmonitoring 271
8.3.2 System und DB-Monitoring 271
8.3.3 ETL-Monitoring 271
8.3.4 Performance-Monitoring 272
8.4 Migration 274
8.4.1 Datenbank 275
8.4.2 ETL-Tool 276
8.4.3 BI-Tools 277
Literatur 278
Index 280
| 3 | Datenmodellierung |
Die Erstellung eines geeigneten Datenmodells ist in vielen Data Warehouses eine der größeren Herausforderungen. Wie werden die analytischen Anforderungen an das Data Warehouse in geeignete Datenstrukturen übersetzt? Das vorliegende Kapitel befasst sich mit der Thematik der Datenmodellierung im Data Warehouse.
-
Abschnitt 3.1 beschreibt die unterschiedlichen Vorgehensweisen für die Datenmodellierung im Data Warehouse mit ihren Vor- und Nachteilen.
-
Abschnitt 3.2 gibt einen kurzen Überblick über die relationale Datenmodellierung und zeigt auf, in welchen Bereichen im Data Warehouse sie eingesetzt werden kann.
-
Abschnitt 3.3 erklärt die wichtigsten Konzepte und Begriffe der dimensionalen Datenmodellierung. Diese Art der Datenmodellierung kommt in fast allen DWH-Systemen zur Anwendung, zumindest für die Implementierung von Data Marts.
-
Das Kapitel schließt mit Hinweisen zu Datenmodellierungswerkzeugen, die in Abschnitt 3.4 zusammengefasst sind.
| 3.1 | Vorgehensweise |
Um ein Data Warehouse zu modellieren, also die Datenmodelle für Staging Area, Cleansing Area, Core und Data Marts zu entwickeln, gibt es verschiedene Vorgehensweisen. Nachfolgend werden zwei typische Ansätze vorgestellt. In den meisten DWH-Projekten werden Mischformen davon eingesetzt.
| 3.1.1 | Anforderungsgetriebene Modellierung |
Bei diesem Ansatz werden zuerst die analytischen Anforderungen mittels fachlicher Analyse und Betrachtung der fachlichen Zusammenhänge ermittelt. Daraus werden die Datenmodelle der Data Marts und des Core abgeleitet. Erst dann werden die Quellsysteme untersucht, um zu ermitteln, woher die Daten beschafft werden können. Im Rahmen einer Gap-Analyse wird untersucht, welche erforderlichen Daten nicht in der gewünschten Form zur Verfügung stehen und unter Umständen von weiteren Datenquellen beschafft werden müssen.
Der Vorteil der in Bild 3.1 dargestellten Vorgehensweise ist, dass nur die fachlich relevanten Informationen im Data Warehouse gespeichert werden. Allerdings kann dies auch zu einem Nachteil werden: Werden in weiteren Phasen zusätzliche Anforderungen an das DWH gestellt, fehlen die dazu benötigten Informationen im Core, und das Datenmodell sowie die Schnittstellen zu den Quellsystemen und die ETL-Prozesse müssen nachträglich erweitert werden. Dieser Ansatz eignet sich deshalb nur dann, wenn die analytischen Anforderungen an das Data Warehouse bekannt und einigermaßen vollständig sind. Nachträgliche Erweiterungen sind möglich, aber aufwendig.
Bild 3.1 Anforderungsgetriebene Datenmodellierung
Wichtig bei diesem Ansatz ist deshalb, dass die Fachbereiche, die mit den Data Marts arbeiten werden, bereits zu Beginn des Projekts in die Entscheidungsprozesse eingebunden werden. Welche Informationen in welcher Form in den Data Marts zur Verfügung stehen sollen, muss von den zuständigen Fachbereichen festgelegt werden. Aus diesem Grund sollten geeignete Fachvertreter bei der Anforderungsanalyse und der logischen Modellierung der Data Marts involviert sein.
Die logische Datenmodellierung der Data Marts, also das Festlegen von Dimensionen und Hierarchien sowie Kennzahlen und Fakten, sollte nicht IT-getrieben, sondern in Zusammenarbeit zwischen dem DWH-Entwicklungsteam und den zuständigen Fachbereichen durchgeführt werden. Die physische Datenmodellierung der Data Marts, insbesondere die technische Umsetzung mittels relationaler oder multidimensionaler Technologie, wird ausschließlich von der Informatik gemacht. Die Fachseite wird für diese Aufgaben nicht einbezogen.
Bei der Datenmodellierung des Core besteht die Hauptschwierigkeit darin zu entscheiden, welche zusätzlichen Informationen im Core gespeichert werden sollen. Werden nur genau die Daten ins Core übernommen, die in den Data Marts benötigt werden, tritt bei zusätzlichen Anforderungen oder der Erweiterung bestehender Data Marts das Problem auf, dass das Core auch erweitert werden muss. Dies ist mit viel Aufwand verbunden. Deshalb sollte von Anfang an bei der Modellierung des Core überlegt werden, welche Daten fachlich relevant sein können und somit „auf Vorrat“ im Core abgelegt werden sollen. Ein empfehlenswerter Ansatz ist es, die Daten in der feinsten Granularität, die vom Quellsystem geliefert wird, im Core abzulegen und in den Data Marts auf die erforderliche Verdichtungsstufe zu aggregieren.
| 3.1.2 | Quellsystemgetriebene Modellierung |
Dieser Ansatz geht von den zur Verfügung stehenden Daten der Quellsystemeaus, wie in Bild 3.2 dargestellt. Vorerst wird — in der Regel IT-getrieben — ermittelt, welche Informationen für das Data Warehouse relevant sind. Daraus wird das Datenmodell für das Core erstellt. Basierend auf dem Core werden dann in Zusammenarbeit mit den Fachabteilungen für unterschiedliche Bedürfnisse spezifische Data Marts erstellt. Wenn sich bei der Modellierung der Data Marts herausstellt, dass gewisse Informationen nicht zur Verfügung stehen, muss das Core entsprechend erweitert werden.
Bild 3.2 Quellsystemgetriebene Datenmodellierung
Diese Vorgehensweise wird oft verwendet, wenn die analytischen Anforderungen der Fachbereiche an das Data Warehouse noch unklar oder nur ansatzweise vorhanden sind. Darin besteht auch die Gefahr dieses Ansatzes: Oft werden zu viele oder die falschen Daten ins DWH übernommen, und das Core tendiert zu einem Archivierungssystem für Daten, die in keinem Data Mart benötigt werden. Wenn nur ein Quellsystem vorhanden ist, wird das Core mit großer Wahrscheinlichkeit nichts anderes als eine historisierte Kopie des Quellsystems werden, indem das gleiche oder ein sehr ähnliches Datenmodell verwendet wird.
Ein reiner quellsystemgetriebener Ansatz sollte als Vorgehensweise für die Datenmodellierung eines Data Warehouse möglichst vermieden werden, da es typischerweise zu DWH-Systemen mit vielen Daten führt, aber nicht den erforderlichen Informationen, die von den Fachbereichen benötigt werden.
| 3.1.3 | Kombination der Ansätze |
Eine sinnvolle und oft angewendete Vorgehensweise ist es, in einem ersten Schritt die anforderungsgetriebene Datenmodellierung zu wählen, um dann in einer zweiten Phase mithilfe der quellsystemgetriebenen Modellierung das Datenmodell zu ergänzen.
Durch die Kombination der beiden Modellierungsvarianten kann sichergestellt werden, dass die Anforderungen an die Data Marts erfüllt werden. Zusätzlich werden fachlich relevante Informationen ins Core übernommen, die momentan zwar noch nicht benötigt werden, aber in Zukunft von Interesse sein könnten.
| 3.2 | Relationale Modellierung |
Die relationale Datenmodellierung wird typischerweise in OLTP-Systemen eingesetzt. Ein großer Teil der Quellsysteme, welche Daten an ein Data Warehouse liefern, besitzen ein Datenmodell in 3. Normalform.
Ob diese Art der Datenmodellierung auch im Data Warehouse eingesetzt werden soll, hängt von verschiedenen Faktoren — und Meinungen — ab. Während für Data Marts hauptsächlich dimensionale Datenmodelle verwendet werden (siehe Abschnitt 3.3), wird für das Core je nach verwendeter Architektur ein dimensionales oder ein relationales Datenmodell verwendet. Auch Mischformen zwischen diesen Ansätzen sind weit verbreitet.
Varianten von relationalen Core-Modellen
In der von William H. Inmon definierten DWH-Architektur Corporate Information Factory (CIF) besitzt das zentrale Enterprise Data Warehouse ein normalisiertes Datenmodell in 3. Normalform. Ebenfalls auf relationalen Konzepten basierend und in den letzten Jahre vermehrt eingesetzt wird Data Vault Modeling, ein von Dan Linstedt definierter Modellierungsansatz für Data Warehouses. Diese beiden Ansätze werden am Ende dieses Kapitels kurz beschrieben.
| 3.2.1 | Darstellung von relationalen Datenmodellen |
Relationale Datenmodelle werden typischerweise als Entity-Relationship-Diagramme dargestellt. Die Entitätstypen werden als Tabellen implementiert. Die Beziehungen (Relationships) zwischen den Entitäten werden als Fremdschlüsselbeziehungen bzw. Foreign Key Constraints implementiert.
Entitätstypen werden im Entity-Relationship-Diagramm als Rechtecke dargestellt. Je nach verwendeter Darstellung und Modellierungstool werden darin nur die Namen der Entitätstypen oder auch die Attribute aufgeführt. Die Verbindungen zwischen den Entitätstypen werden als Linien zwischen den einzelnen Rechtecken dargestellt.
Für die Kardinalitäten und Bedeutungen der Beziehungen gibt es ebenfalls verschiedene Darstellungen (Chen, IDEF1X, UML, Bachmann etc.). Bild 3.3 zeigt ein Beispiel eines Entity-Relationship-Diagramms mit IDEF1X-Notation, erstellt mit dem CA Erwin Data Modeler.
Bild 3.3 Entity-Relationship-Diagramm eines normalisierten Datenmodells
| 3.2.2 | Normalisierung |
Das wichtigste Grundkonzept der relationalen Datenmodellierung ist die Normalisierung der Daten. Ziel der Normalisierung ist es, Redundanz zu vermeiden. Der ursprüngliche Grund, damit Speicherplatz zu sparen, ist heute nicht mehr relevant. Nach wie vor wichtig ist es aber, durch die Vermeidung mehrfach gespeicherter Daten sicherzustellen, dass die Datenkonsistenz gewährleistet werden kann. Ein redundanzfreies relationales...
| Erscheint lt. Verlag | 10.10.2016 |
|---|---|
| Verlagsort | München |
| Sprache | deutsch |
| Themenwelt | Mathematik / Informatik ► Informatik ► Netzwerke |
| Schlagworte | Architektur • BI • Big Data • data integration • Datenbank • Datenqaulität • Oracle • Performance |
| ISBN-10 | 3-446-45145-5 / 3446451455 |
| ISBN-13 | 978-3-446-45145-2 / 9783446451452 |
| Haben Sie eine Frage zum Produkt? |
PDF (Wasserzeichen)Größe: 10,2 MB
DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasserzeichen und ist damit für Sie personalisiert. Bei einer missbräuchlichen Weitergabe des eBooks an Dritte ist eine Rückverfolgung an die Quelle möglich.
Dateiformat: PDF (Portable Document Format)
Mit einem festen Seitenlayout eignet sich die PDF besonders für Fachbücher mit Spalten, Tabellen und Abbildungen. Eine PDF kann auf fast allen Geräten angezeigt werden, ist aber für kleine Displays (Smartphone, eReader) nur eingeschränkt geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür einen PDF-Viewer - z.B. den Adobe Reader oder Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür einen PDF-Viewer - z.B. die kostenlose Adobe Digital Editions-App.
Zusätzliches Feature: Online Lesen
Dieses eBook können Sie zusätzlich zum Download auch online im Webbrowser lesen.
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
EPUB (Wasserzeichen)Größe: 24,3 MB
DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasserzeichen und ist damit für Sie personalisiert. Bei einer missbräuchlichen Weitergabe des eBooks an Dritte ist eine Rückverfolgung an die Quelle möglich.
Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belletristik und Sachbüchern. Der Fließtext wird dynamisch an die Display- und Schriftgröße angepasst. Auch für mobile Lesegeräte ist EPUB daher gut geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür die kostenlose Software Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür eine kostenlose App.
Geräteliste und zusätzliche Hinweise
Zusätzliches Feature: Online Lesen
Dieses eBook können Sie zusätzlich zum Download auch online im Webbrowser lesen.
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich
