Fundamentos Datawarehouse

Fundamentos de Data
Warehouse
Contenidos
Introduccin
Arquitectura del data warehouse
Estructura de un Data warehouse
Data marts
Granularidad
Exploracin y minera de datos
Diseo del data warehouse
Visualizacin del modelo dimensional Aplicaciones OLAP (bases de datos
dimensionales)
Carga de datos en el data warehouse
Ciclo de vida del data warehouse
Introduccin
Data Warehouse es una solucin no un producto o grupo de
productos.
Un DWH puede ayudarnos a obtener respuestas para tomar
decisiones de manera ms acertada.
Antes de construir un DWH debemos responder a las siguientes
preguntas
o
o
o
o
o
De donde vienen los datos del DWH?

cmo se cargarn los datos en el DWH?
cmo se mantendrn?
cmo se estructuran los datos en el DWH?
qu podemos encontrar en un momento del tiempo en el DWH?
Introduccin
Definicin de DWH
Data Warehousing : diseo e implementacin de procesos, y
herramientas para gestionar y proveer informacin completa, en
tiempo, fiel y comprensible para la toma de decisiones. Incluye
todas las actividades que hacen posible a una organizacin la
creacin, gestin y mantenimiento del DWH o del datamart.
o La definicin aceptada de DWH se atribuye a Bill Inmon en 1992*:
o
DWH es una base de datos que sigue cuatro caractersticas:

o Subject oriented
o Nonvolatile
o Integrated
o Time variant
Introduccin
La necesidad del DWH surge a partir de la necesidad de
obtener acceso fcil 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 informacin es un potente
activo del que se pueden obtener importantes beneficios y
ventajas competitivas para cualquier organizacin.
Introduccin
En las dcadas de los 80 y 90 las compaas se han
preocupado principalmente por la adecuacin de los sistemas
operacionales, es decir por la obtencin de los datos, la
disponibilidad de las aplicaciones, el almacenamiento de los
datos, etc... En nuestros das ha legado el momento de sacar
partido de esa informacin, el problema es que los sistemas
operacionales no permiten en la mayora de los casos la
obtencin de informacin de manera rpida y precisa para la
toma de decisiones, por diversas causas.
Introduccin
Debido principalmente a tres fenmenos que han ocurrido
durante la pasada dcada los tamaos de las bases de
datos se han visto incrementados significativamente:
Los costes de almacenamiento se han vuelto insignificantes
en comparacin con el valor de la informacin almacenada.
o Las empresas valoran la informacin (datos) como un activo
de negocio crtico.
o Muchas de las empresas multinacionales comparten su
informacin a travs de toda la organizacin a nivel
mundial.
o
Introduccin
o
Existen diferentes aplicaciones en la organizacin
Diferentes
Diferentes
Diferentes
Diferentes
estructuras de datos
motores de datos
almacenamientos fsicos de informacin (ficheros)
plataformas
o Mainframes
o Sistemas medios multiprocesador
o Proveedores externos de servicios
o Estaciones de trabajo en red e independientes.
Informacin distribuida
Multiplicidad de tipos de datos
o Por ejemplo un sistema calcula la edad a travs de la fecha de nacimiento,
otro lo escribe en un campo, uno llama edad al atributo, otro le llama AGE...
Introduccin
Este tipo de organizaciones tendrn que desarrollar y mantener
diferentes aplicaciones para extraer, preparar y consolidar la
informacin en informes y analticas.
o Es normal tambin que los responsables de la toma de decisin, a
la hora de efectuar un hallazgo quieran profundizar ms en los
datos que han llevado a ese hallazgo.
o
Introduccin
Los sistemas DWH implementan :
Los procesos de acceso a datos heterogneos, limpios, filtrados y
transformados
o El almacenamiento de datos en estructuras fciles de acceder,
fciles de usar y comprensibles.
o
Los datos en el DWH son usados para consultar, analizar y

realizar informes.
El tipo de acceso, uso, tecnologa y rendimiento son
completamente diferentes de los sistemas transaccionales
operacionales OLPT.
Introduccin
Los volmenes de datos en el DWH pueden ser
considerablemente altos, particularmente si existen anlisis
basados en histricos.
o
Debido a este tipo de volumen de datos y el anlisis 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 anlisis. Existe
por tanto un requerimiento de separacin de los dos entornos
DWH-OLPT para minimizar lso posibles conflictos y degradacin de
rendimiento en el sistema operacional.
Introduccin
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
informacin concebidas para el uso de toda la organizacin. La
simple reingeniera de los modelos operacionales no satisfacen
los requerimientos para el DWHing. El desarrollo de DWH
requiere mucho ms anlisis aplicado a las tcnicas de
modelado y una relacin mucho mas cercana con el propio
negocio de la organizacin.
Introduccin
La acumulacin de informacin histrica en el DWH, junto
a su anlisis 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) tambin puede
aportar informacin.
El DWH tambin ayuda al descubrimiento de cosas que
diferencian a la organizacin.
Introduccin
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)

o
La consistencia de los datos se basa en la eleccin de los distintos

orgenes de datos, dimensiones, Reglas de negocio, mtrica y
semntica, que una organizacin selecciona para un uso comn.
Este es de lejos el aspecto ms difcil de implementar en la
arquitectura del data warehouse debido a que incluye y est
condicionada por las polticas y la organizacin de la compaa.
Las decisiones acerca de esta arquitectura deben de conducir a todas
las otras decisiones.
Arquitectura del almacn 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:
o Realizacin de informes que hacen uso de ellos (Reported against)
o Limpieza y organizacin de los datos (Cleaned up)
o Transporte a otro almacn de datos donde pueden ser utilizados para
realizacin de informes o para su limpieza y organizacin.
o
Arquitectura del
Architecture)
o
modelado
de
datos
(Data
modeling
Consiste en la eleccin acerca de si se usarn modelos de datos,

normalizados, denormalizados, orientados a objetos, propietarios,
multidimensionales, etc...
Arquitectura de herramientas (Tool architecture)

o
La eleccin de herramientas que sern usadas para reporting.
Arquitectura de procesado (Processing tiers architecture)

Eleccin de las plataformas fsicas para el procesamiento concurrente
que tiene lugar en el data warehouse.
o Puede ir desde una simple arquitectura como la basada en un nico
servidor de informes hasta uno cientos de servidores distribuidos.
o
Arquitectura de Seguridad (Security Architecture)

o
Aunque la seguridad no presenta ninguna dificultad tcnica a la hora

de ser aplicada si presenta complejas dificultades desde el punto de
vista poltico.
Un sistema DWH debe resolver necesidades propias de

negocio y es por ello que ser sponsorizado por las
personas del negocio que harn uso de el.
Un DWH tambin sigue determinadas especificaciones de
diseo, un DWH no es un DWH simplemente por que
alguien dice que lo es.
Como detectar un DWH

o
o
o
o
o
o
o
o
Funcionalidad (Para que sirve?)

Nmero de Consultas ad-hoc (personalizadas) de los
usuarios
Nmero de consultas personalizadas por da y por usuarioda
Nmero de usuarios de informes standard
Numero de usuarios, usuarios-da de informes standard
Nmero de informes standard
Volumen del historico a almacenar en meses, trimestres o
aos.
Volumen de datos tpico para almacenar (diario,semanal o
mensual)
Dependiendo de las respuestas a las preguntas descritas

anteriormente se pueden establecer cuatro categorias:
OLPT sistema transaccional de operaciones
o ODS operational data store
o OLAP online analytical processing
o DM / DW Data mart / data warehouse
o
Funcionalidad
Herramientas de usuario final
tecnologia BBDD
N de transacciones
Tamao de la transaccin
tiempo de tranasccin
Tamao BBDD en GB
Modelado de datos
Normalizacin
OLPT
ODS
OLAP
DM/DW
Operacional
Cliente Servidor/WEB
Relacional
Alto
Bajo
Corto
1
Entidad Relacin
3-5 NF
Operacional/Decisional
C/S-WEB
Relacional
Medio
Medio
Medio
OLPT * 2 - OLPT *10
Entidad Relacin
3 NF
Decisional
C/S
Cubica
Bajo
Medio
Medio
OLPT * 2 - OLPT *10
N/A
N/A
Decisional/Estrategica
C/S-WEB
Relacional
Bajo
Alto
Alto
OLPT*2-OLPT*100
Dimensional
0 NF
Otra de las mejores formulas para distinguir un DWH de

uno que no lo es consiste en recabar la siguiente
informacin:
o
o
o
o
o
o
o
Nmero de tablas
El nmero de registros de la tabla mayor
El tamao en GB de la tabla mayor
La media de registros de las mayores tablas
El tamao medio en GB de las mayores tablas
La mayor transaccin (rollback) en GB. (Oracle)
El mayor segmento temporal necesitado en GB. (Oracle)
Los sistemas DWH por lo general tienen menos tablas y

mas grandes, mientras que los operacionales tienen mas
tablas y mas pequeas.
En el caso de Oracle y otras BBDD que utilicen
mecanismos de recuperacin de transacciones (rollback),
as como segmentos o reas temporales de ordenacin de
resultados, los sistemas DWH necesitarn que estas
reas sean al menos tan grandes como el objeto mas
grande de la base de datos, mientras que los sistemas
operacionales tan slo necesitan que el espacio sea
suficiente para dar cabida a la transaccin mas
voluminosa del sistema.
N de tablas
Media de Registros por tabla
Media de tamao por tabla (GB)
N de registros de la tabla mas grande
Tamao de la Tabla mas grande (GB)
Tamao de los segmentos de Rollback
Tamao de los segmentos temporales
OLPT
ODS
OLAP
DM/DW
1-miles
miles -millones
1 a 99
miles - millones
1 a 99
1 a 100 Mb
1 a 100 Mb
1-miles
miles - millones
1 a 99
miles - millones
1 a 99
1 a 100 Mb
1 a 100 Mb
OLPT/10
millones
1 a 99
miles - millones
1 a 99
N/A
N/A
OLPT/10
millones
1 a 999
miles - cientos de millones
1 a 999
1 a 999 Gb
1 a 999 Gb
El sistema DWH debe:

o
o
o
o
o
o
Debe hacer la informacin de la compaa accesible de

manera sencilla a usuarios ofimticos no avanzados
Debe presentar la informacin de la compaa 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 compaa ... La informacin.
Debe servir a la funcionalidad ultima de mejora de la toma
de decisin.
Los usuarios deben de aceptar el sistema si se pretende que
su implementacin y uso se haga con xito.
cmo puede responder un sistema a la pregunta?

o
por qu no se han alcanzado los resultados de ventas

previstos?
Hasta el momento no existe ningn sistema informtico

que pueda dar respuesta a una pregunta de este tipo,
imaginemos una sentencia SQL que pudiese dar
respuesta a esta pregunta.
Para que esta pregunta tenga respuesta a travs del

sistema es necesario realizar diversas consultas
sistemticas:
o
As la primera pregunta sera:
Para cada producto, cuales son las ventas acumuladas del ao?
El sistema nos devolvera una lista de los productos con sus
cifras de venta correspondientes
Si quisiera que me mostrase tan slo aquellos productos que

su cifra de ventas es menor que la cifra de ventas objetivo
cules son las ventas acumuladas para cada uno de los

productos en las que las ventas actuales son menores que los
objetivos?
Despus de descubrir cuales son los productos que no

alcanzan la cifra objetivo, analizar cada caso para ver cual
es la posicin del producto con respecto al mercado, etc...
El mismo anlisis podra hacerse para localizar reas de

venta donde no se estn alcanzando los objetivos,
vendedores que no estn alcanzando la cifra, etc...
Un director de ventas se preguntar probablemente:

o
o
qu productos son los que mas se venden y cuales los que

menos?
cules son los clientes mas importantes?
Por cifra de negocio (facturacin)

Por rentabilidad
cul es el periodo medio de compra de mis clientes?
cmo clasificara 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...
qu clientes han reducido su periodo medio de compra?

o qu clientes han reducido su importe medio de compra?
o
qu clientes no han comprado nada en los ltimos 3

meses?
o por qu no se estn cumpliendo los objetivos de ventas?
o
...
A nivel
A nivel
A nivel
A nivel
...
local
provincial
regional
nacional
Una de las mayores obligaciones de un sistema de

soporte a la toma de decisiones (DSS) es la disponibilidad
de la informacin.
o
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
tambin un sistema integrado, no voltil 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 distribucin
probablemente posea una serie de reas comunes de anlisis con el
resto de empresas que se dediquen tambin a la distribucin.
El data warehouse contiene datos corporativos estructurados de
manera granular.
Est integrado
o
o
o
Esta es la caracterstica ms importante

Los datos llegan de diferentes orgenes y son cargados en el data
warehouse.
Los datos en su camino hacia el data warehouse pueden sufrir
transformaciones fruto de clculos realizados sobre los mismos.
Conversin de datos
Reformateado (Reformatted)
Cambio de secuencia (Resequenced)
Sumarizados (Summarized)
Etc...
Como resultado de las transformaciones y

cargas los datos una vez que residen en el data
warehouse poseen una nica imagen fsica.
Histricamente las distintas aplicaciones de una compaa

manejaban la informacin de diferente manera, con
diferentes tipos de datos.
No exista por tanto un consistencia
a la hora de la
codificacin, nombres de entidades y atributos, tipo de
datos, etc.., ...lo que haca ms difcil su integracin en un
nico sistema de explotacin de la informacin generada.
o Es por tanto tarea del sistema data warehouse especificar
un
nico
repositorio
que
integre
las
diferentes
peculiaridades de los distintos orgenes de datos. (Una nica
estructura de datos para distintos orgenes de datos con
estructuras diferentes)
o
No es voltil (nonvolatile)
o
o
o
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.
Los data warehouse son cargados (generalmente en masa)
y accedidos slo para su consulta no para su actualizacin.
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 pasarn a formar parte del histrico del data
warehouse.
Variable en el tiempo
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
se valido la transaccin que lo contena.
En cualquier caso un registro siempre est sometido a una
variable de tiempo.
El horizonte temporal de un sistema data warehouse es

mayor al de un sistema operacional.
Operacional 60-90 das.

DWH 5 a 10 aos.
El data warehouse debe contener ms datos histricos que

cualquier otro sistema.
Data Marts
Pequeos 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 discusin acerca de si la

arquitectura del DWH deba estar basada en Data Marts,
o bien completamente centralizado.
Los data warehouses centrales (enterprise wide data
warehouses)
Proyectos mas arriesgados
o Altos costes
o Tiempos altos de desarrollo.
o
Data Marts
Los data marts

o
o
o
Se pueden implementar de manera rpida y sencilla

Son proyectos de bajo riesgo.
presentan los datos desde la perspectiva de un proceso
simple de negocio (subject).
La cantidad de datos histricos contenidos en un data

mart deben ser dictados por los requerimientos del
negocio.
Data Marts
Arquitectura en Bus
o
Los Data marts en bus
Albergan subconjuntos de datos del repositorio central.

o seleccionados
o preparados
o Son usados por parte de un grupo de usuarios.
Los data marts tambin 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.
facturacin, llamadas del call center, movimientos de almacn,
procurement, etc...
Data Marts
...arquitectura en bus
o
Algunas veces los diseos de arquitecturas data warehouse

basados en data marts caen en el error de disear
estructuras de tela de araa donde mltiples extracciones
de un mismo origen de datos se cargan en diferentes data
marts. Con esto diseos 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 araa
no tienen en cuenta que el diseo de los distintos data
marts debe estar basado en el proceso de negocio y no en la
organizacin departamental de la compaa. En los sistemas
centrados en el proceso (process-centric) los dato son
extrados una sola vez y almacenados en un nico lugar.
Data Marts
...arquitectura en bus
o
o
Un analista que quiera obtener datos acceder de esta

manera al data mart relevante.
Un repositorio de metadatos provee la informacin acerca
de los diferentes data marts (directorio de data mart)
Data Marts
DWH y Business Intelligence
El experto en sistemas de Business Intelligence Drury

Jenkins define la relacin de soporte directo entre los
sistemas business intelligence y los data warehouse
haciendo un especial nfasis en el modelado de los datos
y el anlisis de los mismos.
DWH y BI
Business Intelligence (BI) es la habilidad de tomar mejores

decisiones de manera ms rpida.
o Un entorno de BI enfocado al cliente provee de la
infraestructura necesaria para proveer la informacin
necesaria para maximizar la base de clientes.
o Esta infraestructura combina datos, canales y tcnicas
analticas para mejorar las satisfaccin del cliente y el
beneficio a travs 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.
o
DWH y BI
Los canales de contacto incluyen los tradicionales as como

los basados en intercambio electrnico (email, web).
o Las tcnicas analticas incluyen anlisis de perfiles, modelos
predictivos, anlisis de series de tiempo, y otras tcnicas.
o
DWH y BI
El aspecto clave de proveer de la informacin necesaria es la

creacin de una vista global para cada cliente individual y
sus necesidades.
o La integracin de los datos de los clientes debe proveer de
una vista nica y uniforme de los clientes a lo largo de la
organizacin.
o El objetivo ltimo es alcanzar una foto completa de la
interaccin de un cliente con la organizacin entera, slo se
puede lograr mediante la obtencin y almacenamiento de
los datos apropiados.
o Adems de los datos suplidos de demografa y otros datos
externos, son necesarios numerosos datos internos de la
organizacin.
o
DWH y BI
Demasiado habitualmente, los datos obtenibles estn

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 dispersin de los datos, ha sido debido en gran manera
por el crecimiento de los sistemas de aplicaciones
cliente/servidor en la pasada dcada ....
o
DWH y BI
CRM
Que persigue el CRM...

o
o
o
o
o
Ante todo conocer al cliente

Cual es el valor del cliente para la compaa
Cuales son los clientes ms importantes para la compaa
Cuales son los prospectos potenciales
Cuales son los clientes / productos ms rentables
CRM
...Que persigue el CRM...

o
Cual es el resultado de mis campaas publicitarias
o
o
o
o
N de impactos
N de clientes nuevos
Incremento de ventas
CrossSelling
Optimizar la interaccin con el cliente

Trato personalizado
Ofertas personalizadas
Etc...
CRM
mbito tecnolgico del CRM

o
El trmino CRM es confuso desde el punto de vista tcnico
Se produce un paralelismo entre CRM y herramientas CRM
El CRM es una filosofa/estrategia de compaa que se lleva

a cabo por medio de herramientas especializadas en los
distintos mbitos del tratamiento de la informacin referida
al cliente.
o Hoy por Hoy todo es CRM...
o
CRM
BI
ERP
Anlisis
BBDD
Transacciones
Negocio
Data mining
ETL
Data Warehouse
Herramientas CRM
BBDD
Relaciones
Con clientes
Contact-Center
Reporting
Granularidad
La granularidad es el concepto mas importante en el

diseo 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 correspondera con el mayor nivel de granularidad,
mientras que una consulta acerca del total de ventas del
mes se correspondera con un nivel de granularidad
menor.
Evidentemente a mayor nivel de granularidad mayor ser
el volumen de informacin , 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 extraccin de los datos de los
sistemas operacionales hasta el DWH cuando se produce
la transformacin de los mismos para adecuar su
granularidad a la definida en el diseo del DWH de
destino.
A travs del nivel de granularidad se puede predecir el
crecimiento en nmero de registros del DWH, as como
los requerimientos de espacio para el mismo.
Granularidad
La granularidad tambin 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 compaa.
Por ejemplo los datos de facturacin de una compaa 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 geogrficas por meses,
para el departamento de ventas ser necesario ver los datos
desde la perspectiva de las ventas por vendedor o delegacin
comercial semanalmente. Para el departamento de operaciones
ser conveniente ver los datos desde la perspectiva de ventas
por lnea de producto con carcter 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 lnea de producto.
Financiero
Operaciones
Ventas
Marketing
Ventas por mes
Ventas por mes
Ventas por semana
Ventas por mes
Ventas por semana

Ventas por rea geografica
(52)
Ventas por semana

(52)
Ventas por mes

(52)
(52)
Ventas por vendedor
(52)
1 registro al mes
20 bytes/mes
52 registros al mes
1040 bytes/mes
Ventas por mes
10816 registros al mes

216320 bytes/mes
Mayor Granularidad
Ventas por vendedor

(52)
Ventas por vendedor

(52)
Ventas por producto

(20)
Ventas por producto

(20)
Ventas por nivel de

rentabilidad
(5)

4326400 bytes/mes

21632000 bytes/mes
Beneficios de la granularidad
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 obtencin de
datos podrn ser acomodados con el diseo 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 histrico de actividades y
eventos de la compaa.
A travs del ejemplo anterior veamos el siguiente supuesto:
o
o
o
o
Cuantas unidades ha vendido Paco del producto limpia-hogar

Malvarossa la semana del 3 al 10 de Diciembre del ao pasado.?
En el nivel 1 de granularidad
respuesta.
Ni en el nivel 3.
contestada.
nuestra pregunta no tendra
tampoco
nuestra respuesta si podra ser
tambin podra ser contestada.
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 mltiple
Es posible en determinados sistemas DWH definir dos o

ms niveles diferentes de granularidad para dar solucin
de manera ms eficiente a diferentes peticiones de datos.
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, disearemos 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.
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 tambin el nmero de peticiones sobre
cada uno de los repositorios bajar.
Evidentemente la puesta en marcha de diferentes grados
de granularidad afecta al espacio de almacenamiento.
Gracias a su bajo coste (bsicamente almacenamiento),

eficiencia, facilidad de acceso y habilidad para responder
cualquier consulta, la granularidad mltiple generalmente
a dos niveles, es la mejor eleccin posible en
arquitecturas donde el nivel de detalle del DWH es muy
alto y el volumen de datos es tambin muy alto.
Un nico nivel de granularidad muy detallada est solo
indicada en casos en los que el volumen de datos es
relativamente pequeo.
Estimacin de la Granularidad
El principal condicionante en la eleccin del nivel de

granularidad de nuestro sistema DWH se centra en el
nmero de registros o volumen de datos que contendr la
base de datos, evidentemente este volumen tan slo
podr ser predictivo por estimacin. Es importante
tambin efectuar en esta fase un ejercicio para estimar el
crecimiento del propio DWH.
Estimacin de la granularidad
El primer paso para calcular el espacio que ocupar el DWH

es la identificacin de las tablas que sern construidas.
o 2 estimar el tamao de un registro en cada una de las
tablas. Evidentemente el tamao exacto nunca se conocer
ya que una filas consumirn mas espacio y otras menos, por
lo que nosotros tomaremos como cifra una estimacin
basada en la cantidad mnima de espacio y por otro lado la
cantidad mxima de espacio necesario para una fila.
o
3 estimar en el horizonte de un ao el mximo y mnimo

numero de registros que contendr cada una de las tablas.
Si la informacin 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 situacin 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 aos.
o
5 Establecer el nmero y tamao de los ndices necesarios

para las distintas tablas del DWH, es conveniente crear
ndices en cada una de las variables condicionantes que
formarn parte de las consultas (campos que estarn en las
clusulas WHERE de las sentencias SQL).
o 6 Realizar la operacin
o
(Mximo nmero de filas posible en un ao X tamao mximo

pro registro) + espacio de ndices
(Mnimo nmero de filas posible en un ao X tamao mnimo
por registro) + espacio de ndices
Repetir esta operacin por cada una de las tablas del DWH
o Por lo general las estimaciones siempre se quedan pequeas
debido al crecimiento del DWH, por lo que es aconsejable
sumar un espacio extra de al menos un 30% sobre la
estimacin.
o
Una vez obtenidos los resultados de las predicciones es

necesario aplicar la siguiente tabla para revisar si el nivel
de granularidad es correcto:
nmero de registros a 1 ao vista Nmero de resgristros a 5 aos 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 diseo del
DWHde granularidad Aceptable
1.000.000
10.000.000
Nivel
100.000
1.000.000
Nivel de granularidad Adecuado
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.
o Relacin directa con la granularidad del diseo.
o
A mayor nivel de granularidad mayor es la probabilidad de que

se produzca el desbordamiento.
Con el transcurso del tiempo mayor desbordamiento.

o
o
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.
Por ello a la hora de disear 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 permitira aplicar el mayor nivel de
granularidad deseado.
La granularidad viene determinada a travs 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.
El nivel de granularidad debe tener en cuenta las

necesidades futuras y la evolucin del propio negocio.
o
Un nivel mayor de granularidad significar estar mas

preparado para el futuro.
Caminos para establecer la granularidad
Realizando consultas sobre los orgenes de datos con los

distintos niveles de granularidad posible.
Realizando las operaciones de agregacin, que sern
realizadas desde el origen de los datos en su camino
hacia el data warehouse.
Realizando las operaciones estadsticas como medias,
etc.. que sern 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 slo 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

lgico y a nivel fsico, para una mejor compresin,
mantenimiento y navegacin a travs del DWH
El particionamiento fsico se define a travs de la propia
implementacin fsica del diseo.
En el particionamiento de datos lgico el criterio comn
mas usado es el reas temticas (subject areas).
o
Podemos definir un rea temtica como una porcin del

DWH que es clasificada desde una perspectiva consistente.
Particionamiento
Para el DWH el particionamiento aporta:

o
o
o
o
Acceso ms flexible a los datos

Una gestin 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

volmenes de datos dividindolos en piezas mas
pequeas. Al hacer esto determinadas operaciones con
los datos sern ms fciles de realizar:
o
o
o
o
o
o
Reestructuracin de datos
Indexacin
Escaneado Secuencial (Full Scans)
Reorganizacin
Recuperaciones
Monitoreado
Auditora
Particionamiento
Los criterios de particionamiento de los datos son

variados pero quizs los mas representativos sean:
o
o
o
o
o
o
Periodo de tiempo (Fecha, mes , trimestre, semestre, ao)

Por reas geogrficas
Por producto o lnea de negocio
Por unidad organizativa
...
Por combinaciones de lo anterior
Particionamiento
La eleccin de un criterio de particionamiento est

basado e los requerimientos del propio negocio y las
caractersticas fsicas de la propia base de datos.
Cada herramienta de gestin de bases de datos (DBMS)
tiene su propia manera de implementar el
particionamiento a nivel fsico, y pueden ser bastante
diferentes entre ellas.
Particionamiento
Se puede realizar un particionamiento controlado por la

propia aplicacin.
o
Aadir la posibilidad de portar los datos entre distintos

DWH.
El particionamiento depende de:

El modelo de datos multidimensional
o La granularidad de los datos
o Las capacidades del motor de base de datos
o
reas temticas (subject areas)
Un DWH est siempre orientado a reas temticas

(subject areas).
rea temtica = rea de inters para el negocio
El DWH est siempre orientado a reas especificas de la
organizacin como pueden ser:
o
o
o
o
o
Clientes
Productos
Beneficios
Ventas
...
reas temticas
Esta orientacin 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 ms del tipo:

qu productos se estan vendiendo mejor?
o cules son las oficinas que venden menos?
o cules son los vendedores menos rentables?...
o
reas temticas
Las reas temticas son la forma ms comn de

particionamiento lgico en el DWH.
Para extraer una lista de los candidatos a reas
temticas, debemos hacernos la pregunta:
o
cules son los intereses del negocio?
reas temticas
Para la localizacin de las reas temticas se utiliza el

mtodo 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:
Sobre la pregunta cuando (when)
Clientes, empleados, gerentes, proveedores, competidores,

etc...
Este ao, trimestralmente, mensualmente, anualmente,
semanalmente, etc...
Donde (where)
Provincias, ciudades, pases, etc...
reas temticas
Una vez extrada la lista de candidatos a reas temticas,

habr que seleccionarlas, descomponerlas y redefinirlas
mas claramente.
Como resultado podremos finalmente obtener una lista
de reas temticas que representen claramente a nuestra
organizacin.
El rol principal del rea temtica es la determinacin de la
unidad para un anlisis efectivo, modelado e
implementacin del DWH, lo cual pude servir tambin
como medida para discernir las reas de inters de
nuestro DWH.
Exploracin y data mining (minera de datos)
Los sistemas de Data mining o minera de datos se han

hecho populares durante la pasada dcada.
para obtener mayor informacin
o para obtener una mejor comprensin del negocio
o para encontrar nuevos caminos e ideas para ganar potencial
en otros mercados.
o Para controlar gastos y costes
o
Exploracin y Data mining
Es una practica extendida en nuestros das la integracin

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.
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 modificacin de sus hbitos de compra.
o Etc...
o
Esta integracin en los sistemas operacionales de la

compaa requiere:
Integracin de los sistemas de Data mining con las bases de
datos de produccin
o Integracin de los sistemas de Data Mining con los sistemas
DWH.
o
Exploracin y data mining
El principal caldo de cultivo de los sistemas de data

mining son los sistemas DWH, ya que:
Permiten el anlisis de los datos sobre granularidades
significativas para el sistema
o No influyen en el rendimiento del sistema operacional.
o Buscan patrones de comportamiento a lo largo de todos los
sistemas de la compaa y para ello es fundamental la
integracin y estandarizacin del DWH.
o
Exploracin y Data Mining
Definicin
DATA WAREHOUSE
Preparacin de los datos
Minera de datos
DATA MINING
Interpretacin de resultados
FUNCIONES
DE SCORING
DE
RESULTADOS
Implementacin de
resultados
Consultas e Informes
Permite responder a determinadas preguntas , obteniendo la

informacin relevante desde el DWH, transformndola para el
contexto apropiado y mostrndola de manera legible. En esta
tcnica las consultas realizadas estn basadas en dos
dimensiones.
Los usuarios finales estn especialmente interesados en:
o Procesado de valores numricos...totales de ventas, cantidades
vendidas.
o Clculo o investigacin de medidas de calidad como satisfaccin de
clientes, retrasos en procesos de negocio, etc..
o Predicciones de anlisis de transacciones de negocio, anlisis de
tendencias, etc...
Definicin de la consulta
Acceso y obtencin del dato
Manipulacin del dato

y clculo
Preparacin del informe
Entrega del informe
Anlisis multidimensional
El anlisis multidimensional es una manera de extender las

capacidades de las consultas e informes que como vimos se
basan en dos nicas dimensiones..
Bsicamente sustituye a la necesidad de realizar mltiples
consultas, para ello los datos son estructurados de manera que
se habilita un acceso rpido y fcil a las respuestas de las
preguntas que tpicamente 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

dimensin.
Enero
Vendedor
provincia
Mediante el mecanismo de preclculo 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
mostrados.
El anlisis multidimensional permite a los usuarios tener a su

alcance un gran nmero de factores interdependientes asociados
a un escenario del negocio.
Los usuarios pueden acceder a la informacin explorando los
datos en diferentes niveles de detalle.
Totales de Ventas en Enero
Totales de Ventas en Febrero
Totales de Ventas en Marzo
Roll Up
Drill Down
Totales de Ventas en el primer trimestre
Vendedor 1
Vendedor 2
Vendedor 1
Vendedor 2
Vendedor 1
Vendedor 2
Mad
Mad
Mad
Mad
Mad
Mad
Sev
Sev
Sev
Sev
Sev
Sev
Data Mining
o
Es una tcnica relativamente nueva es muy diferente de las

tcnicas de consultas e informes y del anlisis
multidimensional, su principal diferencia se basa en lo que
se llama tcnica de descubrimiento.
La tcnica de descubrimiento (discovery technique) no
consiste en realizar una consulta especifica a los datos, en
cambio esta tcnica utiliza algoritmos que analizan los datos
y devuelven los resultados descubiertos. A diferencia de las
dos tcnicas anteriores el data mining busca respuesta a
consultas que no han sido previamente realizadas.
Los descubrimientos pueden tomar la forma de encontrar

significado a determinadas relaciones o patrones de datos.
o Despus de realizar un descubrimiento, este puede
convertirse en una regla que sea utilizada para hacer
predicciones basadas en esa regla.
o
Las tcnicas de data mining se utilizan habitualmente para

anlisis estadstico de los datos y para descubrir el
conocimiento (knowledge discovery)
El anlisis estadstico descubre patrones no habituales en los

datos aplicando tcnicas matemticas y estadsticas para la
explicacin de los patrones.
Una vez descubierto el patrn este se utilizar entonces para
hacer previsiones y presupuestos.
Algunas de las tcnicas estadsticas incluyen:
o anlisis linear y no lineal
o anlisis de regresin
o Anlisis multivarianza
o Y anlisis de series en tiempo.
knowledge discovery extrae informacin no conocida de

manera implcita de los datos.
El soporte de las tcnicas de anlisis 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 difcil de descubrir sin el uso
de tcnicas de data mining.
o La minera de datos ofrece nuevos revelaciones acerca del
negocio dando respuesta a preguntas que nunca se nos
hubiese ocurrido preguntar.
o
Gestionado por
el
Analista
Asistido por el
Analista
Gestionado por
los datos
Consultas
e
informes
Anlisis
Multidimensional
Data Mining
OLAP data mart (OnLine Analitical Processing) anlisis

multidimensional
Estn diseados para soportar anlisis multidimensional usando

herramientas de software OLAP.
El data mart en este caso se disea utilizando las tcnicas de
esquema en estrella o tecnologas propietarias de cada
herramienta basadas en el concepto de hipercubo
(Hypercube).
El esquema en estrella o sistema de gestin 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 fcilmente predecibles con
tiempos de respuesta razonables e informes mas o menos
recurrentes.
Almacenes de exploracin (Exploration warehouse)
Almacenes estadsticos (Data mining or statistical

warehouses)
Los almacenes de exploracin estn diseados para dar soporte

real a la exploracin o navegacin puramente customizable por
el usuario ad-hoc.
Despus de un descubrimiento a travs de la exploracin, este
puede dar lugar a la creacin de un nuevo data mart , para que
otros usuario se beneficien del hallazgo a partir de es momento.
Es un data mart especializado diseado para dar soporte a los

analistas e investigadores.
Aplicaciones analticas customizables (Customizable

analytical applications)
Permite la customizacin efectiva de aplicaciones genricas.
Diseo del DWH
Asumamos las siguientes aserciones como ciertas antes

de continuar:
o
El DWH debe tener un enfoque corporativo
En el DWH podremos encontrar datos de todas las unidades de

negocio y departamentos de la compaa.
Se asume tambin que los datos contenidos en el DWH no

violan ninguna de las reglas de negocio establecidas para la
compaa.
El DWH en todo momento debe mostrar su adherencia a las

reglas de negocio de la compaa.
Diseo del DWH
El DWH debe ser cargado con datos lo ms rpida y

eficientemente posible.
o El DWH debe configurarse y disearse para soportar
mltiples tecnologas de BI, tanto presentes como futuras.
o El DWH debe acomodarse fcilmente a cambios tanto en las
estructuras de datos como en los datos propiamente dichos.
o
Diseo del DWH
El tipo de anlisis que ser realizado con el DWH o Data

mart puede determinar el tipo de modelado de datos y
los contenidos del mismo.
Como los anlisis basados en consultas e informes y los
anlisis multidimensionales requieren metadatos
explcitos y sumarizaciones especificas, es importante
que el modelo de datos que de soporte al anlisis
contenga estos elementos.
Diseo del DWH
Debemos tener en cuenta tambin que:

o
o
El anlisis multidimensional tambin permite las operaciones

drill down y roll up.
La minera de datos habitualmente trabaja mejor con el
mayor nivel de detalle disponible (granularidad alta).
Diseo del DWH
Desde principios de los aos 90 uno de los gurus del

DWH , Ralph Kimball, propuso nuevas tcnicas de diseo
basadas en las tradicionales bases de datos relacionales
para lograr que los DWH fueran comprensibles y rpidos.
Estas tcnicas de diseo que actualmente se conoce
como modelado de datos dimensional (dimensional
modeling) hacen que los sistemas DWH sean ms rpidos
a travs de la limitacin del nmero de enlaces (joins)
entre las distintas tablas que forman parte del sistema.
Diseo del DWH
Las caractersticas ideales que debe seguir el modelo de

datos en el sistema DWH son:
o
No redundante.
Debemos por todos los medios a nuestro alcance evitar la

redundancia de los datos en nuestro DWH. La redundancia de
datos aade trabajo extra a las operaciones de extraccin
transformacin y carga (ETL), as como a los diseadores que
tendrn 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.
Diseo 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 tecnologa que por otra parte son los
cambios que ocurren mas frecuentemente en una organizacin.
Por otra parte nuestro DWH debe estar preparado para aadir
nuevas entidades o atributos cuando se aaden nuevas
capacidades de anlisis BI o se incorporan nuevos data marts.
Es importante por tanto que el diseador de nuestro DWH use
tcnicas de modelado que permitan la incorporacin de cambios
en el modelo sin que sea necesario la redefinicin de las
entidades y atributos ya implementados.
Diseo del DWH
Consistente
La consistencia de los datos contenidos en el DWH es sin duda la

caracterstica esencial. Los modelos de datos creados para el
DWH deben reconciliar las discrepancias de concepto y fsicas
entre los distintos orgenes 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.
Diseo del DWH
El modelo de datos resultante para el DWH, se

trasladar a un diseo 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
documentacin
Compartido
El DWH resultante de la implementacin de este modelo de

datos podr ser accedido por mltiples procesos y usuarios
desde cualquier parte de la compaa.
Diseo del DWH
Flexible y adaptable al cambio
La base de datos resultante no condicionar en una direccin u

otra el entorno BI creado. Todas las oportunidades tecnolgicas
que se presenten permanecern disponibles para la compaa.
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 representacin de cmo y que

clase de informacin es usada en la compaa-
Diseo 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 lgico adems de
aconsejable no comenzar realizando un diseo de los
modelos de datos que soportarn nuestro DWH antes de
haber recabado todos los requerimientos por parte de los
usuarios y de la direccin de la compaa.
Diseo del DWH
En la mayora de proyectos de DWH se abre un debate

entre los integrantes tecnologicos del equipo acerca de si
los modelos deben estar basados en diseos en estrella,
normalizados o de-normalizados o simplemente planos.
Por razones varias muchos de los analistas prefieren
aplicar a todos los diseos su particular tcnica de
diseo (quizs por que se sienten comodos con una
tecnica en particular, o sencillamente por que desconocen
el resto) y por esta rzn forzan a los ditintos data marts
a tener un solo tipo de diseo.
Diseo del DWH
Lo mas recomendable en el diseo de data marts es que

los esquemas de base de datos que los soportan deben
estar diseados de acuerdo al uso que se va ha hacer de
ellos y del tipo de informacin que se solicitar al data
mart.
Diseo del DWH
Probablemente basndome en mi experiencia el mejor

diseo 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 diseo es que este soporte todas y cada una de
las posibilidades de anlisis de datos.
Diseo del DWH
Para determinar cual es el mejor diseo 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 diseo
seleccionado as como con respecto a la frecuencia o tipo
de consulta a realizar sobre el data mart.
Diseo del DWH
latencia
Planas
Normalizadas
De-normalizadas
Esquema en estrella
volatilidad
Repetitivas
Customizables
Algoritmicas
Diseo del DWH Estructura de los datos
Para DWH podemos distinguir tres tipos bsicos de datos:

o
o
o
Datos en tiempo real (real-time data)

Datos derivados (Derived data)
Datos reconciliados (Reconciled Data)
Se puede configurar el DWH basndose en estos tres

tipos, con la consideracin adecuada a las caractersticas
particulares de cada implementacin.
Dependiendo de la naturaleza de los sistemas

operacionales, el tipo de negocio, y el nmero 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.
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.
o Los datos en tiempo real muestran la realidad cambiante del
negocio transaccin a transaccin.
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 lecturaescritura por las transacciones operacionales.
o
Estos datos no tienen por que ser patrimonio exclusivo de

los sistemas operaciones ya que es practica habitual la
realizacin 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 tambin en Almacenes de datos operacionales
(ODS Operational Data Stores) para su posterior anlisis 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 ms fcilmente
comprensible y manipulable por los analistas de negocio.
o
Evidentemente, tambin en el caso de que los datos en

tiempo real provengan de distintos orgenes y sistemas,
debern ser reconciliados antes de ser cargados en el DWH.
Datos Derivados (Derived Data)

o
Los datos derivados son datos que han sido creados

probablemente a raz de operaciones como sumas, medias,
o agregaciones de operaciones en tiempo real a travs de
un proceso intermedio de transformacin 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 histricos
referidos a un periodo de tiempo.
Los datos derivados son tradicionalmente usados para la

toma de decisiones y el anlisis del negocio.
o La sumarizacin de los datos en nuevos registros derivados
requiere grandes volmenes de datos a analizar y por
consecuencia necesitar de grandes recursos para su
procesamiento.
o La eficiencia de los procesos de creacin de datos derivados
en tiempo y manera es vital y una de las tareas mas
importantes que los analistas han de resolver.
o
Datos Reconciliados (Reconciled Data)

Los datos reconciliados son datos en tiempo real que han sido
tratados para ajustarse a los niveles de integracin y calidad que se
requieren para ser usados en anlisis de datos.
o La consistencia es uno de los requerimiento de calidad inexcusables.
o Durante el proceso de reconciliacin de datos es posible crear y
mantener datos histricos , por lo que los datos reconciliados
podran ser un tipo especial de datos derivados.
o En algunas ocasiones los datos reconciliados son almacenados en
estructuras fsicas temporales requeridas para transformar de
manera consistente los datos operacionales.
o
El concepto de EDM Enterprise Data Model

Un EDM es una definicin 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 vnculos a los diseos de datos de
cada una de las aplicaciones operacionales.
o A travs del EDM se puede intuir una visin y comprensin
de los requerimientos del negocio.
o
Modelado de datos para el DWH
El modelador de datos debe responder a la premisa de

disear las bases de datos del DWH para soportar de la
mejor manera las necesidades de los usuarios del DWH.
En el DWH existen dos tcnicas bsicas de modelado de
datos :
Modelado entidad-relacin ER
o Modelado dimensional
o
En la mayora de los modelos de datos de los sistemas

operacionales actuales los modelos de datos se soportan
sobre estructuras de modelado ER.
Con la llegada del DWH la necesidad de tcnicas de

modelado orientadas hacia el anlisis se han visto
incrementadas y con ello ha crecido el inters por estas
tcnicas. 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
fcilmente explorar y explotar los datos de manera
comprensible.
El modelo de datos es una abstraccin organizada de los

datos que representan las actividades, recursos y
resultados de la organizacin.
Sin un modelo de datos la organizacin de la estructura y
del contenido del DWH sera muy difcil.
El objetivo de los modelos de datos es conseguir la
independencia lgico / fsica
o
Como se muestran los datos es completamente

independiente de cmo se almacenarn a nivel fsico
Por lo que a nivel lgico se refiere, se referir a los

aspectos de identificacin de la entidad o entidades, su
descripcin y su organizacin.
En el nivel fsico se tratarn aspectos como la
organizacin, acceso y almacenamiento de los datos a
nivel fsico
Modelos entidad-relacin
Los modelos ER producen un modelo de datos de una
especifica rea de interes usando para ello dos conceptos
bsicos: Entidades y las relaciones entre esas entidades. Los
modelos ER contienen tambin Atributos, que son las
propiedades inherentes a las entidades y/o relaciones.
o El modelo ER es una percepcin del mundo compuesta por
objetos llamados entidades y las relaciones entre ellos. Las
entidades se diferencian unas de otras a travs de sus
atributos.
o
El modelado ER se representa mediante un diagrama que

usa tres tipos de graficos para conceptualizar los datos:
Entidad, relacin y Atributo.
Entidad
o Una entidad se define como una persona, lugar cosa o evento de
interes para el negocio o la organizacin.

o Una entidad representa una clase de objeto, que puede ser observado
y clasificado por sus propiedades y caracteristicas.
Relacin
o Una relacin se representa mediante lineas que unen a dos entidades.
Una relacin se designa de manera gramatical por medio de un verbo,

como pertenece a, tiene. Tla relacin entre dos entidades puede ser
definida mediante su cardinalidad. La cardinalidad es el mximo
nmero 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 vlidas en un modelo normalizado)
Atributos
o 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

bsicos:
Medidas (measures)
o Hechos (facts)
o Dimensiones (dimensions)
o
En algunos casos el modelado dimensional es ms

sencillo, ms expresivo y fcil de comprender que el
modelado relacional.
Es relativamente nuevo por lo que no est firmemente
definido, especialmente comparado con las tcnicas de
modelado relacional.

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 anlisis de los datos.
El modelado dimensional se centra en los datos
numricos, como valores, cuentas (count), pesos,
balances y ocurrencias.

dimensional
Hechos (facts)
o
o
Es una coleccin de items de datos relacionados.

Cada hecho generalmente representa un item del negocio,
una transaccin 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 numricos son almacenados.

dimensional
Dimensiones (dimensions)
o
o
o
Es una coleccin de miembros o unidades del mismo tipo.

Las dimensiones determinan el contexto de fondo para los
hechos.
Las dimensiones son los parmetros sobre los que queremos
realizar el anlisis OLAP (online analitical processing).

dimensional
Si consideramos una base de datos de anlisis de ventas,

encontraremos entre otras las siguientes dimensiones.
Tiempo
Localizacin / Provincia
Clientes
Vendedor
Miembros de la dimensin (dimension members)
Una dimensin puede a su vez contener n miembros.

Por ejemplo, los meses : enero, febrero, marzo,...,trimestres,
cuatrimestres son miembros de la dimensin tiempo.

dimensional
Jerarquas de la dimensin (dimension hierarchies)
Las dimensiones pueden a su vez ser divididas en diferentes

jerarquas, cada jerarqua puede tener a su vez distintos niveles
jerrquicos.

dimensional
Jerarquias de la dimensin
Jerarqua 1
Jerarqua 2
ao
Semana
semestre
semestre
...
trimestre
trimestre
...
mes
...
da
da
...

dimensional
Jerarquias de la dimensin
o
Drill down

dimensional
Medidas (measures)
o
o
Es un atributo numrico de un hecho.

Por ejemplo las medidas de ventas seran
El importe de las ventas

El volumen de ventas
Las unidades vendidas
El importe de la materia prima
...
Una medida se determina por la combinacin de miembros

de las dimensiones y est situada en los hechos (facts)

dimensional
dimesion1

dimensional
Tablas de hechos (facts)

o
Es la tabla central en el modelo de datos dimensional, en

esta table es donde se almacenan los valores numricos 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 numricos y aditivos,
como euros o total de ventas.

dimensional
La capacidad de adicin 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 nmero de filas,
medias, etc...
o Es importante tener en cuenta que no es aconsejable la
introduccin de filas en las tablas de hechos que no
representen nada como por ejemplo (12/12/2003 , 0) en
representacin de que el da 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%
o

dimensional
Las tablas de hechos representan el 90% o ms del espacio

ocupado en un DWH, generalmente las tablas de hechos
tienen la tendencia de ser voluminosas en cuanto a nmero
de registros pero tambin a tener pocas columnas
(atributos).
o Las tablas de hechos se pueden adems clasificar en tres
grupos atendiendo a su nivel de granularidad.
o
Transacciones
Fotos-fijas peridicas (periodic snapshots)
Fotos-fijas acumulativas (accumulating snapshots)

dimensional
...Tablas de hechos (facts)

Las tablas de hechos de tipo transaccional son las ms
habituales con diferencia.
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 tambin
podemos afirmar que cada tabla en un modelo dimensional
que posee una clave compuesta es una tabla de hechos.
o

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 sern
tablas de hechos mientras que el resto sern tablas de
dimensiones.
o La composicin de la clave primaria en la tabla de hechos no
tiene por que relaizarse con todas las claves externas ya
que probablemente la agrupacin de unas pocas de ellas
garantice la unicidad del registro.
o

dimensional
En la mayora de los casos no tiene ninguna utilidad la

introduccin de una clave primaria no compuesta para
identificar unvocamente a cada registro de la tabla de
hechos. Al contrario de nuevo podemos ocupar un espacio
extra para aadir esto cuando realmente no es necesario,
con las consecuencias implcitas de almacenamiento y
rendimiento. Aunque si la naturaleza del negocio requiere la
inclusin de varias filas con los mismos valores entonces si
debemos plantearnos la creacin de una clave primaria,
siempre que sea necesario hacer una distincin clara entre
las filas con el mismo contenido.

dimensional

o
Mucho del xito de nuestro DWH depender de cmo se

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

encontrarse en tres estados:
Estn siendo Consultadas

Estn siendo cargadas
Estn siendo gestionadas
o No es posible el mantenimiento de ndices en un corto espacio de
tiempo
Las tablas de hechos tambin pueden estar implementadas

de diferentes maneras:
Sin particionamiento Sin ndices

Particionadas Sin ndices
Sin particionamiento Con ndices

dimensional
Tablas de dimensiones (dimensions)

Las tablas de dimensiones contienen los descriptores
textuales del negocio.
o En un modelo bien diseado las tablas de dimensiones
tienen por lo general muchos atributos que describen la fila
en la tabla de dimensin.
o Las tablas de dimensiones deben contener tantos atributos
como sean necesarios para hacer su contenido lo ms
comprensible posible. No es extrao encontrar tablas de
dimensiones que contengan entre 50 y 100 atributos.
o

dimensional
Por otra parte las tablas de dimensiones por lo general son

tablas que presentan pocos registros en comparacin con las
tablas de hechos, por lo general no mas de 1 milln de
registros.
o Cada dimensin se define a travs 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
sern utilizados para realizar las consultas como
condicionantes, agrupaciones, etc...
o

dimensional
En una consulta los atributos de una dimensin 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.
o

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.
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.
o

dimensional
...tablas de dimensiones (dimensions)

dimensional
Atributos en las dimensiones
Los atributos deben ser palabras reales en lugar de

abreviaciones. Esto nos ayudar en la implementacin 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 tpicos para una dimensin de producto por ejemplo
incluiran una descripcin corta de 10 a 15 caracteres, una
descripcin larga de 30 a 50 caracteres, nombre de la marca,
categora o familia de producto, tipo de empaquetado, tamao ,
peso y otras caractersticas. Aunque se definan atributos
numricos dentro de las dimensiones, conservarn su carcter
de dimensin siempre que se tomen como descripciones
textuales, por ejemplo, el atributo cdigo postal est
representado por un nmero aunque su uso es textual no vamos
a realizar operaciones con este valor, mas que para definir un
rea geogrfica concreta.

dimensional
...tablas de dimensiones (dimensions)

o
Jerarquia de las dimensiones
Las tablas de dimensiones frecuentemente representan

estructuras jerarquicas entre distintas entidades, por ejemplo la
dimensin producto, incluye un atributo marca que puede
permitir a su vez la agrupacin 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 informacin redundante, pero esta
operacin se realiza para evitar nuevas relaciones (joins) en las
consultas que se traducirian en decrementos del rendimiento del
sistema.

dimensional
Debemos resistir nuestro impulso de almacenar tan solo el

cdigo de la marca y crear una vista separada para todas las
marcas. Esto es lo que se conoce como diseo de copo de nieve
(snowflake). Por lo general las tablas de dimensiones presentan
un alto grado de de-normalizacin.
Si con la creacin de diseos 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.

dimensional
Tabla de productos
clave de producto
descripcion del producto
clave de marca (FK)
modelo
clave de familia (FK)
tipo de empaquetado
tamao empaquetado
peso
precio del producto
tabla de marcas
clave de marca
nombre de la marca
tabla de f amilias
clave de familia
nombre de la familia

dimensional
...tablas de dimensiones
o
Las tablas de dimensiones son los puntos de

entrada a las tablas de hechos. La definicin
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.

dimensional
Diseo en estrella (star join schema)

dimensin
tabla de f echas
clave de fecha
fecha
mes
dia
ao
dimensin
Tabla de productos
clave de producto
modelo
marca
familia
tipo de empaquetado
tamao empaquetado
peso
precio del producto
tabla de hechos
ventas diarias
clave de fecha (FK)
clave de tienda (FK)
clave de producto (FK)
cantidad
valor
dimensin
tabla de tiendas
clave de tienda
provincia

dimensional
Diseo en estrella (star join schema)

o
Al relacionar las tablas de hechos con las tablas de

dimensiones nos da la impresin 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 diseo es conocido como diseo en
estrella o star, aunque este termino se acuo en los
primeros das de los diseos relacionales.

dimensional
Una de las primeras cosas que nos llama la atencin acerca

del diseo es su simplicidad y simetra. Evidentemente los
usuarios se beneficiarn de esa simplicidad ya que los datos
sern mas comprensibles, fciles de usar y explorar.
o La simplicidad del modelo tambin lleva aparejado
beneficios en el rendimiento ya que los optimizadores de
base de datos procesarn estos esquemas de manera mas
eficiente cuando existen pocas relaciones entre las
entidades (joins).
o

dimensional
Diseo en estrella
o
En el grfico se
muestra como los
atributos de las
dimensiones definen
las etiquetas de las
columnas del informe ,
mientras que las
tablas de hechos
proveen los valores
numricos.
dimensin
tabla de f echas
clave de fecha
fecha
mes
dia
ao
dimensin
Tabla de productos
clave de producto
modelo
marca
familia
tipo de empaquetado
tamao empaquetado
peso
precio del producto
tabla de hechos
ventas diarias
clave de fecha (FK)
cantidad
valor
dimensin
tabla de tiendas
clave de tienda
provincia
suma
Mes
Enero
Enero
Enero
Febrero
Febrero
Febrero
Marca
Orbea
Marin
Marin
Specialized
Marin
Orbea
Provincia
Madrid
Madrid
Sevilla
Madrid
Madrid
Madrid
suma
Importe de Ventas Cantidad Vendida

4.598,00
3
2.345,00
2
12.678,00
6
2.346,00
1
1.235,00
1
2.345,00
4

dimensional
Diseo en copo de nieve (snowflake)

El modelo copo de nieve es el resultado de la
descomposicin de una o ms de las dimensiones, que a
veces poseen jerarquas.
o La estructura de este modelo muestra la estructura
jerrquica de las dimensiones muy bien.
o Su principal desventaja es la perdida de comprensibilidad
para con los usuarios, y la perdida de facilidad, as como
una devaluacin del rendimiento del sistema ya que las
operaciones de relacin entre las distintas entidades son
mayores y en consecuencia el motor de base de datos se
resiente.
o

dimensional

dimensional
En definitiva no son aconsejables por:
Aadir niveles adicionales de relaciones joins

Complica la construccin 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 creacin de planes de ejecucin
peores.
Tan solo se reduce algo de espacio de almacenamiento en la
Base de datos , a un coste de tiempos de consulta mucho
mayores.

dimensional
A evitar...
o
Centrarse demasiado en la tecnologa 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 aos
en lugar de hacer pequeos pero mas efectivos y
manejables esfuerzos de desarrollo.
Gastar esfuerzos en la construccin de una estructura de
datos normalizada antes de pensar en la construccin de un
rea de presentacin basada en modelos dimensionales.

dimensional
o
o
o
o
o
Prestar mas atencin 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 presentacin para los usuarios demasiado
complejas con estructuras de datos complejas.
Cargar slo datos sumarizados en las reas de presentacin
dimensionales de los datos.
Suponer que el negocio, los requerimientos y anlisis de
informacin son estticos, as como la tecnologa que lo soporta.
Negarse a reconocer que el xito de un DWH se centra en la
aceptacin por parte de los usuarios.

dimensional
Pasos bsicos para la transformacin de modelos OLTP

(operacionales) en diseos en estrella.
o
o
o
o
o
De-normalizar las relaciones de tipo lookup

De-normalizar las relaciones maestro-detalle
Crear y poblar una dimensin de tiempo
Crear jerarquas de datos en las dimensiones
Considerar el uso de claves subrogadas sin sentido *

dimensional
cul es la mejor herramienta para modelar datos para el

DWH?
o
Tu cerebro

dimensional
De-normalizacin
o
En nuestro ejemplo
La tabla de productos
claramente viola la tercera
norma formal:
o Nombre de familia depende
por completo de codigo de

familia
o Nombre de subfamilia
depende por completo de
codigo de subfamilia
o Nombre marca depende por
completo de codigo marca
productos
codigo producto
nombre producto
fecha inicio
fecha fin
codigo f amilia
nombre familia
codigo subfamilia
nombre subfamilia
codigo marca
nombre marca
ancho
alto
peso
cantidad por paquete

dimensional
Evidentemente al incumplir la 3 norma formal nuestro diseo

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 estaramos creando un esquema en copo de nieve
(snowflake), y como hemos visto anteriormente esto es
altamente desaconsejable.
Si para evitar la de-normalizacin optamos por realizar vistas,
estaremos en el mismo problema ya que las vistas no son ms
que consultas preescritas, que cuando se hace referencia a ellas
se ejecutan, con el consiguiente coste de rendimiento.

dimensional
Consultas a esquemas en estrella

o
Por lo general una consulta a un esquema en estrella

contendr:
Funciones de agrupacin (GROUP BY)

Contendr una relacin (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 nmero
relativamente bajo de filas.

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
Enero
Enero
Enero
Febrero
Febrero
Febrero
Marca
Orbea
Marin
Marin
Specialized
Marin
Orbea
Provincia
Madrid
Madrid
Sevilla
Madrid
Madrid
Madrid
Importe de Ventas Cantidad Vendida

4.598,00
3
2.345,00
2
12.678,00
6
2.346,00
1
1.235,00
1
2.345,00
4

dimensional
Modelado de fechas
o
El concepto de tiempo es sin duda el elemento mas

generalmente utilizado en la construccin de informes para
la empresa. No obstante es una de las materias ms
complejas a la hora de disear el DWH, ya que la manera en
la que se implemente este dato podr afectar de manera
significativa al rendimiento.

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 travs 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 das laborables

dimensional
Ventas
Ventas
Ventas
Ventas
Ventas
Ventas
Ventas
en fines de semana
en das festivos
Mensuales
Trimestrales
Cuatrimestrales
Semestrales
Anuales

dimensional
Modelado de fechas
o
Tal como se ha apuntado anteriormente el diseo 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).

dimensional
dimensin
tabla de tiendas
clave de tienda
tabla de hechos
ventas diarias
dimensin
Tabla de productos
clave de producto
modelo
marca
familia
tipo de empaquetado
tamao empaquetado
peso
precio del producto

fecha de venta
cantidad
valor
provincia

dimensional
Modelado de fechas
o
En caso de que quisiramos obtener la suma de ventas por mes en cada una
de las tiendas, por cada uno de los productos, tendramos 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 ( 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
(*) La consulta incluye funciones especficas del gestor de Bases de Datos ORACLE

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 ( 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

dimensional
El resultado de la consulta anterior, tan slo nos agrupara

las ventas por meses (enero, Febrero, Marzo, etc...) sin
tener en cuenta a que ao pertenece cada venta por lo que
para hacer an ms correcta la bsqueda escribiramos:

dimensional
Modelado de Fechas
Como es evidente al tener que realizar el clculo del mes y
del ao sobre la marcha en la ejecucin de la consulta, el
rendimiento de la consulta ser muy pobre, mas teniendo en
cuenta el nmero de registros sobre nuestra tabla de hechos
(ventas diarias).
o El uso de funciones especificas para realizar clculos sobre
datos de fecha adems 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 clculos de fecha con diferente
sintaxis.
o

dimensional
Para solucionar esto es usual en los sistemas de DWH la

creacin de una dimensin de tiempo separada, esto se
traduce en la creacin de una entidad que desglosar cada
una de las fechas en:
Fecha (fecha/alfanumrico)
o 12/12/2003
Da de mes (numrico)
o 1..31
DIA de la semana (alfanumrico)

o Lunes, Martes, Mircoles, Jueves, Viernes, Sbado, Domingo.
Nmero de mes (numrico)

o 1..12
Nombre Mes (alfanumrico)

o Enero, Febrero, Marzo, Abril, Mayo, Junio, Julio, Agosto,
Septiembre,Octubre,Noviembre,Diciembre

dimensional
Nmero de Trimestre (numrico)

o 1..4
Nombre de trimestre (alfanumrico)

o Primer Trimestre, Segundo Trimestre, Tercer Trimestre, Cuarto
Trimestre
Nmero de Cuatrimestre (numrico)

o 1..3
Nombre de Cuatrimestre (alfanumrico)

o Primer Cuatrimestre, Segundo Cuatrimestre, Tercer Cuatrimestre
Nmero de Semestre (numrico)

o 1,2
Nombre de Semestre (alfanumrico)

o Primer Semestre, Segundo Semestre

dimensional
Ao (Numrico)
o ...1990,1991,1992,1993,1994...
Festivo (booleano/alfanumrico/numrico)
o Si,No

dimensional
dimensin
tiempo
clave de fecha
Modelado de Fechas
dia
dia de la semana
mes
nombre mes
trimestre
nombre trimestre
cuatrimestre
nombre cuatrimestre
semestre
nombre semestre
anyo
festivo
dimensin
Tabla de productos
clave de producto

modelo
marca
familia
tipo de empaquetado
tamao empaquetado
peso
precio del producto
dimensin
tabla de tiendas
clave de tienda
provincia
tabla de hechos
ventas diarias
clave de fecha (FK)
fecha de venta
cantidad
valor

dimensional
Modelado de fechas
o
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 compaas en
las que el ao natural (Enero->Diciembre) no coincide con el
ao fiscal, o con lo que se denomina ejercicio. Tambin
algunas empresas tienen el ejercicio dividido en distintas
reas que no tienen por que coincidir con las definidas en el
calendario del ao natural, esto es por ejemplo cuando una
empresa tiene dividido el ejercicio en periodos trimestrales
(quarters) que no coinciden con los del ao natural o dividen
el ejercicio con otras consideraciones (primavera, verano,
otoo, invierno), etc..

dimensional
Para dar solucin a estos casos utilizaremos tambin la

misma dimensin de tiempo y aadiremos los campos
especficos para detallar esta informacin particular sobre la
fecha en la que ha ocurrido un hecho (fact).
Periodo
o 1..n
Nombre Periodo
o ....
Ejercicio Fiscal
o ....
Ejercicio comercial
o ....

dimensional
Temporada
o Alta, baja
o Invierno, verano, otoo, primavera
o ....
Etc..

dimensional
Modelado de fechas
Especifico de la
empresa
Natural / Gregoriano
3
2002
Septiembre
Septiembre
Octubre
Noviembre
Diciembre
Diciembre
Enero
Febrero
Marzo
2003
Marzo
Mayo
Junio
Junio
Agosto
Septiembre
Octubre
Noviembre
2004
Enero
Octubre
Noviembre
Diciembre
2004
Julio
Agosto
Septiembre
Abril
Mayo
Julio
Enero
Febrero
Abril
2003
Octubre
Noviembre
Diciembre
Febrero
Enero
Febrero
Marzo
Marzo

dimensional
Modelado de Fechas
Especifico de una
empresa de moda
Natural / Gregoriano
3
2002
Septiembre
Septiembre
Octubre
Otoo
Octubre
Noviembre
Noviembre
Diciembre
Diciembre
Invierno
Enero
Febrero
Marzo
Febrero
2003
Abril
Mayo
Mayo
Junio
Junio
Julio
Marzo
Abril
2003
Enero
Agosto
Julio
Primavera
Verano
Agosto
Septiembre
Septiembre
Otoo
Octubre
Noviembre
Noviembre
2004
Diciembre
Enero
2004
Octubre
Diciembre
Febrero
Invierno
Enero
Febrero
Marzo
Marzo
Primavera

dimensional
dimensin
tiempo
clave de fecha
dia
dia de la semana
mes
nombre mes
trimestre
nombre trimestre
cuatrimestre
nombre cuatrimestre
semestre
nombre semestre
anyo
festivo
quarter
nombre quarter
temporada
ejercicio
dimensin
Tabla de productos
clave de producto
modelo
marca
familia
tipo de empaquetado
tamao empaquetado
peso
precio del producto
dimensin
tabla de tiendas
clave de tienda
provincia
tabla de hechos
ventas diarias
clave de fecha (FK)
fecha de venta
cantidad
valor

dimensional
Tratamiento de Valores Nulos

o
o
o
o
o
La mayora 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.

dimensional
Valores nulos en una FK (relacin) de la tabla de

hechos
La aparicin de nulos en esta situacin puede ser debida a

diferentes razones:
El valor de la FK no se conoca en el momento de la extraccin.
No se desea que el valor correspondiente se relacione con la
dimensin a la que representa la FK.
Tambin puede ser debido a un error en la etapa de extraccin y
carga.

dimensional
o 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 an no han ocurrido, por ejemplo en una tabla
de hechos donde se recogen los pedidos, en el da de la actualizacin
probablemente existan pedidos que no hayan sido entregados an, de
ah que determinados valores de los atributos de la tabla de hechos,
se encuentren en estado nulo (fecha de entrega), en la siguiente
actualizacin de la tabla de hechos, esta situacin ser solventada
para aquellos pedidos, que hayan sido entregados en el intervalo de
tiempo entre actualizacin y actualizacin, pero tambin se generarn
nuevos registros incompletos. En este caso un eventual informe sobre
la tabla de pedidos no reflejar aquellos pedidos que estn pendientes
de entrega ya que la join

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 dimensin para
identificar la ausencia de datos por ejemplo en el caso anterior se
podra identificar con una fecha inoperativa como 1/1/9999 reflejando
esta en la tabla de dimensin con una descripcin como: no asignada,
los efectos de esta solucin darn satisfaccin a los usuarios de los
informes ya que en los informes no faltar informacin y todos los
pedidos no entregados podrn ser agrupados en la fecha no asignada.
Para el segundo y tercero de los casos se debe aplicar una solucin similar
a la anterior.

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 ningn problema, si por el contrario realizamos la
sustitucin del valor nulo por el valor cero estaremos
degradando la informacin ya que no podremos distinguir entre
aquellos que el valor es igual a 0 por que eran nulos o por que
tras el clculo realmente son igual a 0.

dimensional
Valores nulos en los atributos de las tablas de

dimensiones
La aparicin 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 tambin es aplicable la misma recomendacin, si
dejamos los valores nulos en las tablas de dimensiones puede
ser confuso para el usuario ya que aparecern como
dimensiones blancas (sin contenido) en los informes y
desplegables de las herramientas de explotacin de los datos.
Por tanto, al igual que en el caso anterior la sustitucin del valor
nulo por una cadena del tipo desconocido, no aplicable, etc..
es lo ms recomendable.

dimensional
Hay que tener en cuenta que las herramientas de explotacin 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 diseo independiente de la herramienta o
herramientas de explotacin del data warehouse.
Visualizacin 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.
o
Parecido a una hoja de clculo pero:
Trabajan con grandes volmenes de datos.

Estn optimizados para la manejar trminos de negocio
(dimensiones geogrficas, dimensiones de tiempo).
Estn combinados con capacidades de generacin de informes.
Trabajan con bases de datos dimensionales.

Aplicaciones OLAP
El termino OLAP fue acuado por E.F Codd en 1993 OnLine Analytical Processing (OLAP).
Para representar los datos corporativos en diferentes
perspectivas multidimensionales
o Realizando un anlisis en lnea (on-line) de los datos
o
usando frmulas matemticas

tcnicas estadsticas ms 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 obtencin y
manipulacin de la informacin, contenida en las bases
de datos dimensionales.

Aplicaciones OLAP
Son frecuentemente comparados con lo que se

denominan Bases de datos estadsticas (statistical
databases).
Una clase de bases de datos que permiten la definicin,
manipulacin, elaboracin y almacenamiento de datos
multidimensionales precalculados.
o la principal diferencia entre ambas estriba en que las bases
de datos estadsticas calculan los datos sobre otras bases de
datos, mientras que las bases de datos OLAP representan
los datos directamente.
o

Aplicaciones OLAP
OLAP incluye datos de definicin 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 ms de tres dimensiones, en ese caso
su representacin se realiza con cubos que reciben el
nombre de hipercubos (hypercube).

Aplicaciones OLAP
En la figura podemos ver como se representan las cifras de volumen de ventas

determinado por la combinacin de tres dimensiones, tiempo, producto y
provincia
Granada
Las Palmas
Madrid
Segovia
Bicicletas
Patines
Volumen de ventas en funcin

del tiempo, producto y provincia
3200
1345
2567
1204
6709
150
245
245
245
340
150
Balones
Camisetas
Mochilas
240
267
120
789
356
1245
3789
2567
130
780
560
125
234
1235
370
Enero
Febrero
Marzo
Abril
Mayo

Aplicaciones OLAP
Operaciones bsicas de OLAP
Existen cuatro tipos bsicos de operaciones en OLAP para el anlisis de

datos.
Las operaciones conocidas como drill down y roll up bsicamente van
ha definir el nivel de granularidad con la que queremos analizar los datos,
las operaciones slice y dice nos permitirn 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 operacin de Drill down tambin se conoce como agregacin dinmica.

Aplicaciones OLAP

Aplicaciones OLAP
Slice y Dice
Las operaciones de Slice (trocear) y dice (dado) se corresponden

a las operaciones para la visualizacin de los datos a travs del
cubo.
Slice y dice son las habilidades para acceder a un data
warehouse a travs 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 operacin de Slice realiza un corte en el cubo para que los
usuarios puedan centrarse en un rea determinada del cubo.
Tambin puede decirse que define un subcubo.

Aplicaciones OLAP
La operacin dice, rota el cubo hasta una nueva perspectiva,

para que los usuarios puedan ver los datos desde diferentes
perspectivas en su anlisis de los datos.
Con estas operaciones el usuario que analiza la informacin,
puede agruparla de una manera, analizarla, agruparla de otra y
realizar otro anlisis. Con las operaciones de slice y dice el
usuario posee diferentes perspectivas para el anlisis.

Aplicaciones OLAP

Aplicaciones OLAP
Implementacin de OLAP
El siguiente paso se basa en la eleccin del tipo de
almacenamiento del cubo OLAP.
o La calidad del diseo inicial del proyecto de data warehouse
es inversamente proporcional al coste de la implementacin
del cubo...
o El diseador 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 tamao de los
datos almacenados y la conexin prevista para la carga de
los datos.
o

Aplicaciones OLAP
El diseo 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 volmenes de datos con
consultas frecuentes.
o Las consultas que los usuarios realizan contra los cubos
OLAP consumen grandes recursos del sistema.
o

Aplicaciones OLAP
El almacenaje de los cubos de OLAP es una de las decisiones crticas que se han
de tomar a la hora de disear 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 opcin ms rpida para la
recuperacin de datos, pero requiere de mucho espacio
en disco, aunque en nuestros das esto no es un gran
problema debido al bajo precio de almacenamiento.

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
localizacin de la fuente o no. ROLAP es el mtodo de
almacenamiento mas lento en la recuperacin de los
datos. ROLAP tiene sentido en pequeos volmenes de
datos.

Aplicaciones OLAP
HOLAP
OLAP Hbrido. HOLAP es una combinacin 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.

Aplicaciones OLAP
Debido a que los costes de hardware son cada vez mas

bajos, MOLAP se presenta como la mejor opcin siempre
que sea posible el acceso a una base de datos o fuente
MOLAP independiente. Por otro lado ROLAP es ms
conveniente en el caso de que el nmero de consultas
sea reducido y el volumen de datos relativamente bajo.

Aplicaciones OLAP
Seguridad de OLAP
El almacenamiento de los cubos tambin beneficia a las polticas 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
actuacin con ellos (definicin 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.
o Estas estrategias de seguridad, junto con la posibilidad de
almacenamiento de los cubos OLAP, permiten a las compaas
ahorros considerables en hardware y software para el
procesamiento ad-hoc de las consultas OLAP, as como el
establecimiento de polticas de gestin de los datos adecuadas.
o

Aplicaciones OLAP
Todos los empleados
Mandos Intermedios
Directivos
Comit de direccin
Permisos para acceder a un nmero

limitado de cubos predefinidos,
dependiendo de las polticas de
seguridad aplicables
Permiso para acceder nicamente a

cubos predefinidos
Permiso para acceder a cubos

predefinidos, as como para realizar
consultas OLAP ad-hoc sin lmite
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
aaden al data warehouse o a los distintos data marts.
Esta operacin es la ms complicada en la implementacin del
DWH, ya que:
Las estructuras de datos son completamente diferentes
o Pueden presentarse distintos orgenes de datos
o Es normal realizar transformaciones y operaciones de clculo sobre
los orgenes de datos
o
El proceso de transformacin y carga estn condicionados por:

Estructura de datos del sistema operacional
o Estructura de datos del propio data warehouse.
o
Etapas del proceso de carga del data warehouse

o
En el proceso de carga del data warehouse por tanto

podemos establecer tres etapas claramente diferenciadas:
Extraccin
Transformacin
Carga
Extraccin
La extraccin es el proceso de recogida de los datos desde los
sistemas operacionales o transaccionales u otras fuentes externas
de datos.
o El tipo de extraccin est por tanto directamente relacionado con el
tipo de origen desde el que se realice la extraccin.
o Podemos agrupar los mtodos de extraccin en 6 tcnicas:
o
Extraccin
Extraccin
Extraccin
Extraccin
Extraccin
Extraccin
directa
desde el log de la Base de Datos
ejecutada por disparadores (triggers)
asistida por aplicaciones
en un punto del tiempo
por comparacin
Extraccin directa
La extraccin directa genera como resultado una foto fija de los

datos (snapshot) en un momento determinado del tiempo.
o Generando ficheros externos (ASCII CSV, scripts, etc..)
o Generando tablas temporales.
Impacta en el rendimiento de la BBDD origen (operacional)

o Se realiza en horas valle
o Das de poca actividad
Extraccin desde el Log de la base de datos
Los datos son extrados directamente desde los mecanismos de

registros de transacciones de los motores de bases de datos.
Permite la actualizacin constante casi en tiempo real de los
ficheros de extraccin o del data warehouse, en el caso de
actualizacin 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 tcnicas de programacin muy especificas y de un
conocimiento detallado de las estructuras de almacenamiento en
los registros de log del motor de base de datos en cuestin,
para la extraccin tan slo de aquellos datos que son de nuestro
inters.
Extraccin ejecutada por disparadores (triggers)
Este tipo de extraccin permite tambin la actualizacin en

tiempo virtualmente real de los dispositivos de extraccin.
El mayor inconveniente de esta tcnica de extraccin es que el
sistema (la base de datos) se ve afectada en el rendimiento al
ejecutar por cada evento el procedimiento correspondiente de
actualizacin de la informacin en el destino,
o Este inconveniente puede verse agravado en el caso de que nuestro
sistema est configurado para la ejecucin anidada de disparadores

haciendo que el sistema entre en un estado de actualizacin en
cascada que puede interferir gravemente en el rendimiento del
sistema operacional.
El impacto sobre el rendimiento se puede aminorar si los

triggers tan slo realizan llamadas a una cola externa de
ejecucin
Extraccin asistida por aplicaciones
La extraccin asistida por aplicaciones permite la realizacin de

extracciones complejas sobre los distintos orgenes de datos.
Estas aplicaciones, requieren la programacin explcita de
procedimientos de extraccin para todas y cada una de las
operaciones de extraccin que hayan de ser realizadas.
Un fallo de programacin podra desvirtuar la informacin

extrada.
Existe la posibilidad de usar herramientas especificas para la
extraccin ETL (Extract Transforming Load), que suelen ser
productos comerciales de probada efectividad.
o Incrementan
la productividad a la hora de crear procesos de

extraccin ya que no requieren de programacin propiamente dicha.
o Por otra parte su costo muchas veces no est justificado.
o Su rendimiento suele ser por lo general inferior a un cdigo nativo
optimizado de BBDD.
Existen en el mercado gran variedad de herramientas ETL que

pueden abarcar soluciones para distintas necesidades y
presupuestos, algunas de las mas representativas son:
o Oracle Warehouse Builder (Oracle)
o Microsoft DTS (Microsoft, incluido en el producto MS SQLServer)
o Powermart (Informtica)
o PowerStage, Distribution Agent for VMS (Sybase)
o DataStage (Ascential)
o DataExchange (Pervasive)
o DataPropagator , Visual Warehouse (IBM)
o DecisionBase (Computer associates)
o DecisionStream (Cognos)
o ActaWorks (Acta Technologies)
o Load Plus (BMC)
o Etc..
Existen no obstante numerosos detractores del uso de este tipo

de herramientas, sus razones para tomar esta postura son:
o Las herramientas ETL no producen un cdigo optimizado y eficiente
o Las herramientas ETL, cuestan dinero, generalmente cuestan ms
dinero que las horas de programacin 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 actualizacin
constante del destino de los datos.
Extraccin en un punto del tiempo
Este tipo de extraccin requiere que los registros origen

contengan un campo con la fecha y hora de la ltima
actualizacin, de esta manera el proceso de extraccin podr
fcilmente distinguir entre aquellos registros que sern
transportados hasta su destino y cuales no. Si un registro ha
sido aadido o modificado ser enviado a un fichero o tabla para
su posterior procesamiento o transformacin.
Extraccin por comparacin
La extraccin por comparacin es una tcnica que se us mucho

en el pasado pero que actualmente se encuentra en desuso,
debido principalmente al rendimiento y eficiencia de esta
tcnica.
Sencilla de comprender y de implementar.
Consiste en la extraccin de una copia del origen de datos
(snapshot) en un punto del tiempo, en la siguiente extraccin,
se produce de nuevo un nuevo fichero como resultado de la
extraccin 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.
En el siguiente cuadro se especifican las diferentes tcnicas y su aplicacin ms

adecuada para cada una de ellas:
Transformacin
El proceso de transformacin convierte los datos extrados
desde los sistemas operacionales y otras fuentes a un
formato y estructura conveniente para la carga en el data
warehouse o el data mart.
o Durante este proceso, es natural que se produzcan datos
(metadatos) que describen tanto el origen como el destino
de los distintos valores despus de la transformaci.
o Este proceso tambin se conoce como mapeado de
campos (mapping).
o Ayudar a resolver las posibles anomalas de los datos en
origen
o Ayudar a producir datos de alta calidad .
o
Durante el proceso de transformacin, 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.
o El proceso de transformacin puede requerir que los datos
extrados sean procesados repetidas veces probablemente
debido a que los datos de origen (extrados) son usados
para la carga de distintos registros en el destino.
o
Carga
o
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 tcnicas para el proceso de carga:
Carga simple (load)

Aadir (append)
Mezcla constructiva (constructive merge)
Mezcla destructiva (destructive merge)

o
Carga simple (load)
La carga simple reemplaza todos los datos del destino con los
nuevos datos resultado de la transformacin. Si las tablas de
destino no existen son creadas en este proceso.
Aadir (append)
Aade los nuevos datos sobre los datos ya existentes en el

destino, sin sustituir ni modificar ninguno de los existentes.
Mezcla constructiva (constructive merge)
Aade los nuevos registros sobre el destino y actualiza un valor

de fecha que indica la fecha y hora de la ltima actualizacin
sobre aquellos registros existentes que estn siendo
reemplazados.
La importancia del modelo de datos

o
Debido a los procesos de carga, es muy importante a la hora

de disear las estructuras de datos del data warehouse (el
modelo de datos), tener en cuenta los procesos de carga, ya
la eleccin 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 orgenes de los datos

Los intervalos de tiempo entre actualizaciones
El formato de los datos.
Dependiendo de si los datos existen o no en los orgenes,

los datos debern ser creados en el origen o calculados en el
proceso de transformacin y carga, por lo que los datos
requerirn un mayor nivel de procesamiento con el
consiguiente consumo de tiempo y recursos.
o Otro de los puntos importantes que deben ser tenidos en
cuenta a la hora tanto del diseo del modelo de datos del
data warehouse como de los procesos de carga de los datos
es la granularidad del data warehouse.
o
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 tambin se conoce como Waterfall
model.
El ciclo de vida de desarrollo de sistemas

o
Etapa 1 -- Viabilidad
Se especifican los beneficios de implementar el sistema.
Etapa 2 -- Definicin 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)
Interaccin del usuario con el sistema
Condiciones de operacin del sistema
Informacin generada por el sistema y su tratamiento
Etapa 3 Diseo
Etapa 4 Desarrollo
Especificaciones de programacin
Especificaciones de base de datos
Especificaciones de seguridad, etc...
Parte del diseo para llevar a la practica los distintos procesos
orgnicos descritos en la fase de diseo
En esta fase tambin se incluyen las pruebas del sistema antes
de pasar a produccin
Etapa 5 Implementacin
El sistema se lleva a produccin despus de la aceptacin del

usuario final
Fases del proyecto data warehouse
Se definen 7 fases en la gestin de un proyecto de data

warehouse
o
o
o
o
o
o
o
o
o
Requisitos
Diseo de la Arquitectura tcnica
Seleccin del producto e instalacin
Diseo del modelo dimensional
Diseo fsico
Diseo y desarrollo del proceso de transformacin y carga
Especificaciones de las aplicaciones de anlisis e informes
Desarrollo de las aplicaciones de anlisis e informes
Desarrollo e implementacin
Mantenimiento
Requisitos
o
En esta fase mediante entrevistas, recogida de informacin

y documentos se establecern 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.
Preguntas tpicas en un entrevista seran:
cmo se distinguen o agrupan los distintos productos? ... o los

agentes, o los proveedores, etc..
Si el entrevistado realiza una anlisis de los datos generados en
su rea, preguntaremos entonces acerca de cmo lleva a cabo
los anlisis y cuales son los datos requeridos para esta
operacin.
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 automtica o manual y
sobre los que presentarn las mejoras que necesitan y por
que las necesitan.
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 cmo mejorar la gestin de la
informacin en la compaa.
o 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 relacin con
la informacin generada en los sistemas operacionales.
o En la etapa de requerimientos tambin 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.
o
Diseo de la arquitectura tcnica

En esta etapa diseamos la integracin entre las distintas
tecnologas, existentes con el nuevo proyecto, analizamos el
impacto en los sistemas as como las necesidades que
surgirn para soportar el proyecto. Tambin se definir la
lnea de tiempo para las distintas partes del proyecto.
o Como es evidente el diseo de la arquitectura tcnica ha de
venir marcado por los requerimientos del negocio.
o En esta fase ha de ser tenidas en cuenta las polticas de
tecnologas de la informacin, las arquitecturas tecnolgicas
existentes, la evolucin futura tecnolgica de la empresa,
as como sinergias con otras empresas del grupo.
o
Todos las soluciones tecnolgicas propuestas para dar

respuesta a las necesidades del negocio han de ser
documentadas debidamente.
1.
2.
3.
4.
5.
6.
7.
8.
Establecer un equipo para el diseo de la arquitectura.

Recoger requerimientos readicionados con la arquitectura
Documentar los requerimientos de arquitectura
Desarrollar un modelo de arquitectura a alto nivel
Disear y especificar los subsistemas dentro de la arquitectura
Determinar las fases de implementacin de la arquitectura
Documentar la arquitectura tcnica
Revisin y finalizacin de la arquitectura tcnica
Seleccin del producto e instalacin

1.
2.
3.
4.
5.
6.
El primer paso antes de seleccionar nuevos productos, es comprender el

proceso de aprobacin de compras interno de la compaa.
Desarrollar una matriz de evaluacin 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.
Rastrear el mercado para localizar las posibles soluciones existentes y a
los proveedores.
Ir estrechando la lista de productos candidatos y realizando evaluaciones
ms detalladas.
Realizar pruebas de test si tenemos acceso a productos de evaluacin.
Seleccionar un producto, instalarlo en pruebas y negociar con el o los
posibles proveedores.
Diseo del modelo dimensional

o
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.
Diseo fsico
o
El modelo dimensional diseado en la fase anterior debe ser

traducido al diseo fsico para el motor de base de datos
especifico que hayamos seleccionado.
En esta etapa se establecen las estrategias de agregacin,
as como la creacin inicial de ndices en el rea de
almacenamiento.
Los ndices ms recomendables son:
Sobre tablas de dimensiones:

o ndice sobre la clave primara
o ndices en B-tree en columnas usadas como FK con alta
cardinalidad.
o ndices en Bitmap en columnas con media y baja cardinalidad.
Sobre tablas de hechos:

o Por lo general las tablas de hechos tienen ndices compuestos por las
distintas claves forneas (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 travs de la dimensin de tiempo, la clave fornea (FK)
correspondiente a esta dimensin debe de ser la primera en el ndice
compuesto.
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..
Diseo
y
desarrollo
transformacin y carga
o
de
los
procesos
de
En este estado se disean y desarrollan las reas

temporales de almacenamiento previos a la transformacin.
En esta etapa se disean y desarrollan tambin los
procedimientos para combinar los datos, cualificarlos,
identificar cambios, gestionar las claves, crear valores de
anlisis y manejar errores.
Especificaciones de las aplicaciones analticas y de

informes
o
Siguiendo los requerimientos del negocio establecidos en la

primera fase, en esta fase se establece el diseo y
funcionalidades de las distintas aplicaciones que explotarn
los datos del data warehouse.

Desarrollo
informes
o
de
las
aplicaciones
analticas
de
Se realiza el desarrollo de las aplicaciones diseadas en la

fase anterior.

Desarrollo e implementacin
En esta fase convergen las fases en las que se crearon los
procedimientos y reas de extraccin y transformacin de
datos y las de desarrollo de las aplicaciones de anlisis e
informes. En esta fase se ultima la integracin entre las
distintas reas y se implementa el sistema en produccin,
con las debidas pruebas preliminares.
o En esta fase tambin ser necesario formar a los usuarios
en las herramientas de explotacin de los datos, as como la
generacin de manuales de uso.
o

Mantenimiento
o
Finalmente en este estado se realizan las labores de:
Soporte a los usuarios

Formacin continua
Soporte tcnico
Monitorizacin
http://www.hermenegildoromero.com
Hermenegildo Romero
hromero@db-team.com

Fundamentos Datawarehouse

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Fundamentos Datawarehouse

Cargado por

Copyright:

Formatos disponibles

Fundamentos de Data

De donde vienen los datos del DWH?

DWH es una base de datos que sigue cuatro caractersticas:

Existen diferentes aplicaciones en la organizacin

o Estaciones de trabajo en red e independientes.

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

Debido a este tipo de volumen de datos y el anlisis que se realiza

PARA LOGAR ESTOS RESULTADOS NO BASTA CON LA

Arquitectura del DWH

Consistencia de los datos (Data consistency architecture)

La consistencia de los datos se basa en la eleccin de los distintos

Arquitectura del DWH

Arquitectura del almacn de datos para informes y del rea

Arquitectura del DWH

Consiste en la eleccin acerca de si se usarn modelos de datos,

Arquitectura del DWH

Arquitectura de herramientas (Tool architecture)

La eleccin de herramientas que sern usadas para reporting.

Arquitectura de procesado (Processing tiers architecture)

Arquitectura de Seguridad (Security Architecture)

Aunque la seguridad no presenta ninguna dificultad tcnica a la hora

Arquitectura del DWH

Un sistema DWH debe resolver necesidades propias de

Arquitectura del DWH

Como detectar un DWH

Funcionalidad (Para que sirve?)

Arquitectura del DWH

Dependiendo de las respuestas a las preguntas descritas

Arquitectura del DWH

Arquitectura del DWH

Otra de las mejores formulas para distinguir un DWH de

Arquitectura del DWH

Los sistemas DWH por lo general tienen menos tablas y

Arquitectura del DWH

Arquitectura del DWH

El sistema DWH debe:

Debe hacer la informacin de la compaa accesible de

Arquitectura del DWH

cmo puede responder un sistema a la pregunta?

por qu no se han alcanzado los resultados de ventas

Hasta el momento no existe ningn sistema informtico

Arquitectura del DWH

Para que esta pregunta tenga respuesta a travs del

As la primera pregunta sera:

Arquitectura del DWH

Si quisiera que me mostrase tan slo aquellos productos que

cules son las ventas acumuladas para cada uno de los

Despus de descubrir cuales son los productos que no

El mismo anlisis podra hacerse para localizar reas de

Arquitectura del DWH

Un director de ventas se preguntar probablemente:

qu productos son los que mas se venden y cuales los que

Por cifra de negocio (facturacin)

cul es el periodo medio de compra de mis clientes?

Arquitectura del DWH

cmo clasificara a mis clientes?

qu clientes han reducido su periodo medio de compra?

Arquitectura del DWH

qu clientes no han comprado nada en los ltimos 3

Arquitectura del DWH

Una de las mayores obligaciones de un sistema de

Tener acceso a los datos correctos en el momento correcto y