BASE DE DATOS AVANZADAS

Arquitectura Data Warehousing

Docente:Lsi. Verónica Freire Avilés, Msig,

 INTRODUCCIÓN
▪ DWH está formado por diversos componentes que interactúan entre sí y cumplen una
función específica dentro del sistema.
▪ Su funcionamiento puede resumirse de la siguiente manera:
▪ Los datos son extraídos desde distintas fuentes, bases de datos, archivos, servicios web, etc. (residen
en diferentes tipos de sistemas con arquitecturas y formatos variados).
▪ Los datos son integrados, transformados y limpiados, para luego ser cargados en el DW.
▪ Con base en el DW, se construirán Cubos Multidimensionales y/o Business Models.
▪ Usuarios accederán a los Cubos Multidimensionales, Business Models (u otro tipo de estructura de
datos) del DW, utilizando diversas herramientas de consulta, exploración, análisis,reportes, etc.

Docente: Lsi. Verónica Freire Avilés, Msig

1. DATA SOURCES (ORÍGENES DE DATOS)

▪ Representan los datos transaccionales que genera la empresa en su accionar diario,

junto a otros datos internos y/o externos complementarios.
▪ Poseen características muy disímiles entre sí, en formato, procedencia, función, etc.
▪ En la actualidad esto se ve potenciado gracias a los web services, redes sociales, y a
la utilización cada vez más frecuente de bases de datos NoSQL.
LOS DATA SOURCES MÁS HABITUALES PARA EXTRAER DATOS RELEVANTES SON:
Archivos de textos
Hojas de cálculos
Informes semanales, mensuales, anuales, etc.
Bases de datos transaccionales, SQL y NoSQL
Información no estructurada (páginas web, mails)
Redes sociales
RSS
Web Services
2. LOAD MANAGER
 2. LOAD MANAGER
▪ El componente Load Manager es el
encargado de la ejecución y
calendarización (scheduling) de los
diferentes procesos de Integración de
Datos a través de los cuales:
▪ se extraerán los datos desde los
Data Sources,
▪ serán manipulados, integrados y
transformados, para luego
▪ cargar los resultados obtenidos en
el DW.

▪ La Integración de Datos es una serie de

técnicas y procesos que se encargan de
llevar a cabo todas las tareas
relacionadas con la extracción,
manipulación, control, integración,
depuración de datos, carga y
actualización del DW, etc.

Docente: Lsi. Verónica Freire Avilés, Msig

2. LOAD MANAGER
▪ Si bien el proceso ETL (Extraction, Transformation, Load) es solo una de las
muchas técnicas de la Integración de Datos
▪ Es la más importante, incluso en muchos casos constituyen el proceso de
integración en si.
▪ En este orden, se puede ubicar el resto de las técnicas en las diferentes etapas del
ETL:
▪ el proceso Extracción incluirá técnicas enfocadas por ejemplo a obtener desde diversas
fuentes solamente los datos relevantes y mantenerlos en una Staging Area
(almacenamiento intermedio);
▪ el proceso Transformación incluirá técnicas encargadas de compatibilizar formatos, filtrar
y clasificar datos, relacionar diversas fuentes, etc;
▪ el proceso Carga incluirá técnicas propias de la carga de datos y actualización del DW.

Docente: Lsi. Verónica Freire Avilés, Msig

2. LOAD MANAGER
▪ EXTRACCIÓN

▪ La selección de los Data Sources para proveer todos

los datos tiene que hacerse teniendo en cuenta las
necesidades de usuarios y requisitos definidos para la
solución.
▪ Data Sources a utilizar serán bases de datos
relacionales➔ extracción mediante consultas SQL o
procedimientos almacenados.
▪ Pero en el caso de Data Sources NO convencionales o
NO estructurados, la obtención será más dificultosa.
▪ Una vez seleccionados y extraídos, los datos, deben ser
persistidos en una base de datos relacional Staging

Docente: Lsi. Verónica Freire Avilés, Msig

2. LOAD MANAGER
▪ EXTRACCIÓN

BD relacional Staging (almacenamiento intermedio):

▪ Manipular los datos sin interrumpir ni sobrecargar los Data Sources y el
DW.
▪ Crear una capa de abstracción entre la lectura y la carga.
▪ Almacenar y gestionar los metadatos que se generan en los procesos ETL.
▪ Facilitar la integración.

▪ Staging Area ➔ se constituye en una o más BD donde la información puede

ser persistida en tablas auxiliares, tablas temporales, etc.
▪ Una vez que los datos se encuentren en Staging Area, el proceso puede
desconectarse de los Data Sources y continuar con la transformaciones
necesarias para poblar el DW.

Docente: Lsi. Verónica Freire Avilés, Msig

2. LOAD MANAGER
▪ TRANSFORMACIÓN

▪ Esta función es la responsable de aplicar todas las acciones necesarias

sobre los datos, a fin de hacerlos consistentes, compatibles y congruentes
con el DW.
▪ Los casos más comunes en los que se debe realizar integración, son los
siguientes:
▪ Codificación.
▪ Medida de Atributos.
▪ Fuentes múltiples.

▪ Además de lo antes mencionado, esta función se encarga de realizar los

procesos:
▪ Data Cleansing (Limpieza de Datos).
▪ Data Quality (Calidad de Datos).

Docente: Lsi. Verónica Freire Avilés, Msig

 2. LOAD MANAGER
▪ CODIFICACIÓN
▪ Una inconsistencia típica que se encuentra al integrar varios Data Sources, es la
de contar con más de una forma de codificar un Atributo en común.
▪ Por ejemplo, al especificar el valor que tendrá el campo status, valores 0 y 1, en otros
Apagado y Encendido, etc.
▪ Se deberá seleccionar una de las codificaciones existentes o bien aplicar otra,
pero todos los datos de ese Atributo deben respetar una única convención de
codificación antes de ingresar al DW.

Docente: Lsi. Verónica Freire Avilés, Msig

 2. LOAD MANAGER
▪ MEDIDA DE ATRIBUTOS
▪ Los tipos de unidades de medidas utilizados para
representar Atributos, pueden variar en Data Source.
Ejemplo: centímetros, metros, pulgadas, etc.
▪ Este proceso implica redimensionar el valor asociado
a la unidad de medida.
▪ Este redimensionamiento suele ejecutarse
multiplicando el valor por un factor de escala.
▪ Ejemplo si la unidad de medida seleccionada es metro
y desde un Data Source vienen cm, los valores se
deben multiplicar por el factor de escala 0,01 a fin de
que se mantengan íntegros.

Docente: Lsi. Verónica Freire Avilés, Msig

2. LOAD MANAGER
▪ FUENTES MÚLTIPLES
▪ Un mismo elemento puede derivarse
desde varios Data Sources.
▪ En estos casos, se debe elegir aquella
fuente que se considere más fiable y
apropiada

Docente: Lsi. Verónica Freire Avilés, Msig

2. LOAD MANAGER
▪ DATA CLEANSING(LIMPIEZA DE DATOS)
▪ Objetivo principal ➔ entregar un flujo de datos lo más sanitizado posible (eliminar
datos erróneos o irrelevantes y subsanar aquellos que presenten inconsistencias).

Acciones que se Ignorarlos.

pueden llevar a cabo
al encontrarse
con Outliers (Datos Eliminar la columna (se eliminan el 100% de los datos).
Anómalos)

Filtrar la columna (se eliminan algunos de los datos).

Filtrar la fila errónea, ya que a veces su origen, se debe a casos especiales.

Reemplazar el valor.

Discretizar los valores de las columnas. Por ejemplo, si un campo numérico presenta un
valor de 1 a 2, utilizamos el texto Bajo; de 3 a 7, Óptimo; de 8 a 10, Alto.

Docente: Lsi. Verónica Freire Avilés, Msig

2. LOAD MANAGER
▪ DATA CLEANSING(LIMPIEZA DE DATOS)

Acciones que Ignorarlos.

suelen
efectuarse
Eliminar la columna (se eliminan el 100% de los datos).
contra Missing
Values (Datos
Faltantes) Filtrar la columna (se eliminan algunos de los datos).

Filtrar la fila errónea, ya que a veces su origen, se debe a casos

especiales.
Reemplazar el valor.

Esperar hasta que los datos faltantes estén disponibles.

Docente: Lsi. Verónica Freire Avilés, Msig

2. LOAD MANAGER
▪ CARGA➔ función responsable de ejecutar las tareas relacionadas con Carga
Inicial (Initial Load) y Actualización periódica (Update)

• Primera carga de datos que recibe el DW.

La Carga • Esta tarea consume un tiempo considerable (insertan
gran cantidad de registros pertenecientes a períodos
Inicial (Initial largos de tiempo)

Load)

• Inserción de pequeños volúmenes de datos, y su

Actualización frecuencia está dada en función de la granularidad
(cuán resumidos se encuentran los datos) del DW y
Periódica los requerimientos de usuarios.
• Objetivo ➔ añadir al DW solo aquellos datos que se
(Update) generaron a partir de la última actualización (delta de
cambios).

Docente: Lsi. Verónica Freire Avilés, Msig

2. LOAD MANAGER
▪ CARGA
▪ Previo a una actualización, se deben identificar los cambios (delta) en las fuentes
originales (mediante la fecha de la última actualización). Acciones a realizar:

Cotejar las instancias de los Data Sources involucrados.

Utilizar triggers para informar de los cambios sucedidos en los Data Sources.

Recurrir a Marcas de Tiempo (Time Stamp), en los registros de los Data Sources.

Comparar los datos existentes entre el Data Source y el DW.

Hacer uso de técnicas mixtas.

Si este control consume demasiado tiempo y esfuerzo, o simplemente NO se lleva a cabo existe la
posibilidad de cargar el DW desde cero: este proceso se denomina Carga Total (Full Load). Esta acción
involucra el vaciado previo del DW.
2. LOAD MANAGER
CARGA: El proceso de Carga también es responsable de mantener la estructura del
DW e involucra conceptos como:

Relaciones muchos a muchos.

Claves Subrogadas.

Dimensiones Lentamente Cambiantes.

Dimensiones Degeneradas.

Docente: Lsi. Verónica Freire Avilés, Msig

2. LOAD MANAGER
▪ PROCESO ETL
▪ El proceso ETL trabaja de la siguiente manera:
▪ Se extraen los datos relevantes desde los Data Sources y se depositan en la Staging Area.
▪ Se integran y transforman los datos, para evitar inconsistencias.
▪ Se cargan los datos desde el Staging Area al DW.

Docente: Lsi. Verónica Freire Avilés, Msig

Docente: Lsi. Verónica Freire Avilés, Msig
3. DATA WAREHOUSE MANAGER
El DW Manager está compuesto por una serie de aplicaciones de software dedicadas a
gestionar:

Docente: Lsi. Verónica Freire Avilés, Msig

BASE DE DATOS MULTIDIMENSIONAL
▪ Un Data Warehouse es una base de datos con estructura multidimensional, lo cual
se traduce en una forma específica de almacenamiento en la cual se definen dos
estructuras principales:
▪ tablas de Hechos y
▪ tablas de Dimensiones.
▪ La utilización de tablas de Hechos y Dimensiones, facilita la creación de
estructuras de datos (Cubos Multidimensionales, Business Models, etc.) y posibilita
que las consultas al SGBD sean respondidas con mucha performance.

Docente: Lsi. Verónica Freire Avilés, Msig

BASE DE DATOS MULTIDIMENSIONAL: TIPOS DE
MODELOS LÓGICOS
▪ Existen tres formas de modelar las tablas de Hechos y Dimensiones:

Esquema copo de Esquema

Esquema en estrella nieve (Snowflake constelación
(Star Scheme). Scheme). (Starflake Scheme).

Estos modelos ➔ facilitan el acceso a consultas complejas y con gran cantidad de

agregaciones, es por ello que se encuentran desnormalizadas o semi desnormalizadas,
reduciendo de esta manera al mínimo la cantidad de JOINs que deben emplearse para
acceder a los datos requeridos.

Docente: Lsi. Verónica Freire Avilés, Msig

BASE DE DATOS MULTIDIMENSIONAL: TIPOS DE
IMPLEMENTACIÓN
▪ Los modelos lógicos pueden ser implementados de diferentes maneras:

Multidimensional –
Relacional – ROLAP. Híbrido – HOLAP.
MOLAP.

Docente: Lsi. Verónica Freire Avilés, Msig

TABLAS DE DIMENSIONES
▪ Las tablas de Dimensiones proveen el medio para analizar los datos dentro del
contexto del negocio. Veamos algunos ejemplos

▪ Las tablas de Dimensiones:

▪ contienen datos cualitativos y
▪ representan los aspectos de interés,
▪ mediante los cuales usuarios podrán filtrar y manipular los Hechos almacenados en las
tablas de Hechos.

Docente: Lsi. Verónica Freire Avilés, Msig

TABLAS DE DIMENSIONES
▪ Las tablas de Dimensión contienen los siguientes tipos de campos:
▪ Clave principal.
▪ Claves foráneas (solo para esquemas copo de nieve y constelación).
▪ Datos de referencia primarios: datos que identifican la Dimensión. Por ejemplo: nombre del
cliente.
▪ Datos de referencia secundarios: datos que complementan la descripción de la Dimensión. Por
ejemplo: e-mail del cliente, celular del cliente, etc. No son significativos para tomar decisiones

▪ Es recomendable que la clave principal de las tablas de Dimensiones sea independiente

de las claves de los Data Sources, ya que, por ejemplo, si estos últimos son recodificados,
el DW quedaría inconsistente.
▪ Estas claves independientes se denominan Claves Subrogadas.

Docente: Lsi. Verónica Freire Avilés, Msig

TIEMPO
▪ En un DW, creación y mantenimiento de una tabla de Dimensión
Tiempo es obligatoria, y la definición de granularidad y
estructuración
▪ La Dimensión Tiempo NO es sola una secuencia cronológica
representada de forma numérica, sino que mantiene niveles
jerárquicos especiales ➔ Ej: ventas realizadas teniendo en
cuenta el día de la semana en que se produjeron, quincena, mes,
trimestre, semestre, año, estación, etc.
▪ La forma de diagramar la Dimensión Tiempo es muy sencilla se
debe tomar el campo que indique la fecha en que sucedieron
los Hechos y luego analizar dicha fecha para crear los campos
requeridos.
▪ Ejemplo➔ se ha definido más de una Jerarquía para la
Dimensión tiempo.

Docente: Lsi. Verónica Freire Avilés, Msig

TABLAS DE HECHOS
▪ Utilizados usuarios del DW➔ analizar y responder preguntas de
negocio.
▪ Los Hechos (o Dato agregado):
▪ son datos cuantitativos,
▪ que son filtrados, agrupados y explorados a través de condiciones definidas
en las tablas de Dimensiones
▪ Los datos presentes en las tablas de Hechos constituyen ➔ volumen
del DW, y pueden estar compuestos por millones de registros
dependiendo de su granularidad y la antigüedad de la organización

Docente: Lsi. Verónica Freire Avilés, Msig

TABLAS DE HECHOS
▪ El registro del Hecho posee una clave primaria que está compuesta por las claves
primarias de las tablas de Dimensiones relacionadas a éste.

▪ Es por ello que la clave primaria de la tabla de Hechos es la combinación de las

claves primarias de sus Dimensiones.
▪ Los Hechos en este caso son importeTotal y utilidad.
Docente: Lsi. Verónica Freire Avilés, Msig
TABLAS DE HECHOS
▪ HECHOS VS INDICADORES
▪ Hechos ➔ datos que residen en una tabla de Hechos.
▪ Indicadores ➔ hacen uso de los Hechos para obtener un valor analizable y se
definen mediante una serie de metadatos:
▪ nombre representativo, descripción, I18N, etc;
▪ tipo de agregación al momento de crear una estructura de datos (Cubo Multidimensional,
Business Model). Agregaciones más utilizadas son: SUM, MAX, MIN, COUNT, AVG,
porcentajes, fórmulas, etc;
▪ agregaciones alternativas;
▪ tipo de datos (siempre numéricos).

Docente: Lsi. Verónica Freire Avilés, Msig

TABLAS DE HECHOS
▪ Ejemplos de Hechos
▪ importeTotal = precioProducto * cantidadVendida
▪ rentabilidad = utilidad / patrimonioNeto
▪ cantidadVentas = cantidad
▪ promedioGeneral = AVG(notasFinales)

▪ HECHOS BÁSICOS Y DERIVADOS

▪ Hechos Básicos:
▪ se encuentran representados por un campo de una tabla de Hechos. Ejemplo: precio y
cantidad.
▪ Hechos Derivados:
▪ se obtienen a partir de una expresión, combinando uno o más Hechos con alguna
operación matemática/lógica y que también residen en una tabla de Hechos.
▪ Se almacenan ya calculados, accedidos a través de consultas SQL devolviendo resultados
rápidamente.
▪ Requieren más espacio físico en el DW y más tiempo de proceso en los ETL.
▪ Hecho Derivado➔ total = precio * cantidad
Docente: Lsi. Verónica Freire Avilés, Msig
AGREGADAS Y PREAGREGADAS
▪ Tablas de Hechos Agregadas y Preagregadas ➔ almacenar un resumen de los
datos, es decir, se guardan los datos en niveles de granularidad superior a los que
inicialmente fueron obtenidos y/o gestionados.

• Se generan luego de que se procesa la consulta correspondiente a la

tabla de Hechos que se resumirá.
Tablas de Hechos • Resúmenes utilizados por las herramientas de software de análisis a fin
de mejorar la respuesta.
Agregadas:

• Se generan antes de que se procese la consulta correspondiente a la

tabla de Hechos que se resumirá.
Tablas de Hechos • La consulta se realiza contra una tabla que ya fue previamente
agregada.
Preagregadas: • Estos resúmenes deben generarse y almacenarse al momento de
poblar/actualizar el DW, utilizando procesos ETL.

Docente: Lsi. Verónica Freire Avilés, Msig

AGREGADAS Y PREAGREGADAS
▪ Beneficios:
▪ Reduce la utilización de recursos de hardware en la que se incurre en el momento de
calcular las agregaciones.
▪ Reduce el tiempo utilizado en la generación de consultas por parte de l@s usuari@s.
▪ Son muy útiles en los siguientes casos generales:
▪ Cuando los datos a nivel detalle (menor nivel granular) son innecesarios y/o NO son requeridos.
▪ Cuando una consulta a determinado nivel de granularidad es solicitada con mucha frecuencia.
▪ Cuando el volumen de datos es muy grande y las consultas demoran en ser procesadas.

▪ Desventajas:
▪ Requieren de la creación y mantenimiento de nuevos procesos ETL.
▪ Requieren espacio de almacenamiento adicional en el DW.
▪ Resulta complejo reconocer qué agregaciones son necesarias mantener en tablas.

Docente: Lsi. Verónica Freire Avilés, Msig