Bases de datos orientadas a objetos y documentos. DDBB NoSQL

 

Como ya sabemos el modelo relacional de un SGBD organiza los datos en tablas. Cada tabla contiene un conjunto de registros con atributos comunes o campos representados por columnas. No hay datos de navegación predefinida y se puede acceder a través del lenguage de consulta SQL que si bien es muy parecido en todos los SGBD, hay diferencias entre ellos.

Caso de estos SGBD son MySql, Sql Server, Oracle, PostGreSql, etc

Las consultas se realizan a mano dentro de las propias aplicaciones, con lo cual la ventaja de los lenguajes orientados a objetos se pierde, ya que hay que crear una petición a la base de datos de manera manual y el acceso a los datos desde los programas se vuelve en ocasiones una tarea complicada.

La mayoría de los programadores para que el acceso a las DB relacionales sea más simplificado, abstracto e integrado con el lenguaje orientado a objetos que estén usuando hacen uso de sistemas de mapeo relacional. Los sistemas de Mapeo Objeto-Relacional u ORM ayudan a combatir estas complicaciones o desventajas ya que permiten convertir datos entre el sistema de tipos utilizado en un lenguaje de programación orientado a objetos y el utilizado en una base de datos relacional, utilizando un motor de persistencia.

Lo que hace realmente es crear una DB orientada a objetos virtual, sobre la base de datos relacional posibilitando el uso de las características propias de la orientación a objetos.

Algunos de los motores de persistencia más populares son Entity Framework , Hibernate, Core Data, Doctrine, etc

Pero, ¿y si usamos un modelo que ya esté orientado a objetos nativamente?

Bases de datos NoSQL

Una alternativa más limpia a ORM son las Bases de datos NoSQL. Lo más destacado de estos sistemas  es que no usan SQL como el principal lenguaje de consultas. Los datos almacenados no requieren estructuras fijas como tablas, normalmente no soportan operaciones JOIN, ni garantizan completamente ACID (atomicidad, coherencia, aislamiento y durabilidad), y habitualmente escalan bien horizontalmente que es la característica más atractiva para las empresas.

Los sistemas de bases de datos NoSQL crecieron con las principales compañías de Internet, como Google, Amazon, Twitter y Facebook

Dentro de estos sistemas NoSql podemos encontrar bases de datos clave-valor, bases de datos documentales, bases de datos en grafo, bases de datos tabular, bases de datos multivalor y orientadas a objetos.

Algunas ventajas de las DB NoSql podrían ser:

  • Diferentes DBs NoSQL para diferentes proyectos
  • Manejo de una gran cantidades de datos
  • Se ejecutan en clusters de máquinas económicas
  • Escalamiento simple
  • Evita cuellos de botella
  • Escalabilidad horizontal
  • Escribirá menos código que si estuviera escribiendo para un RDBMS
  • Almacenar estructuras de datos muy complejas 
  • Si está trabajando con datos complejos, un ODBMS le puede dar un rendimiento que es de diez a mil veces más rápido que un RDBMS
  • Uso cuando los datos son complejos o un esquema que tiene muchas entidades de intersección

Algunas desventajas de las DB Nosql:

  • Los Modelos relacionales están generalmente respaldados por grandes proveedores (lo que se considera más fiable a nivel corporativo que un modelo Nosql)
  • Limitados todavía en las herramientas de creación de informes ad hoc
  • Algunas tienen una limitación de 2.5GB de espacio
  • El temor de actividad: La mayoría de los desarrolladores de ODBMS son pequeñas empresas

Entre todas ellas vamos a ver un poco más algunas características de las bases de datos orientadas a objetos y las orientadas a documentos.

Bases de datos orientadas a objetos

En una base de datos orientada a objetos, la información se representa mediante objetos de un lenguaje de programación y cuando se integra con un lenguaje de programción orientado a objetos como como Java, C#, Visual Basic.NET y C++ el resultado es un sistema gestor de base de datos orientada a objetos ODBMS que usa exactamente el mismo modelo que estos lenguajes de programación.

La persistencia del objeto se vuelve casi nativo y el código de la aplicación se simplifica enormemente.

Algunos ejemplos de destas DB son:

  • db4o
  • caché
  • Jade
  • Zope Object Database
  • GemStone S
  • Objectivity/DB

Cuando utilices una base de datos de objeto, te das cuenta de lo inadecuado que el modelo relacional es y vas a intentar no volver nunca a ellas.

Características

  • Mejor unido a un entorno específico. Si utilizamos exclusivamente Java, por ejemplo, tenemos un montón de opciones.
  • Todas aquellas derivadas de cualquier sistema No SQL

Base de datos orientada a documentos

Una base de datos documental o base de datos orientada a documentos está constituida por un conjunto de programas que almacenan, recuperan y gestionan datos de documentos o datos de algún modo estructurados o semiestructurados. . A diferencia de las bases de datos relacionales, estas bases de datos están diseñadas alrededor de una noción abstracta de "Documento".

Estos documentos contienen alguna información similar y otra diferente. En el lado contrario  una base de datos relacional todos los registros deben tener los mismos atributos que pueden estar vacíos.

Con el advenimiento masivo de Internet, la cantidad de almacenamiento grande de documentos se convirtió en una necesidad y pero al mismo tiempo las bases de datos orientadas a documentos aparecieron. 

Los documentos se suelen recuperar a través de consultas dinámicas e impredecibles . Así, las bases de datos de documentos por lo general puede asociar cualquier número de campos de cualquier longitud en un documento . De esta manera se puede almacenar por ejemplo junto con el nombre de una imagen médica de un paciente los datos de nacimiento. En otro momento se puede agregar también el sexo y la profesión incluso si no se concibió originalmente.

Motores de bases de datos documentales.

  • MongoDB, de 10gen
  • RavenDB, de Hibernating Rhinos.
  • djondb
  • SimpleDB
  • IBM Lotus Domino
  • Terrastore
  • CouchDB, de Apache CouchDB
  • CouchBase
  • eXist
  • BaseX

 

Características:

  • uso conveniente si la aplicación se basa en documentos
  • no existe un modelo de datos predefinido. No requiere ajustarse a un esquema estándar ni tener todos las mismas secciones; no esquema (Schema-Less)
  • Cloud-Model. Adecuado para funcionar en la nube
  • codificaciones JSON, YAML, XML y BSON
  • también formatos binarios como PDF y Microsoft Office (MS Word, Excel y demás)
  • aplicación altamente disponible y con gran velocidad de acceso a datos
  • En contra 
    • El modelado del código no recae en la base de datos, sino en la aplicación
    • limitaciones en las consultas

 

Ejemplo de documento:

 {
     Nombre:"Pepe", 
     Dirección:"C/ San Juan 15", 
     Hijos:[
        {Nombre:"Ana",Edad:10}, 
        {Nombre:"Pedro", Edad:8}, 
        {Nombre:"Juan", Edad:5}, 
        {Nombre:"Félix", Edad:2}
   ] 

  } 

Ejemplo de creacción de una aplicación Java con MongoDb http://www.slideshare.net/mongodb/webinar-creacin-de-su-primera-aplicacin-java-con-mongodb

 

 

Bases de datos XML

La mayoría de las bases de datos XML están orientadas a documentos. 

 

Diferencias entre SGDB y DB NoSql orientada a documento

 

DB NoSqlSGBD
Esquema implícito dinámicoEsquema explícito predefinido
Desnormalizado. Duplicación de datosNormalizado. Duplicación reducida
Coleccion de documentos con estructura variableTablas de datos uniformes

Solo es necesario conocer el nombre del documentoconocer el esquema antes de escribir o leer un objeto completo
Consultas estáticas de esquemas dinámicosConsultas dinámicas de esquemas estáticos
  
Tags: