Seminar CRM SS Data Warehouses und Customer Relationship Management

Transkript

1 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 Churn-Analysen und Service-Optimierumg Warenkorb-Analyse Zielgruppen-Analyse Vertriebs-Targeting Budget-Analysen Cross-Selling Fertigung/Logistik/Distribution Cross-funktionale Fragen 5 4. Das Customer Orientation Framework (COF) 6 5. Data Warehouses eine technikorientierte Einführung Einleitung Grundlagen des OLAP Modellierung von Data Warehouses Der Fuzzy Logic Approach Bibliographie 15 1

2 1. Der Einsatz von Data Warehouses im Customer- Relationship-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

3 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

4 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 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 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 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 Ibid. 4

5 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 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 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.» 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 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 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 Ibid. 5

6 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, , Persönliche Beratung ). Abbildung 3: Die fünf Elemente des Customer orientation framework (COF) 6

7 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

8 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

9 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

10 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

11 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

12 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

13 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 Variablen 6 den Zugriff auf die darunter liegenden Daten, indem die fcql- Aufrufe 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,

14 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 A j, definiert auf einem Wertebereich D(A j ), ein Kontext zugeordnet. Ein Kontext K(A j ) ist dann eine Partition von D(A j ) in Äquivalenzklassen. Ein relationales Datenbankschema mit Kontexten besteht daher aus einer Menge von Attributen A=(A 1,...,A n ) und einer Menge assoziierter Kontexte K=(K 1 (A 1 ),...,K n (A n )). (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 where- Klausel 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

15 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, 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, Meier, A. (2003). A Data Warehouse Approach to Customer Relationship Management. Proceedings of the 2 nd International Conference "Management Education for the 21 st 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, 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,

16 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. ( ). "Common Warehouse Metamodel." Retrieved from Wikipedia. ( ). "Online Analytical Processing." Retrieved from 16