Operative vs. Informationelle Systeme. Informationelle Systeme. Informationelle Systeme. Moderne Betriebliche Anwendungen von Datenbanksystemen

Transkript

1 Moderne Betriebliche Anwendungen von Datenbanksystemen Online Transaction Processing Betriebswirtschaftliche Standard- Software (SAP R/) Data Warehouse-Anwendungen Data Mining Operative vs. Informationelle Systeme Anspruch an Datenbanken in Unternehmen ist vielschichtig. Man kann sie - je nach Einsatzzweck - in operative und informationelle Systeme einteilen. Operative Systeme eingesetzt von Sachbearbeitern, am Bankschalter, etc. dienen der täglichen Arbeit Informationelle Systeme helfen dem Management, (strategische) Entscheidungen zu finden. (durch DSS = Decision Support Systems) (Systeme für Business Intelligence Anwendungen) bieten Grundlage für weitere Analysen mit OLAP / Data Mining Informationelle Systeme Informationelle Systeme zugeschnitten auf Gegenstandsbereiche (sog. Subjects), z.b. Kunde, Produkt, Vertriebsregion enthalten sehr große Datenmengen enthalten zum großen Teil historische, zusammengefasste Daten Historie aus Daten der operativen Systeme ist nachvollziehbar unterstützen Informations- und Analyseaufgaben, d.h. das Management in der Entscheidungsfindung wenige Zugriffe, aber mit relativ hohem Datenvolumen Datenbankeinträge werden nicht geändert (keine Updates) relativ hohe Redundanz Überblick über alle relevanten Unternehmensdaten komplexe, oft heuristische Ad-hoc-Anfragen z.b. auf der Basis von OLAP-Funktionalitäten Antwortzeitverhalten spielt untergeordnete Rolle Daten sind wohl strukturiert, integriert und konsolidiert Anzahl Benutzer ist eher klein ( Power-User )

2 Gegensätze Grundlagen Operative Systeme Schnelle Antwortzeit Anwendungsorientiert Aktuelle Daten Detaillierte, primäre Daten Häufige Änderungen Dient täglicher Arbeit Informationelle Systeme Hohe Speicherkapazität Gegenstandsorientiert Historische Daten Auch zusammengefasste, abgeleitete Daten Keine Updates Dienst als Datenspeicher für Analyse und Entscheidungsfindung Man muss beide Systeme trennen. Data Warehouse für den informationellen Systemteil Legacy Systeme DWh DBMS & Data Marts Ext. Daten OLAP Tools Data Mining und Statistik Tools Kausale Modelle Intelligente Informationssysteme und Reports operative Daten informationelle Daten Analytiker Management OLTP: Online Transaction Processing Beispiele Flugbuchungssystem Bestellungen in einem Handelsunternehmen Charakterisierung Hoher Parallelitätsgrad Viele (Tausende pro Sekunde) kurze Transaktionen TAs bearbeiten nur ein kleines Datenvolumen mission-critical für das Unternehmen Hohe Verfügbarkeit muss gewährleistet sein Normalisierte Relationen (möglichst wenig Update-Kosten) Nur wenige Indexe (wegen Fortschreibungskosten) SAP R/: Enterprise Resource Modelling (ERP-System) WAN (Internet) LAN Relationales DBMS als Backend-Server (Oracle, Informix, DB, MS SQL-Server, Adabas)

3 Dreistufige Client/Server-Architektur ( Tier, SAP R/) Interne Architektur von SAP R/ sehr viele (Tausen de) Clients Sehr schnelles LAN (z.b. FDDI) ein Datenbank- Server mehrere Applikatio ns- Server zur Skalierun g langsame Netzverbindung (WAN, Internet, Telefon, ) Transaktionsverarbeitung in SAP R/ Data Warehouse-Anwendungen: OLAP~Online Analytical Processing Sperren anfordern Posting-Schritte Sperren freigeben Wie hat sich die Auslastung der Transatlantikflüge über die letzten zwei Jahre entwickelt? oder Dialog-Schritte D D D P P P P Wie haben sich besondere offensive Marketingstrategien für bestimmte Produktlinien auf die Verkaufszahlen ausgewirkt? Online-Phase Posting-Phase

4 Was ist ein Data Warehouse? Gegenstandsorientierung (subject-oriented) Mit dem Begriff Data Warehouse wird eine von den operationalen DV-Systemen isolierte Datenbank umschrieben, die als unternehmensweite Datenbasis für Management-Unterstützungssysteme dient. [Muksch et al. 996] A Data Warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in support of management s decision-making process. [Inmon, Hackathron 994] DWh ist an Gegenstandsbereichen des Unternehmens orientiert, z.b. Produkten, Kunden, Lieferanten Gegensatz zu Funktions- oder Anwendungsorientierung bei operativen (legacy) Systemen: Funktionen sind z.b. Einkauf, Lagerhaltung, Verkauf Bei der Entwicklung eines DWh stehen die Daten im Mittelpunkt. Bei operationalen Systemen muss auch der Prozess berücksichtigt werden. DWh enthält nur solche Daten, die für DSS-Analysten/Manager relevant und interessant sind, werden oder sein könnten. A Data Warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in support of management s decision-making process. [Inmon, Hackathron 994] Integration Integration Daten aus verschiedenen Quellen werden im DWh vereinheitlicht, u.a. durch Operative Systeme konsistente Vergabe und Definition von Bezeichnern einheitliche Kodierung Externe Datenquellen Integration, Konsolidierung Data Warehouse z.b. wird jedes Datum in der Form <YYYY-MM-DD> gespeichert einheitliches Festlegen der Maßeinheiten von Attributen z.b. werden Preise in Dollar angegeben Auflösung von strukturellen Konflikten z.b. Schema-Wert-Konflikt In zwei verschiedenen operativen Systemen können die gleichen Daten unter verschiedenen Bezeichnern abgelegt sein die gleichen Bezeichner für verschiedene Zwecke benutzt werden der gleiche Sachverhalt auf verschiedene Weise kodiert sein A Data Warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in support of management s decision-making process. [Inmon, Hackathron 994] Integration führt dazu, dass alle Daten im DWh in einer einzigen, allgemein akzeptierten Art und Weise gespeichert sind. Erst die Integration erlaubt die einfache und effektive Nutzung der DWh-Daten für Anwendungen z.b. im Management Integration ist ein schwieriger und zeitaufwendiger Prozess

5 Lebenszyklus eines Data Warehouse Behandlung von Strukturkonflikten in relationalen Schemata: [Saltor et. al. 99] Beispiel: Datenbank für Aktienkurse Datenbank New York (ein Tupel pro Tag und Aktie) date stock clsprice IBM HP GM IBM HP GM 5 Datenbank Barcelona (ein Tupel pro Tag, ein Attribut pro Aktie) date HP IBM GM Datenbank Melbourne (eine Relation pro Aktie, ein Tupel pro Tag) Zeitraumbezug (time variancy) In operativen Systemen ist der aktuelle Datenbestand gespeichert. Er kann jederzeit geändert werden (Update). DWh enthält eine ganze Historie von Daten DWh besteht aus Snapshots der operativen Systeme DWh-Daten sind zu einem bestimmten Zeitpunkt gültig (gewesen). Der Gültigkeitszeitraum ist an allen Daten im DWh vermerkt (als Teil des Schlüssels) Zeithorizont des DWh: ca. 5-0 Jahre operative Systeme: max Tage HP date clsprice IBM date clsprice GM date clsprice A Data Warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in support of management s decision-making process. [Inmon, Hackathron 994] Beständigkeit (nonvolatility) Architektur einer Data Warehouse Umgebung Operative Systeme: Daten werden oft geändert, gelöscht, eingefügt. Aufwendige Mechanismen, um Deadlocks zu vermeiden Locking-Mechanismen, etc. OLAP Tools DWh: primär nur Leseoperationen Daten werden aus den operativen Systemen (initial) geladen Analysesysteme greifen lesend auf DWh-Daten zu. Es gibt keine Updates Legacy Systeme DWh DBMS & Data Marts Ext. Daten Data Mining und Statistik Tools Kausale Modelle Intelligente Informationssysteme und Reports A Data Warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in support of management s decision-making process. operative Daten informationelle Daten Analytiker Management [Inmon, Hackathron 994]

6 Architektur einer DWh-Umgebung Die innere Struktur eines Data Warehouse Architektur einer DWh-Umgebung Beispiel: Telekommunikationsunternehmen Metadaten Stark zusammengefasste Daten Leicht zusammengefasste Daten Aktuelle detaillierte Daten detailliert Für jeden Kunden, jedes Gespräch inkl. Zone Teilnehmer Zeitpunkt Dauer Gebühren Art des Dienstes Byte pro Kunde leicht zusammengefasst Für jeden Kunden Anzahl der Gespräche insgesamt Anzahl der Ferngespräche Gesprächsdauer Umsatz je Zone Umsatz insgesamt Zusammenfassung monatlich ca. 00 Byte pro Kunde Alte (detaillierte) Daten Architektur einer DWh-Umgebung Datenflüsse im Data Warehouse Zusammenfassen Architektur einer DWh-Umgebung Metadaten Metadaten sind Daten über Daten Metadaten lassen sich in Kategorien einteilen: Laden von Daten aus operativen Systemen Zusammenfassen semantische Metadaten Festlegung der DWh-Terminologie Transformations- und Integrationsregeln für die Abbildung der operativen Daten in die DWh-Daten Aggregationsregeln für das Zusammenfassen der Daten auf verschiedenen Aggregationsstufen Alterungsprozess

7 Architektur einer DWh-Umgebung DWh-Entwicklungszyklus Metadaten (forts.): DWh-Entwicklungszyklus unterscheidet sich vom klassischen: verwaltungstechnische Metadaten Festlegung von Benutzer (-gruppen) und zugehörige Zugriffsrechte statische Daten über das DWh Größe von Tabellen Zugriffsrechte auf Tabellen schematische Metadaten logisches Schema des DWh Abbildung zwischen logischem und physischem Schema Quellen der DWh-Daten Am Anfang des Data-Warehouse-Entwicklungszyklus stehen die Daten (der Prozess ist datengeleitet (data-driven)) Das Data Warehouse wird schrittweise entwickelt. Gründe: genaue Ziele/ Anforderungen an das DWh sind meistens noch nicht bekannt, Größe auch schlecht abschätzbar Kosten und Entwicklungszeit schlecht abschätzbar benötigte Ressourcen (Mitarbeiter, Rechner, ) sind hoch Data Warehouse Entwicklungszyklus Iterative Vorgehensweise iteratives Vorgehen und kurze feedback loops haben viele Vorteile: Anwender können ihre Anforderungen erst dann detailliert artikulieren, wenn der erste DWh-Prototyp vorliegt (. Stufe der DWh-Entwicklung) Management wird erst dann größeres Projektbudget genehmigen, wenn positive Resultate sicher greifbar sind. Qualität des DWh wird durch feedback loops mit Anwendern deutlich verbessert. Data Warehouse Entwicklungszyklus Monitoring der DWh-Benutzung Monitoring ist Voraussetzung für Anpassung des DWh an aktuelle Nutzung Welche Daten des DWh werden regelmäßig genutzt? In welchem Umfang wächst der Datenbestand? Wer benutzt das DWh? Welche Antwortzeiten treten bei welchen Anfragen auf? Wie ist die Belastung des DWh? Leitmotiv: Think big! Start small! Grow step by step!

8 Sammlung und periodische Auffrischung der Data Warehouse-Daten OLTP-Datenbanken und andere Datenquellen OLAP-Anfragen Decision Support Data Mining Das Stern-Schema Data Warehouse Stern-Schema bei Data Warehouse- Anwendungen Das Stern-Schema: Handelsunternehmen Eine sehr große Faktentabelle Alle Verkäufe der letzten drei Jahre Alle Telefonate des letzten Jahres Alle Flugreservierungen der letzten fünf Jahre normalisiert Mehrere Dimensionstabellen Zeit Filialen Kunden Produkt Oft nicht normalisiert Kunden Zeit Verkäufe Produkte Verkäufe r Filialen

9 Das Stern-Schema: Krankenversicherung Behandlunge n Zeit Krankhei ten Ärzte Patienten Kranken häuser Stern-Schema Passau 5-Jul-00 Verkäufer Kunde Anzahl Produkt Filiale VerkDatum Verkäufe Bayern D Passau Bezirk Land FilialenKennung Filialen 4 Kemper 47 wiealt Name KundenNr Kunden 9 Elektronik man 85 wiealt Manager Fachgebiet Name VerkäuferNr Verkäufer Faktentabelle (SEHR groß) Dimensionstabellen (relativ klein) Stern-Schema (cont d) Weihnachten Dienstag Dec-0 Hochsommer Saison Dienstag Wochentag Jul-00 KW Quartal Jahr Monat Tag Datum Zeit.... Siemens Telekom Mobiltelekom 47.. Hersteller Produkthauptgruppe Produktgruppe Produkttyp ProduktNr Produkte Nicht-normalisierte Dimensionstabellen: effizientere Anfrageauswertung Weihnachten Dienstag Dec-0 Hochsommer Saison Dienstag Wochentag Jul-00 KW Quartal Jahr Monat Tag Datum Zeit.... Siemens Telekom Mobiltelekom 47.. Hersteller Produkthauptgruppe Produktgruppe Produkttyp ProduktNr Produkte Datum Monat Quartal ProduktNr Produkttyp Produktgruppe Produkthauptgruppe

10 Normalisierung führt zum Schneeflocken-Schema KWs Kunden Zeit Quartale Verkäufe Filialen Verkäufe r Produkthau ptgruppen Produktgr uppen Produktty pen Produkte Vorteile des Stern-Schemas gegenüber herkömmlichen relationalen Schemata Schema-Entwurf entspricht der natürlichen Sichtweise der Benutzer Daten können in einer für Analysen adäquaten Weise zugegriffen werden. Erweiterungen und Änderungen am Schema sind leicht zu realisieren. Beziehungen zwischen den Tabellen sind vordefiniert Join-Operationen können durch entsprechende Zugriffspfade unterstützt werden Schnelle Antwortzeiten sind möglich Stern-Schema kann leicht in relationales DB-Schema umgesetzt werden. Vorteile des Stern-Schemas gegenüber herkömmlichen relationalen Schemata Umsetzung des Stern-Schemas in relationale Tabellen: Kennzahlentabelle (major table): Die Gegenstände der Analyse (Kennzahlen) werden in dieser Tabelle gesichert Nebentabelle (minor tables): Jede Dimension wird zu einer eigenen Relation / Tabelle. Kennzahlentabelle: Jedes Tupel der Kennzahlentabelle besteht aus einem Zeiger für jede Dimensionstabelle (Fremdschlüssel), die den Kontext eindeutig definieren und den numerischen Werten (Daten) für den jeweiligen Kontext. Sie enthält die eigentlichen Geschäftsdaten, die analysiert werden sollen. Die Kennzahlentabelle kann sehr viele Zeilen enthalten (Millionen). Der Schlüssel der Kennzahlentabelle wird durch die Gesamtheit der Dimensionszeiger gebildet Anfragen im Sternschema select sum(v.anzahl), p.hersteller from Verkäufe v, Filialen f, Produkte p, Zeit z, Kunden k Einschränkung where z.saison = 'Weihnachten' and der Dimensionen z.jahr = 00 and k.wiealt < 0 and Join-Prädikate p.produkttyp = '' and f.bezirk = 'Bayern' and v.verkdatum = z.datum and v.produkt = p.produktnr and v.filiale = f.filialenkennung and v.kunde = k.kundennr group by p.hersteller;

11 Algebra-Ausdruck Roll-up/Drill-down-Anfragen σ(produkte) σ(filialen) select Jahr, Hersteller, sum(anzahl) from Verkäufe v, Produkte p, Zeit z A A where v.produkt = p.produktnr and v.verkdatum = z.datum and p.produkttyp = '' Verkäufe group by p.hersteller, z.jahr; σ(kunden) A A σ(zeit) select Jahr, sum(anzahl) from Verkäufe v, Produkte p, Zeit z where v.produkt = p.produktnr and v.verkdatum = z.datum and p.produkttyp = '' group by z.jahr; Roll-up Drill-down Ultimative Verdichtung select sum(anzahl) from Verkäufe v, Produkte p where v.produkt = p.produktnr and p.produkttyp = '';

12 Drill- Down Roll-up Flexible Auswertungsmethoden: slice and dice R eg io n en Produktgruppen K u n d en R eg io n en Produktgruppen R eg io n en Produktgruppen K u n d en K u n d en Materialisierung von Aggregaten insert into DCube ( select p.hersteller, z.jahr, sum(v.anzahl) from Verkäufe v, Produkte p, Zeit z where v.produkt = p.produktnr and p.produkttyp = '' and v.verkdatum = z.datum group by z.jahr, p.hersteller ) union ( select p.hersteller, to_number(null), sum(v.anzahl) from Verkäufe v, Produkte p where v.produkt = p.produktnr and p.produkttyp = '' group by p.hersteller ) union ( select null, z.jahr, sum(v.anzahl) from Verkäufe v, Produkte p, Zeit z where v.produkt = p.produktnr and p.produkttyp = '' and v.verkdatum = z.datum group by z.jahr ) union ( select null, to_number(null), sum(v.anzahl) from Verkäufe v, Produkte p where v Produkt = p ProduktNr and p Produkttyp ='' ); Relationale Struktur der Datenwürfel

13 Würfeldarstellung Der cube-operator select p.hersteller, z.jahr, f.land, sum(v.anzahl) from Verkäufe v, Produkte p, Zeit z, Filialen f where v.produkt = p.produktnr and p.produkttyp = '' and v.verkdatum = z.datum and v.filiale = f.filialenkennung group by cube (z.jahr, p.hersteller, f.land); Wiederverwendung von Teil-Aggregaten insert into VerkäufeProduktFilialeJahr ( select v.produkt, v.filiale, z.jahr, sum(v.anzahl) from Verkäufe v, Zeit z where v.verkdatum = z.datum group by v.produkt, v.filiale, z.jahr ); select v.produkt, v.filiale, sum(v.anzahl) from Verkäufe v group by v.produkt, v.filiale Wiederverwendung von Teil-Aggregaten select v.produkt, v.filiale, sum(v.anzahl) from VerkäufeProduktFilialeJahr v group by v.produkt, v.filiale select v.produkt, z.jahr, sum(v.anzahl) from Verkäufe v, Zeit z where v.verkdatum = z.datum group by v.produkt, z.jahr

14 Die Materialisierungs-Hierarchie { } Die Zeit-Hierarchie Jahr {Produkt} {Jahr} {Filiale} {Produkt, Jahr} {Produkt, Filiale} {Filiale, Jahr} Quartal Woche (KW) {Produkt, Filiale, Jahr} Teilaggregate T sind für eine Aggregation A wiederverwendbar wenn es einen gerichteten Pfad von T nach A gibt Also T A Man nennt diese Materialisierungshierarchie auch einen Verband (Engl. Lattice) Tag Monat Bitmap-Indexe Beispiel-Anfrage und Auswertung Optimierung durch Komprimierung der Bitmaps Ausnutzung der dünnen Besetzung Runlength-compression Grundidee: speichere jeweils die Länge der Nullfolgen zwischen zwei Einsen Mehrmodus-Komprimierung: bei langen Null/Einsfolgen speichere deren Länge Sonst speichere das Bitmuster

15 Bitmap-Operationen Bitmap-Join-Index B-Baum B-Baum B-Baum B-Baum TID-V TID-K TID-V TID-K (i,ii)(ii,i)(iii,ii)(iv,ii)(v, (I,i)(I,v)(II,i )(II iii)(ii iv (i,ii)(ii,i)(iii,ii)(iv,ii)(v, (I,i)(I,v)(II,i )(II iii)(ii iv

16 5 5 Select k.* Select v.* B-Baum From Verkäufe v, Kunden k B-Baum From Verkäufe v, Kunden k TID-V Where v.produktid = 5 And v.kundennr = k.kundennr TID-K Where k.kundennr = 47 and v.kundennr = k.kundennr (i,ii)(ii,i)(iii,ii)(iv,ii)(v, (I,i)(I,v)(II,i )(II,iii)(II,iv Beispielanfrage auf dem Sternschema: Stern-Verbund -- Star Join select sum(v.anzahl), p.hersteller from Verkäufe v, Filialen f, Produkte p, Zeit z, Kunden k where z.saison = 'Weihnachten' and z.jahr = 00 and k.wiealt < 0 and Einschränkung der Dimensionen p.produkttyp = '' and f.bezirk = 'Bayern' and v.verkdatum = z.datum and v.produkt = p.produktnr and v.filiale = f.filialenkennung and v.kunde = k.kundennr group by p.hersteller; Join-Prädikate

17 Illustration des Star Join Zeit Verkäufe Kunden Bitmap-Indexe für die Dimensions- Selektion Zeit Verkäufe Kunden Filialen Produkte Filialen Produkte Ausnutzung der Bitmap-Join-Indexe Zeit Verkäufe Kunden Filialen Eine Produkte weitere Join-Methode: DiagJoin Für :N-Beziehungen Daten sind zeitlich geballt (clustered) Beispiel Order Lineitem Order A Lineitem Die Lineitems (Bestellpositionen) einer Order (Bestellung) kommen zeitlich kurz hintereinander Grundidee des DiagJoins besteht darin, synchron über die beiden Relationen zu laufen Die Orders werden in einem Fenster gehalten

18 DiagJoin Junker 45 Lola 9965 Kaller Hummer Müller Maier 47 Kemper Customer Order Mixer Papier 4 47 Fax Hub Toner 47 Drucker 47 Laptop PC 47 Preis Produkt Position LineItem DiagJoin Junker 45 Lola 9965 Kaller Hummer Müller Maier 47 Kemper Customer Order Mixer Papier 4 47 Fax Hub Toner 47 Drucker 47 Laptop PC 47 Preis Produkt Position LineItem DiagJoin Junker 45 Lola 9965 Kaller Hummer Müller Maier 47 Kemper Customer Order Mixer Papier 4 47 Fax Hub Toner 47 Drucker 47 Laptop PC 47 Preis Produkt Position LineItem DiagJoin Junker 45 Lola 9965 Kaller Hummer Müller Maier 47 Kemper Customer Order Mixer Papier 4 47 Fax Hub Toner 47 Drucker 47 Laptop PC 47 Preis Produkt Position LineItem

19 DiagJoin Order Customer Kemper 47 Maier Müller Hummer Kaller LineItem Position Produkt PC Laptop Drucker Toner Hub Fax Preis DiagJoin Customer Kemper Maier Müller Hummer Kaller Order LineItem Position Produkt PC Laptop Drucker Toner Hub Fax Preis Lola Junker Papier Mixer Lola Junker Papier Mixer 47 5 Quirl Muss zwischengespeichert werden und nachbearbeitet werden Quirl Anforderungen an den DiagJoin :N Beziehung Die -er Tupel sind in etwa derselben Reihenfolge gespeichert worden wie die N -er Tupel Die Tupel werden in der time-of-creation -Reihenfolge wieder von der Platte gelesen (full table scan) Die referentielle Integrität muss gewährleistet sein Das Fenster muss so groß sein, dass kaum Tupel nachbearbeitet werden müssen Nachbearbeitung bedeutet Tupel auf dem Hintergrundspeicher speichern Den zugehörigen Joinpartner via Index auffinden Also ist ein Index auf Order. hierfür notwendig Nicht für die erste Phase des DiagJoins Weitere Decision-Support Anfrage-Typen Top N-Anfragen Ich will nur die N besten Treffer erhalten und nicht alle 5 Millionen Muss bei der Anfrageoptimierung berücksichtigt werden Online Aggregation Man berechnet das Ergebnis approximativ Je länger die Anfrage läuft, desto genauer wird das Ergebnis

20 Top N-Anfragen Select A.* From Angestellte A, Abteilungen abt Where A.Abteilung = abt.abteilungsnr and abt.ort = Passau Order by A.Gehalt Stop after 0 Online-Aggregation Select abt.ort, avg(a.gehalt) From Angestellte A, Abteilungen abt Where A.Abteilung = abt.abteilungsnr Group by abt.ort