Anfängerfrage: Hierarchische Struktur modellieren

KeineAhnung

Benutzer
Beiträge
5
Hallo zusammen,

bevor ich richtig loslege mit meiner Motordatenbank, muss ich doch einmal dieses schöne Forum bemühnen. Ich habe meine alten Vorlesungsunterlagen zu Datenbabsystemen hervorgeholt und stehe nun beim Umdenken von OO-Programmierung auf relationale Tabellen etwas auf dem Schlauch. Ich finde Beispiele für das Umsetzen von netzwerkartigen Verbindungen (klassisches Beispiel: ein Produkt besteht aus Baugruppen und Einzelteilen, die zusammengesetztwerden), darauf würde ich evtl zurückgreifen, aber ich würde es gerne etwas weniger kryptisch haben.

Kurzum: Es geht darum, in der Datenbank abzubilden, was ich sonst klassisch über Vererbung machen würde.

Beispiel: Ein Motor hat einen Stator und einen Rotor.

Nun gibt es unterschiedliche Arten von Rotoren, so dass es unterschiedliche Tabellen geben muss, die jeweils einen Rotortyp beschreiben.


Also wäre eine Idee mit 4 Tabellen (beschränkt auf die Rotorproblematik):

Motor(MotorID, StatorID, RotorID, ...)
Rotorkonfiguration(RotorID, Rotortyp1ID, Rotortyp2ID)
Rotortyp1(Rotortyp1ID, Merkmal1, Merkmal2, ...)
Rotortyp2(Rotortyp2ID, Merkmal1a, Merkmal2a, ...)

Jetzt wäre es so, dass in Rotorkonfiguration für jede RotorID nur entweder Rotortyp1ID ODER Rotortyp2ID besetzt sein darf, da es genau einen Rotortyp gibt und niemals beide in einem Motor. Ist das überhaupt zulässiger Stil (unsicher? fehleranfällig?)? Was sagen die Fachleute?

Vielen Dank für Hinweise!
 
Werbung:
Dann muss eine neue Tabelle Rotortyp3 angelegt werden und die Tabelle Rotorkonfiguration angepasst werden. Oder? Gibt es einen guten Ansatz, der generischer wäre?

Das ist übrigens sogar ein recht wahrscheinlicher Fall.
 
So ein Konzept skaliert also nicht, was Du suchst nennt sich Normalisierung. Vermutlich haben die Rotoren unterschiedliche Eigenschaften, oder? Das wird dann oft via EAV-Prinzip gelöst, was aber recht unhandlich ist. Ein cooler Ansatz wäre hier dann die Verwendung von Key-Value-Stores oder JSON. In PG könntest Du dafür HSTORE oder JSONB verwenden.
 
Jo, jetzt bin ich raus :). Normalisierung sagt mir noch was, der Rest eher nicht.

Aber ist mein Problem denn so ungewöhnlich? Ich würde erwarten, dass ein Großteil von Datenbanken derartige Konstrukte enthält.

Egal, ob Motor, Küchengerät, sonstige technische Sachen. Immer kann man in Mutter-Kind-Beziehungen denken. Denkt der Datenbanker einfach aus einer anderen Richtung?

Richtig ist, daher meine Unterscheidung in "Merkmal1" bzw. "Merkmal1a", die Rotoren haben unterschiedlichen Eigenschaften!

Sogar wenn ich mir eine einfache Literaturliste machen würde, hätte ein Paper andere Eigenschaften als ein Buchband, beites wäre aber ein "Stück Literatur" für mich. Ich bin vielleicht etwas gefangen in der Objektorientierung.
 
Ich sagte ja; EAV. Das macht z.B. Magento so, das ist eine Shopsoftware. Das ist aber gruselig, glaub mir. Ich zeige Dir, wie es elegant geht. Du hast eine Tabelle für alle Rotoren, in einem JSONB-Feld stehen die Eigenschaften. Du kannst z.B. alle mit Records suchen, die eine bestimmte Eigenschaft haben:

Code:
test=# create table rotoren(id int primary key, name text, eigenschaften jsonb);
CREATE TABLE
test=*# create index idx_rotoren_eigenschaften on rotoren using gin (eigenschaften);
CREATE INDEX
test=*# insert into rotoren values (1, 'Rotor 1', '{"Farbe": "rot", "Masse": "2kg"}');
INSERT 0 1
test=*# insert into rotoren values (2, 'Rotor 2', '{"Laenge": "50cm", "Breite": "10cm"}');
INSERT 0 1
test=*# select * from rotoren where eigenschaften ? 'Farbe';
 id |  name  |  eigenschaften   
----+---------+----------------------------------
  1 | Rotor 1 | {"Farbe": "rot", "Masse": "2kg"}
(1 row)

test=*# select * from rotoren where eigenschaften ? 'Breite';
 id |  name  |  eigenschaften   
----+---------+--------------------------------------
  2 | Rotor 2 | {"Breite": "10cm", "Laenge": "50cm"}
(1 row)

test=*# explain select * from rotoren where eigenschaften ? 'Breite';
  QUERY PLAN   
-----------------------------------------------------------------------------------------
 Bitmap Heap Scan on rotoren  (cost=12.01..16.02 rows=1 width=68)
  Recheck Cond: (eigenschaften ? 'Breite'::text)
  ->  Bitmap Index Scan on idx_rotoren_eigenschaften  (cost=0.00..12.01 rows=1 width=0)
  Index Cond: (eigenschaften ? 'Breite'::text)
(4 rows)

test=*#

Und wie man sieht, geht das (also die Suche) über den Index.
 
OK, danke, das zieh ich mir mal rein!

Aber damit lege ich mich auf PostgreSQL fest oder? Wenn jemand mit Access um die Ecke kommt, wird´s düster...
 
Werbung:
Zurück
Oben