Vous êtes sur la page 1sur 275

Fundamentos de Data

Warehouse

Lic. Víctor Ramón Martínez Fretes


UniNorte - 2016
Contenidos

• Introducción
• Arquitectura del data warehouse
• Estructura de un data warehouse
• Data marts
• Granularidad
• Exploración y minería de datos.
• Diseño del data warehouse
• Visualización del modelo dimensional Aplicaciones OLAP
(bases de datos dimensionales)
• Carga de datos en el data warehouse
• Ciclo de vida del data warehouse
Introducción
 Data Warehouse es una solución no un producto o grupo de
productos.

 Un DWH puede ayudarnos a obtener respuestas para tomar decisiones


de manera más acertada.

 Antes de construir un DWH debemos responder a las siguientes


preguntas
 ¿De donde vienen los datos del DWH?
 ¿cómo se cargarán los datos en el DWH?
 ¿cómo se mantendrán?
 ¿cómo se estructuran los datos en el DWH?
 ¿qué podemos encontrar en un momento del tiempo en el DWH?
Introducción
 Definición de DWH

 Data Warehousing: diseño e implementación de procesos, y herramientas


para gestionar y proveer información completa, en tiempo, fiel y
comprensible para la toma de decisiones. Incluye todas las actividades que
hacen posible a una organización la creación, gestión y mantenimiento del
DWH o del datamart.

 La definición aceptada de DWH se atribuye a Bill Inmon en 1992*:

 DWH es una base de datos que sigue cuatro características:


 Orientado a sujeto.
 No volátil
 Integrado
 Tiempo variable
Introducción

 La necesidad del DWH surge a partir de la necesidad de obtener


acceso fácil a una serie de datos estructurados con la calidad
suficiente para ser usados en la toma de decisiones.

 Es sabido por todo el mundo que la información es un potente


activo del que se pueden obtener importantes beneficios y
ventajas competitivas para cualquier organización.
Introducción

 En las décadas de los 80 y 90 las compañías se han preocupado


principalmente por la adecuación de los sistemas
operacionales, es decir por la obtención de los datos, la
disponibilidad de las aplicaciones, el almacenamiento de los
datos, etc...

 En nuestros días ha legado el momento de sacar partido de esa


información, el problema es que los sistemas operacionales no
permiten en la mayoría de los casos la obtención de
información de manera rápida y precisa para la toma de
decisiones, por diversas causas.
Introducción 7

 Debido principalmente a tres fenómenos que han ocurrido


durante la pasada década los tamaños de las bases de datos
se han visto incrementados significativamente:

 Los costes de almacenamiento se han vuelto insignificantes en


comparación con el valor de la información almacenada.

 Las empresas valoran la información (datos) como un activo de


negocio crítico.

 Muchas de las empresas multinacionales comparten su


información a través de toda la organización a nivel mundial.
Introducción
 Existen diferentes aplicaciones en la organización
 Diferentes estructuras de datos
 Diferentes motores de datos
 Diferentes almacenamientos físicos de información (ficheros)
 Diferentes plataformas
 Mainframes
 Sistemas medios multiprocesador
 Proveedores externos de servicios
 Estaciones de trabajo en red e independientes.
 Información distribuida
 Multiplicidad de tipos de datos
 Por ejemplo un sistema calcula la edad a través de la fecha de
nacimiento, otro lo escribe en un campo, uno llama edad al atributo,
otro le llama AGE...
Introducción

 Este tipo de organizaciones tendrán que desarrollar y mantener


diferentes aplicaciones para extraer, preparar y consolidar la
información en informes y analíticas.

 Es normal también que los responsables de la toma de decisión, a


la hora de efectuar un hallazgo quieran profundizar más en los
datos que han llevado a ese hallazgo.
Introducción
 Los sistemas DWH implementan:

 Los procesos de acceso a datos heterogéneos, limpios, filtrados y


transformados.
 El almacenamiento de datos en estructuras fáciles de acceder, fáciles de
usar y comprensibles.

 Los datos en el DWH son usados para consultar, analizar y realizar


informes.

 El tipo de acceso, uso, tecnología y rendimiento son


completamente diferentes de los sistemas transaccionales
operacionales OLPT.
Introducción
 Los volúmenes de datos en el DWH pueden ser considerablemente
altos, particularmente si existen análisis basados en históricos.

 Debido a este tipo de volumen de datos y el análisis que se realiza


sobre ellos se desaconseja hacer este tipo de operaciones
directamente sobre los sistemas transaccionales ya que estos
pueden verse impactados de manera negativa en su rendimiento
debido a las operaciones masivas que requiere el análisis.

 Existe por tanto un requerimiento de separación de los dos


entornos DWH-OLPT para minimizar los posibles conflictos y
degradación de rendimiento en el sistema operacional.
Introducción

 Los sistemas DWH no son considerados ahora como meras fotos-fijas


(snapshots) de los datos operacionales. Los sistemas DWH deben ser
considerados como nuevas fuentes de información concebidas para el
uso de toda la organización.

 La simple reingeniería de los modelos operacionales no satisfacen los


requerimientos para el DWH.

 El desarrollo de DWH requiere mucho más análisis aplicado a las


técnicas de modelado y una relación mucho mas cercana con el
propio negocio de la organización.
Introducción

 La acumulación de información histórica en el DWH, junto a su


análisis puede dar lugar a informaciones o revelaciones nunca
antes conocidas acerca de clientes, competidores, etc..., por lo
que el DWH aunque es un sistema de solo-lectura (read-only)
también puede aportar información.

 El DWH también ayuda al descubrimiento de cosas que


diferencian a la organización.
Introducción

 PARA LOGAR ESTOS RESULTADOS NO BASTA CON LA SIMPLE


REINGENIERIA DE LOS MODELOS DE DATOS OPERACIONALES.
Arquitectura del
DWH

 Consistencia de los datos (Data consistency architecture)


 La consistencia de los datos se basa en la elección de los distintos orígenes de
datos, dimensiones, Reglas de negocio, métrica y semántica, que una
organización selecciona para un uso común.
 Este es de lejos el aspecto más difícil de implementar en la arquitectura del
data warehouse debido a que incluye y está condicionada por las políticas y la
organización de la compañía.
 Las decisiones acerca de esta arquitectura deben de conducir a todas las otras
decisiones.
Arquitectura del
DWH

 Arquitectura del almacén de datos para informes y del área de


almacenamiento temporal (Reporting data store and stagin data store
architecture)
 Las principales razones por las que se almacenan datos en un data warehouse
son:
 Realización de informes que hacen uso de ellos (Reported against)
 Limpieza y organización de los datos (Cleaned up)
 Transporte a otro almacén de datos donde pueden ser utilizados para
realización de informes o para su limpieza y organización.
Arquitectura del DWH

 Arquitectura del modelado de datos (Data modeling Architecture)


 Consiste en la elección acerca de si se usarán modelos de datos,
normalizados, denormalizados, orientados a objetos, propietarios,
multidimensionales, etc...
Arquitectura del
DWH

 Arquitectura de herramientas (Tool architecture)


 La elección de herramientas que serán usadas para reporting.
 Arquitectura de procesado (Processing tiers architecture)
 Elección de las plataformas físicas para el procesamiento concurrente
que tiene lugar en el data warehouse.
 Puede ir desde una simple arquitectura como la basada en un único
servidor de informes hasta uno cientos de servidores distribuidos.
 Arquitectura de Seguridad (Security Architecture)
 Aunque la seguridad no presenta ninguna dificultad técnica a la hora de
ser aplicada si presenta complejas dificultades desde el punto de vista
político.
Arquitectura del
DWH

 Un sistema DWH debe resolver necesidades propias de negocio y es por


ello que será “sponsorizado” por las personas del negocio que harán uso
de el.

 Un DWH también sigue determinadas especificaciones de diseño, un


DWH no es un DWH simplemente por que alguien dice que lo es.
Arquitectura del
DWH

 Como detectar un DWH


 Funcionalidad (¿Para que sirve?)
 Número de Consultas “ad-hoc” (personalizadas) de los usuarios
 Número de consultas personalizadas por día y por usuario-día
 Número de usuarios de informes standard
 Numero de usuarios, usuarios-día de informes standard
 Número de informes standard
 Volumen del histórico a almacenar en meses, trimestres o años.
 Volumen de datos típico para almacenar (diario,semanal o
mensual)
Arquitectura del
DWH

 Dependiendo de las respuestas a las preguntas descritas


anteriormente se pueden establecer cuatro categorías:

 OLPT – sistema transaccional de operaciones


 ODS operational data store
 OLAP online analytical processing
 DM / DW Data mart / data warehouse
Arquitectura del
DWH

OLPT ODS OLAP DM/DW


Funcionalidad Operacional Operacional/Decisional Decisional Decisional/Estrategica
Herramientas de usuario final Cliente Servidor/WEB C/S-WEB C/S C/S-WEB
tecnologia BBDD Relacional Relacional Cubica Relacional
Nº de transacciones Alto Medio Bajo Bajo
Tamaño de la transacción Bajo Medio Medio Alto
tiempo de tranascción Corto Medio Medio Alto
Tamaño BBDD en GB 1 OLPT * 2 - OLPT *10 OLPT * 2 - OLPT *10 OLPT*2-OLPT*100
Modelado de datos Entidad Relación Entidad Relación N/A Dimensional
Normalización 3-5 NF 3 NF N/A 0 NF
Arquitectura del
DWH

 Otra de las mejores formulas para distinguir un DWH de uno que no


lo es consiste en recabar la siguiente información:
 Número de tablas
 El número de registros de la tabla mayor
 El tamaño en GB de la tabla mayor
 La media de registros de las mayores tablas
 El tamaño medio en GB de las mayores tablas
 La mayor transacción (rollback) en GB. (Oracle)
 El mayor segmento temporal necesitado en GB. (Oracle)
Arquitectura del DWH

 Los sistemas DWH por lo general tienen menos tablas y mas


grandes, mientras que los operacionales tienen mas tablas y mas
pequeñas.

 En el caso de Oracle y otras BBDD que utilicen mecanismos de


recuperación de transacciones (rollback), así como segmentos o
áreas temporales de ordenación de resultados, los sistemas DWH
necesitarán que estas áreas sean al menos tan grandes como el
objeto mas grande de la base de datos, mientras que los sistemas
operacionales tan sólo necesitan que el espacio sea suficiente para
dar cabida a la transacción mas voluminosa del sistema.
Arquitectura del DWH

OLPT ODS OLAP DM/DW


Nº de tablas 1-miles 1-miles OLPT/10 OLPT/10
Media de Registros por tabla miles -millones miles - millones millones millones
Media de tamaño por tabla (GB) 1 a 99 1 a 99 1 a 99 1 a 999
Nº de registros de la tabla mas grande miles - millones miles - millones miles - millones miles - cientos de millones
Tamaño de la Tabla mas grande (GB) 1 a 99 1 a 99 1 a 99 1 a 999
Tamaño de los segmentos de Rollback 1 a 100 Mb 1 a 100 Mb N/A 1 a 999 Gb
Tamaño de los segmentos temporales 1 a 100 Mb 1 a 100 Mb N/A 1 a 999 Gb
Arquitectura del DWH

 El sistema DWH debe:


 Debe hacer la información de la compañía accesible de manera
sencilla a usuarios ofimáticos no avanzados
 Debe presentar la información de la compañía de manera
consistente y estructurada
 Debe adaptarse al cambio en el entorno y adaptable a las
necesidades puntuales del usuario
 Debe ser lo suficientemente seguro para proteger el activo mas
importante de la compañía ... La información.
 Debe servir a la funcionalidad ultima, de mejora de la toma de
decisión.
 Los usuarios deben de aceptar el sistema si se pretende que su
implementación y uso se haga con éxito.
Arquitectura del
DWH
 ¿cómo puede responder un sistema a la pregunta?

 ¿por qué no se han alcanzado los resultados de ventas previstos?

 Hasta el momento no existe ningún sistema informático que pueda


dar respuesta a una pregunta de este tipo, imaginemos una
sentencia SQL que pudiese dar respuesta a esta pregunta.
Arquitectura del
DWH
 Para que esta pregunta tenga respuesta a través del sistema es
necesario realizar diversas consultas sistemáticas:

 Así la primera pregunta sería:

 ¿Para cada producto, cuales son las ventas acumuladas del


año?

 El sistema nos devolvería una lista de los productos con sus


cifras de venta correspondientes
Arquitectura del
DWH
 Si quisiera que me mostrase tan sólo aquellos productos que su
cifra de ventas es menor que la cifra de ventas objetivo
 ¿cuáles son las ventas acumuladas para cada uno de los
productos en las que las ventas actuales son menores que los
objetivos?
 Después de descubrir cuales son los productos que no alcanzan la
cifra objetivo, analizará cada caso para ver cual es la posición del
producto con respecto al mercado, etc...
 El mismo análisis podría hacerse para localizar áreas de venta donde
no se están alcanzando los objetivos, vendedores que no están
alcanzando la cifra, etc...
Arquitectura del
DWH

 Un director de ventas se preguntará probablemente:


 ¿qué productos son los que mas se venden y cuales los que
menos?
 ¿cuáles son los clientes mas importantes?
 Por cifra de negocio (facturación)
 Por rentabilidad
 ¿cuál es el periodo medio de compra de mis clientes?
Arquitectura del
DWH
 ¿cómo clasificaría a mis clientes?
 A,B,C
 Basado en cifra de negocio
 Basado en rentabilidad
 Basado en periodo medio de compra
 Otros...
 ¿qué clientes han reducido su periodo medio de compra?
 ¿qué clientes han reducido su importe medio de compra?
Arquitectura del
DWH

 ¿qué clientes no han comprado nada en los últimos 3 meses?


 ¿por qué no se están cumpliendo los objetivos de ventas?
 A nivel local
 A nivel provincial
 A nivel regional
 A nivel nacional
 ...
 ...
Arquitectura del DWH

 Una de las mayores obligaciones de un sistema de soporte a la toma


de decisiones (DSS) es la disponibilidad de la información.

 Tener acceso a los datos correctos en el momento correcto y con un


tiempo de respuesta aceptable.
Estructura de un DWH

 Un data warehouse es un sistema orientado a determinados


“asuntos” o áreas del negocio, es también un sistema integrado, no
volátil y cambiante en el tiempo, que da soporte para la toma de
decisiones de los niveles ejecutivos y gerenciales de una empresa.
 Como es evidente cada tipo de negocio posee su propio conjunto de
“asuntos” o áreas. Es decir una empresa dedicada a la distribución
probablemente posea una serie de áreas comunes de análisis con el
resto de empresas que se dediquen también a la distribución.
 El data warehouse contiene datos corporativos estructurados de
manera granular.
Estructura de un DWH

 Está integrado
 Esta es la característica más importante
 Los datos llegan de diferentes orígenes y son cargados en el data
warehouse.
 Los datos en su camino hacia el data warehouse pueden sufrir
transformaciones fruto de cálculos realizados sobre los mismos.
 Conversión de datos
 Reformateado (Reformatted)
 Cambio de secuencia (Resequenced)
 Sumarizados (Summarized)
 Etc...
Estructura de un DWH

 Como resultado de las transformaciones y cargas los


datos una vez que residen en el data warehouse poseen
una única imagen física.
Estructura de un DWH

 Históricamente las distintas aplicaciones de una compañía


manejaban la información de diferente manera, con diferentes tipos
de datos.
 No existía por tanto un consistencia a la hora de la codificación, nombres
de entidades y atributos, tipo de datos, etc.., ...lo que hacía más difícil su
integración en un único sistema de explotación de la información
generada.
 Es por tanto tarea del sistema data warehouse especificar un único
repositorio que integre las diferentes peculiaridades de los distintos
orígenes de datos. (Una única estructura de datos para distintos orígenes
de datos con estructuras diferentes)
Estructura de un DWH

 No es volátil (nonvolatile)
 Al contrario que en los sistemas transaccionales OLPT, los datos en el
data warehouse no son accedidos de manera regular de registro en
registro.
 Los data warehouse son cargados (generalmente en masa) y accedidos
sólo para su consulta no para su actualización.
 Cuando el data warehouse se carga genera una foto fija en el tiempo de
los datos (snapshot).
 Cuando se producen nuevas cargas fruto de cambios en los sistemas
OLPT una nueva foto fija de los datos nuevos se generará de manera
que los datos ya cargados junto con los nuevos pasarán a formar parte
del histórico del data warehouse.
Estructura de un DWH

 Variable en el tiempo
 Que el data warehouse sea variable en el tiempo implica que cada
dato incluido en el data warehouse ha sido obtenido en un
momento en el tiempo.
 En algunos casos el registro tiene un campo de fecha.
 En otros casos esa fecha se corresponde con la fecha en la que
se valido la transacción que lo contenía.
 En cualquier caso un registro siempre está sometido a una
variable de tiempo.
Estructura de un DWH

 El horizonte temporal de un sistema data warehouse es mayor


al de un sistema operacional.
 Operacional 60-90 días.
 DWH 5 a 10 años.
 El data warehouse debe contener más datos históricos que
cualquier otro sistema.
Data Marts

 Pequeños data warehouses que pueden trabajar


independientemente o interconectados.

 El data mart depende de la arquitectura seleccionada


para el data warehouse.
Data Marts

 Siempre ha existido una discusión acerca de si la


arquitectura del DWH debía estar basada en Data Marts,
o bien completamente centralizado.

 Los data warehouses centrales (“enterprise wide data


warehouses”)
 Proyectos mas arriesgados
 Altos costes
 Tiempos altos de desarrollo.
Data Marts

 Los data marts


 Se pueden implementar de manera rápida y sencilla
 Son proyectos de bajo riesgo.
 presentan los datos desde la perspectiva de un proceso simple de
negocio (subject).

 La cantidad de datos históricos contenidos en un data


mart deben ser dictados por los requerimientos del
negocio.
Data Marts
 Arquitectura en Bus
 Los Data marts en bus
 Albergan subconjuntos de datos del repositorio central.
 seleccionados
 preparados
 Son usados por parte de un grupo de usuarios.
 Los data marts también son conocidos como data warehouses
departamentales (departamental data warehouses).
 No debe ser estrictamente departamental ya que es relativo a un
proceso de negocio no a un departamento.
 facturación, llamadas del call center, movimientos de almacén,
procurement, etc...
Data Marts
 ...arquitectura en bus
 Algunas veces los diseños de arquitecturas data warehouse
basados en data marts caen en el error de diseñar estructuras de
tela de araña donde múltiples extracciones de un mismo origen de
datos se cargan en diferentes data marts. Con esto diseños se
debe tener en cuenta el mayor coste así como la posibilidad de
inconsistencias de los datos en los diferentes data marts.
 Las arquitecturas basadas en estructuras de tela de araña no
tienen en cuenta que el diseño de los distintos data marts debe
estar basado en el proceso de negocio y no en la organización
departamental de la compañía. En los sistemas centrados en el
proceso (process-centric) los dato son extraídos una sola vez y
almacenados en un único lugar.
Data Marts

 ...arquitectura en bus
 Un analista que quiera obtener datos accederá de esta manera al
data mart relevante.
 Un repositorio de metadatos provee la información acerca de los
diferentes data marts (directorio de data mart)
DWH y Business Intelligence

 El experto en sistemas de “Business Intelligence” Drury


Jenkins define la relación de soporte directo entre los
sistemas business intelligence y los data warehouse
haciendo un especial énfasis en el modelado de los datos
y el análisis de los mismos.
DWH y BI

 Business Intelligence (BI) es la habilidad de tomar mejores


decisiones de manera más rápida.
 Un entorno de BI enfocado al cliente provee de la infraestructura
necesaria para proveer la información necesaria para maximizar
la base de clientes.
 Esta infraestructura combina datos, canales y técnicas analíticas
para mejorar las satisfacción del cliente y el beneficio a través de
mayores puntos de contacto.
 Para los especialistas en Marketing esto es la habilidad de
contactar al cliente correcto en el momento correcto, en el lugar
correcto y con el producto correcto.
DWH y BI

 Los canales de contacto incluyen los tradicionales así como


los basados en intercambio electrónico (email, web).

 Las técnicas analíticas incluyen análisis de perfiles, modelos


predictivos, análisis de series de tiempo, y otras técnicas.
DWH y BI
 El aspecto clave de proveer de la información necesaria es la
creación de una vista global para cada cliente individual y sus
necesidades.
 La integración de los datos de los clientes debe proveer de una
vista única y uniforme de los clientes a lo largo de la organización.
 El objetivo último es alcanzar una foto completa de la interacción
de un cliente con la organización entera, sólo se puede lograr
mediante la obtención y almacenamiento de los datos apropiados.
 Además de los datos suplidos de demografía y otros datos
externos, son necesarios numerosos datos internos de la
organización.
DWH y BI

 Demasiado habitualmente, los datos obtenibles están


fragmentados y repartidos sobre muchos lugares y sistemas,
escondidos en numerosas bases de datos de transacciones, o
herramientas de productividad personal como hojas de calculo o
“micro-bases de datos”.

 Esta dispersión de los datos, ha sido debido en gran manera por


el crecimiento de los sistemas de aplicaciones cliente/servidor en
la pasada década ....
DWH y BI
CRM

 Que persigue el CRM...

 Ante todo conocer al cliente


 Cual es el valor del cliente para la compañía
 Cuales son los clientes más importantes para la compañía
 Cuales son los prospectos potenciales
 Cuales son los clientes / productos más rentables
CRM

 ...Que persigue el CRM...


 Cual es el resultado de mis campañas publicitarias
 Nº de impactos
 Nº de clientes nuevos
 Incremento de ventas
 CrossSelling
 Optimizar la interacción con el cliente
 Trato personalizado
 Ofertas personalizadas
 Etc...
CRM

 Ámbito tecnológico del CRM


 El término CRM es confuso desde el punto de vista técnico
 Se produce un paralelismo entre CRM y herramientas CRM
 El CRM es una filosofía/estrategia de compañía que se lleva a cabo por
medio de herramientas especializadas en los distintos ámbitos del
tratamiento de la información referida al cliente.
 Hoy por Hoy todo es CRM...
CRM

BI

Análisis
BBDD
Transacciones Data mining
Negocio
ERP

ETL

Data Warehouse
BBDD
Herramientas CRM Relaciones
Con clientes

Contact-Center

Reporting
Granularidad

 La granularidad es el concepto mas importante en el diseño de un


DWH. Por que es directamente proporcional al volumen de datos
que almacenará el DWH.
 La granularidad se refiere al nivel de detalle o resumen de los datos
contenidos en el DWH.
 A mayor detalle mayor nivel de granularidad.
 A menor detalle menor nivel de granularidad.
Granularidad

 Podemos tomar por ejemplo un registro de datos correspondiente a


una venta, el registro individualmente se correspondería con el mayor
nivel de granularidad, mientras que una consulta acerca del total de
ventas del mes se correspondería con un nivel de granularidad menor.

 Evidentemente a mayor nivel de granularidad mayor será el volumen


de información , mientras que al contrario, a menor granularidad
menor volumen de datos.
Granularidad

 Los datos de origen en los sistemas operacionales se encuentran en


su mayor grado de granularidad, es por tanto durante la fase de
extracción de los datos de los sistemas operacionales hasta el DWH
cuando se produce la transformación de los mismos para adecuar su
granularidad a la definida en el diseño del DWH de destino.

 A través del nivel de granularidad se puede predecir el crecimiento en


número de registros del DWH, así como los requerimientos de
espacio para el mismo.
Granularidad

 La granularidad también afectará como es evidente al


tiempo de respuesta de las consultas al DWH. A mayor
nivel de granularidad menor rendimiento y mayor tiempo
de respuesta. A menor nivel de granularidad del sistema,
menores recursos son utilizados (procesador, memoria,
almacenamiento, etc.).
Los beneficios de la granularidad

 El nivel de granularidad de un DWH es la clave de que


esos datos puedan ser usados por diferentes tipos de
usuarios en diferentes ocasiones y de diferente manera
a lo largo de la compañía.
Los beneficios de la granularidad
 Por ejemplo los datos de facturación de una compañía pueden ser
usados por usuarios de Marketing, Ventas, Operaciones y Financiero.
Todos estos departamentos hacen uso de los mismos datos. Para el
departamento de Marketing será interesante conocer las ventas por
áreas geográficas por meses, para el departamento de ventas será
necesario ver los datos desde la perspectiva de las ventas por
vendedor o delegación comercial semanalmente. Para el
departamento de operaciones será conveniente ver los datos desde
la perspectiva de ventas por línea de producto con carácter mensual
para de esa manera poder prever el nivel óptimo de stock en los
almacenes. Finalmente para el departamento financiero lo
importante será ver los datos desde la perspectiva de la rentabilidad
de las ventas por línea de producto.
Los beneficios de la granularidad
Financiero

Operaciones

Ventas

Marketing

Ventas por mes Ventas por mes


Ventas por mes

Ventas por semana


Ventas por mes
Ventas por semana

Ventas por semana Ventas por área geografica


(52)
Ventas por área geografica
Ventas por mes (52)
Ventas por vendedor
(52)
Ventas por área geografica
(52)
Ventas por vendedor Ventas por producto
Ventas por área geografica (52)
(52) (20)

Ventas por vendedor Ventas por nivel de


(52) Ventas por producto
rentabilidad
(20)
(5)
1 registro al mes 52 registros al mes 10816 registros al mes 216320 registros al mes 1081600 registros al mes
20 bytes/mes 1040 bytes/mes 216320 bytes/mes 4326400 bytes/mes 21632000 bytes/mes

Mayor Granularidad
Beneficios de la granularidad

 Otro de los beneficios de la granularidad es la flexibilidad.


 A mayor nivel de granularidad mayor flexibilidad. Esto significa que
los requerimientos futuros de obtención de datos podrán ser
acomodados con el diseño actual del DWH. Los cambios son
inevitables, por esto nuestro DWH debe estar preparado para los
distintos requerimientos de datos que sobrellevan los cambios del
entorno del negocio.
 Otro de los beneficios de la granularidad es que a mayor
granularidad mayor contenido histórico de actividades y
eventos de la compañía.
Beneficios de la granularidad

 A través del ejemplo anterior veamos el siguiente supuesto:


 ¿Cuantas unidades ha vendido Paco del producto limpia-hogar
Malvarossa la semana del 3 al 10 de Diciembre del año pasado.?

 En el nivel 1 de granularidad nuestra pregunta no tendría


respuesta.
 En el nivel 2 de granularidad tampoco
 Ni en el nivel 3.
 En el nivel 4 de granularidad nuestra respuesta si podría ser
contestada.
 En el nivel 5 de granularidad también podría ser contestada.
Beneficios de la granularidad

 La principal diferencia entre los distintos niveles de


granularidad se centra en el volumen de recursos del
que hace uso cada nivel. (a mayor nivel mayores
recursos).
Granularidad múltiple

 Es posible en determinados sistemas DWH definir dos o


más niveles diferentes de granularidad para dar solución
de manera más eficiente a diferentes peticiones de datos.
Granularidad múltiple
 En nuestro ejemplo mientras el departamento de Operaciones y
Financiero requiere un alto nivel de granularidad, los departamentos
de ventas y Marketing requieren niveles de granularidad menor, para
facilitar la labor de estos últimos´, diseñaremos por tanto dos
repositorios de datos con distinta granularidad el primero de ellos
tendrá un nivel 3 de granularidad y será el usado por el
departamento de marketing y el departamento de Ventas, mientras
que el segundo repositorio contendrá una granularidad de nivel 5 y
dará respuesta a las necesidades de los departamentos de
operaciones y financiero.
Granularidad múltiple

 Los beneficios de la granularidad multiple se centran en un mayor


rendimiento en tiempo y recursos para aquellas peticiones dirigidas
contra el repositorio de mayor granularidad. El reparto de peticiones
entre los diferentes repositorios por granularidad afectará de
manera positiva ya que también el número de peticiones sobre cada
uno de los repositorios bajará.

 Evidentemente la puesta en marcha de diferentes grados de


granularidad afecta al espacio de almacenamiento.
Granularidad múltiple

 Gracias a su bajo coste (básicamente almacenamiento), eficiencia,


facilidad de acceso y habilidad para responder cualquier consulta, la
granularidad múltiple generalmente a dos niveles, es la mejor
elección posible en arquitecturas donde el nivel de detalle del DWH
es muy alto y el volumen de datos es también muy alto.

 Un único nivel de granularidad muy detallada está solo indicada en


casos en los que el volumen de datos es relativamente pequeño.
Estimación de la Granularidad

 El principal condicionante en la elección del nivel de granularidad de


nuestro sistema DWH se centra en el número de registros o volumen
de datos que contendrá la base de datos, evidentemente este
volumen tan sólo podrá ser predictivo por estimación. Es importante
también efectuar en esta fase un ejercicio para estimar el crecimiento
del propio DWH.
Estimación de la granularidad

 El primer paso para calcular el espacio que ocupará el DWH es la


identificación de las tablas que serán construidas.

 2º estimar el tamaño de un registro en cada una de las tablas.


Evidentemente el tamaño exacto nunca se conocerá ya que una filas
consumirán mas espacio y otras menos, por lo que nosotros
tomaremos como cifra una estimación basada en la cantidad
mínima de espacio y por otro lado la cantidad máxima de espacio
necesario para una fila.
Estimación de la granularidad
 3º estimar en el horizonte de un año el máximo y mínimo numero
de registros que contendrá cada una de las tablas. Si la información
contenida se refiere a clientes o ventas es necesario usar las
estimaciones de ventas del negocio recogidas en el plan de negocio
para conocer el crecimiento de las tablas asociadas a las ventas. Si
no existe un plan de negocio, será necesario utilizar otras variables
predictivas como puede ser la situación económica, la cuota de
mercado y el crecimiento en cuota de mercado, las previsiones de la
competencia, etc...

 4ª una vez que se han hecho las previsiones es necesario repetir el


proceso pero esta vez con un horizonte de 5 años.
Estimación de la granularidad

 5º Establecer el número y tamaño de los índices necesarios para las


distintas tablas del DWH, es conveniente crear índices en cada una
de las variables condicionantes que formarán parte de las consultas
(campos que estarán en las cláusulas WHERE de las sentencias
SQL).

 6º Realizar la operación
 (Máximo número de filas posible en un año X tamaño máximo pro
registro) + espacio de índices
 (Mínimo número de filas posible en un año X tamaño mínimo por
registro) + espacio de índices
Estimación de la granularidad

 Repetir esta operación por cada una de las tablas del DWH

 Por lo general las estimaciones siempre se quedan pequeñas


debido al crecimiento del DWH, por lo que es aconsejable sumar
un espacio extra de al menos un 30% sobre la estimación.
Estimación de la granularidad

 Una vez obtenidos los resultados de las predicciones es necesario


aplicar la siguiente tabla para revisar si el nivel de granularidad es
correcto:

número de registros a 1 año vista Número de resgristros a 5 años vista


100.000.000 1.000.000.000 Existen datos no usados por lo que se
debe de replantar niveles inferiores de
granularidad
10.000.000 100.000.000 Posiblemente existan datos no usados
por lo que se recomienda replantearse
el nivel de granularidad en el diseño del
1.000.000 10.000.000 DWH
Nivel de granularidad Aceptable
100.000 1.000.000 Nivel de granularidad Adecuado
Estimación de la granularidad

 Un importante componente de los sistemas DWH es el


concepto de “Overflow storage” almacenamiento
desbordado.

 El almacenamiento desbordado se produce cuando son


almacenados datos que no son usados de manera frecuente.
 Relación directa con la granularidad del diseño.
 A mayor nivel de granularidad mayor es la probabilidad de que se
produzca el desbordamiento.
Estimación de la granularidad

 Con el transcurso del tiempo mayor desbordamiento.


 Almacenar los datos poco consultados en dispositivos externos
CD-ROM - DVD
 El uso del almacenamiento externo tiene implicaciones de
rendimiento.
 Seleccionar cuidadosamente que datos .
 Un reparto inteligente de los datos entre los dispositivos externos e
internos del sistema permitirá un mejor rendimiento a menor coste.
Estimación de la granularidad

 Por ello a la hora de diseñar el almacenamiento de los datos es


necesario discernir entre que datos son necesarios con frecuencia
y cuales no.

 El uso de sistemas sobredimensionados, asumiendo su


coste, nos permitiría aplicar el mayor nivel de
granularidad deseado.
Estimación de la granularidad

 La granularidad viene determinada a través de la


funcionalidad del usuario, si el usuario ve los datos y el
nivel de detalle es correcto para ellos entonces el nivel
de granularidad es el apropiado.
Estimación de la granularidad

 El nivel de granularidad debe tener en cuenta las


necesidades futuras y la evolución del propio negocio.
 Un nivel mayor de granularidad significará estar mas preparado
para el futuro.
Caminos para establecer la
granularidad
 Realizando consultas sobre los orígenes de datos con los distintos
niveles de granularidad posible.

 Realizando las operaciones de agregación, que serán realizadas


desde el origen de los datos en su camino hacia el data warehouse.

 Realizando las operaciones estadísticas como medias, etc.. que serán


realizadas desde el origen de datos en su camino hacia el data
warehouse.
Caminos para establecer la
granularidad
 Identificando los mayores y menores valores en el destino.

 Identificando tan sólo los datos que son estrictamente necesarios en


el destino.

 Realizando pruebas de muestreo de datos utilizando conjuntos


representativos de datos mediante condicionantes.
Particionamiento

 Podemos definir particionamiento de los datos a nivel lógico y a nivel


físico, para una mejor compresión, mantenimiento y navegación a través
del DWH

 El particionamiento físico se define a través de la propia implementación


física del diseño.

 En el particionamiento de datos lógico el criterio común mas usado es el


áreas temáticas (subject areas).
 Podemos definir un área temática como una porción del DWH que es
clasificada desde una perspectiva consistente.
Particionamiento

 Para el DWH el particionamiento aporta:


 Acceso más flexible a los datos
 Una gestión de los datos mas sencilla y eficiente
 Asegura la escalabilidad del DWH
 Habilita la posibilidad de que los elementos del DWH sean
portables y compartidos con otros DWH o archivados en distintos
dispositivos de almacenamiento externo.
Particionamiento

 Habitualmente se realizan particiones de grandes volúmenes de


datos dividiéndolos en piezas mas pequeñas. Al hacer esto
determinadas operaciones con los datos serán más fáciles de
realizar:
 Reestructuración de datos
 Indexación
 Escaneado Secuencial (Full Scans)
 Reorganización
 Recuperaciones
 Monitoreado
 Auditoría
Particionamiento

 Los criterios de particionamiento de los datos son


variados pero quizás los mas representativos sean:
 Periodo de tiempo (Fecha, mes , trimestre, semestre, año)
 Por áreas geográficas
 Por producto o línea de negocio
 Por unidad organizativa
 ...
 Por combinaciones de lo anterior
Particionamiento

 La elección de un criterio de particionamiento está basado e los


requerimientos del propio negocio y las características físicas de la
propia base de datos.

 Cada herramienta de gestión de bases de datos (DBMS) tiene su


propia manera de implementar el particionamiento a nivel físico, y
pueden ser bastante diferentes entre ellas.
Particionamiento

 Se puede realizar un particionamiento controlado por la propia


aplicación.
 Añadirá la posibilidad de portar los datos entre distintos DWH.
 El particionamiento depende de:
 El modelo de datos multidimensional
 La granularidad de los datos
 Las capacidades del motor de base de datos
Áreas temáticas (subject areas)

 Un DWH está siempre orientado a áreas temáticas (subject areas).


 Área temática = área de interés para el negocio
 El DWH está siempre orientado a áreas especificas de la organización
como pueden ser:
 Clientes
 Productos
 Beneficios
 Ventas
 ...
Áreas temáticas

 Esta orientación tiene su base en la forma en la que se plantean las


consultas a un DWH, en un sistema operacional se formulan
preguntas del tipo:
 ¿Se puede pagar la factura del cliente XXXX?
 Mientras que en el DWH las preguntas son más del tipo:
 ¿qué productos se estan vendiendo mejor?
 ¿cuáles son las oficinas que venden menos?
 ¿cuáles son los vendedores menos rentables?...
Áreas temáticas

 Las áreas temáticas son la forma más común de particionamiento


lógico en el DWH.

 Para extraer una lista de los candidatos a áreas temáticas, debemos


hacernos la pregunta:

 ¿cuáles son los intereses del negocio?


Áreas temáticas
 Para la localización de las áreas temáticas se utiliza el
método 5W1H que consiste en preguntarse acerca de:
cuando, donde, quien, que, por que y como (When,
where, who, what, why, how) acerca del negocio.

 Si se hace la pregunta en quien está interesado el negocio (who)


podrá aparecer:
 Clientes, empleados, gerentes, proveedores, competidores, etc...
 Sobre la pregunta cuando (when)
 Este año, trimestralmente, mensualmente, anualmente, semanalmente,
etc...
 Donde (where)
 Provincias, ciudades, países, etc...
Áreas temáticas
 Una vez extraída la lista de candidatos a áreas temáticas, habrá que
seleccionarlas, descomponerlas y redefinirlas mas claramente.

 Como resultado podremos finalmente obtener una lista de áreas


temáticas que representen claramente a nuestra organización.

 El rol principal del área temática es la determinación de la unidad


para un análisis efectivo, modelado e implementación del DWH, lo
cual pude servir también como medida para discernir las áreas de
interés de nuestro DWH.
Exploración y data mining
(minería de datos)
 Los sistemas de Data mining o minería de datos se han
hecho populares durante la pasada década.
 para obtener mayor información
 para obtener una mejor comprensión del negocio
 para encontrar nuevos caminos e ideas para ganar potencial en
otros mercados.
 Para controlar gastos y costes
Exploración y Data mining

 Es una practica extendida en nuestros días la integración de los


sistemas de data mining en las aplicaciones transaccionales de
negocio.

 Por ejemplo call centers donde al recibirse una llamada el sistema localiza
el cliente del cual proviene y le adjudica un operador de acuerdo a su perfil
como cliente.
 Sistemas que generan listados de receptores de publicidad directa con
ofertas adecuadas a su perfil de cliente.
 Sistemas que alertan sobre el riesgo de perdida de un cliente o, de la
modificación de sus hábitos de compra.
 Etc...
Exploración y Data mining

 Esta integración en los sistemas operacionales de la


compañía requiere:

 Integración de los sistemas de Data mining con las bases de datos


de producción.

 Integración de los sistemas de Data Mining con los sistemas DWH.


Exploración y data mining

 El principal caldo de cultivo de los sistemas de data


mining son los sistemas DWH, ya que:

 Permiten el análisis de los datos sobre granularidades significativas


para el sistema
 No influyen en el rendimiento del sistema operacional.
 Buscan patrones de comportamiento a lo largo de todos los
sistemas de la compañía y para ello es fundamental la integración
y estandarización del DWH.
Exploración y Data Mining
Definición

DATA WAREHOUSE

Preparación de los datos

Minería de datos DATA MINING

Interpretación de resultados

FUNCIONES
DE SCORING
DE
RESULTADOS

Implementación de
resultados
Exploración y data mining

 Consultas e Informes
 Permite responder a determinadas preguntas , obteniendo la
información relevante desde el DWH, transformándola para el contexto
apropiado y mostrándola de manera legible. En esta técnica las
consultas realizadas están basadas en dos dimensiones.
 Los usuarios finales están especialmente interesados en:
 Procesado de valores numéricos...totales de ventas, cantidades vendidas.
 Cálculo o investigación de medidas de calidad como satisfacción de clientes,
retrasos en procesos de negocio, etc..
 Predicciones de análisis de transacciones de negocio, análisis de tendencias,
etc...
Exploración y Data Mining

Definición de la consulta

Acceso y obtención del dato

Manipulación del dato


y cálculo

Preparación del informe

Entrega del informe


Exploración y data mining
 Análisis multidimensional
 El análisis multidimensional es una manera de extender las capacidades
de las consultas e informes que como vimos se basan en dos únicas
dimensiones..
 Básicamente sustituye a la necesidad de realizar múltiples consultas, para
ello los datos son estructurados de manera que se habilita un acceso
rápido y fácil a las respuestas de las preguntas que típicamente se realizan.
 Por ejemplo:
 ¿Cuantas unidades del producto X se han vendido en el mes de Enero, por un
determinado vendedor, in una provincia en particular?
 Cada una de las partes de la pregunta es lo que se llama una dimensión.

Enero Vendedor provincia


Exploración y data mining

 Mediante el mecanismo de precálculo integrado en las herramientas de


procesamiento multidimensional, todas las respuestas a las distintas
consultas (dimensiones) se obtienen en la misma orden.
 los datos no son recalculados sino que simplemente son accedidos y
mostrados.
 El análisis multidimensional permite a los usuarios tener a su alcance un
gran número de factores interdependientes asociados a un escenario del
negocio.
 Los usuarios pueden acceder a la información explorando los datos en
diferentes niveles de detalle.
Exploración y data mining

Totales de Ventas en el primer trimestre

Totales de Ventas en Enero Totales de Ventas en Febrero Totales de Ventas en Marzo


Drill Down

Roll Up
Vendedor 1 Vendedor 2 Vendedor 1 Vendedor 2 Vendedor 1 Vendedor 2

Mad Sev Mad Sev Mad Sev Mad Sev Mad Sev Mad Sev
Exploración y Data mining

 Data Mining
 Es una técnica relativamente nueva es muy diferente de las técnicas de
consultas e informes y del análisis multidimensional, su principal
diferencia se basa en lo que se llama técnica de descubrimiento.

 La técnica de descubrimiento (discovery technique) no consiste en realizar


una consulta especifica a los datos, en cambio esta técnica utiliza
algoritmos que analizan los datos y devuelven los resultados descubiertos.
A diferencia de las dos técnicas anteriores el data mining busca respuesta
a consultas que no han sido previamente realizadas.
Exploración y Data Mining

 Los descubrimientos pueden tomar la forma de encontrar


significado a determinadas relaciones o patrones de datos.

 Después de realizar un descubrimiento, este puede convertirse en


una regla que sea utilizada para hacer predicciones basadas en esa
regla.
Exploración y Data Mining
 Las técnicas de data mining se utilizan habitualmente para análisis
estadístico de los datos y para descubrir el conocimiento
(knowledge discovery)

 El análisis estadístico descubre patrones no habituales en los datos


aplicando técnicas matemáticas y estadísticas para la explicación de los
patrones.
 Una vez descubierto el patrón este se utilizará entonces para hacer
previsiones y presupuestos.
 Algunas de las técnicas estadísticas incluyen:
 análisis linear y no lineal
 análisis de regresión
 Análisis multivarianza
 Y análisis de series en tiempo.
 “knowledge discovery” extrae información no conocida de manera
implícita de los datos.
Exploración y Data Mining
 El soporte de las técnicas de análisis de data mining está soportado por
los propios datos del negocio . Existe en el DWH un alto nivel de
complejidad en los datos almacenados y en sus interrelaciones que es
difícil de descubrir sin el uso de técnicas de data mining.

 La minería de datos ofrece nuevos revelaciones acerca del negocio dando


respuesta a preguntas que nunca se nos hubiese ocurrido preguntar.
Exploración y Data mining

Gestionado por
Asistido por el Gestionado por
el
Analista los datos
Analista

Consultas
Análisis
e Data Mining
Multidimensional
informes
Exploración y data mining
 OLAP data mart (OnLine Analitical Processing)  análisis multidimensional
 Están diseñados para soportar análisis multidimensional usando herramientas de
software OLAP.
 El data mart en este caso se diseña utilizando las técnicas de esquema en estrella o
tecnologías propietarias de cada herramienta basadas en el concepto de “hipercubo”
(Hypercube).
 El esquema en estrella o sistema de gestión de base de datos multidimensional
(multidimensional database management system MD DBMS) es el indicado en data
marts de los que se conocen perfectamente los requerimientos, estos son estables y
las consultas a los mismos son fácilmente predecibles con tiempos de respuesta
razonables e informes mas o menos recurrentes.
Exploración y Data Mining
 Almacenes de exploración (Exploration warehouse)
 Los almacenes de exploración están diseñados para dar soporte real a la exploración
o navegación puramente customizable por el usuario “ad-hoc”.
 Después de un descubrimiento a través de la exploración, este puede dar lugar a la
creación de un nuevo data mart , para que otros usuario se beneficien del hallazgo a
partir de es momento.
 Almacenes estadísticos (Data mining or statistical warehouses)
 Es un data mart especializado diseñado para dar soporte a los analistas e
investigadores.
 Aplicaciones analíticas customizables (Customizable analytical applications)
 Permite la customización efectiva de aplicaciones genéricas.
Diseño del DWH

 Asumamos las siguientes aserciones como ciertas antes de continuar:


 El DWH debe tener un enfoque corporativo
 En el DWH podremos encontrar datos de todas las unidades de negocio y
departamentos de la compañía.
 Se asume también que los datos contenidos en el DWH no violan ninguna de
las reglas de negocio establecidas para la compañía.
 El DWH en todo momento debe mostrar su adherencia a las reglas de negocio de la
compañía.
Diseño del DWH
 El DWH debe ser cargado con datos lo más rápida y eficientemente posible.
 El DWH debe configurarse y diseñarse para soportar múltiples tecnologías de
BI, tanto presentes como futuras.
 El DWH debe acomodarse fácilmente a cambios tanto en las estructuras de
datos como en los datos propiamente dichos.
Diseño del DWH

 El tipo de análisis que será realizado con el DWH o Data mart puede
determinar el tipo de modelado de datos y los contenidos del mismo.
 Como los análisis basados en consultas e informes y los análisis
multidimensionales requieren metadatos explícitos y sumarizaciones
especificas, es importante que el modelo de datos que de soporte al
análisis contenga estos elementos.
Diseño del DWH

 Debemos tener en cuenta también que:


 El análisis multidimensional también permite las operaciones “drill down” y
“roll up”.
 La minería de datos habitualmente trabaja mejor con el mayor nivel de detalle
disponible (granularidad alta).
Diseño del DWH

 Desde principios de los años 90 uno de los gurus del DWH , Ralph
Kimball, propuso nuevas técnicas de diseño basadas en las tradicionales
bases de datos relacionales para lograr que los DWH fueran
comprensibles y rápidos.
 Estas técnicas de diseño que actualmente se conoce como modelado de
datos dimensional (dimensional modeling) hacen que los sistemas DWH
sean más rápidos a través de la limitación del número de enlaces (joins)
entre las distintas tablas que forman parte del sistema.
Diseño del DWH

 Las características ideales que debe seguir el modelo de datos en el


sistema DWH son:
 No redundante.
 Debemos por todos los medios a nuestro alcance evitar la redundancia de los datos
en nuestro DWH. La redundancia de datos añade trabajo extra a las operaciones de
extracción transformación y carga (ETL), así como a los diseñadores que tendrán que
preocuparse de que todos los elementos redundantes tengan el valor correcto en el
momento correcto.
 A mayor redundancia mayor complejidad en la carga de los datos.
 Evidentemente cierto grado de redundancia a veces es inevitable e incluso
aconsejable, a este tipo de redundancia la llamaremos redundancia controlada.
Diseño del DWH
 Estable
 Hemos repetido en varias ocasiones que nuestro DWH deba acomodarse a los
cambios con facilidad y estabilidad, esto se logra mediante la independencia de
nuestro DWH a los cambios en procesos, aplicaciones y tecnología que por otra parte
son los cambios que ocurren mas frecuentemente en una organización. Por otra parte
nuestro DWH debe estar preparado para añadir nuevas entidades o atributos cuando
se añaden nuevas capacidades de análisis BI o se incorporan nuevos data marts.
 Es importante por tanto que el diseñador de nuestro DWH use técnicas de modelado
que permitan la incorporación de cambios en el modelo sin que sea necesario la
redefinición de las entidades y atributos ya implementados.
Diseño del DWH
 Consistente
 La consistencia de los datos contenidos en el DWH es sin duda la característica
esencial. Los modelos de datos creados para el DWH deben reconciliar las
discrepancias de concepto y físicas entre los distintos orígenes de datos, tanto a nivel
estructural como a nivel de tipo de dato. Evidentemente este esfuerzo inicial es
previo a cualquier tipo de carga de datos.
Diseño del DWH

 El modelo de datos resultante para el DWH, se trasladará a un diseño de


base de datos que sea:
 Fiable
 No contendrá contradicciones en la forma de nombrar entidades o atributos, en
referencias de unos a tros, así como en la documentación
 Compartido
 El DWH resultante de la implementación de este modelo de datos podrá ser accedido
por múltiples procesos y usuarios desde cualquier parte de la compañía.
Diseño del DWH
 Flexible y adaptable al cambio
 La base de datos resultante no condicionará en una dirección u otra el entorno BI
creado. Todas las oportunidades tecnológicas que se presenten permanecerán
disponibles para la compañía.
 LA base de datos resultante podrá acomodar nuevas entidades y atributos,
manteniendo al integridad de los elementos implementados.
 Correcto
 El modelo de datos proveerá una representación de cómo y que clase de información
es usada en la compañía-
Diseño del DWH

 Como cualquier proyecto de sistemas, un proyecto de DWH debe seguir


las distintas fases del ciclo de vida de desarrollo de sistemas, es por tanto
lógico además de aconsejable no comenzar realizando un diseño de los
modelos de datos que soportarán nuestro DWH antes de haber recabado
todos los requerimientos por parte de los usuarios y de la dirección de la
compañía.
Diseño del DWH

 En la mayoría de proyectos de DWH se abre un debate entre los


integrantes tecnologicos del equipo acerca de si los modelos deben estar
basados en diseños en estrella, normalizados o de-normalizados o
simplemente planos. Por razones varias muchos de los analistas
prefieren aplicar a todos los diseños su “particular” técnica de diseño
(quizás por que se sienten comodos con una tecnica en particular, o
sencillamente por que desconocen el resto) y por esta rázón forzan a los
ditintos data marts a tener un solo tipo de diseño.
Diseño del DWH

 Lo mas recomendable en el diseño de data marts es que los esquemas


de base de datos que los soportan deben estar diseñados de acuerdo al
uso que se va ha hacer de ellos y del tipo de información que se
solicitará al data mart.
Diseño del DWH

 Probablemente basándome en mi experiencia el mejor diseño para los


distintos tipos de data marts será el que no preestablezca o
predetermine las relaciones entre los datos, ya que de esta manera
condicionará el uso del mismo, y el fin último para el que debemos
dirigir nuestro diseño es que este soporte todas y cada una de las
posibilidades de análisis de datos.
Diseño del DWH

 Para determinar cual es el mejor diseño de base de datos posible para el


data mart es aconsejable construir una matriz como la de la figura que
compare el grado de volatilidad de los datos con respecto al tipo de
diseño seleccionado así como con respecto a la frecuencia o tipo de
consulta a realizar sobre el data mart.
Diseño del DWH

latencia

Planas

Normalizadas

De-normalizadas

Esquema en estrella

volatilidad

Repetitivas Customizables Algoritmicas


Diseño del DWH – Estructura de
los datos
 Para DWH podemos distinguir tres tipos básicos de datos:
 Datos en tiempo real (real-time data)
 Datos derivados (Derived data)
 Datos reconciliados (Reconciled Data)
 Se puede configurar el DWH basándose en estos tres tipos, con la
consideración adecuada a las características particulares de cada
implementación.
Diseño del DWH – Estructura de
los datos
 Dependiendo de la naturaleza de los sistemas operacionales, el tipo de
negocio, y el número de usuarios que pueden acceder al DWH, debemos
combinar los tres tipos de datos para crear el mas adecuado modelo de
datos para el DWH.
Diseño del DWH – Estructura de
los datos
 Datos en tiempo real (Real-Time data)
 Los datos en tiempo real representan el estado actual del negocio. Por
supuesto, estos son los datos que utilizan los sistemas operacionales.
 Los datos en tiempo real muestran la realidad cambiante del negocio
transacción a transacción.
 Los datos en tiempo real muestran por otra parte el mayor nivel de detalle lo
que se representa como el mayor nivel de granularidad.
 Habitualmente estos son accedidos en modo lectura-escritura por las
transacciones operacionales.
Diseño del DWH – Estructura de
los datos
 Estos datos no tienen por que ser patrimonio exclusivo de los sistemas
operaciones ya que es practica habitual la realización de transacciones
distribuidas que reparten los datos entre sistemas operacionales y DWH en
tiempo real.
 De igual manera los datos en tiempo real pueden ser almacenados también
en Almacenes de datos operacionales (ODS Operational Data Stores) para su
posterior análisis y carga en sistemas DWH sin afectar al rendimiento de los
sistemas operacionales.
 El uso de datos en tiempo real en el DWH, implica que estos datos deben ser
debidamente tratados para asegurar la adecuada calidad del dato,
probablemente sumarizados y transformados a un formato mucho más
fácilmente comprensible y manipulable por los analistas de negocio.
Diseño del DWH – Estructura de
los datos
 Evidentemente, también en el caso de que los datos en tiempo real
provengan de distintos orígenes y sistemas, deberán ser reconciliados antes
de ser cargados en el DWH.
Diseño del DWH – Estructura de
los datos
 Datos Derivados (Derived Data)
 Los datos derivados son datos que han sido creados probablemente a raíz de
operaciones como sumas, medias, o agregaciones de operaciones en tiempo
real a través de un proceso intermedio de transformación previo a la carga.
 Los datos derivados pueden ser detallados o resumidos dependiendo de las
especificaciones de requerimientos del DWH.
 Pueden representar una vista del negocio en un momento determinado del
tiempo o pueden ser datos históricos referidos a un periodo de tiempo.
Diseño del DWH – Estructura de
los datos
 Los datos derivados son tradicionalmente usados para la toma de decisiones y
el análisis del negocio.
 La sumarización de los datos en nuevos registros derivados requiere grandes
volúmenes de datos a analizar y por consecuencia necesitará de grandes
recursos para su procesamiento.
 La eficiencia de los procesos de creación de datos derivados en tiempo y
manera es vital y una de las tareas mas importantes que los analistas han de
resolver.
Diseño del DWH – Estructura de
los datos
 Datos Reconciliados (Reconciled Data)
 Los datos reconciliados son datos en tiempo real que han sido tratados para ajustarse a
los niveles de integración y calidad que se requieren para ser usados en análisis de
datos.
 La consistencia es uno de los requerimiento de calidad inexcusables.
 Durante el proceso de reconciliación de datos es posible crear y mantener datos
históricos , por lo que los datos reconciliados podrían ser un tipo especial de datos
derivados.
 En algunas ocasiones los datos reconciliados son almacenados en estructuras físicas
temporales requeridas para transformar de manera consistente los datos operacionales.
Diseño del DWH – Estructura de
los datos
 El concepto de EDM – Enterprise Data Model
 Un EDM es una definición consistente de todos los elementos de datos
comunes al negocio. Desde una perspectiva mas abstracta a la mas concreta.
 El EDM incluye a su vez vínculos a los diseños de datos de cada una de las
aplicaciones operacionales.
 A través del EDM se puede intuir una visión y comprensión de los
requerimientos del negocio.
Modelado de datos para el DWH

 El modelador de datos debe responder a la premisa de diseñar las bases


de datos del DWH para soportar de la mejor manera las necesidades de
los usuarios del DWH.
 En el DWH existen dos técnicas básicas de modelado de datos :
 Modelado entidad-relación ER
 Modelado dimensional
Modelado de datos para el DWH

 En la mayoría de los modelos de datos de los sistemas operacionales


actuales los modelos de datos se soportan sobre estructuras de
modelado ER.
Modelado de datos para el DWH

 Con la llegada del DWH la necesidad de técnicas de modelado orientadas


hacia el análisis se han visto incrementadas y con ello ha crecido el
interés por estas técnicas. Con el modelado dimensional, se nos ofrece la
capacidad mejorada de visualizar cuestiones abstractas que surgen del
negocio y los usuarios finales. Mediante el uso de los modelos
dimensionales los usuarios pueden fácilmente explorar y explotar los
datos de manera comprensible.
Modelado de datos para el DWH

 El modelo de datos es una abstracción organizada de los datos que


representan las actividades, recursos y resultados de la organización.
 Sin un modelo de datos la organización de la estructura y del contenido
del DWH sería muy difícil.
 El objetivo de los modelos de datos es conseguir la independencia lógico
/ física
 Como se muestran los datos es completamente independiente de cómo se
almacenarán a nivel físico
Modelado de datos para el DWH

 Por lo que a nivel lógico se refiere, se referirá a los aspectos de


identificación de la entidad o entidades, su descripción y su organización.
 En el nivel físico se tratarán aspectos como la organización, acceso y
almacenamiento de los datos a nivel físico
Modelado de datos para el DWH

 Modelos entidad-relación
 Los modelos ER producen un modelo de datos de una especifica área de
interes usando para ello dos conceptos básicos: Entidades y las relaciones
entre esas entidades. Los modelos ER contienen también Atributos, que son
las propiedades inherentes a las entidades y/o relaciones.
 El modelo ER es una percepción del mundo compuesta por objetos llamados
entidades y las relaciones entre ellos. Las entidades se diferencian unas de
otras a través de sus atributos.
Modelado de datos para el DWH

 El modelado ER se representa mediante un diagrama que usa tres tipos de


graficos para conceptualizar los datos: Entidad, relación y Atributo.
 Entidad
 Una entidad se define como una persona, lugar cosa o evento de interes para el negocio o la
organización.
 Una entidad representa una clase de objeto, que puede ser observado y clasificado por sus
propiedades y caracteristicas.
Modelado de datos para el DWH

 Relación
 Una relación se representa mediante lineas que unen a dos entidades. Una relación se designa
de manera gramatical por medio de un verbo, como pertenece a, tiene. Tla relación entre dos
entidades puede ser definida mediante su cardinalidad. La cardinalidad es el máximo número
de instancias de una entidad que que se relacionan con una instancia de la otra entidad. Las
cardinalidades posibles son:
 Uno a uno 1:1
 Uno a muchos 1:M
 Muchos a muchos M:M (no son válidas en un modelo normalizado)
 Atributos
 Los atributos describen las caracteristicas o propiedades de las entidades. Un nombre de
atributo debe se único en una entidad.
Modelado de datos para el DWH –
Modelado dimensional
 El modelado de datos dimensional usa tres conceptos básicos:
 Medidas (measures)
 Hechos (facts)
 Dimensiones (dimensions)
 En algunos casos el modelado dimensional es más sencillo, más
expresivo y fácil de comprender que el modelado relacional.
 Es relativamente nuevo por lo que no está firmemente definido,
especialmente comparado con las técnicas de modelado relacional.
Modelado de datos para el DWH –
Modelado dimensional
 El modelado dimensional es un conjunto de medidas (measures) que son
descritas por aspectos comunes del negocio.
 Es especialmente útil para sumarizar datos y presentarlos en vistas para
ayudar al análisis de los datos.
 El modelado dimensional se centra en los datos numéricos, como
valores, cuentas (count), pesos, balances y ocurrencias.
Modelado de datos para el DWH –
Modelado dimensional
 Hechos (facts)
 Es una colección de items de datos relacionados.
 Cada hecho generalmente representa un item del negocio, una transacción
del negocio, o un evento que puede ser utilizado para analizar el negocio o un
proceso del negocio.
 En un Data warehouse los hechos (facts) se almacenan donde los datos
numéricos son almacenados.
Modelado de datos para el DWH –
Modelado dimensional
 Dimensiones (dimensions)
 Es una colección de miembros o unidades del mismo tipo.
 Las dimensiones determinan el contexto de fondo para los hechos.
 Las dimensiones son los parámetros sobre los que queremos realizar el
análisis OLAP (online analitical processing).
Modelado de datos para el DWH –
Modelado dimensional
 Si consideramos una base de datos de análisis de ventas, encontraremos entre
otras las siguientes dimensiones.
 Tiempo
 Localización / Provincia
 Clientes
 Vendedor
 Miembros de la dimensión (dimension members)
 Una dimensión puede a su vez contener n miembros.
 Por ejemplo, los meses : enero, febrero, marzo,...,trimestres, cuatrimestres son
miembros de la dimensión tiempo.
Modelado de datos para el DWH –
Modelado dimensional
 Jerarquías de la dimensión (dimension hierarchies)
 Las dimensiones pueden a su vez ser divididas en diferentes jerarquías, cada jerarquía
puede tener a su vez distintos niveles jerárquicos.
Modelado de datos para el DWH –
Modelado dimensional
 Jerarquias de la dimensión

Jerarquía 1 año Jerarquía 2


Semana
semestre semestre
... ...
día
trimestre trimestre

...
mes

...
día
Modelado de datos para el DWH –
Modelado dimensional
 Jerarquias de la dimensión
 Drill down
Modelado de datos para el DWH –
Modelado dimensional
 Medidas (measures)
 Es un atributo numérico de un hecho.
 Por ejemplo las medidas de ventas serían
 El importe de las ventas
 El volumen de ventas
 Las unidades vendidas
 El importe de la materia prima
 ...
 Una medida se determina por la combinación de miembros de las
dimensiones y está situada en los hechos (facts)
Modelado de datos para el DWH –
Modelado dimensional
Modelado de datos para el DWH –
Modelado dimensional
 Tablas de hechos (facts)
 Es la tabla central en el modelo de datos dimensional, en esta table es donde
se almacenan los valores numéricos de las medidas. Se utiliza el termino
hecho (fact) para representar una medida del negocio.
 Una fila de la tabla de hechos representa una medida (measure). Por lo que
una medida es una fila en la tabla de hechos. Todas las medidas de una tabla
de hechos deben tener la misma granularidad.
 Los hechos mas habituales son los numéricos y aditivos, como euros o total de
ventas.
Modelado de datos para el DWH –
Modelado dimensional
 La capacidad de adición es crucial ya que raramente los valores de las tablas
de hechos son recuperados de fila en fila, lo usual es recuperarlos mediante la
suma de una o mas de sus columnas o mediante la cuenta del número de
filas, medias, etc...
 Es importante tener en cuenta que no es aconsejable la introducción de filas
en las tablas de hechos que no representen nada como por ejemplo
(12/12/2003 , 0) en representación de que el día 12/12/2003 no se realizó
ninguna venta, en estos casos es mejor no incluir el registro, de esta manera
el espacio ocupado por la tabla de hechos será util al 100%
Modelado de datos para el DWH –
Modelado dimensional
 Las tablas de hechos representan el 90% o más del espacio ocupado en un
DWH, generalmente las tablas de hechos tienen la tendencia de ser
voluminosas en cuanto a número de registros pero también a tener pocas
columnas (atributos).
 Las tablas de hechos se pueden además clasificar en tres grupos atendiendo a
su nivel de granularidad.
 Transacciones
 Fotos-fijas periódicas (periodic snapshots)
 Fotos-fijas acumulativas (accumulating snapshots)
Modelado de datos para el DWH –
Modelado dimensional
 ...Tablas de hechos (facts)
 Las tablas de hechos de tipo transaccional son las más habituales con
diferencia.
 Las tablas de hechos poseen dos o mas “foreign keys” (FK) que conectan las
tablas de hechos con las tablas de dimensiones.
 La tabla de hechos por otra parte por lo general posee una clave primaria
formada por el conjunto o un subconjunto de las claves externas FK que
posee (clave primaria compuesta). Cada tabla de hechos en un modelo
dimensional tiene una clave compuesta, por lo que también podemos afirmar
que cada tabla en un modelo dimensional que posee una clave compuesta es
una tabla de hechos.
Modelado de datos para el DWH –
Modelado dimensional
 Las relaciones entre las tablas de hechos y las tablas de dimensiones son
siempre relaciones de tipo muchos a muchos M:M. Por lo que las tablas que
presenten este comportamiento relacional en un modelo dimensional serán
tablas de hechos mientras que el resto serán tablas de dimensiones.
 La composición de la clave primaria en la tabla de hechos no tiene por que
relaizarse con todas las claves externas ya que probablemente la agrupación
de unas pocas de ellas garantice la unicidad del registro.
Modelado de datos para el DWH –
Modelado dimensional
 En la mayoría de los casos no tiene ninguna utilidad la introducción de una
clave primaria no compuesta para identificar unívocamente a cada registro de
la tabla de hechos. Al contrario de nuevo podemos ocupar un espacio extra
para añadir esto cuando realmente no es necesario, con las consecuencias
implícitas de almacenamiento y rendimiento. Aunque si la naturaleza del
negocio requiere la inclusión de varias filas con los mismos valores entonces si
debemos plantearnos la creación de una clave primaria, siempre que sea
necesario hacer una distinción clara entre las filas con el mismo contenido.
Modelado de datos para el DWH –
Modelado dimensional
 Tablas de hechos (facts)
 Mucho del éxito de nuestro DWH dependerá de cómo se implementen las
tablas de hechos.

ventas diarias
clave de fecha FK
clave de tienda FK
clave de producto FK
cantidad
valor
Modelado de datos para el DWH –
Modelado dimensional
 Tablas de hechos (facts)
 Hemos de tener en cuenta que las tablas de hechos pueden encontrarse en
tres estados:
 Están siendo Consultadas
 Están siendo cargadas
 Están siendo gestionadas
 No es posible el mantenimiento de índices en un corto espacio de tiempo
 Las tablas de hechos también pueden estar implementadas de diferentes
maneras:
 Sin particionamiento – Sin índices
 Particionadas – Sin índices
 Sin particionamiento – Con índices
Modelado de datos para el DWH –
Modelado dimensional
 Tablas de dimensiones (dimensions)
 Las tablas de dimensiones contienen los descriptores textuales del negocio.
 En un modelo bien diseñado las tablas de dimensiones tienen por lo general
muchos atributos que describen la fila en la tabla de dimensión.
 Las tablas de dimensiones deben contener tantos atributos como sean
necesarios para hacer su contenido lo más comprensible posible. No es
extraño encontrar tablas de dimensiones que contengan entre 50 y 100
atributos.
Modelado de datos para el DWH –
Modelado dimensional
 Por otra parte las tablas de dimensiones por lo general son tablas que
presentan pocos registros en comparación con las tablas de hechos, por lo
general no mas de 1 millón de registros.
 Cada dimensión se define a través de una clave primaria no compuesta (única)
PK que será utilizada para guardar la integridad referencial con cualquier tabla
de hechos con la que esté relacionada.
 Cada uno de los atributos de las tablas de dimensiones serán utilizados para
realizar las consultas como condicionantes, agrupaciones, etc...
Modelado de datos para el DWH –
Modelado dimensional
 En una consulta los atributos de una dimensión son identificables por que
siempre van precedidos de la palabra “por” (by). Quiero saber las ventas por
region, Quiero saber las ventas por mes, Quiero saber las ventas por producto,
...por vendedor, etc.
 Los atributos de las tablas de dimensiones juegan un papel vital en los
modelos de datos dimensionales ya que ellos son el origen de las
condicionantes en las consultas y de los resultados de las mismas. Los
atributos de las tablas de dimensiones son la clave para hacer el DWH usable
y comprensible.
Modelado de datos para el DWH –
Modelado dimensional
 Un DWH será tan bueno como atributos de las tablas de dimensiones posea.
El poder del DWH es directamente proporcional a la calidad y profundidad de
los atributos de sus dimensiones.
 Cuanto mas tiempo pasemos definiendo atributos con sentido para el negocio
mejor será nuestro DWH.
 Cuanto mas tiempo pasemos poblando nuestras tablas de dimensiones con
valores para los distintos atributos mejor será nuestro DWH.
Modelado de datos para el DWH –
Modelado dimensional
 ...tablas de dimensiones (dimensions)
Modelado de datos para el DWH –
Modelado dimensional
 Atributos en las dimensiones
 Los atributos deben ser palabras reales en lugar de abreviaciones. Esto nos ayudará
en la implementación del DWH con respecto a los usuarios del mismo, ya que
contribuye a su facilidad de uso y compresibilidad por parte de los usuarios. Los
atributos típicos para una dimensión de producto por ejemplo incluirían una
descripción corta de 10 a 15 caracteres, una descripción larga de 30 a 50 caracteres,
nombre de la marca, categoría o familia de producto, tipo de empaquetado, tamaño ,
peso y otras características. Aunque se definan atributos numéricos dentro de las
dimensiones, conservarán su carácter de dimensión siempre que se tomen como
descripciones textuales, por ejemplo, el atributo código postal está representado por
un número aunque su uso es textual no vamos a realizar operaciones con este valor,
mas que para definir un área geográfica concreta.
Modelado de datos para el DWH –
Modelado dimensional
 ...tablas de dimensiones (dimensions)
 Jerarquia de las dimensiones
 Las tablas de dimensiones frecuentemente representan estructuras jerarquicas entre
distintas entidades, por ejemplo la dimensión producto, incluye un atributo marca
que puede permitir a su vez la agrupación de los productos por marca, lo mismo
ocurre con la familia de productos. Para cada fila en la dimension de producto se
almacenará el nombre de la marca y el nombre de la familia a la que pertenece,
aunque de esta forma estamos almacenando información redundante, pero esta
operación se realiza para evitar nuevas relaciones (joins) en las consultas que se
traducirian en decrementos del rendimiento del sistema.
Modelado de datos para el DWH –
Modelado dimensional
 Debemos resistir nuestro impulso de almacenar tan solo el código de la marca y crear
una vista separada para todas las marcas. Esto es lo que se conoce como diseño de
copo de nieve (snowflake). Por lo general las tablas de dimensiones presentan un alto
grado de de-normalización.
 Si con la creación de diseños en copo de nieve pretendemos por ello ahorrar espacio
de almacenamiento, hemos de tener en cuenta que las tablas de dimensiones,
raramente representan mas del 10 % del total de almacenamiento del DWH, por lo
que el ahorro no tendrá un impacto significativo, sin embargo si impactará en el
rendimiento y, en la sencillez y comprensibilidad del modelo por parte de los
usuarios.
Modelado de datos para el DWH –
Modelado dimensional

tabla de marcas
Tabla de productos
clave de marca
clave de producto
nombre de la marca
descripcion del producto
clave de marca (FK)
modelo
clave de familia (FK)
tipo de empaquetado
tamaño empaquetado tabla de familias
peso
precio del producto clave de familia
nombre de la familia
Modelado de datos para el DWH –
Modelado dimensional
 ...tablas de dimensiones
 Las tablas de dimensiones son los puntos de entrada a las
tablas de hechos. La definición de unos robustos atributos,
nos traerá capacidades robustas para realizar operaciones
de tipo “slice” y “dice”. Las dimensiones implementan el
interfaz de usuario al DHW.
Modelado de datos para el DWH –
Modelado dimensional

dimensión
tabla de fechas
clave de fecha
fecha
mes
dia tabla de hechos
año ventas diarias
dimensión
Tabla de productos
clave de fecha (FK)
clave de producto clave de tienda (FK)
descripcion del producto clave de producto (FK)
cantidad dimensión
modelo tabla de tiendas
marca valor
familia clave de tienda
tipo de empaquetado provincia
tamaño empaquetado
peso
precio del producto
Modelado de datos para el DWH –
Modelado dimensional
 Diseño en estrella (star join schema)
 Al relacionar las tablas de hechos con las tablas de dimensiones nos da la
impresión de que se dibuja una especie de estrella, donde el punto central es
la tabla de hechos donde convergen todas las tablas de dimensiones.
 Debido a esto este diseño es conocido como diseño en estrella o “star”,
aunque este termino se acuño en los primeros días de los diseños
relacionales.
Modelado de datos para el DWH –
Modelado dimensional
 Una de las primeras cosas que nos llama la atención acerca del diseño es su
simplicidad y simetría. Evidentemente los usuarios se beneficiarán de esa
simplicidad ya que los datos serán mas comprensibles, fáciles de usar y
explorar.
 La simplicidad del modelo también lleva aparejado beneficios en el
rendimiento ya que los optimizadores de base de datos procesarán estos
esquemas de manera mas eficiente cuando existen pocas relaciones entre las
entidades (joins).
Modelado de datos para el DWH –
Modelado dimensional
 Diseño en estrella
 En el gráfico se muestra como
dimensión
los atributos de las tabla de fechas
clave de fecha
dimensiones definen las fecha
mes
etiquetas de las columnas del dia
año
tabla de hechos
ventas diarias
informe , mientras que las dimensión
Tabla de productos
clave de fecha (FK)
tablas de hechos proveen los clave de producto clave de tienda (FK)
descripcion del producto clave de producto (FK)
valores numéricos. modelo cantidad
valor
dimensión
tabla de tiendas
marca
familia clave de tienda
tipo de empaquetado provincia
tamaño empaquetado
peso
precio del producto
suma suma
Mes Marca Provincia Importe de Ventas Cantidad Vendida
Enero Orbea Madrid 4.598,00 € 3
Enero Marin Madrid 2.345,00 € 2
Enero Marin Sevilla 12.678,00 € 6
Febrero Specialized Madrid 2.346,00 € 1
Febrero Marin Madrid 1.235,00 € 1
Febrero Orbea Madrid 2.345,00 € 4
Modelado de datos para el DWH –
Modelado dimensional
 Diseño en “copo de nieve” (snowflake)
 El modelo copo de nieve es el resultado de la descomposición de una o más
de las dimensiones, que a veces poseen jerarquías.
 La estructura de este modelo muestra la estructura jerárquica de las
dimensiones muy bien.
 Su principal desventaja es la perdida de comprensibilidad para con los
usuarios, y la perdida de facilidad, así como una devaluación del rendimiento
del sistema ya que las operaciones de relación entre las distintas entidades
son mayores y en consecuencia el motor de base de datos se resiente.
Modelado de datos para el DWH –
Modelado dimensional
Modelado de datos para el DWH –
Modelado dimensional
 En definitiva no son aconsejables por:
 Añadir niveles adicionales de relaciones “joins”
 Complica la construcción del usuario final (mas tablas para elegir, a no ser que se
creen vistas para facilitar esta tarea.)
 Producen trabajo extra a los optimizadores de base de datos y esto da como
resultado la creación de planes de ejecución peores.
 Tan solo se reduce algo de espacio de almacenamiento en la Base de datos , a un
coste de tiempos de consulta mucho mayores.
Modelado de datos para el DWH –
Modelado dimensional
 A evitar...
 Centrarse demasiado en la tecnología y en los datos en lugar de enfocarse en
las necesidades del negocio y los objetivos del proyecto.
 Tomar el proyecto como un super-proyecto de varios años en lugar de hacer
pequeños pero mas efectivos y manejables esfuerzos de desarrollo.
 Gastar esfuerzos en la construcción de una estructura de datos normalizada
antes de pensar en la construcción de un área de presentación basada en
modelos dimensionales.
Modelado de datos para el DWH –
Modelado
 Prestar mas atención dimensional
a los problemas de rendimiento y facilidad de desarrollo en
lugar de centrarse en el rendimiento de las consultas y la facilidad de uso para los
usuarios.
 Hacer las áreas de presentación para los usuarios demasiado complejas con
estructuras de datos complejas.
 Cargar sólo datos sumarizados en las áreas de presentación dimensionales de los
datos.
 Suponer que el negocio, los requerimientos y análisis de información son estáticos, así
como la tecnología que lo soporta.
 Negarse a reconocer que el éxito de un DWH se centra en la aceptación por parte de
los usuarios.
Modelado de datos para el DWH –
Modelado dimensional
 Pasos básicos para la transformación de modelos OLTP (operacionales)
en diseños en estrella.
 De-normalizar las relaciones de tipo “lookup”
 De-normalizar las relaciones maestro-detalle
 Crear y poblar una dimensión de tiempo
 Crear jerarquías de datos en las dimensiones
 Considerar el uso de claves subrogadas sin sentido *
Modelado de datos para el DWH –
Modelado dimensional
 ¿cuál es la mejor herramienta para modelar datos para el DWH?

 Tu cerebro
Modelado de datos para el DWH –
Modelado dimensional
 De-normalización
 En nuestro ejemplo productos
codigo producto
 La tabla de productos claramente
nombre producto
viola la tercera norma formal: fecha inicio
 Nombre de familia depende por fecha fin
completo de codigo de familia codigo familia
nombre familia
 Nombre de subfamilia depende por codigo subfamilia
completo de codigo de subfamilia nombre subfamilia
codigo marca
 Nombre marca depende por nombre marca
completo de codigo marca ancho
alto
peso
cantidad por paquete
Modelado de datos para el DWH –
Modelado dimensional
 Evidentemente al incumplir la 3ª norma formal nuestro diseño se encontrará en 2ª
norma formal (las normas son acumulativas). Por tanto si se viola la tercera norma
formal nos impide estar en normas formales superiores.
 Si normalizaramos la tabla para cumplir la tercera norma formal entonces estaríamos
creando un esquema en “copo de nieve” (snowflake), y como hemos visto
anteriormente esto es altamente desaconsejable.
 Si para evitar la de-normalización optamos por realizar vistas, estaremos en el mismo
problema ya que las vistas no son más que consultas preescritas, que cuando se hace
referencia a ellas se ejecutan, con el consiguiente coste de rendimiento.
Modelado de datos para el DWH –
Modelado dimensional
 Consultas a esquemas en estrella
 Por lo general una consulta a un esquema en estrella contendrá:
 Funciones de agrupación (GROUP BY)
 Contendrá una relación (JOIN) de una tabla de hechos con una o mas tablas de
dimensiones.
 Tendrá muchos condicionantes (WHERE) usando las columnas de las tablas de
dimensiones.
 Hará un escaneado de muchas filas para devolver un número relativamente bajo de
filas.
Modelado de datos para el DWH –
Modelado dimensional
SELECT SUM (a.cantidad), SUM (a.valor), b.mes, c.marca, d.provincia
FROM ventas_diarias a,
tabla_de_fechas b,
tabla_de_productos c,
tabla_de_tiendas d
WHERE a.clave_de_fecha = b.clave_de_fecha
AND a.clave_de_producto = c.clave_de_producto
AND a.clave_de_tienda = d.clave_de_tienda
AND (b.mes = ‘enero’ OR b.mes = ‘febrero’)
AND (d.provincia = ‘madrid’ OR d.provincia = ‘sevilla’)
GROUP BY b.mes, c.marca, d.provincia

Mes Marca Provincia Importe de Ventas Cantidad Vendida


Enero Orbea Madrid 4.598,00 € 3
Enero Marin Madrid 2.345,00 € 2
Enero Marin Sevilla 12.678,00 € 6
Febrero Specialized Madrid 2.346,00 € 1
Febrero Marin Madrid 1.235,00 € 1
Febrero Orbea Madrid 2.345,00 € 4
Modelado de datos para el DWH –
Modelado dimensional
 Modelado de fechas
 El concepto de tiempo es sin duda el elemento mas generalmente utilizado en
la construcción de informes para la empresa. No obstante es una de las
materias más complejas a la hora de diseñar el DWH, ya que la manera en la
que se implemente este dato podrá afectar de manera significativa al
rendimiento.
Modelado de datos para el DWH –
Modelado dimensional
 En primer lugar debemos de tener en cuenta que la fecha es de crucial
importancia para los usuarios de sistemas de reporting, ya que les permiten
definir claramente el comportamiento a través del tiempo del negocio, o de
un área del mismo. Es normal por tanto que se soliciten informes de datos
agrupados por fechas de distinta forma debido a la flexibilidad que confiere el
dato de fecha, por ejemplo un informe de ventas puede ser agrupado por:
 Ventas diarias
 Ventas semanales
 Ventas en días laborables
Modelado de datos para el DWH –
Modelado dimensional
 Ventas en fines de semana
 Ventas en días festivos
 Ventas Mensuales
 Ventas Trimestrales
 Ventas Cuatrimestrales
 Ventas Semestrales
 Ventas Anuales
Modelado de datos para el DWH –
Modelado dimensional
 Modelado de fechas
 Tal como se ha apuntado anteriormente el diseño de nuestro DWH con
respecto a la fecha de las tablas de hechos puede condicionar en gran medida
el rendimiento del sistema. En el ejemplo que se muestra vemos como una
tabla de hechos (ventas diarias) posee un campo de fecha (Fecha de Venta) y
existen dos dimensiones (Tabla de productos y tabla de tiendas).
Modelado de datos para el DWH –
Modelado dimensional

dimensión
tabla de tiendas
clave de tienda

tabla de hechos provincia


ventas diarias
dimensión
Tabla de productos clave de tienda (FK)
clave de producto clave de producto (FK)
fecha de venta
descripcion del producto cantidad
modelo valor
marca
familia
tipo de empaquetado
tamaño empaquetado
peso
precio del producto
Modelado de datos para el DWH –
Modelado dimensional
 Modelado de fechas
 En caso de que quisiéramos obtener la suma de ventas por mes en cada una de las tiendas, por cada
uno de los productos, tendríamos que realizar una consulta como la siguiente (*):

SELECT SUM (a.cantidad), SUM (a.valor),


EXTRACT (MONTH FROM a.fecha_de_venta) AS mes, c.marca, d.provincia
FROM ventas_diarias a, tabla_de_productos c, tabla_de_tiendas d
WHERE a.clave_de_producto = c.clave_de_producto
AND a.clave_de_tienda = d.clave_de_tienda
AND ( EXTRACT (MONTH FROM a.fecha_de_venta) = ‘enero’
OR EXTRACT (MONTH FROM a.fecha_de_venta) = ‘febrero’
)
AND (d.provincia = ‘madrid’ OR d.provincia = ‘sevilla’)
GROUP BY EXTRACT (MONTH FROM a.fecha_de_venta), c.marca, d.provincia
Modelado de datos para el DWH –
Modelado dimensional
SELECT SUM (a.cantidad), SUM (a.valor),
EXTRACT (MONTH FROM a.fecha_de_venta) AS mes,
EXTRACT (YEAR FROM a.fecha_de_venta) AS agno, c.marca, d.provincia
FROM ventas_diarias a, tabla_de_productos c, tabla_de_tiendas d
WHERE a.clave_de_producto = c.clave_de_producto
AND a.clave_de_tienda = d.clave_de_tienda
AND ( EXTRACT (MONTH FROM a.fecha_de_venta) = 'Enero'
OR EXTRACT (MONTH FROM fecha_de_venta) = 'Febrero'
)
AND (d.provincia = 'Madrid' OR d.provincia = 'Sevilla')
GROUP BY EXTRACT (MONTH FROM a.fecha_de_venta),
EXTRACT (YEAR FROM a.fecha_de_venta),
c.marca,
d.provincia
Modelado de datos para el DWH –
Modelado dimensional
 El resultado de la consulta anterior, tan sólo nos agruparía las ventas por
meses (enero, Febrero, Marzo, etc...) sin tener en cuenta a que año pertenece
cada venta por lo que para hacer aún más correcta la búsqueda escribiríamos:
Modelado de datos para el DWH –
Modelado dimensional
 Modelado de Fechas
 Como es evidente al tener que realizar el cálculo del mes y del año sobre la
marcha en la ejecución de la consulta, el rendimiento de la consulta será muy
pobre, mas teniendo en cuenta el número de registros sobre nuestra tabla de
hechos (ventas diarias).
 El uso de funciones especificas para realizar cálculos sobre datos de fecha
además de suponer un serio decremento del rendimiento del DWH,
condiciona el sistema a el uso del motor de base de datos para el cual ha sido
concebido ya que cada motor de bases de datos posee sus propias funciones
para realizar cálculos de fecha con diferente sintaxis.
Modelado de datos para el DWH –
Modelado dimensional
 Para solucionar esto es usual en los sistemas de DWH la creación de una
dimensión de tiempo separada, esto se traduce en la creación de una entidad
que desglosará cada una de las fechas en:
 Fecha (fecha/alfanumérico)
 12/12/2003
 Día de mes (numérico)
 1..31
 DIA de la semana (alfanumérico)
 Lunes, Martes, Miércoles, Jueves, Viernes, Sábado, Domingo.
 Número de mes (numérico)
 1..12
 Nombre Mes (alfanumérico)
 Enero, Febrero, Marzo, Abril, Mayo, Junio, Julio, Agosto,
Septiembre,Octubre,Noviembre,Diciembre
Modelado de datos para el DWH –
Modelado dimensional
 Número de Trimestre (numérico)
 1..4
 Nombre de trimestre (alfanumérico)
 Primer Trimestre, Segundo Trimestre, Tercer Trimestre, Cuarto Trimestre
 Número de Cuatrimestre (numérico)
 1..3
 Nombre de Cuatrimestre (alfanumérico)
 Primer Cuatrimestre, Segundo Cuatrimestre, Tercer Cuatrimestre
 Número de Semestre (numérico)
 1,2
 Nombre de Semestre (alfanumérico)
 Primer Semestre, Segundo Semestre
Modelado de datos para el DWH –
Modelado dimensional
 Año (Numérico)
 ...1990,1991,1992,1993,1994...
 Festivo (booleano/alfanumérico/numérico)
 Si,No
Modelado de datos para el DWH –
dimensión Modelado dimensional
tiempo
clave de fecha
dia
dia de la semana
mes
nombre mes
trimestre dimensión
nombre trimestre
cuatrimestre tabla de tiendas
nombre cuatrimestre clave de tienda
semestre provincia
nombre semestre
anyo
festivo tabla de hechos
ventas diarias
dimensión
Tabla de productos
clave de fecha (FK)
clave de producto clave de tienda (FK)
descripcion del producto clave de producto (FK)
modelo fecha de venta
marca cantidad
familia valor
tipo de empaquetado
tamaño empaquetado
peso
precio del producto
Modelado de datos para el DWH –
Modelado dimensional
 Modelado de fechas
 En muchos casos se da la circunstancia de que determinados periodos de
tiempo no coinciden plenamente con el calendario gregoriano, tal es el caso
de compañías en las que el año natural (Enero->Diciembre) no coincide con el
año fiscal, o con lo que se denomina ejercicio. También algunas empresas
tienen el ejercicio dividido en distintas áreas que no tienen por que coincidir
con las definidas en el calendario del año natural, esto es por ejemplo cuando
una empresa tiene dividido el ejercicio en periodos trimestrales (quarters)
que no coinciden con los del año natural o dividen el ejercicio con otras
consideraciones (primavera, verano, otoño, invierno), etc..
Modelado de datos para el DWH –
Modelado dimensional
 Para dar solución a estos casos utilizaremos también la misma dimensión de
tiempo y añadiremos los campos específicos para detallar esta información
particular sobre la fecha en la que ha ocurrido un hecho (fact).
 Periodo
 1..n
 Nombre Periodo
 ....
 Ejercicio Fiscal
 ....
 Ejercicio comercial
 ....
Modelado de datos para el DWH –
Modelado dimensional
 Temporada
 Alta, baja
 Invierno, verano, otoño, primavera
 ....
 Etc..
Modelado de datos para el DWH –
Modelado dimensional
 Modelado de fechas Natural / Gregoriano
Especifico de la
empresa

3 Septiembre Septiembre

2002 Octubre 1 Octubre

4 Noviembre Noviembre

Diciembre Diciembre

Enero 2 Enero

1 Febrero Febrero

Marzo
2003 Marzo

Abril 3 Abril

2 Mayo Mayo

2003
Junio Junio

Julio 4 Julio

3 Agosto Agosto

Septiembre Septiembre

Octubre 1 Octubre

4 Noviembre Noviembre
2004
Diciembre Diciembre

Enero
2 Enero

2004 1 Febrero Febrero

Marzo Marzo

3
Modelado de datos para el DWH –
Modelado dimensional
 Modelado de Fechas Especifico de una
Natural / Gregoriano
empresa de moda

3 Septiembre Septiembre

Otoño
2002 Octubre 1 Octubre

4 Noviembre Noviembre

Diciembre Diciembre
Invierno
Enero 2 Enero

1 Febrero Febrero

Marzo
2003 Marzo

Abril 3 Abril Primavera

2 Mayo Mayo

2003
Junio Junio

Julio 4 Julio Verano

3 Agosto Agosto

Septiembre Septiembre
Otoño
Octubre 1 Octubre

4 Noviembre Noviembre
2004
Diciembre Diciembre

Invierno
Enero
2 Enero

2004 1 Febrero Febrero

Marzo Marzo

Primavera
3
Modelado de datos para el DWH –
Modelado dimensional
dimensión
tiempo
clave de fecha
dia
dia de la semana
mes
nombre mes
trimestre
dimensión
nombre trimestre
cuatrimestre tabla de tiendas
nombre cuatrimestre clave de tienda
semestre
nombre semestre provincia
anyo
festivo
quarter tabla de hechos
nombre quarter ventas diarias
temporada
ejercicio clave de fecha (FK)
clave de tienda (FK)
dimensión clave de producto (FK)
fecha de venta
Tabla de productos cantidad
clave de producto valor
descripcion del producto
modelo
marca
familia
tipo de empaquetado
tamaño empaquetado
peso
precio del producto
Modelado de datos para el DWH –
Modelado dimensional
 Tratamiento de Valores Nulos
 La mayoría de los motores de bases de datos usan el valor nulo (Null) para
representar la ausencia de datos. Evidentemente la base de datos no trata de
igual manera a los nulos que a los blancos (‘’) o ceros (0).
 Los valores nulos en un data warehouse pueden ser encontrados en tres
areas:
 Valores nulos en una clave extranjera (Foreign Key) (FK) de la tabla de hechos
(Fact).
 Valores nulos en los hechos (Facts)
 Valores nulos en los atributos de las tablas de dimensiones.
Modelado de datos para el DWH –
Modelado dimensional
 Valores nulos en una FK (relación) de la tabla de hechos
 La aparición de nulos en esta situación puede ser debida a diferentes razones:
 El valor de la FK no se conocía en el momento de la extracción.
 No se desea que el valor correspondiente se relacione con la dimensión a la que
representa la FK.
 También puede ser debido a un error en la etapa de extracción y carga.
Modelado de datos para el DWH –
Modelado dimensional
 El primero de los casos se da especialmente cuando la tabla de hechos se actualiza de manera
acumulativa, ya que en este caso quedan relejados valores que aún no han ocurrido, por
ejemplo en una tabla de hechos donde se recogen los pedidos, en el día de la actualización
probablemente existan pedidos que no hayan sido entregados aún, de ahí que determinados
valores de los atributos de la tabla de hechos, se encuentren en estado nulo (fecha de
entrega), en la siguiente actualización de la tabla de hechos, esta situación será solventada
para aquellos pedidos, que hayan sido entregados en el intervalo de tiempo entre
actualización y actualización, pero también se generarán nuevos registros incompletos. En este
caso un eventual informe sobre la tabla de pedidos no reflejará aquellos pedidos que estén
pendientes de entrega ya que la join
Modelado de datos para el DWH –
Modelado dimensional
(WHERE pedidos.fecha_de_entrega = fechas.Fecha)
condicionará el resultado y hará que estos pedidos no aparezcan.

Para solucionar este problema es recomendable el uso de un valor especial tanto en la tabla
de hechos como en la tabla de dimensión para identificar la ausencia de datos por ejemplo
en el caso anterior se podría identificar con una fecha inoperativa como 1/1/9999
reflejando esta en la tabla de dimensión con una descripción como: ‘no asignada’, los
efectos de esta solución darán satisfacción a los usuarios de los informes ya que en los
informes no faltará información y todos los pedidos no entregados podrán ser agrupados
en la fecha ‘no asignada’.
Para el segundo y tercero de los casos se debe aplicar una solución similar a la anterior.
Modelado de datos para el DWH –
Modelado dimensional
 Valores nulos en los hechos (facts)
 Este hecho puede tener dos significados, o bien el valor realmente no existe, o bien se
ha producido un error a la hora de generar el registro. Tanto en uno como en otro,
dejar el nulo es lo apropiado ya que los motores actuales de base de datos sustituyen
muy bien los nulos por valor = 0, así que a la hora de realizar funciones agregadas
como SUM, MAX, MIN, COUNT, y AVG no habrá ningún problema, si por el contrario
realizamos la sustitución del valor nulo por el valor cero estaremos degradando la
información ya que no podremos distinguir entre aquellos que el valor es igual a 0 por
que eran nulos o por que tras el cálculo realmente son igual a 0.
Modelado de datos para el DWH –
Modelado dimensional
 Valores nulos en los atributos de las tablas de dimensiones
 La aparición de valores nulos en las tablas de dimensiones puede ser debido a las
mismas causas que en el caso de los nulos en las relaciones (FK) de las tablas de
hechos. En cualquier caso también es aplicable la misma recomendación, si dejamos
los valores nulos en las tablas de dimensiones puede ser confuso para el usuario ya
que aparecerán como dimensiones “blancas” (sin contenido) en los informes y
desplegables de las herramientas de explotación de los datos. Por tanto, al igual que
en el caso anterior la sustitución del valor nulo por una cadena del tipo
“desconocido”, “no aplicable”, etc.. es lo más recomendable.
Modelado de datos para el DWH –
Modelado dimensional
 Hay que tener en cuenta que las herramientas de explotación de los data warehouse,
pueden dar tratamientos diferentes en cada caso a los valores nulos,
independientemente de esto, es recomendable seguir las indicaciones anteriores para
hacer de esta manera a nuestro diseño independiente de la herramienta o
herramientas de explotación del data warehouse.
Visualización del modelo
dimensional Aplicaciones OLAP
 El objetivo fundamental de las herramientas OLAP es: soportar las
consultas “ad-hoc” de los usuarios que analizan el negocio.
 Parecido a una hoja de cálculo pero:
 Trabajan con grandes volúmenes de datos.
 Están optimizados para la manejar términos de negocio (dimensiones geográficas,
dimensiones de tiempo).
 Están combinados con capacidades de generación de informes.
 Trabajan con bases de datos dimensionales.
Visualización del modelo
dimensional Aplicaciones OLAP
 El termino OLAP fue acuñado por E.F Codd en 1993 “On-Line Analytical
Processing” (OLAP).
 Para representar los datos corporativos en diferentes perspectivas
multidimensionales
 Realizando un análisis en línea (on-line) de los datos
 usando fórmulas matemáticas
 técnicas estadísticas más sofisticadas
 agregando y consolidando los datos de acuerdo a las diferentes dimensiones.
 Las investigaciones alrededor de OLAP siempre han estado dirigidas a
mejorar el rendimiento de obtención y manipulación de la información,
contenida en las bases de datos dimensionales.
Visualización del modelo
dimensional Aplicaciones OLAP
 Son frecuentemente comparados con lo que se denominan Bases de
datos estadísticas (statistical databases).
 Una clase de bases de datos que permiten la definición, manipulación,
elaboración y almacenamiento de datos multidimensionales precalculados.
 la principal diferencia entre ambas estriba en que las bases de datos
estadísticas calculan los datos sobre otras bases de datos, mientras que las
bases de datos OLAP representan los datos directamente.
Visualización del modelo
dimensional Aplicaciones OLAP
 OLAP incluye datos de definición de datos (metadatos).
 Realmente los cubos como tal no existen, los cubos se utilizan para
representar o visualizar un modelo dimensional.
 Podemos representar un modelo dimensional con tres dimensiones con
un cubo (cube) tal como el de la figura, en cualquier caso lo habitual es
tener modelos dimensionales con más de tres dimensiones, en ese caso
su representación se realiza con cubos que reciben el nombre de
hipercubos (hypercube).
Visualización del modelo
dimensional Aplicaciones OLAP
 En la figura podemos ver como se representan las cifras de volumen de ventas determinado por la
combinación de tres dimensiones, tiempo, producto y provincia

Granada
Las Palmas
Madrid
Segovia

Bicicletas 3200 1345 2567 1204 6709

Patines 150 245 245 245 340


150

Balones 240 267 120 789 356

Camisetas 1245 3789 2567 130 780

Mochilas 560 125 234 1235 370

Enero Febrero Marzo Abril Mayo


Visualización del modelo
dimensional Aplicaciones OLAP
 Operaciones básicas de OLAP
 Existen cuatro tipos básicos de operaciones en OLAP para el análisis de datos.
 Las operaciones conocidas como “drill down” y “roll up” básicamente van ha definir el nivel de
granularidad con la que queremos analizar los datos,
 las operaciones “slice” y “dice” nos permitirán navegar entre las dimensiones.
 Drill down y Roll up
 Las operaciones “drill down” y “roll up” son utilizadas para mover la vista hacia y desde un mayor
nivel de detalle a un menor nivel de detalle.
 Hacia un mayor nivel de detalle realizamos un “drill down”.
 Para un menor nivel de detalle realizamos un “roll up”.
 La operación de Drill down también se conoce como agregación dinámica.
Visualización del modelo
dimensional Aplicaciones OLAP
Visualización del modelo
dimensional Aplicaciones OLAP
 Slice y Dice
 Las operaciones de Slice (trocear) y dice (dado) se corresponden a las operaciones
para la visualización de los datos a través del cubo.
 Slice y dice son las habilidades para acceder a un data warehouse a través de
cualquiera de sus dimensiones por igual. Las operaciones de Slice y dice realizan el
proceso de separar y combinar los datos de infinitas maneras.
 La operación de Slice realiza un “corte” en el cubo para que los usuarios puedan
centrarse en un área determinada del cubo. También puede decirse que define un
subcubo.
Visualización del modelo
dimensional Aplicaciones OLAP
 La operación dice, rota el cubo hasta una nueva perspectiva, para que los usuarios
puedan ver los datos desde diferentes perspectivas en su análisis de los datos.
 Con estas operaciones el usuario que analiza la información, puede agruparla de una
manera, analizarla, agruparla de otra y realizar otro análisis. Con las operaciones de
slice y dice el usuario posee diferentes perspectivas para el análisis.
Visualización del modelo
dimensional Aplicaciones OLAP
Visualización del modelo
dimensional Aplicaciones OLAP
 Implementación de OLAP
 El siguiente paso se basa en la elección del tipo de almacenamiento del cubo
OLAP.
 La calidad del diseño inicial del proyecto de data warehouse es inversamente
proporcional al coste de la implementación del cubo...
 El diseñador del data warehouse puede seleccionar si quiere establecer un
almacenamiento separado para los cubos, o si quiere almacenarlos junto con
el resto de datos del data warehouse. Esto depende directamente del tamaño
de los datos almacenados y la conexión prevista para la carga de los datos.
Visualización del modelo
dimensional Aplicaciones OLAP
 El diseño ideal de almacenamiento de cubos OLAP es el almacenamiento
independiente en estructuras optimizadas para la naturaleza de las consultas
que se llevan a cabo con OLAP (drill down, roll up, slice, dice), sobre todo en
entornos donde se mueven grandes volúmenes de datos con consultas
frecuentes.
 Las consultas que los usuarios realizan contra los cubos OLAP consumen
grandes recursos del sistema.
Visualización del modelo
dimensional Aplicaciones OLAP
 El almacenaje de los cubos de OLAP es una de las decisiones críticas que se han de tomar a la hora de
diseñar el data warehouse. Es posible almacenar los cubos OLAP de tres maneras:
 MOLAP
 OLAP Multidimensional. En MOLAP, los datos de fuente y las
agregaciones son almacenes en un formato multidimensional. MOLAP es
la opción más rápida para la recuperación de datos, pero requiere de
mucho espacio en disco, aunque en nuestros días esto no es un gran
problema debido al bajo precio de almacenamiento.
Visualización del modelo
dimensional Aplicaciones OLAP
 ROLAP
 OLAP Relacional. Todos los datos, incluyendo las agregaciones se
almacenan dentro de una estructura relacional de base de datos, que
puede estar en la misma localización de la fuente o no. ROLAP es el
método de almacenamiento mas lento en la recuperación de los datos.
ROLAP tiene sentido en pequeños volúmenes de datos.
Visualización del modelo
dimensional Aplicaciones OLAP
 HOLAP
 OLAP Híbrido. HOLAP es una combinación de las anteriores
(MOLAP,ROLAP). Las bases de datos HOLAP almacenan las agregaciones
dentro de una estructura multidimensional, pero el almacenamiento de
los mismos (pre-calculados) se produce de forma relacional. HOLAP
ofrece las funcionalidades de MOLAP,pero, es tan lento como ROLAP.
Visualización del modelo
dimensional Aplicaciones OLAP
 Debido a que los costes de hardware son cada vez mas bajos, MOLAP se
presenta como la mejor opción siempre que sea posible el acceso a una
base de datos o fuente MOLAP independiente. Por otro lado ROLAP es
más conveniente en el caso de que el número de consultas sea reducido
y el volumen de datos relativamente bajo.
Visualización del modelo
dimensional Aplicaciones OLAP
 Seguridad de OLAP
 El almacenamiento de los cubos también beneficia a las políticas de seguridad de los
datos de la empresa ya que, es posible dar acceso a determinados usuarios a todos los
datos dejando plena libertad de actuación con ellos (definición de dimensiones y
medidas), o bien por otra parte dar acceso restringido y limitado a usuarios
dependiendo de su perfil y permisos, a unos u otros cubos OLAP pre-procesados y
almacenados.
 Estas estrategias de seguridad, junto con la posibilidad de almacenamiento de los cubos
OLAP, permiten a las compañías ahorros considerables en hardware y software para el
procesamiento ad-hoc de las consultas OLAP, así como el establecimiento de políticas de
gestión de los datos adecuadas.
Visualización del modelo
dimensional Aplicaciones OLAP

Directivos
Todos los empleados Mandos Intermedios
Comité de dirección

Permisos para acceder a un número


Permiso para acceder a cubos
limitado de cubos predefinidos, Permiso para acceder únicamente a
predefinidos, así como para realizar
dependiendo de las políticas de cubos predefinidos
consultas OLAP ad-hoc sin límite
seguridad aplicables
Carga de datos en el DWH
 La carga de datos del data warehouse, es el proceso por el cual se recogen los
datos desde el origen del sistema transaccional que da soporte a las operaciones
y otros sistemas externos y se añaden al data warehouse o a los distintos data
marts.
 Esta operación es la más complicada en la implementación del DWH, ya que:
 Las estructuras de datos son completamente diferentes
 Pueden presentarse distintos orígenes de datos
 Es normal realizar transformaciones y operaciones de cálculo sobre los orígenes de
datos
 El proceso de transformación y carga están condicionados por:
 Estructura de datos del sistema operacional
 Estructura de datos del propio data warehouse.
Carga de datos en el DWH

 Etapas del proceso de carga del data warehouse


 En el proceso de carga del data warehouse por tanto podemos establecer tres
etapas claramente diferenciadas:
 Extracción
 Transformación
 Carga
Carga de datos en el DWH
 Extracción
 La extracción es el proceso de recogida de los datos desde los sistemas operacionales o
transaccionales u otras fuentes externas de datos.
 El tipo de extracción está por tanto directamente relacionado con el tipo de origen
desde el que se realice la extracción.
 Podemos agrupar los métodos de extracción en 6 técnicas:
 Extracción directa
 Extracción desde el “log” de la Base de Datos
 Extracción ejecutada por disparadores (triggers)
 Extracción asistida por aplicaciones
 Extracción en un punto del tiempo
 Extracción por comparación
Carga de datos en el DWH
 Extracción directa
 La extracción directa genera como resultado una foto fija de los datos (snapshot) en
un momento determinado del tiempo.
 Generando ficheros externos (ASCII CSV, scripts, etc..)
 Generando tablas temporales.
 Impacta en el rendimiento de la BBDD origen (operacional)
 Se realiza en horas valle
 Días de poca actividad
Carga de datos en el DWH
 Extracción desde el Log de la base de datos
 Los datos son extraídos directamente desde los mecanismos de registros de
transacciones de los motores de bases de datos.
 Permite la actualización constante casi en tiempo real de los ficheros de extracción o
del data warehouse, en el caso de actualización directa.
 Tiene un impacto muy bajo, casi nulo, en el rendimiento del motor de base de datos,
por lo que los sistemas operacionales no se ven afectados.
 Requiere de técnicas de programación muy especificas y de un conocimiento
detallado de las estructuras de almacenamiento en los registros de “log” del motor de
base de datos en cuestión, para la extracción tan sólo de aquellos datos que son de
nuestro interés.
Carga de datos en el DWH
 Extracción ejecutada por disparadores (triggers)
 Este tipo de extracción permite también la actualización en tiempo virtualmente real
de los dispositivos de extracción.
 El mayor inconveniente de esta técnica de extracción es que el sistema (la base de
datos) se ve afectada en el rendimiento al ejecutar por cada evento el procedimiento
correspondiente de actualización de la información en el destino,
 Este inconveniente puede verse agravado en el caso de que nuestro sistema esté configurado
para la ejecución anidada de disparadores haciendo que el sistema entre en un estado de
actualización en cascada que puede interferir gravemente en el rendimiento del sistema
operacional.
 El impacto sobre el rendimiento se puede aminorar si los triggers tan sólo realizan
llamadas a una cola externa de ejecución
Carga de datos en el DWH
 Extracción asistida por aplicaciones
 La extracción asistida por aplicaciones permite la realización de extracciones
complejas sobre los distintos orígenes de datos.
 Estas aplicaciones, requieren la programación explícita de procedimientos de
extracción para todas y cada una de las operaciones de extracción que hayan de ser
realizadas.
Carga de datos en el DWH
 Un fallo de programación podría desvirtuar la información extraída.
 Existe la posibilidad de usar herramientas especificas para la extracción “ETL” (Extract
Transforming Load), que suelen ser productos comerciales de probada efectividad.
 Incrementan la productividad a la hora de crear procesos de extracción ya que no requieren de
programación propiamente dicha.
 Por otra parte su costo muchas veces no está justificado.
 Su rendimiento suele ser por lo general inferior a un código nativo optimizado de BBDD.
Carga de datos en el DWH
 Existen en el mercado gran variedad de herramientas ETL que pueden abarcar
soluciones para distintas necesidades y presupuestos, algunas de las mas
representativas son:
 Oracle Warehouse Builder (Oracle)
 Microsoft DTS (Microsoft, incluido en el producto MS SQLServer)
 Powermart (Informática)
 PowerStage, Distribution Agent for VMS (Sybase)
 DataStage (Ascential)
 DataExchange (Pervasive)
 DataPropagator , Visual Warehouse (IBM)
 DecisionBase (Computer associates)
 DecisionStream (Cognos)
 ActaWorks (Acta Technologies)
 Load Plus (BMC)
 Etc..
Carga de datos en el DWH
 Existen no obstante numerosos detractores del uso de este tipo de herramientas, sus
razones para tomar esta postura son:
 Las herramientas ETL no producen un código optimizado y eficiente
 Las herramientas ETL, cuestan dinero, generalmente cuestan más dinero que las horas de
programación que sustituyen.
 En las extracciones asistidas por aplicaciones, al igual que en las dos anteriores, existe
la posibilidad de extraer los datos en tiempo relativamente real, produciendo una
actualización constante del destino de los datos.
Carga de datos en el DWH
 Extracción en un punto del tiempo
 Este tipo de extracción requiere que los registros origen contengan un campo con la
fecha y hora de la última actualización, de esta manera el proceso de extracción podrá
fácilmente distinguir entre aquellos registros que serán transportados hasta su
destino y cuales no. Si un registro ha sido añadido o modificado será enviado a un
fichero o tabla para su posterior procesamiento o transformación.
Carga de datos en el DWH
 Extracción por comparación
 La extracción por comparación es una técnica que se usó mucho en el pasado pero
que actualmente se encuentra en desuso, debido principalmente al rendimiento y
eficiencia de esta técnica.
 Sencilla de comprender y de implementar.
 Consiste en la extracción de una copia del origen de datos (snapshot) en un punto del
tiempo, en la siguiente extracción, se produce de nuevo un nuevo fichero como
resultado de la extracción completa de datos, posteriormente un procedimiento se
encarga de comparar el fichero antiguo con el fichero nuevo para de esta manera
capturar aquellos registros que difieran del fichero original.
Carga de datos en el DWH
En el siguiente cuadro se especifican las diferentes técnicas y su aplicación más adecuada para cada una
de ellas:
Carga de datos en el DWH
 Transformación
 El proceso de transformación convierte los datos extraídos desde los sistemas
operacionales y otras fuentes a un formato y estructura conveniente para la
carga en el data warehouse o el data mart.
 Durante este proceso, es natural que se produzcan datos (metadatos) que
describen tanto el origen como el destino de los distintos valores después de
la transformació.
 Este proceso también se conoce como “mapeado” de campos (mapping).
 Ayudará a resolver las posibles anomalías de los datos en origen
 Ayudará a producir datos de alta calidad .
Carga de datos en el DWH
 Durante el proceso de transformación, se pueden producir transformaciones
generadas por funciones externas.
 Estas transformaciones pueden ser aplicables o bien a nivel de registro o bien a nivel
de columna.
 En el caso de transformaciones para adaptar la estructura de origen a la
estructura de destino, estas se producen al nivel de registro.
 El proceso de transformación puede requerir que los datos extraídos sean
procesados repetidas veces probablemente debido a que los datos de origen
(extraídos) son usados para la carga de distintos registros en el destino.
Carga de datos en el DWH

 Carga
 El proceso de carga es el encargado de recoger los datos previamente
transformados y guardarlos en el data warehouse o data mart de destino.
 Existen cuatro técnicas para el proceso de carga:
 Carga simple (load)
 Añadir (append)
 Mezcla constructiva (constructive merge)
 Mezcla destructiva (destructive merge)
Carga de datos en el DWH
 Carga simple (load)
 La carga simple reemplaza todos los datos del destino con los nuevos datos resultado
de la transformación. Si las tablas de destino no existen son creadas en este proceso.
Carga de datos en el DWH
 Añadir (append)
 Añade los nuevos datos sobre los datos ya existentes en el destino, sin sustituir ni
modificar ninguno de los existentes.
Carga de datos en el DWH
 Mezcla constructiva (constructive merge)
 Añade los nuevos registros sobre el destino y actualiza un valor de fecha que indica la
fecha y hora de la última actualización sobre aquellos registros existentes que están
siendo reemplazados.
Carga de datos en el DWH

 La importancia del modelo de datos


 Debido a los procesos de carga, es muy importante a la hora de diseñar las
estructuras de datos del data warehouse (el modelo de datos), tener en
cuenta los procesos de carga, ya la elección de una u otra estructura con unos
u otros contenidos pueden condicionar la carga del data warehouse, tanto
desde el punto de vista del propio proceso de carga en tiempo y consumo de
recursos como desde el punto de vista de la calidad del dato.
 El modelo de datos del data warehouse condicionará:
 Los orígenes de los datos
 Los intervalos de tiempo entre actualizaciones
 El formato de los datos.
Carga de datos en el DWH
 Dependiendo de si los datos existen o no en los orígenes, los datos deberán
ser creados en el origen o calculados en el proceso de transformación y carga,
por lo que los datos requerirán un mayor nivel de procesamiento con el
consiguiente consumo de tiempo y recursos.
 Otro de los puntos importantes que deben ser tenidos en cuenta a la hora
tanto del diseño del modelo de datos del data warehouse como de los
procesos de carga de los datos es la granularidad del data warehouse.
Ciclo de vida del DWH

 El proceso de desarrollo de un data warehouse es similar al presentado


en el ciclo de vida de desarrollo de sistemas lo que también se conoce
como “Waterfall model”.
Ciclo de vida del DWH

 El ciclo de vida de desarrollo de sistemas


 Etapa 1 -- Viabilidad
 Se especifican los beneficios de implementar el sistema.
 Etapa 2 -- Definición de los requisitos
 En esta etapa se desarrollan y especifican los requisitos reflejados durante la etapa de
viabilidad para el desarrollo del sistema.
 Funcionalidades del sistema (lo que debe hacer)
 Interacción del usuario con el sistema
 Condiciones de operación del sistema
 Información generada por el sistema y su tratamiento
Ciclo de vida del DWH
 Etapa 3 – Diseño
 Especificaciones de programación
 Especificaciones de base de datos
 Especificaciones de seguridad, etc...
 Etapa 4 – Desarrollo
 Parte del diseño para llevar a la practica los distintos procesos orgánicos descritos en
la fase de diseño
 En esta fase también se incluyen las pruebas del sistema antes de pasar a producción
 Etapa 5 – Implementación
 El sistema se lleva a producción después de la aceptación del usuario final
Ciclo de vida del DWH
Ciclo de vida del DWH

 Fases del proyecto data warehouse


Ciclo de vida del DWH
 Se definen 7 fases en la gestión de un proyecto de data warehouse
 Requisitos
 Diseño de la Arquitectura técnica
 Selección del producto e instalación
 Diseño del modelo dimensional
 Diseño físico
 Diseño y desarrollo del proceso de transformación y carga
 Especificaciones de las aplicaciones de análisis e informes
 Desarrollo de las aplicaciones de análisis e informes
 Desarrollo e implementación
 Mantenimiento
Ciclo de vida del DWH

 Requisitos
 En esta fase mediante entrevistas, recogida de información y documentos se
establecerán las funcionalidades del futuro data warehouse, siempre desde el
punto de vista del negocio.
 El objetivo de todas y cada una de las entrevistas es hacer hablar a los
usuarios acerca de lo que hacen y por que lo hacen, como miden su trabajo,
cuales son las medidas o cifras necesarias para su trabajo o que son
generadas en su área de negocio.
Ciclo de vida del DWH
 Preguntas típicas en un entrevista serían:
 ¿cómo se distinguen o agrupan los distintos productos? ... o los agentes, o los
proveedores, etc..
 Si el entrevistado realiza una análisis de los datos generados en su área,
preguntaremos entonces acerca de cómo lleva a cabo los análisis y cuales son los
datos requeridos para esta operación.
 El entrevistador en todo momento estará atento a las propuestas de mejora
de los sistemas actuales así como mejoras en los procesos de trabajo. Es
habitual que los usuarios entrevistados para un proyecto data warehouse,
completen sus peticiones con informes que usen actualmente, generados de
manera automática o manual y sobre los que presentarán las mejoras que
necesitan y por que las necesitan.
Ciclo de vida del DWH
 Si las entrevistas se llevan a cabo con ejecutivos de la empresa no es normal
llegar al detalle, en cambio si se preguntará acerca de cómo mejorar la gestión
de la información en la compañía.
 Nuestro principal objetivo es que el data warehouse debe de cumplir las
demandas y expectativas del negocio, por tanto debemos realizar cuantas
entrevistas sean necesarias para tener claros todos los aspectos del negocio y
su relación con la información generada en los sistemas operacionales.
 En la etapa de requerimientos también es necesario priorizar las distintas
funcionalidades, así como lograr un consenso acerca de las funcionalidades
del sistema, entre los futuros usuarios del mismo y los directivos de la
empresa.
Ciclo de vida del DWH

 Diseño de la arquitectura técnica


 En esta etapa diseñamos la integración entre las distintas tecnologías,
existentes con el nuevo proyecto, analizamos el impacto en los sistemas así
como las necesidades que surgirán para soportar el proyecto. También se
definirá la línea de tiempo para las distintas partes del proyecto.
 Como es evidente el diseño de la arquitectura técnica ha de venir marcado
por los requerimientos del negocio.
 En esta fase ha de ser tenidas en cuenta las políticas de tecnologías de la
información, las arquitecturas tecnológicas existentes, la evolución futura
tecnológica de la empresa, así como sinergias con otras empresas del grupo.
Ciclo de vida del DWH
 Todos las soluciones tecnológicas propuestas para dar respuesta a las
necesidades del negocio han de ser documentadas debidamente.
1. Establecer un equipo para el diseño de la arquitectura.
2. Recoger requerimientos readicionados con la arquitectura
3. Documentar los requerimientos de arquitectura
4. Desarrollar un modelo de arquitectura a alto nivel
5. Diseñar y especificar los subsistemas dentro de la arquitectura
6. Determinar las fases de implementación de la arquitectura
7. Documentar la arquitectura técnica
8. Revisión y finalización de la arquitectura técnica
Ciclo de vida del DWH
 Selección del producto e instalación
1. El primer paso antes de seleccionar nuevos productos, es comprender el proceso de
aprobación de compras interno de la compañía.
2. Desarrollar una matriz de evaluación de productos, que identifique los puntos clave de los
productos, así como que asigne pesos a cada una de las capacidades a comparar
dependiendo de nuestras necesidades.
3. Rastrear el mercado para localizar las posibles soluciones existentes y a los proveedores.
4. Ir estrechando la lista de productos candidatos y realizando evaluaciones más detalladas.
5. Realizar pruebas de test si tenemos acceso a productos de evaluación.
6. Seleccionar un producto, instalarlo en pruebas y negociar con el o los posibles
proveedores.
Ciclo de vida del DWH

 Diseño del modelo dimensional


 En esta fase a partir de los requerimientos se construye el modelo
dimensional que dará soporte a nuestro data warehouse.
 El modelo debe estar debidamente documentado.
Ciclo de vida del DWH

 Diseño físico
 El modelo dimensional diseñado en la fase anterior debe ser traducido al
diseño físico para el motor de base de datos especifico que hayamos
seleccionado.
 En esta etapa se establecen las estrategias de agregación, así como la creación
inicial de índices en el área de almacenamiento.
Ciclo de vida del DWH
 Los índices más recomendables son:
 Sobre tablas de dimensiones:
 Índice sobre la clave primara
 Índices en “B-tree” en columnas usadas como FK con alta cardinalidad.
 Índices en “Bitmap” en columnas con media y baja cardinalidad.
 Sobre tablas de hechos:
 Por lo general las tablas de hechos tienen índices compuestos por las distintas claves foráneas
(FK) que participen en la tabla de hechos, en estos casos realizar un índice simple compuesto
en las FK de las principales dimensiones. Como muchas de las consultas son conducidas a
través de la dimensión de tiempo, la clave foránea (FK) correspondiente a esta dimensión debe
de ser la primera en el índice compuesto.
Ciclo de vida del DWH
 El plan de almacenamiento del data warehouse por otra parte no difiere
demasiado de cualquier otro para una base de datos relacional donde se
busque un buen rendimiento en el control de entrada-salida, por lo que
deben de ser aplicados los mismos principios.
 Almacenamiento separado de indices-datos.
 Almacenamiento separado de particiones
 Etc..
Ciclo de vida del DWH

 Diseño y desarrollo de los procesos de transformación y carga


 En este estado se diseñan y desarrollan las áreas temporales de
almacenamiento previos a la transformación. En esta etapa se diseñan y
desarrollan también los procedimientos para combinar los datos, cualificarlos,
identificar cambios, gestionar las claves, crear valores de análisis y manejar
errores.
Ciclo de vida del DWH

 Especificaciones de las aplicaciones analíticas y de informes


 Siguiendo los requerimientos del negocio establecidos en la primera fase, en
esta fase se establece el diseño y funcionalidades de las distintas aplicaciones
que explotarán los datos del data warehouse.
Ciclo de vida del DWH
 Desarrollo de las aplicaciones analíticas y de informes
 Se realiza el desarrollo de las aplicaciones diseñadas en la fase anterior.
Ciclo de vida del DWH
 Desarrollo e implementación
 En esta fase convergen las fases en las que se crearon los procedimientos y
áreas de extracción y transformación de datos y las de desarrollo de las
aplicaciones de análisis e informes. En esta fase se ultima la integración entre
las distintas áreas y se implementa el sistema en producción, con las debidas
pruebas preliminares.
 En esta fase también será necesario formar a los usuarios en las herramientas
de explotación de los datos, así como la generación de manuales de uso.
Ciclo de vida del DWH
 Mantenimiento
 Finalmente en este estado se realizan las labores de:
 Soporte a los usuarios
 Formación continua
 Soporte técnico
 Monitorización
MUCHAS
GRACIAS