Tipp für DS als zusammengehörig markieren

[Carl]

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

[MzKlMu]

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.

aber 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

[Carl]

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

[MzKlMu]

Hallo,
vergiss es, mehr kann ich dazu nicht sagen.

Lä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.

[ebs17]

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.

[Carl]

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

[Carl]

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

[MzKlMu]

Hallo,

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

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?

ja, völlig problemlos, das ist eine einfache Filterung.

[Lachtaube]

Vermutlich dürfen wir Microsoft Sharepoint Services die Mehrwertfelder verdanken, die wir jetzt in Access nicht mehr los werden. Siehe: Anleitung zu Mehrfachwertfeldern.

[MzKlMu]

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.

[ebs17]

Wenn man Werte komma- oder sonstwiegetrennt in einem Feld verwendet, bekommt man daraus erst recht nicht vernünftige Abfragen.

[MzKlMu]

Hallo,

bekommt man daraus erst recht nicht vernünftige Abfragen.

sag ich doch auch.

[ebs17]

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

[Carl]

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?

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

[Lachtaube]

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.