5. Evolución de las Bases de Datos: RDBMS
▣ Los datos usualmente son
almancenados en filas.
▣ Lenguaje estandarizado de
consultas (SQL).
▣ El modelo de datos se define
antes de poder agregar los datos.
▣ Las relaciones unen datos desde
distintas tablas (joins).
▣ Los resultados son tablas.
Oracle, MySql, PostgresSQL,
MSSql, IBM DB/2
▣ Pros: transacciones con alto nivel
de control de seguridad (ACID).
▣ Cons: diseño previo, no son muy
escalables.
6. Evolución de las Bases de Datos: Analytical
▣ Basadas en un esquema estrella
con una tabla central para cada
evento.
▣ Optimizadas para análisis de datos
históricos.
▣ Uso de lenguaje MDX para consultar
las medidas para cada categoría de
datos.
Cognos, Hyperion, Microstrategy,
Pentaho, SAP BO, Microsoft, Oracle.
▣ Pros: consultas rápidas para
grandes volúmenes.
▣ Cons: no optimizado para
transacciones y actualizaciones.
7. Evolución de las Bases de Datos: Key Value
▣ Utilizan valores claves para acceder
a BLOBs (Binary Large Objects) de
datos.
▣ Los valores pueden contener
cualquier tipo de datos (imágenes,
audio, video).
Berkley DB, Memcache,
DynamoDB, S3, Redis, Riak
▣ Pros: escalable, API simple (insertar,
leer, eliminar).
▣ Cons: no es posible consultar
basado en el contenido del valor.
8. Evolución de las Bases de Datos: Column-Family
▣ La clave incluye una fila, familia de
columna y nombre de columna.
▣ Almacenar blob versionado en una
tabla.
▣ Las consultas se pueden realizar a
nivel de fila, familia o nombre de
columna.
Cassandra, HBase, Hypertable,
Apache Accumulo, Bigtable
▣ Pros: escalable, permite versionado.
▣ Cons: no es posible consultar
basado en el contenido del valor.
9. Evolución de las Bases de Datos: Graph
▣ Los datos son almacenados en una
serie de nodos, relaciones y
propiedades.
▣ Las consultas son a través de los
grafos.
▣ Ideal para cuando las relaciones
entre los datos es clave: ej. Redes
sociales.
Neo4J, AllegroGraph, Bigdata triple
store, InfiniteGraph, StarDog
▣ Pros: consultas rápidas en la red.
▣ Cons: Mala escalabilidad cuando el
grafo no cabe en memoria, lenguaje
de consulta especializado.
10. Evolución de las Bases de Datos: Document
▣ Los datos son almacenados en
jerarquías anidadas.
▣ Los datos se guardan como una
unidad.
▣ Cualquier ítem en el documento
puede ser consultado.
MarkLogic, MongoDB,
CouchBase, CouchDB, eXist-db
▣ Pros: capa de mapeo, ideal para
búsqueda.
▣ Cons: Complejo para implementar,
incompatible con SQL.
14. MongoDB: Conceptos
▣ Base de Datos multiplataforma, que provee alta performance, alta disponibilidad
y escalamiento automático.
▣ Un registro en MongoDB es un documento, el cual es una estructura
compuesta de pares campo: valor. Los documentos son similares a los objetos
JSON.
15. JSON: Conceptos
▣ JavaScript Object Notation, es un formato liviano para intercambio de datos.
▣ Es un formato de texto completamente independiente del lenguaje.
▣ Está constituido por dos estructuras:
□ Colección de pares de nombre / valor.
□ Una lista ordenada de valores.
{ : }valuestring
object
,
object
16. JSON: Values
▣ Un valor puede ser una cadena de caracteres, un número, un boolean, un
objeto o un array.
number
string
value
object
false
null
array
true
value
17. JSON: Array
▣ Un arreglo es una colección de valores,
[ ]value
array
,
20. MongoDB: Documents
▣ MongoDB almacena los registros de datos como documentos BSON (Binary
JSON).
▣ El valor de un campo puede ser cualquier tipo de dato BSON, incluyendo otro
documento, array o un array de documentos.
▣ Cada documento incluye un ID para identificarlo univocamente.
21. MongoDB: Modelado
▣ Al momento de modelar un documento, se deben considerar la decisión de
embeber los datos o utilizar referencias.
22. MongoDB: Modelado
▣ Es posible embeber datos relacionados en una estructura simple o documento,
estos esquemas son desnormalizados.
▣ Los modelos de datos embebidos se utilizan cuando:
□ Existe una relación “contiene” entre las entidades.
□ Existe una relación uno-a-muchos entre las entidades.
23. MongoDB: Modelado
▣ Relaciones uno-a-uno entre entidades, es posible embeber directamente los
datos en el documento.
□ En el ejemplo, el domicilio del cliente está embebido en la entidad.
24. MongoDB: Modelado
▣ Es posible resolver relaciones uno-a-muchos embebiendo la información en el
documento.
25. MongoDB: Modelado
▣ Es posible (para evitar la redundancia), resolver las relaciones uno-a-muchos
utilizando referencias.