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.

Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir el espacio requerido.
Algunas aplicaciones Business Intelligence utilizan el término "dimensión" como equivalente a "jerarquía" (especialmente en bases de datos multidimensionales). De esta manera, se habla de la dimensión geográfica que agrupa los diferentes niveles de continentes, países, regiones, provincias y localidades.

Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones
Las dimensiones se agrupan en jerarquías mediante relaciones uno-a-muchos. Una población agrupa a muchos clientes. Una provincia agrupa a muchas poblaciones. Una región está formada por varias provincias. Etcétera. Las jerarquías típicas, que aparecen en cualquier sistema Business Intelligence, 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) Existen dos maneras principales de modelizar las jerarquías:

que son identificadores sin ningún significado específico para el negocio. etc. El modelo en estrella es perfecto para conseguir este objetivo. no siempre es posible tener un modelo en estrella perfecto. 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. Por ejemplo. marca). Sin embargo.Modelo en estrella: Donde una única tabla contiene toda la información de la jerarquía. En este otro modelo. familia. Finalmente. especialmente en entornos de Data Warehouse (DW) y Business Intelligence (BI). Por ejemplo. o una delegación puede asignarse a un delegado diferente. debe crearse una única tabla para cada jerarquía. Las Clave Subrogadas suelen utilizarse especialmente en tablas de dimensión versionadas o históricas. ya que puede modificarse en el operacional por diferentes motivos. El modelo dimensional es el que ataca nuestra herramienta de Business Intelligence. pero los objetivos de venta se marcan a nivel de "familia". por desgracia. por lo que interesa que las consultas generadas sean sencillas (con pocas tablas y pocas relaciones). producto. o éste puede cambiar de ciudad. unificada y limpia. puede corregirse la fecha de nacimiento de un cliente. . Esta limitación aparece cuando diferentes "hechos" están definidos con diferente granularidad. En este caso. es importante destacar que además del "modelo dimensional" el DWH debe mantener un modelo normalizado de la información (llamado "modelo relacional"). Aunque existen diferentes maneras de modelizar estos datos. Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes Dimensiones lentamente Cambiantes La información de las dimensiones no es estática. Es decir. La herramienta de explotación puede requerir normalizar parte de una jerarquía en una tabla independiente. desaparece el problema que generan las diferentes jerarquías en que se pueden agrupar los productos. la información sí que debe estar normalizada. ¿Cómo debe gestionarse esta información? se introducen las "claves subrogadas". muchas herramientas BI exigirán la existencia de una tabla de FAMILIAS. lo habitual es trabajar con las "fechas de vigencia" Las Claves Subrogadas (Surrogate Keys) es un concepto muy utilizado en el diseño de bases de datos. las ventas están a nivel de "producto". Además. La misma tabla de PRODUCTOS debe tener toda la información relativa a los productos (presentación.

si es posible realizar un seguimiento de cambios ilimitado. aunque si resulta posible que dichos cambios se produzcan. a las cuales se las denomina Tablas Slowly Changing Dimensions (SCD) o Tablas SCD. SCD Tipo 1. pues podremos . utilizan un campo como clave de acceso. Los cambios sobre los datos de la tabla. la Clave de Negocio podría ser la matrícula (o quizás el número de bastidor). el hecho de trabajar con Tablas Versionadas o Históricas (Slowly Changing Dimension de Tipo 2) impide que sea así. podríamos pensar que la Clave de Negocio contiene un valor único para cada fila de la base de datos. En entornos de Data Warehouse en condiciones. En un principio. este tipo de tablas suelen tratarse de tablas de Dimensión. tablas de dimensión que almacenan tanto los datos actuales (versión actual) como los datos históricos (versiones antiguas). Los cambios sobre los datos de la tabla. pues en caso contrario se suele utilizar tablas SCD de Tipo 2 (es lo suyo). manteniendo múltiples filas en la tabla para cada Clave de Negocio. el cual identificará de forma inequívoca a un elemento de negocio. la Clave de Negocio podría ser el Número de Póliza (un valor único para cada Póliza. sin embargo. una para las versiones actuales y otra para las versiones históricas). este tipo de tablas (tablas versionadas) pueden modelarse de diferentes formas (ej: utilizar dos tablas. las tablas SCD sólo se implementan en aquellos casos que el seguimiento de cambios no es relevante y/o no es frecuente. En entornos de Data Warehouse (DW) y Business Intelligence (BI). que tiene significado por sí mismo). es decir. Existen diferentes tipos de tablas Slowly Changing Dimension (SCD). para las cuales es posible que se produzcan modificaciones sobre sus datos a lo largo del tiempo. SCD Tipo 2 (Tablas Versionadas). que no se puede realizar un seguimiento de cambios. Si estuviéramos hablando de una tabla que almacena vehículos.conocidas como Slowly Changing Dimension (SCD) de tipo 2. y que en muchos casos tiene significado por sí mismo. son implementados con sentencias INSERT. Pongamos algunos ejemplos: Si estuviéramos hablando de una tabla que almacena Pólizas. En este caso. ¿Qué es una Tabla Versionada o Histórica (Slowly Changing Dimension de Tipo 2)? Habitualmente nos encontraremos con tablas de base de datos. de las cuales sólo una será la fila actual. de tal modo. aunque existen sistemas de gestión que modelan las tablas versionadas del mismo modo que se hace en un Data Warehouse. y además es necesario poder realizar un seguimiento de sus cambios a lo largo del tiempo. son implementados con sentencias UPDATE. es decir. En las bases de datos operacionales (OLTP). La mayoría de las tablas de base de datos con que trabajamos.

incluyendo todos los cambios sufridos a lo largo del tiempo sobre todas sus características (Tomador. para una empresa de seguros resultará vital poder realizar un seguimiento de una Póliza a lo largo de toda su historia. tanto la actual como una o varias versiones históricas) con el mismo valor de la Clave de Negocio (Business Key). En consecuencia. ya no podremos definir la Clave de Negocio como un campo único. Riesgos. En la práctica. ya que pueden existir múltiples filas (es decir. Capital Asegurado. Evidentemente. se podría hacer un INSERT con la información más actual (esto es algo más complicado. siempre que se realiza un cambio sobre la tabla. son implementados agregando nuevos campos a la tabla. En la práctica. si tenemos una tabla en la cual almacenamos una descripción que se repite para muchas filas. y una indexación más óptima (es preferible indexar datos numéricos que datos texto de gran longitud). como por ejemplo. almacenando en cada fila (es decir. incluyendo dos campos Fecha Desde y Fecha Hasta en la tabla). de forma totalmente independiente a los datos de negocio. es posible crear una Clave Subrogada en cualquier tabla (se trate de una Tabla Versionada o no). Garantías contratadas.). Un ejemplo de utilización de Claves Subrogadas sobre tablas no versionadas. . En consecuencia. aunque por el contrario se utilizarán múltiples campos. es bastante habitual encontrarse con tablas SCD de Tipo 2. aunque habitualmente resultan especialmente útiles al trabajar con Tablas Versionadas SCD de Tipo 2. es el caso de la denormalización. SCD Tipo 3. y dicho límite será impuesto por el número de campos utilizados para el seguimiento de cambios. no se utilizan múltiples filas. ¿Qué es una Clave Subrogada (Surrogate Key)? Una Clave Subrogada es un campo numérico de una tabla cuyo único requisito es almacenar un valor numérico único para cada fila de la tabla. Los cambios sobre los datos de la tabla. en cada versión) el periodo de tiempo para el cuál es válida la información de dicha fila de la base de datos (por ejemplo. claro . pero quiero explicarlo así por fines didácticos). es posible realizar un seguimiento limitado de los cambios. actuando como una clave sustituta. y en la tabla inicial sustituir dicha descripción por el valor numérico asociado. Es decir. es poco habitual encontrarse con tablas SCD de Tipo 3. Pero ¿Cómo podemos conseguirlo? Existen diferentes alternativas para implementar esta funcionalidad en el OLTP.insertar ilimitadas filas (salvo que nos quedemos sin espacio en disco. estamos hablando de una tabla de Slowly Changing Dimension (SCD) de Tipo 2. En consecuencia. En este caso. etc. de tal modo que para un campo que pueda cambiar. en vez de realizar un UPDATE (en cuyo caso perderíamos la información original).-). Volviendo al ejemplo de las Pólizas. múltiples versiones. Con esto habremos obtenido un menor tamaño de almacenamiento. se pueda utilizar un campo para el valor actual y otro campo para el valor anterior. que habitualmente no tiene significado por sí misma. es posible crear una nueva tabla que almacene los diferentes valores para dicha descripción asociados a un valor numérico único.

o una persona con 9 bytes es un desperdicio considerable de espacio. Por ejemplo. Rendimiento.Un ejemplo de utilización de Claves Subrogadas sobre tablas versionadas de un Data Warehouse (DW). Identificar una ciudad con 5 bytes. podemos tener una o varias tablas de hechos. los pedidos. Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad. cada una de ellas con sus propias claves. una tabla de hecho es la tabla central de un modelo en estrella. y otros datos asociados a la Póliza que pueden cambiar con el tiempo. los envíos. Puede ocurrir que cambie la lógica operacional de alguna clave que hubiésemos supuesto única. También es un error crear una clave compuesta de varios campos. las compras. por lo que es arriesgado asumir un código de alguna aplicación en particular. Aunque en el operacional la clave compuesta sea única. El DWH suele alimentarse de diferentes fuentes. no debe preocuparnos el espacio que ocupa. la tabla de ventas es la tabla de hechos: . son todas aquellas medidas numéricas que incluiremos en nuestro sistema Business Intelligence. Cambios en las aplicaciones origen. Es decir. en el DWH debemos crear una clave subrogada formada por un solo campo entero autoincremental. sino el tiempo que se pierde en leerlo… Por ejemplo. Denominamos “hechos” a los indicadores de negocio. en la cual almacenamos el Capital Asegurado de la Póliza. una nueva versión) en la tabla de Pólizas. la Provincia del Tomador. nunca debemos caer en la tentación de crear una simple concatenación. si queremos crear una jerarquía de ciudades. pudiendo ahora asociar las tablas de hechos con las Dimensiones (en particular. con la Dimensión Póliza) a través de la Clave Subrogada. y que en cada cambio generarán una nueva fila (es decir. En el siguiente diagrama. etc. como podría ser el ejemplo de Siniestros de las Pólizas o de Pagos de las Primas. una tabla Slowly Changing Dimension de Tipo 2) como pueda ser nuestro ejemplo de Pólizas. En la base de datos. De hecho. las reclamaciones. Error 8: Crear “smart keys” para relacionar una tabla de dimension con una tabla de hechos. Técnicamente. la versión correspondiente de la Póliza a la fecha correspondiente (ej: fecha de siniestro o fecha de prima). o que siempre debería estar informada. Esto nos permitirá poder asociar a cada Siniestro y/o a cada Prima (los ejemplos tomados). son “hechos” las ventas. ocupa menos espacio un entero que una cadena. De este modo. es el caso de tener una Tabla de Dimensión Versionada (es decir. Fuentes heterogéneas.

las ventas están guardadas a nivel de cliente. producto. Nada más. Estructura de Relación Padre-Hijo DataWareHouse . En el anterior ejemplo. almacén. y los indicadores.Una característica importante de las tablas de hecho es el “nivel de detalle” de la información que se almacena. La tabla de hechos contiene las claves subrogadas de aquellas dimensiones que definen su nivel de detalle. promoción y fecha.

las consultas típicas del "product manager" o del "area manager" podrían ejecutarse en pocos segundos. lo correcto sería modelizar el DWH de tal forma que fuese viable consturir cualquier informe. Sin embargo. mientras que el "area manager" consulta habitualmente la evolución de ventas de sus zonas. Por ejemplo. No tendría sentido. las ventas podrían precalcularse a nivel mensual.Error 6: Crear un modelo dimensional para resolver un informe en particular. . todo el detalle de información en su nivel atómico. Error 5: Mezclar hechos de diferente granularidad en una misma tabla de hechos. sin necesidad de acceder a la tabla de ventas detalladas. telecomunicaciones o banca es habitual encontrarse con datawarehouses con miles de millones de registros. producto y punto de venta. por lo tanto. De esta manera. Así. o por cliente. que el equipo de IT tuviese que adaptar el datawarehouse para cada informe necesario. La solución ante estas situaciones pasa siempre para la preparación de tablas agregadas. cliente. 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. Rápidamente nos daremos cuenta que estaremos trabajando con un volumen muy importante de información. Las tablas agregadas sumarizan los indicadores de las tablas de detalle a un nivel superior. las ventas estarán detalladas por fecha. Un "product manager" puede estar interesado en los totales de venta de sus productos mes a mes. el modelo dimensional debe ser independiente de cualquier informe en particular. la mayoría de consultas no necesitan acceder a tanto detalle. El datawarehouse tiene. o por producto. y debe tener. Cada "granularidad" requiere su propia tabla de hechos. en los sectores de distribución retail. Por poner algún ejemplo.

del hardware. En este punto la información ya está limpia e integrada. Es preferible un modelo en "copo de nieve" o incluso normalizado totalmente. Contiene todo el detalle de información. Todos los datawarehouse tienen un problema de rendimiento. y ya se han creado las claves subrogadas. Existen tablas agregadas. Distingo. y podrás mostrarlo cuando te des cuenta de que también lo necesitas en el modelo dimensional. Es un área temporal donde los datos se preparan y normalizan antes de cargarse definitivamente en el DWH. El modelo dimensional está optimizado para conseguir un buen rendimiento. El usuario nunca se equivoca. etc. Y toda la historia posible. En general. No hay tablas agregadas.) Hardware insuficiente (el sistema debe dimensionarse en función del volumen a información a gestionar y el número de usuarios activos) “Seguir teniendo problemas de rendimiento. Se prefiere el modelo en estrella. estas 3 causas de problemas de rendimiento: Dificultad de uso de la herramienta Business Intelligence. Recuerda: Por lo menos carga el máximo nivel de detalle en el modelo relacional. Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento.Error 4: Olvidarse del máximo nivel de detalle en el modelo entidadrelación. Modelo relacional: Es una base de datos donde la información se encuentra normalizada. Sólo disponiendo de un buen DWH podrá asegurarse la continuidad del proyecto BI. Los problemas siempre son del software. también debe tener todo o casi todo el detalle de información. falta de índices. dentro del DWH se distinguen tres áreas principales: Área de staging: Que contiene las información bruta extraída de los sistemas operacionales. 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. en mi opinión. o del informático. porque lo contrario sería señal de que dejaron de utilizar el sistema” . Y. pues. lo que provoca consultas incorrectas o sin sentido por parte de los usuarios Modelización deficiente (falta de agregados.

Por ejemplo. el objetivo es unificarlos. la gestión de estos dos negocios la realizarán personas diferentes de diferentes departamentos. estos deben tener la misma forma y deben haberse cargado aplicando los mismos criterios. Las tablas agregadas sólo son útiles si efectivamente se usan. y reducen considerablemente el número de registros de la tabla detallada. deberemos asegurarnos que en los dos indicadores se están considerando los mismos productos. Habitualmente. de RAM o de CPU. ya que son nuevos elementos que deberán mantenerse y actualizarse indefinidamente. Si se quiere sumar o dividir la información de distintos hechos. Es muy diferente el negocio minorista del negocio mayorista. 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). seguirá funcionando mal después de una ampliación de discos. no se trata sólo de juntar todos estos datos. por ejemplo. El uso de tablas agregadas tiene un coste. Las tablas agregadas añaden complejidad al sistema. y deberán definirse con precisión los términos de cada negocio para que resulten agregables entre sí… Incluso. podría ser recomendable unificar los dos hechos en una misma tabla de hechos. y la facturación evidentemente incluye las ventas al mayor y al ventas retail. olvidarnos de aquellos productos que sólo se venden por Internet o . deben considerarse mejoras en la modelización y descartar nuevas y caras inversiones en hardware.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. Sin embargo. uno de los retos de la creación del DWH sería la unificación de estos dos negocios. dar la misma forma y el mismo significado a dimensiones y hechos aparentemente distintos (en inglés dicen "conform information"). No debemos. Si el sistema no está bien modelizado. Para realizar esta unificación. Error 2: No unificar los hechos entre distintas tablas de hechos 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". Otro ejemplo de "conformar" adecuadamente los hechos sería aplicar los mismos criterios al cargar las compras y las ventas. Si se quiere calcular el cociente de ventas sobre compras. En primer lugar. donde la dimensión "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. las dos tablas de hechos deberán compartir las mismas dimensiones. Deben tener dimensiones compartidas que permitan la comparación y/o agregación entre sí. 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. y cada uno de ellos tendrá sus sistemas informáticos con diferencias significativas entre ellos. es decir. integrarlos y conformarlos. que debe serlo).

deben incluirse también en las compras (aunque provengan de fuentes distintas). deben identificarse los códigos equivalentes. Es sólo un ejemplo tonto. Por ejemplo. Los indicadores clave de desempeño son métricas financieras o no financieras. del inglés Key Performance Indicators. mientras que la aplicación de CRM puede estar utilizando los códigos "H" y "M". . utilizadas para cuantificar objetivos que reflejan el rendimiento de una organización. o cruzar información de distintos orígenes. KPIS KPI. Si no se realiza correctamente. Y un solo maestro de tiendas. y que generalmente se recogen en su plan estratégico. Es un error muy grave. Las dimensiones compartidas entre diferentes hechos permiten navegar por la información. En el DWH. por falta de tiempo y recursos. debe existir un solo maestro de género. de forma que se pueda alcanzar el objetivo fijado. o Indicadores Clave de Desempeño. cada una de ellas con sus propios maestros. Una función importante del DWH es la unificación de estas aplicaciones en unos maestros únicos. Y un solo maestro de cualquier cosa. el mantenimiento del sistema será más sencillo.que forman parte de un negocio secundario de la compañía. miden el nivel del desempeño de un proceso. Error 1: No compartir dimensiones entre diferentes tablas de hechos. y podrá añadirse nueva información al sistema Business Intelligence de manera paulatina y harmoniosa. Y un solo maestro de productos. daremos mucha potencia y funcionalidad a los usuarios de negocio. enfocándose en el "cómo" e indicando el rendimiento de los procesos. la aplicación de recursos humanos puede utilizar los códigos "M" y "F" para indicar el sexo de los empleados. el datawarehouse perderá mucha de su utilidad y sentido. se pueden cargar los diferentes maestros tal cual llegan de los distintos operacionales. pero es la realidad de todas las empresas. En el proceso de carga del datawarehouse. Si se realiza correctamente. Sabemos que es normal que dentro de una compañía convivan muchas aplicaciones informáticas. y asignarles una única clave subrogada. Incluso puede haber diferencias entre los códigos de las tiendas y productos que utilizan las distintas aplicaciones o módulos del ERP. Si estos productos se incluyen en las ventas. evidentemente.

Tiempo de mejoras de asuntos relacionados con los niveles de servicio. Los datos de los que dependen los KPI tienen que ser consistentes y correctos. Tener claros los objetivos/rendimiento requeridos en el proceso de negocio. Nivel de la satisfacción del cliente. Tener una medida cuantitativa/cualitativa de los resultados y que sea posible su comparación 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 acrónimo SMART. . Para una organización es necesario al menos que pueda identificar sus propios KPI's. Estos datos tienen que estar disponibles a tiempo.Usado para calcular. Impacto de la calidad de los recursos financieros adicionales necesarios para realizar el nivel de servicio definido. 2. 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. La clave para esto son: Tener predefinido de antemano un proceso de negocio. entre otros: Tiempo que se utiliza en mejorar los niveles de servicio en un proyecto dado.

Sign up to vote on this title
UsefulNot useful