En mi último proyecto me enfrenté a una situación en la que el cliente me preguntó sobre la mejor opción para un tema en particular y esta vez mi respuesta tenía que ser "depende". Como consultor, mi deber era proporcionar dos opciones diferentes (con sus correspondientes pros y contras), pero no pude tomar una decisión sobre esto, ya que la respuesta dependía en gran medida de la composición de los proveedores de servicios de TI en diferentes áreas y también su camino mapa. En términos generales de BI, podríamos definir la agregación como el proceso de resumir la información en un cierto nivel de detalle para mejorar el rendimiento. El Grupo Kimball define Navegación Agregada Como la capacidad de utilizar la información agregada adecuada y recomienda diseñar una arquitectura con servicios que oculten esta complejidad al usuario final. En el mundo de BusinessObjects, el mismo concepto se denomina Conciencia de agregados Y la comunidad de administradores de bases de datos suele referirse a ella como 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
Si después de leer este post aún tiene dudas sobre la dirección a seguir en su empresa o cliente, no dude en ponerse en contacto con Clariba en info@clariba.com O deja un comentario abajo.