Modelado de Bases de Datos (OLAP)
Las bases de datos son un elemento imprescindible en prácticamente cualquier aplicación que necesite guardar datos de manera persistente.
Todos hemos aprendido que un buen diseño de base de datos se deben de aplicar las 3 reglas de normalización. La normalización es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener.
La Primera Forma Normal (1NF) nos dice:
Los datos están organizados en filas y columnas con los siguientes requisitos:
1. Todos los atributos, valores almacenados en las columnas, cada celda de la tabla debe contener un único valor, es decir, cada campo debe ser atómico
2. No deben existir grupos de valores repetidos
3. Cada columna debe tener un nombre único.
4. El orden de las filas y columnas no importa.
En resumen, la 1NF garantiza que los datos estén organizados de manera tabular y que no haya conjuntos repetidos de atributos dentro de una tabla. Cada valor debe ser indivisible y único en su ubicación específica en la tabla.
La Segunda Forma Normal (2NF) nos dice:
Para cumplir con la 2NF, una tabla debe cumplir con dos condiciones:
Estar en Primera Forma Normal (1NF): Esto significa que la tabla debe estar organizada de manera que cada celda contenga un único valor atómico, y que cada columna tenga un nombre único.
Eliminar las Dependencias Parciales: Cada atributo no clave debe depender completamente de la clave primaria.
Para entender esto, consideremos un ejemplo:
Supongamos que tenemos una tabla de “Pedidos” con los siguientes atributos: ID_pedido (clave primaria), Fecha_pedido, Producto y Precio. Aquí, el ID_pedido es la clave primaria que identifica cada pedido. Sin embargo, si el Producto y el Precio dependen de ID_pedido, pero no de manera exclusiva, entonces hay una dependencia parcial. Por ejemplo, si el Precio depende del Producto y no directamente del ID_pedido, estaríamos violando la 2NF.
Para cumplir con la 2NF, podríamos dividir esta tabla en dos: una tabla “Pedidos” con ID_pedido y Fecha_pedido, y otra tabla “Detalle_Pedido” con ID_pedido, Producto y Precio. Ahora, cada atributo en la tabla “Detalle_Pedido” depende completamente de la clave primaria ID_pedido.
En resumen, la Segunda Forma Normal (2NF) garantiza una estructura de base de datos más libre de redundancias y más eficiente al eliminar las dependencias parciales y asegurar que cada atributo no clave dependa completamente de la clave primaria.
La tercera Forma Normal (3NF) nos dice:
La Tercera Forma Normal (3NF) es una etapa más avanzada de normalización que busca eliminar las dependencias transitivas en una tabla. Una dependencia transitiva ocurre cuando un atributo no clave depende de otro atributo no clave en lugar de depender directamente de la clave primaria.
Para cumplir con la 3NF, una tabla debe cumplir con dos condiciones:
Estar en Segunda Forma Normal (2NF): Esto significa que la tabla ya debe estar libre de dependencias parciales.
Eliminar las Dependencias Transitivas: Cada atributo no clave debe depender únicamente de la clave primaria y no de otros atributos no clave.
Para comprender esto, consideremos un ejemplo:
Supongamos que tenemos una tabla de “Empleados” con los siguientes atributos: ID_empleado (clave primaria), Nombre, Departamento y Ubicación. Aquí, ID_empleado es la clave primaria que identifica a cada empleado. Sin embargo, si la Ubicación depende del Departamento y no directamente de ID_empleado, estaríamos violando la 3NF.
Para cumplir con la 3NF, podríamos dividir esta tabla en dos: una tabla “Empleados” con ID_empleado, Nombre y Departamento, y otra tabla “Departamentos” con Departamento y Ubicación. Ahora, cada atributo en la tabla “Empleados” depende únicamente de la clave primaria ID_empleado.
En resumen, la Tercera Forma Normal (3NF) garantiza una estructura de base de datos aún más libre de redundancias y más eficiente al eliminar las dependencias transitivas y asegurar que cada atributo no clave dependa únicamente de la clave primaria. Esto ayuda a mantener la integridad de los datos y facilita la actualización y modificación de la base de datos
Desnormalización
La desnormalización es el proceso de duplicar información en las tablas de forma intencional, violando las reglas de normalización. La desnormalización se realiza después de haber normalizado una tabla, pero no significa que nos saltemos el proceso de normalización.
Pero… Ahora bien las reglas de normalización no consideran el rendimiento. Entonces, En algunos casos, es necesario considerar la desnormalización para mejorar el rendimiento.
Analicemos los pros y contras de la Desnormalización.
BENEFICIOS DE LA DESNORMALIZACIÓN
Uno de los principales beneficios de la desnormalización es que puede mejorar el rendimiento y la eficiencia de sus herramientas de informes y visualización. Al reducir el número de tablas o combinaciones implicadas en las consultas, puede evitar la sobrecarga y la complejidad de las operaciones de base de datos relacional, como la indización, la ordenación, el filtrado y la agregación. Esto puede resultar en una ejecución de consultas más rápida, menor consumo de recursos y menos latencia. Además, la desnormalización puede hacer que sus datos sean más fáciles de usar e intuitivos, ya que puede eliminar la necesidad de transformaciones o cálculos complejos sobre la marcha. Por ejemplo, puede almacenar métricas o indicadores calculados previamente, como promedios, proporciones o porcentajes, en una tabla desnormalizada y usarlos directamente en sus informes o paneles
[La desnormalización simplifica las consultas complejas mediante la consolidación de datos de varias verticales en un almacén de datos centralizado]
INCONVENIENTES DE LA DESNORMALIZACIÓN
Sin embargo, la desnormalización también tiene algunos inconvenientes que pueden afectar la calidad e integridad de sus datos. Uno de los principales inconvenientes es que puede aumentar el riesgo de inconsistencia o redundancia de datos. Al duplicar o acoplar los datos, puede crear varias fuentes de verdad o versiones contradictorias de la misma información. Esto puede provocar errores, confusión o discrepancias en los informes o visualizaciones, especialmente si no actualiza o sincroniza los datos desnormalizados de forma regular o adecuada. Otro inconveniente es que la desnormalización puede reducir la flexibilidad y escalabilidad de su modelo de datos. Al codificar o incrustar la lógica de datos o las suposiciones en las tablas desnormalizadas, puede limitar su capacidad para adaptar o ampliar los datos a nuevos requisitos o escenarios. Por ejemplo, es posible que deba modificar o volver a crear sus tablas desnormalizadas si desea cambiar sus métricas o indicadores, o agregar nuevas dimensiones o atributos a sus datos.
En resumen, la desnormalización es útil para mejorar el rendimiento en ciertos casos, pero debe implementarse con precaución para evitar problemas de integridad y consistencia de datos.
Tarea 3
Escenario: Sistema de ventas online
Proceso: Identifique como organizar y almacenar eficientemente datos sobre productos, clientes, ventas y la temporalidad de estas ventas para facilitar análisis complejos y la toma de decisiones. Los alumnos deberán crear esquemas que permitan consultas rápidas sobre qué productos se venden más, qué clientes compran con más frecuencia, cómo varían las ventas a lo largo del tiempo, y cómo estos factores interactúan entre sí. Los tres esquemas a desarrollar son:
• Esquema Estrella: Centrado en una tabla de hechos de ventas con dimensiones para productos, clientes, y tiempo.
• Esquema Copo de Nieve: Similar al esquema estrella, pero con dimensiones normalizadas para reflejar jerarquías como categorías de productos y ubicación de clientes.
• Esquema Desnormalizado: Una tabla masiva que combine todas estas dimensiones para minimizar las consultas de unión a costa de redundancia de datos.
Los alumnos deberán considerar cómo estructurar estas entidades y sus relaciones para optimizar el acceso y análisis de datos en cada esquema
Pasos a seguir según la teoría vista en clases
DISEÑO DE UN MODELO ESTRELLA
Para completar el diseño solicitado se deben de seguir una serie de pasos:
1- Identificar la tabla de hechos: La tabla de hechos contendrá las métricas o medidas clave que se analizarán, como ventas, cantidad, ingresos, etc.
2- Identificar las dimensiones: Las dimensiones son las entidades que describen los datos en la tabla de hechos. Por ejemplo, en un sistema de ventas, las dimensiones pueden incluir tiempo, ubicación, producto, cliente, etc.
3- Crear la tabla de hechos: La tabla de hechos contiene claves externas que se relacionan con las dimensiones y las métricas de interés. Por ejemplo, podría contener claves externas para el tiempo, el producto, el cliente y la cantidad vendida.
4- Crear las tablas de dimensiones: Cada tabla de dimensiones contiene detalles sobre una dimensión específica. Por ejemplo, la tabla de dimensión de tiempo podría contener información sobre el año, el mes, el día, etc.
5- Establecer relaciones: Las tablas de dimensiones se relacionan con la tabla de hechos mediante claves externas.
CONVERSIÓN A UN MODELO DE COPO DE NIEVE
En un modelo de copo de nieve, las dimensiones se normalizan aún más dividiendo los atributos de la dimensión en subdimensiones. Por ejemplo, en lugar de tener una tabla de dimensión de producto con todos los detalles del producto, se pueden tener tablas separadas para categoría de producto, subcategoría, marca, etc.
DESNORMALIZACIÓN DEL MODELO DE COPO DE NIEVE
La desnormalización implica revertir la normalización, es decir, combinar tablas para reducir la complejidad de las consultas y mejorar el rendimiento del sistema. En el caso de un modelo de copo de nieve, esto implica fusionar las tablas de dimensiones normalizadas en tablas menos normalizadas, reduciendo la cantidad de tablas y simplificando las relaciones.
En nuestro caso vamos a fusionar la tabla de Hechos Ventas en una sola tabla de Ventas_Desnormal (jaja) con todas las características desnormalizadas. Esto puede hacer que las consultas sean más simples y más rápidas.
