Diseñar una base de datos sin un modelo mental claro es la receta perfecta para el caos. Antes de escribir cualquier instrucción en SQL, es fundamental comprender tres pilares: entidades, atributos y relaciones. Dominar estos conceptos marca la diferencia entre un esquema limpio y escalable, y lo que en consultoría se conoce como la temida "tabla monstruo".

¿Qué es la tabla monstruo y por qué deberías evitarla?

La tabla monstruo aparece cuando alguien decide poner toda la información en un solo lugar [0:12]. Clientes, productos y pedidos mezclados en cuarenta columnas. Al principio parece simple, pero las consecuencias son graves:

• Nadie sabe qué columna pertenece a qué concepto.
• Hay duplicación masiva de datos.
• Si un producto cambia de precio, hay que actualizar miles de filas.
• Si alguien actualiza solo la mitad, la información queda inconsistente.

El modelo plano no fue diseñado para actualizarse. El modelo relacional, en cambio, sí lo fue. La solución comienza por pensar primero en entidades.

¿Qué es una entidad y cómo se traduce a SQL Server?

Una entidad es cualquier cosa importante que el negocio necesita recordar [1:05]. Existe por sí sola, tiene propiedades y se relaciona con otras entidades. La traducción directa a SQL Server es clara:

• Entidad equivale a una tabla.
• Atributo equivale a una columna de esa tabla.
• Instancia equivale a una fila de esa tabla.

Este es el puente conceptual más importante. Un cliente existe aunque no haya hecho pedidos aún; eso lo convierte en una entidad independiente [1:30]. María García sería una instancia, es decir, una fila específica en la tabla. El número que la identifica de forma unívoca, como clienteID, es la clave primaria.

¿Cuáles son las entidades del ejemplo tienda LATAM?

Se trabaja con seis entidades principales, cada una con su clave primaria y atributos esenciales [1:50]:

• Clientes.
• Productos.
• Pedidos.
• Categorías.
• Países.
• Empleados.

La entidad pedido tiene dos claves foráneas: apunta a clientes y a empleados. Esas conexiones son las relaciones entre tablas.

¿Qué tipos de atributos existen?

No todos los atributos funcionan igual. Reconocer su tipo ayuda a diseñar columnas más precisas [2:50]:

• Atributo simple: un solo valor indivisible, como nombreProducto = Laptop HP ProBook.
• Atributo compuesto: por ejemplo, la dirección debe separarse en calle, número y ciudad; nunca en una sola columna.
• Atributo derivado: se calcula en la consulta, no se almacena. La antigüedad de un empleado se obtiene a partir de su fecha de ingreso.
• Atributo multivalor: columnas como teléfono1, teléfono2, teléfono3 violan las formas normales y deben evitarse.

La regla de oro es directa: cada tabla necesita exactamente una clave primaria. Sin clave primaria, no hay tabla relacional [2:38].

¿Cómo identificar las entidades de un negocio desde cero?

Existe un proceso práctico de cuatro pasos que se aplica al iniciar cualquier proyecto [3:28]:

• Paso 1: buscar los sustantivos del negocio. Al leer la descripción del proyecto con atención, las entidades aparecen: cliente, producto, pedido, categoría, país.
• Paso 2: aplicar el filtro de contexto. ¿"Ciudad" es entidad o atributo? Depende del negocio. Si se necesitan reportes por ciudad, es entidad. Si solo es un dato del cliente, es atributo.
• Paso 3: definir los atributos esenciales. Sin volverse loco, empezar por el identificador, los descriptivos y las claves foráneas.
• Paso 4: trazar las relaciones. Un cliente puede tener muchos pedidos, un pedido puede tener muchos productos. Esas conexiones definen la estructura.

El ejercicio recomendado antes de avanzar es dibujar en papel las seis entidades de tienda LATAM con sus atributos principales y señalar el identificador de cada una [4:18]. El valor real está en el acto de pensar el modelo antes de buscar respuestas. ¿Ya intentaste dibujar tu propio diagrama? Comparte tu versión y compárala con la de otros.