Resumen

Cuando una operación maneja millones de registros, como los nueve archivos de TiendaLatam, la pregunta inevitable es cómo diseñar un sistema que distinga registros con nombres idénticos y conecte datos sin duplicarlos. Resolver esos dos problemas desde el inicio marca la diferencia entre una base sólida y un caos de datos difícil de corregir.

¿Qué es una entidad y cómo saber si algo califica como tal?

Una entidad es cualquier cosa del mundo real sobre la que necesitamos guardar información [0:52]. Puede ser algo concreto —un cliente, un producto— o algo abstracto —un pedido, una categoría—. Un pedido no se toca, pero ocurrió en un momento y lugar específicos; una categoría como "Electrónica" no existe en un estante, pero organiza todo el catálogo [1:05]. Ambas son entidades válidas.

Para determinar si algo califica como entidad, hay tres preguntas útiles [1:18]:

  • ¿Existe de manera independiente?
  • ¿Necesito guardar datos sobre ello?
  • ¿Puede haber más de uno?

Si las tres respuestas son sí, es una entidad. El ejemplo de "Cliente" lo cumple perfectamente: María López existe independientemente de si compra algo hoy, necesitamos guardar su nombre, correo y país, y TiendaLatam tiene 2.4 millones como ella [1:34].

Es importante aclarar que entidad no es lo mismo que tabla [1:57]. La entidad es el concepto, el qué necesito representar. La tabla es cómo lo guardo en la base de datos, con filas y columnas concretas. Primero se identifica la entidad, después se construye la tabla.

¿Qué tipos de atributos existen y cuándo separar o almacenar un dato?

Las entidades por sí solas no dicen nada. Lo que les da contenido son los atributos: las características que guardamos de cada entidad [2:16]. En una tabla, cada atributo se convierte en una columna. Existen cuatro tipos:

  • Atributo simple: es indivisible. El precio de un producto es un solo número, la fecha de registro es un solo valor. No tiene partes útiles por separado [2:28].
  • Atributo compuesto: sí se puede dividir en piezas con significado propio. El nombre de un cliente es un buen ejemplo: "María" y "López" son dos datos distintos, cada uno útil por sí solo [2:40]. TiendaLatam los guarda en columnas separadas porque, si necesitamos ordenar por apellido, tener todo en un solo campo dificulta mucho la tarea.
  • Atributo derivado: se puede calcular a partir de otros datos que ya existen [3:12]. La edad de un cliente se obtiene restando su fecha de nacimiento de la fecha actual. Guardarla como columna es arriesgado porque cada año se vuelve incorrecta si nadie la actualiza. Sin embargo, el subtotal en Detalle de Pedidos, que es técnicamente calculable (cantidad por precio unitario), sí se almacena [3:38]. ¿La razón? Los precios cambian. Si el smartphone costaba 299 cuando María lo compró y luego sube a 349, el subtotal guardado preserva lo que realmente se cobró [3:55]. La regla: si no almacenar el valor significa perder información histórica, vale la pena guardarlo.
  • Atributo multivaluado: ocurre cuando un registro tiene múltiples valores para un mismo dato, como un cliente con tres números de teléfono [4:18]. Meterlos en una sola celda genera desorden. La solución es crear una tabla separada donde cada teléfono ocupa su propia fila.

¿Cómo funciona la clave primaria para identificar registros únicos?

Si hay dos clientes llamados María López, ¿cómo las distinguimos? Para eso existe la clave primaria: una columna que identifica de manera única cada fila de una tabla [4:44]. Funciona como un número de cédula: nadie más tiene el mismo y no cambia aunque la persona cambie de nombre o dirección.

Toda clave primaria debe cumplir tres condiciones [5:10]:

  • Ser única, nunca repetida.
  • Nunca estar vacía.
  • Ser estable, es decir, no cambiar con el tiempo.

Por eso usar el correo electrónico como clave primaria no es buena idea [5:21]: la gente cambia de email, dos personas podrían compartir una cuenta o alguien puede escribirlo con un error. La solución es usar una clave sustituta: un número generado automáticamente que existe únicamente para identificar cada fila [5:36]. Eso es exactamente lo que hacen los campos clienteID, productoID y pedidoID en TiendaLatam.

¿Para qué sirve la clave foránea y dónde se coloca?

Las tablas no viven aisladas: una sucursal pertenece a un país, un pedido lo hace un cliente [6:15]. La clave foránea es una columna que guarda el valor de la clave primaria de otra tabla, estableciendo la conexión sin repetir información [6:24].

En TiendaLatam, la tabla Sucursales tiene una columna PaisID [6:31]. Si una sucursal en Bogotá tiene PaisID igual a 2 y en la tabla Países el registro 2 es Colombia, la conexión queda establecida sin escribir "Colombia" en cada una de las ochocientas filas. Esto trae tres ventajas [6:48]:

  • Evita duplicar información.
  • Facilita las actualizaciones: si cambia el nombre de un país, solo hay que modificarlo en un lugar.
  • Protege la integridad de los datos porque la base puede rechazar un PaisID que no exista en la tabla Países.

La regla para saber dónde va la clave foránea es sencilla: siempre va en el lado de "muchos" [7:07]. Muchas sucursales pertenecen a un país, entonces la clave foránea va en Sucursales. Muchos pedidos los hace un cliente, entonces va en Pedidos.

Un detalle que suele generar confusión: la misma columna puede ser clave primaria en una tabla y clave foránea en otra [7:57]. PedidoID en la tabla Pedidos es la clave primaria; ese mismo PedidoID en Detalle de Pedidos es clave foránea porque indica a qué pedido pertenece cada línea. La clave primaria dice "esto es lo que soy" y la clave foránea dice "esto es a lo que estoy conectado" [8:25].

Para identificar claves foráneas en archivos CSV, busquen columnas con nombres que incluyan ID al final del nombre de otra tabla; si un mismo valor se repite varias veces en esa columna, eso confirma que es una clave foránea [8:32].

Con estos cuatro conceptos —entidades, atributos, claves primarias y claves foráneas— ya se cuenta con la base del diseño relacional. ¿Qué falta? Clasificar las conexiones entre tablas: relaciones uno a uno, uno a muchos y muchos a muchos. ¿Se animan a anticipar en cuál de esas categorías cae Detalle de Pedidos?