Office: (Office 365) Tabellen und Beziehung richtig realisieren

Grundlegend weiß ich mittlerweile wie Beziehungen zu verknüpfen sind und wie sie so arbeiten.
Was mir allerdings immer Probleme macht sind die Grundgedanken, wo man welche Tabelle mit welcher anderen Tabelle verknüpft, bzw. was die Haupttabelle und welches die Nebentabelle ist.
Ich denke da an ehesten an n:m Beziehungen, bei 1:n ist ja in der Regel nicht so schwer.

Ich habe zum Beispiel aktuell die Sache, dass ich Händlerpreise eintragen möchte und habe sie jetzt schon zweimal komplett umgestellt.
Ich habe die Händler als Tabelle, die Artikel als Tabelle und die Preise als Tabelle. Bei den Preisen habe ich noch verknüpfte Tabellen über Lieferart, Einheiten usw. (was aber nicht das Problem sein sollte).

Nun hatte ich erst die Preise als "Haupttabelle" gewählt und dann Händler und Artikel als Nebentabelle. Da hat es aber nicht so recht geklappt (was aber nach heutiger Überlegung vermutlich am falschen Umgang mit dem Formular und den Unterformularen lag

Dann habe ich das ganze "umgestellt" nach Artikeln als Haupttabelle mit Preisen und Händler als Nebentabelle. Aber das geht auch nicht so auf.

Ergebnis soll halt sein, dass man ein Formular bekommt, wo man einen Händler (um z.B. Preise auf Rechnungen schnell zu prüfen) oder auf einem anderen Formular den Artikel (Um nach den günstigsten Anbieter eines Artikels zu schauen) auswählt und dann in einer Liste alle Preise sieht, bzw. Artikel und Preise oder Händler und Preise.

Aber ich tu mich eben schwer damit zu entscheiden, welches die "Verbindungstabelle" darstellt für diese M:N Beziehungen, oder ob in "der Mitte" überhaupt eine "richtige" Tabelle stehen sollte, oder diese im Prinzip nur ID-Verbindungen sein sollten und alles hier zusammenkommt..

Mich würde das jetzt einfach mal interessieren, wie ihr Grundsätzlich an eine solche Beziehungskutsche geht. Welche Gedanken ihr euch macht um zu einem funktionierenden Ergebnis zu kommen. Oder denke ich da einfach Grundsätzlich falsch?

Ferner würde mich noch interessieren, ob Beziehungen in einer Datenbank "nur einmal" bestehen dürfen/sollen, oder ob man Tabellen auch mal ganz anders Verbinden kann/muß um ein anderes Ergebnis zu erzielen. Scheint mir zwar nicht logisch, aber vielleicht ist dem ja so. Ich frage nur, weil man die Beziehungen ja immer abspeichert.. Vielleicht kann man ja verschiedene Beziehungen abspeichern und es ist mir bisher noch nie aufgefallen :D

Vielen Dank

 

Hallo,
die Beziehungen zwischen den Tabellen dienen zu allererst dazu die DB konsistent zu halten. Es kann keinen ArtikelLieferantenpreis geben, wenn es den Artikel in der Artikeltabelle und den Lieferant nicht in der Lieferantentabelle gibt.

Lieferanten und Artikel können dagegen erstmal unabhängig erfasst werden.
Also ein Formular für die Artikelpflege, ein Formular für die Lieferantenpflege.
Dann ein Formular zur Erfassung der Preise, wobei im Kopf über Kombinationsfelder der Artikel und der Lieferant ausgewählt werden. (Zweispaltige Kombifelder, damit auch der Lieferantenname, bzw. die Artikelbezeichnung zu sehen ist.) Die Datenherkunft der Kombinationsfelder sollte dabei eine Abfrage auf den Artikel, bzw. Lieferantenstamm sein.

Alles weitere ist wieder eine Sache von passenden Abfragen. Dabei muss man nicht die gespeicherten Beziehungen der Tabellen als gegeben hinnehmen. Sie werden nur von Access im Abfrageentwurf vorgeschlagen. Sie lassen sich dort durch Anklicken und der Taste Entf nur für diese spezielle Abfrage löschen. Ebenso kann man auch komplett andere Beziehungen in einer Abfrage erstellen. Weichen die Beziehungen, insbesondere m:n von den Tabellenbeziehungen ab, kann man unter Umständen in diesen Abfragen die Daten nicht pflegen, weil sie nicht der referentiellen Integrität entsprechen.

 

Danke für die Erklärung. Jetzt hat es endlich geklappt. Diesmal kann ich auch Daten in den Nebentabellen eintragen, was vorher nicht ging. Wobei ich auch nicht wirklich weiß, was ich da wohl verkehrt gemacht habe.

Für mich noch nicht ganz klar, wann ich in einem Formular eine "Datensatzherkunft" angeben soll und wann nicht. Kann hier aber vermutlich auch nicht mit ein paar Worten geklärt werden :)
Auch das mit den Abfragen ist glaube ich noch mal eine Recherche wert, weil ich die vermutlich viel zu Stiefmütterlich behandle als "Sortierhilfe". Ich bin noch nicht dahinter gekommen, ob in einer Abfrage - z. B. wie diese - Alle Elemente aller Tabellen die in dem Formular stehen enthalten sein müssen. Das hatte ich nämlich beim ersten Mal gemacht und hat irgendwie gar nicht geklappt..
Diesmal habe ich eben Lieferanten und Artikel in jeweils einer Abfrage gemacht und scheint ja geklappt zu haben. Ebenfalls noch etwas, was ich vertiefen muß.. Wie ich immer Sage.. Access ist halt kein Word :D

Die Kernfrage ist aber noch herauszuknobeln wie die Beziehungen am besten aufzulösen sind auch bei zukünftigen Projekten.

Ach, etwas ist mir auch aufgefallen: Du hast da bei ArtikelLieferantenPreise zwei Primärschlüssel(?) vergeben. Da wüsste ich jetzt gar nicht (mehr) wie man das macht und ob das wirklich nötig ist. Ich nutze in jeder Tabelle eine ID als Primärschlüssel.
Wenn man zwei Schlüssel ansetzt kann man vermutlich den Datensatz noch genauer Identifizieren, oder?
Wobei ich mich jetzt - bei dieser kleinen Datenbank - frage, was passiert, wenn ich von einem Lieferanten einen zweiten Preis für den selben Artikel eingeben würde? Dann würde es doch einen Konflikt geben, oder?
In meiner Datenbank soll halt noch ein Gültigkeitsdatum von Bis eingebaut werden, damit man auch einen Preisverlauf über einen bestimmten Zeitraum abfragen kann. Ist auch für die Kalkulation hinterher interessant. Allerdings sind da noch viele Steine im Weg, dass man dann ja auch das "Enddatum" manuell setzen muß und wie das alles von statten gehen soll.. Man wächst halt mit den Herausforderungen :)

 

Dort trägt man den Namen der Abfrage ein, welche die Grundlage für das Formular ist. Generiert man ein Formular mit dem Assistenten, trägt Access dort die generierte Abfrage als SQL-Statement ein. Wenn man dann dort auf die 3 Punkte klickt, öffnet sich der Abfrageassistent in dem man die Abfrage auch bearbeiten kann. So lernt man nebenbei noch etwas SQL.

Alle Felder für ein Formular in eine Abfrage zu packen ist bei 1:n und m:n Beziehungen eher kontraproduktiv. Da kannst Du besser mit Haupt- und Unterformularen arbeiten, die dann auf jeweils passend gefilterten Abfragen basieren und dann über die Schlüsselfelder verbunden werden.

Betrachte die Beziehungen zwischen den Tabellen als "Datenpolizei". Sie definieren den datentechnischen Zusammenhang der Tabellen und gewährleisten somit, dass Datensätze nicht ungewollt doppelt sind oder Reste in Untertabellen übrig bleiben, wenn ein übergeordneter Datensatz geändert, bzw. gelöscht wird (Änderungs-, bzw. Löschweitergabe).
Dazu tragen die Primärschlüssel und insbesondere kombinierte Primärschlüssel bei.
Einen kombinierten Primärschlüssel erzeugst Du, indem Du im Tabellenentwurf die Felder markierst und dann unter dem Reiter "Entwurf" den Primärschlüssel wählst. Durch die Reihenfolge der Felder des Primärschlüssels von oben nach unten im Tabellenentwurf beeinflusst Du die Sortierung.
Ein zweiter Preis für die gleiche Artikel-Lieferantenkombination ist in meinem Beispiel nicht möglich. Dazu müsstest Du z.B. ein Datumsfeld "gültig bis" (als dritte Komponente des Primärschlüssels) einfügen. ("gültig von" ergibt sich ja immer automatisch aus dem vorigen Datensatz). Den Standardwert des Datumsfeldes würde ich auf ein Datum weit in der Zukunft setzen, sodass der Preis automatisch "bis auf weiteres" Gültigkeit hat. Natürlich muss man dann bei der Erfassung eines neuen Datensatzes daran denken, dass das "gültig bis"- Datum des Vorgängersatzes dann auch auf das Gültigkeitsende korrigiert wird.