Está en la página 1de 3

Algunas reflexiones sobre los Modelos de Datos

a los 35 años de su introducción


---
TRABAJO PREPARADO PARA EL 1ER. CONGRESO URUGUAYO DE INFORMÁTICA
Copyright © 1997 Breogán Gonda y Nicolás Jodal, todos los derechos reservados
Download it from: www.genexus.com/whitepapers

Resumen
El mundo de las Bases de Datos es un mundo raro, a veces muy avanzado, a veces muy conservador.
El modelo E-R es el generalmente utilizado por la industria y el estudiado en la universidades. Sin embargo
los autores consideran que ese modelo presenta severas limitaciones y, partiendo de esas limitaciones, han
trabajado desde hace ya bastante tiempo con un modelo alternativo que les ha permitido un conjunto de
logros.
Este trabajo tiene como objetivo motivar a la comunidad académica uruguaya para la investigación de
opciones alternativas.

Reflexiones
Los Modelos de Datos desde el principio han estado vinculados a los Sistemas de Gerencia de Base de
Datos y, en particular, a sus limitaciones estructurales. Parece razonable considerar como antecesor de los
demás al introducido informalmente por Charles Bachman asociado a su IDS (1963), primer Sistema de
Gerencia de Base de Datos en el mercado mundial.
El Modelo de Bachman consta de dos tipos de elementos: Archivos y Relaciones Jerárquicas entre ellos.
Los archivos eran, en sus primeras implementaciones, accesibles en forma aleatoria por llave primaria y las
relaciones jerárquicas eran implementadas por listas de pointers simples o bidireccionales que ligaban a
cada registro “padre” con todos sus registros “hijos”. ¿Por qué Bachman pensó únicamente en esos
elementos? probablemente porque eran los únicos a los que se sabía dar una implementación
computacional.
En 1976 Peter Chen introdujo su Modelo de Entidades y Relaciones (E-R). En rigor la pretensión de Chen
fue bastante mayor que la de Bachman: Chen era un teórico mientras que Bachman era un constructor de
Sistemas de Gerencia de Base de Datos. Chen tuvo el objetivo de dotar al modelo de semántica y soportar
otros tipos de relaciones.
La comunidad académica acogió muy bien las ideas de Chen mientras olvidó a Bachman. Una pregunta
obvia, sin embargo es ¿son los modelos de Bachman y Chen esencialmente diferentes?. No parece porque
ambos comparten limitaciones muy importantes que están muy ligadas a su historia, a su parentesco con la
implementación física de las Bases de Datos lo que, por otra parte, era muy razonable en el modelo de
Bachman pero no lo es en la situación actual.
¿Cuales son esas limitaciones?.
En un modelo E-R, asociados a una entidad E1 tenemos un conjunto de dependencias funcionales:
A Æ B, C, D, E
lo que, en definitiva tiene un sentido muy físico: la entidad generalmente la representamos en la Base de
Datos como una tabla donde A, B, C, D y E son columnas y A es la llave primaria.
O sea: dada una entidad tenemos una transformación muy simple para obtener el correspondiente archivo
de la Base de Datos. Al mismo tiempo si tenemos otra entidad
E2 donde BÆ F, G
probablemente existirá una relación 1:n entre E2 y E1 a través del atributo B.
Desde luego que esto es cierto siempre que se adopte una convención de nombres que trate de recoger la
semántica (por ejemplo, utilizando la URA: Universal Relation Assumption). Si eso no es así
probablemente
E2 contendrá XÆ Y, Z
pero el resto será muy parecido (como en el caso anterior E1 estará subordinado a E2 según la restricción
E2.X = E1.B).
Lo anterior puede parecer muy natural. Sin embargo la representación E-R tiene menos poder expresivo
que la constituida por el conjunto de las dependencias funcionales, como puede verse a continuación:
Supongamos el modelo constituido por el conjunto de las dependencias funcionales conocidas (FDM). En
este modelo es esencial representar la semántica del modelo mediante los nombres de los diferentes
elementos.
En el caso anterior tenemos las dependencias funcionales
A Æ B, C, D, E
BÆ F, G
y, si no sabemos nada más, representarlas en una Base de Datos nos llevará a las tablas
E1(A, B, C, D, E)
E2(B,F,G)
y a la restricción de integridad E1.B = E2.B. Hasta aquí estamos coincidiendo con el modelo E-R.
Sin embargo, es bien posible que posteriormente aparezca una nueva dependencia funcional:
CÆ D, E
¿qué ocurre ahora?.
Nuestro FDM es incremental, tan sólo debemos agregar el nuevo conocimiento y quedará
A Æ B, C, D, E
BÆ F, G
CÆ D, E
No se produce inconsistencia alguna porque los hechos
AÆ D, E
CÆ D, E
son totalmente consistentes. El hecho de que, por ejemplo,
CÆ D
A ÆC
ÎAÆD
no obsta a esa consistencia.
¿Qué ocurre en el mismo caso con el Modelo E-R?. Debe modificarse. Ahora existirán tres entidades: la
nueva E3, la E2 vista, una transformada de la E1 que tiene ahora sólo los atributos A, B, C y dos relaciones
1:n E1 estará subordinada a E2 según la restricción E2.B = E1.B y a E3 según la restricción E3.C = E1.C.
¿Que ocurre con las especificaciones de los programas confeccionados partiendo del modelo E-R que
utilizan D o E?. Dejarán de ser correctas y deberán ser modificadas manualmente.
Desde luego que los programas correspondientes, escritos en lenguajes de 3a. o 4a. generación dejarán de
funcionar pero el asunto es más grave: todo lo que se haga con esas especificaciones, a cualquier nivel,
dejará de ser correcto. Este hecho no es irrelevante: es una de las mayores causas de los altísimos costos de
mantenimiento de sistemas que se experimentan actualmente.
Es bueno considerar otro elemento importante: el modelo de dependencias funcionales representa bien las
tradicionales dependencias funcionales tabulares soportadas directamente por los Sistemas de Gerencia de
Base de Datos pero, de la misma manera, permite representar también fórmulas y con pequeñas
extensiones, reglas y eventuales redundancias.
El modelo FDM es incremental. Si conseguimos especificar los programas en función de él esas
especificaciones permanecerán válidas cuando se adicionen o eliminen dependencias funcionales. Dicho de
otra manera, esas especificaciones no perderán su validez cuando se produzcan modificaciones
estructurales en la Base de Datos.
Un inconveniente de este modelo, analíticamente claro, es ser bastante difícil de visualizar. Sin embargo es
posible, en cualquier momento a partir de él, generar el diagrama de Bachman que lo representa total o
parcialmente (o, lo que tiene dificultad equivalente, generar el esquema de la Base de Datos asociada para
un determinado Sistema de Gerencia de Base de Datos). Nótese que, en un modelo real de varios cientos
de entidades la visualización debe, de todas maneras, parcializarse.
Por otra parte, aunque podamos especificar nuestros procesos a nivel de este modelo, los programas, con
las tecnologías actualmente disponibles, deberán referirse a archivos. Podemos, en el momento en que
queremos generar nuestros programas, determinar cuales son las tablas de la Base de Datos que deben
utilizar y usar esas tablas en la generación de dichos programas (desde luego que esto es especialmente útil
cuando se trata de generación automática).

Conclusiones
Se propone utilizar como modelo el conjunto de las dependencias funcionales conocidas (FDM).
Obviamente deben encontrarse maneras inteligentes de representar dichas dependencias funcionales de
manera de operar con ellas fácilmente, a pesar de que se enfrenten modelos reales que contienen miles de
dependencias funcionales y cientos de tablas.
Partiendo de este modelo se pueden obtener en forma automática esquemas de Base de Datos y diagramas
de Bachman (sensiblemente equivalentes a los diagramas E-R) que permitirán una visualización total o
parcial del modelo.
De la misma manera, en el momento de la generación de los programas, puede determinarse cuales son los
archivos involucrados y utilizarlos adecuadamente en esos programas.
Podemos tener especificaciones de procesos independientes unas de otras y todas ellas de la estructura de la
Base de Datos y, en consecuencia, estas especificaciones se mantendrán válidas ante modificaciones
estructurales en la Base de Datos (por adición o eliminación de dependencias funcionales) y, en
consecuencia, el mantenimiento de las aplicaciones puede ser automático.

Curricula de los autores


Breogán Gonda y Nicolás Jodal son Ingenieros de Sistemas formados por la Facultad de Ingeniería de la
Universidad de la República, han desarrollado una intensa actividad docente y de consultoría, han recibido
el Premio Nacional de Ingeniería 1995, otorgado por la Academia Nacional de Ingeniería, por el Proyecto
Genexus (que utiliza los conceptos expuestos en este trabajo) y son socios fundadores y directores de
ARTech y Genexus Consulting en el Uruguay y de Genexus, Inc. en EE UU.

También podría gustarte