Acho que o modelo de rascunho (seguindo 6NF e 3NF) irá ajudá-lo.
Simplifiquei a convenção de nomenclatura removendo a palavra-chave 'shop'.
(Também a entidade de loja pode liderar um conceito separado AKA SaaS)

Demonstração do SqlFiddle





Sobre as perguntas nos comentários:


Sim, é um padrão comum usar identificador substituto em suas mesas. Como você pode ver no artigo, isso virá com seus prós e contras.

Por exemplo, na pergunta, você verá a chave primária de ProductSpecification tabela é uma composição de ProductTypeOptions , OptionValue e Product chaves estrangeiras.
Nesse meio tempo, a chave primária de outras tabelas como OptionValue é uma chave composta (OptionId + ValueName )
Parece que a vida será mais fácil ter um ID campo em cada tabela como a chave primária, sim, mas como designer de banco de dados, você perderá algo valioso, lógica de negócios .

No design atual você pode ter essas restrições na tabela Product-Specification, elas mostrarão parte da sua lógica de negócios:

• Verifique a restrição em ProductSpecification {OptionValue.optionId = productTypeOption.optionId} isso impedirá que um valor como "Branco" seja atribuído a "Tamanho".
• Verifique a restrição em ProductSpecification {product.productTypeId = productTypeOption.productTypeId} que impedirá que um produto como "Nike" seja atribuído a especificações do produto de "Carros".

Se você usa um identificador substituto, você não pode ter esse tipo de restrição dentro de seu banco de dados (tente isso).
Trabalho extra será necessário para ser feito dentro de sua implementação de aplicativo para obtê-los.
BTW use o identificador substituto, verifique a consistência dos dados , se estiver mais interessado, consulte escolhendo uma chave primária:natural ou substituto .



Parece que "Sapato Masculino" da "Nike" precisa ter preço, estoque e sobretaxa, então eles são propriedade natural do Product tabela.