Método general
Posiblemente la mayor ventaja del modelo EER es que la conversión a tablas es casi inmediata:
- En principio, cada entidad corresponderá a una tabla, y los atributos de la entidad darán lugar a los campos de la tabla.
- Las relaciones “de uno a muchos·” (1:M) se reflejarán poniendo la clave del “uno” en la tabla de los “muchos”. Es decir, si un profesor imparte muchos cursos (y cada curso es impartido por un único profesor), lo que haremos es poner el código del profesor (su DNI) en la ficha de cada curso que imparte.
- Las relaciones “de muchos a muchos” (M:M) aparecerán como una nueva tabla, en la que cada registro estará formado por las claves de las tablas que se relacionan. En nuestro caso, la relación “de muchos a muchos” entre alumnos y cursos se convertirá en una nueva tabla, en la que cada registro contiene dos campos: el código del curso al que se asiste y el DNI del alumno que ha asistido.
- Las relaciones “de uno a uno” muchas veces son debidas a un fallo de diseño, y corresponden a datos que deberían estar en una misma tabla. Por ejemplo, si suponemos que cada persona tendrá una única dirección postal, y cada dirección corresponde a una única persona, entonces el dato de la dirección postal deberá ser uno más de la tabla que almacena todos los datos de esa persona. Esta simplificación que hemos hecho no es del todo cierta: a veces las relaciones 1:1 deberán reflejarse como una nueva tabla, dependiendo de si existe restricción de existencia o no, pero no entraremos en tanto detalle… al menos por ahora…
Convirtiendo a tablas nuestro ejemplo
Así, en nuestro caso, obtendríamos las siguientes tablas (con sus campos, limitándonos a los atributos que hemos incluido en el último diagrama):
Alumnos:
- DNI (clave)
- Nombre
- Tlf
Profesores:
- DNI (clave)
- Nombre
- Direcc
Cursos:
- Código (clave)
- Nombre del curso
- Fecha de comienzo
- DNI del profesor
Asistir:
- Código del curso
- DNI del alumno
Ya sólo falta una cosa. Hay que decidir los tipos de datos de los campos y también los tamaños de los campos. Esto es porque al ordenador habrá que darle toda la información muy cuadriculada, para que podamos guardar toda la información que nos interesa pero sin desperdiciar demasiado espacio.
Los tipos de datos existentes pueden variar de un sistema de bases de datos a otro, así que vamos a limitarnos (por ahora) a hacer una primera aproximación, acercándonos al caso de nuestros campos:
- El nombre de un alumno, de un profesor o de un curso, estará formado básicamente por letras. Todos los sistemas de bases de datos tendrán un tipo de datos adecuado para almacenar series de letras (que podrán incluir alguna cifra numérica o algún otro símbolo). Será un tipo llamado “Texto”, “Alfanumérico”, “Carácter” o algo similar. En cuanto al tamaño, nos puede bastar con unas 40 letras (insisto: no debemos quedarnos cortos, pero si nos excedemos, estaremos desperdiciando espacio).
- La dirección tendrá también letras, números y algún otro símbolo, de modo que también será tipo Texto, y unas 50 letras de tamaño puede estar bien.
- El DNI del alumno o del profesor contendrá cifras numéricas, pero posiblemente también alguna letra, de modo que nos interesará que también este dato sea de tipo “Texto”, y entre 10 y 15 letras de tamaño (dependiendo de si vamos a escribir puntos en los millares, guión antes de la letra, etc.).
- El teléfono del alumno sólo contendrá cifras. Tendremos un tipo de dato “Numérico”, que nos puede servir en este caso y que será imprescindible en el caso de que queramos hacer operaciones aritméticas con los datos almacenados en un campo. En el caso del teléfono, no necesitamos hacer operaciones, y también es posible que nos interese escribir paréntesis, guiones o espacio, de modo que quizá sea más interesante dejarlo como tipo “Texto”, de unas 12-15 letras. Además, es frecuente que se “ignoren” (no se muestran ni se guardan) los ceros a la izquierda de una expresión numérica, y esto es algo que no deberemos permitir con un teléfono, que podría tener un prefijo provincial o internacional que comience por 0 (lo mismo ocurre con los códigos postales, que también deberemos almacenar como texto, no como número).
- Para la fecha de inicio de un curso, casi todos los sistemas de bases de datos nos permitirán utilizar un tipo de datos llamado “Fecha”.
- El código de un curso queda a nuestra elección: si queremos que esté formado sólo por números, sería tipo de datos “Numérico”; si queremos que pueda contener letras u otros símbolos, debería ser de tipo “Texto”. Algunos sistemas de bases de datos van más allá y permiten un tipo “Autonumérico”, que es un dato numérico que va incrementándose automáticamente (en el primer registro que introduzcamos será un 1, en el segundo un 2, y así sucesivamente), para que no tengamos ni siquiera que pensar qué código queremos para cada registro (hay gente a quien esto le parece muy cómodo y otros que lo consideran demasiado rígido).
Tipos de datos existentes
En general, los tipos de datos habituales, que encontraremos en casi cualquier sistema de bases de datos, son los siguientes:
- Texto (o alfanumérico, o carácter), cuando nuestro campo deba almacenar letras y quizás algún otro tipo de símbolos de puntuación y/o cifras numéricas. Deberemos indicar la cantidad de letras (o en general, de caracteres) para las que queremos dejar espacio (no deberíamos quedarnos cortos, para que nos quepa toda la información que nos interesa, pero tampoco hay que dejar mucho espacio de más, o estaríamos desperdiciando una parte de la capacidad de nuestros sistemas de almacenamiento sin necesidad).
- Numérico, cuando nuestro campo vaya a guardar cantidades numéricas, especialmente si más adelante necesitaremos realizar operaciones aritméticas con estas cantidades numéricas. Tendremos que indicar también el espacio que queremos reservar, pero esto puede que se haga de forma distinta según el sistema de bases de datos que usemos. Por ejemplo, unos esperarán que les digamos el número de cifras que queremos guardar, mientras que otros emplearán nombres más cercanos a como realmente se va a guardar la información en el ordenador (cosas como “número entero largo” o “número real de doble precisión”).
- Lógico, cuando sólo hay dos posibilidades (verdadero o falso, sí o no).
- Fecha, para almacenar fechas (y, en ocasiones, también horas). Se utiliza para que las comparaciones y las ordenaciones sean correctas (por ejemplo, si escribimos las fechas 12/01/2000 y 31/10/1975 como “texto”, el ordenador consideraría que la primera es menor -anterior- a la segunda, lo cual es claramente incorrecto).
- Memo, es un campo de texto especial, que permite una longitud ilimitada, pero a cambio su acceso es más lento que el campo de texto normal, por lo que sólo se usa en casos muy concretos, en los que la longitud del texto a guardar sea muy variable y no importe que las búsquedas sean lentas. Es el caso de un apartado de “observaciones” sobre un alumno, o el “resumen” de una película.
- Otros menos habituales nos permitirán guardar imágenes o ficheros en general, números que se incrementen automáticamente, hipervínculos (enlaces a una cierta dirección dentro de nuestro ordenador u otro), etc.