SQL Datenbankdesign: Redundanz oder transitive Abhängigkeit unvermeidbar ?

[xrafi1989x]

Hallo Leute,

ich habe ein grundsätzliches Problem beim Design meiner Datenbank für eine Automatisierungsaufgabe. Ich versuche mal mein Problem ausführlich zu schildern.

Meine Anlage besteht aus beliebig vielen "Modulen".

Tab_Module [Id (PK), ModuleTypeId (FK), Name (Attr) ]

Ein Modul gehört zu einem bestimmtem Modultypen. Es können mehrere Module eines Modultypes existieren.

Tab_ModuleType [Id (PK), Name (Attr)]

Für einen ModulTypen existieren"n" viele ProzessCommandos

Tab_Commands [Id (PK), ModuleTypeId (PK -> FK aus ModuleType), Command (Attr)]

Die Anlage wird mittels Rezepten gesteuert. Ein Rezept konfiguriert jedes Modul in der Anlage

Tab_Recipe [Id (PK), Name (Attr) ..... ]

Tab_Configuration [RecipeID (PK -> FK Recipe), ModuleId (PK -> FK aus Modul), ??Command??]


Mein Problem befindet sich nun in der Tab_Configuartion bei den Fragezeichen. Einerseits möchte ich dem User ermöglichen aus einer Liste von Commands für einen bestimmten ModulTypen zu wählen -> deswegen sind Commands mit ModuleType verknüpft. Commands ist nun ein zusammengesetzer Schlüssel aus ModuleTypeID und CommandID).

In der Tab_Configuration möchte ich jedoch nicht einen Modultypen konfigurieren, sondern ein bestimmtes Modul).

Wenn ich jetzt also die Tabelle wie folgt aufbaue:

Tab_Configuration [RecipeID (PK -> FK Recipe), ModuleId (PK), ModuleTypeID(FK) + CommandId (FK)],

habe ich eine transitive Abhängigkeit zwischen ModuleID und ModuleTypeID.



Eine Andere Variante wäre

Tab_Command [Id (PK), Command (Attr)]

und eine Zuordnungstabelle

Tab_ModuleCommand [CommandID (PK), ModuleTypeID (FK)]

Dann in der Config Tabelle:

Tab_Configuration [RecipeID (PK -> FK Recipe), ModuleId (PK), CommandId (FK)]

Hier allerdings das Problem, wenn sich die ModuleID ändert, ist evtl die CommandID ungültig - bzw nicht erlaubt/gewollt.


Eine 3. Variante wäre: ich ordne die möglichen Commands direkt dem Modul zu

Tab_ModuleCommand [CommandID (PK), ModuleId (FK) ]

und verknüpfe diese mit der Config Tabelle

Tab_Configuration [RecipeID (PK -> FK Recipe), ModuleId (PK), CommandId (FK)] (letztere beide Schlüssel aus ModuleCommand)


Da habe ich allerdings wieder das Problem: Wenn ich ein neues Modul vom Typen x habe, muss ich für die entsprechende ModuleID die Tab_ModuleCommand ausfüllen.


Ich habe jetzt echt keine Idee wie ich mit dem Problem am besten umgehen kann. Bin für jede Hilfe dankbar!

Schon mal dickes Danke

Raphael

 

[G-Red]

Hi, gibt es vielleicht eine konkrete also detaillierte Beschreibung der Aufgabe?
Kannst du von deiner gegenwertigen Tabellenstruktur und den ganzen Abhängigkeiten einen Screenshot machen? Mit MS Access kannst du so eine Ansicht ganz schnell erstellen, falls nicht bereits vorhanden.

Bilder sagen mehr als tausend Worte .

 

[benneq]

Es gibt keine beste Lösung.

Entweder nutzt du die Normalisierung und speicherst alle Daten nur 1x. Oder du wählst die Redundanz. Alles hat Vor- und Nachteile.

Und dann muss man halt u.a. abwägen ob man auf Read oder Write Performance optimieren will:
Für Write ist es natürlich optimal, wenn man nur an einer Stelle schreiben muss.
Für Read ist es besser, wenn nicht so viele Joins nötig sind.

In der modernen Webentwicklung speichert man die Daten sogar mehrfach gleichzeitig in verschiedenen Formen in mehreren Datenbanken, damit man für Read nur noch ein einzelnes simples Query braucht und die Server nicht so belastet werden. Für die Writes nimmt man gern die 10-fache Belastung und Dauer in Kauf, weil die Schreibzugriffe eben nur ganz selten vorkommen.

 

[G-Red]

@benneque

Oder wenn man genug Hauptspeicher (RAM) zur verfügung hat, dann kann man diese Aufteilung ganz lassen, vorausgesetzt natürlich, dass die DB In-Memory unterstützt.

 

[Madman1209]

Hi,

Hier allerdings das Problem, wenn sich die ModuleID ändert, ist evtl die CommandID ungültig - bzw nicht erlaubt/gewollt.

ON UPDATE CASCADE? Eine ID, die als PK und FK definiert ist sollte sich zwar in meinen Augen nicht ändern, wenn es das aber doch tut kann ich doch die Aktualisierung kaskadieren, oder verstehe ich dein Anliegen an der Stelle nicht?

Ich würde in jedem Fall mit einer Korrelationstabelle / Kreuztabelle / Zuordnungstabelle Arbeiten und die Daten ohne Redundanzen normalisiert speichern.

VG,
Mad

 

[Drahminedum]

Für die Writes nimmt man gern die 10-fache Belastung und Dauer in Kauf, weil die Schreibzugriffe eben nur ganz selten vorkommen.

Das ist völlig von der Anwendung abhängig. Ein Forum z.B. verursacht bis zu 30% Schreiblast.

 

[xrafi1989x]

Hallo,

das Problem mal im Anhang!

Es geht hier um die Tabellen um gelb markierten Bereich:

Ein Job umfasst mehrere Trannsaktionen - konfiguriert wird die Bearbeitung dieser Transaktionen durch das Rezept. In einem Rezept wird die Verarbeitung für jedes Modul (ProcessConfiguration) festgelegt.

ProcessCommands sind für jeden Modultyp immer die gleichen - wenn ich 2 Module habe die eine Klebemaschine sind, dann haben beide die Kommands Durchschleusen und Kleben zur Verfügung.

Mein Problem ist nun die ProcessConfigurationTabelle

Wenn sich die ModuleID ändert, kann das verknüpfte Command (ProcessCommandID) für den Modultypen invalid sein. CommandID ist z.B 7 (Kleben) aber es handelt sich um ein Modul das nur "Messen" kann.

 

[benneq]

ONE DOES NOT SIMPLY CHANGE THE MODULE ID

... oder anders gefragt: Warum sollte sich die ID jemals ändern?

 

[Enurian]

Gibt´s irgendwelche speziellen Gründe, warum du unnötige Querverweise herstellst, die dein Problem überhaupt erst verursachen?

Wozu ist in der ProcessConfiguration ein FK zu einem Command? Ist ja offenbar nicht mal ein formaler FK laut deinem Screenshot.
Zum Einen kann da dann nur noch ein Command stehen, zum Anderen kommst du über Modul -> Modultyp zu allen verknüpften Commands.

Ist halt schwierig genau zu sagen, wie es sein sollte, ohne alle Umstände zu kennen. Meiner Meinung nach liegt da aber etwas im Argen.