El profesional de la información


Noviembre 1997

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

Por Lluís Codina

En el contexto de los sistemas de información, el término metodologías suele generar equívocos a menudo. Es frecuente que los lectores esperen de ellas cosas que, en realidad, no pueden dar. En concreto, suelen esperar lo mismo que proporcionan, por ejemplo, los algoritmos en matemáticas, es decir, una solución segura a un problema bien planteado.

Por desgracia, en el desarrollo de sistemas de información no existe nada parecido ni a los algoritmos ni a las recetas de cocina. ¿Para qué sirve entonces una metodología en este contexto? La experiencia dice que una metodología sirve, exactamente, para que el resultado final se deba en lo más posible a la planificación consciente y, en lo menos posible, al azar o al método de ensayo y error. Nada más, pero nada menos.

Figura 1: Un registro representando a un libro

No parece necesario insistir mucho en que, mediante la planificación consciente, un profesional tiene derecho a esperar un grado de éxito mucho mayor que si toma las decisiones al azar o por el método del ensayo y error. Por contra, por muy correcta que sea una metodología, un lego no hará nada bueno con ella.

Por tanto, permítame el lector insistir en que la diferencia entre utilizar una metodología o no utilizarla está en qué proporción la parte final del producto puede atribuirse:

  1. al azar
  2. al ensayo y error
  3. a la planificación consciente.

De ello se desprende que siempre se desliza algo de azar en el diseño de sistemas de información, así como siempre existe la necesidad de recurrir al ensayo y error para refinar el resultado final. La cuestión clave radica en que la parte de planificación consciente debe ser la que tenga mayor influencia en el resultado final, tanto por razones de eficiencia como por razones de economía.

Lo contrario, que el azar y el ensayo y error tengan un gran peso, sólo puede producir sistemas desastrosos, principalmente porque si éstos están mal diseñados e ineficientes son mucho más probables -porque hay un número virtualmente infinito de hacer mal cualquier cosa- que los bien diseñados y eficientes. Y siempre que dejamos algo al mero azar sucede lo más probable. Esto no es más que una forma un poco más fisicalista de enunciar la conocida Ley de Murphy.

Por otro lado, es también habitual que las metodologías suenen como un mero puñado de consejos de sentido común, lo cual induce a algunos a un peligroso menosprecio hacia ellas. El problema radica en que, si bien muchos aspectos de las metodologías parecen de sentido común, su contrario también lo parece. Así pues, con una metodología, por lo menos sabemos cuáles de las muchas cosas que parecen razonables son probablemente razonables. Pongamos un ejemplo. Supongamos que alguien afirma, muy serio, que el mejor procedimiento para diseñar una base de datos es escoger un buen equipo informático, después elegir un programa que sea compatible con el mismo y, a continuación, diseñar la base de datos.

No sé que les parece a ustedes, pero yo sé de mucha gente a la cual el consejo le ha parecido tan adecuado que lo han llevado a la práctica con resultados, por supuesto, bastante lamentables. No les hubiera sucedido así si hubieran conocido una de las cosas más básicas del diseño de sistemas de información que aconseja comenzar siempre un proyecto estudiando los aspectos lógicos y no los físicos, o comenzar por la fase de análisis y no por la de implantación, etc. Sin embargo, cuando se explica esa clase de principios en un aula, invariablemente, todo el mundo cree que está recibiendo un mensaje de sentido común.

Qué es una metodología

Por otro lado, unas meras reflexiones o unos consejos no son, a pesar de todo, una auténtica metodología. ¿Qué cosas forman parte, por tanto, de una auténtica metodología? Entendemos que, en sistemas de información, toda metodología debe contemplar, como mínimo, tres elementos o tres grupos de elementos, que aquí llamaremos aparatos:

  1. Aparato conceptual.
  2. Aparato instrumental.
  3. Aparato procedimental.

El primer aparato, o grupo de elementos conceptuales, tiene la misión de proporcionar a los responsables de desarrollo de sistemas de información unas bases conceptuales mínimas que faciliten su entendimiento de todo el proyecto y que faciliten, así mismo, la comunicación entre los diferentes actores involucrados en el proceso. En el aparato conceptual se definen las entidades básicas que intervienen en el proyecto y se proporcionan puntos de vista estratégicos.

El aparato instrumental es el responsable de proveer los instrumentos de análisis y de diseño, es decir, es aquella parte de la metodología que, precisamente, a veces se ha confundido, incorrectamente, con un algoritmo.

Figura 3: Diagrama entidad-relación de las entidades <autores de teatro> y <obras de teatro>

Finalmente, el aparato procedimental establece las fases y los procedimientos básicos, señalando sus objetivos, así como identifica y describe los productos que deben obtenerse de cada fase de análisis, incluido el producto final.

Así pues, y de acuerdo con lo expuesto, se describirá aquí una metodología de desarrollo de bases de datos documentales que no es un algoritmo, es decir, que no libera, mágicamente, de la obligación de tener una buena formación para poder aplicarla con éxito, pero que ayuda a reducir al mínimo posible los riesgos debidos a la improvisación.

Por otro lado, importa señalar que la metodología que se expone aquí se ha obtenido, básicamente, por la utilización de tres tradiciones científicas y académicas distintas, que este autor ha intentado fusionar en una metodología unificada y, hasta cierto punto, consistente. Se trata de las siguientes tradiciones académicas y/o tecnológicas:

  1. La tradición del análisis de sistemas, proveniente de las ciencias informáticas. Unos de los autores más representativos y cualificados sería Yourdon (1993).
  2. La tradición de la teoría de sistemas y de la metodología general de resolución de problemas. Concretamente, se ha utilizado la teoría general de sistemas adaptada a problemas de información (Baiget, 1986; Currás, 1988) y aportaciones de la SSM (Soft System Metodology), una metodología elaborada principalmente, pero no únicamente, por Checkland (1981; Checkland y Scholes, 1990; Lewis, 1994, Underwood, 1996).
  3. La tradición, naturalmente, de los métodos y procedimientos de trabajo de las ciencias de la documentación.

Una vez expuestas estas consideraciones de tipo meta-metodológicas, se presentan en las secciones siguientes los elementos de una metodología que, a su vez, tiene sus fundamentos teóricos en un modelo conceptual sobre sistemas de información documental expuesto con más detalle en otro lugar (Codina, 1994a y Codina 1994b).

Aparato conceptual

Un primer punto de partida muy útil en el diseño de todo sistema de información y, por tanto, también en el diseño de una base de datos documental, consiste en definir un sistema de información como un sistema, S1, denominado sistema de información, que mantiene registros sobre otro sistema del mundo real, S2, denominado sistema objeto.

De este modo, el proceso de análisis y diseño puede concebirse como el intento de obtener un modelo de aquella parte de la realidad, o sistema objeto (S2), que resulta de interés para el sistema de información (S1). Tenemos entonces el par conceptual <sistema de información, sistema objeto>, o <S1, S2>, y la relación que les une es que el primero (S1) es un modelo del segundo (S2), exactamente en el mismo sentido en que un mapa será un buen sistema de información justo en la medida en que sea un buen modelo del territorio sobre el que informa.

El segundo punto de partida consiste en considerar que, desde el punto de vista de los intereses de la Documentación, todo sistema objeto (S2) se compone de dos subsistemas, que denominamos:

  1. Sistema de actividades humanas (SAH).
  2. Sistema de conocimiento (SCO).

El SAH es el sistema social -es decir un sistema formado por personas y cosas- que justifica la existencia del sistema de información, porque en él desarrollan sus actividades los futuros usuarios que necesitarán que exista un sistema de información.

Por ejemplo, si pensamos en una biblioteca universitaria como en un sistema de información, entonces el sistema objeto que modela (y por tanto, el SAH) es la universidad, la cual necesita a la biblioteca (así como otros recursos documentales) para sus actividades de creación y difusión del conocimiento. ¿En qué sentido la biblioteca modela a la universidad? En el sentido en que los temas y disciplinas científicas que cubre la biblioteca, la clase de documentos que adquiere, los procedimientos de trabajo, los servicios que presta, etc., son un reflejo de las características de la universidad.

Si consideramos la base de datos que automatiza el centro de documentación de una empresa determinada, este centro de documentación es el SAH respecto a la base de datos, y la propia empresa es otro SAH que, en este caso, actúa de entorno del centro de documentación. Como el entorno de un sistema siempre influye en él de alguna forma, los diseñadores de la base de datos, aunque deberán concentrarse en las características del centro de documentación, también deberán conocer las características de su entorno, esto es, de la empresa. Los ejemplos podrían multiplicarse fácilmente. Por ejemplo, si se trata de diseñar la base de datos de un museo, el SAH será el museo en cuestión, etc.

Por su parte, el sistema de conocimiento (SCO) está formado por los documentos o las entidades sobre los cuales el sistema de información debe mantener algún tipo de registros.

Por ejemplo, muchos profesionales de distintas ramas de la actividad económica y social necesitan explotar el conocimiento contenido en los documentos científicos y técnicos que se publican a diario en todo el mundo para desempeñar su trabajo. Por eso, los centros de documentación realizan, entre otras labores, una descripción de sus fondos documentales y una labor de representación del conocimiento que contienen esos fondos, que en cada caso serán distintos.

En el caso de la base de datos de un museo, por seguir con otro de los ejemplos mencionados, el SCO consistirá, según decisión de los analistas, o bien en los objetos expuestos en el museo, o bien en los documentos de su centro de documentación o en ambos. En todo caso, este ejemplo nos demuestra que a veces determinar qué forma parte del SCO puede ser una decisión técnica e incluso intuitiva, fruto de un análisis superficial, pero otras veces será el resultado de una decisión política más o menos elaborada.

Con los dos principios fundamentales anteriores se dispone ya de un mínimo aparato conceptual que permite iniciar la discusión de los otros elementos de la metodología. Se observará que algunas herramientas del aparato instrumental, tal como el modelo entidad-relación (que se explica más adelante), incluyen también aspectos conceptuales. En realidad, es en buena parte arbitrario decidir qué elementos pertenecen al aparato conceptual y qué elementos pertenecen al procedural o al instrumental. Aquí se ha hecho una elección concreta, pero probablemente son posibles otras interpretaciones.

Aparato instrumental

El aparato instrumental de una metodología proporciona los instrumentos de análisis que puede utilizar el analista. En concreto, tres son los instrumentos principales que se pueden emplear: el modelo entidad-relación, desarrollado originalmente por Chen (1976), el diccionario de datos y la norma Isbd.

Modelo entidad-relación

El modelo entidad-relación (o modelo E-R) ayuda a detectar sin ambigüedades las entidades que formarán parte de la base de datos, es decir, los objetos que forman parte del sistema de conocimiento. Estas entidades son las que habrán de ser descritas en la base de datos e importa, por tanto, identificarlas con la mayor precisión posible.

Además, el modelo E-R proporciona una terminología adecuada para las primeras fases de diseño y un método para discriminar entre entidad y atributo de entidad, cosa que a veces puede resultar trivial pero que en otras ocasiones no lo es en absoluto. El modelo E-R utiliza los siguientes conceptos:

  • Entidad
  • Atributo
  • Relación

Según este modelo, si las bases de datos representan a cosas u objetos del mundo real, tales cosas deben ser identificables y deben tener algunas propiedades. A las cosas sobre las cuales almacena información una base de datos se las denomina entidades, y pueden ser cosas materiales (libros, personas, etc.) o conceptuales (ideas, teorías científicas, etc.).

La única restricción aplicable es que las entidades que han de estar representadas en una base de datos deben ser identificables y, por tanto, debe ser posible señalar a una cualquiera de ellas sin ambigüedad.

Los atributos, por su parte, son las propiedades relevantes que caracterizan a una entidad. En este sentido, el término relevantes significa lo siguiente: relevantes para el problema de información que se está considerando. Teniendo en cuenta que, en principio, los atributos de una entidad son virtualmente ilimitados, será labor del documentalista seleccionar en cada caso cuáles son los que se consideran más relevantes.

El modelo distingue entre tipo de entidad y ocurrencia de entidad. Un tipo de entidad define un conjunto de entidades constituidas por datos del mismo tipo, mientras que una ocurrencia de entidad es una entidad determinada y concreta. Cuando se diseña una base de datos el objetivo del documentalista debe consistir en definir un tipo de entidad, que obtiene estudiando ocurrencias concretas de entidades.

Un registro es una representación de una entidad en la base de datos y, por lo tanto, cada registro describe a una entidad. Por ejemplo, en una base de datos bibliográfica, cada documento se describe en un registro.

Por tanto, si los registros describen entidades del mundo real, los campos corresponden a los atributos de la entidad. De este modo, si un tipo de entidad posee los atributos A, B, C, el modelo de registro debe poseer los campos A, B, C.

En este punto, necesitamos diferenciar entre los siguientes conceptos:

  1. Etiqueta del campo
  2. Valor del campo
  3. Dominio del campo
  4. La etiqueta es el nombre del campo, es decir, una constante que identifica una zona del registro. El valor se refiere al contenido concreto de un campo concreto y puede ser distinto para cada campo de cada registro. El dominio, por su parte, es el conjunto del cual puede tomar sus valores un campo. Por ejemplo, el dominio del campo Año de publicación es el conjunto formado por los años de publicación de documentos.

    Veámoslo con otro ejemplo. De acuerdo con el registro de la figura 1, el segundo campo o zona de información se puede analizar así:

    • Nombre del campo: Autor
    • Valor del campo: Harley Hahn; Rick Stout
    • Dominio del campo: El conjunto de los nombre de responsables intelectuales de los documentos.

    Generalizaciones y abstracciones

    Al igual que distinguimos ente tipo y ocurrencia de entidad, debemos diferenciar también entre modelo de registro y ocurrencia de registro. Un tipo de entidad se forma por abstracción y/o generalización. Abstracción o generalización significa que se ignoran ciertos aspectos distintos de diversas ocurrencias de entidad, y se forma con todas ellas un tipo unitario, o que se generalizan a todas las entidades ciertos rasgos que presentan regularmente ciertas entidades.

    Por ejemplo, supongamos que aplicando el modelo E-R a un problema de información (por ejemplo, una base de datos para automatizar el archivo de un medio de comunicación), nos muestra como primer resultado los siguientes tipos de entidades:

    1. Artículos de revistas
    2. Artículos de prensa diaria
    3. Capítulos de libros
    4. Libros
    5. Informes
    6. Fotografías de personajes
    7. Fotografías de sucesos
    8. Fotografías de estudio
    9. Infografías
    10. Una simple generalización reduce los nueve tipos de entidades a dos, puesto que las entidades 1 a 5 pueden reducirse, por abstracción, a una sola: Documentos escritos, y los tipos de entidades 5 a 9 al tipo de entidad: Documentos gráficos. La entidad Documentos escritos deberá tener un atributo denominado Tipo de documento, que permitirá describir qué clase de documento es: artículo, libro, etc. Por su parte, la entidad Documentos gráficos deberá tener también un campo denominado Tipo de documento, que permitirá indicar si es una fotografía de personas, fotografía de paisajes, o si es una infografía, etc.

      Relaciones

      Las entidades del mundo real pueden tener relaciones entre ellas y, mientras 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 revelarí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].

      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). Una manera típica de representar estas relaciones y su grado es utilizando diagramas y expresiones textuales. En estos diagramas, las entidades se representan como rectángulos y las relaciones como rombos. A su vez, las entidades se identifican con sustantivos y las relaciones con verbos. En la figura 3 podemos ver un ejemplo de talesdiagramas.

      Así, por ejemplo, la relación que existe entre el número de Isbn y un libro es una relación de 1:1 (que se lee "relación de uno a uno") 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, (“de uno a muchos”) porque cada profesor pertenece a una sola universidad, y una universidad tiene muchos profesores.

      Finalmente, una relación de N:M (“de muchos a muchos”) seria 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 ese es el significado de las letras N y M que hemos puesto en el diagrama de la figura 3.

      Además, la participación de la entidad puede o no ser obligatoria, lo cual significa que una entidad obligatoria interviene siempre 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 bases de datos documental sobre literatura científica y técnica no suele existir ninguna relación entre las entidades representadas (típicamente artículos de revista y monografías) que deba ser tenida en cuenta en el modelo E-R.

      El modelo E-R aporta una importante 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 situaciones 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.

      Por ejemplo, y volviendo al caso 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 si considerar que autor y obras de teatro son entidades distintas, como hemos dado por supuesto en el diagrama.

      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 no 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. Si la relación es de grado 1:1, entonces se trata de una sola entidad 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.
      5. 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 esa regla 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. 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, pero no debería ser menos evidente que si podemos evitar el error en la fase de diseño estaremos trabajando con mucha mejor calidad (ahora que está tan de moda este tema) que si necesitamos llegar a la implantación para detectar los errores, tal vez después de meses de trabajo que, de golpe, se revelarán inútiles.

      Una advertencia final sobre el modelo E-R. Primero, 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 Jackson (1990).

      En general, la tecnología relacional debería ser necesaria cuando se trata sobre todo de modelar actividades (relaciones), y los datos relativos a cada entidad son relativamente simples o están muy estructurados. La mayoría de las actividades de gestión administrativa de una empresa son de esa clase y por eso utilizan sistemas relacionales. En cambio, deberíamos utilizar sistemas documentales en la situación simétricamente opuesta a la anterior, es decir, cuando se trata de modelar depósitos de conocimiento más que actividades, y los datos no son en realidad datos, sino información no estructurada o extremadamente compleja. La mayoría de las actividades de la Documentación responden a ese perfil y por eso utilizan sistemas documentales.

      (Continuará en el próximo número de IWE)

      Enlace del artículo:
      http://www.elprofesionaldelainformacion.com/contenidos/1997/noviembre/una_propuesta_de_metodologia_para_el_diseo_de_bases_de_datos_documentales_parte_i.html