"dynamische" datenbank

[bienemeier]

Hallo,

ich versuche gerade eine Lagerdatenbank zu erstellen (ERM), komme aber einfach nicht weiter.

Mein Problem:

Ich habe ein Produkt, dass aus verschiedenen Komponenten besteht.

Eine Komponente kann aber auch ein Produkt sein.

Eine Komponente kann aber auch wieder aus weiteren Komponenten bestehen usw.

Wie stelle ich das im ERM dar bzw. wie setzte ich es tabellarisch um??

Bin für jeden Tipp dankbar!

grüße

steffi

[Jan Jansen]

Produkt und Komponente könnte man fachlich trennen (für die Lösung aber nicht relevant):

ein Produkt besteht aus einer oder vielen Komponenten

eine Komponete besteht aus einer oder vielen Komponten (rechteckige Linie von der Rechten Seite der Entität bis zu Oberseite der Entität (außen))

Jetzt musst du nur noch überlegen wie man ganz allgemein eine 1:n Beziehung abbildet (in welche Tabelle wird was warum eingefügt) und wende diese Lösung auf die Tabelle Komponete an (stell dir vor, die Tabelle gibt es 2 mal auf deiner Datenbank)

[bienemeier]

Hi,

danke für Deine Antwort.

"Produkt und Komponente könnte man fachlich trennen (für die Lösung aber nicht relevant)"

Ich bin für jeden Hinweis und Tipp dankbar.

Bei zwei Tabellen würde ich mit Fremdschlüssel arbeiten. Aber ich hab ja de fakto nur eine Tabelle. Kann ich den Primärschlüssel gleichzeitig nochmal als FK einfügen??

Ich bin mir auch nicht sicher, ob ich nicht eigentlich eine n:m Beziehung hätte, weil ich eine Komponente habe, die aus versch. Komonenten besteht, die zu versch. Komponenten gehören *Drehwurm*

Ich hab jetzt das Stichwort "Rekursive Beziehung" aufgeschnappt und diese schöne Definition bekommen:

"Es werden zwei unabhängige Tabellen erstellt. Ihr Schlüssel ist jeweils die in Kombination der PKs der beiden teilnehmenden Entitäten."

Der beiden teilnehmenden Entitäten,...

hab ich dann in einer Tabelle Entitäten deren Eindeutigkeit durch zwei Fremdschlüsseln - die in der selben Tabelle PKs sind - gewährleistet ist??

Junge - mein Kopf ist voller Knoten *g*

[Jan Jansen]

ja genau, du fügst einen FK in die Tabelle Komponete ein, der auf eine übergeordnete Komponete zeigt.

Komponete_PK

Komponete_FK

Feld1

Feld2

[...]

Aber die Idee mit der 2. Tabelle ist eventuell sogar besser (und geht dann auch für n:m Beziehungen)

Aufbau der Tabelle (Komponetenzuordnung) wäre dann:

Komponete_PK_übergeordnet

Komponete_PK_untergeordnet

(Anzahl)

Dann brauchst du auch keinen Fremdschlüssel in der Tabelle Komponete

[bienemeier]

danke für die Hilfestellung!

Ich denk so müsste es klappen.

[Reinhold]

Moin,

bei allen Hinweisen hier musst du aber immer noch sicherstellen, dass keine Rekursion eintreten kann. Das wäre dann der Fall, wenn eine Komponente in ihrer Stückliste (über nichts anderes reden wir hier ja wohl) sich selbst enthält.

(aus dem Computerwörterbuch: "Rekursion, die: siehe Rekursion")

Reinhold

[bienemeier]

Hmmm.

Danke für den Hinweis.

Tatsächlich habe ich mir gerade über den Fall Gedanken gemacht.

Als Beispiel:

Komponete_PK | Beschreibung | Komponente_FK

1 |KompA_alleinstehend| ??

2 |KompB_zuA | 1

3 |KompC_zuA | 1

usw.

Welchen FK_Wert bekommt nun die "Oberkomponente"??

[Jan Jansen]

keinen, bzw NULL

[InfoJunkie]

bei allen Hinweisen hier musst du aber immer noch sicherstellen, dass keine Rekursion eintreten kann.

Wie würdest Du das sicherstellen? Kann man Rekursion schon auf DB-Ebene verhindern, oder müsste sich die ERP-Software darum kümmern? Das wäre in meinen Augen die schlechtere der beiden Lösungen.

[Reinhold]

Wie würdest Du das sicherstellen? Kann man Rekursion schon auf DB-Ebene verhindern, oder müsste sich die ERP-Software darum kümmern? Das wäre in meinen Augen die schlechtere der beiden Lösungen.

Hm, das ist eine gute Frage.

Als spontane Idee (und geeignetes DBMS vorausgesetzt) könnte man irgendwelche genialen Trigger beim Update bzw. Insert ausführen lassen, die das überprüfen ....

Verlang aber jetzt bitte keinen Codeschnipsel.

Und ob das sehr performant ist, wage ich auch zu bezweifeln.

Alternativ kannst du auch die Methode "Augen-zu-und-durch" verwenden und dich auf den Standpunkt stellen, dass dein User sehr wohl das System zum Absturz bringen darf, er hat es ja gekauft und somit ist es sein Eigentum... :D:D

Spaß beiseite, wenn jemand einen Vorschlag zu dieser Denksportaufgabe hat, bin ich daran auch sehr interessiert.

Reinhold