Jeg tror, udkastet til modellen (følger 6NF
og 3NF) vil hjælpe dig.
Jeg forenklede navnekonventionen ved at fjerne 'shop'-søgeordet.
(Butiksenhed kan også lede et separat koncept AKA SaaS)
SqlFiddle Demo
Om spørgsmålene i kommentarerne:
Ja, det er et almindeligt mønster at bruge surrogat-id
på dine borde. Som du måske kan se i artiklen, vil det komme med sine fordele og ulemper.
For eksempel vil du i spørgsmålet se den primære nøgle til ProductSpecification tabel er en sammensætning af ProductTypeOptions , OptionValue og Product fremmednøgler.
I mellemtiden primær nøgle for andre tabeller som OptionValue er en sammensat nøgle (OptionId + ValueName )
Det ser ud til, at livet bliver nemmere at have et ID felt i hver tabel som den primære nøgle, ja det er det, men som databasedesigner vil du miste noget værdifuldt, forretningslogik .
I det nuværende design kan du have disse begrænsninger i produktspecifikationstabellen, de vil vise en del af din forretningslogik:
- Tjek begrænsning på
ProductSpecification{OptionValue.optionId = productTypeOption.optionId}der forhindrer en værdi som "Hvid" i at blive tildelt "Størrelse". - Tjek begrænsning på
ProductSpecification{product.productTypeId = productTypeOption.productTypeId}der forhindrer et produkt som "Nike" i at blive tildelt produktspecifikationer for "Biler".
Hvis du bruger surrogat-id, kan du ikke have denne type begrænsninger inde i din database (prøv dette).
Der vil være behov for ekstra arbejde i din applikationsimplementering for at få dem.
BTW brug surrogat-id, kontroller datakonsistens
, hvis mere interesseret se valg af en primær nøgle:naturlig eller surrogat
.
Det lader til, at "Herresko" fra "Nike" skal have pris, lager og tillæg, så de er naturlig ejendom tilhørende Product tabel.