In my last project I faced a situation where the customer asked me about the best option for a particular topic and this time my answer had to be "it depends". As a consultant, my duty was to provide two different options (with their corresponding pros and cons) but I could not make a decision on this, since the answer was highly dependent on the composition of IT service providers in different areas and also their road map. In general BI terms, we could define aggregation as the process of summarizing information at a certain level of detail in order to improve the performance. The Kimball Group defines Aggregate Navigation as the ability to use the right aggregated information and recommends to design an architecture with services that hide this complexity from the end user. In the BusinessObjects world the same concept is called Aggregate Awareness and the database administrators community usually refers to it as query re-write.
En SAP BusinessObjects, esto se puede lograr mediante el uso de la función @aggregate_aware, contextos y objetos incompatibles en el diseñador de universo. En un nivel de base de datos (RDBMS), ciertos proveedores proporcionan esta característica a través de vistas materializadas con opción de reescritura de consulta (Oracle, Sybase, DB2, Informix, PostgreSQL y algunos otros).
Así que aquí tenemos el dilema: ¿dónde colocar esta lógica en un entorno de cliente: en la capa física o en la capa lógica?
Ambas opciones son válidas, pero hay algunas consideraciones que deben tenerse en cuenta desde diferentes puntos de vista:
La información que se ve en la tabla anterior ya puede ser interpretada, pero como resumen, mi recomendación sería:
Implementación de la conciencia agregada en SAP Business Objects:
- Ideal para una arquitectura con muchas fuentes de base de datos (no todas las fuentes de base de datos admiten la característica de reescritura de la consulta y debe mantenerse en cada una de ellas)
- Es bueno tener si el proveedor de la base de datos puede ser cambiado en el futuro (no hay cambios necesarios en el universo)
- No hay acceso a administradores de base de datos que puedan ajustar correctamente la base de datos
- Arquitectura de informes cerrada basada en una capa semántica fuerte en Business Objects
- Existe la necesidad de un repositorio centralizado de metadatos
Implementación de mecanismos de reescritura de consultas en el RDBMS:
- Ideal para una arquitectura con muchas herramientas de informes que acceden a la misma base de datos
- Acceso a administradores de bases de datos sólidos
- Simplifica el diseño del universo
- No es necesario un repositorio centralizado de datos
If after reading this post you still have doubts on what direction to go for at your company or customer, do not hesitate to contact clariba at info@clariba.com or leave a comment below.