SQL o NoSQL, esa es la pregunta. ¿En qué se diferencian? ¿Son competidores o colaboradores? ¿Qué preguntas hacen sobre ellos en una entrevista de trabajo?
Las preguntas sobre las bases de datos relacionales y no relacionales son comunes en las entrevistas técnicas, y no solo para los administradores de bases de datos, sino también para los desarrolladores de backend, probadores, especialistas en ciberseguridad, analistas y muchos más.
No podemos profundizar en este tema en un solo artículo, ya que es demasiado extenso. Así que simplemente proporcionaremos conocimientos básicos o refrescaremos los que ya tengas.
Hablaremos sobre los tipos principales de bases de datos, sus ventajas y desventajas. Y partiremos de las bases relacionales, por lo que las analizaremos un poco más a fondo.
¿Qué son las Bases de Datos Relacionales?
Son bases que se basan en el modelo relacional.
Edgar Codd inventó el modelo relacional de datos en la década de 1970.
Siendo matemático de formación, propuso usar la teoría de conjuntos para procesar datos.
Codd demostró que cualquier representación de datos se reduce a un conjunto de tablas bidimensionales de un tipo especial, que en matemáticas se llama relación (relation), de ahí la palabra «relacional» en la traducción del nombre.
También estableció las 12 reglas de Codd, a las que debe atenerse cualquier base de datos relacional. Estas reglas ayudaron a combatir las bases de datos obsoletas que los proveedores deshonestos intentaban hacer pasar por relacionales.
Y Edgar Codd también dio vida al lenguaje SQL.
Conceptos Básicos
Una relación es una tabla bidimensional con un nombre único. Está formada por filas (registros) y columnas (atributos).
Cada fila de la tabla representa algún objeto del mundo real (instancia de entidad) o una relación entre objetos.
Las columnas son los atributos de la entidad, y cada tipo de entidad tiene los suyos propios.
Entonces, una base de datos relacional es un conjunto limitado de tablas especiales con datos. Estas tablas se llaman relaciones. Las relaciones se usan para representar entidades y también las relaciones entre ellas.
¿Qué hay Dentro? Un Ejemplo de Normalización
Analicemos el funcionamiento de una base de datos relacional con más detalle a través de un ejemplo. Más adelante, esto nos ayudará a comprender y comparar bases de datos de diferentes tipos.
Supongamos que tenemos una base de datos con una sola tabla: Messages. En ella se almacena información sobre las conversaciones telefónicas entre los clientes y los operadores de una empresa de reparación de equipos.
Cada fila de esta tabla contiene datos sobre la llamada de un cliente con su problema y la respuesta del operador, además de la fecha de contacto.
La empresa tiene varios números de teléfono. Por lo tanto, el mismo operador puede recibir llamadas de diferentes clientes, y el mismo cliente puede contactar a diferentes operadores con diferentes preguntas.
Messages
| client | client_phone | operator | operator_phone | question | answer | date |
|---|---|---|---|---|---|---|
| Maria | 8 (902) 111-11-11 | Operador 1 | 8 (800) 111-11-11 | ¡¿Cuándo estará listo el impresora?! | Listo, venga a recogerlo. | 10.02.2024 |
| Jimena | 8 (910) 222-22-22 | Operador 1 | 8 (800) 111-11-11 | ¿Puede cambiar el vidrio de la tableta? | Claro, tráigala. | 10.02.2024 |
| Maria | 8 (902) 111-11-11 | Operador 2 | 8 (800) 222-22-22 | ¡¡¡La impresora no funciona!!! | Tráigala, la vemos. | 20.02.2024 |
Ahora imagina que hay decenas de miles de registros en esta tabla. Y surge una situación: el cliente favorito llama a la empresa y dice que cambió su número de teléfono. Y hay, por ejemplo, cien preguntas sin resolver sobre este cliente en la base de datos. Esto significa que hay que reemplazar el número de teléfono por el nuevo al menos en 100 registros, es decir, realizar cambios en varias filas de la tabla Messages.
Por supuesto, esto se hace mediante una consulta, no manualmente. Sin embargo, incluso la consulta realizará 99 operaciones adicionales, debido a la duplicación de información.
Se tiene en cuenta este tipo de problema en la fase de diseño de la base de datos, y se previene mediante la normalización de las relaciones.
¿Qué es la Normalización?
Para reducir el tamaño de la base de datos relacional (evitar el almacenamiento de datos redundantes) y evitar la inconsistencia (anomalías) al trabajar con ellos, las relaciones en la base de datos se normalizan. En otras palabras, se dividen en tablas interrelacionadas. Esto se llama descomposición.
La redundancia de datos es cuando los mismos datos se almacenan en la base de datos en varios lugares al mismo tiempo.
Comprobemos nuestro ejemplo en busca de redundancia
Cada fila de la tabla Messages contiene el nombre del cliente y el apodo del operador, así como sus teléfonos. Además, en la 1ª y 3ª filas vemos llamadas del mismo cliente, y en la 1ª y 2ª filas, las respuestas del mismo gerente. Es decir, en la 1ª y 3ª filas se duplican el nombre y el teléfono del cliente, Maria, y en la 1ª y 2ª filas, el apodo del gerente «Operador 1».
Para eliminar la duplicación de información, identificaremos las entidades Cliente y Operador. Y trasladaremos los atributos específicos de cada una a tablas separadas.
La primera (Clients) almacenará los nombres y los teléfonos de los clientes, y la segunda (Operators), los de los operadores. Además, a cada registro de estas tablas se le asignará un atributo id, la llamada clave principal (su valor es único, es decir, no puede repetirse dentro de la tabla). Con su ayuda, estableceremos una conexión con los registros de la tabla Messages.
Para ello, añadiremos dos nuevos atributos (claves externas) a cada registro en Messages (recordemos que todavía representa la entidad «llamada»): id_client e id_oper. Se referirán a las claves principales de las tablas Clients y Operators, respectivamente. Eliminaremos las columnas con los nombres y los teléfonos de la tabla Messages.
Y esto es lo que obtenemos:
Clients
| id_client | client | client_phone |
|---|---|---|
| 1 | Maria | 8 (902) 111-11-11 |
| 2 | Jimena | 8 (910) 222-22-22 |
Operators
| id_oper | operator | operator_phone |
|---|---|---|
| 1 | Operador 1 | 8 (800) 111-11-11 |
| 2 | Operador 2 | 8 (800) 222-22-22 |
Messages
| id_client | id_oper | question | answer | date |
|---|---|---|---|---|
| 1 | 1 | ¡¿Cuándo estará listo el impresora?! | Listo, venga a recogerlo. | 10.02.2024 |
| 2 | 1 | ¿Puede cambiar el vidrio de la tableta? | Claro, tráigala. | 10.02.2024 |
| 1 | 2 | ¡¡¡La impresora no funciona!!! | Tráigala, la vemos. | 20.02.2024 |
En esta base de datos, para cambiar el teléfono de un cliente para todos los registros a la vez, basta con modificar un solo campo en la tabla Clients.
Existen seis formas de normalización de bases de datos relacionales, en orden de disminución de la redundancia de las relaciones. Todas ellas se describen mediante reglas formales. Nuestra relación se ha llevado a la segunda forma normal.
Sistemas de Gestión de Bases de Datos Relacionales
Los datos en las tablas no se encuentran como un lastre, sino que los manejan los sistemas de gestión de bases de datos (SGBD).
Con su ayuda, se crean bases de datos (metasquemas), se rellenan con datos y se realizan operaciones con todo esto: se añaden, se eliminan, se cambia la estructura, se analizan, etc.
Lenguajes de Manipulación de Datos
La principal herramienta para interactuar con las bases de datos relacionales es el lenguaje de consulta estructurado SQL.
Este es un lenguaje declarativo. Es decir, las instrucciones en él no se ejecutan una tras otra (como en los lenguajes imperativos). Cada operador SQL solo describe la acción necesaria, y el SGBD decide cómo ejecutarla.
Por ejemplo, para seleccionar todos los datos de la tabla Messages del 10.11.2023, se realiza la siguiente consulta:
SELECT * FROM messages WHERE date = ‘10.11.2023’El lenguaje de consulta estructurado se divide en varias partes (grupos de operadores) y permite:
- Definir datos (DDL)
- Manipularlos (DML)
- Controlar el acceso a los datos (DCL)
- Gestionar las transacciones (TCL)
Hecha un vistazo a nuestra Guía Completa de Consultas SQL.
SQL no tiene inicialmente herramientas para crear informes impresos, formularios de pantalla y otras herramientas para desarrollar programas. Aunque SQL en sí no es un lenguaje de programación completo (Turing-completo), su estándar permite crear extensiones procedimentales. Estas amplían su funcionalidad hasta convertirlo en un lenguaje de programación completo.
Sin embargo, la sintaxis de SQL puede variar en los diferentes SGBD. En algunos casos, incluso se utilizan sus dialectos individuales, por ejemplo:
- T-SQL: para trabajar con Microsoft SQL Server
- PL/SQL: para escribir procedimientos y funciones almacenados en Oracle
- PL/pgSQL: en PostgreSQL
¿Qué son las Bases de Datos Objeto-Relacionales?
Son bases que incluyen herramientas para trabajar con tipos de datos de objetos. Surgieron en relación con el desarrollo de lenguajes de programación orientados a objetos.
En la estructura de estas bases de datos y en el lenguaje de consulta se utilizan clases, objetos, herencia. En esta dirección se desarrollan, por ejemplo, Oracle y PostgreSQL.
¿Qué Bases de Datos Relacionales son Populares en el Desarrollo Web?
MySQL
Es un SGBD de código abierto, comprado por Oracle junto con Sun Microsystems. Con él trabajan más de la mitad (55,6%) de todos los desarrolladores (según los resultados de una encuesta realizada en 2020 por el sitio web StackOverflow.com entre 65.000 encuestados).
Sus principales ventajas son su gratuidad y su alta velocidad de trabajo con los datos. MySQL se creó para procesar enormes conjuntos de información a escala industrial, pero gracias a su accesibilidad y velocidad se ha apoderado de la World Wide Web, ganándose el título de «SGBD de todo Internet». Y hoy en día MySQL sigue siendo el SGBD más cómodo para trabajar con páginas web y aplicaciones web.
MySQL cuenta con un fuerte apoyo de los creadores de lenguajes de programación: prácticamente todos los lenguajes populares tienen una interfaz para trabajar con ella.
SQLite
Este SGBD utiliza la mayor parte del lenguaje SQL estándar.
La principal ventaja de SQlight es su capacidad de integración. Esto se debe a que SQlight no es una aplicación de tipo «cliente-servidor» (a diferencia de otros SGBD relacionales), sino una biblioteca que se conecta directamente al programa.
Y también es muy popular: basta decir que SQLite está en cada smartphone. Por ejemplo, en los smartphones Android, se almacenan allí los contactos y los medios, y en iOS, la utilizan muchas aplicaciones.
PostgreSQL
Se puede considerar la más avanzada. No es solo relacional, sino un SGBD libre objeto-relacional.
PostgreSQL admite no solo los tipos de datos que existen en otros SGBD relacionales. Además de los tipos numéricos, de texto, booleanos y otros tipos estándar, en ella se pueden almacenar y procesar datos geométricos y monetarios, direcciones de red, JSON, XML, matrices, y también crear tipos de datos propios.
Limitaciones de los SGBD Relacionales
Los SGBD relacionales son simples, convenientes y predecibles. Y su mercado es uno de los más conservadores del sector de las tecnologías de la información. Por ello, incluso con la aparición de numerosos NoSQL, las bases de datos relacionales siguen siendo la herramienta más demandada en las diferentes ramas de la industria.
Según los datos de DB-Engines de julio de 2024, la cuota mundial de los SGBD relacionales es del 72.9% del total:
Sin embargo, las bases de datos relacionales no están exentas de inconvenientes.
Escalabilidad
Es difícil escalar una base de datos relacional horizontalmente, es decir, distribuir las tablas en diferentes servidores. En este caso, es muy difícil crear consultas y conectar las tablas.
Por lo tanto, una base de datos en crecimiento debe colocarse en un servidor más potente y caro, es decir, escalar verticalmente.
Pero incluso las capacidades de la máquina más potente son limitadas, por lo que las bases de datos relacionales están poco adaptadas para almacenar datos realmente grandes.
Complejidad
Debido a la normalización, la base de datos relacional tiene una estructura compleja. Y la velocidad de procesamiento de una consulta depende del número de tablas a las que se dirige la consulta.
Imagine que hay 100, 200, 1000 tablas; el SGBD funcionará lentamente, y el código de la consulta será muy voluminoso.
Flexibilidad
Los SGBD relacionales son adecuados para procesar datos con una estructura clara. Por ejemplo, mensajes, información sobre productos, datos sobre usuarios, etc. Pero es difícil organizar el almacenamiento y el procesamiento de entidades con un conjunto arbitrario de atributos o datos jerárquicos.
NoSQL como Alternativa a las Bases de Datos Tradicionales
El mundo cambia. En el proceso de transformación digital, el negocio se enfrenta a nuevos retos. Las empresas los resuelven con nuevas bases de datos. En primer lugar, para no sobrecargar las existentes, y en segundo lugar, porque las bases de datos relacionales clásicas no son adecuadas para todas las tareas modernas.
Y así, a principios de la década de 2000 aparecieron las bases de datos no relacionales. Además de resolver nuevas tareas, sus desarrolladores se centraron en corregir las principales deficiencias de las bases de datos relacionales: problemas de flexibilidad, baja productividad y escalabilidad.
En NoSQL no existen conceptos como filas, columnas, tablas y sus conexiones. Los datos en las bases de datos no relacionales se almacenan como objetos con atributos arbitrarios: pueden ser pares «clave-valor», documentos en formato JSON, grafos, etc.
Tipos de Bases de Datos no Relacionales
Las bases de datos NoSQL se dividen en cuatro categorías principales (en función de las tareas que se resuelven con su ayuda).
Clave-valor
Esta base de datos se puede representar como una tabla enorme. En cada una de sus celdas se almacenan datos de tipo arbitrario, y a cada valor se le asigna una clave única, por la que se puede encontrar este valor.
Este tipo de SGBD no admite conexiones entre objetos, solo realiza operaciones de búsqueda de valores por clave, adición y eliminación de registros.
Por ejemplo:
user1 {Mario, departamento de marketing}
user2 {name: Elena, position: secretaria}
user3 {OOO "Vector"}
user4 {Catalina Mego, departamento 2, diseñadora}
user5 {Alejo Galiani, contable jefe}
user6 {65, 84, 236} Las bases de datos «clave-valor» se utilizan a menudo para almacenar datos en caché y organizar colas.
Sus ventajas son la búsqueda rápida y la sencilla escalabilidad.
Su desventaja es que no se pueden realizar operaciones con los valores. Por ejemplo, ordenarlos o analizarlos.
Las bases de datos «clave-valor» se utilizan en el buscador de Google, Wikipedia, Facebook*, la tienda online Amazon.
Una de las más populares es Redis. La utilizan Uber, Slack, Stack Overflow, sitios web de hoteles y turísticos, la red social Twitter.
Orientadas a documentos
En ellas, los datos se almacenan en forma de estructuras jerárquicas (documentos) con un conjunto arbitrario de campos y sus valores. Los documentos se agrupan en colecciones.
Si se realiza una analogía con los SGBD relacionales, las colecciones equivalen a las tablas, y los documentos, a las filas de las mismas.
Por ejemplo, un fragmento de un documento con información sobre películas:
[
{
"year" : 2023,
"title" : "Soul",
"produced" : "Pixar Animation Studios",
"directors" : [ "Pete Docter", " Kemp Powers"],
"tagline" : "Everybody has a soul. Joe Gardner is about to find his",
"rating" : 8.3,
"genres" : ["Animation", "Comedy"]
},
{
"year": 2023,
"title": "The Queen's Gambit",
"created" : "Allan Scott",
"book" : "Walter Tevis",
"actors" : ["Anya Taylor-Joy", "Marielle Heller", "Moses Ingram"],
"rating" : 8.4,
"genres" : ["Drama", "Sport"]
},
{
"year": 1972,
"title": "Seeta and Geeta",
"produced" : "Sippy Films",
"actors" : ["Hema Malini", "Sanjeev Kumar"],
"genres" : ["Drama", "Musical", "Romance"]
}
]
Las bases de datos orientadas a documentos se utilizan en sistemas de gestión de contenidos (CMS), para almacenar catálogos y perfiles de usuario.
Una de las más populares es MongoDB (allí se pueden crear procedimientos en JavaScript).
Columnares (orientado a columnas)
Estas bases de datos se diferencian de las relacionales solo en la forma de almacenar los datos en el dispositivo de almacenamiento.
Si la base de datos relacional crea un archivo para cada tabla, en la base de datos columnar se crea un archivo separado para cada columna de la tabla.
Por ejemplo, si la tabla relacional tiene este aspecto:
| name | color | property |
|---|---|---|
| lobo | gris | con dientes |
| cabra | blanca | con cuernos |
| repollo | verde |
Las mismas entradas de la base de datos columnar tendrán este aspecto:
| name | lobo | cabra | repollo |
|---|---|---|---|
| color | gris | blanca | verde |
| property | con dientes | con cuernos |
¿Qué es lo que proporciona esto? Imagina que solo necesitas los nombres de los objetos, y sus propiedades no te interesan.
Al ejecutar una consulta en la tabla relacional, se revisa cada entrada y se seleccionan los datos necesarios. En la base de datos columnar, solo se leerá una columna con los nombres del disco. Esto reduce el tiempo de ejecución de la consulta, y mucho.
Las bases de datos columnares se utilizan en varios catálogos y archivos de datos, cuyo trabajo se basa en selecciones de este tipo.
Uno de los SGBD más populares de este tipo es Apache Cassandra.
Grafos
En algunas áreas temáticas, los datos son convenientes de representar en forma de grafos. Para su almacenamiento, las bases de datos de grafos son las mejores.
Los vértices (o nodos del grafo) son objetos (entidades), y las aristas del grafo son las relaciones entre ellos.
Por ejemplo, la información sobre los amigos en las redes sociales es perfecta para representarla en forma de grafo:
Las bases de datos de grafos se utilizan en redes sociales, servicios de recomendación, sistemas de detección de fraudes y similares.
Uno de los SGBD de grafos de código abierto más populares con su propio lenguaje de consulta es Neo4j.
¿Qué Sigue?
Acércate a nuestro curso «Bases de datos». Aprenderás sobre el diseño de bases de datos y el lenguaje SQL, descubrirás cómo elegir un SGBD para tu proyecto y cómo sacarle el máximo partido. Podrás trabajar con bases de datos en el sector bancario, el desarrollo de backend de aplicaciones web y móviles.
