Dashboard en Excel

- Edición 26 -

Sesión III

Docente: Luis Quiroz

 INTRODUCCIÓN AL MODELADO DE DATOS

Juan Alva es un analista de datos de la empresa Alcafarma S.A. y

su jefe le pidió realizar un reporte que le permita analizar:

• La información de venta las tiendas por región y local de

venta.
• El perfil de los clientes, el rango de edad de quien compra
más, que profesiones tienen.
• También se necesita la información de contacto para hacer
campañas dirigidas.
• Revisar esta información comparándola con lo que ocurría el
mes pasado y año pasado.
• Finalmente se desea averiguar en que categorías y
subcategorías de producto, para ver en cuales tenemos un
mejor performance.
INTRODUCCIÓN AL MODELADO DE DATOS

Juan se pregunta ¿qué datos necesito?

Fecha Sexo
Mes Fecha Nacimiento
Año Estado civil
Día Semana Producto
Codigo factura Subcategoria
Unidades Categoria
Monto venta Origen
Nombre cliente
REPORTE GENERADO
 REPORTE GENERADO

¿Si los datos generados son 2 millones de datos? ¿Se podrá almacenar en Excel?

Alternativas: Agrupar los datos / Reducir el nivel de granularidad

*La granularidad es el nivel de detalle de una tabla.

MODELO DE DATOS
MODELO DE DATOS

Modelo de datos:

Ventajas

• Información mejor administrada.

• Ahorro en tamaño, sin perder datos
• Explota mejor el potencial de la
información (DAX).
CARGAMOS LAS TABLAS Y GENERAMOS EL MODELO
 MODELO DE DATOS TRANSACCIONALES VS MODELO DIMENSIONALES

BDT
ERP
Data Warehouse

CRM

MODELOS DE DATOS MODELO DE DATOS

OPERATIVOS DIMENSIONAL (WAREHOUSE)

• Base de Datos Analítica: Ayuda a evaluar los rendimientos de las

• Base de Datos Operativa: Registra y automatiza las principales
actividades de la organización. Comparar el número de ordenes con la
actividades de la organización. Tomar ordenes, registrar nuevos
de meses pasados, investigar porque se están registrando esos nuevos
clientes, registrar y monitorear una operación logística.
clientes,

• Están optimizadas para operar las transacciones con la máxima • Están optimizadas para procesar consultas a altas velocidades (extraer
velocidad (esta totalmente normalizadas). información).

• Muchas veces se actualizan para reflejar el estado más reciente. • Requieren que la información histórica se preserve para evaluar con precisión
el performance de la empresa a lo largo del tiempo.
 MODELO DIMENSIONAL

Es una colección
Esto todavía de tablas
NO ES independientes,
un modelo de datos que no
comparten
alguna conexión
o relación entre
ellas.
 MODELO DIMENSIONAL

Las tablas están

conectadas a
Esto través de
SI ES relaciones,
un modelo de datos basadas en un
campo común
(Por ejemplo:
Fecha y Fecha
de Orden).
 NORMALIZACIÓN DE UNA BASE DE DATOS
Es el proceso de organizar tablas en columnas en una base de datos para reducir redundancia y preservar la integridad de los datos.
Usualmente se usa para:
Eliminar información redundante: Para reducir el tamaño de la base de datos y mejorar el procesamiento y la eficiencia.
Minimizar errores y anomalías: Al realizar modificaciones a la base de datos (insertar, actualizar o eliminar registros).

Simplifica la consulta y el análisis: Estructura la base de datos en una forma fácil de entender e interactuar.

TIP: En una base de datos normalizada, cada tabla debe servir un propósito distinto y específico (Ejemplo: Información sobre el producto,
Fechas, registro de las ventas, atributos de los clientes, etc.).

Cuando no normalizas terminas teniendo

tablas como éstas: Todas las filas con
información duplicada podrían eliminarse si
creamos una tabla de búsqueda basada en
Product ID.

Quizá no pueda parecer crítico ahora, pero

pequeñas ineficiencias pueden volverse un
problema más grande a medida que la
base de datos incrementa su tamaño.
 TABLAS DE DATOS VS TABLAS DE BUSQUEDA
Los modelos casi siempre contienen 2 tipo de tablas: Tablas de datos (o “tabla de hechos”) o tabla de búsqueda (o “tabla de
dimensiones”).
Las tablas de hechos contienen los números o valores (métricas) que queremos analizar, por lo general a nivel granular, acompañado de ID o
“llaves” que pueden ser usados para crear las relaciones entre tablas.
Las tablas de dimensión proveen información descriptiva, por lo general textual acerca de cada dimensión en una tabla.

Tabla “Ventas” Tabla “Calendario”

La tabla de dimensión Calendario provee información adicional sobre cada

fecha (mes, año, día de la semana, trimestre, etc).

Tabla “Tienda”

Esta tabla de hechos contiene las métricas: Unidades y Vendidas y Monto de La tabla de dimensión Tienda provee información adicional sobre cada tienda
Venta. Se conecta a las tablas de dimensión a través de las columnas fecha (Nombre completo, Zona en la que ubica, Región, etc.).
orden, ID Producto, ID Cliente e ID Tienda.
 LLAVE PRIMARIA (PRIMARY KEY) VS LLAVE FORÁNEA (FOREIGN KEY)
Tabla “Calendario”
Tabla “Ventas”
Estas columnas son llaves
primarias: Son únicas en cada fila
de la tabla y se relacionan con las
llaves foráneas de la tabla de
hechos.
Tabla “Tienda”

Tabla “Cliente”

Tabla “Producto”
Estas columnas son llaves foráneas: Contienen múltiples
instancias de cada valor, y son usadas para vincularse a las
llaves primarias de las tablas de dimensión relacionadas.
 USAR RELACIONES VS TABLA UNIFICADA

¿No podría simplemente unir las tablas o usar funciones BUSCARV o COINCIDIR para agregar
esos atributos a la tabla de hechos, así lo tengo todo en un mismo lugar?

Tabla de hechos original Atributos de la tabla de dimensión Atributos de la tabla de dimensión Atributos de la tabla de dimensión
“Ventas” “Calendario” “Tienda” “Productos”

Si puedes. Pero es INEFICIENTE!!!

Unir la data de esa forma crea datos redundantes y utiliza significativamente más memoria y poder de
procesamiento que crear las relaciones entre tablas pequeñas.
 CREANDO LAS RELACIONES ENTRE LAS TABLAS
OPCIÓN 1: Click y arrastrar para conectar la llave primaria con la OPCIÓN 2: Agregar o detectar relaciones utilizando el botón de Diálogo
llave foránea en la vista de modelo. “Administrar Relaciones”, del panel de Inicio.
ADMINISTRAR Y EDITAR RELACIONES
 ADMINISTRAR Y EDITAR RELACIONES

El botón de diálogo nos permite Agregar, Editar o Eliminar las relaciones entre Algunas herramientas de edición de relaciones son aquellas que permiten
tablas. activar/desactivar relaciones, editar la cardinalidad, y modificar la dirección
de filtro cruzado.
RELACIONES ACTIVAS VS INACTIVAS

Elegir que relación quiero activar en ese momento

CARDINALIDAD DE LAS RELACIONES
Cardinalidad se refiere a la singularidad de valores en una columna

Para nuestros reportes nuestro modelo siempre debe estar definido por la
cardinalidad “uno a varios”: Una instancia para cada llave primaria, pero
potencialmente varias instancias por cada llave foránea.

En este caso, solo hay una instancia de cada ID Producto en la

tabla “Dimensión Productos”, ya que cada fila contiene atributos en
un único producto (Nombre, Sku, Descripción, Precio de Lista, etc.)

Hay muchas instancias de cada ID Producto en la tabla “Ventas”

(nótese el asterisco *), ya que hay múltiples ventas asociadas a
cada producto.
 EJEMPLO: RELACION VARIOS A VARIOS
Tabla Productos Tabla Ventas

Si tratamos de conectar estas tablas usando las columnas product_id nos saldrá un aviso de advertencia, ya que
hay múltiples instancias de cada ID en ambas tablas.
Incluso si pudiéramos crear esta relación ¿Podríamos saber realmente que producto se vendió en cada fecha –
Cream Soda o Diet Cream Soda
 EJEMPLO: RELACION UNO A UNO

Si tratamos de conectar estas tablas usando las columnas ID Producto se creará una relación de uno a uno entre
ambas tablas ya que cada ID aparece solo una vez en cada tabla

A diferencia de le relación muchos a muchos, no hay nada erróneo al usar esta relación, solo es ineficiente.

Bastaría con unir ambas tablas en

una sola tabla de búsqueda para
eliminar la ineficiencia.

OJO: Aún estamos respetando las reglas de normalización, porque todas las filas son
únicas y recogen atributos relacionados la llave primaria.
 EJEMPLO: RELACION VARIOS A VARIOS
Vamos a incorporar al modelo una tabla
de hechos adicional: Tabla Retornos.
• Observamos que esta tabla de hechos
tiene una fecha, un ID Producto, y un ID
Tienda, pero no cuenta con una llave
foránea para relacionarse con la
Dimensión Clientes.

• Podemos analizar las ventas y retornos en

una sola visual, pero solo si filtramos la
información por las dimensiones que
tienen en común.

• Sabemos por ejemplo que producto fue

retornado, en que fecha o que tienda, pero
no sabemos que cliente hizo el retorno.

OJO: NUNCA SE DEBEN CREAR RELACIONES ENTRE TABLAS DE HECHOS, LA MEJOR FORMA DE RELACIONARLOS ES A TRAVÉS DE
DIMENSIONES EN CÓMÚN.
FLUJO DE LOS FILTROS
Tenemos dos tablas de hechos (Ventas y Retornos)
conectadas a la tabla Dimensión Tiendas.

Nótese que la dirección de los filtros (se muestran como

flechas) van por defecto desde la parte de “uno” de la
relación (tablas de dimensión) hacia la parte de “muchos” de
la relación (tablas de datos).

• Cuando filtramos o segmentamos una tabla (con alguna

visual o gráfica), el contexto de filtro fluye “hacia abajo”
por el modelo (siguiendo la dirección de las flechitas)

• El filtro nunca va “hacia arriba” (en contra de la dirección

del filtro).

TIP: Siempre ubicar las tablas de dimensión arriba y las tablas

de hechos abajo.
FILTROS BIDIRECCIONALES

Esto quiere decir que los filtros aplicados a la tabla Ventas van
a pasar la tabla de Dimensión, y luego de nuevo hacia abajo a
la tabla Retornos
ESCONDER CAMPOS DE LA VISTA DE REPORTE

Activando la opción “Ocultar en la vista de informe” en algún

campo haremos este inaccesible es la Vista de Informe (pero aún
pueden verse en la vista de datos y vista de modelo).

Usualmente lo utilizamos para evitar que los usuarios usen

filtros con campos inválidos, o para ocultar campos irrelevantes
a la vista.

TIP: Es recomendable ocultar las llaves de los modelos

(especialmente las llaves foráneas).
 CONSEJOS AL ELABORAR UN MODELO DE DATOS

CENTRARSE EN CONSTRUIR UN MODELO NORMALIZADO DESDE EL PRINCIPIO.

• Asegurarse que cada table sirva a un único y distinto propósito.
• Siempre es mejor un modelo de tablas separada que de tabla única.

ORGANIZAR LAS TABLAS DE BUSQUEDA ENCIMA DE LA TABLAS DE HECHOS.

• Nos ofrece una ayuda visual para entender que los filtros fluyen “hacia abajo”.

EVITAR FILTROS CRUZADOS COMPLEJOS A MENOS QUE SEA ABSOLUTAMENTE NECESARIO.

• No usen filtros bidireccionales cuando los filtros en una dirección pueden hacer el trabajo.

ESCONDE LOS CAMPOS IRRELEVANTES DEL REPORTE PARA MEJORAR LA EXPERIENCIA DE USUARIO.
• Es recomendable siempre ocultar las llaves foráneas del modelo.