"Contribuciones a la Economía" es una revista académica con el
Número Internacional Normalizado de Publicaciones Seriadas
ISSN 1696-8360

“ARQUITECTURA DEL SERVIDOR DE INTELIGENCIA DE NEGOCIOS DE ORACLE”

Yunelsy Ortiz Chávez (CV)
Universidad de Holguín "Oscar Lucero Moya", Cuba
Freddy Ramón Laffita Almaguer (CV)
Desarrollo de Programas Informáticos, Cuba
Zaily Lizandra Ortiz Chávez (CV)
Cadena Hotelera Isla Azul, Cuba
yortiz@facii.uho.edu.cu



Resumen
El presente trabajo ayuda de manera fácil e intuitiva, a comprender la estructura del Servidor de Inteligencia de Negocios de Oracle, y se ejemplifican las trasformaciones que sufren las consultas desde los clientes en los servicios de presentación hasta los orígenes de datos físicos.

Para ver el artículo completo en formato pdf comprimido zip pulse aquí

Ortiz Chávez, Y.; Laffita Almaguer, F.; Ortiz Chávez, Z.: "Arquitectura del servidor de inteligencia de negocios de Oracle" , en Contribuciones a la Economía, noviembre 2011, en http://www.eumed.net/ce/2011b/

Introducción
Muchas veces, al realizar proyectos utilizando herramientas de Inteligencia de Negocios de la prestigiosa empresa Oracle, nos encontramos con problemas durante la construcción del repositorio y la creación de respuestas (answers), que en su mayoría, están asociados al desconocimiento parcial o total de la estructura y funcionamiento del servidor. En ocasiones percibimos que no coinciden los datos calculados de forma manual con los que proporcionan los reportes generados por la utilidad Analytics del paquete OBI (Oracle Business Intelligence) en edición empresarial y demás, o tal vez que devuelven errores al relacionar determinadas dimensiones y tablas de hechos. Situaciones como estas pudieran ser resueltas sin incurrir en grandes gastos de tiempo si se conocen a fondo las potencialidades y características de los elementos empleados.

Arquitectura del Servidor de Inteligencia de Negocios de Oracle
Oracle BI Server (OBIS) es un componente de Inteligencia de Negocios que procesa las solicitudes de los usuarios y consulta las fuentes de datos accesibles. Además soporta el modelo de datos lógicos y permite al cliente acceder al mismo a través del puente ODBC1.
La arquitectura del Servidor y el repositorio de OBI provee una capa de abstracción que posibilita a los usuarios enviar consultas simples de SQL Lógico2 contra complejos conjuntos de fuentes de datos.
El OBIS utiliza los metadatos que se encuentran en el repositorio de Oracle BI (OBIR) para realizar las siguientes tareas:

Los clientes de consultas se comunican con el OBIS y reciben los resultados mediante el puente ODBC, de manera similar funciona entre el OBIS y las distintas fuentes de datos a las que tenga acceso, debido a que, originalmente las herramientas de BI pertenecían a la compañía Siebel e implementaron la transmisión de esta forma. Luego al pasar a manos de Oracle se le incorpora una API4  nativa (modelo OCI5) para la conexión específica a su base de datos. Todos los metadatos que procesa el servidor están referenciados en el OBIR, el cual se gestiona a través de la herramienta Administration Tool perteneciente al paquete de OBI. Esta utilidad interactúa con el repositorio de dos formas (en línea y fuera de línea), la diferencia radica en que al usar la primera variante los cambios se pueden actualizar en el servidor, por lo que es imprescindible que el servicio (Oracle BI Server) esté en ejecución, en la segunda los cambios no son actualizables ni requieren que el servidor se encuentre funcionando.
Cuando los usuarios de consulta utilizan algunas de las herramientas de generación de reportes y crean respuestas, los campos de estas pertenecen a las áreas temáticas resultantes de la capa de presentación del repositorio, y ellos a su vez son columnas de las tablas lógicas en la capa intermedia (Modelo del Negocio y Mapeo). A continuación se muestra un ejemplo del SQL Lógico que recibe el servidor producto a una respuesta creada:
SELECT
"D0 Time"."T02 Per Name Month" saw_0,
"D4 Product"."P01 Product" saw_1,
"F2 Units"."2-01 Billed Qty (Sum All)" saw_2
FROM "Sample Sales"
ORDER BY saw_0, saw_1
El OBIS convierte la consulta SQL Lógica en una consulta física sofisticada como sigue:
WITH SAWITH0 AS (
select T986.Per_Name_Month as c1, T879.Prod_Dsc as c2,
   sum(T835.Units) as c3, T879.Prod_Key as c4
from
   Product T879 /* A05 Product */ ,
   Time_Mth T986 /* A08 Time Mth */ ,
   FactsRev T835 /* A11 Revenue (Billed Time Join) */
where ( T835.Prod_Key = T879.Prod_Key and T835.Bill_Mth = T986.Row_Wid)
group by T879.Prod_Dsc, T879.Prod_Key, T986.Per_Name_Month
)
select SAWITH0.c1 as c1, SAWITH0.c2 as c2, SAWITH0.c3 as c3
from SAWITH0
order by c1, c2
En el momento de ejecutarla el OBIS comprueba dos aspectos fundamentales:
Primero: Que exista una relación (camino) lógica (capa lógica) entre los campos ya sean provenientes de tablas de hechos o de dimensiones.
Segundo: De existir dicha relación entonces comprueba si hay un camino físico (capa física) entre los campos en los orígenes de datos hacia los cuales están mapeados.
Si todo está correcto realiza los cálculos finales (escogidos en la respuesta), si no envía los correspondientes mensajes de inconsistencia.
En el caso de la imagen anterior (Figura 4) el modelo del negocio está formado por 2 cubos de datos (C y D). Si se procesa una solicitud que involucre los atributos A.A1, B.B1, C.C1 (C se refiere a la dimensión) y la métrica T2.M1 se tiene que no existe una relación lógica entre C.C1 y ninguno de los otros componentes de la solicitud. Los problemas de inconsistencia lógica no están dados por pertenecer a cubos de datos diferentes, puesto que en un mismo diagrama (modelo del negocio) pueden coexistir más de uno, sino por la falta de relaciones entre las dimensiones y tablas de hechos a las cuales pertenecen los atributos de la solicitud realizada.
Tomando la solicitud de A.A1, B.B1 y la métrica T.M1 correspondiente al diagrama lógico de la figura 3, y como mapeo de los datos el siguiente:
       -  T.M1 procede del campo F2_Key.
       -  A.A1 procede del campo F2_1.
       -  B.B1 procede del campo F3_1.
Para este caso se conoce que no hay problemas en la comprobación lógica, y tampoco habrá en la (2) puesto que existe un camino físico que permite llegar desde los campos que representan los atributos de las dimensiones  A.A1 (F2_1) y B.B1 (F3_1)  hasta los que representan las métricas en la tabla de hechos T.M1 (F2_Key).
Ahora analicemos el mismo ejemplo pero utilizando como mapeo de los datos el siguiente:
       -  T.M1 procede del campo F2_Key.
       -  A.A1 procede del campo F1_1.
       -  B.B1 procede del campo F3_1.
En esta situación existirán dos variantes suponiendo que se haga una unión lógica6 entre las tablas involucradas (T y A, T y B):
Mejor caso: El valor en la columna (F2_Key) de la tabla F2 es el mismo en las tablas F1 y F3, el servidor no arroja errores de consistencia física pero los resultados de los cálculos no serán los esperados (solo calculará la métrica donde coincida en las tres tablas el valor del campo F2_Key).
Peor caso: El valor en la columna (F2_Key) de la tabla F2 se encuentra repartido entre las tablas F1 y F3 pero nunca en ambas, el servidor manda un error de consistencia física en el que especifica que es imposible calcular la métrica T.M1 según las dimensiones seleccionadas puesto que no se pueden mapear los datos.
Pero al adicionar nuevos registros en las tablas F1 y F3, no contenidos en ambas se generan inconsistencias al no existir coincidencias de F2_Key  de la tabla F3 en F1 o viceversa.
En general es de destacar que el OBIS está diseñado para realizar sus operaciones sin atacar las bases de datos, por tanto su diagrama físico (en el repositorio) no verificará ni se interpondrá con el esquema físico de ninguno de los orígenes de datos.
Esperamos que el artículo les sirva de ayuda en el desarrollo de soluciones de Inteligencia de Negocios, en especial la construcción del repositorio como el paso fundamental en este sentido.

Bibliografía
Azriel Marla, Bob Ertl. Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition, 11g Release 1 (11.1.1), April 2011.
Benchmarking Report - Strategic Foresight in Multinational Companies, Report of the European Corporate Foresight Group / R. Rohrbeck...[et.al.]. Berlin, Germany, 2009.
Cano, Josep Lluís. Business Intelligence: Competir con Información, Barcelona, ESADE, 2007.
Concepción Díaz Mayans. Referencias Bibliográficas Estilo Vancouver. Tomado de: http://www.cpimtz.sld.cu/normvanc.htm, 6 de octubre del 2011.
CREME, Phyllis y Mary R. LEA. Escribir en la universidad, Barcelona, Gedisa, 2001.
Ganczarski, Joe. Data Warehouse Implementations: Critical Implementation Factors Study. VDM Verlag, 2009.
INMON, W.H., Building the Data Warehouse, 4 Edition, Wiley, 2005.
Laudon, Jane y Kenneth. Sistemas de información gerencial. Administración de la empresa digital. Pearson Educación, Prentice Hall, 2006.
MARCO, D., Building and Managing the Meta Data Repository, New York: John Wiley & Sons, 2000.
MOSS, L. & ATRE, S., Business Intelligence roadmap: the complete project lifecycle for decision-support applications, Addison Wesley, 2003.
Normas Cubanas para la descripción bibliográfica. Disponible en: http://www.sld.cu/galerias/pdf/sitios/pdvedado/normas_cubanas_para_la_descripcin_bibliogrfica.pdf, consultado el 9 de octubre del 2011.
Oracle Call Interface. Tomado de: http://www.oracle.com/technetwork/database/features/oci/index.html,  19 de octubre del 2011
Referencias bibliográficas Harvard. Disponible en: http://www.sld.cu/galerias/pdf/sitios/ecimed/harvard.pdf, consultado el 11 de octubre del 2011.