1.

2 Alternativas al uso de un RDBMS

Las alternativas al uso de un RDBMS son numerosas, podemos enumerar a los registros
manuales en carpetas y folios, o ya computarizados, los archivos de datos que deben ser
grabados, modificados, borrados y ordenados por programas, lo que requiere de horas de
programación y lo que podría resumirse en que continuamente se estaría inventando la Rueda.

También es posible pensar en herramientas informáticas como planillas de cálculo, donde

podemos armar tablas con filas y columnas, pero hay que recordar lo que dicen las restricciones
de una tabla para poder llamarse relacional: no se deben aceptar filas vacías ni repetidas.
Estas herramientas las aceptan, por lo que hay que distinguir que estamos usando soluciones no
‘Relacionales’, perdiendo de hecho con las propiedades que este modelo y que sus soluciones
tienen limitaciones, pudiendo dar lugar a errores e inconsistencias. Pese a esto, es muy difundido
el uso de planilla de cálculo para resolver problemas de proveer información, pero es un error
considerarlas Bases de Datos Relacionales o al menos pensar, que es la mejor forma de resolver
problemas complejos, ya que no están diseñados para grandes volúmenes y para acceso
concurrente de múltiples usuarios a modificar. El análisis más detallado de este tipo de soluciones,
siempre llega a que se complica su mantenimiento y se corre el riesgo de una posible pérdida o
inconsistencia de información.

Otros problemas que pueden observarse en estos sistemas, en primer lugar, el no soportar a
múltiples usuarios intentando actualizar el mismo archivo, sin el mecanismo adecuado, genera
errores, actualizaciones incompletas, que nos llevan a la Inconsistencia de información. En
segundo lugar está el manejo de transacciones, el movimiento bancario de un cliente requiere
más de un cambio en el conjunto de datos, el tratamiento de varias operaciones necesarias para
realizar el cambio, debe ser monolítica o indivisible y usando este ejemplo típico, si la
transferencia de un monto de dinero es de una cuenta a otra del mismo banco, tiene dos partes,
que deben confirmarse o cumplirse completamente, no acepta partes, el débito en la cuenta
origen y el crédito en la de destino. Si por algún problema no se puede cumplir el crédito, se debe
programar el borrado del débito inicial… si no se logra esta solución, la inconsistencia se hace
presente, debité un monto y nunca se acreditó ese monto, todos perdieron.

Estos problemas son muy habituales y constituyen ejemplos de las numerosas situaciones de
transacciones y accesos simultáneos que ya fueron solucionados en los motores de bases de
datos, sin necesidad de programarlos en la aplicación, una y otra vez, y dando seguridad de su
efectividad. Estos factores generaron que, masivamente, se diera la adopción de los motores de
bases de datos relacionales o RDBMS.

Otra forma de ver los sistemas alternativos a los relacionales es reconocer los antecesores, el
modelo Jerárquico y el modelo de Red, como veremos a continuación.

El modelo Jerárquico [Wikipedia,2009b]

“Una Base de datos jerárquica es un tipo de Sistema Gestor de Bases de Datos que, como su
nombre indica, almacenan la información en una estructura jerárquica que enlaza los registros en
forma de estructura de árbol (similar a un árbol visto al revés), en donde un nodo padre de
información puede tener varios nodos hijo.

Materia: Base de Datos I -1-

Profesor: Calixto Maldonado
Esta relación jerárquica no es estrictamente obligatoria, de manera que pueden establecerse
relaciones entre nodos hermanos. En este caso la estructura en forma de árbol se convierte en
una estructura en forma de grafo dirigido.

Las bases de datos jerárquicas fueron concebidas en los años 1960. El primer metamodelo de
base de datos propuesto fue la mencionada Base de datos en red, concebida bajo el auspicio de
CODASYL (COnference on DAta SYstems Languages). Posteriormente se refinó la idea dando
lugar a la base de datos jerárquica. La primera implementación de este metamodelo fue IMS
(Information Management System). Se trata de un diseño de IBM y otros colaboradores en 1966
para el Programa Apollo de la NASA. IMS aún se encuentra activo. El sector de la banca y las
Administraciones Públicas adoptaron rápidamente esta tecnología, sin la cual, no hubiese sido
posible el grado de automatización que tienen hoy día. Estos sectores eran los únicos con
capacidad económica suficiente para adquirir los enormes mainframe para la automatización de
bases de datos, única solución posible en la época.

Los sistemas gestores de bases de datos relacionales han reemplazado a las bases de datos
jerárquicas hoy día, pero no completamente. La mayoría de las antiguas bases de datos
jerárquicas de bancos y Administraciones Públicas aún siguen en actividad. Esto se debe a que el
rendimiento de las bases de datos jerárquicas sigue sin ser superado por las bases de datos
relacionales. Además estos sectores sufren un gran volumen de transacciones. Obsérvese, por
ejemplo, la cantidad de apuntes contables que requiere una red de cajeros automáticos en un solo
día.

Actualmente, la base de datos de IBM, DB2 versión 9.5, combina en una base de datos híbrida, la
convivencia del enfoque relacional junto con el Jerárquico para ser utilizados en la gestión de
datos usando XML (eXtensible Markup Language), un lenguaje de integración de aplicaciones que
promete ser una tendencia muy marcada en las futuras implementaciones de Bases de datos y
que es jerárquico.

Cómo funcionan las bases de datos Jerárquicas

A diferencia del modelo relacional, el modelo jerárquico no diferencia una vista lógica de una vista
física de la base de datos. De manera que las relaciones entre datos se establecen siempre a
nivel físico, es decir, mediante referencia a direcciones físicas del medio de almacenamiento
(sectores y pistas).

Los datos se almacenan en la forma de registros, el equivalente a las filas del modelo relacional.
Cada registro consta de un conjunto de campos, el equivalente a las columnas del modelo
relacional. Un conjunto de registros con los mismos campos se denomina fichero (record type,
en inglés), el equivalente a las tablas del modelo relacional.

El modelo jerárquico facilita relaciones padre-hijo, es decir, relaciones 1:N (de uno a varios) del
modelo relacional. Pero a diferencia de éste último, las relaciones son unidireccionales. En
justicia, dichas relaciones son hijo-padre, pero no padre-hijo. Por ejemplo, el registro de un
empleado (nodo hijo) puede relacionarse con el registro de su departamento (nodo padre), pero
no al contrario. Esto implica que solamente se puede consultar la base de datos desde los nodos
hoja hacia el nodo raíz. La consulta en el sentido contrario requiere una búsqueda secuencial por
todos los registros de la base de datos (por ejemplo, para consultar todos los empleados de un
departamento). En las bases de datos jerárquicas no existen índices que faciliten esta tarea.

Materia: Base de Datos I -2-

Profesor: Calixto Maldonado
Obsérvese que, a priori, no existen relaciones N:M (de muchos a muchos) en el modelo
jerárquico. Salvo que se simulen mediante varias relaciones 1:N. No obstante, esto puede
provocar problemas de inconsistencia, ya que el gestor de base de datos no controla estas
relaciones.

Como ya se ha mencionado, las relaciones se establecen mediante punteros entre registros. Es

decir, un registro hijo contiene la dirección física en el medio de almacenamiento de su registro
padre. Esto tiene una ventaja fundamental sobre las bases de datos relacionales: el rendimiento.
El acceso de un registro a otro es prácticamente inmediato sin necesidad de consultar tablas de
correspondencia.

Las relaciones jerárquicas entre diferentes tipos de datos pueden hacer que sea muy sencillo
responder a determinadas preguntas, pero muy difícil el contestar a otras.

Limitaciones del modelo jerárquico

A continuación se mencionan los problemas típicos de las bases de datos jerárquicas y que no
existen en las bases de datos relacionales. Todos estos problemas derivan del hecho de que el
sistema gestor de base de datos no implementa ningún control sobre los propios datos, sino que
queda en manos de las aplicaciones garantizar que se cumplen las condiciones invariantes que se
requieran (por ejemplo, evitar la duplicidad de registros). Dado que todas las aplicaciones están
sujetas a errores y fallos, esto es imposible en la práctica. Además dichas condiciones suelen
romperse ex profeso por motivos operativos (generalmente, ajustes debidos a cambios en el
negocio) sin evaluarse sus consecuencias.

Duplicidad de registros
No se garantiza la inexistencia de registros duplicados. Esto también es cierto para los campos
"clave". Es decir, no se garantiza que dos registros cualesquiera tengan diferentes valores en un
subconjunto concreto de campos.

Integridad referencial
No existe garantía de que un registro hijo esté relacionado con un registro padre válido. Por
ejemplo, es posible borrar un nodo padre sin eliminar antes los nodos hijo, de manera que éstos
últimos están relacionados con un registro inválido o inexistente.

De-Normalización
Este no es tanto un problema del modelo jerárquico como del uso que se hace de él. Sin embargo,
a diferencia del modelo relacional, las bases de datos jerárquicas no tienen controles que impidan
la des-normalización de una base de datos. Por ejemplo, no existe el concepto de campos clave o
campos únicos. ”

Materia: Base de Datos I -3-

Profesor: Calixto Maldonado
El modelo de Red [Wikipedia, 2009 c]
Una base de datos de red es una base de datos conformada por una colección o set de registros,
los cuales están conectados entre sí por medio de enlaces en una red. El registro es similar al de
una entidad como las empleadas en el modelo relacional.

Un registro es una colección o conjunto de campos (o atributos - columnas), donde cada uno de
los contiene solamente un único valor almacenado, exclusivamente el enlace es la asociación
entre dos registros, así que podemos verla como una relación estrictamente binaria.

Una estructura de base de datos de red, llamada algunas veces estructura de plex, abarca más
que la estructura de árbol, porque un nodo hijo en la estructura red puede tener más de un nodo
padre. En otras palabras, la restricción de que en un árbol jerárquico cada hijo puede tener sólo un
padre, se hace menos severa en este modelo. Así, la estructura de árbol se puede considerar
como un caso especial de la estructura de red.

Materia: Base de Datos I -4-

Profesor: Calixto Maldonado