¿Puedo tener códigos de no medida combinados con medidas en mi tabla de hechos?

Question

Estamos haciendo un poco complejo de acumulación de datos. Nuestro cliente nos envía algunas cosas que incluyen dos dimensiones (tiempo y una unidad de negocios). El tiempo es mayormente año-mes. La dimensión de la unidad de negocio tiene solo unos pocos atributos: un nombre y algunas categorías a las que las BU pueden pertenecer para fines de informes y análisis.

Las cosas que nos envían incluyen información de estado actual (fechas y códigos). Estos parecen hechos. También envían información que caracteriza la relación con la unidad de negocios (en su mayoría códigos adicionales). Nuevamente, estos son únicos para la unidad de negocios y el período de tiempo.

Finalmente, nos envían cosas que son claramente hechos aditivos. Incluye moneda y recuentos que tienen unidades adecuadas.

¿Debo mezclar esta información cualitativa en una sola tabla de hechos con los hechos aditivos? ¿O debo separar las cosas cualitativas (que solo se pueden usar con recuentos) de las cosas cuantitativas (que se pueden usar con la suma)?

Answer 1

Solo ponga cosas en la tabla de hechos si están degeneradas (causando problemas de alta cardinalidad / unicidad en su dimensión donde lleva la dimensión a una relación 1-1 con la tabla de hechos). Kimball recomienda evitar la tentación de poner cualquier cosa excepto las dimensiones degeneradas con los hechos (número de pedido único, por ejemplo).

Siempre puedes poner esto en lo que Kimball llama un " basura " dimensión. Todos esos códigos pueden simplemente agruparse en una dimensión basura. La mayoría de las fechas irían en la tabla de hechos como claves en su dimensión de fecha en un rol particular (generalmente con una clave int natural de la forma YYYYMMDD - una de las pocas veces que no usamos una clave sustituta sin significado sin identidad)

Me gusta ver ingenuamente a la estrella como todos los hechos y luego a qué columnas se dirigen a qué dimensiones están determinadas simplemente por conveniencia. Uno no debe necesariamente verlos como correspondientes a una entidad comercial en particular, recuerde que la estrella no es una base de datos OLTP normalizada de estilo ERD.

Answer 2

Si los datos están directamente relacionados con el hecho aditivo y no es algo en lo que desea agrupar / ordenar / buscar, entonces ponerlos en la tabla de hechos está bien.

Tenga en cuenta, sin embargo, que los datos no aditivos en la tabla de hechos evitarán los roll-ups o se convertirán en una operación con pérdida.

Answer 3

Brad Wilson describe con precisión el riesgo de agregarlos a su tabla de hechos. En el pasado, he agregado atributos de correo no deseado a mi tabla de hechos solo para requerir una refactorización posterior.

  

Las cosas que nos envían incluyen algunas   información del estado actual (fechas y   códigos). Estos parecen hechos. Ellos   también enviar alguna información que   caracteriza la relación con   la unidad de negocio (en su mayoría adicionales   códigos). Una vez más, estos son únicos para el   unidad de negocio y período de tiempo.

¿Para qué propósito comercial sirven las fechas? De improviso, recomendaría hacer de estas sus propias dimensiones y describirlas con precisión.

¿Qué tan volátiles son los códigos adicionales que vienen? Si el grano de su tabla de hechos es fecha y BU, ¿por qué no pueden incluirse en la dimensión BU y ser tratados como atributos que cambian lentamente?

Sin más detalles, no puedo hacer una recomendación firme, pero estas serían las primeras preguntas que me haría.