Yo y otro DBA en nuestra empresa tenemos la tarea de revisar un diseño de base de datos que un proveedor ha desarrollado para nosotros. El vendedor ha dicho que usan Kimball como base para su diseño. (NOTA: No estoy buscando argumentos de Kimball vs Inmon, etc.) Han diseñado un centro comercial con múltiples hechos y dimensiones.
Ahora, para ser justos, nuestra empresa nunca ha diseñado un solo centro comercial. Siempre hemos tenido los consultores hacerlo. Y nunca nos han enviado a clases ni nada. Por lo tanto, nuestro conocimiento de almacenamiento / marts / modelado dimensional, etc. se basa en la poca experiencia que tenemos, lo que podemos encontrar en Internet y la auto lectura (tenemos los libros de Inmon y Kimball y estamos tratando de abrirnos paso a través de ellos) .
Ahora que el escenario está listo para mi nivel de conocimiento, llegamos al desafío del diseño.
Hay una tabla de hechos llamada "Estadísticas de pérdida de reclamos" (esto es para el seguro). Y están tratando de capturar tanto los pagos por reclamos (acumulados a un nivel mensual) como el dinero en las reservas (algo así como una cuenta bancaria para reclamos). Desean ver los montos mensuales de los pagos (no es gran cosa). Pero desean ver el saldo actual de la cuenta de las reservas.
Daré un ejemplo pictórico.
Supongamos que configuramos $ 1000 USD en reservas para un reclamo. Esto se deja de lado (por lo que, en algunos aspectos, funciona como una cuenta bancaria).
En octubre de 2014, todavía no pagamos nada. Por lo tanto, la empresa quiere ver los pagos y el saldo de la reserva a fines de octubre.
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------Entonces llega noviembre. Efectuamos pagos de $ 100, $ 150 y $ 75 dólares. Desean ver esas cantidades agregadas y la reserva en el saldo de la siguiente manera:
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------
- 112014 - 325.00 - 675.00 -
-----------------------------------------------Y luego digamos que tenemos cero pagos en diciembre y luego $ 200 más en enero del próximo año.
-----------------------------------------------
- MONTH_YEAR - PAYMENTS - RESERVE_BALANCE -
-----------------------------------------------
- 102014 - 0.00 - 1000.00 -
-----------------------------------------------
- 112014 - 325.00 - 675.00 -
-----------------------------------------------
- 122014 - 0.00 - 675.00 -
-----------------------------------------------
- 12015 - 200.00 - 475.00 -
-----------------------------------------------Aquí es donde lucho. Entiendo que la parte de pagos es correcta. Todos se acumulan a nivel mensual dentro de cada registro. Por lo tanto, puede acumular más si lo desea para el año, trimestre, etc.
Pero el monto de las reservas es diferente. Es un equilibrio. Y el negocio quiere ver cuánto hay en el saldo cada mes. Pero no puede agregar en este campo. Si lo hiciera, obtendría algunos resultados inestables.
De alguna manera esto me parece incorrecto. Pero no puedo decir sinceramente que he modelado lo suficiente o que sé lo suficiente. Todo lo que puedo decir es lo que sé. Y por lo que sé, todos los valores en un hecho deben estar en la misma granularidad.
Ambos números tienen la misma granularidad de un "mes", pero no son desde el punto de vista de lo que representan. Uno es dólares agregados dentro de un mes. El otro es solo el equilibrio.
¿Es esto correcto? He estado retrasando este diseño. ¿Me equivoco al hacerlo? ¿Está bien hacer esto de hecho? ¿O es precisa mi sensación de "olor a código" de un mal diseño?
Cualquier ayuda sería apreciada. NOTA: por favor no solo diga "Debería ser la forma X", explique por qué debería ser así para que yo pueda aprender de esto.
EDITAR : Bueno, aprendí que mi comprensión inicial del hecho es incorrecta. La granularidad NO es mensual. La granularidad es el nivel de transacción. Eso significa que dentro del MES_AÑO (es decir, realmente es el período de información financiera) habrá múltiples pagos y transacciones de recuperación. Se publicarán por fecha o fecha de transacción. Pero debido a un informe previo que ve la empresa, y también debido a cómo se almacenan los datos en el sistema heredado de donde provienen, querían colocar tanto los datos transaccionales (una fila por) como el saldo mensual de reserva (una fila por mes )
Una vez que aprendí eso, me di cuenta de que el problema no era tanto aditivo como no aditivo, o incluso semi-aditivo, sino grano, que era lo que sospechaba desde el principio. Nuestro equipo de DBA discutió esto con el equipo del proyecto e informó que están tratando de poner dos granos diferentes en el mismo hecho, y esto no fue correcto. Que deberían subir las transacciones a un nivel mensual, permitiéndoles entonces tener los pagos, las recuperaciones y el saldo de reserva mensual (es decir, un hecho semi-aditivo) porque todo estaría en un grano mensual. O necesitan encontrar una manera de dividir el saldo de reserva en transacciones para preservar el nivel de transacción del grano. O necesitan dividir el hecho en dos hechos. Uno puede ser el nivel mensual para el saldo de reserva. El otro puede estar en el nivel de transacción para los pagos y recuperaciones. (No hay ninguna razón por la cual tampoco pudieron poner los pagos y las recuperaciones a nivel mensual en el nivel mensual también. Solo depende de las necesidades del negocio).
Dado lo que he aprendido, marcaré la respuesta de Thomas como la correcta. Sin embargo, creo que la discusión que comencé con la pregunta original sigue siendo buena para que otros aprendan, por lo que dejaré intacta la parte original de mi pregunta. También tengo la intención de otorgar una recompensa por la respuesta de nikadam, ya que eso me enseñó mucho sobre hechos aditivos, no aditivos y semi-aditivos, y corrigió muchos malentendidos que tenía sobre el modelado dimensional.
fuente
reserve, en un hecho aditivopayment into reserve, que tendrá el mismo nivel de granularidadpayment out of reserveque tiene ahora.Tiene razón: " no se deben mezclar diferentes granos en la misma tabla de hechos ".
Pero el saldo de reserva al final del mes y la suma de los pagos al final del mes son iguales. Solo uno de los hechos es semi-aditivo . El tipo de hecho (aditivo o no) no define el grano de la tabla.
Por lo que describe, veo su grano como "instantánea de reclamo mensual", lo que hace que su tabla de hechos sea " tabla de hechos de instantánea periódica ".
En este artículo, Kimball tiene un ejemplo de hechos aditivos y semi-aditivos en la misma tabla de hechos.
Aquí hay un ejemplo de una instantánea periódica con hechos semi-aditivos de The Data Warehouse Toolkit (página 116):
La mejor práctica es tener una tabla de hechos transaccionales que refleje cada cambio en la reserva (pagos y ajustes) en el nivel atómico más bajo. Cuando maneja reclamos, a menudo el nivel atómico no es reclamo sino reclamo secundario (su compañía de seguros puede tener su propio término para ello). En general, cada reclamación representará una parte diferente de la reclamación y pagos / reservas para cada parte. Por ejemplo, puede que no haya pagos al asegurado, sino pagos a personas no aseguradas por su compañía lesionada y pagos al hospital y al abogado.
Dependiendo del rendimiento de su herramienta de BI, puede usar la tabla de hechos transaccionales directamente para obtener pagos y saldos mensuales. O puede actualizar la tabla periódica de hechos instantáneos de transacciones diarias o al final del mes.
La capacidad de manejar hechos semi-aditivos dependerá de la capa de BI que esté utilizando. Algunas herramientas son capaces de lidiar fácilmente con hechos semi-aditivos y otras no.
El libro principal de Kimball ( The Data Warehouse Toolkit ) tiene un capítulo completo (16) sobre seguros.
fuente