Una base de datos relacional organiza los datos en filas y columnas, que en conjunto forman una tabla. Los datos normalmente se estructuran en varias tablas, que se pueden unir mediante una clave primaria o una clave foránea. Estos identificadores exclusivos demuestran las diferentes relaciones que hay entre las tablas, y estas relaciones suelen ilustrarse a través de diferentes tipos de modelos de datos. Los analistas utilizan las consultas SQL para combinar diferentes puntos de datos y resumir el rendimiento empresarial, lo que permite a las organizaciones obtener información útil, optimizar los flujos de trabajo e identificar nuevas oportunidades.

Por ejemplo, supongamos que su compañía mantiene una tabla de base de datos con información de clientes, que contiene datos de la compañía a nivel de cuenta. También puede haber una tabla diferente, que describa todas las transacciones individuales que se alinean con esa cuenta. Combinadas, estas tablas pueden proporcionar información sobre los diferentes sectores que compran un producto de software específico.

Las columnas (o campos) de la tabla de clientes pueden ser ID del cliente, Nombre de empresa, Dirección de la empresa, Sector, etc.; las columnas para una tabla de transacción pueden ser Fecha de transacción, ID del cliente, Importe de transacción, Método de pago, etc. Las tablas se pueden unir con el campo ID del cliente común. Por lo tanto, puede consultar la tabla para generar informes valiosos como, por ejemplo, informes de ventas por sector o compañía, que pueden servir de base para enviar mensajes a clientes potenciales.

Las bases de datos relacionales también suelen estar asociadas con bases de datos transaccionales, que ejecutan mandatos o transacciones de forma colectiva. Un ejemplo conocido que se utiliza para ilustrar esto es una transferencia bancaria. Se extrae un importe definido de una cuenta y se deposita en otra. El importe total de dinero se retira y se deposita, y esta transacción no puede producirse parcialmente en ningún sentido. Las transacciones tienen propiedades específicas. Representadas por el acrónimo ACID, las propiedades ACID se definen como:

• Atomicidad: todos los cambios en los datos se realizan como si fueran una única operación. Es decir, se realizan todos los cambios o ninguno.

• Consistencia: los datos permanecen en un estado coherente desde el inicio hasta la finalización, lo que refuerza la integridad de los datos.

• Aislamiento: el estado intermedio de una transacción no es visible para otras transacciones y, como resultado, las transacciones que se ejecutan simultáneamente parecen que están serializadas.

• Durabilidad: después de la finalización satisfactoria de una transacción, los cambios en los datos persisten y no se deshacen, incluso en el suceso de un error de sistema.

Estas propiedades habilitan un procesamiento de transacciones fiable.

Base de datos relacional frente al sistema de gestión de bases de datos relacionales

Mientras que una base de datos relacional organiza los datos basándose en un modelo de datos relacionales, un sistema de gestión de bases de datos relacionales (RDBMS) es una referencia más específica al software de base de datos subyacente que permite a los usuarios mantenerlo. Estos programas permiten a los usuarios crear, actualizar, insertar o suprimir datos en el sistema, y proporcionan:

• Estructura de datos

• Acceso a varios usuarios

• Control de privilegios

• Acceso a red

Algunos ejemplos de sistemas RDBMS conocidos pueden ser MySQL, PostgreSQL e IBM DB2. Además, un sistema de bases de datos relacionales es distinto de un sistema de gestión de bases de datos básicas (DBMS) en que almacena los datos en tablas, mientras que un DBMS almacena la información como archivos.

Inventado por Don Chamberlin y Ray Boyce en IBM, el lenguaje de consulta estructurado (SQL) es el lenguaje de programación estándar para interactuar con los sistemas de gestión de bases de datos relacionales, que permite al administrador de bases de datos añadir, actualizar o suprimir filas de datos fácilmente. Originalmente conocido como SEQUEL, se simplificó a SQL debido a un conflicto de marca registrada. Las consultas SQL también permiten a los usuarios recuperar datos de bases de datos usando solo unas pocas líneas de código. Dada esta relación, es fácil ver por qué las bases de datos relacionales también se denominan a veces "bases de datos SQL".  

Usando el ejemplo anterior, puede construir una consulta para encontrar las principales 10 transacciones por compañía para un año específico con el siguiente código:

SELECT COMPANY_NAME, SUM(TRANSACTION_AMOUNT)

FROM TRANSACTION_TABLE A

LEFT JOIN CUSTOMER_TABLE B

ON A.CUSTOMER_ID = B.CUSTOMER_ID

WHERE YEAR(DATE) = 2022

GROUP BY 1

ORDER BY 2 DESC

LIMIT 10

La capacidad de unir datos de esta manera nos ayuda a reducir la redundancia en nuestros sistemas de datos, lo que permite a los equipos de datos mantener una tabla maestra para los clientes en lugar de duplicar esta información si hubiera otra transacción en el futuro. Para obtener más información, Don describe con más detalle la historia de SQL en un artículo que puede consultar aquí (enlace externo a IBM).

Antes de las bases de datos relacionales, las empresas utilizaban un sistema de base de datos jerárquico con una estructura en forma de árbol para las tablas de datos. Estos primeros sistemas de gestión de bases de datos (DBMS) permitían a los usuarios organizar grandes cantidades de datos. Sin embargo, eran complejos, a menudo dependían de una aplicación particular y estaban limitados en las formas en que podían descubrir dentro de los datos. Estas limitaciones llevaron al investigador de IBM Edgar F. Codd a publicar un artículo (enlace externo a IBM) (PDF, 1,5 MB) en 1970 titulado "Un modelo relacional de datos para grandes bancos de datos compartidos", donde teorizó el modelo de base de datos relacional. En el modelo propuesto, la información podía recuperarse sin conocimientos informáticos especializados. Propuso organizar los datos en función de relaciones significativas como tuplas o pares de atributo-valor. Los conjuntos de tuplas se denominaron relaciones, que en última instancia permitían la fusión de datos en las tablas.

En 1973, el laboratorio San Jose Research Laboratory, ahora conocido como el Almaden Research Center, inició un programa llamado System R (R de relacional) para probar esta teoría relacional con lo que llamó "una implementación de potencia industrial". Finalmente, se convirtió también en una base de pruebas para SQL, lo que favoreció su adopción más amplia en un breve período de tiempo. Sin embargo, la adopción de SQL por parte de Oracle tampoco perjudicó su popularidad entre los administradores de bases de datos.

En 1983, IBM presentó la familia DB2 de base de datos relacionales, llamada así porque era la segunda familia de software de gestión de bases de datos de IBM. Actualmente, es uno de los productos de más éxito de IBM, que continúa gestionando miles de millones de transacciones diarias en la infraestructura de cloud y se utiliza como capa fundacional en las aplicaciones de machine learning.

Para obtener más información sobre la historia de IBM, pulse aquí.

Mientras que las bases de datos relacionales estructuran los datos en un formato tabular, las bases de datos no relacionales no tienen un esquema de base de datos tan rígido. De hecho, las bases de datos no relacionales organizan los datos de forma diferente según el tipo de base de datos. Independientemente del tipo de base de datos no relacional, el objetivo de todas es resolver los problemas de flexibilidad y escalabilidad inherentes en los modelos relacionales que no son ideales para formatos de datos no estructurados, como texto, vídeo e imágenes. Estos tipos de bases de datos incluyen:

• Almacén de pares de clave-valor: este modelo de datos sin esquema se organiza en un diccionario de pares de clave-valor, donde cada elemento tiene una clave y un valor. La clave podría ser algo similar a lo que encontramos en una base de datos SQL, como un ID de carro de la compra, mientras que el valor es una matriz de datos, como cada artículo individual en el carro de la compra de ese usuario. Se usa comúnmente para almacenar en caché y guardar información de sesión del usuario, como carritos de compra. Sin embargo, no es ideal cuando necesita extraer varios registros a la vez. Redis y Memcached son ejemplos de bases de datos de código abierto con este modelo de datos.

• Almacén de documentos: como su propio nombre indica, las bases de datos de documentos almacenan datos como documentos. Pueden ser útiles en la gestión de datos semiestructurados y, por lo general, los datos se almacenan en formatos JSON, XML o BSON. Esto mantiene los datos juntos cuando se utilizan en aplicaciones, reduciendo la cantidad de conversión necesaria para utilizarlos. Los desarrolladores también obtienen más flexibilidad porque los esquemas de datos no tienen que coincidir entre documentos (por ejemplo, name vs. first_name). Sin embargo, esto puede ser problemático para transacciones complejas, ya que puede generar corrupción de datos. Entre los casos de uso más populares de bases de datos de documentos destacan los sistemas de gestión de contenidos y los perfiles de usuario. Un ejemplo de base de datos orientada a documentos es MongoDB, el componente de base de datos de la pila MEAN.

• Almacén distribuido en columnas: estas bases de datos almacenan información en columnas, lo que permite a los usuarios acceder solo a las columnas específicas que necesitan sin asignar memoria adicional a datos irrelevantes. Esta base de datos intenta resolver las deficiencias de los almacenes de documentos y pares de clave-valor, pero dado que puede ser un sistema más complejo de gestionar, no se recomienda su uso para equipos y proyectos más nuevos. Apache HBase y Apache Cassandra son ejemplos de bases de datos distribuidas en columnas de código abierto. Apache HBase se basa en el sistema de archivos distribuidos de Hadoop, que proporciona una forma de almacenar conjuntos de datos dispersos. Su uso es frecuente en muchas aplicaciones de big data. Apache Cassandra, por otro lado, se ha diseñado para gestionar grandes cantidades de datos en varios servidores y agrupaciones en clúster que abarcan varios centros de datos. Se utiliza para diversos casos de uso, por ejemplo, en sitios web de redes sociales y análisis de datos en tiempo real.

• Almacén de grafos: este tipo de base de datos normalmente alberga datos de un grafo de conocimiento. Los elementos de datos se almacenan como nodos, aristas y propiedades. Cualquier objeto, ubicación o persona puede ser un nodo. Una arista define la relación entre los nodos. Las bases de datos de grafos se utilizan para almacenar y gestionar una red de conexiones entre elementos dentro del grafo. Neo4j (enlace externo a IBM) es un servicio de base de datos de grafos basado en Java con una edición de comunidad de código abierto donde los usuarios pueden comprar licencias para copias de seguridad en línea y extensiones de alta disponibilidad, o la versión con licencia con copia de seguridad y extensiones incluidas.

Las bases de datos NoSQL también dan prioridad a la disponibilidad frente a la consistencia.

Cuando los equipos se ejecutan en una red, invariablemente deben decidir si desean dar prioridad a resultados consistentes (donde cada respuesta es siempre la misma) o a un elevado tiempo de actividad, lo que se denomina "disponibilidad". Esto se conoce como la "Teoría CAP", que son las siglas en inglés de Consistencia, Disponibilidad o Tolerancia de partición. Las bases de datos relacionales garantizan que la información esté siempre sincronizada y sea consistente. Algunas bases de datos NoSQL, como Redis, prefieren dar siempre una respuesta. Eso significa que la información que recibe de una consulta puede ser incorrecta durante unos segundos, tal vez hasta medio minuto. En los sitios de redes sociales, esto significa ver una foto de perfil antigua cuando la más nueva es muy reciente. La alternativa puede ser un tiempo de espera excedido o un error. Por otro lado, en las transacciones bancarias y financieras, un error y un reenvío serán mejores que una información antigua incorrecta.

Para ver un resumen completo de las diferencias entre SQL y NoSQL, consulte "Bases de datos SQL frente a NoSQL: ¿en qué se diferencian?"

La principal ventaja del enfoque de las bases de datos relacionales es la capacidad de crear información significativa uniendo las tablas. Unir tablas le permite comprender las relaciones entre los datos o cómo se relacionan las tablas. SQL incluye la capacidad de contar, añadir, agrupar y también combinar consultas. SQL puede realizar funciones matemáticas básicas y de subtotales, así como transformaciones lógicas. Los analistas pueden solicitar los resultados por fecha, nombre o cualquier columna. Estas características convierten el enfoque relacional en la herramienta de consulta más popular en las empresas a día de hoy.

Las base de datos relacionales tienen varias ventajas en comparación con otros formatos de bases de datos:

Facilidad de uso

Gracias a la vida útil del producto, hay más de una comunidad en torno a las bases de datos relacionales, lo que perpetúa parcialmente su uso continuado. SQL también facilita la recuperación de conjuntos de datos de varias tablas y la ejecución de transformaciones simples como el filtrado y la agregación. El uso de índices dentro de las bases de datos relacionales también les permite localizar esta información rápidamente sin buscar en cada fila de la tabla seleccionada.

Aunque las bases de datos relacionales se han visto históricamente como una opción de almacenamiento de datos más rígida e inflexible, los avances en la tecnología y las opciones de DBaaS están cambiando esa percepción. Aunque todavía hay una mayor sobrecarga cuando se desarrollan esquemas en comparación con las ofertas base de datos NoSQL, las bases de datos relacionales se están volviendo más flexibles a medida que se migran a entornos en el cloud.

Menor redundancia 

Las bases de datos relacionales pueden eliminar la redundancia de dos formas. El propio modelo relacional reduce la redundancia de datos a través de un proceso conocido como la normalización. Como se ha explicado anteriormente, una tabla de clientes solo debe registrar registros exclusivos de información del cliente, en lugar de duplicar esta información para varias transacciones.

Los procedimientos almacenados también permiten reducir el trabajo repetitivo. Por ejemplo, si el acceso a las bases de datos está restringido a determinados roles, funciones o equipos, un procedimiento almacenado puede ayudar a gestionar el control de acceso. Estas funciones reutilizables liberan el codiciado tiempo de los desarrolladores de aplicaciones para que puedan dedicarse a trabajos de mayor impacto.

Facilidad de copia de seguridad y recuperación tras desastre 

Las bases de datos relacionales son transaccionales, es decir, garantizan que el estado de todo el sistema sea consistente en todo momento. La mayoría de las bases de datos relacionales ofrecen opciones fáciles de exportar e importar, lo que hace que la copia de seguridad y la restauración sean triviales. Estas exportaciones pueden realizarse incluso mientras la base de datos se está ejecutando, lo que facilita la restauración en caso de error. Las bases de datos relacionales modernas basadas en el cloud pueden realizar una duplicación continua, gracias a lo cual la pérdida de datos en la restauración se mide en segundos o menos. La mayoría de los servicios gestionados en el cloud permiten crear réplicas de lectura, como en IBM® Cloud Databases for PostgreSQL. Estas réplicas de lectura permiten almacenar una copia de solo lectura de sus datos en un centro de datos en el cloud. Las réplicas también se pueden promocionar a instancias de lectura/escritura para la recuperación tras desastre .