ESCUELA ACADEMICO PROFESIONAL DE INGENIERIA DE SISTEMAS CURSO: INTELIGENCIA DE NEGOCIOS DOCENTE: ING.

REMBRANDT UBALDE TERCERA LECTURA 10 PRINCIPIOS ESENCIALES PARA EL MODELADO DIMENSIONAL EN INTELIGENCIA DE NEGOCIOS
Principio 1: En una estructura dimensional se deben cargar los datos con el mayor nivel de detalle posible. Llenar los modelos dimensionales con el mayor nivel de datalle posible nos debera ayudar a soportar filtros y agrupaciones inpredecibles requeridas por el usuario. Por lo general los usuarios no necesitan ver la informacin lnea por lnea, pero no se puede predecir las diferentes formas en que querrn navegar y rotar la informacin. Si slo hay disponible informacin sumarizada, uno puede estar asumiendo un modelo que cuando el usuario quiera ir a un nivel de profundidad mayor, no le resultar til. Por supuesto que el detalle atmico puede y debe ser complementado con modelos sumarizados para ganar eficiencia. Principio 2: Estructurar los modelos dimensionales en torno a los procesos de negocio. Los procesos de negocio son las actividades realizadas por la organizacin; los mismos representan eventos medibles, como tomar un pedido o facturarle a un cliente. Los procesos de negocios usualmente capturan o generan mtricas de eficiencia asociadas con cada evento. Las mtricas de tranforman en hechos, con cada proceso de negocio representado por una tabla de hechos. Adems de las tablas de hechos de procesos nicos, a veces son creadas tablas de hechos consolidadas que combinan mtricas de varios procesos en una tabla de hecho con un nivel comn de granularidad para todas. Pero recordemos que las tablas de hechos consolidadas son un complemento a las detalladas, pero no las sustituyen. Principio 3: Asegurarse de que toda tabla de hechos tiene una tabla de dimensin tiempo asociada. Los eventos mencionados en la Principio 2 siempre estn asociados a una fecha cierta, ya sea que se trate de un balance mensual o una transaccin monetaria. Toda tabla de hechos siempre debe tener al menos una foreign key a una tabla de dimensin tiempo, cuya granularidad es la fecha nica en que ocurri el evento. Principio 4: Asegurarse que todos los hechos que estn en una misma tabla de hechos tengan el mismo nivel de granularidad. Todas las medidas de una tabla de hechos deben estar al mismo nivel de detalle. Cuando uno mezcla hechos de diferentes niveles de granularidad en la misma tabla de hechos, se est llevando al usuario a confundirse y a hacer que las aplicaciones de BI arrojen resultados errneos. Principio 5: Resolver las relaciones muchos a muchos en las tablas de hechos. Partiendo de la base de que una tabla de hechos guarda los resultados de los eventos de un proceso de negocio, es muy probable que haya alguna relacin del tipo muchos a muchos (M:M) vinculada entre sus foreign keys, como por ejemplo productos vendidos en mltiples negocios en mltiples das. Estos campos de las foreign key nunca deberan ser nulos. A veces las dimensiones pueden asumir mltiples valores para un hecho nico, tal como muchos diagnsticos asociados con una consulta mdica. En estos casos no es razonable resolver la dimensin de varios valores directamente en la tabla de hechos. Esto violara la granularidad natural del hecho. As, usaremos una relacin muchos a muchos, con una tabla puente de clave doble en conjunto con la tabla de hechos.

Principio 6: Dimensiones con relaciones muchos a uno Por lo general este tipo de relaciones se suelen desnormalizar y aplanar en una tabla. Si usted se ha dedicado mucho tiempo a modelar sistemas transaccionales, evite tentarse a normalizar este tipo de dimensiones o modelarlas como copo de nieve (snowflake). Es muy comn tener varias relaciones 1:M resueltas en una sola tabla de dimensin. Relaciones del tipo 1:1, como la descripcin de un producto relacionada con el cdigo del mismo, son tambin resueltas de esta forma. Principio 7: Guarde en tablas de dimensiones aquellos atributos que utilizar como etiquetas o filtros de informes Todo tipo de atributos que crea que vaya a utilizar como etiquetas de reportes o como filtro de reportes gurdelos un tablas de dimensiones, y no en la tabla de hechos. Es aconsejable evitar valores nulos para los atributos de una tabla de dimensin, para estos casos complete los atributos nulos con el valor NA (Not Applicable), o algn otro valor por defecto. Principio 8: Asegrese que las dimensiones utilicen claves sustitutas (Surrogate Key) La utilizacin de este tipo de claves nos darn una serie de beneficios como claves mas pequeas, con lo cual las tablas de hechos sern ms pequeas, as como los ndices utilizados. generando mejor performance. El uso de surrogate keys ser til si quiere hacer un seguimiento de los cambios de los atributos de la dimensin. Tambin permiten mapear cdigos de diferentes fuentes operacionales, y adems, nos protegen de cambios inesperados en los sistemas transaccionales, como la recodificacin de tablas maestras, reciclado de cdigos de productos que ya no existen, entre otros. Principio 9: Cree dimensiones conformadas para integrar datos a lo largo de la empresa Las dimensiones conformadas son esenciales para un Data Warehouse corporativo. Administradas una sola vez en el ETL y utilizada en varias tablas de hechos, estas dimensiones proporcionan atributos consistentes a lo largo de diferentes modelos dimensionales y permiten hacer drill-across e integrar informacin de diferentes procesos de negocios. La reutilizacin de las dimensiones conformadas reduce el tiempo de salida al mercado mediante la eliminacin de diseo redundante, sin embargo, estas dimensiones requerirn invertir en una buena administracin de datos y en un modelo de gobernanza para las mismas. Principio 10: Balancear los requerimientos de los usuarios con los cambios a realizar en los modelos dimensionales. Los modelos dimensionales se extienden constantemente como consecuencia de los requerimientos que hace el negocio. Como encargado de mantener los diferentes modelos dimensionales, usted deber balancear entre los requerimientos del negocio y el impacto que este tenga sobre los modelos.