Usted añade una clave foránea de fact_sales.customer_id a dim_customer en su almacén de datos. El DDL se ejecuta, la carga nocturna se ejecuta y a la mañana siguiente un lote de nuevas filas de ventas apunta a clientes que no existen. Nada falló, porque nada lo comprobó. En Snowflake, BigQuery, Amazon Redshift y Databricks, una clave foránea no se aplica: la plataforma guarda la declaración como metadatos, pero acepta filas cuya clave no tiene coincidencia en la tabla padre.

Lo mismo ocurre con las claves primarias y las restricciones de unicidad. Eso sorprende a quienes se formaron con PostgreSQL, Oracle o SQL Server, donde una clave foránea declarada rechaza la fila errónea al insertarla. En un almacén de datos en la nube, la declaración es una promesa que usted hace, no una regla que la base de datos cumple por usted. Algunos planificadores de consultas incluso se creen la promesa y la usan para simplificar joins.

Este artículo enumera qué aplica cada plataforma, con enlaces a la documentación de cada proveedor, explica por qué los almacenes de datos aceptan este compromiso, muestra cómo una clave violada puede convertirse en una cifra errónea y describe qué ejecutar en su lugar. Para la idea general de filas padre e hijas y qué es un registro huérfano, empiece por el artículo principal ¿Pueden sus datos seguir encontrando a sus padres? Entender la integridad referencial.

Puntos clave

• Snowflake (tablas estándar), BigQuery, Redshift y Databricks aceptan declaraciones de claves primarias, foráneas y únicas, pero no las aplican. Las tablas híbridas de Snowflake son la excepción.

• NOT NULL se aplica en Snowflake, Redshift y Databricks; Databricks también aplica las restricciones CHECK.

• Redshift y BigQuery usan las claves declaradas al planificar consultas. Si las claves son incorrectas, algunas consultas pueden devolver resultados incorrectos sin ningún error.

• Declare claves solo cuando los datos se hayan validado, y vuelva a validarlos después de cada carga con una comprobación de integridad referencial.

• Mantenga NOT NULL como una regla independiente y vigile las referencias que cruzan sistemas, donde no puede existir ninguna restricción.

Índice de contenidos

• ¿Qué significa "clave foránea no aplicada"?

• ¿Qué almacenes de datos aplican claves primarias y foráneas?

• ¿Por qué los almacenes de datos no aplican las claves foráneas?

• ¿Cómo puede una clave no aplicada devolver resultados de consulta erróneos?

• ¿Cómo se protege la integridad referencial en un almacén de datos?

  • La comprobación anti-join en SQL

• ¿Cómo es una comprobación de integridad referencial en digna?

• Próximos pasos

¿Qué significa "clave foránea no aplicada"?

Una clave foránea no aplicada es una declaración que la base de datos registra pero nunca comprueba. Puede escribir FOREIGN KEY (customer_id) REFERENCES dim_customer (customer_id), y la plataforma la guardará, la mostrará en el catálogo y la expondrá a las herramientas, pero seguirá cargando una fila cuyo customer_id no tiene padre.

Los proveedores las llaman restricciones informativas. Describen la forma prevista de los datos: qué columna identifica una fila, qué columna apunta a qué tabla. Las herramientas de BI, los catálogos de datos y las herramientas de modelado las leen para dibujar diagramas y sugerir joins. Algunos optimizadores de consultas también las leen. Lo que no hacen es detener una carga, generar un error o señalar un huérfano.

Así que, en un almacén de datos, "la clave está declarada" y "la clave se cumple" son dos afirmaciones distintas. La primera es un fragmento de DDL. La segunda es un hecho sobre los datos que solo una comprobación puede establecer, y que puede cambiar con cada carga.

¿Qué almacenes de datos aplican claves primarias y foráneas?

Ninguno de los cuatro principales almacenes de datos en la nube aplica claves primarias, foráneas o únicas en sus tablas estándar. Las tablas híbridas de Snowflake son la única excepción de esta lista. NOT NULL se aplica en Snowflake, Redshift y Databricks, y Databricks también aplica las restricciones CHECK. La tabla resume la documentación de cada proveedor; siga los enlaces para consultar la redacción vigente.

En la práctica importan dos detalles. Primero, NOT NULL es la restricción en la que normalmente puede confiar: en Snowflake, Redshift y Databricks se rechaza un nulo en una columna NOT NULL. Segundo, las tablas híbridas de Snowflake son un tipo de tabla distinto con un comportamiento distinto; una clave foránea en una tabla ordinaria de Snowflake no le da nada de esa aplicación.

Las bases de datos OLTP clásicas como PostgreSQL, Oracle, SQL Server y MySQL con InnoDB sí aplican las claves foráneas declaradas. Pero un almacén de datos cargado desde ellas normalmente no hereda esas restricciones, y muchos procesos de carga desactivan las restricciones para ganar velocidad. La integridad que tenía en el sistema de origen no viaja por sí sola con los datos.

¿Por qué los almacenes de datos no aplican las claves foráneas?

Aplicar una clave foránea significa buscar cada clave entrante en la tabla padre antes de aceptar la fila. Los almacenes de datos están diseñados para cargar lotes muy grandes de forma rápida y en paralelo, y esa búsqueda fila a fila va en contra de ambas cosas. La documentación de los proveedores describe el comportamiento; los motivos siguientes son el compromiso de ingeniería general, no declaraciones de los proveedores.

• Velocidad de carga. Una carga masiva de millones de filas de hechos necesitaría millones de búsquedas en el padre. Omitirlas mantiene predecibles los tiempos de carga.

• Cargas distribuidas y en paralelo. El almacenamiento y la computación se reparten entre muchos nodos y archivos. Comprobar una clave contra una tabla padre que a su vez se está cargando en paralelo requiere coordinación, lo que lo ralentiza todo.

• Orden de carga. Los pipelines a menudo cargan los hechos antes que las dimensiones, o reciben filas de dimensión que llegan tarde. Una aplicación estricta rechazaría filas que habrían sido válidas una hora después.

• Pipelines basados en anexar datos. La mayoría de las tablas del almacén de datos reciben filas nuevas, no se editan fila a fila. El modelo asume que los datos se prepararon aguas arriba, así que la base de datos no los vuelve a comprobar.

El compromiso es razonable. El problema es que la comprobación no desaparece; se traslada. Alguien tiene que ejecutarla después de la carga, y en muchos equipos nadie lo hace.

¿Cómo puede una clave no aplicada devolver resultados de consulta erróneos?

Una clave no aplicada se vuelve peligrosa cuando el planificador de consultas confía en ella. Amazon Redshift documenta que su planificador asume que las claves son válidas tal como se cargan, y que si su aplicación permite claves foráneas o primarias no válidas, algunas consultas podrían devolver resultados incorrectos. Una clave declarada pero violada es peor que no tener clave.

BigQuery usa las claves primarias y foráneas declaradas para eliminar inner y outer joins y para reordenar joins, y su documentación le traslada la responsabilidad a usted: "You are responsible for maintaining the constraints at all times."

Este es el mecanismo en términos generales. Tome una consulta que une fact_sales con dim_customer pero solo selecciona columnas de fact_sales. Si el planificador confía en la clave foránea, puede decidir que el join no puede eliminar ninguna fila y omitirlo. Ejecute la misma consulta sin la clave declarada y el inner join descarta todas las ventas huérfanas. Ahora el mismo informe da dos totales distintos según el plan, y ninguna de las ejecuciones genera un error.

Las claves primarias duplicadas causan un problema relacionado: un join que todo el mundo supone que devuelve una fila por clave devuelve varias, y los totales se duplican. En ambos casos el panel parece normal. La cifra simplemente es incorrecta, y usted se entera por una conciliación semanas después, si es que se entera.

¿Cómo se protege la integridad referencial en un almacén de datos?

La integridad referencial en un almacén de datos se protege tratando las claves declaradas como afirmaciones y comprobándolas después de cada carga. Declare una clave solo cuando los datos se hayan validado, ejecute una comprobación de integridad referencial como parte de cada ejecución del pipeline y avise al equipo responsable cuando falle. Estos pasos funcionan en cualquiera de las cuatro plataformas.

1. Enumere las claves que ha declarado. Sepa qué claves foráneas y primarias existen en el catálogo, porque son esas en las que un planificador puede confiar y sobre las que una herramienta de BI puede hacer joins.

2. Declare claves solo cuando estén validadas. Antes de añadir una clave, demuestre que se cumple con los datos actuales. Si no puede seguir comprobándola, piénselo dos veces antes de declararla.

3. Valide después de cada carga. Ejecute una comprobación de integridad referencial para cada par hijo-padre importante como parte del pipeline, no como una auditoría puntual. Una carga que trae huérfanos debería verse el mismo día.

4. Mantenga NOT NULL como una regla aparte. Una comprobación referencial normalmente ignora las claves nulas, porque un nulo no apunta a nada. Si cada fila debe tener un padre, compruebe customer_id IS NOT NULL por separado, o apóyese en la restricción NOT NULL aplicada donde la plataforma la ofrezca.

5. Vigile las referencias entre sistemas. El maestro de productos puede estar en una base de datos y las transacciones en otra. Ninguna clave foránea puede abarcar dos sistemas, así que estas referencias solo pueden protegerse con una comprobación.

6. Fije un umbral y un responsable. Decida si un solo huérfano es un fallo o si una pequeña proporción es tolerable, y envíe el resultado al equipo responsable de los datos.

La comprobación anti-join en SQL

El núcleo de cualquier comprobación de integridad referencial es un anti-join: encontrar las filas hijas cuya clave no tiene coincidencia en la tabla padre.

SELECT s.*
FROM fact_sales s
LEFT JOIN dim_customer c
  ON c.customer_id = s.customer_id
WHERE s.customer_id IS NOT NULL
  AND c.customer_id IS NULL

SELECT s.*
FROM fact_sales s
LEFT JOIN dim_customer c
  ON c.customer_id = s.customer_id
WHERE s.customer_id IS NOT NULL
  AND c.customer_id IS NULL

SELECT s.*
FROM fact_sales s
LEFT JOIN dim_customer c
  ON c.customer_id = s.customer_id
WHERE s.customer_id IS NOT NULL
  AND c.customer_id IS NULL

El filtro IS NOT NULL deja las claves nulas fuera del recuento de huérfanos, en línea con el paso 4. Para claves compuestas, variantes con NOT EXISTS, rendimiento en tablas grandes y cómo mantener los huérfanos fuera en el momento de la carga, consulte registros huérfanos: encuéntrelos con SQL y manténgalos fuera.

Escribir la consulta es la parte fácil. Ejecutarla después de cada carga, para cada clave, guardar los recuentos, avisar a alguien y mantener las filas fallidas disponibles para quien tenga que corregirlas es donde el SQL escrito a mano suele quedarse atrás.

¿Cómo es una comprobación de integridad referencial en digna?

En digna, una comprobación de integridad referencial es una regla de digna Data Validation: usted elige la columna de una fuente de datos, elige la columna correspondiente de otra y fija un umbral. No hay que escribir SQL. digna genera la comprobación y la ejecuta dentro de su almacén de datos con cada inspección de esa fuente de datos.

La configuración son unos pocos campos en el diálogo Add Data Validation Rule (Configuration → fuente de datos → Data Validation → Add Rule):

• Name y Description (nombre y descripción), por ejemplo hc_product_in_master: "Every administered product exists in the pharmacy product master".

• Type: Referential Integrity (los otros tipos son Rule y Uniqueness).

• Attributes: la columna de esta fuente de datos, aquí product_code.

• must exist in: la Data Source padre (hospital_medications) y sus Attributes (product_code). Para una clave compuesta, elija varias columnas en ambos lados en el mismo orden; las listas de columnas que no coinciden se rechazan.

• Threshold Mode (modo de umbral) Absolute o Relative, con un Info threshold y un Warn threshold. Absolute, Info 0, Warn 1 significa que un solo huérfano ya genera un estado Uncertain y dos o más hacen fallar la regla; deje Warn en 0 si un único huérfano debe provocar el fallo.

La regla de integridad referencial en digna: cada product_code de la fuente de datos de administraciones debe existir en hospital_medications.

El ejemplo usa datos de demostración ficticios de Danubia Kliniken, un grupo hospitalario austriaco ficticio.

El 2026-04-22 se registraron en las unidades 82 administraciones de Coavira 2.5 mg (código de producto 3858646) antes de que el producto llegara al maestro de productos de farmacia. La regla informó de que pasaron 4.244 de 4.326 filas y pasó a Failed. En la vista Invalid Records filtra por Failed, elige la comprobación y ve cada fila huérfana con su hospital, unidad y código de producto, lista para exportar para quien corrija los datos maestros. Sin la comprobación, todos los informes que unían dosis con productos habrían mostrado cero dosis de ese producto.

Tres propiedades encajan con los pasos anteriores. La comprobación se ejecuta dentro del propio almacén de datos: digna envía SQL, recibe recuentos y recupera las filas fallidas solo cuando usted las solicita; no se copia ninguna tabla fuera, y sus datos nunca salen de su infraestructura. Las claves nulas se omiten, así que la presencia es una Rule aparte, como product_code IS NOT NULL. Y desde Release 2026.01 el padre puede estar en otro esquema o incluso en otra conexión de base de datos dentro del mismo proyecto, lo que cubre las referencias entre sistemas a las que ninguna restricción puede llegar. Para la visión más amplia de cómo reunir fuentes en un almacén de datos, consulte nuestra guía de integración de almacenes de datos; el recorrido completo, campo a campo, de la regla está en cómo configurar una comprobación de integridad referencial.

Próximos pasos

Una clave foránea no aplicada no es un fallo de su almacén de datos. Es una decisión de diseño que le devuelve a usted la comprobación. Siga declarando claves donde ayuden a las herramientas y a los planificadores, pero solo después de demostrar que los datos las cumplen, y vuelva a demostrarlo después de cada carga. Una comprobación de integridad referencial que se ejecuta con cada inspección, dentro del almacén de datos, con un umbral y un responsable, cierra el hueco que la plataforma dejó abierto.

Si quiere verlo funcionando sobre las tablas de su propio almacén de datos, solicite una demo con el equipo de digna.

Preguntas frecuentes

¿Aplica Snowflake las claves foráneas?

No en las tablas estándar. Snowflake documenta allí las claves primarias, foráneas y únicas como opcionales y no aplicadas, mientras que NOT NULL sí se aplica. Las tablas híbridas son la excepción: en ellas se aplican las restricciones PK, FK y UNIQUE. Por eso, las filas huérfanas de una tabla estándar se cargan sin ningún error.

¿Pueden las claves foráneas no aplicadas provocar resultados de consulta erróneos?

Sí, cuando el planificador confía en ellas. Amazon Redshift indica que su planificador asume que las claves son válidas tal como se cargan, así que las claves no válidas pueden hacer que algunas consultas devuelvan resultados incorrectos. BigQuery usa las claves declaradas para eliminar y reordenar joins y dice que mantener las restricciones es responsabilidad suya.

¿Qué son las restricciones informativas en un almacén de datos?

Las restricciones informativas son claves primarias, foráneas o únicas que la plataforma registra como metadatos pero no comprueba. Databricks y Amazon Redshift describen sus restricciones de clave como solo informativas. Las herramientas y los planificadores pueden leerlas, pero las filas que las violan se siguen cargando, así que hace falta una comprobación de validación aparte.

¿Debería seguir declarando claves foráneas en Redshift o BigQuery?

Declárelas solo cuando los datos se hayan validado y siga validándolos. Ambas plataformas usan las claves declaradas en la planificación de consultas, así que una clave declarada pero violada puede cambiar los resultados. Ejecute una comprobación de integridad referencial después de cada carga antes de confiar en la declaración.

¿Cómo se comprueba la integridad referencial cuando el almacén de datos no la aplica?

Ejecute un anti-join después de cada carga: seleccione las filas hijas cuya clave no tiene padre coincidente, excluyendo los nulos. En digna Data Validation es una regla Referential Integrity con un umbral, ejecutada dentro del almacén de datos con cada inspección, y las filas fallidas aparecen en la vista Invalid Records.