Capítulo 2. El Modelo Entidad/Relación.
Antes de pasar a implementar la Base de Datos en un Sistema Gestor de Base de Datos como puede ser MySQL deberemos realizar un diseño correcto de la misma, por que si el diseño es incorrecto (o inexistente) la Base de Datos tendrá errores que nos dificultarán su uso, y sobre todo nos complicarán mucho cualquier modificación posterior.
Como MySQL es un Sistema Gestor de Bases de Datos Relacional usaremos en modelo Entidad/Relación (E/R) para realizar el análisis inicial.
Un consejo muy importante es realizar este diseño en papel (usando los dibujos que a continuación se explicarán) por que visualmente resulta mucho más sencillo de entender.
Entenderemos como “entidad” como cualquier objeto real o abstracto sobre el cual deseamos guardar información.
Por ejemplo, podríamos tener las siguientes entidades: persona, alumno, cliente, factura, población, etc.
Su representación en el modelo E/R es mediante un rectángulo dentro del cual aparecerá el nombre de dicha entidad. Como norma que se seguirá en este curso, el nombre aparecerá en mayúsculas y en plural.
Ejemplos:
Las entidades se componen de atributos que son cada una de las propiedades o características que tienen las entidades. Cada ejemplar de una misma entidad posee los mismos atributos, tanto en nombre como en número, diferenciándose cada uno de los ejemplares por los valores que toman dichos atributos.
Por ejemplo, para la entidad “persona” aparecida en el apartado anterior podríamos tener los siguientes atributos: nombre, apellidos, sexo, fecha de nacimiento, DNI, etc.
Los atributos aparecerán representados mediante una elipse, y una línea que une al atributo con su correspondiente entidad.
Ejemplos:
Cuando uno de los atributos de una entidad no puede tomar valores repetidos entonces hablaremos de atributos clave.
Un ejemplo de esto sería el atributo DNI en la entidad “personas”: no podremos tener dos personas con el mismo DNI.
Las claves pueden ser simples (como el ejemplo del DNI) o compuestas: en la entidad “personas” si suponemos que no puede haber dos personas con el mismo “nombre y apellidos” entonces la clave es compuesta.
Puede darse el caso de que tengamos dos posibles claves o más, entonces una de ellas será la clave principal, y la otra u otras serán claves alternativas. Esto es importante, pues en el posterior diseño de la Base de Datos habrá que indicárselo al Sistema Gestor de Bases de Datos (de una forma muy sencilla, como ya veremos).
Una vez decidida cual es la lave principal y cual/es la/s alternativa/s deberemos indicarlo en el diseño E/R de la siguiente forma:
– Clave principal: la subrayaremos.
– Claves alternativas: las subrayaremos, pero de forma discontinua.
Veamos un ejemplo con la entidad “alumnos”. Para esta entidad vamos a tener los siguientes atributos: DNI, Num.Expediente, Nombre, Apellidos, Sexo.
Una vez tenemos los atributos observamos que tenemos dos posibles claves: DNI y Num.Expediente. Decidimos que la clave principal será DNI, y la alternativa Num.Expediente. La representación sería la siguiente:
Como ya se ha comentado, estamos usando el modelo relacional, el cual se basa en que todas las entidades están relacionadas.
Por ejemplo, en una Base de Datos de un colegio, la entidad “alumnos” estará relacionada con la entidad “profesores” por que un profesor impartirá clases a un alumno (o a varios) y de la misma forma la entidad de “cursos” estará relacionada con la entidad “profesores” para indicarnos que profesores imparten un curso, y con la entidad “alumnos” para indicarnos que alumnos están en dicho curso.
En resumen, todo diseño de una Base de Datos tendrá varias entidades, y además toda entidad estará relacionada con al menos otra entidad, es decir, si tenemos una entidad que no se relaciona con ninguna otra hay algo que no es correcto en el diseño.
Si se desea profundizar en el Modelo E/R se recomienda que se busque bibliografía a cerca de dicho modelo por que este tema se sale de los contenidos previstos en este curso.
Una vez realizado el diseño de E/R se procederá al paso a tablas, es decir, a indicar que tablas y atributos tendremos que implementar en el Sistema Gestor de Bases de Datos. Al tratarse de un tema que se sale de los contenidos de este curso se verá sin profundizar.
Podremos tener relaciones entre entidades de varios tipos:
– Unarias: una entidad se relaciona consigo misma.
– Binarias: dos entidades que se relacionan entre sí.
– Ternarias: tres relaciones relacionadas entre sí.
Para indicar que dos entidades se relacionan entre sí (o una consigo misma) las uniremos con una línea que contendrá un rombo partido en su punto medio, tal como aparece en la Ilustración 5, o un triángulo si se trata de una relación ternaria tal y como aparece en la Ilustración 6.
Al salirse de los objetivos de este curso veremos sólo el caso más usual, que son las relaciones binarias y algunas de sus características.
A continuación veremos los 3 casos posibles de relaciones binarias y su forma de pasarlas a tablas. Para ello veremos que el equivalente a una entidad será una tabla (aunque no sea siempre así, lo veremos en las relaciones “uno a uno”) y el equivalente a un atributo será un campo.
En este primer caso veremos una relación R que relaciona las entidades A y B. Cada una de ellas con sus atributos correspondientes y además pondremos también un atributo en la misma relación.
Este caso nos permite tener relaciones en las que un elemento de la entidad A se va a relacionar con uno solo de B, y al revés. Más adelante veremos un ejemplo para aclarar mejor esta idea.
En principio podríamos pensar que tendríamos dos tablas, pero éste es el único caso en el que obtenemos menos tablas que entidades. Veamos la tabla que nos aparece:
Como podemos ver obtenemos una tabla solamente que tiene todos los atributos de las dos entidades y además el de la relación.
Además hay que observar que tenemos una clave principal (la de la entidad A) y otra alternativa (la de la entidad B), que podríamos haber escogido al revés.
Veamos ahora un ejemplo para aclarar esta idea:
Tenemos una Base de Datos que nos guardará “Equipos de Fútbol” y sus correspondientes “Entrenadores”. Como podemos observar un equipo de fútbol sólo podrá tener un entrenador, y a su vez, un entrenador sólo podrá entrenar a un equipo. Además, y para este ejemplo, pondremos un atributo en la relación “Entrenan” para indicarnos la fecha el la cual el entrenador comenzó a entrenar el equipo.
La tabla resultante sería la siguiente:
Podemos observar varias cosas:
– Como hemos unido las dos entidades, hemos tenido que cambiar el nombre al atributo “Nombre” de la entidad Equipos para que no fuese el mismo que el de la entidad “Entrenadores”.
– Nos aparece, como ya se vio, una clave principal y otra alternativa.
En este caso vamos a ver el paso a tablas cuando una entidad A puede relacionarse con varios elementos de la entidad B, pero un elemento de la entidad B sólo puede relacionarse con uno de la entidad A. La parte del “muchos aparecerá sombreada en el rombo.
Veamos las tablas que nos aparecen:
Podemos ver que la parte del “muchos”, en este caso la entidad B, coge tanto la clave de la entidad A como el atributo de la relación R. De esta forma podemos saber cada elemento de B con cual está relacionado en A.
Veamos ahora un ejemplo para aclarar esta idea:
Tenemos una Base de Datos que nos guardará “Equipos de Fútbol” y sus correspondientes “Jugadores”. Como podemos observar un equipo de fútbol podrá tener varios jugadores, pero un jugador sólo podrá jugar en un equipo. Además, y para este ejemplo, pondremos un atributo en la relación “Juegan” para indicarnos la fecha el la cual el jugador comenzó a jugar el equipo.
Las tablas resultantes serían las siguientes:
Podemos observar varias cosas:
– Hemos tenido que cambiar el nombre al atributo “Nombre” de la entidad Equipos para que no fuese el mismo que el de la entidad “Jugadores”. En la tabla “Equipos” aunque no hacía falta también le hemos cambiado el nombre para mayor claridad.
– La clave de la entidad con el “uno” (la parte en blanco en el rombo) pasa a la otra entidad, de esta forma para cualquier jugador miraremos el atributo “NombreEquipo” y sabremos tanto el equipo al que pertenece como cualquier otro dato de ese equipo: mirando con esa clave en la entidad “Equipos” obtendremos el resto de atributos para ese “Equipo”.
– La “FechaInicio” también pasaría a la entidad que tiene el “Muchos” (rombo relleno) junto a ella.
Por último vamos a ver el paso a tablas de dos entidades para las cuales un elemento de una de ellas puede relacionarse con varios de la otra y viceversa.
Veamos las tablas que nos aparecen:
Podemos ver que para cada entidad aparece una tabla, pero además aparece otra tabla nueva que contendrá la relación entre ambas entidades junto con el atributo (o atributos) que tenga la relación, y como clave principal tendrá las claves principales de las dos entidades que forman parte de la relación.
Veamos ahora un ejemplo para aclarar esta idea:
Tenemos una Base de Datos que nos guardará “Equipos de Fútbol” y sus correspondientes “Jugadores”. Como podemos observar un equipo de fútbol podrá tener varios jugadores, y además un jugador podrá haber jugado en más de un equipo.
Además, y para este ejemplo, pondremos un atributo en la relación “Juegan” para indicarnos la temporada en la cual el jugador perteneció al equipo.
Las tablas resultantes serían las siguientes:
Podemos observar varias cosas:
– Para cada una de las dos entidades tenemos una tabla que contiene sólo los atributos de dicha entidad.
– Para la tabla correspondiente a la relación tendremos una clave principal doble que estará formada por las claves principales de las entidades que forman parte de la relación. Obsérvese que un jugador podrá aparecer varias veces en la tabla “Juegan” pero nunca podrá aparecer más de una vez relacionado con un mismo equipo, pues los pares “Jugador,Equipo” no pueden repetirse por ser la clave principal de la tabla. (Este ejemplo no sería muy correcto por que un jugador podría haber estado en un equipo en varias temporadas, y para ese caso deberíamos incluir el atributo “Temporada” en la clave para permitir esos casos).
– Además la tabla “Juegan” tendrá los atributos que estaban en la relación (en este caso la temporada).
Por último, y una vez decidido que Sistema Gestor de Bases de Datos vamos a usar tendremos que decidir que dominio tendrá cada atributo de las tablas, es decir, que tipo de datos almacenará. Para ello nos basaremos en MySQL y en el ejemplo que vamos a usar en este curso.
Como podrá observarse el ejemplo será muy sencillo, pues el curso se centra en los accesos a la Base de Datos desde páginas Web.
El ejemplo en el que basaremos el curso va a ser el siguiente: tenemos un centro que imparte cursos por profesores (para hacerlo de forma sencilla no se tendrán en cuenta los alumnos, pero para ello sólo haría falta incluir una nueva entidad que relacione los “cursos” con los “alumnos”). Un profesor podrá impartir varios cursos, pero un curso solo podrá ser impartido por un profesor, por lo que tendremos una relación “uno a muchos”.
El diseño sería el siguiente:
Una vez realizado el diseño, el siguiente paso será el paso a tablas, cuyo resultado será el siguiente:
El primer paso para decidir los dominios será asignar a cada campo de la tabla un dominio genérico. Para ello vamos a considerar los siguientes dominios:
– Enteros: campos que no necesitaremos decimales. Además este campo podrá ser autonumérico, es decir, según vayamos dando de alta registros en la tabla se le asignará un número entero consecutivo, que nos evitará que lo tengamos que hacer nosotros y por lo tanto que tengamos que saber cual es el siguiente número a asinar.
– Reales: campos para los que necesitemos tener decimales.
– Alfanuméricos: campos en los cuales almacenaremos letras, números, caracteres especiales (como los siguientes: $ % _ : ; * + etc.). Para este tipo de campo deberemos decidir su longitud, o si será de longitud “infinita” (usado para campos como “descripciones”, “notas”, “observaciones”, etc.
– Fecha/hora: campos que contendrán una fecha, una hora, o ambas a la vez.
– Lógicos o booleanos: contendrán valores como “si” o “no”, “verdad” o “falso”, “activado” o “desactivado”, etc.
– Otros: como pueden ser campos que contengan imágenes, contenido en binario,
etc.
En el ejemplo anterior tendríamos los siguientes dominios:
Veamos algunas observaciones sobre lo anterior:
– El código de curso se ha decidido que sea alfanumérico pues contendrá una abreviación del nombre del curso.
– El “CodProfesor” en la tabla de “Profesores” es autonumérico, de forma que cada vez que demos de alta un profesor se le asignará un número correlativo y de forma automática, e esta forma no tendremos que escribirlo nosotros ni deberemos saber cual es el siguiente código a asignar cuando vayamos a dar de alta otro profesor.
– El “CodProfesor” de la tabla “Cursos” debe ser del mismo tipo que el de la tabla “Profesores” para que podamos “relacionar” ambas tablas. Recordemos que ambas tablas estaban unidas a través de este atributo. Así cuando veamos que un curso es impartido por el “CodProfesor” 23 podremos ir a la tabla de “Profesores” y buscar el que tenga ese “CodProfesor” para obtener el resto de datos de este profesor.
– El DNI se ha decidido que sea alfanumérico para poder almacenar los 8 números y la letra del NIF. Y recordemos que no permitirá duplicados por ser clave alternativa.
En segundo lugar, después de decidir que Sistema Gestor de Bases de Datos vamos a usar (en nuestro caso MySQL), deberemos de ver los tipos de datos o dominios de que disponemos en éste y elegir los más adecuados para nuestros campos.
Así tendremos:
Y veamos algunos comentarios sobre estas decisiones:
– Para los campos alfanuméricos escogeremos el tipo VARCHAR, pues aunque le digamos que va a tener una longitud de 20 caracteres, internamente no ocupa esos 20 caracteres sino sólo los que realmente contengan algo. Es decir, si un profesor se llama “Juan” sólo usará 4 bytes, y no 20 como cabría esperar (o como haría si usamos el tipo CHAR).
– Para el “CodProfesor” de la tabla “Profesores” deberemos de marcar la casilla “AUTO_INCREMENT”.
El resto de tipos de campos serán comentados en el Capítulo 4. más detalladamente.