Vorlesung Grundlagen betrieblicher Informationssysteme Prof. Dr. Hans Czap Email: Hans.Czap@uni-trier.de - II - 1 -
Inhalt Kap. 1 Ziele der Datenbanktheorie Kap. 2 Datenmodellierung und Datenbankentwurf Kap. 3 Datenbankarchitektur kt Kap. 4 Die Datenbanksprache SQL Kap. 5 Konzepte für Objektorientierte Datenbanken Kap. 6 Objektrelationale Datenbanken Kap. 7 Datenbankentwurf: Funktionale Abhängigkeiten gg und Normalisierung Kap. 8 Datenintegrität Sperrprotokolle Recovery Kap. 9 Data-Warehouse-Konzept Kap. 10 Data Mining und Knowledge Discovery - II - 2 -
Data-Warehouses Die Bereitstellung von Daten für Entscheidungsunterstützungen (DSS = Decision Support Systeme, EIS Executive Information Systems) erfordert in vielen Fällen den Rückgriff auf historische i h Daten und/oder d spezifische, zeitaufwendige Datenkombinationen. Der gemeinsame Betrieb operativer IS und die Unterstützung strategischer bzw. grundsätzlicher Entscheidungen würde den operativen Betreib massiv beeinträchtigen. Verwendung eigener Hard- und Softwaresysteme Literatur: Bauer, Günzel (Hrsg.): Data Warehouse Systemedpunkt Verlag, Heidelberg, 2., überarbeitete und aktualisierte Auflage, 2004 - II - 3 -
OLTP versus OLAP OLTP = Online Transaction Processing Verarbeitung und Abfragen von Daten des operativen Geschäfts: einfache Abfragen (Abfragen, bei denen nur wenige Relationen verknüpft werden müssen), Datenänderungen bei hoher Parallelität, hohes Transaktionsvolumen große Anzahl paralleler Abfragen große Anzahl paralleler l Updates hohe Wiederholung der ähnlicher Anfragen (Standardisierbarkeit) Technologische Basis: relationales Datenbanksystem Beispiele: Suche den am nächsten gelegenen Lagerort des Artikels X Erhöhe/Erniedrige die Lagermenge des Artikels X um Y Stück Verbuche die Zahlung der Rechnung Z - II - 4 -
OLTP versus OLAP OLAP: Online Analytical Processing Ermittlung von Trends Extrapolation von Entwicklungen Basis: historische Daten, die nach unterschiedlichen Kriterien gruppiert und ausgewertet werden Beispiele Verdichtung nach Kundengruppen, geographischen Regionen unterschiedlichen Zeiträumen Produktsparten Vertretern etc. Analytische Auswertungen werden betont: Abfragen hoher Komplexität (keine Updates, nur Abfragen!) geringes Transaktionsvolumen geringer Wiederholungsgrad riesiges zu speicherndes Datenvolumen (Größenordnung im Tera-Byte-Bereich!) Bereich!) Data Ware House - II - 5 -
Data-Warehouse: Konzept und Anwendungsidee Trennung von statistischen Auswertungen und operationalen Anwendungen Integration verschiedener Datenquellen zum Bau von Entscheidungsunterstützungssystemen Ein Data-Warehouse ist themenbezogen, integriert, zeitveränderlich und nichtflüchtig Schritte zum Einrichten eines Data-Warehouse Extrahieren von Daten aus operationalen Datenbanken, Laden eines initialen Data-Set, periodisches Aktualisieren dessen, Transformation von Quelldaten in das Warehouse-Datenmodell. - II - 6 -
- II - 7 -
- II - 8 -
Phasen des Data-Warehousing Trennung von statistischen Auswertungen und operationalen Anwendungen Integration verschiedener Datenquellen zum Bau von Entscheidungsunterstützungssystemen Ein Data-Warehouse ist themenbezogen, integriert, zeitveränderlich und nichtflüchtig Schritte zum Einrichten eines Data-Warehouse Extrahieren von Daten aus operationalen Datenbanken, Laden eines initialen Data-Set, periodisches Aktualisieren dessen, Transformation von Quelldaten in das Warehouse-Datenmodell. - II - 9 -
Anforderungen an ein Data-Warehouse im Unterschied von OLTP und OLAP Entfallen aufwendiger Konzepte wie Transaktionsmanager und Recovery- Mechanismus Konfiguration der Daten entsprechend den geplanten Auswertungen (z.b. hierarchisch h verdichtet) t) Aufwendige Indexierung (z.t. Vollindexierung mittels Bit-Maps) expliziter Zeitbezug der Daten eines Data Warehouse keine Normalisierung zu Gunsten von größerer Performance - II - 10 -
Referenzmodell Architektur Data-Warehousing Eine Referenzarchitektur enthält die grundsätzlichen Strukturen. Es ist ein statisches Konzept, das nur gelegentlich angepasst wird. Ermöglicht strukturierte Vergleiche zwischen unterschiedlichen Data- Warehouse-Systemen bzw. unterschiedlichen Komponenten derartiger Systeme Hat standardisierenden Charakter und dient als Basis konkreter Implementierungen Vermittelt ein gemeinsames Verständnis von DW-Systemen Idealtypisches Konzept, funktionsorientiert - II - 11 -
Analyse Abb. 2-1 Referenzmodell für die Architektur von Data- Warehouse-Systemen (Referenzarchitektur) Data Warehouse Laden Data- Warehouse- Manager Metadaten- t Manager Repositorium Basis- Datenbank Laden Arbeitsbereich Transformation Extraktion Monitor Datenbeschaffungsbereich Datenquelle - II - 12 - Datenfluss Kontrollfluss
Die Komponenten der DW-Architektur DW-Manager steuert, initiiert und überwacht die einzelnen DW-Prozesse von der Extraktion der Daten bis hin zur Analyse Varianten der Initialisierung: regelmäßige Zeitintervalle, in Abhängigkeit des geänderten Datenvolumens, durch expliziten Anstoß Monitore entdecken und melden dem DW-Manager Änderungen in den Quellen, die für das DW relevant sind Extraktoren selektieren und transportieren die Daten aus den Datenquellen in den Arbeitsbereich Transformatoren vereinheitlichen, itli h bereinigen, i integrieren, i konsolidieren, aggregieren und ergänzen extrahierte Daten im Arbeitsbereich Ladekomponenten übertragen die bereinigten Daten aus dem Arbeitsbereich in die Basisdatenbank und anschließend in das DW Analysekomponenten analysieren die Daten und präsentieren die Ergebnisse - II - 13 -
Die Komponenten der DW-Architektur Datenquellen Datenquellen sind sämtliche dem DW vorgelagerten Systeme, die Daten an das DW liefern. Auswahlkriterien: Zweck des DW Qualität der Quelldaten Verfügbarkeit (rechtlich, sozial, organisatorisch, technisch) Preis Anforderungen an die Qualität der Quelldaten Konsistenz Korrektheit Vollständigkeit Genauigkeit it und Granularität Zuverlässigkeit und Glaubwürdigkeit Verständlichkeit Verwendbarkeit und Relevanz - II - 14 -
Die Komponenten der DW-Architektur Monitore Komponente, die Datenänderungen in den Datenquellen meldet. Typischerweise wird pro Datenquelle ein eigener Monitor benötigt Monitor-Strategien, basierend auf den Konzepten: Trigger Replikation Zeitstempel Logdatei Snapshot Arbeitsbereich Dient der temporären Zwischenspeicherung. Ziel: Integration der Daten Verwaltung durch den DW-Administrator - II - 15 -
Die Komponenten der DW-Architektur Extraktionskomponente: Übertragung aus Datenquelle in Arbeitsbereich Wie bereits notiert gibt es folgende Alternativen: periodisch, auf Anfrage, ereignisgesteuert, bei jeder Änderung Transformationskomponente Hat den Zweck, die Daten in einheitliches Format zu übertragen und die semantische Korrektheit sicherzustellen Datenmigration Anpassung von Datentypen (Vereinheitlichung von Zeichenketten, Datumsangaben, Kombination bzw. Separierung von Attributwerten) t t Konvertierung unterschiedlicher Kodierungen Umrechnung von Maßeinheiten Data-Cleansing (Datenbereinigung) Data Scrubbbing Ausnutzung anwendungsspezifischer Information, um semantische Unzulänglichkeiten zu beseitigen» Anpassung der semantischen Zuordnung von Daten» Beseitigung von Doubletten Data Auditing Identifizieren von (möglicherweise fehlerhaften) Ausreißern mit Hilfe von Data Mining. - II - 16 -
Ladekomponente Die Komponenten der DW-Architektur Übertragung der Daten aus dem Arbeitsbereich in die Basisdatenbank. Typischerweise als inkrementelles Laden realisiert. Dabei wird ein geänderter Satz im DW nicht überschrieben, sondern zusätzlich angelegt. Weiteres Problem bereiten die z.t. sehr hohen Ladevolumina. Online Ladevorgang Offline Ladevorgang Basisdatenbank Versorgt die sich anschließenden DW s mit den erforderlichen Daten (Distributionsfunktion) Stellt dazu eine anwendungsunabhängige integrierte Sicht der Daten bereit Sie enthält die Basisdaten im erforderlichen Detailierungsgrad. Sie enthält keine Aggregate ( single point of truth ): Nachvollziehbarkeit und Verfügbarkeit Die Aktualisierungshäufigkeit hängt von den Erfordernissen der DW- Anwendungen ab Allerdings wird in vielen Implementierungen auf die Basisdatenbank verzichtet. - II - 17 -
Data Warehouse Die Komponenten der DW-Architektur Das DW ist die den gewünschten Analysen zugrunde liegende Datenbank. Ziel: Bereitstellung und Verwaltung der Daten für die gewünschte Analyse. Daten sind im DW analysebezogen gespeichert ( Star-Schema und Snowflake-Schema) Data Marts (historischer i h Begriff, heute bzw. bei Verwendung einer Basisdatenbank weitgehend überholt) Teilsicht eines DW, das organisatorischen Gegebenheiten Rechnung trägt (z.b. Datenschutzaspekte, t Lastverteilung, t Eigenständigkeit it (z.b. Mobilität) bestimmter t Anwendungen Im Gegensatz zum View-Konzept von RDBMS, das die physische Anordnung der Daten nicht verändert (nur logische Sicht auf die Daten) bestehen Data Marts aus anwendungsbezogenen Anordnungen bzw. Umgruppierungen der Daten des Data- Warehouse (materialisierte Views). Zur Pflege dieser Daten (Aktualisierungen!), aber auch zur Erstellung anwendungsspezifischer Reports und Auswertungen sowie der Betreuung der spezifischen Fachabteilungen wird in der Literatur von dem Data-Mart-Administrator gesprochen. Die automatische Aktualisierung der Daten eines Data-Mart erfolgt durch den bereits erwähnten Integrator. - II - 18 -
Analyse Die Komponenten der DW-Architektur Die eigentliche Auswertung der Daten. Analysemethoden (Businesss Intelligence Tools BI-Tools BI-Tools ) Reporting : Werkzeuge zur Erstellung von Berichten und zur Datenrepräsentation. Z.B. Ampelfunktion um Abweichungen von vorgegebenen Bereichen kenntlich zu machen, Tortendiagramme, Säulendiagramme, Tabellen, Grafiken etc. Online Analytical Processing (OLAP): Interaktives Arbeiten mit multidimensionalen Würfeln drill down / roll up: Detaillieren und Verdichten in einer Dimension drill through slice: Herausschneiden einer Scheibe aus dem OLAP-Würfel durch Fixierung einer Dimensionsausprägung. dice (= würfeln würfeln = Drehen des Würfels, Sichtbarmachen anderer Dimensionen) Data Mining - II - 19 -
- II - 20 -
OLAP als Mittel zur Unterstützung von Entscheidungen Die Dimensionen als entscheidungsrelevante Größen müssen vorab festgelegt werden. Anfragen, die sich nicht diesem vorgefertigten Schema unterordnen, können entweder nicht oder nur nach erheblichem Aufwand beantwortet werden. Innovative Fragestellungen werden deswegen nicht ausreichend unterstützt. Betonung zeitlicher Verläufe und damit zusammenhängender Operationen, wie Trendanalysen und Prognose-Rechnungen g Verknüpfung der Daten unterschiedlicher Dimensionen nach relativ einfachen Kriterien, z.b. zur Abweichungsanalyse (Vergleich von Soll und Ist-Daten) oder zur Bildung von Kennziffernsystemen. - II - 21 -
Data Mining als Mittel zur Unterstützung von Entscheidungen Auswertung der im Data Warehouse gehaltenen Daten mit dem Ziel neue Zusammenhänge bzw. Zusammenhangsmuster (Pattern-Analyse) zu entdecken. Konkret ist dabei an Assoziationen bzw. der Analyse von Sequenzen zu denken. Klassifikation von Daten mit dem Ziel Risiko-Faktoren zu entdecken bzw. Ef Erfolgsgruppen (z.b. für Marketing-Aktivitäten) ität zu identifizieren i bzw. zu selektieren. Typisches Anwendungsbeispiel: Klassifikation von Konsumenten, die um einen Kredit nachsuchen, in Risikogruppen. Verwendung von Techniken der Statistik Anwendung maschineller Lernverfahren - II - 22 -
Die Komponenten der DW-Architektur Repositorium Enthält die Metadaten des DW. Sie werden von den Nutzern zum Verständnis benötigt und von Monitor und ETL-Prozessoren zur Steuerung der Prozesse: Fachliche Metadaten Anwendungsspezifische Dokumentationen zu standardisierten Anfragen und Auswertungen Fachbegriffe, Terminologien, Thesauri, domainenspezifisches Wissen Kontextinformationen zu Maßeinheiten oder Datumsformaten Technische Metadaten Logische und physische Datenschemata Integritätsbedingungen Implementierungsinformationen i zu den ETL-Prozessen der unterschiedlichen h Datenquellen Metadatenmanager t Verwaltet und aktualisert die Metadaten im Repositorium. Stellt Schnittstellen zum Lesen und Schreiben des Repositoriums bereit. - II - 23 -
- II - 24 -
Das multidimensionale Modell OLAP-Würfel (Data Cube) Typische Anfragen an ein Data Warehouse sind multidimensional: Erstelle eine Übersicht über die Umsätze, Kosten, Deckungsbeiträge sämtlicher Produkte, geordnet nach Quartalen und Filialen. Dimensionen wären im vorliegenden Fall: Produkte, Quartale (Zeit), Filialen. Unterschieden wird folglich in Fakten ( = Zahlenwerte, Messwerte) und Dimensionen. Dimensionen beschreiben den Kontext des Messwerts und werden häufig hierarchisch verdichtet: Produkt Produktgruppe Produktlinie Sparte Tag Monat Quartal Jahr Veranschaulichung: 3-dimensionaler Würfel (bzw. in Form einer 3-dimensionalen Tabelle) Zellen des Würfels: spezifische Werte Umsatz, Kosten, Deckungsbeitrag pro Produkt, Quartal und Filiale Typische Auswertungen eines OLAP-Würfels ergeben sich durch Projektionen und Summationen (drill down, drill through, roll up, slice, dice) - II - 25 -
- II - 26 -
OLAP-Architekturen ROLAP und MOLAP Die Aufbereitung der Daten eines Data-Warehous für die Zellen des OLAP- Würfels kann als VIEW einer relationalen Datenbank erfolgen. In diesem Fall spricht man von ROLAP (relationales OLAP). Die Werte der Zellen können aber auch vor der Nutzung aus dem Data- Warehouse ausgelesen und im OLAP-Würfel physisch abgespeichert werden, was man dann MOLAP (multidimensionales OLAP) nennt. ROLAP Nutzung der bekannten relationalen Technologie. Kein zusätzliches DBS erforderlich. Erfahrungen der Mitarbeiter mit relationalen DBS können genutzt werden. Nachteil: hochkomplexe SQL-Anfragen, nur beschränkte Nutzung für EIS MOLAP Mittels eigenständigem System (Multidimensionales Datenbankmanagementsystem MDBMS) kann eine Optimierung des multidimensionalen Modells erfolgen. Verzicht auf Sperrkonzepte, Transaktionsmanager und Recovery- Mechanismen reduziert den Overhead. - II - 27 -
OLAP-Architekturen Star-Schema und Snowflake-Schema bei ROLAP Beispiel Relation Prod_Umsatz_Filiale hält die Umsätze verschiedener Produkte pro Filiale und Tag über mehrer Jahre fest: Prod_Umsatz_Filiale ( Prod#, Filialen#, Umsatz, Datum) Dimensionen des OLAP-Würfels Produkt Produktgruppe Produktlinie all Filiale Stadt Region Land all Tag Woche; Tag Monat Quartal Jahr - II - 28 -
- II - 29 -
- II - 30 -
Relationen: Dimensionstabellen Star-Schema PRODUKT (Prod#, Name,..., Prodgruppe, Gruppenbez., Prodlinie, Linienbez.) FILIALE (Filialen#, Name,..., Stadt, Region, Land) DATUM (Datum#, Woche, Monat, Quartal, Jahr) Im Zentrum des Sterns beim Starschema steht die sogenannte Fact- Table, die die konkreten Zahlenwerte, hier Umsatz, mit den Schlüsseln der einzelnen Dimensionen verknüpft: Fact-Table: PROD_UMSATZ (Prod#, Filialen#, Umsatz, Datum#) Keine Normalisierung! Fact Constellation Schema Überlagerung von Sternen dadurch, dass die Dimensionstabellen für mehrere unterschiedliche Faktentabellen verwendet werden. - II - 31 -
- II - 32 -
Relationen: Dimensionstabellen Snowflake-Schema PRODUKT (Prod#, Name,..., Prodgruppe#) PRODUKTGRUPPE (Prodgruppe#, Gruppen_Bezeichnung,..., Prodlinie#) PRODUKTLINIE (Prodlinie#, Linien_Bezeichnung) FILIALE (Filialen#, l Name,..., Stadt_Name) STADT (Stadt_Name,.., Region#) REGION (Region#, Bezeichnung,..., Land) LAND (Land) DATUM (Datum#, Wochen#, Monats#) WOCHE (Wochen#, Jahr#) MONAT (Monats#, Name, Quartals#) Quartal(Quartals#, Jahr#) JAHR (Jahr#) Das Snowflake-SchemaSchema ist normalisiert - II - 33 -