Del modelo ER al esquema de base de datos

Esto no es un espantapájaros: es la forma que tiene una hoja de cálculo, y en una hoja de cálculo empiezan la mayoría de los esquemas. Vale la pena ser preciso sobre qué falla, porque "no está normalizada" no explica nada:

Lo que sigue es modelado de esquemas de bases de datos en el sentido corriente de la expresión: decidir cuáles son las tablas, qué columna identifica cada fila y dónde se le permite vivir a un hecho. Es el paso entre un diagrama ER y un DDL que una base aceptará, y conviene darlo sobre papel, porque cada una de estas decisiones sale cara de deshacer una vez que hay datos en la tabla.

1. No puedes guardar un cliente que no ha pedido nada. El cliente solo existe como columnas de un pedido.
2. Corregir un correo obliga a actualizar todas las filas donde aparece ese cliente - y saltarse una deja a la base sosteniendo dos respuestas distintas.
3. Borrar el último pedido borra al cliente. La información desaparece como efecto colateral de algo que no tiene que ver.
4. product_names contiene una lista. A partir de ahora toda consulta que necesite un producto analiza una cadena, y ningún índice puede ayudar.
5. total puede contradecir a las líneas de las que se supone que es la suma.

Esos cinco tienen nombre - anomalías de inserción, de actualización y de borrado, un grupo repetido y un valor derivado - y la normalización no es más que el procedimiento que los elimina.

Todo lo demás depende de esto, así que va antes que las tablas. Una clave primaria debe ser única, nunca nula y no cambiar jamás. La tercera condición es la que descarta a la mayoría de los candidatos.

Hay seis formas normales y necesitas tres. Cada una es una sola pregunta sobre una tabla, y la respuesta "no" te dice qué columna mover adónde.

Pasa la tabla plana por las tres. La 1FN parte product_names y quantities en una tabla order_lines, una fila por producto. La 2FN nota que el nombre y el precio de un producto dependen solo del producto, así que aparece products. La 3FN nota que el nombre y el correo del cliente dependen del cliente y no del pedido, así que aparece customers. Cuatro tablas, que son justo el diagrama de cabecera - y ningún paso pidió criterio, solo la pregunta.

La columna total de la tabla plana es un problema distinto de los otros cuatro: no está mal colocada, está duplicada. Se puede calcular a partir de las líneas del pedido, así que puede contradecirlas, y acabará haciéndolo.

Tres respuestas legítimas, por orden de preferencia: calcularla en la consulta; calcularla en una vista; guardarla y dejar que la base la mantenga - una columna generada, una vista materializada o un disparador. Lo que no es legítimo es guardarla y confiar en que el código de la aplicación se acuerde de actualizarla; esa es la versión que produce facturas que no cuadran.

Un modelo ER sabe expresar un supertipo con subtipos; una base relacional no tiene esa construcción, así que el modelo físico debe elegir uno de tres diseños. Los tres se usan mucho y la elección es un compromiso real.

Regla aproximada: pocos subtipos con columnas casi todas comunes favorecen la tabla única; muchos subtipos con columnas divergentes y restricciones reales favorecen la tabla por subtipo; y los subtipos que nunca se consultan juntos favorecen tablas separadas. El diagrama de clases del mismo dominio habrá elegido su herencia sin enfrentarse a nada de esto, y por eso los dos modelos tienen permiso para diferir aquí.

Un modelo ER lógico se traduce a DDL casi mecánicamente, que es la recompensa por haberlo dibujado bien:

Dos cosas que el diagrama no te dice y que el DDL debe decidir: qué pasa al borrar (CASCADE para una relación identificadora, RESTRICT para casi todo lo demás), y qué columnas reciben índices más allá de las claves. Ambas son decisiones sobre comportamiento y carga, no sobre el modelo, y ambas conviene anotarlas junto al esquema en lugar de descubrirlas después en un registro de consultas lentas.

1. Normalizar más allá de lo útil. La 3FN es el destino de un esquema transaccional. Partir una tabla porque una columna podría repetirse algún día no aporta nada y cuesta una reunión para siempre.
2. Sin claves ajenas, "por rendimiento". El coste es una búsqueda en índice al escribir; el beneficio es que las filas huérfanas se vuelven imposibles. Casi nunca es el intercambio correcto.
3. Columnas anulables haciendo de tabla ausente. Seis columnas que solo se rellenan para un tipo de fila son un subtipo pidiendo su propia tabla.
4. status como texto libre. Restríngelo - con una restricción de comprobación, un enumerado o una tabla de referencia - o en un año contendrá shipped, Shipped y SHIPPED.
5. Marcas de tiempo sin zona horaria. Correctas exactamente una vez, en una oficina, hasta que el primer servidor se mude.
6. El diagrama abandonado tras la primera migración. Un diagrama de esquema que contradice a la base es peor que ninguno, porque la gente se fía de él.

Si los símbolos de cardinalidad de los diagramas de arriba necesitan descifrarse, están cubiertos en la notación pata de gallo; la forma del modelo en sí está en los diagramas ER.