PDF de programación - Módulo 2: Relaciones entre tablas - Bases de datos en la enseñanza. Open Office

Ministerio de Educación

Base de datos en
la Enseñanza.
Open Office

Módulo 2: Relaciones entre tablas

Instituto de Tecnologías Educativas
2011

Bases de datos en la enseñanza

Relaciones entre tablas

OpenOffice Base es un gestor de base de datos relacional, entre otras cosas, porque permite establecer vínculos o relaciones entre las tablas que lo
componen. El objetivo de estas relaciones sería principalmente evitar la duplicidad de información y en consecuencia, optimizar el rendimiento de la base de
datos.



Nota

Las relaciones son sin lugar a dudas uno de los conceptos de base de datos más complicados de entender pero no te preocupes, con algunos
ejemplos y algo de práctica no tendrás ningún problema para establecer relaciones entre tablas.

Objetivos

Comprender y establecer las relaciones entre tablas como paso imprescindible para aprovechar todo el potencial de nuestra base de datos.

Distinguir los distintos tipos de relaciones.

Configurar relaciones.

Establecer las relaciones de la base de datos de ejemplo.

Concepto de relación

Las relaciones son un tema complejo pero veamos un sencillo ejemplo con las tablas Alumnos y Cursos para entenderlo mucho mejor. Inicialmente nuestras
tablas estarían definidas del siguiente modo:



1

En la tabla Alumnos tenemos toda la información que necesitamos sobre nuestros alumnos como:

Su número de expediente.
Su nombre y apellidos.
Su fecha de nacimiento.
El grupo al que pertenece el alumno.
La ubicación del grupo, es decir, el aula donde están los alumnos de ese grupo (Primera planta, edificio anexo, etcétera).
Cualquier tipo de comentario de interés: grupo de compensatoria, apoyo, etcétera.

Para la tabla Grupos nos podíamos conformar con la denominación del grupo (1A, 1B, 3A...) pero le hemos añadido algunos datos que nos pueden resultar
de interés:

Número total de alumnos que tiene el grupo.
El lugar donde se encuentra ubicado: Aula de música, Aula 205 Edificio principal, etcétera.
Cualquier otro dato de interés: Compensatoria, grupo de apoyo, etcétera.

Si saber nada de bases de datos y de relaciones podemos, darnos cuenta que al comprobar los datos incluidos en las tablas de Alumnos y Grupos
existe información que se repite en ambas:



Esta situación no es demasiado favorable cuando trabajamos con bases de datos donde habitualmente la cantidad de información que se maneja es

2 importante. La solución pasa por RELACIONAR las tablas con información coincidente de modo que no exista duplicidad de información. Todo esto,
traducido a un lenguaje más natural sería: "Para qué escribir dos veces lo mismo, si puedo hacerlo una sola y trabajar del mismo modo".



Volviendo a nuestro ejemplo, si relacionamos las tablas Alumnos y Grupos mediante el nombre del grupo sería suficiente con indicar en la tabla Alumnos este
valor para obtener el número de alumnos del grupo, su ubicación y las posibles observaciones:



Tipos de relaciones

No siempre las condiciones para establecer vínculos entre dos tablas son iguales, la manera en que se relacionan las tablas entre sí da lugar a
comportamientos diferentes. En la estructutura de cualquier base de datos encontramos principalmente tres tipos de relaciones que se describen del
siguiente modo:

Uno a muchos.
Muchos a muchos.
Uno a uno.

De todas ellas, la más utilizada y recomendable en la mayoría de los casos será el modelo Uno a muchos como veremos a continuación.

3 Uno a muchos

Veamos el primer modelo de relación tomando como referencia las tablas Alumnos y Grupos. Cualquier alumno (MUCHOS) pertenece sólo a un grupo
(UNO), un alumno no puede estar en más de una clase. Pues bien, ni más ni menos que este sería el argumento de una relación MUCHOS A UNO.



Otro ejemplo, sabemos que cada profesor pertenece únicamente a un departamento, pero en cada departamento existe más de un profesor. De aquí
podemos extraer una relación UNO a MUCHOS entre las tablas Departamentos y Profesores.



En las relaciones de uno a muchos cada registro de una tabla A, a la que llamaremos tabla primaria, puede estar enlazado con más de un registro de otra
tabla B, a la que llamaremos tabla secundaria. En cambio, cada registro de la tabla B sólo puede estar enlazado a un registro de la tabla A.

Nota

Uno a muchos o muchos a uno únicamente se diferencia en el sentido de la relación, es decir, si la tabla primaria se encuentra a la izquierda o
derecha de la relación. En realidad se trata del mismo tipo de relación y sin lugar a dudas, la que más se utiliza.

Uno a uno

Las relaciones uno a uno no son demasiado frecuentes pero existen así que debemos conocerlas. Buscando alguna coincidencia en nuestro entorno que nos
pueda servir como ejemplo encontramos el vínculo entre un tutor y su grupo. Como sabemos, un profesor puede ser tutor de un sólo grupo (UNO) y del
mismo modo, cada grupo sólo puede tener un tutor. Esta sería una relación UNO a UNO.

4

Cada registro de la tabla A se relaciona con un único registro de la tabla B y cada registro de la tabla B sólo se relaciona con un elemento de la tabla A.
Como hemos comentado, este tipo de relaciones son poco comunes.

Muchos a muchos

Resumiendo lo visto hasta ahora podemos decir que el tipo de relación ideal es uno a muchos o muchos a uno. Las relaciones uno a uno no aportan
demasiado a la base de datos, simplemente nos ayudan a tener mejor organizada la información pero poco más. Veamos qué ocurre con las relaciones
muchos a muchos.

Por ejemplo, si queremos conocer los profesores que dan clase a un grupo o los grupos a los que da clase un profesor determinado, necesitamos en principio
dos tablas: Profesores y Grupos. ¿Y cuál sería la relación entre estas dos tablas? Pues bien, para establecerla podríamos leer que un profesor da clases a
varios grupos (1A, 1B, 2C, etcétera) y un grupo recibe clases de varios profesores (Carlos Pérez, Antonio García, etcétera). Por lo tanto, nos encontramos
entre una relación MUCHOS A MUCHOS.



Desde un punto de vista teórico diríamos que en las relaciones Muchos a muchos a cada registro de la tabla A se le pueden asociar varios registros de la
tabla B y cada registro de la tabla B puede estar relacionado con más de un registro de la tabla A.

Otros ejemplos para ilustrar este modelo de relación podrían ser:

Los alumnos que participan en las actividades deportivas del centro. Concretamente un alumno podría participar en más de un deporte (Fútbol,
Baloncesto, etcétera) y a su vez cada equipo está formado por varios componentes. Esta relación también sería del tipo Muchos a muchos.

Con las actividades extraescolares ocurre lo mismo. Un alumno puede asistir a más de una (manualidades, música, idiomas, etcétera) y en cada una
de ellas, encontraremos a varios alumnos.



Problemas y solución para las relaciones Muchos a muchos

Las relaciones Muchos a muchos no son recomendables y debemos tratar de evitarlas utilizando TABLAS INTERMEDIAS en las que se utilizarían relaciones
de uno a muchos. Una tarea sencilla como podría ser obtener un listado de todos los profesores que imparten clases en 1ºB se convierte en una verdadera
pesadilla si mantenemos esta relación. La solución pasa por crear una TABLA INTERMEDIA que nos permita dividir la relación MUCHOS A MUCHOS en dos
relaciones UNO A MUCHOS como puedes ver en la figura 2.34.

5 Figura 2.34

Importante

En documentación relacionada con bases de datos también podrás encontrar que utilizan otra terminología para identificar las relaciones,
concretamente es común utilizar: uno a varios, varios a uno, varios a varios, etcétera.

Actividad 8

La base de datos utilizada como ejemplo contiene diferentes tablas pero faltarían dos tablas intermedias importantes, concretamente se trata de las
tablas Participantes y ProfesoresCursos.

Tabla Participantes

En la tabla “Participantes” necesitamos utilizar los tres campos disponibles para componer la clave única. Además, teniendo en cuenta que esta tabla
es una de las más importantes de nuestro ejemplo estudiemos mejor el sentido de cada uno de sus campos:

Alumno: Hace referencia al código de expediente del alumno. Con este dato obtendremos después el resto de información necesaria para
identificar al alumno.

ParticipanteEquipo: Código del equipo del que forma parte el alumno. Por ejemplo, el equipo “LocosDelBalón” tiene asociado el código 0,
pues bien, este será el dato que necesitamos para completar esta tabla.

ParticipanteActividad: De nuevo utilizamos un código, pero esta vez corresponde a la actividad en la que participa el equipo: “Fútbol”,
“Baloncesto”…

Es importante recordar que para poder introducir datos en la tabla Participantes es necesario crear previamente las tablas implicadas: Alumnos,
Equipos y Actividades.

A continuación crea esta tabla teniendo en cuenta los siguientes datos:



Nombre del campo

Tipo de dato

Propiedades

Descripción

Alumno

Integer [INTEGER]

Por defecto

Código de alumno. (CAMPO CLAVE)

6 ParticipanteEquipo

Integer [INTEGER]

ParticipanteActividad

Integer [INTEGER]

Por defecto

Por defecto

Código del equipo. (CAMPO CLAVE)

Código de la actividad. (CAMPO
CLAVE)

Tabla ProfesoresCursos

La tabla ProfesoresCursos nos permitirá identificar de forma precisa los grupos (cursos) a los que imparte clase cada profesor. Además con el
campo Tutor sabremos qué curso está directamente tutelado por el profesor. Para completar esta actividad diseña la tabla ProfesoresCursos a partir
de la siguiente información.



Nombre del campo

Tipo de dato

Propiedades

Descripción

Profesor

Integer [INTEGER]

Por defecto

Integer [INTEGER]

Por defecto

Código del profesor. (CAMPO
CLAVE)

Código del curso asociado al
profesor (1B, 1C, 2A...). (CAMPO
CLAVE)

Sí/No [BOOLEAN]

Valor predeterminado, configurar a
“No”.

Si es tutor del curso el campo estará
a “Sí”.

Curso

Tutor



Establecer relaciones entre tablas

Como requisito indispensable para establecer una relación entre