Ich denke, das Entwurfsmodell (nach 6NF
und 3NF) wird Ihnen helfen.
Ich habe die Namenskonvention vereinfacht, indem ich das Schlüsselwort „Shop“ entfernt habe.
(Auch Shop-Einheiten führen möglicherweise ein separates Konzept, auch bekannt als SaaS)
SqlFiddle-Demo
Zu den Fragen in den Kommentaren:
Ja, es ist ein gängiges Muster, Ersatzkennung
zu verwenden auf Ihren Tischen. Wie Sie dem Artikel entnehmen können, hat dies Vor- und Nachteile.
Zum Beispiel sehen Sie in der Frage diesen Primärschlüssel von ProductSpecification Tabelle ist eine Zusammensetzung von ProductTypeOptions , OptionValue und Product Fremdschlüssel.
Mittlerweile Primärschlüssel anderer Tabellen wie OptionValue ist ein zusammengesetzter Schlüssel (OptionId + ValueName )
Es sieht so aus, als wäre das Leben einfacher, eine ID zu haben Feld in jeder Tabelle als Primärschlüssel, ja, aber als Datenbankdesigner verlieren Sie etwas Wertvolles, Geschäftslogik .
Im aktuellen Design können Sie diese Einschränkungen in der Produktspezifikationstabelle haben, sie zeigen einen Teil Ihrer Geschäftslogik:
- Überprüfen Sie die Beschränkung auf
ProductSpecification{OptionValue.optionId = productTypeOption.optionId}das wird verhindern, dass ein Wert wie "Weiß" zu "Größe" zugewiesen wird. - Überprüfen Sie die Beschränkung auf
ProductSpecification{product.productTypeId = productTypeOption.productTypeId}Dadurch wird verhindert, dass ein Produkt wie "Nike" den Produktspezifikationen von "Autos" zugeordnet wird.
Wenn Sie einen Ersatzidentifikator verwenden, können Sie diese Art von Einschränkungen nicht in Ihrer Datenbank haben (versuchen Sie dies).
In Ihrer Anwendungsimplementierung muss zusätzliche Arbeit geleistet werden, um sie zu erhalten.
Übrigens Ersatzkennung verwenden, Datenkonsistenz prüfen
, bei mehr Interesse siehe Wählen eines Primärschlüssels:Natürlich oder Ersatz
.
Es scheint, dass "Herrenschuhe" von "Nike" Preis, Lagerbestand und Aufpreis haben müssen, also sind sie natürliches Eigentum von Product Tabelle.
