Universidad Nacional de Ingeniería

Facultad de Ciencias y Sistemas

Ingeniería de Sistemas

Título: Inteligencia de Negocio o Business Intelligence (BI).

 Erick José Delgadillo Loaisiga

 Aniett Halima Montalván Castillo
 Ivania Mercedes Sánchez Calderón

Profesor: MSc. Walger José Herrera Treminio

Managua, Abril 2018

Tabla de contenido
Introducción...................................................................................................................................3
Objetivos.........................................................................................................................................3
Desarrollo........................................................................................................................................4
1. Inteligencia de Negocios o Business Intelligence (BI).............................................4
1.1. Proceso de BI...............................................................................................................4
1.2. Beneficios.....................................................................................................................5
2. Data Warehousing y Data Warehouse..........................................................................6
2.1. Data Warehousing.......................................................................................................6
2.2. Data Warehouse..........................................................................................................7
2.3. Data Mart......................................................................................................................7
2.4. Características.............................................................................................................7
2.5. Cualidades....................................................................................................................9
2.6. Ventajas......................................................................................................................11
2.7. Desventajas................................................................................................................11
3. Arquitectura del Data Warehousing............................................................................12
3.1. OLTP...........................................................................................................................12
3.2. Load Manager............................................................................................................13
3.2.1. ETL..........................................................................................................................13
3.3. Data Warehouse Manager.......................................................................................14
3.4. Query Manager..........................................................................................................22
3.5. Herramientas de Consulta y Análisis......................................................................22
3.6. Usuarios......................................................................................................................23
4. Metodologías....................................................................................................................23
BIBLIOGRAFIA.............................................................................................................................26
Introducción

En la actualidad, diariamente se generan gran cantidad de datos en cualquier

organización, como resultado de todas las transacciones que se realizan. Estos
pueden ser almacenados y administrador a través de sistemas transaccionales en
base de datos relacionales.

Pero, llegados a un punto en el que una organización cuente con tantos datos,
necesita que estos dejen de ser simples datos y se transformen en información
que enriquezca las decisiones de los usuarios.

Por lo que, la Inteligencia de Negocios (Business Intelligence BI), permite que el

proceso de toma de decisiones se encuentre fundamentado sobre un amplio
conocimiento de sí mismo y del entorno, minimizando asi el riesgo y la
incertidumbre.

Objetivos
- Exponer sobre la inteligencia de negocios, sus ventajas, desventajas e
importancia.
- Presentar un breve ejemplo sobre BI.
Desarrollo
1. Inteligencia de Negocios o Business Intelligence (BI)

Se puede describir Inteligencia de Negocio (BI), como un concepto que integra por
un lado el almacenamiento y por el otro el procesamiento de grandes cantidades
de datos, con el principal objetivo de transformarlos en conocimiento y en
decisiones en tiempo real, a través de un sencillo análisis y exploración.

Este conocimiento debe ser oportuno, relevante, útil y debe estar adaptado al
contexto de la organización.

Es palabras sencillas, Inteligencia de Negocios es el proceso de convertir datos en

conocimiento y el conocimiento en acción, para la toma de decisiones.

La Inteligencia de Negocios hace hincapié en los procesos de recolectar y utilizar

efectivamente la información, con el fin de mejorar la forma de operar de una
organización, brindando a los usuarios, el acceso a la información clave que
necesitan para llevar a cabo sus tareas habituales y más precisamente, para
poder tomar decisiones oportunas basadas en datos correctos y certeros.

Al contar con la información exacta y en tiempo real, es posible, aparte de lo ya

mencionado, identificar y corregir situaciones antes de que se conviertan en
problemas y en potenciales pérdidas de control de la empresa, pudiendo
conseguir nuevas oportunidades o readaptarse frente a la ocurrencia de sucesos
inesperados.

1.1. Proceso de BI
FASE 1: Dirigir y Planear. En esta fase inicial es donde se deberán recolectar los
requerimientos de información específicos de los diferentes usuarios, así como
entender sus diversas necesidades, para que luego en conjunto con ellos se
generen las preguntas que les ayudarán a alcanzar sus objetivos.

FASE 2: Recolección de Información. Es aquí en donde se realiza el proceso de

extraer desde las diferentes fuentes de información de la empresa, tanto internas
como externas, los datos que serán necesarios para encontrar las respuestas a
las preguntas planteadas en el paso anterior.

FASE 3: Procesamiento de Datos. En esta fase es donde se integran y cargan los

datos en crudo en un formato utilizable para el análisis. Esta actividad puede
realizarse mediante la creación de una nueva base de datos, agregando datos a
una base de datos ya existente o bien consolidando la información.

FASE 4: Análisis y Producción. Ahora, se procederá a trabajar sobre los datos

extraídos e integrados, utilizando herramientas y técnicas propias de la tecnología
BI, para crear inteligencia. Como resultado final de esta fase se obtendrán las
respuestas a las preguntas, mediante la creación de reportes, indicadores de
rendimiento, cuadros de mando, gráficos estadísticos, etc.

FASE 5: Difusión. Finalmente, se les entregará a los usuarios que lo requieran las
herramientas necesarias, que les permitirán explorar los datos de manera sencilla
e intuitiva.

1.2. Beneficios
 Reduce el tiempo mínimo que se requiere para recoger toda la información
relevante de un tema en particular, ya que la misma se encontrará integrada en
una fuente única de fácil acceso.
 Automatiza la asimilación de la información, debido a que la extracción y carga
de los datos necesarios se realizará a través de procesos predefinidos.
 Proporciona herramientas de análisis para establecer comparaciones y tomar
decisiones.
 Cierra el círculo que hace pasar de la decisión a la acción.
 Permite a los usuarios no depender de reportes o informes programados,
porque los mismos serán generados de manera dinámica.
 Posibilita la formulación y respuesta de preguntas que son claves para el
desempeño de la organización.
 Permite acceder y analizar directamente los indicadores de éxito.
 Se pueden identificar cuáles son los factores que inciden en el buen o mal
funcionamiento de la organización.
 Se podrán detectar situaciones fuera de lo normal.
 Permitirá predecir el comportamiento futuro con un alto porcentaje de certeza,
basado en el entendimiento del pasado.
 Los usuarios podrán consultar y analizar los datos de manera sencilla e
intuitiva.

2. Data Warehousing y Data Warehouse

Para llevar a cabo la Inteligencia de Negocio es necesario administrar datos de

variadas fuentes, es aquí donde aparece el término Data Warehouse (DW),
definida por William Harvey Inmon como “una colección de datos orientada al
negocio, integrada, variante en el tiempo y no volátil para el soporte del proceso
de toma de decisiones de la gerencia”.

2.1. Data Warehousing

Es el proceso de extraer y filtrar datos de las operaciones comunes de la

organización, procedentes de los distintos sistemas de información operacionales
y/p sistemas externos, para transformarlos, integrarlos y almacenarlos en un
almacén de datos con el fin de acceder a ellos para dar soporte en el proceso de
toma de decisiones de una organización.

2.2. Data Warehouse

Un data warehouse es un repositorio de datos que proporciona una visión global,

común e integrad de los datos de la organización, independientemente de cómo
se vayan a utilizar posteriormente por los consumidores o usuarios, con las
propiedades siguientes: estable, coherente, fiable y con información histórica. Al
abarcar un ámbito global de la organización y con un amplio alcance histórico, el
volumen de datos puede ser muy grande. Las bases de datos relacionales son el
soporte técnico más comúnmente usado para almacenar las estructuras de estos
datos y sus grandes volúmenes.

2.3. Data Mart

Es la implementación de un DW con alcance restringido a un área funcional,

problema en particular, departamento, tema o grupo de necesidades Es también
conocido como un subconjunto de los datos del DW cuyo objetivo es responder a
un determinado análisis, función o necesidad, con una población de usuarios
específica. Al igual que un DW los datos están estructurados en modelos de
estrella o copo de nieve, y un data mart puede ser dependiente o independiente de
un DW.

2.4. Características
2.4.1. Orientada al negocio

Orientada al negocio es la primera categoría del DW, debido a que “la información
se clasifica en base a los aspectos de interés de la organización”. Es decir que el
DW “excluye la información que no será utilizada exclusivamente en el proceso de
toma de decisiones”. Por lo que a las empresas con el DW se les facilita la toma
de decisiones cuando solamente se les muestra datos exclusivos y necesarios
para su desarrollo.

2.4.2. Integrada

Integrada es la siguiente categoría que debe de conformar un DW, esta “implica

que todos los datos de diversas fuentes que son producidos por distintos
departamentos, secciones y aplicaciones, tanto internos como externos, deben ser
consolidados en una instancia antes de ser agregados al DW”. Debido a que los
datos representan la fuente principal para el DW estos deben de pasar por el
proceso de Integración de Datos, el cual posee diversas técnicas conocidas como
procesos ETL: Extracción, Transformación y Carga de Datos.

2.4.3. Variante en el tiempo

En un DW se manejan grandes volúmenes de información por lo que al momento

de realizar cualquier consulta, los resultados tendrán una variación en el tiempo
dependiendo del tipo de consulta realizada, esto lo diferencia de la información
encontrada en los ambientes operacionales, pues en estos los datos requeridos se
desean obtener en el mismo momento del acceso.

“Es importante tener en cuenta la granularidad de los datos, así como también la
intensidad de cambio natural del comportamiento de los fenómenos de la actividad
que se desarrolle, para evitar crecimientos incontrolables y desbordamientos de la
base de datos”. Pues existen datos que dependiendo de su comportamiento se
pueden registrar a periodos distintos, por ejemplo en FDL, la colocación de
créditos se puede registrar día a día, mientras que los pagos de créditos se
pueden almacenar a nivel mensual. Por lo tanto, “el intervalo de tiempo y
periodicidad de los datos debe definirse de acuerdo a la necesidad y requisitos del
usuario”.

"El almacenamiento de datos históricos, es lo que permite al DW desarrollar

pronósticos y análisis de tendencias y patrones, a partir de una base estadística
de información".

2.4.4. No volátil

Una característica importante de los DW es que no son volátiles, pues “la

información es útil para el análisis y la toma de decisiones solo cuando es
estable”, ya que los datos en ambientes operacionales cambian momento a
momento mientras que en el DW los datos una vez que entran no cambian.

En ambientes operacionales se puede insertar, modificar y eliminar mientras que

en el DW solo existen dos tipos de operaciones: la carga de datos y el acceso a
los mismos.
 2.5. Cualidades

- El BI debe hacer que la información sea fácilmente accesible.

Los contenidos del sistema BI debe ser comprensible. Los datos deben ser
intuitivos para el usuario comercial, no simplemente el desarrollador. Las
estructuras de los datos y las etiquetas deben imitar el vocabulario y los procesos
de pensamiento de los usuarios empresariales.

Los usuarios empresariales quieren separar y combinar datos analíticos en

infinitas combinaciones. Las herramientas y aplicaciones de inteligencia
empresarial que acceden los datos deben ser simples y fáciles de usar. También
deben devolver los resultados de la consulta para el usuario con tiempos de
espera mínimos. Podemos resumir este requisito por simplemente diciendo simple
y rápido.

- El BI debe presentar información de manera consistente.

Los datos en BI deben ser creíbles. Los datos deben ser cuidadosamente
ensamblados desde variedades de fuentes, limpiadas, de calidad garantizada y
lanzada solo cuando están bien para el consumo del usuario. Si dos de las
medidas de rendimiento tienen el mismo nombre, deben significar lo mismo. Por el
contrario, si dos medidas no significan lo mismo, deben etiquetarse diferente.

- El BI debe adaptarse al cambio.

Las necesidades del usuario, las condiciones comerciales, los datos y la

tecnología están sujetos a cambios. El BI debe ser diseñado para manejar este
cambio inevitable correctamente para que no invalide datos o aplicaciones
existentes. Los datos y aplicaciones existentes no deberían cambiarse o
interrumpirse cuando la comunidad empresarial haga nuevas preguntas o se
agregan nuevos datos al almacén. Finalmente, si los datos descriptivos en el BI
deben modificarse, debe tener en cuenta adecuadamente los cambios y hacer que
estos cambios sean transparentes para los usuarios.

- El BI debe presentar información de manera oportuna.

Como el BI se usa de manera más intensiva para las decisiones operativas, los
datos brutos pueden necesitar ser convertidos en información procesable en
horas, minutos, o incluso segundos. El equipo de BI y los usuarios comerciales
deben tener expectativas realistas de lo que significa entregar datos cuando hay
poco tiempo para limpiarlo o validarlo.

- El BI debe ser un bastión seguro que proteja la información.

Las joyas informativas de una organización se almacenan en el data warehouse.

El BI debe controlar eficazmente el acceso a la información confidencial de la
organización.

- El BI debe servir como la base confiable para una mejor toma de

decisiones.

El almacén de datos debe tener los datos correctos para apoyar la toma de
decisiones. Los resultados más importantes de un BI son las decisiones que se
toman en base a la evidencia analítica presentada; estas decisiones generan el
impacto comercial y el valor atribuible al BI.

- La comunidad empresarial debe aceptar el BI para considerarlo exitoso.

No importa que haya creado una solución elegante usando los mejores productos
de su clase y plataformas. Si la comunidad empresarial no adopta el entorno del BI
y lo usa activamente, ha fallado la prueba de aceptación. A diferencia de la
implementación de un sistema operacional donde los usuarios de negocios no
tienen más remedio que usar el nuevo sistema, el uso del BI a veces es opcional.

2.6. Ventajas
- Transforma datos orientados a las aplicaciones en información orientada a
la toma de decisiones.
- Integra y consolida diferentes fuentes de datos (internas y/o externas) y
departamentos empresariales, que anteriormente formaban islas, en una
única plataforma sólida y centralizada.
- Provee la capacidad de analizar y explotar las diferentes áreas de trabajo y
de realizar un análisis inmediato de las mismas.
- Permite reaccionar rápidamente a los cambios del mercado.
- Aumenta la competitividad en el mercado.
- Elimina la producción y el procesamiento de datos que no son utilizados ni
necesarios, producto de aplicaciones mal diseñadas o ya no utilizadas.
- Mejora la entrega de información, es decir, información completa, correcta,
consistente, oportuna y accesible. Información que los usuarios necesitan,
en el momento adecuado y en el formato apropiado.
- Logra un impacto positivo sobre los procesos de toma de decisiones.
- Aumento de la eficiencia de los encargados de tomar decisiones.
- Los usuarios pueden acceder directamente a la información en línea, lo que
contribuye a su capacidad para operar con mayor efectividad en las tareas
rutinarias o no.
- Permite la toma de decisiones estratégicas y tácticas.

2.7. Desventajas

- Requiere una gran inversión, debido a que su correcta construcción no es

tarea sencilla y consume muchos recursos, además, su misma
implementación implica desde la adquisición de herramientas de consulta y
análisis, hasta la capacitación de los usuarios.
- Existe resistencia al cambio por parte de los usuarios.
- Los beneficios del almacén de datos son apreciados en el mediano y largo
plazo.
 - Si se incluyen datos propios y confidenciales de clientes, proveedores, etc,
el depósito de datos atentará contra la privacidad de los mismos, ya que
cualquier usuario podrá tener acceso a ellos.
- Infravaloración de los recursos necesarios para la captura, carga y
almacenamiento de los datos.
- Infravaloración del esfuerzo necesario para su diseño y creación.
- Incremento continuo de los requerimientos de los usuarios.
- Subestimación de las capacidades que puede brindar la correcta utilización
del DWH y de las herramientas de BI en general.

3. Arquitectura del Data Warehousing

3.1. OLTP

Los datos que se cargaran en el DW son extraídos desde aplicaciones, bases de

datos, archivos, etc., es aquí donde los OLTP son necesarios (por sus siglas en
ingles On Line Transaction Processing) pues este “representa toda aquella
información transaccional que genera la empresa en su accionar diario, además,
de las fuentes externas con las que puede llegar a disponer”. Los OLTP que se
encuentran en las organizaciones son: “Archivos de textos, hipertextos, hojas de
cálculos, informes semanales, mensuales, anuales, etc., y bases de datos
transaccionales”.
 3.2. Load Manager

Luego de que se identifican las fuentes de datos que posee la empresa, se deben
de extraer estos datos desde los OLTP para que de esta manera estos puedan ser
manipulados y cargados al DW, el sistema encargado de realizar eso es la
Integración de Datos, esta “agrupa una serie de técnicas y subprocesos que se
encargan de llevar a cabo todas las tareas relacionadas con la extracción,
manipulación, control, integración, depuración de datos, carga y actualización del
DW”. Aquí se encuentran los procesos ETL, el cual es una de las técnicas más
usadas para la Integración de Datos.

En la extracción, “se extrae la información que se considere relevante”, la

transformación “es la encargada de convertir aquellos datos inconsistentes en un
conjunto de datos compatibles y congruentes” y por último la carga “se encarga
de la carga inicial y la actualización o mantenimiento periódico”.

3.2.1. ETL

Un Data Warehouse o un Datamart, se cargan periódicamente, y en él se unifica

información procedente de múltiples fuentes, creando una base de datos con un
esquema en específico. Esto implica que debe existir una serie de procesos que
leen los datos de las diferentes fuentes, los transforman y adaptan al modelo que
se haya definido, los depuran y limpian, y lo introducen en esta base de datos de
destino. Esto es lo que se conoce como procesos ETL, procesos de Extracción,
Transformación y Carga.

Es muy importante diseñar un buen proceso ETL, en él se deben de reconciliar

todos los datos de las diferentes fuentes, realizar los cálculos necesarios, mejorar
la calidad o los datos, y por supuesto adaptarlos al nuevo modelo físico y
almacenarlos en él.

3.2.1.1. Extracción de datos

Es aquí, en donde, basándose en las necesidades y requisitos de los usuarios, se

exploran las diversas fuentes OLTP que se tengan a disposición, y se extrae la
información que se considere relevante al caso.
 3.2.1.2. Transformación de datos

Esta función es la encargada de convertir aquellos datos inconsistentes en un

conjunto de datos compatibles y congruentes, para que puedan ser cargados en el
DW. Estas acciones se llevan a cabo, debido a que pueden existir diferentes
fuentes de información, y es vital conciliar un formato y forma única, definiendo
estándares, para que todos los datos que ingresarán al DW estén integrados.

3.2.1.3. Carga en el Data Warehouse

Esta función se encarga, por un lado de realizar las tareas relacionadas con:

- Carga Inicial (Initial Load).

- Actualización o mantenimiento periódico (siempre teniendo en cuenta un
intervalo de tiempo predefinido para tal operación).

La carga inicial, se refiere precisamente a la primera carga de datos que se le

realizará al DW. Por lo general, esta tarea consume un tiempo bastante
considerable, ya que se deben insertar registros que han sido generados
aproximadamente, y en casos ideales, durante más de cinco años.

Los mantenimientos periódicos mueven pequeños volúmenes de datos, y su

frecuencia está dada en función del gránulo del DW y los requerimientos de los
usuarios. El objetivo de esta tarea es añadir al depósito aquellos datos nuevos que
se fueron generando desde el último actualizado

Por otra parte, el proceso de Carga tiene la tarea de mantener la estructura del
DW, y trata temas relacionados con:

- Relaciones muchos a muchos.

- Claves Subrogadas.
- Dimensiones Lentamente Cambiantes.
- Dimensiones Degeneradas.

3.3. Data Warehouse Manager

El Data Warehouse Manager “almacena datos de forma multidimensional, es
decir, a través de tablas de hechos y tablas de dimensiones”, para que se puedan
realizar los cubos necesarios para la creación del DW. El Data Warehouse
Manager se encarga de “transformar e integrar los datos fuentes y del
almacenamiento intermedio en un modelo adecuado para la toma de decisiones”.

3.3.1. Base de datos multidimensional

Una base de datos multidimensional “es una base de datos en donde su

información se almacena en forma multidimensional, es decir, a través de tablas
de hechos y tablas de dimensiones”. Las bases de datos multidimensionales
poseen tres tipos de modelamiento, que permiten realizar consultas de soporte de
decisión: “Esquema en estrella, esquema copo de nieve y esquema constelación”.
Estos esquemas pueden ser implementados de diversas maneras: “ROLAP,
MOLAP y HOLAP”.

3.3.2. Tablas de hechos

Las tablas de hechos “contienen, precisamente, los hechos que serán utilizados
por los analistas de negocio para apoyar el proceso de toma de decisiones.
Contienen datos cuantitativos”. Los hechos “son datos instantáneos en el tiempo,
que son filtrados, agrupados y explorados a través de condiciones definidas en las
tablas de dimensiones”.

Por ejemplo, una venta puede identificarse como un proceso de negocio de

manera que es factible, si corresponde en nuestra organización, considerar la
tabla de hecho ventas.
3.3.2.1. Tipos de tablas de hechos

Una tabla de hecho es una representación de un proceso de negocio. A nivel

de diseño es una tabla que permite guardar dos tipos de atributos
diferenciados:

- Medidas del proceso/actividad/flujo de trabajo/evento que se pretende

modelizar.
- Claves foráneas hacia registros en una tabla de dimensión.

Existen diferentes tipos de tablas de hechos:

- Transaction Fact Table: representan eventos que suceden en un

determinado espacio-tiempo. Se caracterizan por permitir analizar los datos
con el máximo detalle. Ejemplo, se puede pensar en una venta que tiene
como resultado métricas como el importe de la misma.
- Factless Fact Tables/Coverage Table: son tablas que no tienen medidas, y
tiene sentido dado que representan el hecho de que el evento suceda.
Ejemplo: se puede pensar en la asistencia en un acto benéfico en el que
por cada persona que existe se tiene un registro pero se puede no tener
ninguna métrica asociada más.
- Periodic Snapshot Fact Table: son tablas de hechos usadas para recoger
información de forma periódica a intervalos de tiempo regulares.
Dependiendo de la situación medida o de la necesidad de negocio.
 Ejemplo, se puede pensar en el balance mensual. Los datos se recogen
acumulados de forma mensual.
- Accumulating Snapshot Fact Table: representan el ciclo de vida completo
de una actividad o un proceso. Se caracterizan por presentar múltiples
dimensiones relacionadas con los eventos presenten en un proceso.
Ejemplo, se puede pensar en un proceso de matriculación de un estudiante:
recopila datos durante su periodo de vida que suelen sustituir los anteriores
(superación y recopilación de asignaturas, por ejemplo).

3.3.3. Tablas de dimensiones

Las tablas de dimensiones “definen cómo están los datos organizados

lógicamente y proveen el medio para analizar el contexto del negocio. Contienen
datos cualitativos”. Las tablas de dimensiones “representan los aspectos de
interés, mediante los cuales los usuarios podrán filtrar y manipular la información
almacenada en la tabla de hechos”.

Siguiendo con el ejemplo de una venta, para la misma tenemos el cliente que ha
comprado, la fecha en la que se ha realizado. Estos conceptos pueden ser
considerados como vistas para este proceso de negocio. Puede ser interesante
recuperar todas las compras realizadas por un cliente. Ello nos hace entender por
qué la identificamos como una dimensión.

3.3.3.1. Tipos de tablas de dimensiones

Respecto al punto de vista de la gestión histórica de los datos, éstos se pueden
clasificar como:

- SCD2 Tipo 0. No se tiene en cuenta la gestión de los cambios históricos y

no se realiza esfuerzo alguno. Nunca se cambia la información, ni se
reescribe.
- SCD Tipo 1. No se guardan datos históricos. La nueva información
sobrescribe la antigua siempre. La sobrescritura se realiza, principalmente,
por errores de calidad de datos. Este tipo de dimensiones son fáciles de
mantener, y se usan cuando la información histórica no es importante.
- SCD Tipo 2. Toda la información histórica se guarda en el data warehouse.
Cuando hay un cambio se crea una nueva entrada con fecha y surrogate
key apropiadas. A partir de ese momento será el valor usado para las
futuras entradas. Las antiguas usarán el valor anterior.
- SCD Tipo 3. Toda la información histórica se guarda en el data warehouse.
En este caso se crean nuevas columnas con los valores antiguos y los
actuales son remplazados con los nuevos.
- SCD Tipo 4. Es lo que se conoce habitualmente como tablas históricas.
Existe una tabla con los datos actuales y otra con los antiguos o los
cambios.
- SCD Tipo 6/Híbrida. Combina las aproximaciones de los tipos 1, 2 y 3 (y,
claro, entonces 1+2+3=6). Consiste en considerar una dimensión de tipo 1
y añadir un par de columnas adicionales que indican el rango temporal de
validez de una de las columnas de la tabla. Si bien su diseño es complejo,
entre sus beneficios podemos destacar que reduce el tamaño de las
consultas temporales. Existe otra variante para este tipo de dimensión que
consiste en tener versiones del registro de la dimensión (numerados de 0 a
n+1, donde 0 siempre es la versión actual).

Existen otros tipos de dimensiones, cuya clasificación es funcional:

- Degeneradas: se encuentran como atributos en la tabla de hecho, si bien tiene

el significado de un punto de vista de análisis. Contiene información de baja
 cardinalidad formada por relaciones dicotómicas. Frecuentemente contienen
sólo un atributo y, por ello, no se crea una tabla aparte. Por ejemplo, el sexo de
un paciente.
- Monster: es conveniente comentar que algunas dimensiones pueden crecer
desmesuradamente. Una buena práctica es romper la dimensión en dos tablas:
una que contenga los valores estáticos y otra que contenga los valores
volátiles. Un ejemplo claro puede ser la información de cliente. Debemos ser
conscientes de cuál es la información primordial del mismo y cuál la que sólo
se usa puntualmente en los informes u otros análisis.
- Junk: que contiene información volátil que se usa puntualmente y que no se
guarda de forma permanente en el data warehouse.
- Conformadas: que permite compartir información entre dimensiones. Consiste
en dimensiones definidas correctamente para que sean usadas por dos tablas
y poder así realizar consultas comunes. El ejemplo más fácil es la dimensión
temporal.
- Bridge: que permiten definir relaciones n a m entre tablas de hecho.
Necesarias para definir por la relación entre un piloto y sus múltiples
patrocinadores.
- Role-playing: que tienen asignado un significado. Por ejemplo, podemos tener
la dimensión fecha, pero también fecha de entrega.
- Alta cardinalidad: que contienen una gran cantidad de datos difícilmente
consultables en su totalidad. Por ejemplo, cada uno de los habitantes de un
país.

3.3.4. Métrica

Son los indicadores de negocio de un proceso de negocio. Aquellos conceptos

cuantificables que permiten medir nuestro proceso de negocio. Por ejemplo, en
una venta tenemos el importe de la misma.

3.3.4.1. Tipos de Métricas

Se pueden distinguir diferentes tipos de medidas, basadas en el tipo de
información que recopilan así como su funcionalidad asociada:

- Métricas: valores que recogen el proceso de una actividad o los resultados

de la misma. Estas medidas proceden del resultado de la actividad de
negocio.
 Métricas de realización de actividad (leading): miden la realización de
una actividad. Por ejemplo, la participación de una persona en un
evento.
 Métricas de resultado de una actividad (lagging): recogen los
resultados de una actividad. Por ejemplo, la cantidad de puntos de
un jugador en un partido.
- Indicadores clave: valores correspondientes que hay que alcanzar y que
suponen el grado de asunción de los objetivos. Estas medidas proporcionan
información sobre el rendimiento de una actividad o sobre la consecución
de una meta.
 Key Performance Indicator (KPI): indicadores clave de rendimiento.
Más allá de la eficacia, se definen unos valores que nos explican en
qué rango óptimo de rendimiento nos deberíamos situar al alcanzar
los objetivos. Son métricas del proceso.
 Key Goal Indicator (KGI): indicadores de metas. Definen mediciones
para informar a la dirección general si un proceso TIC ha alcanzado
sus requisitos de negocio, y se expresan por lo general en términos
de criterios de información.

3.3.5. Tipos de Modelamiento de un DW

Existen tres tipos de modelamiento de un DW, está el esquema en estrella, el

esquema Copo de Nieve y el esquema Constelación. Para la realización del DM
para FDL se hará uso del esquema en estrella, pues analizando sus
características es el que mejor se adapta.
• El esquema en estrella "consta de una tabla de hechos central y de varias
tablas de dimensiones relacionadas a esta, a través de sus respectivas claves".

• El esquema Copo de nieve "representa una extensión del modelo en

estrella cuando las tablas de dimensiones se organizan en jerarquías de
dimensiones".

• El esquema Constelación "está compuesto por una serie de esquemas en

estrella, está formado por una tabla de hechos principal y por una o más tablas de
hechos auxiliares, las cuales pueden ser sumarizadas de la principal".

3.3.6. Tipos de Implementación de un DW

- MOLAP (Multidimensional OLAP): es la forma clásica de OLAP y
frecuentemente es referida con dicho acrónimo. MOLAP utiliza estructuras
de bases de datos generalmente optimizadas para la recuperación de los
mismos. Es lo que se conoce como bases de datos multidimensionales (o,
más coloquialmente, cubos). En definitiva, se crea un fichero que contiene
todas las posibles consultas precalculadas. A diferencia de las bases de
datos relacionales, estas formas de almacenaje están optimizadas para la
velocidad de cálculo. También se optimizan a menudo para la recuperación
a lo largo de patrones jerárquicos de acceso. Las dimensiones de cada
cubo son típicamente atributos tales como periodo, localización, producto o
código de la cuenta. La forma en la que cada dimensión será agregada se
define por adelantado.
- ROLAP (Relational OLAP): trabaja directamente con las bases de datos
relacionales, que almacenan los datos base y las tablas dimensionales como
tablas relacionales mientras se crean nuevas tablas para guardar la
información agregada.
- HOLAP (Hybrid OLAP): no hay acuerdo claro en la industria en cuanto a qué
constituye el OLAP híbrido, exceptuando el hecho de que es una base de
datos en la que los datos se dividen en almacenaje relacional y
multidimensional. Por ejemplo, para algunos vendedores, HOLAP consiste en
utilizar las tablas relacionales para guardar las cantidades más grandes de
 datos detallados, y utiliza el almacenaje multidimensional para algunos
aspectos de cantidades más pequeñas de datos menos detallados o
agregados.
- DOLAP (Desktop OLAP): es un caso particular de OLAP ya que está orientado
a equipos de escritorio. Consiste en obtener la información necesaria desde la
base de datos relacional y guardarla en el escritorio. Las consultas y los
análisis son realizados contra los datos guardados en el escritorio.
- In-memory OLAP: es un enfoque por el que muchos nuevos fabricantes están
optando. Consiste en que la estructura dimensional se genera sólo a nivel de
memoria y se guarda el dato original en algún formato que potencia su
despliegue de esta forma (por ejemplo, comprimido o mediante una base de
datos de lógica asociativa). En este último punto es donde cada fabricante
pone su énfasis.

3.4. Query Manager

Este componente realiza las operaciones necesarias para soportar los procesos
de gestión y ejecución de consultas relacionales, tales como Join y agregaciones,
y de consultas propias del análisis de datos, como drill-up y drill-down.

3.5. Herramientas de Consulta y Análisis

Las herramientas de consulta y análisis son sistemas que permiten a los usuarios
realizar la exploración de datos del DW. Básicamente constituyen el nexo entre el
depósito de datos y los usuarios.

Utilizan la metadata de las estructuras de datos que han sido creadas previamente
(cubos multidimensionales, Business Models, etc.) para trasladar a través de
consultas SQL los requerimientos de los usuarios, para luego, devolver el
resultado obtenido.
 3.5.1. Dashboard

Los Dashboard “son una colección de reportes, consultas y análisis interactivos

que hacen referencia a un tema en particular y que están relacionados entre sí”.
Los dashboard son necesarios aplicarlos pues gracias a esto el usuario tendrá un
formato de diseño visual muy llamativo que le permita evaluar la situación de la
empresa fácilmente.

3.6. Usuarios

Los usuarios que posee el DW son aquellos que se encargan de tomar decisiones
y de planificar las actividades del negocio, es por ello que se hace tanto énfasis en
la integración, limpieza de datos, etc, para poder conseguir que la información
posea toda la calidad posible.

Es a través de las herramientas de consulta y análisis, que los usuarios exploran

los datos en busca de respuestas para poder tomar decisiones proactivas.

Usuarios OLTP Usuarios DW

Acceso concurrente Muchos Pocos
Tipo de consultas Predefinidas Complejas, no
predecibles y no
anticipadas
Registros consultados Pocos Muchos
Tiempo de respuesta Crítico No Crítico
Acciones permitidas Agregar, modificar, Consultar
eliminar y consultar.

4. Metodologías

Para la construcción de la Inteligencia de Negocio existen distintas metodologías a

considerar, dependiendo del contexto en el que se encuentre la empresa y los
objetivos que persiga se pueden emplear una u otra metodología.
El enfoque top-down “se utiliza cuando la tecnología y los problemas del negocio
se conocen de antemano. Este enfoque logra la sinergia entre los problemas de
negocio alcanzando los objetivos buscados”, se adapta a la visión de Bill Inmon,
quien considera que el almacén de datos debe responder a las necesidades de
todos los usuarios en la organización, y no sólo de un determinado grupo.

Por otro lado el enfoque bottom-up “es una metodología rápida que se basa en
experimentos y prototipos. Es un método flexible que permite a la organización ir
más lejos con menores costos. La idea es construir DM independientes para
evaluar las ventajas del nuevo sistema a medida que avanzamos. En él, las partes
individuales se diseñan con detalle y luego se enlazan para formar componentes
más grandes, que a su vez se enlazan hasta que se forma el sistema completo.”

Este enfoque se adapta a la visión de Ralph Kimball, que considera que el

almacén de datos tiene que ser entendido fácilmente por los usuarios y ofrecer
respuestas correctas a la mayor brevedad posible. Este enfoque parte de los
requisitos de negocio, mientras que el enfoque top-down propone la validación de
los requisitos una vez que se tiene el sistema.

También hay que considerar la metodología de Business Intelligence Roadmap

(BIR) que especifica el camino y la dirección que deben seguir las aplicaciones,
estructuras, herramientas y personas que intervienen en un proyecto de este tipo;
y la metodología de Data Warehouse EngineeringProcess (DWEP) basada en el
Proceso Racional Unificado o RUP (por sus siglas en ingles de Rational Unified
Process) y en la herramienta de Lenguaje Unificado de Modelado o UML (por sus
siglas en ingles Unified Modeling Language) para desarrollar un Data Warehouse
o DataMart.

HEFESTO es una metodología propia, cuya propuesta está fundamentada en una

muy amplia investigación, comparación de metodologías existentes, experiencias
propias en procesos de confección de almacenes de datos. Cabe destacar que
HEFESTO está en continua evolución, y se han tenido en cuenta, como gran valor
agregado, todos los feedbacks que han aportado quienes han utilizado esta
metodología en diversos países y con diversos fines. La construcción e
implementación de un DW puede adaptarse muy bien a cualquier ciclo de vida de
desarrollo de software, con la salvedad de que para algunas fases en particular,
las acciones que se han de realizar serán muy diferentes. La metodología
HEFESTO, puede ser embebida en cualquier ciclo de vida que cumpla con la
condición antes declarada.

Entre las que se encuentran como ciclo completo están: el ciclo de vida Kimball,
Hefesto,Data Warehouse Engineering Process y la propuesta Road Map.

El Ciclo de vida Kimball es muy “amplia la manera de abordar los elementos para
las etapas de desarrollo, y deja claro qué se debe hacer, pero no cómo lograrlo, lo
que provoca demoras en los resultados.”

El ciclo de vida de Hefesto “presenta un caso de estudio para un negocio

empresarial, que no aporta muchos elementos al negocio de gestión de ensayos
clínicos y solo tiene en cuenta los datos que se cargan desde fuentes
operacionales, lo que provocaría que se obvien datos importantes que se obtienen
de las reglas del negocio o del protocolo del ensayo.”

Data Warehouse Engineering Process “fue propuesta por SAS Institute como una

metodología iterativa y basada en el desarrollo incremental del proyecto, pero
presenta poca documentación, lo que dificulta su aplicación integral.”

Road Map mantiene un ciclo de vida similar al propuesto por Kimball en su

metodología, aunque “solo incluye como técnicas de análisis OLAP y minería de
datos, obviando otras importantes y que pueden ser aplicadas en el entorno de la
gestión de ensayos clínicos.”

Mientras que Bill Inmon “tiene un enfoque a modo de explosión en el sentido de

que en cierto modo no viene acompañada del ciclo de vida normal de las
aplicaciones, sino que los requisitos irán acompañando al proyecto según vaya
comprobándose su necesidad. Esta visión de Inmon puede traer consigo mucho
riesgo a la compañía, ya que invierte grandes esfuerzos en el desarrollo del
datawarehouse y no es hasta la aparición de los datmart cuando se empieza a
explotar la inversión y obtener beneficios.”

BIBLIOGRAFIA
- Darío B., Hefesto. Free Software Foundation. Versión 2.0 (2010).
- Curto D., Josep & Conesa, Jordi. Introducción al Business Intelligence.
Primera Edicipon. (2010).
- Ramos, Salvador. (2011). Microsoft Business Intelligence. Vea el cubo
medio lleno.