M2: 2da Pre entrega
Modelo de datos RetailPro
Diseño del modelo relacional: las tablas del
proyecto
Entregable
Descripción: Con el brief definido en M1, ahora vas a diseñar la arquitectura de datos
que va a sostener todo el análisis. Esta pre-entrega es el plano del edificio: si el diseño
es sólido, todo lo que construyas encima va a funcionar. En M3 vas a implementar
exactamente este modelo en SQL, así que cada decisión que tomés acá tiene
consecuencias directas en los módulos siguientes.
Contexto: RetailPro necesita migrar sus datos desde planillas de Excel desorganizadas
a una base de datos relacional. Tu tarea es diseñar el modelo que va a contener toda la
información del negocio aplicando las reglas de normalización hasta 3NF aprendidas en
este módulo.
Instrucciones
1. Diagrama ER: Diseñá el modelo relacional de RetailPro con todas sus tablas,
columnas, tipos de datos, claves primarias y claves foráneas. Podés usar [Link],
Lucidchart, [Link] o cualquier herramienta equivalente. También podés dibujarlo
a mano y fotografiarlo.
Tu modelo debe incluir obligatoriamente:
Tablas Columnas mínimas requeridas
Clientes id_cliente (PK), nombre, email, ciudad, segmento, fecha_registro
Productos id_producto (PK), nombre_producto, categoria, subcategoria, precio, costo
Venta id_venta (PK), fecha_venta, id_cliente (FK), id_producto (FK), cantidad, total_venta, canal
Territorios id_territorio (PK), region, pais, zona
2. Justificación de normalización: Explicá en un párrafo por qué tu diseño cumple con la
3NF, indicando específicamente:
Qué dependencias parciales eliminaste.
Qué dependencias transitivas evitaste.
Por qué no hay redundancia de datos entre tablas.
3. Conexión con el brief de M1: Para cada tabla, indicá a cuál de las preguntas de
análisis que definiste en M1 contribuye y qué columna específica permite responderla.
Resolución
Transformación de Tabla Plana a Esquema Normalizado (3NF)
El punto de partida para este modelo de negocio requiere procesar un flujo constante
de transacciones comerciales que, de gestionarse en una sola tabla plana, provocarían
una enorme redundancia de datos. Almacenar en un único registro los detalles de cada
venta junto con los datos completos del comprador, las especificaciones técnicas del
artículo y la ubicación geográfica generaría duplicaciones masivas (como escribir el
nombre, segmento y ciudad de un mismo cliente cada vez que realiza una compra, o
repetir los costos y categorías de un producto). Esta falta de estructura afectaría el
rendimiento del sistema y aumentaría el riesgo de inconsistencias al actualizar la
información.
Paso 1: Creación de tablas maestras
La primera fase del desarrollo consiste en aislar los componentes fundamentales del
negocio mediante la creación de las tablas maestras: clientes, productos y territorios.
En clientes, se almacena la información única del perfil del comprador, como su email,
segmento y fecha de registro. Por su parte, la tabla productos centraliza el catálogo,
detallando atributos como la categoría, subcategoría, precio y costo de cada artículo.
Finalmente, territorios actúa como la maestra geográfica, organizando las regiones,
países y zonas. Cada una de estas tablas cuenta con su propia clave primaria (PK) para
identificar de forma unívoca cada registro, eliminando cualquier duplicidad de texto.
Paso 2: Creación de la tabla de relación
La segunda fase se materializa con la creación de la tabla central de ventas, la cual actúa
como el puente que conecta a todas las tablas maestras; en lugar de contener
descripciones de texto repetitivas, esta tabla registra el evento comercial utilizando
exclusivamente claves foráneas (FK), vinculando el id_cliente y el id_producto
correspondientes. Además, incorpora las métricas y atributos propios de la
transacción, tales como la fecha de la venta, la cantidad de unidades, el total de la venta
y el canal de distribución utilizado.
Normalización
El diseño cumple estrictamente con la 3NF porque se encuentra en Segunda Forma
Normal (2NF) y se ha garantizado que ningún atributo no clave dependa de forma
transitiva de la clave primaria. En primer lugar, al definir claves primarias simples
(id_cliente, id_producto, id_venta, id_territorio) en lugar de claves compuestas, se
eliminaron por completo las dependencias parciales de la 2NF, asegurando que
atributos como el precio de un producto o el email de un cliente dependan de la
totalidad de su respectivo identificador y no de una fracción de este. En segundo lugar,
se evitaron las dependencias transitivas al aislar las entidades; por ejemplo, en la tabla
clientes, el campo ciudad depende directamente de id_cliente y no a través de otro
atributo secundario, manteniendo una jerarquía limpia donde los atributos no clave
dependen únicamente de la clave primaria. Como resultado de esta separación lógica,
no existe redundancia de datos entre tablas, ya que la información descriptiva y de texto
pesado (como nombres de categorías, regiones o correos electrónicos) se almacena
exactamente una sola vez en sus tablas maestras, mientras que la tabla transaccional de
ventas se limita a conectar el ecosistema mediante claves foráneas (FK), logrando un
modelo óptimo, consistente y libre de anomalías de actualización.
Conexión con el brief de M1
Tabla CLIENTES: segmentamos los compradores por su comportamiento. Permite
resolver la duda sobre los factores contextuales de la variación del ticket promedio
entre segmentos.
Campos clave involucrados: id_cliente, segmento_cliente, ciudad (o región), y
fecha_alta.
Impacto en KPIs: calcula la frecuencia de compras, detectar clientes activos y
medir la tasa de retención (identificando quiénes dejaron de comprar o se
mantienen recurrentes).
Tabla PRODUCTOS: responde al problema de qué categorías explican la caída de las
ventas y cuáles son los productos que generan altos niveles de facturacion pero baja
rentabilidad.
Campos clave involucrados: id_producto, categoría, subcategoría y
margen_ganancia.
Impacto en KPIs: mide la participación por categoría, calcular la rentabilidad por
categoría (gracias al margen_ganancia) y listar el ingreso por producto.
Tabla TERRITORIOS: responde al problema de negocio “por qué determinadas
regiones presentan una caída en sus ventas”, precisamente, permite un análisis
comparado del rendimiento de los territorios que muestran un mejor desempeño
comercial con lo que no.
Campos clave involucrados: id_territorio, región y provincia.
Impacto en KPIs: alimenta las métricas de Ventas por territorio, la Venta
promedio por territorio y la Participación territorial (el peso porcentual de cada
región sobre el total de la empresa).
Tabla VENTAS: responde al interrogante final “qué combinación de cliente, producto
y territorio representa la mayor oportunidad”
Campos clave involucrados: id_venta, fecha_venta, cantidad, precio_total,
descuento y los IDs de conexión (id_cliente, id_producto).
Impacto en KPIs: define el Q de ventas , la variación % de ventas entre trimestres
(mide la caída del negocio) y el ticket promedio operando matemáticamente
sobre el campo precio_total.
Datos crudos
Clientes
Productos
Territorio
Ventas
Clientes Productos
IDCliente IDProducto
Segmento Categoría
Ciudad SubCategoría
FechaAlta Margen_Ganancia
Territorio Ventas
IDTerritorio IDVenta
Región Cantidad
Provincia FechaVenta
Precio
IDProducto
IDCliente