Está en la página 1de 11

Error 12: Incluir atributos de texto en una tabla de hechos, si se hace con la intencin 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 numricos provenientes de los orgenes transaccionales. Las tablas de dimensin contienen los atributos (normalmente textuales) que nos permiten filtrar y agrupar los indicadores.

Error 11: Abreviar las descripciones en las tablas de dimensin con la intencin de reducir el espacio requerido.
Algunas aplicaciones Business Intelligence utilizan el trmino "dimensin" como equivalente a "jerarqua" (especialmente en bases de datos multidimensionales). De esta manera, se habla de la dimensin geogrfica que agrupa los diferentes niveles de continentes, pases, regiones, provincias y localidades.

Error 10: Dividir las jerarquas y los niveles de las jerarquas en mltiples dimensiones
Las dimensiones se agrupan en jerarquas mediante relaciones uno-a-muchos. Una poblacin agrupa a muchos clientes. Una provincia agrupa a muchas poblaciones. Una regin est formada por varias provincias. Etctera. Las jerarquas tpicas, que aparecen en cualquier sistema Business Intelligence, son: Jerarqua geogrfica o de clientes (pas del cliente/regin/ciudad/cliente) Jerarqua de producto (marca/familia/producto/presentacin) Jerarqua comercial (pas/zona/punto de venta) Jerarqua temporal (ao/trimestre/mes/da) Existen dos maneras principales de modelizar las jerarquas:

Modelo en estrella: Donde una nica tabla contiene toda la informacin de la jerarqua. Modelo copo de nieve: Donde se crea una tabla para cada nivel de la jerarqua En la base de datos de presentacin (tambin llamado modelo dimensional) del DWH debe preferirse siempre el modelo en estrella. Es decir, debe crearse una nica tabla para cada jerarqua. La misma tabla de PRODUCTOS debe tener toda la informacin relativa a los productos (presentacin, producto, familia, marca). El modelo dimensional es el que ataca nuestra herramienta de Business Intelligence, por lo que interesa que las consultas generadas sean sencillas (con pocas tablas y pocas relaciones). El modelo en estrella es perfecto para conseguir este objetivo. Adems, desaparece el problema que generan las diferentes jerarquas en que se pueden agrupar los productos. Sin embargo, por desgracia, no siempre es posible tener un modelo en estrella perfecto. La herramienta de explotacin puede requerir normalizar parte de una jerarqua en una tabla independiente. Esta limitacin aparece cuando diferentes "hechos" estn definidos con diferente granularidad. Por ejemplo, las ventas estn a nivel de "producto", pero los objetivos de venta se marcan a nivel de "familia". En este caso, muchas herramientas BI exigirn la existencia de una tabla de FAMILIAS. Finalmente, es importante destacar que adems del "modelo dimensional" el DWH debe mantener un modelo normalizado de la informacin (llamado "modelo relacional"). En este otro modelo, la informacin s que debe estar normalizada, unificada y limpia.

Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes


Dimensiones lentamente Cambiantes
La informacin de las dimensiones no es esttica, ya que puede modificarse en el operacional por diferentes motivos. Por ejemplo, puede corregirse la fecha de nacimiento de un cliente, o ste puede cambiar de ciudad, o una delegacin puede asignarse a un delegado diferente, etc. Cmo debe gestionarse esta informacin? se introducen las "claves subrogadas", que son identificadores sin ningn significado especfico para el negocio. Aunque existen diferentes maneras de modelizar estos datos, lo habitual es trabajar con las "fechas de vigencia" Las Claves Subrogadas (Surrogate Keys) es un concepto muy utilizado en el diseo de bases de datos, especialmente en entornos de Data Warehouse (DW) y Business Intelligence (BI). Las Clave Subrogadas suelen utilizarse especialmente en tablas de dimensin versionadas o histricas,

conocidas como Slowly Changing Dimension (SCD) de tipo 2, es decir, tablas de dimensin que almacenan tanto los datos actuales (versin actual) como los datos histricos (versiones antiguas).

La mayora de las tablas de base de datos con que trabajamos, utilizan un campo como clave de acceso, el cual identificar de forma inequvoca a un elemento de negocio, y que en muchos casos tiene significado por s mismo. Pongamos algunos ejemplos: Si estuviramos hablando de una tabla que almacena Plizas, la Clave de Negocio podra ser el Nmero de Pliza (un valor nico para cada Pliza, que tiene significado por s mismo). Si estuviramos hablando de una tabla que almacena vehculos, la Clave de Negocio podra ser la matrcula (o quizs el nmero de bastidor).
En un principio, podramos pensar que la Clave de Negocio contiene un valor nico para cada fila de la base de datos, sin embargo, el hecho de trabajar con Tablas Versionadas o Histricas (Slowly Changing Dimension de Tipo 2) impide que sea as.

Qu es una Tabla Versionada o Histrica (Slowly Changing Dimension de Tipo 2)?


Habitualmente nos encontraremos con tablas de base de datos, para las cuales es posible que se produzcan modificaciones sobre sus datos a lo largo del tiempo, y adems es necesario poder realizar un seguimiento de sus cambios a lo largo del tiempo. En entornos de Data Warehouse (DW) y Business Intelligence (BI), este tipo de tablas suelen tratarse de tablas de Dimensin, a las cuales se las denomina Tablas Slowly Changing Dimensions (SCD) o Tablas SCD. En las bases de datos operacionales (OLTP), este tipo de tablas (tablas versionadas) pueden modelarse de diferentes formas (ej: utilizar dos tablas, una para las versiones actuales y otra para las versiones histricas), aunque existen sistemas de gestin que modelan las tablas versionadas del mismo modo que se hace en un Data Warehouse. Existen diferentes tipos de tablas Slowly Changing Dimension (SCD), SCD Tipo 1. Los cambios sobre los datos de la tabla, son implementados con sentencias UPDATE, de tal modo, que no se puede realizar un seguimiento de cambios, aunque si resulta posible que dichos cambios se produzcan. En entornos de Data Warehouse en condiciones, las tablas SCD slo se implementan en aquellos casos que el seguimiento de cambios no es relevante y/o no es frecuente, pues en caso contrario se suele utilizar tablas SCD de Tipo 2 (es lo suyo). SCD Tipo 2 (Tablas Versionadas). Los cambios sobre los datos de la tabla, son implementados con sentencias INSERT, es decir, manteniendo mltiples filas en la tabla para cada Clave de Negocio, de las cuales slo una ser la fila actual. En este caso, si es posible realizar un seguimiento de cambios ilimitado, pues podremos

insertar ilimitadas filas (salvo que nos quedemos sin espacio en disco, claro ;-). En la prctica, es bastante habitual encontrarse con tablas SCD de Tipo 2. SCD Tipo 3. Los cambios sobre los datos de la tabla, son implementados agregando nuevos campos a la tabla, de tal modo que para un campo que pueda cambiar, se pueda utilizar un campo para el valor actual y otro campo para el valor anterior. En este caso, no se utilizan mltiples filas, aunque por el contrario se utilizarn mltiples campos. En consecuencia, es posible realizar un seguimiento limitado de los cambios, y dicho lmite ser impuesto por el nmero de campos utilizados para el seguimiento de cambios. En la prctica, es poco habitual encontrarse con tablas SCD de Tipo 3.
Volviendo al ejemplo de las Plizas, para una empresa de seguros resultar vital poder realizar un seguimiento de una Pliza a lo largo de toda su historia, incluyendo todos los cambios sufridos a lo largo del tiempo sobre todas sus caractersticas (Tomador, Riesgos, Garantas contratadas, Capital Asegurado, etc.). Pero Cmo podemos conseguirlo? Existen diferentes alternativas para implementar esta funcionalidad en el OLTP, como por ejemplo, siempre que se realiza un cambio sobre la tabla, en vez de realizar un UPDATE (en cuyo caso perderamos la informacin original), se podra hacer un INSERT con la informacin ms actual (esto es algo ms complicado, pero quiero explicarlo as por fines didcticos), almacenando en cada fila (es decir, en cada versin) el periodo de tiempo para el cul es vlida la informacin de dicha fila de la base de datos (por ejemplo, incluyendo dos campos Fecha Desde y Fecha Hasta en la tabla). Evidentemente, estamos hablando de una tabla de Slowly Changing Dimension (SCD) de Tipo 2. En consecuencia, ya no podremos definir la Clave de Negocio como un campo nico, ya que pueden existir mltiples filas (es decir, mltiples versiones, tanto la actual como una o varias versiones histricas) con el mismo valor de la Clave de Negocio (Business Key).

Qu es una Clave Subrogada (Surrogate Key)?


Una Clave Subrogada es un campo numrico de una tabla cuyo nico requisito es almacenar un valor numrico nico para cada fila de la tabla, actuando como una clave sustituta, de forma totalmente independiente a los datos de negocio, que habitualmente no tiene significado por s misma. En consecuencia, es posible crear una Clave Subrogada en cualquier tabla (se trate de una Tabla Versionada o no), aunque habitualmente resultan especialmente tiles al trabajar con Tablas Versionadas SCD de Tipo 2. Un ejemplo de utilizacin de Claves Subrogadas sobre tablas no versionadas, es el caso de la denormalizacin. Es decir, si tenemos una tabla en la cual almacenamos una descripcin que se repite para muchas filas, es posible crear una nueva tabla que almacene los diferentes valores para dicha descripcin asociados a un valor numrico nico, y en la tabla inicial sustituir dicha descripcin por el valor numrico asociado. Con esto habremos obtenido un menor tamao de almacenamiento, y una indexacin ms ptima (es preferible indexar datos numricos que datos texto de gran longitud).

Un ejemplo de utilizacin de Claves Subrogadas sobre tablas versionadas de un Data Warehouse (DW), es el caso de tener una Tabla de Dimensin Versionada (es decir, una tabla Slowly Changing Dimension de Tipo 2) como pueda ser nuestro ejemplo de Plizas, en la cual almacenamos el Capital Asegurado de la Pliza, la Provincia del Tomador, y otros datos asociados a la Pliza que pueden cambiar con el tiempo, y que en cada cambio generarn una nueva fila (es decir, una nueva versin) en la tabla de Plizas. De este modo, podemos tener una o varias tablas de hechos, como podra ser el ejemplo de Siniestros de las Plizas o de Pagos de las Primas, pudiendo ahora asociar las tablas de hechos con las Dimensiones (en particular, con la Dimensin Pliza) a travs de la Clave Subrogada. Esto nos permitir poder asociar a cada Siniestro y/o a cada Prima (los ejemplos tomados), la versin correspondiente de la Pliza a la fecha correspondiente (ej: fecha de siniestro o fecha de prima).

Error 8: Crear smart keys para relacionar una tabla de dimension con una tabla de hechos.
Fuentes heterogneas. El DWH suele alimentarse de diferentes fuentes, cada una de ellas con sus propias claves, por lo que es arriesgado asumir un cdigo de alguna aplicacin en particular. Cambios en las aplicaciones origen. Puede ocurrir que cambie la lgica operacional de alguna clave que hubisemos supuesto nica, o que siempre debera estar informada. Rendimiento. En la base de datos, ocupa menos espacio un entero que una cadena. Identificar una ciudad con 5 bytes, o una persona con 9 bytes es un desperdicio considerable de espacio. De hecho, no debe preocuparnos el espacio que ocupa, sino el tiempo que se pierde en leerlo Por ejemplo, si queremos crear una jerarqua de ciudades, nunca debemos caer en la tentacin de crear una simple concatenacin. Tambin es un error crear una clave compuesta de varios campos. Aunque en el operacional la clave compuesta sea nica, en el DWH debemos crear una clave subrogada formada por un solo campo entero autoincremental.

Error 7: Aadir dimensiones en una tabla de hechos antes de definir su granularidad.


Denominamos hechos a los indicadores de negocio. Por ejemplo, son hechos las ventas, los pedidos, los envos, las reclamaciones, las compras, etc. Es decir, son todas aquellas medidas numricas que incluiremos en nuestro sistema Business Intelligence. Tcnicamente, una tabla de hecho es la tabla central de un modelo en estrella. En el siguiente diagrama, la tabla de ventas es la tabla de hechos:

Una caracterstica importante de las tablas de hecho es el nivel de detalle de la informacin que se almacena. En el anterior ejemplo, las ventas estn guardadas a nivel de cliente, producto, almacn, promocin y fecha. La tabla de hechos contiene las claves subrogadas de aquellas dimensiones que definen su nivel de detalle, y los indicadores. Nada ms.

Estructura de Relacin Padre-Hijo DataWareHouse

Error 6: Crear un modelo dimensional para resolver un informe en particular.


el modelo dimensional debe ser independiente de cualquier informe en particular. Una de las razones que habitualmente justifica la creacin de un sistema Business Intelligece es la necesidad de otorgar a los usuarios la capacidad de realizar informes ad-hoc. No tendra sentido, por lo tanto, que el equipo de IT tuviese que adaptar el datawarehouse para cada informe necesario. lo correcto sera modelizar el DWH de tal forma que fuese viable consturir cualquier informe.

Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos.


Cada "granularidad" requiere su propia tabla de hechos.

El datawarehouse tiene, y debe tener, todo el detalle de informacin en su nivel atmico. As, las ventas estarn detalladas por fecha, cliente, producto y punto de venta. Rpidamente nos daremos cuenta que estaremos trabajando con un volumen muy importante de informacin. Por poner algn ejemplo, en los sectores de distribucin retail, telecomunicaciones o banca es habitual encontrarse con datawarehouses con miles de millones de registros. Sin embargo, la mayora de consultas no necesitan acceder a tanto detalle. Un "product manager" puede estar interesado en los totales de venta de sus productos mes a mes, mientras que el "area manager" consulta habitualmente la evolucin de ventas de sus zonas.
La solucin ante estas situaciones pasa siempre para la preparacin de tablas agregadas. Las tablas agregadas sumarizan los indicadores de las tablas de detalle a un nivel superior. Por ejemplo, las ventas podran precalcularse a nivel mensual, o por cliente, o por producto. De esta manera, las consultas tpicas del "product manager" o del "area manager" podran ejecutarse en pocos segundos, sin necesidad de acceder a la tabla de ventas detalladas.

Error 4: Olvidarse del mximo nivel de detalle en el modelo entidadrelacin.


En general, dentro del DWH se distinguen tres reas principales: rea de staging: Que contiene las informacin bruta extrada de los sistemas operacionales. Es un rea temporal donde los datos se preparan y normalizan antes de cargarse definitivamente en el DWH. Modelo relacional: Es una base de datos donde la informacin se encuentra normalizada. Contiene todo el detalle de informacin. Y toda la historia posible. No hay tablas agregadas. En este punto la informacin ya est limpia e integrada, y ya se han creado las claves subrogadas. Es preferible un modelo en "copo de nieve" o incluso normalizado totalmente. Modelo dimensional: Es la base de datos que utilizan las herramientas de Business Intelligence para obtener la informacin y hacer los informes o anlisis. El modelo dimensional est optimizado para conseguir un buen rendimiento. Existen tablas agregadas. Se prefiere el modelo en estrella. Y, en mi opinin, tambin debe tener todo o casi todo el detalle de informacin. Slo disponiendo de un buen DWH podr asegurarse la continuidad del proyecto BI. Recuerda: Por lo menos carga el mximo nivel de detalle en el modelo relacional, y podrs mostrarlo cuando te des cuenta de que tambin lo necesitas en el modelo dimensional.

Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento.
Todos los datawarehouse tienen un problema de rendimiento. Los problemas siempre son del software, del hardware, o del informtico. El usuario nunca se equivoca. Distingo, pues, estas 3 causas de problemas de rendimiento: Dificultad de uso de la herramienta Business Intelligence, lo que provoca consultas incorrectas o sin sentido por parte de los usuarios Modelizacin deficiente (falta de agregados, falta de ndices, etc.) Hardware insuficiente (el sistema debe dimensionarse en funcin del volumen a informacin a gestionar y el nmero de usuarios activos) Seguir teniendo problemas de rendimiento, porque lo contrario sera seal de que dejaron de utilizar el sistema

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, que debe serlo). En primer lugar, deben considerarse mejoras en la modelizacin y descartar nuevas y caras inversiones en hardware. Si el sistema no est bien modelizado, seguir funcionando mal despus de una ampliacin de discos, de RAM o de CPU. La ampliacin de hardware slo puede justificarse ante un aumento del volumen de informacin a gestionar y/o en el nmero de usuarios del sistema.
El uso de tablas agregadas tiene un coste. Las tablas agregadas aaden complejidad al sistema, ya que son nuevos elementos que debern mantenerse y actualizarse indefinidamente. Las tablas agregadas slo son tiles si efectivamente se usan, y reducen considerablemente el nmero de registros de la tabla detallada.

Error 2: No unificar los hechos entre distintas tablas de hechos


Uno de los objetivos del DWH es unificar toda esa informacin dispersa en un nico repositorio. Sin embargo, no se trata slo de juntar todos estos datos, el objetivo es unificarlos, integrarlos y conformarlos, es decir, dar la misma forma y el mismo significado a dimensiones y hechos aparentemente distintos (en ingls dicen "conform information"). Por ejemplo, una empresa de distribucin puede tener dos canales de ventas a travs de los cuales vende los mismos productos (venta al mayor y venta retail). Habitualmente, la gestin de estos dos negocios la realizarn personas diferentes de diferentes departamentos, y cada uno de ellos tendr sus sistemas informticos con diferencias significativas entre ellos. Es muy diferente el negocio minorista del negocio mayorista. uno de los retos de la creacin del DWH sera la unificacin de estos dos negocios, porque sin duda existirn usuarios que querrn conocer la "facturacin", y la facturacin evidentemente incluye las ventas al mayor y al ventas retail. Para realizar esta unificacin, las dos tablas de hechos debern compartir las mismas dimensiones, y debern definirse con precisin los trminos de cada negocio para que resulten agregables entre s Incluso, podra ser recomendable unificar los dos hechos en una misma tabla de hechos, donde la dimensin "tipo de venta" permitiese diferenciar las ventas al mayor de las ventas retail. independientemente de que los hechos se modelicen en una o varias tablas de hechos, estos deben tener la misma forma. Deben tener dimensiones compartidas que permitan la comparacin y/o agregacin entre s. Si se quiere sumar o dividir la informacin de distintos hechos, estos deben tener la misma forma y deben haberse cargado aplicando los mismos criterios. Otro ejemplo de "conformar" adecuadamente los hechos sera aplicar los mismos criterios al cargar las compras y las ventas. Si se quiere calcular el cociente de ventas sobre compras, deberemos asegurarnos que en los dos indicadores se estn considerando los mismos productos. No debemos, por ejemplo, olvidarnos de aquellos productos que slo se venden por Internet o

que forman parte de un negocio secundario de la compaa. Si estos productos se incluyen en las ventas, deben incluirse tambin en las compras (aunque provengan de fuentes distintas).

Error 1: No compartir dimensiones entre diferentes tablas de hechos.


Sabemos que es normal que dentro de una compaa convivan muchas aplicaciones informticas, cada una de ellas con sus propios maestros. Una funcin importante del DWH es la unificacin de estas aplicaciones en unos maestros nicos. Por ejemplo, la aplicacin de recursos humanos puede utilizar los cdigos "M" y "F" para indicar el sexo de los empleados, mientras que la aplicacin de CRM puede estar utilizando los cdigos "H" y "M". Es slo un ejemplo tonto, pero es la realidad de todas las empresas. Incluso puede haber diferencias entre los cdigos de las tiendas y productos que utilizan las distintas aplicaciones o mdulos del ERP. En el DWH, evidentemente, debe existir un solo maestro de gnero. Y un solo maestro de tiendas. Y un solo maestro de productos. Y un solo maestro de cualquier cosa. En el proceso de carga del datawarehouse, deben identificarse los cdigos equivalentes, y asignarles una nica clave subrogada.

por falta de tiempo y recursos, se pueden cargar los diferentes maestros tal cual llegan de los distintos operacionales. Es un error muy grave. Las dimensiones compartidas entre diferentes hechos permiten navegar por la informacin, o cruzar informacin de distintos orgenes. Si se realiza correctamente, daremos mucha potencia y funcionalidad a los usuarios de negocio, el mantenimiento del sistema ser ms sencillo, y podr aadirse nueva informacin al sistema Business Intelligence de manera paulatina y harmoniosa. Si no se realiza correctamente, el datawarehouse perder mucha de su utilidad y sentido.

KPIS
KPI, del ingls Key Performance Indicators, o Indicadores Clave de Desempeo, miden el nivel del desempeo de un proceso, enfocndose en el "cmo" e indicando el rendimiento de los procesos, de forma que se pueda alcanzar el objetivo fijado. Los indicadores clave de desempeo son mtricas financieras o no financieras, utilizadas para cuantificar objetivos que reflejan el rendimiento de una organizacin, y que generalmente se recogen en su plan estratgico.

Usado para calcular, entre otros: Tiempo que se utiliza en mejorar los niveles de servicio en un proyecto dado. Nivel de la satisfaccin del cliente. Tiempo de mejoras de asuntos relacionados con los niveles de servicio. Impacto de la calidad de los recursos financieros adicionales necesarios para realizar el nivel de servicio definido. Para una organizacin es necesario al menos que pueda identificar sus propios KPI's. La clave para esto son: Tener predefinido de antemano un proceso de negocio. Tener claros los objetivos/rendimiento requeridos en el proceso de negocio. Tener una medida cuantitativa/cualitativa de los resultados y que sea posible su comparacin con los objetivos. Investigar variaciones y ajustar procesos o recursos para alcanzar metas a corto plazo Cuando se definen KPI's se suele aplicar el acrnimo SMART, ya que los KPI's tienen que ser: eSpecificos (Specific) Medibles (Measurable) Alcanzables (Achievable) Realista (Realistic) a Tiempo (Timely) Lo que realmente es importante: 1. Los datos de los que dependen los KPI tienen que ser consistentes y correctos. 2. Estos datos tienen que estar disponibles a tiempo.