Normalización

Profesor: Elvis Lopez Loza 1

Normalización
Proceso de simplificación de los datos
▪ Tener almacenado con el menor espacio posible
▪ Eliminar datos repetidos
▪ Eliminar errores lógicos
▪ Datos ordenados

1. Primera Forma Normal

2. Segunda Forma Normal
3. Tercera Forma Normal

Profesor: Elvis Lopez Loza 2

La primera Forma Normal (1FN)
Hay que seguir una serie de pasos para normalizar, en otras palabras,
para decir que nuestra tabla está en primera forma normal. Estos son:

1. Eliminar los grupos repetitivos de las tablas individuales

2. Crear una tabla separada por cada grupo de datos relacionados
3. Identificar cada grupo de datos relacionados con una clave primaria

Profesor: Elvis Lopez Loza 3

Primera Forma Normal

Matricula Nombre Dirección Teléfono Curso CódCurso Carrera

1 Elvis Av. Palmeras 969655551 Excel C01 Ing. De

254 Sistemas
1 Elvis Av. Palmeras 969655551 Power BI C02 Ing. De
254 Sistemas

1 Elvis Av. Palmeras 969655551 Power Pivot C03 Ing. De

254 Sistemas

2 Rosa Av. Alisos 451 911254511 Excel C01 Ing. De

Sistemas

Profesor: Elvis Lopez Loza 4

 Primera Forma Normal
Matricula Nombre Dirección Teléfono Carrera

1 Elvis Av. Palmeras 254 969655551 Ing. De Sistemas

2 Rosa Av. Alisos 451 911254511 Ing. De Sistemas

Matricula Curso CódCurso

1 Excel C01

1 Power BI C02
1 Power Pivot C03

2 Excel C01

Profesor: Elvis Lopez Loza 5

La segunda Forma Normal (2FN)
Debemos seguir los siguientes pasos:

1. Tener la 1° forma normal

2. Crear tablas separadas para aquellos grupos de datos que se
aplican a varios registros
3. Relacionar estas tablas mediante una clave externa

Profesor: Elvis Lopez Loza 6

Segunda Forma Normal

Dependencia Funcional Dependencia Transitiva

A A
B B
C C

Profesor: Elvis Lopez Loza 7

Segunda Forma Normal
Matricula Nombre Dirección Teléfono Carrera

1 Elvis Av. Palmeras 254 969655551 Ing. De Sistemas

2 Rosa Av. Alisos 451 911254511 Ing. De Sistemas

Matricula Curso CódCurso

1 Excel C01

1 Power BI C02
1 Power Pivot C03

2 Excel C01

Profesor: Elvis Lopez Loza 8

Segunda Forma Normal
Matricula Nombre Dirección Teléfono Carrera

1 Elvis Av. Palmeras 254 969655551 Ing. De

Sistemas
2 Rosa Av. Alisos 451 911254511 Ing. De
Sistemas

Matricula CódCurso Curso CódCurso

1 C01 Excel C01

1 C02 Power BI C02

1 C03 Power Pivot C03

2 C01 Excel C01

Profesor: Elvis Lopez Loza 9

La tercera Forma Normal (3FN)

Debemos considerar los siguientes puntos:

1. Tener la 2° forma normal

2. Eliminar aquellos campos que no dependan de la clave
3. Ninguna columna puede depender de una columna que no tenga una clave
4. No puede haber datos derivados

Profesor: Elvis Lopez Loza 10

Tercera Forma Normal
Matricul CodCarrera Carrera
Nombre Dirección Teléfono CodCarrera
a CA01 Ing. De
1 Elvis Av. Palmeras 969655551 CA01 Sistemas
254 CA02 Administración
2 Rosa Av. Alisos 451 911254511 CA01

Matricula CódCurso

1 C01 Curso CódCurso

1 C02 Excel C01

1 C03 Power BI C02
2 C01 Power Pivot C03

Profesor: Elvis Lopez Loza 11

Modelo Básico Dimensionales

• Modelo Estrella (Star)

• Modelo Copo de Nieve (Snowflake)

Profesor: Elvis Lopez Loza 12

 Data Warehouse
Un Data Warehouse es esencial para realizar procesos de analítica y toma de decisiones,
en especial para los proyectos de Bussines Intelligence (BI) de cualquier empresa.

Funciona un poco diferente a las bases de datos convencionales (OLTP - OnLine Transactional Processing).
Como su nombre lo indica, manejan los datos transaccionales y los datos de cara a los procesos principales de
la organización. Al ser transaccionales comúnmente manejan segundo a segundo operaciones de consulta,
inserción, borrado y actualización de datos según los requerimientos del usuario (por ejemplo, una reserva de
cine).

Los Data Warehouse usan OLAP (OnLine Analytical Processing). Son datos que, aunque no están disponibles
en tiempo real, pueden ser analizados de forma rápida y masiva sin interrumpir los procesos del usuario. Esto
le otorga a los científicos de datos una perspectiva más amplia para tomar decisiones (por ejemplo, total de
ventas a través del tiempo). Como el Data Warehouse está diseñado con una finalidad analítica, este proceso
puede llegar a ser hasta 1000 veces más rápido que una base de datos convencional.

Profesor: Elvis Lopez Loza 13

Profesor: Elvis Lopez Loza 14
Modelo de estrella
Desde mi punto de vista el modelo de estrella es el más práctico a la hora de diseñar
un datawarehouse, es el que uso yo en mi día a día por lo siguiente:

• Comparto dimensiones entre distintas tablas de hecho

• Actualizo una dimensión y se refleja en todos los modelos e informes
• Quito la complejidad del copo de nieve, tengo dimensiones con bastantes campos (muchos valores
repetidos) pero merece la pena tenerlo así.
• Se tiene muchas menos tablas, pero más grande con más información. Esto es bueno porque en la
dimensión de producto sabés que encontrarás la marca, categoría, familia, proveedor… estos
datos en un modelo de copo de nieve sería dimensiones independientes.

Profesor: Elvis Lopez Loza 15

Profesor: Elvis Lopez Loza 16
Modelo de copo de nieve
En un mundo ideal este modelo sería el ideal, pero no lo es, diseñando un modelo en
copo de nieve conseguiríamos tener un datawarehouse normalizado en la 3FN. Así es
como funcionan todas las bases de datos transaccionales como los ecommerce etc…
pero no creo que para un sistema analítico esto sea necesario por las siguientes
razones.

• Tener muchas tablas nos obliga a hacer multitud de joins

• Cada join ralentiza muchísimo una consulta, con tablas de 100 registros no pasa nada pero con
tablas de 20 millones nos da tiempo a dar muchos likes en tinder

Profesor: Elvis Lopez Loza 17

Profesor: Elvis Lopez Loza 18
Como se ve en esta imagen, está todo normalizado en la 3FN pero ¿es necesario?

Por ejemplo, en la dimensión cliente el sexo y la franja Edad las incluiría dentro de
cliente, aunque estos valores se repitan muchas veces, nos ahorramos dos joins

En la dimensión SubCategoría añadiría los datos de Categoría, aunque se repita el

nombre de categoría.

Aplicando estas 3 recomendaciones ya se hubiera ahorrado 3 joins para hacer una

consulta sobre estas dimensiones.

Profesor: Elvis Lopez Loza 19

 Conclusión
• No obsesionarse con hacer un super análisis, hacer un pequeño análisis inicial y empezar con un pequeño datamart, este ya irá
evolucionando conforme vayan entrando necesidades de negocio y con cada nuevo informe que solicitan (consultando la BBDD
transaccional) ir diseñando el nuevo modelo de datos.

• No usar super tablas desnormalizadas, eso es pan para hoy y hambre para mañana. Con el tiempo van aumentando la cantidad de
supertablas y mantener esas tablas como por ejemplo añadir un campo a una dimensión que se encuentran en 5 tablas es hacer 5
modificaciones.

• No obsesionarse con tener un modelo en copo de nieve muy normalizado, perjudicará las consultas cuando se hagan joins.

• Utilizar un modelo de estrella aplicando el sentido común, por ejemplo, si una dimensión tiene una cantidad de campos muy
elevada se puede usar un híbrido entre el modelo de estrella y el copo de nieve.

• Hay dimensiones como la dimensión producto que contienen datos del proveedor, podemos decidir incluir todos los datos del
proveedor en la misma tabla de producto o desacoplarla de producto teniendo así una nueva dimensión proveedor. (Esto es lo que
he hecho yo).

• Aplicar el sentido común aunque este sea diferente para cada uno.

Profesor: Elvis Lopez Loza 20