Convierte el modelo en Salesforce
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 6 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: Diseña hasta la Tercera Forma Normal y luego retrocede · Siguiente: la guía de estudio del capítulo, y luego el próximo capítulo: Arquitectura de datos de Salesforce
La pregunta que responde este módulo: ¿Cómo se convierte un modelo de datos lógico en un modelo de datos físico de Salesforce?
Por fin vamos a hablar de Salesforce. Si has estado resistiendo las ganas de convertir cada caja en un objeto, ahora puedes. Pero fíjate en el orden en que llegamos aquí: entendimos el negocio, describimos los datos, pusimos cada dato donde corresponde y decidimos dónde lo íbamos a doblar a propósito. Solo ahora pregunto cómo debería implementarlo Salesforce. Esa es la progresión que quiero que recuerdes: conceptual → lógico → físico. El modelo conceptual describe el negocio. El modelo lógico describe los datos. El modelo físico describe cómo lo vamos a construir realmente.
Sentado, quieto, modelo
Sección titulada «Sentado, quieto, modelo »El paso físico se ve más fácil sobre algo pequeño, así que las mascotas van primero.
¿Quiénes son las empresas y las personas? El criador es una empresa, así que se convierte en una Cuenta con un tipo de registro Criador. El dueño también es una Cuenta, o una cuenta personal, con un tipo de registro Dueño. Dos tipos del mismo objeto estándar, uno al lado del otro en la parte de arriba del diagrama, justo donde han estado desde el módulo 1.
¿Qué no tiene un hogar estándar? Mascota, Raza, Truco, Truco de la mascota y Evaluación del truco se convierten en objetos personalizados. ¿Y recuerdas la especie que copiamos en la mascota en el módulo 5? Aquí recibe su trabajo: se convierte en el tipo de registro de la Mascota, Perro o Gato. Un objeto con dos tipos de registro, cada uno con su propio formato de página y sus valores de lista de selección, en lugar de un objeto Perro y un objeto Gato.
¿Qué relaciones son principal-detalle? Uso principal-detalle solo donde el hijo nunca va a cambiar de padre. Un Truco de la mascota pertenece a su mascota de por vida, y cada Evaluación del truco pertenece a su Truco de la mascota, así que ambas son principal-detalle. Eso rinde frutos de inmediato: la principal-detalle es lo que permite que la mascota mantenga un resumen acumulativo de sus Trucos de la mascota, así que el conteo de Trucos conocidos del módulo 5 se mantiene al día solo. Pero las mascotas sí cambian de hogar, así que el Dueño es una búsqueda.
¿Cuáles son búsquedas? Salesforce no recomienda más de 10,000 hijos en un solo padre. Un truco popular como Sentado, una raza común o un criador grande podrían superar eso fácilmente, así que Truco de la mascota apunta a su Truco con una búsqueda, y la mascota apunta a su Raza y a su Criador de la misma forma. Y evita las relaciones polimórficas siempre que puedas, esas en las que un campo puede apuntar a varios tipos de objeto. Son cómodas el primer día y más difíciles para todo lo que tenga que leerlas después: informes, integraciones y, ahora, agentes.
¿Qué se queda fuera de la plataforma? Si la mascota lleva un collar GPS que informa dónde está, esa ubicación no necesita copiarse en absoluto. Puede ser un objeto externo, leído en vivo desde el sistema de rastreo del collar.
Cada decisión de ese diagrama se remonta a algo que decidimos antes, y de eso se trata. Ahora, el mismo paso para Steve Trucking.
Empieza por el modelo lógico
Sección titulada «Empieza por el modelo lógico »Nuestro modelo lógico de Steve Trucking ahora contiene Socio minorista, Centro de distribución, Manifiesto, Entrega, Artículo de entrega, Destinatario, Ruta, Parada, Equipo, Camión y Asignación de equipo. Son conceptos de negocio, y ahora puedo empezar a pasarlos a Salesforce.
Un socio minorista podría ser una cuenta. Una entrega podría corresponder a algo que Salesforce ya tiene para el trabajo programado en campo, o podría convertirse en un objeto personalizado. Un manifiesto no tiene nada estándar que encaje, así que probablemente será personalizado. Y el destinatario es una pregunta realmente difícil: ¿una cuenta personal, un contacto o simplemente información en la entrega? La responderemos como corresponde en el próximo capítulo.
La palabra importante sigue siendo podría. No supongas la implementación solo porque un concepto de negocio suena a un objeto de Salesforce. Por eso construimos primero el modelo lógico: nos da algo contra lo que poner a prueba el diseño de Salesforce.
Una entidad de negocio no significa automáticamente un objeto personalizado
Sección titulada «Una entidad de negocio no significa automáticamente un objeto personalizado »Esta es una trampa que quiero que eviten los administradores: “Identificamos once entidades, así que necesitamos once objetos personalizados”. No. Una entidad lógica nos dice que el concepto de negocio importa. No dicta cómo debe guardarlo Salesforce. Un concepto puede convertirse en un objeto estándar, un objeto personalizado, una relación entre objetos, un campo o unos pocos campos, un valor gestionado en la configuración, o datos que viven por completo fuera de Salesforce (las fotos de las entregas de Steve Trucking son buenas candidatas para eso). El modelo físico es donde se toman esas decisiones, y precisamente por eso no las tomamos en la primera llamada.
Los atributos se convierten en campos físicos
Sección titulada «Los atributos se convierten en campos físicos »La misma transición ocurre con los atributos. Nuestro Camión lógico tiene un número de unidad, VIN, marca, modelo, año del modelo, matrícula y estado. Ahora decidimos cómo existen físicamente: qué objeto es su dueño, qué tipos de campo usan, cuáles son obligatorios, cuáles deben ser únicos, cuáles son identificadores externos, cuáles necesitan validación, cuáles se derivan en lugar de guardarse y cuáles son sensibles. En el nivel lógico preguntamos qué significa Camión. En el nivel físico preguntamos cómo representará Salesforce a Camión. Preguntas distintas.
Las relaciones se convierten en decisiones de plataforma
Sección titulada «Las relaciones se convierten en decisiones de plataforma »Todo el tiempo que dedicamos a las relaciones rinde frutos aquí. Ya sabemos si cada una es de uno a uno, de uno a muchos o de muchos a muchos, obligatoria u opcional, y si importa su historial. Ahora decidimos cómo la implementa Salesforce: una búsqueda, una principal-detalle o un objeto de unión de Salesforce, y quizá un objeto de unión con atributos propios, porque, como descubrimos, la relación en sí puede tener significado de negocio.
Piensa en la Asignación de equipo. Podríamos haber empezado este capítulo diciendo: “Creemos un objeto de unión de Salesforce entre equipo y camión”. Mira lo que nos habríamos saltado: por qué existe la relación, si necesita una fecha y una ruta, si tiene un estado y si un reclamo por daños semanas después necesita su historial. Esas preguntas de negocio nos dicen qué es una Asignación de equipo. Solo entonces deberíamos decidir cómo la construye Salesforce, y si Salesforce ya tiene algo que hace el trabajo.
Ahora dibuja el modelo físico
Sección titulada «Ahora dibuja el modelo físico »El diagrama vuelve a cambiar. El modelo conceptual mostraba conceptos de negocio y líneas simples. El modelo lógico agregó atributos, claves, cardinalidad y las entidades escondidas en las relaciones. Ahora el modelo físico empieza a parecerse a Salesforce: objetos estándar, objetos personalizados, campos, tipos de relación y lo que vive fuera de la plataforma.
Quiero que puedas poner esos tres diagramas uno al lado del otro y ver la progresión: no tres diagramas sin relación, sino el mismo negocio en tres niveles.
Unas palabras sobre cómo los dibujo, porque la disposición es parte del mensaje. Pongo el objeto principal en el centro, un poco más abajo. Si tiene objetos padre, los pongo un poco más arriba, para que leas el modelo de arriba abajo y de izquierda a derecha, como lo piensa el negocio. Los datos de referencia van a un lado. El color también significa algo: siempre pongo Salesforce en azul, y elijo un color para los sistemas propios de la empresa, normalmente verde, porque el verde es un color amable. No uso el rojo, y los amarillos son un poco duros. Cuando un modelo está dispuesto así, me canta. Muchos de los diagramas que encontrarás son en realidad gestión del espacio: ¿cómo estaciono todos mis autos en mi garaje abarrotado? Prefiero pintar una imagen lógica que la mente pueda captar.
El modelo físico tiene que respetar la plataforma
Sección titulada «El modelo físico tiene que respetar la plataforma »Salesforce no es una base de datos relacional genérica. Tiene opiniones sobre las relaciones, la propiedad, la seguridad y los informes. Tiene límites, un comportamiento de consultas y automatización, y una arquitectura que afecta cómo se comporta un modelo a escala. Así que un modelo lógico que parece perfecto en un pizarrón puede necesitar cambios cuando se vuelve físico. No es que Salesforce estorbe. Significa que la plataforma tiene una forma, y los buenos arquitectos entienden esa forma. El próximo capítulo trata precisamente de eso.
A veces, además, el modelo físico se apartará a propósito del modelo lógico limpio por las decisiones de desnormalización que tomamos en el módulo 5. Está bien, siempre que podamos explicar por qué.
No diseñes desde Setup
Sección titulada «No diseñes desde Setup »Hay un hábito que quiero que rompas si lo tienes: empezar tu arquitectura de datos en Setup → Object Manager → New Custom Object (Configuración → Gestor de objetos → Nuevo objeto personalizado) e ir resolviendo el modelo sobre la marcha. Salesforce hace increíblemente fácil crear cosas; es una de sus fortalezas, y una de las razones por las que los modelos de datos débiles aparecen tan rápido. Unos pocos clics y tienes un objeto, unos pocos más y tienes campos y una relación. Luego llegan los datos, se construyen flujos, se crean informes, las integraciones dependen de ello, y el objeto que creaste en cinco minutos es carísimo de cambiar. Es la Prueba de Reversibilidad del capítulo 1. Así que, antes de hacer clic en Nuevo objeto personalizado, dibuja el modelo.
Físico no significa permanente
Sección titulada «Físico no significa permanente »Hay otra razón por la que mantengo separados los tres modelos: la tecnología cambia. Hoy parte de los datos de Steve Trucking vive en el núcleo de Salesforce. Mañana parte de ellos puede vivir en Data 360, un almacén de datos o un sistema que todavía no hemos elegido, y el asistente de IA necesita su propia representación. La arquitectura física puede cambiar, mientras que los conceptos de negocio se mantienen notablemente estables: los socios minoristas, las entregas y los destinatarios siguen existiendo. Eso es lo que hace valioso el modelo lógico. Es una descripción duradera del negocio que no está atada a la implementación de hoy.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »Cuando convierto un modelo lógico en un modelo físico de Salesforce, estoy decidiendo:
- Qué entidades de negocio corresponden a capacidades estándar de Salesforce y cuáles necesitan objetos personalizados u otra representación.
- Cómo los atributos lógicos se convierten en campos físicos, y cómo se implementan las relaciones en la plataforma.
- Dónde pertenece la desnormalización deliberada en el diseño físico.
- Qué datos pertenecen a Salesforce y cuáles a otro lugar.
- Qué características de la plataforma obligan a que el modelo físico difiera del lógico.
Sobre todo, quiero poder rastrear cada decisión hacia atrás. Si señalas algo de mi modelo físico y preguntas “¿Por qué está eso ahí?”, debería poder llevarte de vuelta por el modelo lógico y el modelo conceptual hasta algo que el negocio necesita de verdad: negocio → conceptual → lógico → físico.
Más allá del examen: lo que cambia la IA. La IA ahora puede llevar un documento de requisitos hasta los objetos y campos de Salesforce de un salto. Eso hace la secuencia más importante, no menos: si salta de los requisitos a la configuración, pídele que muestre lo que pasó entre medias: qué decidió que era una entidad, qué claves eligió, qué relaciones supuso y dónde desnormalizó. Son decisiones de arquitectura, y el arquitecto todavía necesita verlas.
Empezamos este capítulo en una primera llamada, escuchando sustantivos, y lo terminamos con un modelo físico que podemos rastrear hasta el negocio. Ahora que hemos elegido construir sobre Salesforce, la siguiente pregunta va más a fondo: ¿sobre qué tipo de plataforma de datos estamos construyendo realmente?
Explora
Sección titulada «Explora »- Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (en inglés, consultado el 2026-10-02): “configura las relaciones padre-hijo con no más de 10,000 hijos por registro padre”. Es una pauta sobre el sesgo de datos, no un límite estricto; el capítulo 7 profundiza más.
- Roll-Up Summary Field (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-10-12): un campo de resumen acumulativo cuenta o suma registros de detalle a través de una relación principal-detalle.