P. 1
Cómo construir un datawarehouse

Cómo construir un datawarehouse

|Views: 347|Likes:
Publicado porssamael

More info:

Published by: ssamael on Nov 11, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

01/20/2014

pdf

text

original

Cómo no construir un datawarehouse

A través de TodoBI he encontrado un artículo muy interesante de Ralph Kimball (¿Algún despistado que no lo conoce?) donde detalla los 12 errores más comunes en la construcción de un datawarehouse. Se trata de un artículo excelente. Cada vez que he cometido alguno de estos errores, he tenido que rectificar al poco tiempo. No valen los atajos, hay que hacer las cosas bien desde el principio. Los doce errores más comunes en la construcción de un datawarehouse son:
           

Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar. Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido. Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones. Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes. Error 8: Crear “smart keys” para relacionar una tabla de dimensión con una tabla de hechos. Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad. Error 6: Crear un modelo dimensional para resolver un informe en particular. Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos. Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación. Error 3: Omitir las tablas agregadas y comprimir las tablas de dimensión para afrontar los problemas de rendimiento. Error 2: No unificar los hechos entre distintas tablas de hechos Error 1: No compartir dimensiones entre diferentes tablas de hechos.

En mi vida laboral he participado en la construcción de varios datawarehouses, y he visto muchos de estos errores. Durante los próximos días, analizaré una a una estas recomendaciones de Kimball, e intentaré justificar por que son errores graves y cómo debemos evitarlos. A mis lectores menos "tekies", os pido perdón porque los próximos mensajes no los escribo pensando en vosotros. Van dirigidos al lado oscuro... :-)

Datawarehouse

El datawarehouse (DWH) es una pieza básica, fundamental e indispensable de todo sistema Business Intelligence. Tal vez alguien no comparta la anterior afirmación, y crea que se puede construir un cuadro de mando, o un sistema de reporting, a partir de un datamart o unos cubitos. Perdónales, porque no saben lo que dicen... :-) La pieza fundamental de un sistema Business Intelligence es el DWH porque todos los listados y análisis que se hagan se harán a partir de esta única base de datos. En el DWH la información está limpia, unificada y verificada, y gracias a esto todo lo que hagamos después cuadrará. Tal como decía en mi anterior mensaje, voy a analizar los 12 errores más comunes que enumera el gurú Ralph Kimball. Tal como hace él, haré la cuenta regresiva del 12 al 1, aunque intentaré hacerlo en positivo, añadiendo ejemplos y experiencias personales, y explicando las bases sobre cómo construir un datawarehouse: Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intención de filtrar o agrupar. En un modelo dimensional se deben diferenciar claramente las tablas de hecho de las tablas de dimensiones.
 

Las tablas de hecho contienen los indicadores numéricos provenientes de los orígenes transaccionales. Las tablas de dimensión contienen los atributos (normalmente textuales) que nos permiten filtrar y agrupar los indicadores.

En ocasiones no es evidente si un dato es dimensional o si se trata de un indicador. Por ejemplo, la hora de la venta (hh:mm:ss) puede considerarse un dato mas del hecho de

podríamos considerar la matrícula como una especie de indicador e incluirlo en la tabla de hechos.venta (como el precio. regiones. por lo que muchas personas lo siguen denominando "atributo". Si el “dato” es compartido entre varias tablas de hecho. De esta manera. países. ni queremos analizarlo por las características del camión. se habla de la dimensión geográfica que agrupa los diferentes niveles de continentes. Hoy en día. Si no tenemos un maestro de los miles de camiones que utilizan nuestros transpostistas. ponlo siempre como una dimensión. . los gigas son baratos. "propiedad". "campo". y que por lo tanto ocuparían mucho espacio en disco y las consultas serían lentas por el IO generado. o las unidades vendidas). provincias y localidades. o una dimensión temporal muy detallada. devoluciones. o nombres de ciudades o personas) en las tablas de hecho. Algunas aplicaciones Business Intelligence utilizan el término "dimensión" como equivalente a "jerarquía" (especialmente en bases de datos multidimensionales). pero el tiempo para leerlos. El término "dimensión" sigue teniendo un cierta connotación técnica. … Dimensiones Denominamos dimensiones a aquellos datos que nos permiten filtrar. ventas. "característica". o incluso "cuadradito azul" (en el caso de una instalación de BO). quejas. Por ejemplo. agrupar o seccionar la información. no. que pueden tener cientos de millones de registros. un mismo cliente puede tener pedidos. O la matrícula del camión que subcontratamos para realizar los transportes. En caso de duda:   Evita colocar texto largos (como comentarios. Estos campos ocuparían un espacio precioso de nuestras tablas de hechos.

En particular. una cadena como Zara puede tener unas 5000 tiendas. Esta manera de actuar nunca me ha generado un problema. lo que nos lleva al error número 11 de nuestra serie: Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido.. (una causa de esto es que con una herramienta Business Intelligence raramente se ha de teclear un código. no debemos considerar el espacio como un aspecto determinante para modelizar las dimensiones. también las dimensiones de cliente o producto son despreciable frente a las ventas. De hecho. es sorprendente lo rápido que se acostumbran los usuarios a trabajar con las descripciones y lo rápido que se olvidan de los códigos con los que han trabajado toda la vida. y especialmente los nuevos empleados pueden tener dificultades para reconocerlos. y debe generar unos 3 o 4 millones de registros de venta diarios. Por lo tanto. Siempre son preferibles las descripciones. Personalmente. nadie los conoce todos. El espacio requerido por las tablas de dimensión es despreciable frente a lo que ocupan los hechos. prefiero reservar el término "dimension" para referirme a cada uno de los niveles de la jerarquía. En el modelo relacional del datawarehouse las dimensiones se almacenan en las "tablas de dimensión".Personalmente. los envíos o la producción diaria. Aunque algunos trabajadores pueden estar acostumbrados a trabajar con los códigos de familia. ya que se trabaja con clics de ratón y con listas de valores). Por ejemplo. . Incluso debemos plantearnos la necesidad real de introducir los códigos en la capa de presentación a los usuarios. Las dimensiones son la interfaz que tendrán los usuarios para navegar por la información. omito por defecto todos los códigos de la capa de presentación. En este y otros ejemplos que podríamos citar. cada código debe tener su descripción. las referencias o los códigos de proveedor.. por lo que conviene que sean lo más explícitas y claras posible. y sólo cuando algún usuario lo solicita explícitamente lo añado en el sistema.

En particular. Las jerarquías típicas. Una región está formada por varias provincias. es habitual la existencia de diferentes jerarquías de producto (lo que es una "pesadez" muchas veces necesaria. Modelo copo de nieve: Donde se crea una tabla para cada nivel de la jerarquía En la base de datos de presentación (también llamado modelo dimensional) del DWH debe preferirse siempre el modelo en estrella.Jerarquías Las dimensiones se agrupan en jerarquías mediante relaciones uno-a-muchos. otro día lo comentaré…). Es decir. que aparecen en cualquier sistema Business Intelligence. podemos cometer errores modelizando las jerarquías. Etcétera. Y. o incluso puede haber diferentes maneras de jerarquizar una misma información. Una provincia agrupa a muchas poblaciones. Esta manera de visualizar jerárquicamente la información resulta muy natural y cómoda para los usuarios de negocio. como siempre. debe crearse una única tabla para . Éste es el error número 10 de esta serie sobre cómo construir un datawarehouse: Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones Existen dos maneras principales de modelizar las jerarquías:   Modelo en estrella: Donde una única tabla contiene toda la información de la jerarquía. Una población agrupa a muchos clientes. pueden existir jerarquías adicionales. son:     Jerarquía geográfica o de clientes (país del cliente/región/ciudad/cliente) Jerarquía de producto (marca/familia/producto/presentación) Jerarquía comercial (país/zona/punto de venta) Jerarquía temporal (año/trimestre/mes/día) Evidentemente.

pero los objetivos de venta se marcan a nivel de "familia". marca). En este otro modelo. por lo que interesa que las consultas generadas sean sencillas (con pocas tablas y pocas relaciones). por desgracia. . es importante destacar que además del "modelo dimensional" el DWH debe mantener un modelo normalizado de la información (llamado "modelo relacional"). muchas herramientas BI exigirán la existencia de una tabla de FAMILIAS. desaparece el problema que generan las diferentes jerarquías en que se pueden agrupar los productos. Finalmente.cada jerarquía. La misma tabla de PRODUCTOS debe tener toda la información relativa a los productos (presentación. En este caso. Sin embargo. la información sí que debe estar normalizada. Por ejemplo. La herramienta de explotación puede requerir normalizar parte de una jerarquía en una tabla independiente. no siempre es posible tener un modelo en estrella perfecto. Además. familia. producto. unificada y limpia. las ventas están a nivel de "producto". El modelo en estrella es perfecto para conseguir este objetivo. El modelo dimensional es el que ataca nuestra herramienta de Business Intelligence. Esta limitación aparece cuando diferentes "hechos" están definidos con diferente granularidad.

deberemos considerar las ventas históricas de las tiendas que actualmente tiene asignado cada delegado. y que sus funciones fueron . La información de las dimensiones no es estática. existen casos donde la información dimensional histórica es importante. Análisis de márgenes: Si queremos analizar los descuentos que aplica cada delegado. Para conseguir este objetivo se introducen las "claves subrogadas".Dimensiones lentamente cambiantes En los anteriores comentarios de esta serie sobre cómo construir un datawarehouse. ¿Cómo debe gestionarse esta información? En primer lugar. en este ejemplo. que son identificadores sin ningún significado específico para el negocio. Por ejemplo. Por ejemplo. deberemos considerar las ventas de aquellas tiendas que han tenido asignadas a lo largo del tiempo. puede observarse que Pedro era el responsable de las delegaciones de Madrid y Barcelona. Sin embargo. explicaba las características de las dimensiones y las jerarquías. o éste puede cambiar de ciudad. etc. Considera estas dos situaciones: Previsión de ventas: Para realizar una previsión de ventas para el próximo año. lo habitual es trabajar con las "fechas de vigencia". ya que puede modificarse en el operacional por diferentes motivos. Aunque existen diferentes maneras de modelizar estos datos. esta sería la estructura de la tabla de DELEGACIONES en el modelo relacional: Ampliar imagen Analizando cuidadosamente los valores de esta tabla. puede corregirse la fecha de nacimiento de un cliente. o una delegación puede asignarse a un delegado diferente. debe tenerse en cuenta que el tratamiento que se realizará dependerá de cada dimensión y de las necesidades del negocio. deberemos modelizar la información de tal modo que seamos capaces de conocer el "delegado actual" y el "delegado/s histórico/s". Sin embargo. Por lo tanto. Por ejemplo. estaba omitiendo un aspecto principal de estas tablas. si se actualiza la fecha de nacimiento de un cliente se puede asumir que ese cambio aplica a toda la historia de ese cliente.

sólo publico la visión actual. En el modelo dimensional. la gestión de dimensiones lentamente cambiantes es imprescindible. No nos dejemos engañar. Sin embargo. o cualquier otra jerarquía. debe mantenerse toda la evolución de los cambios dimensionales. se trata de un tema complejo y que debe considerarse. En el DWH. En el modelo dimensional. es lo que siempre se ha hecho en el sistema operacional. De entrada. A pesar de todo esto. El usuario no siempre entiende la diferencia entre la "visión actual" y la "visión histórica". y con ello se pretende enfatizar que contiene:   Historia de los hechos: En el operacional existe registro de los "hechos" del negocio de los últimos meses o de unos pocos años. añado la visión histórica de esa dimensión. la tabla podría modelizarse de este modo: El sistema funcionaría de manera similar con cualquier otra dimensión que pudiese tener la jerarquía de delegaciones. Pues bien. de entrada. no parece importante (pero lo es). en el DWH se intenta que exista un histórico mucho mayor. Evidentemente. sin embargo. acostumbro a guardar toda la historia de las dimensiones en el modelo relacional (incluso algunos datos que inicialmente no parecen necesarios como la "fecha de nacimiento"). o caeríamos de lleno en el error número 9: Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes En cualquier definición del término datawarehouse se menciona que es un repositorio de información histórica. y sólo cuando lo solicita explícitamente el usuario de negocio. Y por lo tanto no sabe concretar sus necesidades reales. Al fin y al cabo.asumidas posteriormente por Juan y María. Personalmente. este segundo punto se suele olvidar (o ignorar) en algunas implantaciones de DWH por las siguientes razones:    La "visión actual" parece suficiente. Historia de las dimensiones: El operacional sólo suele guardar la situación actual de las dimensiones. La gestión de cambios en las dimensiones nunca aparece en los requerimientos que motivaron el proyecto. .

generalmente. por lo que cada código es . el código BCN puede utilizarse para referirse a Barcelona. o una persona con 9 bytes es un desperdicio considerable de espacio. Son siempre de tipo numérico. Una clave subrogada es un identificador único que se asigna a cada registro de una tabla de dimensión.Claves subrogadas En la anterior entrega de esta serie sobre cómo construir un datawarehouse ya introducía el concepto de las “claves subrogadas”. ¿Qué ocurriría si en el futuro se añade información de una aplicación que tiene su propio maestro de ciudades? Seguro que nos generará un problema. aparecerán ciudades que no existían en nuestro maestro…¿Cómo lo gestionaríamos? No sé. aunque suelen ser de tipo carácter y tienen un sentido específico para los empleados de la compañía. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto. De hecho. ocupa menos espacio un entero que una cadena. un entero autoincremental. no debe preocuparnos el espacio que ocupa. entonces. cada una de ellas con sus propias claves. o que siempre debería estar informada. ¿Qué pasará cuando llegue un empleado sin DNI? ¿Qué pasará cuando se de de alta una ciudad extranjera con el código BCN? Prefiero no saberlo. O el código de barras para referirse a un producto. sino el tiempo que se pierde en leerlo… Recordad que las claves subrogadas las llevaremos a las tablas de hechos. ¿Por qué necesitamos. por lo que es arriesgado asumir un código de alguna aplicación en particular. Puede ocurrir que cambie la lógica operacional de alguna clave que hubiésemos supuesto única. Esta clave. o el DNI de cada empleado puede ser la clave única de la tabla de empleados. Por ejemplo. Rendimiento. el sistema operacional ya utiliza sus propias claves. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto. El DWH suele alimentarse de diferentes fuentes. Preferiblemente. Cambios en las aplicaciones origen. En la base de datos. crear unos nuevos identificadores en el sistema Business Intelligence? Por varios motivos:    Fuentes heterogéneas. Identificar una ciudad con 5 bytes. Habitualmente. no tiene ningún sentido específico de negocio.

susceptible de repetirse cientos de millones de veces. también se pueden cometer errores al generar una clave subrogada… Error 8: Crear “smart keys” para relacionar una tabla de dimension con una tabla de hechos. Aunque en el operacional la terna país-CCAAciudad sea única. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto. en el DWH debemos crear una clave subrogada formada por un solo campo entero autoincremental. Conviene optimizarlo al máximo. si queremos crear una jerarquía de ciudades. Por supuesto. nos puede parecer útil aprovechar la lógica que subyace a los elementos para generar nuestras propias claves. Por ejemplo. . En ocasiones. Recuerda: Sustituye cualquier clave física por una clave entera numerada secuencialmente desde 1 hasta N. nunca debemos caer en la tentación de crear una simple concatenación (y generar el código ESP-CAT-BCN para referirnos a Barcelona)… También es un error crear una clave compuesta de varios campos.

En el anterior ejemplo. los envíos. La tabla de hechos contiene las claves subrogadas de aquellas dimensiones que definen su nivel de detalle. y debe determinarse el nivel de detalle de estos datos. Antes que nada. las reclamaciones. debe entenderse perfectamente el significado de estos indicadores. Una vez hecho esto. producto. las ventas están guardadas a nivel de cliente. la tabla de ventas es la tabla de hechos: Una característica importante de las tablas de hecho es el “nivel de detalle” de la información que se almacena. los pedidos.Tablas de hecho Denominamos “hechos” a los indicadores de negocio. debe localizarse el origen de la información que se quiere cargar. antes de crear la tabla de hechos debe entenderse perfectamente la información que se guardará. Por lo tanto. Es decir. etc. son todas aquellas medidas numéricas que incluiremos en nuestro sistema Business Intelligence. son “hechos” las ventas. Por ejemplo. la creación de la . almacén. Técnicamente. promoción y fecha. De hecho. Nada más. En el siguiente diagrama. una tabla de hecho es la tabla central de un modelo en estrella. o se estará cometiendo el error número 7 de esta serie sobre cómo construir un datawarehouse… Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad. y los indicadores. las compras. la creación de una tabla de hechos es una tarea con poco margen a la imaginación.

Resultaría redundante e impactaría directamente en el tamaño de la tabla (y en los tiempos de respuesta). Esta organización temática de la información facilita posteriormente la construcción de informes ad-hoc. En particular. time-variant and non-volatile collection of data in support of managements decision making process" (Bill Inmon. ya que permite obtener y cruzar información que se generó en procesos de negocio muy diferentes (aunque de una misma temática). donde la información está organizada por transacciones y procesos. Tal y como comentaba anteriormente:La tabla de hechos contiene las claves subrogadas de aquellas dimensiones que definen su nivel de detalle. Y nada menos. 1990) La organización temática de la información se refiere a que los datos que están cargados incluyen los indicadores relevantes de diferentes áreas de información de la compañía. es un error grave y frecuente el error número 6 de esta serie sobre cómo construir un datawarehouse Error 6: Crear un modelo dimensional para resolver un informe en particular. y los indicadores. Nada más. Además. integrated. es un error desnormalizar cualquier dimensión en la tabla de hechos. . y fue el quien introdujo esta característica en su definición: "A warehouse is a subject-oriented. si la información está a nivel de cliente. En particular. DWH organizado por temas Otra de las características importantes que debe tener un DWH es estar "organizado por temas" (subject-oriented).estructura de la tabla es inmediata. no necesitamos poner la población o el país en la tabla de hechos. Por ejemplo. deben poder cruzarse los indicadores relativos al mismo objeto o evento del mundo real. Modelizar adecuadamente la estructura del sistema Business Intelligence es fundamental para que posteriormente el usuario puede generarse cualquier informe que necesite. Bill Inmon es considerado uno de los padres del concepto DWH. Observad que esta manera de organizar la información es muy distinta de la existente en un sistema OLTP tradicional.

que el equipo de IT tuviese que adaptar el datawarehouse para cada informe necesario. Me explico: Esas reuniones son necesarias.Efectivamente. el modelo dimensional debe ser independiente de cualquier informe en particular. telecomunicaciones o banca es habitual encontrarse con datawarehouses con miles de millones de registros. conviene evitar que la aceptación del proyecto esté vinculada a la realización de unos informes en particular. y se hacen interminables reuniones con los usuarios de negocio con este objetivo. las ventas estarán detalladas por fecha. Un "product manager" puede estar interesado en los totales de venta de sus productos mes a mes. Sin embargo. si se trabaja con consultores externos. producto y punto de venta. existe el riesgo de que los esfuerzos se focalicen en la construcción de esos informes. y debe tener. No digas que no te lo advertí :-) Tablas agregadas El datawarehouse tiene. Es un error que puede costar muy caro. . por lo tanto. todo el detalle de información en su nivel atómico. Así. Una de las razones que habitualmente justifica la creación de un sistema Business Intelligece es la necesidad de otorgar a los usuarios la capacidad de realizar informes ad-hoc. la mayoría de consultas no necesitan acceder a tanto detalle. y no conocer particularidades intrascendentes de informes determinados. muchas veces he visto cómo se gastan demasiados esfuerzos en definir los informes que se necesitan. pero el objetivo debería ser entender los indicadores y los conceptos con los que trabajan los usuarios de negocio. Al iniciar un proyecto de datawarehouse. Rápidamente nos daremos cuenta que estaremos trabajando con un volumen muy importante de información. No tendría sentido. cuando lo correcto sería modelizar el DWH de tal forma que fuese viable consturir cualquier informe. en los sectores de distribución retail. cliente. En particular. Por poner algún ejemplo. Si esos son los términos de tu contrato.

Incluso con el uso de índices. lo que repercutiría directamente en el tiempo de respuesta y en el descontento de los usuarios. el operacional apunta el detalle y los totales en el mismo momento. sin necesidad de acceder a la tabla de ventas detalladas. he visto este tipo de tablas (que mezclan información a diferente nivel de detalle) en sistemas operacionales. estas consultas habituales deberían leer. Calcular los agregados en la misma tabla de ventas es un error muy grave e injustificable. La existencia de estas tablas agregadas debe ser completamente transparente para el usuario de negocio. De nada sirve crear muchos agregados si estos no se utilizan. En mi opinión. Por ejemplo. o por cliente. las consultas típicas del "product manager" o del "area manager" podrían ejecutarse en pocos segundos. Máximo nivel de detalle . Es decir. lo que no debe hacerse es lo que indica el error 5 de esta serie sobre cómo construir un datawarehouse: Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos. agrupar y sumar decenas de millones de registros. Aunque puede parece adecuado en algunas situaciones. o con una inversión millonaria en hardware. lo que obliga al técnico a crear modelos extraños. De esta manera. tanto el "area manager" como el "producto manager" trabajarán con el indicador "Ventas". la compresión de las tablas. las ventas podrían precalcularse a nivel mensual. y de esta manera los listados predefinidos del host se ejecutan de manera rápida y sencilla. De esta manera. Personalmente. será sin duda una fuente de problemas e incoherencias futuras. desde luego. y la herramienta Business Intelligence hará el resto. Recuerda: Cada "granularidad" requiere su propia tabla de hechos. Las tablas agregadas sumarizan los indicadores de las tablas de detalle a un nivel superior. evidentemente. o por producto. Este tipo de construcciones erróneas suelen aparecer ante la falta de funcionalidad de las herramientas BI.mientras que el "area manager" consulta habitualmente la evolución de ventas de sus zonas. Y. Es necesario conocer las consultas habituales de los usuarios. La solución ante estas situaciones pasa siempre para la preparación de tablas agregadas. donde resulta prohibitivo calcular los totales en el momento de generación del informe. todo esto es innecesario y contraproducente. En un entorno datawarehouse. lo más complicado es definir las tablas agregadas necesarias.

cualquier consulta posterior podrá resolverse en cualquier de las agrupaciones disponibles. . Modelo relacional: Es una base de datos donde la información se encuentra normalizada. En general. también debe tener todo o casi todo el detalle de información. cada venta. puede parecer suficiente ver las ventas diarias de cada familia. Es preferible un modelo en "copo de nieve" o incluso normalizado totalmente. Conozco las desventajas. dentro del DWH se distinguen tres áreas principales:    Área de staging: Que contiene las información bruta extraída de los sistemas operacionales. Y. Se prefiere el modelo en estrella. Y debemos asumirlas si queremos un datawarehouse que se útil para las necesidades actuales y para las necesidades futuras. Existen tablas agregadas. cada transacción. Contiene todo el detalle de información. Tal vez. El modelo dimensional está optimizado para conseguir un buen rendimiento. Modelo dimensional: Es la base de datos que utilizan las herramientas de Business Intelligence para obtener la información y hacer los informes o análisis. Y toda la historia posible. No hay tablas agregadas. Se debe guardar cada ticket. Soy consciente que el máximo nivel de detalle implica cargar muchos datos. El error 4 de esta serie sobre cómo construir un datawarehouse trata este asunto: Error 4: Olvidarse del máximo nivel de detalle en el modelo entidad-relación. ¿Pero y si luego quiero verlo por grupo social? ¿O por hora de venta? ¿O si lo quiero segmentar por precio de venta? ¿O por tipo de subfamilia? Sólo si inicialmente se diseñó y cargó el datawarehouse con la información detallada podrán contestarse estas preguntas. Si se dispone la información detallada. de entrada. y ya se han creado las claves subrogadas. en mi opinión. Ya. yo soy de los que cree firmemente que en el DWH debe estar disponible el máximo nivel de detalle de la información. sí. Es un área temporal donde los datos se preparan y normalizan antes de cargarse definitivamente en el DWH.Aunque existen varias opiniones al respecto. En este punto la información ya está limpia e integrada. lo que requiere tiempo de carga y espacio en disco. y hacerlo por triplicado.

ni en el modelo relacional. La respuesta está en todos los demás: Modeliza correctamente. y cuanto tiempo requiere cada consulta. y podrás mostrarlo cuando te des cuenta de que también lo necesitas en el modelo dimensional. Sólo disponiendo de un buen DWH podrá asegurarse la continuidad del proyecto BI. Si has llegado hasta esta página intentando resolver los problemas de rendimiento de tu sistema Business Intelligence. Personalmente. Todos los datawarehouse tienen un problema de rendimiento. ¿Cómo voy a proponer un DWH de 500Gb si el gerente sólo quiere 4 pantallitas para hacer el seguimiento mensual de un puñado de indicadores? En mi opinión. y el sistema funcionará como debe. En estos casos. Es más. Debemos conocer cuantas consultas se están ejecutando diariamente. lamento decirte que no encontrarás la respuesta en este post. ni en la staging. la falta de problemas de rendimiento suele esconder un problema mucho mayor y de más difícil solución… la falta de uso del sistema. Rendimiento En primer lugar. cargar todo el detalle puede parecer difícil de justificar. el máximo detalle no lo debemos dejar ni en el operacional. esta manera de trabajar sólo la cuestionan los consultores que han intervenido en excesivos proyectos de cuadro de mando. Sólo de esta manera el sistema Business Intelligence superará el ataque de las consultas ad-hoc. reconozcamos que tenemos un problema de rendimiento. Si hacemos esto. creo que la mejor estrategia para afrontar los problemas de lentitud pasa por monitorizar continuamente el sistema. Todo el detalle debe propagarse hasta el modelo dimensional. Recuerda: Por lo menos carga el máximo nivel de detalle en el modelo relacional. Es habitual que las empresas soliciten un cuadro de mando sin tener antes un datawarehouse ni un sistema de reporting aceptable. Ninguno va excesivamente rápido. Siempre se puede mejorar. Habitualmente.Efectivamente. hay que proponerlo. .

Si el sistema no está bien modelizado. La ampliación de hardware sólo puede justificarse ante un aumento del volumen de información a gestionar y/o en el número de usuarios del sistema. Para mejorar la situación. En primer lugar. estas 3 causas de problemas de rendimiento:    Dificultad de uso de la herramienta Business Intelligence. ante un problema de rendimiento. falta de índices. hubo un momento en el que 85 % de las consultas tardaban menos de 1 minuto. Menos del 1 % de las consultas seguían tardando más de 30 minutos. etc. También debo decir que el uso de tablas agregadas tiene un coste. Unificar los hechos .sabremos como de mal va el sistema. porque lo contrario sería señal de que dejaron de utilizar el sistema :-) Los problemas siempre son del software. lo que provoca consultas incorrectas o sin sentido por parte de los usuarios Modelización deficiente (falta de agregados. seguirá funcionando mal después de una ampliación de discos. del hardware. y reducen considerablemente el número de registros de la tabla detallada. Distingo. o del informático. Educando a los usuarios.) Hardware insuficiente (el sistema debe dimensionarse en función del volumen a información a gestionar y el número de usuarios activos) En particular. Afortunadamente. ya que son nuevos elementos que deberán mantenerse y actualizarse indefinidamente. que debe serlo). Las tablas agregadas sólo son útiles si efectivamente se usan. Las tablas agregadas añaden complejidad al sistema. de RAM o de CPU. y podremos fijarnos objetivos. En el último proyecto datawarehouse que he participado. seguíamos teniendo problemas de rendimiento. debe evitarse cometer el error número 3 de esta serie sobre cómo construir un datawarehouse: Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento. y sin embargo muchos usuarios se quejaban de la lentitud del sistema. pues. analizamos diariamente estas consultas… en ocasiones eran problemas en la manera de hacer las consultas por parte de los usuarios. y otras veces era un problemas de modelización. las tablas agregadas proporcionan una mejora inmediata (y en muchas ocasiones espectacular) en el rendimiento (siempre y cuando la herramienta de BI sea capaz de aprovecharse de estos agregados. El usuario nunca se equivoca. El 5% de las consultas tardaban más de 30 minutos. y con pequeños cambios en el modelo dimensional pudimos ofrecer una mejora significativa a los usuarios. deben considerarse mejoras en la modelización y descartar nuevas y caras inversiones en hardware. Efectivamente.

integrated. Para realizar esta unificación. en este ejemplo. dar la misma forma y el mismo significado a dimensiones y hechos aparentemente distintos (en inglés dicen "conform information"). las dos tablas de hechos deberán compartir las mismas dimensiones. Pues bien. integrarlos y conformarlos. Uno de los objetivos del DWH es unificar toda esa información dispersa en un único repositorio. porque sin duda existirán usuarios que querrán conocer la "facturación". cada uno de ellos con sus propios maestros y su propia información. como el autor de este blog de Business Intelligence en español) se señala que un DWH es un repositorio donde la información corporativa se encuentra "integrada". el objetivo es unificarlos. y deberán definirse con precisión los términos de cada negocio para que resulten agregables entre sí… Incluso. Por ejemplo. Sin embargo. A esta unificación se refiere el penúltimo error de esta serie sobre cómo construir un datawarehouse: . podría ser recomendable unificar los dos hechos en una misma tabla de hechos. time-variant and non-volatile collection of data in support of managements decision making process (Bill Inmon. Habitualmente. 1990) Efectivamente. una empresa de distribución puede tener dos canales de ventas a través de los cuales vende los mismos productos (venta al mayor y venta retail). Es muy diferente el negocio minorista del negocio mayorista. no se trata sólo de juntar todos estos datos. cualquier empresa tiene múltiples sistemas operacionales.En la definición de datawarehouse de Bill Inmon (y en todas las definiciones posteriores de cualquier menda aficionado al BI. donde la dimensión "tipo de venta" permitiese diferenciar las ventas al mayor de las ventas retail. es decir. y cada uno de ellos tendrá sus sistemas informáticos con diferencias significativas entre ellos. A warehouse is a subject-oriented. y la facturación evidentemente incluye las ventas al mayor y al ventas retail. uno de los retos de la creación del DWH sería la unificación de estos dos negocios. la gestión de estos dos negocios la realizarán personas diferentes de diferentes departamentos.

Es sólo un ejemplo tonto. Ahora hablaremos de unificar las dimensiones. No es más importante una cosa que la otra. deben incluirse también en las compras (aunque provengan de fuentes distintas). Si estos productos se incluyen en las ventas. olvidarnos de aquellos productos que sólo se venden por Internet o que forman parte de un negocio secundario de la compañía.Error 2: No unificar los hechos entre distintas tablas de hechos Tal como comentaba. por ejemplo. . estos deben tener la misma forma y deben haberse cargado aplicando los mismos criterios. estos deben tener la misma forma. Si se quiere calcular el cociente de ventas sobre compras. mientras que la aplicación de CRM puede estar utilizando los códigos "H" y "M". independientemente de que los hechos se modelicen en una o varias tablas de hechos. No debemos. pero es la realidad de todas las empresas. Deben tener dimensiones compartidas que permitan la comparación y/o agregación entre sí. Una función importante del DWH es la unificación de estas aplicaciones en unos maestros únicos. cada una de ellas con sus propios maestros. Sabemos que es normal que dentro de una compañía convivan muchas aplicaciones informáticas. Por ejemplo. Las dos son imprescindibles. la aplicación de recursos humanos puede utilizar los códigos "M" y "F" para indicar el sexo de los empleados. deberemos asegurarnos que en los dos indicadores se están considerando los mismos productos. Otro ejemplo de "conformar" adecuadamente los hechos sería aplicar los mismos criterios al cargar las compras y las ventas. Incluso puede haber diferencias entre los códigos de las tiendas y productos que utilizan las distintas aplicaciones o módulos del ERP. Unificar las dimensiones En la anterior entrada de esta serie sobre cómo construir un datawarehouse se describía la importancia de unificar los hechos. Si se quiere sumar o dividir la información de distintos hechos.

daremos mucha potencia y funcionalidad a los usuarios de negocio. por falta de tiempo y recursos. o cruzar información de distintos orígenes.En el DWH. Ni el nombre y los apellidos del cliente. se pueden cargar los diferentes maestros tal cual llegan de los distintos operacionales. . o una llamada al departamento de reclamaciones… Es importante identificar las personas entre distintos aplicativos. Si se realiza correctamente. Un caso especial. evidentemente. Se puede captar información de los clientes a partir de un formulario en la página web. para realizar el "matching" cuanto antes. ni siquiera el DNI son métodos fiables para detectar una misma persona en diferentes aplicaciones. Para identificar adecuadamente un cliente debe utilizarse una combinación de todos los anteriores e incluso puede ser necesaria la intervención manual. se refiere precisamente a este aspecto de la modelización: Error 1: No compartir dimensiones entre diferentes tablas de hechos. En el proceso de carga del datawarehouse. ni la dirección. Y un solo maestro de cualquier cosa. o un carnet de afiliación que solicita el cliente en la tienda. el equipo del DWH debe estar obsesionado por entender y unificar todos los maestros de la compañía. y podrá añadirse nueva información al sistema Business Intelligence de manera paulatina y harmoniosa. es el maestro de clientes. y muy problemático. y asignarles una única clave subrogada. debe existir un solo maestro de género. Y un solo maestro de tiendas. el mantenimiento del sistema será más sencillo. para realizar una identificación fiable resulta necesario modificar las aplicaciones orígen. Y un solo maestro de productos. el datawarehouse perderá mucha de su utilidad y sentido. ni el email. deben identificarse los códigos equivalentes. el más grave según Raplh Kimbal. Si no se realiza correctamente. Es un error muy grave. El primer error. y no suele considerarse una responsabilidad del modelizador del DWH. Las dimensiones compartidas entre diferentes hechos permiten navegar por la información. En todos los demás casos. Efectivamente. Existen herramientas y compañías especializadas en esta tarea. Normalmente.

el datawarehouse perderá mucha de su utilidad y sentido. .Si no se realiza correctamente.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->