Funciones de SQL

La clase que se aplica a la función SQL es Embed-UserFunction, lo que la hace diferente de otras instancias de la función Rule-Alias. En App Explorer, puede filtrar la clase Embed-UserFunction para ver únicamente las funciones SQL.

Supongamos que usted es un Lead System Architect (LSA) que ayuda a FSG a mejorar su aplicación de reservas. Su tarea es capturar la opinión de cada cliente sobre qué tan bien FSG organizó un evento en un lugar determinado. Al cliente se le pide que califique el rendimiento de FSG introduciendo un número del cero al diez. Los números cero y diez representan el Net Promoter Score (NPS) mínimo y máximo. Este rango de valores consiste en tres categorías:

• 0 a 6: detractores
• 7 a 8: pasivos
• 9 a 10: promotores

Después de capturar el Net Promoter Score, FSG quiere que defina un reporte que arroje resultados como el ejemplo que se muestra a continuación. Se supone que el reporte está agrupado por lugar

Utilizar reglas de decisión para precalcular la categoría es una mala opción por diversas razones.

• Redundancia de datos; supongamos que el valor original se actualiza
• Inhibe el análisis “y si”

Hay otras formas de generar este resultado sin usar reglas de decisión:

1. Usar una función SQL personalizada para marcar si el NPS está dentro de un rango determinado; usar la función SUM. Usar la función SQL tres veces.
2. Usar un subreporte parametrizado para CONTAR si el NPS está dentro de un rango determinado. Usar el subreporte tres veces.

Enfoque recomendado, v1

El mejor enfoque es definir una función SQL con tres parámetros enteros (como valor, inicio de rango y fin de rango). La función SQL utiliza el siguiente código.

CASE WHEN {1} >= {2} AND {1} <= {3} THEN   1

ELSE 0

END

El reporte etiqueta cada columna de acuerdo con las categorías que representa (como Promotores, Pasivos o Detractores). El segundo y tercer parámetro de la columna Promotores son 9 y 10, respectivamente. 

Pasos

1. El COE de la FSG definió una clase abstracta FSG-Data-Feedback en el ruleset de FSG. El equipo de reservas utiliza la herencia de patrón para extender la clase abstracta FSG-Data-Feedback a una clase concreta llamada FSG-Data-Feedback-Event. El equipo de reservas crea la clase FSG-Data-Feedback-Event dentro del ruleset BookEvent que es propiedad de la aplicación de reservas.
2. La FSG-Data-Feedback-Event clase contiene una propiedad EventRef , cuyo valor es igual al pyID de un caso FSG-Booking-Work-BookEvent.
3. Para maximizar el potencial de reutilización, la definición de reportes que utiliza la función SQL personalizada se define en FSG-Data-Feedback-Event, no en FSG-Booking-Work-BookEvent.
4. La definición de reportes hace INNER JOIN FSG-Data-Feedback-Event con FSG-Booking-Work-BookEvent WHERE .EventRef = EVENT.pyID, siendo “EVENT” un alias de join.
5. La definición de reportes también hace INNER JOIN con el FSG-Booking-Work-BookEvent to FSG-Data-Venue, usando .EVENT.VenueGUID = VENUE.pyGUID, siendo “VENUE” un alias de join.
6. La definición de reportes GROUP BY VENUE.Name, el resto de las columnas en el reporte usando funciones agregadas, siendo la primera COUNT EVENT.pyID.
7. Las tres columnas agregadas a la derecha utilizan la función SUM().
8. La entrada de cada función SUM() es la función SQL personalizada descrita anteriormente. El primer argumento de esa función SQL personalizada es la propiedad FSG-Data-Feedback .NetPromoterScore. El segundo y tercer argumento de la función SQL personalizada son valores literales, como 9 y 10, o valores obtenidos por un JOIN con la tabla de referencia descrita anteriormente.

Enfoque recomendado, v2

Una alternativa al enfoque v1 anterior es usar una subconsulta SELECT para recuperar los valores del rango inicial y final de una agrupación de filas de Live Data, como se muestra a continuación.

CASE WHEN {1} >= (select RANGE_START from RANGE_VALUES donde RANGE_NAME = {2} AND RANGE_GROUP = {3})

             AND {1} <= (select RANGE_END from RANGE_VALUES donde RANGE_NAME = {2} AND RANGE_GROUP = {3})

THEN  1

ELSE 0

END

La subconsulta anterior asume que se ha definido una tabla de referencia con los nombres de columna RANGE_GROUP, RANGE_NAME, START y END.

Enfoque alternativo

Este enfoque no se recomienda.

Dentro de la solución alternativa, cada subreporte tiene que usar una OUTER JOIN para funcionar correctamente. Obviamente, un reporte que requiere tres subconsultas de OUTER JOIN es menos eficaz que el SQL generado por el enfoque de la función SQL. La razón es que la función SQL es sencilla, ya que se examina cada fila consultada y se utiliza una lógica de comparación simple en cada una de las tres categorías para obtener un cero o un uno. A la vez, la función de agregación SUM suma la salida del caso al total acumulado para cada combinación GROUP BY única, en este caso, solo el nombre del lugar.

Por otro lado, el enfoque de los subreportes requiere que GROUP BY en el reporte principal, donde se cuenta el número total de eventos, también deba “agregar” los recuentos de tres subconsultas de OUTER JOIN. Esto es más complejo para la base de datos y, por lo tanto, tiene un menor rendimiento.