Klassendiagramm und Datenbankableitung : Version 3 'Verleihnix 1.0'

Transkript

1 Änderungsprotokoll: Version 2 auf Version 3 (g.schabus) Änderung Datentypen von Geschlecht, Typ und Status. Da wir diese Eigenschaften nicht als Relationen sondern als Eigenschaften abbilden, hat die Geschäftslogik hier erhöhten Prüfungsbedarf. Die Datenbank kann die Gültigkeit der Werte nur mehr schwer prüfen. Ausnahme: z.b. Geschlecht: das kann sicher als Check-Constraint implementiert werden. Eine gleiche Vorgehensweise bei Artikel empfiehlt sich mm nach nicht, da die Listeneinträge doch dynamischer sind als vergleichsweise Geschlecht. Klassendiagramm 1.1 Wir hatten versucht eine Spezialierung der Entität Artikel zu umgehen. Da wurde uns jedoch vom Kunden Teiniker ein Strich durch die Rechnung gemacht. Vgl. im Anhang und Klassendiagramm 1.0.

2 Die Entitäten Artikel, Benutzer, Entlehnung erben von einer abstrakten Klasse 'Entity' (nicht eingezeichnet). Diese Basisklasse ist 'for future use' und implementiert nur eine 'Id', die alle persistenten Entitäten gemein haben müssen.

3 Datenbankableitung BENUTZER #Id (int) IdGeschlecht (string) Titel (string) Vorname (string) Nachname (string) (string) Passwort (string) Rolle (string) FEHLT im Requirements-Dokument! Vorschlag, statt der Auflösung der m zu n Beziehung die Rolle als string zu ARTIKEL #Id (int) IdTyp (string) Bestellnummer (string) Beschreibung (string) Anzahl (int) CD #Id(int) (referenziert auf Artikel! ) Interpret DVD #Id (int)(referenziert auf Artikel) Regisseur (string) BUCH #Id (int) (referenziert auf Artikel) Autor (string) ENTLEHNUNG #Id (int) IdBenutzer (int) IdArtikel (int) Datum (date) Text (string) IdStatus (string)

4 Entitäten, die über die Geschäftslogik abgebildet werden Geschlecht (Id, Bezeichnung) ('M', männlich; 'W,' weiblich) Typ (Id, Bezeichnung) ('1', Buch; '2', CD; '3' DVD ) Status ( Id, Bezeichnung) ('1', ausgeborgt; '2', zurückgegeben) Diese Entitäten sind im Datenmodell und im Objektmodell nicht als Objekte, sondern als Properties abgebildet. Diese Properties dürfen nur einen entsprechenden Wert aus den Listen annehmen.

5 Grund warum das Datenmodell umgestellt wurde: Anfrage an Kunde Teiniker: Sehr geehrter Herr Doktor! Ich habe eine Frage an Sie als Kunde des Verleihsystems. Artikel Sie möchten mehrere Arten von Artikeln verwalten. Es sind dies Bücher, CD s und DVD s. Für uns stellt sich die Frage, ob Sie es sich vorstellen könnten auch andere Produkte über diese Weise vertreiben zu wollen. Wenn ja, gibt es dahingehend schon eine Vision die Sie uns mitteilen können? Was halten Sie von folgendem Vorschlag? Die Produkte werden mit ihren generellen Merkmalen (Typ, Name, Anzahl etc.) im Artikelstamm abgebildet. Es gibt keine Spezialisierung der Produkte. Beispiel: Es gibt keine strukturierte Information Interpret bei der CD bzw. keinen Regisseur bei einer FilmDVD. Die Besonderheiten eines Produktes können Sie mit einem freien Text beschreiben. Beispiel: Typ: CD, Name: The Ultimate Tribute, Stock: 5 Zusatzinformation: Metallica, Metallic Attack, erschienen 2006, Stock: 3 Beispiel: Typ DVD, Name: Jagdfieber, Zusatzinformation: Columbia Pictures, Sony Animation Studios, Musik: Paul Westerberg, Ramin Djawadi, Regie: Jill Culton und Roger Allers Der Vorteil des Ansatzes: 1. Jede beliebige Information zu einem Produkt kann als Text hinterlegt werden. (Marketinginformation für den Kunden) 2. Schnellere und kostengünstigere Produktion (50%) Der Nachteil: 1. Weniger strukturierte Information. Sie finden im 2. Beispiel nicht den Regisseur Jill Culton sondern alle Artikel in dem der Suchbegriff Jill Culton vorkommen. Das kann jedoch auch als Vorteil gewertet werden, wenn Sie sich eine Websuche a la google vorstellen. 2. Wir müssten die Unterschiedlichkeit der Produkte in diesem und nur in diesem Text darstellen müssen. Ich freue mich auf Ihre Reaktion, damit Sie Ihr Produkt so schnell wie möglich nutzen können. Wir bedanken uns für die gute Zusammenarbeit und verbleiben mit freundlichen Grüßen Team

6 Erläuterung unserer Anfrage für den Nichtkunden Teiniker Wenn der Kunde Teiniker unserem Vorschlag zustimmt, würden wir datenbankseitig single table inheritance anwenden. Wir hätten also nicht für jeden Artikel eine eigene Tabelle, was das Mapping und den Datenbankcode um ca. 30%reduziert. Nur ein Insert pro Artikel und nicht mindestens 2. Das gleiche gilt für Updates, Deletes und Constraints im besonderen. Wir bräuchten weniger SpezialistInnen als würden wir z.b. concrete table inheritance anwenden wollen. Das führt zu einer besseren Skalierbarkeit des Produktionsprozesses. Wir könnten dem Kunden eine spätere Änderung verkaufen, da ihm die Chancen (schneller, günstiger) und die Risken (weniger Offenheit) bewußt waren. Antwort des Kunden ad Artikel) - Momentan sind keine weiteren Artikel-Typen geplant. - Es sollte schon möglich sein, zusätzliche Attribute für die abgeleiteten Typen Buch, CD, DVD zu definieren. Die Abbildung einer solchen Vererbung auf die DB ist Teil der Aufgabenstellung. Mit freundlichen Grüßen Egon Teiniker Durch die erste Aussage brauchen wir keine 'kombinatorische Explosion' zu befürchten. Die letzte Bemerkung bedeutet, daß wir die Geschäftsobjekte korrekt in die Datenbank abzuleiten haben. Alternativer Ansatz (verworfen) Man könnte einen Artikel auch so darstellen, daß die Eigenschaften in einer Relation ausgedrückt werden. Das relativ einfache Datenmodell und die erhöhte Kommunalität wiegen (so glauben wir) nicht die Problematiken der unterschiedlichen Datentypen der Eigenschaften auf.