20 Reglas para crear un RPD

Hola a todos este es mi primer post creado a mano por mi, lo que hice fue intentar traducir lo mejor que pude las 20 reglas de oro para crear un buen repositorio en OBIEE la próxima semana colocare un post de como instalar la versión 11.1.1.5 que por cierto tiene muchas mejoras.

Capa física

• Cuando se modela un esquema estrella (es el único esquema soportado por obiee por lo sencillo que es), es recomendable crear alias para todas las tablas físicas, usando prefijos como DIM, FACT, FACT_AGG
• Cuando sea posible, es recomendable configurar el pool de conexiones para usar un driver nativo para conectarse a las bases de datos física. Por ejemplo, usar OCI para conectarse a una base de datos Oracle en lugar de usar ODBC
• Es recomendable colocar el parámetro de la cantidad máxima de conexiones para el pool de conexiones de forma apropiada (ni demasiado bajo, ni demasiado alto). Si duda de cuál debería ser la cantidad máxima de conexiones, puede usar la siguiente formula con la cual asume que no más del 4% de sus usuarios se conectan y ejecutan reportes al mismo tiempo.

CONEXIONES MÁXIMAS = TOTAL USUARIOS * 0.04 * CANTIDAD MÁXIMA DE ANALISIS EN UN DASHBOARD

Si tienes más de 1000 usuarios y deberías de tener aproximadamente no más de 4 análisis por dashboard, y el parámetro de máximas conexiones seria de 160.

Capa lógica

• Toda tabla lógica debería  tener un prefijo como Dim – Fact – Fact Compound.
• Los nombres de las columnas físicas no deben estar presentes en la capa lógica. Todos los nombres deben estar orientado al negocio como por ejemplo “$ Ingresos” en lugar de usar “DOLAR”, aqui también podemos decir que las columnas físicas que no van a ser utilizadas en la capa lógica es mejor dejarlas en la capa física.
• Las claves primarias o claves sustitutas no deben estar presentes en la capa lógica a menos que sean necesarias para mostrarlas en los análisis.
• Las tablas de dimensiones lógicas siempre deben tener una clave lógica asignada. La clave lógica debe ser orientada al negocio como “Login Empleado” en lugar de “ID_Empleado”.
• Las tablas de dimensiones lógicas solo deben contener los atributos de dimensión, estas nunca deben contener columnas de medida (que tienen una regla de agregación).
• Las tablas de hecho lógicas nunca deben tener una clave lógica asignada.
• Toda columna lógica de una tabla de hechos lógica debe ser una medida, y por lo tanto deben tener una regla de agregación asignada.
• La capa lógica solo debe consistir en un esquema de estrella.
• Cada tabla de dimensión lógica debe tener su correspondiente nivel jerárquico (“Total” como el máximo nivel, y “Detalle” como el nivel más bajo)
• Cada nivel de la jerarquía debe tener la cantidad de elementos apropiadamente colocados, esto es por una cuestión de optimizacion de obiee que le ayuda a recrear las consultas sabiendo la cantidad de elementos que tiene cada nivel acelerando el proceso de armado de la query.
• Cada tabla fuente lógica que se encuentra contenida dentro de las tablas de hechos lógicos debe tener sus niveles de agregación bien establecidos. La única vez que el nivel de agregación no está establecido para una determinada dimensión es cuando no hay ninguna relación lógica entre ellos.
• No es necesario unir todas las medidas dentro de una tabla lógica de hechos. Por ejemplo, se puede dividir “Proyecciones de Venta” y “Ventas Actuales” en dos tablas lógicas “Fact - Ventas” y “Fact - Proyecciones”.
• Para las jerarquías de dimensiones solo se debe activar las opciones de “dimensiones desequilibradas” y “salto de nivel” si dichas jerarquías realmente se ajustan al concepto de desequilibradas o salto de nivel.

Capa de presentación

• Cuando tienes múltiples Áreas Temáticas, es recomendable listar las dimensiones comunes entre ellas en el mismo orden que aparecen en cada una de ellas.
• Las tablas pertenecientes a la capa de presentación no deben contener los prefijos de Dim, Fact, Fact Compound. 
• La tabla Tiempo en la capa de presentación debe ser colocada en el primer lugar de cada Área Temática. Mientras que las tablas de hechos deberían ser colocadas al final y llamarse Medidas.
• No debe existir la posibilidad de que un objeto del Área Temática que haya sido seleccionado por el usuario no posea una relación dentro del análisis, significa que el Área Temática ha sido definida de forma incorrecta ya que dos objetos no podrán coexistir en el mismo análisis (Recordar que los usuarios pueden crear los análisis usando los objetos de diferentes Áreas Temáticas).