Download doc

ANEXO F ARQUITECTURAS DE INTELIGENCIA DE NEGOCIOS
1. Realizado por: Stephanie Herrera Bautista
2. Introducción:
2.1. Propósito:
Se busca realizar el planteamiento de las diversas arquitecturas que se pueden adaptar a procesos
de implementación de herramientas de inteligencia de negocio, con el fin de conocer sus ventajas
y desventajas para los procesos de implementación y cuales son los aportes que cada una realiza
en cada etapa
3. Arquitecturas
3.1. Arquitecturas de Inteligencia de Negocios
3.1.1. Arquitectura de Inteligencia de Negocios [33]
En la arquitectura general para la implementación de una herramienta de inteligencia de negocios,
encontramos que esta compuesta por 6 módulos, en donde cada uno se encarga de una tarea en especifica.
Ilustración 1: Arquitectura de BI
En la ilustración 2, vemos los módulos que componen a la arquitectura de Inteligencia de negocios, que
son:

Origen de datos: Sistemas OLTP o Fuentes de datos

Extracción: TXTs o Vistas

Transformación: Área temporal de preparación y limpieza

Carga de Datos: área dimensional o de modelos estrella

DataMarts: Cubo OLAP o área Multidimensional

Visualización: Consultas, Reportes, Indicadores, Análisis, Estadístico, tendencias, comparaciones
Para esta arquitectura se debe tener las siguientes consideraciones:

Se debe hacer la identificación de los orígenes de datos, estos se deben cargar periódicamente de
acuerdo al modelo requerido

Los datos se deben cargarse desde archivos TXT o desde bases de datos de organización via
ODBC u OLE DB

Los datos cargados acá siempre se deben cargar en áreas temporales para la transformación de
estos, homogenización u otras modificaciones a realizar

En el área denominada temporal es definido como el único origen o punto de entrada del modelo
dimensional

El modelo dimensional es definido como el único punto de origen o punto de entrada del
DataMart
3.1.2. Arquitectura Starcube [34]
La arquitectura de Starcube, es una herramienta de ROLAP de análisis multidimensional para el soporte a
la toma de decisiones, débilmente acoplada con el SGBD PostgreSQL, que fue propuesta por un grupo de
Ingenieros para el desarrollo una aplicación para las PYMES. Esta arquitectura esta compuesta por tres
módulos, que son: el modulo de interfaz grafica de usuario (GUI), el modulo de Kernel y el modulo de
utilidades.
En al siguiente figura, se muestra la arquitectura general de STARCUBE y la interacción con la
herramienta API OLAP4J y el SGBD PostgreSQL
Ilustración 2: Arquitectura general de Starcube
Los tres módulos que la conforman son:

Modo de utilidades:
En este modulo se realizan dos tareas principales que son:
o
Realizar la conexión con la base de datos
o
Ser contenedor de la colección de las clases principales y de las bibliotecas que serán
utilizadas por otras clases en cuanto a la manipulación y la visualización de los datos

Modulo de Kernel:
En este modulo se ha planteado los módulos de lógica de OLAP, los cuales son los necesarios
para la creación y manipulación de los cubos con el fin de realizar un correcto análisis de datos y
así poder tomar las decisiones mas acertadas
Está compuesto por 2 submódulos:
o
Modulo de creación de cubos: En este modulo se hace el planteamiento para la
realización de las operaciones necesarias para la creación de los cubos, en cuanto a sus
dimensiones y mediciones seleccionadas por el usuario
o
Modulo de manipulación de cubos: En este modulo es definido como el encargado de
creación del análisis y el que soporta las operaciones que se pueden realizar sobre cada
cubo cread, además es el encargado de mantener la consistencia de la información que
será entregada a los usuarios finales

Modulo de GUI:
En este modulo
contiene la interfaz entre el usuario y la lógica de la herramienta,
suministrándole al usuario final un ambiente de trabajo agradable
3.1.3. Arquitecturas de integración de las herramientas OLAP con un SGBD.
Las arquitecturas de integración de las herramientas OLAP con un SGBD se pueden ubicar en una de tres
tipos: las que herramientas son débilmente acoplados, las medianamente acoplados y las fuertemente
acoplados con un SGBD [19].
La arquitectura que es débilmente acoplada, es en la que se utilizan algoritmos de análisis en línea y sus
componentes se encuentran en una capa externa al SGBD por fuera del eje central, para su integración se
debe realizar desde una interfaz.
En la arquitectura que es medianamente acoplada se tiene que algunas tareas y algoritmos de análisis en
línea están en el SGBD y que por medio del uso de algunos procedimientos almacenados o funciones que
son definidas por el usuario
En la última arquitectura, que es fuertemente acoplada, se da cuando la totalidad de las tareas y los
algoritmos de análisis en línea son parte del SGBD como una operación primitiva, dándole las
capacidades de análisis en línea y brindándoles la posibilidad de un desarrollo de aplicaciones de este tipo
3.1.3.1.
3.1.3.1.1.
SISTEMAS ROLAP, MOLAP, HOLAP [34]
ROLAP [19] [34]
Para la implementación de una herramienta de ROLAP débilmente acoplada con un SGBD se realiza por
medio de un SQL integrado, siendo un lenguaje anfitrión de motor de ROLAP. Los datos se encuentran
en el SGBD y son leídos por medio de registros a través de ODBC, JDBC o de una interfaz de cursores
SQL. Una de las ventajas de esta arquitectura es su portabilidad, sin embargo sus desventajas son la
escalabilidad y el rendimiento de la aplicación.
En el problema de escalabilidad se da principalmente en las herramientas y aplicaciones que se
encuentran bajo este tipo de arquitectura, debido a que realizan una carga de todo el conjunto de datos en
la memoria, limitándolos para el manejo de grandes cantidades de datos. De igual forma en el problema
de rendimiento se presenta debido a que los registros se tienen que copiar uno a uno del espacio de
direccionamiento de la base de datos al espacio de direccionamiento en el aplicación ROLAP. Dando que
cuando se tienen estas operaciones de entrada/salida en un manejo de grandes volúmenes de datos es
bastante costoso, a pesar de que se ha intentado realizar una optimización en la lectura de estos bloques,
en donde las tuplas son leídas al tiempo, esto lo podemos ver en la ilustración 3
Ilustración 3: Arquitectura ROLAP débilmente acoplada
3.1.3.2.
MOLAP [70] [34]
A diferencia de los sistemas ROLAP, el OLAP multidimensional es un modelo de datos de propósito
especial, en cual las operaciones se hacen directamente sobre la bases de datos multidimensionales
(MDDs), proporcionando un rendimiento muy alto en las consultas (ilustración 4).
Una ventaja que tiene el MOLAP con respecto al ROLAP es la de tener operaciones nativas de OLAP, ya
que en un servidor de base de datos multidimensional es posible realizar pivot, roll up, dril drown,
dándonos que no sea necesario el tener que recurrir a uniones complejas y subconsultas del modelo
relacional
Ilustración 4: Arquitectura MOLAP
3.1.3.3.
HOLAP. [34]
HOLAP es OLAP hibrido, el cual une las ventajas de los dos sistemas anteriores, dando que se utilice un
esquema de MOLAP para el almacenamiento en las regiones determinadas en cada datacubo, pero las
dispersas serian almacenadas en un esquema de ROLAP
Otro método para poder realizar la hibridación es la utilización de una estructura multidimensional que
puede ser el cache de los datos del sistema de base de datos relacional; con estos se busca que se responda
rápidamente a las consultas OLAP con los datos almacenados en la cache, sin embargo al momento de no
encontrar los datos, se construye una consulta SQL para la recuperación de los datos en el sistema de base
de datos relacional
3.1.4. Arquitectura orientada a servicios (SOA)[78]
Es un estilo arquitectural para la construcción de soluciones empresariales que se basa en servicios. SOA
se relaciona con la construcción independiente de servicios alineados con el negocio que pueden llegar a
ser combinados en procesos que son significativos, de alto nivel en el negocio y con soluciones en el
contexto de la empresa. El valor real de SOA radica en la reutilización de los servicios para la
combinación de creación de procesos de negocios agiles y flexibles.
Es decir que por medio de la arquitectura de SOA nos brinda la posibilidad que diferentes organizaciones
puedan desarrollar de forma independiente sus servicios que atiendan a sus necesidades; sin embargo a un
plazo mediano o largo, estos servicios se deberían poder integrar para brindar mas valor a las soluciones
creadas y que tengan un mayor impacto en los procesos de negocio. Para poder lograr esta integración se
necesita que estos servicios sean:

Sean de forma similares en cuanto al: tamaño, forma, función y otras características.

Se adapten a los estándares de la empresa.

Su comunicación este a un nivel técnico y se comuniquen a un nivel semántico.

Y no presenten huecos ni solapamientos en sus responsabilidades
Las capas por las cuales se desempeñan una arquitectura orientada a servicios (ilustración 5), debe incluir
dos capas de conceptos. En la parte izquierda de la ilustración se encuentra una descripción que hace
referencia a los conceptos funcionales que se deben usar para la construcción de sistemas y procesos,
mientras que en la parte derecha de la ilustración se tienen los conceptos de información que son
utilizados para el paso, la descripción o la manipulación de los datos en los diferentes niveles funcionales.
La conexión entre cada capa significa la relación entre las funciones
Ilustración 5. Elementos arquitecturales de SOA [18]
Las capas son de abajo hacia arriba:

Recursos de la empresa y datos operacionales: Se compone de aplicaciones existentes como son
aplicaciones CRM (Customer Relationship Management) y ERP (Enterprise Resource Planning)
e implementaciones antiguas orientadas a objetos.

Servicios de integración: Los servicios de integración proveen este servicio entre las aplicaciones
existentes.

Servicios de negocio: Proveen servicios de negocio de alto nivel a la empresa

Procesos de negocio: Un proceso de negocio consiste en una serie de operaciones que son
ejecutadas en una secuencia ordenada acorde a un conjunto de reglas de negocio.
4. Bibliografía
[78] Rosen, Michael; Lublinsky, Boris; Smith, Kevin; Balcer, Marc. Applied SOA – Service Oriented
Architecture and design strategies. Wiley Publishing. 2008.
[70] Fernández, C.: Imprecisión e Incertidumbre en el Modelo de Datos Multidimensional: Aplicación a
la Minería de Datos, Editorial Universidad de Granada, Granada, España, (2005).
[34] Cujar, Alvaro; Mera, Alexander; Villota, Camilo. (2009). STARCUBE:Una herramienta ROLAP de
análisis multidimensional para el soporte a la toma de decisiones, débilmente acoplada con el
SGBDPostgreSQL. Pasto, Colombia
[33]Taylor, Guillermo. (2004). Arquitectura de una solución de Inteligencia de Negocios.
Consideraciones y mejores prácticas