DATA WAREHOUSE

La pieza fundamental de un sistema BI es el DWH

Porque todos los listados y anlisis que se hagan se harn a partir de esta
nica base de datos. En el DWH la informacin est limpia, unificada y
verificada, y gracias a esto todo lo que hagamos despus ser conforme y
preciso. Aunque algunos no compartan la anterior afirmacin, y crea n que se
puede construir un DASHBOARD, o un sistema de REPORTING, a partir de un
DATAMART o unos cubos, estn equivocados si lo que se quiere hacer es algo
coherente con el plan estratgico de la empresa.

Creo una segunda base de datos o trabajo sobre la B.D. del ERP ?

Un DWH es una base de datos con fines analticos. En ese sentido, la propia
base de datos del ERP podra actuar como una especie de DWH ... pero eso casi
nunca es lo habitual ni lo recomendable. Al hablar de DWH se entiende que
hablamos de una rplica de los datos del ERP con una estructura de datos
distinta y en una base de datos distinta.

Que herramientas utilizo para la creacin y gesti n de la B.D. del DWH?

Para montar ese DWH se puede hacer manualmente usando (T-SQL, PL-SQL,
entre otros) o utilizar alguna de las soluciones ETL existentes (SSIS, etc.). Es
decir:

Se puede utilizar la misma herramienta que incluyen algunos productos

BI para realizar los procesos ETL.
La otra es montar el DWH mediante sistemas como SQL ANALYSIS
SERVICES y SQL INTEGRATION SERVICES (bases de datos relacionales),
independientemente de las herramientas de explotacin que se piensan
utilizar. Un DWH bien diseado debe poder funcionar con cualquier
herramienta de explotacin BI. Esta es la opcin ms recomendable,
porque de esta manera el DWH ser independiente de las soluciones BI.
 DIMENSIONES

Denominamos dimensiones a aquellos datos que nos permiten filtrar, agrupar

o seccionar la informacin. El trmino "dimensin" sigue teniendo un cierta
connotacin tcnica, por lo que muchas personas lo siguen denominando
"atributo", "caracterstica", "propiedad", "campo", o incluso "cuadrad ito azul"
(en el caso de una instalacin de BO). En el modelo relacional del DWH las
dimensiones se almacenan en las "tablas de dimensin".

Algunas aplicaciones BI utilizan el trmino "dimensin" como equivalente a

"jerarqua" (especialmente en bases de da tos multidimensionales). De esta
manera, se habla de la dimensin geogrfica que agrupa los diferentes niveles
de continentes, pases, regiones, provincias y localidades. Preferiblemente se
debe reservar el trmino "dimensin" para referirnos a cada uno de los niveles
de una jerarqua.

JERARQUAS

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 cualqui er sistema BI, son:

Jerarqua geogrfica o de clientes (pas/regin/ciudad/cliente)

Jerarqua de producto (marca/familia/producto/presentacin)
Jerarqua comercial (pas/zona/punto de venta)
Jerarqua temporal (ao/trimestre/mes/da)

Evidentemente, pueden existir jerarquas adicionales, o incluso puede haber

diferentes maneras de jerarquizar una misma informacin. En particular, es
habitual la existencia de diferentes jerarquas de producto. Esta manera de
visualizar jerrquicamente la informacin resulta muy natural y cmoda para
los usuarios de negocio.

Los doce errores ms comunes en la construccin de un DWH son:

 Hay errores que se deben evitar, o rectificar al poco tiempo. Para la creacin
de un DWH no valen los atajos, hay que hacer las cosas bien desde el
principio. Segn RALPH KIMBALL estos son los errores ms comunes:

1) No se deben 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.

L as t ab la s d e he c ho c on ti en en los i nd i ca do re s n um r i co s pro ve n ie nt es d e
l o s or g en es tra ns acc i on al es .
L as ta b las de d im ens i n co nt i en en lo s a tr i bu tos (n or ma lm en t e t e xt ua le s)
q u e nos pe rm i te n fi lt ra r y a gr up ar l os ind i c ado re s.
Podemos hacer la siguiente asociacin:
o Hechos= tablas de movimientos del ERP,
o Dimensiones= tablas maestras del ERP

En ocasiones no es evidente si un dato es dimensional o si se t rata de un

indicador. Por ejemplo, la hora de la venta (hh:mm:ss) puede considerarse un
dato ms del hecho de venta (como el precio, o las unidades vendidas), o una
dimensin temporal muy detallada. O la matrcula del camin que
subcontratamos para realizar los transportes. Si no tenemos un maestro de los
miles de camiones que utilizan nuestros transportistas, ni queremos analizarlo
por las caractersticas del camin, podramos considerar la matrcula como una
especie de indicador e incluirlo en la tabla de hechos.

En caso de duda:

E v i ta co l oc ar te x to l ar go s ( co mo c om en ta r ios , o no mb re s d e c iu da de s o
p er so nas ) en l as tab la s d e h e ch o. E s to s ca mp os o cu pa ra n un e spa c io
p re c io so de nu es t ra s t ab la s d e h e ch os , qu e p ue de n t ene r c ie nt os de
m i l lo ne s de re g is tro s, y q ue p or lo t an to o c up ar an mu ch o es pa c io en
d i s co y l as con su l ta s se r an le n tas p or e l IO g en era do . Hoy en d a , l os
g i ga s so n bar at os , pe ro e l ti em po p ara le e rl os , no.
S i e l da to es co mp ar t ido en tr e v ar ia s t ab la s d e h ec ho , po n lo s i em pre
c o mo una d im en si n . P o r e j em pl o, un m i sm o cl i en te pu ede t en er pe d ido s,
v en ta s, de vo lu c io nes , q ue ja s,

2) No se deben abreviar las descripciones en las tablas de dimensin

con la intencin de reducir el espacio requerido.
El espacio requerido por las tablas de dimensin es despreciable frente a lo
que ocupan los hechos. Por ejemplo, una cadena como Zara puede tener unas
5000 tiendas, y debe generar unos 3 o 4 millones de registros de venta diarios.
En este y otros ejemplos que podramos citar, tambin las dimensiones de
cliente o producto son despreciables frente a las ventas, los envos o la
produccin diaria.

Por lo tanto, no debemos considerar el espacio como un aspecto determinante

para modelar las dimensiones. En particular, cada cdigo debe tener su
descripcin. Las dimensiones son la interfaz que tendrn los usuarios para
navegar por la informacin, por lo que conviene que sean lo ms explcitas y
claras posible.

Incluso debemos plantearnos la necesidad real de introducir los cdigos en la

capa de presentacin a los usuarios. Aunque algunos trabajadores pueden
estar acostumbrados a trabajar con los cdigos de las referencias o los
cdigos de proveedor, nadie los conoce todos, y especialmente los nuevos
empleados pueden tener dificultades para reconocerlos. Siempre son
preferibles las descripciones.

Aunque algunos omiten por defecto todos los cdigos en la capa de

presentacin, slo cuando algn usuario lo solicita explcitamente lo aaden
en el sistema. Esta manera de actuar nunca ha generado problemas. De hecho,
es sorprendente lo rpido que se acostumbran los usuarios a trabajar con las
descripciones y lo rpido que se olvidan de los cdigos con los que han
trabajado toda la vida. (Una causa de esto es que con una herramienta BI
raramente se ha de teclear un cdigo, ya que se trabaja con clic de ratn y con
listas de valores).

3) No se debe Dividir las jerarquas y los niveles de las jerarquas en

mltiples dimensiones.
Tipos de repositorios de B.D. para los modelos dimensionales:

DWH y Sistemas OLAP Para realizar consultas de naturaleza estratgicas.

La data se estructura por temas.
Sistemas OLTP Contiene informacin transaccional, se pueden realizar
consultas tcticas y operativas. La data se estructura por funcin o aplicacin.

Requisitos del proceso de negocio

Requisitos del proceso de negocio - Procesos del Negocio (Unidad de anlisis Ej.
clientes, ganancias, ventas, datos de pedido, productos, etc., no son departamentos de
la organizacin Son actividades relacionadas se crea una lista de procesos
candidatos y se ordenan de acuerdo al inters de negocio y debe priorizar los
requisitos) modelos dimensionales (uno o ms modelos dimensionales por proceso
Dos modelos dimensionales no deben redundar los mismos datos).

Metadatos de un proceso de negocio - modelo dimensional (para identificar):

Requisitos empresariales del negocio seleccionado para el que disear el

modelo dimensional
Procesos de negocio
Propietarios
Sistemas de origen que se utilizarn
Problemas de calidad de los datos
Trminos comunes utilizados en los procesos de negocio
Otros metadatos relacionados con el negocio.

Pasos a seguir con los requisitos empresariales (despus de Identificados):

1. Cree y estudie la lista de procesos de negocio de empresa.

Una nica lista de procesos para toda la empresa. Considerando los siguientes
factores de asesoramiento:

Complejidad de los sistemas de origen de cada proceso de negocio

Disponibilidad de datos de estos sistemas
Calidad de datos de estos sistemas
Significado de negocio estratgico de cada proceso de negocio
Otros factores importantes para los procesos de negocio
Consejo: Puede ser til asignar valores a cada factor de asesoramiento y proceso
de negocio. Cuando asigne valores, puede determinar la prioridad de cada proceso
de negocio.

2. Identifique el proceso de negocio que desea modelar.

 Los procesos ms significativos (mayor prioridad) para el negocio deben
modelarse primero. Van a quedar procesos con menor viabilidad para crearles un
modelo dimensional.

3. Identifique las entidades y medidas de alto nivel que son comunes en diversos
procesos.

Determine las entidades empresariales de alto nivel implicadas en cada proceso.

Determine qu entidades son comunes en varios procesos de negocio. Una vez
identificadas las entidades comunes, puede unir los procesos de negocio a travs
de estas dimensiones comunes (compartidas).

Para crear dimensiones compartidas que se puedan utilizar en toda la empresa,

debe asegurarse de que las distintas partes del negocio estn de acuerdo con las
definiciones de estas entidades comunes. Este proceso puede tardar algn tiempo,
ya que las definiciones de las entidades comunes pueden varias entrar las
distintas partes del negocio. Debe definir las entidades comunes inicialmente, ya
que si necesita cambiar esta definicin en el futuro, las aplicaciones existentes
pueden resultar afectadas.

Un DWH debe proporcionar informacin coherente para todas las consultas de

diferentes departamentos que solicitan informacin similar. Un mtodo para
mantener la coherencia es crear tablas de dimensiones compartidas y utilizarlas
por todas las aplicaciones y todos los modelos dimensionales. Los candidatos para
las dimensiones compartidas incluyen clientes, tiempo, productos y dimensiones
geogrficas, como por ejemplo la dimensin de almacenamiento.

El desarrollo de un conjunto de dimensiones compartidas es un reto importante.

Las dimensiones comunes en los procesos de negocio deben representar la
informacin sobre dimensiones de la misma manera. Es decir, se debe compartir
la informacin y los datos subyacentes. Generalmente, cada proceso de negocio
tiene su propio esquema que contiene una tabla de hechos, varias tablas de
dimensiones compartidas y tablas de dimensiones exclusivas de la funcin de
negocio especfica.

4. Identifique los orgenes de datos.

Identifique los orgenes de datos implicados en los procesos de negocio. Un modelo

dimensional se crea a partir de uno de los siguientes orgenes:

Un DWH para toda la empresa

 Sistemas de origen OLTP (en el caso de las arquitecturas de despensa de
datos independientes o dependientes)
DWH independientes o DATAMART (en esta situacin, quiz le interese
consolidar los DATAMART en un nico DWH).

5. Seleccione el mtodo de recopilacin de requisitos.

Los requisitos suelen ser difciles de definir. Generalmente, slo despus de ver un
resultado se puede decidir que el resultado cumple (o no) un requisito. Los
requisitos de una organizacin tambin cambian a lo largo del tiempo. Lo que es
vlido un da puede no serlo al da siguiente. A pesar de ello, los requisitos
identificados en este punto se utilizan en el ciclo de desarrollo para crear el
modelo dimensional.

Las preguntas son:

Cmo puede crear algo que no se puede definir de forma precisa?

Cmo sabe cundo ha identificado correctamente los requisitos?
Aunque no hay ninguna prueba definitiva, generalmente puede empezar el
proceso de modelado si sus requisitos incluyen las siguientes preguntas:

Para reunir el conjunto completo de requisitos, debe considerar las siguientes

preguntas:

Quines son las personas, los grupos y las organizaciones de inters?

Qu funciones deben analizarse?
Por qu son necesarios los datos?
Cundo deben registrarse los datos?
Dnde, a nivel geogrfico y organizativo, se producen los procesos
relevantes?
Cmo se mide el rendimiento de las funciones?
Cmo se mide el rendimiento del proceso de negocio? Qu factores
determinan el xito o el fracaso?
Cul es el mtodo de distribucin de la informacin? Es un informe de
datos por escrito o por correo electrnico, o se trata de otro mtodo?
Qu tipos de informacin faltan para realizar el anlisis y la toma de
decisiones?
Qu pasos se han llevado a cabo actualmente para satisfacer la falta de
informacin?
Qu nivel de detalle habilitara el anlisis de datos?
En general, la mayora de los mtodos para derivar requisitos empresariales
cumplen uno de estos dos mtodos: controlado por origen y controlado por
usuario.
Controlado por origen

La recopilacin de requisitos controlados por origen se basa en definir los

requisitos utilizando los datos de origen en los sistemas operacionales de
produccin. Puede definir los requisitos analizando un modelo de datos de
origen si hay un disponible o los diseos de registro fsico reales y
seleccionando los datos de inters.

La principal ventaja de este mtodo es que le permite saber desde el principio

que puede proporcionar todos los datos, dado que ya se limita a lo que hay
disponible. Una segunda ventaja es que puede minimizar el tiempo que
necesitan los usuarios en las fases iniciales del proyecto. No obstante, nada
puede sustituir la importancia y el valor que obtiene cuando implica a los
usuarios.

Este mtodo tambin tiene desventajas:

Al minimizar la implicacin de los usuarios, aumenta el riesgo de

producir un conjunto incorrecto de requisitos.
Segn el volumen de los datos de origen de que disponga y de la
disponibilidad de los modelos de origen para los datos, este mtodo
tambin puede tardar mucho tiempo.
Es posible que algunos usuarios necesiten acceder a datos no disponibles
actualmente.
Sin la oportunidad de identificar todos los requisitos, no es posible investigar
qu es necesario para obtener datos externos. Los datos externos son datos
que existen fuera de la empresa. An as, los datos externos con frecuencia
pueden tener un valor significativo para los usuarios de negocio.

El resultado del mtodo controlado por origen es proporcionar lo datos de que

dispone, lo que es apropiado en al menos dos casos:

El mtodo se puede utilizar para desarrollar una lista bastante completa

de las dimensiones principales de inters para la empresa. Si tiene
previsto crear un depsito de datos para toda la empresa, esto puede
minimizar la proliferacin de dimensiones duplicadas en las despensas
de datos desarrolladas independientemente.
El anlisis de relaciones en los datos de origen puede identificar reas en
las que centrar sus esfuerzos de desarrollo de un depsito de datos.

Controlado por usuario

La recopilacin de requisitos controlados por usuario es un mtodo basado en

definir los requisitos investigando las funciones realizadas por los usuarios. Esto
 se suele llevar a cabo a travs de una serie de reuniones o entrevistas con los
usuarios.

La ventaja principal de este mtodo se basa en proporcionar los datos

realmente necesarios, no los que estn disponibles. En general, este mtodo
tiene un mbito inferior al mtodo controlado por origen. Por lo tanto, el
mtodo controlado por usuario generalmente produce un depsito de datos o
una despensa de datos til en un lapso de tiempo ms corto.

Sin embargo, las expectativas se deben gestionar detenidamente. Los usuarios

deben comprender claramente que algunos de los datos que necesitan no
pueden ponerse a su disposicin por diversas razones. No obstante, no debe
limitar las preguntas que realicen los usuarios. Cuando defina los requisitos de
un depsito de datos, deben fomentarse ideas alternativas. Estos requisitos
impiden que elimine requisitos simplemente porque crea que no sean posibles.
Si un usuario est demasiado centrado en algo, puede pasar por alto datos
tiles que estn disponibles en los sistemas de produccin.

La recopilacin de requisitos controlados por usuario generalmente es el

mtodo elegido, especialmente cuando se desarrollan despensas de datos
dependientes o se llenan despensas de datos desde un almacn de empresa de
todo el negocio.

6. Rena los requisitos del modelo dimensional .

Cuando rena los requisitos, las necesidades de los usuarios de negocio se

recopilarn y documentarn. Cuando rena los requisitos, debe estudiar los
procesos de negocio y las actividades del anlisis de informacin con las que se
relacionan los usuarios. Generalmente, los usuarios tienen que evaluar o
analizar algn aspecto del negocio. Centre sus esfuerzos en recopilar los dos
elementos clave de anlisis con los que se relacionan los usuarios de negocio
diariamente:

Qu es lo que se analiza?
Cules son los criterios de evaluacin?
Cuando rena los requisitos, debe tratar de comprender el dominio del
problema para el que se realiza el modelado. Generalmente, los requisitos en
esta fase se documentan informalmente y los esquemas no se detallan en su
totalidad. Cuando rena estos requisitos, identifique las siguientes reas de
inters:
 Identifique las cuestiones ms importantes que debe tratar el negocio.
Puede asignar valores de importancia a cada cuestin para determinar
las cuestiones ms importantes que se deben abordar.
Determine cmo desea el negocio registrar los datos cuando estos
cambian. Por ejemplo, desear saber cmo gestionar los datos
histricos de los productos que ya no estn disponibles o de los
registros de los empleados.

7. Analice los requisitos del modelo dimensional .

Analice los requisitos empresariales. Determine los requisitos informales y

establezca medidas y entidades de alto nivel. Estos objetos pueden
convertirse en dimensiones cuando modele los datos. Utilice este borrador
como punto de partida para filtrar las entidades y medidas. Puede empezar a
trazar la estructura de los requisitos, las dimensiones del trazado, las
jerarquas y las medidas de cada parte del modelo de datos.

8. Resuma el anlisis del proceso de negocio.

Cree un informe a partir del anlisis. El informe debe contener la siguiente

informacin:

Listado de procesos de negocio

Priorizacin de procesos de negocio
Entidades y medidas de alto nivel, que son comunes entre varios
procesos de negocio
Proceso de negocio identificado para el que se crear el modelo
dimensional
Listado de orgenes de datos
Recopilacin de requisitos que contiene todos los requisitos del
proceso de negocio
Anlisis de recopilacin de requisitos
Entidades y medidas de alto nivel identificadas a partir del anlisis de
requisitos
 Paso 2: Identificar el grano (Nivel de detalle de los datos a
almacenar)

Identifique la granularidad de cada tabla de hechos y proceso de negocio. Durante este

proceso deber identificar los tipos de tablas de hechos y los candidatos
preliminares para las dimensiones y medidas.
La lista siguiente contiene varias caractersticas de identificacin del grano:
Especificar qu contienen los registros
Al identificar el grano, se especifica exactamente qu contiene un registro de tabla de
hechos. El grano muestra el nivel de detalle asociado a las medidas de la tabla de
hechos. Cuando identifique el grano, decida tambin el nivel de detalle que desea que
est disponible en el modelo dimensional. Si se incluyen ms detalles, el nivel de
granularidad ser ms bajo. Si se incluyen menos detalles, el nivel de granularidad
ser ms alto.
Identificar el nivel de detalle
El nivel de detalle disponible en un esquema de estrella se conoce como grano. Cada
tabla de hechos y dimensiones tiene su propio grano o granularidad. Cada tabla (de
hechos o dimensiones) contiene un nivel de detalle con el que se asocia. El grano del
modelo dimensional es el nivel de detalle ms fino que est implcito al unir las tablas
de hechos y dimensiones. Por ejemplo, la granularidad de un modelo dimensional que
consta de las dimensiones de fecha, almacn y producto es producto vendido en el
almacn por da.
Identificar los datos
Cada fila contiene el mismo tipo de datos. Por ejemplo, cada fila puede contener
ventas diarias por almacn, por producto, o elementos de lnea diarios por almacn.
Por ejemplo, las definiciones de grano pueden incluir los siguientes elementos:
Un elemento de lnea en un recibo de tienda de comestibles
Una instantnea mensual de un extracto de cuenta bancaria
Un solo billete de avin adquirido un da

Las tablas de hechos y dimensiones tienen una granularidad asociada a ellas. El

modelado dimensional, la granularidad hace referencia al nivel de detalle almacenado
en una tabla. Por ejemplo, una dimensin como la fecha (con las jerarquas de ao y
trimestre) tiene granularidad en el nivel trimestral pero no tiene informacin para los
das o meses individuales. Alternativamente, una tabla de dimensiones de fecha (con
las jerarquas de ao, trimestre y mes) tiene granularidad en el nivel mensual, pero no
contiene informacin en el nivel diario.

Puede gestionar distintas granularidades de datos utilizando varias tablas de hechos

(tablas diarias, mensuales y anuales). Tambin puede utilizar una sola tabla con un
distintivo de granularidad, o una columna que indique el grano de la tabla. No
obstante, no almacene datos con distintas granularidades en la misma tabla de
hechos.
Identificacin de los metadatos del grano
Durante esta fase recopilar los siguientes metadatos:

Una o ms definiciones de grano para el proceso de negocio que va a modelar

Tipo de tabla de hechos utilizada
Dimensiones y medidas preliminares de alto nivel

Cuando identifique los granos de los objetos de datos, realice los pasos siguientes:

1. Determine la granularidad de la tabla de hechos.

El detalle de grano se basa en las conclusiones de los requisitos analizados y

documentados en el Paso 1: Identificar los requisitos del proceso de negocio. Rena
documentos, como facturas, recibos y memorndums de pedido. Estos documentos
con frecuencia incluyen informacin que se puede utilizar para definir el grano. Estos
documentos tambin tienen informacin que ayuda a identificar las dimensiones y
medidas de los modelos dimensionales.

El grano que elija determinar el nivel de detalle de la informacin que puede haber
disponible en el modelo dimensional.

La definicin de grano es la base de cada modelo dimensional. La definicin de grano

determina el nivel de informacin que hay disponible. Las directrices para elegir la
definicin de grano incluyen las siguientes consideraciones:

Durante la fase de recopilacin de requisitos empresariales, intente recopilar los

documentos necesarios, como formularios de facturas, formularios de pedidos y
recibos de ventas. Generalmente, estos documentos tienen asociados datos de
transaccin, como el nmero de pedido y el nmero de factura.
Con frecuencia, los documentos pueden indicarle los elementos importantes del
negocio, como el cliente y los productos. Los documentos a menudo contienen
informacin de nivel inferior que puede ser necesaria para el negocio.
Otro punto importante que se debe considerar es la fecha. Es importante
comprender qu nivel de detalle est asociado con un cliente, un producto o un
proveedor. La informacin de los sistemas de origen est disponible a nivel
diario, mensual o anual?
 2. Determine cmo gestionar varios granos independientes.

Determine si hay varios granos asociados al proceso de negocio para el que va a

disear el modelo dimensional. Puede haber ms de una definicin de grano asociada a
un solo proceso de negocio. En estos casos, disee tablas de hechos independientes
con granos independientes. No fuerce todas las medidas en una sola tabla de hechos.

Se pueden gestionar distintas granularidades de datos utilizando varias tablas de

hechos (por ejemplo, tablas diarias, mensuales y anuales). Adems, considere la
cantidad de datos, espacio y requisitos de rendimiento cuando decida cmo gestionar
varias granularidades.

Criterios para una o ms tablas de hechos

Para determinar si desea utilizar una o ms tablas de hechos, considere los
siguientes criterios:
Considere las medidas. Decida si desea agrupar las medidas en una
tabla de hechos o en distintas tablas de hechos con granos diferentes.
Hay varios sistemas de origen OLTP implicados? Cada sistema de origen
est diseado con un objetivo especfico. Si dos sistemas de origen no
cumplen objetivos diferentes, consolide los sistemas en un solo origen.
Si desea mantener los sistemas separados, cada sistema de origen
deber satisfacer un requisito concreto del negocio. Si los procesos de
negocio incluyen la gestin de pedidos o el inventario de almacn,
probablemente sern necesarios sistemas de origen diferentes. En este
caso, utilice distintas tablas de hechos.
Determine si hay implicados varios procesos de negocio no relacionados.
Cree tablas de hechos independientes para los procesos de negocio no
relacionados. Si un solo proceso de negocio requiere distintos niveles de
granularidad, cree distintas tablas de hechos para gestionar esos
niveles.
Si una dimensin no es verdadera en la definicin de grano, disee una
nueva tabla de hechos con su propia definicin de grano.
Considere la temporizacin y la secuencia de los sucesos. Quiz necesite
procesos diferentes para gestionar un solo suceso. Por ejemplo, una
empresa comercializa su producto. Los clientes solicitan los productos. El
departamento encargado de las cuentas genera una factura. El cliente
paga la factura. Despus de la compra, el cliente puede devolver algunos
de los productos o enviarlos a reparar. Si alguno de los productos est
fuera de garanta, este proceso requiere nuevos cargos. Varios procesos
forman parte de la secuencia de una sola compra. Cada uno de estos
procesos se realiza en momentos temporales diferentes. Cada uno de
estos procesos se gestiona utilizando tablas de hechos diferentes.
 Varias granularidades en una sola tabla de hechos
Si utiliza varios granos en una tabla de hechos, aada una columna
llamada distintivo de granularidad. Esta columna indica el grano de la tabla. La
columna define si la informacin se almacena a nivel diario, semanal, mensual o
anual.
Nota: Puede almacenar varios granos en una sola tabla de hechos, pero este
mtodo no se recomienda. Disee distintas tablas de hechos y esquemas de
estrella para cada definicin de grano.

3. Determine el tipo de tabla de hechos que desea utilizar.

Identifique el tipo de tabla de hechos implicada en el diseo del modelo dimensional.

Para obtener ms informacin sobre los tipos de tablas de hechos, consulte Tablas y
entidades de hechos.

4. Compruebe la atomicidad de los granos.

Revise la atomicidad (nivel de detalle) del grano para asegurarse de que est en
el nivel de mayor detalle. Esta decisin incluye la consideracin por anticipado de
las necesidades futuras con el fin de minimizar la necesidad de crear un nuevo
diseo cuando cambien los requisitos empresariales.

El grano del modelo dimensional es importante al disear el modelo dimensional.

Aunque los requisitos empresariales necesiten informacin a nivel mensual o
trimestral, haga disponible esta informacin a nivel diario. Si las dimensiones son
ms detalladas (atmicas), el negocio puede recupera informacin ms detallada.

Por ejemplo, considere una dimensin de fecha que slo tenga un atributo Year.
Como slo hay un atributo, no puede consultar la informacin a nivel trimestral,
mensual o diario. Para maximizar la informacin disponible, elija un grano atmico
detallado. En este ejemplo, puede definir el grano a nivel diario.

Por ejemplo, pongamos por caso un grano de un producto vendido en un almacn.

No podr asociar un cliente con un producto determinado que se haya adquirido
porque slo hay una fila para un producto. Si mil clientes diferentes compran el
producto, no podr descubrir esa informacin.

Siempre puede declarar granos de mayor nivel para un proceso de negocio

utilizando agregaciones de los datos ms atmicos y detallados. Sin embargo,
cuando se selecciona un grano de mayor nivel, el nmero de dimensiones se
limita y puede ser menos granular. No puede detallar ms estas dimensiones
menos granulares para obtener un nivel menor de detalle.
 La granularidad proporciona la oportunidad de alcanzar el equilibrio entre las
cuestiones importantes relacionadas con un depsito de datos:

El rendimiento frente al volumen de los datos (y el coste derivado de

almacenar esos datos)
La capacidad de acceder a los datos a un nivel detallado frente al
rendimiento (y el coste de almacenar y acceder a grandes volmenes de
datos)
Seleccionar el nivel apropiado de granularidad afecta considerablemente el
volumen de datos del depsito de datos. Seleccionar el nivel apropiado de
granularidad tambin puede determinar la capacidad del depsito de datos para
satisfacer los requisitos de consulta.

Si consideramos el espacio de disco y el volumen de datos, una mayor

granularidad proporciona una forma ms eficaz de almacenar datos que una baja
granularidad. Tambin debe considerar el espacio de disco para el ndice de los
datos. Mediante el uso del ndice, ahorrar espacio de disco. Tenga tambin en
cuenta la manipulacin de grandes volmenes de datos. La manipulacin de datos
puede afectar al rendimiento a costa de ms potencia de proceso.

Siempre existen ventajas y desventajas al procesar los datos. Por ejemplo, al

aumentar la granularidad, disminuye la capacidad para responder a distintos tipos
de consultas (que requieren datos a nivel ms detallado). Si la tabla utiliza un
nivel bajo de granularidad, puede soportar las consultas que utilizan esos datos a
costa del aumento del espacio de almacenamiento y la disminucin del
rendimiento.

Aunque la granularidad no afecta a la capacidad de responder a una consulta, el

sistema puede necesitar ms recursos para ejecutar la misma consulta.
Supongamos que tiene dos tablas con distintos niveles de granularidad: una tabla
con detalles de transaccin y una tabla que resume las cuentas mensualmente.
Para crear un informe de cuentas mensual, puede utilizar cualquiera de las tablas
sin ninguna dependencia de la granularidad. Sin embargo, la consulta de la tabla
de transacciones detalladas es una bsqueda que abarca ms datos, lo que
requiere un proceso para calcular los resultados. La tabla de resumen de cuentas
mensual requiere menos recursos.

Cuando decida el nivel de granularidad, determine si el coste del volumen de

datos compensa la capacidad de responder a las consultas.

5. Determine las dimensiones y medidas de alto nivel segn sus definiciones de

grano.
 6. Cree un informe de sus definiciones de grano.

Identificacin de dimensiones y medidas de alto nivel

Identifique las dimensiones y medidas preliminares de alto nivel a partir de las

cuales comprender la definicin de grano. Para identificar estas dimensiones y
medidas preliminares, no se lleva a cabo ningn anlisis detallado. Cuando defina
el grano correctamente, podr encontrar fcilmente las dimensiones y medidas
preliminares.

Las medidas preliminares son aquellas que se pueden identificar fcilmente

consultando la definicin de grano. Por ejemplo, las medidas como el precio
unitario, la cantidad y el descuento se identifican fcilmente viendo el grano. Sin
embargo, las medidas detalladas como el coste, el precio de fabricacin y el coste
de transporte no son medidas preliminares identificadas por el grano. Estos tipos
de medidas estn ocultas y generalmente no son visibles en un informe. Las
medidas preliminares no son el conjunto final de medidas. La identificacin formal
de medidas detalladas se produce al identificar las medidas.

Estas dimensiones y medidas preliminares de alto nivel son tiles al identificar

formalmente las dimensiones.

Creacin de un informe de la fase de identificacin del grano

El informe de definicin del grano se crea para esta fase. El informe contiene una
o ms definiciones para el grano del proceso de negocio y define el tipo de tabla
de hechos. El informe tambin incluye las dimensiones y medidas preliminares de
alto nivel.
 Paso 3: Identificar las dimensiones

Una vez que haya determinado el grano (el detalle) del modelo, se debe identificar las
dimensiones verdaderas para ese grano. Se deben crear columnas, jerarquas y
casos para el esquema de copo de nieve.

Al identificar tablas de dimensiones, se recopilan los siguientes metadatos:

Nombres de dimensin
Definiciones de negocio
Jerarquas
Gestin de cambios de dimensin
Frecuencia y estadsticas de carga
Estadsticas de uso
Reglas y estadsticas de archivado
Reglas y estadsticas de depuracin
Calidad y precisin de los datos
Claves primarias y forneas y manera de generar las claves
Informacin de origen de datos
Hechos
Para definir totalmente las dimensiones del modelo dimensional, realice los pasos
siguientes:

1. Identifique las dimensiones verdaderas para el grano del modelo.

2. Identifique las columnas y jerarquas dimensionales de las dimensiones.
3. Si crea dimensiones de tiempo y fecha, defina la granularidad de esas
dimensiones.
4. Determine qu dimensiones cambian lentamente a lo largo del tiempo y cmo
abordar esos cambios.
5. Determine qu dimensiones (si hay alguna) deben tener estructura de copo de
nieve.
Identificacin de dimensiones

Identifique las dimensiones verdaderas para el grano del modelo.

Las tablas de dimensiones contienen columnas que describen los registros de hechos
en la tabla de hechos. Algunas de estas columnas proporcionan informacin
descriptiva. Otras columnas especifican cmo se resumen los datos de la tabla de
hechos para proporcionar informacin til. Las tablas de dimensiones contienen
jerarquas que ayudan a resumir los datos. Las tablas de dimensiones son ms
pequeas, tablas de bsqueda desnormalizadas que contienen columnas descriptivas a
las que se hace referencia al definir las consultas.
Para obtener ms informacin sobre las tablas, consulte Tablas y entidades de
dimensiones.

Para identificar dimensiones, realice los pasos siguientes:

1. Utilice la definicin de grano para localizar posibles dimensiones.

2. Liste todas las dimensiones asociadas a este grano. Defina el nivel de detalle
que desea incluir en esa dimensin.
3. Cree claves sucedneas para las claves primarias de las dimensiones. Para
obtener ms informacin sobre las claves sucedneas, consulte Claves
sucedneas.
Identificacin de dimensiones compartidas
Identifique las dimensiones compartidas que haya disponibles, en vez de redisear las
dimensiones. Identifique si una dimensin en uso existe en el depsito de datos de
empresa o modelo dimensional. Para obtener ms informacin sobre las dimensiones
compartidas, consulte Dimensiones compartidas.

Para identificar una dimensin compartida, realice los pasos siguientes:

1. Identifique si existe una dimensin. Si la dimensin existe, debe utilizarla. Si la

dimensin existe, no identifique los atributos dimensionales de esa dimensin
especfica. Comparta una dimensin con una dimensin existente aunque la
dimensin compartida slo contenga un subconjunto de atributos de la
dimensin primaria.
2. Si la dimensin no existe, cree una dimensin que utilizar en toda la empresa.
Si el modelo dimensional requiere una dimensin que no existe, disee una
nueva dimensin. Cuando disee esta dimensin, interacte con expertos en la
materia para averiguar cmo tienen previsto utilizar la dimensin.
Identificacin de columnas y jerarquas dimensionales

Despus de identificar las dimensiones, rellene las dimensiones con columnas. Utilice
las columnas descriptivas para definir los criterios de restriccin para las consultas.

Considere los puntos siguientes cuando disee las dimensiones:

Conserve la clave del sistema origen

Utilice una entrada independiente en la tabla de dimensiones para conservar la clave

del sistema origen natural de la entidad que se va a utilizar en el sistema de origen.

Utilice claves sucedneas

Utilice una clave sucednea para la clave primaria de una dimensin. No es necesario
que analice la clave sucednea. Para obtener ms informacin sobre las claves
sucedneas, consulte Claves sucedneas.
Cree columnas descriptivas exclusivas en el modelo.

Las columnas de una dimensin reflejan las reas potenciales de inters que se pueden
utilizar para los datos agregados o para crear restricciones y notificar interrupciones.

Cree columnas que sean descriptivas y fcilmente comprensibles.

Defina columnas que puedan contener un valor NULL cuando una columna no se aplica
a un elemento especfico o se desconoce su valor.

Defina nombres de columna exclusivos en el modelo. Si tiene nombres duplicados en

distintas tablas de dimensiones, cree una distincin. Por ejemplo, si tiene mltiples
columnas denominadasCdigo de tipo de direccin, renombre una columna
como Cdigo de tipo de direccin de beneficiario y otra columna como Cdigo
de tipo de direccin de prima.

Documente correctamente todas las columnas.

Gestin de cdigos

Si utiliza cdigos en la dimensin, proporcione documentacin del cdigo. Por ejemplo,

si identifica sucursales mediante un cdigo de sucursal, en el que cada cdigo
representa un nombre de sucursal, incluya el cdigo y el nombre.

Una vez que haya definido las columnas, puede definir las jerarquas de la dimensin.
Una jerarqua es una serie en cascada de relaciones de muchos a uno. Una jerarqua
contiene distintos niveles, y cada uno corresponde a un atributo de dimensin. Para
obtener ms informacin sobre las jerarquas, consulte Jerarquas.

Identificacin de la granularidad de las dimensiones de fecha y hora

Identifique la granularidad de las dimensiones de fecha y hora. Las dimensiones de
fecha y hora ayudan a determinar la granularidad del modelo dimensional completo y
el nivel de informacin almacenado en el modelo. Si define un grano incorrecto en la
dimensin de fecha o de hora, es posible que omita dimensiones importantes. Por
ejemplo, si disea un modelo dimensional para un sistema de gestin de pedidos y
disea el grano de la dimensin de fecha como trimestral, es posible que pase por alto
otras dimensiones (como la de hora o empleado). Puede incluir esas otras dimensiones
si el modelo define el grano de la dimensin de datos a nivel diario.

Dimensin de fecha
Dado que todos los modelos dimensionales se basan en unidades de tiempo, cada
despensa de datos tiene una dimensin de fecha. Por ejemplo, quiz desee medir el
rendimiento del negocio transcurrido un tiempo. Un modelo dimensional puede
contener varias dimensiones de fecha.
La dimensin de fecha generalmente no tiene un sistema de origen OLTP conectado a
la dimensin. Puede desarrollar la dimensin de fecha antes de disear el modelo
dimensional. Para crear una dimensin de fecha, realice los pasos siguientes:

1. Identifique todas las columnas que necesite.

2. Utilice sentencias SQL para rellenar columnas tales como Fecha, Da, Mes y Ao
de la tabla de dimensiones de fecha. Es posible que deba introducir datos
manualmente en las columnas especiales. Por ejemplo, si realiza un
seguimiento de los das no comerciales (como las vacaciones), debe
introducir Navidad o San Esteban manualmente. Tambin debe introducir
manualmente fechas como el ao, mes y trimestre fiscal, as como los aos
fiscales.
Los datos de fecha se suelen almacenar en una dimensin de datos diferente (en vez
de en una columna de fecha de una tabla de hechos) por dos razones:

Hay varios atributos de fecha que las funciones de fecha SQL no soportan. Estas
funciones incluyen los perodos fiscales, las vacaciones, las temporadas, los das
de la semana, los fines de semana y las fiestas nacionales. Cuando cree una
dimensin de fecha, puede consultar los indicadores de rendimiento del negocio
a travs de varios atributos fiscales y relacionados con fechas. Los indicadores
de rendimiento no se muestran si utiliza una columna de fecha u hora SQL en la
tabla de hechos.
Es mucho ms fcil arrastrar las columnas desde una tabla de fechas en vez de
utilizar funciones SQL complejas para crear la lgica de los informes.
Dimensin de hora

En el modelado dimensional puede gestionar las horas de dos maneras:

Hora del da como una dimensin independiente
Hora del da como un hecho
Debe gestionar los datos de hora en una tabla de dimensiones pero no un hecho en la
tabla de hechos. Debe crear una dimensin de hora si tiene que dar soporte al
resumen de los periodos de tiempo en agrupaciones ms resumidas para la creacin
de informes y el anlisis. Por ejemplo, cree una dimensin de tiempo para las
siguientes agrupaciones resumidas:

Horas
Agrupaciones de tiempo especficas de negocio (turnos de maana, de noche o
de ltima hora de la tarde durante los das de la semana)
Tambin debe crear una dimensin de hora si desea representar distintas jerarquas
para el tiempo que va a medir. Por ejemplo, cree distintas jerarquas para el tiempo
estndar y el tiempo militar.
Sin embargo, si no resume ni filtra los grupos de hora del da, exprese la hora como un
hecho en la tabla de hechos. En este caso, el tiempo se considera un simple hecho
numrico en el tipo de datos de indicacin de fecha y hora.

Nota: Expresar el tiempo como un hecho en la tabla de hechos dificulta el proceso de

resumen y creacin de informes si tiene que analizar los datos almacenados a lo largo
de un perodo de tiempo. Puede resumir y crear un informe de los datos fcilmente si
crea una dimensin de hora diferente.

Identificacin de dimensiones que cambian lentamente

Debe identificar las dimensiones que cambian lentamente y determinar cmo

gestionar los datos cambiantes.

Una dimensin que cambia lentamente es aquella cuyos atributos para un registro
cambian lentamente a lo largo del tiempo. Por ejemplo, es posible que necesite realizar
un seguimiento de las transferencias de empleados en la empresa.

El entorno de trabajo soporta los siguientes tipos de dimensiones que cambian

lentamente:

Tipo 0

No se realizan cambios en la dimensin.

Tipo 1

Nuevos datos sobrescriben los datos antiguos. No se hace un seguimiento de los

cambios histricos.

Tipo 2

Con este mtodo, se crean dos entradas distintas. El registro original y el nuevo
registro estn disponibles en la tabla. La nueva fila obtiene su propia clave primaria
(clave sucednea).

Tipo 4

Se crean tablas distintas para almacenar algunos o todos los datos histricos. Slo una
tabla contiene los datos actuales, y cuando se producen actualizaciones, los datos
antiguos se desplazan a la tabla histrica.

Tipo 6

Se combina el tipo 1, el tipo 2 y el tipo 3 (almacenar datos en columnas distintas de la

misma tablas). Generalmente, los datos antiguos se desplazan a registros y columnas
diferentes, y los nuevos datos se colocan en los registros originales.
Identificacin de casos para dimensiones de copo de nieve
Un diseo de esquema de copo de nieve se crea si las tablas de dimensiones se
normalizan y expanden en un esquema de estrella. Una tabla de dimensiones tiene
estructura de copo de nieve cuando los atributos de baja cardinalidad de la dimensin
se han colocado en tablas normalizadas diferentes y estas tablas normalizadas se
vuelven a unir a la tabla de dimensiones original.

Nota: La estructura de copo de nieve en el entorno del modelo dimensional no se

recomienda. La estructura de copo de nieve dificulta la comprensin del modelo
dimensional. La estructura de copo de nieve tambin puede reducir el rendimiento, ya
que es necesario unir ms tablas.

Slo debe crear una estructura de copo de nieve en una dimensin de un modelo
dimensional en dos casos:

La tabla de dimensiones contiene dos o ms conjuntos de atributos que definen

informacin en distintos granos.
Los conjuntos de atributos de la misma tabla de dimensiones se rellenan a travs
de distintos sistemas de origen.
No cree estructuras de copo de nieve en jerarquas de una tabla de dimensiones en
tablas distintas. Las jerarquas deben pertenecer nicamente a la tabla de
dimensiones. No cree una estructura de copo de nieve en las jerarquas. Varias
jerarquas pueden pertenecer a la misma dimensin si esta se ha diseado con el nivel
de detalle ms bajo.

Si las jerarquas estn divididas en tablas distintas, el rendimiento resultar afectado,

ya que son necesarias ms uniones. En algunas situaciones, puede crear una
estructura de copo de nieve en las jerarquas de una tabla principal. Cuando utilice un
agregado de la tabla de hechos, utilice slo dimensiones de copo de nieve con las
jerarquas para evitar uniones en grandes tablas de dimensiones. Por ejemplo, si tiene
informacin de marca que desea separar de una tabla de dimensiones de producto,
cree una dimensin de copo de nieve Marca que contenga una sola fila para cada
marca utilizando menos filas que en la tabla de dimensiones Producto.

Nota: Si utiliza demasiadas tablas en un esquema de copo de nieve, el diseo puede

resultar demasiado complejo. El modelado dimensional tiene como objeto crear un
modelo simple, fcil de entender. Si tiene ms tablas, debe crear ms uniones. El
rendimiento disminuye al crear ms uniones.
 Paso 4: Identificar las medidas

Durante este paso del ciclo de diseo de modelo dimensional, identificar las medidas
y el tipo de medidas incluidas en el modelo dimensional.

Para obtener ms informacin sobre las medidas, consulte Medidas.

Al definir las medidas, se recopilan los siguientes metadatos:

Nombre de tabla de hechos

Alias
Grano
Definicin de negocio
Frecuencia y estadsticas de carga
Estadsticas de uso
Cmo gestionar los datos archivados
Cmo y cundo depurar los datos
Calidad y precisin de los datos
Grano de dimensiones de fecha y hora
Claves y cmo se generan las claves
Informacin de origen de datos
Medidas
Dimensiones
Informacin de contacto del propietario de la tabla
Cuando identifique las medidas del modelo dimensional, realice los pasos siguientes:

1. Identifique las medidas verdaderas para el grano de la tabla.

2. Identifique los tipos de medidas del modelo.
3. Si no es una tabla de hechos que agregue totales anuales, asegrese de que no
se incluyan medidas de ao a fecha en la tabla.
4. Si es una tabla de hechos basada en sucesos, determine cmo gestionar los
sucesos.
5. Pronostique el crecimiento de la tabla de hechos.
Identificacin de medidas verdaderas para el grano
Cuando disee las medidas de un modelo, identifique las medidas verdaderas para el
grano de cada nivel del modelo. Cuando haya identificado el grano del modelo
dimensional, habr identificado las medidas preliminares. Puede determinar otras
medidas detalladas consultando la definicin de grano. Por ejemplo, si tiene medidas
detalladas, como el coste por producto individual o el coste del trabajo de fabricacin
por producto, identifique todas las medidas restantes del modelo.

Identificacin de tipos de medidas

Determine qu tipos de medidas se utilizan en el modelo dimensional. Cada medida de
una tabla de hechos debe tener una regla de agregacin (o derivacin) por omisin.
Determinacin de cmo gestionar medidas de ao a fecha

Las medidas de ao a fecha son valores numricos que constan de un total agregado
desde el inicio del ao a la fecha actual. Debe asegurarse de que dichas medidas no se
incluyan en una tabla de hechos con los elementos de lnea de nivel atmico.

Supongamos que una tabla de hechos almacena datos de ventas para el ao 2005. Las
ventas de cada mes son aditivas, y aade las ventas para crear totales de ao a fecha.
Si crea un hecho de ao a fecha, como por ejemplo Sales_$$_Year_To_Date, cuando
consulte este hecho en agosto de 2005 obtendr la suma de todas las ventas hasta
agosto de 2005.

Los modeladores dimensionales pueden incluir medidas agregadas de ao a fecha en la

tabla de hechos con el fin de mejorar el rendimiento y tambin reducir las
complejidades cuando se formen consultas de ao a fecha. Sin embargo, para evitar
confusin, calcule estas medidas en la aplicacin del informe.

Gestione las medidas de ao a fecha con los mtodos siguientes:

Aplicaciones basadas en OLAP

Funciones SQL en vistas o procedimientos almacenados
Determinacin de cmo gestionar sucesos

Si es una tabla de hechos basada en sucesos, debe determinar cmo gestionar los
sucesos.

Las tablas de hechos basadas en sucesos se utilizan para registrar sucesos, como las
visitas a pginas web y la asistencia de empleados o alumnos. Los sucesos no siempre
se convierten en medidas. Si gestiona escenarios basados en sucesos en los que no
hay medidas, utilice las tablas de hechos basadas en sucesos que constan de
seudohechos o de hechos sin hechos.

Tenga en cuenta las siguientes consideraciones asociadas a una tabla de hechos

basada en sucesos:

Las tablas de hechos basadas en sucesos generalmente tienen seudohechos o

no tienen ningn hecho.
Utilice seudohechos para realizar operaciones de recuento.
Una tabla de sucesos de hechos sin hechos slo tiene claves forneas, no
hechos. Utilice las claves forneas para realizar operaciones de recuento.
Pronstico del crecimiento de las tablas de hechos
Pronostique el tamao y el crecimiento de una tabla de hechos para determinar cmo
puede ajustar el rendimiento del modelo dimensional.

Puede calcular el tamao y el crecimiento de la tabla de hechos realizando uno de los

pasos siguientes:

Comprender el negocio
Por ejemplo, supongamos que el negocio de ventas al por menor genera unos
ingresos brutos de 100 millones de dlares americanos. Supongamos tambin
que el precio medio de un elemento de lnea es de 2 dlares americanos. Para
calcular la cantidad de elementos de lnea que necesita, divida los ingresos
brutos por el precio medio de un elemento de lnea:

100000000 / 2 = 50000000 filas

Por lo tanto, 50 millones de filas se insertan en el esquema de estrella para el

proceso de negocio de ventas al por menor de este grano.

Realice el clculo desde una perspectiva tcnica

Determine el tamao de las claves forneas, dimensiones degeneradas y
medidas. Multiplique estas columnas por el nmero mximo de filas que se
puedan insertar, suponiendo que todos los productos se venden en todos los
almacenes cada da. Por ejemplo, en el proceso de negocio de ventas al por
menor, realice los pasos siguientes:

1. Calcule el nmero de filas que hay en cada una de las dimensiones:

2. Dimensin de hora: 4 filas
3. Dimensin de fecha: 365 filas durante 1 ao
4. Dimensin de producto: 100 filas (100 productos)
5. Dimensiones de almacn: 2 filas (2 almacenes)
6. Dimensin de cliente: 1000000 clientes
7. Dimensin de proveedor: 50 proveedores

Dimensin de empleado: 10 empleados

8. Calcule el nivel base de los registros de hechos multiplicando el

nmero de filas de cada dimensin. Utilice los nmeros que haya
obtenido en el paso anterior:

4 * 365 * 100 * 2 * 1000000 * 50 * 10 = 730000000 filas

 Nota: Este nmero puede ser mayor de lo que espera. El nmero slo
se aplica si cada empleado de cada almacn vende cada producto a cada
cliente.

9. Calcule el crecimiento mximo del tamao de tabla de hechos:

10. Nmero de claves forneas: 8
11. Nmero de dimensiones degeneradas: 1

Nmero de medidas: 8

Supongamos que la tabla de hechos ocupa 4 bytes para una columna ENTEROS, y
calcule el tamao de una sola fila:

(8 + 1 + 8) * 4 bytes = 68 bytes

Calcule el crecimiento mximo de los datos para un solo ao del modelo dimensional:

730000000 filas * 68 bytes = 45 GB