Propuesta de Metodologia para DWH

INDICE DE LA PROPUESTA METODOLOGIA
8.2 Política para obtener Calidad en los Datos del DWH .......................................................................................2
FASE 1: EXPLORACION DE LOS DATOS..........................................................................3
FASE 2: DISEÑO DE LAS SOLUCIONES...........................................................................4
FASE 3: EJECUCIÓN DE RUTINAS DE LIMPIEZA..........................................................4
ETAPA 3.1: En DS-Flow......................................................................................................4
ETAPA 3.2: En In-Flow .......................................................................................................5
ETAPA 3.3: En Up-Flow .....................................................................................................5
FASE 4: ASEGURAR LA CALIDAD EN LA DATA............................................................6
Entregable en la Política de Calidad........................................................................................6
Roles y Responsabilidades del Equipo para Obtener Calidad en el DWH..............................7
8.3 Relación entre los Estados de los datos con las políticas para asegurar la calidad en los datos del DWH.......7
8.4 Integración entre el Ciclo de Vida propuesto para desarrollar un DWH con la Política para asegurar la
Calidad en la Data del DWH......................................................................................................................................9
CAPITULO 9: PROCESO DE ELABORACION DEL CICLO DE VIDA DEL DWH...........11
FASE 0: ESTUDIO DE VIABILIDAD DEL DWH....................................................................................................15
MILESTONE 0: Aprobación del Estudio de Viabilidad........................................................16
Entregables............................................................................................................................16
Roles y Responsabilidades del Equipo en la Fase del Estudio de Viabilidad del DWH.......16
FASE 1: VISIONADO...............................................................................................................................................16
ETAPA 1.1: Organización del Proyecto.................................................................................17
ETAPA 1.2: Evaluación de la Solución.................................................................................21
ETAPA 1.3: Definición de la Solución..................................................................................21
MILESTONE 1: Visión y Alcance Aprobados......................................................................22
Entregables............................................................................................................................22
Roles y Responsabilidades del Equipo en la Fase de Visionado...........................................22
FASE 2: PLANIFICACIÓN.......................................................................................................................................23
ETAPA 2.1: Identificación y Análisis de clientes y usuarios.................................................23
ETAPA 2.2: Análisis de Requerimientos ..............................................................................24
ETAPA 2.3: Modelamiento Dimensional..............................................................................30
ETAPA 2.4: Validación del Modelado...................................................................................34
ETAPA 2.5: Diseño del DWH...............................................................................................35
ETAPA 2.6: Validación del Diseño........................................................................................62
MILESTONE 2: Plan de Proyecto Aprobado........................................................................63
Entregables............................................................................................................................63
Roles y Responsabilidades del Equipo en la Fase de Planificación......................................63
FASE 3: DESARROLLO...........................................................................................................................................64
ETAPA 3.1: Consideraciones de la Solución.........................................................................64
ETAPA 3.2: Construcción del Documento del Desarrollo.....................................................65
ETAPA 3.3: Validación del Desarrollo..................................................................................65
MILESTONE 3: Alcance completo.......................................................................................65
Entregables............................................................................................................................65
Roles y Responsabilidades del Equipo en la Fase de Desarrollo..........................................66
FASE 4: ESTABILIZACION .....................................................................................................................................66
ETAPA 4.1: Verificaciones ..................................................................................................67
MILESTONE 4: Versión aprobada........................................................................................67
Entregables............................................................................................................................67
Roles y Responsabilidades del Equipo en la Fase de Estabilización.....................................67
FASE 5: UTILIZACION ...........................................................................................................................................68
ETAPA 5.1: Actividades para el uso del DWH......................................................................68
MILESTONE 5: Implantación aprobada...............................................................................69
Entregables............................................................................................................................69
Roles y Responsabilidades del Equipo en la Fase de Utilización.........................................69
FASE 6: EVALUACIÓN............................................................................................................................................69
ETAPA 6.1: Impactos del DWH............................................................................................70
ETAPA 6.2: Valor del DWH para la Toma de Decisiones.....................................................72
ETAPA 6.3. Balance Costo/Valor..........................................................................................73
Entregables............................................................................................................................73
Roles y Responsabilidades del Equipo en la Fase de Evaluación.........................................74
9.1 CONSIDERACIONES IMPORTANTES.............................................................................................................74
8.2 Política para obtener Calidad en los Datos del DWH
Una buena práctica para minimizar errores en los datos de un DWH es primeramente limpiar la
data de las fuentes de origen y luego continuar paulatinamente estas prácticas cuando los usuarios
ya se encuentran usándolos, de modo que la calidad se mantiene, este tema es una tarea constante
a ejecutar. Existen software, herramientas y entes que nos ayudan a obtener el objetivo deseado
de la calidad, pero estos incluyen un gasto extra generalmente no calculado para efectuar
proyectos de DWH, y por ser un factor que debe de efectuarse constantemente, entonces surge un
gran costo de mantenimiento, que finalmente lleva al fracaso del proyecto del DWH. Una opción
alternativa es la realización de políticas incluidas dentro de la metodología efectuando
determinados procedimientos, ahora bien es necesario evaluar si en las fuentes de datos de la
organización son suficientes con estas rutinas de calidad; si el equipo del DWH determina que se
requiere de un apoyo tecnológico para asegurar la calidad en los datos, es necesario informarlo
antes de iniciar el proyecto para ver la factibilidad del caso, ser claro y explicito en este factor
crítico.
En esta política se acota su alcance a organizaciones cuya información a usar no se presentan en
gran cantidad siendo innecesario el uso de alguna herramienta de software.
La calidad en los datos de un DWH se considera descentralizada porque no se focaliza en la

creación del mismo, sino en todo el ambiente del DWH; es por ello que esta política formará
parte del DWH propiamente dicho (hablando físicamente), y también será parte del proceso ETL
y de las fuentes de orígenes de datos.
La política propuesta para la calidad de datos en este trabajo de tesis se basa exclusivamente para
aquellas organizaciones que con la misma sean suficientes para obtener un DWH con data
confiable; se basa fundamentalmente en la limpieza de la data, consistencia, corrección de errores
típicos, etc. Funcionalmente efectivas para el análisis de poca información.
El costo que pueda generar estas actividades no agrega valor a la elaboración del DWH pero lleva
a los datos a un estado de utilidad y confianza al momento de tomar decisiones generándose
entonces el valor agregado deseado para el DWH, al contar con información confiable, exacta y
completa.
La política de calidad en los datos diferencia a dos estados de los datos en un DWH [BI16],
añadiendo a ello un tercero que lo llamamos DS-Flow (Data Source-Flow) como se observa en la
ilustración.
ILUSTRACION 1: Estados de los datos en un DWH [BI16] [FP]
− DS-flow:
Se refiere a los datos que se encuentran en las fuentes de datos origen (datos generalmente
ubicados en los sistemas operacionales).
− In-flow:
El In-flow describe el flujo de los datos desde su captura hasta su ingreso al almacén. Se hace
referencia a la data que usamos en el Proceso ETL.
− Up-flow:
El Up-flow abarca las etapas donde los datos se resumen a formas relevantes a los usuarios;
es decir, se ubica en el mismo DWH o en aquellas aplicaciones que el proceso de Inteligencia
de Negocios realice o utilice.
Esta distinción en los estados de los datos en un DWH nos permite distinguir tres estados
diferentes de los datos en un ambiente del DWH y de ese modo entender mejor las políticas de
calidad de los datos que se extienden en dicho ambiente. La metodología propuesta para
desarrollar un Almacén de Datos se focalizó en el Estado Up-Flow de los datos, como se observa
en la Ilustración.
FASE 1: EXPLORACION DE LOS DATOS
Se comienza con la exploración de los valores de los datos mediante la investigación de cada
valor en los campos, descubriendo información dentro de campos sin formato, reconociendo
información perdida, alcanzándose el conocimiento necesario acerca del nivel de calidad en que
se encuentran los datos de las fuentes de origen y por tanto se determina si la data es lo
suficientemente confiable para implementarse en el DWH. Al término de esta fase se puede
definir las rutinas de limpieza necesarias para convertirlos en información correcta, completa y
consistente para el DWH, y también determinar si con las rutinas se satisface con datos de calidad
al DWH o con algún tipo de herramienta especializada.
Esta fase nos permite tener una visión sobre la condición real de los datos, ayudándonos a
conocer y comprender mejor la información que se encuentra en las fuentes de datos y su nivel de
calidad. Se compone de las siguientes actividades:
− Se estudia los datos que tengan un significado relativo al negocio o área de estudio.
− Se descubre metadata oculta (o se analiza metadata existente si hubiese) y prácticas de
negocio no documentadas.
− Se extrae datos específicos que se encuentra mezclados en campos de diferente dominio.
FASE 2: DISEÑO DE LAS SOLUCIONES
En esta fase ya se está en condiciones de definir que rutinas de limpieza se deben incluir; se
define también el conjunto de rutinas de limpieza que se deben de incluir para dar solución a los
problemas encontrados en la fase anterior. Las rutinas pueden ser diseñadas como soluciones
automáticas, semi-automáticas o directamente manuales según sea la necesidad de tales
soluciones en los datos.
Se deben diseñar rutinas tendiendo en cuenta 3 componentes básicos: [BI09]
− Verificación de la data: La validación de la data consiste de un número de checks, incluyendo:

Chequeo de dominio, chequeo de claves foráneas, etc.
− Mejorar la data: Es el proceso de la limpieza de los datos válidos para hacerlos más
importantes, por ejemplo, la información del nombre y la dirección.
− Manejar errores: Es un proceso que determina que se hará con los datos que no son perfectos.
La data puede no ser aceptada, guardada para ser reparada en un área de trabajo, o pasar con
sus imperfecciones para el DWH. La metadata para datos imperfectos debe incluir sentencias
sobre la calidad de los datos: Tipos de errores y frecuencia de errores.
Esta no es una lista exhaustiva, sólo nos resalta algunos conceptos básicos a considerar.
FASE 3: EJECUCIÓN DE RUTINAS DE LIMPIEZA
Esta fase se lleva a cabo en el caso de desarrollar las propias rutinas de limpieza de datos,
consiste en la realización de estas rutinas (desarrollo de algoritmos) y su ejecución (aplicarlos en
el proceso del DWH) y también se llevan a acabo el Diseño de las Soluciones planteadas en la
fase anterior, se extienden estas actividades a todo el ciclo de vida del DWH.
Esta es una fase flexible, se adecua a las necesidades de la data para obtener la calidad deseada;
entre algunas (por ejemplo) de las actividades más destacables de esta fase según el estado en que
los datos se encuentren se tiene:
ETAPA 3.1: En DS-Flow
Esta etapa nos permite limpiar la data de los errores que se encuentran presentes en las
fuentes de origen que alimentará al DWH, porque es mejor evitar que datos sin calidad
ingresen al DWH, se extiende hasta mantener la calidad en los datos que ya se ingresaron
al DWH. Esta etapa se lleva a cabo en todo el proceso del DWH.
I. Supervivencia y formateo de datos
Sirven para asegurar que la data más importante sea considerada y se encuentre de
forma adecuada. Esta tarea se encarga de varias sub-tareas como:
− Llenado de datos: Ingresa los valores que faltan en registros remplazándolos con
valores de registros relacionados correspondientes a la misma entidad.
− Resolución de conflictos de datos: Resolver problemas de registros múltiples que se
refieren a la misma entidad con atributos conflictivos. Ejemplo: Registros de clientes
que coinciden en el nombre y dirección pero tienen diferente número de RUC.
− Supervivencia de datos: Determinar los datos apropiados a cargar en caso de
múltiples posibilidades. La información se puede encontrar en más de un lugar y debe
determinarse cuál seleccionar para el DWH.
ETAPA 3.2: En In-Flow
II. Verificación de la uniformidad
Asegura que los valores de los datos que se cargarán, se encuentren dentro de límites
preestablecidos. Las reglas de negocio determinan qué valores son factibles en cada
campo de datos, esta verificación permite que los datos que ingresarán al DWH cumplan
con determinadas reglas y se impide que los datos inválidos ingresen.
III. Transformación de datos
Estas convierten los datos a una forma adecuada para el DWH. Se estandarizan los
datos a un lenguaje común usado para el DWH y también se usan las reglas de negocios
para transformar los datos adecuadamente.
IV. Verificación de versión
Se encarga de detectar cambios en la codificación de los datos fuente se obtiene

comparando con la información de la metadata.
ETAPA 3.3: En Up-Flow
V. Verificación de la completitud
Determina la completitud y correctitud de las agregaciones en los datos, estas son

útiles pero pueden ocultar datos importantes. Por ejemplo cuando se saca un promedio a
partir de campos con valores nulos, el promedio puede estar bien calculado pero no refleja
la realidad correctamente.
VI. Verificación de la conformidad
Valida si los datos se encuentran en la forma adecuada en el DWH; permitiéndonos

descubrir casos excepcionales, donde se debe investigar si la causa de los mismos
proviene de datos erróneos o que los resultados reflejan un cambio en la realidad. Por
ejemplo, si el promedio de ventas en una área organizacional se mantiene constante
durante todos los meses del año y en determinado mes aumenta al doble, los resultados
pueden deberse a datos ingresados en forma errónea por los operadores de los sistemas
operacionales o que las ventas en realidad subieron en dicho mes.
VII. Verificación de la metadata
Esta fase consiste en la revisión de la metadata del DWH, en caso de que exista
alguna BD o DWH en funcionamiento o del DWH que se elaboró en la organización.
FASE 4: ASEGURAR LA CALIDAD EN LA DATA
Esta fase nos indica que el mejoramiento en la calidad de los datos del DWH es un proceso que
va más allá de la construcción del mismo DWH. A diferencia de la limpieza de datos que apunta a
corregir errores, el proceso de mejoramiento de la calidad busca prevenirlos atacando los
problemas desde su origen (Fuente de Datos) y continuando estas mejoras en todo el tiempo de
vida del DWH; se debe mejorar sus procesos de negocio y concientizar a los usuarios y gerencia
de su importancia para que se logre los beneficios deseados.
Una forma indirecta para asegurar la calidad en el DWH es mejorar los procesos de negocios que
producen los datos o reestructurarlos antes de que automaticen de tal manera que se elimine pasos
innecesarios que incluyen costo innecesarios y añaden errores para el DWH.
Los puntos más importantes y resaltantes a considerar dentro de una organización para asegurar
la calidad de la data de las fuentes de origen, son:
1. Definir los datos consistentemente entre todos los futuros usuarios del DWH.
2. Ubicar los programas de captura de datos lo más cerca posible del evento de negocio que
origina esos datos.
3. Ingresar reglas de validación automática que se disparen al momento que se ingresan los
datos y validen si los mismos son correctos.
4. Permitir actualizar los datos siempre.
5. Permitir cargar el valor "desconocido" en cada uno de los campos cuando no se conoce el
valor real.
6. Estimular a la organización para que tenga la data lo más actualizados y correcto posible.
7. Hacer que tanto los encargados de ingresar los datos como los encargados de los procesos de
negocios se sientan responsables de la calidad de los datos.
Si se minimiza los errores de los datos desde el origen, estos nos aseguran que la data que ingresa
al DWH es confiable para la toma de decisiones en la organización
Entregable en la Política de Calidad
− Documento Master de la Política de Calidad de Datos (incluye integradamente aspectos de la

Exploración de los Datos, explicación del Diseño de las Soluciones, Ejecución de Rutinas de
Limpieza, reglas aplicadas para Asegurar la Calidad en los Datos).
− Presentación en Power Point de la Política de Calidad del DWH.

Roles y Responsabilidades del Equipo para Obtener Calidad en el DWH
1 Administración del Producto:

Exploración de los Datos.
2 Administración del Programa:
Diseña las Soluciones.
3 Desarrollo:
Ejecución de Rutinas de Limpieza.
4 Experiencia del Usuario:
Apoyo en la Fase de Exploración de Datos con la participación activa de los usuarios, Trabajo
en Power Point de la Presentación de las Políticas de Calidad.
5 Pruebas:
Verificación de algoritmos o rutinas de limpieza.
6 Administración de Versiones:
Evaluación de los aspectos para desarrollar en las versiones posteriores del tema relacionado
a la calidad.
8.3 Relación entre los Estados de los datos con las políticas para
asegurar la calidad en los datos del DWH
Estados de los DS-Flow In-Flow Up-Flow

Datos  (Fuentes de Datos) (ETL) (DWH)
Políticas de 1º Exploración de los 2º Diseño de las

Calidad  Datos Soluciones
3º Ejecución de rutinas de lim pieza
− Supervivencia y − Verificación de la − Verificación de la

formateo de datos, uniformidad. completitud.
etc. − Transformación de − Verificación de la
datos. conformidad.
− Verificación de − Verificación de la
versión, etc. metadata, etc.
−
4º Asegurar la calidad en la data
TABLA 1: Ubicación de las políticas de Calidad en el Ambiente del DWH [FP]
Esta tabla nos permite entender la relación de los tres estados de los datos de un DWH con las
fases de la Política de Calidad que se propone en este trabajo de tesis; a diferencia de la propuesta
metodológica que se enfoca en el Estado Up-Flow, la política de calidad se enfoca en todo el
ambiente del DWH (proceso ETL, DWH) y también en la Fuentes de Datos que nos permitirán
alimentar al DWH.
ADMINISTRACION DEL PROYECTO
8.4 Integración entre el Ciclo de Vida propuesto para desarrollar un DWH con la Política para asegurar la
Calidad en la Data del DWH
1º Exploración de Datos FASE DE VISIONADO
2º Diseño de Soluciones FASE DE
PRUEBAS
FASE DE DESARROLLO
3º Ejecución de Rutinas
de Limpieza FASE DE
CAPITULO 1:ILUSTRACION 2: Integración de la Calidad de Datos con la propuesta metodológica [FP]

FASE DE UTILIZACION
4º Asegurar la calidad en
la data (ETL, DWH y en
las Fuentes de Datos).
Esta ilustración nos indica que la Política para Asegurar la Calidad en un DWH es una
tarea paralela a la elaboración del DWH.
El equipo del DWH a la vez que realiza la elaboración del proyecto del mismo, debe
realizar tareas paralelas de calidad de datos, para que de esta forma se obtengan datos
con mayor credibilidad.
CAPITULO 9: PROCESO DE ELABORACION DEL CICLO DE
VIDA DEL DWH
La propuesta se basa en la integración del Modelo de Procesos y del Modelo de Equipo

de MSF; se usan los Milestone al culminar cada Fase, los Milestone son puntos en el
proyecto en los cuales los entregables importantes se tienen que completar y revisar.
El Modelo de Procesos de MSF nos permite adaptarnos a los requerimientos cambiantes

del proyecto debido a las iteraciones a través del ciclo de desarrollo y las versiones
incrementales de la solución.
Previamente es importante que se tenga en cuenta algunas pautas y/o significados de

algunos conceptos en la propuesta.
Clientes y Usuarios: Un Cliente es la persona u organización que se encarga del

proyecto, proporciona fondos y quienes esperan conseguir un valor al negocio desde la
solución. Los usuarios son gente quienes interactúan con la solución en sus trabajos.
[BI19]
Nuestra propuesta es una Aproximación basada en Fases y Milestone, identificando

Milestone Principales, los Milestone Principales son aquellos que nos sirven para la
transición de una fase a otra, mientras que los Provisionales nos sirven como
indicadores progresivos que aparecen durante una fase. Aproximación Iterativa, en el
lanzamiento de las versiones, MSF recomienda que las soluciones se desarrollen por
desarrollo, pruebas e implementación estas son el núcleo de la funcionabilidad,
posteriormente un conjunto de características son adicionadas, esto se conoce como el
lanzamiento de una versión, proyectos y/o soluciones pequeñas a veces requieren de una
sola versión, MSF recomienda que una solución se halle en múltiples versiones, de tal
forma que a medida que salen más versiones, la funcionalidad se incrementa como se
muestra en la siguiente Ilustración. El Tiempo de Lanzamiento de las versiones varía de
acuerdo al tipo y tamaño del proyecto.
ILUSTRACION 3: Funcionalidad vs. Tiempo en el Lanzamiento de Versiones
[BI19]
Crear un plan multi-versiones, entregar primero el centro funcional, ciclos a través de

iteraciones rápidamente, establecer el control del cambio, parar de crear nuevas
versiones cuando no agreguen valor; son aquellos aspectos que se debe de considerar al
momento del Lanzamiento de Versiones.
La Versión 1 de la propuesta desarrolla el aspecto funcional, para lo cual se integra el

Modelo de Procesos y de Equipo de MSF adecuándolo a la construcción de un DWH;
en la Versión 2, se centra en el tema de la Calidad de la Datos; las versiones posteriores
se dejan para aspectos de Administración de Riesgos (a profundidad), Administración
del Proyecto, Administración de la Preparación y otros aspectos que se presenta en
MSF, no siendo estos menos importantes que los primeros. Para finalizar, la propuesta
es también una Aproximación Integrada del Desarrollo e Implementación de
Soluciones, una solución no proporciona valor al negocio mientras no se encuentre en
funcionamiento.
Las Fases en el proceso de elaboración del DWH no son iguales en duración, la cantidad
de tiempo en cada fase puede variar dramáticamente y las actividades frecuentemente
atraviesan las fases.
El Modelo de Equipo de MSF por ser un modelo no jerárquico en donde la

Comunicación es el núcleo que integra a todos los “Roles Cluster” (Grupo de Roles)
nos permite estructurar a la gente y sus actividades para encomendar proyectos exitosos.
El Modelo de Equipo se organiza en equipos pequeños y multidisciplinarios, en los
cuales frecuentemente los miembros comparten responsabilidades teniendo una visión
común del proyecto, estos equipos tienen la habilidad de responder más rápido que los
equipos grandes. Los equipos trabajan juntos, una de las metas del equipo es disminuir
los obstáculos para tener una efectiva comunicación, además de hacer cumplir el sentido
de la identidad y unidad del equipo. Los equipos deben tener una total participación
en el Diseño, es importante ello porque cada rol tiene una única perspectiva del diseño
y sus relaciones con objetivos individuales.
Desde una perspectiva general el Modelo de Equipo de MSF se basa en la creencia que
6 son las metas claves de calidad (Role Cluster ó Grupo de Roles) que se deben de
llevar a cabo en orden para que un proyecto se considere exitoso. Estas metas guían al
equipo y definen el Modelo de Equipo. La clave es tener clara la determinación de los
individuos del equipo que son asignados para un específico Role Cluster y sus funciones
asociadas, responsabilidades y contribuciones hacia la meta principal.
En la siguiente tabla se describe los Role Cluster y la meta principal de cada unos de
ellos.
Role Cluster Meta Principal
1. Administración del Producto Satisfacer a los clientes.

2. Administración del Programa Entregar soluciones con las restricciones
del proyecto.
3. Desarrollo Construir las especificaciones.
Aprobar las versiones solo después de que

4. Pruebas los temas de calidad del producto sean
identificados y diseccionados.
5. Experiencia del Usuario Mejorar la eficacia de los usuarios.
6. Administración de Versiones Conseguir una tranquila implementación y

operaciones en curso.
TABLA 2: Metas de los Role Cluster del Modelo de Equipo [FP]
Finalmente, es relevante indicar que el Modelo de Procesos y el de Equipo,

complementan todos los principios fundamentales que nos presenta MSF y los cuales
son los cimientos para nuestra propuesta, como se muestra en la siguiente Ilustración.
Donde:
1. Fomentar la comunicación abierta (Foster Open Communications)
2. Trabajar hacia una visión compartida (Work toward a Shared Vision)
3. Facultar a los miembros del equipo. (Empower team members)
4. Establecer responsabilidades claras y responsabilidades compartidas (Establish clear
accountability and Shared responsability)
5. Centrarse en lo que se entrega de valor al negocio (Focus on Delivering Business
Value)
6. Mantenerse ágiles, esperando el cambio (Stay agile, expect change)
7. Invertir en calidad (Invest in Quality)
8. Aprende de todas las experiencias (Learn from all experiencies)
Modelo de Procesos Modelo de Equipo
1 3
2
7
5
6
8 4
ILUSTRACION 4: Relación de los Principios fundamentales con los Modelos
de Proceso y de Equipo de MSF [FP]
Los 6 Role Cluster del Modelo de Equipo de MSF son participantes activos de cada fase
de la propuesta metodológica.
La siguiente ilustración resume las fases de la propuesta metodológica de este trabajo de

tesis.
LUSTRACION 5: Fases del Ciclo de Vida del Almacén de Datos [FP]
Estas fases se describen a continuación detalladamente con sus respetivas tareas. Cada
Roles Cluster será un participante interactivamente activo en cada fase del ciclo de vida
del DWH.
FASE 0: ESTUDIO DE VIABILIDAD DEL DWH
Esta fase nos permite realizar un previo estudio de algunos criterios en la organización y
así determinar si el proyecto es posible realizar en la organización.
Los costos de construir un DWH son similares para cualquier proyecto informático, se
clasifican en tres categorías: [BI05]
− RRHH: Los usuarios que participen de la construcción deben contar con un enfoque
fuerte sobre el conocimiento del área de la organización involucrada y sus procesos
respectivos; los usuarios y el equipo deben de trabajar juntos, compartiendo
conocimiento y destrezas para enfrentar los desafíos de la construcción del DWH).
− Tiempo: Se debe establecer el tiempo no tan solo para la construcción y entrega de
resultados del DWH, sino también para el planeamiento del proyecto y la definición
de la arquitectura, ambos establecen un marco de referencia y un conjunto de
estándares que son críticos para la eficacia del DWH.).
− Tecnología: Muchas tecnologías nuevas son introducidas por el DWH, el costo de la
nueva tecnología puede ser tan solo la inversión inicial del proyecto).
Los costos de operación se presentan una vez que se haya construido y entregado el
DWH, este se debe mantener y actualizar para que tenga valor empresarial. Son
justamente estas actividades fuentes de continuos costos operacionales para el DWH. Se
distinguen tres tipos de costos de operación: [BI05]
− Evolutivos: Ajustes continuos del DWH a través del tiempo, como cambios de
expectativas y cambios como resultado del aprendizaje de los RRHH del proyecto
mediante su experiencia usando el DWH.
− Crecimiento: Incrementos en el tiempo en volúmenes de datos, del número de

usuarios del DWH, lo cual conllevará a un incremento de los recursos necesarios
como la demanda de monitoreo, la administración y la sintonización del DWH.
− Cambios: El DWH requiere soportar cambios que ocurren tanto en el origen de

datos que éste usa, como en las necesidades de la información que éste soporta.
Cuando se lleva a cabo el proceso del DWH, el impacto de los cambios es
compuesto, existiendo dos orígenes primarios de cambios:
 Cambios en el ambiente organizacional: Un cambio en el ambiente

organizacional pueden cambiar las necesidades de la información de los
usuarios, el contenido del DWH se puede ver afectados y el sistema de BI
pueden requerir cambios.
 Cambios en la tecnología: Un cambio en la tecnología puede afectar la manera
que los datos operacionales son almacenados, lo cual implicaría un ajuste en los
procesos ETL para adaptar las variaciones presentadas.
Los costos por evolución y crecimiento, son normales en un sistema operacional, el

costo por cambios es una tema que se debe de tener especial cuidado.
MILESTONE 0: Aprobación del Estudio de Viabilidad
Este milestone consiste en la entrega y aprobación del estudio de viabilidad del área
gerencial, siendo este milestone el punto de inicio para que se emprenda el proceso de
DWH en la organización.
Entregables
− Documento del Estudio de Viabilidad
Roles y Responsabilidades del Equipo en la Fase del Estudio de

Viabilidad del DWH
Todo el Equipo del DWH se encargará de efectuar este estudio en la organización.
FASE 1: VISIONADO
La Fase de Visionado del DWH, es una de las fases donde se obtienen los
requerimientos fundamentales para asegurar el éxito del proyecto, se realizan las
siguientes etapas y/o tareas resumidas en la siguiente ilustración:
FASE DE VISIONADO
Organización del Proyecto
Evaluación de la Solución
Definición de la Solución
MILESTONE 1:
Visión y Alcance Aprobados
ILUSTRACION 6: Fase de Visionado del Ciclo de Vida del DWH [FP]

ETAPA 1.1: Organización del Proyecto
I. ¿La organización esta preparada para un proyecto de BI (con un DWH inicial?
Cuando ya es factible realizar el proyecto del DWH, surge esta pregunta inicial y
básica para que se de inicio al proyecto del DWH (y así se inicie el proyecto de BI); una
decisión que se puede efectuar en esta fase sería de posponer el proyecto y el equipo
puede recomendar un número de pasos para llevar a acabo la preparación.
La preparación de la organización consta de varios ítems, según sea el tamaño de la

organización y el nivel de preparación que tengan en el momento, se recomienda de
todas maneras realizar estos ítems, por ejemplo: Exponer los casos exitosos del uso de
BI y la importancia del DWH dentro del proceso de BI, exponer beneficios claros para
la empresa, concientizar al área u organización de que todos formamos parte del
proyecto y la importancia vital de su participación activa en todo el proceso, el valor
agregado en la toma de sus decisiones. El equipo debe plantear otros ítems según su
experiencia y la organización lo requiera.
Si la organización se encuentra preparada para emprender el proyecto del DWH, el

equipo decidirá si es necesario que se realice los ítems mencionados, pero se
recomienda realizarlos para asegurar el conocimiento de la organización acerca del
DWH.
II. Visión del Proyecto
Se debe tener una clara visión de lo que se desea conseguir respecto a los clientes. La
Visión del Proyecto se refiere a aquellas soluciones que se pueden dar (perspectiva de lo
que se pueda realizar).
III. Identificación del Alcance del Proyecto del DWH
El Alcance se refiere a las partes de la Visión que se puede cumplir incluyendo las
limitaciones del proyecto.
Una buena definición del Alcance del Proyecto permite:

- Dividir la visión en partes alcanzables.
- Definir las características que se debe ejecutar en cada versión.
- Permitir la flexibilidad para el cambio.
El alcance tiene 2 aspectos: Alcance de la Solución, describe las características de la

solución, son aspectos notables de la aplicación o parte del hardware; el Alcance del
Proyecto de BI, se refiere al Alcance del proyecto final en términos de la BI.
Al definir el Alcance se impide cambios constantes en el ciclo de vida del DWH, tales
como el surgimiento de nuevos requerimientos. Es importante prevenir que los objetivos
que se cambien y/o que surjan nuevos requerimientos implicarían muchas veces
cambiar el Alcance, Visión y con ello la variación del Tiempo de Entrega de la
Solución.
IV. Identificación de las Restricciones del Proyecto

En este ítem se debe investigar sobre aquellos aspectos que son los limitantes, ya
sean del proyecto o de la solución, aspectos a tratar como, Tiempo de Entrega de la
Solución, insuficiente presupuesto que se invertirá, etc., estos aspectos se deben
desarrollar interactivamente con todas las actividades de esta primera fase para
identificar las restricciones.
V. Formación del Equipo de trabajo y asignación de responsabilidades
Formar el núcleo del Equipo y asignar sus responsabilidades a los encargados de los
Grupos de Roles.
La cantidad de personas que formarán el equipo puede variar, cada Role Cluster asigna
un número de personas teniendo en cuenta la cantidad y/o experiencia de cada uno en
los aspectos del Modelo de Equipo; varias personas pueden compartir Roles Cluster; es
decir, el hecho que existan 6 Role Cluster en el Modelo de Equipo no significa que se
necesite un mínimo de 6 personas, el punto clave es que se debe de cumplir 6 metas en
el equipo. Los miembros de los equipos pequeños deben compartir roles y para que se
consiga eficientemente esto, se debe tener en cuenta lo siguiente: Que los miembros del
Grupo de Rol de Desarrollo nunca deben compartir roles, estos se encargan de la
construcción del proyecto y no se deben distraer con otras tareas principales. Se debe
evitar combinar roles que tienen conflictos intrínsecos de interés.
En la siguiente Ilustración se explica claramente que roles pueden ser compartidos o no.
CAPITULO 2:ILUSTRACION 7: Combinación de Roles para proyectos pequeños

[BI20]
Donde:
N, U : No recomendados.
P : Posibles.
VI. Identificar las estrategias a seguir durante el ciclo de vida para la participación e
identificación permanente de los usuarios
El equipo debe de plantear una serie de estrategias que se ejecutarán para mantener viva
la relación entre los clientes, usuarios y la gestión. Estrategias como las que se
menciona a continuación son las que se deben extraer en este ítem:
- Reportar activamente y exponer casos exitosos de uso de proyectos de DWH y BI

respectivamente. La retroalimentación del usuario también ayuda a comprender
cómo evoluciona la implementación del DWH a través del tiempo para reunir
requerimientos de usuarios nuevamente identificados.
- Antes de iniciar una fase se deberá exponer los objetivos y beneficios a obtener con
la misma.
- Exponer y enfatizar que la participación empresarial o del área en estudio es vital
para cumplir el objetivo del Proyecto y conseguir el éxito del mismo.
- Destacar que la Comunicación es el medio que nos lleva al éxito, etc.
VII. Factores de Planificación del DWH
Se indican algunos puntos clave a considerarse en la planificación del DWH:
- Establecer una asociación de usuarios, gestión y grupos

Un efectivo involucramiento entre los usuarios y la gestión nos asegura que el DWH
contenga información que satisfaga los requerimientos de la empresa.
- Seleccionar una aplicación piloto con una alta probabilidad de éxito

Se refiere a desarrollar una aplicación piloto (prototipo inicial) con características
especiales tales como: Alcance limitado, reembolso medible para los usuarios y la
gestión; y con beneficios claros para la empresa.
- Construir prototipos rápida y frecuentemente

Un prototipo nos da la flexibilidad de reunir en mayor cantidad las necesidades de
los usuarios, se recomienda hacer el prototipo a lo largo del Proceso de
Implementación (y aún más).
- Desarrollar una Implementación Incremental

La implementación incremental reduce riesgos y asegura que el tamaño del proyecto
permanezca manejable en cada fase.
VIII. Estrategias para el Desarrollo de un DWH
Previamente al desarrollo del DWH, es crítico desarrollar una estrategia equilibrada

que sea apropiada para los propios requerimientos y usuarios del DWH.
Existe un número de estrategias mediante las cuales las organizaciones pueden

desarrollar sus DWH.
- Primera estrategia: Establecer un ambiente "DWH virtual"
Este se puede crear por:
 Instalación de un conjunto de facilidades para acceso a datos, directorio
de datos y gestión de proceso.
 Entrenamiento de usuarios finales.
 Control de cómo se usan realmente las instalaciones del DWH.
- Segunda estrategia: Construir una copia de la data operacional desde un sistema

operacional único.
Con esto se posibilita al DWH de una serie de herramientas de acceso a la

información. Esta estrategia tiene la ventaja de ser simple y rápida.
Desafortunadamente, si los datos existentes son de mala calidad y/o el acceso a los
datos no se ha evaluado previamente, entonces se puede crear una serie de
problemas.
- Tercera estrategia: La estrategia DWH óptima.
Consiste en seleccionar el número de usuarios basados en el valor de la empresa y

hacer un análisis de sus preguntas y necesidades de acceso a datos. De acuerdo a
estas necesidades, se construyen los prototipos del DWH y se prueban para que los
usuarios finales puedan experimentar y modificar sus requerimientos.
IX. Estrategias para el Diseño del DWH
El hecho que los usuarios finales tengan mayor dificultad en definir sus requisitos no
lo hace menos importante que en los sistemas operacionales. En la práctica, los
diseñadores de DWH tienen que valerse de muchos trucos, por decirlo de alguna
manera, para ayudar a sus usuarios a visualizar sus requerimientos. Por ello, son
esenciales los Prototipos, como una forma de estrategia para la obtención de requisitos
(diseño). Estas estrategias para el Diseño del DWH se evalúan por el Equipo del DWH
y/o se definen las que sean necesarias de acuerdo a la organización y el nivel de la
solución que se desee obtener.
X. Estrategias para la Administración de un DWH
Se debe considerar lo siguiente:
- La Administración tiene que pensar sobre cómo se desea un desempeño eficaz en el

DWH y cómo conseguirán llegar a los usuarios finales. (si y solo si un DWH si y es
una inversión óptima si los usuarios finales realmente pueden conseguir información
vital más rápida y más barata de lo que obtienen con la tecnología actual).
- La Administración debe reconocer que el mantenimiento del DWH es tan crítico

como el mantenimiento de cualquier otra aplicación.
- La Administración debe comprender también que si se embarcan sobre un programa

de DWH se crearán nuevas demandas sobre sus sistemas operacionales, que son:
 Demandas para mejorar la calidad en la data
 Demandas para una data consistente
 Demandas para diferentes tipos de datos, etc.
XI. Planificación de la Administración de Datos
Este ítem nos indica sobre que estrategias se debe organizar para obtener una data de
calidad, como punto inicial es analizar las fuentes de origen y concluir el estado de los
datos en cuanto a la calidad de los mismos. En el Proceso ETL de igual forma se lleva a
cabo, técnicas de limpieza de datos. Finalmente el proyecto del DWH, puede querer
realizar muchos aspectos de limpieza de datos, pero la empresa será el responsable final
de indicarnos hasta donde llegar y que realizar. Por ello en este punto es relevante
enfatizar la importancia de la Calidad en la Data a la organización, descrito con mayor
detalle en las políticas de calidad de datos que se propone en este trabajo de tesis.
ETAPA 1.2: Evaluación de la Solución
XII. Identificación y análisis de Riesgos potenciales antes/durante/después de la

elaboración del proyecto del DWH
Esta actividad se lleva a cabo en todo el ciclo de vida del proyecto. Este trabajo es
un trabajo que sólo concluye con el término del proyecto, es primordial constantemente
evaluar aspectos de riesgo para así poder prevenirlos a tiempo o en tal caso saber que
medidas ejecutar en el momento que se den. Es importante seguir la Disciplina de la
Administración de Riesgos de MSF, siendo estudiada y aplicada para siguientes
versiones de la metodología propuesta.
XIII. Identificación y análisis de los requerimientos del negocio
Esta tarea se refina rigurosamente en la Fase de Planificación, pero es necesario

comenzar con la obtención de requisitos para así evitar la ausencia de algunos al
término de la Etapa de la Obtención de Requisitos.
ETAPA 1.3: Definición de la Solución
XIV. Evaluación de los procesos en el área de estudio
Se indica los procesos encontrados en el área o en la organización de estudio,

además del flujo de datos de los mismos y de las personas involucradas.
XV. Identificar a los indicadores que ayudan a la toma de decisiones
En el momento de identificar los procesos involucrados fácilmente se pueden

extraer aquellos indicadores que ayudan a la toma de decisiones.
XVI. Análisis y elaboración del Flujo de Datos para la toma de decisiones

Se realiza todo el seguimiento de la data que se encuentra involucrada en el
proceso de la toma de decisiones y se identifica también a las personas involucradas en
el proceso de toma de decisiones.
XVII. Verificación de la soluciones
En este ítem se responde preguntas como: ¿Qué se desea analizar?, ¿Porque y

para qué se quiere analizar ello?
MILESTONE 1: Visión y Alcance Aprobados
Este milestone culmina con la Fase de Visionado, en este punto tanto el equipo como los
clientes se tiene que poner de acuerdo en toda la dirección del proyecto, como que
características de la solución se incluirán o no.
Entregables
- Trabajo en Power Point, presentación de la Fase de Visionado del DWH.

- Trabajo realizado en Power Point de la organización y el DWH.
- Documento de Visión/Alcance/Restricciones.
- Documento de Evaluación de la Solución.
- Documento de Estructura del Proyecto.
Roles y Responsabilidades del Equipo en la Fase de Visionado

Se centra en la obtención de las metas; identifica las necesidades de los clientes,
requerimientos; Documento Visión/Alcance/Restricciones.

Diseña las metas, concepto de solución, Documento de la Estructura el proyecto,
Documento de Evaluación de la Solución.
3 Desarrollo:
Análisis de las opciones de desarrollo y tecnología.

Trabajos de Power Point, necesidades e implicaciones de la participación de los
usuarios.
5 Pruebas:
Estrategias de Pruebas.
Implicaciones de la implementación, evaluación de los aspectos para desarrollar en
las versiones del proyecto.
FASE 2: PLANIFICACIÓN
En esta fase, la Planificación se completa y el equipo prepara las especificaciones de los

requerimientos, los trabajos a través de proceso de diseño y prepara planes de trabajo,
estimación de costos, etc.
La siguiente ilustración muestra las Etapas de la Fase de Planificación.
ILUSTRACION 8: Fase de Planificación del Ciclo de Vida del DWH [FP]
ETAPA 2.1: Identificación y Análisis de clientes y usuarios
Se resume los usuarios involucrados en los procesos de negocios en cuestión y para que
se logre este objetivo previamente es necesario estudiar el Flujo del Negocio y extraer
quien (es) son los responsables, paralelamente se necesita entender al sistema
operacional que se usa actualmente si lo hubiese, con esto se entiende también la
filosofía de trabajo de la organización.
ETAPA 2.2: Análisis de Requerimientos
Para que se obtenga los requerimientos, es necesario tener claro quien o quienes son los
clientes y usuarios de los procesos a estudiar. Una confirmación y revisión de la Etapa
anterior da al equipo confianza para seguir avanzando a paso firme.
En esta etapa se direcciona a un nivel alto las necesidades del ambiente completo del
DWH; consiguiendo, analizando y documentando los requerimientos, estos nos sirven
posteriormente para el Modelamiento del DWH.
Al culminar esta etapa se tendrá el documento resultante con la definición de

requerimientos, el cual se debe revisar por la totalidad de las partes involucradas.
El proceso de obtener los requerimientos de la organización es una tarea que cambia

constantemente, en un tiempo dado los requerimientos son verdaderos y luego no lo
son, pero entonces ¿como se va a identificar satisfactoriamente los requerimientos?, la
metodología de IBM expone que si se direcciona los requerimientos hacia las siguientes
interrogantes, probablemente se tiene la suficiente información para comenzar el
modelamiento del DWH.
- Cómo (la gente, los grupos, la organización) se interesa en el usuario.

- Qué (funciones) el usuario intenta analizar.
- Por qué el usuario necesita los datos.
- Cuando (para que periodo en el tiempo) los datos necesitan ser recordados.
- Donde (geográficamente, organizacionalmente) los procesos importantes ocurren.
- Como nosotros indicamos la ejecución o estado de las funciones que son analizadas.
I. Técnicas de Recolección de datos
Existen muchos métodos para hallar los requerimientos de la organización. En general,

estos métodos se pueden ubicar en una de las 2 categorías mencionadas de la
metodología propuesta por IBM.
ILUSTRACION 9: Técnicas de Recolección de los Requerimientos
(traducción) [BI09]
- Recolectando requisitos de las Fuentes de Origen (Source - driven requirements

gathering)
Esta categoría reúne los requerimientos mediante el Análisis de la Información

basado en el uso de las fuentes de origen de la data; es decir, los requerimientos se
hallan en el Análisis del Modelo ER de los sistemas operacionales de la
organización. Con ellos se investiga los documentos existentes (facturas, informes,
reportes, etc.), permitiendo al equipo conocer lo que se posee actualmente en la
organización y comprender las carencias actuales y futuras que deben ser resueltas
en el diseño del DWH, estos sistemas pueden ser usados para reunir y confirmar los
elementos que forman parte del sistema (tablas de sistema), objetos que produce el
sistema (informes, formularios, nuevos archivos de datos), objetos que se usan
(hardware y software), procesos que hay en la empresa (gestión de cobro, ventas,
recepciones), restricciones, criterios de validación y rangos de valores de entrada,
etc.
Una gran ventaja mencionada por IBM es que es importante porque se conoce el
origen y almacenamiento de los datos; además conlleva a que se comprenda la lista
de las mejores dimensiones para el interés de la organización (si se desea realizar un
DWH de la organización minimiza la proliferación de dimensiones duplicadas a
través del desarrollo separado de los Data Marts) e identificar las áreas donde se
debe enfocar los esfuerzos para el desarrollo del DWH. En contraparte, se minimiza
el involucramiento de los usuarios, si en caso se usara únicamente y exclusivamente
esta categoría. Otra desventaja que se añade es que esta tarea por si sola puede
consumir gran cantidad de tiempo en BD de gran volumen, se recomienda usar esta
categoría complementariamente.
- Recolectando requisitos de los usuarios (User - driven requirements gathering)
Esta categoría se basa en la definición de los requerimientos por la investigación de

las funciones que desempeñan los usuarios. Este método se usa generalmente
mediante una serie de encuentros, entrevistas o cuestionarios con la gente
identificada par el proceso.
Esta categoría es el punto principal de lo que se pretende obtener y se necesita en

cuanto a información. Se debe tener cuidado con las expectativas de los clientes y/o
usuarios, están deben ser administradas muy cuidadosamente por el equipo, se debe
hacer entender claramente lo que es posible y lo que no, como en Etapas anteriores
refiere nuestra propuesta.
Una de las más conocidas dentro de esta categoría son las Entrevistas, se obtienen
mediante sucesivas conversaciones dirigidas para conseguir algunos propósitos con
los representantes del departamento del usuario final y los clientes y usuarios;
asimismo el equipo debe ser capaz de validar el proceso de entrevistas y reforzar la
orientación del proyecto. En una entrevista debe haber un cierto clima de
cordialidad para que se produzca un mejor involucramiento y comunicación con el
entrevistado, además se debe preparar al entrevistado (concretar la fecha, hora y
pasarle un guión al entrevistado indicándole la mayor cantidad de alcances de la
entrevista para que el estructure su información). En la entrevista propiamente dicha
se toman notas, se graba en video o audio, o video conferencia con el debido
permiso; en la entrevista se procura conseguir respuestas objetivas. Finalmente al
término se hace un breve resumen de la entrevista y se agradece la atención
prestada.
Un modelo del Informe de la Entrevista se presenta en la siguiente tabla.
Informe de Entrevista
Fecha: 00 / 00 / 2007
Entrevistado : ______________________________________________
Cargo : ______________________________________________
Entrevistador : _____________________________________________
Tema : _____________________________________________
Objetivos de la entrevista: ¿Qué se quiere conseguir con la entrevista?

____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
Puntos principales de la entrevista: Opiniones del entrevistador:
___________________________ ________________________
___________________________ ________________________
___________________________ ________________________
___________________________ ________________________
___________________________ ________________________
___________________________ ________________________
___________________________ ________________________
___________________________ ________________________
___________________________ ________________________
___________________________ ________________________
___________________________ ________________________
___________________________ ________________________
¿Se lograron los objetivos? : (Si) - (No)
Observaciones adicionales:
__________________________________________________________
__________________________________________________________
__________________________________________________________
Compromisos para la próxima entrevista: (si la hubiese)

__________________________________________________________
__________________________________________________________
__________________________________________________________
ILUSTRACION 10: Modelo de Informe de Entrevista [FP]
Otra que se menciona en este tipo de categoría es el Cuestionario, es un documento

que nos permite complementar la entrevista. Sus tipos de preguntas son: Respuestas
abiertas, Si/NO y valoraciones puntuales (1, 2, 3).
Las Reuniones en la organización nos sirven de gran utilidad si se tiene:
 Objetivos definidos.
 Tiempo de duración adecuada.
 Si la reunión se puede realizar en la empresa de los interesados.
 Antes de comenzar todos los participantes tienen que saber las reglas de la
reunión (saber turnos de palabra etc.)
 Cada sesión tiene un objetivo (se da un informe con anticipación).
El uso de estas aproximaciones es opcional, se recomienda usar la unión de ellas en la

medida que el proyecto y el equipo lo requieran.
II. Realización de Obtención de Requerimientos y presentación de informes
Antes de lleva acabo la obtención de los requerimientos mediante las técnicas

especificadas en la Tarea I se indica a toda persona de la cual se extraerán los
requerimientos, de que tipo y la manera como se tratarán los temas y sobre todo la
importancia y seriedad en que deben tomarlos. Finalmente, esta se presentan los
informes respectivos.
III. Preparación de los Planes
El equipo prepara un plan general que es uno de los Entregables en la Fase de

Planificación y se relaciona con los roles y participaciones a lo largo del proyecto. Se
tiene por ejemplo los siguientes planes:
- Plan de Desarrollo (Expansión y Mantenimiento).

- Plan de Pruebas.
- Plan de Operaciones.
- Plan de Seguridad.
- Plan de Capacitación.
- Plan de Implementación.
- Plan de Adquisiciones.
- Plan de Obtención de Requisitos.
- Plan de Administración de Riesgos.
- Proyecto principal del programa. (incluye todos los detalles de los programas), etc.
Como grupo del DWH, el equipo revisa e identifica las dependencias entre estos planes.
Todos los planes son sincronizados y presentados juntos como un Plan de Proyecto
Master. Un beneficio que se observa al hacer un plan de la unión de otros pequeños es
que ellos facilitan la planificación en curso por varios roles del equipo y ofrecen
responsabilidades claras porque se especifican roles y responsabilidades para planes
específicos.
IV. Especificación de los Requerimientos
Después de determinar que técnica de recolección de los datos, se inicia la

construcción del Documento de las Especificaciones y se extiende en toda la Fase de
Planificación, siendo este el resultado del proceso de diseño, las especificaciones son
descripciones detalladas de las necesidades de información y los requerimientos del
DWH a desarrollar desde el punto de vista funcional, y cuanto de cada característica se
debe visualizar y ser operativa, se describe también la arquitectura y diseño de todas las
características. Estas especificaciones son la base para construir el Plan principal del
Proyecto y del Programa, sólo se pueden cambiar con la aprobación de los clientes y/o
usuarios.
Las especificaciones nos sirven para múltiples propósitos, tales como:
- Son instrucciones para que los desarrolladores sepan en que construir.

- Bases para la Estimación del Trabajo.
- Estar de acuerdo con los clientes y/o usuarios exactamente que se construirá.
- Puntos de sincronización de todo el equipo, etc.
Finalmente este Documento debe ser lo más claro posible, presentado y aprobado por la
Gerencia para que se pueda continuar con las siguientes fases.
Una aproximación de este documento sería como en la siguiente ilustración, pero este
documento se debe acomodar básicamente teniendo en cuenta la forma más eficiente
como la gerencia de la organización lo entienda o lo requiera:
Especificación de Requerimientos
Proyecto:
Número del Versión:
Anexos: (que se revisan o que se adjuntan)

Resumen:
La Especificación de Requerimientos se define de forma precisa como se va a construir
el software. Estas decisiones se basan en la información de los documentos del Plan de
Proyecto Master y de los Requerimientos de los usuarios, ambos deben satisfacer el
Diseño. Se verifica y validada por la Gerencia de la organización.
Requerimientos Funcionales:
1. Nombre de la Característica:
Prioridad: (Alta, Media, Baja)
Proceso:
Descripción: (explicar y detallar el requerimiento)
Requerimientos No Funcionales: (por ejemplo)**

- De Usabilidad (fácil acceso, interfaz amigable).
- De Confiabilidad.
- De Precaución.
- De Seguridad (acceso al sistema, derechos de usuarios, etc.)
Detalle: Contraseñas de que longitud, caracteres permitidos, omitidos, etc.
- De Desempeño y Escalabilidad.
- De Mantenimiento y Actualización.
- De Ciclo de Vida del Proyecto.
- De Hardware.
- De Software.
- De Importación y Exportación de datos. (BD, almacenamiento.)
** En cada tipo de requerimientos se debe Detallar de que forma se solicita.
Estado final del documento:
Se verifica y valida por la Gerencia de la organización.
ILUSTRACION 11: Modelo del Documento de la Especificación de

Requerimientos [FP]
Se recomienda enfocar los requerimientos desde cuatro puntos de vista (esto depende
del DWH a construir):
- Requerimientos del Negocio.

- Requerimientos del Cliente/Usuario.
- Requerimientos Operacionales.
- Requerimientos del sistema de BI.
V. Evaluación de la Tecnología
El equipo se encarga de evaluar los productos o tecnologías que se usarán para

construir e implementar la(s) solución(es). Esta elección involucra evaluaciones
comparativas entre las tecnologías rivales o proveedores que dan solución al DWH que
se construirá.
ETAPA 2.3: Modelamiento Dimensional
La técnica de modelamiento elegido para el DWH es el Modelamiento Dimensional.

Este tipo de modelamiento se debe de comprender por los clientes y/o usuarios.
Se debe de distinguir entre completar la Etapa de modelamiento y completar el modelo.

Al fin de esta etapa, se tiene un completo cuadro de los requerimientos. Sin embargo,
sólo parte de la metadata tendrá que ser documentada. Un modelo no puede ser
considerado verdaderamente completo hasta que el resto de la metadata sea identificado
y documentado durante la Fase de Planificación.
No existe exactamente una técnica a seguir para modelar datos, un diseñador se adecúa
diferentes factores, la guía que Ralph Kimball nos presenta se usará como base para
efectuar el Modelamiento Dimensional. (Ver Capítulo de Modelamiento Dimensional
para mayor explicación)
VI. Proceso para realizar el Modelamiento Dimensional (Kimball)
Una buena práctica antes de comenzar a modelar los datos es identificar los indicadores
y dimensiones sin nuestros requerimientos, partiendo de esas premisas, iniciar con los
requerimientos.
Paso 1: Seleccionar los Procesos de Negocio para el modelo

Se realiza el resumen de los Procesos de Negocios encontrados en la Fase de Visionado
(Etapa 1.3: Definición de la Solución). Se enfatiza nuevamente que no se refiere a un
departamento organizacional del negocio al hablar de Proceso de Negocio.
Paso 2: Declarar el Grano de cada Proceso de Negocio

Nos permite especificar el nivel de detalle de una fila individual de la Tabla de Hechos.
Es necesario que se lleve a cabo este paso. Este grano decidirá las dimensiones del
DWH.
Paso 3: Decidir las dimensiones que aplicar para cada fila de la Tabla de Hechos
¿Cómo la gente de negocio describe los datos que resultan de los procesos de negocio?,
se quiere decorar la Tabla de Hechos con un robusto conjunto de dimensiones
representando todas las posibles descripciones que toma un simple valor en el contexto
de cada indicador.
Paso 4: Identificar los hechos numéricos que poblarán cada fila de la Tabla de Hechos
¿Qué se está midiendo?, los usuarios de los negocios son los entusiastamente
interesados en analizar estos performance de las medidas de los procesos de negocio.
Un aporte de la Metodología de IBM, a los requisitos los agrupa como un conjunto de

interrogantes, y para analizar estas interrogantes, se definen Dimensiones e Indicadores
requeridos para encontrar los requerimientos. Esta tabla se recomienda completar
durante el modelamiento para mejor entendimiento del mismo.
REQUERIMIENTOS (PREGUNTAS REQ1 REQ2 REQ3 REQ4

RELACIONADAS )
DIMENSIONES
DIM1 X X
DIM2 X X
DIM3 X X
INDICADORES
IND1 X X
IND2 X X
IND3 X
TABLA 3: Ejemplo del Resumen de Dimensiones, Indicadores y Requisitos

[BI09]
Donde:
Q1, Q2, Q3, Q4 : Requisitos en forma de preguntas relacionadas.
DIM1, DIM2, DIM3 : Dimensiones encontradas.
IND1, IND2, IND3 : Indicadores de la organización.
Con este cuadro se permite revisar dimensiones y asegurarnos que las dimensiones, e
indicadores obtenidos cubren satisfactoriamente los requerimientos.
Este contexto la data gira en torno al Tiempo, por ello se debe añadir la Dimensión
Tiempo y su nivel de granulidad se obtiene del intervalo de tiempo que se requiera la
información analítica que la organización.
A la propuesta de Kimball se le añade algunos pasos complementarios para realizar un

modelo consistente de datos del DWH.
Paso 5: Análisis de la Granulidad y Aditividad

Como regla general, la data se debe guardar en el más alto nivel de granularidad (mayor
detalle) porque no se puede cambiar los datos hacia un nivel más alto que el que se
decidida guardar. Sin embargo, se puede realizar un Roll-Up (sumarizar) de la data para
crear una nueva tabla con un nivel más bajo de granularidad.
Junto la granulidad se debe decidir la Aditividad (capacidad de los indicadores para ser
sumarizados), especialmente cuando se considere posibles sumarizaciones que ocurrirán
en la Tabla de Hechos, habitualmente se aconseja que los indicadores sean
Completamente Aditivos para mayor facilidad en su uso.
Una vez que se tienen calculados la granularidad y aditividad que existen en los Hechos,
se debe de considerar la posibilidad de combinar hechos. Estos pueden ser requeridos
cambiando la granularidad de un hecho particular; usualmente, juntar hechos ampliará
el rango de análisis que puede ser ejecutado en el Hecho, esto es porque al unir hechos a
menudo implica añadir dimensiones para un hecho. Una primera aproximación para
evaluar las posibilidades de tal unión es determinar para cada indicador cuales
dimensiones adicionales se puede incrementar a su granularidad.
Los hechos se deben revisar para tener oportunidades de añadir dimensiones,

incrementando así el valor potencial del análisis.
VII. Integración con los modelos existentes de un DWH actual
Una vez que se concluya la Tarea VI, se busca proceder algunos procesos referidos
a la granularidad, aditividad con datos existentes del almacén (en caso que existiera
alguno), y hasta de Hechos y Dimensiones con el objeto de complementar el modelo,
sin que se llegue al exceso de restringir su capacidad para cambiar los hechos,
dimensiones e indicadores ya existentes.
VIII. Dar inicio a la Metadata
El modelo del DWH se usa continuamente; sus clientes y/o usuarios

constantemente hacen referencia al modelo para determinar los datos que se usa para el
análisis. El índice de cambios de la estructura en los datos en un DWH es mucho mayor
que las estructuras de datos operacionales. Por lo tanto, los usuarios técnicos del DWH
usarán su modelo regularmente como básico. Es aquí donde la metadata llega a ser
relevante.
Usualmente en este punto no se va a definir todo acerca de la metadata; sin embargo,

esto no significa que se deba esperar hasta donde se pueda. Adecuadamente se entiende
el modelo y este confirmará que requerimientos se conocen, un usuario debe tener
acceso a la metadata que describe el DWH en términos de negocios que estos son
fácilmente entendidos. Por lo tanto, la metadata no técnica debe ser documentada en
este punto. Durante las Etapas y Fases posteriores la metadata técnica se añadirá.
En un nivel del DWH, se debe de facilitar una lista sobre que esta disponible en el
DWH. Esta lista debe contener modelos, dimensiones, hechos e indicadores disponibles
como estos serán usados como puntos de entradas iniciales cuando un usuario empieza
el análisis de los datos.
Para cada modelo, proporcionar un nombre, definición y objetivo. Simplemente el

nombre da al usuario un enfoque para la búsqueda. Usualmente, esto es similar como el
hecho. La definición identifica que está modelado y el objetivo describe que modelo se
usa. La metadata para cada modelo debe también contener una lista de dimensiones,
hechos e indicadores asociados con el DWH, como también el nombre de la persona de
contacto para que los usuarios puedan agregar información adicional cuando ellos
tengan algunas dudas acerca del modelo.
Un nombre, definición y sobrenombres deben ser proporcionados para todas las

dimensiones, atributos, hechos e indicadores. Los sobrenombres son necesarios porque
estos a menudo llegar a dificultar la concordancia en los nombres comunes para cada
objeto ampliamente usado.
Para las dimensiones y hechos se debe de proporcionar a una persona de contacto. La

metadata acerca de una dimensión debe también incluir jerarquía, cambio de reglas,
frecuencia de la carga y los atributos, hechos e indicadores asociados con la dimensión.
La jerarquía define las relaciones entre atributos de una dimensión que identifica los
diferentes niveles que existen con ellos. El cambio de reglas identifica como cambian
los atributos en una dimensión. En algunas instancias, estas reglas pueden ser diferentes
para los atributos individuales. La frecuencia de la carga permite al usuario entender si
la data estará disponible cuando se le necesite.
Los atributos de una dimensión son usados para identificar que hechos los usuarios
quieren para analizar.
Los atributos son usados eficientemente, la metadata acerca de ellos debe de incluir
tipos de datos, dominios y reglas de derivación. En este punto, una indicación general
de los tipos de datos (caracter, date, numeric, etc.) es suficiente. La definición exacta del
tipo de dato puede ser realizado durante el diseño. El dominio de un atributo define el
conjunto de valores válidos que estos pueden almacenar. Para atributos que contienen
valores derivados, las reglas para determinar el valor debe ser documentado.
Metadata acerca de un hecho debe incluir la frecuencia de la carga, los indicadores y

dimensiones asociados con los hechos, y tiempo de cada hecho. Aunque esto es posible
para derivar el tiempo para cada hecho a través de sus relaciones la dimensión tiempo.
Metadata acerca de un indicador debe incluir su tipo de dato, dominio, reglas de

derivación, los hechos y dimensiones asociadas con los indicadores. Se facilita una
representación gráfica de la metadata y los caminos de acceso que podrían recorrer los
usuarios cuando analizarían su data. En la Ilustración 12 se presenta un ejemplo de una
metadata de un DWH.
ILUSTRACION 12: Ejemplo de la Metadata para un DWH [BI09]
ETAPA 2.4: Validación del Modelado
Antes de continuar con las siguientes etapas de planificación e invertir mucho tiempo y
esfuerzo en un modelado incorrecto. Para esta revisión se debe básicamente:
- Confirmar que el modelo que se ha realizado hasta el momento puede conocer los
requerimientos del usuario, y además la revisión confirma que el cliente y/o usuario
entienda el modelo. Recordar que una vez que el DWH es implementado, el usuario
confiará en el modelo en una base regular para acceder a la data en el DWH. No
importa cuan bueno el modelo conozca los requerimientos del usuario, el DWH
fallará si el usuario no puede entender el modelo y consecuentemente, no puede
acceder a la data.
- La validación se realiza en un alto nivel. El modelo se revisa con el cliente y/o

usuario para confirmar si entiende o no el modelo. Conjuntamente con ellos se
evalúa el modelo para resolver como se respondería algunas de las interrogantes
identificadas en los requerimientos.
Existe la posibilidad que no se conozca todos los requerimientos en el modelo o

necesiten ser mejor entendidos o tengan que ser cambiados o redefinidos; esto no
implica que se detenga y se regrese al inicio; en tal caso la data en cuestión se
envían a la Etapa de Análisis de Requerimientos y la data validada del modelo pasa
a una Fase Anexa, de Pruebas, para que luego se pueda continuar el ciclo de vida del
DWH. Esta iteración y la creación continua de modelos parcialmente completos son
elementos claves que proporcionan la facilidad para desarrollar rápidamente DWHs.
ETAPA 2.5: Diseño del DWH
En esta etapa se identificarán las fuentes de los datos (sistema operacional, fuentes
externas, etc.) y las transformaciones necesarias para que a partir de dichas fuentes,
obtener el Esquema Lógico del DWH. La mayor parte estas definiciones de los datos
del DWH estarán almacenadas en la Metadata. Los requerimientos de información
identificados en la fase anterior se usan como entrada para esta etapa.
IX. Selección de las Técnicas de Diseño
Para que se de inicio al proceso de diseño se determina que Técnica de Diseño se

usará, se distingue en [BI23] dos técnicas de diseño para el DWH:
- Técnica Top-Down:
Se construye el modelo el modelo general para toda la empresa y a partir de ahí se
construye el DWH de la organización y luego los Data Marts.
- Técnica Bottom-Up:
Se enfoca en el desarrollo de Data Marts pequeños, especializados en determinadas
áreas o procesos que en su conjunto forman la estructura del DWH. Conforme se
vaya desarrollando más Data Mart, el DWH abarca nuevas áreas de la organización.
Sin embargo, Ralph Kimball en [BI24] manifiesta que no existen estas dos técnicas
contrastantes y además que no se hace imprescindible la creación de una BD maestra,
completamente centralizada en el diseño de un DWH, como prerrequisito para que sus
partes sean sumarizadas y publicadas como Data Marts individuales. Ni es factible la
creación de un DWH empresarial desde un proceso de ensamblaje de Data Marts
construidos discordinadamente y no relacionados. Kimball propone la Arquitectura Bus.
- Arquitectura Bus:
Implica que cada dimensión usada en la creación de un Data Mart, debe haber sido
previamente definida según las necesidades empresariales de información, y no sólo
atendiendo a las necesidades de información atendidas por el Data Mart al que se
desea agregar la dimensión. El origen de este requerimiento está en lograr que dicha
dimensión responda al enfoque corporativo del sujeto que representa dentro del total
de la empresa y no únicamente a la visión que los usuarios de un Data Mart
particular puedan tener de el.
ILUSTRACION 13: Arquitectura de Bus [BI24]
Donde cada dimensión definida, será replicada en los distintos lugares en que sea
usada, en caso de un DWH corporativo distribuido, o simplemente compartida por
todas las estructuras dimensionales que intervienen en los distintos Data Marts
constituyentes del DWH. Las dimensiones definidas así, mantienen el concepto
corporativo que relaciona los datos del sistema y se denominan dimensiones
conformadas. En el mismo sentido se definen los hechos conformados como la
reconciliación de las diferentes medidas con la misma semántica que sería posible
definir en cada Data Mart.
Finalmente el concepto de bus se refiere a la representación gráfica, donde un bus

formado por las dimensiones definidas corporativamente, se conecta a cada nuevo
Data Mart que se crea.
Desde este enfoque los Data Mart, son un subconjunto lógico del DWH completo;
es decir son una restricción del DWH a un simple proceso de negocio o a un grupo
de procesos de negocio relacionados. Kimball impone algunos requerimientos de
diseño específicos para los Data Mart, como que cada Data Mart debe estar
representado por un modelo dimensional y dentro de un único DWH y todos los
Data Mart que formen un DWH deben estar construidos desde dimensiones
conformadas y hechos conformados1, respetando así la Arquitectura de Bus
definida. Y manifiesta que un Data Mart no debe estar formado por datos
sumarizados, sino que sostiene que los Data Mart deben estar basados en datos
atómicos, y pueden o no contener sumarizaciones que mejoren la performance.
Es preciso señalar que el Enfoque de la Arquitectura Bus es fácil de escalar para el

futuro, sin la necesidad de modificar las estructuras DWH que se ha construido.
Se debe especificar que Técnica de Diseño se usará para el diseño.
1
Dimensiones conformadas y los Hechos conformados en lo sucesivo se llamarán simplemente como
Dimensiones y Hechos respectivamente.
X. Estudio e identificación de las fuentes de datos
Es importante identificar y estudiar los recursos de la data que se usará para cargar
el modelo antes de comenzar con el diseño del DWH.
Las entidades de las fuentes se necesitan y deben ser documentados para mejorar la
consistencia del mapeo. También se toman en cuenta las reglas de negocios,
conversiones de dominio, etc., toda la metadata respecto al origen de los datos se debe
documentar para el modelo del DWH.
XI. Diseño Conceptual
Para llevar a cabo el Diseño Conceptual, se elegirá el Modelo CMDM (Conceptual

Multidimensional Data Model) [BI18], por tener un lenguaje gráfico, restricciones de
integridad que enriquecen la capacidad de expresión del modelo. CMDM es un modelo
conceptual orientado al diseño de estructuras multidimensionales que propone
estructuras de datos y un mecanismo de especificación de restricciones de integridad.
El Modelo CMDM distingue entre las Dimensiones que identifican los objetos de la
realidad y las Relaciones Dimensionales que representan las relaciones
multidimensionales existentes entre dichos objetos.
La estructura básica del CMDM se conforma de: [BI18]
- Niveles: Un nivel representa un conjunto de datos.
- Dimensiones: Representan los criterios de análisis.
 Con jerarquías formadas por niveles:

Los niveles se representan en jerarquías. Cada jerarquía esta compuesta por una
o mas niveles. En cada jerarquía se tiene una relación uno a muchos entre
objetos de nivel superior e inferior.
 Dimensionalidad genérica: Las medidas se tratan como dimensión más.
− Relaciones Dimensionales: Representan cruzamientos entre dimensiones.
Ejemplo:
Para que se facilite el entendimiento de la estructura básica del Modelo CMDM se da el
siguiente ejemplo.
En la siguiente Ilustración se muestra la definición gráfica de la Dimensión Artículos,

Clientes, Vendedores, Fechas y Cantidades del Modelo CMDM, las Dimensiones se
estructuran en Jerarquías con diferentes niveles de detalle; el nombre de la dimensión
está en la esquina superior izquierda del recuadro, los cuadros de texto son los niveles
de la dimensión, sus nombres aparecen en negrita y subrayados, debajo de estos
nombres, se hallan los atributos que la conforman y las jerarquías de niveles se
representan por flechas entre los niveles, del nivel con menos agregación (hijo) al nivel
con más agregación (padre).
ILUSTRACION 14: Representación Gráfica de Dimensiones en CMDM
[BI04]
Los cruzamientos entre dimensiones se denominan Relaciones Dimensionales, en la

siguiente ilustración se muestra la definición de la Relación Dimensional Venta en el
Modelo CMDM. En la relación se cruzan las Dimensiones: Artículos, Clientes,
Vendedores, Fechas y Cantidades.
ILUSTRACION 15: Representación Gráfica de las Relaciones Dimensionales

en CMDM [BI02]
En CMDM, una Relación Dimensional representa un espacio de cubos resultante de
cruzar niveles de las dimensiones. Una Relación Dimensional en realidad representa a
muchos cubos y este espacio de cubos puede restringirse mediante las restricciones de
integridad del propio modelo.
Las restricciones se construyen en base a predicados con cuantificadores (∀ , ∃, ¬) para

indicar que “Todos los cubos deben tener”, o “Debe existir un cubo que tenga” o
“Ningún cubo debe tener” dicha estructura. Ejemplo: Debe existir un cubo que cruce el
nivel Mes con el nivel Producto.
Estas restricciones sugieren qué cubos sería interesante tener y cuáles no deberían
existir. Sin embargo, la decisión de cuáles de esos cubos se deben materializar se debe
tomar posteriormente.
XII. Diseño Lógico Específico
En [BI02] al Diseño Lógico se le divide en Diseño Lógico Específico y Diseño

Lógico General, al cual se hará referencia.
El Diseño Lógico Específico se basa fundamentalmente en el Diseño Lógico

Dimensional. Se realizan las siguientes actividades:
− Definición del tipo de almacenamiento:
Se define el tipo de almacenamiento dependiendo del uso de tecnología relacional o

Dimensional. Según consideraciones de tamaño y grado de dispersión de la data
existente (por ejemplo, se puede optar por la tecnología relacional para el
almacenamiento de más bajo nivel de granularidad y tecnología Dimensional para
los resúmenes precalculados. Para esta propuesta fundamentalmente se enfoca en la
Tecnología Dimensional. Y para que se obtenga tal fin se utilizarán los
Lineamientos y Mapeos.
 Los Lineamientos:
Son información de Diseño Lógico que complementan al Modelo Conceptual y

permiten al diseñador dar pautas sobre el Esquema Lógico deseado para el
DWH.
Mediante los Lineamientos, el diseñador define el estilo de diseño para el DWH

(copo de nieve, estrella, mixto) e indica requerimientos de performance y
almacenamiento (por ejemplo indicando que cubos implementar), etc. En todos
los casos se trata de información adicional ingresada por el diseñador en forma
explícita.
Existen 3 tipos de lineamientos: [BI04]
• Materialización de Relaciones:
Permite indicar qué cubos se quieren materializar o realizar, atendiendo a
los requerimientos de performance y almacenamiento; es decir, este
lineamiento permite indicar qué cubos se quieren desarrollar.
En este contexto, materializar un cubo corresponde a precalcular los valores

para los cruzamientos de las dimensiones y almacenarlos en una tabla.
Luego se pueden obtener otros cruzamientos mediante operaciones
efectuadas sobre éstos.
En CMDM, un cubo se define mediante una macro que indica los niveles y
la medida del cubo [BI18]. Un cubo debe tener al menos un nivel de cada
dimensión, uno de ellos en el rol de medida. Consideramos que esta
característica es demasiado restrictiva y excluye algunos casos de interés y
que se necesita una definición de cubos más libre o relajada, donde además
de los cubos que se pueden especificar en CMDM se puedan representar:
♦ Cubos que no tengan medidas. Esto es interesante para representar sólo

cruzamientos.
♦ Cubos que omitan algunas de las dimensiones de la relación dimensional.

Esto tiene sentido cuando se quiere sumarizar totalmente la dimensión,
es decir, no se quiere detalle a ningún nivel sino simplemente el total de
la dimensión.
Como lineamiento, el diseñador debe indicar el conjunto de cubos que serán

implementados y almacenados físicamente en el DWH. Para que la
materialización se corresponda con el esquema conceptual, se debe indicar al
menos un cubo que materialice cada relación dimensional.
Un cubo esta formado por un nombre, una relación a la cual materializa, un

conjunto de niveles que forman su nivel de detalle, u opcionalmente un nivel
que es elegido como medida. Gráficamente se representan con un cubo
unido a varios niveles (rectángulo blanco) que conforman el nivel de detalle.
El nombre está dentro del cubo, y entre paréntesis el nombre de la relación
que materializa. Las medidas corresponden a los niveles marcados por una
flecha.
Por ejemplo, si se desease materializar tres cubos para la Relación

Dimensional Venta:
1- Con detalle de Artículos, Clientes, Vendedores y Meses.

2- Con detalle de Artículos, Rubros, Vendedores y Meses.
3- Con detalle de Artículos y Meses.
ILUSTRACION 16: Materialización de Relaciones, Cubo Ventas [BI04]
Se materializó la Relación Dimensional Ventas y se obtuvo: Cubo Ventas-1,

Cubo Ventas-2, Cubo Ventas-3 de la Relación Dimensional Ventas. El Cubo
Ventas-1 tiene por niveles: Meses, Artículos, Clientes, Vendedores; y por
medida a Cantidades.
• Fragmentación Vertical de Dimensiones:
Permite elegir el estilo de diseño deseado para el DWH, indicando el grado

de normalización que se desee desarrollar para las dimensiones, por ejemplo,
un esquema estrella, denormalizar todas las dimensiones en una sola tabla; o
un esquema copo de nieve, normalizando todas las dimensiones; o
estrategias mixtas, en este último caso, se indica qué dimensiones
desnormalizar, normalizar o fragmentar.
También se puede tratar de forma diferente cada dimensión, indicando para

cada una si se normaliza, denormaliza o efectúa una estrategia intermedia,
indicando, en este último caso, qué niveles se guardaran juntos.
En este lineamiento para cada dimensión, se indica qué niveles se desean

almacenar juntos, conformando una fragmentación de los niveles de la
dimensión.
Un fragmento es un subconjunto de los niveles de la dimensión que se

desean almacenar juntos. Se define por extensión una función que a cada
dimensión le haga corresponder un conjunto de fragmento.
Para que una fragmentación tenga sentido los niveles de cada fragmento
deben estar relacionados jerárquicamente; es decir, si se considera el grafo
que representa a la jerarquía de la dimensión, el subgrafo inducido por los
niveles del fragmento debe ser semejante. [BI04]
Ejemplo:
Si se decide seguir las siguientes estrategias de diseño para las dimensiones:

[BI04]
o Clientes: 2 fragmentos, uno con cliente y rubro, y el otro con los

restantes.
o Artículos: 3 fragmentos, uno con artículo y tamaño, otro con producto y
duración, y el otro con familia.
o Vendedores: Denormalizada.
o Fechas: Denormalizada.
o Cantidades: No se implementará, será utilizada como medidas.
La siguiente Ilustración muestra la representación gráfica de los fragmentos.

Los niveles coloreados con el mismo color pertenecen al mismo fragmento,
lo que significa que quieren almacenarse juntos.
ILUSTRACION 17: Fragmentación de Dimensiones [BI04]
• Fragmentación Horizontal de Cubos:

Permite almacenar por separado datos históricos, o dividir la instancia de los
cubos de acuerdo a los criterios del diseñador.
Una tabla hechos puede contener gran cantidad de información histórica lo
que la vuelve ineficiente para las consultas. Esta tabla se puede fragmentar
horizontalmente, guardando un subconjunto de las tuplas en cada fragmento,
lo que se denomina Bandas. Para definir una fragmentación, las condiciones
que distinguen una banda de otra, deben ser expresadas en términos de los
ítems de los niveles del cubo.
Existen dos propiedades [BI04] que se debe cumplir en la fragmentación

horizontal: Completitud y Disjuntez. La propiedad de completitud exige que
cada tupla esté en alguno de los fragmentos, y la propiedad de Disjuntez
exige que cada tupla que esté en a lo sumo un fragmento. Ejemplo:
Se considera la siguiente fragmentación:
La fragmentación no es completa, ya que las tuplas correspondientes a 1999

no pertenecen a ningún fragmento; y no es disjunta, ya que las tuplas
correspondientes a 1997 pertenecen a los dos fragmentos.
En el contexto de BD distribuidas, estas propiedades se deben cumplir para

asegurar la completitud de los datos consultados, minimizando la
redundancia. En el contexto del DWH, es importante que se considere estas
propiedades, pero no es necesario que se cumplan.
Si no se cumple la propiedad de Disjuntez se obtiene redundancia, pero esto

no es necesariamente un problema en un DWH. Por ejemplo, es común
mantener Tablas de Hechos con toda la historia, y tablas de hechos para los
datos del último año. Respecto a la Completitud, es relevante evitar la
pérdida de información a nivel global, pero no siempre se debe cumplir
localmente en la fragmentación de cada cubo. Ejemplo:
Se consideran dos cubos que materializan la Relación Dimensional Venta,

uno con detalle mensual y otro con detalle anual. Se realiza la siguiente
fragmentación sobre los mismos:
La fragmentación del cubo mensual es completa, pero la del cubo anual sólo
tiene información de los últimos años. Sin embargo, las tuplas que no
pertenecen al fragmento del cubo anual, pueden obtenerse a partir de los
fragmentos del cubo mensual, por lo que no hay pérdida de información.
Al haber redundancia, la completitud de las fragmentaciones debe ser
considerada globalmente. En esta propuesta no se exigirá que se cumplan las
propiedades, pero se sugiere tenerlas en cuenta durante la definición de la
fragmentación.
Ejemplo:
Gráficamente la fragmentación se representa como un bloque de llamada a

partir del cubo, dentro del bloque se escriben las franjas. La ilustración
muestra un conjunto de franjas asociado al Cubo venta-1. Las dos primeras
franjas determinan las ventas posteriores a enero de 2000 del vendedor Pérez
y del resto de los vendedores (menos Pérez). La tercera franja determina las
ventas anteriores a ene de 2000 de cualquier vendedor. La fragmentación es
completa y disjunta. [BI04]
ILUSTRACION 18: Fragmentación de Cubos [BI04]
 Un Mapeo:
Es una función que muestra como corresponden los objetos del Esquema
Conceptual con la(s) fuente(s) de origen. Los mapeos son funciones que asocian
a cada ítem de un objeto del Esquema Conceptual una expresión de mapeo,
construida en base a las tablas y atributos de la fuente de origen. Estas funciones
son definidas por el diseñador en forma explícita. Se tiene una función de mapeo
para cada fragmento de la Dimensión y una función de mapeo para cada Cubo.
Un cubo puede mapearse a las fuentes mediante una función de mapeo (mapeo
explícito) o puede indicarse como efectuar un drill-up respecto a otro cubo ya
mapeado, que tiene más detalle.
Una expresión de mapeo puede ser un atributo de una tabla fuente (directo), o un
cálculo que involucra varios atributos de una tupla (cálculo simple), o una
totalización que involucra varios atributos de varias tuplas (cálculo agregado) o
algo externo a las fuentes como una constante, una estampa de tiempo o dígitos
de versión.
Esta vinculación se realiza definiendo una función de mapeo que haga
corresponder los ítems del fragmento o cubo con las tablas fuentes.
Inicialmente se tiene una función de mapeo para cada fragmento de dimensión, y
una función de mapeo para cada cubo. Al fragmentar los cubos se obtiene una
función para cada franja de cada cubo.
Gráficamente una función de mapeo se representa por flechas entre los ítems de
un esquema intermedio y los atributos de las tablas fuentes. Cuando el mapeo es
directo se representa con una línea corrida, cuando es un cálculo se representa
con una línea cortada a cada atributo que interviene en el cálculo y se adjunta la
definición del cálculo y cuando es externo no se utilizan líneas pero se adjunta la
expresión a la que mapea.
En la vinculación de un fragmento o un cubo pueden existir condiciones, por

ejemplo que un atributo se encuentre en determinado rango. Estas condiciones
pueden deberse a restricciones en el esquema conceptual o a restricciones que
deseen aplicarse a las fuentes.
Las funciones de mapeo se utilizan en dos contextos:
• Mapeo de Fragmentos:
Este mapeo vincula los fragmentos de dimensiones con las tablas de las
fuentes de origen.
Para mapear un fragmento se debe definir una función de mapeo para todos
sus ítems, esto incluye algunos ítems de niveles superiores. Si corresponde,
se debe definir una condición que deban cumplir los atributos de las fuentes.
Cada función de mapeo representa una vista o expresión SQL que tiene en el
cabezal (SELECT) las expresiones de mapeo y obtiene los datos (FROM) de
las tablas referenciadas en dichas expresiones, imponiendo los links entre
las tablas como condición de Join (WHERE). Las tablas involucradas deben
tener links definidos, no tienen sentido los productos cartesianos.
En este ejemplo se asocia al fragmento de la Dimensión Geografía la

siguiente vista SQL:
Desde el punto de vista de las instancias, la instancia de la vista SQL debe
coincidir con la instancia esperada para el fragmento o cubo que se quiere
mapear (se mapea a sus ítems).
La vista SQL no se implementará, la generación del esquema lógico se hará

a través de transformaciones de esquemas que conducirán al mismo
resultado (posteriormente realizadas).
En la ilustración se muestra una función de mapeo para la Dimensión

Geografía, con un único fragmento (color rosa). El ítem país tiene un mapeo
externo de tipo constante, el ítem zona tiene un mapeo calculado en base al
atributo zona de la Tabla Departamentos. Los demás ítems tienen mapeos
directos.
ILUSTRACION 19: Mapeo de Fragmentos [BI04]
Además en el ejemplo, el nivel Zona puede tener una restricción indicando

que sólo interesan las zonas menores a 10, que pueden ser por ejemplo, las
zonas uruguayas. Esta es una restricción del esquema conceptual. También
puede ocurrir que en la Tabla Ciudades se almacenen ciudades necesarias en
varios sistemas o secciones y que para el DWH sólo interesen las que tienen
Clasificación R. Esta es una restricción respecto a las fuentes. Ambas
restricciones deben tenerse en cuenta al establecer los mapeos e incorporar
una condición tipo:
Estas restricciones pueden verse como condiciones adicionales de la vista

SQL. Para el ejemplo anterior se agregaría a la expresión:
Gráficamente las condiciones se representan como llamadas (Callouts). La
siguiente ilustración muestra la incorporación de las condiciones al mapeo
anterior.
ILUSTRACION 20: Incorporación de Callouts en el Mapeo de Fragmentos

[BI04]
Formalmente, las condiciones son predicados sobre atributos de las tablas

fuentes. Como en una condición pueden intervenir atributos de varias tablas,
se les pone como prefijo el nombre de la tabla para evitar ambigüedades.
Para definir las condiciones el diseñador debe tener en cuenta las

restricciones del esquema conceptual y expresarlas en término de los
atributos a los que mapean. Esta tarea se podría semi-automatizar tomando
como entrada las restricciones del esquema conceptual. El diseñador además
se debe basar en su conocimiento de las BD fuentes.
Considerar el mapeo de fragmentos como una consulta SQL ayuda en la

elección de los ítems adecuados. [BI04]
• Mapeo de Cubos:
Este mapeo vincular los cubos con las tablas fuentes.
Gráficamente un mapeo base de cubo se representa en forma análoga a un

mapeo de fragmento. En los niveles identificados por un único ítem pueden
omitirse los ítems. En los niveles identificados por varios ítems deben
detallarse todos. Dichos ítems pueden ser del nivel o identificadores de
niveles superiores cuando el nivel tiene clave débil. Mediante un pentágono
se especifican los predicados de roll-up para las medidas.
En la siguiente ilustración se muestra una función de mapeo para el cubo

Venta-1.
ILUSTRACION 21: Representación gráfica de un Mapeo del Cubo Venta-1
[BI04]
Un mapeo recursivo de cubo se representa uniendo los cubos por una flecha
gruesa. Se expresa la función de mapeo entre los ítems de los niveles base y
nuevos de manera análoga un mapeo base. Mediante un pentágono se
especifican los predicados de Roll-Up para las medidas.
La siguiente ilustración se muestra el mapeo del cubo venta-2 como un

Drill-Up del Cubo Venta-1 en la Dimensión Clientes (del nivel cliente, a los
niveles ciudad y rubro), por ello se indica mediante un mapeo como realizar
el Drill-Up.
ILUSTRACION 22: Representación gráfica de un Mapeo Recursivo de un

Cubo. [BI04]
Y por ultimo en la ilustración siguiente se muestra el mapeo del Cubo
Venta-3 como Drill-Up del Cubo Venta-1 eliminando dimensiones.
ILUSTRACION 23: Representación gráfica del Cubo Venta-3 [BI04]
Los mapeos base pueden pensarse como una consulta SQL al igual que los
mapeos de fragmentos. Valen las mismas consideraciones de elección de
atributos que para fragmentos, con la distinción de que se trata de realizar la
menor cantidad posible de joins por razones de performance. Es decir, que
siempre que se tengan definidas claves foráneas o se tenga confianza en la
calidad de los datos, se puede evitar el join de algunas tablas. En el ejemplo
del mapeo del Cubo Venta-2 se mapea el ítem id-cliente del nivel cliente al
atributo cliente de la Tabla Facturas en lugar de realizar un join con la tabla
Clientes y mapearlo allí. La instancia de esa consulta SQL debe coincidir
con la instancia esperada para el cubo.
Los mapeos recursivos simplifican la tarea de definición de mapeos.

Alcanza con que el diseñador realice los mapeos de los Drill-Up, en forma
análoga a como mapea un fragmento. Los mapeos de los fragmentos de las
dimensiones pueden ayudar a definir los mapeos de los Drill-Up. Se podría
realizar un mecanismo semi-automático para deducirlos a partir de los
mapeos de fragmentos.
− Presentación del Esquema Lógico:
Se presenta el Esquema Lógico conformado por el Modelo Dimensional resultante e

ilustración de los esquemas resultantes del Modelo Dimensional, compuestos por las
Tablas de Hechos y sus respectivas Tablas de Dimensiones.
 Modelo Dimensional:
Una vez que se diseñó los cubos, con sus respectivas Tablas de Hechos,
Dimensiones y medidas, se procede a realizar el Esquema Lógico, modelo de la
nueva BD que formará el DWH. Como los DWH se organizan en Esquemas de
Estrella o Copo de Nieve, implica una mayor facilidad del entendimiento de la
información y los datos por parte de o los usuarios, un mejor desempeño en las
consultas a la BD para aplicaciones de soporte de decisiones y demanda menor
espacio de almacenamiento para las BD robustas.
Como resultado de lo que se analizó anteriormente, se obtiene gráficamente el

Esquema Lógico o Modelo Dimensional, se indica que esquemas lo conforman
(Copos de Nieve, Estrella) representados por las Tablas de Hechos, sus
respectivas Dimensiones y las Relaciones entre ellas.
La siguiente ilustración es un ejemplo del Esquema Lógico o Modelo

Dimensional resultante para [BI02]. Este Modelo Dimensional esta compuesto
de tres Esquemas Copos de Nieve y un Esquema Estrella.
ILUSTRACION 24: Esquema Lógico o Modelo Dimensional [BI02]
 Sub-esquemas resultantes del Modelo Dimensional:
Para que se comprenda mejor el Modelo Dimensional del DWH que se obtuvo,
se detallan los sub-esquemas que lo componen, conformados por las Tablas de
Hechos y las Dimensiones relacionadas y finalmente en cada uno de ellos se
realiza su descripción.
Ejemplo:
Del Modelo Dimensional anterior, se extrae el esquema resultante siguiente:
Tabla Hechos Ventas 1:

La ilustración indica las relaciones existentes entre la Tabla de Hechos Ventas 1
y las Dimensiones: Vendedor, Clientes, Producto y Tiempo. Los atributos
cod_producto, cod_cliente, cod_vendedor e id_tiempo; compuestos, conforman
la Clave Primaria de la Tabla de Hechos. Este esquema permite obtener
información para el análisis de las ventas realizadas durante un determinado
período de tiempo, con un detalle mensual, y por cada ítem o línea de producto.
[BI02]
ILUSTRACION 25: Esquema Dimensional en Copo de Nieve de la Tabla de

Hechos Ventas1 [BI02]
XIII. Diseño Lógico General
El Diseño lógico General consta de dos partes:
− Esquema General:
Lo conforman la definición y la forma en que se va ha realizar la obtención de los

datos, transformación de los mismos, carga y descarga del modelo y la explotación
del DWH.
El esquema a utilizar en el desarrollo del proyecto contempla las siguientes

características, cada una de ellas se detalla a continuación: (para ejemplificar esta
etapa se extrae el ejemplo de [BI02])
1. Base Operacional:
Se indica la BD que contiene los datos a analizar.
Ejemplo: Progress versión 8.3b: Esta no posee un driver ODBC por lo cual los
datos son extraídos mediante un procedimiento desarrollado sobre la plataforma.
2. Archivos de Datos:
Éstos se crean al ejecutar el procedimiento y contienen los datos de la base
fuente. Los archivos serán creados en un formato Excel.
3. Transformación de Datos:
Será realizada mediante la herramienta que posee Microsoft SQL Server 2000
(Servicio de Transformación de Datos).
4. Arquitectura:
Se utiliza el sistema MOLAP incorporado en Microsoft SQL Server 2000 en la
herramienta de Analysis Services. Ésta posee una arquitectura de dos niveles: La
BD Dimensional, la cual es la encargada del manejo, acceso y obtención del
dato y el motor analítico, que es el responsable de la ejecución de los
requerimientos OLAP. El nivel de presentación se integra con el de aplicación y
proporciona una interfaz a través del cual los usuarios finales visualizan los
análisis OLAP.
5. Herramienta Front-End:
Tiene por función presentar la información de una manera más entendible al
usuario final, la cual pude contener datos tabulados y/o gráficos de diferentes
estilos.
Ejemplo: La herramienta a utilizar en esta propuesta será Excel, puesto que los
usuarios finales, ejecutivos de la organización tienen un mayor manejo en tal.
La ilustración que se muestra a continuación, describe gráficamente el proceso de

las cinco etapas descritas.
ILUSTRACION 26: Esquema General del Desarrollo [BI02]
− Diseño del Proceso ETL
Se diseñan los procesos de extracción, transformación, de carga/descarga del

modelo y refresque que poblarán el DWH, implican estrategias de limpieza,
notificación de errores y notificación de cambios detectados en los cambios
provenientes de las bases fuentes.
Se considera el uso de herramientas en lugar de realizar una codificación específica

debido a dos facilidades principales que ofrecen: La generación automática de
metadatos (data acerca de la ejecución de los procesos de carga de los datos) y las
facilidades para el mantenimiento de los programas de extracción, transformación y
carga.
Para el Proceso de Carga, primeramente se realiza la carga de las Tablas de
Dimensiones, y luego la carga de las Tablas de Hechos, ya que durante el proceso de
carga de una Tabla de Hechos se deben consultar todas las Tablas de Dimensiones
intervinientes previamente cargadas.
Ejemplo:
Para el caso en particular el diseño de las ETL se detalla a continuación: [BI02]

Los archivos generados en formato Excel por el sistema QAD (fuente de origen) son
extraídos, transformados y cargados al DWH por medio de una herramienta de SQL
Server 2000, más específicamente DTS (Data Tranformation Services, Servicio de
Transformación de Datos). En la ilustración se indica el Diseño del Proceso ETL
para el caso de estudio en [BI02].
ILUSTRACION 27: Diseño del Proceso ETL. [BI02]
XIV. Diseño de la Metadata
Se debe diseñar como se estructurara la metadata. Un ejemplo nos presenta la

Metodología de IBM en [BI09].
ILUSTRACION 28: Diagrama completo de la Metadata para el DWH [BI09]
XV. Diseño de Objetivos Adicionales
La razón fundamental de diseñar los objetivos adicionales es performance. Son

objetivos derivados desde el diseño original de Tablas de Hechos y Tablas
Dimensionales. Se debe considerar un máximo permitible de tiempo para una obtener
resultados de una interrogante.
La metadata para objetivos adicionales debe ser el mismo como los hechos y
dimensiones originales, además la metadata debe contener las razones para crear los
objetivos adicionales.
No es común pronosticar que Objetivos Adicionales se necesitará en la Etapa de Diseño

del DWH, debe existir una justificación clara para su creación.
Ejemplo:
Si un usuario frecuentemente ejecuta una interrogante que suma a través de una

dimensión y explora toda la tabla de hechos, seria recomendable que un objetivo
adicional se deba crear con la dimensión eliminada e indicadores sumados para producir
una tabla con menos filas para esta interrogante. Se debe crear sólo una dimensión
adicional si la dimensión original no se unirá apropiadamente con un hecho adicional.
En la Etapa del Diseño del DWH que se propone se tiene en cuenta que las tareas
presentadas son aspectos básicos del diseño, si al momento del desarrollo se requieren
agregar módulos y/o profundizar en los temas de diseño estos fácilmente se adaptarán a
la propuesta, se presenta el diseño del DWH en términos generales con el fin de obtener
una metodología consistente, coherente y completa en sus fases de desarrollo.
XVI. Estimación del Tamaño del DWH
Concluido el modelo y diseño del DWH se puede estimar la cantidad de espacio

requerido para almacenar datos en cada tabla. Para ello se efectúan los siguientes pasos:
(extraídos de [BI21]).
Para entender mejor este algoritmo, se extraen tablas de la misma fuente y se estima la
cantidad del espacio siguiendo al algoritmo.
Las tablas son:

TABLA 4: Tablas del DWH del Sistema de Apoyo Gerencial Universitario
[BI21]
Nombre Cant Cant Esp fijo Cant Max Null Tam dato var Tam col Pag por Filas Filas por pag Tam
Tabla col filas filas long bitmap filas libres tabla
var var por
pag
dwi_a_enc_rta 10 10 30 2 260 4 266 304 26 0 1 8192
dwi_act
8
# atributos de la tabla
Calcular aprox.
19309
24
smalldatetime: 1x4B = 4 smallint: 1x2B = 2 int: 6x4B = 24
1
# varchar en la tabla
10
varchar(255=) = 255 varchar(5) = 5
Donde: Num_Cols =10
3
2 + ( (10+7) / 8 ) =4 PASO 3:
Tamaño_var_max = 260 Num_col_variables = 2 Donde:
14
2 + (2*2) + 260 = 266 PASO 4:
Null_Bitmap = 4 tamaño_datos_var = 266 tamaño_datos_fijos = 30 Donde:
45 30 + 266 + 4 + 4 PASO 5:
tam_col =304 Donde:

8096 / (304+2) PASO 6:
172
0
Fill_Factor = 100 PASO 7:
Filas_por_paginas_libres = 0 Filas_por_pagina =26 Numero_filas = 10 Donde:
10 / (26-0) PASO 8:
113
Número_Páginas = 1 Donde:
8192 * 1= 8192 PASO 9:
925696
# atributos de la tabla
Calcular aprox.
smalldatetime: 1x4B = 4 smallint: 2x2B = 4 int: 4x4B = 16
# varchar en la tabla
varchar(10) = 10
Donde: Num_Cols =8
2 + ( (8+7) / 8 ) = 3 PASO 3:
Tamaño_var_max = 10 Num_col_variables = 1 Donde:

2 + (1*2) + 10 = 14 PASO 4:
tamaño_datos_var = 14 tamaño_datos_fijos = 24 Donde:
Null_Bitmap = 3 24 + 14 + 3 + 4 PASO 5:
tam_col = 45 Donde:
8096 / (45+2) PASO 6:
Fill_Factor = 100 PASO 7:
Filas_por_paginas_libres = 0 Filas_por_pagina = 172 Numero_filas = 19309 Donde:
19309 / (172-0) PASO 8:
Número_Páginas = 113 Donde:

8192 * 113 = 925696 PASO 9:
TOTAL BYTES 933.888
TABLA 5: Cálculo del espacio para las tablas indicadas como ejemplo [BI21]
Después de realizar el cálculo, se obtiene 934 MB de espacio que requiere el DWH, se
recomienda aumentar a esta cantidad en un 25% promedio (de acuerdo a los criterios del
equipo del DWH), este porcentaje es relativo, quedando 1.2 GB que se requiere de
espacio para almacenar el DWH en el disco.
ETAPA 2.6: Validación del Diseño
El objetivo en esta etapa es garantizar que las tareas del diseño se hayan realizado
eficientemente y que se tuvo en cuenta los requerimientos especificados en la Fase de
Visionado y de las etapas anteriores de la Fase de Planificación del DWH.
La Tabla siguiente muestra el bosquejo de la Validación del Diseño.
Tareas del Diseño del DWH Requisitos Verificación de Estado Final

los Requisitos de las tareas
de Diseño
(se indican requisitos
Selección de las Técnicas de involucrados en cada Todos/Ninguno/
Diseño tarea del diseño) indicar cuales
Estudio e identificación de las

fuentes de datos
Diseño Conceptual
Diseño Lógico Específico
Diseño Lógico General
Diseño de la Metadata
Diseño Objetivos Adicionales
TABLA 6: Validación del Diseño del DWH [FP]
También la Validación del Diseño se lleva a cabo con el usuario, el hands-on testing es
la mejor aproximación, se deja al usuario que intente responder las interrogantes a pesar
de la manipulación de un test objetivo. Aparte del testing, se revisa con el usuario
algunas adiciones y cambios para el modelo para asegurar que sean comprendidas.
Esta claro que lo que no se entienda o presente cualquier tipo de problema retorna a la
Etapa de Análisis de Requerimientos para su aclaración y retroalimentación al diseño, la
data validada del modelo pasa a una Fase Anexa, de Pruebas, para que luego se pueda
continuar con el Proceso de Elaboración del DWH.
MILESTONE 2: Plan de Proyecto Aprobado
Es la culminación de la Fase de Planificación, en este milestone los clientes y los

miembros del equipo están de acuerdo en los detalles en que se entregarán y cuando. El
equipo vuelve a evaluar los riesgos, actualiza las prioridades y establece los últimos
detalles de las estimaciones para los recursos y programas, aprueban especificaciones.
Los roles y responsabilidades son bien definidas y los mecanismos sirven para
direccionar las áreas de los riegos del proyecto.
Al terminar este milestone no significa que todas las decisiones que llegan a la Fase de
Planificación sean finales, el equipo debe revisar y aprobar algunas sugerencias
cambiantes.
Entregables
− Trabajo en Power Point, presentación de la Fase de Planificación del DWH.

− Plan de Proyecto Master.
− Documento de Especificaciones de los Requerimientos.
− Documento del Diseño de la Metadata y de los Objetivos Adicionales para el
Proyecto del DWH.
− Informe de Validación del Modelado.
− Informe de la Validación del Diseño.
− Documento del Modelo del DWH (Modelamiento, Diseño del DWH).
Roles y Responsabilidades del Equipo en la Fase de Planificación

Desarrollo del Diseño Conceptual, Análisis de los Requerimientos del Negocio, plan
de comunicación.
Desarrollo del Diseño Conceptual y Lógico (específico y general), Especificaciones
de los requerimientos, plan principal del proyecto, proyecto principal del programa.
9 Desarrollo:
Evaluación de la tecnología, Diseño Lógico y Físico, desarrollo del Plan/Programa,
desarrollo de las estimaciones.
Uso de escenarios/uso de casos, requerimientos del usuario, localización y
accesibilidad de los requerimientos, documentación del usuario/preparación del
plan/programas para la utilidad de las pruebas, capacitación.
11 Pruebas:
Validación del modelo, Validación del Diseño, pruebas del modelado, pruebas del
diseño, Prueba plan/programa.
Evaluación del Diseño.
FASE 3: DESARROLLO
Durante la fase de Desarrollo el equipo logra la mayor parte de la construcción de los

componentes de la solución (se desarrolla código, se pobla el DWH con datos, etc.); sin
embargo, parte de este trabajo continúa en la Fase de Estabilización en respuesta a las
pruebas.
La Fase de Desarrollo involucra más que desarrollo de código y de software; la

infraestructura también se desarrolla durante esta fase y todos los roles están activos en
los entregables del desarrollo y las pruebas que los criterios de aceptación sean
conocidos.
Un aspecto importante de esta fase es la preparación de un documento de

mantenimiento que informa sobre futuras referencias, entre ellas las características de
las versiones futuras, procesos de mantenimiento, etc.
La siguiente ilustración muestra las Etapas de la Fase de Desarrollo.
ILUSTRACION 29: Fase de Desarrollo del Ciclo de Vida del DWH [FP]
ETAPA 3.1: Consideraciones de la Solución
Se debe tener en cuenta los siguientes ítems: [BI10]

− Definir el mejor diseño físico para el modelo de datos. El diseño físico debe estar
orientado a generar buen rendimiento en el procesamiento de consultas, a diferencia
del modelo lógico que está orientado al usuario y a la facilidad de consulta.
− Definir los procesos de Extracción, filtro, Transformación de información y Carga

de datos que se deben efectuar para poblar el Modelo de Datos.
− Definir los procesos de Administración de la data que permanece en el DWH.
− Definir técnicas de explotación del DWH dependiendo del tipo de aplicación que se
le de a la data: Query & Reporting, OLAP, Sistemas de Información Ejecutivos,
Sistema de Apoyo a Decisiones, Visualización de la información, Minería de Datos,
etc. Estas técnicas deben estar directamente vinculadas con el Proceso de
Inteligencia de Negocios que el equipo posteriormente empleará.
ETAPA 3.2: Construcción del Documento del Desarrollo
En esta etapa se especifica los módulos desarrollados del DWH, ilustrando lo realizado
con gráficas y cualquier método que el equipo lo acuerde.
ETAPA 3.3: Validación del Desarrollo
Es importante que los módulos, procesos de desarrollo de software, y cualquier

aplicación que se desarrolle se verifique probando la funcionalidad, previamente a las
fases posteriores con la finalidad de ir refinando la solución para que culmine sin
errores. Esta etapa la efectúa el Equipo del DWH y los usuarios.
MILESTONE 3: Alcance completo
La Fase de Desarrollo culmina con al Milestone Alcance Completo. En este milestone,

todas las características se completan y la solución esta preparada para pruebas externas
y la estabilización.
Este milestones es la oportunidad para clientes y usuarios, operaciones y apoyo al

personal y evaluar la solución e identificación de algún tema restante que debe ser
diseccionado antes que la solución haya sido liberada. Es importante señalar que
número de Build se realizó, así como por ejemplo: Build Interno N completo, Build
Interno N+1 completo.
Entregables
- Trabajo en Power Point, presentación de la Fase de Desarrollo del DWH.

- Fuentes de Código y Ejecutables.
- Documento de Instalaciones y configuraciones.
- Documento del Desarrollo del DWH.
Roles y Responsabilidades del Equipo en la Fase de Desarrollo

Expectativas del Cliente.

Administración de las Especificaciones de los requerimientos, trayectoria del
proyecto, actualización de planes.
3 Desarrollo:
Desarrollo de código, infraestructura de desarrollo, Fuentes de Código y
Ejecutables.

Trabajo en Power Point, Preparación del Documento del Desarrollo del DWH.
5 Pruebas:
Prueba Funcional, temas de identificación, actualización del plan de prueba.
Creación y/o actualizaciones del Plan de Extensión y planes pilotos.
FASE 4: ESTABILIZACION
La Fase de Estabilización se conduce por las pruebas que se efectúan a las soluciones
que sean completas. Estas pruebas enfatizan el uso y operación bajo condiciones de un
ambiente real, el equipo se enfoca en resolver errores y preparar la solución para las
versiones. Durante esta fase son comunes las pruebas para reportar los errores.
La siguiente ilustración muestra las Etapas de la Fase de Estabilización.
ILUSTRACION 30: Fase de Estabilización del Ciclo de Vida del DWH [FP]
ETAPA 4.1: Verificaciones
Para asegurar la estabilidad y el correcto funcionamiento del DWH, se deben priorizar

tareas diferentes a diferencia de los sistemas operacionales, debido a su orientación a la
toma de decisiones. Las pruebas garantizan la estabilidad del DWH antes de que sea
llevado con el cliente y/o usuarios.
I. Identificación y corrección de los errores
En esta tarea se pretende detectar los errores de todo nivel y darles su inmediata
corrección, a fin de que se evite su propagación. Se verifica la data que ingresa al DWH,
el funcionamiento del DWH, etc.
MILESTONE 4: Versión aprobada
Este milestone ocurre cuando el equipo tiene direccionado todos los temas destacables
esta etapa y tiene versionada la solución o un lugar en el servicio. Una vez que se ha
corregido los errores entonces la versión esta lista para ser Aprobada y utilizada.
Al término de las verificaciones que realiza el Equipo del DWH, estas se concluyen con
la Aprobación Formal de la Prueba de Aceptación del DWH. Esta aprobación involucra
verificar que la prueba de un ambiente específico se tiene que ejecutar y se incluya las
funcionalidades basados en los requerimientos, además esta Aprobación Formal es parte
del milestone.
Entregables
− Trabajo en Power Point, presentación de la Fase de Estabilización del DWH.

− Informe de la ejecución de las pruebas y los resultados a los módulos de la solución
(test, herramientas de prueba, Fuentes de Código y ejecutables probados).
− Informe del Milestone Versión Aprobada.
Roles y Responsabilidades del Equipo en la Fase de Estabilización

Desarrollar las planificaciones.
Seguir la trayectoria del proyecto, identificar errores.
3 Desarrollo:
Resolución de errores, optimización de código.
Trabajo en Power Point, Estabilización y entrenamiento con el usuario.
5 Pruebas:
Realización de pruebas, reporte de errores y estados.
Programa piloto y apoyo, uso de la planificación.
FASE 5: UTILIZACION
Durante esta fase, el equipo utiliza el núcleo de la tecnología, sitúa los componentes,
estabiliza el uso, transiciona al DWH para operaciones y apoyo; y obtiene la aprobación
final de los clientes y/o usuarios del DWH. Después de la utilización el equipo conduce
al DWH a la revisión y a una encuesta de satisfacción del cliente.
Las tareas de estabilización pueden continuar durante este periodo como componente
del DWH se transfiere desde un ambiente de prueba para un ambiente de producción.
La siguiente ilustración muestra las Etapas de la Fase de Utilización.
FASE DE UTILIZACION
Actividades para el uso del DWH
MILESTONE 5:
Implantación aprobada
ILUSTRACION 31: Fase de Utilización del Ciclo de Vida del DWH [FP]
ETAPA 5.1: Actividades para el uso del DWH
I. Preparar material de capacitación del DWH
Se realiza material impreso y/o gráfico sobre el uso y funcionalidad del DWH,
presentando un resumen del Ciclo de Vida del DWH en la organización y de la
importancia de un uso efectivo. Se recomienda presentar esta información en un
formato amigable para la organización.
II. Comparación Alcance/Solución
Se efectúa una comparación entre el Alcance definido en la Fase de Visionado y la

Solución que se obtuvo con el fin de contrastar la coherencia de ambos.
III. Definir los siguientes pasos a seguir
Esta propuesta metodológica nos permite culminar la Fase1 del proceso de

Inteligencia de Negocios, que es el Desarrollo del DWH, el equipo se debe proyectar a
los nuevos objetivos que el proceso de BI y la organización lo requiera.
MILESTONE 5: Implantación aprobada
Este milestone culmina la Fase de Estabilización, la solución de esta fase debe estar
proporcionando las expectativas del valor del negocio para el cliente y el equipo debe
tener eficazmente terminado los procesos y las actividades para llegar a alcanzar las
metas.
El cliente debe estar de acuerdo que el equipo ha conocido sus objetivos antes de que
estos sean declarados como una solución en el DWH o se haya concluido el proyecto.
Entregables
− Trabajo en Power Point, presentación de la Fase de Utilización del DWH.

− Guía/Manual del DWH realizado (funcionalidad, uso, proceso de elaboración).
− Informe del Milestone Implantación Aprobada (datos de satisfacción del cliente y/o
usuario).
− Documento de Comparación Alcance/Solución y de la Definición de los siguientes
pasos a realizar para continuar el Proceso de Inteligencia de Negocios.
Roles y Responsabilidades del Equipo en la Fase de Utilización

Retroalimentación al cliente, revisiones.
Comparación solución/alcance.
3 Desarrollo:
Resolución del problema.
Entrenamiento de la administración del DWH.
5 Pruebas:
Prueba de performance.
Cambios aprobados.
FASE 6: EVALUACIÓN
La Fase de Evaluación es la fase final y analítica del proceso del DWH y nos permite
estimar algunos aspectos del valor agregado para la organización y las tomas de
decisiones respectivamente.
La siguiente ilustración muestra las Etapas de la Fase de Evaluación.

ILUSTRACION 32: Fase de Evaluación del Ciclo de Vida del DWH [FP]
ETAPA 6.1: Impactos del DWH
Como ya se hizo referencia el éxito de un proceso de DWH no se encuentra

exclusivamente en su elaboración, sino en su uso efectivo para mejorar procesos
empresariales, operaciones y decisiones. Posicionar un DWH para que sea usado
efectivamente, requiere entender los impactos de elaboración en los siguientes aspectos.
[BI05]
I. Impactos Humanos
Son aquellos resultados que se presentan sobre la gente de la organización.
− Construcción del DWH:

A diferencia del desarrollo de sistemas en los cuales los requerimientos de la
organización se encuentran bien definidos a través del tiempo, construir un DWH
depende de la realidad organizacional como de sus condiciones actuales, las cuáles
determinan qué debe contener el DWH. La gente de la organización debe participar
activamente durante el ciclo de vida del DWH.
− Accediendo al DWH:
El DWH proveerá data que permitirá a los usuarios a acceder a su propia
información cuando ellos la requieran. Esta aproximación implica lo siguiente:
 La gente de la empresa puede necesitar aprender nuevas destrezas.

 La aparición de nuevas oportunidades en la organización para los especialistas
de información.
 La gran cantidad de reportes en papel serán reducidas o eliminadas.
 La madurez del DWH dependerá del uso activo y retroalimentación de sus
usuarios.
− Usando aplicaciones para el sistema (especialmente en el Proceso de BI):
Los usuarios de estas aplicaciones necesitarán menos experiencia para construir su

propia información y desarrollar nuevas destrezas. Es decir, que para los usuarios, el
DWH extiende el alcance de la información para que puedan acceder directamente
en línea, lo que a la vez contribuye en su capacidad para operar con mayor
efectividad las tareas diarias relacionadas con la toma de decisiones.
Los usuarios del DWH pueden acceder a una variada información que puede ser
vista de forma multidimensional, presentada como una fuente única confiable y
disponible directamente por medio de sus estaciones de trabajo. Los usuarios
pueden usar sus herramientas familiares, hojas de cálculo, procesadores de textos y
software de análisis de datos y análisis estadístico para manipular y evaluar la
información obtenida desde el DWH.
II. Impactos Empresariales
− Procesos Empresariales y Decisiones Empresariales:

Se deben considerar los beneficios empresariales potenciales de los siguientes
impactos:
 Los Procesos de Toma de Decisiones pueden ser mejorados mediante la

disponibilidad de información, las decisiones se realizan más rápidas y con
gente más informada.
 Los procesos empresariales pueden ser optimizados. El tiempo perdido
esperando por información que finalmente es incorrecta o no encontrada, es
eliminada.
 Conexiones y dependencias entre procesos empresariales se vuelven más claros
y entendibles, las secuencias de los procesos organizacionales se pueden
optimizar para ganar eficiencia y reducir costos.
 Procesos y datos de los sistemas operacionales, así como los datos en el DWH,
son usados y examinados; cuando la data se organiza y estructura para tener
significado empresarial, la gente aprende mucho de los sistemas de información;
se exponen posibles defectos en aplicaciones actuales, siendo posible entonces
mejorar la calidad de las nuevas aplicaciones.
− Comunicación e Impactos Organizacionales:

Cuando el DWH comienza a ser la fuente primaria de información empresarial
consistente, los siguientes impactos pueden comenzar a presentarse:
 La gente tiene mayor confianza en las decisiones empresariales que se toman.

Quienes toman la decisión y los afectados conocen que ésta se basa en
información confiable.
 La gente queda mejor capacitada para entender su propio rol y responsabilidades
como también los efectos de sus contribuciones y a la vez, desarrollan un mejor
entendimiento y apreciación con las contribuciones de otros.
 La información compartida conduce a un lenguaje común, conocimiento común,
y mejoramiento de la comunicación en la empresa; mejorándose así la confianza
y cooperación entre distintas áreas de la organización.
 La visibilidad, accesibilidad y conocimiento de los datos producen mayor
confianza en los sistemas operacionales y fomenta aún más su uso.
III. Impactos Técnicos del DWH

Se tienen los siguientes impactos técnicos:
− Nuevas destrezas de desarrollo:

Cuando se elabora el DWH, el impacto más grande sobre la gente técnica está dada
por la curva de aprendizaje, muchas destrezas nuevas se deben aprender, incluyendo
conceptos y estructura del DWH.
 El DWH introduce muchas tecnologías nuevas (ETL, Acceso de Datos, Catálogo

de Metadatos, etc.), y cambia la manera que se usa la tecnología existente.
Nuevas responsabilidades de soporte, nuevas demandas de recursos y nuevas
expectativas, son los efectos de estos cambios.
 Destrezas de diseño y análisis donde los requerimientos organizacionales no son
posibles de definir de una forma estable a través del tiempo.
 Técnicas de desarrollo incremental y evolutivo.
 Trabajo en equipo cooperativo con gente de negocios como participantes activos
en el desarrollo del proyecto.
− Nuevas responsabilidades de operación:

Los cambios sobre los sistemas y datos operacionales deben ser examinados
cuidadosamente para determinar el impacto que estos cambios tienen sobre ellos y
sobre el DWH.
El DWH enriquece las capacidades del usuario autosuficiente y hace que la gerencia
pueda ofrecer nuevos servicios a los usuarios, sin interferir con las aplicaciones
cotidianas de producción, aunque se requiere una asignación de tiempo y personal
técnico para el mantenimiento y operación del DWH.
ETAPA 6.2: Valor del DWH para la Toma de Decisiones
El valor de un DWH queda descrito en tres dimensiones: [BI06]
− Mejorar la Entrega de Información:

Información completa, correcta, consistente, oportuna y accesible; información que
la gente necesita, en el tiempo que la necesita y en el formato que la necesita.
− Facilitar el Proceso de Toma de Decisiones:

Con un mayor soporte de información se obtienen decisiones más rápidas y la gente
de negocios adquiere mayor confianza en sus propias decisiones y las del resto, y se
logra un mayor entendimiento de los impactos de sus decisiones.
− Impacto Positivo sobre los Procesos Organizacionales:

Cuando se accede a una mejor calidad de información, la organización puede
mejorar:
 Eliminando los retardos de los procesos empresariales que resultan de

información incorrecta, inconsistente y/o no existente.
 Integrar y optimizar procesos organizacionales a través del uso compartido e
integrado de las fuentes de información.
 Eliminar la producción y el procesamiento de datos que no son usados ni
necesarios, producto de aplicaciones mal diseñados o ya no utilizados.
ETAPA 6.3. Balance Costo/Valor
Lograr una cuantificación económica de los factores de valor no es fácil ni natural a

diferencia de los factores de costos, agregar valor económico a los factores de valor
resulta ser en extremo complejo y subjetivo. Una alternativa es hacer una valoración
desde la perspectiva de costos evitables, relacionados con los costos de no disponer en
la organización de información apropiada, para el proceso de Toma de Decisiones.
En este tipo de proyectos es difícil estimar de antemano con exactitud los beneficios
económicos, aunque si el valor que introduce en la organización que se implementa,
pero se puede mostrar en base a estadísticas realizadas el beneficio que se obtendrá al
mediano y largo plazo.
En un estudio encargado a la compañía Gartner Group por 20 vendedores y consultores,

se encontró un Retorno Promedio Total de la Inversión (Return On Investment, ROI) de
401% en 2.3 años. El estudio se realizó sobre 62 organizaciones que implementaron
sistemas de apoyo gerencial basados en un DWH. En este estudio se excluyeron los
proyectos fracasados, así como los ejecutados por fuera del cronograma y costos debido
a que sólo interesan los proyectos que fueron ejecutados e implementados
correctamente desde el punto de vista de todas las áreas de Ingeniería de Software
(fundamentalmente Planificación y Gestión de Cambios). [BI21]
Este estudio se resume en siguiente tabla:
ILUSTRACION 33: ROI de proyectos de DWH [BI21]
El DWH es una estrategia de largo plazo. Al elaborar un DWH, se debe evaluar el costo
y el valor considerando un período de tiempo razonable para obtener beneficios. El
retorno sobre la inversión de un DWH, se comienza a percibir bastante más tarde del
tiempo en el cual se realizó la inversión inicial. Hacer un análisis del costo/valor desde
una perspectiva a corto plazo, después de un tiempo de haber concluido el DWH, los
costos serán significativamente más altos en proporción al valor inicial, de esta manera
se evalúa el valor agregado en los procesos involucrados en el DWH de la organización
Entregables
− Trabajo en Power Point, presentación de la Fase de Evaluación del DWH.

− Documento General de la Evaluación del DWH.
Roles y Responsabilidades del Equipo en la Fase de Evaluación
El Rol Cluster de Administración del Producto, Administración del Programa,

Desarrollo, Experiencia del Usuario, Pruebas, Administración de Versiones, en su
conjunto se encargan de evaluar el Impacto, Valor y Balance Costo/Beneficio del DWH
en la organización.
9.1 CONSIDERACIONES IMPORTANTES
Esta metodología se realizó creando el Plan Multi-Versiones basando en la guía

metodológica Microsoft Solution Framework, quedando así:
Primera Versión:
Realización del centro funcional de la metodología; es decir, la elaboración propiamente
dicha de la propuesta metodológica integrada con el Modelo de Procesos y el Modelo
de Equipo de MSF, además de recomendaciones y guías que MSF presenta.
Segunda Versión:
En esta versión, se centra en el tema de la Calidad de la Data y la integración de esta en
la propuesta metodológica ya realizada.
Versiones Posteriores:
En las versiones posteriores y ajenas al alcance de este trabajo de tesis, se dejan
aspectos de Administración de Riesgos (mayor detalle), Administración de Proyectos,
Administración de la Preparación y otros aspectos que se presenta en MSF, no siendo
estos menos importantes que los primeros.
Un aspecto fundamental a considerar es que en la elaboración de la propuesta

metodológica se elaboró mediante este Plan Multi-Versiones, pero al momento de
desarrollar un DWH se recomienda constantemente realizarlo también por Versiones
para la mejora constante del DWH, las funciones de cada versión se debe asignar por el
equipo de desarrollo.
La elección de algún Algoritmo de Optimización del DWH, se basa fundamentalmente

en la manera de adaptarse a las necesidades o a la realidad del DWH, quedando su uso
a disposición del equipo del DWH como ya se mencionó.
Para la realización de esta propuesta se tuvo varios motores de interés para desarrollar
un proyecto de esta magnitud, entre ellos es la ausencia de una metodología abierta que
cubra el aspecto inicial de la Inteligencia de Negocios que es el Desarrollo del DWH,
ahora bien dentro de las pocas metodologías para este fin, se observó claramente la poca
consistencia en su forma de trabajo y dentro de la bibliografía consultada se obtuvo
como referencia inicial de la revista “Best of Business Intelligence: A Year in Review,
2005-2006”,Volumen 3 de The Data Warehousing Institute (TDWI), cuyo artículo “Diez
errores para evitar en la Administración de los Almacenes de Datos”, de Larissa Moss,
Senior Consultant de Cutter's Business Intelligence Practice, nos señala como errores lo
siguiente:
1º Falta y falla para usar una metodología
Las metodologías tradicionales para desarrollar software, nos presentan productos

finales, no incluyen tareas de integración a través de la organización, no tienen
integración con otros productos. Una metodología para un DWH debe tomar en cuenta
que su ambiente DWH no pude ser construido todo de una sola vez; es decir, no
entregar productos finales, este tiene que ser expandido y mejorado. Si un DWH se
considera exitoso entonces cada versión debe de generar nuevos requerimientos. Estos
nuevos requerimientos pueden solicitar que nuevas tecnologías se evalúen y se
adquieran. Una metodología de un DWH proporciona apropiadas tareas para todas estas
actividades, administra múltiples sub-proyectos en paralelo, la metadata es un
importante entregable, merece una especial mención cuando se discute metodologías. Se
resalta que no todas las tareas tienen que ser ejecutadas en cada proyecto, pero se debe
de conocer todas las tareas, que el equipo deberá considerar en cada versión; el rol de la
metodología es proporcionar una lista de todas las posibles tareas, sus dependencias,
roles y responsabilidades asignadas para ejecutarlos y los entregables resultantes de
cada uno de ellos. No usar una metodología nos garantiza que las tareas vitales se
omitan, requiriendo retrabajo de los mismos que pueden ser evitados con el uso de una
metodología para DWH.
2º Ineficiente estructura del equipo del proyecto
El equipo del DWH debe ser mucho más flexible y dinámico que el equipo
tradicional. Los miembros del equipo deben estar disponibles al 100% desde el inicio
hasta el fin del proyecto de DWH. A cada persona en el núcleo del equipo puede tener
múltiple responsabilidades de acuerdo a la organización del equipo en el proyecto.
3º Falta y falla del involucramiento de la gente del negocio
Es importante que la gente del negocio participe en el proyecto, la razón más

importante es para acelerar y mejorar el trabajo del DWH. La gente del negocio es una
parte indispensable e invaluable del equipo de un DWH eficaz porque ellos tienen cierto
conocimiento y autoridad con su tecnología que la contraparte no la tiene. En resumen,
la gente del negocio entiende la intensidad y el impacto monetario de los problemas de
los negocios de la organización y están en posición y autoridad de negociar las
prioridades del proyecto del DWH.
4º Falta y falla para tener versiones de las aplicaciones
La mejor manera para ilustrar las eficientes versiones de las aplicaciones es el

reconocido concepto de Prototipo, se enfoca como pequeño (parcial e incompleto)
alcance que no es completo. Cada siguiente prototipo incluye porciones pequeñas de
todo el alcance siendo más complejo y funcional el DWH. Repitiendo este proceso
hasta que la aplicación sea totalmente funcional. En el desarrollo del DWH se debe
tener en cuenta este aspecto debido al constante y futuro cambio en el DWH.
5º Falta y falla para tener un estatuto activo proyecto
Este documento es frecuentemente conocido como un documento de entendimiento,

acuerdos del proyecto, acuerdos de alcance o estatutos del proyecto. Una vez que el
proyecto termina este documento desaparece y nunca no se vuelve a ver. Este
documento es muy útil y debe ser usado activamente para monitoreo y actividades del
control del proyecto durante el ciclo de vida del DWH, debe de contener secciones
como: Alcance del proyecto, riesgos, limitaciones, suposiciones, etc.
6º Falta de una planificación para la preparación
Los administradores de proyectos atienden conferencias de DWH y aprenden

mejores prácticas para el ciclo de vida del DWH, pero cuando retornan a su realidad a
querer aplicar ello se encuentran con la resistencia de los usuarios de la organización.
Este error en los administradores de los proyectos hacen no darse cuenta que la
organización no se encuentra preparada para un proyecto de esta tipo; por lo tanto, las
organizaciones inicialmente deben ser evaluadas y finalmente se debe de determinar si
está preparadas para un proyecto de DWH o no. Temas como: Metas, objetivos, calidad,
software de soporte, entendimiento de los usuarios que el DWH no es sólo un sistema,
tratar y analizar que los usuarios tengan expectativas realistas y además que
comprendan la importancia de su participación en las actividades del proyecto; son solo
algunos de los temas que se deben tener en cuanta en la organización antes de
emprender un proyecto de DWH.
7º Inadecuadas pruebas
Las pruebas en un DWH generalmente se realizan pobremente y muchas veces el

equipo lo considera como versiones posteriores, si estas pruebas toman tiempo en el
momento de realizar el DWH, posteriormente tomará aun más tiempo. Las pruebas en el
DWH deben ser porque en las siguientes versiones serán largos y más complicados. El
proyecto del DWH debe tener una Unidad de Pruebas que constantemente se encarguen
de esta función, además cada miembro del equipo deben probar sus módulos
individualmente. La aceptación de las pruebas es hecha por los usuarios de los negocios,
ellos validan la funcionabilidad del DWH.
8º Subestimar los esfuerzos en la limpieza de datos
Muchas organizaciones consideran innecesarias, costosas y tiempo perdido a la

limpieza de datos, esto genera dos situaciones claramente: Los defectos en los datos se
propagan inadvertidamente en el DWH y la data sucia se descubre tarde (pruebas ETL o
mientras se carga el DWH). Un DWH tendrá confiabilidad en el procesos de toma de
decisiones, si y sólo si su data es real, consistente y limpia de errores.
9º Ignorar la metadata
La metadata es parte del DWH, tomando un nuevo nivel de importancia porque nos
permite ayudar a la gente del negocio a localizar, administrar, entender y usar la data en
el DWH. Además nos indica que datos están disponibles en que BD, que eso significa,
de donde viene, como fue procesado, cuan limpio esta, como se usa en reportes y
consultas; es decir, toda la información acerca de los datos y procesos del DWH, desde
su procedencia, usos, modelos, diseños, etc. Esta información nos permite tener un
conocimiento superior del DWH y además dejar una guía del DWH para futuros
mantenimientos y/o adiciones en el mismo.
10º Ser un esclavo de las herramientas de Administración de Proyectos
El análisis, planificación y control de los proyectos no es una tarea trivial y toma un

tiempo adicional, y se debe ajustar al plan de proyecto, no significando tomar una
herramienta y automatizar estas labores, las herramientas nos sirven de apoyo pero no
de solución a los mencionados aspectos entre los más resaltantes.
Para Larissa Moss estos son los 10 errores que se comenten en el desarrollo de un DWH
y se deben de evitar; de acuerdo a la bibliografía consultada estos errores son los que
comúnmente ocurren, entonces en esta propuesta de tesis se cohesiono lo que se debe de
evitar de tal manera que nuestra propuesta tenga un porcentaje menor de fracaso.
10 errores que evitar en un Se evitó en la

En que parte se tomo en cuenta
Proceso de DWH propuesta
1º Falta y falla para usar una SI Se realizó una metodología para

metodología desarrollar un DWH, con aquellos
aspectos propios del DWH
2º Ineficiente estructura del equipo SI Se estructuró al equipo de acuerdo a

del proyecto MSF, siendo estos activamente en
todo el proceso del DWH y con roles
puntuales en cada fase de elaboración
del DWH.
3º Falta y falla del involucramiento SI En la mayor parte de las fases se

de la gente del negocio considera vital el involucramiento de
la gente del negocio.
4º Falta y falla para tener versiones SI Al ser una propuesta iterativa e

de las aplicaciones incremental.
5º Falta y falla para tener un SI Este documento se crea por el equipo

estatuto activo proyecto en un inicio, para organizar el trabajo
y limitarlo.
6º Falta de una planificación para SI Existen etapas y tareas que nos

la preparación permiten determinar si la organización
está lista para iniciar el proceso del
DWH y si no se encuentra se realizan
las medidas pertinentes para que lo
este.
7º Inadecuadas pruebas SI La propuesta del DWH tiene una

unidad de pruebas, además de las
pruebas individuales de los módulos.
8º Subestimar los esfuerzos en la SI Se cuenta con políticas sobre el tema

limpieza de datos de la Calidad de los Datos en un
DWH.
9º Ignorar la metadata SI La metadata es un aspecto que se

incrementa a medida que se llega al
final del proceso del DWH.
10º Ser un esclavo de las SI Las herramientas se consideran como

herramientas de Administración de apoyo a la búsqueda de la solución, no
Proyectos como una guía estricta al cual
ceñirnos.
TABLA 7: Evaluación del DWH según Larissa Moss [FP]
Una vez que se ha considerado y a su vez evitado estos errores, surge la pregunta ¿Por
qué es que las metodologías fracasan?, Larissa Moss presenta los diez errores para
evitar en el proceso del DWH, pero estos no son todos los aspectos para lograr un éxito
en un proyecto de DWH; con la propuesta de nuestra metodología se pretende
automatizar algunas etapas, tareas; pero el equipo está conformado por personas y a
muchas de ellas le es pesado seguir las pautas y documentar lo asignado en la propuesta
para desarrollar un DWH. Por otro lado es complicado que el equipo realice actividades
del proceso del DWH automáticamente como si fueran máquinas. Al inicio del proceso
del DWH se evalúa si la organización se encuentra preparada para este tipo de proyecto
y si no lo está se toman las acciones pertinentes, pero no se evalúa al equipo de
desarrollo, este es un factor critico porque a pesar de que la organización este lista para
desarrollar un DWH, si el equipo no lo está, se obtendría un posible fracaso, entonces
¿quien o quienes son los encargados de evaluar al equipo del DWH? y ¿cuales son los
requisitos básicos que este equipo necesita para iniciar?.
Más que evaluación del equipo del DWH es reconocer las habilidades de cada uno
como parte del equipo, de la forma como este se organice y reconozcan sus habilidades
y experiencias en las fases, etapas y tareas del DWH es un punto de inicio. Los
requisitos básicos que debe de cumplir una persona como parte del equipo no se enfoca
en sus conocimientos y destrezas porque estas se solucionan aprendiendo, es algo más
importante y es que las personas sean disciplinadas, sólo las Personas Disciplinadas
son capaces de adherirse a seguir los procesos definidos (propuesta metodológica) y
presentan las siguientes características fundamentales: Son consecuentes (siempre
cumplen sus obligaciones a menos que tengan una razón esencial para no hacerlo),
sinceros (afrontan los hechos no los evitan), innovador (proponen cambios dentro de los
limites del proceso), proactivas (se adelantan a los hechos), humildad personal y
profesional, actitud al cambio, son tolerantes y mantienen una comunicación abierta en
el equipo de sus ideas, propuestas y mejoras como aportes de mejoría en el proceso de
DWH.

Propuesta de Metodologia para DWH

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Propuesta de Metodologia para DWH

Caricato da

Copyright:

Formati disponibili

INDICE DE LA PROPUESTA METODOLOGIA

8.2 Política para obtener Calidad en los Datos del DWH

La calidad en los datos de un DWH se considera descentralizada porque no se focaliza en la

ILUSTRACION 1: Estados de los datos en un DWH [BI16] [FP]

FASE 1: EXPLORACION DE LOS DATOS

FASE 2: DISEÑO DE LAS SOLUCIONES

Se deben diseñar rutinas tendiendo en cuenta 3 componentes básicos: [BI09]

− Verificación de la data: La validación de la data consiste de un número de checks, incluyendo:

FASE 3: EJECUCIÓN DE RUTINAS DE LIMPIEZA

ETAPA 3.1: En DS-Flow

ETAPA 3.2: En In-Flow

II. Verificación de la uniformidad

III. Transformación de datos

IV. Verificación de versión

Se encarga de detectar cambios en la codificación de los datos fuente se obtiene

ETAPA 3.3: En Up-Flow

Determina la completitud y correctitud de las agregaciones en los datos, estas son

VI. Verificación de la conformidad

Valida si los datos se encuentran en la forma adecuada en el DWH; permitiéndonos

VII. Verificación de la metadata

FASE 4: ASEGURAR LA CALIDAD EN LA DATA

Entregable en la Política de Calidad

− Documento Master de la Política de Calidad de Datos (incluye integradamente aspectos de la

− Presentación en Power Point de la Política de Calidad del DWH.

1 Administración del Producto:

Estados de los DS-Flow In-Flow Up-Flow

Políticas de 1º Exploración de los 2º Diseño de las

3º Ejecución de rutinas de lim pieza

− Supervivencia y − Verificación de la − Verificación de la

TABLA 1: Ubicación de las políticas de Calidad en el Ambiente del DWH [FP]

1º Exploración de Datos FASE DE VISIONADO

2º Diseño de Soluciones FASE DE

CAPITULO 1:ILUSTRACION 2: Integración de la Calidad de Datos con la propuesta metodológica [FP]

La propuesta se basa en la integración del Modelo de Procesos y del Modelo de Equipo

El Modelo de Procesos de MSF nos permite adaptarnos a los requerimientos cambiantes

Previamente es importante que se tenga en cuenta algunas pautas y/o significados de

Clientes y Usuarios: Un Cliente es la persona u organización que se encarga del

Nuestra propuesta es una Aproximación basada en Fases y Milestone, identificando

Crear un plan multi-versiones, entregar primero el centro funcional, ciclos a través de

La Versión 1 de la propuesta desarrolla el aspecto funcional, para lo cual se integra el

El Modelo de Equipo de MSF por ser un modelo no jerárquico en donde la

Role Cluster Meta Principal

1. Administración del Producto Satisfacer a los clientes.

3. Desarrollo Construir las especificaciones.

Aprobar las versiones solo después de que

5. Experiencia del Usuario Mejorar la eficacia de los usuarios.

6. Administración de Versiones Conseguir una tranquila implementación y

TABLA 2: Metas de los Role Cluster del Modelo de Equipo [FP]

Finalmente, es relevante indicar que el Modelo de Procesos y el de Equipo,

La siguiente ilustración resume las fases de la propuesta metodológica de este trabajo de

LUSTRACION 5: Fases del Ciclo de Vida del Almacén de Datos [FP]

− Crecimiento: Incrementos en el tiempo en volúmenes de datos, del número de

− Cambios: El DWH requiere soportar cambios que ocurren tanto en el origen de

 Cambios en el ambiente organizacional: Un cambio en el ambiente

Los costos por evolución y crecimiento, son normales en un sistema operacional, el

Roles y Responsabilidades del Equipo en la Fase del Estudio de

Todo el Equipo del DWH se encargará de efectuar este estudio en la organización.

Organización del Proyecto

ILUSTRACION 6: Fase de Visionado del Ciclo de Vida del DWH [FP]

I. ¿La organización esta preparada para un proyecto de BI (con un DWH inicial?

La preparación de la organización consta de varios ítems, según sea el tamaño de la

Si la organización se encuentra preparada para emprender el proyecto del DWH, el

II. Visión del Proyecto