Pon los datos donde corresponden

🌐 También en 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 4 de 6 del capítulo Modelar los datos con sentido, capítulo 2 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Construye el modelo lógico · Siguiente: Diseña hasta la Tercera Forma Normal y luego retrocede

La pregunta que responde este módulo: ¿Cómo me ayuda la normalización a descubrir dónde pertenecen realmente los datos?

Tenemos un modelo lógico: entidades, relaciones, atributos y claves. Ahora quiero hacer una de las preguntas más importantes del modelado de datos: ¿estos datos pertenecen realmente aquí?

Suena sencillo. No lo es. He visto muchísimos sistemas en los que cada campo tenía sentido cuando alguien lo creó. El problema no era que los campos fueran ridículos; era que los datos estaban guardados en el lugar equivocado. Una entrega guarda información que en realidad describe un centro de distribución. La misma dirección aparece en cientos de registros. Un campo guarda tres valores separados por comas. Un cambio en un dato del negocio significa actualizar 10,000 registros. Ese es el problema que la normalización nos ayuda a resolver, y antes de enterrarnos en terminología de bases de datos, esta es la idea completa: pon cada dato donde corresponde. Todo lo demás de este módulo nos ayuda a hacerlo de forma más sistemática.

¿Qué es la normalización?

La normalización es organizar los datos de modo que cada dato se guarde una sola vez, en el lugar al que pertenece. Cuando una tabla hace demasiados trabajos, la dividimos en tablas que describen cada una una sola cosa, y las conectamos con claves.

¿Para qué molestarse? Porque un dato guardado una vez es un dato que cambiamos una vez. La normalización evita la redundancia, el mismo dato copiado en muchos registros, y con ella las inconsistencias que se cuelan cuando una copia se actualiza y las demás no. Por eso encaja con los sistemas transaccionales como Salesforce, donde los registros se crean y se actualizan todo el día.

Normalizamos por pasos llamados formas normales, y cada una hace una sola pregunta:

• Primera forma normal (1FN): un valor por campo, y algo que identifique de forma única cada fila.
• Segunda forma normal (2FN): cada dato describe todo lo que identifica la fila, no solo una parte.
• Tercera forma normal (3FN): cada dato describe esta cosa, no otra cosa con la que está relacionada.

Hay más formas después de la tercera. Diré algo sobre ellas más adelante, y sobre por qué normalmente nos detenemos en la tercera. Primero, veamos cómo ocurren los tres pasos.

¿Por qué normalizamos?

Cuando enseño esto en vivo, no empiezo con entregas. Empiezo con perros. Todo el mundo entiende de perros, así que nadie se distrae con el negocio, y podemos ver cómo los datos intentan encontrar su hogar. Luego llevamos los mismos movimientos a Steve Trucking.

Sentado, quieto, modelo

Inicio: la hoja de cálculo en bruto. Pongo un par de perros en la pantalla y luego la sala agrega los suyos. En pocos minutos tenemos una gran lista: el perro, el año en que nació, quién es su dueño, dónde vive el dueño, la raza, quién lo crió y los trucos que sabe.

Perro	Nacido	Dueño	Código postal	Ciudad	Raza	Criador	Trucos
Bella	2017	Marcus	80202	Denver	Labrador	Maple Ridge	Sentado, Quieto, Pata
Milo	2019	Marcus	80202	Denver	Poodle	Golden Meadow	Sentado, Rodar
Max	2022	Ana	64105	Kansas City	Mestizo		Sentado, Hazte el muerto
Luna	2020	Kenji	98101	Seattle	Husky	Cascade	Sentado, Quieto, Gira
Rocky	2024	Priya	30301	Atlanta	Beagle	Maple Ridge	Sentado
Coco	2014	Ana	64105	Kansas City	Chihuahua	Little Paws	Pata, Gira

Funciona. Toda hoja de cálculo funciona el primer día. Pero mira lo que ya está mal. ¿Cómo encuentro todos los perros que saben dar la Pata? El código postal de Ana está en dos filas, y el de Marcus también: ¿qué pasa si alguien actualiza una y no la otra? Maple Ridge aparece dos veces, y Kansas City también. Y Max vino de la perrera, así que no tiene criador.

Paso 1: primera forma normal. Dos reglas. Cada campo guarda un solo valor, así que la lista de trucos separada por comas tiene que irse. Y cada fila necesita algo que la identifique de forma única. No el nombre del perro: hay muchísimos perros llamados Max. Un ID: un ID autogenerado o un GUID. Los trucos salen a sus propias filas, una fila por cada perro y cada truco. Y una vez que un truco tiene su propia fila, hay lugar para lo que nunca podíamos decir en una lista separada por comas: qué tan difícil es el truco, qué tan bien lo hace este perro y cuándo lo aprendió.

Perro (identificado por el ID del perro)

ID del perro	Nombre	Nacido	Dueño	Código postal	Ciudad	Raza	Criador
D-001	Bella	2017	Marcus	80202	Denver	Labrador	Maple Ridge
D-002	Milo	2019	Marcus	80202	Denver	Poodle	Golden Meadow
D-003	Max	2022	Ana	64105	Kansas City	Mestizo
D-004	Luna	2020	Kenji	98101	Seattle	Husky	Cascade
D-005	Rocky	2024	Priya	30301	Atlanta	Beagle	Maple Ridge
D-006	Coco	2014	Ana	64105	Kansas City	Chihuahua	Little Paws

Truco del perro (identificado por el ID del perro + el truco)

ID del perro	Truco	Dificultad	Nivel	Aprendido
D-001	Sentado	Fácil	Experto	2017-11
D-001	Quieto	Fácil	Experto	2018-01
D-001	Pata	Media	Bueno	2018-06
D-002	Sentado	Fácil	Experto	2020-02
D-002	Rodar	Difícil	Aprendiendo	2023-05
D-003	Sentado	Fácil	Bueno	2022-06
D-003	Hazte el muerto	Difícil	Aprendiendo	2024-03
D-004	Sentado	Fácil	Experto	2020-11
D-004	Quieto	Fácil	Bueno	2021-01
D-004	Gira	Media	Experto	2021-06
D-005	Sentado	Fácil	Aprendiendo	2025-02
D-006	Pata	Media	Experto	2015-06
D-006	Gira	Media	Aprendiendo	2025-04

Ahora “todos los perros que saben dar la Pata” es una pregunta sencilla. Pero fíjate en qué identifica a Truco del perro: no una cosa, sino dos cosas juntas, el perro y el truco. Guarda eso en mente.

Paso 2: segunda forma normal. La segunda forma normal solo importa cuando una fila se identifica por una combinación, y Truco del perro lo hace. Así que le pregunto a cada columna: ¿describe la combinación completa, o solo una parte? El nivel describe a este perro haciendo este truco: Bella es experta en Sentado, Rocky todavía lo está aprendiendo. Aprendido, lo mismo. ¿Pero la dificultad? Sentado es fácil sin importar qué perro lo haga. Describe el truco, solo una parte de la clave, y por eso “Fácil” se repite en cada fila de Sentado. Así que el truco tiene su propia tabla, y lo que queda es el par.

Truco

ID del truco	Truco	Dificultad
T-01	Sentado	Fácil
T-02	Quieto	Fácil
T-03	Pata	Media
T-04	Rodar	Difícil
T-05	Hazte el muerto	Difícil
T-06	Gira	Media

Truco del perro (ID del perro + ID del truco)

ID del perro	ID del truco	Nivel	Aprendido
D-001	T-01	Experto	2017-11
D-001	T-02	Experto	2018-01
D-001	T-03	Bueno	2018-06
D-002	T-01	Experto	2020-02
D-002	T-04	Aprendiendo	2023-05
D-003	T-01	Bueno	2022-06
D-003	T-05	Aprendiendo	2024-03
D-004	T-01	Experto	2020-11
D-004	T-02	Bueno	2021-01
D-004	T-06	Experto	2021-06
D-005	T-01	Aprendiendo	2025-02
D-006	T-03	Experto	2015-06
D-006	T-06	Aprendiendo	2025-04

Esa tabla Truco del perro es la que encontramos en el módulo 2, y tiene nombre en el modelado de datos: una unión (junction) o, como yo la llamo, un objeto de unión lógico. Un perro sabe muchos trucos; un truco lo saben muchos perros. La unión se sitúa entre ellos, y no es una simple tubería vacía: guarda los datos que pertenecen a la relación misma, el nivel y la fecha. La volveremos a ver en el módulo 6, y en el capítulo 3 veremos que Salesforce usa “objeto de unión” en un sentido más estrecho: un objeto de unión de Salesforce (Salesforce Junction Object) es un objeto personalizado con dos relaciones principal-detalle (capítulo 3, módulo 7).

Paso 3: tercera forma normal. Ahora volvamos a la tabla Perro. Todo lo que hay en ella se identifica por el ID del perro, así que la segunda forma normal no tiene nada que decir. La tercera forma normal hace otra pregunta: ¿este dato describe al perro, o a otra cosa con la que el perro está relacionado? La raza es una cosa en sí misma: un labrador es un labrador sea cual sea el perro, y los datos sobre ella, como su tamaño, pertenecen a la raza, no a Bella. El código postal y la ciudad describen al dueño, no al perro: ahí es donde vive Ana, sea cual sea el perro suyo que estemos mirando. Los datos del criador describen al criador. Cada uno de ellos es un dato sobre otro dato, así que cada uno se muda a su propia tabla, y el perro apunta a ella con una clave foránea:

• Perro: ID del perro, Nombre, Nacido, ID del dueño, ID de la raza, ID del criador
• Dueño: ID del dueño, Nombre, Código postal, Ciudad
• Raza: ID de la raza, Raza, Tamaño
• Criador: ID del criador, Nombre, Ciudad
• Truco y Truco del perro, del paso 2

Ahora Ana se guarda una sola vez, con sus dos perros apuntando a ella. Maple Ridge se guarda una sola vez, y la tabla Raza nos da un hogar para los datos de cada raza, como su tamaño, que la hoja de cálculo no tenía dónde poner. Una clave foránea puede estar en blanco: Max no tiene ID del criador, y esa es una respuesta honesta, no un hueco. Luego le lanzo a la sala una pregunta con trampa: la fecha en que el dueño recibió al perro, ¿dónde va? En el perro. En este modelo un perro tiene un solo dueño a la vez, así que esa fecha describe la relación del perro con su dueño.

Podrías ir un paso más allá y separar la ciudad del código postal; los libros de texto lo hacen. En la práctica, una dirección se queda junta, y además Kansas City está en dos estados, un buen recordatorio de que el mundo real no lee nuestros libros de texto.

Esa es la progresión: una hoja de cálculo, luego tres preguntas, y cada dato termina en un solo lugar. Da un paso atrás y mira lo que construimos. Una lista desordenada se convirtió en seis tablas, cada una describiendo una sola cosa, conectadas por claves:

Click to enlarge

Nadie necesitó una sola palabra de Salesforce para seguir eso. Son solo los perros, las personas que los rodean y lo que saben.

Ahora apliquémoslo a Steve Trucking

Los perros hacen que los movimientos sean fáciles de ver. Un negocio real hace que importen, porque los mismos errores cuestan dinero de verdad a escala. Así que llevemos las mismas tres preguntas a Steve Trucking. Imagina que guarda sus entregas así:

Entrega	Socio minorista	Centro de distribución	Ciudad del CD	Equipo	Camión
1001	Keystone	Keystone Phoenix DC	Phoenix	Equipo 12	117
1002	Keystone	Keystone Phoenix DC	Phoenix	Equipo 8	122
1003	Keystone	Keystone Phoenix DC	Phoenix	Equipo 12	117

A primera vista no hay nada complicado aquí. Pero mira el centro de distribución. Repetimos “Keystone Phoenix DC, Phoenix” en cada entrega que sale de él: Steve Trucking hace unas 3,300 entregas al día entre nueve centros de distribución, así que unos cientos al día desde cada uno. ¿Qué pasa si ese centro se muda? ¿Cuántos registros cambiamos, y qué pasa si se nos escapa uno? Ahora los datos dicen que el centro está en dos ciudades a la vez. Eso es una anomalía de actualización. ¿Y si queremos dar de alta un centro de distribución nuevo antes de su primera entrega? ¿Y si eliminamos la última entrega de un centro: acabamos de eliminar el único lugar donde guardábamos algo sobre él?

Son síntomas distintos del mismo problema: mezclamos datos sobre cosas distintas. Los datos del centro de distribución pertenecen al centro de distribución. Los datos de la entrega pertenecen a la entrega. Los datos del equipo pertenecen al equipo. Eso es la normalización en términos prácticos.

Primera Forma Normal: no escondas estructuras que se repiten

Empecemos por la Primera Forma Normal, o 1FN, donde a veces la gente hace la normalización más difícil de lo necesario.

Supón que una entrega tiene un campo llamado Artículos: “Refrigerador, kit de máquina de hielo, retiro del aparato viejo”. Hemos metido tres datos en un solo campo. Parece cómodo, hasta que alguien pregunta: “¿Cuántos retiros hicimos el mes pasado?”. O imagina campos llamados Artículo 1, Artículo 2 y Artículo 3. Funciona, hasta la entrega con cuatro artículos. El problema no es que eligiéramos el número equivocado de campos de Artículo. El problema es que no reconocimos la estructura que se repite. Una entrega puede tener varios artículos. Eso son datos que deberíamos modelar: el Artículo de entrega que encontramos en el módulo 2.

Click to enlarge

La lección práctica de la 1FN: no escondas estructuras que se repiten dentro de los campos. Si el negocio te dice que algo puede pasar muchas veces, escucha. Puede que haya otra entidad intentando salir.

Lo verás todo el tiempo en organizaciones reales. Alguien necesita una descripción en varios idiomas, así que crea un campo llamado Description_English, luego Description_French, luego Description_German. O una aprobación necesita a varias personas, así que tenemos Aprobador 1, Aprobador 2, Aprobador 3. Cuando encuentro eso en una revisión, es un tirón de orejas: arregla tu modelo de datos. Uno o dos, quizá, si el negocio de verdad solo tiene uno o dos. Cualquier cosa más allá debería ser un objeto hijo: una Traducción con un idioma, un Paso de aprobación con un aprobador. El siguiente idioma, o el cuarto aprobador, se convierte en un registro nuevo, no en un campo nuevo y un despliegue.

Segunda Forma Normal: describe la cosa completa

La Segunda Forma Normal, o 2FN, importa cuando un registro se identifica por una combinación de cosas. Toma el Artículo de entrega. Tiene su propio ID de registro, pero cada uno es único por Entrega + Producto. Supón que guardamos la entrega, el producto, la cantidad y la descripción del producto.

La cantidad tiene sentido aquí: describe este producto en esta entrega. Pero la descripción del producto no describe la combinación; describe el producto. Ponla en cada Artículo de entrega y la repetiremos cada vez que ese modelo de refrigerador salga en otro camión. Esa es la pista de que el dato pertenece a otro lugar.

Así que la pregunta de la 2FN es: ¿este atributo describe la cosa completa que estoy identificando, o solo una parte? Si describe solo el producto, va con Producto. Si describe el lugar del producto en esta entrega concreta (la cantidad, si se instala), pertenece al Artículo de entrega. Muchos administradores nunca dirán conscientemente “ahora estoy aplicando la Segunda Forma Normal”. No pasa nada. Me importa mucho más que aprendas a preguntar: ¿qué describe realmente este dato?

Tercera Forma Normal: no guardes datos sobre otros datos

Ahora la que más me importa para el modelado del día a día: la Tercera Forma Normal, o 3FN.

Cada centro de distribución tiene un gerente del lado del socio minorista, alguien que usa el portal de socios. Supón que ponemos el nombre del gerente del centro directamente en cada entrega. ¿Qué pasa cuando el centro tiene un gerente nuevo? Actualizamos cada entrega de ese centro. Otra vez ese olor: estamos repitiendo un dato que pertenece a otro lugar. La entrega sale de un centro de distribución; el centro tiene un gerente. Son dos relaciones, y el nombre del gerente pertenece al centro.

La versión clásica de los libros es la dirección: código postal, ciudad y estado guardados juntos en cada registro, cuando la ciudad y el estado normalmente se derivan del código postal. La misma forma, la misma pregunta.

Click to enlarge

La pregunta práctica de la 3FN es: ¿este dato describe esta cosa, o algo distinto con lo que esta cosa está relacionada? Quiero que te la hagas constantemente.

Ahora da un paso atrás, igual que hicimos con los perros. La tabla de entregas con la que empezamos se ha convertido en cinco cosas, cada una con sus propios datos: el Artículo de entrega salió en la primera forma normal, el Producto en la segunda, y la ciudad y el gerente del centro de distribución se mudaron al Centro de distribución en la tercera.

Click to enlarge

Las mismas tres preguntas, el mismo resultado: cada dato en un solo lugar.

Una forma sencilla de pensar en la 1FN, la 2FN y la 3FN

Podrías dedicar un curso entero de bases de datos a la normalización. No lo vamos a hacer. Para este curso, quiero que tengas una comprensión práctica de arquitecto:

• 1FN: ¿estoy escondiendo varios valores o estructuras que se repiten dentro de un campo o de un registro?
• 2FN: ¿este dato describe la cosa completa que estoy identificando?
• 3FN: ¿este dato describe realmente esta entidad, o algo relacionado con ella?

No son definiciones para un libro de texto de bases de datos. Son preguntas que de verdad puedo usar mientras diseño.

Sí, la normalización va más allá: la Forma Normal de Boyce-Codd (FNBC) endurece las reglas en torno a la 3FN para modelos con claves más complicadas, y existen la Cuarta, la Quinta e incluso la Sexta Forma Normal. Se ocupan de tipos de repetición más raros, los que vienen de estructuras de claves inusuales más que de los registros cotidianos de un negocio. Mucha teoría y, en mi experiencia, no vale el dolor de cabeza para el tipo de sistemas que construimos en Salesforce. En los sistemas de negocio, la presión suele ir en sentido contrario: es mucho más probable que retrocedamos desde la tercera forma normal, por los usuarios, los informes y el rendimiento, que ir más allá de ella. Ese es el próximo módulo. Sabe que las otras formas existen, pero para la mayor parte de lo que hacemos, de la 1FN a la 3FN nos dan las herramientas de pensamiento que necesitamos.

Diseña hasta la Tercera Forma Normal

Esta es mi postura. Cuando intento entender un negocio y diseñar su modelo lógico, quiero empezar limpio: los datos de la entrega con la entrega, los del centro de distribución con el centro, los del camión con el camión, y los conceptos que se repiten modelados como conceptos. No quiero un dato del negocio copiado por todo el modelo solo porque podría hacer más fácil una pantalla o un informe. Todavía no.

Pero la normalización no es una religión. El objetivo no es el modelo más académicamente puro posible. He visto arquitectos tan centrados en la pureza que el modelo se vuelve doloroso para todos los que tienen que usarlo. No intentamos ganar un concurso de normalización; estamos construyendo un sistema, y ese sistema tiene usuarios, informes, integraciones, necesidades de rendimiento, escala y, cada vez más, IA que lee los datos. Todos ellos pueden querer los datos con formas distintas.

Así que mi punto de partida es diseñar hasta la Tercera Forma Normal donde sea viable y luego retroceder cuando sea necesario: entender primero dónde pertenece cada dato. Luego, si nos vamos a apartar de ella, quiero saber por qué. Si la respuesta es “porque no sabía dónde más poner el campo”, no basta. Si la respuesta es “copiamos este valor a propósito porque simplifica el informe de desempeño de los socios, y tenemos una forma confiable de mantenerlo sincronizado”, ahora sí estamos teniendo una conversación de arquitectura.

Lo que decide aquí un arquitecto

Cuando normalizo un modelo lógico, busco:

• Valores o estructuras que se repiten y que deberían modelarse por separado.
• Atributos que describen una entidad distinta de aquella en la que están guardados.
• Datos duplicados innecesariamente en muchos registros, y las dependencias que hacen que se vuelvan inconsistentes.
• Conceptos de negocio escondidos dentro de los campos.
• Un modelo limpio que represente la verdad antes de cualquier concesión de implementación.

No porque todo sistema físico deba quedarse perfectamente normalizado. Todo lo contrario. En el próximo módulo nos apartaremos del modelo limpio a propósito, por los usuarios, los informes, la escala, la analítica y la IA, y lo haremos sabiendo exactamente a qué renunciamos.