Este documento proporciona una descripción general de convenciones y notación de diagrama de relaciones de entidades de Salesforce (ERD) para ayudarle a interpretar claramente los modelos de datos de productos disponibles en la galería de modelos de datos.

Un ERD, también conocido como modelo de datos, es una representación gráfica de un sistema de información. Muestra las relaciones entre personas, objetos, lugares, conceptos y eventos en ese sistema. Es un modelo lógico que transmite la estructura funcional de los datos. En Salesforce ERD, las entidades normalmente se asignan a un objeto en la base de datos de Salesforce.

Una entidad es una cosa u objeto de importancia, ya sea real o conceptual, sobre la que se necesita conocer o mantener información.

Las entidades se representan en los diagramas como cuadros con esquinas redondeadas. Cada cuadro de entidad proporciona normalmente dos etiquetas (cuando procede):

• El nombre lógico de la entidad (p. ej. “Entidad de Salesforce” en el ejemplo mostrado aquí). Esto puede corresponder a la etiqueta singular del objeto de Salesforce representado, pero no siempre.
• El Nombre de API “físico” o Nombre de desarrollador del objeto en su organización de Salesforce (p. ej. “Nombre de API” en el ejemplo). Para objetos de paquetes gestionados, el nombre de API enumerado en el diagrama normalmente no incluye el espacio de nombres del paquete gestionado (“vlocity_ins**”, por ejemplo) a menos que Salesforce o Industry Cloud utilicen múltiples paquetes gestionados. El final del nombre de API para objetos de paquetes gestionados denota el tipo de objeto personalizado utilizado: “**c” para objetos personalizados normales y configuración personalizada, “**mdt” para metadatos personalizados, “**x” para objetos externos.

Los cuadros de entidad también pueden enumerar uno o más atributos representativos de los atributos de esa entidad. Un atributo está precedido por un carácter “#” o “-”.

• Un “#” indica un atributo que forma parte de la clave exclusiva lógica de la entidad. En el diagrama de ejemplo, “Atributo de clave de usuario” se considera la clave principal de usuario de la entidad.
• Un “•” indica un atributo no clave.

Cada diagrama de relación de entidad ilustra el modelo de datos de Salesforce desde la perspectiva de una nube especificada como Sales Cloud, Service Cloud o Marketing Cloud. El esquema de colores del diagrama refleja la nube enfocada. Todas las nubes de la industria como Financial Service Cloud, Health Cloud y Media Cloud utilizan el mismo esquema de colores de la industria.

El color de una entidad determinada en el diagrama también tiene un significado específico. El color de la nube de enfoque se indica utilizando su color con marca de Salesforce, incluyendo algunos ejemplos a continuación.

La siguiente sección revisará el formato de entidad diferente haciendo referencia a la leyenda de ejemplo de Sales Cloud a continuación:

Una entidad con los colores de la nube de enfoque representa un objeto que viene con la licencia para esa nube.

Una entidad con un relleno blanco y un borde negro representa un objeto que incluye una licencia diferente a la de la nube de enfoque y que no está ampliada por la licencia de la nube de enfoque. Las entidades Cuenta y Contacto mostradas en un sistema ERD de Sales Cloud o Service Cloud, por ejemplo, se mostrarán como blancas con un borde negro ya que esos objetos están disponibles con una licencia de plataforma.

Una entidad con un relleno gris claro y un borde negro representa un objeto que incluye una licencia diferente a la nube de enfoque, pero la nube de enfoque amplía ese objeto. Por ejemplo, Commerce Cloud amplía el objeto Producto2 base con campos adicionales. Las extensiones incluyen campos, relaciones y tipos de registro adicionales.

Las entidades sin bordes son virtuales. Cuando se utilizan en un diagrama, estos cuadros reconocen la existencia de una entidad en el modelo lógico para el dominio, pero la entidad no está implementada como un objeto físico en Salesforce. Se espera que se acceda a los datos de esta entidad a través de llamadas de API externas o Salesforce Connect en la solución implementada.

Las entidades con un borde discontinuo se modelan como tipos de registro en Salesforce. En el ejemplo que se muestra aquí, los subtipos Cuenta de negocio, Cuenta de facturación, Cuenta de consumidor y Cuenta de servicio tienen un borde discontinuo porque se asignan a tipos de registro entregados con el paquete gestionado Communications Cloud.

Las entidades con un borde de puntos son virtuales. Ni los tipos de registro ni un objeto separado se utilizan para diferenciar estos subtipos en la solución de Salesforce. Estos subtipos representan lógicamente un concepto desde el dominio que ayuda a ilustrar la funcionalidad del modelo de datos.

Un subtipo de una entidad es la definición de un subconjunto de sus incidencias. Cuando se agrega un conjunto de subtipos en una entidad de supertipo, la entidad de supertipo representa los atributos y relaciones comunes mientras que las entidades de subtipo muestran atributos y relaciones específicos del subtipo. En la notación del diagrama, los subtipos se excluyen mutuamente, lo que significa que cualquier registro único debe ser de un solo subtipo.

Los subtipos pueden tener subtipos anidados que diferencian aún más las incidencias. Los subtipos en los diagramas son lógicos pero pueden asignarse a una representación física de una de tres formas. La solidez del borde de entidad de subtipo define cómo se implementa el subtipo en el modelo de datos de Salesforce.

Las entidades de subtipo con un borde sólido tienen un objeto real que realiza un seguimiento de las incidencias de ese subtipo. En el ejemplo que se muestra aquí, el subtipo Usuario externo de Contacto tiene un borde sólido porque los contactos registrados como Usuarios externos se siguen con un registro en el objeto Usuario.

Una relación es una asociación significativa nombrada entre dos entidades.

Las marcas y el texto en o alrededor de las líneas describen la cardinalidad, la opcionalidad y el significado de la relación.

Cardinalidad indica el número relativo de incidencias en cada lado de la relación. En la notación, los extremos de una línea de relación indican la cardinalidad de la relación en ese extremo. Una pata de gallo en un extremo indica que muchas incidencias de entidad en ese extremo pueden relacionarse con cada incidencia en el extremo opuesto. La falta de una pata de gallo en un extremo indica que como máximo una incidencia de entidad en ese extremo puede relacionarse con una incidencia concreta en el otro extremo.

Salesforce admite dos tipos de campos de relaciones: campos de búsqueda y campos principal-secundario (también conocidos como principal-detalle). Los campos principal-secundario son como búsquedas obligatorias pero aplican acoplamiento adicional entre las entidades relacionadas. Los registros en el lado de la relación se eliminan en cascada cuando se elimina el registro principal. También la visibilidad de los registros de detalles está controlada por la visibilidad del registro principal.

Para ilustrar la diferencia entre una relación principal-secundaria y una relación de búsqueda, Salesforce ERD toma prestada la notación de diamante de UML. Un diamante en el lado singular de una relación significa que la entidad de ese lado desempeña la función principal en la relación. La entidad del lado de una relación de este tipo es el detalle o la entidad secundaria y se puede pensar que está incluida en la entidad principal.

Opcionalidad indica si la relación es obligatoria o no para una incidencia en cada extremo. Como concepto, la opcionalidad está estrechamente relacionada con la cardinalidad y la notación refleja esa cercanía. La opcionalidad se indica en cada extremo de una relación a través de un círculo o barra a través de la línea en el otro extremo de la relación. ¿Por qué en el otro extremo de la relación? Para incluir el marcado de opcionalidad en el mismo lado de la línea que la cardinalidad.

En el lado de muchas (es decir, pata de gallo) de la relación, casi siempre hay un círculo en la línea. Esto significa que puede haber de cero a muchas incidencias en el lado de la relación para cada incidencia en el lado singular de la relación.

En el lado singular de la relación, un círculo y una barra indican una relación opcional para la entidad en el lado de la pata de gallo de la relación. El círculo y la barra significan que puede haber cero o una incidencias en el lado singular de la relación para cada incidencia en el lado múltiple.

De manera alternativa, en el lado singular de la relación, las barras dobles indican una relación obligatoria para la entidad en los distintos lados de la relación. Las barras dobles significan que debe haber una y solo una incidencia en el lado singular de la relación para cada incidencia en el lado de varias.

La opcionalidad de una relación puede mostrarse como obligatoria aunque la relación física subyacente en Salesforce sea opcional. Por ejemplo, el campo AccountId en Contacto es físicamente una relación opcional, pero si ignora Contactos privados, la relación directa de un Contacto con una Cuenta es lógicamente obligatoria. El indicador de opcionalidad se utiliza con moderación. En la mayoría de los casos, la opcionalidad mostrada en el sistema ERD refleja la opcionalidad subyacente de la relación.

Más allá de la cardinalidad y la opcionalidad, cada relación entre dos entidades expresa un cierto significado que distingue esa relación de otras relaciones entre las mismas dos entidades. Los nombres de extremo de relaciones, como “parte de” y “compuesto de” en el diagrama anterior, definen la naturaleza de la relación.

Cuando combina la cardinalidad, la opcionalidad y los nombres finales de una relación, se pueden utilizar para formar una frase que describe la relación.

De izquierda a derecha: Cada (puede/debe) ser <nombre final 1> (uno y solo uno / uno o más) .

De derecha a izquierda: Cada (puede/debe) ser <nombre final 2> (uno y solo uno / uno o más) .

Por ejemplo,

De izquierda a derecha: “Cada contacto debe ser principalmente un contacto para una y solo una cuenta.” De derecha a izquierda: “Cada Cuenta puede estar representada principalmente por uno o más Contactos.”

Las líneas de relaciones están codificadas por colores. Las relaciones agregadas por la nube enfocada para el diagrama se dibujan en un color. Las líneas negras representan una relación que incluye una licencia diferente a la de la nube de enfoque.

Las relaciones pueden ser entre dos incidencias de la misma entidad. Esto se denomina una relación recursiva. Se utiliza una línea de relación curva para indicar relaciones recursivas.

Los sistemas ERD de Salesforce normalmente excluyen la mayoría de las reglas de negocio para centrarse en la estructura del modelo de datos, pero una relación mutuamente excluyente es una regla de negocio que es informativa para la estructura de modo que se anota. Una relación mutuamente excluyente indica que solo se utilizará una de las varias relaciones incluidas en el arco para cualquier incidencia concreta. Tenga en cuenta que dos, tres o más relaciones pueden participar en la misma relación mutuamente exclusiva. Una frase que describe la relación mutuamente excluyente mostrada aquí podría ser: “Cada Entidad puede ser una instancia de una y solo una Primera Otra Entidad o una y solo una Segunda Otra Entidad.”

Tenga en cuenta que en Salesforce ERD, una línea de relación discontinua que pasa por el arco no forma parte de la relación mutuamente excluyente.

Los ERD de productos oficiales de Salesforce siguen las convenciones de formato para mejorar la capacidad de lectura. Estas convenciones de formato incluyen lo siguiente:

• Las líneas de relación siempre deben ser rectas.
• Las líneas de relación deben trazarse vertical u horizontalmente. En raras ocasiones donde esto no es posible, utilice una línea recta en una diagonal.
• Con el fin de mantener las líneas de relación rectas, los cuadros de entidad se pueden cambiar de tamaño (más altos o más anchos) para proporcionar un lugar de destino para las relaciones entre las dos entidades. Las entidades más importantes (que tienen más relaciones aterrizando en ellas) se muestran más grandes en el diagrama reforzando su importancia.
• En un único ERD, las patas de gallo en las relaciones deben estar de forma coherente en el lado izquierdo y/o superior de la línea de relación (formato boca abajo) o de forma coherente en el lado derecho y/o inferior de la línea de relación (formato del lado derecho hacia arriba). Esta convención proporciona claridad ya que da como resultado entidades similares recopiladas en la misma área del diagrama, lo que es útil para comprender las entidades. El uso del formato boca abajo da como resultado diagramas que aparecen boca abajo con entidades secundarias cayendo por encima o a la izquierda de entidades principales; sin embargo, esto garantiza que las entidades más específicas en el diagrama caen en la esquina superior izquierda del diagrama, lo que hace que los diagramas sean más distinguibles entre sí y reconocibles. El uso de la convención de formato del lado derecho hacia arriba da como resultado que las mismas entidades comunes caigan en la parte superior izquierda de cada diagrama, pero las entidades secundarias estarán por debajo o a la derecha de las entidades principales.

La adhesión estrecha a estas convenciones de formato da como resultado un diagrama limpio y fácil de leer.

Asegúrese de consultar la galería de modelos de datos para los modelos de datos de Salesforce más recientes que siguen este estándar.