01 Material

Diseño dimensional
Capítulo 2
Diseño Dimensional
Objetivo
Al finalizar el capítulo, el alumno:
• Comprender los mecanismos de agregación.

• Diseñar soluciones de un DataMart.
• Diseñar estructuras que se utilizarán en el desarrollo de un DataMart.
• Aplicar los conocimientos adquiridos en múltiples situaciones de diseño.
Temas
1. Concepto de medida
2. Tabla de hechos
3. Granularidad
4. Criterios para agrupar la información
5. Relaciones entre las tablas
6. Tipos de modelo dimensional
7. Pasos del modelo dimensional
IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 1

Diseño dimensional
1. Concepto de medida
Measures (medidas):
• Son valores cuantitativos que almacenan las métricas del negocio y responde a la pregunta
¿Cuánto?
• Están representados por columnas numéricas en la fact table.
• En algunos casos provienen directamente de los sistemas transaccionales.
• Son las variables que ayudarán a medir el desempeño del negocio.
• Una fila en una tabla de hechos corresponde a una o varias medidas
Ejemplo: proceso de negocio y medidas

• Ventas
Cantidad de pedidos
Comisiones
Descuentos
Montos vendidos
Cantidades vendidas
Devoluciones
Valores presupuestados

Diseño dimensional
• Marketing
Unidades vendidas
Valores actuales
Valores presupuestados
• Logística
Unidades aceptadas
Unidades devueltas
Peso
Costo inventario
Montos comprados
• Producción
Tiempo de producción
Capacidad usada
Unidades embarcadas
Unidades planificadas
Unidades producidas
Costos producción
Horas hombre
Peso ingresado
Peso procesado
1.1 Clasificación de las medidas
• Las medidas naturales o básicas:

− Existen físicamente en el warehouse junto a los atributos que los
caracterizan.
− Son aquellas que se obtienen por agregación de los datos originales.
− Funciones de agregación relacionadas:
 Suma: suma los valores de las columnas.
 Cuenta: conteo de los valores.
 Mínima: valor mínimo.
 Máxima: valor máximo.
 Cuenta de distintos: valores diferentes.
• Las medidas derivas o calculadas:

− Se construyen a partir de las medidas básicas y pueden o no estar
almacenados físicamente en la data warehouse.
− Si se derivan de una medida natural
− Funciones de agregación relacionadas:
 Cálculos matemáticos
 Expresiones condicionales
 Alertas

Diseño dimensional
1.2 Grado de agregación
Las medidas tienen propiedades que permiten definir su funcionamiento, así

como controlar cómo aparecen ante los usuarios.
Al usar una dimensión para segmentar una medida, la medida se resume en las
jerarquías contenidas en la dimensión. Todas las medidas que se crean están
respaldadas por una función de agregación que determina la operación de la
medida.
El comportamiento de suma depende de la función de agregado especificada en la

medida.
Para la mayoría de las medidas que contienen datos numéricos, la función de

agregado es Sum. Asumiendo que la columna de origen contiene datos
numéricos. Sum se asigna independientemente del tipo de datos de la columna
de origen.
El grado de agregación de una función de agregación determina cómo se agrega la

medida en todas las dimensiones del cubo. Las funciones de agregación
pertenecen a uno de tres niveles de grado de agregación:
1.2.1 Aditivas
• Una medida aditiva, también denominada medida completamente

aditiva, se puede agregar en todas las dimensiones que están
incluidas en el grupo de medidas que contienen la medida, sin
restricciones
1.2.2 Semiaditivas
• Una medida semiaditiva se puede agregar en algunas, pero no todas,

las dimensiones que están incluidas en el grupo de medidas que
contienen la medida.
• Por ejemplo: una medida que representa la cantidad disponible para
inventario puede agregarse en una dimensión de geografía para
generar una cantidad total disponible para todos los almacenes, pero
la medida no se puede agregar en una dimensión de tiempo porque
representa una instantánea periódica de las cantidades disponibles.
Agregar dicha medida en una dimensión de tiempo generaría
resultados incorrectos.
1.2.3 No aditivas
• Una medida no aditiva no se puede agregar en ninguna dimensión en

el grupo de medida que contienen la medida.
• En su lugar, la medida debe calcularse de forma individual para cada
celda del cubo que representa la medida. Por ejemplo, una medida
calculada que devuelve un porcentaje.

Diseño dimensional
• Por ejemplo, un margen de beneficio, no se puede agregar a partir de

los valores de porcentaje de los miembros secundarios en cualquier
dimensión.
En la siguiente tabla se enumeran las funciones de agregación y se describen el

grado de agregación y el resultado esperado de la función.

Diseño dimensional
2. Tabla de hechos
Las tablas de hechos son tablas que registran eventos como las ventas que hacemos, las
páginas visitadas en nuestro sitio web o las entradas de productos en nuestro
inventario. Son tablas que se actualizan constantemente y esa periodicidad de
actualización la define el negocio.
Son las tablas más importantes del modelo de negocio que representan un hecho o
evento que ocurre en el proceso de negocio y son de tres tipos: transacción, periódicas y
acumulativas.
Es en definitiva es la tabla principal del modelo dimensional que contiene campos clave
asociados con la tabla de dimensiones, que contiene las métricas o también conocidas
como métricas que queremos medir o analizar. Estos suelen ser valores que
normalmente sumarían.
Son tablas que evitan la redundancia de estos atributos en la tabla de dimensiones.

Por lo general, hay muchos (millones) de registros. Ejemplo: ventas, compras, cambios
contables

Diseño dimensional
2.1 Tablas de hechos
Un Datamart está orientado a brindar a los usuarios información numérica,

que contribuya a entender el comportamiento del negocio y tomar mejores
decisiones.
Esta información numérica recibe el nombre de medida (measure). Algunos
ejemplos de medidas comúnmente utilizadas por todo tipo de negocio son:
ventas, unidades vendidas, costo, gasto, etc.
Las medidas se almacenan en una o más tablas de hechos (fact tables). Toda
tabla de hechos contiene una cantidad variable de columnas numéricas, que
almacenan los valores de las medidas.
Una tabla de hechos tiene las siguientes características:
 Es la tabla central en un esquema dimensional.

 Almacenan las mediciones numéricas del negocio.
 El grano o la granularidad de la tabla queda determinada por el nivel de
detalle que se almacenará en la tabla.
 Cada medida es tomada de la intersección de las dimensiones que la
definen.
Las Fact tables pueden tener 4 tipos de columnas:
 Llave primaria (Primary Key). Columnas que identifican a cada miembro de

la dimensión dentro del modelo de negocio
 Foreign Key (Llave foranea). Columnas que almacenan las llaves primarias
(Primary Key) de las dimensiones.
 Measure. Columnas con los valores de las medidas que se usarán para
obtener los análisis.
 Metadata. Columnas que almacenan datos de auditoría de los procesos
del negocio
Ejemplo:
En el ejemplo anterior, las columnas Id_Fecha, Id_Producto y Id_Cliente

constituyen la clave primaria de la tabla de hechos Ventas_Fact.

Diseño dimensional
 Estas columnas contienen claves foráneas que enlazan la tabla de hechos

con las tablas de dimensión fecha, producto y cliente. Las columnas
importe total y utilidad corresponden con las medidas de la tabla de
hechos.
Por otro lado, las tablas de dimensiones incluyen criterios por lo que podemos
segmentar los "hechos" (en inglés Fact Table). Por ejemplo, si la tabla de hechos
contiene ventas por internet, podemos querer segmentar las ventas por cliente quien
nos han comprado o quienes les hemos vendido (Dimensión Customer), o podemos
querer segmentarlas según el país, región o ciudad en el que se producen
(Dimension DimGeography), o según la categoría del producto vendido
(Dimension DimProductCategory). Las tablas de dimensiones son normalmente
estáticas, casi siempre no se modifican o en algunos casos se modifican con poca
frecuencia (Método Slowly Changing Dimensions).

Diseño dimensional
3. Granularidad
Determinar la granularidad de Tabla de Hechos y proceso empresarial. Durante este

proceso, se define los tipos de tablas de datos y los candidatos iniciales para las
dimensiones y medidas.
Definir la tabla de hechos del modelo de negocio es identificar la granularidad de la

tabla, la granularidad indica el nivel de detalle que se mide por cada fila de datos. Por
ejemplo, una dimensión como la fecha (con las jerarquías de año y trimestre) tiene
granularidad en el nivel trimestral pero no tiene información para los días o meses
individuales. Alternativamente, una tabla de dimensiones de fecha (con las jerarquías de
año, trimestre y mes) tiene granularidad en el nivel mensual, pero no contiene
información en el nivel diario.
Puede administrar varias granularidades de datos usando varias tablas de hechos (tablas
diarias, mensuales y anuales). Asimismo, se puede disponer de una sola tabla con un
distintivo de granularidad, o una columna que indique el grano de la tabla. Pero, no
gestione datos con distintas granularidades en una misma tabla de hechos (Fact Table).
Cuando identifique los granos de los objetos de datos, realice los pasos siguientes:
3.1 Definir la metadata del grano
• Una o más definiciones del grano para el proceso empresarial que se

modelara.
• Tipo de tabla de hechos utilizada (Transaccional, Incremental, Actualizada)
• Tabla maestra o Tabla de Dimensiones y medidas preliminares de alto nivel

Diseño dimensional
3.2 Definir la granularidad de la tabla de hechos (Fact Table)
Unificar documentos del negocio, como facturas, boletas y recibos de pedidos.

Estos documentos frecuentemente incluyen información útil para definir el grano.
Estos documentos también cuentan con información para identificar las
dimensiones y medidas de los modelos dimensionales.
Para elegir el grano incluir las siguientes consideraciones:
• Durante esta fase recopilar los documentos necesarios, como facturas,

pedidos y recibos de ventas. Casi siempre, estos documentos tienen
asociados datos de la transacción del negocio; por ejemplo: como el
número de pedido y el número de factura.
• Los documentos indican elementos importantes del negocio, por ejemplo:

el cliente y los productos.
• Un tema importante que se debe considerar es el tiempo (Fecha).

Debemos entender qué nivel de detalle está asociado, por ejemplo: con
un cliente, un producto o un proveedor. Preguntándonos ¿La información
de los sistemas de origen está disponible a nivel diario, mensual,
trimestral, semestral o anual?
3.3 Administrar varios granos independientes
Puede existir varios granos asociados a un proceso de negocio que se definen

durante el diseño dimensional. En este escenario, diseñar tablas de hechos
independiente con granos independientes. No incluir todas las medidas en una
sola tabla de hechos.
Se pueden administrar distintas granularidades de datos utilizando varias tablas

de hechos (ejemplo, tablas diarias, mensuales, semestrales y anuales).
Adicionalmente, considerar la cantidad de datos, espacio y requisitos de
rendimiento cuando requiera cómo administrar varias granularidades.
3.4 Asignar correctamente los tipos de tablas de hechos que se pueden

utilizar
Definir el tipo de tabla de hechos implicada en el diseño del modelo dimensional.
3.5 Validar la atomicidad del grano
Validar la atomicidad (nivel de detalle) del grano para asegurarse de que está en
el nivel de mayor detalle. Esta opción define la consideración por anticipado de las
necesidades posteriores con el fin de minimizar la necesidad de crear un nuevo
diseño cuando cambien los requisitos del negocio.

Diseño dimensional
El grano del modelo dimensional es de suma importancia cuando se diseña el

modelo dimensional. Cuando los requisitos de negocio requieran la información a
nivel mensual o trimestral, prepare sus diseños a nivel diario. Si las tablas de
dimensiones son más detalladas (atómicas), el negocio puede recupera
información más detallada.
Ejemplo, una tabla de dimensión de tiempo (fecha) que sólo tiene un atributo año
(Year). Como sólo hay un atributo, no puede consultar la información a nivel
trimestral, mensual o diario.
3.6 Identificar las tablas de dimensiones y medidas de alto nivel
Definir las tablas de dimensión y medidas de alto nivel, de las cuales se entendería
la definición de grano. Para identificar estos elementos, no se lleva a cabo ningún
análisis detallado.
Las medidas son las que se logran definir fácilmente consultando la definición de
grano. Ejemplo, las medidas como el precio unitario, la cantidad y el descuento se
identifican fácilmente viendo el grano.

Diseño dimensional
4. Criterios para agrupar la información
Son las áreas temáticas o sujetos del negocio que proveen un método general para organizar la
información corporativa. Se definen como un grupo de uno o más atributos. Las dimensiones
no comparten atributos, estas definen los niveles de análisis (Jerarquías). Esto permite obtener
agregación o sumarización.
4.1 Tablas dimensión
Para entender el negocio, es fundamental conocer los valores de las ventas,

los costos y los gastos. Sin embargo, estos números son de escasa utilidad si
no se definen los criterios que se usarán para cruzar la información.
Por ejemplo, la medida ventas, por sí sola, no brinda suficiente información.

En un reporte, ¿estamos visualizando el total de ventas desde que se fundó la
empresa? ¿O las ventas para un determinado período de tiempo? ¿Es
necesario ver las ventas desglosadas por cliente y producto? ¿Se desea
visualizar las ventas por distribuidor?
En este caso, tiempo, cliente, producto y distribuidor constituyen ejemplos de

lo que, en la terminología de Business Intelligence, se denomina dimensiones.
Las dimensiones contienen las descripciones de las entidades principales del
negocio, respecto de las cuales se calcularán las medidas.
Las dimensiones tienen múltiples criterios de agrupación. Por ejemplo, una

dimensión de ubicación geográfica puede agrupar su información en
continentes, regiones, países y ciudades. Estos criterios de agrupación se
denominan niveles (levels). La principal característica de los niveles es que

Diseño dimensional
cada nivel se encuentra contenido en su nivel superior: una ciudad está

contenida en un país, dicho país en una región, y la región en un continente.
Las dimensiones se almacenan en tablas de dimensión. Las características de
una tabla de dimensión son:
 Tienen una relación uno a muchos con la tabla de hechos (fact table).
 Incluyen una clave primaria, de preferencia numérica y auto
incrementado.
 En el ejemplo anterior el campo Producto_Key es la clave primaria de la

tabla de dimensión. Una buena práctica es establecer un tipo de dato
entero y auto generado para las claves de las tablas de dimensión, pues
esto incrementará la velocidad de las consultas (si se efectúan
directamente sobre el modelo STAR) o de los procesamientos de
información (si las consultas se efectúan a través de un cubo). Este tipo de
llave conoce como surrogada o artificial.
El campo IDProducto sirve para conocer el identificador del producto en su

sistema de origen (recuérdese que la información del Datamart puede tener
múltiples orígenes). Este campo será útil durante la escritura de los procesos
de población del Datamart.
En este ejemplo, los niveles de la dimensión producto son: familia, subfamilia,
marca y presentación.
En un modelo STAR, los niveles de la dimensión están representados por
columnas en la tabla de dimensión. Obsérvese, en la tabla PRODUCTO_DIM,
las columnas que representan los niveles anteriormente mencionados.
Ejemplo de llave surrogada o artificial:

Diseño dimensional
Las preguntas que nos permiten identificarlas son:
Ejemplo:
• Las dimensiones definen los niveles de análisis (Jerarquías). Esto permite obtener
agregación o sumarización.
• Es una entidad de negocios respecto de la cual, se deben analizar las métricas.
• Ejemplo 1: Empresa Cadena de supermercados:

Actividad objeto de análisis: ventas de productos.
Información registrada sobre una venta:” Se vendió 5 unidades del producto
A, en el almacén número 1, el día 20/01/2017 por un total de 250.000
soles”.
• Ejemplo 2: Proceso de negocio y dimensiones
• Ventas
Producto
Organización
Tiempo

Diseño dimensional
Cliente
Formas de pago
• Marketing
Producto
Organización
Tiempo
Segmento de clientes
Medios de entrega
Territorios
• Logística
Estado
Proveedores de inventario
Materiales
Productos
Ubicación
Organización
Tiempo
• Producción
Organización
Producto
Procesos
Estaciones de trabajo
• Es preciso que toda dimensión signifique lo mismo para cada tabla de hechos con la
que se relacione: fechas, productos, geografía, cliente …
• Generalmente provienen de las tablas maestras de los sistemas transaccionales.
• En cantidad de registros las dimensiones son las tablas más pequeñas.
• Las dimensiones están compuestas de dos partes:
Atributos
Jerarquías
• Las dimensiones conformadas hacen posible que:

Una única dimensión se puede utilizar frente a varias tablas de hechos
Une varios modelos estrellas o copos de nieve.
2.2 Atributos, jerarquías y niveles
Atributos
• Los atributos son una agrupación de elementos o ítems dentro de una

dimensión.
• Representan categorías o clases de elementos que tienen el mismo nivel lógico
dentro de una dimensión.
• La finalidad de los atributos es ver la información de cada dimensión a
diferentes niveles de detalle y agrupar los datos para ser analizados.
• Son características del Negocio.
• Constituyen los criterios de análisis que se utilizarán para analizar los
indicadores dentro de un cubo.

Diseño dimensional
• Se basan en una gran mayoría, en los campos de las tablas de dimensiones
• Ejemplo: atributos de la dimensión Geografía
Jerarquías y niveles
• Los atributos son una agrupación de elementos o ítems dentro de una

dimensión.
• Representan categorías o clases de elementos que tienen el mismo nivel lógico
dentro de una dimensión.
• La finalidad de los atributos es ver la información de cada dimensión a
diferentes niveles de detalle y agrupar los datos para ser analizados.
• Es la distribución de los atributos en niveles.
• Pueden existir varias en un mismo cubo.
• Están compuestas por dos o más niveles.
• Se tiene una relación “1-n” o “padre-hĳo” entre atributos consecutivos de un
nivel superior y uno inferior.
• Un nivel representa un nivel particular de agregación dentro de una
dimensión; cada nivel sobre el nivel base representa la sumarización total de
los datos desde el nivel inferior.
• Es una forma de organizar los atributos de una dimensión y permite realizar la
técnica denominada Drill Down / Drill Up.
• La ventaja reside en poder analizar los datos desde su nivel más general al más
detallado y viceversa, al desplazarse por los diferentes niveles.
• Ejemplo: Jerarquías y niveles:
Dimensión Zona Geográfica.

Diseño dimensional
5. Relación entre las tablas
Para crear tablas relacionadas, se debe definir una relación entre dos tablas. Una relación se
establece cuando el valor de un campo, denominado campo de coincidencia (a veces recibe el
nombre de campo de clave) en un lado de la relación se compara con éxito con un valor en el
campo de coincidencia en el otro lado de la relación de acuerdo con los criterios que
especifique en la relación.
Por ejemplo, puede crear una relación tal que cuando el valor en el campo ID de estudiante de
una tabla Alumnos sea igual al valor del campo ID de estudiante de una tabla Clases, los
registros de las dos tablas se relacionen.
5.1 Campos utilizados en relaciones
• Un campo de coincidencia puede ser un campo o una combinación de campos

que identifican un registro de una tabla. Por ejemplo, un campo de coincidencia
puede contener fechas que, comparadas con los criterios de la relación,
determinan si la relación es correcta.
• Una clave es un tipo de campo de coincidencia. Por lo general, las claves

contienen valores que se utilizan como ID como, por ejemplo, un ID de producto.
Existen dos tipos de claves:

Diseño dimensional
o Clave principal:
Un campo que se encuentra en la misma tabla que el registro que identifica.

Un valor de clave principal debe ser exclusivo y no estar vacío (no ser nulo).
Solo hay una clave principal en una tabla, pero la clave puede estar formada
por varios campos. De forma predeterminada, al crear un archivo o una tabla
en el cuadro de diálogo Gestionar base de datos, la nueva tabla contiene el
campo de clave principal.
o Clave externa:
Un campo de una tabla que identifica un registro de otra tabla. Los valores en
claves externas no tienen que ser exclusivos en la tabla y pueden estar vacíos
(nulos). Puede haber varias claves externas en una tabla.
Ejemplo: En una base de datos Ventas, la tabla Clientes y la tabla Factura

pueden utilizar el campo ID de cliente para identificar de forma exclusiva a
cada cliente y cada compra. El campo ID de cliente de la tabla Clientes a
menudo es el campo de clave principal debido a que este campo identifica de
forma exclusiva a cada cliente. El campo ID de cliente de la tabla Factura es el
campo de clave externa debido a que sus valores se originan en otra tabla, en
este ejemplo, la tabla Clientes. Sin embargo, los campos ID de cliente de
ambas tablas son campos de coincidencia.
5.2 Tipos de relaciones
Las relaciones fomentan la introducción de datos coherentes y aplican reglas en la

base de datos.
Tipo de Relación Descripción Breve

Un registro de una tabla está asociado a uno y
Uno a Uno
solo un registro de otra tabla
Un registro de una tabla puede estar asociado a
Uno a muchos o de muchos uno o varios registros de otra tabla. O bien, uno
a uno o varios registros de una tabla pueden estar
asociados a un registro de otra tabla.
Por lo general, los sistemas de bases de datos
relacionales no permiten implementar una
relación directa de muchos a muchos entre dos
Muchos a muchos
tablas. Sin embargo, puede diseñar una base de
datos que admita relaciones de muchos-a-
muchos utilizando una tercera tabla intermedia

Diseño dimensional
a) Relaciones de uno a uno
o En una relación de uno a uno, un registro de una tabla se asocia a uno y

solo un registro de otra tabla. Por ejemplo, en una base de datos de un
centro educativo, cada alumno tiene solamente un ID de estudiante, y
cada ID de estudiante se asigna solo a una persona.
o Una relación de uno a uno presenta el siguiente aspecto en el gráfico de

relaciones:
o En este ejemplo, el campo de clave de cada tabla, ID de estudiante, se ha

diseñado para contener valores exclusivos. En la tabla Alumnos, el campo
ID de estudiante es la clave principal; en la tabla Información de
contacto, el campo ID de estudiante es una clave externa.
o Esta relación devuelve registros relacionados cuando el valor del campo

ID de estudiante de la tabla Información de contacto es el mismo que el
del campo ID de estudiante de la tabla Alumnos.
b) Relaciones de uno a muchos
o En una relación de uno a muchos, un registro de una tabla se puede

asociar a uno o varios registros de otra tabla... Por ejemplo, cada cliente
puede tener varios pedidos de ventas.
o Una relación de uno a muchos presenta el siguiente aspecto en el

gráfico de relaciones:

Diseño dimensional
o En este ejemplo, el campo de clave principal de la tabla Clientes, ID de

cliente, se ha diseñado para contener valores exclusivos. El campo de
clave externa de la tabla Pedidos, ID de cliente, se ha diseñado para
permitir varias instancias del mismo valor.
o Esta relación devuelve registros relacionados cuando el valor del campo

ID de cliente de la tabla Pedidos es el mismo que el valor del campo ID
de cliente de la tabla Clientes
c) Relaciones de muchos a muchos
o Una relación de muchos a muchos se produce cuando varios registros

de una tabla se asocian a varios registros de otra tabla. Por ejemplo,
existe una relación de muchos a muchos entre los clientes y los
productos: los clientes pueden comprar varios productos y los
productos pueden ser comprados por muchos clientes.
o Por lo general, los sistemas de bases de datos relacionales no permiten

implementar una relación directa de muchos a muchos entre dos
tablas. Tenga en cuenta el ejemplo de seguimiento de facturas. Si había
muchas facturas con el mismo número de factura y uno de sus clientes
preguntó acerca de ese número de factura, no sabría a qué número se
refería. Este es el motivo por el que se debe asignar un valor exclusivo a
cada factura.

Diseño dimensional
o Para evitar este problema, puede dividir la relación de muchos a

muchos en dos relaciones de uno a muchos mediante el uso de una
tercera tabla denominada tabla de unión.
o Cada registro de una tabla de unión incluye un campo de coincidencia

que contiene el valor de las claves principales de las dos tablas que se
unen. (En la tabla de unión, estos campos de coincidencia son claves
externas). Estos campos de clave externa se rellenan con datos, ya que
los registros de la tabla de unión se crean desde cualquiera de las tablas
que se unen.
o Un ejemplo típico de una relación de muchos a muchos es aquella entre

los estudiantes y las clases. Un estudiante puede matricularse en
muchas clases y una clase puede incluir muchos estudiantes.
o En el siguiente ejemplo, se incluye una tabla Alumnos, que contiene un

registro para cada estudiante, y una tabla Clases, que contiene un
registro para cada clase. Una tabla de unión, Matrículas, crea una
relación de uno a muchos, una entre cada una de las dos tablas.
 La clave principal ID de estudiante identifica de forma exclusiva a cada

estudiante de la tabla Alumnos.
 La clave principal ID de clase identifica de forma exclusiva cada clase

de la tabla Clases.
 La tabla Matrículas contiene las claves externas ID de estudiante e ID

de clase.
 Mediante este diseño, si un estudiante se matricula en tres clases, ese

estudiante tendrá un registro en la tabla Alumnos y tres registros en la
tabla Matrículas: un registro para cada clase en la que se ha
matriculado el estudiante.

Diseño dimensional
6. Tipo de modelo dimensional
El modelo físico puede ser de dos tipos Star Schema (Modelo en estrella) o tipo Snowflake (Copo
de nieve).
Para construir un modelo dimensional, debemos considerar un conjunto de técnicas y conceptos

para diseñar nuestro almacén de datos. Una de las partes básicas es el tipo de tabla en la que
almacenamos la información, distinguimos una tabla de hechos (lo que queremos medir o
analizar) y una tabla de dimensiones (cómo queremos medirlo).
6.1 Modelo Start (Estrella)
• En el modelo STAR, cada nivel de una jerarquía de dimensión está representado

por una columna en la tabla de dimensión.
• El modelo es el más sencillo en estructura.
• Consta de una tabla central de "Hechos" y varias "dimensiones" relacionadas a

esta, incluida una dimensión de "Tiempo". Relacionadas a través de sus
respectivas claves.
• Lo característico de la arquitectura de estrella es que sólo existe una tabla de

dimensiones para cada dimensión.

Diseño dimensional
• Esto quiere decir que la única tabla que tiene relación con otra es la de hechos, lo
que significa que toda la información relacionada con una dimensión debe estar
en una sola tabla.
• Las tablas de dimensión están desnormalizadas.
• Una estrella no debería tener más de 25 tablas de dimensión:
• Un exceso de dimensiones denota que varias no son independientes. En este

caso, deben combinarse en dimensiones más simples.
• Características
Posee los mejores tiempos de respuesta.

Su diseño es fácilmente modificable.
Existe paralelismo entre su diseño y la forma en que los usuarios visualizan y
manipulan los datos.
Simplifica el análisis.
Es ideal por su simplicidad y velocidad para ser usado para análisis.
Las consultas no sencillas, ya que las condiciones y las uniones (JOIN)
necesarias sólo involucran a la tabla de hechos y a las de dimensiones
• Inconvenientes
Este modelo es el menos robusto para la carga y es el más lento de construir.
Ejemplo de un modelo estrella:

Diseño dimensional
Obsérvese el diagrama superior. Este modelo consta de cinco tablas de

dimensión: tiempo, promoción, clientes, productos y almacén, circundando a
una tabla de hechos llamada ventas.
Cada registro de la tabla ventas representa un hecho de ventas. Sus cinco
primeros campos constituyen la clave primaria, y provienen de su relación con
cada una de las tablas de dimensión.
Las columnas restantes representan las medidas relacionadas con las ventas.
A partir de este modelo, es fácil comprender que las métricas de ventas
(registrados en la tabla de hechos ventas) se computan por tiempo,
promoción, clientes, almacén y productos (representados por las tablas de
dimensión).
6.2 Modelo Snowflake (Copo de nieve)
• En el modelo SNOWFLAKE, cada nivel de jerarquía de dimensión está

representado por una tabla. Por tanto, en este modelo una dimensión puede
estar formada por varias tablas.
• Representa una extensión del modelo en estrella, en el que las tablas de

dimensión se normalizan en múltiples tablas.
• En este modelo la tabla de hechos deja de ser la única relacionada con otras
tablas ya que existen otras tablas que se relacionan con las dimensiones y que no
tienen relación directa con la tabla de hechos.
• El modelo fue concebido para facilitar el mantenimiento de las dimensiones, sin

embargo, esto hace que se vinculen más tablas a las secuencias SQL, haciendo la
extracción de datos más difícil, así como vuelve compleja la tarea de mantener el
modelo.
• Características
Posee mayor complejidad en su estructura.

Hace una mejor utilización del espacio.
Las tablas de dimensiones están normalizadas, por lo que requiere menos
esfuerzo de diseño.
Puede desarrollar clases de jerarquías fuera de las tablas de dimensiones, que
permiten realizar análisis de lo general a lo detallado y viceversa.
• Inconvenientes
Si se poseen múltiples tablas de dimensiones, cada una de ellas con varias

jerarquías, se creará un número de tablas bastante considerable, que pueden
llegar al punto de ser inmanejables.
Al existir muchas uniones y relaciones entre tablas, el desempeño puede
verse reducido.
La existencia de las diferentes jerarquías de dimensiones debe estar bien
fundamentada, ya que de otro modo las consultas demorarán más tiempo en
devolver los resultados, debido a que se deben realizar las uniones entre las
tablas.

Diseño dimensional
• Ejemplo de un modelo copo de nieve:
Obsérvese el diagrama superior. Este modelo consta de una dimensión

productos, que en este modelo SNOWFLAKE esta tabla se “partiría” en dos
conservando posiblemente el modelo normalizado del transaccional.
La siguiente tabla muestra una comparación de diversas características de los

modelos STAR y SNOWFLAKE:
 En un modelo STAR, la performance de las consultas y del procesamiento

del Datamart mejora considerablemente debido a que el número de
uniones necesarias para obtener los datos es menor.
 En cambio, el modelo SNOWFLAKE, debido al alto número de tablas que
produce, tiene un tiempo de procesamiento y respuesta más alto.
 Por otro lado, un modelo STAR es bastante más sencillo que un modelo
SNOWFLAKE. El modelo SNOWFLAKE es más difícil de entender, y sus
procesos de carga de datos son más complejos.

Diseño dimensional
7. Pasos del modelo dimensional
Para el modelamiento dimensional se tienen documentos que nos permiten tener un

mejor y más claro concepto del modelo final.
7.1 Entrevistas
• Definir y utilizar templates con anticipación para el levantamiento de

requerimientos del negocio.
• Preparar con anterioridad las preguntas basándose en la información
preliminar obtenida previamente.
• Identificar a los usuarios de negocio correctos. Se requiere información de
todos los niveles de usuarios y grupos dentro de la organización.
• Identificar a los usuarios técnicos correctos para poder validar la
información proporcionado por los usuarios de negocio sobre los BD,
diseños físicos, herramientas de ETL, OLAP, entre otros.
• Efectuar entrevistas para el levantamiento de requerimientos a detalle con
los usuarios de negocio y validar las fuentes de datos con el equipo de
tecnología de la información.
• Obtener las definiciones del negocio y asegurar que sea entendido por toda
la organización. Definir cada término desde la perfectiva de negocio y
solicitar ejemplos de cada definición.
• Identificar el valor para el negocio de cada dato y el impacto de no tenerlo.
• Dar al usuario la oportunidad de revisar en “blanco y negro” los resultados
del levantamiento de requerimientos – cambios, aclaraciones, omisiones,
aprobación

Diseño dimensional
 La plantilla de entrevista consta de tres secciones:
Problemas detectados: el enfoque garantizará detectar los posibles y

actuales problemas presentados con la información en la organización.
Necesidades: el enfoque garantizará identificar las necesidades actuales
y esperadas de la información en la organización.
Análisis: el enfoque garantizará mapear los diferentes reportes con los
datos fuentes de la organización, en el cual se identificarán las métricas
para el análisis.
Template de entrevistas:
7.2 Matriz Bus
• Es un instrumento de documentación de alcance, y de definición de la

estructura de las tablas de hechos.
• Principalmente se encarga de mostrar cuáles serán las medidas a
implementar en cada hecho (Fact) y como están relacionadas con las
distintas dimensiones del modelo.
• Hacer por cada hecho una lista de las dimensiones con las que se relaciona
para que sea entendido no solo para usuarios técnico, sino también para
revisar el modelo con nuestros usuarios de negocio.
•
• Una vez que sabemos cuáles son las dimensiones y las tablas de hechos que
tendrá nuestro cubo, debemos crear una matriz o tabla mostrando

Diseño dimensional
las Medidas en las filas y las Dimensiones en las columnas, y marcando la

intersección existente entre ellas con una ‘X’.
• Es aquí que surge la matriz de Bus, que es una excelente y casi
indispensable herramienta que nos ayuda a representar nuestro diseño del
cubo.
• Las matrices de Bus son en general como se muestran a continuación:
Nombre Fact Dimensión 1 Dimensión 2 Dimensión 3 … Dimensión N
Medida 1 X X X X
Medida 2 X X X
Medida 3 X X X X X
Medida 4 X X
…
Medida N X X X X
• En este punto es visualmente más sencillo, pero probablemente también se

preguntará: ¿por qué debo colocar una equis (X) marcando las asociaciones
entre las dimensiones y las medidas? ¿acaso no están TODAS las
dimensiones relacionadas con TODAS las medidas de un hecho
(Fact) específica? La respuesta a esta interrogante es: NO.
• Para ilustrar este escenario, consideremos el siguiente ejemplo:
Imaginemos que tenemos un cliente que es una tienda, y que ellos

desean crear un Datawarehouse para sus ventas.
Esta tienda tiene sucursales en todo el país, y también tiene
un Site o página Web por donde los clientes pueden hacer sus compras
que recibirán en la dirección que deseen pagando un monto extra por
transporte y entrega a domicilio.
En nuestro Datawarehouse tenemos que reflejar en este caso en
una Fact de ventas, cuándo se hace una venta, a qué cliente se le realizó
la venta, en qué fecha, cuál fue el articulo comprado, cuántos compró y
cuál fue el vendedor que realizó la venta (en caso que aplique), teniendo
por separado las ventas por internet de las ventas en las tiendas.
En este caso, tendríamos las medidas: “Ventas tienda” y “Ventas
Internet” para la Fact de ventas.
Y las dimensiones: fecha, cliente, vendedor y producto.
Como podemos notar, en este caso la medida “Ventas tienda” tendrá un
vendedor asociado, pero en el caso de la medida “Ventas Internet”, el
vendedor NO existe.
• Por lo tanto, la matriz de Bus de la Fact de ventas que tendríamos para

nuestro ejemplo sería la siguiente:
Fact Ventas Fecha Cliente Producto Vendedor

Ventas Tienda X X X X
Ventas Internet X X X

Diseño dimensional
• Como podemos ver, la matriz de Bus en este caso nos sirvió para mostrar
de una manera fácil y sencilla cuáles son nuestras dimensiones, cuáles son
nuestras medidas y cuáles son las relaciones entre ellas.
• Por tanto, adoptar la matriz Bus como una herramienta para definir el
diseño y así poder mostrarlo al usuario de negocio, que agradecerá por
simplificarle el entendimiento del modelo del Datawarehouse para su
negocio.
7.3 Diagrama Start Net
• Para dar inicio al desarrollo del modelo dimensional, se inicia con un

diagrama que nos muestra a través de líneas, círculos y rectángulos la
representación del modelo dimensional, en la parte izquierda encontramos
los indicadores que se caracterizan por ser métricas, los cuales se relaciona
con las dimensiones mostradas en la derecha y sus respectivos niveles.
• Ejemplo: Start Net expedientes
Este modelo nos permitirá obtener información estadística de

expediente, teniendo la posibilidad de extraer una serie de decisiones
asociadas y a partir de variables como: delitos, instancias, especialidad,
entre otros.
Los perfiles de análisis derivados serán diversos y dependerá de la
necesidad funcional de los usuarios en el poder judicial.
A continuación, se muestra el modelo:
7.4 Jerarquías
• Muestran las diferentes formas de visualizar una perspectiva del negocio.

Definiendo criterios de agrupamiento de los atributos de una dimensión.
• Las dimensiones se agrupan en jerarquías mediante relación uno-a-muchos.
• Por ejemplo:
Una población agrupa a muchos clientes.
Una provincia agrupa a muchas poblaciones.
Una región está formada por varias provincias, entre otras.

Diseño dimensional
• Las jerarquías típicas, que apareen en cualquier sistema de Business

Intelligence, son:
Jerarquía Geográfica o de clientes (país del

cliente/región/ciudad/cliente):
Jerarquía de productos (marca/familia/producto/presentación)
Jerarquía comercial (país/zona/punto de venta)
Jerarquía calendario (año/trimestre/mes/día)
• Evidentemente, pueden existir jerarquías adicionales, o incluso puede

haber diferentes maneras de jerarquizar una misma información.
• Esta manera de visualizar jerárquicamente la información resulta muy
natural y cómoda para los usuarios de negocio.
7.5 Modelo dimensional
• Una base de datos con “modelo dimensional” es una base de datos que
tiene una estructura adecuada para resolver consultas analíticas.
• Se trata de modelos sencillos que aseguran unos buenos tiempos de
respuesta, y que se corresponden bastante con el lenguaje de negocio de
los usuarios
• La implementación de una base de datos relacional, construirás el “modelo
dimensional” utilizando una estructura en estrella, o una estructura en
copo de nieve.
• Por ejemplo:
En un modelo estrella el diagrama de este modelo parece una estrella

con una tabla central alrededor de la cual se muestran un conjunto de
otras tablas.
La tabla central es la única tabla del esquema con varias uniones que la
conectan con todas las demás tablas.
Esta tabla central se denomina la tabla de hechos y las demás tablas se
denominan tablas de dimensiones.

La figura siguiente muestra un modelo dimensional sencillo de una
empresa que vende productos en distintos mercados y evalúa el
rendimiento de la empresa a lo largo del tiempo.

Diseño dimensional
 Ejemplo:
7.5.1 Tipos de tablas de hechos
a) SnapShot
− Cada período se agrega un registro para la entidad, sin

remplazar ni modificar la foto del período anterior.
− Ejemplo: balances, estados de resultados
b) Transaccional
− Un registro por cada evento, que ocurre en una fecha

determinada. Solo se pueden hacer inserciones.
− Ejemplo: sistemas de ventas

Diseño dimensional
c) Incremental
Un registro por cada ocurrencia, pero la fila contiene

múltiples fechas que indica el cambio de estados.
A diferencia de los anteriores, en este tipo de estructuras se

puede insertar y actualizar los registros.
Ejemplo: workflow, ticket de soporte
7.5.2 Dimensiones - Optimizar rendimiento de las consultas mejorando

los tiempos en las consultas
a) Mejorar los tiempos en las consultas
b) Agrupa varias dimensiones en una sola, el objetivo principal es

mejorar el rendimiento de la solución.
c) Ejemplo: tabla de clientes del modelo ejemplo
d) Ventajas
• Optimiza T° Respuesta
• Simplifica modelo para usuario final

Diseño dimensional
e) Desventajas
• Aumenta almacenamiento (no relevante)

• Complejiza proceso de carga del cubo
7.5.3 Dimensiones - Optimizar rendimiento de las consultas para

mejorar el almacenamiento
a) Factoriza (Tabla hechos o dimensiones):
• Cuando hay mucha información repetida en una tabla de

Hechos, es posible quitar esta información y “Factorizarla”
en una tabla de dimensión.
• Esto minimiza el espacio utilizado por la tabla de hechos y
mejora el análisis sobre los datos.
• Los campos candidatos son aquellos con baja cardinalidad.
7.5.4 Dimensiones - Optimizar rendimiento de las consultas

(Negocio)
a) Dimensión de roles
Cuando hay varios campos que hace referencia a la misma

dimensión, pero con conceptos diferentes.
Ejemplo:

Diseño dimensional
b) Súper dimensión
Cuando es necesario juntar dos dimensiones para generar

cálculos que de otra forma sería difícil de administrar.
Ejemplo:
7.5.5 Dimensiones - Información histórica (Negocio)
La dimensión puede cambiar con el tiempo (no estática): cambian

algunos atributos. En este caso es considerado inaceptable colocar
todo en la tabla de hechos o crear dimensiones dependientes.
Si el valor de un atributo cambia en el sistema operacional. ¿Cómo

responder a ese cambio en el modelo dimensional? En ese sentido,
existen varias alternativas las cuales se detalla a continuación:
a) Dimensiones que cambian lentamente Nº 1:
Sobrescribir el valor
Es fácil de implementar, pero no mantiene la historia de
los cambios los atributos.

Diseño dimensional
b) Dimensiones que cambian lentamente Nº 2:
Adicionar una fila a la dimensión

La clave de la dimensión es compuesta, registra, por cada
cambio en la fila de la dimensión (o los campos que sean
relevantes), un nuevo registro.
Es poderosa ya que la nueva fila divide automáticamente
la historia en la tabla de hechos. Sin embargo, no permite
asociar el nuevo valor del atributo con la historia de los
hechos y viceversa.
c) Dimensiones que cambian lentamente Nº 3:
Adicional una columna a la dimensión por cada columna

cuyo valor queremos mantener en la historia.
Es apropiado cuando se necesita soportar dos vistas del
mundo al mismo tiempo.
Es inapropiado si se desea hacer seguimiento de valores
intermedios de los atributos

Diseño dimensional
Menos usada

01 Material

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

01 Material

Cargado por

Copyright:

Formatos disponibles

Diseño dimensional

Al finalizar el capítulo, el alumno:

• Comprender los mecanismos de agregación.

IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 1

Ejemplo: proceso de negocio y medidas

IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 2

1.1 Clasificación de las medidas

• Las medidas naturales o básicas:

• Las medidas derivas o calculadas:

IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 3

1.2 Grado de agregación

Las medidas tienen propiedades que permiten definir su funcionamiento, así

El comportamiento de suma depende de la función de agregado especificada en la

Para la mayoría de las medidas que contienen datos numéricos, la función de

El grado de agregación de una función de agregación determina cómo se agrega la

• Una medida aditiva, también denominada medida completamente

• Una medida semiaditiva se puede agregar en algunas, pero no todas,

• Una medida no aditiva no se puede agregar en ninguna dimensión en

IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 4

• Por ejemplo, un margen de beneficio, no se puede agregar a partir de

En la siguiente tabla se enumeran las funciones de agregación y se describen el

IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 5

Son tablas que evitan la redundancia de estos atributos en la tabla de dimensiones.

IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 6

2.1 Tablas de hechos

­ Un Datamart está orientado a brindar a los usuarios información numérica,

­ Una tabla de hechos tiene las siguientes características:

 Es la tabla central en un esquema dimensional.

­ Las Fact tables pueden tener 4 tipos de columnas:

 Llave primaria (Primary Key). Columnas que identifican a cada miembro de

En el ejemplo anterior, las columnas Id_Fecha, Id_Producto y Id_Cliente

IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 7

 Estas columnas contienen claves foráneas que enlazan la tabla de hechos

IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 8

Determinar la granularidad de Tabla de Hechos y proceso empresarial. Durante este

Definir la tabla de hechos del modelo de negocio es identificar la granularidad de la

3.1 Definir la metadata del grano

• Una o más definiciones del grano para el proceso empresarial que se

IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 9

3.2 Definir la granularidad de la tabla de hechos (Fact Table)

Unificar documentos del negocio, como facturas, boletas y recibos de pedidos.

Para elegir el grano incluir las siguientes consideraciones:

• Durante esta fase recopilar los documentos necesarios, como facturas,

• Los documentos indican elementos importantes del negocio, por ejemplo:

• Un tema importante que se debe considerar es el tiempo (Fecha).

3.3 Administrar varios granos independientes

Puede existir varios granos asociados a un proceso de negocio que se definen

Se pueden administrar distintas granularidades de datos utilizando varias tablas

3.4 Asignar correctamente los tipos de tablas de hechos que se pueden

Definir el tipo de tabla de hechos implicada en el diseño del modelo dimensional.

3.5 Validar la atomicidad del grano

IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 10

El grano del modelo dimensional es de suma importancia cuando se diseña el

3.6 Identificar las tablas de dimensiones y medidas de alto nivel

IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 11

4. Criterios para agrupar la información

4.1 Tablas dimensión

­ Para entender el negocio, es fundamental conocer los valores de las ventas,

­ Por ejemplo, la medida ventas, por sí sola, no brinda suficiente información.

­ En este caso, tiempo, cliente, producto y distribuidor constituyen ejemplos de

­ Las dimensiones tienen múltiples criterios de agrupación. Por ejemplo, una

IES Cibertec S.A.C - Data Analytics Power BI – Nivel Intermedio 12

cada nivel se encuentra contenido en su nivel superior: una ciudad está

 En el ejemplo anterior el campo Producto_Key es la clave primaria de la

Un Datamart está orientado a brindar a los usuarios información numérica,

Una tabla de hechos tiene las siguientes características:

Las Fact tables pueden tener 4 tipos de columnas:

Para entender el negocio, es fundamental conocer los valores de las ventas,

Por ejemplo, la medida ventas, por sí sola, no brinda suficiente información.

En este caso, tiempo, cliente, producto y distribuidor constituyen ejemplos de

Las dimensiones tienen múltiples criterios de agrupación. Por ejemplo, una

El campo IDProducto sirve para conocer el identificador del producto en su

Las preguntas que nos permiten identificarlas son:

Posee los mejores tiempos de respuesta.

Este modelo es el menos robusto para la carga y es el más lento de construir.

Obsérvese el diagrama superior. Este modelo consta de cinco tablas de