Access-o-Mania

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:

  ZitatEine 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 (http://office.microsoft.com/de-de/access-help/beziehungen-in-einer-access-datenbank-mdb-HP005188444.aspx)

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

Danke für eure Hilfe!

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.

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.

Zitat von: Wurliwurm am Mai 30, 2012, 11:52:19
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?

Siehe Zusammengesetzten Index anlegen (http://www.ardiman.de/datenbanken/grundlagen/tabellen.html#SEC1).

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 ...
... WHERE ID IN (SELECT IDX ...
... funktioniert übersichtlich nur mit einem Einfeldschlüssel.

MfGA
ebs

Zitat von: ebs17 am Mai 30, 2012, 13:24:23
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?

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.

ZitatWeitere 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

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]

Zitat von: ebs17 am Mai 30, 2012, 18:14:30
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.

Zitat
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.

Zitat
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.

ZitatGegenfrage: 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.

ZitatEs 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

Zitat von: ebs17 am Mai 31, 2012, 12:20:32
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.

Zitat
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.

Zitat
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.

Zitat
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. ]

ZitatEs 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?

Zitat
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

Zitat von: ebs17 am Juni 01, 2012, 00:26:51
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.

Zitat
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.

Zitat
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.

Zitat

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.

Zitat
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.

ZitatSolche 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.

ZitatDas 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

Zitat von: ebs17 am Juni 01, 2012, 11:57:52
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.

Zitat
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.

Zitat von: ebs17 am Juni 01, 2012, 11:57:52
Und: Auch ein Kleinwagen will und kann auf der Autobahn fahren, und zwar nicht nur auf der rechten Spur

Wie wichtig ist dafür der Spoiler?

Da ein Kleinwagen leichter als eine Reiselimousine ist, ist der Effekt des Spoilers bei höheren Geschwindigkeiten wesentlicher, um Bodenhaftung zu halten.

Access ist natürlich kein Ersatz für eine große Datenbank (wer behauptet so etwas?). Es bietet aber trotzdem einiges, was man auch nutzen kann (und daher kennen sollte, statt sich abschätzig zu äußern).

Nebenbei: In drei und mehr Ebenen verschachtelte Subselects sind nicht extrem tief, wenn man sich vor Augen hält, dass nach Spezifikation für Acc2000/Jet 4 50 Ebenen möglich sind. Da kratzt man allenfalls an der Oberfläche und ist weit davon entfernt, vorhandene Möglichkeiten auszureizen.

Im Ernst: Mit Abfragen (SQL) kann man etwas mehr bewerkstelligen, als Daten, die man durch Datenmodellierung und Normalisierung getrennt hat, wieder aneinander zu hängen und dann etwas zu filtern und sortieren.

MfGA
ebs

Zitat von: ebs17 am Juni 02, 2012, 16:01:36
Da ein Kleinwagen leichter als eine Reiselimousine ist, ist der Effekt des Spoilers bei höheren Geschwindigkeiten wesentlicher, um Bodenhaftung zu halten.

Was ich mit dem Vergleich (der wie jeder andere Vergleich hinkt) meinte: Ein Kleinwagen wird nicht zum Sportwagen, trotz allem Tuning wie Spoiler o.ä. . Der Unterschied ist unter der Motorhaube. Ich hoffe, das empfindest Du nicht als hochnäsig, wenn ich nochmals betone, daß es bei typischen Access-Anwendungen relativ unkritisch ist, ob das Ergebnis einer "extensiven Abfrage" nach 2 oder 20 Sekunden vorliegt. Wichtiger ist ein übersichtliches Datenmodell, wo man zur Not auch mal händisch eingreifen kann.

50 Ebenen für Subselects sind natürlich ebenso unrealistisch wie die Grenze von 256 Tabellen pro File und 256 Spalten pro Tabelle. Solche Datenbank-Dimensionen gibt es, aber da wird man Access nicht verwenden.

Zitat
Im Ernst: Mit Abfragen (SQL) kann man etwas mehr bewerkstelligen, als Daten, die man durch Datenmodellierung und Normalisierung getrennt hat, wieder aneinander zu hängen und dann etwas zu filtern und sortieren.

Latürnich. Es kommen Aggregatfunktionen und arithmetische Ausdrücke hinzu. Aber das hat mit dem Primärschlüssel einer Tabelle nichts zu tun.

Ich habe über Dein Argument nachgedacht, daß es bei Subselects ohne einen Einfeld-Index kaum möglich ist, die Ergebnisse einer inneren Abfrage mit "IN" in der äußeren Abfrage zu verwenden(1). Es stimmt.

Meine Idee dazu weiter oben hast Du aber nicht kommentiert:

Zitat
Es würde dann aber genauso gehen, mit einem
Nichtschlüsselfeld, welches automatisch inkrementiert wird und welches eindeutig
indexiert ist.

Warum kann man, wenn man "extensive Abfragen" machen will, nicht einfach so ein Indexfeld nachrüsten? Das wäre im Sinne der Normalisierung klarer, weil dieses Feld vom Schlüssel (zusammengesetzen Schlüssel!), nur vom Schlüssel und von nichts als dem Schlüssel abhängig wäre. Während der Autowert-Key gegen die 2. Normalform verstößt.


Ich habe auch noch ein bißchen gegoogelt und erlaube mir, folgendes Zitat einzufügen.

http://www.ben-morris.com/identity-surrogate-vs-composite-keys-in-sql-server

Zitat
...Many people point to a potential performance bonus in using an identity column, but a surrogate key will not improve performance in most cases unless you are selecting records by the surrogate key alone...

...A surrogate key might seem like a tidier solution than a key based on more than one column, but they do not simplify data design – using an identity column over a composite key actually complicates the data design. In order to guarantee data integrity you will have to add a constraint and an index onto the columns that would form the composite key as well as having to create an identity column and primary key...

...There is a distinction between those tables that define entities and those that relate entities.
A table that defines entities is one that describes a single entity within your problem domain, say a person or a product. In this case, a surrogate primary key may well be more appropriate than using the natural key as it is will not be vulnerable to any changes in the characteristics of the entities over time.

However, if you want to relate people and products in a table then this is a different story. The natural key in this case would be a combination of the people and product primary keys. Adding an extra surrogate key would only serve to complicate the design and undermine data integrity without bringing any benefits in terms of performance or maintenance...

Schöner Artikel. Der bringt alles auf den Punkt, was ich gemeint habe.

(1) Damit meine ich nicht nur Zwei-Ebenen-Subqueries.

ZitatNichtschlüsselfeld, welches automatisch inkrementiert wird und welches eindeutig indexiert ist

Das wäre natürlich auch in etlichen Fällen verwendbar. In einer Verknüpfungstabelle muss aber die Kombination der Fremdschlüssel nicht zwingend eindeutig sein, sie wäre dann als Primärschlüssel ungeeignet. Auf diesen Hinweis bist Du nicht eingegangen, wie auch auf einige weitere.

Und ich wiederhole: Performance ist immer ein Thema.
Was in diesem Zusammenhang als kritisch zu sehen ist (Frust durch Warten, (Selbst-)Mordgedanken) lasse ich uninterpretiert. Erwartungshaltung und Akzeptanz können höchst unterschiedlich ausgeprägt sein.

Eine etwas längere Abfragedefinition oder aber ein längerer Code haben nun aber auch keine direkte Abhängigkeit zur Laufzeit der Abarbeitung.

MfGA
ebs

Zitat von: ebs17 am Juni 04, 2012, 11:05:50
Was in diesem Zusammenhang als kritisch zu sehen ist (Frust durch Warten, (Selbst-)Mordgedanken) lasse ich uninterpretiert.

(Selbst-)Mordgedanken wegen länger laufenden Abfragen sind eher ein Fall für den Psychologen. "Kritisch" meine ich rein objektiv. Eine
Abfrage für die Geschäftsführersitzung bei Amazon muß rechtzeitig fertig sein, eine Abfrage nach einer Zugverbindung muß schnell kommen. Ich hatte weiter ja oben ja schon angedeutet, daß es dafür zig Möglichkeiten gibt wie Hauptspeicherpuffer, Materialized Views, Data Warehouses etc.pp., wo die Daten auch denormalisiert und aggregiert vorgehalten werden. In Bezug auf die Eingangsfrage reduziert sich hier die Fragestellung auf: Wieviel bringt ein extra Autowert-PK in einer m:n Relation für die Performance?

Zitat
Das wäre natürlich auch in etlichen Fällen verwendbar.

In welchen Fällen wäre es nicht verwendbar und im Gegensatz dazu ein einzelner Autowert-PK die Lösung?

Zitat
In einer Verknüpfungstabelle muss aber die Kombination der Fremdschlüssel nicht zwingend eindeutig sein, sie wäre dann als Primärschlüssel
ungeeignet.

Diese Frage hatte ich weiter oben schon beantwortet. Wenn der Faktor Zeit zum Beispiel dazu kommt, dann muß der
Schlüssel erweitert werden. Das Problem liegt in der Sache und wird nicht dadurch geheilt, indem man einen zusätzlichen
AutoID-Schlüssel hinzugefügt. Durch das Setzen eines zusammengesetzten Primärschlüssel wird ein eindeutiger Index erzeugt. Und durch das
Ergänzen mit einem Sekundärindex könnten auch die Unterabfragen genauso formuliert werden und wären genauso schnell.

Zitat
Auf diesen Hinweis bist Du nicht eingegangen, wie auch auf einige weitere.

Bitte die "einigen weiteren" Hinweise benennen.

Zitat
Eine etwas längere Abfragedefinition oder aber ein längerer Code haben nun aber auch keine direkte Abhängigkeit zur Laufzeit der Abarbeitung.

Natürlich hängt das von vielen Faktoren ab, aber hier reduziert sich das auf die Frage, wie Indexe beitragen können zu Performance. Außer in
den Fällen, die Du genannt hast (korrelierte Unterabfragen mit "SELECT IN" aus einer nichtaggregierten Unterabfrage) kann der Index
Autowert-PK nicht benutzt werden.

Hallo Kollegen,

ich habe euren Diskurs verfolgt, mir fehlt aber zu einigen, sicher spaß gemeinten Vergleichen der sinnhafte praktische Zugang .

eigentlich ist doch schon alles gesagt:

in #1 Klaus:  

Zitat...ich würde als PK einen Autwert verwenden. Ein einzelner PK ist im weiteren Verlauf der Entwicklung der DB leichter zu handhaben.

hierbei ist "weiteren Verlauf der Entwicklung der DB" zu beachten, denn wie oft kommt es vor, dass zu 2 Schlüsselfeldern noch weitere Felder hinzukommen,

siehe 4# ebs

Zitat...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

somit gibt es (mindestens) 2 Gründe, in einer m:n Tabelle einen zusätzlichen PK-Wert einzuführen.

sorry, aber alles weitere ist ein ziemlich akademisches Geplänkel, denn man braucht doch diese Gründe nicht zu hinterfragen; die praktische Frage an Wurliwurm ist doch: was schadet es denn ;)

Gruß Oma

Zitat von: oma am Juni 04, 2012, 16:43:31
eigentlich ist doch schon alles gesagt:

Hast Du nur die eine Hälfte gelesen oder nur die eine Hälfte verstanden? Es fehlt:

Zitat von: wurliwurm
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.

Zitat von: webseite
Adding an extra surrogate key would only serve to complicate the design and undermine data integrity without bringing any benefits in terms of performance or maintenance...

Zitat von: oma
hierbei ist "weiteren Verlauf der Entwicklung der DB" zu beachten, denn wie oft kommt es vor, dass zu 2 Schlüsselfeldern noch weitere Felder hinzukommen,

Dann ändert sich die Kardinalität der Beziehung so grundlegend, daß der Schlüssel nicht mehr stimmt und geändert werden muß.

Zitat von: ebsWenn man etwas extensiver Abfragen schreibt, ist es durchaus hilfreich, wenn man ein Feld als Schlüssel zum Verknüpfen verwenden kann als einen Mehrfelderindex

Ist mit einem Sekundärschlüssel sauberer lösbar, siehe weiter oben.

Zitat von: oma
die praktische Frage an Wurliwurm ist doch: was schadet es denn ;)

Ist auch schon gesagt: Es verletzt die Normalformen und macht die Struktur weniger überschaubar.

I

Da gab es doch ganz am Anfang eine klar und deutlich definierte Frage:

ZitatWas ist der Primärschlüssel der Zwischentabelle? Muss ich ein AutoID einfügen oder geht auch folgendes: Zitat ...

Ein AutoWert-Feld als PK einzuführen ist ein KANN aber nicht unbedingt ein MUSS - die Erklärung des Herstellers in der zitierten Quelle
ist eine Lösung bei der jedoch eine Kombination der beiden Fremdschlüssel nur einmalig vorkommen darf.

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

Markiere im Tabellenentwurf beide Fremdschlüsselfelder und klicke auf das Schlüsselsymbol um diese beiden Felder zu einem PK zu machen.

...wäre es denn nicht viel einfacher einem Fragesteller eine klare und deutlich verständliche Antwort zu geben anstatt ellenlange Diskussionen um des Kaisers Bart zu führen?

Zitat...wäre es denn nicht viel einfacher einem Fragesteller eine klare und deutlich verständliche Antwort zu geben

Das ist aber längst erfolgt: Per Link, wo sogar Bilder anzuschauen sind.

MfGA
ebs

Hallo ebs

...stimmt, ist mir wegen des Farbfehlers auf meinem alten Monitor leider nicht gleich beim ersten Lesedurchgang aufgefallen.  :-[
Meine freundlich gemeinte Kritik war jedoch nicht in deine Richtung ausgelegt.  ;)

Hallo,

@wurliwurm: 

ZitatHast Du nur die eine Hälfte gelesen oder nur die eine Hälfte verstanden?

Ich finde solche Bemerkungen unfreundlich.
Ich habe alles gelesen und nicht alles verstanden, was auch teilweise an Formulierungen lag.
Wir hatten uns aber schon einmal verständigt, das dein Wissen über das der übrigen Forumsteilnehmer liegt und du insofern auch Geduld mit Unwissenden aufbringen musst ;D

Ansonsten teile ich die Auffassung das mit #1, #4 und #7 für Johnny sachgerechte Antworten gegegeben sind.

Gruß Oma

Zitat von: oma am Juni 05, 2012, 09:05:26
Ich finde solche Bemerkungen unfreundlich.

Entschuldigung! Daß ich hier manchmal rechthaberisch rüberkomme, weiß ich und mag das auch nicht.

Wenn ich sonst ruhig bin und nicht rechthaberisch rüberkomme, dann nimm einfach an:
-die Antworten der anderen Forumsteilnehmer sind richtig oder
-ich weiß es auch nicht (besser)

Im dem Fall, wo ich überzeugt bin, Recht zu haben und meine, das auch bewiesen zu haben, ärgert mich die Formulierungen "akademisches Geplänkel".

Ich kann nur versuchen, das mit einem Vergleich zu verdeutlichen: Der Lehrer in der Schule bringt Deinem Kind bei, jeder arithmetische Ausdruck müsse grundsätzlich und immer mit 1 malgenommen werden. Warum: Er mache das schon immer so und habe immer richtige Ergebnisse. Du behauptest, daß das nicht nötig sei und versuchst ihm das zu beweisen. Als Antwort bekommst Du, daß das akademisches Geplänkel ist, ein Streit um "Kaiser´s Bart" und fragt Dich, was Dich denn daran stört, alle Ergebnisse sind doch richtig ...

Die Anleitung zum Anlegen des zusammengesetzten Schlüssels habe ich nicht gelesen, weil ich davon ausgehe, daß sie richtig ist. Im übrigen bin ich der Meinung, daß die von dir genannten Antworten von mir sachgerecht widerlegt sind.

Der Autowert-PK bei m:n-Tabellen ist einfach schlechter Stil und ich wenn er wieder mit Zusätzen wie "grundsätzlich", "immer", "auf jeden Fall" empfohlen wird, werde ich das hinterfragen.

Hallo Johannes Wurliwurm,

Entschuldigung ist natürlich angenommen-zumal ich auch manchmal im "Streitgespräch" zu unnötigen Sticheleien neige.

Die Bemerkung  "...ellenlange Diskussionen um des Kaisers Bart zu führen?" war wohl auch auf die doch ziemlich langatmige und mit verwegenen Beispielen gespickte Diskussion, die auch den Fragesteller wahrscheinlich nicht mehr interessiert hat (da er sich nicht mehr geäußert hat)

ZitatDer Autowert-PK bei m:n-Tabellen ist einfach schlechter Stil und ich wenn er wieder mit Zusätzen wie "grundsätzlich", "immer", "auf jeden Fall" empfohlen wird, werde ich das hinterfragen.

Recht hast du, wenn man das mit grundsätzlich und immer Im Sinne von "immer" und "absolut richtig" behauptet wird.

Ich habe allerdings  ein triviales Beispiel, dass für mich eine Sinnfälligkeit eines Auto-PK in einer m:n - Tabelle ergab:

Ich hatte ( sinngemäß) ein Problem für Projekte und Mitarbeiter, wobei die Mitarbeiter in verschiedenen Projekten arbeiten können. Die Tabelle war damit

tblProjektMitarbeiter: Projekt_ID, Mitarbeiter_ID

Später kam der Wunsch hinzu , den Beginn der Mitarbeit des Mitarbeiters an ein Projekt zu speichern. Somit wurde aus der Tabelle:

tblProjektMitarbeiter: PM_ID, Projekt_ID, Mitarbeiter_ID, DatumBeginn, Bemerkung

Deine Bemerkungen:

ZitatDann ändert sich die Kardinalität der Beziehung so grundlegend, daß der Schlüssel nicht mehr stimmt und geändert werden muß. Es verletzt die Normalformen und macht die Struktur weniger überschaubar.

habe ich überhaupt nicht in Betracht gezogen, da die Normalformen wichtige, aber nicht in jedem Fall immer einzuhaltende Bedingungen sind und von wenig überschaubar kann in diesem Fall auch keine Rede sein.
Der "Zugriff" auf einen bestimmten Datensatz war somit mit einem Schlüssel möglich (natürlich wäre es auch mit 2 Schlüssel gegangen) und die Lösung war einfach und praktikabel (auch wenn du anführst: weit ab von der Theorie) ;)

Gruß Oma

Zitat von: oma am Juni 05, 2012, 17:00:05
Später kam der Wunsch hinzu , den Beginn der Mitarbeit des Mitarbeiters an ein Projekt zu speichern. Somit wurde aus der Tabelle:
tblProjektMitarbeiter: PM_ID, Projekt_ID, Mitarbeiter_ID, DatumBeginn, Bemerkung

Hallo Oma,

Der extra ID-Schlüssel wäre in dem Fall überhaupt nicht nötig gewesen! Weil sich an der Relation
überhaupt nichts ändert, es bleibt eine m:n-Beziehung. An dem Schlüssel (PM_ID, Projekt_ID)
könnten neben DatumBeginn und Bemerkung beliebig viele Nichschlüsselattribute hängen wie
Tarif, geleistete Stunden, LeistungsBewertung und so weiter.

Die Kardinalität ändert erst dann, wenn etwa ein Faktor Aufgabe etwa so hinzukommen soll
tblProjektMitarbeiterAufgabe: *Projekt_ID, *Mitarbeiter_ID, *AufgabeID, ... -> Nichtschlüsselattribute
sprich pro Projekt/Mitarbeiter/Aufgabe die Daten genau aufgeschlüsselt werden sollen.

Das wäre dann eher eine neue Tochtertabelle tblProjektMitarbeiterAufgabe, die mit der Tabelle tblProjektMitarbeiter per n:1 verknüpft wäre in

dem Sinne:
FOREIGN KEY(ProjektID, Mitarbeiter_ID) REFERENCES tblProjektMitarbeiter(ProjektID, Mitarbeiter_ID)

So eine weitere Verschachtelungsebene ist m.E. wirklich nötig, wenn die Aufgaben extra erfasst werden müssen. Ein Join müßte natürlich immer über beide Attribute erfolgen. Das finde ich sauber, ich kenne und mache das immer so.

Hatte ich aber eigentlich oben alles schon langatmig ausgeführt ... war aber scheinbar leider nur für mich selbst ;-)
Den ursprünglichen Threadersteller haben wir vergrault, das ist mir schon klar.

Johannes
-----
Im Disput. – Wenn man zugleich einer anderen Meinung widerspricht und dabei seine eigene entwickelt, so verrückt gewöhnlich die fortwährende Rücksicht auf die andere Meinung die natürliche Haltung der eigenen: sie erscheint absichtlicher, schärfer, vielleicht etwas übertrieben.
Nietzsche - Menschliches, Allzumenschliches

Hallo,
wollte mich noch mal kurz einmischen. Auch renomierte Datenbankentwickler verwenden in Ihren Beispielen einen extra Autowert.
Z.B. Allen Browne. Was natürlich nicht zwangsläufig heist, dass es richtig ist.

Microsoft Access Tips for Casual Users (http://allenbrowne.com/casu-23.html)

Da solche Links in den Foren sehr verbreitet sind bzw. werden, muss man sich also nicht wundern.
Insofern, fühle ich mich mit meiner Empfehlung einen Autowert zu verwenden in guter Gesellschaft.

Ich möchte auf keinen Fall die Diskussion von vorne beginnen, ich bin fachlich nicht in der Lage das so tiefgründig zu betrachten und zu begründen.
Ich beteilige mich schon sehr lange an verschiedenen Access Foren und habe die Erfahrung gemacht, dass auch User die ganz konsequent auf Normalisierung achten auch einen zusätzlichen Autowert empfehlen. Diese Erfahrung versuche ich weiterzugeben. Dass das nicht immer richtig ist/sein muss ist mir auch klar.

Aber dazu gibt es ja solche Foren, möge jeder sein eigenes Fazit aus solchen Diskussionen ziehen. Wobei man natürlich darauf achten sollte, das richtige Fazit zu ziehen.  ;D ;D

Ich persönlich würde zwischenzeitlich bei einer einfachen n:m Tabelle auf den Autowert verzichten.

Zitat von: MzKlMu am Juni 05, 2012, 19:32:12
Da solche Links in den Foren sehr verbreitet sind bzw. werden, muss man sich also nicht wundern.

Ich habe auch schon intensiv gegoogelt dazu. Allerdings habe ich nirgendwo eine befriedigende Erklärung dazu gefunden, WARUM das so empfohlen wird. In der Tat scheint das mit Autowert-PK so üblich zu sein, vielleicht jeder es vom anderen kritiklos abschaut. So ähnlich wie bei der Sprache, wo falsche Grammatik sich oft durchsetzt, obwohl sich die Deutschlehrer die Haare raufen.