Cuando toda la información de un negocio vive en una sola hoja de cálculo con cuarenta columnas, el caos es cuestión de tiempo. Nombres de clientes, productos, pedidos y direcciones mezclados en filas interminables generan problemas reales de consistencia y mantenimiento. Comprender cómo separar esa información antes de escribir una sola línea de código es la habilidad que distingue a una base de datos robusta de una que colapsa en meses.

¿Por qué una tabla gigante es una trampa para tus datos?

Imaginen a Ana García, clienta de una tienda en línea, con cincuenta compras registradas [0:24]. En una tabla plana, su nombre, email y teléfono aparecen copiados cincuenta veces. Si Ana cambia su email, hay que actualizar cincuenta registros. Basta con olvidar tres para que el sistema muestre tres emails distintos sin que nadie sepa cuál es el correcto [0:46].

Ese fenómeno se conoce como anomalía de actualización [0:52]: la misma información repetida en múltiples filas provoca inconsistencias cuando se modifica un solo dato. Lo mismo ocurre con un producto que cambia de precio: si se actualiza en todos los pedidos antiguos, se pierde el historial real; si no se toca, el precio vigente nunca se refleja [0:58]. No existe una respuesta limpia porque la estructura nunca fue diseñada para manejar ese caso.

Cada vez que el negocio crece y necesita registrar sucursales o proveedores, la solución es seguir agregando columnas a esa tabla monstruo. Cada cambio se vuelve más difícil que el anterior [1:21].

¿Qué son las entidades y cómo se traducen a SQL?

La solución comienza con una idea sencilla: separar cada concepto del negocio en su propia caja [1:36]. A esas cajas las llamamos entidades. Una entidad es algo importante que el negocio necesita recordar y que existe por sí solo [1:44].

• Un cliente existe aunque nunca haya comprado nada.
• Un producto existe aunque nadie lo haya pedido todavía.

El puente entre el pensamiento de negocio y SQL funciona así [1:56]:

• La entidad se convierte en una tabla.
• Los atributos (propiedades que describen a la entidad, como nombre, email o código postal) se convierten en columnas.
• Cada instancia concreta —por ejemplo, Ana García con su email específico— se almacena como una fila [2:19].

Pensar en la entidad como un molde de galletas ayuda: el molde define la forma, cada galleta cortada es una instancia y todas las galletas en la bandeja forman el conjunto de entidades [2:22].

¿Qué tipos de atributos existen?

No todos los atributos se guardan igual. Hay cuatro tipos esenciales [2:58]:

• Atributo simple: un valor indivisible como el precio o el email. Se guarda directo en una columna.
• Atributo compuesto: la dirección es el ejemplo clásico. Si se almacena completa en una sola columna, después no se puede filtrar por ciudad. La solución es dividirla en calle, número, ciudad y código postal [3:13].
• Atributo derivado: la edad de un empleado se calcula a partir de su fecha de nacimiento. No se almacena, se calcula cuando se necesita. Si se guardara, habría que actualizarla cada año y, al olvidarlo, la base de datos mentiría [3:33].
• Atributo multivalor: un cliente puede tener tres teléfonos. Crear columnas Teléfono1, Teléfono2, Teléfono3 genera un límite artificial. La regla correcta es crear una tabla separada conectada mediante el identificador del cliente [3:50]. Esto es exactamente lo que exige la Primera Forma Normal [4:26].

¿Cómo funciona la clave primaria?

Toda tabla necesita algo que identifique cada fila sin ambigüedad: la clave primaria [4:45]. Sus tres condiciones son inquebrantables:

• Unicidad: no pueden existir dos filas con el mismo valor.
• No nula: sin identificador, la fila no existe en el modelo relacional.
• Estabilidad: no debería cambiar una vez asignada [4:53].

Existen dos caminos: usar una clave natural (un dato real del negocio, como el email) o una clave artificial (un número generado automáticamente) [5:12]. Si Ana cambia su email y este es la clave primaria, todas las referencias en la tabla de pedidos apuntan a una dirección que ya no existe [5:29]. En cambio, con un ClienteID autogenerado, Ana puede cambiar su email cien veces: el identificador mil uno siempre será Ana y las referencias nunca se rompen [5:53]. La única excepción razonable son códigos estándar que genuinamente no cambian, como los códigos de país ISO [6:17].

¿Cómo detectar entidades en la vida real con la técnica del sustantivo?

La técnica del sustantivo consiste en tomar la descripción del negocio y subrayar todos los sustantivos [6:36]. Por ejemplo: "Los clientes realizan pedidos de productos. Los pedidos son gestionados por empleados. Los productos pertenecen a categorías." Los sustantivos candidatos son: cliente, pedido, producto, empleado y categoría [6:43].

Después se aplica el filtro de independencia [6:59]:

• ¿Puede existir por sí solo?
• ¿El negocio necesita recordar información específica sobre esto?
• ¿Aparecería en un reporte como lista propia?

Si la respuesta es sí, es entidad. Si no, probablemente es solo un atributo [7:08]. El caso de "ciudad" lo ilustra bien: si solo interesa saber dónde vive un cliente, ciudad es un atributo; si el jefe pide reportes de ventas por ciudad y análisis demográficos, entonces necesita su propia tabla [7:16].

Todo este proceso de identificar entidades, definir atributos y elegir claves primarias es el trabajo que ocurre antes de escribir SQL [7:53]. Es pensar, y ese pensamiento es lo que separa una base de datos que funciona durante años de una que colapsa en seis meses.

¿Ya identificaron las entidades de su propio trabajo? Compartan cuáles encontraron y qué dudas les surgieron al aplicar la técnica del sustantivo.