Your SlideShare is downloading. ×
Fundamentos de DataWarehouse
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Fundamentos de DataWarehouse

7,174

Published on

Introducción a la arquitectura y los fundamentos de un sistema DataWarehouse

Introducción a la arquitectura y los fundamentos de un sistema DataWarehouse

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,174
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
437
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Fundamentos de Data Warehouse HHeerrmmeess RRoommeerroo DDAATTAABBAASSEE TTEEAAMM
  • 2. Contenidos  Introducción  Arquitectura del data warehouse  Estructura de un Data warehouse  Data marts  Granularidad  Exploración y minería de datos  Diseño del data warehouse  Visualización del modelo dimensional Aplicaciones OLAP (bases de datos dimensionales)  Carga de datos en el data warehouse  Ciclo de vida del data warehouse
  • 3. Introducción  Data Warehouse es una solución no un producto o grupo de  Un DWH puede ayudarnos a obtener respuestas para tomar  Antes de construir un DWH debemos responder a las siguientes preguntas o ¿De donde vienen los datos del DWH? o ¿cómo se cargarán los datos en el DWH? o ¿cómo se mantendrán? o ¿cómo se estructuran los datos en el DWH? o ¿qué podemos encontrar en un momento del tiempo en el DWH? © 2004 Database Team S.L © Hermes Romero productos. decisiones de manera más acertada. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 4. o Data Warehousing : diseño e implementación de procesos, y herramientas para gestionar y proveer información completa, en tiempo, fiel y comprensible para la toma de decisiones. Incluye todas las actividades que hacen posible a una organización la creación, gestión y mantenimiento del DWH o del datamart. o La definición aceptada de DWH se atribuye a Bill Inmon en 1992*: • DWH es una base de datos que sigue cuatro características: © 2004 Database Team S.L © Hermes Romero Introducción  Definición de DWH o Subject oriented o Nonvolatile o Integrated o Time variant DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 5. 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. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 6. 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. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 7. Introducción  Debido principalmente a tres fenómenos que han ocurrido durante la pasada década los tamaños de las bases de datos se han visto incrementados significativamente: o Los costes de almacenamiento se han vuelto insignificantes en comparación con el valor de la información almacenada. o Las empresas valoran la información (datos) como un activo o Muchas de las empresas multinacionales comparten su información a través de toda la organización a nivel mundial. © 2004 Database Team S.L © Hermes Romero de negocio crítico. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 8. • Diferentes estructuras de datos • Diferentes motores de datos • Diferentes almacenamientos físicos de información (ficheros) • Diferentes plataformas o Por ejemplo un sistema calcula la edad a través de la fecha de nacimiento, otro lo escribe en un campo, uno llama edad al atributo, otro le llama AGE... © 2004 Database Team S.L © Hermes Romero Introducción o Existen diferentes aplicaciones en la organización o Mainframes o Sistemas medios multiprocesador o Proveedores externos de servicios o Estaciones de trabajo en red e independientes. • Información distribuida • Multiplicidad de tipos de datos DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 9. 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. © 2004 Database Team S.L © Hermes Romero Introducción DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 10. o Los procesos de acceso a datos heterogéneos, limpios, filtrados y o El almacenamiento de datos en estructuras fáciles de acceder,  Los datos en el DWH son usados para consultar, analizar y  El tipo de acceso, uso, tecnología y rendimiento son completamente diferentes de los sistemas transaccionales operacionales OLPT. © 2004 Database Team S.L © Hermes Romero Introducción  Los sistemas DWH implementan : transformados fáciles de usar y comprensibles. realizar informes. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 11. 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. © 2004 Database Team S.L © Hermes Romero Introducción  Los volúmenes de datos en el DWH pueden ser DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 12. 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. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 13. 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 © 2004 Database Team S.L © Hermes Romero diferencian a la organización. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 14.  PARA LOGAR ESTOS RESULTADOS NO BASTA CON LA SIMPLE REINGENIERIA DE LOS MODELOS DE DATOS OPERACIONALES. © 2004 Database Team S.L © Hermes Romero Introducción DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 15.  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 © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH las otras decisiones. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 16.  Arquitectura del almacén de datos para informes y del área de almacenamiento temporal (Reporting data store and stagin data store architecture) o Las principales razones por las que se almacenan datos en un data o Realización de informes que hacen uso de ellos (Reported against) o Limpieza y organización de los datos (Cleaned up) o Transporte a otro almacén de datos donde pueden ser utilizados para realización de informes o para su limpieza y organización. © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH warehouse son: DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 17.  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... © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 18.  Arquitectura de herramientas (Tool architecture) o La elección de herramientas que serán usadas para reporting.  Arquitectura de procesado (Processing tiers architecture) o Elección de las plataformas físicas para el procesamiento concurrente o Puede ir desde una simple arquitectura como la basada en un único servidor de informes hasta uno cientos de servidores distribuidos.  Arquitectura de Seguridad (Security Architecture) o Aunque la seguridad no presenta ninguna dificultad técnica a la hora de ser aplicada si presenta complejas dificultades desde el punto de vista político. © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH que tiene lugar en el data warehouse. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 19.  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. © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 20. o Funcionalidad (¿Para que sirve?) o Número de Consultas “ad-hoc” (personalizadas) de los o Número de consultas personalizadas por día y por usuario-día o Número de usuarios de informes standard o Numero de usuarios, usuarios-día de informes standard o Número de informes standard o Volumen del historico a almacenar en meses, trimestres o o Volumen de datos típico para almacenar (diario,semanal o © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH  Como detectar un DWH usuarios años. mensual) DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 21.  Dependiendo de las respuestas a las preguntas descritas anteriormente se pueden establecer cuatro categorias: o OLPT – sistema transaccional de operaciones o ODS operational data store o OLAP online analytical processing o DM / DW Data mart / data warehouse © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 22. OLPT ODS OLAP DM/DW Funcionalidad Operacional Operacional/Decisional Decisional Decisional/Estrategica Herramientas de usuario final Cliente Servidor/WEB C/S-WEB C/S C/S-WEB tecnologia BBDD Relacional Relacional Cubica Relacional Nº de transacciones Alto Medio Bajo Bajo Tamaño de la transacción Bajo Medio Medio Alto tiempo de tranascción Corto Medio Medio Alto Tamaño BBDD en GB 1 OLPT * 2 - OLPT *10 OLPT * 2 - OLPT *10 OLPT*2-OLPT*100 Modelado de datos Entidad Relación Entidad Relación N/A Dimensional Normalización 3-5 NF 3 NF N/A 0 NF © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 23.  Otra de las mejores formulas para distinguir un DWH de uno que no lo es consiste en recabar la siguiente información: o Número de tablas o El número de registros de la tabla mayor o El tamaño en GB de la tabla mayor o La media de registros de las mayores tablas o El tamaño medio en GB de las mayores tablas o La mayor transacción (rollback) en GB. (Oracle) o El mayor segmento temporal necesitado en GB. (Oracle) © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 24.  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. © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 25. OLPT ODS OLAP DM/DW Nº de tablas 1-miles 1-miles OLPT/10 OLPT/10 Media de Registros por tabla miles -millones miles - millones millones millones Media de tamaño por tabla (GB) 1 a 99 1 a 99 1 a 99 1 a 999 Nº de registros de la tabla mas grande miles - millones miles - millones miles - millones miles - cientos de millones Tamaño de la Tabla mas grande (GB) 1 a 99 1 a 99 1 a 99 1 a 999 Tamaño de los segmentos de Rollback 1 a 100 Mb 1 a 100 Mb N/A 1 a 999 Gb Tamaño de los segmentos temporales 1 a 100 Mb 1 a 100 Mb N/A 1 a 999 Gb © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 26. o Debe hacer la información de la compañía accesible de manera sencilla a usuarios ofimáticos no avanzados o Debe presentar la información de la compañía de manera o Debe adaptarse al cambio en el entorno y adaptable a las o Debe ser lo suficientemente seguro para proteger el activo mas importante de la compañía ... La información. o Debe servir a la funcionalidad ultima de mejora de la toma o Los usuarios deben de aceptar el sistema si se pretende que © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH  El sistema DWH debe: consistente y estructurada necesidades puntuales del usuario de decisión. su implementación y uso se haga con éxito. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 27.  ¿cómo puede responder un sistema a la pregunta? o ¿por qué no se han alcanzado los resultados de ventas  Hasta el momento no existe ningún sistema informático que pueda dar respuesta a una pregunta de este tipo, imaginemos una sentencia SQL que pudiese dar respuesta a esta pregunta. © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH previstos? DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 28.  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 © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 29. 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... © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 30.  Un director de ventas se preguntará probablemente: o ¿qué productos son los que mas se venden y cuales los que o ¿cuál es el periodo medio de compra de mis clientes? © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH menos? o ¿cuáles son los clientes mas importantes? • Por cifra de negocio (facturación) • Por rentabilidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 31. o ¿qué clientes han reducido su periodo medio de compra? o ¿qué clientes han reducido su importe medio de compra? © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH o ¿cómo clasificaría a mis clientes? • A,B,C – Pareto o Basado en cifra de negocio o Basado en rentabilidad o Basado en periodo medio de compra • Otros... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 32. o ¿qué clientes no han comprado nada en los últimos 3 o ¿por qué no se están cumpliendo los objetivos de ventas? © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH meses? • A nivel local • A nivel provincial • A nivel regional • A nivel nacional • ... o ... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 33.  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 © 2004 Database Team S.L © Hermes Romero Arquitectura del DWH con un tiempo de respuesta aceptable. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 34.  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 © 2004 Database Team S.L © Hermes Romero Estructura de un DWH manera granular. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 35. o Esta es la característica más importante o Los datos llegan de diferentes orígenes y son cargados en el data o Los datos en su camino hacia el data warehouse pueden sufrir transformaciones fruto de cálculos realizados sobre los mismos. • Conversión de datos • Reformateado (Reformatted) • Cambio de secuencia (Resequenced) • Sumarizados (Summarized) • Etc... © 2004 Database Team S.L © Hermes Romero Estructura de un DWH  Está integrado warehouse. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 36.  Como resultado de las transformaciones y cargas los datos una vez que residen en el data warehouse poseen una única imagen física. © 2004 Database Team S.L © Hermes Romero Estructura de un DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 37.  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) © 2004 Database Team S.L © Hermes Romero Estructura de un DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 38. o Al contrario que en los sistemas transaccionales OLPT, los datos en el data warehouse no son accedidos de manera regular de registro en registro. o Los data warehouse son cargados (generalmente en masa) y accedidos sólo para su consulta no para su actualización. o Cuando el data warehouse se carga genera una foto fija en o Cuando se producen nuevas cargas fruto de cambios en los sistemas OLPT una nueva foto fija de los datos nuevos se generará de manera que los datos ya cargados junto con los nuevos pasarán a formar parte del histórico del data warehouse. © 2004 Database Team S.L © Hermes Romero Estructura de un DWH  No es volátil (nonvolatile) el tiempo de los datos (snapshot). DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 39. o Que el data warehouse sea variable en el tiempo implica que cada dato incluido en el data warehouse ha sido obtenido en un momento en el tiempo. • En algunos casos el registro tiene un campo de fecha. • En otros casos esa fecha se corresponde con la fecha en la que • En cualquier caso un registro siempre está sometido a una variable de tiempo. © 2004 Database Team S.L © Hermes Romero Estructura de un DWH  Variable en el tiempo se valido la transacción que lo contenía. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 40. o El horizonte temporal de un sistema data warehouse es o El data warehouse debe contener más datos históricos que © 2004 Database Team S.L © Hermes Romero Estructura de un DWH mayor al de un sistema operacional. • Operacional 60-90 días. • DWH 5 a 10 años. cualquier otro sistema. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 41.  Pequeños data warehouses que pueden trabajar  El data mart depende de la arquitectura seleccionada © 2004 Database Team S.L © Hermes Romero Data Marts independientemente o interconectados. para el data warehouse. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 42.  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 © 2004 Database Team S.L © Hermes Romero Data Marts warehouses”) o Proyectos mas arriesgados o Altos costes o Tiempos altos de desarrollo. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 43. o Se pueden implementar de manera rápida y sencilla o Son proyectos de bajo riesgo. o presentan los datos desde la perspectiva de un proceso  La cantidad de datos históricos contenidos en un data mart deben ser dictados por los requerimientos del negocio. © 2004 Database Team S.L © Hermes Romero Data Marts  Los data marts simple de negocio (subject). DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 44. • Albergan subconjuntos de datos del repositorio central. o Los data marts también son conocidos como data warehouses departamentales (departamental data warehouses). • No debe ser estrictamente departamental ya que es relativo a un proceso de negocio no a un departamento. • facturación, llamadas del call center, movimientos de almacén, procurement, etc... © 2004 Database Team S.L © Hermes Romero Data Marts  Arquitectura en Bus o Los Data marts en bus o seleccionados o preparados o Son usados por parte de un grupo de usuarios. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 45. o Algunas veces los diseños de arquitecturas data warehouse basados en data marts caen en el error de diseñar estructuras de tela de araña donde múltiples extracciones de un mismo origen de datos se cargan en diferentes data marts. Con esto diseños se debe tener en cuenta el mayor coste así como la posibilidad de inconsistencias de los datos en los diferentes data marts. o Las arquitecturas basadas en estructuras de tela de araña no tienen en cuenta que el diseño de los distintos data marts debe estar basado en el proceso de negocio y no en la organización departamental de la compañía. En los sistemas centrados en el proceso (process-centric) los dato son extraídos una sola vez y almacenados en un único lugar. © 2004 Database Team S.L © Hermes Romero Data Marts  ...arquitectura en bus DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 46. o Un analista que quiera obtener datos accederá de esta o Un repositorio de metadatos provee la información acerca de los diferentes data marts (directorio de data mart) © 2004 Database Team S.L © Hermes Romero Data Marts  ...arquitectura en bus manera al data mart relevante. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 47. Usuarios Finales Usuarios Finales Usuarios Finales © 2004 Database Team S.L © Hermes Romero Data Marts BBDD Sistema Operacional Datos Historicos Repositorio Centralizado de Datos ODS (Operational Data Store) Otros datos Metadatos Data Marts DataMart DataMart DataMart DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 48.  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. © 2004 Database Team S.L © Hermes Romero DWH y Business Intelligence DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 49. o Business Intelligence (BI) es la habilidad de tomar mejores o Un entorno de BI enfocado al cliente provee de la infraestructura necesaria para proveer la información necesaria para maximizar la base de clientes. o Esta infraestructura combina datos, canales y técnicas analíticas para mejorar las satisfacción del cliente y el beneficio a través de mayores puntos de contacto. o Para los especialistas en Marketing esto es la habilidad de contactar al cliente correcto en el momento correcto, en el lugar correcto y con el producto correcto. © 2004 Database Team S.L © Hermes Romero DWH y BI decisiones de manera más rápida. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 50. 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. © 2004 Database Team S.L © Hermes Romero DWH y BI DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 51. 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. © 2004 Database Team S.L © Hermes Romero DWH y BI DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 52. 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 .... © 2004 Database Team S.L © Hermes Romero DWH y BI DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 53. © 2004 Database Team S.L © Hermes Romero DWH y BI DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 54. o Ante todo conocer al cliente o Cual es el valor del cliente para la compañía o Cuales son los clientes más importantes para la compañía o Cuales son los prospectos potenciales o Cuales son los clientes / productos más rentables © 2004 Database Team S.L © Hermes Romero CRM  Que persigue el CRM... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 55. o Cual es el resultado de mis campañas publicitarias © 2004 Database Team S.L © Hermes Romero CRM  ...Que persigue el CRM... • Nº de impactos • Nº de clientes nuevos • Incremento de ventas • CrossSelling o Optimizar la interacción con el cliente o Trato personalizado o Ofertas personalizadas o Etc... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 56. o El término CRM es confuso desde el punto de vista técnico • Se produce un paralelismo entre CRM y herramientas CRM o El CRM es una filosofía/estrategia de compañía que se lleva a cabo por medio de herramientas especializadas en los distintos ámbitos del tratamiento de la información referida al cliente. © 2004 Database Team S.L © Hermes Romero CRM  Ámbito tecnológico del CRM o Hoy por Hoy todo es CRM... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 57. BI Análisis Data mining © 2004 Database Team S.L © Hermes Romero CRM BBDD Transacciones ERP Negocio BBDD Relaciones Con clientes Herramientas CRM Contact-Center ETL Data Warehouse DATABASE TECHNOLOGIES & SERVICES Reporting www.hermesromero.com
  • 58.  La granularidad es el concepto mas importante en el diseño de un DWH. Por que es directamente proporcional al volumen de datos que almacenará el DWH.  La granularidad se refiere al nivel de detalle o resumen  A mayor detalle mayor nivel de granularidad.  A menor detalle menor nivel de granularidad. © 2004 Database Team S.L © Hermes Romero Granularidad de los datos contenidos en el DWH. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 59.  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. © 2004 Database Team S.L © Hermes Romero Granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 60.  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. © 2004 Database Team S.L © Hermes Romero Granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 61.  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.). © 2004 Database Team S.L © Hermes Romero Granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 62.  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. © 2004 Database Team S.L © Hermes Romero Los beneficios de la granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 63.  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. © 2004 Database Team S.L © Hermes Romero Los beneficios de la granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 64. Ventas por mes Ventas por semana Ventas por área geografica (52) Ventas por vendedor (52) Ventas por producto (20) Ventas por nivel de rentabilidad (5) 1081600 registros al mes 21632000 bytes/mes © 2004 Database Team S.L © Hermes Romero Los beneficios de la granularidad Ventas por mes Marketing Ventas Ventas por mes Ventas por área geografica (52) Operaciones Financiero Ventas por mes Ventas por semana Ventas por área geografica (52) Ventas por vendedor (52) Ventas por mes Ventas por semana Ventas por área geografica (52) Ventas por vendedor (52) Ventas por producto (20) 10816 registros al mes 216320 bytes/mes Mayor Granularidad 1 registro al mes 20 bytes/mes 52 registros al mes 1040 bytes/mes 216320 registros al mes 4326400 bytes/mes DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 65.  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. © 2004 Database Team S.L © Hermes Romero Beneficios de la granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 66. o A través del ejemplo anterior veamos el siguiente supuesto: • ¿Cuantas unidades ha vendido Paco del producto limpia-hogar Malvarossa la semana del 3 al 10 de Diciembre del año pasado.? o En el nivel 1 de granularidad nuestra pregunta no tendría o En el nivel 2 de granularidad tampoco o Ni en el nivel 3. o En el nivel 4 de granularidad nuestra respuesta si podría ser o En el nivel 5 de granularidad también podría ser contestada. © 2004 Database Team S.L © Hermes Romero Beneficios de la granularidad respuesta. contestada. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 67. 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). © 2004 Database Team S.L © Hermes Romero Beneficios de la granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 68.  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. © 2004 Database Team S.L © Hermes Romero Granularidad múltiple DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 69.  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. © 2004 Database Team S.L © Hermes Romero Granularidad múltiple DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 70.  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. © 2004 Database Team S.L © Hermes Romero Granularidad múltiple DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 71.  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. © 2004 Database Team S.L © Hermes Romero Granularidad múltiple DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 72.  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. © 2004 Database Team S.L © Hermes Romero Estimación de la Granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 73. 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. © 2004 Database Team S.L © Hermes Romero Estimación de la granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 74. 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. © 2004 Database Team S.L © Hermes Romero Estimación de la granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 75. o 5º Establecer el número y tamaño de los índices necesarios para las distintas tablas del DWH, es conveniente crear índices en cada una de las variables condicionantes que formarán parte de las consultas (campos que estarán en las cláusulas WHERE de las sentencias SQL). • (Máximo número de filas posible en un año X tamaño máximo pro registro) + espacio de índices • (Mínimo número de filas posible en un año X tamaño mínimo por registro) + espacio de índices © 2004 Database Team S.L © Hermes Romero Estimación de la granularidad o 6º Realizar la operación DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 76. o Repetir esta operación por cada una de las tablas del DWH o Por lo general las estimaciones siempre se quedan pequeñas debido al crecimiento del DWH, por lo que es aconsejable sumar un espacio extra de al menos un 30% sobre la estimación. © 2004 Database Team S.L © Hermes Romero Estimación de la granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 77.  Una vez obtenidos los resultados de las predicciones es necesario aplicar la siguiente tabla para revisar si el nivel de granularidad es correcto: 100.000.000 1.000.000.000 Existen datos no usados por lo que se debe de replantar niveles inferiores de granularidad 10.000.000 100.000.000 Posiblemente existan datos no usados por lo que se recomienda replantearse el nivel de granularidad en el diseño del 1.000.000 10.000.000 DNiWveHl de granularidad Aceptable 100.000 1.000.000 Nivel de granularidad Adecuado © 2004 Database Team S.L © Hermes Romero Estimación de la granularidad número de registros a 1 año vista Número de resgristros a 5 años vista DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 78.  Un importante componente de los sistemas DWH es el concepto de “Overflow storage” almacenamiento desbordado o El almacenamiento desbordado se produce cuando son almacenados datos que no son usados de manera frecuente. o Relación directa con la granularidad del diseño. • A mayor nivel de granularidad mayor es la probabilidad de que se produzca el desbordamiento. © 2004 Database Team S.L © Hermes Romero Estimación de la granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 79.  Con el transcurso del tiempo mayor desbordamiento. o Almacenar los datos poco consultados en dispositivos o El uso del almacenamiento externo tiene implicaciones de rendimiento. • Seleccionar cuidadosamente que datos . • Un reparto inteligente de los datos entre los dispositivos externos e internos del sistema permitirá un mejor rendimiento a menor coste. © 2004 Database Team S.L © Hermes Romero Estimación de la granularidad externos CD-ROM - DVD DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 80. 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. © 2004 Database Team S.L © Hermes Romero Estimación de la granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 81.  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. © 2004 Database Team S.L © Hermes Romero Estimación de la granularidad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 82.  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 © 2004 Database Team S.L © Hermes Romero Estimación de la granularidad preparado para el futuro. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 83. Caminos para establecer la granularidad  Realizando consultas sobre los orígenes de datos con los  Realizando las operaciones de agregación, que serán realizadas desde el origen de los datos en su camino hacia el data warehouse.  Realizando las operaciones estadísticas como medias, etc.. que serán realizadas desde el origen de datos en su camino hacia el data warehouse. © 2004 Database Team S.L © Hermes Romero distintos niveles de granularidad posible. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 84. Caminos para establecer la granularidad  Identificando los mayores y menores valores en el  Identificando tan sólo los datos que son estrictamente  Realizando pruebas de muestreo de datos utilizando conjuntos representativos de datos mediante condicionantes. © 2004 Database Team S.L © Hermes Romero destino. necesarios en el destino. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 85.  Podemos definir particionamiento de los datos a nivel lógico y a nivel físico, para una mejor compresión, mantenimiento y navegación a través del DWH  El particionamiento físico se define a través de la propia  En el particionamiento de datos lógico el criterio común mas usado es el áreas temáticas (subject areas). o Podemos definir un área temática como una porción del DWH que es clasificada desde una perspectiva consistente. © 2004 Database Team S.L © Hermes Romero Particionamiento implementación física del diseño. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 86. o Acceso más flexible a los datos o Una gestión de los datos mas sencilla y eficiente o Asegura la escalabilidad del DWH o Habilita la posibilidad de que los elementos del DWH sean portables y compartidos con otros DWH o archivados en distintos dispositivos de almacenamiento externo. © 2004 Database Team S.L © Hermes Romero Particionamiento  Para el DWH el particionamiento aporta: DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 87.  Habitualmente se realizan particiones de grandes volúmenes de datos dividiéndolos en piezas mas pequeñas. Al hacer esto determinadas operaciones con los datos serán más fáciles de realizar: o Reestructuración de datos o Indexación o Escaneado Secuencial (Full Scans) o Reorganización o Recuperaciones o Monitoreado o Auditoría © 2004 Database Team S.L © Hermes Romero Particionamiento DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 88.  Los criterios de particionamiento de los datos son variados pero quizás los mas representativos sean: o Periodo de tiempo (Fecha, mes , trimestre, semestre, año) o Por áreas geográficas o Por producto o línea de negocio o Por unidad organizativa o ... o Por combinaciones de lo anterior © 2004 Database Team S.L © Hermes Romero Particionamiento DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 89.  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. © 2004 Database Team S.L © Hermes Romero Particionamiento DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 90.  Se puede realizar un particionamiento controlado por la propia aplicación. o Añadirá la posibilidad de portar los datos entre distintos © 2004 Database Team S.L © Hermes Romero Particionamiento DWH.  El particionamiento depende de: o El modelo de datos multidimensional o La granularidad de los datos o Las capacidades del motor de base de datos DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 91.  Un DWH está siempre orientado a áreas temáticas  Área temática = área de interés para el negocio  El DWH está siempre orientado a áreas especificas de la © 2004 Database Team S.L © Hermes Romero Áreas temáticas (subject areas) (subject areas). organización como pueden ser: o Clientes o Productos o Beneficios o Ventas o ... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 92.  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?... © 2004 Database Team S.L © Hermes Romero Áreas temáticas DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 93.  Las áreas temáticas son la forma más común de  Para extraer una lista de los candidatos a áreas © 2004 Database Team S.L © Hermes Romero Áreas temáticas particionamiento lógico en el DWH. temáticas, debemos hacernos la pregunta: o ¿cuáles son los intereses del negocio? DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 94.  Para la localización de las áreas temáticas se utiliza el método 5W1H que consiste en preguntarse acerca de: cuando, donde, quien, que, por que y como (When, where, who, what, why, how) acerca del negocio. o Si se hace la pregunta en quien está interesado el negocio (who) podrá aparecer: • Clientes, empleados, gerentes, proveedores, competidores, etc... • Este año, trimestralmente, mensualmente, anualmente, semanalmente, etc... © 2004 Database Team S.L © Hermes Romero Áreas temáticas o Sobre la pregunta cuando (when) o Donde (where) • Provincias, ciudades, países, etc... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 95.  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. © 2004 Database Team S.L © Hermes Romero Áreas temáticas DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 96. Exploración y data mining (minería de datos)  Los sistemas de Data mining o minería de datos se han hecho populares durante la pasada década. o para obtener mayor información o para obtener una mejor comprensión del negocio o para encontrar nuevos caminos e ideas para ganar potencial © 2004 Database Team S.L © Hermes Romero en otros mercados. o Para controlar gastos y costes DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 97.  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. © 2004 Database Team S.L © Hermes Romero Exploración y Data mining o Etc... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 98.  Esta integración en los sistemas operacionales de la compañía requiere: o Integración de los sistemas de Data mining con las bases de o Integración de los sistemas de Data Mining con los sistemas © 2004 Database Team S.L © Hermes Romero Exploración y Data mining datos de producción DWH. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 99.  El principal caldo de cultivo de los sistemas de data mining son los sistemas DWH, ya que: o Permiten el análisis de los datos sobre granularidades o No influyen en el rendimiento del sistema operacional. o Buscan patrones de comportamiento a lo largo de todos los sistemas de la compañía y para ello es fundamental la integración y estandarización del DWH. © 2004 Database Team S.L © Hermes Romero Exploración y data mining significativas para el sistema DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 100. © 2004 Database Team S.L © Hermes Romero Exploración y Data Mining Definición DATA WAREHOUSE Preparación de los datos Minería de datos Interpretación de resultados Implementación de resultados DATA MINING FUNCIONES DE SCORING DE RESULTADOS DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 101. • Permite responder a determinadas preguntas , obteniendo la información relevante desde el DWH, transformándola para el contexto apropiado y mostrándola de manera legible. En esta técnica las consultas realizadas están basadas en dos dimensiones. • Los usuarios finales están especialmente interesados en: o Procesado de valores numéricos...totales de ventas, cantidades o Cálculo o investigación de medidas de calidad como satisfacción de o Predicciones de análisis de transacciones de negocio, análisis de © 2004 Database Team S.L © Hermes Romero Exploración y data mining  Consultas e Informes vendidas. clientes, retrasos en procesos de negocio, etc.. tendencias, etc... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 102. Preparación del informe Entrega del informe © 2004 Database Team S.L © Hermes Romero Exploración y Data Mining Definición de la consulta Acceso y obtención del dato Manipulación del dato y cálculo DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 103. • 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. © 2004 Database Team S.L © Hermes Romero Exploración y data mining o Análisis multidimensional Enero Vendedor provincia DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 104. • Mediante el mecanismo de precálculo integrado en las herramientas de procesamiento multidimensional, todas las respuestas a las distintas consultas (dimensiones) se obtienen en la misma orden. o los datos no son recalculados sino que simplemente son accedidos y • El análisis multidimensional permite a los usuarios tener a su alcance un gran número de factores interdependientes asociados a un escenario del negocio. • Los usuarios pueden acceder a la información explorando los datos en diferentes niveles de detalle. © 2004 Database Team S.L © Hermes Romero Exploración y data mining mostrados. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 105. Totales de Ventas en Enero Totales de Ventas en Febrero Totales de Ventas en Marzo Vendedor 1 Vendedor 2 Vendedor 1 Vendedor 2 Vendedor 1 Vendedor 2 Mad Sev Mad Sev Mad Sev Mad Sev Mad Sev Mad Sev © 2004 Database Team S.L © Hermes Romero Exploración y data mining Totales de Ventas en el primer trimestre Drill Down DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com Roll Up
  • 106. o Es una técnica relativamente nueva es muy diferente de las técnicas de consultas e informes y del análisis multidimensional, su principal diferencia se basa en lo que se llama técnica de descubrimiento. o La técnica de descubrimiento (discovery technique) no consiste en realizar una consulta especifica a los datos, en cambio esta técnica utiliza algoritmos que analizan los datos y devuelven los resultados descubiertos. A diferencia de las dos técnicas anteriores el data mining busca respuesta a consultas que no han sido previamente realizadas. © 2004 Database Team S.L © Hermes Romero Exploración y Data mining  Data Mining DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 107. 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. © 2004 Database Team S.L © Hermes Romero Exploración y Data Mining DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 108. o Las técnicas de data mining se utilizan habitualmente para análisis estadístico de los datos y para descubrir el conocimiento (knowledge discovery) • El análisis estadístico descubre patrones no habituales en los datos aplicando técnicas matemáticas y estadísticas para la explicación de los patrones. • Una vez descubierto el patrón este se utilizará entonces para hacer previsiones y presupuestos. • Algunas de las técnicas estadísticas incluyen: • “knowledge discovery” extrae información no conocida de manera implícita de los datos. © 2004 Database Team S.L © Hermes Romero Exploración y Data Mining o análisis linear y no lineal o análisis de regresión o Análisis multivarianza o Y análisis de series en tiempo. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 109. 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. © 2004 Database Team S.L © Hermes Romero Exploración y Data Mining DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 110. Gestionado por los datos Multidimensional Data Mining © 2004 Database Team S.L © Hermes Romero Exploración y Data mining Gestionado por el Analista Asistido por el Analista Consultas e informes Análisis DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 111. o OLAP data mart (OnLine Analitical Processing)  análisis multidimensional • Están diseñados para soportar análisis multidimensional usando • El data mart en este caso se diseña utilizando las técnicas de esquema en estrella o tecnologías propietarias de cada herramienta basadas en el concepto de “hipercubo” (Hypercube). • El esquema en estrella o sistema de gestión de base de datos multidimensional (multidimensional database management system MD DBMS) es el indicado en data marts de los que se conocen perfectamente los requerimientos, estos son estables y las consultas a los mismos son fácilmente predecibles con tiempos de respuesta razonables e informes mas o menos recurrentes. © 2004 Database Team S.L © Hermes Romero Exploración y data mining herramientas de software OLAP. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 112. o Almacenes de exploración (Exploration warehouse) • Los almacenes de exploración están diseñados para dar soporte real a la exploración o navegación puramente customizable por el usuario “ad-hoc”. • Después de un descubrimiento a través de la exploración, este puede dar lugar a la creación de un nuevo data mart , para que otros usuario se beneficien del hallazgo a partir de es momento. o Almacenes estadísticos (Data mining or statistical warehouses) • Es un data mart especializado diseñado para dar soporte a los o Aplicaciones analíticas customizables (Customizable analytical applications) • Permite la customización efectiva de aplicaciones genéricas. © 2004 Database Team S.L © Hermes Romero Exploración y Data Mining analistas e investigadores. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 113.  Asumamos las siguientes aserciones como ciertas antes • En el DWH podremos encontrar datos de todas las unidades de negocio y departamentos de la compañía. o Se asume también que los datos contenidos en el DWH no violan ninguna de las reglas de negocio establecidas para la compañía. • El DWH en todo momento debe mostrar su adherencia a las © 2004 Database Team S.L © Hermes Romero Diseño del DWH de continuar: o El DWH debe tener un enfoque corporativo reglas de negocio de la compañía. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 114. o El DWH debe ser cargado con datos lo más rápida y o El DWH debe configurarse y diseñarse para soportar múltiples tecnologías de BI, tanto presentes como futuras. o El DWH debe acomodarse fácilmente a cambios tanto en las estructuras de datos como en los datos propiamente dichos. © 2004 Database Team S.L © Hermes Romero Diseño del DWH eficientemente posible. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 115.  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. © 2004 Database Team S.L © Hermes Romero Diseño del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 116. o El análisis multidimensional también permite las operaciones o La minería de datos habitualmente trabaja mejor con el mayor nivel de detalle disponible (granularidad alta). © 2004 Database Team S.L © Hermes Romero Diseño del DWH  Debemos tener en cuenta también que: “drill down” y “roll up”. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 117.  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. © 2004 Database Team S.L © Hermes Romero Diseño del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 118.  Las características ideales que debe seguir el modelo de • Debemos por todos los medios a nuestro alcance evitar la redundancia de los datos en nuestro DWH. La redundancia de datos añade trabajo extra a las operaciones de extracción transformación y carga (ETL), así como a los diseñadores que tendrán que preocuparse de que todos los elementos redundantes tengan el valor correcto en el momento correcto. • A mayor redundancia mayor complejidad en la carga de los datos. • Evidentemente cierto grado de redundancia a veces es inevitable e incluso aconsejable, a este tipo de redundancia la llamaremos redundancia controlada. © 2004 Database Team S.L © Hermes Romero Diseño del DWH datos en el sistema DWH son: o No redundante. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 119. • 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. © 2004 Database Team S.L © Hermes Romero Diseño del DWH o Estable DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 120. • 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. © 2004 Database Team S.L © Hermes Romero Diseño del DWH o Consistente DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 121.  El modelo de datos resultante para el DWH, se trasladará a un diseño de base de datos que sea: o Fiable • No contendrá contradicciones en la forma de nombrar entidades o atributos, en referencias de unos a tros, así como en la documentación • El DWH resultante de la implementación de este modelo de datos podrá ser accedido por múltiples procesos y usuarios desde cualquier parte de la compañía. © 2004 Database Team S.L © Hermes Romero Diseño del DWH o Compartido DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 122. • La base de datos resultante no condicionará en una dirección u otra el entorno BI creado. Todas las oportunidades tecnológicas que se presenten permanecerán disponibles para la compañía. • LA base de datos resultante podrá acomodar nuevas entidades y atributos, manteniendo al integridad de los elementos implementados. • El modelo de datos proveerá una representación de cómo y que clase de información es usada en la compañía- © 2004 Database Team S.L © Hermes Romero Diseño del DWH o Flexible y adaptable al cambio o Correcto DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 123.  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. © 2004 Database Team S.L © Hermes Romero Diseño del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 124.  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. © 2004 Database Team S.L © Hermes Romero Diseño del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 125.  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. © 2004 Database Team S.L © Hermes Romero Diseño del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 126.  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. © 2004 Database Team S.L © Hermes Romero Diseño del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 127.  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. © 2004 Database Team S.L © Hermes Romero Diseño del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 128. © 2004 Database Team S.L © Hermes Romero Diseño del DWH latencia DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com Repetitivas Customizables Algoritmicas volatilidad Esquema en estrella De-normalizadas Normalizadas Planas
  • 129. Diseño del DWH – Estructura de los datos  Para DWH podemos distinguir tres tipos básicos de datos:  Se puede configurar el DWH basándose en estos tres tipos, con la consideración adecuada a las características particulares de cada implementación. © 2004 Database Team S.L © Hermes Romero o Datos en tiempo real (real-time data) o Datos derivados (Derived data) o Datos reconciliados (Reconciled Data) DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 130. Diseño del DWH – Estructura de los datos  Dependiendo de la naturaleza de los sistemas operacionales, el tipo de negocio, y el número de usuarios que pueden acceder al DWH, debemos combinar los tres tipos de datos para crear el mas adecuado modelo de datos para el DWH. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 131. Diseño del DWH – Estructura de los datos o Los datos en tiempo real representan el estado actual del negocio. Por supuesto, estos son los datos que utilizan los sistemas operacionales. o Los datos en tiempo real muestran la realidad cambiante del o Los datos en tiempo real muestran por otra parte el mayor nivel de detalle lo que se representa como el mayor nivel de granularidad. o Habitualmente estos son accedidos en modo lectura-escritura por las transacciones operacionales. © 2004 Database Team S.L © Hermes Romero  Datos en tiempo real (Real-Time data) negocio transacción a transacción. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 132. Diseño del DWH – Estructura de los datos 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. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 133. Diseño del DWH – Estructura de los datos 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. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 134. Diseño del DWH – Estructura de los datos 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. © 2004 Database Team S.L © Hermes Romero  Datos Derivados (Derived Data) DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 135. Diseño del DWH – Estructura de los datos o Los datos derivados son tradicionalmente usados para la o La sumarización de los datos en nuevos registros derivados requiere grandes volúmenes de datos a analizar y por consecuencia necesitará de grandes recursos para su procesamiento. o La eficiencia de los procesos de creación de datos derivados en tiempo y manera es vital y una de las tareas mas importantes que los analistas han de resolver. © 2004 Database Team S.L © Hermes Romero toma de decisiones y el análisis del negocio. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 136. Diseño del DWH – Estructura de los datos 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. © 2004 Database Team S.L © Hermes Romero  Datos Reconciliados (Reconciled Data) DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 137. Diseño del DWH – Estructura de los datos  El concepto de EDM – Enterprise Data Model o Un EDM es una definición consistente de todos los elementos de datos comunes al negocio. Desde una perspectiva mas abstracta a la mas concreta. o El EDM incluye a su vez vínculos a los diseños de datos de o A través del EDM se puede intuir una visión y comprensión © 2004 Database Team S.L © Hermes Romero cada una de las aplicaciones operacionales. de los requerimientos del negocio. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 138.  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 © 2004 Database Team S.L © Hermes Romero Modelado de datos para el DWH datos : o Modelado entidad-relación ER o Modelado dimensional DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 139.  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. © 2004 Database Team S.L © Hermes Romero Modelado de datos para el DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 140.  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. © 2004 Database Team S.L © Hermes Romero Modelado de datos para el DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 141.  El modelo de datos es una abstracción organizada de los datos que representan las actividades, recursos y resultados de la organización.  Sin un modelo de datos la organización de la estructura y  El objetivo de los modelos de datos es conseguir la independencia lógico / física o Como se muestran los datos es completamente independiente de cómo se almacenarán a nivel físico © 2004 Database Team S.L © Hermes Romero Modelado de datos para el DWH del contenido del DWH sería muy difícil. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 142.  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 © 2004 Database Team S.L © Hermes Romero Modelado de datos para el DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 143. o Los modelos ER producen un modelo de datos de una especifica área de interes usando para ello dos conceptos básicos: Entidades y las relaciones entre esas entidades. Los modelos ER contienen también Atributos, que son las propiedades inherentes a las entidades y/o relaciones. o El modelo ER es una percepción del mundo compuesta por objetos llamados entidades y las relaciones entre ellos. Las entidades se diferencian unas de otras a través de sus atributos. © 2004 Database Team S.L © Hermes Romero Modelado de datos para el DWH  Modelos entidad-relación DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 144. o El modelado ER se representa mediante un diagrama que usa tres tipos de graficos para conceptualizar los datos: Entidad, relación y Atributo. • Entidad o Una entidad se define como una persona, lugar cosa o evento de o Una entidad representa una clase de objeto, que puede ser observado y clasificado por sus propiedades y caracteristicas. © 2004 Database Team S.L © Hermes Romero Modelado de datos para el DWH interes para el negocio o la organización. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 145. o Una relación se representa mediante lineas que unen a dos entidades. Una relación se designa de manera gramatical por medio de un verbo, como pertenece a, tiene. Tla relación entre dos entidades puede ser definida mediante su cardinalidad. La cardinalidad es el máximo número de instancias de una entidad que que se relacionan con una instancia de la otra entidad. Las cardinalidades posibles son: • Uno a uno 1:1 • Uno a muchos 1:M • Muchos a muchos M:M (no son válidas en un modelo normalizado) o Los atributos describen las caracteristicas o propiedades de las entidades. Un nombre de atributo debe se único en una entidad. © 2004 Database Team S.L © Hermes Romero Modelado de datos para el DWH • Relación • Atributos DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 146. Modelado de datos para el DWH – Modelado dimensional  El modelado de datos dimensional usa tres conceptos  En algunos casos el modelado dimensional es más sencillo, más expresivo y fácil de comprender que el modelado relacional.  Es relativamente nuevo por lo que no está firmemente definido, especialmente comparado con las técnicas de modelado relacional. © 2004 Database Team S.L © Hermes Romero básicos: o Medidas (measures) o Hechos (facts) o Dimensiones (dimensions) DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 147. Modelado de datos para el DWH – Modelado dimensional  El modelado dimensional es un conjunto de medidas (measures) que son descritas por aspectos comunes del negocio.  Es especialmente útil para sumarizar datos y presentarlos en vistas para ayudar al análisis de los datos.  El modelado dimensional se centra en los datos numéricos, como valores, cuentas (count), pesos, balances y ocurrencias. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 148. Modelado de datos para el DWH – Modelado dimensional o Es una colección de items de datos relacionados. o Cada hecho generalmente representa un item del negocio, una transacción del negocio, o un evento que puede ser utilizado para analizar el negocio o un proceso del negocio. o En un Data warehouse los hechos (facts) se almacenan donde los datos numéricos son almacenados. © 2004 Database Team S.L © Hermes Romero  Hechos (facts) DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 149. Modelado de datos para el DWH – Modelado dimensional o Es una colección de miembros o unidades del mismo tipo. o Las dimensiones determinan el contexto de fondo para los o Las dimensiones son los parámetros sobre los que queremos realizar el análisis OLAP (online analitical processing). © 2004 Database Team S.L © Hermes Romero  Dimensiones (dimensions) hechos. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 150. Modelado de datos para el DWH – Modelado dimensional o Si consideramos una base de datos de análisis de ventas, encontraremos entre otras las siguientes dimensiones. • Tiempo • Localización / Provincia • Clientes • Vendedor o Miembros de la dimensión (dimension members) • Una dimensión puede a su vez contener n miembros. • Por ejemplo, los meses : enero, febrero, marzo,...,trimestres, cuatrimestres son miembros de la dimensión tiempo. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 151. Modelado de datos para el DWH – Modelado dimensional o Jerarquías de la dimensión (dimension hierarchies) • Las dimensiones pueden a su vez ser divididas en diferentes jerarquías, cada jerarquía puede tener a su vez distintos niveles jerárquicos. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 152. Modelado de datos para el DWH – Modelado dimensional Semana día ... © 2004 Database Team S.L © Hermes Romero  Jerarquias de la dimensión Jerarquía 1 año Jerarquía 2 semestre semestre trimestre trimestre mes día ... ... ... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 153. Modelado de datos para el DWH – Modelado dimensional © 2004 Database Team S.L © Hermes Romero  Jerarquias de la dimensión o Drill down DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 154. Modelado de datos para el DWH – Modelado dimensional o Una medida se determina por la combinación de miembros de las dimensiones y está situada en los hechos (facts) © 2004 Database Team S.L © 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 • ... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 155. Modelado de datos para el DWH – Modelado dimensional © 2004 Database Team S.L © Hermes Romero  dimesion1 DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 156. Modelado de datos para el DWH – Modelado dimensional o Es la tabla central en el modelo de datos dimensional, en esta table es donde se almacenan los valores numéricos de las medidas. Se utiliza el termino hecho (fact) para representar una medida del negocio. o Una fila de la tabla de hechos representa una medida (measure). Por lo que una medida es una fila en la tabla de hechos. Todas las medidas de una tabla de hechos deben tener la misma granularidad. o Los hechos mas habituales son los numéricos y aditivos, © 2004 Database Team S.L © Hermes Romero  Tablas de hechos (facts) como euros o total de ventas. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 157. Modelado de datos para el DWH – Modelado dimensional o La capacidad de adición es crucial ya que raramente los valores de las tablas de hechos son recuperados de fila en fila, lo usual es recuperarlos mediante la suma de una o mas de sus columnas o mediante la cuenta del número de filas, medias, etc... o Es importante tener en cuenta que no es aconsejable la introducción de filas en las tablas de hechos que no representen nada como por ejemplo (12/12/2003 , 0) en representación de que el día 12/12/2003 no se realizó ninguna venta, en estos casos es mejor no incluir el registro, de esta manera el espacio ocupado por la tabla de hechos será util al 100% © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 158. Modelado de datos para el DWH – Modelado dimensional o Las tablas de hechos representan el 90% o más del espacio ocupado en un DWH, generalmente las tablas de hechos tienen la tendencia de ser voluminosas en cuanto a número de registros pero también a tener pocas columnas (atributos). o Las tablas de hechos se pueden además clasificar en tres grupos atendiendo a su nivel de granularidad. • Transacciones • Fotos-fijas periódicas (periodic snapshots) • Fotos-fijas acumulativas (accumulating snapshots) © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 159. Modelado de datos para el DWH – Modelado dimensional o Las tablas de hechos de tipo transaccional son las más o Las tablas de hechos poseen dos o mas “foreign keys” (FK) que conectan las tablas de hechos con las tablas de dimensiones. o La tabla de hechos por otra parte por lo general posee una clave primaria formada por el conjunto o un subconjunto de las claves externas FK que posee (clave primaria compuesta). Cada tabla de hechos en un modelo dimensional tiene una clave compuesta, por lo que también podemos afirmar que cada tabla en un modelo dimensional que posee una clave compuesta es una tabla de hechos. © 2004 Database Team S.L © Hermes Romero  ...Tablas de hechos (facts) habituales con diferencia. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 160. Modelado de datos para el DWH – Modelado dimensional o Las relaciones entre las tablas de hechos y las tablas de dimensiones son siempre relaciones de tipo muchos a muchos M:M. Por lo que las tablas que presenten este comportamiento relacional en un modelo dimensional serán tablas de hechos mientras que el resto serán tablas de dimensiones. o La composición de la clave primaria en la tabla de hechos no tiene por que relaizarse con todas las claves externas ya que probablemente la agrupación de unas pocas de ellas garantice la unicidad del registro. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 161. Modelado de datos para el DWH – Modelado dimensional o En la mayoría de los casos no tiene ninguna utilidad la introducción de una clave primaria no compuesta para identificar unívocamente a cada registro de la tabla de hechos. Al contrario de nuevo podemos ocupar un espacio extra para añadir esto cuando realmente no es necesario, con las consecuencias implícitas de almacenamiento y rendimiento. Aunque si la naturaleza del negocio requiere la inclusión de varias filas con los mismos valores entonces si debemos plantearnos la creación de una clave primaria, siempre que sea necesario hacer una distinción clara entre las filas con el mismo contenido. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 162. Modelado de datos para el DWH – Modelado dimensional o Mucho del éxito de nuestro DWH dependerá de cómo se © 2004 Database Team S.L © Hermes Romero  Tablas de hechos (facts) implementen las tablas de hechos. ventas diarias clave de fecha FK clave de tienda FK clave de producto FK cantidad valor DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 163. Modelado de datos para el DWH – Modelado dimensional o Hemos de tener en cuenta que las tablas de hechos pueden o No es posible el mantenimiento de índices en un corto espacio de o Las tablas de hechos también pueden estar implementadas © 2004 Database Team S.L © Hermes Romero  Tablas de hechos (facts) encontrarse en tres estados: • Están siendo Consultadas • Están siendo cargadas • Están siendo gestionadas tiempo de diferentes maneras: • Sin particionamiento – Sin índices • Particionadas – Sin índices • Sin particionamiento – Con índices DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 164. Modelado de datos para el DWH – Modelado dimensional o Las tablas de dimensiones contienen los descriptores o En un modelo bien diseñado las tablas de dimensiones tienen por lo general muchos atributos que describen la fila en la tabla de dimensión. o Las tablas de dimensiones deben contener tantos atributos como sean necesarios para hacer su contenido lo más comprensible posible. No es extraño encontrar tablas de dimensiones que contengan entre 50 y 100 atributos. © 2004 Database Team S.L © Hermes Romero  Tablas de dimensiones (dimensions) textuales del negocio. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 165. Modelado de datos para el DWH – Modelado dimensional o Por otra parte las tablas de dimensiones por lo general son tablas que presentan pocos registros en comparación con las tablas de hechos, por lo general no mas de 1 millón de registros. o Cada dimensión se define a través de una clave primaria no compuesta (única) PK que será utilizada para guardar la integridad referencial con cualquier tabla de hechos con la que esté relacionada. o Cada uno de los atributos de las tablas de dimensiones serán utilizados para realizar las consultas como condicionantes, agrupaciones, etc... © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 166. Modelado de datos para el DWH – Modelado dimensional o En una consulta los atributos de una dimensión son identificables por que siempre van precedidos de la palabra “por” (by). Quiero saber las ventas por region, Quiero saber las ventas por mes, Quiero saber las ventas por producto, ...por vendedor, etc. o Los atributos de las tablas de dimensiones juegan un papel vital en los modelos de datos dimensionales ya que ellos son el origen de las condicionantes en las consultas y de los resultados de las mismas. Los atributos de las tablas de dimensiones son la clave para hacer el DWH usable y comprensible. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 167. Modelado de datos para el DWH – Modelado dimensional o Un DWH será tan bueno como atributos de las tablas de dimensiones posea. El poder del DWH es directamente proporcional a la calidad y profundidad de los atributos de sus dimensiones. o Cuanto mas tiempo pasemos definiendo atributos con sentido para el negocio mejor será nuestro DWH. o Cuanto mas tiempo pasemos poblando nuestras tablas de dimensiones con valores para los distintos atributos mejor será nuestro DWH. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 168. Modelado de datos para el DWH – Modelado dimensional © 2004 Database Team S.L © Hermes Romero  ...tablas de dimensiones (dimensions) DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 169. Modelado de datos para el DWH – Modelado dimensional • Los atributos deben ser palabras reales en lugar de abreviaciones. Esto nos ayudará en la implementación del DWH con respecto a los usuarios del mismo, ya que contribuye a su facilidad de uso y compresibilidad por parte de los usuarios. Los atributos típicos para una dimensión de producto por ejemplo incluirían una descripción corta de 10 a 15 caracteres, una descripción larga de 30 a 50 caracteres, nombre de la marca, categoría o familia de producto, tipo de empaquetado, tamaño , peso y otras características. Aunque se definan atributos numéricos dentro de las dimensiones, conservarán su carácter de dimensión siempre que se tomen como descripciones textuales, por ejemplo, el atributo código postal está representado por un número aunque su uso es textual no vamos a realizar operaciones con este valor, mas que para definir un área geográfica concreta. © 2004 Database Team S.L © Hermes Romero o Atributos en las dimensiones DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 170. Modelado de datos para el DWH – Modelado dimensional • Las tablas de dimensiones frecuentemente representan estructuras jerarquicas entre distintas entidades, por ejemplo la dimensión producto, incluye un atributo marca que puede permitir a su vez la agrupación de los productos por marca, lo mismo ocurre con la familia de productos. Para cada fila en la dimension de producto se almacenará el nombre de la marca y el nombre de la familia a la que pertenece, aunque de esta forma estamos almacenando información redundante, pero esta operación se realiza para evitar nuevas relaciones (joins) en las consultas que se traducirian en decrementos del rendimiento del sistema. © 2004 Database Team S.L © Hermes Romero  ...tablas de dimensiones (dimensions) o Jerarquia de las dimensiones DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 171. Modelado de datos para el DWH – Modelado dimensional • Debemos resistir nuestro impulso de almacenar tan solo el código de la marca y crear una vista separada para todas las marcas. Esto es lo que se conoce como diseño de copo de nieve (snowflake). Por lo general las tablas de dimensiones presentan un alto grado de de-normalización. • Si con la creación de diseños en copo de nieve pretendemos por ello ahorrar espacio de almacenamiento, hemos de tener en cuenta que las tablas de dimensiones, raramente representan mas del 10 % del total de almacenamiento del DWH, por lo que el ahorro no tendrá un impacto significativo, sin embargo si impactará en el rendimiento y, en la sencillez y comprensibilidad del modelo por parte de los usuarios. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 172. Modelado de datos para el DWH – Modelado dimensional © 2004 Database Team S.L © Hermes Romero tabla de marcas clave de marca nombre de la marca tabla de familias clave de familia nombre de la familia Tabla de productos clave de producto descripcion del producto clave de marca (FK) modelo clave de familia (FK) tipo de empaquetado tamaño empaquetado peso precio del producto DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 173. Modelado de datos para el DWH – Modelado dimensional o Las tablas de dimensiones son los puntos de entrada a las tablas de hechos. La definición de unos robustos atributos, nos traerá capacidades robustas para realizar operaciones de tipo “slice” y “dice”. Las dimensiones implementan el interfaz de usuario al DHW. © 2004 Database Team S.L © Hermes Romero  ...tablas de dimensiones DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 174. Modelado de datos para el DWH – Modelado dimensional dimensión tabla de tiendas clave de tienda provincia © 2004 Database Team S.L © Hermes Romero  Diseño en estrella (star join schema) dimensión tabla de fechas clave de fecha fecha mes dia año dimensión tabla de hechos ventas diarias clave de fecha (FK) clave de tienda (FK) clave de producto (FK) cantidad valor Tabla de productos clave de producto descripcion del producto modelo marca familia tipo de empaquetado tamaño empaquetado peso precio del producto DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 175. Modelado de datos para el DWH – Modelado dimensional o Al relacionar las tablas de hechos con las tablas de dimensiones nos da la impresión de que se dibuja una especie de estrella, donde el punto central es la tabla de hechos donde convergen todas las tablas de dimensiones. o Debido a esto este diseño es conocido como diseño en estrella o “star”, aunque este termino se acuño en los primeros días de los diseños relacionales. © 2004 Database Team S.L © Hermes Romero  Diseño en estrella (star join schema) DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 176. Modelado de datos para el DWH – Modelado dimensional 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). © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 177. Modelado de datos para el DWH – Modelado dimensional dimensión tabla de tiendas clave de tienda provincia clave de fecha (FK) clave de tienda (FK) clave de producto (FK) cantidad valor suma suma Mes Marca Provincia Importe de Ventas Cantidad Vendida Enero Orbea Madrid 4.598,00 € 3 Enero Marin Madrid 2.345,00 € 2 Enero Marin Sevilla 12.678,00 € 6 Febrero Specialized Madrid 2.346,00 € 1 Febrero Marin Madrid 1.235,00 € 1 Febrero Orbea Madrid 2.345,00 € 4 © 2004 Database Team S.L © Hermes Romero  Diseño en estrella o 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 tabla de fechas clave de fecha fecha mes dia año dimensión tabla de hechos ventas diarias Tabla de productos clave de producto descripcion del producto modelo marca familia tipo de empaquetado tamaño empaquetado peso precio del producto DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 178. Modelado de datos para el DWH – Modelado dimensional 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 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. © 2004 Database Team S.L © Hermes Romero  Diseño en “copo de nieve” (snowflake) o El modelo copo de nieve es el resultado de la jerárquica de las dimensiones muy bien. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 179. Modelado de datos para el DWH – Modelado dimensional © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 180. Modelado de datos para el DWH – Modelado dimensional • 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. © 2004 Database Team S.L © Hermes Romero o En definitiva no son aconsejables por: DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 181. Modelado de datos para el DWH – Modelado dimensional 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. © 2004 Database Team S.L © Hermes Romero  A evitar... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 182. Modelado de datos para el DWH – Modelado dimensional 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 o Cargar sólo datos sumarizados en las áreas de presentación 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 © 2004 Database Team S.L © Hermes Romero complejas con estructuras de datos complejas. dimensionales de los datos. aceptación por parte de los usuarios. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 183. Modelado de datos para el DWH – Modelado dimensional  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-detalle o Crear y poblar una dimensión de tiempo o Crear jerarquías de datos en las dimensiones o Considerar el uso de claves subrogadas sin sentido * © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 184. Modelado de datos para el DWH – Modelado dimensional  ¿cuál es la mejor herramienta para modelar datos para el © 2004 Database Team S.L © Hermes Romero DWH? o Tu cerebro DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 185. Modelado de datos para el DWH – Modelado dimensional productos codigo producto nombre producto fecha inicio fecha fin codigo familia nombre familia codigo subfamilia nombre subfamilia codigo marca nombre marca ancho alto peso cantidad por paquete © 2004 Database Team S.L © Hermes Romero  De-normalización o En nuestro ejemplo • La tabla de productos claramente viola la tercera norma formal: o Nombre de familia depende por completo de codigo de familia o Nombre de subfamilia depende por completo de codigo de subfamilia o Nombre marca depende por completo de codigo marca DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 186. Modelado de datos para el DWH – Modelado dimensional • Evidentemente al incumplir la 3ª norma formal nuestro diseño se encontrará en 2ª norma formal (las normas son acumulativas). Por tanto si se viola la tercera norma formal nos impide estar en normas formales superiores. • Si normalizaramos la tabla para cumplir la tercera norma formal entonces estaríamos creando un esquema en “copo de nieve” (snowflake), y como hemos visto anteriormente esto es altamente desaconsejable. • Si para evitar la de-normalización optamos por realizar vistas, estaremos en el mismo problema ya que las vistas no son más que consultas preescritas, que cuando se hace referencia a ellas se ejecutan, con el consiguiente coste de rendimiento. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 187. Modelado de datos para el DWH – Modelado dimensional o 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 • 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. © 2004 Database Team S.L © Hermes Romero  Consultas a esquemas en estrella mas tablas de dimensiones. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 188. Modelado de datos para el DWH – Modelado dimensional Mes Marca Provincia Importe de Ventas Cantidad Vendida Enero Orbea Madrid 4.598,00 € 3 Enero Marin Madrid 2.345,00 € 2 Enero Marin Sevilla 12.678,00 € 6 Febrero Specialized Madrid 2.346,00 € 1 Febrero Marin Madrid 1.235,00 € 1 Febrero Orbea Madrid 2.345,00 € 4 © 2004 Database Team S.L © 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.provincia DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 189. Modelado de datos para el DWH – Modelado dimensional o 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. © 2004 Database Team S.L © Hermes Romero  Modelado de fechas DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 190. Modelado de datos para el DWH – Modelado dimensional 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 © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 191. Modelado de datos para el DWH – Modelado dimensional © 2004 Database Team S.L © Hermes Romero • Ventas en fines de semana • Ventas en días festivos • Ventas Mensuales • Ventas Trimestrales • Ventas Cuatrimestrales • Ventas Semestrales • Ventas Anuales DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 192. Modelado de datos para el DWH – Modelado dimensional o 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). © 2004 Database Team S.L © Hermes Romero  Modelado de fechas DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 193. Modelado de datos para el DWH – Modelado dimensional dimensión tabla de tiendas clave de tienda tabla de hechos provincia © 2004 Database Team S.L © Hermes Romero dimensión Tabla de productos clave de producto descripcion del producto modelo marca familia tipo de empaquetado tamaño empaquetado peso precio del producto ventas diarias clave de tienda (FK) clave de producto (FK) fecha de venta cantidad valor DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 194. Modelado de datos para el DWH – Modelado dimensional o 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 (*): EXTRACT (MONTH FROM a.fecha_de_venta) AS mes, c.marca, FROM ventas_diarias a, tabla_de_productos c, tabla_de_tiendas AND a.clave_de_tienda = d.clave_de_tienda AND ( EXTRACT (MONTH FROM a.fecha_de_venta) = ‘enero’ OR EXTRACT (MONTH FROM a.fecha_de_venta) = ‘febrero’ ) © 2004 Database Team S.L © Hermes Romero  Modelado de fechas SELECT SUM (a.cantidad), SUM (a.valor), d.provincia d WHERE a.clave_de_producto = c.clave_de_producto AND (d.provincia = ‘madrid’ OR d.provincia = ‘sevilla’) GROUP BY EXTRACT (MONTH FROM a.fecha_de_venta), c.marca, d.provincia (*) La consulta incluye funciones específicas del gestor de Bases de Datos ORACLE DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 195. Modelado de datos para el DWH – Modelado dimensional © 2004 Database Team S.L © 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 a.clave_de_tienda = d.clave_de_tienda AND ( EXTRACT (MONTH FROM a.fecha_de_venta) = 'Enero' OR EXTRACT (MONTH FROM fecha_de_venta) = 'Febrero' ) AND (d.provincia = 'Madrid' OR d.provincia = 'Sevilla') GROUP BY EXTRACT (MONTH FROM a.fecha_de_venta), EXTRACT (YEAR FROM a.fecha_de_venta), c.marca, d.provincia DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 196. Modelado de datos para el DWH – Modelado dimensional 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: © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 197. Modelado de datos para el DWH – Modelado dimensional o 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. © 2004 Database Team S.L © Hermes Romero  Modelado de Fechas DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 198. Modelado de datos para el DWH – Modelado dimensional 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 Lunes, Martes, Miércoles, Jueves, Viernes, Sábado, Domingo. o Enero, Febrero, Marzo, Abril, Mayo, Junio, Julio, Agosto, © 2004 Database Team S.L © Hermes Romero o 12/12/2003 • Día de mes (numérico) o 1..31 • DIA de la semana (alfanumérico) • Número de mes (numérico) o 1..12 • Nombre Mes (alfanumérico) Septiembre,Octubre,Noviembre,Diciembre DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 199. Modelado de datos para el DWH – Modelado dimensional o Primer Trimestre, Segundo Trimestre, Tercer Trimestre, Cuarto o Primer Cuatrimestre, Segundo Cuatrimestre, Tercer Cuatrimestre © 2004 Database Team S.L © Hermes Romero • Número de Trimestre (numérico) o 1..4 • Nombre de trimestre (alfanumérico) Trimestre • Número de Cuatrimestre (numérico) o 1..3 • Nombre de Cuatrimestre (alfanumérico) • Número de Semestre (numérico) o 1,2 • Nombre de Semestre (alfanumérico) o Primer Semestre, Segundo Semestre DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 200. Modelado de datos para el DWH – Modelado dimensional © 2004 Database Team S.L © Hermes Romero • Año (Numérico) o ...1990,1991,1992,1993,1994... • Festivo (booleano/alfanumérico/numérico) o Si,No DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 201. Modelado de datos para el DWH – Modelado dimensional dimensión tabla de tiendas clave de tienda provincia © 2004 Database Team S.L © Hermes Romero dimensión tiempo clave de fecha dia dia de la semana mes nombre mes trimestre nombre trimestre cuatrimestre nombre cuatrimestre semestre nombre semestre anyo festivo  Modelado de Fechas dimensión Tabla de productos clave de producto descripcion del producto modelo marca familia tipo de empaquetado tamaño empaquetado peso precio del producto tabla de hechos ventas diarias clave de fecha (FK) clave de tienda (FK) clave de producto (FK) fecha de venta cantidad valor DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 202. Modelado de datos para el DWH – Modelado dimensional o En muchos casos se da la circunstancia de que determinados periodos de tiempo no coinciden plenamente con el calendario gregoriano, tal es el caso de 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.. © 2004 Database Team S.L © Hermes Romero  Modelado de fechas DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 203. Modelado de datos para el DWH – Modelado dimensional 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). • Periodo © 2004 Database Team S.L © Hermes Romero o 1..n • Nombre Periodo o .... • Ejercicio Fiscal o .... • Ejercicio comercial o .... DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 204. Modelado de datos para el DWH – Modelado dimensional © 2004 Database Team S.L © Hermes Romero • Temporada o Alta, baja o Invierno, verano, otoño, primavera o .... • Etc.. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 205. Modelado de datos para el DWH – Modelado dimensional Natural / Gregoriano Especifico de la empresa Septiembre Octubre Noviembre Diciembre Enero Febrero Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Enero Febrero Marzo 1 2 3 4 1 2 3 © 2004 Database Team S.L © Hermes Romero  Modelado de fechas Septiembre Octubre Noviembre Diciembre Enero Febrero Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Enero Febrero Marzo 2002 2003 2004 2003 2004 3 4 1 2 3 4 1 DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 206. Modelado de datos para el DWH – Modelado dimensional Natural / Gregoriano Especifico de una empresa de moda Septiembre Octubre Noviembre Diciembre Enero Febrero Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Enero Febrero Marzo 2003 2004 1 2 3 4 1 2 3 Otoño Invierno Primavera Verano Otoño Invierno Primavera © 2004 Database Team S.L © Hermes Romero  Modelado de Fechas Septiembre Octubre Noviembre Diciembre Enero Febrero Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Enero Febrero Marzo 2002 2003 2004 3 4 1 2 3 4 1 DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 207. Modelado de datos para el DWH – Modelado dimensional dimensión tabla de tiendas clave de tienda provincia © 2004 Database Team S.L © Hermes Romero dimensión tiempo clave de fecha dia dia de la semana mes nombre mes trimestre nombre trimestre cuatrimestre nombre cuatrimestre semestre nombre semestre anyo festivo quarter nombre quarter temporada ejercicio dimensión Tabla de productos clave de producto descripcion del producto modelo marca familia tipo de empaquetado tamaño empaquetado peso precio del producto tabla de hechos ventas diarias clave de fecha (FK) clave de tienda (FK) clave de producto (FK) fecha de venta cantidad valor DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 208. Modelado de datos para el DWH – Modelado dimensional o 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 o Valores nulos en una clave extranjera (Foreign Key) (FK) de o Valores nulos en los hechos (Facts) o Valores nulos en los atributos de las tablas de dimensiones. © 2004 Database Team S.L © Hermes Romero  Tratamiento de Valores Nulos encontrados en tres areas: la tabla de hechos (Fact). DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 209. Modelado de datos para el DWH – Modelado dimensional 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 • 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. © 2004 Database Team S.L © Hermes Romero diferentes razones: DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 210. Modelado de datos para el DWH – Modelado dimensional o El primero de los casos se da especialmente cuando la tabla de hechos se actualiza de manera acumulativa, ya que en este caso quedan relejados valores que 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 © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 211. Modelado de datos para el DWH – Modelado dimensional (WHERE pedidos.fecha_de_entrega = fechas.Fecha) condicionará el resultado y hará que estos pedidos no aparezcan. Para solucionar este problema es recomendable el uso de un valor especial tanto en la tabla de hechos como en la tabla de dimensión para identificar la ausencia de datos por ejemplo en el caso anterior se podría identificar con una fecha inoperativa como 1/1/9999 reflejando esta en la tabla de dimensión con una descripción como: ‘no asignada’, los efectos de esta solución darán satisfacción a los usuarios de los informes ya que en los informes no faltará información y todos los pedidos no entregados podrán ser agrupados en la fecha ‘no asignada’. Para el segundo y tercero de los casos se debe aplicar una solución similar © 2004 Database Team S.L © Hermes Romero a la anterior. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 212. Modelado de datos para el DWH – Modelado dimensional • 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. © 2004 Database Team S.L © Hermes Romero o Valores nulos en los hechos (facts) DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 213. Modelado de datos para el DWH – Modelado dimensional 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. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 214. Modelado de datos para el DWH – Modelado dimensional • Hay que tener en cuenta que las herramientas de explotación de los data warehouse, pueden dar tratamientos diferentes en cada caso a los valores nulos, independientemente de esto, es recomendable seguir las indicaciones anteriores para hacer de esta manera a nuestro diseño independiente de la herramienta o herramientas de explotación del data warehouse. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 215. 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. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 216. Visualización del modelo dimensional Aplicaciones OLAP  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 o 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. © 2004 Database Team S.L © Hermes Romero perspectivas multidimensionales DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 217. Visualización del modelo dimensional Aplicaciones OLAP  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. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 218. Visualización del modelo dimensional Aplicaciones OLAP  OLAP incluye datos de definición de datos (metadatos).  Realmente los cubos como tal no existen, los cubos se utilizan para representar o visualizar un modelo dimensional.  Podemos representar un modelo dimensional con tres dimensiones con un cubo (cube) tal como el de la figura, en cualquier caso lo habitual es tener modelos dimensionales con más de tres dimensiones, en ese caso su representación se realiza con cubos que reciben el nombre de hipercubos (hypercube). © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 219. Visualización del modelo dimensional Aplicaciones OLAP  En la figura podemos ver como se representan las cifras de volumen de ventas determinado por la combinación de tres dimensiones, tiempo, producto y provincia Segovia Volumen de ventas en función del tiempo, producto y provincia © 2004 Database Team S.L © Hermes Romero Granada Las Palmas Madrid 3200 1345 2567 1204 6709 150 245 245 245 340 150 240 267 120 789 356 1245 3789 2567 130 780 560 125 234 1235 370 Bicicletas Patines Balones Camisetas Mochilas Enero Febrero Marzo Abril Mayo DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 220. Visualización del modelo dimensional Aplicaciones OLAP • Existen cuatro tipos básicos de operaciones en OLAP para el análisis de • 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 • 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 © 2004 Database Team S.L © Hermes Romero  Operaciones básicas de OLAP datos. dimensiones. o Drill down y ­Roll up dinámica. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 221. Visualización del modelo dimensional Aplicaciones OLAP © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 222. Visualización del modelo dimensional Aplicaciones OLAP • 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. © 2004 Database Team S.L © Hermes Romero o Slice y Dice DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 223. Visualización del modelo dimensional Aplicaciones OLAP • La operación dice, rota el cubo hasta una nueva perspectiva, para que los usuarios puedan ver los datos desde diferentes perspectivas en su análisis de los datos. • Con estas operaciones el usuario que analiza la información, puede agruparla de una manera, analizarla, agruparla de otra y realizar otro análisis. Con las operaciones de slice y dice el usuario posee diferentes perspectivas para el análisis. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 224. Visualización del modelo dimensional Aplicaciones OLAP © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 225. Visualización del modelo dimensional Aplicaciones OLAP o El siguiente paso se basa en la elección del tipo de 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. © 2004 Database Team S.L © Hermes Romero  Implementación de OLAP almacenamiento del cubo OLAP. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 226. Visualización del modelo dimensional Aplicaciones OLAP 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. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 227. Visualización del modelo dimensional Aplicaciones OLAP  El almacenaje de los cubos de OLAP es una de las decisiones críticas que se han de tomar a la hora de diseñar el data warehouse. Es posible almacenar los cubos OLAP de tres maneras:  MOLAP  OLAP Multidimensional. En MOLAP, los datos de fuente y las agregaciones son almacenes en un formato multidimensional. MOLAP es la opción más rápida para la recuperación de datos, pero requiere de mucho espacio en disco, aunque en nuestros días esto no es un gran problema debido al bajo precio de almacenamiento. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 228. Visualización del modelo dimensional Aplicaciones OLAP  ROLAP  OLAP Relacional. Todos los datos, incluyendo las agregaciones se almacenan dentro de una estructura relacional de base de datos, que puede estar en la misma localización de la fuente o no. ROLAP es el método de almacenamiento mas lento en la recuperación de los datos. ROLAP tiene sentido en pequeños volúmenes de datos. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 229. Visualización del modelo dimensional Aplicaciones OLAP  HOLAP  OLAP Híbrido. HOLAP es una combinación de las anteriores (MOLAP,ROLAP). Las bases de datos HOLAP almacenan las agregaciones dentro de una estructura multidimensional, pero el almacenamiento de los mismos (pre-calculados) se produce de forma relacional. HOLAP ofrece las funcionalidades de MOLAP,pero, es tan lento como ROLAP. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 230. Visualización del modelo dimensional Aplicaciones OLAP  Debido a que los costes de hardware son cada vez mas bajos, MOLAP se presenta como la mejor opción siempre que sea posible el acceso a una base de datos o fuente MOLAP independiente. Por otro lado ROLAP es más conveniente en el caso de que el número de consultas sea reducido y el volumen de datos relativamente bajo. © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 231. Visualización del modelo dimensional Aplicaciones OLAP o 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. © 2004 Database Team S.L © Hermes Romero  Seguridad de OLAP DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 232. Visualización del modelo dimensional Aplicaciones OLAP Todos los empleados Mandos Intermedios Directivos Comité de dirección Permiso para acceder a cubos predefinidos, así como para realizar consultas OLAP ad-hoc sin límite © 2004 Database Team S.L © Hermes Romero Permisos para acceder a un número limitado de cubos predefinidos, dependiendo de las políticas de seguridad aplicables Permiso para acceder únicamente a cubos predefinidos DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 233.  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 diferentes o Pueden presentarse distintos orígenes de datos o Es normal realizar transformaciones y operaciones de cálculo sobre  El proceso de transformación y carga están condicionados por: © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH los orígenes de datos o Estructura de datos del sistema operacional o Estructura de datos del propio data warehouse. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 234.  Etapas del proceso de carga del data warehouse o En el proceso de carga del data warehouse por tanto podemos establecer tres etapas claramente diferenciadas: • Extracción • Transformación • Carga © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 235. o 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: © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH  Extracción • 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 DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 236. • 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) © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH o Extracción directa o Se realiza en horas valle o Días de poca actividad DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 237. 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. © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 238. 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 © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 239. • 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. © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH o Extracción asistida por aplicaciones DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 240. • 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 © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH optimizado de BBDD. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 241. • 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.. © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 242. • 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 eficiente o 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. © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 243. • 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. © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH o Extracción en un punto del tiempo DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 244. • 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. © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH o Extracción por comparación DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 245. En el siguiente cuadro se especifican las diferentes técnicas y su aplicación más adecuada para cada una de ellas: © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 246. o 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 o Ayudará a resolver las posibles anomalías de los datos en © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH  Transformación campos (mapping). origen o Ayudará a producir datos de alta calidad . DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 247. 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 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. © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH registro o bien a nivel de columna. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 248. o El proceso de carga es el encargado de recoger los datos previamente transformados y guardarlos en el data warehouse o data mart de destino. o Existen cuatro técnicas para el proceso de carga: © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH  Carga • Carga simple (load) • Añadir (append) • Mezcla constructiva (constructive merge) • Mezcla destructiva (destructive merge) DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 249. • 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. © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH o Carga simple (load) DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 250. • Añade los nuevos datos sobre los datos ya existentes en el destino, sin sustituir ni modificar ninguno de los existentes. © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH o Añadir (append) DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 251. 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. © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 252. o 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á: © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH  La importancia del modelo de datos • Los orígenes de los datos • Los intervalos de tiempo entre actualizaciones • El formato de los datos. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 253. 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. © 2004 Database Team S.L © Hermes Romero Carga de datos en el DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 254.  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”. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 255.  El ciclo de vida de desarrollo de sistemas • Se especifican los beneficios de implementar el sistema. • 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 © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH o Etapa 1 -- Viabilidad o Etapa 2 -- Definición de los requisitos DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 256. • 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 • El sistema se lleva a producción después de la aceptación del usuario final © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH o Etapa 3 – Diseño • Especificaciones de programación • Especificaciones de base de datos • Especificaciones de seguridad, etc... o Etapa 4 – Desarrollo o Etapa 5 – Implementación DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 257. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 258. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH  Fases del proyecto data warehouse DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 259.  Se definen 7 fases en la gestión de un proyecto de data warehouse o Requisitos o Diseño de la Arquitectura técnica o Selección del producto e instalación o Diseño del modelo dimensional o Diseño físico o Diseño y desarrollo del proceso de transformación y carga o Especificaciones de las aplicaciones de análisis e informes o Desarrollo de las aplicaciones de análisis e informes o Desarrollo e implementación o Mantenimiento © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 260. o 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. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH  Requisitos DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 261. • ¿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. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH o Preguntas típicas en un entrevista serían: DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 262. 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. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 263. o 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. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH  Diseño de la arquitectura técnica DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 264. 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 arquitectura 3. Documentar los requerimientos de arquitectura 4. Desarrollar un modelo de arquitectura a alto nivel 5. Diseñar y especificar los subsistemas dentro de la arquitectura 6. Determinar las fases de implementación de la arquitectura 7. Documentar la arquitectura técnica 8. Revisión y finalización de la arquitectura técnica © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 265. 1. El primer paso antes de seleccionar nuevos productos, es comprender el proceso de aprobación de compras interno de la compañía. 2. Desarrollar una matriz de evaluación de productos, que identifique los puntos clave de los productos, así como que asigne pesos a cada una de las capacidades a comparar dependiendo de nuestras necesidades. 3. Rastrear el mercado para localizar las posibles soluciones existentes y a 4. Ir estrechando la lista de productos candidatos y realizando 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 © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH  Selección del producto e instalación los proveedores. evaluaciones más detalladas. posibles proveedores. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 266. o 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. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH  Diseño del modelo dimensional DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 267. o 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. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH  Diseño físico DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 268. o Índice sobre la clave primara o Índices en “B-tree” en columnas usadas como FK con alta o Índices en “Bitmap” en columnas con media y baja cardinalidad. 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. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH o Los índices más recomendables son: • Sobre tablas de dimensiones: cardinalidad. • Sobre tablas de hechos: DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 269. 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.. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 270.  Diseño y desarrollo de los procesos de transformación y carga o 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. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 271.  Especificaciones de las aplicaciones analíticas y de informes o 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. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 272. Ciclo de vida del DWH  Desarrollo de las aplicaciones analíticas y de informes o Se realiza el desarrollo de las aplicaciones diseñadas en la © 2004 Database Team S.L © Hermes Romero fase anterior. DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 273. o 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. © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH  Desarrollo e implementación DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 274. o Finalmente en este estado se realizan las labores de: © 2004 Database Team S.L © Hermes Romero Ciclo de vida del DWH  Mantenimiento • Soporte a los usuarios • Formación continua • Soporte técnico • Monitorización DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com
  • 275. Http://hermesromero.com Hermes Romero hromero@db-team.com © 2004 Database Team S.L © Hermes Romero DATABASE TECHNOLOGIES & SERVICES www.hermesromero.com

×