Manual Teoría Inteligencia de Negocios

Inteligencia

de

Negocios (Teoría)

Índice

Presentación 5

Red de contenidos 7

Unidad de Aprendizaje 1

FUNDAMENTOS DE BUSINESS INTELLIGENCE 9

1.1 Tema 1 : Introducción y conceptos 10

1.1.1 : Inteligencia de Negocios 10 1.1.2 1.1.3 1.1.4 1.2 Tema 2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 : : : : : : : : : : Necesidades de negocio Historia y evolución de BI

Casos de éxito de Inteligencia de Negocios Data Warehousing

Data Warehouse y Data Mart Tendencias en BI

OLTP y OLAP

Las Visiones de Bill Inmon y Ralph Kimball Arquitectura de Zachman 12 14 16 18 18 21 23 26 28 Unidad de Aprendizaje 2 MODELAMIENTO DIMENSIONAL 35

2.1 Tema 3 : Diseño de DataMart 36

2.1.1 : Modelamiento Dimensional 36

2.1.2 : Componentes de un modelo dimensional 38

2.1.3 : Surrogate Key – Nivel de Granularidad 38

2.1.4 2.1.5 2.1.6 : : :

Tipos de modelo dimensional

Documentación de los elementos de diseño Resolución de casos

39 42 43

2.2 Tema 4 : Taller de Modelado Dimensional 45

2.2.1 : Identificando medidas 45

2.2.2 : Identificando dimensiones y sus tipos 45

2.2.3 2.2.4

: :

Diseñando niveles de granularidad Resolución de casos

49 49

Unidad de Aprendizaje 3

ETL y METODOLOGÍA DE RALPH KIMBALL 53

3.1 Tema 5 : ETL 54

3.1.1 : Concepto 54

3.1.2 : Etapas de un proceso ETL 55

3.1.3 : Opciones para implementar procesos ETL 63

3.2 Tema 6 : Metodología 63

3.2.1 : Introducción a la metodología de Ralph Kimball 63 3.2.2 : Identificación de las fases de la metodología RK 64 3.2.3

3.2.4

: :

Etapas de un proceso de Data Mart y Data Warehouse Actividades y entregables

66 71

3.3 Tema 7 3.3.1

: :

Taller

Desarrollo de un caso aplicando metodología RK

74 74

Unidad de Aprendizaje 4

BIG DATA, HADOOP, MACHINE LEARNING, DATA MINING 79

4.1 Tema 8 : Big Data 80

4.1.1 : Definición y su rol en el mundo empresarial 80 4.1.2 : Fases de desarrollo de una estrategía Big Data 83 4.1.3 : Gobernabilidad para la gestión de volúmenes de datos 86

4.2 Tema 9 : Hadoop 92 4.2.1 : Introducción a Hadoop 92 4.2.2 : Arquitectura 93 4.2.3 : Administración Hadoop 96 4.2.4 : Componentes Hadoop 99

4.3 Tema 10 : Machine Learning 103

4.3.1 : Concepto 103

4.3.2 : Escenarios de Negocio que utilicen ML 104

4.3.3 : Tipos de aprendizaje 107

4.3.4 : Algoritmos básicos 108

4.4 Tema 11 : Data Mining 115

4.4.1 : Concepto 115 4.4.2 : Proceso 118 4.4.3 : Normas 118 4.4.4 4.4.5 : : Usos Análisis ForeCasting 119 122

4.5 Tema 12 : Semana Integradora 122

4.4.1 : El futuro de la Inteligencia de Negocios 122 4.4.1.1 : Tendencias tecnológicas y Redes Sociales 124 4.4.1.2 : La Web como repositorio de información 131

Presentación

En un mundo donde las Tecnologías de Información determinan la forma en que se hacen los negocios, las empresas necesitan explotar su mayor recurso: la información. Este análisis permitirá que se realicen análisis de tendencias y se obtengan parámetros que permita optimizar la toma de decisiones, tales como crear estrategias de negocio, fusión de empresas, nuevas giros en el negocio, expansiones, etc.

El presente manual tiene por objetivo brindar a los alumnos los conceptos básicos para el curso de Inteligencia de Negocios.

El manual esta desarrollado para complementar y afianzar lo expuesto en clase, con ejemplos y ejercicios prácticos se busca la comprensión de los temas.

El tema central del curso, Datawarehouse es abordado desde sus conceptos básicos, arquitectura, modelamiento dimensional, en la cual se incide de manera precisa y detallada, transformación de datos, MDX y minería de datos.

Red de contenidos

ADMINISTRACIÓN DE DATA WAREHOUSE

M E T O D O L O G ÍA M E T A D A T O S

FUNDAMENTOS DE BUSINESS

INTELLIGENCE

L

Al término de la unidad, el alumno identifica los conceptos fundamentales

relacionados a soluciones de Inteligencia de Negocios.

T

1.1 Tema 1 : Introducción y conceptos 1.1.1 : Inteligencia de Negocios 1.1.2 1.1.3 1.1.4 1.2 Tema 2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 : : : : : : : : : : Necesidades de negocio Historia y evolución de BI

Casos de éxito de Inteligencia de Negocios Data Warehousing

Data Warehouse y Data Mart Tendencias en BI

OLTP y OLAP

Las Visiones de Bill Inmon y Ralph Kimball Arquitectura de Zachman

A

 Los alumnos reconocen las necesidades de un negocio.

 Los alumnos discuten sobre diversos escenarios de negocio

 Los alumnos identifican Data Warehouse y Datat Mart.

UNIDAD

1

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.

Figura 1: Ciclo de datos

Fuente.- Tomado de https://sqlservermasbi.files.wordpress.com/2012/08/bi_png.png

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.

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 proceso de consulta y análisis de datos que despliegan la información de una forma fácil de interpretar y analizar.

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 se 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.

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 sus 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. Historia y evolución de los conceptos de Inteligencia de Negocios

El concepto de Business Intelligence no es un concepto reciente, hace miles de años los mayas, incas, fenicios, persas, egipcios y otros pueblos practicaban este principio cuando usaban información obtenida de la naturaleza en beneficio propio. Observar y analizar el comportamiento de los astros, las mareas, los períodos de sequía y de lluvias, entre otras, eran maneras de obtener información que luego usaban para tomar decisiones que pudieran permitir mejoras en la vida de sus respectivos pueblos. El mundo ha evolucionado pero, el concepto sigue siendo el mismo. La necesidad de relacionar informaciones para realizar una gestión empresarial eficaz y eficiente es hoy una realidad tanto como en el pasado lo fue descubrir si la crecida de la marea sea propicia para obtener una pesca más abundante.

En los años 60’s surgen las tarjetas perforadas como medio de almacenamiento de datos, los transistores como un gran avance electrónico en la arquitectura de computadores y el lenguaje estructurado de programación COBOL. En esta época, los ordenadores se mostraban como algo difícil de conocer y el almacenamiento de información se realizaba de manera lineal y secuencial. Este nuevo despliegue tecnológico, es decir, la implementación de las bases de datos para el procesamiento en línea, las nuevas tecnologías y los Lenguajes de Cuarta Generación (4GL), permitieron al usuario la facilitarle el control de los sistemas y de la información. Esto dio origen a los primeros Sistemas de Información formales.

Los Dispositivos de Almacenamiento de Acceso Directo (DASD, Direct Access Storage Device), surgen en los 70’s permitiendo que la velocidad de acceso a los datos se mejore enormemente, ya que las búsquedas ya no eran lineales, sino directas. Asimismo, también aparecen los Sistemas de Administración de Bases de Datos (DBMS) que permitía al desarrollador el acceso a la información al encargarse del almacenamiento e índices.

A inicios del año 1990, las más importantes empresas ya contaban con grandes Centros de Información (CI) que funcionaban como repositorio de datos, brindando información poco disponible. A pesar de esta limitante, los CI otorgaban de cierta manera, la información que los ejecutivos requerían para tomar decisiones. Pero a medida que los años avanzaron, el mercado empezó a comportarse de un modo más complejo y cambiante, lo que obligó a que la tecnología de la información comenzara perfeccionando las herramientas de soporte a las decisiones de tal manera que ofrezcan informaciones precisas y en el momento adecuado para poder definir acciones mejorando el desempeño de la organización.

El concepto de Data Warehouse nace entre los años 1992 y 1993, este concepto se asocia a una gran base de datos, es decir, un "recipiente - depósito" único de datos (los cuales pasaron por un proceso de extracción, transformación). Éste repositorio es la parte fundamental para la ejecución práctica de un proyecto de Business Intelligence. Pero al hablar de Business Intelligence, encontramos varios puntos de vista. Para algunos autores es muy importante que la empresa que desea implementar herramientas de Business Intelligence cuente con un "repositorio" único para reunir los datos ya transformados en informaciones. Este "repositorio" no necesariamente es, un

Data Warehouse, puede ser algo más pequeño y menos complejo como, por ejemplo, un Data Mart (banco de datos diseñado para áreas específicas en forma personalizada), o un banco de datos relacional común, pero independiente de ambiente transaccional (operacional) y exclusivo para contener información que será usada como base para la realización de diversos análisis y proyecciones.

El término de Business Intelligence es bastante antiguo. Sin embargo, el avance de la tecnología de la información permitió crear herramientas que facilitó en gran medida todo el proceso de extracción, almacenamiento, consolidación, filtrado, validación y disponibilidad de los datos. Gracias a ello, las empresas empezaron a interesarse en las soluciones de BI de una forma más decisiva, esto a finales de 1996, cuando el concepto se difundió como un proceso de evolución del Executive Information Systems (EIS) - un sistema creado a finales de la década del 70 en el MIT (Massachusets Institute of Tecnology-EUA).

El término Business Intelligence se extendió hacia otras herramientas como por ejemplo:

Executive Information System - Sistema de Información Ejecutiva (EIS), soluciones Decision Support System - Sistema de Soporte a las Decisiones (DSS), Balanced Scorecard (Indicadores de Gestión), Dashboard (Cuadros de Mando), ER (Reporteadores Empresariales), Data Marts, Data Mining, Herramientas OLAP, cuyo fin principal es dinamizar la capacidad de tomar decisiones, afinar estrategias de relaciones con los clientes y satisfacer las necesidades del sector empresarial.

Como pueden darse cuenta, hay mucha similitud entre la red de datos y la red eléctrica. La diferencia fundamental radica en la magnitud de energía que cada red maneja.

1.1.4. 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.

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:

Ralph Kimball:

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, se 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

“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

“Un Data Warehouse es una copia de los datos transaccionales, específicamente diseñada para realizar consultas y análisis.”

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.

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 DE DATA WAREHOUSE

INFRAESTRUCTURA

TÉCNICA

INFRAESTRUCTURA

OPERATIVA

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, la 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.

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:

Miraflores San Borja Surco Drama 120 100 85 Comedia 250 210 190 Ciencia Ficción 52 25 45 Infantil 90 75 70 Terror 40 20 28 TIENDA C A T EG O R IA DRAMA COMEDIA CIENCIA FICCIÓN INFANTIL TERROR 110 88 65 231 142 130 29 20 20 74 64 35 27 17 12 ENERO FEBRERO M ARZO

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 de datos derivados:

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 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.

Resumen

1. Inteligencia de negocios es obtener conocimiento a partir de datos propios de la empresa para la toma de decisiones.

2. Existe 03 tipos de informaciones dentro de un negocio: a. Información Estratégica

b. Información Táctica. c. Información Operacional

3. Desde tiempos antiguos se empleaba la información obtenida (experiencias) para tomar la decisión de ciertas tareas en el campo.

4. En la construcción de un proyecto cualquiera, cada persona tiene una perspectiva distinta definida por el rol que desempeña.

5. Las dimensiones de la arquitectura de Zachman, nos ayudan a entender las necesidades de cada perspectiva

6. La arquitectura de regencia de Zachman, específica para Data Warehouse, está compuesta de bloques y capas. Los bloques están relacionados al proceso de DataWarehousing y las capas son el soporte a este proceso.

7. La arquitectura de referencia de Zachman es un instrumento fundamental en el análisis, pues permite identificar en detalle todos los componentes del Data Warehouse.

8. Una arquitectura es necesaria porque nos dice el orden en el que se deben hacer las cosas y porque da a todos una visión de lo que será un sistema de información, gracias a que muestra un patrón reconocido universalmente.

9. En la construcción de un proyecto cualquiera, cada persona tiene una perspectiva distinta definida por el rol que desempeña

Pueden revisar los siguientes enlaces para ampliar los conceptos vistos en esta unidad:

o https://www.youtube.com/watch?v=OODib6aGmOk o https://www.youtube.com/watch?v=9maeZ9slKwE o https://www.youtube.com/watch?v=z5bIX75nkfg o https://www.youtube.com/watch?v=tDtkyMfT-F8

MODELAMIENTO DIMENSIONAL

L

Al término de la unidad, el alumno diseña soluciones de datamart en base a los

requerimientos de negocio utilizando modelamiento dimensional.

T

2.1 Tema 3 : Diseño de DataMart

2.1.1 : Modelamiento Dimensional. ¿Qué es un modelo Dimensional? 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 : : : : :

Componentes de un modelo Dimensional Surrogate Key y nivel de granularidad Tipos de modelo Dimensional

Documentación de los elementos de diseño Resolución de casos

2.2 Tema 4 : Taller de Modelamientos Dimensional 2.2.1 : Identificando Medidas 2.2.2 2.2.3 2.2.4 : : :

Identificando dimensiones y sus tipos Diseñando niveles de granularidad Resolución de casos prácticos

A

 Los alumnos identifican el Modelo Dimensional y sus tipos.

 Los alumnos identifican los componentes del Modelo Dimensional.

 Los alumnos resuelven casos de casos prácticos de Modelamiento

Dimensional.

UNIDAD

2

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.

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