Metodología de creación de bases de datos documentales (Parte II)

6. Relaciones

Volvamos al modelo Entidad-Relación (E-R). Las entidades del mundo real pueden tener relaciones entre ellas y, mientras que las entidades suelen nombrarse mediante sustantivos, las relaciones se nombran mediante verbos. Por ejemplo, consideremos el caso de una base de datos sobre teatro español. Un análisis intuitivo nos mostraría la existencia de dos entidades relevantes para el sistema: [obras de teatro] y [autores teatrales], y veríamos que entre ambas entidades existe la relación <escriben>, que significa más explícitamente que [autores teatrales] <escriben> [obras de teatro].

Gráficamente, estas relaciones entre entidades se pueden representar así:

Un aspecto importante de la relación es su grado, el cual indica el número de elementos que pueden participar en cada uno de los extremos de la relación, en este caso [autores] y [obras de teatro]. Este grado puede ser de uno a uno (1:1), de uno a muchos (1:N) y de muchos a muchos (N:M).

Por ejemplo, la relación que existe entre el número de ISBN y un libro es una relación de 1:1 porque un número de ISBN se asigna a un solo libro, y cada libro tiene un solo número de ISBN.

En cambio, la relación entre profesores y universidades es de 1:N, porque cada profesor pertenece a una sola universidad y una universidad tiene muchos profesores.

Finalmente, una relación de N:M sería la que existe entre autores de teatro y obras de teatro, porque un autor puede escribir diversas obras de teatro, y una obra de teatro puede estar escrita por varios autores y justamente ése es el significado de las letras N y M que hemos puesto en la tabla anterior.

Además, la participación de la entidad puede o no ser obligatoria en la relación. Por ejemplo, en la relación entre ISBN y libros, la participación de la entidad [libros] es obligatoria, porque siempre que hay un número de ISBN hay un libro. En cambio lo contrario no es cierto, porque hay libros que no tienen número de ISBN.

Esta última parte del análisis entidad-relación (grado y participación) es muy importante en el diseño de bases de datos de gestión, que suelen utilizar tecnología relacional, porque ayuda a modelar los datos de la empresa y a representarlos en tablas normalizadas.

En cambio, en sistemas documentales no es tan importante porque éstos no suelen utilizar tecnología relacional, ni necesitan modelar relaciones complejas entre entidades como las que se dan en los sistemas de gestión administrativos.

En muchos sistemas documentales, las entidades, de hecho, no mantienen relaciones entre ellas que deban ser reflejadas en el modelo E-R. Por ejemplo, en una típica base de datos documental sobre bibliografía científica y técnica no suele existir ninguna relación entre las entidades representadas (normalmente artículos de revista y monografías) que deba ser tenida en cuenta en el modelo E-R.

En tales situaciones, el modelo E-R “sólo” aporta una cierta claridad conceptual y proporciona una terminología común a todos los miembros que participan en el diseño. Sin embargo, el propósito de las herramientas de diseño no es tanto proporcionar soluciones para situaciones que son bien conocidas, sino para las no conocidas o menos típicas y, en este sentido, el modelo E-R puede resultar de ayuda también para determinar otros elementos del diseño.

Volvamos al ejemplo anterior, donde se nos pide diseñar una base de datos sobre teatro español. Supongamos que tenemos dudas sobre el siguiente aspecto: no sabemos si considerar que el autor y todos sus datos biográficos son atributos de la obra de teatro, o bien que autor y obras de teatro son entidades distintas.

Si adoptáramos el primer punto de vista, tendríamos que diseñar un único modelo de registro, donde los atributos del autor serían otros tantos campos, junto con los atributos de la obra de teatro. En cambio, si adoptamos el segundo punto de vista, necesitaremos diseñar dos modelos de registro, uno para obras de teatro y otro para autores. Puede ser que la simple intuición nos indique cuál es el camino correcto en este o en otros casos parecidos, pero si queremos estar seguros de no equivocarnos en nuestra decisión, siempre podemos aplicar el siguiente procedimiento:

1. En caso de duda, tratar las cosas como entidades distintas.
2. Determinar la relación entre entidades.
3. Determinar su grado.
4. Aplicar las siguientes reglas:
   a) Si la relación es de grado 1:1, entonces se trata de una sola entidad, y un solo modelo de registro es suficiente para representarla. Por ejemplo, el número de Isbn es, de hecho, un atributo de la entidad libro, y para representarla es suficiente un solo registro, con un atributo que incluya el número de Isbn.
   b) Si la relación es de grado N:1, o N:M, se trata de dos entidades y, por lo tanto, necesitamos dos modelos de registro, uno para cada entidad, y cada uno de ellos debe contar con un campo con un dominio común.

En nuestro ejemplo, la aplicación de esas reglas nos indicaría que la decisión acertada consiste en utilizar dos modelos de registro: uno para representar obras de teatro y otro para representar autores teatrales. El campo con un dominio común podría ser el campo Autor, que debería figurar en ambos registros.

¿Qué sucedería si no procediéramos como indica esta norma? En tal caso, la carga de datos sería poco eficiente, porque para autores muy prolíficos tendríamos que entrar los mismos datos tantas veces como obras de teatro hubiera escrito. En general, si un autor ha escrito n obras de teatro, tendríamos que repetir sus datos n veces.

Además, la redundancia, como es sabido, genera inmediatamente inconsistencias, y tendríamos enseguida, por ejemplo, diversas fechas de nacimiento para un mismo autor. Es evidente que si no detectamos ese error de diseño a tiempo, no tardará en hacerse evidente en algún momento de la fase de carga de datos. Si necesitamos llegar a la implantación para detectar los errores, tal vez entonces se revelarán inútiles meses de trabajo.

Una advertencia final sobre el modelo E-R.

Cuando se utiliza para diseñar bases de datos relacionales, las reglas para tomar decisiones son más complejas, porque la descomposición de datos a la que obliga el modelo relacional implica la necesidad de representar no sólo las entidades, sino también las relaciones entre entidades mediante una tabla más. Los interesados en esos aspectos de diseño pueden consultar G. A. Jackson, 1990 (ver referencia al final) y también el artículo “Bases de datos relacionales: qué son y qué aportan a la gestión de información”, Ll. Codina, IWE-29, noviembre de 1994, pp. 18-19.
https://www.scimagoepi.com/bases-de-datos-relacionales-que-son-y-que-aportan-a-la-gestion-de-la-informacion

7. Modelos canónicos

Por otro lado, no deberíamos olvidar que, en Documentación, la experiencia previa ha dejado bien sentados cuáles son los atributos de algunas entidades e incluso cuál es la forma más conveniente de representarlos. Podemos hablar entonces de situaciones canónicas que han generado un modelo. La mejor herramienta de análisis y de diseño, en tal caso, consiste precisamente en aplicar ese modelo bien conocido y probado.

Por ejemplo, los atributos estructurales de cualquier clase de documento pueden ser adecuadamente modelados siguiendo la norma internacional ISBD (International standard bibliographic description). Recordemos que esa norma internacional representa un gran esfuerzo de abstracción para proporcionar un marco general de descripción, válido para cualquier clase de documento, desde una partitura musical, hasta una filmación audio-visual, pasando por un fichero de ordenador, un fonograma o un artículo de revista, de manera que la ISBD constituye una herramienta de diseño de primera magnitud para cualquier problema documental donde debamos representar documentos.

Sobre el uso de ISBD, cabe advertir que algunos centros de documentación se han sentido intimidados ante la aparente complejidad de la norma y la supuesta obligación de adoptarla como un todo, incluyendo la prolija puntuación que prescribe, y se ha argumentado que utilizar la norma ISBD sólo tiene sentido en el contexto de la lectura pública.

Tal postura es un error porque siempre podemos utilizar la estructura ISBD como una orientación en el análisis de los documentos convencionales así como una fuente de inspiración para situaciones más “exóticas”, independientemente de que incorporemos o no la norma en todos sus detalles, es decir, incluyendo todos los niveles de descripción y todas las prescripciones de puntuación, máxime cuando el hecho de separar zonas mediante campos libera de la necesidad de utilizar la puntuación prescrita.

Además, en caso necesario, el programa documental debería permitir presentar la salida de los datos en formato ISBD (o en cualquier otro formato), desde el momento en que la estructura repetitiva de los registros permite incorporar instrucciones del tipo: “el valor del campo Título se transcribe seguido por un punto, espacio y una raya”, etc.

8. Fase de diseño

El propósito ahora es obtener un Modelo Conceptual de la base de datos y un Modelo de Normativa de Indexación.

El primero contiene los elementos necesarios para orientar el proceso de implantación. El segundo establece criterios y orientaciones sobre el proceso de representación del contenido semántico de los documentos o entidades de los que tratará la base de datos.

Los dos son el resultado de la fase de diseño y deben ser aprobados por quien encargó el proyecto, antes de que puedan servir como guías de implantación. Por tanto, el modelo conceptual no sólo debe ser acertado, sino que, además, debe parecerlo.

El Modelo Conceptual contiene, por lo menos, los siguientes elementos:

1. Definición raíz
2. Definición del dominio de la base de datos.
3. Identificación de las entidades representadas en la base de datos.
4. Diccionario de datos
5. Descripción funcional del sistema.

El dominio de la base de datos es el conjunto de los temas o entidades sobre los que mantiene información la base de datos. Como todo dominio, puede definirse por extensión o por comprensión. Por tanto, puede ser tan breve como el nombre de una o más disciplinas científicas. Por ejemplo, el dominio de la base de datos LISA Plus (Library and Information Science Abstracts) es el de las Ciencias de la Documentación. O puede consistir en una frase. Por ejemplo, el dominio de la base de datos Teseo se enuncia diciendo que está formado por las tesis doctorales publicadas por universidades españolas.

Las herramientas para producir el documento anterior son las siguientes:

1. Definición raíz
2. Modelo entidad-relación (que ya se comentó antes)
3. Diccionario de datos
4. Descripción funcional

La definición raíz expresa qué es la base de datos o, si se quiere, describe la clase de problemas que podrá solucionar. Esta descripción debe mencionar a los usuarios de la base de datos. No debe ser más larga de uno o dos párrafos. La información necesaria para construir la definición raíz se obtuvo del Modelo esencial, que forma parte de la fase de análisis, que vimos en su momento.

Una forma de definición raíz que podría generalizarse para un amplio rango de bases de datos documentales, aplicada por ejemplo al caso de la de un medio de comunicación podría ser:

“El propósito de esta base de datos es satisfacer las necesidades de información retrospectiva de los redactores del diario, permitiéndoles recuperar selectivamente cualquier información publicada anteriormente por el mismo”.

9. Diccionario de datos

Ayuda al diseñador a garantizar la calidad, fiabilidad, consistencia y coherencia de la información introducida en la base de datos, de tal manera que el mismo marcará decisivamente el rendimiento y la calidad global del sistema de información.

Consiste en la lista detallada de cada uno de los campos que forman los distintos modelos de registro de la base de datos. A cada campo de cada modelo de registro se le aplica una parrilla de análisis que contempla, como mínimo, los siguientes aspectos:

1. Dominio
2. Tipo
3. Tratamiento de indexación
4. Tratamiento documental
5. Lengua
6. Otros controles de validación

Supongamos una base de datos documental sobre noticias de actualidad con sólo tres campos: <Título>, <Descriptores> y <Fecha de publicación>. El diccionario de datos tendría esta forma:

• Campo Título

Dominio: Título del documento. Se transcribe de la siguiente forma: Título: antetítulo: subtítulo.
Tipo: Alfanumérico
Tratamiento indexación: Indexado
Tratamiento documental: Lenguaje libre
Lengua: Lengua del documento
Controles de validación: No puede quedar vacío. Si por alguna razón el documento careciera de título, el documentalista asignará un título descriptivo.

• Campo Descriptores

Dominio: Palabras clave normalizadas que expresan los conceptos principales contenidos en el documento, según el siguiente principio general: si el artículo contiene n conceptos relevantes se asignan n descriptores, procurando no asignar más de 20 descriptores por documento.
Tipo: Alfanumérico
Tratamiento indexación: Indexado
Tratamiento documental: Lenguaje controlado
Lengua: Del centro de documentación
Controles de validación: No puede quedar vacío y sólo admite valores extraídos de una lista de términos autorizados.

• Campo fecha de publicación

Dominio: Fecha de publicación de la noticia con el siguiente formato: DD/MM/AAAA.
Tipo: Fecha
Tratamiento indexación: Indexado
Tratamiento documental: No procede
Lengua: No procede
Controles de validación: No admite valores fuera de rango.

Estudiando el diccionario de datos anterior, podemos observar lo siguiente:

1. Que el Dominio es el conjunto del que puede obtener sus valores el campo.
2. Que el Tipo se refiere al tipo de datos que admite el campo. Suele ser:

– Numérico: permite efectuar cálculos aritméticos o búsquedas por rangos de valores.
– Alfanumérico: admite tanto cadenas de caracteres como números, pero trata a estos últimos como caracteres.
– Fechas: sólo admite fechas en un formato establecido y permite búsquedas por rangos o por valores superiores o inferiores a una fecha dada.
– Lógico: sólo admite uno de dos valores: Sí o No; Verdadero o Falso.

3. Que el Tratamiento documental establece si se debe utilizar algún lenguaje documental para entrar los valores del campo, como así sucede en el campo Descriptores, donde el diccionario de datos regula que ese campo sólo admite palabras clave autorizadas extraídas de un tesauro o de una lista de autoridades.
4. Que la Lengua puede ser, o bien la del documento, o bien la del centro de documentación. Eso significa, en el caso de un documento escrito en inglés, que el título estaría en inglés, pero los descriptores en castellano, siempre de acuerdo con el diccionario de datos precedente.

La descripción funcional, por su parte, incluye los siguientes elementos:

1. Qué y cómo entra la información en el sistema.
2. Qué procesos documentales se llevan a cabo.
3. Qué servicios y productos genera el sistema, y/o a qué aplicaciones pueden dar soporte.

En el primer punto se describe en qué consisten las entradas del sistema. El punto segundo da una idea sobre qué procesos de tratamiento documental automatiza la base de datos, y el punto siguiente explica en qué consisten las salidas del sistema.

Por ejemplo, siguiendo con la base de datos de un medio de comunicación (supongamos que se trata de un diario), la descripción funcional podría explicar lo siguiente:

“Diariamente entran en la base de datos las noticias que se publicarán al día siguiente. Esta entrada se realiza mediante una importación automática de los archivos informáticos generados por la redacción.

Los documentalistas revisan las noticias entradas el día anterior, las analizan y asignan descriptores a cada una de ellas, utilizando la lista de descriptores autorizados.

En el caso de las fotografías, redactan un título o copian el pie de foto si resulta adecuado como título y les asignan también los descriptores correspondientes.

Tanto el texto completo de las noticias como la imagen facsímil de las mismas y las fotos quedan archivados en la base de datos, asociados a los descriptores asignados por los documentalistas, que actúan de puntos de acceso a la noticia, junto con el texto completo del documento en el caso de los artículos.

La base de datos puede proporcionar recuperación selectiva de la información por texto completo y por descriptores, así como mostrar y/o imprimir el documento primario en pantalla. Igualmente puede generar listados, con cualquier periodicidad, de artículos publicados sobre un tema o por un periodista determinados, y mostrar estadísticas de uso de términos.

La base de datos podría ser el núcleo para ofrecer un servicio de recuperación de información en línea a clientes externos, distribuirse en cd-rom, o utilizarse para automatizar la publicación de los índices anuales”.

Sobre el modelo de normativa de indexación, únicamente cabe advertir que debe dar indicaciones lo más completas posible sobre la política que se recomienda para los campos controlados: aplicación de las normas ampliamente aceptadas por la comunidad profesional, como p. ej. la norma UNE sobre construcción de tesauros (UNE 50-106-90), así como ofrecer orientaciones sobre su utilización concreta en la base de datos que se ha diseñado.

Por ejemplo, siguiendo el caso anterior, y teniendo en cuenta las características de la documentación periodística, el Modelo de Normativa de Indexación debería proponer una indexación postcoordinada, basada en la utilización de descriptores extraídos de un lenguaje documental controlado que, en su día, puede llegar a ser un tesauro, y para elegir la forma de los descriptores, su nivel de especificidad, etc., se podría recomendar la mecionada norma UNE.

Sobre los extremos relacionados con la descripción documental no nos extenderemos aquí, y tan sólo diremos que tales recomendaciones deben ser tan detalladas como sea posible.

11. Implantación

Una vez aprobado el modelo conceptual de la base de datos, puede procederse a su implantación, la cual suele seguir el siguiente proceso:

1. Selección del sistema informático (software + hardware) que pueda satisfacer los requerimientos del modelo conceptual y del modelo de normativa de indexación. Primera instalación y nombramiento de un administrador de la base de datos que, a partir de ahora, será su máximo responsable.
2. Pruebas con una colección-test de documentos.
3. Cambios o ajustes necesarios.
4. Formación del personal técnico y de los usuarios finales.
5. Edición de la versión 1 del Libro de estilo de la base de datos, que incluye la versión definitiva del modelo conceptual, la normativa de indexación y, en su caso, a modo de anexo, la lista de descriptores autorizados o el tesauro.
6. Acciones de promoción, formación de usuarios finales, etc.

12. Bibliografía

Aenor (1990). Norma UNE 50‑106‑90. Documentación. Directrices para el establecimiento y desarrollo de tesauros monolingües. Madrid: Aenor, 47 pp.

Codina, Lluís (1994). Sistemes d’informació documental: concepció, anàlisi i disseny de sistemes de gestió documental amb microordinadors. Barcelona: Pòrtic, 224 pp.

Jackson, Gleen A. (1990). Introducción al diseño de bases de datos relacionales. Madrid: Anaya, 203 pp.

Van Slype, Georges (1991). Los lenguajes de indización: concepción, construcción y utilización en los sistemas documentales. Madrid: Fundación Germán Sánchez Ruipérez, 198 pp.

Walker, David W. (1991). Sistemas de información basados en ordenador. Barcelona: Marcombo.

Yourdon, Edward (1993). Análisis estructurado moderno. México: Prentice‑Hall Hispanoamericana, 735 pp.

Lluís Codina. Profesor de Documentación. Universitat Pompeu Fabra.
Barcelona.
Tel.: +34-3-542 22 65 / 6
codina_lluis@fcsc.upf.es

—

Esta información se publicó en la revista Information World en Español (IWE), n. 34, mayo de 1995, pp. 9-12.

• Volver al índice de este número 34:
  https://www.scimagoepi.com/information-world-en-espanol-iwe-numero-34-mayo-de-1995

• Volver a la página principal de Information World en Español (IWE):
  https://www.scimagoepi.com/information-world-en-espanol-iwe