Claves, integridad y restricciones
Mapa conceptual
- Bases de Datos
- Modelo E-R
- Entidades
- Relaciones
- Cardinalidad
- Normalización
- 1FN
- 2FN
- 3FN
- SQL
- SELECT
- JOIN
- GROUP BY
- Transacciones
- ACID
- Bloqueos
- Índices
- B-tree
- Hash
- Modelo E-R
Integridad de entidad
Toda tabla necesita una clave primaria: única y no nula, que distinga cada fila. Es la integridad de entidad: garantiza que cada hecho del mundo real aparezca una sola vez. Sin clave primaria, no puedes referirte con seguridad a un registro ni actualizarlo sin riesgo de ambigüedad.
Integridad referencial
Una clave foránea obliga a que un valor apunte a una clave primaria existente, o sea nulo. Es el pacto de que «no me refiero a algo que no existe»: no puede haber un pedido de un cliente inexistente. Su violación produce los temidos datos huérfanos.
Qué pasa al borrar o cambiar
- RESTRICT impide borrar o modificar un padre todavía referenciado.
- CASCADE propaga el cambio: al borrar el cliente se borran sus pedidos.
- SET NULL deja la foránea a nulo, conservando el hijo huérfano pero válido.
- La elección depende del significado del dato, no de la comodidad.
Unicidad
UNIQUE impone que una columna o conjunto de columnas no se repita, sin necesidad de ser la clave primaria. El correo del usuario, el número de serie, un par (alumno, asignatura) sin duplicados. Permite valores nulos, a diferencia de la primaria.
Not null
NOT NULL exige que un campo siempre tenga valor. Obligar a rellenar el nombre o el precio evita huecos que romperían cálculos después. Una columna que admite nulos debe declararse a conciencia, sabiendo que cada nulo es una decisión de negocio pendiente.
Check
CHECK declara una condición que cada fila debe cumplir: precio mayor o igual que cero, edad entre cero y ciento veinte, estado dentro de un conjunto. A diferencia del filtro de una consulta, actúa en la escritura y rechaza el insert o update que la viola.
Dominio y tipo de dato
Elegir bien el tipo es la primera restricción: un entero no guarda texto, una fecha con zona horaria no es un texto, un decimal no es un flotante para dinero. El tipo de dato acota el dominio antes que cualquier regla explícita.
Defensa en profundidad
Puede tentarse validar solo en la aplicación, pero ahí quedan fuera las cargas directas, los scripts de mantenimiento y los errores del propio código. La restricción en base es la última línea de defensa: la única que no se puede saltar olvidando una comprobación.
Declarar la regla donde vive
- Pon en la base lo que siempre debe cumplirse: identidad, referencias, coherencia.
- Pon en la aplicación lo que depende de contexto o puede cambiar.
- Documenta las reglas de negocio complejas que ninguna de las dos capas impone sola.
Coste de la integridad
Verificar restricciones cuesta en cada escritura: buscar si la foránea existe, si el valor es único. En cargas masivas de carga, a veces se desactivan temporalmente los índices asociados, pero se revalida al final. Nunca se sacrifica integridad sin un plan de comprobación.
Errores frecuentes
- Crear la foránea sin índice asociado, penalizando los JOIN y las comprobaciones.
- Fiarse solo de la validación de la aplicación y permitir datos huérfanos.
- Usar clave natural mutable como primaria y romper foráneas al cambiar un dato.
Una clave primaria admite valores nulos siempre que sean únicos.
Nulos y restricciones
El nulo dialoga de forma distinta con cada regla: la primaria lo prohíbe, UNIQUE lo permite (a veces varias veces, según el motor), una foránea nula significa «sin referencia» y no viola integridad referencial. Modelar a conciencia qué significa nulo en cada columna evita interpretaciones dudosas.
Reglas entre tablas
Restricciones que cruzan tablas («el total de la línea iguala la suma de sus detalles») no caben en un CHECK simple de una fila: se implementan con disparadores o se validan por aplicación. Conocer el límite de las restricciones declarativas evita prometer lo que el esquema no puede cumplir.
Auditar y confiar
Aun con integridad, conviene registrar quién y cuándo cambió qué: no sustituye la restricción, pero permite reconstruir la historia cuando algo se corrompe por una regla mal modelada. Defensa y trazabilidad van juntas.
Tipos de restricción
Toca una tarjeta para ver la respuesta.
Asigna cada regla a la restricción que la garantiza:
Arrastra cada ficha a su categoría (o tócala y luego toca la categoría). También puedes usar el teclado.
PostgreSQLDocumentación de restricciones de integridad en un motor real.
Diseña las restricciones de una tabla Pedidos con cliente id, importe y estado. ¿Qué va como foránea, qué como CHECK, qué como NOT NULL y qué decisión tomas al borrar un cliente?
Tu texto se guarda sólo en este dispositivo.
Documentación PostgreSQLReferencia oficial de SQL y bases de datos.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.