collapse

* Benutzer Info

 
 
Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?

* Wer ist Online

  • Punkt Gäste: 94
  • Punkt Versteckte: 0
  • Punkt Mitglieder: 0

Es sind keine Mitglieder online.

* Forenstatistik

  • stats Mitglieder insgesamt: 14809
  • stats Beiträge insgesamt: 76028
  • stats Themen insgesamt: 10230
  • stats Kategorien insgesamt: 5
  • stats Boards insgesamt: 17
  • stats Am meisten online: 933

Autor Thema: unabhängige Kombinationsfelder  (Gelesen 5631 mal)

Offline helpneeded

  • Newbie
  • Beiträge: 2
unabhängige Kombinationsfelder
« am: Oktober 24, 2011, 14:49:16 »
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.
 
 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 24505
Re: unabhängige Kombinationsfelder
« Antwort #1 am: Oktober 24, 2011, 16:15:44 »
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?

Offline MzKlMu

  • Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 8524
Re: unabhängige Kombinationsfelder
« Antwort #2 am: Oktober 24, 2011, 19:39:53 »
Hallo,
Zitat
Ich 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
 

Offline DF6GL

  • Global Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 24505
Re: unabhängige Kombinationsfelder
« Antwort #3 am: Oktober 24, 2011, 22:32:01 »
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.

Offline MzKlMu

  • Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 8524
Re: unabhängige Kombinationsfelder
« Antwort #4 am: Oktober 24, 2011, 23:07:02 »
Hallo,
Zitat
Ich 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.
Zitat
Also umgefähr so: Teilnummer- Eigenschaft 1-Eigenschaft 2-usw.
in seiner Erklärung.

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

Offline helpneeded

  • Newbie
  • Beiträge: 2
Re: unabhängige Kombinationsfelder
« Antwort #5 am: Oktober 28, 2011, 09:51:09 »
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.
 

Offline MzKlMu

  • Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 8524
Re: unabhängige Kombinationsfelder
« Antwort #6 am: Oktober 28, 2011, 18:55:08 »
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) ?

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

database

  • Gast
Re: unabhängige Kombinationsfelder
« Antwort #7 am: Oktober 28, 2011, 19:22:22 »
Hallo,

@Klaus

BCNF ... Boyce Codd - Normalform

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

Offline MzKlMu

  • Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 8524
Re: unabhängige Kombinationsfelder
« Antwort #8 am: Oktober 28, 2011, 20:32:22 »
@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
 

Offline Beaker s.a.

  • Access Guru
  • ****
  • Beiträge: 2429
Re: unabhängige Kombinationsfelder
« Antwort #9 am: November 06, 2011, 00:35:03 »
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.
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.
 

Offline MzKlMu

  • Moderator
  • Access-Oberguru
  • *****
  • Beiträge: 8524
Re: unabhängige Kombinationsfelder
« Antwort #10 am: November 06, 2011, 10:54:34 »
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:
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.
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.
« Letzte Änderung: November 06, 2011, 10:57:03 von MzKlMu »
Gruß
Klaus
 

Offline Beaker s.a.

  • Access Guru
  • ****
  • Beiträge: 2429
Re: unabhängige Kombinationsfelder
« Antwort #11 am: November 06, 2011, 16:41:11 »
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
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.
 

 


Advertisment / Werbung - Amazon Affiliate Links