SQL: La normalización de la base de datos, manteniendo las restricciones

Question

Supongamos que tengo las siguientes tablas:

 ____________________    ____________________ 
    |  Organisms  |   |  Species  | 
    |--------------------|   |--------------------| 
    |OrganismId (int, PK)|   |SpeciesId (int, PK) | 
    |SpeciesId (int, FK) |∞---------1|Name (varchar)  | 
    |Name (varchar)  |   |____________________| 
    |____________________|      1 
       1         | 
       |         | 
       |         | 
       ∞         ∞ 
    ______________________  ____________________   _______________ 
    | OrganismPropsValues |  | SpeciesProps  |  |  Props  | 
    |----------------------|  |--------------------|  |---------------| 
    |OrganismId (int, FK) |  |PropId (int,PK,FK) | ∞-----1|PropId (int,PK)| 
    |PropId (int, FK)  |  |SpeciesId(int,PK,FK)|  |Name (varchar) | 
    |Value (varchar)  |  |____________________|  |_______________| 
    |______________________|            1 
       ∞               | 
       |               | 
       ----------------------------------------------------------- 

Una explicación rápida de lo que estoy tratando de representar aquí: Supongamos que tenemos una lista de especies, tales como gato, perro , humanos, etc. También tenemos un conjunto de propiedades (Apoyos abreviados para que se ajusten más fácilmente en el diagrama) que se aplican a algunas especies, pero no necesariamente a todas; por ejemplo, puede ser la longitud de la cola (para especies con colas)), color de ojos (para aquellos con ojos), etc.

SpeciesProps es una tabla de engarce que define qué propiedades se aplican a qué especie-- así que aquí Tiene {Human, Eye Color}, {Dog, Eye Color}, {Cat, Eye Color}, {Dog, Tail Length}, {Cat, Tail Length}. No tenemos {Human, Tail Length} porque la longitud de cola obviamente no es una propiedad válida para aplicar a un ser humano.

La tabla de Organismos contiene "implementaciones" reales de la especie-- Así que aquí podríamos tener {Humanos, Bob}, {Perro, Rufus}, y {Gato, Felix}.

Aquí está mi problema: en la tabla OrganismPropsValues, quiero almacenar los 'valores' de las propiedades para cada organismo; por ejemplo, para Bob quiero almacenar {Bob, Eye Color, Blue}. Para Rufus, me gustaría almacenar {Rufus, Eye Color, Brown} y {Rufus, Tail Length, 20} (similar para Felix). Mi problema, sin embargo, es que en el esquema que he detallado, es perfectamente posible almacenar {Bob, Tail Length, 10}, aunque la tupla {Human, Tail Length} no exista en SpeciesProps. ¿Cómo puedo modificar este esquema para poder aplicar las restricciones definidas en SpeciesProps en OrganismPropsValues, manteniendo una normalización adecuada?

Answer 1

Estás aplicación del antipatrón Entity-Attribute-Value. Esto no puede ser un diseño de base de datos normalizado, porque no es relacional.

Lo que sugeriría su lugar es el patrón de diseño Class Table Inheritance:

• Crear una tabla para los organismos, que contiene propiedades comunes a todas las especies.

• Cree una tabla por especie, que contenga propiedades específicas de esa especie. Cada una de estas tablas tiene una relación de 1 a 1 con Organismos, pero cada propiedad pertenece a su propia columna.

  ____________________    ____________________ 
  |  Organisms  |   |  Species  | 
  |--------------------|   |--------------------| 
  |OrganismId (int, PK)|   |SpeciesId (int, PK) | 
  |SpeciesId (int, FK) |∞---------1|Name (varchar)  | 
  |Name (varchar)  |   |____________________| 
  |____________________| 
        1 
        | 
        | 
        1 
  ______________________ 
  | HumanOrganism  | 
  |----------------------| 
  |OrganismId (int, FK) | 
  |Sex  (enum)  | 
  |Race  (int, FK) | 
  |EyeColor (int, FK) | 
  |....     | 
  |______________________| 
  

Esto quiere decir que va a crear muchas mesas, pero considera esto como una solución de compromiso con los muchos beneficios prácticos para almacenar propiedades de una manera relacional correcta:

• Usted puede utilizar los datos de SQL tipos apropiadamente, en lugar de tratar todo un varchar de forma libre.
• Puede usar restricciones o tablas de búsqueda para restringir ciertas propiedades mediante un conjunto predefinido de valores.
• Puede hacer que las propiedades sean obligatorias (es decir, NO NULAS) o usar otras restricciones.
• Los datos y los índices se almacenan de manera más eficiente.
• Las consultas son más fáciles de escribir y el RDBMS más fácil de ejecutar.

Para más información sobre este diseño, ver el libro de Martin Fowler Patterns of Enterprise Application Architecture, o mi presentación Practical Object-Oriented Models in SQL, o mi libro, SQL Antipatterns: Avoiding the Pitfalls of Database Programming.

Answer 2

Hmm ...
Aquí es una manera de hacerlo:
Añadir SpeciesPropsId en la tabla SpeciesProps.
Reemplazar PropId con SpeciesPropsId en la tabla OrganismPropsValues.
Deberá cambiar las restricciones un poco.
Es necesario agregar SpeciesProps a OrganismPropsValues ​​constrain.
Necesidad de eliminar OrganismPropsValues ​​to Props constrain.

Técnicamente no es necesario eliminar PropId de OrganismPropsValues, pero si lo conserva redundará en redundancia de datos.

Answer 3

Otra forma de lograr estas restricciones sería cambiar la PK de la tabla Organism dejando caer OrganismId y agregando un No. Luego haga PK el compuesto (SpeciesId, No). Por lo tanto, habría "Bob"(Human, 1), "Rufus" habría (Dog, 1), etc.

A continuación, agregue en la tabla OrganismPropsValues, la SpeciesId y la No (eliminación de la OrganismId.)

Esto permitirá cambiar el FK desde OrganismPropsValuesProps a hacer referencia a SpeciesProps lugar:

 ____________________    ____________________ 
    |  Organisms  |   |  Species  | 
    |--------------------|   |--------------------| 
    |SpeciesId (int, FK) |   |SpeciesId (int, PK) | 
    |No (int)   |∞---------1|Name (varchar)  | 
    |Name (varchar)  |   |____________________| 
    |PK (SpeciedId,No) |      1 
    |____________________|      | 
       1         | 
       |         | 
       |         | 
       ∞         ∞ 
    ______________________  ____________________   _______________ 
    | OrganismPropsValues |  | SpeciesProps  |  |  Props  | 
    |----------------------|  |--------------------|  |---------------| 
    |SpeciesId (int, PK) |  |PropId (int,PK,FK) | ∞-----1|PropId (int,PK)| 
    |No (int, PK)   |  |SpeciesId(int,PK,FK)|  |Name (varchar) | 
    |PropId (int, PK)  |  |____________________|  |_______________| 
    |Value (varchar)  |     1 
    |FK (SpeciesId,No)  |     | 
    |FK (SpeciesId,PropId) |     | 
    |______________________|     | 
       ∞        | 
       |        | 
       ------------------------------- 

Answer 4

Siempre que tenga una dependencia en forma de diamante como esta, considere poner más énfasis en compuesto PRIMARY KEYS.

En concreto, identificar el organismo no sólo por OrganismId, sino por la combinación de SpeciesId y OrganismSubId (que aún puede tener OrganismId, pero mantenerlo como una clave alternativa - no muestran aquí por razones de brevedad).

Una vez hecho esto, el modelo se puede hacer para tener este aspecto:

La clave a destacar aquí es que SpeciesId se "propaga" abajo ambos bordes de este diamante gráfico en forma. Esto es lo que le da la restricción deseada de no poder "asignar un valor" a una propiedad que no fue "declarada" para la especie dada.

Por cierto, utilice singular al nombrar sus tablas. Además, considere usar claves primarias naturales (por ejemplo, SpeciesName en lugar de SpeciesId como PK) - si se hace bien, puede aumentar significativamente la velocidad de sus UNIONES (especialmente en conjunción con la agrupación).