Mapping / Zuordnung in zwei Richtungen (Tabelle)

[tomm85]

Hallo,

ich möchte gern Folgendes darstellen:

• Es gibt eine Tabelle mit Systemen
• Darin sollen auch Schnittstellen gepflegt werden, also Schnittstellen zueinander
• An sich habe es ich hinbekommen, dass das Feld "interface" letztlich auf die eigene Liste zugreift (happy)
• Nun fände ich es gut, wenn das in beide Richtungen geht: Heißt, wenn das ERP eine Schnittstelle zum Intranet hat, dann brauche ich ja beim Intranet nicht nochmal die Information pflegen, dass das Intranet eine Schnittstelle zum ERP hat

Sie dürfen in diesem Board keine Dateianhänge sehen.

Sie dürfen in diesem Board keine Dateianhänge sehen.

Sie dürfen in diesem Board keine Dateianhänge sehen.

Sie dürfen in diesem Board keine Dateianhänge sehen.

Danke für euren Input

[MzKlMu]

Hallo,
die Beziehungen sind nicht vollständig. Es fehlt die Tabelle für den 2. Fremdschlüssel.
Von einem zusammengesetzten Primärschlüssel würde ich Abstand nehmen, nimm leiber einen Autowert als PS und lege über die beiden FS-Felder einen zusammengesetzten eindeutigen Index.

[tomm85]

Danke Klaus.

Wie meinst Du das mit dem "zusammengesetzten, eindeutigem Index"?

...edit:
meinst Du das so?

Sie dürfen in diesem Board keine Dateianhänge sehen.

...zumindest hat jetzt meine Zwischentabelle einen eigenen PS :-)

[tomm85]

so sieht es jetzt aus (also bis hierhin glaube ich Dich verstanden zu haben)

Sie dürfen in diesem Board keine Dateianhänge sehen.

[Beaker s.a.]

Hallo Tom,

...zumindest hat jetzt meine Zwischentabelle einen eigenen PS :-)

Den würde ich aber umbenennen (z.B. "sys_int_ID"). Sonst könnte es
zu Verwechselungen kommen.
Wie es scheint kann wohl ein Interface auch ein System sein.
Dann musst du die t_systems ein zweites Mal in das Beziehungsfenster
aufnehmen, und mit dieser die Beziehung zu tf_InterfaceID erstellen.

gruss ekkehard

[tomm85]

Den würde ich aber umbenennen (z.B. "sys_int_ID"). Sonst könnte es

ist erledigt.

Sie dürfen in diesem Board keine Dateianhänge sehen.

Wie es scheint kann wohl ein Interface auch ein System sein.

Das ist immer so. Genau darum geht es. Womöglich ist der Titel "interface" irreführend. In der Liste (Tabelle) sollen alle System drin sein und dann möchte ich eben die Schnittstellen (also "interfaces" i.S.v. "Systemen") pflegen.

Das ist so ähnlich wie dieser Treat hier mit der Personen-Liste und dann mit Ehe-Partnern, nur eben mehr als ein Ehepartner bzw. hier "System".

Ich habe das ja auch eingangs einseitig hinbekommen möchte das aber gern sauber haben. Deshalb nochmal das Beispiel: wenn ich bei dem Zeile "Intranet" bereits pflege, dass das Intranet mit dem ERP und dem Wiki kommuniziert (also jeweils Schnittstellen hat), dann möchte ich beim ERP nicht nochmal pflegen müssen, dass es mit dem Intranet eine Schnittstelle hat - das wäre doppelt gepflegt und schreit nach Fehlern.

[MzKlMu]

Hallo,
die Beziehungen stimmen noch nicht.
Du musst die Tabelle "t_system" 2x in das Beziehungsfenser aufnehmen und 2 Beziehungen zu den beiden Fremdschlüsseln herstellen. Du hast dann zwei 1:n Beziehungen. Die 2. Tabelle wird von Access automatisch mit _1 ergänzt. Das solltest Du als erstes erledigen.

dann möchte ich beim ERP nicht nochmal pflegen müssen

Das ist aber nicht so einfach und erfordert etwas Programmierarbeit mit VBA.
Immer wenn die eine Richtung angelegt ist, muss über eine Anfügeabfrage auch die andere Richtung eingetragen werden. Und Du musst dafür sorgen, wenn eine Richtung gelöscht wird (oder geändert) dass der umgekehrte Datensatz auch gelöscht bzw. mit einer Aktualisierungsabfrage geändert wird. Die Daten konsistent zu halten erfordert Aufwand und lässt sich nicht automatisieren.

[tomm85]

Du musst die Tabelle "t_system" 2x in das Beziehungsfenser aufnehmen und 2 Beziehungen zu den beiden Fremdschlüsseln herstellen. Du hast dann zwei 1:n Beziehungen. Die 2. Tabelle wird von Access automatisch mit _1 ergänzt. Das solltest Du als erstes erledigen.

Okay. Lieben Dank für die ausführliche Erklärung. So ist es jetzt auch.

Sie dürfen in diesem Board keine Dateianhänge sehen.

Das ist aber nicht so einfach und erfordert etwas Programmierarbeit mit VBA

Ok, ärgerlich! DAs hatte ich befürchtet. Ich war mir nicht sicher, ob ich einen Knoten im Kopf habe und das nicht hinbekomme oder ob es nicht geht. Schade ... das muss ich erstmal sacken lassen    und mir den ganzen Ansatz nochmal überlegen

[tomm85]

mal unabhängig vom VBA ... so richtig funktioniert das jetzt aber auch noch nicht.

1.) Zum einen verstehe ich nicht, warum beim Aufklappen nur eine Spalte (tf_sys_int_ID) und die Verknüpfung auch mit dieser besteht.

2.) ich habe dann einfach händisch "Systeme als Schnittstellen" in der Zwischentabelle verknüpt und die tauchen gar nicht auf.

Sie dürfen in diesem Board keine Dateianhänge sehen.

[MzKlMu]

Hallo,
wieso beim Aufklappen, hast Du schon Kombinationsfelder in der Tabelle angelegt?
In Tabellen gehören keine Kombinationsfelder, die kommen nur in Formularen zum Einsatz.

Kombinationsfelder kann man so einstellen, dass mehrere Spalten zu sehen sind.

Zu "sacken lassen", es gibt für eine Datenbank keine Alternative zu diesem Ansatz.

[tomm85]

ich "surfe" immer ganz gern auf den Tabellen direkt rum und mache da meine Eintragungen. Mit Formularen verliert man sich (oder zumindest ich mich) häufig im Detail. Deshalb ist mein Ansatz schon möglichst viel auf der untersten Ebene zu lösen (also bei den Tabellen und Abfragen); wenn das da klappt, gestaltet sich der Rest nach oben hin einfacher (also Richtung Formular / FE).

Ich mache das immer über den Nachschlage-Assistenen. Darin wähle ich fast immer eine Abfrage (und ja, daher kenne ich das auch mit der Darstellung mehrer Spalten beim Aufklappen). Manchmal mache ich sogar in der Abfrage Kombinationen (z.B. ID und NAME) wähle das dann für die Darstellung im dem Feld aus, während die Verknüpfung im Hintergrund aber tatsächlich sauber über die ID läuft (s. rote Markierung im Bild).

Sie dürfen in diesem Board keine Dateianhänge sehen.

Wenn ich das jetzt mal so Review passieren lasse, dann war ich doch mit meiner Lösung, wie ich sie eingangs hatte, doch eigentlich schon weiter (s. ebenfalls das Bild).

Da konnte ich das ja schon in eine Richtung pflegen und wenn ich Dich richtig verstanden habe, dann müsste da jetzt VBA den umgekehrten Fall nachtragen (ggf. auch löschen).

[tomm85]

mit "sacken lassen" meine ich zu überlegen, ob ich das nicht ganz lösen sollte. Dabei bin ich nochmal auf Excel gekommen und eine banale Matrix. DAS ist es eigentlich; so, wie es dort dargestellt ist, bräuchte ich das in der Datenbank. Eine Verbindung wird gepflegt und dann taucht gleichzeitig diese "Abhängigkeit" oder Verbindung bei dem korrespondieren System auf.

Sie dürfen in diesem Board keine Dateianhänge sehen.

(Ich hole deshalb nochmal so weit aus und teile meine Gedanken in der Hoffnung, dass ich es ungeschickt erklärt habe und womöglich doch noch jemand eine zündende Idee hat).

Ich meine, wie wäre es denn in dem Eheleute-Beispiel hier:
https://www.access-o-mania.de/forum/index.php?topic=12934.0

Wenn ich bei Manfred pflege, dass er mit Erna verheiratet ist, müsste man dann zusätzlich den umgekehrten Fall pflegen, also auch, dass Erna mit Manfred verheiratet ist?

[MzKlMu]

Hallo,
Nachschlagefelder haben in Tabellen direkt nichts zu suchen. Das ist eine potentielle Fehlerquelle und sollte unbedingt vermieden werden.
Du kannst diese auch mit dem Assi in Formularen auch verwenden und hast keine Nachteile wenn diese in den Tabellen nicht sind. Also bitte ändern in normale Textfelder.

Dass der Doppeleintrag nicht automatisch geht trifft auch für das Ehepaar zu, ich hatte das auch mit dem System verstanden. Auch bei einem Ehepaar muss die 2. Verbindung manuell angelegt werden und gepflegt. Das lässt sich mit Aufwand (wie beschrieben) auch per VBA automatisieren.

Noch etwas mehr Info zu den Nachschlagefeldern:

1. Ein Nachschlagefeld verbirgt den eigentlichen Feldinhalt. Wenn man beispielsweise eine Tabelle in Datenblattansicht öffnet, wird ein Firmenname dargestellt, obwohl in Wirklichkeit im Feld die Kundennummer steht, und der Firmenname aus einer anderen Tabelle stammt. Nachschlagefelder verhindern, dass Datenbanken sauber durchstrukturiert angelegt werden.

2. Eine Abfrage, die das Nachschlagefeld verwendet und nach dem dargestellten Wert sortieren soll, funktioniert nicht. So wird im obigen Beispiel nicht nach dem Firmennamen, sondern nach der Kundennummer sortiert. Ebensowenig funktioniert die Angabe des Werts als Kriterium - auch hier müsste man die Nummer anstelle des Namens verwenden, um Ergebnisse zu erhalten. Wenn man den Wert aus einer Wertliste eines Kombinationsfelds auswählt, kann es passieren, dass gültige Daten mit falschen Werten überschrieben werden.

3. Das Nachschlagefeld beinhaltet eine (intern angelegte) Beziehung zwischen den Tabellen sowie die Anlage zusätzlicher Indizes, die in aller Regel überflüssig sind und die Datenbank unnütz aufblähen. Auch kann es vorkommen, dass man auf diese Weise die maximal zugelassene Anzahl von Indizes je Tabelle unwillentlich überschreitet.

4. Ein Kombinationsfeld auf der Basis eines Nachschlagefelds kann bei Filterung des Formulars dazu führen, dass der Filter mit dem Formular gespeichert wird. Beim nächsten Öffnen des Formulars fehlt der Wert und wird nachgefragt, was wiederum zu einem Fehler führt.

5. Berichte, deren Datenherkunft Nachschlagefelder enthält, benötigen Kombinationsfelder zu deren Darstellung, die den Bericht langsam und ineffizient machen können.

6. Die Datenbank kann nicht vernünftig von außen abgefragt (beispielsweise in Form einer Datenquelle eines Word-Serienbriefs) oder exportiert werden, da die Nachschlagefelder nicht nach außen gereicht werden.
7. Wenn man das Access-Sicherheitssystem verwendet, reichen die Berechtigungen oft nicht aus, um die Nachschlagefelder mit Inhalt zu füllen, was zu schwer nachzuvollziehbaren Fehlern führt. Das gilt insbesondere, wenn man aus Sicherheitsgründen mit Abfragen mit "WITH OWNERACCESS OPTION" arbeitet.

8. Nachschlagefelder verfälschen das, der Datenbank zu Grunde liegende, Relationenmodell aus der Sicht des Betrachters - besonders für Anfänger im Bereich Datenbanktechnik führt dieses zu einer unrichtigen Interpretation der Normalisierung

[tomm85]

ok Klaus, nochmals vielen Dank für die Ausführungen und die Hinweise zu den Nachschlagefeldern.

Eine mögliche Alternative ist mir gestern noch gekommen, die ich aber nochmal durchdenken oder gar testen möchte, sobald ich richtig wach bin.

Ein Klassiker für m:n ist bestimmt Kunde - Artikel, also Kunde - (Auftrag) - Artikel mit den den Abfragemöglichkeiten: "Welche Artikel hat der Kunde bestellt?" sowie umgekehrt "Welche Kunden haben diesen einen Artikel bestellt?"

Jetzt geht meine Überlegung dahin, dass beide Tabellen (also Kunde sowie Artikel) meine "System"-Tabelle sind, aber eben zwei verschiedene (die ich dann immer synchron halten muss, bspw. durch eine Tabellen-Erstellungs-Abfrage ... vielleicht geht es auch mit dem Ansatz, den Du beschrieben, zwei mal dieselbe Tabelle zu nehmen mit _1; da kenne ich aber die Besonderheiten / Einschränkungen noch nicht, ob sich das identisch verhält).

Jedenfalls geht der Gedanke dann so weiter, eine Abfrage auf Kunde (erste "System"-Tabelle) und eine Abfrage auf die Artikel (zweite "System"-Tabelle) zu machen und die dann bspw. über einen UNION so zusammenzubringen, dass sich die jeweils andere Kombination ergibt.

Aber jetzt erstmal einen Café und vielen lieben Dank bis hierhin.

[ebs17]

Deine Gedanken sind noch unausgegoren.

Tabellen-Erstellungs-Abfrage

... erzeugt unter dem Strich Kopien von vorhandenen Daten und damit
- Redundanz (Angriff auf Datenintegrität)
- letzten Endes Datenmüll (Aufblähen der DB)

Kunde, Artikel

Die Primärtabellen der m:n-Beziehung existieren schlicht für sich, schön ohne Duplikate. Da gibt es nichts zu synchronisieren, es müssen nur jeweils alle Kunden/Artikel vorhanden sein, die man in Nachfolge verwenden will.

In der Verknüpfungstabelle werden dann die Fremdschlüssel aus Kunde und Artikel fallbezogen zusammengeführt, je nach Gegenheiten und betrieblichen Ablauf ergänzt um ein Datum, eine Auftrag-ID u.a.
Daraus kann man dann die benötigten Abfragen entwickeln. Bei sauberen Strukturen ist das meist einfach.