Las bases de datos se apoyan en conjuntos, relaciones, funciones, grafos y lógica. Estos conceptos permiten organizar información, imponer integridad, consultar datos sin ambigüedades y diseñar esquemas mantenibles.
Una base de datos no es solamente un conjunto de tablas. Es un sistema que representa entidades, atributos y relaciones, y que aplica reglas para mantener los datos coherentes a medida que se insertan, actualizan y consultan.
La matemática discreta aporta el lenguaje para expresar esas reglas: una tabla se relaciona con un conjunto de tuplas, una clave con una función de identificación, una consulta con operaciones de conjuntos y una referencia con una arista entre entidades.
En el modelo relacional, una relación es un conjunto de tuplas con los mismos atributos. Una tabla SQL es una implementación práctica de esta idea, aunque los sistemas SQL suelen admitir particularidades como orden de presentación, duplicados y valores nulos.
Matemáticamente, una relación de n atributos puede verse como un subconjunto de un producto cartesiano de dominios. Cada fila válida elige un valor de cada dominio.
El esquema define la estructura de una relación: nombre, atributos, tipos y restricciones. Una tupla es una instancia concreta que respeta ese esquema.
Definir dominios reduce datos inválidos desde el origen. Una fecha, un identificador, un código de país y un porcentaje requieren restricciones distintas aunque se almacenen con tipos similares.
Una clave candidata es un conjunto mínimo de atributos que identifica de manera única una tupla. Una clave primaria es la clave candidata elegida para identificar las filas de una relación.
La unicidad es una propiedad lógica, no una suposición sobre los datos actuales. Debe imponerse con una restricción para que el sistema no permita duplicados futuros.
Una clave foránea referencia una clave de otra relación. Implementa una relación entre entidades y protege la integridad referencial.
Esta conexión puede verse como una arista dirigida desde Pedido hacia Cliente. La base de datos puede impedir referencias inexistentes y definir qué hacer si se elimina una entidad referenciada.
Las relaciones entre entidades tienen cardinalidades que expresan cuántas instancias pueden asociarse. Las más frecuentes son uno a uno, uno a muchos y muchos a muchos.
La tabla intermedia no es un detalle accidental: representa la relación como una entidad con atributos propios, como fecha de inscripción, estado o calificación.
El álgebra relacional define operaciones sobre relaciones. Una consulta compone estas operaciones para producir otra relación como resultado.
Estas operaciones conectan consultas de bases de datos con conjuntos, lógica booleana y productos cartesianos estudiados en el curso.
La selección conserva las tuplas que cumplen una condición; la proyección conserva solo determinados atributos. Son análogas a filtrar y transformar colecciones en programación.
En SQL, estas ideas suelen expresarse con WHERE y SELECT. El orden conceptual ayuda a entender qué datos deben filtrarse antes de elegir sus columnas de salida.
Las operaciones de conjuntos aparecen al combinar resultados compatibles. Dos relaciones deben tener atributos compatibles para unirlas o compararlas directamente.
El modelo relacional clásico trabaja con conjuntos, mientras que SQL suele usar semántica de multiconjuntos por defecto. Esa diferencia explica por qué DISTINCT y las variantes ALL importan en consultas reales.
Un join combina tuplas de dos relaciones según una condición. Conceptualmente parte de un producto cartesiano y conserva solo las combinaciones que satisfacen la relación de unión.
El join es una de las operaciones más importantes y más costosas de una base de datos. Las claves, índices y condiciones correctas ayudan al optimizador a ejecutarlo eficientemente.
SELECT c.nombre, p.id AS pedido_id, p.fecha
FROM Cliente AS c
JOIN Pedido AS p
ON p.cliente_id = c.id
WHERE p.fecha >= DATE '2026-01-01';La consulta combina clientes con sus pedidos, filtra por fecha y proyecta los campos solicitados. La sintaxis exacta de literales de fecha puede variar entre motores, pero la estructura lógica es la misma.
Una dependencia funcional X → Y indica que, dentro de una relación, dos tuplas con el mismo valor de X deben tener el mismo valor de Y. X determina funcionalmente Y.
Las dependencias funcionales describen reglas del dominio y sirven para analizar redundancia. No se derivan solo de una muestra de datos: deben ser verdaderas para cualquier instancia válida.
Guardar datos de entidades distintas en una misma relación redundante provoca anomalías: modificaciones repetidas, imposibilidad de insertar un dato aislado o pérdida accidental de información al borrar una fila.
La normalización busca separar las relaciones de modo que cada hecho se almacene una vez en el lugar apropiado y pueda recombinarse mediante joins.
La normalización organiza relaciones según dependencias funcionales para reducir redundancia y preservar integridad. Las formas normales son criterios progresivos, no una receta que sustituya el análisis del dominio.
Un diseño puede desnormalizarse de manera consciente por rendimiento, pero esa decisión debe documentar qué redundancia se introduce y cómo se mantiene coherente.
Las restricciones convierten reglas de negocio en condiciones verificadas por la base de datos. Complementan la validación de la aplicación porque protegen los datos sin depender de un único cliente.
Las restricciones no reemplazan toda la lógica de negocio, pero son la última línea de defensa para invariantes que deben mantenerse sin importar qué servicio escribe los datos.
SQL suele usar NULL para representar información desconocida, ausente o no aplicable, según el modelo. Las comparaciones con NULL producen un valor lógico desconocido, no verdadero ni falso.
NULL no es una cadena vacía ni el número cero. Debe usarse con una semántica clara; de lo contrario complica restricciones, joins, agregaciones y filtros.
Un índice es una estructura auxiliar que acelera ciertas búsquedas. Muchos motores implementan índices con variantes de árboles balanceados, como B-trees, que permiten buscar, insertar y recorrer rangos eficientemente.
La teoría de árboles conecta directamente con esta implementación. Un índice útil depende de las condiciones, joins y ordenamientos que ejecuta realmente la aplicación.
Las relaciones de jerarquía o dependencia forman grafos y pueden consultarse de forma recursiva. Ejemplos comunes son organigramas, categorías, rutas y prerequisitos.
Algunos motores ofrecen expresiones de tabla comunes recursivas. El modelo de grafo ayuda a definir límites de profundidad y manejar referencias circulares de forma segura.
Una base relacional es adecuada para muchos sistemas transaccionales y consultas bien estructuradas. Una base de grafos puede resultar atractiva cuando las consultas frecuentes recorren relaciones de varios saltos.
No existe una elección universal. Es frecuente combinar tecnologías, siempre que se definan fuentes de verdad, sincronización e invariantes entre sistemas.
Los valores de una consulta deben enviarse como parámetros, no concatenarse como texto SQL. Separar estructura y datos evita que una entrada se interprete como parte de la consulta.
Los detalles de API dependen del lenguaje y motor de base de datos. La regla general es que la consulta fija su sintaxis y los parámetros transportan únicamente valores.
Un esquema es una hipótesis sobre el dominio. Debe evolucionar con migraciones controladas y conservar la coherencia de los datos existentes.
Las bases de datos aplican matemática discreta para convertir hechos del dominio en información coherente y consultable. En el próximo tema veremos cómo estos conceptos también fundamentan técnicas de inteligencia artificial.