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 a través de una clave principal o una clave externa.

Estos identificadores únicos demuestran las diferentes relaciones que existen entre las tablas, y estas relaciones generalmente se ilustran a través de diferentes tipos de modelos de datos.

Los analistas utilizan consultas SQL para combinar diferentes puntos de datos y resumir el rendimiento empresarial, lo que permite a las organizaciones obtener insights, optimizar los flujos de trabajo e identificar nuevas oportunidades.

Por ejemplo, imagine que su empresa mantiene una tabla de base de datos con información de clientes, que contiene datos de la empresa a nivel de cuenta. También puede haber una tabla diferente, que describe todas las transacciones individuales que se alinean con esa cuenta. Juntas, estas tablas pueden proporcionar información acerca de las diferentes industrias que compran un producto de software específico.

Las columnas (o campos) de la tabla de clientes pueden ser ID de cliente, Nombre de la empresa, Dirección de la empresa, Industria, etc. Las columnas de una tabla de transacciones pueden ser Fecha de transacción, ID de cliente, Cantidad de la transacción, Método de pago, etc. Las tablas se pueden unir con el campo ID de cliente común. Por lo tanto, puede consultar la tabla para producir informes valiosos, como informes de ventas por industria o empresa, que pueden informar mensajes a clientes potenciales.

Las bases de datos relacionales también suelen estar asociadas con bases de datos transaccionales, que ejecutan comandos o transacciones de forma colectiva.

Un ejemplo popular que se utiliza para ilustrar esto es una transferencia bancaria. Se retira una cantidad definida de una cuenta y luego se deposita en otra. La cantidad total de dinero se retira y se deposita, y esta transacción no puede ocurrir en ningún sentido parcial. Las transacciones tienen propiedades específicas.

Representado por las siglas ACID, las propiedades de ACID se definen como:

Atomicidad

Todos los cambios en los datos se realizan como si fueran una sola operación. Es decir, se realizan todos los cambios, o ninguno.

Consistencia

Los datos permanecen en un estado consistente de un estado a otro, 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 estar serializadas.

Durabilidad

Después de completar con éxito una transacción, los cambios en los datos persisten y no se deshacen, incluso en caso de falla del sistema.

Estas propiedades permiten un procesamiento de transacciones confiable.

Base de datos relacional frente a sistema de gestión de base de datos relacional

Mientras que una base de datos relacional organiza los datos en función de un modelo de datos relacional, un sistema de gestión de base de datos relacional (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 eliminar datos en el sistema y proporcionan:

• Estructura de datos
• Acceso multiusuario
• Control de privilegios
• Acceso a la red

Los ejemplos de sistemas RDBMS populares incluyen MySQL, PostgreSQL e IBM DB2. Además, un sistema de base de datos relacional se diferencia de un sistema básico de gestión de bases de datos (DBMS) en que almacena datos en tablas, mientras que un DBMS almacena 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, lo que permite que el administrador de la base de datos agregue, actualice o elimine filas de datos fácilmente.

Originalmente conocido como SEQUEL, se simplificó a SQL debido a un problema 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é a veces las bases de datos relacionales también se denominan "bases de datos SQL".  

Usando el ejemplo anterior, puede construir una consulta para encontrar las 10 transacciones principales por empresa 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 dentro de nuestros sistemas de datos, lo que permite que los equipos de datos mantengan 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 detalla más sobre la historia de SQL que puede consultar en su artículo aquí (enlace externo a IBM).

Antes de las bases de datos relacionales, las empresas usaban un sistema de base de datos jerárquica con una estructura en forma de árbol para las tablas de datos. Estos primeros sistemas de gestión de bases de datos (DBMS) permitieron a los usuarios organizar grandes cantidades de datos.

Sin embargo, eran complejos, a menudo propietarios de una aplicación en particular, y limitados en las formas en que podían descubrirse dentro de los datos. Estas limitaciones eventualmente 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", que teorizó el modelo de base de datos relacional.

En este modelo propuesto, la información podrí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, lo que finalmente permitió la fusión de datos en 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". En última instancia, también se convirtió en un campo de pruebas para SQL, lo que permitió que se adoptara más ampliamente en un corto 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 bases de datos relacionales, llamada así porque era la segunda familia de software de gestión de bases de datos de IBM.

Hoy, es uno de los productos más exitosos de IBM, continúa manejando miles de millones de transacciones todos los días en la infraestructura de la nube y establece la capa fundamental para las aplicaciones de machine learning.

Para leer más acerca de la historia de IBM, haga clic 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 manera diferente según el tipo de base de datos.

Independientemente del tipo de base de datos no relacional, todas tienen como objetivo resolver los problemas de flexibilidad y escalabilidad inherentes a los modelos relacionales que no son ideales para formatos de datos no estructurados, como texto, video e imágenes.

Estos tipos de bases de datos incluyen:

Almacén clave-valor

Este modelo de datos sin esquema se organiza en un diccionario de pares clave-valor, donde cada elemento tiene una clave y un valor. La clave podría ser algo similar que se encuentra en una base de datos SQL, como una ID de carrito de compras, mientras que el valor es una matriz de datos, como cada artículo individual en el carrito de compras de ese usuario.

Se usa comúnmente para almacenar en caché y almacenar información de sesión de usuario, como carritos de compras. 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 sugiere el nombre, las bases de datos de documentos almacenan datos como documentos. Pueden ser útiles para gestionar datos semiestructurados y los datos generalmente se almacenan en formatos JSON, XML o BSON. Esto mantiene los datos juntos cuando se usan en aplicaciones, lo que reduce la cantidad de traducción necesaria para usar los datos.

Los desarrolladores también ganan más flexibilidad ya que los esquemas de datos no necesitan coincidir entre documentos (por ejemplo, nombre vs. primer nombre). Sin embargo, esto puede ser problemático para transacciones complejas, lo que lleva a la corrupción de datos. Los casos de uso populares de bases de datos de documentos incluyen sistemas de gestión de contenido y perfiles de usuario.

Un ejemplo de una base de datos orientada a documentos es MongoDB, el componente de base de datos del lote de MEAN.

Almacén de columnas anchas

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 valores clave y los almacenes de documentos, 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 de columna ancha 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, que se usa comúnmente en muchas aplicaciones de big data. Apache Cassandra, por otro lado, ha sido diseñado para gestionar grandes cantidades de datos en múltiples servidores y agrupaciones que abarcan múltiples centros de datos.

Se ha utilizado para una variedad de casos de uso, como sitios web de redes sociales y analítica de datos en tiempo real.

Almacén de gráficos

Este tipo de base de datos normalmente alberga datos de un gráfico de conocimiento. Los elementos de datos se almacenan como nodos, bordes y propiedades. Cualquier objeto, lugar o persona puede ser un nodo. Un borde define la relación entre los nodos.

Las bases de datos de gráficos se utilizan para almacenar y gestionar una red de conexiones entre elementos dentro del gráfico. Neo4j (enlace externo a IBM), un servicio de base de datos basado en gráficos y 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 una versión con licencia preempaquetada con copias de seguridad y extensiones incluidas.

Las bases de datos NoSQL también priorizan la disponibilidad sobre la consistencia.

Cuando las computadoras funcionan sobre una  red, invariablemente necesitan decidir priorizar resultados consistentes (donde cada respuesta es siempre la misma) o un alto tiempo de actividad, llamado "disponibilidad". Esto se denomina "teoría CAP", que significa 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 proporcionar siempre una respuesta. Eso significa que la información que recibe de una consulta puede ser incorrecta por unos segundos, quizás hasta medio minuto.

En los sitios de redes sociales, esto significa ver una foto de perfil antigua cuando la más reciente fue actualizada hace solo un momento. La alternativa podría ser un tiempo de espera o un error. Por otro lado, en las transacciones bancarias y financieras, un error y un reenvío puede ser mejor que la información antigua e incorrecta.

Para obtener un resumen completo de las diferencias entre SQL y NoSQL, consulte "Bases de datos SQL frente a NoSQL: ¿Cuál es la diferencia?"

El principal beneficio del enfoque de base de datos relacional 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 conectan las tablas.

SQL incluye la capacidad de contar, agregar, agrupar y también combinar consultas. SQL puede realizar funciones matemáticas básicas y subtotales y transformaciones lógicas. Los analistas pueden ordenar los resultados por fecha, nombre o cualquier columna.

Esas características hacen del enfoque relacional la herramienta de consulta más popular en los negocios hoy en día.

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

Facilidad de uso

En virtud de la vida útil de su producto, existe más 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 realiza transformaciones simples, como filtrado y agregación. El uso de índices dentro de las bases de datos relacionales también les permite ubicar esta información rápidamente sin buscar en cada fila de la tabla seleccionada.

Si bien históricamente las bases de datos relacionales se han visto como una opción de almacenamiento de datos más rígida e inflexible, los avances en tecnología y las opciones de DBaaS están cambiando esa percepción.

Si bien aún hay más gastos generales para desarrollar esquemas en comparación con las soluciones de bases de datos NoSQL, las bases de datos relacionales se vuelven más flexibles a medida que migran a entornos en la nube.

Redundancia reducida 

Las bases de datos relacionales pueden eliminar la redundancia de dos formas. El propio modelo relacional reduce la redundancia de datos mediante un proceso conocido como normalización.

Como se señaló anteriormente, una tabla de clientes solo debe registrar registros únicos de información del cliente en lugar de duplicar esta información para múltiples transacciones.

Los procedimientos almacenados también ayudan a reducir el trabajo repetitivo. Por ejemplo, si el acceso a la base de datos está restringido a ciertos roles, funciones o equipos, un procedimiento almacenado puede ayudar a gestionar el control de acceso. Estas funciones reutilizables liberan un valioso tiempo del desarrollador de aplicaciones para abordar el trabajo de alto impacto.

Facilidad de copia de seguridad y recuperación de desastres 

Las bases de datos relacionales son transaccionales: garantizan que el estado de todo el sistema sea consistente en todo momento.

La mayoría de las bases de datos relacionales ofrecen opciones sencillas de exportación e importación, lo que hace que la copia de seguridad y la restauración sean triviales. Estas exportaciones pueden ocurrir incluso mientras la base de datos se está ejecutando, lo que facilita la restauración en caso de falla. Las bases de datos relacionales modernas basadas en la nube pueden realizar una duplicación continua, lo que hace que la pérdida de datos durante la restauración se mida en segundos o menos.

La mayoría de los servicios gestionados en la nube le permiten crear réplicas de lectura, como en IBM® Cloud Databases for PostgreSQL. Estas réplicas de lectura le permiten almacenar una copia de solo lectura de sus datos en un centro de datos en la nube. Las réplicas también se pueden promocionar a instancias de lectura/escritura para la recuperación de desastres.