Modelo relacional de bases de datos: claves y ejemplo

El modelo relacional de bases de datos organiza información mediante relaciones formadas por atributos y tuplas, con reglas que determinan qué estados de los datos son válidos. En una implementación habitual, esas relaciones se representan mediante tablas. Comprender el modelo exige examinar identidad, dominios y restricciones, además de dibujar filas y columnas.

Un ejemplo de estudiantes, cursos e inscripciones permitirá distinguir claves primarias y foráneas, representar una relación de muchos a muchos y explicar qué hace una consulta de unión. El objetivo es entender el significado de los datos y sus reglas. La normalización constituye un análisis posterior y específico, no una definición alternativa del modelo.

Relación, atributo, tupla y dominio

Una relación puede entenderse como un conjunto de tuplas que comparten una estructura. Cada atributo tiene un nombre y un dominio de valores permitidos. Por ejemplo, un identificador de estudiante pertenece a un dominio diferente del de una calificación. Que ambos puedan almacenarse como números no les da el mismo significado.

Una tupla reúne valores correspondientes a los atributos. En Estudiante, la tupla (E1, Ana) puede asociar la matrícula E1 con el nombre Ana. Los nombres de los atributos permiten interpretar los valores; mover una fila en pantalla no cambia el hecho representado. La posición visual no debe funcionar como identificador.

Conviene distinguir esquema e instancia. El esquema describe atributos, dominios y restricciones; la instancia es el conjunto de tuplas presente en un momento. Agregar a Luis cambia los datos, no necesariamente el esquema. Agregar un atributo como fecha_ingreso sí modifica la estructura que debe interpretar la aplicación.

La introducción de PostgreSQL a los conceptos relacionales presenta tablas, filas y columnas, y recuerda que SQL no garantiza el orden de las filas. El modelo permite razonar sobre la información sin prescribir el orden físico de almacenamiento ni una presentación única en pantalla.

Un modelo de inscripciones con reglas explícitas

En el ejemplo hipotético, cada estudiante posee una matrícula única. Cada curso tiene un código único y puede aparecer en varios periodos. Un estudiante puede inscribirse en varios cursos, y un curso puede recibir varios estudiantes. Se permite como máximo una inscripción por estudiante, curso y periodo; no se distinguen grupos dentro de esa combinación.

Los estudiantes son (E1, Ana), (E2, Luis) y (E3, Maya). Los cursos son (C1, Estadística, 3) y (C2, Programación, 4). Para el periodo 2026B se registran cuatro inscripciones: E1–C1, E1–C2, E2–C1 y E3–C2. Esta lista contiene relaciones entre estudiantes y cursos, no copias completas de ambas entidades en cada inscripción.

Ana cursa dos materias; Estadística tiene dos estudiantes. La tabla intermedia expresa así la relación de muchos a muchos. Desde Estudiante hacia Inscripcion hay una relación de uno a muchos, y lo mismo ocurre desde Curso hacia Inscripcion. Las cardinalidades describen reglas posibles, no solo el número de filas que hoy contiene el ejemplo.

La regla de grupos es decisiva. Si un estudiante pudiera tener dos inscripciones del mismo curso y periodo en grupos distintos, la combinación elegida dejaría de identificar cada inscripción. Haría falta representar la oferta o el grupo y revisar la clave. El modelo debe derivarse del dominio, no de una plantilla que parezca funcionar con pocos registros.

Claves candidatas, primaria y foráneas

Una superclave identifica de manera única cada tupla. Una clave candidata es una superclave mínima: no contiene atributos prescindibles para esa identificación. Si matrícula ya es única, matrícula más nombre también identifica, pero no es mínima. “Mínima” no significa necesariamente la clave con menos caracteres ni con el menor número de columnas entre todas las candidatas.

La clave primaria es una candidata seleccionada como identificación principal. Puede ser simple o compuesta. En Inscripcion, matrícula, código y periodo forman una clave compuesta bajo las reglas fijadas. Quitar periodo impediría que una persona volviera a cursar la misma materia en otro periodo; quitar matrícula confundiría a estudiantes distintos.

Una clave foránea establece una referencia a una clave apropiada de otra relación, o de la misma en modelos autorreferentes. En el ejemplo, Inscripcion.matricula referencia Estudiante.matricula e Inscripcion.codigo referencia Curso.codigo. El nombre de la columna por sí solo no crea esa garantía: debe existir la restricción correspondiente en la implementación.

No toda columna llamada id constituye automáticamente una clave válida del negocio. Añadir un identificador artificial a Inscripcion puede facilitar referencias, pero no impide dos registros con la misma matrícula, curso y periodo. La regla de unicidad de esa combinación sigue siendo necesaria si el dominio prohíbe duplicados.

Integridad: definir qué datos pueden existir

Las restricciones de dominio delimitan valores admisibles: una calificación puede pertenecer a una escala de 0 a 10; los créditos pueden ser enteros positivos. Las reglas de entidad e identificación impiden claves primarias nulas o duplicadas. La integridad referencial impide referencias obligatorias a estudiantes o cursos inexistentes.

La documentación de restricciones de PostgreSQL describe PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL y CHECK. Son mecanismos de implementación que deben corresponder a reglas concretas. Un tipo numérico no impide por sí mismo almacenar una calificación fuera del intervalo permitido.

En nuestro modelo, la calificación puede estar pendiente. Si se representa con NULL en SQL, no debe confundirse con cero: cero es un valor de la escala, mientras que NULL marca ausencia de un valor ordinario. Además, un CHECK de intervalo no sustituye NOT NULL cuando el dato deba ser obligatorio.

Eliminar un estudiante que tiene inscripciones exige una política explícita: impedir la eliminación, conservarlo como registro inactivo u otra operación compatible con los requisitos. Una eliminación en cascada puede borrar registros relacionados. La política debe elegirse por su significado y necesidades de conservación, no solo para evitar un mensaje de error.

Selección, proyección y unión con el mismo ejemplo

La selección filtra tuplas según una condición. Seleccionar las inscripciones cuyo código sea C1 deja E1–C1–2026B y E2–C1–2026B. La proyección conserva ciertos atributos: si se proyectan sus matrículas, se obtienen E1 y E2. Estas operaciones permiten expresar una pregunta sin detallar manualmente cómo recorrer archivos físicos.

Una unión o JOIN combina tuplas que cumplen una condición. Para obtener los nombres de quienes cursan Estadística, se unen Inscripcion y Estudiante por igualdad de matrícula y se filtra código = C1. El resultado del ejemplo contiene Ana y Luis. El tutorial de PostgreSQL sobre uniones explica cómo se emparejan filas mediante una condición.

Si se omite la condición de emparejamiento, se puede producir un producto cartesiano. Tres estudiantes combinados libremente con cuatro inscripciones generan 3 × 4 = 12 pares, muchos sin significado en el dominio. Una consulta ejecutable no es necesariamente una consulta correcta: debe preservar la relación que se pretendía representar.

SQL y el modelo matemático no son idénticos

En el modelo de conjuntos, una tupla no aparece repetida dentro de una relación. SQL puede conservar filas duplicadas en tablas o resultados si las restricciones y operaciones no las eliminan. SELECT DISTINCT solicita eliminar duplicados del resultado; la documentación sobre listas de selección presenta esta distinción.

Proyectar solo nombres podría combinar personas diferentes que se llaman igual. Por eso, eliminar duplicados no reemplaza identificar estudiantes con su matrícula. También debe pedirse un orden mediante ORDER BY si la presentación lo requiere. La identidad, el contenido del resultado y su orden son decisiones distintas.

La normalización de bases de datos profundiza en dependencias y anomalías de diseño. Aquí basta distinguir su propósito: revisar cómo se organizan relaciones a partir de reglas del dominio. Tener varias tablas o declarar claves no demuestra por sí mismo que un esquema satisfaga determinada forma normal.

¿Qué cambia frente a una base no relacional?

Una base de datos no relacional puede organizar información mediante documentos, claves y valores u otros modelos. La elección debe comparar consultas, restricciones y necesidades de operación. No implica que una categoría tenga siempre esquema y la otra carezca de él, ni que una sea universalmente más rápida.

¿Una hoja con filas y columnas ya es una base relacional?

La apariencia tabular no basta para sostener todas las reglas del modelo. Examine atributos, dominios, identidad, referencias y operaciones. Un diseño útil permite explicar qué representa cada tupla, qué combinaciones son válidas y cómo obtener una respuesta sin depender de la posición visual de los datos.