Jag tror att utkastet till modellen (följer 6NF
och 3NF) kommer att hjälpa dig.
Jag förenklade namnkonventionen genom att ta bort nyckelordet 'butik'.
(Också butiksenheten kan leda ett separat koncept AKA SaaS)
SqlFiddle Demo
Om frågorna i kommentarerna:
Ja, det är ett vanligt mönster att använda surrogatidentifierare
på dina bord. Som du kanske ser i artikeln kommer det att ha sina för- och nackdelar.
Till exempel, i frågan kommer du att se den primära nyckeln för ProductSpecification tabellen är en sammansättning av ProductTypeOptions , OptionValue och Product främmande nycklar.
Under tiden primärnyckeln för andra tabeller som OptionValue är en sammansatt nyckel (OptionId + ValueName )
Det ser ut som att livet kommer att bli lättare att ha ett ID fält i varje tabell som primärnyckel, ja det är det, men som databasdesigner kommer du att förlora något värdefullt, affärslogik .
I den nuvarande designen kan du ha dessa begränsningar i produktspecifikationstabellen, de kommer att visa en del av din affärslogik:
- Kontrollera begränsningen på
ProductSpecification{OptionValue.optionId = productTypeOption.optionId}som förhindrar att ett värde som "Vit" tilldelas "Storlek". - Kontrollera begränsningen på
ProductSpecification{product.productTypeId = productTypeOption.productTypeId}som förhindrar att en produkt som "Nike" tilldelas produktspecifikationer för "Bilar".
Om du använder surrogatidentifierare kan du inte ha den här typen av begränsningar i din databas (prova detta).
Extra arbete kommer att behöva göras i din applikationsimplementering för att få dem.
BTW använd surrogatidentifierare, kontrollera datakonsistens
, om mer intresserade se välja en primärnyckel:naturlig eller surrogat
.
Det verkar som om "Herrsko" från "Nike" måste ha pris, lager och tilläggsavgift, så de är naturliga egendomar för Product bord.