Alternativas a sub consultas usando Query & Analysis en Desktop Intelligence e Web Intelligence

Las herramientas de Consulta y Análisis de SAP BusinessObjects - Desktop Intelligence e Web Intelligence - son muy poderosas cuando se trata de analizar información corporativa. Le brindan la capacidad de agregar condiciones complejas sin la necesidad de conocer el lenguaje SQL. Un problema que puede surgir al generar su consulta es que, al definir condiciones con subconsultas, la complejidad (un indicador del rendimiento que tendrá la consulta cuando se transforma en lenguaje SQL) se intensifica, lo que hace que su consulta tarde una enorme cantidad de tiempo en generar, o no generar en absoluto. Veamos las causas profundas de estos hechos y una solución alternativa que puede usarse para agilizar su análisis.

Las causas fundamentales de un bajo rendimiento

Let’s consider the following example: We want to show a list of Contacts that accomplish a certain condition, but we also want to exclude two groups of contacts from that list. Let´s call this operation – –

Nuestra consulta se basará en los códigos de contacto, todos sus objetos de atributo necesarios y algunas condiciones que restringen la consulta, además de otras dos restricciones: "Códigos que no están en la lista Códigos que cumplen B" y "Códigos que no están en la lista Códigos que cumplen C "

Si el número de elementos en estas restricciones es demasiado alto, el motor SQL no puede manejar toda la solicitud y el resultado es que la consulta no finaliza.

Alternativas a una subconsulta

En el ejemplo anterior, podemos cargar los códigos de restricción en diferentes consultas o proveedores de datos. Luego, la consulta principal se puede modificar para que las subconsultas se conviertan en llamadas a proveedores de datos: "Códigos que no están en la consulta que cumple con B" y "Códigos que no están en la consulta que realiza C".

Esta solución tiene la ventaja de que la condición de subconsulta ya es física y no está involucrada en el cálculo de la consulta, por lo tanto, se reduce la complejidad. Desafortunadamente, hay un límite en el número de elementos en la subconsulta que puede manejar el motor de SAP BusinessObjects. Un mensaje emergente le informará sobre esto.

Another solution that actually works is to load the three lists (A, B, C) and do the exclusion – – directly in a report using report filtering… more on this below.

La solución

La solución con el mejor rendimiento es aquella en la que cargamos los datos que necesitamos en tres consultas o proveedores de datos diferentes, combinamos esta información en una sola tabla y aplicamos algo de filtrado directamente en el informe.

Las ventajas de este método son que el rendimiento está optimizado, ya que cada consulta tiene la menor complejidad. Además, es más visual ya que podemos verificar con ejemplos para asegurarnos de que lo que estamos haciendo es correcto. La única desventaja es que la solución puede ser demasiado técnica para un usuario comercial final, ya que estamos utilizando la fusión o vinculación de dimensiones y el filtrado complejo no intuitivo.

Encuentre a continuación una demostración de la ganancia de rendimiento analizando el costo de las consultas utilizando el plan de explicación de Oracle a partir de un ejemplo real:

the cost index using a single query containing two sub queries is 146,091
Cost index using three single queries shows a dramatic improvement. The cost is 7 times better (maximum cost = 6,334 x 3 = 19,000).

Si está interesado en probar esta solución, puede seguir estos pasos:

  1. Cargue las tres consultas o proveedores de datos (incluidos los códigos principales) como dimensiones

  2. Fusionar o vincular o las tres consultas o proveedores de datos solo a través de su código principal

  3. Asegúrese de cargar un tipo de objeto de detalle que tenga una relación de 1 a 1 con el código principal en cada consulta. Si no está disponible en el universo, se puede crear una variable de detalle emulando esta característica. Llamaremos a estas variables "banderas de filtrado"

  4. Create a table that contains the main code, its attributes and their filtering flags. Only the codes that are in the main table , but are not in or are the ones that are useful for us.

  5. 1. Agregue tres filtros en la pestaña / Informe: Indicador A: No es nulo / Indicador B: Es nulo / Indicador C: Es nulo

Mesa con tres filtros añadidos

Ahora se pueden ocultar las banderas y se pueden agregar todos los objetos de descripción para un código.

Con este ejemplo, hemos descrito un método para replicar consultas complejas cuando el número de elementos en las restricciones es demasiado alto. Si el número de elementos en las restricciones es razonable, entonces podemos continuar con el método estándar.

Esperemos que esta publicación le haya dado un buen ejemplo de cómo funciona la fusión / vinculación de consultas / proveedores de datos y ha demostrado que una buena comprensión de ellos ayudará a resolver los desafíos reales y respaldará la flexibilidad de las herramientas de SAP BusinessObjects Query & Analysis .

EspañolEnglish