Es posible que desee considerar un modelo de datos de Tipo/Subtipo. Esto es muy parecido a las clases/subclases en la programación orientada a objetos, pero mucho más complicado de implementar, y ningún RDBMS (que yo sepa) los admite de forma nativa. La idea general es:
- Usted define un Tipo (Edificio), crea una tabla para él, le da una clave principal
- Usted define dos o más subtipos (aquí, Hospital, Clínica, Escuela, Universidad), crea tablas para cada uno de ellos, crea claves principales... pero las claves principales también son claves externas que hacen referencia a la tabla Edificio
- Su tabla con una columna "ObjectType" ahora se puede construir con una clave externa en la tabla de construcción. Tendría que unirse a algunas mesas para determinar qué tipo de edificio es, pero tendría que hacerlo de todos modos. Eso, o almacenar datos redundantes.
Has notado el problema con este modelo, ¿verdad? ¿Qué impide que un Edificio tenga entradas en dos o más de las tablas de subtipos? Me alegra que hayas preguntado:
- Agregue una columna, tal vez "BuildingType", a Building, digamos char(1) con valores permitidos de {H, C, S, U} que indican (duh) el tipo de edificio.
- Cree una restricción única en BuildingID + BuildingType
- Tenga la columna BulidingType en las subtablas. Póngale una restricción de verificación para que solo pueda establecerse en el valor (H para la tabla Hospitales, etc.). En teoría, esta podría ser una columna calculada; en la práctica, esto no funcionará debido al siguiente paso:
- Construya la clave externa para relacionar las tablas usando ambas columnas
Listo:Dada una fila de EDIFICIO configurada con tipo H, una entrada en la tabla ESCUELA (con tipo S) no se puede configurar para hacer referencia a ese Edificio
Recordarás que dije que era difícil de implementar.
De hecho, la gran pregunta es:¿Vale la pena hacerlo? Si tiene sentido implementar los cuatro (o más, a medida que pasa el tiempo) tipos de edificios como tipo/subtipo (más ventajas de normalización:un lugar para la dirección y otros atributos comunes a cada edificio, con atributos específicos del edificio almacenados en las subtablas), bien puede valer la pena el esfuerzo extra para construir y mantener. Si no es así, vuelve al punto de partida:un modelo lógico que es difícil de implementar en el RDBMS promedio de hoy en día.
