Cita: Luego para obtener los datos con un JOIN es suficiente, no?
Esa es la idea.
Cita: 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.