TheProfessor schrieb:

... oder habe ich nichts verstanden?

Imo, so flüchtig angeguckt, also "nichts verstanden" kann man auf keinen Fall sagen
(Andererseits finde ich immer was zu meckern - ich glaub, von dieser Regel hats bislang noch keine Ausnahme gegeben, obwohl das theoretisch doch möglich sein müsste )
ZB die Benamung:

• Bestellung.Nummer sollte Bestellung.ID heissen (und entsprechend wären auch die Fremdschlüssel zu ändern)
• ich empfehle immer, Entitäten (also Tabellen) singular zu benamen. Plural-Namen mögen auf die Tabelle bezogen plausibel erscheinen, aber es wird auch Code für einzelne Datensätze generiert, und dort ist die Plural-Flexierung definitiv falsch und irreführend, denn ein Datensatz repräsentiert eine Einheit, keine Vielheit
  

TheProfessor schrieb:

Personen können Disponenten sein, müssen es aber nicht. Andersherum ist jeder Disponent auch eine Person.
Genauso verhält es sich mit Firmen, die Lieferanten sein können...

Das berührt das problematische Thema der Vererbung von Entitäten.
Ist glaub so leidlich möglich, wie du es umgesetzt hast, aber letztendlich wird, was wirklich mit Entität-Vererbung gemeint ist (Stichwort 1:1-Relation), von typDataset nicht unterstützt.

Die AnfragenpositionMap ist eine klassische Mittler-Tabelle einer m:n-Relation - jo, genau so macht man das.

Ich versteh nur noch nicht die Beziehung zw. Lieferant und Artikel - Lieferant ist nicht etwa eine Spedition, sondern ist der Hersteller eines Artikels, richtig?
Aber da müsste doch eine Beziehung bestehen, denn ein Hersteller stellt doch bestimmte Artikel her (und andere nicht), evtl. auch m:n, wenn mehrere Hersteller gleichartige Artikel herstellen.
Oder ist das so, dass alle Hersteller alle infrage kommenden Artikel herstellen - dann kann man das so global lassen.

Das mit den Anfragen versteh ich auch nicht - also worum gehts eiglich insgesamt?
Ich versteh das Modell als Beschaffungs-Verwaltung, also die Artikel kommen herein, oder?

Jdfs. verstehe ich nicht, warum man zyklisch zu iwelchen Bestell-Positionen Anfragen stellt.
In meiner Welt ist eine Bestellung was fertiges, also wenn man nicht vorher den Preis angefragt hat, ist man selber schuld.

Und wieso Anfragen nur zu einzelnen Positionen?

Für mich ergäbe es einen Sinn, wenn man eine Bestellung zusammenstellt, und sich dann Angebote einholt - aber das macht man ja nicht zyklisch, sondern das wäre vlt. ein Status, den eine Bestellung einnehmen kann. Dann bezöge die Anfrage sich auf die komplette Bestellung.
Eine andere Art Anfrage wäre punktuell artikelbezogen, "Eggood - was kosten die Kondome?" oder sowas.

Also gut - ich versteh das nicht, so wie's ist.

TheProfessor schrieb:

Ging mir beim Designen irgendwie gegen den Strich Disponenten/Anfragende (ist hier nicht drin, kommt aber wahrscheinlich noch)/LieferantenAnsprechpartner als eigene Entitäten einzupflegen und jedem die selben Eigenschaften zu geben.

Jo - genau an diesem Punkt merkt man das, dass dem Dataset ein Konzept von Entität-Vererbung fehlt.
Wird sich dann zeigen, ob und wie du mit deim Behelf durchkommst, oder ob nicht doch besser ist, (zähneknirschend gewissermassen) die Attribut-Gruppen halt mehrfach anzulegen, in verschiedenen Entitäten.
Zumindest im DGV und in anderen datengebundenen Dialogen wirds glaub einfacher werden, wenn die Attribute direkt zu binden sind, und nicht erst eine Relation aufzulösen ist.

Ansonsten versteh ich glaub dein Modell nu (fast)

(Fast) nämlich, warum gibts 2 Relationen Disponent => Bestellung ?

Und wie gesagt: Beobachte zumindest die Auswirkungen der Plural-Flexierung. Ich rate ja davon ab, und dein Mischmasch ist besonders ungeschickt, also achte drauf, ob dir später beim Coden was auffält an den generierten Benamungen, mit denen du zu hantieren hast.

Ich halte den Aufbau der Tabellen Personen, Firma, Lieferanten und Disponenten für nicht zweckmäßig, von der Benamsung in Plural mal abgesehen.
Jede "Person" mit der eine Geschäftsbeziehung besteht gehört für mich in einen "Topf", den nenne ich Businesspartner (also die Tabelle).
In der Tabelle kann man "Firma" und "Person" unterscheiden und für beide benötige ich noch Anreden, die aus der (nicht vorhandenen) Tabelle Anredecode kommen. Dann gehören da noch Adressen mit in die Tabelle Businesspartner und Subtabellen für die Kontaktdaten (Telefonnummern, Email-Adressen).

Lieferant und Disponent sind für mich Rollen (Tabelle), ebenso wie Mitarbeiter, Kunde oder wenn man das spezifiszieren will oder muss, Endabnehmer, Großabnehmer. Hinter den Rollen stecken dann weitere Informationen wie Personalnummer beim Mitarbeiter oder Lieferantennummer beim Lieferanten etc.