Crear consultas de relaciones con objetos estándar

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

• Describir dos tipos de consultas de relación.
• Identificar la relación entre dos objetos.
• Crear una consulta de secundario a principal utilizando notación de punto.
• Crear una consulta de principal a secundario utilizando una subconsulta.
• Usar una subconsulta para filtrar los resultados de la consulta.

Siga el proceso con Trail Together

¿Desea seguir el proceso con un experto a medida que realiza este paso? Eche un vistazo a este vídeo, parte de la serie Trail Together en Trailhead Live.

(Este clip comienza en la marca del minuto 36:18, en caso de que desee retroceder y volver a ver el principio del paso).

Acerca de las consultas de relación

Como administrador de Salesforce, ya está familiarizado con los campos de fórmula que extraen datos de registros relacionados. Ahora puede aplicar su conocimiento sobre las relaciones entre objetos para escribir consultas SOQL.

Aunque la cláusula FROM (DESDE) está limitada a un solo objeto, podemos acceder a dos objetos relacionados utilizando una consulta de relación. Una consulta de relación se basa en la relación entre dos objetos diferentes para devolver campos de ambos objetos. Piense en ello como una consulta entre objetos.

Considerar este requisito:

"Obtener una lista de todos los contactos con el nombre de cuenta de cada contacto".

Podemos consultar el objeto Contact (Contacto), pero no tiene un campo Account Name (Nombre de cuenta). El nombre de la cuenta es en realidad el campo Name (Nombre) en la Account (Cuenta) que está relacionada con Contact (Contacto). En una organización, se utiliza un campo de fórmula para acceder a un campo de cualquier objeto relacionado. En Apex, se utiliza una consulta de relación, pero el tipo de consulta de relación depende de cómo están relacionados los dos objetos.

Para obtener registros:

• Si quiere obtener registros de un objeto secundario e incluir campos de un objeto principal relacionado, use una consulta de secundario a principal.
• Si quiere obtener registros de un objeto principal e incluir campos de un objeto secundario relacionado, use una consulta de principal a secundario.

Antes de decidir qué tipo de consulta utilizar, necesitamos saber cómo están relacionados nuestros dos objetos, Contact (Contacto) y Account (Cuenta). ¿Cuál es el principal y cuál el secundario?

Identificar la relación entre los objetos

Como administrador, ya conoce cómo funciona la relación maestro-detalle en una organización. Una relación de maestro-detalle es una relación de principal a secundario. El objeto maestro es el principal, y el objeto detalle es el secundario. Si los dos objetos que desea incluir en una consulta tienen una relación de maestro-detalle, entonces sabe cuál es el principal y cuál es el secundario.

Una relación maestro-detalle es una relación de uno a varios. El objeto maestro (el principal) puede tener muchos objetos detalle (secundarios), pero cada objeto detalle (secundario) tiene solo un objeto maestro (principal).

Si no conoce bien los dos objetos que desea incluir en una consulta, o no sabe cómo están relacionados, explore los objetos en Object Manager (Gestor de objetos). Comience con el objeto que es más probable que sea el secundario y revise Fields & Relationships (Campos y relaciones). Busque un nombre de campo que pueda estar relacionado con el objeto principal.

Por ejemplo, Contact (Contacto) tiene un campo AccountId con el tipo de dato Lookup(Account) (Búsqueda[Cuenta]). Recuerde que en el código necesitamos el nombre del campo (AccountId), no la etiqueta del campo (Account Name).

En los detalles del campo AccountId, Child Relationship Name (Nombre de la relación secundaria) es Contacts (Contactos), en plural. Por defecto, el nombre de la relación para los objetos estándar es la forma plural del nombre del objeto secundario.

Child Relationship Name (Nombre de la relación secundaria) confirma que Contact (Contacto) es un objeto secundario de Account (Cuenta). También nos proporciona el nombre de la relación que necesitamos para una consulta de principal a secundario (que abordaremos más adelante en esta unidad).

Crear una consulta de secundario a principal

Ahora sabemos que Contact (Contacto) y Account (Cuenta) tienen una relación de secundario a principal. Contact (Contacto) es el secundario y Account (Cuenta) el principal. Para devolver todos los contactos (secundarios) y el nombre de la cuenta (principal) de cada contacto, necesitamos una consulta de secundario a principal.

En una consulta de secundario a principal, se consulta el objeto secundario y se obtienen los campos del objeto principal utilizando la notación de punto, de la siguiente manera:

SELECT Name, Account.Name FROM Contact

Esta instrucción SELECT (SELECCIONAR) consulta el objeto Contact (Contacto). En la cláusula SELECT (SELECCIONAR), Name es el campo Contact's Name (Nombre del contacto), y Account.Name es el campo Name (Nombre) de la Account (Cuenta) relacionada con el Contact (Contacto).

Ejecutar una consulta de secundario a principal

1. En el editor de consultas de Developer Console, escriba:

   SELECT Name, Account.Name FROM Contact

   Copy
2. Haga clic en Execute (Ejecutar).

Las primeras seis filas de sus resultados deberían ser:

La segunda columna muestra el nombre de la cuenta del objeto Account (Cuenta) principal de Contact (Contacto).

Crear una consulta de principal a secundario

Ahora consideremos cómo consultar un objeto principal y obtener campos de su objeto secundario. En una consulta de principal a secundario, usamos una subconsulta para obtener campos del objeto secundario. Una subconsulta es una instrucción SELECT (SELECCIONAR) encerrada entre paréntesis e integrada dentro de otra consulta.

Supongamos que nuestro requisito es el siguiente:

"Para cada cuenta, devolver el nombre de la cuenta y el nombre de cada contacto relacionado".

Cuando leemos "de cada contacto relacionado", se entiende que necesitamos una consulta de relación. Como Contact (Contacto) es un objeto secundario de Account (Cuenta), necesitamos una consulta de relación de principal a secundario, que contiene una subconsulta del objeto secundario.

La primera parte del requisito ("para cada cuenta, devolver el nombre de la cuenta") se convierte en la consulta principal, que forma la parte externa de la consulta completa. La segunda parte del requisito, "el nombre de cada contacto relacionado", se convierte en la subconsulta, la consulta interna integrada dentro de la consulta principal.

Primero definimos la consulta principal: SELECT Name FROM Account

A continuación, definimos la subconsulta entre paréntesis: (SELECT Name FROM Contact)

Luego, posicionamos la subconsulta como si fuera el segundo campo en la consulta principal. Agregamos una coma después de Name (Nombre) y luego insertamos la subconsulta, de la siguiente manera:

Dentro de una subconsulta, en lugar del nombre del campo del objeto relacionado, usamos el nombre de la relación secundaria. Y, como paso final, cambiamos la subconsulta para usar el nombre de la relación secundaria Contacts (Contactos), en lugar del nombre del objeto Contact (Contacto), de la siguiente manera:

Esta consulta devuelve el nombre de la cuenta y todos los nombres de contacto para todas las cuentas. Veamos esto poco a poco.

Esta consulta se ejecuta en tres partes:

1. La consulta selecciona una cuenta y obtiene el campo Account Name (Nombre de cuenta). Esa es la consulta principal (la consulta externa).
2. A continuación, la consulta examina los contactos relacionados con la cuenta y obtiene el campo Name (Nombre) de cada uno. Esa es la subconsulta (la consulta interna).
3. Luego, pasa a la siguiente cuenta y repite el proceso hasta haber seleccionado todas las cuentas.

Ejecutar la consulta de principal a secundario

1. En el editor de consultas, escriba:

   SELECT Name, (SELECT Name FROM Contacts) FROM Account

   Copy
2. Haga clic en Execute (Ejecutar).

Las primeras seis filas de sus resultados deberían verse así:

¡Qué interesante! La ventana de resultados de la consulta muestra los nombres de las cuentas y una colección de registros de contactos secundarios asociados a cada cuenta. Este tipo de colección probablemente le resulte familiar porque tratamos los mapas en el módulo de Programación orientada a los objetos para administradores.

Si no recuerda qué es un mapa, no se preocupe: vamos a repasarlo. Una colección de mapas contiene pares clave-valor separados por comas. La clave es el nombre del campo, como Name (Nombre). La clave va seguida de su valor, como Jake Llorrac. Los pares clave-valor son devueltos por la instrucción SELECT (SELECCIONAR) integrada que consulta los contactos relacionados con la cuenta.

Filtrado con una subconsulta

Supongamos que solo queremos las cuentas que tengan un contacto relacionado con el apellido Forbes. Esto es complicado porque queremos filtrar el objeto principal, Account (Cuenta), por un valor en el objeto secundario, Contact (Contacto). De la misma manera en que integramos una subconsulta dentro de la consulta principal, podemos usar una subconsulta (del objeto secundario) en la cláusula WHERE (DÓNDE) de la consulta principal. Los resultados de la subconsulta actúan como un filtro para la consulta principal. Si ya conoce los filtros cruzados, agregar la cláusula WHERE (DÓNDE) en la subconsulta es equivalente a usar un filtro cruzado en un informe.

Comenzamos con la consulta que tenemos actualmente:
SELECT Name, (SELECT Name FROM Contacts) FROM Account

A continuación, necesitamos una subconsulta que obtenga el campo AccountId de los contactos que tengan el apellido Forbes:

(SELECT AccountId FROM Contact WHERE LastName = 'Forbes')

Puede que se pregunte por qué necesitamos el campo AccountId del contacto. Comprobamos el campo AccountId del contacto para encontrar los contactos que están relacionados con una cuenta. Un contacto está relacionado con una cuenta cuando el campo AccountId en el objeto Contact (Contact) y el campo Id (Identificador) en el objeto Account (Cuenta) tienen el mismo valor (Contact.AccountId = Account.Id). Así que consultamos el objeto Contact (Contacto) y devolvemos su valor de AccountId. Para seleccionar la cuenta relacionada con el contacto, encontramos la cuenta que tiene ese valor en su campo Id (Identificador).

Por último, agregamos una cláusula WHERE (DÓNDE) a la consulta principal. Queremos seleccionar un registro de Account (Cuenta) solo si su Id (Identificador) se encuentra en el campo AccountId de un Contact (Contacto) devuelto por la subconsulta. Entonces, añadimos WHERE Id IN (DONDE el Id. esté en) seguido de la subconsulta, de la siguiente manera:

SELECT Name, (SELECT Name FROM Contacts) FROM Account WHERE Id IN (SELECT AccountId FROM Contact WHERE LastName = 'Forbes')

Esta consulta hace cuatro cosas.

1. La consulta encuentra los contactos con el apellido Forbes y devuelve el valor del campo AccountId de cada contacto. (La subconsulta en la cláusula WHERE [DÓNDE] hace eso).
2. A continuación, encuentra el valor de ese AccountId en el campo Id (Identificador) de una cuenta y obtiene el nombre de esa cuenta. (La cláusula WHERE [DÓNDE] principal hace eso).
3. Luego, la consulta examina los contactos relacionados con la cuenta y obtiene el nombre de cada contacto. (La subconsulta de la consulta principal hace eso).
4. Por último, la consulta principal devuelve el nombre de cada cuenta que tiene un contacto relacionado con el apellido Forbes y, para cada una de esas cuentas, los nombres de todos los contactos relacionados.

Ejecutar la consulta filtrada

1. En el editor de consultas, escriba:

   SELECT Name, (SELECT Name FROM Contacts)
   FROM Account
   WHERE Id IN (SELECT AccountId FROM Contact WHERE LastName = 'Forbes')

   Copy
2. Haga clic en Execute (Ejecutar).

Sus resultados deberían verse así:

Resumen

Ahora ya sabes cómo elegir y construir el tipo correcto de consulta de relación para los objetos estándar. En la siguiente unidad, aprenderá sobre las consultas de relación para objetos personalizados.

Recursos

• Documentación de desarrolladores de Salesforce: Entendiendo los nombres de relaciones
• Documentación de desarrolladores de Salesforce: Uso de las consultas de relación