Dashboards en Excel

• Docente: Luis Felipe Garayar Burneo

• Correo: luis.garayar.dmc@gmail.com

w w w. d m c . p e
Contenido General

I. Introducción al Análisis, Diseño y Modelamiento de Base de Datos

II. Power Query
III. Power Pivot para Excel
IV. Entorno del Power View
V. Entorno de Power Map
VI. Implementación de Dashboards con Power Pivot
VII. Funciones DAX
Contenido General

I. Introducción al Análisis, Diseño y Modelamiento de Base de Datos

II. Power Query
III. Power Pivot para Excel
IV. Entorno del Power View
V. Entorno de Power Map
VI. Implementación de Dashboards con Power Pivot
VII. Funciones DAX
Analizando el Negocio (I)
 El modelo de negocios es el estudio de la organización.
 Durante el proceso de modelado del negocio, se examina la estructura de la organización y se
observan los roles en la compañía y como estos se relacionan.
 El objetivo principal del modelamiento es comprender el conjunto de procesos de negocio que
tienen lugar dentro de una empresa, como paso previo a establecer los requisitos del sistema a
desarrollar.
Analizando el Negocio (II)
¿Porqué modelar el negocio?
 Conocimiento de la visión organizacional:
• Documentar lo que hace la organización.
 Re-ingeniería de procesos del negocio
• Analizar cambios en los flujos de trabajo.
 Ayuda al entrenamiento del personal en la organización
• Indican claramente cuales son las responsabilidades de cada persona dentro del flujo de
trabajo.
 Contexto para una solución de software
• Si no podemos entender el negocio, se pueden presumir conceptos erróneos sobre lo que
debe hacer el software y cómo puede ser utilizado lo mejor posible por la comunidad del
negocio.
 El "mundo alrededor del sistema" es una consideración importante al construir software.
 Analizando el Negocio (III)
¿Cuándo es necesario hacer un modelo de
negocios?
 Cuando el grupo de trabajo es nuevo en la
organización.
 Cuando la organización a enfrentado un reciente
proceso de reingeniería de negocios.
 Cuando la organización esta planificando un
proceso de reingeniería de negocios.
 Cuando el software a construir será utilizado por
una porción importante de la organización.
 Existen flujos de trabajo complejos dentro de la
organización que no están documentados.
 Cuando se es un consultor en una organización
en la cuál no se a trabajado antes.
¿Cuándo no es necesario…?
 Cuando se tiene un conocimiento de la
estructura de la organización, de las metas, de la
visión y de los clientes/usuarios.
 Cuando el software a construir será usado por
una pequeña parte de la organización, y no tiene
un efectos en el resto del negocio.
 Cuando los flujos de trabajo de la organización
están bien documentados.
 Cuando el tiempo lo permita, no todos los
procesos tiene el tiempo necesario para
completar un análisis de negocio
Definiendo los procesos (I)
¿Cómo consigue la empresa sus objetivos?
 Una organización tiene una serie de objetivos que satisface a través de Procesos de Negocio
 Elementos de un proceso de negocio:
• Flujo de Tareas, Agentes, Información, Reglas de Negocio
 Reglas de Negocio regulan el funcionamiento de la empresa
– Describen restricciones y comportamientos
– NO son requisitos, pero influyen en ellos
Definiendo los procesos (II)
Diseñando la base de datos (I)
 El objetivo principal del diseño de bases de datos es generar tablas que modelan los registros en
los que guardaremos nuestra información.
 Debemos comenzar estudiando el mundo real que deseamos representar en la aplicación y base
de datos, lo que es simplemente la visión del mundo real bajo unos determinados objetivos.
Diseñando la base de datos (II)
En el proceso de diseño de una base de datos
existen tres grandes fases:
 Diseño externo o conceptual: una
representación de la información con
independencia de usuarios y aplicaciones en
particular, y fuera de consideraciones sobre la
eficiencia del ordenador.
 Diseño lógico, describe la estructura de la
base de datos, realizado en la fase de diseño
del sistema, y que cumple los requisitos de los
usuarios. En nuestro caso nos referiremos a
este modelo de datos relacional.
 Diseño interno o físico, describe la estructura
física de almacenamiento de la base de datos.
Diseñando la base de datos (III)
Caso de estudio:
Para desarrollar el diseño de una base de datos, tomaremos como ejemplo el diseño de una base
de datos relacional que permita la gestión de prestamos de libros de una biblioteca.
 Diseño conceptual:
En nuestro ejemplo de estudio, partimos de que la forma actual de trabajo de la biblioteca, la cual
consiste en una serie de fichas de tres tipos:
• Fichas con las características de los libros (nombre, código, tipo, etc.).
• Fichas con las características de los lectores (nombre, apellidos, domicilio, etc.).
• Fichas con la información de los prestamos de libros que se han efectuado, incluyendo el lector a
quién se le ha prestado, la fecha, etc.
Además de estas fichas, en nuestras conversaciones con los empleados, obtenemos algunas
informaciones y comentarios útiles para el diseño como los siguientes:
• De cada libro pueden existir varios ejemplares.
• Sé esta interesado en tener información sobre el idioma del libro.
• Interesa reflejar los temas de los libros, pudiendo cada libro pertenecer a varios temas y/o subtemas.
• Interesa conocer el nombre de los autores.
Diseñando la base de datos (IV)
Ejemplo de diseño conceptual:

Entidad

Relación
Cardinalidad
Diseñando la base de datos (V)
 Diseño lógico: Esta basado en los siguientes principios:
1. Todo tipo de entidad del modelo conceptual se convierte en una tabla.
2. Todo tipo de relación entre tablas 1:N se traduce en una propagación de la clave (se crea una clave
primaria o foránea) o bien se crea una nueva tabla intermedia.
3. Todo tipo de relaciones entre tablas N:M (muchos a muchos) origina la creación de una nueva tabla
intermedia.
Aplicando a nuestro caso de estudio:
1 Aplicando la primera regla, obtenemos que
como existen seis entidades (autor, libro,
ejemplar, tema, idioma y socio), hemos de
crear seis tablas, una por cada entidad,
obteniendo las siguientes seis tablas con su
correspondiente clave primaria (PK:
Primary key)
Diseñando la base de datos (VI)
2 Apliquemos ahora la segunda regla. Tenemos dos relaciones 1:N, lo cual nos origina la
propagación de las claves. La propagación se efectúa desde la tabla de cardinalidad 1 a la tabla
de cardinalidad N. Además, la propagación es de clave primaria si la clave primaria de la tabla
a la que se propaga la clave no identifica unívocamente la entidad, en caso contrario se
propaga en forma de clave foránea (FK: Foreign key)

• La clave codigo_libro de la tabla

LIBRO se propaga a la tabla EJEMPLAR
como clave primaria.
• La clave codigo_idioma de la tabla
IDIOMA se propaga a la tabla LIBRO
como clave foránea.
Diseñando la base de datos (VII)
3 Apliquemos ahora la tercera regla. Tenemos tres relaciones N:M, cada una de las cuales dará
lugar a una nueva tabla que estará compuesta por las claves primarias de las tablas que
relaciona así como por todos los datos que identifican la relación entre las entidades. De esta
forma obtendremos el siguiente MODELO RELACIONAL final de tablas:
Normalización de datos (I)
 En el desarrollo del diseño lógico obtenemos tablas finales que son las candidatas a formar
nuestra base de datos. Sin embargo, dichas tablas han sido obtenidas a partir de un diseño
conceptual elaborado sin ningún tipo de reglas, por lo que podemos obtener un diseño de
tablas más o menos heterogéneo.
 La normalización consiste en un conjunto de reglas formales que nos permiten asegurar que
un diseño lógico cumple una serie de propiedades, corrigiendo la estructura de los datos de
las tablas y evitando una serie de problemas como:
 Incapacidad de almacenar ciertos hechos.
 Redundancias y, por tanto, posibilidad de inconsistencias.
 Aparición en la base de datos de estados no válidos en el mundo real, es lo que se llama anomalías de inserción,
borrado y modificación.
 Ambigüedades.
 Pérdida de información.
Normalización de datos (II)
Dependencias funcionales (DF):
 Es la relación que tienen los atributos (campos) de una tabla con otros atributos de la propia
tabla. Un campo tiene dependencia funcional si necesita información de otro/s campo/s para
poder contener un valor.
 Ejemplo: si tenemos la siguiente entidad:
Alumno (Código, nombre, apellido, nota1, nota2, promedio)
Diremos entonces:
 El campo Nombre y Apellido tienen DF con la clave Código.
 Nota1, Nota2 y Promedio no tienen DF con la clave Código.
 Estos tres últimos campos se pueden repetir para un solo Código.

Sólo aquellos atributos que pertenezcan a las características propias de la entidad, tienen
dependencia funcional con la PK. En caso contrario, si no dependen funcionalmente de la clave
principal o pueden tomas múltiples valores, entonces no pertenecen a la entidad.
Normalización de datos (III)
Formas Normales
 Primera Forma Normal: Una base de datos se considera que está en 1FN si cada atributo
(campo) de una tabla contiene un solo valor atómico (simple). Pasos:
1. Identificar los grupos repetitivos y no repetitivos (GR, GNR).
2. Remover los GR y crear una nueva entidad con ellos.
3. Llevar la clave a la nueva entidad

Grupos no
Repetidos

Grupos
Repetidos
Normalización de datos (IV)
Formas Normales
 Segunda Forma Normal: Una tabla se considera que está en 2FN si está en 1FN y cada
atributo (campo) no clave depende de la clave completa, no de parte de ella. Una base de
datos estará en 2FN si todas sus tablas lo están.
 La idea es identificar todas las tablas con una clave compuesta, pues todas las tablas con
clave simple están por defecto en 2FN si están en 1FN, y comprobar que cada uno de los
campos de esta tabla depende de la clave completa.
 En nuestro ejemplo, la tabla FACTURA se encuentra en 2FN pues está en 1FN y su clave es
simple. Sin embargo la tabla DETALLE_FACT tiene que analizarse pues su clave es compuesta:
Normalización de datos (V)
Formas Normales
 Tercera Forma Normal: Una tabla se considera que está en 3FN si está en 2FN y todos los
atributos que no son claves deben ser mutuamente independientes, es decir, un atributo no
debe depender de otro atributo no clave de su tabla.
 Si un atributo que no es clave depende de otro atributo que no es clave, la tabla
posiblemente contiene datos acerca de mas de una entidad, contradiciendo el principio de
que cada tabla almacene información de una entidad.
Normalización de datos (VI)
Para que un diseño de datos tenga credibilidad y de suficiente soporte al cumplimiento de
requerimiento de los usuarios, se acepta hasta la 3FN, es decir, si el diseño se encuentra
normalizado hasta la 3FN entonces cumple con los requisitos del sistema. Este ejemplo
quedaría así:
Caso Práctico: Normalización (I)
A través del siguiente ejemplo se intenta afirmar los conocimientos de normalización con un
ejemplo de una base de datos para una pequeña biblioteca.
Caso Práctico: Normalización (II)
No se cumple el requisito de la Primera Forma Normal (1FN) de sólo tener campos atómicos,
pues el nombre del lector es un campo que puede (y conviene) descomponerse en apellido
paterno, apellido materno y nombres, tal como se muestra en la siguiente tabla:

Como se puede ver, hay cierta redundancia característica de Primera forma normal.
Caso Práctico: Normalización (III)
El título es completamente identificado por el código del libro, pero el nombre del lector en
realidad no tiene dependencia de este código, por tanto estos datos deben ser trasladados a otra
tabla. Se tiene que crear la columna CodLector para identificar a cada lector de forma única.

Con esto obtenemos la Segunda Forma Normal.

Caso Práctico: Normalización (IV)
Para la Tercera Forma Normal (3FN) la relación debe estar en 2FN y además los atributos no clave
deben ser mutuamente independientes y dependientes por completo de la clave primaria.
En nuestro ejemplo en 2FN, la primera tabla conserva información acerca del libro, los autores y
editoriales, por lo que debemos crear nuevas tablas para satisfacer los requisitos de 3FN.

Aunque hemos creado nuevas tablas para que cada una

tenga sólo información acerca de una entidad, también
hemos perdido la información acerca de qué autor ha
escrito qué libro y las editoriales correspondientes, por lo
que debemos crear otras tablas que relacionen cada libro
con sus autores y editoriales.
Ejercicios
1. Se quiere diseñar una base de datos relacional para almacenar información sobre los asuntos
que lleva un gabinete de abogados. Cada asunto tiene un número de expediente que lo
identifica, y corresponde a un solo cliente. Del asunto se debe almacenar el período (fecha de
inicio y fecha de archivo o finalización), su estado (en trámite, archivado, etc.), así como los
datos personales del cliente al que pertenece (DNI, nombre, dirección, etc.). Algunos asuntos
son llevados por uno o varios procuradores, de los que nos interesa también los datos
personales.
2. Dada la siguiente tabla de una base de datos, aplicar las tres primeras formas normales y
llevar el diseño a 3FN.
ordenes (id_orden, fecha, id_cliente, nom_cliente, estado, num_art, nom_art, cant, precio)
Contenido General

I. Introducción al Análisis, Diseño y Modelamiento de Base de Datos

II. Power Query
III. Power Pivot para Excel
IV. Entorno del Power View
V. Entorno de Power Map
VI. Implementación de Dashboards con Power Pivot
VII. Funciones DAX
Introducción a Power Query (I)
Introducción a Power Query (II)
Introducción a Power Query (III)
Microsoft Excel posee una herramienta ETL adicional, orientada al usuario de Negocio, llamada
Power Query, que se integra como complemento del Excel 2013. Esta herramienta nos permite:

 Buscar y conectar datos en una gran variedad de orígenes.

 Combinar y dar forma a orígenes de datos para que coincidan con los requisitos de análisis de
datos o prepararlos para un modelado y análisis más exhaustivo con herramientas como Power
Pivot y PowerView.
 Crear vistas personalizadas de los datos.
 Realizar operaciones de limpieza datos.
 Importar datos de varios archivos de registro.
 Crear una consulta de los elementos marcados con “me gusta” en Facebook que represente un
gráfico de Excel.
 Extraer datos a Power Pivot de nuevos orígenes de datos (como XML, Facebook y las carpetas del
archivo) como conexiones actualizables.
 Importando Información diferentes fuentes (I)
Contenido Pestaña Power Query (Excel 2010 y 2013)

En Excel 2016, Power Query se encuentra integrado en la pestaña “Datos”

 Importando Información diferentes fuentes (II)
En la sección “Get External
Data” tenemos:

Conexión de datos de fuentes web

 Importando Información diferentes fuentes (III)
Importando desde ficheros
Importando Información diferentes fuentes (IV)
 Importando Información diferentes fuentes (V)
Importando desde Facebook
 Importando Información diferentes fuentes (VI)
Importando desde Facebook
 Importando Información diferentes fuentes (VII)
Importando desde Facebook
Importando Tablas de Excel (I)
Importando Tablas de Excel (II)
Caso práctico del Curso – Parte 1
 Supongamos que tenemos un archivo de ventas
históricos hasta cierta fecha (en nuestro caso hasta
el 3 de febrero del 2017) . Luego día a día se van a
generar archivos diarios de ventas que se deben
incorporar al histórico. Esto lo haremos mediante
una consulta utilizando Power Query:

 Lo interesante es que al agregar nuevos archivos a

la carpeta, la tabla consolidada se actualizará
automáticamente (mediante la consulta de Power
Query) incorporando los nuevos datos, además de
aplicar todas las operaciones de limpieza que
definamos de manera automática.
Dashboards en Excel
• Docente: Luis Felipe Garayar Burneo
• Correo: luis.garayar.dmc@gmail.com

w w w. d m c . p e