ドラフトモデル（ 次の6NF
および3NF）が役立ちます。
「shop」キーワードを削除して命名規則を簡略化しました。
（また、ショップエンティティは別の概念AKA SaaSをリードする場合があります）
SqlFiddleデモ
コメントの質問について：
はい、代理識別子
を使用するのが一般的なパターンです。 あなたのテーブルに。記事でわかるように、これには長所と短所があります。
たとえば、質問では、ProductSpecificationの主キーが表示されます。 テーブルはProductTypeOptionsの構成です 、OptionValue およびProduct 外部キー。
それまでの間、OptionValueなどの他のテーブルの主キー 複合キーです（OptionId + ValueName ）
IDを持っている方が人生はもっと簡単になるようです すべてのテーブルのフィールドを主キーとして使用します。そうですが、データベースデザイナーとして、価値のあるビジネスロジックを失うことになります。 。
現在の設計では、製品仕様テーブルでこれらの制約を設定できます。これらの制約は、ビジネスロジックの一部を示します。
-
ProductSpecificationの制約を確認します{OptionValue.optionId = productTypeOption.optionId}これにより、「白」などの値が「サイズ」に割り当てられるのを防ぐことができます。 -
ProductSpecificationの制約を確認します{product.productTypeId = productTypeOption.productTypeId}これにより、「Nike」のような製品が「Cars」のproductSpecificationsに割り当てられるのを防ぐことができます。
サロゲート識別子を使用する場合、データベース内にこれらのタイプの制約を設定することはできません（これを試してください）。
それらを取得するには、アプリケーション実装内で追加の作業を行う必要があります。
BTW 代理識別子を使用し、データの整合性を確認します
、興味がある場合は、主キーの選択：ナチュラルまたはサロゲート
を参照してください。 。
「ナイキ」の「メンズシューズ」は、価格、在庫、追加料金が必要なようですので、Productの自然な財産です。 テーブル。