Datenverknüpfungen unterschiedlicher Tabellen aus Navigationsmenü?

[Novafly]

Hallo zusammen,

ich arbeite aktuell an einer Bauteildatenbank, bei welcher verschiedene Daten über ein Navigationssystem eingegeben werden sollen (der Übersichtlichkeit halber nicht alles in uForms).

Kurze Erläuterung zum Aufbau:
- "article" kann nur einen einzigen "sensor" enhalten und auch nur einen "manufacturer"
- "sensor" kann aber mehrere Meßbereiche (ranges) haben
- die beiden nicht verknüpften Tabellen rechts dienen nur zur Auswahl von vorgebenden Einträgen und stehen deshalb nicht in einer Beziehung

Nun komme ich an folgendem Punkt nicht mehr weiter...

a) wenn ich "nfrm_s_sensor" als Unterformular in "frm_s_articles" einbinde, werden die Daten sauber eingetragen und die Datensätze sauber verknüpft. Es wird kein Fehler geworfen.

b) Packe ich die drei Formulare für die Dateneingabe in ein Navigationsmenü und binde das nun unter "frm_s_articles" ein, kann keine Verknüpfung der Daten in den Unterformularen mehr zu "tbl_s_article" erstellt werden. Access überträgt die ID "article" nicht in das Unterformular nach "IDarcticle" (Screenshot).

Wie gehe ich da am besten vor bzw. wo liegt der Fehler, den ich nicht sehe?
Habe die Screenshots der Beziehungen und des Formularentwurfes einmal angehängt und hoffe, dass mir jemand von euch weiterhelfen kann

Bin wirklich für jeden Tipp dankbar, dass ich das verstehen kann.

Vielen Dank euch vorab und viele Grüße,
Stefan

[Beaker s.a.]

Hallo,

Wie gehe ich da am besten vor bzw. wo liegt der Fehler, den ich nicht sehe?

Im Datenmodell.
So auf die Schnelle
Die Beziehung sind fast alle falsch. Zwischen articles und sensors ist das eine
1:n-Beziehung aber andersrum
"ein article hat einen von n sensors"
die Beziehung zwischen sensors und ranges muss m.E. über eine n:m Zwischentabelle
herstellt werden.
Eine Tabelle manufacturers ist nicht vorhanden, ausser das ist die manufacturerlist.
Dann gehört diese aber 1:n mit der manufacturerData in Beziehung gesetzt. Letztere
ist dann auch eine n:m-Tabelle.
Die Tabelle sensors schreit auch noch nach weiterer Normalisierung; - zumindest die
max- und min-Felder gehören raus. Das sind Aggregate, die man sich mit einer Abfrage
anzeigen lässt.

gruss ekkehard


P.S. Bitte an die Regulars mich zu korrigieren und evtl. einzuspringen, da ich diese
Woche wahrscheinlich nicht täglich werde mitlesen können.

[Novafly]

Ahoi ekkehard,

vielen Dank dir für dein Feedback!!
Habe die Struktur nochmal komplett angepasst. für die "m:n"-Beziehungen gäbe es nun die Zwischentabellen "vtbl_xxx", sowohl für den "manufacturer" als auch für die "ranges". Ist das so umgesetzt, wie es Datenbank technisch korrekt ist?

Die Tabelle sensors schreit auch noch nach weiterer Normalisierung; - zumindest die
max- und min-Felder gehören raus. Das sind Aggregate, die man sich mit einer Abfrage
anzeigen lässt.

Hier müsstest du mir noch helfen, was du genau damit meinst (Aggregate abfragen)? die Min- und Max-Werte sind "hart" eingetragene Werte zur Beschreibung der maximalen Umgebungsparameter. Hier könnte auch ein Text stehen, vergleichbar mit den SIL-Angaben in den anderen Feldern.

Ich hänge die aktuellen Beziehungsstruktur nochmal an.

Bitte gerne um dein (euer) Feedback zum Entwurf. Mir geht es darum, mir das Wissen nachhaltig anzueignen bzw. vergangenes wieder aufzufrischen. In der PLC-Programmierung folgt man einer anderen Logik, den Sprung zu Datenbankstrukturen möchte ich aber hinbekommen!  

Vielen Dank euch für eure Zeit und viele Grüße,
Stefan

[Beaker s.a.]

Hallo Stefan,

Ist das so umgesetzt, wie es Datenbank technisch korrekt ist?

Noch nicht ganz. Die Beziehung zwischen articles und sensors muss anders herum,
wie bereits geschrieben; - in articles gehört ein FK zum sensor.
Ich kenne natürlich deine abzubildende Realität nicht, aber auf der rechten
Seite halte ich es soweit für richtig.
Auf der linken Seite verwirren mich die beiden manufacturer-Tabellen;- was hat
ein device (was ist das?) mit dem manufacturer in einer Tabelle zu suchen?
Wenn devices eine weitere, bis jetzt nicht erwähnte Entität ist, braucht es auch
dafür eine eigene Tabelle.

die Min- und Max-Werte sind "hart" eingetragene Werte

Also Grenzwerte, - die stehen dann doch vermutl. in der Tabelle ranges. Dann
kannst du die auch typisieren (Ta, Tp, Pp) und aus den sensors entfernen.

was du genau damit meinst (Aggregate abfragen)?

Ich war davon ausgegangen, das da Min- & Maxwerte aus einer Bewegungstabelle
gespeichert werden sollen. Und das wäre falsch.

gruss ekkehard

P.S.: Da gibt es noch ein paar Feldnamen mit dem Sonderzeichen "-". Ersetze das
noch durch "_", oder nimm's ganz raus.

[Novafly]

Hallo Ekkehard,

vielen Dank für deine Hilfe! Hierzu mein Feedback

Hi Ekkehard,

vielen Dank für deine Erläuterungen, hier mal mein Feedback

Noch nicht ganz. Die Beziehung zwischen articles und sensors muss anders herum,
wie bereits geschrieben; - in articles gehört ein FK zum sensor.

Das hatte ich tatsächlich anfangs so gemacht. Warum wurde das wieder geändert: 

Normalerweise ist der Vorgang der Datenanlage wie folgt gedacht:

a) neuer Artikel anlegen -> b) neuer Sensor anlegen unter diesem Artikel -> b2) Manufacturer zuweisen zum Artikel.

Baue ich die Struktur so auf, dass die Tabelle "aricles" als Zwischentabelle von "manufacturer" und "sensors" dient (also eine m:n-Beziehung zwischen diesen beiden Außentabellen herstellt), schmeißt Access immer die Fehlermeldung, dass er neue Datensätze aus Schritt b) nicht hinzufügen kann, weil diese mit "articles" in Beziehung stehen müssen.

Mir ist auch bewusst, woher das kommt: weder der neue Datensatz in "sensors", noch in "manufacturer" bekommen den Primärschlüssel von "article" übertragen und kennen sich daher nicht. Wie ich das lösen kann, ist mir noch nicht ganz klar, da ich die Anlagereihenfolge von oben gerne einhalten möchte und ggf. mit Unterformularen im Formular "acrticles" arbeiten möchte. Außer das geht so gar nicht, dann brauch ich ne andere Lösung  

Auf der linken Seite verwirren mich die beiden manufacturer-Tabellen;- was hat
ein device (was ist das?) mit dem manufacturer in einer Tabelle zu suchen?

Die ganz linke (1) und ganz rechte (2) Tabelle dient nur zur Auswahl von vordefinierten Werten (stbl... -> selectTables), so dass ich diese nicht einzeln in einer Werteliste in den übergeordneten Tabellen führen muss. Hier sind dann einfach Auswahlmöglichkeiten für die Tabellenfelder in (A) und (B) hinterlegt. 

Also Grenzwerte, - die stehen dann doch vermutl. in der Tabelle ranges. Dann
kannst du die auch typisieren (Ta, Tp, Pp) und aus den sensors entfernen.

Es gibt zwei Arten von Grenzwerten:

a) harte Limits in Bezug auf die maximale Umgebungstemperatur (Ta), Prozesstemperatur (Tp) etc., unter welchen das Gerät eingesetzt werden darf. Diese hänge nicht vom Messbereich ab, sondern sind artikelbezogene Limits.

b) In "ranges" werden dann die entsprechenden Messbereiche mit den min- und max-Werten zum Messbereich angegeben.

Ich hab das jetz nochmal umgebaut (Anhang) und versuche nun mal die manuelle Dateneingabe direkt in den Tabellen, bevor ich über die zugehörigen Formulare geheh. Mal sehen, ob das was wird

Vielen Dank nochmals und viele Grüße,
Stefan

[Beaker s.a.]

Hallo Stefan,

a) neuer Artikel anlegen -> b) neuer Sensor anlegen unter diesem Artikel -> b2) Manufacturer zuweisen zum Artikel.

Das ist ja auch richtig so (denk ich).

Dazu aber erst noch eine Frage wegen "neuer Sensor", - gibt es jeden Sensor mit allen
seinen Eigenschaften immer nur einmal, oder gibt es gleiche, will sagen Typen, von denen es
dann mehrere gibt?

Dann würde man bei Erfassung eines neuen Artikels den passenden Sensor aus einem Kombi auswählen
oder wenn es ein neuer ist, diesen über das NotInList-Ereignis anlegen. Das gleiche gilt für den
Manufacturer. Dabei wird in beiden Kombis der FK in articles gespeichert (refID_xxx).
Die Tabelle articles2manufacturer (war die im ersten DM auch drin?) macht nur Sinn, wenn es für
einen article mehrere manufacturer gibt (wird dann DS-Herkunft eines UFos). Und wenn das so ist
muss der FK aus der articles raus.
Dann ist das auch keine Zwischentabelle mehr.

Die ganz linke (1) und ganz rechte (2) Tabelle dient nur zur Auswahl von vordefinierten Werten

Ist das, was ich oben beschrieben habe.
Mit den Ranges kann ich mich heute nicht mehr beschäftigen, - Feierabend.

gruss ekkehard

[Novafly]

Guten Morgen Ekkehard

Genau, es gibt zu einem Artikel nur jeweils einen einzigen Sensor mit den jeweiligen Eigenschaften und auch nur einen einzigen Manufacturer

Wenn ich "articles" als Zwischentabelle von "manufachturer" und "sensors" (m:n) verwende, müsste man doch diese beiden Datensätze zuerst anlegen und am Schluss dem Artikel zuweisen, richtig?

Viele Grüße,
Stefan 

[Beaker s.a.]

Hallo Stefan,

Genau, es gibt zu einem Artikel nur jeweils einen einzigen Sensor mit den jeweiligen Eigenschaften

Ja, das hatte ich schon verstanden. Aber jetzt ist mir aufgegangen, das meine dies
bezügl. Frage natürlich Unsinn ist. Selbst wenn du mehrere Sensoren eines Typs hast
müssen die ja trotzdem einzeln erfasst werden, um eben den einen sensor dem article
zuordnen zu können.

auch nur einen einzigen Manufacturer

Wenn sich das auch in Zukunft nicht ändert (obwohl, man weissja nie) wäre die
Zwischentabelle dann überflüssig, und die manufacturerID kommt direkt in die articles
als FK.

Wenn ich "articles" als Zwischentabelle von "manufachturer" und "sensors" (m:n) verwende, müsste man doch diese beiden Datensätze zuerst anlegen und am Schluss dem Artikel zuweisen, richtig?

articles ist keine Zwischentabelle in dem Sinne. Die Tabellen sensors und manufacturers
sind im Prinzip Nachschlagetabellen für die beiden Eigenschaften des articles. Ich würde
deshalb das Beziehungsbild auch anders anordnen; - die articles ganz nach links, und die
anderen rechts davon übereinander.
Natürlich müssen sensor und manufacturer angelegt sein bevor du die dem article zuordnen
kannst. Da dies aber auf einem Formular eh über Kombifelder läuft, hast du dort auch die
Möglichkeit die beiden Tabellen um neue Einträge zu ergänzen. Dazu verwendet man gewöhnlich
das Ereignis "NotInList", welches ein Kombi zu Verfügung stellt.

gruss ekkehard

P.S.: Noch nicht geklärt ist, was ein Device ist.

[Novafly]

Hallo Ekkehard,

jetzt sind wir glaube ich beinander, wie man in Bayern so schön sagt

Der "manufacturer" kann pro "sensor" nur einer sein, auch in die Zukunft gedacht. Ein funktionsgleicher Sensor hätte dann wieder eine andere ERP-Nr. und einen anderen Hersteller (manufacturer). Sofern man hier noch Lieferanten aufführen wollen würde, verhält es sich anders. Dann kann tatsächlich ein Artikel mehrere Lieferanten haben. Das ist dann aber Sache von SAP bei uns . Die Datenbank dient den Entwicklungsabteilungen zur Auswahl von definierten Standardkomponenten.

articles ist keine Zwischentabelle in dem Sinne. Die Tabellen sensors und manufacturers
sind im Prinzip Nachschlagetabellen für die beiden Eigenschaften des articles. Ich würde
deshalb das Beziehungsbild auch anders anordnen; - die articles ganz nach links, und die
anderen rechts davon übereinander.

Da hast du absolut Recht. Ich ändere die Anordnung zur besseren Lesbarkeit ab.

Dazu verwendet man gewöhnlich
das Ereignis "NotInList", welches ein Kombi zu Verfügung stellt.

Schau ich mir gleich mal an in dem Zusammenhang - Danke dir!

P.S.: Noch nicht geklärt ist, was ein Device ist.

Das "Device" ist einfach nur das Gerät beim Hersteller, welches eine bestimmte Herstellerbezeichnung und eine eindeutige Herstellernummer hat. Vielleicht vergleichbar mit einem "A6" von AUDI und der zugehörigen Fahrgestellnummer (einmalige Nummer). Bei uns intern heißen die ganzen Geräte ja anderes, entsprechend den Vorgaben in der Anlagenentwicklung. Daher stand/steht der DeviceName und DeviceCode unter dem Hersteller und nicht unter dem Artikel.

Ich danke dir vielmals Ekkehard für deine Unterstützung und Hilfe!!
Denke das weitere Vorgehen ist mir soweit klar. Vielen Dank!

Gruß,
Stefan

[Beaker s.a.]

Das "Device" ist einfach nur das Gerät beim Hersteller,

Welches Gerät? Der article oder der sensor?
edit:
Spielt gar keine Rolle, da die beiden Felder dann Eigenschaften des Geräts sind und somit
auch in die entsprechende Tabelle gehören.