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


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 (identificación, nombre, apellido, papel, ... AdminFields ..., ... TechFields ...)

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

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


32
2017-12-05 21:39


origen


Respuestas:


Hice lo que sugirió Donnie, pero sin el papel campo, 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:

ERD

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


23
2018-01-12 09:09



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

I.e., tabla EMPLOYEE (id, ...generic fields... , role)

Y luego, para cada función:

mesa 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.


6
2017-12-05 21:45



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".


6
2017-12-06 08:58



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

También tiene algunas notas y diagramas relevantes en su sitio web. Específicamente, los patrones Herencia de tabla única, Herencia de mesa de clase y Herencia de Mesa de Concreto describe 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 una sola persona para tener múltiples roles.
  2. Cambiar el rol de una persona será más fácil.

5
2017-12-05 22:37



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 ricos de   las bases de datos relacionales objeto abre muchos   más opciones para el diseño lógico de   un esquema de base de datos que aumenta la   complejidad del diseño de la base de datos lógica   enormemente. Enfocándose en la generalización   construcciones de modelos conceptuales que   explorar las implicaciones de rendimiento   de las diversas alternativas de diseño para   mapeo generalizaciones en el   esquema de un objeto-relacional   sistema de bases de datos.


3
2017-12-05 22:42



¿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 .


2
2017-12-05 21:54



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 tu ejemplo, probablemente no te refieras papel, ya que típicamente una persona puede llenar muchos tipos diferentes de roles. Los roles normalmente se modelarán como tiene un relación. Si intentas implementarlo usando es un Las relaciones (o subclases) inevitablemente terminan teniendo que hacer algo más complicado para manejar casos en los que una persona ocupa un puesto híbrido, es decir, una secretaria que también funciona como la persona de TI local, necesitando permisos o atributos de ambos.


1
2017-12-05 21:51