Office: (Office 2010) neuer Datensatz in abhängigen Verbindungen

Ja, darum gings doch seit Tagen.... *tongue.gif*

Moment. Der User hat sich über die linke Formhälfte über Type, hersteller und Baureihe für ein Modell entschieden und sieht jetzt dessen verlangte Eigenschaften und deren Erfüllung. Das ist die Anzeige vorhandener Modelle.

Für die Suche nach Modellen anhand von Eigenschaften kann es wohl nicht sinnvoll sein, ein Modell suchen zu müssen. Da würde ich doch eher ein paar neue Formulare aufbauen, die anhand der Vorgaben die Modelle suchen.... Diese Formulare können sich aus den bisherigen Forms ergeben, sind aber eben separat zu halten, da z.B. das Eigenschaften-des-aktuellen-Modells-Ufo eben nicht als Modellsuche taugt.

 

Darum gings es seit Tagen, stimmt ... Aber ich habs ja noch nicht umgesetzt, und ich kapier des meist erst dann zu 100% wenn ich es umsetze :-)
Aber bzgl. dem VBA werde ich dafür deine Hilfe benötigen. Wenn ich soweit bin, werde ich mich wie immer melden ^^


Ja, der User hat sein model ausgewählt. Ein Model ist aber nicht = ein fertig "selektierter Truck". Ein model ist wie der "Golf GTI" hier ein "4x2 TT". Insgesamt haben wir aktuelle 14 Modelle. Ein Model kann aber unterschiedliche Konfigurationen haben, daher können wir mehrere Modelle habe mit unterschiedlichen Konfigurationen -> mehrere Gold GTI, der eine hat 130 PS, der andere 250 PS :-)
es ist zwar das gleiche Model, aber nicht das Selbe Fahrzeug. Hier muss ich viele ggf viele gleiche Fahrzeuge darstellen.

Der Anwender muss sich den gezielten Truck auswählen, damit er ihn verwalten kann "Rohbau Beginn, Rohbau Ende, usw. usw."
Ich hatte mir gedacht, dass der Anwender um seinen Truck zu finden, nun ich eine Maske bereitstelle, dass er sagt: Truck - Percedes-Renz - Golf - GTI => dann stellt er sich die Frage: welchen Golf suche ich noch mal? Stell dir vor es gibt 1000 GTI's mit unterschiedlichen Konfigurationen ... von PS bis Farbe. ggf will der Auditor nen gleichen Wagen mit anderen Farbe, weil ein gelbes Auto zB andere Korrosionsschwächen hat? Oder was auch immer sein Grund ist. Irgendwie muss ich doch nun die Möglichkeit bereitstellen, den gezielten Truck aus der tblValue zu finden.

Wie würdest du das denn realisieren? Noch mal kurz gesagt, wichtig ist, dass der Anwender sein gezieltes Fahrzeug findet, damit er darauf "aufbauen" kann/ arbeiten/ planen kann.

 

Das ging unter. Modelle sind bisher die tiefste Hiearchiebene. Ein 250-PS-Golf-GTI und ein 130-PS-Golf_GTI müssten bisher zwei Modelle sein. Vielleicht sind es dann besser zwei Varianten desselben Modells, also eine weitere Ebene.

Zum Suche-Bearbeitungs-Dilemma:
Bisher arbeiten wir an der Bearbeitungsseite: das aktuelle Modell zeigt sein Pflichtenheft und dessen Erfüllung durch die eingestellten Werte. Wenn die Auswahl des Modells nun nicht nur durch die Entlanghangeln an Typ-Hersteller-Baureihe geschieht, sondern auch durch hierarchiefreie Suche nach einer "Eigenschaftskonfiguration", dann ist das eine neue Anforderung. Bau dir halt dafür neue, eigene Formulare. Die resultieren letztlich aber in einer Trefferliste aus passenden Modellen, deren jedes man dann in den bisherigen Formulare bearbeiten und kopieren könnte.

So ein Modellsuchformular nach Eigenschaften könnte so aussehen:

• Man wählt, welche Eigenschaften (maximal: alle) man vorgeben will (z.B. Typ, Achsanzahl, Übersetzung).
• Für diese gewählten Eigenschaften werden in einem Ufo die gewünschten Werte erfragt: Gesuchter Typ sei Truck, gesuchte Achsanzahl sei 3, gesuchte Übersetzung sei 3,8:1.
• Diese Suchebegriffe stehen in einer Tabelle "Suchparameter". Bei Einzelwerten ist die Suchbedingung dann "Achsanzahl = 3". Bei Alternativwerten (Achse = 2 oder 3) sollte die Bedingung dann sein: Achsanzahl In (2,3)
• Die Modellsuche sucht nun die passenden Modelle, indem die Teilkriterien der Tabelle zusammengesetzt und angewendet werden.

 

Moment, ggf hab ich mich falsch ausgedrückt. Ein und das selbe Fahrzeug kann natürlich nur eine Konfiguration haben. Das ist klar. Wenn du aber zB einen Golf GTI bei mir bestellst, willst du ja einen "bestimmten" Golf GTI. Den werde ich dir bauen. Dieser Golf GTI, den muss ich dann in der DB hinterlegen. Da muss ich dann planen, wann der fertig ist usw. damit du ihn pünktlich vor die Haustüre kriegst.

Hier soll das Fahrzeug dann zB auf die Teststrecke, oder irgendwo als Demo oder Benchmark ausgestellt werden, was auch immer.


Was ändert das denn an der Hierarchie? Nichts? Es gibt doch nichts, unter Model? Oder kommt da das genaue Fahrzeug hin? Wird das nicht mit der tblValue (EingestellteEigenschaftswerte) gewährleistet? Meiner Meinung nach ja, da die value_ID mit der f_model_ID und der f_prop_ID eindeutig das Fahrzeug identifizieren?! Jain? Oder muss ich für deinen Golf GTI eine sogennante Fahrgestellnummer haben, mit der das Fahrzeug eindeutig identifizerit werden kann/ wird. Mit dieser Nummer kann man ja in der Produktion die Stückliste einsehen.

In der DB hier, würde ich sagen, dass dein GOLF GTI die nummer X is, das meinst du, oder?


bzgl des Suchmasken-Dilemmas:
Jap, genau so eine Suchfunktion ist gewünscht. Und es sollte seinen Bezug auf das Modell nehmen. Wenn der Anwender schon vorher seinen "Golf GTI" ausgewählt hat, muss mir die Suchmaske ja keinen Polo mehr anzeigen.

Leider kann ich mir gerade nicht erschließen, wie ich das mit der tblSuchparameter anstellen soll. Den logischen Hintergrund meine ich verstanden zu haben. Alles was da drin ist, nachdem wird gesucht werden können. Aber was genau steht da drin? fertige Trucks? oder nur wieder die Optionen? Die könnten wir ja dann widerum aus der tblPropStock holen?

 

Die Diskussion hatten wir auch schon mal (#28): "Mit einem Modell kann ich nicht fahren und kann keine Beule reintreten. Das kann ich nur mit Fahrzeugen (Modellinstanzen).". Ein Modell kann auch nicht die Farbe blau haben, da ein blauer Golf GTI ein instanziierter Golf ist. Das Modell Golf GTI bietet zwar die Eigenschaft Farbe, aber da nicht alle GTIs blau sind, ist das nur eine Eigenschaft. Eingestellt wird diese Eigenschaft nur für echte Blechkisten. Das ist dir offenbar noch nicht klargeworden.

Wenn es also wirklich um den Bau von Fahrzeugen (mit Blaulackier- und Beulenfähigkeit) geht, dann fehlt in der Tat noch eine Tabelle: Fahrzeuge. So wie ich das deute, sind das bei euch Prototypen (oder habt ihr eine Liste aller existierenden Gölfe weltweit?!). Also wären die Prototypen die "ausgeformten Modelle": man kann Beulen reintreten und sie auf die Teststrecke stellen.

Also:

Ja, da kommt das Fahrzeug hin. Das Fahrzeug wird ja auch einen Projekt/Prototypnamen haben?! Es heißt ja vermutlich nicht "3-Achser-mit-450-PS-und-Nachbrenner-den-kein-TÜV-abnimmt".?! Das ist vielleicht die Kette der eingestellten Werte, aber nicht das Fahrzeug.

Bedenke, dass nicht alle Eingestellten Eigenschaften Fremdschlüssel der Eigenschaftsvorräte sind. Für Maße (4,20 m) beispielweise gibt es sicher keine Vorratstabelle; die Autos werden so lang wie sie wollen. Da steht also dann nicht die Kennzahl für 4,20 drin, sondern 4,20 direkt. Und ich bin auch nicht sicher, dass Modell-ID und Prop-ID in Kombination eindeutig sind. Diese "Wer-hat-was"-Zeile könnte sich wiederholen; 6 Airbags im GTI kann man als eine Eigenschaft "6 Airbags" ablegen, oder (besser) als 6 Zeilen der Eigenschaft "Airbag".

Also "Vorauswahl" nach Type, Hersteller, Baureihe, Modell (?), so dass dann z.B. nur die Golf GTIs in Frage kommen: der rote mit 250 PS und der gelbe mit 130 PS. Aus diesen zwei vorselektierten Modellen wird dann mit Achsanzahl etc. weiter gefiltert?

Die Parametertabelle könnte so aussehen: ein Textfeld "Kriterien".
Code:

Für die modellbegrenzten Fahrzeuge müssen diese Angaben dann ermittelt werden. Da kann eine dynamisch zusammengesetzte SQL helfen.

PS: habt ihr eigentlich keine Informatiker im Haus, oder hab ich das gar schonmal gefragt?! *grins

 

Jap, die Diskussion hatten wir schon mal. Gut also, dass wir nun den gemeinsamen Nenner gefunden haben :-)

Ja genau, es geht hier um prototypen. Natürlich hat auch jeder Prototyp einen Namen. Die Prototypen sind ausgeformte Modelle. Na, ... ich hoffe doch mal schwer, dass man KEINE Beule reintreten kann :-D

Ok, also kommt nach/ unter der tblModel die tblVehicle. Die schiebe ich zwischen die tblModel und der tblValue. Die besteht aus:
- vehicle_ID (pk)
- f_model_ID
- f_value_ID
- vehicle_name

Was wird hier gesagt?? Ich will doch jetzt eigentlich in der tblFahrzeuge (tblVehicle) sagen, wie ein Fahrzeug konfiguriert ist. braucht dann nicht EIN Fahrzeug auch EINE ID für seine Konfiguration? So wie in der tblType klar wird, dass "Truck = 1; Engine = 2; usw. ..." ist?
-> wo ist dann der Sinn der tblValue? Was mache ich mit der? was steht da drin?

Ganz genau. Dann soll diese tolle Suchmaske kommen, mit der ich die maximalen Eigenschaften filtern kann, aber wenn ich zb nur nach Farbe filtern will, sollen alle die die Farbe rot haben angezeigt werden.




Du hast das schon gefragt und ich musste ganz bescheiden "jain" sagen ;-)

Zum Hintergrund, warum ich das mache. Ich hatte letztes Jahr eine DB erstellt für die Verarbeitung von Marktdaten. hatte da auch unterstützung von einem IT Manager, hat wunderbar geklappt.
Für dieses Praktikum wurde mir gesagt, -> wir brauchen lediglich eine DB in der wir unsere Fahrzeuge auflisten können, damit wir sehen, was wir haben. und nun sind wir da wo ich bin -.-

Soviel zum Thema "Stellenbeschreibung" :-D

 

tblVehicle solte so aussehen:
Code:

und hängt unter den Modellen, aber zu den Values (EingestellteEigeschaften) hat sie keinen Bezug. Vielmehr sind es nun die Prototypen, die Eingestellte Eigenschaften haben. Die Eingestellten Werte eines Prototyps sagen aus, wie der Prototyp das Gesamtpflichtenheft erfüllt, das sich aus den Typ-, Baureihe- und Modell-Pflichten ergibt. Darum fliegt die valueID aus den Fahrzeugen raus.

Der Prototyp 42 (PKW VW Golf GTI A mit 130 PS) muss liefern:

• als PKW z.B. die Anzahl Türen (eingestellt: 4)
• als Baureihe Golf z.B. die Golf-Spezialeigenschaft "Werksradio" (eingestellt: Beta)
• als Modell GTI z.B. den Nachbrenner (eingestellt: nein)
• als Prototyp Super 130 PS die "A-Spezialeigenschaft" (eingestellt: X)

Der Prototyp 99 (PKW VW Golf GTI B mit 250 PS) muss liefern:

• als PKW z.B. die Anzahl Türen (eingestellt: 4)
• als Baureihe Golf z.B. die Golf-Spezialeigenschaft "Werksradio" (eingestellt: Gamma)
• als Modell GTI z.B. den Nachbrenner (eingestellt: ja)
• als Prototyp Super 130 PS die "A-Spezialeigenschaft" (eingestellt: Y)

Zur Suchmaske hast du ja schon einen Anstoß bekommen. Baus halt mal.

 

Alles klar.
Ja bin dabei, gebe mein Bestes :-)

was mache ich nun mit der tblValue? wozu benötige ich die noch? Schließlich wird doch nun alles in der tblVehicle dargestellt.

 

Irrtum. Vehicles und Properties sind m:n: Ein Vehicle kann viele Eigenschaften "ausprägen", und eine Eigenschaft kann in vielen Vehicles auftreten (m:n). Die Values vermitteln: wer (Prototyp 42 = A-GTI) hat in welcher Eigenschaft (6 = Achsenanzahl) welchen eingestellten Wert (2 = 2 Achsen).

 

aaa, ok :-)

j' ai compris. merci

 

ich kriegs net hin -.-

ich weiß nicht, wie ich dieses Suchmaskenformular erstellen soll. Rein theoretisch wüsste ich wie. Praktisch tut es das aber nicht.


Ich muss ganz klar die tblProperties und die tblPropStock nehmen. Die Properties zeigt mir die allgemeinen Eigenschaftenbezeichnungen und die tblPropStock die genauen Eigenschaften. Dein Code klappt mit der Eingrenzung auf die tblProperties. Aber dieser "Sucher" ist ja was ganz "unverbindliches". Er bindet sich ausschließlich an seinen Inhalt. Was nicht drin steht, kann nicht ausgewählt werden.


Nächstes Anliegen:

Kann ich tblValue mit der tblVehicle den platz tauschen?
Begründung: Die Konfiguration eines Fahrzeuges bestimmt den Namen eines Fahrzeuges. Z.B ein MAN TGX 18.440. So heißt des Ding. Wenn man sich mal auf der Internetseite des mal anschaut, selektiert man dort ein Fahrzeug nach bestimmten Kriterien. als erstes die Baureihe (TGX) usw. die 18 steht für 18 Tonner und die 440 für 440PS. Wenn ich also nen 480PS nehme in dem Selektor, dann heißt er TGX 18.480.


Gedanke beim Tausch:
ein Model besteht aus vielen Eigenschaften (anstatt das Fahrzeug). Bestimmte Eigenschaften bilden ein Fahrzeugnamen (wie im vorhergegangenen beispiel). Dieses Fahrzeug besteht aus bestimmten Eigenschaften.
Ist das machbar? Weil ich hab mich vorhin mit dem produktmgmt echt gefetzt :-D das ist meiner meinung nach nur ein Luxusproblem, für die, die zu Faul sind, vorher nen namen für das Ding einzutippen.


EDIT
Fehler: Model besteht aus Eigenschaften daher muss die Properties verknüpft sein, ganz klar. Vehicle gehört jetzt nur noch an die tblValue einfach angehängt, um einen Namen zu genieren. Wie siehst du das?

 

Hab heute und morgen ganztägige Termine. Melde mich am WE oder montag wieder.

 

alles klar. danke :-)

 

Zu #71 inkl. Edit:

Ziel ist, die Einzelkriterien einer Suche (Achsanzahl = 3, Leistung = 440 PS) in einer Tabelle oder einer ähnlichen Struktur (Array, Collection, ...) zu speichern. Dieser Stapel von Kriterien wird aus den Einzelkriterien gebildet, für die man jeweils alle Props auf Werte eingrenzen kann.

Beispiel einer neuen Suche:

• Erstes Kriterium: Auswahl der Prop Achsanzahl -> Eingabe des gewünschtes Werts 3 -> "auf Stapel legen"
• Zweites Kriterium: Auswahl der Prop Motorleistung -> Eingabe des gewünschten Werts 440 -> "auf Stapel legen".
• Am Ende der Auswahl: Stapel zum Gesamtkriterium vereinen und passende Fahrzeuge suchen.

Für das Einzelkriterium ist der Aufbau mit einem Form machbar:

• Auswahl des zu untersuchenden Props
• Auswahl oder Eingabe des gesuchten Werts (ggf. auch Mehrfachauswahl (?)); bei Props mit Vorrat kann dieser angeboten werden, aber es sind wohl auch vorratsfremde Werte möglich.
• Ablage auf Stapel

Die Vereinigung des Stapels zum Gesamtkriterium wäre dann - je nach Stapelart - durch Join(Array, " AND ") oder durch Recordset-Iteration der Tabelle mit Verkettung der Teilkriterien möglich.

Zur Tabellenposition:
Verhicles sind benamste Kombinationen ("Sets") von Eigenschaften. Es bleibt daher so, wie es war. Ein Tausch ist nicht sinnvoll.

 

Der Ablauf des von dir genannten Beispiels ist verstanden.
Ich müsste also eine tblSuchparameter anlegen. Diese dient mir nur für die Suche. Die aus dem cboFeldern ausgewählten Werte werden dort drin abgebildet und ein bestimmter Code sucht zeigt mir dann alle Fahrzeuge an, die diesen Kriterien entsprechen.

Aber wie darf ich das mit dem Einzelkriterium verstehen?
Es wird doch lediglich im tblPropStock die aktuellen werte gesourced und in der tblvalue nach passenden ergebnisse, welche in verbindung mit dem primärschlüssel des fahrzeugnames stehen dargestellt.
Was ist mit der Frage gemeint, ob mehrfachauswahl möglich sei? ein fahrzeug hat ganz genau eine Achsenkonfiguration?

Des mit Vereinigung hab ich nicht verstanden, da geht es ja dann auch schon mit Code los :-D
Tabellenposition wird nicht verändert, habe mir da auch noch mal genauere gedanken gemacht, das ist einfach nicht sinngemäß dem was ich als Ziel haben will. (danke)