UNIVERSIDAD TÉCNICA DE MACHALA

Maestría en Software

Módulo:
Bases de datos NoSQL

Tema:
Taller Individual 1 - Bases de Datos NoSQL

Alumno
Byron David Aguilar Tigre

Docente
Ing. Nelson Oswaldo Piedra Pullaguari

MACHALA - 2021
Objetivo: Conocer diferentes tipos de bases NoSQL y sus principales
características.

1. Analice el teorema de CAP y su relevancia al diseñar

aplicaciones distribuidas y elegir un almacén de datos
relacional o NoSQL.

En Ciencias de la Computación se enunció un teorema que nos dice

que en un sistema distribuido de almacenamiento de datos no
podemos garantizar consistencia y disponibilidad (para
actualizaciones), al tiempo cuando el sistema sufre una partición
(queda separado en dos o más islas). Este es el Teorema CAP, por
Consistency (Consistencia), Availability (Disponibilidad) y
Partition Tolerance (Tolerancia al Particionamiento).

Lo que dice el teorema es que solo puedes garantizar dos de estos tres atributos

CP (Consistencia y Tolerancia al particionamiento): Esto quiere

decir que no se garantiza la disponibilidad, hay clientes que por
ejemplo requieren que el sistema esté disponible 100% del tiempo o
muy cerca, con bases de datos que cumplan con CP no es posible
garantizar esto, no quiero decir que no se pueda lograr en cierto
nivel, pero el sistema está enfocado en aplicar los cambios de
forma consistente aunque se pierda comunicación con algunos nodos.
AP (Disponibilidad y Tolerancia al particionamiento): En este caso
no se garantiza que los datos sean iguales en todos los nodos todo
el tiempo, en este caso el sistema siempre estará disponible para
las peticiones aunque se pierda la comunicación entre los nodos.

CA (Consistencia y disponibilidad): En este caso no se puede

permitir el particionado de los datos, porque se garantiza que los
datos siempre son iguales y el sistema estará disponible
respondiendo todas las peticiones.

2. ACID es el conjunto de propiedades que garantizan que las

transacciones de una Base de Datos se procesen de manera
fiable. Explicar cuáles son estas características que deben
observarse

El modelo de transacción de la base de datos ACID asegura que una

transacción realizada sea siempre consistente. Esto lo convierte
en una buena opción para las empresas que se ocupan del
procesamiento de transacciones en línea (por ejemplo,
instituciones financieras) o del procesamiento analítico en línea
(por ejemplo, almacenamiento de datos). Estas organizaciones
necesitan sistemas de bases de datos que puedan manejar muchas
pequeñas transacciones simultáneas. Debe haber tolerancia cero
para estados no válidos.

ACID significa:

Atómico: cada transacción se lleva a cabo correctamente o el

proceso se detiene y la base de datos vuelve al estado anterior al
inicio de la transacción. Esto asegura que todos los datos de la
base de datos sean válidos.
Consistente: una transacción procesada nunca pondrá en peligro la
integridad estructural de la base de datos.
Aislado: las transacciones no pueden comprometer la integridad de
otras transacciones al interactuar con ellas mientras aún están en
curso.
Durable: los datos relacionados con la transacción completada
persistirán incluso en los casos de cortes de energía o de red. Si
una transacción falla, no afectará los datos manipulados.

Ejemplo de caso de uso de ACID

Las instituciones financieras utilizarán casi exclusivamente bases

de datos ACID. Las transferencias de dinero dependen de la
naturaleza atómica del ACID.

Una transacción interrumpida que no se elimina inmediatamente de

la base de datos puede causar muchos problemas. El dinero podría
debitarse de una cuenta y, debido a un error, nunca acreditarse en
otra.

¿Qué bases de datos son compatibles con ACID?

Una forma segura de asegurarse de que su base de datos sea

compatible con ACID es elegir un sistema de administración de base
de datos relacional. Estos incluyen MySQL, PostgreSQL, Oracle,
SQLite y Microsoft SQL Server.

Algunos DBMS NoSQL, como CouchDB de Apache o Db2 de IBM, también

poseen un cierto grado de conformidad con ACID. Sin embargo, la
filosofía detrás del enfoque NoSQL para la gestión de bases de
datos va en contra de las estrictas reglas ACID. Por lo tanto, las
bases de datos NoSQL no son la opción recomendada para quienes
necesitan entornos estrictos.

3. Explore conceptos generales de los paradigmas NOSQL, así:

a. Características o atributos generales de las bases de
datos NoSQL.

Las principales características de una base de datos no relacional

son las siguientes:

● La información no se almacena en tablas sino a través de

documentos.
● Son bases de datos muy útiles para organizar y gestionar
información no estructurada, o cuando no se tiene una noción
clara de los datos a almacenar.
● Son bases de datos con alto grado de escalabilidad y están
diseñadas para soportar grandes volúmenes de datos.
● No utilizan el lenguaje SQL para consultas, aunque sí lo
pueden usar como herramienta de apoyo.
 ● Es un sistema de almacenamiento de datos relativamente nuevo,
y como tal, todavía no posee un sistema estandarizado.
● A diferencia de las no relacionales, no garantizan el
cumplimiento de las cualidades ACID, esto es, atomicidad,
consistencia, integridad y durabilidad.

b. Tipos de bases de datos NoSQL

Existen diferentes tipos de bases de datos no relacionales, en

función del método que emplean para almacenar la información.

Clave-valor: Se trata de bases de datos no relacionales que

almacenan la información en base a pares de clave valor. Es decir,
cada clave sirve como un identificador único, y a cada una de
ellas se le aplica un valor. Son especialmente usadas a la hora de
almacenar datos de juegos, aplicaciones o aparatos que funcionan
mediante el internet de las cosas (IoT).

Documentos: En una base de datos relacional basada en documentos la

información se representa como objetos o documentos JSON. Su
principal ventaja es que los documentos son de naturaleza
flexible, semiestructurada y jerárquica, lo que facilita a los
desarrolladores las tareas de almacenamiento, gestión y consulta
de datos. Es un modelo usado habitualmente en sistemas de
administración de contenidos o para gestionar perfiles de
usuarios.

Gráficos: Las bases de datos no relacionales basadas en gráficos

están pensadas para crear relaciones y navegar por ellas. Las
entidades de datos se almacenan mediante nodos y los bordes son
los que crean las relaciones entre entidades. Con frecuencia las
bases de datos gráficas se emplean en redes sociales, sistemas de
detección o prevención de fraudes o sistemas de recomendaciones.

En memoria: Son bases de datos no relacionales diseñadas para

ofrecer respuestas en milisegundos y soportar grandes picos de
tráfico. Un ejemplo de bases de datos en memoria son las empleadas
en tablas de clasificaciones de juegos o en herramientas para
hacer análisis en tiempo real.
Bases de datos multivalor
Las bases de datos multivalor son sistemas interesantes que
incorporan diferentes características multidimensionales y NoSQL
para la clasificación y manejo de los datos. Estas BBDD comparten
significativas similitudes con los modelos relacionales
tradicionales. Ambos esquemas contienen tablas. Pero que esto no
te engañe, las BBDD multivalor proporcionan un esquema de trabajo
menos rígido.
Orientadas a objetos: Como bien lo indica su nombre, las BBDD de
este tipo están conformadas por objetos. Estos objetos pueden ser
de diferentes tipos, sobre los que se definen unas operaciones que
determinan sus propiedades de interacción. Las Bases de datos
orientadas a objetos han revivido el interés de los usuarios
gracias a sus características principales.

Tabulares: Una BBDD tabular no es más que la estructuración de una

BBDD en forma de tabla. Incorpora elementos en columnas y líneas.
Cada una de las celdas genera intersecciones entre las columnas y
las líneas. A estas intersecciones se les asigna una numeración
única para establecer un orden eficiente de los datos. Están
pensadas para grandes volúmenes de datos.

De Arrays: Las Bases de datos arrays sirven para trabar colecciones

de datos conocidas como raster data. Sitúan los datos en una
cuadrícula regular con más de dos dimensiones. Estas bases de
datos se utilizan para representar simulaciones, sensores y datos
estadísticos. Son capaces de manejar volúmenes de datos
importantes ofreciendo flexibilidad y escalabilidad.

c. Describa dos modelos de datos NoSQL y describa con

detalle las características

● Modelo y Meta-modelo conceptual: Permitirá entender la

relación y la organización de los posibles conceptos a alto
nivel describiéndolos en más de un dominio.
● Metamodelo lógico: Permite visualizar todos los campos
susceptibles a ser utilizados en los conceptos.
● Modelo y Meta-modelo físico: Este modelo extiende el
meta-modelo lógico y en él se describen las distintas formas
en las que un concepto o esquema puede ser almacenado
físicamente. Esta visualización permite verificar los
modelos/meta-modelos conceptual y lógico para, más tarde,
visualizar las bases de datos en funcionamiento.

Modelo y meta-modelo conceptual:

A continuación vemos un modelo en 2 dimensiones. Por un lado, en
la dimensión de negocio se describe el concepto Person o persona.
Por otro lado, en la dimensión de aplicación, el concepto Person
se desglosa en tres entidades: Person se compone de
Identification, y se le agrega Address, es decir, una persona debe
tener al menos una identificación y puede tener al menos una
dirección.
Si nuestro modelo representa una base de datos documental.
Agregamos al modelo conceptual el dominio de infraestructura, en
el que se indican los tipos de documentos físicos que se van a
crear, ademas, se indicara qué conceptos van a almacenar, como se
puede ver a continuación:

El artefacto Person (ArchiMate Artifact) representa a un tipo de

documento NoSql que internamente describe a los conceptos Person e
Identification, paralelamente un artefacto Address almacenará sólo
un concepto de su mismo nombre. Por lo tanto, el artefacto Person
en JSON, tiene una estructura similar a la que se ve a
continuación:
Cabe resaltar que con el modelo anterior no se quiere decir que
existen solo dos documentos, lo que se muestra es una
representación de los tipos de documentos que pueden existir en la
base de datos. Si se desea ser más explícito con el diseño, se
pueden agregar más artefactos en el dominio de infraestructura,
que puede servir para describir cómo escalar horizontalmente las
bases de datos, a modo de ejemplo.

A continuación vemos el diseño completo. En él que se distinguen

dos partes:

● El dominio de aplicación se concebirá como meta-modelo

conceptual de una base de datos documental.
● Y el dominio de infraestructura como el Modelo Conceptual
En el caso de que de bases de datos de gráfos, el meta-modelo
conceptual tiene la apariencia que se muestra a continuación. En
el meta-modelo se observan las tres entidades descritas
anteriormente, pero en este caso, las relaciones son de ida y
vuelta entre entidades, es decir: Person se identifica con un
Identification, un Identification identifica a un Person, un
Person vive en un Address y un Address pertenece a una o varias
Person. Este modelo es la base para luego construir los grafos.

De esta manera, el meta-modelo describe un mapa de todas las

relaciones base sobre el que luego se construye el grafo
físicamente. A continuación, agregamos un ejemplo de Modelo de
grafos que permite validar el meta-modelo. Se heredan los
conceptos del meta-modelo para probar si el modelo de grafos se
ajusta a nuestras necesidades de representación.
Meta-modelo Lógico:

A continuación, se describe el meta-modelo lógico para base de

datos documental. Para cada concepto identificado en el
meta-modelo conceptual, se describen las propiedades susceptibles
a ser utilizadas, sus tipos ( cadenas, numéricos, etc), la
cardinalidad entre clases. Las relaciones entre conceptos,
dependen de las que se permitan dentro de un documento NoSQL.

Si se trata de una base de datos de grafos, al igual en en el el

diagrama documental, describimos las posibles propiedades y sus
tipos, en el meta-modelo lógico se respetan las relaciones de ida
y vuelta del meta -modelo conceptual.

Se define un meta-modelo lógico y no como modelo lógico, porque en

lugar de describir un futuro modelo lógico, se describe un patrón
de como debe crecer y evolucionar una base de datos NoSQL. Es
decir, sirve de guía para saber como relacionar un nuevo concepto,
agregar correctamente una propiedad a un concepto adecuado y tener
una referencia del tipo que debería tener. Por otro lado, nos
ayuda a medir el impacto, cuando es necesario evolucionar el
esquema.

Webgrafía

● Lizeth, Y. (2017, noviembre 21). Qué es el teorema CAP y cómo

elegir la base de datos para tu proyecto. Platzi.
https://platzi.com/blog/que-es-el-teorema-cap-y-como-elegir-l
a-base-de-datos-para-tu-proyecto/
● ACID vs. BASE: Comparison of Database Transaction Models.
(2020, noviembre 25). https://phoenixnap.com/kb/acid-vs-base
● Tablado, F. (2020, septiembre 9). Base de datos no relacional.
¿Qué es? Características y ejemplos. AyudaLeyProteccionDatos.
https://ayudaleyprotecciondatos.es/bases-de-datos/no-relacion
al/
● Bases de Datos NoSQL. (2019, junio 4).
https://www.grapheverywhere.com/bases-de-datos-nosql-marcas-t
ipos-ventajas/
● Charito. (2018, agosto 3). Modelos de datos NoSQL.
https://eaminds.com/2018/08/03/modelando-nosql-data-bases/