Dokumentation Händler 1

Transkript

1 Dokumentation Händler 1 Tim Brüggemann, Michael Onken, Carsten Saathoff, Oliver Wien 16. Mai

2 Inhaltsverzeichnis 1 Aufgabenbeschreibung Kurze Beschreibung des Händlers Aufgaben Vorgehensweise 4 3 Aufgabenanalyse 7 4 Entwurf unter Berücksichtigung temporaler Aspekte Subject Area Bestellung Erklärung der Entitäten/Attribute Schlüsselbeziehungen Grafik der Subject Area Bestellung Subject Area Hersteller Erklärung der Entitäten/Attribute Schlüsselbeziehungen Grafik der Subject Area Hersteller Subject Area Kunde Erklärung der Entitäten/Attribute Schlüsselbeziehungen Grafik der Subject Area Kunde Subject Area Produkte Erklärung der Entitäten/Attribute Schlüsselbeziehungen Grafik der Subject Area Produkte Subject Area Sitzung Erklärung der Entitäten/Attribute Schlüsselbeziehungen Grafik der Subject Area Sitzung Subject Area Warenkörbe Erklärung der Entitäten/Attribute Schlüsselbeziehungen Grafik der Subject Area Warenkörbe

3 5 Überprüfung und Erweiterung 53 6 Implementierung 54 7 Plausibilitätsprüfung 54 8 Dokumentation 56 9 Meilensteine Zusammenfassung 58 3

4 1 Aufgabenbeschreibung Im Folgenden wird die dieser Dokumentation zugrunde liegende Aufgabe beschrieben. 1.1 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. 1.2 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. 2 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 4

5 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. 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 Daten- 5

6 modell 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 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. 1 Heuer et al., Datenbanken kompakt, mitp Verlag, Atzeni et. al., Database Systems, McGraw-Hill,

7 3 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 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. 7

8 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. 8

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

10 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. 4.1 Subject Area Bestellung Die Subject Area Bestellung enthält folgende Entitäten: Warenkorb Gutschein Konto Kreditkarte Adresse Bestellung Zahlung Kunde Erklärung der Entitäten/Attribute Warenkorb Die Entität Warenkorb dient im Gesamtszenario dazu, die zu bestellenden Artikel der 10

11 Kunden aufzuführen. Das Attribut wk id ist der eindeutige Primärschlüssel der Entität Warenkorb. Die Attribute knd id und knd sid ordnen jedem Warenkorb den zugehörigen Kunden zu. Attributname Wertebereich Nullwerte erlauben Kommentar wk id INTEGER nein PK wk sid INTEGER nein PK knd id INTEGER ja FK knd sid INTEGER nein FK Gutschein Die Entität Gutschein enthält alle Information zu der Zahlungsmöglichkeit mit einem Gutschein. Das Attribut g id ist der eindeutige Primärschlüssel der Entität Gutschein. Jeder Gutschein besitzt einen eindeutigen Code, wodurch der Gutschein identifiziert werden kann. Der Wert legt den Euro-Betrag fest, über den der Gutschein ausgestellt worden ist. Das Attribut Gueltigkeit legt die Zeitdauer der Gueltigkeit des Gutscheines fest. Die Attribute knd id und knd sid ordnen jedem Gutschein den zugehörigen Kunden zu. 11

12 Attributname Wertebereich Nullwerte erlauben Kommentar g id INTEGER nein PK g sid INTEGER nein PK code VARCHAR(20) nein wert INTEGER nein gueltigkeit DATE nein knd id INTEGER nein FK knd sid INTEGER nein FK Konto Die Entität Konto enthält alle Information zu der Zahlungsmöglichkeit per Kontoverbindung. Das Attribut ko id ist der eindeutige Primärschlüssel der Entität Konto. Das Attribut Institut enthält das jeweilige Institut, bei dem der Kunde sein Konto eingerichtet hat. Das Attribut blz legt die Bankleitzahl fest, durch die das jeweilige Bankinstitut identifiziert wird. Das Attribut kto legt die Kontonummer des Kunden fest. Das Attribut Inhaber ordnet jedem Konto den Inhaber zu. 12

13 Attributname Wertebereich Nullwerte erlauben Kommentar ko id INTEGER nein PK ko sid INTEGER nein PK institut VARCHAR2(255) nein blz INTEGER nein kto INTEGER nein inhaber VARCHAR2(255) nein Kreditkarte Die Entität Kreditkarte enthält alle Information zu der Zahlungsmöglichkeit mit einer Kreditkarte. Das Attribut kr id ist der eindeutige Primärschlüssel der Entität Kreditkarte. Das Attribut Kreditkarte legt das Institut fest, bei dem der jeweilige Kunde die Kreditkarte besitzt. Das Attribut nummer identifiziert eine Kreditkarte eindeutig. Das Attribut gueltigkeit legt die Gültigkeitsdauer der Kreditkarte fest. Das Attribut Inhaber ordnet der Kreditkarte einen Inhaber zu. Attributname Wertebereich Nullwerte erlauben Kommentar kr id INTEGER nein PK kr sid INTEGER nein PK institut VARCHAR2(255) nein nummer INTEGER nein gueltigkeit DATE nein inhaber VARCHAR2(255) nein 13

14 Adresse Die Entität Adresse enthält alle Information eines Kunden, die für eine Warenlieferung nötig sind. Das Attribut a id ist der eindeutige Primärschlüssel der Entität Adresse. Die Attribute Name und Vorname legen den Namen fest, an den das Produkt oder die Rechnung ausgelifert wird. Das Attribut Strasse legt die Strasse fest, an die das bestellte Produkt oder die entsprechende Rechnung geliefert wird. Das Attribut Hausnummer identifiziert ein Haus innerhalb einer Strasse. Die Attribute plz und ort identifizieren über die Postleitzahl und den Ortsnamen die Stadt oder den Ort der Liefer- oder Rechnungsadresse. Das Attribut Land gibt das jeweilige Land der Liefer- bzw. Rechnungsadresse an. Das Attrbut telefon legt, wenn vorhanden, die Telefonnummer der zugehörigen Adresse fest, während das Attribut telefax die zugehörige Telefaxnummer zuordnet. Attributname Wertebereich Nullwerte erlauben Kommentar a id INTEGER nein PK a sid INTEGER nein PK name VARCHAR(40) ja vorname VARCHAR(30) ja strasse VARCHAR(60) ja hausnummer VARCHAR(10) ja plz VARCHAR(10) ja ort VARCHAR(60) ja land VARCHAR(60) ja telefon VARCHAR(30) ja telefax VARCHAR(30) ja Bestellung 14

15 Die Entität Bestellung verbindet die Informationen des Warenkorbes mit den Adressen des Kunden bei der Bestellabwicklung. Das Attribut b id ist der eindeutige Primärschlüssel der Entität Bestellung. Die Attribute wk id und wk sid ordnen jeder Bestellung den zugehörigen Watenkorb zu. Die beiden Attribute bezüglich der Rechnungsadresse (rechnungsadresse id und rechnungsadresse sid) ordnen jeder Bestellung die Adresse zu, an die die Rechnung geschickt wird. Die beiden Attribute bezüglich der Lieferadresse (lieferadresse id und lieferadresse sid) ordnen jeder Bestellung die Adresse zu, an die die Ware geliefert wird. Rechnungsadresse und Lieferadresse müssen dabei nicht identisch sein. Attributname Wertebereich Nullwerte erlauben Kommentar b id INTEGER nein PK b sid INTEGER nein PK wk id INTEGER nein FK wk sid INTEGER nein FK rechnungsadresse id INTEGER nein FK rechnungsadresse sid INTEGER nein FK lieferadresse id INTEGER nein FK lieferadresse sid INTEGER nein FK Zahlung Die Entität Zahlung enthält für jede Bestellung den zugehörigen Zahlungstyp. (Konto, Kreditkarte oder Gutschein) Das Attribut za id ist der eindeutige Primärschlüssel der Entität Zahlung. Die Attribute b id und b sid ordnen jeder Zahlung die jeweilige Bestellung zu. Das Attribut typ legt die Zahlungsart fest. Möglich sind in diesem Szenario die Zahlungsarten per Konto, per Gutschein und per Zahlung. Das Attribut betrag legt die Höhe der jeweiligen Zahlung 15

16 fest. Attributname Wertebereich Nullwerte erlauben Kommentar za id INTEGER nein PK za sid INTEGER nein PK z sid INTEGER nein FK b id INTEGER nein FK b sid INTEGER nein FK typ INTEGER nein betrag INTEGER ja Kunde Die Entität Kunde enthält die für den Onlineshop relevanten Kundendaten. Das Attribut knd id ist der eindeutige Primärschlüssel der Entität Kunde. Die Attribute name und vorname legen den Kundennamen fest. Das Attribut gebdatum legt das Geburtsdatum des jeweiligen Kunden fest. Das Attribut geschlecht legt das Geschlecht des Kunden fest und kann die Werte männlich oder weiblich annehmen. Das Attribut beschreibt die adresse des Kunden. Jedem Kunden wird durch das Attribut kennwort zusätzlich ein Kennwort zugeordnet, welches zum Einloggen auf der Shopoberfläche dient. 16

17 Attributname Wertebereich Nullwerte erlauben Kommentar knd id INTEGER nein PK knd sid INTEGER nein PK name VARCHAR(40) nein vorname VARCHAR(30) nein gebdatum DATE nein geschlecht INTEGER nein VARCHAR(255) nein kennwort VARCHAR(255) nein Schlüsselbeziehungen Schlüsselbeziehungen in der Subject Area Bestellung An dieser Stelle werden hier und bei den folgenden Subject Areas die Beziehungen zwischen den Attributen der jeweiligen Subject Area beschrieben. Bestellung Warenkorb Die Entität Bestellung verfügt über eine Fremdschlüsselbeziehung zur Entität Warenkorb. Die Bestellung-Warenkorb-Beziehung ist eine n:1-beziehung. Zu jeder Bestellung gehört ein Warenkorb, der mit wk id referenziert wird (Bestellung.wk id Warenkorb.wk id, Bestellung.wk sid Warenkorb.wk sid). Eine weitere Beziehung besteht zu der Entität Zahlung. Eine Bestellung kann mehrere Zahlungen zugeordnet haben. Dies macht insofern Sinn, da eine Bestellung mit unterschiedlichen Zahlungsmitteln bezahlt werden kann (s.u.). Adresse Bestellung Die Entität Adresse verfügt über 1:n-Beziehungen zu Bestellung (Adresse.a id Bestellung.rechnungsadresse id, Adresse.a sid Bestellung.rechnungsadresse sid und Adres- 17

18 se.a id Bestellung.lieferadresse id, Adresse.a sid Bestellung.lieferadresse sid). Jede Adresse kann mit einer oder mehreren Bestellungen in Verbindung gebracht werden. Eine Adresse kann also auch zweimal mit einer Bestellung benutzt werden und zwar als Rechnungsadresse und als Lieferadresse. Warenkorb Kunde Ein Warenkorb hat eine n:1-beziehung mit der Entität Kunde. Das heißt zu jedem Warenkorb kann mittels des Attributs knd id genau ein Kunde zugeordnet werden (Kunde.knd id Warenkorb.knd id, Kunde.knd sid Warenkorb.knd sid). Ein Kunde kann allerdings mehrere Warenkörbe haben. Kunde Kunde Die Entität Kunde hat eine n:m Beziehung mit Konto und Kreditkarte. Diese Beziehungen werden mit Kunde Konto bzw. Kunde Kreditkarte aufgelöst (Kunde.knd id Kunde Konto.knd id, Kunden.knd sid Kunde Konto.knd sid und Kunde Konto.ko id Konto.ko id, Kunde Konto.ko sid Konto.ko sid bzw. Kunde.knd id Kunde Kreditkarte.knd id, Kunden.knd sid Kunde Kreditkarte.knd sid und Kunde Kreditkarte.kr id Kreditkarte.kr id, Kunde Kreditkarte.kr sid Kreditkarte.kr sid). Jeder Kunde kann mehrere Kontoverbindungen und Kreditkarten verwalten. Außerdem kann ein Kunde mehrere Gutscheine erwerben. Hier gibt es also eine 1:n-Beziehung zwischen den Entitäten Kunde und Gutschein. Zahlung Konto, Kreditkarte, Gutschein Die Entität Zahlung hat eine n:1 Beziehung zu Konto. Jede Zahlung benötigt ein Konto. Mit einem Konto können mehrere Zahlungen vorgenommen werden. Das gleiche gilt für Beziehungen zwischen Zahlung und Kreditkarte bzw. Gutschein. Gutschein, Konto, Kreditkarten Die Beziehungen dieser Entitäten wurden im vorangegangenen Text bereits beschrieben. 18

19 4.1.3 Grafik der Subject Area Bestellung Abbildung 1: Subject Area Bestellung 19

20 4.2 Subject Area Hersteller Die Subject Area Hersteller enthält die Entität: Hersteller Erklärung der Entitäten/Attribute Hersteller Die Entität Hersteller enthält alle nötigen Informationen, die ein Onlinehändler bezüglich der Lieferanten benötigt. Das Attribut h id ist der eindeutige Primärschlüssel der Entität Hersteller. Die Attribute name und vorname legen den vollständigen Namen des Herstellers fest. Das Attribut ap name legt den Namen des Ansprechpartners des Herstellers fest. Das Attribut ap geschlecht legt das Geschlecht des Herstelleransprechpartners fest. Das Attribut legt die Adresse des Herstellers fest. Das Attribut Strasse legt die Strasse fest, an der sich der Hersteller befindet. Das Attribut Hausnummer identifiziert das Herstelellergebäude innerhalb einer Strasse. Die Attribute plz und ort identifizieren über die Postleitzahl und den Ortsnamen die Stadt oder den Ort des Herstellers. Das Attribut Land gibt das jeweilige Land des Herstellers an. Das Attrbut telefon legt, wenn vorhanden, die Telefonnummer des Herstellers fest, während das Attribut telefax die zugehörige Telefaxnummer zuordnet. Das Attribut url legt die Internetadresse des Herstellers fest. 20

21 Attributname Wertebereich Nullwerte erlauben Kommentar h id INTEGER nein PK h sid INTEGER nein PK name VARCHAR2(100) nein ap vorname VARCHAR2(30) ja ap name VARCHAR2(40) ja ap geschlecht VARCHAR2(20) ja VARCHAR2(255) ja strasse VARCHAR2(60) ja hausnummer VARCHAR2(18) ja plz VARCHAR2(20) ja ort VARCHAR2(60) ja land VARCHAR2(60) ja telefon VARCHAR2(30) ja telefax VARCHAR2(30) ja url VARCHAR2(255) ja Schlüsselbeziehungen Schlüsselbeziehungen in der Subject Area Hersteller In dieser Area gibt es keine Beziehungen. 21

22 4.2.3 Grafik der Subject Area Hersteller Abbildung 2: Subject Area Hersteller 22

23 4.3 Subject Area Kunde Die Subject Area Kunde enthält die Entitäten: Kunde Gutschein Konto Kreditkarte Adresse Profil Kunde Profil Adresse Kunde Kunde Konto Kunde Kreditkarte Erklärung der Entitäten/Attribute Kunde Die Entität Kunde enthält die für den Onlineshop relevanten Kundendaten. Das Attribut knd id ist der eindeutige Primärschlüssel der Entität Kunde. Die Attribute name und vorname legen den Kundennamen fest. Das Attribut gebdatum legt das Geburtsdatum des jeweiligen Kunden fest. Das Attribut geschlecht legt das Geschlecht des Kunden fest und kann die Werte männlich oder weiblich annehmen. Das Attribut beschreibt die adresse des Kunden. Jedem Kunden wird durch das Attribut kennwort zusätzlich ein Kennwort zugeordnet, welches zum Einloggen auf der Shopoberfläche dient. 23

24 Attributname Wertebereich Nullwerte erlauben Kommentar knd id INTEGER nein PK knd sid INTEGER nein PK name VARCHAR(40) nein vorname VARCHAR(30) nein gebdatum DATE nein geschlecht INTEGER nein VARCHAR(255) nein kennwort VARCHAR(255) nein Gutschein Die Entität Gutschein enthält alle Information zu der Zahlungsmöglichkeit mit einem Gutschein. Das Attribut g id ist der eindeutige Primärschlüssel der Entität Gutschein. Jeder Gutschein besitzt einen eindeutigen Code, wodurch der Gutschein identifiziert werden kann. Der Wert legt den Euro-Betrag fest, über den der Gutschein ausgestellt worden ist. Das Attribut gueltigkeit legt die Zeitdauer der Gueltigkeit des Gutscheines fest. Die Attribute knd id und knd sid ordnen jedem Gutschein den zugehörigen Kunden zu. 24

25 Attributname Wertebereich Nullwerte erlauben Kommentar g id INTEGER nein PK g sid INTEGER nein PK code VARCHAR(20) nein wert INTEGER nein gueltigkeit DATE nein knd id INTEGER nein FK knd sid INTEGER nein FK Konto Die Entität Konto enthält alle Information zu der Zahlungsmöglichkeit per Bankverbindung. Das Attribut ko id ist der eindeutige Primärschlüssel der Entität Konto. Das Attribut Institut enthält das jeweilige Institut, bei dem der Kunde sein Konto eingerichtet hat. Das Attribut blz legt die Bankleitzahl fest, durch die das jeweilige Bankinstitut identifiziert wird. Das Attribut kto legt die Kontonummer des Kunden fest. Das Attribut Inhaber ordnet jedem Konto den Inhaber zu. 25

26 Attributname Wertebereich Nullwerte erlauben Kommentar ko id INTEGER nein PK ko sid INTEGER nein PK institut VARCHAR2(255) nein blz INTEGER nein kto INTEGER nein inhaber VARCHAR2(255) nein tze DATE nein Kreditkarte Die Entität Kreditkarte enthält alle Information zu der Zahlungsmöglichkeit per Kreditkarte. Das Attribut kr id ist der eindeutige Primärschlüssel der Entität Kreditkarte. Das Attribut institut legt das Institut fest, bei dem der jeweilige Kunde die Kreditkarte besitzt. Das Attribut nummer identifiziert eine Kreditkarte eindeutig. Das Attribut gueltigkeit legt die Gültigkeitsdauer der Kreditkarte fest. Das Attribut Inhaber ordnet der Kreditkarte einen Inhaber zu. 26

27 Attributname Wertebereich Nullwerte erlauben Kommentar kr id INTEGER nein PK kr sid INTEGER nein PK institut VARCHAR2(255) nein nummer INTEGER nein gueltigkeit DATE nein inhaber VARCHAR2(255) nein Adresse Die Entität Adresse enthält alle Information eines Kunden, die für eine Warenlieferung nötig sind. Das Attribut a id ist der eindeutige Primärschlüssel der Entität Adresse. Die Attribute Name und Vorname legen den Namen fest, an den das Produkt oder die Rechnung ausgelifert wird. Das Attribut strasse legt die Strasse fest, an die das bestellte Produkt oder die entsprechende Rechnung geliefert wird. Das Attribut Hausnummer identifiziert ein Haus innerhalb einer Strasse. Die Attribute plz und ort identifizieren über die Postleitzahl und den Ortsnamen die Stadt oder den Ort der Liefer- oder Rechnungsadresse. Das Attribut Land gibt das jeweilige Land der Liefer- bzw. Rechnungsadresse an. Das Attrbut telefon legt, wenn vorhanden, die Telefonnummer der zugehörigen Adresse fest, während das Attribut telefax die zugehörige Telefaxnummer zuordnet. 27

28 Attributname Wertebereich Nullwerte erlauben Kommentar a id INTEGER nein PK a sid INTEGER nein PK name VARCHAR(40) ja vorname VARCHAR(30) ja strasse VARCHAR(60) ja hausnummer VARCHAR(10) ja plz VARCHAR(10) ja ort VARCHAR(60) ja land VARCHAR(60) ja telefon VARCHAR(30) ja telefax VARCHAR(30) ja Profil Die Entität Profil enthält Informationen zu verschiedenen Profiltypen, die den Kunden zugeordnet werden. Das Attribut pr id ist der eindeutige Primärschlüssel der Entität Profil. Das Attribut typ beschreibt verschiedene Profiltypen. Das Attribut name beschreibt den Namen des jeweiligen Profils. Das Attribut beschreibung dient der näheren Beschreibung des Profils. 28

29 Attributname Wertebereich Nullwerte erlauben Kommentar pr id INTEGER nein PK pr sid INTEGER nein PK typ INTEGER nein name VARCHAR(255) nein beschreibung VARCHAR(255) ja Kunde Profil Die Entität Kunde Profil ordnet jedem Kunden verschiedene Profile zu. Attributname Wertebereich Nullwerte erlauben Kommentar knd id INTEGER nein FK knd sid INTEGER nein FK pr id INTEGER nein FK pr sid INTEGER nein FK Adresse Kunde Die Entität Adresse Kunde ordnet jedem Kunden eine Adresse zu. Das Attribut typ legt fest, ob die Liefer- oder die Rechnungsadresse gemeint ist. 29

30 Attributname Wertebereich Nullwerte erlauben Kommentar knd id INTEGER nein FK knd sid INTEGER nein FK a id INTEGER nein FK a sid INTEGER nein FK typ INTEGER nein ak sid INTEGER nein PK Kunde Konto Die Entität Kunde Konto ordnet jedem Kunden ein Konto zu. Attributname Wertebereich Nullwerte erlauben Kommentar knd id INTEGER nein FK knd sid INTEGER nein FK ko id INTEGER nein FK ko sid INTEGER nein FK Kunde Kreditkarte Die Entität Kunde Kreditkarte ordnet einem Kunden seine Kreditkarte zu. 30

31 Attributname Wertebereich Nullwerte erlauben Kommentar knd id INTEGER nein FK knd sid INTEGER nein FK kr id INTEGER nein FK kr sid INTEGER nein FK Schlüsselbeziehungen Schlüsselbeziehungen in der Subject Area Kunde Kunde Adresse Die Entität Kunde hat eine 1:n-Beziehung mit der Entität Adresse Kunde (Kunde.knd id Adresse Kunde.knd id, Kunde.knd sid Adresse Kunde.knd sid), die wiederum eine n:1-beziehung mit Adresse (Adresse Kunde.a id Adresse.a id, Adresse Kunde.a sid Adresse.a sid) hat. So kann einem Kunden eine beliebige Anzahl von Adressen zugeordnet werden. In der Entität Adresse Kunde wird dabei gespeichert, um was für einen Typ von Adresse (Rechnungs-, oder Lieferadresse) es sich handelt. Kreditkarte, Konto Die Beziehungen zu Kreditkarte und Konto wurden bereits beschrieben. Die Entitäten Kunde Kreditkarte und Kunde Konto stellen eine Auflösung der n:m-beziehungen zwischen Kunde und Konto bzw. Kunde und Kreditkarte dar. Kunde Profil Die Beziehung Kunde-Kunde Profil (Kunde.knd id Kunde Profil.knd id, Kunde.knd sid Kunde Profil.knd sid) und Kunde Profil-Profil (Kunde Profil.pr id Profil.pr id, Kunde Profil.pr sid Profil.pr sid) stellt eine Auflösung der n:m-beziehung Kunde- Profil dar. Dem Kunden können so beliebig viele Profile zugeordnet werden. Ein Profil 31

32 kann ebenfalls beliebig vielen Kunden zugeordnet werden. Kunden Gutschein Die 1:n-Beziehung Kunde-Gutschein (Kunde.knd id Gutschein.knd id, Kunde.knd sid Gutschein.knd sid) ermöglicht, dass ein Kunde beliebig viele Gutscheine kaufen kann. Jeder Gutschein wiederum kann aber nur von einem Kunden gekauft werden Grafik der Subject Area Kunde Abbildung 3: Subject Area Kunde 32

33 4.4 Subject Area Produkte Die Subject Area Produkte enthält folgende Entitäten: Hersteller Attribut Produkt Kategorie Kategorie Produkttyp Text Attribut String Attribut Number Attribut MM Attribut MM Typ Produkt Profil Produkttyp Attribut Produkt Profil Erklärung der Entitäten/Attribute Hersteller Die Entität Hersteller enthält alle nötigen Informationen, die ein Onlinehändler bezüglich der Lieferanten benötigt. Das Attribut h id ist der eindeutige Primärschlüssel der Entität Hersteller. Die Attribute name und vorname legen den vollständigen Namen des Herstellers fest. Das Attribut ap name legt den Namen des Ansprechpartners des Herstellers fest. Das Attribut ap geschlecht legt das Geschlecht des Herstelleransprechpartners fest. Das Attribut 33

34 legt die Adresse des Herstellers fest. Das Attribut Strasse legt die Strasse fest, an der sich der Hersteller befindet. Das Attribut Hausnummer identifiziert das Herstelellergebäude innerhalb einer Strasse. Die Attribute plz und ort identifizieren über die Postleitzahl und den Ortsnamen die Stadt oder den Ort des Herstellers. Das Attribut Land gibt das jeweilige Land des Herstellers an. Das Attrbut telefon legt, wenn vorhanden, die Telefonnummer des Herstellers fest, während das Attribut telefax die zugehörige Telefaxnummer zuordnet. Das Attribut url legt die Internetadresse des Herstellers fest. Attributname Wertebereich Nullwerte erlauben Kommentar h id INTEGER nein PK h sid INTEGER nein PK name VARCHAR2(100) nein ap vorname VARCHAR2(30) ja ap name VARCHAR2(40) ja ap geschlecht VARCHAR2(20) ja VARCHAR2(255) ja strasse VARCHAR2(60) ja hausnummer VARCHAR2(18) ja plz VARCHAR2(20) ja ort VARCHAR2(60) ja land VARCHAR2(60) ja telefon VARCHAR2(30) ja telefax VARCHAR2(30) ja url VARCHAR2(255) ja Attribut Die Entität Attribut legt den produktabhängigen Attributtyp fest. 34

35 Das Attribut a id ist der eindeutige Primärschlüssel der Entität Attribut. Das Attribut name ordnet dem Attribut einen Namen zu. Mit Hilfe des Attributs beschreibung lässt sich das Attribut näher beschreiben. Attributname Wertebereich Nullwerte erlauben Kommentar a id INTEGER nein PK a sid INTEGER nein PK name VARCHAR2(60) ja beschreibung VARCHAR2(255) ja typ INTEGER ja tze DATE nein Produkt Kategorie Die Entität Produkt Kategorie ordnet jedes Produkt in eine spezielle Kategorie ein. Attributname Wertebereich Nullwerte erlauben Kommentar p id INTEGER nein FK p sid INTEGER nein FK k id INTEGER nein FK k sid INTEGER nein FK Kategorie 35

36 Die Entität Kategorie enthält Informationen zu verschiedenen Kategorien, denen die Produkte zugeordnet werden. Das Attribut k id ist der eindeutige Primärschlüssel der Entität Attribut. Mit Hilfe der Attribute parent id und parent sid lassen sich die Produkte rekursiv in verschiedene Kategorien einbauen. Es existieren dabei also Ober- und Unterkategorien. Das Attribut Name ordent jeder Kategorie einen Namen zu. Mit Hilfe des Attributs beschreibung lässt sich die Kategorie näher beschreiben. Das Attribut bild ordnet jeder Kategorie ein Bild zu. Attributname Wertebereich Nullwerte erlauben Kommentar k id INTEGER nein PK k sid INTEGER nein PK parent id INTEGER ja FK parent sid INTEGER ja FK name VARCHAR2(255) ja beschreibung VARCHAR2(255) ja bild VARCHAR2(255) ja Produkttyp Die Entität Produkttyp fasst gleiche Attribute verschiedener Produkte zu einem Produkttyp zusammen. Das Attribut pt id ist der eindeutige Primärschlüssel der Entität Produkttyp. Das Attribut name ordent dem produkttyp einen Namen zu. Mit Hilfe des Attributs beschreibung lässt sich der Produkttyp näher beschreiben. 36

37 Attributname Wertebereich Nullwerte erlauben Kommentar pt id INTEGER nein PK pt sid INTEGER nein PK name VARCHAR2(255) ja beschreibung VARCHAR2(255) ja Text Attribut Die Entität Text Attribut ordnet jedem Produkt eine längere Beschreibungen zu. Attributname Wertebereich Nullwerte erlauben Kommentar p id INTEGER nein FK p sid INTEGER nein FK a id INTEGER nein FK a sid INTEGER nein FK ta sid INTEGER nein PK wert VARCHAR2(20) ja tze DATE nein String Attribut Die Entität String Attribut ordnet jedem Produkt kürzere Beschreibungen zu. 37

38 Attributname Wertebereich Nullwerte erlauben Kommentar p id INTEGER nein FK p sid INTEGER nein FK a id INTEGER nein FK a sid INTEGER nein FK sa sid INTEGER nein PK wert VARCHAR2(255) nein Number Attribut Die Entität Number Attribut ordnet jedem Produkt eine Zahl zu. (Bsp. Gewicht) Attributname Wertebereich Nullwerte erlauben Kommentar p id INTEGER nein FK p sid INTEGER nein FK a id INTEGER nein FK a sid INTEGER nein FK na sid INTEGER nein PK wert INTEGER nein tze DATE nein Multimedia Attribut Die Entität Multimedia Attribut ordnet jedem Produkt eine Multimedia-Beschreibung 38

39 zu. Attributname Wertebereich Nullwerte erlauben Kommentar p id INTEGER nein FK p sid INTEGER nein FK a id INTEGER nein FK a sid INTEGER nein FK mma sid INTEGER nein PK wert VARCHAR2(255) nein name VARCHAR2(255) ja groesse INTEGER ja typ INTEGER nein gza BLOB ja mmt sid INTEGER ja FK MM Typ Die Entität MM Typ enthält Informationen zu dem jeweiligen Multimediatyp, der ein Multimedia Attribut genauer beschreibt. Attributname Wertebereich Nullwerte erlauben Kommentar mmt id INTEGER nein PK mmt sid INTEGER nein PK name VARCHAR2(255) nein beschreibung VARCHAR2(255) ja 39

40 Produkt Profil Die Entität Produkt Profil ordnet jedem Produkt das jeweilige Profil zu. Attributname Wertebereich Nullwerte erlauben Kommentar p id INTEGER nein FK p sid INTEGER nein FK pr id INTEGER nein FK pr sid INTEGER nein FK Produkttyp Attribut Die Entität Produkttyp Attribut ordnet jedem Produkttypen ein Attribut zu. Attributname Wertebereich Nullwerte erlauben Kommentar pt id INTEGER nein FK pt sid INTEGER nein FK a id INTEGER nein FK a sid INTEGER nein FK Produkt 40

41 Die Entität Produkt enthält alle relevanten Daten, die der Online-Händler zu dem jeweiligen Produkt speichert. Das Attribut p id ist der eindeutige Primärschlüssel der Entität Produkt. Das Attribut name legt den Produktnamen fest. Die Attribute kurz beschreibung und beschreibung liefer einfache und detailliertere Beschreibungen des Produktes. Das Attribut thumbmail liefert ein Bild des jeweiligen Produktes. Die Attribute e preis und v preis legen den Einkaufs- bzw. den Verkaufspreis des Produktes fest. Das Attribut versandaufschlag legt den Aufschlag für schwer zu versendende Produkte fest. Das Attribut rabattfaehig legt fest, ob ein Produkt rabattfähig ist, oder nicht. Das Attribut prioritaet legt die Sortierreihenfolge innerhalb verwandter Produkte fest. Das Attribut status legt fest, ob das Produkt gerade verfügbar ist, oder nicht. Die Attribute pt id und pt sid stellen die Verbindung von Produkt und Produkttyp dar. Das Attribut k id stellt die Verbindung zwischen Produkt und Kategorie dar. Das Attribut h sid komm bei einer Änderung des Herstellers des jeweiligen Produktes zur Anwendung. 41

42 Attributname Wertebereich Nullwerte erlauben Kommentar p id INTEGER nein PK p sid INTEGER nein PK name VARCHAR(255) nein kurz beschreibung VARCHAR(255) ja beschreibung VARCHAR(255) ja thumbmail VARCHAR(255) nein e preis FLOAT(10) nein v preis FLOAT(10) nein versandaufschlag INTEGER nein rabattfaehig INTEGER nein prioritaet INTEGER ja status INTEGER ja pt id INTEGER ja FK pt sid INTEGER ja FK k id INTEGER nein FK h sid INTEGER ja FK Profil Die Entität Profil enthält Informationen zu verschiedenen Profiltypen, die den Kunden zugeordnet werden. Das Attribut pr id ist der eindeutige Primärschlüssel der Entität Profil. Das Attribut typ beschreibt verschiedene Profiltypen. Das Attribut name beschreibt den Namen des jeweiligen Profils. Das Attribut beschreibung dient der näheren Beschreibung des Profils. 42

43 Attributname Wertebereich Nullwerte erlauben Kommentar pr id INTEGER nein PK pr sid INTEGER nein PK typ VARCHAR(20) ja name VARCHAR(20) ja beschreibung VARCHAR(20) ja tze DATE nein Schlüsselbeziehungen Schlüsselbeziehungen in der Subject Area Produkt Produkt Produkttyp Die Entität Produkt hat eine Schlüsselbeziehung zu Produkttyp. Jedes Produkt wird so einem Produkttypen (Produkt.pt id Produkttyp.pt id, Produkt.pt sid Produkttyp.pt sid) zugeordnet. Produkt Hersteller Eine weitere n:1-beziehung besteht zwischen Produkt und Hersteller (Produkt.h id Hhersteller.h id, Produkt.h sid Hersteller.h sid). Jedes Produkt kann so genau einem Hersteller zugeordnet werden. Produkt Profil Zwischen Produkt und Produkt Profil existiert eine 1:n-Beziehung (Produkt.p id Produkt Profil.p id, Produkt.p sid Produkt Profil.s sid) und zwischen Produkt Profil und Profil eine n:1-beziehung (Produkt Profil.pr id Profil.pr id, Produkt Profil.pr sid Profil.h sid). Produkt Kategorie 43

44 Jedes Produkt wird über die 1:n-Beziehung mit Produkt Kategorie (Produkt.p id Produkt Kategorie.p id, Produkt.p sid Produkt Kategorie.s sid) und die n:1-beziehung zwischen Produkt Kategorie und Kategorie (Produkt Kategorie.k id Kategorie.k id, Produkt Kategorie.k sid Kategorie.k sid) mit einer Kategorie verbunden. Jedes Produkt kann so in mehreren Kategorien bzw. in jeder Kategorie können mehrere Produkte enthalten sein. Kategorie Kategorie Zur Verwirklichung rekursiver Kategorien, kann eine Kategorie auf sich selbst referenzieren. Es gibt deshalb eine 1:1-Beziehung innerhalb der Entität Kategorie (k id parent id, k sid parent sid). Die Startkategorie muss für parent id einen Null-Wert enthalten. Produkt Attribute Jedes Produkt verfügt über 1:n-Beziehungen mit Multimedia Attribut, String Attribut, Text Attribut und Number Attribut. So können zu verschiedenen Attributen die speziellen Produkteigenschaften verknüpft werden. Produkttyp Attribute Jeder Produkttyp verfügt über 1:n-Beziehungen mit Multimedia Attribut, String Attribut, Text Attribut und Number Attribut. So können zu verschiedenen Attributen die speziellen Produkttypeigenschaften verknüpft werden. Multimedia Attribut MM Typ Die 1:n-Beziehung zwischen Multimedia Attribut und MM Typ (Multimedia Attribut.mmt id MM Typ.mmt id, Multimedia Attribut.mmt sid MM Typ.mmt sid)ist dafür verantwortlich, dass mit der Entität Multimedia Attribut verschieden Medientypen verwalten werden können. So kann ein Attribut z.b. vom Typ PDF sein. 44

45 4.4.3 Grafik der Subject Area Produkte Abbildung 4: Subject Area Produkte 45

46 4.5 Subject Area Sitzung Die Subject Area Sitzung besteht aus den zwei Entitäten: Sitzung Kunde Erklärung der Entitäten/Attribute Sitzung Die Entität Sitzung enthält Informationen bezüglich der Kundenbesuche auf der Internetseite des Online-Händlers. Das Attribut s id ist der eindeutige Primärschlüssel der Entität Sitzung. Die Attribute knd id und knd sid verweisen auf den Kunden, der einer Sitzung zugeordent wird. Attributname Wertebereich Nullwerte erlauben Kommentar s id INTEGER nein PK s sid INTEGER nein PK knd id INTEGER ja FK knd sid INTEGER ja FK Kunde Die Entität Kunde enthält die für den Onlineshop relevanten Kundendaten. Das Attribut knd id ist der eindeutige Primärschlüssel der Entität Kunde. Die Attribute name und vorname legen den Kundennamen fest. Das Attribut gebdatum legt das Geburtsdatum des jeweiligen Kunden fest. Das Attribut geschlecht legt das Geschlecht des Kunden fest und kann die Werte männlich oder weiblich annehmen. Das Attribut beschreibt die adresse des Kunden. Jedem Kunden wird durch das Attribut 46

47 kennwort zusätzlich ein Kennwort zugeordnet, welches zum Einloggen auf der Shopoberfläche dient. Attributname Wertebereich Nullwerte erlauben Kommentar knd id INTEGER nein PK knd sid INTEGER nein PK name VARCHAR(40) nein vorname VARCHAR(30) nein gebdatum DATE nein geschlecht INTEGER nein VARCHAR(255) nein kennwort VARCHAR(255) nein Schlüsselbeziehungen Schlüsselbeziehungen in der Subject Area Sitzungen Sitzung Kunde Die einzelnen Sitzungen (engl. Sessions), also Besuche im Shop, werden in der Entität Sitzung gespeichert. Entsprechend kann zu einem Kunden in einer 1:n-Beziehung eine beliebige Anzahl Sitzungen zugeordnet werden (Sitzung.knd id Kunde.knd id, Sitzung.knd sid Kunde.knd sid). 47

48 4.5.3 Grafik der Subject Area Sitzung Abbildung 5: Subject Area Sitzung 4.6 Subject Area Warenkörbe Die Subject Area Warenkoerbe enthält die folgenden Entitäten: Kunde Warenkorb Produkt Produkt Warenkorb Erklärung der Entitäten/Attribute Kunde 48

49 Die Entität Kunde enthält die für den Onlineshop relevanten Kundendaten. Das Attribut knd id ist der eindeutige Primärschlüssel der Entität Kunde. Die Attribute name und vorname legen den Kundennamen fest. Das Attribut gebdatum legt das Geburtsdatum des jeweiligen Kunden fest. Das Attribut geschlecht legt das Geschlecht des Kunden fest und kann die Werte männlich oder weiblich annehmen. Das Attribut beschreibt die adresse des Kunden. Jedem Kunden wird durch das Attribut kennwort zusätzlich ein Kennwort zugeordnet, welches zum Einloggen auf der Shopoberfläche dient. Attributname Wertebereich Nullwerte erlauben Kommentar knd id INTEGER nein PK knd sid INTEGER nein PK name VARCHAR(40) nein vorname VARCHAR(30) nein gebdatum DATE nein geschlecht INTEGER nein VARCHAR(255) nein kennwort VARCHAR(255) nein Warenkorb Die Entität Warenkorb dient im Gesamtszeanrio dazu, die zu bestellenden Artikel der Kunden aufzuführen. Das Attribut wk id ist der eindeutige Primärschlüssel der Entität Warenkorb. Die Attribute knd id und knd sid ordnen jedem Warenkorb den zugehörigen Kunden zu. 49

50 Attributname Wertebereich Nullwerte erlauben Kommentar wk id INTEGER nein PK wk sid INTEGER nein PK knd id INTEGER ja FK knd sid INTEGER nein FK Produkt Die Entität Produkt enthält alle relevanten Daten, die der Online-Händler zu dem jeweiligen Produkt speichert. Das Attribut p id ist der eindeutige Primärschlüssel der Entität Produkt. Das Attribut name legt den Produktnamen fest. Die Attribute kurz beschreibung und beschreibung liefert einfache und detailliertere Beschreibungen des Produktes. Das Attribut thumbmail liefert ein Bild des jeweiligen Produktes. Die Attribute e preis und v preis legen den Einkaufs- bzw. den Verkaufspreis des Produktes fest. Das Attribut versandaufschlag legt den Aufschlag für schwer zu versendende Produkte fest. Das Attribut rabattfaehig legt fest, ob ein Produkt rabattfähig ist, oder nicht. Das Attribut prioritaet legt die Sortierreihenfolge innerhalb verwandter Produkte fest. Das Attribut status legt fest, ob das Produkt gerade verfügbar ist, oder nicht. Die Attribute pt id und pt sid stellen die Verbindung von Produkt und Produkttyp dar. Das Attribut k id stellt die Verbindung zwischen Produkt und Kategorie dar. Das Attribut h sid komm bei einer Änderung des Herstellers des jeweiligen Produktes zur Anwendung. 50

51 Attributname Wertebereich Nullwerte erlauben Kommentar p id INTEGER nein PK p sid INTEGER nein PK name VARCHAR(255) nein kurz beschreibung VARCHAR(255) ja beschreibung VARCHAR(255) ja thumbmail VARCHAR(255) nein e preis FLOAT(10) nein v preis FLOAT(10) nein versandaufschlag INTEGER nein rabattfaehig INTEGER nein prioritaet INTEGER ja status INTEGER ja pt id INTEGER ja FK pt sid INTEGER ja FK k id INTEGER nein FK h sid INTEGER ja FK Produkt Warenkorb Die Entität Produkt Warenkorb ordnet jedem Warenkorb die enthaltenen Produkte zu. Mit Hilfe des Attributes menge wird festgelegt, wieviele Produkte in einem Warenlorb enthalten sind. 51

52 Attributname Wertebereich Nullwerte erlauben Kommentar p id INTEGER nein FK p sid INTEGER nein FK wk id INTEGER nein FK wk sid INTEGER nein FK pw sid INTEGER nein PK menge INTEGER nein Schlüsselbeziehungen Schlüsselbeziehungen in der Subject Area Warenkorb Produkt Warenkorb Die Entität Produkt hat eine 1:n-Beziehung zu Produkt Warenkorb (Produkt.p id Warenkorb.p id, Produkt.p sid Warenkorb.p sid) und die wiederum eine n:1-beziehung zu Warenkorb (Produkt Warenkorb.wk id Warenkorb.wk id, Produkt Warenkorb.wk sid Warenkorb.wk sid). So können in jedem Warenkorb mehrere Produkte und ihre Mengen (über Produkt Warenkorb) gespeichert werden. Warenkorb Kunde Zwischen Warenkorb und Kunde gibt es eine weitere Beziehung (Warenkorb.knd id Kunde.knd id, Warenkorb.knd sid Kunden.knd sid). Jeder Warenkorb gehört zu genau einem Kunden (1:n-Beziehung). 52

53 4.6.3 Grafik der Subject Area Warenkörbe Abbildung 6: Subject Area Warenkörbe 5 Überprüfung und Erweiterung In der Phase der Überprüfung wurde festgestellt, dass das Schema noch nicht voll funktionsfähig war. Zwischen den Entitäten Attribut und Text Attribut, Number Attribut und String Attribut stimmten zwischenzeitlich die Schlüsselbeziehungen nicht. In einer früheren Version des Schemas wurden die Beziehungen anhand von Timestamps gebildet. Änderte sich nun ein Tupel der einen Entität blieb die Beziehung zu der alten Version bestehen, da das Schlüsselattribut der anderen Entität nicht aktualisiert worden ist. Von dem gleichen Problem waren auch alle anderen Entitäten betroffen, die sich der gleichen Technik bedienten. Die hier angewandte Lösung des Problems ist die Verwendung von Sequenzen, die in vorherigen Kapiteln bereits erläutert wurde. In der Subject Area Bestellung wurde zwischenzeitlich die Zahlungsart nicht berücksichtigt, aber auch das wurde nachgetragen. Die Entität Zahlung enthält nun die gewählte 53

54 Zahlungsart. Zur Diskussion wurde die Entität Hersteller gestellt. Die Gruppe hat sich gefragt, ob die Ausweitung auf die Hersteller notwendig ist und ob dies nicht als einfaches Attribut in der Produkt-Entität ausreichen würde. Mit dem Argument, dass der Hersteller einen guten Ansatz zur Personalisierung geben würde, fiel die Entscheidung zu Gunsten einer eigenen Entität. 6 Implementierung Das logische Modell wurde in ER-Win erstellt. Alle Entitäten und Relationen wurden entsprechend der Überlegungen angelegt. Abschließend wurde mit Hilfe von ER-Win das Schema auf den Oracle-Datenbank-Server übertragen und dort getestet. In einzelnen Punkten mußte das logische Modell angepaßt werden, damit es auf dem DBMS fehlerfrei funktioniert. Im speziellen mußten einige Nullwerte überdacht und die Länge der Varchars angepasst werden. 7 Plausibilitätsprüfung Um das Datenbankschema zu testen, sind Testdaten eingepflegt worden. Dabei handelt es sich bei den Stammdaten wie Kunden und Produkten um zufällig erzeugte Datensätze, die per Perlskript generiert wurden und über den Batchmodus von SQL*Plus importiert wurden. Durch die zufällige Erzeugung sind keine Pattern in diesen Daten zu erwarten. Männliche und weibliche Kunden haben alle jeweils den selben (geschlechtsspezifischen) Namen und eine angehängte fortlaufende Nummer. Straße, Hausnummer und Wohnort sind zufällig (teilweise aus kurzen Listen) ausgewählt. Die Schlüsselbeziehungen zwischen den Relationen werden durch die Testdaten erfüllt. Aus diesem Grund mußten die Relationen in bestimmter Reihenfolge gefüllt werden. Die Transaktionsdaten - Warenkörbe und Bestellungen - wurden hingegen mit Hilfe einer Java-Klasse namens TBasket 3 erstellt. TBasket implementiert einen Algorithmus, 3 Li, Ning, Wang, Jajodia: Generating market basket data with temporal information ( 54

55 der Transaktionsdaten mit zwei Arten von Pattern erzeugt: Die erste Form sind nichttemporale Pattern, wie sie vom Apriori-Algorithmus gefunden werden und bei der zweiten handelt es sich um sogenannte Kalenderpattern. Nichttemporale Pattern bezeichnen also frequent Itemsets, die in Bezug auf die gesamte Datenmenge häufig auftreten. Kalenderpattern hingegen erhält man durch Erweiterung der frequent Itemsets um temporale Informationen. Diese Informationen können bspw. die Form Jahr,Monat,Tag haben. Dabei können für Jahr, Monat und Tag konkrete Werte oder eine Wildcard eingesetzt werden. Somit bezeichnet z.b. 2000,12,*, dass ein Pattern im Dezember 2000 häufig auftrat, aber in den übrigen Daten nicht als Pattern identifiziert werden kann. Um auch Performance-Messungen durchführen zu können, sind relativ große Datenmengen erstellt worden. Es wurden 2000 Kunden, Produkte sowie ca. 1,1 Millionen Warenkörbe für einen Gesamtzeitraum von Januar 2000 bis Dezember 2002 erstellt. Damit kommt man auf etwa 11 Millionen Zuweisungen von Produkten zu Warenkörben. Pro Tag existieren etwa 1000 Transaktionen, in denen etwa 100 Pattern enthalten sind. Es wurde darauf verzichtet, shop-spezifische Daten wie Kategorien und Kreditkarteninformationen zu erzeugen, da diese für das Mining vorerst nicht relevant sind. 55