Этот документ предоставляет обзор нотации диаграммы взаимосвязей объектов Salesforce (ERD) и условностей, чтобы помочь вам четко интерпретировать модели данных продуктов, доступные в галерее моделей данных.
ERD, также известная как модель данных — это графическое представление информационной системы. Он отображает взаимосвязи между людьми, объектами, местами, понятиями и событиями в этой системе. Это логическая модель, передающая функциональную структуру данных. В Salesforce ERD объекты обычно соотносятся с объектом в базе данных Salesforce.
Объект - это вещь или объект значимости, будь то реальная или концептуальная, о которых необходимо знать или владеть информацией.
Объекты представлены на диаграммах в виде полей со скругленными углами. Каждое поле объекта обычно содержит две метки (где применимо):
- Логическое имя объекта (например, «Объект Salesforce» в примере, приведенном ниже). Это может соответствовать метке единственного числа представленного объекта Salesforce, но не всегда.
- «Физическое» API-имя или имя разработчика объекта в организации Salesforce (например, «API-имя» в примере). В объектах управляемого пакета имя API, указанное на диаграмме, обычно не содержит пространства имен управляемого пакета (например, «vlocity_ins**»), если облако Salesforce или Industry не использует несколько управляемых пакетов. Конец API-имени для объектов управляемого пакета обозначает тип используемого настраиваемого объекта: «**c» для обычных настраиваемых объектов и настраиваемых параметров, «**mdt» для настраиваемых метаданных, «**x» для внешних объектов.
Кроме того, поля объекта могут содержать как минимум один атрибут, представляющий атрибуты объекта. Атрибуту предшествует символ «#» или «-».
- Значение «#» обозначает атрибут, являющийся частью логического уникального ключа объекта. В примере диаграммы «Атрибут ключа пользователя» считается основным ключом пользователя объекта.
- «•» обозначает атрибут неключа.
Каждая диаграмма взаимосвязи объекта иллюстрирует модель данных Salesforce с точки зрения указанного облака, например, Sales Cloud, Service Cloud или Marketing Cloud. Цветовая схема диаграммы отображает облако в фокусе. Все отраслевые облака, например, Financial Service Cloud, Health Cloud и Media Cloud, используют одну цветовую схему отрасли.
Цвет данного объекта на диаграмме также имеет определенное значение. Цвет фокусного облака обозначается фирменным цветом Salesforce, включая некоторые примеры ниже.
Ниже приведен пример легенды Sales Cloud, используемый в следующем разделе, посвящен разному форматированию объектов.
Объект с цветами фокусного облака представляет объект, который входит в лицензию для этого облака.
Объект с белым заполнением и черной каймой представляет объект, имеющий лицензию, отличную от лицензии фокусного облака, и не расширенный лицензией фокусного облака. Например, объекты «Организация» и «Контакт», отображаемые в ERD Sales или Service Cloud, будут отображаться белым цветом с черной границей, поскольку эти объекты доступны с лицензией платформы.
Объект со светло-серым заполнением и черной каймой представляет объект, имеющий лицензию, отличную от фокусного облака, но фокусное облако расширяет этот объект. Например, Commerce Cloud расширяет базовый объект Product2 дополнительными полями. Расширения содержат дополнительные поля, взаимосвязи и типы записей.
Объекты без границ являются виртуальными. При использовании в диаграмме эти поля признают существование объекта в логической модели домена, но объект не реализован в качестве физического объекта в Salesforce. Ожидается, что данные для этого объекта будут доступны посредством внешних вызовов API или Salesforce Connect в развернутом решении.
Объекты с пунктирной границей моделируются как типы записей в Salesforce. В примере ниже подтипы «Организация-компания», «Организация для счета», «Организация-потребитель» и «Организация-служба» имеют пунктирную границу, поскольку соотносятся с типами записей, доставленными посредством управляемого пакета Communications Cloud.
Объекты с пунктирной границей являются виртуальными. Ни типы записей, ни отдельные объекты не используются для дифференциации этих подтипов в решении Salesforce. Эти подтипы логически отображают понятие из домена, которое помогает проиллюстрировать функции модели данных.
Подтип объекта - это определение поднабора его экземпляров. При добавлении набора подтипов в объект супертипа объект супертипа отображает общие атрибуты и взаимосвязи, в то время как объекты подтипа отображают атрибуты и взаимосвязи, характерные для подтипа. В обозначении диаграммы подтипы взаимоисключающие, то есть любая отдельная запись должна быть одного подтипа.
Подтипы могут иметь вложенные подтипы, которые дополнительно различают случаи. Подтипы в диаграммах логичны, но они могут быть соотнесены с физическим представлением одним из трех способов. Сплошность границы объекта подтипа определяет способ внедрения подтипа в модель данных Salesforce.
Объекты подтипа со сплошной границей имеют фактический объект, отслеживающий случаи этого подтипа. В примере ниже подтип «Внешний пользователь» контакта имеет сплошную границу, поскольку контакты, зарегистрированные как внешние пользователи, отслеживаются с записью в объекте «Пользователь».
Взаимосвязь — это именованная значимая связь между двумя объектами.
Отметки и текст на линиях или вокруг них описывают кардинальность, дополнительность и значение взаимосвязи.
Кардинальность обозначает относительное количество случаев с каждой стороны взаимосвязи. В обозначении концы линии взаимосвязи обозначают кардинальность взаимосвязи с этой целью. Воронья нога на конце указывает, что многие случаи объекта на этом конце могут быть связаны с каждым случаем на противоположном конце. Отсутствие вороньей ноги на конце указывает на то, что как минимум одно появление объекта на этом конце может быть связано с данным появлением на другом конце.
Salesforce поддерживает два типа полей взаимосвязи: поля поиска и поля «родительский-дочерний» (также известные как «Основная — подробная»). Поля «Родительские-дочерние» аналогичны обязательным поискам, но они применяют дополнительную связь между связанными объектами. Удаление родительской записи инициирует ее каскадное удаление. Также доступность подробных записей определяется доступностью родительской записи.
Чтобы проиллюстрировать разницу между взаимосвязью «дочерний-родительский» и взаимосвязью «Поиск», Salesforce ERD заимствует алмазную нотацию из UML. Алмаз в единственном числе взаимосвязи означает, что объект на этой стороне играет основную роль во взаимосвязи. Объект на многих сторонах такой взаимосвязи является подробным или дочерним объектом и может рассматриваться как содержащийся в родительском объекте.
Дополнительный параметр определяет, является ли взаимосвязь обязательной для каждого экземпляра. Как понятие, необязательность тесно связана с кардинальностью, и нотация отражает эту близость. Дополнительный параметр обозначается в каждом конце взаимосвязи посредством круга или строки через линию на другом конце взаимосвязи. Почему на другом конце отношений? Чтобы добавить разметку дополнительности по ту же сторону линии, что и кардинальность.
На многих (то есть на ворониных ногах) сторонах взаимосвязи почти всегда есть круг на линии. Это значит, что для каждого экземпляра в единственном числе взаимосвязи может быть нулевое ко многим.
В единственном числе взаимосвязи круг и полоса обозначают необязательную взаимосвязь для объекта на стороне вороньих ног взаимосвязи. Круг и полоса означают, что для каждого экземпляра на многих сторонах взаимосвязи может быть ноль или один экземпляр.
В качестве альтернативы на стороне взаимосвязи в единственном числе двойные полосы обозначают обязательную взаимосвязь для объекта на многих сторонах взаимосвязи. Двойные полосы означают, что для каждого экземпляра на многих сторонах взаимосвязи должен быть один и только один экземпляр.
Дополнительность взаимосвязи может отображаться при необходимости, даже если базовая физическая взаимосвязь в Salesforce является дополнительной. Например, поле AccountId в поле «Контакт» является физически необязательной взаимосвязью, но если вы игнорируете личные контакты, логично, что прямая связь контакта с организацией обязательна. Индикатор дополнительности используется экономно. В большинстве случаев необязательность, отображаемая в ERD, отражает основную необязательность взаимосвязи.
Помимо кардинальности и необязательности, каждая взаимосвязь между двумя объектами выражает определенный смысл, отличающий эту взаимосвязь от других взаимосвязей между этими двумя объектами. Конечные имена взаимосвязей, например, «часть» и «состоящие» на схеме выше, определяют природу взаимосвязи.
При объединении кардинальности, необязательности и конечных имен взаимосвязи они могут использоваться для формирования предложения, описывающего взаимосвязь.
Слева направо: Каждое
Справа налево: Каждое
Например,
Слева направо: «Каждый контакт должен быть контактом только для одной организации». Справа налево: «Каждая организация может быть представлена одним или несколькими контактами».
Линии взаимосвязи кодируются цветом. Взаимосвязи, добавленные облаком в фокус диаграммы, рисуются цветом. Черные линии представляют взаимосвязь, которая поставляется с другой лицензией, чем фокусное облако.
Взаимосвязи могут быть между двумя экземплярами одного объекта. Это называется рекурсивной взаимосвязью. Изогнутая линия взаимосвязи используется для обозначения рекурсивных взаимосвязей.
Salesforce ERD обычно исключают большинство бизнес-правил, чтобы сосредоточиться на структуре модели данных, но взаимоисключающая взаимосвязь - это одно бизнес-правило, которое является информативным для структуры, поэтому следует отметить. Взаимоисключающая взаимосвязь указывает на то, что в каждом конкретном случае будет использоваться только одна из нескольких взаимосвязей, добавленных в дугу. Обратите внимание, что две, три и более взаимосвязи могут участвовать в одной взаимоисключающей взаимосвязи. Предложение, описывающее взаимоисключающую взаимосвязь, может быть следующим: «Каждый объект может быть экземпляром одного и только одного первого другого объекта или одного и только одного второго другого объекта».
Обратите внимание, что в ERD Salesforce разрыв линии взаимосвязи, проходящей через дугу, не является частью взаимоисключающей взаимосвязи.
Официальные ООД продуктов Salesforce придерживаются правил макета для улучшения читаемости. Эти типовые соглашения включают следующее:
- Линии взаимосвязи всегда должны быть прямыми.
- Линии взаимосвязи должны проводиться по вертикали или горизонтали. В редких случаях, когда это невозможно, используйте прямую линию по диагонали.
- Чтобы линии взаимосвязи были прямыми, размер полей объекта может быть изменен (более высокий или широкий), что обеспечит место для взаимосвязей между двумя объектами. Более важные объекты (с большим количеством взаимосвязей) отображаются более крупными на диаграмме, повышающей их важность.
- На протяжении одного ERD ноги вороны во взаимосвязи должны постоянно находиться с левой и/или верхней стороны линии взаимосвязи (макет вверх ногами) – или последовательно с правой и/или нижней стороны линии взаимосвязи (макет вправо-вверх ногами). Эта конвенция вносит ясность, поскольку она приводит к тому, что аналогичные объекты собираются в одной области диаграммы, что помогает понять объекты. Использование макета вверх ногами приводит к отображению диаграмм вверх ногами с дочерними объектами, расположенными выше или слева от родительских объектов, однако это обеспечивает попадание наиболее определенных объектов в левый верхний угол диаграммы, что делает диаграммы более отличимыми друг от друга и узнаваемыми. Использование правил макета вправо приводит к тому, что одинаковые общие объекты попадают в верхнюю левую часть каждой диаграммы, но дочерние объекты будут ниже или справа от родительских объектов.
Благодаря строгому соблюдению этих правил макетирования диаграмма становится чистой и легко читаемой.
Обязательно проверьте галерею моделей данных на наличие последних моделей данных Salesforce, следующих данному стандарту.