Planeta Código

Mapeo objeto-relacional (herencia II)

Septiembre 22nd, 2005 - [Enlace local]

Hola de nuevo. Estos días no he posteado porque he estado de vacaciones .
En el anterior post hablé sobre el mapeo de una jerarquía de herencia usando
la estrategia “una tabla por clase”. En este post voy a explicar la
estrategia “Una tabla por cada clase concreta (no abstracta)”. Sigo con
el mismo modelo de datos (alumnos, profesores, etc.). Con esta estrategia
las clases abstractas no tienen tabla propia. Por lo tanto no habrá
una tabla “personas” y por tanto las tablas de las clases hijas tendrán
más columnas (para almacenar las propiedades que heredan de la clase
Persona). Así quedarían las tablas:

CREATE TABLE alumnos (nif INTEGER NOT NULL,
        nombre VARCHAR(50),
        apellidos VARCHAR(50),
        fecha_nacimiento DATE,
        numero_creditos_cursados INTEGER,
        PRIMARY KEY(nif)) TYPE=INNODB;
	
CREATE TABLE profesores (nif INTEGER NOT NULL,
        nombre VARCHAR(50),
        apellidos VARCHAR(50),
        fecha_nacimiento DATE,
        id_departamento INTEGER,
        PRIMARY KEY(nif)) TYPE=INNODB;
	
CREATE TABLE asignaturas (id_asignatura INTEGER NOT NULL AUTO_INCREMENT,
        nombre VARCHAR(50),
        curso INTEGER,
        creditos INTEGER,
        profesor_titular INTEGER,
        PRIMARY KEY(id_asignatura)) TYPE=INNODB;
	
CREATE TABLE departamentos (id_departamento INTEGER NOT NULL AUTO_INCREMENT,
        nombre VARCHAR(50),
        PRIMARY KEY(id_departamento)) TYPE=INNODB;
	
CREATE TABLE matriculas (id_asignatura INTEGER NOT NULL,
        nif INTEGER NOT NULL,
        PRIMARY KEY(id_asignatura, nif)) TYPE=INNODB;

Creo las claves foráneas para las relaciones…

ALTER TABLE asignaturas ADD FOREIGN KEY (profesor_titular) REFERENCES profesores (nif);
ALTER TABLE profesores ADD FOREIGN KEY (id_departamento) REFERENCES departamentos (id_departamento);
ALTER TABLE matriculas ADD FOREIGN KEY (id_asignatura) REFERENCES asignaturas (id_asignatura);
ALTER TABLE matriculas ADD FOREIGN KEY (nif) REFERENCES alumnos (nif);

Esta estrategia requiere menos tablas que la anterior, pero en ciertas ocasiones la integridad referencial a veces no puede asegurarse sólo con claves foráneas. Supongamos que existe
una entidad “Libro” que tiene un “propietario” de tipo “Peronsa”. En la estrategia enterior
crearíamos una columan en la tabla “libros” que apuntara a la clave primaria de la tabla “personas”;
pero en este caso no hay tabla “personas”, ahora debería apuntar o a “alumnos” o a “profesores”. En ese caso no podríamos asegurar mediante claves
foráneas que un libro apunte a una persona cuya clave primaria existe.

Esta estrategia es mejor que la anterior en cuanto a que dar de alta una persona o un alumno
es más sencillo porque sólo tenemos que modificar una tabla cada vez.

Para hacer un “listado polimórfico”, por ejemplo, listar todas las personas (alumnos y profesores)
tendríamos que hacer un “select” por cada tabla y juntarlos con “UNION”. Ejemplo: “select … from alumnos where … UNION select … from profesores where …”.

Un saludo y hasta el próximo post!

» Leer más, comentarios, etc...

Planeta código

Meta-Info

¿Que es?

Sponsors

Mapeo objeto-relacional (herencia II)