Bi Tecnico

código Mm050 MANUAL INTELIGENCIA de NEGOCIOS, DataMining - Data WareHouse - Cubos OLAP

Copyright © 2012 [Instituto Gala] Reservados todos los derechos. 1

Inteligencia de Negocios

DataMining – DataWareHouse y Cubos Olap



Índice Definición ....................................................................................................................................... 4

Historia ........................................................................................................................................... 5

Características .............................................................................................................................. 5

Niveles de realización de BI ........................................................................................................ 6

......................................................................................................................................................... 7

Inteligencia de Empresas ............................................................................................................ 7

Proceso ........................................................................................................................................ 17

Protocolo de un proyecto de minería de datos ...................................................................... 18

Negocios de Data Mining ...................................................................................................... 24

Comportamiento en Internet ................................................................................................. 26

Terrorismo ............................................................................................................................... 26

Juegos ...................................................................................................................................... 26

Ciencia e Ingeniería ............................................................................................................... 27

Minería de datos y otras disciplinas análogas ....................................................................... 28

De la estadística ..................................................................................................................... 28

De la informática ..................................................................................................................... 29

Minería de datos basada en teoría de la información ........................................................... 30

Tendencias .................................................................................................................................. 31

Herramientas de software ......................................................................................................... 32

Data Mart ......................................................................................................................................... 45

Dependencia de un data mart .................................................................................................. 46

Conceptos erróneos de los Data Marts .................................................................................. 47

DATA WAREHOUSE VS. DATA MART ............................................................................. 47

Definición de ETL ....................................................................................................................... 55

Proceso de Extracción con Software ETL .............................................................................. 55

Proceso de Transformación con una Herramienta ETL ....................................................... 56

Proceso de Carga con Software de ETL ................................................................................ 58

Procesamiento en Herramientas ETL ..................................................................................... 58

Desafíos para los procesos y Herramientas de ETL ............................................................ 59



Algunas Herramientas ETL ................................................................................................... 60

Desafíos ....................................................................................................................................... 60

Cubo OLAP ..................................................................................................................................... 62

Un ejemplo ................................................................................................................................... 63

Dimensiones y jerarquías .......................................................................................................... 64

Dispersión en cubos OLAP ....................................................................................................... 64

Acceso y cálculo de un cubo OLAP ........................................................................................ 65

Definición técnica ....................................................................................................................... 65

Funcionalidad .............................................................................................................................. 67

Tipos de sistemas OLAP ........................................................................................................... 67

ROLAP ..................................................................................................................................... 67

MOLAP ..................................................................................................................................... 68

HOLAP (Hybrid OLAP) .......................................................................................................... 68

Comparación ........................................................................................................................... 68

Otros tipos ............................................................................................................................... 69

Pasos para extraer información del cubo OLAP en Analysis Services y SQL Server Business Intelligence Development Studio ............................................................................ 80

Creando una Dimensión de tiempo en SQL Server Analysis Services ......................... 86



Business Intelligence

Desafortunadamente, este término no tiene nada que ver con el índice de inteligencia medio de las personas que trabajan en un determinado negocio. De hecho, (BI) tiene que ver con los datos y aplicaciones de un negocio para entenderse mejor.

Semejante a la inteligencia militar, que procura entender al enemigo, la inteligencia de negocio versa sobre todo alrededor de si mismo.

Específicamente, los sistemas de la inteligencia de negocio se basan en crear modelos informáticos de negocio de modo que pueda funcionar más eficientemente.

El almacenamiento de los datos está en la base de los procesos de la inteligencia de negocio. En el mundo de ETL (Extract – Transform – Load) , la inteligencia de negocio se refiere generalmente al espacio entero de los sistemas de la base de datos, del software, del análisis, y de la evaluación del usuario que pretende entender y evaluar un negocio.

Definición

El término inteligencia empresarial se refiere al uso de datos en una empresa para facilitar la toma de decisiones. Abarca la comprensión del funcionamiento actual de la empresa, bien como la anticipación de acontecimientos futuros, con el objetivo de ofrecer conocimientos para respaldar las decisiones empresariales.

Las herramientas de inteligencia se basan en la utilización de un sistema de información de inteligencia que se forma con distintos datos extraídos de los datos de producción, con información relacionada con la empresa o sus ámbitos y con datos económicos.

Mediante las herramientas y técnicas ELT (extraer, cargar y transformar), o actualmente ETL (extraer, transformar y cargar) se extraen los datos de distintas fuentes, se depuran y preparan (homogeneización de los datos) para luego cargarlos en un almacén de datos.

La vida o el periodo de éxito de un software de inteligencia de negocios dependerá únicamente del éxito de su uso en beneficio de la empresa; si esta empresa es capaz de incrementar su nivel financiero, administrativo y sus decisiones mejoran la actuación de la empresa, el software de inteligencia de negocios seguirá



presente mucho tiempo, en caso contrario será sustituido por otro que aporte mejores y más precisos resultados.

Por último, las herramientas de inteligencia analítica posibilitan el modelado de las representaciones basadas en consultas para crear un cuadro de mando integral que sirve de base para la presentación de informes.

Historia

En un artículo de 1958, el investigador de IBM Hans Peter Luhn utiliza el término Inteligencia de Negocio. Se define la inteligencia como: " La capacidad de comprender las interrelaciones de los hechos presentados en tal forma como para orientar la acción hacia una meta deseada".

La inteligencia de negocios, tal como se entiende, hoy en día se dice que ha evolucionado desde los sistemas de apoyo a las decisiones que se inició en la década de 1960 y desarrollado a lo largo de mediados de los años 80. DSS se originó en los modelos por computadora, creado para ayudar en la toma de decisiones y la planificación. Desde DSS, data warehouses, sistemas de información ejecutiva, OLAP e inteligencia de negocios entraron en principio centrándose a finales de los años 80.

En 1989, Howard Dresner (más tarde, un analista de Gartner Group) propuso la "inteligencia de negocios" como un término general para describir "los conceptos y métodos para mejorar la toma de decisiones empresariales mediante el uso de sistemas basados en hechos de apoyo". No fue hasta finales de 1990 que este uso estaba muy extendido.

Características

Este conjunto de herramientas y metodologías tienen en común las siguientes características:

Accesibilidad a la información. Los datos son la fuente principal de este concepto. Lo primero que deben garantizar este tipo de herramientas y técnicas será el acceso de los usuarios a los datos con independencia de la procedencia de estos.

Apoyo en la toma de decisiones. Se busca ir más allá en la presentación de la información, de manera que los usuarios tengan acceso a herramientas de análisis que les permitan seleccionar y manipular sólo aquellos datos que les interesen.



Orientación al usuario final. Se busca independencia entre los conocimientos técnicos de los usuarios y su capacidad para utilizar estas herramientas.

Niveles de realización de BI

De acuerdo a su nivel de complejidad se pueden clasificar las soluciones de Business Intelligence en:

Reportes

Reportes predefinidos

Reportes a la medida

Consultas ("Query") / Cubos OLAP (On-Line Analytic Processing).

Alertas

Análisis

Análisis estadístico

Pronósticos ("Forecasting")

Modelado Predictivo o Minería de datos ("Data Mining")

Optimización

Minería de Procesos



Inteligencia de Empresas

La Inteligencia de Empresas es el concepto más amplio del uso de la inteligencia en las organizaciones. Desde distintas perspectivas, la inteligencia de empresas ha ido emergiendo a partir de la contribución de muchas áreas del conocimiento: market intelligence (inteligencia de mercados), competitive intelligence (Inteligencia Competitiva), business intelligence (inteligencia empresarial).

Este concepto ha sido muy utilizado en el mundo de la tecnología con distintos significados como inteligencia de negocios, strategic foresight (Inteligencia Estratégica), corporate intelligence (Inteligencia Corporativa), vigilancia tecnológica, prospectiva tecnológica, etc.

Hay generalmente unos o más usos analíticos del software (por ejemplo, Business Objects, Cognos, o Microstrategy ).



Los sistemas del BI se diferencian de sistemas operacionales en que están optimizados para preguntar y divulgar sobre datos.

Esto significa típicamente que, en un Datawarehouse, los datos están desnormalizados para apoyar preguntas de alto rendimiento, mientras que los sistemas operacionales generalmente se normalizan completamente para apoyar integridad de referencia y para insertar datos continuamente.

Los procesos de ETL que cargan sistemas del BI tienen que traducir del sistema operacional normalizado a desnormalizado.

Y, típicamente, tienen fallos severos de funcionamiento debido a que no deben degradar el funcionamiento de los sistemas operacionales, y no deben prohibir el acceso al almacén.

Por eso surge el Business Intelligence, basado en nuevas estructuras de análisis, básicamente multidimensional, en contraste con el relacional.

¿Cómo elegir una aplicación Business Intelligence?

Lo primero que se puede decir es que tenemos que identificar cuales son las necesidades y el tipo de herramienta que se busca: análisis, reporting, base de datos, OLAP, etc...

Los principales factores (sin orden de importancia) a tener en cuenta cuando elegimos una herramienta Business Intelligence:

La Plataforma: No es lo mismo estar atados a Microsoft, o poder trabajar en Unix, o tener una estrategia Open Source Linux. Lo mismo aplica al hardware. Algunos fabricantes son restrictivos.

El Curriculum del vendedor: Es muy útil conocer el tipo de implementaciones que se han hecho, si se han realizado en tiempo, si se utilizan, la satisfacción de usuarios, etc...

El tamaño del cubo: Es imprescindible hacer un análisis previo de la amplitud de la información a almacenar. Algunas aplicaciones pueden 'explotar' llegado cierto nivel.

La velocidad de consulta: Los usuarios siempre quieren velocidad en sus consultas. Y si 20 segundos de espera es mucho, quizás haya que buscar otra herramienta.

Servicios de soporte y ayuda a nivel mundial: Tenemos que tener la seguridad de que si algo falla en la aplicación ( y fallará, esto es seguro) podamos resolverla en el menor tiempo posible.



Evaluaciones de analistas: Gartner, IDC saben de que hablan... y suelen ser objetivos. No está de más fijarse en sus 'cuadrantes'.

El ecosistema del vendedor (consultores, partners, acuerdos, comunidad de desarrolladores…).

Base instalada de usuarios. Si hay de mi sector mucho mejor. Si puedo hablar con ellos y ver la herramienta en vivo, todavía mejor.

Graphical User Interface (GUI). Hay que recordar que hablamos de una herramienta para usuarios finales y si a éstos no les gusta, no la utilizarán y será dinero tirado.

El precio: No tiene por qué ser lo más importante..... pero... es importante!!!

Integración con otras herramientas: Ninguna herramienta funciona como una isla aislada del resto. Lo mismo que una empresa, si creas islas, crearás incomunicación.

¿Por qué fallan muchos proyectos Business Intelligence?

A veces nos sorprende que con el desarrollo al que han llegado muchas herramientas, el uso de metodologías contrastadas y el mayor nivel desconocimiento de técnicos y usuarios, se produzcan tantos desastres en la implementación de soluciones Business Intelligence, en términos de exceso de coste sobre el previsto, no utilización por parte de los usuarios, no cumplir con las expectativas, información errónea, etc...

En base a la experiencia estos son algunos de los principales fallos:

Muchos Data Warehouses crecen en tamaño de forma desproporcionada porque los técnicos no consiguen decir 'no' a las 'excesivas' demandas de los usuarios.

Se prefiere realizar el proyecto con gente de la propia empresa, cuando éstos no tienen ni tiempo, ni conocimientos para poder abarcarlo.

Se fijan unas fechas de entrada en producción del sistema poco realistas, que provoca nuevas fechas y más retrasos.

El presupuesto destinado para el proyecto es escaso en comparación con el grado de complejidad que se quiere desarrollar.

La selección del software y hardware a veces se realiza siguiendo criterios de acuerdos generales o compromisos, antes que puramente técnicos.

Antes del proyecto, no se realizan benchmarks o 'pruebas de concepto' para determinar la viabilidad.



Los datos de origen no están limpios. Duplicidades, errores, caracteres erróneos.. implican un proceso ETL más costoso, mayor tamaño de la Base de datos y peor rendimiento.

El sponsor del proyecto no ejerce como tal durante el mismo. No 'baja a la tierra'.

Mala elección de los consultores y excesiva rotación entre ellos.

Escasa involucración de los usuarios finales que les lleva a sentir cierta frustración con los resultados obtenidos.

Caer en el error de 'en informática todo se puede hacer' y empezar con customizaciones, escribir código fuera de las funcionalidades estándar.

No alinear el proyecto dentro de una estrategia de negocio.

Existen muchos más factores que pueden hacer fallar un proyecto Business Intelligence, pero éstos pueden hacer literalmente 'tumbarlo', no conseguir más proyectos para los consultores, mala imagen del producto y riesgos internos para el director de informática y otros sponsors.

Los sistemas OLAP. Consejos para su correcto uso.

Vamos a suponer que hemos realizado un análisis detallado de las necesidades de la empresa, se ha hablado con todos los interlocutores y usuarios, hemos identificado las necesidades de reporting y acceso, y finalmente, tenemos claro el modelo (que variables, formulas, dimensiones..) vamos a incluir. Es en este momento cuando nos planteamos la pregunta clave: ¿Qué método de almacenamiento vamos a utilizar?

Podemos tener todos los datos en nuestro sistema transaccional, que permite montarlo más rápido, pero puede ser menos eficiente. O podemos precalcular la información para que ésta se obtenga de forma rápida y exacta.

Es una decisión muy importante, porque puede implicar mayor coste de mantenimiento y de licencias.

Es aquí donde conviene aclarar estos acrónimos:

OLAP es online analytical processing.

Se trata de una forma de almacenar la información en una Base de Datos que permita realizar de forma más efectiva las queries. Es una definición abreviada, claro está, la realidad es más compleja.



MOLAP: Multidimensional OLAP. Tanto los datos fuente como los datos agregados o precalculados residen en el mismo formato multidimensional.

Optimiza las queries, pero requiere más espacio de disco y diferente software.

El primer punto esta dejando ser un problema: el espacio de disco cada vez es más barato.

ROLAP: Relational OLAP. Tanto los datos precalculados y agregados como los datos fuente residen en la misma base de datos relacional.

Si el DataWarehouse es muy grande o se necesita rapidez por parte de los usuarios puede ser un problema.

HOLAP: Hybrid OLAP: Es una combinación de los dos anteriores. Los datos agregados y precalculados se almacenan en estructuras multidimensionales y los de menor nivel de detalle en el relacional.

Requiere un buen trabajo de análisis para identificar cada tipo de dato.

Desde un punto de vista práctico añadiremos algunas otras características de un sistema OLAP:

- Debe ser rápido. No debe transcurrir mucho tiempo entre la necesidad de información y el resultado.

- Debe tener un lenguaje funcional y de negocio.

- Debe ser de manejo sencillo, con wizards y templates.

- Debe poder integrar API.

- Debe tener potentes posibilidades gráficas.

- Debe utilizar mapas de forma habitual.

- Posibilidad de almacenar y compartir los informes y cálculos creados por los usuarios.

- La administración la deben llevar los usuarios, no IT.

- El tiempo de implementación (proyecto) debe ser muy corto.

- Deber generar respuestas medibles para la toma de decisiones.

- Tenemos que ser capaces de obtener ROI con las aplicaciones OLAP.

Como resumen final se puede decir los tres principales aspectos a cuidar son la elección de las personas que usaran las herramientas, de quienes llevan el mando en el proyecto y de los consultores externos.



Además de todo esto, el sistema debe estar dentro de una estrategia de negocio clara a medio y largo plazo, para evitar soluciones parche y gastos innecesarios.

BI persigue la transformación de los datos de la compañía en conocimiento para obtener una ventaja competitiva.

Qué: conjunto de metodologías, aplicaciones y tecnologías.

Cómo: reuniendo, depurando y transformando datos de los sistemas transaccionales e información desestructurada (interna y externa a la compañía) en información estructurada.

Para qué: para su explotación directa (informes, análisis OLAP...) o para su análisis y conversión en conocimiento soporte a la toma de decisiones sobre el negocio.



DATAMINING

Descubriendo Información Oculta

Data Mining, la extracción de información oculta y predecible de grandes bases de datos, es una poderosa tecnología nueva con gran potencial para ayudar a las compañías a concentrarse en la información más importante de sus Bases de Información (Data Warehouse). Las herramientas de Data Mining predicen futuras tendencias y comportamientos, permitiendo en los negocios tomar decisiones proactivas y conducidas por un conocimiento acabado de la información (knowledge-driven). Los análisis prospectivos automatizados ofrecidos por un producto así van más allá de los eventos pasados provistos por herramientas retrospectivas típicas de sistemas de soporte de decisión. Las herramientas de Data Mining pueden responder a preguntas de negocios que tradicionalmente consumen demasiado tiempo para poder ser resueltas y a los cuales los usuarios de esta información casi no están dispuestos a aceptar. Estas herramientas exploran las bases de datos en busca de patrones ocultos, encontrando información predecible que un experto no puede llegar a encontrar porque se encuentra fuera de sus expectativas.

Muchas compañías ya colectan y refinan cantidades masivas de datos. Las técnicas de Data Mining pueden ser implementadas rápidamente en plataformas ya existentes de software y hardware para acrecentar el valor de las fuentes de información existentes y pueden ser integradas con nuevos



productos y sistemas pues son traídas en línea (on-line). Una vez que las herramientas de Data Mining fueron implementadas en computadoras cliente servidor de alta performance o de procesamiento paralelo, pueden analizar bases de datos masivas para brindar respuesta a preguntas tales como, "¿Cuáles clientes tienen más probabilidad de responder al próximo mailing promocional, y por qué? y presentar los resultados en formas de tablas, con gráficos, reportes, texto, hipertexto, etc.

Conceptos e Historia

Aunque desde un punto de vista académico el término data mining es una etapa dentro de un proceso mayor llamado extracción de conocimiento en bases de datos (Knowledge Discovery in Databases o KDD) en el entorno comercial, así como en este trabajo, ambos términos se usan de manera indistinta. Lo que en verdad hace el data mining es reunir las ventajas de varias áreas como la Estadística, la Inteligencia Artificial, la Computación Gráfica, las Bases de Datos y el Procesamiento Masivo, principalmente usando como materia prima las bases de datos. Una definición tradicional es la siguiente: "Un proceso no trivial de identificación válida, novedosa, potencialmente útil y entendible de patrones comprensibles que se encuentran ocultos en los datos" (Fayyad y otros, 1996). Desde nuestro punto de vista, lo definimos como "la integración de un conjunto de áreas que tienen como propósito la identificación de un conocimiento obtenido a partir de las bases de datos que aporten un sesgo hacia la toma de decisión" (Molina y otros, 2001).

La idea de data mining no es nueva. Ya desde los años sesenta los estadísticos manejaban términos como data fishing, data mining o data archaeology con la idea de encontrar correlaciones sin una hipótesis previa en bases de datos con ruido. A principios de los años ochenta, Rakesh Agrawal, Gio Wiederhold, Robert Blum y Gregory Piatetsky-Shapiro, entre otros, empezaron a consolidar los términos de data mining y KDD.[3] A finales de los años ochenta sólo existían un par de empresas dedicadas a esta tecnología; en 2002 existen más de 100 empresas en el mundo que ofrecen alrededor de 300 soluciones. Las listas de discusión sobre este tema las forman investigadores de más de ochenta países. Esta tecnología ha sido un buen punto de encuentro entre personas pertenecientes al ámbito académico y al de los negocios.

El data mining es una tecnología compuesta por etapas que integra varias áreas y que no se debe confundir con un gran software. Durante el desarrollo de un



proyecto de este tipo se usan diferentes aplicaciones software en cada etapa que pueden ser estadísticas, de visualización de datos o de inteligencia artificial, principalmente. Actualmente existen aplicaciones o herramientas comerciales de data mining muy poderosas que contienen un sinfín de utilerías que facilitan el desarrollo de un proyecto. Sin embargo, casi siempre acaban complementándose con otra herramienta.

Los Fundamentos del Data Mining

Las técnicas de Data Mining son el resultado de un largo proceso de investigación y desarrollo de productos. Esta evolución comenzó cuando los datos de negocios fueron almacenados por primera vez en computadoras, y continuó con mejoras en el acceso a los datos, y más recientemente con tecnologías generadas para permitir a los usuarios navegar a través de los datos en tiempo real. Data Mining toma este proceso de evolución más allá del acceso y navegación retrospectiva de los datos, hacia la entrega de información prospectiva y proactiva. Data Mining está listo para su aplicación en la comunidad de negocios porque está soportado por tres tecnologías que ya están suficientemente maduras:

Recolección masiva de datos Potentes computadoras con multiprocesadores Algoritmos de Data Mining

La necesidad paralela de motores computacionales mejorados puede ahora alcanzarse de forma más costo - efectiva con tecnología de computadoras con multiprocesamiento paralelo. Los algoritmos de Data Mining utilizan técnicas que han existido por lo menos desde hace 10 años, pero que sólo han sido implementadas recientemente como herramientas maduras, confiables, entendibles que consistentemente son más performantes que métodos estadísticos clásicos.

En la evolución desde los datos de negocios a información de negocios, cada nuevo paso se basa en el previo. Por ejemplo, el acceso a datos dinámicos es crítico para las aplicaciones de navegación de datos (drill through applications), y la habilidad para almacenar grandes bases de datos es crítica para Data Mining.

Los componentes esenciales de la tecnología de Data Mining han estado bajo desarrollo por décadas, en áreas de investigación como estadísticas, inteligencia artificial y aprendizaje de máquinas. Hoy, la madurez de estas técnicas, junto con los motores de bases de datos relacionales de alta performance, hicieron que estas tecnologías fueran prácticas para los entornos de data warehouse actuales.

El Alcance de Data Mining



El nombre de Data Mining deriva de las similitudes entre buscar valiosa información de negocios en grandes bases de datos - por ej.: encontrar información de la venta de un producto entre grandes montos de Gigabytes almacenados - y minar una montaña para encontrar una veta de metales valiosos. Ambos procesos requieren examinar una inmensa cantidad de material, o investigar inteligentemente hasta encontrar exactamente donde residen los valores. Dadas bases de datos de suficiente tamaño y calidad, la tecnología de Data Mining puede generar nuevas oportunidades de negocios al proveer estas capacidades:

Predicción automatizada de tendencias y comportamientos. Data Mining automatiza el proceso de encontrar información predecible en grandes bases de datos. Preguntas que tradicionalmente requerían un intenso análisis manual, ahora pueden ser contestadas directa y rápidamente desde los datos. Un típico ejemplo de problema predecible es el marketing apuntado a objetivos (targeted marketing). Data Mining usa datos en mailing promocionales anteriores para identificar posibles objetivos para maximizar los resultados de la inversión en futuros mailing. Otros problemas predecibles incluyen pronósticos de problemas financieros futuros y otras formas de incumplimiento, e identificar segmentos de población que probablemente respondan similarmente a eventos dados.

Descubrimiento automatizado de modelos previamente desconocidos. Las herramientas de Data Mining barren las bases de datos e identifican modelos previamente escondidos en un sólo paso. Otros problemas de descubrimiento de modelos incluye detectar transacciones fraudulentas de tarjetas de créditos e identificar datos anormales que pueden representar errores de tipeado en la carga de datos.

Las técnicas de Data Mining pueden redituar los beneficios de automatización en las plataformas de hardware y software existentes y puede ser implementadas en sistemas nuevos a medida que las plataformas existentes se actualicen y nuevos productos sean desarrollados. Cuando las herramientas de Data Mining son implementadas en sistemas de procesamiento paralelo de alta performance, pueden analizar bases de datos masivas en minutos. Procesamiento más rápido significa que los usuarios pueden automáticamente experimentar con más modelos para entender datos complejos. Alta velocidad hace que sea práctico para los usuarios analizar inmensas cantidades de datos. Grandes bases de datos, a su vez, producen mejores predicciones.

Las bases de datos pueden ser grandes tanto en profundidad como en ancho:

Más columnas. Los analistas muchas veces deben limitar el número de variables a examinar cuando realizan análisis manuales debido a limitaciones de tiempo. Sin embargo, variables que son descartadas porque



parecen sin importancia pueden proveer información acerca de modelos desconocidos. Un Data Mining de alto rendimiento permite a los usuarios explorar toda la base de datos, sin preseleccionar un subconjunto de variables.

Más filas. Muestras mayores producen menos errores de estimación y desvíos, y permite a los usuarios hacer inferencias acerca de pequeños pero importantes segmentos de población.

Proceso

Un proceso típico de minería de datos consta de los siguientes pasos generales:

1. Selección del conjunto de datos, tanto en lo que se refiere a las variables

objetivo (aquellas que se quiere predecir, calcular o inferir), como a

las variables independientes (las que sirven para hacer el cálculo o

proceso), como posiblemente al muestreo de los registros disponibles.

2. Análisis de las propiedades de los datos, en especial los histogramas,

diagramas de dispersión, presencia de valores atípicos y ausencia de datos

(valores nulos).

3. Transformación del conjunto de datos de entrada, se realizará de

diversas formas en función del análisis previo, con el objetivo de prepararlo

para aplicar la técnica de minería de datos que mejor se adapte a los datos

y al problema, a este paso también se le conoce

como preprocesamiento de los datos.

4. Seleccionar y aplicar la técnica de minería de datos, se construye el

modelo predictivo, de clasificación o segmentación.

5. Extracción de conocimiento, mediante una técnica de minería de datos,

se obtiene un modelo de conocimiento, que representa patrones de

comportamiento observados en los valores de las variables del problema o

relaciones de asociación entre dichas variables. También pueden usarse

varias técnicas a la vez para generar distintos modelos, aunque

generalmente cada técnica obliga a un preprocesado diferente de los

datos.



6. Interpretación y evaluación de datos, una vez obtenido el modelo, se

debe proceder a su validación comprobando que las conclusiones que

arroja son válidas y suficientemente satisfactorias. En el caso de haber

obtenido varios modelos mediante el uso de distintas técnicas, se deben

comparar los modelos en busca de aquel que se ajuste mejor al problema.

Si ninguno de los modelos alcanza los resultados esperados, debe

alterarse alguno de los pasos anteriores para generar nuevos modelos.

Si el modelo final no superara esta evaluación el proceso se podría repetir desde

el principio o, si el experto lo considera oportuno, a partir de cualquiera de los

pasos anteriores. Esta retroalimentación se podrá repetir cuantas veces se

considere necesario hasta obtener un modelo válido.

Una vez validado el modelo, si resulta ser aceptable (proporciona salidas

adecuadas y/o con márgenes de error admisibles) éste ya está listo para su

explotación. Los modelos obtenidos por técnicas de minería de datos se aplican

incorporándolos en los sistemas de análisis de información de las organizaciones,

e incluso, en los sistemas transaccionales. En este sentido cabe destacar los

esfuerzos del Data Mining Group, que está estandarizando el

lenguaje PMML (Predictive Model Markup Language), de manera que los modelos

de minería de datos sean interoperables en distintas plataformas, con

independencia del sistema con el que han sido construidos. Los principales

fabricantes de sistemas de bases de datos y programas de análisis de la

información hacen uso de este estándar.

Tradicionalmente, las técnicas de minería de datos se aplicaban sobre información

contenida en almacenes de datos. De hecho, muchas grandes empresas e

instituciones han creado y alimentan bases de datos especialmente diseñadas

para proyectos de minería de datos en las que centralizan información

potencialmente útil de todas sus áreas de negocio. No obstante, actualmente está

cobrando una importancia cada vez mayor la minería de datos desestructurados

como información contenida en ficheros de texto, en Internet, etc.

Protocolo de un proyecto de minería de datos

Un proyecto de minería de datos tiene varias fases necesarias que son,

esencialmente:



Comprensión del negocio y del problema que se quiere resolver.

Determinación, obtención y limpieza de los datos necesarios.

Creación de modelos matemáticos.

Validación, comunicación, etc. de los resultados obtenidos.

Integración, si procede, de los resultados en un sistema transaccional o

similar.

La relación entre todas estas fases sólo es lineal sobre el papel. En realidad, es

mucho más compleja y esconde toda una jerarquía de subfases. A través de la

experiencia acumulada en proyectos de minería de datos se han ido

desarrollando metodologías que permiten gestionar esta complejidad de una

manera más o menos uniforme.

Las técnicas más comúnmente usadas en Data Mining son:

Redes neuronales artificiales: modelos predecible no-lineales que aprenden a través del entrenamiento y semejan la estructura de red neuronal biológica.

Arboles de decisión: estructuras de forma de árbol que representan conjuntos de decisiones. Estas decisiones generan reglas para la clasificación de un conjunto de datos. Métodos específicos de árboles de decisión incluyen Arboles de Clasificación y Regresión (CART: Classification And Regression Tree) y Detección de Interacción Automática de Chi Cuadrado (CHAI: Chi Square Automatic Interaction Detection)

Algoritmos genéticos: técnicas de optimización que usan procesos tales como combinaciones genéticas, mutaciones y selección natural en un diseño basado en los conceptos de evolución.

Método del vecino más cercano: una técnica que clasifica cada registro en un conjunto de datos basado en una combinación de las clases del/de



los k registro (s) más similar/es a él en un conjunto de datos históricos (donde k 1). Algunas veces se llama la técnica del vecino k-más cercano.

Regla de inducción: la extracción de reglas if-then de datos basados en significado estadístico.

Muchas de estas tecnologías han estado en uso por más de una década en herramientas de análisis especializadas que trabajan con volúmenes de datos relativamente pequeños. Estas capacidades están ahora evolucionando para integrarse directamente con herramientas OLAP y de Data Warehousing.

¿Cómo Trabaja el Data Mining?

¿Cuán exactamente es capaz Data Mining de decirle cosas importantes se desconocen o que van a pasar? La técnica usada para realizar estas hazañas en Data Mining se llama Modelado. Modelado es simplemente el acto de construir un modelo en una situación donde usted conoce la respuesta y luego la aplica en otra situación de la cual desconoce la respuesta. Por ejemplo, si busca un galeón español hundido en los mares lo primero que podría hacer es investigar otros tesoros españoles que ya fueron encontrados en el pasado. Notaría que esos barcos frecuentemente fueron encontrados fuera de las costas de Bermuda y que hay ciertas características respecto de las corrientes oceánicas y ciertas rutas que probablemente tomara el capitán del barco en esa época. Usted nota esas similitudes y arma un modelo que incluye las características comunes a todos los sitios de estos tesoros hundidos. Con estos modelos en mano sale a buscar el tesoro donde el modelo indica que en el pasado hubo más probabilidad de darse una situación similar. Con un poco de esperanza, si tiene un buen modelo, probablemente encontrará el tesoro.

Este acto de construcción de un modelo es algo que la gente ha estado haciendo desde hace mucho tiempo, seguramente desde antes del auge de las computadoras y de la tecnología de Data Mining. Lo que ocurre en las computadoras, no es muy diferente de la manera en que la gente construye modelos. Las computadoras son cargadas con mucha información acerca de una variedad de situaciones donde una respuesta es conocida y luego el software de Data Mining en la computadora debe correr a través de los datos y distinguir las características de los datos que llevarán al modelo. Una vez que el modelo se construyó, puede ser usado en situaciones similares donde usted no conoce la respuesta.

Si alguien le dice que tiene un modelo que puede predecir el uso de los clientes, ¿Cómo puede saber si es realmente un buen modelo? La primera cosa que puede



probar es pedirle que aplique el modelo a su base de clientes - donde usted ya conoce la respuesta. Con Data Mining, la mejor manera para realizar esto es dejando de lado ciertos datos para aislarlos del proceso de Data Mining. Una vez que el proceso está completo, los resultados pueden ser testeados contra los datos excluidos para confirmar la validez del modelo. Si el modelo funciona, las observaciones deben mantenerse para los datos excluidos.

Una arquitectura para Data Mining

Para aplicar mejor estas técnicas avanzadas, éstas deben estar totalmente integradas con el data warehouse así como con herramientas flexibles e interactivas para el análisis de negocios. Varias herramientas de Data Mining actualmente operan fuera del warehouse, requiriendo pasos extra para extraer, importar y analizar los datos. Además, cuando nuevos conceptos requieren implementación operacional, la integración con el warehouse simplifica la aplicación de los resultados desde Data Mining. El Data warehouse analítico resultante puede ser aplicado para mejorar procesos de negocios en toda la organización, en áreas tales como manejo de campañas promocionales, detección de fraudes, lanzamiento de nuevos productos, etc.

El punto de inicio ideal es un data warehouse que contenga una combinación de datos de seguimiento interno de todos los clientes junto con datos externos de mercado acerca de la actividad de los competidores. Información histórica sobre potenciales clientes también provee una excelente base para prospecting. Este warehouse puede ser implementado en una variedad de sistemas de bases relacionales y debe ser optimizado para un acceso a los datos flexible y rápido.

Un server multidimensional OLAP permite que un modelo de negocios más sofisticado pueda ser aplicado cuando se navega por el data warehouse. Las estructuras multidimensionales permiten que el usuario analice los datos de acuerdo a como quiera mirar el negocio - resumido por línea de producto, u otras perspectivas claves para su negocio. El server de Data Mining debe estar integrado con el data warehouse y el server OLAP para insertar el análisis de negocios directamente en esta infraestructura. Un avanzado, metadata centrado en procesos define los objetivos del Data Mining para resultados específicos tales como manejos de campaña, prospecting, y optimización de promociones. La integración con el data warehouse permite que decisiones operacionales sean implementadas directamente y monitoreadas. A medida que el data warehouse crece con nuevas decisiones y resultados, la organización puede "minar" las mejores prácticas y aplicarlas en futuras decisiones.

Este diseño representa una transferencia fundamental desde los sistemas de soporte de decisión convencionales. Más que simplemente proveer datos a los usuarios finales a través de software de consultas y reportes, el server de Análisis Avanzado aplica los modelos de negocios del usuario directamente al warehouse y devuelve un análisis proactivo de la información más relevante. Estos resultados mejoran los metadatos en el server OLAP proveyendo una estrato de metadatos



que representa una vista fraccionada de los datos. Generadores de reportes, visualizadores y otras herramientas de análisis pueden ser aplicadas para planificar futuras acciones y confirmar el impacto de esos planes.

Glosario de Términos de Data Mining

Algoritmos genéticos: Técnicas de optimización que usan procesos tales como combinación genética, mutación y selección natural en un diseño basado en los conceptos de evolución natural.

Análisis de series de tiempo (time-series): Análisis de una secuencia de medidas hechas a intervalos específicos. El tiempo es usualmente la dimensión dominante de los datos.

Análisis prospectivo de datos: Análisis de datos que predice futuras tendencias, comportamientos o eventos basado en datos históricos.

Análisis exploratorio de datos: Uso de técnicas estadísticas tanto gráficas como descriptivas para aprender acerca de la estructura de un conjunto de datos.

Análisis retrospectivo de datos: Análisis de datos que provee una visión de las tendencias, comportamientos o eventos basado en datos históricos.

Árbol de decisión: Estructura en forma de árbol que representa un conjunto de decisiones. Estas decisiones generan reglas para la clasificación de un conjunto de datos. Ver CART y CHAID.

Base de datos multidimensional: Base de datos diseñada para procesamiento analítico on-line (OLAP). Estructurada como un hipercubo con un eje por dimensión.

CART Árboles de clasificación y regresión: Una técnica de árbol de decisión usada para la clasificación de un conjunto da datos. Provee un conjunto de reglas que se pueden aplicar a un nuevo (sin clasificar) conjunto de datos para predecir cuáles registros darán un cierto resultado. Segmenta un conjunto de datos creando 2 divisiones. Requiere menos preparación de datos que CHAID.

CHAID Detección de interacción automática de Chi cuadrado: Una técnica de árbol de decisión usada para la clasificación de un conjunto da datos. Provee un conjunto de reglas que se pueden aplicar a un nuevo (sin clasificar) conjunto de datos para predecir cuáles registros darán un cierto resultado. Segmenta un conjunto de datos utilizando tests de chi cuadrado para crear múltiples divisiones. Antecede, y requiere más preparación de datos, que CART.

Clasificación: Proceso de dividir un conjunto de datos en grupos mutuamente excluyentes de tal manera que cada miembro de un grupo esté lo "más cercano" posible a otro, y grupos diferentes estén lo "más lejos" posible uno del otro, donde la distancia está medida con respecto a variable(s) específica(s) las cuales se están tratando de predecir. Por ejemplo, un problema típico de clasificación es el de dividir una base de datos de compañías en grupos que



son lo más homogéneos posibles con respecto a variables como "posibilidades de crédito" con valores tales como "Bueno" y "Malo".

Clustering (agrupamiento): Proceso de dividir un conjunto de datos en grupos mutuamente excluyentes de tal manera que cada miembro de un grupo esté lo "más cercano" posible a otro, y grupos diferentes estén lo "más lejos" posible uno del otro, donde la distancia está medida con respecto a todas las variables disponibles.

Computadoras con multiprocesadores: Una computadora que incluye múltiples procesadores conectados por una red. Ver procesamiento paralelo.

Data cleansing: Proceso de asegurar que todos los valores en un conjunto de datos sean consistentes y correctamente registrados.

Data Mining: La extracción de información predecible escondida en grandes bases de datos.

Data Warehouse: Sistema para el almacenamiento y distribución de cantidades masivas de datos

Datos anormales: Datos que resultan de errores (por ej.: errores en el tipeado durante la carga) o que representan eventos inusuales.

Dimensión: En una base de datos relacional o plana, cada campo en un registro representa una dimensión. En una base de datos multidimensional, una dimensión es un conjunto de entidades similares; por ej.: una base de datos multidimensional de ventas podría incluir las dimensiones Producto, Tiempo y Ciudad.

Modelo analítico: Una estructura y proceso para analizar un conjunto de datos. Por ejemplo, un árbol de decisión es un modelo para la clasificación de un conjunto de datos

Modelo lineal: Un modelo analítico que asume relaciones lineales entre una variable seleccionada (dependiente) y sus predictores (variables independientes).

Modelo no lineal: Un modelo analítico que no asume una relación lineal en los coeficientes de las variables que son estudiadas.

Modelo predictivo: Estructura y proceso para predecir valores de variables especificadas en un conjunto de datos.

Navegación de datos: Proceso de visualizar diferentes dimensiones, "fetas" y niveles de una base de datos multidimensional. Ver OLAP.

OLAP Procesamiento analítico on-line (On Line Analitic procesing): Se refiere a aplicaciones de bases de datos orientadas a array que permite a los usuarios ver, navegar, manipular y analizar bases de datos multidimensionales.

Outlier: Un item de datos cuyo valor cae fuera de los límites que encierran a la mayoría del resto de los valores correspondientes de la muestra. Puede indicar datos anormales. Deberían ser examinados detenidamente; pueden dar importante información.

Procesamiento paralelo: Uso coordinado de múltiples procesadores para realizar tareas computacionales. El procesamiento paralelo puede ocurrir en



una computadora con múltiples procesadores o en una red de estaciones de trabajo o PCs.

RAID: Formación redundante de discos baratos (Redundant Array of inexpensive disks). Tecnología para el almacenamiento paralelo eficiente de datos en sistemas de computadoras de alto rendimiento.

Regresión lineal: Técnica estadística utilizada para encontrar la mejor relación lineal que encaja entre una variable seleccionada (dependiente) y sus predicados (variables independientes).

Regresión logística: Una regresión lineal que predice las proporciones de una variable seleccionada categórica, tal como Tipo de Consumidor, en una población.

Vecino más cercano: Técnica que clasifica cada registro en un conjunto de datos basado en una combinación de las clases del/de los k registro (s) más similar/es a él en un conjunto de datos históricos (donde k 1). Algunas veces se llama la técnica del vecino k-más cercano.

SMP Multiprocesador simétrico (Symmetric multiprocessor): Tipo de computadora con multiprocesadores en la cual la memoria es compartida entre los procesadores

Negocios de Data Mining

La minería de datos puede contribuir significativamente en las aplicaciones

de administración empresarial basada en la relación con el cliente. En lugar de

contactar con el cliente de forma indiscriminada a través de un centro de llamadas

o enviando cartas, sólo se contactará con aquellos que se perciba que tienen una

mayor probabilidad de responder positivamente a una determinada oferta o

promoción.

Por lo general, las empresas que emplean minería de datos ven rápidamente el

retorno de la inversión, pero también reconocen que el número de modelos

predictivos desarrollados puede crecer muy rápidamente.

En lugar de crear modelos para predecir qué clientes pueden cambiar, la empresa

podría construir modelos separados para cada región y/o para cada tipo de cliente.

También puede querer determinar qué clientes van a ser rentables durante una

ventana de tiempo (una quincena, un mes) y sólo enviar las ofertas a las personas

que es probable que sean rentables. Para mantener esta cantidad de modelos, es



necesario gestionar las versiones de cada modelo y pasar a una minería de datos

lo más automatizada posible.

Hábitos de compra en supermercados

El ejemplo clásico de aplicación de la minería de datos tiene que ver con la

detección de hábitos de compra en supermercados. Un estudio muy citado

detectó que los viernes había una cantidad inusualmente elevada de clientes que

adquirían a la vez pañales y cerveza. Se detectó que se debía a que dicho día

solían acudir al supermercado padres jóvenes cuya perspectiva para el fin de

semana consistía en quedarse en casa cuidando de su hijo y viendo la televisión

con una cerveza en la mano. El supermercado pudo incrementar sus ventas de

cerveza colocándolas próximas a los pañales para fomentar las

ventas compulsivas.

Patrones de fuga

Un ejemplo más habitual es el de la detección de patrones de fuga. En muchas

industrias —como la banca, las telecomunicaciones, etc. Existe un comprensible

interés en detectar cuanto antes aquellos clientes que puedan estar pensando en

rescindir sus contratos para, posiblemente, pasarse a la competencia. A estos

clientes —y en función de su valor— se les podrían hacer ofertas personalizadas,

ofrecer promociones especiales, etc., con el objetivo último de retenerlos. La

minería de datos ayuda a determinar qué clientes son los más proclives a darse de

baja estudiando sus patrones de comportamiento y comparándolos con muestras

de clientes que, efectivamente, se dieron de baja en el pasado.

Fraudes

Un caso análogo es el de la detección de transacciones de lavado de dinero o

de fraude en el uso de tarjetas de crédito o de servicios de telefonía móvil e,

incluso, en la relación de los contribuyentes con el fisco. Generalmente, estas

operaciones fraudulentas o ilegales suelen seguir patrones característicos que

permiten, con cierto grado de probabilidad, distinguirlas de las legítimas y

desarrollar así mecanismos para tomar medidas rápidas frente a ellas.

Recursos humanos

La minería de datos también puede ser útil para los departamentos de recursos

humanos en la identificación de las características de sus empleados de mayor



éxito. La información obtenida puede ayudar a la contratación de personal,

centrándose en los esfuerzos de sus empleados y los resultados obtenidos por

éstos. Además, la ayuda ofrecida por las aplicaciones para Dirección

estratégica en una empresa se traducen en la obtención de ventajas a nivel

corporativo, tales como mejorar el margen de beneficios o compartir objetivos; y

en la mejora de las decisiones operativas, tales como desarrollo de planes

de producción o gestión de mano de obra.

Comportamiento en Internet

También es un área en boga el del análisis del comportamiento de los visitantes

sobre todo, cuando son clientes potenciales en una página de Internet. O la

utilización de la información obtenida por medios más o menos legítimos sobre

ellos para ofrecerles propaganda adaptada específicamente a su perfil. O para,

una vez que adquieren un determinado producto, saber inmediatamente qué otro

ofrecerle teniendo en cuenta la información histórica disponible acerca de los

clientes que han comprado el primero.

Terrorismo

La minería de datos ha sido citada como el método por el cual la unidad Able

Danger del Ejército de los EE. UU. había identificado al líder de los atentados del

11 de septiembre de 2001, Mohammed Atta, y a otros tres secuestradores del "11-

S" como posibles miembros de una célula de Al Qaeda que operan en los EE. UU.

Más de un año antes del ataque. Se ha sugerido que tanto la Agencia Central de

Inteligencia y su homóloga canadiense, Servicio de Inteligencia y Seguridad

Canadiense, también han empleado este método.

Juegos

Desde comienzos de la década de 1960, con la disponibilidad de oráculos para

determinados juegos combinacionales, también llamados finales de juego de

tablero (por ejemplo, para las tres en raya o en finales de ajedrez) con cualquier

configuración de inicio, se ha abierto una nueva área en la minería de datos que

consiste en la extracción de estrategias utilizadas por personas para estos

oráculos. Los planteamientos actuales sobre reconocimiento de patrones, no

parecen poder aplicarse con éxito al funcionamiento de estos oráculos. En su

lugar, la producción de patrones perspicaces se basa en una amplia



experimentación con bases de datos sobre esos finales de juego, combinado con

un estudio intensivo de los propios finales de juego en problemas bien diseñados

y con conocimiento de la técnica (datos previos sobre el final del juego). Ejemplos

notables de investigadores que trabajan en este campo son Berlekamp en el juego

de puntos-y-cajas (o Timbiriche) y John Nunn en finales de ajedrez.

Ciencia e Ingeniería

En los últimos años la minería de datos se está utilizando ampliamente en

diversas áreas relacionadas con la ciencia y la ingeniería. Algunos ejemplos de

aplicación en estos campos son:

Genética

En el estudio de la genética humana, el objetivo principal es entender la

relación cartográfica entre las partes y la variación individual en las secuencias

del ADN humano y la variabilidad en la susceptibilidad a las enfermedades. En

términos más llanos, se trata de saber cómo los cambios en la secuencia de ADN

de un individuo afectan al riesgo de desarrollar enfermedades comunes (como por

ejemplo el cáncer). Esto es muy importante para ayudar a mejorar el diagnóstico,

prevención y tratamiento de las enfermedades. La técnica de minería de datos que

se utiliza para realizar esta tarea se conoce como "reducción de

dimensionalidad multifactorial".

Ingeniería eléctrica

En el ámbito de la ingeniería eléctrica, las técnicas minería de datos han sido

ampliamente utilizadas para monitorizar las condiciones de las instalaciones

de alta tensión. La finalidad de esta monitorización es obtener información valiosa

sobre el estado del aislamiento de los equipos. Para la vigilancia de las

vibraciones o el análisis de los cambios de carga en transformadores se utilizan

ciertas técnicas para agrupación de datos (clustering) tales como los Mapas

Auto-Organizativos (SOM, Self-organizing map). Estos mapas sirven para detectar

condiciones anormales y para estimar la naturaleza de dichas anomalías.

Análisis de gases

También se han aplicado técnicas de minería de datos para el análisis de gases

disueltos (DGA, Dissolved gas analysis) en transformadores eléctricos. El análisis

de gases disueltos se conoce desde hace mucho tiempo como herramienta para



diagnosticar transformadores. Los Mapas Auto-Organizativos (SOM) se utilizan

para analizar datos y determinar tendencias que podrían pasarse por alto

utilizando las técnicas clásicas DGA.

Minería de datos y otras disciplinas análogas

Suscita cierta polémica el definir las fronteras existentes entre la minería de

datos y disciplinas análogas, como pueden serlo la estadística, la inteligencia

artificial, etc. Hay quienes sostienen que la minería de datos no es

sino estadística envuelta en una jerga de negocios que la conviertan en un

producto vendible. Otros, en cambio, encuentran en ella una serie de problemas y

métodos específicos que la hacen distinta de otras disciplinas.

El hecho es, que en la práctica la totalidad de los modelos y algoritmos de uso

general en minería de datos (redes neuronales, árboles de regresión y

clasificación, modelos logísticos, análisis de componentes principales, etc.) gozan

de una tradición relativamente larga en otros campos.

De la estadística

Ciertamente, la minería de datos bebe de la estadística, de la que toma las

siguientes técnicas:

Análisis de varianza, mediante el cual se evalúa la existencia de diferencias

significativas entre las medias de una o más variables continúas en

poblaciones distintas.

Regresión: define la relación entre una o más variables y un conjunto de

variables predictoras de las primeras.

Prueba chi-cuadrado: por medio de la cual se realiza el contraste la hipótesis

de dependencia entre variables.

Análisis de agrupamiento o clustering: permite la clasificación de una población

de individuos caracterizados por múltiples atributos (binarios, cualitativos o

cuantitativos) en un número determinado de grupos, con base en las

semejanzas o diferencias de los individuos.

Análisis discriminante: permite la clasificación de individuos en grupos que

previamente se han establecido, permite encontrar la regla de clasificación de



los elementos de estos grupos, y por tanto una mejor identificación de cuáles

son las variables que definan la pertenencia al grupo.

Series de tiempo: permite el estudio de la evolución de una variable a través

del tiempo para poder realizar predicciones, a partir de ese conocimiento y

bajo el supuesto de que no van a producirse cambios estructurales.

De la informática

De la informática toma las siguientes técnicas:

Algoritmos genéticos: Son métodos numéricos de optimización, en los que

aquella variable o variables que se pretenden optimizar junto con las variables

de estudio constituyen un segmento de información. Aquellas configuraciones

de las variables de análisis que obtengan mejores valores para la variable de

respuesta, corresponderán a segmentos con mayor capacidad reproductiva. A

través de la reproducción, los mejores segmentos perduran y su proporción

crece de generación en generación. Se puede además introducir elementos

aleatorios para la modificación de las variables (mutaciones). Al cabo de cierto

número de iteraciones, la población estará constituida por buenas soluciones

al problema de optimización, pues las malas soluciones han ido

descartándose, iteración tras iteración.

Inteligencia Artificial: Mediante un sistema informático que simula un sistema

inteligente, se procede al análisis de los datos disponibles. Entre los sistemas

de Inteligencia Artificial se encuadrarían los Sistemas Expertos y las Redes

Neuronales.

Sistemas Expertos: Son sistemas que han sido creados a partir de reglas

prácticas extraídas del conocimiento de expertos. Principalmente a base de

inferencias o de causa-efecto.

Sistemas Inteligentes: Son similares a los sistemas expertos, pero con mayor

ventaja ante nuevas situaciones desconocidas para el experto.

Redes neuronales: Genéricamente, son métodos de proceso numérico en

paralelo, en el que las variables interactúan mediante transformaciones

lineales o no lineales, hasta obtener unas salidas. Estas salidas se contrastan



con los que tenían que haber salido, basándose en unos datos de prueba,

dando lugar a un proceso de retroalimentación mediante el cual la red se

reconfigura, hasta obtener un modelo adecuado.

Minería de datos basada en teoría de la información

Todas las herramientas tradicionales de minería de datos asumen que los datos

que usarán para construir los modelos contienen la información necesaria para

lograr el propósito buscado: obtener suficiente conocimiento que pueda ser

aplicado al negocio (o problema) para obtener un beneficio (o solución).

El inconveniente es que esto no es necesariamente cierto. Además, existe otro

problema mayor aún. Una vez construido el modelo no es posible conocer si el

mismo ha capturado toda la información disponible en los datos. Por esta razón la

práctica común es realizar varios modelos con distintos parámetros para ver si

alguno logra mejores resultados.

Un enfoque relativamente nuevo al análisis de datos soluciona estos problemas

haciendo que la práctica de la minería de datos se parezca más a una ciencia que

a un arte.

En 1948 Claude Shannon publicó un trabajo llamado “Una Teoría Matemática de

la Comunicación”. Posteriormente esta pasó a llamarse Teoría de la información y

sentó las bases de la comunicación y la codificación de la información. Shannon

propuso una manera de medir la cantidad de información a ser expresada en bits.

En 1999 Dorian Pyle publicó un libro llamado “Data Preparation for Data Mining”

en el que propone una manera de usar la Teoría de la Información para analizar

datos. En este nuevo enfoque, una base de datos es un canal que transmite

información. Por un lado está el mundo real que captura datos generados por el

negocio. Por el otro están todas las situaciones y problemas importantes del

negocio. Y la información fluye desde el mundo real y a través de los datos, hasta

la problemática del negocio.

Con esta perspectiva y usando la Teoría de la información, es posible medir la

cantidad de información disponible en los datos y qué porción de la misma podrá

utilizarse para resolver la problemática del negocio. Como un ejemplo práctico,



podría encontrarse que los datos contienen un 65% de la información necesaria

para predecir qué cliente rescindirán sus contratos. De esta manera, si el modelo

final es capaz de hacer predicciones con un 60% de acierto, se puede asegurar

que la herramienta que generó el modelo hizo un buen trabajo capturando la

información disponible. Ahora, si el modelo hubiese tenido un porcentaje de

aciertos de solo el 10%, por ejemplo, entonces intentar otros modelos o incluso

con otras herramientas podría valer la pena.

La capacidad de medir información contenida en los datos tiene otras ventajas

importantes.

Al analizar los datos desde esta nueva perspectiva se genera un mapa de

información que hace innecesario la preparación previa de los datos, una tarea

absolutamente imprescindible si se desea buenos resultados, pero que lleva

enorme cantidad de tiempo.

Es posible seleccionar un grupo de variables óptimo que contenga la información

necesaria para realizar un modelo de predicción.

Una vez que las variables son procesadas con el fin de crear el mapa de

información y luego seleccionadas aquellas que aportan la mayor información, la

elección de la herramienta que se usará para crear el modelo deja de tener

importancia, ya que el mayor trabajo fue realizado en los pasos previos.

Tendencias

La Minería de Datos ha sufrido transformaciones en los últimos años de acuerdo

con cambios tecnológicos, de estrategias de marketing, la extensión de los

modelos de compra en línea, etc. Los más importantes de ellos son:

La importancia que han cobrado los datos no estructurados (texto, páginas

de Internet, etc.).

La necesidad de integrar los algoritmos y resultados obtenidos en sistemas

operacionales, portales de Internet, etc.

La exigencia de que los procesos funcionen prácticamente en línea (por

ejemplo, en casos de fraude con una tarjeta de crédito).

Los tiempos de respuesta. El gran volumen de datos que hay que procesar

en muchos casos para obtener un modelo válido es un inconveniente; esto



implica grandes cantidades de tiempo de proceso y hay problemas que

requieren una respuesta en tiempo real.

Herramientas de software

Existen muchas herramientas de software para el desarrollo de modelos de

minería de datos tanto libres como comerciales como, por ejemplo:

dVelox

KXEN

KNIME

Orange

Powerhouse

Quiterian

RapidMiner

R

SPSS Clementine



Ejemplo de Data Mining

Predicciones de Venta

DESCRIPCIÓN:

Uno de los campos de aplicación tradicionales de la minería de datos es la predicción de la evolución en el futuro de una variable (o conjunto de variables) a partir de datos históricos sobre su comportamiento en el pasado. Las técnicas de minería de datos constituyen una alternativa útil y eficaz a las aproximaciones matemáticas tradicionales, especialmente en el caso de variaciones muy irregulares, complicadas de modelar con los métodos clásicos.

La empresa Bayer mantiene un registro histórico de diferentes datos, entre ellos las cifras de ventas. Basándose únicamente en los datos de ventas de uno de sus productos, sin indicadores adicionales, pretende desarrollar un modelo del comportamiento de dicho producto en el mercado que le permita predecir las



ventas del mismo con cierta anticipación. En concreto, se dispone de las cifras de los últimos 56 meses.

Con esta información, los resultados obtenidos aplicando métodos de predicción tradicionales no son suficientemente precisos. Así, tomando como estimación para un mes el importe correspondiente al mes anterior, se obtiene un error del 25,6%, y del 14% si se usa el de ese mes en el año anterior. La calidad de la predicción mejora utilizando medias móviles, pero el error es aún del 11,8%. Debido a los altos porcentajes de error obtenidos, ninguno de estos métodos satisface las necesidades de la compañía.

Para mejorar la precisión del modelo y conseguir la exactitud necesaria en las predicciones, se han aplicado técnicas de minería de datos.

En primer lugar, se han analizado las características básicas de la serie. A simple vista, se observa que las ventas presentan una tendencia creciente en el tiempo que puede modelarse con medias móviles. También se observan oscilaciones estacionales, aunque estas regularidades no aparecen en todos los meses. Por ejemplo, si bien los valores de las ventas son siempre bajos en agosto, los de mayo presentan grandes variaciones. Esto puede significar que la serie incluye varios factores de influencia con distintos periodos. Estas observaciones se ven confirmadas por el análisis del espectro de frecuencia, que muestra varios máximos.

Las conclusiones de los estudios preliminares sugieren la conveniencia de incluir en el modelo información no sólo de los valores de ventas en los meses previos sino también sobre la tendencia de la serie y sobre la temporada en cuestión, datos todos ellos contenidos en la propia serie.

El sistema desarrollado, basado en una red neuronal, predice las ventas en un determinado mes partiendo únicamente de características extraídas de la serie de ventas en función del tiempo, sin indicadores adicionales. En concreto, los datos de entrada con los que se han obtenido los mejores resultados son:

� Valores de las ventas en los tres meses anteriores.

� Ventas del mes a predecir en el año anterior.

� Valor medio de las ventas durante los últimos 12 meses.

� Identificador del mes.



Las predicciones del modelo obtenido aplicando minería de datos son notablemente más precisas, con un error medio del 6,4%, que con las técnicas clásicas, debido sin duda a que la serie considerada presenta un comportamiento altamente volátil, difícil de modelar con los métodos clásicos.

Data WareHouse

Introducción

Que es un Data WareHouse?

Es un repositorio de datos de muy fácil acceso, alimentado de numerosas fuentes, transformadas en grupos de información sobre temas específicos de negocios, para permitir nuevas consultas, análisis, reporteador y decisiones.

Que es lo que le preocupa a los ejecutivos?

Se tienen montañas de datos en la compañía, pero no podemos llegar a ellos adecuadamente. Nada enloquece más a los ejecutivos que dos personas presentando el mismo resultado de operación pero con diferentes números y los ejecutivos lo que buscan es ver la información pero desde diferentes ángulos, mostrando únicamente lo que es importante para tomar una decisión en la empresa, finalmente los ejecutivos saben que hay datos que nunca serán confiables, por lo que prefieren que se eviten en los reportes ejecutivos.

Uno de los valores más importantes de una organización es la información.

Estos valores normalmente son guardados por la organización de dos formas:

Los sistemas operacionales de registros Y el Data Warehouse

Crudamente hablando, los sistema operacionales de registros es donde los datos son depositados y el Data WareHouse es de donde se extraen eso datos.

Los objetivos fundamentales de un Data WareHouse son:

Hace que la información de la organización sea accesible: los contenidos del Data WareHouse son entendibles y navegables, y el acceso a ellos son caracterizado por el rápido desempeño. Estos requerimientos no tienen fronteras y tampoco limites fijos. Cuando hablamos de entendible significa, que los niveles de la información sean correctos y obvios. Y Navegables significa el reconocer el destino en la pantalla y llegar a donde queramos con solo un clic. Rápido desempeño significa, cero tiempos de espera. Todo lo demás es un compromiso y por consiguiente algo que queremos mejorar.



Hacer que la información de la organización sea consistente: la información de una parte de la organización puede hacerse coincidir con la información de la otra parte de la organización. Si dos medidas de la organización tienen el mismo nombre, entonces deben significar la misma cosa. Y a la inversa, si dos medidas no significan la misma cosa, entonces son etiquetados diferentes. Información consistente significa, información de alta calidad. Significa que toda la información es contabilizada y completada. Todo lo demás es un compromiso y por consiguiente algo que queremos mejorar.

Es información adaptable y elástica: el Data WareHouse está diseñado para cambios continuos. Cuando se le hacen nuevas preguntas al Data WareHouse, los datos existentes y las tecnologías no cambian ni se corrompen. Cuando se agregan datos nuevos al Data WareHouse, los datos existentes y las tecnologías tampoco cambian ni se corrompen. El diseño de Data Marts separados que hacen al Data WareHouse, deben ser distribuidos e incrementados. Todo lo demás es un compromiso y por consiguiente algo que queremos mejorar.

Es un seguro baluarte que protege los valores de la información: el Data WareHouse no solamente controla el acceso efectivo a los datos, si no que da a los dueños de la información gran visibilidad en el uso y abusos de los datos, aún después de haber dejado el Data WareHouse. Todo lo demás es un compromiso y por consiguiente algo que queremos mejorar.

Es la fundación de la toma de decisiones: el Data WareHouse tiene los datos correctos para soportar la toma de decisiones. Solo hay una salida verdadera del Data WareHouse: las decisiones que son hechas después de que el Data WareHouse haya presentado las evidencias. La original etiqueta que preside el Data WareHouse sigue siendo la mejor descripción de lo que queremos construir: un sistema de soporte a las decisiones.

Los elementos básicos de un Data WareHouse

Sistema fuente: sistemas operacionales de registros donde sus funciones son capturar las transacciones del negocio. A los sistemas fuentes también se le conoce como Legacy System.

Área de tráfico de datos: es un área de almacenamiento y grupo de procesos, que limpian transforman, combinan, remover los duplicados, guardan, archivan y preparan los datos fuente para ser usados en el Data WareHouse.



Servidor de presentación: la maquina física objetivo en donde los datos del Data WareHouse son organizados y almacenados para queries directos por los usuarios finales, reportes y otras aplicaciones.

Modelo dimensional: una disciplina específica para el modelado de datos que es una alternativa para los modelos de entidad – relación.

Procesos de negocios: un coherente grupo de actividades de negocio que hacen sentido a los usuarios del negocio del Data WareHouse.

Data Mart: un subgrupo lógico del Data WareHouse completo. Data WareHouse: búsquedas fuentes de datos de la empresa. Y es la unión de

todos los data marts que la constituyen. Almacenamiento operacional de datos: es el punto de integración por los

sistemas operacionales. Es el acceso al soporte de decisiones por los ejecutivos.

OLAP: actividad general de búsquedas para presentación de texto y números del Data WareHouse, también un estilo dimensional especifico de búsquedas y presentación de información y que es ejemplificada por vendedores de OLAP.

ROLAP: un grupo de interfaces de usuarios y aplicaciones que le dan a la base de datos relacional un estilo dimensional.

MOLAP: un grupo de interfaces de usuarios, aplicaciones y propietarios de tecnología de bases de datos que tienen un fuerte estilo dimensional.

Aplicaciones para usuarios finales: una colección de herramientas que hacen los queries, analizan y presentan la información objetivo para el soporte de las necesidades del negocio.

Herramientas de acceso a datos por usuarios finales: un cliente de Data WareHouse.

Ad Hoc Query Tool: un tipo específico de herramientas de acceso a datos por usuarios finales que invita al usuario a formas sus propios queries manipulando directamente las tablas relacionales y sus uniones.

Modelado de aplicaciones: un sofisticado tipo de cliente de Data WareHouse con capacidades analíticas que transforma o digiere las salidas del Data WareHouse.

Meta Data: toda la información en el ambiente del Data WareHouse que no son así mismo los datos actuales.



Los procesos básicos del Data WareHouse (ETL)

Extracción: este es el primer paso de obtener la información hacia el ambiente del Data WareHouse.

Transformación: una vez que la información es extraída hacia el área de trafico de datos, hay posibles paso de transformación como; limpieza de la información, tirar la basura que no nos sirve, seleccionar únicamente los campos necesarios para el Data WareHouse, combinar fuentes de datos, haciéndolas coincidir por los valores de las llaves, creando nuevas llaves para cada registro de una dimensión.

Carga: al final del proceso de transformación, los datos están en forma para ser cargados.

Las razones básicas de porque una organización implementa Data WareHouse:

Para realizar tareas en los servidores y discos, asociados a queries y reportes en servidores y discos que no son utilizados por sistemas de proceso de transacciones.

Muchas de las empresas quieren instalar sistemas de procesos de transacciones para que haya una alta probabilidad de que las transacciones sean completadas en un tiempo razonable. Estos sistemas de procesos de transacciones hacen que las transacciones y peticiones sean más rápidas en menores tiempos dado a que los queries y reportes consumen mucho más de su límite permitido en los recursos de servidores y discos, por tal motivo las empresas han implementado una arquitectura de Data WareHouse que utiliza sus servidores y discos por separado para algunos de los queries y reportes.



Para utilizar modelos de datos o tecnologías de servidores que agilizan los queries y reportes, y que no son apropiados para los procesos de transacciones.

Existen maneras de modelar los datos que usualmente agilizan los queries y reportes (ejemplo: el esquema del modelo estrella) y que no son apropiados para los procesos de transacciones porque la técnica de modelado bajaría el rendimiento y complicaría el proceso de transacciones. También existen tecnologías que aceleran el proceso de queries y reportes pero baja la velocidad en el proceso de transacciones (ejemplo: la indexación de bitmaps) y tecnología de servidores que incrementan la velocidad en el proceso de transacciones, pero que disminuyen la velocidad del proceso de queries y reportes (ejemplo: La tecnología de recuperación de transacciones). Todo esto entonces esta en el cómo se hacen los modelos de datos y que tecnología se utiliza, inclusive que productos se adquieren para el impacto de los procesos de queries y reportes.

Para proveer un ambiente donde relativamente una muy poca cantidad de conocimiento de los aspectos técnicos de tecnología de bases de datos es requerida para escribir y mantener queries y reportes.

Frecuentemente un Data WareHouse puede ser instalado de manera que los queries y reportes puedan ser escritos por personal sin tanto conocimiento técnico, lo que hace que su mantenimiento y construcción se haga sin más complejidad.

Para proveer un repositorio del sistema de proceso de transacciones limpio que puede ser reportado y que no necesariamente requiere que se arregle el sistema de proceso de transacciones.

El Data WareHouse provee la oportunidad de limpiar los datos sin cambiar los sistemas de proceso de transacciones, sin embargo algunas implementaciones de Data WareHouse provee el significado para capturar las correcciones hechas a los datos del Data WareHouse y alimenta las correcciones hacia el sistema de proceso de transacciones. Muchas veces hace más sentido hacer las correcciones de esta manera que aplicar las correcciones directamente al sistema de proceso de transacciones.

Para hacer los queries y reportes de datos básicamente más fácil de los múltiples procesos de transacciones y de las fuentes externas y de los datos que deben ser almacenados solamente para el propósito de hacer queries y reportes.

Desde hace mucho tiempo que las compañías necesitan reportes con información de múltiples sistemas y han hecho extracciones de datos para después correrlos bajo la lógica de búsqueda combinando la información de las extracciones con los reportes generados, lo que en muchas ocasiones es una buena estrategia. Pero cuando se tienen muchos datos y las búsquedas se vuelven muy pesadas y después limpiar la búsqueda, entonces lo apropiado sería un Data WareHouse.



En esencia la creación de un DataWareHouse representa en la mayoría de las ocasiones el primer paso, desde el punto de vista técnico, para implantar una solución completa y fiable de Business Intelligence.

Una de las claves del éxito en la construcción de un DataWareHouse es el desarrollo de forma gradual, seleccionando a un departamento usuario como piloto y expandiendo progresivamente el almacén de datos a los demás usuarios. Por ello es importante elegir este usuario inicial o piloto, siendo importante que sea un departamento con pocos usuarios, en el que la necesidad de este tipo de sistemas es muy alta y se pueda obtener y medir resultados a corto plazo.

La ventaja principal de este tipo de bases de datos radica en las estructuras en las que se almacena la información (modelos de tablas en estrella, en copo de nieve, cubos relacionales, etc.). Este tipo de persistencia de la información es homogénea y fiable, y permite la consulta y el tratamiento jerarquizado de la misma (siempre en un entorno diferente a los sistemas operacionales).



CARACTERÍSTICAS

No volátil: el almacén de información de un data warehouse existe para ser leído, pero no modificado. La información es por tanto permanente, significando la actualización del data warehouse la incorporación de los últimos valores que tomaron las distintas variables contenidas en él sin ningún tipo de acción sobre lo que ya existía.

Integrado: los datos almacenados en el data warehouse deben integrarse en una estructura consistente, por lo que las inconsistencias existentes entre los diversos sistemas operacionales deben ser eliminadas. La información suele estructurarse también en distintos niveles de detalle para adecuarse a las distintas necesidades de los usuarios.

Temático: sólo los datos necesarios para el proceso de generación del conocimiento del negocio se integran desde el entorno operacional. Los datos se organizan por temas para facilitar su acceso y entendimiento por parte de los usuarios finales. Por ejemplo, todos los datos sobre clientes pueden ser



consolidados en una única tabla del data warehouse. De esta forma, las peticiones de información sobre clientes serán más fáciles de responder dado que toda la información reside en el mismo lugar.

Histórico: el tiempo es parte implícita de la información contenida en un data warehouse. En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente. Por el contrario, la información almacenada en el data warehouse sirve, entre otras cosas, para realizar análisis de tendencias. Por lo tanto, el data warehouse se carga con los distintos valores que toma una variable en el tiempo para permitir comparaciones. Otra característica del data warehouse es que contiene metadatos, es decir, datos sobre los datos. Los metadatos permiten saber la procedencia de la información, su periodicidad de refresco, su fiabilidad, forma de cálculo... etc. Los metadatos serán los que permiten simplificar y automatizar la obtención de la información desde los sistemas operacionales a los sistemas informacionales.

Para comprender íntegramente el concepto de data warehouse, es importante entender cuál es el proceso de construcción del mismo, denominado ETL (Extracción, Transformación y Carga), a partir de los sistemas operacionales de una compañía:



Extracción: obtención de información de las distintas fuentes tanto internas como externas.

Transformación: filtrado, limpieza, depuración, homogenización y agrupación de la información.

Carga: organización y actualización de los datos y los metadatos en la base de datos.

PRINCIPALES APORTACIONES DE UN DATAWAREHOUSE

a. Proporciona una herramienta para la toma de decisiones en cualquier área funcional, basándose en información integrada y global del negocio.

b. Facilita la aplicación de técnicas estadísticas de análisis y modelización para encontrar relaciones ocultas entre los datos del almacén; obteniendo un valor añadido para el negocio de dicha información.

c. Proporciona la capacidad de aprender de los datos del pasado y de predecir situaciones futuras en diversos escenarios.

d. Simplifica dentro de la empresa la implantación de sistemas de gestión integral de la relación con el cliente.

e. Supone una optimización tecnológica y económica en entornos de Centro de Información, estadística o de generación de informes con retornos de la inversión espectaculares.

f. Integrar datos de múltiples sistemas de origen, lo que permite una vista central de toda la empresa. Este beneficio es siempre valiosa, pero especialmente cuando la organización ha crecido por la fusión.

g. Mejorar la calidad de los datos, al proporcionar los códigos y descripciones consistentes, marcar o incluso la fijación de los datos erróneos.

h. Presentar la información de la organización constantemente.

i. Proporcionar un único modelo de datos común para todos los datos de interés independientemente de la fuente de los datos.



j. Agregar valor a las aplicaciones de negocio operativo, en particular la gestión de relaciones con clientes (CRM).

Data Mart

Un Data mart es una versión especial de almacén de datos (data warehouse).

Son subconjuntos de datos con el propósito de ayudar a que un área específica

dentro del negocio pueda tomar mejores decisiones. Los datos existentes en este

contexto pueden ser agrupados, explorados y propagados de múltiples formas

para que diversos grupos de usuarios realicen la explotación de los mismos de la

forma más conveniente según sus necesidades.

El Data mart es un sistema orientado a la consulta, en el que se producen

procesos batch de carga de datos (altas) con una frecuencia baja y conocida. Es

consultado mediante herramientas OLAP (On line Analytical Processing -

Procesamiento Analítico en Línea) que ofrecen una visión multidimensional de la

información. Sobre estas bases de datos se pueden construir EIS (Executive

Information Systems, Sistemas de Información para Directivos) y DSS (Decision

Support Systems, Sistemas de Ayuda a la toma de Decisiones). Por otra parte, se

conoce como Data Mining al proceso no trivial de análisis de grandes cantidades

de datos con el objetivo de extraer información útil, por ejemplo para realizar

clasificaciones o predicciones.



En síntesis, se puede decir que los data marts son pequeños data

warehouse centrados en un tema o un área de negocio específico dentro de una

organización.

Dependencia de un data mart

Según la tendencia marcada por Inmon sobre los data warehouse, un data mart

dependiente es un subconjunto lógico (vista) o un subconjunto físico (extracto) de

un almacén de datos más grande, que se ha aislado por alguna de las siguientes

razones:

Se necesita para un esquema o modelo de datos espacial (por ejemplo, para

reestructurar los datos para alguna herramienta OLAP).

Prestaciones: Para descargar el data mart a un ordenador independiente para

mejorar la eficiencia o para obviar las necesidades de gestionar todo el

volumen del data warehouse centralizado.

Seguridad: Para separar un subconjunto de datos de forma selectiva a los que

queremos permitir o restringir el acceso.

Conveniencia: la de poder pasar por alto las autorizaciones y requerimientos

necesarios para poder incorporar una nueva aplicación en el Data Warehouse

principal de la Empresa.

Demostración sobre el terreno: para demostrar la viabilidad y el potencial de

una aplicación antes de migrarla al Data Warehouse de la Empresa.

Política: Cuando se decide una estrategia para las TI (Tecnologías de la

información) en situaciones en las que un grupo de usuarios tiene más

influencia, para determinar si se financia dicha estrategia o descubrir si ésta no

sería buena para el almacén de datos centralizado.

Política: Estrategia para los consumidores de los datos en situaciones en las

que un equipo de almacén de datos no está en condiciones de crear un

almacén de datos utilizable.

Según la escuela Inmon de data warehouse, entre las pérdidas inherentes al uso

de data marts están la escalabilidad limitada, la duplicación de datos, la

inconsistencia de los datos con respecto a otros almacenes de información y la

incapacidad para aprovechar las fuentes de datos de la empresa. Así y todo estas

herramientas son de gran importancia.



Conceptos erróneos de los Data Marts

Al hablar de los data marts, es inevitable la comparación con los data warehouse y

al final se acaba diciendo (o entendiendo) que son como estos, pero en pequeño,

y en cierto modo esto es así, pero esta idea suele hacer caer en los siguientes

errores sobre la implementación y funcionamiento de los data marts:

Son más simples de implementar que un Data Warehouse: FALSO, la

implementación es muy similar, ya que debe proporcionar las mismas

funcionalidades.

Son pequeños conjuntos de datos y, en consecuencia, tienen menor necesidad

de recursos: FALSO, una aplicación corriendo sobre un data mart necesita los

mismos recursos que si corriera sobre un data warehouse.

Las consultas son más rápidas, dado el menor volumen de datos: FALSO, el

menor volumen de datos se debe a que no se tienen todos los datos de toda la

empresa, pero sí se tienen todos los datos de un determinado sector de la

empresa, por lo que una consulta sobre dicho sector tarda lo mismo si se hace

sobre el data mart que si se hace sobre el data warehouse.

En algunos casos añade tiempo al proceso de actualización: FALSO,

actualizar el data mart desde el data warehouse cuesta menos (ya que los

formatos de los datos son o suelen ser idénticos) que actualizar el data

warehouse desde sus fuentes de datos primarias, donde es necesario realizar

operaciones de transformación (ver ETL).

DATA WAREHOUSE VS. DATA MART

La duplicación en otro entorno de datos es un término que suele ser mal interpretado e incomprendido. Así es usado por los fabricantes de SGBD en el sentido de simple réplica de los datos de un sistema operacional centralizado en sistemas distribuidos. En un contexto de Data Warehouse, el término duplicación se refiere a la creación de Data Marts locales o departamentales basados en subconjuntos de la información contenida en el Data Warehouse central o maestro.

Según define Meta Group, "un Data Mart es una aplicación de Data Warehouse, construida rápidamente para soportar una línea de negocio simple". Los Data Marts, tienen las mismas características de integración, no volatilidad, orientación



temática y no volatilidad que el Data Warehouse. Representan una estrategia de "divide y vencerás" para ámbitos muy genéricos de un Data Warehouse.

Esta estrategia es particularmente apropiada cuando el Data Warehouse central crece muy rápidamente y los distintos departamentos requieren sólo una pequeña porción de los datos contenidos en él. La creación de estos Data Marts requiere algo más que una simple réplica de los datos: se necesitarán tanto la segmentación como algunos métodos adicionales de consolidación.

La primera aproximación a una arquitectura descentralizada de Data Mart, podría ser venir originada de una situación como la descrita a continuación.

El departamento de Marketing, emprende el primer proyecto de Data Warehouse como una solución departamental, creando el primer Data Mart de la empresa.

Visto el éxito del proyecto, otros departamentos, como el de Riesgos, o el Financiero se lanzan a crear sus Data Marts. Marketing, comienza a usar otros datos que también usan los Data Marts de Riesgos y Financiero, y estos hacen lo propio.

Esto parece ser una decisión normal, puesto que las necesidades de información de todos los Data Marts crecen conforme el tiempo avanza. Cuando esta situación evoluciona, el esquema general de integración entre los Data Marts pasa a ser, la del gráfico de la derecha.

En esta situación, es fácil observar cómo este esquema de integración de información de los Data Marts, pasa a convertirse en un rompecabezas en el que la gestión se ha complicado hasta convertir esta ansia de información en un auténtico quebradero de cabeza. No obstante, lo que ha fallado no es la integración de Data Marts, sino su forma de integración.



En efecto, un enfoque más adecuado sería la coordinación de la gestión de información de todos los Data Marts en un Data Warehouse centralizado.

En esta situación los Data Marts obtendrían la información necesaria, ya previamente cargada y depurada en el Data Warehouse corporativo, simplificando el crecimiento de una base de conocimientos a nivel de toda la empresa.

Esta simplificación provendría de la centralización de las labores de gestión de los Data Marts, en el Data Warehouse corporativo, generando economías de escala en la gestión de los Data Marts implicados.

Según un estudio de IDC (International Data Corporation) tras analizar 541 empresas, la distribución de las implantaciones de Data Warehouse y Data Marts en la actualidad, y sus opiniones respecto a esta distribución en el futuro, nos muestra los siguientes datos:

En la gráfica, observamos, cómo en la actualidad, de las empresas consultadas, un 80% de ellas cuentan con implantaciones de Data Warehouse o Data Marts.



La proporción actual de implantaciones de Data Warehouse es casi el doble que el de Data Mart.

No obstante, seguramente tras la andadura inicial de alguno de estos proyectos de Data Mart, se ve como más adecuado para el futuro este enfoque "divide y vencerás", previéndose una inversión de estos papeles y duplicando la implantación de Data Marts a los Data Warehouse.

Probablemente, el 5% de usuarios que disponen de tecnología de Data Warehouse y piensan renunciar a ella en el futuro, no han realizado previamente un estudio de factores implicados en un Data Warehouse, o han pasado por la situación inicial de partida, y no se han planteado una reorganización del mismo.



OLTP

OLTP (On Line Transaction Processing) es un tipo de procesamiento de transacciones a través de una red de computadoras. Algunos tipos de aplicaciones OLTP pueden ser banca electrónica, procesamiento de pedidos o comercio electrónico. Es un programa que facilita y administra aplicaciones transaccionales, usualmente para data entry y transacciones en empresas, incluyendo bancos, aerolíneas, etc. Los nuevos paquetes de Software para OLTP se basa en la arquitectura cliente-servidor ya que suelen ser utilizados por empresas que no se encuentran 100% en el mismo medio físico, sino expandidas geográficamente.

OLAP

OLAP es el acrónimo en inglés de procesamiento analítico en línea (On-Line Analytical Processing). Es una solución utilizada en el campo de la Inteligencia de Negocios (Business Intelligence), la cual consiste en consultas a estructuras multidimensionales (o Cubos OLAP) que contienen datos resumidos de grandes Bases de Datos o Sistemas Transaccionales (OLTP). Se usa en informes de negocios de ventas, márketing, informes de dirección, minería de datos y áreas similares. La razón de usar OLAP para las consultas es la velocidad de respuesta. Una base de datos relacional almacena entidades en tablas discretas si han sido normalizadas. Esta estructura es buena en un sistema OLTP pero para las complejas consultas multitabla es relativamente lenta. Un modelo mejor para búsquedas, aunque peor desde el punto de vista operativo, es una base de datos multidimensional. La principal característica que potencia a OLAP, es que es lo más rápido a la hora de hacer selects, en contraposición con OLTP que es la mejor opción para INSERTS, UPDATES Y DELETES. Existen algunas clasificaciones entre las implementaciones OLAP. La clasificación está hecha sobre la base de en qué tipo de motor son almacenados los datos: ROLAP es una implementación OLAP que almacena los datos en un motor relacional. Típicamente, los datos son detallados, evitando las agregaciones y las tablas se encuentran normalizadas. Los esquemas más comunes sobre los que se trabaja son estrella ó copo de nieve, aunque es posible trabajar sobre cualquier base de datos relacional. La arquitectura está compuesta por un servidor de banco de datos relacional y el motor OLAP se encuentra en un servidor dedicado. La principal ventaja de esa arquitectura es que permite el análisis de una enorme cantidad de datos. MOLAP es una implementación OLAP que almacena los datos en una base de datos multidimensional. Para optimizar los tiempos de respuesta, el



resumen de la información es usualmente calculado por adelantado. Estos valores precalculados o agregaciones son la base de las guanacias de desempeño de este sistema. Algunos sistemas utilizan técnicas de compresión de datos para disminuir el espacio de almacenamiento en disco debido a los valores precalculados. HOLAP (Hybrid OLAP) almacena algunos datos en un motor relacional y otros en una base de datos multidimensional DOLAP es un OLAP orientado a equipos de escritorio (Desktop OLAP). Trae toda la información que necesita analizar desde la base de datos relacional y la guarda en el escritorio. Desde ese momento, todas las consultas y análisis son hechas contra los datos guardados en el escritorio.

El análisis multidimensional

Un principio clave del OLAP es que los usuarios deberán obtener tiempos de

respuesta consistentes para cada visita de datos que requieran. Dado que la

información se colecta en el nivel de detalle solamente, el resumen de la

información es usualmente calculado por adelantado. Estos valores pre

calculados son la base de las ganancias del desempeño del OLAP.

Los sistemas OLAP (procesamiento analítico en línea) incorporan tres criterios

con alto nivel de eficiencia:

1. Proporcionan un modelo de datos intuitivo y conceptual, para que los

usuarios que no tengan experiencia como analistas puedan comprender y

rápidamente relacionar. Este modelo se llama análisis multidimensional.

2. Son la respuesta para conseguir la experiencia de “información a la

velocidad del pensamiento”. Rápidos tiempos de respuesta permite que los

analistas puedan preguntar y resolver más situaciones en un corto período de

tiempo.

3. Tienen un motor de cálculo robusto para manejar las necesidades de cálculo

especializado que una estructura multidimensional impone.



La potencia de OLAP proviene de la forma en que los datos estructurados

están alineados, en la forma en la que las personas de forma natural hacemos

análisis.

Los cubos, las dimensiones y las jerarquías son la esencia de la navegación

multidimensional de OLAP. Esta organización, acompañada por una

herramienta de interface para rotar y anidar dimensiones, permite a los

usuarios visualizar rápidamente valores en detalle, patrones, variaciones y

anomalías en los datos que estarían de otra manera ocultos por un análisis

dimensional simple. A mayor número de dimensiones (dentro de los límites

razonables), mayor es la profundidad del análisis.

Herramientas ETL

Cuando hablábamos de Data Warehousing, pasamos por encima de las herramientas ETL, considerándolas un elemento fundamental en la construcción, explotación y evolución de nuestro Data Warehouse (DW).



Esquema Típico de Herramienta ETL

Decíamos que las herramientas ETL, deberían de proporcionar, de forma general, las siguientes funcionalidades:

• Control de la extracción de los datos y su automatización, disminuyendo el tiempo empleado en el descubrimiento de procesos no documentados, minimizando el margen de error y permitiendo mayor flexibilidad.

• Acceso a diferentes tecnologías, haciendo un uso efectivo del hardware, software, datos y recursos humanos existentes.



• Proporcionar la gestión integrada del Data Warehouse y los Data Marts existentes, integrando la extracción, transformación y carga para la construcción del Data Warehouse corporativo y de los Data Marts.

• Uso de la arquitectura de metadatos, facilitando la definición de los objetos de negocio y las reglas de consolidación.

• Acceso a una gran variedad de fuentes de datos diferentes.

• Manejo de excepciones.

• Planificación, logs, interfaces a schedulers de terceros, que nos permitirán llevan una gestión de la planificación de todos los procesos necesarios para la carga del DW.

• Interfaz independiente de hardware.

• Soporte en la explotación del Data Warehouse.

Es hora de ampliar las definiciones y entrar un poco más a fondo en lo que son realmente las ETL´s:

Definición de ETL

Si ampliamos las definiciones, en la Wikipedia se dice lo siguiente de las herramientas ETL:

ETL son las siglas en inglés de Extraer, Transformar y Cargar (Extract, Transform and Load). Es el proceso que permite a las organizaciones mover datos desde múltiples fuentes, reformatearlos y limpiarlos, y cargarlos en otra base de datos, data mart, o data warehouse para analizar, o en otro sistema operacional para apoyar un proceso de negocio.

Los procesos ETL también se pueden utilizar para la integración con sistemas heredados (aplicaciones antiguas existentes en las organizaciones que se han de integrar con los nuevos aplicativos, por ejemplo, ERP´s. La tecnología utilizada en dichas aplicaciones puede hacer difícil la integración con los nuevos programas).

Proceso de Extracción con Software ETL

La primera parte del proceso ETL consiste en extraer los datos desde los sistemas de origen. La mayoría de los proyectos de almacenamiento de datos fusionan datos provenientes de diferentes sistemas de origen. Cada sistema separado puede usar una organización diferente de los datos o formatos distintos. Los formatos de las fuentes normalmente se encuentran en bases de datos relacionales o ficheros planos, pero pueden incluir bases de datos no



relacionales u otras estructuras diferentes. La extracción convierte los datos a un formato preparado para iniciar el proceso de transformación.

Una parte intrínseca del proceso de extracción es la de analizar los datos extraídos, de lo que resulta un chequeo que verifica si los datos cumplen la pauta o estructura que se esperaba. De no ser así los datos son rechazados.

Un requerimiento importante que se debe exigir a la tarea de extracción es que ésta cause un impacto mínimo en el sistema origen. Si los datos a extraer son muchos, el sistema de origen se podría ralentizar e incluso colapsar, provocando que éste no pueda utilizarse con normalidad para su uso cotidiano. Por esta razón, en sistemas grandes las operaciones de extracción suelen programarse en horarios o días donde este impacto sea nulo o mínimo.

Interfaz Gráfico herramienta ETL

Proceso de Transformación con una Herramienta ETL

La fase de transformación de un proceso de ETL aplica una serie de reglas de negocio o funciones sobre los datos extraídos para convertirlos en datos que serán cargados. Algunas fuentes de datos requerirán alguna pequeña manipulación de los datos. No obstante en otros casos pueden ser necesarias aplicar algunas de las siguientes transformaciones:



Seleccionar sólo ciertas columnas para su carga (por ejemplo, que las columnas con valores nulos no se carguen).

Traducir códigos (por ejemplo, si la fuente almacena una “H” para Hombre y “M” para Mujer pero el destino tiene que guardar “1″ para Hombre y “2″ para Mujer).

Codificar valores libres (por ejemplo, convertir “Hombre” en “H” o “Sr” en “1″).

Obtener nuevos valores calculados (por ejemplo, total_venta = cantidad * precio).

Unir datos de múltiples fuentes (por ejemplo, búsquedas, combinaciones, etc.).

Calcular totales de múltiples filas de datos (por ejemplo, ventas totales de cada región).

Generación de campos clave en el destino. Transponer o pivotar (girando múltiples columnas en filas o viceversa). Dividir una columna en varias (por ejemplo, columna “Nombre: García,

Miguel”; pasar a dos columnas “Nombre: Miguel” y “Apellido: García”). La aplicación de cualquier forma, simple o compleja, de validación de

datos, y la consiguiente aplicación de la acción que en cada caso se requiera:

o Datos OK: Entregar datos a la siguiente etapa (Carga). o Datos erróneos: Ejecutar políticas de tratamiento de

excepciones (por ejemplo, rechazar el registro completo, dar al campo erróneo un valor nulo o un valor centinela).

Interfaz Gráfico de la herramienta ETL Kettle - Pentaho



Proceso de Carga con Software de ETL

La fase de carga es el momento en el cual los datos de la fase anterior (transformación) son cargados en el sistema de destino. Dependiendo de los requerimientos de la organización, este proceso puede abarcar una amplia variedad de acciones diferentes. En algunas bases de datos se sobrescribe la información antigua con nuevos datos. Los data warehouse mantienen un historial de los registros de manera que se pueda hacer una auditoría de los mismos y disponer de un rastro de toda la historia de un valor a lo largo del tiempo.

Existen dos formas básicas de desarrollar el proceso de carga:

Acumulación simple: La acumulación simple es la más sencilla y común, y consiste en realizar un resumen de todas las transacciones comprendidas en el período de tiempo seleccionado y transportar el resultado como una única transacción hacia el data warehouse, almacenando un valor calculado que consistirá típicamente en un sumatorio o un promedio de la magnitud considerada.

Rolling: El proceso de Rolling por su parte, se aplica en los casos en que se opta por mantener varios niveles de granularidad. Para ello se almacena información resumida a distintos niveles, correspondientes a distintas agrupaciones de la unidad de tiempo o diferentes niveles jerárquicos en alguna o varias de las dimensiones de la magnitud almacenada (por ejemplo, totales diarios, totales semanales, totales mensuales, etc.).

La fase de carga interactúa directamente con la base de datos de destino. Al realizar esta operación se aplicarán todas las restricciones y triggers (disparadores) que se hayan definido en ésta (por ejemplo, valores únicos, integridad referencial, campos obligatorios, rangos de valores). Estas restricciones y triggers (si están bien definidos) contribuyen a que se garantice la calidad de los datos en el proceso ETL, y deben ser tenidos en cuenta.

Procesamiento en Herramientas ETL

Un desarrollo reciente en el software ETL es la aplicación de procesamiento paralelo. Esto ha permitido desarrollar una serie de métodos para mejorar el rendimiento general de los procesos ETL cuando se trata de grandes volúmenes de datos. Hay 3 tipos principales de paralelismos que se pueden implementar en las aplicaciones ETL:

De datos: Consiste en dividir un único archivo secuencial en pequeños archivos de datos para proporcionar acceso paralelo.



De segmentación (pipeline): Permitir el funcionamiento simultáneo de varios componentes en el mismo flujo de datos. Un ejemplo de ello sería buscar un valor en el registro número 1 a la vez que se suman dos campos en el registro número 2.

De componente: Consiste en el funcionamiento simultáneo de múltiples procesos en diferentes flujos de datos en el mismo puesto de trabajo.

Estos tres tipos de paralelismo no son excluyentes, sino que pueden ser combinados para realizar una misma operación ETL.

Una dificultad adicional es asegurar que los datos que se cargan sean relativamente consistentes. Las múltiples bases de datos de origen tienen diferentes ciclos de actualización (algunas pueden ser actualizadas cada pocos minutos, mientras que otras pueden tardar días o semanas). En un sistema de ETL será necesario que se puedan detener ciertos datos hasta que todas las fuentes estén sincronizadas. Del mismo modo, cuando un almacén de datos tiene que ser actualizado con los contenidos en un sistema de origen, es necesario establecer puntos de sincronización y de actualización.

Desafíos para los procesos y Herramientas de ETL

Los procesos ETL pueden ser muy complejos. Un sistema ETL mal diseñado puede provocar importantes problemas operativos.

En un sistema operacional el rango de valores de los datos o la calidad de éstos pueden no coincidir con las expectativas de los diseñadores a la hora de especificarse las reglas de validación o transformación. Es recomendable realizar un examen completo de la validez de los datos (Data profiling) del sistema de origen durante el análisis para identificar las condiciones necesarias para que los datos puedan ser tratados adecuadamente por las reglas de transformación especificadas. Esto conducirá a una modificación de las reglas de validación implementadas en el proceso ETL.

Normalmente los data warehouse son alimentados de manera asíncrona desde distintas fuentes, que sirven a propósitos muy diferentes. El proceso ETL es clave para lograr que los datos extraídos asíncronamente de orígenes heterogéneos se integren finalmente en un entorno homogéneo.

La escalabilidad de un sistema de ETL durante su vida útil tiene que ser establecida durante el análisis. Esto incluye la comprensión de los volúmenes de datos que tendrán que ser procesados según los acuerdos de nivel de servicio (SLA:Service level agreement). El tiempo disponible para realizar la extracción de los sistemas de origen podría cambiar, lo que implicaría que la misma cantidad de datos tendría que ser procesada en menos tiempo. Algunos sistemas ETL son



escalados para procesar varios terabytes de datos para actualizar un data warehouse que puede contener decenas de terabytes de datos. El aumento de los volúmenes de datos que pueden requerir estos sistemas pueden hacer que los lotes que se procesaban a diario pasen a procesarse en micro-lotes (varios al día) o incluso a la integración con colas de mensajes o a la captura de datos modificados (CDC: change data capture) en tiempo real para una transformación y actualización continua.

Algunas Herramientas ETL

Ab Initio Benetl BITool – ETL Software CloverETL Cognos Decisionstream (IBM) Data Integrator (herramienta de Sap Business Objects) ETI*Extract (ahora llamada Eti Solution) IBM Websphere DataStage (antes Ascential DataStage) Microsoft Integration Services Oracle Warehouse Builder WebFocus-iWay DataMigrator Server Pervasive Informática PowerCenter Oxio Data Intelligence ETL full web SmartDB Workbench Sunopsis (Oracle) SAS Dataflux Sybase Syncsort: DMExpress. Opentext (antes Genio, Hummingbird).

Desafíos

Los procesos ETL pueden ser muy complejos. Un sistema ETL mal diseñado

puede provocar importantes problemas operativos.

En un sistema operacional el rango de valores de los datos o la calidad de

éstos pueden no coincidir con las expectativas de los diseñadores a la hora de



especificarse las reglas de validación o transformación. Es recomendable

realizar un examen completo de la validez de los datos (Data profiling) del

sistema de origen durante el análisis para identificar las condiciones

necesarias para que los datos puedan ser tratados adecuadamente por las

reglas de transformación especificadas. Esto conducirá a una modificación de

las reglas de validación implementadas en el proceso ETL.

Normalmente los data warehouse son alimentados de manera asíncrona

desde distintas fuentes, que sirven a propósitos muy diferentes. El proceso

ETL es clave para lograr que los datos extraídos asíncronamente de orígenes

heterogéneos se integren finalmente en un entorno homogéneo.

La escalabilidad de un sistema de ETL durante su vida útil tiene que ser

establecida durante el análisis. Esto incluye la comprensión de los volúmenes

de datos que tendrán que ser procesados según los acuerdos de nivel de

servicio (SLA: Service level agreement). El tiempo disponible para realizar la

extracción de los sistemas de origen podría cambiar, lo que implicaría que la

misma cantidad de datos tendría que ser procesada en menos tiempo. Algunos

sistemas ETL son escalados para procesar varios terabytes de datos para

actualizar un data warehouse que puede contener decenas de terabytes de

datos. El aumento de los volúmenes de datos que pueden requerir estos

sistemas pueden hacer que los lotes que se procesaban a diario pasen a

procesarse en micro-lotes (varios al día) o incluso a la integración con colas de

mensajes o a la captura de datos modificados (CDC:change data capture) en

tiempo real para una transformación y actualización continua.



Cubo OLAP

Cubo OLAP de tres dimensiones (Ciudades, Productos y Tiempo).

Un cubo OLAP, OnLine Analytical Processing o procesamiento Analítico En

Línea, término acuñado por Edgar Frank Codd de EF Codd & Associates,

encargado por Arbor Software (en la actualidad Hyperion Solutions), es una base

de datos multidimensional, en la cual el almacenamiento físico de los datos se

realiza en un vector multidimensional. Los cubos OLAP se pueden considerar

como una ampliación de las dos dimensiones de una hoja de cálculo.

A menudo se pensaba que todo lo que los usuarios pueden querer de un sistema

de información se podría hacer de una base de datos relacional. No

obstante Codd fue uno de los precursores de las bases de datos relacionales, por

lo que sus opiniones fueron y son respetadas.

La propuesta de Codd consistía en realizar una disposición de los datos

en vectores para permitir un análisis rápido. Estos vectores son llamados cubos.

Disponer los datos en cubos evita una limitación de las bases de datos

relacionales, que no son muy adecuadas para el análisis instantáneo de grandes



cantidades de datos. Las bases de datos relacionales son más adecuadas para

registrar datos provenientes de transacciones (conocido como OLTP o

procesamiento de transacciones en línea). Aunque existen muchas herramientas

de generación de informes para bases de datos relacionales, éstas son lentas

cuando debe explorarse toda la base de datos.

Por ejemplo, una empresa podría analizar algunos datos financieros por producto,

por período, por ciudad, por tipo de ingresos y de gastos, y mediante la

comparación de los datos reales con un presupuesto. Estos parámetros en función

de los cuales se analizan los datos se conocen como dimensiones. Para acceder

a los datos sólo es necesario indexarlos a partir de los valores de las dimensiones

o ejes.

El almacenar físicamente los datos de esta forma tiene sus pros y sus contras. Por

ejemplo, en estas bases de datos las consultas de selección son muy rápidas (de

hecho, casi instantáneas). Pero uno de los problemas más grandes de esta forma

de almacenamiento es que una vez poblada la base de datos ésta no puede

recibir cambios en su estructura. Para ello sería necesario rediseñar el cubo.

En un sistema OLAP puede haber más de tres dimensiones, por lo que a

los cubos OLAP también reciben el nombre de hipercubos. Las herramientas

comerciales OLAP tienen diferentes métodos de creación y vinculación de estos

cubos o hipercubos (véase Tipos de OLAP en el artículo sobre OLAP).

Un ejemplo

Un analista financiero podría querer ver los datos de diversas formas, por ejemplo,

visualizándolos en función de todas las ciudades (que podrían figurar en el eje de

abscisas) y todos los productos (en el eje de ordenadas), y esto podría ser para un

período determinado, para la versión y el tipo de gastos. Después de haber visto

los datos de esta forma particular el analista podría entonces querer ver los datos

de otra manera y poder hacerlo de forma inmediata. El cubo podría adoptar una

nueva orientación para que los datos aparezcan ahora en función de los períodos

y el tipo de coste. Debido a que esta reorientación implica resumir una cantidad

muy grande de datos, esta nueva vista de los datos se debe generar de manera

eficiente para no malgastar el tiempo del analista, es decir, en cuestión de



segundos, en lugar de las horas que serían necesarias en una base de datos

relacional convencional.

Dimensiones y jerarquías

Cada una de las dimensiones de un cubo OLAP puede resumirse mediante una

jerarquía. Por ejemplo si se considera una escala (o dimensión) temporal "Mayo

de 2005" se puede incluir en "Segundo Trimestre de 2005", que a su vez se

incluye en "Año 2005". De igual manera, otra dimensión de un cubo que refleje

una situación geográfica, las ciudades se pueden incluir en regiones, países o

regiones mundiales; los productos podrían clasificarse por categorías, y las

partidas de gastos podrían agruparse en tipos de gastos. En cambio, el analista

podría comenzar en un nivel muy resumido, como por ejemplo el total de la

diferencia entre los resultados reales y lo presupuestado, para posteriormente

descender en el cubo (en sus jerarquías) para poder observar con un mayor nivel

de detalle que le permita descubrir en el cubo los lugares en los que se ha

producido esta diferencia, según los productos y períodos.

Dispersión en cubos OLAP

Vincular o enlazar cubos es un mecanismo para superar la dispersión. Ésta se

produce cuando no todas las celdas del cubo se rellenan con datos (escasez de

datos o valores nulos). El tiempo de procesamiento es tan valioso que se debe

adoptar la manera más efectiva de sumar ceros (los valores nulos o no

existentes). Por ejemplo los ingresos pueden estar disponibles para cada cliente y

producto, pero los datos de los costos pueden no estar disponibles con esta

cantidad de análisis. En lugar de crear un cubo disperso, a veces es mejor crear

otro cubo distinto, pero vinculado, en el que un subconjunto de los datos se puede



analizar con gran detalle. La vinculación asegura que los datos de los dos cubos

mantengan una coherencia.

Acceso y cálculo de un cubo OLAP

Los datos de los cubos pueden ser actualizados de vez en cuando, tal vez por

personas diferentes de forma concurrente. Para solventar este problema a

menudo es necesario bloquear partes de un cubo mientras otro usuario está

escribiendo, para volver a calcular los totales en el cubo. Otras implementaciones

añaden la posibilidad de mostrar una alerta que indique que los totales calculados

previamente ya no son válidos tras los nuevos datos. También hay algunos

productos que calculan los totales cuando se les necesita con los últimos datos

producidos en el sistema.

Definición técnica

En teoría de bases de datos, un cubo OLAP es una representación abstracta de

la proyección de una relación de un RDBMS (Sistema administrador de bases de

datos relacionales). Dada una relación de orden N, se considera la posibilidad de

una proyección que dispone de los campos X, Y, Z como clave de la relación y

de W como atributo residual. Categorizando esto como una función se tiene que:

W : (X,Y,Z) → W

Los atributos X, Y, Z se corresponden con los ejes del cubo, mientras que el

valor de W devuelto por cada tripleta (X, Y, Z) se corresponde con el dato o

elemento que se rellena en cada celda del cubo.

Debido a que los dispositivos de salida (monitores, impresoras, ...) sólo

cuentan con dos dimensiones, no pueden caracterizar fácilmente cuatro

dimensiones, es más práctico proyectar "rebanadas" o secciones de los datos

del cubo (se dice proyectar en el sentido clásico vector analítico de reducción

dimensional, no en el sentido de SQL, aunque los dos conceptos son

claramente análogos), tales como la expresión:

W : (X,Y) → W

Aunque no se conserve la clave del cubo (al faltar el parámetro Z), puede

tener algún significado semántico, sin embargo, también puede que una



sección de la representación funcional con tres parámetros para un

determinado valor de Z también resulte de interés.

La motivación que hay tras OLAP vuelve a mostrar de nuevo el paradigma

de los informes de tablas cruzadas de los sistemas de gestión de base de

datos de los 80. Se puede desear una visualización al estilo de una hoja de

cálculo, donde los valores de X se encuentran en la fila $1, los valores

de Y aparecen en la columna $A, y los valores de W: (X, Y) → W se

encuentran en las celdas individuales a partir de la celda $B2 y desde ahí,

hacia abajo y hacia la derecha. Si bien se puede utilizar el Lenguaje de

Manipulación de Datos (o DML) de SQL para mostrar las tuplas (X,Y,W),

este formato de salida no es tan deseable como la alternativa de tablas

cruzadas. El primer método requiere que se realice una búsqueda lineal

para cada par (X,Y) dado, para determinar el correspondiente valor de W,

mientras que el segundo permite realizar una búsqueda más

convenientemente permitiendo localizar el valor W en la intersección de la

columna X apropiada con la fila Y correspondiente.

Se ha desarrollado el lenguaje MDX (MultiDimensional

eXpressions o expresiones multidimensionales) para poder expresar

problemas OLAP de forma fácil. Aunque es posible traducir algunas sus

sentencias a SQL tradicional, con frecuencia se requieren expresiones SQL

poco claras incluso para las sentencias más simples del MDX. Este

lenguaje ha sido acogido por la gran mayoría de los proveedores de OLAP

y se ha convertido en norma de hecho para estos sistemas.

La razón de usar OLAP para las consultas es la rapidez de respuesta. Una base

de datos relacional almacena entidades en tablas discretas si han sido

normalizadas. Esta estructura es buena en un sistema OLTP pero para las

complejas consultas multitabla es relativamente lenta. Un modelo mejor para

búsquedas (aunque peor desde el punto de vista operativo) es una base de datos

multidimensional.

La principal característica que potencia a OLAP, es que es lo más rápido a la hora

de ejecutar sentencias SQL de tipo SELECT, en contraposición con OLTP que es

la mejor opción para operaciones de tipo INSERT, UPDATE Y DELETE



Funcionalidad

En la base de cualquier sistema OLAP se encuentra el concepto de cubo

OLAP (también llamado cubo multidimensional o hipercubo). Se compone de

hechos numéricos llamados medidas que se clasifican por dimensiones. El cubo

de metadatos es típicamente creado a partir de un esquema en estrella o copo de

nieve, esquema de las tablas en una base de datos relacional. Las medidas se

obtienen de los registros de una tabla de hechos y las dimensiones se derivan de

la dimensión de los cuadros.

Tipos de sistemas OLAP

Tradicionalmente, los sistemas OLAP se clasifican según las siguientes

categorías:

ROLAP

Implementación OLAP que almacena los datos en un motor relacional.

Típicamente, los datos son detallados, evitando las agregaciones y las tablas se

encuentran desnormalizadas Los esquemas más comunes sobre los que se

trabaja son estrella ó copo de nieve, aunque es posible trabajar sobre cualquier

base de datos relacional. La arquitectura está compuesta por un servidor de banco

de datos relacional y el motor OLAP se encuentra en un servidor dedicado. La

principal ventaja de esta arquitectura es que permite el análisis de una enorme

cantidad de datos.



MOLAP

Esta implementación OLAP almacena los datos en una base de datos

multidimensional. Para optimizar los tiempos de respuesta, el resumen de la

información es usualmente calculado por adelantado. Estos valores precalculados

o agregaciones son la base de las ganancias de desempeño de este sistema.

Algunos sistemas utilizan técnicas de compresión de datos para disminuir el

espacio de almacenamiento en disco debido a los valores precalculados.

HOLAP (Hybrid OLAP)

Almacena algunos datos en un motor relacional y otros en una base de datos

multidimensional.

Comparación

Cada sistema OLAP tiene ciertos beneficios (aunque existe desacuerdo acerca de

las características específicas de los beneficios entre los proveedores).

Algunas implementaciones MOLAP son propensas a la "explosión" de la base de

datos; este fenómeno provoca la necesidad de grandes cantidades de espacio de

almacenamiento para el uso de una base de datos MOLAP cuando se dan ciertas

condiciones: elevado número de dimensiones, resultados precalculados y escasos

datos multidimensionales. Las técnicas habituales de atenuación de la explosión

de la base de datos no son todo lo eficientes que sería deseable.

Por lo general MOLAP ofrece mejor rendimiento debido a la especializada

indexación y a las optimizaciones de almacenamiento. MOLAP también necesita

menos espacio de almacenamiento en comparación con los

especializados ROLAP porque su almacenamiento especializado normalmente

incluye técnicas de compresión.

ROLAP es generalmente más escalable. Sin embargo, el gran volumen de

preprocesamiento es difícil de implementar eficientemente por lo que con

frecuencia se omite; por tanto, el rendimiento de una consulta ROLAP puede verse

afectado.

Desde la aparición de ROLAP van apareciendo nuevas versiones de bases de

datos preparadas para realizar cálculos, las funciones especializadas que se

pueden utilizar tienen más limitaciones.



HOLAP (OLAP Híbrido) engloba un conjunto de técnicas que tratan de

combinar MOLAP y ROLAP de la mejor forma posible. Generalmente puede pre-

procesar rápidamente, escala bien, y proporciona una buena función de apoyo.

Otros tipos

Los siguientes acrónimos a veces también se utilizan, aunque no son sistemas tan

generalizados como los anteriores:

WOLAP o Web OLAP: OLAP basado u orientado para la web.

DOLAP o Desktop OLAP: OLAP de escritorio

RTOLAP o Real Time OLAP: OLAP en tiempo real

SOLAP o Spatial OLAP: OLAP espacial

A menudo se pensaba que todo lo que los usuarios pueden querer de un sistema

de información se podría hacer de una base de datos relacional. No

obstante Codd fue uno de los precursores de las bases de datos relacionales, por

lo que sus opiniones fueron y son respetadas.

Diseño en copo de nieve de un Cubo OLAP

La propuesta de Codd consistía en realizar una disposición de los datos en

vectores para permitir un análisis rápido. Estos vectores son llamados cubos.



Disponer los datos en cubos evita una limitación de las bases de datos

relacionales, que no son muy adecuadas para el análisis instantáneo de grandes

cantidades de datos.

Las bases de datos relacionales son más adecuadas para registrar datos

provenientes de transacciones (conocido como OLTP o procesamiento de

transacciones en línea). Aunque existen muchas herramientas de generación de

informes para bases de datos relacionales, éstas son lentas cuando debe

explorarse toda la base de datos. Por ejemplo, una empresa podría analizar

algunos datos financieros por producto, por período, por ciudad, por tipo de

ingresos y de gastos, y mediante la comparación de los datos reales con un

presupuesto. Estos parámetros en función de los cuales se analizan los datos se

conocen como dimensiones.

Para acceder a los datos sólo es necesario indexarlos a partir de los valores de las

dimensiones o ejes. El almacenar físicamente los datos de esta forma tiene sus

pros y sus contras. Por ejemplo, en estas bases de datos las consultas de

selección son muy rápidas (de hecho, casi instantáneas). Pero uno de los

problemas más grandes de esta forma de almacenamiento es que una vez

poblada la base de datos ésta no puede recibir cambios en su estructura. Para ello

sería necesario rediseñar el cubo.



En un sistema OLAP puede haber más de tres dimensiones, por lo que a los

cubos OLAP también reciben el nombre de hipercubos. Las herramientas

comerciales OLAP tienen diferentes métodos de creación y vinculación de estos

cubos o hipercubos (véase Tipos de OLAP en el artículo sobre OLAP).

La principal característica que potencia a OLAP, es que es lo más rápido a la hora

de ejecutar sentencias SQL de tipo SELECT, en contraposición con OLTP que es

la mejor opción para operaciones de tipo INSERT, UPDATE Y DELETE.

Cubos Virtuales

Usted puede juntar cubos, dentro de cubos virtuales, muy parecido al proceso de juntar tablas con vistas en las bases de datos relacionales. Un cubo virtual, provee acceso a los datos en los cubos combinados, si la necesidad de construir un nuevo cubo, mientras permite que se mantenga en mejor diseño en cada cubo individual. Un cubo podrá ser actualizado, procesando solo los datos que han sido añadidos,



en vez de hacerlo con el cubo entero, se puede usar la actualización incremental para actualizar un cubo mientras se esté usando.

Agregaciones Así se le llama al proceso de precalcular sumas de datos, para ayudar a disminuir los tiempos de respuestas, en los procesos de búsquedas de información.

Seguridad Usando las facilidades de seguridad manejadas por Microsoft SQL Server OLAP services, usted puede controlar quien accesa los datos y los tipos de operaciones que los usuarios pueden ejecutar con los datos. OLAP services soporta el sistema de seguridad integrado que ofrece el sistema operativo Windows NT y permite que usted asigne permisos de acceso, a la base de datos y al cubo incluyendo a los cubos virtuales.

La seguridad es manejada vía los derechos de control de acceso que son manejados por los Roles, estos determinan el tipo de acceso a los datos. Los Roles definen, categorías de usuarios con los mismos controles de acceso.

Modos de Almacenaje

En esta ocasión se muestra un pequeño tutorial para hacer la transformación de una Base de datos Transaccional a un Cubo para análisis OLAP. Un cubo es una unidad de consulta multimensional, el problema que resuelvo consiste en construir el cubo a partir de la base de datos transaccional de ejemplo usando SQL Server. El proceso consiste en tres pasos: Ubicar la tabla Fact o tabla que incluya todos los requerimientos, a continuación se debe modificar las relaciones de la base de datos y finalmente, cargar los datos en la nueva relación o Cubo OLTP.

El archivo de inicio y la solución se pueden descargar a continuación. Para revisar el ejemplo necesita SQL Server 2008 estándar o mayor.



Empecemos: Paso 1:

Observe el esquema de la base de datos transaccional. Aprecie las relaciones de la base de datos de nombre OLTP_Ventas.

Note que la tabla candidato a FACT es Matrícula porque relaciona las dimensiones Cliente, Producto, Empleado, etc.

Paso 2:

Empezaremos haciendo la estructura del cubo. Borre las relaciones de las tablas.



Paso 3:

Seleccionar las tablas que harán la composición de las dimensiones del cubo. En este ejemplo se debe seleccionar Pedido, Cliente, Producto, Empleado y Proveedor. Luego renombre la tabla Pedido como Fact_Pedido y para el resto de tablas usar el prefijo Dim (Dimensión) por ejemplo: Dim_Cliente, Dim_Producto, Dim_Categoría, así en lo sucesivo.

Paso 4:



Crear la tabla Dim_Tiempo. La tabla dimensión tiempo es fundamental en todo cubo y organiza el resto de dimensiones en función del tiempo. CREATE TABLE [dbo].[Dim_tiempo]( [idTiempo] [smalldatetime] NOT NULL, [dia] [int] NULL, [mes] [int] NULL, [anio] [int] NULL, CONSTRAINT [PK_Dim_tiempo] PRIMARY KEY CLUSTERED ( [idTiempo] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]

Paso 5:

Agregue "Claves Primarias" en la tabla Fact_Pedido (que es la tabla central del cubo) con el objetivo de unir las entidades Cliente, Producto, Empleado y Proveedor en la tabla Fact_Pedido.

En este ejemplo se agrega los siguientes campos:

IdProducto IdProveedor También debe agregar "Campos de Métrica" o que guardan cálculos (Totales, subtotals). Para este ejemplo agregaremos:

Cantidad (int), Descuento (int), Subtotal (Money)



Cambie el nombre del campo Fact_Pedido.Fecha_pedido por Fact_Pedido.IdTiempo y asocie el campo a Dim_Tiempo. Finalmente, Elimine campo Fact_Pedido.Fecha_entrega porque las fechas son innecesarias en esta tabla.

Ya casi tenemos el cubo.

Paso 6:

Para que el cubo se complete es necesario cargar datos a las tablas o dimensiones. Es importante notar que los nuevos campos recién creados: IdProducto, IdProveedor, Cantidad y Subtotal recién agregados a la tabla Fact_Pedido no tienen valores o son NULL. Note que Subtotal es un caso especial, porque es producto del cálculo de Cantidad * Precio. Ud. debe imaginar una manera práctica para cargar datos.

En este ejemplo vamos usar una consulta SQL para completar datos que faltan en la tabla Fact_Pedido y Dim_detalle_pedido calculando Cantidad * Precio y el resto de claves que falta asignar. SELECT dbo.Fact_Pedido.NroPed, dbo.Dim_Producto.IdProducto, dbo.Dim_Producto.IdProveedor, dbo.Fact_Pedido.idTiempo, dbo.Fact_Pedido.Id_Cliente, dbo.Fact_Pedido.IdEmpleado, dbo.Dim_Detalle_pedido.Cantidad, dbo.Dim_Detalle_pedido.Descuento, dbo.Dim_Detalle_pedido.Cantidad * dbo.Dim_Producto.PrecioUnit AS Subtotal FROM dbo.Fact_Pedido INNER JOIN dbo.Dim_Detalle_pedido ON dbo.Fact_Pedido.NroPed = dbo.Dim_Detalle_pedido.NroPedido INNER JOIN dbo.Dim_Producto ON dbo.Dim_Detalle_pedido.IdProducto = dbo.Dim_Producto.IdProducto



Guarde esta salida de la consulta en un archivo de texto. Servirá a posterior para llenar la tabla Fact_Pedido:

1 3425 C002 2007-01-25 00:00:00.000 D004 D06 100 15 20,0000 2 4564 C001 2007-05-13 00:00:00.000 F006 C05 15 11 225,0000 3 2345 C001 2007-08-24 00:00:00.000 C003 A02 45 19 202,5000 3 7845 C003 2007-08-24 00:00:00.000 C003 A02 60 15 180,0000 Paso 7:

Borre los registros (filas) de la tabla Fact_Pedido. Edite Fact_Pedido quitando "Clave Primaria" de NroPed. Registre estas nuevas columnas como Clave Primaria:

IdProducto IdProveedor idTiempo Id_Cliente IdEmpleado La tabla debería quedar así:



Importante: Solo se debe conservar Llaves Primarias y Campos creados con objetivo de guardar resultado de cálculos en la tabla Fact_Pedido. Paso 8:

Ahora toca cargar los datos desde el archivo de texto descrito en Paso 6 sobre la tabla Fact_Pedido. La tabla se llenará, ya no da lugar a campos nulos.

Paso 9:

Cargar los datos para la tabla Dim_Tiempo. Los datos de Dim_Tiempo son el resultado de Fact_Pedido.IdTiempo, por tanto, usaremos esta consulta para extraer los datos:



SELECT DISTINCT idTiempo, DAY(idTiempo) AS dia, MONTH(idTiempo) AS mes, YEAR(idTiempo) AS anio FROM dbo.Fact_Pedido

Paso 10:

Finamente (ahora sí...) relacionar Fact_Pedido con el resto de tablas o dimensiones usando las relaciones. Debería quedar así:



El 'cubo' está listo.

Es hora de hacer consultas al cubo

Pasos para extraer información del cubo OLAP en Analysis Services y SQL Server Business Intelligence Development Studio Descomprima en una ubicación sencilla el archivo *.bak, compruebe que tiene instalado en el servidor y equipo cliente Analysis Services y SQL Server Business Intelligence Development Studio. De ser correcto siga las instrucciones: Paso 1:

Conectarse al Motor de base de datos y restaure la base de datos



NorthWind_OLAP. Mire el diagrama de relaciones. En el ejemplo, la base de datos tiene 5 dimensiones y Sales_Fact es la tabla central.

Paso 2:

Abrir SQL Server Business Intelligence Development Studio. Use la opción para crear una Nueva base de datos. En "Nombre de la base de datos" Escriba Northwind_Mart y configure el modo de suplantación. Para el ejemplo se usará "Utilizar las credenciales del usuario actual"



Listo. Las bases para las consultas fueron realizadas con éxito.

Paso 3:

En Visual Studio crear una nueva solución para Bussiness Intelligence y conectar con la base de datos Northwind_Mart. Siga las instrucciones del asistente.



Paso 4:

Como resultado del paso anterior obtenemos un esquema de la base de datos. Es necesario definir las dimensiones. En el Explorador de soluciones encontrar el nodo Dimensiones y crear una nueva dimension usando el menú contextual en el nodo.

Seleccionar los elementos o campos que estarán presentes en las dimensiones.

Seleccionar la tabla que será el centro de las combinaciones o que tiene las medidas. Para el ejemplo seleccionamos Sales_Fact.



Seguir agregando las dimensiones hasta completar todo el esquema de base de datos.

Paso 5:

Terminada la configuración de dimensiones es necesario procesar el cubo. En el nodo Cubo del Explorador de soluciones usar el menú contextual para iniciar la comprobación.



"Procesar Cubo" verifica si la configuración de la base de datos Northwind_OLAP es adecuada para las consultas de cubo. Si aparece un error, reconfigurar el cubo usando las descripciones de error que aparecen en el log.

Paso 6

Si el paso 6 terminó con éxito, solo queda conectar al cubo para obtener el resultado de la consulta.

En las pestaña Examinador arrastrar las dimensiones al espacio de consulta y ver el resultado.



La calidad de la información recibida dependerá del manejo de las dimensiones y del correcto diseño del cubo.

Creando una Dimensión de tiempo en SQL Server Analysis Services

Si queremos comenzar a crear un cubo para análisis de datos en SQL Server Analysis Services (SSAS) versiones 2005, 2008 y 2008 R2, en lo primero que debemos pensar es en la dimensión de tiempo. Y es que no tiene sentido crear un cubo para analizar nuestras ventas, inventario, datos de salud, o cualquier otro hecho, sin tener la perspectiva del tiempo que le dé sentido a dichos datos.

Una dimensión de tiempo define además la granularidad en que nuestros datos en las tablas de hechos han sido generados, ya sea a nivel de año, semestre, trimestre, mes, día, hora, minuto, segundo, por nombrar algunas escalas. Si bien es cierto que a pesar de que nuestros datos en las tablas de hechos estén guardados a un nivel granular de tiempo en específico, por decir ventas a nivel de mes, ventas a nivel de día, etc.; es una buena práctica crear una dimensión de tiempo que incluya todos los niveles de granularidad que podrían usarse no sólo en las tablas de hechos (fact tables) que se vayan a crear ahora requieran, sino también las que se puedan tener a lo largo de la vida de nuestra solución. Por tanto es recomendable por lo menos crear una dimensión de tiempo con los niveles: año>semestre>trimestre>mes>día.

En otro caso, si la industria en la que estén trabajando lo requiere, se podrían considerar otros niveles de tiempo menores a día, como hora>minuto>segundo, pero la estrategia de implementación de ese nivel de granularidad puede ser muy distinta a la que vamos a ver hoy en este artículo para el caso de día como mínimo nivel granular.

Una de las facilidades que nos brinda SSAS con respecto a la dimensión de tiempo, es que él mismo la genere por nosotros incluso sin tener una tabla física de tiempo pre-existente en nuestro data warehouse. Este es el escenario que vamos a explorar en esta oportunidad, hablaremos de las otras opciones que tiene SSAS más adelante.

El propósito de este artículo es entender cómo SSAS nos facilita la vida en términos de generar nuestra propia dimensión de tiempo, que luego además podremos personalizar a nuestro gusto. El segundo propósito es que podamos aprender cómo SSAS hace el trabajo y entender su funcionamiento, de modo que nosotros podamos crear nuestra propia dimensión de tiempo desde cero si algo no nos gusta. ¡Comencemos!

Creando el Data Warehouse



Vamos a crear una nueva base de datos con nombre MiDataWarehouse en SQL Server 2008 R2, la cual será nuestro DataWarehouse ficticio sin tabla u otro objeto alguno:

Creando el proyecto de Analysis Services

Ahora crearemos un nuevo proyecto de SSAS en el Business Intelligence Development Studio (BIDS) de la versión de SQL Server 2008R2:



Creando el Data Source

Creamos un nuevo Data Source que apunte hacia nuestra base de datos MiDataWarehouse:



Creando el Data Source View



Ahora procedemos a crear nuestro Data Source View, en donde posteriormente SSAS generará la definición de nuestra dimensión de tiempo de manera automática:



Como mencioné anteriormente, no tenemos tabla alguna en nuestra base de datos, así que no tenemos nada que agregar al Data Source View:



Creando la dimensión de tiempo

Ahora procedemos a crear nuestra dimensión de tiempo en SSAS:



La pantalla que se muestra a continuación es clave, ya que nos permite indicar a SSAS, de qué forma generaremos nuestra nueva dimensión, en este caso la dimensión de tiempo:



Nos detenemos aquí un momento para explicar las opciones que se muestran:

Use an existing table: Se creará una nueva dimensión en nuestra base de datos OLAP (SSAS) basada en una tabla pre-existente de nuestro Data Source View (y por tanto en nuestro DW).

Generate a time table in the data source: Se creará una dimensión de tiempo en nuestro DW, su respectiva definición en el Data Source View y la dimensión de tiempo en nuestra base de datos OLAP.

Generate a time table on the server: Se creará la dimensión de tiempo en nuestra base de datos OLAP similar a la opción anterior. La posible desventaja de esta opción es que no nos creará nada en nuestro Data Source View que podamos modificar si así lo deseamos. Tampoco necesita de una dimensión existente en nuestro Data Warehouse.

Generate a non-time table in the data source: Se creará una dimensión distinta a una dimensión de tiempo en nuestro DW, su respectiva definición en el Data Source View y la dimensión correspondiente en nuestra base de datos OLAP.

Como se muestra en la imagen anterior, seleccionamos la opción Generate a time table in the data source para que SSAS sea el que se encargue de todo el trabajo.

La siguiente pantalla del asistente (Dimension Wizard) nos pide el rango de fechas para los cuales queremos generar datos en nueva dimensión de tiempo. De igual



manera nos pide seleccionar cuál son los periodos de tiempo que queremos generar. En mi caso he seleccionado todas las opciones pero es muy probable que no todos necesiten la opción de Half Year (semestre) o la de Ten Days (diez días) por mencionar alguna de las menos comunes. Finalmente, esta pantalla nos pide indicar cuál será el idioma en que se deben generar los datos de nuestra dimensión de tiempo y como se muestra a continuación, no incluye el idioma Español (lo cual es una deficiencia siendo el Español el segundo o tercer lenguaje más hablado del mundo).

Una de las formas superar esta deficiencia sería definiendo una traducción (dimension translation) para cada atributo. Nosotros seguiremos enfocados en cómo SSAS genera la dimensión de tiempo (aunque sea en Inglés) y las relaciones entre sus atributos.

La siguiente pantalla del asistente, pregunta por los tipos de calendario que queremos generar en nuestra dimensión. Los más usados son Regular calendar (calendario natural) y Fiscal calendar (calendario fiscal) que son las que seleccionaremos. En el caso del calendario fiscal, es posible indicar cuál será el día y el mes en que se inicia dicho calendario de acuerdo a nuestra organización, así mismo el nombre del año fiscal en comparación con el nombre del año calendario:



Esta es toda la información que SSAS necesita para generar nuestra dimensión de tiempo en el lado OLAP (SSAS). Ahora en la pantalla final que se muestra a continuación seleccionaremos el checkbox que dice Generate schema now para que en este mismo momento SSAS nos cree también la tabla física en nuestro Data Warehouse y su definición en nuestro Data Source View.



Ahora aparecerá un nuevo asistente que nos guiará a través del proceso de la generación del esquema físico y lógico que soportarán nuestra dimensión de tiempo, así como los datos (miembros) que contendrá:



La primera pregunta del asistente es acerca del Data Source View (DSV) en que deseamos crear la definición de la nueva dimensión. En nuestro caso seleccionaremos el mismo DSV que ya hemos creado al inicio de esta solución y que hasta el momento no contiene elemento alguno:



Ahora vienen las preguntas con respecto a la creación física de la tabla sobre nuestro Data Warehouse incluyendo si queremos poblar de datos nuestra nueva tabla:



Una pantalla más antes de terminar y esta se refiere a la convención de nombres o estándares a usar en las columnas de la nueva tabla:



Una vez finalizado el asistente, se inicia el proceso de generación del esquema y de la tabla física, el cual puede ser examinado en detalle en la siguiente pantalla:

Analizando la estructura de la nueva dimensión de tiempo

Ya tenemos nuestro nuevo esquema y estamos listos para ver la magia detrás del espectáculo, comenzando por la nueva tabla dbo.Time creada en nuestra base de datos MiDataWareHouse.

Noten que el asistente ha creado columnas para cada uno de los periodos de tiempo siguiendo las convenciones de nombre seleccionadas:



Si hacemos una consulta a la tabla generada, veremos que también se han generado los datos apropiados para cada una de las columnas en el rango de fechas indicado:



Cómo mencionamos anteriormente en este artículo, además de la tabla física en nuestro DW, se ha creado la definición de nuestra dimensión y la dimensión en sí dentro de nuestro proyecto de SSAS. Nuestro Data Source View ahora tiene la tabla “Time”:

Los atributos de nuestra “flamante” y nueva dimensión de tiempo se muestran a continuación:



El asistente también nos ha creado una serie de jerarquías naturales. Estas son:



Después de identificar los componentes básicos de nuestra dimensión, ya estamos listos para explorar los resultados de nuestra nueva dimensión de tiempo pero no sin antes procesar la misma:



Explorando los datos de la nueva dimensión de tiempo

Finalmente, ya podemos explorar los resultados de nuestra nueva dimensión de tiempo. Si se posicionan en la pestaña “Browser”, pueden seleccionar cada uno de los atributos de la dimensión o una de las jerarquías. En nuestro caso, seleccionamos la jerarquía Year – Trimester – Month - Ten Days – Date:



Los resultados se muestran como esperábamos, de igual manera para la jerarquía Year – Half Year – Quarter – Month – Ten Days - Date:



También tenemos jerarquías para el calendario fiscal como Fiscal Year – Fiscal Half Year – Fiscal Quarter – Fiscal Month – Fiscal Day:



Factores claves en el diseño de una dimensión de tiempo

De acuerdo a mi experiencia, mucho sucede que cuando construimos una dimensión de tiempo por nuestros propios medios, la navegación de las jerarquías creadas no funciona como nosotros esperamos, con los miembros de datos asignados al padre incorrecto (por ejemplo una fecha dentro del mes incorrecto, o un trimestre dentro del año incorrecto). Debido a esto, debemos tener claro que una de las claves de éxito de cualquier dimensión de SSAS es la definición de relaciones entre sus atributos. De esto depende que nuestras jerarquías funcionen correctamente y por otro lado tienen un gran impacto en los tiempos de respuesta cuando el usuario navegue sobre el cubo al que pertenezca la dimensión.



La dimensión de tiempo generada ha sido definida con las siguientes relaciones entre sus atributos:

Hemos subrayado en color rojo los atributos de la jerarquía Year – Half Year – Quarter – Month – Ten Days – Date, para profundizar un poco en los detalles de sus atributos Clave Primaria y Columna a Mostrar. La propiedad Clave Primaria (KeyColumns), define cómo SSAS va a diferenciar internamente a cada uno de los miembros del atributo, los cuales tienen que ser valores únicos. Debemos usar la propiedad Columna a Mostrar (Display Column), en el caso de querer mostrar una columna distinta a la usada en la clave primaria o cuando ésta esté compuesta de dos o más columnas. Esto nos ayudará a evitar posibles errores de navegación tanto de la dimensión de tiempo como de cualquier otra dimensión.

En el caso del atributo Year, éste define como su KeyColumn a la columna Year de nuestra tabla Time; y comoNameColumn a la columna Year_Name:



Si exploramos los datos que contienen estás dos columnas vemos lo siguiente:

Hacemos énfasis nuevamente sobre la importancia de la propiedad KeyColumn de un atributo, el cual debe contener un valor único para cada miembro de datos incluyendo a las jerarquías a donde esté asignado. En el caso del atributo Year, no se tiene mayores problemas ya que no es posible “confundir” un año con otro, ya que el valor del año en sí es su identificador único.

En cambio, con un atributo como Half Year (semestre) deberíamos tener un poco más de cuidado, ya que si revisan su relación con el atributo Year en la imagen del Dimension Usage, esta es de varios-a-uno, es decir, varios (dos) semestres en un año. Por tanto, en este contexto un semestre no vive por sí solo, sino que le pertenece a un año en específico. Es decir, si nos piden el semestre 1, nos tienen que decir siempre el año al que se están refiriendo. Por ejemplo: semestre 1 del 2010, semestre 2 del 2010, etc.

Por tanto el KeyColumn para HalfYear debe de identificar únicamente a cada semestre dentro de un año. En el caso de nuestra dimensión, las propiedades KeyColumn y NameColumn están definidas de la siguiente manera:



Los datos que almacenan dichas columnas se muestran a continuación:

Noten, que la columna Half_Year definida como KeyColumn, tiene sus valores incluyendo no sólo el mes de inicio del semestre (01 – enero - ó 07 - julio), sino también el año al que pertenece (1950-01-01 y 1950-07-01 para los que se muestran en la imagen).



MUY IMPORTANTE: Si la columna Half_Year sólo tuviera el semestre y no el año (por ejemplo: Semestre 1, Semestre 2), habría la necesidad de definir un KeyColumn compuesto que no sólo incluya la columna Half-Year sino también la columna Year, ya que ambas en su combinación, harían único a cada miembro de datos.

El comportamiento de Half-Year es similar al de Trimester y Month de nuestra jerarquía. Es decir, requiere que la columna que se use como KeyColumn, incluya en su definición, el año al que pertenece y no solamente el nombre del periodo. En el caso del atributo Date, éste se comporta de manera similar a Year, ya que cada fecha por sí misma es auto-suficiente para no ser confundida con otra fecha del calendario.

Así se ve el atributo Month (mes) de nuestra dimensión:



Ahora veamos sus propiedades:

Como vimos, la definición de Month es idéntica a la de Half-Year. Pero ahora veamos cómo se ven los datos del atributo Month Of Year, el cuál no pertenece a ninguna jerarquía sino como atributo independiente de nuestra dimensión de tiempo:



En este caso Month Of Year sólo nos muestra los doce meses del año sin indicar a qué año pertenece. Este tipo de atributo es necesario, para cuando necesitemos crear algún informe que permita el análisis comparativo de los mismos meses para distintos años, como por ejemplo:

Month 1 Month 2 Month 3…

2009

2010

2011…

Debido a esto las propiedades del atributo Month of Year han sido definidas como sigue:



Las columnas Month_Of_Year y el Month_Of_Year_Name contienen los siguientes valores:

Como se muestra en la última imagen, a diferencia de la columna Month, Month_Of_Year no contiene el año como parte de sus valores,



solamente el periodo de tiempo al que pertenece, en este caso el mes. Esto permite que todos los meses de Enero (Month 1) de cualquier año o trimestre, aparezca como si fuese uno solo. Lo mismo para todos los demás meses del año.

El cierre

Como resumir, podemos señalar lo siguiente:

SQL Server Analysis Services, nos puede ahorrar mucho el trabajo de crear una dimensión de tiempo para nuestra solución OLAP incluso sin tener previamente la dimensión creada en nuestro Data Warehouse relacional.

Podemos crear una dimensión de tiempo y su tabla en nuestro Data Warehouse usando el asistente para la creación de dimensiones de SSAS, y luego personalizar la misma para dejarla a nuestro gusto como borrar algún atributo o modificar alguna jerarquía.

Podemos optar también por crear nuestra dimensión de tiempo desde cero (por ejemplo si la queremos hacer en Español) siguiendo las mejores prácticas de acuerdo a como SSAS crea su dimensión de tiempo.

El asistente para la creación de la dimensión de SSAS no soporta el idioma Español. Una forma para tener nuestra dimensión de tiempo en este idioma, es crearla por ejemplo en Inglés y modificarla para usar la capación de Translations de SSAS. A diferencia de una base de datos relacional en donde el centro de todo son las relaciones entre tablas. La definición de relaciones entre atributos es la parte nuclear que define el comportamiento e influye en los tiempos de respuesta de nuestro cubo.

Otro aspecto clave para obtener el comportamiento deseado de nuestras jerarquías y atributos es la definición de las claves. Debemos indicar en la propiedad KeyColumn, la columna que haga a nuestro atributo único de acuerdo al contexto en donde se vaya a usar, ya sea como parte de una jerarquía o como atributo independiente.

Ya con nuestra nueva dimensión de tiempo, estamos listos para agregando las demás dimensiones a nuestra solución OLAP y posteriormente el o los cubos que sean necesarios.

Bi Tecnico

Documents

Transcript of Bi Tecnico