Construye el modelo lógico
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)
Módulo 3 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: Dibuja las relaciones · Siguiente: Pon los datos donde corresponden
La pregunta que responde este módulo: ¿Cómo convierto un modelo conceptual en un modelo de datos lógico?
El modelo conceptual nos dijo qué existe en Steve Trucking y cómo se relaciona: los socios minoristas y sus centros de distribución, los manifiestos y las entregas, los destinatarios, las rutas y las paradas, los equipos, los camiones y las asignaciones de equipo. Eso basta para una conversación muy productiva con el negocio. Pero tarde o temprano necesito más detalle. ¿Qué necesitamos saber de una entrega? ¿Qué hace distinto a un centro de distribución de otro? ¿Cómo identificamos a un destinatario? ¿Qué pertenece a una asignación de equipo y no al equipo o al camión? Esas preguntas nos llevan de un modelo conceptual hacia un modelo de datos lógico, y todavía no estamos construyendo Salesforce.
Sentado, quieto, modelo
Sección titulada «Sentado, quieto, modelo »Primero, volvamos a los perros. Tenemos las cajas y las líneas. Ahora, dos preguntas nuevas: ¿qué sabemos de cada cosa y cómo distinguimos una de otra?
¿Qué la describe? Un perro tiene un nombre y una fecha de nacimiento. Un dueño tiene un nombre, un número de teléfono y una dirección. Un truco tiene un nombre y una dificultad. Cada hecho va en la caja que describe.
Luego, la entidad de unión. Qué tan bien hace Bella Sentado, y cuándo lo aprendió: ¿eso describe a Bella? No del todo; hace mejor unos trucos que otros. ¿Describe a Sentado? No; cada perro hace Sentado de una forma distinta. Describe a Bella y a Sentado juntos, así que pertenece al Truco del perro: el nivel de habilidad y la fecha en que lo aprendió. Por eso existe la entidad de unión: algunos hechos solo pertenecen a la pareja.
¿Qué perro es cuál? Prueba primero con el nombre. Hay muchísimos perros llamados Max, así que el nombre no es único. ¿El número de teléfono del dueño? Marcus tiene dos perros con el mismo teléfono, la gente cambia de número, y es un dato personal de alguien, que se copiaría en cada sistema que alguna vez apunte a un perro. El número de microchip parece mejor: es único y no cambia. Pero un cachorro nuevo quizá todavía no tenga chip, y una clave no puede estar vacía. Así que el microchip se queda, como algo por lo que el perro también se conoce, y el perro recibe su propio ID del perro (Dog ID): un número que hace un único trabajo aburrido, distinguir un perro de otro.
Esas son las mismas preguntas que ahora le haremos a Steve Trucking, y las razones por las que el nombre, el teléfono y el microchip no sirven se convierten en una regla que sostengo desde hace años.
El conceptual me dice qué existe; el lógico me dice qué significa como datos
Sección titulada «El conceptual me dice qué existe; el lógico me dice qué significa como datos »Toma Camión. ¿Qué necesito saber de un camión? Quizá su número de unidad, VIN, marca, modelo, año del modelo, matrícula, kilometraje actual y estado. Esos son atributos de Camión.
Ahora toma Entrega. Quizá el número de pedido del socio minorista, la fecha de entrega, la franja horaria prometida, la hora real de llegada, el estado y si incluye una instalación o un retiro del aparato viejo. Otra vez, atributos.
El modelo conceptual nos dijo que existe la Entrega. El modelo lógico empieza a decirnos qué significa una entrega como datos. Una caja simple como Camión o Entrega puede representar todo un conjunto de campos.
Aun así, en la mayoría de nuestros diagramas las cajas se quedan simples, por tres razones. El número de campos crece. Los campos quedan obsoletos rápidamente. Y cada campo tiene detalles difíciles de mostrar en un modelo de objetos: su nombre de API, su etiqueta, su tipo de datos y su longitud. Esos detalles se van a registrar sin duda, solo que no en el primer modelo de datos. Cuando mostrar unos pocos campos clave ayuda de verdad a contar la historia, dibujo un modelo de datos detallado: una porción concreta, solo con los campos que importan para la idea.
Los atributos deberían describir la entidad
Sección titulada «Los atributos deberían describir la entidad »Esta es una pregunta sencilla que uso cuando miro un atributo: ¿qué describe esto? La marca del camión claramente describe el camión. Pero ¿y los nombres de los miembros del equipo en una entrega? ¿Describen la entrega? ¿O describen un equipo, que tuvo una asignación de equipo, que cubrió la ruta, que incluía esta parada?
Aquí es donde un modelo de datos empieza a dejar al descubierto cosas que parecen perfectamente razonables en una pantalla. Un coordinador dice: “Quiero ver los nombres del equipo en la entrega”. Es un requisito de experiencia de usuario válido. No es necesariamente un requisito de guardar los nombres del equipo en la entrega. Son dos cosas distintas, y volveremos a ello con la normalización. Por ahora, acostúmbrate a preguntar qué cosa describe realmente este dato. Esa pregunta te ahorrará muchos problemas.
Luego tenemos que hablar de los ID únicos
Sección titulada «Luego tenemos que hablar de los ID únicos »Los atributos describen cosas. Pero hay otro problema que resolver: ¿cómo sé qué cosa es cuál?
Dos destinatarios se llaman John Smith. ¿Son la misma persona? Quizá sí, quizá no. Un nombre no basta. ¿Una dirección? La gente se muda. Los números de teléfono cambian. Las direcciones de correo electrónico cambian. Incluso el nombre de un socio minorista puede cambiar.
Esto nos lleva a las claves: lo que nos permite identificar algo de forma única en nuestro modelo. Es un área sobre la que, con los años, me he formado una opinión bastante firme. Para un identificador quiero cuatro cosas:
Único. Inmutable. Sin significado. Nunca datos personales (PII).
Único. Un identificador tiene que identificar exactamente una cosa. Si dos entregas pueden tener el mismo valor, no es un identificador de entrega confiable. Los nombres no suelen ser únicos, las direcciones no son necesariamente únicas y los números de teléfono se comparten. Incluso los valores que hoy parecen únicos pueden dejar de serlo cuando tengas suficientes datos. Así que pregunta: ¿pueden dos de estos tener alguna vez el mismo valor? Si la respuesta es sí, ten mucho cuidado con usarlo como el ID único del registro.
Inmutable. Este se pasa por alto. Si identificamos a un socio minorista por su nombre y el socio cambia de nombre, ¿tenemos un socio nuevo? No. La entidad del negocio siguió siendo la misma; cambió uno de sus atributos. El ID único de un registro debería sobrevivir a los cambios de lo que identifica, lo que descarta nombres, direcciones de correo electrónico, números de teléfono, direcciones postales y nombres de usuario, por muy cómodos que parezcan cuando empezamos a construir un sistema.
Sin significado. Suena raro la primera vez que lo oyes. ¿Por qué querría que un identificador no tuviera significado? Porque el significado cambia. Imagina que alguien construye un ID de entrega que codifica el centro de distribución, el socio minorista, la fecha de entrega y un número de secuencia: PHX-KEY-20261002-0042. Parece ingenioso. Luego el destinatario cambia la entrega al viernes. ¿Cambiamos el identificador? Si no lo hacemos, nos está mintiendo. Si lo hacemos, cambiamos el ID único de la entrega porque cambió uno de sus atributos, y cada sistema que guardó el ID antiguo acaba de perderle la pista. El identificador intentaba hacer dos trabajos: identificar la entrega y describirla. Prefiero que los atributos la describan y que el identificador haga un único trabajo aburrido: identificarla. Los identificadores aburridos son buenos identificadores.
Nunca datos personales (PII). Este es lo bastante importante como para mantenerlo aparte. No uses información de identificación personal como identificador solo porque parece única. En Steve Trucking es tentador reconocer a un destinatario por su número de teléfono. Pero una clave se copia en todas partes donde los sistemas necesitan conectar registros: integraciones, exportaciones, logs, archivos de estado que vuelven a los socios minoristas, el almacén de datos, los datos de prueba. Haz de un número de teléfono la clave y habrás esparcido los datos personales de un destinatario por toda la arquitectura.
Una clave también tiene que estar presente en cada registro: nunca nula ni vacía. Si algunas personas no te darán un valor, o no deberían tener que dártelo, ese valor no puede ser la clave. Por eso los sistemas emiten sus propios identificadores internos, y los datos personales, si es que los necesitas, se convierten en un atributo protegido.
Así que mi regla es: único, inmutable, sin significado, nunca datos personales (PII).
Claves naturales y claves sustitutas
Sección titulada «Claves naturales y claves sustitutas »La gente de bases de datos tiene nombres para algo de esto. Una clave natural ya existe en los datos del negocio: el VIN de un camión es un buen ejemplo. Nuestra aplicación no lo inventó, y ya tiene significado. Una clave sustituta se crea específicamente para identificar el registro; no describe nada, solo identifica.
En la mayoría de las arquitecturas prefiero una clave sustituta como ID de registro interno y conservo los identificadores naturales importantes como atributos. Eso no hace malos a los identificadores naturales; a menudo son extremadamente importantes. Simplemente no los convierto automáticamente en el ID único del registro. Pregunta qué pasa si el valor se corrige, se reformatea, se reemplaza, se reutiliza, falta o llega desde más de un sistema de origen. Ahí es donde una decisión de apariencia simple se convierte en una decisión de arquitectura.
Una cosa puede tener varios identificadores útiles
Sección titulada «Una cosa puede tener varios identificadores útiles »El ID de registro interno no es necesariamente el identificador que usan todos los demás sistemas. Steve Trucking podría identificar una entrega internamente con un ID generado. Cada socio minorista conoce esa misma entrega por su propio número de pedido: Keystone en su manifiesto CSV, Redrock en su API, Brightwave en sus mensajes EDI. Y los ocho años de historial de RouteDesk, la herramienta de despacho heredada, usan los propios ID de entrega de RouteDesk.
Esos identificadores importan. Tenemos que conservarlos y mapearlos correctamente, porque una actualización de estado tiene que volver a cada socio con su número. Pero no todos tienen que convertirse en el ID único de la entrega. “¿Cuál es su ID?” puede tener más de una respuesta, y el arquitecto tiene que saber qué ID es el de referencia en cada contexto. Volveremos a esto con los datos maestros y la integración.
Las relaciones dependen de los ID únicos
Sección titulada «Las relaciones dependen de los ID únicos »Ahora vuelve a las líneas que dibujamos. Un manifiesto enumera entregas. Un destinatario recibe entregas. Un equipo tiene asignaciones de equipo. Esas relaciones solo funcionan porque podemos identificar de forma confiable las cosas de ambos extremos.
Aquí es donde muerde en Steve Trucking. Un socio minorista revisa su manifiesto el mismo día: un pedido cancelado, un artículo cambiado, una dirección nueva. Si no podemos emparejar la línea revisada con la entrega que ya tenemos, mediante el número de pedido del socio, creamos una segunda entrega para el mismo refrigerador, y un equipo puede presentarse dos veces. Cajas, atributos, claves y relaciones no son ideas separadas. Son partes del mismo modelo.
A estas alturas quizá estés pensando: “Salesforce le da un ID a cada registro”. Correcto, y llegaremos ahí. Si los datos viven en Salesforce, cada registro recibe un ID generado por Salesforce. Es críptico y difícil de leer, así que normalmente también exponemos un campo de ID que la gente pueda usar, como un número de entrega D-000184227, un campo de numeración automática (Auto Number). La gente suele pensar que ese número es el ID del registro, pero no lo es: el ID de Salesforce sigue estando debajo. Un sistema o una base de datos externa, Oracle o SQL Server, también tiene sus propios ID únicos. Pero la arquitectura puede acabar incluyendo Salesforce, el ERP de finanzas, Snowflake, Data 360, los sistemas de los socios y sistemas que todavía no existen. El modelo lógico describe los datos del negocio sin hacer que cada decisión dependa de una tecnología. Cómo lo implementa físicamente Salesforce es un paso posterior.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »Cuando convierto un modelo conceptual en un modelo lógico, estoy decidiendo:
- Qué atributos describen realmente cada entidad.
- Cómo se identifica de forma única cada entidad, y si ese identificador es lo bastante estable para ser su ID único.
- Qué identificadores del negocio (números de pedido de los socios, ID heredados) hay que conservar y mapear.
- Si se está usando información sensible como clave.
- Si las relaciones conectan las entidades mediante ID únicos confiables.
Ahora tenemos entidades, relaciones, atributos e ID únicos: los comienzos de un modelo de datos lógico de verdad. Pero todavía hay un problema. Es muy fácil poner datos perfectamente válidos en el lugar equivocado. Ahí entra la normalización.
Explora
Sección titulada «Explora »- Custom Field Types (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-10-09): la numeración automática asigna a cada registro un número único con un formato de presentación, como un prefijo y ceros a la izquierda; no es el ID de Salesforce del registro. Consulta también Auto-Number Fields Are Not Always Sequential (opens in a new tab) (en inglés, consultado el 2026-10-09).