Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!

Mobiles Hauptmenü

unabhängige Kombinationsfelder

Begonnen von helpneeded, Oktober 24, 2011, 14:49:16

⏪ vorheriges - nächstes ⏩

helpneeded

Hallo,

ich bin relativ fit in SQL, jedoch eher weniger in Makros und VBA. Ich habe folgendes Problem:
Ich habe mehrere Kombinationsfelder, die Daten in einem Unterformular suchen (über den Assistenten erstellt).
Ich habe ein Teil mit mehreren Eigenschaften. Also umgefähr so: Teilnummer- Eigenschaft 1-Eigenschaft 2-usw.
Die Teilenummer ist eindeutig, die Eigenschaften treffen auf mehrere Teile zu. Ich will, dass die Suche nach Teilen und nach Eigenschaften möglich ist, die Anzeige soll aber nicht von der Auswahl der anderen Felder abhängen. Das heiß: Wenn im Kombifeld ein Teil ausgewählt wird soll nur eines angezeigt werden. Wenn in einem der Eigenschaftenfelder etwas ausgewählt wird, sollen alle Teile angezeigt werden, die diese Eigenschaft haben. Ich schaffe aber immer nur eines von beiden: Entweder es wird immer nur ein Teil angezeigt, oder viele. Je nachdem wie ich die Verknüpfung setze. Kann mir jemand weiterhelfen? Hoffentlich habe ich mich verständlich ausgedrückt...Finde immer nur Hilfe zu abhängigen Kombifeldern, das brauche ich aber nicht.

DF6GL

Hallo,

einfach so:

Sub cmbTeilenummer_Afterupdate()
Me.Filter= " Teilenummer = '" & Me!cmbTeilenummer & "'"   ' falls Teilenummer in der Tabelle den Datentyp Text hat.
Me.FilterOn=true
End Sub

Sub cmbEigenschaft1_Afterupdate()
Me.Filter= " Eigenschaft1 = '" & Me!cmbEigenschaft1 & "'"   ' falls Eigenschaft1 in der Tabelle den Datentyp Text hat.
Me.FilterOn=true
End Sub

Sub cmbEigenschaft2_Afterupdate()
Me.Filter= " Eigenschaft2 = " & Me!cmbEigenschaft2    ' falls Eigenschaft2 in der Tabelle den Datentyp Zahl. Long hat.
Me.FilterOn=true
End Sub



Was hast Du für "Verknüpfungen" dabei gesetzt, bzw. was meinst Du damit?
Viele Grüße vom Bodensee
Franz, DF6GL

Hilfestellung:  http://www.access-o-mania.de/forum/index.php?topic=6969.msg118738#msg118738

Links und Tipps:
1.   http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/
1a. http://www.tinohempel.de/info/info/datenbank/normalisierung.htm
1b. https://support.office.com/de-de/article/Grundlagen-des-Datenbankentwurfs-eb2159cf-1e30-401a-8084-bd4f9c9ca1f5#bmterms
2.   http://www.donkarl.com
3.   https://web.archive.org/web/20201201233522/http://www.dbwiki.net/
4.   http://www.access-tutorial.de/
5.   http://www.tty1.net/smart-questions_de.htm
6.   http://access.joposol.com/accept

Last but not least:   < F1 > für Hilfe
;) Learning by doing not by spoon-feed ;)

Tipp: Find and Replace for Access

MzKlMu

Hallo,
ZitatIch habe ein Teil mit mehreren Eigenschaften. Also umgefähr so: Teilnummer- Eigenschaft 1-Eigenschaft 2-usw.
wobei nicht unerwähnt bleiben sollte, dass das ein falsches Datenmodell ist. Und wenn ich mehrere lese, sind das ja bestimmt nicht nur 2 Eigenschaften.

Für die Zuordnung der Eigenschaften ist eine extra Tabelle erforderlich je zugeordneter Eigenschaft ein Datensatz. Wobei jeweils nur die TeilID und die EigenschaftID als Fremdschlüssel in der Zuordnungstabelle gespeichert wird.
Das ist eine klassische n:m Beziehung.

@Franz Übersehen, oder ignoriert?
Wahrscheinlich ignoriert.  ;D  ;D ;D
Gruß Klaus

DF6GL

Hallo,


@Klaus:

Jain...  ;)


Wenn die "Eigenschaften" (Attribute) unterschiedlichen sinnlichen Inhalt haben, dann ist zwar eine "Eigenschaften"-Tabelle mit 1:n zur eigentlichen Tabelle denkbar, in der Praxis aber eher hinderlich, bzw. nur für "Sonderfälle" brauchbar (z. B. wenn die Anzahl der Attribute pro Datensatz variiert).


Ich glaube nicht( zumindest hoffe ich es nicht) , dass der "Hilfenötighabende" mit "Eigenschaft1,Eigenschaft2" Aufzählungsfelder mit gleichbedeutenden Inhalt gemeint hat. Dann wäre eine "Detailtabelle" tatsächlich dringend vonnöten.
Viele Grüße vom Bodensee
Franz, DF6GL

Hilfestellung:  http://www.access-o-mania.de/forum/index.php?topic=6969.msg118738#msg118738

Links und Tipps:
1.   http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/
1a. http://www.tinohempel.de/info/info/datenbank/normalisierung.htm
1b. https://support.office.com/de-de/article/Grundlagen-des-Datenbankentwurfs-eb2159cf-1e30-401a-8084-bd4f9c9ca1f5#bmterms
2.   http://www.donkarl.com
3.   https://web.archive.org/web/20201201233522/http://www.dbwiki.net/
4.   http://www.access-tutorial.de/
5.   http://www.tty1.net/smart-questions_de.htm
6.   http://access.joposol.com/accept

Last but not least:   < F1 > für Hilfe
;) Learning by doing not by spoon-feed ;)

Tipp: Find and Replace for Access

MzKlMu

Hallo,
ZitatIch glaube nicht( zumindest hoffe ich es nicht) , dass der "Hilfenötighabende" mit "Eigenschaft1,Eigenschaft2" Aufzählungsfelder mit gleichbedeutenden Inhalt gemeint hat.
doch, ich glaube schon, beachte das usw.
ZitatAlso umgefähr so: Teilnummer- Eigenschaft 1-Eigenschaft 2-usw.
in seiner Erklärung.

Aber mal sehen, warten wir mal seine Darstellung ab.
Gruß Klaus

helpneeded

Hallo,
vielen, vielen Dank schon mal für die Hilfe.
Die Kombinationsfelder dienen der Suche in einem Unterformular, das wiederum eine Abfrage ausgibt. Die "Eigenschaften" sind natürlich Attribute. Es kommt jedoch vor, das verschiedene Teile den gleichen Wert bei einem Attribut haben, dies folgt jedoch keinerlei Regelmäßigkeit, also will ich das auch nicht auslagern. Die Datenbank ist in BC-Normalform, das müsste also passen ;)
Mein Hauptprobelm ist eigentlich nur, dass jedes Kombinationsfeld das andere sozusagen "ignorieren" soll.
Mit Verknüpfung beziehe ich mich auf die Möglichkeit in Access die Untertabelle mit "Verknüpung nach" mit den Kombinationsfeldern zu verknüpfen.

MzKlMu

Hallo,
Zitat"Eigenschaften" sind natürlich Attribute.
Ja, das ist klar, aber wie liegen diese in der Tabelle vor?
Vereinfacht gefragt, nebeneinander (alle in einem Datensatz) oder untereinander (je Atriubut ein Datensatz) ?

ZitatDie Datenbank ist in BC-Normalform
Was verstehst Du unter BC Normalform?
Gruß Klaus

database

Hallo,

@Klaus

BCNF ... Boyce Codd - Normalform

...so wahr mir Codd helfe...    ::)

MzKlMu

@Peter,

danke hatte ich noch nie gehört, aber wie Wikipedia nachgeschlagen und gelich wiedererkannt.  ;D

Trotzdem warte ich mal auf die Beantwortung der Frage.
Gruß Klaus

Beaker s.a.

Hallo MzKlMu,
Zitat
Trotzdem warte ich mal auf die Beantwortung der Frage.

Ist eigentlich durch seine Aussagen:
"ich bin relativ fit in SQL"
"Die "Eigenschaften" sind natürlich Attribute" und
"Die Datenbank ist in BC-Normalform"
schon beantwortet.
Ich würde daraus schliessen, dass die Teile-Eigenschaften in einer n:m Beziehung abgebildet sind.
gruss
beaker s.a.
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)

MzKlMu

#10
Hallo,
@Beaker s.a.
was glaubst, wieviele hier (und in anderen Foren) schon geschrieben haben: "DB liegt vollständig normalisiert vor" und es war noch nicht mal die Spur von normalisiert.
Liese mal diesen Satz von Ihm aus dem 1. Beitrag:
ZitatIch habe ein Teil mit mehreren Eigenschaften. Also umgefähr so: Teilnummer- Eigenschaft 1-Eigenschaft 2-usw.
Die Teilenummer ist eindeutig,
Wenn die Teilenummer hier eindeutig ist, kann das keine n:m Tabelle sein.
Und die Aussage:
Zitat"Die "Eigenschaften" sind natürlich Attribute"
kann auch für Aufzählungsfelder zutreffend sein.
Insofern, habe ich so meine Zweifel. Wenn die DB korrekt ist, kann das ja mit einem Satz geklärt werden.
Gruß Klaus

Beaker s.a.

Hallo MzKlMu,

Zitat
was glaubst, wieviele hier (und in anderen Foren) schon geschrieben haben: "DB liegt vollständig normalisiert vor" und es war noch nicht mal die Spur von normalisiert.

Ja, Normalisierung ist ein immer wieder auftauchendes Problem. Bei mir war das am Anfang so, dass ich, ohne den Begriff jemals gehört zu haben, in meinen ersten Versuchen das irgendwie instinktiv gemacht habe. Zwar sicher nicht konsequent bis zur letzten NF aber rudimentär zumindest für meine Bedürfnisse brauchbar. Ich muss allerdings zugeben, dass ich die höheren Formen bis heute noch nicht vollständig verstanden habe.
Dazu, was hier so darüber geschrieben/behauptet wird, muss ich sagen, dass ich neu hier bin, und noch nicht so viele Beiträge gelesen habe. Hörte sich beim OP aber schon so an, als dass er wüsste vorüber er spricht.
Vielleicht sollte ich mich an dieser Stelle erstmal vorstellen. Ich bin ein Hobby"programmierer" und würde mich als fortgeschrittenen Anfänger bezeichnen. War bis jetzt eher in Newsgroups unterwegs; - da ist nun aber leider nicht mehr viel los :-(.
Ich bin mit meinen Antworten manchmal etwas voreilig, bitte aber meistens die, die es besser wissen, mich zu korrigieren; - ich bin da äusserst lernfähig. Ich beantworte Fragen nämlich auch aus dem Grunde selber was zu lernen.
Zurück zum Thema.

Zitat
Zitat
Ich habe ein Teil mit mehreren Eigenschaften. Also umgefähr so: Teilnummer- Eigenschaft 1-Eigenschaft 2-usw.
Die Teilenummer ist eindeutig,
Wenn die Teilenummer hier eindeutig ist, kann das keine n:m Tabelle sein.

Er schreibt aber nicht "Tabelle" sondern "Teil", sagt also IMO nichts über sein Datenmodell aus.

Ich glaube jetzt eher, dass dieses
Zitat
Es kommt jedoch vor, das verschiedene Teile den gleichen Wert bei einem Attribut haben, dies folgt jedoch keinerlei Regelmäßigkeit, also will ich das auch nicht auslagern.

ein Hinweis auf mangelnde Normalisierung ist.

Jetzt noch eine Nachfrage von mir.
Zitat
Wenn die "Eigenschaften" (Attribute) unterschiedlichen sinnlichen Inhalt haben, dann ist zwar eine "Eigenschaften"-Tabelle mit 1:n zur eigentlichen Tabelle denkbar, in der Praxis aber eher hinderlich, bzw. nur für "Sonderfälle" brauchbar (z. B. wenn die Anzahl der Attribute pro Datensatz variiert).

Wieso sollte in diesem Fall die Normalisierung hinderlich sein. Wenn die Eigenschaften unterschiedlichen sinnlichen Inhalt haben, braucht man IMO ja sogar noch eine vierte Tabelle, also eine zusätzliche für die Eigenschaften-Werte. Ich mach mal ein Beispiel.
Sagen wir mal es geht um T-Shirts. Die haben die Eigenschaften "Farbe", Grösse" und evtl vllt. noch "Material".
Das würde ich folgendermassen abbilden:

1. tblArtikel(Teile)
ArtikelID (PK)
Bezeichnung
.
.

2. tblEigenschaften
EigenschaftenID
Bezeichnung
.
.

3. tblEigenschaftenWerte
EigenschaftWertID (PK)
EigenschaftenID (FK)
Wert
.
.

tblArtikelEigenschaften ist 1:n mit tblEigenschaftenWerte verknüpft

tblArtikelEigenschaften
ArtEigID (PK)
ArtikelID (FK)
EigenschaftWerteID (FK)
.
.

Dies in die Verbindungstabelle zwischen Artikeln und Eigenschaften, mit der dann alle Möglichkeiten abgedeckt sind; -
beliebig viele Artikel mit der/den gleichen Eigenschaft(en) und beliebig vielen Werten (z.B. alle T-Shirts habe die Eigenschaft "Farbe"/"Grösse" aber nicht alle T-Shirts gibt es in den gleichen Farben/Grössen). Und natürlich lassen sich so auch alle T-Shirts mit einer gegebenen Eigenschaft anzeigen.

gruss
ekkehard
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)