Er-Modell erstellen.

[Joseph100]

Hallo zusammen,

ich habe eine kleine Frage zu Er-Modelle, und zwar ich muss den folgenden Satz ins Er-Modell umsetzen..

Ein Kunde kann sich beliebig viele Exemplare eines Artikels ausleihen. Dabei wird in der Datenbank zu jeder Ausleihe ein Zeitraum der Ausleihe mit Beginn und Ende gespeichert, sowie ein Vermerk darüber, ob die Ausleihe zurückgegeben wurde.
Eine Ausleihe bezieht sich auf ein Exemplar.
Der Kunde kann sich beliebig viele Exemplare ausleihen. Jede Ausleihe kann beliebig oft verlängert werden.


es ist nun so, dass man die Verlängerung durch Update der Beginn- und Ende-Zeit machen kann.
So meine Idee ist einfach ,dass man Ausleihe gar nicht als Entity in der Datenbank darstellt, Sondern alle Attribute an den Exemplar-Entity anhängt.
Also die Frage ist nun, OB man auf Ausleihe wirklich verzichten kann, indem man alle Attribute (wie Beginn, Ende, Ist-Zurück ) an Exemplar anhängt ?? oder wie würdet ihr sowas machen ??

ich hoffe, ihr könnt mir helfen.
Viele Grüße.

 

[benneq]

Ich mach das grundsätzlich so: Niemals Daten überschreiben oder updaten, sonst verliert man Daten. Speicherplatz kostet nichts, aber Informationen sind Gold wert. Jede (Trans)Aktion wird in irgendeiner Form abgelegt, damit man später nachverfolgen kann was, wann, wie, wo passiert ist.

 

[tollertyp]

Wenn du später nicht wissen willst, wer wann was geliehen hat, dann ja.
Aber selbst dann nicht, weil es einfach unschön modelliert ist.

 

[Joseph100]

Danke euch erstmal für die Antworten. Aber es werden keine Informationen Verloren gehen, da es immer noch eine Beziehung zwischen Kunde und Exemplar gibt. Also

Kunde (K-Id, Name, ...)
Exemplar (Ex-Id, Beginn, Ende, ... )
leiht aus (K-id , Ex-id )

Da es Redundanz vermieden werden soll.

 

[FranzvonAssisi]

Und was wenn einer sein Exemplar zurückgibt und der nächste es ausleiht?

Dann hast Du K1 und K2, die beide 'leiht aus' zum selben Exemplar haben.

Wer von beiden hat denn nun das Exemplar?

Da geht ganz sicher Information verloren

Lg

 

[benneq]

Wenn du auf die Ausleihe Tabelle verzichtest, woher weißt du dann wer zuletzt (also davor) das Buch ausgeliehen hat? Oder wie lang das Buch durchschnittlich ausgeliehen wird, um dem nächsten Kunden ungefähr sagen zu können, wann es wieder verfügbar ist? Oder wie oft es schon ausgeliehen wurde? Oder ob derselbe Kunde es einfach immer wieder ausleiht, und man ihn mal auffordern sollte, es sich einfach zu kaufen? Oder ob man lieber ein zweites Exemplar noch anschaffen sollte, weil die Nachfrage so hoch ist?

 

[Joseph100]

würdet ihr dann das so machen ..

Kunde (K-Id, Name, ...)

Exemplar (Ex-Id , Ist-Zurück)
leiht aus (K-id , Ex-id )

Ausleihe (Ausleihe-id, , Beginn, Ende, )
verlängert (Ausleihe-Id, K-Id)

Aber wie soll ich nun beide Entitys Ausleihe und Exemplar miteinander verbinden??

 

[FranzvonAssisi]

Nö, ein Kunde macht eine Ausleihe. Und die Ausleihe hat ein Exemplar (das ausgeliehen wird). Das Exemplar ist das Exemplar eines Artikels.

Die Verlängerung könnte man dann modellieren als ‚verlängert(K-Id, Ausleihe-Id, Enddatum)

Lg

PS: So würde ich es machen. Gibt bestimmt andere Möglichkeiten. Grundsätzlich werden die auch bestimmt alle akzeptiert, solange du die bei euch besprochenen Sachen einhältst.

 

[netzgestaltung]

Aber wie soll ich nun beide Entitys Ausleihe und Exemplar miteinander verbinden??

Mit der Exemplar ID, die wird bei der Ausleihe mit eingetragen.

 

[Joseph100]

ich glaube ich verstehe das langsam
Im Anhang steht jetzt mein kleines Er-Modell, ich hoffe es ist nun richtig geworden.
würde mich freuen wenn ihr mir noch mal etwas dazu sagt. Lg

 

[FranzvonAssisi]

Ja, sieht schon ganz gut aus.

Im Text oben steht „sowie ein Vermerk darüber, ob die Ausleihe zurückgegeben wurde“

du hast modelliert: „ein Vermerk darüber, ob das Exemplar zurückgegeben wurde“

ansonsten könnte man halt noch den Artikel modellieren (ist oben im Text auch fettgeschrieben)

Und ich bin mir nicht sicher, ob die Kardinalitäten stimmen (aber da bin ich mir wirklich nicht sicher) - gab ja soweit ich weiß auch noch verschiedene Notationen...

lg

 

[Joseph100]

Ja, an die Kardinalitäten müssen noch arbeiten, da das nur ein Teil des Modells war.

und ich habe es so gemacht mit dem Vermerk, weil eine Ausleihe ja von vielen Exemplaren bestehen kann. ich meine, wenn ich den Vermark an die Ausleihe hängen würde, dann würde das heißen dass der Kunde alle Exemplare auf einmal zurückgeben sollte, oder ist das nicht richtig??

 

[benneq]

Kommt halt darauf an wie fein granular es werden soll:
Kann ein Kunde immer nur eine Sache ausleihen?
Kann ein Kunde mehrere Sachen gebündelt ausleihen? Will man das dann als eine Ausleihe modellieren? (Quasi wie ein Warenkorb bei Amazon, in dem mehrere Artikel sind)
Kann man nur die gesamte Ausleihe wieder zurückgeben? Oder auch nur Teile davon?
Kann man nur alles zusammen verlängern? Oder auch nur Teile davon?

Ich finde die Analogie zu einem Warenkorb im Online Shop eigentlich ziemlich gut, vor allem wenn man das Retour System mit einbezieht. Bei Amazon kannst du ja auch 5 Produkte in einer Bestellung haben, aber dann nur 2 davon zurückgeben. (Nur das Thema "Verlängerung" ist da natürlich nicht enthalten)

Das wäre dann grob so zu formulieren:
Ein "Kunde" (id, name) kann beliebig viele "Ausleihen" machen
Eine "Ausleihe" (id, kunde_id, zeitstempel) besteht aus beliebig vielen "Ausgeliehenen Exemplaren"
Ein "Ausgeliehenes Exemplar" (id, ausleihe_id, exemplar_id, von, bis, zurückgegeben) ist einem "Exemplar" zugeordnet
Ein "Exemplar" (id, name) entspricht einem realen Produkt
Ein "Exemplar" ist verfügbar, wenn es kein "Ausgeliehenes Exemplar" davon gibt, dessen "zurückgegeben" Feld nicht gesetzt ist.

"Ausleihe" ist dann quasi das Gegenstück zum Warenkorb (bzw. Bestellung) im Online Shop.

Im Prinzip könnte man auch auf "Ausleihe" verzichten, weil alle nötigen Daten auch in "Ausgeliehenes Exemplar" vorhanden sind. Aber ich würde die Tabelle trotzdem behalten, der logischen Struktur wegen. Und vielleicht will man irgendwann dort noch zusätzliche Informationen hinterlegen, die sich auf die Ausleihe selbst, aber eben nicht auf die einzelnen Exemplare beziehen.

Das Thema "Verlängerung" lässt sich dann zusätzlich noch anfügen als eigene Tabelle, die mit den "Ausgeliehenen Exemplaren" verknüpft ist. Damit man jedes Exemplar separat verlängern kann.

 

[Joseph100]

Vielen lieben Dank euch allen für eure Hilfen. ohne euch hätte ich das ganze gar nicht verstanden. Lg

 

[Joseph100]

Hallo,

ich habe eine kleine Frage zu ER-Modellierung, und zwar ich muss folgendes machen:

Ein Redakteur kann Blogeinträge anlegen. Bearbeiten und Löschen ist nur bei seinen eigenen Einträgen möglich

Also wie kann ich das so modellieren, dass jeder Redakteur nur auf seine Blogeinträge zugriff hat. (hab unten meine Lösung beigefügt).

viele Grüße.

jeder Redakteur kann beliebig viele bearbeiten, aber ein Blogeinträge kann von genau einem Redakteur bearbeitet werden.

 

[DonnyDepp]

Hey, bei mir ists schon länger her mit ER Modellen ... aber was du da als Lösungsvorschlag hast, sieht eher wie eine Vermischung mit den use-cases aus.

Würde da ganz Simpel:
[Redakteur] --- 1 ---- <verwaltet> --- * --- [Blogeintrag]

Also ein Redakteur verwaltet viele (*) Blogeinträge.
Ein Blogeintrag wird von genau 1 Redakteur verwaltet. ( <- und das ist deine Anforderung in Rot)

 

[Joseph100]

Heyyy, Danke erstmal für die Antwort.

heißt das dass der Lösungsvorschlag nicht richtig ist?

ich weiß jetzt nicht ob ich alle drei Beziehungen (anlegen, löschen, bearbeiten) durch (verwalten) ersetzen kann, weil das der Aufgabestellung nicht mehr entspricht.

 

[DonnyDepp]

Dazu müsste man die ganze Aufgabe mal gesehen haben.

Aber wenn ich deinen Lösungsvorschlag in Code gießen müsste, würde das Entity in Pseudocode so aussehen:

class Redakteur{
List<Blogeintrag> angelegt;
List<Blogeintrag> kann_bearbeiten;
List<Blogeintrag> kann_loeschen;
}

Und der Code dahinter würde einen angelegten Blogeintrag in alle 3 Listen werfen.
Das ist somit sehr redundant und fachlich sinnfrei, da sich die Listen nicht unterscheiden.

Wäre da eine Logik dahinter, dass der Redakteur zb. nur jeden dritten Blogeintrag bearbeiten darf und jeden vierten löschen, dann machen die extra Zuordnungen wieder Sinn.

 

[Hauro]

Nur mit diesem kleinen Ausschnitt der Anforderungen, Geschäftsklassen / Entitäten, usw. ist es schwierig eine Aussage zu machen.

anlegen, löschen, bearbeiten

sind Aktivitäten. Diese in der Datenbank zu speichern macht nur Sinn, wenn festgehalten werden soll, welcher Redakteur die Aktivität wann durchgeführt hat. Darüber könnte dann z.B. ermittelt werden, welcher Redakteur einen Blogeintrag zuletzt bearbeitet hat.

Es dreht sich auf Basis der dürftigen Informationen darum, dass ein Blogeintrag (aktuell) nur von dem Redakteur bearbeitet und gelöscht werden kann, der ihn angelegt hat. D.h., dass eine Beziehung zwischen dem Redakteur und dem Blogeintrag hergestellt werden muss, der ihn angelegt hat. Dies geht über eine Tabelle oder einem Attribut, z.B. Identifier des Redakteurs, in Blogeintrag.

 

[ayngush]

ER wird ohne Use Case (das ist UML) dargestellt - es geht da nur um die Beziehungen innerhalb des Datenmodells und nicht um die Berechtigungen. Es sei denn, die sind an einer Stelle Teil des Datenmodells.

Also ER mit Kardinalität:
Redakteur (1) — verwaltet — (n) Beitrag

Anlegen, Bearbeiten, Löschen ist wieder typisches CRUD. Das bezeichnet zum einen die Datenbankoperationen mit DML, also Insert, Update, Delete, aber auch zum anderen die Use Cases, die man üblicherweise in einen UML Use Case Diagramm skizziert und wer gerne viel zeichnet in einer CRUD-Matrix zusätzlich.