Bases de datos SQL (bases de datos relacionales)

Se llama base de datos relacional también bajo las siglas BDR, a un tipo de base de datos específica, basada en el modelo relacional definido en la década de 1970 por el científico informático inglés, Edgar Frank Codd.

Bajo el paradigma del modelo relacional, podemos definir una base de datos relacional (BDR) como una base de datos (BBDD) que almacena y permite el acceso a conjuntos de datos relacionados entre sí bajo unas normas claras, específicas y bien definidas.

Una base de datos relacional (BDR) será una base de datos formada por un conjunto de tablas estructuradas en filas (registros) y columnas (campos) relacionadas entre sí, por medio de un campo común que generalmente se le conoce como ID, identificador o clave.

Será preciso, antes de profundizar en el modelo relacional y los diferentes tipos de relaciones, entender correctamente qué es una tabla de base de datos y sus componentes. Una vez aclarados dichos conceptos, será más fácil entender cómo se establecen las relaciones de datos.

¿Qué es una tabla?

Una tabla de base de datos (BBDD) es un objeto o estructura cuya finalidad principal consiste en el almacenamiento de datos. Las tablas se dividen en las dos siguientes estructuras principales:

• Campos: Los campos de una tabla se corresponderán al nombre de cada columna. Estos deben ser únicos y tener un tipo de dato asociado (VARCHAR, INTEGER, DATE, BIT …)

• Registros: Un registro, también conocido como fila o tupla, se corresponde con el conjunto de campos de cada fila de la tabla. Para entenderlo de manera más sencilla podemos decir que cada fila de datos de una tabla conforma un registro. Cada registro tiene que ser único y no duplicado, lo que implica que al menos el dato de uno de sus campos nunca debe repetirse. Dicho dato generalmente corresponderá con el identificador o Primary Key.

Para entender estos conceptos, vamos a suponer que estamos trabajando con una tabla sencilla llamada: alumnos con los siguientes campos y registros:

Viendo este ejemplo podemos sacar las siguientes conclusiones:

• La tabla alumnos tiene tres campos: id_alumno (INT autoincremental), nombre (VARCHAR) y apellido (VARCHAR).

• La tabla alumnos consta de tres registros o filas (1 Francisco García) conforma el primer registro y así sucesivamente.

• El campo id_alumno como su nombre indica es el identificador único e irrepetible de cada registro. Este campo se definirá como Primary Key o clave primaria.

CLAVES

Para entender mejor cómo funcionan las tablas y se relacionan entre sí, es necesario comprender los diferentes tipos de claves que puede presentar una tabla.

Primary Key

Una Primary Key, es una clave formada por uno o una combinación de campos, que identifican de manera única y exclusiva cada registro de una tabla en el modelo de bases de datos relacionales. El valor de la Primary Key deberá ser irrepetible en cada registro y nunca admitirá nulos.

En el ejemplo de la tabla alumnos, el campo id_alumno cumple todos los requisitos de Primary Key. No tiene valor nulo, no se repite y permite identificar de manera única a cada registro.

Unique Key

Una Unique Key como en el caso anterior también estará formada por un campo o combinación de ellos que nos permiten identificar de manera única y exclusiva un registro determinado. Se utiliza principalmente para evitar que se inserten valores duplicados en una columna específica o combinación de columnas que participen en la restricción UNIQUE y no formen parte de la Primary Key.

A diferencia de la Primary Key, la Unique Key nos permite generar índices con valores nulos en alguno de sus campos. Además, mejora el rendimiento de la recuperación de datos a través de búsquedas más rápidas y eficientes.

Supongamos que en el ejemplo de la tabla alumnos incluimos un campo más que no admita nulos llamado dni para almacenar el documento nacional de identidad. Si quisiéramos, podríamos utilizar ese nuevo campo como Unique Key ya que no se repite e identifica exclusivamente a cada registro. También podríamos determinar que nuestra Unique Key fuese la combinación de los campos apellido y dni. De esta manera, aunque apellido admitiera nulos, podríamos seguir identificando a nuestros registros únicamente a través del campo dni.

Foreign Key

Una Foreign Key es una clave externa que permite establecer relaciones entre dos tablas. Dicha clave se vincula directamente a la Primary Key de la tabla principal con la que se establece la relación. Esto quiere decir que la Foreign Key solo puede contener valores que existan en la Primary Key de la tabla relacionada, asegurando que se mantengan las referencias entre ambas claves.

Las Foreign Key controlan y evitan que pueda modificarse una Primary Key y/o eliminar un registro si existe en alguna otra tabla una Foreign Key que haga referencia a dicho registro. A esta ley inviolable se le conoce como integridad referencial, y nos asegura que siempre haya cohesión y coherencia entre los datos de las diferentes tablas de una base de datos.

La integridad referencial es una de las propiedades más importantes de las bases de datos relacionales y nos asegura tanto la integridad de los datos como la sincronización de las relaciones en las operaciones de eliminación y actualización.

Para explicar de manera más gráfica la Foreign Key, supongamos que aparte de la tabla alumnos tenemos una segunda tabla llamada expediente:

Viendo este ejemplo podemos sacar las siguientes conclusiones:

• La tabla expediente tiene una Primary Key (id_expediente) que identifica de manera única cada registro.

• La tabla expediente se relaciona con la tabla alumnos a través de la clave Foreign Key id_alumno. Dicha clave se vincula con la Primary Key id_alumno de la tabla alumnos estableciendo una relación entre ambas tablas.

• Se está estableciendo un tipo de relación 1 a 1, ya que un alumno solo puede tener un expediente y un expediente solo puede pertenecer a un alumno. En la siguiente sección se explican los tipos de relaciones.

La relación entre las tablas alumnos y expediente nos permite entre otras cosas obtener información de ambas tablas desde una sola consulta. Por ejemplo, podríamos visualizar en una única consulta el nombre del alumno junto al estado de su expediente, ambos campos pertenecientes a tablas independientes pero relacionadas.

Por otro lado y con finalidad de ejemplificar la integridad referencial, supongamos que queremos eliminar directamente de la tabla alumnos, el primer registro referente a Francisco García. Esta acción nos daría un error de violación de Foreign Key ya que ese registro está vinculado a la tabla expediente. Si quisiéramos por tanto eliminar el registro de base de datos, tenemos que asegurarnos de eliminarlo de todas aquellas tablas relacionadas en las que este presente. A esto se le conoce como borrado y/o actualización en cascada, siendo otro de los aspectos claves de las bases de datos relacionales.

Candidate Key

Una Candidate Key es un campo o conjunto de campos que sin definirse como Primary Key, cumplen las condiciones específicas de la misma para identificar de manera única a cada registro.

El campo dni de la tabla alumnos sería un buen ejemplo de Candidate Key, ya que es irrepetible, no puede ser null y permite por si mismo identificar univocamente cualquier registro.

Alternate Key

Una Alternate Key es, en definitiva, una Candidate Key o clave candidata secundaria que cumple las condiciones de una Primary Key para identificar de manera única una fila en una tabla, pero no se establece como tal. A veces se las conoce como claves secundarias y definen el conjunto de claves candidatas diferentes a la Primary Key.

Para entender mejor la diferencia entre una Candidate Key y una Alternate Key supongamos el siguiente escenario. Cuando se define una tabla, todos los campos susceptibles de definirse como Primary Key son en esencia Candidate Key. Una vez que el administrador de base de datos ha establecido una Primary Key, el resto Candidate Key que no han sido utilizadas se convierten en Alternate Key como claves secundarias.

Por ende, podemos deducir que en esencia Candidate Key y Alternate Key es lo mismo, solo difiriendo su nomenclatura en el momento final que se define la Primary Key de la tabla.

Composite Key

Una Composite Key no es más que una clave que para identificar de manera única a un registro y ser susceptible de utilizarse como Primary Key, necesita de la utilización de dos o más campos, por lo que también es conocida como clave concatenada. Los campos de dicha clave compuesta por si solos no son suficientes para identificar de manera única a un registro por lo que será dependiente de varios campos.

Para entender este concepto, supongamos el caso de una tabla que en lugar de tener un identificador secuencial como Primary Key, se quisiera identificar un registro por el nombre de usuario.

nombre	apellidos	fecha_nacimiento	nacionalidad
Andrés	Rodríguez Ruiz	01-11-1989	española
Andrés	Rodríguez Ruiz	24-07-2001	española
Carmen	Navarro García	24-07-2001	chilena

Supongamos que quisiéramos identificar el primer registro de la supuesta tabla. Ninguno de los campos por sí solos cumple las condiciones para identificarlo de manera única como Primary Key. Sin embargo, podríamos conformar una Composite Key susceptible de utilizarse como Primary Key concatenando los campos nombre, apellidos y fecha_nacimiento, siendo los tres datos necesarios para poder identificar cada registro de manera única.

Incluso en el ejemplo anterior cabe la remota posibilidad que existiera un usuario que coincidiera con otra persona ya registrada tanto en nombre, apellidos y fecha_nacimiento. Si ese fuera el caso, dicha persona no podría insertarse en la base de datos por violar la ley de unicidad que debe poseer toda Primary Key. Esto pone de manifiesto la importancia, en la medida de los posible, de utilizar campos por sí mismos con valores irrepetibles, como podría se algún tipo de identificador único o un código secuencial.

Super Key

Una Super Key es un conjunto de uno o más atributos, que pueden identificar de manera única una fila en una tabla. Podríamos decir que las Super Key son todas las combinaciones de atributos posibles que nos permiten identificar un registro. Dichos subconjuntos o Super Key permiten al administrador de BBDD, seleccionar las claves candidatas filtrando aquellas que carezcan de atributos redundantes para la identificación de un registro.

Modelo Relacional

El modelo relacional, como su nombre indica, es un modelo de datos basado en el concepto matemático de relación entre las diferentes tablas que conforman una base de datos. Dicho modelo está basado en la lógica de predicados y la teoría de Conjuntos y sigue siendo a día de hoy, el modelo más utilizado para modelar y administrar datos de manera dinámica.

Como hemos visto anteriormente, se basa en la definición de tablas con sus respectivas filas y columnas, y la relación de las tablas entre sí a través de la definición de los identificadores únicos (Primary Key) y las claves que se asocian con dichos identificadores para montar las relaciones (Foreign Key).

Ventajas del modelo relacional

El uso del modelo relacional para gestionar y administrar nuestras bases de datos nos ofrece principalmente las siguientes ventajas frente a otros modelos de bases de datos:

• Facilita la gestión y administración de grandes cantidades de datos de manera segura y uniforme.
• Dispone de herramientas y procesos que evitan la duplicidad de los datos.
• Garantiza la integridad referencial, asegurándonos una correcta cohesión y coherencia de datos. Para eliminar u actualizar un registro el sistema asegura que el cambio en la base de datos se aplique en cascada a todos los registros dependientes de las diferentes tablas relacionadas.
• Permite la normalización de las bases de datos como proceso que facilita aplicar una serie de reglas en las relaciones con el objetivo principal de minimizar la redundancia de datos y facilitar la gestión de los mismos.

Modelo ACID

Cuando hablamos de bases de datos es muy común escuchar el termino ACID, fusión de las siglas de los conceptos (Atomicity, Consistency, Isolation y Durability). El modelo ACID es un conjunto de propiedades aplicables a las bases de datos con el objetivo de garantizar la seguridad de las transacciones.

Podemos definir una transacción como una operación lógica o unidad única de trabajo que garantiza que una secuencia de operaciones funcione como una unidad. De esta manera si alguna operación falla durante la transacción, el proceso al completo queda invalidado, asegurándonos la integridad de la base de datos.

Aclarado este punto, pasemos a definir las cuatro propiedades básicas del modelo ACID:

1. Atomicity o Atomicidad: Esta propiedad garantiza que la transacción se comporte como una unidad atómica. Como antes hemos mencionado, esta propiedad garantiza que para que una transacción finalice correctamente, todas las partes de las que está compuesta deben haber funcionado previamente. Si alguna parte es errónea, todo el conjunto falla.

2. Consistency o Consistencia: Esta propiedad se encarga principalmente de garantizar la integridad referencial de nuestra base de datos. Dicho de otra manera, el sistema garantiza la ejecución de transacciones válidas que sigan manteniendo la integridad de los datos de acuerdo a las reglas aplicadas.

3. Isolation o Aislamiento: Esta propiedad asegura que cada transacción debe ser ejecutada en aislamiento total de manera independiente para salvaguardar cualquier tipo de error en el caso que se ejecuten transacciones paralelas.

4. Durability o durabilidad: Esta propiedad implica que una vez finalice una transacción correctamente, los cambios en la base de datos serán permanentes, asegurándonos una correcta persistencia de datos.