Metodologia Hefesto Warehouse Parte 2 PDF

DATA WAREHOUSING:
Investigación y
Sistematización de Conceptos
–
HEFESTO: Metodología
propia para la Construcción
de un Data
Warehouse
Ing. Bernabeu, Ricardo Dario
Córdoba, Argentina – Miércoles 07 de Noviembre de 2007
I
I
Copyright ©2007 Ing. Bernabeu, Ricardo Dario. Se otorga permiso para copiar, dis-
tribuir y/o modificar este documento bajo los términos de la Licencia de Documentación
Libre de GNU, Versión 1.2 o cualquier otra versión posterior publicada por la Free Soft-
ware Foundation; requiriendo permanecer invariable el nombre de la metodología (HE-
FESTO), en cuanto al diseño de su logotipo, debe mantenerse el estilo medieval para su
confección y letra ”O” representada por el símbolo de radioactividad ( ). Una copia de
la licencia está incluida en la sección titulada Licencia de Documentación Libre de GNU.
III
...si supiese qué es lo que estoy haciendo,
no lo l lamaría INVESTIGACIÓN...
Albert Einstein
IV
Parte II
HEFESTO: Metodología propia

para la Construcción de un Data
Warehouse
V
RESUMEN
En esta segunda parte de la publicación, se propondrá una metodología propia para la

construcción de un Data Warehouse, que partirá de la recolección de requerimientos y
necesidades de información del usuario, y concluirá en la confección de un esquema ló-
gico y sus respectivos procesos de extracción, transformación y carga de datos. Además, se
ejemplificará cada etapa de la metodología a través de su aplicación a una empresa real,
que servirá de guía para que se puedan visualizar los resultados que se esperan de cada
paso y para clarificar los conceptos enunciados.
Primero, se describirán los aspectos más sobresalientes de la metodología y luego se

explicará cada paso con su respectiva aplicación. Finalmente, se expondrán algunas
consideraciones que deben tenerse en cuenta al momento de construir e implementar
un Data Warehouse.
El principal objetivo es facilitar el arduo trabajo que significa construir un Data Wa-
rehouse desde cero, aportando información que permitirá aumentar la performance del
mismo. En adición a ello, esta nueva metodología estará orientada a evitar el tedio que
provoca el tener que seguir pasos sin terminar de comprender el por qué de los mismos.
VI
Capítulo 5
METODOLOGÍA HEFESTO
5.1. Introducción
En esta sección se presentará la metodología HEFESTO, que permitirá la construcción de
Data Warehouse de forma sencilla, ordenada e intuitiva. Su nombre fue inspirado en el
dios griego de la construcción y el fuego, y su logotipo es el siguiente:
Figura 5.1: Metodología HEFESTO, logotipo.
HEFESTO es una metodología propia, cuya propuesta está fundamentada en una muy
amplia investigación, comparación de metodologías existentes y experiencias propias en
procesos de confección de almacenes de datos.
La idea principal, es comprender cada paso que se realizará, para no caer en el tedio de
tener que seguir un método al pie de la letra sin saber exactamente qué se está ha-
ciendo, ni por qué.
La construcción e implementación de un DW puede adaptarse muy bien a cualquier ciclo

de vida de desarrollo de software, con la salvedad de que para algunas fases en particular,
las acciones que se han de realizar serán muy diferentes. Lo que se debe tener muy en
cuenta, es no entrar en la utilización de metodologías que requieran fases exten- sas de
reunión de requerimientos y análisis, fases de desarrollo monolítico que conlleve
demasiado tiempo y fases de despliegue muy largas. Lo que se busca, es entregar una
primera implementación que satisfaga una parte de las necesidades, para demostrar las
ventajas del DW y motivar a los usuarios.
La metodología HEFESTO, puede ser embebida en cualquier ciclo de vida que cumpla con
la condición antes declarada.
VII
5. METODOLOGÍA HEFESTO Ing. Bernabeu, R. Dario
Con el fin de que se llegue a una total comprensión de cada paso o etapa, se
acom- pañará con la implementación en una empresa real, para demostrar los
resultados que se deben obtener y ejemplificar cada concepto.
5.2. Descripción
La metodología HEFESTO puede resumirse a través del siguiente gráfico:
Figura 5.2: Metodología HEFESTO, pasos.
68
Como se puede apreciar, se comienza recolectando las necesidades de información de los

usuarios y se obtienen las preguntas claves del negocio. Luego, se deben identificar los
indicadores resultantes de los interrogativos y sus respectivas perspectivas de análisis,
mediante las cuales se construirá el modelo conceptual de datos del DW.
Después, se analizarán los OLTP para señalar las correspondencias con los datos fuentes y
seleccionar los campos de estudio de cada perspectiva.
Una vez hecho esto, se pasará a la construcción del modelo lógico del depósito, expli- citando
las jerarquías que intervendrán.
Por último, se definirán los procesos de carga, transformación, extracción y limpieza de los
datos fuente.
5.3. Características
Esta metodología cuenta con las siguientes características:
Los objetivos y resultados esperados en cada fase se distinguen fácilmente y son sencillos
de comprender.
Se basa en los requerimientos del usuario, por lo cual su estructura es capaz de
adaptarse con facilidad y rapidez ante los cambios en el negocio.
Reduce la resistencia al cambio, ya que involucra al usuario final en cada etapa para que tome
decisiones respecto al comportamiento y funciones del DW.
Utiliza modelos conceptuales y lógicos, los cuales son sencillos de interpretar y analizar.
Es independiente del tipo de ciclo de vida que se emplee para contener la metodo- logía.
Es independiente de las herramientas que se utilicen para su implementación.
Es independiente de las estructuras físicas que contengan el DW y de su respectiva
distribución.
Cuando se culmina con una fase, los resultados obtenidos se convierten en el punto de
partida para llevar a cabo el paso siguiente.
Se aplica tanto para DM como para DW.
5.4. Empresa analizada

Antes de comenzar con el primer paso, es menester describir las características principales
de la empresa a la cual se le aplicará la metodología HEFESTO, así se podrá tener como base
un ámbito predefinido y se comprenderá mejor cada decisión que se tome con respecto a
la implementación y diseño del DW.
Además, este análisis ayudará a conocer el funcionamiento y accionar de la empresa, lo que

permitirá examinar e interpretar de forma óptima las necesidades de información de la
misma, como así también apoyará a una mejor construcción y adaptación del de- pósito de
datos.
La descripción de la empresa se encuentra en el Apéndice A (página 97).
69
5.5. Pasos y aplicación metodológica
5.5.1. PASO 1) ANÁLISIS DE REQUERIMIENTOS

5.5.1.1. a) Identificar preguntas
El primer paso comienza con el acopio de las necesidades de información, el

cual puede llevarse a cabo a través de muy variadas y diferentes técnicas, cada
una de las cuales poseen características inherentes y específicas, como por
ejemplo entrevistas, cuestionarios, observaciones, etc.
El análisis de los requerimientos de los diferentes usuarios, es el punto de partida

de esta metodología, ya que ellos son los que deben, en cierto modo, guiar la
investigación hacia un desarrollo que refleje claramente lo que se espera del
depósito de datos, en relación a sus funciones y cualidades.
El objetivo principal de esta fase, es la de obtener e identificar las necesidades de

in- formación clave de alto nivel, que es esencial para llevar a cabo las metas y
estrategias de la empresa, y que facilitará una eficaz y eficiente toma de
decisiones.
Debe tenerse en cuenta que dicha información, es la que proveerá el soporte

para desarrollar los pasos sucesivos, por lo cual, es muy importante que se preste
especial atención al relevar los datos.
Una forma de asegurarse de que se ha realizado un buen análisis, es que el

resultado del mismo debe hacer explícitos los objetivos estratégicos planteados
por la empresa que se está estudiando.
Otra forma de encaminar el relevamiento, es enfocar las necesidades de

información en los procesos principales que desarrolle la empresa en cuestión.
La idea central es, que se formulen preguntas complejas sobre el negocio, que
inclu- yan variables de análisis que se consideren relevantes, ya que son estas las
que permi- tirán estudiar la información desde diferentes perspectivas.
Un punto importante que debe tenerse muy en cuenta, es que la información

debe estar soportada de alguna manera por algún OLTP, ya que de otra forma, no
se podrá elaborar el DW.
Caso práctico:
Se indagó a los usuarios en busca de sus necesidades de información, pero las mismas abarca- ban
casi todas las actividades de la empresa, por lo cual se les pidió que escogieran el proceso que
considerasen más importante en las actividades diarias de la misma y que estuviese soportado de
alguna manera por algún OLTP. El proceso elegido fue el de Ventas.
A continuación, se procedió a identificar que era lo que les interesaba conocer acerca de este
proceso y cuáles eran las variables o perspectivas que debían tenerse en cuenta para poder tomar
decisiones basadas en ello.
Se les preguntó cuáles eran según ellos, los indicadores que representan de mejor modo el proceso
de Ventas y qué sería exactamente lo que se desea analizar del mismo. La respuesta obtenida, fue
que se deben tener en cuenta y consultar datos sobre la cantidad de unidades vendidas y el
70
monto total de ventas.
Luego se les preguntó cuáles serían las variables o perspectivas desde las cuales se consultarán dichos
indicadores. Para simplificar esta tarea se les presentó una serie de ejemplos concretos de otros casos
similares.
El resultado obtenido fue el siguiente:
Se desea conocer cuántas unidades de cada producto fueron vendidas a sus clientes en un periodo
determinado. O en otras palabras: ”Unidades vendidas de cada producto a cada cliente en un tiempo
determinado”.
Se desea conocer cuál fue el monto total de ventas de productos a cada cliente en un periodo determinado. O
en otras palabras: ”Monto total de ventas de cada producto a cada cliente en un tiempo determinado”.
Debido a que la dimensión Tiempo es un elemento fundamental en el DW, se hizo hincapié en él. Además, se
puso mucho énfasis en dejar en claro a los usuarios, a través de ejemplos prácticos, que es este componente
el que permitirá tener varias versiones de los datos a fin de realizar un correcto análisis posterior.
Como se puede apreciar, las necesidades de información expuestas están acorde a los objetivos y estrategias de
la empresa, ya que es precisamente esta información requerida la que proveerá un ámbito para la toma de
decisiones, que en este caso permitirá analizar el comportamiento de los clientes a los que se pretende
satisfacer ampliamente, para así lograr obtener una ventaja competitiva y maximizar las ganancias.
5.5.1.2. b) Identificar indicadores y perspectivas de análisis
Una vez que se han establecido las preguntas claves, se debe proceder a su descom-
posición para descubrir los indicadores que se utilizarán y las perspectivas de análisis que
intervendrán.
Para ello, se debe tener en cuenta que los indicadores, para que sean realmente
efectivos son, en general, valores numéricos y representan lo que se desea analizar con-
cretamente, por ejemplo: saldos, promedios, cantidades, sumatorias, fórmulas, etc.
En cambio, las perspectivas se refieren a los objetos mediante los cuales se quiere
examinar los indicadores, con el fin de responder a las preguntas planteadas, por ejemplo:
clientes, proveedores, sucursales, países, productos, rubros, etc. Cabe destacar, que el
Tiempo es muy comúnmente una perspectiva.
Caso práctico:
A continuación, se analizarán las preguntas obtenidas en el paso anterior y se detallarán cuáles son sus
respectivos indicadores y perspectivas.
71
Figura 5.3: Caso práctico, indicadores y perspectivas.
En síntesis, los indicadores son:
Unidades vendidas. Monto

total de ventas.
Y las perspectivas de análisis son:
Clientes.
Productos.
Tiempo.
5.5.1.3. c) Modelo Conceptual
En esta etapa, se construirá un modelo conceptual1 a partir de los indicadores y

perspectivas obtenidas en el paso anterior.
A través de este modelo, se podrá observar con claridad cuales son los alcances
del proyecto, para luego poder trabajar sobre ellos, además al poseer un alto nivel
de defi- nición de los datos, permite que pueda ser presentado ante los usuarios y
explicado con facilidad.
La representación gráfica del modelo conceptual es la siguiente:
Figura 5.4: Modelo Conceptual.
1 Modelo Conceptual: descripción de alto nivel de la estructura de la base de datos, en la cual la

información es representada a través de objetos, relaciones y atributos.
72
A la izquierda se colocan las perspectivas seleccionadas, que serán unidas a un óvalo central
que representa y lleva el nombre de la relación que existe entre ellas. La rela- ción,
constituye el proceso o área de estudio elegida. De dicha relación y entrelazadas con
flechas, se desprenden los indicadores o medidas, estos se ubican a la derecha del
esquema.
Como puede apreciarse en la figura anterior, el modelo conceptual permite de un solo vistazo
y sin poseer demasiados conocimientos previos, comprender cuáles serán los resultados
que se obtendrán, cuáles serán las variables que se utilizarán para analizarlos y cuál es la
relación que existe entre ellos.
Caso práctico:
El modelo conceptual resultante de los datos que se han recolectado, es el siguiente:
Figura 5.5: Caso práctico, Modelo Conceptual.
Como puede observarse, la relación mediante la cuál se unen las diferentes perspectivas, para obtener como
resultado los indicadores requeridos por los usuarios, es precisamente ”Venta”.
5.5.2. PASO 2) ANÁLISIS DE LOS OLTP

5.5.2.1. a) Establecer correspondencias con los requerimientos
El objetivo de este análisis, es el de examinar los OLTP disponibles que contengan la

información requerida, como así también sus características, para poder identificar las
correspondencias entre el modelo conceptual y las fuentes de datos.
En el caso de los indicadores, deben explicitarse como se calcularán, y más aún si son
fórmulas u operaciones complejas.
La idea es, que todos los elementos del modelo conceptual estén correspondidos en los
OLTP.
73
Caso práctico:
En el OLTP de la empresa analizada, el proceso de venta está representado por el diagrama de
entidad relación2 de la siguiente figura.
Figura 5.6: Caso práctico, Diagrama de Entidad Relación.
Los indicadores se calcularán de la siguiente manera:
”Unidades Vendidas” representa las unidades que se han vendido de un producto en particular.
”Monto Total de Ventas” representa en monto total que se ha vendido de cada producto, y se
obtiene al multiplicar la cantidad de unidades vendidas, por su respectivo precio.
A continuación, se expondrá la correspondencia entre los dos modelos:
74
Figura 5.7: Caso práctico, correspondencia.
Las relaciones identificadas fueron las siguientes:

La tabla ”Productos” se relaciona con la perspectiva ”Productos”. La tabla
”Clientes” con la perspectiva ”Clientes”.
El campo ”fecha” de la tabla ”Facturas_Venta” con la perspectiva ”Tiempo” (debido a que es la fecha
principal en el proceso de venta).
El campo ”cantidad” de la tabla ”Detalles_Venta” con el indicador ”Unidades Vendidas”. El campo
”cantidad” de la tabla ”Detalles_Venta” multiplicado por el campo ”precio_Fact”
de la misma tabla, con el indicador ”Monto Total de Ventas”.
5.5.2.2. b) Seleccionar los campos que integrarán cada perspectiva. Nivel de

granularidad
Una vez que se han establecido las relaciones con los OLTP, se examinarán y selec-
cionarán los campos que contendrá cada perspectiva, ya que será a través de estos por los
que se manipularán y filtrarán los indicadores.
Para ello, basándose en las correspondencias establecidas en el paso anterior, se debe

presentar al usuario los datos de análisis disponibles para cada perspectiva. Es muy
importante conocer en detalle que significa cada campo y/o valor de los datos encon-
trados en los OLTP, por lo cual, es conveniente investigar su sentido, ya sea a través de
diccionarios de datos, reuniones con los encargados del sistema, análisis de los datos
propiamente dichos, etc.
Luego de exponer frente al usuario los datos existentes, explicando su significado, valores
posibles y características, este debe decidir cuales son los que considera relevantes para
consultar los indicadores y cuales no.
75
Con respecto a la perspectiva “Tiempo”, es muy importante definir el ámbito

mediante el cual se agruparán o sumarizarán los datos. Este punto es
fundamental precisarlo con claridad, debido a que, determinará la granularidad de la
información encontrada en el DW. Sus campos posibles pueden ser: día de la
semana, quincena, mes, trimestres, semestre, año, etc.
Finalmente, y con el fin de graficar los resultados obtenidos, se ampliará el

modelo conceptual expuesto anteriormente, colocando bajo cada perspectiva los
campos o atributos elegidos.
Figura 5.8: Modelo Conceptual con atributos.
Caso práctico:
De acuerdo a las correspondencias establecidas, se analizaron los campos residentes en cada tabla
a la que se hacia referencia, a través de dos métodos diferentes. Primero se examinó la base de
datos para intuir los significados de cada campo, y luego se consultó con el encargado del
sistema sobre algunos aspectos de los cuales no se comprendía su sentido.
De todas formas, y como puede apreciarse en el diagrama de entidad relación antes expuesto, los
nombres de los campos son bastante explícitos y se deducen con facilidad, pero aún así fue
necesario investigarlos para evitar cualquier tipo de inconvenientes.
Con respecto a la perspectiva ”Clientes”, los datos disponibles son los siguientes:
• id_Cliente: es la clave primaria de la tabla ”Clientes”, y representa unívocamente a un cliente
en particular.
• Codigo: representa el código del cliente, este campo es calculado de acuerdo a una
combinación de las iniciales del nombre del cliente, el grupo al que pertenece y un número
incremental.
• Razon_Soc: nombre o razón social del cliente.
• Telefono1: número de teléfono del cliente.
• Telefono2: segundo número telefónico del cliente.
• Fax1: número de fax del cliente.
• Fax2: segundo número de fax del cliente.
• Mail1: dirección de correo electrónico del cliente.
• Mail2: segunda dirección de correo del cliente.
• id_Sit_Fiscal: representa a través de una clave foránea el tipo de situación fiscal que posee el
cliente. Por ejemplo: Consumidor Final, Exento, Responsable No Inscripto, Responsable
Inscripto.
76
• CUIT: número de C.U.I.T. del cliente.

• ConvenioMultilateral: indica si el cliente posee o no convenio multilateral.
• DGR: número de D.G.R. del cliente.
• id_Clasificación: representa a través de una clave foránea la clasificación del cliente.
Por ejemplo: Muy Bueno, Bueno, Regular, Malo, Muy Malo.
• id_nota: representa a través de una clave foránea una observación realizada acerca del cliente.
• Cta_Habilitada: indica si el cliente posee su cuenta habilitada.
• id_Rubro: representa a través de una clave foránea el grupo al que pertenece el cliente.
Por ejemplo: Bancos, Construcción, Educación Privada, Educación Pública, Particula- res.
• idCuentaContable: representa la cuenta contable asociada al cliente, la cual se utilizará para imputar los
movimientos contables que este genere.
• Eliminado: indica si el cliente fue eliminado o no. Si fue eliminado, no figura en las listas de clientes
actuales.
En la perspectiva ”Productos”, los datos que se pueden utilizar son los siguientes:
• id_prod: es la clave primaria de la tabla ”Productos”, y representa unívocamente a un producto en
particular.
• stock: stock actual del producto.
• stock_min: stock mínimo del producto, se utiliza para dar alerta si el stock actual está cerca del mismo, al
ras o si ya lo superó.
• Precio: precio de venta del producto.
• Detalle: nombre o descripción del producto.
• id_Rubro: representa a través de una clave foránea el rubro al que pertenece el producto.
• id_Marca: representa a través de una clave foránea la marca a la que pertenece el producto.
• stock_MAX: stock máximo del producto. Al igual que ”stock_min”, se utiliza para dar alertas del nivel de
stock actual.
• tipo: clasificación del producto. Por ejemplo: Producto, Servicio, Compuesto.
• Costo: precio de costo del producto.
• codigo: representa el código del producto, este campo es calculado de acuerdo a una combinación de las
iniciales del nombre del producto, el rubro al que pertenece y un número incremental.
• Imagen: ruta de acceso a una imagen o dibujo mediante la cual se quiera representar al producto. Este
campo no es utilizado actualmente.
• Generico: indica si el producto es genérico o no.
• Eliminado: indica si el producto fue eliminado o no. Si fue eliminado, no figura en las listas de productos
actuales.
• PrecioR: precio de lista del producto.
Con respecto a la perspectiva ”Tiempo”, que es la que determinará la granularidad del depósito de
datos, los atributos más típicos que pueden emplearse son los siguientes:
• Año.
• Semestre.
• Cuatrimestre.
• Trimestre.
• Número de mes.
• Nombre del mes.
• Quincena.
• Semana.
• Número de día.
77
• Nombre del día.
Una vez que se recolectó toda la información pertinente y se consultó con los usuarios cuales eran
los datos que consideraban de interés para analizar los indicadores ya expuestos, los resultados
obtenidos fueron los siguientes:
En la perspectiva ”Clientes” sólo se tendrá en cuenta el nombre del cliente, o sea, el campo
”Razon_Soc” de la tabla ”Clientes”.
En la perspectiva ”Productos”, se utilizarán los campos que hacen referencia al nombre del
producto (”detalle” de la tabla ”Productos”) y a la marca a la que pertenecen (”Nombre” de la
tabla ”Marcas”, obtenido a través de la unión con la tabla ”Productos”).
En la perspectiva ”Tiempo”, se seleccionaron los campos ”Mes” (referido al nombre del mes),
”Trimestre” y ”Año”.
Teniendo esto en cuenta, se completará el diseño del diagrama conceptual:
Figura 5.9: Caso práctico, Modelo Conceptual con atributos.
5.5.3. PASO 3) ELABORACIÓN DEL MODELO LÓGICO DE LA

ESTRUC- TURA DEL DW
A continuación, se confeccionará el modelo lógico3 de la estructura del DW,
teniendo como base el modelo conceptual que ya ha sido creado.
Se debe seleccionar cuál será el tipo de esquema que se utilizará para contener
la estructura del depósito de datos, que se adapte mejor a los requerimientos y
necesidades del usuario. Es muy importante definir objetivamente si se empleará
un esquema en estrella, constelación o copo de nieve, ya que esta decisión afectará
considerablemente la elaboración del modelo lógico.
Caso práctico:
El esquema que se utilizará será en estrella, debido a sus características, ventajas y
diferencias con los otros esquemas.
3 Modelo Lógico: representación de una estructura de datos, que puede procesarse y almacenarse en algún
SGBD.
78
5.5.3.1. a) Diseñar tablas de dimensiones
Este paso, se aplicará por igual a todos los tipos de esquemas lógicos.
Lo primero que se hará será crear las dimensiones del mismo, para ello se tomará cada
perspectiva con sus atributos relacionados y se les realizará el siguiente proceso:
Se elegirá un nombre que identifique la dimensión.
Se añadirá un campo que represente su clave principal.
Se redefinirán los nombres de los atributos si es que no son lo bastante explicativos.
Gráficamente:
Figura 5.10: Diseño de tablas de dimensiones.
Caso práctico:
A continuación, se diseñaran las tablas de dimensiones.
Perspectiva “Clientes”:
• La nueva dimensión tendrá el nombre “CLIENTE”.
• Se le agregará una clave principal con el nombre “idCliente”.
• Se modificará el nombre del atributo “Razon_Soc” por “Cliente”.
Se puede apreciar el resultado de estas operaciones en la siguiente gráfica:
Figura 5.11: Caso práctico, dimensión ”CLIENTE”.
Perspectiva “Productos”:
• La nueva dimensión tendrá el nombre “PRODUCTO”.
• Se le agregará una clave principal con el nombre “idProducto”.
• El nombre del atributo “Marca” no será cambiado.
• Se modificará el nombre del atributo “Detalle” por “Producto”.
79
Figura 5.12: Caso práctico, dimensión ”PRODUCTO”.
Perspectiva “Tiempo”:
• La nueva dimensión tendrá el nombre “FECHA”.
• Se le agregará una clave principal con el nombre “idFecha”.
• El nombre los atributos no serán modificados.
Figura 5.13: Caso práctico, dimensión ”FECHA”.
5.5.3.2. b) Diseñar tablas de hechos
En este paso, se definirán las tablas de hechos, que son las que contendrán los
indicadores de estudio.
Para los esquemas en estrella y copo de nieve, se realizará lo siguiente:
• Al igual que las dimensiones, se le deberá asignar un nombre a la tabla de

hechos que en este caso represente la información analizada, área de investi-
gación, negocio enfocado, etc.
• Se definirá su clave primaria, que se compone de la combinación de las claves
primarias de cada dimensión que se utilizará para generar las consultas.
• Se renombrarán los hechos o indicadores si es que no llegasen a ser lo suficien-
temente explícitos.
Gráficamente:
Figura 5.14: Tabla de hechos.
80
Para los esquemas constelación se realizará lo siguiente:
• Las tablas de hechos se deben confeccionar teniendo en cuenta el análisis de las

preguntas realizadas por el usuario en pasos anteriores y sus respectivos indicadores
y dimensiones.
• Cada tabla de hechos debe poseer un nombre que la identifique, contener sus
indicadores correspondientes y su clave debe estar formada por la combina- ción de
las claves de las dimensiones que intervendrán.
Antes de continuar, vale la pena recordar que las perspectivas fueron converti- das en
dimensiones en el paso anterior, razón por la cual, las preguntas realizadas por el
usuario son examinadas a través de indicadores y dimensiones.
• Al diseñar las tablas de hechos, se deberá tener en cuenta:

◦ Caso 1: Si en dos o más preguntas figuran los mismos indicadores pero con diferentes
dimensiones de análisis, existirán tantas tablas de hechos como preguntas cumplan
esta condición. Por ejemplo:
Figura 5.15: Caso 1, preguntas.
Entonces se obtendrá:
Figura 5.16: Caso 1, diseño de tablas de hechos.
◦ Caso 2: Si en dos o más preguntas figuran diferentes indicadores con diferentes
dimensiones de análisis, existirán tantas tablas de hechos como preguntas cumplan
esta condición. Por ejemplo:
Entonces se obtendrá:
81
Figura 5.18: Caso 2, diseño de tablas de hechos.
◦ Caso 3: Si el conjunto de preguntas cumplen con las condiciones de los dos

puntos anteriores se deberán unificar aquellos interrogantes que po- sean
diferentes indicadores pero iguales dimensiones de análisis, para luego reanudar el
estudio de las preguntas. Por ejemplo:
Se unificarán en:
Figura 5.20: Caso 3, unificación.
Caso práctico:
A continuación, se confeccionará la tabla de hechos:
La tabla de hechos tendrá el nombre “VENTAS”.
Su clave principal será la combinación de las claves principales de las dimensiones antes
definidas: “idCliente”, “idProducto” e “idFecha”.
Los indicadores serán renombrados, “Unidades Vendidas” por “Cantidad” y “Monto

Total de Ventas” por “MontoTotal”.
En el gráfico siguiente se puede apreciar mejor este paso:
82
Figura 5.21: Caso práctico, diseño de la tabla de hechos.
5.5.3.3. c) Realizar uniones
Para los tres tipos de esquemas, se realizarán las uniones correspondientes entre sus
tablas de dimensiones y sus tablas de hechos.
Caso práctico:
Se realizarán las uniones pertinentes, de acuerdo corresponda:
Figura 5.22: Caso práctico, uniones.
5.5.3.4. d) Determinar jerarquías
Para los esquemas en estrella y constelación, se deberán especificar las jerarquías que
existirán dentro de cada tabla de dimensión, teniendo siempre presente cual es el
objetivo de las mismas. Para representar las jerarquías en el modelo lógico, se deberán
colocar los atributos pertenecientes a las jerarquías en sus respectivas tablas, en orden
descendente y acompañado con un número ordinal encerrado entre corchetes.
Por ejemplo, si se posee la siguiente jerarquía:
83
Figura 5.23: Jerarquía de ”GEOGRAFIA”.
Entonces, para representar esta jerarquía, la tabla “GEOGRAFIA” debe quedar como
sigue:
Figura 5.24: Jerarquía de ”GEOGRAFIA”, representación.
Para los esquemas copo de nieve, cuando existan jerarquías dentro de una dimen-
sión, esta tabla deberá ser normalizada. Por ejemplo, si se toma como referencia la
dimensión “GEOGRAFIA” de la imagen anterior y su respectiva jerarquía, entonces,
al normalizar esta tabla se obtendrá:
Figura 5.25: Normalización de la jerarquía de ”GEOGRAFIA”.
Caso práctico:
A continuación, se definirán las jerarquías existentes en el esquema, las cuales fueron
acordadas con los usuarios, tras haberles explicado sus objetivos y utilidades.
En la dimensión “FECHA” se seleccionó la siguiente:
84
Figura 5.26: Caso práctico, jerarquía de ”FECHA”
Entonces, la tabla “FECHA” queda como sigue:
Figura 5.27: Caso práctico, representación de la jerarquía de ”FECHA”
En la dimensión “PRODUCTO” se seleccionó la siguiente jerarquía:
Figura 5.28: Caso práctico, jerarquía de ”PRODUCTO”
Entonces, la tabla “PRODUCTO” queda como sigue:
Figura 5.29: Caso práctico, representación de la jerarquía de ”FECHA”
En la figura que se presentará a continuación, se puede apreciar el esquema lógico del

DW resultante, tras haber definido sus jerarquías correspondientes.
85
Figura 5.30: Caso práctico, Modelo Lógico.
5.5.4. PASO 4) PROCESOS ETL, LIMPIEZA DE DATOS Y

SENTENCIAS SQL
Una vez construido el modelo lógico, se deberá proceder a probarlo con datos, a
tra- vés de procesos ETL.
Para realizar la compleja actividad de extraer datos de diferentes fuentes, para

luego integrarlos, filtrarlos y depurarlos, existen varios software que facilitan estas
tareas, por lo cual este paso se centrará solo en la generación de las sentencias SQL
que contendrán los datos que serán de interés.
Antes de realizar la carga de datos, es conveniente efectuar una limpieza de los

mismos, para evitar valores faltantes y anómalos.
Al generar los ETL, se debe tener en cuenta cual es la información que se desea
alma- cenar en el depósito de datos, para ello se pueden establecer condiciones
adicionales y restricciones. Estas condiciones deben ser analizadas y llevadas a
cabo con mucha pru- dencia para evitar pérdidas de datos importantes.
En la cláusula ORDER BY de las sentencias SQL, que se efectuarán para cargar

cada tabla, deben figurar los atributos, medidas y claves en orden de aparición de
sus respectivas tablas. Al realizar esta acción, se logrará aportar mayor
eficiencia cuando se realizan búsquedas de datos.
Cuando se trabaja con un esquema constelación, hay que tener presente que
varias dimensiones serán compartidas con diferentes tablas de hechos, ya que
puede darse el caso de que algunas restricciones aplicadas sobre una tabla de
dimensión en particular para analizar los indicadores de una tabla de hechos, se
puedan contraponer con otras restricciones o condiciones de análisis de otros
indicadores de otras tablas de hechos.
Primero se cargarán los datos de las dimensiones y luego los de las tablas de
hechos, teniendo en cuenta siempre, la correcta correspondencia entre cada
elemento y las sumarizaciones que se requieran. En el caso en que se esté
utilizando un esquema copo de nieve, cada vez que existan jerarquías de
dimensiones, se comenzarán cargando las tablas de dimensiones del nivel más
general al más detallado.
86
Cuando se haya cargado en su totalidad el DW, se deben establecer sus políticas de

actualización o refresco de datos.
Caso práctico:
A continuación, se generarán las sentencias SQL para cargar las diferentes dimensiones y la tabla de
hechos.
Dimensión “CLIENTE”:
Se tomará como fuente de entrada la tabla “Clientes” del OLTP mencionado anteriormente.
Se consultó con los usuarios y se averiguó que deseaban tener en cuenta solo aquellos clientes
que no estén eliminados y que tengan su cuenta habilitada.
Es importante destacar que aunque existían numerosos movimientos de clientes que en la
actualidad no poseen su cuenta habilitada o que figuran como eliminados, se decidió no
incluirlos debido a que el énfasis está puesto en analizar los indicadores a través de aquellos
clientes que no cuentan con estas condiciones.
Los clientes eliminados son referenciados mediante el campo “Eliminado”, en el cual un valor
“1” indica que este fue eliminado, y un valor “0” que aún permanece vigente. Cuando se
examinaron los registros de la tabla, para muchos clientes no había ningún valor asignado para
este campo, lo cual, según comunicó el encargado del sistema, se debía a que este se agregó poco
después de haberse creado la base de datos inicial, razón por la cual existían valores faltantes.
Ade- más, comentó que en el sistema, si un cliente posee en el campo “Eliminado” un valor “0” o
un valor faltante, es considerado como vigente.
Con respecto a la cuenta habilitada, el campo del OLTP que le hace mención es
“Cta_Habilitada”, y un valor “0” indica que no está habilitada y un valor “1” que sí.
Seguidamente, se generará la sentencia SQL, sobre el OLTP “Clientes”, con los datos requeridos
para cargar esta dimensión:
Figura 5.31: Caso práctico, sentencia SQL de ”CLIENTES”.
87
Dimensión “PRODUCTO”:
Las fuentes que se utilizarán, son las tablas “Productos” y “Marcas”.
En este caso, aunque existían productos eliminados, el usuario decidió que está
condición no fuese tomada en cuenta, ya que habían movimientos que ha- cían
referencia a productos con este estado.
Es necesario realizar una unión entre la tabla “Productos” y “Marcas”, por lo cual se
debió asegurar que ningún producto hiciera mención a alguna marca que no existiese,
y se tomaron medidas contra su futura aparición.
El SQL es el siguiente:
Figura 5.32: Caso práctico, sentencia SQL de ”PRODUCTOS”.
Dimensión “FECHA”:
Para generar esta dimensión, infaltable en todo DW, existen varias herramientas y
utilidades de software que proporcionan diversas opciones para su confección. Pero,
si no se cuenta con ninguna, se puede realizar a mano o mediante algún programa,
llenando los datos en un archivo, tabla, hoja de cálculo, etc, y luego exportándolos a
donde se requiera.
Lo que se hizo, fue realizar un pequeño programa para cargar en un archivo plano las
fechas desde el año del primer movimiento de la empresa, en este caso el año 2000,
hasta la fecha actual.
A continuación, se puede apreciar una muestra de los datos generados:
88
Figura 5.33: Caso práctico, datos de ”FECHA”.
Como se puede observar, la primera fila representa los nombres de las colum- nas, las cuales están
separadas entre sí, y para establecer delimitadores, por “;”, y sus nombres figuran entre
comillas dobles. De la segunda fila en adelante se encuentran todos los datos de la dimensión.
Los campos que son del tipo texto están encerrados entre comillas dobles, los que son
numéricos no.
La clave principal es un campo numérico representado por el formato “yyyymmdd”. La misma también
puede calcularse mediante la siguiente fórmula:
Figura 5.34: Caso práctico, fórmula ”yyyymmdd”.
Tabla de hechos “VENTAS”:
Para la confección de la tabla de hechos, se tuvieron que tomar como fuente las tablas
“Facturas_Ventas” y “Detalles_Venta”. Al igual que en las tablas de dimensiones, se
recolectaron las condiciones que deben cumplir los datos para considerarse de interés, y en este
caso, se trabajará solamente con aquellas facturas que no hayan sido anuladas.
Se investigó al respecto, y se llegó a la conclusión de que el campo que da dicha información

en “Anulada” de la tabla “Facturas_Ventas” y si el mismo posee el valor “1” significa que
efectivamente fue anulada.
Otro punto importante a tener en cuenta es que la fecha se debe convertir al formato numérico
“yyyymmdd”.
Aquí también se realizarán las sumarizaciones correspondientes de los hechos, para ello se utilizará
la cláusula GROUP BY para agrupar todos los registros a través de las claves primarias de esta
tabla.
La sentencia SQL resultante fue la siguiente:
89
Figura 5.35: Caso práctico, sentencia SQL de ”VENTAS”.
Con respecto a las actualizaciones del depósito de datos, también existen diversas
herramientas DW, que proveen muchas facilidades, por lo cual no se entrará en detalle en
su utilización, pero sí se establecerá por escrito las políticas que se han convenido con los
usuarios:
La información se refrescará cada semana.
Los datos de las dimensiones “PRODUCTO” y “CLIENTE” serán cargados total- mente cada
vez.
Los datos de la dimensión “FECHA” se cargarán de manera incremental teniendo en cuenta la
fecha de la última actualización.
Los datos de la tabla de hechos que corresponden al último año a partir de la fecha actual, serán
reemplazados cada vez.
Estas acciones se realizarán durante un periodo de prueba, para analizar cuál es la manera
más eficiente de generar las actualizaciones, basadas en el estudio de los cambios que se producen
en los OLTP y que afectan al contenido del DW.
97
Apéndice A
Descripción de la empresa
A.1. Identificación de la empresa

La empresa analizada, desarrolla las actividades comerciales de mayorista y minorista de
artículos de limpieza, en un ambiente geográfico de alcance nacional. De acuerdo a su
volumen de operaciones, se la puede considerar de tamaño mediano.
Con respecto a su clasificación, es una sociedad de responsabilidad limitada con fines de

lucro.
Su estructura está formalizada y posee características de una organización funcional.
A.2. Objetivos
Su objetivo principal es el de maximizar sus ganancias. Pero también, se puede adi-
cionar el objetivo de expandirse a un nuevo nivel de mercado, con el fin de conseguir
una mayor cantidad de clientes y posicionarse competitivamente por sobre sus rivales.
Otra meta que persigue, pero que aún no está definida como tal, es la de incursionar en
otros rubros para lograr diversificarse.
A.3. Políticas
La empresa posee escasos grandes clientes con un gran poder adquisitivo, y son pre-
cisamente estos, los que adquieren el volumen de los productos que se comercializan.
Debido a ello, la política que se utiliza para cubrir los objetivos antes mencionados, es la
de satisfacer ampliamente las necesidades de sus clientes, brindándoles confianza y
promoviendo un ambiente familiar entre los mismos. Esta acción se realiza con el fin de
mantener los clientes actuales y para que nuevos se interesen en su forma de operar.
Existe otra política que es implícita, por lo cual, no está definida tan estrictamente como
la anterior, y es la de mejorar continuamente, con el objetivo de sosegar las exi- gencias y
cambios en el mercado en el que actúa y para conseguir una mejor posición respecto a
sus competidores.
98
Ing. Bernabeu, R. Dario A. Descripción de la empresa
A.4. Estrategias
Dentro de las estrategias existentes, se han destacado dos por considerarse más sig-
nificativas, ellas son:
Expandir el ámbito geográfico, creando varias sucursales en puntos estratégicos del

país.
Añadir nuevos rubros a su actividad de comercialización.
A.5. Organigrama
A continuación, se expondrá un organigrama que fue confeccionado a partir de los
datos suministrados en la empresa, ya que no existía ninguno previamente predefinido.
Figura A.1: Organigrama.
A.6. Datos del entorno específico

Los clientes con que cuenta son bastantes variados y cubren un amplio margen. Los
mismos son tanto provinciales, como nacionales, con diferentes tipos de poder adquisi-
tivo.
99
A. Descripción de la empresa Ing. Bernabeu, R. Dario
Con respecto a sus proveedores, la empresa posee en algunos rubros diversas opciones
de las cuales puede elegir y comparar, pero en otros solo cuenta con pocas alternativas.
Además, tiene como rivales a nivel de mayoreo, varios competidores importantes y ya

consolidados en el mercado, pero, a nivel minorista aventaja por su tamaño y volumen de
actividades a sus principales competidores.
A.7. Relación de las metas de la organización con las

del DW
El DW coincide con la metas de la empresa, ya que esta necesita mejorar su eficiencia en la
toma de decisiones y contar con información detallada a tal fin. Esto es vital, ya que es muy
importante para procurar una mayor ventaja competitiva conocer cuáles son los factores
que inciden directamente sobre su rentabilidad, como así también, analizar su relación
con otros factores y sus respectivos por qué.
El DW aportará un gran valor a la empresa, entre las principales ventajas e inconve-

nientes que solucionará se pueden mencionar los siguientes:
Permitirá a los usuarios tener una visión general del negocio.
Transformará datos operativos en información analítica, enfocada a la toma de de-
cisiones.
Se podrán generar reportes dinámicos, ya que actualmente son estáticos y no ofre- cen
ninguna facilidad de análisis.
Soportará la estrategia de la empresa.
Aportará a la mejora continua de la estructura de la empresa.
A.8. Procesos
Los principales procesos que se llevan a cabo son los siguientes:
Venta:
• Minorista: es la que se le realiza a los clientes particulares que se acercan hasta la

empresa para adquirir los productos que requieren.
• Mayorista: es la que se le efectúa a los grandes clientes, ya sea por medio de
comunicaciones telefónicas, o a través de visitas o reuniones.
• Al realizarse una venta, el departamento de Depósito se encarga de controlar el stock,
realizar encargos de mercadería en caso de no cubrir lo solicitado, armar el pedido y
enviarlo por medio de transporte propio o de terceros al destino correspondiente.
Compra:
• El departamento de Compras, al recibir del departamento de Depósito las necesidades

de mercadería, realiza una comparación de los productos ofrecidos por sus diferentes
proveedores en cuestión de precio, calidad y confianza. Pos- teriormente, se efectúa el
pedido correspondiente.
10
0
Ing. Bernabeu, R. Dario A. Descripción de la empresa
100
Apéndice B
Licencia de Documentación
Libre de GNU
Versión 1.2, Noviembre 2002
This is an unofficial translation of the GNU Free Documentation License into Spanish. It
was not published by the Free Software Foundation, and does not legally state the
distribution terms for documentation that uses the GNU FDL
– only the original English text of the GNU FDL does that. However, we hope that this
translation will help Spanish speakers understand the GNU FDL better.
Ésta es una traducción no oficial de la GNU Free Document License a Es- pañol
(Castellano). No ha sido publicada por la Free Software Foundation y no establece
legalmente los términos de distribución para trabajos que usen la GFDL (sólo el
texto de la versión original en Inglés de la GFDL lo hace). Sin embargo, esperamos
que esta traducción ayude los hispanohablantes a entender mejor la GFDL. La versión
original de la GFDL esta disponible en la Free Soft- ware Foundation.
Esta traducción está basada en una de la versión 1.1 de Igor Támara y Pa- blo Reyes.
Sin embargo la responsabilidad de su interpretación es de Joaquín Seoane.
Copyright ©2000, 2001, 2002 Free Software Foundation, Inc. 59 Temple Pla- ce, Suite
330, Boston, MA 02111-1307 USA. Se permite la copia y distribución de copias
literales de este documento de licencia, pero no se permiten cam- bios1 .
B.1. Preámbulo
El propósito de esta Licencia es permitir que un manual, libro de texto, u otro docu-
mento escrito sea libre en el sentido de libertad: asegurar a todo el mundo la libertad
efectiva de copiarlo y redistribuirlo, con o sin modificaciones, de manera comercial o no.
En segundo término, esta Licencia proporciona al autor y al editor2 una manera de
1 Ésta esla traducción del Copyright de la Licencia, no es el Copyright de esta traducción no autorizada.
2 Lalicencia original dice publisher, que es, estrictamente, quien publica, diferente de editor, que es más bien
quien prepara un texto para publicar. En castellano editor se usa para ambas cosas.
101
B. Licencia de Documentación Libre de GNU Ing. Bernabeu, R. Dario
obtener reconocimiento por su trabajo, sin que se le considere responsable de las modi-
ficaciones realizadas por otros.
Esta Licencia es de tipo copyleft, lo que significa que los trabajos derivados del docu-
mento deben a su vez ser libres en el mismo sentido. Complementa la Licencia Pública
General de GNU, que es una licencia tipo copyleft diseñada para el software libre.
Hemos diseñado esta Licencia para usarla en manuales de software libre, ya que el
software libre necesita documentación libre: un programa libre debe venir con manuales
que ofrezcan la mismas libertades que el software. Pero esta licencia no se limita a ma-
nuales de software; puede usarse para cualquier texto, sin tener en cuenta su temática o si
se publica como libro impreso o no. Recomendamos esta licencia principalmente para
trabajos cuyo fin sea instructivo o de referencia.
B.2. Aplicabilidad y definiciones

Esta Licencia se aplica a cualquier manual u otro trabajo, en cualquier soporte, que
contenga una nota del propietario de los derechos de autor que indique que puede ser
distribuido bajo los términos de esta Licencia. Tal nota garantiza en cualquier lugar del
mundo, sin pago de derechos y sin límite de tiempo, el uso de dicho trabajo según las
condiciones aquí estipuladas. En adelante la palabra Documento se referirá a cualquiera
de dichos manuales o trabajos. Cualquier persona es un licenciatario y será referido co-
mo Usted. Usted acepta la licencia si copia. modifica o distribuye el trabajo de cualquier
modo que requiera permiso según la ley de propiedad intelectual.
Una Versión Modificada del Documento significa cualquier trabajo que contenga el
Documento o una porción del mismo, ya sea una copia literal o con modificaciones y/o
traducciones a otro idioma.
Una Sección Secundaria es un apéndice con título o una sección preliminar del Do-
cumento que trata exclusivamente de la relación entre los autores o editores y el tema
general del Documento (o temas relacionados) pero que no contiene nada que entre di-
rectamente en dicho tema general (por ejemplo, si el Documento es en parte un texto
de matemáticas, una Sección Secundaria puede no explicar nada de matemáticas). La
relación puede ser una conexión histórica con el tema o temas relacionados, o una opi-
nión legal, comercial, filosófica, ética o política acerca de ellos.
Las Secciones Invariantes son ciertas Secciones Secundarias cuyos títulos son desig-
nados como Secciones Invariantes en la nota que indica que el documento es liberado
bajo esta Licencia. Si una sección no entra en la definición de Secundaria, no puede
designarse como Invariante. El documento puede no tener Secciones Invariantes. Si el
Documento no identifica las Secciones Invariantes, es que no las tiene.
Los Textos de Cubierta son ciertos pasajes cortos de texto que se listan como Textos de
Cubierta Delantera o Textos de Cubierta Trasera en la nota que indica que el docu-
mento es liberado bajo esta Licencia. Un Texto de Cubierta Delantera puede tener como
mucho 5 palabras, y uno de Cubierta Trasera puede tener hasta 25 palabras.
Una copia Transparente del Documento, significa una copia para lectura en máquina,
representada en un formato cuya especificación está disponible al público en general,
apto para que los contenidos puedan ser vistos y editados directamente con editores
de texto genéricos o (para imágenes compuestas por puntos) con programas genéricos
102
de manipulación de imágenes o (para dibujos) con algún editor de dibujos ampliamente

disponible, y que sea adecuado como entrada para formateadores de texto o para su
traducción automática a formatos adecuados para formateadores de texto. Una copia
hecha en un formato definido como Transparente, pero cuyo marcaje o ausencia de él
haya sido diseñado para impedir o dificultar modificaciones posteriores por parte de los
lectores no es Transparente. Un formato de imagen no es Transparente si se usa para
una cantidad de texto sustancial. Una copia que no es Transparente se denomina Opaca.
Como ejemplos de formatos adecuados para copias Transparentes están ASCII puro sin
marcaje, formato de entrada de Texinfo, formato de entrada de LATEX, SGML o XML
usando una DTD disponible públicamente, y HTML, PostScript o PDF simples, que sigan los
estándares y diseñados para que los modifiquen personas. Ejemplos de formatos de
imagen transparentes son PNG, XCF y JPG. Los formatos Opacos incluyen formatos
propietarios que pueden ser leídos y editados únicamente en procesadores de palabras
propietarios, SGML o XML para los cuáles las DTD y/o herramientas de procesamiento no
estén ampliamente disponibles, y HTML, PostScript o PDF generados por algunos proce-
sadores de palabras sólo como salida.
La Portada significa, en un libro impreso, la página de título, más las páginas siguientes
que sean necesarias para mantener legiblemente el material que esta Licencia requiere
en la portada. Para trabajos en formatos que no tienen página de portada como tal,
Portada significa el texto cercano a la aparición más prominente del título del trabajo,
precediendo el comienzo del cuerpo del texto.
Una sección Titulada XYZ significa una parte del Documento cuyo título es precisa-
mente XYZ o contiene XYZ entre paréntesis, a continuación de texto que traduce XYZ a
otro idioma (aquí XYZ se refiere a nombres de sección específicos mencionados más
abajo, como Agradecimientos, Dedicatorias , Aprobaciones o Historia. Conservar el Títu- lo
de tal sección cuando se modifica el Documento significa que permanece una sección
Titulada XYZ según esta definición3 .
El Documento puede incluir Limitaciones de Garantía cercanas a la nota donde se

declara que al Documento se le aplica esta Licencia. Se considera que estas Limitacio- nes
de Garantía están incluidas, por referencia, en la Licencia, pero sólo en cuanto a
limitaciones de garantía: cualquier otra implicación que estas Limitaciones de Garantía
puedan tener es nula y no tiene efecto en el significado de esta Licencia.
B.3. Copia literal

Usted puede copiar y distribuir el Documento en cualquier soporte, sea en forma co-
mercial o no, siempre y cuando esta Licencia, las notas de copyright y la nota que indica
que esta Licencia se aplica al Documento se reproduzcan en todas las copias y que usted no
añada ninguna otra condición a las expuestas en esta Licencia. Usted no puede usar
medidas técnicas para obstruir o controlar la lectura o copia posterior de las copias que
usted haga o distribuya. Sin embargo, usted puede aceptar compensación a cambio de las
copias. Si distribuye un número suficientemente grande de copias también deberá seguir
las condiciones de la sección 3.
Usted también puede prestar copias, bajo las mismas condiciones establecidas ante-
riormente, y puede exhibir copias públicamente.
3 En sentido estricto esta licencia parece exigir que los títulos sean exactamente Acknowledgements, Dedi-
cations, Endorsements e History, en inglés.
103
B.4. Copiado en cantidad

Si publica copias impresas del Documento (o copias en soportes que tengan normal-
mente cubiertas impresas) que sobrepasen las 100, y la nota de licencia del Documento
exige Textos de Cubierta, debe incluir las copias con cubiertas que lleven en forma cla-
ra y legible todos esos Textos de Cubierta: Textos de Cubierta Delantera en la cubierta
delantera y Textos de Cubierta Trasera en la cubierta trasera. Ambas cubiertas deben
identificarlo a Usted clara y legiblemente como editor de tales copias. La cubierta de-
be mostrar el título completo con todas las palabras igualmente prominentes y visibles.
Además puede añadir otro material en las cubiertas. Las copias con cambios limitados a
las cubiertas, siempre que conserven el título del Documento y satisfagan estas condi-
ciones, pueden considerarse como copias literales.
Si los textos requeridos para la cubierta son muy voluminosos para que ajusten legi-
blemente, debe colocar los primeros (tantos como sea razonable colocar) en la verdadera
cubierta y situar el resto en páginas adyacentes.
Si Usted publica o distribuye copias Opacas del Documento cuya cantidad exceda las
100, debe incluir una copia Transparente, que pueda ser leída por una máquina, con cada
copia Opaca, o bien mostrar, en cada copia Opaca, una dirección de red donde cualquier
usuario de la misma tenga acceso por medio de protocolos públicos y estandarizados a
una copia Transparente del Documento completa, sin material adicional. Si usted hace
uso de la última opción, deberá tomar las medidas necesarias, cuando comience la dis-
tribución de las copias Opacas en cantidad, para asegurar que esta copia Transparente
permanecerá accesible en el sitio establecido por lo menos un año después de la última
vez que distribuya una copia Opaca de esa edición al público (directamente o a través
de sus agentes o distribuidores).
Se solicita, aunque no es requisito, que se ponga en contacto con los autores del
Documento antes de redistribuir gran número de copias, para darles la oportunidad de
que le proporcionen una versión actualizada del Documento.
B.5. Modificaciones
Puede copiar y distribuir una Versión Modificada del Documento bajo las condiciones de
las secciones 2 y 3 anteriores, siempre que usted libere la Versión Modificada bajo esta
misma Licencia, con la Versión Modificada haciendo el rol del Documento, por lo tanto
dando licencia de distribución y modificación de la Versión Modificada a quienquiera
posea una copia de la misma. Además, debe hacer lo siguiente en la Versión Modificada:
A) Usar en la Portada (y en las cubiertas, si hay alguna) un título distinto al del Do-
cumento y de sus versiones anteriores (que deberían, si hay alguna, estar listadas en la
sección de Historia del Documento). Puede usar el mismo título de versiones
anteriores al original siempre y cuando quien las publicó originalmente otorgue permiso.
B) Listar en la Portada, como autores, una o más personas o entidades responsables de la
autoría de las modificaciones de la Versión Modificada, junto con por lo menos cinco de los
autores principales del Documento (todos sus autores principales, si hay menos de
cinco), a menos que le eximan de tal requisito.
C) Mostrar en la Portada como editor el nombre del editor de la Versión Modificada. D)
Conservar todas las notas de copyright del Documento.
104
E) Añadir una nota de copyright apropiada a sus modificaciones, adyacente a las otras
notas de copyright.
F) Incluir, inmediatamente después de las notas de copyright, una nota de licencia dando
el permiso para usar la Versión Modificada bajo los términos de esta Licencia, como se
muestra en la Adenda al final de este documento.
G) Conservar en esa nota de licencia el listado completo de las Secciones Inva- riantes
y de los Textos de Cubierta que sean requeridos en la nota de Licencia del Documento
original.
H) Incluir una copia sin modificación de esta Licencia.
I) Conservar la sección Titulada Historia, conservar su Título y añadirle un elemento que
declare al menos el título, el año, los nuevos autores y el editor de la Versión Modificada,
tal como figuran en la Portada. Si no hay una sección Titulada Historia en el Documento,
crear una estableciendo el título, el año, los autores y el editor del Documento, tal como
figuran en su Portada, añadiendo además un elemento describiendo la Versión
Modificada, como se estableció en la oración anterior.
J) Conservar la dirección en red, si la hay, dada en el Documento para el acceso público
a una copia Transparente del mismo, así como las otras direcciones de red dadas en el
Documento para versiones anteriores en las que estuviese basado. Pueden ubicarse en
la sección Historia. Se puede omitir la ubicación en red de un trabajo que haya sido
publicado por lo menos cuatro años antes que el Documento mismo, o si el editor original
de dicha versión da permiso.
K) En cualquier sección Titulada Agradecimientos o Dedicatorias, Conservar el Título de la
sección y conservar en ella toda la sustancia y el tono de los agradecimientos y/o
dedicatorias incluidas por cada contribuyente.
L) Conservar todas las Secciones Invariantes del Documento, sin alterar su texto ni sus
títulos. Números de sección o el equivalente no son considerados parte de los títulos de la
sección.
M) Borrar cualquier sección titulada Aprobaciones. Tales secciones no pueden estar
incluidas en las Versiones Modificadas.
N) No cambiar el título de ninguna sección existente a Aprobaciones ni a uno que entre en
conflicto con el de alguna Sección Invariante.
O) Conservar todas las Limitaciones de Garantía.
Si la Versión Modificada incluye secciones o apéndices nuevos que califiquen como Sec-
ciones Secundarias y contienen material no copiado del Documento, puede opcional-
mente designar algunas o todas esas secciones como invariantes. Para hacerlo, añada sus
títulos a la lista de Secciones Invariantes en la nota de licencia de la Versión Modifi- cada.
Tales títulos deben ser distintos de cualquier otro título de sección.
Puede añadir una sección titulada Aprobaciones, siempre que contenga únicamente
aprobaciones de su Versión Modificada por otras fuentes –por ejemplo, observaciones de
peritos o que el texto ha sido aprobado por una organización como la definición oficial de
un estándar.
Puede añadir un pasaje de hasta cinco palabras como Texto de Cubierta Delantera y un
pasaje de hasta 25 palabras como Texto de Cubierta Trasera en la Versión Modificada. Una
entidad solo puede añadir (o hacer que se añada) un pasaje al Texto de Cubierta De- lantera
y uno al de Cubierta Trasera. Si el Documento ya incluye un textos de cubiertas
105
añadidos previamente por usted o por la misma entidad que usted representa, usted no
puede añadir otro; pero puede reemplazar el anterior, con permiso explícito del editor
que agregó el texto anterior.
Con esta Licencia ni los autores ni los editores del Documento dan permiso para usar sus
nombres para publicidad ni para asegurar o implicar aprobación de cualquier Versión
Modificada.
B.6. Combinación de documentos

Usted puede combinar el Documento con otros documentos liberados bajo esta Li-
cencia, bajo los términos definidos en la sección 4 anterior para versiones modificadas,
siempre que incluya en la combinación todas las Secciones Invariantes de todos los do-
cumentos originales, sin modificar, listadas todas como Secciones Invariantes del trabajo
combinado en su nota de licencia. Así mismo debe incluir la Limitación de Garantía.
El trabajo combinado necesita contener solamente una copia de esta Licencia, y puede
reemplazar varias Secciones Invariantes idénticas por una sola copia. Si hay varias
Secciones Invariantes con el mismo nombre pero con contenidos diferentes, haga el títu-
lo de cada una de estas secciones único añadiéndole al final del mismo, entre paréntesis,
el nombre del autor o editor original de esa sección, si es conocido, o si no, un número
único. Haga el mismo ajuste a los títulos de sección en la lista de Secciones Invariantes
de la nota de licencia del trabajo combinado.
En la combinación, debe combinar cualquier sección Titulada Historia de los docu-

mentos originales, formando una sección Titulada Historia; de la misma forma combine
cualquier sección Titulada Agradecimientos, y cualquier sección Titulada Dedicatorias.
Debe borrar todas las secciones tituladas Aprobaciones.
B.7. Colecciones de documentos

Puede hacer una colección que conste del Documento y de otros documentos liberados
bajo esta Licencia, y reemplazar las copias individuales de esta Licencia en todos los
documentos por una sola copia que esté incluida en la colección, siempre que siga las
reglas de esta Licencia para cada copia literal de cada uno de los documentos en
cualquiera de los demás aspectos.
Puede extraer un solo documento de una de tales colecciones y distribuirlo individual-

mente bajo esta Licencia, siempre que inserte una copia de esta Licencia en el documen-
to extraído, y siga esta Licencia en todos los demás aspectos relativos a la copia literal
de dicho documento.
B.8. Agregación con trabajos independientes

Una recopilación que conste del Documento o sus derivados y de otros documentos o
trabajos separados e independientes, en cualquier soporte de almacenamiento o dis-
tribución, se denomina un agregado si el copyright resultante de la compilación no se
usa para limitar los derechos de los usuarios de la misma más allá de lo que los de los
trabajos individuales permiten. Cuando el Documento se incluye en un agregado, esta
Licencia no se aplica a otros trabajos del agregado que no sean en sí mismos derivados
106
del Documento.
Si el requisito de la sección 3 sobre el Texto de Cubierta es aplicable a estas copias del

Documento y el Documento es menor que la mitad del agregado entero, los Textos de
Cubierta del Documento pueden colocarse en cubiertas que enmarquen solamente el
Documento dentro del agregado, o el equivalente electrónico de las cubiertas si el
documento está en forma electrónica. En caso contrario deben aparecer en cubiertas
impresas enmarcando todo el agregado.
B.9. Traducción
La Traducción es considerada como un tipo de modificación, por lo que usted puede
distribuir traducciones del Documento bajo los términos de la sección 4. El reemplazo las
Secciones Invariantes con traducciones requiere permiso especial de los dueños de
derecho de autor, pero usted puede añadir traducciones de algunas o todas las Seccio- nes
Invariantes a las versiones originales de las mismas. Puede incluir una traducción de esta
Licencia, de todas las notas de licencia del documento, así como de las Limita- ciones de
Garantía, siempre que incluya también la versión en Inglés de esta Licencia y las versiones
originales de las notas de licencia y Limitaciones de Garantía. En caso de desacuerdo
entre la traducción y la versión original en Inglés de esta Licencia, la nota de licencia o la
limitación de garantía, la versión original en Inglés prevalecerá.
Si una sección del Documento está Titulada Agradecimientos, Dedicatorias o Historia el

requisito (sección 4) de Conservar su Título (Sección 1) requerirá, típicamente, cambiar
su título.
B.10. Terminación
Usted no puede copiar, modificar, sublicenciar o distribuir el Documento salvo por lo
permitido expresamente por esta Licencia. Cualquier otro intento de copia, modificación,
sublicenciamiento o distribución del Documento es nulo, y dará por terminados automá-
ticamente sus derechos bajo esa Licencia. Sin embargo, los terceros que hayan recibido
copias, o derechos, de usted bajo esta Licencia no verán terminadas sus licencias, siempre
que permanezcan en total conformidad con ella.
B.11. Revisiones futuras de esta licencia

De vez en cuando la Free Software Foundation puede publicar versiones nuevas y
revisadas de la Licencia de Documentación Libre GNU. Tales versiones nuevas serán si-
milares en espíritu a la presente versión, pero pueden diferir en detalles para solucionar
nuevos problemas o intereses. Vea http://www.gnu.org/copyleft/.
Cada versión de la Licencia tiene un número de versión que la distingue. Si el Docu- mento
especifica que se aplica una versión numerada en particular de esta licencia o cualquier
versión posterior, usted tiene la opción de seguir los términos y condiciones de la versión
especificada o cualquiera posterior que haya sido publicada (no como borrador) por la
Free Software Foundation. Si el Documento no especifica un número de versión de esta
Licencia, puede escoger cualquier versión que haya sido publicada (no como borrador) por
la Free Software Foundation.
107
B.12. Adenda: cómo usar esta Licencia en sus docu-

mentos
Para usar esta licencia en un documento que usted haya escrito, incluya una copia de
la Licencia en el documento y ponga el siguiente copyright y nota de licencia justo
después de la página de título:
Copyright ©AÑO SU NOMBRE. Se otorga permiso para copiar, distribuir y/o

modificar este documento bajo los términos de la Licencia de Documentación Libre
de GNU, Versión 1.2 o cualquier otra versión posterior publicada por la Free
Software Foundation; sin Secciones Invariantes ni Textos de Cubierta De- lantera ni
Textos de Cubierta Trasera. Una copia de la licencia está incluida en la sección
titulada GNU Free Documentation License.
Si tiene Secciones Invariantes, Textos de Cubierta Delantera y Textos de Cubierta Trase-

ra, reemplace la frase sin ... Trasera por esto:
siendo las Secciones Invariantes LISTE SUS TÍTULOS, siendo los Textos de Cubierta
Delantera LISTAR, y siendo sus Textos de Cubierta Trasera LISTAR.
Si tiene Secciones Invariantes sin Textos de Cubierta o cualquier otra combinación de los
tres, mezcle ambas alternativas para adaptarse a la situación.
Si su documento contiene ejemplos de código de programa no triviales, recomendamos

liberar estos ejemplos en paralelo bajo la licencia de software libre que usted elija, como
la Licencia Pública General de GNU (GNU General Public License), para permitir su uso en
software libre.
108
Bibliografía
[1] Laboratorios, prácticos, apuntes y bibliografía de la materia MOTORES DE BASE DE

DATOS – Ing. Mauricio Rizzi, Ing. Mariano García Mattío – Instituto Universitario Aero-
náutico (IUA) - Año 2006.
[2] Laboratorios, prácticos, apuntes y bibliografía de la materia SOPORTE PARA LA TOMA
DE DECISIONES – Ing. María Alejandra Boggio – Instituto Universitario Aeronáutico (IUA)
– Año 2006.
[3] Laboratorios, prácticos, apuntes y bibliografía del curso SISTEMAS AVANZADOS DE

BASE DE DATOS CON SOPORTE PARA LA TOMA DE DECISIONES – Ing. Mauricio Rizzi –
Universidad Católica de Córdoba (UCC) – Año 2006.
[4] WIKIPEDIA.org y links relacionados.

[5] ESTRATEGIA COMPETITIVA, Técnicas para el Análisis de los Sectores Industriales y de
la Competencia – Michael E. Porter – Año 2000 – Vigésima séptima reimpresión.
[6] EL NUEVO DIRECTIVO RACIONAL, Análisis de problemas y toma de decisiones – Char-
les H. Kepner, Benjamin B. Tregoe – Ed. McGraw-Hill – Año 1992
[7] Ingeniería del Software, Un enfoque práctico – Roger S. Pressman. MacGraw-Hill –
Año 2001 – 5ta Edición.
109

Metodologia Hefesto Warehouse Parte 2 PDF

Cargado por

Copyright:

Formatos disponibles

Metodologia Hefesto Warehouse Parte 2 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodologia Hefesto Warehouse Parte 2 PDF

Cargado por

Copyright:

Formatos disponibles

DATA WAREHOUSING:

Ing. Bernabeu, Ricardo Dario

Córdoba, Argentina – Miércoles 07 de Noviembre de 2007

HEFESTO: Metodología propia

En esta segunda parte de la publicación, se propondrá una metodología propia para la

Primero, se describirán los aspectos más sobresalientes de la metodología y luego se

Figura 5.1: Metodología HEFESTO, logotipo.

La construcción e implementación de un DW puede adaptarse muy bien a cualquier ciclo

Figura 5.2: Metodología HEFESTO, pasos.

Como se puede apreciar, se comienza recolectando las necesidades de información de los

5.4. Empresa analizada

Además, este análisis ayudará a conocer el funcionamiento y accionar de la empresa, lo que

La descripción de la empresa se encuentra en el Apéndice A (página 97).

5.5. Pasos y aplicación metodológica

5.5.1. PASO 1) ANÁLISIS DE REQUERIMIENTOS

El primer paso comienza con el acopio de las necesidades de información, el

El análisis de los requerimientos de los diferentes usuarios, es el punto de partida

El objetivo principal de esta fase, es la de obtener e identificar las necesidades de

Debe tenerse en cuenta que dicha información, es la que proveerá el soporte

Una forma de asegurarse de que se ha realizado un buen análisis, es que el

Otra forma de encaminar el relevamiento, es enfocar las necesidades de

Un punto importante que debe tenerse muy en cuenta, es que la información

monto total de ventas.

El resultado obtenido fue el siguiente:

5.5.1.2. b) Identificar indicadores y perspectivas de análisis

Figura 5.3: Caso práctico, indicadores y perspectivas.

En síntesis, los indicadores son:

Unidades vendidas. Monto

Y las perspectivas de análisis son:

5.5.1.3. c) Modelo Conceptual

En esta etapa, se construirá un modelo conceptual1 a partir de los indicadores y

La representación gráfica del modelo conceptual es la siguiente:

Figura 5.4: Modelo Conceptual.

1 Modelo Conceptual: descripción de alto nivel de la estructura de la base de datos, en la cual la

Figura 5.5: Caso práctico, Modelo Conceptual.

5.5.2. PASO 2) ANÁLISIS DE LOS OLTP

El objetivo de este análisis, es el de examinar los OLTP disponibles que contengan la

Figura 5.6: Caso práctico, Diagrama de Entidad Relación.

Los indicadores se calcularán de la siguiente manera:

A continuación, se expondrá la correspondencia entre los dos modelos:

Figura 5.7: Caso práctico, correspondencia.

Las relaciones identificadas fueron las siguientes:

5.5.2.2. b) Seleccionar los campos que integrarán cada perspectiva. Nivel de

Para ello, basándose en las correspondencias establecidas en el paso anterior, se de- be

Con respecto a la perspectiva “Tiempo”, es muy importante definir el ámbito

Finalmente, y con el fin de graficar los resultados obtenidos, se ampliará el

Figura 5.8: Modelo Conceptual con atributos.

• CUIT: número de C.U.I.T. del cliente.

• Nombre del día.

Teniendo esto en cuenta, se completará el diseño del diagrama conceptual:

Figura 5.9: Caso práctico, Modelo Conceptual con atributos.

5.5.3. PASO 3) ELABORACIÓN DEL MODELO LÓGICO DE LA

5.5.3.1. a) Diseñar tablas de dimensiones

Se elegirá un nombre que identifique la dimensión.

Se añadirá un campo que represente su clave principal.

Se redefinirán los nombres de los atributos si es que no son lo bastante explicativos.

Figura 5.10: Diseño de tablas de dimensiones.

Figura 5.11: Caso práctico, dimensión ”CLIENTE”.

Figura 5.12: Caso práctico, dimensión ”PRODUCTO”.