Semana 2

Agenda

• Conceptos de Modelamiento Dimensional

• Desarrollo de Casos de Modelamiento
• Conceptos de Modelamiento Avanzado
Dimensional
 Fases en el Diseño de un Data
Warehouse
I. Definir el Modelo de Negocios (Modelo
Conceptual)
II. Crear el Modelo Dimensional (Modelo
Lógico)
III. Crear el Modelo Físico
IV. Modelar Sumarias
 Diferencias con un modelo
OLTP
A diferencia de un diseño para una base de datos
OLTP, el modelo del Warehouse:
• Focalizado en las consultas
• Desarrollo incremental
• Estructura dinámica
• Data Histórica
 Retos en el diseño

• Requerimientos de consultas variables

• Tiempos de respuesta
• Administrar volúmenes grandes de datos
• Costos de operación e interface
• Control de interfaces y herramientas
• Backup y Restauración
 Business Modeling Checklist

Fase I: Definir el Modelo de Negocio

Realizar el análisis estratégico
Crear el modelo de Negocio
 Análisis de la Estrategia

Desarrollar el análisis de la estrategia

– Identificar los procesos del negocio
– Entender los procesos del negocio
– Priorizar y seleccionar los procesos a seleccionar
 Procesos del Negocio identificados

Inca Video Rent:

Empresa dedicada al alquiler de videos y video
juegos.

 Alquiler
 Devoluciones
 Agotamiento
 Resultados de oficinas
 Revisión de los procesos de negocio:
Medidas y Dimensiones de Negocio
Dimensiones
de Negocio Medidas

 Cantidad de Alquileres
 Tienda
 Importe de Alquiler
 Producto
 Costo de Alquiler
 Fecha
 Ganancias
 Cliente
 Matriz de Procesos de Negocio
Inca Video Rent: Matriz del Proceso de Negocio

Dimensiones Alquileres Retornos Agotadas Resultados

de Negocio de oficina

Alquiler Date X
Retorno Date X
Alquiler Time X
Retorno Time X
Tienda X X X
Producto X
X X X
Cliente X X
 Seleccionar el Proceso de Negocio
 Cual me retornará el mejor ROI?
 Cual me dará el mayor valor estratégico?
 Que tipo de decisiones de negocio podré hacer
con la información?
 Cual es el más simple de implementar?
 Cuanto tiempo puede tomar implementar el
proceso evaluado?
 Creando el Modelo de Negocio

– Definir los requerimientos de negocio

• Definir las medidas del negocio
• Definir los parámetros de análisis
• Identificar el grano
• Identificar las reglas de negocio
– Verificar las fuentes de datos
 Documentar los elementos del modelo
de negocio

Para el proceso seleccionado documentar:

 Una lista de las medidas de negocio
 Detallar la lista de cada dimensión del
negocio
 Definir las reglas de negocio
 Dimensiones del Negocio
Día Producto Cliente Tienda
Fecha Producto Cliente Tienda
Mes Categoría Estado Distrito
Año Tipo Nivel de actividad
Región
Fin de semana Estado Tipo de preferencia.
Tamaño
Feriado Mdia Año del film. Cate Pelicula pref.
Feriado Dia Periodo de renta Edad Pelicula pref.
Cate Juego pref.
Edad Juego pref.
 Identificando las Reglas de Negocio

Producto
Tipo categoría Estado
Tienda Pelicula Drama Nueva
Regla: Una tienda es en solo Juego Comedia Reciente
un distrito Acción Vieja
Familiar
Regla: Un registro pertenece a .
una única región. .
.
Regla: Un video solo puede pertenecer
a una categoría de producto.
Regla: Una categoría de producto
pertenece a solo un tipo de producto
 Modelo Lógico de datos
Un modelo de datos que representa la
estructura inherente de los datos. Es
independiente de las aplicaciones
individuales de los datos y también del
software o hardware empleado para
representar y usar la data.
El modelo lógico de datos es enllavado y
atribuido.
 Crear el Modelo Dimensional

Fase II: Crear el Modelo Dimensional (Modelo

Lógico)
Analizar los sistemas fuentes
Identificar las fact tables
• Trasladar las medidas del negocio en las tablas Fact
• Identificar las medidas base y las dericadas
• Documentar la adición de las medidas
Identificar las tablas de dimensión
Relacionar las Fact y las tablas de dimensión
 Modelo Lógico
Dia ID (PK) Producto ID (PK)
Dia ID Producto ID
Dia Desc Producto Desc
Fin de Semana Categoria ID
Feriado TD Categoria Desc
Feriado MD Tipo ID
Mes ID Tipo Desc
Mes Desc Estado
Año ID Edad de Clasificación
Año Desc Alquiler Periodo de Renta
Dia ID (FK)
Cliente ID (FK)
Producto ID (FK)
Tienda ID (FK)
Cliente ID (PK)
Tienda ID (PK)
Cantidad de Alquileres
Cliente ID Tienda ID
Nombre Cliente Importe de Alquiler Tienda Desc
Estado Localización
Costo de Alquiler
Nivel de Actividad Tamaño
Tipo Ganancias
Distrito ID
Cat Pelicula Pref Distrito Desc
Cat Edad Pref Region ID
Cat Juego Pref Region Desc
Cat Edad Pref
 Estructura Star Schema
Modelo Estrella
• Definición de Star Schema:
Un modelo de datos relacional
desnormalizado, organizado alrededor
de una tabla central (hechos) unidas
algunas pocas tablas pequeñas
(dimensiones) a través de relaciones
con llaves foraneas...
 El Esquema en Estrella
Tablas
Dimensionales

Producto_id Tabla Tabla Cliente_id

,PK Producto Cliente
, PK
Llave Primaria está
Tabla de Hechos (Fact Table) compuesto de todas
las otras llaves

Tiempo, Tabla Tabla Tienda_id,

PK Tiempo Tienda PK
 Consideraciones del Star
Schema
• Organización del modelo de datos
– Debe lucir como el negocio
– Reconocido por los tipos del negocio
– Aprobado por la gente del negocio
• Tres reglas de diseño para el modelamiento de
Start Schema:
– Simple
– Simple
– Simple
Configuración Constelación

Atomic Fact
 Ventajas de Usar un Modelo
Dimensional
• Soporta análisis multidimensional.
• Crea un diseño de Base de Datos que mejora la
performance
• Modelos de datos sencillos y claros para el usuario.
• Paralelo entre los modelos y la manera como el usuario
piensa y como usa la data.
• Provee un modelo extendido que soporta cambios en los
requerimientos del negocio. Da flexibilidad a las
consultas.
• Soportado por un gran número de herramientas de
acceso a Base de Datos, que requieren de un modelo
Estrella.
 Pasos para crear un modelo
dimensional
1. Identificar medidas
Que medidas son necesarias para el análisis
2. Identificar dimensiones y jerarquías
Dimensiones, jerarquías, elemento,
asociaciones
3. Determinar granularidad de la fact table
4. Verificar el modelo con el usuario refinarlo
El usuario puede entender el modelo y lo
aprueba
 Hechos - Facts
• Una Fact Table puede ser definida como:
La tabla central en un esquema del tipo join
start. Esta contiene las medidas del negocio
que aparecen en los reportes o son
manipulables. Los hechos son diseñados
como atributos en la entidad lógica y como
columnas en la estructura física.
El Fact son definidos como eventos que son
descritos por medidas y una llave compuesta
 Mas acerca de fact tables...
• Tienden a ser entidades flacas con pocos atributos
• Tienden a reflejar el número de transacciones
• Soportan los procesos del negocio
• A menudo son tablas muy grandes que tienden a
crecer rápidamente.
• Puede contener datos básicos, derivados o
sumarizados.
• Se relacionan con las dimensiones a través de sus
llaves foráneas
• Ejemplos:
– Embarques de paquetes, Llamadas de larga distancia,
Compras, Ventas, diarias, semanales, mensuales
 Identificar medidas Base y
Derivadas
• Identificar los facts candidatos
• Remover los facts duplicados
• Describir y documentar las fórmulas de cálculo para las
medidas derivadas.
• Realizar un cruce referencial con las facts, para ver si
contienen las medidas requeridas para el cálculo.
• Obtener la aprobación final para los datos derivados.
 Datos Básicos y Derivados

Tabla de planillas
Emp_Id Mes_Id Salario Com IngB
101 05 1,000 1,000
102 05 1,500 100 1,600
103 05 1,000 200 1,200
104 05 1,500 1,000 2,500

Datos Datos
Básicos Derivados
 Tipos de Medidas en la Tabla
Fact
Aditivas: Semiaditivas: No-aditivas:
Agregadas a Agregadas sobre No pueden ser
través de todas las algunas dimensiones agregadas sobre
dimensiones ninguna dimensión
 Las tablas de dimensión...
• Una tabla de dimensión puede ser
definida como:
– Son las tablas alrededor de la fact table en el
start schema, que contiene los atributos que
describen las dimensiones de la fact tables.
Esas tablas son similares a las referencias o
lookup tables.
 Mas acerca de las
Dimensiones
• Se caracterizan por tener una llave simple, Los atributos
tienden a ser textuales y a menudo una fuente de constrains
• Dimensiones son muchas veces relacionados en jerarquías.
• Son definidas para ser entendidas por los usuarios
• Son anchas con muchos atributos descriptivos
• Tienen mucho menos registros que las fact table
• Ellas tipicamente representan mas del 90% de los datos
atribuidos en el sistema
• Atributos comunmente generan constrains o clausulas de
agregaciones
• Son altamente indexados
• Ejemplo :
– Geografía, Producto, tienda, cliente, tiempo, etc.
 Tipos de Llaves en la Base de
Datos
• Llave primaria (PKs)
• Llave foránea (FKs)
• Llave compuesta
• Llave artificial
 Uso de Llaves artificiales

Ventaja de incluir llaves artificiales:

• Control sobre la data Llave Artificial
• Reduce el tamaño de la tabla fact
Product Key: 38972

Evitar usar las siguientes llaves como llave del Warehouse:

• Llaves naturales de producción (OLTP)
• Llaves inteligentes, con significado embebido (smart
key)
 Ejemplo de Llaves Artificiales

Emp_Ak Vendedor_ID Vendedor_Nombre Gerente_ID

1 100 Smith 201
2 201 Jones 300
3 311 Harvey 300
22 100 Smith 400

Prod_AK Producto_ID Producto_Nombre Marca_Cod

1 126-7878 Cereal NES
2 125-9889 Cafe NES
3 125-9889 Cafe ALP
4 766-1288 Bebida Gaseosa KR

10/10/2021 34
 Agregando Artificial PKs a las
Tablas de Dimensión
Dia Key (PK)

Dia Desc Producto Key (PK)

Fin de Semana
Producto ID
Feriado
Producto Desc
Feriado MD Categoria ID
Mes ID Categoria Desc
Mes Desc
Artificial PKs Tipo ID
Año ID Tipo Desc
Año Desc Fact Alquiler Estado
Clasificacion
Numero de Alquiler Periodo de
Importe de Alquiler Alquiler
Cliente Key (PK) Costo Alquiler
Ganancia
Cliente ID
Tienda Key (PK)
Nombre del Cliente
Estado Tienda ID
Nivel de Actividad Tienda Desc
Tipo Localización
Cat Pelicula Pref Tamaño
Edad Pelicula Pref Distrito ID
Cat Juego Pref Distrito Desc
Edad Juego Pref Region ID
Region Desc
 Identificar Jerarquías de
Análisis
Las Jerarquías del Negocio describen la organización de los datos
y ayudan a mejorar el análisis de los datos.
La Jerarquía señala una relación de padre-hijo entre los atributos.
Es almacenada en las tablas de dimensión.
Dimension Tienda Jerarquía de la organización

Tienda ID Region
Tienda Desc
Localización
Tamaño
Distrito ID
Distrito Desc Distrito
Region ID
Region Desc

Tienda

10/10/2021 36
 Múltiples Jerarquías

Dimensión Tienda

Tienda ID
Tienda Desc Jerarquía de la Jerarquía de la
Localización organización Geografía
Tamaño
Distrito ID Distrito Region Estado
Desc
Region ID
Region Desc
Ciudad ID Distrito País
Ciudad Desc
Pais ID
Pais Desc
Estado ID Tienda Ciudad
Estado Desc

10/10/2021 37
 Múltiple Jerarquía del tiempo

Jerarquía del tiempo Fiscal Jerarquía del tiempo calendario

Año Fiscal Año Calendario

Trimestre Fiscal Trimestre Calendario

Mes Fiscal Mes Calendario

Semana Fiscal Semana Calendario

10/10/2021 38
 Drilling Up y Drilling Down
Jerarquía de Tienda

Tienda

Region 1 Region 2

Distrito 1 Distrito 2 Distrito 3 Distrito 4

Tienda 1 Tienda 2 Tienda 3 Tienda 4 Tienda 5 Tienda 6 Tienda 7

10/10/2021 39
 El grano del data
warehouse
• Determina el mas bajo nivel de detalle de la fact
table
• Determina la dimensionalidad del DW
Comenzar con grano fino…muy explotable
Granos grandes ocultan mucha información que
no puede ser servida al DW
 Documentar la granularidad de
la Dimensión
• Es una importante consideración de diseño
• Determinar el nivel de detalle
• La granularidad es determinada por las reglas de
negocio

Grano de Bajo Nivel Grano de Alto Nivel

(Datos a nivel de Transaccion) (Data Sumarizada)

10/10/2021 41
 Definir la granularidad del
tiempo
Jerarquía Tiempo Fiscal
Año Fiscal

Trimestre Fiscal

Mes Fiscal

Semana Fiscal actual grano de la dimension

Dia Futuro grano de la

dimension
 El Snowflake schema o
Copo de Nieve
• Un Snowflake schema es similar a un star
excepto:
– Desarrollar un “snowflake” requiere construir
clases de jerarquías para cada dimensión
(normalizando las dimensiones en una
estructura de árbol)
– Puede no resultar intuitivo para el usuario de
negocio
– Puede degradar el performance.
 El Snowflake Schema

Tabla Tabla Tabla Clase

Categoria Producto Cliente de Cliente

Tabla de Hechos (Fact)

Periodo del Tabla Tabla Tienda

Tiempo Tiempo Direccion
Una variación del clasico Star Schema
donde una dimensión plana es
descompuesta en una estructura de árbol,
con mas de un nivel añadido.
 Es recomendable el
Snowflake?
• Porque SI
– Típicamente snowflaking puede salvar espacio al no
almacenar data redundante
– Algunas veces algunas de las jerarquías de la
dimensión cambian cuando una dimensión es
normalizada
• Porque NO
– Snowflakes no es intuitivo para el usuario como el
Star…
– Implica generalmente mas joins que degradan la
performance.
La conclusión es que debes evitar el Snowflake !!!
 Una Gran Tabla de Hechos
(Fact Table)
 Pros:  Cons:
– Muchas dimensiones apuntan
– Toda la data en un
solo lugar a un gran número de rows
– Sumarizar será a menudo
– Pocos joins
necesario
– Fácil de modelar – Puede confundir al usuario
– Puede resultar una data
esparcida
– Puede haber refresco de un
dato mas frecuente que otos
 Múltiples fact tables
 Pros:  Cons:
– Tablas contienen poco – Joins pueden ser
registro necesarios
– Data es organizada – Joins pueden causar
alrededor de un uso problemas de
performance
– Data es mas entendible
– El modelo de datos se
– Performance es mejor puede volver mas
– Puede salvar espacio, complejo y duro de
porque la data no estará entender
esparcida
 Nivel de Transaccion Level Vs
Nivel Snapshot

 Transaction level: Refleja el estado del

negocio por transacción básica
 Snapshot level: Refleja el estado del
negocio para diferentes tiempos
 Tablas Factless

Asistencia

FK Estudiante No.
FK Profesor No.
Profesor
Estudiante

Estudiante No. Profesor No.

 Cambio en las dimensiones
 Algunas dimensiones cambian en el tiempo, para
lo cual se tiene las siguientes opciones:
– Sobreescribir el atributo o cambiar completamente la
dimensión
– Poner un dato de fecha en la llave de la estructura
– Agregar el nuevo atributo a la fact y una nueva
dimensiones también
– Generar un llave artificial
 Dimensiones Agrupadas
(Brackets)
• Usadas para mejorar la performance y la
capacidad de análisis.
• Crea grupo de valores para atributos con
varios valores únicos, como rango de
ingresos y grupos de edades
• Minimiza la necesidad de buscar sobre
todas las tablas por data preagregada

10/10/2021 51
 Dimensiones Agrupadas
Dimensión Agrupadas

Fact de Ingresos AgruCli_Key (PK)

Cliente_Key (FK)
AgruCli_Key (FK) Dimensión Cliente
Customer_Key (PK)
AgruCli_Key (FK)

AgruCli_Key Ingresos Estado Civil Genero Edad

1 10K-20K Divorced Male < 21
2 10K-20K Divorced Male 21-35
3 10K-20K Divorced Male 35-55
4 10K-20K Divorced Male > 55
5 10K-20K Divorced Female < 21
6 10K-20K Divorced Female 21-35

10/10/2021 52
 Tipos especiales de
dimensiones
• Mini-dimensions
• Dirty dimensions
• Degenerate dimensions
 Mini-Dimension Ejemplos
Cliente
Fact Table
Cod de cliente
Nombre del
Cod de Cliente
cliente
Cod Demogr
Cod Demogr

...
Demografico

Cod Demogr
Nivel de Ingreso
Estado Civil
Slowly Changing Dimension

Customer
MOVED!
101
Joe Smith Av.Arequipa 110
Av. Javier Prado
1223
IL
 ¿Qué es una tabla Sumaria?

• Almacenamiento de data presumarizada

• Son basadas en los requerimientos del usuario

Ventas
Region
Sumaria
Estado Ventas

Ciudad

Tiempo Producto

10/10/2021 57
 Tablas Sumarias o
Agregadas

Año

Mes

Día

Producto Límea de Marca

Producto
 Por que sumarizara datos?

Mejora las consultas

Tiempos de respuesta

Optimiza la utilización de recursos

Facilita los procesos de análisis

 Un ejemplo
Sin sumaria

Scan
Tienda
Ventas 100 tiendas
Tiempo fact table
1095
dias 109,500,000 Producto
filas 10,000 productos
Total ventas por año

Con sumaria

Tienda
Ventas
100 tiendas
tabla
Año sumaria
3 años
3,000,000
Producto
filas
10,000 productos

10/10/2021 60
 Jerarquías de los atributos

Dimension Producto: Dimension Tienda:

Una jerarquía Dos jerarquías

Total Total Total

Clase Clase Region Region Estado Estado

Grupo Grupo Distrito Distrito Ciudad Ciudad

Producto Tienda Tienda

Jerarquia de Mercado Jerarquia Geografica

10/10/2021 61
 Sumarias de N-vías
Una vía
Year T3 Cat. S3 Region Total sales
Month T2 P2 S2 District by year,
by item,
Day T1 P1 S1 Store by store
Item
Dos vías Total sales
T3 S3
by day,
T2 P2 S2 by category,
by region
T1 P1 S1

Tres vías
T3 S3 Total sales
by month,
T2 P2 S2 by category,
by region
T1 P1 S1
10/10/2021 62
 Dos alternativas de diseño
Fundamentalmente dos aproximaciones para las
tablas sumarias:
• Multiple sumarias fact tables (constelacion)
• Una gran fact table con detalle de fact data y
data sumarizada almacenada en la misma tabla

10/10/2021 63
 Constelacion
Tablas
Dimensionales
Sumarias

Sumarias
fact

Atomic fact

10/10/2021 64
 Sumaria de una vía: Distrito

Sumaria fact table

(por distrito)
d

Distrito (Tienda)
sumaria
P C Tabla Dimensional

Td T

Atomic fact table

10/10/2021 65
 Sumaria de dos vías: Categoria
y Distrito
Categoria (producto)
Sumaria fact table
sumaria
(por categoria y distrito)
dimension table

c d

Distrito (tienda)
P C
sumaria
dimension table

S T

Atomic fact table

10/10/2021 66
 Restricciones en la
sumarización
De tamaño

De la ventana de carga
 Escogiendo las sumarias

Seis dimensiones
Con diferentes jerarquías

10/10/2021 68
 Navegación a través de las
sumarias
• Se requiere de un conocimiento para un uso efectivo de
las tablas sumarias.
• Métodos para la navegación:
– Engine del Data Base
– A través del engine de las herramientas de explotación
– 4GL desarrollados con lógica compleja

select total_sales...

Which
summaries?
 Guía para la agregación

• Construye agregadas para subjects

altamente usados
• Construye agregadas para
sumarizaciones densas de datos.
• Construir agregadas que puedan
responder un amplio rango de
preguntas.
 Conclusión

• Los modelos dimensionales están orientados al

negocio
• Estos modelos permiten facilidad y flexibilidad
por el usuario de negocio
• Los modelos dimensionales permitirán la
construcción de los cubos de informacion