Universidad Rey Juan Carlos Aplicaciones Informticas a la Fisioterapia

A.Guzmn M.Ortuo 2000/2001

Prcticas Bases de Datos. Anexo 3

Ficheros de la base de datos
Cuando entramos en Access y creamos una nueva base de datos partiendo de una Base de Datos en blanco, lo primero en indicar dnde guardar el fichero. Si no indicamos ninguna carpeta, el sitio por defecto es C:\mis documentos Este puede ser un sitio vlido para guardar documentos. Pero para familiarizarnos con el uso de carpetas1 tambin podemos guardar por ejemplo en C:\temp\mi_nombre\mi_documento.mdb O en cualquier otro sitio que tengamos bajo nuestro control. En principio es posible guardar directamente en el disquete o en una carpeta de red en un servidor (Como pj Bart). Pero no es en absoluto recomendable: Todo ir ms lento, cada vez que consultemos o modifiquemos una fila, o simplemente pasemos de una ventana a otra, habr que leer o escribir en el disquete o en la unidad de red, lo que es mucho ms torpe y propenso a errores. Lo apropiado es: Trabajar siempre contra el disco duro local Finalizado el trabajo, cerrar access y desde el explorador de windows, copiar o mover el fichero .mdb al disquete o a la unidad de red. Copiarlo con el explorador desde el disquete o la unidad de red al disco duro local Trabajar en el disco local.

Cuando queramos volver a trabajar con el documento -

Lo que no debemos hacer es desde access usar Archivo | guardar como o exportar Porque esto lo que guarda no es la base de datos entera, sino slo el objeto (tabla, consulta...) que est seleccionado en ese momento. (Obviamente no debemos hacerlo a no ser que lo que realmente queramos sea eso, exportar slo determinado objeto) Debemos tambin tener en cuenta que un disquete es un soporte muy barato pero muy poco fiable: Se puede estropear, borrar accidentalmente. Si nuestro trabajo es medianamente importante, es imprescindible hacer copias de seguridad frecuentes. Aunque con las copias de seguridad tambin hay que tener cuidado: Como en toda duplicidad corremos el riego de inconsistencia: Que la copia no concuerde con el original, por ejemplo porque un da hayamos trabajado sobre una copia antigua en vez de sobre la versin ms reciente.

Extensiones
Los ficheros con bases de datos Access tienen extensin .mdb2, aunque desde access no es necesario indicarlo, lo pone por defecto. Cada vez que abramos una BD, access crea un fichero temporal con el mismo nombre de la BD, con extensin .ldb y un icono ligeramente distinto. (El docuento, una llave y una tuerca). Si cuando vamos a copiar el documento desde el explorador vemos el fichero temporal ldb, generalmente se debe a que hemos olvidado cerrar access. Aunque puede ser que el fichero est ah porque windows se haya bloqueado anteriormente con el fichero abierto. Si estamos seguros de que access est cerrado y vemos un fichero .ldb con fecha antigua, podemos borrarlo sin ms.

Aproximacin a las relaciones entre tablas

Cuando alguien empieza a trabajar con una BD como Access por las buenas, usando slo el prueba y error y sin ninguna nocin de Bases de Datos, su tendencia natural es repetir informacin de una tabla en otra. Supongamos que se quiere almacenar informacin sobre pacientes y fisioterapeutas de una clnica, de cada paciente almacenamos, entre otras cosas, el fisioterapeuta que le trata.
1

Recordemos que podemos considerar que carpeta es sinnimo de directorio. As como fichero es, ms o menos, equivalente a documento o archivo.
2

Para ver la extensin tal vez debamos personalizar el explorador como indica el anexo 2. 1

Universidad Rey Juan Carlos Aplicaciones Informticas a la Fisioterapia

A.Guzmn M.Ortuo 2000/2001

La primera idea sera algo as: Pacientes: Nombre Juan Mara Apellidos Snchez Fisioterapeuta Ana Mara Garca Fernndez Ana Mara Garca

Fisioterapeutas Nombre Ana Mara Alberto Apellidos Garca Snchez

Esto es errneo, por varias razones. La fundamental es que se est copiando informacin entre una tabla y otra. La informacin est duplicada, y esa duplicidad se debe evitar a toda costa. Una razn puede ser ahorrar espacio, pero eso lo de menos. El principal problema es lo difcil que es tratar toda la informacin repetida y el riesgo de inconsistencia: que la datos duplicados acaben siendo distintos. En el ejemplo anterior Qu pasa si para un paciente se dice que su fisioterapeuta es Ana Garca (En vez de Ana Mara Garca) O Ana Garcia (Sin acento). Seran distitos. Y si resulta que una vez hecha la BD hay que cambiar los datos de Ana Mara Garca? O lo hacemos con mucho cuidado actualizando todos sus pacientes, (lo cual es una tarea pesada y donde es fcil cometer errores), o la BD quedar en estado inconsistente: Unos pacientes tendrn los datos viejos, otros los nuevos. Lo correcto es establecer una relacin entre las tablas. Algo como esto: paciente: Nombre Juan Mara Apellidos Snchez Id_fisioterapeuta 1 Fernndez 1

fisioterapeuta id_fisioterapeuta Nombre 1 2 Ana Mara Alberto Apellidos Garca Snchez

En este segundo caso hemos creado una relacin mediante el atributo id_fisioterapeuta. (Adems, el nombre de la tabla lo hemos puesto en singular, lo que recomiendan muchas metodologas). Diremos que fisioterapetura.id_fisioterapeuta es una clave principal (es el atributo por el que identificaremos las filas), mientras que paciente.id_fisioterapeuta (Atributo id_fisioterapeuta de la tabla paciente) es una clave ajena (no es clave principal en esta tabla pero s en la primera). A la tabla con la clave principal access le llama tabla principal, a la segunda, tabla relacionada. Otra mejora que necesitaran estas tablas es aadir una clave principal a paciente.

Un ejemplo
Supongamos lo siguiente: Un Fisioterapeuta trata pacientes. Cada paciente tiene un tratamiento. Un tratamiento est compuesto por una o ms terapias. De los pacientes debemos saber nombre, apellido, direccin, ciudad, CP , telfono1 y telfono2. De los fisioterapeutas, nombre y apellidos. De cada tratamiento, su fecha (de inicio). De cada terapia, su nombre. De cada una de las terapias aplicadas en un tratamiento concreto, n de sesiones, tiempo de tratamiento y una descripcin. De aqu identificamos las entidades: Fisioterapeuta, paciente, tratamiento y terapia. Y las relaciones entre ellas: Un fisioterapeuta trata pacientes, un paciente tiene un tratamiento, un tratamiento est compuesto de terapias.

Universidad Rey Juan Carlos Aplicaciones Informticas a la Fisioterapia

A.Guzmn M.Ortuo 2000/2001

Lo siguiente es asignar cardinalidades a las relaciones: Un fisioterapeuta trata muchos pacientes, pero cada paciente es tratado por un solo fisioterapeuta, esto es una relacin 1:N (O lo que es lo mismo, uno a muchos) En nuestro modelo hemos establecido que un paciente tiene un tratamiento (y solo uno) y que un tratamiento corresponde a uno y solo un paciente, es una relacin 1:1. En el caso de relaciones 1 a 1, casi siempre ambas entidades/tablas pueden unirse en una sola, aunque en este caso no lo haremos por simplificar y ver un ejemplo 1:1. Un tratamiento est compuesto de varias terapias. Y sin duda, una misma terapia podr estar presente en muchos tratamientos distintos. Esta es una relacin N:N. Cuando pasemos este modelo a tablas, la relacin N:N generar una tabla auxiliar y dos relaciones 1:N como veremos despus.3 Todo esto lo llevamos al diagrama Entidad Relacin de la figura 1.
N :1

P a c ie n t e

T ra ta

F is io t e r a p e u t a

T ie n e

1 :1

N :N

T ra ta m ie n to

C o m p u e s to p o r

T e r a p ia

Figura 1 - Diagrama Entidad-Relacin

Creacin de las tablas.

Una vez que tenemos claro el modelo con lpiz y papel, lo llevamos a las tablas Access. En primer lugar creamos las tablas. Podemos guiarnos por la Figura 2. Las claves principales aparecen marcadas en negrita. Todas las claves principales formadas por un solo atributo, las definimos de tipo autonumrico. Las claves ajenas son de tipo numrico. La clave principal de tratamiento-terapia est formada por la unin de dos claves ajenas: Es tambin de tipo numrico. Lo que en la Figura 1 era una relacin N-N vemos que en la Figura 2 se convierte en una tabla auxiliar (tratamiento-terapia) y dos relaciones 1-N, cuyo nombre es la unin de los nombres de ambas tablas (esto no es obligatorio pero s recomendable) y cuya clave principal es la unin de las claves principales de las dos tablas (esto s debe ser siempre as) Recordemos que una relacin siempre se crea a travs de un atributo, el caso ms habitual es el de la relacin 1:N donde en una tabla el atributo es clave principal, en la otra, clave ajena. No es obligatorio que el atributo tenga el mismo nombre en ambas, pero s es muy recomendable. El tipo del atributo debe ser el mismo, con una excepcin muy importante y muy frecuente: Un atributo puede ser numrico y el otro autonumrico. Las cardinalidades de las relaciones, contra lo que se pueda pensar, no las indicaremos nosotros al crear la relacin, sino que las pondr automticamente access segn como estn definidos los atributos. Por el extremo de la relacin donde haya una clave principal o un indexado sin duplicados, la relacin ser 1 Por el extremo donde el atributo no sea ni clave principal ni indexado sin duplicados4, la relacin ser N

Por tanto para que la relacin entre tratamiento y paciente sea 1 a 1 debemos marcar tratamiento.id_paciente como indexado sin duplicados, tal y como vemos en la Figura 3. Indexado sin duplicados lo que hace es dar un error en caso de que intentsemos hacer algo as:
3

En la vida real, hacer correctamente todo este proceso no es una tarea sencilla, en el caso de un problema de tamao no trivial es labor de un Analista Informtico, un especialista que hara el modelo y coordinara a el/los programador/es que lo llevaran a la prctica. Tal vez el analista sea tambin el programador, pero son roles distintos.
4

En tratamiento-terapia la relacin id_tratamiento-id_tratamiento es 1-N porque id_tratamiento no es clave principal ni indexado sin duplicado; la clave principal es la unin de id_tratamiento e id_terapia. Lo mismo puede decirse de la relacin id_terapia-id_terapia 3

Universidad Rey Juan Carlos Aplicaciones Informticas a la Fisioterapia

A.Guzmn M.Ortuo 2000/2001

Tabla: tratamiento Id_paciente 1 1 id_tratamiento 4 16 Fecha 1/11/2000 4/1/2001

Es decir, impide que haya dos filas con el mismo valor para id_paciente, impide que un mismo paciente tenga dos tratamientos distintos, exige que la relacin entre tratamiento y paciente sea 1 por el lado de tratamiento.

Implementacin en Access de las relaciones.

Creadas las tablas y con los atributos de tipo correcto, lo que resta es muy sencillo. Antes de empezar a marcar relaciones, debemos cerrar todas las tablas, si intentamos crear relaciones entre tablas abiertas access dar un error. Entramos en la ventana relaciones, desde Herramientas | relaciones O pulsando el icono relaciones desde la ventana Base de Datos. En este momento no veremos ninguna tabla sobre la que marcar relaciones, pulsando el botn derecho del ratn aparece un men contextual con las opciones Mostrar Tabla, que nos permite agregar tablas, o Mostrar Todo, que agrega todas las tablas. Si posteriormente creamos tablas nuevas, debemos repetir este proceso. Para crear la relacin, simplemente hacemos clic sobre el atributo en que se basa la relacin en una de las tablas y lo arrastramos al segundo. Aparecer el cuadro de dilogo relaciones. En general es recomendable activar la casilla exigir integridad referencial. Pulsamos crear y se crear la relacin. Si queremos acceder de nuevo a esta ventana, desde la pantalla de relaciones, hacemos clic sobre la lnea de la relacin y pulsamos el botn derecho.

Figura 2 - El modelo, llevado a la prctica

Universidad Rey Juan Carlos Aplicaciones Informticas a la Fisioterapia

A.Guzmn M.Ortuo 2000/2001

Recordemos que el concepto integridad referencial significa, entre otras cosas, que cuando se crea una fila en una tabla relacionada y se indica la clave ajena, debe existir la clave principal en la tabla principal. Aplicado a nuestro ejemplo: Si se dice que un paciente tiene como fisioterapeuta al profesional cuyo id_fisioterapeuta vale 13, este fisioterapeuta debe existir. Exigiendo integridad referencial, tampoco podramos borrar el fisioterapeuta ni cambiarle su clave principal si es referenciado por algn paciente. En la Figura 2 tenemos la implementacin de las relaciones. Observamos que Access usa la notacin 1- en vez de 1-N. Si en las relaciones no exigimos integridad referencial, no aparecern los smbolos 1-.

Figura 3 - Definicion de tratamiento.id_tratamiento indexado sin duplicados

Normas de Grabacin de datos

Creadas las tablas, podemos empezar a introducir datos. Como consecuencia inmediata de la integridad referencial, el orden debe ser el siguiente: Tablas sin claves ajenas Tablas con claves ajenas Tablas auxiliares generadas a partir de relaciones N a N

En nuestro ejemplo, primero fisioterapeuta y terapia, despus paciente, tratamiento, y por ltimo tratamiento-terapia. En la Figura 4 podemos ver el tratamiento (2) correspondiente al paciente Francisco Iglesias (8), que es tratado por Mara Fernndez. Consta de la aplicacin de dos terapias: Onda corta y tracciones. Observamos que onda corta es la terapia de id_terapia 8, mientras que la aplicacin de la onda corta en un tratamiento concreto es la fila (2,8) de tratamiento-terapia.

Universidad Rey Juan Carlos Aplicaciones Informticas a la Fisioterapia

A.Guzmn M.Ortuo 2000/2001

Figura 4 - Un tratamiento

Otro ejemplo
Supongamos que necesitamos una Base de Datos que contenga informacin sobre discos y sus intrpretes. Identificamos las entidades disco, intrprete, y la relacin disco es de intrprete. Hasta aqu es evidente. Podramos haber elegido otros nombres, pero debera ser muy parecido. Pasamos a asignar cardinalidades. Lo ms sencillo sera N-1, un disco es de un intrprete, un intrprete tiene varios discos. Esto sirve para la mayora de los discos, pero si queremos que nuestro modelo sea capaz de almacenar que hay discos que tienen varios intrpretes, la relacin debe ser N-N, como muestra la Figura 5.

N -N D is c o Es de In t r p r e te

Figura 5 - Diagrama Entidad-Relacin

Definido el modelo, lo llevamos a Access como ya sabemos, generando una tabla auxiliar, tal y como muestra la Figura 6. Disco.id_disco e interprete.id_interprete son claves principales, de tipo autonumrico. En disco_interprete son claves ajenas de tipo numrico, la unin de ambos claves ajenas forma la clave principal.

Universidad Rey Juan Carlos Aplicaciones Informticas a la Fisioterapia

A.Guzmn M.Ortuo 2000/2001

Figura 6 - El modelo anterior, en Access Ya podemos introducir valores. En la tabla disco almacenamos el nombre del disco, la tabla interprete contiene los autores, y en la tabla disco_interprete se almacena de quin es cada disco. Si un disco tiene tres intrpretes, esto sern tres filas en esta tabla.

Columna de bsqueda
Sabemos que lo correcto es que en disco_intrprete figure no el nombre del disco, sino la clave. No debe figurar el nombre del intrprete, sino su clave. Aunque esto puede parecer incmodo a la hora de meter datos, ya que, en principio, si queremos introducir determinado intrprete, habra que consultar primero cual es su clave. Lo que adems de engorroso puede provocar errores. Para evitarlo, podemos usar una columna de bsqueda. La idea es que en la tabla se almacenar la clave del disco, pero el usuario cuando lo introduzca, no indica la clave sino el ttulo, access automticamente busca la clave correspondiente y es lo que mete en la tabla. A la hora de mostrarse la tabla, aunque lo que hay en la tabla es la clave principal, access busca el ttulo correspondiente y es lo que muestra. Para ello, una vez que hemos definido disco_interprete como hasta ahora5, abrimos en modo diseo disco_interprete y cambiamos el tipo de id_disco a asistente para bsquedas 1. 2. 3. 4. 5. Dejamos el valor por defecto, indicando que la columna de bsqueda busque valores en una tabla. La tabla que proporcionar valores para la columna de bsqueda ser disco. El campo que contiene los valores de la columna de bsqueda es titulo, Ajustamos el ancho de la columna para que quepa el ttulo completo, o un fragmento suficiente. Para la etiqueta de la columna de bsqueda dejamos el valor por defecto.

Ahora sobre esta misma tabla hacemos lo mismo con id_intrprete, indicando que la tabla es intrprete y el campo que contiene el valor de la columna de bsqueda, nombre. As llegaremos al resultado de la Figura 7. No debe inducirnos a error: En la tabla, aunque veamos el valor de ttulo o nombre, lo que contiene es el identificador, la clave principal. Si en la tabla interprete cambiamos por ejemplo Sabina por Joaqun Sabina, observamos como se modifica lo que muestra disco_interprete. Observamos tambin que si volvemos a la tabla disco_interprete en vista diseo, aunque pusimos los atributos de las claves ajenas en tipo asistente para bsqueda, siguen estando de tipo numrico: La razn es la misma, la tabla sigue conteniendo los valores (numricos) de las claves, aunque access nos lo ensea con un aspecto diferente para que nos resulte ms cmodo.

Como en este ejemplo la columna de bsqueda se aplica sobre atributos que forman la clave principal de la tabla, es necesario que primero definamos los atributos de tipo numrico, guardemos la tabla, creemos las relaciones y luego usemos el asistente para bsquedas. En otro caso ms sencillo, podramos usar el asistente directamente. Si queremos una norma sencilla de recordar y siempre vlida: Primero crear las tablas y las relaciones. Hecho esto, podemos indistintamente meter filas o definir las columnas de bsqueda. 7

Universidad Rey Juan Carlos Aplicaciones Informticas a la Fisioterapia

A.Guzmn M.Ortuo 2000/2001

Figura 7 - Uso de la columna de bsqueda