sql >> Base de Datos >  >> RDS >> Mysql

Clase abstracta de diagrama UML a ER. Posible ? ¿Cómo?

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 para Admin , uno para Teacher y uno para Student .

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
  • Con
    • Hay un montón de campos que nunca se utilizan. Todos los campos específicos para Student y Teacher nunca se completan para Admins 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 simple Not Null restricción.

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 un Admin , Teacher o Student grabar.

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.