 |
Antes de empezar, nos parece importante señalar que en este apartado emplearemos el término información de la manera más genérica posible. Así, dicha información puede consistir en un conjunto de datos sobre cualquier entidad (autores, libros, personas, pacientes, contabilidad, etc.) o puede tratarse también de fragmentos de audio, imágenes, textos, películas, etc.
La manera habitual de almacenar información en un ordenador es mediante el uso de ficheros. Sin embargo, cuando se gestionan grandes cantidades de información es preciso contar con algún tipo de estructuración, bien del conjunto de ficheros o de la información que guardamos en ellos. En caso contrario invertiremos gran parte del tiempo en tareas poco productivas, que tienen más que ver con la (des)organización de la información que con los objetivos finales de nuestro trabajo.
Un ejemplo de entorno profesional donde se gestiona mucha información en un corto período de tiempo es el control de la producción de una obra multimedia: ficheros de texto en su primera o segunda versión, los mismos ficheros validados, una nueva versión corregida, elementos multimedia asociados a uno o diversos nodos de información, etc.
Un caso como este os puede plantear múltiples interrogantes, como por ejemplo:
De entre todos los ficheros de autores, ¿dónde encuentro la última versión de este artículo? ¿Es la versión definitiva la que hay en este fichero? ¿Se ha revisado ya este artículo? ¿Los elementos multimedia que ha pedido el autor se han desarrollado según lo previsto? ¿Hemos enviado una orden de pago al departamento financiero para que pague al autor?
Si el proyecto en cuestión consiste en una obra de 500 páginas con 100 elementos multimedia y 10 autores, estas preguntas no pueden responderse confiando únicamente en nuestra memoria. Normalmente, como editores multimedia, estaremos trabajando en varias obras de manera simultánea. Además es probable que contemos con colaboradores externos: lo que menos deseamos es que nos estén preguntado constantemente o que se nos pasen por alto cuestiones importantes que los colaboradores ya tienen resueltas.
Una posible manera de organizar grandes volúmenes de información sería definiendo una especie de fichas, como las que se emplean en una biblioteca para catalogar los libros. Dichas fichas se denominan técnicamente registros, y están formados por diferentes unidades semánticamente indivisibles a las que se denomina técnicamente campos. La granularidad en la definición de los campos depende de criterios de diseño de la tabla, los cuales implican una diferente funcionalidad según las aplicaciones que la usen. Estos criterios de diseño no deben confundirse con los criterios de diseño gráfico, sino que se refieren a la información y a las posibles interrelaciones de los datos de una tabla.
Se puede considerar una dirección como un campo con el contenido «Avenida del Parque, 33, 5.° 2.ª, San Agustín de Puebla», o bien, el mismo contenido puede dividirse en varios campos: vía, número, piso, puerta, población. De este modo se podrán o no ordenar los registros por población de manera sencilla.
Los sistemas de bases de datos organizan los diferentes registros manteniendo un conjunto de interrelaciones entre ellos. Se dice que dos o más registros de una base de datos están interrelacionados si hay campos en un registro que provienen de otro, de manera que se establece un vínculo entre la información contenida por ambos.
Se puede establecer una interrelación entre los datos personales de los empleados de una empresa (nombre, dirección, DNI/pasaporte, etc.) y los cargos dentro de la empresa (director, contable, editor, etc.).
Adicionalmente, los sistemas de bases de datos ofrecen un conjunto de procedimientos para recuperar y modificar el contenido de la información almacenada, manteniendo su coherencia gracias a un conjunto de reglas definidas por el diseñador de la base de datos. Toda la información necesaria para este cometido se deposita en una serie de ficheros que, en principio, sólo el sistema de base de datos sabe interpretar.
En la base de datos de la bibliografía de mi departamento hay seiscientos registros, que corresponden a los seiscientos libros que tenemos en las estanterías. Cada uno de estos registros tiene campos: título, autor, editorial, año de edición, lugar de edición, ubicación en el departamento, categoría, subcategoría, persona que lo tiene en préstamo y día de devolución.
Redundancia lógica y redundancia física
Uno de los mayores peligros que puede surgir al organizar información es la duplicación.
Incoherencia entre los ficheros del sistema de almacenamiento: si durante la actualización de un dato (por ejemplo, la dirección de un autor), éste está duplicado y no se actualiza en todos los ficheros en los que está presente, el conjunto de información presentará incoherencias (podría suceder que un cliente tuviera asociadas varias direcciones y no supiéramos cuál de ellas es la correcta).
Incremento de las necesidades de almacenamiento y de los tiempos de procesamiento: se utiliza más espacio de almacenamiento del imprescindible y, si el volumen de redundancia es elevado, se aumentarán el coste de los discos y el tiempo de procesamiento de la información, tanto en procesos productivos (generación de facturas, contabilidad, etc.) como en procesos de administración del sistema informático (por ejemplo, copias de seguridad en cinta).
Las técnicas de bases de datos fueron desarrolladas para intentar solucionar el problema de la redundancia. Para ello básicamente se establecen, dentro del sistema de base de datos, una serie de normas de diseño y mecanismos automáticos de control que dificultan la aparición de redundancias. Sin embargo, no perdamos de vista que la redundancia es un concepto semántico, y que cobra sentido según se interpretan los datos: aunque trabajemos con una base de datos de última generación, un mal diseño puede provocar redundancias indeseables.
La redundancia evidente es la comentada hasta ahora y se denomina redundancia lógica. Su aparición se debe a:
La información introducida en el ordenador ya presenta redundancias que no son eliminadas.
Un autor nos envía su última versión de un artículo. Por error envía el documento dos veces. Si no tenemos constancia de que ya habíamos recibido previamente su última versión y de que no esperábamos recibir más artículos por su parte, probablemente guardaremos los dos ficheros de contenido idéntico.
Un diseño incorrecto del conjunto de aplicaciones.
El departamento de administración mantiene un fichero de clientes, mientras que el departamento de marketing mantiene un fichero de clientes potenciales. Hay clientes potenciales que se acabarán convirtiendo en clientes. Imaginemos que un cliente cambia sus datos. Puede ser que lo notifique al departamento de administración, pero puede suceder también que el departamento de marketing se aperciba del cambio de dirección al adquirir un fichero de direcciones de un colectivo (por ejemplo, al comprar la actualización de los datos profesionales de las empresas del sector alimentario de España).
Debido a la duplicación de datos, al tener los datos de la misma persona en el fichero de clientes y en el fichero de clientes potenciales, los errores pueden ser múltiples.
La solución menos elaborada consistiría en realizar un costoso mantenimiento de las discrepancias entre ambos ficheros, ya sea de forma manual (comunicándose los cambios entre departamentos), ya sea de manera automática (generando los procesos informáticos adecuados).
Sin embargo, la solución ideal sería diseñar un sistema en el que los datos de una persona aparecieran en un solo fichero y hubiera dos réplicas de este fichero en las que se pudiera catalogar a una persona desde el punto de vista de cliente o desde el punto de vista de cliente potencial.
Por lo explicado hasta aquí quizá parezca que la redundancia de datos es un error que debe ser erradicado de nuestros ordenadores a cualquier precio. Sin embargo, en algunas ocasiones la redundancia puede ser útil. Por ejemplo, podemos servirnos de la denominada redundancia física como recurso de diseño para reducir tiempos de cálculo de un valor costoso de obtener y cuya validez es considerablemente larga en el tiempo.
Podríamos mantener cada una de las versiones de los artículos que escriben los autores, a la vez que un registro de las modificaciones que se han introducido entre dos versiones consecutivas. Estamos duplicando información. Sin embargo, si sólo guardásemos las versiones finales, posteriormente sería costoso averiguar qué modificaciones se han introducido. Si, por el contrario, se almacena tan sólo la última versión y el registro de cambios, recuperar una versión intermedia también resultaría costoso.
