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 veces a un cierto y 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 razonables. Pongamos un ejemplo: supongamos que alguien afirma 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. Por desgracia, se sabe de 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 uno de los aspectos más básicos del diseño de sistemas de información que aconseja comenzar siempre un proyecto estudiando en primer lugar 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 explican esa clase de principios a una audiencia, invariablemente, todo una parte de ella 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: a) Aparato conceptual b) Aparato instrumental c) 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 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. 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 ayudará a reducir al mínimo posible los riesgos debidos a la improvisación. Para elaborar esta metodología, los autores han seguido tres principios o tradiciones, cada una de ella bien cimentada en su propio campo: (2) la tradición del análisis de sistemas, de fuerte influencia informática, que podemos representar en autores como Yourdon; (2) la Soft System Metodology, desarrollada por Chekland, muy utilizada para el análisis general de problemas y a su vez muy influenciada por la teoría general de sistemas; por último, hemos tenido siempre como background general (3) las metodologías propias de las Ciencias de la documentación relacionadas con la descripción y el tratamiento de información cognitiva. A través de diversos proyectos en los que han participado los autores, la metodología que se expone aquí ha sido a su vez puesta a prueba en el terreno de la realidad y refinada con los resultados de la experiencia. Aparato conceptual. Modelos. El punto de partida consiste en considerar la futura base de datos como un sistema de información que mantiene registros sobre alguna parte del mundo real. A esta parte del mundo real la podemos denominar sistema objeto. Por tanto, una base de datos, vista de esta forma, es un sistema que mantiene registros para describir o representar cosas del mundo real (documentos, ideas, personas, objetos, etc.). De este modo, el proceso de análisis y diseño puede concebirse como el intento de obtener un modelo lo más fiel posible de aquella parte de la realidad (sistema objeto), que resulta de interés para el sistema de información. Tenemos entonces el par conceptual: 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 es un modelo de un territorio. Esta relación nos dice algo que, a primera vista parece obvio, pero que, en la práctica, se olvida con mucha frecuencia: una base de datos es un modelo y su misión como tal es parecerse lo más posible a aquello que intenta representar. Si el sistema objeto consiste en fotografías (imaginemos la base de datos de imágenes de un diario o de una revista), entonces la base de datos documental debe contemplar las características de esa parte del mundo real que son las fotografías, y deberá tener en cuenta el hecho de que una fotografía tiene características formales (ByN, color), características icónicas (aparecen determinadas cosas o personas en las fotografías), que tienen una fecha de toma, que tienen un autor que posee unos derechos de reproducción sobre las mismas, etc. No tiene sentido entonces esa expresión, por desgracia tan frecuente, que dice así más o menos: “lo siento, no podemos buscar fotografías por el nombre del autor porque no está previsto en el sistema”. Ese tipo de declaraciones son en realidad declaraciones de fracasos y si se ajustaran a la realidad, deberían decir lo siguiente: “lo siento, pero el diseño de este sistema de información es tan deficiente que no ha sido capaz de reproducir aspectos esenciales de la realidad que se supone debería representar”. Subsistemas. El segundo punto de partida consiste en considerar que, desde el punto de vista de las bases de datos documentales, todo sistema objeto (S2) se compone al menos de dos componentes o subsistemas: a) La empresa o el sistema social que necesita de la base de datos o, dicho de forma más abstracta, el sistema de actividades humanas (SAH) en el que se inscribe la futura base de datos. b) El conjunto de cosas, entidades o documentos que deberán ser descritos y representados en la base de datos, o dicho de forma más abstracta, el sistema de entidades registrables (SER) que estará incluidas en la base de datos. El sistema de actividades humanas (SAH) se refiere a la organización, la empresa o, en términos generales al sistema social –es decir, un sistema formado por personas y cosas– que justifica o exige la existencia de la futura base de datos. En esta organización social desarrollan sus actividades los futuros usuarios que necesitarán que exista un sistema de información (en ocasiones, nos puede convenir considerar que, a su vez, dentro del SAH podemos distinguir entre el poseedor o propietario del sistema y los usuarios o beneficiarios del sistema (Checkland, 1981)). Por ejemplo, si pensamos en el OPAC (catálogo online) de una biblioteca universitaria como en un sistema de información, entonces el sistema objeto al cual modela es la universidad de la que forma parte, 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, entonces, el OPAC de la biblioteca modela en alguna forma a la universidad? En el sentido en que el lenguaje documental con el cual describe a los documentos, la propia selección de los documentos que adquiere, los procedimientos de trabajo, los servicios que presta, etc., son un reflejo de las características de la universidad. Si consideramos ahora la base de datos de una empresa periodística, la propia empresa periodística es el SAH del sistema objeto, pero el público interesado en la consulta de esa base de datos formará parte también del SAH, en este caso, como beneficiarios del sistema. Dado que el entorno siempre influye en el sistema, a veces de forma decisiva, los diseñadores de la base de datos también deberán conocer las características del entorno de la empresa (o del SAH en términos más abstractos). Por su parte, el conjunto de cosas, entidades o documentos que deberán ser descritos y representados en la base de datos forma el llamado sistema de entidades registrables (SER). Cuando pensamos en una base de datos documental es normal pensar en documentos (p.e., en documentos impresos), pero desde un punto de vista abstracto esto es inexacto. En primer lugar, en rigor, una base de datos contiene representaciones de entidades y no necesariamente a las entidades en sí mismas (piensen en una base de datos de patrimonio arquitectónico). En segundo lugar, en una base de datos documental podemos tener los siguientes tipos de entidades representadas: a) Cosas: como documentos en papel (bases de datos bibliográficas), films (bases de datos de cinematografía), obras de arte (bases de datos de museos) o monumentos (bases de datos de patrimonio arquitectónico).