1/48
Looks like no tags are added yet.
Name | Mastery | Learn | Test | Matching | Spaced | Call with Kai | Chat |
|---|
No analytics yet
Send a link to your students to track their progress
Historische Entwicklung der BI
1960er: MIS (Management Information Systems)
1970er: DSS (Decision Support Systems)
1980er: EIS (Executive Information Systems)
1990er: DWH (Data Warehouse)
2000er: BI
MIS (Management Information Systems)
Informationsversorgung des Managements
DSS (Decision Support Systems)
interaktive Analysen, statistische Algorithmen
EIS (Executive Information Systems)
multidimensionale Modellierung, Fokus auf Top-Management
DWH (Data Warehouse)
einheitliche, konsistente Datenbasis
BI
Oberbegriff für alle Analysewerkzeuge auf Basis des DWH
Analytische Anwendungen, Kennzahlsysteme, Data Mining, Balanced Scorecards
4 Merkmale eines Data Warehouse (nach Inmon)
Subject-oriented: themenorientierte Datenorganisation
Integrated: Zusammenführung heterogener Quellen
Nonvolatile: Daten werden nicht geändert/gelöscht
Time-variant: Zeitreihenanalysen möglich
BI-Verständnis eng
Kernapplikationen zur direkten Entscheidungsfindung ohne komplexe Modelle (OLAP, MIS, EIS)
BI-Verständnis analyseorientiert
direkte Analyse durch Nutzer mit Methoden/Modellen
BI-Verständnis weit
alle Anwendungen für Entscheidungsfindung inkl. Datenspeicherung
Operative Systeme: OLTP (Online Transaction Processing)
Aktuelle Daten, viele Nutzer, häufige Änderungen
Dispositive Systeme: OLAP (Online Analytical Processing)
Entscheidungsunterstützung, historische/verdichtete Daten, wenige Experten, komplexe Anfragen
BI-Referenzarchitektur (Komponenten)
Quellsysteme
Staging Area
ETL-Prozess (Extraktion, Transformation, Laden)
ODS (Operational Data Store)
Core Data Warehouse
Data Mart
Frontend
BI-Referenzarchitektur (Prozessphasen)
Datenbereitstellung
Informationsgenerierung, Speicherung und Distribution
Informationszugriff
Unabhängige Data Marts
Jede Abteilung eigenes DWH, einfach und schnell, aber unternehmensweite Auswertungen kaum möglich
Data Marts mit abgestimmten Datenmodellen
Alle Marts folgen einem gemeinsamen Datenmodell – bessere Konsistenz
Zentrales C-DWH (ohne Data Marts)
Monolithischer Ansatz, sinnvoll bei geringen Nutzerzahlen und kleinen Datenmengen, Nachteile bei Performance und Komplexität
Mehrere C-DWHs
Sinnvoll für spartenorientierte Großunternehmen mit unterschiedlichen Produkt- und Marktstrukturen
C-DWH mit abhängigen Data Marts
häufigste Variante in der Literatur, Data Marts werden aus dem C-DWH gespeist, kurze Antwortzeiten durch geringeres Datenvolumen in den Marts
DWH-Architektur-Mix
Kombination aller Varianten inkl. virtuellem DWH, häufig historisch gewachsen oder bewusst gestaltet
ETL-Prozess
Extraktion: relevante Daten aus Quellsystemen lesen
Transformation: Daten bereinigen und vereinheitlichen
Laden: Daten in das DWH schreiben
Transformationsschritte
Filterung
Harmonisierung
Aggregation
Anreicherung
Filterung (Transformationsschritt)
Selektion, Zwischenspeicherung, Bereinigung syntaktischer/semantischer Mängel
Harmonisierung (Transformationsschritt)
Schlüsselharmonien, Kodierungen, Synonyme/Homonyme vereinheitlichen
Aggregation (Transformationsschritt)
Verdichtung auf gewünschte Granularität
Anreicherung (Transformationsschritt)
Berechnung betriebswirtschaftlicher Kennzahlen
Mängelklassen
Klasse 1: automatisch erkannt und korrigiert
Klasse 2: automatisch erkannt, manuell korrigiert
Klasse 3: nur manuell erkannt und korrigiert
Data Mart
abteilungsbezogen, höher aggregiert, geringes Datenvolumen
C-DWH
unternehmensweit, höchste Detailtiefe, sehr großes Datenvolumen
ODS (Operational Data Store)
themenorientiert, integriert, zeitpunktbezogen, volatil, hoher Detaillierungsgrad
Keine Historisierung; Daten werden überschrieben
Metadaten passiv
dokumentieren Daten und deren Verhältnis zur Umwelt
Metadaten aktiv
Transformationsregeln, zur Laufzeit interpretierbar
Metadaten technisch
Fokus auf Filterung
Metadaten betriebswirtschaftlich
Fokus auf Harmonisierung, Aggregation, Anreicherung
OLAP-Würfel
Fakten: betriebswirtschaftliche Kennzahlen (z.B. Umsatz, Kosten)
Dimensionen: beschreibende Kontexte (z.B. Zeit, Region, Produkt)
Hierarchien: ermöglichen Aggregation und Navigation
OLAP-Operationen
Drill-Down
Roll-Up
Slice
Dice
Drill-Across
Pivotierung
Drill-Down
höhere Detaillierung z.B. von Quartalsdaten auf Monatsdaten
Roll-Up
Detaillierungsgrad verringern z.B. Monatsdaten auf Quartalsdaten
Slice
einzelne Scheibe aus dem Würfel herausschneiden z.B. nur Daten für eine bestimmte Region anzeigen
Dice
Teilwürfel ausschneiden z.B. Kennzahlen für eine bestimmte Kombination aus Region, Zeit und Produkt
Drill-Across
zwischen verschiedenen Würfeln wechseln, um Daten aus unterschiedlichen Themengebieten zu verknüpfen
Pivotierung
Würfel virtuell drehen, um Daten aus einer anderen Perspektive zu betrachten, die Reihenfolge der Dimensionen wird vertauscht
Physische Speicherkonzepte
ROLAP, MOLAP, HOLAP
ROLAP (Relationale Speicherung)
Multidimensionale Daten werden in zweidimensionalen relationalen Tabellen gespeichert
häufigste Variante, große Datenmengen
MOLAP (Multidimensionale Speicherung)
Daten werden direkt in einem multidimensionalen Datenbanksystem gespeichert (Array-Struktur)
sehr hohe Abfragegeschwindigkeit
nicht geeignet für sehr große Datenmengen
HOLAP (Hybride Speicherung)
Kombination aus ROLAP und MOLAP, Detaildaten in relationale Datenbank, aggregierte Daten in multidimensionale Datenbank
hoher Implementierungsaufwand, Kenntnisse beider Technologien erforderlich
Star-Schema
Zentrale Faktentabelle mit sternförmigen Dimensionstabellen, für jede Dimension eine Tabelle, Beziehungen nur zwischen Fakten- und Dimensionstabellen, Verknüpfung über Fremdschlüssel
Snowflake-Schema
Erweiterung des Star-Schemas: Dimensionstabellen nach funktionalen Abhängigkeiten normalisiert, mehr Tabellen, per SQL-Join verbunden
weniger Redundanz in Dimensionstabellen
Performance-Defizite durch viele Joins
Slowly Changing Dimensions (SCD)
Typ 1: Datensatz überschreiben, keine Historisierung
Typ 2: Gültigkeitsintervall (GültigVon/GültigBis), vollständige Historisierung
Typ 3: Zusatzattribut für neuen Wert, nur Ursprung und aktueller Zustand gespeichert