n:m oder m:n, egal? PK der Zwischentabelle?

[JohnnyK]

Hallo Community,

bin gerade dabei in Access 2003 das ER-Diagramm für Standorte und deren verbauten Komponenten zu bilden, d.h. ich hab ne Liste mit Standorten, ne Liste mit Komponenten und verheirate diese in ner dritten Zwischentabelle. Ein Standort kann mehrere Komponenten haben, jede Komponente kann in vielen Standorten vorkommen.

Frage:

• Welche seite ist n, welche m, oder ist das egal?
  
• Was ist der Primärschlüssel der Zwischentabelle? Muss ich ein AutoID einfügen oder geht auch folgendes:

  Eine m:n-Beziehung besteht eigentlich aus zwei 1:n-Beziehungen mit einer dritten Tabelle, deren Primärschlüssel aus zwei Feldern besteht, und zwar den Fremdschlüsseln aus den beiden anderen Tabellen. Quelle

  Aber wie mach ich das in Access, also zwei FK als PK zu definieren?
  

Danke für eure Hilfe!

[MzKlMu]

Hallo,
ich würde als PK einen Autwert verwenden. Ein einzelner PK ist im weiteren Verlauf der Entwicklung der DB leichter zu handhaben. Außerdem kann es ohnehin sein, dass Du einen einzelnen PK brauchst, falls auch diese Tabelle zu einer 1-Tabelle wird, was ja sein kann.
Um Doppelungen auszuschließen kannst Du auch einen zusammengesetzten eindeutigen Index (kein PK!) anlegen.

[Wurliwurm]

Im Prinzip ist es egal, welche Seite m und welche n ist. Wenn Du etwa eine Tabelle modellierst, wer wen kennt, ist das ja auch egal.

Eigentlich brauchst Du nur eine Tabelle mit zwei Feldern, die zusammen den Primärschlüssel bilden. Das eine Feld hat dabei den FK zur Standorttabelle, das andere den FK zur Komponententabelle. Eine AutoID für die Zwischentabelle ist überflüssig, weil diese Tabelle ja keine echten Entitäten speichert.

[JohnnyK]

Eigentlich brauchst Du nur eine Tabelle mit zwei Feldern, die zusammen den Primärschlüssel bilden. Das eine Feld hat dabei den FK zur Standorttabelle, das andere den FK zur Komponententabelle. Eine AutoID für die Zwischentabelle ist überflüssig, weil diese Tabelle ja keine echten Entitäten speichert.

Ok, ab er wie mach ich das in Access? Wo kann ich das einstellen?

[ebs17]

Siehe Zusammengesetzten Index anlegen.

Ich würde aber in jedem Fall gemäß Klaus Vorschlag ein Autowertfeld als Primärschlüssel einführen und verwenden:
- Wenn in der Zwischentabelle die Verknüpfungen um weitere Informationen wie Gültigkeitsbegrenzungen u.ä. ergänzt werden, entstehen durchaus eigene Informationseinheiten.
- Wenn man etwas extensiver Abfragen schreibt, ist es durchaus hilfreich, wenn man ein Feld als Schlüssel zum Verknüpfen verwenden kann als einen Mehrfelderindex. Ein Konstrukt wie ...

Code [Auswählen] Erweitern

... WHERE ID IN (SELECT IDX ...
... funktioniert übersichtlich nur mit einem Einfeldschlüssel.

MfGA
ebs

[Wurliwurm]

Ich würde aber in jedem Fall gemäß Klaus Vorschlag ein Autowertfeld als Primärschlüssel einführen

Die m:n-Beziehung ist völlig uninteressant ohne die beteiligten Fremdschlüssel. Sie hat keine eigene Existenz. Ich kann mir nicht vorstellen, daß sie jemals ohne diese Attribute gelesen wird.

Lehrbeispiel: Es gibt eine Tabelle Personen (wo ein einzelner Autowert-Schlüssel absolut angesagt ist) und eine Tabelle (~"Relation") Beziehung, wo die Beziehung der Eltern modelliert ist. Die Relation "Beziehung" braucht keinen Autowert als Primärschlüssel.

tblPersonen
-PersonID (Autowert INT)
-Vorname, Nachname, Geburtstag etc...
-VaterID (FK zu tblPersonen.PersonID)
-MutterID (FK zu tblPersonen.PersonID)

tblBeziehung
-MannID
-FrauID
-Beziehungsstatus (verliebt|verlobt|verheiratet ...)
-viele weitere Attribute zur Beziehung wie Kennenlerndatum, erster Kuß ...

Beispielabfrage:
Liste alle Personen auf, deren Eltern in einer Beziehung sind und gib die Beziehung an:
SELECT tblPerson.PersonID, tblPerson.Vorname, tblPerson.Nachname,
tblPerson.Geburtstag, tblBeziehung.Status as Elternbeziehung
FROM tblBeziehung INNER JOIN tblPerson ON (tblBeziehung.MannID = tblPerson.VaterID)
AND (tblBeziehung.FrauID = tblPerson.MutterID);

Wie würdest Du das modellieren? Würde mich echt interessieren, welche Abfragen denkbar sind, wo nicht beide Attribute MannID und FrauID bei der Relation tblBeziehung zur Verknüpfung benutzt werden, sondern ein zusätzliches Attribut BeziehungID.

Weitere Frage: Wenn die Beziehung zwischen A und B angelegt, gelöscht und wieder neu angelegt wird, ist sie dann eine neue Beziehung oder immer noch die alte?

[ebs17]

Mit extensiveren Abfragen meine ich nicht simple JOIN's (die sich dann auch noch ausschließlich an Beziehungen orientieren), sondern Abfragen, wo Subselects über drei und deutlich mehr Ebenen geschachtelt sein können

Bei Aufgabenstellungen wie "Wer hat im Zeitraum X mehr als 6 Beziehungen, die länger als 3 Monate dauern + ..." kann ich mir gut vor stellen, dass ich die Kernlösung nur an Hand der Zwischentabelle vornehme, die dann auch womöglich mehrfach mit sich selber verknüpft werden müsste. Da spielt die Länge eines verwendbaren Schlüssels eine erhebliche Rolle.
Ohne eine "eigene Existenz" der Zwischentabelle wäre das wohl nicht möglich.

Der Fremdschlüssel in seiner Funktion als Fremdschlüssel würde da erst danach und dann in Kraft treten, wenn ich mir zu den ermittelten Personen auch die Namen holen will.

Weitere Frage: Wenn die Beziehung zwischen A und B angelegt, gelöscht und wieder neu angelegt wird, ist sie dann eine neue Beziehung oder immer noch die alte?]Weitere Frage: Wenn die Beziehung zwischen A und B angelegt, gelöscht und wieder neu angelegt wird, ist sie dann eine neue Beziehung oder immer noch die alte?

Gegenfrage: Wenn man aus seinem langjährigen Arbeitsverhältnis gekündigt wird, nach 10 Monaten aber wieder von der gleichen Firma eingestellt wird: Ist das noch genau der gleiche Job mit gleichen Rechten und Ansprüchen? Es könnte sein ...

MfGA
ebs

[MzKlMu]

Hallo,
ich führe grundsätzlich in jeder Tabelle ein Primärschlüsselfeld, meistens ein Autowert. Egal ob man einen zusammengesetzten PK braucht oder nicht. Die Lehrmeinung ist mir hier egal, da die (meine) Erfahrung gelehrt hat, dass es zweckmäßig ist. Und ein Autowertfeld kostet 4 Byte.
Anbei mal ein Bild.
In der Tabelle BestellPositionen könnte man aus BestellID und ArtikelID einen PK bilden. Aber die Mengen sind hier in einer extra Tabelle (wegen Bestandsermittlung). In der Mengentabelle fehlt noch der Fremdschlüssel zur Nachbestellungstabelle die wie die Bestellpositionstabelle aufgebaut ist. In der Tabelle sind dann 2 Fremdschlüssel wovon immer nur einer gefüllt ist. Mit zusammengesetztem PK hätte ich dann 4 Fremdschlüsselfelder.

[Anhang gelöscht durch Administrator]

[Wurliwurm]

Bei Aufgabenstellungen wie "Wer hat im Zeitraum X mehr als 6 Beziehungen, die länger als 3 Monate dauern + ..." kann ich mir gut vor stellen, dass ich die Kernlösung nur an Hand der Zwischentabelle vornehme, die dann auch womöglich mehrfach mit sich selber verknüpft werden müsste. Da spielt die Länge eines verwendbaren Schlüssels eine erhebliche Rolle.

Ohne Dir jetzt einen mathematischen Beweis ad hoc liefern zu können, meine ich, daß Du auch bei beliebig komplexen Abfragen nur die Nichtschlüssel-Attribute auswertest; der AutoWertID bleibt dabei völlig außen vor. Wenn Du z.B. in einer Subquery auswertest "Wer hat im Zeitraum X mehr als 6 Beziehungen", brauchst Du für "wer" das Attribut "MannID"/"FrauID", für "im Zeitraum x" und "Dauer der Beziehung" Attribute wie "Beziehungsbeginn", "Beziehungsende". Es ist nunmal so, daß der Autowert-Schlüssel in keinerlei Beziehung zu den Nichtschlüsselattributen steht, es besteht keinerlei funktionale Abhängigkeit.

Ohne eine "eigene Existenz" der Zwischentabelle wäre das wohl nicht möglich.

Die Zwischentabelle hat auch bei einem zusammengesetzten Schlüssel eine eigene Existenz! Bloß keine von den Fremdschlüsseln unabhängige Existenz.

Der Fremdschlüssel in seiner Funktion als Fremdschlüssel würde da erst danach und dann in Kraft treten, wenn ich mir zu den ermittelten Personen auch die Namen holen will.

Das ist schon klar. Allerdings ist auch hier der AutoWert-PK der Beziehungstabelle ohne Bedeutung.

Gegenfrage: Wenn man aus seinem langjährigen Arbeitsverhältnis gekündigt wird, nach 10 Monaten aber wieder von der gleichen Firma eingestellt wird

In dem konkreten Fall ist es auf jeden Fall eine neue Beziehung, mit neuer Kündigungsfrist und neuem Gehalt.

[ebs17]

Es ist nunmal so, daß der Autowert-Schlüssel in keinerlei Beziehung zu den Nichtschlüsselattributen steht, es besteht keinerlei funktionale Abhängigkeit.

Es ist nicht so, dass ein Autowert einen Datensatz eindeutig macht (neben anderen möglichen eindeutigen Schlüsseln)??

Es ist nicht so, dass man in einer Abfrage auf die Idee kommen könnte, ein "WHERE X IN (SELECT Y ..."-Konstrukt einzusetzen??
Wie würde man das einfach(!) mit einem Mehrfeldschlüssel umsetzen?
Aus einem Zweifeldschlüssel kann sehr leicht ein Fünffeldschlüssel werden, wenn man eben gezielte Filterungen in der Tabelle vornehmen will. Da zeigt meine Erfahrung, dass ein Ersatzschlüssel aus einem Feld sehr hilfreich sein kann, und wenn mir dieser Ersatzschlüssel hilft, weitere Verschachtelungen von Subselects zu vermeiden und Komplexität der Abfrage in Grenzen zu halten, ist das für mich nachhaltige Funktionalität.

Wenn so etwas in Deiner Praxis nicht vorkommt, muss das nicht zwingend die gesamte Praxis abbilden. Lehrbeispiele ohne öffnende Phantasie zu erstellen halte ich für bedenklich, darauf zu vertrauen für fahrlässig.

Ich würde zustimmen, dass in der eingangs genannten Konstellation (Verknüpfungstabelle nur mit zwei Fremdschlüsseln und keine weiteren Attribute und keine weiteren Tabellenabhängigkeiten) ein gesonderter Autowert-Key verzichtbar ist. An der Stelle stört er aber auch nicht.
In vielen anderen Fällen kann und wird er sich aber als nützlich erweisen.

MfGA
ebs

[Wurliwurm]

Es ist nicht so, dass ein Autowert einen Datensatz eindeutig macht (neben anderen
möglichen eindeutigen Schlüsseln)??

Nein, es ist nicht so. Der Datensatz ist schon vorher eindeutig.

Es ist nicht so, dass man in einer Abfrage auf die Idee kommen könnte, ein "WHERE X IN
(SELECT Y ..."-Konstrukt einzusetzen??

Auf die Idee kommen kann man sicher, aber mir leuchtet es nicht ein, was das bringen
soll. Der Surrogatschlüssel wird m.E. nie in der WHERE-Bedingung ausgewertet. Da müßte ich ein Beispiel sehen.

Wenn so etwas in Deiner Praxis nicht vorkommt, muss das nicht zwingend die gesamte
Praxis abbilden. Lehrbeispiele ohne öffnende Phantasie zu erstellen halte ich für
bedenklich, darauf zu vertrauen für fahrlässig.

Meine Praxis ist durchaus komplex; als technischer SAP-Berater und Entwickler bin ich
Fünffeld-Schlüssel und noch längere durchaus gewohnt. Das SAP-Datenmodell sucht
seinesgleichen, was die Komplexität betrifft. Das Beispiel habe ich mir halt schnell
ausgedacht. Formale Darstellungen in maxmimaler Allgemeinheit sind hier wahrscheinlich noch mehr fehl am Platz.
Gelernt habe früher Sachen wie Anfrageformulierung im Tupelkalkül, Algorithmen zur
Berechnung der transitiven Hülle einer Relation etc..., aber das will ich hier nicht
mehr aufwärmen.

Ich würde zustimmen, dass in der eingangs genannten Konstellation (Verknüpfungstabelle
nur mit zwei Fremdschlüsseln und keine weiteren Attribute und keine weiteren
Tabellenabhängigkeiten) ein gesonderter Autowert-Key verzichtbar ist.

Deshalb habe ich dem auch TE nahegelegt, den Autowert wegzulassen. Vorteil ist, daß
man bei Mehrfeldschlüsseln sofort sieht, was eine Relation ausmacht. Zum Beispiel weiß
man bei der Kombination Kunde/Artikel oder Mitarbeiter/Monat/Fixgehalt sofort, was
gemeint ist. Um Eindeutigkeit beim AutowertID-Key zu bekommen, müßte er ja sowieso
einen eindeutigen Index auf die Fremdschlüsselfelder erzeugen und damit einen
zusätzlichen Index mitschleppen. ]

[ebs17]

Es ist nicht so, dass ein Autowert einen Datensatz eindeutig macht?

Falsche Formulierung: Eindeutig kennzeichnet, nicht macht. Verwendbar wäre er damit schon.

Komplexe Praxis und komplexe Abfragen meinen nicht wirklich das Gleiche, auch ein Fünffachschlüssel läuft letztendlich nur(!) auf einen  JOIN hinaus. Abfragen können aber vielfältiger sein. Ich denke da an Subselects in mehrfach als dreifach geschachtelter Tiefe, wo man ohne Einfeldschlüssel gut und gerne drei Verschachteliungstiefen hinzufügen muss, was der Übersicht und letztendlich auch der Performance erheblich abträglich sein kann.

Darüber hinaus: MzKlMu  hat ja angedeutet, dass es bezüglich Datenmodellierung erweiterte Anforderungen geben kann als eine pure m:n-Beziehung zwischen genau zwei Tabellen. Es bleibt doch eine m:n-Beziehung, wenn zusätzliche Tabellen beziehungsmäßig dazu kommen, oder? Auch könnte die Zuordnung von zwei Fremdschlüsseln zueinander nicht eindeutig sein (z.B. über zeitliche Abhängigkeit). Dann stirbt schon mal dieser PK und wird zu einem längeren Schlüssel.

Ernsthafte Gedanken über ein "sichtbares Beispiel" (zumal für ein beliebig erstelltes Lehrbeispiel) mache ich mir erst dann, wenn eine glaubhaft hinterlegte nennenswerte Belohnung vorhanden ist. Einer Meinung pur kann ich meine Meinung gegenüberstellen. Wer hat davon einen Nutzen?

Formale Darstellungen in maxmimaler Allgemeinheit sind hier wahrscheinlich noch mehr fehl am Platz.

Davon kannst Du ausgehen. Wer Prinzipien errichtet, wo sie unnötig bis falsch sind, kann dadurch leicht in Kritik geraten.

MfGA
ebs

[Wurliwurm]

Komplexe Praxis und komplexe Abfragen meinen nicht wirklich das Gleiche, auch ein
Fünffachschlüssel läuft letztendlich nur(!) auf einen JOIN hinaus.

Bei allen relationalen Beziehungen geht es letztendlich um JOIN! Und um einen JOIN
machen zu können, braucht man (letztendlich) auch gar keine Schlüssel in den Tabellen.

Abfragen können aber vielfältiger sein. Ich denke da an Subselects in mehrfach als
dreifach geschachtelter Tiefe, wo man ohne Einfeldschlüssel gut und gerne drei
Verschachtelungstiefen hinzufügen muss, was der Übersicht und letztendlich auch der
Performance erheblich abträglich sein kann.

Angenommen, Du hast recht: Es würde dann aber genauso gehen, mit einem
Nichtschlüsselfeld, welches automatisch inkrementiert wird und welches eindeutig
indexiert ist.

Ich hatte mal gelernt, daß man Subselects grundsätzlich immer auch in äquivalente
Abfragen mit JOIN umformulieren kann, mit Ausnahme von solchen Abfragen, wo die
Unterabfrage nicht korreliert ist und in der Unterabfrage aggregiert wird. Im
Datenbank-Lehrbuch von Kemper/Eickler gibt es z.B. Übungsaufgaben, wo genau das
gemacht werden muß. Aber mangels ausstehender Belohnung werde ich das nicht
herauskramen, das soll hier ja auch kein Seminar mit Hausarbeit und Scheinerwerb sein.

Deshalb frage ich eher praktisch: Solche extrem tief verschachtelten Subselects sind
schon sehr exotisch, von Übersicht kann da schon von Haus aus nicht die Rede sein. Das
Performancethema im Zusammenhang mit MS Access ist sowieso nicht relevant, oder wo
gibt es Anwendungen in Access wo riesige Datenmengen gespeichert sind und solche
Abfragen superschnell laufen müssen? Im professionellen OLAP-Bereich gibt es dafür
Business-Warehouses, wo die Daten unnormalisiert und auch aggregiert vorgehalten
werden.

Darüber hinaus: MzKlMu  hat ja angedeutet, dass es bezüglich Datenmodellierung
erweiterte Anforderungen geben kann als eine pure m:n-Beziehung zwischen genau zwei
Tabellen. Es bleibt doch eine m:n-Beziehung, wenn zusätzliche Tabellen beziehungsmäßig
dazu kommen, oder?

Ja natürlich, wenn der Faktor Zeit zum Beispiel dazu kommt, dann kann es sein, daß die
Schlüssel erweitert werden muß. Aber, das möchte ich nochmals betonen, das Problem
liegt in der Sache und wird nicht dadurch geheilt, indem man einen zusätzlichen
AutoID-Schlüssel hinzugefügt.

Ernsthafte Gedanken über ein "sichtbares Beispiel" (zumal für ein beliebig erstelltes
Lehrbeispiel) mache ich mir erst dann, wenn eine glaubhaft hinterlegte nennenswerte
Belohnung vorhanden ist. Einer Meinung pur kann ich meine Meinung gegenüberstellen.
Wer hat davon einen Nutzen?

Ein Belohnung kann ich Dir nicht anbieten. Dann solltest Du aber nicht mein kleines
Beispiel, welches ich ohne jede Aussicht auf Belohnung hingeschrieben habe, als zu
speziell und simpel abqualifizieren. Um "Meinung pur" geht es aber nicht, sondern
prinzipiell schon um beweisbare Zusammenhänge. Im SoHo-Bereich ist die Fragestellung
aber schon ähnlich relevant wie die Frage, ob ein Kleinwagen unbedingt immer einen
Spoiler haben muß oder nicht.

Wer Prinzipien errichtet, wo sie unnötig bis falsch sind, kann dadurch leicht in
Kritik geraten.

Das sehe ich genauso, aber in Bezug auf die Aussage "Eine m:n Beziehung braucht immer
einen AutoWert-PK".

Mein Argument war, daß es dem Lernenden und der Verständlichkeit von Datenmodellen
dient, wenn man Kardinalitäten von m:n analog zum Entity-Relationship-Diagramm auch in
der Datenbank so modelliert.

[ebs17]

Solche extrem tief verschachtelten Subselects sind schon sehr exotisch ...

Ist das so? Es ist meine Erfahrung und meine Überzeugung, dass eine Verarbeitung per SQL mit den Methoden der Massendatenverarbeitung sehr zügig läuft, insbesondere wenn man einige dazu gehörige Regeln einhält. Aber selbst schlechte SQL-Anweisungen sind recht oft deutlich schneller, als wenn man alternativ eine prozedurale Abarbeitung (VBA) verwenden würde.
Da ist es dann ein logischer Schritt, zunehmend Verarbeitungslogik und -schritte in eine Abfrage zu legen, wobei sich das nicht auf Beziehungen beschränken will und wird.

Das Performancethema im Zusammenhang mit MS Access ist sowieso nicht relevant, oder wo gibt es Anwendungen in Access wo riesige Datenmengen gespeichert sind und solche Abfragen superschnell laufen müssen?

Der erste Teilsatz verdeutlicht eine enorme Hochnäsigkeit oder Unkenntnis. Warum lässt Du Dich überhaupt herunter in die Niederungen von Access?

Was riesige Datenmengen sind, darüber kann man diskutieren. Aber immerhin verwendet man recht oft Access-Frontends für DBMS, und diese Datenbanken sind dann immer noch die gleichen. Darüber hinaus müssen recht oft Daten aus den professionellen DB's in Access oder gar in Excel verwurstet werden, weil die Profi-DB's oder das zuständige Personal nicht genügend den Anforderungen der Fachabteilungen entsprechen.

Und: Auch ein Kleinwagen will und kann auf der Autobahn fahren, und zwar nicht nur auf der rechten Spur. Performance ist immer ein Thema, selbst bei einem Seifenkistenrennen.

MfGA
ebs

[Wurliwurm]

Der erste Teilsatz verdeutlicht eine enorme Hochnäsigkeit oder Unkenntnis. Warum lässt Du Dich überhaupt herunter in die Niederungen von Access?

Weil ich regelmäßig etwas brauche zwischen einer großen Datenbank und Excel. Dafür ist es super. Als Ersatz für eine große Datenbank ist es ungeeignet. Nenn mich hochnäsig, dann sage ich "Wenn das einzige Werkzeug, das Du kennst, ein Hammer ist, dann sieht jedes Problem aus wie ein Nagel". Vielleicht findet es der Excel-Jockey als hochnäsig, wenn man ihm sagt, daß Excel toll zum Rechnen ist, aber nicht so toll ist zur Datenspeicherung und man dafür dieses komische Access nehmen soll. Ich komme übrigens auch mit Excel gut zurecht.

Bei Seifenkistenrennen ist die Performance vielleicht auch wichtig, aber für die Autobahn ist ein PKW besser, da sollte man nicht anfangen, die Seifenkiste zu tunen.

Profi-DB's oder das zuständige Personal nicht genügend den Anforderungen der Fachabteilungen entsprechen

Die Fachabteilungen sind naiv und meinen, daß Datenschiefstände durch einfaches Ausbessern wie im Excel korrigierbar sind. Und ahnen nicht die Probleme, die im Multiuserzugriff entstehen können.