Je pense que le projet de modèle (suivant 6NF
et 3NF) vous aideront.
J'ai simplifié la convention de nommage en supprimant le mot-clé "boutique".
(L'entité boutique peut également mener à un concept distinct AKA SaaS)
Démo SqlFiddle
À propos des questions dans les commentaires :
Oui, c'est un modèle courant d'utiliser identifiant de substitution
sur vos tables. Comme vous pouvez le voir dans l'article, cela viendra avec ses avantages et ses inconvénients.
Par exemple, dans la question, vous verrez cette clé primaire de ProductSpecification table est une composition de ProductTypeOptions , OptionValue et Product clés étrangères.
En attendant la clé primaire d'autres tables comme OptionValue est une clé composée (OptionId + ValueName )
Il semble que la vie sera plus facile d'avoir un ID champ dans chaque table comme clé primaire, oui, mais en tant que concepteur de base de données, vous perdrez quelque chose de précieux, logique métier .
Dans la conception actuelle, vous pouvez avoir ces contraintes dans le tableau Product-Specification, elles montreront une partie de votre logique métier :
- Vérifier la contrainte sur
ProductSpecification{OptionValue.optionId = productTypeOption.optionId}cela empêchera une valeur comme "Blanc" d'être affectée à "Taille". - Vérifier la contrainte sur
ProductSpecification{product.productTypeId = productTypeOption.productTypeId}cela empêchera un produit comme "Nike" d'être attribué aux spécifications de produit de "Voitures".
Si vous utilisez un identifiant de substitution, vous ne pouvez pas avoir ce type de contraintes dans votre base de données (essayez ceci).
Un travail supplémentaire sera nécessaire à l'intérieur de l'implémentation de votre application pour les obtenir.
BTW utiliser un identifiant de substitution, vérifier la cohérence des données
, si plus intéressé voir choisir une clé primaire :naturelle ou de substitution
.
Il semble que "Mens Shoe" de "Nike" doit avoir un prix, un stock et un supplément, ils sont donc la propriété naturelle de Product tableau.
