Мисля, че черновият модел (следвайки 6NF
и 3NF) ще ви помогне.
Опростих конвенцията за именуване, като премахнах ключовата дума 'shop'.
(Също така обектът на магазина може да води отделна концепция, наречена SaaS)
SqlFiddle Демо
Относно въпросите в коментарите:
Да, често срещан модел е да се използва сурогатен идентификатор
на вашите маси. Както може да видите в статията, това ще дойде със своите плюсове и минуси.
Например във въпроса ще видите този първичен ключ на ProductSpecification таблицата е състав от ProductTypeOptions , OptionValue и Product външни ключове.
Междувременно първичен ключ на други таблици като OptionValue е съставен ключ (OptionId + ValueName )
Изглежда, че животът ще бъде по-лесно да имате ID поле във всяка таблица като първичен ключ, да, така е, но като дизайнер на база данни ще загубите нещо ценно, бизнес логика .
В текущия дизайн можете да имате тези ограничения в таблицата със спецификации на продукта, те ще покажат част от вашата бизнес логика:
- Проверете ограничението в
ProductSpecification{OptionValue.optionId = productTypeOption.optionId}това ще предотврати присвояването на стойност като "White" на "Размер". - Проверете ограничението в
ProductSpecification{product.productTypeId = productTypeOption.productTypeId}това ще попречи на продукт като „Nike“ да бъде присвоен към продуктовите спецификации на „Автомобили“.
Ако използвате сурогатен идентификатор, не можете да имате този тип ограничения във вашата база данни (опитайте това).
Ще е необходима допълнителна работа в реализацията на приложението, за да ги получите.
BTW използвайте сурогатен идентификатор, проверете последователността на данните
, ако се интересувате повече, вижте избиране на първичен ключ:естествен или сурогатен
.
Изглежда, че "Мъжки обувки" на "Nike" трябва да има цена, наличност и доплащане, така че те са естествена собственост на Product таблица.
