sql - khan - ¿Cómo implementamos una relación IS-A?

sequel database

Question

Implementamos una relación Uno a Muchos agregando un PK de tabla, como FK a la otra tabla. Implementamos una relación de Muchos a Muchos al agregar 2 PK de la Tabla a una tercera Tabla.

¿Cómo implementamos una relación IS-A?

Las Entidades son TÉCNICAS y ADMINISTRATIVAS, ambas EMPLEADAS. Podría usar un campo adicional en la tabla EMPLEADO (id, nombre, apellido, rol , ... AdminFields ..., ... TechFields ...)

pero me gustaría explorar la opción IS-A.

EDITAR: Hice lo que sugirió Donnie, pero sin el campo de rol.

Answer 1

¿Por qué no implementar esto como una relación de tabla uno a cero / una tabla? Supongamos que tiene una tabla que representa una clase base llamada Vehículo, con una clave principal de VehicleID. Luego, puede tener cualquier cantidad de tablas de satélites que representen todas las subclases de Vehicle, y esas tablas también tienen VehicleID como su clave principal, teniendo una relación de 1> 0/1 desde Vehicle-> Subclass.

O bien, si quiere hacerlo más simple y sabe con certeza que solo tendrá algunas subclases y no hay muchas posibilidades de que eso cambie, podría representar toda la estructura en una sola tabla con un campo de tipo discriminador .

Answer 2

Depende si está construyendo una mono-jerarquía o poli-jerarquía. Este es un diseño codificado, que creo que es lo que usted quería.

Para mono (la tabla secundaria tiene una tabla padre), donde el padre IS-A es padre, la FK y PK son las mismas en la tabla secundaria, y esa clave también es la PK en la tabla padre.

Para poly (la tabla secundaria tiene varias tablas padre), donde el hijo IS-A padre-1 y el hijo IS-A padre-2, tendrá una clave compuesta (es decir, varias claves primarias para hacer que la tabla sea única), donde la regla es lo mismo que una mono-jerarquía para cada clave.

Answer 3

Este documento describe algunas estrategias para mapear generalizaciones en el diseño del esquema.

http://www.sztaki.hu/conferences/ADBIS/3-Eder.pdf

Una copia del resumen:

Los modelos de datos más completos de bases de datos relacionales de objetos abren muchas más opciones para el diseño lógico de un esquema de base de datos que aumenta enormemente la complejidad del diseño de bases de datos lógicas. Centrándonos en las construcciones de generalización de modelos conceptuales, exploramos las implicaciones de rendimiento de las diversas alternativas de diseño para mapear generalizaciones en el esquema de un sistema de base de datos relacional de objetos.

Answer 4

Hice lo que sugirió Donnie, pero sin el campo de roles , porque complica las cosas. Esta es la implementación final:

DDL:

CREATE TABLE Employee (
ast VARCHAR(20) not null,
firstname VARCHAR(200) not null,
surname VARCHAR(200) not null,
...
PRIMARY KEY(ast)
);

CREATE TABLE Administrative (
employee_ast VARCHAR(20) not null REFERENCES Employee(ast),
PRIMARY KEY(employee_ast)
);

CREATE TABLE Technical (
employee_ast VARCHAR(20) not null REFERENCES Employee(ast),
...
PRIMARY KEY(employee_ast)
);

Diagrama de ER:

En este modelo, no hay empleados de tipo genérico. Aquí, un empleado solo puede ser administrativo o técnico.

Answer 5

La mayoría de los ORM implementan la relación IS-A usando un discriminador de columna única, eligiendo qué subclase crear para instanciar en función del valor en una columna en particular. Con respecto a su ejemplo, probablemente no se refiera realmente al rol , ya que típicamente una persona puede llenar muchos tipos diferentes de roles. Los roles normalmente se modelarían como una relación has-a . Si intentas implementarlo usando is-a relaciones (o subclassing) inevitablemente terminarás teniendo que hacer algo más complicado para manejar casos donde tienes a una persona ocupando una posición híbrida, es decir, una secretaria que también funciona como el local Persona de TI que necesita permisos o atributos de ambos.

Answer 6

La relación IS-A también se conoce como el patrón de diseño gen-spec. Gen-spec es la abreviatura de "generalización de especialización".

El modelado relacional de gen-spec es diferente del modelado de objetos de gen-espec porque el modelo relacional no tiene herencia incorporada.

Aquí hay un buen artículo que muestra cómo implementar gen-spec como una colección de tablas.

http://www.javaguicodexample.com/erdrelationalmodelnotes1.html

Preste especial atención a la forma en que se configuran las teclas principales en las tablas especializadas. Eso es lo que hace que usar estas tablas sea tan fácil.

Puede encontrar muchos otros artículos de Googlin "generalización especialización modelo relacional".

Answer 7

Si tiene una aplicación OO que necesita para conectarse a una base de datos de back-end relacional, le recomiendo obtener los patrones de arquitectura de aplicaciones empresariales de Martin Fowler.

También tiene algunas notas y diagramas relevantes en su sitio web. Específicamente, los patrones herencia de tabla única , herencia de tabla de clase y herencia de tabla concreta describen tres tácticas para mapear IS-A en tablas de datos.

Si está utilizando Hibernate o JPA, admiten mapeos para todos estos, aunque tienen nombres diferentes para ellos.

En esta instancia específica, yo no usaría IS-A en absoluto.

Las cosas como los roles de los empleados se modelan mejor como HAS-A, como

1. Es posible que desee que una sola persona tenga múltiples roles.
2. Cambiar el rol de una persona será más fácil.

Answer 8

Siempre he hecho esto con un campo de role , y luego relaciones opcionales.

Es decir, tabla EMPLOYEE (id, ...generic fields... , role)

Y luego, para cada función:

tabla ROLE1 (employeeid, ...specific fields...)

Esto le permite obtener información general del empleado con una sola consulta y requiere combinaciones para obtener la información específica del rol. La desventaja más importante es que si necesitas un superinforme con toda la información del rol, te quedas atascado con un montón de combinaciones externas.