Seminar CRM SS 2006 Data Warehouses und Customer

Seminar CRM SS 2006
Data Warehouses und Customer Relationship
Management
Jan Guggisberg & Urs Dietrich
1.
Der Einsatz von Data Warehouses im Customer-Relationship-Management
2
2.
Die Einführung eines Data Warehouses
3
3.
Anforderungen an das Data Warehouse
4
3.1.1
Churn-Analysen und Service-Optimierumg
4
3.1.2
Warenkorb-Analyse
4
3.1.3
Zielgruppen-Analyse
4
3.1.4
Vertriebs-Targeting
5
3.1.5
Budget-Analysen
5
3.1.6
Cross-Selling
5
3.1.7
Fertigung/Logistik/Distribution
5
3.1.8
Cross-funktionale Fragen
5
4.
Das Customer Orientation Framework (COF)
6
5.
Data Warehouses – eine technikorientierte Einführung
7
6.
5.1
Einleitung
7
5.2
Grundlagen des OLAP
9
5.3
Modellierung von Data Warehouses
11
5.4
Der Fuzzy Logic Approach
13
Bibliographie
15
1
1.
Der Einsatz von Data Warehouses im CustomerRelationship-Management
Um heute noch konkurrenzfähig zu sein, müssen die Unternehmen Strategien entwickeln, die
den
Kundenanforderungen
entsprechen.
Die
Hauptschwierigkeit
hier
ist,
die
Kundenbeziehungen als Asset einzusetzen. Um dies zu erreichen, ist die Entwicklung eines
Data Warehouses unumgänglich. (Meier 2003)
Es
werden
Lösungen
angestrebt,
die
gezielt
den
Kundenanspruch
sowie
die
Kundenzufriedenheit steigern. Dazu benötigt man Daten, die z. B. Aussagen über das Kaufdas Reklamations- und das Bestellverhalten enthalten, um die Ausrichtung der gesamten
unternehmerischen Wertschöpfungskette auf den Kunden ermöglichen. Hier kommt das Data
Warehouse ins Spiel. Es dient als zentraler Speicher von Kundenwissen, das mit Hilfe
analytischer Hilfsmittel (Business Intelligence) wie Data-Mining und OLAP die benötigten
Informationen liefert. (Hofmann and Mertiens 2000)
Abbildung 1: Marktanalyse der Behandlung von Kundentaten für CRM
Wie man bei Abbildung 1 sieht, ist die häufigste Methode der Datenbeschaffung immer noch
die manuelle Sammlung. Ausserdem werden diese eher dazu gebraucht, die Bestellungen zu
machen, als das Kundenverhalten zu analysieren und zu überwachen. Wenn die Daten
elektronisch erfasst werden, stellt sich ausserdem das Problem, dass sich diese oft an
verschiedenen Standorten in verschiedenen Datenbanken befinden. Die Aufgabe des Data
Warehouses ist, die Daten aus den verschiedenen Datenquellen zu sammeln und soll
ermöglichen, dass diese ohne grösseren Aufwand analysiert werden können.
«Das Beispiel des Einzelhandels macht die Problematik klarer. Jeder Kunde hinterlässt an
der Scannerkasse Spuren seines Einkaufs. Es wird der genaue Inhalt des Einkaufswagens
2
zusammen mit dem Datum und der Uhrzeit des Einkaufs gespeichert. Sogar die Identität kann
bei Zahlung mit ec- oder Kreditkarte festgestellt werden.»1
2.
Die Einführung eines Data Warehouses
Die meisten Projekte ein Data Warehouse einzuführen, scheitern am organisatorischen
Aufwand. Es ist empfehlenswert, den Aufbau in verschiedenen Etappen vorzunehmen, da es
oft gar nicht möglich ist, ein unternehmensweites Data Warehouse in einem Schritt
aufzubauen. In Abbildung 2 sind die wesentlichen Schritte dargestellt:
Abbildung 2: Die wesentlichen Schritte bei der Einführung eines Data Warehouses
Als erstes muss bestimmt werden, welchen Anforderungen das Data Warehouse genügen soll.
Aufschluss darüber gibt eine Prozessanalyse der ausgewählten Unternehmensteile. Es wird
eine Mitarbeiterumfrage durchgeführt um die vorhandenen Informationsströme zu analysieren
und um herauszufiltern, welche Informationen gefordert werden. Ausserdem fördert diese
Umfrage die Akzeptanz für dieses neue Informationssystem. Mit den gewonnenen
Informationen wird nun ein Grobkonzept erstellt. Auf dieser Basis sollte eine
1
Hofmann, M. and M. Mertiens (2000). Customer-Lifetime-Value-Management. Kundenwerte schaffen und
erhöhen: Konzepte, Strategien, Praxisbeispiele. Wiesbaden, S. 155.
3
Wirtschaftlichkeitsanalyse durchgeführt werden, wobei der erwartete Nutzen des Ware
Houses den Kosten für Aufbau, Betrieb und Schulung der Mitarbeiter gegenübergestellt wird.
Hat man sich nun für die Einführung entschieden, müssen die verschiedenen Datenquellen
identifiziert und detailliert beschrieben werden. Ausserdem ist auf Abhängigkeiten zwischen
den verschiedenen Datenquellen zu achten.
Wenn man diese zwei Hauptschritte durchgeführt hat, muss man noch die richtige Software
auswählen und diese dem bestehenden System anpassen.
3.
Anforderungen an das Data Warehouse
«Von einem Data-Warehouse wird die komfortable Analyse komplizierter Sachverhalte mit
niedrigen Antwortzeiten, auch bei sehr grossen Datenmengen, erwartet.»2
Jegliche Auswertungen sollten ohne grossen Programmieraufwand machbar sein. Nicht alle
Benutzer sind an denselben Daten interessiert. Analytiker benötigen detailliertere Daten als
die Geschäftsleitung. Folgende Analysebeispiele geben Aufschluss auf die unterschiedlichen
Anforderungen an das Data Warehouse.
3.1.1 Churn-Analysen und Service-Optimierumg
Die Churn-rate ist die Rate der Vertragskündigungen oder die Rate der Geshäftskunden, die
dauerhaft in einem anderen Geschäft einkaufen. Die Gründe dieser Fluktuationen geben
oftmals Aufschluss über mögliches Optimierungspotential in der Kundenbeziehung.
Andererseits dient die Churn-Analyse auch als Frühwarnsystem.3
3.1.2 Warenkorb-Analyse
Durch die Analyse der Warenverkäufe kann überprüft werden, ob positive oder negative
Korrelationen zwischen den einzelnen Produkten bestehen (z. B. wird Bier häufig zusammen
mit Chips oder Grillwaren gekauft). Mit diesen Informationen lässt sich das Sortiment und die
Produktpositionierung optimieren.
3.1.3 Zielgruppen-Analyse
Data Warehousing und Data-Mining erlauben es, die klassische Zielgruppenanalyse um eine
Dimension zu erweitern. Verschiedenste Variablen des Kaufverhaltens können genauestens
untersucht werden. Somit kann vom bestehenden Sortiment auf Kundenprofile geschlossen
2
Ibid., S. 178.
3
Ibid.
4
werden, «die als ‹Schablone› für Neukunden dienen können.»4 Mit Hilfe dieser Profile können
ausserdem Vorhersagemodelle erstellt werden, welche die Wahrscheinlichkeit vorhersagen
können, ob ein neues Produkt ein Erfolg werden kann oder nicht.
3.1.4 Vertriebs-Targeting
Hier wird vor allem eine geographische Analyse der Kaufgewohnheiten durchgeführt. Mit
den gewonnenen Erkenntnissen können die Vertriebsressourcen optimiert und die
Marketingaktivitäten koordiniert werden.
3.1.5 Budget-Analysen
Mit Hilfe der Zielgruppenanalyse kann auch festgestellt werden, wie effektiv das Budget
bezüglich einzelner Kampagnen eingesetzt wurde: «so können zum Beispiel nach einer
Kampagne in einem Printmedium die reinen Abverkaufszahlen des beworbenen Produktes
aufgebrochen, mit der regionen- sowie zielgruppenspezifischen Reichweite des gewählten
Medium verknüpft und miteinander in Beziehung gesetzt werden.»5
3.1.6 Cross-Selling
Häufig werden bei grossen Produktpaletten die Geschäftsfelder getrennt, um die Vermarktung
zu vereinfachen. Dadurch werden mögliche Synergien gar nicht oder nur unzureichend
ausgenutzt. Ein Data Warehouse ermöglicht hier Geschäftsfelder zu virtuellen Einheiten zu
verknüpfen.
3.1.7 Fertigung/Logistik/Distribution
Durch die verschiedenen Analysen des Marktes mit Hilfe von Data-Mining können Trends
frühzeitig erkannt werden. Dies erlaubt es einem Unternehmen, rechtzeitig reagieren zu
können und die Fertigung anzupassen. Ausserdem kann die Lagerhaltung und der Vertrieb
schnell angepasst werden.
3.1.8 Cross-funktionale Fragen
Die Einführung eines Data Warehouses kann das Informationsverhalten der Mitarbeiter
positiv beeinflussen. Sie erhalten einen Einblick auf die gesamte Wertschöpfungskette und
können die Konsequenzen ihres Handelns besser abschätzen. Ausserdem können die
Verknüpfungen zwischen den Abteilungen analysiert werden. Managemententscheidungen
4
Ibid., S. 161.
5
Ibid.
5
können so auf eine solide Grundlage gestellt werden. Durch Red-Flag-Funktionalitäten
werden darüber hinaus schnelle Reaktionszeiten auf kritische Veränderungen ermöglicht.
Die hier aufgezeigten Beispiele stellen nur einen Bruchteil der Möglichkeiten dar, die durch
die Einführung von Customer Data Warehouses möglich sind.
4.
Das Customer Orientation Framework (COF)
Um Kundenbeziehungen zu bilden und zu pflegen, braucht es spezifische Methoden, hier
illustriert durch die fünf Elemente eines customer orientation frameworks (COF).
In einem ersten Schritt muss die Strategie festgelegt werden. Es muss ein Mix zwischen
Kundengewinnung, Kundenbindung und add-on selling gefunden werden.
Ziel der Kundengewinnung ist es, aus der Gesamtheit der Marktteilnehmer Sympathisanten zu
gewinnen, sie zu Interessenten zu machen und als Kunden zu gewinnen. Folgende Mittel
stehen
dafür
zur
Verfügung:
Imagewerbung/Public
Relations,
Produktwerbung,
Responsemedien (Mailings, Telefon…) usw.
Weiter muss versucht werden, die gewonnenen Kunden zu binden. Das Wohlwollen der
Kunden muss schrittweise gefestigt werden, um so die Loyalität und das Vertrauen der
Kunden zu erhöhen (Abbildung 4). Das kann man erreichen, wenn man in ständiger
Kommunikation mit den Kunden bleibt (Telefon, Fax, E-Mail, Persönliche Beratung…).
Abbildung 3: Die fünf Elemente des Customer orientation framework (COF)
6
Abbildung 4: Die einzelnen Phasen des Beziehungskreislaufes
Der zweite Schritt widmet sich der Planung. Als erstes müssen die Geschäftsprozesse
während dem gesamten Kundenlebenszyklus analysiert werden. Zweitens werden durch ein
customer equity model Kundensegmente gebildet oder angepasst. In einem dritten Schritt
werden
Kampagnen
geplant,
um
die
interessanten
Segmente
zu
bearbeiten
(Kundengewinnung und Bindung). (Meier 2003)
Drittens muss die Organisation geregelt werden. Eine wichtige Frage ist hier, ob ein chief
customer officer (CCO) ernannt werden soll oder nicht. Als Mitglied der Geschäftsleitung
wäre er dafür da, eine kundenorientierte Unternehmenspolitik zu garantieren. Ausserdem
wäre er für das Relationship-Marketing, sales und after-sales Dienstleistungen zuständig.
(Meier 2003)
Schritt vier dieses frameworks besteht in der Bereitstellung und dem Support von «customer
data warehouses» bzw. einer «contact database» (Meier 2003). Die folgenden Ausführungen
fokussieren auf technische Aspekte von Data Warehouses und gehen insbesondere auf neuere
Entwicklungen in diesem Bereich ein.
5.
Data Warehouses – eine technikorientierte
Einführung
5.1
Einleitung
Im Gegensatz zu Datenbanken, die im produktiven Bereich eingesetzt werden und
transaktionsorientiert ausgerichtet und diesbezüglich optimiert sind, werden Data Warehouses
7
unter dem Blickwinkel der Auswertbarkeit von Informationen entworfen und implementiert.
Elmasri und Navathe beschreiben sie in einer sehr allgemeinen Form als «a collection of
decision support technologies, aimed at enabling the knowledge worker (executive, manager,
analyst) to maker better and faster decisions» (Elmasri and Navathe 2004). Sie werden für
Anwendungen des On-Line Analytical Processings (OLAP), der Visualisierung, des Data
Minings und des Knowledge Discovery verwendet. Dabei sind die darin enthaltenen Daten
von den operationalen Daten getrennt, themenbezogen, integriert, zeitveränderlich und nicht
flüchtig (Vossen 2000). In der Praxis sind Data Warehouses in eine technische Umgebung
eingebettet, die in vielen Fällen etwa folgendem Muster entspricht:
o Die (meisten) Datenquellen sind relationale Datenbanken
o Das Data Warehouse selbst ist ein relationales Datenbankmanagementsystem.
o Datenintegration und –extraktion erfolgen offline, meist im Batchbetrieb über Nacht.
o Die Quelldatenbanken werden vollständig im Data Warehouse repliziert, die Extraktion
findet, wenn überhaupt, auf einem nur rudimentären Level statt.
o Das Data Warehouse wird weiter in Data Marts unterteilt, welche themenspezifische
Untersuchungen, Auswertungen und OLAP erlauben. Damit wird in vielen Fällen eine
zusätzliche Schicht zwischen dem in Abbildung 5 gezeigten Data Warehouse und den
anschliessenden Auswertungen gelegt.
Um ein Data Warehouse einzurichten, sind zumindest folgende Aktivitäten notwendig:
o Extrahieren von Daten aus operationalen Datenbanken
o Laden eines initialen Datensets
o Periodische Aktualisierungen dieses Datensets
o Transformation und Anpassung der Quelldaten an das Schema des Data Warehouse
8
Abbildung 5: Auswertungsorientierte Integration von Daten und Anwendungen von Data Warehouses
(Vossen 2000)
Da das Data Warehouse von den zugrunde liegenden Quellen losgelöst unterhalten wird,
müssen die Datenbestände in regelmässigen Abständen aktualisiert werden. Hier werden zwei
Ansätze unterschieden:
o Bei einem Refresh-Copy werden in bestimmten Abständen alle Daten neu ins Data
Warehouse kopiert. Für grosse Datenmengen ist dieser Ansatz ungeeignet.
o Bei einem Incremental-Copy werden nur die geänderten Daten im Data Warehouse
nachgeführt. (Vossen 2000)
Mittels des von der OMG vorgeschlagenen Common Warehouse Metamodells (CWM) wird
ein Standard zur Beschreibung, den Zugriff und den Austausch von Metadaten in Data
Warehouses vorgeschlagen. Der Standard definiert ein Metamodell, das Metadaten sowohl
aus betriebswirtschaftlicher als auch aus technischer Sicht darstellen kann. Da das CWM
sowohl die Syntax als auch die Semantik bereitstellt, kann der komplette Prozess beschrieben
werden. (OMG 2003; Haag 2004; Wikipedia 2006)
5.2
Grundlagen des OLAP
Beim On-Line Analytical Processing geht es in erster Linie um die Unterstützung von
Anfragen zum Zwecke von Analysen oder auch um eine Aufbereitung von geschäftskritischen
Daten für Entscheidungsträger in Unternehmungen. Der Begriff geht auf Codd zurück, der 12
Regeln zur Evaluierung von OLAP-Systemen formulierte und diese letztendlich auf 18
erweiterte (Codd, Codd et al. 1993). Unter dem Akronym FASMI (Fast Analysis of Shared
9
Multidimensional
Information)
wurden
1995
durch
Pendse
und
Creeth
fünf
herstellerunabhängige Evaluierungsregeln aufgestellt, um damit das OLAP-Konzept zu
beschreiben; hier wurde das Gewicht verstärkt auf Benutzeranforderungen und weniger auf
technische Anforderungen gelegt. OLAP wird den hypothesengestützten Analysemethoden
zugeordnet, was bedeutet, dass der Analyst vor der eigentlichen Untersuchung wissen muss,
welche Anfragen er an das System stellen möchte. Seine Hypothese wird dann durch das
Analyseergebnis bestätigt oder abgelehnt (Wikipedia 2006).
Zentral für Data Warehouses und OLAP ist die Sicht, dass Daten mehrdimensional sein
können. Das Data Warehouse wird als eine Menge von Fakten in einem multidimensionalen
Raum betrachtet, wobei jedes Faktum durch ein aggregiertes Mass sowie eine oder mehrere
Dimensionen wie «Zeit», «Ort» oder «Produktekategorie» gekennzeichnet ist.
Das folgende Beispiel eines 3D-Cubes zeigt Daten über erfolgte Verkäufe. Als Dimensionen
werden hier «Product», «Quarter» und «City» verwendet, als Mass (Measure) die Verkäufe.
In einem solchen – hier mit drei Dimensionen versehenen – Datenwürfel oder Data Cube
spannen die Dimensionen den Würfel auf, bilden also die Koordinatenachsen. Durch die
betrachteten Attribute wird der Würfel in Zellen zerlegt und jeweils mit einem Funktionswert
in Abhängigkeit der Dimensionen versehen. (Vossen 2000)
Abbildung 6: Bestandteile eines (3D-)Datenwürfels (Vossen 2000)
Auf einem solchen Cube können dann die folgenden Operationen ausgeführt werden:
o ein Roll-up aggregiert Daten, bildet Summen und reduziert Dimensionen,
10
o ein Drill-down navigiert von Summen zu detaillierteren Daten und entspricht damit der
Umkehrung des Roll-ups,
o Slice and Dice dient der Selektion von Teilwürfeln, z. B. der Selektion horizontaler
Ebenen oder einzelner Zellen,
o das Ranking bzw. Sorting bildet Rangfolgen und Ordnungen,
o derived oder computed attributes nehmen Ergebnisse von Berechnungen innerhalb
einer Dimension oder dimensionsübergreifend auf,
o das Nesting erlaubt die Darstellung eines n-dimensionalen Würfels (mit n>2) in genau
2 Dimensionen
o und das Pivoting erlaubt ein Rotieren von Spalten und Zeilen. (Elmasri and Navathe
2004)
5.3
Modellierung von Data Warehouses
Zur Unterstützung der oben aufgezählten Operationen haben sich spezifische Formen von
Datenbankschemas herauskristallisiert. Man unterscheidet in solchen Schemas zwischen einer
Faktentabelle und jeweils einer oder mehreren unnormalisierten Dimensionstabellen, die zu
einem Star-, Snowflake- oder Fact Constellation Schema angeordnet werden.
Beim Star-Schema bildet die Faktentabelle das Zentrum, die Dimensionstabellen die
«Strahlen». Jede Dimensionstabelle ist durch zwei Arten von Attributen gekennzeichnet,
nämlich durch einen gegebenenfalls künstlichen Schlüssel sowie zugehörende beschreibende
Attribute.
Abbildung 7: Allgemeine Form eines Starschemas (Vossen 2000)
11
Die einzelnen Dimensionen können als Hierarchie strukturiert sein, um Aggregationen zu
ermöglichen. Die Zeitdimension in Abbildung 8 weist zum einen eine Fragmentierung des
Jahres in Quartale, Monate und Tage auf, zum andern eine Fragmentierung in Wochen und
Tage.
Abbildung 8: Beispiel eines Starschemas (Meier 2003)
Ein solches Schema unterstützt keine Attributhierarchien, was aber durch eine Normalisierung
und einen Übergang von einem Stern- zu einem Snowflakeschema erreicht werden kann:
Abbildung 9: Beispiel eines Snowflakeschemas (Vossen 2000)
Ein Fact Constellation Schema verwendet mit mehreren Faktentabellen dieselben
Dimensionstabellen, so dass mehrere Starschemen praktisch überlagert werden.
12
5.4
Der Fuzzy Logic Approach
Heute ist nicht mehr der Mangel an Daten, sondern deren Überfluss ein Problem.
Unternehmen und Organisationen suchen daher Werkzeuge für die Datenanalyse, die ihnen
Grundlagen für Entscheide liefern können. Mittels Knowledge Discovery in Datenbanken
(KDD) werden wertvolle Informationen aus solchen Datenbeständen extrahiert. Primäres Ziel
eines solchen Prozesses ist die Reduktion der Datenkomplexität sowie das Erkennen von
Mustern. Klassische Ansätze verwenden Cluster- oder Regressionsanalysen, basieren also auf
statistischen Verfahren. Diese wiederum erfordern als Grundlage numerische Werte oder
solche aus einem definierten Wertebereich. Fehlt eine solche Basis, versagen viele der
herkömmlichen Ansätze. (Meier, Werro et al. 2005; Werro, Meier et al. 2005)
Anfragesprachen wie SQL setzen voraus, dass die Anfragen in der gleichen Granularität und
Genauigkeit formuliert werden, wie die Daten in der Datenbank abgelegt sind. SQL als die
am weitest verbreitete Anfragesprache erlaubt keine ungenau oder unscharf formulierten
Abfragen, was aber in vielen Fällen erwünscht ist. So ergeben sich in den verschiedensten
Anwendungsbereichen Probleme. (Werro, Stormer et al. 2005)
Abbildung 10: Beispiel einer unscharfen Abfrage unter Verwendung einer linguistischen Variable (Meier,
Mezger et al. 2003)
Die an der Universität Fribourg entwickelte unscharfe Klassifizierungssprache fuzzy
Classification Query Language (fCQL) basiert auf einer Erweiterung des relationalen
Datenbankschemas; hierbei wird ein Kontextmodell für unscharfes Klassifizieren von
Tabelleninhalten vorgeschlagen. fCQL ermöglicht mit Hilfe von vordefinierten unscharfen
linguistischen Variablen6 den Zugriff auf die darunter liegenden Daten, indem die fCQLAufrufe in SQL übersetzt werden, was wiederum eine Migration des Basissystems in eine
unscharfe Datenbank zu vermeiden hilft. (Meier, Mezger et al. 2003; Werro, Stormer et al.
2005)
6
Siehe dazu auch: Koop, E. A. (2004). Datenbankunterstützung für imperfekte Daten im Verkehrsumfeld.
Karlsruhe, 2004.
13
Mit Hilfe dieses Kontextmodells werden Klassen im relationalen Datenbankschema gebildet,
so dass z. B. «Lieferenten mit schlechtem Service» in eine andere Klasse als «Lieferanten mit
sehr gutem Service» zu liegen kommen.7 Damit wird die Komplexität reduziert. Neben
klassischen «scharfen» Klassifikationen, wie sie beispielsweise bei Gebrauch von bool’schen
Variablen entstehen, können auch solche verwendet werden, die Werte zwischen 0 und 1
akzeptieren, also 0.25 für die Klasse «Lieferenten mit schlechtem Service» und 0.75 für die
Klasse «Lieferanten mit sehr gutem Service» - ein so verorteter Lieferant ist also zumindest
ein akzeptabler Zulieferer.
Im fuzzy-relationalen Kontextmodell ist jedem Attribut Aj, definiert auf einem Wertebereich
D(Aj), ein Kontext zugeordnet. Ein Kontext K(Aj) ist dann eine Partition von D(Aj) in
Äquivalenzklassen. Ein relationales Datenbankschema mit Kontexten besteht daher aus einer
Menge
von
Attributen
A=(A1,...,An)
und
einer
Menge
assoziierter
Kontexte
K=(K1(A1),...,Kn(An)). (Meier, Mezger et al. 2003; Meier, Werro et al. 2005; Werro, Meier et
al. 2005)
fCQL ist stark an SQL angelehnt; anstelle des Kommandos «Select» wird «classify»
verwendet, die from-Klausel ist mit derjenigen in SQL identisch und an Stelle der whereKlausel wird das Konstrukt «with» verwendet, das ein Prädikat für eine Klassifikation
spezifiziert. Ein Beispiel für eine Anfrage könnte dann wie folgt aussehen:
classify
CUSTOMER
from
CUSTOMERRELATION
with
turnover is high and paymenttime is positive
Wie bereits erwähnt, wird mit diesem System das Datenbankschema erweitert, und zwar im
Bereich
des
Metadatenmodells.
Namen
und
dazugehörende
Definitionen
der
Äquivalenzklassen, die Beschreibung der Klassen und die gesamten Metainformationen, die
so genannten «membership functions» betreffend. Abbildung 11 zeigt die Architektur des
fCQL-Toolkits, dessen wesentlichstes Merkmal die Zwischenschicht zwischen dem
relationalen DBMS und dem Benutzer ist und es ermöglicht, dieses DBMS inhaltlich nicht zu
verändern, sondern lediglich zu erweitern. Der Zugriff auf die Datenbank erfolgt entweder
wie bis anhin direkt (Fall 1) und unter Einsatz von SQL, über mEdit (Fall 2) oder über den
Interpreter von fCQL (Fall 3). Mit mEdit kann der Datenarchitekt Attribute auswählen,
Äquivalenzklassen, linguistische Variablen, linguistische Terme und «membership functions»
7
Siehe dazu auch die Arbeiten zum Thema «Imperfekte Daten» und «Erweiterungen des relationalen Modells
für unscharfe Klassifikationen»: Merkel, A. (2003). Imperfektion und Datenbanken. Schemaerweiterung zur
Abbildung von imperfekten Daten, Schepperle, H., A. Merkel and A. Haag (2004). Erhalt von Imperfektion in
einem DataWarehouse. Symposium “Data Warehousing und Data Mining“, Darmstadt.
14
definieren. Der Interpreter erlaubt die Bildung von unscharfen Anfragen, die analysiert und
dann nach einer Übersetzung in SQL an die Datenbank geschickt werden. Das Resultat
ermöglicht dem Interpreter, die Unschärfe für den Benutzer zu berechnen.8
Abbildung 11: Architektur des fCQL Toolkits
6.
Bibliographie
Codd, E. F., S. B. Codd and C. T. Salley (1993). Providing OLAP to User-Analysts: An IT
Mandate. Codd & Associates. Michigan
Elmasri, R. and S. B. Navathe (2004). Fundamentals of Database Systems. Boston
Haag, A. (2004). Konzeption und Umsetzung einer Erweiterung des Common Warehouse
Metamodel (CWM) zur Beschreibung von imperfekten Daten. Karlsruhe, 2004.
Hofmann, M. and M. Mertiens (2000). Customer-Lifetime-Value-Management. Kundenwerte
schaffen und erhöhen: Konzepte, Strategien, Praxisbeispiele. Wiesbaden
Koop, E. A. (2004). Datenbankunterstützung für imperfekte Daten im Verkehrsumfeld.
Karlsruhe, 2004.
Meier, A. (2003). A Data Warehouse Approach to Customer Relationship Management.
Proceedings of the 2nd International Conference "Management Education for the 21st
Century", Hanoi, Vietnam.
Meier, A., C. Mezger, N. Werro, et al. (2003). Zur unscharfen Klassifikation von
Datenbanken mit fCQL. Proceedings of the GI-Workshop LLWA - Lehren, Lernen,
Wissen, Adaptivität.
Meier, A., N. Werro and M. Albrecht (2005). Using a Fuzzy Classification Query Language
for Customer Relationship Management. Proceedings of the Very Large Database
Conference (VLDB05), Trondheim.
Merkel, A. (2003). Imperfektion und Datenbanken. Schemaerweiterung zur Abbildung von
imperfekten Daten.
Nançoz, C. (2004). mEdit. membership function editor for fCQL-based architecture. Fribourg,
2004.
OMG (2003). Common Warehouse Metamodel (CWM) Specification.
8
Siehe dazu auch den ausführlichen Artikel von Christian Nançoz: Nançoz, C. (2004). mEdit. membership
function editor for fCQL-based architecture. Fribourg, 2004.
15
Schepperle, H., A. Merkel and A. Haag (2004). Erhalt von Imperfektion in einem
DataWarehouse. Symposium “Data Warehousing und Data Mining“, Darmstadt.
Vossen, G. (2000). Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme.
München
Werro, N., A. Meier and C. Mezger (2005). Concept and Implementation of a Fuzzy
Classification Query Language. Proceedings of the International Conference on Data
Mining (DMIN05). World Congress in Applied Computing, Las Vegas.
Werro, N., H. Stormer and A. Meier (2005). Personalized discount - a fuzzy logic approach.
Proceedings of the IFIP International Conference on eBusiness, eCommerce and
eGovernment, Poznan, Poland.
Wikipedia. (11.05.2006). "Common Warehouse Metamodel." Retrieved 23.05.2006 from
http://de.wikipedia.org/wiki/CWM.
Wikipedia. (19.05.2006). "Online Analytical Processing." Retrieved 22.05.2006 from
http://de.wikipedia.org/wiki/OLAP.
16