UNIVERSIDAD SAN PEDRO

CARRERA 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
adaptacin especializada del
modelo relacional usada para
almacenar datos en
depsitos de datos, de modo
que los datos fcilmente
puedan ser extrados usando
consultas OLAP. En el modelo
dimensional, una base de
datos consiste en una sola

 ElModelo Dimensionales el nombre que se le

da a una tcnica utilizada especialmente en
Data Warehouses. Este modelo difiere bastante
del modelo Entidad-Relacin que normalmente
conocemos.
ElModelo Dimensionalbusca presentar la
informacin de una manera estndar, sencilla y
sobre todo intuitiva para los usuarios, adems
de que permite accesos a la informacin mucho
ms rpida por parte de los manejadores de
bases de datos.

Que es un Proceso de Negocio?

Unproceso de negocioes un conjunto de tareas

relacionadas lgicamente 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 funcin
pueda ser aplicada. Cuando una funcin es aplicada a las
entradas de un mtodo, tendremos ciertas salidas
Un
proceso de negocio puede ser parte de un proceso
resultantes.
mayor que lo abarque o bien puede incluir otros procesos
de negocio que deban ser incluidos en su funcin. En este
contexto un proceso de negocio puede ser visto a varios
niveles de granularidad.

LOS PROCESOS POSEEN LAS SIGUIENTES CARACTERSTICAS:

Pueden ser medidos y estn orientados al

rendimiento
Tienen resultados especficos
Entregan resultados a clientes o stakeholders
Responden a alguna accin o evento especfico
Las actividades deben agregar valor a las
entradas del
proceso.

Hay tres tipos de procesos de negocio:

1. Procesos estratgicos : Estos procesos dan orientacin
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 mercancas
3. Procesos de apoyo vertical u horizontal: Estos
procesos dan soporte
a los procesos centrales. Por
ejemplo, Registrar los hechos econmicos, Dar
Soporte/Servicio tcnico.

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 debera
ayudar a soportar filtros y agrupaciones impredecibles 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 podrn navegar y rotar la informacin. Si slo
hay disponible informacin 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 atmico 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 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 transforman 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

3: Asegrese de que toda tabla de hechos tiene una tabla de

dimensin tiempo asociada.
Los eventos mencionados en la regla 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.
4: Asegurarse que todos los hechos que estn 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 errneos.

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 puden 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.
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

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.
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

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.
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.