Creo que el borrador del modelo (después de 6NF
y 3NF) lo ayudarán.
Simplifiqué la convención de nomenclatura eliminando la palabra clave 'tienda'.
(También la entidad de la tienda puede liderar un concepto separado, también conocido como SaaS)
Demostración de SqlFiddle
Sobre las preguntas en los comentarios:
Sí, es un patrón común usar identificador sustituto
en vuestras mesas. Como puede ver en el artículo, eso vendrá con sus ventajas y desventajas.
Por ejemplo, en la pregunta, verá la clave principal de ProductSpecification la tabla es una composición de ProductTypeOptions , OptionValue y Product claves foráneas.
Mientras tanto, la clave principal de otras tablas como OptionValue es una clave compuesta (OptionId + ValueName )
Parece que la vida será más fácil con una ID campo en cada tabla como la clave principal, sí lo es, pero como diseñador de bases de datos perderá algo valioso, lógica de negocios .
En el diseño actual, puede tener estas restricciones en la tabla de especificaciones del producto, que mostrarán parte de su lógica empresarial:
- Verifique la restricción en
ProductSpecification{OptionValue.optionId = productTypeOption.optionId}eso evitará que se asigne un valor como "Blanco" a "Tamaño". - Verifique la restricción en
ProductSpecification{product.productTypeId = productTypeOption.productTypeId}eso evitará que un producto como "Nike" se asigne a productSpecifications de "Cars".
Si usa un identificador sustituto, no puede tener este tipo de restricciones dentro de su base de datos (pruebe esto).
Será necesario realizar un trabajo adicional dentro de la implementación de su aplicación para obtenerlas.
Por cierto usar identificador sustituto, verificar consistencia de datos
, si está más interesado, consulte elegir una clave principal:natural o sustituta
.
Parece que "Zapatillas de hombre" de "Nike" necesita tener precio, stock y recargo, por lo que son propiedad natural de Product mesa.
