Fundamentos DW

Fundamentos de Data
Warehouse
HHeerrmmeess RRoommeerroo
DDAATTAABBAASSEE TTEEAAMM

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
 Un DWH puede ayudarnos a obtener respuestas para tomar
 Antes de construir un DWH debemos responder a las siguientes
preguntas
o ¿De donde vienen los datos del DWH?
o ¿cómo se cargarán los datos en el DWH?
o ¿cómo se mantendrán?
o ¿cómo se estructuran los datos en el DWH?
o ¿qué podemos encontrar en un momento del tiempo en el DWH?
© 2004 Database Team S.L
© Hermes Romero
productos.
decisiones de manera más acertada.
DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com

o 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.
o La definición aceptada de DWH se atribuye a Bill Inmon en 1992*:
• DWH es una base de datos que sigue cuatro características:
© Hermes Romero
Introducción
 Definición de DWH
o Subject oriented
o Nonvolatile
o Integrated
o Time variant

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.
© Hermes Romero

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.
© Hermes Romero

Introducción
 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:
o Los costes de almacenamiento se han vuelto insignificantes
en comparación con el valor de la información almacenada.
o Las empresas valoran la información (datos) como un activo
o Muchas de las empresas multinacionales comparten su
información a través de toda la organización a nivel
mundial.
© Hermes Romero
de negocio crítico.

• Diferentes estructuras de datos
• Diferentes motores de datos
• Diferentes almacenamientos físicos de información (ficheros)
• Diferentes plataformas
o 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...
© Hermes Romero
Introducción
o Existen diferentes aplicaciones en la organización
o Mainframes
o Sistemas medios multiprocesador
o Proveedores externos de servicios
o Estaciones de trabajo en red e independientes.
• Información distribuida
• Multiplicidad de tipos de datos

o 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.
o 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.
© Hermes Romero
Introducción

o Los procesos de acceso a datos heterogéneos, limpios, filtrados y
o El almacenamiento de datos en estructuras fáciles de acceder,
 Los datos en el DWH son usados para consultar, analizar y
 El tipo de acceso, uso, tecnología y rendimiento son
completamente diferentes de los sistemas transaccionales
operacionales OLPT.
© Hermes Romero
Introducción
 Los sistemas DWH implementan :
transformados
fáciles de usar y comprensibles.
realizar informes.

considerablemente altos, particularmente si existen análisis
basados en históricos.
o 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 lso posibles conflictos y degradación de
rendimiento en el sistema operacional.
© Hermes Romero
Introducción
 Los volúmenes de datos en el DWH pueden ser

Introducción
 Los sistemas DWH no son considerados ahora como meras
fotos-fijas (snapshots) de 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 DWHing. 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.
© Hermes Romero

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
© Hermes Romero
diferencian a la organización.

 PARA LOGAR ESTOS RESULTADOS NO BASTA CON LA
SIMPLE REINGENIERIA DE LOS MODELOS DE DATOS
OPERACIONALES.
© Hermes Romero
Introducción

 Consistencia de los datos (Data consistency architecture)
o 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.
o 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.
o Las decisiones acerca de esta arquitectura deben de conducir a todas
© Hermes Romero
Arquitectura del DWH
las otras decisiones.

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

 Arquitectura del modelado de datos (Data modeling
Architecture)
o Consiste en la elección acerca de si se usarán modelos de datos,
normalizados, denormalizados, orientados a objetos, propietarios,
multidimensionales, etc...
© Hermes Romero

 Arquitectura de herramientas (Tool architecture)
o La elección de herramientas que serán usadas para reporting.
 Arquitectura de procesado (Processing tiers architecture)
o Elección de las plataformas físicas para el procesamiento concurrente
o 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)
o 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.
© Hermes Romero
que tiene lugar en el data warehouse.

 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.
© Hermes Romero

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

 Dependiendo de las respuestas a las preguntas descritas
anteriormente se pueden establecer cuatro categorias:
o OLPT – sistema transaccional de operaciones
o ODS operational data store
o OLAP online analytical processing
o DM / DW Data mart / data warehouse
© Hermes Romero

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
© Hermes Romero

 Otra de las mejores formulas para distinguir un DWH de
uno que no lo es consiste en recabar la siguiente
información:
o Número de tablas
o El número de registros de la tabla mayor
o El tamaño en GB de la tabla mayor
o La media de registros de las mayores tablas
o El tamaño medio en GB de las mayores tablas
o La mayor transacción (rollback) en GB. (Oracle)
o El mayor segmento temporal necesitado en GB. (Oracle)
© Hermes Romero

 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.
© Hermes Romero

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
© Hermes Romero

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

 ¿cómo puede responder un sistema a la pregunta?
o ¿por qué no se han alcanzado los resultados de ventas
 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.
© Hermes Romero
previstos?

 Para que esta pregunta tenga respuesta a través del
sistema es necesario realizar diversas consultas
sistemáticas:
o 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
© Hermes Romero

o 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?
o 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...
© Hermes Romero

 Un director de ventas se preguntará probablemente:
o ¿qué productos son los que mas se venden y cuales los que
o ¿cuál es el periodo medio de compra de mis clientes?
© Hermes Romero
menos?
o ¿cuáles son los clientes mas importantes?
• Por cifra de negocio (facturación)
• Por rentabilidad

o ¿qué clientes han reducido su periodo medio de compra?
o ¿qué clientes han reducido su importe medio de compra?
© Hermes Romero
o ¿cómo clasificaría a mis clientes?
• A,B,C – Pareto
o Basado en cifra de negocio
o Basado en rentabilidad
o Basado en periodo medio de compra
• Otros...

o ¿qué clientes no han comprado nada en los últimos 3
o ¿por qué no se están cumpliendo los objetivos de ventas?
© Hermes Romero
meses?
• A nivel local
• A nivel provincial
• A nivel regional
• A nivel nacional
• ...
o ...

 Una de las mayores obligaciones de un sistema de
soporte a la toma de decisiones (DSS) es la disponibilidad
de la información.
o Tener acceso a los datos correctos en el momento correcto y
© Hermes Romero
con un tiempo de respuesta aceptable.

 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.
o 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.
o El data warehouse contiene datos corporativos estructurados de
© Hermes Romero
Estructura de un DWH
manera granular.

o Esta es la característica más importante
o Los datos llegan de diferentes orígenes y son cargados en el data
o 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...
© Hermes Romero
 Está integrado
warehouse.

 Como resultado de las transformaciones y
cargas los datos una vez que residen en el data
warehouse poseen una única imagen física.
© Hermes Romero

 Históricamente las distintas aplicaciones de una compañía
manejaban la información de diferente manera, con
diferentes tipos de datos.
o 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.
o 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)
© Hermes Romero

o Al contrario que en los sistemas transaccionales OLPT, los
datos en el data warehouse no son accedidos de manera
regular de registro en registro.
o Los data warehouse son cargados (generalmente en masa) y
accedidos sólo para su consulta no para su actualización.
o Cuando el data warehouse se carga genera una foto fija en
o 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.
© Hermes Romero
 No es volátil (nonvolatile)
el tiempo de los datos (snapshot).

o 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
• En cualquier caso un registro siempre está sometido a una
variable de tiempo.
© Hermes Romero
 Variable en el tiempo
se valido la transacción que lo contenía.

o El horizonte temporal de un sistema data warehouse es
o El data warehouse debe contener más datos históricos que
© Hermes Romero
mayor al de un sistema operacional.
• Operacional 60-90 días.
• DWH 5 a 10 años.
cualquier otro sistema.

 Pequeños data warehouses que pueden trabajar
 El data mart depende de la arquitectura seleccionada
© Hermes Romero
Data Marts
independientemente o interconectados.
para el data warehouse.

 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
© Hermes Romero
Data Marts
warehouses”)
o Proyectos mas arriesgados
o Altos costes
o Tiempos altos de desarrollo.

o Se pueden implementar de manera rápida y sencilla
o Son proyectos de bajo riesgo.
o presentan los datos desde la perspectiva de un proceso
 La cantidad de datos históricos contenidos en un data
mart deben ser dictados por los requerimientos del
negocio.
© Hermes Romero
Data Marts
 Los data marts
simple de negocio (subject).

• Albergan subconjuntos de datos del repositorio central.
o 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...
© Hermes Romero
Data Marts
 Arquitectura en Bus
o Los Data marts en bus
o seleccionados
o preparados
o Son usados por parte de un grupo de usuarios.

o 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.
o 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.
© Hermes Romero
Data Marts
 ...arquitectura en bus

o Un analista que quiera obtener datos accederá de esta
o Un repositorio de metadatos provee la información acerca de
los diferentes data marts (directorio de data mart)
© Hermes Romero
Data Marts
 ...arquitectura en bus
manera al data mart relevante.

Usuarios Finales
Usuarios Finales
Usuarios Finales
© Hermes Romero
Data Marts
BBDD
Sistema
Operacional
Datos
Historicos
Repositorio
Centralizado de
Datos
ODS
(Operational Data
Store)
Otros datos Metadatos
Data Marts
DataMart
DataMart
DataMart

 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.
© Hermes Romero
DWH y Business Intelligence

o Business Intelligence (BI) es la habilidad de tomar mejores
o Un entorno de BI enfocado al cliente provee de la
infraestructura necesaria para proveer la información
necesaria para maximizar la base de clientes.
o 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.
o 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.
© Hermes Romero
DWH y BI
decisiones de manera más rápida.

o Los canales de contacto incluyen los tradicionales así como
los basados en intercambio electrónico (email, web).
o Las técnicas analíticas incluyen análisis de perfiles, modelos
predictivos, análisis de series de tiempo, y otras técnicas.
© Hermes Romero
DWH y BI

o 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.
o 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.
o 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.
o Además de los datos suplidos de demografía y otros datos
externos, son necesarios numerosos datos internos de la
organización.
© Hermes Romero
DWH y BI

o 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”.
o 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 ....
© Hermes Romero
DWH y BI

© Hermes Romero
DWH y BI

o Ante todo conocer al cliente
o Cual es el valor del cliente para la compañía
o Cuales son los clientes más importantes para la compañía
o Cuales son los prospectos potenciales
o Cuales son los clientes / productos más rentables
© Hermes Romero
CRM
 Que persigue el CRM...

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

o El término CRM es confuso desde el punto de vista técnico
• Se produce un paralelismo entre CRM y herramientas CRM
o 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.
© Hermes Romero
CRM
 Ámbito tecnológico del CRM
o Hoy por Hoy todo es CRM...

BI
Análisis
Data mining
© Hermes Romero
CRM
BBDD
Transacciones
ERP Negocio
BBDD
Relaciones
Con clientes
Herramientas CRM
Contact-Center
ETL
Data
Warehouse
DATABASE TECHNOLOGIES & SERVICES Reporting
www.hermesromero.com

 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
 A mayor detalle mayor nivel de granularidad.
 A menor detalle menor nivel de granularidad.
© Hermes Romero
Granularidad
de los datos contenidos en el DWH.

 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.
© Hermes Romero
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.
© Hermes Romero
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.).
© Hermes Romero
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.
© Hermes Romero
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.
© Hermes Romero

Ventas por mes
Ventas por semana
Ventas por área geografica
(52)
Ventas por vendedor
(52)
Ventas por producto
(20)
Ventas por nivel de
rentabilidad
(5)
1081600 registros al mes
21632000 bytes/mes
© Hermes Romero
Ventas por mes
Marketing
Ventas
Ventas por mes
(52)
Operaciones
Financiero
Ventas por mes
Ventas por semana
(52)
Ventas por vendedor
(52)
Ventas por mes
Ventas por semana
(52)
Ventas por vendedor
(52)
Ventas por producto
(20)
216320 bytes/mes
Mayor Granularidad
1 registro al mes
20 bytes/mes
52 registros al mes
1040 bytes/mes
4326400 bytes/mes

 Otro de los beneficios de la granularidad es la flexibilidad.
o 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.
© Hermes Romero
Beneficios de la granularidad

o 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.?
o En el nivel 1 de granularidad nuestra pregunta no tendría
o En el nivel 2 de granularidad tampoco
o Ni en el nivel 3.
o En el nivel 4 de granularidad nuestra respuesta si podría ser
o En el nivel 5 de granularidad también podría ser contestada.
© Hermes Romero
respuesta.
contestada.

o 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).
© Hermes Romero

 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.
© Hermes Romero
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.
© Hermes Romero

 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.
© Hermes Romero

 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.
© Hermes Romero

 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.
© Hermes Romero
Estimación de la Granularidad

o El primer paso para calcular el espacio que ocupará el DWH
es la identificación de las tablas que serán construidas.
o 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.
© Hermes Romero
Estimación de la granularidad

o 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 economica, la cuota de mercado
y el crecimiento en cuota de mercado, las previsiones de la
comptencia, etc...
o 4ª una vez que se han hecho las previsiones es necesario
repetir el proceso pero esta vez con un horizonte de 5 años.
© Hermes Romero

o 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).
• (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
© Hermes Romero
o 6º Realizar la operación

o Repetir esta operación por cada una de las tablas del DWH
o 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.
© Hermes Romero

 Una vez obtenidos los resultados de las predicciones es
necesario aplicar la siguiente tabla para revisar si el nivel
de granularidad es correcto:
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 DNiWveHl de granularidad Aceptable
100.000 1.000.000 Nivel de granularidad Adecuado
© Hermes Romero
número de registros a 1 año vista Número de resgristros a 5 años vista

 Un importante componente de los sistemas DWH es el
concepto de “Overflow storage” almacenamiento
desbordado
o El almacenamiento desbordado se produce cuando son
almacenados datos que no son usados de manera frecuente.
o Relación directa con la granularidad del diseño.
• A mayor nivel de granularidad mayor es la probabilidad de que
se produzca el desbordamiento.
© Hermes Romero

 Con el transcurso del tiempo mayor desbordamiento.
o Almacenar los datos poco consultados en dispositivos
o 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.
© Hermes Romero
externos CD-ROM - DVD

o 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.
© Hermes Romero

 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.
© Hermes Romero

 El nivel de granularidad debe tener en cuenta las
necesidades futuras y la evolución del propio negocio.
o Un nivel mayor de granularidad significará estar mas
© Hermes Romero
preparado para el futuro.

Caminos para establecer la granularidad
 Realizando consultas sobre los orígenes de datos con los
 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.
© Hermes Romero
distintos niveles de granularidad posible.

Caminos para establecer la granularidad
 Identificando los mayores y menores valores en el
 Identificando tan sólo los datos que son estrictamente
 Realizando pruebas de muestreo de datos utilizando
conjuntos representativos de datos mediante
condicionantes.
© Hermes Romero
destino.
necesarios en el destino.

 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
 En el particionamiento de datos lógico el criterio común
mas usado es el áreas temáticas (subject areas).
o Podemos definir un área temática como una porción del
DWH que es clasificada desde una perspectiva consistente.
© Hermes Romero
Particionamiento
implementación física del diseño.

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

 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:
o Reestructuración de datos
o Indexación
o Escaneado Secuencial (Full Scans)
o Reorganización
o Recuperaciones
o Monitoreado
o Auditoría
© Hermes Romero
Particionamiento

 Los criterios de particionamiento de los datos son
variados pero quizás los mas representativos sean:
o Periodo de tiempo (Fecha, mes , trimestre, semestre, año)
o Por áreas geográficas
o Por producto o línea de negocio
o Por unidad organizativa
o ...
o Por combinaciones de lo anterior
© Hermes Romero
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.
© Hermes Romero
Particionamiento

 Se puede realizar un particionamiento controlado por la
propia aplicación.
o Añadirá la posibilidad de portar los datos entre distintos
© Hermes Romero
Particionamiento
DWH.
 El particionamiento depende de:
o El modelo de datos multidimensional
o La granularidad de los datos
o Las capacidades del motor de base de datos

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

 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:
o ¿Se puede pagar la factura del cliente XXXX?
 Mientras que en el DWH las preguntas son más del tipo:
o ¿qué productos se estan vendiendo mejor?
o ¿cuáles son las oficinas que venden menos?
o ¿cuáles son los vendedores menos rentables?...
© Hermes Romero
Áreas temáticas

 Las áreas temáticas son la forma más común de
 Para extraer una lista de los candidatos a áreas
© Hermes Romero
Áreas temáticas
particionamiento lógico en el DWH.
temáticas, debemos hacernos la pregunta:
o ¿cuáles son los intereses del negocio?

 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.
o Si se hace la pregunta en quien está interesado el negocio
(who) podrá aparecer:
• Clientes, empleados, gerentes, proveedores, competidores, etc...
• Este año, trimestralmente, mensualmente, anualmente,
semanalmente, etc...
© Hermes Romero
Áreas temáticas
o Sobre la pregunta cuando (when)
o Donde (where)
• Provincias, ciudades, países, etc...

 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.
© Hermes Romero
Áreas temáticas

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.
o para obtener mayor información
o para obtener una mejor comprensión del negocio
o para encontrar nuevos caminos e ideas para ganar potencial
© Hermes Romero
en otros mercados.
o Para controlar gastos y costes

 Es una practica extendida en nuestros días la integración
de los sistemas de data mining en las aplicaciones
transaccionales de negocio.
o 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.
o Sistemas que generan listados de receptores de publicidad
directa con ofertas adecuadas a su perfil de cliente.
o Sistemas que alertan sobre el riesgo de perdida de un
cliente o, de la modificación de sus hábitos de compra.
© Hermes Romero
Exploración y Data mining
o Etc...

 Esta integración en los sistemas operacionales de la
compañía requiere:
o Integración de los sistemas de Data mining con las bases de
o Integración de los sistemas de Data Mining con los sistemas
© Hermes Romero
datos de producción
DWH.

 El principal caldo de cultivo de los sistemas de data
mining son los sistemas DWH, ya que:
o Permiten el análisis de los datos sobre granularidades
o No influyen en el rendimiento del sistema operacional.
o 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.
© Hermes Romero
Exploración y data mining
significativas para el sistema

© Hermes Romero
Exploración y Data Mining
Definición
DATA WAREHOUSE
Preparación de los datos
Minería de datos
Interpretación de resultados
Implementación de
resultados
DATA MINING
FUNCIONES
DE SCORING
DE
RESULTADOS

• 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:
o Procesado de valores numéricos...totales de ventas, cantidades
o Cálculo o investigación de medidas de calidad como satisfacción de
o Predicciones de análisis de transacciones de negocio, análisis de
© Hermes Romero
 Consultas e Informes
vendidas.
clientes, retrasos en procesos de negocio, etc..
tendencias, etc...

Preparación del informe
Entrega del informe
© Hermes Romero
Definición de la consulta
Acceso y obtención del dato
Manipulación del dato
y cálculo

• 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:
o ¿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.
© Hermes Romero
o Análisis multidimensional
Enero Vendedor provincia

• 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.
o los datos no son recalculados sino que simplemente son accedidos y
• 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.
© Hermes Romero
mostrados.

Totales de Ventas en Enero Totales de Ventas en Febrero Totales de Ventas en Marzo
Vendedor 1 Vendedor 2 Vendedor 1 Vendedor 2 Vendedor 1 Vendedor 2
Mad Sev Mad Sev Mad Sev Mad Sev Mad Sev Mad Sev
© Hermes Romero
Totales de Ventas en el primer trimestre
Drill Down
Roll Up

o 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.
o 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.
© Hermes Romero
 Data Mining

o Los descubrimientos pueden tomar la forma de encontrar
significado a determinadas relaciones o patrones de datos.
o Después de realizar un descubrimiento, este puede
convertirse en una regla que sea utilizada para hacer
predicciones basadas en esa regla.
© Hermes Romero

o 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:
• “knowledge discovery” extrae información no conocida de
manera implícita de los datos.
© Hermes Romero
o análisis linear y no lineal
o análisis de regresión
o Análisis multivarianza
o Y análisis de series en tiempo.

o 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.
o La minería de datos ofrece nuevos revelaciones acerca del
negocio dando respuesta a preguntas que nunca se nos
hubiese ocurrido preguntar.
© Hermes Romero

Gestionado por
los datos
Multidimensional Data Mining
© Hermes Romero
Gestionado por
el
Analista
Asistido por el
Analista
Consultas
e
informes
Análisis

o OLAP data mart (OnLine Analitical Processing)  análisis
multidimensional
• Están diseñados para soportar análisis multidimensional usando
• 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.
© Hermes Romero
herramientas de software OLAP.

o 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.
o Almacenes estadísticos (Data mining or statistical
warehouses)
• Es un data mart especializado diseñado para dar soporte a los
o Aplicaciones analíticas customizables (Customizable
analytical applications)
• Permite la customización efectiva de aplicaciones genéricas.
© Hermes Romero
analistas e investigadores.

 Asumamos las siguientes aserciones como ciertas antes
• En el DWH podremos encontrar datos de todas las unidades de
negocio y departamentos de la compañía.
o 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
© Hermes Romero
Diseño del DWH
de continuar:
o El DWH debe tener un enfoque corporativo
reglas de negocio de la compañía.

o El DWH debe ser cargado con datos lo más rápida y
o El DWH debe configurarse y diseñarse para soportar
múltiples tecnologías de BI, tanto presentes como futuras.
o El DWH debe acomodarse fácilmente a cambios tanto en las
estructuras de datos como en los datos propiamente dichos.
© Hermes Romero
Diseño del DWH
eficientemente posible.

 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.
© Hermes Romero
Diseño del DWH

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

 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.
© Hermes Romero
Diseño del DWH

 Las características ideales que debe seguir el modelo de
• 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.
© Hermes Romero
Diseño del DWH
datos en el sistema DWH son:
o No redundante.

• 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.
© Hermes Romero
Diseño del DWH
o Estable

• 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.
© Hermes Romero
Diseño del DWH
o Consistente

 El modelo de datos resultante para el DWH, se
trasladará a un diseño de base de datos que sea:
o Fiable
• No contendrá contradicciones en la forma de nombrar entidades
o atributos, en referencias de unos a tros, así como en la
documentación
• 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.
© Hermes Romero
Diseño del DWH
o Compartido

• 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.
• El modelo de datos proveerá una representación de cómo y que
clase de información es usada en la compañía-
© Hermes Romero
Diseño del DWH
o Flexible y adaptable al cambio
o Correcto

 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.
© Hermes Romero
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.
© Hermes Romero
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.
© Hermes Romero
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.
© Hermes Romero
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.
© Hermes Romero
Diseño del DWH

© Hermes Romero
Diseño del DWH
latencia
Repetitivas Customizables Algoritmicas
volatilidad
Esquema en estrella
De-normalizadas
Normalizadas
Planas

Diseño del DWH – Estructura de los datos
 Para DWH podemos distinguir tres tipos básicos de datos:
 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.
© Hermes Romero
o Datos en tiempo real (real-time data)
o Datos derivados (Derived data)
o Datos reconciliados (Reconciled Data)

 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.
© Hermes Romero

o Los datos en tiempo real representan el estado actual del
negocio. Por supuesto, estos son los datos que utilizan los
sistemas operacionales.
o Los datos en tiempo real muestran la realidad cambiante del
o Los datos en tiempo real muestran por otra parte el mayor
nivel de detalle lo que se representa como el mayor nivel de
granularidad.
o Habitualmente estos son accedidos en modo lectura-escritura
por las transacciones operacionales.
© Hermes Romero
 Datos en tiempo real (Real-Time data)
negocio transacción a transacción.

o 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.
o 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.
o 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.
© Hermes Romero

o 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.
© Hermes Romero

o 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.
o Los datos derivados pueden ser detallados o resumidos
dependiendo de las especificaciones de requerimientos del
DWH.
o Pueden representar una vista del negocio en un momento
determinado del tiempo o pueden ser datos históricos
referidos a un periodo de tiempo.
© Hermes Romero
 Datos Derivados (Derived Data)

o Los datos derivados son tradicionalmente usados para la
o 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.
o 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.
© Hermes Romero
toma de decisiones y el análisis del negocio.

o 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.
o La consistencia es uno de los requerimiento de calidad inexcusables.
o 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.
o En algunas ocasiones los datos reconciliados son almacenados en
estructuras físicas temporales requeridas para transformar de
manera consistente los datos operacionales.
© Hermes Romero
 Datos Reconciliados (Reconciled Data)

 El concepto de EDM – Enterprise Data Model
o 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.
o El EDM incluye a su vez vínculos a los diseños de datos de
o A través del EDM se puede intuir una visión y comprensión
© Hermes Romero
cada una de las aplicaciones operacionales.
de los requerimientos del negocio.

 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
© Hermes Romero
Modelado de datos para el DWH
datos :
o Modelado entidad-relación ER
o Modelado dimensional

 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.
© Hermes Romero

 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.
© Hermes Romero

 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
 El objetivo de los modelos de datos es conseguir la
independencia lógico / física
o Como se muestran los datos es completamente
independiente de cómo se almacenarán a nivel físico
© Hermes Romero
del contenido del DWH sería muy difícil.

 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
© Hermes Romero

o 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.
o 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.
© Hermes Romero
 Modelos entidad-relación

o El modelado ER se representa mediante un diagrama que
usa tres tipos de graficos para conceptualizar los datos:
Entidad, relación y Atributo.
• Entidad
o Una entidad se define como una persona, lugar cosa o evento de
o Una entidad representa una clase de objeto, que puede ser observado
y clasificado por sus propiedades y caracteristicas.
© Hermes Romero
interes para el negocio o la organización.

o 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)
o Los atributos describen las caracteristicas o propiedades de las
entidades. Un nombre de atributo debe se único en una entidad.
© Hermes Romero
• Relación
• Atributos

Modelado de datos para el DWH – Modelado
dimensional
 El modelado de datos dimensional usa tres conceptos
 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.
© Hermes Romero
básicos:
o Medidas (measures)
o Hechos (facts)
o Dimensiones (dimensions)

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.
© Hermes Romero

dimensional
o Es una colección de items de datos relacionados.
o 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.
o En un Data warehouse los hechos (facts) se almacenan
donde los datos numéricos son almacenados.
© Hermes Romero
 Hechos (facts)

dimensional
o Es una colección de miembros o unidades del mismo tipo.
o Las dimensiones determinan el contexto de fondo para los
o Las dimensiones son los parámetros sobre los que queremos
realizar el análisis OLAP (online analitical processing).
© Hermes Romero
 Dimensiones (dimensions)
hechos.

dimensional
o Si consideramos una base de datos de análisis de ventas,
encontraremos entre otras las siguientes dimensiones.
• Tiempo
• Localización / Provincia
• Clientes
• Vendedor
o 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.
© Hermes Romero

dimensional
o 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.
© Hermes Romero

dimensional
Semana
día ...
© Hermes Romero
 Jerarquias de la dimensión
Jerarquía 1 año
Jerarquía 2
semestre semestre
trimestre trimestre
mes
día
...
...
...

dimensional
o Una medida se determina por la combinación de miembros
de las dimensiones y está situada en los hechos (facts)
© Hermes Romero
 Medidas (measures)
o Es un atributo numérico de un hecho.
o 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
• ...

dimensional
o 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.
o 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.
o Los hechos mas habituales son los numéricos y aditivos,
© Hermes Romero
 Tablas de hechos (facts)
como euros o total de ventas.

dimensional
o 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...
o 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%
© Hermes Romero

dimensional
o 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).
o 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)
© Hermes Romero

dimensional
o Las tablas de hechos de tipo transaccional son las más
o Las tablas de hechos poseen dos o mas “foreign keys” (FK)
que conectan las tablas de hechos con las tablas de
dimensiones.
o 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.
© Hermes Romero
 ...Tablas de hechos (facts)
habituales con diferencia.

dimensional
o 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.
o 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.
© Hermes Romero

dimensional
o 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.
© Hermes Romero

dimensional
o Mucho del éxito de nuestro DWH dependerá de cómo se
© Hermes Romero
implementen las tablas de hechos.
ventas diarias
clave de fecha FK
clave de tienda FK
clave de producto FK
cantidad
valor

dimensional
o Hemos de tener en cuenta que las tablas de hechos pueden
o No es posible el mantenimiento de índices en un corto espacio de
o Las tablas de hechos también pueden estar implementadas
© Hermes Romero
encontrarse en tres estados:
• Están siendo Consultadas
• Están siendo cargadas
• Están siendo gestionadas
tiempo
de diferentes maneras:
• Sin particionamiento – Sin índices
• Particionadas – Sin índices
• Sin particionamiento – Con índices

dimensional
o Las tablas de dimensiones contienen los descriptores
o 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.
o 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.
© Hermes Romero
 Tablas de dimensiones (dimensions)
textuales del negocio.

dimensional
o 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.
o 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.
o Cada uno de los atributos de las tablas de dimensiones
serán utilizados para realizar las consultas como
condicionantes, agrupaciones, etc...
© Hermes Romero

dimensional
o 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.
o 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.
© Hermes Romero

dimensional
o 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.
o Cuanto mas tiempo pasemos definiendo atributos con
sentido para el negocio mejor será nuestro DWH.
o Cuanto mas tiempo pasemos poblando nuestras tablas de
dimensiones con valores para los distintos atributos mejor
será nuestro DWH.
© Hermes Romero

dimensional
• 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.
© Hermes Romero
o Atributos en las dimensiones

dimensional
• 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.
© Hermes Romero
 ...tablas de dimensiones (dimensions)
o Jerarquia de las dimensiones

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.
© Hermes Romero

dimensional
© Hermes Romero
tabla de marcas
clave de marca
nombre de la marca
tabla de familias
clave de familia
nombre de la familia
Tabla de productos
clave de producto
descripcion del producto
clave de marca (FK)
modelo
clave de familia (FK)
tipo de empaquetado
tamaño empaquetado
peso
precio del producto

dimensional
o 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.
© Hermes Romero
 ...tablas de dimensiones

dimensional
dimensión
tabla de tiendas
clave de tienda
provincia
© Hermes Romero
 Diseño en estrella (star join schema)
dimensión
tabla de fechas
clave de fecha
fecha
mes
dia
año
dimensión
tabla de hechos
ventas diarias
clave de fecha (FK)
clave de tienda (FK)
clave de producto (FK)
cantidad
valor
Tabla de productos
clave de producto
descripcion del producto
modelo
marca
familia
tipo de empaquetado
tamaño empaquetado
peso
precio del producto

dimensional
o 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.
o 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.
© Hermes Romero
 Diseño en estrella (star join schema)

Fundamentos DW

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Fundamentos DW

Similaire à Fundamentos DW (20)

Plus de Hermes Romero

Plus de Hermes Romero (16)

Fundamentos DW