2 Das Data Warehouse-Konzept - Department of Information Systems

Westfälische Wilhelms-Universität Münster
Ausarbeitung
Data Warehouse, Data Mining, Weblog Mining
im Rahmen des Seminars „Informatik und Recht“
Tobias Gerke
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Dipl.-Wirt.Inform. Christoph Lembeck
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft
Abgabetermin: 18. Dezember 2003
Inhaltsverzeichnis
1
Einleitung................................................................................................................... 1
2
Das Data Warehouse-Konzept................................................................................... 2
3
2.1
Notwendigkeit einer separaten Datenhaltung ................................................... 2
2.2
Begriffsdefinition Data Warehouse.................................................................. 3
2.3
Data Warehouse als Architekturkomponente ................................................... 4
Datenanalyse.............................................................................................................. 7
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.2
3.2.1
3.2.2
4
Data Mining ...................................................................................................... 7
Assoziationsanalyse ...................................................................................... 8
Sequenzanalyse........................................................................................... 10
Entscheidungsbauminduktion..................................................................... 11
Clusteranalyse............................................................................................. 12
Web Log Mining............................................................................................. 13
Aufbereitung der Protokolldateien.............................................................. 15
Informationsgewinnung aus den Protokoll-Daten ...................................... 16
Fazit ......................................................................................................................... 19
Literaturverzeichnis ........................................................................................................ 21
II
Kapitel 1: Einleitung
1 Einleitung
In jüngster Zeit ist in der Wirtschaft ein struktureller Wandel zu erkennen, der sich insbesondere in geänderten Führungsprinzipien, optimierten Geschäftsprozessen und der
Entwicklung neuer Konzepte, wie z.B. dem Total Quality Management (TQM) oder
dem Just-in-Time-Prinzip, manifestiert. Viele Unternehmen sehen sich u.a. durch Produkthomogenisierung, Ressourcenverknappung, immer kürzere Innovations- und Produktlebenszyklen sowie insbesondere den Wandel von Verkäufer- zu Käufermärkten
einem immer härter werdenden Wettbewerb ausgesetzt [Mu97, S. 4]. Unternehmerischer Erfolg hängt immer mehr von Informationsvorsprüngen ab, im Idealfall sollte die
richtige Information immer zur richtigen Zeit am richtigen Ort sein.
Gleichzeitig mit der Entwicklung der Information zum wichtigsten Produktionsfaktor in
Unternehmen geht eine steigende Datenflut einher, die insbesondere in den operativen
Bereichen der Unternehmen entsteht. Diese sind jedoch oftmals nicht in der Lage, die
anfallenden Daten sinnvoll zu nutzen und die verborgenen, wichtigen Informationen
hieraus zu extrahieren. Hinzu kommt, dass auch die Datenmenge der unternehmensexternen Quellen ständig zunimmt, so dass es auch hier schwieriger wird, die relevanten
Informationen aus den Daten herauszufiltern.
Aus diesem Grund sind einige Konzepte und Methoden entwickelt worden, mit denen
versucht wird, den Informationsdefiziten zu entgegnen, indem aus den verfügbaren,
riesigen Datenmengen möglichst automatisch Informationen extrahiert und dem Benutzer in geeigneter Weise präsentiert werden.
In Kapitel 2 wird zunächst die Notwendigkeit diskutiert, alle verfügbaren Daten zu Analysezwecken in einer zentralen, integrierten Datenbank, dem sogenannten Data Warehouse zu verwalten. Hier wird außerdem auf die Architektur und die Arbeitsweise eines
idealtypischen Data Warehouse eingegangen.
In Kapitel 3 wird dann auf Möglichkeiten eingegangen, aus den Daten des Data Warehouse Informationen zu extrahieren. So wird zunächst das Data Mining als das allgemeine Anwendungsgebiet beschrieben, mit dem Muster in einem gegebenen Datenbestand entdeckt werden können. Einige der wichtigsten, konkreten Data Mining Methoden werden dann schließlich näher vorgestellt. Als letztes wird auf das Web Log Mi1
Kapitel 2: Das Data Warehouse-Konzept
ning, ein Spezialgebiet des Data Mining, näher eingegangen, das das Verhalten von
Konsumenten in internetbasierten Markapplikationen untersucht und Muster aufdeckt.
Im Kapitel 4 wird dann abschließend noch mal eine Zusammenfassung der vorgestellten
Konzepte und Methoden dargeboten.
2 Das Data Warehouse-Konzept
2.1 Notwendigkeit einer separaten Datenhaltung
Wie im einleitenden Kapitel erwähnt, hat sich die Information zu einem der wichtigsten
Produktionsfaktoren in Unternehmen entwickelt. Es besteht das Bestreben, möglichst
schnell die richtigen Informationen aus den vorhandenen Daten abzuleiten, um so dem
Management eine Entscheidungsunterstützung zu geben. Außerdem ist im Laufe der
Jahre die Menge der anfallenden Daten in den operationalen Datenbanken der Unternehmen immer größer geworden, so dass es geeigneter Analysemethoden bedarf, um
die in den Daten verborgenen Informationen zu extrahieren.
Denkbar wäre es, diese Analysemethoden direkt auf die operationalen Datenbanken
anzuwenden, doch dieser Vorgehensweise stehen eine Menge von Nachteilen gegenüber:
Die als Online Transaction Processing (OLTP) bezeichneten Anwendungen der täglichen Datenverarbeitung, die auf den operationalen Datenbanken durchgeführt werden,
sind durch ein hohes Transaktionsaufkommen gekennzeichnet. Beispiele für solche
Anwendungen sind das Buchen eines Fluges in einem Flugreservierungssystem oder
das Verarbeiten einer Bestellung in einem Handelsunternehmen. Derartige Transaktionen sind im allgemeinen strukturiert, repetitiv, erfordern aktuelle Daten und greifen auf
geringe Datenmengen zu. Datenbank-Größen liegen im Bereich vieler MB bis einiger
GB [Vo00, S. 674]. Es sollte vor allem eine schnelle Transaktionsabwicklung und eine
Minimierung der Konflikte zwischen den Transaktionen gewährleistet sein.
Anwendungen zur Analyse von Daten hingegen erfordern meist eine komplexe Auswertung. Würden solche Anwendungen auf den operationalen Datenbanken ausgeführt,
würde dies die Performance dieser Datenbanken stark beeinträchtigen. Außerdem sind
für bestimmte Fragestellungen historische Daten bei der Datenanalyse von Belang, die
in den OLTP-Anwendungen nicht benötigt werden und aus Performancegründen daher
2
Kapitel 2: Das Data Warehouse-Konzept
auch nicht in den operationalen Datenbanken gespeichert werden. Ferner ist festzustellen, dass die verschiedenen operationalen Datenquellen eines Unternehmens einen heterogenen Charakter besitzen: Unterschiedliche Datenbanktypen und –schemata werden
verwendet und inkonsistente Datenrepräsentationen und –formate sind anzutreffen. Da
jedoch die aus den Daten abzuleitenden Informationen der Entscheidungsunterstützung
dienen, ist eine einheitliche, gehobene Datenqualität unabdingbar. Häufig ist es auch
wünschenswert, neben den operationalen Datenbanken externe Datenquellen als Datengrundlage in die Analyse einzubeziehen. Insgesamt scheint es also am geeignetsten zu
sein, eine Trennung von den operationalen Datenbanken und den Daten zur Analyse
vorzunehmen. Zu diesem Zweck werden Letztere in einem sogenannten Data Warehouse vorbehalten, dessen Aufbau und Funktionen im nachfolgenden Kapitel kurz beschrieben wird.
2.2 Begriffsdefinition Data Warehouse
Der Begriff des Data Warehouse wurde vor allem von INMON geprägt, so dass in der
Literatur meist auch eine von ihm stammende Definition angeführt wird:
A data warehouse is a subject oriented, integrated, non-volatile, and time variant collection of data in support of management’s decisions [In96, S. 33].
Die Eigenschaft der Themenorientierung besagt, dass nicht alle verfügbaren Daten in
das Data Warehouse übernommen werden, sondern nur solche, die von den Führungskräften im Rahmen der Planungs-, Entscheidungs- und Steuerungsaufgaben auch benötigt werden.
Die Daten des Data Warehouse entstammen vielen, verschiedenen, völlig heterogenen
Datenquellen, in denen beispielsweise die Merkmalsausprägungen unterschiedlich kodiert sein können: So könnte zur Angabe des Geschlechts in einer Datenquelle m und w
verwendet werden, während in einer anderen hierfür 0 und 1 benutzt werden. Auch unterschiedliche Maßeinheiten (z.B. Meter vs. Zentimeter für eine Längenangabe) können
für das gleiche Attribut anzutreffen sein. Um dem Entscheidungsträger die Daten in
einheitlicher Form zur Verfügung zu stellen, sind sie daher zu integrieren und in das
Data Warehouse zu überführen.
Eine weitere wichtige Eigenschaft eines Data Warehouse ist die Nicht-Flüchtigkeit der
Daten. Da Entscheidungsträger bei der Analyse der Geschäftsdaten daran interessiert
3
Kapitel 2: Das Data Warehouse-Konzept
sind, die Entwicklung bestimmter Kenngrößen im zeitlichen Verlauf zu überprüfen,
sind auch historische Daten von besonderem Interesse. Nach dem einmaligen Einfügen
von Daten in das Data Warehouse werden diese später i.d.R. nicht mehr aktualisiert
oder gelöscht. Die Hauptoperation, die auf ein Data Warehouse angewendet wird, ist
somit das Lesen der Daten.
Eng mit der Eigenschaft der Nicht-Flüchtigkeit zusammen hängt das Charakteristikum
der zeitlichen Varianz: Im Gegensatz zu den operationalen Datenbanken, bei denen zu
jedem Zeitpunkt nur der aktuelle Zustand der Daten abgefragt werden kann, spiegeln
die Daten des Data Warehouse die Ausprägungen der interessierenden Unternehmensdaten jeweils zu einem festen Zeitpunkt wieder (snapshot data). Der Zeitraumbezug der
Daten ist dabei immer impliziter oder expliziter Bestandteil des Elementschlüssels der
Daten im Data Warehouse [Sc01, S. 6]. Nach MUCKSCH, BEHME beträgt der abgebildete Zeithorizont in einem Data Warehouse in Abhängigkeit von der unternehmensindividuellen Anforderung bis zu zehn Jahre [Mu97, S.37].
2.3 Data Warehouse als Architekturkomponente
Innerhalb des betrieblichen Informationssystems kann das Data Warehouse als die zentrale Architekturkomponente aufgefasst werden, die alle analyserelevanten Daten in geeigneter Form vorbehält. Die Positionierung des Data Warehouse innerhalb dieses betrieblichen Informationssystems wird in Abb. 2.1 anhand eines Schichtenmodells verdeutlicht.
Die unterste Schicht des Management-Informationssystems bilden die heterogenen Datenquellen. Diese können einerseits einen unternehmensinternen Ursprung haben und
den operationalen Datenbanken oder aber auch unstrukturierten Daten wie Textdateien
oder Bildern entstammen. All diese Daten fallen bei der täglichen Durchführung von
Geschäftsprozessen an. Anderseits können auch Daten aus unternehmensexternen Quellen bei der Entscheidungsunterstützung von Interesse sein, so dass beispielsweise Daten
von Nachrichtendiensten, von Marktforschungsinstituten oder von anderen internetbasierten Quellen Eingang in das betriebliche Informationssystem finden.
Die Funktion, Daten aus den heterogenen Datenquellen in einheitlicher Form im Data
Warehouse bereitzustellen, übernehmen die ETL-Werkzeuge (Abk. für Extraktion,
Transformation, Loading). Sie stellen somit die Importschicht des ManagementInformationssystems dar. Ihre Aufgabe ist es, die entscheidungsrelevanten Daten aus
4
Kapitel 2: Das Data Warehouse-Konzept
den heterogenen Datenquellen zu selektieren, sie in eine einheitliche Form zu transformieren, Unreinheiten zu beseitigen und die bereinigten, einheitlichen und konsistenten
Daten in das Data Warehouse zu laden. Nach einem einmaligen, initialen Laden der
Daten in das Data Warehouse, erfolgt i.d.R. eine periodische Aktualisierung, die z.B.
täglich, wöchentlich oder monatlich durchgeführt werden kann. Dabei ist zu beachten,
dass durch den Aktualisierungsvorgang das Antwortzeitverhalten der operationalen Datensysteme u.U. stark beeinträchtigt werden kann, so dass eine solche Aktualisierung
nach Möglichkeit zu niederlastigen Operationszeiten, z.B. im Batch-Betrieb über Nacht,
durchgeführt werden sollte [Vo00, S. 677].
Analyse- und
Präsentationsschicht
Zentrales
Data
Warehouse
Data Mining
Tools
EIS
Spreadsheet
MIS/
Reportsysteme
MetaDaten
Archivierungssystem
Data Warehouse
Management
Tool
Data
Mart
Data Warehouse
Data
Mart
Extraktion, Transformation, Loading (ETL)
Importschicht
Interne Datenquellen
Datenquellen
der operativen
Systeme
OLAP-Tools
Operative
DB
unstrukturierte
Daten (Textfiles,
Bilder …)
Externe Datenquellen
WWW
Nachrichten
-dienste
Quelle: Vgl. Schütte et al., S. 8.
Abb. 2.1:
Schichtenmodell eines Management-Informationssystems.
Die zentrale Schicht des betrieblichen Informationssystems bildet das Data Warehouse
selbst, das eine enorme Größe von einigen Terabyte in Anspruch nehmen kann. SCHÜT5
Kapitel 2: Das Data Warehouse-Konzept
TE ET AL.
führen an, dass das Data Warehouse von WAL*MART 1999 eine Bestandsgrö-
ße von etwa 25 Terabyte hatte [Sc01, S. 10]. Aufgrund der mit der Größe des Data Warehouse steigenden Anfragezeiten und aufgrund der Tatsache, dass Adressaten bei Analysen immer nur einen Teilbereich des gesamten Datenbestandes abfragen, werden neben dem Data Warehouse noch kleinere, adressatenspezifische Datenbestände geführt,
die Kopien von Teilbereichen des Data Warehouse darstellen. Abfragen werden dann
direkt auf diesen sogenannten Data Marts ausgeführt, wodurch kürzere Antwortzeiten
erreicht werden. Um dem Anwender Informationen bereitzustellen, welche Art von Daten wo im Data Warehouse gespeichert sind und wie diese abgefragt werden können, ist
zum Data Warehouse eine Metadatenbank bereit zu stellen. Als Letztes befindet sich
auf der zentralen Data Warehouse Schicht noch ein Data Warehouse Management Tool
zur Administration und Konfiguration des Data Warehouse sowie ein Archivierungssystem zur Datensicherung und –archivierung. Die Datensicherung dient der Wiederherstellung des Data Warehouse im Fall eines Hard- oder Softwarefehlers. Bei der DatenArchivierung werden in Abhängigkeit der festgelegten Verdichtungsstufen und
-frequenzen Daten der untersten Detaillierungsstufen aus dem Data Warehouse ausgelagert und auf Offline-Datenträgern archiviert. Diese Reduzierung des Datenvolumens
im Data Warehouse dient der Performancesteigerung [Mu97, S. 57].
Die oberste Schicht des Management-Informationssystems beinhaltet Werkzeuge zur
Analyse der Daten und Präsentation der gefundenen Zusammenhänge. Auch Komponenten zur Navigation durch den Datenbestand sind hierzu zu zählen. Neben Werkzeugen zur tabellarischen Auflistung und graphischen Aufbereitung von Daten sind hier als
wichtigste Analyseinstrumente die Online-Analytical-Processing (OLAP)-Systeme, die
eine geeignete Navigation durch den Datenbestand ermöglichen, mit der Möglichkeit,
Daten in verschiedenen Verdichtungsstufen darzustellen und die verschiedenen Methoden des Data Mining zu nennen, durch die Muster und Zusammenhänge im Datenbestand aufgedeckt und verifiziert werden können. Da das Data Mining einen besonderen
Stellenwert bei der Unterstützung von Management-Entscheidungen einnimmt, ist dieses Teilgebiet der betrieblichen Informationssysteme im folgenden Kapitel näher zu
erläutern.
6
Kapitel 3: Datenanalyse
3 Datenanalyse
3.1 Data Mining
Für den Begriff des Data Mining hat sich weder eine allgemein anerkannte Definition
noch ein deutscher Terminus durchgesetzt. Die meisten in der Literatur zu findenden
Definitionen ähneln der von BERRY, LINOFF, die Data Mining definieren als Exploration
und Analyse großer Datenmengen mit automatischen oder semiautomatischen Werkzeugen, um bedeutungsvolle Muster und Regeln aufzufinden [Be97, S. 5]. Es sind also
mit möglichst geringer Benutzerinteraktion in Datenbeständen vormals unbekannte Zusammenhänge aufzudecken und in weiteren Analysen auf ihre Richtigkeit hin zu überprüfen. Das Data Mining ist Bestandteil des KDD-Prozesses (Knowledge Discovery in
Databases), der als integrierter Prozess verstanden wird, und alle Phasen der Wissensentdeckung, von der Auswahl, Extraktion und Vorbereitung der Daten über die Mustererkennung und Evaluation bis hin zur Präsentation und Interpretation umfasst. Eine
schematische Darstellung des KDD-Prozesses ist Abb. 3.1 zu entnehmen.
Quelle: Bensberg (2001), S. 72.
Abb. 3.1:
Graphische Darstellung des KDD-Prozesses
Die ersten drei Phasen des abgebildeten KDD-Prozesses ähneln sehr den in Kapitel 2.3
beschriebenen Schritten der Datenextraktion und -aufbereitung im ManagementInformationssystem: Aus den Quelldatenbeständen werden relevante Daten selektiert
7
Kapitel 3: Datenanalyse
und extrahiert (Phase 1), in ein einheitliches, konsistentes Format transformiert und in
einer Zieldatenbank abgelegt (Phase 2). Beim beschriebenen, idealtypischen Management-Informationssystem wird hierfür ein Data Warehouse verwendet. Beim KDDProzess ist die Verwendung eines Data Warehouse zwar nicht zwingend vorgeschrieben, in der Praxis jedoch häufig anzutreffen. VOSSEN merkt hierzu an, dass man Data
Mining unabhängig von einem Data Warehouse betreiben kann, dass allerdings ein
Data Warehouse das Data Mining leichter sowie billiger macht [Vo00, S. 705]. Die
Phase 3 des KDD-Prozesses, die Mustererkennung, entspricht der Anwendung verschiedener Data Mining Methoden. Hier wird der Datenbestand durchgescannt und nach
auffälligen Mustern durchsucht. In der Phase der Evaluation (Phase 4) wird für jedes
entdeckte Muster geprüft, ob es sich um einen neuen Zusammenhang handelt. Ist dies
der Fall, findet das Muster Eingang in die sogenannte Hypothesenbank. Widerspricht
ein gefundenes Muster einer bereits gespeicherten Hypothese der Hypothesenbank, so
sind beide näher zu überprüfen und zu verifizieren. In der Phase der Präsentation (Phase
5) werden die entdeckten Muster in eine für den Benutzer geeignete Form überführt.
Hierbei werden häufig tabellarische Darstellungen, Diagramme oder sonstige graphische Präsentationen verwendet. Dem Benutzer wird somit ein intuitiver Zugang zu den
gefundenen Zusammenhängen geboten. Die Phase der Interpretation (Phase 6) stellt den
Abschluss des KDD-Prozesses dar. Hier erfolgt eine Interaktion mit dem Anwender,
indem dieser die u.U. graphisch aufbereiteten Zusammenhänge interpretiert und es somit potentiell zu einer Veränderung seines Domänenwissens kommt.
Es sind in dem Bereich des Data Mining eine ganze Reihe von Methoden entwickelt
worden, von denen im Folgenden die wichtigsten und meistverwendeten vorgestellt
werden sollen.
3.1.1 Assoziationsanalyse
Unter der Assoziationsanalyse versteht man die Ermittlung von Abhängigkeiten zwischen Teilmengen eines Datenbestandes. Sie wird häufig in der Warenkorbanalyse eingesetzt: Angenommen, es sei eine endliche Menge von Produkten (oder allgemeiner:
Items) I = {i1, i2, ..., im} gegeben. Alle Kaufabwicklungen werden laufend in einer
Transaktionsdatenbank T = {t1, t2, ..., tn} abgespeichert, wobei jede Transaktion ti eine
Teilmenge von I darstellt, sich also aus einem oder mehreren Produkten zusammensetzt.
8
Kapitel 3: Datenanalyse
Nun wird in der Transaktionsdatenbank nach Assoziationsregeln gesucht, die die Struktur und Signifikanz der Abhängigkeit einer Prämisse zu einer Konsequenz beschreiben.
Prämisse und Konsequenz sind dabei Teilmengen des Datenbestandes und werden auch
als linke und rechte Seiten einer Assoziationsregel bezeichnet. Als Kennzahlen dienen
der Assoziationsanalyse der Supportfaktor, der Aussagen über die Häufigkeit einer entdeckten Regel macht, und der Konfidenzfaktor, der Aufschluss über die Zuverlässigkeit
der Regel gibt.
Um das Vorgehen der Assoziationsanalyse zu verdeutlichen, wird im Folgenden ein
einfaches Beispiel einer Warenkorbanalyse erläutert. Gegeben sei die in Tab. 3.1 aufgeführte Transaktionsdatenbank.
TID
134
134
134
134
135
135
135
136
136
137
137
137
Tab. 3.1:
KID
246
246
246
246
355
355
355
15
15
246
246
246
Position
1
2
3
4
1
2
3
1
2
1
2
3
Produkt
Füller
Tinte
Heft
Seife
Füller
Tinte
Heft
Füller
Heft
Füller
Tinte
Seife
Beispiel einer Transaktionsdatenbank
Nun kann z.B. eine einfache Assoziationsregel der Form
Tinte Æ Füller
gebildet werden, die Aufschluss über den gemeinsamen Kauf beider Artikel gibt.
Der Supportfaktor ist nun definiert als die Wahrscheinlichkeit, dass eine Transaktion
sowohl die Prämisse (in diesem Fall die Tinte), als auch die Konsequenz (Füller) beinhaltet. Für obige Assoziationsregel „Tinte Æ Füller“ beträgt der Support also 0,75 (Tinte und Füller tauchen in 3 von 4 Transaktionen auf, also 3/4 = 0,75).
Der Konfidenzfaktor gibt die bedingte Wahrscheinlichkeit dafür an, dass eine Transaktion, die die Prämisse (Tinte) enthält, auch die Konsequenz (Füller) beinhaltet. Für die
Assoziationsregel beträgt der Konfidenzfaktor daher 1 (in allen Transaktionen, in denen
Tinte gekauft wurde, wurde auch ein Füller gekauft, also 3/3 = 1).
9
Kapitel 3: Datenanalyse
In der Praxis sind in der Regel eine sehr große Anzahl von Produkten und eine riesige
Transaktionsdatenbank anzutreffen. Daher können hieraus eine noch größere Anzahl
potenzieller Assoziationsregeln gebildet werden (Anzumerken ist hierbei, dass nicht nur
Regeln bestehend aus einelementigen Mengen gebildet werden können, sondern z.B.
auch solche der Form „Tinte, Füller Æ Seife, Heft“. Hierdurch steigt die Anzahl möglicher Regeln nochmals). Um jedoch nur aussagekräftige Regeln zu generieren, wird
meist ein kritischer Support- und ein kritischer Konfidenzfaktor angegeben, so dass nur
noch solche Regeln ausgegeben werden, die diese Werte überschreiten.
Da die Assoziationsanalyse Aufschluss über korrelierte Produkte gibt, kann sie als Entscheidungsgrundlage zur bedarfsgerechten Ausgestaltung marketingpolitischer Maßnahmen herangezogen werden. So können Maßnahmen der Verkaufsraumgestaltung
und der Produktplatzierung daraus abgeleitet werden [Be01, S. 107].
3.1.2 Sequenzanalyse
Mit der Assoziationsanalyse methodisch sehr verwandt ist die Sequenzanalyse. Auch
hier werden Abhängigkeiten zwischen Teilmengen eines Datenbestandes ermittelt, allerdings unter Berücksichtigung eines meist zeitlichen Ordnungskriteriums. Hier interessiert nicht die Information, welche Produkte häufig gemeinsam in einer Transaktion
auftauchen, sondern wie groß die Wahrscheinlichkeit ist, dass ein Kunde, der ein Produkt A gekauft hat, innerhalb eines bestimmten Zeitraums auch ein bestimmtes Produkt
B kauft. Hierfür ist die Transaktionsdatenbank nach Kundennummern zu sortieren und
in eine Datenbank bestehend aus Konsumentensequenzen zu überführen (In Tab. 3.2 ist
eine solche Datenbank für die Transaktionsdatenbank aus Tab. 3.1 abgebildet). Aus
dieser sind dann alle Sequenzen zu bestimmen, deren Supportfaktor einen gewissen
Schwellenwert (Mindestsupport) überschreitet. Hierbei ist zu beachten, dass eine Sequenz nicht aus unmittelbar hintereinander folgenden Items bestehen muss, es ist lediglich die zeitliche Reihenfolge einzuhalten.
Beispielsweise würde in Tab. 3.2 die Sequenzregel
Füller Æ Heft
einen Support von 1 aufweisen, da diese Sequenz in allen Kundensequenzen aufzufinden ist.
10
Kapitel 3: Datenanalyse
TID
136
136
134
134
134
134
137
137
137
135
135
135
KID
15
15
246
246
246
246
246
246
246
355
355
355
Tab. 3.2:
Position
1
2
1
2
3
4
1
2
3
1
2
3
Produkt
Füller
Heft
Füller
Tinte
Heft
Seife
Füller
Tinte
Seife
Füller
Tinte
Heft
Sequenzdatenbank
Eingesetzt werden kann die Sequenzanalyse bei der Gestaltung kundenindividueller
Marketinginstrumente. So können einem Kunden nach einem Einkauf durch die Prognose seines zukünftigen Verhaltens auf geeignete Weise weitere Produkte angeboten
werden, so dass auf diese Weise eine stärkere Kundenbindung möglich wird. Dies ist
besonders geeignet für den Einsatz im internetbasierten Handel und wird beispielsweise
von der Firma AMAZON.COM angewendet, um kundenindividuelle Angebote zu offerieren.
3.1.3 Entscheidungsbauminduktion
Die Entscheidungsbauminduktion ist ein weit verbreitetes Verfahren zur Klassifikation
von Objekten. Hierzu wird eine baumartige Struktur, bestehend aus Knoten und Kanten,
gebildet. Jeder innere Knoten (incl. der Wurzel) stellt eine Testklasse für ein Attribut
der zugrundeliegenden Analyseobjekte dar. Die möglichen Ergebnisse sind an den
nachfolgenden Kanten eines Knotens abgetragen. In den Blättern des Entscheidungsbaumes sind schließlich die klassifizierten Merkmale abzulesen. Abb. 3.2 zeigt den
Aufbau eines solchen Baumes.
Durch Traversierung durch den Entscheidungsbaum lassen sich dann Produktionsregeln
ablesen, die zur Klassifikation von Objekten benutzt werden können, wie z.B.:
Wenn (Verschuldungsgrad < 40%) und (Einkommen < 40.000)
dann (nicht kreditwürdig).
Erzeugt wird solch ein Entscheidungsbaum für einen gegebenen Datenbestand durch
Anwendung geeigneter Verfahren, die in einer Lernphase einen Trainingsdatenbestand
11
Kapitel 3: Datenanalyse
vorklassifizierter Objekte analysieren. Die Güte des erzeugten Entscheidungsbaumes
wird dann anhand von Testdaten überprüft und deren Fehlerrate bestimmt.
Verschuldungsgrad
< 40%
Einkommen
< 40.000
nicht kreditwürdig
Wurzel
>= 40%
Innere
Knoten
Einkommen
>= 40.000
kreditwürdig
< 40.000
nicht kreditwürdig
>= 40.000
kreditwürdig
Blätter
Quelle: Bensberg (2001), S. 110
Abb. 3.2:
Darstellung eines Entscheidungsbaumes
Durch die anschauliche, graphische Repräsentation der Objektklassifikationen bietet der
Entscheidungsbaum eine hohe Transparenz für den Anwender.
3.1.4 Clusteranalyse
Durch die Clusteranalyse wird eine große Menge ungeordneter Objekte in kleinere,
homogene Teilmengen gruppiert. Objekte innerhalb eines solchen Clusters weisen zueinander homogene Merkmalsausprägungen auf, während sie zu Objekten eines anderen
Clusters heterogen sind. Zur Gruppierung werden sämtliche Merkmale der Objekte herangezogen.
Zur Durchführung sind zwei Schritte notwendig: Zunächst ist ein geeignetes Proximitätsmaß zu wählen, welches die Ähnlichkeit der einzelnen Objekte zueinander angibt.
Dabei werden die Ausprägungen aller Merkmale miteinander verglichen und zu einer
Ähnlichkeitskennzahl aggregiert. Als zweites ist ein Fusionierungsalgorithmus anzuwenden, der die Objekte nach ihren Ähnlichkeitswerten zu Gruppen zusammenfasst.
Hierbei ist zwischen hierarchischen und partitionierenden Verfahren zu unterscheiden.
Das agglomerative hierarchische Verfahren beginnt mit einelementigen Partitionen,
d.h. jedes Objekt stellt ein Cluster dar. Durch sukzessive Fusionierung, also durch kontinuierliche Erhöhung des Distanzniveaus werden Cluster zu einem neuen Cluster zusammengefasst.
Bei den divisiven hierarchischen Verfahren beginnt man mit der gesamten Objektmenge als einziges Cluster. Durch sukzessive Minderung des Distanzniveaus wird dann ein
12
Kapitel 3: Datenanalyse
Cluster in immer kleinere Cluster aufgeteilt. In Abb. 3.3 ist die Arbeitsweise der hierarchischen Verfahren dargestellt.
Quelle: Bensberg (2001), S. 119.
Abb. 3.3:
Dendogramm zur Clusterbildung mittels hierarchischer Verfahren
Die partitionierenden Verfahren erwarten eine initiale Gruppenaufteilung der Objekte
und versuchen dann hieraus kontinuierlich die Ausgangslösung zu verbessern.
Die Clusteranalyse wird häufig als erstes Verfahren zur Hypothesengenerierung verwendet, da es aus umfangreichen Datenmengen komplexe Strukturen aufdecken kann.
Auf den Ergebnissen der Clusteranalyse aufbauend sollten dann weitere Verfahren des
Data Mining angewendet werden.
3.2 Web Log Mining
Der elektronische Handel ist besonders geeignet, Geschäfts- und insbesondere Kundendaten elektronisch aufzubereiten und hieraus marketingrelevante Entscheidungen abzuleiten. Denn neben der Aufzeichnung von Kaufabwicklungen besteht hierbei auch die
Möglichkeit, das Verhalten der Kunden zu beobachten, zu speichern und hieraus weitere Informationen abzuleiten.
Die Aufgabe der Speicherung des Kundenverhaltens im internetbasierten Handel übernimmt die Protokollkomponente des Webservers, die in nahezu allen heutzutage eingesetzten Webservern verfügbar ist. Die vom Nutzer bzw. Kunden über einen Browser
getätigten Anforderungen werden dabei ebenso gespeichert, wie der Vorgang der Bear13
Kapitel 3: Datenanalyse
beitung einer Anforderung vom Webserver. Abb. 3.4 zeigt eine schematische Darstellung der serverbasierten Protokollaufzeichnung.
WWW-Server
WWW-Client
(Browser)
REQUEST
RESPONSE
Protokollkomponente
Abb. 3.4:
Log
Protokolldatei
Serverbasierte Protokollaufzeichnung.
Welche und wie viele Attribute bei der Serverinteraktion in die Protokolldatei übernommen werden, hängt von der Konfiguration des verwendeten Webservers ab. Es gibt
hierzu eine Reihe verschiedener standardisierter Log File-Formate, wie z.B. das Common Log File Format oder das W3C Extended Format. Alle sind im Aufbau ähnlich,
unterscheiden sich aber in Umfang und Codierung der protokollierten Daten. Der Aufbau der häufig verwendeten Erweiterung des älteren Common Log File Format, des
Combined Log File Formates soll im Folgenden vorgestellt werden:
Jede Zeile einer Protokolldatei weist dabei die gleiche Struktur auf und besitzt die folgenden, durch Leerzeichen getrennten Elemente:
Attribut
Beschreibung
Internetadresse
Eindeutige Rechneradresse des anfragenden Clients, entweder als symbolische DNS-Adresse (z.B. pcwi012.uni-muenster.de) oder als numerische IPAdresse (z.B. 80.129.240.65).
Anmeldekennung
Kann nur dann erfasst werden, wenn auf dem Clientrechner ein entsprechender Identifikationsdienst installiert ist. Findet in der Praxis jedoch kaum
Anwendung.
Authentifizierungskennung Kennung, mit der sich ein Nutzer am Server angemeldet hat. Dies ist üblich,
um bestimmte Ressourcen des Rechners zu schützen.
Zeit
Zusammengesetztes Attribut aus dem Datum, der Uhrzeit und der Zeitzone
des Serverstandortes.
HTTP-Anforderung
Zusammengesetztes Attribut, bestehend aus
•
Zugriffsmethode - GET für das Anfordern einer Ressource, POST für
das Zusenden von Daten, wie es z.B. bei Formularen benutzt wird
•
Adresse der angeforderten Ressource
•
HTTP-Version – zur Synchronisation von Client und Server
14
Kapitel 3: Datenanalyse
Status
Zeigt den Status der Anfrage-Verarbeitung an. Einige wichtige Stati:
•
200 – OK: Daten können gesendet werden
•
401 – Unauthorized: Die angeforderte Ressource ist zugangsgeschützt,
der Browser zeigt daraufhin ein Log-In Fenster an.
•
403 – Forbidden: Der Zugang zu einer geschützten Ressource mit der
eingegebenen Nutzername/Passwort Kombination wurde verweigert.
•
404 – Not Found: Die angeforderte Ressource ist nicht vorhanden
Umfang
Menge an Bytes, die zum anfragenden Client übertragen wurde. Tritt kein
Fehler auf, entspricht dies der Größe der angeforderten Ressource.
Browsertyp
Herstellerspezifischer Browsername und häufig auch die Versionsnummer
Betriebssystemtyp
Betriebssystem, das vom anfragenden Client verwendet wird.
Referent
Adresse der Ressource, die der Konsument in der vorangehenden Interaktion
angefordert hat.
Fehlermeldung
Meldungen, die der Fehleranalyse und Administration des WWW-Servers
dienen.
Tab. 3.3:
Attribute des Combined Log File Format.
Zur Veranschaulichung wird nachfolgend ein Auszug aus einer solchen Protokolldatei
angegeben:
80.129.240.65 - - [28/Nov/2003:10:53:27 +0100] "GET /produktkatalog/VR33381.php
HTTP/1.1" 200 15135 "http://www.google.de/search?..." "Mozilla/4.0 (compatible;
MSIE 5.01; Windows 98)"
80.129.240.65 - - [28/Nov/2003:10:53:28 +0100] "GET /Background-lg.gif HTTP/1.1"
200
159
"http://www.mein-server.de/produktkatalog/VR33381.php"
"Mozilla/4.0
(compatible; MSIE 5.01; Windows 98)"
...
129.206.114.31 - - [28/Nov/2003:11:36:56 +0100] "GET /produktkatalog/EU50088.php
HTTP/1.1"
200
15748
"http://de.search.yahoo.com/search/de?..."
"Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1)"
129.206.114.31 - - [28/Nov/2003:11:36:56 +0100] "GET /Background-lg.gif HTTP/1.1"
200
159
"http://www.mein-server.de/produktkatalog/EU50088.php"
"Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1)"
Die Intention des Web Log Mining als Spezialgebiet des Data Mining ist es nun, durch
Anwendung geeigneter Methoden auf Webserver-Protokolldateien Muster zu entdecken. Hierdurch kann Aufschluss über das Kundenverhalten erlangt und so die internetbasierte Marktapplikation hieran adäquat angepasst werden. Analog zum Data Mining
sind hierzu die Daten zunächst zu bereinigen und aufzubereiten und anschließend geeignete Analysemethoden anzuwenden.
3.2.1 Aufbereitung der Protokolldateien
Wie aus obigem Beispielauszug aus einer Protokolldatei ersichtlich wird, protokolliert
ein Webserver nicht nur die vom Konsumenten getätigten Anforderungen von beispielsweise HTML-Seiten, sondern er generiert auch für jedes eingebettete Element
innerhalb dieser Seite, wie z.B. Grafiken, einen eigenständigen Logeintrag. Da bei der
15
Kapitel 3: Datenanalyse
Analyse des Kundenverhaltens jedoch nur die besuchten Seiten der Konsumenten von
Interesse sind, müssen alle Einträge herausgefiltert werden, die keine HTML-Seite oder
dynamische Seite einer Skriptsprache, wie z.B. PHP darstellen.
Außerdem sollen nur Ressourcenanforderungen in die Analyse eingehen, so dass alle
Protokollzeilen, deren HTTP-Anforderung nicht GET lautet, ebenfalls gelöscht werden.
Ebenfalls nicht von Interesse sind fehlerhafte Anforderungen oder unvollständige Übertragungen, da in diesen Fällen davon auszugehen ist, dass der Benutzer die angeforderte
Ressource nicht wahrnehmen konnte. Diese sind anhand des Status-Attributes zu identifizieren.
Als Letztes ist darauf zu achten, dass auch nur wirkliche Konsumentenzugriffe berücksichtigt werden. Neben Konsumenten greifen jedoch auch die Betreiber der Marktapplikation zu administrativen Zwecken sowie regelmäßig automatische SuchmaschinenRoboter zur Indizierung der Webseiten auf die Webpräsenz zu. Administratorzugriffe
sind anhand der Authentifizierungskennung zu erkennen, während SuchmaschinenRoboter sich über den Browsertyp identifizieren lassen. Nachfolgend sind zwei Protokollzeilen abgedruckt, die Anfragen solcher Roboter beinhalten. Die erste ist eine Anfrage der Suchmaschine GOOGLE, die zweite wurde durch die Suchmaschine INKTOMI
generiert, die zur Firma YAHOO! gehört:
64.68.80.10 - - [28/Nov/2003:19:13:00 +0100] "GET /produktkatalog/MV00341.php
HTTP/1.0" 200 9973 "-" "Googlebot/2.1 (+http://www.googlebot.com/bot.html)"
66.196.72.16 - - [28/Nov/2003:19:14:18 +0100]
HTTP/1.0"
200
10848
"-"
"Mozilla/5.0
http://www.inktomi.com/slurp.html)"
"GET /produktkatalog/FT11411.php
(Slurp/cat;
[email protected];
Administratorzugriffe und Suchmaschinen-Roboter-Anforderungen sind also ebenfalls
nicht in die Analyse des Kundenverhaltens zu übernehmen.
3.2.2 Informationsgewinnung aus den Protokoll-Daten
Nachdem im letzten Schritt die Protokolldaten bereinigt wurden, so dass sie nun in einer
zu Analysezwecken geeigneten Form vorliegen, ist zu diskutieren, wie nun Informationen aus diesen Daten extrahiert werden können. Um Aussagen über das Kundenverhalten tätigen zu können, sind zunächst die einzelnen Kundentransaktionen zu ermitteln.
Darunter versteht man sämtliche Interaktionen eines Konsumenten mit der Marktapplikation, die einen zeitlichen Zusammenhang aufweisen [Be01, S. 138].
Da das HTTP ein verbindungsloses Protokoll darstellt, ist die Ermittlung der Transaktionen keine triviale Angelegenheit.
16
Kapitel 3: Datenanalyse
Die fehlerfreiste und sicherste Methode der Transaktionsableitung und damit auch der
Zuordnung einzelner Logzeilen zu einem Benutzer ist die Benutzer-Authentifizierung.
Falls sich jeder Benutzer einer internetbasierten Marktapplikation zunächst am Webserver mit einem eindeutigen Benutzernamen anmelden muss, wird diese daraufhin auch in
den entsprechenden Zeilen der Protokolldatei mitgeführt, so dass die Transaktionen
eindeutig ableitbar sind. Dieses Vorgehen trifft allerdings auf wenig Akzeptanz seitens
der Konsumenten, da diese ein möglichst bequemes und anonymes Durchsuchen des
Informationsangebotes bevorzugen.
Eine weitere Möglichkeit der Transaktionsableitung ist der Einsatz von sogenannten
Cookies. Dies sind kleine Textdateien, deren Inhalt meist nur aus einem eindeutigen
Schlüssel besteht. Greift ein Benutzer erstmalig auf eine Internetpräsenz zu, so wird
solch ein Cookie erzeugt und auf den Rechner des anfragenden Clients übertragen. Bei
allen weiteren Interaktionen dieses Benutzers mit dem Webserver lädt der Webserver
den Cookie vom Rechner des Benutzers, liest dessen Inhalt aus und kann den Benutzer
auf diese Weise authentifizieren. Eine Logzeile kann um die ausgelesene Identifikationskennung erweitert werden, so dass die einzelnen Transaktionen leicht abgeleitet
werden können. Kaum anwendbar wird diese Methode, da der Browser des Nutzers so
konfiguriert werden kann, dass er jegliche Cookies ablehnt. Außerdem können diese
auch leicht per Hand gelöscht werden.
Als letzte Methode bleibt schließlich noch die direkte Ableitung von Transaktionen aus
den Attributen der Protokolldatei:
Die Internetadresse scheint eine erste Möglichkeit zur Differenzierung unterschiedlicher
Nutzer zu sein. Es ist jedoch zu bedenken, dass die eindeutige Identifikation des Clients
über die Internetadresse nur bei direkter Kommunikation mit dem Server möglich ist.
Wird vom Client ein Proxyserver verwendet, so wird die Adresse des Proxys protokolliert. Da ein Proxyserver viele Benutzer gleichzeitig bedienen kann, ist es möglich, dass
verschiedene Benutzer mit der gleichen Internetadresse in der Protokolldatei verzeichnet sind. Außerdem ist zu beachten, dass Nutzer bei Einwahl ins Internet häufig eine
temporäre IP-Adresse zugewiesen bekommen, so dass ihre Internetadresse zur Authentifizierung nur temporäre Gültigkeit besitzt. Neben der Internetadresse werden daher
noch die Browser- und Betriebssystemdaten betrachtet, da nicht davon auszugehen ist,
dass ein Benutzer während einer Transaktion unterschiedliche Browser benutzt. Da
Transaktionen zudem zeitlich begrenzt sind, werden nur dann zeitlich aufeinanderfol17
Kapitel 3: Datenanalyse
gende Elementaroperationen zu einer Transaktion zusammengefasst, wenn ihre zeitliche
Distanz einen kritischen Wert nicht überschreitet [Be01, S. 140]. Auf diese Weise,
durch Berücksichtigung von Internetadresse, Browser- und Betriebsystemdaten und der
Zeit können Transaktionen hinreichend genau abgeleitet und so das Kundenverhalten
analysiert werden.
Für jede isolierte Transaktion kann dann beispielsweise über das Referent-Attribut der
initialen Interaktion abgelesen werden, über welche externe Webseite der Benutzer auf
die aktuelle Internetpräsenz navigiert ist. Ebenfalls über das Referent-Attribut sowie die
HTTP-Anforderung kann der komplette Navigationspfad des Benutzers nachvollzogen
werden. Das Zeitattribut schließlich gibt Aufschluss über die ungefähre Verweildauer
auf den einzelnen Seiten sowie die Dauer der gesamten Transaktion. In Tab. 3.4 sind
einige Attribute einer Transaktion aufgelistet, aus der die Ermittlung der erwähnten
Kennzahlen hervorgeht.
Internetadresse Zeit
HTTP-Anforderung Referent
194.232.66.25
[28/Nov/2003:14:26:47 +0100] GET A.html
Extern.html
194.232.66.25
[28/Nov/2003:14:28:25 +0100] GET B.html
A.html
194.232.66.25
[28/Nov/2003:14:28:39 +0100] GET C.html
B.html
194.232.66.25
[28/Nov/2003:14:28:59 +0100] GET B.html
C.html
194.232.66.25
[28/Nov/2003:14:29:44 +0100] GET D.html
B.html
Tab. 3.4:
Pfadableitung aus einer Transaktion
Im Rahmen des Web Log Mining können nahezu alle allgemeinen Data Mining Methoden angewandt werden. Einzige Voraussetzung, die erfüllt sein muss, um die
festgestellten
Muster
sinnvoll
interpretieren
zu
können,
ist
ein
geeignetes
Domänenwissen über die Inhalte der einzelnen Dokumente.
So können beispielsweise durch Anwendung der Assoziationsanalyse Verbundbeziehungen zwischen einzelnen Informationsangeboten bzw. Dokumenten der Marktapplikation aufgezeigt werden. Hieraus können dann Anpassungen der Markapplikation abgeleitet werden, indem z.B. durch Verweisintegrationen weitere Komplementärbeziehungen geschaffen werden.
Die Sequenzanalyse im eigentlichen Sinne kann im Web Log Mining nicht angewendet
werden, da nicht ohne weiteres mehrere Transaktionen einem Benutzer zugeordnet werden können. Wie bereits erwähnt, wäre dies nur über den Einsatz von Cookies oder die
Benutzerauthentifizierung möglich. Es ist aber eine Beschränkung auf einzelne Trans18
Kapitel 4: Fazit
aktionen möglich. Hierdurch können signifikante Navigationspfade ermittelt werden,
weshalb die Sequenzanalyse im Bereich des Web Log Mining auch als Pfadanalyse
bezeichnet wird [Be01, S. 149].
Als Letztes sei darauf hingewiesen, dass auch clusteranalytische Verfahren eine große
Bedeutung im Bereich des Web Log Mining besitzen. Als klassifizierende Merkmale
können hier alle in der Protokolldatei verfügbaren Attribute benutzt werden. Anzumerken ist hierbei, dass die Internetadresse einen Anhaltspunkt zur geographischen Herkunft des Konsumenten geben kann: Die Endung de deutet darauf hin, dass der Konsument möglicherweise aus Deutschland stammt. Allerdings ist hierbei wiederum der
mögliche Einsatz eines Proxyservers zu berücksichtigen, wodurch die Information der
Herkunft verfälscht würde. Als nützliche Information könnte die Clusteranalyse beispielsweise hervorbringen, dass fremdsprachliche Konsumenten (also Internetadressen
mit einer anderen Endung als .de für Deutschland, .ch für die Schweiz oder .at für Österreich) eine sehr kurze Verweildauer aufweisen. Hieraus könnte man schließen, dass
der Grund hierfür in der reinen Informationspräsentation in deutscher Sprache liegt. Zur
Verlängerung der Verweildauer dieser Konsumenten könnte man das Informationsangebot zusätzlich zur deutschen Sprache auch in weiteren Sprachen, z.B. in englisch anbieten.
4 Fazit
Es wurden eine Reihe von Möglichkeiten aufgezeigt, die sich Unternehmen bieten, um
der zunehmenden Datenflut zu entkommen und relevante Informationen aus den riesigen Datenbeständen interner und externer Quellen herauszufiltern. Diese Methoden
erlangen gerade deshalb eine solch große Bedeutung, da die hieraus gewonnen Informationen der Entscheidungsunterstützung des Managements dienen und damit indirekten
Einfluss auf die ökonomischen Zielgrößen der Unternehmen haben.
Es wurde zunächst die Notwendigkeit einer separaten Datenhaltung aller analyserelevanten Daten erörtert. Das Data Warehouse wurde dann als zentrale Komponente eines
Management-Informationssystems vorgestellt, um diese Aufgabe der zentralen
Datenhaltung zu übernehmen.
Anschließend wurden Möglichkeiten der Datenanalyse beschrieben. Es wurden sowohl
allgemeine Methoden des Data Mining erklärt, als auch im speziellen auf das Gebiet
19
Kapitel 4: Fazit
des Web Log Mining eingegangen, welches Methoden zur Analyse von Mustern in
Transaktionsdatenbanken internetbasierter Märkte bereitstellt.
Zusammenfassend ist festzustellen, dass eine Vielzahl unterschiedlicher Methoden existiert, mit denen in geeigneter Weise automatisch oder semiautomatisch Muster in großen Datenbeständen entdeckt und hieraus wiederum marketingstrategische Entscheidungen abgeleitet werden können. Insgesamt wirkt sich die effiziente Anwendung solcher Methoden positiv auf die ökonomischen Zielgrößen einer Unternehmung aus. Zu
beachten sind bei der Errichtung eines Management-Informationssystems und der Anwendung von Methoden des Data Mining allerdings die datenschutzrechtlichen Besonderheiten, die bei der Erfassung und Verarbeitung personenbezogener Daten bestehen.
Im Einzelfall ist daher zu untersuchen, welche Datenspeicherung und Methodenanwendung datenschutzrechtlich zulässig ist.
20
Literaturverzeichnis
[Be97]
M. J. A. Berry, G. Linoff: Data Mining Techniques: For Marketing, Sales
and Customer Support. John Wiley & Sons, New York et al., 1997.
[Be01]
F. Bensberg: Web Log Mining als Instrument der Marketingforschung – Ein
systemgestaltender Ansatz für internetbasierte Märkte. Gabler, Wiesbaden,
2001.
[In96]
W.H. Inmon: Building the Data Warehouse. 2. Aufl., John Wiley & Sons,
New York et al., 1996.
[Mu97]
H. Mucksch, W.Behme: Das Data-Warehouse Konzept: Architektur – Datenmodelle – Anwendungen. 2. Aufl., Gabler, Wiesbaden, 1997.
[Sc01]
R. Schütte, T. Rotthowe, R. Holten: Data Warehouse Management Handbuch - Konzepte, Software, Erfahrungen. Springer-Verlag, Berlin et al.,
2001.
[Vo00]
G. Vossen: Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme. 4. Aufl., Oldenbourg, München, Wien, 2000.