Diseña hasta la Tercera Forma Normal y luego retrocede
También en 28 idiomas
English · 日本語 · 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 · Español (México) · Français (Canada) · Deutsch (Schweiz)
Módulo 5 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: Pon los datos donde corresponden · Siguiente: Convierte el modelo en Salesforce
La pregunta que responde este módulo: ¿Cuándo debería alejarme a propósito de un modelo normalizado limpio?
En el módulo anterior te dije que diseñaras hasta la Tercera Forma Normal.
Ahora te voy a decir que la rompas.
A veces.
Es una distinción importante. Hay una gran diferencia entre construir por accidente un modelo de datos desordenado y desnormalizar a propósito uno limpio. Si no entiendes dónde pertenecen los datos en primer lugar, copiarlos a otro sitio no es arquitectura. Es solo duplicación.
Pero una vez que entiendo el modelo lógico limpio, puedo tomar la decisión consciente de dar a los datos una forma distinta para las personas y los sistemas que los consumen.
Diseña hasta la Tercera Forma Normal donde sea viable. Luego retrocede cuando sea necesario.
Fíjate en lo que esa frase no dice. No dice que la Tercera Forma Normal sea más fácil de entender. A veces es más difícil: un modelo totalmente normalizado puede repartir una idea de negocio entre cinco objetos, y quienes lo usan tienen que volver a armarla en su cabeza. La normalización me dice dónde pertenece cada dato. No promete que esa sea la forma más fácil de leer, usar o sacar informes. Precisamente por eso retroceder es una habilidad de diseño y no un fracaso.
Empieza modelando la verdad. Luego decide cómo hay que entregar esa verdad.
Sentado, quieto, modelo
Sección titulada «Sentado, quieto, modelo »Volvamos a los perros, y esta vez tomamos algunas decisiones deliberadas.
Raza: ¿una lista de selección o su propia tabla? Pásala por las preguntas que te daré más adelante en este módulo. ¿Hay más de una columna de información? Sí: el tamaño, por lo menos. ¿Cuántos valores? Los clubes caninos reconocen unos cuantos cientos de razas (solo el American Kennel Club enumera 205), muy por encima de mi regla práctica de unos 20. Así que la Raza se gana su propia tabla, y cada perro apunta a su raza. Eso resuelve la pregunta que arrastramos desde el módulo 1: la Raza es una caja propia.
Nivel de habilidad: una lista de selección. Aprendiendo, Bueno, Experto. Tres etiquetas, nada más que decir sobre ellas, y no van a cambiar. Exactamente para eso es una lista de selección.
¿Cuántos trucos sabe cada perro? La respuesta ya está en el modelo: cuenta los registros de Truco del perro de ese perro. Pero el entrenador quiere ese número en cada informe, para ordenar y filtrar por él, sin armar un informe que cruce dos tablas. Así que retrocedo, y guardo un conteo de Trucos conocidos directamente en el perro. Eso es una copia. La verdad sigue viviendo en Truco del perro; el conteo es una representación de ella, y tiene que mantenerse al día. Salesforce nos da una forma limpia de hacer exactamente eso, y la veremos en el módulo 6.
Ahora, el giro: la escuela canina empieza a aceptar gatos. ¿Qué hacemos? Una opción: agregar una tabla Gato junto a la tabla Perro, y un Truco del gato junto al Truco del perro. Todo se duplica: dos de cada pantalla, dos de cada informe, y el día que acepten conejos, tres. La otra opción: dar un paso atrás y notar que un gato tiene un dueño, quizá un criador, una raza, una fecha de nacimiento y, con paciencia, un truco o dos. Los mismos hechos y las mismas relaciones que un perro. Así que generalizamos: una Mascota, con una Especie, perro o gato. Cada raza también pertenece a una especie, y ahí es donde vive realmente la especie: un labrador es un perro. La mascota lleva una copia, a propósito, para que cada pantalla e informe pueda empezar con “¿perro o gato?” sin buscar la raza. Otra copia deliberada, y en el módulo 6 recibe un trabajo propio.
Eso es diseñar para el cambio, y es un compromiso. Si generalizas demasiado pronto, todo se convierte en una “Cosa” vaga con un campo de tipo que nadie entiende. Yo generalizo cuando el negocio de verdad me trae el segundo tipo, y los dos comparten casi todo, como aquí los perros y los gatos. Si los gatos necesitaran hechos muy distintos, lo pensaría dos veces.
Ahora, el mismo tipo de decisiones en Steve Trucking, donde lo que está en juego es mayor.
El modelo más limpio no siempre es el mejor sistema
Sección titulada «El modelo más limpio no siempre es el mejor sistema »Imagina a un equipo en una parada. La entrega tiene sus artículos. La instalación tiene una lista de verificación. Cada paso necesita fotos. El destinatario firma.
El modelo normalizado es precioso: Entrega → Artículo de entrega → Lista de verificación de instalación → Foto, cada cosa donde corresponde.
Luego me siento con las personas que de verdad lo usan. Un equipo cierra unas diez paradas al día, en entradas de garaje, a menudo sin señal. Si mi precioso modelo los manda por un laberinto de pantallas y listas relacionadas para terminar una parada, tengo un problema de arquitectura.
El modelo de datos no es lo único que estamos diseñando.
Estamos diseñando un sistema.
A veces gana la experiencia de usuario
Sección titulada «A veces gana la experiencia de usuario »Esta es una de las razones por las que a veces me alejo de un modelo perfectamente normalizado: la experiencia de usuario.
Quizá un concepto técnicamente podría ser su propia entidad, pero separarlo agrega una complejidad que aporta muy poco valor. Quizá un padre con varios niveles de hijos es académicamente limpio pero un suplicio para ingresar datos y mantenerlo. Quizá el concepto es pequeño, estable y se usa sobre todo como una selección.
Aquí es donde dejo de preguntar solo “¿Dónde pertenece este dato en teoría?” y empiezo a preguntar “¿Cómo se va a usar realmente este sistema?”.
Eso no significa que cada queja por un clic de más aplane el modelo. Significa que la facilidad de uso es un insumo legítimo de la arquitectura.
A veces ganan los informes
Sección titulada «A veces ganan los informes »Los informes son otra razón habitual.
Cada socio minorista quiere un informe de desempeño: entregas a tiempo por región, por mes. En el modelo limpio, una entrega conoce su centro de distribución, y el centro conoce su región. Técnicamente, podemos recorrer eso.
Pero ¿puede la herramienta de informes? ¿Pueden las personas que crean sus propios informes? ¿Pueden responder la pregunta sin una arquitectura de informes más complicada que la propia pregunta?
Ahí es cuando podría copiar o derivar la región en la entrega, más cerca de donde se consume.
Ahora he introducido duplicación. Así que necesito otra pregunta: ¿quién es dueño de la verdad?
Si el valor de origen cambia, ¿qué pasa con mi copia? ¿Debería cambiar? ¿O debería conservar lo que era cierto cuando ocurrió la entrega? Son requisitos distintos.
La desnormalización no elimina la complejidad.
La traslada.
¿Búsqueda o lista de selección?
Sección titulada «¿Búsqueda o lista de selección? »Este es un ejemplo más pequeño con el que los administradores de Salesforce se encuentran todo el tiempo. El usuario tiene que elegir entre un conjunto de valores. ¿Creo otra entidad y me relaciono con ella, o uso una lista de selección?
Toma el estado de una entrega: programada, cargada, en reparto, llegando, entregada, instalada, excepción, devuelta. Una lista corta y estable de etiquetas. Una lista de selección es exactamente lo que quiero.
Ahora toma el tipo de parada: solo entrega, entrega con instalación, entrega con retiro del aparato viejo. Esa sí lleva información propia: cuánto tarda la parada, qué habilidades necesita el equipo, qué lista de verificación de instalación aplica. Cambia por su cuenta, y el negocio la gestiona. Eso es una entidad, no una etiqueta.
Si creo un objeto por cada concepto que en teoría podría normalizarse, puedo construir un sistema técnicamente precioso que nadie disfruta usar. Si convierto cada concepto en una lista de selección porque es fácil, puedo acorralarme muy rápido.
Así que pregunto: ¿tiene información propia? ¿Relaciones? ¿Cambia por su cuenta? ¿Hay que gestionarlo como datos? ¿Podría el negocio necesitar algún día algo más que una etiqueta?
Estas son las preguntas que de verdad hago en una sesión de diseño.
¿Hay más de una columna de información? Si el valor necesita una descripción, una duración, una lista de habilidades, un dueño, ya no es una etiqueta.
¿Cuántos valores? Mi regla general es unos 20. Pasados 20 valores, una lista de selección empieza a fallar, y es momento de pensar en un objeto. Los estados de EE. UU., que son cincuenta, son la excepción con la que vivimos, y los países son peores; sinceramente, ¿a alguien le encantan las listas de selección de países? A mí me parecen molestas.
¿Los valores se crean con el tiempo, y quién los crea? Agregar un valor a una lista de selección es un cambio de configuración, lo que significa un administrador. Si el negocio agrega valores cada semana y quienes los agregan no son administradores, una lista de selección pone un ticket delante de cada valor nuevo.
¿La gente necesita filtrar y hacer informes con ello? Las listas de selección son geniales para eso. Las búsquedas no son tan limpias. Cada búsqueda agrega un salto: un tipo de informe solo sigue una cadena corta de objetos relacionados (un tipo de informe personalizado admite como máximo cuatro relaciones entre objetos), la pantalla se convierte en listas relacionadas dentro de listas relacionadas y el código se complica.
Una lista de valores a menudo nace como lista de selección y, con el tiempo, se gana un objeto propio. Deja que se lo gane.
A veces la escala cambia la respuesta
Sección titulada «A veces la escala cambia la respuesta »Un diseño que funciona de maravilla con unos pocos miles de registros puede comportarse de forma muy distinta con millones.
Así que no mires solo el diagrama. Conoce los números.
Steve Trucking hace alrededor de un millón de entregas al año, creciendo un 30 % anual. Cada entrega acumula unas ocho actualizaciones de estado. Son ocho millones de registros de estado este año, y unos 13,5 millones al año para el tercer año. Suma cuatro o cinco millones de fotos al año.
El mismo modelo. Una arquitectura muy distinta.
Profundizaremos mucho más en Arquitectura a escala. Por ahora, recuerda: el volumen puede cambiar una decisión de modelado de datos. Una relación lógicamente correcta no es automáticamente el mejor diseño físico a cualquier escala.
Consumidores distintos quieren formas distintas
Sección titulada «Consumidores distintos quieren formas distintas »Hasta ahora hemos pensado en el sistema operativo. Los coordinadores asignan rutas a las entregas. Los equipos cierran paradas. El sistema cambia a medida que funciona el negocio.
Pero el negocio también quiere analizar años de historial. ¿Qué socios y regiones van con retraso? ¿Cómo ha cambiado el tiempo de entrega? ¿Con qué frecuencia las instalaciones necesitan una segunda visita?
Un sistema analítico puede querer la misma información organizada de otra forma. Oirás términos como almacén de datos, hecho, dimensión y esquema en estrella. No los vamos a desarrollar aquí; en Steve Trucking ese es el almacén de Snowflake, y volveremos a él más adelante en el curso.
Por ahora: consumidores distintos pueden necesitar formas distintas de la misma verdad.
La IA agrega otro consumidor
Sección titulada «La IA agrega otro consumidor »Y ahora hay otro consumidor: la IA.
Un destinatario escribe: “¿Dónde está mi entrega?”. Un asistente de IA podría consultar esto:
Entrega 10427, Ruta 3312, Parada 7, Camión 117, Franja 13:00–15:00.
Una aplicación tradicional está perfectamente contenta siguiendo esas relaciones. Pero para responder al destinatario, el asistente necesita un contexto armado a partir de varios lugares:
Tu lavavajillas Redrock es la séptima parada de la ruta de hoy desde el centro de distribución de Phoenix. El camión está a tres paradas, y sigues dentro de tu franja de 1 a 3 de la tarde.
Tomamos información de varias entidades relacionadas y armamos una representación más plana y rica en contexto para un consumidor concreto.
Eso no significa que destruya mi modelo normalizado. Y definitivamente no significa “a la IA le gustan los datos planos, así que pon todo en un objeto gigante”. No lo hagas.
La fuente de la verdad se mantiene limpia. La IA recibe una representación construida para el trabajo que hace. Es la misma idea que acabamos de ver con la analítica:
Una sola fuente de la verdad puede sostener varias formas de consumo.
Profundizaremos mucho más en el grounding (anclaje en datos) y la recuperación más adelante en el curso.
No crees varias verdades
Sección titulada «No crees varias verdades »Aquí hay un peligro.
Si copio la región en la entrega para los informes, envío una versión aplanada a Snowflake y construyo una versión rica en contexto para el asistente de IA, ¿cuál es la correcta?
Esa pregunta necesita una respuesta. Quiero saber dónde vive el valor de referencia. Todo lo demás es una representación de esa verdad para un propósito.
Ese lugar es el sistema de registro. Las copias desnormalizadas pueden ser buenas: la pantalla de paradas, el informe de desempeño, Snowflake y el contexto de la IA hacen mejor su trabajo con una forma construida para ellos, y consultarlas está bien. Pero cuando algo cambia, el cambio empieza en el sistema de registro, normalmente el modelo relacional, y fluye hacia afuera, a cada copia. Nadie corrige la región en Snowflake ni edita a mano el contexto de la IA. Corrígelo en el origen y deja que el cambio fluya.
Y importa sobre todo cuando los datos cambian. Si hoy un centro de distribución pasa a otra región, ¿las entregas del mes pasado deberían mostrar la región nueva? Quizá. Quizá no. Para el historial, puede que necesite la región que era cierta cuando ocurrió la entrega. Eso ya no es un problema de sincronización. Es una decisión de negocio.
Por eso la desnormalización nunca debería ocurrir por accidente. Cada dato duplicado plantea preguntas sobre la propiedad, la sincronización, el historial y la confianza. Es el pensamiento de compensaciones del capítulo 1: sabe qué estás comprando (una pantalla más fácil, un informe más simple, mejor contexto para la IA) y qué estás pagando (datos duplicados, sincronización, una propiedad de la verdad más complicada). Y como partimos de un modelo lógico limpio, podemos señalar cada copia y decir: “Sé que esto pertenece allá. Estoy poniendo aquí una representación por este requisito”. Esa es una decisión que podemos revisar, cuestionar y dejar por escrito, para que el siguiente arquitecto sepa por qué.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »Cuando considero desnormalizar, estoy decidiendo:
- Dónde vive la fuente de referencia de cada dato del negocio.
- Si el modelo limpio crea problemas reales para los usuarios, los informes, la escala o el rendimiento.
- Si una representación más simple compensa la duplicación, y cómo se mantiene confiable la copia.
- Si los valores históricos deberían cambiar cuando cambia el origen actual.
- Si la analítica o la IA necesitan una forma de los datos distinta de la del sistema operativo.
El punto de partida nunca cambia: sabe dónde pertenece la verdad. Luego, cuando los requisitos lo justifiquen, dale forma para entregarla.
A continuación, Salesforce vuelve a la escena. Vamos a convertir lo que hemos diseñado en un modelo de datos físico.
Explora
Sección titulada «Explora »- Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24 de junio de 2019 (en inglés, consultado el 2026-10-12): un tipo de informe personalizado “puede abarcar hasta 4 relaciones de objetos”.
- Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2 de enero de 2026 (en inglés, consultado el 2026-10-12): “El AKC reconoce 205 razas, incluidas estas tres recién llegadas”.
- Por diversión: la FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (consultado el 2026-10-12): la lista de razas de la federación internacional, en diez grupos. Recórrela y verás por qué la Raza se ganó su propia tabla.