Myslím, že návrh modelu (po 6NF
a 3NF) vám pomohou.
Zjednodušil jsem konvenci pojmenování odstraněním klíčového slova 'obchod'.
(Také entita obchodu může vést samostatný koncept AKA SaaS)
Ukázka SqlFiddle
O otázkách v komentářích:
Ano, je běžným vzorem použití náhradního identifikátoru
na vašich stolech. Jak můžete vidět v článku, bude to mít své klady a zápory.
Například v otázce uvidíte primární klíč ProductSpecification tabulka je složením ProductTypeOptions , OptionValue a Product cizí klíče.
Mezitím primární klíč jiných tabulek, jako je OptionValue je složený klíč (OptionId + ValueName )
Zdá se, že život bude snazší mít ID pole v každé tabulce jako primární klíč, to ano, ale jako návrhář databází ztratíte něco cenného, obchodní logiku .
V aktuálním návrhu můžete mít tato omezení v tabulce Product-Specification, budou zobrazovat část vaší obchodní logiky:
- Zkontrolujte omezení v
ProductSpecification{OptionValue.optionId = productTypeOption.optionId}to zabrání přiřazení hodnoty jako „Bílá“ k „Velikost“. - Zkontrolujte omezení v
ProductSpecification{product.productTypeId = productTypeOption.productTypeId}to zabrání tomu, aby byl produkt jako „Nike“ přiřazen ke specifikacím produktu „Auta“.
Pokud používáte zástupný identifikátor, nemůžete mít tento typ omezení ve své databázi (zkuste to).
K jejich získání bude potřeba provést další práci v implementaci vaší aplikace.
BTW použít náhradní identifikátor, zkontrolovat konzistenci dat
, pokud máte další zájem, podívejte se na výběr primárního klíče:přirozený nebo náhradní
.
Zdá se, že "Pánské boty" od "Nike" musí mít cenu, sklad a příplatek, takže jsou přirozenou vlastností Product tabulka.