База данных, объекты в базе данных и связи между ними - это не чисто сейлсфорсовые понятия, это все "общепрограммистское" и разработчику нужно разбираться что к чему.
Связи в БД образуются за счет ссылочных полей (в SF в основном это Lookup Relationship и Master-Detail Relationship, есть более детальная статья про другие типы ссылочных полей)
Relationship - это связь между объектами.
Связи бывают:
Начнем с самого понятного и часто используемого - это один ко многим, он же one to many
Если вы уже проходили трейлхед или просто что-то клацали, то знаете что в SF есть такие объекты как Account и Contact.
Представим что Аккаунт - это компания-партнер, Контакт - это контакты людей с этой компании. Получается что Аккаунт один, а контактов у него много.
Если мы возьмем другой аккаунт - то у него будут другие контакты.
Эту связь можно рассматривать и наоборот, как many to one, то есть много контактов относятся к одному аккаунту. А как же они относятся?
На объекте Контакт есть поле-лукап на Аккаунт. Получается, что на многих контактах мы можем указать один и тот же аккаунт. За счет этого и образуется связь one to many, когда много записей могут ссылаться на одну и ту же запись.
Если бы на Аккаунте было поле-лукап на Контакт, то у нас получилось бы что аккаунт связан только с одним контактом и все. А это совсем не то, что нужно.
Что бы образовалась связь one to many нужно на объекте, которого должно быть “много” создать поле-ссылку на объект, который должен быть один.
Очень важно разобраться кого должно быть много, а кто один.
Представляем маму и детей. Мама одна, у одной и той же мамы может быть много детей, но у каждого ребенка может быть только одна мама. Даже если будет много мам - то у каждой из них будут свои дети, и у каждого ребенка будет только одна мама. Эта аналогия подходит ко всему, кто один - тот родитель (мама), кого много - это дети, то есть чайлды или дочерние.
Теперь рассмотрим многие ко многим, которое many to many
Представим что какая-то компания периодически проводит какие-то мероприятия с целью привлечения Лидов (потенциальных клиентов). Мероприятий может быть много, на каждое из этих мероприятий может прийти много лидов. И каждый лид может прийти на несколько меропприятий.
Если мы сделаем на Лиде поле-лукап на Ивент, получится что на один ивент может прийти много лидов. Но один лид сможет прийти только на один ивент, указанный в поле А надо что бы он мог прийти на несколько мероприятий.
И если мы на ивенте сделаем лукап на лида - получится что один и тот же лид сможет прийти на разные ивенты, но вот на ивент прийдет только один лид и все.
В данном случае нам нужен связывающий объект, за счет которого и образовывается связь много ко многим.
Мы создаем еще один объект, назовем его Participation, и добавим на него два поля - лукап на лида и лукап на ивент.
Получается, что с одним ивентом будет связано много партисипейшенов(если лукап на партисипейшене, значит мы можем создать много партисипейшенов, указать один и тот же ивент), и так как каждый из этих партисипейшенов связан еще и с лидом - то с одним ивентом будет связано много лидов.
И в то же время, с одним лидом может быть связано много партисипейшенов (лукап на партисипейшене, значит мы можем создать много партисипейшенов, указать одного и того же лида), каждый из которых связан с ивентом, так что лид будет связан с несколькими ивентами.
Точно так же будет образовываться связь, если в университете на одном факультете учится много студентов, и один студент может учиться на нескольких факультетах.
Так само когда вы лайкаете фотки с соц сетях, каждый пост может лайкнуть много людей, каждый человек может лайкнуть много постов, каждый лайк - это запись в БД, которая связывается с постом и юзером.
В некоторых источниках говорится, что для связи мени-ту-мени в сейлсфорсе нужно использовать мастер-дитейл, но на практике из-за такой связи могут быть проблемы с доступом, так как родительским и дочерним записям не всегда нужен именно тот доступ, который получится при мастер-дитейл. Поэтому, когда нет необходимости именно в мастер-дитейл - делают лукап.
Если рассматривать, например, лайк в соц сетях - то он получается самостоятельным объектом со своим функционалом, а не просто связывающим объектом между юзером и постом. И чаще всего задачи именно такие - связать два объекта через мени-ту-мени, и чтобы при этом на самом связывающем объекте было еще куча функционала (мени-ту-мени, который связывался бы через мастер-дитейл, подошел бы только в том случае, когда кроме связывания объектов больше никакого функционала нет, необходимость в такой строгой связи бывает редко)
Статья про доступ, в частности и про доступ к дочерним рекордам при Master-Detail Relationship.
И наконец один к одному, one to one
Представим что в компании есть сотрудники, они занимают какие то должности, имеют подчиненных и/или руководителей, выполняют какие то обязанности, еще и имеют какой то рейтинг внутри компании. Все это хранится с полях объекта Сотрудник (Employee)
И помимо данных, относящихся именно к его работе, нужно хранитиь еще его личные данные, может даже паспортные.
Можно на объекте Employee создать дополнительные поля для этих данных, но это будет не очень удобно - придется смотреть на кучу лишней информации, да и с доступом могут быть проблемы - если кому то нужны только паспортные данные, то придется давать доступ ко всему объекту, а вместе с этим и к некоторым полям, к которым давать доступ нельзя (статья про доступ, и про поля, к которым нельзя этот доступ ограничить)
Поэтому, паспортные данные нужно вынести в отдельный объект Passport, и когда кому то нужен доступ к паспортным данным - то уже не надо давать доступ к целому Employee. Тут может быть на Employee поле-лукап на Passport, или наоборот, на паспорте лукап на сотрудника, надо смотреть как удобнее (какой объект будет основной? основной - это сотрудник и его должностные особенности, а паспорт его дополняет? или основной объект именно паспорт, а все остальное его дополняет? смотреть по бизнес-логике, может быть любой вариант
Если у нас на Employee поле-лукап на паспорт, то, исходя из данных про one to many, мы можем создать еще одного Employee и указать на нем тот же паспорт. Это будет противоречить связи один к одному, да и здравому смыслу тоже, поэтому, при такой связи добавляют ограничения, что бы нельзя было на двух сотрудников один паспорт завести.
Так само может быть, если сотруднику выдают в пользование компьютер, один работник - один компьютер, но характеристики (то есть поля) у работника и у компьютера совсем разные, поэтому лучше разделить.
Или медицинская компания может хранить данные мед-карт своих клиентов, но при этом не каждый клиент разрешил такую информацию хранить, поэтому поле с мед-картой будет просто пустым.
Еще такая связь может быть в том случае, когда надо Salesforce Object связать с External Object с другой системы. Тут тоже будет один к одному, так как один рекорд в сф соответствует одному рекорду другой системы.
Так же важно понимать, что не всегда будут нужны именно такие связи, иногда проще создать несколько полей, чем целый объект.
Пока это все, периодически буду дополнять)
Ставьте лайки, пишите комментарии 
