Está en la página 1de 24

Área: Negocios y gestión

Bases de datos no estructuradas

M1 NoSQL y JSON
Módulo: 1
Curso: Bases de datos no estructuradas

Mapa de Contenido

Conceptos generales y uso de


JSON

La evolución de
Tipos de base de JSON y bases
los sistemas de
datos NoSQL NoSQL
bases de datos

Diseño de sistemas Bases de datos


JSON vs XML
distribuidos clave/valor

Normalización y Bases de datos de Uso de JSON en


modelos de datos columna ancha servicios Web REST

Bases de datos
orientadas a Grafos

Bases de datos
documentales
Módulo: 1
Curso: Bases de datos no estructuradas

Índice

Introducción ............................................................................................................................................................................................................ 4
1. La evolución de los Sistemas de Base de Datos .................................................................................................................................. 5
1.1 Diseño de sistemas distribuidos ........................................................................................................................................ 6
1.2 Normalización y modelos de datos ................................................................................................................................. 10
2. Tipos de bases de datos NoSQL .............................................................................................................................................................. 13
2.1 Bases de datos Clave/Valor ............................................................................................................................................. 13
2.2 Bases de datos de Columna Ancha .................................................................................................................................. 13
2.3 Bases de datos Orientadas a Grafos ................................................................................................................................ 14
2.4 Bases de datos Documentales: ........................................................................................................................................ 15
3. JSON y Bases NoSQL .................................................................................................................................................................................... 16
3.1 JSON vs XML .................................................................................................................................................................... 16
3.2 Uso de JSON en servicios Web REST................................................................................................................................ 21
Cierre ....................................................................................................................................................................................................................... 24
Módulo: 1
Curso: Bases de datos no estructuradas

Resultado de aprendizaje

Diseña consultas JSON como medio de comunicación con servicios asociados a bases de datos
NoSQL, en un contexto de bases de datos no estructuradas.

Introducción
En este módulo se presentarán los conceptos generales
relacionados con las bases de datos no estructuradas.
Comenzaremos por revisar la historia de las bases de datos para
comprender la necesidad de generar enfoques de organización de
la información distintos al enfoque tradicional de los sistemas de
bases de datos, tanto por la necesidad de generar arquitecturas
altamente escalables y tolerantes a fallas en donde es más
importante la escalabilidad que la consistencia, como por la
existencia de grandes volúmenes de información no estructurada
que requiere ser almacenada y consultada en formas distintas a las que habitualmente se utilizan para
acceder a la información en una base de datos relacional. Gran parte de estos avances han sido
impulsados por la aparición de empresas como Amazon, Google o Facebook, que han alcanzado una
escala global que ninguna otra había alcanzado antes, en cuanto a niveles transaccionales, servicios de
búsqueda o redes sociales.

Este módulo finalizará con una descripción del formato de


intercambio de información JSON, el cual se adapta muy bien
para la generación de servicios REST que interactúen con bases de
datos NoSQL y que actúen como puentes para transferir la
información hacia sitios web o aplicaciones móviles.

El material de este módulo es indispensable para un Ingeniero


Informático, ya que le permite comprender gran parte de los
hechos que han cambiado las arquitecturas tecnológicas y las
formas en que se entregan servicios a través de la tecnología.

Pág. 4
Módulo: 1
Curso: Bases de datos no estructuradas

1. La evolución de los Sistemas de Base de Datos


Una de las primeras aplicaciones de los computadores fue el
procesamiento de grandes volúmenes de datos. Inicialmente
estos grandes volúmenes de datos eran almacenados en archivos
con una estructura especial, que los programas debían conocer
para poder leerlos y modificarlos. En 1970, Edgar Frank Codd de
los laboratorios de IBM, observando que este acoplamiento era
un inconveniente, propuso la necesidad de independizar el
almacenamiento de la información y su estructura de los
programas que actuaban como clientes. Para hacerlo propuso
diseñar los sistemas de almacenamiento de datos usando dos elementos:

1. Un modelo basado en relaciones n-arias entre entidades representadas usando una forma normal.

2. Un lenguaje universal para acceder a la información.

Atención

Estos dos elementos sentaron los cimientos para la creación de las bases de datos estructuradas, en
donde los datos se modelan mediante entidades relacionadas entre sí, en las que se busca evitar la
redundancia de información y en donde la información puede ser consultada utilizando el lenguaje
de consultas estructurado (Structured Query Language, SQL).

Durante varias décadas, los sistemas de bases de datos estructurados


fueron el paradigma dominante. Esto comenzó a cambiar con el
advenimiento de las redes sociales y los sistemas de comercio
electrónico, en donde los sistemas pasaron de tener cientos o miles de
usuarios concurrentes, a tener potencialmente millones. Para manejar el
incremento en el tamaño de las bases de datos y la carga de
transacciones, fue necesario buscar mecanismos para facilitar la
escalabilidad de los sistemas. Hay dos tipos principales de escalabilidad:

1. Escalabilidad Vertical: que es cuando se incrementa la capacidad de procesamiento aumentando


el poder de cómputo del servidor en que reside el sistema. Esta escalabilidad depende de disponer
máquinas cada vez más poderosas.

Pág. 5
Módulo: 1
Curso: Bases de datos no estructuradas

2. Escalabilidad Horizontal: que es cuando se busca incrementar la capacidad de procesamiento


distribuyendo el procesamiento entre varios servidores. Este tipo de escalamiento tiene dos
características que lo hacen muy conveniente:

a. Menor costo: cada servidor puede ser más simple, ya que en lugar de procesar toda la
carga de transacciones, deberá procesar solamente una parte.
b. Mayor flexibilidad: debido a que el incremento de la capacidad se lograr incorporando
nuevos servidores, no es necesario interrumpir el servicio para migrarlo a un servidor más
potente.

Desafortunadamente, los sistemas de bases de datos estructurados


tienen un diseño que hace que puedan escalar principalmente de
forma vertical, lo que los hace poco flexibles, aunque se pueden usar
varios servidores para una misma base de datos, habitualmente son
esquemas principalmente de replicación, en el que los datos están
duplicados como medida de respaldo pero no para un procesamiento
distribuido.

Otro inconveniente adicional es que en la medida que aumenta la cantidad de información almacenada,
pasando de Gigabytes, a Terabytes y luego llegando a Petabytes, es cada vez más difícil llevar a cabo los
procesos de respaldo de información, ya que toman cada vez más tiempo. Para distribuir la información
y el procesamiento entre múltiples servidores surge la necesidad del particionamiento, para lo cual se
deben considerar los principios de diseño de los sistemas distribuidos, y por lo tanto, repensar la forma
en que se gestionan los sistemas de bases de datos.

1.1 Diseño de sistemas distribuidos


Uno de los teoremas fundamentales para el diseño de
sistemas distribuidos es el Teorema CAP, (también llamado
Conjetura de Brewer, ya que fue presentado por Eric Brewer
en el año 2000 durante un Simposio de Principios de
Computación Distribuida). CAP es un acrónimo de
Consistency (Consistencia), High Availability (Alta
disponibilidad) y Partitions (tolerancia a particiones de red).
Este teorema afirma que en un sistema distribuido no se
puede lograr una perfecta consistencia al mismo tiempo que
una perfecta disponibilidad cuando los datos están
particionados. Estas dos características son importantes en
todo sistema distribuido, ya que la consistencia implica la
existencia de una única copia actualizada de los datos y la
disponibilidad que exista un acceso ininterrumpido a los datos para ser actualizados.

Pág. 6
Módulo: 1
Curso: Bases de datos no estructuradas

Para entender el fundamento tras el teorema CAP, comenzaremos por analizar un sistema de base de
datos sin partición de datos, como el de la figura 1:

Figura 1. Sistema de Base de Datos sin partición de datos


Fuente: Elaboración Propia

En el esquema de la figura 1, cuando el cliente actualiza la información se puede preservar en forma


conjunta la consistencia y la disponibilidad de la información, ya que el sistema tiene una única copia de
los datos. La posibilidad de conservar ambas características es lo que promovió durante mucho tiempo
la escalabilidad vertical en los sistemas de bases de datos, ya que solamente se dependía de incrementar
la capacidad de procesamiento de la máquina. Sin embargo, estos tiene dos inconvenientes:

El primero es que si el servidor tiene un problema, se produce una completa pérdida del servicio ya
que tenemos un único punto de falla.

El segundo inconveniente se hizo notorio con el advenimiento de sistemas que almacenaban


Terabytes o Petabytes de información y con cientos de miles o millones usuarios concurrentes, una
única máquina no era capaz de manejar en forma eficiente toda la carga.

Pág. 7
Módulo: 1
Curso: Bases de datos no estructuradas

Debido a estos problemas, se hizo necesario distribuir la carga de transacciones y la información entre
múltiples máquinas que se pudieran incorporar a la infraestructura en forma flexible, en la medida que
se necesitaran, incluso en forma temporal, para absorber incrementos de carga en ciertos momentos del
año (pensemos por ejemplo en los incrementos de transacciones que ocurren en fechas como el
cybermonday). Es más factible agregar y retirar una máquina sencilla que mover de ida y de vuelta un
servicio complejo de un servidor a otro. Es por eso, que se necesitó particionar la información entre varias
máquinas, generándose un esquema como el que aparece en la figura 2.

Figura 2. Sistema de base de datos particionado


Fuente: Elaboración propia

En la figura 2, el sistema de base de datos está distribuido entre dos servidores, que tienen en un principio
una copia exacta de los datos y que están conectados a través de la red. En caso de la falla de un servidor,
el otro servidor puede continuar prestando el servicio sin interrupción, lo que preserva la disponibilidad.

Sin embargo, cuando un cliente se conecta con el nodo 1 y realiza una actualización se afecta
inmediatamente la consistencia de la información, ya que los datos del nodo 2 durante un período de
tiempo no estarán exactamente sincronizados con el nodo 1: no se afecta la disponibilidad pero si la
consistencia. Por otro lado, si no desea mostrar inconsistencia de datos a los clientes, el nodo 2 debería
dejar de estar disponible hasta que se sincronice exactamente con el nodo 1, por lo tanto se afectaría la
disponibilidad. Es exactamente esto lo que el teorema CAP indica, no se puede lograr simultáneamente
perfecta disponibilidad con perfecta consistencia, pero si pueden lograrse compromisos de diseño
suficientemente efectivos. En particular, el diseño de bases de datos NoSQL promueve concentrarse
primero en la disponibilidad de la información y en la consistencia después. Por otro lado, los sistemas
de bases de datos tradicionales realizan exactamente lo contrario.

Pág. 8
Módulo: 1
Curso: Bases de datos no estructuradas

Estas dos filosofías se pueden representar con los acrónimos ACID y BASE: los sistemas de base de datos
tradicionales se enfocan en la consistencia, por lo que usan la filosofía ACID y los sistemas de bases de
datos NoSQL dado que se enfocan en la disponibilidad usan la filosofía BASE. Ambas filosofías se
diferencian en los principios que usan para procesar las transacciones.

ACID, es el acrónimo de cuatro propiedades:

A •Atomicidad (Atomicity): implica que cada transacción se realiza completamente o


no se realiza.

C
•Consistencia (Consistency): el estado de los datos se modifica en forma coherente
a las reglas que lo definen, por lo que nunca se obtiene información que está
inconsistente o incompleta a consecuencia de una transacción en curso.

I •Aislamiento (Isolation): implica que cada transacción se procesa en forma


independiente de las demás.

D •Durabilidad (Durability): implica que una vez que una transacción se completa es
definitiva.

Para lograr la atomicidad, consistencia y aislamiento, los sistemas de bases de datos tradicionales utilizan
el bloqueo de datos. Dependiendo de la configuración, el bloqueo puede ser a nivel de registro o tabla.
Los bloqueos evitan que dos transacciones modifiquen la información al mismo tiempo o que otra
transacción lea información que está siendo modificada, pero con el costo de generar una contención en
el acceso a la información que limita la escalabilidad del sistema y el número de operaciones concurrentes
que puede manejar. Para evitar este problema, la filosofía BASE relaja las restricciones de consistencia lo
cual permite evitar el uso de bloqueos, y por lo tanto aumentando el número de transacciones
concurrentes que un sistema puede manejar.

BASE, es un acrónimo que representa tres características del procesamiento de transacciones:

• Disponibilidad básica (Basically available): esta propiedad implica que los datos estarán
siempre disponibles, incluso al costo de recuperar información que está siendo modificada o que
está pendiente de actualizarse.

• Estado “Suave” (Soft State): implica que los datos pueden modificarse no solamente debido a
las transacciones sino que también debido a operaciones de sincronización originadas por la
propiedad de consistencia eventual.

Pág. 9
Módulo: 1
Curso: Bases de datos no estructuradas

• Eventualmente consistente (Eventually Consistent): implica que cuando se realizan


transacciones el sistema alcanzará eventualmente un estado consistente con la última actualización
realizada, en la medida que termine la propagación de los cambios o cuando ya no se reciban más
actualizaciones (Vogel, 2009). Si no existen fallas, el tiempo para lograr la consistencia será una
función de los retardos en las comunicaciones, la carga del sistema y el número de réplicas que
deben ser sincronizadas. Un ejemplo de sistema eventualmente consistente es el servicio de
nombres de dominio (DNS).

Esto nos permite comprender que los sistemas de bases de datos NoSQL se rigen mayoritariamente por
principios de diseño enfocados en la disponibilidad y maximización del rendimiento, más que en la
consistencia, como una forma de superar las limitaciones de la filosofía ACID, en el que se establecen las
bases de datos tradicionales. Sin embargo, la única diferencia no se encuentra en la forma en que se
diseña el sistema, también podemos encontrar diferencias en la forma en que se organiza la información
en la base de datos, que es lo que será el objetivo de la siguiente sección.

1.2 Normalización y modelos de datos


Los fundamentos teóricos de los sistemas de base de datos se
remontan al modelo de datos relacional. En este modelo, la
información se organiza en tuplas compuestas de atributos. El
modelo busca mantener la consistencia y evitar la redundancia
de la información mediante la normalización. Para acceder a
la información, no es necesario conocer la forma en que la
información está almacenada, solamente se requiere
especificar mediante un lenguaje de consulta la información
que se desea obtener: este lenguaje se llama SQL (Structured
Query Language), el cual, con algunas variaciones específicas
a cada implementación, está presente en todos los sistemas de bases de datos relacionales.

Cada entidad tiene algún atributo que la distingue de las demás llamado su clave primaria, la cual se
utiliza para conectar una entidad con otra relacionada actuando en esta ocasión como una clase foránea.
Esta filosofía de organización de la información usando un modelo de entidades y relaciones se adapta
muy bien para crear modelos de conceptos de la realidad (facturas, clientes, órdenes de compra), para
organizar información en forma jerárquica describiendo relaciones de composición (una factura y cada
una de sus líneas de detalle), y las relaciones que existen entre ellos (la relación entre orden de compra y
factura, entre factura y guía de despacho, entre una cliente y su historial de compras, etc.). Sin embargo,
el paradigma de la normalización y el deseo de evitar la redundancia de la información genera algunos
inconvenientes:

Pág. 10
Módulo: 1
Curso: Bases de datos no estructuradas

1. En su implementación física, promueve la aparición de múltiples tablas (la implementación


física de una entidad en una base de datos estructurada). Cuando la cardinalidad de la relación es
de N:N se requiere además una tabla para relacionar una entidad con otra, las llamadas tablas de
relación, en las que la mayoría de las veces solamente encontraremos las claves primarias de cada
entidad que participa de la relación, pero ningún atributo.

2. También ocurre, que dependiendo del estado en que se encuentre cada entidad, puede que no
todos sus atributos estén completos, siendo necesario considerar en las tablas la existencia de
atributos nulos.

3. En el caso de las entidades compuestas, sucede algo similar. En las relaciones de composición,
que conectan varias tablas, un encabezado podría no tener un valor de detalle, e incluso
cuando los datos del detalle de una entidad compuesta están presentes, pueden ser relativamente
pocos, lo que hace dudar respecto de la obligatoriedad de mantener la normalización y crear una
tabla especial para los registros de detalle. Esto además se refuerza por el hecho, de que en
general, cada vez que se lee una entidad compuesta se terminará necesitando la información de
detalle también. La normalización requiere la aplicación de JOIN para reunir la información
relacionada: esto es una limitación para la distribución de la información, ya que las operaciones
JOIN no tienen un buen desempeño en un entorno distribuido, pues la información requerida
para resolver la consulta podría estar en múltiples servidores.

4. Existe información que a pesar de que se puede incluir en un modelo relacional, tiene una
naturaleza distinta, por ejemplo documentos de texto o pdf, porque no tienen una estructura
fija. Si bien se pueden almacenar en campos de tipo binario, este tipo de campos requieren
administración especial y en la medida que aumenta la cantidad de información que contienen
dificultan los procesos de respaldo de información. Es por esto, que resulta más eficiente
almacenar la información en un formato legible, sin embargo, para eso se requeriría tener una
tabla que tenga un esquema flexible.

5. Finalmente, con la masificación del paradigma de diseño orientado al objeto en la ingeniería de


software se comenzó a considerar a la base de datos como un repositorio en el que se maneja
el estado persistente de los objetos. En un modelo de datos compuesto de múltiples tablas cuya
única finalidad es mantener la normalización, el manejo de la serialización y deserialización de
objetos desde y hacia la base de datos se complejiza, siendo necesaria la lectura de varias tablas
al mismo tiempo para obtener la información asociada a un objeto. La serialización es el proceso
de convertir la representación de un objeto en el programa a un formato que pueda ser
almacenado en la base de datos, muchas veces a través de la generación de múltiples
actualizaciones en las tablas que almacenan su estado. La deserialización es el proceso inverso:
muchas veces las tablas se acceden únicamente por su clave primaria o por un atributo específico
que permite identificar la instancia del objeto que se desea obtener, se lee la información de las

Pág. 11
Módulo: 1
Curso: Bases de datos no estructuradas

tablas relacionadas y con esto se construye una instancia del objeto en el programa. En estos dos
casos, de serialización y deserialización no siendo necesario el uso de todas las potencialidades
del lenguaje SQL, que fue diseñado para la especificación de consultas complejas, ya que
generalmente las consultas leen todos los campos de las tablas y también los actualizan todos,
pues es mucho más complejo llevar un registro en el programa de qué campos fueron
modificados.

Todas estas desventajas, combinadas con los requerimientos de


disponibilidad y rendimiento hicieron necesaria la aparición de
nuevos tipos de bases de datos, las bases de datos NoSQL.
Este nombre hace referencia a que en general este tipo de base
de datos no soportan el lenguaje SQL, sino que cada una tiene
un lenguaje de consulta propio, pero un nombre más apropiado
sería el de almacenes de datos (data stores), ya que su principal
diferencia está en la forma en que modelan la información
(generalmente sin un esquema de datos como el de las bases
relacionales) y en los principios de diseño que usan para gestionar su actualización (filosofía BASE en
lugar de ACID, como en las bases de datos relacionales).

Ejemplo

Ejemplo de estas bases de datos son: las bases de datos clave/valor, las de columna ancha y las
bases de datos de documentos.

Pág. 12
Módulo: 1
Curso: Bases de datos no estructuradas

2. Tipos de bases de datos NoSQL


2.1 Bases de datos Clave/Valor
Las bases de datos clave/valor se basan en una estructura
de datos llamada “tabla de hash”. Una tabla de hash es
una generalización de los arreglos, en donde se puede
utilizar como índice una clave que no está limitada a ser
numérica, sino que puede ser cualquier tipo de dato. La
conexión entre la clave y el índice en el arreglo se realiza
utilizando una función de hash (Cormen, 2010), que
permite recuperar la información asociada a la clave
indicada.

Ejemplo

Este tipo de almacén de datos se usa en servidores de caché como memcached


(https://memcached.org/) o en bases de datos clave/valor como Redis (https://redis.io/).

2.2 Bases de datos de Columna Ancha


Se pueden considerar como una variación de las bases de datos clave/valor basadas en el diseño de
Bigtable, base de datos desarrollado por Google y utilizada por varios de sus servicios (búsqueda, google
earth, google maps, Gmail, etc.). En este tipo de base de datos los registros en lugar de tener una única
clave están indexados por una combinación de varias claves, conformando una tabla de hash
multidimensional (Chang, 2006). Otra de sus características, y que les da nombre, es el hecho de que
permiten que cada entidad tenga un número flexible e ilimitado de columnas, las cuales se incorporan
mediante el concepto de familia de columnas. Una familia de columnas es un grupo de columnas
relacionadas que tienen un nombre que las identifica, cada columna tiene un nombre y un valor. Esta
familia de columnas se modela tal como se modelaría una tabla en una base de datos relacional. En la
figura 3, se puede ver un ejemplo:

Figura 3. Ejemplo de la familia de columnas estudiantes


Fuente: Elaboración propia

Pág. 13
Módulo: 1
Curso: Bases de datos no estructuradas

En el ejemplo, se puede ver que cada registro en la familia de columnas tiene una clave única, que en el
ejemplo es el RUT. Luego existe un conjunto de pares atributo/valor para cada columna que no son
iguales para todos los registros. Esto es diferente al concepto de tabla en una base de datos relacional,
pues si bien la familia de columnas tiene un nombre y agrupa datos, las columnas en cada registro pueden
tener diferentes componentes. La clave única de un registro puede reutilizarse en múltiples familias de
columnas, con diferentes atributos asociados en cada una.

Ejemplo
Ejemplos de este tipo de base de datos son:

• BigTable (https://cloud.google.com/bigtable/)
• Apache HBase (https://hbase.apache.org/)
• Apache Cassandra (http://cassandra.apache.org/)

2.3 Bases de datos Orientadas a Grafos


Un dominio de aplicación para que las bases de datos relacionales no resultan adecuadas es el
almacenamiento de grafos. Los grafos son estructuras de datos muy utilizadas para el modelamiento de
entidades altamente interconectadas, como los participantes en una red social, para representar las
interacciones (interactomes) entre proteínas o genes en bioinformática o para representar rutas en
sistemas de transporte.

Las bases de datos orientadas a grafos integran los


conceptos de nodo y arco en forma nativa, pudiendo ambos
tener atributos asociados. Esta característica hace posible
acceder en tiempo constante a la información de los nodos
adyacentes a un nodo cualquiera (Robinson, 2015), al
contrario de lo que ocurriría en una base de datos
relacional, pues esta tarea demoraría mucho más tiempo
por la necesidad de generar un join con los elementos
relacionados a través de las claves foráneas.

En bioinformática se han observado incrementos de rendimiento al usar bases de datos orientadas a


grafos en lugar de bases relacionales, los cuales van desde 36 veces mejor para obtener los vecinos de
un nodo, hasta un incremento de 2441 veces mejor para calcular el camino más corto entre los nodos de
un grafo (Have, 2013).

Pág. 14
Módulo: 1
Curso: Bases de datos no estructuradas

Ejemplo
Ejemplos de este tipo de bases de datos son:

• Neo4j (https://neo4j.com/)
• AllegroGraph (https://franz.com/agraph/allegrograph/): esta base de datos tiene la
particularidad de almacenar los grafos en un formato llamado triple, basado en la lógica de primer
orden, compuesto de un sujeto un predicado y un objeto.

Cabe destacar que al contrario de otras bases de datos NoSQL, las dos bases de datos orientadas a
grafos indicadas anteriormente están diseñadas con la filosofía ACID, al igual que las bases de datos
relacionales.

2.4 Bases de datos Documentales:


El último tipo de base de datos NoSQL que revisaremos son las bases de datos orientadas a documentos.
Este tipo de base de datos tiene la característica de que no tiene un esquema de datos particular, sino
que se orienta a almacenar documentos representados usando un lenguaje de intercambio de datos
como XML o JSON. Estas bases de datos proveen mecanismos para recuperar documentos a partir de
una o varias de sus propiedades, lo que permite buscar documentos potencialmente heterogéneos en su
contenido sin necesidad de tener un modelo de datos predefinido. Otra de sus características es que
habitualmente las operaciones de
actualización se realizan sobre un único
registro a la vez, ya que están orientadas al
procesamiento de documentos
independientes entre sí, lo cual es una
característica a considerar al momento de
evaluar su uso. Al igual que las bases
relacionales soportan el concepto de índice
para acelerar las búsquedas.

Ejemplo
Algunas bases de datos documentales son:

• MongoDB (https://www.mongodb.com/): usa JSON binario para almacenar los datos.


• CouchDB (https://couchdb.apache.org/)

Pág. 15
Módulo: 1
Curso: Bases de datos no estructuradas

3. JSON y Bases NoSQL


El último tipo de bases de datos NoSQL que revisamos fueron las
bases orientadas a documentos. Éstas bases de datos se
caracterizaban por estar diseñadas para el almacenamiento de
conjuntos de documentos no relacionados entre sí, los cuales se
almacenan asociados a una clave única (como en las bases
clave/valor) y cuyos atributos no deben ajustarse a ninguna
definición de esquema. Para permitir esta flexibilidad, estas bases
de datos utilizan formatos de intercambio de datos originalmente
utilizados en los servicios web REST, tales como XML y JSON, por
ser ampliamente conocidos, tener un buen soporte en los lenguajes de programación y porque están
diseñados para modelar cualquier tipo de información. Ambos formatos además tienen la posibilidad de
representar datos organizados jerárquicamente, pues posible generar múltiples niveles de anidamiento.

3.1 JSON vs XML


XML (Extensible Markup Language) es un lenguaje de etiquetas muy parecido a HTML, en donde la
información se almacena asociada a tags. Cada tag es el nombre de un atributo, y su contenido el valor.
Recordemos el ejemplo de los datos de un estudiante, que usamos al mostrar el funcionamiento de las
base de datos de columna ancha:

Figura 4. Datos típicos de un estudiante


Fuente: Elaboración propia

En la figura 4, los datos del estudiante tienen como clave su número de RUT y los estudiantes poseen
cinco atributos, cada uno de los cuales tiene un nombre y un valor. Una posible representación de esta
información en XML podría ser como en la figura 5:

Pág. 16
Módulo: 1
Curso: Bases de datos no estructuradas

Figura 5. XML con los datos de un estudiante


Fuente: Elaboración propia

En la figura 5, se observa como para cada atributo, su nombre se indica entre etiquetas, la cuales
comienzan con un tag de inicio, contienen un valor y terminan con un tag de cierre.

Ejemplo

Por ejemplo, para el atributo dirección, el tag de inicio es <direccion>, el valor es Uno Norte 3 y
tag de cierre es </direccion>.

Para que un documento XML se considere válido, cada tag tiene que tener un inicio, un contenido y un
valor. Es posible anidar tags, como queda en evidencia por la forma en que se define el estudiante, que
es una agrupación de tags que son sus atributos. Este formato tiene la ventaja de que es legible para las
personas y se puede serializar y deserializar con relativa facilidad solamente usando textos para su
transporte, lo que lo hace muy útil como formato de retorno en servicios web. Sin embargo, esta ventaja
se convierte en una desventaja cuando se requiere intercambiar múltiples documentos XML para
convertirlos en objetos de un lenguaje de programación en particular, pues cada documento XML debe
ser interpretado y luego sus etiquetas utilizadas para inicializar los atributos de un objeto.

Para facilitar este tipo de procesamiento, especialmente en los servicios Web, se creó JSON (Javascript
Object Notation), que también es un formato de texto en el que se puede serializar/deserializar objetos,
sigue siendo legible para las personas, pero que es mucho más rápido de interpretar por lenguajes de
programación tales como Javascript o Python, de hecho JSON es fácilmente interpretable como un objeto
javascript, lo que lo hace muy útil para el intercambio de datos entre servicios web y aplicaciones AJAX
en páginas web. JSON tiene una sintaxis basada en pares atributo/valor pero sin etiquetas, sino que se
usan los dos puntos como separadores. La información del estudiante de la figura 5, se podría representar
en JSON como aparece en la figura 6:

Pág. 17
Módulo: 1
Curso: Bases de datos no estructuradas

Figura 6. JSON con los datos del estudiante


Fuente: Elaboración propia

En la figura 6, se puede ver como la representación JSON de la información es más compacta, sin sacrificar
la legibilidad, ya que aún puede ser leída e interpretada con facilidad. Adicionalmente este formato se
puede convertir rápidamente en un objeto ya que cada par es un nombre de atributo y su valor, en el
mismo formato que se utiliza por ejemplo en las tablas de hash (o diccionarios), que son la base de la
implementación de los objetos en lenguajes como Javascript y Python, los cuales comparten la
característica de no indicar en forma explícita los tipos de datos y de que se pueden agregar nuevos
atributos a cualquier objeto, fuera de su definición original.

Saber más

Un buen tutorial de JSON puede encontrarse en https://www.w3schools.com/js/js_json_intro.asp.

Es por sus características, que JSON es el lenguaje que se utiliza para representar la información en bases
como MongoDB (con una variante llamada BSON, que consiste de convertir el texto JSON en un binario
que es más fácil de escribir y leer de disco) y para agregar información en bases de datos como
Cassandra, que son las bases NoSQL que estudiaremos en profundidad en este curso.

Pág. 18
Módulo: 1
Curso: Bases de datos no estructuradas

JSON soporta varios tipos de datos, los cuales se infieren a partir de la forma en que los datos están
escritos:

Textos Los cuales se indican entre comillas dobles o comillas simples.

Números Que se indican fuera de comillas.


Booleanos Que se indican con la palabra true o false, al igual como en javascript.

Que se indican con la palabra null, como en javascript, y que permiten definir un
Nulos
atributo nulo.

Que se indican agrupando valores entre corchetes [ ], al igual que en javascript o


Arreglos Python, separando los valores por comas (,). Un arreglo puede estar compuesto de
cualquier otro tipo de datos válido en JSON.

Los objetos se declaran usando llaves { }, indicando cada atributo con un string entre
comillas, dos puntos (:) como separador y un valor que puede ser cualquier tipo de
Objetos
dato JSON válido. La sintaxis de los objetos es similar a la de los diccionarios en
javascript o Python.

En el ejemplo de la figura 3 creamos un objeto que tiene seis atributos de tipo texto. Ahora le
agregaremos un atributo booleano que indicará la vigencia o no del estudiante, y un atributo numérico
que será su año de ingreso.

Figura 7. JSON del estudiante con atributos booleanos y numéricos


Fuente: Elaboración propia

Crearemos una segunda entidad llamada curso, que tendrá un nombre y una sigla, y que tendrá un
arreglo de estudiantes.

Pág. 19
Módulo: 1
Curso: Bases de datos no estructuradas

Lo primero que haremos será definir el JSON del curso, como aparece en la figura 8.

Figura 8. JSON del curso


Fuente: Elaboración propia

Ahora agregaremos en el curso un atributo de tipo arreglo, que serán los estudiantes:

Figura 9. JSON del curso con el atributo estudiantes vacío


Fuente: Elaboración propia

Finalmente, incorporamos en el atributo estudiantes el JSON del estudiante que vimos anteriormente
(figura 10):

Figura 10. JSON del curso con un estudiante


Fuente: Elaboración propia

Pág. 20
Módulo: 1
Curso: Bases de datos no estructuradas

De esta forma se puede representar cualquier tipo de objeto utilizando el formato JSON. JSON no tiene
validaciones más allá de aquellas relacionadas con su sintaxis, por lo que depende del programador es
mantener la coherencia en el nombre de las etiquetas a través de diferentes objetos.

JSON es un formato ampliamente utilizado en aplicaciones Web, por lo que bases de datos como
MongoDB lo usan tanto para almacenar la información como para retornarla como resultado de las
consultas. Esto facilita el paso de la información desde la capa de persistencia a la de la lógica de negocio
implementada en los servicios, y también en la capa de presentación donde el objeto JSON puede
deserializarse y ligarse con alguna etiqueta HTML para mostrarse al cliente.

3.2 Uso de JSON en servicios Web REST


En los siguientes módulos del curso aprenderemos
como crear, gestionar y acceder las bases de datos
NoSQL Cassandra y MongoDB, para lo cual es útil
tener experiencia en representar objetos usando
JSON. Para practicar este conocimiento, crearemos
un sencillo servicio web del tipo REST que retornará
un objeto JSON. En esta etapa del curso, cuando aún
no contamos con una base de datos, el objeto JSON
lo crearemos en memoria; más adelante lo
obtendremos de alguna de las dos bases de datos
que estudiaremos.

El objeto JSON que utilizaremos será el objeto curso


de la figura 8. Para crear este ejemplo utilizaremos el
lenguaje de programación Javascript, el framework
node.js (https://nodejs.org/es/) y el módulo express
(https://expressjs.com/es/). Dado que el objeto de
nuestro curso son las bases de datos, basaremos nuestro código de prueba en el ejemplo básico de
express, el cual pueden acceder en el siguiente link (http://expressjs.com/es/starter/hello-world.html).

Pág. 21
Módulo: 1
Curso: Bases de datos no estructuradas

Procedimiento

Para crear este ejemplo deberán cumplir los siguientes prerrequisitos:

1. Disponer de un editor de texto (notepad es suficiente), aunque es recomendable usar


algún editor que ayude con la sintaxis de javascript, como Visual Studio Code
(https://code.visualstudio.com/) o Atom (https://atom.io/).
2. Descargar e instalar node.js versión 8.9.1 o superior.
3. Crear una carpeta llamada curso.
4. Instalar express dentro de la carpeta curso. Para hacerlo, se debe ingresar a la carpeta
desde la línea de comando y ejecutar npm install express.

Una vez que se disponga de todo el software necesario, se requiere copiar el código de la Figura 11 en
un archivo de texto llamado cursos.js y grabarlo dentro de la carpeta curso.

Figura 10. Código del ejemplo


Fuente: Elaboración propia

En la demostración que acompaña a este módulo explicaremos paso por paso en qué consiste el
programa. Una vez copiado completamente en el archivo cursos.js, se debe ingresar en la carpeta curso
(donde se instaló el módulo express y está el archivo cursos.js) y ejecutar el comando node cursos.js.
Si todo funcionó correctamente en la consola deberemos ver un mensaje como el de la Figura 11:

Pág. 22
Módulo: 1
Curso: Bases de datos no estructuradas

Figura 11. El servidor se encuentra activo


Fuente: Elaboración propia

Ahora para ver el funcionamiento de nuestro servicio Web debemos utilizar cualquier navegador y visitar
el URL http://localhost:3000/getCursos. Si todo funciona correctamente, en nuestro navegador
debiéramos ver el JSON de los cursos, tal como aparece en la figura 12:

Figura 12. El JSON retornado por el servicio REST


Fuente: Elaboración propia

Pág. 23
Módulo: 1
Curso: Bases de datos no estructuradas

Cierre
En este módulo comprendimos como la aparición de empresas de alcance global como Amazon,
Facebook o Google hizo necesaria la creación de nuevos sistemas de base de datos, que orientaran su
diseño hacia la escalabilidad en lugar de la consistencia. Este cambio en los enfoques generó un paso de
la filosofía ACID de las bases de datos estructuradas tradicionales a la filosofía BASE de gran parte de las
bases NoSQL. Este cambio de filosofía no está exento de dificultades, ya que un comportamiento
eventualmente consistente y la tolerancia a la presencia de información que está pendiente o en proceso
de modificación requiere que el desarrollador de la aplicación lo considere en su implementación,
proveyendo en algunos casos medios para gestionar éstas particularidades; esto nos indica que no todas
las aplicaciones necesariamente deberán portarse a una base de datos NoSQL, podríamos resumir los
escenarios en que una base de datos NoSQL son una opción a considerar cuando:

• Los requerimientos de escalabilidad y disponibilidad son más importantes que los de perfecta
consistencia.
• En aplicaciones de BigData, en donde un procesamiento efectivo de la información hace que un
modelo relacional basado en un único servidor y en consultas SQL que utilizan JOIN para integrar
la información, provocarían una degradación en el desempeño del sistema. En este mismo
sentido, también son una opción cuando se requiera implementar mecanismos de procesamiento
paralelo de la información, como MapReduce, que será tratado en profundidad en el módulo 4
de este curso.
• Finalmente, vimos que hay información que no se adapta bien a un modelo relacional, como el
almacenamiento de documentos XML o JSON, por sus requerimientos de flexibilidad, o
información que naturalmente se representaría usando estructuras de datos como los grafos, los
cuales tienen múltiples aplicaciones en sistemas de transporte, redes sociales y bioinformática.

Pág. 24

También podría gustarte