De la Planilla al Modelo

Entidades, Relaciones y Normalización · Semana 4 · Unidad II

Universidad San Sebastián

2026-03-01

¿Dónde Estamos?

  • Unidad 1 (W01–W03): Entendimos para qué sirven los SI y cómo fluyen los datos desde OLTP hasta el CMI.
  • Hoy comienza la Unidad 2: aprendemos a diseñar la estructura de datos que hace funcionar esos sistemas.

Pregunta de inicio: ¿por qué TechStyle no puede simplemente usar Excel para gestionar sus 8,5 millones de clientes?

El Problema de Roberto: La Planilla Imposible

María, la Gerente de Marketing de TechStyle, abre el archivo ventas_historial.xlsx:

  • 340.000 filas, todas en una sola hoja.
  • Nombre del cliente repetido en cada fila de su historial de compras.
  • Si un cliente cambia de email → hay que buscar y corregir todas sus filas manualmente.
  • ¿Hay productos sin precio? Solo si los buscas uno a uno.
  • Juan intenta un BUSCARV(VLOOKUP) para cruzar con proveedores → Excel tarda 47 minutos y se congela.

“Necesitamos una base de datos,” dice Roberto. “Pero, ¿cómo se diseña una?”

La Planilla Plana de TechStyle

Así se ve ventas_historial.xlsx:

ID_Venta Fecha Cliente_ID Cliente_Nombre Cliente_Email Producto_ID Producto_Nombre Categoria Precio Cant
V001 15/01/26 C001 Juan Pérez juan@mail.com P001 Nike Air Max Calzado 89990 1
V002 15/01/26 C001 Juan Pérez juan@mail.com P002 Polera Adidas Ropa 24990 2
V003 16/01/26 C002 María López maria@mail.com P001 Nike Air Max Calzado 89990 1

¿Qué ves de inmediato? Juan Pérez aparece dos veces. Nike Air Max aparece dos veces.

Las 3 Anomalías de una Planilla Plana

Anomalía de actualización: Si Juan Pérez cambia su email, hay que modificar todas las filas donde aparece. Si se olvida una → datos inconsistentes.

Anomalía de inserción: Para registrar un cliente nuevo (sin ventas aún), ¿qué pongo en las columnas de Producto, Precio, Cantidad? → NULL en todas → fila sin sentido.

Anomalía de eliminación: Si elimino la venta V003 (la única de María López), pierdo también todos los datos del cliente. → El cliente desaparece de la “base de datos”.

🚀 Desafío Rápido 1

En parejas (3 minutos):

Analiza esta situación de TechStyle:

El proveedor de “Nike Air Max” cambia su nombre a “Nike Air Max 2026”. El producto aparece en 1.200 filas de la planilla.

  1. ¿Qué anomalía representa este problema?
  2. ¿Cuántas filas hay que modificar manualmente?
  3. ¿Qué riesgo existe si la actualización queda incompleta?
  4. ¿Cómo lo resolvería una base de datos bien diseñada?

La Solución: Separar la Realidad en Piezas

Idea clave: en el mundo real, un cliente existe independientemente de sus compras. Un producto existe independientemente de quién lo compró.

Una base de datos bien diseñada refleja esta realidad:

  • Una tabla para Clientes → cada cliente existe una sola vez.
  • Una tabla para Productos → cada producto existe una sola vez.
  • Una tabla para Ventas → registra qué cliente compró qué producto.

Principio clave de la Unidad 2: “Una base de datos es una representación estructurada de la realidad del negocio.”

El Modelo Entidad-Relación (MER)

El MER es el lenguaje para describir esa realidad antes de construir la base de datos.

  • Es un plano que se entrega al desarrollador (o al gestor de BD) para que construya el sistema.
  • Tiene tres elementos fundamentales: Entidades, Atributos y Relaciones.
  • Es independiente del software: funciona para MySQL, PostgreSQL, SQL Server, etc.

Analogía: el MER es al programador lo que el plano arquitectónico es al constructor. Nadie construye un edificio sin un plano.

Entidades: Las “Cosas” del Negocio

Una entidad es cualquier objeto, persona o concepto relevante para el negocio que necesita ser almacenado.

  • Se representa como un rectángulo.
  • Debe ser identificable de forma única.
  • En TechStyle: Cliente, Producto, Venta, Proveedor, Región.

Regla práctica: si puedes hacerte la pregunta “¿hay más de uno de esto?”, probablemente es una entidad.

→ ¿Hay más de un cliente? Sí → CLIENTE es una entidad.
→ ¿Hay más de un producto? Sí → PRODUCTO es una entidad.

Atributos: Las Características de las Entidades

Un atributo es una propiedad o característica de una entidad.

  • Se representan como óvalos conectados a su entidad (en el diagrama clásico) o como columnas de la tabla.
  • Cada entidad tiene un atributo clave (PK) que la identifica de forma única: subrayado.
  • Tipos: simples (nombre), compuestos (dirección = calle + número), derivados (edad = fecha_hoy − fecha_nacimiento).

CLIENTE: cliente_id (PK), nombre, apellido, email, region, segmento PRODUCTO: producto_id (PK), nombre_producto, categoria, precio_venta, stock

Clave Primaria y Clave Foránea

Clave Primaria (PK — Primary Key):
Atributo (o combinación de atributos) que identifica de forma única cada fila de una tabla. No puede repetirse ni ser nulo.

Tabla Clave Primaria ¿Por qué?
CLIENTE cliente_id Dos clientes pueden llamarse igual, pero su ID es único
PRODUCTO producto_id El código del producto no se repite
DETALLE_VENTA (venta_id, producto_id) Clave compuesta: la combinación identifica una línea de venta

Clave Foránea (FK — Foreign Key):
Atributo que referencia la PK de otra tabla, estableciendo el vínculo entre tablas. Garantiza que no existan datos huérfanos.

→ VENTA.cliente_id es FK que referencia CLIENTE.cliente_id. → Esto significa: no puede existir una venta de un cliente que no esté en la tabla CLIENTE.

Relaciones y Cardinalidad

Una relación describe cómo se asocian dos entidades.

Tipo Lectura Ejemplo TechStyle
1 : 1 Uno a uno Un empleado tiene un contrato
1 : N Uno a muchos Un cliente realiza muchas ventas
N : M Muchos a muchos Una venta incluye muchos productos; un producto aparece en muchas ventas

Notación “cuervo” (crow’s foot):
- || = exactamente uno
- o{ = cero o muchos
- |{ = uno o muchos

Diagrama MER de TechStyle

erDiagram
    CLIENTE {
        INT cliente_id PK
        VARCHAR nombre
        VARCHAR apellido
        VARCHAR email
        VARCHAR region
        VARCHAR segmento
    }
    PRODUCTO {
        INT producto_id PK
        VARCHAR nombre_producto
        VARCHAR categoria
        DECIMAL precio_venta
        INT stock
    }
    VENTA {
        INT venta_id PK
        DATE fecha
        INT cliente_id FK
    }
    DETALLE_VENTA {
        INT venta_id FK
        INT producto_id FK
        INT cantidad
        DECIMAL precio_unitario
    }
    CLIENTE ||--o{ VENTA : "realiza"
    VENTA ||--|{ DETALLE_VENTA : "contiene"
    PRODUCTO ||--o{ DETALLE_VENTA : "aparece en"

¿Por Qué Existe DETALLE_VENTA?

Una venta puede incluir múltiples productos, y un producto puede aparecer en múltiples ventas → relación N:M.

Las bases de datos relacionales no pueden implementar directamente relaciones N:M.

Solución: crear una tabla intermedia DETALLE_VENTA que “rompe” el N:M en dos relaciones 1:N:

  • VENTA (1) → DETALLE_VENTA (N) → una venta tiene muchas líneas de detalle.
  • PRODUCTO (1) → DETALLE_VENTA (N) → un producto aparece en muchas líneas de detalle.

La clave primaria de DETALLE_VENTA es compuesta: (venta_id, producto_id).

Introducción a UML: Diagrama de Casos de Uso

El Diagrama de Casos de Uso describe quién hace qué en el sistema, antes de diseñar las tablas.

  • Actor: persona o sistema externo que interactúa con el sistema (representado como un muñeco).
  • Caso de Uso: acción que el actor realiza (representado como una elipse).
  • Relación: línea que conecta actor con caso de uso.

Actores en TechStyle: Cliente Web, Gerente de Ventas, Sistema de Bodega.

Casos de Uso: Registrar Venta, Consultar Stock, Generar Reporte, Procesar Pago.

🚀 Desafío Rápido 2

En grupos de 3 (5 minutos):

Para el sistema de TechStyle, identifica:

  1. ¿Cuáles son las entidades principales? (nombra al menos 4)
  2. Para la entidad CLIENTE: lista 5 atributos relevantes para el análisis de ventas.
  3. ¿Qué tipo de relación existe entre PROVEEDOR y PRODUCTO? (1:1 / 1:N / N:M) — justifica.
  4. Si TechStyle agrega un sistema de despacho, ¿qué nueva entidad agregarías al modelo?

Normalización: ¿Para Qué Sirve?

La normalización es el proceso de organizar las tablas para:

  • Eliminar redundancia (no repetir el mismo dato en múltiples lugares).
  • Prevenir anomalías de inserción, actualización y eliminación.
  • Garantizar integridad de los datos.

Se aplica siguiendo una secuencia de Formas Normales (FN). Cada forma elimina un tipo específico de problema.

Para el 99% de los sistemas de negocio, llegar a la 3FN es suficiente.

El Caso de la Factura de TechStyle

Así almacenaba TechStyle sus facturas en Excel (sin normalizar):

N_Factura Fecha RUT Nombre_Cliente Ciudad Item1_Cod Item1_Nombre Item1_Precio Item1_Cant Item2_Cod Item2_Nombre Item2_Precio Item2_Cant
F001 15/01/26 12.345.678-9 Juan Pérez Santiago P001 Nike Air Max 89.990 1 P002 Polera Adidas 24.990 2
F002 16/01/26 23.456.789-0 María López Valparaíso P003 Short Nike 19.990 3 — — — —

Problema inmediato: ¿qué pasa si un cliente compra 5 productos? ¿Agrego Item3, Item4, Item5? → La estructura de la tabla cambia.

Eso viola la Primera Forma Normal.

1FN — Primera Forma Normal

Regla: cada celda debe contener un solo valor atómico (indivisible). No pueden existir grupos repetidos.

Antes (violación): columnas Item1, Item2, Item3… — grupos repetidos.

Después (en 1FN): una fila por cada ítem comprado:

N_Factura Fecha RUT Nombre_Cliente Ciudad Cod_Prod Nombre_Prod Precio Cantidad
F001 15/01/26 12.345.678-9 Juan Pérez Santiago P001 Nike Air Max 89.990 1
F001 15/01/26 12.345.678-9 Juan Pérez Santiago P002 Polera Adidas 24.990 2
F002 16/01/26 23.456.789-0 María López Valparaíso P003 Short Nike 19.990 3

Clave primaria compuesta: (N_Factura, Cod_Prod). ¿Nuevo problema? Nombre_Prod y Precio dependen solo de Cod_Prod, no de toda la clave.

2FN — Segunda Forma Normal

Regla: debe estar en 1FN y cada atributo no-clave debe depender de toda la clave primaria (no solo de una parte).

Problema detectado en la tabla 1FN: Nombre_Prod y Precio dependen solo de Cod_Prod (dependencia parcial).

Solución: separar en tablas distintas.

FACTURA (N_Factura, Fecha, RUT, Nombre_Cliente, Ciudad)
PRODUCTO (Cod_Prod, Nombre_Prod, Precio)
DETALLE (N_Factura, Cod_Prod, Cantidad) ← clave compuesta, sin dependencias parciales

Ahora si el precio de Nike Air Max cambia → se actualiza una sola fila en PRODUCTO.

3FN — Tercera Forma Normal

Regla: debe estar en 2FN y ningún atributo no-clave debe depender de otro atributo no-clave (no puede haber dependencias transitivas).


Problema en FACTURA: Nombre_Cliente y Ciudad dependen de RUT, no de N_Factura.

→ Si Juan Pérez se cambia a Valparaíso, actualizo Ciudad en FACTURA… pero, ¿en cuántas filas de FACTURA aparece Juan? En todas sus compras.


Solución: separar al cliente.

FACTURA (N_Factura, Fecha, RUT) ← solo la llave foránea
CLIENTE (RUT, Nombre_Cliente, Ciudad) ← datos del cliente, una sola vez
PRODUCTO (Cod_Prod, Nombre_Prod, Precio)
DETALLE (N_Factura, Cod_Prod, Cantidad)

El Resultado Final: 4 Tablas Limpias

erDiagram
    CLIENTE {
        VARCHAR rut PK
        VARCHAR nombre_cliente
        VARCHAR ciudad
    }
    FACTURA {
        INT n_factura PK
        DATE fecha
        VARCHAR rut FK
    }
    PRODUCTO {
        VARCHAR cod_prod PK
        VARCHAR nombre_prod
        DECIMAL precio
    }
    DETALLE {
        INT n_factura FK
        VARCHAR cod_prod FK
        INT cantidad
    }
    CLIENTE ||--o{ FACTURA : "emite"
    FACTURA ||--|{ DETALLE : "contiene"
    PRODUCTO ||--o{ DETALLE : "aparece en"

Resumen: Las 3 Formas Normales

Forma Normal Elimina Pregunta clave
1FN Grupos repetidos / valores no atómicos ¿Cada celda tiene un único valor?
2FN Dependencias parciales ¿Cada columna depende de toda la clave?
3FN Dependencias transitivas ¿Alguna columna depende de otra columna no-clave?

Metáfora: la normalización es como organizar una bodega. 1FN: un artículo por caja. 2FN: artículos del mismo tipo en la misma sección. 3FN: cada sección tiene su propio catálogo, sin duplicar información entre secciones.

🚀 Desafío Rápido 3

En parejas (5 minutos):

La siguiente tabla del sistema de RRHH de TechStyle está en 1FN:

ID_Contrato ID_Empleado Nombre_Empleado ID_Cargo Nombre_Cargo Sueldo_Base ID_Departamento Nombre_Depto
Clave primaria compuesta: (ID_Contrato, ID_Cargo)

Identifica:
1. ¿Viola la 2FN? ¿Cuál es la dependencia parcial?
2. ¿Viola la 3FN? ¿Cuál es la dependencia transitiva?
3. ¿Cuántas tablas necesitas para llegar a 3FN? Nombra cada una con sus atributos.

Conexión con la Toma de Decisiones

¿Por qué le importa esto a Roberto, el CEO?

  • Una BD no normalizada → anomalías → datos incorrectos → decisiones equivocadas.
  • Si el email de 500 clientes Premium está desactualizado → la campaña de María llega al segmento equivocado → $15M mal invertidos.
  • Una BD en 3FN → cada dato existe en un solo lugar → actualizaciones fiables → KPIs correctos → CMI confiable.

El modelo de datos es la base de confianza del sistema analítico.
 Un mal modelo de datos hace que todos los análisis posteriores sean cuestionables.

El Diccionario de Datos

El Diccionario de Datos es el documento que acompaña al MER. Especifica, para cada atributo, su tipo de dato, restricciones y descripción.


Es el “manual de instrucciones” para el desarrollador que implementará la base de datos. Sin él, el MER está incompleto.

Ejemplo — Tabla CLIENTE:

Atributo Tipo NOT NULL Restricción Descripción
cliente_id INT Sí PK Identificador único del cliente
email VARCHAR(100) Sí UNIQUE Correo electrónico, uno por cliente
segmento VARCHAR(20) No CHECK: Premium/Estándar/Básico Segmento comercial
fecha_registro DATE Sí Fecha de alta en el sistema

Tipos de Datos SQL Fundamentales

Los tipos de dato definen qué clase de valor puede almacenar una columna y cuánto espacio ocupa.

Tipo Uso Ejemplo en TechStyle
INT Números enteros cliente_id, stock, cantidad
VARCHAR(n) Texto de longitud variable (máx. n caracteres) nombre, email, categoria
DECIMAL(p, s) Número con decimales exactos (p dígitos, s decimales) precio_venta DECIMAL(10,2) = hasta $99.999.999,99
DATE Fecha (sin hora): YYYY-MM-DD fecha_venta, fecha_registro
BOOLEAN Verdadero / Falso producto_activo

Tipos de Datos SQL Fundamentales

Restricciones comunes:
- NOT NULL → el campo no puede quedar vacío.
- UNIQUE → no puede repetirse el valor en la columna.
- DEFAULT valor → valor automático si no se especifica.
- CHECK (condición) → MySQL verifica que el valor cumpla la condición antes de insertarlo.

Del MER al SQL: El Siguiente Paso

Una vez que el MER está en 3FN, cada entidad se convierte en una tabla SQL:

-- Cada entidad → una tabla
-- Cada atributo → una columna con su tipo de dato
-- Cada PK → PRIMARY KEY
-- Cada FK → FOREIGN KEY (garantiza integridad referencial)

CREATE TABLE cliente (
    rut          VARCHAR(12)  PRIMARY KEY,
    nombre       VARCHAR(100) NOT NULL,
    ciudad       VARCHAR(50)  NOT NULL
);

CREATE TABLE factura (
    n_factura    INT          PRIMARY KEY,
    fecha        DATE         NOT NULL,
    rut          VARCHAR(12)  NOT NULL,
    FOREIGN KEY (rut) REFERENCES cliente(rut)
);

Puntos Clave de la Semana 4

  • Excel no es una base de datos: genera anomalías de actualización, inserción y eliminación que comprometen la integridad de los datos.
  • Una entidad es una “cosa” del negocio (Cliente, Producto, Venta); un atributo es una característica de esa entidad.
  • Las relaciones entre entidades pueden ser 1:1, 1:N o N:M. Los N:M se implementan con una tabla intermedia.
  • La normalización es el proceso de eliminar redundancias: 1FN elimina grupos repetidos, 2FN elimina dependencias parciales, 3FN elimina dependencias transitivas.
  • Un modelo en 3FN garantiza que cada dato existe en un único lugar → actualizaciones confiables → análisis confiables → decisiones correctas.

Preview del Laboratorio W04

Lab W04: De la Planilla al Modelo

  • Recibirás techstyle_ventas_planas.csv: una tabla desnormalizada de ventas de TechStyle con todos los problemas vistos en clase.
  • Parte 1: Identificar las anomalías y violaciones de forma normal.
  • Parte 2: Diseñar el Diagrama MER (draw.io o MySQL Workbench) con las entidades normalizadas.
  • Parte 3: Construir el Diccionario de Datos (tipos de datos SQL por atributo).
  • Parte 4: Escribir las sentencias CREATE TABLE en SQL.