SQL Entity Relationship Modell - einen 'Zähler' für z.B. Verkauf / Verleih darstellen.

Hallo zusammen,

mal wieder eine Frage zum Entity-Relationship-Modell :-).

Hier zunächst die originale Aufgabenstellung (bzw. ein Teil davon):

"Larry musste des Öfteren feststellen, dass Medien, die er freundlicherweise Bekannten
ausgeliehen hatte, nicht zurückgebracht wurden. Daher soll das System auch die Möglichkeit
bieten, CDs, DVDs, Blu-rays und Bücher auszuleihen. Das System soll dabei so flexibel sein,
dass seine Bekannten sich die gleichen Sachen auch mehrmals ausleihen können und er
jederzeit eine Übersicht hat, wie oft etwas bereits ausgeliehen wurde oder welche Person
gerade welche Medien ausgeliehen hat."

CD's, DVD's etc. habe ich zunächst in einer 'Disjunkt-Partiellen' Generalisierung zum Entitytypen 'Medium' gestellt, welcher nun eine Relationship 'Verleih' mit dem Entitytyp 'Bekannte/r' eingeht (Kardinalität 0/n - 0/n).

Nun bin ich mir allerdings nicht sicher, wie ich einen Zähler darstelle, der zählt, wie oft ein Medium bereits verliehen wurde.

Mein Ansatz wäre es nun gewesen, den Relationshiptypen 'Verleih' in einen Entitytypen umzuinterpretieren (also ein Viereck um die Raute ziehen (wobei natürlich die Kanten zwischen Medium und Bekanne/r nachwievor mit der Raute verbunden sind) und diesen dann mit sich selbst in eine '0/n-0/n'-Relationship namens 'Zähler' zu stellen (also ein ähnliches Vorgehen wie bei einer Hierarchie, wobei es dort natürlich eine 0/1-0/n Kardinalität wäre).

Ist dieses Vorgehen korrekt - falls nicht, wo liegt der Fehler ? :-)

Beste Grüße,
HansHansen123

was spricht dagegen in der Entity Medium ein Attribut Zähler einzubauen?

Da es in dieser Aufgabe ausschließlich darum geht ein ERM-Modell von dem geschilderten Sachverhalt darzustellen (keine Relationsschemata / SQL-Implementierungen) und der Entitytyp Medium ebenfalls mit Kunden (Kaufzeitpunkt) und Verlag (hat veröffentlicht) in Verbindung steht, ist es evt. nicht ersichtlich, was das Attribut Zähler nun konkret zählt bzw. zählen soll.

Diese Aufgabe stammt aus einer vergangegen Klausur, von daher bin ich mir nicht sicher, ob die Umsetzung als Attribut wirklich im Sinne der Aufgabenstellung ist :-).

Wäre mein Ansatz des Zählers deiner Ansicht nach korrekt gewesen ?

Vielleicht könntest du das anhand einer Zeichnung z. B. durch Paint, PowerPoint, Visio verdeutlichen.

Für mich ist die Aufgabenstellung schon nicht deutlich. So wie diese formuliert ist und wie mein Menschenverstand arbeitet hat Larry das Medium jeweils einmal zur Verfügung und kann es daher nur jeweils einem Bekannten verleihen. Dieser Satz heißt für mich: "dass seine Bekannten sich die gleichen Sachen auch mehrmals ausleihen können" heißt lediglich, dass sie sich die Sachen nicht parallel sondern nacheinander ausleihen können. Für mich wäre das eine normale Medium-n->verleiht-1->Bekannter Beziehung (nach Chen), wobei dadurch ganz einfach abzulesen ist, wer welches Medium ausgeliehen hat. Den Zähler wiederum kann man als Attribut in Medium einbinden, da du ja keine Referenz brauchst wie oft genau ein Bekannter es ausgeliehen hat sondern nur wie oft das Medium ausgeliehen wurde.

mfg

Was die Aufgabenstellung angeht hast du definitiv recht, sie ist nicht eindeutig - ich habe es z.B. genau andersrum interpretiert, dass jedes Medium beliebig oft zur Verfügung steht ... wobei das nach deinem Beitrag nun tatsächlich eher unsinnig erscheint.

Dein Lösungsansatz leuchtet mir definitiv ein, ich habe vermutlich einfach zu kompliziert gedacht.

Hier mein ursprünglicher Gedanke:

Jegliche Form von Zähler ist hier unnötig, da die Anzahl Ausleihen für ein Medium ja bereits dadurch bestimmt ist, wie oft es in der Tabelle "Verleih" vorkommt (davon ausgehend, dass bei Rückgabe der Verleih-Datensatz nicht gelöscht wird, sondern nur z. B. ein Attribut "Zurückgegeben" auf "Verleih" gesetzt wird).
Das lässt sich leicht per SQL ermitteln, sodass ein Zähler nur Redundanz und somit potentiell Inkonsistenz verursacht.

Ihr benutzt wie es aussieht die MIN/MAX Notation. Du hast jetzt bei beiden 0, N geschrieben, d.h. ein Objekt Medium oder ein Objekt Bekannter muss nicht existieren bzw. muss nicht ausgeliehen werden (würde ich auch so annehmen). Bei Medium würde ich die Notation so belassen, da die Antwort auf die Frage wieviele Medien können von einem Bekannten ausgeliehen werden? entweder 0 oder mehrere sind. Jedoch fragt man anders herum, wieviele Bekannte können ein Medium ausleihen? Komme ich laut Textbeschreibung auf die Antwort entweder 0 oder 1. Also musst du deinen rechteckigen Kasten entfernen und die Raute dazwischen lassen.

Den Zähler würde ich in eine Blase an das Medium als Attribut hängen --> http://www.staud.info/er/er_f_4.htm 4.4 Min-/Max-Angaben bei mehrstelligen Beziehungen.

Erläuterung warum du das machst habe ich ja schon weiter oben gegeben ^^.
Apropos wenn du mal so eine Konstruktion 0,N 0,N hast dann wird eine neue Entität erschaffen (ohne deine Raute), die bei dem relationalen Datenbankschema dann eine Tabelle ist.

Ich habe diese Aufgaben immer in Klausuren geliebt *Ironie*, da es so viel Interpretationsspielraum gab und man wirklich jeden Schritt argumentieren musste (das ging dann aber auch immer gut ^^)

Die Zeichnung entspricht wie gesagt meinem ursprünglichem Lösungsansatz (als ich noch davon ausgegangen bin, dass beliebig viele Medien verliehen werden können).

Bevor ich dieses Thema als beendet betrachte, würde ich allerdings noch gerne wissen, ob mein Vorgehen aus der Zeichnung korrekt ist, wenn wir einfach mal annehmen, dass beliebig viele Medien zum Verleih zur verfügung stehen (nur um zu sehen, ob ich das Prinzip eines Zählers, der nicht als Attribut definiert wird, richig verstanden bzw. umgesetzt habe - darum geht es bei solchen Aufgaben ja oftmals - oder ob soein Vorgehen grundsätzlich immer falsch ist und ich es mir dementsprechend abgewöhnen sollte).

Das soein Zähler, wie von TheCadillacMan bereits erwähnt, eventuell überflüssig ist bzw. zu Inkonsistenzen führen kann, können wir ja mal für einen kurzen Augenblick aussen vor lassen :-P

Nein es kann leider so nicht gemacht werden.

1. Punkt in einer Raute dürfen nur Verben stehen
2. Punkt Wenn du eine n/m oder eine 0,N 0,N Verbindung hast dann wird eine neue Entität erstellt. Diese Entität kann entweder Verleih heißen oder die zwei Anfangsbuchstaben der ersten Entität + der zweiten Entität (diese Variante nur nehmen wenn man keine Ahnung hat wie man es sonst bennenen soll), d.h. du musst dann Medium --> Raute (ist im)-->Verleih--->Raute (kann tätigen) --> Bekannter
3. Die Raute ist eigentlich nur dazu da, damit das ERM schöner zu lesen ist --> hat keine Relevanz für das rel. Datenbankschema bedeutet, dass der Zähler in einer Raute schonmal keinen Nutzen hat
4. Den Zähler würde ich dann wahrscheinlich auch nicht mehr einbauen, da wie schon gesagt durch eine Abfrage dieser leicht ersichtlich ist, wenn dann würde es nur wieder beim Medium als Attribut Sinn machen.

Danke für deine ausfürhliche Antwort.

Es ist interessant zu sehen, dass uns in der Vorlesung ein komplett anderes Vorgehen beigebracht wird, angefangen bei der Bennenung von Relationshiptypen (die Raute), dort wurde uns explizit gesagt, dass Verben nicht verwendet werden sollten :-P.

Zum anderen haben wir ebenfalls nicht gelernt, dass eine (0,n) - (0,n) Beziehung zweier Entitytypen in einem neuen Entitytypen resultiert.

Das schweift aber alles vom ursprünglichen Thema ab (wenn du Interesse hast, kann ich dir ja die Folien meiner Vorlesung zukommen lassen, dann siehst du, was ich meine :-)).

Das Thema kann also als beendet angesehen werden, vielen Dank für die Hilfe ! :-)

HansHansen123 schrieb:

Bevor ich dieses Thema als beendet betrachte, würde ich allerdings noch gerne wissen, ob mein Vorgehen aus der Zeichnung korrekt ist, wenn wir einfach mal annehmen, dass beliebig viele Medien zum Verleih zur verfügung stehen (nur um zu sehen, ob ich das Prinzip eines Zählers, der nicht als Attribut definiert wird, richig verstanden bzw. umgesetzt habe - darum geht es bei solchen Aufgaben ja oftmals).

Zum Vergrößern anklicken....

Ich habe die Aufgabe so interpretiert, dass die Medien jeweils nur ein mal vorhanden sind und eben nacheinander ausgeliehen werden können. Für dieses Auslegung brauchst du wie gesagt keine Zähler.
Das gilt auch noch wenn man davon ausgeht, dass ein Medium mehrfach vorhanden sein kann aber jede Person maximal 1 Exemplar gleichzeitig ausleihen kann (Beispiel: du hast 3 Matrix-DVDs, Alice leiht sich eine, Bob darf sich auch eine leihen aber nicht zwei, er darf sich aber eine Matrix-DVD und eine Spiderman-DVD leihen).

Darf sich eine Person das gleiche Medium mehrmals gleichzeitig ausleihen (z. B. Bob will sich zwei Matrix-DVDs leihen) hast du zwei Möglichkeiten:
a) Du splittest die Transaktion: Du legst einen Verleih-Datensatz für die erste Matrix-DVD an und einen zweiten für die zweite Matrix-DVD. Hier ist auch kein Zähler nötig.
b) Du führst für die Tabelle "Verleih" eine Spalte "Anzahl" ein. Die gibt an wie viele gleiche Medien du in diesem Vorgang verliehen hast.
Fall b) ist meist schöner, da so klar ersichtlich ist, dass beide Medien in einer Transaktion und nicht etwa nacheinander ausgeliehen wurden.

Mir fällt spontan kein Fall ein, in dem es richtig wäre Zähler als eigene Tabelle auszuführen. Ein Attribut ist völlig ausreichend.

Selbst einen "Verleih"-Zähler auf der Tabelle "Medium" sollte man sich sparen, weil er redundant ist. Das würde man nur machen wenn man extrem große Datenmengen hat und das Schema selektiv denormalisiert um für bessere Performance Joins zu sparen. Aus Designsicht ist es meiner Meinung nach einfach falsch.

Danke für deinen Beitrag CaddilacMan, nun habe ich eine gute bzw. bessere Vorstellung davon, wie ich mit soeiner Situation korrekt umzugehen habe und was ich besser vermeiden sollte :-).

Richtig gut beigebracht muss ich sagen hat mir das auch nur die Schule. In der Vorlesung, naja da wurde es halt kurz durchgesprochen, aber wie man jetzt die Fragen aufbaut, wann was wirklich zu machen ist, da wird einem immer gesagt --> Selbststudium. Wobei damit viele überfordert sind ^^, obwohl es eigentlich wenn man weiß wie man die Fragen aufzubauen hat gar nicht so schwer ist.

Aber TheCadillacMan interpretierte es auch wie ich, dass Larry wirklich nur immer eines übrig hat und es nicht parallel ausgeliehen werden kann.

@ TheCadillacMan nochmal eine Frage: Wenn du es doch so siehst, dass es wirklich nur ein Medium pro Sache gibt warum willst du dann eine Tabelle mit Verleih. Reicht nicht da die Vererbung des Fremdschlüssels?

NightfireNES schrieb:

@ TheCadillacMan nochmal eine Frage: Wenn du es doch so siehst, dass es wirklich nur ein Medium pro Sache gibt warum willst du dann eine Tabelle mit Verleih. Reicht nicht da die Vererbung des Fremdschlüssels?

Zum Vergrößern anklicken....

Du meinst bei "Medium" gibt es einen Fremdschlüssel auf "Bekannter"?

Das ist erst mal völlig OK. Allerdings hast du bei dieser Lösung keinerlei Historie wer was wann ausgeliehen hat. In der Praxis will man bei so gearteten Relationen aber oft eine solche Historie haben. Man will z. B. Auswerten wie lange bestimmte Leute Dinge durchschnittlich ausleihen und wenn diese Dauer zu hoch ist ihnen eben nichts mehr leihen. Bei deiner Lösung weist du nur wer hat gerade was. Um die Aufgabe zu erfüllen brauchst du zusätzlich einen Zähler auf "Medium" um sagen zu können wie oft etwas ausgeliehen wurde. Über eine zusätzliche Tabelle bist du einfach flexibler.

Das ist natürlich alles über den eigentlichen Aufgabentext hinausgedacht. Wenn man Datenbanken in Softwareprojekten plant sollte man das aber immer machen, weil man sich sonst wahrscheinlich unnötig viele Wege verstellt um weitere Anforderungen zu lösen. Man muss halt aufpassen, dass man nicht zu weit über das Ziel hinausschießt.