Creo que la pregunta es lo suficientemente clara. Algunas de las columnas en mi tabla datawarehouse podrían tener una relación con una clave principal. ¿Pero es una buena práctica? Está desnormalizado, por lo que nunca debería borrarse nuevamente (datos en datawarehouse). La pregunta de esperanza es bastante clara.¿Es una buena práctica tener claves externas en un datawarehouse (relaciones)?
No tengo ni idea. Pero nadie está respondiendo, por lo que Google y encontró a best practises paper que parecen decir lo útil "Depende" :-)
Si bien las limitaciones de claves externas ayudan integridad de los datos, que tienen un costo asociado a todos inserción, actualización y eliminar declaraciones Preste especial atención al uso de restricciones en su almacén u ODS cuando desee garantizar la integridad y validación de los datos
Supongo que se refiere a los FK en las tablas de hecho. Durante la carga de DW, los índices y cualquier clave externa se eliminan para acelerar la carga: el proceso de ETL se ocupa de las claves.
La restricción de clave foránea se "activa" durante las inserciones y actualizaciones (aquí es cuando debe verificar que el valor de clave exista en la tabla padre) y durante las supresiones de claves primarias en las tablas principales. No juega parte durante las lecturas. La eliminación de registros en un DW es (debería) ser un proceso controlado que busque cualquier relación existente antes de eliminar de las tablas de dimensiones.
Por lo tanto, la mayoría de los DW no tienen claves foráneas implementadas como restricciones.
La pregunta es clara, pero la "buena práctica" parece ser una pregunta incorrecta.
"¿Ha podido tener FK's"?
Las claves foráneas son un mecanismo para preservar las restricciones de integridad durante las modificaciones de la base de datos.
Si su DW es de solo lectura (acumulando fuentes de datos sin escribir de vuelta), no hay necesidad de FK.
Si su DW admite escrituras, las constantes de integridad normalmente deben coordinarse entre las fuentes de datos participantes por ETL (más bien, es equivalente a la Tienda). Este proceso puede o no basarse en FK en la base de datos.
Así que la pregunta correcta sería: ¿usted necesita ellos.
(La única otra razón que se me ocurre sería la documentación de la relación - sin embargo, esto se puede hacer en el papel/en un documento separado, también.)
La razón de utilizar una restricción de clave externa en una el almacén de datos es el mismo que para cualquier otra base de datos: para garantizar la integridad de los datos.
También es posible que el rendimiento de la consulta se beneficie porque las claves externas permiten ciertos tipos de reescritura de consultas que normalmente no son posibles sin ellos. Sin embargo, la integridad de los datos sigue siendo la razón principal para usar claves externas.
Las restricciones de FK funcionan bien en los modelos dimensionales de Kimball en SQL Server.
Normalmente, su ETL tendrá que buscar en la tabla de dimensiones (generalmente en la clave comercial para manejar dimensiones que cambian lentamente) para determinar las identidades suplentes de dimensión, y la identificación sustituta de dimensión suele ser una identidad y la PK en la dimensión generalmente es la identificación sustituta de dimensión, que ya es un índice (probablemente agrupado).
Tener RI en este punto no es una gran tarea con las escrituras, ya que también puede ayudar a detectar defectos de ETL durante el desarrollo. Además, tener el PK de la tabla de hechos como una combinación de todos los FK también puede ayudar a atrapar posibles problemas de modelado de datos y doble carga.
En realidad, puede reducir la sobrecarga en selecciona si desea hacer vistas planas de uso general o funciones con valores de tabla de sus modelos estrella. Debido a que se garantiza que las uniones internas adicionales a las dimensiones producen una y una sola fila, el optimizador puede usar estas restricciones de manera muy efectiva para eliminar la necesidad de mirar hacia arriba en la tabla. Sin restricciones FK, estas búsquedas se deben hacer para eliminar los hechos donde la dimensión no existe.
Usar restricciones de FK en un DW es como usar un casco de bicicleta. Si el ETL está diseñado correctamente, usted técnicamente no los necesita. Dicho esto, si tuviera un millón de dólares por cada vez que he visto ETL sin errores, tendría cero dólares.
Hasta que se encuentre en un punto donde las restricciones FK están causando problemas de rendimiento, digo leave'em. Limpiar problemas de integridad referencial puede ser mucho más difícil que agregarlos desde el principio ;-)
Mis más de 20 años de experiencia en almacenamiento de datos y datos están de acuerdo con usted ... ¡Los proyectos cambian/evolucionan y los clientes (y los desarrolladores!) Pueden introducir fácilmente cambios que rompen suposiciones. Tener FK es de hecho una gran red de seguridad: ¡el "puente de bicicleta" oscila como un símil! De lo contrario, recomendaría una fase final de "validación" del proceso de carga que al menos verifique las restricciones/exclusividad en los datos. Gran respuesta, Bill. –
Hay una muy buena razón para crear restricciones FK incluso en DW/DM de solo lectura. Sí, no son realmente necesarios desde el punto de vista de solo lectura DW, si su ETL es a prueba de balas, etc., etc. Pero adivinen qué: la vida no se detiene en los datos de carga en DW. La mayoría de las herramientas analíticas/de informes de BI están usando información sobre sus relaciones DW para construir automáticamente su modelo (por ejemplo, el modelo SSAS Tabular). En mi humilde opinión, esto solo supera la pequeña sobrecarga en la caída y la recreación de las restricciones FK durante el proceso ETL.
Sí, como una práctica recomendada, implemente las restricciones FK en sus tablas de hechos. En SQL Server, use NOCHECK. En ORACLE siempre use RELY DISABLE NOVALIDATE. Esto permite que el almacén o centro comercial sepa sobre la relación, pero no la verifique en las operaciones INSERTAR, ACTUALIZAR o ELIMINAR. Transformaciones de estrellas, optimizaciones, etc. pueden no depender de las restricciones de FK para mejorar las consultas como solían hacerlo, pero nunca se sabe qué herramientas de BI u OLAP se usarán en la parte frontal o en su almacén o centro comercial. Algunas de estas herramientas pueden hacer uso de saber que las relaciones están definidas. Además, ¿cuántos almacenes de aspecto feo ha visto con poca o ninguna documentación externa y tuvo que intentar realizar una ingeniería inversa? Definir los FK siempre ayuda con eso.
Como diseñadores, NUNCA parece que nuestros data warehouses o marts sean autodocumentados como deberíamos. La definición de FK sin duda ayuda con eso. Ahora, una vez dicho esto, si los esquemas de estrellas están diseñados correctamente sin que se definan los FK, es fácil de leer y entender de todos modos.
Y para las tablas de hechos ORACLE, siempre defina un índice LOCAL BITMAP en cada FK en una dimensión. Solo hazlo. La indexación es realmente más importante que el FK definido.
+1. "Las claves externas son un mecanismo para preservar las restricciones de integridad durante las modificaciones de la base de datos. Si su DW es de solo lectura, no hay necesidad de FK ..." - ¡Ojo de buey! –
Algunas bases de datos tienen optimizaciones específicas en lugares para almacenes de datos estructurados de estrellas o copos de nieve. En esos casos, incluso en una situación de solo lectura, las claves externas pueden servir para alertar al almacén sobre cómo está estructurada la estrella, para decirle cuáles son el hecho y las dimensiones.Incluso en bases de datos normalizadas, las claves externas pueden afectar al optimizador. Estoy luchando para determinar cuándo y cuánto me importa a mí mismo ahora, pero ciertamente tiene ALGO efecto. – Chipmonkey