El profesional de la información


Abril 1995

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

Por Lluís Codina

Conceptos fundamentales

Lluís CodinaUn 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 algo que mantiene registros sobre otro conjunto del mundo real 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 (sistema objeto) que resulta de interés para el sistema de información. Tenemos entonces el par conceptual <sistema de información, sistema objeto>, y la relación que les une es que el primero es un modelo del segundo, 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 es considerar que, desde el punto de vista de los intereses de la Documentación, todo sistema objeto se compone de dos subsistemas, que denominamos:

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

El SAH es el sistema social -es decir, 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 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 modelar las características del centro de documentación, también deberán conocer las características de su entorno, esto es, de la empresa.

Por su parte, el sistema de conocimiento (SIC) 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.

Ciclo de vida

El principio general de diseño de sistemas de información indica que el proceso comienza siempre por un diseño lógico o conceptual y que, una vez aprobado éste, se procede a su implantación, en un proceso que es más circular que lineal, ya que la implantación puede obligar a repensar aspectos del diseño.

De este modo, 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 (adquiriendo primero el programa y el ordenador y diseñando después la base de datos, pensando en la forma y el tamaño de las estanterías y diseñando después el sistema, etc.).

Otra manera de enfocar incorrectamente este proceso consiste en abordar directamente el diseño del sistema de información e incluso pretender visualizarlo por completo en nuestra mente, sin saber antes nada del sistema objeto. El resultado, claro está, será una visión caótica. Todos los interrogantes se agolparán en nuestra mente y seremos incapaces de despejar uno solo de ellos.

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

Así pues, el proceso de diseño de un sistema de información se ajustará siempre al siguiente ciclo de vida:

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

Cada una de las tres fases precedentes 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 restantes fases, de implantación, pueden subdividirse en cuatro subfases (a, b, c, d, e):

  1. Análisis
    1. Del sistema de actividades humanas
    2. Del sistema de conocimiento
  2. Diseño
    1. Del modelo conceptual
    2. Determinación de procedimientos de indexación
  3. Implantación
    1. Selección del soporte informático (software y hardware)
    2. Pruebas de rendimiento.
    3. Elaboración del libro de estilo de la base de datos.
    4. Formación de usuarios
    5. Promoción, etc.

El proceso de diseño es circular, porque llegados a la fase 2b, por ejemplo, es posible que el diseñador desee considerar de nuevo aspectos de 2a, o que necesite aclarar mejor algunas cuestiones de 1b, etc.

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 caso.

Después del diseño, el ciclo de vida del sistema nos indica que debe procederse a su implantación, es decir, a tratar los aspectos físicos de la cuestión, y por tanto, aquí es donde entra a considerarse qué tipo de sistema informático puede satisfacer los requerimientos del diseño conceptual.

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 las fases de diseño y de análisis las realice el departamento de documentación, mientras que todos los aspectos de implantación corran a cargo del departamento de informática.

Este reparto de tareas parece el más conveniente para todas las partes, ya que sólo el departamento de informática tiene una visión global de la arquitectura informática de la empresa, y sólo el departamento de informática posee la competencia técnica y las atribuciones que le permiten tomar decisiones que afectan a esa infraestructura corporativa.

Sin embargo, lo que nunca es conveniente es que el proceso de análisis y de diseño se sustraiga del departamento de documentación, que es el único que tiene competencia técnica en los aspectos lógicos de esa clase de sistemas, exactamente por la misma razón que el diseño de una biblioteca lo debe desarrollar un experto en biblioteconomía, aunque su automatización la lleve a cabo el departamento de informática; el sistema contable, un experto en contabilidad, aunque lo automatice el departamento de informática, etc.

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, extremos que serán discutidos seguidamente.

Fase de análisis

Su objetivo es conocer bien la parte del mundo real, llamada sistema objeto, que justifica la creación del sistema de información y que, como ya se ha dicho, se considera dividido en un sistema de actividades humanas (SAH) y un sistema de conocimientos (SIC).

Por lo tanto, y dado que sus características determinarán las de la base de datos, el SAH deberá conocerse lo mejor posible antes de iniciar cualquier actividad de diseño.

El resultado de esta fase de análisis es una descripción sobre el SAH, que suele denominarse Modelo Esencial, y que incluye, como mínimo, los siguientes aspectos:

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

La herramienta principal aquí son las 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 analista lo considera necesario, diagramas o gráficos que faciliten su comprensión.

No hace falta que sea muy extenso, sino que, tal como indica su nombre, consiste ú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 pueden ser suficientes para aportar el conocimiento necesario para los objetivos perseguidos.

Análisis del sistema de conocimiento

El propósito de esta fase es conocer el segundo componente del sistema objeto que determinará las características de la base de datos, a saber, los documentos o las cosas sobre las cuales la base de datos deberá recoger información y que denominamos sistema de conocimiento.

El resultado es la identificación clara y sin ambigüedades de los documentos o las cosas sobre las cuales la base de datos mantendrá información, así como 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), bastante intuitivo y que resulta de gran utilidad para enfocar este tipo de análisis.

El modelo E-R utiliza los siguientes conceptos:

  • Entidad
  • Atributo
  • Relación

Según ello, si las bases de datos representan cosas u objetos del mundo real, tales cosas deber ser identificables y tener algunas propiedades. A las cosas sobre las cuales almacena información una base de datos se las denomina entidades, y pueden ser 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 deben ser identificables y, por tanto, ser posible señalar a una cualquiera de ellas sin ambigüedad.

Los atributos, por su parte, son las propiedades relevantes que caracterizan una entidad (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 consiste 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 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. Nombre de campo
  2. Valor de campo
  3. Dominio de campo

El nombre del campo es una constante que identifica una zona del registro. El valor es una variable que se refiere al contenido concreto de un campo y puede ser distinto para cada uno. 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. En 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 nombres de responsables intelectuales de los documentos.

Título Internet: manual de referencia
Autor Harley Hahn; Rick Stout
Fuente Madrid: Osborne
Mcgraw-Hill, 1994
Año 1994
Páginas 692
Isbn 84-481-1882-0
Descriptores Internet, Redes telemáticas, Bases de datos, Correo electrónico, Telnet, Usenet, FTP, Wais, World Wide Web

Generalizaciones y abstracciones

Al igual que distinguíamos entre 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, o sea, ignorando ciertos aspectos distintos de diversas ocurrencias de entidad, y formando 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 (diseños gráficos)

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, de paisajes, o si es una infografía, etc.

La segunda y última parte de este trabajo se publicará en el próximo número.

Lluís Codina. Profesor de Documentación. Universidad Pompeu Fabra. Barcelona

Tel.: +34-3-542 22 65 / 6

codina_lluis ARROBA fcsc.upf.es

Enlace del artículo:
http://www.elprofesionaldelainformacion.com/contenidos/1995/abril/metodologa_de_creacin_de_bases_de_datos_documentales_parte_i.html