UNIVERSIDAD TCNICA DE MACHALA

ESCUELA DE INFORMTICA

INTELIGENCIA DE NEGOCIOS

ING. BERTHA MAZN, MG. SC.

Machala - Ecuador
2014

INTRODUCCIN

En el ltimo decenio del siglo XX e inicios del siglo XXI, la humanidad ha asistido con
asombro a profundas transformaciones en las relaciones econmicas nacionales e
internacionales, en el campo del conocimiento cientfico-tecnolgico y en la globalizacin
de la economa que ha establecido y sigue determinando una nueva estructura
empresarial, con un avance vertiginoso por alcanzar altos estndares de productividad y
calidad en las operaciones cotidianas de sus empresas.
La Inteligencia de Negocios (Business Intelligence BI), es una alternativa tecnolgica y de
administracin de negocios, que permite manejar la informacin para la toma de
decisiones acertadas en todos los niveles de una organizacin, desde la extraccin,
depuracin y transformacin de datos, hasta la explotacin y distribucin de la
informacin mediante herramientas de fcil uso para los usuarios. En el mbito
empresarial, las decisiones se toman en alguno de los tres niveles organizacionales:
estratgico, tctico u operativo. Las decisiones estratgicas se centran en la direccin del
negocio a largo plazo siendo labor de los ejecutivos de alta gerencia. Las decisiones
tcticas corresponden a los gerentes de nivel medio y se enfocan en la planeacin,
anlisis y produccin de proyectos; a nivel operativo los empleados toman decisiones
cotidianas que se requieren para convertir los planes en accin.

CAPTULO I
INTRODUCCIN A LA
INTELIGENCIA DE NEGOCIOS

1.1.

NECESIDAD DE INFORMACIN Y CONOCIMIENTO EN LA EMPRESA

Las organizaciones actualmente caracterizan a la informacin como uno de los activos de

la empresa (BITAM, 2002.), es as, que se comienza a tratarla, especialmente aquella
relacionada con datos para tomar decisiones, de una manera ms metodolgica. A
continuacin se exponen brevemente algunos conceptos relacionados con la informacin
y su importancia estratgica para la toma de decisiones en las entidades.

1.1.1. Las Empresas en la Era de la Informacin

Desde que las organizaciones comenzaron a guardar los datos de sus operaciones en
medios de almacenamiento fsico, con el fin de permitirles una mayor administracin y
control de la informacin, ha existido una necesidad de utilizarla para atender las
necesidades propias del negocio.
La informacin y su importancia estratgica comenz a surgir cuando la competencia se
hizo muy fuerte, y cada vez ms y ms productos similares, de diferentes compaas, se
ponan a la venta, en ese momento el consumidor tuvo la opcin de seleccionar aquello
que ms le conviniera o lo que ms se adecuara a sus gustos y preferencias. Surge
entonces la necesidad de brindar servicios adicionales para obtener la lealtad de los
clientes, quienes poco a poco comenzaron a ver, no solo el producto que compraban,
sino cmo eran atendidos, qu garantas se ofrecan sobre su compra, qu ventajas
habra entre diferentes productos y, en general, evaluar todo lo que genera la
diferenciacin entre las compras que realizan. Cuando las empresas no tienen
garantizada la venta de lo que producen, realizan un cambio paulatino hacia obtener de
los datos toda la informacin til y estratgica para mantenerse en el mercado, dndole
un lugar preponderante al cliente.

Actualmente, se le da un peso especfico muy importante a la informacin como el

principal conocimiento que sostiene el negocio. Existen empresas que, de modo
predominante, ofrecen servicios y giran su negocio principal sobre el manejo de la
informacin (bancos, aseguradoras, casas de bolsa, internet, etc.), en ellas es fcil
identificar la importancia de la informacin, si no existiera sta dejaran de existir. Sin
embargo, hay otras en las que su giro principal es alrededor de la produccin, en ellas la
informacin debe identificarse para analizar y perfeccionar su produccin (porcentajes de
desecho, lneas de produccin, distribucin de materias, suministro, inventarios y
almacenes, procesos internos, publicidad y mercadotecnia, preferencias del cliente,
etc.).De hecho, en cualquier empresa se est tratando de convertir, por todos los medios
posibles, esa informacin en conocimiento que mejore los procesos y, a su vez, se
traduzca en ventajas competitivas en los mercados.
La idea de las empresas sedientas de informacin no surge de sbito, en realidad desde
que se almacenan los datos debe entenderse que tendran un fin utilitario en algn
momento, caso contrario, cualquier dato de control sera desechado instantneamente.
Lo que si surge de sbito es la imprescindible necesidad de dar respuesta rpida a los
requerimientos de informacin para la toma de decisiones para ayudar a mejorar de
alguna manera los procesos internos de negocio (BITAM, 2002.).

1.1.2. El Valor de la Informacin

En la poca actual, que se caracteriza por un crecimiento exponencial de las nuevas
tecnologas de la informacin y las telecomunicaciones, los activos ms valiosos de una
empresa ya no son activos tangibles o los depsitos en los bancos, sino los
conocimientos, habilidades, valores y actitudes de las personas que forman parte de una
empresa. De hecho, para generar riqueza es suficiente tener conocimiento sobre un tema
determinado y explotarlo de la mejor manera posible. Los factores de la produccin como
capital, tierra y trabajo, han sido sustituidos por el capital intelectual, que comprende

todos aquellos conocimientos tcitos o explcitos que generan valor econmico para la
empresa.
Prcticamente nadie cuestiona el hecho de que vivimos en la Era de la Informacin y que
la informacin tiene un valor econmico, esto se evidencia por que existen empresas
cuyo nico negocio es alrededor de la venta de informacin, como por ejemplo Gartner
Group, Empresas de Internet y Amazon, entre otras. En mercadotecnia, el conocimiento
es el nico camino posible para sostener ventajas competitivas. Es ms, en la actualidad,
la informacin y el conocimiento son considerados como el capital intelectual que soporta
la riqueza de una organizacin.
En el momento que una persona decide cambiar de empleo se est llevando consigo
informacin, conocimientos y est vendiendo su fuerza intelectual por un mayor precio; el
campo laboral nos indica que la fuerza de trabajo intelectual aumenta su costo con dos
factores bsicos que generan conocimiento: la experiencia y la educacin. Por su parte,
si un sistema que posee informacin eventualmente desaparece o falla, generar
prdidas a la empresa, incluso por cada minuto que est detenido. En la actualidad las
empresas estn apostando mucho por la tecnologa y los individuos para que juntos
tengan un conocimiento suficiente que acerque la visin interna de ambos a la realidad
exterior, en la medida que esa brecha disminuye, las decisiones tomadas se acercan ms
a la realidad exterior, generando decisiones ms correctas y en menos tiempo; si la
brecha o "gap de informacin" aumenta, puede ocasionar grandes prdidas para la
organizacin.
Es fcil entenderlo, suponiendo una situacin hipottica en la cual un nuevo auto es
diseado con lujo, pero con algunos toques de un auto deportivo y, sin realizar ningn
tipo de estudio previo ms que la intuicin y el sentido comn, se pretende lanzarlo para
que sea adquirido por adultos mayores de 30 aos. Para ello, una vez que se encuentra

listo para la distribucin, comienzan las campaas de publicidad y presentaciones

orientadas precisamente a ese mercado potencial.
Al cabo de cierto tiempo se dan cuenta que las campaas que lanzaron no han tenido
mucho impacto en ese segmento, pero curiosamente un porcentaje similar de las ventas
a la fecha se han dado en personas entre 25 y 30 aos. La realidad indica que ese auto
tiene un impacto mayor en un segmento distinto al que supona. En caso de haber tenido
informacin suficiente sobre las preferencias de los distintos segmentos, la historia de las
ventas y, sobre todo, un estudio previo de mercado se habra sabido con anticipacin
hacia dnde dirigir los esfuerzos de la publicidad con dos resultados benficos: en primer
lugar, la publicidad no habra sido inefectiva y el dinero utilizado en las campaas no se
habra desperdiciado; y en segundo lugar, se habra atendido a los verdaderos clientes
potenciales, con lo cual las ventas habran sido mayores. El ejemplo es hipottico, pero la
situacin es muy similar a la cotidianeidad, muchas empresas utilizan el sentido comn y
la intuicin para tomar decisiones, la informacin que se traduce en conocimientos acerca
la visin interna a la realidad y esa diferencia existente es la que puede representar miles
o millones de dlares. Lo que se pretende es acercar el mundo real a la visin interna
para generar ganancias, para convertir la informacin en utilidades, para darle un valor a
la informacin.
Si la informacin es un activo, debemos poder asignarle un valor econmico. La pregunta
que surge inmediatamente es cmo podemos asignarle un valor econmico a la
informacin. Dado un mercado libre, la primera respuesta es que el valor de la
informacin es lo que en el mercado se pague por ella. Este recurso simple, basado en el
valor percibido, muchas veces es suficiente para asignarle un valor a la informacin, sin
embargo, no es suficiente en otros casos, por ejemplo, en el caso de una pieza de
informacin que no vende y que es utilizada nicamente en procesos internos de toma de
decisiones.

La importancia de una buena informacin puede ser vista como la diferencia en valor
entre una decisin correcta y una decisin equivocada, en donde la decisin est basada
en esa informacin. Mientras ms grande sea esa diferencia entre decisin correcta y
errnea, mayor ser la importancia de contar con una buena informacin (BITAM, 2002.).

1.1.3. Por qu las Organizaciones Requieren Distintos Sistemas de

Informacin?
Para tener completamente automatizada a la empresa es necesaria una gran
infraestructura en tecnologa que soporta sistemas de informacin. Este crecimiento
tecnolgico tiene distintos orgenes, que van desde la implementacin, crecimiento,
ampliacin, integracin, etc. Las condiciones actuales de los mercados han provocado, la
necesidad de tecnologa cada vez ms avanzada para responder a las peticiones muy
particulares de informacin.
Sistemas de Procesamiento de Datos (SPD o OLTP), Sistemas de Manufactura,
Administracin de Recursos Empresariales (ERP), Sistemas de Informacin Ejecutiva
(EIS), Sistemas de Soporte a las decisiones (DSS), Sistemas Gerenciales, Manejo de
Relacin con Clientes (CRM), Suministro de la Cadena de Distribucin (SCM), son
algunos de los sistemas que surgen, se ponen de moda y luego algunos desaparecen
acorde a la evolucin de las empresas. Lo que es un hecho, independientemente del
enfoque que est de moda o sea ms til en el momento, es que los datos siempre sern
almacenados en bases de datos y esos datos sern el soporte total a las decisiones de la
empresa.
Muchos negocios requieren informacin de su actividad especfica, por ejemplo, los ERP
(Administracin de Recursos Empresariales) son sistemas muy grandes y complejos en
donde gran parte de su contenido se dedica a la produccin, sera ilgico adquirir un
sistema tan complejo y costoso si la empresa se dedica a los bienes races. En ese
mismo sentido existen desarrollos comercializados como productos que solo son

configurados en una organizacin en particular, pero tienen el funcionamiento mnimo

necesario para cierta industria. Hay software para la industria automotriz, software para
hoteles, comercio minorista, transporte, software educativo, entre otros. El motivo por el
cual son distintas las herramientas utilizadas obedece a que las actividades de misin
crtica, que soportan cada una de las industrias son diferentes y como tal, tambin es
distinto el tipo de informacin que puede solicitar un directivo en cada una de las
industrias, motivo por el cual hay muchos productos de software dedicados a explotar la
informacin de las bases de datos que no tienen caractersticas estndares, sino ms
bien son adaptables a cada situacin.
Considerando las distintas necesidades en cada actividad, es fcil extrapolar la misma
situacin a cada empresa, incluso con actividades similares, pero lo importante es
entender el ltimo nivel en cuanto a la diferenciacin de la informacin solicitada.
La informacin que fluye en una empresa est destinada a responder a diversos tipos de
preguntas de sus usuarios, de ah la necesidad que existan sistemas de informacin para
requerimientos muy especficos que permitan la recoleccin y el manejo de datos.
En el interior de una empresa, los puestos son factores importantes para determinar la
informacin que comnmente es requerida por la gente.
Los sistemas de procesamiento de datos (OLTP) hacen uso de medios de
almacenamiento y tcnicas para poblarlos. La mayora de las empresas, por la cantidad
de informacin que manejan, se basan en los OLTP para guardar muchos datos y tener
tiempos de respuesta cortos a los cientos de transacciones realizadas cotidianamente,
sin embargo, la eficiencia no es para la consulta masiva de grandes cantidades de
informacin y mucho menos para el anlisis de la misma. La tecnologa ha tenido que
adaptar los medios de que se vale para que sean eficientes en el mbito especfico de
aplicacin, tanto para el diseo de estructuras de datos que ordenen la informacin como
se desea, como en las herramientas o software que permite solucionar en tiempo y forma

lo que el usuario demanda. Es importante resaltar que todos los Sistemas de Informacin
tienen un fin muy particular, y se complementan para sostener, de la manera ms
eficiente, un negocio; sin embargo, no todos pueden solucionar las distintas demandas de
los usuarios, precisamente porque son diseados para alguna rea de aplicacin muy
especfica.
El motivo por el cual existen varios sistemas de informacin es porque los usuarios tienen
preguntas muy especficas que no cualquier sistema puede resolver. De hecho, las bases
de datos operacionales, que son las indispensables en cualquier organizacin, no estn
organizadas para responder a preguntas globales sino a pequeos grupos de datos.
Preguntas que involucren consultas complejas podran resolverse en un lapso extenso,
en el cual cabe la posibilidad de que la vigencia desaparezca. Lo importante es destacar
que una base de datos o sistema de informacin no tienen la capacidad de resolver las
necesidades informativas de toda la organizacin (BITAM, 2002.).

1.1.4. Informacin que las Empresas Necesitan

La tendencia de las organizaciones actuales es demandar informacin en los niveles
donde antes la administracin se basaba en la intuicin y el sentido comn para tomar
decisiones. A pesar de que en los niveles operativos siempre se ha demandado
informacin, histricamente no ha existido restriccin alguna para brindarla al usuario.
Ms bien los mercados dinmicos han obligado a las empresas para que la informacin
estratgica sea puesta en las computadoras de los directivos, este comportamiento se ha
generalizado principalmente motivado por la facilidad y utilidad de la informacin
compartida. En estos momentos la informacin fluye en todos los niveles de la
organizacin con diferentes fines (comunicacin, control, administracin, evaluacin, etc.)
independientemente de los puestos. Las empresas estn entendiendo que los niveles
directivos tienen una gran responsabilidad al tomar decisiones, pues el impacto que
generan recae sobre toda la organizacin, pero tambin existen ms personas que toman

decisiones y, a pesar de que stas no tienen un impacto global, deben ser tambin
correctas y oportunas, pues ciertos grupos dependen de las mismas.
Directores, gerentes, supervisores, jefes, todos aquellos que toman decisiones deben
tener suficiente informacin para apoyarse en su trabajo cotidiano, el lugar que ocupen
en la pirmide organizacional se vuelve secundario cuando el enfoque es hacia el manejo
de procesos y todos los puestos tienen cierta relacin y dependencia entre s.
De modo general en una pirmide organizacional, los requerimientos informativos se
dividen en 3 partes:

Informacin Estratgica

Informacin Tctica

Informacin Tcnico Operacional.

Informacin Estratgica
Est orientada principalmente a soportar la Toma de Decisiones de las reas directivas
para alcanzar la misin empresarial. Se caracteriza porque son sistemas sin carga
peridica de trabajo y sin gran cantidad de datos, sin embargo, la informacin que
almacenan est relacionada a un aspecto cualitativo ms que cuantitativo, que puede
indicar como operar la empresa ahora y en el futuro, el enfoque es distinto, pero sobre
todo es distinto su alcance. Se asocia este tipo de informacin a los ejecutivos de primer
nivel de las empresas.
Un punto importante es que la informacin estratgica toma grandes cantidades de datos
de reas relacionadas y no se enfoca especficamente hacia una sola, de ah que las
decisiones que puedan ser tomadas impactan directamente sobre toda la organizacin.

Informacin Tctica
Informacin que soporta la coordinacin de actividades y el plano operativo de la
estrategia, es decir, se plantean opciones y caminos posibles para alcanzar la estrategia
indicada por la direccin de la empresa. Se facilita la gestin independiente de la
informacin por parte de los niveles intermedios de la organizacin. Este tipo de
informacin es extrada especficamente de un rea o departamento de la organizacin,
por lo que su alcance es local y se asocia a gerencias o subdirecciones.
Informacin Tcnico Operacional
Se refiere a las operaciones tradicionales que son efectuadas de modo rutinario en las
empresas mediante la captura masiva de datos y Sistemas de Procesamiento
Transaccional. Las tareas son cotidianas y soportan la actividad diaria de la empresa
(contabilidad, facturacin, almacn, presupuesto y otros sistemas administrativos).
Tradicionalmente se asocian a las Jefaturas o Coordinaciones operativas o de tercer
nivel.
Si consideramos factores internos y externos de una organizacin podramos concluir que
los requerimientos actuales se orientan a conocer y mejorar los costos de toda la cadena
econmica. Estos requerimientos se reflejan en el inters por tener a la mano los
diagnsticos que arrojen informacin especfica y clave para determinada rea de
conocimiento, en el menor tiempo posible. La tendencia es que las reas directivas
necesitan en su escritorio la informacin clave de su empresa; en todos los niveles el
requerimiento es similar aunque, evidentemente, tiene objetivos diferentes. El paradigma
de la informacin exclusiva en los niveles directivos para apoyar la toma de decisiones no
es obsoleto, simplemente se debe mejorar y complementar agregando la informacin
tambin en otros niveles medios y jefaturas, o sea, en cualquier persona que tenga el
poder de tomar decisiones (BITAM, 2002.).

1.1.5. Objetivos de la informacin

El objetivo del usuario operativo es que se le facilite y automatice la operacin de una
funcin especfica de la empresa; el de un estratega es maximizar la funcin de la
empresa.

1.1.6. Usuarios
El usuario es distinto incluso en la misma pirmide organizacional. Mientras los sistemas
operativos tienen interfaces muy especializadas para un usuario que realiza una
operacin rutinaria, los usuarios estratgicos realizan consultas variadas y no previstas
de la informacin, por lo que los sistemas deben ser sencillos y con toda la informacin
disponible que cubra cualquier consulta requerida, de este caso el software final debe ser
orientado a un usuario en particular y, por ende, deber adecuarse al conocimiento que
tenga sobre el tema.

1.1.7. Tipos de preguntas

Las preguntas que responde un sistema operacional son referentes a las transacciones
que se realizan diariamente y a nivel registro o suma de registros de un solo tipo. Un
usuario operativo realiza frecuentemente preguntas sobre registros como pueden ser el
estado actual de una factura, movimientos de un cliente, cantidad surtida por un
proveedor, fecha del ltimo movimiento de un distribuidor, etc. Las preguntas de un
ejecutivo pueden tambin ser especficas, pero se orientan ms a agrupamientos de
datos como pueden ser totales por zona, promedios de clientes, tendencias de ventas e
incluso pronsticos. Toda esta informacin se encuentra de alguna forma en los
almacenes operativos, pero lanzar una consulta como las ventas totales del ao anterior
puede implicar hasta das en resolverse y otro tiempo para publicar los datos. Un sistema
organizado para resolver preguntas de ambos tipos en el menor tiempo posible es lo
ideal.

1.1.8. Cantidad de datos

Si un usuario procesa la informacin de las transacciones se mueve en el nivel registro.

Si un usuario procesa informacin de entidades, se mueve en el nivel agrupamientos de
registros, obviamente la cantidad de datos que se necesitan es distinta y debe ser un
sistema diferente el que provea de esa informacin. Para que un director o gerente, quien
necesita conocer las transacciones de toda una zona para tomar una decisin, pudiera
analizar cierto comportamiento, seran necesarias muchas hojas de reportes con cientos
de datos. El usuario operativo que necesita pocos registros no tiene mayor problema por
recibir una hoja de reportes, pero el directivo si tendra problemas con una cantidad
exagerada de papeles. Se necesitan sistemas que brinden no solo la cantidad ideal de
informacin segn el usuario, sino tambin que la entreguen en tiempos ptimos.
Resumiendo, existe una gran necesidad de informacin en muchos niveles de las
organizaciones, pero hasta el momento no existe un sistema de informacin que est
diseado para dar respuesta cabal a todos ellos. Cada sistema da respuesta a una parte
de los requerimientos de toda la empresa para que, en conjunto, no quede un espacio
vaco de informacin ni en tiempo, ni en forma.

1.2.

INTRODUCCIN A DATAWAREHOUSE Y DATAMART.

En la actualidad toda empresa pblica o privada necesita herramientas que le permitan

depositar mucha confianza en la toma de decisiones sobre los negocios que efecta,
para la toma de estas decisiones se necesita de hechos y cifras, ya que adems
la competitividad en los negocios crece aceleradamente entonces las decisiones que
debemos tomar en nuestra empresa deben ser ms rpidas y deben estar basadas en
buenos cimientos y para esto debemos manejar y analizar adecuadamente la informacin
que posee la empresa en el menor tiempo posible ya que las demoras pueden causar
incluso el cierre del negocio. Por ese motivo se requieren herramientas que nos ayuden a
minimizar el tiempo para analizar mucha informacin con mayor velocidad y precisin ya
que utilizando dichas herramientas logramos mantenernos competitivos debido a que

nuestros negocios deben reaccionar de acuerdo al cambio del mercado. De otro modo el
mercado globalizado, la presin inmensa de la competencia, los arranques tecnolgicos
entre otros cambios drsticos a que se han dado, irn debilitando nuestra empresa. Esto
nos muestra que las empresas en la actualidad estn invirtiendo en tecnologa y
soluciones con las cuales se mantienen competitivas en este mundo cambiante, ahora las
empresas no dependen tan solo de factores como ubicacin, productos o marketing. Sino
tambin del conocimiento basado en informacin comprensible, detallada y relevante que
es crucial para lograr y sostener ventajas competitivas. El poseer conocimientos correctos
significa tener respuestas correctas y realizar decisiones estratgicas para su ejecucin
en beneficio de la empresa. Pero las tareas de recolectar, procesar, limpiar y transformar
la informacin necesaria para la toma de decisiones no es una tarea sencilla mas si
consideramos que una empresa tiene distintas reas que a veces se encuentran alejadas
de los ejecutivos de negocios. El Componente de Inteligencia de Negocios (Business
Intelligence) que resuelve este caos en el manejo y anlisis la informacin o datos es el
Data Warehouse. El Data Warehouse es un conjunto de procesos y acciones, es una
coleccin de datos orientados a un tema, integrados y no voltiles en el soporte al
proceso de toma de decisiones de la gerencia.
Data Warehouse es el centro de la arquitectura para los sistemas de informacin en la
dcada de los '90. Soporta el procesamiento informtico al proveer una plataforma slida,
a partir de los datos histricos para hacer el anlisis. Facilita la integracin de sistemas
de aplicacin no integrados. Organiza y almacena los datos que se necesitan para el
procesamiento analtico, informtico sobre una amplia perspectiva de tiempo. Un Data
Warehouse es una coleccin de datos orientado a temas, integrado, no voltil, de tiempo
variante que es considerada la solucin integral y oportuna para desarrollar negocio y se
usa para el soporte del proceso de toma de decisiones gerenciales. Data Warehouse es
una herramienta con procesos para consolidar y administrar datos de variadas fuentes
con el propsito de responder preguntas de negocios y tomar decisiones. Data

Warehouse es un proceso que agrupa datos desde mltiples fuentes heterogneas,

incluyendo datos histricos para soportar la continua necesidad de consultas, reportes
analticos y soporte de decisiones.
Data Warehouse: Es la integracin de datos consolidados, almacenados en un dispositivo
de memoria no voltil, proveniente de mltiples y posiblemente diferentes fuentes de
datos. Con el propsito del anlisis y a partir de este tomar decisiones en funcin de
mejorar la gestin del negocio. Contiene un conjunto de cubos de datos que permiten a
travs de tcnicas de OLAP consolidar, ver y resumir los datos acorde a diferentes
dimensiones de estos.

Segn INMON (1992)

Un Data Warehouse es una coleccin de datos orientados a temas,
integrados, no-voltiles y variante en el tiempo, organizados para soportar
necesidades empresariales.
Segn SUSAN OSTERFELDT (1993)
Yo considero al Data Warehouse como algo que provee dos beneficios
empresariales reales: Integracin y Acceso de datos. DW elimina una gran
cantidad de datos intiles y no deseados, como tambin el procesamiento
desde el ambiente operacional clsico

Segn CHAUDHURI & DAYAL (1997)

Data Warehouse es la integracin de datos consolidados, almacenados en
un

dispositivo

de memoria no

voltil,

proveniente

de

mltiples

posiblemente diferentes fuentes de datos. Con el propsito del anlisis y a

partir de este tomar decisiones en funcin de mejorar la gestin del negocio.
Contiene un conjunto de cubos de datos que permiten a travs de tcnicas
de OLAP consolidar, ver y resumir los datos acorde a diferentes
dimensiones de estos.
Un Data Warehouse es una base de datos que permite analizar la informacin histrica
que contiene. Dependiendo las necesidades de anlisis de la organizacin puede
almacenarse desde unos meses hasta varios aos de informacin, para a partir de esta
tomar decisiones con el fin de mejorar la gestin del empresarial.

1.2.1. Caractersticas del Data Warehouse

Un Data Warehouse tiene muchas caractersticas entre las que podemos destacarlas
siguientes:

Orientado al tema
Una primera caracterstica del Data Warehouse es que la informacin se clasifica en base
a los aspectos que son de inters para la empresa. Siendo as, los datos tomados estn
en contraste con los clsicos procesos orientados a las aplicaciones. El ambiente
operacional se disea alrededor de las aplicaciones y la base de datos combina estos
elementos en una estructura que acomoda las necesidades de la aplicacin. La
alineacin alrededor de las reas de los temas afecta el diseo y la implementacin de
los datos encontrados en el Data Warehouse. Las 48principales reas de los temas
influyen en la parte ms importante de la estructura clave. Las aplicaciones estn
relacionadas con el diseo de la base de datos y del proceso. En Data Warehouse se
enfoca el modelamiento de datos y el diseo de la base de datos. El diseo del proceso
no es separado de este ambiente. Las diferencias entre la orientacin de procesos y

funciones de las aplicaciones y la orientacin a temas, radican en el contenido de la Data

a nivel detallado. En el Data Warehouse se excluye la informacin que no ser usada por
el proceso de sistemas de soporte de decisiones, mientras que la informacin de las
orientadas a las aplicaciones, contiene datos para satisfacer de inmediato los
requerimientos funcionales y de proceso, que pueden ser usados o no por el analista de
soporte de decisiones.
Integrado
El aspecto ms importante del ambiente Data Warehouse es que la informacin
encontrada al interior est siempre integrada. La integracin de datos se muestra de
muchas maneras: en convenciones de nombres consistentes, en la medida uniforme de
variables, en la codificacin de estructuras consistentes, en atributos fsicos de los datos
consistentes, fuentes mltiples y otros. A travs de los aos, los diseadores de las
diferentes aplicaciones han tomado sus propias decisiones sobre cmo se debera
construir una aplicacin. Se diferencian en la codificacin, en las estructuras claves, en
sus caractersticas fsicas, en las convenciones de nombramiento y otros. La capacidad
colectiva de muchos de los diseadores de aplicaciones, para crear aplicaciones
inconsistentes, es fabulosa.
De tiempo variante
Toda la informacin del Data Warehouse es requerida en algn momento. Esta
caracterstica bsica de los datos en un depsito, es muy diferente de la informacin
encontrada en el ambiente operacional. En stos, la informacin se requiere al momento
de acceder. En otras palabras, en el ambiente operacional, cuando usted accede a una
unidad de informacin, usted espera que los valores requeridos se obtengan a partir del
momento de acceso. Como la informacin en el Data Warehouse es solicitada en
cualquier momento los datos encontrados en el depsito se llaman de "tiempo variante.

Los datos histricos son de poco uso en el procesamiento operacional. La informacin del
depsito por el contraste, debe incluir los datos histricos para usarse en la identificacin
y evaluacin de tendencias como vemos en la figura continuacin.

Figura 1. De tiempo de variante

Fuente: (DOMINGUEZ)

No voltil
La informacin es til slo cuando es estable. Los datos operacionales cambian sobre
una base momento a momento. La perspectiva ms grande, esencial para el anlisis y la
toma de decisiones, requiere una base de datos estable. En la siguiente Figura se
muestra que la actualizacin es decir el proceso de insertar, borrar y modificar, se hace
regularmente en el ambiente operacional sobre una base de registro por registro. Pero la
manipulacin bsica de los datos que ocurre en el Data Warehouse es mucho ms
simple. Hay dos nicos tipos de operaciones: la carga inicial de datos y el acceso a los
mismos. No hay actualizacin de datos en el depsito, como una parte normal de
procesamiento.

Figura 2 No voltil
Fuente: (Bernabeu, 2010)

Escalable
Cuando la organizacin est lista para implementar una solucin de Data Warehouse, la
solucin necesita acomodarse al incremento dramtico de la demanda de los datos.
Como las instituciones crecen en otras reas, la solucin de Data Warehouse necesita
localizar los nuevos orgenes de datos y debe variar en su tamao de acuerdo a las
necesidades.

1.2.2. Estructura del Data Warehouse

Los Data Warehouse tienen una estructura distinta. Hay niveles diferentes de
esquematizacin y detalle que delimitan el Data Warehouse. La estructura de un Data
Warehouse se muestra a continuacin:

Figura 3 Estructura de los datos de un Data Warehouse

Fuente: (Bernabeu, 2010)

En la figura, se muestran los diferentes componentes del Data Warehouse y son:

Datos completamente resumidos
El siguiente nivel de datos encontrado en el Data Warehouse es el de los datos
completamente resumidos. Estos datos son compactos y fcilmente accesibles. A veces
se encuentra en el ambiente de Data Warehouse y en otros, fuera del lmite de la
tecnologa que ampara al Data Warehouse.
Datos ligeramente resumidos
La Data ligeramente resumida es aquella que proviene desde un bajo nivel de detalle
encontrado al nivel de detalle actual. Este nivel del Data Warehouse casi siempre se
almacena en disco. Los puntos en los que se basa el diseador para construirlo son: Que
la unidad de tiempo se encuentre sobre la esquematizacin hecha. Qu contenidos
(atributos) tendr la Data ligeramente resumida.

Detalle de datos actuales.

En gran parte, el inters ms importante radica en el detalle de los datos actuales, debido
a que: Refleja las ocurrencias ms recientes, las cuales son de gran inters.
Es voluminoso, ya que se almacena al ms bajo nivel de granularidad. Casi siempre se
almacena en disco, el cual es de fcil acceso, aunque su administracin sea costosa y
compleja.
Detalle de datos histricos
La Data antigua es aquella que se almacena sobre alguna forma de almacenamiento
masivo. No es frecuentemente accesada y se almacena a un nivel de detalle, consistente
con los datos detallados actuales. Mientras no sea prioritario el almacenamiento en un
medio de almacenaje alterno, a causa del gran volumen de datos unido al acceso no
frecuente de los mismos, es poco usual utilizar el disco como medio de almacenamiento.
Metadatos
El componente final del Data Warehouse es el de los Metadatos. De muchas maneras los
Metadatos se sitan en una dimensin diferente al de otros datos del Data Warehouse,
debido a que su contenido no es tomado directamente desde el ambiente operacional.
Los Metadatos juega un rol especial y muy importante en el Data Warehouse y son
usados como: Un directorio para ayudar al analista a ubicar los contenidos del Data
Warehouse. Una gua para el mapping de datos de cmo se transforma, del ambiente
operacional al de Data Warehouse.

1.2.3. Arquitectura del Data Warehouse

Dentro de arquitectura de un Data Warehouse, se define la estructura de los datos, as
como todos los procesos que intervienen en el manejo de los mismos, as tenemos las
comunicaciones, procesamiento y presentacin de los datos.
A travs del siguiente grfico se explicitar la estructura del Data Warehousing:

Figura 4 Arquitectura del Data Warehouse

(Bernabeu, 2010)
Tal y como se puede apreciar, el ambiente est formado por diversos elementos que
interactan entre s y que cumplen una funcin especfica dentro del sistema. Por ello es
que al abordar la exposicin de cada elemento se lo har en forma ordenada y teniendo
en cuenta su relacin con las dems partes.
Bsicamente, la forma de operar del esquema superior se resume de la siguiente
manera:
Los datos son extrados desde aplicaciones, bases de datos, archivos, etc. Esta
informacin generalmente reside en diferentes tipos de sistemas, orgenes y arquitecturas
y tienen formatos muy variados.
Los datos son integrados, transformados y limpiados, para luego ser cargados en el DW.
Principalmente, la informacin del DW se estructura en cubos multidimensionales, ya que
estos preparan esta informacin para responder a consultas dinmicas con una buena
performance. Pero tambin pueden utilizarse otros tipos de estructuras de datos para
representar la informacin del DW, como por ejemplo Business Models.
Los usuarios acceden a los cubos multidimensionales, Business Models (u otro tipo de
estructura de datos) del DW utilizando diversas herramientas de consulta, exploracin,
anlisis, reportes, etc.
A continuacin se detallar cada uno de los componentes de la arquitectura del Data
Warehousing, teniendo como referencia siempre el grfico antes expuesto, pero
resaltando el tema que se tratar.

OLTP

Figura 5 OLTP

(Bernabeu, 2010)
OLTP (On Line Transaction Processing), representa toda aquella informacin
transaccional que genera la empresa en su accionar diario, adems, de las fuentes
externas con las que puede llegar a disponer.
Como ya se ha mencionado, estas fuentes de informacin, son de caractersticas muy
dismiles entre s, en formato, procedencia, funcin, etc.
Entre los OLTP ms habituales que pueden existir en cualquier organizacin se
encuentran:

Archivos de textos.
Hipertextos.
Hojas de clculos.
Informes semanales, mensuales, anuales, etc.
Bases de datos transaccionales.

Load Manager

Figura 6 Load Manager

(Bernabeu, 2010)

Para poder extraer los datos desde los OLTP, para luego manipularlos, integrarlos y
transformarlos, para posteriormente cargar los resultados obtenidos en el DW, es
necesario contar con algn sistema que se encargue de ello. Precisamente, la Integracin
de Datos en quien cumplir con tal fin.
La Integracin de Datos agrupa una serie de tcnicas y subprocesos que se encargan de
llevar a cabo todas las tareas relacionadas con la extraccin, manipulacin, control,
integracin, depuracin de datos, carga y actualizacin del DW, etc. Es decir, todas las
tareas que se realizarn desde que se toman los datos de los diferentes OLTP hasta que
se cargan en el DW.
Como se mencion anteriormente cuando se trataron las caractersticas del DW1, si bien
los procesos ETL (Extraccin, Transformacin y Carga) son solo una de las muchas
tcnicas de la Integracin de Datos, el resto de estas tcnicas puede agruparse muy bien
en sus diferentes etapas. Es decir, en el proceso de Extraccin tendremos un grupo de
tcnicas enfocadas por ejemplo en tomar solo los datos indicados y mantenerlos en un
almacenamiento intermedio; en el proceso de Transformacin por ejemplo estarn
aquellas tcnicas que analizarn los datos para verificar que sean correctos y vlidos; en
el proceso de Carga de Datos se agruparn por ejemplo tcnicas propias de la carga y
actualizacin del DW.

Data Warehouse Manager

Figura 7 Data Warehouse Manager

(Bernabeu, 2010)
El DW Manager presenta las siguientes caractersticas y funciones principales:

Se constituye tpicamente al combinar un SGBD con software y aplicaciones

dedicadas.

Almacena los datos de forma multidimensional6, es decir, a travs de tablas de

hechos7 y tablas de dimensiones8.

Gestiona las diferentes estructuras de datos que se construyan o describan sobre

el DW, como Cubos Multidimensionales9, Business Models10, etc.

Gestiona y mantiene metadatos.

Adems, el DW Manager se encarga de:

Transformar e integrar los datos fuentes y del almacenamiento intermedio en un

modelo adecuado para la toma de decisiones.

Realizar todas las funciones de definicin y manipulacin del depsito de datos,

para poder soportar todos los procesos de gestin del mismo.

Ejecutar y definir las polticas de particionamiento11. El objetivo de realizar esto,

es conseguir una mayor eficiencia y performance en las consultas al no tener que
manejar todo el grueso de los datos. Esta poltica debe aplicarse sobre la tabla de
hechos que, como se explicar ms adelante, es en la que se almacena toda la
informacin que ser analizada.

Realizar copias de resguardo incrementales o totales de los datos del DW.

Query Manager

Figura 8 Query Manager

(Bernabeu, 2010)
Este componente realiza las operaciones necesarias para soportar los procesos de
gestin y ejecucin de consultas relacionales, tales como Join y agregaciones, y de
consultas propias del anlisis de datos, como drill-up y drill-down.
Query Manager recibe las consultas de los usuarios, las aplica a la estructura de datos
correspondiente (cubo multidimensional, Business Models, etc.) y devuelve los resultados
obtenidos.
Cabe aclarar que una consulta a un DW, generalmente consiste en la obtencin de
indicadores a partir de los datos (hechos) de una tabla de hechos, restringidas por las
propiedades o condiciones de los atributos que hayan sido creados.
Las operaciones que se pueden realizar sobre modelos multidimensionales y que son las
que verdaderamente les permitirn a l@s usuari@s explorar e investigar los datos en
busca de respuestas, son:

Drill-down.

Drill-up.

Drill-across.

Roll-across.

Pivot.

Page.

Drill-through.

Herramientas de Consulta y Anlisis

Figura 9 Herramientas de Consulta y Anlisis

(Bernabeu, 2010)

Las herramientas de consulta y anlisis son sistemas que permiten a l@s usuari@s
realizar la exploracin de datos del DW. Bsicamente constituyen el nexo entre el
depsito de datos y los usuarios.
Utilizan la metadata de las estructuras de datos que han sido creadas previamente
(cubos multidimensionales, Business Models, etc.) para trasladar a travs de consultas
SQL los requerimientos de los usuarios, para luego, devolver el resultado obtenido.
Estas herramientas tambin pueden emplear simples conexiones a bases de datos
(JNDI, JDBC, ODBC), para obtener la informacin deseada.
A travs de una interfaz grfica y una serie de pasos, los usuarios generan consultas que
son enviadas desde la herramienta de consulta y anlisis al Query Manager, este a su
vez realiza la extraccin de informacin al DW Manager y devuelve los resultados
obtenidos a la herramienta que se los solicit. Luego, estos resultados son expuestos
ante los usuarios en formatos que le son familiares.
Este proceso se puede comprender mejor al observar la siguiente figura:

Figura 10 Proceso de Consulta y Anlisis

(Bernabeu, 2010)
El mismo, se lleva a cabo a travs de seis pasos sucesivos:
1. Los usuarios seleccionan o establecen que datos desean obtener del DW,
mediante las interfaces de la herramienta que utilice.
2. La herramienta recibe el pedido de los usuarios, construye la consulta (utilizando
la metadata) y la enva al Query Manager.
3. El Query Manager ejecuta la consulta sobre la estructura de datos con la que se
est trabajando (cubo multidimensional, Business Model, etc.).
4. El Query Manager obtiene los resultados de la consulta.

5. El Query Manager enva los datos a la herramienta de consulta y anlisis.

6. La herramienta presentan a los usuarios la informacin requerida.

Usuarios

Figura 11 Usuarios

(Bernabeu, 2010)
L@s usuari@s que posee el DW son aquell@s que se encargan de tomar decisiones y
de planificar las actividades del negocio, es por ello que se hace tanto nfasis en la
integracin, limpieza de datos, etc, para poder conseguir que la informacin posea toda la
calidad posible.
Es a travs de las herramientas de consulta y anlisis, que los usuarios exploran los
datos en busca de respuestas para poder tomar decisiones proactivas.
Para comprender mejor a los usuarios del almacn de datos, se har referencia a las
diferencias que estos tienen con respecto a los del OLTP:

Los usuarios que acceden al DW concurrentemente son pocos, en cambio los que
acceden a los OLTP en un tiempo determinado son muchos ms, pueden ser
cientos o incluso miles. Esto se debe principalmente al tipo de informacin que
contiene cada fuente.

Los usuarios del DW generan por lo general consultas complejas, no predecibles

y no anticipadas. Usualmente, cuando se encuentra una respuesta a una consulta
se formulan nuevas preguntas ms detalladas y as sucesivamente. Es decir,
primero se analiza la informacin a nivel de datos actual para averiguar el qu,
luego, para obtener mayor detalle y examinar el cmo, se trabajan con los datos
ligeramente resumidos, derivados de la consulta anterior, y desde all se puede

explorar los datos altamente resumidos. Teniendo en cuenta siempre la

posibilidad de utilizar el detalle de datos histrico. Al contrario, los usuarios de los
OLTP solo manejan consultas predefinidas.

Los usuarios del DW, generan consultas sobre una gran cantidad de registros, en
cambio los del OLTP lo hacen sobre un pequeo grupo. Esto se debe a que como
ya se ha mencionado, el depsito contiene informacin histrica e integra varias
fuentes de datos.

Las consultas de los usuarios del DW no tienen tiempos de respuesta crticos,

aunque s se espera que se produzcan en el mismo da en que fueron realizadas.

1.2.4. Metodologas de Diseo de Dataware house

1.2.4.1.

La metodologa de Kimball

La metodologa se basa en lo que Kimball denomina Ciclo de Vida Dimensional del

Negocio (Business Dimensional Lifecycle) (Kimball et al 98, 08, Mundy & Thornthwaite
06). Este ciclo de vida del proyecto de DW, est basado en cuatro principios bsicos:

Centrarse en el negocio: Hay que concentrarse en la identificacin de los

requerimientos del negocio y su valor asociado, y usar estos esfuerzos para
desarrollar relaciones slidas con el negocio, agudizando el anlisis del mismo y
la competencia consultiva de los implementadores.

Construir una infraestructura de informacin adecuada: Disear una base de

informacin nica, integrada, fcil de usar, de alto rendimiento donde se reflejar
la amplia gama de requerimientos de negocio identificados en la empresa.

Realizar entregas en incrementos significativos: crear el almacn de datos (DW)

en incrementos entregables en plazos de 6 a 12 meses. Hay que usa el valor de
negocio de cada elemento identificado para determinar el orden de aplicacin de

los incrementos. En esto la metodologa se parece a las metodologas giles de

construccin de software.

Ofrecer la solucin completa: proporcionar todos los elementos necesarios para

entregar valor a los usuarios de negocios. Para comenzar, esto significa tener un
almacn de datos slido, bien diseado, con calidad probada, y accesible.
Tambin se deber entregar herramientas de consulta ad hoc, aplicaciones para
informes y anlisis avanzado, capacitacin, soporte, sitio web y documentacin.

Figura 12 Tareas de la metodologa de Kimball, denominada Business

FUENTE: (CHICAS, 2010)

1.2.4.2.

Metodologa propuesta por Bill Inmon

La metodologa de Inmon tiene un enfoque a modo de explosin en el sentido de que en

cierto modo no viene acompaada del ciclo de vida normal de las aplicaciones, sino que
los requisitos irn acompaando al proyecto segn vaya comprobndose su necesidad.
Esta visin de Inmon puede traer consigo mucho riesgo a la compaa, ya que invierte
grandes esfuerzos en el desarrollo del DW y no es hasta la aparicin de los DM cuando
se empieza a explotar la inversin y obtener beneficios. Esta estrategia se contempla en
el marco de que es imposible conocer cules son las necesidades concretas de
informacin de una empresa, el ambiente dinmico en que se mueve la organizacin, el

cambio de estructura que conlleva el desarrollo de la nueva plataforma y los

consiguientes cambios a los sistemas transaccionales que su introduccin implica. Esto
hace muy probable que despus de la gran inversin entiempo y recursos en el desarrollo
del DWH, se haga patente la necesidad de cambios fundamentales que traen consigo
altos costos de desarrollo para la organizacin, poniendo en evidente peligro el xito de
todo el proyecto en s y que podan ser evitados con una pronta deteccin en una
temprana puesta en explotacin de un primer avance del DWH. Esta metodologa para la
construccin de un sistema de este tipo es frecuente a la hora de disear un sistema de
informacin, utilizando las herramientas habituales como el esquema Entidad/Relacin
pero al tener un enfoque global, es ms difcil de desarrollar en un proyecto sencillo, pues
estamos intentando abordar el todo, a partir del cual luego iremos al detalle. Esta es
otra de las restricciones que trabajan en contra de la metodologa de Inmon ya que
implica un consumo de tiempo mayor, teniendo como consecuencia que muchas
empresas se inclinen por usar metodologas con las que obtengan resultados tangibles
en un espacio menor de tiempo

.
Figura 13 Desarrollo del DWH segn la metodologa de Bill Inmon
FUENTE: (CHICAS, 2010)

1.2.5. Introduccin a los Data Mart

Un Datamart es una base de datos departamental, especializada en el almacenamiento
de los datos de un rea de negocio especfica. Se caracteriza por disponer la estructura

ptima de datos para analizar la informacin al detalle desde todas las perspectivas que
afecten a los procesos de dicho departamento. Un datamart puede ser alimentado desde
los datos de un data warehouse, o integrar por s mismo un compendio de distintas
fuentes de informacin.
Por ejemplo, un posible usos sera para el data mining. El data mart est pensado para
cubrir las necesidades de un grupo de trabajo o de un determinado departamento dentro
de la organizacin. Es el almacn natural para los datos departamentales. En cambio, el
mbito del data warehouse es la organizacin en su conjunto. Es el almacn natural para
los datos corporativos comunes.
Segn (MICROSFT DATA WAREHOUSE TRAINING, 2000)
Data Marts: Es un subconjunto del Data Warehouse, usado normalmente
para el anlisis parcial de los datos. Ej: El Data Mart de los datos del
departamento ventas y el Data Mart de Inventarios. El objetivo de subdividir
est dado por la complejidad computacional del anlisis global de todas las
dimensiones del Data Warehouse y por la necesidad de rapidez.
Segn (DEFINE META GROUP)
"Un Data Mart es una aplicacin de Data Warehouse, construida rpidamente
para soportar una lnea de negocio simple".
Un Data Mart es una base de datos departamental que est especializada en el
almacenamiento de informacin confidencial de un rea de negocios especfica, adems
permite a los usuarios acceso a los datos que ellos necesitan para analizarlos ms a
menudo.

1.2.6. Tipos de Data Mart

Se definen dos tipos de Data Mart, los dependientes y los independientes:

Dependientes: Son los que se construyen a partir de un Data Warehouse central, es

decir reciben sus datos de un repositorio empresarial central.
Independientes: Son aquellos Data Mart que no dependen de un Data Warehouse
central, ya que pueden recibir los datos directamente del ambiente operacional, ya sea
mediante procesos internos de las fuentes de datos o de almacenes de datos
operacionales (ODS).

1.2.7. Carga de datos en Data Mart

Para la carga de datos hacia el Data Mart de pueden utilizar tcnicas de carga para las
herramientas OLAP, pero se debe tener en cuenta la capacidad de soportar extraccin de
grandes volmenes de datos desde las fuentes, para as no sobrecargar las mismas.
Adems los tiempos de carga y la calidad de los datos a ser transportados hacia el Data
Mart. Una de las herramientas para la carga de datos en Microsoft SQL Server son los
DTS, con los cuales podemos realizar la carga con solo escoger las fuentes y los
destinos Se debe tener cuidado que los datos sean coherentes es decir que los datos que
extraemos sean los que se cargan. Esta Fase comprende: preparacin, integracin, alto
nivel de agregacin y customizacin de los datos.

1.3.

PROCESO DE EXTRACCIN TRANSFORMACIN Y CARGA (ETL).

El primer paso para obtener los datos suele comenzar con tareas de extraccin,
transformacin y carga. Conocidos como procesos ETL (Extract, Transform and Load)
pueden realizarse con herramientas tambin denominadas ETL o sin ellas segn
necesidades. En cualquier caso es muy importante poner el mayor esfuerzo en
convertirlos en procesos desasistidos o automatizados.

Figura 14 Proceso de Extraccin, Transformacin y Carga de Datos

Fuente: (HUAMANTUMBA, 2007)

1.3.1. Extraer
La primera parte del proceso ETL consiste en extraer los datos desde los sistemas de
origen. La mayora de los proyectos de almacenamiento de datos fusionan datos
provenientes de diferentes sistemas de origen. Cada sistema separado puede usar una
organizacin diferente de los datos o formatos distintos. Los formatos de las fuentes
normalmente se encuentran en bases de datos relacionales o ficheros planos, pero
pueden incluir bases de datos no relacionales u otras estructuras diferentes. La
extraccin convierte los datos a un formato preparado para iniciar el proceso de
transformacin.
Una parte intrnseca del proceso de extraccin es la de analizar los datos extrados, de lo
que resulta un chequeo que verifica si los datos cumplen la pauta o estructura que se
esperaba. De no ser as los datos son rechazados.
Un requerimiento importante que se debe exigir a la tarea de extraccin es que sta
cause un impacto mnimo en el sistema origen. Si los datos a extraer son muchos, el

sistema de origen se podra ralentizar e incluso colapsar, provocando que ste no pueda
utilizarse con normalidad para su uso cotidiano. Por esta razn, en sistemas grandes las
operaciones de extraccin suelen programarse en horarios o das donde este impacto
sea nulo o mnimo.

1.3.2. Transformar
La fase de transformacin aplica una serie de reglas de negocio o funciones sobre los
datos extrados para convertirlos en datos que sern cargados. Algunas fuentes de datos
requerirn alguna pequea manipulacin de los datos. No obstante en otros casos
pueden ser necesarias aplicar algunas de las siguientes transformaciones:

Seleccionar slo ciertas columnas para su carga (por ejemplo, que las columnas
con valores nulos no se carguen).

Traducir cdigos (por ejemplo, si la fuente almacena una "H" para Hombre y "M"
para Mujer pero el destino tiene que guardar "1" para Hombre y "2" para Mujer).

Codificar valores libres (por ejemplo, convertir "Hombre" en "H" o "Sr" en "1").

Obtener nuevos valores calculados (por ejemplo, total_venta = cantidad * precio).

Unir datos de mltiples fuentes (por ejemplo, bsquedas, combinaciones, etc.).

Calcular totales de mltiples filas de datos (por ejemplo, ventas totales de cada
regin).

Generacin de campos clave en el destino.

Transponer o pivotar (girando mltiples columnas en filas o viceversa).

Dividir una columna en varias (por ejemplo, columna "Nombre: Garca, Miguel";
pasar a dos columnas "Nombre: Miguel" y "Apellido: Garca").

La aplicacin de cualquier forma, simple o compleja, de validacin de datos, y la

consiguiente aplicacin de la accin que en cada caso se requiera:
o

Datos OK: Entregar datos a la siguiente etapa (Carga).

Datos errneos: Ejecutar polticas de tratamiento de excepciones (por

ejemplo, rechazar el registro completo, dar al campo errneo un
valor nulo o un valor centinela).

1.3.3. Carga
La fase de carga es el momento en el cual los datos de la fase anterior (transformacin)
son cargados en el sistema de destino. Dependiendo de los requerimientos de la
organizacin, este proceso puede abarcar una amplia variedad de acciones diferentes.
En algunas bases de datos se sobrescribe la informacin antigua con nuevos datos.
Los data warehouse mantienen un historial de los registros de manera que se pueda
hacer una auditora de los mismos y disponer de un rastro de toda la historia de un valor
a lo largo del tiempo.
Existen dos formas bsicas de desarrollar el proceso de carga:

Acumulacin simple: La acumulacin simple es la ms sencilla y comn, y

consiste en realizar un resumen de todas las transacciones comprendidas en el
perodo de tiempo seleccionado y transportar el resultado como una nica
transaccin hacia el data warehouse, almacenando un valor calculado que
consistir tpicamente en un sumatorio o un promedio de la magnitud considerada.

Rolling: El proceso de Rolling por su parte, se aplica en los casos en que se opta
por mantener varios niveles de granularidad. Para ello se almacena informacin
resumida a distintos niveles, correspondientes a distintas agrupaciones de la
unidad de tiempo o diferentes niveles jerrquicos en alguna o varias de las
dimensiones de la magnitud almacenada (por ejemplo, totales diarios, totales
semanales, totales mensuales, etc.).

La fase de carga interacta directamente con la base de datos de destino. Al realizar esta
operacin se aplicarn todas las restricciones y triggers (disparadores) que se hayan
definido en sta (por ejemplo, valores nicos, integridad referencial, campos obligatorios,

rangos de valores). Estas restricciones y triggers (si estn bien definidos) contribuyen a
que se garantice la calidad de los datos en el proceso ETL, y deben ser tomados en
cuenta.

1.3.4. Procesamiento paralelo

Un desarrollo reciente en el software ETL es la aplicacin de procesamiento paralelo.
Esto ha permitido desarrollar una serie de mtodos para mejorar el rendimiento general
de los procesos ETL cuando se trata de grandes volmenes de datos. Hay 3 tipos
principales de paralelismos que se pueden implementar en las aplicaciones ETL:

De datos: Consiste en dividir un nico archivo secuencial en pequeos archivos

de datos para proporcionar acceso paralelo.

De segmentacin (pipeline): Permitir el funcionamiento simultneo de varios

componentes en el mismo flujo de datos. Un ejemplo de ello sera buscar un valor
en el registro nmero 1 a la vez que se suman dos campos en el registro nmero
2.

De

componente: Consiste

en

el

funcionamiento

simultneo

de

mltiples procesos en diferentes flujos de datos, pertenecientes todos ellos a un

nico flujo de trabajo. Esto es posible cuando existen porciones dentro de un flujo
de trabajo que son totalmente independientes entre ellas a nivel de flujo de datos.
Estos tres tipos de paralelismo no son excluyentes, sino que pueden ser combinados
para realizar una misma operacin ETL.
Una dificultad adicional es asegurar que los datos que se cargan sean relativamente
consistentes. Las mltiples bases de datos de origen tienen diferentes ciclos de
actualizacin (algunas pueden ser actualizadas cada pocos minutos, mientras que otras
pueden tardar das o semanas). En un sistema de ETL ser necesario que se puedan
detener ciertos datos hasta que todas las fuentes estn sincronizadas. Del mismo modo,

cuando un almacn de datos tiene que ser actualizado con los contenidos en un sistema
de origen, es necesario establecer puntos de sincronizacin y de actualizacin.

1.3.5. Los Retos del ETL

Existen numerosos desafos para implementar unos procesos ETL eficaces y fiables.
Los volmenes de datos crecen de forma exponencial, y los procesos ETL tienen que
procesar grandes cantidades de datos granulares (productos vendidos, llamadas
telefnicas, transacciones bancarias). Algunos sistemas de BI se actualizan
simplemente de manera incremental, mientras que otros requieren una recarga completa
en cada iteracin.
A medida que los sistemas de informacin crecen en complejidad, tambin aumenta la
disparidad de las source. Los procesos ETL necesitan una extensa conectividad a las
aplicaciones en paquetes (ERP, CRM, etc.), bases de datos, mainframes, archivos,
servicios Web, etc.
Las estructuras y aplicaciones de Inteligencia de negocio incluyen los almacenes de
datos histricos generales e individuales y las aplicaciones OLAP, para el anlisis,
notificacin y cuadros de mando operacionales y tcticos (dashboarding) y estratgicos
(scorecarding), etc.
Todas estas estructuras objetivo tienen requisitos diferentes de transformacin de datos,
y distintas latencias.
Las transformaciones implicadas en los procesos ETL pueden ser muy complejas. Los
datos necesitan agregarse, analizarse, computarse, procesarse estadsticamente, etc.
Tambin se necesitan transformaciones especficas a BI, como Slowly Changing
Dimensions.

Mientras que la Inteligencia de negocio tiende hacia una puntualidad real, los almacenes
de datos generales e individuales se tienen que actualizar ms a menudo, ya que las
ventanas de tiempo de carga se reducen.

1.3.6. Caractersticas de los ETL

Una interfaz de usuario para transformaciones eficaz y fcil de usar compatible con el
trabajo en colaboracin, la reutilizacin de procesos y los metadatos comunes.

Adquisicin de datos de una sola fuente o de mltiples fuentes, transformacin,

depuracin y carga para crear data warehouses, colecciones de datos y memorias de
datos analticos o de inteligencia de negocios.

Los metadatos son capturados y documentados a travs de transformaciones y

procesos de data integration y estn disponibles para reutilizacin inmediata.

Las transformaciones se pueden ejecutar en cualquier plataforma con cualquier

fuente de datos.

Ms de 300 transformaciones a nivel de columna y tabla predefinidas.

Transformaciones analticas listas para ser usadas, incluyendo correlaciones y

frecuencias, anlisis de distribucin y estadsticas de resumen.

Asistente de generacin de transformaciones o plantillas de diseo de plug-ins de

Java para la creacin de transformaciones reutilizables y repetibles, con seguimiento
y registr en metadatos.

Procesos de transformacin que puedan ser llamados a travs de salidas

personalizadas, colas de mensajes y servicios web de manera que pueden ser
reutilizados en diferentes proyectos y diferentes entornos de tecnologa.

Las transformaciones pueden ser ejecutadas de manera interactiva o programar su

ejecucin en lote a horas especficas o con base en eventos que activen su ejecucin.

Estructura para la publicacin de informacin en archivos, canal de publicacin,

correo electrnico o diversos middleware de cola de mensajes.

Fcil de renovar, agregar y actualizar durante la carga.

Tcnicas de carga optimizadas con opciones seleccionables por el usuario.

Tcnicas de carga compatibles bases de datos, incluyendo funciones de carga

masiva, creacin de ndices y claves, y truncado e interrupcin de tablas electrnicas.

Capacidad para disear, crear y cargar cubos OLAP fcilmente.

1.4.

CUBOS OLAP (ON-LINE ANALYTICAL PROCESSING)

Un cubo

OLAP, Online

Analytical

Processing,

es

una

base

de

datos

pero

multidimensional, que guarda los datos fsicos a travs de un vector multidimensional.

Una de las principales caractersticas de la potencia de los cubos OLAP es la rpida
ejecucin de las sentencias SQL de tipo SELECT.
Edgar Frank Codd fue el pionero en este tipo de bases de datos y precursor del diseo
del cubo, su idea era tener los datos en vectores con el fin de un anlisis mucho ms
rpido.
Los vectores seran los cubos y con esto se resolva el problema de las bases de datos
relacionales las cuales no podan analizar instantneamente altas cantidades de datos.
La funcionalidad de los sistemas OLAP se caracteriza por ser un anlisis
multidimensional de datos corporativos, que soportan los anlisis del usuario y unas
posibilidades de navegacin, seleccionando la informacin a obtener. Normalmente este
tipo de selecciones se ve reflejada en la visualizacin de la estructura multidimensional,
en unos campos de seleccin que nos permitan elegir el nivel de agregacin (jerarqua)
de la dimensin, y/o la eleccin de un dato en concreto, la visualizacin de los atributos
del sujeto, frente a una(s) dimensiones en modo tabla, pudiendo con ello realizar, entre
otras las siguientes acciones:

Rotar (Swap): alterar las filas por columnas (permutar dos dimensiones de
anlisis)

Bajar (Down): bajar el nivel de visualizacin en las filas a una jerarqua inferior.

Detallar (Drilldown): informar para una fila en concreto, de datos a un nivel

inferior.

Expandir (Expand): id. anterior sin perder la informacin a nivel superior para
ste y el resto de los valores.

Colapsar (Collapse): operacin inversa de la anterior.

Las siguientes caractersticas continan distinguiendo las herramientas OLAP de las

herramientas de query y reporting tools:

En una herramienta Multidimensional los usuarios analizan los valores numricos

de diferentes dimensiones (como producto, tiempo, geografa). En un informe, por
otro lado, solo hay una dimensin de anlisis.

El cambio entre las diferentes dimensionales de anlisis y los diferentes niveles de

ellas es muy rpido en este tipo de herramientas. Si un usuario hace un doble
click en la dimensin tiempo, en el nivel Ao, rpidamente va a poder ver la
informacin de un mes o de un da en concreto, sin tiempos de espera excesivos.
En un informe, los tiempos de clculo pueden ser muy considerables (hasta llegar
incluso al punto de tener que ser programados en procesos batch su ejecucin).

La herramienta Olap es sumamente interactiva, permitindonos pivotar sobre la

informacin vindola desde diferentes perspectivas y cambiar dichas perspectivas
de una forma muy rpida. Analizando las ventas por mes, podremos cambiar la
visin de la informacin para verla por producto o por tipo de cliente. Adems se
pueden establecer filtrados interactivos y el desglose de la informacin se puede
realizar para un subconjunto de la dimensin en concreto. Este tipo de interaccin
con los datos es imposible con los informes (aunque posible en algunos
productos).

Figura 15 Plataformas OLAP y las Interfaces de Usuario OLAP

Fuente: (ESPINOSA, 2010)

Para distinguir los requerimientos OLAP, es importante distinguir entre las plataformas
OLAP y las interfaces de usuario OLAP.

1.4.1. Plataformas OLAP

La plataforma OLAP es aquella en la que se almacenan los datos para permitir el anlisis
multidimensional. El cubo mostrado en la imagen superior representa una base de datos
OLAP. En este contexto, los usuarios finales no tendrn que preocuparse como se
almacena la informacin, si se replica, tiene cache o qu tipo de arquitectura utiliza, pero
todos estos aspectos si influirn en que tipo de herramienta front-end puede utilizar, que
podr analizar y como.
Hay cuatro tipos de arquitectura OLAP:
Relational OLAP (ROLAP): este tipo de plataforma almacena los datos en una base de
datos relacional, lo que implica que no es necesario que los datos se repliquen en un
almacenamiento separado para el anlisis (veremos que en la mayora de los casos es

preferible esta diferenciacin). Los clculos se realizan en una base de datos relacional,
con grandes volmenes de datos y tiempos de navegacin no predecibles. Parte de la
premisa que las capacidades Olap se desarrollan mejor contra este tipo de bases de
datos.
El sistema ROLAP utiliza una arquitectura de tres niveles. La base de datos relacional
maneja los requerimientos de almacenamiento de datos, y el motor ROLAP proporciona
la funcionalidad analtica.

El nivel de base de datos usa bases de datos relacionales para el manejo, acceso
y obtencin del dato.

El nivel de aplicacin es el motor que ejecuta las consultas multidimensionales de

los usuarios.

El motor ROLAP se integra con niveles de presentacin, a travs de los cuales los
usuarios realizan los anlisis OLAP.

Figura 16 Relational OLAP (ROLAP)

Fuente: (ESPINOSA, 2010)

Los usuarios finales ejecutan sus anlisis multidimensionales, a travs del motor ROLAP,
que transforma dinmicamente sus consultas a consultas SQL. Se ejecutan estas
consultas SQL en las bases de datos relacionales, y sus resultados se relacionan
mediante tablas cruzadas y conjuntos multidimensionales para devolver los resultados a
los usuarios.
La arquitectura ROLAP es capaz de usar datos precalculados si estos estn disponibles,
o de generar dinmicamente los resultados desde los datos elementales si es preciso.
Esta arquitectura accede directamente a los datos del Data Warehouse, y soporta
tcnicas de optimizacin de accesos para acelerar las consultas. Estas optimizaciones
son, entre otras, particionado de los datos a nivel de aplicacin, soporte a la
desnormalizacin y joins mltiples.
Algunos fabricantes son: Oracles BI EE, SAP Netweaver BI, MicroStrategy, Cognos 8,
BusinessObjects Web Intelligence.
Multidimensional OLAP (MOLAP): los datos son replicados en plataformas con un
almacenamiento construido a propsito que asegura mayor velocidad en los anlisis. Los
clculos se llevan a cabo en un servidor con una base de datos multidimensional,
partiendo de la premisa que un sistema OLAP estar mejor implantado almacenando los
datos multidimensionalmente.
El sistema MOLAP utiliza una arquitectura de dos niveles: La bases de datos
multidimensionales y el motor analtico.

La base de datos multidimensional es la encargada del manejo, acceso y

obtencin del dato.

El nivel de aplicacin es el responsable de la ejecucin de los requerimientos

OLAP. El nivel de presentacin se integra con el de aplicacin y proporciona un

interfaz a travs del cual los usuarios finales visualizan los anlisis OLAP. Una
arquitectura cliente/servidor permite a varios usuarios acceder a la misma base de
datos multidimensional.

La informacin procedente de los sistemas operacionales, se carga en el sistema

MOLAP, mediante una serie de rutinas batch. Una vez cargado el dato elemental en la
Base de Datos multidimensional (MDDB), se realizan una serie de clculos en batch, para
calcular los datos agregados, a travs de las dimensiones de negocio, rellenando la
estructura MDDB. Tras rellenar esta estructura, se generan unos ndices y algoritmos de
tablas hash para mejorar los tiempos de accesos a las consultas.
Una vez que el proceso de compilacin se ha acabado, la MDDB est lista para su uso.
Los usuarios solicitan informes a travs del interface, y la lgica de aplicacin de la
MDDB obtiene el dato. La arquitectura MOLAP requiere unos clculos intensivos de
compilacin. Lee de datos precompilados, y tiene capacidades limitadas de crear
agregaciones dinmicamente o de hallar ratios que no se hayan precalculados y
almacenados previamente.
Algunos fabricantes son: Oracles Hyperion Essbase, Microsoft Analysis Services, TM1,
SAS OLAP, Cognos PowerCubes.
Hybrid OLAP (HOLAP): plataformas que usan una combinacin de varias tcnicas de
almacenamiento. Las agregaciones se realizan en cache, pero el drill-down a travs de la
base de datos relacional. Algunos fabricantes son: Microsoft Analysis Services, SAS
OLAP, Oracles Hyperion Essbase.
Dynamic OLAP (DOLAP): generan una pequea cache multidimensional cuando los
usuarios ejecutan las consultas contra la base de datos. Algunos fabricantes son:
BusinessObjects Web Intelligence, Oracles Hyperion Interactive Reporting (formerly
Brio).

1.4.2. Tipos de Sistemas OLAP

Tradicionalmente, los sistemas OLAP se clasifican segn las siguientes categoras:
ROLAP
Implementacin OLAP que almacena los datos en un motor relacional. Tpicamente, los
datos son detallados, evitando las agregaciones y las tablas se encuentran normalizadas
MOLAP
Esta implementacin OLAP almacena los datos en una base de datos multidimensional.
Para optimizar los tiempos de respuesta, el resumen de la informacin es usualmente
calculado por adelantado.
HOLAP (Hybrid OLAP)
Almacena algunos datos en un motor relacional y otros en una base de datos
multidimensional.

1.4.3. ROLAP vs. MOLAP (Comparativa)

Cuando se comparan las dos arquitecturas, se pueden realizar las siguientes
observaciones:
El ROLAP delega la negociacin entre tiempo de respuesta y el proceso batch al diseo
del sistema. Mientras, el MOLAP, suele requerir que sus bases de datos se precompilen
para conseguir un rendimiento aceptable en las consultas, incrementando, por tanto los
requerimientos batch.

Los sistemas con alta volatilidad de los datos (aquellos en los que cambian las
reglas de agregacin y consolidacin), requieren una arquitectura que pueda
realizar esta consolidacin ad-hoc. Los sistemas ROLAP soportan bien esta

consolidacin dinmica, mientras que los MOLAP estn ms orientados hacia

consolidaciones batch.

Los ROLAP pueden crecer hasta un gran nmero de dimensiones, mientras que
los MOLAP generalmente son adecuados para diez o menos dimensiones.

Los ROLAP soportan anlisis OLAP contra grandes volmenes de datos

elementales, mientras que los MOLAP se comportan razonablemente en
volmenes ms reducidos (menos de 5 Gb).

Por ello, y resumiendo, el ROLAP es una arquitectura flexible y general, que crece
para dar soporte a amplios requerimientos OLAP. El MOLAP es una solucin
particular, adecuada para soluciones departamentales con unos volmenes de
informacin y nmero de dimensiones ms modestos.

1.4.4. Objetivo principal de Cubos OLAP

Es ofrecer a los usuarios una solucin que permite agilizar de manera notable las
consultas y evaluaciones de la gran cantidad de datos que produce constantemente una
compaa, utilizando informacin proveniente de todos los sectores de la misma, que
confluye en un sistema central.
Es por ello, que la velocidad de respuesta que ofrece OLAP hace que las soluciones a los
posibles

problemas

surgidos

durante

los

procesos

productivos,

las

posteriores decisiones gerenciales, tengan lugar en tiempo y forma precisa.

1.5.

SISTEMAS DE SOPORTE DE DESICIONES

Un DSS es un sistema informtico que utiliza informacin y modelos matemticos para

ayudar a los trabajadores de la informacin a tomar decisiones empresariales adecuadas
segn las condiciones del mercado y la situacin interna de la compaa.

El trmino DSS es el acrnimo de "Decision Support System", es decir, se refiere a los

sistemas para el apoyo a la toma de decisiones. Se trata de un trmino que se populariz
a mediados de los 90 pero que sin embargo ha cado en desuso con la misma facilidad
con la que se populariz.
Un DSS es un sistema, es decir, no es una herramienta, ni un software, ni un concepto ni
una metodologa. Es un sistema. Y qu es un sistema?. Un sistema es un conjunto de
componentes relacionados entre s que contribuyen a un determinado objetivo. Un
sistema se caracteriza habitualmente a travs de sus entradas y salidas, y su resultado
se ve afectado por las condiciones externas al sistema, y por parmetros internos del
mismo.
Pues bien, exactamente esta definicin es aplicable para referirse al trmino DSS. Un
DSS es un sistema informtico que utiliza informacin y modelos matemticos para
ayudar a los trabajadores de la informacin a tomar decisiones empresariales adecuadas
segn las condiciones del mercado y la situacin interna de la compaa.
Como sabemos, en el da a da de las empresas se toman continuamente decisiones de
muy distinto tipo, y de manera muy diferente. Existen decisiones que por su naturaleza se
toman de manera racional y absolutamente informada, y otras que se toman de manera
menos sistemtica, casi por instinto.

1.5.1. Clasificacin de DSS

Diferentes autores proponen diferentes clasificaciones, por tanto utilizaremos varios
criterios para dividirlas:
Segn relacin con el usuario

DSS pasivo: Es un sistema de ayudas para el proceso de toma de decisiones,

pero que no puede llevar a cabo una decisin explcita sugerencias o soluciones.

DSS activo: Puede aportar a cabo dicha decisin sugerencias soluciones.

DSS cooperativo: Permite la toma de decisiones, modificar, completar o

perfeccionar las sugerencias de decisin proporcionadas por el sistema, antes de
enviar de vuelta al sistema para su validacin. 7

Segn el modo de asistencia

DSS dirigidos por modelos: Utiliza datos y parmetros proporcionados por los
usuarios para ayudar a los encargados de adoptar decisiones en el anlisis de
una situacin, que no son necesariamente los datos intensivos.

DSS dirigidos por comunicacin: Disponen de soporte para varias personas

que trabajan en una misma tarea compartida.

DSS dirigidos por datos: Tambin llamados orientados por datos, enfatizan el
acceso y la manipulacin de series temporales de datos internos de la empresa y,
a veces, tambin de datos externos.

DSS dirigidos por documentos: Gestionan, recuperan y manipulan informacin

no estructurada en una variedad de formatos electrnicos.

DSS dirigidos por conocimiento: Proporcionan experiencia acumulada en forma

de hechos, normas, procedimientos, o en estructuras similares especializados
para la resolucin de problemas. 8

Segn el mbito

DSS para la gran empresa: Este DSS estar enlazado con un almacn de datos
de gran tamao y dar servicio a muchos gerentes, directores y/o ejecutivos de la
compaa.

DSS de escritorio: Es un sistema pequeo que puede correr en el ordenador

personal de un gerente al que da servicio (un solo usuario).

1.5.2. Funciones

Permiten resolver gran parte de las limitaciones de los programas de gestin.

Permiten extraer y manipular informacin de una manera flexible.

Permiten al usuario definir interactivamente qu informacin necesita y cmo

combinarla.

Suelen incluir herramientas de simulacin.

Pueden combinar informacin de los sistemas internos de la empresa con los de

otra empresa externa.

1.5.3. Tipos de DSS

Sistemas de apoyo a decisiones de grupo (GDSS): es un sistema que apoya a

grupos de personas que tienen un objetivo comn.

Sistemas de informacin gerencial (MIS): Tambin llamados Sistemas de

Informacin Administrativa (AIS). Dan soporte a un sector ms amplio de tareas
organizacionales.

Sistemas de informacin ejecutiva (EIS): Son el tipo de DSS que ms se usa

en Business Intelligence, ya que proveen a los gerentes de un acceso sencillo a
informacin interna y externa de su compaa.

Sistemas expertos basados en inteligencia artificial (SSEE): los sistemas

expertos simulan el conocimiento de un experto y lo utilizan de forma efectiva para
resolver un problema concreto.

1.5.4. Componentes
Diferentes autores identifican diferentes componentes principales para un DSS. En
cualquier caso cada sistema SSD consiste de al menos de los subsistemas de datos,
interface de usuario, y de administracin del modelo, as como tambin de los
usuarios.

El subsistema de datos del SSD est compuesto de la base de datos del SSD, del
sistema de administracin de la base de datos, del directorio de datos y de la facilidad
para hacer consultas.

El subsistema de administracin del modelo del SSD comprende:

o

La base de modelo.

El sistema de administracin de la base de modelo.

El lenguaje de modelacin.

El directorio del modelo.

El procesador de comandos, integracin y ejecucin del modelo.

El subsistema de interface de usuario incluye:

o

El hardware y el software.

Factores

involucrados

con

la

facilidad

de

uso,

accesibilidad,

interacciones humano-mquina.

El usuario o gerente es la persona que tiene que tomar la decisin que pretende
ser soportada por el SSD.

Los sistemas ms complejos adaptan otros componentes como el subsistema de

administracin del conocimiento, as como tambin mdulos hechos a la
medida para la resolucin de problemas especficos.

1.6.

HERRAMIENTAS PARA SISTEMAS DE SOPORTE DE DECISIONES

1.6.1. Herramientas Propietarias

A continuacin se describen y se muestra la arquitectura de las plataformas BI
propietarias ms relevantes:

COGNOS: Proveedor de tecnologa y servicios para el

Business Intelligence (BI) y la Gestin del Rendimiento,
ofrece una plataforma basada en estndares abiertos
para generacin reportes, anlisis y scorecards que se
integran con los presupuestos, planes, proyecciones e
informes financieros conducidos por finanzas.

Figura 17. Arquitectura BI de IBM Cognos.

Fuente: (IBM, 2009)

La plataforma Business Intelligence de Microsoft

comprende aplcaciones de servidor, cliente y
programador. Est basada en Microsoft SQL Server
2008, que incluye administracin de bases de datos
relacionales, SQL Server Integration Services, SQL
Server Analysis Services, SQL Server Reporting
Services y las capacidades de anlisis de datos
SQL Server Data Mining y est integrada con la
plataforma de desarrollo Microsoft Visual Studio
2008 y con Microsoft Office 2007.

Figura 18. Arquitectura BI de Microsoft.

Fuente: (Microsoft, 2009)

ORACLE BUSINESS INTELLIGENCE SUITE

ENTERPRISE EDITION (OBIEE):
Integra tecnologa de Siebel con Oracle Fusion
Middleware. Incluye: consulta y anlisis relacional y
OLAP de entornos Oracle y de otros proveedores,
herramientas de anlisis y consulta ad-hoc,
dashboards analticos, creacin de informes y
herramientas de publicacin, alertas en tiempo
real, capacidades analticas para dispositivos
mviles e integracin con las herramientas de
escritorio de Microsoft.

Figura 19. Arquitectura BI de OBIEE.

Fuente: (ORACLE, 2009)

La empresa SAP compr en el 2008 a Business

Object, convirtindose en un fuerte competidor de
tecnologas de inteligencia de negocios. Suministra
a los usuarios el poder acceder de forma sencilla a
los datos, analizar la informacin almacenada y
creacin de informes.

Figura 20. Arquitectura BI de SAP BusinessObjects XI 3.1.

Fuente: (SAP, 2009)

MICROSTRATEGY provee soluciones a clientes de

cualquier industria y/o rea funcional con el fin de
ayudarlos en la obtencin de un mayor
conocimiento sobre la informacin manejada en su
empresa.

Figura 21. Arquitectura BI de Microstrategy

Fuente: (Microstrategy, 2009)

SAS provee una Plataforma de Inteligencia abierta

y extensible que sirve de base para la creacin y
entrega de inteligencia a la organizacin; incluye
herramientas: ETL para extraccin, transformacin
y carga independiente a la plataforma; Intelligence
Storage para distribuir informacin a aplicaciones
de BI y analticas desde SAS o terceros; SAS
Enterprise BI Server brinda acceso a la informacin
en diferentes formatos; SAS Analytic Technologies
para manejo y modelacin de informacin analtica,
algortmica y matemtica.

Figura 22. Arquitectura BI de SAS

Fuente: (SAS, 2009)

1.6.2. Herramientas OPEN SOURCE

El software libre dispone al da de hoy de casi todas las herramientas necesarias para el
trabajo informtico. Incluso hay campos en donde su supremaca no se discute y ni
siquiera se contempla la posibilidad de usar otro tipo de software.
En el informe de investigacin Magic Quadrant for Business Intelligence Platforms
presentado por la empresa Gartner en enero del 2009, que trata de un estudio de
mercado de las plataformas de inteligencia de negocios a nivel mundial, dio seria
consideracin a la inclusin de proveedores de cdigo abierto de BI; pero an no generan
los suficientes ingresos para su visualizacin en el Magic Quadrant; sin embargo,
destacan la presencia en el mercado a Jaspersoft y Pentaho.
A continuacin se describen los productos open source ms relevantes para BI:

Pentaho es la solucin BI Open Source lder del

mercado y la mejor alternativa a los productos
comerciales. La plataforma ser capaz de ejecutar
las reglas de negocio necesarias, expresadas en
forma de procesos y actividades y de presentar y
entregar la informacin adecuada en el momento
adecuado, mediante anlisis OLAP, Cuadros de
Mando, etc

Figura 23. Arquitectura BI de Pentaho

Fuente: (Pentaho, 2009)

JasperSoft a travs de su plataforma de BI en

cdigo abierto JasperIntelligence proporciona
productos
propios
actualizados
como:
JasperAnalysis,
JasperReports,
iReports,
JasperETL y JasperServer. JasperAnalysis,
diseado para proporcionar a las empresas
medianas anlisis online en tiempo real de
grandes volmenes de datos. JasperServer,
dirigido a la integracin de fuentes de datos y otros
servicios, aporta funciones como scheduling y
control de la seguridad de acceso de los usuarios.
JasperReports e iReport incluyen un plug-in para
JasperServer. JasperSoft ofrece sus productos sin
coste y licencias comerciales que incluyen soporte
y servicios.

Figura 24. Arquitectura BI de JasperSoft

Fuente: (JasperSoft, 2009)

Actuate es una empresa que figura en el

cuadrante mgico y es miembro del proyecto
Eclipse Business Intelligence and Reporting Tools
(BIRT) ofrece un conjunto de herramientas open
source para desarrollar cuadros de mando y
gestor de informes avanzados, entre sus mdulos
destacan: BIRT Report DesignerProf, BIRT Chart
Engine SDK, BIRT Report Engine.

Figura 25. Arquitectura BI de Eclipse BIRT

Fuente: (BIRT, 2009)

La firma alemana Jedox presenta Palo como una

plataforma de cdigo abierto para soluciones BI
basado en la planificacin, anlisis y presentacin
de informes. Las soluciones que provee PALO
son: Indicadores de rendimiento clave (KPI),
Gestin de liquidez y Previsin, Presupuesto y
Planificacin y Balanced Scorecards, Cockpits,
Dashboards. Las herramientas que integran esta
plataforma son: Palo OLAP Server, Palo ETL
Server, Palo Supervision Server, Palo WorkSheet
Server y Open-API

Figura 26. Arquitectura BI de Palo

Fuente: (Palo, 2009)

Openi es una aplicacin de Inteligencia de Negocios,

diseado para el uso basado en la web. Basado en J2EE y
sus aplicaciones corren sobre Apache Tomcat, OpenI es
una solucin para la construccin y publicacin de
informes de XMLA compatible con fuentes de datos OLAP,
como Microsoft Analysis Services o Mondrian. Su objetivo
es proporcionar anlisis consolidado de los principales
componentes de datos de una aplicacin inteligente,
incluyendo: fuentes de datos OLAP, bases de datos
relacionales, modelos de datos estadsticos y modelos de

minera de datos.

Figura 27. Arquitectura BI de Openi

Fuente: (Openi, 2009)

CAPTULO II
ETAPA DE ANLISIS,
DISEO E IMPLEMENTACIN
DEL SISTEMA DE SOPORTE DE
DECISIONES

2.1 METODOLOGA UTILIZADA PARA EL DISEO DEL DATA WAREHOUSE

Segn el estudio realizado, existen muchas metodologas de diseo y construccin de
DW. Cada fabricante de software de inteligencia de negocios busca imponer una
metodologa con sus productos.

En los ltimos aos se han propuesto distintas

metodologas para el diseo de Almacenes de Datos (AD) o Data Warehouse (DW),

aunque ninguna de ellas ha sido aceptada plenamente.
En algunos casos, las metodologas son extensiones de las metodologas clsicas para
bases de datos, en otros casos se ha adoptado un enfoque completamente nuevo.
Intentando analizar el trabajo hecho hasta el momento en el rea del diseo, las
propuestas metodolgicas pueden clasificarse en tres grupos: metodologas dirigidas por
datos, metodologas dirigidas por procesos y metodologas compuestas (datos-procesos).
El objetivo de las metodologas dirigidas por datos es obtener el esquema conceptual del
AD a partir de la descripcin de las bases de datos operacionales de la organizacin, por
el contrario, las metodologas dirigidas por procesos derivan el esquema conceptual del
AD a partir de los requisitos de usuario. Finalmente, las metodologas compuestas
realizan una combinacin de las dos aproximaciones anteriores, es decir, consideran los
requisitos de usuario as como la descripcin de la base de datos operacional. A
continuacin se citan algunas:

Metodologa de Kimball. Kimball fue quien determin que un data warehouse no era
ms que: "la unin de todos los Data marts de una entidad". Defiende por tanto una
metodologa ascendente (bottom-up) a la hora de disear un almacn de datos.

Figur28 Arquitectura bottom-up a de un DW

(Bernabeu, 2010)

Metodologa de Immon. Inmon defiende una metodologa descendente (top-down) a

la hora de disear un almacn de datos, ya que de esta forma se considerarn mejor

todos los datos corporativos. En esta metodologa los Data marts se crearn despus
de haber terminado el data warehouse completo de la organizacin.

Figura 29 Arquitectura top-down de un DW

(Bernabeu, 2010)

Model Driven Architecture 2.0 (MDA 2.0). Desarrollado por The Object
Management Group (OMG). Consiste en un conjunto de estndares que asisten en
la creacin, implementacin, evolucin y desarrollo de sistemas dirigido por modelos.
Los estndares que constituyen MDA son: Lenguaje Unificado de Modelado (UML),
Meta-Object-Facility (MOF), Meta-Data Interchange

(XMI) y Common Warehouse

Metamodel (CWM).

Multidimensional Fact Model (DFM) propuesta por Golfarelly, M. y Dario. Permite

hacer una representacin de los hechos y dimensiones con una notacin grfica
propia, adems proponen una metodologa semiautomtica para obtener un esquema
multidimensional a partir de un diagrama Entidad Relacin (ER). Un esquema en DFM
se define como una coleccin de esquemas de hechos, cuyos elementos bsicos son
los hechos, los atributos, las dimensiones y las jerarquas.

Modelo Multidimensional (MD). Cabibbo y Torlone proponen el mtodo de diseo

MD, que definen como un modelo lgico para sistemas OLAP, sin embargo los
autores mencionan que es independiente de cualquier implementacin, por lo que lo
ubican en el nivel conceptual. El mtodo de diseo que proponen construye un
esquema MD a partir de una base de datos operacional existente, el esquema MD
consiste de un conjunto finito de Dimensiones y un conjunto finito de F-Tables
(Hechos), donde las dimensiones son categoras sintcticas que permiten especificar
mltiples caminos para la bsqueda de informacin y cada dimensin se organiza en
una jerarqua de niveles correspondientes.

Metodologa HEFESTO.

Propuesta por Bernabu D. Es una metodologa

fundamentada en metodologas existentes y experiencias propias del autor respecto

al proceso de confeccin de almacenes de datos. La construccin e implementacin
de un DW puede adaptarse muy bien a cualquier ciclo de vida de desarrollo de
software, con la salvedad de que para algunas fases en particular, las acciones que
se han de realizar sern muy diferentes. Lo que se debe tener muy en cuenta, es no
entrar en la utilizacin de metodologas que requieran fases extensas de reunin de
requerimientos y anlisis, fases de desarrollo monoltico que conlleve demasiado
tiempo y fases de despliegue muy largas. Lo que se busca, es entregar una primera
implementacin que satisfaga una parte de las necesidades, para demostrar las
ventajas del DW y motivar a los usuarios.
Existen otras metodologas para el diseo de Data Warehouse, sin embargo se ha
elegido la metodologa HEFESTO, debido a que define claramente el Qu? Y el
Cmo? de cada una de sus fases y actividades.

2.2 METODOLOGA HEFESTO

Permitir la construccin de Data Warehouse de forma sencilla, ordenada e intuitiva. Su
nombre fue inspirado en el dios griego de la construccin y el fuego, y su logotipo es el
siguiente:

Figura 30 Logo Metodologa HEFESTO

(Bernabeu, 2010)

HEFESTO es una metodologa propia, cuya propuesta est fundamentada en una muy
amplia investigacin, comparacin de metodologas existentes, experiencias propias en
procesos de confeccin de almacenes de datos. Cabe destacar que HEFESTO est en
continua evolucin, y se han tenido en cuenta, como gran valor agregado, todos los
feedbacks que han aportado quienes han utilizado esta metodologa en diversos pases y
con diversos fines.

La idea principal, es comprender cada paso que se realizar, para no caer en el tedio de
tener que seguir un mtodo al pie de la letra sin saber exactamente qu se est
haciendo, ni por qu.
A continuacin se presenta la arquitectura de la metodologa y se la describe
brevemente:

Figura 31 Metodologa HEFESTO pasos

(Bernabeu, 2010)
Como se puede apreciar, se comienza recolectando las necesidades de informacin de
los usuarios y se obtienen las preguntas claves del negocio. Luego, se deben identificar
los indicadores resultantes de los interrogativos y sus respectivas perspectivas de
anlisis, mediante las cuales se construir el modelo conceptual de datos del DW.

Despus, se analizarn los OLTP para determinar cmo se construirn los indicadores,
sealar las correspondencias con los datos fuentes y para seleccionar los campos de
estudio de cada perspectiva.
Una vez hecho esto, se pasar a la construccin del modelo lgico del depsito, en
donde se definir cul ser el tipo de esquema que se implementar. Seguidamente, se
confeccionarn las tablas de dimensiones y las tablas de hechos, para luego efectuar sus
respectivas uniones.
Por ltimo, utilizando tcnicas de limpieza y calidad de datos, procesos ETL, etc, se
definirn polticas y estrategias para la Carga Inicial del DW y su respectiva actualizacin.

2.3 ANLISIS DE REQUERIMIENTOS

Lo primero que se har ser identificar los requerimientos del usuario a travs de
preguntas que expliciten los objetivos de la organizacin. Luego, se analizarn las estas
preguntas a fin de identificar cules sern los indicadores y perspectivas que sern
tomadas en cuenta para la construccin del DW. Finalmente se confeccionar un modelo
conceptual en donde se podr visualizar el resultado obtenido en este primer paso.
a) Identificar preguntas
El objetivo principal en esta fase, es el de obtener e identificar las necesidades de
informacin clave para la organizacin la cual ser de vital importancia para llevar a cabo
las metas y estrategias de la misma, permitindoles tomar una eficaz y eficiente toma de
decisiones.
Aplicando al caso de estudio. A continuacin se narra los procesos ms importantes que
la empresa Data Mart tiene en consideracin para la toma de decisiones empresariales.

DESCRIPCIN DE PROCESOS PARA LA TOMA DE DECISIONES EMPRESARIALES

DE DATA MART

La empresa Data Mart est estructurada en departamentos o reas: Gerencia, Departamento

Contable/financiero, Compras, Ventas, Limpieza, Servicio Tcnico, Bodega y Sistemas. El gerente
es la persona encargada de la supervisin de los departamentos que existen en la entidad
financiera.
El rea de Contable /Financiero es el encargado de llevar la contabilidad de la empresa como
ingresos, egresos, el inventario, etc. El departamento de Compras es el encargado de llevar un
control de los productos nuevos que ingresan a la empresa, costos, fecha de ingreso, etc. El
encargado de Ventas es el responsable de llevar las estadsticas de las ventas que se realizan y
hacer un reporte de las mismas.
Dependiendo de la utilidad en ventas (monto y el %) el gerente toma decisiones como si se
realizan compras de productos, adquisicin de nueva mercadera.

Preguntas identificadas:
-

Se cuenta con estadsticas de la cantidad de ventas realizadas en la empresa?

Se cuenta con estadsticas de egresos e ingresos a la entidad financiera?

Se cuenta con estadstica del costo total de las compras realizadas

trimestralmente?

Se cuenta con estadstica del monto total de ventas realizadas anuales?

Es posible detallar el nmero de ventas realizadas segn la forma de pago de la

misma?

Es posible presentar la informacin en grficos estadsticos?

Es posible la generacin de informes en formato PDF, Excel y HTML?

Para el desarrollo el prototipo de este sistema, se ha considerado centrar el

estudio en el mbito financiero y especficamente en informacin de ventas,
compras y la utilidad de ventas realizadas en la empresa.

2.4 ANLISIS DE LOS INDICADORES DEL NEGOCIO

2.4.1 Identificar indicadores y perspectivas de anlisis
Una vez que se han establecido las preguntas claves, se debe proceder a su
descomposicin para descubrir los indicadores que se utilizarn y las perspectivas de
anlisis que intervendrn. Los indicadores deben ser realmente efectivos y por lo general
son valores numricos. En cambio, las perspectivas se refieren a los objetos mediante los
cuales se quiere examinar los indicadores, con el fin de responder a las preguntas
planteadas.
Aplicando al caso de estudio. De entrevistas realizadas al personal administrativo se
obtuvo un listado de los reportes que ms prioridad tienen:
-

Utilidad en ventas (monto y el %) que tiene la empresa mensual, trimestral,

semestral o anual.

Monto total de ventas realizadas en un periodo de tiempo dado ya sea mensual,

trimestral, semestral o incluso anual.

Cantidad vendida segn la marca o lnea el producto.

Costo de compra realizada mensual, trimestral, semestral o anual.

Cantidad vendida de un producto segn la ciudad de procedencia del cliente.

Ejemplo de anlisis de indicadores y perspectivas:

Utilidad en ventas (monto y el %),
Monto total de ventas, cantidad
vendida, costo de compra.

Indicador

Indicadores:
-

Utilidad en ventas

Monto total de ventas

Cantidad vendida

Costo de compra

por mes, trimestre, semestre, ao,

cliente,
producto,
ciudad
de
procedencia del cliente, lnea,
marca, forma de pago (contado,
crdito).
Perspectivas

Perspectiva de Anlisis:
-

Mes

Trimestre

Semestre

Ao

Cliente

Producto

Ciudad de procedencia del cliente

Lnea

Marca

Forma de pago (contado, crdito)

2.4.1.1

Indicadores

Utilidad en Ventas
La utilidad en ventas se la realiza una vez que se determina el valor de las ventas netas
que ha realizado la empresa y el costo de lo que se ha vendido, es as que se la
determina restando de las ventas netas y el valor del costo de lo vendido.
Monto total de ventas
El monto total de las ventas se lo determina mediante los clculos de las ventas
realizadas ya sean al contado, como a crdito para luego poder obtener el presupuesto
de las ventas que se han realizado.
Cantidad vendida
Es el nmero de productos que se han vendidos a los clientes de la empresa Data Mart.
Costo de compra
El costo de compra se lo conoce como un gasto que representa la entrada de nuevos
productos a la empresa, con el fin de generar ingresos a la organizacin.

2.5 DISEO DEL DATAMART DE VENTAS DE LA EMPRESA

Data Warehouse nos permite la integracin de datos corporativos en un nico depsito
donde los usuarios puedan consultar o analizar los datos para la toma de decisiones.

El diseo del Datamart que se puede apreciar en la imagen es el que se hizo para la
empresa DATAMARKET.

Figura 32 Modelo Lgico del DW SISTEMA DE SOPORTE DE DECISIONES

Fuente: Elaboracin propia

2.6 DISEO DE LOS PROCESOS EXTRACCIN, TRANSFORMACIN Y

CARGA (ETL)
El diseo del proceso ETL para la empresa est orientado a todas las actividades
necesarias relacionadas a la administracin de datos y metadatos para satisfacer las
necesidades de informacin.

Figura 33 Proceso Extraccin, Transformacin y Carga (ETL) al DW del sistema de SOPORTE DE

DECISIONES
Fuente: Elaboracin propia

Creacin de la dimensin Cliente

Se realiza el proceso de extraccin de datos de la base del sistema actual con el que
cuenta la empresa, para luego transformarlos y cargarlos en el datawarehouse del
sistema de Soporte de Decisiones.
SELECT
SujCodigo AS cli_codigo,
SujNombre AS cli_nombre, SujCodZona AS ciu_codigo
FROM
Sujetos
WHERE
(SujClienteProveedor = 'CLIE')

Creacin de la dimensin Provincia

Se hace un traspaso de los datos de las provincias que estn almacenadas en la base de
datos del sistema actual, al datawarehouse del Sistema de Soporte de Decisiones.
SELECT
FROM
WHERE

ZonCodigo AS pro_codigo, ZonDescripcion AS pro_nombre

Zonas
(LEN(ZonCodigo) <= 2)

Creacin de la dimensin Ciudad

Se ejecuta el proceso de extraccin de datos de la base del sistema actual que tiene la
empresa, para luego tranformarlos y cargarlos datawarehouse del sistema de Soporte de
Decisiones.
SELECT
b.ZonCodigo AS ciu_codigo, b.ZonDescripcion AS ciu_nombre,
LEFT(a.ZonCodigo, 2) AS pro_codigo

FROM
Zonas b INNER JOIN Zonas a ON b.ZonCodigo = a.ZonCodigo
WHERE
(LEN(b.ZonCodigo) = 4)
ORDER BY b.ZonDescripcion;

Creacin de la dimensin Lnea

Se hace un traspaso de los datos de lnea del producto que estn almacenadas en la
base de datos del sistema actual, al datawarehouse del Sistema de Soporte de
Decisiones.
SELECT LinCodigo AS lin_codigo, LinDescripcion AS lin_nombre
FROM
Lineas

Creacin de la dimensin Marca

Se hace un traspaso de los datos de marca del producto que estn almacenadas en la
base de datos del sistema actual, al datawarehouse del Sistema de Soporte de
Decisiones.
SELECT
FROM
WHERE

ParCodigo AS mar_codigo, ParDescripcion AS mar_nombre

Parametros
(ParTipo = 'MAR')

Creacin de la dimensin Marca

Se realiza el proceso de extraccin de la informacin que esta almacenada en la base de
datos del sistema actual, acerca de las los producto que ofrece la empresa, para
transformarla y cargarla al datawarehouse del sistema propuesto.
SELECT
ArtCodigo AS pro_codigo, ArtDescripcion AS pro_nombre, ArtMarca AS
mar_codigo, ArtLinea AS lin_codigo
FROM
Articulos

Creacin de la dimensin Ventas

Se realiza el proceso de extraccin de la informacin que esta almacenada en la base de
datos del sistema actual, acerca de las ventas realizadas para transformarla y cargarla al
datawarehouse del sistema propuesto.
SELECT CabMovInventarios2010.CMIFecha AS fecha,
CabMovInventarios2010.CMICodSujeto AS cli_codigo,
DetMovInventarios2010.DMICodArticulo AS pro_codigo,
DetMovInventarios2010.DMICantidad AS monto_venta,
DetMovInventarios2010.DMICostoMercaderia AS costo_unitario,
DetMovInventarios2010.DMIPrecio AS PUV,
DetMovInventarios2010.DMICostoMercaderia *
DetMovInventarios2010.DMICantidad AS CostoTotal,

DetMovInventarios2010.DMICantidad *
DetMovInventarios2010.DMIPrecio AS VentaTotal,
DetMovInventarios2010.DMICantidad *
DetMovInventarios2010.DMIPrecio - DetMovInventarios2010.DMICostoMercaderia *
DetMovInventarios2010.DMICantidad
AS Utilidad
FROM
CabMovInventarios2010 INNER JOIN
DetMovInventarios2010 ON CabMovInventarios2010.CMINumero =
DetMovInventarios2010.DMINumero
WHERE
(DetMovInventarios2010.DMICodTipo = '55')
UNION
SELECT
CabMovInventarios2011.CMIFecha AS fecha,
CabMovInventarios2011.CMICodSujeto AS cli_codigo,
DetMovInventarios2011.DMICodArticulo AS pro_codigo,
DetMovInventarios2011.DMICantidad AS monto_venta,
DetMovInventarios2011.DMICostoMercaderia AS costo_unitario,
DetMovInventarios2011.DMIPrecio AS PUV,
DetMovInventarios2011.DMICostoMercaderia *
DetMovInventarios2011.DMICantidad AS CostoTotal,
DetMovInventarios2011.DMICantidad *
DetMovInventarios2011.DMIPrecio AS VentaTotal,
DetMovInventarios2011.DMICantidad *
DetMovInventarios2011.DMIPrecio - DetMovInventarios2011.DMICostoMercaderia *
DetMovInventarios2011.DMICantidad
AS Utilidad
FROM
CabMovInventarios2011 INNER JOIN
DetMovInventarios2011 ON CabMovInventarios2011.CMINumero =
DetMovInventarios2011.DMINumero
WHERE
(DetMovInventarios2011.DMICodTipo = '55')
UNION
SELECT
CabMovInventarios2012.CMIFecha AS fecha,
CabMovInventarios2012.CMICodSujeto AS cli_codigo,
DetMovInventarios2012.DMICodArticulo AS pro_codigo,
DetMovInventarios2012.DMICantidad AS monto_venta,
DetMovInventarios2012.DMICostoMercaderia AS costo_unitario,
DetMovInventarios2012.DMIPrecio AS PUV,
DetMovInventarios2012.DMICostoMercaderia *
DetMovInventarios2012.DMICantidad AS CostoTotal,
DetMovInventarios2012.DMICantidad *
DetMovInventarios2012.DMIPrecio AS VentaTotal,
DetMovInventarios2012.DMICantidad *
DetMovInventarios2012.DMIPrecio - DetMovInventarios2012.DMICostoMercaderia *
DetMovInventarios2012.DMICantidad
AS Utilidad
FROM
CabMovInventarios2012 INNER JOIN
DetMovInventarios2012 ON CabMovInventarios2012.CMINumero =
DetMovInventarios2012.DMINumero
WHERE
(DetMovInventarios2012.DMICodTipo = '55');

2.7 DISEO DE LOS CUBOS OLAP

El diseo de los cubos OLAP proporciona rpidamente informacin de resumen
agregada mediante un esquema que los usuarios finales pueden comprender con
facilidad. El diseo OLAP no requiere la "unin" de las tablas como en una base de datos
relacional e incluye todas las relaciones necesarias para permitir la ejecucin de un
conjunto de consultas especfico en la base de datos.

Para disear el cubo se ha utilizado una herramienta denominada Workbench, esta

herramienta permite disear fcilmente los cubos en formato XML estableciendo en
primera instancia la conexin con el data warehouse del sistema de Soporte de
Decisiones.
En la siguiente figura se muestra el cubo creado (Ventas), en este cubo se defini la tabla
de hechos, las dimensiones, la jerarqua y las medidas.

Figura 34 Diseo del Cubo OLAP del Sistema de Soporte de Decisiones

Fuente: Elaboracin propia

2.8 DISEO DEL SSD DE VENTAS

El diseo del SSD de Ventas es utilizado para servir de apoyo, ms que automatizar, el
proceso de toma de decisiones. La decisin es una eleccin entre alternativas basadas
en estimaciones de los valores de esas alternativas. El apoyo a una decisin significa
ayudar a las personas que trabajan solas o en grupo a reunir inteligencia, generar
alternativas y tomar decisiones. Apoyar el proceso de toma de decisin implica el apoyo a
la estimacin, la evaluacin y/o la comparacin de alternativas.

2.8.1 Diagrama de casos de uso del sistema

Figura 35. Diagrama de casos de uso del sistema de SOPORTE DE DECISIONES

Fuente: Elaboracin propia

2.8.2 Diagrama de componentes basado en capas del sistema de SOPORTE

DE DECISIONES

Figura 36. Diagrama de componentes basado en capas del sistema de SOPORTE DE

DECISIONES
Fuente: Elaboracin propia

2.9 IMPLEMENTACIN DEL SSD.

2.9.1 Herramientas utilizadas.
La mayora de herramientas utilizadas son open source. A continuacin se presenta y se
describe cada herramienta utilizada.

mysql-5.0.45-win32. Es el servidor de bases de datos donde se almacena del

Data warehouse del sistema de Soporte de Decisiones.

mysql_yog. Esta herramienta es un FrontEnd que permite la gestin del servidor

de bases de datos.

apache-tomcat-6.0.18. Es el servidor web utilizado para aplicaciones JAVA.

jdk-6u10-windows-i586-p. Es el Kit de desarrollo de JAVA. Sirve de soporte para

que el servidor web Apache Tomcat ejecute aplicaciones JAVA.

Toad Data Modeler 3.6. Herramienta para crear diagramas Entidad-Relacin.

jpivot-1.8.0. Es el visor de los cubos que son administrados por un servidor

OLAP.

pentaho. Servidor de cubos OLAP y se integra a Jpivot.

mysql-connector-java-5.0.5-bin. Java Data Base Conectivity. Conector a bases

de datos Mysql desde aplicaciones Java.

workbench-2.3.2.9247. Herramienta para el diseo de cubos OLAP.

Spoon. Herramienta para el diseo del ETL (Extraccin, Transformacin y Carga)

de datos.

2.9.2 Interfaces del Software

A continuacin se muestran algunas pantallas del Sistema de Soporte de Decisiones:
Pantalla de Inicio al Sistema de Soporte de Decisiones

Figura 37 Pantalla de inicio al sistema de soporte de decisiones

Fuente: Sistema de Soporte de Decisiones

Estadstica General de los Datos de Ventas

Obtencin de los indicadores que se tomaron para la realizacin del sistema de soporte
de decisiones.

Figura 38 Estadstica General de los Datos de Ventas

Fuente: Sistema de Soporte de Decisiones

Codigo MDX de las estadisticas generales de las ventas

select NON EMPTY {[Measures].[Monto], [Measures].[CostoUnitario], [Measures].[CostoTotal],
[Measures].[PrecioUnitario], [Measures].[PrecioTotal], [Measures].[Utilidad],
[Measures].[PorcentajeUtilidad]} ON COLUMNS,
NON EMPTY {([Anio].[All Anios], [Producto].[All Productos], [Linea].[All Lineas],
[Marca].[All Marcas], [Cliente].[All Clientes], [Ciudad].[All Ciudads])} ON ROWS
from [Ventas]

Utilidad de Ventas por Ao

Figura 39 Utilidad de Ventas por Aos

Fuente: Sistema de Soporte de Decisiones

Cdigo MDX de los datos de utilidad de ventas por aos.

select NON EMPTY {[Anio].[2010], [Anio].[2010].[Semestre 1], [Anio].[2010].[Semestre 2],
[Anio].[2011], [Anio].[2011].[Semestre 1], [Anio].[2011].[Semestre 2], [Anio].[2012],
[Anio].[2012].[Semestre 1], [Anio].[2012].[Semestre 2]} ON COLUMNS,
NON EMPTY {[Measures].[Utilidad]} ON ROWS from [Utilidad_Anios]

Exportacin a Formato PDF

Figura 40 Utilidad de Ventas por Aos en formato PDF

Fuente: Sistema de Soporte de Decisiones

Utilidad de ventas por Ao

Figura 41 Utilidad de un ao (2011)

Fuente: Sistema de Soporte de Decisiones

Cdigo MDX de Utilidad de un ao (2011).

select NON EMPTY [Anio].[2011].Children ON COLUMNS,
NON EMPTY {[Measures].[Utilidad]} ON ROWS from [Utilidad_Anios]

Monto Total de Ventas por aos

Figura 42 Monto Total de Ventas por aos

Fuente: Sistema de Soporte de Decisiones

Cdigo MDX del Monto Total de Ventas por aos

select NON EMPTY {[Anio].[All Anios], [Anio].[2010], [Anio].[2011], [Anio].[2012]} ON
COLUMNS, NON EMPTY {[Measures].[PrecioTotal]} ON ROWS from [Total_Ventas_Anios]

Exportacin a formato Excel

Figura 43 Monto Total de Ventas por aos en formato Excel .xls

Fuente: Sistema de Soporte de Decisiones

Monto Total de Ventas realizadas por aos segn Clientes

Figura 44 Monto Total de Ventas realizadas por aos segn Clientes

Fuente: Sistema de Soporte de Decisiones

Cdigo MDX del Monto Total de Ventas realizadas por aos segn clientes
select NON EMPTY {[Measures].[PrecioTotal]} ON COLUMNS,
NON EMPTY Crossjoin(Hierarchize(Union({[Anio].[All Anios]}, [Anio].[All Anios].Children)),
{[Cliente].[All Clientes]}) ON ROWS from [Ventas]

Monto Total de Ventas realizadas por aos segn Productos

Figura 45 Monto Total de Ventas realizadas por aos segn Productos

Fuente: Sistema de Soporte de Decisiones

Cdigo MDX del Monto Total de Ventas realizadas por aos segn Productos
select NON EMPTY {[Measures].[PrecioTotal]} ON COLUMNS,NON EMPTY
Crossjoin(Hierarchize(Union({[Anio].[All Anios]}, [Anio].[All Anios].Children)),
{[Producto].[All Productos]}) ON ROWS from [Ventas]