Office: (Office 2016) Doppelte Werte in zusammengesetztem Abfrage-Feld vermeiden

Hallo,
mache aus den 12 Detailtabellen eine Tabelle.
Siehe Bild. Tabelle fortsetzen bis SW_min.
Das gibt 113 Datensätze in dieser Tabelle.
In der Zuordnungstabelle braucht es dann nur noch ein Feld (GeoDatenID) als Fremdschlüssel.

Es könnte sinnvoll sein, auch für die Geoart eine Tabelle anzulegen und nur einen Schlüsselwert zu speichern.


PS:
Ich kann erst am späten Abend wieder weiter machen.

 

=> Datensätze haben untereinander auch nichts miteinander zu tun. Bei gegenseitigen Abhängigkeiten (außer Verweisen per Schlüssel) hätte man etwas falsch gemacht.

=> SW_min und SW_max sind Abmessungen, Dezimalzahlen und gar mit der gleichen Maßeinheit? Eine Abmessung ist EINE Information und somit festzumachen in einem Feld, nicht nur einer Tabelle. Unterschiede und Zuordnungen kann man in weiteren Spalten spezifizieren.

 

Ja, es sind zwar alles "Abmessungen", bezüglich der Zahlenwerte können Gleichheiten auftreten, haben untereinander aber nichts miteinander zu tun und dürfen auch nicht vermischt werden.

Um sich von den Zahlenwerten etwas lösen zu können, habe ich im angefügten Beispiel den Detailtabellen mal ganz andere "Inhalte" gegeben. Der Aufbau ist gleich geblieben und nur nochmal etwas eingekürzt.

Ich habe doch jetzt (wie vorher auch?) zwischen den "tblBauteilgruppe" und zB. "tbl_Farbe" eine m:n Beziehung - oder? Das wäre nämlich richtig. Gleiches gilt doch dann für {"tblBauteilgruppe" / "tbl_SW_min"}, {"tblBauteilgruppe" / "tbl_Gewicht"} und {"tblBauteilgruppe" / "tbl_Einheitspreis"}?

Würde man denn bei dieser Konstellation auch alle "Details" in nur eine einzige Tabelle packen? Wenn ja, dann habe ich wirklich noch einen gewaltigen Knoten in meiner Denke ... *eek.gif*

Auch hier wieder:
Die Abfrage liefert richtige Ergebnisse. Daß die Abfrage 347 Bauteilgruppen auswirft ist ebenfalls richtig.

 

Bei ständig fließenden Aufgabenstellungen ziehe ich mich aus Bequemlichkeits- und Vernunftsgründen zurück, weil da tiefere eigene Überlegungen umsonst sind.

Die Zeit wird da besser in etwas Werthaltiges investiert, z.B. will und muss ich noch Möhren ernten für den morgigen Speseplan.

Nur so weit: Für die "obere Baugruppe" legst Du einen Wust an Tabellen in Beziehungen an, hast aber noch zwei weitere zu bedienen. Was soll da passieren?

Weiter: Ist es wirklich undenkbar, dass nicht weitere + andere Baugruppen hinzukommen? Früher gab es Postkutschen, heute gibt es Raketen - was sagt Dir das?

Wenn man wirklich in Baugruppen denkt, ist man von etwas Alltäglichem wie einer Stückliste nicht weit entfernt. Da wird eine Baugruppe mehrfach und in verschiedenen Ebenen auftreten. Darauf kannst Du mit Deiner Modellierung reagieren und das Ganze beherrschen, verstehen sowieso?

Wie dann auch: Die Begrenzung der Indexanzahl gilt durchgehend, auch wenn Du Dich von einer anderen Seite annäherst. Da könntest Du das DBMS wechseln, wo derartige Grenzen höher sind. Grundsätze der Datenmodellierung sind aber die gleichen.

 

Ganz lieben Dank für deine Zeit!!!

Ich denke, daß ich die eigentliche Aufgabenstellungen nicht geändert habe. Ich habe nur die Namen / Datentypen geändert, weil ich dachte, daß es dadurch klarer würde.

Ich kniffele schon eine halbe Ewigkeit daran rum, komme aber nicht auf den Trichter, wie ihr das Umstellen meint.

Sorry

 

Habe ich gemacht, aber dann beißt sich irgendwie was ganz böse. Hatte zwischendurch auch noch einen weiteren Versuch unternommen die Zusammenhänge etwas klarer zu formulieren ... vllt schaust du dir den vorher mal.

Auf jeden Fall ein ganz herzliches Danke vorweg!

 

Hallo,
jdes mal andere Anforderungen und einen anderen Aufbau. Damit komme ich nun gar nicht mehr klar. Dein Upload in #18 hat doch nun mit dem bisher Gesagten (und dem Upload in #14) nichts mehr zu tun.
Das ist doch jetzt ein völlig anderer Aufbau.

Ich würde Dich bitten mal die wirklich vorliegenden realen Rahmenbedingungen hier darzulegen.

 

Hallo und guten Morgen ...

Oh weh - ich dachte, ich hätte es verständlicher gemacht. Das Problem ist immer noch das selbe, ich habe lediglich die kryptischen Benennungen durch was "Sprechendes" ersetzt und in den Detailtabellen auch mal etwas anderes als reine Zahlenwerte gewählt, um mehr auf allgemeinere Eigenschaften eines Bauteils abzustellen. Am grundsätzlichen Prinzip hat sich aber wirklich nichts geändert.

Zur Sachlage:
Eine Baugruppe besteht aus drei Bauteilen (oberes, mittleres und unteres Bauteil), wobei alle drei Bauteile immer aus dem selbem Werkstoff hergestellt werden. Die einzelnen Bauteile werden jeweils durch unterschiedliche Eigenschaften definiert. Diese Eigenschaften sind z.B. verschiedene Abmessungen in den Festlegungen Nominal-, Minimal- und Maxiamal-Wert oder aber auch Farbe, Gewicht usw.

Die Aufgabe ist, einzelnen Bauteile zu definieren und aus diesen jeweils eine Baugruppe zu bilden. Wie eps17 schon angedeutet hat, kommen natürlich neue Baugruppen durch erneute Zusammensetzung bekannter Bauteile oder auch hier neu anzulegender Bauteile hinzu.
Die Bauteile können als Lego-Steine angesehen werden, aus denen etwas gebaut wird (=Baugruppe).

Was es zu vermeiden gilt ist, daß bereits generierte Bauteile oder Baugruppen erneut modeliert werden.

Der Anwender soll im ersten Schritt überprüfen, ob alle benötigten Bauteile bereits existieren - fehlende erforderlichenfalls erstellen - und daraus dann eine Baugruppe bilden. Die so gebildeten Baugruppen werden dann über ihre Baugruppen_ID's weiterverarbeitet. Die Baugruppen_ID ist somit die Schnittstelle.

Abgesehen von den Benennungen habe ich die BspDB "TestKombiVerC" wirklich nur vom Umfang her reduziert, um es etwas übersichtlicher zu halten. Ich habe sie nochmal angehängt.

Einen ganz lieben Gruß
Thomas

 

Hallo,
es ist natürlich für einen Außenstehenden schon schwer hier Vorschläge zu machen, aber trotzdem will ich es mal versuchen.
Du musst für die Eigenschaften unterscheiden, ob mit den Eigenschaften auch gerechnet wird.

Wird hier z.B. geprüft ob der Nimonalwert innerhalb von min und max ist ?
Oder wird das Gewicht geprüft.
Auch der Preis ist so ne Sache, ein Preis unterliegt ja zeitlichen Veränderungen.
Was heute 50.-€ kostet, kosten morgen 52.-€ Wie willst Du das erfassen?
Ich würde auch keine extra Tabelle anlegen für jede Lage der Bauteile, sondern nur eine Tabelle die statt "tblEigenschaftenOberesBauteil" nur "tblEigenschaftenBauteil" und darin alle Eigenschaften erfassen. Es braucht ja nur ein Kennzeichen in dieser Tabelle (ein Feld) für die Lage (Oben, Mitte, Unten) um das unterscheiden zu können.

Ich würde zunächst mal alle Eigenschaften mit den nicht gerechnet wird (egal ob Zahl oder Text) als Text erfassen in einer Tabelle.

Was auch irritierend ist, ist das Gewicht. Wieso gibt es für das Gewicht feste Vorgaben die in einer Tabelle zur Auswahl gespeichert sind. Sind die Gewichte genormt?

Weiterhin wäre noch zu klären, ob diese Zuordnung regelmäßig in anderer Kombination gemacht werden muss, oder ob das für eine Baugruppe einmalig festgelegt wird.

 

Ich würde hier eine Tabelle anlegen und zwar mit genau den Feldern die du aus der oben genannter Abfrage aus der Vielzahl deiner Tabellen generierst.

Dann in Steps:

- für die ID des Datensatz ein SQL Insert die die Datensstzanlage mittels deinen erwähnten zusammen gesetzten Schlüssel definiert
- die weiteren Felder mit VBA erstellst oder errechnest und als Variable ausgibst mittels zb dbexecute.update in die Tabelle schreibst

Wenn du magst erstelle ich dir ein kleines Beispiel wie das funktioniert und lade es hier hoch welches du selber ausbauen kannst.

Gib kurz Bescheid

Lg Jimmy

 

Hallo zurück

ab und an muß man Aufgaben etwas unterbrechen, weil andere Dinge vorgezogen werden müssen.

@gpswanderer
Mit den "Eigenschaften" wird weitergearbeitet, das ist mit unter auch der Grund, weshalb sie in separaten Tabellen geführt werden. Hierzu gehört auch, daß sich die drei Bauteile nicht nur von der Lage unterscheiden, sondern jedes für sich spezifisch definiert wird. Das heißt, das obere Bauteil ist ganz was anderes als zB. das Mittlere.

@Jimmy_Star
Die von dir beschriebene Herangehensweise schwirrt mir auch schon seit ein paar Tagen im Kopf herum, insbesondere weil mir die im Beispiel enthaltene Abfrage im Prinzip ja schon die benötigten Informationen liefert. Ich habe mir auch gestern zwei Access-VBA Bücher bestellt.
Insofern wäre ich dir für das angebotene kleine Beispiel sehr dankbar. Dann könnte ich mich da wohl etwas leichter einarbeiten.

Danke & Gruß
Thomas

 

Hallo,

Das ist doch egal. Wenn alle Eigenschaften die es gibt in einer Tabelle gespeichert sind, so musst Du doch nur zutreffende Eigenschaften in der Zuordnungstabelle speichern. In diese Zuordnungstabelle muss noch ein Feld zur Kennzeichnung der Lage (oben, mitte, unten) und ein Feld für den eigentlichen Wert.
Damit bist Du völlig flexibel und kannst jede beliebige Eigenschaft jedem beliebigen Bauteil in jeder beliebigen Lage zuordnen.

Im übrigen hast Du nur ein Teil meiner Fragen beantwortet und bist auch auf andere Hinweis nicht eingegangen.

Wenn das ordentliche Bücher sind (wovon ich ausgehe), wirst Du keinen Hinweis finden der zu einer Tabelle rät.

 

Hallo

Würde es ja gern ausprobieren, bekomme es aber nicht auf den Schirm, wie du das meinst ... sorry. Wenn es nicht zu unverschämt ist - vllt auch mal ein kurzes Beispiel anhand der letzten Fassung? Es müsste nicht vollständig sein, nur das Prinzip eben.

Gruß
Thomas

 

Hallo,
ich brauche erst die Antwort auf die restlichen Fragen.

Hatte ich schon mal erbeten.

 

Ein möglicher Ansatz dazu wäre Generics - Eine Datenbank für alle(s)..., weil nach Beispielen gefragt wird. Dies ist aber in der weiteren Anwendung aus verschiedenen Gründen heraus dann auch etwas anspruchsvoller, was z.T. in dem beigefügten PDF schon angedeutet wird.

Von der Datenmodellierung wiederum ist eine Methode, die den eingangs geäußerten Wunsch (siehe Thementitel) erfüllen kann, unmittelbar abhängig und somit erst dann sinnvoll diskutabel.