WWW EPI

Diciembre 1997

Una propuesta de metodologia para el diseño de bases de datos documentales (Parte II)

Por Lluís Codina

La primera parte de este artículo se publicó en el anterior número de IWE, vol. 6, nº 11, noviembre de 1997, pp. 23-29.

El diccionario de datos

Es una herramienta que ayuda al diseñador de una base de datos a garantizar la calidad, la fiabilidad, la consistencia y la coherencia de la información introducida en la base, de tal manera que el diccionario de datos 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. Indización
4. Tratamiento documental
5. Lengua
6. Otros controles de validación u observaciones
7. Ejemplos válidos

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

Etiqueta: Título
Dominio:
Título del documento. El título se transcribe de la siguiente forma: Título: antetítulo: subtítulo.
Tipo:
Alfanumérico
Indización:
Indizado
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.
Etiqueta: 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
Indización:
Indizado
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.
Etiqueta: Fecha de publicación
Dominio:
La fecha de publicación de la noticia, indicada con el siguiente formato: dd/mm/aaa.
Tipo:

Fecha
Indización:
Indizado
Tratamiento documental :
No procede
Lengua:
No procede
Controles de validación:
No admite valores fuera de rango.

Estudiando el ejemplo anterior, formado únicamente por tres campos, podemos observar cuatro aspectos importantes para el diseño de bases de datos:

1. Que el Dominio, en el contexto del diccionario de datos, se refiere al conjunto del que un campo puede obtener sus valores.
2. Que el Tipo se refiere, en cambio, al tipo de dato que admite el campo. Los tipos de datos suelen ser: numérico, alfanumérico, fechas y lógico.
   
   Recordemos que un tipo de dato (data type) define un conjunto de operaciones válidas y un rango de valores aceptable. Por ejemplo, el tipo de datos "alfanumérico" define operaciones de comparación de cadenas de caracteres, entre otras, así como cualquier letra de la a la z, número del 0 al 9, y combinación de esos caracteres en palabras, frases, párrafos, etc. En cambio, no admite operaciones aritméticas, aunque admita números. Por el contrario, un tipo de dato "numérico" admite sólo números así como cualquier operación aritmética, etc.
   
   Por su parte, un campo de fechas sólo acepta fechas en un formato establecido y permite búsquedas por rangos de fechas o por valores superiores o inferiores a una fecha dada. Un campo lógico sólo admite uno de dos valores: Sí o No; Verdadero o Falso.
3. Que el Tratamiento documental fija 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 establece que ese campo sólo admite palabras clave autorizadas extraídas de un thesaurus o de una lista de autoridades.
4. Que la Lengua puede ser, o bien la lengua 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, debe incluir los siguientes elementos:

1. Qué clase de información se tratará y cómo entrará la información en el sistema.
2. Qué procesos documentales se llevarán a cabo.
3. Qué servicios y productos generará el sistema, y/o a qué aplicaciones podrá dar soporte.

   El primer punto debe describir en qué consisten las entradas del sistema. El punto dos debe proporcionar una idea sobre qué procesos de tratamiento documental automatiza la base de datos, y el punto siguiente debe explicar en qué consisten las salidas del sistema.

La Isbd y los 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 testeado.

Por ejemplo, los atributos estructurales de cualquier clase de documento pueden ser adecuadamente modelados siguiendo la norma internacional Isbd. Recordemos que esa norma 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 archivo de ordenador, un fonograma o un artículo de revista, de manera que las Isbd constituyen una herramienta de diseño de primera magnitud para cualquier problema documental donde debamos representar documentos.

Sobre el uso de las 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, en tal sentido, se ha argumentado que utilizar la norma Isbd sólo tiene sentido en el contexto de la lectura pública.

Entiendo que tal postura es un error: primero, porque siempre podemos utilizar la estructura de las 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 toda su complejidad, es decir, incluyendo decir 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.

Aparato procedimental

El principio general de diseño de sistemas de información indica que todo proyecto comienza siempre por un diseño lógico y que, una vez aprobado éste, se procede al diseño físico o implantación, en un proceso que es tan circular como lineal, ya que la fase de diseño, por ejemplo, puede obligar a repensar aspectos de la fase de análisis.

El aspecto importante aquí es que la metodología nos dice claramente que el proceso de creación de una base de datos debe ir siempre desde los aspectos lógicos hacia los aspectos físicos, y no al revés, como, sin embargo, suele suceder, ya que, en la práctica, existen muchas formas de violar ese principio general a causa de malos hábitos de trabajo.

Otra manera de enfocar incorrectamente este proceso consiste en querer abordar directamente el diseño del sistema de información e incluso en querer visualizarlo por completo en nuestra mente, sin saber antes nada del sistema objeto.

El resultado, claro está, será una visión caótica. Todas las interrogantes se agolparán en nuestra mente y seremos incapaces de despejar una sola de ellas.

Lo correcto en ambos casos es comenzar a diseñar los aspectos lógicos (nivel conceptual) ignorando de momento los aspectos físicos; así como comenzar por analizar el sistema objeto, y sólo después de conocerlo bien podemos iniciar el diseño del sistema de información.

Así pues, el proceso de diseño de un sistema de información debe ajustarse siempre al siguiente ciclo de vida que, por otro lado, es universal para todo sistema de información:

1. Análisis
2. Diseño
3. Implantación

Otra forma de enfocar el ciclo de vida de un proyecto de desarrollo es indicar que la dirección del diseño debe proceder de lo conocido a lo desconocido, y no al revés, como sucede cuando se desea visualizar el sistema de información antes de conocer el sistema de actividades humanas y el sistema de conocimiento.

Finalmente, y por la misma razón, la dirección del diseño debe ir de lo general a lo específico y de los aspectos lógicos a los aspectos físicos, y nunca al revés, es decir, nunca se debe empezar a discutir o a considerar cuestiones concretas (¿cómo se imprimirá la información?) o físicas (¿qué tamaño tendrán las estanterías de los documentos?) antes de plantear las cuestiones generales (¿cuál es el propósito de la base de datos?) o lógicas (¿qué entidades formarán parte de la base de datos?). El cuadro sinóptico de la figura 3 sintetiza estas ideas.

En cuanto, al ciclo de vida, cada una de las tres fases enunciadas antes (Análisis, Diseño, Implantación) puede dividirse en cuantas subfases sean necesarias según el proyecto concreto y la clase de sistema que se está diseñando.

En el caso de una base de datos documental, las dos primeras fases se pueden subdividir en otras dos subfases (a y b). Las fases de implantación pueden subdividirse en cuatro subfases (a, b, c, d, e). Nuevamente debe indicarse que tales divisiones tienen siempre algo de arbitrario. Aquí se hace una propuesta concreta, pero pueden ser válidas otras formas de dividir el ciclo de vida. En concreto, en esta metodología se propone la división de fases del cuadro sinóptico de la figura 4.

Aunque expresado en fases enumeradas secuencialmente el proceso parece estrictamente lineal, en realidad, el proceso de diseño también tiene mucho de circular, porque aunque siempre se empieza por la fase de análisis y se sigue con la de diseño, llegados a la fase 2b, por ejemplo, es posible que el diseñador desee considerar de nuevo algunos aspectos de 2a, o que necesite aclarar mejor algunas cuestiones de 1b, etc., idea que recoge la figura 5.

En este sentido, debe hacerse notar que la metodología no excluye totalmente el procedimiento del ensayo y error, como ya se advirtió, sino que lo integra como un modo natural de refinar el producto.

En particular, es prácticamente imposible producir un modelo conceptual correcto en el primer intento, y la experiencia indica que lo más probable es que el modelo elaborado en los puntos 2a y 2b haya que rehacerlo más de una vez, por lo menos en alguno de sus aspectos, principalmente a la vista de las primeras pruebas de rendimiento (3c).

Naturalmente, tiene que llegar un momento en el cual el diseñador dé por finalizado el proceso, pero la cuestión de cuántas veces conviene iterarlo antes de darlo por bueno no puede establecerse a priori, sino que, antes bien, es una cuestión sensible al contexto y que debe decidir el diseñador en cada situación.

En todo caso es importante que se llegue a la fase de implantación con un modelo lo más sólido posible porque a partir de tal fase ya no resulta tan fácil reconsiderar el proyecto, por lo menos no sin pagar algún precio, de manera que el punto 3c debería considerarse el punto de despegue, de alguna manera el punto de no retorno del proyecto.

La fase de implantación puede llevarla a cabo un equipo distinto del que hizo el diseño. De hecho, en algunas empresas, sobre todo en empresas medianas y grandes, puede ocurrir que la fase de implantación corra a cargo del departamento de informática, aunque el análisis y el diseño lo haya hecho el de documentación. En empresas pequeñas, lo más habitual es que todo el proceso lo ejecute un mismo equipo o una misma persona.

Cada una de las fases precedentes (Análisis, Diseño, Implantación) tiene unos objetivos, debe producir unos resultados concretos y utilizar unas herramientas determinadas.

La fase de análisis

El objetivo de esta fase es conocer bien aquella parte del mundo real, llamada sistema objeto, que justifica y requiere la creación del sistema de información, de una base de datos en este caso.

Como ya vimos anteriormente, a efectos de análisis, el sistema objeto se considera dividido en:

• Un sistema de actividades humanas (SAH)
• Un sistema de conocimientos (SCO).

Por lo tanto, y dado que las características del sistema de actividades humanas (SAH) determinarán las características de la base de datos, deberá conocerse lo mejor posible antes de iniciar cualquier actividad de diseño.

El resultado que debe producir esta fase de análisis es una descripción textual que puede incluir gráficos de ser necesario, sobre el SAH, que suele denominarse Modelo Esencial, y que debe incluir, como mínimo, los siguientes aspectos:

1. Propósito y objetivos
2. Actores principales
3. Actividades más relevantes
4. Entorno

La herramienta principal aquí es la realización de entrevistas con representantes del SAH y el análisis de cualquier documentación, del y sobre el SAH, que pueda aportar una comprensión global del sistema. Entre tales documentos podemos citar organigramas, documentos fundacionales, memorias, etc.

Aunque el Modelo Esencial consiste básicamente en una descripción textual, puede incluir, si el documentalista lo considera necesario, diagramas o gráficos que faciliten su comprensión.

El Modelo Esencial no debe ser muy extenso sino, que tal como indica su nombre, debe consistir únicamente en una descripción que recoja los aspectos esenciales de la naturaleza y de las actividades del SAH. Además, como una base de datos documental no persigue el modelado de esas actividades, probablemente cinco o seis párrafos deberían ser suficientes para aportar el conocimiento necesario para los objetivos perseguidos.

Este modelo podrá formar parte del producto final, pero no es necesario que sea así, ya que principalmente su misión es asegurarse de que el responsable del proyecto y otros actores que intervengan en él tienen una adecuada concepción de la naturaleza del SAH.

Por su parte, el propósito de la fase del análisis del sistema de conocimiento consiste en conocer el componente clave en este caso del sistema objeto, a saber, los documentos o las cosas sobre las cuales la base de datos deberá recoger información.

El resultado de esta fase debe consistir en la identificación clara y sin ambigüedades de los documentos o las cosas (entidades) sobre las cuales la base de datos deberá mantener información. Además debe poner de manifiesto las propiedades más relevantes de esas entidades.

La herramienta más adecuada para esta fase es el modelo entidad-relación (modelo E-R), un modelo bastante intuitivo que, sin embargo, resulta de gran utilidad para enfocar este tipo de análisis.

La fase de diseño

El propósito de la fase de diseño es obtener un Modelo conceptual de la base de datos y una Propuesta de tratamiento documental. El primero contiene los elementos necesarios para orientar el proceso de implantación. El segundo establece criterios y orientaciones sobre el proceso de descripción y de representación del contenido semántico de los documentos o entidades de los que tratará la base de datos.

Los dos modelos mencionados 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 debe contener, por lo menos, los siguientes elementos:

1. Definición raíz, que es una definición, al estilo del modelo esencial, que describa los aspectos más importantes del SAH y del SC, aunque sin necesidad de entrar en detalles, mencionando el propósito de la base de datos y a los usuarios del sistema.
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 son 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, entre otras, las siguientes:

1. La definición raíz.
2. El modelo entidad-relación.
3. El diccionario de datos.

La definición raíz expresa qué es la base de datos o, si se quiere, expresa la clase de problemas que podrá solucionar y a qué categoría de usuarios dará servicio. Esta descripción debe mencionar a los usuarios de la base de datos. No debe ser más larga de tres o cuatro 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 y que vimos en su momento.

Un ejemplo sencillo podría ser la definición raíz de la base de datos documental de un medio de comunicación, podría adoptar la siguiente forma: "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 diario".

Al igual que en la identificación del dominio de la base de datos, elaborar la definición raíz puede ser una tarea fácil e intuitiva, resultado de un mero análisis técnico, o bien puede ser producto de una refinada decisión política. Lo que es importante es que, sea cual sea el proceso de decisión, ésta quede documentada y expresa, y formalmente detallada por escrito.

La fase de 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. Se selecciona el sistema informático (software + hardware) que pueda satisfacer mejor los requerimientos del modelo conceptual y del modelo de normativa de indización. De ser necesario, se examinarán varios programas candidatos hasta que exista una razonable certeza de que el programa elegido se ajusta bien a los requerimientos del modelo conceptual. Se realiza la primera instalación y se nombra a un administrador de la base de datos que, a partir de ahora, será el máximo responsable de ella.
2. Se realizan pruebas con una colección-test de documentos o de entidades a ser representadas para comprobar la consistencia de los modelos y esquemas de registros.
3. Se realizan los cambios o ajustes necesarios, hasta obtener el modelo final.
4. Definición de una política de mantenimiento y explotación.
5. Se edita la versión 1 del Libro de estilo de la base de datos, que incluye:
   1. La versión definitiva del modelo conceptual.
   2. La normativa de tratamiento documental, en su caso.
6. Se procede a la formación del personal técnico y de los usuarios finales.
7. Acciones de promoción, en su caso.

Conclusiones

El valor de esta metodología radica, como ya se dijo al principio, en que ayuda a que el producto final sea más resultado del diseño consciente que de las fuerzas ciegas del azar y/o del ensayo y error, pero, particularmente entendemos que su utilidad aumenta conforme se aplica a situaciones poco canónicas o a situaciones atípicas, como las que el entorno cambiante de nuestra profesión introduce en cada momento y, al parecer, tal como el nuevo horizonte de las autopistas de la información y de un futuro mundo digital parece prometer.

Esperamos que, entonces, la aplicación de esta clase de metodologías sirva para que los profesionales de nuestro campo puedan demostrar los beneficios de una adecuada formación académica, del trabajo bien realizado y de la planificación, porque en nuestro campo de actividades también es rigurosamente cierto que el éxito se debe invariablemente a "un diez por ciento de inspiración y un noventa por ciento de transpiración".

Bibliografía básica

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

Baiget, T. (1986). Análisis de sistemas de información. (Apuntes de curso). Barcelona: Institut Català de Tecnologia, 1986, 64 p.

Checkland, P. B. (1981). Systems thinking, systems practice. Chichester: Wiley, 1981.

Checkland, P. B. ; Scholes, J. (1990). Soft systems methodology in action. Chichester: Wiley , 1990.

Chen, P. P‑S. (1976). "The entity‑relationship model: towards a unified view of data". ACM transactions on databases systems, v. 1, n.1, 1976, p. 9‑36.

Codina, L. (1994a). Sistemes d'informació documental: concepció, anàlisi i disseny de sistemes de gestió documental amb microordinadors. Barcelona: Pòrtic, 1994, 224 p.

Codina, L. (1994b). "Modelo conceptual de un sistema de información documental". Revista española de documentación científica, v. 17, n. 4, octubre‑diciembre 1994, p. 440‑449.

Codina, L. (1995). "Metodología de creación de bases de datos documentales". Partes I y II. Information world en español, n. 33, abril 1995, p. 10‑11; n. 34, mayo 1995, p. 9‑12.

Currás, E. (1988). La información en sus nuevos aspectos. Madrid: Paraninfo, 1988, 307 p.

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

Lewis, P. (1994). Information systems development. London: Pitman, 1994, 260 p.

Underwood, P. G. (1996). Soft Systems Analysis and the management of libraries, information services and resource centres. London: Library Association, 1996, 198 p.

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, 1991, 198 p.

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

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

Este artículo es una versión adaptada de la conferencia del autor con motivo de su participación en Ibersid'96: I Encuentro sobre sistemas de información y documentación. Zaragoza. Facultad de Filosofía y Letras. Área de Biblioteconomía y Documentación. 1996.

Ll. Codina.

codina_lluis ARROBA fcsc.upf.es

Enlace del artículo:
http://www.elprofesionaldelainformacion.com/contenidos/1997/diciembre/una_propuesta_de_metodologia_para_el_diseo_de_bases_de_datos_documentales_parte_ii.html