Material de estudio para la asignatura Sistema de Soporte de Decisión de la carrera Licenciatura en Informática de la Universidad Blas Pascal (Córdoba - Argentina)

1. SanPi-SSD
Módulo 1: Sistemas de soporte de dirección........................................................................................4
INTRODUCCIÓN A LOS SISTEMAS DE SOPORTE DE DIRECCIÓN..................................... 4
1.Sistemas de Información Gerencial (SIG).................................................................................5
2.Sistemas de Soporte de Decisión (SSD)....................................................................................5
3.Sistemas de Soporte de Decisión en Grupo (SSDG).................................................................6
4.Sistemas de Información Ejecutivos (SIE, o EIS en inglés)..................................................... 6
5.Sistemas Expertos (SE)............................................................................................................. 6
6.Redes Neuronales Artificiales................................................................................................... 6
7.Evolución cronológica de los sistemas y sus características:....................................................7
Proceso de toma de decisiones......................................................................................................... 8
1.El proceso está compuesto por varias fases...............................................................................9
Componentes de los sistemas de soporte de decisiones................................................................. 13
Módulo 2: MODELADO MULTIDIMENSIONAL.......................................................................... 16
¿Qué es un modelo?........................................................................................................................16
1.Modelado de datos...................................................................................................................16
Modelo entidad - relación...............................................................................................................16
Modelado multidimensional...........................................................................................................16
1.Componentes del modelo multidimensional........................................................................... 18
Diseño de una base de datos multidimensional..............................................................................21
Conceptos avanzados de modelado multidimensional................................................................... 24
1.Tabla de hechos que representan eventos................................................................................24
2.Medidas aditivas, semiaditivas y no aditivas.......................................................................... 24
3.Dimensiones sucias y degeneradas y mini-dimensión............................................................ 25
4.Cambios en dimensiones y soluciones de tipo I, II y III......................................................... 26
5.Periodos de tiempo continuos..................................................................................................26
Herramientas para mejorar la performance.................................................................................... 27
1.Tablas agregadas......................................................................................................................27
2.Tablas fragmentadas................................................................................................................ 28
Administración y Actualización..................................................................................................... 29
1.Operaciones en un Data Warehouse........................................................................................ 29
Evolución del Warehouse............................................................................................................... 30
1.Transformación de datos y metadatos..................................................................................... 31
Metadatos....................................................................................................................................... 35
1.Tipos de metadatos:................................................................................................................. 37
Módulo 3: Gerenciamiento de los sistemas de información...............................................................41
CORPORATE INFORMATION FACTORY..................................................................................... 41
1.Objetivos de un Data Warehouse.............................................................................................43
Evolución de un data warehouse:...................................................................................................43
Características esenciales:.............................................................................................................. 43
1.Orientado a Temas .................................................................................................................. 44
2.Integración ..............................................................................................................................45
3.De Tiempo Variante ................................................................................................................46
4.No Volátil ................................................................................................................................47
OLTP vs. DSS:................................................................................................................................48
1.El Data Mart............................................................................................................................ 50
2.Análisis estadísticos. ...............................................................................................................50
3.Exploration Warehouse............................................................................................................50
4.Data Mining Warehouse.......................................................................................................... 51
5.Los almacenamientos alternativos...........................................................................................51
6.Los metadatos..........................................................................................................................51
Explotación del Corporate Information Factory.............................................................................52
Definición del el término OLAP.....................................................................................................55
1.Descripción de cada una de las características:.......................................................................56
SSD - 1/83

2. SanPi-SSD
Etapas para la construcción de un data warehouse.........................................................................62
1.Planificación............................................................................................................................63
2.Determinación de requerimientos............................................................................................65
3.Construcción de la BDD .........................................................................................................68
4.Diseño físico ...........................................................................................................................69
5.Mapeo de datos y transformación ...........................................................................................69
6.Extracción de datos y carga ....................................................................................................69
7.Desarrollo de aplicaciones.......................................................................................................69
8.Validación de datos..................................................................................................................69
9.Entrenamiento..........................................................................................................................69
1.g l o s a r i o............................................................................................................................. 70
SSD - 2/83

3. SanPi-SSD
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. Componentes. Diferencias entre sistemas de información ejecutivos, sistemas de soporte
de decisión y sistemas de soporte de decisión en grupos. Concepto de sistema de soporte de
decisión. Evolución de los sistemas de soporte de decisión.
Unidad 2: El proceso de toma de decisiones y los sistemas de soporte de decisión
Fases involucradas en el proceso de toma de decisiones. Fase de inteligencia, diseño, elección e
implementación. Aporte de los sistemas de soporte de decisión a las distintas fases de proceso de
toma de decisiones. Subsistemas involucrados: subsistema de manejo de datos, subsistema de
manejo de modelos, subsistema de conocimiento y subsistema de interfaz de usuario. Concepto y
características de cada uno.
Módulo 2: Modelado multidimensional
Unidad 3: Modelado multidimensional
Concepto. Características y beneficios. Componentes: dimensiones, atributos, hechos, métricas,
tabla base, tabla de dimensión. Tipos de diseños: estrella, copo de nieve y mixtos. Indexación.
Esquemas de sumarización. Particionamiento. Dimensiones de gran tamaño. Dimensiones con
cambios en el tiempo. Principios de diseño.
Unidad 4: Administración
Esquemas de traspaso de datos de los sistemas OLTP a los sistemas OLAP. Actualización del Data
Warehouse. Metadatos.
Módulo 3: Gerenciamiento de los sistemas de información
Unidad 5: Corporate Information Factory
Concepto. Tipos de estructuras de datos. Componentes. Arquitectura. Sistemas OLTP.
Características de la información. OLTP vs. DSS. EDW. Data Mart. ODS. Exploration Warehouse.
Data Mining Warehouse.
Unidad 6: Explotación
Tipos de usuarios. Herramientas de Query & Reporting. Herramientas OLAP. Tipos de OLAP.
Reglas de OLAP. Motores OLAP. Data Mining. Verificación de hipótesis vs. descubrimiento de
conocimiento. Aplicaciones, operaciones y técnicas. Segmentación. Clasificación. Asociaciones.
Patrones secuenciales.
Unidad 7: Metodología de desarrollo
Concepto. Distintas alternativas. Etapas en el ciclo de desarrollo. Descripción de cada una de las
etapas involucradas. Construcción del equipo de desarrollo. Construcción de prototipos. Entrevistas.
http://www.devoo.net/Introduccion_al_Soporte_de_Decisione.pdf
http://www.ongei.gob.pe/publica/metodologias/Lib5084/INDEX.HTM
http://www.sqlmax.com/dataw1.asp
http://www.programatium.com/manuales/sql/gen005.htm
http://www.information-management.com/infodirect/20010105/2954-1.html
http://www.willydev.net/descargas/prev/ElABCDW.PDF
SSD - 3/83

4. SanPi-SSD
Módulo 1: Sistemas de soporte de dirección
INTRODUCCIÓN A LOS SISTEMAS DE SOPORTE DE DIRECCIÓN
Los ‘Sistemas de Soporte de Dirección’ se brindan a través de tecnologías computarizadas, tienen
como objetivo brindar soporte al quehacer gerencial y al proceso de toma de decisiones, que en
general son las tecnologías computarizadas avanzadas y emergentes, para brindar soporte a las
soluciones de los problemas de los directivos.
Estas tecnologías están cambiando la estructura organizacional, facilitando la reingeniería de
procesos de negocio y cambiando los métodos gerenciales.
Los sistemas de soporte de dirección que explicaremos son los siguientes:
• Sistemas de información gerencial
• Sistemas de soporte de decisión
• Sistemas de soporte de decisión en grupo
• Sistemas de información ejecutivos
• Sistemas expertos
• Redes neuronales artificiales
Como se puede ver, los ‘Sistemas de Soporte de Decisión’ constituyen una de las tecnologías
computarizadas de los ‘Sistemas de Soporte de Dirección’.
Para comenzar, debemos comprender el concepto de dirección, a fin de identificar el ámbito de
aplicación de los sistemas de dirección.
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.
El éxito es medido como la relación entre las entradas y las salidas, es decir la productividad.
Productividad = Salidas
Entradas
El nivel de la productividad depende de la ejecución de funciones del directivo, tales 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” (Stoner).
Antiguamente, se consideraba la toma de decisiones como un arte, basado en 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. En el cuadro analizaremos los factores que producen el cambio:
Factor Tendencia Resultado
Tecnología Creciendo Más alternativas para elegir
Informática/ Computac. Creciendo
Estructura compleja Creciendo Grandes costos de cometer
Competencia Creciendo errores
Mercados internacionales Creciendo Mayor incertidumbre respecto
Estabilidad política Decreciendo al futuro
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.
SSD - 4/83

5. SanPi-SSD
1. Sistemas de Información Gerencial (SIG)
Un SIG es un sistema formal basado en computadoras, con el objetivo de recuperar, extraer e
integrar datos de varias fuentes para proveer la información necesaria para la toma de decisiones
gerenciales.
Características:
• Tiene su mayor potencial en proveer información para la toma de decisiones rutinarias
simples, repetitivas y anticipadas.
• No es exitoso para las decisiones en situaciones complejas.
• Es el primero de los sistemas de información existentes para la toma de decisiones rutinaria,
estructurada y anticipada.
• No posee capacidades de modelado.
• No es fácil de utilizar por los usuarios gerenciales.
• No provee interfaz amigable.
2. Sistemas de Soporte de Decisión (SSD)
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 fáciles interfaces de usuarios. En un modo
sofisticado incluye también el desarrollo de modelos.
¿Por qué se usa?
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 a 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
• Administrador de datos: Contiene la base de datos decisional y el DBMS.
SSD - 5/83

6. SanPi-SSD
• Administrador de modelos: Conjunto de modelos cualitativos y cuantitativos y el software
apropiado para su construcción.
• Administrador de diálogo: Provee la interfaz con el usuario.
• Administrador de conocimiento: El mismo se presenta a modo indicativo.
3. Sistemas de Soporte de Decisión en Grupo (SSDG)
La mayoría de las decisiones complejas en las diferentes organizaciones son tomadas por grupos.
Colocar un grupo junto 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.
4. Sistemas de Información Ejecutivos (SIE, o EIS en inglés)
Está basado en un sistema de información computarizado e intenta devolver, extraer e integrar datos
de varias fuentes en forma organizada, proveyendo información para la toma de decisión ejecutiva.
Generalmente brinda información de tipo rutinaria, estructurada para decisiones anticipadas.
Es un sistema de información amplio en base de datos e interfaz del usuario, pero con capacidades
rudimentarias de modelado.
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 un Sistema de Soporte de Decisiones (S.S.D.) y un Sistema de
Información de Ejecutivos (S.I.E.)
SSD: SIE:
• Puede ser utilizado para la toma de • Brinda la información a manera de
decisiones no programadas. listados, reportes de excepción (muestra
• La toma de decisión acepta el valor del de ítems que requieren de atención).
modelo y el valor del resultado. • La estructura de los reportes son valores
• Puede proveer soporte a las decisiones de un único problema.
en muy poco tiempo.
• Puede ser desarrollado por personas que
no son profesionales.
5. Sistemas Expertos (SE)
Un SE es un paquete, para resolución de problemas, de software y hardware que puede alcanzar y a
veces sobrepasar el nivel del experto humano en alguna área específica.
Los SE son una rama de aplicación de la inteligencia artificial, generalmente utilizados en
diagnósticos médicos, configuración de computadoras, etc.
La idea básica de un SE es simplemente transferir el conocimiento desde el humano a la
computadora.
El objetivo de un sistema experto es diseñar un algoritmo de búsqueda para propósitos generales
que sea capaz de vincular pasos de razonamiento elementales para encontrar una solución completa
(Stuart Russell, 2003).
6. Redes Neuronales Artificiales
En los casos anteriores, la computadora no aprendía de la experiencia de situaciones previas. Este se
solucionó con las redes neuronales.
SSD - 6/83

7. SanPi-SSD
Tratan de copiar la manera en que trabaja el cerebro humano y pueden trabajar con información
parcial, incompleta o inexacta.
7. Evolución cronológica de los sistemas y sus características:
Al revelar el momento de aparición de los distintos sistemas existentes, podemos comprender la
evolución que han tenido los mismos:
− Sistemas de Procesamiento Transaccional (1950)
− Sistemas de Información Gerenciales (1960)
− Sistemas de Automatización de Oficinas (1970)
− Sistemas de Soporte de Decisión (1970-1980)
− Sistemas Expertos (1980-1990)
− Sistemas de Soporte de Decisión en Grupos (1990)
− Sistemas de Información Ejecutivos (1990)
− Redes Neuronales (1990)
− Herramientas de Decisión Colaborativas basadas en web y tecnología inalámbrica.
Para finalizar, presentaremos una tabla en la que se analizan distintas dimensiones de los sistemas
de soporte de dirección:
Caracteristicas 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 complejas y
información proyección de largo alcance, estratégica, la gerencia repetitivas,
de ventas, problemas control de alto diagnóstico,
ventas monitoreo complejos interno nivel. control de
inversión
Enfoque Transacciones Información Decisiones, Transferencia Seguimiento, Reconocimiento
de datos flexibilidad, de la control y, de Patrones
amigable inferencia “Drill
con el usuario del conoci- down”
miento de
expertos
Base de Datos Única para Acceso Sistemas de Conocimien- Externo Aprendizaje
cada interactivo administra- to procedural (online) y provisto por
aplicación, por progra- ción de base y de la corporativo, Casos históricos
actualizacione madores de datos, realidad; acceso
s por lote acceso Bases del distribuido
interactivo, conocimiento a todas las
conocimiento (hechos, bases de
de la realidad reglas) datos de la
empresa
Capacidad de No usado para Problemas Problemas Los sistemas Sólo cuando Predicciones
Decisión decisión rutinarios y Semiestructu- realizan está principalmente,
estructurados rados, integra decisiones combinado basado en
usando modelos de la complejas, no con información
herramientas ciencia de la estructuradas, un DSS histórica
convencio- administra- uso de reglas
nales de la ción. (heurísticas)
ciencia de la
administración
Manipulación Numérica Numérica Numérica Simbólica Numérica Numérica
(principalme (necesita
nte), a veces preprocesamient
simbólica o)
SSD - 7/83

8. SanPi-SSD
Tipo de Reportes Reportes por Información Consejos y Reportes de Proyecciones,
información sumarizados, demanda y para explicaciones excepción, clasificación de
operacional programados, soporte a indicadores acuerdo a
reportes de decisiones clave patrones
excepción específicas
Más alto nivel Sub-gerencial, Gerencia Gerentes y Gerentes y Sólo Gerentes y
organizacional Gerencia de Media Analistas Especialistas Ejecutivos Especialistas
que sirve bajo nivel Senior
Relevancia en: Conveniencia Eficiencia Efectividad Efectividad y Oportunidad Conveniencia
conveniencia de
presentación
Características de los sistemas de soporte computarizados
Ejemplo de Tareas que realiza cada uno de los sistemas de Soporte de Dirección
Tareas realizadas por cada uno de los sistemas de soporte de dirección para el sistema de
información basado en computadora 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 Preparar reportes sumarizados (ej.: salario promedio de cada
Gerencial 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.
Sistema de Información No existe al nivel departamental, sino al corporativo. Mide los
Ejecutivo indicadores de performance clave del departamento (tales como $
ganados o invertidos por empleado).
Sistema de Soporte de Decisión Soporta el proceso de toma de decisiones polémicas (ej.: políticas
en Grupo de personal); brainstorming electrónico. Puede utilizarse para
decisiones.
Computación Neuronal Analiza la causa por la cual las personas dejan o se quedan con
la empresa (encuentra patrones). Selecciona aspirantes para un
trabajo.
Proceso de toma de decisiones
Los sistemas de información para la dirección que dan soporte a la toma de decisiones,
específicamente a las estratégicas.
¿Qué es un proceso para la toma de decisión?
El proceso de toma de decisiones es la secuencia de etapas que se ejecutan o realizan para tomar
SSD - 8/83

9. SanPi-SSD
una decisión.
También podemos decir que es el proceso de elegir entre varias alternativas.
¿Pero qué es decidir?
“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 solo uno) entre un conjunto de cursos de
acción alternativos.”
El proceso involucra una secuencia de etapas básicas:
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: 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: Determinación de cuál es la mejor alternativa para el caso; elección de la alternativa. La
decisión es tomada basada en los resultados del análisis. Soportado 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.
1. El proceso está compuesto por varias fases.
El proceso de toma de decisiones está compuesto por las siguientes fases:
1. Fase de inteligencia.
2. Fase de diseño.
3. Fase de elección.
4. Fase de implementación.
Fase de inteligencia
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.
Encontrar la magnitud y definir el problema.
La existencia del problema en una organización puede ser estimada monitoreando y analizando los
niveles de productividad (por 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 uno de los pasos más dificultosos del análisis).
Una vez que la investigación preliminar es completada, 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.
La actividad de conceptuar el problema involucra la clasificación dentro de ciertas
categorías.
La clasificación 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 programado o no estructurado: en la medida que resultan novedosos, no estructurados e
inusitadamente importantes en sí mismos. No existe ningún método previsto en sus detalles
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
SSD - 9/83

10. SanPi-SSD
tratamiento hecho a la medida. Estos tipos de problemas 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. Resolviendo cada uno de
ellos se puede ayudar a solucionar el problema total.
− Propietario: es importante establecer el propietario del problema. 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 también 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.
Fase de diseño
La fase de diseño generalmente requiere desarrollar una tarea de análisis y la generación de las
alternativas. Esta última tiene por finalidad establecer qué caminos tenemos disponibles para el
logro de los objetivos.
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.
El modelo del problema es construido, testeado y validado.
El modelado involucra la conceptualización del problema, lo cual incluye la abstracción de un
modelo cualitativo o cuantitativo.
En el caso de un modelo matemático, las variables dependientes e independientes son identificadas
y la ecuación describe las relaciones entre ambas.
Es necesario encontrar el balance entre los niveles de representación del modelo y la representación
de la realidad.
La tarea de modelar involucra combinación de arte y ciencia.
Los siguientes puntos del modelado son presentados para los modelos cuantitativos (matemáticos y
financieros).
1. Componentes del modelo.
2. Estructura del modelo.
3. Selección de los principios de elección (criterio de evaluación).
4. Generación de alternativas.
5. Predicción de las salidas.
6. Medición de las salidas.
7. Escenario.
1. Componentes del modelo cuantitativo:
Los componentes están conectados por relaciones matemáticas (en los cualitativos las relaciones
son símbolos o cualidades).
Variables :
• Variables de decisión: Las variables de decisión describen los cursos alternativos de acción.
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.
SSD - 10/83

11. SanPi-SSD
• 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 cuantitativo.
Los componentes son un conjunto de expresiones matemáticas como ecuaciones o inecuaciones.
Modelo del valor presente
Donde: 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
(ó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. Chequea 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. Generación 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.
Esto 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 puede ser con torbellino de 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
SSD - 11/83

12. SanPi-SSD
Para evaluar y comparar las alternativas, es necesario predecir las salidas de cada una de las
propuestas, 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.
• Riesgosa: 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”.
Fase de elección
SSD - 12/83

13. SanPi-SSD
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 puede sintetizarse en el siguiente
cuadro.
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 sensitivo:
• 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?
Fase de implementación
Consiste en colocar la solución recomendada a trabajar.
Componentes de los sistemas de soporte de decisiones
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).
2. Administrador de modelos: contiene el conjunto de modelos cuantitativos y cualitativos y el
software apropiado para su administración.
3. Administrador de diálogo: el administrador de dialogo es el que provee la interfaz con el
usuario final.
SSD - 13/83

14. SanPi-SSD
4. Administrador de conocimiento: es utilizado en el caso de los sistemas expertos. Este punto
no será desarrollado en los contenidos de la asignatura
El administrador 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.
Tiene las siguientes características:
• Extrae datos para colocarlos en la base de datos decisional.
• Actualiza datos de la base de datos decisional.
• Interrelaciona datos de diferentes fuentes (internas y externas).
• Recupera rápidamente los datos almacenados (debido a su estructura).
• Provee seguridad.
• Proporciona información de su contenido y fuentes de extracción.
El administrador de modelos
Está compuesto por los siguientes elementos:
• Base de modelos.
• MBMS (Model Base Management System).
• Lenguaje de modelado.
• Directorio de modelos.
• Procesador de comandos.
Tiene las siguientes capacidades:
• Creación rápida y fácil de modelos.
• Permite a los usuarios la fácil manipulación de los modelos existentes.
• Almacena los modelos de manera lógica e integrada.
SSD - 14/83

15. SanPi-SSD
• Vincula los modelos con los datos correspondientes.
• Proporciona información del contenido de modelos y su función (metadatos).
El administrador de diálogo
Está compuesto por el software y hardware que proveen la interfaz del usuario con el SSD. Es uno
de los componentes más importantes. 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).
• Procesador de lenguaje natural.
• DGMS (Dialog Generation and Management System).
Tiene las siguientes capacidades:
• Posee diferentes estilos de diálogo (para usuarios diferentes).
• Posibilita un amplio rango de dispositivos de entrada/salida.
• Presenta los datos en varios formatos.
• Provee al usuario capacidades de ayuda en línea.
• Interactúa con el administrador de datos y el de modelos.
• Provee capacidades gráficas.
• Provee flexibilidad.
• Provee casos-tipo de ejemplos.
SSD - 15/83

16. SanPi-SSD
Módulo 2: MODELADO MULTIDIMENSIONAL
En este módulo vamos a profundizar las diferentes alternativas que nos permitirán el diseño y la
construcción de un data warehouse (almacén de datos). Para realizar el diseño del data warehouse,
es decir realizar el diseño de la base de datos, nos valemos de un modelo.
¿Qué es un modelo?
Un modelo es una abstracción o representación formal de un aspecto del mundo real. En este caso,
de algún aspecto o proceso del negocio que se intenta especificar.
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. 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.
Es un componente de la documentación de todo sistema.
1. Modelado 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 las siguientes:
• Modelo entidad – relación.
• 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.
A modo de repaso, citaremos algunos elementos del modelo entidad - relación, para luego dedicarle
atención a los modelos multidimensionales.
Modelo entidad - relación
Nos permite representar el mundo real a través de la identificación de objetos denominados
entidades , y las relaciones entre ellas.
Tiene como componentes:
• Entidades.
• Relaciones.
• Atributos y dominios.
• Supertipos y subtipos.
• Restricciones de integridad y referencial.
• 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.
Debido a su orientación analítica, impone un procesamiento y un pensamiento distinto, los cuales se
sustentan en un modelamiento de base de datos propio, que busca ofrecer al usuario su visión
respecto de la operación del negocio.
El modelamiento dimensional es una técnica para modelar bases de datos simples y entendibles para
el usuario final. La idea fundamental es que el usuario visualice fácilmente la relación que existe
entre los distintas componentes del modelo.
Por ejemplo, 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.
Asignémosles asignan valores particulares a estos ejes. Digamos que el eje X representa Productos,
SSD - 16/83

17. SanPi-SSD
el eje Y representa el Mercado, y el eje Z corresponde al Tiempo. Se podría tener por ejemplo, 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 al punto que
buscamos, lo definimos como la cantidad de madera vendida, entonces se tendrá un valor específico
y único para tal combinación.
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 negocio. Por ejemplo: los gerentes de finanzas de las empresas no
preguntan “¿Cuánto hemos gastado?”, sino “¿Cuánto hemos gastado en beneficio de la salud,
mensualmente, en la división x, en cada región, comparado con lo presupuestado?”, la cual es una
consulta que involucra cinco dimensiones.
Por otra parte, el modelamiento multidimensional es bastante simple: representa un conjunto de
requerimientos de datos de una manera, concisa y comprensible, y la información se presenta en
términos familiares.
Los datos se almacenan de modo que resulten independientes de los programas que los usan,
empleándose métodos bien determinados para incluir datos nuevos y para modificar o extraer los
almacenados.
La base multidimensional es una herramienta usada con relación a 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 de Procesamiento Transaccional en Línea (OLTP), 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.
SSD - 17/83

18. SanPi-SSD
1. Componentes del modelo multidimensional
Los componentes básicos del modelado multidimensional:
1. Hechos.
2. Dimensiones.
3. Elementos.
4. Atributos.
5. Miembros.
6. Tabla de hechos.
7. Tabla de dimensión.
8. Esquemas.
1. Hechos
Los hechos son atributos numéricos que representan la performance, el comportamiento o la
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 se desea realizar el control, por ejemplo la cantidad, importe
vendido, las horas trabajadas, etc. Son valores que indican cómo se está llevando a cabo una
operación. Se almacenan en la tabla de hechos.
2. Dimensiones
Las dimensiones son clases descriptoras de los hechos; son los puntos de vistas a través de los
cuales se desean analizar los mismos.
Son calificadores de hechos, los ponen en perspectiva. Por ejemplo, si el hecho es venta, las
dimensiones podrían ser tiempo, geografía, clientes y/o productos.
Organizan la información de manera que se pueda preguntar qué, cuándo, dónde, etc., y son
almacenadas en tablas junto con los elementos y atributos de dimensión.
Representan una colección de miembros o unidades del mismo tipo.
3. Elementos
Se trata de 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 “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 les
son familiares , por ejemplo 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.
Ejemplos:
A.
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.
B. Elementos
SSD - 18/83

19. SanPi-SSD
Atributos :
Cliente: Código del cliente.
Nombre.
Apellido.
Dirección.
Teléfono, etc.
Ejemplo de 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.
Contiene 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 y la alimentan. No contienen
hechos; 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 está compuesta por una primary key que identifica unívocamente una fila en
la tabla junto con un conjunto de atributos; 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 es la DENORMALIZACIÓN.
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).
SSD - 19/83

20. SanPi-SSD
2. Copo de Nieve (Snowflake Schema).
3. Mixto (Mixed Schema).
4. Constelación (Costellation or MultiStar).
1. Esquema estrella
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.
l esquema estrella deriva su nombre del hecho de que su diagrama forma una estrella, con puntos
radiales desde el centro. El centro de la estrella consiste en una o más tablas fact, y las puntas son
las tablas look-up.
EEste 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.
Características
• La tabla de hechos tiene datos detallados y resumidos.
• La tabla de hechos sólo posee una columna clave por dimensión y cada clave es generada.
• Cada dimensión es una simple tabla altamente denormalizada.
2. Esquema copo de nieve
La diferencia del esquema estrella con el copo de nieve está en la estructura de las tablas de
dimensiones.
SSD - 20/83

21. SanPi-SSD
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
• 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.
3. Esquema mixto
Es una combinación de star schema con snowflake schema, en el que algunas dimensiones están
seminormalizadas y otras totalmente denormalizadas
4. Esquema constelación
Consiste en la representación de varios modelos estrella y/o copo de nieve en un solo modelo,
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
Para diseñar la base contamos con 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.
Para este ejemplo contamos con la siguiente información:
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 elevar una solicitud de desarrollo de un
SSD - 21/83

22. SanPi-SSD
sistema de información que le permitiera controlar los movimientos de la empresa.
Analizando detalladamente los requerimientos del gerente, 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 (ver gráfico 1).
Comenzaremos haciendo una lectura detallada de la organización, de los requerimientos y de la
base de datos transaccional.
Antes de diseñar la base vamos a identificar los componentes del modelo multidimensional. Una
vez que contemos con esta información, nos será fácil el armado de la misma.
Comencemos:
1. Identificamos los hechos, para ello tendremos en cuenta los requerimientos del sistema. En
nuestro caso en particular son los requerimientos de información del gerente de finanzas.
Si leemos nuevamente los requerimientos, podemos ver que los hechos son:
• Cantidad de facturas,
• importe cobrado,
• cantidad de recibos.
2. Analizamos las dimensiones; tendremos presente en este momento que éstas son las
perspectivas de análisis de los indicadores del negocio.
A nivel de dimensiones es posible definir jerarquías, las cuales son grupos de atributos que siguen
un orden preestablecido.
Una jerarquía implica una organización de niveles dentro de una dimensión, con cada nivel
representando el total agregado de los datos del nivel inferior. Las jerarquías definen cómo los datos
son sumarizados desde los niveles más bajos hacia los más altos. Una dimensión típica soporta una
SSD - 22/83

23. SanPi-SSD
o más jerarquías naturales. Una jerarquía puede pero no exige contener todos los valores existentes
en la dimensión.
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 del gráfico 1).
• 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.
Hasta este momento hemos identificado los hechos, las dimensiones, los elementos y la jerarquía
que forman. Ahora pensemos qué atributos corresponderían a cada uno de los elementos.
Para la dimensión tiempo tenemos que los atributos de los elementos serían:
o Día: • Día
• Descripción del día
o Mes : • Mes
• Descripción del mes
o Año • Año
Para la dimensión zona geográfica serían:
o Provincia: • Id_provincia
• Descripción de la provincia
o Sucursal: • Id_sucursal
• Id_provincia (a la que pertenece la sucursal)
• Descripción de la sucursal
Para la dimensión vendedor, que no tiene elementos, tenemos simplemente los atributos de cada
uno de los vendedores de la empresa:
• Id_vendedor
• Nombre
Para la dimensión cliente, los atributos podrían ser:
• 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.
Con todos estos componentes definidos, estamos en condiciones de graficar la base de datos
multidimensional, con un star schema.
Nota: si es necesario, revise nuevamente el material anterior, donde se explica qué contiene cada
una de las tablas que aparecen en el modelo.
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.
Tiempo Tabla de Hechos Vendedores
• Fecha_factura • Id_factura • Id_vendedor
SSD - 23/83

24. SanPi-SSD
• Mes • Id_recibo • Nombre
• Desc_mes • Id_vendedor
• Año • Id_cliente
Zona geográfica • Id_sucursal Clientes
• Id_sucursal • Fecha_factura • Id_cliente
• Desc_sucursal • Cantidad facturas • Nombre
• Id_provincia • Cantidad recibos
• Desc_provincia • Importe cobrado
Conceptos avanzados de modelado multidimensional
1. Tabla de hechos que representan eventos.
2. Medidas aditivas, semiaditivas y no aditivas.
3. Minidimensiones, dimensiones sucias y dimensiones degeneradas.
4. Cambios en dimensiones y soluciones de tipo I, II y III.
5. Periodos de tiempo.
1. Tabla de hechos que representan eventos
Algunos de los procesos de negocio que queremos modelar usando un data warehouse están
relacionados a 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 clase específica.
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
SSD - 24/83

25. SanPi-SSD
í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 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.
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 demográfica como el ejemplo, la clave demográfica puede ser
almacenada como una clave foránea en tabla base y en cliente. Esto permite a la
minidimensión demográfica componerse directamente de la tabla base. La clave
demográfica también puede ser usada directamente con la tabla cliente para examinar los
atributos demográficos.
SSD - 25/83

26. SanPi-SSD
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.
A) Tipo I: Cambio en el valor almacenado en una columna de una dimensión.
Sobreescribir el viejo valor en el registro dimensional y por lo tanto perder la capacidad de
seguir la vieja historia. 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.
B) Tipo II: Crear un segundo registro de dimensión con el nuevo valor y una clave
generalizada. Crear un registro dimensional adicional (con una nueva llave) que permita
registrar el cambio presentado por el valor del atributo. De esta forma permanecerían en la
base tanto el antiguo como el nuevo valor del registro con lo cual es posible segmentar la
historia de la ocurrencia.
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.
C) Tipo III: Crear un campo “actual” nuevo en el registro dimensional original el cual almacene
el valor del nuevo atributo, manteniendo el atributo original también. Cada vez que haya un
nuevo cambio en el atributo, se modifica el campo “actual” solamente. No se mantiene un
registro histórico de los cambios intermedios.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. Un día dado, por ejemplo, actualmente
pertenecería a períodos de 3 meses y a períodos de 6 meses. El 1º de Junio pertenecería a Abril
-Mayo-Junio, Mayo-Junio-Julio y Junio-Julio-Agosto. Habría 3 registros para el 1º 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 a una tabla de dimensión
especial en lugar de una tabla de dimensión estándar.
SSD - 26/83

27. SanPi-SSD
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 periodo 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 "
Herramientas para mejorar la performance
Tres técnicas para mejorar la performance son:
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 agregadas
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 lleguen a estar 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 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.
SSD - 27/83

28. SanPi-SSD
Algunas consideraciones cuando usamos totales son:
• Beneficios
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
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.
La fragmentación de tablas puede ser ventajosa para máquinas multiprocesadoras 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
SSD - 28/83

29. SanPi-SSD
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 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 distribuirlas
equitativamente entre los fragmentos. 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,
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. Para ello realizaremos una introducción al tema con
las:
1. Operaciones en un Data Warehouse
En el siguiente gráfico se muestran algunos de los tipos de operaciones que se efectúan dentro de un
ambiente data warehousing.
SSD - 29/83

30. SanPi-SSD
El desarrollo de los puntos a) hasta el f) que a continuación desarrollaremos, permitirá comprender
el gráfico:
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 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.
Este proceso 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.
Los mismos elementos de datos, si son usados por aplicaciones diferentes o administrados por
distintos software DBMS, pueden definirse al usar nombres de elementos inconsistentes, que tienen
formatos inconsistentes y/o ser codificados de una manera alternativa. Todas estas inconsistencias
deben resolverse antes de 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): cómo estos se integran y transforman antes de ser almacenados en información
similar. Los metadatos llevan registros de los datos almacenados, integrados en la misma base de
datos. Describen el contenido de la base de datos de información. Describen las tablas, índices y el
contenido de los datos. Los metadatos guardan información sobre los formatos, significado y origen
de los datos y facilitan, por lo tanto, el acceso, la navegación y la administración de los datos en la
bodega. Son datos sobre los datos.
d) Acceso de usuario final
Los usuarios acceden al data warehouse por medio de herramientas de productividad basadas en
GUI (Graphical User Interface - Interfaz gráfica de usuario). Pueden proveerse a los usuarios del
data warehouse muchos de estos tipos de herramientas.
Éstos pueden incluir 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.
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.
Nuestro siguiente objetivo es comprender que los datos que mantiene el data warehouse cambian en
el tiempo. Para ello revisaremos los siguientes conceptos:
Evolución del Warehouse
Construir un data warehouse es una gran tarea. No es recomendable emprender el desarrollo del
SSD - 30/83

31. SanPi-SSD
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 solo paso. Muchas, sin embargo,
lo han logrado luego de un desarrollo paso a paso.
Los datos en el data warehouse no son volátiles y es un repositorio de datos de sólo lectura (en
general). Sin embargo, pueden añadirse nuevos elementos sobre una base regular 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 identificarlos 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 bases 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. Como se añaden las nuevas ocurrencias de datos,
los 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.
1. Transformación de datos y metadatos
La migración de los datos desde las fuentes operacionales al DataWarehouse requiere la necesidad
de procesos para extraer, transformar y cargar los datos, actividad que se conoce como ETL.
La razón por la cual se requieren estos procesos se origina en una necesidad de reformatear,
conciliar y limpiar los datos de origen. Seria conveniente que las transformaciones a los datos se
apliquen solo una vez y que se reflejen en los archivos y bases de datos que actuan como fuente de
datos.
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 se dan cuando
múltiples bases 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 distintas. Los procesos de transformación de datos se desarrollan
para direccionar estas inconsistencias.
SSD - 31/83

32. SanPi-SSD
La transformación de datos también se encarga de las inconsistencias en el contenido de ellos.
La parte mas importante de la transformación de datos consiste en el precálculo de los mismos para
que las consultas al DataWarehouse se respondan mas eficientemente:
• Totalización (Sumarización): consiste en procesar valores numéricos para obtener valores
generales como cantidades, promedios, máximos, mínimos, totales. Estos valores son los
que componen las tablas de hechos, y se pueden calcular y almacenar en distintos niveles,
por ejemplo, calcular los totales de ventas por departamentos, los totales por regiones, y los
totales por país.
• Agregación: se refiere a crear datos derivados a partir de la unión de varios datos atómicos,
en forma horizontal. Por ejemplo, agregar los elementos de datos de un cliente a partir de la
tabla Clientes y de la tabla Ventas para armar un historial de los movimientos del cliente en
la empresa.
La mayoría de los datos se agregan y se totalizan basándose en patrones de los reportes requeridos y
en la estructura de la base de datos multidimensional elegida (Star o Snowflake).
Es importante examinar en que momento realizar cada transformacion. Hay solo un proceso ETL,
así que las transformaciones aplicables a todos los datos de origen, como las conversiones de tipos,
se deberían realizar en primer lugar. Las transformaciones especificas del DataWarehouse, como
agregaciones y totalizaciones, deberían realizarse más hacia el final del proceso.
Una vez que se toma la decisión sobre las reglas de transformación que serán establecidas, deben
crearse e incluirse las definiciones en las rutinas de modificación.
Se requiere una planificación cuidadosa y detallada para transformar datos inconsistentes en
conjuntos de datos conciliables y consistentes para cargarlos en el data warehouse.
En la transformación de datos existe otra dificultad además de la integración: la eficiencia de acceso
a los sistemas de datos existentes. ¿Cómo sabe el programa que busca sistemas existentes cuándo un
archivo fue recorrido previamente? ¿O cuándo un archivo no fue recorrido? Existe mucha
información en el entorno de los sistemas existentes, e intentar recorrerlos por completo cada vez
que se actualiza el data warehouse es muchas veces poco realista y 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 de los
SSD - 32/83

33. SanPi-SSD
datos continua 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.
Son cinco las técnicas más comunes para limitar la cantidad de datos recorridos de las aplicaciones
existentes:
1. Time stamped
2. Delta file
3. Log de transacciones
4. Modificación de aplicaciones
5. Creación de imágenes
1. 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 han sido
“fechados”.
2. 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 que 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. 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 con este
es que son operaciones que protegen los archivos de log, porque éstos son necesarios en el
proceso de recuperación y no someten al archivo de log a otra cosa que no sea su propósito
original. Otra diferencia o 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. La cuarta técnica para examinar la gran cantidad de datos que requiere la extracción al data
warehouse es modificar el código de la aplicación. Generalmente esta técnica tiene
resistencia a ser usada debido a la antigüedad del código existente y a la fragilidad del
mismo.
5. La quinta y última opción es mantener imágenes anteriores y posteriores conjuntamente.
Debe obtenerse una fotografía de la base de datos al momento de la extracción. Cuando se
requiere realizar otra extracción, se toma otra fotografía. Cada fotografía se compara con la
otra para determinar la actividad transcurrida. Esta tarea es complicada y requiere gran
cantidad de recursos.
Estructura de datos en el data warehouse (periodicidad)
Básicamente existen cuatro estructuras (las más comunes):
• Acumulativa simple
• Rotación de datos sumarizados
• Archivo directo simple
• Archivo continuo
La estructura de datos más común y simple es la que encontramos en una estructura acumulativa
simple, en la 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 data warehouse 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. Así, 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
SSD - 33/83