Wirtschaftsinformatik: Beziehung herausfinden?

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Hallo alle zusammen,

ich habe folgendes Problem:
ich mache mein Abi auf einer BOS nach und habe zum ersten Mal seit 5 Jahren wieder Wirtschaftsinformatik.

Wir haben mit dem Thema „Datenbanken“ begonnen.

Folgendes Problem:

Aufgabe:
In einem Gartencenter werden überwiegend Bäume und Pflanzen verkauft.

Informationsstruktur:

  • Das Gartencenter bietet versch. Artikel an. Jeder Artikel ist einer Kategorie zu geordnet (z. B. Fichte ist ein Nadelbaum etc.)

  • Jeder Kunde kann unterschiedliche Aufträge erteilen und mit jedem Auftrag zahlreiche Artikel bestellen. Für jeden Auftrag soll die Stückzahl der jeweiligen Artikel erfasst werden.

  • Das Unternehmen hat Mitarbeiter. Dabei ist für einen Auftrag immer ein konkreter Mitarbeiter zuständig.

Bearbeitung:
Erstellen Sie aus der angegebenen Informationsstruktur ein E-R-Diagramm und bestimmen Sie die Kardinalitäten der Assoziationen.

Meine Frage:

Wie finde ich die Kardinalitäten von dieser Beziehung heraus:

„- Jeder Kunde kann unterschiedliche Aufträge erteilen und mit jedem Auftrag zahlreiche Artikel bestellen. Für jeden Auftrag soll die Stückzahl der jeweiligen Artikel erfasst werden.“?

Ich dachte mir, es können doch MEHRERE KUNDEN MEHRERE AUFTRÄGE erteilen => die Beziehung ist n:m.

KD1 Auftrag 1
KD2 Auftrag 2
KD3 Auftrag 3
KD4 Auftrag 4

Jetzt könnte doch von KD1 und KD4 jeweils den Auftrag 1, Auftrag 2 und Auftrag 3 erteilen. Also wären es doch MEHRERE KUNDEN die MEHRERE Aufträge erteilen, also n:m.

Laut Lösung soll die Beziehung 1:n sein, also GENAU EIN KUNDE erteilt mehrere Aufträge.

Wo habe ich meinen Denkfehler? Wie lässt sich die Kardinalität n:m herausfinden? Gibt es eine Frage die ich mir diesbezüglich stellen kann?

Vielen Dank im Voraus!

#2

Hallo,

Ich dachte mir, es können doch MEHRERE KUNDEN MEHRERE AUFTRÄGE
erteilen

an sich richtig.

=> die Beziehung ist n:m.

Da aber die Frage falsch gestellt wurde, ist auch die Beziehung falsch. :smile:

KD1 Auftrag 1
KD2 Auftrag 2
KD3 Auftrag 3
KD4 Auftrag 4

Jetzt könnte doch von KD1 und KD4 jeweils den Auftrag 1,
Auftrag 2 und Auftrag 3 erteilen.

Aber nein doch. Jeder Kunder erteilt doch nur einen dieser Aufträge, es kommt eben NICHT vor, dass KD1 und KD4 den Auftrag 1 erteilen.

Laut Lösung soll die Beziehung 1:n sein, also GENAU EIN KUNDE
erteilt mehrere Aufträge.

Richtig.

Wo habe ich meinen Denkfehler?

Es ist ein Fehler, den Schüler ständig machen, das nur zum Trost. :smile:

Wie lässt sich die Kardinalität
n:m herausfinden? Gibt es eine Frage die ich mir diesbezüglich
stellen kann?

Ja, und zwar ganz einfach. Um die Kardinalität von der gegenüberliegenden Seite herauszufinden, musst du anfangs immer von der 1 auf der einen Seite ausgehen. Sprich: EIN Kunde kann MEHRERE Aufträge erteilen. D. h. auf der Auftragseite steht ein n. Andersrum: EIN Auftrag kann von genau EINEM Kunden erteilt werden, also steht auf der Kundenseite eine 1.

Wie gesagt, in der Summe ist es zwar richtig, dass mehrere Kunden mehrere Aufträge erteilen, aber an der Stelle ist es irrelevant, weil du dich, je nach Richtung, auf einen Kunden bzw. auf einen Auftrag als Ausgangs-Entity beziehen musst.

Vielen Dank im Voraus!

Bitte. :smile:

Christa

#3

Der Urfurz der Modellierung
Moin,

Ich dachte mir, es können doch MEHRERE KUNDEN MEHRERE AUFTRÄGE
erteilen => die Beziehung ist n:m.

kleiner Schlurzkuss, es geht nicht um Kunden und Aufträge überhaupt, sondern um die Frage, was konkrete Kunden mit konkreten Aufträgen zu tun haben. Schauen wir uns mal die Sachverhalte an und zwar aus beiden Richtungen:

  1. 1 Kunde kann beliebig viele Aufträge erteilen.
  2. 1 Auftrag kommt von genau einem Kunden.

==> Kunde > Auftrag

(1.) erklärt sich von selbst, (2.) muss so sein, weil aus einem Auftrag (mindestens) eine Lieferung wird, und die kann nur einen Empfänger haben. Alles klar?

Diese Form der Verbalisierung ist die Vorstufe zu jedem brauchbaren Datenmodell. Nach 20 Jahren im Geschäft fange ich immer noch so an :wink:

Gruß Ralf

#4

PS … Primärschlüssel
FS … Fremdschlüssel

Tabelle Mitarbeiter: Mitarbeiternummer (PS), Nachname, Vorname, …

Tabelle Sortiment: SortimentID(PS), Bezeichnung, …

Tabelle Artikel: Artikelnummer (PS), Bezeichnung, SortimentID(FS)…

Tabelle Auftrag: AuftragID (PS), Kunde (FS), Auftragsdatum, Mitarbeiternummer (FS)

Tabelle AuftragsInhalt: AuftragID (FS), Artikelnummer (FS), Menge, …

Damit gibt es in dieser Datenbank lauter 1:n-Beziehungen.
Ein Kunde kann mehrere Aufträge auslösen, ein Auftrag ist aber stets nur einem Kunden zugeordnet.
Ein Mitarbeiter kann mehrere Aufträge betreuen, ein Auftrag wird immer nur von einem Mitarbeiter betreut.
Ein Sortiment kann mehrere Artikel beinhalten. Ein Artikel gehört genau zu einer Sortiment.
Im Auftragsinhalt können mehrere Artikel stehen, diese Artikel lassen sich aber nur zu genau einem Stammsatz zurückverfolgen.

Verbal könnte man von einer m:n-Beziehungen sprechen: Ein Auftrag enthält viele Artikel, ein Artikel kann Bestandteil mehrerer Aufträge sein. Aber für die Umsetzung der Datenbank muss mann diese m:n-Beziehungen auflösen in mehrere 1:n-Beziehungen (hier Auftrag 1:n Auftragsinhalt, Artikel 1:n Auftragsinhalt).

Gruß
EPa

#5

ER-Modell/Datenbankumsetzung
Hallo,

auch wenn es schon länger als 1 Monat her ist und der UP sich nicht mehr gemeldet hat …

Verbal könnte man von einer m:n-Beziehungen sprechen

Nicht nur verbal, man hat einfach beim ER-Modell 1:n- und m:n-Beziehungen.

Aber für die Umsetzung der Datenbank
muss mann diese m:n-Beziehungen auflösen in mehrere
1:n-Beziehungen

Es ging gar nicht um die Umsetzung, sondern um die Modellierung, das sind zwei verschiedene Paar Schuhe. :wink: Und es ist auch nicht ganz richtig, dass die m:n-Beziehungen in 1:n-Beziehungen „aufgelöst“ werden, denn aus m:n wird eigentlich 1:1 (die Tabelle der m:n-Beziehung hat als Primärschlüssel die Primärschlüssel der beteiligten Entitys).

Viele Grüße
Christa

#6

Moin, Christa,

Und es ist auch nicht ganz richtig, dass die m:n-Beziehungen in
1:n-Beziehungen „aufgelöst“ werden, denn aus m:n wird
eigentlich 1:1 (die Tabelle der m:n-Beziehung hat als
Primärschlüssel die Primärschlüssel der beteiligten Entitys).

hm. Da braucht’s aber viel Liebe, um das zu glauben :wink:

Zwei Entitäten, zwischen denen eine m:n-Beziehung steht, können so nicht in Tabellen abgebildet werden. Man behilft sich mit einer zusätzlichen Entität, die zu den ursprünglichen Entitäten jeweils eine 1:n-Beziehung hat. Vorteil dabei: Die m:n-Beziehung kann, falls nötig, eigene Attribute bekommen. Eigentlicher Zweck ist aber, dass ein Tool aus den Entitäten die Tabellen erzeugen kann.

Und die Fremdschlüsselattribute können in den Schlüsselkandidaten eingehen; wie der tatsächliche Schlüssel aussieht, steht auf einem anderen Blatt.

Gruß Ralf