BussinessIntelligence Teoria Parte 1 PDF

Business
Intelligence con
SQL Server 2016
(Teoría)
INTELIGENCIA DE NEGOCIOS 2
Red de contenidos
DATA WAREHOUSING
INDICADORES
ARQUITECTURA
CONSTRUCCIÓN
ANÁLISIS DE ACCESO AL
REQUERIMIENTO DATA
Y FUENTES WAREHOUSE
METODOLOGÍA
METADATOS
MODELAMIENTO CONSULTAS
Y OLAP MINERIA
DISEÑO DE DATOS
BIG DATA
POBLANDO EL HADOOP
DATA MACHINE
WAREHOUSE
LEARNING
ADMINISTRACIÓNDE DATA WAREHOUSE

DAD
1
FUNDAMENTOS DE BUSINESS
INTELLIGENCE
1.1. INTRODUCCIÓN Y CONCEPTOS
1.1.1. Inteligencia de Negocio
La Inteligencia de Negocios o Business Intelligence (BI) se puede definir como el

proceso de extraer datos de cualquier fuente: archivos o base de datos para
transformarlos en información, de tal manera que ésta apoye a la toma de decisiones
de las empresas. BI provee la información que requiere el usuario de negocio en la
manera como lo desea y en el momento que lo necesite, mejorando enormemente la
efectividad para la toma de decisiones, revelando tendencias de negocio no
perceptibles fácilmente.
Es el proceso de transformación de datos en iformación, haciendo uso de técnicas de

Extracción, Transpormación y Carga (ETL), proporcionando información validada
para una adecuada toma de decisiones.
Figura 2: Transformación de datos
Fuente.- Tomado de http://4.bp.blogspot.com/-
Wo6sMxlVbew/UaVBdrR9FNI/AAAAAAAAAHE/3MOHlmlCR0o/s1600/FIGURA3.jpg
Figura 3: DashBoard
Fuente.- Tomado de
http://2gc.eu/images/made/5cf576e340e572f3/InPhase_typical_dashboard_made_by_a_PA_800_600.png
Existe una gran cantidad de procesos detrás de una arquitectura de Data Warehouse
de una solución BI de suma importancia. Estos comprenden desde procesos de
extracción que estudian y seleccionan los datos fuente adecuado para el data
warehouse hasta proce so de consulta y análisis de datos que despliegan la
información de una form a fácil de interpretar y analizar.
Existen conceptos y terminologías de inteligencia de negocio.
Data Warehouse
Entonces podemos definir que un Data Warehouse es una colección de datos en la

cual, se encuentra integrada la información de la Institución y que es usada como
soporte para el proceso de toma de decisiones gerenciales.
Reunir los elementos de datos apropiados desde diversas fuentes de aplicación en un
ambiente integral centralizado, simplifica el problema de acceso a la información y en
consecuencia, acelera el proceso de análisis, consultas y disminuye el tiempo de
Acceso a la información.
Las aplicaciones para soporte de decisiones basadas en un Data Warehouse, pueden

hacer más práctica y fácil la explotación de datos. De esa forma, podemos obtener una
mayor eficacia en la toma de decisiones, que no se logra cuando se usan sólo los
datos que provienen de las aplicaciones operacionales (que ayudan en la operación de
la empresa en sus operaciones cotidianas) en los que la información se obtiene
realizando procesos independientes y muchas veces complejos.
Un Data Warehouse se crea al extraer datos desde una o más bases de datos de
aplicaciones operacionales. La data extraída es transformada para eliminar
inconsistencias y resumir si es necesario y luego, cargarlas en el Data Warehouse. El
proceso de transformar, crear el detalle de tiempo variante, resumir y combinar los
extractos de datos ayuda a crear el ambiente para el acceso a la información
institucional. Este nuevo enfoque ayuda a las personas individuales, en todos los
niveles de la empresa, a efectuar su toma de decisiones con mayor objetividad.
1.1.2. Necesidades del Negocio insatisfechas por las soluciones

tradicionales
Las empresas actualmente poseen las siguientes necesidades de negocios que no

pueden ser resueltas por los sistemas tradicionales:
✓ Pasan más tiempo recolectando y preparando información que analizándola.

✓ Se frustran al no poder encontrar información que está seguro existe en la
empresa.
✓ Quieren saber que productos fueron más rentables durante un periodo de
tiempo
✓ No saben cual es el patrón de compra de sus clientes dependiendo de las
zonas
✓ Pasan mucho tiempo tratando de hacer que los reportes en Excel luzcan bien.
✓ Han perdido oportunidades de negocios por recibir información retrasada.
✓ No sabe con certeza si sus empleados están alcanzando los objetivos
planeados.
Es decir las empresas empiezan a valorar ya no como registrar la información sino

como recuperarla adecuadamente, ya que han descubierto que siendo esta
información más oportuna y exacta, la empresa se volverá más competitiva. Visto así,
la información corporativa es un activo importante de la empresa que genera valor y la
falta de ella generará pérdidas.
Las organizaciones y sus requerimientos de sistemas de información
Con el fin soportar la gran cantidad de información que maneja una empresa, muchas
de ellas despliegan una gran infraestructura tecnológica que soportan Sistemas de
Información. El crecimiento tecnológico tiene varias etapas que van desde la
integración de sistemas, el crecimiento y la implementación. Las condiciones actuales
de competencia han provocado el que sea necesaria tecnología cada vez más
sofisticadas para responder a las peticiones muy particulares de información. Sistemas
de Procesamiento de Datos (SPD), Sistemas de Manufactura, Administración de
Recursos Empresariales (ERP), Sistemas de Información Ejecutiva (EIS), Sistemas de
Soporte a las Decisiones (DSS), Manejo de Relación con Clientes (CRM), Suministro
de la Cadena de Distribución (SCM) , Sistemas en la nube (CLOUD Computing), etc.,
son algunos de los sistemas que afloran y s e ponen de moda y luego desaparecen
acorde a la evolución de las empresas. Pero algo que no va a desaparecer y es la
necesidad de las empresas de consumir información para atender los distintos
requerimientos del negocio dependiendo de la función que cada empleado desempeñe
en la empresa.
La información que las empresas necesitan
La información se está extendiendo a todo nivel dentro de la organización, áreas

donde la toma de decisiones se basaba en la experiencia o la intuición requieren cada
vez más de soporte basado en información. Si bien es cierto, los niveles operativos y
tácticos siempre han requerido de información para el día a día del negocio, está no ha
estado restringida para su uso. El avance vertiginoso de las tecnologías de la
información ha permitido que la información estratégica sea puesta en las
computadoras de los directivos, este comportamiento se ha generalizado
principalmente motivado no sólo por la facilidad y utilidad de la información compartida
sino por los software de toma de decisiones cada vez más sencillos de usar.
Actualmente, la información es enviada a todos los niveles de la empresa con

diferentes fines (comunicación, control, administración, evaluación, planeamiento,
etc.). Las organizaciones están entendiendo que los niveles directivos tienen una gran
responsabilidad al tomar decisiones, ya que ellas recaen sobre toda la empresa, pero
también existen más empleados que toman decisiones y, a pesar de que éstas no
tienen un impacto global, deben ser también adecuadas y oportunas, pues ciertos
grupos dependen de las mismas. Directores, gerentes, supervisores, jefes,
coordinadores todos aquellos que toman decisiones deben tener suficiente información
para apoyarse en su trabajo diario, el lugar que ocupen en la pirámide organizacional
se vuelve secundario cuando el enfoque es hacia el manejo de procesos y todos los
puestos tienen cierta relación y dependencia entre sí.
De manera general dentro de la organización, los requerimientos de información se

dividen en 3 partes:
Figura 4: Pirámide de Información

Fuente.- Tomado de
http://2.bp.blogspot.com/-_oziKhlNrqs/U9Sa-Co4fyI/AAAAAAAABdA/Qe8sh2RxASA/s1600/SIs.png
1. Información Estratégica
Soporta principalmente las decisiones del primer nivel de la pirámide organizacional,
respondiendo a las preguntas estratégicas de la empresa. Su característica principal
es que no muestra muchos datos y está asociado a la gerencia visual a través de
indicadores que muestran si se están alcanzando los objetivos y metas o no a nivel
global. Ello permitirá saber cómo se encuentra la empresa ahora y poder tomar
decisiones oportunas.
2. Información Táctica
Esta información da soporte al segundo nivel de la pirámide organizacional. Está
relacionada al plano operativo de la estrategia planteando vías posibles para lograr la
estrategia dictada por los ejecutivos y directivos. Esta información corresponde a un
área o departamento específico de la empresa, siendo su alcance departamental y se
asocia a gerencias o subdirecciones.
3. Información Técnico Operacional

Este nivel de información corresponde a la parte operativa de la empresa, compuesta

por los sistemas de entrada masiva de datos y procesamiento transaccional. Soporta
el día a día del negocio y a su s diversas áreas (contabilidad, facturación, almacén,
presupuesto y otros sistemas administrativos). Se asocian a las jefaturas o
coordinaciones operativas o de tercer nivel.
1.1.3. Casos de éxito en Inteligencia de Negocio
WallMart
✓ Pionero en el uso de la información para identificar nuevas
oportunidades de mercado
✓ Uso de datamining masivo, solución basada en Teradata
✓ Caso Clásico: Pañales y Cerveza
Es, sin duda, uno de los ejemplos más clásicos de la llamada Business Intelligence
(BI), utilizado en las escuelas de negocio de todo el mundo para ilustrar cómo el
análisis de los datos de los clientes puede llevar a conclusiones interesantes y
aprovechables en el contexto del denominado Market-Basket Analysis: la correlación
entre los pañales y la cerveza.
Estos dos productos, aparentemente sin ninguna relación, protagonizan esta historia
que los profesores y estudiantes de marketing suelen atribuir a lo que ocurrió en los
hipermercados WalMart, cuando se empezó a utilizar por primera software analítico
para combinar el análisis de los datos de compras de algunas personas obtenidos
gracias a sus tarjetas de fidelización.
Según la historia, se descubrieron una serie de asociaciones, algunas perfectamente

obvias, como que las personas que compraban cereal también compraban leche, o los
que compraban ron, también compraban Coca-Cola, y una completamente
inesperada: pañales y cerveza.
Aparentemente, los clientes masculinos cuando compraban pañales el fin de semana,

tenían además una gran tendencia a adquirir también cerveza. De ahí surgió toda una
amplia gama de teorías psicológicas sobre cómo los hombres, cuando eran enviados
por pañales al supermercado, asociaban la idea con la de obtener alguna recompensa
para ellos, o relacionaban el fin de semana con tomar cerveza y, a pesar de ser ya
padres, realizaban una acción de solteros, que seguramente era aprobada en sus
hogares ya que la diferencia era que estos hombres bebían dentro de su casa.
Como resultado del descubrimiento de esta correlación, según sus estadísticas, el

hipermercado decidió mover la cerveza y ponerla al lado de los pañales, y obtuvieron
gracias a ello un incremento de ventas bastante importante.
NBA
✓ Un resultado interesante fue uno hasta entonces no observado por los
entrenadores de los Knicks de Nueva York. El doble marcaje a un jugador
puede generalmente dar la oportunidad a otro jugador de encestar más
fácilmente.
✓ Mezcla datos de jugadores de baloncesto con imágenes de partidos para
encontrar patrones y apoyar a la generación de estrategias.
✓ “Advanced Scout”, basado en IBM DB2 Universal Database, IBM DB2
Intelligent Miner y Virtual Gold's VirtualMiner
AC MILAN
✓ El sistema, creado por Computer Associates International, es alimentado por
datos de cada jugador, relacionados con su rendimiento, alimentación y
respuesta a estímulos externos, que se obtienen y analizan cada quince días.
✓ Actualmente el sistema permite predecir alguna posible lesión.
✓ El club está ahorrando dinero evitando comprar jugadores que presenten una
alta probabilidad de lesión.
ODYSSEY
✓ Gobierno Español enjuicia a la empresa Odyssey por apoderarse de 18
toneladas de monedas de Oro.
✓ Un espectacular sistema de tratamiento de datos llamado «Data Mining». Su
funcionamiento es sencillo: se introducen en una base de datos todas las
variables imaginables, desde los lugares en los que hay barcos hundidos hasta
las corrientes marinas predominantes, los puntos más habituales de tormentas
o las rutas que probablemente utilizara cada capitán. De todo ese cóctel, se
extrae un modelo que indica, con una fiabilidad impresionante, en qué puntos
exactos hay más probabilidades de hallar un tesoro. A partir de ese momento,
y después de años de paciente estudio, esa computadora proporciona a
Odyssey un detallado y gigantesco mapa del tesoro sin necesidad de
escudriñar todo el fondo del Atlántico o el Mediterráneo.
SUNAT
✓ SAS, el líder en Inteligencia de Negocios, anunció hoy que la SUNAT, ha
logrado una mejor detección de la subvaloración de mercancías en la principal
aduana peruana, al incrementar en 14 puntos porcentuales el éxito en los
hallazgos en el Proceso de Selección de Canales de Control.
✓ SUNAT es la primera entidad tributaria en latinoamérica en emplear con éxito
técnicas de Minería de Datos en la lucha contra el contrabando y la
subvaluación.
✓ Solución sobre plataforma SAS, Oracle, Informix, Java.
1.2. DATA WAREHOUSING

1.2.1. Data Warehouse y Data Mart
Data Mart
Orientado a un departamento dentro de la organización, puede ser implementado
como una solución para problemas inmediatos, no es necesario para construir un Data
Warehouse.
Implementación rápida y sencilla a un menor costo de implementación. Cubre

necesidades específicas del Negocio, respuestas rápidas por el menor volumen de
información y asegura la consistencia de los datos.
El empleo de los Datamarts estará determinado por los que toman decisiones. Por
ejemplo en una empresa el gerente de ventas necesitará analizar la información de su
área, es decir las ventas de la empresa.
Inadvertidamente se puede usar datos no compatibles con otros Datamarts que luego
alarguen el tiempo de unificación.
Si el Data Warehouse es construido primero, se requiere de hardware adicional para

soportarDatamarts individuales.
Data Warehouse
La construcción del Data Warehouse se va haciendo por etapas que normalmente
corresponden a las principales áreas operativas de la empresa. Por ejemplo: Área de
Ventas, Área Financiero Contable, Área de Recursos Humanos, etc. Estas áreas
reciben el nombre de Data Marts.
Los Data Warehouses (Base de Datos OLAP, On-Line Analytical Processing) son
diseñados para cumplir con un conjunto de metas, las cuales son muy diferentes de
los objetivos de un sistema transaccional (OLTP, On-Line Transaction Processing).
Por ejemplo, una meta de los OLTP es maximizar la concurrencia mediante el uso de
locks, dicho objetivo no es pertinente en el diseño de DW donde las operaciones son
sólo de consulta, es decir del tipo SELECT.
Además de las técnicas de diseño, un desarrollador de Data Warehousing debe

focalizarse en entregar un análisis multidimensional y capacidades de reportes ad-hoc
(generación de reportes por parte del usuario experto basados en el conocimiento del
negocio). Para realizar esto, el diseñador necesita conocer los requerimientos del
negocio tan bien como las técnicas de diseño multidimensional.
Sin lugar a dudas, el Data Warehousing es parte integral de lo que algunos autores
definen como la “Era de la Información” ya que posibilita la construcción y
mantenimiento de estructuras destinadas al análisis de los datos, transformando los
datos en información y la información en conocimiento.
Estos nuevos conceptos fueron definidos por los padres del DataWarehouse, Bill
Inmon y Ralph Kimball, cuyas visiones las revisaremos luego.
Hay muchas definiciones de Data Warehouse en la literatura, de las cuales se

presenta, las dos más representativas:
William Inmon:
“El Data Warehouse es una colección de datos,
orientados a un tema, integrados, no volátiles, variantes
en el tiempo, organizados para el apoyo a toma de
Ralph Kimball:
“Un Data Warehouse es una copia de los datos
transaccionales, específicamente diseñada para realizar
Necesidad de un Data Warehouse
Una de claves del éxito de las corporaciones modernas es el acceso a la información

correcta, en el tiempo adecuado, en el lugar correcto y en la forma adecuada.
Es muy común escuchar a los ejecutivos decir las siguientes frases:
✓ “Tenemos montañas de datos en esta compañía, pero no podemos acceder a

ellos”
✓ “Nada enloquece más a un gerente que tener dos personas que le presenten el
mismo resultado de negocio, pero con diferentes cifras”.
✓ “Sólo me interesa ver lo que es importante”.
✓ “Todos sabemos qué datos no están bien”.
Estos problemas se presentan en la mayoría de las empresas, y pueden ser

convertidos en oportunidades y transformados en requerimientos:
El Data Warehouse proporciona acceso a los datos corporativos u organizacionales.
Los datos en el Data Warehouse son consistentes.
El Data Warehouse no contiene solamente datos sino un conjunto de herramientas de

consulta, análisis y presentación de la información.
La calidad de los datos en un Data Warehouse, conducirá a una reingeniería de las

aplicaciones de negocio.
De los datos al conocimiento
Cuando los datos se ponen en un contexto, s e convierten en información, y luego esta

información es sintetizada con la ayuda de la experiencia se llega al conocimiento.
DATO
INFORMACIÓN
CONOCIMIENTO
Componentes Funcionales
Los componentes funcionales que son parte del proceso son la adquisición de datos,
el almacenamiento y el acceso por parte de usuarios finales.
• Adquisición: Consiste en recoger los datos útiles del sistema de producción. Se

debe identificar los datos que sean necesarios para atender los requerimientos de
información, luego planificar las extracciones con el fin de evitar saturación en la
red, o afectar al sistema transaccional de producción.
Los procesos de extracción deben estar sincronizados con la finalidad de

garantizar la integridad de la información. Los problemas que surgen al hacer esta
sincronización pueden ser muy complejos.
Después de extraer los datos del sistema transaccional, estos se deben “preparar”
para adecuarlos a la forma del Data Warehouse. Esta “preparación” incluye la
correspondencia de los formatos, la limpieza, la transformación y la agregación en
muchos casos.
La carga es la última fase de la adquisición de datos, esta fase es particularmente
importante sobre todo si se trata de volúmenes muy grandes.
• Almacenamiento: El componente básico del soporte del almacenamiento es el

DBMS (DataBase Manager System). El DBMS o motor de base de datos debe
tener las características que le permitan responder eficientemente a las exigencias
de las consultas analíticas. Para lograrlo debe contar con diversos recursos como
el paralelismo, la optimización del indexado con la finalidad de acelerar las
consultas agregadas, ordenamientos y agrupaciones.
En relación con los tipos de datos, generalmente, se almacenan en formatos

relacionales; sin embargo, frente a la gran cantidad de datos en forma de
documentos, imágenes, audio y video, los DBMS están evolucionando en el
sentido de permitir la gestión de estos tipos de datos. Esta evolución se ve
reforzada aún más con la llegada de Internet.
• Acceso: El acceso al Data Warehouse se da mediante herramientas o aplicaciones

de tipo Cliente/servidor o herramientas que pueden utilizarse desde el Web. Hay
una gran variedad de herramientas en el mercado y el número de aplicaciones de
acceso que se pueden desarrollar es también muy grande. Sea cual sea el tipo de
herramienta, tendrá que adaptarse a las exigencias del usuario y su manera de
trabajar. En el mundo de la decisión, el análisis es también un proceso iterativo y
los resultados de la consulta actual influyen a menudo en la consulta siguiente.
Esto se puede resumir en la siguiente frase: “Dame lo que te pido y luego podré
decirte lo que realmente quiero“.
Infraestructura
Para hacer frente a las necesidades de Data Warehouse, el papel de la informática es

definir e integrar una arquitectura sobre la que implementará el Data Warehouse.
Se debe considerar dos niveles de infraestructura en un Data Warehouse: la

infraestructura técnica o conjunto de componentes materiales y programas, y la
infraestructura operativa o conjunto de procedimientos y servicios para administrar los
datos, gestionar los usuarios y utilizar el sistema.
Por un lado, la infraestructura técnica se compone de productos que implementan las

tecnologías elegidas, integrados en un conjunto coherente y homogéneo. Por otro lado
la infraestructura operativa se compone de todos los procesos que permiten, a partir
de los datos de producción, crear y gestionar el Data Warehouse.
ARQUITECTURA DE DATA WAREHOUSE
INFRAESTRUCTURA INFRAESTRUCTURA
TÉCNICA OPERATIVA
1.2.2. Tendencias en BI
El universo BI no deja de sorprender con su capacidad para renovarse, adaptarse y

transformarse, consiguiendo satisfacer las necesidades de los usuarios, colmando sus
expectativas, y yendo aún más allá. Las tendencias en Business Intelligence rompen
moldes y apuntan en una dirección que, si bien ya se intuía a comienzos de este año,
no muchos creyeron que fuese posible alcanzar.
Business Intelligence consiste en transformar datos en información, para que esa

información pueda convertirse en conocimiento. La toma de decisiones requiere de un
análisis que ha de apoyarse en datos estructurados, que necesitan haber sido
procesados previamente. El procesado de datos los reúne, los depura, los homologa si
es necesario y los deja listos para ser utilizados.
La forma de llevar a cabo este proceso hoy día puede ser muy diferente, dependiendo
de la madurez tecnológica de la empresa, de su efectividad en la recogida de datos,
de sus capacidades de almacenamiento, etc. Sin embargo, existen unos factores
diferenciales que marcan la línea entre unas organizaciones y otras . Agilidad,
automatización y movilidad serían los pilares fundamentales del BI de última
generación.
Quienes ya conocen seguramente buscan el ir más allá, explotando todas las

posibilidades de su inteligencia de negocio. Las tendencias en BI son:
✓ Movilidad: aplicaciones más especializadas y mayor abanico de usuarios.

Empleados, clientes, proveedores, el círculo se va ampliando para enriquecer la BI.
La Mobile Intelligence es el núcleo alrededor del que orbita todo esta información
que permite realizar análisis más específicos y llevar a cabo tareas más complejas,
independientemente del lugar, el momento o el dispositivo que se vaya a utilizar
para ello.
✓ Mayor velocidad de procesamiento para mejores resultados en el análisis

predictivo: la integración es la palabra. Minimizar los tiempos de respuesta es una
demanda mayoritaria que requiere que toda aplicación de BI englobe desde las
reglas de negocio, hasta las funcionalidades, pasando por el análisis y modelado
de datos.
✓ Los proveedores de soluciones e integradores del mundo BI liderarán el cambio:

Una de las tendencias en BI es el mirar más allá de la funcionalidad y la
arquitectura, colaborando con los usuarios finales al seleccionar una solución y

evaluándola conjuntamente.
✓ La nueva forma de tomar decisiones a la que es posible acceder gracias al nuevo

BI tendrá un gran impacto en la evolución cultural: será el germen del concepto de
software social, que procurará entornos de colaboración donde interactúen las
redes sociales, el BI y las herramientas analíticas.
✓ Los dashboards evolucionan: su expansión apoyada en tecnología puntera, no es

más que una confirmación de que el BI debe estar alineado con los objetivos de
negocio para garantizar el éxito empresarial. El simple acceso a los datos hace
tiempo que dejó de ser suficiente. Hay que buscar soluciones que permitan a los
trabajadores ganar concentración sobre las métricas, dotándoles de proactividad.
La movilidad es un imprescindible en este camino.
✓ El autoservicio es una realidad: tener la capacidad de prescindir del Departamento

de IT, poder acceder a los datos de forma sencilla, visual y rápida es sinónimo de
efectividad. Para ello los usuarios necesitan la herramienta adecuada,
personalizada, completa e interconectada que lo haga posible.
✓ BYOD: las políticas de Bring Your Own Device impulsarán la necesidad de contar
con Mobile Intelligence en las empresas. Para ello, la tecnología ha de apoyar esta
evolución. Entre las tendencias en BI se encuentran las soluciones multiplataforma,
que hacen posible no tener que depender de un dispositivo en concreto, sino poder
contar con esa libertad que redunda en la productividad y los resultados.
✓ Nuevas alternativas en lo concerniente a Big Data tendrán su influencia en el

desarrollo en BI. Las opciones crecen y eso significa que la calidad aumenta y los
costes se reducen. Es el momento de pensar a lo grande. Lo mismo sucede con
las tecnologías In Memory, que se convierten en la corriente principal y lo hacen
pasando por delante de disk based Data Warehouse, analytic appliance o
columnar database.
✓ La nube baja a tierra: el cloud será considerado como una opción más, dejará de
marcar la diferencia como lo había hecho hasta ahora y su uso será
completamente rutinario. La aceptación generalizada por parte de los usuarios,
que han aparcado sus recelos en cuanto a la seguridad de sus datos es el
impulsor principal de este cambio de perspectiva, que exigirá que todas las
soluciones de BI deban estar preparadas para la nube.
✓ La colaboración es una necesidad: su potencial en cuanto a BI consigue que de los

datos se extraiga toda la información posible, lo que desemboca en el mejor
análisis. Prescindir de esta posibilidad ya no es cuestionable y por eso, en 2014, el
BI de todas las empresas ha de permitir a sus usuarios interactuar sin límites de
conectividad, ni geográficos, ni temporales.
✓ El Business Intelligence será mejor. El modo de usar la información para tomar

decisiones se está transformando, prueba de ello es que su orientación es cada
vez más estratégica y su prioridad es el proporcionar una visión única, global y
completa. BI y Mobile Intelligence deben ser una prioridad en entornos
empresariales, ya que son la única forma de alcanzar una ventaja competitiva y
mantenerla en el tiempo, gracias a la mejora del servicio al cliente, al control de
gastos, al impulso de beneficios y a una toma de decisiones más ágil y más
precisa.
1.2.3. OLTP y OLAP
On Line Transacction Processing (OLTP)

El sistema On Line Transaction Processing (OLTP) se encarga de dar soporte a los
procesos diarios de ingreso y mantenimiento de datos y son en tiempo real. De esa
manera, las aplicaciones OLTP sirven para la captura de las transacciones cotidianas
(ventas, compras, control de almacén, cuenta corriente, generación de notas de
crédito, control de la producción, contabilidad, etc.) y es la fuente principal de datos de
las soluciones analíticas. Entre las diferencias principales tenemos que las
aplicaciones
OLTP poseen volatilidad de datos (los datos sólo permanecen en el sistema por un
periodo corto de tiempo) a diferencia de las soluciones analíticas, que requieren de
datos históricos para generar diversas perspectivas de análisis. Otra diferencia es la
actualizaciones frecuente de los datos (la información es modificada muchas veces en
el día), mientras que las aplicaciones analíticas realizan operaciones normalmente, de
sólo lectura.
Características
• Diseño orientado a la transacción
• Volatilidad de los datos
• Soporte limitado a la toma de decisiones
Ejemplos
• Cobranzas
• Sistema de control de asistencia
• Control de almacén
On Line Analytical Processing (OLAP)

OnLine Analytical Processing (OLAP) es un proceso en el que se emplean
herramientas sofisticadas que permiten agilizar el proceso de análisis de información
de la empresa, organizada en perspectivas (dimensiones) y métricas permitiendo
ejecutar análisis complejos de datos en base a los cuales se tomarán las decisiones
del negocio.
OLAP permite a los usuarios una fácil y amigable navegación por la información
obteniendo el nivel de granularidad (detalle) que requiera para la toma de decisiones.
Asimismo, puede generar cálculos adicionales en base a los datos existentes. Los
servicios OLAP proveen múltiples formas y niveles de análisis gracias a que los datos
se encuentran estructurados con esta finalidad. De esta manera, el usuario puede
realizar comparaciones entre periodos anteriores o paralelos, encontrar patrones y
tendencias, aislar un grupo de datos con características específicas para realizar un
análisis más profundo y sobretodo de una manera amigable, rápida y confiable.
Características OLAP
• Es consolidada. La data se centraliza desde diferentes orígenes de datos en un
repositorio central único a la cual tienen accesos los usuarios de toda la
organización.
• Es consistente. Los usuarios deben obtener una única versión de los datos no
importando de qué área provengan las consultas ni el momento en que ellas se
realicen.
• Es orientada al objetivo. Sólo contiene información relevante para la toma de

decisiones, de esta manera la orientación está en cómo se usan los datos y no
como se almacenan.
• Es histórica. Los sistemas OLAP almacenan toda la información histórica de la
empresa permitiendo de esta manera, realizar comparaciones entre periodos
actuales e históricos.
• Es de sólo lectura. El sistema OLAP se diseña y optimizan sólo para realizar
consultas, las operaciones de actualización, borrado, etc. son exclusivos de los
sistemas transaccionales.
• No es atómica. Los sistemas OLAP contienen datos sumarizados que permiten
la velocidad en la consulta.
Figura 4: Cubo OLAP

Fuente.- Tomado de
https://alexberenguerdotcom.files.wordpress.com/2013/12/olap.png
Como se observa en el gráfico superior en un modelo de datos OLAP, la información

es vista como cubos, los cuales consisten de valores cualitativos, atributos
(dimensiones) y valores cuantitativos, métricas (medidas).
Un analista de negocio ve a una consulta analítica en términos de un cierto número de

perspectivas de análisis (dimensiones) tales como productos, cliente, vendedor,
tiempo, regiones, fabricantes, o artículos y desea poder analizar un conjunto de
valores cuantitativos (cantidades, montos, ratios, etc.) de tal manera que usando estos
componentes pueda lograr distintas vistas de una misma consulta.
Ejemplo
Para la cadena de tiendas de alquiler de videos que posee 3 sucursales, el sistema
OLAP le permite presentar información consolidada por cada sucursal, compararla y
tomar decisiones apropiadamente.
TIENDA
Miraflores San Borja Surco
CATEGORIA
Drama 120 100 85
Comedia 250 210 190
Ciencia Ficción 52 25 45
Infantil 90 75 70
Terror 40 20 28
Sin embargo, la tienda de alquiler de videos también desearía ver cómo se desarrollan
las ventas en el tiempo. Para hacer esto, se necesitarían varias hojas de cálculo.
De esta manera, las medidas que deseamos visualizar del negocio se encontrarán
almacenadas en la intersección de las perspectivas de análisis, en sectores llamados
“celdas” del cubo, como se grafica a continuación:
MARZO
FEBRERO
ENERO
DRAMA 110 88 65
COMEDIA 231 142 130
CIENCIA
FICCIÓN 29 20 20
INFANTIL 74 64 35
TERROR 27 17 12
Siguiendo con el ejemplo anterior, con este cubo podemos ahora tomar rebanadas del
mismo para responder preguntas como:
✓ ¿Cuánto se alquila por categoría de video en cada tienda en un mes dado?

Categoría de video por tienda en un mes dado
✓ ¿Qué tiendas han mejorado sus alquileres de video dado a través del tiempo?
Tienda por tiempo de una categoría de video dado
✓ ¿Cuánto se alquila por categoría de video a través del tiempo en una tienda
dada?
Sistemas OLTP vs OLAP

En cuanto a las soluciones transaccionales y las soluciones Data Warehousing
también tenemos diferencias:
✓ Frecuencia de actualización: las soluciones transaccionales se encuentran en
tiempo real, manteniendo la data actualizada. En cambio, las soluciones Data
Warehousing, poseen una periodicidad de carga: diario, semanal, mensual, etc,
pudiendo estar sus datos en tiempo real o cercano al tiempo real.
✓ Estructurado para responder a las transacciones diarias de la empresa y
diseñada para conservar una alta integridad de datos, a diferencia de ello, las
soluciones Data Warehousing están estructurados para proporcionar facilidad y
velocidad en la consulta.
✓ Optimizado para las soluciones transaccionales están optimizados para el
registro diario de las operaciones del negocio. Las soluciones Data
Warehousing están optimizados para la consulta, de tal forma que se dé la
manera más amigable y rápida.
1.2.4. Las visiones de Bill Inmon y Ralph Kimball
Bill Inmon
Bill Inmon es universalmente reconocido con el “Padre del Data Warehouse”. Tiene
más de 26 años de experiencia en el campo de las bases de datos y diseño de Data
Warehouses, ha publicado cerca de 40 libros y más de 350 artículos en las más
importantes revistas especializadas. Su libro más reconocido es “Building
DataWarehouse” Bill Inmon ve la necesidad de transferir la información de los
diferentes OLTP (Sistemas Transaccionales) de las organizaciones a un lugar
centralizado donde los datos puedan ser utilizados para el análisis (sería el CIF o
Corporate Information Factory). Insiste además en que ha de tener las siguientes
características:
• Orientado a temas. Los datos en la base de datos están organizados de manera

que todos los elementos de datos relativos al mismo evento u objeto del mundo
real queden unidos entre sí.
• Integrado. La base de datos contiene los datos de todos los sistemas
operacionales de la organización, y dichos datos deben ser consistentes.
• No volátil. La información no se modifica ni se elimina, una vez almacenado un
dato, éste se convierte en información de sólo lectura, y se mantiene para futuras
consultas.
• Variante en el tiempo. Los cambios producidos en los datos a lo largo del tiempo
quedan registrados para que los informes que se puedan generar reflejen esas
variaciones.
La información ha de estar a los máximos niveles de detalle. Los Dw departamentales

o datamarts son tratados como subconjuntos de este Dw corporativo, que son
construidos para cubrir las necesidades individuales de análisis de cada
departamento, y siempre a partir de este Dw Central (del que también se pueden

construir los ODS (Operational Data Stores ) o similares).
El enfoque Inmon también se referencia normalmente como Top-down. Los datos son
extraídos de los sistemas operacionales por los procesos ETL y cargados en las áreas
de stage, donde son validados y consolidados en el DW corporativo, donde además
existen los llamados metadatos que documentan de una forma clara y precisa el
contenido del DW. Una vez realizado este proceso, los procesos de refresco de los
Data Mart departamentales obtienen la información de él, y con las consiguientes
transformaciones, organizan los datos en las estructuras particulares requeridas por
cada uno de ellos, refrescando su contenido.
Al tener este enfoque global, es más difícil de desarrollar en un proyecto sencillo (pues
estamos intentando abordar el “todo”, a partir del cual luego iremos al “detalle”).
Ralph KimBall
Ralph Kimball fue co-inventor de Xerox Star Workstation, el primer producto comercial
en usar iconos y ventanas. Fue Vice-presidente de Metaphor Computer Systems,
fundador y CEO de Red Brick Systems. Kimball es un referente de la metodología
dimensional para diseñar grandes Data Warehouses, fue el que realmente explotó al
máximo el tema de Data Warehousing.
Actualmente enseña Data Warehousing a diferentes grupos y ayuda a clientes con

técnicas de diseño específicos. Kimball es columnista de la revista Intelligent
Enterprise y tiene relación con Sagent Technology, Inc. Su libro “The Data Warehouse
Tookit” es ampliamente reconocido como un pilar sobre la materia.
Para Ralph Kimball el Data Warehouse es un conglomerado de todos los Data Marts
dentro de una empresa, siendo una copia de los datos transaccionales estructurados
de una forma especial para el análisis, de acuerdo al Modelo Dimensional (no
normalizado), que incluye, las dimensiones de análisis y sus atributos, su organización
jerárquica, así como los diferentes hechos de negocio que se quieren analizar. Por un
lado tenemos tablas para las representar las dimensiones y por otro lado tablas para
los hechos (las facts tables). Los diferentes Data Marts están conectados entre sí por
la llamada bus structure, que contiene los elementos anteriormente citados a través de
las dimensiones conformadas (que permiten que los usuarios puedan realizar querys
conjuntos sobre los diferentes Data Marts, pues este bus contiene los elementos en
común que los comunican). Una dimensión conformada puede ser, por ejemplo, la
dimensión cliente, que incluye todos los atributos o elementos de análisis referentes a
los clientes y que puede ser compartida por diferentes Data Marts (ventas, pedidos,
gestión de cobros, etc).
Este enfoque también se referencia como Bottom-up, pues al final el Datawarehouse

Corporativo no es más que la unión de los diferentes Datamarts, que están
estructurados de una forma común a través de la bus structure. Esta característica le
hace más flexible y sencillo de implementar, pues podemos construir un Data Mart
como primer elemento del sistema de análisis, y luego ir añadiendo otros que
comparten las dimensiones ya definidas o incluyen otras nuevas. En este sistema, los
procesos ETL extraen la información de los sistemas operacionales y los procesan
igualmente en el área stage, realizando posteriormente el llenado de cada uno de los
Data Mart de una forma individual, aunque siempre respetando la estandarización de
las dimensiones (dimensiones conformadas).
1.2.5. Arquitectura Zachman
Introducción a la arquitectura de Zachman
La construcción de un Data Warehouse involucra tres tipos de técnicas. En primer

lugar, las técnicas empresariales relacionadas con la comprensión del significado de
los datos que contiene un Data Warehouse. En segundo lugar las técnicas
relacionadas con la tecnología debido a la necesidad de interactuar con muchas
tecnologías, distribuidores y usuarios finales. Finalmente las técnicas administrativas,
que deben permitir administrar la diversidad de procesos, usuarios, temas de negocio,
y tecnologías.
Para compartir una visión desde distintos puntos de vista, es necesario tener un
diagrama. El mismo permite ver algo complicado y hacerlo inteligible mediante el uso
de analogías que simplifican y ayudan a separar una solución compleja en
componentes pequeños.
Los requerimientos de un Data Warehouse son tan variados y diversos como sus
usuarios. Estos requerimientos se pueden analizar desde la perspectiva de cada
usuario.
Las perspectivas de la arquitectura de Zachman

El diagrama de Zachman es una de las formas más eficaces de visualizar un sistema

desde muchas perspectivas. En una compañía, las personas tienen diferentes roles y,
por lo tanto, tienen diferentes perspectivas dependiendo de sus necesidades y usos de
la información
Hay 5 roles básicos en la creación de un producto:
• Planificador: define parámetros básicos, especifica el alcance.

• El dueño (inversionista): proporciona información sobre el producto y su uso.
• Diseñador: especifica el producto, de manera que se cubran las expectativas
del dueño.
• Constructor: administra el proceso de construcción y ensamblaje.
• Sub-contratista: construye cada componente especificado por el constructor.
Las perspectivas se caracterizan por:

Las dimensiones de la arquitectura de Zachman.

Las dimensiones de la arquitectura de Zachman son una forma abstracta de entender
las necesidades de cada perspectiva.
Se busca dar respuesta a las siguientes preguntas:
Las dimensiones se caracterizan por:
Beneficios de la arquitectura de referencia
La arquitectura de referencia facilita las siguientes tareas:

• Evaluación de las inversiones actuales
• Análisis de los costos y beneficios
• Análisis y administración de riesgos
• Evaluación de distribuidores
• Evaluación de productos y herramientas
• Mantenimiento y mejoramiento
• Planeación y administración de proyectos
• Evaluar la tecnología
• Simulación de proyectos
• Arquitectura y diseño
Los bloques de construcción de la arquitectura de referencia

La arquitectura de referencia divide el Data Warehouse en bloques de construcción y
capas.
• Bloques: se relacionan con la funcionalidad específica del Data Warehouse.
• Capas: representan el ambiente necesario para la implementación de los
bloques.
Una visión de alto nivel de la arquitectura de referencia sería la siguiente:
Los bloques del diagrama de Zachman:
El bloque de fuentes de datos en detalle:
Bloque de construcción del Data Warehouse.
Bloque de construcción de datos derivados:

Bloque de acceso y uso del Data Warehouse:
Las capas en el diagrama de Zachman
La capa de administración de datos

La capa de administración de metadatos
La capa de transporte:
La capa de infraestructura:
La arquitectura de referencia de Zachman para Data Warehouse nos ayuda a analizar

y definir los componentes que deben ser implementados en el Data Warehouse y la
forma en que se debe hacer esta implementación. Es útil también para determinar
cuáles son los incrementos en la construcción del Data Warehouse.
UNIDAD
2
MODELAMIENTO DIMENSIONAL
2.1. DISEÑO DE UN DATAMART
2.1.1. Modelamiento Dimensional
Conceptos preliminares
Los componentes fundamentales de la arquitectura de datos de data warehouse son

los siguientes:
• Área temática
• Modelo conceptual
• Modelo lógico
• Modelo físico
✓ Área temática
Un área temática es una entidad primaria que es importante para la organización. Un

área temática típicamente es un sustantivo, por ejemplo, Cliente, producto, recurso
humano entre otros.
Todo negocio está compuesto de un conjunto de áreas temáticas:

✓ Modelo Conceptual
Representación gráfica y textual del análisis que identifica los datos que necesita una
organización para lograr su misión, sus metas, sus objetivos, funciones y estrategias.
Un modelo de datos identifica entidades y sus relaciones entre ellas, proporcionando
una visión conceptual del negocio.
✓ Modelo lógico
Es el modelo que representa las entidades y su estructura inherente. Además de las

relaciones entre ellas, es independiente de las aplicaciones individuales. Contiene la
implementación de los atributos de las entidades y las reglas de negocio (Diagrama
entidad-relación).
✓ Modelo físico
Es la instancia física del modelo lógico. Está conformado por los estándares de
codificación, tipos de datos, longitudes, constraints, índices, particiones.
¿Qué es un Modelo Dimensional?
El modelo dimensional le permite al usuario ver la data mediante múltiples

dimensiones, por ejemplo, ver las ventas por producto, por tienda, por mes por año. Un
modelo dimensional es un modelo simple que muestra medidas, dimensiones y sus
relaciones y que puede ser presentado al usuario para verificación. La información
deberá ser presentada utilizando etiquetas de negocio que le sean familiares al
usuario final. Este modelo puede ser utilizado para crear un esquema físico.
Un modelo dimensional se crea para dar respuesta a requerimientos de análisis como

el siguiente: “¿Cuáles fueron los 10 productos más vendidos fabricados por la
compañía XYZ basados en las ventas totales por sector para cada trimestre de los dos
últimos años?”.
2.1.2. Componentes de un modelo Dimensional
En el modelamiento Dimensional, los componentes principales son:
✓ Hechos
✓ Dimensiones
Hechos
Los Hechos serían aquéllos datos que nos proporcionan una información cuantitativa
sobre las características del Negocio que queremos analizar. En nuestro caso, los
Hechos serán los datos de la acción (“Precio Apertura”, “Precio Cierre”, “Máximo
Diario”, “Mínimo Diario”, “Volumen”).
Su finalidad es proporcionar información necesaria para la gestión, facilitando el

conocimiento del Negocio o Proceso a modelar, y fundamentar, entre otras, la toma de
decisiones, facilitar los procesos de marketing (ofertas y promociones), fidelizar
clientes, valorar el desempeño de los trabajadores, etc.
Dimensión
Por otra parte, las Dimensiones buscan determinar un contexto para el análisis de los
Hechos. Se trata de grupos homogéneos de elementos, en muchas ocasiones,
jerarquizados. Su papel es promocionar la información contenida en los Hechos.
Las Dimensiones pueden estar jerarquizadas o no. Por ejemplo, los elementos de la
dimensión tiempo son jerarquizables, y se pueden representar en un esquema en
árbol. El primer término es “Año”, siendo sus descendientes “Trimestres”, que a su vez
tienen como descendientes a los “Meses”, éstos a las “Semanas”, etc. En este
contexto, definimos al “Elemento Padre” como el elemento superior en la jerarquía
dado un elemento (“Año es el Elemento Padre de “Trimestres”) y como “Elemento
Hijo” a los elementos inferiores en la jerarquía dado un elemento (“Meses es el
Elemento Hijo de Semanas”).
La relación entre los Hechos y las Dimensiones tiene en cuenta la “Granularidad”.
Definimos la “Granularidad” como el menor grado de detalle de nuestro análisis. Otra

forma de definirlo es cómo el menor nivel al que existe relación entre los Dimensiones
y el conjunto de Hechos. Por lo tanto, los Hechos son explicables a partir de datos en
un entorno día-sociedad. A partir de aquí, podemos realizar “Roll Up”, que no es más
que ir agregando los valores en función de los elementos-Padre, y así sucesivamente
hasta llegar al Elemento superior de la jerarquía. El proceso inverso, basado en
desagregar en función de los elementos-Hijo, se conoce como “Drill Down”, y busca

permitir al analista de la información, una forma de ver más detalle los datos.
2.1.3. Surrogate Key y Nivel de granularidad
Surrogate Key
En el ejemplo del Dimensión Producto, el campo Producto_Key es la clave primaria de

la tabla de dimensión. Una buena práctica es establecer un tipo de dato entero y auto
generado para las claves de las tablas de dimensión, pues esto incrementará la
velocidad de las consultas (si se efectúan directamente sobre el modelo STAR) o de
los procesamientos de información (si las consultas se efectúan a través de un cubo).
Este tipo de llave conoce como surrogada o artificial.
El campo IDProducto sirve para conocer el identificador del producto en su sistema de

origen (recuérdese que la información del Data Mart puede tener múltiples orígenes).
Este campo será útil durante la escritura de los procesos de población del Data Mart.
Nivel de Granularidad
La granularidad representa el nivel de detalle al que se desea almacenar la

información sobre el negocio que se esté analizando. Por ejemplo, los datos referentes
a ventas o compras realizadas por una empresa, pueden registrarse día a día, en
cambio, los datos pertinentes a pagos de sueldos o cuotas de socios, podrán
almacenarse a nivel de mes.
Mientras mayor sea el nivel de detalle de los datos, se tendrán mayores posibilidades
analíticas, ya que los mismos podrán ser resumidos o sumarizados. Es decir, los datos
que posean granularidad fina (nivel de detalle) podrán ser resumidos hasta obtener
una granularidad media o gruesa. No sucede lo mismo en sentido contrario, ya que por
ejemplo, los datos almacenados con granularidad media podrán resumirse, pero no
tendrán la facultad de ser analizados a nivel de detalle. O sea, si la granularidad con
que se guardan los registros es a nivel de día, estos datos podrán sumarizarse por
semana, mes, semestre y año, en cambio, si estos registros se almacenan a nivel de
mes, podrán sumarizarse por semestre y año, pero no lo podrán hacer por día y
semana.
2.1.4. Tipos de Modelo Dimensional
El modelo dimensional es una adaptación especializada del modelo relacional usada

para almacenar datos en depósitos de datos, de modo que los datos fácilmente
puedan ser extraídos usando consultas OLAP. En el modelo dimensional, una base
de datos consiste en una sola tabla grande de datos que son descritos usando
dimensiones y medidas. Existen 02 tipos de esquemas:
Modelo Star
El modelo estrella (Star Schema) está compuesto de una tabla central llamada tabla
de Hechos (Fact Table) y de una o varias tablas periféricas llamadas Tabla de
Dimensiones (Dimensional Table).
Obsérvese el diagrama superior. Este modelo consta de cinco tablas de dimensión:

Employee, Product, Customer, Shipper y Time, circundando a una tabla de hechos
llamada Sales_Fact.
Cada registro de la tabla Sales_Fact representa un hecho de ventas. Sus cinco
primeros campos constituyen la clave primaria, y provienen de su relación con cada
una de las tablas de dimensión. Las columnas restantes representan las medidas
relacionadas con las ventas. A partir de este modelo, es fácil comprender que las
métricas de ventas (almacenadas en Sales_Fact) se computan por producto,
empleado, cliente, proveedor y tiempo (almacenados en las tablas de dimensión).
Modelo Snowflake
En el modelo STAR, cada nivel es representado por una columna en la tabla de

dimensión. En el modelo SNOWFLAKE, cada nivel está representado por una tabla.
Por tanto, en este modelo una dimensión puede estar formada por varias tablas.
La siguiente tabla modela la entidad PRODUCTO, en un modelo STAR típico:
En un modelo SNOWFLAKE, esta tabla se “dividiría” en cuatro:
La siguiente tabla muestra una comparación de diversas características de los

modelos STAR y SNOWFLAKE:
En un modelo STAR, la performance de las consultas y del procesamiento del Data

Mart mejora considerablemente debido a que el número de uniones necesarias para

obtener los datos es menor. En cambio, el modelo SNOWFLAKE, debido al alto
número de tablas que produce, tiene un tiempo de procesamiento y respuesta más
alto.
Por otro lado, un modelo STAR es bastante más sencillo que un modelo
SNOWFLAKE. El modelo SNOWFLAKE es más difícil de entender, y sus procesos de
carga de datos son más complejos.
2.1.5. Documentación de los elementos de Diseño
Para el modelamiento dimensional se tienen documentos que nos permiten tener un

mejor y más claro concepto del modelo final.
Así tenemos:
- El Diagrama Star Net

- Matriz Dimensión – Proceso de Negocio
- Modelo de Datos
Diagrama Star Net.-
Es un diagrama que nos muestra a través de líneas, círculos y rectángulos la

representación de un modelo dimensional.
El rectángulo representa los hechos (medidas), los círculos mayores son las
dimensiones, los círculos pequeños corresponden a los atributos de las dimensiones y
las líneas permiten la relación entre estos elementos:
Matriz Dimensión - Proceso de Negocio (Bus Matrix).-
Es un diagrama de matriz que permite identificar que dimensiones intervienen en que

proceso de negocio o hecho.
Modelo Dimensional.-
Es un modelo desnormalizado basado en dos entidades: Tablas Dimensionales (tablas

periféricas) y Tablas de Hecho (tabla central), que en el siguiente punto aprenderemos
más a detalle.
2.1.6. Resolución de casos
Caso de Diseño – Tarjetas de Crédito

Enunciado:
El área de tarjetas de crédito de un banco desea implementar un DataMart. Se desea

visualizar la información de créditos concedidos y pagos hasta llegar a cada tarjeta.
Las tarjetas pueden ser de dos tipos: “VISA” y “MASTERCARD”. También se desea
visualizar los créditos y pagos por cada vendedor y cada cliente. Cada cliente
pertenece a un distrito, cada distrito a una provincia y cada provincia a un
departamento. Cada vendedor pertenece a una agencia, y cada agencia pertenece a
un distrito, cada distrito a una provincia y cada provincia a un departamento. Las
métricas deben visualizarse como totalizados anuales, semestrales, trimestrales y
mensuales. Diseñe las dimensiones, las medidas y el modelo de datos.
Solución:
El primer paso en la construcción de un Data Mart es la definición de las medidas. Del

enunciado del problema, puede deducirse que existen dos medidas en este Data Mart:
créditos concedidos y pagos.
A continuación, se deben establecer las dimensiones del Data Mart. Se desea

visualizar la información por cliente y vendedor. Esto sugiere la existencia de dos
dimensiones: Cliente y Vendedor. Para cada dimensión, se deben establecer los
niveles. Cada cliente está en un distrito, cada distrito en una provincia y cada provincia
en un departamento.
Por tanto, la dimensión Cliente tiene los siguientes niveles:
- Dimensión Cliente
. Departamento
.. Provincia
… Distrito
…. Nombre cliente
Obsérvese el uso de la notación de puntos para representar a los niveles. El nivel más
superior se representa por un punto al lado izquierdo, el nivel siguiente por dos puntos,
y así sucesivamente.
Respecto de la dimensión Vendedor, se sabe que cada vendedor está en una agencia,
cada agencia en un distrito, cada distrito en una provincia y cada provincia en un
departamento. Por tanto, los niveles de la dimensión Vendedor son:
- Dimensión Vendedor
. Departamento
.. Provincia
… Distrito
…. Agencia
….. Nombre Vendedor
Por otro lado, las tarjetas de crédito pueden ser de dos tipos: “VISA” y
“MASTERCARD”.
Esto sugiere la existencia de la dimensión Tipo Tarjeta, con un solo nivel.

- Dimensión Tipo Tarjeta
. Tipo Tarjeta
.. Nro. Tarjeta
Por último, las medidas deben visualizarse como totalizados anuales, semestrales,
trimestrales y mensuales. Por lo general, todo data mart tiene una dimensión que
representa las escalas temporales. En este caso, existe una dimensión llamada
Tiempo, que tiene la siguiente estructura:
- Dimensión Tiempo
. Año
.. Semestre
… Trimestre
…. Mes
2.2. TALLER DE MODELADO DIMENSIONAL

2.2.1. Identificando Medidas
Measures (medidas): Son valores cuantitativos que almacenan las métricas del
negocio. Están representados por columnas numéricas en la fact table.
Ejemplo:
- Cantidad Vendida
- Monto Vendido
- Impuestos
- Gasto
- Costo
Es la parte cuantitativa de los reportes y la pregunta que nos permite identificarla es

¿Cuánto?
2.2.2. Identificando Dimensiones y sus tipos
Dimensión:
Es una entidad de negocios respecto de la cual se deben calcular las métricas.

Ejemplos: clientes, productos, tiempo, vendedor, tienda, ubigeo, etc.
Es la parte atribuible de una solución de Business Intelligence, es la parte cualitativa

(características) de los reportes.
Generalmente provienen de las tablas maestras de los sistemas transaccionales.

Las dimensiones están compuestas de dos partes: Atributos y Jerarquías, y en
cantidad de registros son las tablas más pequeñas.
Las preguntas que nos permiten identificarlas son: ¿Quién?, ¿Qué?, ¿Cuándo?,
¿Dónde? ¿A quién?
Son las áreas temáticas, líneas del negocio o sujetos del negocio.
Las mismas proveen un método general para organizar la información corporativa
Definidas como un grupo de uno o más atributos, separados y distintos uno de otros
(es decir, que no se comparten atributos).
Dentro de cada dimensión se puede definir los niveles de agregación o sumarización

para cada análisis, a estos niveles de granularidad se los caracteriza con el nombre de
atributos.
Ejemplo:
Analizamos las ventas:
Por Tienda
Por Vendedor
Por Producto
Por Semana
Por Departamento
Por Marca
Por Mes
Por Territorio de Ventas
Por País
Ejemplo:
Dimensión Tiempo
Dimensión Producto
Tipos de Dimensiones:
Las tablas de dimensiones se construyen incluyendo todos los atributos que la

incluyen de una forma des normalizada.
Existen diversas variantes al momento de diseñar las dimensiones:
Dimensiones normales o regulares (Planas)

Dimensiones Roll-up
Dimensiones Role-Playing
Dimensiones Degeneradas
✓ Regular Dimensión:
Un foreign key existe entre la tabla de Hecho y la tabla dimensional.
TIEMPO_DIM TARJETA_FACT CLIENTE_DIM

Tiempo_Key Tiempo_Key Cliente_Key
Año Cliente_Key IdCliente
Semestre Vendedor_Key Departamento
Trimestre TipoTarjeta_Key Provincia
Mes creditos_concedido Distrito
pagos NombreCliente
✓ Dimensiones Roll-up
Es una dimensión que es un subconjunto de otra, necesarias para el caso en que

tenemos tablas de hechos con diferente granularidad
MES_DIM DIA_DIM
Mes_Key Dia_Key
Nombre_Mes dia
Año Mes_Key
CUOTAVENDEDOR_FACT VENTADIARIA_FACT
Mes_Key Dia_Key
Vendedor_Key Vendedor_Key
Cuota_MontoVenta Cliente_Key
Producto_Key
Cuota_MontoVenta
✓ Role-Playing Dimensión:
Una dimension puede ser usada múltiples veces sobre el mismo cubo/measure group.
Se ve dos dimensiones distintas:
TiempoVencimiento
TiempoPago
TIEMPO_DIM TARJETA_FACT
Tiempo_Key Tiempo_Key_Vencimiento
Año Tiempo_Key_Pago
Semestre Cliente_Key
Trimestre Vendedor_Key
Mes TipoTarjeta_Key
creditos_concedido
pagos
✓ Fact-Dimensión o Dimensión degenerada
Es una dimensión basada sobre un atributo de una tabla de hechos, tambien es

conocida como dimensión degenerada.
El término Dimensión Degenerada, hace referencia a un campo que será utilizado

como criterio de análisis y que es almacenado en la tabla de hechos.
Esto sucede cuando un campo que se utilizará como criterio de análisis posee el
mismo nivel de granularidad que los datos de la tabla de hechos, y que por lo tanto no
se pueden realizar agrupaciones o sumarizaciones a través de este campo. Los
"números de orden", "números de ticket", "números de transacción", etc, son algunos
ejemplos de dimensiones degeneradas.
La inclusión de estos campos en las tablas de hechos, se lleva a cabo para reducir la
duplicación y simplificar las consultas.
VENTADIARIA_FACT
Nro_Factura
Tiempo_Key_Envio
Tiempo_Key_Pago
Vendedor_Key
Cliente_Key
Producto_Key
Unidades_Vendida
Monto_Vendido
✓ Many to many Dimensión
Utiliza un grupo de medidas intermedia.
Siempre que sea posible, se debe evitar mantener en el DW tablas de dimensiones

con relaciones muchos a muchos entre ellas, ya que esta situación puede, entre otros
inconvenientes, provocar la pérdida de la capacidad analítica de la información y
conducir a una sumarización incorrecta de los datos.
Para explicar esta problemática, se tomará como ejemplo la relación existente entre
ríos y provincias, es decir: Una provincia tiene uno o más ríos, y un río pertenece a
una o más provincias. Además, se tomará como referencia las siguientes tablas
pertenecientes a un OLTP, que contienen básicamente los datos relacionados a ríos y
provincias:
RIO_DIM RECORRIDO_DIM PROVINCIA_DIM

Rio_Key Reccorrido_Key Provincia_Key
IdRio Rio_Key IdProvincia
NomRio Provincia_Key NombreProvicncia
2.2.3. Diseñando Niveles de Granularidad
Atributos.-.
Son las características del negocio. Un grupo de atributos crean una Dimensión.
Ejemplo: Dimensión: Tiempo Atributos: Año, Semestre, Trimestre, Mes.
Jerarquías.-.
Es la distribución de los atributos en niveles.
Ejemplo:
✓ Jerarquía Ubicación:
Departamento
Provincia
Distrito
✓ Jerarquía Calendario:
Año
Trimestre
Distrito
Niveles.-.
Es una forma de organizar los atributos de una dimensión. Los niveles permiten
realizar la técnica BI llamada Drill Down / Drill UP.
Ejemplo:
✓ Jerarquía Ubicación:
Departamento Nivel 1
Provincia Nivel 2
Distrito Nivel 3
2.2.4. Resolución de Caso Práctico
Caso Pinacoteca:
El instituto Nacional de Cultura desea analizar la siguiente información:
✓ La cantidad de cuadros que se encuentran en las pinacotecas (museo)

peruanas.
✓ El número de visitas y el monto recaudado en cada museo por tipo de entrada.
Un tipo de entrada es la forma de pago que realiza la persona (Universitario,
Escolar, Adulto, AdultoMayor). Además, es necesario detallar lo anterior por la
frecuencia de días, semanas, mes y año.
✓ Se desea conocer en cuantas pinacotecas ha estado un cuadro determinado y
cuánto tiempo ha permanecido en la pinacoteca.
De cada pinacoteca se desea analizar su nombre, ciudad en la que se encuentra y el

área en metros cuadrados que tiene.
De los cuadros se quiere analizar su nombre, medidas, fecha en la que fue pintado y
técnica usada para pintarlo. Cada cuadro es pintado por un determinado pintor
(nombre, país, ciudad, fecha de nacimiento y fecha de fallecimiento). Un pintor pueden
pertenecer o no a una escuela.
Los pintores pueden tener también uno o varios mecenas que los protegen (nombre,
país, ciudad de nacimiento, fecha de nacimiento y muerte). Asimismo, se desea
conocer la fecha en que se inicia y termina el mecenazgo con cada pintor). A su vez
un mismo mecenas puede serlo de varios pintores. Mecenas es la persona que apoya
económicamente al pintor para realizar su trabajo.
Solución:
Identificando Medidas:
▪ Cantidad de cuadros
▪ Tiempo de permanencia
▪ Número de visitas
▪ Monto recaudado
Identificando Dimensiones:
▪ Cuadro
▪ Pintor
▪ Pinacoteca
▪ Mecenas
▪ Tiempo
▪ Escuela
▪ Tipo de Entrada
CUADRO PINTOR PINACOTECA MECENAS TIEMPO ESCUELA TIPO ENTRADA

Cantidad de
X X
Cuadros
Número de
X X X
Visitas
Monto
X X X
Recaudado
Número de
X X X
Días
Duración de
X X X
Mecenazgo

BussinessIntelligence Teoria Parte 1 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BussinessIntelligence Teoria Parte 1 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Business

ADMINISTRACIÓNDE DATA WAREHOUSE

La Inteligencia de Negocios o Business Intelligence (BI) se puede definir como el

Es el proceso de transformación de datos en iformación, haciendo uso de técnicas de

Existen conceptos y terminologías de inteligencia de negocio.

Entonces podemos definir que un Data Warehouse es una colección de datos en la

Las aplicaciones para soporte de decisiones basadas en un Data Warehouse, pueden

1.1.2. Necesidades del Negocio insatisfechas por las soluciones

Las empresas actualmente poseen las siguientes necesidades de negocios que no

✓ Pasan más tiempo recolectando y preparando información que analizándola.

Es decir las empresas empiezan a valorar ya no como registrar la información sino

La información que las empresas necesitan

La información se está extendiendo a todo nivel dentro de la organización, áreas

Actualmente, la información es enviada a todos los niveles de la empresa con

De manera general dentro de la organización, los requerimientos de información se

Figura 4: Pirámide de Información

3. Información Técnico Operacional

Este nivel de información corresponde a la parte operativa de la empresa, compuesta

1.1.3. Casos de éxito en Inteligencia de Negocio

Según la historia, se descubrieron una serie de asociaciones, algunas perfectamente

Aparentemente, los clientes masculinos cuando compraban pañales el fin de semana,

Como resultado del descubrimiento de esta correlación, según sus estadísticas, el

1.2. DATA WAREHOUSING

Implementación rápida y sencilla a un menor costo de implementación. Cubre

Si el Data Warehouse es construido primero, se requiere de hardware adicional para

Además de las técnicas de diseño, un desarrollador de Data Warehousing debe

Hay muchas definiciones de Data Warehouse en la literatura, de las cuales se

Necesidad de un Data Warehouse

Una de claves del éxito de las corporaciones modernas es el acceso a la información

Es muy común escuchar a los ejecutivos decir las siguientes frases:

✓ “Tenemos montañas de datos en esta compañía, pero no podemos acceder a

✓ “Sólo me interesa ver lo que es importante”.

✓ “Todos sabemos qué datos no están bien”.

Estos problemas se presentan en la mayoría de las empresas, y pueden ser

El Data Warehouse proporciona acceso a los datos corporativos u organizacionales.

Los datos en el Data Warehouse son consistentes.

El Data Warehouse no contiene solamente datos sino un conjunto de herramientas de

La calidad de los datos en un Data Warehouse, conducirá a una reingeniería de las

De los datos al conocimiento

Cuando los datos se ponen en un contexto, s e convierten en información, y luego esta

• Adquisición: Consiste en recoger los datos útiles del sistema de producción. Se

Los procesos de extracción deben estar sincronizados con la finalidad de

• Almacenamiento: El componente básico del soporte del almacenamiento es el

En relación con los tipos de datos, generalmente, se almacenan en formatos

• Acceso: El acceso al Data Warehouse se da mediante herramientas o aplicaciones

Para hacer frente a las necesidades de Data Warehouse, el papel de la informática es

Se debe considerar dos niveles de infraestructura en un Data Warehouse: la

Por un lado, la infraestructura técnica se compone de productos que implementan las

ARQUITECTURA DE DATA WAREHOUSE

El universo BI no deja de sorprender con su capacidad para renovarse, adaptarse y

Business Intelligence consiste en transformar datos en información, para que esa

Quienes ya conocen seguramente buscan el ir más allá, explotando todas las

✓ Movilidad: aplicaciones más especializadas y mayor abanico de usuarios.

✓ Mayor velocidad de procesamiento para mejores resultados en el análisis

✓ Los proveedores de soluciones e integradores del mundo BI liderarán el cambio:

arquitectura, colaborando con los usuarios finales al seleccionar una solución y

✓ La nueva forma de tomar decisiones a la que es posible acceder gracias al nuevo

✓ Los dashboards evolucionan: su expansión apoyada en tecnología puntera, no es

✓ El autoservicio es una realidad: tener la capacidad de prescindir del Departamento

✓ Nuevas alternativas en lo concerniente a Big Data tendrán su influencia en el

✓ La colaboración es una necesidad: su potencial en cuanto a BI consigue que de los

✓ El Business Intelligence será mejor. El modo de usar la información para tomar

1.2.3. OLTP y OLAP