Taller de Bases de Datos Documentales Temas avanzados 2: Relaciones entre Bases de Datos

Por Llus Codina1

ltima revisin, febrero 2002

PRIMER

PARTE:

TEORA

DE LAS BASES

DE DATOS RELACIONADAS

Relaciones Las bases de datos representan entidades, que pueden ser objetos materiales como libros y fotografas, seres animados como personas o ideas abstractas como teoras y conceptos. Para ser eficaces, las bases de datos deben representar a las entidades con la mayor fidelidad posible. Es por ello que los registros de las bases de datos deben incluir las propiedades ms relevantes de cada tipo de entidad. Esto se hace a travs de los modelos de registros que, como sabemos, se articulan en campos que, a su vez, corresponden a propiedades de las entidades. Si el modelo de registro descuida alguna propiedad importante de una entidad, la base de datos ser ineficiente. Ahora bien, las entidades, adems de tener atributos, tienen relaciones entre ellas. Por ejemplo, supongamos una base de datos de imagen que contenga datos sobre fotografas y sobre fotgrafos. Ciertamente, tanto las fotografas como los fotgrafos son entidades que poseen determinadas propiedades, y los registros deben recogerlas de la forma ms adecuada posible en sus modelos de registro, siempre segn los objetivos de la base de datos y el pblico de la misma. Ahora bien, por el mismo motivo que necesitamos representar a las entidades y a sus propiedades, necesitamos tambin representar las relaciones que se dan entre las entidades. Por ejemplo, entre imgenes y autores se da la siguiente relacin: las imgenes son hechas por autores. Para saber como tratar estas relaciones en una base de datos necesitamos determinar el grado de la misma. A efectos de su representacin, consideramos que los grados de una relacin pueden ser de tres clases: - De uno a uno (1:1) - De uno a varios (n:1) - De varios a varios (n:m) Ejemplo de relacin 1:1 es la que existe entre monografas e ISBN. Cada monografa tiene un nmero de ISBN y solo uno (1); por otro lado, cada nmero de ISBN se asigna a una monografa y solo a una (1). 1
2
Doctor en ciencias de la informacin. Profesor titular de universidad. Universitat Pompeu Fabra de Barcelona. Correo electrnico: lluis.codina@cpis.upf.es Evitamos expresamente la expresin "bases de datos relacionales" para no crear

confusin.

Una relacin 1:n es la que se da, por ejemplo, entre profesores y departamentos. Cada departamento tiene varios profesores (n), pero cada profesor solamente puede formar parte de un departamento (1). Por ltimo, una relacin n:m es la que existe entre realizadores y films. Por un lado, un realizador puede haber dirigido varios films (n), pero tambin puede ser que un mismo film tenga varios realizadores (m). Consecuencias para el diseo Las relaciones y los grados de la relacin tienen implicaciones en el diseo de bases de datos, segn veremos a continuacin: 1:1 Si la relacin es de tipo 1:1, esto significa que debemos tratar a las dos entidades como una sola. Siguiendo con nuestro ejemplo, en el caso de las monografas y los nmeros de ISBN, nos conviene considerar que el nmero de ISBN es una ms de las propiedades de la monografa junto a otras como ttulo, autor, fecha de publicacin, etc. Por tanto, cuando determinamos una relacin 1:1, necesitamos un solo modelo de registro. Cualquiera de las dos candidatas a entidad puede ser la entidad representada en la base de datos, siendo la otra candidata una propiedad de la entidad. 1:n y n:m Si la relacin es de tipo 1:n o de tipo n:m necesitaremos al menos dos modelos de registros: uno para cada entidad. Para indicar la relacin necesitaremos que ambos registros tengan un campo en comn, es decir, un campo con el mismo dominio (el mismo tipo de valores) y con el mismo tipo de dato (textual, numrico, etc.). En el caso de profesores y departamentos el campo comn puede ser el cdigo del Departamento. Una representacin simplificada de los dos registros de nuestra base de datos imaginaria de profesores y departamentos podra la siguiente: Modelo de registro: Profesores Elvis, Juan Nombre Departamento D011 Bases de datos documentales Asignatura Modelo de registro: Departamentos Documentacin y Comunicacin Nombre D011 Cdigo C/. Balmes, sector norte, Edificio Ciencias Sociales, n. 123 Direccin 08787 Barcelona Gracias al campo comn, Departamento en el primer modelo de registro y Cdigo en el segundo modelo, podremos cruzar datos. Obsrvese que no

es necesario que las etiquetas de los campos sean iguales. Lo que necesitamos es que ambos campos tengan el mismo dominio. Por ejemplo, podremos disear una consulta donde aparezcan relacionados junto a cada departamento de la universidad los profesores que forman parte del mismo y las asignaturas que imparten, etc. Pero, porqu no podramos tener un solo modelo de registro? Por ejemplo, porqu no podramos representar al departamento como una caracterstica de la entidad profesor y as simplificar el diseo? Piense el alumno en la respuesta e intente ver qu consecuencias podra tener que tuviramos un solo modelo de registro unificado, por ejemplo como el siguiente, en el cual que hay una sola entidad, profesores, con los datos del departamento como caractersticas de la entidad: Modelo de registro: Profesores Elvis, Juan Nombre D011 Cdigo Dep. Bases de datos documentales Asignaturas Departamento Documentacin y Comunicacin Direccin Dep. C/. Balmes, sector norte, Edificio Ciencias Sociales, n. 123 08787 Barcelona Bases de datos intermedias en relaciones n:m Para entidades que mantienen entre ellas relaciones del tipo n:m a veces se necesitan tres bases de datos: una para cada entidad y una tercera para la relacin. Los casos en los que es necesaria esta tercera base de datos son aquellos en los cuales la relacin, como hemos dicho es de tipo n:m, y la naturaleza de esta es dinmica, es decir, cuando consiste en una actividad que cambia en el tiempo. El ejemplo clsico son las operaciones de prstamo de documentos en las bibliotecas o centros de documentacin. Tenemos, en este caso, dos entidades: documentos y usuarios y una relacin, el prstamo de documentos. Como los usuarios de un documento van cambiando en el tiempo, un mismo documentos puede ser prestado a lo largo del tiempo a distintos usuarios. Adems, un mismo usuario puede tener distintos documentos en prstamos. En esta situacin la relacin no es esttica, por lo tanto estamos ante un caso en el que se requieren tres bases de datos: la base de datos de libros, la base de datos de usuarios y la base de datos de prstamos. La base de datos intermedia contendr un registro para cada prstamo. Por tanto, deber abrirse un registro nuevo cada vez que se realice un prstamo. Ser conveniente que cada entidad tenga un identificador nico; por ejemplo, los documentos deben tener un nmero nico, y los usuarios tambin debern tener un nmero de identificacin nico. El registro de cada prstamo tendr campos comunes a ambas bases de datos junto con campos propios, como la fecha del prstamo y la de fecha de devolucin.

Relacionar bases en Inmagic En Inmagic podemos relacionar una base de datos a una o ms bases de datos para combinar la informacin que contienen (hasta un mximo de cuatro bases de datos). En Inmagic las relaciones se establecen a nivel de campos: un campo de una base de datos se enlaza con otro campo de otra base de datos. La relacin se produce cuando el valor de estos campos coincide. Por ejemplo, sean las bases de datos Documentos y Autores. Cuando el campo enlazado Autor en la base de datos Documentos, contiene el mismo valor que el campo Nombre en la base de datos Autores, se produce la relacin. Entonces, se pueden combinar datos de ambos registros enlazados mediante un formato de consulta --primer paso-- y de visualizacin --segundo paso--. Obsrvese que, como se ha indicado, los campos comunes, es decir, los campos enlazados no necesitan tener el mismo nombre en las dos bases de datos, pero s deben tener el mismo dominio, En Inmagic, las bases de datos enlazadas reciben el nombre de base de datos primaria (de la que parte el enlace) y de base de datos secundaria (la que recibe el enlace) respectivamente. El campo del que parte la relacin en la base de datos primaria se llama campo enlace. El campo relacionado correspondiente de la base de datos secundaria se llama campo asociado. La definicin del enlace solamente se realiza en la base de datos primaria. En la base de datos secundaria no es necesario realizar ninguna indicacin, aunque deben cumplir algunas condiciones, como veremos. En contrapartida, las relaciones son unidireccionales: base de datos primaria > base de datos secundaria, pero no al revs. Solamente la base de datos primaria "sabe" que existe la relacin. Inmagic recomienda que la base de datos primaria sea la que cambia con ms frecuencia, y la base de datos secundaria la que contiene los datos ms estructurales o que cambian con menor frecuencia. En nuestro ejemplo anterior, la base de datos Documentos debera ser la base de datos primaria y la base de datos Autores, la base de datos secundaria. Para relacionar bases de datos en Inmagic, se requieren al menos tres tareas: 1. Definir una segunda base de datos Para relacionar bases de datos se requieren, al menos dos tipos de entidades distintos. Si ya tenemos una base de datos (primer tipo de entidad), debemos definir la segunda base de datos (segundo tipo de entidad) que va estar relacionada con la primera. 2. Definir un campo enlace en la base de datos primaria La relacin se define en la base de datos primaria mediante la ventana de edicin de campos. El campo enlace en la base de datos primaria se define con el tipo de campo Enlace.

El campo enlace debe tener indizacin por Trminos, sin perjuicio de tener tambin indizacin por Palabra. El campo enlace es siempre del tipo Slo una entrada en los controles de Validacin. Adicionalmente, es aconsejable que sea del tipo Obligatorio y Slo entradas nicas. Por su parte, el campo asociado de la base de datos secundaria debe responder a las mismas especificaciones respecto a indizacin (indizacin por Trminos), y es aconsejable que sea tambin de valores nicos y no repetidos. 3. Crear un formato de visualizacin en la base de datos primaria El formato de visualizacin puede incluir cualquiera (o todos) los campos de la base de datos primaria y cualquiera (o todos) los campos de la secundaria. Para que se visualice alguna informacin de los campos de la base de datos secundaria en el formato de visualizacin es necesario que haya dos registros coincidentes. Adicionalmente, es recomendable una cuarta tarea: 4. Crear un formulario de consulta en la base de datos primaria Lo significativo, en este caso, es que el formulario de consulta de la base de datos primaria puede incluir campos de la base de datos secundaria. De este modo, se pueden consultar datos de la base de datos secundaria desde la base de datos primaria. SEGUNDA
PARTE:

TALLER

0. Escenario y diccionario de datos Para esta prctica, seguiremos con el escenario que nos sirvi para crear la base de datos Imagen. Si el alumno realiz la prctica de publicacin de bases de datos en Internet, es probable que su base de datos Imagen haya cambiado de nombre. Por ello, Imagen es el nombre de una variable: designa al nombre concreto con el cual cada alumno renombr a su base de datos Imagen. Si el alumno an no ha realizado el taller de publicacin en Internet, su base de datos seguir denominndose Imagen. Supongamos que hemos visto la necesidad de contar con una nueva base de datos que nos ayude a gestionar la informacin sobre los autores de las imgenes que contiene nuestra base de datos Imagen. Esta nueva base de datos hemos decidido llamarla Autores. Tendremos que decidir tambin cul es el nexo entre las dos bases de datos. Como sabemos, conviene que el nexo de unin sea una propiedad que genere valores nicos y no repetidos. Parece que el nombre del autor ser el ms adecuado en este caso. La alternativa sera otorgar una clave de identificacin nica a cada autor, pero en este contexto el apellido cumple bien ese papel, ya que la posibilidad que dos autores distintos tengan el mismo nombre es remota. Por tanto, tendremos dos bases de datos y el tipo de relaciones que se expresa en la tabla siguiente:

Proyecto Bases de BD primaria Campo enlace BD secundaria Campo asociado

Datos Acme Imagen Autor Autores Nombre

Vemos, por tanto, la necesidad de crear una segunda base de datos. Como consecuencia de ello, hemos preparado este diccionario de datos: Diccionario de datos Base de Datos Autores
Campo Nombre Dominio Apellido, Nombre del autor de la imagen Pas del autor Breve biografa del autor Iniciales del operador Fecha de creacin del registro Nmero nico de identificacin de cada registro Tipo de campo Texto Indizacin Trmino Palabra Trmino Palabra Trmino Palabra Palabra Palabra Trmino Palabra Validacin Entrada obligatoria Slo entradas nicas Entrada obligatoria Entrada obligatoria Entrada obligatoria No hay validacin Entrada obligatoria

Nacionalidad Biografa Operador FechaAlta NumReg

Texto Texto Texto Fecha automtica ID automtico

1. Primera operacin: creacin de la base de datos secundaria Por el procedimiento que el alumno ya conoce, debe crear una base de datos con Inmagic, denominada Autores, que responda al diccionario de datos anterior. Esta base de datos deber estar situada en el mismo directorio y carpeta que la base de datos Imagen creada anteriormente. Una vez creada Autores, dar de alta estos dos registros (como siempre, obviamos representar aqu los tres ltimos campos de tipo administrativo): (1) Nombre Nacionalidad Biografa Adams, Ansel Norteamericano San Francisco 1902 - Monterrey (Mxico) 1984. Uno de los grandes artistas de la historia de la fotografa. Elev la fotografa de paisajes a cotas mticas

(2) Nombre Nacionalidad Biografa

Cartier-Bresson, Henry Francs Chanteloup 1908. Fotgrafo y cineasta. A partir de la

segunda guerra mundial su obra se centra en el reportage. Fundador de la Agencia Magnum El resultado deber ser similar al siguiente (mostramos nicamente el primer registro):

Una vez haya dado de alta los dos registros anteriores, puede cerrar esta base de datos Autores y pasar a la siguiente fase. 2. Segunda operacin: preparacin de la base de datos primaria Abra la base de datos Imagen. Vamos a declarar el campo Autor como campo enlace. Para ello: Mantener > Editar estructura. Haga clic en el campo Autor para seleccionarlo. Clic en Editar campos:

Despus, haga clic en Tipo e Indizacin. Seleccione en Tipo de campo: Enlace. Se abrir una ventana para que seleccione la base de datos secundaria:

Seleccione la base de datos Autores. Una vez seleccionada, mostrar una lista de campos. Seleccione Nombre y clic en Aceptar:

Confirme con Aceptar. Despus, en Editar Campos, haga clic en Cambiar y despus en Cerrar:

Confirme despus en las sucesivas ventanas que le pidan confirmacin, hasta que se cierre la ltima y el cambio quede realizado. Si ha seguido bien todos los pasos, ahora ya tiene dos bases de datos relacionadas. La base de datos Imagen es la base de datos primaria, y la base de datos Autores es la secundaria. Las operaciones de cruce de datos se harn siempre desde la base de datos primaria. 3. Tercera operacin: modificacin del formulario de visualizacin Ahora vamos a modificar el formato de visualizacin de la base de datos primaria para que podamos cruzar datos de ambas bases (siempre que haya coincidencia en los datos de los campos relacionados). Tambin podramos crear un formato nuevo, pero para simplificar la prctica, nos limitaremos a modificar el formato que ya tenemos. Para ello: Ver > Disear formato... Seleccionar el formato en uso. Si sigui las convenciones de talleres anteriores, podr seleccionar el formato Normal (o cualquier otro que usted haya creado):

Haga clic en el lugar aproximado donde quiere que aparezca el nuevo recuadro (por ejemplo, haga clic en el recuadro Autor para quede debajo de este)y despus haga clic en el botn de aadir recuadro:

Aparecer una ventana para definir las propiedades del formato (no se preocupe si el nuevo recuadro no queda situado donde usted deseara, ya lo mover despus):

En la pestaa Campos, desplace el cursor y ver que, adems de los campos de la base de datos Imagen (la que tenemos abierta ahora), aparecen listados los campos de la base primaria y tambin de la secundaria:

Los campos de la base de datos secundaria se muestran seguidos de @Autor, para indicar que son de la otra base de datos. Seleccione Nacionalidad@Autor y haga Aadir, de manera que el campo indicado quede asignado al nuevo recuadro:

Haga otras modificaciones de manera que en la pestaa Etiqueta quede activada la opcin Mostrar etiqueta y que la Etiqueta del recuadro sea Nacionalidad. Haga Aplicar, Cerrar. Haga los ajustes para que el diseo final del formato de visualizacin sea, ms o menos como ver a continuacin, con la observacin de que no es importante que sea idntico, ni siquiera es necesario que en el formato final figuren los mismos campos, pero s es imprescindible que figure el recuadro Nacionalidad:

Observe que hemos aadido el recuadro Nacionalidad, y vea as mismo que la indicacin del campo del recuadro es Nacionalidad@Autor. Guarde los cambios del formato y cierre la ventana: , Vamos a comprobar la funcin del nuevo formato de visualizacin. Vaya a la plantilla de consultas para recuperar la ficha datos de la imagen titulada Moonrise (o abra toda la base y haga una exploracin secuencial). Con el nuevo formato de visualizacin, ahora tenemos este resultado:

Vemos que, ahora, la base de datos Imagen cruza datos de la otra base y los muestra de manera unificada. En concreto, la nacionalidad no forma parte de la base de datos Imagen, sino de la base de datos Autores, sin embargo los ha combinado en nuestro nuevo formato. Es importante entender que el cruce de datos solamente se produce en los casos en los cuales haya un registro de cada base de datos con datos en

comn. En concreto, solamente hemos dado de alta dos autores en la base de datos secundaria, pero en la base de datos primaria hay otros nombres de autor. Solamente cuando coincidan los valores de dos registros (uno de la base primaria y otro de la secundaria) se producir el cruce de datos. Tambin es importante entender que las bsquedas cruzadas solamente tienen lugar desde la base de datos que hemos declarado como primaria hacia la base de datos secundaria, pero no al revs. El alumno puede disear otros formatos de visualizacin con distintas combinaciones de campos, si desea avanzar ms en este tema. 4. Otras modificaciones Siguiendo un procedimiento idntico a los anteriores, el alumno debe intentar disear ahora un formulario de consulta que permita consultar la base de datos secundaria desde la base de datos primaria. Por ejemplo, modifique el recuadro Buscar en cualquier campo para obtener informacin sobre imgenes a partir de algn dato de la biografa del autor. Deber modificar las propiedades de ese recuadro para aadir el campo Biografa de la base de datos secundaria (Autores). Una vez modificado el recuadro del formulario de consulta, debe tener esta apariencia:

Ponga a prueba este formulario buscando la ficha de una imagen cuyo autor haya sido cineasta (use el trmino cineasta en el recuadro Buscar en cualquier campo para lanzar la bsqueda). El resultado debe ser la ficha de una fotografa de Cartier-Bresson. Sin embargo, aunque haya recuperado el registro indicado, no aparecen los datos biogrficos. Es lgico que sea as. Se debe a que el formato de visualizacin no incluye ese campo, pero se podra conseguir que apareciese ese campo si se modifica el formato de la forma que ya conoce. A efectos de esta prctica no es necesario.

Tambin puede crearse informes para cruzar datos por el procedimiento ya practicado. Finalmente, las operaciones de mantenimiento de la base de datos primaria tambin pueden beneficiarse de los enlaces, utilizando directamente el ndice de valores de la base de datos secundaria para entrar valores en el campo enlazado procedentes del campo asociado. Las posibilidades de los enlaces en Inmagic son muy numerosas. Nada impide que una base de datos secundaria sea primaria a su vez. Por otro lado, una base de datos primaria puede enlazar hasta cuatro bases de datos secundarias. Sin embargo, con lo visto hasta ahora daremos por acabada esta prctica, sin prejuicio que el alumno, si es de su inters contine profundizando en el tema diseando otros formatos (informes, visualizacin, consultas) y haciendo pruebas con otras posibilidades de relacin (puede invertir la relacin y declarar ahora un enlace desde la base Autor a la Imagen). Fin de esta prctica
L. Codina, febrero 2002