Módulo 1

Inteligencia de
Negocios
1. Introducción a los
SSD y a DW

1.1 Concepto de Business Intelligence

“Business Intelligence (BI) es un término genérico que incluye las

aplicaciones, infraestructura y herramientas y las mejores
prácticas que permiten el acceso y análisis de información para
mejorar y optimizar las decisiones y el desempeño”

(Gartner, http://www.gartner.com/it-glossary/business-
intelligence-bi, s.f.)

Introducción

El objetivo de Business Intelligence (BI), también conocida como

Inteligencia de Negocios en español, consiste en “apoyar de forma
sostenible y continuada a las organizaciones para mejorar su
competitividad, facilitando la información necesaria para la toma de
decisiones” (Cano, 2007, p. 22).

Howard Dresner, de Gartner, la reconocida empresa de consultoría en

tecnologías de la información fue quién utilizó por primera vez el concepto
de BI en el año 1989.

Casualmente, la definición más actualizada y apropiada del concepto la

podemos ubicar en el actual Glosario de Términos del Sitio Web de Gartner
(http://goo.gl/9bNho4, s.f.): “Business Intelligence (BI) es un término
genérico que incluye las aplicaciones, infraestructura y herramientas y las

1
mejores prácticas que permiten el acceso y análisis de información para
mejorar y optimizar las decisiones y el desempeño”.

En tanto, Olivia Parr Rud (2009) considera a BI como un conjunto de

teorías, metodologías, arquitecturas y tecnologías que transforman datos
en información útil y significativa para los objetivos de negocios. Así, BI
puede manejar grandes cantidades de datos desestructurados para ayudar
a identificar, desarrollar y crear nuevas oportunidades. BI, en definitiva,
permite interpretar los datos voluminosos de manera amigable, facilitando
el aprovechamiento de potenciales nuevas oportunidades, implementando
una estrategia efectiva que le provea una ventaja competitiva a la
empresa.

Las tecnologías de BI proporcionan vistas históricas y predictivas de las

operaciones comerciales de las compañías. Entre las funciones más
comunes de las tecnologías de BI podemos encontrar: reporting, OLAP,
minería de datos, entre otras.

Boris Evelson, de la consultora especializada Forrester Research, sostiene

que:
BI es un conjunto de metodologías, procesos, arquitecturas y
tecnologías que transforman los datos en información útil y
significativa tal que permite una toma de decisiones estratégica,
táctica y operativa más efectiva, con datos en tiempo real que le
posibilitan a una empresa superar de manera eficaz a sus demás
competidores en el mercado.

(http://goo.gl/oIeCU, 2008)

Ralph Kimball (2013) define que un sistema de BI debe satisfacer varios

requerimientos, entre los cuales podemos citar los siguientes:

 Debe hacer que la información sea fácilmente accesible.

 Debe presentar la información de manera consistente.

 Debe adaptarse al cambio.

 Debe presentar la información de manera oportuna.

 Debe ser un resguardo seguro que proteja los activos de

información.

 Debe servir como el fundamento autorizado y confiable para la

toma de decisiones.

2
  La comunidad de negocios debe aceptar al sistema de BI para que
sea exitoso.

Por otro lado, Ralph Kimball (2013) sostiene que estos dos últimos
requerimientos son los más críticos y frecuentemente los más
desatendidos por las organizaciones a la hora de implementar un sistema
de BI.

1.2 Evolución de los SSD

Historia

Si bien el término BI fue popularizado a partir de 1989, fue en el año 1958

cuando Hans Peter Luhn, investigador de IBM, definió a la inteligencia de
negocios haciendo referencia a “la capacidad de comprender las
interrelaciones de hechos presentados de una manera tal que guía la
acción hacia una meta deseada” (BCW, http://goo.gl/LEiSV0, 2012).

Incluso las primeras empresas de software especializadas en lo que hoy

denominamos BI surgen en la década de 1970, como por ejemplo:
Information Builders (1975) o SAS (1976).

Sin embargo, el término BI, tal como lo conocemos hoy, ha evolucionado

significativamente desde los originales Sistemas de Soporte de Decisión
(DSS, Decision Support Systems en inglés).

William Inmon (2005) sostiene que en la década de 1980 aparecieron los

Sistemas de Información Gerencial (MIS, Management Information
Systems en inglés); posteriormente, ya más conocidos como DSS, los
primeros MIS comenzaron a usarse como software para tomar decisiones.
Anteriormente, tanto los datos como las tecnologías existentes se usaban
exclusivamente para tomar decisiones operativas detalladas, y hasta
entonces ningún motor de bases de datos podía llegar a servir para
propósitos de procesamiento operacional/transaccional y analítico en
forma simultánea.

Los software MIS, que generalmente contaban con una interfaz de usuario
poco amigable, tampoco tenían grandes capacidades de modelado y
estaban más bien orientados a la integración de información para la toma
de decisiones.

3
Los Sistemas de Gestión de Bases de Datos (DBMS, Database Management
Systems en inglés) que surgieron en la década de 1970, verdaderamente
iniciaron una nueva era informática con el advenimiento del denominado
procesamiento transaccional en línea (OLTP, Online Transaction
Processing).

William Inmon (2005) alega que los primeros Almacenes de Datos (más
conocidos como Data Warehouses en inglés) nacen en 1983.

Tras la implementación de masivos sistemas operacionales/transaccionales

(OLTP, OnLine Transaction Processing en inglés), hacia el año 1985
surgieron los primeros sistemas de extracción de datos (ETL, Extract,
Transform and Load en inglés), que posibilitaban transferir datos hacia otra
base de datos o archivo. Estos programas de extracción comenzaron a ser
muy populares en su época ya que permitían que los análisis de
información para la toma de decisiones se ejecutaran sobre una base de
datos distinta, diferente de la que usaban los sistemas transaccionales u
operacionales. Naturalmente estos OLTP son fundamentales para la
operación exitosa de cualquier negocio.

Los DSS nacieron también en la década de 1980. Estos sistemas fueron

creados para asistir al proceso de toma decisiones y planificación; con
mayores capacidades de modelado y mejor interfaz de usuario que los
tradicionales MIS, pronto tuvieron un gran éxito y en pocos años
evolucionaron en sistemas multi-usuario, es decir, permitieron la toma de
decisiones en grupo.

Posteriormente, a comienzos de la década de 1990, nacen los Sistemas de

Información Ejecutivos (EIS, Executive Information Systems en Inglés),
software con capacidades adicionales para navegar sobre información más
detallada, extraordinarias interfaces y, sobre todo, intensivos en el acceso
a bases de datos integradas y unificadas, pero a la vez carentes, en muchos
casos, de herramientas avanzadas de modelado. Information Builders en
1991 anuncia su primer software EIS, pero es en 1992 cuando la empresa
MicroStrategy lanza al mercado el primer producto de software de BI
completo.

En los '90 también surgieron las herramientas de Minería de Datos (Data

Mining, en inglés) orientadas a la búsqueda de patrones y relaciones
ocultas en los datos. Gracias a la implementación de enormes Almacenes
de Datos (más conocidos como Data Warehouses en inglés) se podía
obtener conocimiento de grandes volúmenes de datos.

William Inmon (2005) menciona que a partir de 1994 surgieron otros

conceptos ligados a BI tales como las bases de datos multidimensionales

4
(OLAP), Exploration Warehouses, ODS, entre otros (conceptos que veremos
más adelante en esta misma unidad).

En definitiva, si bien el concepto actual de BI fue propuesto en 1989 por

Howard Dresner, fue recién a fines de la década de 1990 en que el
software BI logra gran inserción en las organizaciones hasta la actualidad.

Además, cabe destacar la impresionante convergencia de tecnologías

surgidas en las últimas dos décadas, tales como:

 La aparición de Internet, que posibilitó que el software BI estuviera

disponible a través de la visualización de información en un
navegador o browser.

 El concepto de Software como Servicio (SaaS, Software as a Service

en Inglés) y Computación en la Nube (Cloud Computing en Inglés)
que permitió disminuir drásticamente los costos de implementación
de grandes sistemas de BI, al contratar por usuario un abono
mensual.

 Bases de Datos In-Memory y Técnicas de Lógica Asociativa que le

proveen a los usuarios de BI la posibilidad de analizar grandes
cantidades de datos sin necesidad de generar costosas estructuras
analíticas por separado (como herramientas OLAP u otras);

 El boom de la tecnología Mobile a través de Smartphones y Tablets,

que logró que los usuarios BI pudieran trabajar muchas veces en
forma remota accediendo a información crítica del negocio para la
toma de decisiones en forma descentralizada;

 Big Data y la evolución hacia grandes volúmenes de datos desde

algunos terabytes hasta varios petabytes en único repositorio;

 Aplicaciones Analíticas: dada la gran proliferación de herramientas

de BI, algunas de ellas se focalizaron en especializarse en la gestión
de métricas o Indicadores Claves de Negocio (KPI, Key Performance
Indicator en Inglés) para determinadas industrias verticales; es
decir, BI para el sector finanzas, BI para el sector salud, BI para el
sector manufacturero, entre otras.

Evidentemente, esta convergencia tecnológica está generando una

constante evolución del software BI para adaptarse a nuevos
requerimientos de los usuarios, a nuevas tecnologías, a nuevas
metodologías y a nuevas formas de acceder a los datos.

5
1.3 Necesidades

Ralph Kimball (2013) considera que uno de los activos más importantes de
cualquier organización es su información. Este activo es casi siempre usado
para dos propósitos: la preservación de los registros
operativos/transaccionales y la toma de decisiones analítica.

Así, mientras los sistemas operacionales/transaccionales se ocupan de

incorporar datos a las bases de datos, los sistemas de BI, en cambio,
permiten explotar o visualizar esos datos convirtiéndolos en información
para la toma de decisiones.

Los usuarios de los sistemas operacionales/transaccionales son los que

realmente mueven las ruedas de la organización (generando solicitudes,
dando de alta clientes y monitoreando el estado de las actividades, entre
otros). De esta manera, estos sistemas están optimizados para procesar las
transacciones rápidamente.

Casi siempre los sistemas transaccionales trabajan con un registro o una

transacción por vez en un momento dado. En definitiva, automatizan los
procesos de negocio de la empresa. Pero dado su enfoque operativo,
generalmente no guardan datos históricos con gran precisión, sino que, por
el contrario, sus estructuras de datos frecuentemente solo guardan el
estado actual.

En cambio, los usuarios de un sistema de BI se encargan de vigilar y

controlar el movimiento de las ruedas de la organización, con el objeto de
evaluar su desempeño. Así, cuentan la cantidad de solicitudes generadas y
las comparan con las del mes o año anterior, etc. Se preocupan por que los
procesos operativos estén trabajando correctamente.

Aunque necesitan datos detallados para soportar sus requerimientos, los

usuarios BI casi nunca se enfocan en una transacción en un momento
dado.

Los sistemas BI generalmente están optimizados para consultas de alto

desempeño, teniendo en cuenta que las consultas de los usuarios
frecuentemente requieren la agregación o sumarización de cientos, miles o
incluso millones de registros diferentes. Por lo tanto, el contexto histórico
(y principalmente el período o tiempo asociado) es vital para la evaluación
del desempeño que hacen.

Ahora, ¿quién necesita de BI? En este sentido, Josep Lluís Cano (2007, p.
30) sostiene que “la información que podemos generar a partir de Business

6
Intelligence es útil para todos los departamentos de nuestra organización”.
Esto incluye a los responsables o gerentes de departamentos tales como:

 Compras

 Ventas / Comercial

 Finanzas

 Marketing

 Recursos Humanos

 Operaciones

 entre otros.

Es decir, para todas aquellas personas que deban tomar decisiones.

1.4 Problemática

Ralph Kimball (2013) sostiene que los problemas típicos de los usuarios
pueden sintetizarse en algunas de las demandas que mencionamos a
continuación:

 Recolectamos toneladas de datos, pero no podemos acceder a

ellos.

 Los directivos necesitan obtener los datos fácilmente.

 Sólo muéstrame lo que es importante.

 Desperdiciamos reuniones completas discutiendo quién tiene los

números correctos, en lugar de tomar decisiones.

 Queremos que la gente use la información para mejorar su proceso

de toma de decisiones.

7
Por otro lado, William Inmon (2005) expresa que la inexistencia de una
solución BI lleva a los siguientes problemas:

 Falta de credibilidad en los datos

 Problemas con la Productividad

 La Incapacidad de Convertir Datos en Información.

Falta de Credibilidad en los Datos

Cuando no existe un único origen de información, puede suceder que en

una misma organización encontremos dos departamentos, por ejemplo,
uno de los cuales experimentó un incremento en las ventas del 10% y el
otro un decremento del 5%. Conciliar la información de ambos puede ser
difícil o incluso imposible. Cuando la gerencia recibe esta información
contradictoria no puede tomar decisiones racionalmente dada la falta de
credibilidad en las fuentes. Las diferencias pueden surgir por varios
factores:

 No existe una misma base (tiempo) de cálculo

 Algoritmos diferentes

 Niveles de extracción disímiles

 Datos externos tenidos (o no) en cuenta

 Distinta base de datos fuente de la información.

Problemas con la Productividad

Del mismo modo que en el caso anterior, si no existe una base de datos
única e integrada para el análisis de la información se produce una fuerte
pérdida de productividad al tener que, por cada análisis requerido, revisar
distintos archivos, bases de datos, etc., compilando información muchas
veces contradictoria y sin una regla explícita de integración que puede
depender de lo que hace cada analista en un momento dado. Hay una
evidente sobrecarga de trabajo al tener que producir un reporte o informe
manualmente.

8
La Incapacidad de Convertir Datos en Información

Lo primero que descubrieron los analistas de los sistemas DSS a la hora de

satisfacer la solicitud de información es que ir a los sistemas
transaccionales para obtener los datos necesarios era el peor escenario,
puesto que estos sistemas y sus bases de datos subyacentes se
construyeron sin tener en cuenta una futura integración de datos entre sí.

Otro obstáculo es que no hay suficientes datos históricos almacenados en

las aplicaciones. Es decir, son sistemas que fueron diseñados para
responder rápidamente, con altos niveles de performance, y muchas veces
esto se consigue guardando sólo los últimos doce meses de trabajo en la
base de datos, sin grandes registros históricos.

1.5 Beneficios

Beneficios Tangibles, Intangibles y Estratégicos

De acuerdo con Josep Lluís Cano (2007, p. 32), “uno de los objetivos
básicos de los sistemas de información es que nos ayuden a la toma de
decisiones. Cuando un responsable tiene que tomar una decisión pide o
busca información, que le servirá para reducir la incertidumbre”.

Por lo tanto, un sistema de información de BI es clave para transformar los

datos en información y la información en conocimiento.

Actualmente, las empresas, ante una dinámica de cambios casi

permanente en los mercados, están sometidas a fuertes presiones
competitivas y sus directivos requieren del conocimiento que puede
brindar un sistema de BI para poder soportar un adecuado proceso de
toma de decisiones.

Los beneficios que se pueden obtener a través del uso de BI pueden ser de
distintos tipos:

 Beneficios tangibles, por ejemplo: reducción de costes, generación

de ingresos y reducción de tiempos para las distintas actividades del
negocio.

9
  Beneficios intangibles: el hecho de que tengamos disponible la
información para la toma de decisiones hará que más usuarios
utilicen dicha información para tomar decisiones y mejorar la
nuestra posición competitiva.

 Beneficios estratégicos: Todos aquellos que nos facilitan la

formulación de la estrategia, es decir, a qué clientes, mercados o
con qué productos dirigirnos.

(Cano, 2007, pp. 32-33)

Este mismo autor también sostiene que (2007, p. 37) “la principal razón de
un proyecto de Business Intelligence es el análisis de un problema o
problemas interrelacionados”.

Cálculo del ROI en Proyectos de BI: Porqué es

importante calcular el ROI.

De acuerdo con Josep Lluís Cano (2007), al plantear cualquier proyecto de

sistema de información es imprescindible calcular cuál es la rentabilidad
esperada del mismo.

Por lo tanto es necesario:

 Definir el valor esperado, es decir, tratar de estimar cuál es el

beneficio o valor agregado total que aportará el proyecto a la
empresa.

 Determinar la inversión total requerida del proyecto con el objetivo

de asegurar los fondos necesarios para su concreción, identificando
los distintos retornos que se podrán conseguir.

 Implementar el proyecto y evaluar si se ha logrado alcanzar el valor

y retorno esperados.

 Medir los resultados del proyecto e implementar un plan de acción

correctivo alternativo.

La medida comúnmente utilizada en el entorno empresarial para

comprobar la rentabilidad de un proyecto es el retorno de la

10
 inversión (ROI). El ROI pone en relación el valor aportado al
negocio con las inversiones necesarias para obtenerlo. Una forma
simplificada del cálculo del ROI es:

(Cano, 2007, p. 45)

Metodología para el Cálculo del ROI

Josep Lluís Cano, en base a un artículo de Bill Whittemore, propone la

siguiente metodología paso a paso para el cálculo del ROI de un proyecto
de BI:
1) Definir cuál es el problema u oportunidad de negocio y los
objetivos de negocio. Los objetivos deben ser específicos,
medibles, alcanzables, adecuados y referidos a un periodo de
tiempo.

2) Recoger los requerimientos de negocio.

3) Construir el proyecto de Business Intelligence.

4) Identificar y cuantificar los beneficios (tangibles, estratégicos e

intangibles).

5) Establecer el punto de partida de medida, tanto de los costos

como de los ingresos.

6) Calcular el costo total de propiedad (TCO): incluye el hardware,

software, los servicios de consultoría, los costos de los recursos
internos (costos de personal) y los costos de lanzamiento,
mantenimiento y formación.

7) Calcular el ROI. Para ello se aplica la siguiente fórmula:

11
 En donde NPV es el Valor Neto Actual, es decir, la suma
actualizada de los beneficios esperados del proyecto.

8) Una vez aprobado e implementado el proyecto, deberemos

hacer un seguimiento tanto de la inversión como de los costos y
de los beneficios que realmente se han conseguido, para poder
tomar las medidas correctivas que sean necesarias.

(2007, pp. 47-49)

Además, de acuerdo con Josep Lluís Cano (2007, p. 52), “los proyectos de
Business Intelligence tienen un ROI elevado, su comportamiento es mucho
mejor que en el resto de proyectos de Sistemas de Información”.

1.6 Proceso de Toma de Decisiones

Podemos denominar Proceso de Toma de Decisiones al proceso de tener

que elegir entre distintos cursos de acción alternativos con el propósito de
alcanzar un objetivo en particular.

De acuerdo con Kennet Laudon (2004), el proceso de toma de decisiones

consta de cuatro etapas:

 Inteligencia

 Diseño

 Selección

 Implementación.

12
A continuación veremos cada una de estas fases:

Fase de Inteligencia

La etapa de Inteligencia consiste en:

Identificar y entender los problemas que se presentan en la
organización: el por qué ocurre un problema, dónde y cuáles son
sus efectos.

Los sistemas MIS tradicionales que suministran una gran variedad

de información detallada pueden ayudar a identificar problemas,
especialmente si los sistemas reportan excepciones.

(Kennet Laudon, 2004, p. 88)

Fase de Diseño

La etapa de Diseño, según Kennet Laudon es aquella durante la cual “el

individuo genera posibles soluciones para los problemas. Los DSS más
pequeños son ideales en esta etapa de la toma de decisiones, porque
trabajan sobre modelos sencillos, es posible desarrollarlos rápidamente y
pueden operar con datos limitados” (2004, p. 88).

Fase de Selección

La etapa de Selección:
Consiste en elegir entre alternativas de solución. Aquí el
encargado de la toma de decisiones podría necesitar un sistema
DSS más grande para obtener datos más extensos a partir de
varias alternativas y modelos complejos, o bien, herramientas de
análisis de datos para recabar todos los costos, consecuencias y
oportunidades.

(Kennet Laudon, 2004, p. 88)

13
Fase de Implementación

La etapa de Implementación se lleva a cabo:

Cuando la decisión se pone en práctica. En ella, los gerentes
pueden utilizar un sistema que elabore informes de rutina sobre
el progreso de una solución específica.

Los sistemas de apoyo pueden abarcar desde sistemas MIS con

características avanzadas hasta sistemas mucho más pequeños,
así como software de planeación de proyectos que se ejecute en
computadoras personales.

(Kennet Laudon, 2004, p. 88)

Tal como destaca Mónica López Gutiérrez (http://goo.gl/Xy2REl, 2004),

debemos tener en cuenta que un DSS no es más que un sistema de
información gerencial que permite “resolver problemas semi-estructurados
y no estructurados, involucrando al usuario a través de una interfaz
amigable”.

Mónica López Gutiérrez también sostiene que un DSS permite “mejorar el

Proceso de Toma de Decisiones a lo largo de las etapas del mismo:
inteligencia, diseño, selección e implementación... Los DSS principalmente
se utilizan para decisiones estratégicas y tácticas en la gestión a nivel
superior” (http://goo.gl/Xy2REl, 2004).

1.7 CIF

Niveles de Datos

De acuerdo con William Inmon (2005), podemos diferenciar cuatro niveles

de datos:

 Nivel Operacional

 Nivel Atómico (o Data Warehouse)

 Nivel Departamental (o Data Mart u OLAP o Multidimensional)

14
  Nivel Individual.

Estos niveles son la base del concepto del Corporate Information Factory
(CIF). A continuación, describiremos las principales características de cada
uno de estos niveles de datos:

 Nivel Operacional

El nivel operacional de datos mantiene solamente datos primitivos (es

decir, operacionales, transaccionales) orientados a la aplicación, y sirve
específicamente a la comunidad de usuarios de procesamiento OLTP, de
alta performance requerida.

En este nivel generalmente no se mantienen registros históricos ya que los

datos se actualizan y se pierden los valores anteriores.

 Nivel del Data Warehouse

El nivel de datos atómico o de Data Warehouse mantiene datos

primitivos, pero históricos e integrados que no pueden actualizarse,
además de algunos datos derivados/analíticos.

 Nivel Departamental

El nivel de datos Departamental contiene datos derivados que son

formateados especialmente en función de los requerimientos de análisis de
datos de los usuarios, ajustados a las necesidades de un departamento de
la organización en particular.

 Nivel Individual

El nivel de datos Individual es donde mayor análisis heurístico se realiza.

Generalmente, aquí hay datos temporales. Como regla general,
típicamente los Sistemas de Información Ejecutivos (EIS) procesan datos a
este nivel y corren sobre una PC.

15
Imagen 1: Niveles de Datos

Fuente: Elaboración propia en base a William Inmon (2005, p. 16)

Componentes del CIF

Resulta evidente que los tipos de consultas que se pueden efectuar en cada
nivel de datos son distintos. Así, los diferentes niveles de datos requieren
un conjunto de entidades arquitectónicas diferenciadas. Estas entidades
constituyen el Corporate Information Factory (CIF).

El CIF es un concepto que hace referencia al conjunto de todas las

estructuras de datos que posee una determinada organización (bases de
datos transaccionales y analíticas, entre otras), conjuntamente con todos
aquellos procesos y herramientas utilizados en las distintas etapas para
poder generar información y lograr que la misma se encuentre disponible
en tiempo y forma para todos los niveles de la organización.

Como señalan Josep Lluís Cano (2007), William Inmon (2005) y Ralph
Kimball (2013), los distintos componentes del CIF y, por ende, de una
solución de BI, son (aunque no siempre encontraremos todos ellos):

 Fuentes de Información

 Procesos ETL de Extracción, Transformación y Carga de datos en el

Data Warehouse

 Data Warehouse

 Data Mart

16
  Repositorio de Metadatos

 Operational Data Store (ODS)

 Exploration Warehouse

 Data Mining Warehouse

 Herramientas de Business Intelligence para la visualización y

explotación de datos.

En el siguiente gráfico podemos ver estos componentes del CIF y las

relaciones entre ellos:

Imagen 2: Componentes del CIF

Fuente: Josep Lluís Cano (2007, p. 93)

17
Fuentes de Información
Según Josep Lluís Cano (2007), las fuentes de información hacen referencia
a los lugares (bases de datos, etc.) de donde se extraerán los datos para
alimentar el Data Warehouse.

Principales Fuentes de Datos

Las principales fuentes de información son:

 Bases de Datos de cada uno de los Sistemas

Operacionales/Transaccionales, que pueden incluir tanto
aplicaciones desarrolladas a la medida de la organización, como así
también productos “enlatados” o grandes sistemas corporativos,
como por ejemplo: los sistemas de Gestión de las Relaciones con los
Clientes (CRM, Customer Relationship Management), sistemas de
Gestión Financiera y Planificación de Recursos Empresariales (ERP,
Enterprise Resource Planning), sistemas de Gestión de la Cadena de
Abastecimiento (Supply Chain Management) y sistemas de Gestión
de Recursos Humanos o del Capital Humano (HCM, Human Capital
Management), entre otros.

 Sistemas de Información Departamentales, muchas veces basados

en planillas de cálculo Excel, etc.

 Fuentes de información correspondientes a Bases de Datos

externas a la empresa, que en algunos casos pueden haber sido
compradas a terceras organizaciones, como por ejemplo:
consultoras de investigación de mercado. Las fuentes de
información externas son fundamentales para enriquecer la
información que tenemos de los clientes. En algunos casos es
interesante incorporar información referente, por ejemplo, a
población y número de habitantes, entre otros. Podemos acceder a
información de este tipo en la correspondiente web del Instituto
Nacional de Estadísticas.

18
Pero también existen otras fuentes de información de las cuales se pueden
llegar a tomar datos según las necesidades, tales como:

 Otras fuentes de Internet: Muchas veces es necesario poder

realizar comparaciones en los indicadores con otras compañías u
organizaciones; es lo que se denomina una actividad de
Benchmarking. Esto es fundamental dado que para saber si
determinado valor es bueno o malo - en realidad se trata de un
valor relativo a cómo les va a otras empresas- pueden obtenerse
datos públicos de Internet e incorporarlos al Data Warehouse.

 Datos aportados por analistas expertos, especializados en alguna

temática en particular.

 Otros.

Factores a Considerar

Según Josep Lluís Cano (2007), hay distintos factores que contribuyen a la
complejidad de la carga de información; entre ellos el autor destaca la
cantidad de fuentes diferentes de información, teniendo en cuenta que en
las grandes corporaciones es natural hablar de una media de 8 bases de
datos hasta llegar incluso a 50.

A medida que se requiere acceder a un número creciente de fuentes de

información, la complejidad de todo proyecto de creación de un Data
Warehouse se incrementa notablemente dado que probablemente algunas
bases de datos están en SQL Server, otras en Oracle, otras en IBM DB2,
etc.; además de la propia complicación inherente al modelo de datos
subyacente de cada aplicación.

Otro problema es el que deviene de la falta de documentación de estas

bases de datos, correspondientes en muchas ocasiones a aplicaciones que
han sido modificadas a lo largo de los años por distintos programadores sin
seguir ningún tipo de estándares y con criterios sumamente heterogéneos.
La información que cargamos en un Data Warehouse
normalmente es estructurada, es decir, aquella que se puede
almacenar en tablas: en la mayoría de los casos es información
numérica. Cada vez más, la tecnología nos permite trabajar con
información no estructurada, y se espera que este tipo de
información sea cada vez más importante. Dentro de la

19
 información no estructurada tenemos: correos electrónicos,
cartas, informes, videos, etc.

(Cano, 2007, pp. 96-97)

Calidad de Datos

De acuerdo con Josep Lluís Cano (2007), una vez que ya se han establecido
cuáles serán las fuentes de información debe procederse a verificar la
calidad de los datos del Data Warehouse, lo cual es un aspecto esencial.
Consecuentemente, es necesario asegurar que la calidad de los
datos es máxima. Si en el Data Warehouse hay errores, éstos se
propagarán a lo largo de toda la organización y son muy difíciles
de localizar. Además, pueden ocasionar que se tomen decisiones
erróneas que afecten a los resultados de la organización. Los
costes derivados de que la calidad de los datos no sea la correcta
pueden llegar a ser muy elevados.

(Cano, 2007, p. 98)

Por otro lado, el autor también expresa que:

Asumir que la calidad de los datos es buena puede ser un error
fatal en los proyectos de Business Intelligence. Normalmente,
cuando se construye un Data Warehouse la mayoría de las
organizaciones se focalizan en identificar los datos que necesitan
analizar, los extraen y los cargan en el Data Warehouse.
Generalmente no se piensa en la calidad de los datos, permitiendo
que los errores sean cargados al Data Warehouse. Debería por
tanto establecerse un control o conjunto de controles en el
proyecto que localizara los errores en los datos y no permitiera la
carga de los mismos. Las comprobaciones se deberán llevar a
cabo, de forma manual o automatizada, teniendo en cuenta
distintos niveles de detalle y variando los periodos de tiempo,
comprobando que los datos cargados coinciden con los de las
fuentes de datos origen.

En algunos casos se detectan errores que se originan por fallos en

los sistemas transaccionales, lo que debería provocar proyectos

20
 de mejora en los mismos. Muchos de estos casos se deben a que
los usuarios pueden introducir datos sin ningún tipo de control.
Siempre que se pueda, es recomendable que los usuarios elijan
entre distintos valores, en lugar de introducirlos libremente ellos.
No es una buena opción corregirlos en el proceso ETL y no
modificar las aplicaciones origen. Esta alternativa es mucho más
rápida inicialmente, pero mucho más costosa a largo plazo.

Los errores también se pueden producir, por ejemplo, en el

proceso de ETL o al integrarlos en el Data Warehouse.

(Cano, 2007, p. 99)

Respecto de la responsabilidad de la calidad de los datos, Josep Lluís Cano

determina que la misma:
No pertenece sólo a los departamentos de tecnología: Debe
asumirse la parte correspondiente en cada uno de los propietarios
de los procesos y de las aplicaciones que los soportan. Desde el
proyecto debemos velar por la calidad de los datos, puesto que si
la calidad no es la adecuada nunca podremos obtener los
beneficios esperados del proyecto. Debemos entender que la
problemática de la calidad de datos no es un problema de los
departamentos de tecnología, sino un problema estratégico al que
debemos asignar objetivos, recursos y planificación.

(2007, p. 100)

Finalmente, las principales características que deben satisfacer los datos,

con el objeto de que alcancen un nivel de calidad elevado son:
1) Precisión: ¿Representan los datos con precisión una realidad o
una fuente de datos que se pueda verificar?

2) Integridad: ¿Se mantienen constantemente la estructura de los

datos y las relaciones a través de las entidades y los atributos?

3) Coherencia: ¿Son los elementos de datos constantemente

definidos y comprendidos?

4) Totalidad: ¿Están todos los datos necesarios?

21
 5) Validez: ¿Son los valores aceptables en los rangos definidos por
el negocio?

6) Disponibilidad: ¿Están los datos disponibles cuando se

necesitan?

7) Accesibilidad: ¿Se puede acceder a los datos fácil y

comprensiblemente?

(Cano, 2007, p. 102)

Procesos de Extracción, Transformación

y Carga

Concepto de ETL

El ETL se trata del proceso correspondiente a:

La extracción, transformación y carga de los datos en el Data
Warehouse. Antes de almacenar los datos en un Data Warehouse,
éstos deben ser transformados, limpiados, filtrados y redefinidos.
Normalmente, la información que tenemos en los sistemas
transaccionales no está preparada para la toma de decisiones.

(Cano, 2007, pp. 93-94)

Es decir, es el proceso que consiste en extraer información de las fuentes

de datos, transformarla, re-codificarla, limpiarla, explicitar reglas de
negocio ocultas, formatearla y organizarla de manera de poder
incorporarla en el Data Warehouse. A estos procesos se los conoce con la
sigla ETL (Extract, Transform and Load, en inglés).

De acuerdo con William Inmon (2005), el proceso ETL se encarga de

transferir datos desde el entorno operacional al entorno del Data
Warehouse, integrando las distintas fuentes de información.

22
Proceso ETL en el Proyecto de BI

El diseño de los procesos ETL insume gran parte del tiempo de un proyecto
BI. Se trata de una tarea compleja, pero para poder aprovechar los
beneficios del Data Warehouse es fundamental que se logre la integración
de datos desde los distintos orígenes.

Josep Lluís Cano señala que “el proceso de ETL consume entre el 60% y el
80% del tiempo de un proyecto de Business Intelligence, por lo que es un
proceso clave en la vida de todo proyecto” (2007, p. 103).

Pasos del Proceso ETL

El proceso ETL se divide en 5 subprocesos:

1) Extracción: Este proceso recupera los datos físicamente de las
distintas fuentes de información. En este momento disponemos
de los datos en bruto.

2) Limpieza: Este proceso recupera los datos en bruto y

comprueba su calidad, elimina los duplicados y, cuando es posible,
corrige los valores erróneos y completa los valores vacíos, es decir
se transforman los datos -siempre que sea posible- para reducir
los errores de carga. En este momento disponemos de datos
limpios y de alta calidad.

3) Transformación: Este proceso recupera los datos limpios y de

alta calidad y los estructura y sumariza en los distintos modelos de
análisis. El resultado de este proceso es la obtención de datos
limpios, consistentes, sumarizados y útiles.

4) Integración: Este proceso valida que los datos que cargamos en

el Data Warehouse son consistentes con las definiciones y
formatos del Data Warehouse; los integra en los distintos modelos
de las distintas áreas de negocio que hemos definido en el mismo.
Estos procesos pueden ser complejos.

5) Actualización: Este proceso es el que nos permite añadir los

nuevos datos al Data Warehouse.

(Cano, 2007, pp. 104-105)

23
Problema de Integración de Datos

De acuerdo con William Inmon (2005), se extraen datos desde distintas

fuentes/sistemas/aplicaciones, datos que no están integrados. Incluirlos en
el Data Warehouse sin integrarlos sería un gran error.

Ocurre que cuando fueron diseñados esos sistemas nadie pensó en futuras
integraciones. Cada una tuvo sus propios requerimientos. Por lo tanto,
extraer datos de distintos lugares e integrarlos en una base de datos única
es un problema complejo.

Imagen 3: Problema de Integración de Datos

Fuente: Elaboración propia en base a William Inmon (2005, p. 73)

Algunos ejemplos de falta de integración que comúnmente podemos

encontrar son:

 Valores que se encuentran codificados de manera distinta

 Valores con distintas unidades de medida

 Campos que tienen distintos nombres pero representan lo mismo

 Formatos diferentes.

24
Eficiencia en el Acceso a los Sistemas
Transaccionales

William Inmon (2005) destaca, sin embargo, que la integración no es la

única dificultad en la transformación de datos desde los sistemas
transaccionales; otro problema es la eficiencia en el acceso a los datos de
los sistemas existentes. No tiene sentido cargar todos los datos de los
sistemas operacionales en el Data Warehouse cada vez que haya una
extracción.

Podemos identificar entonces tres tipos de carga en el Data Warehouse:

 Datos antiguos, archivados (carga única, de una sola vez).

 Datos actualmente contenidos en el entorno operacional.

 Cambios continuos al Data Warehouse a partir de cambios

(actualizaciones) que ocurrieron en los sistemas operacionales
desde la última actualización. (Esto presenta el mayor desafío para
un arquitecto de datos puesto que no es fácil identificar dichos
cambios).

Según William Inmon (2005), existen cinco técnicas que comúnmente se

usan para limitar la cantidad de datos operacionales extraídos:

 Extraer los datos que tienen marca temporal en las bases de datos
operacionales. Sólo se traen los datos desde la última fecha y hora
de actualización.

 A través de un archivo delta que contenga solo los cambios hechos

en una aplicación como resultado de las transacciones ejecutadas
sobre las bases de datos operacionales. El proceso es muy eficiente,
pero muy pocas aplicaciones cuentan con un archivo delta.

 Escanear un archivo log (similar al archivo delta, pero con mayor

información).

 Modificar el código de la aplicación.

 Tomar una imagen o snapshot de la base de datos operacional,

antes y después de cada extracción; luego se comparan ambas
versiones para identificar las diferencias.

25
Desafíos en los Procesos ETL

De acuerdo con William Inmon (2005), los procesos ETL encaran varios
desafíos complejos:

 La extracción de datos desde los sistemas transaccionales hacia el

Data Warehouse generalmente requiere un cambio de tecnología
(por ejemplo: leer desde una base de datos Microsoft SQL Server y
cargar un Data Warehouse en Oracle).

 La selección de datos a extraer puede ser muy compleja, tal como

se describió anteriormente.

 Los campos claves en las bases de datos operacionales

frecuentemente deben ser reestructurados y convertidos antes de
escribirlos en el Data Warehouse.

 Reformateo de campos no claves como, por ejemplo, el formato de

las fechas.

 Limpieza de datos (formato, verificación de clave foránea, etc.), a

medida que se introduce en el Data Warehouse.

 Consolidación de datos de distintas fuentes.

 Provisión de valores por default.

 Sumarización de datos.

 Renombre de datos.

 Conversiones en los formatos de datos.

 Registro de cantidad de datos extraídos, transformados y cargados

en el Data Warehouse (tema clave de auditoría/metadatos cuando
se cargan grandes volúmenes de datos).

 Otros.

26
Enterprise Data Warehouse

El Data Warehouse es el núcleo del Corporate Information Factory;

contiene datos históricos, integrados, de toda la organización,
generalmente con alto nivel de detalle (granularidad), actualizado a partir
de los procesos ETL.

Además, es una colección de información corporativa que alimenta a otras

estructuras de datos como Data Marts, Exploration Warehouses, Data
Mining Warehouses, Operational Data Stores (ODS) y, en definitiva,
construidos con el objetivo de ser explotados por diferentes Sistemas de
Soporte de Decisión (DSS).

De acuerdo con William Inmon (2005), el Data Warehouse está en el

corazón del CIF y es el fundamento de todo DSS. El Data Warehouse
contiene datos corporativos con alta granularidad (alto nivel de detalle).

Por diversas razones (implicancias en performance, integración y

transformación de datos, entre otras), es conveniente que los sistemas DSS
realicen las consultas analíticas sobre un Data Warehouse aislado de las
bases de datos operacionales.
La aparición de los Data Warehouse o Almacenes de Datos son la
respuesta a las necesidades de los usuarios que necesitan
información consistente, integrada, histórica y preparada para ser
analizada para poder tomar decisiones.

Al recuperar la información de los distintos sistemas, tanto

transaccionales como departamentales o externos, y
almacenándolos en un entorno integrado de información
diseñado por los usuarios, el Data Warehouse nos permitirá
analizar la información contextualmente y relacionada dentro de
la organización.

(Cano, 2007, p. 113)

Según William Inmon (2005), los aspectos más importantes de un Data

Warehouse son:

 Orientado a una materia o área de interés: Los sistemas

transaccionales se organizan alrededor de las aplicaciones
funcionales de la organización; por ejemplo, para una compañía de
seguros las aplicaciones pueden ser para el procesamiento de

27
 seguros de autos, vida, casa, salud, etc. Las principales áreas de
interés podrían ser: cliente, póliza, etc. Cada tipo de empresa tiene
sus propias áreas de interés. A su vez, cada área de interés está
físicamente implementada como una serie de tablas relacionadas
en el Data Warehouse. Por ejemplo, para el área “Clientes” podría
haber una tabla con todos los clientes de la empresa y varias tablas
con la actividad de estos clientes, algunas con los eventos
detallados y otras con sumarizaciones o agregaciones (como
cantidad de transacciones realizadas por mes, promedio de
accidentes por año, etc.); todas las tablas estarán relacionadas por
el ID del Cliente.

 Integrado: De todos los aspectos del Data Warehouse, este es el

más importante. Los datos provienen de múltiples orígenes. Antes
de insertarse, se convierten, reformatean, e incluso pueden
sumarizarse. Dado que cada aplicación en su momento fue
desarrollada en forma aislada, sin tener en cuenta futuras
integraciones, generalmente se encuentran inconsistencias de
datos entre los distintos orígenes o bases de datos, ya sea a nivel de
nomenclatura, codificación, atributos físicos y unidad de medida,
entre otros.

 No volátil: los datos operacionales son generalmente accedidos y

manipulados de a un registro por vez. Los datos operacionales son
actualizados regularmente, no así en el Data Warehouse donde los
datos se cargan (usualmente en forma masiva, en un formato
estático o “snapshot”) y se consultan, pero no se actualizan. Cuando
hay un cambio en los sistemas transaccionales, en el Data
Warehouse se graba un nuevo registro o snapshot. Esto permite
tener un registro histórico de datos.

 Variable con el tiempo: Esto implica que cada unidad de datos en el

Data Warehouse es precisa y en un momento dado. Generalmente,
cada registro está asociado a una fecha de transacción en particular
o a una marca de tiempo. Habitualmente, el Data Warehouse tiene
un horizonte de tiempo almacenado de 5 a 10 años, aunque a veces
puede extenderse mucho más. En cambio, las bases de datos
transaccionales contienen datos de valor actual, es decir, datos
cuya precisión solo es válida en el momento en que se consulta o se
accede. Por ejemplo: un Banco sabe exactamente cuánto dinero
tiene un cliente en su cuenta hoy; este valor se actualiza cada vez
que hay un depósito o una extracción.

En el Data Warehouse la serie de snapshots provee una secuencia

histórica de actividades y eventos; la estructura clave de los datos
operacionales puede o no contener un elemento de tiempo como

28
 año, mes o día, pero el Data Warehouse siempre contiene algún
elemento de tiempo.

Data Mart

De acuerdo con William Inmon (2005), un Data Mart es una estructura de

datos que está dedicada a servir las necesidades analíticas de un grupo de
personas, como el departamento de Finanzas, por ejemplo.
El trabajo de construir un Data Warehouse corporativo puede
generar inflexibilidades, o ser costoso y requerir plazos de tiempo
que las organizaciones no están dispuestos a aceptar. En parte,
estas razones originaron la aparición de los Data Mart. Los Data
Mart están dirigidos a una comunidad de usuarios dentro de la
organización, que puede estar formada por los miembros de un
departamento, o por los usuarios de un determinado nivel
organizativo, o por un grupo de trabajo multidisciplinar con
objetivos comunes.

Los Data Mart almacenan información de un número limitado de

áreas; por ejemplo, pueden ser de marketing y ventas o de
producción. Normalmente se definen para responder a usos muy
concretos.

Normalmente, los Data Mart son más pequeños que los Data
Warehouses. Tienen menos cantidad de información, menos
modelos de negocio y son utilizados por un número inferior de
usuarios.

Los Data Mart pueden ser independientes o dependientes. Los

primeros son alimentados directamente de los orígenes de
información, mientras que los segundos se alimentan desde el
Data Warehouse corporativo. Los Data Mart independientes
pueden perpetuar el problema de los “silos de información” y en
su evolución pueden llegar a generar inconsistencias con otros
Data Mart.

(Cano, 2007, pp. 117-118)

29
Repositorio de Metadatos

De acuerdo con William Inmon (2005), un componente central del Data

Warehouse es el Repositorio de Metadatos ya que le permite al usuario
final de un DSS navegar entre distintas posibilidades. Cuando el usuario se
acerca a un Data Warehouse sin metadatos no sabe dónde iniciar su
análisis o cómo encontrar los datos correctos, ni cómo interpretar los datos
encontrados. Con la ayuda de metadatos el usuario puede ir rápidamente a
los datos principales. Así, los metadatos actúan como un índice de los
contenidos del Data Warehouse.

Generalmente, almacenan el seguimiento de:

 Estructuras de datos importantes para un desarrollador

 Estructuras de datos importantes para un analista de BI

 Fuentes de datos que alimentan el Data Warehouse

 Transformación de datos en el Data Warehouse

 Modelo de datos

 Relaciones entre el modelo de datos y el Data Warehouse

 Historia de extracciones (ejecuciones de los procesos ETL).

Josep Lluís Cano expresa que:

Un componente crítico de un Data Warehouse es el Metadata. El

Metadata es el repositorio central de información de la
información. Nos da el significado de cada uno de los
componentes y sus atributos que residen en el Data Warehouse (o
Data Mart). La información que contiene el Metadata es útil para
los departamentos de tecnología y los propios usuarios. Puede
incluir definiciones de negocio, descripciones detalladas de los
tipos de datos, formatos y otras características.

La construcción del Metadata supone que se defina el significado

de cada una de las tablas y cada uno de los atributos que se
cargan en el Data Warehouse. Este es un punto complejo de todo
proyecto, ya que obliga a que se definan los conceptos de negocio
y se homogeneícen entre los distintos departamentos, filiales, etc.
Obliga a que todos los componentes de la organización hablen

30
 utilizando la misma terminología y con el mismo significado, lo
cual no siempre es sencillo. Cuando alguien hable de “margen
bruto” o “margen de contribución” deberá estar absolutamente
definido para la organización. Evidentemente, organizaciones
distintas tendrán normalmente definiciones distintas.

(Cano, 2007, pp. 120-121)

En el siguiente gráfico, podemos ver distintos aspectos involucrados al

Repositorio de Metadatos:

Imagen 4: Metadatos

Fuente: Elaboración propia

31
Operational Data Store (ODS)

El ODS, como estructura de datos, da soporte a la toma de decisiones

operativas, rutinarias y diarias de los niveles más bajos de la organización.

De acuerdo con William Inmon (2005), con los ODS fue posible hacer
procesamiento en tiempo real contra datos integrados.
Existe un componente tecnológico, los Operational Data Store
(ODS) que a veces se confunden con los Data Warehouses. Los
ODS son una extensión de la tecnología de los Data Warehouses.

Los ODS consolidan datos de múltiples fuentes provenientes de

distintos sistemas de información no integrados y facilitan un
acceso online integrado sobre esa información. Su objetivo es
proporcionar información integrada, con el fin de facilitar la toma
de decisiones en entornos operacionales. Algunas veces se utilizan
para evitar integraciones o implementaciones de soluciones ERP.
La información que reside en los ODS es volátil y normalmente
tiene, como máximo, una antigüedad de dos o tres meses. La
principal diferencia con los Data Warehouses es que los datos de
los ODS son volátiles y se actualizan en tiempo real. Los ODS
habitualmente se convierten en una fuente de datos para el Data
Warehouse.

(Cano, 2007, pp. 121-122)

Clases de ODS

Siguiendo a William Inmon (2005), enunciamos cuatro clases de ODS cuya

clasificación depende de la rapidez con que llegan los datos a la estructura
del ODS:

 Clase I, en donde las actualizaciones de datos desde los sistemas

transaccionales hacia el ODS son síncronas. En general, podemos
hablar de que pasan milisegundos entre una actualización en el
entorno operacional y en el ODS; el usuario, por lo tanto, no se da
cuenta de la diferencia entre un esquema y el otro. Esta clase de
ODS es cara y tecnológicamente desafiante; casi nunca se justifica

32
 económicamente. Mayormente se opta simplemente por pasar
datos del entorno operacional al ODS sin integrarlos.

 Clase II, en donde las actualizaciones ocurren dentro de un marco

temporal de 2 a 3 horas. Esta clase de ODS es común. El mayor
tiempo de sincronización permite la integración de los datos, es
decir, que se ejecuten procesos ETL con mayor nivel de
procesamiento y transformación de datos.

 Clase III, en donde la sincronización de las actualizaciones se

produce cada 24 horas, generalmente de noche. Es similar a la clase
II, aunque con una implementación marcadamente más económica.

 Clase IV, en donde las actualizaciones del ODS son frecuentemente

a partir del Data Warehouse pero no están calendarizadas; es decir,
existe un largo período de tiempo (incluso meses o años) entre la
coordinación del ODS y su fuente. Generalmente la fuente aquí es el
Data Warehouse, aunque puede provenir de otras fuentes.

De acuerdo con William Inmon (2005), un Data Warehouse nunca puede

accederse en milisegundos. Debido a la naturaleza de sus datos, no está
preparado para soportar procesos de tipo OLTP. Sin embargo, poder
obtener tiempos de respuestas tan óptimos es algo muy valioso.

Cuando se requieren tiempos de respuesta óptimos y a su vez debe

accederse a datos integrados, consolidados en una plataforma BI, debe
emplearse el ODS, que es el repositorio para procesamiento de alta
performance.

A diferencia del Data Warehouse, el ODS es opcional. Así, ambas

estructuras son complementarias, ya que las dos residen fuera del entorno
operacional, soportan procesamiento DSS o BI y usan datos integrados.
Además, los flujos de datos entre ambos son bidireccionales. En algunas
situaciones el ODS alimenta el Data Warehouse; en otras, el Data
Warehouse alimenta el ODS. Pero a diferencia del Data Warehouse, el ODS
está diseñado para procesamiento en tiempo real.

Las actualizaciones de datos en el ODS son normales, a diferencia del Data

Warehouse donde siempre queda la foto histórica. Es decir, mientras en el
Data Warehouse se almacenan valores históricos, en el ODS se almacenan
valores actuales; esto implica que las aplicaciones BI que necesitan
visualizar datos actuales, corren sobre el ODS y no sobre el Data
Warehouse. Generalmente, un ODS no contiene más de un mes de
histórico.

33
El diseño del ODS sigue un modelo híbrido, puede hacerse siguiendo
modelo relacional en una parte y multidimensional en otra parte;
dependerá de los requerimientos en cuanto a flexibilidad y performance.

El ODS suele contar con un volumen de datos muy inferior al Data

Warehouse.

Exploration Warehouse

De acuerdo con William Inmon (2005), el Exploration Warehouse es una

forma especial de Data Warehouse. El objetivo de esta estructura consiste
en proporcionar un fundamento para el análisis estadístico “pesado”. Una
vez construido, se pueden ejecutar sobre él análisis estadísticos sin
problemas, ya que estará en una máquina separada de donde ocurre el
procesamiento regular del Data Warehouse. Es decir, el Exploration
Warehouse permite satisfacer requerimientos de procesamiento temporal
y desestructurado con altas velocidad de respuesta.

Otra explicación para la creación de un Exploration Warehouse es que la

tecnología de análisis estadístico es tan diferente de otros estilos de
análisis que tiene sentido ejecutarla sobre entornos separados. Además,
otra razón es el diseño de bases de datos: el Exploration Warehouse casi
nunca es una copia directa de los datos encontrados en el Data
Warehouse. En lugar de ello, el Exploration Warehouse inicia con un
subconjunto de los datos del Data Warehouse, incluso pueden agregarse
algunos campos pre-calculados. Debido a la naturaleza de los
requerimientos de explotación, sus datos se encuentran también
altamente indexados.

Los Exploration Warehouses generalmente están enfocados en proyectos;

es decir, una vez terminado un proyecto, desaparecen. Por tanto, tienen
una existencia transitoria, lo cual contrasta con un Data Warehouse, ya que
éste es de vida permanente. Además, a diferencia de un Data Warehouse,
en ocasiones se puede “congelar” la información, sin actualizarla con los
datos más nuevos. Dado a que se prueban distintos algoritmos, conviene
hacerlos sobre los mismos datos, sin actualizarlos con tanta frecuencia.

En algunas situaciones, el Exploration Warehouse puede estar asociado con

el Data Mining Warehouse.

34
Data Mining Warehouse

De acuerdo con William Inmon (2005), un Data Mining Warehouse es

similar en distintos aspectos a un Exploration Warehouse, pero con algunas
diferencias:

 El objetivo primario de un Exploration Warehouse es la creación de

afirmaciones, hipótesis y observaciones. Un Data Mining
Warehouse tiene el objetivo de probar dichas hipótesis.

 Un Exploration Warehouse está optimizado en amplitud de

información, mientras que el Data Mining Warehouse está
optimizado en profundidad de información.

 Sin embargo, dado que las diferencias son sutiles -salvo en grandes
corporaciones-, pueden estar bajo la misma estructura.

Hay que tener en cuenta que se trata de un almacén de datos creado

específicamente para contener las entradas y las salidas de los procesos de
Data Mining, de manera que no interfieran ni con los sistemas
operacionales, ni con los DSS.

Herramientas de Business Intelligence

Las principales herramientas de Business Intelligence son:

 Generadores de Reportes / Informes: Utilizados por
desarrolladores profesionales para crear informes estándar
para grupos, departamentos o la organización.

 Herramientas de Usuario Final de Consultas e Informes

(Query & Reporting): Empleadas por usuarios finales para
crear informes para ellos mismos o para otros; no requieren
programación.

 Herramientas OLAP: Permiten a los usuarios finales tratar la

información de forma multidimensional para explorarla desde
distintas perspectivas y periodos de tiempo.

35
  Herramientas de Dashboard y Scorecard: Permiten a los
usuarios finales ver información crítica para el rendimiento con
un simple vistazo, utilizando iconos gráficos y con la posibilidad
de ver más detalle para analizar información detallada e
informes si así lo desean.

 Herramientas de Planificación, Modelización y Consolidación:

Permite a los analistas y a los usuarios finales crear planes de
negocio y simulaciones con la información de Business
Intelligence. Se utilizan para elaborar la planificación, los
presupuestos, las previsiones. Estas herramientas proveen a
los Dashboards y los Scorecards con los objetivos y los
umbrales de las métricas.

 Herramientas de Data Mining: Permiten a estadísticos o

analistas de negocio crear modelos estadísticos de las
actividades de los negocios. Data Mining es el proceso para
descubrir e interpretar patrones desconocidos en la
información mediante los cuales resolver problemas de
negocio. Los usos más habituales del Data Mining son:
segmentación, venta cruzada, sendas de consumo,
clasificación, previsiones, optimizaciones, entre otros.

(Cano, 2007, p. 132-133)

Herramientas OLAP

Josep Lluís Cano expresa que “existen distintas tecnologías que nos
permiten analizar la información que reside en un Data Warehouse, pero la
más extendida es el OLAP” (2007, p. 125).

El autor también sostiene que:

Los usuarios necesitan analizar información a distintos niveles de

agregación y sobre múltiples dimensiones: Por ejemplo, ventas de
productos por zona de ventas, por tiempo, por clientes o tipo de
cliente y por región geográfica. Los usuarios pueden hacer este
análisis al máximo nivel de agregación o al máximo nivel de
detalle. OLAP provee de estas funcionalidades y algunas más, con
la flexibilidad necesaria para descubrir las relaciones y las

36
 tendencias que otras herramientas menos flexibles no pueden
aportar.

A estos tipos de análisis les llamamos multidimensionales, porque

nos facilitan el análisis de un hecho desde distintas perspectivas o
dimensiones. Esta es la forma natural que se aplica para analizar la
información por parte de los tomadores de decisiones, ya que los
modelos de negocio normalmente son multidimensionales.

(Cano, 2007, p. 126)

Generalmente, al hablar de análisis multidimensional u OLAP (Online

Analytical Processing, en Inglés) pensamos en un cubo, puesto que es la
representación gráfica habitual del mismo.

Como puede verse en el siguiente ejemplo de Josep Lluís Cano, tenemos un

cubo con la cantidad de unidades vendidas de cada uno de los libros (libro
1, libro 2 y libro 3), para cada uno de los clientes (cliente 1, cliente 2,
cliente 3) y en cada uno de los distintos años (año 1, año 2, año 3):

Imagen 5: Cubo OLAP

Fuente: Josep Lluís Cano (2007, p. 127)

37
En el ejemplo anterior, la cantidad de unidades vendidas de cada uno de
los libros por cliente y por año es lo que se denomina un Hecho. A su vez,
las dimensiones son:

 Clientes

 Libros

 Años (Tiempo).

Incluso, una dimensión dada puede tener una jerarquía específica. Por
ejemplo, generalmente la dimensión Tiempo tiene una jerarquía del tipo:

 Año

 Mes

 Día.

Aunque, dependiendo el modelo de negocio, puede requerirse el análisis

por semestre, trimestre, semana, intervalos horarios, día de la semana
(lunes, martes, etc.).

Por otra parte, las Herramientas OLAP permiten realizar diferentes

operaciones sobre los cubos:

 Slice

 Dice

 Roll-Up

 Drill-Down

 Roll-Across

 Drill-Across

 Pivot.

38
Herramientas de Visualización por Lógica Asociativa

De acuerdo con Josep Lluís Cano, “una alternativa al OLAP son las
herramientas que utilizan consultas de lógica asociativa” (2007, p. 131). En
este tipo de herramientas, cuando se realiza una consulta se accede
directamente a los datos (ya sea de la base de datos transaccional o al Data
Warehouse preferentemente) pero sin diseñar un cubo, sin dimensiones ni
jerarquías predefinidas y sin restricciones en cuanto al volumen de
información.
El modelo de almacenamiento interno proporciona una visión
“vertical” (basada en columnas) de los datos así como una visión
“horizontal ampliada” (basado en fi las) que va más allá de la
tecnología de bases de datos relacionales. Cada columna
almacena cada valor diferente de forma separada con la
frecuencia y usos de cada valor. Las consultas son altamente
eficientes por el nuevo modelo de almacenamiento y el conjunto
de operaciones utilizados para resolver las consultas.

Se indexan automáticamente el 100% de los datos y se eliminan

automáticamente los datos redundantes y los valores nulos, lo
que significa un menor uso de espacio de disco y menores
tiempos de escritura y lectura.

(Cano, 2007, p. 132)

Este tipo de herramientas ha tenido un gran auge en los últimos años, en

detrimento de las soluciones OLAP, puesto que las primeras reducen
drásticamente los tiempos de desarrollo e implementación de una solución
BI.

39
Bibliografía Lectura 1

 Harris, H. (2014, 30 de Abril). The History of Business Intelligence

[post de la web]. Recuperado de:
http://www.businesscomputingworld.co.uk/the-history-of-
business-intelligence-infographic/

 Cano J. L. (2007). Business Intelligence: Competir con Información.

España: Banesto Fundación Cultural y ESADE.

 Evelson, B. (2008). Topic Overview: Business Intelligence.

Recuperado el 30 de Abril de 2014:
http://www.forrester.com/Topic+Overview+Business+Intelligence/-
/E-RES39218?objectid=RES39218

 Gartner (s.f.). IT Glossary - Business Intelligence. Recuperado el 30

de Abril de 2014: http://www.gartner.com/it-glossary/business-
intelligence-bi

 Inmon William (2005). Building the Data Warehouse (4º Edición).

Estados Unidos: Wiley Publishing.

 Kimball Ralph, R. M. (2013). The Data Warehouse Toolkit (3º

Edición). Estados Unidos: Wiley Publishing.

 Laudon Kenneth, L. J. P. (2004). Sistemas de Información Gerencial:

administración de la empresa digital (8º Edición). México: Pearson
Educación.

 López Gutiérrez, M. (2004, 30 de Abril). El lugar de los DSS en el

proceso de toma de decisión. GestioPolis [post de la web].
Recuperado de 2014: http://goo.gl/Xy2REl

 Parr Rud, O. (2009). Business Intelligence Success Factors: Tools for

Aligning Your Business in the Global Economy. Hoboken, New
Jersey: John Wiley & Sons.

www.uesiglo21.edu.ar

40
Módulo 2
Arquitectura de
Soluciones de BI
2. Arquitectura de
Soluciones
“Un Data Warehouse es una colección de información creada
para soportar las aplicaciones de toma de decisiones”

(Cano, 2007, p. 114)

2.1 Data Warehouse: Definición

En el Módulo 1 definimos el concepto de Data Warehouse o Almacén de

Datos como el componente central dentro del Corporate Information
Factory (CIF) y, en general de toda solución de Business Intelligence (BI).

A continuación, analizaremos dos aspectos fundamentales en la

construcción de un Data Warehouse:

 Granularidad

 Particionamiento

Granularidad

De acuerdo con William Inmon (2005), el aspecto más importante en el

diseño de un Data Warehouse es la granularidad, la cual se refiere al nivel
de detalle o sumarización de las unidades de datos dentro del Data
Warehouse.

Mientras más detalle tenga el Data Warehouse, más bajo será el nivel de
granularidad. A menor detalle, mayor nivel de granularidad. Por ejemplo,

1
 una única transacción estaría en el nivel más bajo de granularidad,
mientras que un resumen de todas las transacciones realizadas durante el
mes en curso estaría en un nivel más alto de granularidad.

En los sistemas operacionales/transaccionales siempre se almacena en las

bases de datos a un bajo nivel de granularidad, es decir, máximo detalle.
Sin embargo, en el Data Warehouse (si bien es recomendable) no siempre
es así.

Se dice que la granularidad es el principal aspecto de diseño de un Data

Warehouse debido a que afecta profundamente el volumen de datos
general que reside en el Data Warehouse y el tipo de consultas que se
pueden ejecutar. Mientras más bajo sea el nivel de granularidad, más
versátil será el Data Warehouse a la hora de poder responder distintos
tipos de consultas.

Imagen 1: Granularidad

Granularidad
El nivel de Detalle

Nivel Alto de Detalle Nivel Bajo de Detalle

Bajo Nivel de Granularidad Alto Nivel de Granularidad

Ejemplo: Ejemplo:
El detalle de cada llamada El resumen de llamadas
telefónica realizada por un telefónicas realizadas por un
cliente para un mes cliente para un mes

Fuente: Elaboración propia en base a William Inmon (2005, p. 42)

2
Según William Inmon (2005), los beneficios de un bajo nivel de
granularidad son los siguientes:

 Los datos granulares del Data Warehouse son la clave para la

reusabilidad, dado que pueden ser usados por distintas personas y
de diversas maneras (un usuario quizás quiera ver los datos
sumarizados por mes, otro por año, otro por región geográfica,
entre otras dimensiones posibles).

 La capacidad para conciliar datos: si hay discrepancias entre dos o

más departamentos sobre un determinado valor de una métrica o
cálculo, existe un sólido y único fundamento detallado sobre el cual
indagar.

 La flexibilidad para formatear los datos según las necesidades de los

usuarios de distintos departamentos.

 Contiene una historia detallada de las actividades y eventos de la

corporación.

 Pero el principal beneficio es que permite acomodarse a los

requerimientos futuros. Con un Data Warehouse de bajo nivel de
granularidad se logra mejorar sustancialmente la adaptación al
cambio frente a nuevos requerimientos.

 Permite, además, responder con precisión a determinadas

consultas o requerimientos, lo cual no podría ser posible si los datos
estuvieran sumarizados.

 Permite la construcción de Data Marts o tablas sumarizadas a

partir de los datos detallados.

 Permite la optimización de los procesos de

Visualización/Exploración y Data Mining, que requieren de datos
detallados e históricos para descubrir patrones ocultos en los datos.

3
Niveles Duales de Granularidad y Tablas Sumarizadas

Sin embargo, William Inmon (2005) destaca que cuando una organización
tiene gran necesidad de eficiencia en el almacenamiento y acceso a los
datos, y a la vez la necesidad de contar con la capacidad de analizar datos
en detalle sobre un Data Warehouse de gran volumen de datos, debería
considerarse la posibilidad de contar con dos o más niveles de granularidad
en simultáneo.

De esta manera, puede tenerse una tabla detallada y una o más tablas
sumarizadas que favorecen determinadas consultas al estar ya pre-
calculadas; es decir, además de contar con una estructura de tablas con
todos los registros históricos detallados, contar también con tablas que
sumaricen esos registros para facilitar las consultas y mejorar la
performance de las aplicaciones DSS que usen el Data Warehouse como
fuente.

Estas tablas sumarizadas tienen, notoriamente, menos registros. Según

William Inmon (2005), hay que tener en cuenta que aproximadamente el
95% del procesamiento de un DSS corre sobre datos sumarizados y sólo un
5% sobre datos detallados (esto se debe a que, por lo general, los
directivos de una organización están interesados en conocer los grandes
números -cómo van las ventas, por ejemplo-, y no el detalle completo de
cada transacción en particular).

Por lo tanto, contar con niveles duales de granularidad puede permitir

procesar la mayoría de los requerimientos de manera eficiente, accediendo
generalmente a la tabla sumarizada y solo en casos puntuales a los casos
detallados.

Según William Inmon (2005), y en función de lo anterior, contar con niveles

duales de granularidad es la mejor opción arquitectónica para un Data
Warehouse.

4
Particionamiento

De acuerdo con William Inmon (2005), después de la granularidad, un

segundo aspecto de importancia en el diseño de un Data Warehouse es el
particionamiento, el cual se refiere a la división o partición de los datos en
tablas o unidades físicas separadas que pueden ser manejadas
independientemente.

Un particionamiento apropiado permite mejorar el Data Warehouse en

cuanto a la carga, acceso, archivado, eliminación, monitoreo y
almacenamiento de los datos.

Las pequeñas unidades o tablas pueden ser:

 Reestructuradas

 Indexadas

 Secuencialmente escaneadas

 Reorganizadas

 Recuperadas

 Monitoreadas.

El particionamiento puede hacerse a nivel del motor de Base de Datos

(DBMS, DataBase Management System en inglés) o incluso del sistema
operativo y a nivel de aplicación. Cada enfoque tiene sus ventajas y sus
desventajas. Cuando se hace a nivel de aplicación, presenta un mayor
grado de flexibilidad.

Los datos pueden dividirse por muchos criterios, tales como:

 Por Fecha

 Por Unidad de negocios

 Por Región Geográfica

 Por Unidad organizacional

 Por todo lo anterior.

5
 Aunque definitivamente la fecha es un criterio mandatorio, casi siempre es
empleado. Incluso, en ocasiones puede ser necesario hacerlo ya que la
definición o estructura de los datos puede variar de un año a otro. Por
ejemplo, en lugar de tener una tabla con gran cantidad de registros,
podríamos tener varias tablas con las actividades de los años 2009, 2010,
2011, 2012 y 2013, por separado.

Imagen 2: Particionamiento

2009
------- 2010
------- -------
------- -------
-------

2011
-------
-------
-------

2013
-------
-------
2012
-------
-------
-------
-------

Fuente: Elaboración propia en base a William Inmon (2005, p. 42)

6
 2.2 Datawarehouse: Comparación con
OLTP

Según William Inmon (2005), es importante hacer la distinción entre datos

primitivos y datos derivados. Los datos primitivos son los que se almacenan
en las bases de datos por los propios sistemas transaccionales (OLTP),
mientras que los datos derivados son en realidad una transformación de
los mismos para poder ser usados por los DSS con el objeto de tomar
decisiones.

Las diferencias son las siguientes:

Tabla 1: Comparación con OLTP

Datos Primitivos / Operacionales Datos Derivados / Decisionales (DSS)

(OLTP)

Están orientados y organizados según Esta orientados y organizados por área

las necesidades de cada aplicación de interés

Detallado Detallado y Sumarizado

Preciso al momento del acceso Representa valores en el tiempo,

(valores actuales) históricos, snapshots

Sirve a la comunidad operativa de la Sirve a la comunidad directiva de la

organización organización

Pueden actualizarse No se actualizan

Las aplicaciones corren Las aplicaciones corren

repetitivamente sobre ellos heurísticamente sobre ellos

Requerimientos de procesamiento Requerimientos de procesamiento NO

comprendidos a priori comprendidos a priori

Compatibles con el ciclo de vida de Ciclo de vida completamente diferente

desarrollo de software

Sensible a la performance Relajado en cuanto a performance

Accedidos una unidad por vez Se accede a un conjunto por vez

(valores sumarizados)

7
Datos Primitivos / Operacionales Datos Derivados / Decisionales (DSS)
(OLTP)

Gestionado por la transacción Gestionado por el análisis de

información

Control de las actualizaciones en El control de las actualizaciones no

términos de propiedad o dueño del interesa
dato

Alta disponibilidad Disponibilidad más relajada

Gestionado en su completitud Gestionado por subconjuntos

Sin redundancias Se permiten las redundancias

Estructura estática, contenido Estructura flexible

variable

Pequeñas cantidades de datos usados Grandes cantidades de datos usados

en un proceso en un proceso

Soporta las operaciones diarias Soporta las necesidades gerenciales de

la organización

Alta probabilidad de acceso a un dato Baja probabilidad de acceso a un dato

en particular en particular

Naturaleza dinámica de los datos Naturaleza estática hasta el próximo

refresh de datos

Se usan para el procesamiento Se usan para el procesamiento

repetitivo de los datos, altamente analítico de los datos, altamente
estructurado desestructurado

Estructura con muchas tablas Estructura con pocas tablas de-

altamente normalizadas normalizadas
Fuente: Elaboración propia en base a William Inmon (2005, p. 15)

8
En definitiva, según William Inmon (2005) las principales diferencias entre
ambos esquemas son:

 Los datos primitivos son datos detallados, usados para ejecutar las
operaciones diarias de la organización. Los datos derivados han sido
sumarizados o pre-calculados para satisfacer las necesidades de la
gerencia.

 Los datos primitivos pueden actualizarse. Los datos derivados no

pueden re-calcularse porque no pueden ser actualizados
directamente.

 Los datos primitivos son datos de valor actual. Los datos derivados
son datos históricos.

 Los datos primitivos son operados por procedimientos repetitivos.

Los datos derivados son operados por programas heurísticos, no
repetitivos.

 Los datos de los sistemas transaccionales OLTP son datos primitivos.

Los datos de los sistemas DSS son datos derivados.

 Los datos primitivos apoyan las tareas operativas. Los datos

derivados soportan la toma de decisiones gerenciales.

2.3 Tipos de Implementación

Existen dos modelos básicos para el diseño de la base de datos de un Data

Warehouse:

 El Modelo Relacional (propuesto y defendido por William Inmon)

 El Modelo Multidimensional (propuesto y defendido por Ralph

Kimball).

De acuerdo con William Inmon (2005):

 En el Modelo Relacional, los datos están altamente normalizados

(tercera forma normal). Esta normalización implica que el diseño de
la base de datos genere un muy bajo nivel de granularidad. El valor
del modelo Relacional para el Data Warehouse es que hay disciplina
en la forma en que se construye el diseño de la base de datos,
claridad del significado y uso del nivel detallado de datos

9
 normalizados bajo la tercera forma normal. Así, el modelo
Relacional produce un diseño muy flexible. Flexibilidad en términos
de que el diseño puede adaptarse a distintas vistas. Esta es la mayor
fortaleza junto con la versatilidad, dado que los datos detallados
pueden combinarse: pueden soportarse muchas vistas distintas.

 En cambio, el Modelo Multidimensional, también conocido como

esquema Estrella (o Star Join) tiene una tabla Fact (tabla de Hechos)
en el centro del modelo, que contiene gran cantidad de registros,
de-normalizados, y alrededor de ella una serie de tablas de
Dimensiones que describen cada uno de los campos de la tabla
Fact. Generalmente, las Dimensiones tienen pocos registros (sobre
todo en comparación con la Fact) y contienen información
relevante separada (ubicación de sucursales, calendario, etc.). La
tabla Fact y las tablas de dimensiones están asociadas por un
campo referencial en común. La gran ventaja del modelo
Multidimensional es su eficiencia de acceso. Su estructura se basa
en los requerimientos del usuario.

En la Unidad 3 (Módulo 3) dedicaremos más tiempo a trabajar con

el modelado multidimensional.

Las principales diferencias entre ambos modelos, según William Inmon

(2005), son:

 El Modelo Relacional es altamente flexible, pero no está optimizado

en términos de performance para ningún usuario en particular. El
modelo Multidimensional es altamente eficiente al servir las
necesidades de una comunidad de usuarios en particular, pero no
es bueno en cuanto a su flexibilidad.

 El modelo Multidimensional tiene un alcance más limitado en el

sentido de que el diseño se optimiza para un conjunto de
requerimientos de usuarios, se ajusta mejor a los requerimientos de
un departamento. En cambio, el modelo Relacional está orientado a
un alcance mayor (modelo empresarial).

 El modelo Relacional está basado en un modelo de datos

corporativo o empresarial, mientras que el modelo
Multidimensional lo está en función de un modelo basado en los
requerimientos de procesamiento para satisfacer las demandas del
usuario.

 Si bien el modelo Relacional no es óptimo en performance para el

acceso directo a los datos, debido a su diseño flexible pueden
generarse estructuras especiales (tablas sumarizadas) para un
acceso indirecto a los datos más óptimo. En estos términos, el

10
 modelo Multidimensional ofrece una performance similar con un
acceso directo a los datos.

2.4 Arquitectura

La Arquitectura de William Inmon

William Inmon (2005) sentó las bases de la primera definición

arquitectónica de BI en base al Corporate Information Factory, tal como ya
vimos en la Unidad 1 (Módulo 1).

Además, sostiene que el modelo Relacional es mucho mejor para el diseño

de un Data Warehouse dado que se necesita soportar el acceso de muchos
usuarios distintos con diferentes requerimientos. Es decir, considera que el
Data Warehouse no debe estar optimizado para el acceso de un usuario en
particular.

Para William Inmon (2005), la clave está en el “reshaping” del modelo

Relacional. Debido al nivel de granularidad que provee este modelo, es
relativamente fácil crear tablas “sumarizadas” que se elaboran a partir de
necesidades específicas de un conjunto único de usuarios.

De esta manera, esta tabla sumarizada se encuentra lista para su acceso

directo, altamente eficiente en términos de performance. Se pueden crear
tantas tablas sumarizadas como sean necesarias. La sencillez de su creación
se deriva de que:

 Los datos están almacenados al nivel más granular, más

normalizado.

 Las relaciones entre tablas relacionales ya están identificadas.

 Nuevas tablas pueden contener nuevas sumarizaciones, nuevos

criterios de selección y nuevas agregaciones.

En el caso del modelo Multidimensional, dado que está optimizado para un

grupo único de usuarios, cualquier otro usuario debe pagar el precio de
una performance que no es la óptima. Según William Inmon (2005), este
modelo no garantiza la optimización para todos los usuarios para todos sus
requerimientos.

11
La ventaja del modelo Relacional apunta a su flexibilidad al cambio, hacia
nuevos requerimientos o nuevos grupos de usuarios que tienen
necesidades distintas.

Las tablas sumarizadas proveen agregaciones de los datos a nivel granular,

es decir, cualquier combinación de átomos. Además, otra ventaja se deriva
de que si para otro usuario se requiere otro cálculo, no es necesario tocar
el modelo base, ya que simplemente se agrega una nueva tabla
sumarizada. Se reduce y aísla el impacto al cambio. En el modelo
Multidimensional, en cambio, el impacto puede ser mucho más profundo,
al tener que cambiar la misma estructura.

Debido a estas causas William Inmon (2005) sostiene que el modelo

Relacional es ideal para el diseño de un Data Warehouse, mientras que el
modelo Multidimensional es ideal para el diseño de un Data Mart.

William Inmon (2005) alega que los Data Warehouses se diseñan a partir
de los requerimientos de información corporativos de toda la organización,
y no desde los requerimientos departamentales (como un Data Mart). Por
lo tanto, crear un Data Warehouse con un modelo Multidimensional sería
un error ya que el resultado será un Data Warehouse optimizado para una
comunidad de usuarios a expensas de otros usuarios.

La Arquitectura de Ralph Kimball

Ralph Kimball (2013), en cambio, sostiene que el Data Warehouse debería

basarse sobre un Modelo Multidimensional, también con datos detallados.

Según su enfoque, el paso final de los procesos ETL consiste en la carga de

los datos en la estructura física bajo un modelo multidimensional, tablas
que luego serán la base del área de presentación de BI (las aplicaciones
DSS). Estos subsistemas ETL son críticos, muchos de los cuales se enfocan
en el procesamiento de las tablas de dimensión, mientras que las tablas de
hechos si bien tienen muchos registros, no suelen demandar gran
preparación. Una vez actualizadas, indexadas y con la calidad de datos
asegurada, estas tablas son publicadas para los usuarios.

Existe un debate respecto de si los datos debieran cargarse primero en una

estructura normalizada previo a cargarlos en un modelo dimensional para
la consulta y reporting. Si bien esto es aceptable, la creación de estructuras
normalizadas para el ETL y estructuras dimensionales para el área de

12
presentación implican doble proceso de ETL, lo cual requiere más tiempo e
inversión para el desarrollo, mayor tiempo de actualización de los datos y
más capacidad para almacenar las múltiples copias de datos. Aunque la
consistencia de datos a nivel empresarial es un objetivo fundamental de un
Data Warehouse, puede ser más efectivo y menos costoso no incluir en el
ETL estas estructuras normalizadas.

El Área de Presentación BI es aquella donde los datos se organizan,

almacenan y están disponibles para la consulta de los usuarios y
aplicaciones analíticas. Dado que las herramientas ETL están fuera de sus
límites, esta área es todo lo que ven los usuarios.

Ralph Kimball (2013) insiste en que los datos sean presentados,

almacenados y accedidos en esquemas multidimensionales.

Además, insiste en que el área de presentación debe tener datos

detallados, atómicos, los cuales se requieren para responder a consultas de
usuarios ad hoc, impredecibles. Aunque contenga datos sumarizados con
alta performance, no es suficiente con entregar esta información sin contar
con los datos granulares en una forma dimensional. Es decir, es inaceptable
guardar datos sumarizados en modelos dimensionales teniéndolos en
estructuras normalizadas.

El Área de Presentación BI debería ser estructurada alrededor de los

eventos de medición del proceso de negocio. Este enfoque se alinea con
los sistemas operacionales. Los modelos dimensionales deberían
corresponderse a los eventos de captura de datos físicos, no deben
diseñarse para entregar el reporte del día. Los procesos de negocio cruzan
los límites de los departamentos de la organización. Debe construirse una
sola tabla de hechos con los datos atómicos de las ventas en lugar de
generar estructuras separadas similares.

Todas las estructuras dimensionales deben diseñarse usando dimensiones

comunes. Esta es la base del Enterprise Data Warehouse Bus Architecture.
Sin dimensiones compartidas, un modelo dimensional se vuelve una
aplicación standalone. Los datos aislados generan vistas incompatibles de
la empresa. Con dimensiones compartidas, los modelos dimensionales
pueden ser compartidos. En una gran empresa, podemos encontrar una
docena de modelos dimensionales combinados con tablas de dimensión
compartidas.

Aunque la arquitectura de Kimball habilita normalización opcional para

soportar el procesamiento ETL, el Enterprise Data Warehouse normalizado
es un requisito obligatorio en el Corporate Information Factory de Inmon.

13
Al igual que el enfoque de Kimball, el Corporate Information Factory
subraya la coordinación e integración de datos empresariales. El Corporate
Information Factory dice que el Enterprise Data Warehouse normalizado
satisface este rol, mientras que la arquitectura de Kimball recalca la
importancia de un Enterprise Data Warehouse Bus Architecture con
dimensiones compartidas.

La Arquitectura Híbrida Inmon – Kimball

Según Ralph Kimball (2013), se puede plantear una arquitectura híbrida

que integre los conceptos tanto de uno como de otro enfoque.

Esta arquitectura carga un Enterprise Data Warehouse al estilo del

Corporate Information Factory, que está completamente fuera de alcance
para los usuarios para reporting y análisis. Es solo la fuente para cargar un
área de presentación tipo Kimball en la cual los datos son
multidimensionales, atómicos/muy detallados (complementados por
sumarizaciones), centrado en procesos, y dentro del Enterprise Data
Warehouse Bus Architecture.

Este enfoque trae lo mejor de los dos mundos, pero este esquema híbrido
sólo puede ser apropiado si la empresa ya invirtió en un Enterprise Data
Warehouse normalizad, porque iniciar desde cero implica más costos y más
tiempo, tanto en desarrollo como operación continua, dados los múltiples
movimientos de datos y almacenamiento redundante de datos detallados.

Desarrollo Iterativo del Data Warehouse

De acuerdo con William Inmon (2005), es conveniente construir un Data

Warehouse de manera iterativa ya que el usuario es incapaz de articular
muchos requerimientos hasta que la primera iteración finalice, además de
que la gerencia generalmente no se compromete por completo hasta ver
algunos resultados tangibles.

Ralph Kimball (2013) sostiene desde su enfoque que usando el Enterprise

Data Warehouse Bus Architecture puede desarrollarse un Data Warehouse
de manera iterativa, gradual, ágil, descentralizada.

14
2.5 Datamart

Arquitecturas Disponibles

En cuanto al diseño de los Data Marts, también podemos destacar distintos

tipos de arquitecturas disponibles.

 Data Marts aislados/independientes

 Data Marts interconectados/dependientes

Data Marts Independientes

De acuerdo con William Inmon (2005), la arquitectura de Data Marts

Independiente consiste en diseñarlos directamente desde las aplicaciones
fuente (sistemas transaccionales). Un Data Mart Independiente puede ser
creado por un departamento, sin consideración alguna de otros
departamentos ni la participación del área centralizada de Sistemas.

Un Data Mart independiente representa el conjunto de requerimientos de

BI de un sector en particular, por ello es relativamente fácil, rápido y
económico de construir, a la vez que le permite a ese sector o
departamento manejar por sí mismo su política de BI. Es por esto que son
tan populares.

Con este enfoque, los datos analíticos se despliegan en una base

departamental sin consideraciones de compartir e integrar información a lo
largo de la empresa. Generalmente, un único departamento identifica los
requerimientos de datos desde un sistema operacional. Así, se construye
una base de datos que satisface sus necesidades departamentales, pero
este Data Mart departamental refleja sólo los requerimientos analíticos del
departamento al trabajar en forma aislada.

Mientras tanto, otro departamento se interesa en los mismos datos fuente,

pero dado que no tiene acceso al Data Mart inicialmente construido por el
otro, procede de manera similar construyendo una solución departamental
aislada. De esta manera, cuando los usuarios se reúnen a discutir sobre una
misma métrica, encontramos dos visiones distintas porque el cálculo no

15
necesariamente dio el mismo resultado al usar distintas fórmulas o reglas
de negocio.

Algunos de los defensores del modelo Multidimensional favorecen esta

estrategia. Por su parte, William Inmon (2005) sostiene que se trata una
estrategia de corto plazo, de enfoque limitado, ya que no provee una base
firme para la consolidación de la información corporativa.

En su análisis, los Data Marts Independientes presentan varias desventajas:

 No proporcionan una plataforma para la reusabilidad.

 No proporcionan una base para la reconciliación de datos.

 No proporcionan un único conjunto de programas de interfaz (ETL)

con las aplicaciones transaccionales.

 Requieren que cada Data Mart independiente construya su propio

“pool” de datos detallados, lo cual es redundante con otros Data
Marts independientes de la misma empresa.

Ralph Kimball (2013) también sostiene que es una estrategia de desarrollo

rápida, de bajo costo en el corto plazo; pero múltiples extracciones de
datos no coordinadas y el almacenamiento redundante de datos analíticos
son ineficientes y de alto costo en el largo plazo.

Sin una perspectiva empresarial, este enfoque termina en una gran

cantidad de aplicaciones aisladas y vistas incompatibles del desempeño
organizacional. Kimball también desaconseja este enfoque.

Imagen 3: Data Marts Independientes

Fuente: Josep Lluís Cano (2007, p. 118)

16
Data Marts Dependientes

Según William Inmon (2005), la arquitectura de Data Marts Dependientes

se basa en un Data Warehouse centralizado; los datos de los Data Marts
provienen de allí (tal cual se plantea en el Corporate Information Factory).

Es decir, el Data Mart dependiente no depende de los datos operacionales,

sino del Data Warehouse. Esta estrategia requiere, desde luego, de una
mayor inversión, planificación, perspectiva a largo plazo y cooperación y
coordinación en la definición de los requerimientos entre los diferentes
departamentos de la organización.

De acuerdo con William Inmon (2005), un aspecto clave es cómo transferir

los datos desde el Data Warehouse hacia el Data Mart. Los datos en un
Data Warehouse están muy detallados, con bajo nivel de granularidad. Los
datos en un Data Mart suelen estar más compactos y sumarizados.
Periódicamente deben enviarse los datos de una estructura a la otra. Este
movimiento es análogo a un proceso ETL. Además, los Data Marts se
diseñan, generalmente, siguiendo un modelo Multidimensional.

Asimismo, la estructura de datos multidimensional en cada uno de los Data

Marts está especialmente diseñada para cada uno de los requerimientos
departamentales. Así, cada departamento requerirá una estructura de
Data Mart distinta. Todas estas estructuras se alimentarán desde el mismo
Data Warehouse y pueden estar en una base de datos relacional (esquema
multidimensional conocido como “Star Join”) o en una base de datos
multidimensional (cubos OLAP).

De acuerdo con William Inmon (2005), diferentes Data Marts requieren

distinto nivel de granularidad. Ahora, para poder alimentar a los distintos
Data Marts se requiere que el Data Warehouse tenga el nivel más bajo de
granularidad que cualquiera de los Data Marts que alimentará.

Imagen 4: Data Marts Dependientes

Fuente: Josep Lluís Cano (2007, p. 118)

17
Modos de Implementación

Existen dos modos de implementación de un Data Warehouse y los

respectivos Data Marts:

 Top Down, estrategia propuesta por William Inmon (2005). Como

afirma Josep Lluís Cano, “propone definir un Data Warehouse
corporativo y a partir de él ir construyendo los modelos de análisis
para los distintos niveles y departamentos de la organización; es
decir, una estrategia de arriba abajo, desde la estrategia a lo más
operativo” (2007, p. 118).

 Bottom Up, estrategia inicialmente propuesta por Ralph Kimball

(2013). Como afirma Josep Lluís Cano, propone “construir distintos
Data Marts que cubran las distintas necesidades de la organización,
sin la necesidad de construir un Data Warehouse” (2007, p. 119).

Es evidente que ambas alternativas pueden ser viables en función de las

características de cada proyecto. Cada una de ellas presenta sus propias
ventajas y desventajas.
Como afirma el Profesor Hugh J. Watson, cuando se desarrollan
correctamente las dos estrategias son válidas.

Con la estrategia de definir un Data Warehouse corporativo, el

Data Warehouse es desarrollado en fases y cada una de las
mismas debe ser diseñada para generar valor para el negocio. Se
construye un Data Warehouse corporativo, del que se cuelga un
Data Mart dependiente con una parte de la información del Data
Warehouse. En fases posteriores se van desarrollando Data Marts
usando subconjuntos del Data Warehouse. Igual que los proyectos
complejos, es caro, necesita mucho tiempo y es propenso al
fracaso. Cuando tenemos éxito conseguimos un Data Warehouse
integrado y escalable.

Si optamos por la estrategia más común, la de construir distintos

Data Marts, el proyecto comienza con un Data Mart único al que
posteriormente se irán añadiendo otros Data Marts que cubrirán
otras áreas de negocio. Normalmente no requiere de grandes
inversiones y es fácil de implementar, aunque conlleva algunos
riesgos; de entre ellos, cabe destacar fundamentalmente dos:
puede perpetuar la existencia del problema de “silos de

18
 información” y posponer la toma de decisiones que conciernen a
la definición de criterios y modelos de negocio. Si seguimos esta
estrategia debemos tener claro el plan de acción, es decir, qué
áreas cubriremos y la integración de los distintos modelos. Esta
estrategia se utiliza a veces como un paso previo al desarrollo de
un Data Warehouse corporativo.

Las dos aproximaciones abogan por construir una arquitectura

robusta que se adapte fácilmente a los cambios de las
necesidades de negocio y que nos proporcione una sola versión
de la verdad.

(Cano, 2007, p. 119)

2.6 Data Mining

Definición

Según un informe de Two Crows Corporation (1999), la Minería de Datos

(más conocida por el término Data Mining, en Inglés) consiste en la
búsqueda de patrones y relaciones ocultas en los datos de las
organizaciones.

Data Mining no es más que la aplicación de algoritmos específicos al Data

Warehouse para obtener resultados útiles. En otras palabras, consiste en la
aplicación de técnicas matemáticas, estadísticas y principalmente de
Inteligencia Artificial para descubrir relaciones, patrones y tendencias en
los datos almacenados por una organización.

Actualmente, existen enormes bases de datos en donde se encuentra

oculta información estratégica de gran relevancia, a la que no se puede
acceder a través de las técnicas tradicionales de recuperación de
información. Para revelar esta información es necesario hacer uso de la
minería de datos que se trata de un proceso que utiliza una amplia
variedad de herramientas de análisis de datos para descubrir patrones y
relaciones en los datos, los cuales son utilizados posteriormente para
realizar predicciones válidas.

19
La minería de datos es parte de un proceso iterativo mayor llamado
descubrimiento de conocimiento en base de datos (KDD, Knowledge
Discovery in Databases en Inglés).

Es importante destacar que la minería de datos no reemplaza a las técnicas

de estadísticas tradicionales, sino que, por el contrario, muchas de las
técnicas más utilizadas en la minería de datos tienen sus raíces en las
aplicaciones estadísticas, como los modelos utilizados para clustering y
segmentación.

Generalmente, no se distingue la diferencia entre OLAP (On-Line Analytical

Processing) y Data Mining. El análisis OLAP es esencialmente un proceso
deductivo: el analista OLAP genera una serie de patrones y relaciones
hipotéticas y utiliza consultas contra la base de datos para verificarlas o
refutarlas. La Minería de Datos difiere del análisis OLAP puesto que, en
lugar de verificar patrones hipotéticos, utiliza los datos para descubrir
patrones y es esencialmente un proceso inductivo. La minería de datos y
OLAP se pueden complementar entre sí ya que OLAP puede ser usado
antes de la minería de datos para ayudar a explorar los datos, focalizar la
atención sobre las variables importantes, identificar excepciones o
encontrar interacciones, contribuyendo de esta manera a un mayor
entendimiento de los datos.

Aplicaciones de Minería de Datos

Entre las principales aplicaciones de minería de datos, podemos detallar las

siguientes:

 Venta Cruzada (Cross Selling): las técnicas de minería se utilizan

para identificar productos que se venden bien juntos; por ejemplo,
los clientes masculinos que compran pañales, viven en el centro y
tienen entre 20 y 27 años, generalmente también compran cerveza.
De esta forma, los vendedores pueden diagramar la distribución en
góndolas (poner estos productos más cerca o más lejos) y planificar
su publicidad, entre otras estrategias basadas en este
conocimiento.

 Control de Calidad: aquí la aplicación se basa en procesar la

información de seguimiento de los procesos productivos en busca
de desviaciones anormales de los mismos, tendencias y demás
indicadores de un proceso fuera de control.

 Retención de Clientes: esta área se avoca a la tarea de conservar

los clientes y, si es posible, hacerlos leales. En dicho proceso las

20
 técnicas de minería nos ayudan a identificar los aspectos
característicos de nuestros servicios que han hecho leales a algunos
de nuestros clientes para tratar de replicarlos con los demás
clientes. Además, nos puede informar sobre las características
particulares de nuestros clientes leales para obtener un perfil de los
mismos y luego focalizar las campañas de incorporación de nuevos
clientes en personas con el mismo perfil, es decir, con una alta
probabilidad de tener una relación a largo término con la empresa.

 Adquisición de Nuevos Clientes: Se complementa con la anterior.

Es la tarea de conseguir nuevos clientes, es decir, de utilizar minería
para determinar estrategias dirigidas a ganar nuevos clientes. La
minería nos ayudará a definir la mejor estrategia de adquisición,
analizando campañas anteriores y el mejor grupo de personas que
será el blanco de la misma.

 Análisis de la Lealtad del Cliente: consiste en minar los datos de los

consumidores para extraer modelos de lealtad que muestren el
grado de lealtad a un determinado producto o marca. De esta
manera, la compañía puede determinar niveles de lealtad y diseñar
estrategias diferenciadas para cada nivel.

 Marketing Dirigido: para realizar marketing dirigido es necesario

poder identificar subconjuntos de la población que responderán
más probablemente a una campaña publicitaria: en el caso de la
adquisición de nuevos clientes, será la población en general; si se
trata de lanzamiento de nuevos productos, estarán incluidos
también los clientes actuales. Mientras mejor seleccionados estén
los miembros del subconjunto elegido, más efectiva será la
campaña y esto se traducirá en mejores beneficios y menores
costos debido a la focalización de los recursos.

 Prevención de Fraude: uso de la minería de datos para detectar

patrones de fraude.

 Administración del Riesgo: las aseguradoras deben poder calcular

en forma precisa los riesgos asociados a cada una de las pólizas que
otorgan y verificar que los valores de las mismas se correspondan
con los riesgos asociados; es decir que no se debe sobrevalorar una
póliza que implica un riesgo pequeño y, de la misma forma,
tampoco se debe infravalorar una póliza que tiene un riesgo muy
alto. Muchos de los factores que afectan el riesgo asociado a un
evento son claros, pero pueden existir algunas relaciones más
sutiles, no intuitivas, entre las variables que son difíciles de discernir
si no se les aplican herramientas de análisis más perfeccionadas. Las
técnicas modernas de minería ofrecen un modelo más preciso y

21
 más eficiente que las tecnologías anteriores. Los algoritmos de
minería permiten echar luz sobre tendencias y relaciones que no
son evidentes en los grandes cúmulos de datos, y las nuevas
técnicas gráficas permiten visualizar complejos modelos de
información que facilitan el análisis y la comparación. Las técnicas
de minería ayudan a los aseguradores a segmentar sus clientes para
poder tratarlos de forma diferenciada y dividirlos en subconjuntos
con un riesgo asociado a cada grupo.

Operaciones de Minería de Datos

Entre las principales operaciones de Minería de Datos, podemos mencionar

las siguientes:

 Modelado Predictivo

 Análisis de Relaciones

 Segmentación de Bases de Datos

 Detección de Desviaciones

Técnicas de Minería de Datos

Antes de poder diseñar buenos modelos predictivos, es necesario en

primer lugar llegar a una comprensión (entiéndase por el conocimiento) de
los datos.

En primera instancia, el proceso se inicia recuperando una variedad de

resúmenes numéricos (incluyendo estadísticas descriptivas tales como:
promedios, desviaciones estándar y otras), como así también observando
cuidadosamente la correspondiente distribución de los datos.

En algunos casos, incluso, es deseable producir tabulaciones cruzadas (o

pivot tables) para datos de carácter multidimensional.

Los datos pueden, desde ya, ser continuos, caso en el cual pueden asumir
cualquier valor numérico (por ejemplo, la cantidad vendida); o discretos,
incluidos dentro de clases discretas (como azul, verde, rojo, etc.). Los datos
discretos pueden ser, además, definidos o categorizados en ordinales, los

22
cuales tienen un orden significativo (por ejemplo: alto, medio, bajo); o
nominales, los que están desordenados (por ejemplo, los códigos postales).

Entre las principales técnicas encontramos:

 Clustering: divide o segmenta una base datos en diferentes grupos.

El objetivo del Clustering es encontrar grupos que son muy
diferentes uno del otro y cuyos miembros son muy similares entre
sí. A diferencia de la clasificación (Minería de Datos Predictiva), en
el Clustering uno no es capaz de conocer los clusters a priori, o bien
por cuáles atributos los datos serán segmentados.
Consecuentemente, alguien que tenga un gran conocimiento del
negocio es quien debe interpretar los clusters.

 Asociaciones: se trata de una aproximación descriptiva para la

exploración de datos que puede ayudar en la identificación de
relaciones entre valores en una base de datos. Las dos
aproximaciones más comunes para el análisis de relaciones son: el
descubrimiento de asociación y el descubrimiento de secuencia. El
primero encuentra reglas sobre ítems que aparecen conjuntamente
en un evento como una transacción de compra. El análisis de la
canasta de mercado (ó simplemente conocido como análisis del
‘changuito’) es un ejemplo bastamente conocido de descubrimiento
de asociación. Por su parte, el descubrimiento de secuencia es muy
similar al anterior, con la diferencia de que se analiza una secuencia
que es una asociación relacionada a lo largo del tiempo.

 Clasificación: los problemas de clasificación ayudan a identificar las

características que indican el grupo al cual pertenece cada caso
específico. Este patrón puede ser usado tanto para comprender los
datos existentes como para predecir el comportamiento que
tendrán las nuevas instancias. Por ejemplo, puede ser deseable
predecir si los individuos serán clasificados como aquellos que
probablemente responderán a un envío de correo o se someterán a
un procedimiento quirúrgico, entre otros. La minería de datos crea
modelos de clasificación examinando los datos ya clasificados
(llamados casos), e inductivamente encuentra un patrón de
predicción.

 Regresión: usa los valores existentes para pronosticar qué otros

valores habrá. En el caso más simple, la regresión emplea técnicas
estadísticas tales como la regresión lineal.

 Series de Tiempo: los pronósticos de series de tiempo predicen

valores desconocidos en el futuro, basados sobre una serie variante
en el tiempo de predictores. Al Igual que la Regresión (explicada

23
 anteriormente), usa resultados conocidos para guiar sus
predicciones.

Imagen 5: Aplicaciones, Operaciones y Técnicas de Minería de Datos

Fuente: Elaboración Propia

24
2.7 Balanced Scorecard

“Cuando una persona puede medir aquello sobre lo que está

hablando y expresarlo con números, sabe alguna cosa sobre la
cuestión; pero cuando no puede medirlo, cuando no puede
expresarlo con números, lo que sabe es escaso e insatisfactorio”

Lord Kelvin (en Paul Niven, 2002, p. 23)

La Insuficiencia de los Indicadores Financieros

Paul Niven sostiene en su descripción del Balanced Scorecard que “desde

que existen las organizaciones empresariales, el método tradicional para
medir los resultados ha sido fijarse en los aspectos financieros” (2002, p.
29). Sin embargo, los indicadores financieros no pueden ser la única forma
de medir el desempeño de una empresa. En los últimos años han aparecido
numerosas críticas al uso excesivo de indicadores pura y estrictamente
financieros:

 Los indicadores financieros muchas veces no son del todo

compatibles con la realidad empresarial actual en el sentido de que
muchas actividades de valor agregado no se encuentran reflejadas
en los activos fijos y tangibles (valores monetarios) de una empresa.

 Los indicadores financieros proporcionan una excelente revisión

histórica de los resultados pasados de la organización, pero no
tienen poder de predicción para el futuro (por ejemplo, si la
empresa fue o no rentable el año pasado no significa que sí lo será
el próximo año).

 Tendencia a reforzar los silos funcionales. Los estados financieros

generalmente están discriminados por área o departamento
funcional de la empresa, pero no tienen en cuenta el valor y el
costo asociado a las interrelaciones entre los departamentos.

 Sacrificio del pensamiento a largo plazo. Muchas veces, los

esfuerzos por la reducción de costos pueden ser muy útiles para
mejorar determinados indicadores financieros en el corto plazo,
pero pierden de vista el largo plazo y la capacidad para crear valor

25
 agregado en la empresa (ejemplo: reduciendo el presupuesto de
investigación y desarrollo).

 Los indicadores financieros no son los adecuados para muchos

niveles de la empresa. Los empleados de todos los niveles de la
empresa necesitan datos sobre resultados con los que puedan
trabajar.

Concepto de Cuadro de Mando Integral

Como sostiene Paul Niven (2002, p. 33), “se necesita un sistema que
equilibre la exactitud histórica de las cifras financieras con los impulsores
de los resultados futuros, al mismo tiempo que ayude a las empresas a
poner en marcha sus estrategias diferenciadoras”.

En el año 1992, Robert Kaplan y David Norton plantearon el concepto de

Cuadro de Mando Integral (BSC, Balanced Scorecard en Inglés).

El Balanced Scorecard no es más que un conjunto cuidadosamente

seleccionado de indicadores derivados de la estrategia de una empresa, es
decir, es una herramienta para medir el desempeño de la empresa.

Perspectivas

El Balanced Scorecard está compuesto de cuatro grandes perspectivas:

 Clientes

 Procesos Internos

 Aprendizaje y Crecimiento

 Financiera

Perspectiva Clientes

Según Paul Niven (2002, p. 38), “al elegir las medidas (indicadores) que
formarán parte de la perspectiva del cliente dentro del cuadro de mando,
las empresas deben responder a dos preguntas fundamentales: ¿Quiénes

26
son nuestros clientes? y ¿cuál es nuestra proposición de valor al
servirlos?”.

Entre los indicadores de clientes generalmente usados en las

organizaciones, podemos encontrar los siguientes:
- Satisfacción de los clientes

- Fidelidad de los clientes

- Cuota de mercado

- Quejas de los clientes

- Quejas resueltas al primer contacto

- Tasa de rentabilidad

- Tiempo de respuesta por solicitud de cliente

- Precio directo

- Precio en relación con la competencia

- Costo total para el cliente

- Duración media de la relación

- Clientes perdidos

- Retención de clientes

- Tasa de adquisición de clientes

- Clientes por empleado

- Porcentaje de ingresos por nuevos clientes

- Número de clientes

- Ventas anuales por cliente

- Tasa de ganancia (ventas cerradas / contactos de ventas)

- Visitas de clientes a la empresa

- Horas pasadas con los clientes

- Costo comercial como porcentaje de las ventas

- Número de anuncios publicados

27
 - Número de propuestas hechas

- Reconocimiento de marca

- Tasa de respuesta

- Número de ferias con participación

- Volumen de ventas

- Gastos compartidos por cliente objetivo con clientes

- Ventas por cada canal

- Tamaño medio económico de los clientes

- Gastos por servicios a los clientes por cliente

- Rentabilidad de los clientes

- Frecuencia (numero de transacciones de venta)

(Niven, 2002, p. 174)

Perspectiva Procesos Internos

En esta perspectiva, de acuerdo con Paul Niven (2002, p. 39), “se

identifican los procesos claves en los que la empresa debe destacar para
continuar añadiendo valor para los clientes y finalmente para los
accionistas”.

Para poder satisfacer a los clientes, es necesario que los procesos de

negocio internos de la organización funcionen eficaz y eficientemente y de
esa manera cumplir con los objetivos de la empresa.

Según Paul Niven (2002, p. 39), “nuestra tarea en esta perspectiva es

identificar esos procesos y desarrollar las mejoras medidas (indicadores)
posibles con las que hacer el seguimiento de nuestros avances”.

Entre los indicadores de procesos internos generalmente usados en las

organizaciones podemos encontrar los siguientes:
- Costo medio por transacción

- Entrega a tiempo

28
- Tiempo de espera medio

- Rotación de inventario

- Emisiones medioambientales

- Gasto de investigación y desarrollo

- Participación de la comunidad

- Patentes pendientes

- Edad media de las patentes

- Relación productos nuevos / oferta total

- Falta de existencias

- Tasas utilización mano de obra

- Tiempo de respuesta a solicitudes de clientes

- Porcentaje de defectos

- Repetición del trabajo

- Disponibilidad base de datos clientes

- Momento de equilibrio

- Mejora de los tiempos cíclicos

- Mejoras continuas

- Reclamaciones de garantías

- Identificación usuario destacado

- Productos y servicios en la red

- Tasa de rentabilidad interna de proyectos nuevos

- Reducción desperdicios

- Utilización del espacio

- Frecuencia de compras devueltas

- Tiempo muerto

- Exactitud de la planificación

29
 - Tiempo necesario para salir al mercado de nuevos productos /
servicios

- Introducción de nuevos productos

- Número de historias positivas en los medios

(Niven, 2002, p. 183)

Perspectiva Aprendizaje y Crecimiento

En esta perspectiva, de acuerdo con Paul Niven (2002, pp. 39-40), “si se
quieren alcanzar resultados ambiciosos con respecto a los procesos
internos, los clientes y también los accionistas, ¿qué se puede hacer? Las
medidas concernientes a la perspectiva de aprendizaje y crecimiento son
verdaderos facilitantes de las otras tres perspectivas”.

Debido a lo anterior, también suele decirse que esta perspectiva

representa de algún modo los “cimientos” sobre los cuales se estructura el
edificio organizacional.

Entre los indicadores de aprendizaje y crecimiento generalmente usados en

las organizaciones, podemos encontrar los siguientes:
- Participación de los empleados en asociaciones profesionales o
comerciales

- Inversión en formación por cliente

- Promedio años de servicio

- Porcentaje de empleados con estudios avanzados

- Número de empleados con formación cruzada

- Ausentismo

- Tasa de rotación

- Sugerencias de los empleados

- Satisfacción de los empleados

- Participación en planes de propiedad de acciones

- Accidentes y tiempo perdido

30
- Valor añadido por empleado

- Índice de motivación

- Número de solicitudes de empleo pendientes

- Tasas de diversidad

- Índice de empowerment (número de directivos)

- Calidad del entorno laboral

- Calificación de las comunicaciones internas

- Productividad de los empleados

- Números de cuadros de mando producidos

- Promoción de la salud

- Horas de formación

- Tasa de cobertura de competencias

- Realización de metas personales

- Oportuna conclusión de valoración de actividades

- Desarrollo de liderazgo

- Planificación de la comunicación

- Accidentes dignos de mención

- Porcentaje de empleados con ordenadores

- Ratio de información estratégica

- Tareas interfuncionales

- Gestión del conocimiento

- Violaciones de la ética

(Niven, 2002, p. 191)

31
Perspectiva Financiera

Los indicadores financieros siguen siendo, desde luego, un componente

central del Balanced Scorecard, pero ya no son las únicas métricas que
usaremos.

De acuerdo con Paul Niven (2002, p. 40), “las medidas de esta perspectiva
nos dicen si la ejecución de nuestra estrategia, detallada a través de
medidas elegidas en las otras perspectivas, nos está llevando a resultados
finales mejores”.

Así, los indicadores financieros tradicionales se encuentran en esta

perspectiva.

Entre los indicadores financieros generalmente usados en las

organizaciones, podemos encontrar los siguientes:
- Activo total

- Activo total por empleado

- Beneficio como % del activo total

- Rentabilidad del activo neto

- Rentabilidad del activo total

- Ingresos / activo total

- Margen bruto

- Beneficio neto

- Beneficio como % de las ventas

- Beneficio por empleado

- Ingresos

- Ingresos por productos nuevos

- Ingresos por empleado

- Rentabilidad de los recursos propios (ROE)

- Rentabilidad del capital empleado (ROCE)

- Rentabilidad de la inversión (ROI)

32
- Valor económico añadido (EVA)

- Valor añadido de mercado (MVA)

- Valor añadido por empleado

- Tasa de crecimiento compuesta

- Dividendos

- Valor de mercado

- Precio de las acciones

- Mix de accionistas

- Fidelidad de los accionistas

- Flujo de caja

- Costos totales

- Calificación crediticia

- Deuda

- Relación capital ajeno / capital propio

- Intereses ganados

- Días ventas en cuentas a cobrar

- Facturación cuentas a cobrar

- Días en cuentas a pagar

- Días en inventario

- Ratio rotación de existencias

(Niven, 2002, p. 164)

33
 Imagen 6: Perspectivas del Balanced Scorecard

Perspectiva
Financiera

Indicadores

Iniciativas
Objetivos
¿Qué objetivos

Metas
financieros debemos
alcanzar para ser
exitosos?

Perspectiva Clientes Perspectiva

Procesos Internos
Indicadores

Indicadores
¿Qué necesidades de
Iniciativas

Iniciativas
Objetivos

Objetivos
los clientes debemos ¿En qué procesos
Metas

Metas
satisfacer para tener debemos ser
éxito? Visión y Estrategia excelentes para
satisfacer a nuestros
accionistas y clientes?

Perspectiva
Aprendizaje y
Indicadores

Iniciativas
Crecimiento
Objetivos

Metas

¿Cómo debemos
aprender a cambiar,
innovar y mejorar
para alcanzar
nuestros objetivos?

Fuente: Elaboración propia en base a Paul Niven (2002, p. 37)

Equilibrio en el Cuadro de Mando Integral

Como destaca Paul Niven (2002, pp. 47-48), el equilibrio en el sistema del
Balanced Scorecard se refiere a tres aspectos:

 “Equilibrio entre indicadores financieros y no financieros.

 Equilibrio entre constituyentes internos y externos de la empresa.

 Equilibrio entre indicadores posteriores (pasados) y futuros de los

resultados”.

34
Desarrollo del Cuadro de Mando Integral

Los pasos principales para el desarrollo de un Balanced Scorecard son los

siguientes:
 Paso 1: Reunir y distribuir material informativo de fondo.

 Paso 2: Desarrollar o confirmar misión, valores, visión y

estrategia.

 Paso 3: Entrevistarse con la dirección.

 Paso 4: Desarrollar objetivos y medidas (indicadores) en cada

una de las perspectivas del Cuadro de Mando Integral.

 Paso 5: Desarrollar relaciones de causa – efecto.

 Paso 6: Establecer metas para las medidas (indicadores).

 Paso 7: Desarrollar el plan en marcha para implementar el

Cuadro de Mando Integral.

(Niven, 2002, pp. 94-96)

Desde luego, de los pasos anteriores debe quedar claro que la Misión,
Visión, Valores y la Estrategia de la empresa seguramente ya existen.

El trabajo se concentrará, por lo tanto, en definir los objetivos de

resultados para cada una de las cuatro perspectivas. Como sostiene Paul
Niven (2002, p. 149): “las declaraciones de objetivos son declaraciones
concisas que describen las cosas concretas que hay que hacer bien para
poder implementar la estrategia con éxito”. Dichos objetivos deberán estar
alineados con la Visión y Misión empresarial.

Y por cada objetivo, posteriormente, debemos definir los indicadores.

Según Niven (2002, pp. 157-158), “las medidas (o indicadores) de los
resultados son las herramientas que usamos para determinar si estamos
cumpliendo con nuestros objetivos”.

Es decir, los indicadores deben ser cuantificables, con el objeto de poder

medir su grado de avance hacia el cumplimiento de los objetivos pautados.

35
Modelización del Negocio

Respecto a esta temática, Josep Lluís Cano expresa lo siguiente:

Cuando definíamos Business Intelligence […] decíamos que se
refiere a un área concreta del negocio: clientes, productos, costes,
etc. Cuando nos referimos a un área de negocio siempre
pretendemos “medir” un resultado, bien sean ingresos, costes,
ventas, etc. La razón que nos lleva a ello está ampliamente
desarrollada en la literatura empresarial y se podría resumir como
“aquello que no se mide, no se puede gestionar”. El primer paso,
por tanto, es definir qué queremos medir, cómo lo vamos a hacer.
Para ello debemos definir cuál es nuestro modelo de negocio y
cuáles son las métricas que vamos a utilizar.

Construir un modelo nos permite analizar qué está sucediendo y

para poder construirlo debemos documentar, probar, y
desarrollar nuestras teorías acerca de cómo funciona el negocio.
Los modelos nos ayudan a experimentar de que manera afectarán
los cambios que introduzcamos al resultado.

Es importante construir modelos de negocio, ya que en algunos

casos no siempre la mejor solución para un departamento es la
mejor para toda la organización.

Hablamos de “silos de información” cuando entre distintos

departamentos no fluye la información necesaria, bien para la
gestión o bien para el análisis, dando lugar tanto a problemas de
operaciones, como de optimización del negocio.

Los “silos de información” pueden ser originados por la no

integración de los sistemas de información de los distintos
departamentos o por razones políticas dentro de nuestra
organización.

Los modelos de negocio son simplificaciones de la realidad que

nos sirven para comprender qué está sucediendo.

Para definirlos podemos acudir a distintas metodologías:

Contabilidad Analítica o de Costes, EFQM (European Foundation
for Quality Management), SixSigma, Análisis de procesos, Modelos
Financieros, Análisis de ratios, etc.

36
 Si el modelo de negocio está bien definido nos permitirá
responder preguntas clave de la gestión de nuestra organización.

(Cano, 2007, pp. 59-61 y 65)

Indicadores Claves del Negocio (KPI)

Los Indicadores Claves del Negocio (KPI, Key Performance Indicator en

Inglés) representan una herramienta esencial para saber si la organización
está alcanzando o no sus objetivos.
Una vez que han analizado su misión, han identificado los grupos
de poder y han definido sus objetivos, las organizaciones
necesitan un sistema para medir su progreso hacia la consecución
de los objetivos. Los KPI son los instrumentos adecuados para
llevarlo a cabo.

Los KPI deben ser cuantificables y deben medir las mejoras en

aquellas actividades que son críticas para conseguir el éxito de la
organización. Los KPI deben estar relacionados con los objetivos y
con las actividades fundamentales de nuestra organización
(aquellas que nos permiten obtener los resultados).

Distintas empresas de un mismo sector pueden tener distintos

KPI’s en función de sus modelos de negocio, objetivos o su propia
idiosincrasia.

Los KPI’s que escojamos deben:

 Reflejar los objetivos del negocio.

 Ser críticos para conseguir el éxito.

 Ser cuantificables y comparables.

 Permitir las acciones correctivas.

Si establecemos KPI’s por departamentos deberán estar alineados

entre ellos y con los objetivos de la organización.

Los KPI’s deben ser establecidos involucrando a los responsables

de cada una de las áreas de la organización. Debemos seleccionar
aquellos KPI’s que estén relacionados con la consecución de los

37
 resultados en la organización, es decir, aquellos que son
esenciales para conseguir los objetivos.

Debemos escoger un número reducido de KPI’s para facilitar que

los distintos miembros de nuestra organización nos centremos en
conseguirlos. A tal fin, debemos darles un nombre, una definición,
establecer como calcularlos y los valores a conseguir.

(Cano, 2007, pp. 65-67)

Scorecards

Como vimos en la Unidad 1 (Módulo 1), una de las herramientas de

visualización de Business Intelligence consiste en los denominados
‘Scorecards’. Los mismos están basados en el concepto de Balanced
Scorecard.

Consisten, básicamente, en herramientas o pantallas de Tableros de

Comando en donde se refleja la estructura del Cuadro de Mando Integral:
la visión y misión de la empresa, objetivos, indicadores, etc. En un
Scorecard puede analizarse la evolución de cada uno de los KPI definidos
dentro de un Mapa Estratégico de Balanced Scorecard.

A diferencia de un Dashboard (en donde puede verse la evolución de

distintos indicadores), en el Scorecard los KPI están clasificados por
objetivos a los que pertenecen y éstos enmarcados dentro de cada una de
las cuatro perspectivas.

Sin lugar a dudas, el desarrollo de un Scorecard es mucho más complejo

que un simple Dashboard puesto que implica haber llevado adelante
previamente una estrategia de definición del Cuadro de Mando Integral de
la organización.

38
Bibliografía Lectura 2

 Cano, J. L. (2007). Business Intelligence: Competir con Información.

España: Banesto Fundación Cultural y ESADE.

 Inmon, W. (2005). Building the Data Warehouse (4º Edición).

Estados Unidos: Wiley Publishing.

 Kimball Ralph, R. M. (2013). The Data Warehouse Toolkit (3º

Edición). Estados Unidos: Wiley Publishing.

 Niven, P. (2002). El Cuadro de Mando Integral Paso a Paso. España:

Ediciones Gestión 2000.

 Two Crows Corporation (1999). Introduction to Data Mining and

Knowledge Discovery (3º Edición). Recuperado el 5 de Mayo de
2014:
http://www.stanford.edu/class/stats315b/Readings/DataMining.pd
f

www.uesiglo21.edu.ar

39
Módulo 3
Modelado
Multidimensional
3. Análisis
Multidimensional
El análisis multidimensional nos facilita el análisis de un hecho
desde distintas perspectivas o dimensiones. Esta es la forma
natural que se aplica para analizar la información por parte de
los tomadores de decisiones, ya que los modelos de negocio
normalmente son multidimensionales.

(Cano, 2007, p. 126)

3.1 Introducción al modelado

¿Qué es un Modelo?

Un modelo es una abstracción de la realidad que, como sabemos, suele ser

muy compleja. En particular, podemos hablar de un modelo de datos, que
no es otra cosa que la representación de la estructura de los datos
almacenados en un Sistema de Gestión de Bases de Datos (DBMS).

El paradigma de modelado de datos por excelencia en los sistemas

transaccionales/operacionales es el Relacional. Si bien se utiliza también en
las bases de datos analíticas o decisionales, el modelado Multidimensional
es, por lejos, el más usado.

1
Modelado Relacional

De acuerdo con Josep Lluís Cano (2007, p. 71), “una vez definido el modelo
de negocio debemos determinar qué información tenemos para
analizarlo”.

Para ello, la clave está en comprender el modelo Entidad - Relación de la

base de datos origen o fuente de datos.
Se trata del modelo relacional desarrollado por E. F. Codd en el
año 1970: Está formado por tablas y relaciones entre las mismas.

La mayoría de las aplicaciones de gestión utilizan bases de datos

fundamentadas en el modelo relacional. El modelo relacional
utiliza un lenguaje de interrogación conocido por Standard Query
Language (SQL).

El modelo relacional se basa, pues en tablas con distintos

atributos o campos y las relaciones entre las tablas. Cada tabla
tiene una Clave Primaria (“Primary Key” o PK) formada por uno o
más atributos y las tablas se relacionan entre ellas mediante las
Claves Externas o Foráneas (“Foreign Key” o FK) que actúan como
claves primarias en sus propias tablas.

(Cano, 2007, p. 71)

Es decir, en el modelo Relacional tenemos Tablas (Entidades) y Relaciones

entre ellas. Cada tabla tiene N atributos o campos, de los cuales los más
importantes son la Clave Primaria (PK) y las Claves Foráneas (FK).

Y el lenguaje por excelencia para la consulta de datos es el SQL. En el Anexo

del libro de referencia de Josep Lluís Cano (2007) se puede encontrar un
resumen con las características principales del lenguaje SQL (páginas 353 a
379 inclusive).
Una base de datos relacional es una base de datos que es
percibida por el usuario como una colección de tablas. Cada tabla
está formada por filas (registros o tuplas) y columnas (atributos o
campos). Las tablas están compuestas por registros o tuplas y
cada uno de los registros tiene distintos atributos o campos.

Las tablas o relaciones deben cumplir varios requisitos:

 No existen registros repetidos.

2
  El orden de los registros no es significativo.

 El orden de los atributos no es significativo.

 Los valores de los atributos son atómicos.

Codd propuso las bases de datos relacionales en 1970, pero fue

posteriormente, en 1974, cuando Chanberlin y Boyce publicaron
un artículo proponiendo un lenguaje estructurado que llamaron
SEQUEL, que es el origen del SQL.

El modelo relacional fue desarrollado posteriormente por C.J.

Date y H. Darven, entre otros.

Las bases de datos relacionales tienen al menos dos

características:

 La información está integrada, generalmente en un solo

lugar de la base de datos. Los usuarios de los distintos
procesos acceden a la misma información en una sola
ubicación, lo que minimiza las redundancias de
información.

 La información es relacional, está interrelacionada con

otras informaciones en otras partes de la base de datos.

(Cano, 2007, pp. 354-355)

Modelado Multidimensional

Como sostiene Josep Lluís Cano (2007), a partir del esquema entidad-
relación, original de los sistemas transaccionales, se deberá construir el
esquema multidimensional (usualmente tipo estrella, como veremos más
adelante en esta misma Lectura) que nos permitirá analizar la información
en la base de datos analítica.

A pesar de algunas desventajas que ya vimos en la Unidad 2 (según la

opinión de William Inmon), de acuerdo con el enfoque de Ralph Kimball
(2013) el modelado multidimensional es ampliamente aceptado como la
técnica preferida para presentar datos analíticos ya que trata dos
requerimientos simultáneos:

 Entregar datos que sean comprendidos por los usuarios del

negocio.

3
  Responder consultas con rápida performance.

El Modelado Multidimensional es una técnica que permite simplificar el

diseño de bases de datos. La simplicidad es crucial porque asegura que los
usuarios entienden los datos, además de permitirle al software navegar y
entregar resultados rápida y eficientemente.

Muchas personas encuentran intuitivo pensar en un negocio en términos

de un cubo de datos con los ejes: producto, mercado y tiempo. Los puntos
dentro del cubo contienen las métricas tales como volumen de ventas o
ganancias. Es decir, el modelado Multidimensional es una técnica que
permite representar los requerimientos de datos de forma simple y
entendible, ya que se puede ver la información
(hechos/indicadores/métricas, generalmente numéricos) desde diferentes
puntos de vista (dimensiones).

Según Ralph Kimball (2013), si bien los modelos multidimensionales

frecuentemente se diseñan también en RDBMS (Sistemas de Gestión de
Bases de Datos Relacionales), difieren de los modelos en tercera forma
normal en tanto que se permiten eliminar las redundancias. Las estructuras
normalizadas dividen los datos en muchas entidades discretas, cada una de
las cuales se convierte en una tabla relacional.

La industria se refiere a los modelos en tercera forma normal como

modelos entidad-relación (o simplemente Modelos Relacionales).

Los Diagramas de Entidad-Relación (DER) permiten comunicar las

relaciones entre tablas. Tanto los modelos Relacionales como los modelos
Multidimensionales pueden representarse con DER porque consisten en
tablas relacionadas; la diferencia clave es el grado de normalización.

Las estructuras normalizadas son útiles en el procesamiento operacional

porque un ‘update’ o un ‘insert’ toca la base de datos en un solo lugar.

Los modelos normalizados, sin embargo, son demasiado complicados para

las consultas de BI. Los usuarios no pueden comprender, navegar o
recordar modelos normalizados. Por otra parte, muchos RDBMS no pueden
consultar eficientemente un modelo normalizado; la complejidad de las
impredecibles consultas de los usuarios supera los optimizadores de bases
de datos causando mala performance.

En otras palabras, un modelo multidimensional contiene la misma

información que un modelo relacional normalizado, pero empaqueta los
datos en un formato tal que permite entregar al usuario un mayor grado de
comprensibilidad y performance en las consultas.

4
3.2 RDM vs. MDM

Como hemos visto en el Módulo 2, punto 2.3: Tipos de Implementación,

existen dos modelos básicos para el diseño de la base de datos de un Data
Warehouse: el modelado Relacional (RDM) y el modelado
Multidimensional (MDM).

Si bien cada uno tiene sus ventajas y desventajas, en la actualidad el

modelado Multidimensional, tal como señalábamos en el apartado
anterior, se ha convertido en el enfoque más utilizado para el diseño de un
Data Warehouse (y/o un Data Mart).

Ralph Kimball (2013) establece que existen cinco mitos sobre el modelado
Multidimensional:

 Mito 1: Los modelos multidimensionales solamente son para datos

sumarizados

 Mito 2: Los modelos multidimensionales son departamentales, no

empresariales

 Mito 3: Los modelos multidimensionales no son escalables

 Mito 4: Los modelos multidimensionales sólo son para uso

predictivo

 Mito 5: Los modelos dimensionales no pueden ser integrados

A continuación, veremos en detalle cada uno de estos falsos mitos, según

lo que establece este mismo autor (Kimball, 2013).

Mito 1: Los modelos multidimensionales solamente

son para datos sumarizados

Dado que no se pueden predecir todas las consultas que harán los
usuarios, es necesario que se acceda a los datos detallados.

Los datos sumarizados deberían complementar los datos detallados para

una mejor performance de consultas comunes, pero no reemplazarlos.

Por otra parte, no hay límites en cuanto a la cantidad de registros

históricos que pueda tener un modelo multidimensional.

5
Mito 2: Los modelos multidimensionales son
departamentales, no empresariales

En lugar de tener en cuenta los límites en términos de departamentos

organizacionales, los modelos multidimensionales deberían organizarse en
términos de los procesos de negocio.

Múltiples departamentos frecuentemente quieren analizar las mismas

métricas del mismo proceso de negocio. Múltiples extracciones ETL de la
misma fuente de datos, que crean múltiples e inconsistentes bases de
datos analíticas, deberían evitarse.

Mito 3: Los modelos multidimensionales no son

escalables

Los modelos multidimensionales son extremadamente escalables; las

tablas de hechos frecuentemente tienen millones de filas. Los proveedores
de soluciones de BI continúan incorporando capacidades en sus productos
para optimizar la escalabilidad y performance de los modelos
multidimensionales.

Ambos modelos, normalizado y multidimensional, contienen la misma

información y relaciones de datos, el contenido lógico es idéntico. Cada
relación de datos expresada en un modelo puede ser precisamente
expresada en el otro, y ambos modelos pueden responder exactamente las
mismas preguntas, aunque varía la dificultad.

Mito 4: Los modelos multidimensionales sólo son

para uso predictivo

Los modelos multidimensionales no deberían diseñarse enfocados en

reportes o análisis predefinidos, sino que el diseño debería centrarse en
procesos de medición.

Si bien es importante considerar los requerimientos de filtros de las

aplicaciones de BI, no debería basarse solo en ello porque esto varía a
menudo haciendo al modelo multidimensional muy cambiante. La clave es
enfocarse en los eventos de medición de la organización, que

6
generalmente son estables, excepto por los análisis que están
continuamente evolucionando.

Debido a su simetría, las estructuras multidimensionales son flexibles al

cambio. El secreto está en diseñar las tablas de hechos con el máximo nivel
de detalle, ya que esto da más flexibilidad y extensibilidad.

Mito 5: Los modelos multidimensionales no pueden

ser integrados

Los modelos multidimensionales sí pueden ser integrados. Las dimensiones

compartidas se diseñan de manera centralizada, persistentes y son
reutilizadas entre los distintos modelos multidimensionales para permitir la
integración de datos y asegurar una consistencia semántica. La integración
de datos depende de etiquetas, valores y definiciones estandarizadas, lo
cual requiere de consenso organizacional.

3.3 Componentes MDM

Principales Componentes de un Modelo

Multidimensional

De acuerdo con Ralph Kimball (2013), los principales componentes de un

modelo Multidimensional son:

 Hechos

 Dimensiones

 Elementos

 Atributos

 Miembros

 Tablas de Hechos

 Tablas de Dimensión

 Esquemas.

7
Hechos

Un Hecho es un atributo que representa una métrica del negocio respecto

a una o más dimensiones. Se almacenan en las Tablas de Hechos.

Ejemplo: Ventas en $.

Dimensiones

Una Dimensión hace referencia a los distintos puntos de vista (o

perspectivas) a través de los cuales se puede analizar un Hecho. Se
almacenan en las Tablas de Dimensión.

Ejemplos: Tiempo (año, mes, día, entre otros), Zona Geográfica (país,
provincia/estado, localidad, entre otros), etc., lo cual permite analizar, por
ejemplo, las Ventas Totales por Provincia y por Mes.

Elementos de Dimensión

Un Elemento de Dimensión es un componente de una Dimensión, que

permite agrupar lógicamente determinados atributos del negocio.
Generalmente, tienen una organización jerárquica para que se pueda
navegar la información por distintos niveles de detalle.

Ejemplo: la Provincia dentro de la dimensión Zona Geográfica.

Atributos de Dimensión

Un Atributo de Dimensión contiene la descripción y otros datos

relacionados con cada Elemento de Dimensión. Es decir, un mismo
Elemento de Dimensión puede tener varios Atributos.

Ejemplo: el elemento Provincia dentro de la dimensión Zona Geográfica

tiene varios atributos tales como: Código, Descripción y Región (Sur, Norte,
Este, Oeste).

8
Miembro de Dimensión

Un Miembro de Dimensión representa cada una de las instancias reales y

concretas de una Dimensión en particular.

Ejemplo: para la dimensión Zona Geográfica, un miembro es la ciudad de

Mendoza en la provincia de Mendoza, en el país Argentina.

Tablas de Hechos para Mediciones

Según Ralph Kimball (2013), la tabla de Hechos en un modelo

multidimensional almacena las mediciones resultantes de los eventos de
los procesos de negocio de una organización.

Cada medición debería almacenarse en un único modelo multidimensional.

Permitir a usuarios de múltiples departamentos acceder a un repositorio
centralizado asegura el uso de datos consistentes.

En una tabla de Hechos cada fila se corresponde con un evento de

medición y los datos en cada fila están en un nivel específico de
detalle/granularidad (por ejemplo: un producto vendido en una
transacción de venta). Además, todas las filas deben tener la misma
granularidad. Con la disciplina de crear tablas de hechos con igual nivel de
detalle se asegura que las mediciones sean correctas.

Los hechos más útiles son numéricos y aditivos, como por ejemplo, las
ventas en pesos. La aditividad es crucial, porque las aplicaciones de BI rara
vez consultan una sola fila de la tabla de hechos; por lo general, consultan
miles de filas para traer un valor sumarizado. Sin embargo, hay hechos no
aditivos, como el precio unitario, que nunca pueden ser sumados; en
cambio, se podrá hacer cuentas o promedios.

No se debe almacenar información textual redundante en una tabla de

hechos, excepto que el texto sea único por cada fila, caso en el cual debería
ir a una tabla de dimensión.

Por otro lado, si no hubo ventas para un producto, no debe incluirse una
fila con ceros en la tabla de hechos. No obstante, las tablas de hechos
consumen el 90% de espacio de una base de datos multidimensional.
Dichas tablas tienden a ser profundas en cantidad de filas, pero
generalmente de pocas columnas.

9
Todas las tablas de hechos tienen 2 o más claves foráneas (FK) que las
conectan con las tablas de dimensión. La tabla de hechos generalmente
tiene su propia clave primaria, compuesta por un subconjunto de las FK de
las dimensiones. Toda tabla que tenga clave compuesta es una tabla de
hechos, dado que expresan relaciones muchos a muchos; las restantes son
tablas de dimensión.

Por ejemplo, podemos tener una tabla de Hechos con los siguientes
campos:

Imagen 1: Tabla de Hechos

Fuente: Elaboración propia

En este ejemplo, por cada combinación de tres Dimensiones distintas:

Tiempo (año, mes, día, etc.), Zona Geográfica (país, provincia, localidad,
etc.) y Producto (categoría y descripción), contamos con dos Hechos: la
Cantidad de Unidades Vendidas del Producto (en cada día y localidad) y el
Precio Unitario al cual se vendió.

En definitiva, la Tabla de Hechos es el núcleo de un modelo

multidimensional. Cada registro de la tabla representa una combinación de
los valores claves de las dimensiones, representando, por lo tanto, un
evento o una transacción del negocio.

10
Tablas de Dimensión para Contexto Descriptivo

De acuerdo con Ralph Kimball (2013), las tablas de Dimensión acompañan

a una tabla de Hechos. Aquellas contienen el contexto textual asociado con
un evento de medición del proceso de negocio; describen el "quién, qué,
dónde, cuándo, cómo y por qué" asociados al evento.

Frecuentemente, dichas tablas tienen muchas columnas o atributos. A

veces hasta 50 o 100 atributos, aunque algunas tablas de dimensión
naturalmente tienen solo unos cuantos. Además, tienden a tener menos
filas que una tabla de hechos. Cada tabla se define por una clave primaria
(PK) simple, lo que permite integridad referencial con cualquier tabla de
hechos.

Los atributos de dimensión sirven como la fuente primaria de restricciones

de las consultas, agrupamientos y etiquetas de reportes. En una consulta,
los atributos se identifican con la palabra "por". Ejemplo: cuando un
usuario quiere ver las ventas por marca, las marcas deben estar disponibles
como un atributo de dimensión.

Los atributos de dimensión juegan un rol clave en un sistema de BI. Deben

estar escritos con palabras reales y no abreviaturas. Debe minimizarse el
uso de códigos, reemplazándolos por atributos textuales. Cuando los
códigos tienen significancia real para los usuarios, deben aparecer como
atributos explícitos. El poder analítico de un Data Warehouse es
directamente proporcional a la calidad y profundidad de los atributos de
dimensión.

Las tablas de dimensión suelen representar relaciones jerárquicas. Por

ejemplo: los productos podrían agruparse en marcas, y las marcas en
categorías. De este modo, por cada fila de la dimensión Producto deberían
almacenarse las descripciones de la marca y categorías asociadas. Esta
información redundante permite una mayor facilidad de uso y mejor
performance de las consultas. Es decir, la característica principal de las
tablas de dimensión es la de-normalización. Debería evitarse crear una
tabla Marcas y otra Categorías. Cuando se aplica la normalización, se llama
copo de nieve. En lugar de usar la tercera forma normal, las tablas de
dimensión generalmente están altamente de-normalizadas con relaciones
muchos a uno dentro de una misma tabla de dimensión. Dado que tienen
un tamaño menor que las tablas de hechos, mejorar la eficiencia de
almacenamiento a través de la normalización o copo de nieve casi no tiene
impacto sobre el tamaño total de la base de datos.

Siguiendo con el ejemplo anterior, tenemos las tablas de dimensión

correspondientes a las tres dimensiones mencionadas:

11
Imagen 2: Tabla de Dimensión Tiempo

Fuente: Elaboración propia

Imagen 3: Tabla de Dimensión Zona Geográfica

Fuente: Elaboración propia

Imagen 4: Tabla de Dimensión Producto

Fuente: Elaboración propia

12
Hechos y Dimensiones relacionados en un Esquema
Estrella

Cada proceso de negocios se representa por un modelo multidimensional

que consiste en una tabla de hechos que contiene las mediciones
numéricas del evento, rodeada de varias tablas de dimensiones que
contienen el contexto textual que fue correcto o verdadero en el momento
en que ocurrió el evento. Esta estructura particular se denomina Esquema
Estrella.

Una de las características de este modelo es su simplicidad: los datos son

más fáciles de comprender y navegar gracias al número reducido de tablas
y descripciones amigables; además, es beneficiosa en cuanto a la
performance, al necesitar las consultas menos joins. Por otra parte, se
adapta mejor a los cambios. Es un modelo simétrico.

Cuanto más granulares o atómicos sean los datos, mayor dimensionalidad

habrá. Los datos detallados deberían ser el fundamento para cada diseño
de tablas de hechos.

Con los modelos multidimensionales se pueden agregar nuevas

dimensiones y hechos, suponiendo que el nivel de detalle es consistente
con la tabla existente.

Mientras los hechos proveen los valores numéricos de un reporte, los

atributos de dimensión proveen los filtros de un reporte.

13
A continuación, podemos ver cómo nos quedó el ejemplo con el esquema
Estrella:

Imagen 5: Esquema Estrella

Fuente: Elaboración propia

Como puede deducirse, la consulta SQL escrita o utilizada por una

herramienta BI es muy simple.

En el SELECT se ubican los atributos de dimensión que se quieren leer,

seguida por la métrica correspondiente sumarizada, por ejemplo un SUM
(CANTIDAD).

La cláusula FROM identifica todas las tablas de dimensión involucradas. En

el WHERE se identifica el filtro solicitado en el reporte por el usuario,
además de los joins correspondientes, y en el GROUP BY se establecen las
distintas sumarizaciones o agrupaciones.

Para poder obtener las Ventas Totales es necesario multiplicar los campos
CANTIDAD y PRECIO_UNITARIO.

14
3.4 Esquema de Implementación

Como adelantamos en los apartados anteriores, pueden establecerse

distintos esquemas de implementación de un modelo Multidimensional:

 Estrella (cuando un modelo está de-normalizado, con una sola tabla

de hechos y varias tablas de dimensión).

 Copo de Nieve (semejante al anterior, pero existen varias tablas

normalizadas por cada dimensión, por ejemplo: para la dimensión
Zona Geográfica tendríamos tres tablas: País, Provincia y Localidad).

 Constelación (cuando se unen varios modelos Estrella a través de

dimensiones compartidas).

Esquemas Estrella

Según Josep Lluís Cano (2007, p. 75), “para la construcción del esquema
estrella debemos distinguir entre las tablas de hechos (aquello que
queremos medir o analizar) y las tablas de dimensiones (cómo lo
queremos medir)”.
Las características del esquema estrella son:

 Una tabla de hechos que contiene los datos sin

redundancias.

 Una sola tabla por dimensión.

 La tabla de hechos (Fact table) tiene un atributo columna

que forma la clave de cada dimensión.

 Cada tabla de dimensión (Dimension table) es una tabla

simple desnormalizada.

(Cano, 2007, p. 79)

El esquema Estrella (Star, en inglés) es el más común y, en general, el más

recomendado.

15
Esquemas Copos de Nieve

Generalmente, se tiende a no utilizar esquemas Copos de Nieve (también

conocidos como Snowflake en inglés).
En el esquema “copo de nieve” aparecen relaciones entre las
tablas de dimensiones, mientras que en el esquema “estrella” sólo
hay relaciones entre la tabla de hechos y las de dimensiones.

En este caso, las tablas de dimensiones están totalmente

normalizadas, lo que reduce el espacio que ocupan, aunque en
algunos casos esta diferencia no es significativa.

(Cano, 2007, p. 80)

Para el ejemplo anteriormente mencionado, tendríamos el siguiente

modelo de esquema Copo de Nieve, en el cual la dimensión Zona
Geográfica es dividida en tres tablas distintas para almacenar las
Localidades, Provincias y Países; mientras que la dimensión Producto es
dividida en dos tablas distintas, una para almacenar los Tipos de Productos
y otra para las Categorías de Productos:

Imagen 6: Esquema Copo de Nieve

16
Fuente: Elaboración propia
Esquemas Constelación

Es frecuente ver un esquema Constelación (Constellation en inglés) en

grandes sistemas de BI en donde hay varias tablas de hechos (es decir,
varios modelos multidimensionales unidos a través de dimensiones
compartidas). Como indica Josep Lluís Cano, «Cuando unimos distintos
esquemas “estrella” que tienen distintas tablas de hechos, pero comparten
las de las dimensiones, hablamos de constelaciones de hechos; algunos
autores hablan incluso de esquema “galaxia”» (2007, p. 79).

Si bien puede haber una Constelación de esquemas Estrella, también

podría suceder que se trate de una Constelación de esquemas Copos de
Nieve.

Multidimensionalidad

Según Josep Lluís Cano (2007, p. 84), “al poder utilizar las distintas
dimensiones a la vez estamos utilizando la funcionalidad de la
multidimensionalidad. La multidimensionalidad nos permite analizar la
información por distintas dimensiones a la vez”.

Así, para el ejemplo anterior, podemos analizar las Ventas Totales por
varias dimensiones en simultáneo, es decir, ver la evolución de las ventas
por cada una de las Provincias de Argentina, para el 3º Trimestre de 2012 y
la categoría de Productos de Alta Gama.

La multidimensionalidad es un aspecto clave y, desde luego, de muy

frecuente consulta por parte de los usuarios finales.

17
3.5 Conceptos relacionados

Esquemas Estrella vs. Cubos OLAP

Según Ralph Kimball (2013), los modelos multidimensionales

implementados en RDBMS son denominados esquemas Estrella por su
estructura similar. En cambio, los modelos multidimensionales
implementados en bases de datos multidimensionales (MDBMS) son
llamados cubos OLAP. Tanto una arquitectura como la otra incluyen
modelos multidimensionales, es decir, un diseño lógico común; la
diferencia está en la implementación física.

Cuando los datos se cargan en un cubo OLAP, se almacenan e indexan

usando formatos y técnicas diseñadas para datos multidimensionales.
Además, los datos pre-calculados o sumarizaciones son calculadas por el
motor OLAP. Por ello, los cubos OLAP tienden a tener mejor performance
de consulta.

Los usuarios de negocio pueden hacer drill-down o drill-up, agregando o

eliminando atributos de sus análisis con excelente performance sin hacer
nuevas consultas.

Los cubos OLAP también proveen funciones analíticas más robustas que las
disponibles en el lenguaje SQL. La desventaja es que se paga un precio en
performance de carga, especialmente en grandes volúmenes de datos.
Aunque las capacidades de la tecnología OLAP están continuamente
mejorando, generalmente se recomienda que la información atómica y
detallada se cargue en un esquema estrella sobre un RDBMS. Los cubos
OLAP, de desarrollo opcional, luego se cargan a partir del esquema estrella
inicial.

Hay que tener en cuenta que un cubo OLAP contiene atributos

dimensionales y hechos, pero se accede a través de lenguajes con más
capacidades analíticas que el SQL; entre ellos, podemos mencionar XML for
Analysis (XMLA) y MDX. Estos lenguajes tienen su propia sintaxis, diferente
del SQL tradicional.

18
Consideraciones sobre el Despliegue en Cubos OLAP

Según Ralph Kimball (2013):

 Un esquema Estrella hosteado en una RDBMS es un buen

fundamento físico para diseñar un cubo OLAP, y generalmente es
una base más estable para backup y recuperación de datos.

 Los cubos OLAP tradicionalmente han sido destacados por

presentar grandes ventajas en performance sobre los RDBMS
tradicionales; sin embargo, esta distinción se ha vuelto cada vez
menos importante con los últimos avances en hardware, BD ‘in-
memory’, etc.

 Las estructuras de datos de cubos OLAP (MDBMS) son más variables

entre los diferentes proveedores de bases de datos que los
tradicionales RDBMS, por lo tanto, el despliegue final depende de
qué motor OLAP se seleccione. Usualmente es más difícil portar
aplicaciones BI entre diferentes herramientas OLAP que entre
diferentes RDBMS.

 Los cubos OLAP, por lo general, ofrecen opciones de seguridad más

sofisticadas que los RDBMS, limitando el acceso a datos detallados
pero dando más acceso abierto a datos sumarizados.

 Al no tener las restricciones del SQL, los cubos OLAP ofrecen

capacidades de análisis significativamente más ricas que los RDBMS.
Esta es la principal justificación para utilizar un producto OLAP.

 Los cubos OLAP necesitan frecuentemente ser re-procesados

parcial o totalmente.

 Los cubos OLAP soportan complejas jerarquías de profundidad

indeterminada, tales como un organigrama, usando sintaxis de
consulta nativa, superior a los enfoques para RDBMS.

 Los cubos OLAP pueden imponer restricciones detalladas en la

estructura de las claves de dimensión que implementan jerarquías
drill-down en comparación con los RDBMS.

 Algunos productos OLAP no permiten roles o alias dimensionales,

sino que requieren dimensiones físicas separadas para poder ser
definidas.

En definitiva, según Ralph Kimball (2013) –y como puede apreciarse en los

puntos anteriores-, sólo en determinadas situaciones es recomendable
avanzar hacia la inclusión de un MDBMS y un producto OLAP en particular.

19
3.6 Mejoras de Performance

Indexación, Tablas Sumarizadas y Particionamiento

en el Data Warehouse

Como destaca William Inmon (2005), existen diferentes formas para

mejorar la performance de las aplicaciones de BI. Puntualmente, podemos
mencionar las siguientes técnicas que se pueden aplicar en el Data
Warehouse:

 Indexación

 Tablas Sumarizadas

 Particionamiento

El caso del Particionamiento ya lo hemos analizado en detalle en la Unidad

2 (Módulo 2). Así, para ejemplo de esta unidad, podríamos particionar la
tabla de Hechos que contienen las Ventas con una tabla separada por cada
año; esto impactará, lógicamente, en el tiempo de respuesta de las
consultas que accederán a una cantidad menor de registros.

El ítem Indexación es esencial. Al menos las claves primarias de las

distintas tablas (especialmente la tabla de hechos) deberían contar con su
índice respectivo; pero también es conveniente crear índices para aquellas
columnas que generalmente se usan como filtros en los reportes o sobre
las cuales hay búsquedas frecuentes por parte de los usuarios.

En cuanto a las Tablas Sumarizadas, pueden ser determinantes para la

performance de algunas consultas cuando la tabla de hechos contiene una
gran cantidad de registros. En estos casos puede haber un
procedimiento/algoritmo que se encargue de llenar, por ejemplo, una tabla
sumarizada todas las noches con las ventas totales por Categoría de
Producto y otra por cada una de las Provincias.

En definitiva, la búsqueda de una mejor performance es una actividad de

tuning permanente por parte de un especialista en Business Intelligence
puesto que aquí se juega, en muchas ocasiones, el prestigio de una
solución de BI en términos de performance apropiada.

20
Business Intelligence In-Memory y Visualización por
Lógica Asociativa

Sin lugar a dudas, el surgimiento en los últimos años de herramientas de BI

de lógica asociativa con bases de datos in-memory ha mejorado
sustancialmente la performance de las aplicaciones, aunque ello implique
dejar de lado algunos de los principios tradicionales en cuanto a diseño
arquitectónico.

El procesamiento in-memory es una tecnología emergente que habilita a

los usuarios a contar con acceso inmediato a los datos con tiempos de
respuesta óptimos. Esto se debe a que la tecnología tradicional de BI
almacena la información en disco -ya sea tablas o cubos OLAP-.

Sin embargo, la tecnología in-memory, como lo indica su nombre, permite

que los datos se carguen directamente en memoria RAM. Este tipo de
herramientas no sólo obtiene ganancias en performance, sino también en
tiempos de desarrollo de aplicaciones de BI; por ejemplo, al evitar la
construcción de cubos OLAP.

No obstante, si bien algunos proveedores recomiendan el acceso directo a

los datos transaccionales por parte de estas innovadoras herramientas, se
aduce que no es lo suficiente aconsejable, puesto que si no existe un
adecuado proceso ETL que alimente el Data Warehouse podemos perder
significativamente niveles de calidad en los datos al no realizarse una
apropiada integración y transformación de los datos primitivos
operacionales.

Muchas organizaciones cometen el error de aplicar la tecnología de BI in-

memory sin construir un Data Warehouse. Vale decir, el approach más
aconsejable (en caso de optar por este tipo de herramientas) consiste en
seguir todos los pasos del Corporate Information Factory hasta la
construcción del Data Warehouse/Data Mart, y utilizar las herramientas de
BI in-memory/lógica asociativa solamente para la visualización/explotación
de los datos.

Según uno de los productos líderes en este mercado, las claves para la
mejor performance de las aplicaciones de BI in-memory con lógica
asociativa están dados por los siguientes aspectos:
 Tiene un motor de inferencia que mantiene las
asociaciones entre los datos automáticamente.

 Calcula las agregaciones sobre la marcha, según se van

necesitando, para una experiencia de usuario ultra rápida.

21
  Comprime los datos hasta un 10% de su tamaño original
para optimizar la potencia de los procesadores.

(QlikTech, http://goo.gl/BMi8Mr, s.f.)

En este tipo de productos toda la información necesaria se carga

inicialmente en la memoria del servidor, lo cual en principio elimina la
necesidad de aplicar algún tipo de optimización de bases de datos (tal
como la indexación o el particionamiento, por ejemplo).

Este repositorio in-memory permanece en memoria hasta que algún

usuario realice actividad alguna.

Así, se puede cargar en memoria un Data Mart completo o un pequeño

Data Warehouse incluso.

Por otra parte, muchas de estas herramientas utilizan algoritmos de

compresión de datos que reducen el tamaño que los datos ocupan en
memoria. El acceso por parte de los usuarios finales a estos datos es más
rápido, puesto que no es necesario buscar la información en disco.

La mayor demanda de estas herramientas se dio a partir de la confluencia

de varios factores, entre ellos:

 Costos reducidos en hardware.

 Arquitectura de procesador multi-núcleo.

 Memoria flash.

 Técnicas y algoritmos de compresión de datos que permiten

minimizar el espacio de almacenamiento de los datos una vez que
están en memoria.

 Sistemas de gestión de bases de datos orientados a las columnas

(Column-Oriented DBMS, en inglés).

 Sistemas operativos de 64 bits.

 Grandes volúmenes de datos que dificultan la ejecución de los

procesos ETL (ya sea por aspectos de complejidad de los algoritmos
o, más frecuentemente, por la cantidad de tiempo requerido para
movilizar datos desde un esquema transaccional hacia el Data
Warehouse).

22
  Necesidad de analizar la información en tiempo real, dado que de
manera frecuente las aplicaciones de BI se usan para tomar
decisiones inmediatas a base de los perfiles históricos.

 Lógica de Consulta Asociativa (AQL, Associative Query Logic en

inglés), que permite relacionar o asociar un determinado campo
con cualquier otra columna de la base de datos.

 Otros aspectos.

La Lógica de Consulta Asociativa (AQL), mencionada en el párrafo anterior,

realmente configura una innovación no solo en términos de performance,
sino también en permitir análisis más desestructurados.

Por ejemplo, con la tecnología OLAP se diseñan dimensiones pre-

establecidas; es decir, la lógica de explotación de los datos por parte de un
usuario final es muy estructurada en el sentido de que debe seguir la
jerarquía de la dimensión, mientras que con AQL es posible detectar todo
tipo de cruce de datos sin seguir una jerarquía de navegación pre-
establecida. Esto se debe a que AQL mantiene todas las asociaciones
existentes entre los datos.

Imagen 7: AQL

Fuente: QlikView (2010). QlikView Architectural Overview. Pág. 3

23
4. Administración del
Modelo
“Las herramientas OLAP permiten a los usuarios finales tratar la
información de forma multidimensional para explorarla desde
distintas perspectivas y períodos de tiempo.”

(Cano, 2007, p. 132)

4.1 Herramientas OLAP

En la parte final de la lectura de la Unidad 1 (Módulo 1), pudimos analizar

las principales características de una herramienta OLAP.

En términos generales, una herramienta OLAP puede ser Cliente/Servidor o

Web Enabled:
Cliente / Servidor, lo que significa tener las instalaciones locales
en los ordenadores de los usuarios.

Acceso Web: cliente, cliente ligero, o solo con el navegador. En

este tipo de acceso el navegador se comunica con un servidor
web, el cual habla con la aplicación del servidor, que es la que
conecta con el Data Warehouse. En el caso de acceder con el
navegador sin ningún tipo de cliente o con cliente ligero (por
ejemplo JAVA), normalmente se descargan pequeñas aplicaciones
para aumentar la funcionalidad.

Algunos autores también hablan del Virtual o Desktop OLAP

(DOLAP). En este caso creamos un cubo con las dimensiones que
le interesan al usuario, lo cargamos en memoria en su ordenador,
trabaja y, cuando acaba, lo eliminamos de la memoria. La ventaja

24
 es que el usuario sólo recibe los hechos y las dimensiones en los
que está interesado y los analiza en forma local.

(Cano, 2007, pp. 130-131)

4.2 FASMI

De acuerdo con Josep Lluís Cano (2007, p. 126), “el OLAP Council sumarizó
las 12 reglas de Codd en lo que ellos llamaban el concepto FASMI y que los
productos OLAP deben cumplir”.

FASMI es una sigla compuesta por los siguientes anglicismos:

 Fast

 Analysis

 Shared

 Multidimensional

 Information

A continuación, vemos lo que representa cada una de ellas:

FAST (Rápido): Debe ser rápido, necesitamos lanzar consultas y
ver los resultados inmediatamente.

ANALYSIS (Análisis): Debe soportar la lógica de negocio y análisis

estadísticos que sean necesarios para los usuarios.

SHARED (Compartido): Tiene que manejar múltiples

actualizaciones de forma segura y rápida.

MULTIDIMENSIONAL (Multidimensional): Tiene que proveer de

una visión conceptual de la información a través de distintas
dimensiones.

INFORMATION (Información): Debe poder manejar toda la

información relevante y la información derivada.

(Cano, 2007, pp. 126-127)

25
4.3 Almacenamiento OLAP

Existen diferentes tipos de herramientas OLAP según su grado de

almacenamiento:

 ROLAP

 MOLAP

 HOLAP

Con las siguientes características principales:

ROLAP: Relational OLAP

Las capacidades OLAP acceden directamente a la base de datos

relacional. Se accede por tanto a una base de datos relacional
(RDBMS). Accede habitualmente sobre un modelo “estrella”. La
principal ventaja es que no tiene limitaciones en cuanto al
tamaño, pero es más lento que el MOLAP, aunque algunos
productos comerciales nos permiten cargar cubos virtuales para
acelerar los tiempos de acceso.

MOLAP: Multimensional OLAP

La implementación OLAP accede directamente sobre una base de

datos multidimensional (MDBMS). La ventaja principal de esta
alternativa es que es muy rápida en los tiempos de respuesta y la
principal desventaja es que, si queremos cambiar las dimensiones,
debemos cargar de nuevo el cubo.

HOLAP: Hybrid OLAP

Accede a los datos de alto nivel en una base de datos

multidimensional y a los atómicos directamente sobre la base de
datos relacional. En esencia, utiliza las ventajas del ROLAP y del
MOLAP.

(Cano, 2007, p. 130)

26
4.4 Conceptos Avanzados

Proceso de Diseño Dimensional en 4 Pasos

De acuerdo con Ralph Kimball (2013), las cuatro decisiones clave que se
toman durante el diseño de un modelo multidimensional incluyen los
siguientes pasos:

 Seleccionar el proceso de negocio

 Declarar la granularidad

 Identificar las dimensiones

 Identificar los hechos.

Las respuestas a estos interrogantes se determinan considerando las

necesidades del negocio junto con las realidades de los datos fuente
subyacentes durante las sesiones de modelado colaborativas.

Luego de los cuatro pasos, el equipo de diseño determina los nombres de

tablas y columnas, valores de dominio de muestra y reglas de negocio.
Representantes del negocio deben participar en esta actividad detallada
para garantizar su compromiso.

1. Procesos de Negocio

Los procesos de negocio son las actividades operativas realizadas por una
organización, como por ejemplo: tomar una orden o solicitud, procesar una
queja o reclamo, registrar estudiantes en un curso, y otros.

Los eventos de un proceso de negocio generan o capturan métricas de

desempeño que se traducen en hechos en una tabla de hechos. Muchas
tablas de hechos se enfocan en los resultados de un proceso de negocio en
particular.

Seleccionar el proceso es importante porque define un objetivo de diseño

específico y permite declarar la granularidad, las dimensiones y los hechos.

27
 2. Granularidad

Declarar la granularidad es el paso principal en un diseño dimensional. La

granularidad establece exactamente qué representa una fila de una tabla
de hechos, y debe declararse antes de seleccionar las dimensiones o
hechos, ya que cada uno de estos debe ser consistente con la granularidad.
Esta consistencia fuerza a una uniformidad en todos los diseños
dimensionales que es crítica para la performance y facilidad de uso de una
aplicación BI.

La granularidad atómica se refiere al nivel más bajo, en el cual los datos son
capturados por un proceso de negocio dado. Ralph Kimball (2013)
recomienda iniciar enfocándose en datos de granularidad atómica porque
permite resistir el surgimiento de consultas de usuario impredecibles.

La granularidad sumarizada es buena para la performance, pero presupone

las consultas comunes de los usuarios. Cada granularidad de tabla de
hechos propuesta resulta en una tabla física separada; diferentes niveles
de granularidad no deben mezclarse en la misma tabla de hechos.

3. Dimensiones para la Descripción del Contexto

Las dimensiones proporcionan el contexto: quién, qué, dónde, cuándo,

por qué y cómo, circundante a un evento de proceso de negocio.

Las tablas de dimensión contienen los atributos descriptivos usados por las
aplicaciones BI para filtrar y agrupar los hechos.

Con la granularidad de una tabla de hechos en mente, todas las

dimensiones posibles pueden ser identificadas. Cada vez que sea posible,
una dimensión debería ser valuada cuando se asocia a una fila de un hecho
dado.

Las tablas de dimensión son algunas veces llamadas el ‘alma’ del Data
Warehouse porque contienen los puntos de entrada y etiquetas
descriptivas que le permiten a un sistema BI habilitar el análisis del
negocio.

28
 4. Hechos para Medición

Los hechos son las mediciones que resultan de un evento de proceso de

negocio y son casi siempre numéricos. Una fila de una tabla de hechos
tiene una relación uno a uno con un evento de medición, en función de la
granularidad de la tabla de hechos.

Por lo tanto, una tabla de hechos corresponde a un evento observable

físico y no a la demanda de un reporte particular. Dentro de una tabla de
hechos sólo son permitidos los consistentes con la granularidad detallada.

Técnicas Básicas para Tablas de Hechos

A continuación, veremos un conjunto de técnicas básicas para las Tablas de

Hechos, de acuerdo con los lineamientos de Ralph Kimball (2013).

Estructura de la Tabla de Hechos

Una Tabla de Hechos contiene las mediciones numéricas producidas por un

evento de medición operacional en el mundo real.

En el más bajo nivel de granularidad, una fila de tabla de hechos

corresponderá a un evento de medición y viceversa. Por lo tanto el diseño
fundamental de una tabla de hechos está completamente basado en una
actividad física y no está influenciado por los reportes eventuales que
puedan producirse.

Además de las métricas numéricas, una Tabla de Hechos siempre contiene

claves foráneas (FK) para cada una de sus dimensiones asociadas, así como
opcionales claves de dimensiones degeneradas y columnas de fecha/hora.

Estas tablas son el objetivo primario de cálculos y sumarizaciones

dinámicas en las consultas.

29
Hechos Aditivos, Semi-Aditivos y No Aditivos

Las métricas numéricas en una tabla de hechos caen dentro de tres

categorías:

 Los hechos más flexibles y útiles son totalmente aditivos. Las

métricas aditivas pueden sumarse a lo largo de cualquiera de las
dimensiones asociadas con la tabla de hechos.

 Las métricas semi-aditivas pueden sumarse a lo largo de algunas

dimensiones, pero no todas; por ejemplo, las cantidades de un
balance contable pueden sumarse para todas las dimensiones,
excepto el tiempo.

 Finalmente, algunas métricas son completamente no aditivas,

como por ejemplo, los ratios. Un buen enfoque para los hechos no
aditivos es, donde sea posible, almacenar los componentes
totalmente aditivos de las métricas no aditivas y sumar estos
componentes en la respuesta final antes de calcular el hecho no
aditivo. Este cálculo final frecuentemente se realiza en la aplicación
BI o cubo OLAP.

Valores NULL en Tablas de Hechos

Las mediciones que tienen valores NULL se comportan correctamente en

las Tablas de Hechos. Las funciones de agregación (SUM, COUNT, MIN,
MAX y AVG) se comportan bien con hechos que tienen valores NULL.

Sin embargo, los NULL deben evitarse en las claves foráneas de las tablas
de hechos porque los mismos causarían automáticamente una violación de
la integridad referencial.

En lugar de una clave foránea NULL, las tablas de dimensión asociadas

deben tener una fila por default que represente un valor desconocido o
una condición no aplicable.

Hechos Ajustados

Si la misma medición aparece en Tablas de Hechos separadas, deben

tomarse resguardos para asegurar que las definiciones técnicas de los
hechos sean idénticas si son comparadas o computadas conjuntamente.

30
Si las definiciones de hechos separadas son consistentes, los hechos
ajustados deberían ser nombrados idénticamente; pero si son
incompatibles, deberían ser nombrados de manera diferente para alertar a
los usuarios y aplicaciones BI.

Tablas de Hechos de Transacción

Una fila en una Tabla de Hechos de transacción corresponde a un evento

de medición en un punto en espacio y tiempo.

Las Tablas de Hechos cuyo nivel de granularidad es de transacción

atómica/detallada son las tablas más dimensionales y expresivas. Esta
dimensionalidad robusta permite el máximo nivel de slicing y dicing de
datos de las transacciones.

Estas tablas pueden ser o no densas porque las filas solo existen si las
mediciones toman lugar. Además, siempre contienen una clave foránea
por cada dimensión asociada, y opcionalmente contienen timestamps
precisos y claves de dimensiones degeneradas.

Los hechos numéricos medidos deben ser consistentes con la granularidad

de la transacción.

Tablas de Hechos de Snapshots Periódicos

Una fila en una Tabla de Hechos de snapshot periódica sumariza muchos

eventos de medición que ocurren sobre un período estándar, como por
ejemplo: un día, una semana o un mes. La granularidad es el período, no la
transacción individual.

Estas tablas frecuentemente contienen muchos hechos, ya que cualquier

evento de medición consistente con la granularidad de la tabla de hechos
es permisible. Además, son uniformemente densas en sus claves foráneas
porque aún si ninguna actividad toma lugar durante el período, una fila es
típicamente insertada en la tabla conteniendo un cero o NULL por cada
hecho.

31
Tablas de Hechos de Snapshots de Acumulación

Una fila en una Tabla de Hechos de Snapshots de Acumulación sumariza los

eventos de medición que ocurren en pasos predecibles entre el comienzo y
fin de un proceso.

Los procesos de workflow, que tienen un punto de inicio determinado,

pasos intermedios estándares y punto final definido, pueden ser
modelados con este tipo de tablas. Existe una clave foránea de tipo Fecha
en la Tabla de Hechos por cada hito crítico en el proceso.

Una fila individual en una Tabla de Hechos de Snapshots de Acumulación

corresponde, por ejemplo, a una línea en una solicitud o factura
(inicialmente se inserta cuando la línea se crea). Cada vez que hay un
avance en el workflow, la fila de la tabla de hechos se actualiza.

Además de las claves foráneas de fechas asociadas con cada paso crítico
del proceso, las Tablas de Hechos de Snapshots de Acumulación contienen
claves foráneas para otras dimensiones, y opcionalmente contienen
dimensiones degeneradas.

Es frecuente que este tipo de tablas incluya mediciones de retraso

numérico consistentes con la granularidad, junto con contadores de
completitud de los hitos.

Tablas de Hechos sin Hechos

Aunque muchos eventos de medición capturan resultados numéricos, es

posible que el evento solamente registre un conjunto de entidades
dimensionales que vienen juntas en un determinado momento.

Por ejemplo, un evento de un estudiante asistiendo a clases en un día dado

puede que no tenga un hecho numérico registrado, pero que una fila de
hechos con clave foránea para el día calendario, estudiante, profesor,
ubicación y clase, esté bien definida. Asimismo, las comunicaciones con los
clientes son eventos, pero podría no haber métricas asociadas.

Las tablas de hechos sin hechos pueden también ser usadas para analizar
qué no sucedió. Estas consultas siempre tienen dos partes: una tabla sin
hechos que contiene todas las posibilidades de eventos que podrían
suceder y una tabla de actividades que contiene los eventos que
sucedieron. Cuando la actividad se extrae de la primera, el resultado es el
conjunto de eventos que no sucedió.

32
Tablas de Hechos Sumarizadas o Cubos OLAP

Las Tablas de Hechos Sumarizadas son simples rollups numéricos de Tablas

de Hechos atómicas construidas para acelerar la performance de las
consultas. Estas tablas deberían estar disponibles en la capa BI al mismo
tiempo que las Tablas de Hechos atómicas, de modo que las herramientas
BI seleccionen el nivel de sumarización apropiado en el tiempo de consulta.

Este proceso, conocido como agreggate navigation, debe ser abierto de

manera tal que cada herramienta de consulta, reporte y/o aplicación BI -
entre otros- tenga los mismos beneficios de performance. Un conjunto
apropiadamente diseñado de sumarizaciones debería comportarse como
índice de bases de datos que acelere la performance de las consultas.

Las Tablas de Hechos Sumarizadas contienen claves foráneas a

dimensiones ajustadas reducidas, así como hechos sumarizados creados
sumando métricas de tablas de hechos más atómicas.

Finalmente, los cubos OLAP sumarizados con métricas sumarizadas son

frecuentemente construidos de la misma manera que los relacionales, pero
los usuarios pueden acceder directamente a los cubos OLAP.

Tablas de Hechos Consolidados

Es frecuentemente conveniente combinar hechos de múltiples procesos

juntos en una simple tabla de hechos consolidada si pueden ser expresados
a la misma granularidad. Por ejemplo, las ventas actuales pueden
consolidarse con las predicciones de ventas en la misma Tabla de Hechos
para permitir análisis más simples y rápidos en comparación con ensamblar
una aplicación que use tablas separadas.

Estas tablas agregan procesamiento adicional a los ETL, pero también

facilitan el análisis en la aplicación BI. Además, dichas tablas deben
considerarse para métricas de procesos cruzados que frecuentemente se
analizan conjuntamente.

33
Técnicas Básicas para Tablas de Dimensión

A continuación, veremos un conjunto de técnicas básicas para las tablas de

dimensión, de acuerdo con los lineamientos de Ralph Kimball (2013).

Estructura de Tablas de Dimensión

Cada tabla de dimensión tiene una única columna PK. Esta clave primaria
está embebida como una FK en cualquier tabla de hechos asociada, donde
el contexto descriptivo de la fila de la dimensión es exactamente correcto
para esa fila de la Tabla de Hechos.

Las tablas de dimensión generalmente son tablas de-normalizadas con

muchos atributos de texto de baja cardinalidad. Estos atributos son el
objetivo primario de restricciones y agrupamientos en las consultas y
aplicaciones BI.

Claves Subrogadas de Dimensiones

Una tabla de dimensión se diseña con una columna que sirve como única
PK; esta no puede ser la clave natural del sistema operacional porque
habrá múltiples filas de dimensión para esa clave natural cuando los
cambios se sigan en el tiempo. Además, las claves naturales para una
dimensión pueden ser creadas por más de un sistema fuente y pueden ser
incompatibles o pobremente administradas.

El sistema BI necesita tener control de las PK de todas las dimensiones en

lugar de usar claves naturales con fechas agregadas; deberían crearse PK
enteras anónimas para cada dimensión. Estas Claves Subrogadas de
Dimensiones son números enteros, asignados en secuencia, iniciando con
el valor 1.

La dimensión Tiempo está exenta de esta regla, ya que es una dimensión

altamente predecible y estable y puede usar una PK más significativa.

34
Claves Naturales, Durables y Sobrenaturales

Las claves naturales creadas por los sistemas operacionales están sujetas a
reglas de negocio fuera del control del sistema BI.

Cuando el Data Warehouse desea tener una única clave, debe crearse una
nueva clave durable, persistente y que no cambie. En ocasiones, se hace
referencia a la misma como ‘clave sobrenatural durable’. Generalmente
son secuencias numéricas iniciando en 1.

Mientras múltiples claves subrogadas pueden estar asociadas, por ejemplo,

con un registro de un empleado a lo largo del tiempo, aunque sus datos
cambien, la clave durable nunca cambia.

Drill Down

Drill Down es la forma de análisis fundamental. Significa agregar un

encabezado de fila a una consulta existente en la que el nuevo encabezado
es un atributo de dimensión añadido a la expresión GROUP BY en una
consulta SQL. El atributo puede venir de cualquier dimensión adjunta a la
Tabla de Hechos, no requiere la definición de jerarquías predeterminadas.

Dimensiones Degeneradas

En algunas ocasiones una dimensión se define porque no tiene contexto,

excepto para su PK. Una dimensión degenerada es aquella que no tiene
tabla de dimensión asociada. Por otro lado, las Dimensiones Degeneradas
son más comunes en las tablas de hechos de snapshot acumulativas y
transaccionales.

Dimensiones Aplanadas De-normalizadas

En general, los diseñadores dimensionales deben resistir a la

normalización, de-normalizando dimensiones con dos objetivos:
simplicidad y velocidad.

35
Múltiples Jerarquías en Dimensiones

Muchas dimensiones contienen más de una jerarquía natural. En estos

casos, las jerarquías separadas pueden coexistir en la misma tabla de
dimensión. Por ejemplo: en una dimensión tiempo, jerarquía día-semana-
mes-año fiscal y otra de día-mes-año.

Banderas e Indicadores como Atributos Textuales

Las abreviaturas crípticas, banderas verdadero/falso y los indicadores

operacionales deberían ser suplementados en las tablas de dimensión con
palabras de texto completas que tengan significado cuando se visualicen
independientemente.

Los códigos operacionales con significado embebido dentro del valor del
código deberían ser fragmentados en cada parte del código,
expandiéndose en distintos atributos descriptivos de dimensión separados.

Atributos NULL en las Dimensiones

Los atributos de dimensiones con valor NULL resultan cuando una fila de
dimensión dada no ha sido totalmente llenada o cuando hay atributos que
no son aplicables a todas las filas de la dimensión. En ambos casos, Ralph
Kimball (2013) recomienda sustituir un string descriptivo, tal como por
ejemplo: Desconocido o No Aplica, en lugar del valor NULL.

Los valores NULL en los atributos de dimensión deberían evitarse porque

diferentes bases de datos manejan el agrupamiento o restricciones sobre
los NULL de manera inconsistente.

Dimensiones de Fecha Calendario (Tiempo)

Las dimensiones de fecha calendario (Tiempo) están adjuntas virtualmente

a cada Tabla de Hechos para permitir la navegación a través de fechas
familiares, meses, períodos fiscales y días especiales del calendario.

La dimensión Tiempo generalmente tiene muchos atributos que describen

características tales como nº de semana, nombre del mes, período fiscal o
vacaciones nacionales.

36
Para facilitar el particionamiento, la PK de una dimensión Fecha o Tiempo
puede ser más significativa, como un entero que representa AAAAMMDD,
en lugar de dimensión Tiempo necesita una fila especial para representar
fechas desconocidas o a ser determinadas. Cuando se necesita mayor
precisión, un timestamp separado puede agregarse a la tabla de hechos. El
timestamp no es una FK relacionada con una tabla de dimensión, sino que
es una columna aislada.

Por otra parte, si los usuarios del negocio restringen o agrupan los datos en
base a atributos de la hora del día, debería agregarse una FK separada con
los rangos horarios a la tabla de hechos.

Dimensiones ‘Role-Playing’

Una única dimensión física puede ser referenciada múltiples veces en una
tabla de hechos, con cada referencia enlazada a un rol lógicamente distinto
para la dimensión.

Por ejemplo, una tabla de hechos puede tener distintas fechas, cada una de
las cuales estará representada por una FK a la dimensión Tiempo.

Es esencial que cada FK se refiera a una vista separada de la dimensión

Tiempo, de modo que las referencias sean independientes. Estas vistas de
dimensión separadas son llamadas roles.

Dimensiones Inútiles

Los procesos de negocio transaccionales producen normalmente un

número de banderas e indicadores misceláneos de baja cardinalidad. En
lugar de hacer dimensiones separadas para cada bandera y atributo, puede
crearse una única dimensión inútil combinándolas conjuntamente.

Esta dimensión, frecuentemente etiquetada como una dimensión de perfil

transacción en un esquema, no necesita ser el producto cartesiano de
todos los valores posibles del atributo, sino que debería solo contener la
combinación de valores que actualmente están presentes en los datos
fuente.

37
Dimensiones Copos de Nieve

Cuando una relación jerárquica en una tabla de dimensión es normalizada,

los atributos de baja cardinalidad aparecen como tablas secundarias
conectadas a la tabla de dimensión base por una clave de atributo.

Cuando este proceso es repetido con todas las jerarquías de la tabla de

dimensión, una estructura multinivel característica es creada, la cual es
llamada copo de nieve.

Aunque el copo de nieve representa los datos jerárquicos precisamente,

deberían evitarse los copos de nieve porque es difícil para un usuario
comprenderlos y navegarlos; a su vez, pueden impactar negativamente en
la performance de las consultas.

Una tabla de dimensión de-normalizada aplanada contiene exactamente la

misma información que una dimensión en copo de nieve.

Dimensiones de Refuerzo

Una dimensión puede contener una referencia a otra tabla de dimensión.

Por ejemplo, una dimensión de Cuenta Bancaria puede referenciar una
dimensión separada que represente la Fecha en la cual se abrió la cuenta.

Estas referencias a dimensiones secundarias se denominan Dimensiones de

Refuerzo; si bien están permitidas, deberían usarse con moderación. En
muchos casos, las correlaciones entre dimensiones deben llevarse a una
tabla de hechos en donde las dimensiones se representan como FK
separadas.

38
Bibliografía Lectura 3

 Cano, J. L. (2007). Business Intelligence: Competir con Información.

España: Banesto Fundación Cultural y ESADE.

 Inmon, W. (2005). Building the Data Warehouse (4º Edición).

Estados Unidos: Wiley Publishing.

 Kimball Ralph, R. M. (2013). The Data Warehouse Toolkit (3º

Edición). Estados Unidos: Wiley Publishing.

 QlikTech (2010). QlikView architectural overview (White Paper).

Recuperado el 7 de Mayo de 2014:
http://www.swbi.co.uk/pdf/QlikView_Architectural_Overview.pdf

 QlikTech (s.f.). QlikView es pionero del BI en memoria. Recuperado

el 7 de Mayo de 2014:
http://www.qlik.com/es/explore/products/overview

www.uesiglo21.edu.ar

39
Módulo 4
Soluciones de BI
5. Herramientas y
Soluciones de BI
“Existen cuatro tipos de usuarios de una solución de Business
Intelligence (BI): Granjeros, Exploradores, Mineros y Turistas”.

(William Inmon, 2005)

5.1 Tipos de Usuarios

Clasificación de William Inmon

De acuerdo con William Inmon (2005), no existe un único tipo de usuario

de una solución de BI, sino cuatro tipos distintos, cada uno con sus propias
características:

 Granjeros

 Exploradores

 Mineros

 Turistas.

Demográficamente, hay más granjeros que otros tipos de usuarios.

Sin embargo, debe aclararse que el mismo usuario puede variar en

distintos tipos, comportándose según la ocasión o la tarea.

A continuación, analizaremos las principales características de cada uno de

estos cuatro tipos de usuarios.

1
Granjeros

 Es el tipo de usuario más predominante.

 Es una persona predecible. Hace la misma actividad en forma

rutinaria.

 Los tipos de consultas varían solo en el tipo de dato de la consulta.

Repite el mismo tipo de consulta siempre.

 Las consultas tienden a ser cortas; dado que sabe lo que quiere, va
directamente a donde están los datos.

 Sus consultas tienen un patrón de acceso similar (ejemplo: una vez

por semana los lunes a la tarde).

 Tiene un alto ratio de probabilidad de encontrar lo que busca.

 Acceden a los datos activamente usados en el Data Warehouse.

 En el Corporate Information Factory generalmente acceden a Data

Marts.

Exploradores

 Es una persona que no sabe lo que quiere. Opera en un modo de

completa impredecibilidad. Quizás pasen 6 meses sin que haga una
sola consulta y luego haga varias en pocos días.

 Tiene el hábito de navegar en grandes volúmenes de datos. No sabe

lo que quiere antes de iniciar el proceso de exploración. Busca
patrones en los datos que pueden o no existir.

 Opera en modo heurístico, es decir, no sabe el próximo paso de

análisis hasta completar los resultados del paso actual.

 También opera en el marco de proyectos. Cuando se termina un

proyecto, el proceso de exploración finaliza.

 Muchas veces busca algo y nunca lo encuentra, pero en otras

ocasiones, encuentra un diamante del que nadie se había
percatado.

 Acceden a todos los datos del Data Warehouse.

2
  En el Corporate Information Factory, generalmente acceden al Data
Warehouse y al Exploration Warehouse.

Mineros

 Es el individuo que navega en pilas de datos y determina si los datos

dicen algo o no. A partir de un supuesto, determina su validez a
través de herramientas estadísticas.

 Opera en proyectos.

 Crea consultas enormes en tamaño.

 Opera de modo heurístico.

 Frecuentemente trabaja en cooperación con un Explorador. El

Explorador crea los supuestos e hipótesis y el Minero determina su
validez.

 Tiene habilidades especiales en matemática que lo diferencia de

otros técnicos.

 En el Corporate Information Factory, generalmente acceden al Data

Mining Warehouse o al Exploration Warehouse.

Turistas

 Es un individuo que sabe dónde encontrar cosas. Tiene una gran

amplitud de conocimientos, pero no gran profundidad.

 Está familiarizado con los sistemas formales e informales.

 Sabe cómo usar Internet.

 Conoce sobre metadatos, sabe dónde encontrar índices y cómo

usarlos.

 Conoce sobre datos estructurados y desestructurados.

 Conoce de código fuente, cómo leerlo e interpretarlo.

 En el ‘Corporate Information Factory’ generalmente accede al

Repositorio de Metadatos.

3
5.2 Tipos de Soluciones

Clasificación de Wayne Eckerson y Cindi Howson

Por otra parte, de acuerdo con Josep Lluís Cano (2007), en base a la
clasificación de Wayne Eckerson y Cindi Howson (2005), podemos
identificar dos grandes tipos de usuarios:

 Los productores de información

 Los consumidores de información

Para cada uno de los cuales podemos también identificar qué tipo de
soluciones son las más apropiadas:
Los productores de información: Normalmente se trata del 20%
de los usuarios y utilizan herramientas desktop para crear
informes o modelos. […] se trata de estadísticos que utilizan
herramientas Data Mining o autores de informes que utilizan
herramientas de diseño o de programación para crear informes
específicos. Habitualmente los autores de informes son: técnicos
de sistemas de información no usuarios de negocio avanzados que
son capaces de entender la información y la informática. Los
usuarios avanzados pueden crear o utilizar informes, por lo que en
el gráfico están a medio camino entre los productores y los
consumidores de información. Usualmente utilizan hojas de
cálculo, herramientas de consulta y de informes para acceder y
analizar la información.

Los consumidores de información: La mayoría de los

consumidores de información son usuarios no habituales que
regularmente consultan informes para la toma de decisiones, pero
no acceden a los números o hacen análisis detallados diariamente.
Los usuarios no habituales son directivos, gestores, responsables,
colaboradores y usuarios externos. Este numeroso grupo está bien
servido con cuadros de mando con análisis guiados, informes
interactivos (por ejemplo: OLAP, informes parametrizados,
vinculados) e informes de gestión estandarizados. La mayoría de
estas herramientas proveen ahora acceso vía web para promover

4
 el acceso desde cualquier lugar y facilitar el uso y minimizarlos
costes de administración y mantenimiento.

(Cano, 2007, p. 140)

Imagen 1: Tipos de Usuarios y Soluciones según Eckerson y Howson

Fuente: Josep Lluís Cano (2007, p. 141)

Es importante señalar que se diferencian los roles, no los

individuos.

La mayoría de los usuarios no se adecuan absolutamente a una de

las dos categorías. Un ejecutivo podría querer ver información
financiera utilizando un informe estático publicado
semanalmente, pero ver información operacional en tiempo real
utilizando un cuadro de mando.

De esta manera, es crítico conocer la información a la que

acceden los usuarios y las funcionalidades que necesitan en
función de los roles.

(Cano, 2007, p. 141)

5
6. Ciclo de Vida del
Business Intelligence
“El ciclo de vida de un proyecto de Business Intelligence abarca
desde la planificación del proyecto hasta el despliegue,
crecimiento y mantenimiento de la solución.”

(Ralph Kimball, 2013, p. 404)

6.1 Etapas del Ciclo de Vida

Diagrama del Ciclo de Vida de BI

De acuerdo con Ralph Kimball (2013), el ciclo de vida de un proyecto de

Business Intelligence atraviesa un conjunto de etapas:

 Planificación y Gestión del Proyecto

 Definición de los Requerimientos del Negocio
 Diseño de la Arquitectura Técnica
 Selección e Instalación de Productos
 Modelado Multidimensional
 Diseño Físico
 Diseño y Desarrollo de Procesos ETL
 Especificación / Diseño de la Aplicación de BI
 Desarrollo de la Aplicación de BI
 Despliegue
 Crecimiento
 Mantenimiento.

6
A continuación, se presenta un diagrama del ciclo de vida en donde se aprecia cómo se interrelacionan las distintas etapas / tareas:

Imagen 2: Diagrama del Ciclo de Vida de un Proyecto de BI

Fuente: Elaboración propia en base a Ralph Kimball (2013, p. 404)

6.2 Pasos de cada Etapa

A continuación, describiremos las características principales de cada etapa

de acuerdo con lo enunciado por Ralph Kimball (2013).

Etapa de Planificación y Gestión del Proyecto

Todo proyecto de Business Intelligence inicia con una serie de actividades

ligadas a la planificación del proyecto, incluyendo:

 Evaluación de si la organización está preparada para iniciar un

proyecto de BI, en base a tres factores críticos:

- Contar con el apoyo de los directivos;

- contar con una motivación comercial que justifique el

proyecto de BI;

- que exista factibilidad tanto técnica como a nivel de

recursos, pero especialmente la factibilidad para acceder a
los datos transaccionales / operacionales.

 Definición del Alcance del proyecto (por ejemplo, iniciar con un sólo
proceso de negocio) y la justificación del mismo, lo cual está
relacionado con realizar una estimación de los beneficios y costos
asociados al proyecto.

 Conformación de un equipo de personas que sea multi-disciplinario

preferentemente. El equipo estará constituido por varios perfiles;
entre ellos podemos encontrar:

- Sponsor del Negocio (cliente): correspondiente al directivo

que promueve el proyecto

- Líder del Negocio (quién conoce más sobre el negocio y

quién será el referente con el que se comunicará el líder del
proyecto)

- Usuarios Finales

- Analistas del Negocio / Analistas Funcionales

- Administrador de Datos (Data Steward)

- Arquitecto / Diseñador de BI
 - Desarrollador de Aplicaciones de BI

- Project Manager

- Arquitecto Técnico

- Arquitecto de Datos

- Modelador de Datos

- Administrador de Bases de Datos (DBA)

- Coordinador de Metadatos

- Arquitecto / Diseñador ETL

- Desarrolladores de Procesos ETL.

 Desarrollo y mantenimiento del plan del proyecto de BI, el cual

identifica todas las tareas necesarias del ciclo de vida. Aquí es clave
la estimación del esfuerzo requerido en cada tarea así como los
criterios de aceptación e hitos del proyecto.

Etapa de Definición de los Requerimientos del

Negocio

Incluye:

 Pre-planificación de los requerimientos, que consiste básicamente

en seleccionar el lugar adecuado para llevar adelante las
sesiones/entrevistas de captura de requerimientos. Además, se
debe identificar y preparar el equipo que realizará el relevamiento y
captura de requerimientos, al igual que seleccionar
apropiadamente los responsables del negocio/usuarios que serán
entrevistados, si esto fuera posible.

 Captura de los requerimientos del negocio.

 Conducción de entrevistas centradas en los datos, es decir,

teniendo sesiones con los expertos en los sistemas
transaccionales/operacionales.

 Documentación de los requerimientos.

 Priorización de los requerimientos.

9
Etapa de Diseño de la Arquitectura Técnica

Incluye:

 Establecer un mini-equipo dedicado y enfocado en el diseño de la

arquitectura. Generalmente está compuesto por el Arquitecto
Técnico junto con el Arquitecto ETL y el Arquitecto BI.

 Captura de los requerimientos relacionados con la arquitectura

técnica.

 Documentación de los requerimientos de arquitectura.

 Creación del modelo de arquitectura técnica del proyecto.

 Determinación de las fases de implementación de la arquitectura.

 Diseño y especificación de los sub-sistemas.

 Creación del plan de arquitectura técnica.

 Revisión y finalización de la arquitectura técnica.

Etapa de Selección e Instalación de Productos

Incluye las siguientes tareas:

 Comprensión del proceso corporativo interno de compras.

 Desarrollo de una matriz de evaluación de productos.

 Conducción de investigaciones de mercado.

 Evaluación de productos a partir de una lista reducida pre-

seleccionada de opciones.

 Diseño de un prototipo, si fuera necesario.

 Selección de los productos.

 Instalación de versiones trial de los productos.

 Negociación comercial con los proveedores de los productos.

10
Etapa de Modelado Multidimensional

Esta etapa corresponde al modelado de las estructuras multi-

dimensionales del Data Warehouse y/o Data Mart.

Etapa de Diseño Físico

Los modelos multidimensionales desarrollados y documentados necesitan

traducirse en una base de datos física. Con el modelado multidimensional,
los diseños lógico y físico suelen ser bastante similares.

Los detalles de implementación de la base de datos física pueden variar

ampliamente por plataforma y proyecto.

Esta etapa incluye:

 Desarrollo de estándares de bases de datos, como por ejemplo,

nombres de tablas y columnas.

 Desarrollo del modelo físico de base de datos.

 Desarrollo del plan de indexación inicial.

 Diseño de sumarizaciones, incluyendo el diseño de los cubos OLAP,

si es que se incluyen en el proyecto de BI.

 Finalización del almacenamiento físico (bloques, archivos, discos,

particiones y tablespaces, entre otros aspectos).

Etapa de Diseño y Desarrollo de Procesos ETL

En esta etapa se lleva adelante el diseño arquitectónico general de cada

uno de los procesos ETL y posteriormente el desarrollo propiamente dicho
de los mismos.

11
Etapa de Especificación / Diseño de la Aplicación de
BI

Una vez definidos los requerimientos del negocio, se necesita establecer un

conjunto inicial de aproximadamente 10 a 15 reportes y aplicaciones
analíticas de BI.

Antes de proceder a desarrollar las aplicaciones de BI, es necesario

también establecer ciertos estándares tales como el look & feel que
tendrán los distintos dashboards, por ejemplo.

Etapa de Desarrollo de la Aplicación de BI

La actividad de desarrollo puede iniciarse cuando el diseño de la base de

datos esté finalizado, las herramientas BI instaladas y un subconjunto de
datos históricos se carguen en la base de datos.

Etapa de Despliegue

El despliegue depende de la convergencia exitosa entre la tecnología, los

datos y las aplicaciones de BI. Es claro que las tareas relacionadas con los
procesos ETL suelen ser las más impredecibles, puesto que podemos
encontrarnos con cualquier tipo de complejidad en los datos, muchas de
las cuales pueden no haber sido contempladas.

También en el despliegue es necesario realizar un testing end-to-end final,

incluyendo el aseguramiento de la calidad de los datos, el procesamiento
correcto de las distintas operaciones y procedimientos, issues de
performance y, por supuesto, un testing de usabilidad.

También un punto crítico en esta etapa consiste en la capacitación de los

usuarios finales de las nuevas herramientas de BI.

12
Etapas de Crecimiento y Mantenimiento

Luego de la implementación en producción será necesario un trabajo de

mejora continua incluyendo:

 Soporte técnico

 Soporte funcional

 Capacitación

 Nuevas funcionalidades.

A diferencia de los sistemas tradicionales, el cambio en los proyectos de BI

debe visualizarse como una medida del éxito de su despliegue y uso.

6.3 Core Team

De acuerdo con Ralph Kimball, Margy Ross, Warren Thornthwaite, Joy

Mundy y Bob Becker (2008), el Core Team soporta el grueso de la
responsabilidad en el diseño y desarrollo del sistema de BI.

Analista de Negocio / Analista Funcional

El Analista de Negocio o Analista Funcional es el responsable de liderar las

actividades de definición de requerimientos del negocio, como así también
de representar estos requerimientos en la especificación de arquitectura
técnica, modelo multidimensional y aplicaciones de BI.

El rol del Analista de Negocio generalmente se cubre con una persona de

Sistemas que esté extremadamente centrada en el usuario y conozca del
negocio. Alternativamente, podría cubrirse también con una persona de la
organización que conozca bastante del negocio y que no sea del
Departamento de Sistemas, pero debe contar con sólidos fundamentos
técnicos.

En proyectos más pequeños, el propio Project Manager o el Líder del

Proyecto del Negocio puede cubrir esta misma posición. El Analista del

13
Negocio debe contar con fuertes habilidades comunicacionales. Por otro
lado, ser respetado por los clientes/usuarios resulta un plus adicional,
teniendo en cuenta que dicho Analista estará representando al resto del
equipo del proyecto en cuanto a la definición de requerimientos.

Administrador de Datos / Analista de Aseguramiento

de la Calidad (QA)

El Administrador de Datos, o Data Steward en Inglés, es el responsable de

gestionar el acuerdo organizacional en cuanto a las definiciones, reglas de
negocio, valores de dominio permitidos para el Data Warehouse, además
de la posterior publicación de estas definiciones y reglas.

Históricamente se refirió a este rol como el DBA (DataBase Administrator

en Inglés), una función dentro de Sistemas. Sin embargo, es conveniente
que este rol sea cubierto por un experto en la materia/área de interés de la
aplicación de BI por parte del propio negocio/cliente.

Además, este es un rol políticamente cambiante. Deben ser líderes

altamente respetados, comprometidos con el trabajo a través de
inevitables cruces inter-funcionales y apoyados por alta gerencia,
especialmente cuando se requiere del compromiso organizacional.

Algunas veces trabaja en conjunto con los Analistas de Aseguramiento de

la Calidad (QA) quienes garantizan que los datos cargados en el Data
Warehouse sean precisos y completos, identifican potenciales errores en
los datos y buscan su resolución.

En ciertas ocasiones, el Analista QA también es responsable de verificar la

integridad funcional de las aplicaciones de BI. Además, tiene una carga de
trabajo significativa durante la carga de datos inicial para asegurar que los
procesos ETL trabajen correctamente. Dada la necesidad de una
verificación continua de los datos, el rol no finaliza aunque el Data
Warehouse entre en producción.

14
Arquitecto de Datos/Modelador de
Datos/Administrador de Bases de Datos (DBA)

El Arquitecto de Datos es responsable de desarrollar la estrategia

arquitectónica de datos general del sistema de BI asegurando la
reusabilidad, la integración y la optimización.

El Modelador de Datos es responsable de realizar el análisis detallado de

los datos y de desarrollar el modelo de datos multidimensional. Su rol tiene
gran influencia en el éxito del proyecto, los modelos bien diseñados son
más fáciles de implementar al mismo tiempo que satisfacen los
requerimientos de los usuarios.

Para este rol se requiere de gran conocimiento de las estructuras de datos

de los sistemas corporativos como así también de las reglas del negocio. Si
bien es valiosa su experiencia previa en modelado de estructuras de datos,
es clave que no esté demasiado "atado" al pensamiento ligado al modelo
relacional y al diseño normalizado tradicional para poder seguir las técnicas
de diseño multidimensional.

En caso de usarse OLAP, esta persona frecuentemente diseña tanto el

modelo multidimensional sobre el RDBMS como sobre el MDBMS, en
conjunto con el desarrollador de la aplicación de BI. El Modelador de Datos
participa en la actividad de definición de requerimientos en un rol
secundario.

El Administrador de Bases de Datos (DBA, Data Base Administrator en

inglés) se encarga de traducir el modelo multidimensional en una
estructura física de tablas. En algunos casos también está involucrado en el
proceso de modelado multidimensional; por lo tanto, las personas que
cubran este rol deben estar, como mínimo, familiarizadas con estas
técnicas de diseño.

El DBA es responsable del diseño físico general, incluyendo aspectos tales

como particionamiento, plan de índices y otros. Además, el DBA también
es responsable del soporte operativo diario de la base de datos asegurando
la integridad de datos, disponibilidad y performance.

15
Coordinador de Metadatos

Es necesario que alguien tome la responsabilidad de coordinar los

metadatos, puesto que pueden estar ubicados en cualquier parte del
sistema de BI.

En este rol de Coordinador de Metadatos no se es responsable de cargar

los metadatos, sino de asegurar que todos los componentes contribuyen a
su carga, desde los sistemas transaccionales fuente, pasando por el ETL y
hasta las herramientas de visualización de BI.

Esta persona tiene la última palabra sobre qué metadatos se conservan,

dónde se ubican y cómo se publican a los usuarios.

Arquitecto ETL/Desarrollador ETL

El Arquitecto/Diseñador ETL es responsable del diseño end-to-end del

proceso ETL.

El desarrollo de procesos ETL requiere de fuertes habilidades en diseño

modular de sistemas. Este rol muchas veces no se cubre y el desarrollador
debe codificar sin plan alguno.

El Arquitecto/Diseñador ETL debería estar involucrado en la captura de

requerimientos y tener una relación laboral permanente con el equipo de
la aplicación de BI.

Los Desarrolladores ETL construyen, prueban y automatizan los procesos

ETL bajo la dirección del Arquitecto ETL. Quien asuma este rol debe tener
un conocimiento íntimo de los sistemas transaccionales/operacionales
para ayudar en el mapeo, así como un conocimiento básico de los modelos
multidimensionales destino.

Arquitecto BI/Desarrollador de Aplicación BI

El Arquitecto BI tiene la responsabilidad general del sistema BI asegurando

que todo el entorno de BI esté optimizado para tratar los requerimientos
del negocio.

El Arquitecto BI establece el framework y refuerza los estándares que son

usados por los desarrolladores BI.

16
El Desarrollador de Aplicaciones de BI crea y mantiene las aplicaciones de
BI, generalmente usando software de Query & Reporting; además es
responsable de configurar la capa semántica de la herramienta de BI. Este
rol requiere de conocimientos en bases de datos y también habilidades en
programación, junto con una profunda comprensión del negocio y sus
requerimientos.

6.4 Extended Team

De acuerdo con Ralph Kimball, Margy Ross, Warren Thornthwaite, Joy

Mundy y Bob Becker (2008), el Extended Team está conformado por roles
adicionales que contribuyen al proyecto de BI, pero sobre aspectos muy
especializados o temas puntuales.

Desde luego, los roles que aquí mencionamos también pueden ser llevados
a cabo por las personas que conforman el Core Team.

Arquitecto Técnico/Arquitecto de Seguridad

El Arquitecto Técnico/Arquitecto de Seguridad es responsable del diseño

de la infraestructura técnica y la estrategia de seguridad para soportar el
Data Warehouse. Para desempeñar este rol no se necesita ser un experto
en todas las tecnologías de infraestructura y seguridad, sino que más bien
debe proveer cohesión general para asegurar que los componentes se
ajusten entre sí.

Especialistas en Soporte Técnico

Dependiendo de la organización, puede haber especialistas enfocados en

sistemas cliente/servidor, redes, comunicaciones, etc. Estos Especialistas
en Soporte Técnico están involucrados en las etapas iniciales del proyecto
para realizar un análisis de recursos y capacidad de equipos.

Además, durante la selección de los productos aseguran la compatibilidad

con el entorno tecnológico existente. Una vez seleccionada la tecnología,
proceden a la instalación y configuración de los nuevos componentes;
también proveen de soporte continuo en producción.

17
Programador de Data Staging

El Programador de Data Staging es un programador cuyo rol puede ser

cubierto incluso por el desarrollador ETL, pero en este caso, si se usa
alguna estructura de Preparación de Datos (Data Staging, en inglés) se
requerirá entonces de un rol especializado para esta etapa intermedia
entre el ETL y antes de que los datos lleguen al repositorio definitivo del
Data Warehouse.

Consultores Externos

Desde luego, en más de un proyecto se requerirá de uno o más

Consultores Externos especializados en alguno de los roles mencionados
anteriormente.

18
7. Taller
“Escoger aquella herramienta de Business Intelligence que mejor
satisfaga las necesidades de los usuarios en cuanto a las
funcionalidades, con la mejor arquitectura y al mejor coste, no
es una tarea fácil”

(Cano, 2007, p. 163)

7.1 Elección herramienta

Múltiples Alternativas

Uno de los primeros puntos a definir a la hora de encarar un proyecto de

Business Intelligence consiste en identificar qué herramientas vamos a
utilizar. Se debe tener en cuenta que existen múltiples opciones, puesto
que hay muchas empresas que proveen este tipo de software (como puede
verse en el capítulo VI de Josep Lluís Cano, 2007).

Para poder seleccionar correctamente las herramientas de BI que vamos a

utilizar, es importante tener en cuenta las características de nuestros
usuarios.

Josep Lluís Cano (2007), en base a un trabajo de Jonathan Wu (2000),

establece que el proceso de selección de las herramientas puede ser
formal o informal.

Proceso de Selección Informal

Según Josep Lluís Cano (2007, p. 164), “Comúnmente, las organizaciones

no establecen un proceso formal de selección de software y,
desafortunadamente, en la mayoría de los casos este procedimiento no
produce los resultados esperados”.

19
 Es posible, por lo tanto, que una organización haya adquirido
inapropiadamente un software porque no ha destinado los
suficientes recursos en tiempo y dinero para seleccionar la
solución.

La elección de una solución de Business Intelligence no se puede

tomar de cualquier manera: Algunas organizaciones se ven
obligadas a cambiar de proveedor al cabo de uno o dos años. Los
costes para la organización no son tan sólo los de adquisición de
las licencias, sino también los del proyecto de implementación,
que incluyen tanto los de formación de los usuarios como los de
conseguir el conocimiento necesario por parte de la organización
para que la solución sea utilizada.

Debemos tener en cuenta el coste, los requerimientos funcionales

y la arquitectura tecnológica.

(Cano, 2007, p. 165)

Proceso de Selección Formal

Según Josep Lluís Cano (2007, p. 165), “Con un proceso formal de selección
de software la probabilidad deseleccionar la mejor herramienta para la
organización se incrementa sustancialmente”.

El autor describe un conjunto de etapas y tareas a seguir para la selección

formal de software de BI, en base a dos metodologías distintas: la de
Jonathan Wu y la de Wayne Eckerson y Cindi Howson:

Metodología de Jonathan Wu
1. Inicio del proyecto:

1.1. Alcance y objetivos.

1.2. Equipo.

1.3. Comunicación del inicio.

2. Análisis de los procesos de negocio:

2.1. Comprender los procesos actuales y su información

asociada.

20
 2.2. Identificar las mejores prácticas que apoyan a los
objetivos de negocio.

2.3. Análisis de las diferencias.

2.4. Desarrollar como deberían ser los procesos en el

futuro.

3. Definir los requerimientos:

3.1. De negocio:

3.1.1. Presupuesto y plazos.

3.1.2. Requerimientos de información

directiva.

3.2. Funcionales:

3.2.1. Estado de las necesidades de negocio.

3.3. Técnicos:

3.3.1. Estándares de sistemas.

3.3.2. Diagramas de flujo.

3.3.3. Interfaces de sistemas.

4. Punto de decisión: Construir (¿realmente queremos construir la

solución en lugar de utilizar uno de los productos disponibles en el
mercado?) versus comprar.

5. Gestión de los proveedores:

5.1. Demostraciones.

5.2. Análisis de sus ofertas.

5.3. Ranking de las soluciones de los proveedores.

5.4. Negociación

(Cano, 2007, pp. 165-166)

21
Metodología de Wayne Eckerson y Cindi Howson
1. Deberíamos constituir el Comité de Selección de la herramienta
de Business Intelligence. Debería estar formado por todos los
stakeholders de los distintos departamentos, incluido el de
Sistemas de Información. En el Comité debería participar algún
directivo que actúe como sponsor del proyecto. Si tenemos
usuarios con experiencia deben participar en él. Para quesean
efectivos, los comités deben estar compuestos por pocos
miembros.

2. Definir los usuarios y los escenarios de uso: muchas

organizaciones no se preocupan demasiado por los usuarios. Su
foco es crear un Data Mart o un informe, y no definir cuál es la
información que se necesita y para qué rol y nivel de la
organización. Se hace necesario definir quién interactuará con un
informe y cómo, ya que los diferentes tipos de usuarios requieren
distintas herramientas e interfaces. Comprender los segmentos de
usuarios es crítico para gestionar el alcance en la selección y
resolver los conflictos de los requerimientos. Siguiendo este
proceso, puedes descubrir que distintos grupos de usuarios que
tienen los mismos requerimientos quieren soluciones distintas.

3. Refinar los requerimientos de información: Cada herramienta

de Business Intelligence soporta modelos y esquemas ligeramente
diferentes, lo cual es crítico para incorporar los requerimientos en
el proceso de selección. Por ejemplo, los usuarios quizás necesiten
analizar las ventas con los inventarios para calcular “inventarios
por días de venta” de varios grupos de productos y periodos de
tiempo. Este simple requerimiento se convierte en una serie de
características técnicas: 1) multi SQL para consultar dos tablas del
Data Warehouse; 2) capacidad para agregarlos inventarios por
grupos de producto, pero no a través de periodos de tiempo; 3)
suma automática de filas individuales de información para poder
ver los totales del año o por grupos de productos. Las distintas
herramientas de BI solventan estos requerimientos de formas
absolutamente distintas. El Comité de Selección debe comprender
las diferencias y saber qué aproximación será mejor para la
organización.

4. Definir los criterios de selección y su peso. Hay varias

metodologías para capturar los requerimientos de los usuarios:
Entrevistas individuales, análisis de la diferencia o sesiones de
tormenta de ideas. La clave, sin embargo, es trasladar los

22
requerimientos a las capacidades de la herramienta de Business
Intelligence. Por ejemplo, es difícil que los usuarios digan:
“Queremos una herramienta de BI con una capa de metadata”. Lo
que probable mentedirán es que quieren crear sus propios
informes sin necesidad de conocer su lenguaje. Los criterios más
utilizados son viabilidad del vendedor, estrategia del vendedor,
funcionalidades (en consultas, en informes, en entrega de
información, integración con hojas de cálculo, cuadros de mando,
administración, arquitectura, coste, formación y soporte).
Deberemos priorizar cada criterio con un peso. Si se quieren
consultar ejemplos de listas de criterios, se pueden consultar en
www.BIScorecard.com.

5. Solicitudes de información (RFI). Generan mucho trabajo para el

vendedor y poco valor para el comprador; muchos vendedores
dicen “sí” a todos los requerimientos. Para ser justos, algunos
vendedores son más honestos que otros y los requerimientos
están sujetos a interpretación. Por ejemplo, si necesitas una
arquitectura tecnológica basada en Unix, los vendedores que no
soportan Unix pueden ser eliminados. Para aumentar el valor del
RFI, se deben incluir aquellos requerimientos que sean decisivos
en la selección o en la estandarización: Preguntar cómo las
herramientas específicas solucionan los requerimientos de los
usuarios. Las preguntas abiertas, al final, pueden mostrar luz
sobre la aproximación del vendedor y el interés que tiene por el
proyecto. Los vendedores que atienden cuidadosamente las
respuestas en lugar de los que utilizan material preparado y
empaquetado por marketing son más validos.

6. Demostraciones: El Comité debe ver las distintas

demostraciones de los proveedores y debe prepararse un orden
del día para cada vendedor. En el orden del día debe disponerse
de tiempo para hablar de las consideraciones estratégicas, así
como de las capacidades del producto. Se debe invitar a usuarios
que no participan en el Comité a las demostraciones para poder
obtener su opinión y asegurar que han participado en el proceso
de decisión, preguntándoles cuál es su valoración de la habilidad
de los vendedores en cubrir sus requerimientos específicos. Las
demostraciones se pueden basar en los datos del vendedor o en
los propios de la organización: El uso de los de la organización
puede ayudar a comprender mejor las diferencias entre
herramientas, aunque requiere una inversión en tiempo mayor
para el vendedor y la propia organización. Esta alternativa vale la

23
pena si tenemos pocas alternativas, ya que si el número de
productos es muy elevado no es demasiado práctica.

7. Determinar cuál es la herramienta que se ajusta más: Usando

los requerimientos definidos en el punto 4, puntuar los criterios y
las demostraciones; incorporar consideraciones estratégicas,
información cualitativa e información de clientes de la
herramienta para saber cuál de ellas y qué proveedor se ajusta
mejora corto y largo plazo a nuestra organización. Si la elección
está clara, no se deben abandonar las segundas alternativas
completamente: Debemos todavía probar el concepto, negociar el
contrato o poner a prueba si nuestra primera elección tiene
problemas insuperables.

8. Probar el concepto: Sólo deberíamos tener uno o dos

proveedores posibles al llegar a esta fase. Es la oportunidad de
probarla herramienta en nuestro entorno. Únicamente es una
prueba, aunque en este punto es importante conseguir que el
Comité esté centrado en los requerimientos críticos más que en
jugar interminablemente con la herramienta o intentando crear
informes. La prueba del concepto sirve para elegir entre las
alternativas, su propósito es confirmar que el producto funciona
como se espera. Para ello deberemos escoger un grupo de
informes, limitando el alcance, para probar el concepto. Los
informes de ejemplo pueden basarse en los requerimientos
definidos en el punto 3 y que sean moderadamente complejos (se
trata de que no sean simples listados, pero tampoco tan
complejos que un programador experimentado tenga que
destinar un mes completo para crearlos). La prueba del concepto
nos dará la idea de cómo debemos adaptar el resto de nuestra
arquitectura de BI, pero no es la clave definitiva para resolver los
problemas de implementación.

(Cano, 2007, pp. 166-170)

24
Criterios de Selección de la Herramienta / Producto
de BI

Josep Lluís Cano (2007) describe un conjunto de criterios a tener en cuenta

a la hora de seleccionar la herramienta de BI, en base a un trabajo de
Wayne Eckerson y Cindi Howson (2003):
 Evaluar datos financieros sobre del proveedor:

- Total de ingresos de productos de Business Intelligence

/total de sus ventas.

- Ratio entre ingresos por servicios y licencias.

- Evolución de la venta de licencias.

- Resultado económico.

- Evolución de las acciones.

- Recursos destinados a Investigación y desarrollo.

- Estrategia de ventas.

- Fusiones, adquisiciones, etc.

 La estrategia del proveedor:

- Si tiene otros productos (por ejemplo de ETL, base de

datos propia, etc.).

- Cuando venden, ¿qué venden?

- Cuáles son sus principales competidores.

- Cuál es su origen y hacia donde van.

- Cuáles son sus diferencias respecto a los otros

proveedores.

- Posibles evoluciones de la herramienta.

 La arquitectura tecnológica del proveedor.

- Arquitectura orientada a servicios (SOA).

- Estructura común a través de todos los productos.

25
 - Procesamiento en el servidor (o en cliente).

- Desarrollo por capas.

- Conectividad con terceros.

- Solidez del sistema.

- Escalabilidad y rendimiento.

- Alta disponibilidad.

- Que soporte estándar.

 Las funcionalidades de consultas:

- Proteger a los usuarios de las complejidades del motor

de base de datos.

- Consultas ad hoc.

- Consultas totalizadas y detalladas.

- Seleccionar de listas.

- Acceder a distintas fuentes de datos.

- Impacto de las consultas en la base de datos.

- Complejidad del lenguaje de las consultas.

- Acceso desde cliente servidor o vía web.

 Las funcionalidades de informes:

- Estructura de los documentos y flexibilidad.

- Complejidad del documento (distintas fuentes de

datos, tablas combinadas, gráficos).

- Formatos de tablas.

- Tipos de gráficos.

- Cálculos basados en el informe.

- Diseño del informe, formato rápido.

- Control de impresión.

- Formato contextual.

26
 - Capacidades de navegación.

- Formato WYSIWYG.

- Entrega de información:

o Planificada (tiempo, eventos, versiones, etc.).

o Formatos (Excel, PDF, HTML, etc.).

o Dispositivos (correo electrónico, PDA,

impresora).

o Integración en portales.

 Las funcionalidades OLAP:

- Tipo de arquitectura: MOLAP, ROLAP, HOLAP, DOLAP.

- Uso de particiones.

- Proceso de construcción de los cubos.

- Cálculos.

- Jerarquías alternativas.

- Análisis de atributos.

- Soporta otras fuentes OLAP.

- Valores en un momento del tiempo o agregados en un

periodo.

- Navegar a detalle.

- Deshacer en análisis que pasaría si (What if).

- Posibilidad de crear funciones.

- Número de usuarios, dimensiones, etc.

- Pivotar cubos, arrastrar y soltar.

- Tiempo de respuesta.

- Cálculos a nivel de usuario.

- Utilizar jerarquías definidas y caminos de navegación.

- Ranking.

27
 - Alertas y semáforos.

- Juntar tablas y gráficos y navegar de forma

sincronizada.

- Formatos de impresión.

 Las funcionalidades de administración:

- Autentificación de usuarios (LDAP, roles, basados en

web).

- Construcción y mantenimiento del Metadata.

- Administración del servidor.

- Información y monitorización del uso.

- Entornos de desarrollo.

- Control de cambios.

 Los precios:

- Licencias (nominales, concurrentes, por servidor, por

CPU).

- Mantenimiento (importe, actualizaciones y soporte).

- Soporte (niveles, importe, base de datos de

incidencias).

- Importe para el proyecto concreto.

- Coste total de propiedad115 (TCO, “Total Cost of

Ownership”).

(Cano, 2007, pp. 171-174)

28
Criterios de Selección del Implementador de BI

Josep Lluís Cano (2007) propone también una serie de criterios que deben
tenerse en cuenta a la hora de seleccionar la empresa proveedora que
realizará la implementación de la solución de BI. Puntualmente, menciona
los siguientes aspectos:
 Historia.

 Estabilidad y viabilidad financiera.

 Recursos humanos y de gestión.

 Cobertura geográfica.

 Servicios ofertados.

 Experiencia con el producto y en el sector.

 Experiencia con clientes afines.

 Metodología y herramientas de desarrollo.

 Productos y metodologías implementadas.

 Grado de confianza.

A estos criterios deberían añadirse algunos de los que propone

Forrester Research:

 Especialización vertical.

 Facilitar la colaboración con otros proveedores.

 Flexibilidad para cambiar las necesidades del cliente.

 Soporte para la aparición de nuevas tecnologías o la

innovación en los negocios.

 Casar los servicios ofrecidos con las necesidades de los

clientes.

(Cano, 2007, pp. 174-175)

29
Productos de BI

En la Nota Técnica 3 del Capítulo VI (2007, pp. 175-185), Josep Lluís Cano
hace una recopilación de distintos proveedores de productos de BI.

Es evidente que para el caso de las PyMEs muchas veces los costos pueden
resultar definitivamente prohibitivos; en tal caso no queda otra alternativa
por la cual optar que por una herramienta Free Open Source, o bien por
alguna opción comercial de relativo bajo costo, como por ejemplo, para la
visualización de los datos puede ser la planilla de cálculo Microsoft Excel.
En este sentido, Josep Lluís Cano (2007) muestra un ejemplo de acceso a
bases de datos OLAP con Excel (también en el mencionado capítulo VI, pp.
186-192).

Por otro lado, en el capítulo VIII hace un repaso de la evolución de las

herramientas de BI y del mercado global de soluciones de BI.

Para datos de mercado más actualizados puede accederse al informe de

Gartner1, en donde se estima que el mercado global de BI llegó en el año
2012 a un valor de 13.100 millones de dólares en ingresos, con un
crecimiento del 7% con respecto a 2011.

En el informe de Gartner es interesante observar cuáles son las empresas

que tienen mayor participación de mercado,
(http://www.gartner.com/newsroom/id/2507915, 2013) lo cual denota el
grado de implementación de sus productos por parte de las organizaciones
cliente en todo el mundo:

 “SAP: 22,1 %

 Oracle: 14,9%

 IBM: 12,4 %

 SAS: 12,2%

 Microsoft: 9,1%”

1
Sitio Web donde se pueden consultar los datos de mercado actualizados:
http://www.gartner.com/newsroom/id/2507915

30
7.2 Relevamiento del Negocio
Una vez decidida la plataforma tecnológica de soluciones de BI, el
relevamiento del negocio es fundamental para poder comprender los
requerimientos.

Entre los aspectos que debemos tener en cuenta podemos mencionar los
siguientes:

 Datos generales sobre la empresa y el área de Sistemas (todo esto

en caso de que estemos ofertando o proporcionando una solución
de BI a un cliente externo).

 Relevamiento de requerimientos de información con los usuarios

claves.

 Relevamiento de los Sistemas de Información

Transaccionales/Operacionales de la empresa que se utilizarán
como fuente de datos para la construcción del Data Warehouse.

 Otros aspectos.

Josep Lluís Cano (2007) hace, en el capítulo VII, una recorrida de distintos
casos de estudio con diferentes experiencias de implementación de
soluciones de BI.

7.3 Análisis OLTP

Para cada uno de los Sistemas de Información

Transaccionales/Operacionales de la empresa será necesario hacer un
análisis detallado exhaustivo respecto a sus características,
funcionalidades, plataformas tecnológicas y, sobre todo, sus estructuras de
datos. Contar con un Diagrama de Entidad-Relación (DER) de cada uno de
ellos será fundamental.

Josep Lluís Cano (2007) enuncia, en el capítulo VII, distintos casos de

empresas con sus respectivos sistemas origen.

31
7.4 Construcción procesos ETL

A partir de los datos transaccionales/operacionales se deberá proceder a

construir los procesos ETL que terminarán transportando los datos hacia el
Data Warehouse.

Josep Lluís Cano (2007) denota, en el capítulo VII, en su recorrida de

distintos casos de estudio con diferentes experiencias de implementación
de soluciones de BI, las características de varios procesos ETL empleados.

7.5 Armado de Datamart

Los procesos ETL deberán finalmente llevar datos al Data Warehouse y

luego deberá armarse el Data Mart correspondiente.

Josep Lluís Cano (2007), en el capítulo VII, expone el modelo

multidimensional generado en varios casos de estudio. Así, por ejemplo,
podríamos tener un modelo multidimensional como el que sigue,
correspondiente a una concesionaria que vende automóviles en todo el
país:

En el mismo, tenemos 2 hechos:

 Cantidad de unidades vendidas

 Precio unitario

Y además las dimensiones:

 Tiempo (año, mes y día)

 Producto (marca y modelo de auto)

 Sucursal

 Cliente.

32
Imagen 3: Modelo Multidimensional de Ejemplo de Concesionaria

Fuente: Elaboración propia

33
7.6 Presentación

La capa de Presentación es clave, puesto que por más que hayamos

realizado un excelente trabajo de integración y transformación de datos -
entre otros-, lo mismo no aportará valor agregado al usuario final si no
cuenta con una herramienta de visualización/explotación que le sea útil y
fácil de usar.

También Josep Lluís Cano (2007), en el capítulo VII, muestra diferentes

tipos de aplicaciones que se usaron en varias empresas.

Siguiendo el ejemplo de la concesionaria de vehículos, podríamos poner en

la pantalla cada una de las dimensiones para que el usuario pueda
seleccionar los valores que desee para hacer drill-down y ver más detalles.

Así, por ejemplo, como puede verse en la imagen 4, ubicamos los valores
de la dimensión Tiempo en la parte superior de la pantalla y el resto de las
dimensiones en el margen izquierdo de la misma.

Sin embargo, aún no hemos incluido ningún gráfico en la pantalla (como

puede verse en la Imagen 4), para poder visualizar los indicadores
seleccionados.

Imagen 4: Pantalla con Dimensiones sin Indicadores

Fuente: Elaboración propia

34
A continuación, se muestra un gráfico en el que se visualiza el indicador de
Cantidad de Unidades Vendidas, que lo definimos como un SUM del campo
FACT_VENTAS.CANTIDAD. Este gráfico de ejemplo se elaboró incluyendo la
dimensión Producto, de modo tal que podremos ver los autos vendidos por
cada una de las marcas (productos).

Utilizamos un gráfico de torta ordenando los valores desde el producto

más vendido hasta el menos vendido. Los valores se muestran arriba de
cada producto.

Imagen 5: Autos Vendidos por Marca

Fuente: Elaboración propia

Sobre el mismo gráfico vamos a hacer una operación de drill-down. Para

ello, simplemente seleccionaremos un valor de la Dimensión Sucursal.

En este caso, queremos ver para el indicador de Cantidad de Unidades

Vendidas cuántos se vendieron en la sucursal "ROSARIO".

35
Imagen 6: Autos Vendidos por Marca por Sucursal

Fuente: Elaboración propia

Ahora aplicamos un ‘drill-across’ seleccionando un valor de la Dimensión

Cliente. Queremos ver los autos vendidos por marca en la sucursal
"ROSARIO" para el cliente "ABC S.A.".

Imagen 7: Autos Vendidos por Marca por Sucursal por Cliente

Fuente: Elaboración propia

36
A continuación, queremos ver la evolución de las ventas usando el mismo
indicador, pero por tiempo. Para ello, agregamos otro gráfico, en este caso
de barras, para ver los autos vendidos por año, mes y día (es decir,
agregamos la dimensión Tiempo).

En este caso, y a diferencia de las dimensiones anteriores, la dimensión

Tiempo cuenta con una jerarquía (año, mes, día).

Imagen 8: Autos Vendidos por Año

Fuente: Elaboración propia

37
Ahora seleccionamos un año: 2012, con lo cual vemos las ventas para dicho
año. El gráfico nos muestra la evolución mes por mes (hicimos un drill-
down en la jerarquía de la dimensión Tiempo):

Imagen 9: Autos Vendidos por Mes del Año

Fuente: Elaboración propia

Luego, aplicamos un nuevo drill-down y seleccionamos el mes de Junio.

Vemos la evolución de las ventas por día:

Imagen 10: Autos Vendidos por Día del Mes del Año

Finalmente, podemos hacer un análisis combinado.

Fuente: Elaboración propia

38
Supongamos que queremos ver las ventas de RENAULT CLIO en el año
2013, para el mes 9:

Imagen 11: Autos Vendidos por Producto (Marca), Año y Mes

Fuente: Elaboración propia

En definitiva, como conclusión final se establece que la capa de

Presentación de una Solución de Business Intelligence es lo que realmente
termina visualizando el usuario y es con lo que termina interactuando. Por
lo tanto, sus capacidades gráficas, posibilidades de navegación, niveles de
usabilidad, entre otros, son factores claves para el éxito de cualquier
proyecto de BI.

39
Bibliografía Lectura 4

 Cano, J. L. (2007). Business Intelligence: Competir con Información.

España: Banesto Fundación Cultural y ESADE.

 Inmon, W. (2005). Building the Data Warehouse (4º Edición).

Estados Unidos: Wiley Publishing.

 Gartner (2013). Gartner Says Worldwide Business Intelligence, CPM

and Analytic Applications/Performance Management Software
Market Grew Seven Percent in 2012. Recuperado el 8 de Mayo de
2014: http://www.gartner.com/newsroom/id/2507915.

 Kimball Ralph, R. M. (2013). The Data Warehouse Toolkit (3º

Edición). Estados Unidos: Wiley Publishing.

 Kimball Ralph, R. M.; Thornthwaite, W. y Mundy Joy, B. B. (2008).

The Data Warehouse Lifecycle Toolkit (2º Edición). Estados Unidos:
Wiley Publishing.

www.uesiglo21.edu.ar

40