Limitaciones del Modelo Relacional

Con el tiempo, ha quedado demostrado que los modelos de bases de datos relacionales son extremadamente poderosos en aplicaciones tradicionales de bases de datos, como sistemas de negocios o sistemas de información administrativa. Además de su simplicidad, el concepto de tabla ofrece una aproximación ideal para la representación de datos del negocio.

Sin embargo, cuando el modelo relacional se aplica en soluciones informáticas que no están relacionadas con la administración de los datos del negocio, tales como aplicaciones de CAD, imágenes, multimedia, información geográfica, etc., se hace obvio que el modelo relacional no es el más apropiado.

Este tipo de aplicaciones involucra datos y estructuras extremadamente complejas para ser representadas en la tradicional estructura de tabla plana.

Atributos Multivalor

Dos de las primeras limitaciones del modelo relacional nacen de sus restricciones estructurales. En un modelo relacional, se deben descomponer los atributos en busca de una expresión atómica e indivisible. Para aquellos atributos que involucran listas de valores (multivalor), dichos valores deben ser mapeados en una tabla diferente.

Como resultado, la información sobre la estructura de los atributos se pierde y los datos están diseminados en múltiples relaciones.

Jerarquía (ISA Hierarchy)

Debido a que el modelo relacional no permite expresar directamente las jerarquías, no podemos usar el concepto de herencia para la simplificación de queries.

Por ejemplo, dadas las tablas:

• MEMBER(MemberId, Fname, MI, Lname)
• LIFE_MEMBER(MemberId, Year)

En el modelo relacional, para obtener el nombre de un LIFE_MEMBER será necesario realizar en forma explícita la navegación a través de las relaciones (operación de join):

Select M.Fname, M.MI, M.Lname
From MEMBER M, LIFE_MEMBER LF
Where LF.MemberId = M.MemberId

En un modelo objeto-relacional, la operación de join es implícita, aplicando el concepto de herencia. Esto es, todos los atributos de MEMBER son heredados por LIFE_MEMBER:

Select Fname, MI, Lname
From LIFE_MEMBER

Binary Large Objects (BLOBs)

Los DBMS relacionales soportan el uso de strings de bits y data binaria en general. Sin embargo, su soporte es limitado, normalmente orientado a pequeños volúmenes de datos, como gráficos o imágenes.

En general, grandes volúmenes de data binaria no son soportados por un DBMS relacional, tales como videoclips de cientos de megabytes.

Incluso si por un momento ignoramos estas limitaciones estructurales y asumimos que se puede almacenar un BLOB (Binary Large Objects) en una tabla, es imposible consultar esta información usando SELECT. Por ejemplo, cómo obtener la secuencia de cuadros entre el 13 y 27 de un videoclip. Este tipo de operaciones requiere de implementaciones particulares.

Los DBMS relacionales no proveen especificación para operaciones tipo-específicas.

Character Large Object (CLOBs)

Una situación similar se presenta en objetos de grandes volúmenes de información alfanumérica, tales como data semiestructurada, páginas HTML, etc.

Tipos de datos y objetos definidos por el usuario

Abstract Data Types (ADTs)

Los problemas que surgen con el manejo de BLOBs y CLOBs (Character Large Object) son ilustrativos del problema generalizado que presenta la falta de soporte a tipos de datos y funciones definidas por el usuario en los DBMS relacionales.

Los problemas que surgen de complejas estructuras de datos que requieren ser manipuladas de una manera específica pueden ser resueltos encapsulándolos como Tipos de Datos Abstractos o Abstract Data Types (ADTs).

Los ADTs han sido exitosamente utilizados en lenguajes de programación para administrar de una manera más efectiva el desarrollo y mantenimiento de grandes sistemas de información.

Un ADT consiste en:

• Una especificación de sus estructuras de datos visibles y operaciones permitidas.
• Una implementación de su estado, relaciones con otros ADTs y sus operaciones.

Si un ADT es utilizado para definir el dominio de una columna, entonces las operaciones definidas en dicho ADT pueden ser utilizadas en queries y transacciones para manipular los valores de la columna.

Más allá, un ADT puede ser pensado como el tipo de un objeto. En otras palabras, un objeto puede ser interpretado como una instancia de un tipo de datos abstracto (ADT).

En dicho caso, la idea de herencia de estado y operaciones que provienen de la programación orientada al objeto puede ser aplicada a objetos y ADTs en bases de datos.

Tendencias

La introducción a ADTs y objetos como medio de soporte a aplicaciones de bases de datos avanzadas ha tomado varias formas, dos de las cuales, object-relational databases y object-oriented databases, están en proceso de estandarización.

La primera aproximación (object-relational) extiende el modelo relacional con ADTs y objetos, y se espera que esté estandarizada con SQL3, la siguiente versión de SQL.

La segunda aproximación (object-oriented) extiende un lenguaje de programación orientado a objetos (típicamente C++), con conceptos propios de bases de datos.

Un estándar de modelo de datos orientado al objeto es propuesto por el grupo ODMG (Object Database Management Group). Otro proceso de definición de estándares está siendo llevado a cabo por OMG (Object Management Group), y su iniciativa empuja por un modelo estándar cliente-servidor orientado a objetos denominado CORBA (Common Object Requester Broker Architecture).

En este punto, es importante mencionar que existe una gran transposición entre las tres ramas de estandarización, y en este sentido los esfuerzos se han desarrollado en paralelo.

Alta Disponibilidad en Bases de Datos

La alta disponibilidad busca evitar que la operación tenga interrupciones. Se deben disponer los elementos necesarios para evitar que se produzcan interrupciones y, si ocurren, minimizar el tiempo de las mismas.

Elementos Necesarios para la Alta Disponibilidad

• Tecnología con baja tasa de fallas.
• Tolerancia a desastres (redundancia).
• Disponer de procedimientos de contingencia.
• Conmutación (manual o automática).
• Control de cambios.

Esquema General de Redundancia

Capas en un Sistema Protegido

• Presentación: Esta capa representa la interfaz gráfica que verá la operadora y el cliente a través de un navegador de internet, y será servida a través de un servidor web donde se manejará el contexto y la sesión.
• Lógica del Negocio: Esta capa contiene toda la lógica del negocio. Además, se manejan las transacciones y consultas con las bases de datos locales y externas. Esto se logra a través de lenguajes de script en el servidor.
• Datos: Esta capa contiene el almacén físico de los datos y un administrador de bases de datos.

Replicación de Datos

Consiste en el transporte de los datos entre dos o más servidores, permitiendo que ciertos datos de la base de datos estén almacenados en más de un sitio y así aumentar la disponibilidad de los datos y mejorar el rendimiento de las consultas globales.

Componentes de la Replicación

• Publicador: Servidor que pone los datos a disposición de otros servidores para poder replicarlos.
• Distribuidor: Servidor que aloja la base de datos de distribución y almacena los datos históricos, transacciones y metadatos.
• Suscriptores: Reciben los datos replicados.

Tipos de Replicación

• Instantáneas: Sistema en que los datos se van replicando a medida que se van modificando en su origen.
• Transaccional: Sistema para el procesamiento y distribución de pedidos. Se podría tener varios publicadores recibiendo pedidos de mercancías. Estos pedidos se replican entonces a un almacén central donde se despachan los pedidos. El almacén puede tratar los datos como de solo lectura y requiere nueva información periódicamente.
• Mezcla: Permite que varios sitios funcionen en línea o desconectados de manera autónoma, y mezclar más adelante las modificaciones de datos realizadas en su resultado único y uniforme. Los datos se sincronizan entre los servidores a una hora programada o a petición. Por ejemplo, para una base de datos que registre la historia delictiva de individuos, en cada municipio se puede tener una copia de la base de datos de toda la región y no se requiere estar conectado permanentemente a la base de datos de la instancia regional.

Factores Determinantes en la Replicación

• Autonomía: De un sitio, da la medida de cuánto puede operar el sitio desconectado de la base de datos publicadora.
• Consistencia Transaccional: De un sitio, viene dado por la necesidad de ejecutar o no inmediatamente todas las transacciones que se han ejecutado en el servidor, o si es suficiente con respetar el orden de las mismas.
• Latencia: De un sitio, se refiere al momento en que se deben sincronizar las copias de los datos. ¿Necesitan los datos estar el 100% en sincronía?

Finalmente: La replicación es muy útil para mejorar la disponibilidad de datos, lo cual pudiera llevarse al caso extremo, conocido como las bases de datos distribuidas replicadas totalmente. Consiste en la replicación de la base de datos completa en cada sitio en el sistema distribuido y garantiza notablemente la disponibilidad de datos, pues el sistema puede continuar operando cuando exista en servicio al menos uno de los servidores. La desventaja es un alto costo para mantener la consistencia de las copias en cada sitio.