(Maschinen)Konfigurator

K

Klaubinho

Neuer Benutzer
Beiträge
3
Hallo zusammen,

ich arbeite gerade an einer Software für einen Maschinenhersteller zur Konfiguration von Angeboten und zur Verfolgung dieser Angebote. Unter anderem soll halt auch eine Art Maschinenkonfigurator erstellt werden. Nun stehe ich grade voll auf (mei)'nem Schlauch und verzweifele!

Die Situation ist wie folgt:
Es gibt bereits eine Tabelle mit den Standardmaschinen, diese können aber ähnlich wie bei einem Auto auch mit Optionen ausgestattet werden. Aber nicht alle Optionen können jeder Maschine hinzugefügt werden.
Als Zwischenübersicht habe ich nun folgende Relationen meiner Tabellen:

tblMaschinen (1:n) tblMaschinenoptionen (n:1) tblOptionsliste

Die Tabelle "Maschinenoptionen" habe ich gewählt um die möglichen Konfigurationen festzuhalten; Hier kurz Beispiele von möglichen Einträgen:
MaschinenID: XX - OptionsID: 1
MaschinenID: XX - OptionsID: 2
MaschinenID: XX - OptionsID: 3
MaschinenID: XY - OptionsID: 1
MaschinenID: XY - OptionsID: 4
MaschinenID: XY - OptionsID: 5


Nun habe ich also eine Übersicht welche Maschinenkonfigurationen möglich sind. Das heisst:
Ich habe die Möglichkeit Maschine XX mit den Optionen 1, 2 und 3 auszustatten - Maschine XY kann aber nur mit Option 1, 4 und 5 ausgestattet werden.

Eine individuelle Maschinenkonfiguration möchte ich aber irgendstmöglich einem speziellen Angebot zuweisen. D.h. in Angebot "00001" soll Maschine XY mit Option 1 und 5 angeboten werden. --> UND GENAU HIER KOMME ICH NICHT WEITER. Ich stehe hier vermutlich - und wie bereits eingangs gesagt - einfach nur auf dem Schlauch.
Wie müssen hierfür die Beziehungen gesetzt werden? Ich habe schon überlegt es so zu lösen:
tblAngebote (1:n) tblMaschinen (1:n) tblMaschinenoptionen (1:n) tblAngebotsoptionen (n:1) tblAngebote
Diagramm1.png

Ich habe aber mal gehört (in meinen jungen Jahren), dass "Kreisbeziehungen" vermieden werden sollten?
Gibt es hier vielleicht jemanden, der weiterhelfen kann?

Besten Gruß und Danke schonmal im Voraus.

MfG
Klaubinho
 
Werbung:
Ja. Und?

Code: 
[local]:test=# create table maschine(id int primary key);CREATE TABLE
[local]:test=*# create table optionen (id int primary key);CREATE TABLE
[local]:test=*# create table m_o (m_id int references maschine, o_id int references optionen, primary key(m_id, o_id));
CREATE TABLE
[local]:test=*# create table angebot (id int primary key);CREATE TABLE
[local]:test=*# create table a_position (a_id int references angebot, m_id int references maschine, primary key(a_id, m_id));
CREATE TABLE
[local]:test=*# create table amo(a_id int, m_id int, o_id int, foreign key(a_id, m_id) references a_position, foreign key(m_id, o_id) references m_o);
CREATE TABLE
[local]:test=*#

Mal ganz grob.
 
Werbung:
Du musst zunächst mal zwischen möglichen Optionen und Angebotenen/Bestellten Optionen unterscheiden. Eine Maschine hat in deinem Beispiel 3 mögliche Optionen. Diese sind erstmal nur fiktiv und keinem Angebot zugeordnet.

Dann gibt es noch Maschinen die Angeboten oder tatsächlich gebaut werden. Hier musst du die Optionen-Konfiguration auch dem Angebot (ggf. der Position auf dem Angebot wenn mehrere Maschinen pro Angebot) zuordnen.

Du kannst jetzt sagen die möglichen Optionen kommen in eine eigene Tabelle und sparst dir die FKs für die Zuordnung zu Angeboten. Dann machst du für die Ausführung von Maschinen eine eigene Zwischentabelle die das selbe abbildet aber mehrfach für unterschiedliche Angebotspositionen. Ich würde das der Übersichtlichkeit halber so machen.

Du kannst aber theoretisch alles in einer Tabelle halten und bei den möglichen Optionen dann die FKs einfach NULL lassen. Dann wären Constraints für gültige Konfigurationen aber eventuell auch komplexer.
 
Zurück
Oben