Modelar los datos con sentido
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)
Guía de estudio del capítulo 2 del curso Data Architect. Lee primero los seis módulos; esta página te ayuda a comprobar lo que te quedó.
Sobre esta guía de estudio. Está construida solo con el contenido de este curso y con la lista de objetivos publicada en la guía del examen de Salesforce. Nunca se basa en preguntas reales del examen, y no pretende saber qué hay en el examen. Si ya hiciste el examen, por favor no me envíes preguntas: el acuerdo de certificación prohíbe compartirlas, y memorizar respuestas es, de todos modos, la forma equivocada de convertirse en arquitecto.
Este capítulo es la base de la sección Data Modeling and Database Design (modelado de datos y diseño de bases de datos) del examen, que es una cuarta parte del examen. Cubre el pensamiento; el próximo capítulo, Arquitectura de datos de Salesforce, cubre cómo lo construye la plataforma. Así que la mayor parte de lo que se evalúa sobre objetos, campos y relaciones necesita los dos capítulos.
Para el examen
Sección titulada «Para el examen »Los puntos de este capítulo que más probablemente importen en el examen. Cada uno está vinculado a su objetivo del examen y enlaza con el lugar donde se enseña. Márcalos a medida que avanzas.
DM-1: comparar técnicas para diseñar un modelo de datos de Salesforce
- Puedo explicar la diferencia entre un modelo de datos conceptual, uno lógico y uno físico, y para qué sirve cada uno. (Convierte el modelo en Salesforce)
- Puedo encontrar entidades candidatas en un requisito, y distinguir a una persona que hace un trabajo de un dato. (Los sustantivos te dan entidades candidatas)
- Puedo leer y dibujar la notación pata de gallo: uno, muchos y la segunda marca para opcional u obligatorio. (Lee las líneas, La opcionalidad también importa)
- Puedo nombrar la cardinalidad de una relación: de uno a uno, de uno a muchos, de muchos a muchos. (Pregunta “¿uno o muchos?”)
- Sé que una relación de muchos a muchos se convierte en una entidad propia y, en Salesforce, normalmente en un objeto de unión con dos padres. (Las relaciones pueden convertirse en cosas)
- Sé cuándo una relación necesita historial (un registro con fechas de inicio y fin) en lugar de un campo que se sobrescribe. (El tiempo cambia las relaciones)
- Puedo elegir un buen ID único, y sé por qué una clave natural o cualquier cosa con información personal es una elección arriesgada. (Luego tenemos que hablar de los ID únicos)
- Sé la diferencia entre una clave natural y una clave sustituta, y que un registro puede llevar varios identificadores externos. (Claves naturales y claves sustitutas)
- Sé que un campo de numeración automática (Auto Number) es un número legible, no el ID de Salesforce del registro. (Las relaciones dependen de los ID únicos)
- Puedo aplicar la primera, segunda y tercera forma normal, y detectar un campo que guarda varios valores o que repite un dato sobre otra cosa. (Una forma sencilla de pensar en la 1FN, la 2FN y la 3FN)
- Puedo explicar cuándo desnormalizar a propósito (usuarios, informes, escala) y lo que cuesta. (Diseña hasta la Tercera Forma Normal y luego retrocede)
- Puedo decidir entre una lista de selección y una búsqueda a un objeto para una lista de valores. (¿Búsqueda o lista de selección?)
- Sé que un tipo de informe personalizado admite como máximo cuatro relaciones entre objetos, y por qué eso importa en los modelos profundos. (¿Búsqueda o lista de selección?)
- Sé cuándo encaja una principal-detalle (el hijo nunca cambia de padre) y cuándo es más segura una búsqueda, incluida la recomendación de Salesforce de no tener más de 10,000 hijos en un solo padre. (Las relaciones se convierten en decisiones de plataforma)
- Sé por qué evitar las relaciones polimórficas cuando puedo. (Las relaciones se convierten en decisiones de plataforma)
- Sé que una entidad de negocio no significa automáticamente un objeto personalizado: puede ser un objeto estándar, un campo, configuración o datos que viven fuera de Salesforce. (Una entidad de negocio no significa automáticamente un objeto personalizado)
Más allá del examen
Sección titulada «Más allá del examen »El examen es el piso, no el techo. Estos son los hábitos de este capítulo que necesita un arquitecto, los pregunte o no el examen.
- Olvídate de Salesforce por un minuto. Modela el negocio antes de pasarlo a cuentas y contactos.
- Escucha la palabra que esconde dos cosas. En Steve Trucking, “cliente” era un socio minorista y un destinatario.
- El modelo es parte de la conversación. Tu primer modelo no tiene que estar bien; tiene que mostrarte dónde te equivocas.
- Ponle nombre a las líneas. Dos modelos con las mismas cajas pueden significar cosas distintas.
- Pregunta “¿ahora o a lo largo del tiempo?” de cada relación.
- Único, inmutable, sin significado, nunca datos personales (PII).
- Pon cada dato donde corresponde, luego retrocede a propósito, y escribe por qué.
- La desnormalización no elimina la complejidad; la traslada. Sabe quién es dueño de la verdad.
- Una sola fuente de la verdad, muchas formas: pantallas, informes, el almacén de datos y la IA.
- No diseñes desde Setup. Dibuja el modelo antes de hacer clic en Nuevo objeto personalizado.
- Rastrea cada decisión física hacia atrás hasta algo que el negocio necesita.
Palabras que conviene conocer
Sección titulada «Palabras que conviene conocer »| Término | En una línea |
|---|---|
| Entidad | Una cosa que le importa al negocio y de la que guarda datos |
| Entidad candidata | Un sustantivo que podría convertirse en entidad, una vez que lo has cuestionado |
| Atributo | Un dato que describe una entidad |
| Relación | Cómo se conectan dos entidades, con un nombre en el lenguaje del negocio |
| Cardinalidad | Cuántos de uno se relacionan con cuántos del otro |
| Opcionalidad | Si la relación es obligatoria o puede ser cero |
| Pata de gallo | La marca de “muchos” en el extremo de una línea |
| Objeto de unión | La forma de Salesforce de construir una relación de muchos a muchos: un hijo de ambos padres |
| Modelo conceptual | Lo que existe en el negocio y cómo se relaciona; sin Salesforce |
| Modelo lógico | Los datos: atributos, ID únicos y relaciones, todavía sin atarse a una plataforma |
| Modelo físico | Cómo lo construirá la plataforma: objetos, campos y tipos de relación |
| Clave natural | Un identificador que ya existe en el negocio, como el VIN de un camión |
| Clave sustituta | Un identificador creado solo para identificar el registro |
| Identificador externo | El ID de otro sistema para el mismo registro, conservado y mapeado |
| Normalización (1FN, 2FN, 3FN) | Poner cada dato donde corresponde: un valor por campo, datos sobre la clave completa, ningún dato sobre otros datos |
| Desnormalización | Copiar o aplanar datos a propósito, por una razón que puedes nombrar |
| Anomalía de actualización | El mismo dato guardado en muchos lugares, de modo que un cambio deja algunas copias mal |
Ponte a prueba
Sección titulada «Ponte a prueba »Escenarios cortos al estilo del curso. Decide tu respuesta antes de abrirla.
1. Un negocio te dice que un equipo maneja un camión. Seis semanas después, alguien pregunta qué equipo tenía el camión 117 un día concreto. ¿Qué debería haber tenido el modelo?
Una Asignación de equipo: la relación entre equipo y camión como un registro propio, con una fecha de inicio, una fecha de fin y la ruta. Equipos y camiones son de muchos a muchos a lo largo del tiempo, y al negocio le importa el historial. Un campo en el camión se habría sobrescrito. Vuelve a leer El tiempo cambia las relaciones.
2. Un equipo propone usar el número de teléfono de cada destinatario como ID único, "porque es único". ¿Qué dices?
No pasa las pruebas: los números de teléfono cambian y se comparten, así que no es inmutable ni confiablemente único, y es información personal que se copiaría en cada sistema que enlace con el registro. Usa un ID generado sin significado y conserva el número de teléfono como atributo. Vuelve a leer Luego tenemos que hablar de los ID únicos.
3. Una entrega tiene los campos Artículo 1, Artículo 2 y Artículo 3. Llega una entrega con cuatro artículos. ¿Cuál es el problema real y cuál la solución?
El modelo escondió una estructura que se repite dentro de los campos (un problema de primera forma normal). La solución no es un campo Artículo 4; es una entidad Artículo de entrega, hija de Entrega, para que cada artículo sea un registro. Vuelve a leer Primera Forma Normal.
4. Cada entrega guarda el nombre del gerente del centro de distribución. El gerente cambia. ¿Qué salió mal?
Se guardó en la entrega un dato sobre otra cosa (el centro de distribución): un problema de tercera forma normal, y ahora una anomalía de actualización en cientos de registros. El gerente pertenece al centro de distribución; la entrega apunta al centro de distribución. Vuelve a leer Tercera Forma Normal.
5. El tipo de parada (solo entrega, con instalación, con retiro) necesita una duración, las habilidades del equipo y una lista de verificación. ¿Lista de selección u objeto?
Un objeto. Tiene más de una columna de información, lo gestiona el negocio y cambia a su propio ritmo. El estado de una entrega, una lista corta y estable de etiquetas, sigue siendo una lista de selección. Vuelve a leer ¿Búsqueda o lista de selección?.
6. Los socios quieren un informe de desempeño de puntualidad por región, y la región vive en el centro de distribución. Copias la región en cada entrega. ¿Qué tienes que decidir?
Quién es dueño de la verdad, cómo se mantiene sincronizada la copia, y si las entregas antiguas deberían conservar la región que era cierta cuando ocurrieron o seguir al centro de distribución si cambia de región. Desnormalizar trasladó la complejidad; no la eliminó. Vuelve a leer A veces ganan los informes.
7. Un truco como Sentado podría estar vinculado a cientos de miles de mascotas. ¿Principal-detalle o búsqueda de Truco de la mascota a Truco?
Una búsqueda. La recomendación de Salesforce es no tener más de 10,000 hijos en un solo padre, y un truco popular la superaría. La principal-detalle encaja de Truco de la mascota a Mascota, porque el truco de una mascota nunca cambia de padre y una mascota sabe solo unos pocos trucos; además, es lo que permite que la mascota acumule su conteo de Trucos conocidos. Vuelve a leer Sentado, quieto, modelo.
Explora
Sección titulada «Explora »- Guía del examen Salesforce Certified Platform Data Architect (opens in a new tab), Ayuda de Salesforce (en inglés, consultado el 2026-09-25): la lista oficial de objetivos y sus pesos. Revisa siempre la versión actual antes de reservar el examen.