01 Material

Diseño dimensional 1
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.
Temas
1. ¿Qué deseo medir?: Concepto de medida y tabla de hechos

2. ¿Qué criterios uso para agrupar la información?: concepto de dimensión, atributos,
jerarquías y relaciones.
3. Modelo dimensional
4. Tipos de modelo dimensional
5. Pasos del modelo dimensional
IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

1. ¿Qué deseo medir?: concepto de medida y tabla de hechos
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

 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

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.3 Semiaditivas
• 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.
• 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.

2. ¿Qué criterios uso para agrupar la información?: concepto de

dimensión, atributos, jerarquías y relaciones
2.1 Dimensión
• Es la parte cualitativa (características) de los reportes.

• Son las áreas temáticas o sujetos del negocio.
• 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
• 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
- 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.
 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
2.3 Relaciones entre tablas
 Para crear tablas relacionadas, puede 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.
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:

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

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

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:

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.

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.

3. Modelo dimensional
El modelo físico está compuesto de dos tipos de tablas: tablas dimensionales y tablas de
hechos.
3.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, productor 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

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:

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

 Contiene las claves externas (FK), que se relacionan con sus respectivas
tablas de dimensiones, y las columnas con los valores (métricas) que
serán analizados.
 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.
- 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.
 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.

4. Tipos de modelo dimensional
El modelo físico puede ser de dos tipos Star Schema (Modelo en estrella) o tipo Snowflake
(Copo de nieve).
4.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.
- 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:
- 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).

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

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

5. 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.
5.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
- 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:
5.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
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 Dimensión Dimensión Dimensión

… Dimensión N
Fact 1 2 3
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
- 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.
5.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:
5.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.
- 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.
5.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.

 Ejemplo:
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

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

e) Desventajas
• Aumenta almacenamiento (no relevante)

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

mejorar el almacenamiento
f) 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.
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

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:

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

01 Material

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

01 Material

Caricato da

Copyright:

Formati disponibili

Diseño dimensional 1

Al finalizar el capítulo, el alumno:

 Comprender los mecanismos de agregación.

1. ¿Qué deseo medir?: Concepto de medida y tabla de hechos

IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

1. ¿Qué deseo medir?: concepto de medida y tabla de hechos

Ejemplo: proceso de negocio y medidas

IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

1.1 Clasificación de las medidas

• Las medidas naturales o básicas:

• Las medidas derivas o calculadas:

IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

1.2 Grado de agregación

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 el grupo de

IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

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

IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

2. ¿Qué criterios uso para agrupar la información?: concepto de

• Es la parte cualitativa (características) de los reportes.

IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

• Ejemplo 1: Empresa Cadena de supermercados:

• Ejemplo 2: Proceso de negocio y dimensiones

IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

• Las dimensiones conformadas hacen posible que:

2.2 Atributos, jerarquías y niveles

 Los atributos son una agrupación de elementos o ítems dentro de una

 Ejemplo: atributos de la dimensión Geografía

 Los atributos son una agrupación de elementos o ítems dentro de una

IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

 La finalidad de los atributos es ver la información de cada dimensión a

2.3 Relaciones entre tablas

Campos utilizados en relaciones

 Un campo de coincidencia puede ser un campo o una combinación de campos

 Una clave es un tipo de campo de coincidencia. Por lo general, las claves

IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

Un campo que se encuentra en la misma tabla que el registro que

Un campo de una tabla que identifica un registro de otra tabla. Los

o Ejemplo: En una base de datos Ventas, la tabla Clientes y la tabla

Las relaciones fomentan la introducción de datos coherentes y aplican reglas en la

Tipo de Relación Descripción Breve

IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

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

o Una relación de uno a uno presenta el siguiente aspecto en el gráfico de

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

o Esta relación devuelve registros relacionados cuando el valor del campo

b) Relaciones de uno a muchos

o En una relación de uno a muchos, un registro de una tabla se puede

o Una relación de uno a muchos presenta el siguiente aspecto en el

IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

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

o Esta relación devuelve registros relacionados cuando el valor del campo

c) Relaciones de muchos a muchos

o Una relación de muchos a muchos se produce cuando varios registros

o Por lo general, los sistemas de bases de datos relacionales no permiten

IES Privado Cibertec S.A.C - Data Analytics - Power BI Cloud

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

o Cada registro de una tabla de unión incluye un campo de coincidencia

o Un ejemplo típico de una relación de muchos a muchos es aquella entre