Modelo relacional: Base de datos relacional

Bien, para iniciar con este interesante tema debemos establecer algunos conceptos básicos para ir avanzando paso a paso, así que comencemos con los fundamentos del modelo relacional.

¿Qué es el modelo relacional?

El modelo relacional es el fundamento para el modelado y gestión de bases de datos, está basado en la lógica de predicados y en la teoría de conjuntos.

¿Cuándo fue postulado el modelo relacional y por quien?

• El modelo relacional nace en 1970
• Fue postulado por Edgar Frank Codd en los laboratorios del gigante de las computadoras IBM.

Ventajas del modelo relacional

El modelo relacional es uno de los mas utilizados hasta la fecha en que he escrito este post, incluso, la base de datos de esta página es relacional y así como EWebik, hay millones de sitios web que almacenan la información en bases de datos relacionales, y esto se debe a que tiene grandes ventajas, por ejemplo:

• Nos proporciona herramientas que nos permiten evitar la duplicidad de registros.
• Garantiza la integridad de datos, sobre todo en el caso referencial, es decir, cuando eliminamos un dato, se eliminan todos los registros con dependencias.
• Favorece la normalización.

Desventajas del modelo relacional

Si, tiene algunas desventajas, sobre todo para ciertas aplicaciones donde se manipulen datos como:

• Datos gráficos
• Multimedia
• CAD
• Y en sistemas con datos geográficos
• Tipos de datos de texto

Para los casos anteriores se deberá analizar el tipo de aplicación y diseñar una base de datos que nos permita manipular la información con el mejor rendimiento posible, por ejemplo, las bases orientadas a objetos, suelen usarse en este tipo de aplicaciones.

Fundamentos del modelo relacional

En el modelo relacional los datos se almacenan en relaciones, donde cada relación es considerado un conjunto de datos independiente y dentro de cada conjunto el orden de los datos no es importante. Para comprender como opera el modelo relacional pasemos a analizar las bases de datos relacionales y sus características, ya que de esta manera, estoy seguro comprenderás mejor los conceptos de:

• Relaciones
• Tuplas
• Atributos

¿Qué es una base de datos relacional?

Una base de datos relacional es un conjunto de relaciones, en donde dichas relaciones son un conjunto de tuplas y cada tupla es un conjunto de atributos.

Elementos principales de una base de datos relacional

La definición anterior quizá parezca un trabalenguas y para muchos sea difícil de comprender, así que te explicaré ¿Qué es una base relacional? Pero, desde una perspectiva diferente, por ejemplo:

Relaciones: Matrices o tablas

Primero trata de imaginar que una base de datos de este tipo es un conjunto de matrices o tablas,  y que, a ese conjunto de matrices o tablas le pondremos un nombre, le llamaremos relaciones.

Atributos (columnas) y tuplas (filas)

Excelente, ahora cada matriz o tabla la vamos a imaginar como:

• Cada fila como una tupla.
• Y cada columna como un atributo.

Ya se va entendiendo mejor ¿Cierto? Bajo estas consideración, es importante que comprendas que:

• Cada columna o atributos tengan un nombre único dentro de cada tabla.
• Al igual que cada tupla o fila, debiera ser diferente.

Ahora, cada atributo se divide en dos partes:

Atributos Simples (datos atómicos)

También denominados datos atómicos son aquellos que ya no pueden subdividirse en datos más simples, por ejemplo la edad de una persona.

Atributos Complejos (datos no atómicos)

Conocidos también como datos no atómicos, este tipo de atributos son aquellos datos que se pueden dividir en datos más simples, no obstante existen dos tipos de datos no atómicos, por ejemplo:

• Un tipo sería aquellos datos que se repiten, pero que al dividirse en datos más simples, significan lo mismo, por ejemplo: una lista de números de cuenta: 123456, 234567, 345678, al dividirlos tendríamos:
  • Cuenta1: 123456
  • Cuenta2: 234567
  • Cuenta3: 345678
• Otro tipo sería aquellos datos que se pueden dividir, pero que al ser divididos tienen diferente significado, por ejemplo: una dirección: República del Salvador, Olivar, Ciudad de México, al dividirse cada uno de los elementos cuenta con un significado diferente:
  • Calle: Republica del Salvador
  • Colonia: Olivar
  • Estado: Ciudad de México

Ahora ¿Cómo puedo decidir para ocupar, atributos atómicos, no atómicos y que tipo? 🤔 Esto realmente depende de la naturaleza de tu proyecto, por ejemplo:

• Quizá tengas una aplicación donde registras el nombre de una persona, pero no te interesa saber cual es su nombre, cual es su apellido paterno o materno, tu aplicación no lo demanda, para ese caso, podrías utilizar un atributo no atómico que simplemente se llame “nombre”.
• Pero ahora, si tu aplicación es de prestamos o renta de inmuebles, claro que te interesa conocer a las personas lo mejor posible, para este caso, si deberías ocupar un dato atómico, es decir, incrementar la exactitud de los datos en tus tablas, por lo tanto, descompondrías el nombre en, otros atributos atómicos, tal como:
  • nombre
  • apellido_paterno
  • apellido_materno

📌 NOTA: como desarrolladores, siempre debemos ver hacia futuro para poder tomar este tipo de decisiones, muchas veces no tenemos en cuenta que nuestras aplicaciones van a crecer y cuando llega ese momento la base de datos queda corta y hay que rediseñar e incluso en casos más serios, volver a crearla desde cero, siempre ten en cuenta el costo beneficio, tu presupuesto y sobre todo, la ética para hacer un buen diseño de base de datos.

Cuando hayas tomado la decisión y estés utilizando un tipo de atributo u otro, debes mantener la consistencia de los datos en todas tus tablas y recordar que los datos atómicos son mas fácil de consultar y mantener que los datos que no son atómicos, a continuación veremos algo de esto.

Concepto de derivabilidad en el modelo relacional

El concepto derivabilidad es algo abstracto, pero en resumen significa que:

Podemos considerar una tabla o relación derivable, siempre y cuando podamos extraer sus atributos desde otras relaciones u otras partes mediante una serie de operaciones.

Desde otra perspectiva este concepto indica que podemos dividir una relación en relaciones más simples, pero para poder explicarte mejor este concepto pasemos a ver el término de redundancia y verás que te de quedará mucho más claro.

Concepto de redundancia de datos en el modelo relacional

Cuando hablamos de redundancia simplemente hacemos referencia a la duplicidad de los datos y la podemos dividir en dos partes:

• Redundancia fuerte: este tipo de redundancia la encontramos en relaciones que tienen datos derivables y por ende son innecesarios y en la mayoría de los casos debe ser evitada.
• Redundancia débil: en este caso solo existen datos no derivables y mediante operaciones podremos obtener datos derivables, pero sin caer en el primer caso o redundancia fuerte, cabe mencionar que este caso es el más común al que deberíamos llegar en la mayoría de nuestras aplicaciones.

Ejemplo de redundancia y derivabilidad

Para comprender a la perfección estos dos conceptos que desde mi punto de vista son bastante abstracto, revisemos el siguiente ejemplo sobre “Salas de cines” donde tenemos una tabla con una redundancia fuerte.

Podemos ver fácilmente que hay una redundancia fuerte, ya que en prácticamente todas las columnas hay datos repetidos y por ende pueden ser derivables, tal como muestra la siguiente imagen, donde:

• Dividimos la relación o tabla anterior en relaciones más simples.
• Y mediante un conjunto de operaciones (Las cuales represente mediante las flechas), podemos obtener los datos derivables.

Este ejemplo aún se puede simplificar más y te invito a seguir simplificándolo por ti mismo, al al finalizar de leer este post.

Consistencia de los datos en el modelo relacional

La consistencia de los datos se refieren simplemente a la "calidad de los datos" y este término lo podemos interpretar mediante la duración, estabilidad y veracidad de los datos.

No obstante existen situaciones que bajan dicha calidad de los datos y nos pueden llevar a la inconsistencia de los mismo, por ejemplo:

• Existe error en la entrada de datos, ya sea por que hay reglas de negocio poco claras, error en la validación de datos o quizá se ha ingresado información mal intencionada por usuarios que desean hacer daño a nuestra información.
• También podemos caer en inconsistencia debido a la falta de datos, ya sea por una mala ejecución de las operaciones causando perdida en la información y creando datos que no están relacionados y por ende quedan perdidos en nuestras tablas.

Excelente viajero, si has llegado hasta aquí ya conoces a la perfección lo que es una relación, atributos y tuplas y, como esto se relaciona con matrices y tablas, ahora pasaremos a uno de los temas principales dentro del modelo relacional, el cual es el tema de las llaves (También se conocen como clave o Keys).

Identificación inequívoca de los datos: Creación de llaves (claves o keys)

Uno de los aspectos más importantes dentro del modelo relacional y por obvias razones de las bases de datos relacionales, es la identificación única o inequívoca de los datos, esto quiere decir que, cada dato dentro de una relación debe estar identificado plenamente y en forma única. Veamos un ejemplo para que se comprenda mejor.

Bien, de la tabla anterior trata de ubicar el dato “b₂” ¿Lo lograste? Si trataste de ubicarlo quizá te diste cuenta de lo siguiente:

• Podemos decir que b₂ esta en la Columna 2.
• Sin embargo, si ahora lo tratamos de ubicar por tupla o fila, no podemos asegurar que se encuentra en la fila 2, ya que en el modelo relacional, las filas no tienen un orden determinado.

Es aquí donde todo comienza a tener sentido las bases de datos relacionales, ya que para poder identificar un dato que pertenece a una fila, necesitamos crear llaves.

¿Qué son las llaves o claves en una base de datos relacional?

Una llave es un atributo con un valor único para cada tupla, lo que nos permite identificar a una y solo una tupla o fila dentro de nuestra relación o tabla.

¿Qué tal? Ves como todo tiene un por qué, ahora si agregamos un llave a nuestra tabla tendremos lo siguiente:

📌 Con tan solo agregar dicha llave, la cual tiene datos que no se pueden repetir todo cambia, ahora si, intenta nuevamente Identificar al dato b₂:

• b₂, se encuentra en la tupla con llave 2 y Atributo 2

Excelente, pero ¿La llave siempre debe ser un número consecutivo como en el ejemplo? Y la respuesta es NO, aunque más adelante veremos el tema de los índices y sus tipos y hay una correlación con el orden, por el momento solo piensa en esto, nosotros podemos identificar a un smartphone de forma natural, mediante:

• IMEI
• Número de teléfono
• Dirección MAC
• UID

No obstante, ahora debemos elegir cual será la llave de nuestra tabla, si yo tuviera que elegir, seleccionaría el IMEI, por ser un número único y que no se repite.

Si bien cada uno de los parámetros anteriores puede identificar de forma natural a un smartphone, dado que cada parámetro es inherente al dispositivo, que pasa con aquellas relaciones donde los datos no tienen un identificador natural ¿Qué clave debemos elegir? Realmente no hay que complicarnos, simplemente debemos tomar un número que se vaya incrementado y listo, a esto se le conoce como llave suplente, por ejemplo:

Tipos de claves

Ahora que ya conocemos el funcionamiento de las llaves, es importante que también comprendas que hay distintos tipos que nos ayudarán con la relación de nuestros datos, por ejemplo:

Clave primaria (Primary Key)

Una llave primaria o Primary Key en ingles la podemos representar mediante “PK” y, es aquella columna dentro de nuestra tabla y que hemos elegido nosotros para definir de manera unívocamente a cada una de nuestras filas, tal y como lo hicimos en los ejemplos anteriores. En la práctica nuestra Primary Key, puede estar conformada por una o mas columnas de nuestra tabla, esto se debe a que en muchas ocasiones por reglas de negocio deseamos que ciertos datos no se dupliquen en mas de dos columnas por cada fila, por ejemplo:

1. Supongamos que tenemos una aplicación que reporta la fecha hora del evento de encendido y apagado de un smartphone.
2. En nuestra tabla mínimo deberíamos tener los atributos:
   1. Llave
   2. Fecha hora
   3. Evento
3. Y ahora supongamos que quizá por alguna razón, el smartphone envía dos veces el evento de apagado con la misma fecha hora.
4. Si solo definimos como llave primaria al atributo llave, tendríamos una redundancia fuerte dentro de nuestra tabla, cada vez que el smartphone duplique la información, aquí no hay forma de subdividir nuestra tabla para eliminar dicha redundancia.
5. Para estas situaciones podemos definir una llave primaria con más e un atributo, que para este caso serían las tres columnas.
6. Con esta nueva llave primaria, cada vez que se intente agregar una fila duplicada, la base de datos rechazará la acción y mantendremos la calidad de los datos intacta.

Clave externa o foránea

Mediante este tipo de llave podemos relacionar tablas, es decir, una llave foránea o Foreign Key la cual se representa a través de “FK”, es una referencia a una clave de otra tabla, las claves foráneas no requieren ser datos únicos en la tabla donde se localizan, pero si lo deben ser en la tabla de referencia.

Llave índice

Los índices los veremos adelante, por lo pronto quédate con la idea de que nosotros podemos seleccionar cualquier atributo como índice y nos servirá para realizar búsquedas más rápidas dentro de nuestra tabla.

¿Qué sigue? Bien, en este post, hemos aprendido varios conceptos importantes y las bases que establece el modelo relacional, ahora, toca revisar uno de los temas que matemáticamente hará que nos vuele la cabeza, pero yo te lo tratare de hacértelo a meno, en el siguiente post trataré de explicarte todo lo relacionado con el álgebra relaciona.