Este documento describe los modelos de datos relacionales y no relacionales. Explica las características de los modelos de datos no relacionales y los divide en cuatro categorías principales: orientados a clave/valor, orientados a documentos, orientados a columna y orientados a grafos. También discute el Teorema CAP y sus implicaciones para los modelos de datos no relacionales.

1. [+34] 902 20 25 52 hablemos@beeva.com www.beeva.com
Clara del Rey 26, planta 4ª - 28002 Mardid
MODELOS DE DATOS
RELACIONALES Y NO RELACIONALES

2. Modelos de datos relacionales y no relacionales 2
INDICEINDICE
MODELOS DE DATOS RELACIONALES Y NO RELACIONALES
TEOREMA CAP
QUÉ SON LOS MODELOS DE DATOS NO RELACIONALES
TIPOS DE MODELOS DE DATOS NO RELACIONALES
NOSQL, ¿EL NUEVO SQL 2.0?
ENLACES Y LIBROS DE INTERÉS
3!
5!
7!
9!
18!
20!

3.
Modelos de datos relacionales y no relacionales 3
MODELOS DE DATOS
BEE UPDATED

4.
Modelos de datos relacionales y no relacionales 4!
El modelo a través del cual percibimos y organizamos nuestros datos.
Centrándonos en Bases de Datos, un Modelo de Datos indica cómo
interactuamos con los datos almacenados en nuestras Bases de datos.
El Modelo de Datos dominante en las últimas décadas es el Modelo Relacional, que estructura sus datos a
modo de Tablas que contienen Filas de datos y cada una de estas filas representa una Entidad concreta. Cada
Entidad se define mediante un conjunto de columnas con un único valor, que pueden incluir referencias a otras
filas de otra tabla o de la misma, constituyendo así las relaciones entre las entidades. Este modelo de filas y
columnas otorgan un esquema rígido a las tablas y constituyen la base del modelo relacional.
El Modelo de Datos No Relacional, surge de la necesidad de evitar los esquemas rígidos y permitir que los datos
que se almacenen en base de datos tengan una estructura más cercana a los datos con los que las
aplicaciones trabajan en memoria (Impedance Mismatch).
MODELOS DE DATOS
Relacionales y no relacionales
¿QUÉ ENTENDEMOS POR MODELO DE DATOS?

5.
Modelos de datos relacionales y no relacionales 5
TEOREMA CAP
BEE UPDATED

6.
Modelos de datos relacionales y no relacionales 6!
El Teorema CAP establece que dadas las tres propiedades de:
• Consistencia
• Disponibilidad
• Tolerancia a particiones
Cualquier base de datos no relacional, sólo podrá cumplir dos de ellas.
Martin Fowler en su libro NoSQL Distilled, expone claramente las
consecuencias del Teorema CAP y la necesidad de relajar alguna de
estas tres propiedades para poder optar a lograr las tres, sin sacrificar
ninguna de ellas.
No obstante, se puede obtener más información del teorema CAP en
Wikipedia.
TEOREMA CAP

7.
Modelos de datos relacionales y no relacionales 7
MODELOS DE DATOS NO RELACIONALES
BEE INFORMED

8.
Modelos de datos relacionales y no relacionales 8!
Un Modelo de Datos No Relacional, se identifica por reunir las siguientes características:
• No utilizan un Modelo de Datos Relacional
• Están diseñados para ejecutarse de manera eficiente en Clusters
• Son generalmente OpenSource
• Carecen de esquema, lo que permite añadir campos libremente sin tener que definir ni modificar previamente
la estructura; lo cual es muy útil cuando trabajamos con datos no uniformes o cambiantes en el tiempo
Los modelos de datos No Relacionales, se conocen también como NoSQL.
No existe una única solución No Relacional (o NoSQL) y cada una de ellas plantea su propio Modelo de Datos,
junto con sus ventajas e inconvenientes. Pueden dividirse en cuatro categorías principales:
• Orientados a Clave/Valor
• Orientados a Documentos
• Orientados a Columna
• Orientados a Grafos
De entre estos modelos, los tres primeros comparten la característica común de estar orientados a
‘Conjuntos’ (‘Aggregate’ en inglés) que se definen como: “Una colección de objetos o atributos relacionados
bajo una clave única, los cuales interesa tratar como una unidad lógica e independiente.”
LOS MODELOS DE DATOS NO RELACIONALES
Características y categorías

9.
Modelos de datos relacionales y no relacionales 9!
Almacena sus datos bajo una clave o un par de claves únicos, guardando toda la información asociada a dicha
clave (atributos) a modo de mapa, sin tener en cuenta el tipo de estructura ni el modo de organización presente
en los datos al trabajar con ellos en memoria. La tarea de recomponer la estructura de los datos en memoria
recae sobre el desarrollador y la lógica de negocio de la aplicación.
Un claro exponente de este tipo de modelo es DynamoDB de Amazon, junto con Voldemort, Riak, Redis e incluso
Memcache DB.
La ventaja de este modelo es que permite almacenar cualquier tipo de información con total libertad, siempre
respetando los límites establecidos para cada base de datos en concreto. Por ejemplo, DynamoDB establece
un límite de tamaño de 64Kb para cada Clave junto con todos sus atributos (DynamoDB los denomina Items).
Suelen ser modelos de datos orientados a sistemas con un número de escrituras muy elevado ofreciendo una
alta disponibilidad y consistencia de los datos en todo momento; aunque la consistencia se aplica a operaciones
sobre una misma clave.
TIPOS DE MODELOS DE DATOS NO RELACIONALES (I)
Modelos orientados a clave / valor (I)

10.
Modelos de datos relacionales y no relacionales 10!
Al ser sistemas distribuidos que garantizan la consistencia de los datos almacenados, la forma de leer estos
datos se ve penalizada ya que el único atributo que se encuentra indexado es la clave (key), o el par de claves, y
es el único que podremos introducir en la Query.
Por tanto, no sería posible lanzar una Query sobre los valores de los atributos que no se encuentran indexados
o, en los casos en los que se permita (operación de Scan en DynamoDB por ejemplo) el rendimiento se ve
ampliamente afectado.
Otro efecto a tener en cuenta con este Modelo de Datos en el que sólo podemos lanzar Queries por Key, es:
¿Qué ocurre si no conocemos la Key? ¿Cómo extraemos el valor (o valores) asociado(s)?
Conviene tener en cuenta que la gran mayoría de estos sistemas, no nos ofrecen un listado de todas las claves
almacenadas, ¿Habéis intentado hacer esto con Memcached…?
Bases de datos como DynamoDB, Riak o Voldemort se orientan a favorecer la Disponibilidad y la Tolerancia a
particiones, situándose en el lado AP del Teorema CAP.
TIPOS DE MODELOS DE DATOS NO RELACIONALES (II)
Modelos orientados a clave / valor (II)

11.
Modelos de datos relacionales y no relacionales 11!
El Modelo de Datos NoSQL orientado a Documentos, organiza su información en estructuras denominadas
‘Documentos’ permitiendo una representación de los mismos en lenguaje XML, JSON o BSON y sin ningún tipo
de esquema definido, lo que permite que cada documento tenga un esquema propio y un conjunto de atributos
específico. Este esquema interno puede diseñarse para que represente de una manera más fidedigna los datos
con los que posteriormente se trabajará en memoria.
Un claro exponente de este tipo de modelo es MongoDB o CouchDB.
En comparación con los modelos orientados a Clave/Valor, los orientados a Documentos poseen también una
única clave primaria y presentan la ventaja de permitir indexar por cualquier atributo definido y, por tanto,
realizar consultas sobre cualquier atributo presente en el Documento (incluso soluciones como MongoDB
permiten índices secundarios).
También permiten enlazar documentos mediante atributos de enlace gracias a la clave primaria, aunque
estos enlaces no están físicamente representados en la estructura interna de la base de datos y serán un
atributo más con un valor determinado que será la clave primaria de otro documento. Por lo que recae en el
lado del desarrollador y su aplicación la tarea de recuperar cada documento enlazado con una nueva consulta.
TIPOS DE MODELOS DE DATOS NO RELACIONALES (II)
Modelos orientados a documentos (I)

12.
Modelos de datos relacionales y no relacionales 12!
En lo referente a la atomicidad en las operaciones de escritura, este modelo garantiza que cada documento
completo se escribirá de forma atómica; si en algún momento de la escritura se produce un error, toda la
operación falla y el documento entero queda sin escribir a disco, no hay escrituras parciales. Sin embargo no
nos garantiza que los documentos enlazados se escriban en conjunto de forma atómica, por lo que garantizar la
transaccionalidad dependerá de la aplicación.
Las bases de datos orientadas a documentos, procuran dotar de Consistencia y Disponibilidad (Availability) a
los datos almacenados (CA en el Teorema CAP). La consistencia se logra mediante la penalización en los
tiempos de escritura de datos, ya que la operación no se da por finalizada hasta que el dato no ha sido
replicado en la mayoría de nodos. La disponibilidad se garantiza mediante la mencionada replicación de los
datos, con lo que el mismo dato se encuentra replicado en varios nodos, que a su vez pueden estar situados en
diferentes zonas geográficas.
TIPOS DE MODELOS DE DATOS NO RELACIONALES (II)
Modelos orientados a documentos (II)

13.
Modelos de datos relacionales y no relacionales 13!
El Modelo de Datos NoSQL orientado a Columna utiliza un patrón similar a las bases de datos orientadas a
Clave/Valor. En esta ocasión, bajo una misma clave se agrupan varios atributos de tipo clave/valor que se
denominan columnas, que a su vez, pueden contener columnas como valor (supercolumnas). Este conjunto de
Clave y Columnas se denomina Fila. Su estructura se asemeja a un mapa de dos niveles, donde la clave se
considera el identificador de la fila.
TIPOS DE MODELOS DE DATOS NO RELACIONALES (II)
Modelos orientados a columna (I)
Es una estructura diseñada para obtener un gran rendimiento en sistemas que requieran un número elevado
de operaciones de escritura, penalizando las lecturas debido a la falta de estructuras de indexación en aquellos
atributos que no sean el identificador de la fila (Row) (Al igual que sucede con el modelo Clave/Valor).
Un claro exponente de este tipo de modelo es Cassandra, HBase o Hypertable.

14.
Modelos de datos relacionales y no relacionales 14!
De modo similar a lo que ocurre en el modelo orientado a Documentos, una Columna puede representar un
enlace a otra fila de la Tabla a través de su Clave (o identificador de fila), lo que permite enlazar filas entre sí,
pero nuevamente recaería en el desarrollador lanzar la cadena de consultas para recuperar todas las filas
enlazadas.
Este aspecto se refleja también en la transaccionalidad, ya que la atomicidad de las escrituras sólo garantiza
que una fila se escriba de forma atómica, delegando la responsabilidad de llevar a cabo la transaccionalidad de
las filas enlazadas en la parte del desarrollador.
Las bases de datos orientadas a columnas, procuran dotar de alta tolerancia a las particiones a los datos
almacenados (P en el Teorema CAP). Cada exponente de este modelo decide sacrificar una parte del Teorema
CAP; por ejemplo: Cassandra hacer mayor hincapié en favorecer la Disponibilidad de los datos y sacrificar la
Consistencia (aunque se puede garantizar consistencia en los datos perjudicando los tiempos de escritura); por
lo que diríamos que Cassandra está en la zona AP del Teorema CAP.
HBase sacrifica la disponibilidad de los datos situándose en la zona CP del Teorema CAP.
TIPOS DE MODELOS DE DATOS NO RELACIONALES (II)
Modelos orientados a columna (II)

15.
Modelos de datos relacionales y no relacionales 15!
Los modelos orientados a Grafos presentan un paradigma completamente diferente a lo visto hasta ahora.
Estos modelos tratan de resolver el problema de modelar relaciones complejas al que se enfrentan las bases
de datos relacionales. Para ello se basan en un modelo de registros, denominados Nodos, que almacenan muy
poca información pero que poseen unas interconexiones muy complejas entre sí denominadas Arcos.
Debido a que estos modelos están diseñados para relacionar nodos entre sí y construir una estructura robusta
que permita realizar consultas con alto contenido semántico, la gran potencia de estos sistemas se destina a
favorecer la comunicación entre los nodos. Estos modelos tienen a sus máximos exponente en las redes
sociales, donde la interconexión y la relación entre los datos cobra mayor importancia que los datos en sí
mismos.
Este énfasis en las relaciones conlleva que estos sistemas sean tan diferentes a lo visto hasta ahora y esas
diferencias se hacen patentes en el hecho de que resulta muy difícil plantear estos sistemas en un entorno de
ejecución distribuido, ya que para garantizar la atomicidad en las operaciones, puede ser necesario recorrer
una gran cantidad de nodos, lo que resultaría costoso (en tiempo y potencia computacional) si estos nodos no
se encuentran en la misma máquina.
Por todo esto, las Bases de datos orientadas a grafos no suelen ser tolerantes a las particiones.
Un claro exponente de este tipo de modelos es Neo4j.
Como suele ser desaconsejable ejecutar este tipo de bases de datos en un entorno distribuido, la consistencia
en un único servidor siempre está garantizada y la disponibilidad puede lograrse utilizando servidores esclavos.
Por lo que Neo4j se sitúa en la rama CA del teorema CAP.
TIPOS DE MODELOS DE DATOS NO RELACIONALES (II)
Modelos orientados a grafos (I)

16.
Modelos de datos relacionales y no relacionales 16!
Hay varios motivos principales por los cuales podemos considerar apropiado utilizar tecnología NoSQL en
nuestras arquitecturas:
1. Cuando el volumen de datos que tenemos que gestionar es muy elevado y la necesidad de acceder
extremadamente rápido y eficiente a dichos datos, justifica la creación de un cluster.
2. Cuando necesitamos mejorar la productividad del desarrollo de aplicaciones utilizando un Modelo de Datos
que se adapte mejor a cómo las aplicaciones trabajan con esos datos en memoria.
3. Cuando la naturaleza de los datos es cambiante en el tiempo y necesitamos total libertad para almacenar
los datos sin imponer ningún tipo de estructura.
VENTAJAS E INCONVENIENTES DE NoSQL

17.
Modelos de datos relacionales y no relacionales 17!
De igual modo, hay varios motivos por los que podríamos considerar no apropiado utilizar almacenamiento No
Relacional en nuestra arquitectura:
1. Cuando haya relaciones entre los datos y la consistencia de las mismas sea un punto crítico para nuestro
sistema.
2. Cuando sea necesario garantizar la consistencia de la escritura de los datos mediante transaccionalidad
ACID.
3. Cuando nuestras Queries requieran poder consultar por cualquier campo de nuestra base de datos, sin
poder establecer a priori cuáles serán los campos más consultados.
4. Cuando la naturaleza de las aplicaciones que acceden a los datos sea muy diversa y cada una explote
dichos datos mediante diferentes Queries.
Estos dos últimos puntos, resultan decisivos a la hora de descartar un Modelo de Datos No Relacional para
nuestra arquitectura, ya que, cuando estos modelos logran un mayor rendimiento, es cuando preparamos la
estructura de los datos para adaptarse a las necesidades de la aplicación que los va a consumir. Si hay varias
aplicaciones consumiendo los datos, es imposible normalizar los datos no estructurados para garantizar que el
rendimiento de acceso sea óptimo.
Con una Base de Datos Relacional no tenemos este inconveniente ya que si diseñamos nuestro modelo
siguiendo las diferentes Formas Normales, garantizamos que cualquier aplicación va a poder acceder de modo
fiable a los datos y con un rendimiento óptimo.
VENTAJAS E INCONVENIENTES DE NoSQL

18.
Modelos de datos relacionales y no relacionales 18
NoSQL, ¿ES EL NUEVO SQL 2.0?
BEE UPDATED

19.
Modelos de datos relacionales y no relacionales 19!
Si estás leyendo este documento y eres adicto a la tecnología, muy probablemente ya conocerás la respuesta a
esta pregunta. La respuesta es NO (con mayúsculas).
NoSQL no es una tecnología pensada para sustituir a SQL o a las Bases de Datos relacionales.
Ciertamente, las Bases de Datos Relacionales forman parte de nuestra cultura de programación y diseño de
arquitecturas software, ya que hubo un tiempo durante el cual, eran la opción de almacenamiento persistente
más fiable (y casi la única).
Con la aparición de la nueva tecnología No Relacional (NoSQL), se abren nuevos modos de organizar nuestra
información y nuevos retos que afrontar en nuestras arquitecturas; pero eso no quiere decir que una tecnología
deba suplantar a la otra.
Desde el punto de vista técnico, hemos visto las limitaciones y ventajas que ambos sistemas ofrecen, e incluso,
podemos discernir cuándo es recomendable utilizar uno u otro, o los dos al mismo tiempo.
El problema que se empieza a plantear es que, desde un punto de vista menos técnico, más orientado a
comercial o a cliente, se percibe esta tecnología como una nueva versión de la anterior y cada vez más clientes
demandan utilizarla en sus sistemas a toda costa, sí o sí; aunque no encaje en absoluto.
Nos toca desde nuestro punto de vista técnico aconsejar (educar) a nuestros clientes para guiarles por el
camino del NoSQL, sólo cuando realmente su Modelo de Datos lo justifique y su arquitectura lo permita.
NoSQL, ¿ES EL NUEVO SQL 2.0?

20.
Modelos de datos relacionales y no relacionales 20
ENLACES Y LIBROS DE INTERÉS
BEE UPDATED

21.
Modelos de datos relacionales y no relacionales 21!
Libro: NoSQL Distilled A Brief Guide to the Emerging World of Polyglot Persistence. Martin Fowler
Libro: Getting Started With NoSQL. Gaurav Vaish
Wikipedia: CAP Theorem
Wikipedia: NoSQL
ENLACES Y LIBROS DE INTERÉS

22. [+34] 902 20 25 52
hablemos@beeva.com
www.beeva.com
Clara del Rey 26, planta 4ª - 28002 Madrid
Pablo Valiente Rocha
Arquitecto de Software en BEEVA