Estás utilizando un navegador obsoleto. Este u otros sitios web pueden no ser mostrados correctamente.
Debes actualizarlo o utilizar un navegador alternativo.
Debes actualizarlo o utilizar un navegador alternativo.
Duda Modelización MicroStrategy
- Iniciador del tema JLP-C
- Fecha de inicio
A
Anonymous
Guest
JLP-C escribió:
Hola,
Mi problema es el siguiente: una factura puede estar asociada a un producto, un activo ó un número de cuenta contable dependiendo de lo que se haya comprado. ¿Cual es la mejor manera de modelizar esto tanto a nivel de tablas en el DW como luego en MicroStrategy?.
No sé si ya lo tienes resuelto pero sin saber más datos acerca de las relaciones, entiendo que para cada una de esas entidades relacionadas con la factura la relación es 1:n (1 factura->1 producto, 1 producto->n facturas por ejemplo). Si bien esta relación debe resolverse en una tabla de hechos. Así pues, yo crearía un 'tipo de factura' con tres valores (P,NC,A) posibles por encima de factura y la factura bajaría a una tabla de hechos donde llevaré el código de factura y el código único asociado a cada una de las entidades que pueden asociarse a la factura. Es decir, Producto (P) , Activo(A), Nº cuenta(NC) tendrán cada uno su tabla lookup, pero sus IDs se mapearán sobre un campo que se llamará igual (en los tres casos) aunque vaya mapeado sobre la lookup correspondiente y sobre la tabla de hechos a la que bajará ese código único. Cuando quieras analizar cada uno de ellos por separado sólo tienes que filtrar por el tipo de factura y cuando quieras estudiar el conjunto olvídate del tipo.
El truco está en el mapeo de los atributos sobre las tablas.
Si tienes alguna duda te lo aclaro mejor
Hola,
Mi problema es el siguiente: una factura puede estar asociada a un producto, un activo ó un número de cuenta contable dependiendo de lo que se haya comprado. ¿Cual es la mejor manera de modelizar esto tanto a nivel de tablas en el DW como luego en MicroStrategy?.
No sé si ya lo tienes resuelto pero sin saber más datos acerca de las relaciones, entiendo que para cada una de esas entidades relacionadas con la factura la relación es 1:n (1 factura->1 producto, 1 producto->n facturas por ejemplo). Si bien esta relación debe resolverse en una tabla de hechos. Así pues, yo crearía un 'tipo de factura' con tres valores (P,NC,A) posibles por encima de factura y la factura bajaría a una tabla de hechos donde llevaré el código de factura y el código único asociado a cada una de las entidades que pueden asociarse a la factura. Es decir, Producto (P) , Activo(A), Nº cuenta(NC) tendrán cada uno su tabla lookup, pero sus IDs se mapearán sobre un campo que se llamará igual (en los tres casos) aunque vaya mapeado sobre la lookup correspondiente y sobre la tabla de hechos a la que bajará ese código único. Cuando quieras analizar cada uno de ellos por separado sólo tienes que filtrar por el tipo de factura y cuando quieras estudiar el conjunto olvídate del tipo.
El truco está en el mapeo de los atributos sobre las tablas.
Si tienes alguna duda te lo aclaro mejor
A
Anonymous
Guest
Gracias por tu respuesta, al final lo solucioné de una forma menos elegante pero también efectiva creando una nueva entidad (elemento comprado) con su correspondiente tabla de look-up y en la que están todos los productos, activos y cuentas y asociando a cada factura las 4 entidades (el elemento comprado siempre con un valor y los otros tres rellenos ó vacíos dependiendo del caso).
Ahora tengo otra duda, ¿cual es la mejor manera de gestionar relaciones entre entidades cambiantes con el tiempo si no hay ºtablas de hechos de por medio?. Ejemplo: el número de empleados por departamento teniendo en cuenta que a lo largo del tiempo se dan de alta, de baja y pueden cambiar de departamento. ¿Cómo se modelizaría una función que contara (sin tabla de hechos dónde ya esten contados) el número de empleados que había en cada departamento y en cada momento del tiempo?
Ahora tengo otra duda, ¿cual es la mejor manera de gestionar relaciones entre entidades cambiantes con el tiempo si no hay ºtablas de hechos de por medio?. Ejemplo: el número de empleados por departamento teniendo en cuenta que a lo largo del tiempo se dan de alta, de baja y pueden cambiar de departamento. ¿Cómo se modelizaría una función que contara (sin tabla de hechos dónde ya esten contados) el número de empleados que había en cada departamento y en cada momento del tiempo?
A
Anonymous
Guest
Ahora tengo otra duda, ¿cual es la mejor manera de gestionar relaciones entre entidades cambiantes con el tiempo si no hay ºtablas de hechos de por medio?. Ejemplo: el número de empleados por departamento teniendo en cuenta que a lo largo del tiempo se dan de alta, de baja y pueden cambiar de departamento. ¿Cómo se modelizaría una función que contara (sin tabla de hechos dónde ya esten contados) el número de empleados que había en cada departamento y en cada momento del tiempo?[/quote]
Veamos:
Cuando se construye funcionalmente el modelo (definición de entidades, métricas, cuadros de cruce dimensional, nivel de agregación, componentes,...) se define o debe definir con el cliente qué querrá hacer con la dimensión tiempo y los atributos cambiantes con el tiempo. Normalmente al cliente le suele interesar tener una foto fija de la última situación de manera que la información de periodos anteriores bien se lleva acumulada por periodos (anuales) o bien se lleva a un histórico acordado de no más de dos años.
En el caso concreto por el que me preguntas en que deseas conocer el nº de empleados por departamento y tiempo (supongamos meses), yo lo llevaría precalculado en una tabla junto con el resto de datos precalculados del mismo tipo y al mismo nivel que se vayan a necesitar y a utilizar, seguramente, en fórmulas más complejas. De no querer precalcularlo (y no veo porqué no) necesitamos un campo de alta y otro de baja en la tabla de empleado, de modo que en el indicador que cuenta empleados filtremos dichos campos por el periodo solicitado de estudio. Por otra parte, si quieres calcular el nº de empleados por departamento debes contemplar la posibilidad de que un empleado puede cambiar de departamento mientras que en tu agrupación vas a tener la última foto de agrupación lo que nos lleva a la solución más fácil de precalcularla en la carga.
Otra opción para llevar de la manera más óptima posible la relación depto-empleado-tiempo es llevar en una tabla 4 campos:depto-empleado-fecha entrada-fecha salida siendo en este caso las fechas de entrada y salida aquellas en que cada empleado entra y sale de un departamento. En una compañía con gran rotación entre departamentos puede interesar llevar esta tabla e incluso llegar al detalle e incluso mostrar el puesto con las fechas de promoción y/o democión.
Como ves hay varias posibilidades que deben ser el resultado de un consenso con el cliente para que identifique claramente sus necesidades en este sentido. Las tablas de históricos suelen ser pesadas y deben crearse sólamente cuando las necesidades específicas del cliente así lo requieran.
Veamos:
Cuando se construye funcionalmente el modelo (definición de entidades, métricas, cuadros de cruce dimensional, nivel de agregación, componentes,...) se define o debe definir con el cliente qué querrá hacer con la dimensión tiempo y los atributos cambiantes con el tiempo. Normalmente al cliente le suele interesar tener una foto fija de la última situación de manera que la información de periodos anteriores bien se lleva acumulada por periodos (anuales) o bien se lleva a un histórico acordado de no más de dos años.
En el caso concreto por el que me preguntas en que deseas conocer el nº de empleados por departamento y tiempo (supongamos meses), yo lo llevaría precalculado en una tabla junto con el resto de datos precalculados del mismo tipo y al mismo nivel que se vayan a necesitar y a utilizar, seguramente, en fórmulas más complejas. De no querer precalcularlo (y no veo porqué no) necesitamos un campo de alta y otro de baja en la tabla de empleado, de modo que en el indicador que cuenta empleados filtremos dichos campos por el periodo solicitado de estudio. Por otra parte, si quieres calcular el nº de empleados por departamento debes contemplar la posibilidad de que un empleado puede cambiar de departamento mientras que en tu agrupación vas a tener la última foto de agrupación lo que nos lleva a la solución más fácil de precalcularla en la carga.
Otra opción para llevar de la manera más óptima posible la relación depto-empleado-tiempo es llevar en una tabla 4 campos:depto-empleado-fecha entrada-fecha salida siendo en este caso las fechas de entrada y salida aquellas en que cada empleado entra y sale de un departamento. En una compañía con gran rotación entre departamentos puede interesar llevar esta tabla e incluso llegar al detalle e incluso mostrar el puesto con las fechas de promoción y/o democión.
Como ves hay varias posibilidades que deben ser el resultado de un consenso con el cliente para que identifique claramente sus necesidades en este sentido. Las tablas de históricos suelen ser pesadas y deben crearse sólamente cuando las necesidades específicas del cliente así lo requieran.