Ayuda con diseño de dimensiones y hechos

 

Les escribo porque quiero unos consejos para el modelo que estoy haciendo en mi trabajo, es la primera vez que me han designado hacer un modelo de cero, por eso me encuentro algo preocupado para que salga un buen trabajo.

Sin más paso a explicarles parte del modelo transaccional del cual voy partir para crear mi modelo dimensional:

MODELO TRANSACCIONAL: http://imagizer.imageshack.us/v2/640x480q90/542/64pp.jpg

Las tablas en color verde son las candidatas para ser tablas FACT, ya que responden a preguntas para hallar medidas e indicadores.

Banca: tabla donde se registras las bancas (premiun, negocio, personal, etc) Item_Rendimiento: tabla donde se registra las agencias y oficinas

Producto: tabla donde se registra los diferentes productos del banco (producto cuenta sueldo, producto cuenta personal, producto préstamo hipotecario, etc)

Moneda: tabla donde se registra los diferentes tipos de monedas

Funcionario: tabla donde se registran al personal que tiene a su cargo una cartera de clientes. Funcionario pertenece a una BANCA

Clientes: tabla donde se registra la información de los clientes del banco. Un cliente pertenece a una banca, es atendido por un funcionario, pertenece a un Item_Rendimiento (agencia y oficina).

Tabla CUENTAS (candidata a ser FACT): tabla donde se registra la información de las cuentas del banco. La cuenta le pertenece a un cliente, tiene una moneda de sus operaciones, es de un tipo de producto; ejemplo, la cuenta crédito hipotecario en dólares del cliente Juan Perez (producto-moneda-cliente).

Tabla CUOTAS (candidata a ser FACT): tabla donde se registra las cuotas de los diferentes productos crediticios. Una Cuota pertenece a una Cuenta y se realiza en tipo de moneda; ejemplo: la CUENTA crédito hipotecario del ejemplo anterior se pactó en 60 cuotas, el pago de la cuota 21 en moneda dólares

Tabla SALDODIARIO (candidata a ser FACT): tabla donde se registra los movimientos de las diferentes cuentas, el movimiento pertenece a una banca, los realiza un cliente, afecta a una cuenta, lo atiende un funcionario, se realiza en un ItemRendimiento(agencia u oficina), se realiza en una moneda y afecta a un producto

Tabla ResumenNeto (candidata a ser FACT): tabla donde se registra el resumen al cierre mensual por cliente de la tabla SaldoDiario.

 

En mi modelo dimensional tengo la siguiente idea:

http://imagizer.imageshack.us/v2/640x480q90/32/h2i9.jpg

Tengo las siguientes dimensiones:

                dimBancas

dimClientes

dimCuentaContable

dimEstadoCuentas

dimFechas

dimFuncionarios

dimMonedas

dimUbigeo

dimItemRendimiento

dimProductos

 

Las siguientes tablas de hechos:

FactCuentas (ayuda me nuble)

factResumenNeto (la del modelo)

factSaldoDiario (ayuda me nuble)

factCuotas (ayuda me nuble)

 

 

En resumen los problemas que tengo son los siguientes: (en especial para armar SaldoDiario)

¿2 dimensiones se pueden relacionar sin ser jerarquías?

¿Cómo puede relacionar 2 fact?

Un CLIENTE relaciona BANCA, esto es una relación DIM-DIM

Un FUNCIONARIO relaciona BANCA, esto es una relación DIM-DIM

Un CLIENTE relaciona FUNCIONARIO, esto es una relación DIM-DIM

La CUENTA relaciona CLIENTE, esto es una relación FACT-DIM.

El SALDO DIARIO relaciona BANCA, esto es una relación FACT-DIM.

El SALDO DIARIO relaciona CLIENTE, esto es una relación FACT-DIM.

El SALDO DIARIO relaciona CUENTA, esto es una relación FACT-FACT,  dos FACT no se pueden relacionar, acá ya me atasque.

El SALDO DIARIO relaciona FUNCIONARIO, esto es una relación FACT-DIM.

El SALDO DIARIO relaciona ITEM RENDIMIENTO, esto es una relación FACT-DIM.

El SALDO DIARIO relaciona MONEDA, esto es una relación FACT-DIM.

El SALDO DIARIO relaciona PRODUCTO, esto es una relación FACT-DIM.

 

Por favor si alguien pudiera hacer un modelo de cómo debería ser mi diseño se lo agradecería bastante al menos para darme un inicio.

 

Gracias por su apoyo.

 

Saludos,

Tenéis decidido ya con qué software vais a implementar el proyecto de BI? Lo digo porque, aunque estés aún con el diseño lógico, las capacidades del software pueden hacer más adecuado un tipo de diseño u otro, sobretodo de cara a ir hacia un modelo en estrella o en copo de nieve. Las suites de BI que están ideadas para trabajar con modelos ROLAP en copo de nieve, por ejemplo, son mucho más flexibles en las relaciones entre las tablas del Data warehouse, y seguramente te permitirían establecer las relaciones que te parecen problemáticas.

De la pregunta de las dimensiones, puedes poner un ejemplo? Te refieres a una relación de varios a varios?

Sobre las tablas de hechos, sólo se hace si es realmente necesario, pero sí que se pueden relacionar, siempre que el software lo permita.

 

 

 

Hola Carlos,
 
En cuanto al repositorio es un SQLServer2012, y para la explotación temporalmente lo haremos con SSRS, tenemos la licencia de COGNOS, vamos a recibir una capacitación en la herramienta.
La relación entre las dimensiones (que a su vez se relacionan con la tabla de hechos) es de uno a muchos; por ejemplo:
Un CLIENTE pertenece a una BANCA, y una BANCA tiene muchos CLIENTES.
Un CLIENTE tiene un FUNCIONARIO, y un FUNCIONARIO es responsable de muchos CLIENTES.
Las relaciones de CUENTA  (una tabla de hechos)
Una CUENTA le pertenece a un CLIENTE, y un CLIENTE puede tener muchas CUENTAS.
Una CUENTA es de un tipo de producto, y un PRODUCTO se presenta en muchas CUENTAS.

 
(continua.....)

 (continuacion...)

 

Las relaciones de SALDODIARIO (una tabla de hechos). 

El SALDODIARIO se ejecuta en una BANCA, la operación la solicita un CLIENTE, afecta a una CUENTA, la opera un FUNCIONARIO, se realiza en un tipo de MONEDA, es para un PRODUCTO específico.

En este caso vemos que existe una relación de una FACT con 5 DIMENSIONES y además parece que debería existir una relación FACT con otra FACT (SALDODIARIO - CUENTAS). En este punto me bloque. Cabe indicar que las 5 dimensiones indicadas deberían de relacionarse por fuera aparte de la relación que tienen con la FACT.

Las relaciones de RESUMEN_NETO (una tabla de hechos)

El RESUMEN_NETO se ejecuta en una BANCA, la operación la solicita un CLIENTE, la opera un FUNCIONARIO, es para un PRODUCTO específico.

Las relaciones de CUOTAS (una tabla de hechos)

Las CUOTAS se pagan en un tipo de MONEDA, y afectan a una CUENTA.

Como vemos en este caso también parece existir una relación entre las 2 FACT (CUOTA - CUENTA), en el modelo transaccional obligatoriamente si se relaciones, porque como sabes la cuota que pago un cliente a cuál de sus cuentas afecta.

Mi idea inicial era realizar una estrella, sin embargo estoy pensandolo bien y creo que va a ser necesario un copo de nieve.

 

Agradecería mucho tu ayuda.

 

 

 

En respuesta a por Zend

Pues lo de utilizar Cognos no va a servir de mucho para elegir modelo porque Cognos BI puede trabajar tanto con cubos OLAP como en modo ROLAP, te adelanto que seguramente tendrás que decidirte por una u otra. Si te sirve de algo, personalmente pienso que Cognos estaba pensado en origen para trabajar en MOLAP, y los cubos son muy potentes. El modo 'ROLAP' a mí me parece un poco rebuscado, y creo que puede complicar bastante el desarrollo. Aclaro que estoy hablando de Cognos, de hecho con otras herramientas yo me siento más cómodo trabajando sobre ROLAP.

Viendo lo que quieres hacer, puede que te sea más fácil modelizarlo en copo de nieve.
Si te decides por utilizar cubos de Cognos, el modelo te servirá para crear los cubos, y si tienes que 'mezclar' dos tablas de hechos, puedes preparar la carga para seleccionar en el último paso los datos que necesites de cada una, y crear un cubo con la combinación.
Si trabajas en ROLAP, con Cognos creo que tampoco tendrás problema en definir los metadatos sobre el modelo en copo de nieve. Para el caso de las tablas de hechos de diferente granularidad, normalmente la manera de 'enlazarlas' es a través de dimensiones compartidas, ya nos irás explicando cómo lo haces..