Skip to main content
Announcements
NEW Customer Portal: Initial launch will improve how you submit Support Cases. FIND OUT MORE
cancel
Showing results for 
Search instead for 
Did you mean: 
jorcan46
Contributor II
Contributor II

¿Cuales son las mejores prácticas cuando tenemos varias tablas de hechos, y muchas fechas relevantes diferentes?

Hola a todos,

Llevo un tiempo formandome en qlikview y haciendo algún proyecto, no obstante todavía me considero muy rookie y necesito un poco de ayuda. En muchos proyectos donde solo tenemos un par de fechas resulta relativamente fácil construir un Dashboard que genere alto valor al empresario, no obstante me encuentro en un momento donde por el modelo y la cantidad de hechos que se evalúan no tengo muy claro las mejores practicas para obtener un resultado fiable.

El modelo de datos tiene los las siguientes tablas de hechos:

Leads:

     Fecha.Captacion.

     Fecha.Cierre

     Datos identificativos del hecho

SalesOrders: (Incluyes presupuestos y pedidos)

     Fecha.creacion (Presupuesto)

     Fecha.Confirmacion (Conversion a pedido)

     Datos identificativos del hecho

Contratos: (derivados de una correcta ejecución del sale.order y que generarn una relacion recurrente)7

     F.InicioContrato

     F.FinContrato

Reclamaciones:

     F. Creacion

     F. Resolucion

AccionesCRM:

     F.AccionRealizada

Facturas:

     Fecha.Facturacion

     Fecha.Cobro

Esto es una simplificación del modelo, ya que tiene mas tablas de hechos. (8 tablas mas) con similares estructuras de fechas.

LA CUESTIÓN RELEVANTE PARA LA EMPRESA

La lógica asociativa de Qlikview permite la asociación de los hechos y dimensiones, por lo que me gustaría mantener todas las tablas de hechos en el mismo modelo, ya que al menos por ahora los tiempos de carga y ejecución permiten una aplicación fluida, y aporta una visión cruzada a la hora de analizar las tendencias en la evolución de indicadores y métricas. No obstante la multitud de fechas, hace que corramos varios riesgos, por una parte que los usuarios en su área de responsabilidad se confundan con que fecha están seleccionado, que la magnitud de la aplicación se haga de dificil mantenimiento, así como posibles errores derivados de una modelo de datos tan complejo.

DUDAS SOBRE UN REPLANTEAMIENTO

La problematica con las fechas. Me llega a un planteamiento que no tengo claro que sea el mas adecuado, y antes de meterme en un "lio" de muchas horas me gustaría conocer la opinión de los mas expertos.

Mi intención es generar una sola tabla de hechos a través de Resident LOAD uniendo las diferentes tablas de hechos. La tabla resultante tendrá diferentes fechas pero en una sola tabla.  Al final la tabla tendrá unos 800.000 registros creciendo en 300.000 aproximadamente al año.

No tengo claro si es una solución viable, o si existe alguna mejor practica. Agradezco vuestra opinión y ayuda al respecto.

Saludos!!!!

3 Replies
rubenmarin

Hola Jorge, en mi opinión la solución a la que has llegado es la más común para simplificar el modelo, yo intento tener una única tabla de hechos, en algunas circunstancias, cuando el documento mezcla hechos y comportamientos muy distintos es cuando los separo, pero tiene que haber una razón de peso para crear tablas de hechos adicionales.

Hay que solucionar algunos puntos, como los campos no informados en algunos hechos, las relaciones... hay distintas soluciones para cada punto.

Por comentar que también hay casos donde varias tablas de hechos giran en torno a unos campos clave que son los mismos en todas las tablas, en estos casos sí que puede ser mejor tener una tabla de selecciones y varias de hechos... depende mucho de los datos disponibles y del objetivo del documento.

De todas formas la gestión de las fechas tiene sus complicaciones, si te aclaras con el inglés hay un documento con enlaces a varios posts sobre gestión de calendarios:

How to use - Master-Calendar and Date-Values

Saludos.

jorcan46
Contributor II
Contributor II
Author

Muchas gracias Ruben, voy a echarle un vistazo a la documentación que me remites, y te cuento. Un saludo.

hector_munoz
Specialist
Specialist

Hola Jorge,

Estoy con Rubén. El modelo con tabla de hechos central (agregado o cajón de sastre de múltiples entidades con algo en común) tiene muchos beneficios a la hora de diseñar una aplicación: como el de un calendario canónico, otras dimensiones comunes a estas entidades como de estructura organizativa o territorial; pero además las aplicaciones construidas así suelen tener un mejor rendimiento a la hora de estar en un servidor porque expanden en RAM por un factor bastante menor que modelos con más "ramificaciones" de tablas.

Saludos,
Héctor