Introducción Al Datamart y El Datawarehouse

Programa Business Intelligence SQL Server 2012

Introduccin al Datamart y al Datawarehouse Objetivo Al finalizar el captulo, el alumno:

Reconoce y diferencia los conceptos de Datamart y Datawarehouse. . Temas

1. Concepto de Datamart

2. Concepto de Datawarehouse

3. La visin de Bill Inmon: Inmon Corporate Information Factory

4. La visin de Ralph Kimball: Kimball Bus Architecture

5. Etapas de un proceso de Data Mart y Data Warehouse segn la metodologa de

Ralph Kimball

Introduccin al Datamart y Datawarehouse 20

1. Concepto de Datamart

Orientado a un departamento dentro de la organizacin, puede ser implementado como una

solucin para problemas inmediatos, no es necesario para construir un Data Warehouse.

Implementacin rpida y sencilla a un menor costo de implementacin. Cubre necesidades

especficas del Negocio, respuestas rpidas por el menor volumen de informacin y asegura la

consistencia de los datos

El empleo de los Datamarts estar determinado por los que toman decisiones. Por ejemplo en

una empresa el gerente de ventas necesitar analizar la informacin de su rea, es decir las

ventas de la empresa.

Inadvertidamente se puede usar datos no compatibles con otros Datamarts que luego alarguen

el tiempo de unificacin.

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

Datamarts individuales.


2. Concepto de Datawarehouse

La construccin del Data Warehouse se va haciendo por etapas que normalmente

corresponden a las principales reas operativas de la empresa. Por ejemplo: rea de Ventas,

rea Financiero Contable, rea de Recursos Humanos, etc. Estas reas reciben el nombre de

Data Marts.

Los Data Warehouses (Base de Datos OLAP, On-Line Analytical Processing) son diseados

para cumplir con un conjunto de metas, las cuales son muy diferentes de los objetivos de un

sistema transaccional (OLTP, On-Line Transaction Processing). Por ejemplo, una meta de los

OLTP es maximizar la concurrencia mediante el uso de locks, dicho objetivo no es pertinente

en el diseo de DW donde las operaciones son slo de consulta, es decir del tipo SELECT.

Adems de las tcnicas de diseo, un desarrollador de Data Warehousing debe focalizarse en

entregar un anlisis multidimensional y capacidades de reportes ad-hoc (generacin de

reportes por parte del usuario experto basados en el conocimiento del negocio). Para realizar

esto, el diseador necesita conocer los requerimientos del negocio tan bien como las tcnicas

de diseo multidimensional.

Sin lugar a dudas, el Data Warehousing es parte integral de lo que algunos autores definen

como la Era de la Informacin ya que posibilita la construccin y mantenimiento de

estructuras destinadas al anlisis de los datos, transformando los datos en informacin y la

informacin en conocimiento.

Estos nuevos conceptos fueron definidos por los padres del DataWarehouse, Bill Inmon y

Ralph Kimball, cuyas visiones las revisaremos a continuacin.


3. La visin de Bill Inmon: Inmon Corporate Information

Factory

Bill Inmon es universalmente reconocido con el Padre del Data Warehouse. Tiene ms de 26

aos de experiencia en el campo de las bases de datos y diseo de Data Warehouses, ha

publicado cerca de 40 libros y ms de 350 artculos en las ms importantes revistas

especializadas. Su libro ms reconocido es Building DataWarehouse

Bill Inmon ve la necesidad de transferir la informacin de los diferentes OLTP (Sistemas

Transaccionales) de las organizaciones a un lugar centralizado donde los datos puedan ser

utilizados para el analisis (sera el CIF o Corporate Information Factory). Insiste adems en que

ha de tener las siguientes caractersticas:

Orientado a temas. Los datos en la base de datos estn organizados de manera que

todos los elementos de datos relativos al mismo evento u objeto del mundo real queden

unidos entre s.

Integrado. La base de datos contiene los datos de todos los sistemas operacionales de

la organizacin, y dichos datos deben ser consistentes.

No voltil. La informacin no se modifica ni se elimina, una vez almacenado un dato,

ste se convierte en informacin de slo lectura, y se mantiene para futuras consultas.

Variante en el tiempo. Los cambios producidos en los datos a lo largo del tiempo

quedan registrados para que los informes que se puedan generar reflejen esas

variaciones.

La informacin ha de estar a los mximos niveles de detalle. Los Dw departamentales o

datamarts son tratados como subconjuntos de este Dw corporativo, que son construidos para

cubrir las necesidades individuales de analisis de cada departamento, y siempre a partir de

este Dw Central (del que tambin se pueden construir los ODS (Operational Data Stores ) o

similares).


El enfoque Inmon tambin se referencia normalmente como Top-down. Los datos son

extrados de los sistemas operacionales por los procesos ETL y cargados en las reas de

stage, donde son validados y consolidados en el DW corporativo, donde adems existen los

llamados metadatos que documentan de una forma clara y precisa el contenido del DW. Una

vez realizado este proceso, los procesos de refresco de los Data Mart departamentales

obtienen la informacin de l, y con las consiguientes transformaciones, organizan los datos en

las estructuras particulares requeridas por cada uno de ellos, refrescando su contenido.

Al tener este enfoque global, es ms difcil de desarrollar en un proyecto sencillo (pues

estamos intentando abordar el todo, a partir del cual luego iremos al detalle).


4. La visin de Ralph Kimball: Kimball Bus Architecture

Ralph Kimball fue co-inventor de Xerox Star Workstation, el primer producto comercial en usar

iconos y ventanas. Fue Vice-presidente de Metaphor Computer Systems, fundador y CEO de

Red Brick Systems. Kimball es un referente de la metodologa dimensional para disear

grandes Data Warehouses, fue el que realmente explot al mximo el tema de Data

Warehousing.

Actualmente ensea Data Warehousing a diferentes grupos y ayuda a clientes con tcnicas de

diseo especficos. Kimball es columnista de la revista Intelligent Enterprise y tiene relacin con

Sagent Technology, Inc. Su libro The Data Warehouse Tookit es ampliamente reconocido

como un pilar sobre la materia.

Para Ralph Kimball el Data Warehouse es un conglomerado de todos los Data Marts dentro de

una empresa, siendo una copia de los datos transaccionales estructurados de una forma

especial para el anlisis, de acuerdo al Modelo Dimensional (no normalizado), que incluye,

las dimensiones de anlisis y sus atributos, su organizacin jerrquica, as como los

diferentes hechos de negocio que se quieren analizar. Por un lado tenemos tablas para las

representar las dimensiones y por otro lado tablas para los hechos (las facts tables). Los

diferentes Data Marts estn conectados entre s por la llamada bus structure, que contiene los

elementos anteriormente citados a travs de las dimensiones conformadas (que permiten que

los usuarios puedan realizar querys conjuntos sobre los diferentes Data Marts, pues este bus

contiene los elementos en comn que los comunican). Una dimensin conformada puede ser,

por ejemplo, la dimensin cliente, que incluye todos los atributos o elementos de anlisis

referentes a los clientes y que puede ser compartida por diferentes Data Marts (ventas,

pedidos, gestin de cobros, etc).

Este enfoque tambin se referencia como Bottom-up, pues al final el Datawarehouse

Corporativo no es ms que la unin de los diferentes Datamarts, que estn estructurados de

una forma comn a travs de la bus structure. Esta caracterstica le hace ms flexible y sencillo

de implementar, pues podemos construir un Data Mart como primer elemento del sistema de


anlisis, y luego ir aadiendo otros que comparten las dimensiones ya definidas o incluyen

otras nuevas. En este sistema, los procesos ETL extraen la informacin de los sistemas

operacionales y los procesan igualmente en el rea stage, realizando posteriormente el llenado

de cada uno de los Data Mart de una forma individual, aunque siempre respetando la

estandarizacin de las dimensiones (dimensiones conformadas).


5. Etapas de un proceso de Data Mart y Data Warehouse

segn la metodologa de Ralph Kimball

Este diagrama muestra la secuencia de tareas de alto nivel requeridas para el efectivo diseo,

desarrollo e implementacin de Data Warehouses. El diagrama muestra una vista general del

mapa de ruta de un proyecto en el cual cada rectngulo es una columna que nos indica dnde

estamos, por dnde pasamos y hacia dnde debemos dirigirnos.

1. Planificacin del Proyecto

La planificacin del proyecto es dependiente de los requerimientos del negocio, como

podemos apreciar en el diagrama del Business Dimensional Lifecycle (BDL), ya que los

requerimientos del negocio determinan el alcance del proyecto, definen los recursos

necesarios, etc., la planificacin acotar los requerimientos ya sea por cuestiones de

recursos y/o tiempo.

Esta etapa se concentra sobre la definicin del proyecto, especficamente en la

identificacin del escenario del proyecto para saber de dnde surge la necesidad del

Data Warehouse. Factores asociados con estas etapas incluyen: identificacin de los

usuarios, sponsors, convincentes motivaciones del negocio, cooperacin entre reas

de sistemas y negocios, cultura analtica de la organizacin y anlisis de factibilidad

(tanto tecnolgica como de disponibilidad de datos). Para medir estos factores propone

un test de buena disposicin del proyecto dnde describe diferentes escenarios

posibles.

Adicionalmente, propone tcnicas (Relevamientos de Alto Nivel, Priorizacin de

Requerimientos y Pruebas de Concepto) para mitigar las deficiencias que el proyecto

pudiera tener en algunos de los factores mencionados anteriormente.

Cmo metodologa de estas etapas propone identificar el alcance preliminar basndose

en los requerimientos del negocio y no en fechas lmites (Deadlines) construyendo la


justificacin del proyecto en trminos del negocio con indicadores como el ROI

(Retorno de Inversin), NPV (Valor Presente Neto) y el IRR (Indice de Retorno Interno).

A nivel de planificacin del proyecto, establece la identidad del mismo, el personal

(staff): los usuarios sponsors, lideres, gerentes del proyecto (tanto de sistemas como

del sector usuarios), equipo corazn del proyecto (analistas, arquitectos, DBAs,

diseadores, responsables de extraccin, desarrolladores, instructores, etc.), equipo

especial del proyecto (soporte, seguridad informtica, programadores, analistas de

calidad y testing), el desarrollo del plan del proyecto, el seguimiento y monitoreo.

2. Definicin de los Requerimientos del Negocio

La definicin de los requerimientos del negocio establece la base para las tres etapas

paralelas subsiguientes. Estas etapas estn focalizadas en la tecnologa, los datos y

las aplicaciones por lo cual es altamente crtica y es el centro de atencin del BDL.

Los usuarios finales y sus requerimientos impactan siempre en las implementaciones

realizadas de un Data Warehouse. Segn la perspectiva de Kimball, los requerimientos

del negocio se posicionan en el centro del Universo del Data Warehouse. Como

destaca siempre el autor, los requerimientos del negocio deben determinar el alcance

del data warehouse (qu datos debe contener, cmo debe estar organizado, cada

cunto debe actualizarse, quines y desde dnde accedern, etc). Kimball da consejos

y tcnicas para descubrir eficazmente los requerimientos del negocio. Estas tcticas y

estrategias se focalizan sobre las entrevistas de relevamiento (diferentes tipos,

preparacin de la entrevista, roles a cubrir, bsqueda de informacin pre-entrevista,

seleccin de entrevistados, desarrollo de los cuestionarios, planificacin, preparacin

de los entrevistados, conduccin de la entrevista, contenido, cierre, revisin de

resultados, etc.).

3. Modelado Dimensional

Ralph Kimball es realmente un referente en el tema de modelado dimensional. Por

ejemplo en el Captulo 6 del libro A Graduate Course on Dimensional Modeling

(Kimball,1998), se introducen conceptos avanzados del modelado, tales como,

relaciones many to many en esquemas estrella, role-playing dimensions, relaciones

recursivas, manejo de granularidades diferentes, mltiples unidades de medida,

modelos multimoneda, bandas de rangos, consultas ROLAP avanzadas, anlisis

market basket, atributos puercoespn, etc.

4. Diseo Fsico

El diseo fsico de las base de datos se focaliza sobre la seleccin de las estructuras

necesarias para soportar el diseo lgico. Algunos de los elementos principales de este

proceso son la definicin de convenciones estndares de nombres y configuraciones

especficas del ambiente de la base de datos. Los ndices y las estrategias de

particionamiento son tambin determinadas en esta etapa.

5. Diseo y Desarrollo de Presentacin de Datos

Todas estas tareas son altamente crticas pues tienen que ver con la materia prima del

Data Warehouse: los datos. La desconfianza y prdida de credibilidad del Data

Warehouse sern resultados inmediatas e inevitables si el usuario se encuentra con


informacin inconsistente. Es por ello que la calidad de los datos es un factor

determinante en el xito de un proyecto de Data Warehousing. Es en esta etapa donde

deben sanearse todos los inconvenientes relacionados con la calidad de los datos

fuente.

Plan

1. Crear un diagrama de flujo fuente-destino esquemtica, de una pgina y

a nivel global.

2. Probar, elegir e implementar una herramienta de Data Staging.

3. Profundizar en detalle por tabla destino, grficamente describir las

reestructuraciones o transformaciones complejas. Grficamente ilustrar

la generacin de las claves surrogadas. Desarrollo preliminar de la

secuencialidad de los trabajos.

Carga de dimensiones

4. Construir y probar la carga de una tabla dimensional esttica. La

principal meta de este paso es resolver los problemas de infraestructura

que pudieran surgir (conectividad, transferencia, seguridad, etc.)

5. Construir y probar los procesos de actualizacin de una dimensin.

6. Construir y probar las cargas de las restantes dimensiones.

Fact Tables y automatizacin

7. Construir y probar la carga histrica de las Fact Tables (carga masiva de

datos). Incluyendo bsqueda y sustitucin de claves.

8. Construir y probar los procesos de cargas incrementales.

9. Construir y probar la generacin de agregaciones.

10. Disear, construir y probar la automatizacin de los procesos.

6. Diseo de la Arquitectura Tcnica

Ralph Kimball hace una analoga entre los planos arquitectnicos de una casa y la

arquitectura de un Warehouse, Se debe de tener un plan antes de comenzar, no es

simplemente reordenar y explotar la informacin.

Al igual que en una construccin, los planos sirven para comunicar los deseos entre los

clientes y el arquitecto, como as tambin para medir esfuerzos y materiales necesarios

para la obra (comunicacin, planificacin, flexibilidad y mantenimiento, documentacin,

productividad y reuso). Finalmente, argumenta Kimball (1998), un buen conjunto de

planos, como cualquier buena documentacin, nos ayudar ms tarde cuando sea

tiempo de remodelar o hacer incorporaciones.

7. Seleccin de Productos e Instalacin

Utilizando el diseo de arquitectura tcnica como marco, es necesario evaluar y

seleccionar componentes especficos de la arquitectura cmo ser la plataforma de

hardware, el motor de base de datos, la herramienta de ETL o el desarrollo pertinente,

herramientas de acceso, etc.


Una vez evaluados y seleccionados los componentes determinados se procede con la

instalacin y prueba de los mismos en un ambiente integrado de Data Warehousing.

8. Especificacin de Aplicaciones para Usuarios Finales

Kimball (1998) divide el proceso de creacin de las aplicaciones para usuarios finales

en dos grandes fases: especificacin y desarrollo. Clasifica a los usuarios segn su

perfil de consulta, desde usuarios con un perfil ms estratgico y menos predecibles

(Power Users) hasta usuarios netamente operacionales que consumen una serie de

reportes estndares (Final Users) pasando por los usuarios gerenciales con uso de

interfases push-button (EIS Users).

Kimball (1998) destaca cuatro pasos principales (siempre enfatizando el hecho de

involucrar a los usuarios en cada uno de estos pasos).

Determinacin del conjunto de templates iniciales (identificar reportes candidatos,

clasificarlos y priorizarlos)

Diseo de la estrategia de navegacin dentro de la aplicacin (esquema de

pantallas, esquema de carpetas directorios-, criterios de agrupamiento -por

datos, por dueo, por regla del negocio, etc.)

Determinacin de estndares (nombre de objetos, ubicacin de objetos, formato

de las salidas)

Detalle de las especificaciones (definicin: nombre, descripcin o propsito,

frecuencia, parmetros, restricciones, layout, etc.)

9. Desarrollo de Aplicaciones para Usuarios Finales

Seleccin de un enfoque de implementacin

1. Basado en Web

- Inter/Intranet

- Usuarios altamente distribuidos

- Manejo centralizado de nuevas versiones

2. Herramienta propietaria

- Mayor complejidad de uso

- Para usuarios ms capacitados

- Instalacin local

3. EIS

- Acceso estructurado

- Secuencialidad de pantallas

- Push-Button

4. Interfase personalizada

- Application Programming Interface (API)

- Desarrollos propios sobre la base de un conjunto de funcionalidades


Desarrollo de la aplicacin

i. Definicin de herramienta de acceso al MetaData

ii. Desarrollo de Templates y esquema de navegacin de la aplicacin

iii. Seleccin de reportes para pre-ejecucin

Prueba y verificacin de datos

i. Descripciones

ii. Informacin duplicada

iii. Relaciones entre atributos

iv. Consistencia e integridad de datos con sistemas fuentes

Documentacin y Roll Out

i. Retroalimentacin con los resultados de la puesta en produccin

Mantenimiento

i. Nuevos templates

ii. Incorporacin de nuevos sistemas fuentes

iii. Monitoreo de performance

iv. Eliminacin de templates en desuso

10. Implementacin

La tecnologa que reside en el escritorio del usuario es la ltima pieza que debe ser

ubicada antes de la salida a produccin (Roll Out o Deployment). Desafortunadamente,

afirma Kimball (1998), las organizaciones frecuentemente subestiman el esfuerzo y el

tiempo requerido para esta etapa. Kimball, propone entonces un checklist sobre

actividades que deberan ocurrir antes de la implantacin, para asegurar que la

infraestructura correspondiente al ambiente del usuario est correcta. El checklist

incluye: Configuracin de Hardware, Conexin a las Bases, Acceso a Intranet o

Internet, Direcciones LAN (si no son dinmicamente asignadas), Auditorias de

Tecnologa sobre las configuraciones en las que se encontraban las PCs.

Asimismo incluye preveer actualizaciones de hardware y software (determinando

responsables, proyecto o rea de usuario), verificaciones de seguridad (logon de red y

base de datos), prueba de procedimientos de instalacin en una variedad de mquinas,

planificacin de instalacin con la correspondiente educacin a los usuarios. Debe

instruirse al usuario en tres aspectos claves: contenido del warehouse, aplicacin y

herramientas de acceso.

11. Mantenimiento y crecimiento

Data Warehousing es un proceso bastante particular cuya evolucin es en forma

espiral. Esto permite ir afinando cada etapa y retroalimentndola hasta lograr el objetivo

principal, que es plasmar el requerimiento del usuario en una base de datos para la

toma de decisiones e ir creciendo con el tiempo.

Kimball (1998 brinda una serie de puntos a tener en cuenta para mantener

exitosamente el Warehouse. Entre ellos se destacan: el continuo soporte y la constante

capacitacin a usuarios de negocios, el manejo de la infraestructura (monitoreo de

base de datos, trfico, etc.), tuning de rendimiento sobre las consultas, mantenimiento

del metadata y procesos ETLs. Otros aspectos involucran el monitoreo regular del

cumplimiento de las expectativas sobre el Warehouse (variables de medicin del xito


fijadas con anterioridad), relevamiento de casos de estudio (situaciones reales donde

una decisin basada en informacin del Warehouse tuvo impacto sobre el negocio).

Del mismo modo, la constante publicidad interna del uso del warehouse (permitiendo

acceso siempre y cuando se tenga la capacitacin correspondiente) y fluida

comunicacin con los sectores de negocios y sistemas para asegurar la buena salud

del Data Warehouse.

12. Gerenciamiento del Proyecto

El gerenciamiento del proyecto se encuentra en cada una de las actividades del

proyecto, desde su concepcin hasta la puesta en produccin. Es una fase vital dentro

del Business Dimensional Lifecycle (BDL) permitiendo un fluido flujo de los

requerimientos del rea usuaria hacia el equipo de desarrollo del Data Warehouse.

Asimismo el buen manejo de situaciones inesperadas que puedan hacer peligrar el

proyecto.


Laboratorio N 2

Documents

Introducción Al Datamart y El Datawarehouse