Myślę, że projekt modelu (po 6NF
i 3NF).
Uprościłem konwencję nazewnictwa, usuwając słowo kluczowe „sklep”.
(Również encja sklep może prowadzić osobną koncepcję AKA SaaS)
SqlFiddle Demo
O pytaniach w komentarzach:
Tak, powszechnym wzorcem jest użycie identyfikatora zastępczego
na twoich stołach. Jak możesz zobaczyć w artykule, będzie to miało swoje zalety i wady.
Na przykład w pytaniu zobaczysz klucz podstawowy ProductSpecification tabela jest kompozycją ProductTypeOptions , OptionValue i Product klucze obce.
Tymczasem klucz podstawowy innych tabel, takich jak OptionValue jest kluczem złożonym (OptionId + ValueName )
Wygląda na to, że łatwiej będzie mieć ID pole w każdej tabeli jako klucz podstawowy, tak, ale jako projektant baz danych stracisz coś cennego, logikę biznesową .
W obecnym projekcie możesz mieć te ograniczenia w tabeli Product-Specification, pokażą one część logiki biznesowej:
- Sprawdź ograniczenie w
ProductSpecification{OptionValue.optionId = productTypeOption.optionId}co zapobiegnie przypisaniu wartości takiej jak „Biały” do „Rozmiaru”. - Sprawdź ograniczenie w
ProductSpecification{product.productTypeId = productTypeOption.productTypeId}co uniemożliwi przypisanie produktu takiego jak „Nike” do specyfikacji produktu „Samochody”.
Jeśli używasz identyfikatora zastępczego, nie możesz mieć tego typu ograniczeń w swojej bazie danych (spróbuj tego).
Dodatkowa praca będzie potrzebna do wykonania w ramach implementacji aplikacji, aby je uzyskać.
BTW użyj identyfikatora zastępczego, sprawdź spójność danych
, jeśli jesteś bardziej zainteresowany, zobacz wybór klucza podstawowego:naturalnego lub zastępczego
.
Wygląda na to, że „Buty męskie” marki „Nike” muszą mieć cenę, zapasy i dopłaty, więc są one naturalną własnością Product tabela.
