Datenbankdesign: Dynamische Daten speichern

[Xzeer]

Hallo,

ich wende mich an euch, weil mir für ein aktuelles Datenbankproblem noch eine geeignete Lösung fehlt. Sowohl Programmiersprache und Datenbanksystem stehen noch nicht fest, ist bisher alles noch im Entwurfsstadium.

Zum Problem:
In einer Datenbank werden unter anderem Geräte in einer Tabelle verwaltet. Dabei handelt es sich um viele verschiedene Gerätetypen. Von welchen Gerätetyp ein Gerät ist, wird durch einen Fremdschlüssel auf eine Gerätetypen-Tabelle festgelegt. In unregelmäßigen Abständen kommt ein neuer Typ dazu. Es wird also einfach ein neuer Eintrag in der Gerätetypen-Tabelle erstellt. So weit so gut... Zu jedem dieser Gerätetypen soll es nun Checklisten geben. In diesen Checklisten werden je nach Gerätetyp aber vollkommen andere Daten gespeichert. Das heißt eine Tabelle reicht zum Speichern der Daten nicht aus.

Meine Frage: Wie speicher ich diese Checklistendaten am besten ab und wie sollte mein Datenbankdesign aussehen?

Die einzige Idee, die mir bisher einfällt ist, für jede Checkliste eine neue Tabelle anzulegen. Das klingt aber irgendwie suboptimal, da mit der Zeit recht viele Checklisten erstellt werden und damit die Anzahl an Tabellen ansteigt.

Beste Grüße,
Xzeer

[Linor]

N'abend,

für die Checklisten kannst du eine Tabelle generieren die im wesentlichen aus drei Feldern besteht: Schlüssel, Typ und Daten. Der Schlüssel ist dabei ein normierter Begriff der beschreibt um welche Daten es sich handelt, z.B. VOLTAGE. Im Feld Typ speicherst du die zu erwartende Nenngröße: Integer, Date, String, Float usw... Im Feld Daten liegen dann die eigentlichen Nutzendaten, idealerweise immer als String abgelegt, musst dann halt beim Schreiben und Lesen die Daten mittels der Info aus Typ konvertieren.

[Furtbichler]

Das wäre aber dann keine 3NF: Zwei Geräte, die beide einen Spannung ('VOLTAGE') als Eigenschaft besitzen, würden zwei -bis auf den Wert- identische Einträge aufweisen => Redundanz.

Aber das Prinzip ist richtig.

Ich würde 2 zusätzliche Tabellen verwenden:
1. Tabelle: Properties mit 3 Spalten:
PropertyID, PropertyName, PropertyTyp

2. Tabelle PropertyValues mit 3 Spalten
GeräteID, PropertyID, Value

[Linor]

Es ist schon klar das EINE Tabelle mit nur DREI Felder nicht reicht, es sollte ja auch nur zeigen wie man verschiedene Daten in einer Tabelle unterbringen könnte...

Idealerweise gibt es zur Geräte-Tabelle eine Checklisten-Tabelle, könnnem ja mehrere sein, und dann halt die Nutzdaten-Tabelle die dann aus Checklisten-Id, Schlüssel, Typ und Daten besteht.

[Furtbichler]

Ja, stimmt, bei deinem Prinzip fehlte sowieso der Verweis zum Gerät.

[Xzeer]

Schon mal danke für die super Antworten bisher. Hat mir schon geholfen und ich habe jetzt mal versucht eure Ideen in einem Datenbankdiagramm umzusetzten.
Habe ich das so richtig verstanden?

[Linor]

Nein, eigentlich nicht, denn aus deiner Struktur heraus hat jedes Gerät genau eine Checkliste, und damit sind die anderen fast alle über...

Du brauchst dann nur eine Tabelle mit den Feldern: Gerät, Schlüssel, Typ, Daten

Ob du die Schlüssel in einer Tabelle definierst, kommt drauf was du damit machen willst und woher die Daten kommen. Sinn macht das wenn du eine Suche auslösen willst: Alle Geräte die VOLTAGE = 230 haben... Dann könntest du auch das Feld Typ weglassen und dieses in die Schlüssel-Tabelle verlagern:

Tabelle 1: Gerät, Bezeichnung
Tabelle 2: Schlüssel, Typ
Tabelle 3: Gerät, Schlüssel, Daten

Nur später darauf achten, das einmal angelegte Schlüssel nur schwerlich wieder änderbar sind. Sollten anlegbar und löschbar sein. Änderbar erfordert evtl. ein konvertieren aller Daten in Tabelle 3.

[Daniela.S]

Kann es sein, dass du so etwas in der Richtung brauchst (als ERM Dargestellt)?
Eine extra Tabelle für "Checkliste" ist nicht unbedingt notwendig, da die nur eine 1:1 Beziehung zu Tabelle "Typ" eingehen würde.

Der Wert selbst wäre eine n:m Verbindung, sprich eine eigene Tabelle mit FK von "Gerät" und "Property" an der auch das Attribut "Value" hängt...

[Iwo Asnet]

Zitat von Linor:

Nur später darauf achten, das einmal angelegte Schlüssel nur schwerlich wieder änderbar sind. Sollten anlegbar und löschbar sein. Änderbar erfordert evtl. ein konvertieren aller Daten in Tabelle 3.

Deswegen nimmt man dafür nichtsprechende Schlüssel, wie z.B. Zähler oder GUID. Beides wird von RDBMS unterstützt (Generatoren, AutoInc, Identity, etc.).



@Daniela: Wenn man Gerätetypen hat (also mehrere Geräte eines Typs) aber pro Gerätetyp jeweils genau und nur eine Checkliste, dann müsste man das erweitern. Ich denke auch, eine Checkliste pro Gerät(etyp) reicht erst einmal, oder?

[Daniela.S]

In dem Fall, den ich modelliert habe, hätte man eine Checkliste pro Gerätetyp. Man müsste also nicht jedes mal eine neue Checkliste anlegen wenn ein Gerät des gleichen Typs angelegt wird, denn jeder Typ hat seine vordefinierte Checkliste. Die muss man nur anlegen wenn ein neuer Gerätetyp angelegt wird. Der Wert selber wird über Property und Gerät referenziert.