Taller NoSQL
Joger Ivan Muñoz Dueñas
Niver Emiro Vides Daza
Samuel Gerard Alape Hastamorir
David Santiago DiGregorio Lombana
Miguel Angel Guativa
Facultad de Ingeniería
Asignatura: Bases de Datos
Docente:
Cristhian Fernando Lara Espejo
Sede Bogotá, Colombia
Junio 10 del 2026
Taller NoSQL
Contenido
Contenido i
1 Objetivos 1
1.1 Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Marco Teórico 2
2.1 Bases de datos NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Teorema CAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Modelos ACID y BASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.4 Persistencia Políglota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Metodología 4
3.1 Selección del caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Identificación de usuarios y datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Análisis de patrones de consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4 Evaluación de tecnologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Desarrollo del Taller y Resultados 6
4.1 Parte 1: Selección del caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1 Caso elegido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2 Descripción del caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.3 Tipos de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.4 Tipos de datos almacenados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Parte 2: Patrones de consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1 Pregunta 1: Patrones de consulta frecuentes . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2 Pregunta 2: Estimación de escalabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Parte 3: Análisis CAP y ACID vs BASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1 Pregunta 3: Teorema CAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.2 Pregunta 4: ACID vs BASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.3 Pregunta 5: Escalamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
i
Taller NoSQL
4.4 Parte 4: Selección del modelo NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4.1 Pregunta 6: Comparación de modelos de bases de datos . . . . . . . . . . . . . . . . . 9
4.4.2 Pregunta 7: Modelo recomendado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4.3 Persistencia políglota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5 Parte 5: Diseño del modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5.1 Pregunta 8: Modelo de datos propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5.2 Pregunta 9: Consultas propuestas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6 Parte 6: Bases de datos vectoriales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5 Análisis y Discusión 13
5.1 Selección del modelo documental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 Implicaciones del teorema CAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3 Ventajas de la persistencia políglota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4 Limitaciones de la propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6 Conclusiones 15
7 Referencias 16
A Anexos 17
A.1 Desarrollo manuscrito del taller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
ii
Taller NoSQL
1 Objetivos
1.1 Objetivo general
Analizar y diseñar una solución de almacenamiento de datos para un sistema bancario utilizando tecnologías
NoSQL, evaluando diferentes modelos de bases de datos distribuidas y seleccionando la arquitectura más
adecuada de acuerdo con los requerimientos de consistencia, disponibilidad, escalabilidad y rendimiento del
sistema.
1.2 Objetivos específicos
Identificar los principales actores, datos y patrones de consulta presentes en un sistema bancario.
Analizar los requerimientos de almacenamiento, escalabilidad y procesamiento de información asocia-
dos al caso de estudio.
Evaluar las implicaciones del teorema CAP y de los modelos ACID y BASE en el diseño de sistemas
distribuidos.
Comparar diferentes tecnologías de bases de datos relacionales y NoSQL para determinar sus ventajas
y limitaciones dentro del contexto planteado.
Diseñar un modelo de datos documental que represente la información de clientes, cuentas bancarias
y préstamos.
Proponer una arquitectura basada en persistencia políglota que aproveche las fortalezas de diferentes
tecnologías de almacenamiento.
Formular consultas representativas sobre el modelo de datos diseñado para validar su funcionalidad.
1
Taller NoSQL
2 Marco Teórico
2.1 Bases de datos NoSQL
Las bases de datos NoSQL surgieron como una alternativa a los sistemas de gestión de bases de datos
relacionales tradicionales, con el objetivo de responder a las necesidades de escalabilidad, disponibilidad
y manejo de grandes volúmenes de información generados por aplicaciones modernas. A diferencia de los
sistemas relacionales, las bases de datos NoSQL no dependen necesariamente de esquemas rígidos ni de
relaciones complejas entre tablas, lo que permite una mayor flexibilidad en el almacenamiento de datos.
Dentro de las principales categorías de bases de datos NoSQL se encuentran los modelos documentales,
clave-valor, orientados a columnas y basados en grafos. Cada uno de estos modelos ofrece ventajas específicas
dependiendo de los requerimientos de la aplicación.
2.2 Teorema CAP
El teorema CAP establece que un sistema distribuido no puede garantizar simultáneamente consistencia
(Consistency), disponibilidad (Availability) y tolerancia a particiones (Partition Tolerance). En presencia de
fallos de comunicación entre nodos, el sistema debe priorizar únicamente dos de estas propiedades.
La consistencia garantiza que todos los usuarios observen la misma información; la disponibilidad asegura
que el sistema responda a las solicitudes realizadas; y la tolerancia a particiones permite que el sistema
continúe funcionando aun cuando existan problemas de comunicación entre los nodos de la infraestructura.
2.3 Modelos ACID y BASE
El modelo ACID define un conjunto de propiedades para garantizar la confiabilidad de las transacciones en
bases de datos. Estas propiedades corresponden a atomicidad, consistencia, aislamiento y durabilidad.
Por otro lado, el modelo BASE constituye una aproximación más flexible utilizada frecuentemente en siste-
mas NoSQL distribuidos. Este enfoque prioriza la disponibilidad y la escalabilidad mediante los principios de
disponibilidad básica (Basically Available), estado flexible (Soft State) y consistencia eventual (Eventually
Consistent).
La elección entre ACID y BASE depende de los requerimientos específicos de la aplicación y del equilibrio
deseado entre consistencia, disponibilidad y rendimiento.
2
2. Marco Teórico 2.4. Persistencia Políglota
2.4 Persistencia Políglota
La persistencia políglota consiste en utilizar diferentes tecnologías de almacenamiento dentro de una misma
arquitectura, aprovechando las fortalezas particulares de cada sistema gestor de bases de datos.
Este enfoque permite seleccionar la tecnología más adecuada para cada tipo de información o patrón de
acceso. Por ejemplo, una aplicación puede utilizar una base de datos documental para almacenar información
de clientes, una base de datos orientada a columnas para gestionar grandes volúmenes de transacciones y
una base de datos en memoria para optimizar consultas frecuentes mediante mecanismos de caché.
3
Taller NoSQL
3 Metodología
3.1 Selección del caso de estudio
Para el desarrollo del presente taller se seleccionó un sistema bancario simplificado como caso de estudio.
Este sistema permite analizar diferentes problemáticas asociadas al almacenamiento y gestión de información
financiera, incluyendo clientes, cuentas bancarias, préstamos, transacciones y sucursales.
La elección de este caso resulta adecuada debido a que combina requerimientos de consistencia, disponibilidad
y escalabilidad, aspectos fundamentales en el diseño de arquitecturas modernas de bases de datos.
3.2 Identificación de usuarios y datos
Inicialmente se identificaron los principales actores que interactúan con el sistema:
Clientes.
Operadores o administradores.
Gerentes de sucursal.
Posteriormente se determinaron los tipos de información que deben almacenarse dentro de la base de datos:
Información de clientes.
Información de cuentas bancarias.
Historial de transacciones.
Información de préstamos.
Información de sucursales y empleados.
3.3 Análisis de patrones de consulta
Con el fin de seleccionar la tecnología de almacenamiento más adecuada, se identificaron las consultas más
frecuentes realizadas sobre el sistema. Entre ellas se encuentran:
Consulta de información de clientes.
Consulta de cuentas bancarias.
4
3. Metodología 3.4. Evaluación de tecnologías
Consulta de transacciones.
Consulta de préstamos.
Consulta de sucursales y empleados.
Adicionalmente se realizó una estimación del volumen de datos, frecuencia de consultas y crecimiento espe-
rado del sistema, permitiendo evaluar los requerimientos de escalabilidad de la solución propuesta.
3.4 Evaluación de tecnologías
A partir de los requerimientos identificados se analizaron diferentes alternativas tecnológicas, considerando
bases de datos relacionales y NoSQL. Para ello se estudiaron aspectos relacionados con:
Consistencia de los datos.
Disponibilidad del sistema.
Tolerancia a particiones.
Escalabilidad horizontal.
Flexibilidad del esquema de almacenamiento.
Finalmente se compararon tecnologías como PostgreSQL/MySQL, MongoDB y Cassandra, seleccionando la
arquitectura que mejor se adapta a las necesidades del caso de estudio.
5
Taller NoSQL
4 Desarrollo del Taller y Resultados
4.1 Parte 1: Selección del caso
4.1.1 Caso elegido
El caso seleccionado corresponde a un Sistema Bancario Simplificado, encargado de gestionar informa-
ción relacionada con clientes, cuentas bancarias, transacciones, sucursales, tarjetas de crédito y préstamos.
Este sistema permite centralizar la información financiera de los usuarios y facilitar la administración de los
distintos productos ofrecidos por la entidad bancaria.
4.1.2 Descripción del caso
La base de datos propuesta tiene como objetivo almacenar y administrar la información de los clientes
pertenecientes a una entidad bancaria, así como los diferentes productos financieros asociados a ellos. El
sistema debe permitir consultar de manera eficiente información sobre cuentas bancarias, préstamos, tarjetas
de crédito, transacciones y sucursales.
Además, la solución debe garantizar la integridad de la información, facilitar la trazabilidad de las operacio-
nes realizadas por los clientes y permitir que los funcionarios de la entidad puedan gestionar adecuadamente
los productos y servicios ofrecidos.
4.1.3 Tipos de usuarios
Los principales actores que interactúan con el sistema son:
1. Cliente: persona natural o jurídica que posee productos financieros dentro de la entidad bancaria.
Puede consultar información de sus cuentas, realizar transacciones y solicitar nuevos productos finan-
cieros.
2. Operador o Administrador: funcionario encargado de la gestión de clientes, validación de opera-
ciones, administración de productos financieros y atención de solicitudes realizadas por los usuarios.
3. Gerente de sucursal: responsable de supervisar el funcionamiento de una sucursal bancaria, realizar
consultas de información consolidada y gestionar los recursos asociados a su oficina.
4.1.4 Tipos de datos almacenados
La base de datos debe almacenar, entre otros, los siguientes tipos de información:
6
4. Desarrollo del Taller y Resultados 4.2. Parte 2: Patrones de consulta
Datos de clientes: número de identificación, nombre completo, dirección, teléfono y correo electró-
nico.
Datos de cuentas bancarias: número de cuenta, tipo de cuenta, saldo disponible, fecha de apertura
y estado de la cuenta.
Datos transaccionales: consignaciones, retiros, transferencias, pagos, fecha y hora de cada operación.
Datos de préstamos y créditos: número de préstamo, valor aprobado, tasa de interés, cuotas
pendientes y fecha de vencimiento.
Datos de sucursales y empleados: código de sucursal, dirección, nombre de empleados, cargo y
área de trabajo.
4.2 Parte 2: Patrones de consulta
4.2.1 Pregunta 1: Patrones de consulta frecuentes
A partir de los requerimientos del sistema bancario, se identificaron las consultas y operaciones más fre-
cuentes mostradas en la Tabla 4-1.
Consulta Descripción Frecuencia Dato principal
Consulta de cliente Obtener la información general de un cliente y Alta Clientes
sus productos asociados.
Consulta de cuentas Consultar cuentas bancarias asociadas a un Alta Cuentas
cliente.
Consulta de transac- Consultar el historial de movimientos realizados Alta Transacciones
ciones por un cliente.
Consulta de présta- Consultar créditos activos, cuotas pendientes y Media Préstamos
mos fechas de vencimiento.
Consulta de sucursa- Obtener información de sucursales y personal Baja Sucursales y emplea-
les y empleados administrativo. dos
Tabla 4-1: Consultas frecuentes del sistema bancario.
4.2.2 Pregunta 2: Estimación de escalabilidad
Con el fin de analizar los requerimientos de almacenamiento y procesamiento del sistema, se plantean los
siguientes valores aproximados para una entidad bancaria de tamaño medio.
Métrica Valor estimado
Número de clientes registrados 500 000
Nuevas transacciones por día 200 000
Tamaño promedio de una transacción 1 KB
Volumen generado por día 200 MB
Volumen generado por mes 6 GB
Lecturas por segundo 1 000 consultas/s
Escrituras por segundo 300 operaciones/s
Tabla 4-2: Estimación de escalabilidad para el sistema bancario.
Los resultados muestran que el sistema debe manejar un volumen considerable de consultas y transacciones diarias.
Debido a este crecimiento continuo, la solución seleccionada debe permitir escalabilidad y una gestión eficiente de
grandes cantidades de información, especialmente en el almacenamiento del historial transaccional.
7
4.3. Parte 3: Análisis CAP y ACID vs BASE 4. Desarrollo del Taller y Resultados
4.3 Parte 3: Análisis CAP y ACID vs BASE
4.3.1 Pregunta 3: Teorema CAP
El teorema CAP establece que en un sistema distribuido no es posible garantizar simultáneamente las propiedades
de consistencia (Consistency), disponibilidad (Availability) y tolerancia a particiones (Partition Tolerance). En con-
secuencia, el diseño de un sistema debe priorizar dos de estas propiedades dependiendo de los requerimientos del
negocio.
Consistencia (Consistency): todos los usuarios observan la misma versión de los datos en un momento
determinado. Si se actualiza un registro, los demás usuarios deben visualizar inmediatamente la información
actualizada.
Disponibilidad (Availability): el sistema debe responder a todas las solicitudes realizadas por los usuarios,
incluso ante fallos parciales de la infraestructura.
Tolerancia a particiones (Partition Tolerance): el sistema debe continuar operando aun cuando existan
fallos de comunicación entre distintos nodos o servidores.
Para el caso de un sistema bancario, las propiedades más importantes son la consistencia y la tolerancia a particiones.
Las operaciones financieras requieren que los saldos y movimientos reflejen información correcta en todo momento.
Ante una partición de red, resulta preferible retrasar temporalmente una operación antes que permitir inconsistencias
en los datos financieros.
Por esta razón, la combinación seleccionada es CP (Consistency + Partition Tolerance).
Combinación Seleccionada
CA (Consistencia + Disponibilidad)
CP (Consistencia + Tolerancia a particiones) X
AP (Disponibilidad + Tolerancia a particiones)
Tabla 4-3: Selección de propiedades según el teorema CAP.
4.3.2 Pregunta 4: ACID vs BASE
Los sistemas de bases de datos pueden priorizar diferentes propiedades dependiendo de los requerimientos de la
aplicación. Dos de los enfoques más utilizados son ACID y BASE.
Modelo ACID
ACID es un conjunto de propiedades que garantizan la confiabilidad de las transacciones en una base de datos:
Atomicidad (Atomicity): una transacción debe ejecutarse completamente o no ejecutarse en absoluto. Si
ocurre un error durante la operación, todos los cambios realizados deben revertirse.
Consistencia (Consistency): cada transacción debe llevar la base de datos de un estado válido a otro estado
válido, respetando todas las reglas de integridad definidas.
Aislamiento (Isolation): las transacciones concurrentes no deben interferir entre sí. Los cambios realizados
por una transacción no son visibles para otras hasta que esta finalice.
Durabilidad (Durability): una vez confirmada una transacción, sus efectos permanecen almacenados per-
manentemente, incluso ante fallos del sistema.
Modelo BASE
BASE es un enfoque utilizado frecuentemente en sistemas NoSQL distribuidos y prioriza la disponibilidad y escala-
bilidad.
8
4. Desarrollo del Taller y Resultados 4.4. Parte 4: Selección del modelo NoSQL
Basically Available: el sistema permanece disponible para responder solicitudes incluso ante fallos parciales.
Soft State: el estado de los datos puede cambiar con el tiempo debido a procesos de sincronización internos.
Eventually Consistent: después de un período de propagación, todas las réplicas convergen hacia el mismo
estado consistente.
Modelo seleccionado para el caso de estudio
Para un sistema bancario resulta fundamental garantizar la integridad y exactitud de la información financiera. Cuan-
do un cliente realiza una transferencia, un retiro o un pago, los saldos involucrados deben actualizarse correctamente
y mantenerse consistentes en todo momento.
Por esta razón, el modelo ACID resulta más adecuado para el caso de estudio, ya que proporciona garantías fuertes
de consistencia y confiabilidad para las transacciones financieras.
Ejemplo de consistencia eventual
Un ejemplo de consistencia eventual dentro del contexto bancario podría ocurrir cuando una transacción realizada
en una sucursal debe replicarse hacia centros de datos ubicados en diferentes regiones geográficas. Durante algunos
segundos podrían existir diferencias temporales entre las réplicas; sin embargo, una vez finalizado el proceso de
sincronización, todas las copias almacenarán exactamente la misma información.
4.3.3 Pregunta 5: Escalamiento
Existen dos estrategias principales para aumentar la capacidad de un sistema de bases de datos:
Escalamiento vertical: consiste en aumentar los recursos de un único servidor, por ejemplo, incorporando
más memoria RAM, procesadores más rápidos o mayor capacidad de almacenamiento.
Escalamiento horizontal: consiste en distribuir la carga entre múltiples servidores o nodos, permitiendo
incrementar la capacidad del sistema mediante la adición de nuevas máquinas.
En un sistema bancario, la consistencia de la información constituye un requisito fundamental, especialmente para
las operaciones financieras y el manejo de saldos. Por esta razón, tradicionalmente los sistemas transaccionales han
favorecido arquitecturas con un fuerte control de consistencia.
Sin embargo, debido al crecimiento continuo del volumen de clientes, transacciones y consultas, también resulta
necesario contar con mecanismos que permitan escalar la infraestructura de manera eficiente. En este contexto, las
tecnologías NoSQL ofrecen alternativas de escalamiento horizontal para componentes específicos del sistema, tales
como el almacenamiento de historiales transaccionales, la gestión de sesiones o el procesamiento de grandes volúmenes
de consultas.
El principal desafío de escalamiento para el sistema bancario consiste en mantener la consistencia e integridad de los
datos mientras se incrementa la capacidad de procesamiento y almacenamiento del sistema.
4.4 Parte 4: Selección del modelo NoSQL
4.4.1 Pregunta 6: Comparación de modelos de bases de datos
Con el fin de identificar la tecnología más adecuada para el sistema bancario propuesto, se realizó una comparación
entre una base de datos relacional tradicional y dos alternativas NoSQL ampliamente utilizadas.
9
4.4. Parte 4: Selección del modelo NoSQL 4. Desarrollo del Taller y Resultados
Sistema Modelo Ventajas Desventajas
PostgreSQL / Relacional Garantiza propiedades ACID, inte- Escalabilidad horizontal más com-
MySQL gridad referencial, transacciones se- pleja y menor flexibilidad para es-
guras y alta consistencia. tructuras de datos cambiantes.
MongoDB Documental Flexibilidad en el esquema, almace- Menor rigidez en la integridad de da-
namiento en documentos JSON, fa- tos y posibles complejidades al ma-
cilidad para manejar datos hetero- nejar relaciones altamente estructu-
géneos y crecimiento progresivo de radas.
la estructura de datos.
Cassandra Columnar Alta disponibilidad, tolerancia a fa- Mayor complejidad de modelado y
llos y excelente rendimiento para consistencia eventual en muchos es-
grandes volúmenes de escritura y cenarios de uso.
lectura distribuidos.
Tabla 4-4: Comparación entre tecnologías relacionales y NoSQL.
A partir de la comparación realizada se observa que las bases de datos relacionales ofrecen mayores garantías de
consistencia, mientras que las soluciones NoSQL proporcionan ventajas significativas en términos de flexibilidad,
disponibilidad y escalabilidad para grandes volúmenes de información.
4.4.2 Pregunta 7: Modelo recomendado
Después de analizar los patrones de consulta, los requerimientos de escalabilidad y las características del sistema
bancario, se propone utilizar un modelo de base de datos documental, implementado mediante MongoDB, como
componente principal de la solución NoSQL.
La elección del modelo documental se justifica por las siguientes razones:
Patrones de consulta: gran parte de las consultas del sistema se realizan sobre información asociada a
clientes, cuentas bancarias, préstamos y productos financieros. El almacenamiento en documentos permite
agrupar información relacionada y reducir la necesidad de operaciones de unión complejas.
“‘
Naturaleza de los datos: los clientes pueden poseer diferentes combinaciones de productos financieros, tales
como cuentas de ahorro, cuentas corrientes, tarjetas de crédito o préstamos. El modelo documental ofrece
flexibilidad para representar estas estructuras sin requerir modificaciones frecuentes del esquema.
Escalabilidad: MongoDB proporciona mecanismos de particionamiento y distribución que permiten aumentar
la capacidad del sistema a medida que crece el volumen de usuarios y transacciones.
Análisis CAP: el sistema bancario requiere un alto nivel de consistencia para la información financiera
crítica. Aunque ciertos componentes pueden beneficiarse de una mayor disponibilidad, la integridad de los
datos continúa siendo una prioridad fundamental dentro de la arquitectura propuesta. “ ‘
4.4.3 Persistencia políglota
Aunque el modelo documental constituye la solución principal propuesta, se considera conveniente utilizar una
estrategia de persistencia políglota para aprovechar las fortalezas de diferentes tecnologías de bases de datos.
La arquitectura propuesta se compone de los siguientes elementos:
MongoDB: almacenamiento principal de información de clientes, cuentas bancarias y productos financieros.
Cassandra: almacenamiento distribuido de historiales transaccionales de gran volumen, aprovechando su
capacidad para manejar altas tasas de escritura y disponibilidad.
Redis: gestión de sesiones, caché de consultas frecuentes y almacenamiento temporal de información de acceso
rápido.
Esta combinación permite equilibrar consistencia, rendimiento, disponibilidad y escalabilidad, aprovechando las
fortalezas particulares de cada tecnología dentro del sistema bancario.
10
4. Desarrollo del Taller y Resultados 4.5. Parte 5: Diseño del modelo de datos
4.5 Parte 5: Diseño del modelo de datos
4.5.1 Pregunta 8: Modelo de datos propuesto
De acuerdo con la selección realizada en la sección anterior, se propone un modelo documental implementado me-
diante MongoDB. Cada cliente se almacena como un documento que contiene información personal y los productos
financieros asociados.
{
"_id": 654152,
"nombre": "Ana Torres",
"correo": "[[Link]@[Link]]([Link]
"telefono": "3001234567",
"cuentas": [
{
"numero_cuenta": "10025478",
"tipo": "Ahorros",
"saldo": 3500000
}
],
"prestamos": [
{
"id_prestamo": "P001",
"valor": 12000000,
"tasa_interes": 0.12,
"cuotas_pendientes": 18
}
]
}
En este modelo, la información principal del cliente y sus productos financieros se almacena dentro de un mis-
mo documento, facilitando consultas frecuentes y reduciendo la necesidad de operaciones de unión entre múltiples
estructuras de datos.
4.5.2 Pregunta 9: Consultas propuestas
A continuación se presentan tres consultas representativas sobre el modelo documental propuesto.
Consulta 1: Buscar un cliente por su identificador
Permite recuperar toda la información asociada a un cliente específico.
[Link](
{ "_id": 654152 }
)
Consulta 2: Consultar las cuentas bancarias de un cliente
Permite obtener únicamente la información relacionada con las cuentas bancarias de un cliente.
[Link](
11
4.6. Parte 6: Bases de datos vectoriales 4. Desarrollo del Taller y Resultados
{ "_id": 654152 },
{ "cuentas": 1, "_id": 0 }
)
Consulta 3: Consultar los préstamos activos de un cliente
Permite visualizar la información correspondiente a los préstamos registrados para un cliente.
[Link](
{ "_id": 654152 },
{ "prestamos": 1, "_id": 0 }
)
Estas consultas representan algunas de las operaciones más frecuentes dentro de un sistema bancario, donde resulta
común consultar información de clientes, productos financieros y obligaciones crediticias.
4.6 Parte 6: Bases de datos vectoriales
Las bases de datos vectoriales están diseñadas para almacenar representaciones numéricas de datos complejos, co-
nocidas como vectores o embeddings. Estas tecnologías son ampliamente utilizadas en aplicaciones de inteligencia
artificial, sistemas de recomendación, procesamiento de lenguaje natural y búsqueda semántica.
Para el caso del sistema bancario analizado en este taller, el uso de una base de datos vectorial no constituye
un requisito fundamental. La mayor parte de la información gestionada corresponde a datos estructurados, tales
como clientes, cuentas bancarias, préstamos y transacciones, los cuales pueden almacenarse eficientemente mediante
modelos documentales y otras tecnologías NoSQL tradicionales.
Sin embargo, las bases de datos vectoriales podrían resultar útiles en escenarios más avanzados relacionados con el
sector financiero. Por ejemplo, podrían emplearse para detectar patrones de fraude, identificar comportamientos atí-
picos en las transacciones, analizar perfiles de riesgo o desarrollar sistemas de recomendación de productos financieros
personalizados para los clientes.
Debido a que estas funcionalidades no forman parte de los requerimientos planteados para el sistema bancario
simplificado considerado en este taller, se concluye que la incorporación de una base de datos vectorial no es necesaria
dentro de la arquitectura propuesta.
12
Taller NoSQL
5 Análisis y Discusión
5.1 Selección del modelo documental
A partir del análisis realizado se determinó que MongoDB constituye una alternativa adecuada para el almacena-
miento de la información principal del sistema bancario. El modelo documental permite representar de forma flexible
la información de clientes, cuentas y préstamos, facilitando la evolución futura del esquema de datos sin requerir
modificaciones complejas en la estructura de almacenamiento.
Adicionalmente, la agrupación de información relacionada dentro de un mismo documento reduce la necesidad
de realizar operaciones de unión, mejorando el rendimiento de consultas frecuentes asociadas a los clientes y sus
productos financieros.
5.2 Implicaciones del teorema CAP
El análisis del teorema CAP permitió identificar que los sistemas bancarios presentan una alta dependencia de la
consistencia de los datos. En este contexto, resulta fundamental garantizar que las operaciones financieras reflejen
información correcta y actualizada en todos los nodos del sistema.
Por esta razón, la arquitectura propuesta prioriza la consistencia y la tolerancia a particiones frente a la disponibilidad
absoluta, evitando inconsistencias que puedan afectar saldos, préstamos o transacciones financieras.
5.3 Ventajas de la persistencia políglota
La estrategia de persistencia políglota permite aprovechar las fortalezas de diferentes tecnologías de almacenamiento
dentro de una misma solución.
MongoDB proporciona flexibilidad para la gestión de clientes y productos financieros. Cassandra ofrece alta dispo-
nibilidad y capacidad para manejar grandes volúmenes de transacciones distribuidas. Redis complementa la arqui-
tectura mediante mecanismos de almacenamiento en memoria que permiten acelerar consultas frecuentes y reducir
los tiempos de respuesta del sistema.
Esta combinación permite construir una solución más eficiente que la utilización de una única tecnología para todos
los requerimientos del sistema.
5.4 Limitaciones de la propuesta
Aunque la arquitectura planteada ofrece ventajas en términos de escalabilidad y flexibilidad, también introduce
desafíos relacionados con la administración de múltiples tecnologías de almacenamiento. La sincronización de datos, el
monitoreo de la infraestructura y la complejidad operativa aumentan a medida que se incorporan nuevos componentes
al sistema.
13
5.4. Limitaciones de la propuesta 5. Análisis y Discusión
Por esta razón, la implementación de una arquitectura de persistencia políglota debe justificarse por necesidades
reales de rendimiento, escalabilidad y disponibilidad.
14
Taller NoSQL
6 Conclusiones
1. El análisis realizado permitió identificar que los sistemas bancarios requieren altos niveles de consistencia
debido a la naturaleza crítica de las operaciones financieras y al manejo de información sensible de los clientes.
2. El teorema CAP constituye una herramienta fundamental para comprender los compromisos existentes entre
consistencia, disponibilidad y tolerancia a particiones en sistemas distribuidos.
3. La evaluación de diferentes tecnologías permitió concluir que MongoDB representa una alternativa adecuada
para modelar información bancaria mediante documentos flexibles y escalables.
4. La estrategia de persistencia políglota propuesta permite aprovechar las fortalezas de MongoDB, Cassandra y
Redis para responder de manera eficiente a diferentes patrones de consulta y almacenamiento.
5. Las bases de datos NoSQL ofrecen soluciones robustas para aplicaciones modernas que requieren escalabilidad,
flexibilidad y procesamiento de grandes volúmenes de información.
15
Taller NoSQL
7 Referencias
MongoDB Inc. (2026). MongoDB Documentation. Recuperado de: [Link]
Apache Software Foundation. (2026). Apache Cassandra Documentation. Recuperado de: [Link]
[Link]/doc/latest/
Redis Ltd. (2026). Redis Documentation. Recuperado de: [Link]
Brewer, E. (2012). CAP Twelve Years Later: How the Rules Have Changed. Computer, 45(2), 23–29.
Sadalage, P. J., Fowler, M. (2013). NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot
Persistence. Addison-Wesley Professional.
Kleppmann, M. (2017). Designing Data-Intensive Applications. O’Reilly Media.
Lara Espejo, C. F. (2026). Material de clase: Bases de Datos. Universidad Nacional de Colombia.
16
Taller NoSQL
A Anexos
A.1 Desarrollo manuscrito del taller
A continuación se presenta el desarrollo manuscrito realizado por el grupo durante la elaboración inicial del taller.
17