SSDG - Sistemas de soporte de decisión en grupo

SSD – Resumen Examen Final UBP - Mayo 2013
Módulo 1: Sistemas de soporte de dirección
Unidad 1: Introducción a los sistemas de soporte de dirección

Concepto de sistemas de soporte de dirección.
Los Sistemas de Soporte de Dirección se brindan a través de tecnologías computarizadas -generalmente,
avanzadas y emergentes- y tienen como objetivo brindar soporte al quehacer gerencial y al proceso de toma de
decisiones, para lograr competitividad, velocidad en la respuesta, y brindar soporte a los problemas de los
directivos.
Los sistemas de soporte de dirección que explicaremos son los siguientes:
• Sistemas de soporte de decisión (SSD)
• Sistemas de soporte de decisión en grupo (SSDG)
• Sistemas de información ejecutivos (SIE)
• Sistemas expertos (SE)
• Redes neuronales artificiales
• Sistemas de información gerencial (SIG)
Otros conceptos
Dirección: Conduce a la organización a funcionar. Su objetivo es alcanzar el máximo rendimiento
de todos sus empleados en el interés de los aspectos generales. Es el proceso por el cual son
alcanzadas ciertas metas mediante el uso de recursos (humanos, materiales, energéticos,
financieros, informáticos, etc.). Los recursos son considerados la entrada, y la consecución de
las metas, la salida del proceso.
Productividad: es la medida del éxito, la relación entre las entradas y las salidas. Productividad =
S/E. El nivel de productividad depende de funciones como planificación, organización, dirección y
control. Para llevar a cabo estas funciones, el directivo está inmerso en un continuo proceso de
toma de decisiones.
Decidir: Es “realizar un proceso mental, deliberado, voluntario, sistemático, a través del ejercicio
del raciocinio, con la finalidad de elegir un curso de acción (y sólo uno) entre un conjunto de
cursos de acción alternativos...”.
Antiguamente, se consideraba la toma de decisiones como un arte, basado en la creatividad, intuición y

experiencia más que en métodos cuantitativos o científicos. Con el transcurso del tiempo, el entorno para la
toma de decisiones está cambiando y cada vez es más complejo. Los factores que producen el cambio son:
Factor Tendencia Resultado

Tecnología  Mas alternativas para elegir
Informática/Computación 
Estructura compleja  Grandes costos en caso de
 cometer errores
Competencia
Mercados internacionales  Mayor incertidumbre con respecto
 al futuro
Estabilidad política
Como resultado de estos factores (cambio del entorno y complejidad de las decisiones), los directivos no
pueden administrar en base a la prueba y el error; se hace necesaria la utilización de técnicas, herramientas,
métodos cuantitativos y científicos que ayuden en este proceso de toma de decisiones.
SIG - Sistemas de Información Gerencial (1960)

Un SIG es un sistema formal basado en computadoras, cuyo objetivo es recuperar, extraer e integrar datos de
varias fuentes para proveer la información necesaria para la toma de decisiones gerenciales.
Características:
• Su mayor potencial está en proveer información para la toma de decisiones rutinarias simples,
repetitivas y anticipadas.
• No son exitosos para tomar decisiones en situaciones complejas.
1/69
• Son los primeros sistemas de información existentes para la toma de decisiones rutinarias,
estructuradas y anticipadas.
• No poseem capacidades de modelado.
• No son fáciles de utilizar por los usuarios gerenciales.
• Su interfaz no es amigable.
SSD - Sistemas de Soporte de Decisión (1970-1980)

Un SSD es un sistema de información computarizado, flexible, interactivo y adaptable, especialmente
desarrollado para solucionar problemas de dirección particulares con el objeto de mejorar la toma de
decisiones. Emplea datos y provee interfaces de usuario sencillas. En un modo sofisticado incluye también el
desarrollo de modelos.
¿Por qué se usan?
• Las compañías fueron operando en un ambiente inestable y compiten en mercados caracterizados por
competitividad, especialización y dinamismo. Esto obliga a estar alertas a los cambios.
• Los sistemas de información en las empresas no soportan los objetivos de incrementar la eficiencia,
beneficio e ingresar en mercados productivos.
• El usuario final no necesita ser programador, ya que tiene herramientas y procedimientos de fácil uso.
Características
• Provee soporte a las decisiones semi-estructuradas o no estructuradas.
• Es interactivo, por ser un sistema computacional con la posibilidad de interactuar en forma
amigable y con respuestas en tiempo real, con el encargado de tomar decisiones.
• Es fácil de usar, puesto que posee una interfaz amigable y simple y no requiere entrenamiento.
Es simple y posible de aprender y utilizar por el usuario final.
• Posee amplias bases de datos: tiene la capacidad de acceder a la información de las bases de
datos corporativas.
• Soporta modelos y capacidades analíticas.
• Tiene un proceso evolutivo de diseño.
• Da soporte a las diferentes etapas del proceso de toma de decisiones
• No debe imponer una decisión.
Beneficios
• Posibilidad de soportar la solución a problemas complejos.
• Rápida respuesta a los cambios de escenarios.
• Facilita la comunicación de información relevante de los niveles altos a los niveles operativos y
viceversa, a través de gráficas. Puede emplearse por usuarios de diferentes áreas funcionales
como ventas, producción, administración, finanzas y recursos humanos.
• Mejora el control, rendimiento y la eficiencia de los directivos Tiene una utilización frecuente por
parte de la administración media y alta para el desempeño de su función.
• Reduce costos.
• Favorece toma de decisiones objetivas.
Componentes
Los componentes de un SSD son diversos administradores: el administrador de Datos, que contiene la base de
datos decisional y el DBMS; el de Modelos, que agrupa un conjunto de modelos cualitativos y cuantitativos y el
software apropiado para su construcción, el administrador de Diálogo, que provee la interfaz con el usuario y el
administrador de Conocimiento, que se usa en el caso de los Sistemas expertos.
SE - Sistemas Expertos (1980-1990)

Un SE es un paquete para resolución de problemas que puede alcanzar y a veces sobrepasar el nivel del
experto humano en algún área específica, y que además del software puede incluir hardware.
Los SE son una rama de aplicación de la inteligencia artificial, cuya idea básica es transferir el conocimiento del
humano a la computadora. Generalmente se utiliza estos sistemas para diagnósticos médicos, configuración de
computadoras, situaciones donde es demasiado caro o imposible acceder a un especialista, entornos donde no
pueden trabajar las personas, etc.
El objetivo de un sistema experto es diseñar un algoritmo de búsqueda para propósitos generales que sea
2/69
capaz de vincular pasos de razonamiento elementales para encontrar una solución completa (Stuart Russell,
2003).
SSDG - Sistemas de Soporte de Decisión en Grupo (1990)
La mayoría de las decisiones complejas en las diferentes organizaciones son tomadas por grupos, no por
individuos aislados, pero reunir un grupo en un lugar para tomar una decisión es complicado y costoso. Para
ello se desarrollaron los SSDG: estos sistemas permiten tomar decisiones cuando los integrantes están
geográficamente separados, reduciendo el costo de reunirlos.
Los SSDG ofrecen a los equipos el potencial de reducir sus esfuerzos mediante métodos automáticos para
ingresar, grabar y operar sobre las ideas de los miembros de los equipos durante el encuentro. Permiten
mostrar las ideas al resto del grupo, como así también la realización de votaciones.
Ejemplos: mails, conferencias, mesas de discusión, etc.
SIE - Sistemas de Información Ejecutivos (Executive Information System en inglés) (1990)

Un sistema de Información ejecutivo es un sistema computarizado que intenta devolver, extraer e integrar datos
de varias fuentes en forma organizada, proveyendo información para la toma de decisiones ejecutiva.
Generalmente brinda información de tipo rutinaria, estructurada para decisiones anticipadas.
Un SIE tiene amplias prestaciones en cuanto a base de datos e interfaz de usuario, pero su capacidad de
modelado es rudimentaria.
“SIE es lo que un Ejecutivo Senior utiliza para encontrar problemas, mientras que un SSD es lo que utiliza un
staff para resolverlo”. Turban, Efraim: Decision Support and Expert Systems
Características
• Brinda información que utiliza el ejecutivo.
• Provee interfaces extremadamente amigables a los ejecutivos.
• Contempla los estilos de dirección y decisión: autocráticos, participativos, etc.
• Capacidad de drill-down: posee un rápido acceso a la información detallada.
Diferencias entre SSD y SIE

SSD – Sistema de Soporte de Decisiones SIE – Sistema de Información de Ejecutivos
• Puede ser utilizado par la toma de decisiones • Brinda la información a manera de listados,
no programadas. reportes de excepción (muestra de ítems que
• La toma de decisión acepta el valor del modelo requieren de atención).
y el valor del resultado. • La estructura de los reportes son valores de
• Puede proveer soporte a las decisiones en un único problema.
muy poco tiempo.
• Puede ser desarrollado por personas que no
son profesionales.
Redes Neuronales Artificiales (1990)

Las redes neuronales tratan de copiar la manera en que trabaja el cerebro humano, pueden trabajar con
información parcial, incompleta o inexacta. Estos sistemas aprenden de la experiencia de situaciones previas,
una característica que no tenían los sistemas mencionados anteriormente (salvo algunos SE).
Características de los Sistemas y evolución cronológica

Dentro de la evolución cronológica de los sistemas podemos mencionar, además de los ya descriptos, a los
Sistemas de Procesamiento Transaccional (1950) , a los Sistemas de Automatización de Oficinas (1970) y a las
Herramientas de Decisión Colaborativas basadas en web y tecnología inalámbrica (2000 en adelante).
Características Sistemas de Sistemas de Sistemas de Sistemas Sistemas de Redes
Procesamiento Información Soporte de Expertos Información Neuronales
Transaccional Gerencial Decisión Ejecutiva
(TPS) (MIS) (DSS) (ES) (EIS)
Aplicación Inventario, Control de Planificación Diagnóstico, Soporte a las Decisiones
producción e producción, estratégica de planificación decisiones de la complejas y
información de proyección de largo alcance, estratégica, gerencia de alto repetitivas,
Ventas. ventas, problemas control interno. nivel. diagnóstico,
monitoreo. complejos. control de
3/69
inversión.
Enfoque Transacciones Información Decisiones, Transferencia Seguimiento, Reconocimiento
de datos flexibilidad, de la inferencia control y drill de Patrones.
amigable con el del down.
usuario conocimiento
de expertos
Base de Datos Única para Acceso Sistemas de Conocimiento Externo (online) Aprendizaje
cada aplicación, interactivo por administración procedural y de y corporativo, provisto por
actualización programadores. de BD, acceso la realidad, acceso casos
por lotes. interactivo, bases de distribuido a históricos.
conocimiento conocimiento todas las BD de
de la realidad (hechos, reglas) la empresa .
Capacidad de No usado para Problemas Problemas Los sistemas Sólo cuando Principalmente
Decisión decisión rutinarios y semi- realizan está combinado predicciones ,
estructurados estructurados, decisiones con un DSS basado en
usando integra modelos complejas, no información
herramientas de la ciencia de estructuradas, histórica.
convencionales la uso de reglas
de la ciencia de administración. (heurística).
la
administración.
Manipulación Numérica Numérica Numérica Simbólica Principalmente Numérica
numérica, a (necesita pre-
veces simbólica procesamiento)
Tipo de Reportes Reportes por Información Consejos y Reportes de Proyecciones,
información sumarizados, demanda y para soporte a explicaciones. excepción, clasificación de
operacional. programados, decisiones indicadores acuerdo a
reportes de específicas. clave. patrones.
excepción.
Más alto nivel Sub-gerencial, Gerencia Media Gerentes y Gerentes y Sólo ejecutivos Gerentes y
organizacional gerencia de Analistas Especialistas senior especialistas
que sirve bajo nivel
Relevancia en Conveniencia Eficiencia Efectividad Efectividad y Oportunidad de Conveniencia
conveniencia presentación
Tareas que realiza cada uno de los sistemas de Soporte de Dirección (Ejemplo)
Las siguientes son las tareas realizadas por cada uno de los sistemas de soporte de dirección para un sistema
de información basado en computadoras de un Departamento de Personal .
Categoría Tarea
Procesamiento Transaccional Mantener los registros del personal, preparar los pagos, cálculo de salarios
y planes de incentivo.
Sistema de Información Gerencial Preparar reportes sumarizados (por ejemplo: salario promedio de cada
departamento). Efectuar programación a corto plazo. Llevar el seguimiento
del rendimiento de los empleados, presupuesto laboral. Monitoreo del
sistema de control de posiciones (cargos). Realizar cronogramas de corto
plazo. Encontrar posiciones y candidatos. Realizar monitoreo y control de
beneficios.
Sistema de Soporte de Decisión Preparar reportes especializados (logro de igualdad de oportunidades).
Planificación a largo plazo de recursos humanos. Diseño de un plan de
compensaciones.
Sistema Experto Advierte acerca de implicaciones legales y técnicas durante la negociación
laboral. Selecciona el medio de entrenamiento. Diseña programas de
entrenamiento comprensivo. Desarrolla un plan de responsabilidad social.
Ayuda en la selección de nuevos empleados. Asiste en la evaluación anual
de empleados.
Automatización de Oficina Mantiene listas de correo, utiliza el correo electrónico, prepara material de
entrenamiento.
4/69
Sistema de Información Ejecutivo No existe a nivel departamental, sino corporativo. Mide los indicadores de
performance clave del departamento (tales como $ ganados/ invertidos por
empleado)
Sistema de Soporte de Decisión Soporta el proceso de toma de decisiones polémicas (ej: políticas de
en Grupo personal), brainstorming electrónico. Puede utilizarse para decisiones.
Computación Neuronal Analiza la causa por la cual las personas dejan o se quedan en la empresa
(encuentra patrones). Selecciona aspirantes para un trabajo.
Unidad 2: El proceso de toma de decisiones y los SSD

Los sistemas de soporte de decisión son sistemas de información dan soporte a la toma de decisiones,
específicamente a las estratégicas. Por este motivo, tenemos que analizar lo que es un proceso de toma de
decisiones.
Proceso de toma de decisiones

El proceso de toma de decisiones es la secuencia de etapas que se ejecutan o realizan para tomar una
decisión. También podemos decir que es el proceso de elegir entre varias alternativas. Como todo proceso,
puede dividirse en un conjunto de etapas básicas.
Etapas del proceso de toma de decisiones
• Paso A: Determinación de cuál es el problema. Encontrar el problema involucra la colección de

información desde varias fuentes para identificar el problema y las oportunidades. El SIE puede
ayudar en la búsqueda e interpretación de la información recogida, mediante amplias bases de
datos que permitan obtener información sobre el problema.
• Paso B: Analizar alternativas de solución. Una vez que el problema ha sido identificado, es el
momento de analizar y determinar cuáles son las alternativas posibles de la solución.
El análisis puede ser cuantitativo (soportado por un SSD y por herramientas de análisis) o
cualitativo (por SE), así como también mediante herramientas que den soporte al modelado.
• Paso C: Elección de la alternativa. En este paso se determina cuál es la mejor alternativa para el
caso y se la elige. La decisión se tomada basada en los resultados del análisis, puede ser
soportada por un SSD si la decisión es individual o por un SSDG si es grupal, y mediante
herramientas que permitan simular las diferentes alternativas, a fin de seleccionar la que más se
acerque a los objetivos propuestos.
• Paso D: Implementación. Es la puesta en marcha de la decisión, cuando ésta es implementada.
La solución puede haber sido propuesta por un DSS/ ES, entendidas como herramientas que
permiten comunicar y fundamentar la decisión tomada.
Fases involucradas en el proceso de toma de decisiones.

El proceso de toma de decisiones está compuesto por cuatro fases: de inteligencia, de diseño, de elección y de
implementación.
1. Fase de inteligencia
Esta fase comienza con la identificación de los objetivos organizacionales. Generalmente existe un problema
cuando hay diferencia entre lo que fue planeado y lo que sucede (o no sucede) , hay que estar atentos a
encontrar el problema real y no los síntomas del mismo.
La existencia del problema en una organización puede ser estimada, por ejemplo, monitoreando y analizando
los niveles de productividad de los departamentos de la organización. La medición de la productividad está
basada en los datos, la búsqueda de los ya existentes y la estimación de los futuros (este es uno de los pasos
más dificultosos del análisis).
Una vez que se completa la investigación preliminar, es posible determinar si el problema realmente existe,
dónde se localiza y qué importancia tiene.
En resumen, la fase de inteligencia puede involucrar otras actividades como:

1. Clasificación.
5/69
La actividad de conceptuar el problema involucra la clasificación dentro de ciertas categorías, de
acuerdo a la estructura del problema:
• Programados o estructurados: se programan en la medida en que son repetitivos y de
rutina, es decir en la medida en que se ha elaborado un procedimiento definido para
manejarlos de tal modo que no debe tratárselos de nuevo cada vez que se presentan.
Ej.: la fijación de precio de los pedidos comunes de los clientes, determinación de pago
de salarios, etc.
• No programados o no estructurados : en la medida en que resultan novedosos, no
estructurados e inusitadamente importantes en sí mismos. No existe ningún método
previsto para manejar el problema, porque éste no ha surgido antes, o porque su
naturaleza y estructura precisas son huidizas o muy complejas, o porque es tan
importante que merece un tratamiento hecho a la medida. Estos tipos de problemas le
corresponden a la dirección superior, a la alta gerencia.
Ej.: reorganización de la organización, proyecto de desarrollo de nuevos productos, etc.
2. Descomposición del problema.
Muchos problemas complejos pueden ser divididos en subproblemas, y resolviendo cada uno de
ellos se puede ayudar a solucionar el problema total.
Al analizar un problema, es importante establecer quién es su propietario: un problema existe en
una organización sólo si la organización tiene la capacidad de resolverlo.
Ej.: muchas organizaciones perciben que tienen problemas porque las tasas de interés son
demasiado altas. Las tasas de interés son el problema del gobierno y no de la compañía, ya que
ésta no puede reducirlas. El problema de la compañía es cómo operar en un ambiente con esas
altas tasas de interés.
La fase de inteligencia finaliza cuando el problema es identificado y definido, dando comienzo a la fase de
diseño.
2. Fase de diseño
La fase de diseño generalmente requiere desarrollar una tarea de análisis y remata en la generación de las
alternativas. Estas establecen qué caminos tenemos disponibles para el logro de los objetivos. Esta fase
incluye actividades como entendimiento del problema y control de la solución y su viabilidad.
Tanto en la fase de diseño como en la de elección, el decisor se vale de modelos que se construyen, testean y
validan.
Modelado de un problema
El modelado involucra la conceptualización del problema, lo cual incluye la abstracción de un modelo cualitativo
o cuantitativo. Es necesario encontrar el balance entre los niveles de representación del modelo y la realidad, y
no confundir el modelo obtenido con la realidad que representa. La tarea de modelar involucra combinación de
arte y ciencia.
Modelos cualitativos
Surgen en el siglo XX en el marco de la investigación social. Su objetivo es describir las cualidades de un
fenómeno; no se trata de probar ni medir el grado en que se encuentra una cualidad en un acontecimiento, sino
de descubrir tantas cualidades como sea posible.
Estos modelos intentan comprender la realidad dentro de un contexto dado y por lo tanto no pueden
fragmentarse ni dividirse en variables dependientes/independientes. Se aplican mayormente en las Ciencias
Sociales, y comprenden cuatro fases: Preparación, Trabajo de Campo, Fase analítica, Fase informativa.
Modelos cuantitativos
Para el modelado de modelos cuantitativos (matemáticos y financieros), se presentan los siguientes puntos:
1. Componentes del modelo
Los componentes están conectados por relaciones matemáticas (en los cualitativos las relaciones son
símbolos o cualidades), se identifican las variables dependientes e independientes y la ecuación
describe las relaciones entre ambas.
Variables:
• Variables de decisión: Las variables de decisión describen los cursos alternativos de acción.
6/69
Son clasificadas matemáticamente como variables independientes. Con apoyo de un SSD
se puede encontrar una buena o el mejor valor de esas variables.
Ej.: el número de cajeros de un banco. Uso de las computadoras.
• Variables de resultado: Reflejan el nivel de efectividad de los sistemas, indican cómo éstos
cumplen con la performance o se acercan a las metas.
Ej.: satisfacción del cliente, costo total de la producción.
• Incontrolables o parámetros. Son factores que afectan las variables de resultado, pero no
están bajo el control del sistema.
Ej.: leyes impositivas, tasas de interés.
• Intermedias: Son necesarias para unir las variables de decisión con las de resultado.
Algunas veces reflejan resultados intermedios. Por ejemplo: el salario de los empleados
(decisión) está determinado por la satisfacción de los empleados (salida intermedia) y fija
los niveles de productividad (resultado).
2. Estructura del modelo.
Los componentes son un conjunto de expresiones matemáticas como ecuaciones o inecuaciones.
Ejemplo: Modelo del valor presente
P: valor presente,
F: pago futuro,
I: Tasa de interés,
N: N° de años.
Usando este modelo, se puede encontrar el valor

que corresponde abonar de $100.000, a pagar en 5 años, con una tasa de interés del 10% anual.
Ejemplo: uso de las

computadoras.
Variables de decisión: utilización de las computadoras.
Variables de resultado: costo del procesamiento de las computadoras.
Variables incontrolables: tecnología disponible.
3. Principios de elección
La evaluación de alternativas depende del tipo de criterio que se use. ¿Tratamos de tomar la mejor
alternativa (óptima), o con una buena es suficiente?
El principio de elección determina la solución que se aceptará. Hay varios principios de elección:
• Normativos: existe una forma de demostrar que las alternativas seleccionadas son las
mejores de todas. Para ello se utiliza la programación lineal, transporte.
• Descriptivos: el modelo descriptivo muestra las cosas como son y como cree que deberían
ser. Muchos modelos son muy provechosos en SSD, por investigar las consecuencias de
los cursos de acción ante diferentes entradas y procesos. Chequean la performance del
sistema y el conjunto de las alternativas, lo cual no garantiza que las alternativas
seleccionadas sean las óptimas; en muchos casos son sólo satisfactorias.
Suboptimización
La suboptimización requiere que la decisión tomada considere el impacto de cada alternativa en la
organización global. La razón de la decisión tomada en un área puede tener efectos significativos en
las otras.
Ej.: la reducción de costos de un determinado producto, puede afectar la calidad de la producción.
4. Desarrollo de alternativas
Una gran parte del proceso de construcción del modelo consiste en la generación de las alternativas.
En el caso de la programación lineal éstas son generadas automáticamente por el modelo, lo cual
puede ser un muy largo proceso que involucra la búsqueda y creatividad, lo cual toma tiempo y costo.
La generación de alternativas depende de la disponibilidad y el costo de la información. Cuando la
creatividad se usa para la generación de alternativas, pueden utilizarse técnicas como torbellino de
7/69
ideas, sesiones dinámicas de grupo, etc.
Esta alternativa puede ser automatizada y para ello se utilizan los SSD.
5. Predecir las salidas de cada alternativa

Para evaluar y comparar las alternativas, es necesario predecir las salidas de cada una de ellas, en
función del grado de conocimiento de las variables no controlables. Existen tres categorías:
• Ciertas: Cuando se conoce el estado que habrán de asumir las variables no controlables;
es decir que sólo se puede obtener un resultado único y conocido para cada alternativa. Se
parte de la premisa que se basa en que para la elección, se están considerando todas las
opciones posibles y algún criterio valorativo para medirlas. El futuro es considerado
determinista. Ocurre en problemas programados.
• Riesgosas: Se deben considerar muchas posibles salidas (opciones) para cada una de las
alternativas. Ello significa que cada una se asocia a más de un resultado posible con su
respectiva probabilidad, la cual surge de la observación del comportamiento previo del
contexto en el que tendrá lugar la decisión, o de un contexto análogo que sea
representativo. Bajo esta suposición, la decisión tomada puede determinar la disminución
del riesgo asumido. El análisis de riesgo es usualmente ejecutado por computadora,
determinando valores para cada alternativa y seleccionando la alternativa que mejor valor
posea.
• Inciertas: Se trata de aquellas que se producen cuando no se cuenta con información para
hacer una estimación del comportamiento. Estas decisiones admiten más de un resultado
posible y tienen probabilidades desconocidas. En contraste con una situación riesgosa, la
decisión tomada no es conocida y no se puede estimar la probabilidad de ocurrencia de las
posibles salidas. En condiciones inciertas, es dificultosa la evaluación por la insuficiencia de
información.
6. Medición de las salidas.

El valor de cada una de las alternativas es definida en términos de obtención de los objetivos. Algunas
veces las salidas son expresadas directamente en términos de objetivos.
Por ejemplo: las ganancias son salidas, considerando que la maximización de las ganancias es un
objetivo y ambos son expresados en términos de dinero. En otros casos las salidas pueden ser
expresadas en otros términos, como por ejemplo: horas hombre, horas máquinas, etc.
7. Escenario.
Consiste en una descripción narrativa del contexto en el cual será analizada la situación de decisión.
Un escenario describe la decisión y las variables incontrolables o parámetros para una situación
específica. Un escenario es especialmente útil en simulaciones y análisis “what-if”. En ambos casos
nosotros vamos cambiando los escenarios.
Se pueden plantear al menos tres escenarios: El “Peor Posible”, El “Mejor Posible”, El “Más Probable”.
3. Fase de elección
Esta fase del proceso de toma de decisiones involucra la búsqueda, evaluación y recomendación de una
solución apropiada al modelo. La solución del modelo no implica la solución del problema, ésta debe también
ser implementada con éxito. El proceso de búsqueda se puede sintetizar en el siguiente cuadro:
8/69
La evaluación es el paso anterior a la recomendación de una solución. Varios elementos son importantes en la
evaluación de la solución provista por un SSD.
• Múltiples objetivos: Se debe evaluar cuánto cumple la alternativa seleccionada respecto a los
objetivos propuestos (problema a solucionar). Generalmente se deben alcanzar en forma
simultánea múltiples metas, que a veces se contraponen.
• Análisis sensitivo: Es de ayuda cuando el administrador no se encuentra seguro de la exactitud y la
importancia de la información, o cuando quiere conocer cómo impacta el cambio en la información
de entrada al modelo con los mismos resultados, o medir la performance. Existen dos tipos de
análisis sensitivos:
◦ Análisis sensitivo automático: son aquellos modelos cuantitativos estándares, como el de
programación lineal. Son generalmente limitados a un cambio a la vez y sólo de ciertas
variables.
◦ Prueba/Error: se realizan cambios en los datos de entrada y se resuelve el modelo. Se
efectúa en forma repetitiva, hasta encontrar la mejor alternativa.
Esta experimentación puede realizarse de dos formas:
▪ Análisis “what-if”: qué pasará con la solución si varía el dato de entrada o el valor de un
parámetro es cambiado.
Ej.: ¿Qué sucede con el costo total del inventario si el costo de transporte se incrementa
en un 10%?
▪ Búsqueda de objetivo: determina las entradas necesarias para un nivel deseado de
salida.
Ej.: ¿Cuántos programadores son necesarios para terminar el proyecto el próximo mes?
4. Fase de Implementación
Consiste en colocar la solución recomendada a trabajar.
El Sistema de Soporte de Decisiones
9/69
Una vez analizado el proceso de la toma de decisiones, comenzamos en particular a analizar los sistemas de
soporte de decisiones. Podemos esquematizar un SSD, en función de sus componentes y la relación con los
usuarios, de la siguiente manera:
Componentes
de un SSD
1. Administrador de datos: este administrador es el que contiene la base de datos decisional y el
DBMS (sistema administrador de la base de datos). Está compuesto por los siguientes elementos:
◦ Base de datos decisional
◦ DBMS (el sistema administrador de la base de datos).
◦ El directorio de datos (metadatos)
◦ El facilitador de la consulta.
El administrador de datos interrelaciona datos de diferentes fuentes (internas y externas), extrae
datos para colocarlos en la base de datos decisional, y actualiza estos datos. Además, recupera
rápidamente datos almacenados (debido a su estructura), proporciona información de su contenido
y fuentes de extracción, y provee seguridad.
2. Administrador de modelos: contiene el conjunto de modelos cuantitativos y cualitativos y el
software apropiado para su administración. Está compuesto por los siguientes elementos:
• Base de modelos.
• MBMS (Model Base Management System).
• Lenguaje de modelado.
• Directorio de modelos.
• Procesador de comandos.
El administrador de modelos tiene la capacidad de crear rápida y fácilmente modelos, y los
almacena de manera lógica e integrada. También vincula los modelos con los datos, y permite que
los usuarios los manipulen con facilidad. Proporciona metadatos: información del contenido de
modelos y su función .
3. Administrador de diálogo: es el que provee la interfaz con el usuario final.
Está compuesto por el software y hardware que proveen la interfaz del usuario con el SSD. Es uno
de los componentes más importantes, ya que una interfaz inconveniente puede producir que los
directivos dejen de utilizar el SSD. Debe contener los siguientes elementos:
• Lenguaje de creación (Input).
• Lenguaje de visualización (Output).
• PProcesador de lenguaje natural.
• DGMS (Dialog Generation and Management System).
10/69
El administrador de diálogo posee diferentes estilos de diálogo, para usuarios diferentes, y les
provee capacidades de ayuda en linea.
Es flexible: presenta los datos en varios formatos y posibilita un amplio rango de dispositivos de
entrada/salida; además provee capacidades gráficas y casos-tipo de ejemplos. Se encarga de
interactuar con el administrador de datos y el de modelos.
4. Administrador de conocimiento: es utilizado en el caso de los sistemas expertos, no lo analizaremos.
11/69
Módulo 2: Modelado multidimensional
Unidad 3: Modelado multidimensional

Para realizar el diseño de un almacén de datos (data warehouse), es decir el diseño de la base de datos, nos
valemos de un modelo.
Un modelo es una abstracción o representación formal de una aspecto del mundo real. En este caso, de algún
aspecto o proceso del negocio que se intenta especificar.
También decimos que un modelo es una forma de explicitar gráfica y sencillamente un problema, la solución al
problema o un proceso, de manera de facilitar su entendimiento. , es un componente de la documentación de
todo sistema.
El modelo define los componentes y las interrelaciones de una solución. El tipo de análisis que se requiera
hacer sobre un Data Warehouse va a determinar el tipo de modelo que se deberá realizar y el contenido del
modelo.
Modelado de datos
Conocer qué es un modelo es importante para comenzar a trabajar , particularmente sobre aquellos modelos
que nos permiten modelar estructuras de datos.
El modelado de datos es un proceso que tiene por entradas la especificación de la información que un sistema
debe manejar y como salida la estructura que almacenará la información de la manera más eficiente de
acuerdo a la naturaleza del problema que debe resolver.
Técnicas de modelado
Las técnicas más utilizadas actualmente para modelar estructuras de datos son el modelo Entidad-Relación y
el modelo multidimensional. Cada uno tiene sus ventajas y sus desventajas y son utilizados principalmente
para entornos operativos diferentes, si bien en la realidad se complementan.
• Modelo Entidad – Relación
Es el tipo de modelado de datos para aplicación por excelencia. Nos permite representar el mundo real
a través de la identificación de objetos denominados Entidades y Relaciones, que como su nombre lo
indica son las relaciones entre ellos.
Además de las entidades y relaciones, sus componentes son: restricciones de Integridad, atributos y
dominios, Supertipos y Subtipos, y normalización.
• Modelado multidimensional
El Modelo de datos Multidimensional es un nuevo modelo de datos que sirve de base tecnológica para
aplicaciones de tipo de Procesamiento analítico en línea (OLTP).
Modelado Multidimensonal
Debido a su orientación analítica, la cual se sustenta por un modelamiento de base de datos propio, el
modelado multidimensional impone un procesamiento y un pensamiento distinto, que busca ofrecer al usuario
su visión respecto de la operación del negocio.
El Modelado Dimensional es una técnica para modelar bases de datos simples y entendibles al usuario final. La
idea fundamental es que el usuario visualice fácilmente la relación que existe entre los distintos componentes
del modelo.
Consideremos un punto en el espacio. El espacio se define a través de sus ejes coordenados (por ejemplo
X,Y,Z). Un punto cualquiera de este espacio quedará determinado por la intersección de tres valores
particulares de sus ejes.
Por ejemplo: Digamos que el eje X representa Productos, el eje Y representa el Mercado y, el eje Z
corresponde al Tiempo. Se podría tener la siguiente combinación:
producto = madera, mercado = Córdoba, tiempo = diciembre-2003.
La intersección de estos valores nos definirá un solo punto en nuestro espacio. Si el punto que buscamos, lo
definimos como la cantidad de madera vendida, entonces se tendrá un valor específico y único para tal
combinación.
12/69
Figura: Cubo dimensional para la combinación de

producto, mercado y tiempo.
En el modelo multidimensional cada eje corresponde a

una dimensión particular. Entonces la dimensionalidad de nuestra base estará dada por la cantidad de ejes (o
dimensiones) que le asociemos.
Cuando una base puede ser visualizada como un cubo de tres o más dimensiones, es más fácil para el usuario
organizar la información e imaginarse en ella cortando y rebanando el cubo a través de cada una de sus
dimensiones, para buscar la información deseada.
Al responder a este tipo de consultas, las bases de datos multidimensionales que soportan OLTP transforman
los datos corporativos en inteligencia empresarial (BI), una nueva área de conocimiento que se ha desarrollado
a partir de los tradicionales sistemas de información ejecutivos (EIS) y de sistemas de soporte de decisiones
(DSS). Los sistemas de BI dan a los usuarios acceso a diversas fuentes de datos, permitiéndoles también a
través del descubrimiento, entender las tendencias que conforman los datos. Apoyados en este entendimiento,
los profesionales pueden resolver problemas de negocio y capitalizar sus fortalezas.
Los productos multidimensionales han heredado su nombre de la naturaleza multidimensional de la mayoría de
las consultas de negocios. Por ejemplo, en un departamento de finanzas de una empresas no se preguntan
¿Cuanto hemos gastado? La pregunta es ¿Cuanto hemos gastado en beneficio de la salud, mensualmente, en
la división X, en cada región, comparado con lo presupuestado?, y esta es una consulta que involucra cinco
dimensiones.
Por otra parte, el modelado multidimensional es bastante simple, representa un conjunto de requerimientos de
datos de una manera simple, concisa y entendible. Y la información se presenta en términos familiares. Los
datos se almacenan de modo que resulten independientes de los programas que lo usan, empleándose
métodos bien determinados para incluir datos nuevos y para modificar o extraer los datos almacenados.
Las bases multidimensionales son una herramienta usada en relación de un data warehouse. Estructuralmente
es igual a una base de datos relacional, ya que se compone de un conjunto de tablas, pero la diferencia está en
que la base de datos multidimensional forma agregaciones o resúmenes, a partir de las consultas típicas de los
usuarios.
Las bases de datos relacionales, que utilizan Lenguaje de consulta Estructurado (SQL) como un estándar para
organizar, administrar, actualizar y acceder datos, sirven de plataforma a aplicaciones de tipo OLTP
(Procesamiento Transaccional en Línea), pero hoy en día, la base de datos multidimensional está completando
las relacionales para dar una mayor utilidad a sus datos, y servir de base a tecnologías para aplicaciones del
tipo de procesamiento Analítico en Línea (OLAP).
Un modelo multidimensional puede ser implementado en una base de datos relacional, multidimensional,
orientada a objetos u otra, siendo lo más consecuente almacenarlo en una base de datos multidimensional.
Componentes del modelo multidimensional

Los Componentes básicos del modelado multidimensional son los Hechos, las Dimensiones, los Elementos,
Atributos, Miembros, Tabla de Hechos, Tabla de Dimensión y Esquemas.
1. Hechos :
Los hechos son atributos numéricos que representan la performance, el comportamiento o la
13/69
tendencia del negocio con respecto a una o más dimensiones. Representan el criterio de evaluación
de algún aspecto del negocio, son datos cuantificadores acerca de un tema particular.
Son los elementos sobre los cuales quiero realizar el control, por ejemplo la cantidad, importe
vendido, las horas trabajadas, etc. , indican cómo se está llevando a cabo una operación.
Los Hechos se almacenan en la tabla de hechos.
2. Dimensiones
Las dimensiones son clases descriptoras de los hechos, son los puntos de vista a través de los
cuales se desean analizar los hechos.
Las dimensiones organizan la información de manera que se pueda preguntar qué, cuándo, dónde...
representan una colección de miembros o unidades del mismo tipo.
Son calificadores de hechos, los ponen en perspectiva.
Por ejemplo, si el hecho es una venta, las dimensiones podrían ser tiempo, geografía, clientes, y/o
productos.
Las dimensiones son almacenadas en tablas junto con los elementos y atributos de dimensión .
3. Elementos
Los Elementos son agrupaciones lógicas de atributos o propiedades de una clase de objeto del
negocio.
Son los componentes conceptuales de una dimensión y están jerárquicamente organizados para
que el usuario final pueda navegar por distintos niveles de detalle de la información.
Por ejemplo: si tomamos la dimensión del “Tiempo”, los elementos podrían ser año, semestre,
bimestre, mes, semana, día.
4. Atributos
Los atributos son los que proporcionan descripciones y otra información relacionada a cada
elemento de dimensión, por lo que un mismo elemento puede contener múltiples atributos.
Facilitan la tarea a los usuarios finales para formular consultas usando términos del negocio que le
son familiares, por ejemplo el nombre, dirección, etc.
5. Miembros
Los miembros representan las instancias reales de una dimensión. Una dimensión comprende dos o
más miembros por ejemplo, Juan Pérez, General Paz 350.
Ejemplo: Proceso de Negocio: datos completos de las ventas al por menor.

Hechos: Precio de venta, Unidades de venta, Unidades de envío, etc.
Dimensiones: Clientes, Productos, Tiempo.
Atributos: Cliente: Código del cliente.
Nombre.
Apellido.
Dirección.
Teléfono, etc.
Ejemplo: Elementos
Ejemplo: Elementos
14/69
Ejemplo: Miembro
América. Argentina. Córdoba. Capital. Cap. Córdoba Capital. 5000.
6. Tabla de Hechos o Fact Table

La tabla de hechos es la tabla central en un esquema dimensional; se trata de una colección de
datos relacionados consistente en medidas y datos de contexto. Representa un ítem de negocio, un
evento o una transacción.
Contienen una lista de todas las medidas y todas las claves del nivel más bajo de la jerarquía de
cada dimensión.
La granularidad de la tabla de hechos está determinada por el nivel más bajo de cada tabla de
dimensión y contiene un registro por cada combinación de claves de las dimensiones.
7. Tabla de Dimensión o look-up table

Las tablas dimensionales son las que se conectan a la tabla de hechos, son las que alimentan a la
tabla de hechos.
Las tablas de dimensión están compuestas de elementos y atributos para cada nivel de la jerarquía.
El nivel más bajo de la jerarquía está determinado por el nivel más bajo de detalle requerido para el
análisis; y los niveles más altos son la base de la jerarquía y almacenan datos redundantes. Esta
denormalización reduce el número de relaciones necesarias en una consulta.
La tabla de dimensión tiene una primary key que identifica unívocamente una fila en la tabla junto
con un conjunto de atributos, y dependiendo del diseño del modelo multidimensional puede existir
una foreign key que determina su relación con otra tabla de dimensión.
La característica principal de estas tablas es la DENORMALIZACION.
8. Esquemas
La colección de tablas en el modelo multidimensional se conoce como esquema, los esquemas
caen dentro de estas categorías:
1. Estrella (Star Schema).
En general, el modelo multidimensional también se conoce con el nombre de esquema estrella,
pues su estructura base es similar: una tabla central y un conjunto de tablas que la atienden
radialmente.
El esquema estrella deriva su nombre del hecho que su diagrama forma una estrella, con
puntos radiales desde el centro. El centro de la estrella consiste de una o más tablas fact, y las
puntas de la estrella son las tablas look_up.
Este modelo entonces, resulta ser asimétrico, pues hay una tabla dominante en el centro con
varias conexiones a las otras tablas. Las tablas look-up tienen sólo la conexión a la tabla fact y
ninguna más. Las características del modelo estrella son:
15/69
◦ La tabla de hechos tiene datos detallados y resumidos.
◦ La tabla de hechos solo tiene una columna clave por dimensión y cada clave es generada.
◦ Cada dimensión es una simple tabla altamente desnormalizada.
2. Esquema Copo de Nieve (Snowflake Schema).

La diferencia del esquema estrella con el copo de nieve está en la estructura de las tablas de
dimensiones: en el Copo de Nieve, las tablas de dimensiones están normalizadas. Cada tabla de
dimensión contiene solo el nivel que es clave primaria en la tabla y la clave foránea de su
parentesco del nivel más cercano del diagrama.
Características del esquema Copo de Nieve
◦ Las tablas de dimensión son normalizadas por la descomposición en el nivel de atributo.
◦ Cada tabla de dimensión tiene una única clave para cada nivel de la jerarquía de la
dimensión.
◦ La clave del nivel más bajo une la tabla de dimensión con la tabla de hechos y la tabla de
atributo de bajo nivel.
◦ Hay un mejor desempeño cuando las consultas involucran agregaciones.
16/69
3. Mixto (Mixed Schema).

Es una combinación de Star Schema con Snowflake Schema, en el que algunas dimensiones
están seminormalizadas y otras totalmente denormalizadas
4. Constelación (Constellation o MultiStar).

Consiste en la representación de varios modelos estrella y/o copo de nieve en un solo modelo y
relacionados entre sí por la o las dimensiones que poseen en común.
Actúan entre sí como agregaciones.
Diseño de una base de datos multidimensional

Se analizarán los pasos que nos permitan diseñar una base de datos multidimensional, trabajando a partir de
un ejemplo de negocios.
Para diseñar la base multidimensional se parte de los datos relacionados con la empresa u organización y la
base de datos de tipo transaccional, es decir aquella donde la empresa va registrando todas las transacciones
que ocurren.
El gerente de finanzas de una empresa multinacional que se dedica a la venta de materiales de
construcción recurrió a su departamento de sistemas para solicitar el desarrollo de un sistema de
información que le permitiera controlar los movimientos de la empresa.
Analizando detalladamente los requerimientos, se obtuvieron los siguientes datos relevantes:
a.- Se debe poder conocer la cantidad de facturas cobradas por mes y por provincia.
b.- El importe cobrado por cada sucursal, vendedor y mes.
c.- Cantidad de recibos por cliente
La mencionada empresa cuenta actualmente con un sistema de información de tipo transaccional,
que registra la información en la base de datos operacional
Comenzamos haciendo una lectura detallada de la organización, de los requerimientos y de la base de datos
transaccional. Luego, vamos a identificar los componentes del modelo multidimensional, ya que una vez que
contemos con esta información, nos será fácil el armado de la base.
1. Identificar los hechos.

Debe tenerse en cuenta los requerimientos del sistema.
En nuestro caso en particular son los requerimientos de información del gerente de finanzas. Leyendo
nuevamente los requerimientos, podemos ver que los hechos son:
· Cantidad de facturas,
· Importe cobrado,
· Cantidad de recibos.
2. Analizar las dimensiones, elementos y jerarquías que las conforman

Para analizar las dimensiones, hay que tener presente que éstas son las perspectivas de análisis de
los indicadores del negocio.
Leyendo nuevamente los requerimientos, percibimos que se desprende el mes de la venta, la
provincia, sucursal, vendedor que realizó la venta, y el cliente que hizo la compra. Entonces,
podemos armar las siguientes dimensiones:
• Una que llamaremos tiempo, cuyos elementos forman la siguiente jerarquía: día, mes,
año.
• Otra que podríamos llamar zona geográfica, integrada por jerarquía provincia, sucursal
(para armar las jerarquías tenemos en cuenta la estructura de la empresa; en nuestro
caso lo visualizamos en el modelo de datos operacional )
• Una tercera dimensión será denominada vendedor. Podemos observar que esta
dimensión no contiene elementos que puedan formar una jerarquía, sino que solamente
está integrada por los atributos del vendedor.
• Y la última será llamada cliente. Esta dimensión no contiene elementos, sino solamente
los atributos del cliente.
17/69
3. Identificar los atributos
En este paso hay que pensar qué atributos corresponden a cada uno de los elementos.
En la tabla siguiente se listan los atributos de nuestro ejemplo. Note que los de la Dimensión
tiempo son generales, y siempre estarán en una BD multidimensional.
Dimensión Elemento Atributos

Tiempo Día dia
descripción del día
Mes mes
descripción del mes
Año año
Zona Geográfica Provincia Id_provincia
Descripción de la provincia
Sucursal Id_sucursal
Id_provincia (a la que pertenece la sucursal)
Descripción de la sucursal
Vendedor (no tiene) Id_vendedor
Nombre
Cliente (no tiene) Id_cliente
Nombre
Nota: podrían agregarse otros atributos; para ello tenemos en cuenta qué información
necesitará el usuario del SSD. Por ejemplo: podría ser la dirección, sexo, edad, estado civil
del cliente, etc.
4. Graficar la base de datos multidimensional
Una vez cumplidos los pasos anteriores, estamos en condiciones de graficar la base de datos
multidimensional.
En nuestro ejemplo, graficaremos la base con un star schema. Con respecto al modelo
podríamos observar que teniendo en cuenta la granularidad con que hemos almacenado los
datos en la tabla de hechos, la cantidad de facturas es 1 y la cantidad de recibos también es
1. Por lo tanto, esos dos hechos pueden ser eliminados de la tabla de hechos. Esa
información se puede obtener haciendo una consulta sobre la tabla de hechos. El único
hecho que quedaría es el importe cobrado.
Conceptos
avanzados de modelado multidimensional
1. Tabla de hechos que representan eventos
18/69
Algunos de los procesos de negocio que queremos modelar usando un data warehouse están relacionados con
eventos que han ocurrido. Ciertos ejemplos son servicios de investigación, procedimientos para pacientes de
un hospital y reporte de accidentes.
Por ejemplo, en el modelo de datos de
atención de un colegio, las dimensiones
podrían ser, por supuesto, profesor,
estudiante, instalación y tiempo.
La tabla de hechos consistiría en claves
foráneas que unen a todas las tablas de
dimensión para el evento de
concurrencia de cada estudiante a una
determinada clase.
2. Medidas aditivas, semiaditivas y no

aditivas
Muchas consultas involucran a operadores matemáticos, financieros, etc., como un SUM, COUNT, etc., de un
grupo de medidas.
• Medidas aditivas
Idealmente, las medidas deberían ser aditivas a través de todas las dimensiones.
Ejemplo: RENTAS es aditiva a través de Producto, Tiempo o Locación.
• Medidas semi-aditivas
Algunas medidas son aditivas a través de algunas, pero no de todas las dimensiones.
Ejemplo: INVENTARIO no es aditivo a través del tiempo.
Las medidas que no son aditivas a través de una dimensión, pueden ser difíciles de recuperar
correctamente. Inventario, por ejemplo, puede ser totalizado a través del tiempo calculando el
promedio de inventario por el número de períodos de tiempo. Las sentencias SQL pueden llegar
a ser más complejas desde que el promedio de inventario para el periodo de tiempo apropiado
tendría que ser calculado separadamente de otros totales.
• Medidas no aditivas
Algunas medidas son no aditivas del todo.
El porcentaje de descuento es no aditivo a través de ninguna dimensión. El margen total es un
índice. Si el porcentaje de descuento representa un cálculo, la solución debe ser recalcular la
medida usando los totales apropiados.
3. Dimensiones sucias y degeneradas y mini-dimensión
• Una dimensión sucia contiene muchas entradas extrañas y duplicadas. Esto es frecuentemente un
problema en los servicios financieros donde un cliente puede manejar múltiples cuentas, y el nombre y
la dirección de cada cuenta pueden ser diferentes.
Este problema también es encontrado cuando se trata de crear una dimensión de parentesco donde
muchos individuos pertenecen a la misma familia. No sería posible, usando los datos disponibles,
eliminar completamente las duplicaciones en cada situación. Los analistas de negocios pueden ser
advertidos del grado en el cual una dimensión en particular es sucia.
• Una dimensión degenerada tiene una dimensión clave que no se corresponde con una tabla de
dimensión.
Mientras que algunos ítems que se desea almacenar no son métricas, tampoco forman parte de una
dimensión jerárquica con otros elementos. Si se desea almacenar un número de orden de compra, por
ejemplo, no puede ser guardado como una métrica en la tabla base, pero no se quiere tampoco crear
una tabla de dimensión que consista sólo en números de órdenes de compra. La solución es
almacenarlo en la tabla base como si fuera una clave de dimensión. Por esto se dice que es una
dimensión degenerada.
• Una mini-dimensión es un grupo pequeño de atributos que han sido “explotados” de una gran tabla de
dimensión.
19/69
La tabla de dimensión como la tabla cliente o producto puede tener 50 ó 100 atributos y muchos
millones de filas. Los campos que raramente serán usados como restricción en una consulta, o campos
que son frecuentemente comparados simultáneamente, pueden ser separados en una tabla de mini-
dimensión diferente.
En una mini-dimensión como la
del ejemplo, la clave demográfica
puede ser almacenada como una
clave foránea en la tabla y en el
cliente.
• Esto permite a la min-idimensión
demográfica componerse de la
tabla base directamente. La clave
demográfica también puede ser
usada directamente con la tabla
cliente para examinar los atributos
demográfico
4. Cambios en dimensiones y
soluciones de tipo I, II y III
La mayoría de las dimensiones son casi constantes en el tiempo, desde que pueden ocurrir cambios en las
ventas por distritos o regiones, o en nombres y direcciones. Para realizar una comparación histórica, estos
cambios deben ser administrados. Las soluciones pueden ser del tipo I, II o III.
• Solución Tipo I: Cambio en el valor almacenado en una columna de una dimensión.
En el ejemplo de arriba, el registro para Joe Smith en la dimensión cliente podría ser actualizado
para mostrar la dirección nueva en Park Ridge. Todas las historias de ventas a Joe anteriores
estarán ahora asociadas con el barrio Park Ridge en lugar de Des Planes.
• Solución Tipo II: Crear un segundo registro de dimensión con el nuevo valor y una clave
generalizada. Esto efectivamente particiona la historia.
Joe tendría ahora 2 registros en la tabla de dimensión cliente. El viejo registro con la clave 101
permanece, y habría registros en la tabla asociados con él. Un nuevo registro sería agregado a
la tabla de dimensión cliente para Joe, con una nueva clave que consista de la vieja más alguna
versión de dígitos (101.01 por ejemplo). Todos los registros subsecuentes agregados a la tabla
base para Joe serían asociados con esta nueva clave.
• Solución Tipo III: Consiste en agregar un nuevo campo en la tabla de dimensión para el atributo
afectado y renombrar el viejo atributo. Este tipo es raramente usado, a menos que haya una real
necesidad de rastrear la vieja historia en términos del nuevo valor y viceversa.
Joe tendría un nuevo atributo denominado dirección actual, y el atributo viejo sería renombrado
dirección original.
5. Periodos de tiempo continuos
El rastreo de períodos de tiempo continuos puede ser un requerimiento de negocio importante. Una solución es
crear una dimensión de tiempo continua aparte.
Por ejemplo: Un día dado, actualmente pertenecería a períodos de 3 meses y a períodos de 6 meses. El
1o de Junio pertenecería a Abril -Mayo-Junio, Mayo- Junio-Julio y Junio-Julio-Agosto. Habría 3 registros
para el 1o de Junio. Una columna llamada período continuo contaría con valores indicando que Junio 1
perteneció a estos 3 períodos.
Las consultas que involucran un período de tiempo continuo se agrupan en una tabla de dimensión especial en
lugar de una tabla de dimensión estándar. Debido a que la relación muchos a muchos existe entre la tabla base
y la tabla de dimensión especial, es importante que esta última se use sólo con un filtro sobre el período de
tiempo para eliminar las duplicaciones que resultarían.
SELECT Nombre_Cliente, DiaOrden, Renta
FROM cliente, tiempo, ventas
WHERE cliente.CodigoCliente=ventas.CodigoCliente
AND tiempo.CodigoTiempo=ventas.CodigoTiempo
AND tiempo.PeriodoTiempo=”Junio-Julio-Agosto “
Técnicas/Herramientas para mejorar la performance
20/69
1. Tablas de agregación: la creación de tablas adicionales que pre-calculan y sumarizan los datos
para consultas críticas.
2. Fragmentación de tablas por sistema o aplicación: para permitir el paralelismo y extender E/S a
través de los discos.
3. Indexación: agregación de índices. (Este punto no será desarrollado)
1. Tablas de agregación
El tiempo requerido para acceder a grandes cantidades de filas y sumarizar los datos puede ser reducido
mediante la creación de tablas adicionales que pre- calculan los totales deseados.
La realización de operaciones de consulta con una tabla de totales en lugar de una tabla de datos muy grande
hace que los resultados estén disponibles más rápidamente.
Por ejemplo, una tabla de totales podría ser creada para ventas por marca y por mes. Si la tabla
base que contiene una fila por producto por día tiene un millón de filas, la tabla de totales
conteniendo una fila por marca debería tener sólo unas pocas miles.
Pautas para tablas agregadas
Construir totales para áreas del modelo de difícil uso.
Construir totales para sumarizar muchos datos.
Construir totales que respondan a una amplia gama de preguntas.
Debido a los costos involucrados, los totales deben ser construidos sólo para la mayor parte de temas
comunes. Auditando el uso para identificar las consultas críticas, las cuales proveerán de candidatos para los
totales. Una vez que un candidato para la agregación es identificado, la densidad de datos estaría determinada
por cuán extensivamente poblado es el nivel de dimensión.
Si la mayoría de los productos tiene sólo unas pocas ventas en cada sucursal por semana, por
ejemplo, no habría una reducción significativa del número de filas procesadas si se creara un total
por producto por sucursal por semana.
Una regla sugerida es crear totales que sumaricen
al menos 10, y preferentemente 20 o más ítems de
nivel más bajo. Los totales más sumarizados
ofrecen la mejor performance, pero como
desventaja, las tablas altamente sumarizadas
frecuentemente contestan un rango limitado de
preguntas.
El equilibrio en la performance se contrapone con
la flexibilidad por selección del menor nivel de
agregación que almacenaría sustancialmente
menos filas que su predecesor.
Beneficios en el uso de tablas agregadas
• Mejor performance en consultas: la recuperación de datos directamente de las tablas de totales
es sustancialmente más rápida que la sumarización de los datos luego de obtenerlos.
• Menores requerimientos de recursos del sistema: con la eliminación de la necesidad de realizar
sumarizaciones intensivas con la memoria RAM, los recursos están libres para otras tareas.
Inconvenientes de las tablas agregadas

• Mayor mantenimiento: el número de tablas que deben mantenerse se incrementa.
• Llamadas a datos: cada vez que una nueva base de datos es cargada en memoria, los totales
deben rehacerse.
• Incremento de la complejidad del modelo: los usuarios finales deben comprender cuándo
consultar la tabla base completa y cuándo consultar una tabla de totales.
2. Tablas fragmentadas
La performance de las consultas puede ser mejorada si las filas de una tabla individual son distribuidas
(fragmentadas). Ubicar los fragmentos en diferentes discos puede reducir la contención para los discos sobre
los cuales residen los datos.
21/69
La fragmentación de tablas puede ser ventajosa para máquinas con capacidad de multiprocesamiento para
permitir composiciones paralelas (joins), búsquedas, group by, y clases cuando se realizan consultas.
La performance en la carga de datos puede ser mejorada significativamente a través de la carga en paralelo.
Ejemplo:
Uno de los requerimientos del depósito (warehouse) es almacenar los datos en base a la
registración de un período de 24 meses. La mayoría de los meses recientes son más consultados.
Además, los datos del mes actual serán más utilizados.
El warehouse fue fragmentado por tiempo (los meses anteriores en un fragmento y los meses más
recientes divididos a través de 4 fragmentos). Esto permite búsquedas paralelas para consultas
que direccionan sólo uno de los meses más recientes. Al final de cada mes, pueden agregarse los
fragmentos del mes más nuevo, y los fragmentos de meses más anteriores pueden omitirse o
removerse.
Esquemas de fragmentación
La performance de una tabla fragmentada está determinada primero por la estrategia de fragmentación que es
usada para localizar espacio en disco para los fragmentos, y por el esquema de distribución que se usa para la
asignación de filas a los fragmentos individuales.
El servidor dinámico soporta los siguientes esquemas de distribución:
• Round robin: las filas son ubicadas aleatoriamente en fragmentos, para que la distribución entre
los fragmentos sea equitativa. Este esquema puede incrementar la performance de cargas de
gran volumen y búsquedas paralelas de una tabla entera.
Ejemplo:
CREATE TABLE orders (.....)
FRAGMENT BY ROUND ROBIN;
• Basado en expresión: las filas que cuentan con valores similares son ubicadas en el mismo
fragmento. Esto puede ser utilizado para distribuir lógicamente los datos, basados en patrones
de acceso de sus aplicaciones. El servidor de base de datos puede también eliminar fragmentos
que no se necesitan del plan de consulta, lo cual resulta en un mejor desempeño.
Ejemplo:
CREATE TABLE orders (.....)
FRAGMENT BY EXPRESSION
Order_num <1000 in dbspace1,
Order_num <2000 in dbspace2,
Order_num >=2000 in dbspace3;
Unidad 4: Administración
Administración y Actualización
Habiendo analizado cuáles son los componentes de un sistema de soporte de decisión y los conceptos de
modelado multidimensional, es hora de ver los conceptos asociados a la actualización y mantenimiento de
datos del data warehouse.
1. Operaciones en un Data Warehouse

Las operaciones que se efectúan dentro de un ambiente de data warehousing, son Extraer, Transformar, y
22/69
Cargar (ETL: Extract, Transform, Load en inglés).
Analizando el
ambiente de un Data Warehouse, como está graficado, como soporte, origen y destino de esas operaciones,
encontramos diferentes elementos.
a) Sistemas Operacionales
Los datos administrados por los sistemas de aplicación operacionales son la fuente principal de datos
para el data warehouse. Las bases de datos operacionales se organizan como archivos indexados,
bases de datos de redes/jerárquicas o sistemas de base de datos relacionales (DB2, Oracle, Informix,
etc.).
b) Extracción, Transformación y Carga de los Datos
Se requieren herramientas de gestión de datos para extraer datos desde bases de datos y/o archivos
operacionales, luego es necesario manipular o transformar los datos antes de cargar los resultados en el
data warehouse.
Tomar los datos desde varias bases de datos operacionales y transformarlos en datos requeridos para el
warehouse, se refiere a la transformación o a la integración de datos. Las bases de datos operacionales,
diseñadas para el soporte de varias aplicaciones de producción, frecuentemente difieren en el formato
del DW, por lo cual los datos que contienen deben ser manipulados.
Además, los mismos elementos de datos, si son usados por aplicaciones diferentes o administrados por
diferentes software DBMS, pueden definirse al usar nombres de elementos inconsistentes, que tienen
formatos inconsistentes y/o ser codificados de manera diferente. Todas estas inconsistencias deben
resolverse antes que los elementos de datos sean almacenados en el data warehouse.
c) Metadatos
Otro paso necesario es crear los metadatos (es decir, datos acerca de datos), los que describen los
contenidos del data warehouse. Los metadatos son definiciones de los elementos de datos fuente
(warehouse). Como los datos, se integran y transforman antes de ser almacenados en información
similar.
d) Acceso de usuario final
Los usuarios accesan al data warehouse por medio de herramientas de productividad basadas en GUI
(Graphical User Interface - Interfase gráfica de usuario). Puede proveerse a los usuarios del data
warehouse varias de estas herramientas, como software de consultas, generadores de reportes,
procesamiento analítico en línea, herramientas data/visual mining, etc., dependiendo de los tipos de
usuarios y sus requerimientos particulares. Sin embargo, una sola herramienta no satisface todos los
requerimientos, por lo que es necesaria la integración de una serie de herramientas.
e) Plataforma del data warehouse
La plataforma para el data warehouse es casi siempre un servidor de base de datos relacional. Cuando
se manipulan volúmenes muy grandes de datos puede requerirse una configuración en bloque de
servidores UNIX con multiprocesamiento simétrico (SMP) o un servidor con procesamiento paralelo
masivo (MPP) especializado.
23/69
Las extracciones de datos se integran y transforman y se cargan en el data warehouse. La elección de la
plataforma es crítica. El warehouse crecerá y hay que comprender qué requerimientos existirán después
de 3 o 5 años.
f) Datos Externos
Dependiendo de la aplicación, el alcance del data warehouse puede extenderse por la capacidad de
acceder a los datos externos.
2. Evolución del Warehouse

Construir un data warehouse es una gran tarea. No es recomendable emprender el desarrollo del data
warehouse de la empresa como un proyecto cualquiera. Más bien, se recomienda que los requerimientos de
una serie de fases se desarrollen e implementen en modelos consecutivos que permitan un proceso de
implementación más gradual e iterativo.
No existe organización que haya triunfado en el desarrollo del data warehouse de la empresa en un sólo paso.
Muchas, sin embargo, lo han logrado luego de un desarrollo paso a paso.
Los datos que mantiene el data warehouse cambian en el tiempo; si bien en general es un repositorio de datos
no volátiles y de sólo lectura, pueden sin embargo añadirse nuevos elementos sobre una base estándar, para
que el contenido siga la evolución de los datos en la base de datos fuente, tanto en los contenidos como en el
tiempo.
Uno de los desafíos de mantener un data warehouse es idear métodos para identificar datos nuevos o
modificados en las bases de datos operacionales. Algunas maneras para identificar estos datos incluyen
insertar fecha/tiempo en los registros de base de datos y entonces crear copias de registros actualizados y
copiar información de los registros de transacción y/o base de datos diarias. Estos elementos de datos nuevos
y/o modificados son extraídos, integrados, transformados y agregados al data warehouse en pasos periódicos
programados.
Cuando se añaden las nuevas ocurrencias de datos, los datos antiguos son eliminados. Por ejemplo, si los
detalles de un sujeto particular se mantienen por 5 años, como se agregó la última semana, la semana anterior
es eliminada.
Transformación de Datos y Metadatos

Transformación de Datos
Uno de los desafíos de cualquier implementación de data warehouse, es el problema de transformar los datos.
La transformación se encarga de las inconsistencias en los formatos de datos y la codificación, que pueden
existir dentro de una base de datos única y que casi siempre existen cuando múltiples bases de datos
contribuyen al data warehouse.
En el siguiente ejemplo se ilustra una forma de inconsistencia, en la cual el género se codifica de manera
diferente en tres bases de datos diferentes. Los procesos de transformación de datos se desarrollan para
solucionar estas inconsistencias.
La transformación de datos también se encarga de las inconsistencias en el contenido de datos. Una vez que
se toma la decisión sobre que reglas de transformación serán establecidas, deben crearse e incluirse las
definiciones en las rutinas de modificación.
24/69
Es importante que, para transformar datos inconsistentes y cargarlos en el DW, se haga una planificación
cuidadosa y detallada, ya que además de la integración otra dificultad es la eficiencia de acceso a los sistemas
de datos existentes. Debe saberse qué archivos de sistemas existentes ya se recorrieron, y cuando, porque
intentar recorrerlos por completo cada vez que se actualiza el data warehouse es poco realista y muchas veces
costoso.
Existen 3 tipos de carga que pueden realizarse en un data warehouse desde el ambiente operacional:
• La carga de datos archivados
• La carga de datos actualmente existentes en el ambiente operacional
• La carga continua de actualizaciones al ambiente de data warehouse de los cambios que han ocurrido
en el ambiente operacional desde el último refresco del data warehouse.
Los dos primeros tipos de carga no representan una dificultad mayor, dado que por lo general se realizan por
única vez y solo requieren que el administrador del warehouse cronometre la conversión.
La mayor dificultad para el arquitecto de datos se encuentra en la carga de las actualizaciones continuas de los
datos desde el entorno operacional (resultado del procesamiento transaccional), que es un proceso que se
hace repetidamente y que puede consumir una gran cantidad de recursos.
Las técnicas más comunes para limitar la cantidad de datos recorridos de las aplicaciones existentes, son:
1. Time Stamped
La primera técnica es recorrer datos Time Stamped. Cuando una aplicación establece el tiempo en el
que se realizó el último cambio o actualización de un registro, el recorrido del data warehouse puede
ejecutarse más eficientemente, porque los datos con fecha no necesitan tocarse. Sin embargo
usualmente es circunstancial que los datos hayan sido “fechados”.
2. Delta File
La segunda técnica para limitar la cantidad de datos a recorrer para la extracción del data warehouse
es utilizar un “delta file” (archivo de diferencias).
Un delta file es aquel que se crea por una aplicación, y contiene solo los cambios efectuados. Cuando
existe un archivo de diferencias, el proceso de recorrido es muy eficiente ya que los datos que no son
candidatos para examinarse nunca se tocan. Tampoco existen muchas aplicaciones que guarden
“delta files”.
3. Log de Transacciones
La tercer técnica es aquella que examina y audita el archivo de log. El archivo de log o auditoría
contiene básicamente los mismos datos que un delta file. Las diferencias son las operaciones que
protege los archivos de log , porque son necesarios en el proceso de recuperación y no son propensos
a otra cosa que no sea su propósito original.
Otra diferencia/dificultad con los archivos de log es que su formato interno no ha sido creado para ser
utilizado por aplicaciones y se necesita un gurú en tecnología para realizar la interfaz de aplicación. Por
último, un archivo de log contiene mucha más información que la deseada por el desarrollador del data
warehouse.
4. Modificación de Aplicaciones
La cuarta técnica para examinar la gran cantidad de datos que requiere la extracción para actualizar el
data warehouse es modificar el código de la aplicación.
Generalmente el uso de esta técnica es resistido por la antigüedad del código existente y la fragilidad
del mismo.
5. Creación de Imágenes
La última opción es mantener imágenes anteriores y posteriores conjuntamente. Debe extraerse una
fotografía de la base de datos al momento de la extracción. Cuando se debe realizar otra extracción, se
toma otra fotografía. Cada fotografía se compara con la otra para determinar la actividad transcurrida.
Esta actividad es complicada y requiere gran cantidad de recursos
Estructura de datos en el data warehouse (periodicidad)

Básicamente, las estructuras más comunes que existen, son cuatro
1. Acumulativa simple
2. Rotación de datos sumarizados
3. Archivo directo simple
25/69
4. Archivo continuo
La estructura de datos más común y simple es la que encontramos en una estructura acumulativa simple, en
las que las transacciones diarias se transportan desde el ambiente operacional. Una vez transportadas, se
sumarizan en registros del data warehouse. Una sumarización puede ser por cliente, cuenta, o cualquier área
del negocio en la que el warehouse esté organizado. Las transacciones se sumarizan por día.
Por ejemplo: La actividad diaria de un cliente para una cuenta se totaliza y pasa al DW día por día.
Una variación de la acumulación diaria de datos es la rotación de datos sumarizados, hacer un "rollup" de los
datos, almacenando en detalle los más actuales y acumulando los antiguos.
Por ejemplo, en el caso de las ventas se podría tener una tabla para las ventas de cada día de la
semana y una vez que se termina la semana, acumular los datos de toda la semana en una tabla,
almacenando una para cada semana del mes y, una vez terminado el mes, agregar los datos en
una tabla para cada mes:
Los datos se pasan del ambiente operacional al del DW tal como el acumulativo simple. Solo que rotando los
datos sumarizados, los datos se introducen en una estructura muy diferente. Para los primeros siete días de la
semana, la actividad se sumariza en 7 slots diarios (uno por cada día). Al octavo día, los siete slots diarios se
suman y se colocan en el primer slot semanal. El total diario se agrega en el primer slot diario. Al final del mes,
los slots semanales se suman y se ubican en el primer slot mensual. Los slots semanales se resetean a cero.
Al final del año, los slots mensuales se suman y el primer slot de año se carga, luego los slots mensuales se
resetean a cero.
Otra posibilidad de estructurar los datos en el data warehouse es un archivo directo simple. Los datos se
llevan directamente desde el ambiente operacional al del DW. No hay ningún tipo de acumulación. El archivo
directo simple no se realiza en una base diaria, sino sobre un largo periodo de tiempo, como puede ser una
semana o un mes, y representa una fotografía de datos operacionales tomada en un instante del tiempo.
A partir de dos o más archivos directos simple, puede crearse un archivo continuo.
Por ej. Si tomamos dos fotografías con una base mensual –enero y febrero- se unen ambos para
crear un archivo continuo.
Los datos en un archivo continuo representan la continuidad de los datos desde el primer mes (en la base del
ejemplo) hasta el último.
Por último cabe agregar que a nivel de clave, las claves del data warehouse son compuestas inevitablemente
debido fundamentalmente a que la fecha –año, año-mes, año-mes-día, etc- forma parte de la clave, y a que los
datos del data warehouse están particionados, entonces los diferentes componente del particionamiento
también forman parte de la clave .
Proceso para efectuar un desarrollo para ETL.

Se presentan cinco fases, cada una de ellas incluye una ejecución secuencial de pasos que usan los
componentes de infraestructura del Sistema de Soporte de Decisión. Estos pasos y cargas de tablas destino
pueden ocurrir en paralelo con alguna planificación adicional del ciclo global del proceso ETL en lotes. Primero,
26/69
se ensambla cada paso por medio de un script o programa en un lenguaje de alto nivel. Luego, se juntan los
scripts de transformación en un script de carga de tabla destino. Por último, se toman los scripts de carga de
las tablas destino en el orden de ejecución requerido para formar el procesamiento necesario del ciclo batch
(diario, semanal, mensual, y así sucesivamente).
Es importante tener presente que dependiendo de los requerimientos del negocio y la complejidad de las reglas
del negocio necesarias en la transformación, no siempre se necesitará usar las cinco fases para cada tabla
destino.
Fase 1: Comprobación del Origen. En esta fase, su sistema debe acceder, extraer y crear una vista
temporal de los datos del sistema origen. Esta extracción del origen está incluida en respaldos del ciclo
batch completo con propósitos de regeneración y para reconciliación y auditoría durante el testeo.
También se pueden obtener metadatos técnicos y del negocio y verificar el mismo contra el repositorio
de metadatos (si se encuentra disponible), y verificar las reglas del negocio para el sistema origen.
Fase 2: Alteración del Origen. Dependiendo de las necesidades del negocio, en esta fase se pueden
realizar una variedad de transformaciones al origen.
Las opciones incluyen integración de datos desde múltiples sistemas fuente (origen) basados en un
ranking de prioridades o disponibilidad, integrando los datos desde fuentes secundarias, dividiendo los
archivos fuente del
sistema en múltiples archivos de trabajo para múltiples cargas de tablas destino (clusters) y aplicando
lógica y conversiones a los sistemas fuente.
También se pueden aplicar identificadores para metadatos técnicos como por ejemplo identificadores de
fuente del sistema, claves de producción activas, e indicadores de nivel de confianza.
Fase 3: Intercambio Común. En la tercera fase, el intercambio común, se aplican reglas del negocio o
lógica de transformación comunes a múltiples tablas destino –tales como integridad referencial
(introduciendo claves a la tabla de hechos desde las tablas de dimensión, por ejemplo) y definiciones de
la empresa y reglas del negocio desde el repositorio de metadatos.
Por ejemplo: conversión de códigos de país en formato ISO estándar.
Fase 4: Determinación de Carga Destino. En esta fase, el sistema pone los datos en su formato final
para producir los archivos “listos para cargar” en la tabla destino, identifica y selecciona filas a ser
insertadas o actualizadas (si es necesario), identifica los metadatos técnicos, y procesa los datos en un
RDBMS. También compara registros procesados desde el sistema origen para el ciclo batch actual
contra registros cargados en los ciclos anteriores, para determinar si se requieren inserciones o
actualizaciones.
Para los archivos actualizados, los metadatos técnicos registran datos como la fecha de carga, fecha de
actualización, estado actual, ciclo de carga, o los totales de control de redundancia cíclicos para indicar
el cambio en el estado de los registros de datos. Los archivos listos para carga construidos en esta fase
se incluyen en los backups del ciclo batch completo con propósitos de recarga y auditoría durante el
testing.
Dependiendo de la plataforma de DBMS para el DW y el número de registros involucrados, en esta fase
se puede sustituir la opción de carga paralela de gran velocidad en lugar de la utilidad de carga de la
base de datos normal. Se puede lograr a menudo mayor performance en la carga simplemente
eliminando y re insertando todas las filas de datos.
Fase 5: Agregación. En la quinta y última fase, agregación, el sistema usa los archivos listos para
cargar de la fase anterior para construir tablas de agregación que mejoran la performance de las
consultas contra el data warehouse.
Esta fase sólo se aplica contra los procesos de carga con destino tablas de hechos (fact tables).
Asegúrese que los registros agregados finalicen con las claves correctas de las tablas de dimensión para
los niveles de sumarización requeridos en los informes.
Metadatos
Otro aspecto de la arquitectura de data warehouse es crear soporte para los metadatos. Metadatos son la
información sobre los datos que alimentan, se transforman y existen en el data warehouse. Es un concepto
genérico, pero cada implementación de los metadatos usa técnicas y métodos específicos.
27/69
Los métodos y técnicas específicos dependen de los requerimientos de cada organización, de las capacidades
existentes y de los requerimientos de interfaces de usuario. No hay normas para los metadatos, por lo que los
metadatos se definen desde el punto de vista del software data warehousing, seleccionado para una
implementación específica.
Típicamente, los metadatos incluyen los siguientes ítems:
• Las estructuras de datos que dan una visión de los datos al administrador de datos.
• Las definiciones del sistema de registro desde el cual se construye el data warehouse.
• Las especificaciones de transformaciones de datos que ocurren tal como la fuente de datos se
replica al data warehouse.
• El modelo de datos del data warehouse (es decir, los elementos de datos y sus relaciones).
• Un registro de cuando los nuevos elementos de datos se agregan al data warehouse y cuando
los elementos de datos antiguos se eliminan o se resumen.
• Los niveles de sumarización, el método de sumarización y las tablas de registros de su DW.
Los metadatos sirven como el corazón del ambiente data warehousing. Crear definiciones de metadatos
completos y efectivos puede ser un proceso que consume tiempo, pero lo mejor de las buenas definiciones, si
se usan herramientas de gestión de software integrado, es que ese esfuerzo ayudará al mantenimiento del data
warehouse.
Los metadatos se sitúan en una dimensión diferente al de otros datos del data warehouse, debido a que su
contenido no se toma directamente desde el ambiente operacional.
Juegan un rol especial y muy importante en el data warehouse y se usan como:
• Un directorio para ayudar al analista a ubicar los contenidos del data warehouse.
• Una guía para el mapping de datos de cómo se transforma del ambiente operacional al de data
warehouse.
• Una guía de los algoritmos usados para la esquematización entre el detalle de datos actual, con los
datos ligeramente resumidos y éstos, con los datos completamente resumidos, etc.
Los metadatos juegan un papel mucho más importante en un ambiente data warehousing que en un ambiente
operacional clásico. A fin de recordar los diferentes niveles de los datos encontrados en el data warehouse,
considere el siguiente ejemplo:
El detalle de ventas antiguas son las que se
encuentran antes de 1992. Todos los detalles de
ventas desde 1982 (o cuando el diseñador inició
la colección de los archivos) se almacenan en el
nivel de detalle de datos más antiguo.
El detalle actual contiene información desde
1992 a 1993 (suponiendo que 1993 es el año
actual). En general, el detalle de ventas no se
ubica en el nivel de detalle actual hasta que
hayan pasado, por lo menos, veinticuatro horas
desde que la información de ventas llegue a
estar disponible en el ambiente operacional.
En otras palabras, habría un retraso de tiempo de
por lo menos veinticuatro horas, entre el tiempo
en que en el ambiente operacional se haya
hecho un nuevo ingreso de la venta y el
momento cuando la información de la venta haya
ingresado al data warehouse.
El detalle de las ventas son resumidas
semanalmente por línea de subproducto y por
región, para producir un almacenamiento de
datos ligeramente sintetizados.
El detalle de ventas semanal es adicionalmente
resumido en forma mensual, según una gama de
líneas, para producir los datos completamente resumidos.
Los metadatos contienen (al menos): • La estructura de los datos
28/69
• Los algoritmos usados para la esquematización
• El mapping desde el ambiente operacional al data warehouse
La información adicional que no se esquematiza se almacena en el data warehouse. En muchas ocasiones, allí
se hará el análisis y se producirá un tipo u otro de resumen. El único tipo de esquematización que se almacena
permanentemente en el data warehouse, es el de los datos que son usados frecuentemente. En otras palabras,
si un analista produce un resumen que tiene una probabilidad muy baja de ser usado nuevamente, entonces la
esquematización no se almacena en el data warehouse.
1. Administración de metadatos. Dentro de ella se incluyen las siguienes actividades:
1. Definiciones estándares de datos (incluyendo definiciones técnicas y descripciones del
negocio) de los datos almacenados en el warehouse.
2. Metadatos creados y capturados en los procesos de Refinamiento y Reingeniería.
3. Metadatos respecto a granularidad, particionamiento, agregaciones y sumarizaciones.
4. Metadatos que describen consultas y reportes predefinidos.
5. Metadatos que describen índices y configuraciones para mejorar el acceso a los datos y
performance de respuesta.
6. Metadatos describiendo reglas para tiempos y periodicidad de refresco, actualización y ciclo
de réplica
2. Tipos de Metadatos:
• Genéricos: Son los que corresponden a definiciones estándares de los Datos, como la
Fuente de Datos, el Volumen de Datos, la Antigüedad de datos, la Fecha de Depuración,
la Estructura de Datos.
• Específicos: Son los utilizados por las Herramientas DSS , como las Relaciones entre las
tablas, Atributos y métricas, Reportes, Niveles de usuarios y permisos, Sumarizaciones,
Particiones.
3. Modelo genérico de un repositorio de metadatos (ejemplo)

Presentaremos a modo de ejemplo un repositorio de metadatos para el data warehouse, donde se
establece el modelo básico con sus componentes y tablas a modo indicativo.
Componentes:
1. Logical Data Warehouse Model (Modelo Lógico del DW): Contiene información respecto del
modelo lógico del data warehouse, que tiene todas las entidades del negocio para temas
específicos del mismo, relaciones entre entidades y atributos de las entidades que comprenden
el modelo objeto de estudio.
2. Physical Data Warehouse Model (Modelo Físico del DW): Presenta información detallada del
modelo físico del data warehouse. El modelo lógico del data warehouse debe sufrir un proceso
de transformación para convertirse en el modelo físico del data warehouse. Un conjunto de
pasos para modelado dimensional debe aplicarse para producir el modelo físico (por ejemplo,
agregado de tiempo). Este modelo puede contemplar extensiones como índices o estrategias
de fragmentación.
3. Source Data Models (Modelos de Origen de Datos): Tiene información física respecto de
fuentes que alimentan de datos al data warehouse. Esta información operacional puede
originarse desde las bases de datos origen, extracciones de archivo, hojas de cálculo, Internet y
otros formatos. Esta información almacenada en el data warehouse puede usarse para alertar al
equipo de desarrollo del data warehouse de cambios pendientes que podrían afectar
potencialmente el modelo del data warehouse, el proceso ETL y el procesamiento de reportes.
4. Source to Target DW Data Mapping (Mapeo de Datos Origen a Destino del DW): El componente
almacena las referencias cruzadas de mapeos y resolución semántica de las tablas/columnas
entre los sistemas operacionales origen y el modelo físico del data warehouse destino.
5. Bussines Subject Areas (Areas Objeto del Negocio): Aquí se almacena el agrupamiento lógico
de las tablas del data warehouse físicoí. Esta información provee a los usuarios finales del
negocio de un método de navegación o visualización de la información almacenada en el data
warehouse más intuitivo. Esta información puede usarse tanto por las herramientas de reporte
del front-end como el ETL.
29/69
6. ETL Statistics (Estadísticas ETL): La información de
las extracciones individuales, procesos de
transformación y carga, se capturan en este
componente. Esta información puede usarse para
determinar mejoras de los procesos, de la base de
datos, fallas de aislamiento y otros procesos de
optimización para el data warehouse.
7. Query Statistics (Estadísticas de Consulta): En este
componente se almacena la información de cada
consulta efectuada a la base de datos del data
warehouse. Esta información se usa para determinar
qué optimizaciones pueden realizarse a la base de
datos del data warehouse. Las estadísticas de uso
sobre tablas y columnas son analizadas para
determinar datos no utilizados, candidatos para
agregaciones o índices.
En la figura siguiente se muestra la vista lógica de modelado del repositorio genérico de metadatos. Es
importante recordar que este modelo genérico debe ser usado como guía, revisando, agregando y
eliminando los componentes individuales del modelo dependiendo de las necesidades del ambiente del
negocio y de la infraestructura de la empresa específica.
A continuación, se agrupan las tablas acorde al modo en que intervienen para cada componente .
Componente Tablas Descripción
30/69
Modelo Lógico y Físico del Data Warehouse

Target Table Estas tablas guardan información física y lógica sobre el modelo del DW.
Target Column
Target Table: Almacena vistas físicas y lógicas de tablas en el warehouse
Target Domain usando la columna Tipo, que distingue entre las dos categorías. La columna
Target Column Map Nombre contiene contiene el nombre físico o lógico de la DB de la tabla del
warehouse.
Table Column Map: provee una referencia cruzada de las tablas físicas/lógicas
con sus columnas asociadas.
Target Column: contiene información técnica y del negocio sobre el campo de la
tabla. El campo Target Column Business Rules se usa para denotar cualquier
convención o práctica que debe seguir la columna.
Ej: un campo monto debe tener un valor de moneda correspondiente.
Target Domain: contiene definiciones de valores para columnas conteniendo
solamente códigos (lista lookup). Cada posible valor de un dominio o código para
una columna se guarda en esta tabla.
Ejemplo: la columna código de país tiene valores de dominio que incluyen USA
(Estados Unidos) y CAN (Canadá)
Source Estas tablas guardan información física sobre los sistemas operacionales,
Modelo de Datos Origen
Source Column que alimentan de información el DW.

Source Domain
Source Table: contiene información sobre la DB del sistema de origen o del
archivo de extracción usado para poblar las tablas destino del warehouse. La
columna Source ID se usa para identificar unívocamente un registro o sistema
particular (ERP, Orden de Administración N°1, Ticket con problemas, Extracto de
Cliente N°5). El Source Format Type provee medios para identificar la categoría
de la fuente de los datos, como servidor/db, directorio/archivo o archivo de hoja de
cálculo.
Source Column y Source Domain: siguen las mismas definiciones que Target
Column y Target Domain, pero para el Origen de datos.
Source To Target Estas tablas proveen la estrategia de diseño necesaria para construir los
Mapeo datos Origen a Destino
Column Map procesos de extracción, transformación y carga (ETL, por sus siglas en
inglés), enlazando las fuentes operacionales de origen de datos con las
Source To Target tablas del warehouse que alimentan.
Domain Map
Además del mapeo documentado en estas tablas de referencia cruzada,
en la columna Mapping Semantic Resolution de ambas tablas se describe
cualquier instrucción adicional que sea necesaria.
ETL Process Estas tres tablas mapean tablas del DW y fuentes operacionales con los
procedimientos que acceden a ellas y capturan estadísticas sobre el
ETL Process procesamiento de la carga. La población de estas tablas dependerá de la
Estadísticas ETL
Statistics metodología y de los productos ETL utilizados por la organización.

ETL Process Source ETL Process: contiene una columna Process ID para identificar univocamente el
Map procedimiento ETL en el ambiene del warehouse.
ETL Process Statistics: contiene el mapeo de los procesos a una o varias tablas
del DW y las estadísticas de fecha/hora del proceso para un ciclo de carga
asincrónico específico. Un solo proceso ETL puede cargar una o muchas tablas
del DW, dependiendo de las fuentes de datos y de los requerimientos del negocio
involucrados.
ETL Process Source Map: provee una referencia cruzada de los procesos ETL
con los archivos de extracción o los sistemas operacionales.
31/69
Subject Area Estas tablas proveen al usuario final con una agrupamiento lógico o vista del
Estadísticas de Consulta Áreas del negocio

negocio sobre las tablas del DW.
Subject Area Table Ejemplo: Ventas, Financieras, Recursos Humanos
Map
Subject Area: contiene la columna Subject Area ID para identificar univocamente
el conjunto de tablas dentro de la empresa desde una perspectiva del negocio.
Subject Area Table Map: agrupa las tablas del DW (lógicas y físicas) en un área
del negocio.
Query Statistics Mapean las tablas y columnas del warehouse a los requerimientos de las
consultas que las acceden capturan estadísticas sobre procesamiento. La
Query Table Column población de estas tablas dependerá del DBMS, la herramienta de
Hits reportes y/o el producto de monitoreo de datos que se esté usando.
Query Statistics: contiene informaciones varias sobre resultados de las consultas
hechas al warehouse. Estos requerimientos pueden ser del front-end de la
herramienta de reportes o de consultas ad-hoc hechas directamente a la DB, y
dependiendo de las necesidades de información de los DBAs, los desarrolladores
de adquisición de datos, los desarrolladores de acceso de datos o el arquitecto.
Query Table Column Hits: provee una referencia cruzada entre las consultas de
la base de datos y las tablas y columnas del warehouse.
32/69
Módulo 3: Gerenciamiento de los sistemas de información
Unidad 5: Corporate Information Factory

Existen, hoy en día, personas tendientes a organizar las ideas y actividades dentro de un marco conceptual
unificado. Desde la década de los ‘60, William H. Imon, ha estado involucrado con la tecnología de base de
datos y en el diseño de data warehouse. Como autor, ha desarrollado infinidad de artículos en lo que respecta
a la construcción, uso y mantenimiento de un data warehouse. Una de sus últimas obras fue la
conceptualización del Corporate Information Factory (desde ahora CIF).
Inmon define: “el CIF es un concepto que abarca todas las estructuras de datos de una organización junto con
todos los procesos y herramientas utilizados en las distintas etapas para generar información y hacer que esté
disponible en tiempo y forma en todos los niveles de dicha organización”. El CIF consiste de los siguientes
componentes:
A. Aplicaciones Transaccionales.
B. Aplicaciones ERP
C. Un área de integración y transformación.
D. Un proceso ETL o de integración y transformación.
E. Un Enterprise Data Warehouse (o solamente un “Data Warehouse”).
F. Un ODS corporativo.
G. Diferentes Data Marts.
H. Aplicaciones DSS.
I. Utilidades de exploración/Data Mining.
J. Almacenamientos alternativos.
A. Aplicaciones Transaccionales
Las Aplicaciones Transaccionales constituyen los sistemas en donde se hacen las transacciones. Esas
aplicaciones, en gran parte, son legacy systems, escritos hace varios años, y en su mayoría no están
integradas con ninguna otra aplicación. Cada aplicación es dueña de su propio entorno. Estos pueden ser
sistemas internos o externos a la organización, y constituyen el origen del CIF.
B. Aplicaciones ERP
Del mismo modo que las aplicaciones transaccionales, las aplicaciones ERP (Enterprise Resource Plannig) o
de planificación de recursos empresariales, son aquellas provistas por un vendedor ERP y están integradas,
por lo menos dentro del entorno ERP, ya que las transacciones se ejecutan dentro de este entorno. Al igual que
las aplicaciones transaccionales, constituyen la base del CIF.
Estas dos clases de aplicaciones definen los lugares de donde se extraerá la información para su análisis
posterior, e incluyen las BD de sistemas operacionales, BD externas a la empresa, BD de sistemas ERP ,
Internet, datos aportados por especialistas, y cualquier otro medio interno o externo que se use para registrar
33/69
información (documentos, Mails, Planillas, Memos, Internet, etc.) .
C. Área de Transformación e Integración
El Área de transformación/integración es el lugar en donde los datos son depositados luego de ser extraídos de
las aplicaciones. Representa el lugar en donde los datos pueden ser transformados sin el impacto negativo
sobre la performance de las aplicaciones. Generalmente este área es necesaria solamente en donde hay
grandes volúmenes de datos a procesar.
Normalmente, el área de transformación/integración no es accesible por otros procesos que no sean para la
extracción de datos desde las aplicaciones y preparación para la entrada en el entorno ETL. No se hacen
reportes de ningún tipo que no esté relacionado con el procesamiento de transformación e integración.
D. Procesos ETL o de integración y transformación
La integración y transformación se compone de procesos que se encargan de extraer información de las
fuentes de datos, transformarla, recodificarla, limpiarla, explicitar reglas de negocio ocultas, formatearla y
organizarla de manera de poder incorporarla en el entorno. A estos procesos se los conoce con la sigla ETL
(Extract, Transform and Load).
La capa de procesamiento ETL (Extract, Transformation, Load) es el lugar en donde los datos no integrados y
no depurados provenientes de diferentes aplicaciones son procesados. El propósito de los procesos de ETL es
integrar y depurar los datos para la preparación anterior a la inserción al data warehouse o hacia el ODS
corporativo. El procesamiento ETL realiza las siguientes tareas:
• Convierte datos. • Verifica el rango de dominio de los datos.

• Formatea datos. • Verifica las relaciones entre atributos.
• Unifica datos. • Unifica diferentes tecnologías de DBMS.
• Reestructura datos. • Unifica sistemas operativos.
• Altera los valores de las claves. • Resume - Sumariza datos.
• Suministra valores por defecto si son • Separa datos, si es necesario.
necesarios. • Combina atributos, si es necesario.
• Ordena datos. • Combina datos desde otras fuentes, si es
• Depura inconsistencia en los datos. necesario.
Los datos de aplicaciones no integrados entran en la capa ETL y los datos integrados y depurados persisten
dentro de la capa de ETL. El procesamiento ETL puede manejar un gran volumen de datos de diferentes
formas, manejando el flujo de datos en paralelo, ejecutando código de forma eficiente, tomando ventajas de
áreas de caching, y demás formas.
E. Data Warehouse
El DW es una colección de información corporativa derivada directamente de los sistemas operacionales y de
algunos orígenes de datos externos. Es actualizado mediante procesos complejos de transformación (ETL) y
organizado por áreas de interés con el objeto de servir a los propósitos de sistemas de soporte de decisión. Es
el centro del CIF. Contiene datos históricos, integrados, de toda la organización, con alta granularidad y no
redundantes.
El Data Warehouse alimenta a Data Marts, Exploration Warehouses, Data Mining Warehouses y cierto tipo de
ODS. Normalmente está almacenado en unidades de almacenamiento primario (discos de alta velocidad) pero
puede estarlo también sobre cintas y dispositivos ópticos.
Otras definiciones de DW:
• Un data warehouse es un conjunto de datos integrados orientados a una materia, que varían
con el tiempo y que no son transitorios, los cuales soportan el proceso de toma de decisiones
de una administración.
• Un data warehouse es un depósito semánticamente consistente de datos (separados y que no
interfieren con los sistemas operativos y de producción existentes) que llenan por completo los
diferentes requerimientos de acceso y reportes de datos.
El Data Warehouse tiene como objetivos utilizar la información que ha reunido una organización durante sus
ciclos de operaciones para ayudarle a reaccionar mejor, más elegante, rápida y eficientemente, y organizar
esta información de manera que ésta pueda ser utilizada como una ventaja estratégica frente a la competencia.
En resumen, el data warehouse es el lugar en donde residen los datos granulares. Los datos encontrados en él
son detallados, históricos, e integrados y se registran después de haber pasado por la capa ETL. Pueden estar
formulados de diferentes formas, porque diferentes personas necesitan ver los datos granulares en formas
34/69
diferentes.
El data warehouse tiende a contener grandes volúmenes de datos históricos: es muy común hablar de datos de
más de 10 años de antigüedad. Cada unidad de dato encontrada tiene un elemento de tiempo asociado , cada
registro posee una fecha (o elemento de tiempo) que lo describe. Ya que cada registro es histórico, se dicen
que los datos se mantienen como “snapshots” (fotos) en el data warehouse. Cuando ocurren cambios, se toma
una nueva foto y se almacena un nuevo registro. Los datos en el warehouse no son modificados, pero se
adicionan snapshots constantemente para reflejar los cambios.
El data warehouse no soporta procesamiento de transacciones en línea (OLTP).
Problemas en cada etapa de evolución de un data warehouse
1. Tablas Sumarizadas.
◦ No aislaba carga de Trabajo.
◦ Altos costos de actualización de equipos.
◦ Se debía disponer de datos provistos por OLTP.
◦ El recálculo era muy costoso.
2. Datos operacionales en un Servidor Separado.
◦ No administraba metadatos.
◦ Base de datos no optimizada.
◦ Flexibilidad Limitada.
3. Data Mart aislado.
◦ Futuras expansiones forzaban a replantear los programas
◦ No poseían datos sumarizados.
4. Data Warehouse en capas.
◦ Altos costos de implementación.
◦ Altos tiempos de implementación.
Características Esenciales de un Data Warehouse

• Orientado a un tema.
• Integrado.
• Variable en el tiempo.
• No volátil.
Orientado a un tema
Se dice que un DW está orientado a una materia (a
un tema) cuando está orientado a las principales
entidades de un empresa u organización. El dato
orientado a un tema es un enfoque que contrasta a
la orientación clásica de las aplicaciones y sistemas
operacionales, que casi siempre es proceso/función.
El mundo operacional está diseñado alrededor de
las aplicaciones y funciones tales como préstamos,
ahorros, tarjetas bancarias, y créditos para una
institución financiera.
El mundo de un data warehouse esta organizado a
través de las principales entidades tales como clientes, vendedores, productos y actividad. La alineación a
través de las áreas afecta el diseño e implementación de los datos encontrados en el data warehouse.
El mundo de la aplicación se interesa por el diseño de la base de datos y del diseño de los procesos. El
mundo de un DW se enfoca en el modelado de datos y diseño de base de datos exclusivamente.
Integración
Que haya fácil integración es el aspecto más importante del entorno de un data warehouse y define que los
datos encontrados dentro de este, están integrados. SIEMPRE, SIN EXCEPCIONES. La integración se
muestra de diferentes formas – en la consistencia de convenciones de nombramiento, en la consistencia de
las medidas de las variables, en la consistencia de la codificación de las estructuras, en la consistencia de
los atributos físicos de datos, y muchos más. El contraste de la integración encontrada en el data warehouse
35/69
con la carencia de integración del ambiente de aplicaciones, se muestran en la figura, con diferencias bien
marcadas
A través de
los años, los
diferentes
diseñadores de aplicaciones han hecho sus propias decisiones de cómo una aplicación debe ser construida.
El estilo y las decisiones de diseño individualizadas de los diseñadores de aplicaciones se muestran en
cientos de formas: en diferencias de codificación, estructuras de claves, características físicas,
nombramientos, y demás.
La habilidad de muchos diseñadores de aplicaciones en crear aplicaciones inconsistentes es legendaria. La
figura, muestra algunas de las diferencias más importantes en las formas en que se diseñan las
aplicaciones:
• Codificación. Los diseñadores codifican el campo GENERO de varias formas. Un diseñador
representa GENERO como una "M" y una "F", otros como un "1" y un "0", otros como una "X" y una
"Y" e inclusive, como "masculino" y "femenino".
No importa mucho cómo el GENERO llega al data warehouse. Probablemente "M" y "F" sean tan
buenas como cualquier otra representación. Lo importante es que de cualquier fuente de donde
venga, el GENERO debe llegar al data warehouse en un estado integrado uniforme.
Por lo tanto, cuando el GENERO se carga en el data warehouse desde una aplicación, donde ha
sido representado en formato "M" y "F", los datos deben convertirse al formato del data warehouse.
36/69
• Medida de atributos. Los diseñadores de aplicaciones usan diferentes unidades de medida de las
tuberías. Un diseñador almacena los datos de tuberías en centímetros, otros en pulgadas, otros en
millones de pies cúbicos por segundo y otros en yardas.
Al dar medidas a los atributos, la transformación traduce las diversas unidades de medida usadas
en las diferentes bases de datos para transformarlas en una medida estándar común. Cualquiera
que sea la fuente, cuando la información de la tubería llegue al data warehouse necesitará ser
medida de la misma manera.
• Convenciones de Nombramiento. Se usan nombres diferentes para el mismo elemento en las
diversas aplicaciones. El proceso de transformación asegura que se use preferentemente el nombre
de usuario.
• Fuentes Múltiples: El mismo elemento puede derivarse desde fuentes múltiples. En este caso, el
proceso de transformación debe asegurar que la fuente apropiada sea usada, documentada y
movida al depósito.
Tal como se muestra en la figura, los puntos de integración afectan casi todos los aspectos de diseño -las
características físicas de los datos, la disyuntiva de tener más de una de fuente de datos, el problema de
estándares de denominación inconsistentes, formatos de fecha inconsistentes y otros.
Cualquiera que sea la forma del diseño, el resultado es el mismo - la información necesita ser almacenada
en el data warehouse en un modelo globalmente aceptable y singular, aun cuando los sistemas
operacionales subyacentes almacenen los datos de manera diferente.
Cuando el analista de sistema de soporte de decisiones observe el data warehouse, su enfoque deberá
estar en el uso de los datos que se encuentre en el depósito, antes que preguntarse sobre la confiabilidad o
consistencia de los datos.
Variable en el tiempo
Se entiende que todos los datos en el data warehouse son precisos en un momento de tiempo dado. Esta
característica es muy diferente al del entorno operacional en donde los datos son precisos al momento de
acceso, en otras palabras, en el entorno operacional, cuando se accede a una unidad de dato, se espera
que éste refleje el valor preciso a ese momento. Ya que los datos son precisos a un momento en el tiempo,
los datos encontrados en el warehouse se dicen que son “variables en el tiempo” .
La figura muestra
la variabilidad de
los datos:
El tiempo variante se muestra de varias maneras:

1. La más simple es que la información representa los datos sobre un horizonte largo de tiempo ,
desde cinco a diez años. El horizonte de tiempo representado para el ambiente operacional es
mucho más corto - desde valores actuales hasta sesenta a noventa días.
Las aplicaciones que tienen un buen rendimiento y están disponibles para el procesamiento de
transacciones, deben llevar una cantidad mínima de datos si tienen cualquier grado de flexibilidad.
Por ello, las aplicaciones operacionales tienen un corto horizonte de tiempo, debido al diseño de
aplicaciones rígidas.
2. La segunda manera en la que se muestra el tiempo variante en el data warehouse está en la
estructura clave. Cada estructura clave en el data warehouse contiene, implícita o explícitamente,
un elemento de tiempo como día, semana, mes, etc.
El elemento de tiempo está casi siempre al pie de la clave concatenada, encontrada en el data
warehouse. En ocasiones, el elemento de tiempo existirá implícitamente, como el caso en que un
archivo completo se duplica al final del mes, o al cuarto.
3. La tercera manera en que aparece el tiempo variante es cuando la información del data warehouse,
37/69
una vez registrada correctamente, no puede ser actualizada. La información del data warehouse es,
para todos los propósitos prácticos, una serie larga de "snapshots" (instantáneas).
4. Por supuesto, si los snapshots de los datos se han tomado incorrectamente, entonces pueden ser
cambiados. Asumiendo que los snapshots se han tomado adecuadamente, no son alterados una
vez hechos. En algunos casos puede ser no ético, e incluso ilegal, alterar los snapshots en el data
warehouse. El dato operacional es preciso al momento de acceso, y por lo tanto es modificado
tantas veces como sea necesario.
Los datos históricos son de poco uso en el procesamiento operacional. La información del depósito , por el
contrario, debe incluir los datos históricos para usarlos en la identificación y evaluación de tendencias.
No Volátil
La figura muestra esta ultima característica del DW, la de ser no volátil:
La figura muestra que modificaciones, inserciones, borrados y cambios son hechos regularmente a los
entornos operacionales, registro por registro. Pero la manipulación básica de los datos que existen en el
data warehouse es mas simple. Hay solo dos tipos de operaciones que ocurren en un data warehouse – la
carga inicial de los datos y el acceso a los datos. No hay modificación de los datos en el data warehouse
como parte del procesamiento normal.
Hay algunas consecuencias muy importantes de esta diferencia básica, entre el procesamiento operacional
y del data warehouse. En el nivel de diseño, la necesidad de ser precavido para actualizar las anomalías no
es un factor en el data warehouse, ya que no se hace la actualización de datos. Esto significa que en el nivel
físico de diseño, se pueden tomar libertades para optimizar el acceso a los datos, particularmente al usar la
normalización y denormalización física.
Otra consecuencia de la simplicidad de la operación del data warehouse está en la tecnología subyacente,
utilizada para correr los datos en el depósito. Teniendo que soportar la actualización de registro por registro
en modo on-line (como es frecuente en el caso del procesamiento operacional) requiere que la tecnología
tenga un fundamento muy complejo debajo de una fachada de simplicidad.
La tecnología permite realizar backup y recuperación, transacciones e integridad de los datos y la detección
y solución al estancamiento que es más complejo. En el data warehouse no es necesario el procesamiento.
La fuente de casi toda la información del data warehouse es el ambiente operacional. A simple vista, se
puede pensar que hay redundancia masiva de datos entre los dos ambientes. Desde luego, la primera
impresión de muchas personas se centra en la gran redundancia de datos, entre el ambiente operacional y
el ambiente de data warehouse. Dicho razonamiento es superficial y demuestra una carencia de
entendimiento con respecto a qué ocurre en el data warehouse. De hecho, hay una mínima redundancia de
datos entre ambos ambientes. Se debe considerar lo siguiente:
• Los datos se filtran cuando pasan desde el ambiente operacional al de depósito. Existe mucha
data que nunca sale del ambiente operacional. Sólo los datos que realmente se necesitan
ingresarán al ambiente de data warehouse.
• El horizonte de tiempo de los datos es muy diferente de un ambiente al otro. La información en el
ambiente operacional es más reciente con respecto a la del data warehouse. Desde la
perspectiva de los horizontes de tiempo únicos, hay poca superposición entre los ambientes
38/69
operacional y de data warehouse.
• El data warehouse contiene un resumen de la información que no se encuentra en el ambiente
operacional.
• Los datos experimentan una transformación fundamental cuando pasa al data warehouse. La
mayor parte de los datos se alteran significativamente al ser seleccionados y movidos al data
warehouse. Dicho de otra manera, la mayoría de los datos se alteran física y radicalmente
cuando se mueven al depósito. No es la misma data que reside en el ambiente operacional
desde el punto de vista de integración.
En vista de estos factores, la redundancia de datos entre los dos ambientes es una ocurrencia rara, que
resulta en menos de 1%.
OLTP vs. DSS
Las aplicaciones de BD OLTP (Online Transaction Processing) son óptimas para administrar datos que
cambian. Estas aplicaciones, típicamente, tienen muchos usuarios que ejecutan transacciones que
modifican datos en tiempo real al mismo tiempo; en otras palabras, OLTP es una DB en vivo (con inserts,
deletes, updates, etc).
Las aplicaciones de BD de los Sistemas de Soporte de Decisión son óptimos para consultas que no
modifican los datos. Por ejemplo, una compañía puede sumarizar periódicamente sus ventas por fecha,
por región, o producto y guardar esta información en una DB separada para ser usada para análisis por la
administración. Para tomar decisiones de negocios, los usuarios deben ser capaces de determinar
tendencias en las ventas con rapidez, a través de las consultas a los datos usando diferentes criterios.
Estas consultas no modifican los datos. Las tablas de una BD de soporte a decisiones están fuertemente
indexadas, y los datos crudos son a menudo preprocesados y organizados para soportar varios tipos de
consultas.
Como los usuarios no modifican los datos, la concurrencia y atomicidad no plantean problemas: los datos
se modifican sólo con actualizaciones masivas y periódicas, fuera del horario de trabajo y cuando el
tráfico de datos en la BD es bajo.
Las diferencias resumidas entre ambos ambientes de datos se muestran en la tabla siguiente:
DATOS DSS OLTP
Contenido Datos Sumarizados Valores discretos, Detallados
Organización Por área de interés Por aplicación
Naturaleza Estático hasta hacer el refresco Dinámico
Uso Procesamiento analítico, altamente Procesamiento repetitivo, altamente
desestructurado. estructurado.
Estructura Pocas tablas desnormalizadas Muchas tablas altamente
normalizadas
Granularidad Cierto nivel de sumarización Transaccional
Tiempo de respuesta Desde algunos segundos hasta Desde centésimos hasta 2 ó 3
minutos segundos
F. ODS (Operation Data Store)

El Corporate ODS es una construcción de datos destinada a servir de apoyo a la toma de decisiones
operativas, rutinarias y diarias de los niveles más bajos de la organización.
Sus características principales son:
• Orientado a una materia.
• Integrado.
• Con valores actuales.
• Volátil
• Detallado.
• Con velocidad de respuesta entre 2 y 3 segundos.
• Para usuarios con perfil de operadores.
39/69
El ODS corporativo es una estructura híbrida en donde se encuentran algunos aspectos operacionales y
algunos aspectos de sistemas de decisiones (DSS). Soporta procesamiento de transacciones en línea (2 – 3
segundos de tiempo de respuesta) y procesamiento de actualización directa, y también soporta procesamiento
DSS usando datos integrados, exactamente igual que el data warehouse.
El ODS es alimentado por la capa de ETL.
Podemos clasificar los ODS según el momento en que se los refresca, a partir de la actualización de los datos
transaccionales.
Clase I. Las transacciones son movidas hacia el ODS en forma inmediata desde las
aplicaciones, en el rango de uno a dos segundos, desde el momento en que la transacción fue
ejecutada en el entorno operacional hasta que la transacción es incorporada al ODS.
Clase II. Las actividades que ocurren en el entorno operacional fueron almacenadas y
retransmitidas hacia el ODS cada hora y más. En este caso, hay un notable salto entre la
ejecución original y el reflejo de la misma en el ODS.
Clase III. La diferencia de tiempo entre la ejecución en el entorno operacional y el reflejo de la
misma en el ODS, se realiza durante la noche. Este tipo de ODS es fácil de construir.
Clase IV. Un ODS de este tipo es aquel que depende de un data warehouse. La entrada al ODS
puede ser regular o irregular. Esta clase de ODS es más fácil de construir ya que depende
directamente del data warehouse el cual ya ha sido construido y depurado.
G. Data Mart
El Data Mart es el lugar en donde diferentes departamentos ubican sus propios datos para el procesamiento
DSS. El data mart es único por departamento o sub-departamento. Típicamente los departamentos que tienen
su propio data mart son los departamentos de finanzas, ventas, marketing, contabilidad, y Recursos humanos.
El dato granular encontrado en el data warehouse es tomado y transformado en una forma óptima para el
departamento. Típicamente , hay mucho menos datos en el data mart que en el data warehouse ya que en el
data mart los datos son sumarizados y denormalizados, y a su vez, el data mart contiene mucho menos datos
históricos.
La estructura de datos típica del entorno de data mart es el star join (estrella), en donde se ubica una tabla
base y sus tablas de dimensiones. La estructura de un data mart es muy diferente de la estructura de otro data
mart.
En estos entornos, las tecnologías dimensionales son óptimas. Los data marts son periódicamente refrescados
desde el data warehouse para mantener su datos actualizados.
Características básicas:
• Es un subconjunto de datos corporativos válidos para una unidad de negocio específica, sobre
un tema puntual o para un grupo reducido de personas. Este subconjunto consiste de datos
históricos, sumarizados y posiblemente detallados.
• Es una solución menos costosa y mucho más reducida que la implementación de un Data
Warehouse.
• Normalmente comprende un modelo multidimensional.
• Para usuarios con perfil de granjeros (ver mas adelante)
H. Aplicaciones DSS
Las aplicaciones DSS son el lugar en donde una simple función es realizada. La función generalmente recorre
múltiples departamentos. Algunas aplicaciones DSS son CRM, análisis de elasticidad, reportes de ERP
Business Intelligence, etc.
I. Utilidades de exploración/Data Mining.
Análisis estadísticos.
El procesamiento estadístico fuerte ocurre en los medios de exploración y data mining. La separación de los
medios de exploración y data mining con el resto del entorno de data warehouse se basa en que el
procesamiento que ocurre en los medios de exploración y data mining no tienen impacto de performance
con el resto del procesamiento que ocurre en el entorno de data warehouse.
Los tiempos de respuesta pueden ser desde una hora hasta una semana de procesamiento.
40/69
El dato encontrado en los medios de exploración y data mining es usualmente muy detallado e histórico.
Además, ocasionalmente hay una necesidad de que no se refresquen los datos de exploración. El dato de
exploración se necesita mantener constante para que el resultado obtenido de un análisis pueda ser
comparado con el resultado de otro análisis.
Exploration Warehouse
• Satisface requerimientos de procesamiento temporal y desestructurado con alta velocidad de
respuesta.
• Condensa la información de un EDW y la organiza de manera que pueda ser incorporada
parcialmente en la memoria de un Servidor y conseguir de esta manera, altas velocidades de
respuesta.
• Puede nutrirse del EDW para fines exploratorios o de los sistemas transaccionales si se utilizará
para realizar análisis “What-if”
• Debido a la naturaleza de los requerimientos de exploración sus datos se encuentran altamente
indexados.
• Su existencia es transitoria o temporaria.
• Sirve de puente a un Data Mining Warehouse.
• Para usuarios con perfil de Exploradores.
Data Mining Warehouse
• Es un almacén creado para contener las entradas y las salidas de los procesos de minería, de manera
que no interfieran con los sistemas operacionales y de soporte de decisión.
• Permite realizar búsquedas altamente desestructuradas de exploración.
• Los datos están enriquecidos con variables necesarias para los procesos de minería.
• Para usuarios con perfil de Mineros.
J. Almacenamientos Alternativos
Los almacenamiento Alternativos consisten de medios de almacenamiento de baja performance, entre los que
se incluyen:
• Datos viejos
• Datos de uso no frecuente
• Datos sumarizados de uso no frecuente
• Datos de contingencia, y otros...
Es necesario usar herramientas que controlen el uso y el traspaso de información a estos almacenamientos.
El almacenamiento alternativo es diferente del almacenamiento de discos clásico. Hay mucho datos en el data
warehouse que de alguna forma se transforman en obligatorios. Además, el volumen en un data warehouse
maduro es demasiado, por lo que es necesario separar este en dos clases: Almacenamiento usado
activamente y almacenamiento no usado activamente.
Transcurrido el tiempo, el data warehouse crece y la cantidad de datos inactivos supera ampliamente la
cantidad de datos usado activamente. A este punto, no hay justificación económica ni tecnológica para
continuar almacenando estos datos en almacenamiento de discos de alta performance. Los almacenamientos
alternativos presentan una atractiva alternativa de almacenamiento a un bajo costo.
K. Metadatos
Los Metadatos son el lugar donde se almacena la información que necesitan las herramientas de consulta y el
motor de cálculo para traducir peticiones de datos en consultas contra un motor.
También se almacena información sobre las fuentes, los procedimientos de extracción de datos, la periodicidad
de actualización, las unidades de medida y cualquier otra información válida tanto para el usuario final como
para los componentes intermedios.
Una forma más práctica de definir qué es un metadatos es citando algunos ejemplos:
• Descripción del Dato. El registro de clientes contiene una lista de atributos, y su posición relativa
y formato en el medio de almacenamiento.
◦ Cust-id char (15)
◦ Cust-name varchar (45)
◦ Cust-address varchar (45)
41/69
◦ Cust-balance dec fixed (15, 2)
• Contenido. Hay 150,000 ocurrencias de la transacción X en la tabla PLK.
• Índices. La tabla XYZ contiene índices en las siguientes columnas:
◦ Columna HYT
◦ Columna BFD
◦ Columna MJI
• Plan de Actualización. La tabla ABC es refrescada cada Martes a las 2:00 P .M.
• Uso. Solamente 2 de 10 columnas en la tabla ABC han sido usadas en los últimos 3 meses.
• Integridad referencial. La tabla XYZ está relacionada con la tabla ABC por la clave QWE.
• Documentación General. “La tabla ABC fue diseñada en 1975 como parte del sistema de
cobranza”. La tabla ABC contiene datos de cuentas morosas calculadas por... ”
Estos ejemplos de metadatos solamente son un subconjunto ínfimo de la información contenida en este. La
forma final deberá ser limitada solamente por la imaginación y por las necesidades que gobiernan el uso y la
administración del CIF.
La razón por la cual los metadatos son importantes para el CIF, y sus diferentes componentes, es que son el
mecanismo que almacenan la arquitectura del CIF. La figura ilustra este rol de los metadatos. Sin metadatos,
los diferentes componentes del CIF son solamente estructuras sin relación entre ellas.
Unidad 6:
Explotación del Corporate Information Factory (CIF)
Hasta ahora hemos detallado cada uno de los componentes de un CIF (Unidad 5), como así también, hemos
analizado una metodología de diseño de modelos multidimensionales contenida en este, pero no hemos
nombrado aún quienes son los principales destinatarios de este gran trabajo.
En primer lugar, se pueden clasificar diferentes tipo de usuarios, identificados por características propias que
marcan esa diferencia.
Al conjunto de todos los usuarios que por su naturaleza utilizan el CIF, se los denomina comunidad de usuarios
del CIF. A primera vista, surgen tres tipos básicos de usuarios, los cuales se detallan a continuación:
• Turistas.
El turista, en términos generales es el tipo de usuario que sabe como encontrar los datos,
navega sobre los mismos en forma ligera y rápida. En general, los turistas no tienen un
conocimiento formado acerca de lo que están buscando, solo conocen todo acerca de índices,
catálogos y metadatos.
Están cómodos con los motores de búsqueda.
• Granjeros
42/69
El granjero es el usuario regular. Trabaja en forma predecible, busca datos en forma regular y
generalmente realiza consultas rutinarias. El granjero conoce qué es lo que busca, y los
resultados de sus consultas son de poca cantidad de registros. Generalmente, el granjero
encuentra lo que está buscando y accede a un datamart.
• Exploradores
El explorador es una persona impredecible. Ejecuta largas consultas que recorren grandes
cantidades de registros. Este usuario generalmente no encuentra lo que está buscando pero las
pocas veces que encuentra algo, seguramente produce un efecto positivo en la organización. El
explorador opera dentro del Enterprise Data Warehouse ya que precisa de datos altamente
normalizados, históricos y consolidados.
Estos tipos de usuarios están determinados por el uso que hacen del CIF en un determinado momento. Con
esto queremos especificar que un usuario puede ser de un tipo en un momento y luego, tras haber cambiado
su forma de actuar con el tiempo, pasar a representar otro tipo de usuario dentro de la comunidad.
Para simplificar la comparación proponemos el siguiente cuadro :
Turistas Exploradores Granjeros

(Exploration DataWarehouses) (DataMarts)
✔ Es un individuo que sabe qué ✔ Son personas que tienen una ✔ Conocen qué quieren y cómo
es lo que quiere. idea de lo que quieren y por obtenerlo. Por lo tanto, no
✔ Su objetivo es inspeccionar dónde buscar, pero no saben miran muchos datos.
tanto territorio como le sea realmente cómo avanzar en su ✔ Frecuentemente encuentran
posible. tarea o encontrar sus objetivos. “pepitas de oro”.
✔ Hará poco o ningún análisis ✔ A menudo no encuentran nada. ✔ Es inusual buscar algo sin
profundo. Pero a veces encuentran una encontrarlo después.
✔ E turista mira el resumen de “gema” de gran valor para la Normalmente no encuentran
muchas cosas diferentes. organización. “gemas” enormes, como a
✔ Los metadatos son muy ✔ No van a muchos lugares como veces les pasa a los
importantes para él. lo hace el turista. exploradores.
✔ Ama Internet y su capacidad de ✔ Los metadatos son importantes, ✔ Hacen muy poco uso de los
búsqueda. pero no tanto como lo son para metadatos.
✔ No pasa mucho tiempo en un un turista. ✔ Internet es sólo una curiosidad
sitio o lugar. ✔ Internet a veces es muy para ellos.
✔ Frecuentemente mira un valioso. Sin embargo, cuando ✔ Operan en un horario
conjunto de datos una sola vez ha encontrado la “pila de datos predecible. Realizan la misma
y nunca más regresa. que necesita”, Internet juega un actividad repetidamente,
✔ Es la persona indicada para papel pasajero. excepto sobre los mismos
interrogar cada vez que desee ✔ Crean enormes consultas. El datos.
realizar un análisis de un SSD y tiempo de respuesta varía en ✔ Las transacciones que realizan
no tenga idea por dónde muchos días. son muy eficientes debido a
empezar. ✔ Miran los datos de una manera, que examinan sólo una
luego de otra, luego pasan a pequeña cantidad de datos en
otros datos. cada una de ellas.
✔ Generalmente son actuarios e ✔ Esperan una buena
ingenieros de control de performance para las consultas
procesos. que realizan.
✔ Por lo general son trabajadores
del conocimiento de áreas de
Contabilidad y Finanzas.
Recientemente, se han descubierto otros usuarios finales de un CIF: los mineros. Los mineros examinan
metódicamente los datos buscando la confirmación de hipótesis o quizás buscando nuevas. Una vez que han
encontrado el patrón, tratan de explicarlo con sentido técnico y de negocios.
Hay una conexión importante entre el explorador y el minero de datos, en un sentido el explorador precede al
minero y establece el escenario para el éxito del Data Mining (Minería de Datos). El explorador hace el trabajo
necesario para la identificación y creación de las hipótesis. El minero de datos luego toma la hipótesis y la
confirma o rechaza y determina la solidez de la misma. A pesar de esto, existen diferencias muy marcadas,
como las que se detallan a continuación:
43/69
Explorador Minero de datos
✔ Opera en la misma BD. ✔ Está constantemente cambiando de BD.
✔ La BD está normalizada. ✔ Las BD son planas y no son normalizadas.
✔ No sabe lo que espera antes de la ejecución de la ✔ Tiene una idea clara de qué espera antes de
consulta. presentar la consulta.
Esta clasificación de los usuarios finales de un CIF, provee un marco de trabajo a partir del cual el diseñador y
el arquitecto del CIF pueden comenzar a comprender el mismo. Este marco de trabajo, a su vez, da las bases
para el ordenamiento a través de muchas contradicciones aparentes que se encuentran en el procesamiento y
el diseño. Sin este “mapa de ruta” de los usuarios finales del entorno del CIF, no se puede tener un marco
comprensivo para el procesamiento.
Dentro del entorno de un CIF, los usuarios se relacionan con este de diferentes formas:
1. SQL
2. Query and Reporting.
3. Herramientas OLAP
4. KDD / Data Mining.
Cada usuario tiene formas diferentes de acceder al CIF y a cada una de sus partes. Hay usuarios que con solo
la utilización de sentencias SQL (para motores del tipo relacionales) o de sentencias multidimensionales (para
motores del tipo multidimensionales) pueden obtener lo que están buscando. Una forma mas sofisticada sería
la de embeber en aplicaciones propias, conjuntos de estas sentencias para acceder al CIF. En este caso, nos
estaríamos acercando a herramientas del tipo Query and Reporting.
Las herramientas Query and Reporting pueden ser de terceros o no, y poseen la capacidad de acceder a
estructuras de motores de base de datos de diferentes tipos y marcas, para realizar consultas complejas. En un
escalón adicional, encontramos a usuarios un poco más sofisticados en lo que a análisis respecta, y a los
cuales con sólo SQL o herramientas de Query and Reporting no les alcanza para sus análisis. Estos usuarios
manipulan otro tipo de herramientas, llamadas OLAP.
Las herramientas OLAP tienen la capacidad de acceder a diferentes tipos y marcas de bases de datos, como
así también, interpretan estructuras de metadatos. Muestran la información en términos familiares para el
usuario, es decir, términos del negocio u organización. Las herramientas OLAP son más flexibles que las de
reporting, especialmente por la característica de acceso a metadatos. La forma de navegación es más rica,
amigable e intuitiva. Como característica adicional, podemos decir que el usuario final, con este tipo de
herramientas, no necesariamente necesita conocer acerca de estructuras de sentencias SQL ni de bases de
datos. La misma herramienta ayuda al usuario a realizar las peticiones en forma gráfica y asistida.
Por otro lado, encontramos una cuarta forma de acceso a los datos del CIF. Estos análisis se caracterizan por
búsquedas en grandes bases de datos, búsquedas no convencionales que identifican relaciones y patrones
ocultos dentro de dichas base de datos. Estas relaciones representan conocimiento valuable para una
organización. Para ello, estos usuarios utilizan técnicas variadas tales como predicciones, estimaciones y
clasificaciones. Esta técnica de búsqueda de relaciones y patrones se denomina KDD (Knowledge Discovery
in Databases) o por muchos autores, simplemente Data Mining.
Básicamente, los distintos tipos de usuarios acceden de la siguiente forma a los datos:
Usuario Forma de Acceso Observaciones

Turistas SQL o Sentencias Conocen las estructuras de datos, por lo tanto les es mas útil la
Multidimensionales. misma herramienta de consultas del motor de base de datos o
algo similar.
Granjeros Query and Reporting Poseen un conjunto de consultas predefinidas y fijas que
pueden ajustarse bien a herramientas de este tipo.
Exploradores Query and Reporting Son usuarios que por su naturaleza necesitan herramientas
Herramientas OLAP totalmente flexibles y amigables como lo son las herramientas
OLAP o herramientas de Query and Reporting.
Mineros Herramientas OLAP Con las herramientas OLAP realizan el análisis preliminar de
KDD/Data Mining datos para su adecuación y la posterior aplicación de procesos
de minería.
44/69
Herramientas OLAP
OLAP (On Line Analytical Processing) es una categoría de software que, a través de una interfaz sencilla y ágil,
permite a analistas, administradores y ejecutivos analizar datos corporativos desde diferentes puntos de vista,
con niveles de granularidad y agregación variables, ya sean datos históricos o proyecciones y mostrando los
resultados en términos familiares al usuario, con el objeto de tomar decisiones.
La funcionalidad OLAP se caracteriza por los análisis de tipo multidimensional dinámico de datos consolidados
corporativos, soportando actividades analíticas y de navegación del usuario final. Este software ayuda al
usuario final a sintetizar información de la organización por medio de vistas personalizadas como así también
por medio del análisis de datos proyectados e históricos en variados escenarios.
OLAP es implementado en arquitecturas cliente/servidor y en ambientes multiusuario y ofrece rápida respuesta
a las consultas, ocultando el tamaño de la base de datos y su complejidad.
FASMI Test
¿Qué hace que un programa de software sea catalogado como OLAP ? En 1993, E. F. Codd & Associates,
publicaron un white paper comisionado por Arbor Software denominado “Providing OLAP (On Line Analytical
Processing ) to User-Analysts: An IT Mandate”. El Dr. Codd fue siempre muy bien considerado, como así
también, un respetado investigador de tecnología de base de datos desde los años 1960 y fue acreditado como
el creador del modelo de bases de datos relacionales. En este documento, el Dr. Codd enumeraba 12 reglas,
por las cuales una herramienta podía considerarse dentro de la categoría OLAP, sí y solo sí, cumplía con cada
una de ellas. Sin embargo, estas reglas fueron invalidadas por la mayoría de los investigadores ya que se
presumía que habían sido condicionadas por vendedores de software. Unos años mas tarde, en el año 1995,
Nigel Pendse reforzó las 12 reglas, agregando 6 reglas adicionales. A su vez, las reestructuró en cuatro grupos
llamándolos después “características”.
Así nace el “FASMI Test”, que se desprende de las siglas (Fast Analysis Shared Multidimensional Information).
FAST: Significa que la mayoría de los análisis que realiza el sistema, deben ser entregados dentro
de los 5 segundos; los análisis más simples, dentro del segundo y muy pocos, en más de 20
segundos.
Investigaciones independientes han mostrado que el sistema falla si los usuarios no han tenido
respuesta de sus peticiones dentro de los 30 segundos y que intentarían, pasado estos, presionar
las teclas “ALT+CTRL+DEL” mas allá de que el sistema los advirtió de que se iba a tomar su tiempo
para responder. De todos modos, si el usuario no hubiese, en este caso, tomado la decisión de
presionar el conjunto de teclas o bien cancelar la ejecución de la consulta, seguramente su cadena
de pensamiento se verá perjudicada y la calidad del análisis disminuiría. En la actualidad, las
respuestas lerdas a consultas son el problema principal de las herramientas OLAP actuales y
muchas de ellas no pasan este paso en el test.
ANALYSIS: Significa que el sistema se puede adaptar a una lógica de negocio y a análisis
estadísticos que son relevantes para la aplicación y para el usuario. Puede realizarse algún tipo de
preprogramación, pero no sería aceptable que fuera de la totalidad de las definiciones de la
aplicación. Es necesario permitir al usuario final que defina nuevos análisis no especificados con
anterioridad (Ad hoc) sin tener que programar. La aplicación debe incluir características especiales
tales como análisis de series de tiempo, ubicación de costos, cambios de monedas, búsqueda de
objetivos, modelado no procedural, alertas de excepciones, minería de datos y otras dependencias
de aplicaciones.
SHARED: Significa que el software implementa todos los mecanismos de seguridad necesarios
para los requerimientos de confidencialidad. No todas las aplicaciones permiten realizar escritura en
las bases de datos. Esta es el área de mayores conflictos de las herramientas OLAP de hoy y es por
ello que muchos productores de software asumen que deben ser read-only solamente.
MULTIDIMENSIONAL: Es el requerimiento clave, en donde el sistema debe proveer una vista
conceptual de los datos, incluyendo un amplio soporte de jerarquías y jerarquías múltiples. No
estamos determinando un mínimo de dimensiones que la aplicación debe soportar ni tampoco
definimos que tipo de servidor de base de datos deberán usar para soportar el enfoque
45/69
multidimensional.
INFORMATION: La información está compuesta por todos los datos y toda la información necesaria.
Se mide la capacidad de las aplicaciones en términos de la cantidad de datos de entrada que
pueden administrar , y no en cuantos gigabytes de datos pueden almacenar. Hay muchas
consideraciones aquí, incluyendo la duplicación de datos, memoria RAM requerida, utilización de
espacio en disco, performance, integración con el data warehouse y cómo las resuelve.
Características de las Herramientas OLAP

Características Básicas (B)
1. Vista conceptual multidimensional. (Regla Original 1)
Esta característica es una de las principales, pues es el corazón del OLAP. Las vistas de
información de la organización deberán ser conformadas por la conjunción de dimensiones
conceptuales de la misma. En este sentido, la herramienta debe proveer el soporte necesario para
que la información, y los datos, puedan ser representados en jerarquías simples y complejas.
2. Manipulación de datos intuitiva. (Regla original 10).
La manipulación y manejo de la información debe ser realizada en los mismos análisis, incluso en
las mismas celdas contenedoras de los datos sin la necesidad de recurrir a múltiples menúes para
realizar acciones.
3. Accesibilidad. (Regla Original 3)
En esta regla se describe a los motores OLAP como capas intermedias, accediendo a orígenes de
datos heterogéneos y un front-end OLAP. Hoy en día la mayoría de los productos pueden cumplir
con esta regla.
4. Extracción batch versus intuitiva. (Regla Nueva).
Esta regla especifica que las herramientas OLAP deben poseer accesos a sus propias bases de
datos OLAP, como así también acceso directo a datos externos. Muchas no lo realizan de forma
fácil o automática. Hoy en día se está haciendo popular el uso de arquitecturas híbridas en la cual
se accede a bases de datos multidimensionales pero al momento de buscar el detalle de dicha
información, la misma permite acceder a bases de datos relacionales externas.
5. Modelos de análisis OLAP. (Regla Nueva).
El Dr. Codd requirió que no solamente los productos deberían ser cliente/servidor, sino también que
el componente del servidor OLAP debería ser suficientemente inteligente como para que variados
clientes pudieran conectarse a este con esfuerzo o programación mínima.
6. Arquitectura cliente / servidor. (Regla Original 5).
Tecnología distribuida donde el procesamiento es dividido por funciones. El servidor realiza
funciones compartidas: administra la comunicación, provee servicios de bases de datos, etc. El
cliente realiza funciones específicas del usuario: provee interfaz customizable, realiza navegación
pantalla por pantalla, ofrece funciones de ayuda, etc.
7. Transparencia. (Regla Original 2).
Transparencia significa que un usuario podría estar viendo los datos directamente desde la
herramienta o bien desde una hoja de cálculos que posea una conexión con un servidor OLAP, pero
este usuario no debería saber, en definitiva, dónde residen los datos.
8. Soporte Multiusuario. (Regla Original 8).
El Dr. Codd reconoce que las aplicaciones OLAP deben proveer acceso concurrente, integridad y
seguridad. Recordemos que muchas aplicaciones OLAP poseen la posibilidad de realizar escrituras
sobre los motores de bases de datos. Este tipo de acciones deben ser tomadas en cuenta dentro
del soporte multiusuario.
Características especiales (S)
9. Tratamiento de datos no normalizados. (Regla Nueva)
Esta regla caracteriza el tratamiento e integración de los datos almacenados en el entorno OLAP y
el origen de datos denormalizado. El Dr. Codd especifica que cualquier cambio en los datos del
entorno OLAP no se debieran propagar al entorno transaccional.
46/69
10. Almacenamiento de resultados OLAP. (Regla Nueva)
Esto forma parte de una implementación más que una característica de una herramienta. Aquí se
hace referencia a que las aplicaciones OLAP que permiten la realización de escrituras hacia el
motor OLAP deben mantener estos datos separados de los datos transaccionales.
11. Extracción de datos perdidos. (Regla Nueva)
Todos los valores perdidos deben ser diferenciados de los valores cero. En este caso, siguiendo el
interés de almacenar datos en forma más compacta obvian estos datos sin ser incluidos dentro de
la base de datos.
12. Tratamientos de valores perdidos. (Regla Nueva)
Todos los valores perdidos deben ser omitidos por el analizador OLAP sin prestar atención a su
origen. Esta regla se relaciona con la anterior y es probablemente la más inevitable consecuencia
de cómo los motores multidimensionales tratan todos los datos.
Características de Reporting (R)
13. Reporting flexible. (Regla Original 11)
El Dr. Codd especifica que todas las dimensiones intervinientes dentro de un modelo, en una
herramienta OLAP, deben poder ser incluidas en cualquier análisis como así también en
combinación con las demás dimensiones. Esto es especificado dentro de las herramientas OLAP
pero no se especifica para los viewers.
14. Performance uniforme de reportes. (Regla Original 4)
El Dr. Codd especifica que la performance de los reportes no debe ser perjudicada por el
incremento de dimensiones o incremento en el tamaño de la Base de Datos. Sin embargo, en la
práctica, reportes con mayor contenido o mayores cálculos no previstos generalmente tardan mas
en la búsqueda de sus datos.
15. Ajuste automático del nivel físico. (Regla Original 7)
El Dr. Codd requiere que los sistemas OLAP ajusten el esquema físico automáticamente para
adaptarse al tipo de modelo, volumen de datos y esparcimiento del mismo. Es una regla difícil de
cumplir pero día a día se está desarrollando cada vez más.
Control de la Dimensión (D)
16. Dimensionalidad genérica. (Regla Original 6)

Codd define que cada dimensión debe ser equivalente en estructura y capacidades operacionales.
Sin embargo, especifica también que se permite asignar capacidades operacionales a alguna
dimensión.
17. Dimensiones y niveles de agregación ilimitadas. (Regla Original 12)
Técnicamente ningún producto puede cumplir con esta característica, ya que es imposible generar
infinitos elementos dentro de una computadora limitada. Sin embargo, no muchos modelos
necesitan mas de 10 o 15 dimensiones, menos aún, mas de 6 niveles de consolidación.
18. Operaciones entre dimensiones no restringidas. (Regla Original 9).
Todos los tipos de cálculos se deben poder realizar a través de todas las dimensiones. Esos tipos
de cálculos son importantes para realizar operaciones complejas.
Otros términos relativos a las herramientas OLAP
Dentro de las herramientas OLAP sentiremos nombrar en numerosas oportunidades el concepto de Cubo. Nos
referimos a un Cubo cuando hablamos de una estructura de celdas de datos agrupadas y ordenadas en filas y
columnas, cada una de estas representando una dimensión. A un array de tres dimensiones lo podemos
representar con un cubo, con cada dimensión formando un lado del cubo. Arreglos de más de tres dimensiones
no pueden ser representados con una metafórica física.
En esta definición hemos nombrado un nuevo término, Celda. Se entiende por Celda a un dato que ocurre en
la intersección de la selección de un miembro de cada dimensión en un cubo.
Dentro de las estructuras de cubos encontramos cubos del tipo Densos o cubos del tipo Comprimidos. Los
cubos densos son aquellos que poseen un alto porcentaje de posibles combinaciones de las dimensiones que
47/69
los componen con valor, y esta definición es opuesta a la de cubo esparcido. Decimos que un cubo es
comprimido si un alto porcentaje de las posibles combinaciones de los miembros de las dimensiones
contienen valores perdidos.
Definimos como miembro de una dimensión a un nombre discreto o identificador usado para distinguir una
posición de un ítem de dato y descripción dentro de una dimensión.
Por ejemplo, “Enero de 1989” o “1Trimestre1993” son ejemplos típicos de miembros de una
dimensión.
Como sinónimos podemos nombrar a Atributo, Ítem o Posición. Por consiguiente, una combinación de
miembros es una descripción exacta de una única celda en un array multidimensional, consistiendo de una
selección específica de miembros en cada dimensión. Es decir, es un sinónimo de Celda.
Cualquier miembro puede estar organizado, basados en una relación de padre- hijo, en donde el padre
representa la consolidación de o los miembros hijos. El resultado de esto es una jerarquía y la relación padre-
hijo es una relación jerárquica.
Por otro lado, se dicen que los miembros de una dimensión están en un mismo nivel jerárquico, si dentro de
esta jerarquía tienen el mismo máximo numero de descendientes en una ruta simple hacia abajo. De la misma
forma, si dos miembros poseen la misma cantidad máxima de antecesores, se dice que esos miembros son de
la misma generación.
Estas relaciones y jerarquías nos permiten, al momento de consultar la información, utilizar técnicas analíticas
para navegar a través de los niveles de datos, desde los mas detallados hacia los mas resumidos. Estás
técnicas se llaman Drill Up y Drill Down. La primera de ellas, es la usada para ir desde la sección mas
detallada hacia la mas resumida o consolidada (hacia arriba en la jerarquía). La segunda, nos permite navegar
al revés, es decir, desde la más resumida hacia la mas detallada (hacia abajo en la jerarquía).
Otra técnica muy usada es la de Slice. Con la técnica de slice, uno puede seleccionar para su análisis un
subconjunto del array multidimensional correspondiente a un valor simple de uno o más miembros de una
dimensión que no esté en el subconjunto.
Por ejemplo, si el miembro “actual” es seleccionado de la dimensión “escenarios”, el sub-cubo
formado por todas las dimensiones restantes es el slice.
El cambio de orientación de un reporte se denomina Rotación. La rotación consiste de intercambiar las filas y
las columnas o mover una fila de dimensión dentro de una columna de dimensión. Como sinónimo de este
termino podemos especificar el término Pivotear.
Una técnica muy útil es la que se denomina Reach Through. Esta técnica engloba la acción de extender la
accesibilidad de los datos al usuario final a un sistema transaccional,a través de consultas en el Data
Warehouse.
Existen productos de gran escala que presentan una simple y única estructura lógica, como así también usan
modelos sofisticados para comprimir datos. Estos generalmente permiten que se inserten valores de datos por
cada combinación de miembros de dimensiones, y todas las partes del espacio de datos tienen idéntica
dimensionalidad. A estos los llamamos hipercubos.
Por otro lado, un enfoque mucho mas común, es el uso de multicubos. En productos multicubos, el diseñador
de aplicaciones segmenta la base de datos en conjuntos de estructuras multidimensionales, cada una de las
cuales se compone de un subconjunto de numero promedio de dimensiones en la base de datos. Cada una de
estas estructuras se llama subcubos.
Subcategorías de OLAP
Existen tres subcategorías de OLAP, que se identifican por el tipo de almacenamiento que utilizan. Es obvio
que el tipo de almacenamiento afecta la performance de consulta. Las subcategorías son ROLAP, MOLAP y
HOLAP.
1. ROLAP
ROLAP (Relational OLAP) usa bases de datos relacionales en donde almacena las agregaciones de
los cubos. En contraste con el almacenamiento OLAP, no mantiene una copia de los datos base,
sino que provee acceso a una tabla base para poder buscar los mismos. Las respuestas de los
almacenamientos ROLAP son generalmente lerdas. Un uso particular de este tipo de
almacenamiento es para grandes volúmenes de datos que no se consultan frecuentemente , tales
como datos históricos.
48/69
2. MOLAP
MOLAP (Multidimensional OLAP) usa una estructura multidimensional que contiene agregaciones y
especificaciones de implementación propias del negocio. Provee el potencial de ser el tipo de
almacenamiento más rápido dentro de las estructuras OLAP. En general , este tipo de estructuras
es la más apropiada para cubos con alta frecuencia de uso y con necesidad de respuesta en tiempo
mínimo.
3. HOLAP (híbrido)
HOLAP (Hybrid OLAP) combina atributos del almacenamiento MOLAP y ROLAP. Los datos
agregados son almacenados en estructuras MOLAP y los datos base son almacenados dentro de
estructuras ROLAP. Los cubos almacenados en ambientes HOLAP son mucho menores que los
mismos cubos almacenados en estructuras MOLAP, y el tiempo de respuesta es mejor a los de
almacenamiento ROLAP para consultas que buscan datos sumarizados.
Características que diferencian a las herramientas OLAP

• Poseen la ventaja de que la información se presenta en términos familiares al usuario con
respecto a conceptos del negocio.
• Permiten representar las dimensiones de análisis de la empresa.
• El usuario final no requiere conocimientos sobre base de datos.
• Poseen capacidades de navegación sobre el mar de datos y las salidas de los análisis son
dinámicas y amigables, van mas allá de un simple listado.
• Poseen múltiples tipos de salidas: Tablas, Gráficos, Mapas, Reportes por Excepción, Mail,
Documentos y Planillas de Cálculo, Alertas, Termómetros y Semáforos.
• Poseen alta performance de recuperación de grandes volúmenes de información.
• Generalmente están preparados para soportar interfaces en la web.
• La administración de los datos depende únicamente del servidor OLAP .
• Poseen capacidades de administrar la seguridad en forma mas detallada.
• Permiten que el usuario final decida como y que tipo de información incluir en el reporte
haciendo este un proceso dinámico de consulta de información.
Este tipo de herramientas dan soporte a innumerables aplicaciones organizacionales, mejorando la toma de
decisiones basándose en análisis de información, más allá de la sola aplicación de la experiencia del decisor.
Entre otras actividades de las organizaciones en las cuales estas herramientas prestan su ayuda, podemos
nombrar:
✔ Marketing en General ✔ Consolidación Financiera

✔ Análisis de Ventas ✔ Administración en General
✔ Análisis de Sitios Web ✔ Sistemas de Información a Ejecutivos (EIS)
✔ Database Marketing ✔ Balanced Scorecards
✔ Análisis Presupuestario y Proyección ✔ Análisis de Rentabilidad
✔ Reportes Financieros en General. ✔ Gestión de la Calidad
Uso del CIF por medio de la minería de datos.

Recordemos que el minero examina metódicamente los datos buscando la confirmación de hipótesis o quizás
buscando nuevas hipótesis y una vez que ha encontrado el patrón, trata de explicarlo con sentido técnico y de
negocios. Este tipo de usuarios se vale de técnicas y métodos especiales para la realización de tal tarea.
Podemos englobar esta actividad dentro de lo que se denomina Knowledge Discovery in Databases, es decir
KDD.
El KDD es el proceso de extraer información válida, útil, desconocida y comprensible desde repositorios de
datos para utilizarla en la toma de decisiones de una organización. Al término de Data mining suele atribuírsele
en algunos escritos esta misma acepción.
Para nosotros, el Data Mining es la aplicación de las técnicas matemáticas, estadísticas y principalmente de
Inteligencia Artificial, para descubrir relaciones, patrones y tendencias ocultas en los datos almacenados por
49/69
una organización. Es la etapa de descubrimiento de un proceso de KDD.
En este punto debemos hacer una aclaración. Según lo que veníamos viendo en relación con las herramientas
OLAP, el usuario (el explorador, el turista, el granjero) las usaba para responder a preguntas que se formulaba
con el fin de justificar sus ideas. Estas acciones terminaban en consultas que eran lanzadas contra el servidor
OLAP y por último contra el servidor de bases de datos, con el fin de buscar la información adecuada que
respondiera a tales interrogantes. Llamaremos a estas acciones Chequeos de Hipótesis que son Conducidos
por la Verificación. Obviamente, estas acciones son comunes dentro del entorno OLAP, pero ahora, con la
llegada de los mineros, estamos entrando en un campo totalmente distinto, que llamaremos Descubrimiento
del Conocimiento.
Si analizamos las acciones que realizan los mineros, encontraremos que pretenden descubrir conocimiento sin
hipótesis previas o precondiciones. Se limitan a estudiar los datos existentes para hallar comportamiento,
patrones y/o tendencias ocultas con ellos. Acciones totalmente distintas a las de los exploradores, turistas y
granjeros que intentan explicar y/o confirmar una hipótesis planteada por un analista de antemano. Podemos
afirmar que el descubrimiento del conocimiento es conducido por el mismo descubrimiento.
Dentro del Descubrimiento del Conocimiento, encontramos que existen dos tipos de descubrimientos: Directo o
Indirecto.
El Descubrimiento Directo pretende explicar el comportamiento de una variable, denominada Objetivo, a
través del comportamiento de un conjunto de variables llamadas Descriptoras.
El Descubrimiento Indirecto pretende explicar el comportamiento simultáneo de un conjunto de variables y
explicar la relación que existe entre ellas.
Al día de hoy existen lo que se llaman funciones de minería que ayudan al minero a realizar las operaciones
sobre los datos en pos de la búsqueda de sus resultados. Son éstas funciones, acciones bien definidas a
utilizar con diferentes propósitos sobre los datos. Podemos nombrar aquí cinco funciones muy importantes en
la vida de un minero de datos, aunque no son las únicas existentes. Debemos aclarar que la utilización de una
de ellas sobre un conjunto de datos no implica que pueda ser usada otra de las funciones sobre el mismo
universo de datos, ni que sobre los resultados de una función, se utilice otra función que intente explicar los
resultados de la primera.
Estas cinco funciones son:
1. Asociación.
2. Segmentación.
3. Clasificación.
4. Patrones Secuenciales.
5. Secuencias de Tiempo Similares.
1. Asociación
La asociación es una técnica que utiliza el tipo de descubrimiento indirecto y se define como “Dada una
colección de ítems y un conjunto de registros, los cuales están contenidos en un número de ítems de la
colección dada, una función de asociación es una operación sobre este conjunto de registros la cual retorna la
afinidad o patrón que existe sobre colección de ítems”. Estos patrones pueden representarse con reglas como
“el 72% de todos los registros que contienen ítems A, B y C también contienen ítems D y E”.
2. Segmentación
Siendo la Segmentación una técnica del tipo de descubrimiento indirecto y siendo conocida también como
Clustering, se define como “El proceso de creación de particiones compuestas de miembros de una población
por la cual todos los miembros de esa partición son similares entre sí acorde a alguna métrica”. Un cluster es
un conjunto de objetos agrupados a través de su similitud o proximidad.
3. Clasificación
Cuando definimos el Descubrimiento Directo, dijimos que pretende explicar el comportamiento de una variable,
llamada Objetivo, a través del comportamiento de un conjunto de variables llamadas Descriptoras. Podemos
afirmar que la combinación de valores de las variables descriptoras sobre el valor predicho define una clase. El
proceso de descubrir conjuntos de valores de variables descriptoras para definir un valor de la variable objetivo,
se denomina Clasificación.
La salida de una clasificación es un conjunto de reglas en las cuales se definen los diferentes valores que las
variables descriptoras adoptan para cada uno de los valores que puede tomar una variable objetivo. Es válido
50/69
aclarar que previamente se debe definir cual es la variable objetivo y cuales las descriptoras dentro del
universo de datos.
4. Patrones Secuenciales
Esta técnica analiza un conjunto de registros de un período de tiempo con el objetivo de identificar tendencias.
Con esta técnica podemos identificar que secuencia de eventos o secuencia de registros ocurren relacionados
con una entidad.
Por ejemplo, podremos analizar un conjunto de registros pertenecientes a clientes. Cada registro
posee la misma estructura y se relaciona por el identificador del cliente. En este universo de
registros se podrían ver las diferentes compras de diferentes clientes. Una técnica de patrones
secuenciales podría analizar este conjunto de registros y detectar entre ellos patrones similares de
compra de productos. Un patrón secuencial de ejemplo podría ser el ser de compras que
preceden a la compra de un Horno Microondas.
Con relación a los Patrones Secuenciales podemos definir que las Secuencias de Tiempos Similares tratan de
identificar cada cuanto tiempo ocurren las secuencias encontradas por la técnica de Patrones Secuenciales.
Estas técnicas son usadas dentro de la etapa de minería en un proceso de KDD. Como vemos, la minería de
datos es una de las etapas dentro de un conjunto de etapas que son:
1. Análisis del Problema.
2. Análisis de Datos.
3. Selección de Datos.
4. Preparación de Datos.
5. Minería de Datos.
6. Interpretación de Resultados.
7. Aplicación del Conocimiento obtenido.
El Análisis de Problema es la tarea de entender lo que se quiere encontrar o que objetivo perseguimos con la
ejecución de un proceso de KDD. Es entender en términos organizacionales qué significan cada una de las
partes que componen el problema.
Luego de realizar el análisis del problema, se emprende lo que se llama el Análisis de Datos, que hace
referencia a la búsqueda de las diferentes variables que intervendrán dentro del proceso de KDD. Esta etapa
sólo se interesa en la identificación y no en la selección de los datos en la base de datos, ya que esto lo realiza
la etapa de Selección de Datos.
La Selección de Datos, toma como entrada la definición de las variables conformadas en la etapa de Análisis
de Datos. Dentro de la selección de datos, se definen los algoritmos y procesos a ejecutar sobre la base de
datos para obtener el conjunto de registros con los valores de cada una de las variables buscadas. Una vez
obtenidos los registros, estos conformaran el universo de datos a los cuales se le ejecutarán las funciones de
minería previa Preparación de Datos.
La Preparación de datos consiste de procesos que se denominan Limpieza, Enriquecimiento y Codificación.
La limpieza de datos se usa para corregir desvíos y errores de integridad que pudieran ocurrir en las variables y
en la relación entre ellas. Es necesario tener un entendimiento real y preciso sobre cada una de ellas para
poder detectar cuales son los errores y desvíos. En segundo lugar, el enriquecimiento se refiere a la
transformación de los datos para un mejor entendimiento como así también la creación de datos a partir de las
variables fuentes.
Un ejemplo podría ser el caso de la fecha de nacimiento de los clientes. En este caso, sería muy
conveniente, y contendría mas información, crear una variable con la edad que se deriva de esta
fecha de nacimiento.
Por último la codificación se refiere al proceso de transformar los valores de las variables a valores acordes a
las funciones de minería a ejecutar. Las funciones de minería utilizan procesos estadísticos específicos y
basados en la Ingeniería Artificial los cuales necesitan, en ciertos casos, que las variables adopten valores
específicos o dentro de rangos específicos para que estos puedan ser interpretados. En fin, la codificación es la
adecuación de las variables de entrada a las funciones de minería.
En la etapa siguiente, se procede con la Minería de Datos en donde se realiza la ejecución de las funciones
sobre los datos fuentes. Dentro de esta etapa podemos realizar tareas complementarias a la función de minería
de datos, tales como:
✔ Análisis preliminar utilizando herramientas de consulta de datos.
51/69
✔ Análisis preliminar utilizando funciones estadísticas.
✔ Análisis preliminar utilizando herramientas OLAP
✔ Aplicación de la técnica de minería propiamente dicha.
Existen diferentes modos de minería de datos, y ellos son Entrenamiento, Prueba y Aplicación/Producción.
a. Entrenamiento: Es la ejecución de la función de minería basándose en datos históricos y con los cuales
se construye el modelo de minería.
b. Prueba: se refiere al testeo del o los modelos construidos en el entrenamiento utilizando como entrada
un conjunto de datos históricos con resultados conocidos. La calidad del o los modelos estará dada por
la cantidad de ocurrencias de los resultados arrojados por el modelo y los resultados reales del
conjunto de datos, sobre la cantidad de datos total.
c. Aplicación / Producción: Es la implementación de los modelos creados sobre conjuntos de datos con
resultados desconocidos.
Previa a la aplicación de los modelos se debe pasar por la etapa de Interpretación de Resultados la cual se
refiere a la realización de un análisis exhaustivo de los resultados obtenidos, tratando de transformarlos en
términos de negocios u organizacionales. Es aquí en donde el conocimiento obtenido por el proceso es
asimilado en términos organizacionales.
Interpretados los resultados, la siguiente etapa dentro de este proceso de KDD es la aplicación de los mismos,
es decir, la Aplicación del Conocimiento obtenido con el fin de obtener los beneficios que este proceso
brinda.
En el mercado actual existen variadas herramientas, las cuales incluyen diferentes técnicas de minería como
las que hemos visto. Estos aspectos, la cantidad y tipos de técnicas que incluye, podrían ser variables fuertes
al momento de tomar la decisión de utilizar o no dicha herramienta. Por otro lado existen otras características
que no debemos dejar de lado, como son:
• La posibilidad de hacer la selección y preparación de los datos en la herramienta misma.
• La existencia de funciones de limpieza y transformación de los datos.
• La existencia de funciones estadísticas para el análisis de los datos.
• La existencia de diferentes tipos y formatos de visualización de los resultados obtenidos por las
diferentes técnicas de minería.
• La existencia de utilidades de almacenamiento de los resultados arrojados por las funciones de
minería, como así también herramientas de almacenamiento del conocimiento e interpretaciones
obtenidas a través de los resultados .
Unidad 7: Metodología de desarrollo

Desde este ítem nos concentraremos en adquirir los conocimientos que nos permitan comprender los pasos a
seguir para la construcción de un data warehouse, involucrando e integrando los conceptos de los capítulos
previos de manera de establecer los lineamientos para desarrollar un proyecto de data warehouse.
Metodología de desarrollo: estableceremos las pautas generales para la confección de un data warehouse, de
manera de aplicar los conceptos previamente adquiridos. La metodología de desarrollo está compuesta por
etapas que se describen a continuación.
Etapas para el desarrollo de un Data Warehouse
Son similares a las etapas del ciclo de vida de desarrollo del software. Las identificamos a continuación:
3. Planificación
4. Determinación de requerimientos
5. Construcción de la BDD
6. Diseño físico
7. Mapeo de datos y transformación
8. Extracción de datos y carga
9. Desarrollo de aplicaciones
10. Validación de datos
52/69
11. Entrenamiento
En lo que respecta a esta unidad, se hará un especial énfasis en los temas no comprendidos en las unidades
previas, ampliando fundamentalmente los conceptos de las dos primeras: planificación y determinación de
requerimientos.
1. Planificación
1.1 Seleccionar la Estrategia de Implementación
• Top down:
Se utiliza cuando están identificados los requerimientos del negocio para la solución propuesta de
data warehouse, y los problemas del negocio a resolver están claramente comprendidos.
Se la recomienda para los siguientes escenarios:
◦ Cuando la organización que lo implementa está familiarizada con la tecnología.
◦ Cuando los ejecutivos, quienes toman decisiones e inversores tienen una clara visión de los
objetivos del data warehouse.
◦ Cuando los ejecutivos, quienes toman decisiones e inversores tienen en claro dónde ubicar
el data warehouse en su estructura organizacional como una herramienta para toma de
decisiones.
◦ Cuando los ejecutivos, quienes toman decisiones e inversores tienen en claro que el data
warehouse es un subproceso de un proceso de negocio existente.
• Bottom up:
Generalmente comienza con experimentos y prototipos basados en tecnología. Se selecciona un
subconjunto específico de problemas del negocio y se formula una solución para el mismo.
Normalmente esta solución es más rápida. Permite evaluar la tecnología cuando ésta no está aún
madura y antes de efectuar compromisos mayores. Normalmente utilizada para la implementación
de un data mart, un pequeño EIS, o un warehouse departamental orientado a responder unas pocas
preguntas de un dominio específico, como contabilidad, análisis de mercado o gestión de producto.
Se la recomienda para los siguientes escenarios:
◦ Cuando la tecnología de implementación es novedosa.
◦ Cuando la organización no posee aún una tecnología de data warehouse.
◦ Cuando la organización está evaluando tecnología y experimentando costos y tiempos de
implementación.
◦ Cuando existen objetivos poco claros.
• Combinación de ambas: una organización puede explotar los beneficios de planificación que otorga
la metodología top down, con la implementación rápida y oportuna de la bottom up.
Recomendada cuando:
◦ La organización que implementa el warehouse tiene personal experimentado en tecnología.
◦ La organización tiene un equipo de proyecto comprometido que tiene claro el objetivo de
dónde aplicar la tecnología de data warehouse.
1.2 Seleccionar la Metodología de Desarrollo

• Metodología de análisis y diseño estructurado (cascada) : Útil para requerimiento claros y bien
especificados
• Metodología de desarrollo en espiral . Útil para velocidad de desarrollo y entrega con conocimiento
de que los requerimientos no pueden ser claramente identificados. Este es el método más usado.
1.3 Definir Alcance del Proyecto

Para ello necesitamos desarrollar una lista de objetivos del negocio que el sistema debe cumplimentar. Para
planificar los objetivos del data warehouse debemos responder las siguientes preguntas:
• ¿Cuáles son los usuarios potenciales para el data warehouse?
Las personas con una alta percepción de sus necesidades tendrán un valor percibido superior para
los servicios de data warehouse.
• ¿Cuál es la plataforma actual o futura?
Debe dimensionarse la plataforma en cuanto a servidores, estaciones de trabajo del cliente, diseño
53/69
de interfaz gráfica de usuario (GUI) y motores de bases de datos (comunicaciones, RDBMS)
• ¿Cuál es el plan en términos de características y funciones?
Es el valor percibido por los usuarios finales para cada característica. Estas características y
funciones están dentro de las siguientes categorías:
◦ Las que son visibles y pueden ser usadas por usuarios finales externos al data warehouse.
◦ Las que no son visibles externamente, pero deben ser implementadas dentro del data
warehouse para desarrollar sus capacidades.
• ¿Cuáles son los distintos orígenes de datos que pueden y/o deben integrarse dentro del data
warehouse?
Hay que tener en cuenta esto, dadas sus implicancias tecnológicas por la dificultad de la extracción
de datos de distintas bases de datos, así como de orígenes externos de datos.
• ¿Cuándo debería estar operacional el data warehouse?
Existen distintos factores para determinar este momento: la competencia está usando tecnología de
data warehouse destinada a los clientes importantes y desarrollo de nuevos servicios. Un
departamento, dentro de la organización, no puede desarrollar sus funciones por no disponibilidad
de información clave respecto a clientes y datos históricos.
Definir el alcance de la implementación inicial

La mayoría de los proyectos de data warehouse de las organizaciones tienen como motivación principal una
primera implementación rápida que brinde beneficios inmediatos para un grupo de usuarios. Después de haber
definido un conjunto de objetivos para el data warehouse, es necesario delimitar el alcance para esta primera
implementación.
Existen distintas dimensiones que permiten restringir el alcance de un proyecto de data warehouse:
• Cantidad y tipo de departamentos servidos: quiénes y con qué propósito usarán el data warehouse.
• Número y tipo de orígenes de datos: para ello es importante el desarrollo de consultas de negocio
que deben responderse inicialmente. La selección inicial de orígenes de datos y su número tienen
una gran influencia en la entrega de una implementación a tiempo. Se debe tener en cuenta la
calidad de los datos de los orígenes seleccionados, dado que sino es buena puede significar
retrasos en la implementación hasta que se efectúen los cambios.
• Subconjunto del modelo de la empresa seleccionado: delimitar la cantidad de consultas que
efectivamente requieren efectuar “drill-down” y sólo cuando es requerido, y gestionar registros
sumarizados antes que detallados, son técnicas para restringir el alcance de la implementación
inicial.
La existencia de documentación, diccionarios de datos, repositorios, catálogos y modelo de datos
(herramientas CASE) de las bases de datos que participarán en el proyecto favorece la velocidad de
implementación.
1.4 Definir Tareas y Recursos
1.5 Definición de Tiempos y Presupuestos del Proyecto
La planificación de tiempos y presupuesto del proyecto puede realizarse por medio de dos aproximaciones:
• Estimación de tiempos y costos basados en la historia organizacional de desarrollo de software:
pueden asignarse porcentajes a las fases del ciclo de vida basados en hechos pasados.
• Estimación de tiempos y costos basados en la arquitectura de referencia: cada componente de la
arquitectura de referencia (orígenes de datos, data warehouse, data marts, herramientas de acceso
del usuario final, administración de datos y metadatos, transformación e infraestructura) puede
descomponerse en subcomponentes y presupuestarse separadamente.
1.6 Definiciones Técnicas (Escenarios de uso del Negocio, Metadatos)
A continuación se brindará una serie de definiciones que ayudarán a comprender la temática. Como el data
warehouse es una extensión de la arquitectura de datos organizacional, es importante tener en cuenta la
plataforma existente en cuanto a la capacitación de los recursos técnicos escasos: programadores, DBAs.
Definición de la arquitectura para el proyecto: usar copias de los datos operacionales o un
almacenamiento operacional (ODS), sólo data warehouse, sólo data mart, data warehouse y data marts,
54/69
arquitectura en dos capas (cliente/ servidor) o tres capas.
Definir escenarios de uso: son importantes como una herramienta de prototipos; para ello se necesita
contar con tres características: un usuario del negocio claramente identificado con un rol bien definido,
un área funcional que sea sponsor del proyecto y lo use cuando esté disponible, una o más consultas del
negocio de interés relevante para el área funcional que actualmente no sea satisfecho por los sistemas
de información existentes.
2. Determinación de Requerimientos
En esta fase se pretende precisar las especificaciones para las funciones que serán efectuadas por el data
warehouse. Deben describir el ambiente operacional en el que será entregado el data warehouse. Pueden
llamarse requerimientos a las expectativas del sistema que tienen los participantes del proyecto (propietarios,
arquitectos, desarrolladores y usuarios finales).
2.1 Relevamiento a Usuarios:
Desde el punto de vista del propietario (inversor) deberían responderse las siguientes preguntas:
- ¿Por qué se está construyendo un data warehouse o data mart?
- ¿A qué problema del negocio está dirigido?
- ¿Cuáles son los objetivos del negocio?
- ¿Quiénes son los participantes? ¿Quién es el cliente? ¿Quién el sponsor?
- ¿Cuánto costará?
- ¿Cuándo estará listo?
- ¿Cuál es el impacto en la gente/organización?
- ¿Tenemos conocimientos para hacerlo?
- ¿Cuáles son los riesgos?
Respondiendo a estas preguntas, obtendremos los requerimientos que formarán un criterio de aceptación
desde la perspectiva del propietario.
Algunos aspectos que potencialmente brindarán requerimientos son :
- Objetivos del negocio
- Objetivos del data warehouse/data mart, cliente y participantes.
- Orígenes de datos
- Planes, como presupuestos, cronogramas y recursos
- Impacto en inversiones actuales, como ser personal, tecnología y entrenamiento.
Parte de los requerimientos del negocio serán también especificaciones del alcance del DW en términos de lo
siguiente:
• Áreas involucradas:
La selección cuidadosa de áreas involucradas puede contener el alcance de la implementación del
data warehouse, maximizando su utilidad.
Por ejemplo, el departamento de marketing puede tener interés en alguno de los siguientes tópicos:
estudio de mercado, análisis de competitividad, comportamiento de los proveedores, segmentación
del mercado para el producto, decisiones de precio y presupuesto, decisiones de producto,
decisiones de canales, proyección de tendencias, etc. Entonces, el análisis de campo de las áreas
de interés involucradas para el departamento de marketing puede dar como resultado áreas de:
órdenes, promociones, mercados, ventas, ciclo de tiempo.
• Granularidad:
Se refiere al nivel de detalle de la información requerida y tiene una relación directa con las
actividades de sumarización a realizarse con los datos. A menor granularidad, mayor nivel de
detalle. Los datos operacionales tienden a estar en el menor nivel de granularidad. Para incrementar
el nivel de granularidad, los datos deben sumarizarse posteriormente.
Generalmente se requerirá mayor cantidad de procesamiento para sumarizar y convertir los datos
operacionales para obtener una mayor granularidad, pero también a mayor granularidad los datos
necesitan menor cantidad de almacenamiento y pueden consultarse rápida y convenientemente. La
sumarización debe realizarse cada vez que se refresca el data warehouse de los orígenes de datos.
Como conclusión, podemos decir que a un incremento de la granularidad, crecerá la utilidad para los
altos niveles de toma de decisión, disminuirá el volumen de datos e incrementará el procesamiento.
55/69
Algunos ejemplos de granularidad en consultas de negocio son: ¿Cuál es el beneficio por región en
los últimos seis trimestres (no el beneficio diario por región)?, o bien ¿Cuáles son los nombres de
los diez primeros productos por región por volumen de ventas (no el volumen de ventas actual)?
• Dimensiones:
Los data warehouses organizan un gran almacén de datos operacionales e históricos usando una
categorización de múltiples dimensiones. Los datos se agrupan acorde a un rango temporal para
responder consultas de negocio que requieren, por ejemplo, ventas de un producto específico en el
último trimestre. Las dimensiones más comunes que se usan en consultas de negocio son: tiempo,
grupos de cliente, familias de producto, geográfica (dimensión), estructura organizacional.
Una jerarquía de la dimensión geográfica sería, por ejemplo: representante de ventas, localidad,
provincia, región del país, país, corporación.
• Requerimientos del arquitecto:
Es la persona responsable de determinar los distintos componentes del data warehouse para
soportar necesidades actuales y futuras. El esfuerzo invertido en arquitectura determinará:
1. El rango de funciones y características ofrecidas.
2. Las plataformas necesarias para la implementación.
3. El uso de estándares e interfaces abiertas.
4. Flexibilidad para incorporar mejoras.
Los arquitectos deben compilar un conjunto de requerimientos concordantes con la visión del
propietario así como también un conjunto de requerimientos que reflejen la implementación
tecnológica. Para ello se deben determinar tres componentes importantes de la arquitectura:
◦ La arquitectura de datos se puede desarrollar identificando los elementos de datos y metadatos
◦ La arquitectura de aplicación se puede desarrollar listando las aplicaciones y sus características
y funciones.
◦ La arquitectura de tecnología se desarrolla listando las selecciones para cada nivel y cada
componente del data warehouse.
• Requerimientos del desarrollador:
Si la visión del arquitecto del data warehouse es abstracta, la del desarrollador debe ser concreta.
Los requerimientos del desarrollador están cercanos a la arquitectura de implementación. Requiere
que las arquitecturas de datos, aplicación y tecnología que desarrolló el arquitecto se transformen
en aplicaciones específicas, interfaces, computadoras, bases de datos, comunicaciones y pantallas
de interfaz con el usuario.
• Requerimientos de tecnología:
Se necesitan orígenes de datos y metadatos, extracción de datos y metadatos, almacenamientos de
datos, administración de datos, redes y comunicaciones, un ambiente de procesamiento y
producción, gestión del flujo de trabajo y estándares.
El data warehouse/ data mart necesita refinamiento y reingeniería de la organización de datos,
redes y comunicaciones, un ambiente de procesamiento y producción, almacén de datos y
metadatos, catálogo de metadatos, gestión del flujo de trabajo y estándares.
Respecto a las herramientas del usuario final, se necesita middleware para acceso y devolución de
datos, almacenamiento local, ambiente de datos multidimensional, herramientas para reporte y
navegación de metadatos, estándares, herramientas para usuarios del negocio para efectuar
análisis y reportes, modelado del negocio, data mining, navegación de datos y OLAP .
• Requerimientos de distribución:
Se relacionan con la capacidad del data warehouse para proveer acceso a información distribuida
oportuna y convenientemente. El data warehouse debe proveer una variedad de métodos de acceso
para herramientas del usuario final y aplicaciones especializadas de data warehouse. También debe
proveer un rango de caminos de conexión desde dial-up usando una laptop, hasta estaciones de
trabajo conectadas en una LAN.
Se consideran importantes los siguientes requerimientos para un desarrollo efectivo del data
warehouse:
◦ Métodos de acceso
56/69
◦ Métodos de entrega
◦ Herramientas de acceso
◦ Requerimientos de conectividad
◦ Requerimientos de la plataforma cliente.
• Requerimientos para efectividad en producción del data warehouse:
Un sistema de data warehouse se convierte en un sistema de producción cuando es de misión
crítica y se usa frecuentemente para decisiones operacionales y estratégicas.
Se relacionan principalmente con la gestión de disponibilidad, mantenimiento de consistencia y
exactitud en la información, rendimiento y crecimiento de datos, definición de políticas y
procedimientos para actualización y mantenimiento tanto de los datos del data warehouse como de
sus metadatos, provisión de control de acceso y procedimientos de seguridad. Algunos de estos
requerimientos son:
◦ Mantenimiento de información consistente, confiable y actualizada.
◦ Gestión de metadatos y meta modelos del data warehouse.
◦ Aseguramiento de que los mecanismos de transporte, bases de datos, computadoras y
mecanismos de comunicaciones están levantados y disponibles todo el tiempo.
◦ Provisión inmediata de soporte técnico y help desk para asistencia a usuarios cuando el
sistema está caído.
◦ Provisión de seguridad de acceso y políticas y procedimientos de autenticación.
◦ Gestión del tamaño de las BD usadas por el data warehouse, que incluye selección de
niveles múltiples de almacenamiento en múltiples medios (discos ópticos, torres de discos,
discos duros, etc.). En grandes proyectos de data warehouse este costo llega a alcanzar un
50% del presupuesto de hardware.
◦ Mejoramiento del tiempo de respuesta.

◦ Requerimientos del usuario final: El usuario final ve al data warehouse como una gran caja
negra, cuyo principal acceso es a través de herramientas y aplicaciones para consulta y
reportes, por medio de una especie de mapa de la información almacenada dentro del data
warehouse. Los requerimientos de usuario pueden caer en algunas de las siguientes
categorías:
▪ Workflow: cómo se acomoda la funcionalidad ofrecida por el data warehouse al flujo de
trabajo del usuario final.
▪ Requerimientos de consulta: los requerimientos de consulta permiten capturar ejemplos
de consultas de negocio definidas en terminología del usuario final.
Ejemplos:
Departamento de Ventas: Selección de personal: ¿Cuál representante de ventas tiene la
menor cantidad de clientes y cuál tiene los mejores registros de clientes? Análisis de
órdenes: ¿Cuál es nuestro origen de órdenes individual y más grande en Navidad?
Atención al cliente: ¿Cuáles son nuestros clientes más importantes este año?, ¿Cuáles
el año pasado?, ¿Por qué nos dejaron algunos clientes este año? Benchmarking: ¿Cuál
región ha estado realizando el mejor trabajo en forma continuada durante los últimos 6
trimestres? Gestión de Producto: ¿Cuáles son los 10 principales productos vendidos en
mi región en los últimos 4 trimestres?
Departamento de Marketing: Producto: ¿Cuáles son los 10 principales productos que
anduvieron bien el año pasado? ¿Y este año? Análisis de promociones: ¿Cuán bien
anduvieron las promociones de este año comparadas a las del año pasado? ¿Cuáles
productos anduvieron bien en las promociones? ¿Cuáles promociones debemos
discontinuar? Opciones de envío: ¿Cuáles son los métodos de envío más populares?
¿Cuál deberíamos dejar de usar? Cambios demográficos: ¿Cómo se relacionan los
cambios demográficos con los cambios en el consumo de productos? Posicionamiento
de mercado: ¿Cuáles son los mercados que debemos dominar este año? ¿Cuáles
dominamos el año pasado? ¿Cuáles son nuestros competidores en estos mercados?
Departamento de Distribución: puede estar enfocado internamente en gestión de costos
y tener consultas que son completamente operacionales por su naturaleza: Análisis
57/69
operacional: ¿Cuáles son nuestros dos principales métodos de envío este año? ¿Y el
año anterior? ¿Qué destinos deberíamos estandarizar? ¿Cuáles eliminar? Operaciones:
¿Cuáles son nuestros métodos de envío más costosos? ¿Cuál es el método que deja
menor margen de ganancias? ¿Cuáles son nuestros 10 principales destinos? ¿Cuán
cercanos están geográficamente? Clientes: ¿Cuáles son las preferencias de nuestros
clientes respecto a los métodos de envío?
▪ Requerimientos de reportes: Cada usuario final descripto previamente tiene diversos
requerimientos de reportes, por ejemplo:
¿Cuáles fueron las ventas trimestrales para cada localidad y región para los 8 últimos
trimestres? ¿Cuáles fueron las ventas por línea de producto para cada localidad para los
últimos 24 meses (solo respecto a los meses de cambio de estación)?¿Cuál es el gasto
mensual en promociones y publicidad por medio de comunicación en los últimos dos
años? ¿Cuál fue el presupuesto trimestral para cada agencia para los últimos cuatro
trimestres? ¿Cuáles son los montos de venta mensual de productos por línea de
producto para cada localidad en los últimos 24 meses? ¿Envíos mensuales de
productos por método de envío y destino para los últimos 12 meses? Para cada gran
cliente, ¿cuáles son los envíos por semana en el último trimestre?
Los usuarios finales también pueden especificar requerimientos a cumplimentar por las
consultas de datos; por ejemplo:
▪ Acceso rápido, buena manipulación y muy buena presentación.
▪ Responder a las necesidades de variedad de usuarios.
▪ Permitir a los usuarios crear sus propias consultas usando términos del negocio que
ellos conocen y ofrecer una estructura de datos consistente.
▪ Drill-down sin necesidad de re-acceder.
▪ Requerimiento mínimo de entrenamiento y soporte.
▪ Soportar el hardware, software y DBMS del warehouse actual.
▪ También pueden especificar los tipos de análisis de datos que desean realizar sobre los
datos después de que son devueltos del data warehouse. Por ejemplo:
Tipos de Actividades
Slice and dice: ítems de datos separados de distintas formas.
Drill-down: exponer progresivamente mayor nivel de detalle.
Data mining: buscar patrones de datos ocultos
Datasurfing: mostrar de manera indirecta.
Bajar y realizar modificaciones locales.
Crear modelos del negocio, por ejemplo usando hojas de cálculo.
Vista de datos:
Bidimensional –hojas de cálculo–, relacional.
Multi-dimensional.
Reportes y gráficos.
2.2 Documentación de Resultados

Deben documentarse los resultados del relevamiento.
2.3 Modelo de datos de la Base de Datos Operacional

Debe obtenerse el modelo de datos operacional de manera de lograr un conocimiento acabado de la estructura
de los datos que intervienen en el proyecto.
2.4 Significado de los Atributos

Es necesario conocer el significado de los atributos del modelo de datos para facilitar el desarrollo de las
siguientes etapas.
3 - Construcción de la BDD (ver capítulos 3, 5 y 6)

Como primer paso, se requiere efectuar la conversión de los requerimientos en un conjunto de especificaciones
que permitan soportar el diseño. Existen tres especificaciones principales para el data warehouse:
58/69
1. Requerimientos con foco en el negocio: delinean los límites de información que debe abarcar el
data warehouse.
2. Requerimientos de orígenes de datos: marcan los límites de información disponible desde los
orígenes actuales de datos.
3. Especificaciones de requerimientos de acceso y del usuario final: definen cómo deberá ser
usada la información del data warehouse; también el tipo de herramientas y técnicas que usan.
Una vez analizados y comprendidos los requerimientos, se puede continuar con las siguientes actividades :
• Confeccionar el modelo de la Base de Datos Decisional, que debe cumplir los requerimientos
enunciados.
• Determinación de atributos del modelo determinado previamente (métricas, referenciales,
descriptivos).
• Tipo de estructura.
• Tablas de lookup
4. Diseño físico (ver unidad 3)
En esta etapa, el modelo lógico determinado precedentemente debe convertirse a un modelo físico. Aquí se
definen los diseños para los programas que realizarán las tareas requeridas por los procesos.
• Determinación de sumarizaciones.
• Determinación de particionamiento.
• Determinación de índices.
• Denormalización.
5. Mapeo de datos y transformación (ver capítulos IV y V)

• Definición de datos fuentes.
• Desarrollo de especificaciones.
• Estudio de tiempos.
• Programación de aplicaciones.
6. Extracción de datos y carga (ver capítulo IV)

• Desarrollo de procedimientos.
• Extracción de datos.
• Carga a la bdd.
• Pruebas.
7. Desarrollo de aplicaciones
• Desarrollo de reportes predefinidos.
• Prueba de reportes.
• Aplicación de herramientas DSS.
• Documentación.
8. Validación de datos
• Validaciones de totales.
• Validaciones de sumarizaciones.
• Validaciones con reportes.
• Validaciones de consistencia.
9. Entrenamiento
• Diseño de programas de entrenamiento.
• Diseño de procedimientos para soporte a usuarios.
• Marketing interno.
• Entrenamiento a operadores.
59/69
Glosario
ALERTAS: Una notificación de un evento que ha excedido un límite preestablecido.
BASE DE DATOS
BASE DE DATOS OPERACIONAL: La base de datos operacional contiene el origen de los datos
para un data warehouse. Este contiene datos detallados usados para ejecutar las operaciones del
día a día del negocio. Los datos continuamente cambian y reflejan el estado actual de la última
transacción.
BASE DE DATOS RELACIONAL: Un sistema de base de datos que soporta un completo rango de
SQL estándar.
RDBMS: Sistema de administración de bases de datos relacionales.
OPTIMIZADOR BASADO EN COSTO: El software en una base de datos relacional que
intenta determinar cómo procesar la consulta asignando costos estimados a varias
alternativas diferentes.
BASE DE DATOS MULTIDIMENSIONAL (MDBMS): Una poderosa base de datos que permite a los
usuarios analizar grandes cantidades de datos. Un MDBMS captura y presenta los datos en arrays
que pueden ser ordenados en múltiples dimensiones.
DBA: Data Base Administrator. Administrador de base de datos.
DISEÑO FÍSICO: El paso de diseño de bases de datos, seguido al diseño lógico que identifica las
estructuras de las tablas de la base de datos actual y la estructura de los índices usados para
implementar el diseño lógico. Comparar con “Diseño lógico”.
DISEÑO LÓGICO: La fase del diseño de base de datos que trata de identificar las relaciones entre
los elementos de datos. Comparar con “Diseño físico”.
CUBO (CUBO DE DATOS): Un nombre para una base de datos dimensional.
BUSINESS INTELLIGENCE (BI): Conocimiento obtenido acerca de un negocio por medio del uso de distintas
tecnologías de hardware / software, las cuales habilitan a las organizaciones a transformar datos en
información.
DICCIONARIO DE DATOS: Una base de datos acerca de la estructura de los datos y de las bases de datos.
Un catálogo de todos los elementos de datos, conteniendo sus nombres, estructuras e información acerca de
su uso.
CATÁLOGO: Un componente de un diccionario de datos que contiene un directorio de los objetos
de un DBMS, como así también atributos de cada objeto.
CLAVE
CLAVE PRIMARIA: Un campo o combinación de campos de una tabla de base de datos que
identifica unívocamente cada uno de los registros de dicha tabla.
CLAVE FORÁNEA: Una clave foránea es una clave primaria de una estructura de datos que está
ubicada en otra estructura de datos, con el fin de establecer una relación entre esas dos estructuras.
Las claves foráneas resuelven las relaciones y dan soporte a la navegación a través de las
estructuras.
CLAVE COMPUESTA: Una clave de una tabla de base de datos, compuesta de varios campos.
Igual que “Clave concatenada”.
CLAVE CONCATENADA: Ver “Clave compuesta”.
CLIENTE / SERVIDOR: Una tecnología distribuida en donde el procesamiento es dividido por funciones. El
servidor realiza funciones compartidas: administra la comunicación, provee servicios de bases de datos, etc. El
cliente realiza funciones específicas del usuario: provee interfaz customizable, realiza navegación pantalla por
60/69
pantalla, ofrece funciones de ayuda, etc.
SERVER: Servidor. Un servicio que provee funciones estándares para clientes con respuestas a
mensajes estándares desde los clientes. Una definición comúnmente usada de servidor es para
referirse a la computadora física desde la cual los servicios son proveídos.
CLIENTE: Un programa de software usado para contactar y obtener datos desde un programa de
software servidor en otra computadora. Cada programa cliente es diseñado para trabajar con uno o
más programas servidores específicos.
CLIENTE OLAP: Aplicación de usuario final que puede realizar slices desde servidores
OLAP y provee visualización bi-dimensional o multi-dimensional, selecciones, rankings,
cálculos, etc., para propósitos de visualización y navegación. Los clientes OLAP pueden
ser tan simples como planillas de cálculos.
DATA MART: Un subconjunto de datos, usualmente orientado a un propósito específico, que puede ser
distribuido para soportar las necesidades del negocio.
ODS: Operational Data Store. Es una base de datos integrada de datos operacionales. Un ODS puede
contener 30 o 60 días de información histórica, mientras que un data warehouse contiene años de datos.
DATA WAREHOUSE: Una copia de los datos transaccionales especialmente estructurada para consulta y
análisis. Una implementación de una base de datos para información, usada para almacenar orígenes de datos
compartidos de una base de datos operacional.
ARQUITECTURA DE UN DATA WAREHOUSE: Un integrado conjunto de productos que habilitan
la extracción y transformación de datos operacionales para ser cargados en una base de datos,
para análisis de los usuarios finales y para reporting.
DATA WAREHOUSE DIMENSIONAL: Un conjunto de bases de datos para el soporte de las
decisiones, diseñado con un modelo dimensional.
ENTERPRISE DATA WAREHOUSE (EDW): Data Warehouse Empresarial. Data Warehouse
centralizado que sirve de apoyo a la empresa en forma completa.
WAREHOUSE CENTRAL: Una base de datos creada de extracciones operacionales que
conforman un modelo de datos simple, consistente y empresarial, que asegura consistencia en los
datos de soporte de decisiones a través de la corporación. Un estilo de tecnología en donde todos
los sistemas de información son ubicados y administrados desde una locación física simple y
centralizada
DDW: Dimensional Data Warehouse. Data Warehouse dimensional.
DWA: Data Warehouse Administrator. El administrador del Data Warehouse.
INTEGRIDAD REFERENCIAL: Una condición mandatoria en un data warehouse, en donde todas
las claves en las tablas de hechos son legítimas claves foráneas relativas a las tablas de
dimensiones.
TIEMPO DE RESPUESTA DE UNA CONSULTA: El tiempo que un motor de data warehouse se
toma para procesar una consulta compleja a través de grandes volúmenes de datos hasta que
retorna los resultados de la misma.
FILTRO: Conjunto almacenado de criterios elegidos para la selección de un subconjunto de
información en un data warehouse.
MOTOR DE UN DATA WAREHOUSE: RDBMS y MDBMS. Los motores de bases de datos
requieren de fuertes capacidades de consulta, mecanismos de carga de datos rápida y
requerimientos de alto almacenamiento.
METADATOS: Cualquier dato mantenido como soporte de las operaciones de uso del data
warehouse. Los metadatos son los datos acerca de los datos. Como ejemplos pueden incluirse
descripciones de los elementos de datos, descripciones de los tipos de datos, descripciones de las
61/69
propiedades y los atributos, descripciones de los dominios y rangos, etc.
SLICE Y DICE: La descripción estándar de la habilidad de acceder al data warehouse por medio de
cualquiera de las dimensiones. Un término usado para describir un análisis complejo de datos
provisto por un MDBMS.
DATO: Ítem que representan hechos, texto, gráficos, imágenes, sonido, segmentos de vídeo digital o análogo.
Los datos son la materia prima de los sistemas y son usados por los consumidores de información para crear
información.
DATOS ADMINISTRATIVOS: En una data warehouse, los datos que ayudan a un administrador de
data warehouse a administrar el almacén de datos.
DATOS AGREGADOS: Datos que son el resultado de la aplicación de un proceso de combinar
elementos de datos. Datos que son tomados en forma colectiva o en forma resumida.
DATOS DEL NEGOCIO: Información acerca de la gente, lugares, cosas, reglas de negocio y
eventos, los cuales son usados para operar el negocio.
DATA MINING: Una técnica que usa herramientas de software orientada a usuarios que no
conocen exactamente qué es lo que están buscando. Data Mining es el proceso de búsqueda a
través de una extensa cantidad de datos para producir relaciones entre ellos. Este puede predecir
tendencias y comportamientos futuros, permitiendo al negocio realizar decisiones pro activas y
dirigidas por el conocimiento.
PARTICIONAMIENTO DE DATOS: El proceso de particionamiento físico o lógico de los datos en
segmentos que son mas fácilmente mantenidos o accedidos. Los sistemas de RDBMS actuales
proveen este tipo de funcionalidad. El particionamiento de los datos ayuda a la performance de
consulta.
REDUNDANCIA: El almacenamiento de múltiples copias de un dato idéntico.
MAPEO DE DATOS: El proceso de asignar un elemento de datos origen con un elemento de datos
destino.
GRANULARIDAD: Grado de sumarización o resumen de los datos.
VISUALIZACIÓN DE DATOS: Técnicas para transformar datos en información usando la alta
capacidad del cerebro humano para reconocer visualmente patrones y tendencias.
INFORMACIÓN: Dato que ha sido procesado, el cual incrementa el conocimiento de la persona que
lo recibe. La información es la salida de los sistemas de información.
DIMENSIÓN: Una entidad independiente en un modelo de una organización que sirve como un punto de
entrada, o como un mecanismo de corte de las métricas aditivas de una organización.
DIMENSIÓN DEGENERADA: Una clave de dimensión que no tiene atributos, y por consiguiente no
tiene una tabla de dimensión.
SNOWFLAKE: Una dimensión normalizada en donde una dimensión plana simple es descompuesta
en una estructura de árbol con posibles niveles. Los modelos snowflakes generalmente
comprometen el entendimiento del usuario y la performance de visualización.
TABLA DE DIMENSIÓN: Una tabla en el esquema dimensional.
ATRIBUTO: Un campo en una tabla de dimensión.
MULTIDIMENSIONAL: Estructura de datos con tres o más dimensiones independientes.
RELACIONES JERÁRQUICAS: Un miembro de dimensión puede estar organizado basado en
relaciones padre-hijo, típicamente en donde el miembro padre representa la consolidación del
miembro hijo. El resultado es una jerarquía, y la relación padre-hijo da cuenta de las relaciones
jerárquicas.
RELACIONES MUCHO A MUCHO: Una relación de datos lógica en la cual los valores
62/69
de uno de los elementos de datos pueden existir en combinación con muchos valores de
otros elementos de datos, y viceversa.
RELACIONES UNA A MUCHOS: Una relación de datos lógica en la cual el valor de un
elemento de datos puede existir en combinación con muchos valores de otros elementos
de datos, pero no viceversa.
DRILL ACROSS: El hecho de analizar datos desde una dimensión hacia otra dimensión, para
cambiar el enfoque de la misma.
DRILL DOWN: El hecho de reemplazar o agregar en un análisis un nuevo atributo de dimensión,
con el fin de detallar el mismo dentro de una misma dimensión.
DRILL UP: El hecho de remover un atributo de dimensión o reemplazar el mismo por otro atributo
de dimensión, con el fin de agrupar la información contenida en la misma, dentro de una misma
dimensión.
ESQUEMA: Una representación diagramática de la estructura de algo. Esta es la definición lógica y física de
los elementos de datos, características físicas e interrelaciones.
ESQUEMA DE BASE DE DATOS: La definición lógica y física de la estructura de la base de datos.
ESQUEMA ESTRELLA: Es un conjunto de tablas compuesto por una simple y central tabla de
hechos seguida por dimensiones denormalizadas. Cada dimensión es representada por una simple
tabla. El esquema estrella implementa estructura de datos dimensionales con dimensiones
denormalizadas. Los datos son almacenados en una tabla central de hechos y una o más tablas que
almacenan la información de cada dimensión. Las dimensiones tienen niveles y cada uno de estos
niveles son representados por columnas en cada tabla de dimensión.
ESQUEMA SNOWFLAKE: Es un conjunto de tablas compuesto por una simple y central tabla de
hechos seguida por normalizadas estructuras de tablas que forman las dimensiones compuestas
por jerarquías. Cada nivel de dimensión es representado en una tabla. Los esquemas snowflakes
implementan estructuras de datos dimensionales con dimensiones completamente normalizadas.
ETL: Extract, transform and load. Extraer, transformar y cargar datos.

EXTRACCIÓN DE DATOS: El proceso de copiado de datos desde el sistema transaccional, con el
fin de cargarlos en un sistema de data warehouse.
SOFTWARE DE EXTRACCIÓN DE DATOS: Software que lee uno o más orígenes de
datos para crear una nueva imagen de dichos datos.
SOFTWARE DE ADMINISTRACIÓN DE DATOS: Software que convierte los datos en
un formato unificado, tomando datos derivados para crear campos nuevos, unir archivos,
resumir y filtrar datos. El proceso de lectura de datos desde sistemas operacionales.
También se lo llama “Software de Extracción de Datos”.
ASEGURAMIENTO DE LA CALIDAD DE DATOS: El paso durante el proceso de
extracción de datos, en donde estos son testeados en consistencia, completitud y
aptitud, para ser publicados hacia el usuario final.
TRANSFORMACIÓN DE DATOS: Creación de la información a través de los datos. Esto incluye
decodificación de los datos de producción y unificación de los registros de múltiples formatos de
DBMS. Esto es también conocido como Data Cleaning.
CARGA DE DATOS DE PRODUCCIÓN: El proceso completo de extracción de datos de producción
desde las aplicaciones operacionales, transformándolos, cargándolos e indexándolos, asegurando
calidad y publicación.
GUI: Graphical User Interface. Interfaz gráfica de usuario. Un estilo de interfaz de computadoras caracterizado
por ventanas, iconos, gráficos y el uso de dispositivos de punteros.
HECHO: Una métrica, típicamente numérica o aditiva, que es almacenada en una tabla de hechos.
63/69
HECHOS ADITIVOS: Métricas en la tabla de hechos que están disponibles para ser sumarizadas a
través de todas las dimensiones.
HECHOS NO ADITIVOS: Un hecho que no puede ser sumarizado lógicamente entre registros.
Puede ser numérico o no. Si no es numérico, puede ser usado solamente en restricciones,
agrupaciones o conteos.
HECHOS SEMIADITIVOS: Un hecho numérico que puede ser adicionado o sumarizado a través de
algunas dimensiones de la tabla de hechos, pero no por otras.
SNAPSHOT: Un conjunto de tablas de hechos que representan el estado de las cuentas al final de
cada período de tiempo. Snapshots diarios y mensuales son muy comunes.
HERRAMIENTAS
HERRAMIENTA BACK END: Una aplicación de software, típicamente ubicada en el cliente y en el
servidor, que asiste en el proceso de extracción de datos. Comparar con “Herramienta FRONT
END”.
HERRAMIENTA FRONT END: Una herramienta cliente que recorre o manipula los datos
almacenados en una base de datos relacional. Comparar con “Herramienta BACK END”.
HERRAMIENTA DE ACCESO A LOS DATOS: una herramienta de usuario final que permite la
construcción de consultas sql.
HERRAMIENTA DE CONSULTA: una herramienta cliente que mantiene una sesión con el dbms,
enviando pequeños grupos de sentencias sql, y recibiendo pequeños conjuntos de resultados a
tales consultas.
HERRAMIENTA DE CONSULTA AD-HOC: una herramienta de usuario final que acepta
acciones point-and-click para construir una consulta ad-hoc que devuelva el resultado
esperado.
LENGUAJE DE CONSULTA MULTIDIMENSIONAL: Un lenguaje computarizado que permite especificar qué

datos recuperar de un cubo de datos. El proceso de usuario para este tipo de consulta es usualmente llamado
slicing y dicing. El resultado de una consulta multidimensional es un nuevo cubo de datos.
MODELOS
MODELO DE DATOS: Un mapa lógico que representa las propiedades inherentes de los datos
independientes de las consideraciones de hardware, software o performance de las máquinas. El
modelo muestra los elementos de datos agrupados en registros, como así también las asociaciones
de esos registros.
MODELADO DE DATOS: Un método usado para definir y analizar los requerimientos de datos
necesarios para soportar las funciones de negocios de una empresa. Esos requerimientos de datos
son almacenados como un modelo de datos conceptual con definiciones de datos asociadas. El
modelo de datos define las relaciones entre los elementos de datos y las estructuras.
MODELO DE NEGOCIO: Una vista del negocio en un determinado punto en el tiempo. La vista
puede ser pasada, presente o futura.
MODELO DIMENSIONAL: Una metodología de diseño top-down, que para cada proceso de
negocio enumera las dimensiones y los hechos relevantes.
MODELO ENTIDAD RELACIÓN: Un modelo de datos de una organización, el cual es representado
por objetos entidades y objetos relaciones entre dichas entidades.
NORMALIZAR: El proceso de remover redundancia en los datos, separándolos en múltiples tablas. Es el

proceso de reducir una estructura de datos compleja en otra simple y más estable.
DENORMALIZAR: Permitir redundancia en una tabla.
ODBC: Open Database Connectivity. Conectividad abierta de bases de datos. Un estándar para el acceso a las
64/69
bases de datos adoptado por Microsoft.
OLAP: On Line Analytic Processing. Procesamiento analítico en línea. Un término que contrasta con el término
OLTP. OLAP es un conjunto definido de principios que provee un marco dimensional para el soporte de
decisiones. Es el procesamiento que soporta el análisis de las tendencias y proyecciones del negocio.
ROLAP: Relational OLAP Un producto que provee análisis multidimensional de los datos,
agregados y metadatos almacenados en un RDBMS. El procesamiento multidimensional puede ser
hecho dentro de un RDBMS, un servidor de capa intermedia o un cliente.
HOLAP: Hybrid OLAP OLAP híbrido. Un producto que puede proveer análisis multidimensional
simultáneamente de datos almacenados en una base de datos multidimensional y en un RDBMS.
OLTP: On Line Transaction Processing. La descripción original para todas las actividades y sistemas asociados
con la carga de datos dentro de las bases de datos, en un entorno de procesamiento de transacciones.
SEMAFORIZACIÓN: Una técnica que usa círculos coloreados para identificar el contenido de un elemento de
dato. Los colores son definidos por un conjunto de límites predefinidos.
SISTEMA
SISTEMA DE INFORMACIÓN EJECUTIVA (SIE): Herramienta programada para proveer reportes o
libros de información resumida hacia los ejecutivos de los niveles más altos. Estos ofrecen reportes
de indicadores estáticos.
SISTEMA DE SOPORTE DE DECISIÓN (DSS): Software que soporta el reporte por excepción,
reporte en base a semáforos, con repositorios estándares, análisis de datos y análisis basados en
reglas. Una base de datos creada para procesamiento de consultas ad-hoc para usuarios finales.
SOPORTE A LAS DECISIONES: La actividad de usar los datos para tomar decisiones
en una organización.
SISTEMA OPERACIONAL: Un sistema que almacena los datos de las operaciones de una
compañía.
SQL: El lenguaje de consulta estándar para acceso a bases de datos relacionales.

CONSULTA (QUERY): Una sentencia SQL suministrada por la aplicación front end hacia el DBMS
relacional.
CONSULTA AD-HOC: Cualquier consulta que no puede ser determinada en forma
previa al momento en que la consulta es suministrada. Una consulta que consiste en
SQLs estructurados dinámicamente y que es usualmente construida por una herramienta
de consulta.
JOIN: Junta. Una operación realizada en las tablas de datos de un RDBMS, en la cual los datos de
dos tablas son combinados en una tabla unida detallada y mayor.
CLÁUSULA FROM: La cláusula SQL que lista todas las tablas intervinientes en una consulta.
CLÁUSULA GROUP BY: La cláusula SQL que lista los hechos no agregados en la lista SELECT.
CLÁUSULA ORDER BY: La cláusula SQL que determina el ordenamiento de las filas en el set de
resultados de la consulta.
SINÓNIMO: Una sentencia SQL que crea una copia lógica de una tabla que puede ser usada
separadamente en una sentencia SQL.
RESTRICCIÓN: Una frase en una cláusula WHERE de una sentencia SQL.
RESTRICCIÓN DE JOIN: Una porción de la cláusula WHERE que establece la relación
de junta entre la tabla de hechos y una o más tablas de dimensiones.
SELECT DISTINCT: Una sentencia SQL que elimina registros duplicados en el resultado de una
consulta.
65/69
HECHOS AGREGADOS (SQL): Los ítems en una lista de la sentencia SQL SELECT que participan
con una función SUM, COUNT, MIN, MAX y AVG.
TABLA DE HECHOS o TABLA BASE: La tabla central de un esquema dimensional, caracterizado por una
clave compuesta en donde cada uno de los elementos de dicha clave son claves foráneas a una tabla de
dimensión.
TABLA DE HECHOS SIN HECHOS: Tabla de hechos en donde no intervienen hechos.
TABLA DE SEGUIMIENTO DE EVENTOS: Una tabla de hechos en donde las dimensiones de las
tablas definen una descripción de un evento.
TABLA SUMARIZADA: Tablas creadas por medio del uso de las dimensiones comúnmente accedidas para
proveer velocidad en el tiempo de respuesta de las consultas. Estas tablas incrementan la redundancia de los
datos almacenados en el data warehouse.
AGREGADOS o SUMARIZADOS: Resúmenes precalculados y prealmacenados que son
guardados en el data warehouse para implementar mejoras de performance en las consultas.
66/69
Identificación de los componentes del Corporate Information Factory (CIF)
La dirección de una empresa de comercialización al por menor de productos alimenticios, con sucursales en
variadas regiones, ha incorporado tecnología a su planta administrativa con el objetivo de mejorar la toma de
decisiones a nivel gerencial y ejecutivo.
La incorporación de la mencionada tecnología se basa en los siguientes elementos:
• Herramientas de captura de datos en servidores con aplicaciones transaccionales (ubicación:
Sucursales).
• Servidores de comunicación entre sucursales y casa matriz (ubicación: Sucursales y Casa
Matriz).
• Líneas de enlaces digitales entre sucursales y casa matriz.
• Servidor de residencia temporal de los datos colectados desde sucursales (ubicación: Casa
Matriz).
• Servidor de base de datos relacionales con capacidad ampliada (ubicación: Casa Matriz).
• Herramientas de transformación y carga de datos.
• Programación de stored procedures y procesos de actualización de modelos de EDW.
• Herramienta de explotación de modelos decisionales.
• Herramientas de monitoreo de performance de consultas.
• Servidores de backups como almacenamientos secundarios.
• Herramientas de extracción y consulta de datos con fines operativos.
El Departamento de Tecnología ha ideado esta implementación sin tener en cuenta el concepto de Corporate
Information Factory.
a) Como consultor de esta organización, esquematice estos elementos dentro del marco del CIF. El
resultado final deberá contener un esquema de la arquitectura de implementación adecuada al CIF.
67/69
b) Aconseje la incorporación de elementos extras no planteados en la arquitectura inicial, que mejoren

el proceso de toma de decisiones de los usuarios antes mencionados.
• Construcción de data marts acotados a cada área de análisis de la organización.
• Incorporación de data mining y exploration warehouse con finalidad de análisis estadísticos e
identificación de patrones de comportamiento de nuestros clientes, ocultos a las consultas de
información tradicional.
• Incorporación de aplicaciones analíticas del tipo de Business Intelligence con finalidad de
descubrir diseños de negocios adaptables a las necesidades de los clientes, empleados y
ejecutivos.
c) En el caso de haber integrado herramientas de minería de datos, ¿qué funciones aplicaría y qué
resultados posibles se obtendrían con dicha incorporación en organizaciones de este rubro?
En el caso de incorporar herramientas de minería de datos (data mining) utilizaríamos las siguientes funciones
68/69
con los consiguientes resultados:
• Asociación: que identifique canastas de productos de venta en transacciones atómicas.
Ejemplo: en el 80% de los casos, cuando se venden productos de copetín, se venden en la
misma transacción latas de cerveza.
• Segmentación: que identifique grupos de personas (clientes) que poseen patrones de conducta
similares ante la compra.
Ejemplo: dos grupos de clientes, los compradores de productos bajas calorías y los compradores
de productos tradicionales.
• Clasificación: que identifique las características de los clientes que poseen patrones de
conducta similares.
Ejemplo: Luego de identificar los dos grupos de clientes después de la segmentación, la
clasificación arrojaría las reglas más relevantes sobre las variables analizadas que identifiquen a
cada grupo.
Grupo 1: clientes de baja edad de sexo femenino, Grupo 2: resto de los clientes.
• Patrones secuenciales: que identifique cómo se suceden las compras a través del tiempo como
modas en los consumos.
Ejemplo: Año x: caracterizado por la compra de artículos de limpieza de alta calidad. Año n+1:
caracterizado por la compra de artículos de bazar de calidad media y artículos de vidrio.
• Secuencia de patrones secuenciales: que identifique el rango de tiempo en el cual un patrón
secuencial se repite.
Ejemplo: siguiendo con el ejemplo próximo anterior, el mismo se produce cada 10 años.
d) Identifique los tipos de usuarios destinados a explotar esa estructura.
• Operativos: en la utilización del ODS
• Exploradores: en la utilización de los modelos decisionales
• Mineros: en la utilización de las herramientas de minería
69/69

SSDG - Sistemas de soporte de decisión en grupo

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SSDG - Sistemas de soporte de decisión en grupo

Diunggah oleh

Hak Cipta:

Format Tersedia

SSD – Resumen Examen Final UBP - Mayo 2013

Módulo 1: Sistemas de soporte de dirección

Unidad 1: Introducción a los sistemas de soporte de dirección

Antiguamente, se consideraba la toma de decisiones como un arte, basado en la creatividad, intuición y

Factor Tendencia Resultado

SIG - Sistemas de Información Gerencial (1960)

SSD - Sistemas de Soporte de Decisión (1970-1980)

SE - Sistemas Expertos (1980-1990)

SIE - Sistemas de Información Ejecutivos (Executive Information System en inglés) (1990)

Diferencias entre SSD y SIE

Redes Neuronales Artificiales (1990)

Características de los Sistemas y evolución cronológica

Unidad 2: El proceso de toma de decisiones y los SSD

Proceso de toma de decisiones

• Paso A: Determinación de cuál es el problema. Encontrar el problema involucra la colección de

Fases involucradas en el proceso de toma de decisiones.

En resumen, la fase de inteligencia puede involucrar otras actividades como:

Usando este modelo, se puede encontrar el valor

Ejemplo: uso de las

5. Predecir las salidas de cada alternativa

6. Medición de las salidas.

Módulo 2: Modelado multidimensional

Unidad 3: Modelado multidimensional

Figura: Cubo dimensional para la combinación de

En el modelo multidimensional cada eje corresponde a

Componentes del modelo multidimensional

Ejemplo: Proceso de Negocio: datos completos de las ventas al por menor.

América. Argentina. Córdoba. Capital. Cap. Córdoba Capital. 5000.

6. Tabla de Hechos o Fact Table

7. Tabla de Dimensión o look-up table

2. Esquema Copo de Nieve (Snowflake Schema).

3. Mixto (Mixed Schema).

4. Constelación (Constellation o MultiStar).

Diseño de una base de datos multidimensional

1. Identificar los hechos.

2. Analizar las dimensiones, elementos y jerarquías que las conforman

Dimensión Elemento Atributos

2. Medidas aditivas, semiaditivas y no

Técnicas/Herramientas para mejorar la performance

Inconvenientes de las tablas agregadas

1. Operaciones en un Data Warehouse

2. Evolución del Warehouse

Transformación de Datos y Metadatos

Estructura de datos en el data warehouse (periodicidad)

Proceso para efectuar un desarrollo para ETL.

3. Modelo genérico de un repositorio de metadatos (ejemplo)

Modelo Lógico y Físico del Data Warehouse

Source Column que alimentan de información el DW.

Statistics metodología y de los productos ETL utilizados por la organización.

Estadísticas de Consulta Áreas del negocio

Módulo 3: Gerenciamiento de los sistemas de información

Unidad 5: Corporate Information Factory

• Convierte datos. • Verifica el rango de dominio de los datos.

Características Esenciales de un Data Warehouse

El tiempo variante se muestra de varias maneras:

F. ODS (Operation Data Store)

Turistas Exploradores Granjeros

Usuario Forma de Acceso Observaciones

Características de las Herramientas OLAP

Control de la Dimensión (D)

16. Dimensionalidad genérica. (Regla Original 6)

Otros términos relativos a las herramientas OLAP

Características que diferencian a las herramientas OLAP