Relaciones en MySQL

[rapuig]

Hola, tengo que modelar una relación de tipo herencia en una base de datos MySQL, por ejemplo:
Persona
id (PK)
nombre
apellido

Estudiante
cursos
materiasAprobadas

Profesor
examenes
asistencias

Necesito que Estudiante y Profesor hereden todos los atributos de Persona, a nivel de MySQL cómo hago esto? Se hace con una FK? Estudiante y Profesor pueden tener como PK el id de Persona?

Muchas gracias!

[gnzsoloyo]

La herencia se da por su dependencia formal: Ni Estudiante ni Profesor tienen clave propia, sino que su PK es a la vez FK de la tabla Persona.
Es la implementación del concepto "entidad débil" del modelo Entidad-Relación.

Por otra parte, te hago notar una cosa: Ni "materiasAprobadas" es atributo de estudiante, ni "asistencias" es atributo de Profesor.
Esos conceptos implican que cada tabla tiene relación con otras donde esa información se puede calcular, en base a registros únicos (de aprobación de cada materia en un caso y de asistencia a una fecha en otra), pero no se pueden almacenar N valores en un campo. Eso no se hace en bases de datos.
Es una violación a la primera forma normal (Ver 1FN), y está específicamente prohibido en el modelo E-R.

[rapuig]

Gracias por responder.
No me queda claro si Profesor y Estudiante tienen que tener una PK o no.

Yo probé ponerles a Profesor y Estudiante una PK con el mismo nombre y tipo que la PK de Persona.
Luego Profesor y Estudiante les asigné como FK la PK de Persona, pero al insertar un Profesor no puedo agregarle los atributos de Persona. Por qué sucede esto?

Lo que me comentas de los atributos tienes razón, lo hice a modo de ejemplo sin pensar.
Aclaración: tengo las tablas con el motor InnoDB.

Gracias!

[gnzsoloyo]

En esencia, vas bien encaminado. Pero debes respetar las dependencias que tu mismo estás declarando.
Primero se crea la Persona, con todos los atributos que deba tener como tal, y recién entonces y previo recuperar la clave generada para esa persona, se inserta el Alumno o el Profesor que corresponda, usando como valor de PK el mismo valor que tiene en la tabla Persona.
¿Se entiende la idea?
Esto implica que por lo pronto, si decides usar un autoincremental en la tabla Persona para la PK (no es obligatorio hacerlo así), las PK/FK de Alumno y Profesor no deben ser autoincrementales.
¿Queda claro eso?

[rapuig]

Quedó clarisimo! Me despejaste algunas dudas que tenía. Luego para obtener los datos con un JOIN es suficiente, no?

Si la tabla padre no tiene demasiados atributos (para ser exactos 9), se justifica esta implementación de tipo generalización o es mejor bajar los atributos del padre a los hijos?

Muchas gracias.

[gnzsoloyo]

Luego para obtener los datos con un JOIN es suficiente, no?

Esa es la idea.

Si la tabla padre no tiene demasiados atributos (para ser exactos 9), se justifica esta implementación de tipo generalización o es mejor bajar los atributos del padre a los hijos?

No.
Los atributos de una tabla deben ser siempre los atributos de la entidad. Todos. Ya sea uno o doscientos. Una entidad no se debe descomponer en N entidades porque haya muchos atributos, sino por razones de normalización.
En una herencia, si entidades del mismo nivel (hijo, nieto), tienen atributos comunes, eso significa que esos atributos deben estar en el grado anterior de la jerarquía.
Nada tiene que ver la cantidad de ellos.

Como regla general, en Bases de Datos, si lo único que diferencia a dos hijos en una herencia es un único atributo, puede no ser necesario crear la herencia, sino dejar ese atributo como opcional. Sería, por ejemplo, el caso de diferentes subconjuntos de Alumnos (si los hubiera). Si se los puede clasificar de diferentes modos, eso no necesariamente quiere decir que se deba generar un nuevo nivel de herencia.
Ten en cuenta que el analisis orientado a datos no es el mismo que el análisis orientado a procesos. Puede suceder que una herencia en el sistema, una herencia desde el punto de vista de la programación orientada a objetos, no se vea reflejada en la base de datos.
Para el caso, que puedas subclasificar como clases distintas a Camiones, Autos, Tractores, Motocicletas, como objetos de un padre Vehiculo, es algo que puede no existir en la base de datos, porque en ella esas clases son relaciones con la entidad Categoría (y su correspondiente tablla), y no entidades de datosdiferentes. Por ello podría suceder que todas estuviesen en una única tabla.
Esto último es algo medio dificultoso de ver para los programadores.
Ver la arquitectura de datos, es algo diferente a ver la arquitectura de las aplicaciones. Mis profesores siempre lo decían, y con el tiempo llegué a la conclusión que tenían razón.

[rapuig]

Muchas gracias, soy estudiante de Ingeniería en Sistemas y hace tiempo que cursé Base de datos y tenía algunos conceptos olvidados, me vinieron bárbaro tus conceptos.

Nuevamente gracias por tu ayuda y tiempo gnzsoloyo.
Saludos.