CAPÍTULO 11

Data Warehousing e Inteligencia de Negocio

Arquitectura Modelado de
de Datos Datos y Diseño

Almacenamiento
Calidad de de Datos y
Datos Operaciones

Gobierno S eg u ri da d
Metadatos De d e D a tos
Datos

Data Warehousing Integraci6n de

e Inteligencia de Datos e
Interopera-
Negocio Datos
bilidad
Maestros y de Gesti6n de
Referencia Documentos
y Contenido

DAMA-DMBOK2 Marco de Referencia de Gestión de Datos

Copyright © 2017 by DAMA International

1. Introducción

E l concepto de DW (Data Warehouse Almacén de Datos) surgi6 en los años ochenta, cuando
la tecnología permiti6 a las organizaciones integrar datos de una serie de fuentes en un
modelo de datos común. Los datos integrados prometieron proporcionar informaci6 n sobre
los procesos operativos y abrir nuevas posibilidades para aprovechar los datos para la toma de
decisiones y crear valor organizacional. De la misma manera, los DWs fueron vistos como un
medio para reducir la proliferaci6n de sistemas de soporte de decisiones (Decision Support System
- DSS), la mayoría de los cuales se basaron en los mismos datos empresariales centrales. El
concepto de un almacén de datos empresarial ofreci6 una forma de reducir la redundancia de datos,
mejorar la consistencia de la informaci6n y permitir que una empresa utilice sus datos para tomar
mejores decisiones.

363

.
364 DMBOK2

Figura 79 Diagrama de Contexto Datawarehousing e Inteligencia de Negocio

Los DWs comenzaron a construirse en serio en los años noventa. Desde entonces (y especialmente con
la coevoluci6n de BI (Business Intelligence Inteligencia de Negocios) como principal impulsor de la
toma de decisiones empresariales), los DWs se han convertido en un estándar. La mayoría de las
empresas cuentan con DWs, y estos son reconocidos como el núcleo de la gesti6n de datos
empresarial62. Aunque ya esté bien establecida esta práctica, el DW continúa evolucionando. A medida
que se crean nuevas formas de datos con una velocidad cada vez mayor, surgen nuevos conceptos, como los
Data Lakes, que influirán en el futuro del DW. Véanse los capítulos 8 y 15.

62 http://bit.ly/2sVPIYr.

.
 DA T A WAR EH OU SIN G E IN TELI GEN C IA D E NE GOC IO 36 5

1.1 Motivadores de Negocio

El principal motivador para el DW es dar soporte a funciones operativas, requerimientos regulatorios y

actividades de BI (aunque no todas las actividades de BI dependen de los datos del DW). Cada vez a
más organizaciones se les solicita que proporcionen datos como evidencia de que han cumplido con los
requerimientos regulatorios. Debido a que contienen datos hist6ricos, los DW son a menudo los medios
para responder ese tipo de solicitudes. Sin embargo, el soporte a BI continúa siendo la principal raz6n
para un DW. BI ofrece informaci6n sobre la organizaci6n, sus clientes y sus productos. Una
organizaci6n que actúa en base al conocimiento adquirido con BI puede mejorar la eficiencia operativa
y su ventaja competitiva. A medida que más datos están disponibles a mayor ve locidad, BI ha
evolucionado desde la evaluaci6n retrospectiva hasta el análisis predictivo.

1.2 Metas y Principios

Las organizaciones implementan DWs con el fin de:

Dar soporte a la actividad de BI.
Disponibilizar el análisis de negocios y la toma de decisiones de forma efectiva.
Encontrar formas de innovar basadas informaci6n de sus datos.

La implementaci6n de un DW debe seguir estos principios base:

Enfoque en los objetivos empresariales: Asegúrese de que el DW responda a las
prioridades de la organizaci6n y resuelva los problemas empresariales.
Comience con el objetivo final en mente: Permita que las prioridades del negocio y el
alcance del entregable final de datos del ámbito de BI direccionen la creaci6n del contenido
del DW.
Piense y disease globalmente; actúe y construya localmente: Permita que la visi6n final guíe
la arquitectura, pero construya y entregue de forma incremental, a través de proyectos
focalizados o sprints que permitan un retorno de inversi6n inmediato.
Sumarize y optimice al final, no al principio: Construya sobre datos at6micos. Agregue y sume
para cumplir los requerimientos y asegurar rendimiento, no para reemplazar el detalle.
Promueva la transparencia y el autoservicio: Cuanto más contexto (Metadatos de todo
tipo) se proporcione, los consumidores de datos tendrán mayor capacidad para obtener valor
de estos. Mantener a las partes interesadas informadas sobre los datos y sobre los procesos
que conforman la integraci6n.
Construya Metadatos con el DW: Crítico para el éxito del DW es la capacidad de
explicar los datos. Por ejemplo, ser capaz de responder a preguntas básicas como "¿Por qué
esta suma es X?", "¿C6mo fue calculada?" y "¿De d6nde provienen los datos?" Los
Metadatos deben ser capturados como parte del ciclo de desarrollo y administrados como
parte de las operaciones continuas.
Colabore: Colaborar con otras iniciativas de datos, especialmente con las de Gobierno de
Datos, Calidad de los Datos y Metadatos.
El mismo tamaaso no se ajusta a todo: Utilice las herramientas y los productos adecuados
para cada grupo de consumidores de datos.

.
366 DMBOK2

1.3 Conceptos Esenciales

1.3.1 BI (Business Intelligence Inteligencia de Negocios)

El término BI tiene dos significados. En primer lugar, se refiere a un tipo de análisis de datos
destinado a comprender las actividades y oportunidades de la organizaci6n. Los resultados de este
análisis se utilizan para impulsar el éxito de la organizaci6n. Cuando las personas afirman que los
datos son la clave para obtener una ventaja competitiva, están articulando la promesa inherente a la
actividad de BI: que, si una organizaci6n hace las preguntas correctas de sus propios datos, puede
obtener informaci6n sobre sus productos, servicios y clientes que le permitan tomar mejores
decisiones sobre c6mo cumplir con sus objetivos estratégicos. En segundo lugar, BI se refiere a un
conjunto de tecnologías que soportan este tipo de análisis de datos. Existe una evoluci6n de las
herramientas de soporte para la toma de decisiones, ya que las herramientas de BI permiten consultar,
hacer minería de datos, análisis estadístico, generaci6n de informes, modelado de escenarios,
visualizaci6n de datos y elaboraci6n de tablero de mandos. Éstas se utilizan para todo, desde la
elaboraci6n de presupuestos hasta la analítica avanzada.

1.3.2 Data Warehouse

Un DW es una combinaci6n de dos componentes principales: Una base de datos de soporte de toma de
decisi6n integrada y el software relacionado que se utiliza para recopilar, limpiar, transformar y
almacenar datos desde una variedad de fuentes operacionales y externas. Para soportar los
requerimientos de datos hist6ricos, analíticos y de BI, un DW también puede incluir Data Marts
dependientes, que son copias de un subconjunto de datos del DW. En su contexto más amplio, un DW
incluye todos los almacenes o extractos de datos utilizados para soportar la generaci6n de datos para los
fines de BI. Un EDW (Enterprise Data Warehouse Data Warehouse Corporativo) es un DW
centralizado diseñado para atender las necesidades de BI de toda la organizaci6n. Un EDW se adhier e a
un modelo de datos empresarial para garantizar la coherencia de las actividades de apoyo a la toma de
decisiones en toda la empresa.

1.3.3 Data Warehousing

Data Warehousing describe los procesos operativos de extracci6n, limpieza, transformaci6n, control
y carga de los datos en un DW. El proceso de data warehousing se centra en la habilitaci6n de un
contexto empresarial integrado e hist6rico basado en los datos operacionales mediante el
cumplimiento de las reglas de negocio y el mantenimiento adecuado de las relaciones de datos
empresariales. El data warehousing se enfoca en datos estructurados: elementos en campos definidos,
ya sea en archivos o tablas, con documentaci6n similar a la de los modelos de datos. Con los
recientes avances en tecnología, el espacio de BI y DW ahora abarca datos semi -estructurados y no
estructurados. Los datos semi-estructurados, definidos como elementos electr6nicos organizados
como entidades semánticas sin necesidad de afinidad en los atributos, son anteriores a XML, pero no
a HTML; un EDI (Electronic Data Interchange Intercambio Electr6nico de Datos) podría servir de
ejemplo. Los datos no estructurados se refieren a datos que no están predefinido s a través de un
modelo de datos. Debido a que los datos no estructurados existen en un rango de formatos y engloban
elementos tales como correos electr6nicos, texto en formato libre, documentos comerciales, videos,
fotos y páginas web, para nombrar unos pocos, definir una infraestructura de almacenamiento viable
que sostenga las cargas de trabajo analíticas dentro del gobierno de data warehousing es un desafío
aún por superar.

.
 DA T A WA RE HO US IN G E INT E LI GEN C IA D E N E GO CI O 367

1.3.4 Enfoques para el Data Warehousing

Gran parte de la conversaci6n acerca de lo que constituye un DW ha sido impulsada por dos influyentes
líderes de pensamiento, Bill Inmon y Ralph Kimball - quienes tienen diferentes enfoques para modelar
y desarrollar DWs. Inmon define un DW como "una colecci6n de datos orientados a un tema,
integrados, variante de tiempo y no volátil para apoyar el proceso de toma de decisiones de la
gerencia" 63. Un modelo relacional normalizado se usa para almacenar y gestionar datos. Kimbal l define
un DW como "una copia de los datos de una transacci6n, específicamente estructurados para consultas
y análisis". El enfoque de Kimball requiere un modelo dimensional. (Véase el capítulo 5.)

Mientras que Inmon y Kimball abogan por diferentes enfoques para construir DWs, sus definiciones
reconocen ideas centrales similares:
Los DWs almacenan datos de otros sistemas.
El acto de almacenar datos incluye organizar los datos de manera que aumenten su valor.
Los DWs hacen que los datos sean accesibles y utilizables para el análisis.
Las organizaciones construyen DWs porque necesitan poner a disposici6n a las partes
interesadas y autorizadas datos integrados y confiables.
Los datos de un DW sirven para muchos prop6sitos, desde el soporte al flujo de trabajo de la
gesti6n operacional hasta el análisis predictivo.

1.3.5 Fábrica de Información Corporativa (Inmon)

La CIF (Corporate Information Factory - Fábrica de Informaci6n Corporativa) de Bill Inmon es uno de los
dos patrones principales para el data warehousing. Las partes que componen la definici6n de un DW de
Inmon, "orientado a un tema, integrado, variante de tiempo, y no volátil, de datos hist6ricos resumidos y
detallados", describen los conceptos que soportan una CIF y señalan las diferencias entre DWs y sistemas
operacionales.

Orientado a un tema: El DW está organizado en base a las principales entidades

empresariales, en lugar de centrarse en una funcionalidad o aplicaci6n.
Integrado: los datos en el DW están unificados y cohesionados. Las mismas estructuras clave,
codificaci6n y decodificaci6n de estructuras, definiciones de datos y convenciones de
nomenclatura son aplicadas de manera consistente en todo el DW. Debido a que los datos están
integrados, los datos del DW no son simplemente una copia de los datos operativos. En su lugar,
el DW se convierte en un sistema de registro de los datos.
Variante de tiempo: El DW almacena los datos tal como existen en un punto del tiempo. Los
registros en el DW son como fotografías instantáneas. Cada uno refleja el estado de los datos en
un momento del tiempo. Esto significa que consultar datos basados en un período de tiempo
específico siempre producirá el mismo resultado, independientemente de cuándo se envíe la
consulta.
No volátil: En el DW, los registros normalmente no se actualizan como sucede en los
sistemas operacionales. En su lugar, se añaden nuevos datos a los datos existentes. Un
conjunto de registros puede representar estados diferentes de la misma transacci6n.
Datos agregados y detallados: Los datos en el DW incluyen detalles de transacciones a
nivel at6mico, así como datos resumidos. Los sistemas operacionales rara vez realizan

63 http://bit.ly/2sVPIYr.

.
368 DMBOK2

agregaci6n de datos. Cuando los DWs se establecieron por primera vez, las consideraciones de
costo y espacio llevaron a la necesidad de resumir los datos. Los datos resumidos pueden ser
persistentes (almacenados en una tabla) o no persistentes (representados en una vista) en
entornos DW contemporáneos. El factor decisivo en relaci6n con persistir o no lo es
generalmente el rendimiento.
Hist6rico: El enfoque de los sistemas operacionales son los datos actuales. Los almacenes
también contienen datos hist6ricos. A menudo albergan grandes cantidades de ellos.

Inmon, Claudia Imhoff y Ryan Sousa describen el data warehousing en el contexto de la CIF. Vea la Figura
80. Los componentes CIF incluyen:
Aplicaciones: Las aplicaciones realizan procesos operacionales. Los datos detallados de las
aplicaciones se introducen en el DW y en los ODSs (Operational Data Store Almacén de Datos
Operacional) donde pueden ser analizados.
Área de datos para ensayos (staging area): Es una base de datos que se encuentra entre
las bases de datos operacionales fuente y las bases de datos de destino. El área de datos
para ensayos es donde se realiza la extracci6n, la transformaci6n y la carga. No es utilizada
por los usuarios finales. La mayoría de los datos en el staging son transitorios, aunque
normalmente hay una cantidad relativamente pequeña de datos persistentes.
Integraci6n y transformaci6n: En la capa de integraci6n, los datos procedentes de fuentes
dispares se transforman para que puedan integrarse en la representaci6n / modelo corporativo
estándar en el DW y ODS.
ODS: Un ODS es una base de datos integrada de datos operacionales. Puede obtenerse
directamente de las aplicaciones o de otras bases de datos. Los ODSs generalmente
contienen datos actuales o relativamente recientes (30-90 días), mientras que un DW
también contiene datos hist6ricos (a menudo varios años de datos). Los datos en el ODS son
volátiles, mientras que los datos del DW son estables. No todas las organizaciones usan
ODSs. Estos aparecieron para satisfacer la necesidad de datos de baja latencia. Un ODS
puede servir como la fuente primaria para un DW; También puede utilizarse para auditar un
DW.
Data marts: Los Data marts proporcionan datos preparados para el análisis. Estos datos
suelen ser un subconjunto de datos del DW, diseñados para soportar determinados tipos de
análisis o para un grupo específico de consumidores de datos. Por ejemplo, los data marts
puede agregar datos para soportar un análisis más rápido. El modelado dimensional (usando
técnicas de desnormalizaci6n) se utiliza a menudo para diseñar data marts de datos
orientados al usuario.
Data Mart Operacional (OpDM Operational Data Mart): Un data mart operacional es un
data mart centrado en el apoyo de decisiones tácticas. Se obtiene directamente de un ODS, y no
de un DW. Comparte características de un ODS: contiene datos actuales o de corto plazo. Su
contenido es volátil.
Data Warehouse: El DW proporciona un único punto de integraci6n para los datos
corporativos para apoyar la toma de decisiones de gesti6n y el análisis estratégico y la
planificaci6n. Los datos fluyen hacia un DW desde los sistemas de aplicaci6n y ODS, y
fluyen hacia los data marts, usualmente en una sola direcci6n. Los datos que necesitan
correcci6n se rechazan, se corrigen en su fuente e idealmente se vuelven a alimentar a
través del sistema.
Informes operacionales: Son informes que se emiten desde los repositorios de datos.
Datos de referencia, maestros y externos: Además de los datos transaccionales de las
aplicaciones, la CIF también incluye los datos necesarios para entender transacciones, como los
datos de referencia y los datos maestros. El acceso a datos comunes simplifica la

.
 DA T A WAR EH OU SIN G E IN TELI GEN C IA D E NE GOC IO 36 9

integraci6n en el DW. Mientras que las aplicaciones consumen los datos maestros y de
referencia actuales, el DW requiere también valores hist6ricos y los períodos de tiempo
durante los cuales fueron válidos (consulte el capítulo 10).

La figura 80 representa el movimiento dentro de la CIF, desde la recolecci6n y creaci6n de datos a través de
aplicaciones (a la izquierda) hasta la creaci6n de informaci6n a través de data marts y análisis (a la derecha).
El movimiento de izquierda a derecha incluye otros cambios. Por ejemplo,
El prop6sito cambia de la ejecuci6n de las funciones operativas al análisis.
Los usuarios finales de sistemas se mueven de los trabajadores de primera línea a los
tomadores de decisiones.
El uso del sistema se mueve de operaciones fijas a usos ad-hoc.
Los requisitos de tiempo de respuesta son relajados (las decisiones estratégicas toman más
tiempo que las operaciones diarias).
Muchos más datos están involucrados en cada operaci6n, consulta o proceso

Los datos en el DW y data marts difieren de los de las aplicaciones:

Los datos están organizados por tema en lugar de por funci6n.
Los datos son datos integrados en lugar de datos en silos.
Los datos son variantes en el tiempo en lugar de ser solamente valores actuales.
Los datos tienen mayor latencia en el DW que en las aplicaciones.
Se dispone significativamente de muchos más datos hist6ricos en un DW que en las
aplicaciones.

Figura 80 La Fábrica de Informaci6n Corporativa

1.3.6 DW Dimensional (Kimball)

El DW dimensional de Kimball es el otro patr6n principal para el desarrollo de DWs. Kimball define un
almacén de datos simplemente como "una copia de datos transaccionales específicamente estructurados
para consulta y análisis" (Kimball, 2002). Sin embargo, la "copia" no es exacta. Los datos

.
370 DMBOK2

del DW se almacenan en un modelo de datos dimensional. El modelo dimensional está diseñado para
permitir a los consumidores de datos comprender y utilizar los datos, al mismo tiempo que potencia el
rendimiento de la consulta 64. No está normalizado de la forma de un modelo de entidad-relaci6n.

A menudo denominados Esquemas Estrella, los modelos dimensionales están compuestos por hechos
que contienen datos cuantitativos que provienen de procesos de negocio (por ejemplo, números de
ventas) y dimensiones, que almacenan atributos descriptivos relacionados con datos de hechos y
permiten a los consumidores de datos responder preguntas sobre los hechos (por ejemplo, ¿Cuántas
unidades del producto X se vendieron este trimestre?) Una tabla de hechos se une a muchas tablas de
dimensiones, y cuando se ve como un diagrama, asemeja a la forma de una estrella. (Véase el capítulo
5). Múltiples tablas de hechos compartirán las dimensiones comunes o confor madas a través de un
"bus", similar a un bus en una computadora65. Múltiples data marts pueden ser integrados a nivel empresarial
conectándolos al bus de dimensiones conformadas.

La matriz del bus de DW muestra la intersecci6n de procesos de negocio que generan datos de hechos y
las áreas temáticas de datos que representan dimensiones. Existen oportunidades para dimensiones
conformadas donde múltiples procesos usan los mismos datos. La Tabla 27 es un ejemplo de una matriz
de bus. En este ejemplo, los procesos de negocio Ventas, Inventario y Pedidos requieren todos datos de
fecha y producto. Ventas e Inventario requieren los datos de almacenes, mientras que Inventario y
Órdenes requieren datos del proveedor. La fecha, el producto, el almacén y el vendedor son todos los
candidatos para las dimensiones conformadas. En cambio, Bodega no se comparte; solamente es
utilizada en Inventario.

Tabla 27 Ejemplo de Matriz de DW-Bus

Áreas Temáticas
Procesos de Negocio Fecha Producto Almacén Proveedor Bodega
Ventas X X X
Inventario X X X X X
Órdenes X X X
Candidato a Dimensión Conformada Si Si Si Si No

La matriz de bus DW empresarial puede utilizarse para representar los requisitos de datos a largo plazo
para el sistema DW / BI, independientemente de su tecnología. Esta herramienta permite que una
organizaci6n estime el alcance manejable de esfuerzo de desarrollo. Cada implementaci6n genera un
incremento de la arquitectura general. En algún momento, existen esquemas dimensionales suficientes
para cumplir con el objetivo de un entorno integrado de DW empresarial.

La Figura 81 representa la vista de Piezas a Ajedrez del DW de Kimball para la arquitectura de DW / BI.
Tenga en cuenta que el DW de Kimball es más expansivo que el de Inmon. El DW abarca todos los
componentes del área de ensayo de datos y del área de presentaci6n de datos.
Sistemas fuente operacionales: Son las aplicaciones operacionales / transaccionales de la
Empresa. Éstas crean los datos que se integran en el ODS y DW. Este componente es
equivalente a los sistemas de aplicaci6n en el diagrama CIF.

64 http://bit.ly/1udtNC8.
65 El
término bus viene de la formaci6n de Kimball como ingeniero eléctrico, donde un bus era algo que proveía energía
común a un número de componentes eléctricos.

.
 DA T A WAR EHO U S IN G E IN T E LI GENC IA D E N E GO C I O 3 71

Área de ensayo de datos: El área de ensayo de datos de Kimball incluye el conjunto de

procesos necesarios para integrar y transformar los datos para su presentación. Se puede
comparar con una combinación de los componentes de integración, transformación y DW
de la CIF. Kimball se centra en la entrega eficiente de los datos analíticos, un ámbito más
pequeño que la gestión corporativa de datos de Inmon. El DW empresarial de Kimball
puede encajar en la arquitectura del área de ensayo de datos.
Área de presentación de datos: Similar a los Data Marts en la CIF. La diferencia
arquitectónica clave es el paradigma integrador de un "Bus de DW ", como las dimensiones
compartidas o conformadas que unifican los múltiples data marts.
Herramientas de acceso a datos: El enfoque de Kimball se centra en los requerimientos de
datos de los usuarios finales. Estas necesidades impulsan la adopción de herramientas de acceso
a datos apropiadas.

Figura 81 Piezas de ajedrez del DW de Kimball66

1.3.7 Componentes de la Arquitectura DW

El entorno del DW incluye una colección de componentes arquitectónicos que deben organizarse para
satisfacer las necesidades de la empresa. La figura 82 representa los componentes arquitectónicos del
ambiente de DW / BI y de Big Data discutidos en esta sección. La evolución de Big Data ha cambiado el
panorama de DW / BI al añadir otro camino a través del cual los datos pueden ser introducidos en una
empresa.

66 Adaptado de Kimball y Ross (2002). Uso permitido.

.
372 DMBOK2

La Figura 82 también describe aspectos del ciclo de vida de los datos. Los datos se mueven de los
sistemas de origen a un área de ensayo donde pueden ser limpiados y enriquecidos a medida que se
integran y se almacenan en el DW y/o en un ODS. Desde el DW se puede acceder a los datos a través de
data marts o cubos y ser utilizados para diversos tipos de informes. Big Data pasa por un proceso
similar, pero con una diferencia significativa: mientras que la mayoría de DWs integran datos antes de
aterrizar en tablas, las soluciones de Big Data ingestan los datos antes de integrarlos. Big Data BI puede
incluir análisis predictivo y minería de datos, así como formas más tradicionales de reportes. (Véase el
capítulo 14.)

Figura 82 Arquitectura Conceptual DW / BI

1.3.7.1 Sistemas Fuente

Los sistemas fuente, en el lado izquierdo de la Figura 82, incluyen los sistemas operativos y los datos
externos que deben introducirse en el entorno DW / BI. Éstos incluyen típicamente sistemas
operativos tales como CRM (Customer Relationship Management Gestión de Relación con el
Cliente), contabilidad, y aplicaciones de recursos humanos, así como sistemas operacionales que se
diferencian según la industria. También se pueden incluir datos de proveedores y fuentes externas,
como DaaS (Data as a Service Datos como un Servicio), contenido web y cualquier resultado de
cálculo de Big Data.

1.3.7.2 Integración de Datos

La integración de datos abarca ETLs (Extract, Transform y Load - Extracción, Transformación y Carga),
virtualización de datos y otras técnicas para obtener datos de una forma y ubicación comunes. En un
entorno SOA (Service Oriented Architecture Arquitectura Orientada a Servicios), las capas de
servicios de datos son parte de este componente. En la Figura 82, todas las flechas representan proc esos
de integración de datos. (Véase el Capítulo 8.)

.
 DA T A WAR EH OU SIN G E IN TELI GEN C IA D E NE GOC IO 37 3

1.3.7.3 Áreas de Almacenamiento de Datos

El DW tiene un conjunto de áreas de almacenamiento:

Área de datos de ensayo: Un área de datos de ensayo es un almacén de datos intermedio
entre una fuente de datos original y el repositorio de datos centralizado. Los datos se organizan
para que puedan transformarse, integrarse y prepararse para cargarse en el DW.
Dimensiones conformadas de datos de referencia y datos maestros: Los datos de
referencia y maestros se pueden almacenar en repositorios independientes. El DW alimenta
nuevos datos maestros y es alimentado por el contenido de dimensiones conformadas de
repositorios distintos.
DW Central: Una vez transformados y preparados, los datos del DW suelen persistir en la capa
central o atómica. Esta capa mantiene todos los datos históricos atómicos, así como la última
instancia de la ejecución por lotes. La estructura de datos de esta área se desarrolla y es
influenciada en función a las necesidades de rendimiento y los patrones de uso. Estos son
algunos elementos de diseño puestos en consideración:
La relación entre el valor de la clave de negocio y claves subrogadas por temas de
rendimiento.
Creación de índices y claves foráneas para soportar dimensiones.
Técnicas CDC (Change Data Capture Captura de Cambios de Datos) que se utilizan
para detectar, mantener y almacenar historia.
ODS (Operational Data Store): El ODS es una versión de un almacén persistente central
que admite latencias más bajas para usos operativos. Dado que el ODS contiene una
ventana de tiempo de datos y no el historial completo, puede actualizarse mucho más
rápidamente que un DW. A veces, las secuencias en tiempo real son capturadas de forma
instantánea a intervalos predefinidos en el ODS para permitir reportes y análisis integrados.
Con el tiempo, con la creciente frecuencia de actualizaciones impulsadas por las
necesidades del negocio, la creciente tecnología y técnicas para integrar datos en tiempo
real en el DW, muchas implementaciones han integrado sus ODS en la arquitectura
existente de DW o Data Marts.
Data marts: Un data mart es un tipo de almacenamiento de datos utilizado con frecuencia
para soportar capas de presentación de datos en el ambiente DW. También se utiliza para
presentar un subconjunto departamental o funcional del DW para la reportería integrada,
consulta y análisis de información histórica. El data mart está orientado a un área temática
específica, un solo departamento o un único proceso de negocio. También puede constituir la
base de un DW virtualizado en el que la combinación de Data Marts conforman la entidad
DW. Los procesos de integración de datos refrescarán, actualizarán o expandirán el
contenido de los distintos Data marts de la capa de persistencia.
Cubos: Tres enfoques clásicos de implementación soportan OLAP (On-Line Analytical
Processing Procesamiento Analítico en Línea). Sus nombres se refieren a tipos de bases de
datos, como Relacional, Multidimensional e Híbrido.

1.3.8 Tipos de Procesamiento de Carga

Data Warehousing implica dos tipos principales de procesos de integración de datos: cargas históricas y
actualizaciones continuas. Los datos históricos se cargan en general solamente una vez, o algunas veces
mientras que resuelven problemas con los datos, y luego nunca más. Las actualizaciones continuas se
programan y ejecutan constantemente para mantener actualizados los datos del DW.

.
374 DMBOK2

1.3.8.1 Datos Históricos

Una ventaja de un DW es que puede capturar la historia detallada de los datos que almacena. Hay
diferentes métodos para capturar este detalle. Una organización que quiere capturar historia debe
diseñar en base a requerimientos. Ser capaz de reproducir fotos de los datos en un punto en el tiempo,
requiere un enfoque diferente que simplemente presentar el estado actual.

El DW de Inmon sugiere que todos los datos se almacenan en una sola capa de DW. Esta capa
almacenará datos de nivel atómico limpios, estandarizados y gobernados. Una capa de integración y
transformación común facilita la reutilización a través de las implementaciones de entrega. Un modelo
de datos empresarial es necesario para tener éxito. Una vez validado, este único almacén está
disponible para diferentes consumidores de datos a través de un data mart en estructura estrella.

El DW de Kimball sugiere que el DW se compone de una combinación de Data Marts departamentales que
contienen datos limpios, estandarizados y gobernados. Los data marts almacenarán la historia a nivel
atómico. Dimensiones y hechos conformados proporcionarán información de nivel empresarial.

En otro enfoque, la bóveda de datos también limpia y estandariza los datos como parte del proceso de
datos de ensayo. La historia se almacena en una estructura atómica normalizada, subrogada
dimensionalmente, con definición de claves primarias y foráenas. Asegurar que las claves de negocio y
las claves subrogadas permanezcan intactas se convierte en el rol secundario de la bóveda - esta es la
historia del data mart. Los hechos son persistidos aquí como estructuras atómicas. La bóveda está
entonces disponible para una variedad de consumidores de datos a través de los data marts. Al
conservar la historia dentro de la bóveda, la recarga de los hechos es posible cuando incrementos
posteriores introducen cambios de granularidad. Es posible virtualizar la capa de presentación,
facilitando la entrega incremental ágil y el desarrollo colaborativo con la comunidad empresarial. Un
proceso final de materialización puede implementar un data mart más tradicional, en esquema de
estrella, para el consumo del usuario final de producción.

1.3.8.2 Captura de Cambios de Datos por Lotes

Los DWs son a menudo cargados diariamente y atendidos por una ventana de carga en lotes por la
noche. El proceso de carga puede acomodar una variedad de detección de cambios, ya que cada sistema
fuente puede requerir diferentes técnicas de captura de cambios.

Las técnicas de registro de base de datos son probables candidatas para aplicaciones desarrolladas
internamente, ya que es poco probable que las aplicaciones compradas a un proveedor toleren la
modificación con disparadores o sobrecarga adicional. Las cargas de tablas con marcas de tiempo o
registro son las más comunes. Las cargas completas se producen cuando se trata de sistemas legados
construidos sin capacidades nativas de marcado de tiempo (sí, existen aplicaciones sin bases de datos) o
cuando se aplican ciertas condiciones de recuperación por lotes.

La Tabla 28 resume la diferencia entre las técnicas de captura de cambios de datos, incluyendo su
complejidad y velocidad relativas. La columna Superposición identifica si puede haber duplicación de
datos entre los cambios del sistema de origen y el entorno de destino. Cuando la superposición es 'Sí',
es posible que estos datos cambiados ya estén presentes. Cuando el indicador de Eliminación está
establecido en 'Sí', el Método de Cambio de Datos rastrea cualquier borrado que haya ocurrido en el
sistema de origen - útil para las dimensiones por expirar y que ya no están en uso. Cuando las
eliminaciones no son rastreadas por el sistema de origen, se requieren esfuerzos adicionales pa ra
determinar cuándo ocurren. (Véase el Capítulo 8.)

.
 DA T A WAR EHO U S IN G E IN T E LI GENC IA D E N E GO C I O 37 5

Tabla 28 Comparaci6n de las Técnicas CDC

Método Requerimientos de Complejidad Carga de Carga de Super- Elimi-

Sistema Fuente Hechos Dimensiones posi- nacio
ci6n nes
Carga de Los cambios en el sistema
cambios en fuente están marcados con la Baja Rápida Rápida Si No
marcas de hora y fecha del sistema.
tiempo
Carga de Los cambios en el sistema
cambios en fuente están capturados en Media Nominal Nominal Si Si
tablas de tablas de registro
registro
Registro de La Base de Datos captura los
transacciones cambios en el registro Alta Nominal Nominal No Si
de la Base de transaccional
Datos
Cambios en Los cambios en el sistema
mensajes fuentes son publicados como Extrema Lenta Lenta No Si
mensajes en tiempo [casi] real
Carga No hay indicadores de
Completa cambios, las tablas son Simple Lenta Nominal Si Si
extraídas completamente y
comparadas para
identificar cambios

1.3.8.3 Tiempo Casi Real y Tiempo Real

Con el comienzo del BI Operacional (o Analítica Operacional) presionando por una menor latencia y una
mayor integraci6n de datos en tiempo real o casi en tiempo real en el DW, surgieron nuevos enfoques
arquitect6nicos para tratar la inclusi6n de datos volátiles. Por ejemplo, una aplicaci6n común de BI
operacional es el aprovisionamiento automatizado de datos de la maquinaria bancaria. Al realizar una
transacci6n bancaria, los saldos hist6ricos y los nuevos saldos resultantes de las acciones bancarias
inmediatas deben presentarse al cliente bancario en tiempo real. Dos conceptos clave de diseño que se
requieren para el aprovisionamiento de datos en tiempo casi real son el aislamiento del cambio y las
alternativas al procesamiento por lotes.

El impacto de los cambios de los nuevos datos volátiles debe aislarse de la mayor parte de los datos
hist6ricos no volátiles del DW. Los enfoques arquitect6nicos típicos para el aislamiento incluyen una
combinaci6n de particionamiento y el uso de consultas que unan las dife rentes particiones. Las
alternativas al procesamiento por lotes manejan los requerimientos de tiempos de latencia cada vez más
cortos para la disponibilidad de datos en el DW. Existen tres tipos principales: la alimentaci6n por
goteo, la mensajería y la transmisi6n en flujo, que difieren en funci6n de d6nde se acumulan los datos
mientras se espera su procesamiento. (Véase el Capítulo 8.)
Alimentaci6n por goteo (acumulaci6n en la fuente): En lugar de ejecutar la carga en un
horario nocturno, el goteo ejecuta cargas por lotes con mayor frecuencia (por ejemplo, cada hora,
cada 5 minutos) o cuando se alcanza un umbral (por ejemplo, 300 transacciones, 1Gb de datos).
Esto permite que algo de procesamiento ocurra durante el día, pero no tan

.
376 DMBOK2

intensamente como con un proceso dedicado por lotes durante la noche. Se necesita
cuidado para asegurar que, si un lote de alimentaci6n por goteo tarda más en completarse
que el tiempo entre alimentaciones, el siguiente debe retrasarse para que los datos se
carguen todavía en el orden correcto.
Mensajería (acumulaci6n en el bus): La interacci6n de mensajes en tiempo real o casi en
tiempo real es útil cuando paquetes de datos extremadamente pequeños (mensajes, eventos o
transacciones) son publicados en un bus cuando éstos ocurren. Los sistemas de destino se
suscriben al bus y procesan los paquetes gradualmente en el DW según sea necesario. Los
sistemas fuente y los sistemas de destino son independientes entre sí. DaaS utiliza con frecuencia
este método.
Streaming (acumulaci6n en el destino): En lugar de esperar un horario o umbral basado en la
fuente, un sistema de destino recopila los datos a medida que se reciben en un buffer o cola y son
procesados en orden. La interacci6n resultante o algún agregado pueden aparecer posteriormente
como una carga adicional al DW.

2. Actividades

2.1 Entender los requerimientos

Desarrollar un DW es diferente a desarrollar de un sistema operacional. Los sistemas operacionales

dependen de requerimientos precisos y específicos. Los DWs reúnen datos que se utilizarán de
diferentes maneras. Además, su uso evolucionará con el tiempo a medida que los usuarios analicen y
exploren datos. Es necesario tomarse el tiempo en las fases iniciales para hacer preguntas relacionadas
con las capacidades y fuentes de datos que apoyarán estas capacidades. En este caso, diseñar se traduce
en reducci6n de retrabajos en el futuro cuando el procesamiento de datos sea probado usando fuentes de
datos reales.

En el levantamiento de requerimientos para los proyectos de DW / BI, hay que comenzar con las metas
y la estrategia del negocio. Identificar y alcanzar a las áreas de negocio, y después identificar y
entrevistar a las personas de negocio adecuadas. Hay que preguntar qué hacen y porqué. Se necesita
capturar las preguntas específicas que ellos se están haciendo ahora, y quiénes quieren pedir datos.
Documentar c6mo distinguir y categorizar aspectos importantes de la informaci6n. Donde sea posible,
definir y capturar métricas clave de rendimiento y cálculos. Estos pueden revelar reglas de negocio que
proporcionen la base para la automatizaci6n de las expectativas de calidad de datos.

Catalogue requerimientos y deles prioridad a aquellos que son necesarios para salir a producci6n y para
la adopci6n del DW, y determine aquellos que pueden esperar. Busque puntos que sean simples y
valiosos para incentivar la productividad de la versi6n inicial del proyecto. Un informe de
requerimientos del proyecto de DW / BI debe enmarcar todo el contexto de las áreas de negocio y / o
procesos que están en su alcance.

2.2 Definir y Mantener la Arquitectura DW / BI

La arquitectura DW / BI debe describir de d6nde vienen los datos, a d6nde van, cuándo van, por qué y c6mo
ingresan en un DW. El "c6mo" incluye el detalle de hardware y software y el marco organizativo para juntar
todas las actividades. Los requisitos técnicos deben incluir el rendimiento, la disponibilidad y las
restricciones de tiempo. (Ver Capítulos 4 y 8.)

.
 DA T A WAR EHO U S IN G E IN T E LI GENC I A D E N E GOC I O 37 7

2.2.1 Definir Arquitectura Técnica DW / 8I

Las mejores arquitecturas de DW / BI son aquellas que diseñan un mecanismo para conectarse de
regreso hacia reportes de nivel transaccional y reportes de nivel operacional en un DW at6mico. Este
mecanismo protegerá al DW de tener que cargar con todo el detalle transaccional. Un ejemplo es
proporcionar un mecanismo de visualizaci6n para informes operativos clave o formularios basados en
una clave transaccional, como Número de Factura. Los clientes siempre desearán todo el detalle
disponible, pero algunos de los datos operacionales, como los campos de descripci6n largos, s6lo
tienen valor en el contexto del reporte original y no proporcionan valor analítico.

Una arquitectura conceptual es un punto de partida. Muchas actividades son necesarias para alinear
correctamente los requerimientos no funcionales con las necesidades del negocio. Los prototipos pueden
demostrar o refutar rápidamente los puntos clave antes de compromisos costosos con las tecnologías o
arquitecturas. Además, el empoderamiento de la comunidad empresarial con los programas de
conocimiento y adopci6n defendidos a través de un equipo de gesti6n del cambio ayudará en la
transici6n y el continuo éxito de la operaci6n en curso.

Una extensi6n natural de este proceso de transformaci6n es el mantenimie nto, o al menos la

validaci6n, con el modelo de datos empresarial. Dado que el foco está en las estructuras de datos que
están en uso por las áreas de la organizaci6n, hay que validar el despliegue físico contra el modelo
l6gico. Hay que generar actualizaciones si ocurren omisiones o errores.

2.2.2 Definir Procesos de Gestión DW / 8I

Es necesario dirigir la gesti6n de ambientes productivos con un proceso de mantenimiento coordinado e

integrado, entregando nuevas versiones peri6dicamente a la comunidad empresarial.

Es crucial establecer un plan estándar de liberaci6n (ver Secci6n 2.6). Idealmente, el equipo del
proyecto de DW debe gestionar cada actualizaci6n al producto de datos desplegado como una liberaci6n
de software que provee funcionalidad adicional. Establecer un calendario para los lanzamientos permite
generar un plan anual de demanda, una planificaci6n de recursos y una programaci6n estandarizada de
entregas. Se debe utilizar el lanzamiento interno para ajustar esta programaci6n estandarizada, las
expectativas de recursos y las hojas de estimaci6n generadas para ello.

Establecer un proceso de liberaci6n garantiza que la gerencia comprenda que se trata de un proceso
proactivo centrado en productos de datos y no un producto instalado orientado mediante la resoluci6n
reactiva de problemas. Es fundamental trabajar de manera proactiva y colaborativa en un equipo
multifuncional para agregar y mejorar continuamente las funcionalidades - los sistemas de soporte
reactivos reducen la adopci6n.

2.3 Desarrollar el Data Warehouse y Data Marts

Normalmente, los proyectos DW / BI tienen tres caminos de desarrollo simultáneos:

Datos: Los datos necesarios para soportar el análisis que el negocio desea hacer. Este
camino implica la identificaci6n de las mejores fuentes para los datos y el diseño de reglas
con la mejor manera para remediarlos, transformarlos, integrarlos, almacenarlos y ponerlos a
disposici6n de las aplicaciones. Este paso también incluye decidir como manejar datos que
no cumplen con las expectativas.

.
378 DMBOK2

Tecnología: Son los sistemas back-end y los procesos que soportan el almacenamiento y el
movimiento de datos. La integración con la empresa existente es fundamental, ya que el DW
no es una isla en sí misma. Las arquitecturas empresariales, específicamente las
especializadas en tecnología y aplicaciones, suelen gestionar este camino.
Herramientas de BI (Business Intelligence Inteligencia de Negocios): Es un conjunto de
aplicaciones necesarias para que los consumidores de datos obtengan información significativa
de los productos de datos desplegados.

2.3.1 Mapear Fuentes hacia Destinos

El mapeo de fuentes a destinos establece reglas de transformación para entidades y elementos de

datos desde fuentes individuales a un sistema de destino. Dicho mapeo también documenta el linaje
para cada elemento de datos disponible en el entorno de BI hasta a su (s) fuente (s) respectiva (s). La
parte más difícil de cualquier esfuerzo de mapeo es determinar enlaces válidos o equivalencias entre
elementos de datos en sistemas múltiples. Consideremos el esfuerzo de consolidar los datos en un
DW de múltiples sistemas de facturación o de gestión de pedidos. Lo más probable es que las tablas
y campos que contengan datos equivalentes no tengan los mismos nombres o estructuras. Una
taxonomía sólida es necesaria para mapear elementos de datos en diferentes sistemas a una estructura
consistente en el DW. La mayoría de las veces, esta taxonomía es el modelo lógico de datos. El
proceso de mapeo también debe considerar si los datos en diferentes estructuras deben añadirse,
modificarse o insertarse.

2.3.2 Remediar y Transformar Datos

Las actividades de remediación o limpieza de datos fomentan el cumplimiento de normas y corrigen y

mejoran los valores de dominio de elementos de datos individuales. La remediación es
particularmente necesaria para las cargas iniciales cuando se trata de un dato histórico significativo.
Para reducir la complejidad del sistema de destino, los sistemas de origen deben hacerse responsables
de la remediación y corrección de datos.

Desarrolle estrategias para los registros de datos que se carguen, pero se encuentre que sean
incorrectos. Una política para eliminar registros antiguos puede causar algunos estragos con tablas
relacionadas y claves foráneas, hacer expirar el registro y cargar los nuevos datos como un regisrto
completamente nuevo, puede ser una mejor opción.

Una estrategia de carga optimista puede incluir la creación de entradas de dimensión para acomodar
datos de hechos. Tal proceso debe tener en cuenta cómo actualizar y expirar dichas entradas. Las
estrategias de carga pesimista deben incluir un área de reciclado para los datos de hechos que no se
pueden asociar con las correspondientes claves de dimensión. Estas entradas requieren una
notificación, alertas y reportes apropiados para asegurar que se rastreen y se vuelvan a cargar más
tarde. Los procesos de hechos deben considerar primero cargar entradas recicladas, luego procesar el
contenido recién llegado.

La transformación de datos se centra en actividades que implementan reglas de negocio dentro de un

sistema técnico. La transformación de datos es esencial para la integración de datos. Definir las reglas
correctas para integrar los datos a menudo requiere la participación directa de los Data Stewards y otros
SMEs (Subject Matter Experts Expertos en la Materia). Las reglas deben ser documentadas para que
puedan ser gobernadas. Las herramientas de integración de datos realizan estas tareas. (Véase el
Capítulo 8.)

.
 DA T A WAR EHO U S IN G E IN T E LI GENC IA D E N E GO C I O 37 9

2.4 Poblar el DW

La mayor parte del trabajo en cualquier esfuerzo DW / BI es la preparación y procesamiento de los

datos. Las decisiones y principios de diseño que definen el nivel de detalle de los datos que contienen
los DWs son una prioridad de diseño clave para la arquitectura DW / BI. La publicación de reglas claras
sobre qué datos estarán disponibles únicamente a través de reportes operativos (no en DW) es
fundamental para el éxito de los esfuerzos de DW / BI.

Los factores clave a considerar al definir un enfoque de llenado son la latencia requerida, la
disponibilidad de fuentes, las ventanas de lotes o los intervalos de carga, las bases de datos de destino,
los aspectos dimensionales y la consistencia de márgenes de tiempo del DW y data mart . El enfoque
también debe abordar el procesamiento de la calidad de los datos, el tiempo para realizar
transformaciones y las dimensiones que lleguen tarde y los datos rechazados.

Otro aspecto para definir un enfoque de llenado se centra en el proceso de captura de cambios de datos,
detectando cambios en el sistema de origen, integrando esos cambios y alineando los cambios a lo
largo del tiempo. Varias bases de datos proporcionan ahora la funcionalidad de captura de registro
sobre las cuales las herramientas de integración de datos pueden operar directamente, de modo que la
base de datos informa al usuario de lo que ha cambiado. Los procesos de scripting pueden ser escritos o
generados cuando esta función no está disponible. Varias técnicas están disponibles para los equipos de
diseño y construcción para la alineación de latencia a través de cargas heterogéneas.

El primer incremento abre el camino para el desarrollo de capacidades adicionales y la incorporación

de nuevas unidades de negocio. Muchas nuevas tecnologías, procesos y habili dades son necesarias, así
como una planificación cuidadosa y atención al detalle. Los incrementos de flujos de bajada de datos
se basan en este elemento fundamental, por lo que se recomiendan más inversiones para sostener datos
de alta calidad, arquitectura técnica y transición a los ambientes productivos. Se deben crear procesos
para facilitar y automatizar la identificación oportuna de errores de datos con la integración del usuario
final del flujo de trabajo.

2.5 Implementar el Portafolio de BI

La implementación del Portafolio de BI consiste en identificar las herramientas adecuadas para las
comunidades de usuarios adecuadas dentro o entre unidades de negocio. Identificar similitudes a
través de la alineación de procesos comunes de negocio, análisis de rendimiento, estilos de
administración y requisitos.

2.5.1 Agrupar a Usuarios de acuerdo con las Necesidades

En la definición de los grupos de usuarios destino, existe un espectro de necesidades de BI. En primer
lugar, conocer los grupos de usuarios y, a continuación, cotejar la herramienta con los grupos de
usuarios en la empresa. En un extremo del espectro están los desarrolladores de TI que se preocupan
por extraer datos, que se centran en funcionalidades avanzadas. En el otro extremo, los consumidores
de información pueden desear acceso rápido a los reportes previamente desarrollados y ejecutados.
Estos consumidores pueden desear un cierto grado de interactividad tal como desglosar, filtrar,
clasificar, o pueden querer solamente ver un reporte estático.

Los usuarios pueden pasar de una clase a otra a medida que sus habilidades aumentan o cuando realizan
diferentes funciones. Un administrador de la cadena de suministro, por ejemplo, puede querer

.
380 DMBOK2

ver un reporte estático sobre las finanzas, pero también un reporte altamente interactivo para analizar
el inventario. Un analista financiero y un gerente de línea responsable de costos pueden ser usuarios
empoderados al analizar los gastos totales, pero están satisfechos con un reporte estático de una
factura telefónica. Los ejecutivos y los gerentes utilizan una combinación de reportes fijos, tableros
de mando y BSCs (Balance Score Cards - Cuadros de Mando Integral). Los gerentes y los usuarios
empoderados tienden a querer desagregar, dividir y seccionar los datos en estos reportes para
identificar las posibles causas de los problemas. Los clientes externos pueden utilizar cualquiera de
estas herramientas como parte de su experiencia.

2.5.2 Cotejar las Herramientas con los Requerimientos del Usuario

El mercado ofrece una impresionante gama de herramientas de reportería y análisis. Los principales
píxeles
vez fueron el dominio de las aplicaciones de reportería. Muchos proveedores de aplicaciones ofrecen
capacidades analíticas integradas con contenido estándar extraído de cubos poblados previamente o
tablas agregadas. La virtualización ha desdibujado las líneas entre la s fuentes locales de datos y los
datos externos comprados o abiertos, y en algunos casos proporciona integración bajo demanda
controlada por el usuario centrada en reportes. En otras palabras, es prudente que las empresas
utilicen mecanismos comunes de infraestructura y entrega. Estos incluyen la web, correo electrónico y
aplicaciones para la entrega de todo tipo de información y reportes, de los cuales DW / BI es un
subconjunto.

Muchos proveedores ahora combinan herramientas de BI relacionadas, mediante fusiones y

adquisiciones o nuevos desarrollos, y ofrecen Suites de BI. Las suites son la opción principal en el
nivel de Arquitectura Empresarial, pero dado que la mayoría de las organizaciones ya han adquirido
herramientas individuales o han adoptado herramientas de código abierto, es probable que surjan
preguntas acerca del reemplazo versus la coexistencia. Recuerde que cada herramienta de BI tiene un
costo, requerimientos de recursos del sistema, soporte, capacitación e integración arquitectónica.

2.6 Mantenimiento de los Productos de Datos

Un DW implementado y sus herramientas de BI orientadas al cliente son productos de datos. Las mejoras
(extensiones, ampliaciones o modificaciones) a una plataforma de DW existente deben implementarse de
forma incremental.

Mantener el alcance hacia una ruta crítica incremental y en ejecución para elementos de trabajo clave
puede ser un desafío en un entorno de trabajo dinámico. Se deben establecer prioridades con los
socios del negocio y enfocar el trabajo en mejoras obligatorias.

2.6.1 Gestión de Liberaciones

La gestión de liberaciones es fundamental para los procesos de desarrollo incremental que crean nuevas
capacidades, mejoran el despliegue en producción y garantizan el mantenimiento regular de los activos
desplegados. Este proceso mantendrá el DW actualizado, limpio y funcionando en su mejor forma. Sin
embargo, este proceso requiere la misma alineación entre TI y el negocio, así como entre el modelo de DW y
las capacidades de BI. Es un esfuerzo continuo de mejora.

La Figura 83 ilustra un ejemplo de un proceso de liberación, basado en una programación trimestral. A lo

largo del año, hay tres liberaciones impulsadas por el negocio y una liberación basada en tecnología

.
 DA T A WAR EHO U S IN G E I NT E LI GENC IA D E N E GO C I O 38 1

(para atender los requisitos internos del DW). El proceso debe permitir el desarrollo incremental del DW y la
gesti6n del encolamiento de requerimientos.

Figura 83 Ejemplo de Proceso de Liberaci6n

2.6.2 Gestionar el Ciclo de Vida del Desarrollo de Productos de Datos

Mientras que los consumidores de datos están utilizando el DW existente, el equipo de DW se está
preparando para la siguiente iteraci6n, entendiendo que no todos los elementos llegarán a producci6n.
Se deben alinear las iteraciones a las liberaciones con una lista de tareas pendientes priorizada por las
unidades de negocio. Cada iteraci6n extenderá un incremento existente o agregará nueva
funcionalidad al integrar una unidad de negocio. Las liberaciones alinearán la funcionalidad a la
unidad de negocio, mientras que la iteraci6n alineará la funcionalidad a la propia configuraci6n
administrada por el gestor de producto.

Aquellos elementos que el negocio cree que están listos y son factibles de investigaci6n más detallada
pueden ser revisados, ajustados si es necesario, y luego promovidos a piloto o a entorno de pruebas,

.
382 DMBOK2

donde los usuarios del negocio investigan nuevos enfoques, experimentan con nuevas técnicas o
desarrollan nuevos modelos o algoritmos de aprendizaje. En esta área se puede observar menos
gobierno y supervisi6n que otras áreas de negocios, pero alguna forma de priorizaci6n controlada es
necesaria. Al igual que el tradicional sistema de aseguramiento de la calidad o ambiente pruebas, se
deben analizar los elementos en la zona piloto para garantizar que sean adecuados para ambientes
productivos. Qué tan bien funcionan los pilotos determina los pr6ximos pasos. Hay que tener cuidado
de no promocionar productos ciegamente y sin tener en cuenta los problemas de la calidad de datos o
de gobierno. La vida útil en ambientes productivos es s6lo una medida existencial: los productos deben
ser de la más alta calidad práctica para estar en producci6n. Los elementos que pasan el piloto y se
consideran listos para producci6n por parte de representantes del negocio y de TI pueden ser
promovidos a ambientes productivos como nuevos productos de datos. Esto completa una iteraci6n.

Los elementos que no pasan el piloto pueden ser rechazados por completo o devueltos al área de
desarrollo para pequeños ajustes. Tal vez el apoyo adicional del equipo DW sea necesario en este
momento para que el elemento avance a ser promovido en la pr6xima iteraci6n.

2.6.3 Supervisar y Ajustar los Procesos de Carga

Es necesario supervisar el procesamiento de cargas en todo el sistema para controlar cuellos de

botella y dependencias. Emplee técnicas de afinamiento de base de datos cuando sea necesario,
incluyendo particiones, respaldos afinados y estrategias de recuperaci6n. Archivar es una tarea
complicada en data warehousing. Los usuarios consideran a menudo al DW como un archivo activo
debido al largo historial que se construye, y no están dispuestos, particularmente si las fuentes de
procesamiento analitico en linea (OLAP) han eliminado registros, a aceptar que el DW realice
archivado. (Véase el capitulo 6.)

2.6.4 Monitorear y Afinar la Actividad y el Rendimiento de BI

Una buena práctica para el monitoreo y afinamiento de BI es definir y mostrar un conjunto de métricas
de satisfacci6n orientadas al cliente. El tiempo promedio de respuesta a consultas y el número de
usuarios por dia, semana o mes son ejemplos de métricas útiles. Además de las medidas estadisticas
disponibles en los sistemas, es útil encuestar regularmente a los clientes de DW / BI.

La revisi6n regular de las estadisticas y patrones de uso es esencial. Los reportes que proporcionan la
frecuencia y el uso de recursos de datos, consultas y reportes permiten mejoras prudentes. El
afinamiento de la actividad de BI es análogo al principio de perfilar aplicaciones para saber d6nde
están los cuellos de botella y d6nde aplicar esfuerzos de optimizaci6n. La creaci6n de indices y
agregaciones es más efectiva cuando se hace de acuerdo con patrones de uso y estadisticas. Las
enormes ganancias de rendimiento pueden venir de soluciones sencillas como publicar lo s resultados
diarios completados en un reporte que se ejecuta cientos o miles de veces al dia. La transparencia y la
visibilidad son principios fundamentales que deberian impulsar el monitoreo DW / BI. Cuanto más se
puedan exponer los detalles de las actividades de DW / BI, más consumidores de datos podrán ver y
entender lo que está pasando (y tener confianza en el BI), y se requerirá menos soporte directo al
cliente final. Proporcionar un tablero de mando que exponga a alto nivel el estado de las actividad es
de entrega de datos, con capacidades de desglose, es una práctica recomendada que permite la
obtenci6n de informaci6n por parte del personal de soporte y de los clientes.

La adici6n de medidas de calidad de datos mejorará el valor de este tablero donde el rendimiento es más que
solamente velocidad y tiempo. Se recomienda utilizar mapas de calor para visualizar la carga

.
 DA T A WAR EHO U S IN G E IN T E LI GENC IA D E N E GO C I O 38 3

de trabajo en la infraestructura, el caudal de datos y el cumplimiento con los niveles de acuerdo

operativo.

3. Herramientas
La elección del conjunto inicial de herramientas puede ser un proceso largo. Incluye el intento de
satisfacer los requerimientos a corto plazo, las especificaciones no funcionales y los requerimientos
de próxima generación que se van a crear. Los conjuntos de herramientas de criterios de decisión,
herramientas de implementación de procesos y ofertas de servicios profesionales pueden facilitar y
acelerar esta actividad. Es crítico evaluar no sólo las opciones convencionales de construcción o
compra, sino también la opción de alquiler provista como SaaS ( Software as a Service Software
como Servicio). El alquiler de herramientas SaaS y la experiencia asociada se compara con el costo
de construir desde cero o desplegar productos adquiridos de proveedores. Consideremos también la
actualización continua y los posibles costos de reemplazo. La alineación a un conjunto de OLA
(Operational Level Agreement - Acuerdo de Niveles de Operación) puede soportar los costos
previstos y proporcionar información para fijar tarifas y sanciones para las violaciones a término que
sean atractivas.

3.1 Repositorio de Metadatos

Las grandes organizaciones suelen encontrarse con muchas herramientas de diferentes proveedores,
cada una de ellas desplegada potencialmente en versiones diferentes. La clave de este esfuerzo es la
capacidad de unificar Metadatos de una variedad de fuentes. La automatización e integración de la
población de este repositorio se puede lograr con una variedad de técnicas. (Véase el capítulo 13.)

3.1.1 Diccionario de Datos / Glosario

Un diccionario de datos es necesario para apoyar el uso de un DW. El diccionario describe los datos en
términos del negocio e incluye otra información necesaria para usar los datos (por ejemplo, tipos de
datos, detalles de estructura, restricciones de seguridad). A menudo, el contenido del diccionario de
datos proviene directamente del modelo lógico de datos. Es recomendable planificar con el objetivo de
obtener Metadatos de alta calidad asegurando que los modeladores adopten un enfoque disciplinado para
gestionar las definiciones como parte del proceso de modelado.

En algunas organizaciones, los usuarios de negocio participan activamente en el desarrollo del

diccionario de datos suministrando, definiendo y luego corrigiendo las definiciones de los elementos de
datos del área temática. Se debe aprovechar esta actividad a través de una herramienta de colaboración,
monitorear las actividades a través de un Centro de Excelencia y asegurar que el contenido creado a
través de esta actividad se mantenga en el modelo lógico. Garantizar un acuerdo entre el contenido
orientado al negocio y el modelo de datos físico orientado a la técnica, reducirá el riesgo de errores
replicantes y retrabajos. (Véase el capítulo 13.)

3.1.2 Linaje de Datos y del Modelo de Datos

Muchas herramientas de integración de datos ofrecen análisis de linaje que considera tanto el código de carga
desarrollado como el modelo de datos físicos y la base de datos. Algunos ofrecen interfaces

.
384 DMBOK2

web para supervisar y actualizar las definiciones y otros Metadatos. La documentaci6n de linaje sirve para
muchos prop6sitos:
Investigaci6n de las causas de los problemas de datos.
Análisis de impacto para cambios en el sistema o problemas de datos.
Capacidad para determinar la fiabilidad de los datos, en funci6n de su origen

Busque implementar una herramienta integrada de impacto y linaje que pueda comprender todas las
partes m6viles involucradas en el proceso de carga, asi como reportes y analitica para e l usuario final.
Los reportes de análisis de impacto describirán que componentes se ven afectados por un cambio
potencial, agilizando y racionalizando las tareas de estimaci6n y mantenimiento. Muchos procesos,
relaciones y terminologias clave del negocio se capturan y explican durante el desarrollo del modelo
de datos. El modelo de datos l6gico contiene gran parte de esta informaci6n, que a menudo se pierde o
se ignora durante el desarrollo o el despliegue a producci6n. Es fundamental asegurarse de que esta
informaci6n no se descarte y de que los modelos l6gicos y fisicos se actualicen después de la
implementaci6n y estén sincronizados.

3.2 Herramientas de Integración de Datos

Las herramientas de integraci6n de datos se usan para poblar un DW. Además de realizar el trabajo de
integraci6n de datos, permiten la programaci6n de tareas de manera que se cuente con entrega de datos
complejos de múltiples fuentes. Al seleccionar una herramienta, también debe tener en cuenta estas
caracteristicas que permiten la administraci6n del sistema:
Auditoria de procesos, control, reinicio y programaci6n.
La capacidad de extraer selectivamente elementos de datos en tiempo de ejecuci6n y pasar ese
extracto a un sistema federado para prop6sitos de auditoria.
Controlar que operaciones pueden o no pueden ejecutarse y reiniciar una ejecuci6n fallida o
anulada (consulte el Capitulo 8)

Una variedad de herramientas de integraci6n de datos también ofrece capacidades de integraci6n con el
portafolio de BI, soportando la importaci6n y exportaci6n de mensajes de flujo de trabajo, correo
electr6nico o incluso capas semánticas. La integraci6n de flujo de trabajo puede generar procesos de
identificaci6n, resoluci6n y escalamiento de defectos de calidad de datos. La mensajeria a través del
correo electr6nico o el procesamiento de alertas de correo electr6nico es una práctica común,
especialmente para dispositivos m6viles. Además, la capacidad de proporcionar un destino de datos
como una capa semántica puede ser un candidato de virtualizaci6n de datos para implementaciones
ágiles.

3.3 Tipos de Herramientas de BI

La madurez del mercado de BI y una amplia gama de herramientas de BI disponibles hace que sea raro que
las empresas construyan sus propias herramientas de BI67. El prop6sito de esta secci6n es
introducir los tipos de herramientas disponibles en el mercado de BI y proporcionar una visi6n general
de sus caracteristicas principales con informaci6n que ayude a combinar las herramientas con las
capacidades de nivel de cliente adecuadas. Las herramientas de BI están evolucionando rápidamente,

67 ®,
http://bit.ly/2tNirv5; utilizado con permiso, con cambios y aportes menores.

.
 DA T A WAR EHO U S IN G E IN T E LI GENC IA D E N E GO C I O 38 5

lo que permite una transici6n de los reportes estandarizados guiados por TI al autoservicio de reportería y a la
exploraci6n de datos guiada por el negocio68.
Reportería operacional es la aplicaci6n de herramientas de BI para analizar las tendencias de
negocio, tanto a corto plazo (mes a mes) como a largo plazo (año a año). La reportería
operacional también puede ayudar a descubrir tendencias y patrones. se debe utilizar el BI
táctico para apoyar las decisiones empresariales a corto plazo.
BPM (Business Process Management - Gestión del Desempeño Empresarial) incluye la
evaluaci6n formal de las métricas alineadas con las metas de la organizaci6n. Esta evaluaci6n
suele ocurrir a nivel ejecutivo. Se debe utilizar el BI estratégico para apoyar metas y objetivos
corporativos a largo plazo.
La analítica descriptiva y autoservicio proporciona BI a la línea de frente del negocio,
donde las capacidades analíticas orientan las decisiones operativas. La analítica operativa
acopla las aplicaciones de BI con funciones y procesos operativos, para guiar las decisiones
en tiempo casi real. La necesidad de baja latencia (captura y entrega de datos en tiempo casi
real) impulsará el enfoque arquitect6nico de las soluciones analíticas operacionales. SOA
(Service Oriented Architecture - Arquitectura Orientada a Servicios) y Big Data se hacen
necesarios para soportar plenamente el análisis operacional (ver capítulos 8 y 15).

3.3.1 Reportería Operacional

La reportería operacional involucra a que los usuarios de negocio generen reportes directamente
desde sistemas transaccionales, aplicaciones operac ionales o de un DW. Esto es una funcionalidad
típica de una aplicaci6n. A menudo, las áreas de negocio empezarán a usar un DW para la
generaci6n de informes operativos, especialmente si el gobierno de DW / BI es deficiente o si el DW
contiene datos adicionales que mejoran los datos operativos y transaccionales. A menudo, los
reportes aparecen como consultas ad-hoc, cuando de hecho son reportes simples o se utilizan para
iniciar el flujo de trabajo. Desde una perspectiva de gesti6n de datos, la clave es ente nder si los datos
necesarios para este reporte existen dentro de la propia aplicaci6n o si se requiere mejoras de datos
desde el DW o desde el ODS.

Las herramientas de exploraci6n de datos y reportería, a veces llamadas herramientas de consulta ad-
hoc, permiten a los usuarios crear sus propios reportes o crear salidas para su uso por otros. Ellos están
menos preocupados por el diseño preciso porque no están tratando de generar una factura o algo similar.
Sin embargo, quieren incluir gráficos y tablas de forma rápida e intuitiva. A menudo, los reportes
creados por usuarios del negocio se convierten en informes estándar, no utilizados exclusivamente para
preguntas del negocio ad hoc.

Las necesidades dentro de reporte de operaciones del negocio son a menud o diferentes a las
necesidades de consultas y reportes generenciales. Para los reportes gerenciales, el origen de datos
suele ser un DW o data mart (aunque no siempre). Mientras TI desarrolla reportes de producci6n,
los usuarios avanzados y los usuarios del negocio ad hoc desarrollan sus propios informes con
herramientas de consulta gerencial. Se debe utilizar los reportes generados con las herramientas de
consulta empresarial de forma individual, departamental o empresarial. Los reportes de producci6n
cruzan los límites de DW / BI y, a menudo, consultan los sistemas transaccionales para producir

68

http://bit.ly/2sTgXTJ (accesado el 2017-01-22).

.
386 DMBOK2

elementos operativos tales como facturas o estados bancarios. Los desarrolladores de informes de producci6n
tienden a ser personal de TI.

Las herramientas de BI tradicionales cubren bastante bien algunos métodos de visualizaci6n de datos
como tablas, gráficos circulares, gráficos de lineas, gráficos de área, gráficos de barras, histogramas,
candelabros como ejemplos. Las visualizaciones de datos se pueden entregar en un formato estático, tal
como un reporte publicado, o un formato en linea más interactivo; y algunos apoyan la interacci6n del
usuario final donde las capacidades de desglose o filtrado facilitan el análisis de datos dentro de la
visualizaci6n. Otros permiten que la visualizaci6n sea cambiada por el usuario bajo demanda. (Véase el
capitulo 14.)

3.3.2 Gestión del Rendimiento Empresarial

La gesti6n del rendimiento es un conjunto de procesos organizacionales integrados y de aplicaciones

diseñadas para optimizar la ejecuci6n de la estrategia empresarial; sus aplicaciones incluyen la
generaci6n de presupuestos, la planificaci6n y la consolidaci6n financiera. Ha habido varias
adquisiciones importantes en este segmento, ya que los proveedores de ERP (Enterprise Resourse
Planning Planificaci6n de Recursos Empresariales) y los proveedores de BI ven grandes oportunidades
de crecimiento aqui y creen que BI y la gesti6n de rendimiento están convergiendo. La frecuencia con la
que los clientes compran BI y la gesti6n del rendimiento del mismo proveedor depende de las
capacidades del producto.

En términos generales, la tecnologia de gesti6n de rendimiento permite que los procesos ayuden a
cumplir las metas de la organizaci6n. La medici6n y un bucle de realimentaci6n con refuerzo positivo
son elementos clave. Dentro del espacio de BI, esto ha tomado la forma de muchas aplicaciones
empresariales estratégicas, como presupuesto, previsi6n o planificaci6n de recursos. Otra
especializaci6n se ha formado en esta área: crear tablas de puntuaci6n impulsadas por tableros para la
interacci6n del usuario. Los tableros de mando, como los que se encuentran en los auto m6viles,
proporcionan al usuario final la informaci6n resumida o agregada necesaria con las actualizaciones
más recientes (Eckerson, 2005).

3.3.3 Aplicaciones Analíticas Operacionales

Henry Morris de IDC acuñ6 el término Aplicaciones Analiticas en los años noventa, aclarando c6mo
son diferentes de las herramientas OLAP y BI generales (Morris, 1999). Las aplicaciones analiticas
incluyen la l6gica y los procesos para extraer datos de sistemas fuente conocidos, tales como sistemas
ERP de proveedores, un modelo de datos para el data mart y reportes y cuadros de mando
preconstruidos. Proporcionan a las empresas una soluci6n preconstruida para optimizar un área
funcional (gesti6n de personas, por ejemplo) o vertical de la industria (analitica de ventas, por ejemplo).
Los diferentes tipos de aplicaciones analiticas incluyen aplicaciones de clientes, financieras, de cadena
de suministro, de fabricaci6n y de recursos humanos.

3.3.3.1 Análisis Multidimensional - OLAP

OLAP se refiere a un enfoque para proporcionar un rendimiento rápido para consultas analiticas
multidimensionales. El término OLAP se origin6, en parte, para hacer una clara distinci6n de OLTP
(Online Transactional Processing Procesamiento Transaccional en Linea). El resultado tipico de
consultas OLAP está en un formato de matriz. Las dimensiones forman las filas y las columnas de la
matriz, y los factores, o medidas, son los valores dentro de la matriz. Conceptualmente, esto se ilustra

.
 DA T A WAR EHO U S IN G E IN T E LI GENC IA D E N E GO C I O 38 7

como un cubo. El análisis multidimensional con cubos es particularmente útil donde hay analistas con buen
conocimiento que deseen mirar los resúmenes de datos.

Una aplicación tradicional es el análisis financiero, donde los analistas quieren recorrer repetidamente
las jerarquias conocidas para analizar datos; por ejemplo, la fecha (como Año, Trimestre, Mes, Semana,
Dia), organización (como Región, Pais, Unidad de Negocio, Departamento) y jerarquia de productos
(como Categoria de Producto, Linea de Producto, Producto). Hoy en dia, muchas herramientas
incorporan cubos OLAP en su huella de software y algunos incluso automatizan e integran
perfectamente el proceso de definición y población. Esto significa que cualquier usuario en cualquier
proceso de negocio puede seccionar y dividir sus datos. Hay que alinear esta capacidad con los usuarios
avanzados de las comunidades del área temática y distribuirla a lo largo de un canal de autoservicio para
que estos usuarios seleccionados puedan analizar sus datos a su manera.

Normalmente, las herramientas OLAP tienen un componente de servidor y un componente fin al

orientado al cliente instalado en el computador personal o disponible en la Web. Algunos
componentes de escritorio se pueden acceder desde una hoja de cálculo apareciendo como un
elemento de menú o una función incrustados. La arquitectura seleccionada ( ROLAP, MOLAP,
HOLAP) guiará los esfuerzos de desarrollo, pero la definición de la estructura de cubos, las
necesidades agregadas, el aumento de Metadatos y el análisis de la dispersión de datos será común
para todas.

Estructurar el cubo para proporcionar los requisitos funcionales deseados puede requerir dividir
dimensiones mayores en cubos separados para acomodar requisitos de almacenamiento, población o
cálculo. Se recomienda utilizar niveles de agregación para asegurar que el cálculo y la recuperación de
las fórmulas deseadas ocurran dentro de los tiempos de respuesta acordados. El aumento de jerarquias
por parte del usuario final permite cumplir con los requisitos de agregación, cálculo o población.
Además, la escasez de datos de cubos puede requerir la adición o remoción de estructuras agregadas o
refinar las necesidades de materialización en la capa de datos del DW que las proporciona.

Provisionar la seguridad basada en roles o texto multilingüe dentro del cubo puede requerir dimensiones
adicionales, funciones adicionales, cálculos o, a veces, la creación de estructuras cúbicas separadas.
Lograr un equilibrio entre la flexibilidad del usuario final, el rendimiento y las cargas de trabajo del
servidor significa que existirá algún tipo de negociación. La negociación tipicamente ocurre durante los
procesos de carga y puede requerir cambios de jerarquia, cambios de estructura agregados u objetos de
datos adicionales materializados en DW. Hay que obtener el equilibrio adecuado entre el recuento de
cubos, la carga de trabajo del servidor y la flexibilidad entregada, de modo que la actualización se
realice de manera oportuna y los cubos proporcionen consultas fiables y consistentes sin altos costes de
almacenamiento o utilización del servidor.

El valor de las herramientas y cubos OLAP es la reducción de la posibilidad de confusión e

interpretación errónea, alineando el contenido de los datos con el modelo mental del analista. El
analista puede navegar a través de la base de datos y buscar un subconjunto particular de datos,
cambiando la orientación de los datos y definiendo cálculos analiticos. Dividir y seccionar es el
proceso de navegación iniciado por el usuario llamando a la visualización por páginas de forma
interactiva, a través de la especificación de cortes a través de rotaciones y desgloses / consolidaciones.
Las operaciones comunes de OLAP incluyen seccionado y división, desglose, consolidación, cálculo de
subtotales y pivotaje.
Seccionado (Slice): Una sección es un subconjunto de una matriz multidimensional que
corresponde a un valor único para uno o más miembros de las dimensiones que no están en el
subconjunto.

.
388 DMBOK2

División (Dice): La operación de división es un seccionado en más de dos dimensiones de un

cubo de datos, o más de dos secciones consecutivas.
Desglose / Consolidación (Drill down / up): El desglose y la consolidación son técnicas
analíticas específicas mediante las cuales el usuario navega entre los niveles de datos, desde el
más resumido (consolidado) hasta el más detallado (desglosado).
Subtotales (Roll-up): Un subtotal implica el cálculo de todas las relaciones de datos para una
o más dimensiones. Para ello, se debe definir una relación o fórmula computacional.
Pivote: Un pivote cambia la orientación dimensional de un informe o visualización de
página.

Tres métodos clásicos de implementación soportan OLAP.

Procesamiento Analítico Relacional En Línea (ROLAP): ROLAP soporta OLAP mediante
el uso de técnicas que implementan la multidimensionalidad en las tablas bidimensionales de
los sistemas de gestión de bases de datos relacionales (RDBMS). La combinación de
esquemas en estrella son una técnica común de diseño de bases de datos utilizada en
entornos ROLAP.
Procesamiento analítico multidimensional en línea (MOLAP): MOLAP apoya a OLAP
utilizando tecnología de base de datos multidimensional propietaria y especializada.
Procesamiento analítico híbrido en línea (HOLAP): Esto es simplemente una
combinación de ROLAP y MOLAP. Las implementaciones HOLAP permiten que parte de
los datos se almacenen en forma MOLAP y otra parte de los datos que se almacenarán en
ROLAP. Las implementaciones varían en el control que el diseñador tiene para variar la
mezcla de partición.

4. Técnicas

4.1 Prototipos Para Guiar Requerimientos

Se deben priorizar rápidamente los requerimientos antes de comenzar las actividades de

implementación creando un conjunto de datos de muestra y aplicando los pasos de descubrimiento en
un esfuerzo conjunto de prototipo. Los avances en tecnologías de virtua lización de datos pueden
aliviar algunos de los dolores de la implementación tradicionales a través de técnicas colaborativas de
creación de prototipos.

La elaboración de perfiles de los datos contribuye a la creación de prototipos y ayuda a reducir el

riesgo asociado con datos inesperados. El DW es a menudo el primer lugar donde el dolor de la mala
calidad de datos en los sistemas fuente o las funciones de entrada de datos se hace evidente. El
perfilamiento de datos también puede revelar diferencias entre fuentes que pueden presentar
obstáculos a la integración de datos. Los datos pueden ser de alta calidad dentro de sus fuentes, pero
debido a los sistemas fuente, el proceso de integración de datos se vuelve más complicado.

La evaluación del estado de los datos de origen conduce a estimaciones anticipadas más precisas sobre la
viabilidad y el alcance del esfuerzo. La evaluación también es importante para establecer expectativas
apropiadas. Se debe planificar el colaborar con el equipo de calidad de datos y gobierno de datos y
aprovechar la experiencia de otras PYMEs para comprender las discrepancias y los riesgos de los datos.
(Véanse los capítulos 11 y 13.)

.
 DA T A WAR EHO U S IN G E IN T E LI GENC IA D E N E GO C I O 38 9

4.2 Autoservicio de BI

El autoservicio es un canal de entrega fundamental dentro del portafolio de BI. Esto normalmente
canaliza la actividad del usuario dentro de un portal gobernado donde, dependiendo de los privilegios
del usuario, se ofrece una variedad de funcionalidades qu e van desde mensajería, alertas, visualización
de informes de producción programados, interacción con reportes analíticos, desarrollo de reportes ad-
hoc y, por supuesto, tableros de mando y cuadros de mando. Los informes pueden ser enviados al portal
en horarios estandarizados, para ser recuperados por los usuarios a su antojo. Los usuarios también
pueden extraer datos mediante la ejecución de reportes desde el portal. Estos portales comparten
contenido a través de los límites de la organización.

La ampliación de la herramienta de colaboración hacia la comunidad de usuarios también puede

proporcionar consejos y trucos de autoservicio, un comunicado integrado sobre el estado de la carga, el
rendimiento general y el progreso de la liberación, así como foros de diálogo. Se debe mediar el
contenido del foro a través del canal de soporte y luego facilitar con sesiones de grupos de usuarios a
través del canal de mantenimiento.

Apoyarse en herramientas de visualización y análisis estadístico permite la rápida explo ración y

descubrimiento de datos. Algunas herramientas permiten la construcción orientada al negocio de
objetos como tableros de mando que pueden ser rápidamente compartidos, revisados y revitalizados.
En algún momento, solamente parte del dominio de TI y desarrolladores, muchas técnicas de
modelado de datos, cálculo y visualización ahora pueden ser empleados por la comunidad
empresarial. Esto ofrece un grado de distribución de la carga de trabajo y los esfuerzos de integración
pueden ser prototipados de manera factible a través de los canales de negocio y luego materializados y
optimizados por TI.

4.3 Auditar los Datos que Pueden ser Consultados

Con el fin de mantener el linaje, todas las estructuras y procesos deben tener la capacidad de crear y
almacenar información de auditoría en un nivel de granularidad útil para el seguimiento y la
presentación de reportes. Permitir a los usuarios consultar estos datos de auditoría permite a los usuarios
verificar por sí mismos la condición y la llegada de los datos, lo que mejora la confianza del usuario. La
información de auditoría también permite una resolución de problemas más detallada cuando surgen
problemas de datos.

5. Guías de Implementación

Una arquitectura estable que puede adaptarse a las necesidades futuras es fundamental para el éxito de un
DW. Un equipo de apoyo en producción capaz de hacer frente a la carga diaria, el análisis y la
retroalimentación del usuario final es obligatorio. Además, para mantener el éxito, asegúrese de que el DW y
los equipos de la unidad de negocio estén alineados.

5.1 Evaluación de la Preparación / Evaluación del Riesgo

Puede haber una brecha entre cuando una organización abraza una nueva empresa, y cuando tiene la
capacidad de sostener esa empresa. Los proyectos exitosos comienzan con una lista de verificación de

.
390 DMBOK2

requisitos previos. Todos los proyectos de TI deben contar con soporte del negocio, estar alineados con la
estrategia y tener un enfoque arquitectónico definido. Además, un DW debería:
Definir las restricciones de seguridad y sensibilidad de los datos.
Realizar la selección de herramientas.
Asegurar recursos
Crear un proceso de ingesta para evaluar y recibir datos de origen.

Se deben identificar e inventariar elementos de datos sensibles o restringidos en el DW. Estos datos tendrán
que ser enmascarados u ofuscados para impedir el acceso de personal no autorizado. Pueden aplicarse
restricciones adicionales cuando se considera la subcontratación para actividades de implementación o
mantenimiento.

Hay que tener en cuenta las limitaciones de seguridad antes de seleccionar herramientas y asignar recursos.
Se debe asegurar que los procesos de gestión de datos para su revisión y aprobación han sido seguidos. DW
/ BI proyecta riesgo de reenfoque o la cancelación total debido a estos factores globales.

5.2 Hoja de Ruta de Liberación

Debido a que requieren un gran esfuerzo de desarrollo, los DW se construyen de forma incremental.
Cualquier método elegido para implementar, ya sea cascada, iterativo o ágil, debe dar cuenta del
estado final deseado. Es por eso por lo que una hoja de ruta es una valiosa herramienta de
planificación. El método combinado con los procesos de mantenimiento puede ser flexible y adaptable
para equilibrar las presiones de entrega individual del proyecto con metas generales de datos e
infraestructura reutilizables.

Se sugiere un enfoque incremental que aproveche la matriz de bus DW como herramienta de

comunicación y marketing. Se deben utilizar las prioridades determinadas por la empresa atadas por
métricas de exposición para determinar cuanto rigor y gastos generales se aplicarán a cada incremento;
una pequeña entrega de una sola fuente puede permitirse la relajación de la regla, especialmente cuando
se siente una exposición limitada si esas cuestiones son de conocimiento de la organización.

Cada incremento modificará las capacidades existentes o agregará capacidades nuevas típicamente
alineadas con una nueva unidad de negocio integrada. Se debe aplicar un proceso consistente de
necesidades y habilidades para determinar la próxima unidad de negocio a bordo. También es
necesario mantener una lista de artículos de trabajo o de órdenes pendientes para identificar
capacidades excepcionales y las prioridades de negocios. Debemos determinar las dependencias
técnicas que requieran entregas en un orden diferente. A continuación, se debe empaquetar este
trabajo en una versión de software. Cada lanzamiento puede ser entregado a un ritmo acordado:
trimestral, mensual, semanal o incluso más rápido cuando sea apropiado. Gestione las versiones con
los socios de negocios mediante el montaje de una hoja de ruta: una lista de lanzamientos por fecha
por capacidades.

5.3 Gestión de la Configuración

La gestión de la configuración se alinea con la hoja de ruta de la liberación y proporciona el refuerzo

de las oficinas de soporte y las secuencias de comandos necesarias para automatizar el desarrollo, las
pruebas y el transporte hasta producción. También marca el modelo por la liberación a nivel de base
de datos y vincula el código base a esa marca de manera automatizada de modo que los programas

.
 DA T A WAR EHO U S IN G E IN T E LI GENC IA D E N E GO C I O 391

manualmente codificados, generados y el contenido de la capa semántica estén armonizados a través del
ambiente y estén controlados por versiones.

5.4 Organización y Cambio Cultural

Comenzar y mantener un enfoque empresarial consistente a lo largo del ciclo de vida de DW / BI es

esencial para el éxito. Observar la cadena de valor de la empresa es una buena manera de entender el
contexto empresarial. Los procesos de negocio específicos en la cadena de valor de una empresa
proporcionan un contexto natural orientado al negocio en el cual enmarcar áreas de análisis.

Más importante aún es alinear los proyectos detrás de las necesidades reales del negocio y evaluar el soporte
empresarial necesario, considerando estos factores críticos de éxito:
Patrocinio del negocio: ¿Existe patrocinio ejecutivo apropiado, es decir, un comité directivo
identificado y comprometido y financiamiento conmensurado? Los proyectos DW / BI requieren
un fuerte patrocinio ejecutivo.
Objetivos y alcance del negocio: ¿Hay una necesidad de negocio claramente identificada,
prop6sito y alcance para el esfuerzo?
Recursos empresariales: ¿Existe un compromiso por parte de la direcci6n de la empresa con
la disponibilidad y compromiso de los expertos en materia de negocio apropiados? La falta de
compromiso es un punto común de fracaso y una raz6n suficiente para detener un proyecto
DW / BI hasta que el compromiso sea confirmado.
Preparaci6n para el negocio: ¿Está el socio comercial preparado para una entrega
incremental a largo plazo? ¿Se han comprometido a establecer centros de excelencia para
mantener el producto en futuros lanzamientos? ¿Qué tan amplio es el conocimiento
promedio o la brecha de habilidades dentro de la comunidad objetivo y se puede cerrar esta
brecha con un solo incremento?
Alineamiento de la visi6n: ¿Qué tan bien soporta la Estrategia de TI la Visi6n del Negocio? Es
vital asegurarse de que los requerimientos funcionales deseados correspondan a las capacidades
empresariales que se pueden o pueden mantener en la hoja de ruta inmediata de TI. Cualquier
desviaci6n significativa o falta de material en la alineaci6n de capacidad puede interrumpir o
detener un programa DW / BI.

5.4.1 Equipo Dedicado

Muchas organizaciones tienen un equipo dedicado para gestionar las operaciones en curso del entorno de
producci6n. (Véase el capítulo 6). Un conjunto separado de manos que operan el producto de datos
suministrado es beneficioso para la optimizaci6n de la carga de trabajo ya que este grupo tiene tareas
repetitivas en un ciclo calendario y puede utilizarse además para cualquier elemento de escalamiento,
mientras que el canal de mantenimiento verá picos de carga de trabajo alineados con productos
específicos.

Un grupo de apoyo de la oficina central interactúa con el equipo de mantenimiento para fomentar las
relaciones interdepartamentales y asegurar que las actividades críticas se aborden en los pr6ximos
lanzamientos. Se notifica al equipo de cualquier deficiencia a ser abordada. Un equipo de soporte de back-
office en operaciones garantizará que la configuraci6n de producci6n se haya ejecutado de acuerdo con lo
requerido. Ellos escalarán alertas e informarán respecto al estado del rendimiento.

.
392 DMBOK2

6. Gobierno de DW / BI

Las industrias que están altamente reguladas y necesitan reportería enfocada en cumplimiento, se
beneficiarán en gran medida de un DW bien gobernado. De fundamental importancia para el apoyo
continuo y vital para la planificación de la liberación es garantizar que las actividades de gobierno se
completen y se aborden durante la implementación. Cada vez más organizaciones están ampliando su
SDLC (Software Development Life Cycle Ciclo de Vida del Desarrollo de Software) con
entregables específicos dirigidos a satisfacer las necesidades de gobierno. Los procesos de gestión de
DW deben alinearse con la gestión de riesgos. Deben ser impulsados por las empresas, ya que
diferentes tipos de empresas tienen diferentes necesidades (por ejemplo, las empresas de marke ting y
publicidad utilizarán sus datos de forma diferente a las instituciones financieras). Los procesos de
gobierno deben mitigar el riesgo, no restringir la ejecución.

Las funciones más críticas son aquellas que gobiernan el área de descubrimiento o refinamiento operado
por el negocio, y las que garantizan una calidad prístina del propio DW. Dado que el área de
refinamiento determina todos los límites de la iniciativa, acuerdos y procedimientos en ejecución bien
definidos son necesario para instanciar, operar, transferir y descartar los datos en estas áreas. El
archivado de datos y los horizontes enmarcados en el tiempo son elementos clave en los acuerdos que
definen límites ya que ayudan a evitar la expansión descontrolada. La supervisión de estos entorno s y
horarios para determinar los términos de longevidad se incluye en las sesiones de grupos de usuarios, así
como en las reuniones de administración. Cargar los datos en el almacén significa asignar tiempo,
recursos y esfuerzos de programación para que los datos reparados, creíbles y de alta calidad lleguen a
la comunidad de usuarios finales, por supuesto de manera oportuna.

Considere los eventos de un solo uso o de uso limitado como parte del ciclo de vida, y quizás
restringirlos dentro de la zona piloto, o dentro de un área de 'caja de arena' controlada por el usuario.
Los procesos de análisis en tiempo real pueden alimentar los resultados de agregación alineados con el
tiempo en el DW a través de un proceso automatizado. La política se define para los pr ocedimientos
aplicados en el entorno en tiempo real, y el gobierno se aplica a la intermediación de resultados en el
DW para el consumo de la organización.

Se debe aplicar discriminación de datos a los elementos conocidos o catalogados que son gestionados a
través de una matriz de mitigación de la exposición al riesgo. Aquellos artículos considerados de alta
exposición y baja mitigación o difícil detección temprana, garantizan funciones de gobierno para reducir
el riesgo asociado. Dependiendo de la sensibilidad de los datos que se están examinando, también se
puede requerir un espacio de trabajo aislado para el personal local seleccionado. Una revisión
exhaustiva con el área de seguridad corporativa y el personal legal durante la formación de políticas
crea una red de seguridad final.

6.1 Habilitando la Aceptación por Parte del Negocio

Un factor clave de éxito es la aceptación de los datos por parte del negocio, incluyendo que los datos
sean entendibles, tengan calidad verificable y tengan un linaje demostra ble. La aceptación de los datos
por parte del negocio debe ser parte de las Pruebas de Aceptación del Usuario. Se deben realizar
pruebas aleatorias estructuradas de los datos, usando una herramienta de BI, contra datos en los
sistemas fuente relacionados a la carga inicial, y después de algunos ciclos de carga de actualización,
para cumplir con los criterios acordados. Cumplir estos requisitos es primordial para cada

.
 DA T A WAR EHO U S IN G E IN T E LI GENC IA D E N E GO C I O 393

implementación de DW / BI. Consideremos, por adelantado, algunos subcomponentes arquitectónicos de

importancia crítica, junto con sus actividades de apoyo:
Modelo de Datos Conceptual: ¿Qué información es fundamental para la organización?
¿Cuáles son los conceptos clave del negocio y cómo se relacionan entre sí?
Bucle de retroalimentación de calidad de datos: ¿Cómo se identifican y remedian los
problemas de datos? ¿Cómo están siendo informados los propietarios de los sistemas de los
problemas que se originan en estos mismos y como se responsabilizan de su corrección?
¿Cuál es el proceso de remediación de los problemas causados por los procesos de
integración de datos de DW?
Metadatos de principio a fin: ¿Cómo soporta la arquitectura el flujo de Metadatos integrado de
principio a fin? En particular, ¿Está el acceso al significado y al contexto diseñado en la
arquitectura? ¿Cómo responden los consumidores de datos preguntas básicas como "¿Qué
significa este reporte?" ó "¿Qué significa esta métrica?"
Linaje de datos verificable de principio a fin: ¿Los elementos expuestos a los usuarios de
negocio pueden rastrearse a los sistemas de origen de forma automatizada y mantenida? ¿Ha sido
identificado un sistema de registro para todos los datos?

6.2 Satisfacción del Cliente / Usuario

La percepción de la calidad de los datos conducirá a la satisfacción del cliente, pero la satisfacción
también depende de otros factores, como el entendimiento de los datos por parte d e los clientes y la
respuesta del equipo de operaciones a los problemas identificados. La recolección, comprensión y
actuación sobre la retroalimentación de los clientes se puede facilitar a través de reuniones
programadas regularmente con representantes de los usuarios. Dicha interacción también puede
ayudar al equipo de DW a compartir información sobre la hoja de ruta del lanzamiento y entender
como usan los consumidores de datos el DW.

6.3 Acuerdos de Nivel de Servicio

Las expectativas empresariales y técnicas para los ambientes deben especificarse en SLAs (Service Level
Agreement Acuerdo de Niveles de Servicio). A menudo, el tiempo de respuesta, la retención de datos y los
requisitos de disponibilidad difieren mucho entre los tipos de necesidades de negocio y sus respectivos
sistemas de soporte (por ejemplo, ODS versus DW versus Data Mart).

6.4 Estrategia de Reportería

Hay que asegurarse de que exista una estrategia de reportería dentro del portafolio de BI. Una
estrategia de presentación de reportes incluye normas, procesos, directrices, mejores prácticas y
procedimientos. Garantizará que los usuarios tengan información clara, precisa y oportuna. La
estrategia de presentación de informes debe considerar:
Seguridad de acceso para garantizar que sólo los usuarios con derecho accedan a elementos de
datos sensibles.
Mecanismos de acceso para describir como los usuarios desean interactuar, reportar,
examinar o ver sus datos.
Tipos de comunidades de usuario y herramienta apropiada para consumirlas
Resumen de la naturaleza del reporte, detalles, excepciones, así como la frecuencia,
sincronización, distribución y formatos de almacenamiento

.
394 DMBOK2

Potencial uso de capacidades de visualización para proveer salidas gráficas

Balanceo entre puntualidad y rendimiento.

Los reportes estándar deben ser evaluados periódicamente para asegurar que sigan proporcionando
valor, ya que la simple ejecución de los reportes supone un costo de almacenamiento y procesamiento.
Los procesos de implementación y mantenimiento y las actividades de gestión son fundamentales.
Alinear las herramientas de reporteria apropiadas con la comunidad empresarial es un factor critico de
éxito. Dependiendo del tamaño y la naturaleza de la organización, probablemente haya muchas
herramientas de reporteria diferentes utilizadas en una variedad de procesos. Hay que asegurar que la
audiencia sea capaz de hacer el mejor uso de las herramientas de reporteria; los usuarios que son más
sofisticados tendrán demandas cada vez más complejas. Es recomendable mantene r una matriz de
decisión basada en estas demandas para determinar actualizaciones o la selección de herramientas en
el futuro.

La supervisión y el control del gobierno de la fuente de datos son también vitales. Es necesario
asegurarse de que los niveles adecuados de datos sean aprovisionados de forma segura para el
personal autorizado, y que los datos suscritos sean accesibles de acuerdo con los niveles acordados
previamente.

Un centro de excelencia puede proporcionar formación, conjuntos de inicio, mejores prácticas de

diseño, consejos y trucos de la fuente de datos y otras soluciones puntuales o artefactos para empoderar
a los usuarios del negocio para obtener un modelo de autoservicio. Además de la gestión del
conocimiento, este centro puede proporcionar comunicaciones oportunas hacia del desarrollador,
diseñador, analista y comunidades de usuarios suscritas.

6.5 Métricas

6.5.1 Métricas de Uso

Las métricas de uso del DW suelen incluir el número de usuarios registrados, asi como usuarios
conectados o conexiones concurrentes de usuarios. Estas métricas muestran cuántas personas dentro
de la organización están utilizando el DW. Identificar cuántas cuentas de usuario tienen licen cia para
cada herramienta es un gran comienzo, especialmente para los auditores. Sin embargo, cuántos se
conectan realmente con esa herramienta es una mejor métrica, y cuántas consultas (o equivalentes a
una consulta) son enviadas por una comunidad de usuarios por periodo de tiempo es una métrica
técnica aún mejor, especialmente para la planificación de la capacidad. Se deben permitir múltiples
métricas de análisis, como usuarios de auditoria, capacidad de consulta de usuarios generada, y
usuarios consumidores.

6.5.2 Porcentaje de Cobertura de Áreas Temáticas

Los porcentajes de cobertura del área temática miden cuánto del DW (desde la perspectiva de la
topologia de datos) es accesado por cada departamento. También resaltan los datos compartidos entre
los departamentos, y aquellos que no se comparten, pero deberian.

El mapeo de la(s) fuente(s) operativa(s) a los destinos es otra extensión natural, que refuerza y valida
el linaje y Metadatos ya recolectados, y puede proporcionar un análisis de penetración para aquellos
sistemas fuente que están en uso analitico y qué departamentos lo usan. Esto puede ayudar a enfocar

.
 DATA WAREHOUSING E INTELIGENCIA DE NEGOCIO 395

los esfuerzos de ajuste en esas consultas analíticas de alto impacto, al mitigar cualquier cambio en objetos de
origen altamente utilizados.

6.5.3 Métricas de Respuesta y Rendimiento

La mayoría de las herramientas de consulta miden el tiempo de respuesta. Es necesario recuperar métricas de
respuesta o de rendimiento de las herramientas. Estos datos proveerán métricas sobre el número y el tipo de
usuarios.

Se deben obtener los tiempos de los procesos de carga para cada producto de datos en formato bruto.
Éstos también deben expresarse como un porcentaje de soporte esperado: por lo que un Data Mart ,
que se espera sea actualizado diariamente y cargado en una ventana de cuatro horas, cuente con un
100% de soporte cuando se carga en cuatro horas. Hay que aplicar este proceso también a cualquier
extracto generado para procesamiento.

La mayoría de las herramientas conservarán, en un registro o repositorio, registros de consulta,

actualizaci6n de datos y tiempos de extracci6n de datos para los objetos proporcionados a los usuarios.
Se necesita dividir estos datos en objetos programados y ejecutados, y expresarlos como conteos
directos, tanto de intentos como de éxitos. Los objetos o las consultas más populares que ejecutan o
procesan mal, son probablemente requeridas para tomar atenci6n antes de que las métricas de
satisfacci6n disminuyan. Esto puede guiar el análisis de defectos, la planificaci6n de mantenimiento, así
como la planificaci6n de capacidad, en el caso que un grupo de objetos está fallando regularmente. La
remediaci6n puede variar dependiendo de la herramienta, pero a veces la creaci6n o la eliminaci6n de un
índice puede dar lugar a grandes mejoras. (Véase el capítulo 6.)

Un seguimiento natural para ello es la validaci6n y ajuste de los niveles de servicio. Se deben ajustar
elementos que hayan fallado sistemáticamente en la pr6xima versi6n, o en ausencia del financiamiento
necesario, el nivel de soporte debe ser reducido.

7. Trabajos Citados / Recomendados

Adamson, Christopher. Mastering Data Warehouse Aggregates: Solutions for Star Schema Performance. John Wiley and Sons,
2006. Print.
Adelman, Sid and Larissa T. Moss. Data Warehouse Project Management. Addison-Wesley Professional, 2000. Print.
Adelman, Sid, Larissa Moss and Majid Abai. Data Strategy. Addison-Wesley Professional, 2005. Print.
Adelman, Sid, et al. Impossible Data Warehouse Situations: Solutions from the Experts. Addison-Wesley, 2002. Print.
Aggarwal, Charu. Data Mining: The Textbook. Springer, 2015. Print.
Biere, Mike. Business Intelligence for the Enterprise. IBM Press, 2003. Print.
Biere, Mike. The New Era of Enterprise Business Intelligence: Using Analytics to Achieve a Global Competitive Advantage. IBM
Press, 2010. Print. IBM Press.
Brown, Meta S. Data Mining for Dummies. For Dummies, 2014. Print. For Dummies.
Chorianopoulos, Antonios. Effective CRM using Predictive Analytics. Wiley, 2016. Print.

Delmater, Rhonda and Monte Hancock Jr. Data Mining Explained; A Manager's Guide to Customer-Centric Business Intelligence.
Digital Press, 2001. Print.
Dyche, Jill. E-Data: Turning Data Into Information With Data Warehousing. Addison- Wesley, 2000. Print.
Eckerson, Wayne W. Performance Dashboards: Measuring, Monitoring, and Managing Your Business. Wiley, 2005. Print.

.
396 DMBOK2

Han, Jiawei, Micheline Kamber and Jian Pei. Data Mining: Concepts and Techniques. 3rd ed. Morgan Kaufmann, 2011. Print. The
Morgan Kaufmann Ser in Data Management Systems.
Hastie, Trevor, Robert Tibshirani, and Jerome Friedman. The Elements of Statistical Learning: Data Mining, Inference, and
Prediction. 2nd ed. Springer, 2011. Print. Springer Series in Statistics.
Hill, Thomas, and Paul Lewicki. Statistics: Methods and Applications. Statsoft, Inc., 2005. Print.
Howson, Cindi. Successful Business Intelligence: Unlock the Value of BI and Big Data. 2nd ed. Mcgraw-Hill Osborne Media, 2013.
Print.
Imhoff, Claudia, Lisa Loftis, and Jonathan G. Geiger. Building the Customer-Centric Enterprise: Data Warehousing Techniques for
Supporting Customer Relationship Management. John Wiley and Sons, 2001. Print.
Imhoff, Claudia, Nicholas Galemmo, and Jonathan G. Geiger. Mastering Data Warehouse Design: Relational and Dimensional
Techniques. John Wiley and Sons, 2003. Print.
Inmon, W. H., Claudia Imhoff, and Ryan Sousa. The Corporate Information Factory. 2nd ed. John Wiley and Sons, 2000. Print.
Inmon, W.H., and Krish Krishnan. Building the Unstructured Data Warehouse. Technics Publications, LLC., 2011. Print.

Josey, Andrew. TOGAF Version 9.1 Enterprise Edition: An Introduction. The Open Group, 2011. Kindle. Open Group White
Paper.
Kaplan, Robert S and David P. Norton. The Balanced Scorecard: Translating Strategy into Action. Harvard Business Review Press,
1996. Kindle.
Kimball, Ralph, and Margy Ross. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling. 3d ed. Wiley,
2013. Print.
Kimball, Ralph, et al. The Data Warehouse Lifecycle Toolkit. 2nd ed. Wiley, 2008. Print.
Kimball, Ralph. The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning, Conforming, and Delivering
Data. Amazon Digital Services, Inc., 2007. Kindle.
Linoff, Gordon S. and Michael J. A. Berry. Data Mining Techniques: For Marketing, Sales, and Customer Relationship Management.
3rd ed. Wiley, 2011. Print.
Linstedt, Dan. The Official Data Vault Standards Document (Version 1.0) (Data Warehouse Architecture). Amazon Digital
Services, Inc., 2012. Kindle.
Loukides, Mike. What Is Data Science? O'Reilly Media, 2012. Kindle.
Lublinsky, Boris, Kevin T. Smith, and Alexey Yakubovich. Professional Hadoop Solutions. Wrox, 2013. Print.
Malik, Shadan. Enterprise Dashboards: Design and Best Practices for IT. Wiley, 2005. Print.

http://bit.ly/2rRrP4x.
Moss, Larissa T., and Shaku Atre. Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support
Applications. Addison-Wesley Professional, 2003. Print.
Ponniah, Paulraj. Data Warehousing Fundamentals: A Comprehensive Guide for IT Professionals. Wiley-Interscience, 2001. Print.
Provost, Foster and Tom Fawcett. Data Science for Business: What you need to know about data mining and data-analytic
thinking. O'Reilly Media, 2013. Print.
Wiley, 2009. Print.
Russell, Matthew A. Mining the Social Web: Data Mining Facebook, Twitter, LinkedIn, Google+, GitHub, and More. 2nd ed.
O'Reilly Media, 2013. Print.
Silverston, Len, and Paul Agnew. The Data Model Resource Book Volume 3: Universal Patterns for Data Modeling. Wiley, 2008.
Print.
Simon, Alan. Modern Enterprise Business Intelligence and Data Management: A Roadmap for IT Directors, Managers, and
Architects. Morgan Kaufmann, 2014. Print.
Thomsen, Erik. OLAP Solutions: Building Multidimensional Information Systems. 2nd ed. Wiley, 2002. Print.
Vitt, Elizabeth, Michael Luckevich and Stacia Misner. Business Intelligence. Microsoft Press, 2008. Print. Developer Reference.
WAGmob. Big Data and Hadoop. WAGmob, 2013. Kindle.
Wremble, Robert and Christian Koncilia. Data Warehouses and Olap: Concepts, Architectures and Solutions. IGI Global, 2006.
Print.