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

Programa Business Intelligence SQL Server 2012

Introduccin al Datamart y Datawarehouse

1.

20

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.

Introduccin al Datamart y Datawarehouse

2.

21

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.

Introduccin al Datamart y Datawarehouse

3.

22

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

Introduccin al Datamart y Datawarehouse

23

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

Introduccin al Datamart y Datawarehouse

4.

24

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

Introduccin al Datamart y Datawarehouse

25

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

Introduccin al Datamart y Datawarehouse

5.

26

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

Introduccin al Datamart y Datawarehouse

27

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

Introduccin al Datamart y Datawarehouse

28

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

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

a nivel global.
Probar, elegir e implementar una herramienta de Data Staging.
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.

5.
6.

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.)
Construir y probar los procesos de actualizacin de una dimensin.
Construir y probar las cargas de las restantes dimensiones.

Fact Tables y automatizacin

7.
8.
9.
10.

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

datos). Incluyendo bsqueda y sustitucin de claves.
Construir y probar los procesos de cargas incrementales.
Construir y probar la generacin de agregaciones.
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.

Introduccin al Datamart y Datawarehouse

29

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

Introduccin al Datamart y Datawarehouse

30

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

Introduccin al Datamart y Datawarehouse

31

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.

Introduccin al Datamart y Datawarehouse

Laboratorio N 2

32