Darf ich mal um Tipps bitten, für ein Design?
Ich habe eine DB mit einer Tabelle und DS. Manche dieser Datensätze gehören in gewisser Weise zusammen und bilden Gruppen zu 2 bis ca 5 oder maximal 10. Diese Gruppen entstehen immer dann, wenn die Datensätze ein gemeinsames Merkmal haben, das aber nirgendwo auftaucht. Ein DS kann Mitglied mehrere solcher Gruppen sein.
Jetzt wollte ich in einem Endlosformular eine Möglichkeit einbauen um
* anzuzeigen, ob der DS in einer Gruppe ist
* die Gruppe anzuzeigen und die jeweils anderen Datensätze dieser Gruppe auch noch anzeigen.
Es ist mir klar, dass ich mit einer weiteren Tabelle "Gruppen" arbeiten möchte, aber ich würde dort gern ein Feld haben, das alle der zugeordneten DS enthält, z.B. die ID abspeichert.
Und dann ein Formular, das diese Gruppe aufrufen kann, so dass man sie sich ansehen kann.
Carl
Hallo,
das ist eine ganz klassische n:m Beziehung. Du brauchst noch 2 Tabellen, eine für die Gruppen und eine für die Zuordnung der Mitglieder zur Gruppe.
In einem Hautformular kannst Du dann die Gruppen anzeigen und darin ein Unterformular (endlos) zur Anzeige der Mitglieder.
Im Datensatz selbst kannst Du auch die Gruppe anzeigen, wenn in die Abfrage für den Datensatz die beiden neuen Tabellen mit den Verknüpfungen enthält.
Diese beiden zusaätzlichen Tabellen sind für eine Datenbank die einzigste sinnvolle Möglichkeit.
Zitataber ich würde dort gern ein Feld haben, das alle der zugeordneten DS enthält, z.B. die ID abspeichert.
Dazu ist dann etwas Aufwand notwendig. Z.B. so:
http://dbwiki.net/wiki/VBA_Tipp:_Liste_per_SQL_aufbauen
Hm.
Und wenn man ein Feld nimmt, in das man mehrere Werte gleichzeitig eintragen kann?
Also eine Tabelle "Gruppe" und in der Haupttabelle ein solches Feld mit den ID's der Gruppe. Lässt sich das dann sortieren und darstellen oder wäre das keine gute Idee?
Carl
Hallo,
vergiss es, mehr kann ich dazu nicht sagen.
ZitatLässt sich das dann sortieren und darstellen oder wäre das keine gute Idee?
Nein, keine gute Idee, das ist Krampf, sonst nix. Und sortieren geht auch nicht, zumindest nicht ohne Aufwand. Z.B. die ID's in ein Array einlesen und dann mit BubbleSort sortieren.
Alles Krampf im Vergleich zu einer ordentlichen n:m Beziehung.
Was gefällt Dir daran nicht ?
Im Vergleich zu Deiner angedachten Lösung, wäre das relativ einfach.
Ehe Du Dir was erzählen lässt: Probiere es doch einfach mal aus, insbesondere dann auch die Abfrageerstellung auf solche mehrwertigen Felder.
Wenn Du dann irgendwann erkennst, dass da intern auch weitere Tabellen, aber nicht so offensichtlich und sichtbar, verwendet werden, wird Dir der Klassiker, diese Tabellen gleich im Datenmodell zu verwenden, ganz angenehm sein.
okay, ich verstehe m:n
Und ich habe noch eine Frage,
* Endlosformular
* Feld [xy]
* daneben ein button
Ist es möglich, den Button so anzusteuern, dass er auf Druck alle Datensätze filtert, die im Feld [xy] den selben Wert haben wie der Datensatz, in dem der Button gedrückt wurde?
Carl
Zitat von: ebs17 am April 07, 2018, 19:00:46
Wenn Du dann irgendwann erkennst, dass da intern auch weitere Tabellen, aber nicht so offensichtlich und sichtbar, verwendet werden,
Ja, okay, das ging mir auch durch den Kopf. Es muss ja aus logischen Gründen irgendwo verarbeitet werden.
Wozu sind dann diese Mehrfach-Felder gedacht?
Carl
Hallo,
ZitatWozu sind dann diese Mehrfach-Felder gedacht?
um dem Anfänger einen Anreiz zu bieten Access zu verwenden. Und etwas einfaches vorzugaukeln was sich dann als komplizierter herausstellt.
Zitatdass er auf Druck alle Datensätze filtert, die im Feld [xy] den selben Wert haben wie der Datensatz, in dem der Button gedrückt wurde?
ja, völlig problemlos, das ist eine einfache Filterung.
Vermutlich dürfen wir Microsoft Sharepoint Services die Mehrwertfelder verdanken, die wir jetzt in Access nicht mehr los werden. Siehe: Anleitung zu Mehrfachwertfeldern (https://support.office.com/de-de/article/anleitung-zu-mehrfachwertfeldern-7c2fd644-3771-48e4-b6dc-6de9bebbec31).
Hallo,
eigentlich hat ja das ganze Thema mit Mehrwertfeldern ja gar nix zu tun. Die Mehrwertfelder kamen ja nur durch Eberhard ins Spiel.
Carl wollte ja ursprünglich nur mehrere Werte in ein Feld eintragen, von diesen Mehrwertfeldern war da ja noch gar nicht die Rede. Die Mehrwertfelder wählen ja durch Anhaken aus und das war ja nicht der Plan.
Wenn man Werte komma- oder sonstwiegetrennt in einem Feld verwendet, bekommt man daraus erst recht nicht vernünftige Abfragen.
Hallo,
Zitatbekommt man daraus erst recht nicht vernünftige Abfragen.
sag ich doch auch.
Zitataber ich würde dort gern ein Feld haben, das alle der zugeordneten DS enthält
Es wird oftmals nicht bedacht oder erkannt, dass Speicherung von Daten und Anzeige von Daten recht unterschiedliche Dinge sein können. Zumal man sich nicht in einem einzelnen Excelsheet bewegt, sondern in der entwicklerfreundlichen Entwicklungsumgebung Access, wo für Tabellen, Beziehungen, Abfragen, Formulare & Co. sehr viele leistungsfähige Assistenten zum Zusammenklicken zur Verfügung stehen. Und wenn dann der Entwickler mit eigenen Fähigkeiten seinem Berufbild entspricht ...
Zitat von: MzKlMu am April 07, 2018, 19:22:15
Zitatdass er auf Druck alle Datensätze filtert, die im Feld [xy] den selben Wert haben wie der Datensatz, in dem der Button gedrückt wurde?
ja, völlig problemlos, das ist eine einfache Filterung.
ist das ein "formularbasierten Filter"?
Also in einem Endlosformular in jedem DS den selben Button, der das ganze Endlosformular nach jenem Wert filtert, der im gewählten Datensatz im Feld [xy] steht. Nach welcher Funktion soll ich da suchen?
Carl
Die möglichweise vielen Infos stehen in einer normalisierten Datenbank in einer Detailtabelle in Form von Datensätzen, in der jeder Datensatz einen Fremdschlüssel zur Haupttabelle aufweist. D. h., die Haupttabelle weiß nichts von Details (ob es ein, kein oder viele Details gibt); die Detailtabelle kennt jedoch sehr genau in jedem ihrer Datensätze den zugehörigen Datensatz aus der Haupttabelle.
Faustregel: wenn 0..1 Informationen vorliegen können, werden diese i.d.R. in der Haupttabelle in Form eines Fremdschlüssels gespeichert. Bsp.: Tabelle mit Personendaten, Tabelle mit Ortsdaten. Der Geburtsort würde in der Personentabelle als Fremdschlüssel auftreten. Weil es nur einen geben kann, den man entweder kennt - dann ist das Feld ausgefüllt, oder nicht kennt - dann bleibt der Eintrag leer (Null).
Wohnorte der Person kann es hingegen viele (sogar parallel) geben (0..n). Also braucht man eine weitere Tabelle, in der jetzt die Person und auch der Ort in Form eines Fremdschlüssels auftreten. Wenn die Betrachtung dynamisch ist, wird man auch noch Zeitangaben machen, wann die Person am Wohnort gelebt hat.
Hallo,
nein, kein "formularbasierten Filter".
Du muss ja nach der Gruppe filtern. Und das ist ein Zahl.
Lege einfach einen Button mit folgendem Code (Beim Klicken):
Me.Filter = "GruppeID_F = " & Me.GruppeID_F
Me.FilterOn = True
Der Vorschlag setzt aber die Umsetzung der n:m Beziehung voraus wie ich es weiter oben beschrieben habe.
Zeige mal ein Bild des Beziehungsfensters auf dem man die 3 Tabellen (die die n:m Beziehung abbildet) sieht.
Mist, ich sehe gerade, dass das gut sortierte Beziehungsfenster sich automatisch verstellt hat und alles wieder unsortiert ist. Chaos. Wie kann sowas passieren?
Ich habe jetzt keine n:m-Beziehung gemacht, sondern nur 1:n zwei Tabellen, ohne Zuordnungstabelle. Weil mir eingefallen ist, dass jeder DS nur zu einer einzigen Gruppe (A) gehören kann. Weil ja alle DS, die in einer zweiten Gruppe B befindlich wären, der der DS auch zugeordnet werden könnte, zugleich auch zu allen DS in Gruppe A parallel wären und umgekehrt. Dann wäre Gruppe A = Gruppe B, wenn sie einen einzigen gemeinsamen DS haben. Die Gruppen schließen sich daher gegenseitig aus.