El profesional de la información


Noviembre 1994

Bases de datos relacionales: qué son y qué aportan a la gestión de información

Por Lluís Codina

Ahora que se ha puesto de moda atacar a las bases de datos relacionales con la discutible oportunidad de los sistemas orientados a objeto, puede ser un buen momento para examinar esta tecnología, basada en uno de los más elegantes y sólidos modelos que ha producido la informática desde que existen las bases de datos.

Para comprender la tecnología relacional, sin embargo, será útil introducir un poco de jerga, algunos conceptos de la gestión de ficheros y situar todo esto en su entorno natural: la gestión de los datos corporativos.

Ficheros y registros

Un fichero es un conjunto de registros. Un registro es el equivalente informático a una ficha. Los registros se componen de campos, que son las zonas de información en las que se articula un registro. Los registros y los ficheros son unidades de trabajo básicas en informática, y no sólo en el terreno de las bases de datos. Los ficheros y los registros se usaban antes de que existieran aquellas y se usan, en general, en cualquier situación donde sea necesario estructurar conjuntos de datos. Por ello, hay aplicaciones informáticas que son capaces de crear y gestionar ficheros, es decir, que permiten definir estructuras de registros, dar registros de alta, recuperarlos, modificarlos, etc.

Por su parte, una base de datos es un conjunto de ficheros, aunque pueden existir bases de datos compuestas por un solo fichero. Desgraciadamente, en la literatura que genera la industria del software esta diferencia semántica se ha perdido, de manera que, de facto, los términos fichero y base de datos se utilizan como sinónimos en bastantes contextos.

Ficheros planos

Algunos programas pueden trabajar solamente con un fichero a la vez (esto es, sólo pueden tener un fichero abierto y cargado en la memoria RAM a la vez), mientras que otros programas pueden trabajar con varios. Solamente estos últimos son, en rigor, sistemas de gestión de bases de datos (sgbd), mientras que los primeros son sistemas de gestión de ficheros (sgf).

Con ambas clases de programas se puede articular la información de la empresa en varios ficheros distintos, pero sólo los sgbd pueden cruzar datos entre ellos y generar nuevos ficheros con la información seleccionada.

Por qué se divide la información

La información se mantiene en ficheros separados porque ello facilita su mantenimiento: los datos son independientes de su utilización concreta y, así, los mismos datos pueden utilizarlos distintos departamentos de la empresa, sin necesidad de volver a entrarlos para cada proceso. De esa manera, puede existir un almacén de datos unificados a disposición de todos los departamentos de la empresa, aunque cada uno tenga una visión de ellos acorde con sus necesidades. La existencia de este almacén central de datos aporta muchas ventajas prácticas, porque además de facilitar mucho su utilización, evita la aparición de inconsistencias y hace más sencillo su mantenimiento.

Pongamos un ejemplo: cuando el departamento de ventas emite una factura, utiliza datos que obtiene de distintos ficheros: del fichero de clientes, del fichero de productos y del fichero de vendedores, por ejemplo. Otros departamentos, como el de contabilidad, utilizarán algunos datos de algunos de estos mismos ficheros. Lo mismo sucede con el departamento de marketing, el de gerencia, etc. Lo que no resulta competitivo, actualmente, es que cada uno de estos departamentos mantenga sus propios ficheros con los mismos datos, ni que cada vez que haya que ejecutar una aplicación se tenga que introducir esos datos, etc.

Separar para integrar

En resumen, el punto crítico aquí es el siguiente: mantener información útil para toda la empresa implica que los datos deben articularse en distintos ficheros, pero, para poder obtener algo útil de todo ello se necesita un programa capaz de seleccionar datos de distintos ficheros.

Los sgbd son esa clase de programas y para realizar su función se han utilizado históricamente (y se utilizan aún) diferentes estructuras de ficheros, y, así, por ejemplo, antes del sistema relacional se utilizaban los modelos jerárquico y en red.

El modelo relacional, por tanto, es una más de esas estructuras. Su aportación consiste en proponer un modelo basado en la teoría de conjuntos, concretamente en el concepto conjuntista de relación, así como en definir un álgebra que permite realizar operaciones con ficheros que generan nuevos ficheros. El padre intelectual de este sistema fue E. F. Codd, un investigador que desarrolló el modelo en los años 70 cuando trabajaba para unos laboratorios de IBM.

El modelo pronto despertó expectación por su elegancia y otros teóricos realizaron interesantes aportaciones, como P. Chen, quien propuso un sistema para analizar la información y dividirla en ficheros basado en los conceptos de entidad y relación. En poco tiempo, si lo comparamos con el tiempo que tardaron otros desarrollos teóricos en llegar al mercado, la industria fue capaz de ofrecer programas relacionales que proporcionaban a las empresas un medio seguro para el almacenamiento de todos sus datos corporativos.

El prestigio de los sistemas relacionales no dejó de crecer, hasta el punto en que, hoy, para la mayor parte de los informáticos hablar de bases de datos es hablar de sistemas relacionales, como si no existieran, ni hubieran existido nunca, otras estructuras de ficheros.

Los elementos del modelo

Los elementos conceptuales del modelo con los cuales se construyen bases de datos relacionales son los siguientes: los datos se organizan en ficheros, que se denominan tablas. Las tablas se consideran estructuras bidimensionales homogéneas (matrices) compuestas por filas y columnas. Cada tabla está formada por un número fijo de columnas y por un número variable de filas. Las filas se denominan tuplas, cada tupla es un registro, y cada registro representa a una entidad del mundo real; las columnas, por su parte, son los campos del registro, que representan a los diversos atributos de la entidad. El conjunto de los valores que puede adoptar una columna se denomina su dominio.

En resumen, puede hacerse la siguiente identificación de términos: registro es equivalente a fila, a tupla y a entidad. Columna equivale a campo y a atributo de entidad. Tabla es sinónimo de fichero.

Los diversos nombres para designar (casi) a la misma cosa, no responden a una mera cuestión académica, sino que reflejan los diversos puntos de vista que pueden adoptarse ante el mismo problema. Por ejemplo, desde el punto de vista informático, se hablará de registros; pero el diseñador del sistema, en cambio, pensará en entidades del mundo real, etc. Las columnas no pueden tener valores repetidos ni valores compuestos, ni pueden existir tampoco dos filas repetidas. De esta manera, una relación se puede definir, en términos de teoría de conjuntos, como el conjunto de las tuplas ordenadas (filas) en donde los valores de las tuplas son los elementos que pertenecen a una serie de conjuntos llamados dominios.

Formas normales de las tablas

El álgebra relacional especifica entonces las diversas operaciones que pueden realizarse con las tablas, las cuales generan nuevas tablas. La base para realizar operaciones con dos tablas (cruzar datos) radica en la existencia de por lo menos una columna en ambas tablas cuyos elementos pertenezcan al mismo dominio. Sin embargo, para que las operaciones relacionales se comporten de la forma prevista por el álgebra, las tablas deben estar construidas de acuerdo con unas especificaciones concretas, y de las tablas así construidas se dice que están normalizadas.

Esta normalización admite varios grados, y cada grado subsume al anterior, debiendo estar una tabla por lo menos en tercera forma normal (third normal form, o 3NF) para que acepte operaciones de álgebra relacional sin generar anomalías. Estar en 1NF (first normal form), por ejemplo, significa que los valores de cada columna son atómicos, es decir, que no se pueden descomponer más. Por ejemplo, un campo que admita valores como Nombre, dirección, población no es atómico.

Para estar en primera forma normal esta columna deberá descomponerse en varias columnas, por ejemplo, (Apellido 1), (Apellido 2), (Dirección), (Población), etc.

Por la misma razón, un campo con valores como (Descriptor 1, Descriptor 2..., Descriptor N) tampoco estaría en 1NF, y en su lugar deberían crearse las columnas (Descriptor 1), (Descriptor 2)..., (Descriptor N), es decir, tantas como descriptores se prevé que puedan llegar a asignarse.

Todas las formas normales intentan asegurarse de que cuando se produzcan altas, bajas y modificaciones en una tabla, así como cuando se creen tablas nuevas combinando filas y columnas, no se pierda información ni se produzcan las temidas anomalías, cuya aparición está matemáticamente garantizada si las tablas no cumplen la forma normal.

La gestión documental

Bien, pero, ¿qué tiene que ver todo esto con la gestión de documentos? La respuesta es que no tiene nada que ver.

Para gestionar documentos, o si se prefiere, para explotar la información contenida en documentos científicos, culturales y técnicos, la tecnología relacional no aporta nada. Digámoslo de nuevo, por si alguien cree no haber leído bien: el modelo relacional solamente aporta desventajas para explotar el conocimiento registrado en grandes volúmenes de información textual.

En cambio, es el mejor instrumento para cualquier otra situación que pueda darse en un servicio de información, por ejemplo, para gestionar directorios o guías, para gestionar los datos de los usuarios y las adquisiciones de documentos, etc., es decir, en general, para situaciones en las cuales se manejan datos (fechas, nombres, valores numéricos, etc.) más que información (documentos científicos, técnicos o culturales, relatos textuales, etc.).

Una forma alternativa de enfocar este asunto es la siguiente: la tecnología relacional es la manera más eficiente de gestionar los datos necesarios para automatizar una actividad, por ejemplo, para automatizar el sistema de adquisición de documentos, que es una actividad que involucra acciones como aceptar desideratas de los usuarios, cursar pedidos a los proveedores, comprobar órdenes de pago, reclamar documentos, cursar devoluciones, etc. En cambio, la tecnología relacional no sirve para automatizar la representación y/o la extracción de conocimiento de un depósito de información textual ni, por la misma razón, para representar necesidades de información de los usuarios de un sistema documental. En realidad, el modelo relacional nunca se diseñó para otra cosa que para modelar actividades que generan una serie de datos que el sistema debe recordar durante algún tiempo para poder funcionar correctamente (recuérdese el ejemplo de la facturación citado antes).

Para representar y explotar el conocimiento registrado han existido otros modelos, tanto anteriores como posteriores al modelo relacional, con el que ninguna relación han mantenido.

Las primeras bases de datos documentales datan de antes de la aparición del modelo relacional, y el concepto de hipertexto y el de recuperación probabilística, tal como los conocemos ahora, son posteriores al modelo relacional. Es decir, modelar actividades y explotar fondos de conocimiento registrado son realidades distintas que responden a lógicas diferentes y que tienen soluciones tecnológicas distintas.

Es cierto que existen situaciones en las que es útil disponer de una herramienta que combine el modelo relacional y el modelo documental. Por ejemplo, las bibliotecas gestionan adquisiciones y préstamos de documentos y, al mismo tiempo, necesitan automatizar su catálogo. Pero esto sólo confirma que debe aplicarse la tecnología adecuada a cada dominio, so pena de reducir severamen­te las prestaciones en alguno de ellos, y eso es exactamente lo que sucede con sistemas relacionales que automatizan catálogos, o lo que sucedería si a alguien se le ocurriera automatizar la gestión administrativa con sistemas documentales.

Ll. C. UPF. Passeig de Circumval.lació 8, 08003 Barcelona.

Tel.: +34-3-542 22 65; fax: 542 23 72

Bibliografía recomendada:

Austing, R. H.; Caseel, L. N. Gestión de ficheros: organización y métodos de acceso. Madrid: Anaya, 1991.

Chen, P. "The entity relationship model ─towards a unified view of data". ACM trans. database systems, (1) 1, p. 9-36, 1976.

Codd, E. F. "A relational model of data for large shared data banks". Comm. ACM, 13, 377-387, 1970.

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

Tort, J. et al. "Un modelo de datos: el modelo entidad‑relación". Novática, (xviii) 95, 1991, p. 13-23.

Enlace del artículo:
http://www.elprofesionaldelainformacion.com/contenidos/1994/noviembre/bases_de_datos_relacionales_qu_son_y_qu_aportan_a_la_gestin_de_informacin.html