Modelo Dimensional

Construcción Data Warehouse

Modelado Físico
Debemos pasar el modelo lógico que hicimos (conceptual), al modelo físico
(tablas de una BD). Al igual que un DER de un sistema transaccional habrá
cambios en este pasaje lógico a físico. Para realizar esta tarea existen
diferentes técnicas de modelado según la realidad del negocios

➢ Armar un modelo físico es dar un soporte en tablas a todos los

objetos identificados en el modelo multidimensional

➢ Lo que se define en esta etapa son las tablas del Data Warehouse
(DW)

➢ El modelo físico se compone exclusivamente de tablas y columnas

Tablas LookLook
UpUp (LK_)
Tablas Relación (REL_) Base (BT_)
De hechos / Fact tables
Aggregate (AGG_)

Las tablas de look up o tablas maestras son las

que almacenan los elementos de un atributo
➢ Podemos crear una tabla de look up por cada atributo (lo que se conoce
como esquema snowflake o copo de nieve) o una tabla por dimensión (lo
que se conoce como esquema star o estrella)

➢ Tienen una columna por attribute form + una columna por cada padre
(del atributo)
Tablas de Relación
Look Up (LK_)
Tablas Relación (REL_) Base (BT_)
De hechos / Fact tables
Aggregate (AGG_)

Las tablas de relación se utilizan cuando hay

una relación muchos a muchos entre dos
atributos
Tablas de Hechos
Look Up (LK_)
Tablas Relación (REL_) Base (BT_)
De hechos / Fact tables
Aggregate (AGG_)

Las tablas de hechos o fact tables son las que

almacenan los valores de los hechos
➢ Son las tablas de mayor cantidad de filas (ocupan más del 90% del
data warehouse)

➢ Tienen una columna por cada hecho + una columna por cada
atributo del nivel al cual se conocen los hechos
Tablas de Hechos
Look Up (LK_)
Tablas Relación (REL_) Base (BT_)
De hechos / Fact tables
Aggregate (AGG_)
Las tablas base o base tables son las que
guardan los hechos al mínimo nivel de detalle.
➢ Son imprescindibles en términos de información

➢ Habrá tantas tablas de hechos como conjunto de hechos se conozcan al

mismo nivel
➢ En general tienen una gran cantidad de filas

➢ Sus filas se llenan a partir de los datos que provienen de los sistemas OLTP
Tablas de Hechos
Look Up (LK_)
Tablas Relación (REL_) Base (BT_)
De hechos / Fact tables
Aggregate (AGG_)

Las tablas agregadas se crean exclusivamente

para reducir el tiempo de respuesta de las consultas
➢ Son prescindibles en términos de información (no dicen nada que no
sea dicho por una tabla base ... Pero lo que dicen lo dicen más rápido)

➢ En general tienen pocas filas

➢ Su contenido se calcula a partir de las tablas base

 Ejemplo: Tablas Look Up
1, Santa Fe
Provincia 2, Buenos Aires
@ID 3, Chubut
@DESC

LK_PROVINCIA
Provincia_SK Provincia_DESC
1 Santa Fe
Una fila por elemento del
2 Buenos Aires atributo
3 Chubut
... ...

Una columna por attribute form

Ejemplo: Tablas Look Up
LK_CIUDAD
Provincia
Ciudad_SK Ciudad_DESC Provincia_SK

11 Junín 1
Ciudad
@ID
12 Pehuajó 1
@DESC
31 Paso del Sapo 3

Una columna por Una columna por cada

attribute form + padre
Ejemplo: Tablas de Hechos
Empleado Día Artículo

Ventas $

Unidades Vendidas

BT_VENTAS_EMP_DIA_ART
Empleado_SK Dia_SK Articulo_SK Ventas_$ Unid_Vend
111 20130102 17 $2 4
112 20130102 17 $4 8
113 20130102 17 $4 8
... ... ... ... ...
 Ejemplo: Tablas Agregadas
BT_VENTAS_EMP_DIA_ART
Empleado_SK Dia_SK Articulo_SK Ventas_$ Unid_Vend
111 20130102 17 $2 4
112 20130104 17 $4 8
113 20130107 17 $4 8
... ... ... ... ...

AGG_VENTAS_EMP_MES
Empleado_SK Mes_SK Ventas_$ Unid_Vend
111 201301 $4,200 315
112 201301 $6,700 405
113 201301 $8,200 617
... ... ... ...
Ventajas del modelado dimensional
✓ Fácil de extender

➢ Agregar un nuevo hecho no planeado, siempre y cuando sea compatible

con la granularidad ya definida

➢ Agregar una nueva dimensión teniendo en cuenta que un único valor de

la dimensión esté relacionado con los hechos de la tabla

➢ Agregar en una dimensión un atributo que no había sido planeado

➢ Romper una dimensión existente llevándola a un nivel de granularidad

menor a partir de un momento dado
Surrogate Key
“Es aconsejable no usar como claves los códigos de producción”

Las SK eliminan los siguientes problemas

➢ En producción se pueden usar códigos que se habían depurado y aún

existen en el dw

➢ En producción puede cambiar la descripción de un producto o

cliente, sin cambiar el código que lo representa.

➢ Producción podría cambiar el formato de sus claves, por ejemplo de

ser numéricas a ser alfanuméricas.

✓ Las claves de las tablas ocuparán menos espacio.

✓ Son más fáciles de mantener.

Star Schema
Dimensión Item
SALES_TRANS
Category Sale_Date_sk
ITEM
Store_sk
Item_sk
Item_sk
Item_id
Genre Cust_sk
Item_Name
Sales Amt
Category_Name
Sales Unit
Genre_Name

Item

➢ Una tabla por dimensión

➢ Hay menos tablas involucradas
➢ Los queries son más fáciles de construir
➢ Los queries son resueltos más rápidos porque se necesita acceder a
menos tablas (aunque mas uso del DISTINCT)
Snowflake Schema
CATEGORY
➢ Más difícil de entender para el usuario final Category_sk
Category_Name
➢ Más lento para traer datos
➢ Son más fáciles de llenar las tablas
➢ Mayor número de tablas GENRE
Secondary Genre_sk
Dimension Genre_Name
Category_sk
Dimensión Item

Category ITEM
Primary Item_sk
Dimension Item_Name
Genre_sk
Genre

SALES_TRANS
Sale_Date_sk
Item Fact Table Store_sk
Item_sk
Cust_sk
Sales Amt
Sales Unit
Snowflake Schema
Completamente normalizado
✓Las tablas lookup contienen el id propio, la descripción y CATEGORY
el id del padre. Category_sk
Category_Name

✓Se minimiza la redundancia de datos y espacio de

almacenamiento. GENRE
Genre_sk
Genre_Name
Category_sk
✓Requiere numerosos joins si quiero datos de las tablas de
más alto nivel.

SALES_TRANS
Sale_Date_sk
ITEM
Store_sk
Item_sk
Item_sk
Item_Name
Cust_sk
Genre_sk
Sales Amt
Sales Unit
Snowflake Schema
Moderadamente Normalizado
✓Las tablas lookup tienen el id propio, su CATEGORY
descripción, y todos los id de sus ancestros Category_sk
Category_Name

✓Reduce significativamente la cantidad e joins

para consultar datos dentro de la jerarquía. GENRE
Genre_sk
Genre_Name
✓Hay algo de redundancia. Category_sk

SALES_TRANS
Sale_Date_sk ITEM
Store_sk Item_sk
Item_sk Item_Name
Cust_sk Genre_sk
Sales Amt Category_sk
Sales Unit
Snowflake Schema
Completamente Desnormalizado
CATEGORY
Category_sk
✓Las tablas lookup tienen el id propio, su descripción, y Category_Name
todos los id y descripciones de sus ancestros

✓Elimina del todo los joins para buscar las GENRE

descripciones de los diferentes niveles Genre_sk
Genre_Name
Category_sk
Category_Name
✓Ocupa mucho espacio de almacenamiento.

SALES_TRANS ITEM
Sale_Date_sk Item_sk
Store_sk Item_Name
Item_sk Genre_sk
Cust_sk Genre_Name
Sales Amt Category_sk
Sales Unit Category_Name
Tipos de Hechos
✓ Aditivos: son hechos que pueden ser sumados a través de todas las
dimensiones.
✓ Semi aditivos: se pueden sumar en algunas dimensiones y en otras
no.
✓ No aditivos: no tienen sentidos de ser sumadas.

• Tabla de tipo Acumulativa

• Hechos aditivos • Tabla de tipo Snapshot
• Hecho semi aditivo
• Hecho no aditivo

SALES_TRANS
Sale_Date_sk
Store_id_sk BALANCE
Item_sk Balance_Date_sk
Sales Amt Account_sk
Sales Unit Current Balance
Profit Margin
Tipos de Fact Tables
➢ Acumulativas: describen que fue pasando durante un periodo de tiempo.
Por lo general: los hechos son en su mayoría aditivos

➢ Snapshot: describen el estado de algo en un momento determinado.

Por lo general: los hechos son no aditivas y semi aditivos

Id_atributos
SALES_TRANS Indicarán la granularidad
Sale_Date_sk
Store_sk
Item_sk
Cust_sk

Sales Amt
Sales Unit

Facts
Slowly Changing Dimensions
➢ Los códigos no cambian pero las descripciones si. No cambian todos los
días, sino que lo hacen ocasionalmente.
Tipo 1: Reescribo el registro perdiendo el valor anterior

• V: Es la forma mas fácil de manejar los cambios.

• D: Se pierde la historia.

SK_Cliente Id_cliente Cod_cliente Nombre Dirección Estado_civil

1 67 JC Juan Cameli Av. Corrientes 3859 Soltero

3° A

Juan se casa, entonces…

SK_Cliente Id_cliente Cod_cliente Nombre Dirección Estado_civil
1 67 JC Juan Cameli Av. Corrientes 3859 Casado
3° A
Slowly Changing Dimensions
Tipo 2: Inserto un nuevo registro con otra SK.

• V: Permite guardar toda la historia de cambios.

• D: La tabla crece mucho y puede complicar la carga del ETL.

SK_Cliente Id_cliente Cod_cliente Nombre Dirección Estado_civil

1 67 JC Juan Cameli Av. Corrientes 3859 Soltero
3° A

Juan se casa, entonces…

SK_Cliente Id_cliente Cod_cliente Nombre Dirección Estado_civil
1 67 JC Juan Cameli Av. Corrientes 3859 Soltero
3° A
5 67 JC Juan Cameli Av. Corrientes 3859 Casado
3° A
Slowly Changing Dimensions
Necesito poner alguna marca para saber cuando se cambio o cual se cambio
primero.
SK_Cliente Id_cliente Cod_cliente Nombre Dirección Estado_civil Start_Date End_Date

1 67 JC Juan Av. Corrientes Soltero 10/05/2010 14/02/2011

Cameli 3859 3° A

5 67 JC Juan Av. Corrientes Casado 15/02/2011

Cameli 3859 3° A

Otra forma…
SK_Cliente Id_cliente Cod_cliente Nombre Dirección Estado_civil Versión

1 67 JC Juan Av. Corrientes Soltero 1

Cameli 3859 3° A

5 67 JC Juan Av. Corrientes Casado 2

Cameli 3859 3° A

10 67 JC Juan Av. Corrientes Divorciado 3

Cameli 3859 3° A
Slowly Changing Dimensions
Tipo 3: Utilizo un campo “anterior” para guardar el valor original

• V: No incrementa el tamaño de la tabla.

• D: Solo guarda el último valor

SK_Cliente Id_cliente Cod_cliente Nombre Dirección Estado_civil

1 67 JC Juan Cameli Av. Corrientes 3859 3° Soltero

A

Juan se casa, entonces…

SK_Cliente Id_cliente Cod_cliente Nombre Dirección EC_act Fecha EC_ant

1 67 JC Juan Av. Corrientes Casado 15/02/2011 Soltero

Cameli 3859 3° A
Rapidily Changing Monster Dimensions
Característica: Las dimensiones son muy grandes y las descripciones
cambian todos los días
Acción
LK_CLIENTE •Partir la dimensión en 2
SK_cliente •Llevar los atributos dinámicos a rangos

Id_Cliente
FACT_TABLE
Nombre
SK_cliente
Dirección
SK_.....
Fecha Nac
SK_.....
Ingresos
Hechos
Nivel_Educacion

Cantidad_Hijos Desventajas
• Pierdo nivel de información
Estado_Civil • Para navegar jerarquías tengo que pasar por la fact
Puntaje_Credito

Puntaje_Compras
Rapidily Changing Monster Dimensions
1° Separo los atributos “estáticos” de los “dinámicos”

LK_CLIENTE
FACT_TABLE
SK_cliente
Estáticos SK_Cliente
Id_Cliente
SK_Demografia
Nombre
LK_DEMOGRAFIA SK_.....
Dirección
SK_demografia Hechos
Fecha Nac
Ingresos

Nivel_Educacion

Cantidad_Hijos

Dinámicos Estado_Civil

Puntaje_Credito

Puntaje_Compras
Rapidily Changing Monster Dimensions
Puede pasar que los rangos que utilizo sean muchos y la dimensión
LK_DEMOGRAFÍA termine siendo muy grande… Entonces separo los
atributos dinámicos de los volátiles.

LK_CLIENTE FACT_TABLE
Estáticos SK_cliente SK_cliente
Id_Cliente SK_demografia
Nombre SK_cred_comp
Dirección Hechos
LK_DEMOGRAFIA
Fecha Nac
SK_demografia
LK_CRED_COMP
Ingresos

Nivel_Educacion SK_cred_comp
Dinámicos Volátiles
Cantidad_Hijos Puntaje_Credito

Estado_Civil Puntaje_Compras
Rapidily Changing Monster Dimensions
En definitiva cuando una dimensión es muy grande y tiene
muchos cambios podríamos:

✓ Dejarla tal como está

✓ Separar las dimensiones en valores estáticos y

dinámicos

✓ Separar los valores en estáticos, dinámicos y volátiles

✓ Contemplar la posibilidad de llevar el atributo volátil a la

fact table
Degenerate Dimensions
La dimensión la creo directamente desde la fact, no cargo una LK para esa
dimensión

TIEMPO
CLIENTE

FACT_VENTA

COMPROBANTE PRODUCTO

Granularidad
• Comprobante, producto.
Degenerate Dimensions
LK_COMPROBANTE
Con cada venta voy a insertar un
SK_comp nro_comp tipo
registro en la LK
1 1245214 A

2 2323452 B

BT_VENTA

sk_comp SK_cliente SK_producto fecha Volumen_Vta

1 1 101 10/05/2011 5

1 1 540 10/05/2011 10

2 3 350 10/05/2011 3

2 3 540 10/05/2011 15
Degenerate Dimensions LK_TIPO_COMP
Con cada venta voy a insertar un
Sk_Tipo_Comp tipo
registro en la LK
1 A

2 B

BT_VENTA
Sk_Tipo_Comp Sk_cliente Sk_producto Comprobante fecha Volumen_Vta

1 1 101 0001-01245214 10/05/2011 5

2 1 540 0003-00034567 10/05/2011 10

3 3 350 0005-01288968 10/05/2011 3

1 3 540 0001-01276597 10/05/2011 15

Junk Dimensions
➢ Vamos a encontrar atributos que no están relacionados a ninguna
dimensión.
➢ Nos van a empezar a quedar muchos atributos sueltos, por lo
general con pocos elementos.

Tengo 3 posibilidades:
✓ Poner esos atributos en la Fact Table.
✓ Manejar cada atributo como una dimensión separada y crear una
LK para cada atributo.
✓ Sacarlos del diseño.
✓ Crear una Junk Dimension

“Una Junk Dimension es una agrupación de atributos no

relacionados que se llevan a una dimensión.”