UNIVERSIDAD SAN PEDROCARRERA PROFECIONAL DE INGENIERIA INFORMATICA Y DE SISTEMAS

TRABAJO DEL CURSO DE INTELIGENCIA DE NEGOCIOS

TEMA:MODELO DIMENCIONAL DE UN PROCESO DE NEGOCIO

DOCENTE:FRANKLIN PEREZ URTEAGA

ALUMNOS PARTICIPANTES:VERA CABELLOS MILAGROS DEL PILAR

SAAVEDRA BAZAN MIGUEL ANGEL

Modelo Dimensional de un Proceso de Negocio

• ¿Qué es un Modelo Dimensional? 

El modelo dimensional es una adaptación especializada del modelo relacional usada para almacenar datos en depósitos de datos, de modo que los datos fácilmente puedan ser extraídos usando consultas OLAP. En el modelo dimensional, una base de datos consiste en una sola tabla grande de datos que son descritos usando dimensiones y medidas. 

• El Modelo Dimensional es el nombre que se le da a una técnica utilizada especialmente en Data Warehouses. Este modelo difiere bastante del modelo Entidad-Relación que normalmente conocemos.

• El Modelo Dimensional busca presentar la información de una manera estándar, sencilla y sobre todo intuitiva para los usuarios, además de que permite accesos a la información mucho más rápida por parte de los manejadores de bases de datos.

Que es un Proceso de Negocio?

• Un proceso de negocio es un conjunto de tareas relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio definido. Cada proceso de negocio tiene sus entradas, funciones y salidas. Las entradas son requisitos que deben tenerse antes de que una función pueda ser aplicada. Cuando una función es aplicada a las entradas de un método, tendremos ciertas salidas resultantes.• Un proceso de negocio puede ser parte de un proceso mayor que lo abarque o bien puede incluir otros procesos de negocio que deban ser incluidos en su función. En este contexto un proceso de negocio puede ser visto a varios niveles de granularidad. 

LOS PROCESOS POSEEN LAS SIGUIENTES CARACTERÍSTICAS:

•Pueden ser medidos y están orientados al rendimiento•Tienen resultados específicos•Entregan resultados a clientes o “stakeholders”•Responden a alguna acción o evento específico•Las actividades deben agregar valor a las entradas del proceso.

Hay tres tipos de procesos de negocio:

1. Procesos estratégicos : Estos procesos dan orientación al negocio. Por ejemplo, “Planeacion estrategica”, “Establecer objetivos y metas”.

2. Procesos sustantivos : Estos procesos dan el valor al cliente, son la parte principal del negocio. Por ejemplo, “Repartir mercancías”

3. Procesos de apoyo vertical u horizontal : Estos procesos dan soporte a los procesos centrales. Por ejemplo, “Registrar los hechos económicos”, “Dar Soporte/Servicio técnico”.

Condiciones para el Modelado Dimensional

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 detalle posible nos debería ayudar a soportar filtros y agrupaciones impredecibles requeridas por el usuario. Por lo general los usuarios no necesitan ver la información línea por línea, pero no se puede predecir las diferentes formas en que podrán navegar y rotar la información. Si sólo hay disponible información sumar izada, 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 atómico puede y debe ser complementado con modelos sumados para ganar eficiencia.

2: Estructurar los modelos dimensionales en torno a los procesos de negocio.

Los procesos de negocio son las actividades realizadas por la organización; los mismos representan eventos medibles, como tomar un pedido o facturarle a un cliente. Los procesos de negocios usualmente capturan o generan métricas de eficiencia asociadas con cada evento. Las métricas de transforman en hechos, con cada proceso de negocio representado por una tabla de hechos. Además de las tablas de hechos de procesos únicos, a veces son creadas tablas de hechos consolidadas que combinan métricas de varios procesos en una tabla de hecho con un nivel común de granularidad para todas. Pero recordemos que las tablas de hechos consolidadas son un complemento a las detalladas, pero no las sustituyen.

3: Asegúrese de que toda tabla de hechos tiene una tabla de dimensión tiempo asociada.

Los eventos mencionados en la regla 2 siempre están asociados a una fecha cierta, ya sea que se trate de un balance mensual o una transacción monetaria. Toda tabla de hechos siempre debe tener al menos una foreign key a una tabla de dimensión tiempo, cuya granularidad es la fecha única en que ocurrió el evento.

4: Asegurarse que todos los hechos que están en una misma fact 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 erróneos.

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 relación del tipo muchos a muchos (M:M) vinculada entre sus foreign keys, como por ejemplo productos vendidos en múltiples negocios en múltiples días. Estos campos de las foreign key nunca deberían ser nulos. A veces las dimensiones puden asumir múltiples valores para un hecho único, tal como muchos diagnósticos asociados con una consulta médica. En estos casos no es razonable resolver la dimensión de varios valores directamente en la tabla de hechos. Esto violaría la granularidad natural del hecho. Así, usaremos una relación muchos a muchos, con una tabla puente de clave doble en conjunto con la tabla de hechos.

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 común tener varias relaciones 1:M resueltas en una sola tabla de dimensión. Relaciones del tipo 1:1, como la descripción de un producto relacionada con el código del mismo, son también resueltas de esta forma.

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 guárdelos un tablas de dimensiones, y no en la tabla de hechos. Es aconsejable evitar valores nulos para los atributos de una tabla de dimensión, para estos casos complete los atributos nulos con el valor “NA” (Not Applicable), o algún otro valor por defecto.

8: Asegúrese que las dimensiones utilicen claves sustitutas (Surrogate Key)

La utilización de este tipo de claves nos darán una serie de beneficios como claves mas pequeñas, con lo cual las tablas de hechos serán más pequeñas, 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 dimensión. También permiten mapear códigos de diferentes fuentes operacionales, y además, nos protegen de cambios inesperados en los sistemas transaccionales, como la recodificación de tablas maestras, reciclado de códigos de productos que ya no existen, entre otros.

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 información de diferentes procesos de negocios. La reutilización de las dimensiones conformadas reduce el tiempo de salida al mercado mediante la eliminación de diseño redundante, sin embargo, estas dimensiones requerirán invertir en una buena administración de datos y en un modelo de gobernanza para las mismas.

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.

Gracias