Contenidos del Máster en Documentación Digital Artículo 2.2. Metodologia de análisis y diseño de base de datos documentales Autor: Lluís Codina

Usuario: Ines Frade Miguez. Tipo de página: contenido. Fichero: pag90332.htm

[imprimir] · [exportar a Openoffice]

Citación recomendada: Lluís Codina. Artículo 2.2. Metodologia de análisis y diseño de base de datos documentales [en línea]. En Cristòfol Rovira; Lluís Codina (dir.). Máster en Documentación Digital. Barcelona: Área de Ciencias de la Documentación. Departamento de Comunicación Audiovisual. Universidad Pompeu Fabra, 2009. http://www.documentaciondigital.org

Sumario 1. Introducción 2. El peligro del sentido común 3. ¿Qué es una metodología? 4. Aparato conceptual 4.1. Composición del sistema objeto 4.1.1. Sistema de actividades humanas 4.1.2. Sistema de entidades registrables 4.2. Propósitos y objetivos 5. Aparato instrumental 5.1. Modelo Entidad-Relación 5.2. Generalizaciones y abstracciones 5.2.1. Toma de decisiones 5.3. El diccionario de datos 5.4. La norma ISBD, modelos canónicos y benchmarking 6. Aparato procedimental 6.1. La fase de análisis 6.2. La Fase de diseño 6.3. La fase de implantación 7. Estudio de caso 7.1. Escenario del proyecto: descripción 7.2. Resolución del problema: Diccionario de datos 7.3. Diccionario de datos 7.4. Ilustraciones 7.5. Conclusiones del estudio de caso 8. Oferta del mercado de sistemas de gestión de bases de datos documentales 9. Conclusiones generales: significado estratégico de las bases de datos y algunos factores

para el éxito 10. Bibliografía recomendada

1. Introducción

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

Por desgracia (o por suerte), en el desarrollo de sistemas de información no existe nada parecido a los algoritmos (ni a las recetas de cocina). ¿Para qué sirve entonces una metodología en nuestro contexto?

La experiencia indica que una metodología sirve, exactamente, para que el resultado final de un proyecto documental 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.

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, la diferencia entre utilizar una metodología o no utilizarla está en la proporción del producto final que puede atribuirse al azar, al ensayo y error o 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, es decir, que el azar y el ensayo y error tengan un gran peso, sólo puede producir sistemas deficientes, principalmente porque los sistemas ineficientes son mucho más probables, ya que hay un número virtualmente infinito de formas de hacer mal cualquier cosa, y siempre que dejamos algo al hazar 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.

2. El peligro del sentido común

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 ante esta postura radica en que, si bien muchas recomendaciones acertadas parecen de sentido común, sus contrarias también lo parecen. Es decir, aunque una recomendación dada suene a sentido común, es peligroso no observar que, si nos fuera dada la recomendación contraria, también nos parecería de sentido común.

Así pues, con una metodología, por lo menos sabemos cuáles de las muchas cosas que parecen razonables son, de hecho, 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.

No sé que le parecerá al lector, pero se sabe de muchos equipos de diseñadores a los cuales el consejo le pareció tan adecuado que lo llevaron a la práctica con resultados, por supuesto, negativos. 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 primero 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 en un aula, o se leen en un artículo, invariablemente, se tiene la sensación de estar ante un mensaje de sentido común.

3. ¿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 documentales, una metodología debería contemplar, como mínimo, tres grupos de elementos o aparatos:

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

El aparato conceptual 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.

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 ayuda a reducir al mínimo posible los riesgos debidos a la improvisación.

Una vez expuestas estas consideraciones de tipo meta-metodológicas, se exponen 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 por este mismo autor en otros documentos (Codina, 1994a y Codina 1994b).

4. 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, al que denominamos S1, que mantiene registros sobre otro sistema del mundo real, al que denominamos S2. A partir de aquí, podemos decir que, si S1 es un sistema de información, entonces, S2 es un sistema objeto, es decir la parte de la realidad que, por algún motivo queremos registrar y representar en el sistema de información.

De este modo, el proceso de análisis y diseño puede concebirse como el intento de construir un modelo, S1, de aquella parte de la realidad, S2, que denominamos sistema objeto, y que, por algún motivo, resulta de interés para los diseñadores del sistema de información.

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, sistema de información) es un modelo del segundo (S2, sistema objeto o la parte del mundo real que queremos registrar), 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) presenta la siguiente composición:

1. Subsistema de actividades humanas 2. Subsistema de entidades registrables

Además, sabemos que todo sistema significativo presenta unos:

1. Propósitos y objetivos

¿Cuantos aparatos o elementos debe contener una metodología en sistemas de información?

A su vez, esta composición determinarán: el público, la composición y los objetivos de la base de datos. Examinemos en el siguiente punto las características del sistema objeto.

4.1. Composición del sistema objeto

Los componentes del sistema objeto, o parte de la realidad que queremos representar y registrar y que resultan relevantes a efectos de análisis y diseño de bases de datos, según hemos avanzado antes, son los siguientes:

1. (sub)Sistema de actividades humanas (SAH) 2. (sub)Sistema de entidades registrables (SER) 3. Propósitos y objetivos del sistema

4.1.1. Sistema de actividades humanas

El Sistema de Actividades Humanas (SAH) es el sistema social --es decir un sistema formado por personas y cosas-- que justifica la existencia del futuro (o actual) sistema de información, porque en él desarrollan sus actividades los futuros usuarios que consultarán, explotarán, etc., ese sistema de información.

Por su parte, el término Sistema de entidades registrables (SER) debe entenderse como una abreviación de la expresión siguiente: sistema de entidades candidatas a ser descritas y registradas en la base de datos. A fin de evitar esa expresión tan poco manejable, nos quedamos con la anterior, que representaremos como SER, por sus siglas. Vamos a continuar examinando con más detalles a estos componentes.

El SAH, como hemos dicho es un sistema social, y por tanto se caracterizará por estar formado por unos actores, por formar parte de otros sistemas más amplios y por las relaciones que mantenga con otros sistemas. Como veremos más adelante, pero puede intuirse ya perfectamente, para diseñar una base de datos es preciso conocer antes el SAH al que dará soporte. A su vez, conocer el SAH significa determinar por lo menos los siguientes elementos:

1. Su composición 2. Su entorno 3. Su propósito

En este punto debe advertirse que es fácil identificar al SAH con la empresa u organismo propietaria de la futura (o actual) base de datos, pero debe advertirse que no siempre resulta ventajoso considerarlo así. Por eso, hablamos de Sistema de Actividades Humanas, y no simplemente de empresa que crea, produce o posee la base de datos. Deberemos distinguir, por tanto, entre el poseedor de la base de datos y el SAH que da sentido (modela es el término técnico) a la base de datos.

Pongamos un ejemplo: la empresa ACME decide crear la base de datos MAGNUM. Por tanto, esto parece indicar que el SAH que debe influenciar (modelar es el término técnico, como decimos) a Magnum es, precisamente, ACME. Veamos si es cierto.

Con frecuencia una empresa crea una base de datos documental para uso interno, por ejemplo, para dar soporte a su departamento de I+D. En este caso, la identificación entre SAH y empresa productora de la base de datos es totalmente correcta, ya que ACME es, a la vez el propietario y el (sub)sistema de actividades humanas (SAH) de MAGNUM y, por tanto, la base de datos MAGNUM deberá estar modelada por las características de la empresa ACME: por sus objetivos generales, por las características de sus inversiones en I+D, por las necesidades de sus usuarios, etc.

De hecho, si concretamos un poco más, deberíamos hablar de dos niveles de SAH: el primer nivel es del departamento concreto al que debe dar soporte la base de datos, en este caso, hemos dicho que es el departamento de I+D. Este departamento es el SAH de primer nivel de la base de datos. En el segundo nivel tenemos a la propia ACME, que es el SAH de segundo nivel de la base de datos, cuando ésta exista.

En otros casos, la empresa que crea o posee una base de datos la produce para ofrecerla en explotación a un público externo determinado. En este caso, el SAH estará formado por el sistema que forma ese público determinado. Por ejemplo, supongamos que ACME produce MAGNUM no para uso interno, sino con el fin de obtener ingresos procedentes de permitir la consulta de la base de datos, y estos ingresos se espera que procedan del interés por parte del público por suscribirse a MAGNUM con tal de poder consultarla. Por ejemplo, supongamos que ACME desea producir una base de datos de información legal y económica para las empresas. El SAH está formado entonces por el conjunto de los usuarios de la base de datos: empresas que desean tener acceso selectivo a información estratégica para sus actividades de negocios.

Otro ejemplo, supongamos que una ONG dedicada a la defensa de los derechos humanos y la paz decide crear una base de datos con informes, documentos y noticias de prensa relacionados con los temas de su interés a fin de ponerlos al servicio de los técnicos, estudiosos e investigadores en el tema. La clase de sistema de actividades humanas que deberán estudiar los diseñadores de esa base de datos serán las actividades relacionadas con el estudio de los derechos humanos y la promoción de soluciones pacíficas para los conflictos.

Así, debemos insistir en que el SAH no necesariamente es la organización que crea la base de datos, sino el sistema de actividades humanas que utilizará, se beneficiará, etc., de la futura base de datos.

4.1.2. Sistema de entidades registrables

Por su parte, el sistema de entidades candidatas a ser registradas (SER, para simplificar) está formado por la clase de entidades (documentos, personas, objetos o conceptos) sobre las cuales la base de datos debe mantener algún tipo de registro. Al igual que con el anterior concepto, debemos resistirnos aquí a la identificación simple según la cual las entidades siempre son documentos porque, efectivamente, no siempre las bases de datos documentales (pese a su nombre) registran documentos.

Considere el alumno las siguientes posibilidades de bases de datos en las que los tipos de entidad no son tipos de documentos (por lo menos no lo son en el sentido tradicional del término):

1. Bases de datos sobre el fondo artístico de un museo 2. Bases de datos sobre hechos históricos o teorías científicas 3. Bases de datos biográficas 4. Bases de datos sobre patrimonio arquitectónico

En ninguno de los casos precedentes tenemos descripción de documentos sino de objetos, conceptos, personas y edificios respectivamente. Es por este motivo, que hablamos de entidades y no de documentos, puesto que tanto las cosas cocretas, como objetos y documentos; las cosas abstractas, como teorías y conceptos; y los seres animados, como los seres humanos, son entidades.

Analicemos un caso concreto para acabar de ver estas ideas:

Caso ACME. Supongamos que se precisa la creación de una base de datos de prensa con fines de distribución comercial, es decir, destinada a ser un producto competitivo en el mercado. Imaginemos, para exponer este caso, que la empresa ACME ha decidido entrar en el negocio de la producción de sistemas de información con valor añadido, dirigida al sector de negocios. El valor añadido consiste en la selección de las noticias, el tratamiento documental y la posibilidad de su consulta retrospectiva y acumulada con valor heurístico propia de las bases de datos documentales.

Se supone que un estudio previo ha demostrado a ACME que existe un nicho comercial no explotado, o no explotado del todo, consistente en la demanda de una base de datos sobre información económica para empresarios y directivos. Ante esta situación, ¿cuáles son el SAH

y el SER de la futura base de datos?; ¿Qué clase de cosas deberemos estudiar para poder enfocar con éxito nuestro proyecto?

Aunque ACME es la entidad que va a crear la base de datos, ahora ya sabemos que el sistema de actividades humanas a considerar es la actividad de negocios que llevan a cabo las empresas y, dentro de ellas, determinadas personas que serán los futuros clientes (usuarios) de la base de datos. La composición de este SAH está formada, por tanto, por empresarios, ejecutivos, inversores, analistas, financieros…, etc., de deben estar informados sobre su entorno y que deben tomar decisiones económicas.

Por su parte, el SER, o sistema de entidades registrables, está formado por las noticias sobre economía y negocios que publican los medios de comunicación, incluyendo, eventualmente, transcripciones de noticias de radio y televisión. Deberemos conocer bien, por tanto, qué es y que estructura tiene una noticia de prensa, cuáles son los géneros periodísticos y cuáles son los medios más influyentes, qué secciones de la prensa incluyen noticias más relevantes para nuestro público, etc.

En conclusión, para diseñar la base de datos de este caso, nos veremos inmersos en el mundo de la empresa, el mercado y los negocios, por un lado (el del SAH); así como en el mundo de la prensa y las noticias de actualidad, por otro lado (el del SER). Del estudio de esas dos realidades podremos obtener la información que necesitamos para nuestro proyecto.

¿Qué opina de esta proposición? "una base de datos es una representación de una parte de la realidad"

4.2. Propósitos y objetivos

Para poder proseguir, debemos establecer una distinción entre propósito y objetivo. Un propósito es algo que se percibe como una tendencia deseable para el sistema o un estado óptimo al que aspira el sistema aunque tal vez no se pueda cumplir del todo nunca. Consideremos el propósito de un organismo como la Unesco: proporcionar acceso a la cultura a todos los ciudadanos del mundo, y proporcionarlo en condiciones de igualdad. Tal vez no lo consiga del todo nunca, pero no deja de ser una aspiración que guía sus actividades. Además, expresado de esa manera, no existe una única forma de medir su cumplimiento.

Los objetivos, en cambio, deben formularse para ser cumplidos total o parcialmente, y deben formularse de manera que sea posible medir su grado de cumplimiento de una forma clara y sin ambigüedades, típicamente cuantificándolos. Por ejemplo, la Unesco puede proponerse que en determinado año, cierta región del mundo disponga de un cierto número de bibliotecas y libros por habitante. Ese objetivo se puede expresar, como se vé, de manera que es posible medir su grado de cumplimiento y se supone que se hace confiando en qué es totalmente posible su cumplimiento.

Todo sistema social o humano significativo tiene un propósito. Por tanto, deberemos conocer bien el propósito del sistema objeto para dotar de un objetivo a la base de datos que estamos en vías de diseñar.

La razón es que, siendo la base de datos un modelo del sistema objeto, el objetivo de la base de datos deberá coincidir o por lo menos ser plenamente compatible con el propósito del sistema objeto.

De hecho, es casi imposible saber alguna cosa razonablemente fundada de un sistema de actividades humanas sin conocer su propósito, pero aquí queremos hacer énfasis en la utilidad de tener clara estas ideas en el momento en que, trabajando en el proyecto, cual ayuda metodológica es valiosa.

Por lo tanto, por un lado, debemos saber cuál es el propósito del sistema objeto para conocerlo realmente, pero además, deberemos conocer cuáles son los objetivos concretos que están en

curso. Por otro lado, sabemos que el propósito de toda base de datos, en cuanto sistema de información documental, es el mismo: producir personas informadas, o si se quiere decir en un lenguaje menos sistémico, satisfacer necesidades de información.

En segundo lugar, debemos considerar que el intento de diseñar un nuevo sistema, en este caso, una base de datos, coincide siempre con la existencia de lo que Checkland (el autor de la Soft System Methodology, o SSM) denomina "una situación problemática" en el seno del sistema de actividades humanas.

Según la SSM, cuando se produce una situación problemática, los componentes del SAH buscan, como es lógico, algo que la solucione. Este "algo", en nuestro caso, se supone que es la futura base de datos (si este algo no es la base de datos, entonces no tenemos nada que hacer en este caso, salvo desearles suerte). La idea aquí, por tanto, es la siguiente:

1º. Averíguese en qué consiste el problema que los actores del SAH creen que la base de datos va a solucionar y examínese críticamente esa idea.

2º. Si es plausible la idea que los actores del SAH se han hecho de la cuestión, deberá incorporarse entonces a los objetivos del diseño. Por ejemplo, tal vez la motivación para crear la base de datos sobre recursos culturales del Ayuntamiento de Metrópolis proviene de alguna iniciativa ciudadana. Sería lógico examinar la formulación de esa inciativa y sería lógico planificar alguna encuesta que nos permitiera conocer qué podrían esperar de la base de datos algunos de sus futuros usuarios.

Por tanto, la determinación del público, el propósito y los objetivos de la base de datos serán una coproducción entre las características del SAH y las características de la situación percibida como problemática por los miembros del SAH y que se supone que la base de datos solucionará o ayudará a solucionar

Pongamos otro ejemplo. El propósito que se supone que da sentido a un Ayuntamiento podría enunciarse diciendo que consiste en aumentar la calidad de vida de los ciudadanos del municipio (por lo menos asi se entiende en un país democrático). Supongamos que el Ayuntamiento de Metrópolis forma parte de un país democrático y decide crear una base de datos de recursos culturales de su ciudad: museos, bibliotecas, archivos, monumentos, centros de información, centros de documentación, teatros, cines, institutos, centros de investigación, etc.

La idea, tal vez, es que sea útil a los profesionales y planificadores culturales del Ayuntamiento en primer lugar; a los profesionales de la cultura de la ciudad en general en segundo lugar; a otros departamentos del ayuntamiento en tercer lugar y a otros ciudadanos de otras ciudades, en cuarto lugar. La situción problemática es que los técnicos, profesionales y altos cargos del ayuntamiento encuentran dificultades para desarrollar su labor de gestión y planificación cultural a causa de la complejidad y variedad de la oferta cultural de su ciudad, lo que es una gran cosa, pero la cuestión es que tienen dificultades reales para manejar la información por lo procedimientos habituales, y de aquí que surge la idea de crear una base de datos.

Repasemos la situación con lo que sabemos hasta ahora: ¿cuál será el propósito de la base de datos? Satisfacer necesidades de información. ¿Cuál es el propósito del Ayuntamiento de Metrópolis? Aumentar la calidad de vida de sus ciudadanos. Por tanto, y aquí estamos en condiciones de crear nuevo conocimiento, ¿cuál podría ser el propósito de la base de datos?: contribuir al aumento de la calidad de vida de los ciudadanos de Metrópolis satisfaciendo sus necesidades de información en materia de cultura; indirectamente proporcionándola a los profesionales en gestión y planificación cultural, y directamente proporcionando información al propio ciudadano.

En cambio, los objetivos de la base de datos podrían consistir en tener tantos y tantos recursos descritos cada año, en proporcionar tantos y cuantos accesos o consultas por año, etc.

La cuestión es que, 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 he hecho una elección concreta, pero probablemente son posibles otras interpretaciones.

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

5.1. Modelo Entidad-Relación

El modelo entidad-relación (o modelo E-R) ayuda a detectar sin ambigüedad 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

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.

Figura 1: Un registro en representación de un libro

Título Multimedia and hypertext: the Internet and beyond

Autor Jakob Nielsen

Fuente Boston: Academic Press, 1995

Año 1995

Páginas 480

ISBN 0-12-518408-5

Descriptores Hipertextos, Multimedia, Sistemas de información, Publicaciones digitales, Documentación, Bases de datos, Internet, World Wide Web

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 o descomponer así:

• Nombre del campo: Autor • Valor del campo: Jakob Nielsen • Dominio del campo: Responsables intelectuales de los documentos

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

Figura 2: Digrama de una relación entre dos entidades. Así, por ejemplo, la relación que existe entre el número de ISBN y un libro es una relación de 1:1 (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 catedráticos de universidad y universidades es de 1:N, (de uno a muchos) porque cada catedrático pertenece a una sola universidad, y una universidad tiene diversos catedráticos.

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

5.2.1. Toma de decisiones

En conclusión, 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. 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, 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

5. Si la relación es de grado N:1, o N:M, se trata de dos entidades y, por lo tanto, necesitamos al menos dos modelos de registro, uno para cada entidad. Los dos modelos de registro deben contar con un campo compartido, lo cual proporciona dos campos con un dominio común. Esto último permitirá el cruce de datos. En algunos casos, podemos necesitar un tercer modelo de registro para representar la relación. Esto último es necesario cuando la relación es muy dinámica ya que representa una actividad o un proceso que cambia constantemente con el tiempo. Por ejemplo, la relación entre autores (una entidad) y libros (otra entidad) es estática y no cambia o cambia solamente de manera incremental. En cambio, la relación entre documento y usuario del documento es muy dinámica. En este caso necesitaremos tres modelos de registro: uno para documentos (una entidad), otro para libros (la segunda entidad) y

otro para préstamos (la relación). Por ejemplo, en el supuesto que estamos discutiendo, deberían utilizarse estos dos modelos de registro:

• Autores • Obras

Tanto el modelo de registro Autores como el modelo de registro Obras debería tener un campo cuyo dominio fuera el nombre de los autores, aunque en cada campo la etiqueta fuera distinta.

¿Qué sucedería si no procedíeramos 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, 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 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, muy importante, sobre la aplicación del 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.

5.3. El diccionario de datos

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 datos, 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. Etiqueta 2. Dominio 3. Tipo de datos 4. Indexación 5. Tratamiento documental 6. Lengua 7. Otros controles de validación u observaciones

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 podría tener entonces esta forma:

Campo Título Etiqueta: Titulo Dominio: Título del documento. Tipo: Alfanumérico. Indexación:Sí 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. Observaciones: El título se transcribe de la siguiente forma Título: antetítulo: subtítulo.

Campo Descriptores 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. Tipo: Alfanumérico Indexación: Sí 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 Etiqueta: FechaPub Dominio: La fecha de publicación de la noticia, indicada con el siguiente formato, DD/MM/AAAA. Tipo: Fecha Indexación: Sí Tratamiento documental: No procede Lengua: No procede Controles de validación: No admite valores fuera de rango.

Estudiando el ejemplo de diccionario de datos anterior, formado únicamente por tres campos, podemos observar, por vía de ejemplos, algunos aspectos importantes para el diseño de bases de datos que retomamos ahora:

(1) Dominio. En el contexto del diccionario de datos, el dominio se refiere al conjunto del que un campo puede obtener sus valores. Dicho de otra forma, describir el dominio de un campo consiste en describir el contenido teórico de ese campo, es decir, la clase de contenidos que puede admitir el campo.

(2) Tipo (o data type). Es el tipo de dato que admite el campo. Los tipos de datos suelen ser: numérico, alfanumérico, fechas y lógico. El tipo dato (data type) establece cuáles son las operaciones válidas que puede hacerse y el rango de valores aceptable. Por ejemplo, el tipo de datos alfanumérico permite realizar operaciones de ordenación, en cambio, no admite operaciones aritméticas. Por el contrario, un tipo de dato numérico solamente admite números y operaciones aritméticas. Por su parte, un campo de fecha 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, etc.

(3) Etiquetas. En los tres ejemplos anteriores hemos seleccionado etiquetas sujetas a algunas restricciones habituales: no más de ocho caracteres, sin espacios y sin acentos. Lo hemos hecho así para ilustrar la diferencia entre el nombre del campo en lenguaje natural (sin limitaciones especiales) y su etiqueta, que suele estar sometida a restricciones como las señaladas.

(4) Tratamiento documental. Este parámetro 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 establece que ese campo sólo admite palabras clave autorizadas extraídas de un thesaurus o de una lista de autoridades.

(5) Lengua. La lengua o idioma de un campo puede ser, o bien la lengua del documento, o bien la del centro de documentación. Si observamos los ejemplos anteriores esto significa que, en el caso de un documento escrito en inglés, 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.

5.4. La norma ISBD, modelos canónicos y benchmarking

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 cual 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 testado.

Por ejemplo, los atributos estructurales de cualquier clase de documento pueden ser adecuadamente modelados siguiendo la norma internacional ISBD.

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 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 señalar 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 puntuación que prescribe y, en tal sentido, se ha argumentado que utilizar la norma ISBD puede tener sentido en algunos contextos de lectura pública, pero no necesariamente para el diseño de bases de datos documentales.

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 información para situaciones más exóticas, independientemente de que incorporemos o no la norma en toda su complejidad.

Por último, unas palabras sobre el benchmarking en el diseño de bases de datos (aunque más adelente volveremos sobre ello, brevemente): benchmarking significa, como es sabido, observar a nuestra mejor competencia para intentar aprender de ella. Debe descartarse cualquier leve asomo de espionaje o de obtención de información sin el consentimiento de la parte interesada. Benchmarking significa aprender a partir de informaciones hechas públicas, por ejemplo, de lo que nuestros colegas o nuestra competencia publica en congresos. También de lo que nos quieren explicar si pedimos abiertamente ayuda o colaboración. Las empresas compiten entre ellas, pero también colaboran. Por ejemplo, algunos sectores económicos

tienen organismos de I+D cofinanciados entre las empresas de un sector. Si nuestro proyecto está dentro del sector público, con más razón deberíamos hacer una labor de benchmarking para determinar si alguna otra Administración ya ha hecho algo parecido y tratar de aprender de ellos. En definitva, se trata de no olvidar que el benchmarking, realizado de forma ética, debe formar parte del conjunto de herramientas de análisis y diseño de un documentalista a la hora de afrontar proyectos de información por poco que se lo pueda permitir.

6. 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, pero siempre que empecemos por las cuestiones lógicas y no al revés.

El aspecto importante aquí, por tanto, 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) e 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 siguiente cuadro sinóptico sintetiza estas ideas:

Figura 3: Cuadro sinóptico de la dirección del diseño en el ciclo de vida de un sistema de información

• De lo conocido a lo desconocido • De los aspectos lógicos a los aspectos físicos

• De lo general a lo concreto

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:

Figura 4: Cuadro sinóptico del ciclo de vida de una base de datos documental

1. Análisis

1a. Análisis del sistema de actividades humanas y, si es el caso, de su entorno más significativo, incluyendo análisis comparativos, si es el caso (benchmarking)1b. Análisis del sistema de entidades registrables. 1c. Primera estimación de objetivos y requerimientos1d. Primera estimación presupuestaria y de calendario de realizaciones

2. Diseño

2a. Diseño del modelo conceptual2b. Determinación de los procedimientos de tratamiento documental (descripción, análisis e indexación documental, etc.) si es el caso.

3. Implantación

3a. Elaboración de un presupuesto final y del calendario de implantación, en su caso. 3b. Selección del soporte informático (software y hardware) de acuerdo con los requerimientos expresados en el modelo conceptual de la base de datos producido en la fase 2a y de acuerdo con los requerimientos expresados en 2b. 3c. Instalación, pruebas de rendimiento y (re)elaboración, en su caso, de los puntos previos de este ciclo de vida. 3d. Elaboración del libro de estilo de la base de datos. 3e. Carga de datos, formación de usuarios y promoción del producto.

Aunque expresado en fases y 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.

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

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.

6.1. 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 conjunto de entidades susceptibles o candidatas a ser registradas (SER) 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.

Es por ello que el resultado que debe producir esta fase de análisis es un adecuado conocimiento del sistema objeto, compuesto como ya hemos indicado más arriba, por el Sistema de actividades humanas (SAH) y por el Sistema de entidades candidatas a ser registradas (SER).

A veces, dilucidar las características, tanto del SAH como del SER, puede resultar fácil hasta la trivialidad, sobre todo si se trata de diseñar una base de datos para un departamento un organismo en el que llevamos tiempo trabajando y que, por tanto, conocemos bien.

Otras veces, tal vez no estemos tan familiarizados con el SAH. En estos casos, ¿cómo podemos estar seguros de que hemos comprendido bien las cuáles son las características del SAH?

Naturlamente, una vez más, debemos señalar que no hay fórmulas mágicas ni recetas infalibles. El procedimiento habitual para conocer o comprender la naturaleza de un sistema incluye tres procedimientos:

Primero: realización de entrevistas con los actores del sistema. Si tenemos el encargo de hacer una base de datos para la Filmoteca deberemos entrevistarnos con el staff de la

Filmoteca. ¿Con cuánta gente? Depende del presupuesto, del tiempo disponible, etc., de manera que si nos podemos entrevistar con todo el staff mejor, si no es el caso, sería aconsejable entrevistarse con una representación de todas las categorías de usuarios de la Filmoteca: la gerencia, el archivo, el departamento de estudios, con algunos usuarios, etc.

Segundo: con el examen de documentos fundacionales, memorias e informes de actuación del organismo o empresa.

Tercero: con visitas a otros organismos semejantes, si el caso, que hayan desarrollado servicios similares o que tengan problemas parecidos. Estas visitas pueden sustituirse a veces con estudios realizados a través de la Web de bases de datos similares. Por ejemplo, si tenemos que diseñar una base de datos de imágenes, sería impresoindible seleccionar unas cuantos bancos de imágenes en la web y analizar cómo tratan la información. No se trata nunca de copiar, sino de intentar aprender de nuestro entorno y de nuestra competencia, pero transformando y aplicando lo aprendido de manera propia y original a nuestro contexto. En algunos casos, puede ser necesario hacer ambas cosas: una investigación en la web y alguna visita a colegas de otros organismos con problemáticas similares

Por tanto, si la complejidad del proyecto lo requiere, y si deseamos estar seguros de que hemos superado bien esta fase, podemos aplicar una especie de test final que consiste en producir un documento que denominaremos Modelo Esencial, y que puede incluir los siguientes aspectos:

1. Propósito y objetivos del SAH 2. Actores principales del SAH 3. Descripción de las actividades más relevantes del SAH 4. Datos más relevantes sobre el entorno del SAH 5. Descripción de los candidatos a entidades registrables 6. Determinación de ojetivos y usuarios del sistema de información

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 unos cuantos párrafos serán 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, es decir, que la producción de este documento, como decimos, es una especie de test al que se somete el equipo de diseñadores para asegurarse que han entendido el entorno donde va a dar su servicio la base de datos. Otras veces, será suficiente con que el equipo de desarrollo se asegure de tener esas informaciones claras en la cabeza, sin necesidad de que llegue a producir el documento por escrito.

Por su parte, el propósito de la fase del análisis del sistema de entidades regitrables o SER consiste en asegurarse de que hemos identificado y de que conocemos bien los documentos o las cosas sobre las cuales la base de datos deberá recoger información.

El resultado de esta fase, en todo caso, 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, así como 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. Este modelo se explicará en el apartado dedicado a las herramientas.

6.2. La Fase de diseño

El propósito de la fase de diseño es producir un documento denominado Modelo Conceptual que incluya, principalmente, el diccionario de datos y una propuesta de tratamiento documental, si es el caso. El Modelo Conceptual consiste en la base de datos diseñada sobre el papel y equivaldría al guión de una película si lo comparemos con un film, o a los planos de un edificio si lo comparamos con una casa.

La idea es sencilla y se ha reiterado en varias ocasiones: al planificar la base de datos sobre el papel, separamos el momento del diseño del momento de la implantación, y lo hacemos cuando corresponde: diseño antes de la implantación. Además, al planificar sobre el papel, podemos tomar decisiones con tiempo suficiente para reaccionar, prevenir, etc.

Finalmente, podemos hacer que nuestro cliente, si es el caso, apruebe el modelo conceptual, es decir, cuando aún estamos a tiempo de canviar cosas y de tomar nuevas decisiones sin un coste muy alto, antes de iniciar la implantación.

La cuestión es que el Modelo Conceptual puede incluir diversos elementos, dependiendo del alcance y complejidad del proyecto, como ya veremos, pero los dos principales son los que ya hemos señalado: (1) el diccionario de datos y (2) la propuesta de tratamiento documental, desarrollada por separado si es necesario, ya que puede estar incluida en las especificaciones del diccionario de datos.

El diccionario de datos, como ya sabemos, guiará el proyecto desde el inicio mismo del proceso de creación, permitirá realizar las primera pruebas e implantar la base de datos. A partir de aquí y cuando la base de datos ya esté en pleno funcionamiento, el diccionario de datos será su auténtico "libro de estilo" de cara a su mantenimiento y explotación posteriores. La existencia de este libro de estilo asegurará, por tanto, el mantenimiento de la consistencia a lo largo del tiempo y aunque pasen diversos equipos de trabajo por ella.

Por su parte, la propuesta de tratamiento documental establece criterios y orientaciones sobre el proceso de análisis, descripción y representación de los documentos o entidades de los que tratará la base de datos, si es el caso.

El documento denominado Modelo Conceptual puede contener otros elementos si la naturaleza o la complejidad del proyecto los hace necesarios. Pero, a fin de tener una idea más concreta, a continuación indicamos los elementos que pueden formar parte del Modelo Conceptual si, por la naturaleza o complejidad del proyecto, se desea hacer producir un documento muy elaborado:

1. El Modelo Esencial, mencionando el propósito de la base de datos e identificando el tipo de usuarios del sistema

2. Una definición del tema o dominio de la base de datos, aunque puede estar recogido en el punto anterior

3. El diccionario de datos completo 4. Una descripción funcional del sistema, salvo que haya quedado bien establecida a

través de las explicaciones de los apartados anteriores

Cabe señalar que 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 consiste en que trata sobre 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.

Insistimos, sin embargo, que para muchas situaciones profesionales construir el Diccionario de datos (incluyendo, en su caso, las propuestas de tratamiento documental) es suficiente para crear el Modelo Conceptual, ya que los demás elementos, como el modelo esencial y el modelo entidad-relación, una vez han prestado su servicio como elementos de análisis para el profesional no es necesario que se incluyan en el informe final.

Así pues, y mientras no se diga lo contrario, siempre que hablemos de modelo conceptual de una base de datos, podemos identificar ese término con el de Diccionario de datos.

6.3. La fase de implantación

La implantación de una base de datos, cuando forma parte de un proyecto completo, requiere toda una metodología propia en donde se contemplen las diversas fases de proyecto y se pueda realizar la estimación de costos y el calendario de realizaciones.

Aquí hemos presentado una metodología de análisis y de diseño de bases de datos. Para la fase de implantación, únicamente podemos ofrecer aquí algunas orientaciones muy generales.

Estas orientaciones pueden ser válidas en tanto son muy generales, pero debe tenerse en cuenta que en determinado proyectos, por ejemplo en proyectos de tipo GED (Gestión Electrónica de Documentos) que incluyen a veces digitalizaciones masivas de documentos, cada una de las fases que se indicarán a continuación debe ser objeto de estudio y evaluación específica.

Por tanto, 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 realiza un análisis de costos y un primer calendario de realizaciones. Ambas cosas deben hacerse en función de las características del proceso de análisis de la información; del valor añadido que se quiera dar a los documentos mediante tratamiento documental; del volumen de datos a tratar y de las características y número de usuarios del futuro sistema.

2. 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 que contempla aquel. Naturalmente, en algunos entornos la arquitectura de información corporativa impondrá restricciones en el rango de soluciones informáticas a contemplar. En estas situaciones, la selección del sistema informático suele ser una responsabilidad exclusiva del Departamento de Informática. En tales casos, el equipo de documentalistas únicamente debe ocuparse de presentar las especificaciones funcionales que debe satisfacer el sistema al Departamento de Informática. De ser posible, se examinarán varios programas candidatos hasta que exista la certeza de que el programa elegido se ajustará lo mejor posible a los requerimientos funcionales del diseño. En este punto, tanto si la selección del programa va a cargo del departamento de informática como si va a cargo del propio equipo de documentalistas, corresponde señalar lo siguiente: probablemente no hay ninguna manera fiable de seleccionar un buen software basándonos únicamente en sus características técnicas o en una demostración puntual. Al final, la única forma fiable (e incluso esta puede fallar) es considerando, además de las características técnicas, las características de la empresa que está detrás del software. La experiencia dice que, tan importante --o más-- que el programa es la empresa que está detrás: ¿cuantos años hace que está en el mercado?, ¿cuántos clientes o cuantas instalaciones tienen?, ¿tienen club de usuarios?, ¿pueden facilitar referencias de instalaciones similares?, etc. Una vez seleccionado un software: 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. Se realizan pruebas con una colección-test de documentos o de entidades a ser representadas para comprobar la consistencia de los modelos, esquemas de registros, vocabularios controlados, etc.

3. Se realizan los cambios o ajustes necesarios, para refinar el modelo final. 4. Se determina la política final de mantenimiento y explotación. 5. Se edita la versión 1 del Libro de estilo de la base de datos, que incluye:

a)La versión definitiva del modelo conceptual (en la práctica, la mayor parte de las veces se identidica con el diccionario de datos) b) La normativa de tratamiento documental, si es el caso.

6. Se procede a la formación del personal técnico y de los usuarios finales. 7. Acciones de promoción, etc., en su caso.

7. Estudio de caso

Proyecto: Sistema de información sobre recursos digitales de Internet para la Editorial Acme.

7.1. Escenario del proyecto: descripción

La editorial Acme, especializada en comunicación audiovisual, multimedia y temas culturales, proyecta crear un sitio web que actúe como portal de Internet para los ámbitos temáticos señalados. Por lo tanto, esperan ser el portal de temas culturales y de comunicación.

Una de las secciones que esperan que proporcione un mayor interés a su portal es un servicio de selección y evaluación de recursos digitales que sea fácil de consultar por el público de la editorial y que permita a ese público hacer búsquedas selectivas por múltiples criterios: título, temas, idioma, etc.; así como búsquedas en las que se combinen dos o más de esos criterios.

Además, ese servicio deberá dar soporte a las diversas redacciones de la editorial que publica revistas sobre cine, cultura y pensamiento, humanidades, etc. Finalmente, y si el servicio es eficiente, la base de datos será el núcleo de una serie de guías sobre temas culturales en Internet que la editorial piensa ir publicando periódicamente.

Después de un proceso de análisis se ha llegado a la conclusión que se necesitará una base de datos documental para dar soporte al servicio, dada la diversidad de formas de explotación que se prevén. En concreto, la base de datos servirá para que un equipo de editores, con formación en documentación, pueda crear y mantener el sistema de información sobre recursos digitales.

Además, a través de un servidor web y de un programa que actúe como pasarela, la misma base de datos podrá ser consultada desde Internet utilizando un navegador web estándar, como Nestscape o Explorer.

Problema Desarrollar el diccionario de datos que constituirá el modelo conceptual de la base de datos que habrá de servir como núcleo del sistema de información descrito anteriormente.

7.2. Resolución del problema: Diccionario de datos

Después de un estudio de las características de ACME, del tipo de proyecto que desea llevar a cabo y del tipo de usuario al que desea dar servicio, así como después de estudiar la clase de recursos digitales que se desea evaluar, se propone la siguiente lista de atributos:

Tabla de atributos:

Título Tipo de recurso Autor Fuente Lugar Idioma Clasificación Descriptores Descripción Valoración Última visita URL

Atributos relevantes de la entidad

Operador Número de registro Fecha de alta Fecha de modificación

Elementos de control

7.3. Diccionario de datos

Cada uno de los atributos precedentes será un campo de la base de datos documental que servirá para el mantenimiento del sistema. En cada campo se indica, cuando es el caso, el tratamiento de control terminológico o documental más conveniente.

Campo Título Etiqueta Titulo

Dominio

Título propio o título atribuido del recurso, seguido del título traducido a la lengua del centro, en su caso. El título traducido se indica en la línea siguiente y entre corchetes. Ejemplo: Internet Movie Database [Base de datos de cine de Internet]

Tipo de datos Alfanumérico

Indización Sí

Lengua Del recurso/ Del centro

Tratam. Docum. NP

Obligatorio Sí

Observaciones Si el recurso tiene subtítulo o un elemento que actúa como tal, debe indicarse también, en la forma [Título: subtítulo].

Campo Tipo de recursoEtiqueta Tipo

Dominio La clase de recurso digital: base de datos, institución, documento, etc.

Tipo de datos Alfanumérico

Indización Sí

Lengua Del centro

Tratam. Docum.

Lenguaje controlado cerrado. Lista de valores admitidos: Base de datos Directorio Documento Institución Publicación periódica

Obligatorio Sí

Observaciones -

Campo Autor Etiqueta Autor

Dominio Nombre de la persona o institución responsable intelectual del recurso. En caso de tratarse del nombre de una persona, entrar en forma invertida: Apellido, Nombre

Tipo de datos Alfanumérico

Indización Sí

Lengua Del recurso

Tratam. Docum. NP

Obligatorio No

Observaciones -

Campo Fuente Etiqueta Fuente

Dominio Nombre de la institución o empresa responsable de la edición del recurso en su forma actual

Tipo de datos Alfanumérico

Indización Sí

Lengua Del centro

Tratam. Docum. NP

Obligatorio Sí

Observaciones Ejemplos: Universidad Pompeu Fabra; Institut Català de Tecnología; IBM, etc.

Campo Lugar Etiqueta Lugar

Dominio Topónimo de la institución fuente. A nivel internacional, con indicación del país, por ejemplo, [Francia]. A nivel nacional, con indicación de Ciudad, Comunidad Autónoma y país. Ejemplo: [Barcelona. Cataluña. España]

Tipo de datos Alfanumérico

Indización Sí

Lengua Del centro

Tratam. Docum. NP

Obligatorio Sí. Si no se ha identificado, se indicará así: "no identificado"

Observaciones -

Campo Idioma Etiqueta Idioma

Dominio Lengua del recurso o lenguas del recurso

Tipo de datos Alfanumérico

Indización Sí

Lengua Del centro

Tratam. Docum.

Lenguaje controlado abierto. Lista de valores más frecuentes: Catalán Castellano Francés Inglés

Obligatorio Sí

Observaciones -

Campo Clasificación Etiqueta

Clasificacion

Dominio Indicación sintética de la categoría o categorías temáticas principales del recurso

Tipo de datos Alfanumérico

Indización Sí

Lengua Del centro

Tratam. Docum.

Lenguaje controlado cerrado. Lista de valores admitidos: Arte Cine Cultura Fotografía Humanidades Literatura

Multimedia Música Teatro Televisión

Obligatorio Sí

Observaciones NP

Campo Descriptores Etiqueta

Descriptores

Dominio Términos de indización normalizados

Tipo de datos Alfanumérico

Indización Sí

Lengua Del centro

Tratam. Docum. Lenguaje controlado mediante tesauro

Obligatorio Sí

Observaciones La norma general consiste en asignar tantos descriptores como temas relevantes presente el recurso, siguiendo la norma UNE de creación de tesauros monolingues

Campo Descripción Etiqueta Descripcion

Dominio Descripción textual del tema, contenido, orientación, etc., del recurso

Tipo de datos Alfanumérico

Indización Sí

Lengua Del centro

Tratam. Docum. NP

Obligatorio Sí

Observaciones -

Campo Valoración Etiqueta Valoracion

Dominio Puntuación alcanzada por el recurso, en una escala de 1 a 3

Tipo de datos Numérico

Indización Sí

Lengua NP

Tratam. Docum. NP

Obligatorio Sí

Observaciones -

Campo URL Etiqueta URL

Dominio URL del recurso

Tipo de datos Alfanumérico

Indización Sí

Lengua NP

Tratam. Docum. NP

Obligatorio Sí

Observaciones -

Campo Última visita Etiqueta Visitado

Dominio Fecha de la última vez que fue comprobado el recurso

Tipo de datos Fecha

Indización Sí

Lengua NP

Tratam. Docum. NP

Obligatorio Sí

Observaciones --

Campo Número de registro Etiqueta RecNo

Dominio Número de registro

Tipo de datos Numérico

Indización Sí

Lengua NP

Tratam. Docum. NP

Obligatorio Sí

Observaciones -

Campo Operador Etiqueta Operador

Dominio Primer apellido de la persona que ha entrado los datos

Tipo de datos Alfanumérico

Indización Sí

Lengua NP

Tratam. Docum. NP

Obligatorio Sí

Observaciones --

Campo Fecha de alta Etiqueta Created

Dominio Fecha de creación del registro

Tipo de datos Fecha

Indización Sí

Lengua NP

Tratam. Docum. NP

Obligatorio Sí

Observaciones --

Campo Fecha de modificación Etiqueta Modified

Dominio Fecha de la última modificación del registro

Tipo de datos Fecha

Indización Sí

Lengua NP

Tratam. Docum. NP

Obligatorio Sí

Observaciones --

7.4. Ilustraciones

En las siguientes ilustraciones vamos a ver cómo queda plasmado el diccionario de datos en una base de datos. En este caso, hemos utilizado el programa de gestión documental Idealist.

Figura 1: El menú de implementación del diccionario de datos en Idealist es el menú que permite definir las características de los campos

Observe el alumno que tenemos aquí un menú donde, a la izquierda, tenemos una lista, por orden alfabético, de todos los campos. A la derecha, tenemos las características o parámetros de cada campo: si es un campo de texto, numérico, etc., si es indizado o no, etc. En la ilustración se ha desplegado la lista de valores autorizados para uno de los campos.

Figura 2. Aquí podemos ver cómo queda un registro con los datos de un recurso digital descrito en la base de datos.

7.5. Conclusiones del estudio de caso

En este estudio de caso hemos podido ver cómo un problema de información puede recibir un tratamiento adecuado diseñando una base de datos.

Hemos visto que el proceso incluye considerar o estudiar las características del sistema objeto (SAH + SER), diseñar el diccionario de datos y finalmente, diseñar la base de datos y proceder a la carga de los datos, el mantenimiento, etc.

La idea es que esa base de datos es la herramienta de trabajo del equipo editorial que realiza los análisis y las evaluaciones de las sedes web y gracias a esa base de datos pueden realizar su trabajo con el máximo de seguridad y consistencia.

Para que los datos de esa base de datos sean accesibles a través de la web existen diversas soluciones, que dependen del entorno informático utilizado, pero que podemos resumir en las dos siguientes:

1. Volcado periódico (cada día o cada semana, etc.) de los contenidos de la base de datos en una página con formato HTML y que se coloca en el servidor de la web de Acme. Esto se puede hacer de manera automática mediante formatos de exportación de la base de datos. El acceso y la consulta la harían los usuarios a través de un

navegador convencional (Netscape, Internet Explorer, etc.) y a través de índices, clasificaciones, motor de indización, etc., de la página web

2. Uso de una base de datos documental compatible con un servidor web. En este caso, a través de un navegador convencional, los usuarios podrían consultar directamente la base de datos

Actualmente, la opción más utilizada es la número 2, ya que casi todos los sistemas de gestión de bases de datos documentales tienen versiones compatibles con servidores web.

8. Oferta del mercado de sistemas de gestión de bases de datos documentales

Tabla 1: Algunos de los principales programas de gestión documental -muchos del mercado español-, distribuidos por niveles

Sistemas personales

AskSam www.asksam.com FileMaker www.filemaker.com Knosys www.micronet.es

Sistemas departamentales o pequeña y mediana empresa

FileMaker www.filemaker.com Knosys www.micronet.es Inmagic DB/Text Works www.doc6.es ZyLab www.zylab.com InvesDoc (El Corte Inglés) www.ieci.es

Sistemas corporativos o empresas medianas y grandes

Inmagic DB/Text Works www.doc6.es Notes (Lotus) www-01.ibm.com/software/lotus/ Oracle Text Retrieval www.oracle.com BRS www.baratz.es

9. Conclusiones generales: significado estratégico de las bases de datos y algunos factores para el éxito

A continuación, unas conclusiones generales sobre el significado estratégico de la tecnología documental en los sistemas de información y sobre los factores claves para el éxito en el proceso de producción de un sistema de información basado en una base de datos documental:

1. Las bases de datos documentales son una tecnología preparada para la gestión de información cognitiva. Son también una de las bases tecnológicas principales para la así llamada gestión del conocimiento, al manos para la parte de la gestión del conocimiento vinculada al tratamiento del conocimiento registrado.

2. Las bases de datos documentales utilizan unos modelos de representación de la información distintos del modelo relacional, aunque no es incompatible con él. En el modelo documental, estrechamente basado en las teoría de recuperación de información, la capacidad para crear índices invertidos (índices analíticos) y para poder utilizar controles terminológicos es esencial.

3. En los procesos de creación de bases de datos documentales, el ciclo de vida debe ir siempre desde los elementos más abstractos y generales a los más concretos; así como de los aspectos conceptuales a los aspectos físicos. En la fase análisis, la adecuada comprensión de los componentes, público y objetivos tanto del sistema de

actividades humanas como del futuro sistema de información son esenciales. En la fase de diseño, el diccionario de datos es la herramienta esencial. Después, en el mantenimiento, el diccionario de datos será el libro de estilo que garantizará la calidad y consistencia de la información.

4. En general, cuando se requiere un entorno exigente de control de la información la solución siempre pasa por la combinación de metadatos más tratamiento sistematizado de la información. La eficiencia de las bases de datos descansa, precisamente, en que son herramientas perfectamente preparadas para ambas cosas.

Por último, señalamos los siguientes como algunos de los factores críticos para el éxito en el proceso de producción de una base de datos

• La flecha del proceso. Tomamos esta expresión de la física, donde se habla de la "flecha del tiempo", para indicar que el tiempo siempre corre en una misma dirección: del pasado al futuro, pasando por el presente. En los procesos relacionados con sistemas de información, probablemente, no hay nada tan importante como respetar una flecha que dice que las fases son las siguientes: (1) análisis, (2) diseño, (3) implantación. ¿Significa esto que no podemos revisar alguna cosa del análisis cuando estamos en la fase de diseño? No. Podemos y debemos hacer tal cosa si se presenta la oportunidad, pero esto no desmiente el hecho esencial, que recomiendo repetir como un mantra: "no diseñar sin análisis, no implementar sin diseño"

• El benchmarking. El benchmarking, es decir, el proceso de mejora continua basado en compararnos con nuestra mejor competencia, también tiene sentido en el desarrollo de sistemas de información documentales. En todos los ámbitos de negocio existe la posibilidad de hacer benchmarking, por tanto, también en documentación. Si tenemos el proyecto de desarrollar una base de datos para un fondo de imágenes, ¿porqué no planificar algunas visitas a otros organismos o empresas que ya tengan bases de datos de imágenes?; o, al menos, ¿porqué no hacer un análisis comparativo de bases de datos de imágenes en el mercado?. La experiencia me dice que incluso nuestros colegas de la competencia aceptarán recibirnos y explicarnos parte de su experiencia, sin traicionar ninguna información sensible de su empresa, si somos abiertos, sinceros y demostramos nuestra disposición a estar a la recíproca.

• El diccionario de datos. Nunca se defenderá demasiado la figura del diccionario de datos en los sistemas de información. Una base de datos documental adquiere su valor por acumulación. La información de hoy se acumulará a la información de dentro de cinco o de diez años. Sin un diccionario de datos (y sin la cultura de tenerlo en cuenta), esa base de datos dentro de cinco años puede no valer nada a causa del enorme número de contradicciones y agujeros que tendrá...

• La selección del software. Como hemos señalado antes, no parece haber ninguna manera fiable de seleccionar un buen software basándonos únicamente en sus características técnicas o en una demostración. Se debe considerar, además de las características técnicas, las características de la empresa que está detrás: su experiencia, el número de instalaciones previas, sus salud financiera (aunque no siempre es posible saberlo), su implantación en el mercado, etc. Otro factor de éxito, o más bien que de éxito, de supervivencia, es la adecuación del software a estándares y formatos abiertos de exportación y de importación. Al menos, el programa debe ser capaz de exportar en formato ascii o formato texto con algún método que separe campos y registros de manera fácilmente manipulables, es decir, eligiendo el carácter separador de tales campos. Probablemente, nos convendrá que acepte algún otro estándar, pero esto depende del contexto, como MARC; aunque cada vez más es más importante el formato XML.

• El soporte de la gerencia ¿Porqué razón la gerencia puede aprobar un proyecto y al mismo tiempo no darle soporte? La razón se nos escapa (¿factor humano?), pero es sorprendente el número de proyectos vinculados con sistemas de información que no acaban de salir del todo bien (o que fracasan abiertamente) porque no tienen un apoyo claro de la gerencia. Por eso, ante cualquier proyecto de estas características, recabar

ese apoyo o asegurarse de que el compromiso de la gerencia con el proyecto es sincero antes y durante el proyecto, puede ser absolutamente fundamental.

10. Bibliografía recomendada

Primera advertencia: la bibliografía recomendada para esta unidad contempla dos partes: Fundamentos y Obras recientes. El eje temporal elegido es el año 2000. Por supuesto, no son categorías auto-excluyentes, pero se presentan por separado dado que los fundamentos incluyen obras (artículos y libros) que no son precisamente modernas y, por tanto, pueden ser difíciles de encontrar. Sin embargo, para quien desee profundizar en el tema desde una perspectiva de investigación (o de I+D) son del todo aconsejables. Las obras más recientes incluyen en cambio libros mucho más accesibles, puesto que se trata siempre de referencias posteriores al año 2002, y son las referencias adecuadas para quien desee ampliar conocimientos desde una perspectiva más pragmática y profesional.

Segunda advertencia: en esta bibliografía me autocito. Como autor estoy orgulloso de lo que he escrito y creo en la calidad de mi trabajo, por tanto que nadie se extrañe de que lo haga. Ahora bien, nadie tiene ninguna obligación de hacerme el más mínimo caso. Doy también referencia de otras obras que pueden sustituir perfectamente las mías, o sea que mi propuesta no obliga a nada. Como dijo un participante de la edición del Máster de 2004: ¡viva la libertad! Pero no nos pongamos trascendentes. Aqui van mis recomendaciones, por fin:

Fundamentos (antes del 2000)

BUCKLAND, M. Information and information systems. Westport: Greenwood Press, 1991, 225 pp.

CHEN, P. P-S. "The entity-relationship model: towards a unified view of data". ACM transactions on databases systems, v. 1, n. 1, 1976, pp. 9-36

CODINA, L. "Modelo conceptual de un sistema de información documental". Revista española de documentación científica, v. 17, n. 4, Octubre-diciembre 1994, pp. 44-53

JACKSON, G. A. Introducción al diseño de bases de datos relacionales. Madrid: Anaya, 1990, 203 pp.

POLLIT, A. S. Information storage and retrieval systems: origin, development and applications . Chichester: Ellis Horwood, 1989, 175 pp.

SOERGEL, D. Organi../imgdocs/758/ZINg information: principles of data base and retrieval systems. Orlando: Academic Press, 1985, 450 pp.

WILLITTS, John. Database design and construction: an open learning course for students and information managers . London: Library Association Publishing , 1992 , 425 pp.

YOURDON, E. Análisis estructurado moderno. México: Prentice-Hall Hispanoamericana, 1993, 735 p

Obras recientes (a partir del 2000)

ABADAL, E.; CODINA, L. Bases de datos documentales: características, funciones y método. Madrid: Síntesis, 2005.

BLAIR, David C. "The challenge of commercial document retrieval, Part I: Major issues, and a framework based on search exhaustivity, determinacy of representation and document collection size". Information Processign and Management, v. 38, 2002, p. 273-291

CELMA, M.; CASAMAYOR, J.C.; MOTA, L. Bases de datos relacionales. Madrid: Pearson, 2003, 285 p.

SILBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Fundamentos de bases de datos. Madrid: McGraw-Hill, 2002, 787 p.

© Master en Documentación Digital (IDEC-UPF) 29/09/2010