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
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
Comment