Fundamentos de DataWarehouse

Fundamentos de Data Warehouse

Hermes RomeroHermes Romero

DATABASE TEAMDATABASE TEAM

Contenidos

Introducción Arquitectura del data warehouse Estructura de un Data warehouse Data marts Granularidad Exploración y minería de datos Diseño del data warehouse Visualización del modelo dimensional Aplicaciones OLAP (bases de datos dimen

sionales) Carga de datos en el data warehouse Ciclo de vida del data warehouse

© 2004 Database Team S.L

© Hermes Romero

www.hermesromero.comDATABASE TECHNOLOGIES & SERVICES

Introducción

Data Warehouse es una solución no un producto o grupo de productos.

Un DWH puede ayudarnos a obtener respuestas para tomar decisiones de manera más acertada.

Antes de construir un DWH debemos responder a las siguientes preguntaso ¿De donde vienen los datos del DWH?o ¿cómo se cargarán los datos en el DWH?o ¿cómo se mantendrán?o ¿cómo se estructuran los datos en el DWH?o ¿qué podemos encontrar en un momento del tiempo en el DWH?


© Hermes Romero


Introducción

Definición de DWHo Data Warehousing : diseño e implementación de procesos, y

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

o La definición aceptada de DWH se atribuye a Bill Inmon en 1992*:• DWH es una base de datos que sigue cuatro características:

o Subject orientedo Nonvolatileo Integratedo Time variant


© Hermes Romero


Introducción

La necesidad del DWH surge a partir de la necesidad de obtener acceso fácil a una serie de datos estructurados con la calidad suficiente para ser usados en la toma de decisiones.

Es sabido por todo el mundo que la información es un potente activo del que se pueden obtener importantes beneficios y ventajas competitivas para cualquier organización.


© Hermes Romero


Introducción

En las décadas de los 80 y 90 las compañías se han preocupado principalmente por la adecuación de los sistemas operacionales, es decir por la obtención de los datos, la disponibilidad de las aplicaciones, el almacenamiento de los datos, etc... En nuestros días ha legado el momento de sacar partido de esa información, el problema es que los sistemas operacionales no permiten en la mayoría de los casos la obtención de información de manera rápida y precisa para la toma de decisiones, por diversas causas.


© Hermes Romero


Introducción

Debido principalmente a tres fenómenos que han ocurrido durante la pasada década los tamaños de las bases de datos se han visto incrementados significativamente:o Los costes de almacenamiento se han vuelto insignificantes

en comparación con el valor de la información almacenada.o Las empresas valoran la información (datos) como un activo

de negocio crítico.o Muchas de las empresas multinacionales comparten su

información a través de toda la organización a nivel mundial.


© Hermes Romero


Introducción

o Existen diferentes aplicaciones en la organización• Diferentes estructuras de datos• Diferentes motores de datos• Diferentes almacenamientos físicos de información (ficheros)• Diferentes plataformas

o Mainframeso Sistemas medios multiprocesadoro Proveedores externos de servicioso Estaciones de trabajo en red e independientes.

• Información distribuida• Multiplicidad de tipos de datos

o Por ejemplo un sistema calcula la edad a través de la fecha de nacimiento, otro lo escribe en un campo, uno llama edad al atributo, otro le llama AGE...


© Hermes Romero


Introducción

o Este tipo de organizaciones tendrán que desarrollar y mantener diferentes aplicaciones para extraer, preparar y consolidar la información en informes y analíticas.

o Es normal también que los responsables de la toma de decisión, a la hora de efectuar un hallazgo quieran profundizar más en los datos que han llevado a ese hallazgo.


© Hermes Romero


Introducción

Los sistemas DWH implementan :o Los procesos de acceso a datos heterogéneos, limpios, filtrados y

transformadoso El almacenamiento de datos en estructuras fáciles de acceder,

fáciles de usar y comprensibles. Los datos en el DWH son usados para consultar, analizar y

realizar informes. El tipo de acceso, uso, tecnología y rendimiento son

completamente diferentes de los sistemas transaccionales operacionales OLPT.


© Hermes Romero


Introducción

Los volúmenes de datos en el DWH pueden ser considerablemente altos, particularmente si existen análisis basados en históricos.o Debido a este tipo de volumen de datos y el análisis que se realiza

sobre ellos se desaconseja hacer este tipo de operaciones directamente sobre los sistemas transaccionales ya que estos pueden verse impactados de manera negativa en su rendimiento debido a las operaciones masivas que requiere el análisis. Existe por tanto un requerimiento de separación de los dos entornos DWH-OLPT para minimizar lso posibles conflictos y degradación de rendimiento en el sistema operacional.


© Hermes Romero


Introducción

Los sistemas DWH no son considerados ahora como meras fotos-fijas (snapshots) de de los datos operacionales. Los sistemas DWH deben ser considerados como nuevas fuentes de información concebidas para el uso de toda la organización. La simple reingeniería de los modelos operacionales no satisfacen los requerimientos para el DWHing. El desarrollo de DWH requiere mucho más análisis aplicado a las técnicas de modelado y una relación mucho mas cercana con el propio negocio de la organización.


© Hermes Romero


Introducción

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

El DWH también ayuda al descubrimiento de cosas que diferencian a la organización.


© Hermes Romero


Introducción

PARA LOGAR ESTOS RESULTADOS NO BASTA CON LA SIMPLE REINGENIERIA DE LOS MODELOS DE DATOS OPERACIONALES.


© Hermes Romero


Arquitectura del DWH

Consistencia de los datos (Data consistency architecture)o La consistencia de los datos se basa en la elección de los

distintos orígenes de datos, dimensiones, Reglas de negocio, métrica y semántica, que una organización selecciona para un uso común.

o Este es de lejos el aspecto más difícil de implementar en la arquitectura del data warehouse debido a que incluye y está condicionada por las políticas y la organización de la compañía.

o Las decisiones acerca de esta arquitectura deben de conducir a todas las otras decisiones.


© Hermes Romero



Arquitectura del almacén de datos para informes y del área de almacenamiento temporal (Reporting data store and stagin data store architecture)o Las principales razones por las que se almacenan datos en

un data warehouse son:o Realización de informes que hacen uso de ellos (Reported

against)o Limpieza y organización de los datos (Cleaned up)o Transporte a otro almacén de datos donde pueden ser

utilizados para realización de informes o para su limpieza y organización.


© Hermes Romero



Arquitectura del modelado de datos (Data modeling Architecture)o Consiste en la elección acerca de si se usarán modelos de

datos, normalizados, denormalizados, orientados a objetos, propietarios, multidimensionales, etc...


© Hermes Romero



Arquitectura de herramientas (Tool architecture)o La elección de herramientas que serán usadas para reporting.

Arquitectura de procesado (Processing tiers architecture)o Elección de las plataformas físicas para el procesamiento

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

Arquitectura de Seguridad (Security Architecture)o Aunque la seguridad no presenta ninguna dificultad técnica a

la hora de ser aplicada si presenta complejas dificultades desde el punto de vista político.


© Hermes Romero



Un sistema DWH debe resolver necesidades propias de negocio y es por ello que será “sponsorizado” por las personas del negocio que harán uso de el.

Un DWH también sigue determinadas especificaciones de diseño, un DWH no es un DWH simplemente por que alguien dice que lo es.


© Hermes Romero



Como detectar un DWHo Funcionalidad (¿Para que sirve?)o Número de Consultas “ad-hoc” (personalizadas) de los

usuarioso Número de consultas personalizadas por día y por usuario-

díao Número de usuarios de informes standardo Numero de usuarios, usuarios-día de informes standardo Número de informes standardo Volumen del historico a almacenar en meses, trimestres o

años.o Volumen de datos típico para almacenar (diario,semanal o

mensual)


© Hermes Romero



Dependiendo de las respuestas a las preguntas descritas anteriormente se pueden establecer cuatro categorias:o OLPT – sistema transaccional de operacioneso ODS operational data storeo OLAP online analytical processingo DM / DW Data mart / data warehouse


© Hermes Romero



OLPT ODS OLAP DM/DWFuncionalidad Operacional Operacional/Decisional Decisional Decisional/EstrategicaHerramientas de usuario final Cliente Servidor/WEB C/S-WEB C/S C/S-WEBtecnologia BBDD Relacional Relacional Cubica RelacionalNº de transacciones Alto Medio Bajo BajoTamaño de la transacción Bajo Medio Medio Altotiempo de tranascción Corto Medio Medio AltoTamaño BBDD en GB 1 OLPT * 2 - OLPT *10 OLPT * 2 - OLPT *10 OLPT*2-OLPT*100Modelado de datos Entidad Relación Entidad Relación N/A DimensionalNormalización 3-5 NF 3 NF N/A 0 NF


© Hermes Romero



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


© Hermes Romero



Los sistemas DWH por lo general tienen menos tablas y mas grandes, mientras que los operacionales tienen mas tablas y mas pequeñas.

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


© Hermes Romero



OLPT ODS OLAP DM/DWNº de tablas 1-miles 1-miles OLPT/10 OLPT/10Media de Registros por tabla miles -millones miles - millones millones millonesMedia de tamaño por tabla (GB) 1 a 99 1 a 99 1 a 99 1 a 999Nº de registros de la tabla mas grande miles - millones miles - millones miles - millones miles - cientos de millonesTamaño de la Tabla mas grande (GB) 1 a 99 1 a 99 1 a 99 1 a 999Tamaño de los segmentos de Rollback 1 a 100 Mb 1 a 100 Mb N/A 1 a 999 GbTamaño de los segmentos temporales 1 a 100 Mb 1 a 100 Mb N/A 1 a 999 Gb


© Hermes Romero



El sistema DWH debe:o Debe hacer la información de la compañía accesible de

manera sencilla a usuarios ofimáticos no avanzadoso Debe presentar la información de la compañía de manera

consistente y estructuradao Debe adaptarse al cambio en el entorno y adaptable a las

necesidades puntuales del usuarioo Debe ser lo suficientemente seguro para proteger el activo

mas importante de la compañía ... La información.o Debe servir a la funcionalidad ultima de mejora de la toma

de decisión.o Los usuarios deben de aceptar el sistema si se pretende que

su implementación y uso se haga con éxito.


© Hermes Romero



¿cómo puede responder un sistema a la pregunta?o ¿por qué no se han alcanzado los resultados de ventas

previstos? Hasta el momento no existe ningún sistema informático

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


© Hermes Romero



Para que esta pregunta tenga respuesta a través del sistema es necesario realizar diversas consultas sistemáticas:o Así la primera pregunta sería:

• ¿Para cada producto, cuales son las ventas acumuladas del año?• El sistema nos devolvería una lista de los productos con sus

cifras de venta correspondientes


© Hermes Romero



o Si quisiera que me mostrase tan sólo aquellos productos que su cifra de ventas es menor que la cifra de ventas objetivo

• ¿cuáles son las ventas acumuladas para cada uno de los productos en las que las ventas actuales son menores que los objetivos?

o Después de descubrir cuales son los productos que no alcanzan la cifra objetivo, analizará cada caso para ver cual es la posición del producto con respecto al mercado, etc...

El mismo análisis podría hacerse para localizar áreas de venta donde no se están alcanzando los objetivos, vendedores que no están alcanzando la cifra, etc...


© Hermes Romero



Un director de ventas se preguntará probablemente:o ¿qué productos son los que mas se venden y cuales los que

menos?o ¿cuáles son los clientes mas importantes?

• Por cifra de negocio (facturación)• Por rentabilidad

o ¿cuál es el periodo medio de compra de mis clientes?


© Hermes Romero



o ¿cómo clasificaría a mis clientes?• A,B,C – Pareto

o Basado en cifra de negocioo Basado en rentabilidado Basado en periodo medio de compra

• Otros...

o ¿qué clientes han reducido su periodo medio de compra?o ¿qué clientes han reducido su importe medio de compra?


© Hermes Romero



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

o ¿por qué no se están cumpliendo los objetivos de ventas?• A nivel local• A nivel provincial• A nivel regional• A nivel nacional• ...

o ...


© Hermes Romero



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

con un tiempo de respuesta aceptable.


© Hermes Romero


Estructura de un DWH

Un data warehouse es un sistema orientado a determinados “asuntos” o áreas del negocio, es también un sistema integrado, no volátil y cambiante en el tiempo, que da soporte para la toma de decisiones de los niveles ejecutivos y gerenciales de una empresa.o Como es evidente cada tipo de negocio posee su propio

conjunto de “asuntos” o áreas. Es decir una empresa dedicada a la distribución probablemente posea una serie de áreas comunes de análisis con el resto de empresas que se dediquen también a la distribución.

o El data warehouse contiene datos corporativos estructurados de manera granular.


© Hermes Romero



Está integrado o Esta es la característica más importanteo Los datos llegan de diferentes orígenes y son cargados en

el data warehouse.o Los datos en su camino hacia el data warehouse pueden

sufrir transformaciones fruto de cálculos realizados sobre los mismos.• Conversión de datos• Reformateado (Reformatted)• Cambio de secuencia (Resequenced)• Sumarizados (Summarized)• Etc...


© Hermes Romero



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


© Hermes Romero



Históricamente las distintas aplicaciones de una compañía manejaban la información de diferente manera, con diferentes tipos de datos.o No existía por tanto un consistencia a la hora de la

codificación, nombres de entidades y atributos, tipo de datos, etc.., ...lo que hacía más difícil su integración en un único sistema de explotación de la información generada.

o Es por tanto tarea del sistema data warehouse especificar un único repositorio que integre las diferentes peculiaridades de los distintos orígenes de datos. (Una única estructura de datos para distintos orígenes de datos con estructuras diferentes)


© Hermes Romero



No es volátil (nonvolatile)o Al contrario que en los sistemas transaccionales OLPT, los

datos en el data warehouse no son accedidos de manera regular de registro en registro.

o Los data warehouse son cargados (generalmente en masa) y accedidos sólo para su consulta no para su actualización.

o Cuando el data warehouse se carga genera una foto fija en el tiempo de los datos (snapshot).

o Cuando se producen nuevas cargas fruto de cambios en los sistemas OLPT una nueva foto fija de los datos nuevos se generará de manera que los datos ya cargados junto con los nuevos pasarán a formar parte del histórico del data warehouse.


© Hermes Romero



Variable en el tiempoo Que el data warehouse sea variable en el tiempo implica que

cada dato incluido en el data warehouse ha sido obtenido en un momento en el tiempo.

• En algunos casos el registro tiene un campo de fecha.• En otros casos esa fecha se corresponde con la fecha en la que

se valido la transacción que lo contenía.• En cualquier caso un registro siempre está sometido a una

variable de tiempo.


© Hermes Romero



o El horizonte temporal de un sistema data warehouse es mayor al de un sistema operacional.

• Operacional 60-90 días.• DWH 5 a 10 años.

o El data warehouse debe contener más datos históricos que cualquier otro sistema.


© Hermes Romero


Data Marts

Pequeños data warehouses que pueden trabajar independientemente o interconectados.

El data mart depende de la arquitectura seleccionada para el data warehouse.


© Hermes Romero


Data Marts

Siempre ha existido una discusión acerca de si la arquitectura del DWH debía estar basada en Data Marts, o bien completamente centralizado.

Los data warehouses centrales (“enterprise wide data warehouses”) o Proyectos mas arriesgadoso Altos costes o Tiempos altos de desarrollo.


© Hermes Romero


Data Marts

Los data marts o Se pueden implementar de manera rápida y sencillao Son proyectos de bajo riesgo.o presentan los datos desde la perspectiva de un proceso

simple de negocio (subject). La cantidad de datos históricos contenidos en un data

mart deben ser dictados por los requerimientos del negocio.


© Hermes Romero


Data Marts

Arquitectura en Buso 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.

o Los data marts también son conocidos como data warehouses departamentales (departamental data warehouses).

• No debe ser estrictamente departamental ya que es relativo a un proceso de negocio no a un departamento.

• facturación, llamadas del call center, movimientos de almacén, procurement, etc...


© Hermes Romero


Data Marts

...arquitectura en buso Algunas veces los diseños de arquitecturas data warehouse

basados en data marts caen en el error de diseñar estructuras de tela de araña donde múltiples extracciones de un mismo origen de datos se cargan en diferentes data marts. Con esto diseños se debe tener en cuenta el mayor coste así como la posibilidad de inconsistencias de los datos en los diferentes data marts.

o Las arquitecturas basadas en estructuras de tela de araña no tienen en cuenta que el diseño de los distintos data marts debe estar basado en el proceso de negocio y no en la organización departamental de la compañía. En los sistemas centrados en el proceso (process-centric) los dato son extraídos una sola vez y almacenados en un único lugar.


© Hermes Romero


Data Marts

...arquitectura en buso Un analista que quiera obtener datos accederá de esta

manera al data mart relevante. o Un repositorio de metadatos provee la información acerca

de los diferentes data marts (directorio de data mart)


© Hermes Romero


Data Marts

BBDDSistema

Operacional

DatosHistoricos

Otros datos MetadatosData Marts

RepositorioCentralizado de

DatosODS

(Operational DataStore)

DataMart

DataMart

DataMart

Usuarios Finales

Usuarios Finales

Usuarios Finales


© Hermes Romero


DWH y Business Intelligence

El experto en sistemas de “Business Intelligence” Drury Jenkins define la relación de soporte directo entre los sistemas business intelligence y los data warehouse haciendo un especial énfasis en el modelado de los datos y el análisis de los mismos.


© Hermes Romero


DWH y BI

o Business Intelligence (BI) es la habilidad de tomar mejores decisiones de manera más rápida.

o Un entorno de BI enfocado al cliente provee de la infraestructura necesaria para proveer la información necesaria para maximizar la base de clientes.

o Esta infraestructura combina datos, canales y técnicas analíticas para mejorar las satisfacción del cliente y el beneficio a través de mayores puntos de contacto.

o Para los especialistas en Marketing esto es la habilidad de contactar al cliente correcto en el momento correcto, en el lugar correcto y con el producto correcto.


© Hermes Romero


DWH y BI

o Los canales de contacto incluyen los tradicionales así como los basados en intercambio electrónico (email, web).

o Las técnicas analíticas incluyen análisis de perfiles, modelos predictivos, análisis de series de tiempo, y otras técnicas.


© Hermes Romero


DWH y BI

o El aspecto clave de proveer de la información necesaria es la creación de una vista global para cada cliente individual y sus necesidades.

o La integración de los datos de los clientes debe proveer de una vista única y uniforme de los clientes a lo largo de la organización.

o El objetivo último es alcanzar una foto completa de la interacción de un cliente con la organización entera, sólo se puede lograr mediante la obtención y almacenamiento de los datos apropiados.

o Además de los datos suplidos de demografía y otros datos externos, son necesarios numerosos datos internos de la organización.


© Hermes Romero


DWH y BI

o Demasiado habitualmente, los datos obtenibles están fragmentados y repartidos sobre muchos lugares y sistemas, escondidos en numerosas bases de datos de transacciones, o herramientas de productividad personal como hojas de calculo o “micro-bases de datos”.

o Esta dispersión de los datos, ha sido debido en gran manera por el crecimiento de los sistemas de aplicaciones cliente/servidor en la pasada década ....


© Hermes Romero


DWH y BI


© Hermes Romero


CRM

Que persigue el CRM...o Ante todo conocer al clienteo Cual es el valor del cliente para la compañíao Cuales son los clientes más importantes para la compañíao Cuales son los prospectos potencialeso Cuales son los clientes / productos más rentables


© Hermes Romero


CRM

...Que persigue el CRM...o Cual es el resultado de mis campañas publicitarias

• Nº de impactos• Nº de clientes nuevos• Incremento de ventas• CrossSelling

o Optimizar la interacción con el clienteo Trato personalizadoo Ofertas personalizadaso Etc...


© Hermes Romero


CRM

Ámbito tecnológico del CRMo El término CRM es confuso desde el punto de vista técnico

• Se produce un paralelismo entre CRM y herramientas CRM

o El CRM es una filosofía/estrategia de compañía que se lleva a cabo por medio de herramientas especializadas en los distintos ámbitos del tratamiento de la información referida al cliente.

o Hoy por Hoy todo es CRM...


© Hermes Romero


CRM

BBDDRelaciones

Con clientes

BBDDTransacciones

NegocioERP

Herramientas CRM

Contact-Center

ETL

Data Warehouse

BI

Análisis

Data mining

Reporting


© Hermes Romero


Granularidad

La granularidad es el concepto mas importante en el diseño de un DWH. Por que es directamente proporcional al volumen de datos que almacenará el DWH.

La granularidad se refiere al nivel de detalle o resumen de los datos contenidos en el DWH.

A mayor detalle mayor nivel de granularidad. A menor detalle menor nivel de granularidad.


© Hermes Romero


Granularidad

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

Evidentemente a mayor nivel de granularidad mayor será el volumen de información , mientras que al contrario, a menor granularidad menor volumen de datos.


© Hermes Romero


Granularidad

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

A través del nivel de granularidad se puede predecir el crecimiento en número de registros del DWH, así como los requerimientos de espacio para el mismo.


© Hermes Romero


Granularidad

La granularidad también afectará como es evidente al tiempo de respuesta de las consultas al DWH. A mayor nivel de granularidad menor rendimiento y mayor tiempo de respuesta. A menor nivel de granularidad del sistema, menores recursos son utilizados(procesador, memoria,almacenamiento,etc.).


© Hermes Romero


Los beneficios de la granularidad

El nivel de granularidad de un DWH es la clave de que esos datos puedan ser usados por diferentes tipos de usuarios en diferentes ocasiones y de diferente manera a lo largo de la compañía.


© Hermes Romero



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


© Hermes Romero



Ventas por mes

Ventas por mes

Ventas por área geografica(52)

Ventas por mes

Ventas por semana


Ventas por vendedor(52)

Ventas por mes

Ventas por semana



Ventas por producto(20)

Ventas por mes

Ventas por semana



Ventas por producto(20)

Ventas por nivel derentabilidad

(5)

Mayor Granularidad

Marketing

Ventas

Operaciones

Financiero

1 registro al mes20 bytes/mes

52 registros al mes1040 bytes/mes





© Hermes Romero


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 obtención de datos podrán ser acomodados con el diseño actual del DWH. Los cambios son inevitables, por esto nuestro DWH debe estar preparado para los distintos requerimientos de datos que sobrellevan los cambios del entorno del negocio.

Otro de los beneficios de la granularidad es que a mayor granularidad mayor contenido histórico de actividades y eventos de la compañía.


© Hermes Romero



o A través del ejemplo anterior veamos el siguiente supuesto:• ¿Cuantas unidades ha vendido Paco del producto limpia-hogar

Malvarossa la semana del 3 al 10 de Diciembre del año pasado.?

o En el nivel 1 de granularidad nuestra pregunta no tendría respuesta.

o En el nivel 2 de granularidad tampocoo Ni en el nivel 3.o En el nivel 4 de granularidad nuestra respuesta si podría ser

contestada.o En el nivel 5 de granularidad también podría ser contestada.


© Hermes Romero



o La principal diferencia entre los distintos niveles de granularidad se centra en el volumen de recursos del que hace uso cada nivel. (a mayor nivel mayores recursos).


© Hermes Romero


Granularidad múltiple

Es posible en determinados sistemas DWH definir dos o más niveles diferentes de granularidad para dar solución de manera más eficiente a diferentes peticiones de datos.


© Hermes Romero



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


© Hermes Romero



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

Evidentemente la puesta en marcha de diferentes grados de granularidad afecta al espacio de almacenamiento.


© Hermes Romero



Gracias a su bajo coste (básicamente almacenamiento), eficiencia, facilidad de acceso y habilidad para responder cualquier consulta, la granularidad múltiple generalmente a dos niveles, es la mejor elección posible en arquitecturas donde el nivel de detalle del DWH es muy alto y el volumen de datos es también muy alto.

Un único nivel de granularidad muy detallada está solo indicada en casos en los que el volumen de datos es relativamente pequeño.


© Hermes Romero


Estimación de la Granularidad

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


© Hermes Romero


Estimación de la granularidad

o El primer paso para calcular el espacio que ocupará el DWH es la identificación de las tablas que serán construidas.

o 2º estimar el tamaño de un registro en cada una de las tablas. Evidentemente el tamaño exacto nunca se conocerá ya que una filas consumirán mas espacio y otras menos, por lo que nosotros tomaremos como cifra una estimación basada en la cantidad mínima de espacio y por otro lado la cantidad máxima de espacio necesario para una fila.


© Hermes Romero



o 3º estimar en el horizonte de un año el máximo y mínimo numero de registros que contendrá cada una de las tablas. Si la información contenida se refiere a clientes o ventas es necesario usar las estimaciones de ventas del negocio recogidas en el plan de negocio para conocer el crecimiento de las tablas asociadas a las ventas. Si no existe un plan de negocio, será necesario utilizar otras variables predictivas como puede ser la situación economica, la cuota de mercado y el crecimiento en cuota de mercado, las previsiones de la comptencia, etc...

o 4ª una vez que se han hecho las previsiones es necesario repetir el proceso pero esta vez con un horizonte de 5 años.


© Hermes Romero



o 5º Establecer el número y tamaño de los índices necesarios para las distintas tablas del DWH, es conveniente crear índices en cada una de las variables condicionantes que formarán parte de las consultas (campos que estarán en las cláusulas WHERE de las sentencias SQL).

o 6º Realizar la operación• (Máximo número de filas posible en un año X tamaño máximo

pro registro) + espacio de índices• (Mínimo número de filas posible en un año X tamaño mínimo por

registro) + espacio de índices


© Hermes Romero



o Repetir esta operación por cada una de las tablas del DWHo Por lo general las estimaciones siempre se quedan pequeñas

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


© Hermes Romero



Una vez obtenidos los resultados de las predicciones es necesario aplicar la siguiente tabla para revisar si el nivel de granularidad es correcto:

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

100.000.000 1.000.000.000 Existen datos no usados por lo que se debe de replantar niveles inferiores de granularidad

10.000.000 100.000.000 Posiblemente existan datos no usados por lo que se recomienda replantearse el nivel de granularidad en el diseño del DWH1.000.000 10.000.000 Nivel de granularidad Aceptable

100.000 1.000.000 Nivel de granularidad Adecuado


© Hermes Romero



Un importante componente de los sistemas DWH es el concepto de “Overflow storage” almacenamiento desbordadoo El almacenamiento desbordado se produce cuando son

almacenados datos que no son usados de manera frecuente. o Relación directa con la granularidad del diseño.

• A mayor nivel de granularidad mayor es la probabilidad de que se produzca el desbordamiento.


© Hermes Romero



Con el transcurso del tiempo mayor desbordamiento.o Almacenar los datos poco consultados en dispositivos

externos CD-ROM - DVDo El uso del almacenamiento externo tiene implicaciones de

rendimiento.• Seleccionar cuidadosamente que datos .• Un reparto inteligente de los datos entre los dispositivos externos

e internos del sistema permitirá un mejor rendimiento a menor coste.


© Hermes Romero



o Por ello a la hora de diseñar el almacenamiento de los datos es necesario discernir entre que datos son necesarios con frecuencia y cuales no.

El uso de sistemas sobredimensionados, asumiendo su coste, nos permitiría aplicar el mayor nivel de granularidad deseado.


© Hermes Romero



La granularidad viene determinada a través de la funcionalidad del usuario, si el usuario ve los datos y el nivel de detalle es correcto para ellos entonces el nivel de granularidad es el apropiado.


© Hermes Romero



El nivel de granularidad debe tener en cuenta las necesidades futuras y la evolución del propio negocio.o Un nivel mayor de granularidad significará estar mas

preparado para el futuro.


© Hermes Romero


Caminos para establecer la granularidad

Realizando consultas sobre los orígenes de datos con los distintos niveles de granularidad posible.

Realizando las operaciones de agregación, que serán realizadas desde el origen de los datos en su camino hacia el data warehouse.

Realizando las operaciones estadísticas como medias, etc.. que serán realizadas desde el origen de datos en su camino hacia el data warehouse.


© Hermes Romero


Caminos para establecer la granularidad

Identificando los mayores y menores valores en el destino.

Identificando tan sólo los datos que son estrictamente necesarios en el destino.

Realizando pruebas de muestreo de datos utilizando conjuntos representativos de datos mediante condicionantes.


© Hermes Romero


Particionamiento

Podemos definir particionamiento de los datos a nivel lógico y a nivel físico, para una mejor compresión, mantenimiento y navegación a través del DWH

El particionamiento físico se define a través de la propia implementación física del diseño.

En el particionamiento de datos lógico el criterio común mas usado es el áreas temáticas (subject areas). o Podemos definir un área temática como una porción del

DWH que es clasificada desde una perspectiva consistente.


© Hermes Romero


Particionamiento

Para el DWH el particionamiento aporta:o Acceso más flexible a los datoso Una gestión de los datos mas sencilla y eficienteo Asegura la escalabilidad del DWHo Habilita la posibilidad de que los elementos del DWH sean

portables y compartidos con otros DWH o archivados en distintos dispositivos de almacenamiento externo.


© Hermes Romero


Particionamiento

Habitualmente se realizan particiones de grandes volúmenes de datos dividiéndolos en piezas mas pequeñas. Al hacer esto determinadas operaciones con los datos serán más fáciles de realizar:o Reestructuración de datoso Indexacióno Escaneado Secuencial (Full Scans)o Reorganizacióno Recuperacioneso Monitoreadoo Auditoría


© Hermes Romero


Particionamiento

Los criterios de particionamiento de los datos son variados pero quizás los mas representativos sean:o Periodo de tiempo (Fecha, mes , trimestre, semestre, año)o Por áreas geográficaso Por producto o línea de negocioo Por unidad organizativao ...o Por combinaciones de lo anterior


© Hermes Romero


Particionamiento

La elección de un criterio de particionamiento está basado e los requerimientos del propio negocio y las características físicas de la propia base de datos.

Cada herramienta de gestión de bases de datos (DBMS) tiene su propia manera de implementar el particionamiento a nivel físico, y pueden ser bastante diferentes entre ellas.


© Hermes Romero


Particionamiento

Se puede realizar un particionamiento controlado por la propia aplicación. o Añadirá la posibilidad de portar los datos entre distintos

DWH. El particionamiento depende de:

o El modelo de datos multidimensionalo La granularidad de los datoso Las capacidades del motor de base de datos


© Hermes Romero


Áreas temáticas (subject areas)

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

Área temática = área de interés para el negocio El DWH está siempre orientado a áreas especificas de la

organización como pueden ser:o Clienteso Productoso Beneficioso Ventaso ...


© Hermes Romero


Áreas temáticas

Esta orientación tiene su base en la forma en la que se plantean las consultas a un DWH, en un sistema operacional se formulan preguntas del tipo:o ¿Se puede pagar la factura del cliente XXXX?

Mientras que en el DWH las preguntas son más del tipo: o ¿qué productos se estan vendiendo mejor?o ¿cuáles son las oficinas que venden menos?o ¿cuáles son los vendedores menos rentables?...


© Hermes Romero


Áreas temáticas

Las áreas temáticas son la forma más común de particionamiento lógico en el DWH.

Para extraer una lista de los candidatos a áreas temáticas, debemos hacernos la pregunta:o ¿cuáles son los intereses del negocio?


© Hermes Romero


Áreas temáticas

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

(who) podrá aparecer:• Clientes, empleados, gerentes, proveedores, competidores, etc...

o Sobre la pregunta cuando (when)• Este año, trimestralmente, mensualmente, anualmente,

semanalmente, etc...o Donde (where)

• Provincias, ciudades, países, etc...


© Hermes Romero


Áreas temáticas

Una vez extraída la lista de candidatos a áreas temáticas, habrá que seleccionarlas, descomponerlas y redefinirlas mas claramente.

Como resultado podremos finalmente obtener una lista de áreas temáticas que representen claramente a nuestra organización.

El rol principal del área temática es la determinación de la unidad para un análisis efectivo, modelado e implementación del DWH, lo cual pude servir también como medida para discernir las áreas de interés de nuestro DWH.


© Hermes Romero


Exploración y data mining (minería de datos)

Los sistemas de Data mining o minería de datos se han hecho populares durante la pasada década.o para obtener mayor informacióno para obtener una mejor comprensión del negocio o para encontrar nuevos caminos e ideas para ganar potencial

en otros mercados.o Para controlar gastos y costes


© Hermes Romero


Exploración y Data mining

Es una practica extendida en nuestros días la integración de los sistemas de data mining en las aplicaciones transaccionales de negocio.o Por ejemplo call centers donde al recibirse una llamada el

sistema localiza el cliente del cual proviene y le adjudica un operador de acuerdo a su perfil como cliente.

o Sistemas que generan listados de receptores de publicidad directa con ofertas adecuadas a su perfil de cliente.

o Sistemas que alertan sobre el riesgo de perdida de un cliente o, de la modificación de sus hábitos de compra.

o Etc...


© Hermes Romero



Esta integración en los sistemas operacionales de la compañía requiere:o Integración de los sistemas de Data mining con las bases de

datos de produccióno Integración de los sistemas de Data Mining con los sistemas

DWH.


© Hermes Romero


Exploración y data mining

El principal caldo de cultivo de los sistemas de data mining son los sistemas DWH, ya que:o Permiten el análisis de los datos sobre granularidades

significativas para el sistemao No influyen en el rendimiento del sistema operacional.o Buscan patrones de comportamiento a lo largo de todos los

sistemas de la compañía y para ello es fundamental la integración y estandarización del DWH.


© Hermes Romero


Exploración y Data Mining

Preparación de los datos

Definición

Minería de datos

Interpretación de resultados

Implementación deresultados

DATA WAREHOUSE

DATA MINING

FUNCIONESDE SCORING

DERESULTADOS


© Hermes Romero



Consultas e Informes• Permite responder a determinadas preguntas , obteniendo la

información relevante desde el DWH, transformándola para el contexto apropiado y mostrándola de manera legible. En esta técnica las consultas realizadas están basadas en dos dimensiones.

• Los usuarios finales están especialmente interesados en:o Procesado de valores numéricos...totales de ventas, cantidades

vendidas. o Cálculo o investigación de medidas de calidad como satisfacción de

clientes, retrasos en procesos de negocio, etc.. o Predicciones de análisis de transacciones de negocio, análisis de

tendencias, etc...


© Hermes Romero



Definición de la consulta

Acceso y obtención del dato

Manipulación del datoy cálculo

Preparación del informe

Entrega del informe


© Hermes Romero



o Análisis multidimensional• El análisis multidimensional es una manera de extender las

capacidades de las consultas e informes que como vimos se basan en dos únicas dimensiones..

• Básicamente sustituye a la necesidad de realizar múltiples consultas, para ello los datos son estructurados de manera que se habilita un acceso rápido y fácil a las respuestas de las preguntas que típicamente se realizan.

• Por ejemplo:o ¿Cuantas unidades del producto X se han vendido en el mes de Enero,

por un determinado vendedor, in una provincia en particular?• Cada una de las partes de la pregunta es lo que se llama una

dimensión.

Enero Vendedor provincia


© Hermes Romero



• Mediante el mecanismo de precálculo integrado en las herramientas de procesamiento multidimensional, todas las respuestas a las distintas consultas (dimensiones) se obtienen en la misma orden.

o los datos no son recalculados sino que simplemente son accedidos y mostrados.

• El análisis multidimensional permite a los usuarios tener a su alcance un gran número de factores interdependientes asociados a un escenario del negocio.

• Los usuarios pueden acceder a la información explorando los datos en diferentes niveles de detalle.


© Hermes Romero



Totales de Ventas en el primer trimestre

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

Vendedor 1 Vendedor 2 Vendedor 1 Vendedor 2 Vendedor 1 Vendedor 2

Mad Mad Mad Mad Mad MadSev Sev Sev Sev Sev Sev

Dri

ll D

own

Rol

l Up


© Hermes Romero



Data Miningo Es una técnica relativamente nueva es muy diferente de las

técnicas de consultas e informes y del análisis multidimensional, su principal diferencia se basa en lo que se llama técnica de descubrimiento.

o La técnica de descubrimiento (discovery technique) no consiste en realizar una consulta especifica a los datos, en cambio esta técnica utiliza algoritmos que analizan los datos y devuelven los resultados descubiertos. A diferencia de las dos técnicas anteriores el data mining busca respuesta a consultas que no han sido previamente realizadas.


© Hermes Romero



o Los descubrimientos pueden tomar la forma de encontrar significado a determinadas relaciones o patrones de datos.

o Después de realizar un descubrimiento, este puede convertirse en una regla que sea utilizada para hacer predicciones basadas en esa regla.


© Hermes Romero



o Las técnicas de data mining se utilizan habitualmente para análisis estadístico de los datos y para descubrir el conocimiento (knowledge discovery)

• El análisis estadístico descubre patrones no habituales en los datos aplicando técnicas matemáticas y estadísticas para la explicación de los patrones.

• Una vez descubierto el patrón este se utilizará entonces para hacer previsiones y presupuestos.

• Algunas de las técnicas estadísticas incluyen:o análisis linear y no linealo análisis de regresióno Análisis multivarianzao Y análisis de series en tiempo.

• “knowledge discovery” extrae información no conocida de manera implícita de los datos.


© Hermes Romero



o El soporte de las técnicas de análisis de data mining está soportado por los propios datos del negocio . Existe en el DWH un alto nivel de complejidad en los datos almacenados y en sus interrelaciones que es difícil de descubrir sin el uso de técnicas de data mining.

o La minería de datos ofrece nuevos revelaciones acerca del negocio dando respuesta a preguntas que nunca se nos hubiese ocurrido preguntar.


© Hermes Romero



Gestionado porel

Analista

Asistido por elAnalista

Gestionado porlos datos

Consultase

informes

AnálisisMultidimensional

Data Mining


© Hermes Romero



o OLAP data mart (OnLine Analitical Processing) análisis multidimensional

• Están diseñados para soportar análisis multidimensional usando herramientas de software OLAP.

• El data mart en este caso se diseña utilizando las técnicas de esquema en estrella o tecnologías propietarias de cada herramienta basadas en el concepto de “hipercubo” (Hypercube).

• El esquema en estrella o sistema de gestión de base de datos multidimensional (multidimensional database management system MD DBMS) es el indicado en data marts de los que se conocen perfectamente los requerimientos, estos son estables y las consultas a los mismos son fácilmente predecibles con tiempos de respuesta razonables e informes mas o menos recurrentes.


© Hermes Romero



o Almacenes de exploración (Exploration warehouse)• Los almacenes de exploración están diseñados para dar soporte

real a la exploración o navegación puramente customizable por el usuario “ad-hoc”.

• Después de un descubrimiento a través de la exploración, este puede dar lugar a la creación de un nuevo data mart , para que otros usuario se beneficien del hallazgo a partir de es momento.

o Almacenes estadísticos (Data mining or statistical warehouses)

• Es un data mart especializado diseñado para dar soporte a los analistas e investigadores.

o Aplicaciones analíticas customizables (Customizable analytical applications)

• Permite la customización efectiva de aplicaciones genéricas.


© Hermes Romero


Diseño 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 compañía.

o Se asume también que los datos contenidos en el DWH no violan ninguna de las reglas de negocio establecidas para la compañía.

• El DWH en todo momento debe mostrar su adherencia a las reglas de negocio de la compañía.


© Hermes Romero


Diseño del DWH

o El DWH debe ser cargado con datos lo más rápida y eficientemente posible.

o El DWH debe configurarse y diseñarse para soportar múltiples tecnologías de BI, tanto presentes como futuras.

o El DWH debe acomodarse fácilmente a cambios tanto en las estructuras de datos como en los datos propiamente dichos.


© Hermes Romero


Diseño del DWH

El tipo de análisis que será realizado con el DWH o Data mart puede determinar el tipo de modelado de datos y los contenidos del mismo.

Como los análisis basados en consultas e informes y los análisis multidimensionales requieren metadatos explícitos y sumarizaciones especificas, es importante que el modelo de datos que de soporte al análisis contenga estos elementos.


© Hermes Romero


Diseño del DWH

Debemos tener en cuenta también que:o El análisis multidimensional también permite las operaciones

“drill down” y “roll up”.o La minería de datos habitualmente trabaja mejor con el

mayor nivel de detalle disponible (granularidad alta).


© Hermes Romero


Diseño del DWH

Desde principios de los años 90 uno de los gurus del DWH , Ralph Kimball, propuso nuevas técnicas de diseño basadas en las tradicionales bases de datos relacionales para lograr que los DWH fueran comprensibles y rápidos.

Estas técnicas de diseño que actualmente se conoce como modelado de datos dimensional (dimensional modeling) hacen que los sistemas DWH sean más rápidos a través de la limitación del número de enlaces (joins) entre las distintas tablas que forman parte del sistema.


© Hermes Romero


Diseño del DWH

Las características 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 añade trabajo extra a las operaciones de extracción transformación y carga (ETL), así como a los diseñadores que tendrán que preocuparse de que todos los elementos redundantes tengan el valor correcto en el momento correcto.

• A mayor redundancia mayor complejidad en la carga de los datos.

• Evidentemente cierto grado de redundancia a veces es inevitable e incluso aconsejable, a este tipo de redundancia la llamaremos redundancia controlada.


© Hermes Romero


Diseño del DWH

o Estable• Hemos repetido en varias ocasiones que nuestro DWH deba

acomodarse a los cambios con facilidad y estabilidad, esto se logra mediante la independencia de nuestro DWH a los cambios en procesos, aplicaciones y tecnología que por otra parte son los cambios que ocurren mas frecuentemente en una organización. Por otra parte nuestro DWH debe estar preparado para añadir nuevas entidades o atributos cuando se añaden nuevas capacidades de análisis BI o se incorporan nuevos data marts.

• Es importante por tanto que el diseñador de nuestro DWH use técnicas de modelado que permitan la incorporación de cambios en el modelo sin que sea necesario la redefinición de las entidades y atributos ya implementados.


© Hermes Romero


Diseño del DWH

o Consistente• La consistencia de los datos contenidos en el DWH es sin duda la

característica esencial. Los modelos de datos creados para el DWH deben reconciliar las discrepancias de concepto y físicas entre los distintos orígenes de datos, tanto a nivel estructural como a nivel de tipo de dato. Evidentemente este esfuerzo inicial es previo a cualquier tipo de carga de datos.


© Hermes Romero


Diseño del DWH

El modelo de datos resultante para el DWH, se trasladará a un diseño de base de datos que sea:o Fiable

• No contendrá contradicciones en la forma de nombrar entidades o atributos, en referencias de unos a tros, así como en la documentación

o Compartido• El DWH resultante de la implementación de este modelo de

datos podrá ser accedido por múltiples procesos y usuarios desde cualquier parte de la compañía.


© Hermes Romero


Diseño del DWH

o Flexible y adaptable al cambio• La base de datos resultante no condicionará en una dirección u

otra el entorno BI creado. Todas las oportunidades tecnológicas que se presenten permanecerán disponibles para la compañía.

• LA base de datos resultante podrá acomodar nuevas entidades y atributos, manteniendo al integridad de los elementos implementados.

o Correcto• El modelo de datos proveerá una representación de cómo y que

clase de información es usada en la compañía-


© Hermes Romero


Diseño del DWH

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


© Hermes Romero


Diseño del DWH

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


© Hermes Romero


Diseño del DWH

Lo mas recomendable en el diseño de data marts es que los esquemas de base de datos que los soportan deben estar diseñados de acuerdo al uso que se va ha hacer de ellos y del tipo de información que se solicitará al data mart.


© Hermes Romero


Diseño del DWH

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


© Hermes Romero


Diseño del DWH

Para determinar cual es el mejor diseño de base de datos posible para el data mart es aconsejable construir una matriz como la de la figura que compare el grado de volatilidad de los datos con respecto al tipo de diseño seleccionado así como con respecto a la frecuencia o tipo de consulta a realizar sobre el data mart.


© Hermes Romero


Diseño del DWH

Repetitivas Customizables Algoritmicas

volatilidad

latencia

Esquema en estrella

De-normalizadas

Normalizadas

Planas


© Hermes Romero


Diseño del DWH – Estructura de los datos

Para DWH podemos distinguir tres tipos básicos de datos:o Datos en tiempo real (real-time data)o Datos derivados (Derived data)o Datos reconciliados (Reconciled Data)

Se puede configurar el DWH basándose en estos tres tipos, con la consideración adecuada a las características particulares de cada implementación.


© Hermes Romero



Dependiendo de la naturaleza de los sistemas operacionales, el tipo de negocio, y el número de usuarios que pueden acceder al DWH, debemos combinar los tres tipos de datos para crear el mas adecuado modelo de datos para el DWH.


© Hermes Romero



Datos en tiempo real (Real-Time data)o Los datos en tiempo real representan el estado actual del

negocio. Por supuesto, estos son los datos que utilizan los sistemas operacionales.

o Los datos en tiempo real muestran la realidad cambiante del negocio transacción a transacción.

o Los datos en tiempo real muestran por otra parte el mayor nivel de detalle lo que se representa como el mayor nivel de granularidad.

o Habitualmente estos son accedidos en modo lectura-escritura por las transacciones operacionales.


© Hermes Romero



o Estos datos no tienen por que ser patrimonio exclusivo de los sistemas operaciones ya que es practica habitual la realización de transacciones distribuidas que reparten los datos entre sistemas operacionales y DWH en tiempo real.

o De igual manera los datos en tiempo real pueden ser almacenados también en Almacenes de datos operacionales (ODS Operational Data Stores) para su posterior análisis y carga en sistemas DWH sin afectar al rendimiento de los sistemas operacionales.

o El uso de datos en tiempo real en el DWH, implica que estos datos deben ser debidamente tratados para asegurar la adecuada calidad del dato, probablemente sumarizados y transformados a un formato mucho más fácilmente comprensible y manipulable por los analistas de negocio.


© Hermes Romero



o Evidentemente, también en el caso de que los datos en tiempo real provengan de distintos orígenes y sistemas, deberán ser reconciliados antes de ser cargados en el DWH.


© Hermes Romero



Datos Derivados (Derived Data)o Los datos derivados son datos que han sido creados

probablemente a raíz de operaciones como sumas, medias, o agregaciones de operaciones en tiempo real a través de un proceso intermedio de transformación previo a la carga.

o Los datos derivados pueden ser detallados o resumidos dependiendo de las especificaciones de requerimientos del DWH.

o Pueden representar una vista del negocio en un momento determinado del tiempo o pueden ser datos históricos referidos a un periodo de tiempo.


© Hermes Romero



o Los datos derivados son tradicionalmente usados para la toma de decisiones y el análisis del negocio.

o La sumarización de los datos en nuevos registros derivados requiere grandes volúmenes de datos a analizar y por consecuencia necesitará de grandes recursos para su procesamiento.

o La eficiencia de los procesos de creación de datos derivados en tiempo y manera es vital y una de las tareas mas importantes que los analistas han de resolver.


© Hermes Romero



Datos Reconciliados (Reconciled Data)o Los datos reconciliados son datos en tiempo real que han sido

tratados para ajustarse a los niveles de integración y calidad que se requieren para ser usados en análisis de datos.

o La consistencia es uno de los requerimiento de calidad inexcusables.o Durante el proceso de reconciliación de datos es posible crear y

mantener datos históricos , por lo que los datos reconciliados podrían ser un tipo especial de datos derivados.

o En algunas ocasiones los datos reconciliados son almacenados en estructuras físicas temporales requeridas para transformar de manera consistente los datos operacionales.


© Hermes Romero



El concepto de EDM – Enterprise Data Modelo Un EDM es una definición consistente de todos los

elementos de datos comunes al negocio. Desde una perspectiva mas abstracta a la mas concreta.

o El EDM incluye a su vez vínculos a los diseños de datos de cada una de las aplicaciones operacionales.

o A través del EDM se puede intuir una visión y comprensión de los requerimientos del negocio.


© Hermes Romero


Modelado de datos para el DWH

El modelador de datos debe responder a la premisa de diseñar las bases de datos del DWH para soportar de la mejor manera las necesidades de los usuarios del DWH.

En el DWH existen dos técnicas básicas de modelado de datos :o Modelado entidad-relación ERo Modelado dimensional


© Hermes Romero



En la mayoría de los modelos de datos de los sistemas operacionales actuales los modelos de datos se soportan sobre estructuras de modelado ER.


© Hermes Romero



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


© Hermes Romero



El modelo de datos es una abstracción organizada de los datos que representan las actividades, recursos y resultados de la organización.

Sin un modelo de datos la organización de la estructura y del contenido del DWH sería muy difícil.

El objetivo de los modelos de datos es conseguir la independencia lógico / físicao Como se muestran los datos es completamente

independiente de cómo se almacenarán a nivel físico


© Hermes Romero



Por lo que a nivel lógico se refiere, se referirá a los aspectos de identificación de la entidad o entidades, su descripción y su organización.

En el nivel físico se tratarán aspectos como la organización, acceso y almacenamiento de los datos a nivel físico


© Hermes Romero



Modelos entidad-relacióno Los modelos ER producen un modelo de datos de una

especifica área de interes usando para ello dos conceptos básicos: Entidades y las relaciones entre esas entidades. Los modelos ER contienen también Atributos, que son las propiedades inherentes a las entidades y/o relaciones.

o El modelo ER es una percepción del mundo compuesta por objetos llamados entidades y las relaciones entre ellos. Las entidades se diferencian unas de otras a través de sus atributos.


© Hermes Romero



o El modelado ER se representa mediante un diagrama que usa tres tipos de graficos para conceptualizar los datos: Entidad, relación y Atributo.

• Entidado Una entidad se define como una persona, lugar cosa o evento de

interes para el negocio o la organización.o Una entidad representa una clase de objeto, que puede ser observado

y clasificado por sus propiedades y caracteristicas.


© Hermes Romero



• Relacióno Una relación se representa mediante lineas que unen a dos entidades.

Una relación se designa de manera gramatical por medio de un verbo, como pertenece a, tiene. Tla relación entre dos entidades puede ser definida mediante su cardinalidad. La cardinalidad es el máximo número de instancias de una entidad que que se relacionan con una instancia de la otra entidad. Las cardinalidades posibles son:

• Uno a uno 1:1• Uno a muchos 1:M• Muchos a muchos M:M (no son válidas en un modelo normalizado)

• Atributoso Los atributos describen las caracteristicas o propiedades de las

entidades. Un nombre de atributo debe se único en una entidad.


© Hermes Romero


Modelado de datos para el DWH – Modelado dimensional

El modelado de datos dimensional usa tres conceptos básicos:o Medidas (measures)o Hechos (facts)o Dimensiones (dimensions)

En algunos casos el modelado dimensional es más sencillo, más expresivo y fácil de comprender que el modelado relacional.

Es relativamente nuevo por lo que no está firmemente definido, especialmente comparado con las técnicas de modelado relacional.


© Hermes Romero



El modelado dimensional es un conjunto de medidas (measures) que son descritas por aspectos comunes del negocio.

Es especialmente útil para sumarizar datos y presentarlos en vistas para ayudar al análisis de los datos.

El modelado dimensional se centra en los datos numéricos, como valores, cuentas (count), pesos, balances y ocurrencias.


© Hermes Romero



Hechos (facts)o Es una colección de items de datos relacionados.o Cada hecho generalmente representa un item del negocio,

una transacción del negocio, o un evento que puede ser utilizado para analizar el negocio o un proceso del negocio.

o En un Data warehouse los hechos (facts) se almacenan donde los datos numéricos son almacenados.


© Hermes Romero



Dimensiones (dimensions)o Es una colección de miembros o unidades del mismo tipo.o Las dimensiones determinan el contexto de fondo para los

hechos.o Las dimensiones son los parámetros sobre los que queremos

realizar el análisis OLAP (online analitical processing).


© Hermes Romero



o Si consideramos una base de datos de análisis de ventas, encontraremos entre otras las siguientes dimensiones.

• Tiempo• Localización / Provincia• Clientes• Vendedor

o Miembros de la dimensión (dimension members)• Una dimensión puede a su vez contener n miembros.• Por ejemplo, los meses : enero, febrero, marzo,...,trimestres,

cuatrimestres son miembros de la dimensión tiempo.


© Hermes Romero



o Jerarquías de la dimensión (dimension hierarchies)• Las dimensiones pueden a su vez ser divididas en diferentes

jerarquías, cada jerarquía puede tener a su vez distintos niveles jerárquicos.


© Hermes Romero



Jerarquias de la dimensión

año

semestre semestre

trimestre trimestre

mes

día

...

...

...

Jerarquía 1 Jerarquía 2Semana

día...


© Hermes Romero



Jerarquias de la dimensióno Drill down


© Hermes Romero



Medidas (measures)o Es un atributo numérico de un hecho.o Por ejemplo las medidas de ventas serían

• El importe de las ventas• El volumen de ventas• Las unidades vendidas• El importe de la materia prima• ...

o Una medida se determina por la combinación de miembros de las dimensiones y está situada en los hechos (facts)


© Hermes Romero



dimesion1


© Hermes Romero



Tablas de hechos (facts)o Es la tabla central en el modelo de datos dimensional, en

esta table es donde se almacenan los valores numéricos de las medidas. Se utiliza el termino hecho (fact) para representar una medida del negocio.

o Una fila de la tabla de hechos representa una medida (measure). Por lo que una medida es una fila en la tabla de hechos. Todas las medidas de una tabla de hechos deben tener la misma granularidad.

o Los hechos mas habituales son los numéricos y aditivos, como euros o total de ventas.


© Hermes Romero



o La capacidad de adición es crucial ya que raramente los valores de las tablas de hechos son recuperados de fila en fila, lo usual es recuperarlos mediante la suma de una o mas de sus columnas o mediante la cuenta del número de filas, medias, etc...

o Es importante tener en cuenta que no es aconsejable la introducción de filas en las tablas de hechos que no representen nada como por ejemplo (12/12/2003 , 0) en representación de que el día 12/12/2003 no se realizó ninguna venta, en estos casos es mejor no incluir el registro, de esta manera el espacio ocupado por la tabla de hechos será util al 100%


© Hermes Romero



o Las tablas de hechos representan el 90% o más del espacio ocupado en un DWH, generalmente las tablas de hechos tienen la tendencia de ser voluminosas en cuanto a número de registros pero también a tener pocas columnas (atributos).

o Las tablas de hechos se pueden además clasificar en tres grupos atendiendo a su nivel de granularidad.

• Transacciones• Fotos-fijas periódicas (periodic snapshots)• Fotos-fijas acumulativas (accumulating snapshots)


© Hermes Romero



...Tablas de hechos (facts)o Las tablas de hechos de tipo transaccional son las más

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 también podemos afirmar que cada tabla en un modelo dimensional que posee una clave compuesta es una tabla de hechos.


© Hermes Romero



o Las relaciones entre las tablas de hechos y las tablas de dimensiones son siempre relaciones de tipo muchos a muchos M:M. Por lo que las tablas que presenten este comportamiento relacional en un modelo dimensional serán tablas de hechos mientras que el resto serán tablas de dimensiones.

o La composición de la clave primaria en la tabla de hechos no tiene por que relaizarse con todas las claves externas ya que probablemente la agrupación de unas pocas de ellas garantice la unicidad del registro.


© Hermes Romero



o En la mayoría de los casos no tiene ninguna utilidad la introducción de una clave primaria no compuesta para identificar unívocamente a cada registro de la tabla de hechos. Al contrario de nuevo podemos ocupar un espacio extra para añadir esto cuando realmente no es necesario, con las consecuencias implícitas de almacenamiento y rendimiento. Aunque si la naturaleza del negocio requiere la inclusión de varias filas con los mismos valores entonces si debemos plantearnos la creación de una clave primaria, siempre que sea necesario hacer una distinción clara entre las filas con el mismo contenido.


© Hermes Romero



Tablas de hechos (facts)o Mucho del éxito de nuestro DWH dependerá de cómo se

implementen las tablas de hechos.

ventas diarias

clave de fecha FKclave de tienda FKclave de producto FK

cantidadvalor


© Hermes Romero



Tablas de hechos (facts)o Hemos de tener en cuenta que las tablas de hechos pueden

encontrarse en tres estados:• Están siendo Consultadas• Están siendo cargadas• Están siendo gestionadas

o No es posible el mantenimiento de índices en un corto espacio de tiempo

o Las tablas de hechos también pueden estar implementadas de diferentes maneras:

• Sin particionamiento – Sin índices• Particionadas – Sin índices• Sin particionamiento – Con índices


© Hermes Romero



Tablas de dimensiones (dimensions)o Las tablas de dimensiones contienen los descriptores

textuales del negocio.o En un modelo bien diseñado las tablas de dimensiones

tienen por lo general muchos atributos que describen la fila en la tabla de dimensión.

o Las tablas de dimensiones deben contener tantos atributos como sean necesarios para hacer su contenido lo más comprensible posible. No es extraño encontrar tablas de dimensiones que contengan entre 50 y 100 atributos.


© Hermes Romero



o Por otra parte las tablas de dimensiones por lo general son tablas que presentan pocos registros en comparación con las tablas de hechos, por lo general no mas de 1 millón de registros.

o Cada dimensión se define a través de una clave primaria no compuesta (única) PK que será utilizada para guardar la integridad referencial con cualquier tabla de hechos con la que esté relacionada.

o Cada uno de los atributos de las tablas de dimensiones serán utilizados para realizar las consultas como condicionantes, agrupaciones, etc...


© Hermes Romero



o En una consulta los atributos de una dimensión son identificables por que siempre van precedidos de la palabra “por” (by). Quiero saber las ventas por region, Quiero saber las ventas por mes, Quiero saber las ventas por producto, ...por vendedor, etc.

o Los atributos de las tablas de dimensiones juegan un papel vital en los modelos de datos dimensionales ya que ellos son el origen de las condicionantes en las consultas y de los resultados de las mismas. Los atributos de las tablas de dimensiones son la clave para hacer el DWH usable y comprensible.


© Hermes Romero



o Un DWH será tan bueno como atributos de las tablas de dimensiones posea. El poder del DWH es directamente proporcional a la calidad y profundidad de los atributos de sus dimensiones.

o Cuanto mas tiempo pasemos definiendo atributos con sentido para el negocio mejor será nuestro DWH.

o Cuanto mas tiempo pasemos poblando nuestras tablas de dimensiones con valores para los distintos atributos mejor será nuestro DWH.


© Hermes Romero



...tablas de dimensiones (dimensions)


© Hermes Romero



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

abreviaciones. Esto nos ayudará en la implementación del DWH con respecto a los usuarios del mismo, ya que contribuye a su facilidad de uso y compresibilidad por parte de los usuarios. Los atributos típicos para una dimensión de producto por ejemplo incluirían una descripción corta de 10 a 15 caracteres, una descripción larga de 30 a 50 caracteres, nombre de la marca, categoría o familia de producto, tipo de empaquetado, tamaño , peso y otras características. Aunque se definan atributos numéricos dentro de las dimensiones, conservarán su carácter de dimensión siempre que se tomen como descripciones textuales, por ejemplo, el atributo código postal está representado por un número aunque su uso es textual no vamos a realizar operaciones con este valor, mas que para definir un área geográfica concreta.


© Hermes Romero



...tablas de dimensiones (dimensions)o Jerarquia de las dimensiones

• Las tablas de dimensiones frecuentemente representan estructuras jerarquicas entre distintas entidades, por ejemplo la dimensión producto, incluye un atributo marca que puede permitir a su vez la agrupación de los productos por marca, lo mismo ocurre con la familia de productos. Para cada fila en la dimension de producto se almacenará el nombre de la marca y el nombre de la familia a la que pertenece, aunque de esta forma estamos almacenando información redundante, pero esta operación se realiza para evitar nuevas relaciones (joins) en las consultas que se traducirian en decrementos del rendimiento del sistema.


© Hermes Romero



• Debemos resistir nuestro impulso de almacenar tan solo el código de la marca y crear una vista separada para todas las marcas. Esto es lo que se conoce como diseño de copo de nieve (snowflake). Por lo general las tablas de dimensiones presentan un alto grado de de-normalización.

• Si con la creación de diseños en copo de nieve pretendemos por ello ahorrar espacio de almacenamiento, hemos de tener en cuenta que las tablas de dimensiones, raramente representan mas del 10 % del total de almacenamiento del DWH, por lo que el ahorro no tendrá un impacto significativo, sin embargo si impactará en el rendimiento y, en la sencillez y comprensibilidad del modelo por parte de los usuarios.


© Hermes Romero



tabla de familiasclave de familia

nombre de la familia

tabla de marcasclave de marca

nombre de la marca

Tabla de productosclave de producto

descripcion del productoclave de marca (FK)modeloclave de familia (FK)tipo de empaquetadotamaño empaquetadopesoprecio del producto


© Hermes Romero



...tablas de dimensiones

o Las tablas de dimensiones son los puntos de entrada a las tablas de hechos. La definición de unos robustos atributos, nos traerá capacidades robustas para realizar operaciones de tipo “slice” y “dice”. Las dimensiones implementan el interfaz de usuario al DHW.


© Hermes Romero



Diseño en estrella (star join schema)

dimensión

dimensión

dimensión

tabla de hechos

tabla de fechasclave de fecha

fechamesdiaaño

tabla de tiendasclave de tienda

provincia

ventas diarias

clave de fecha (FK)clave de tienda (FK)clave de producto (FK)cantidadvalor


descripcion del productomodelomarcafamiliatipo de empaquetadotamaño empaquetadopesoprecio del producto


© Hermes Romero



Diseño en estrella (star join schema)o Al relacionar las tablas de hechos con las tablas de

dimensiones nos da la impresión de que se dibuja una especie de estrella, donde el punto central es la tabla de hechos donde convergen todas las tablas de dimensiones.

o Debido a esto este diseño es conocido como diseño en estrella o “star”, aunque este termino se acuño en los primeros días de los diseños relacionales.


© Hermes Romero



o Una de las primeras cosas que nos llama la atención acerca del diseño es su simplicidad y simetría. Evidentemente los usuarios se beneficiarán de esa simplicidad ya que los datos serán mas comprensibles, fáciles de usar y explorar.

o La simplicidad del modelo también lleva aparejado beneficios en el rendimiento ya que los optimizadores de base de datos procesarán estos esquemas de manera mas eficiente cuando existen pocas relaciones entre las entidades (joins).


© Hermes Romero



Diseño en estrellao En el gráfico 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 numéricos.

dimensión

dimensión

dimensión

tabla de hechos

tabla de fechasclave de fecha

fechamesdiaaño


provincia

ventas diarias

clave de fecha (FK)clave de tienda (FK)clave de producto (FK)cantidadvalor



Mes Marca Provincia Importe de Ventas Cantidad VendidaEnero Orbea Madrid 4.598,00 € 3Enero Marin Madrid 2.345,00 € 2Enero Marin Sevilla 12.678,00 € 6Febrero Specialized Madrid 2.346,00 € 1Febrero Marin Madrid 1.235,00 € 1Febrero Orbea Madrid 2.345,00 € 4

suma suma


© Hermes Romero



Diseño en “copo de nieve” (snowflake)o El modelo copo de nieve es el resultado de la

descomposición de una o más de las dimensiones, que a veces poseen jerarquías.

o La estructura de este modelo muestra la estructura jerárquica 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 devaluación del rendimiento del sistema ya que las operaciones de relación entre las distintas entidades son mayores y en consecuencia el motor de base de datos se resiente.


© Hermes Romero




© Hermes Romero



o En definitiva no son aconsejables por:• Añadir niveles adicionales de relaciones “joins”• Complica la construcción del usuario final (mas tablas para

elegir, a no ser que se creen vistas para facilitar esta tarea.)• Producen trabajo extra a los optimizadores de base de datos y

esto da como resultado la creación de planes de ejecución peores.

• Tan solo se reduce algo de espacio de almacenamiento en la Base de datos , a un coste de tiempos de consulta mucho mayores.


© Hermes Romero



A evitar...o Centrarse demasiado en la tecnología y en los datos en

lugar de enfocarse en las necesidades del negocio y los objetivos del proyecto.

o Tomar el proyecto como un super-proyecto de varios años en lugar de hacer pequeños pero mas efectivos y manejables esfuerzos de desarrollo.

o Gastar esfuerzos en la construcción de una estructura de datos normalizada antes de pensar en la construcción de un área de presentación basada en modelos dimensionales.


© Hermes Romero



o Prestar mas atención 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.

o Hacer las áreas de presentación para los usuarios demasiado complejas con estructuras de datos complejas.

o Cargar sólo datos sumarizados en las áreas de presentación dimensionales de los datos.

o Suponer que el negocio, los requerimientos y análisis de información son estáticos, así como la tecnología que lo soporta.

o Negarse a reconocer que el éxito de un DWH se centra en la aceptación por parte de los usuarios.


© Hermes Romero



Pasos básicos para la transformación de modelos OLTP (operacionales) en diseños en estrella.o De-normalizar las relaciones de tipo “lookup”o De-normalizar las relaciones maestro-detalleo Crear y poblar una dimensión de tiempoo Crear jerarquías de datos en las dimensioneso Considerar el uso de claves subrogadas sin sentido *


© Hermes Romero



¿cuál es la mejor herramienta para modelar datos para el DWH?

o Tu cerebro


© Hermes Romero



De-normalizacióno 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

productoscodigo producto

nombre productofecha iniciofecha fincodigo familianombre familiacodigo subfamilianombre subfamiliacodigo marcanombre marcaanchoaltopesocantidad por paquete


© Hermes Romero



• Evidentemente al incumplir la 3ª norma formal nuestro diseño se encontrará en 2ª norma formal (las normas son acumulativas). Por tanto si se viola la tercera norma formal nos impide estar en normas formales superiores.

• Si normalizaramos la tabla para cumplir la tercera norma formal entonces estaríamos creando un esquema en “copo de nieve” (snowflake), y como hemos visto anteriormente esto es altamente desaconsejable.

• Si para evitar la de-normalización optamos por realizar vistas, estaremos en el mismo problema ya que las vistas no son más que consultas preescritas, que cuando se hace referencia a ellas se ejecutan, con el consiguiente coste de rendimiento.


© Hermes Romero



Consultas a esquemas en estrellao Por lo general una consulta a un esquema en estrella

contendrá:• Funciones de agrupación (GROUP BY)• Contendrá una relación (JOIN) de una tabla de hechos con una o

mas tablas de dimensiones.• Tendrá muchos condicionantes (WHERE) usando las columnas de

las tablas de dimensiones.• Hará un escaneado de muchas filas para devolver un número

relativamente bajo de filas.


© Hermes Romero



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.provinciaMes Marca Provincia Importe de Ventas Cantidad VendidaEnero Orbea Madrid 4.598,00 € 3Enero Marin Madrid 2.345,00 € 2Enero Marin Sevilla 12.678,00 € 6Febrero Specialized Madrid 2.346,00 € 1Febrero Marin Madrid 1.235,00 € 1Febrero Orbea Madrid 2.345,00 € 4


© Hermes Romero



Modelado de fechaso El concepto de tiempo es sin duda el elemento mas

generalmente utilizado en la construcción de informes para la empresa. No obstante es una de las materias más complejas a la hora de diseñar el DWH, ya que la manera en la que se implemente este dato podrá afectar de manera significativa al rendimiento.


© Hermes Romero



o En primer lugar debemos de tener en cuenta que la fecha es de crucial importancia para los usuarios de sistemas de reporting, ya que les permiten definir claramente el comportamiento a través del tiempo del negocio, o de un área del mismo. Es normal por tanto que se soliciten informes de datos agrupados por fechas de distinta forma debido a la flexibilidad que confiere el dato de fecha, por ejemplo un informe de ventas puede ser agrupado por:

• Ventas diarias• Ventas semanales• Ventas en días laborables


© Hermes Romero



• Ventas en fines de semana• Ventas en días festivos• Ventas Mensuales• Ventas Trimestrales• Ventas Cuatrimestrales• Ventas Semestrales• Ventas Anuales


© Hermes Romero



Modelado de fechaso Tal como se ha apuntado anteriormente el diseño de nuestro

DWH con respecto a la fecha de las tablas de hechos puede condicionar en gran medida el rendimiento del sistema. En el ejemplo que se muestra vemos como una tabla de hechos (ventas diarias) posee un campo de fecha (Fecha de Venta) y existen dos dimensiones (Tabla de productos y tabla de tiendas).


© Hermes Romero





ventas diarias

clave de tienda (FK)clave de producto (FK)fecha de ventacantidadvalor


provinciatabla de hechos

dimensión

dimensión


© Hermes Romero



Modelado de fechaso En caso de que quisiéramos obtener la suma de ventas por mes en cada una

de las tiendas, por cada uno de los productos, tendríamos que realizar una consulta como la siguiente (*):

(*) La consulta incluye funciones específicas del gestor de Bases de Datos ORACLE

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


© Hermes Romero



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


© Hermes Romero



o El resultado de la consulta anterior, tan sólo nos agruparía las ventas por meses (enero, Febrero, Marzo, etc...) sin tener en cuenta a que año pertenece cada venta por lo que para hacer aún más correcta la búsqueda escribiríamos:


© Hermes Romero



Modelado de Fechaso Como es evidente al tener que realizar el cálculo del mes y

del año sobre la marcha en la ejecución de la consulta, el rendimiento de la consulta será muy pobre, mas teniendo en cuenta el número de registros sobre nuestra tabla de hechos (ventas diarias).

o El uso de funciones especificas para realizar cálculos sobre datos de fecha además de suponer un serio decremento del rendimiento del DWH, condiciona el sistema a el uso del motor de base de datos para el cual ha sido concebido ya que cada motor de bases de datos posee sus propias funciones para realizar cálculos de fecha con diferente sintaxis.


© Hermes Romero



o Para solucionar esto es usual en los sistemas de DWH la creación de una dimensión de tiempo separada, esto se traduce en la creación de una entidad que desglosará cada una de las fechas en:

• Fecha (fecha/alfanumérico)o 12/12/2003

• Día de mes (numérico) o 1..31

• DIA de la semana (alfanumérico) o Lunes, Martes, Miércoles, Jueves, Viernes, Sábado, Domingo.

• Número de mes (numérico)o 1..12

• Nombre Mes (alfanumérico)o Enero, Febrero, Marzo, Abril, Mayo, Junio, Julio, Agosto,

Septiembre,Octubre,Noviembre,Diciembre


© Hermes Romero



• Número de Trimestre (numérico)o 1..4

• Nombre de trimestre (alfanumérico)o Primer Trimestre, Segundo Trimestre, Tercer Trimestre, Cuarto

Trimestre• Número de Cuatrimestre (numérico)

o 1..3• Nombre de Cuatrimestre (alfanumérico)

o Primer Cuatrimestre, Segundo Cuatrimestre, Tercer Cuatrimestre• Número de Semestre (numérico)

o 1,2• Nombre de Semestre (alfanumérico)

o Primer Semestre, Segundo Semestre


© Hermes Romero



• Año (Numérico)o ...1990,1991,1992,1993,1994...

• Festivo (booleano/alfanumérico/numérico)o Si,No


© Hermes Romero



Modelado de Fechas

dimensión

tiempoclave de fecha

diadia de la semanamesnombre mestrimestrenombre trimestrecuatrimestrenombre cuatrimestresemestrenombre semestreanyofestivo



ventas diarias

clave de fecha (FK)clave de tienda (FK)clave de producto (FK)fecha de ventacantidadvalor


provincia

tabla de hechos

dimensión

dimensión


© Hermes Romero



Modelado de fechaso En muchos casos se da la circunstancia de que

determinados periodos de tiempo no coinciden plenamente con el calendario gregoriano, tal es el caso de compañías en las que el año natural (Enero->Diciembre) no coincide con el año fiscal, o con lo que se denomina ejercicio. También algunas empresas tienen el ejercicio dividido en distintas áreas que no tienen por que coincidir con las definidas en el calendario del año natural, esto es por ejemplo cuando una empresa tiene dividido el ejercicio en periodos trimestrales (quarters) que no coinciden con los del año natural o dividen el ejercicio con otras consideraciones (primavera, verano, otoño, invierno), etc..


© Hermes Romero



o Para dar solución a estos casos utilizaremos también la misma dimensión de tiempo y añadiremos los campos específicos para detallar esta información particular sobre la fecha en la que ha ocurrido un hecho (fact).

• Periodoo 1..n

• Nombre Periodoo ....

• Ejercicio Fiscalo ....

• Ejercicio comercialo ....


© Hermes Romero



• Temporadao Alta, bajao Invierno, verano, otoño, primaverao ....

• Etc..


© Hermes Romero



Modelado de fechas

Enero

Febrero

Marzo

Abril

Mayo

Junio

Julio

Agosto

Septiembre

Octubre

Noviembre

Diciembre

Enero

Febrero

Marzo

Diciembre

Noviembre

Octubre

Septiembre

Enero

Febrero

Marzo

Abril

Mayo

Junio

Julio

Agosto

Septiembre

Octubre

Noviembre

Diciembre

Enero

Febrero

Marzo

Diciembre

Noviembre

Octubre

Septiembre

Natural / GregorianoEspecifico de la

empresa

2002

2003

2004

2003

2004

3

4

1

2

3

4

1

1

2

3

4

1

2

3


© Hermes Romero



Modelado de Fechas

Enero

Febrero

Marzo

Abril

Mayo

Junio

Julio

Agosto

Septiembre

Octubre

Noviembre

Diciembre

Enero

Febrero

Marzo

Diciembre

Noviembre

Octubre

Septiembre

Enero

Febrero

Marzo

Abril

Mayo

Junio

Julio

Agosto

Septiembre

Octubre

Noviembre

Diciembre

Enero

Febrero

Marzo

Diciembre

Noviembre

Octubre

Septiembre

Natural / GregorianoEspecifico de unaempresa de moda

2002

2003

2004

2003

2004

3

4

1

2

3

4

1

1

2

3

4

1

2

3

Otoño

Invierno

Primavera

Verano

Otoño

Invierno

Primavera


© Hermes Romero



dimensióntiempoclave de fecha

diadia de la semanamesnombre mestrimestrenombre trimestrecuatrimestrenombre cuatrimestresemestrenombre semestreanyofestivoquarternombre quartertemporadaejercicio



ventas diarias

clave de fecha (FK)clave de tienda (FK)clave de producto (FK)fecha de ventacantidadvalor


provincia

tabla de hechos

dimensión

dimensión


© Hermes Romero



Tratamiento de Valores Nuloso La mayoría de los motores de bases de datos usan el valor

nulo (Null) para representar la ausencia de datos. Evidentemente la base de datos no trata de igual manera a los nulos que a los blancos (‘’) o ceros (0).

o Los valores nulos en un data warehouse pueden ser encontrados en tres areas:

o Valores nulos en una clave extranjera (Foreign Key) (FK) de la tabla de hechos (Fact).

o Valores nulos en los hechos (Facts)o Valores nulos en los atributos de las tablas de dimensiones.


© Hermes Romero



o Valores nulos en una FK (relación) de la tabla de hechos

• La aparición de nulos en esta situación puede ser debida a diferentes razones:

• El valor de la FK no se conocía en el momento de la extracción.• No se desea que el valor correspondiente se relacione con la

dimensión a la que representa la FK.• También puede ser debido a un error en la etapa de extracción y

carga.


© Hermes Romero



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 aún no han ocurrido, por ejemplo en una tabla de hechos donde se recogen los pedidos, en el día de la actualización probablemente existan pedidos que no hayan sido entregados aún, de ahí que determinados valores de los atributos de la tabla de hechos, se encuentren en estado nulo (fecha de entrega), en la siguiente actualización de la tabla de hechos, esta situación será solventada para aquellos pedidos, que hayan sido entregados en el intervalo de tiempo entre actualización y actualización, pero también se generarán nuevos registros incompletos. En este caso un eventual informe sobre la tabla de pedidos no reflejará aquellos pedidos que estén pendientes de entrega ya que la join


© Hermes Romero



(WHERE pedidos.fecha_de_entrega = fechas.Fecha)condicionará el resultado y hará que estos pedidos no aparezcan. Para solucionar este problema es recomendable el uso de un valor especial

tanto en la tabla de hechos como en la tabla de dimensión para identificar la ausencia de datos por ejemplo en el caso anterior se podría identificar con una fecha inoperativa como 1/1/9999 reflejando esta en la tabla de dimensión con una descripción como: ‘no asignada’, los efectos de esta solución darán satisfacción a los usuarios de los informes ya que en los informes no faltará información y todos los pedidos no entregados podrán ser agrupados en la fecha ‘no asignada’.

Para el segundo y tercero de los casos se debe aplicar una solución similar a la anterior.


© Hermes Romero



o Valores nulos en los hechos (facts)• Este hecho puede tener dos significados, o bien el valor

realmente no existe, o bien se ha producido un error a la hora de generar el registro. Tanto en uno como en otro, dejar el nulo es lo apropiado ya que los motores actuales de base de datos sustituyen muy bien los nulos por valor = 0, así que a la hora de realizar funciones agregadas como SUM, MAX, MIN, COUNT, y AVG no habrá ningún problema, si por el contrario realizamos la sustitución del valor nulo por el valor cero estaremos degradando la información ya que no podremos distinguir entre aquellos que el valor es igual a 0 por que eran nulos o por que tras el cálculo realmente son igual a 0.


© Hermes Romero



o Valores nulos en los atributos de las tablas de dimensiones

• La aparición de valores nulos en las tablas de dimensiones puede ser debido a las mismas causas que en el caso de los nulos en las relaciones (FK) de las tablas de hechos. En cualquier caso también es aplicable la misma recomendación, si dejamos los valores nulos en las tablas de dimensiones puede ser confuso para el usuario ya que aparecerán como dimensiones “blancas” (sin contenido) en los informes y desplegables de las herramientas de explotación de los datos. Por tanto, al igual que en el caso anterior la sustitución del valor nulo por una cadena del tipo “desconocido”, “no aplicable”, etc.. es lo más recomendable.


© Hermes Romero



• Hay que tener en cuenta que las herramientas de explotación de los data warehouse, pueden dar tratamientos diferentes en cada caso a los valores nulos, independientemente de esto, es recomendable seguir las indicaciones anteriores para hacer de esta manera a nuestro diseño independiente de la herramienta o herramientas de explotación del data warehouse.


© Hermes Romero


Visualización del modelo dimensional Aplicaciones OLAP

El objetivo fundamental de las herramientas OLAP es: soportar las consultas “ad-hoc” de los usuarios que analizan el negocio. o Parecido a una hoja de cálculo pero:

• Trabajan con grandes volúmenes de datos.• Están optimizados para la manejar términos de negocio

(dimensiones geográficas, dimensiones de tiempo).• Están combinados con capacidades de generación de informes.• Trabajan con bases de datos dimensionales.


© Hermes Romero



El termino OLAP fue acuñado por E.F Codd en 1993 “On-Line Analytical Processing” (OLAP).o Para representar los datos corporativos en diferentes

perspectivas multidimensionaleso Realizando un análisis en línea (on-line) de los datos

• usando fórmulas matemáticas• técnicas estadísticas más sofisticadas • agregando y consolidando los datos de acuerdo a las diferentes

dimensiones. Las investigaciones alrededor de OLAP siempre han

estado dirigidas a mejorar el rendimiento de obtención y manipulación de la información, contenida en las bases de datos dimensionales.


© Hermes Romero



Son frecuentemente comparados con lo que se denominan Bases de datos estadísticas (statistical databases).o Una clase de bases de datos que permiten la definición,

manipulación, elaboración y almacenamiento de datos multidimensionales precalculados.

o la principal diferencia entre ambas estriba en que las bases de datos estadísticas calculan los datos sobre otras bases de datos, mientras que las bases de datos OLAP representan los datos directamente.


© Hermes Romero



OLAP incluye datos de definición de datos (metadatos). Realmente los cubos como tal no existen, los cubos se

utilizan para representar o visualizar un modelo dimensional.

Podemos representar un modelo dimensional con tres dimensiones con un cubo (cube) tal como el de la figura, en cualquier caso lo habitual es tener modelos dimensionales con más de tres dimensiones, en ese caso su representación se realiza con cubos que reciben el nombre de hipercubos (hypercube).


© Hermes Romero



En la figura podemos ver como se representan las cifras de volumen de ventas determinado por la combinación de tres dimensiones, tiempo, producto y provincia

240 267 120 789 356

1245 3789 2567 130 780

560 125 234 1235 370

150 245 245 245 340

3200 1345 2567 1204 6709

150

Bicicletas

Patines

Balones

Camisetas

Mochilas

Enero Febrero Marzo Abril Mayo

Granada

Las Palmas

Madrid

SegoviaVolumen de ventas en función

del tiempo, producto y provincia


© Hermes Romero



Operaciones básicas de OLAP• Existen cuatro tipos básicos de operaciones en OLAP para el análisis de

datos. • Las operaciones conocidas como “drill down” y “roll up” básicamente van

ha definir el nivel de granularidad con la que queremos analizar los datos,• las operaciones “slice” y “dice” nos permitirán navegar entre las

dimensiones.

o Drill down y Roll up• Las operaciones “drill down” y “roll up” son utilizadas para mover la vista

hacia y desde un mayor nivel de detalle a un menor nivel de detalle. • Hacia un mayor nivel de detalle realizamos un “drill down”.• Para un menor nivel de detalle realizamos un “roll up”. • La operación de Drill down también se conoce como agregación

dinámica.


© Hermes Romero




© Hermes Romero



o Slice y Dice• Las operaciones de Slice (trocear) y dice (dado) se corresponden

a las operaciones para la visualización de los datos a través del cubo.

• Slice y dice son las habilidades para acceder a un data warehouse a través de cualquiera de sus dimensiones por igual. Las operaciones de Slice y dice realizan el proceso de separar y combinar los datos de infinitas maneras.

• La operación de Slice realiza un “corte” en el cubo para que los usuarios puedan centrarse en un área determinada del cubo. También puede decirse que define un subcubo.


© Hermes Romero



• La operación dice, rota el cubo hasta una nueva perspectiva, para que los usuarios puedan ver los datos desde diferentes perspectivas en su análisis de los datos.

• Con estas operaciones el usuario que analiza la información, puede agruparla de una manera, analizarla, agruparla de otra y realizar otro análisis. Con las operaciones de slice y dice el usuario posee diferentes perspectivas para el análisis.


© Hermes Romero




© Hermes Romero



Implementación de OLAPo El siguiente paso se basa en la elección del tipo de

almacenamiento del cubo OLAP.o La calidad del diseño inicial del proyecto de data warehouse

es inversamente proporcional al coste de la implementación del cubo...

o El diseñador del data warehouse puede seleccionar si quiere establecer un almacenamiento separado para los cubos, o si quiere almacenarlos junto con el resto de datos del data warehouse. Esto depende directamente del tamaño de los datos almacenados y la conexión prevista para la carga de los datos.


© Hermes Romero



o El diseño ideal de almacenamiento de cubos OLAP es el almacenamiento independiente en estructuras optimizadas para la naturaleza de las consultas que se llevan a cabo con OLAP (drill down, roll up, slice, dice), sobre todo en entornos donde se mueven grandes volúmenes de datos con consultas frecuentes.

o Las consultas que los usuarios realizan contra los cubos OLAP consumen grandes recursos del sistema.


© Hermes Romero



El almacenaje de los cubos de OLAP es una de las decisiones críticas que se han de tomar a la hora de diseñar el data warehouse. Es posible almacenar los cubos OLAP de tres maneras:

MOLAP OLAP Multidimensional. En MOLAP, los datos de fuente

y las agregaciones son almacenes en un formato multidimensional. MOLAP es la opción más rápida para la recuperación de datos, pero requiere de mucho espacio en disco, aunque en nuestros días esto no es un gran problema debido al bajo precio de almacenamiento.


© Hermes Romero



ROLAP OLAP Relacional. Todos los datos, incluyendo las

agregaciones se almacenan dentro de una estructura relacional de base de datos, que puede estar en la misma localización de la fuente o no. ROLAP es el método de almacenamiento mas lento en la recuperación de los datos. ROLAP tiene sentido en pequeños volúmenes de datos.


© Hermes Romero



HOLAP OLAP Híbrido. HOLAP es una combinación de las

anteriores (MOLAP,ROLAP). Las bases de datos HOLAP almacenan las agregaciones dentro de una estructura multidimensional, pero el almacenamiento de los mismos (pre-calculados) se produce de forma relacional. HOLAP ofrece las funcionalidades de MOLAP,pero, es tan lento como ROLAP.


© Hermes Romero



Debido a que los costes de hardware son cada vez mas bajos, MOLAP se presenta como la mejor opción siempre que sea posible el acceso a una base de datos o fuente MOLAP independiente. Por otro lado ROLAP es más conveniente en el caso de que el número de consultas sea reducido y el volumen de datos relativamente bajo.


© Hermes Romero



Seguridad de OLAPo El almacenamiento de los cubos también beneficia a las políticas de

seguridad de los datos de la empresa ya que, es posible dar acceso a determinados usuarios a todos los datos dejando plena libertad de actuación con ellos (definición de dimensiones y medidas), o bien por otra parte dar acceso restringido y limitado a usuarios dependiendo de su perfil y permisos, a unos u otros cubos OLAP pre-procesados y almacenados.

o Estas estrategias de seguridad, junto con la posibilidad de almacenamiento de los cubos OLAP, permiten a las compañías ahorros considerables en hardware y software para el procesamiento ad-hoc de las consultas OLAP, así como el establecimiento de políticas de gestión de los datos adecuadas.


© Hermes Romero



Todos los empleados Mandos IntermediosDirectivos

Comité de dirección

Permisos para acceder a un númerolimitado de cubos predefinidos,dependiendo de las políticas de

seguridad aplicables

Permiso para acceder únicamente acubos predefinidos

Permiso para acceder a cubospredefinidos, así como para realizar

consultas OLAP ad-hoc sin límite


© Hermes Romero


Carga de datos en el DWH

La carga de datos del data warehouse, es el proceso por el cual se recogen los datos desde el origen del sistema transaccional que da soporte a las operaciones y otros sistemas externos y se añaden al data warehouse o a los distintos data marts.

Esta operación es la más complicada en la implementación del DWH, ya que:

o Las estructuras de datos son completamente diferenteso Pueden presentarse distintos orígenes de datoso Es normal realizar transformaciones y operaciones de cálculo sobre

los orígenes de datos El proceso de transformación y carga están condicionados por:

o Estructura de datos del sistema operacional o Estructura de datos del propio data warehouse.


© Hermes Romero



Etapas del proceso de carga del data warehouseo En el proceso de carga del data warehouse por tanto

podemos establecer tres etapas claramente diferenciadas:• Extracción• Transformación• Carga


© Hermes Romero



Extraccióno La extracción es el proceso de recogida de los datos desde los

sistemas operacionales o transaccionales u otras fuentes externas de datos.

o El tipo de extracción está por tanto directamente relacionado con el tipo de origen desde el que se realice la extracción.

o Podemos agrupar los métodos de extracción en 6 técnicas:• Extracción directa• Extracción desde el “log” de la Base de Datos• Extracción ejecutada por disparadores (triggers)• Extracción asistida por aplicaciones• Extracción en un punto del tiempo• Extracción por comparación


© Hermes Romero



o Extracción directa• La extracción 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 Días de poca actividad


© Hermes Romero



o Extracción desde el Log de la base de datos• Los datos son extraídos directamente desde los mecanismos de

registros de transacciones de los motores de bases de datos. • Permite la actualización constante casi en tiempo real de los

ficheros de extracción o del data warehouse, en el caso de actualización directa.

• Tiene un impacto muy bajo, casi nulo, en el rendimiento del motor de base de datos, por lo que los sistemas operacionales no se ven afectados.

• Requiere de técnicas de programación muy especificas y de un conocimiento detallado de las estructuras de almacenamiento en los registros de “log” del motor de base de datos en cuestión, para la extracción tan sólo de aquellos datos que son de nuestro interés.


© Hermes Romero



o Extracción ejecutada por disparadores (triggers)• Este tipo de extracción permite también la actualización en

tiempo virtualmente real de los dispositivos de extracción. • El mayor inconveniente de esta técnica de extracción es que el

sistema (la base de datos) se ve afectada en el rendimiento al ejecutar por cada evento el procedimiento correspondiente de actualización de la información en el destino,

o Este inconveniente puede verse agravado en el caso de que nuestro sistema esté configurado para la ejecución anidada de disparadores haciendo que el sistema entre en un estado de actualización en cascada que puede interferir gravemente en el rendimiento del sistema operacional.

• El impacto sobre el rendimiento se puede aminorar si los triggers tan sólo realizan llamadas a una cola externa de ejecución


© Hermes Romero



o Extracción asistida por aplicaciones• La extracción asistida por aplicaciones permite la realización de

extracciones complejas sobre los distintos orígenes de datos. • Estas aplicaciones, requieren la programación explícita de

procedimientos de extracción para todas y cada una de las operaciones de extracción que hayan de ser realizadas.


© Hermes Romero



• Un fallo de programación podría desvirtuar la información extraída.

• Existe la posibilidad de usar herramientas especificas para la extracción “ETL” (Extract Transforming Load), que suelen ser productos comerciales de probada efectividad.

o Incrementan la productividad a la hora de crear procesos de extracción ya que no requieren de programación propiamente dicha.

o Por otra parte su costo muchas veces no está justificado.o Su rendimiento suele ser por lo general inferior a un código nativo

optimizado de BBDD.


© Hermes Romero



• 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 (Informática)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..


© Hermes Romero



• 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 código optimizado y eficienteo Las herramientas ETL, cuestan dinero, generalmente cuestan más

dinero que las horas de programación que sustituyen.• En las extracciones asistidas por aplicaciones, al igual que en las

dos anteriores, existe la posibilidad de extraer los datos en tiempo relativamente real, produciendo una actualización constante del destino de los datos.


© Hermes Romero



o Extracción en un punto del tiempo• Este tipo de extracción requiere que los registros origen

contengan un campo con la fecha y hora de la última actualización, de esta manera el proceso de extracción podrá fácilmente distinguir entre aquellos registros que serán transportados hasta su destino y cuales no. Si un registro ha sido añadido o modificado será enviado a un fichero o tabla para su posterior procesamiento o transformación.


© Hermes Romero



o Extracción por comparación• La extracción por comparación es una técnica que se usó mucho

en el pasado pero que actualmente se encuentra en desuso, debido principalmente al rendimiento y eficiencia de esta técnica.

• Sencilla de comprender y de implementar. • Consiste en la extracción de una copia del origen de datos

(snapshot) en un punto del tiempo, en la siguiente extracción, se produce de nuevo un nuevo fichero como resultado de la extracción completa de datos, posteriormente un procedimiento se encarga de comparar el fichero antiguo con el fichero nuevo para de esta manera capturar aquellos registros que difieran del fichero original.


© Hermes Romero



En el siguiente cuadro se especifican las diferentes técnicas y su aplicación más adecuada para cada una de ellas:


© Hermes Romero



Transformacióno El proceso de transformación convierte los datos extraídos

desde los sistemas operacionales y otras fuentes a un formato y estructura conveniente para la carga en el data warehouse o el data mart.

o Durante este proceso, es natural que se produzcan datos (metadatos) que describen tanto el origen como el destino de los distintos valores después de la transformació.

o Este proceso también se conoce como “mapeado” de campos (mapping).

o Ayudará a resolver las posibles anomalías de los datos en origen

o Ayudará a producir datos de alta calidad .


© Hermes Romero



o Durante el proceso de transformación, se pueden producir transformaciones generadas por funciones externas.

• Estas transformaciones pueden ser aplicables o bien a nivel de registro o bien a nivel de columna.

o 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 transformación puede requerir que los datos extraídos sean procesados repetidas veces probablemente debido a que los datos de origen (extraídos) son usados para la carga de distintos registros en el destino.


© Hermes Romero



Cargao El proceso de carga es el encargado de recoger los datos

previamente transformados y guardarlos en el data warehouse o data mart de destino.

o Existen cuatro técnicas para el proceso de carga:• Carga simple (load)• Añadir (append)• Mezcla constructiva (constructive merge)• Mezcla destructiva (destructive merge)


© Hermes Romero



o Carga simple (load)• La carga simple reemplaza todos los datos del destino con los

nuevos datos resultado de la transformación. Si las tablas de destino no existen son creadas en este proceso.


© Hermes Romero



o Añadir (append)• Añade los nuevos datos sobre los datos ya existentes en el

destino, sin sustituir ni modificar ninguno de los existentes.


© Hermes Romero



o Mezcla constructiva (constructive merge)• Añade los nuevos registros sobre el destino y actualiza un valor

de fecha que indica la fecha y hora de la última actualización sobre aquellos registros existentes que están siendo reemplazados.


© Hermes Romero



La importancia del modelo de datoso Debido a los procesos de carga, es muy importante a la hora

de diseñar las estructuras de datos del data warehouse (el modelo de datos), tener en cuenta los procesos de carga, ya la elección de una u otra estructura con unos u otros contenidos pueden condicionar la carga del data warehouse, tanto desde el punto de vista del propio proceso de carga en tiempo y consumo de recursos como desde el punto de vista de la calidad del dato.

o El modelo de datos del data warehouse condicionará:• Los orígenes de los datos• Los intervalos de tiempo entre actualizaciones• El formato de los datos.


© Hermes Romero



o Dependiendo de si los datos existen o no en los orígenes, los datos deberán ser creados en el origen o calculados en el proceso de transformación y carga, por lo que los datos requerirán un mayor nivel de procesamiento con el consiguiente consumo de tiempo y recursos.

o Otro de los puntos importantes que deben ser tenidos en cuenta a la hora tanto del diseño del modelo de datos del data warehouse como de los procesos de carga de los datos es la granularidad del data warehouse.


© Hermes Romero


Ciclo de vida del DWH

El proceso de desarrollo de un data warehouse es similar al presentado en el ciclo de vida de desarrollo de sistemas lo que también se conoce como “Waterfall model”.


© Hermes Romero



El ciclo de vida de desarrollo de sistemaso Etapa 1 -- Viabilidad

• Se especifican los beneficios de implementar el sistema.

o Etapa 2 -- Definición de los requisitos• En esta etapa se desarrollan y especifican los requisitos

reflejados durante la etapa de viabilidad para el desarrollo del sistema.

• Funcionalidades del sistema (lo que debe hacer)• Interacción del usuario con el sistema• Condiciones de operación del sistema• Información generada por el sistema y su tratamiento


© Hermes Romero



o Etapa 3 – Diseño• Especificaciones de programación• Especificaciones de base de datos• Especificaciones de seguridad, etc...

o Etapa 4 – Desarrollo• Parte del diseño para llevar a la practica los distintos procesos

orgánicos descritos en la fase de diseño• En esta fase también se incluyen las pruebas del sistema antes

de pasar a producción

o Etapa 5 – Implementación• El sistema se lleva a producción después de la aceptación del

usuario final


© Hermes Romero




© Hermes Romero



Fases del proyecto data warehouse


© Hermes Romero



Se definen 7 fases en la gestión de un proyecto de data warehouseo Requisitoso Diseño de la Arquitectura técnicao Selección del producto e instalacióno Diseño del modelo dimensionalo Diseño físicoo Diseño y desarrollo del proceso de transformación y cargao Especificaciones de las aplicaciones de análisis e informeso Desarrollo de las aplicaciones de análisis e informeso Desarrollo e implementacióno Mantenimiento


© Hermes Romero



Requisitoso En esta fase mediante entrevistas, recogida de información

y documentos se establecerán las funcionalidades del futuro data warehouse, siempre desde el punto de vista del negocio.

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


© Hermes Romero



o Preguntas típicas en un entrevista serían: • ¿cómo se distinguen o agrupan los distintos productos? ... o los

agentes, o los proveedores, etc.. • Si el entrevistado realiza una análisis de los datos generados en

su área, preguntaremos entonces acerca de cómo lleva a cabo los análisis y cuales son los datos requeridos para esta operación.

o El entrevistador en todo momento estará atento a las propuestas de mejora de los sistemas actuales así como mejoras en los procesos de trabajo. Es habitual que los usuarios entrevistados para un proyecto data warehouse, completen sus peticiones con informes que usen actualmente, generados de manera automática o manual y sobre los que presentarán las mejoras que necesitan y por que las necesitan.


© Hermes Romero



o Si las entrevistas se llevan a cabo con ejecutivos de la empresa no es normal llegar al detalle, en cambio si se preguntará acerca de cómo mejorar la gestión de la información en la compañía.

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 relación con la información generada en los sistemas operacionales.

o En la etapa de requerimientos también es necesario priorizar las distintas funcionalidades, así como lograr un consenso acerca de las funcionalidades del sistema, entre los futuros usuarios del mismo y los directivos de la empresa.


© Hermes Romero



Diseño de la arquitectura técnicao En esta etapa diseñamos la integración entre las distintas

tecnologías, existentes con el nuevo proyecto, analizamos el impacto en los sistemas así como las necesidades que surgirán para soportar el proyecto. También se definirá la línea de tiempo para las distintas partes del proyecto.

o Como es evidente el diseño de la arquitectura técnica ha de venir marcado por los requerimientos del negocio.

o En esta fase ha de ser tenidas en cuenta las políticas de tecnologías de la información, las arquitecturas tecnológicas existentes, la evolución futura tecnológica de la empresa, así como sinergias con otras empresas del grupo.


© Hermes Romero



o Todos las soluciones tecnológicas propuestas para dar respuesta a las necesidades del negocio han de ser documentadas debidamente.

1. Establecer un equipo para el diseño de la arquitectura.2. Recoger requerimientos readicionados con la arquitectura3. Documentar los requerimientos de arquitectura4. Desarrollar un modelo de arquitectura a alto nivel5. Diseñar y especificar los subsistemas dentro de la arquitectura6. Determinar las fases de implementación de la arquitectura7. Documentar la arquitectura técnica8. Revisión y finalización de la arquitectura técnica


© Hermes Romero



Selección del producto e instalación1. El primer paso antes de seleccionar nuevos productos, es comprender el

proceso de aprobación de compras interno de la compañía.2. Desarrollar una matriz de evaluación de productos, que identifique los

puntos clave de los productos, así como que asigne pesos a cada una de las capacidades a comparar dependiendo de nuestras necesidades.

3. Rastrear el mercado para localizar las posibles soluciones existentes y a los proveedores.

4. Ir estrechando la lista de productos candidatos y realizando evaluaciones más detalladas.

5. Realizar pruebas de test si tenemos acceso a productos de evaluación.6. Seleccionar un producto, instalarlo en pruebas y negociar con el o los

posibles proveedores.


© Hermes Romero



Diseño del modelo dimensionalo En esta fase a partir de los requerimientos se construye el

modelo dimensional que dará soporte a nuestro data warehouse.

o El modelo debe estar debidamente documentado.


© Hermes Romero



Diseño físicoo El modelo dimensional diseñado en la fase anterior debe ser

traducido al diseño físico para el motor de base de datos especifico que hayamos seleccionado.

o En esta etapa se establecen las estrategias de agregación, así como la creación inicial de índices en el área de almacenamiento.


© Hermes Romero



o Los índices más recomendables son:• Sobre tablas de dimensiones:

o Índice sobre la clave primarao Í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 foráneas (FK) que participen en la tabla de hechos, en estos casos realizar un índice simple compuesto en las FK de las principales dimensiones. Como muchas de las consultas son conducidas a través de la dimensión de tiempo, la clave foránea (FK) correspondiente a esta dimensión debe de ser la primera en el índice compuesto.


© Hermes Romero



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


© Hermes Romero



Diseño y desarrollo de los procesos de transformación y cargao En este estado se diseñan y desarrollan las áreas

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


© Hermes Romero



Especificaciones de las aplicaciones analíticas y de informeso Siguiendo los requerimientos del negocio establecidos en la

primera fase, en esta fase se establece el diseño y funcionalidades de las distintas aplicaciones que explotarán los datos del data warehouse.


© Hermes Romero



Desarrollo de las aplicaciones analíticas y de informeso Se realiza el desarrollo de las aplicaciones diseñadas en la

fase anterior.


© Hermes Romero



Desarrollo e implementacióno En esta fase convergen las fases en las que se crearon los

procedimientos y áreas de extracción y transformación de datos y las de desarrollo de las aplicaciones de análisis e informes. En esta fase se ultima la integración entre las distintas áreas y se implementa el sistema en producción, con las debidas pruebas preliminares.

o En esta fase también será necesario formar a los usuarios en las herramientas de explotación de los datos, así como la generación de manuales de uso.


© Hermes Romero



Mantenimientoo Finalmente en este estado se realizan las labores de:

• Soporte a los usuarios• Formación continua• Soporte técnico• Monitorización


© Hermes Romero


Http://hermesromero.comHermes [email protected]

Documents

Fundamentos de DataWarehouse