Datenbankkonzept: Attribute als Werte und nicht als Spalten

[Rapunzel]

Guten Abend,

ich stehe vor der Aufgabe eine Datenbank für Stammdaten bezüglich Produkteigenschaften zu entwerfen. In der Regel setzt sich ja ein Tupel über die Spalten zusammen, in denen die Eigenschaftswerte der Attribute gespeichert sind.

Dieses Konzept finde ich allerdings in Bezug auf eine Produktdatenbank überhaupt nicht sinnvoll, da unterschiedliche Produkte unterschiedliche Eigenschaften besitzen können bzw. werden und eine Realisierung über Tabellenspalten meiner Meinung nach nicht zielführend ist, da laufend neue
Eigenschaften hinzukommen können und somit der Client fortlaufend um die neuen Eigenschaften erweitert werden müsste.

Um dieses Problem zu lösen, denke ich an eine Art Key-Value-Store, wobei ich
Key-Value-Store dem NoSQL-Lager entliehen habe. Konkret mach es doch Sinn,
nach folgendem Schema vorzugehen:

Tabelle 'Artikel' enthält zum Beispiel die nötigen Metainformationen wie
'Angelegt am', 'Geändert am', 'Datensatzersteller' und die generellen Indentifikationsdaten wie 'Artikelnummer <primary key>, 'Hersteller', 'Artikelbezeichnung' etc.

In einer zweiten Tabelle, nennen wir sie mal 'Artikeleigenschaften', erfolgt jetzt die Zuordnung der Eigenschaften und den Eigenschaftswerten mit den Artikeln. Die Eigenschaften müssen zuvor natürlich über eine weitere Tabelle definiert werden. Beispiel: 'Eigenschaftsnummer <primary key>, 'Eigenschaft'.

Beispiel einer Artikelzuordnung:

ID ArtNr Eigenschaftsnummer Eigenschaftswert
1 1000 8 500 <Meter>


Meine Frage ist an dieser Stelle, ob meine Ausführungen überhaupt Sinn ergeben, oder ob sie dem Modell der relationalen Datenbanken widersprechen.
Musste von euch schon einmal jemand eine ähnliche Aufgabenstellung meistern bzw. welches Datenbankmodell (Relational, NoSQL, Objekt relational) habt ihr
verwendet.

Gibt es einen entsprechenden Fachausdruck für diese Art von Datenbankgestaltung, bzw. gibt es weiterführende Literatur zu dem Thema "Attribute als Werte und nicht als Spalten"?


Anmerkung: Da es in dem Teil "Datenbanken" dieses Forums kein "Allgemein" gibt, habe ich mir erlaubt meine Frage unter "SQL" anzulegen. Wenn dies jetzt falsch ist, dann bitte korrigieren.

Gruß

Rapunzel

[Christian Marquardt]

übliches Vorgehen

http://de.wikipedia.org/wiki/Kardina...odellierung%29

[Ralf Jansen]

Wenn du kein festes Schema hast bieten sich üblicherweise die dokumentenbasierten Datenbanken an. Aber ob das wirklich passt oder ob du bei einem klassischen relationalen System besser/schlechter aufgehoben bist erschließt sich glaube ich erst wenn du dir überlegst (und/oder uns erzählst) welche Art von Abfragen du über die ~dynamischen~ Attribute von Artikeln ausführen willst. Dann kann man sich überlegen wie man die am besten ablegt. Da du andeutest das du deinen Client nicht anpassen möchtest bei neuen Attributen deduziere ich daraus das du mit den zusätzlichen Attributen nicht viel mehr vorhast als sie abzulegen und anzuzeigen. Dann ist vermutlich fast egal wie du die ablegst. Dann kann man sich auch überlegen ob es überhaupt Sinn macht die in irgendwas zu Zerlegen. Eventuell ist es dann sogar besser die einfach in irgendeinem beliebigen Format in ein Feld deiner Artikeltabelle als Ganzes zu werfen.

[Falk Prüfer]

Hallo,

...Anmerkung: Da es in dem Teil "Datenbanken" dieses Forums kein "Allgemein" gibt, habe ich mir erlaubt meine Frage unter "SQL" anzulegen. Wenn dies jetzt falsch ist, dann bitte korrigieren.

Gut, "Allgemein" gibt es nicht - heist hier "Diverses" ...

[defo]

Deine Gedanken machen schon Sinn. Ich hatte leider noch keine Gelegenheit, eine solches Verfahren weitreichend umzusetzen.
Wenn Du jedoch eine solche Struktur anlegst, musst Du Dir darüber klar sein, wie Du sie weiterverarbeiten willst. Wie werden Datenpflege, Darstellung und Reporting gemacht? M.E. benötigst Du dafür generische Formulare und Reports, da es ansonsten kaum zu realisieren ist, für alle (wachsenden) Varianten individuelle Reports und Masken zu erstellen.

Die von Dir beschriebene Datenstruktur ist problemlos in einer relationale DB unterzubringen. noSQL und objektrelationale Systeme sind natürlich für soetwas geschaffen, kenne ich in der Praxis aber nicht. Es könnten sich damit Probleme mit Migration, Schnittstellen und Performance ergeben.

Eine Abwandlung Deines Verfahrens wäre die Schaffung von Produktklassen. D.h. Du wendest Deine Idee nicht auf Produktebene an, sondern etwas allgemeiner.

[Wernfried]

Grundsätzlich kann man das so machen und es funktioniert auch.

Eine andere Variante wäre dass du die Eigenschaften doch in Spalten ablegst und den Client so programmierst, dass er zuerst die Attribute ermittelt und dann die entsprechende SQL-Abfrage dynamisch aufbaut und ausführt.

Spontan würde ich aber auch zu der Variante von defo hin tendieren. Also nicht eine grosse Tabelle für alle Artikel, sondern für jede Artikelgruppe, bzw. Artikelklasse eine Tabelle mit den entsprechenden Attributen. Natürlich ist es auch dabei von Vorteil wenn der Client die Liste mit den Attributen dynamisch erstellt.

Gruss