About.me

lunes, 29 de noviembre de 2010

Análisis entre modelo relacional y modelo documental en bases de datos

El origen de las bases de datos va ligado a la necesidad de organizar la cada vez más exigente cantidad de datos que se requieren. En los inicios, la información estaba delegada a los ficheros, como meros depósitos de información y a los que se accedía a bajo nivel para las operaciones más elementales de lectura y escritura. Con el tiempo, la información requerida se hacía mayor, y la complejidad de gestionarla también creció. Se comenzó a aplicar técnicas como índices para accesos más rápidos y para la ordenación de la misma. Pero las aplicaciones debían tratar los ficheros de forma artesanal y personalizada.

Surgieron sistemas que automatizaban las operaciones complejas de gestión de los datos, como los índices, así como las primeras relaciones entre campos clave entre dos o más tablas. Pioneros en estos sistemas fueron (por citar los más conocidos) fueron dBASE y Clipper, pero también empezaban a gestarse grandes bases de datos profesionales, como Oracle o DB2. Estamos hablando de los años 80.

Los dispositivos de almacenamiento eran limitados, así como la capacidad de los sistemas operativos en almacenar y direccionar información, aunque suficientes para la época. Es por ello que la optimización del espacio fuera un un factor vital, y que el diseño de las tablas contemplase el acotar el almacenamiento de cada campo, tener en cuenta el tamaño de cada fila, y prever el tamaño total de los ficheros junto con la previsión de crecimiento de los mismos.


Bases de datos relacionales

El modelo relacional surge ante estas circunstancias, postulado por Frank Codd en 1970. La normalización de los datos permite organizar la información separando en tablas la información más pequeña posible e independiente, para evitar la repetición de la misma. Para acceder a toda la información, las tablas se relacionan unas y otras mediante campos clave comunes, que suelen ser números con un id único.

Este modelo de almacenamiento es organizado y óptimo, define unas reglas que evitan la redundancia de la información y facilitan la consistencia de los datos. Este sistema de ingeniería de la información es el que ha regido las bases de datos durante los últimos 40 años.

Para trabajar con este modelo de almacenamiento, surgió el lenguaje SQL, que facilitó el entendimiento de las relaciones a través de una sintaxis sencilla y asimilable.

Este modelo de almacenamiento tiene las siguientes ventajas:
- Sistema de normalización óptimo en almacenamiento. Idóneo para sistemas con requisitos muy claros y poco dado a cambios.
- Sistema fuertemente estructurado e interrelacionado, formando un esquema.
- Sistema unánimente aceptado y estándar, utilizado en más del 90% de las aplicaciones
- La mayor parte de fabricantes de bases de datos utilizan el SQL estándar en sus productos, si bien puede haber alguna pequeña variación fácilmente subsanable.
- Las migraciones entre bases de datos de diferentes fabricantes no son excesivamente impactantes
- Las consultas SQL tienen funciones agregadas de cálculo asociadas a columnas en los resultados.
- Los sistemas de bases de datos relacionales asumen el trabajo de las complejidades de la integridad referencial, velando por la consistencia de la información y liberando al desarrollador de estas tareas para que se centre solamente en las consultas.
- Multitud de herramientas productivas construídas en torno a este modelo: business intelligence, datamining, ETL, administración, monitorización, etc.
- Eficiente para gestionar datos para automatizar actividades.

Sin embargo, también conlleva algunos inconvenientes:
- La normalización en entidades atómicas no es natural y tiende a complicar su entendimiento y los desarrollos.
- Basar la identificación de los registros y relacionar tablas por códigos numéricos es críptico y poco natural.
- La información, tal y como está almacenada, difiere mucho de cómo es gestionada, y requiere un esfuerzo importante de adaptaciones.
- Sistema rígido y estricto poco tolerante a fallos y que penaliza los cambios.
- La adición de entidades de relación y de campos clave a una tabla ya existente implica complejidad e impacta en los desarrollos actuales.
- Sistema que gana en complejidad a medida que crece. La escalabilidad de la estructura se torna condicionada.
- El desarrollo de las aplicaciones requiere de capacitación para conocer el modelo entidad-relación.
- El almacenamiento de toda la información requiere dividir la información en entidades atómicas y tratar éstas por separado en varios procesos.
- Las consultas requieren tracear la información separada y reunirla. Las joins suelen ser complejas y pesadas, y a veces no son suficientes, requiriendo varios procesos de consulta adicionales.
- La gestión automatizada de la integridad referencial supone una penalización de tiempo de accesos (lectura y escritura) a la información.
- La gestión automatizada de la integridad referencial no evita que el desarrollador preste atención a errores de integridad y su causa. El desarrollador debe asegurar previamente la integridad y controlar si el sistema le informa de alguna violación de reglas de integridad. Por ejemplo, la creación de una categoría de productos. El sistema informará si se está tratando de crear una categoría ya existente, y el programa debería capturar este aviso para advertir al usuario sobre la causa del problema. Otra forma (sin integridad automatizada) sería consultar previamente cuántas categorías existen con ese nombre. Si es mayor de cero advertir al usuario, y si no guardar la nueva categoría. El trabajo en ambos casos (con y sin integridad automatizada) no difiere mucho.
- La información de cada tabla está limitada a una estructura fija de campos o columnas, sean o no necesarios, y tengan o no valores. Si no se utiliza una columna, ésta se almacena de todas formas en cada fila.
- Poco eficiente a la hora de explotar grandes volúmenes de información textual (maneja mejor datos que información).
- Los principales fabricantes de sistemas de bases de datos relacionales las desarrollan de forma propietaria.


Bases de datos documentales

Las bases de datos documentales, a diferencia de las bases de datos relacionales, están libres de esquemas y de estructuras. Por tanto, la información no se divide en columnas fijas y filas, si no en documentos que pueden tener libertad de información, como cualquier cantidad de campos o de tipos de campos, e incluso de contener en el propio campo una lista de valores, un documento o una colección de documentos. La información almacenada en un documento está formado por pares de clave y valor.

La gran ventaja de no poseer esquema (y la consiguiente rigidez de estructuras y relaciones), es que son muy eficientes al trabajar con grandes cantidades de documentos.

Las principales ventajas de una base documental son las siguientes:
- Libre de esquemas. Al no estar sujeta a estructuras ni relaciones, los cambios de diseño son fáciles de adoptar y con un impacto mínimo.
- Al no tener relaciones se facilita la replicación
- Los sistemas de bases de datos documentales ganan rapidez dedicándose más en exclusiva al almacenamiento y la recuperación de la información (no consumen tiempos en la integridad o en la revisión de las reglas o constraints).
- Poseen un lenguaje de consulta natural.
- Sencillez y potencia en escalabilidad.
- Los campos vacíos no se añaden al documento, optimizando el espacio de almacenamiento.
- Cada documento (o “fila”) puede tener estructuras diferentes (más o menos campos, tipos diferentes de datos, etc.)
- Un documento es un objeto que normalmente es mapeado mediante JSON o XML
- Posibilidad en embeber documentos y colecciones dentro de documentos. Esto solventaría joins entre documentos, aunque agregaría complejidad a la estructura del documento.
Los datos almacenados no necesitan adaptaciones por las aplicaciones (tal como se almacenan se pueden gestionar).
- Muy eficiente a la hora de explotar grandes volúmenes de información textual (maneja mejor información que datos).
- Las migraciones entre bases de datos diferentes tienen muy poco impacto, pues comparten el formato JSON o XML.
- La mayor parte de los fabricantes de sistemas de bases de datos documentales, la desarrollan como open source.
- El auge de la Web está mirando este modelo de datos como clave en sus negocios, por su mayor capacidad de escalabilidad, rendimiento y alta disponibilidad, que los actuales sistemas de bases de datos relacionales.

Los principales inconvenientes serían:
- El sistema de base de datos no contempla realizar joins entre documentos.
- Más peso por parte de las aplicaciones para asumir la integridad y la consistencia.
- No posee funciones agregadas para realizar cálculos sobre la información de las consultas.
- Redundancia de la información. Penaliza el espacio de almacenamiento en aras de una mayor rapidez de acceso y de claridad de la información.
- Menos eficiente para automatizar actividades.
- Aunque este modelo de información es anterior al relacional, aún tiene una aceptación muy baja (menos de un 10% del total de aplicaciones funcionando en el mundo).
- No hay muchas herramientas de productividad en torno a este tipo de bases de datos, como Business Intelligence, monitorización, etc.
- Aunque es posible migrar un sistema relacional a un sistema documental, la potencia de la integridad referencial ha de ser restituida por código en las aplicaciones. No merece la pena esto, y sí una restrospectiva en la que se adapte los conceptos a documentos teniendo siempre en mente las ventajas que podría ganarse en la migración.

Safe Creative #1003275854193