Zwischenbericht Teil A. Personalisierung internetbasierter Handelsszenarien

Transkript

1 Zwischenbericht Teil A der Projektgruppe Personalisierung internetbasierter Handelsszenarien DATA IN KNOWLEDGE OUT Tim Brüggemann, Tina Goldau, Christian Lüpkes, Michael Onken, Matthias Pretzer, Christian Reitenberger, Carsten Saathoff, Helge Saathoff, Ralph Stuber, Insa Stührenberg, Oliver Wien, Guido Zendel, Ralf Krause, Heiko Tapken Carl von Ossietzky Universität Oldenburg Fakultät 2 Department für Informatik Abteilung Informationssysteme Prof. Dr. Appelrath

2

3 c Prof. Dr. Hans-Jürgen Appelrath Carl v. Ossietzky Universität Department für Informatik Escherweg Oldenburg appelrath@informatik.uni-oldenburg.de erschienen im Jahr 2003

4

5 Dieser Bericht fasst die Ergebnisse zusammen, die etwa bei Halbzeit des Projektes vorliegen. Die Projektgruppe Personalisierung internetbasierter Handelsszenarien gehört zum Fachbereich Informatik der Universität Oldenburg und findet im Wintersemester 2002/2003 und im Sommersemester 2003 statt. Dieser Zwischenbericht setzt sich aus zwei Teilen zusammen: Teil A fasst den bisherigen Ablauf und die bisherigen Ergebnisse der Arbeit der Projektgruppe zusammen Teil B enthält die ausgearbeiteten Seminarvorträge aus der Seminarphase der Projektgruppenteilnehmer Nach Abschluss der Projektgruppe im Herbst 2003 wird ein Endbericht erscheinen.

6

7 Inhaltsverzeichnis 1 Rahmenbedingungen Was ist eine Projektgruppe? Definition von Projektgruppen Erläuterungen zum Zweck von Projektgruppen Hinweise für Veranstalter und Studierende Projektgruppenantrag Formalia Veranstalter Zeitraum Umfang Lehrveranstaltungsäquivalent Inanspruchnahme von Fachbereichsressourcen Teilnahmevoraussetzungen Aufgabenstellung Kartensysteme Zielsetzung Entwicklungsumgebung Minimalergebnisse, Scheinkriterien Meilensteinplanung Literatur Teilnehmer Seminarphase Data Warehousing Datenanalyse allgemein Der KDD-Prozess Data Preprocessing - Datenvorverarbeitungsschritte des Prozessmodelles Clustering und Klassifikation Assoziationsanalyse und Konzeptbeschreibung I

8 Inhaltsverzeichnis 2.7 Temporale Aspekte des Data Mining Geschäftsmodelle Datenanalyse im Marketing Verwendung personalisierter Daten im Web Web Usage Mining Rechtliche und soziale Aspekte der Datenanalyse Dokumentationen Händler Aufgabenbeschreibung Kurze Beschreibung des Händlers Aufgaben Vorgehensweise Aufgabenanalyse Entwurf unter Berücksichtigung temporaler Aspekte Subject Area Bestellung Subject Area Hersteller Subject Area Kunde Subject Area Produkte Subject Area Sitzung Subject Area Warenkörbe Überprüfung und Erweiterung Implementierung Plausibilitätsprüfung Dokumentation Meilensteine Zusammenfassung Händler Aufgabenbeschreibung Die gestellte Aufgabe Vorgehensweise Meilensteine Analyse Anforderungsdefinition Entwurf Entitätenbestimmung Designentscheidungen Entwurf des Datenschemas Testdaten II

9 Inhaltsverzeichnis List of Value Perl erzeugte Testdaten Zusammenfassung Kartenanbieter Aufgabenbeschreibung Anforderungsdefinition Business Understanding Data Understanding Entwurf Entitätenbestimmung Designentscheidungen Entwurf des Datenmodells Testdaten Meilensteine Fazit Anhang Anforderungsdefinitionen Gesamtszenario Ausgangssituation und Zielsetzung Systemeinsatz und Systemumgebung Funktionale Anforderungen Nichtfunktionale Anforderungen Benutzerschnittstellen und Fehlerverhalten Dokumentationsanforderungen Abnahmekriterien Integration Ausgangssituation und Zielsetzung Systemeinsatz und Systemumgebung Funktionale Anforderungen Nichtfunktionale Anforderungen Benutzerschnittstellen Dokumentationsanforderungen Abnahmekriterien Anhang Analyse Ausgangssituation und Zielsetzung Allgemein Aufgaben im 1. Teilschritt Systemeinsatz und -umgebung III

10 Inhaltsverzeichnis Funktionale Anforderungen Laufzeit-Konfiguration Temporale Erweiterung WEKAs Algorithmus für kalendarische Muster Nicht-Funktionale Anforderungen Benutzerschnittstellen Fehlerverhalten Dokumentationsanforderungen Abnahmekriterien Zusammenfassung und Ausblick 183 IV

11 1 Rahmenbedingungen 1.1 Was ist eine Projektgruppe? Im Folgenden wird das Selbstverständnis dieser Lehrveranstaltungsform in Form einer Definition, Erläuterungen zum Zweck sowie Hinweise für Veranstalter und Studierende einer Projektgruppe beschrieben. Ein Papier zu dieser Thematik stand bereits zum Jahreswechsel 87/88 im wesentlichen fest und wurde nach kleinen Änderungen am von der Studienkommission des Fachbereichs Informatik der Universität Oldenburg verabschiedet Definition von Projektgruppen Projektgruppen sollen die Besonderheiten eines Fortgeschrittenenpraktikums, eines Seminars und einer Studienarbeit vereinen und zugleich berufstypische Arbeitsweisen im Studium vermitteln. Eine Projektgruppe besteht aus acht bis zwölf Studierenden, die ein Jahr lang ein umfangreiches Problem bearbeiten. Insgesamt wird diese Lehrveranstaltung mit 15 Semesterwochenstunden angesetzt. Die Themen für Projektgruppen können sowohl aus der Kern-Informatik als auch aus ihren Anwendungsgebieten stammen. Es ist möglich (und auch sinnvoll), daß sich an einer Projektgruppe Studierende anderer Fachrichtungen oder externe Kooperationspartner beteiligen. Eine Projektgruppe sollte i. allg. durch eine Stammvorlesung und/oder eine Spezialvorlesung vorbereitet werden. In der Regel werden aus einer Projektgruppe mehrere Diplomarbeiten hervorgehen Erläuterungen zum Zweck von Projektgruppen Zu vermittelnde berufstypische Arbeitsweisen sind: Arbeiten im Team (insbesondere: Präzisierung und Definition von Schnittstellen, Aufgabenverteilung, Zuständigkeiten und Verläßlichkeiten in einer Gruppe) 1

12 1 Rahmenbedingungen Umfassendere Betrachtungsweisen bei der Software-Entwicklung (Kennenlernen des gesamten Software-Lebenszyklusses, Verwendung unterschiedlicher Spezifikationssprachen, Ist- und Soll-Analysen, Kosten-Nutzen-Analysen, Einsatz- und Auswirkungsproblematik, Standard- und kundenspezifische Software) Einsatz von Werkzeugen (Sichtung vorhandener Software, Planung und Auswahl von Sprachen, Nutzung von Software-Entwicklungswerkzeugen, maschinenabhängige und maschinenunabhängige Konzepte) Konkrete Erstellung von Software unter gleichzeitiger Anfertigung einer Dokumentation und weiterer Materialien (Handbücher, Konfigurierungen, Wartungsanweisungen usw.) Arbeitsstil und persönliche Befähigungen (Organisation umfangreicher Projekte, Präsentation von Resultaten und Teilnahme an Diskussionen, Sitzungen mit präziser Protokollierung, Planungs- und Konfliktmanagement, Einarbeitung und Beschaffung von Literatur, Einblick in arbeitspsychologische Phänomene) Hinweise für Veranstalter und Studierende Entsprechend dieser Ziele sollte eine Projektgruppe nach folgendem Schema geplant werden und ablaufen: 1. Die Vorgaben durch die Veranstalter umfassen: Grobziele der Projektgruppe mit Themenstellung und Zielsetzungen Zeitplanung über zwei Semester Literaturangaben und Vorträge für die Seminarphase Vorschläge für Selbstverwaltungsaufgaben Teilnahmevoraussetzungen präzise Kriterien für die Erlangung des Projektgruppenscheins benötigte Ressourcen des Fachbereichs und Entwicklungsumgebungen 2

13 1.1 Was ist eine Projektgruppe? 2. Minimalergebnisse: Von jedem Teilnehmer wird die aktive Mitarbeit an den Projektgruppensitzungen, die Vorbereitung und Abhaltung eines oder zweier Seminarvorträge, die Erfüllung von bestimmten Verwaltungsaufgaben innerhalb der Projektgruppe, die Mitarbeit an einem Zwischen- und einem Endbericht und die Erfüllung der übertragenen Programmieraufgaben erwartet. Frühzeitige Aussprachen über mangelnde Mitarbeit oder Desinteresse bei Beteiligten gehören zum Konfliktmanagement und sollten keinesfalls verdrängt werden. Von besonderer Bedeutung ist die kontinuierliche Erarbeitung einer Dokumentation, an der alle Teilnehmer in gleichem Maße mitwirken müssen. Dabei geht es nicht um ein Handbuch (das ebenfalls erstellt werden muß), sondern um die systematische Darstellung z. B. folgender Bereiche: Problemstellung, Literatur, Überblick Ist-Analyse und Soll-Konzept Anforderungen, Spezifizierungen, Benutzungsschnittstellen Empirische und formale Evaluation Modulbeschreibungen und Implementierung Integration und Tests Wartung, Fehlerfälle, Portierungsmöglichkeiten Erweiterungen, Ausblick. 3. Die Zeitplanung kann nach folgendem Schema ablaufen: Vorlesungsfreie Zeit vor der Projektgruppe: Vorbereitung der Vorträge der 1. Seminarphase, Einarbeitung in die Entwicklungsumgebungen Erstes Semester: Seminarphase (ca. vier Wochen) Planungsund Entwurfsphase (ca. vier Wochen) Spezifikationen, Aufgabenverteilung, Probeimplementierungen (ca. vier Wochen) Vorlesungsfreie Zeit: Beginn der Implementierungsphase Zweites Semester: Weiterführung der Implementierungsphase, Integrationsphase und Tests (ca. vier Wochen), Seminarphase, Erprobung, Handbuch, Dokumentation 3

14 1 Rahmenbedingungen Vorlesungsfreie Zeit nach der Projektgruppe: Präsentation der Projektgruppenergebnisse im Fachbereich Informatik. Besuche bei anderen Fachbereichen und/ oder Anwendern sollten eingeplant werden; empfehlenswert ist eine Exkursion zu Firmen/ Institutionen, die sich mit ähnlichen Fragen wie die Projektgruppe beschäftigen. 4. Selbstverwaltungsangaben in der Projektgruppe: Erfahrungsgemäß fallen folgende Ämter an: Meilensteinüberwachung/ Projektplaner Schnittstellenüberwachung und -präzisierung Tester Archivar Bibliothekar und Literaturbeschaffung Experten für spezielle Programmiersprachen Experten für spezielle Rechnersysteme Experten für spezielle Softwaresysteme Kümmerer und Haushaltsüberwacher Webbeauftragter Hinweis: Projektgruppen sind von den Gremien des Fachbereichs Informatik zu genehmigen. Hierzu ist zunächst das Thema und die Ankündigung (einschl. der unter 1 bis 3 genannten Punkte) im vorangehenden Semester der Studienkommission zur Bestätigung vorzulegen. Da eine Projektgruppe ein Seminar, ein Fortgeschrittenenpraktikum und eine Studienarbeit ersetzt, muß der Diplom-Prüfungsausschuß die Äquivalenz der Projektgruppe mit diesen Studienleistungen genehmigen. Anschließend kann die Projektgruppe ausgeschrieben werden. Eine Projektgruppe soll nicht begonnen werden, wenn weniger als acht Studierende an ihr teilnehmen. 1.2 Projektgruppenantrag Die nachfolgende Übersicht faßt den im Fachbereich gestellten Antrag des Veranstalters auf Durchführung der Projektgruppe in seinen formalen Angaben und der Aufgabenstellung zusammen. 4

15 1.2 Projektgruppenantrag Formalia Veranstalter Prof. Dr. H.-J. Appelrath Informatik-Assistent Ralf Krause Dipl.-Informatiker Heiko Tapken Zeitraum WS 02/03 und SS Umfang Bei der Planung ist eine Basierung der Abschätzung auf der Grundlage von Personen-Tagen üblich. Ein Personen-Tag umfasst acht Stunden. Für die Projektgruppe sind folgende Aufwände zu verplanen (ein Jahr - zwei Wochen Urlaub - vier Wochen Seminar): Fachbereich 10 (Informatik): 7 Personen * 20 Stunden * 46 Wochen= Personen-Stunden Fachbereich 4 (Wirtschaftswissenschaften): 5 Personen * 15 Stunden * 46 Wochen= Personen-Stunden Insgesamt Personen-Stunden/8 Stunden, d.h Personen- Tage Lehrveranstaltungsäquivalent 1 Seminar 1 Fortgeschrittenpraktikum 1 Studienarbeit Inanspruchnahme von Fachbereichsressourcen Der Rechner- und Softwarebedarf wird durch Ressourcen der veranstaltenden Abteilung befriedigt. Ein Raum für Sitzungen steht im OFFIS-Gebäude zur Verfügung Teilnahmevoraussetzungen Abgeschlossenes Grundstudium mit erfolgreich abgeschlossenem Vordiplom zu Beginn des WS 02/03. 5

16 1 Rahmenbedingungen Aufgabenstellung Das Ziel dieser Projektgruppe ist es, ein System zu konzipieren und zu realisieren, das personalisierte, internetbasierte Handelsszenarien abbildet. Die Teilnehmer der Projektgruppe sollen sich in die Lage eines Kartenanbieters (analog zu Payback, Miles&More) versetzen. Es soll ein neues Szenario für die Nutzung von Kundenkarten realisiert werden, das von mehreren Händlern genutzt wird, um dieses später weiteren Händlern zu verkaufen Kartensysteme Kartensysteme bieten Vorteile für Händler, Anbieter von Kartensystemen sowie für Kunden. Kunden haben die Möglichkeit, ein personalisiertes Informations- und Warenangebot in Anspruch zu nehmen. Dieses wird dadurch ermöglicht, dass Handelstransaktionen von partizipierenden Kunden von den Händlern an den entsprechenden Kartenanbieter (Card-Provider) übermittelt werden. Dafür erhält der Händler vom Card-Provider ein Entgelt. Der Kartenanbieter analysiert nun die Kundendaten. Heute beschränken sich die von den Kartenanbietern durchgeführten Analysen auf die Segmentierung von Kunden in Kundengruppen (Bsp.: Amazon). Händler sind bestrebt, ihren Kunden ein möglichst gutes Angebot zu machen. Dies können sie gewährleisten, indem sie von Kartenanbietern Analyseergebnisse in Form von Kundengruppenbeschreibungen und Einkaufsregelbeschreibungen einkaufen. Dies kann z.b. unter Verwendung eines Publish/Subscribe Ansatzes erfolgen. Diese gekauften Informationen kann der Händler nutzen, um Kunden kundengruppenzentrierte Angebote z.b. über das Internet unterbreiten zu können. Die sich ergebenden Vorteile für alle partizipierenden Gruppen werden im folgenden dargestellt: Kunden erhalten ein auf sie zugeschnittenes Informations- und Warenangebot, der Händler kann seine Kunden besser an sich binden und der Kartenanbieter verdient durch Verkauf seiner Analyseergebnisse. Tatsächlich profitieren jedoch in der Regel nur die Kartenanbieter und die Händler, da die Kunden ihre Daten für eine geringe Gegenleistung bereitstellen. Der Kunde wird durch die Weitergabe seiner Daten zum gläsernen Kunden, wodurch sich Probleme entwickeln können (Datenschutz usw.). Der 6

17 1.2 Projektgruppenantrag Händler hingegen begibt sich durch die Einführung von Kartensystemen in eine Abhängigkeit zu dem mit ihm kooperierenden Kartenanbieter. Für Kunden und Händler kann es ferner von Nachteil sein, dass ihre Daten in einem Informationsverbund gespeichert werden, auf den sie nur beschränkt Einfluss nehmen können. Wenn z.b. ein Kartenanbieter einer Branche mit einem Händler kooperiert, sollte er z.b. (auch schon technisch) daran gehindert werden, diese Daten einem Konkurrenten dieses Händlers zukommen zu lassen. Nachteile für den Kartenanbieter ergeben sich i.d.r. nicht. Aus diesem Grunde versetzt sich die Projektgruppe in die Rolle eines Kartenanbieters. Um ein System entwickeln zu können, dass von einem Kartenanbieter angeboten werden kann, ist es notwendig, sowohl die Seite des Kartenanbieters als auch die Rolle des Händlers zu betrachten: Händler Ein Händler partizipiert in der zu betrachtenden Architektur in zweierlei Formen von Handelsbeziehungen. Er handelt einerseits mit Kunden durch den Verkauf von Gütern. Andererseits verkauft er dem Kartenanbieter Informationen und kauft Analyseergebnisse von diesem. Er sammelt und speichert alle Daten (Verkaufsdaten, Interessenten, Web-logs, etc.), die mit seinem Geschäft zu tun haben. Einen kleinen Teil dieser Daten (die Daten, die mit der angebotenen Karte zu tun haben, i.d.r. die Informationen des Kassenbons) übermittelt er an den Kartenanbieter. Ihm stehen jedoch weit mehr Informationen zur Verfügung, die er zur Individualisierung seines Angebotes nutzen könnte. Hierbei könnte er z.t. auf die vom Kartenanbieter gelieferten Analyseergebnisse zurückgreifen. Kennt er die Präferenzen seines Kunden als Individuum (Tante-Emma-Laden Metapher), so kann er z.b. in einem elektronischem Shopsystem eine personalisierte Präsentation seiner Waren vornehmen. Kartenanbieter Der Kartenanbieter geht Handelsszenarien mit Händlern und Endkunden ein. Um an die Daten zu kommen, die für die Identifikation von Kundengruppen benötigt werden, bezahlen die Kartenanbieter die Kunden in Form von Prämien (Punktesysteme, Prämien, o.ä.). An die Daten von Kunden kommen die Kartenanbieter durch die Händler, die ein Entgelt (z.b. in Form 7

18 1 Rahmenbedingungen von Analyseergebnissen) für das Processing (Bearbeiten) der Daten erhalten. Der Kartenanbieter sammelt, integriert, bereinigt und speichert die Daten dauerhaft. Anhand dieser aufbereiteten Daten ist der Kartenanbieter in der Lage, Analysen verschiedener Art durchzuführen. Hierzu zählen die Warenkorbanalyse, die Kundengruppierung, die Konzeptbeschreibung sowie die Herleitung von Regeln. Ein fiktives Beispiel für eine solche Regel ist: Ein junger Vater Ende 20, der in einem Supermarkt Pampers kauft, kauft mit einer Wahrscheinlichkeit von x% auch einen 6er Träger Bier. Die Ergebnisse dieser Analysen kann er Händlern zum Kauf anbieten. Die an diesem Handel teilnehmenden Personen können hierbei andere sein als die, die sich an der Datenlieferung beteiligt haben Zielsetzung Die Aufgaben der Projektgruppe gliedern sich in zwei Aufgabengebiete: 1. Herleitung personalisierter Daten Kundensegmentierung: Wie kann man (aggregierte) Kundendaten mehrerer Händler nutzen, um Kunden in Gruppen einzuteilen? (Card- Provider) Individualisierung: Wie kann man aus den Daten individuelle, interessante Angebote für den Kunden erstellen? (Händler) 2. Internetbasierte, individualisierte Präsentation von Daten Wie können Händler individuelle Angebote unterbreiten? (Der Kunde soll hierbei personalisierte Angebote erhalten.) Für einen Händler soll exemplarisch ein Shopsystem konzipiert und realisiert werden Entwicklungsumgebung Hardware: SUN-Workstations 8

19 1.2 Projektgruppenantrag DEC-Workstations PCs unter Windows 2000/XP und Linux Software: Mozilla Navigator Microsoft Explorer Java Developers Kit 1.4 (SDK) Eclipse IDE Oracle 9i, Oracle 9i Application Server CVS (Versionskontrolle) Rational Rose (UML) Perl (zur Realisierung von CGI-Skripten, soweit notwendig) L A TEX (für die Dokumentation) JUnit Berkeley DB Minimalergebnisse, Scheinkriterien Minimalergebnisse müssen erreicht werden (s.o.) Aktive Mitarbeit bei der Analyse, Konzeption und Implementierung Erfüllung übertragender Aufgaben Präsentation und Ausarbeitung von Seminarvorträgen Erstellung von Zwischen- und Endbericht sowie anfallenden Dokumentationen Meilensteinplanung Die folgende Darstellung (siehe Abbildung 1.1) zeigt die von den Projektgruppenmitgliedern festgelegten Meilensteine. Zu jedem Meilenstein existiert ein Start- und ein Enddatum. Aus diesen Daten ergibt sich die Bearbeitungsdauer eines Meilensteins in Wochen. Meilensteine, die miteinander durch eine Linie verbunden sind, werden als voneinander abhängige Meilensteine bezeichnet: der zeitlich vorangehende Meilenstein muss vor Beginn des verbundenen Meilensteins abgeschlossen sein. 9

20 1 Rahmenbedingungen Nr Meilenstein Start Ende Dauer Q4 02 Q1 03 Q2 03 Q3 03 Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep 1 Fertigstellung der Ausarbeitungen ,14w 2 Entwurf DB-Schemata ,29w 3 Test u. Dokumentation DB-Schemata ,86w 4 Erstellung Zwischenbericht ,43w 5 Fertigstellung Zwischenbericht ,29w 6 Anforderungsdefinitionen Gesamtszenario, Integration, Analyse ,57w Abbildung 1.1: Meilensteinplanung Fertigstellung der Ausarbeitungen Der eigentlichen Projektaufgabe ging die Seminarphase voran. Ergebnis der Seminarphase waren einerseits drei Seminartage mit Vorträgen und andererseits die Erstellung der zu den Vorträgen gehörigen Ausarbeitungen. Die Fertigstellung der Ausarbeitungen ist Ziel des ersten Meilensteins. Meilenstein 1: bis , Dauer: 13,14 Wochen. Entwurf DB-Schemata Parallel zu der Fertigstellung der Ausarbeitungen wird mit der Erstellung der DB-Schemata für Händler 1, Händler 2 und den Kartenanbieter begonnen. Meilenstein 2: bis , Dauer: 5,29 Wochen. Test und Dokumentation Nach Abschluss der Entwurferstellung müssen die Schemata getestet, dokumentiert und mit Testdaten gefüllt werden. Meilenstein 3: bis , Dauer: 7,86 Wochen. Erstellung Zwischenbericht Nachdem die für den Zwischenbericht notwendigen Meilensteine abgeschlossen sind, kann mit der Erstellung des Zwischenberichtes begonnen werden. Eine vorläufige Fassung soll zum Ende dieses Meilensteins fertig sein. Meilenstein 4: bis , Dauer: 8,43 Wochen. 10

21 1.3 Teilnehmer Fertigstellung Zwischenbericht Während dieses Meilensteins soll der Zwischenbericht auf Fehler und Vollständigkeit von den Projektgruppenmitglieder und den Veranstaltern geprüft werden. Eventuelle Fehler sollen bis Ende des Meilensteins ausgebessert und der Bericht damit abgeschlossen sein. Meilenstein 5: bis , Dauer: 4,29 Wochen. Anforderungsdefinitionen Gesamtszenario, Integration, Analyse Die Erarbeitung von drei Anforderungsdefinitionen für das Gesamtszenario, die Integration der Händler-Daten und das Analyseszenario ist Bestandteil dieses Meilensteins. Mit Erreichen des Meilensteins sollen drei fertige Dokumente vorliegen. Die Erstellung der Anforderungsdefinitionen erfolgt unabhängig vom Fortschritt des Zwischenberichts. Meilenstein 6: bis , Dauer: 4,57 Wochen. Soll-/Ist-Vergleich Die Meilensteinplanung in Abbildung 1.1 stellt die Sollplanung dar. Zum aktuellen Datum sind alle bis hierhin fälligen Meilensteine in der vorgegebenen Zeit erreicht worden Literatur Teilnehmer Die Projektgruppe setzt sich aus folgenden zwölf Studierenden zusammen: Tim Brüggemann Tina Goldau Christian Lüpkes Michael Onken 11

22 1 Rahmenbedingungen Matthias Pretzer Christian Reitenberger Carsten Saathoff Helge Saathoff Ralph Stuber Insa Stührenberg Oliver Wien Guido Zendel Veranstalter sind Prof. Dr. H.-J. Appelrath, Informatik-Assistent Ralf Krause und Dipl.-Informatiker Heiko Tapken. 12

23 2 Seminarphase Die Seminarphase der Projektgruppe diente dazu, den Kenntnisstand der Teilnehmer bezüglich der Thematik der Projektgruppe - Personalisierung internetbasierter Handelszenarien - zu verbessern und zu vereinheitlichen. Dieses Kapitel enthält Zusammenfassungen der einzelnen Vorträge. Die vollständigen Ausarbeitungen befinden sich im Teil B des Zwischenberichts. 2.1 Data Warehousing Die Datenmengen in den Betrieben wachsen stetig. Neben den operativen Datenbanksystemen, die dem operativen Tagesgeschäft dienen, haben sich Data Warehouses als Speicherkomponente etabliert. Ein Data Warehouse stellt eine integrierte und bereinigte Datenbank dar, die eine zeitliche Sicht auf die Daten ermöglicht. Um eine Datenhistorisierung zu gewährleisten, dürfen veränderte Datensätze nicht einfach überschrieben werden. Ein Data Warehouse stellt nur einen Bestandteil eines Data Warehouse Systems dar. Als Data Warehousing wird der gesamte Prozess der Datenbeschaffung, Integration und Analyse bezeichnet. Die wichtigsten Anwendungen sind die interaktive Datenanalyse OLAP sowie Data Mining. Konzeptionell liegt einem Data Warehouse das multidimensionale Datenmodell zugrunde. Dieses Modell verwendet die Datenunterteilung in Fakten und Dimensionen, die in ihrer Kombination einen Würfel bilden. Dimensionshierarchien schaffen einen Verdichtungsgrad, der für die Analyse angemessen ist. Für die Berücksichtigung temporaler Gesichtpunkte werden in einem Data Warehouse Zeitstempel verwendet. Diese können entweder auf Attribut- oder Tupelebene eingeführt werden. Für die Umsetzung des multidimensionalen Datenmodells existieren mehrere Möglichkeiten. Neben der direkten multidimensionalen Abbildung (MOLAP), ist auch eine relationale Umsetzung (ROLAP) 13

24 2 Seminarphase der multidimensionalen Konstrukte realisierbar. Wenn Detaildaten in Relationen gespeichert werden und gewisse Verdichtungen multidimensional gehalten werden, wird das hybride OLAP (HOLAP) verwendet. Insa Stührenberg 2.2 Datenanalyse allgemein Diese Ausarbeitung betrachtet das Feld der Datenanalyse Allgemein, deren Verfahren sich aus verschiedenen wissenschaftlichen Disziplinen zusammensetzen und mit deren Hilfe verstecktes Wissen aus (grossen) Datenbeständen gewonnen werden soll. Hierzu wird im Folgenden der Bereich der Datenanalyse abgesteckt und Analyseverfahren aus Statistik, künstlichen Neuronalen Netzen sowie OLAP beleuchtet. Ziel ist es, einen Überblick über die Werkzeuge zu bekommen, die hierzu zur Verfügung stehen. Michael Onken 2.3 Der KDD-Prozess In dieser Arbeit wird der Prozess des Knowledge Discovery in Databases (KDD) untersucht und anhand von Modellen beschrieben. Die Klassifizierung verschiedener Modellansätze wird mit einer Phaseneinteilung nach Gaul und Säuberlich gemacht, die Beschreibung der einzelnen Teilphasen erfolgt durch den Cross Industry Standard Process for Data Mining (CRISP-DM). Die übrigen hier betrachteten Modelle von Fayyad, Brachman und Anand, Hippner und Wilde und der Entwurf SEMMA von SAS weichen vom CRISP-DM-Ansatz nur in Teilbereichen ab. Krisnashwamy beleuchtet mit seinem Modell die Möglichkeiten des verteilten Data Mining, der Analysephase im KDD-Prozess. Die dargestellten Modelle für den Prozess finden sich in den KDD-Lösungen der führenden Softwareanbieter in diesem Sektor, IBM, SAS und SPSS in unterschiedlicher Form wieder. Guido Zendel 14

25 2.4 Data Preprocessing - Datenvorverarbeitungsschritte des Prozessmodelles 2.4 Data Preprocessing - Datenvorverarbeitungsschritte des Prozessmodelles Daten treten in der realen Welt oftmals unvollständig, mit Fehlern behaftet oder inkonsistent auf. Weiterhin erfordert die Integration mehrerer Datenbestände in einen gemeinsamen Datenbestand oftmals die Anpassung einzelner Daten, sei es, weil der Wertebereich differiert oder weil einfach syntaktische Unterschiede zwischen den zu vereinheitlichenden Datensätzen vorherrschen. Soll schließlich knowledge discovery auf Daten betrieben werden, so können heterogene Daten Konfusionen verursachen, die zu unzuverlässigen und ungenauen Ergebnissen führen können. Wächst die Datenmenge enorm an, so kann eine Datenreduktion sowohl die Geschwindigkeit einer Datenverarbeitung als auch deren Kosten senken. Die angesprochenen Fragestellungen lassen sich in gewissem Maße mit Hilfe von Datenvorverarbeitungsschritten durchführen. Es werden hierzu verschiedene Technologien und Vorgehensweisen vorgestellt. Ralph Stuber 2.5 Clustering und Klassifikation Im heutigen Informationszeitalter fallen immer schneller mehr und mehr Daten an, die von Unternehmen, wissenschaftlichen Vereinigungen oder anderen Interessenverbänden gespeichert werden. Diese Daten bergen ein enormes Wissenspotential, das es zu erschließen gilt. Hier setzen Knowledge Discovery in Databases und vor allem das Teilgebiet Data Mining an. Zwei wichtige Methoden des Data Mining Clustering und Klassifikation werden in dieser Arbeit vorgestellt. Zunächst werden die Zielsetzung und Grundlagen der beiden Verfahren umrissen, dann werden einige Ansätze, die diese Ziele erreichen sollen, beschrieben. Clusteringverfahren dienen dazu, Objekte der Eingabedaten zu Gruppen zusammenzufassen, um diese besser verstehen zu können. Es werden partitionierende Clusteringalgorithmen wie k-means, k-medoid und Dbscan, sowie hierarchische wie das Single-Link Verfahren und Optics vorgestellt. Klassifikationsverfahren dienen dagegen dazu, unbekannte Daten einer vorgegebenen Klasse zuzuordnen. Dabei lernt ein Klassifikator die 15

26 2 Seminarphase Zuordnung anhand bereits klassifizierter Trainingsdaten. Es werden Bayes-Klassifikatoren, Entscheidungsbäume und (k)-nächste-nachbarn-klassifikatoren vorgestellt. 2.6 Assoziationsanalyse und Konzeptbeschreibung Matthias Pretzer Wir leben im Informationszeitalter. Fortschritte in der Hard- und Softwaretechnologie haben es ermöglicht, daß heutzutage riesige Datenmengen erfaßt und gespeichert werden können. Das in diesen Datenbanken enthaltene Wissenpotential wird jedoch häufig nicht voll ausgeschöpft. Knowledge Discovery in Databases wurde entwickelt, um diesen Mangel zu beheben. In diesem Forschungsgebiet geht es um die automatisierte Entdeckung von Wissen in Datenbanken mit Hilfe von intelligenten Suchalgorithmen. Diese werden unter dem Begriff Data Mining Verfahren zusammengefaßt. Zwei dieser Verfahren, die Assoziationsanalyse und die Konzeptbeschreibung, sollen in dieser Arbeit vorgestellt werden. Der erste Teil dieser Arbeit befaßt sich mit der Assoziationsanalyse, die nach Regelmäßigkeiten in Datenmengen sucht und diese in Form von Assoziationsregeln darstellt. Für diese Aufgabe steht eine Vielzahl von Suchalgorithmen zur Verfügung, von denen der in dieser Arbeit erläuterte Apriori-Algorithmus der Grundlegendste ist. Je nach Anwendungszweck stehen außerdem mehr oder weniger komplexe Typen von Assoziationsregeln zur Verfügung, von denen ebenfalls einige eingeführt werden. Der zweite Teil der Arbeit behandelt das Thema Konzeptbeschreibung. Diese dient dazu, große und unübersichtliche Datenmengen auf ein für menschliche Benutzer verständliches Maß zusammenzufassen ohne dabei wichtige Informationen zu verlieren. In diesem Zusammenhang wird auf die Charakterisierung und den Klassenvergleich mittels Attributorientierter Induktion eingegangen. 2.7 Temporale Aspekte des Data Mining Helge Saathoff Die vorliegende Arbeit beschäftigt sich mit den temporalen Aspekten des Data Mining. Es werden wichtige Grundlagen zum Zeitbegriff 16

27 2.8 Geschäftsmodelle und seiner Verwendung gemacht sowie die Granularität von Zeitpunkt und Zeitraum bestimmt. Die Repräsentationsformen Temporale Datenbank und Zeitreihen sowie ihre Eigenschaften werden vorgestellt. Deutlich gemacht wird dabei der Nutzen von Transaktions- und Gültigkeitszeit in Form des bitemporalen Modells. Das Data Mining über einzelne Transaktionen hinaus birgt weitere Vorteile in so genannten Inter-Transaktionsmustern. Diese Muster decken Zusammenhänge auf, die ohne temporale Komponenten nicht realisiert werden würden. Zu den bekanntesten gehören dabei sequentielle Muster und zeitliche Assoziationsregeln. Die Analyse der zeitlichen Assoziationsregeln sowie zwei Algorithmen zur Entdeckung von sequentiellen Mustern werden zum Abschluss dieser Ausarbeitung ausführlich und mit Beispielen dargestellt. Oliver Wien 2.8 Geschäftsmodelle Unternehmen versuchen mit verschiedenen Geschäftsmodellen die Kundenbindung zu erhöhen. Eine Instrument hierfür sind Bonusprogramme, von denen es verschiedene Ausprägungen gibt, die beschrieben werden. An dem Programm teilnehmende Kunden können über Kundenkarten identifiziert werden und durch Einkäufe Punkte sammeln. Diese können gegen Prämien eingelöst werden. Unternehmen sammeln dabei Kundeninformationen. Die aufgenommenen Daten werden analysiert, um Kundenprofile zu erstellen, so dass eine gezieltere Werbung möglich wird. Es entstehen verschiedene Vor- und Nachteile für Unternehmen und Kunden, die näher erläutert werden. Kunden werden zum gläsernen Kunden. Bei Unternehmen besteht abgesehen von der Beschreibung des Bonusprogramms und der Beschreibung von Vorteilen für Kunden ein Informationsmangel. Ein Vergleich verschiedener Bonusprogramme zeigt Unterschiede und Gemeinsamkeiten auf. Insbesondere in Bezug auf die Datenweitergabe und genaue Datenverwendung ist eine Informationsbeschaffung durch mangelnde öffentliche Informationen erschwert. Tina Goldau 17

28 2 Seminarphase 2.9 Datenanalyse im Marketing In der vorliegenden Arbeit: Datenanalyse im Marketing wird in Anlehnung an Fayyad auf die Wissensentdeckung in Datenbanken eingegangen, wobei es um den Prozess der Identifikation von bisher nicht erkannten Mustern in großen Datenbeständen geht. Dieser Prozess wird im alggemeinen unter dem Begriff Data Mining zusammengefasst, wobei über 80 Prozent der schon produktiven Data Mining- Lösungen im Marketing eingesetzt werden. Es lassen sich dabei 4 Hauptaufgabenbereiche unterscheiden, auf die in dieser Arbeit näher eingegangen wird. Der erste Bereich der Klassifikation wird häufig im Bereich der Kreditwürdigkeitsprüfung eingesetzt. Beim zweiten Anwendungsbereich handelt es sich um das so genannte Clustering, wobei eine direkte Kundenansprache im Vordergrund steht. Als drittes Hauptaufgabengebiet ist die Assoziierung zu nennen, wobei das Hauptanwendungsfeld in der Sortimentsanalyse des Einzelhandels zu sehen ist. Abschließend wird noch die Prognose angesprochen, bei der es beispielsweise um die optimierte Werbeträgerplanung geht. Diese Aufzählung macht dabei deutlich, wie vielfältig Data Mining heutzutage speziell im Marketing eingesetzt wird, weshalb diese Thematik im Mittelpunkt dieser Arbeit steht. Tim Brüggemann 2.10 Verwendung personalisierter Daten im Web Gegenwärtig ist zu beobachten, dass die Nachfragebedürfnisse der Kunden schnell und oft wechseln. Die Anbieter, speziell die eines Online-Shops, stehen deshalb vor der Herausforderung, ihre Produkte und Dienstleistungen immer wieder auf die einzelnen Nachfrager personalisiert auszurichten. Online-Shops haben durch hohe Bequemlichkeit und zeitunabhängiges Einkaufen einen guten Stellenwert, jedoch fehlt den Kunden in vielen Fällen Kundenbetreuung und der persönliche Kontakt. Die Personalisierung gilt als probates Mittel, um die oben erwähnten Probleme zu lösen und die Beziehung zwischen Anbietern und Kunden zu fördern. Gleichzeitig wird die Personalisierung als Maßnahme gegen die wachsende Menge an Informationen zunehmend wichtiger, um die Informationen für die Kunden vorzufiltern. Personalisierung schafft Anbieterloyalität und Kundenbindung 18

29 2.11 Web Usage Mining und wird dadurch immer unverzichtbarer, speziell in Verbindung mit dem immer noch als anonym angesehenen Internet. Christian Reitenberger 2.11 Web Usage Mining Web Mining ist das Anwenden von Data Mining Methoden auf Daten, die im Internet zu finden sind bzw. täglich anfallen. Prinzipiell ist zwischen drei Arten von Daten zu unterscheiden. Dem Inhalt (content), der Struktur (structure) und den Nutzungsdaten (usage) von Websites. Diesen drei Gebieten widmen sich dementsprechend Web Content Mining, Web Structure Mining und Web Usage Mining. Letzteres ist Thema dieser Arbeit und es soll ein Überblick über den Prozess des Web Usage Mining im Allgemeinen gegeben werden. Dazu werden, nach einem kurzen Überblick über das Web Mining allgemein, zuerst einige grundlegende Begriffe erläutert und anschließend der im Web Usage Mining sehr wichtige Prozess der Daten Bereinigung besprochen. In Kapitel 12.4 werden 3 grundlegende Algorithmen kurz exemplarisch vorgestellt. Im Kapitel 12.5 werden die möglichen Methoden zur Auswertung der Mining Ergebnisse diskutiert und in der Zusammenfassung soll abschließend eine Bewertung der vorgestellten Methoden gegeben werden. Carsten Saathoff 2.12 Rechtliche und soziale Aspekte der Datenanalyse Dank Neuerungen in der Informationstechnologie wird die Verarbeitung und Speicherung von großen Datenmengen immer leistungsfähiger und dabei gleichzeitig kostengünstiger. Wurden früher in Unternehmen Geschäftsvorfälle noch mittels Quittungs- und Auftragsbuch oder Laufzettel bearbeitet, ist dies heutzutage fast vollständig durch elektronische Datenverarbeitung verdrängt worden. Der größte Vorteil von elektronischen Daten liegt darin, daß sie auf einfache Weise automatisch verarbeitet werden können. So können alle Daten eines Unternehmens zentral in einer großen Datenbank gespeichert und mittels Datenanalyse ausgewertet werden. 19

30 2 Seminarphase Analysen im Unternehmensumfeld werden häufig dazu verwendet, durch Auswertung der eigenen Produktionsdaten Produktionsabläufe zu optimieren. Den größten Vorteil von Datenanalysen erhoffen sich Unternehmen aber in der Individualisierung ihrer Kundenkontakte, indem Kundendaten analysiert und ausgewertet werden, dem sogenannten Customer Relationship Management. Hierbei kann es jedoch zu rechtlichen Problemen und sozialen Bedenken kommen, wenn die vorhandenen Daten mißbräuchlich verwendet werden, Stichwort Gläserner Kunde. Diese Probleme treten aber nicht nur im Bereich von Unternehmen auf, auch bei wissenschaftlichen Forschungen werden oft sensitive Daten verwendet, die besonders schutzwürdig sind, da sie einzelnen Personen zugeordnet werden können. Aber auch Unternehmen selbst können durch die fortschreitende Datenanalysetechnik geschädigt werden; nämlich dann, wenn Konkurrenten diese Verfahren einsetzen, um sich ein detailliertes Bild ihrer Mitbewerber zu machen. In dieser Ausarbeitung soll nach einer kurzen Begriffsbestimmung, die rechtliche Situation von Datenanalysen zum Kundenmanagement bzw. der Verarbeitung von personenbezogenen Daten allgemein vorgenommen werden. Dabei wird auch noch auf die besonderen Regelungen in der Forschung eingegangen. Danach werden Beispiele für einzelne Situationen sowohl für die Probleme des Datenschutzes bei Personen als auch von Unternehmen vorgestellt, an die sich Lösungsansätze im Unternehmensbereich sowie ebenfalls Verfahren zum Datenschutz bei Forschungsprojekten anschließen. Zum Schluß findet noch eine Einordung des Projetktes Personalisierung internetbasierter Handelsszenarien statt, in dessen Rahmen diese Ausarbeitung entstand. Abschließend wird noch ein persönlicher Ausblick auf die Praktiken im Customer Relationship Management gegeben. Christian Lüpkes 20

31 3 Dokumentationen Im Folgendem werden die Dokumentationen der Datenbankschemata des Händlers 1, Händerls 2 sowie des Kartenanbieters aufgeführt. In der Gruppe des Händlers 1 sind zu dieser Phase des Projekts Tim Brüggemann, Michael Onken, Carsten Saathoff und Oliver Wien. Die Gruppe des Händlers 2 besteht aus Tina Goldau, Christian Lüpkes, Ralph Stuber und Insa Stührenberg. Matthias Pretzer, Christian Reitenberger, Helge Saathoff und Guido Zendel befinden sich in der Gruppe des Kartenanbieters. 3.1 Händler Aufgabenbeschreibung Im Folgenden wird die dieser Dokumentation zugrunde liegende Aufgabe beschrieben Kurze Beschreibung des Händlers Bei Händler 1 handelt es sich um einen Online-Händlers, der seinen Kunden einen personalisierten Webauftritt bieten möchte. Da der Händler kein Ladengeschäft oder ähnliches besitzt, ist er dazu auf Spuren angewiesen, die seine Kunden über Besuche seiner Internetpräsenz eher unabsichtlich hinterlassen. Diese Daten fallen in Form von Daten an, die direkt mit einem Kunden verknüpft werden können oder anonyme Daten, die entstehen, wenn sich Besucher nicht über Cookies oder andere Authentisierungsverfahren anmelden. Hier spielt das Weblog eine besondere Rolle, das (beschränkt) Auskunft über die Verweildauer und die Wege geben kann, die Kunden über die Webseite nehmen. Ziel ist es nun, ein Datenbankschema zu entwickeln, das den Verkaufsansprüchen eines Shops genügt sowie genauso den Ansprüchen der betreibenden Firma gerecht wird, Analysen über das Kundenverhalten durchzuführen. 21

32 3 Dokumentationen Aufgaben Die Aufgabe ist es ein Datenbankschema für den oben beschriebenen Online-Händler zu modelieren. Dabei müssen alle Umstände berücksichtigt werden, die speziell den Händler im Internet betreffen. Ergebnis dieser Arbeit ist ein fertiges auf Oracle ausgeführtes DB-Schema, dessen Funktionsweise mit Testdaten kontrolliert wurde Vorgehensweise Zur Implementierung der gestellten Aufgaben wurde die folgende Vorgehensweise gewählt: Aufgabenanalyse mit Business- und Data-Understanding Entwurf unter Berücksichtigung temporaler Aspekte Überprüfung und Erweiterung Implementierung Verifikation mit Hilfe eines speziellen Skripts Erstellung dieser Dokumentation Die Phase der Aufgabenanalyse beinhaltet die Verdeutlichung der grundlegenden Geschäftsprozesse des Online-Händlers. Elementare Begriffe sind diskutiert und eindeutig bestimmt worden. Festgelegt wurde außerdem, welche Daten für den Händler und die zu erstellenden Analysen von Bedeutung sind. Es handelt sich hierbei um konzeptionelle Phase des Datenbankentwurfs. Temporalen Aspekte stellen im weiteren Vorgehen eine besondere Phase dar, weil sie im Projektgruppenkontext eine wichtige Rolle spielen. Für alle Entitäten muss deshalb überprüft werden, ob die Erweiterung um temporale Attribute sinnvoll ist. Ist dies der Fall, werden die jeweiligen Entitäten um Attribute wie Transaktionszeit und Gültigkeitszeit ergänzt. Für den Entwurf des Datenbankmodells wird auf die Software ERwin zurückgegriffen. 22

33 3.1 Händler 1 In der Phase der Überprüfung und Erweiterung sind in Rücksprache mit dem Auftraggeber, dem Projektgruppenveranstalter, Änderungen vorgenommen worden. Die Implementierungsphase umfasst die Erstellung des eigentlichen logischen und physischen Entwurfs. Als Verifikation wird die Überprüfung des logischen Schemas anhand von Testdaten verstanden. Zu diesem Zweck ist ein spezielles Skript erstellt worden, dass die anfangs leere Datenbank mit zufälligen, aber plausiblen Daten füllt. Die Dokumentation beschreibt das vorliegende Dokument gemeint, welches die Beschreibungen aller Entitäten, Attribute und Relationen enthält. Mit Hilfe dieser Dokumentation soll das Datenbankschema für Außenstehende zugänglich gemacht werden. Dies ermöglicht Erweiterungen, auch durch andere, zu einem späteren Zeitpunkt. 3-Ebenen-Modell Die Erstellung des Schemas folgt dem bekannten 3-Ebenen-Modell. Die erste Ebene ist der konzeptuelle Entwurf. Dieser enthält eine implementierungsunabhängige Modellierung des gesamten Schemas in einem systemunabhängigen Datenmodell 1. Als systemunabhängig wird das ER-Modell oder z.b. das relationale Modell bezeichnet. Für das Schema von Händler 1 wurde das ER-Modell angewandt. Der logische Entwurf stellt die zweite Ebene dar. Das logische Modell wurde in diesem Fall mit ERwin umgesetzt. Bei der Erstellung des logischen Modells wird das konzeptuelle Modell an das vorhandene DBMS angepasst. Trotzdem bleibt das logische Modell unabhängig von physischen Details 2. Ein weiterer wichtiger Schritt im Rahmen der Erstellung der logischen Modells ist die Optimierung. Abhängig von den Operationen, die auf den Daten ausgeführt werden sollen, muss das Schema optimiert werden. So gibt es Operationen, z.b. Joins, die relativ aufwendig für das jeweilige DBMS sind und die, sofern möglich vermieden werden sollten. Eine weitere Optimierung findet mit der Normalisierung der Daten statt. In der dritten Ebene, dem physischen Modell wird das logische Modell um die physischen 1 Heuer et al., Datenbanken kompakt, mitp Verlag, Atzeni et. al., Database Systems, McGraw-Hill,

34 3 Dokumentationen Details erweitert, das heißt um die Dateiorganisation und die Index- Erstellung. Diese Aufgaben werden in der Regel vom DBMS wahrgenommen. Als Ergebnis liegt dann ein physisches Schema vor, dass sich auf das physische Datenmodell (des jeweiligen DBMS) bezieht Aufgabenanalyse Im Rahmen des Business- und Data-Understanding ist folgendes festzuhalten: Der Online-Händler benötigt einen Shop, der es ermöglicht unterschiedliche Produkte in verschiedenen Kategorien zu verwalten. Ein jedes Produkt verfügt über verschiedene Attribute, die das Produkt beschreiben. Dazu gehört beispielsweise der Preis, aber auch multimediale Attribute werden berücksichtigt. Die Kategorien sollen einerseits die zugeordneten Produkte, andererseits aber auch mögliche Unterkategorien enthalten. Jedem Produkt soll ein Hersteller zugewiesen werden, damit später Analysen in Abhängigkeit des Herstellers vorgenommen werden können. Die angesprochenen Produkte werden beim Kaufprozess in einem virtuellen Warenkorb abgelegt. Für diesen Warenkorb müssen entsprechende Relationen und Entitäten vorgehalten werden. Diese Warenkörbe sollen über den eigentlichen Bestellvorgang hinaus gespeichert bleiben und können dann vom Besucher des Shops erneut geladen werden. Aus Besuchern werden mit Abschluss einer Transaktion Kunden. Den einzelnen Kunden werden bestimmte Profile zugeordnet, welches in Abhängigkeit von den gekauften Produkten geschieht. Jedem Kunden stehen des weiteren verschiedene Zahlungsarten zur Verfügung, mit denen die gewünschten Produkte bezahlt werden können. Auf Wunsch des Kunden können unterschiedliche Rechnungs- und Lieferadresse gespeichert werden, die je Bestellvorgang neu ausgewählt werden können. Diese Informationen werden jeweils im Rahmen der Bestellung erfasst. Das besondere am Onlineshop ist das Vorhandensein eines sogenannten Weblogs. In einem Weblog werden alle Aktivitäten des Besuchers protokolliert. Das Weblog enthält Sessionids, Cookies und Referrer. In der Anwendung lassen sich drei Fälle unterscheiden: Der Besucher ist völlig anonym auf der Seite, eine Zuordnung zu einem speziellen Kunden ist nicht möglich. Ein anonymer Kunde bestellt am Ende etwas; dazu muss er sich in den Shop einloggen bzw. sich anmelden. Dadurch können 24

35 3.1 Händler 1 die Einträge des anonymen Kunden im Weblog im Nachhinein einem Kunden zugeordnet werden. Der Kunde logged sich gleich zu Anfang auf der Seite ein oder schickt einen identifizierenden Cookie mit, so kann gleich zu Anfang festgehalten werden, welche Weblogeinträge zu welchem Kunden gehören. In den letzten beiden Fällen ist es vorgesehen, eine Sitzungs-ID und eine Kunden-ID im Zusammenhang in der Datenbank speichern, um nachträglich Kundenzuordnungen im Weblog durchführen können Entwurf unter Berücksichtigung temporaler Aspekte Zur übersichtlicheren Darstellung wurde der Entwurf in so genannte Subject Areas eingeteilt. Unter einer Subject Area versteht man die Darstellung ausgewählter Teilbereiche des ER-Schemas. Die Areas lauten wie folgt: Bestellung Die Subject Area Bestellung enthält alle Entitäten im Zusammenhang mit der Bestellung. Dazu gehören die Zahlungsarten, sowie die jeweiligen Adressen des Kunden. Hersteller Die Subject Area Hersteller enthält ausschließlich die Entität des Herstellers Kunde Die Subject Area Kunde enthält alle Entitäten zur Kundenverwaltung, einschließlich der Adressen und der Zahlungsarten des Kunden. Produkt Die Subject Area Produkt enthält alle produktbeschreibenden Entitäten, sowie die Entitäten, die zur Einordnung in Kategorien nötig sind. Sitzung Die Subject Area Sitzung enthält alle Entitäten, die notwendig sind, um eine Verbindung zwischen den Websitzungen und den Kunden herzustellen. 25

36 3 Dokumentationen Warenkorb Die Subject Area Warenkorb enthält alle Entitäten, die die Warenkörbe des Kunden anhand von Kunden und Produkten beschreibt. Im Folgenden werden die einzelnen Areas mit ihren Entitäten sowie die Attribute und ihre temporalen Aspekte vorgestellt. Zu den Attributen wird ebenfalls angezeigt, welcher Wertebereich für sie erlaubt ist. Durch die Einteilung in Subjectareas kommt es vor, dass einzelne Entitäten in mehreren Areas dargestellt werden. Hierbei handelt es sich immer um ein und die selbe Area. Generell haben alle Entitäten des Datenbankmodells einen zweiteiligen Primärschlüssel, der aus einer eindeutigen, entitätenabhängigen ID und einer SID bestehen. Verschiedene Objektversionen werden dabei anhand ihrer unterschiedlichen sequentiellen ID (SID) unterschieden. Bei jeder Änderung von Attributwerten erhöht sich dabei die SID um einen Wert. Die temporalen Aspekte der unterschiedlichen Entitäten werden jeweils anhand der Attribute tza, tze, gza und gze gekennzeichnet. Bei der Erstellung eines Tupels bildet tza die zur Erstellungszeit aktuelle Uhrzeit ab. Der Wert (Uhrzeit) der tze kennzeichnet das Ende dieser Transaktion. Eine Transaktion ist dann zu Ende, wenn sie gelöscht wurde, oder eine neuere Version des betrachteten Objektes existiert. In jeder Entität gibt es des weiteren einen Wert für GZA und GZE. GZA steht für den Beginn und GZE für das Ende des Gültigkeitzeitraums. So können unterschiedliche Objektversionen verwaltet werden. In Hinblick auf die Produkte kann dies z.b. sinnvoll sein, um Preisreduzierungen in Form eines Sonderangebots zu berücksichtigen. Ein Produkt würde dann mit einem reduzierten Preis und dem Zeitraum zu dem dieser Preis gilt in der Datenbank gespeichert werden Subject Area Bestellung Die Subject Area Bestellung enthält folgende Entitäten: Warenkorb Gutschein Konto Kreditkarte 26