Índice de contenidos

Esta unidad te va a convertir en un experto en bases de datos relacionales. Vas a aprender desde los conceptos más básicos hasta crear tu propia base de datos funcional usando MariaDB.

El temario cubre todo lo esencial: empezarás entendiendo qué son los modelos de datos y cómo se diseñan las bases de datos paso a paso. Después dominarás el modelo relacional de Codd, que es la base de casi todas las aplicaciones modernas.

La parte práctica incluye SQL (el lenguaje universal de las bases de datos) y MariaDB como sistema gestor. También aprenderás los lenguajes DDL para crear estructuras y DCL para gestionar permisos y usuarios.

Dato curioso: Las bases de datos relacionales fueron inventadas en 1970 por Edgar Codd en IBM, ¡y siguen siendo el estándar hoy en día!

Al final de esta unidad serás capaz de diseñar, crear y administrar bases de datos profesionales que podrían funcionar en aplicaciones reales.

Modelos de datos: Concepto y tipos

Los modelos de datos son como los planos de un arquitecto, pero para organizar información. Te permiten describir cómo se estructuran los datos, qué reglas deben cumplir y cómo se pueden manipular.

Piensa en ellos como lenguajes especializados que describen tres cosas fundamentales: las estructuras de datos (qué tipos de información guardas), las restricciones de integridad (qué reglas deben cumplir) y las operaciones que puedes hacer con ellos.

Existen tres niveles según lo alejados que estén del mundo real. Los modelos conceptuales $como Entidad-Relación$ se usan para entender el problema sin pensar en tecnología. Los modelos lógicos (como el Relacional) definen cómo implementar el sistema. Los modelos físicos son las estructuras técnicas de bajo nivel dentro del sistema.

El proceso de diseño tiene cinco fases claras: recoger requisitos, diseño conceptual, diseño lógico, diseño físico e implementación. Cada fase tiene su propósito y todas son necesarias para crear una base de datos que funcione correctamente y sea eficiente.

Consejo práctico: Nunca te saltes la fase de análisis de requisitos. Es mejor invertir tiempo al principio que tener que rediseñar todo después.

El proceso completo de diseño

El diseño conceptual se centra únicamente en entender el problema sin preocuparse por la tecnología. Aquí usas herramientas como diagramas ER o UML para representar gráficamente qué información necesitas guardar y cómo se relaciona.

En el diseño lógico ya eliges el tipo de base de datos (relacional, orientada a objetos, etc.) y transformas tu modelo conceptual. Si eliges relacional, obtienes tablas con sus claves primarias y foráneas. Si eliges orientada a objetos, defines clases y herencias.

El diseño físico es donde eliges el SGBD específico (MySQL, PostgreSQL, etc.) y optimizas el rendimiento. Aquí defines aspectos técnicos como índices, particiones y estructuras de almacenamiento físico.

Los objetivos clave del diseño físico son optimizar el tiempo de respuesta, minimizar el uso del espacio, maximizar la carga de transacciones y garantizar la disponibilidad del sistema. Todo esto depende del SGBD concreto que elijas.

Realidad profesional: En empresas como bancos o aerolíneas, la disponibilidad debe ser 24/7 porque cada minuto de caída cuesta miles de euros.

La implementación incluye la carga de datos, optimización del rendimiento y configuración de usuarios y permisos de seguridad.

Modelo relacional: Los objetivos de Codd

Edgar Codd revolucionó el mundo de las bases de datos en 1970 con el modelo relacional. Su nombre viene de la relación matemática entre conjuntos, donde trabajas con el producto cartesiano de los mismos.

Los objetivos de Codd eran ambiciosos pero necesarios. La independencia física significa que puedes cambiar cómo se almacenan los datos sin afectar a las aplicaciones. La independencia lógica permite modificar la estructura sin romper los programas que la usan.

La flexibilidad te da diferentes vistas de los mismos datos según el usuario. La uniformidad simplifica todo porque solo manejas un tipo de estructura: tablas. La sencillez hace que sea más fácil de usar que los sistemas anteriores.

Codd también definió 12 reglas que debe cumplir cualquier sistema para ser verdaderamente relacional. Aunque pocos sistemas las cumplen al 100%, las mejores bases de datos se acercan bastante y estas reglas siguen siendo el estándar de referencia.

Dato técnico: Muy pocos SGBD cumplen todas las reglas de Codd, pero los mejores como PostgreSQL u Oracle se acercan mucho.

Estas reglas abarcan desde cómo se almacena la información hasta cómo se manejan los valores nulos y la distribución de datos.

Las 12 reglas fundamentales

Las reglas de Codd son como un examen de calidad para bases de datos. La regla de información dice que todos los datos deben estar en tablas, sin excepciones. El acceso garantizado asegura que puedes llegar a cualquier dato conociendo su clave y columna.

El tratamiento de valores NULL es crucial porque estos valores especiales deben manejarse correctamente en todas las operaciones. El catálogo en línea significa que hasta los metadatos se guardan en tablas relacionales.

La regla del sublenguaje completo exige que exista al menos un lenguaje (como SQL) que permita hacer cualquier operación. La actualización de vistas garantiza que siempre veas información actualizada, nunca obsoleta.

Las operaciones de alto nivel trabajan con conjuntos de filas, no registro por registro. Esto hace que los lenguajes como SQL sean de cuarta generación, mucho más potentes que programar con bucles tradicionales.

Ejemplo práctico: Un SELECT en SQL puede procesar millones de registros en una sola instrucción, algo que en C++ requeriría cientos de líneas de código.

Las reglas de independencia (física, lógica, integridad y distribución) aseguran que tu sistema sea robusto y flexible ante cambios futuros.

Relaciones, atributos y tuplas

Una relación es simplemente una tabla con filas y columnas, pero con reglas muy específicas. Los atributos son las columnas (como DNI, nombre, apellidos) y las tuplas son las filas con datos concretos de una persona.

Cada atributo tiene un dominio, que es el conjunto de valores válidos que puede tomar. Por ejemplo, el atributo "sexo" podría tener dominio {'M', 'F'} y "edad" podría ser números enteros entre 0 y 120.

El grado de una relación es su número de columnas (atributos). La cardinalidad es su número de filas (tuplas). Estos conceptos son fundamentales para entender el tamaño y complejidad de tus tablas.

Las relaciones tienen propiedades estrictas: no puede haber tuplas duplicadas, el orden no importa (ni de filas ni columnas), cada atributo toma un solo valor por tupla y todos los datos de una columna deben ser del mismo dominio.

Regla de oro: Los dominios deben ser atómicos, es decir, no se pueden dividir en partes más simples.

Existen diferentes tipos de relaciones: base (las tablas reales), vistas (consultas almacenadas) e instantáneas (fotografías de datos en un momento específico).

Valores NULL y sinónimos

El valor NULL es especial y representa "ausencia de dato". No es lo mismo que cero, que espacio en blanco o que cadena vacía. Es literalmente "no hay información" y requiere una lógica especial.

Cuando operas con NULL, los resultados cambian. VERDADERO AND NULL da NULL, pero FALSO AND NULL da FALSO. VERDADERO OR NULL da VERDADERO, pero FALSO OR NULL da NULL. Para comprobar si algo es nulo usas IS NULL.

La terminología puede ser confuente porque se usan sinónimos. Relación = tabla = fichero. Tupla = fila = registro. Atributo = columna = campo. Es el mismo concepto con diferentes nombres según el contexto.

Las relaciones válidas deben cumplir reglas estrictas: nombres únicos para tablas y atributos, un solo valor por celda, no duplicar filas completas, y que el orden no importe.

Error común: Muchos principiantes confunden NULL con cadena vacía ("") o con cero (0). ¡Son valores completamente diferentes!

Se clasifican en persistentes (base, vistas, instantáneas) que solo los usuarios pueden borrar, y temporales que el sistema elimina automáticamente.

Sistema de claves

Las claves son tu método para identificar únicamente cada fila en una tabla. Una superclave es cualquier conjunto de atributos que identifica tuplas, pero las claves candidatas son las superclaves mínimas.

De todas las claves candidatas, eliges una como clave primaria. Las que no eliges se llaman claves alternativas. La clave primaria puede ser simple (un campo) o compuesta (varios campos juntos).

Los requisitos son claros: unicidad (no puede haber dos filas con los mismos valores) e irreductibilidad (si quitas algún atributo, deja de ser única). Esto garantiza identificación perfecta.

Las claves foráneas conectan tablas entre sí. Son atributos que referencian la clave primaria de otra tabla, estableciendo relaciones entre los datos.

Truco profesional: Si no tienes una clave natural obvia, crea un ID autonumérico. Es simple, eficiente y nunca falla.

Las claves foráneas pueden repetirse y ser NULL, pero si tienen valor, debe existir en la tabla que referencian. Esto mantiene la integridad referencial.

Claves foráneas y relaciones

Las claves foráneas son el pegamento que une las tablas. Si tienes USUARIO y PARTIDA, la clave primaria de USUARIO (como login) aparecerá en PARTIDA como clave foránea para indicar quién juega cada partida.

A diferencia de las claves primarias, las foráneas sí pueden repetirse (un usuario puede jugar varias partidas) y pueden ser NULL (una partida sin jugador asignado). Pero si tienen valor, ese valor debe existir en la tabla referenciada.

Esta restricción se llama integridad referencial y evita datos inconsistentes. No puedes tener una partida de un jugador que no existe en la base de datos, pero sí puedes tener una partida sin jugador asignado.

El sistema es flexible pero estricto: puedes registrar usuarios sin partidas, partidas sin jugador específico, pero nunca partidas de jugadores inexistentes.

Ejemplo real: En una tienda online, no puedes tener un pedido de un cliente que no existe en la tabla CLIENTES.

Las claves foráneas representan relaciones entre datos y son fundamentales para evitar redundancia y mantener consistencia en la información.

Representación de esquemas relacionales

La forma clásica usa la notación TABLA(columna1, columna2, ...) donde las claves primarias van subrayadas y las alternativas con línea discontinua. Es simple pero no muestra bien las relaciones entre tablas.

Los grafos relacionales añaden líneas que conectan claves primarias con foráneas, facilitando visualizar cómo se relacionan las tablas. Es como un mapa de conexiones de tu base de datos.

Los esquemas derivados del modelo entidad-relación intentan combinar lo mejor de ambos mundos. La notación de patas de gallo es muy popular en herramientas CASE profesionales y metodologías como la de Oracle.

También existe la notación estilo Access que Microsoft popularizó y que muchos desarrolladores conocen por su simplicidad visual.

Consejo profesional: Aprende varias notaciones porque cada empresa y herramienta puede usar una diferente.

Cada notación tiene sus ventajas: la clásica es concisa, los grafos muestran relaciones claramente, y las derivadas de ER son más expresivas para modelar restricciones complejas.