Einsendeaufgaben EA-Besprechung | 31751 | WS 2018/19 | EA1 00817 | 06.12.2018

Hallo Leute,
ich starte das Thema und habe einen Entwurf angefertigt. Ich freue mich auf eine rege Diskussion.:notebook::bier:
Viele Grüße
Max
 

Anhänge

  • 1(3).pdf
    1,7 MB · Aufrufe: 150
Hallo Max,
Im Anhang ist mein Vorschlag.
Wo ich mir derzeit sehr unsicher bin, ist ob es eine direkte Verbindung zwischen den Mitarbeitern und den Kunden braucht, oder ob es aussreicht so wie du es hast (alles geht über die Antiquitäten als Verbindungspunkt).

Lg Geri
 

Anhänge

  • Einsendearbeit 3.jpeg
    Einsendearbeit 3.jpeg
    62,3 KB · Aufrufe: 138
Hallo Geri,
ok alles klar. Was ich relativ sicher weiß ist der letzte punkt der Aufgabe Punkt 6"Antiquitäten werden bisher in Einrichtungs- und Gebrauchsgegenstände sowie
Kunstobjekte unterteilt, wenngleich diese Einteilung bisweilen für Diskussionen sorgt, da sie von einigen weder als vollständig noch eindeutig angesehen wird."
bei einer älteren EA der selbe Wortlaut: Es kommen mehrere Dreiecke(du hast eins) , hier Verbindung zwischen Antiquität und den 3 Gegenständen.

Bei der Verbindung zwischen Kunden und Mitarbeiter könntest du Recht haben.(ich habs falsch) Punkt 2 ".....Beide dürfen Antiquitäten verkaufen." Punkt 3"....Dazwischen besteht ein gewisser Spielraum für Rabatte für treue Kunden."

Könntest du mir bitte den Unterschied zwischen mc m und c erklären.

Danke dir
Viele Grüße

 
Das habe ich gesehen. Ich habe an der Stelle nur ein Dreieck, da ich das von dem Beispiel in der Angabe übernommen habe. Ich frage mich ob es sich dabei nur um eine andere Darstellungsweise handelt oder nicht. Das muss ich mir nochmals genauer anschauen.

Den Unterschied zwischen c, mc und m kannst du in 00817 Kurseinheit 2 Seite 14 finden. Dabei geht es nur um die Anzahl der Entitäten die einer anderen Entität zugeordnet werden können.

c ... keine oder genau eine
m ... mindestens eine
m ... keine oder mehrere

Grüße
Geri
 
Hallo zusammen,

gibt es einen expliziten Grund, weshalb ihr keine Rauten für Beziehungstypen in euern ER Diagrammen modelliert habt?
Ich hätte es alternativ wie im Anhang modelliert.

Gruß
Martin
 

Anhänge

  • IMG_1442.JPG
    IMG_1442.JPG
    157,1 KB · Aufrufe: 102
Zuletzt bearbeitet:
Hallo,

wie schaut es bei euch mit Aufgabe 2 der EA1 aus? Folgende Lösung hätte ich anzubieten:
Frage1: Vereinigung
Frage2: Durchschnitt

Gruß
Martin
 
Hallo flowma,
In der Angabe steht gerschrieben:
Nutzen Sie die Notation, bei der ein Beziehungstyp zwischen zwei Entitätstypen als einfache Verbindungslinie
dargestellt wird. Tragen Sie für jeden Beziehungstyp die vollständigen Kardinalitäten
(1, c, m, mc) ein. Andere Notationen werden nicht gewertet.

Aufgabe 2 habe ich auch so

Geri
 
Hallo zusammen,

gibt es einen expliziten Grund, weshalb ihr keine Rauten für Beziehungstypen in euern ER Diagrammen modelliert habt?
Ich hätte es alternativ wie im Anhang modelliert.

Gruß
Martin

Wieso hast du denn beim Herkunftsnachweis ein "C" hingeschrieben?
Wofür bräuchte man überhaupt einen Herkunftsnachweis, der keine Antiquität hat?
 
Moin,

im Anhang mein ER-Diagramm. Ich habe festgestellt, dass wir fast alles gemeinsam haben, was die Unterteilung in Entitäten angeht, allerdings haben wir viele verschiedene Beziehungstypen... Über Feedback würde ich mich freuen..

Ich habe bei Herkunft das C gewählt, da es einen Herkunftsnachweis haben kann, also nicht zwangsläufig hat, und bei Antiquität die 1, da ein Herkunftsnachweis nur einer Antiquität zugeordnet werden kann.

Zwischen Antiquität und Mitarbeiter habe ich eine mc 1 Verbindung gewählt, da ein Mitarbeiter keine Antiquität zwangsläufig verkauft, aber eine oder mehrere verkaufen könnte.

Zwischen Fachkraft und Antiquität habe ich eine 1-1 Beziehung gewählt, da eine Antiquität durch eine Fachkraft begutachtet wird.

Zwischen Verkäufer und Antiquität habe ich eine m-mc Beziehung gewählt, weil es mindestens einen Verkäufer gibt, der, wenn er Pech hat, keine Antiquität verkauft, wenn er Glück hat eine Antiquität und wenn er richtig gut drauf ist mehrere Antiquitäten verkaufen kann.

Zwischen Kunde und Antiquität habe ich eine m-m Beziehung gewählt, weil es mindestens einen Kunden gibt, der mindestens eine Antiquität kaufen muss, weil er sonst kein Kunde wäre.

Zwischen Antiquität und Preisinfo habe ich eine m - 1 Beziehung gewählt, da mindestens eine Antiquität einer Preisinformation zugeordnet werden kann...

Hallo Max,
Im Anhang ist mein Vorschlag.
Wo ich mir derzeit sehr unsicher bin, ist ob es eine direkte Verbindung zwischen den Mitarbeitern und den Kunden braucht, oder ob es aussreicht so wie du es hast (alles geht über die Antiquitäten als Verbindungspunkt).

Lg Geri

Gute Frage...

LG,

Thore
 

Anhänge

  • DocScan.pdf
    308,6 KB · Aufrufe: 120
Bevor ich auf alles einzeln eingehe, denke ich, das hier ein grundlegendes Missverständnis vorherrscht. Die Min-Max-Notation bezieht sich auf die Anzahl der Teilnahmen der Entitäten an einem Beziehungstyp, sie sagt hingegen nichts darüber aus, was nun auf der anderen Seite passiert, und wenn, dann nur im sehr begrenzten Umfang.
Außerdem müssen Kardinalitäten immer in beide Richtungen gelesen werden.


Ich habe bei Herkunft das C gewählt, da es einen Herkunftsnachweis haben kann, also nicht zwangsläufig hat, und bei Antiquität die 1, da ein Herkunftsnachweis nur einer Antiquität zugeordnet werden kann.

Das sagst du so aber nicht aus.
Du sagst damit, das auf einem Herkunftsausweis eine Antiquität vorkommen kann, aber nicht muss. Eigentlich möchtest du aber sagen, das es zu einer Antiquität einen Herkunftsausweis geben kann. Siehe Beispiel Seite 16 mit Absatzregion - Lager. Ich glaube, hier sind die Kardinalitäten vertauscht.

Zwischen Antiquität und Mitarbeiter habe ich eine mc 1 Verbindung gewählt, da ein Mitarbeiter keine Antiquität zwangsläufig verkauft, aber eine oder mehrere verkaufen könnte.
Das scheint korrekt zu sein. Nur kann es auch Mitarbeiter geben, die gar keine Antiquitäten verkaufen. Wäre also statt dem 1 ein c. Und da ein Mitarbeiter mehrere verkaufen kann, wäre das ein mc. Kann eigentlich eine Antiquität mehrfach verkauft werden? Wenn nein, dann ist das hier eine 1 bzw. ein c, da es auch Antiquitäten geben kann, die nicht verkauft wurden.

Zwischen Fachkraft und Antiquität habe ich eine 1-1 Beziehung gewählt, da eine Antiquität durch eine Fachkraft begutachtet wird.

Ist die Frage, was hier eine "Begutachtung" genau darstellen soll.Hier sagst du, das jede Antiquität durch genau eine Fachkraft begutachtet wird und das jede Fachkraft genau eine Antiquität begutachten kann. Das heißt also, der Laden hat z.b. 10 Fachkräfte und 10 Antiquitäten. Keine Fachkraft ohne Antiquität. Und keine Antiquität ohne Fachkraft. Eigentlich willst du aber sagen, das eine Fachkraft entweder keine (frisch eingestellt), eine, oder mehrere Antiquitäten begutachten kann. Ist denn jede neue Antiquität auch automatisch begutachtet durch eine Fachkraft? Ich glaube nicht. Wäre also auch hier eine c:mc-Beziehung zwischen Antiquität und Fachkraft.
P.s: Eigentlich steht in der Aufgabenstellung, das erst eine Begutachtung erfolgt sein muss damit ein Verkäufer die Antiquität entgegen nimmt. D.h. ein Verkauf ist abhängig von der Existenz einer Begutachtung. Aus meiner eigenen beruflichen Erfahrung heraus wäre das dann eine schwache Entität, die von anderen Entitäten abhängig ist - in dem Fall von der Begutachtung. Das diese hingegen nirgendwo erwähnt wird in den KEs, wundert mich eigentlich. Ich finde das hier sehr verwirrend beschrieben.

Zwischen Verkäufer und Antiquität habe ich eine m-mc Beziehung gewählt, weil es mindestens einen Verkäufer gibt, der, wenn er Pech hat, keine Antiquität verkauft, wenn er Glück hat eine Antiquität und wenn er richtig gut drauf ist mehrere Antiquitäten verkaufen kann.

Wir modellieren hier eine Datenbank. Der Datenbank ist es - außer vielleicht bei irgendeiner Auswertung - ziemlich egal, wie viele male ein Verkäufer etwas verkauft hat oder nicht. Uns interessiert lediglich, ob es a) nur Verkäufer geben kann, die keine Antiquität verkauft haben(min 0), b) nur Verkäufer geben kann, die eine verkauft haben(min 1) oder c) welche geben kann, die mehrere verkauft haben(min nicht gesagt, zwischen 0 und m), oder jeder Verkäufer mind. 1 und maximal m verkauft hat.
Auf Seite der Antiquität interessiert uns das umgekehrt auch. Lagern wir Antiquitäten? Dann gibt es per se welche, die nicht verkauft wurden. (Minimum 0) Wird jede Antiquität sofort verkauft und zwar nur ein mal? (Minimum 1/maximum 1), oder wird eine Antiquität mehrfach verkauft weil wir es irgendwie geschafft haben, die Gesetze der Physik zu umgehen und unsere Antiquitäten einfach mehrfach verkaufen (minimum 1, maximal m)

Zwischen Kunde und Antiquität habe ich eine m-m Beziehung gewählt, weil es mindestens einen Kunden gibt, der mindestens eine Antiquität kaufen muss, weil er sonst kein Kunde wäre.

Damit sagst du wieder aus, das jede Antiquität mind. einen Kunden und maximal m Kunden hat und jeder Kunde mind. 1 und maximal m Antiquitäten kauft.
Es wäre aber irgendwie abstrus, wenn es keine Antiquität ohne Kunde gäbe. Umgekehrt gilt das übrigens auch. Was wäre das eigentlich für ein ERP-System, wenn ich Kunden nur anlegen dürfte, wenn diese vorher bei uns einen Auftrag erbeten haben? Ich kann auch nur die Stammdaten eines Kunden erfasst haben, weil dieser vielleicht eine Anfrage gestellt hat, oder vorher ein Telefongespräch erfolgte, oder oder oder...das heißt zwar, das der Kunde bei Unzufriedenheit vielleicht einen Umsatz von 0 in der Periode hat, aber das stellt doch nicht seine Existenz in Frage, oder? :)

Zwischen Antiquität und Preisinfo habe ich eine m - 1 Beziehung gewählt, da mindestens eine Antiquität einer Preisinformation zugeordnet werden kann...

Das sagt aber aus, das eine Antiquität eine oder mehrere Preisinformationen haben kann. (Wäre unter gewissen Umständen sogar sinnvoll mit anderen Rahmenbedingungen, hier wird dazu aber nichts gesagt.). Gibt es Antiquitäten ohne Preisinformationen? Etwa weil diese erst begutachtet werden müssten z.B.?
Hier besteht Interpretationsspielraum. Allerdings nicht auf Seiten der Fachkraft. Das eine Preisinfo von Antiquität und Fachkraft abhängig ist, ist soweit richtig. Schwierig ist es jedoch, das man eine Fachkraft erst Fachkraft nennt, wenn sie mindestens eine Preisinfo generiert hat. Kann ja sein, das derjenige neu ist und noch gar nicht in diesem Betrieb gearbeitet hat
 
Zuletzt bearbeitet:
Moin,
ist es erlaubt, die Entitäten Antiquität und Mitarbeiter zu verbinden, so dass nur eine indirekte Verbindung zwischen Antiquität und Fachkraft/Aushilfe über Generalisierung besteht? Ich habe dann über Kommentare die Aufgaben der Fachkräfte formuliert.
Gruß Alter
 
Hallo an alle, ich habe das ER-Diagramm auch fast wie alle Vorposter. Nur der Einteilung der Antiquitäten in Einrichtungs -/ Gebrauchsgegenstände und Kunstobjekte habe ich die Darstellung als Attribut in Ellipsen gewählt. Habe ich einen Denkfehler?
 
Naja, so etwas geht so lange gut, wie du für Kunstobjekte und Gebrauchsgegenstände keine eigenen Attribute brauchst. Aber wenn ich mir die Aufgabenstellung anschaue, so denke ich, das hier explizit eine Oberklasse Antiquität mit Unterklassen gefragt ist, wobei aus der Aufgabenstellung auch hervor geht, das diese a) überlappend ist und b) nicht vollständig, d.h. es kann auch noch andere Unterklassen geben, die hier nicht genannt sind:

"Antiquitäten werden bisher in Einrichtungs- und Gebrauchsgegenstände sowie Kunstobjekte unterteilt, wenngleich diese Einteilung bisweilen für Diskussionen
sorgt, da sie von einigen weder als vollständig noch eindeutig angesehen wird."
 
"Antiquitäten werden bisher in Einrichtungs- und Gebrauchsgegenstände sowie Kunstobjekte unterteilt, wenngleich diese Einteilung bisweilen für Diskussionen
sorgt, da sie von einigen weder als vollständig noch eindeutig angesehen wird."

Genau diese Aussage spricht meiner Meinung nach für eine Modellierung als ein Attribut "Kategorie". So lassen sich neue Kategorien ad hoc ohne Änderung des Modells einführen.
 
Genau diese Aussage spricht meiner Meinung nach für eine Modellierung als ein Attribut "Kategorie". So lassen sich neue Kategorien ad hoc ohne Änderung des Modells einführen.

Ein Attribut "Kategorie" wäre hier ein Diskriminator, womit ich also die Entitätsmenge "Antiquität" in mehrere Entitätsmengen aufspalten könnte. Diese Lösung hat jedoch drei große Nachteile:
Einerseits geht hierbei die Information verloren, das diese Aufspaltung nicht unbedingt eindeutig sein muss, d.h. etwas ist zum Beispiel Einrichtungsgegenstand als auch Kunstobjekt - somit müsste neben den Kunstobjekten, Gebrauchs - und EInrichtungsgegenständen auch alle dazu gehörigen Kombinationen eingegeben werden um diesen Informationsverlust auszugleichen und mit jedem weiteren hinzufügen eines weiteren möglichen Attributwertes müsste dieser Punkt bedacht werden. Daneben wird es spätestens dann ein Problem geben, wenn du zum Beispiel 10 Kategorien hast und für jede Kategorie noch mal alle dazu gehörigen Kombinationen. Du hast eine Unmenge an redundanten Informationen und auch Overhead hierbei.
Zweitens kann ich so auch weder eigene Beziehungen für z.B. Kunstobjekte, geschweige denn zusätzliche spezifische Attribute modellieren.
Drittens und damit einhergehend wäre so etwas ein hohes Risiko, wenn zum Beispiel ein neuer Kunde eine solche Unterteilung wünscht, wenn er sich irgendwann mal anders entscheiden sollte und zum Beispiel solche Attribute und/oder Beziehungen haben möchte. Diese Lösung wäre somit kaum vernünftig zu erweitern geschweige denn zu ändern, wenn diese Datenstrukturen umgesetzt wurden. Selbst wenn nicht dann hast du plötzlich anstatt einer Erweiterung eines Modells eine komplette Neufassung eines Datenmodells für einen anderen Kunden, und spätestens bei der Änderung der Business Logic fliegt dir das völlig um die Ohren, weil du diese komplett neu verfassen musst anstatt einfach mittels Parametrisierung zum Beispiel zu steuern was genau wo geschehen soll. Das wäre auch kaum für das eigene Unternehmen noch gewinnbringend umzusetzen, womit überhaupt die Umsetzung eines Projekts für Neukunden in Frage gestellt würde.

Ich weiß nicht, inwieweit sich die Macher der Aufgabe darüber Gedanken gemacht haben, vielleicht denke ich hierbei auch schon bereits viel zu weit und sie wollen nur sehen, das du so etwas grundsätzlich modellieren kannst. Falsch ist die Lösung jedenfalls nicht, hätte jedoch auch die oben genannten Nachteile.
 
Mir gefiel halt die Vererbung nicht -- die ist immer sehr unflexibel. Wenn man natürlich zu den Kategorien noch weitere Eigenschaften speichern muss, kommt man nicht drumherum. Ich hätte das eigentlich über einen selbstdefinierten Datentyp gelöst, eine Art erweiterbaren Enum. Damit lässt sich alles umsetzen, was keine zusätzlichen Eigenschaften erfordert.

Ich habe jetzt jedenfalls die Vererbung weggelassen.
 
Zurück
Oben