Ministerio de Educación.Uso educativo-nc. Elaboración propia
Ada le ha comentado a María que pronto van a tener que desarrollar un pequeño proyecto usando NoSQL. María está un poco asustada porque aunque ha oído algo sobre ello, no tiene muy claro del todo qué es y cómo se implementaría un proyecto con esa tecnología. Por eso, llama apurada a Juan para preguntarle sobre el asunto.
Juan intenta calmarla y le dice a María que no se preocupe, que NoSQL es un término amplio que comprende tecnologías no relacionales, y que seguramente haya usado alguna de ellas y no lo sepa. Le propone tomar un café para explicarle brevemente qué es eso de NoSQL y comentarle algunos ejemplos de aplicaciones que usan esas tecnologías.
Las bases de datos no relacionales se conocen también como bases de datos NoSQL. El término NoSQL significa "Not Only SQL" (no solo SQL), o sea, no es una tecnología que venga a sustituir o destronar a SQL, sino que viene a complementar. Es decir, comporta una serie de tecnologías para un fin determinado, de modo que en una empresa de desarrollo de software habrá casos en los que nos interese usar el modelo relacional con SQL y en otras ocasiones NoSQL para otros proyectos donde no se emplee el modelo relacional.
Carlo Strozzi es el primero que menciona el término NoSQL en 1998, pero será en 2009 cuando más va a empezar a usarse a raíz de que Eric Evans lo popularice. Evans suele referirse a estas tecnologías de bases de datos de nueva generación como Big Data mientras que Strozzi las nombra como no relacionales. Quizás este último término sea más adecuado puesto que Big Data es algo bastante más amplio.
¿Cuál es el origen de estas tecnologías NoSQL? ¿Por qué surgen? La evolución del mundo digital, la cantidad de dispositivos, aplicaciones, etc., tales como: relojes, pulseras inteligentes, aplicaciones de esos dispositivos, sensores, etc., que generan un montón de datos. Ese crecimiento de datos sobre los que se pueden hacer analíticas, tomar decisiones, etc., ha conducido a la explosión de estas tecnologías NoSQL y en definitiva del Big Data.
Si te fijas, las empresas cada vez más comercian a través de la web, además de que la computación en la nube también ha propiciado la necesidad de facilitar el acceso a servicios de Internet. Es raro ya la empresa que no ofrezca sus productos y servicios a través de esos canales digitales. Piensa, por ejemplo, en empresas como Ebay, Amazon, etc.: estas compañías necesitan gestionar a diario una enorme cantidad de usuarios accediendo de manera concurrente, y por ello se gestionan volúmenes de datos muy grandes que se deben procesar y almacenar, etc.
En esta situación actual y para muchos desarrollos de software nos interesará por tanto emplear estas tecnologías NoSQL. Nos encontramos, además del volumen enorme de datos, con otras características cuando hablamos de Big Data, y así, se habla de las 5 V del Big Data:
Volumen de datos a gestionar,
Variedad de formatos en la que llegan los datos recogidos por dispositivos, sensores, etc. y que habrá que transformar quizás antes de poder almacenar,
Velocidad: la gran velocidad a la que llegan los datos a procesar lo antes posible (piensa por ejemplo en aplicaciones como google maps que indican el estado actual del tráfico)
Veracidad de los datos, en el sentido de que puedo tener múltiples fuentes y tendrá que analizarse cuáles son útiles para mi aplicación y cuáles no me sirvan,
Valor: la idea no es almacenar por almacenar datos, sino que sirvan para algo a la empresa: tomar decisiones, ofrecer mejor servicio a los clientes que empleen la aplicación, etc. Un ejemplo puede ser un supermercado, donde en base a los datos almacenados por otras ocasiones y en función del uso actual, sepa más o menos predecir cuántas cajeras va a necesitar en ese intervalo de tiempo en que se esté.
En las bases de datos relacionales estamos familiarizados con las transacciones ACID, pues garantizan la consistencia y estabilidad de las operaciones pero requieren bloqueos. Recordemos brevemente que esas siglas significan:
Atomicidad, la transacción se ejecutará totalmente o no se ejecutará.
Consistencia, una vez completada, la base de datos quedará en un estado consistente, es decir, no se viola ninguna restricción de integridad.
Aislamiento: las transacciones concurrentes son independientes y no afectan unas a otras.
Durabilidad: las actualizaciones efectuadas por una transacción podrían recuperarse ante fallas del sistema
Los sistemas NoSQL no requieren seguir el modelo ACID en todo el sistema porque en estas tecnologías lo que prima es la velocidad, por tanto, se produce una necesidad de atender a gran velocidad una cantidad enorme de datos pero sacrificando alguna otra característica. Puede haber unos milisegundos en los que haya consistencia eventual y no tan estricta en los datos como se da en el modelo relacional. Esto no nos lo podríamos permitir en una transacción bancaria, pero sí en otros casos como por ejemplo en un sistema de mapas de tráfico en tiempo real, donde puede que la información que vea en un instante un usuario sea levemente distinta a la que vea en ese mismo instante otro usuario, esas diferencias, en poco tiempo convergerán.
Tenemos por tanto que las bases de datos NoSQL no siguen el modelo ACID sino el enfoque BASE (que significa: coherencia eventual flexible básicamente disponible).
Tal y como estamos viendo, los sistemas gestores de bases de datos relacionales tradicionales nos permiten definir la estructura de los esquemas de bases de datos que demanda reglas rígidas, siguen el modelo ACID. Sin embargo, las aplicaciones web, móviles, otros sistemas de información modernos, etc., necesitan no tanta rigidez sino que demandan más bien: volumen de datos a gran escala o escala web, alta frecuencia de lecturas y escrituras, etc. Como consecuencia esto llevó a la aparición de soluciones NoSQL como: MongoDB, Cassandra, Redis, CouchDB , BigTable , Dynamo o Neo4j.
Estas tecnologías NoSQL emplean una arquitectura distribuida y tolerante a fallos, donde los datos se guardan de modo redundante en distintos servidores.
La computación distribuida, en términos sencillos, gestiona las tareas informáticas a través de una red de ordenadores o servidores, en lugar de un solo PC y procesador (lo que se conoce como sistema monolítico)
Respecto a la persistencia y al modelo de datos que emplean las bases de datos NoSQL para almacenar los datos, podemos resaltar que:
Suelen ofrecer estructuras de datos sencillas como arrays asociativos, o almacenes de pares clave valor,...
No hay joinsya que es una operación costosa que combina entradas de dos o más tablas, y que requiere esquemas fijos y consistencia fuerte.
Suelen tener un sistema de consultas propio en vez de usar un lenguaje de consultas estándar.
No tienen esquemas fijos (sino dinámicos) y permite la migración del esquema sin tener que ser reiniciadas o paradas.
Aparecen otros modos de almacenamiento de los datos. En el modelo relacional el almacenamiento se base en columnas y filas mientras que en las bases de datos NoSQL se suelen emplear otros métodos.
Suelen garantizar la consistencia eventual.
Un array, arreglo o vector es una colección ordenada de datos del mismo tipo
Ministerio de Educación. Uso educativo-nc. Elaboración propia.
Ada ha hablado con Juan para que con la ayuda de Ana trabajen en un nuevo proyecto. En esta ocasión van a tener que usar una tecnología NoSQL, por lo que les ha comentado que decidan qué tecnología van a usar, puesto que NoSQL realmente son un conjunto de tecnologías y, por tanto, de productos los que se pueden usar en un proyecto determinado. De este modo, Ana irá aprendiendo sobre NoSQL a la vez que ayuda a Juan en tan importante tarea.
Ada tiene especial interés en que el proyecto se desarrolle bien desde el primer momento y que Ana vaya adiestrándose adecuadamente en estas tecnologías NoSQL, por lo que supervisará todo el trabajo para que no haya ningún fleco o problema.
El director de una gran empresa de ventas por Internet pidió a BK programación un desarrollo para su sitio web. Necesita de mucha velocidad y gestión de grandes cantidades de datos. Es primordial el almacenamiento de los datos de los artículos, los clientes, las compras de los clientes, etc. Todo deberá guardarse en bases de datos, para su tratamiento y recuperación las veces que haga falta.
Como sabemos, en el modelo relacional trabajamos con SQL. SQL es un estándar que lo implementan muchas marcas, pero son todas SQL, es decir, que sabiendo SQL podemos interactuar con una base de datos Oracle, MySQL, H2, etc. Es cierto que puede haber pequeñas diferencias a la hora de implementar, algún comando de administración de base de datos, etc., pero al final siguen todas el mismo modelo de diseño de datos, mismo E/R, mismo lenguaje de acceso, etc.
En NoSQL esto no es así, no es una tecnología, sino que es un conjunto de cuatro categorías o tecnologías o cuatro familias de base de datos:
Almacenes de clave valor.
Almacenes de familia de columnas, o lo que se llama también wide colum store (almacén de columna ancha).
Almacenes de documentos o bases de datos de documentales.
José Javier Bermúdez Hernández.Uso educativo-nc. Elaboración propia.
En este tipo de bases de datos, el modelo de datos es muy sencillo: es una colección de pares clave/valor
Es similar a los diccionarios o mapas o matrices asociativas, si conoces Java, sería por similar a los Hash Map.
La clave es el identificador único que permite acceder al valor asociado. El valor es lo que se recupera, puede variar desde un fichero, una imagen, un zip, un número, una lista, etc., o incluso otro par clave valor encapsulado con un objeto. En general las búsquedas son por la clave, no se puede buscar por el valor.
Hay que prestar atención especial a la elección adecuada de las claves. Por ejemplo si dada una base de datos con campos, uno de ellos sea nombre, si elegimos nombre como clave, esto no sería buena idea, ya que por ejemplo puede haber dos o más "Juan", "Antonio", etc.
Estas bases de datos destacan principalmente en que las operaciones de lectura y escritura tienen un desempeño altísimo y una alta disponibilidad de los datos y son más sencillas de particionar que otras bases de datos no relacionales, debido a lo simple de su estructura. Por ejemplo, twitter utiliza este tipo de bases de datos para recargar el conjunto de tweets que el usuario de esta red todavía no ha leído.
Las operaciones básicas:
PUT: para añadir un nuevo par clave valor o actualizar el valor si la llave ya está presente.
GET: que devuelve el valor de una clave determinada.
DELETE: elimina un par clave valor.
Puesto que las Bases de Datos Clave Valor permiten virtualmente cualquier tipo de datos, es importante que los desarrolladores implementen las comprobaciones pertinentes en sus aplicaciones.
Las bases más usadas son Redis, Dynamo DB, etc.
La partición de bases de datos consiste en almacenar una base de datos grande en varias máquinas. Un solo servidor de base de datos puede almacenar y procesar únicamente una cantidad limitada de datos. La partición de bases de datos evita esta limitación al dividir los datos en trozos más pequeños (denominados particiones) y almacenarlos en varios servidores de bases de datos.
José Javier Bermúdez Hernández(Uso educativo-nc. Elaboración propia)
Son las más parecidas al mundo relacional porque guardan los datos en tablas con filas y columnas, similar al modelo relacional, pero los nombres y los formatos de las columnas pueden variar de fila a fila en cada tabla.
Agrupan las columnas con datos relacionados (en familias de columnas).
Se puede interpretar como un almacén de clave valor bidimensional.
El precursor en esta familia de bases de datos fue Google BigTable y algunos ejemplos son HBase (implementación código abierto de BigTable), Hypertable, Cassandra (el más extendido actualmente), etc.
Se emplean fundamentalmente en aplicaciones analíticas por estar optimizada para lograr una recuperación rápida de columnas de datos.
Utilizan una compresión muy eficientemente al estar las columnas seguidas en el disco, proporcionan una alta disponibilidad y están optimizadas para operaciones a nivel de columnas (contar, sumar, promediar, etc.) Como desventaja mencionar que las escrituras en las bases de datos son costosas, porque tienen que escribir en muchos sitios en el disco.
Estas bases de datos poseen un compromiso entre el tamaño y la complejidad de datos, están muy orientadas a la web y se corresponde con la manera en que se modelan los objetos y sus propiedades en los lenguajes orientados a objetos.
Este tipo de bases de datos están orientadas a la web, facilitando las operaciones CRUD (Create, Read, Update, Delete)
Las bases de datos orientadas a documentos son bases de datos que poseen una naturaleza flexible y jerárquica de su contenido. Estas guardan principalmente información basada en una estructura de documentos anidados (documentos dentro de documentos).
Permiten realizar potentes consultas y facilitan el análisis de datos.
El modelo de datos que emplean consiste en colecciones de documentos (JSON, XML, BSON) que contienen colecciones de claves valor.
El producto precursor de estas bases de datos fue Lotus Notes, si bien la que más se emplea actualmente es MongoDB, sobre que que más adelante veremos con más detalle. También otras bases de datos de este tipo son: Amazon DocumentDB, CouchDB, etc.
El nombre de MongoDB viene de la palabra en ingles “humongous” que significa enorme. Una base de datos MongoDB contiene colecciones, una colección esta formada por documentos y cada documento esta compuesto de campos.
Este tipo de bases de datos son muy buenas en modelar grafos, o sea, datos muy relacionados. Consisten en nodos interconectados por relaciones.
Están indicadas para aquellos contextos en los que las relaciones son fundamentales, como por ejemplo las redes sociales.
El modelo de datos está formado por tres elementos: nodos, relaciones y propiedades. altamente relacionales con múltiples relaciones muchos a muchos, cuando la importancia recae más en las interrelaciones que se establecen entre los datos, que en los propios datos en sí.
Es muy difícil particionar estas bases de datos, debido precisamente a extrema relación entre los datos.
Las bases de datos orientadas a grafos se diferencian entre sí en la forma que almacenan los datos y la forma en que procesan las consultas en el grafo:
Graph Storage (Almacenamiento del grafo): define la forma en la que se almacena el grafo
Almacenamiento nativo: optimizado para almacenar grafos
Almacenamiento no nativo: utilizan otras tecnologías como bases de datos relacionales u otros tipos de bases de datos NoSQL para almacenar los datos
Graph Processing (Procesamiento del grafo): define la forma en la que se procesan las operaciones CRUD (Create, Read, Update, Delete) sobre los datos
Procesamiento nativo: algoritmos optimizados para atravesar grafos. Los nodos conocen la posición física (dirección de memoria) de los nodos adyacentes de forma que no hace falta aplicar ningún algoritmo de búsqueda para encontrarlos.
Procesamiento no nativo: no optimizado para atravesar el grafo.
Ana ha recibido el encargo de que introduzca una serie de datos en la base de datos que usarán en las pruebas del proyecto, de cara a verificar que todo funcione correctamente. Para ello, y dado que se ha decidido que emplearán MongoDB, tendrá que introducir los datos en el formado adecuado. Juan le ha comentado que revise JSON, si no se acuerda o hace tiempo que no lo usa, ya que le va a ser de gran utilidad para poder realizar el próximo cometido. En particular, también deberá comprender qué es BSON, muy parecido a JSON, le explica Juan.
Para trabajar con MongoDB tendrán que tener en cuenta que no están en el mundo relacional de tablas, filas, columnas sino que con MongoDB se habla de colecciones, documentos,...
Hemos visto y trabajado en las unidades anteriores con bases de datos relacionales, que se caracterizan por estar formadas por tablas, donde se almacenan distintos tipos de datos en filas y columnas. Además, pueden tener relaciones entre las distintas tablas. MongoDB, que es el SGBD con el que vamos a trabajar en esta unidad, es totalmente diferente a la hora de guardar la información. Se caracteriza principalmente, por ser un base de datos NoSQL y guardar los datos en diferentes documentos, independientes entre ellos.
Como comentamos brevemente con anterioridad, el modelo de datos que emplea MongoDB consiste en colecciones de documentos (JSON, XML, BSON) que contienen colecciones de pares cadena valor. Como vimos en temas anteriores, en los sistemas de gestión de bases de datos relacionales tenemos bases de datos, tablas, filas, columnas...
Pero en las bases de datos NoSQL, en concreto en MongoDB, los datos se almacenan en formato BSON (una versión binaria de JSON). Se almacenan en estructuras denominadas colecciones , que serían similares a las tablas. En el siguiente esquema, puedes contemplar una comparativa de los conceptos equiparados entre el mundo relacional y el no relacional.
Por tanto, esquematizando la visión de la base de datos MongoDB tendríamos algo como lo que ves a continuación, donde se observan dos colecciones (lo que en el modelo relacional serían dos tablas) con varios documentos (que en el modelo relacional serían filas), en concreto la primera colección tendría seis documentos y la segunda cinco documentos.
José Javier Bermúdez Hernández.Uso educativo-nc. Elaboración propia.
JSON es un formato de texto sencillo para el intercambio de datos. Supone una alternativa a XML como lenguaje de intercambio de datos, bastante más sencillo de leer y escribir. Proporciona un formato de intercambio de datos legible por el hombre. Se emplea mucho en bases de datos NoSQL, no solo en MongoDB, y está soportado por multitud de lenguajes de programación.
Un objeto JSON está formado por uno o varios pares cadena valor ( String: value ). Por ejemplo, podríamos tener el siguiente ejemplo de un elemento en este formato. Como vemos en el código de más abajo, se trata de pares de cadena con su correspondiente valor, se separa por comas cada par, y por los dos puntos la cadena del valor. Se puede observar que hay valores booleanos como el que corresponde a la cadena "casado", e incluso valores array. Si te fijas, el array "coches" tiene dos elementos, las llaves delimitan cada uno de los elementos y el corchete delimita el array, por tanto esa persona tiene dos coches, según en este ejemplo.
Podemos decir que BSON es básicamente JSON binario, supone por tanto un "superconjunto" de JSON, o JSON ampliado con algunos tipos de datos más. A diferencia de un fichero JSON que puedes abrirlo con un editor de texto plano y es legible, BSON emplea un formato binario, serializado y es el que usa internamente MongoDB.
Los documentos BSON pueden contener objetos de fechas o binarios que no son nativamente representables en JSON puro. Además, los registros BSON tienden a ser más pequeños que los registros JSON, por lo que se optimiza el almacenamiento. Se suele usar JSON en la transmisión de datos y BSON para el almacenamiento de datos en MongoDB.
La serialización consiste en un proceso de codificación de un objeto en un medio de almacenamiento con el fin de transmitirlo a través de una conexión en red como una serie de bytes o en un formato humanamente más legible como XML o JSON
Podemos observar unas cuantas diferencias entre JSON y BSON aquí:
Principales diferencias entre JSON y BSON
JSON
BSON
Formato de texto plano
Formato de fichero binario
JSON contiene algunos tipos de datos básicos como cadenas de caracteres, números, booleanos y null
BSON contiene algunos tipos de datos adicionales como fecha, timestamp,...
Bases de datos como Redis, AnyDB y otras almacenan los datos en formato JSON
MongoDB almacena los datos en formato BSON
Es comparativamente menos rápido que BSON
El almacenamiento es más rápido con BSON que con JSON
Se usa en la transmisión de datos
Se usa en el almacenamiento de datos
No incluye ninguna técnica de codificación y descodificación
Emplea una técnica rápida de codificación y descodificación
JSON es una combinación de objetos y arrays donde un objeto es una colección de pares clave-valor mientras que array es una lista ordenada de elementos
La técnica de codificación binario proporciona alguna información adicional como la longitud de la cadena y los subtipos de los objetos. Soporta tipos adicionales como binario y fecha que no soporta JSON
En la siguiente imagen puedes ver cómo se representaría la misma información en JSON y en BSON, siendo una entendible para el ser humano y la otra no.
La instalación de MongoDB es sumamente sencilla, basta con descargarlo y seguir el proceso, tras la instalación se habrá instalado el servidor y la aplicación Compass, el entorno gráfico similar a sqlDeveloper de Oracle o a MySQL WorkBench.
Para crear la base de datos en los proyectos que acometamos, como es normal, debemos tener claro el tipo de datos que necesitamos para cada atributo a guardar en los documentos de la base de datos.
En MongoDB la información se almacena en documentos, agrupados en colecciones que pertenecen a bases de datos. Los documentos de una colección no tienen porqué compartir la misma estructura, aunque en general sí que lo suelen hacerlo.
Un documento es un conjunto de datos que representan una determinada información de un objeto. Por eso, en ocasiones cuando se habla de documentos en MongoDB, también empleamos el término objeto. En el caso del esquema que ves más abajo, tenemos información de una persona.
En el ejemplo mostrado, usamos un determinado formato para representar cada una de las características de la persona. El nombre de la característica y su valor se separan con el símbolo : donde va primero el nombre de la característica. Utilizamos una línea para cada característica.
En MongoDB se utiliza el formato BSON para almacenar los documentos. BSON no es más que una extensión de JSON que se representa de manera binaria. JSON es un formato estándar utilizado principalmente para transmitir datos entre un servidor web y una aplicación web.
BSON acelera el acceso a la información contenida en un documento. Cuando trabajamos con la consola de MongoDB se utiliza JSON, ya que es más legible.
El driver de la base de datos es el encargado de convertir la información entre BSON y la estructura del lenguaje (JSON). Cuando se lee de MongoDB se convierte de BSON a la estructura del lenguaje, y cuando se almacena en MongoDB al revés.
Como hemos visto, en JSON el formato es muy sencillo. Para cada característica tenemos un par nombre/valor, separados por el símbolo dos puntos. El nombre es siempre una cadena o String, que identifica a cada uno de los pares. Los valores pueden ser: String o cadena, Number o número, etcétera, en el siguiente artículo puedes ver la lista de tipos de datos disponibles en MongoDB.
Un tipo especial de tipo de datos es el identificador de objeto, ObjectId, un tipo de datos pequeño, único, rápido de crear y ordenado. Está formado por 12 bytes: cuatro para guardar los segundos desde el 1 de enero de 1970, tres para identificar la máquina, dos para identificar el proceso, y tres para un contador. Cuando se generan dos valores en el mismo segundo, en la misma máquina y desde el mismo proceso, el primero tendrá un valor aleatorio en el contador, y el segundo el anterior valor aleatorio más uno. Así que para que se pudiera repetir el valor de ObjectId deberían generarse más de 16 millones y medio (2 elevado a 24) de valores en el mismo segundo, en la misma máquina y desde el mismo proceso. Se utiliza como identificador de documentos, para diferenciar unívocamente unos de otros.
En el artículo de más abajo se ve más sobre el uso de este tipo de datos.
Aquí podemos ver algunos comandos útiles en la consola de Mongo:
Comandos útiles en la consola de MongoDB
Función
Comando
Salir de la consola
quit
Listar las bases de datos
show dbs
Cambiar de base de datos
use nombre_de_laBD
Mostrar el nombre de la base de datos
db
Listar las colecciones de una base de datos
show collections / show tables
Crear una colección en una base de datos
db.createCollection("nombre_coleccion")
Mostrar el contenido de una colección
db.nombre_de_la_colección.find()
Borrar la base de datos
db.dropDatabase()
Mostrar fecha y hora
Date()
Mostrar ayuda sobre comandos en la consola
db.help
En el siguiente vídeo puedes ver la ejecución de unos primeros comandos en la consola de MongoDB y también un una primera ejecución del entorno gráfico MongoDB Compass.
Probando los primeros comandos en la consola de MongoDB y Compass
Ministerio de Educación. Uso educativo-nc. Elaboración propia.
Ana está pensando en las consultas que han de realizar en el nuevo proyecto en el que están embarcados. Medita sobre la forma de hacerlas, ya que está acostumbrada a hacerlas en el modelo relaciona, con SQL y con MongoDB, que es la tecnología que van a usar en el nuevo proyecto, la forma de realizar esas consultas a la base de datos se hacen de otra manera.
Tendrá que ver cómo hacer las inserciones de datos, las posibles actualizaciones y borrados, y las consultas que se harán sobre las colecciones que haya en la base datos,...
—Seguro que no será tan difícil —piensa Ana—, mientras en su cabeza da vueltas a la idea de que siempre le suele pasar lo mismo, que se agobia mucho al principio, pero luego ve que todo sale sin problemas.
Como sabemos, CRUD son las siglas de las diferentes operaciones que se pueden hacer con los datos en una tabla o colección, es decir: insertar, leer o consultar actualizar y borrar documentos. El concepto hace referencia a un acrónimo en el que se reúnen las primeras letras de las cuatro operaciones fundamentales de aplicaciones persistentes en sistemas de bases de datos:
Create (Crear registros)
Read. Retrieve (Leer registros)
Update (Actualizar registros)
Delete. Destroy (Borrar registros)
Veamos en los siguientes apartados cómo se harían estas operaciones con MongoDB
En el siguiente enlace se ven ejemplos del uso del comando para insertar varios documentos con la misma instrucción, empleando db.collectionName.insertMany
Para borrar documentos de las colecciones, tenemos una situación similar a insertar, y podemos así eliminar un solo documento o varios con:
db.nombre_de_colección.deleteOne(<json>) para eliminar un documento
db.nombre_de_colección.deleteMany(<json>) para eliminar varios documentos.
Así por ejemplo, podríamos borrar de la base de datos empresa donde insertábamos datos anteriormente, en la colección personas, el documento que cumpla la condición de que el nombre tenga el valor Anacleto, del siguiente modo:
db.personas.deleteOne({nombre:'Anacleto'})
Ese comando hará que se borre el primer documento que cumpla esa condición. Si se utiliza deleteMany entonces se eliminarán todos los documentos que cumplan la condición.
En MongoDB podemos observar tres formas de actualizar documentos:
db.<code>nombre_de_colección.updateOne(, ) para actualizar un documento,
db.<code>nombre_de_colección.updateMany(, para actualizar uno o más documentos,
db.<code>nombre_de_colección.replaceOne(, ) para reemplazar un documento.
Se emplea <filter> para seleccionar o filtrar a qué documentos afectará y en <update> pondremos los nuevos valores, empleando el operador <$set> para indicar qué campos son los que se van a actualizar.
Por ejemplo, si quisiéramos actualizar todos los registros de nuestra colección personas, y para aquellos documentos cuyo nombre sea "Eva" establecerle las siguientes propiedades: los apellidos a "Pérez Pérez", el sueldo a 25000 y además, creamos una propiedad que no teníamos antes en los documentos que sea becaria y poniendo ese valor a true. Entonces la actualización sería:
La lista de operadores disponibles en MongoDB es enorme, los operadores de consulta en MongoDB incluyen operadores de comparación, lógicos y de evaluación.
Los operadores de comparación se utilizan para comparar valores en los documentos de una colección y seleccionar documentos que cumplan con ciertas condiciones. Algunos de operadores de comparación son:
Operadores de comparación
Operador
Descripción
$eq
Compara si un campo es igual a un valor específico.
$ne:
Compara si un campo no es igual a un valor específico.
$gt
Compara si un campo es mayor que un valor específico.
$lt
Compara si un campo es menor que un valor específico.
$gte
Compara si un campo es mayor o igual a un valor específico.
$lte
Compara si un campo es menor o igual a un valor específico.
En la siguiente tabla puedes ver algunos operadores lógicos, los cuales se utilizan para combinar múltiples condiciones en una sola consulta.
Operadores lógicos
Operador
Descripción
$and
Realiza una operación lógica "y" en una lista de expresiones.
$or
Realiza una operación lógica "o" en una lista de expresiones.
$not
Niega una expresión.
$nor
Realiza una operación lógica "ni" en una lista de expresiones.
Los operadores de evaluación se utilizan para realizar operaciones de evaluación en los valores de los campos. Algunos operadores de evaluación en MongoDB los podemos ver en la tabla siguiente:
Operadores de evaluación
Operador
Descripción
$type
Comprueba el tipo de un campo.
$exists
Comprueba si un campo existe en un documento.
$mod
Comprueba si un campo es divisible por un valor dado.
$regex
Realiza una búsqueda de expresión regular en un campo.
Empezamos viendo las consultas a través de ejemplos. Así, para obtener todos los documentos de la colección, usamos el método: db.nombre_de_la_colección.find({}). En nuestra base de datos empresa con la que venimos trabajando, par listar todos los documentos de la colección personas podemos hacer:
db.personas.find()
y nos arrojará el listado por consola. Sería un equivalente si fuera una base de datos relacional a hacer: SELECT * from personas
Para buscar un registroespecífico, basta con poner el nombre del campo y el valor a buscar, por ejemplo:
db.personas.find( { "nif": "51234978H" } )
devolverá los documentos de la colección personas cuyo nif coincida con "51234978H" (Lo lógico si es una colección de personas sería que sólo hubiera una persona con ese nif). La consulta o query equivaldría en el entorno relacional a haber hecho un SELECT * from personas WHERE nif="51234978H". Podemos ver el resultado de la consulta realizada en la consola en la imagen:
José Javier Bermúdez Hernández. Uso educativo-nc. Elaboración propia.
Teniendo en cuenta los operadores que veíamos en el apartado anterior, ¿cómo haríamos para buscar un valormenoroigual que otro? Por ejemplo, para buscar las personas cuyo sueldo sea menor o igual a 28000. Pues sería:
db.personas.find( {sueldo: { $lte: 28000 } } )
Si en lugar de hacer las consultas en la shell de MongoDB, las hacemos desde Compass, habrá que escribirlas en el recuadro que ves en la imagen de abajo, donde consultamos los documentos que tengan un sueldo mayor que 33000:
José Javier Bermúdez Hernández. Uso educativo-nc. Elaboración propia.
Debemos saber que el método find, recibe dos objetos: la búsqueda que queremos y los campos a mostrar.
Entonces, si en nuestra colección de personas queremos mostrar sólo los campos nombre y sueldo de los documentos basta mandar un valor 1. A continuación puedes ver la ejecución y resultado de la consulta:
Veamos cómo realizar algunas consultas con arrays. Es decir, supongamos que tenemos en la base de datos empresa con la que estamos trabajando una colección llamada mascotas:
José Javier Bermúdez Hernández. Uso educativo-nc. Elaboración propia.
¿Cómo podríamos realizar consultas preguntando sobre elementos de un array de un documento? Es decir, dado el ejemplo que tenemos de la colección mascotas, donde cada documento tiene un array de juguetes, ¿cómo podría averiguar por ejemplo los documentos que tenga la madeja de hilo como elemento del array?
Pues haríamos:
db.mascotas.find({ juguetes: "madeja de hilo"}).pretty()
y podemos ver el resultado al ejecutarlo por la consola, donde se nos devuelven los dos documentos esperados:
empresa> db.mascotas.find({ juguetes: "madeja de hilo"}).pretty()
[
{
_id: ObjectId('65ad444110f91825dc172a55'),
nombre: 'Gato Misifú',
color: 'Blanco',
edad: 4,
juguetes: [ 'ratoncito de plástico', 'madeja de hilo' ]
},
{
_id: ObjectId('65ad452410f91825dc172a59'),
nombre: 'Caracol rapidín',
color: 'Beig pimienta',
edad: 2,
juguetes: [
'bólido para caracoles marca ACME',
'Pit stop de reparaciones para caracoles',
'madeja de hilo'
]
}
]
empresa>
Y volviendo a nuestra colección de personas, fíjate que en ella, el array que tenemos tiene varios elementos, es decir, tomado un documento de ejemplo, la estructura como ves es la siguiente, donde cada elemento del array tiene marca, modelo y anio:
José Javier Bermúdez Hernández. Uso educativo-nc. Elaboración propia.
¿Cómo hacemos en este caso las consultas? Es decir, supongamos que queremos consultar en la colección personas todos aquellos documentos que tengan como marca de coche un valor de "Mazda". ¿Cómo lo haríamos? Pues en estos casos observa que la consulta debe ser similar a ésta:
Como hemos visto, para las consultas con MongoDB, normalmente utilizarás la función find() habitualmente. Sin embargo, hay ocasiones en las que necesitarás utilizar operaciones de agregación.
Las operaciones de agregación procesan registros de datos y devuelven resultados calculados. Agrupan valores de varios documentos y pueden realizar una variedad de operaciones en los datos agrupados para devolver un único resultado.
La agregación es una forma de procesar un gran número de documentos de una colección haciéndolos pasar por distintas etapas. Las etapas constituyen lo que se conoce como tubería o pipeline.
A continuación se muestra un diagrama que ilustra un proceso de agregación:
etapa 1: Entrada de datos.
etapa 2: Filtrar o coincidir.
etapa 3: Agrupar .
etapa 4: Ordenar.
etapa 5: Salida.
donde: $match: filtra los documentos con los que se desea trabajar $group: realiza la agregación $sort: ordena los documentos resultantes de la forma que se desee (ascendente o descendente)
A continuación, mediante la tubería se realizan transformaciones sucesivas en los datos hasta alcanzar el objetivo perseguido.
De este modo, podemos dividir una consulta compleja en etapas más sencillas, en cada una de las cuales completamos una operación diferente sobre los datos. Así, al final de la cadena de consultas, habremos conseguido todo lo que queríamos.
Este enfoque nos permite comprobar si nuestra consulta funciona correctamente en cada etapa examinando tanto su entrada como su salida. La salida de cada etapa será la entrada del siguiente.
El operador $sort se utiliza para ordenar los documentos en función de uno o más campos. Por ejemplo, si queremos ordenar los documentos de la colección de trabajadores por el campo “sueldo” de forma descendente, podemos utilizar el operador $sort del siguiente modo:
En el siguiente ejemplo vemos la consulta y resultados devueltos, al preguntar por la suma de los sueldos de los documentos de la colección de trabajadores agrupados por la categoría del trabajo. Observa cómo se emplean $group y $sum:
donde collectionName - es el nombre de una colección,
pipeline - es un array que contiene las etapas de agregación,
options - parámetros opcionales para la agregación
Este es un ejemplo de la sintaxis de la agregación:
Empleamos $match para filtrar los documentos que nos interesen, $proyect para seleccionar algunos campos específicos de una colección. Así, en este ejemplo obtendremos los campos nombre y sueldo de los trabajadores de la categoría desarrollador ordenados por sueldo de manera descendente:
Materiales desarrollados inicialmente por el Ministerio de Educación, Cultura y Deporte y actualizados por el profesorado de la Junta de Andalucía bajo licencia Creative Commons BY-NC-SA.
Antes de cualquier uso leer detenidamente el siguenteAviso legal
Actualización de materiales y correcciones menores.
Versión: 02.00.00
Fecha de actualización: 11/05/24
Autoría: José Javier Bermúdez Hernández
Ubicación: UNIDAD 7 COMPLETA Mejora (tipo 3): Según el RD 405/2023 la unidad 7 se modifica por completo para apostar por un RA en el cual se trabaje con no sql y los datos no relacionales :7. Gestiona la información almacenada en bases de datos no relacionales, evaluando y utilizando las posibilidades que proporciona el sistema gestor.
Por ello, el equipo de base de datos propone realizar la unidad 7 al completo con los siguientes contenidos:
Teniendo esto en cuenta yo planteo que la herramienta usada sea MONGO DB
Por lo tanto, hacer una unidad dónde :
1. Bases de datos no SQL. Caracteríscticas
2. Tipos de bd no SQL
3. Elementos utilizados
4. Instalación de mongo db
5. Utilización de mongo db.
Es necesario tener preparada la unidad para dar contenido cuando se implante el curso que viene el RD y su orden relacionada.
Ubicación: Se cambia el mapa entero Mejora (Mapa conceptual): Se cambia el mapa entero por cambio de unidad
Ubicación: Indice Mejora (Orientaciones del alumnado): La unidad es nueva por lo que se cambia el índice
Versión: 01.02.00
Fecha de actualización: 19/04/22
Autoría: Víctor Gil Rodríguez
Ubicación: Apartado 7 Mejora (tipo 2): Incluir en el apartado 7 que se llamaba Ejemplo, un ejercicio práctico completo utilizando 4 subapartados explicando con detalle lo que se va realizando tanto textualmente como con videotutoriales.
Ubicación: Índice del contenido Mejora (Orientaciones del alumnado): Se incluye el apartado 7 y subapartados que lo incluyen.
Versión: 01.01.00
Fecha de actualización: 20/04/21
Autoría: Víctor Gil Rodríguez
Ubicación: Toda la unidad Mejora (tipo 2): Se incluyen videotutoriales siguiendo un mismo ejemplo desde el comienzo de la unidad para explicar cada uno de los apartados.
