Básicamente, hay tres opciones para traducir la generalización en un modelo de base de datos
1. Una mesa por clase concreta
Crear tablas Admin
, Teacher
y Student
. Cada una de estas tablas contiene columnas para todos los atributos y relaciones de User
- Pro
- Todos los campos de una subclase concreta están en la misma tabla, por lo que no es necesario unirlos para obtener todos los datos de los Estudiantes
- Restricciones de validación de datos fáciles (como campos obligatorios para
Student
)
- Con
- Todos los campos de
User
se duplican en cada tabla de subclase - Claves foráneas para
User
tiene que dividirse en tres campos FK. Uno paraAdmin
, uno paraTeacher
y uno paraStudent
.
- Todos los campos de
2. Sobre la mesa para todo el conjunto de generalización
En este caso, solo tiene una llamada de tabla User
que contiene todos los campos de User
+ todos los campos de todas las subclases de User
- Pro
- Todos los campos están en la misma tabla, por lo que no es necesario unirse para obtener todos los
User
datos - Sin división de FK para
User
- Todos los campos están en la misma tabla, por lo que no es necesario unirse para obtener todos los
- Con
- Hay un montón de campos que nunca se utilizan. Todos los campos específicos para
Student
yTeacher
nunca se completan paraAdmins
y viceversa - Validación de datos como campos obligatorios para una clase concreta como
Student
se vuelve bastante complejo ya que ya no es un simpleNot Null
restricción.
- Hay un montón de campos que nunca se utilizan. Todos los campos específicos para
3. Una tabla por clase concreta y otra para la superclase
En este caso, crea tablas para cada una de las subclases concretas y crea una tabla para la clase User
. Cada una de las tablas de subclases concretas tiene un FK obligatorio para User
- Pro
- Esquema más normalizado:sin campos repetidos para los atributos del usuario y sin campos sin usar.
- Sin división de FK para
User
- Restricciones de validación de datos fáciles (como campos obligatorios para
Student
)
- Con
- Tienes que consultar dos tablas si quieres todos los datos de un
Student
- Reglas de validación complejas para asegurarse de que cada
User
el registro tiene exactamente unAdmin
,Teacher
oStudent
grabar.
- Tienes que consultar dos tablas si quieres todos los datos de un
Cuál de estas opciones elija depende de varias cosas, como la cantidad de subclases, la cantidad de atributos en la subclase o la superclase, la cantidad de FK en la superclase y probablemente algunas otras cosas que no hice pensar.