Моделирование данных ради смысла
Также доступно на 28 языках
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 · Español (México) · Français (Canada) · Deutsch (Schweiz)
Учебное пособие к главе 2 курса Data Architect. Сначала прочитайте шесть модулей; эта страница поможет проверить, что запомнилось.
Об этом учебном пособии. Оно построено только на собственных материалах этого курса и на списке целей из опубликованного руководства Salesforce по экзамену. Оно никогда не основано на настоящих экзаменационных вопросах и не претендует на знание того, что будет на экзамене. Если вы сдавали экзамен, пожалуйста, не присылайте мне вопросы из него: сертификационное соглашение запрещает ими делиться, да и заучивание ответов — неправильный путь к тому, чтобы стать архитектором.
Эта глава — основа для раздела экзамена Data Modeling and Database Design (моделирование данных и проектирование баз данных), на который приходится четверть экзамена. Она охватывает мышление; следующая глава, Архитектура данных Salesforce, — то, как это строит платформа. Поэтому для большей части того, что проверяется по объектам, полям и связям, нужны обе главы.
Для экзамена
Заголовок раздела «Для экзамена »Пункты этой главы, которые с наибольшей вероятностью важны на экзамене. Каждый привязан к своей экзаменационной цели и ведет туда, где он объясняется. Отмечайте их по мере продвижения.
DM-1: сравнение техник проектирования модели данных Salesforce
- Я могу объяснить разницу между концептуальной, логической и физической моделью данных и для чего нужна каждая. (Воплотите модель в Salesforce)
- Я могу найти сущности-кандидаты в требовании и отличить человека, выполняющего работу, от части данных. (Существительные дают сущности-кандидаты)
- Я могу читать и рисовать нотацию «воронья лапка» (crow’s foot): один, много и вторую отметку для необязательной или обязательной связи. (Читайте линии, Обязательность тоже важна)
- Я могу назвать кардинальность связи: «один к одному», «один ко многим», «многие ко многим». (Спросите: «Один или много?»)
- Я знаю, что связь «многие ко многим» становится самостоятельной сущностью, а в Salesforce обычно связующим объектом (junction object) с двумя родителями. (Связи могут становиться вещами)
- Я знаю, когда связи нужна история (запись с датами начала и окончания), а не поле, которое перезаписывается. (Время меняет связи)
- Я могу выбрать хороший уникальный ID и знаю, почему естественный ключ или что-либо с персональными данными — рискованный выбор. (Теперь нужно поговорить об уникальных ID)
- Я знаю разницу между естественным ключом и суррогатным ключом и то, что одна запись может нести несколько внешних идентификаторов. (Естественные и суррогатные ключи)
- Я знаю, что поле Auto Number — это удобочитаемый номер, а не ID записи в Salesforce. (Связи зависят от уникальных ID)
- Я могу применить первую, вторую и третью нормальные формы и заметить поле, которое содержит несколько значений или повторяет факт о чем-то другом. (Простой способ думать о 1НФ, 2НФ и 3НФ)
- Я могу объяснить, когда намеренно денормализовать (пользователи, отчетность, масштаб) и чего это стоит. (Проектируйте до третьей нормальной формы, затем отступите)
- Я могу выбрать между списком выбора и lookup на объект для списка значений. (Lookup или список выбора?)
- Я знаю, что пользовательский тип отчета допускает не больше четырех связей между объектами, и почему это важно для глубоких моделей. (Lookup или список выбора?)
- Я знаю, когда подходит master-detail (дочернюю запись никогда не переподчиняют), а когда безопаснее lookup, включая рекомендацию Salesforce иметь не больше 10 000 дочерних записей у одного родителя. (Связи становятся решениями платформы)
- Я знаю, почему стоит избегать полиморфных связей, где это возможно. (Связи становятся решениями платформы)
- Я знаю, что бизнес-сущность не означает автоматически пользовательский объект: это может быть стандартный объект, поле, конфигурация или данные, которые живут вне Salesforce. (Бизнес-сущность не означает автоматически пользовательский объект)
За пределами экзамена
Заголовок раздела «За пределами экзамена »Экзамен — это пол, а не потолок. Это привычки из этой главы, которые нужны архитектору, независимо от того, спросят ли о них когда-нибудь на экзамене.
- На минуту забудьте о Salesforce. Смоделируйте бизнес, прежде чем сопоставлять его с организацией и контактом.
- Прислушивайтесь к слову, за которым прячутся две вещи. В Steve Trucking «клиент» был и розничным партнером, и получателем.
- Модель — часть разговора. Ваша первая модель не обязана быть правильной; она нужна, чтобы показать вам, где вы ошибаетесь.
- Давайте линиям имена. Две модели с одинаковыми прямоугольниками могут означать разное.
- Спрашивайте «сейчас или во времени?» о каждой связи.
- Уникальный, неизменный, без смысла, никогда не PII.
- Поместите факт туда, где ему место, затем отступайте намеренно и записывайте почему.
- Денормализация не убирает сложность, а перемещает ее. Знайте, кому принадлежит истина.
- Один источник истины, много форм: экраны, отчеты, хранилище данных и ИИ.
- Не проектируйте из Setup. Нарисуйте модель, прежде чем нажать New Custom Object.
- Прослеживайте каждое физическое решение назад к тому, что нужно бизнесу.
Ключевые термины
Заголовок раздела «Ключевые термины »| Термин | В одной строке |
|---|---|
| Сущность | Вещь, которая важна бизнесу и о которой он хранит данные |
| Сущность-кандидат | Существительное, которое может стать сущностью, после того как вы о нем спросили |
| Атрибут | Факт, который описывает сущность |
| Связь | То, как соединены две сущности, названное языком бизнеса |
| Кардинальность | Сколько одних связано со сколькими другими |
| Обязательность | Обязательна ли связь или может быть нулевой |
| «Воронья лапка» | Отметка «много» на конце линии |
| Связующий объект (junction object) | Способ Salesforce построить связь «многие ко многим»: дочерний объект обоих родителей |
| Концептуальная модель | Что существует в бизнесе и как это связано; без Salesforce |
| Логическая модель | Данные: атрибуты, уникальные ID и связи, все еще без привязки к платформе |
| Физическая модель | Как это построит платформа: объекты, поля и типы связей |
| Естественный ключ | Идентификатор, который уже существует в бизнесе, например VIN грузовика |
| Суррогатный ключ | Идентификатор, созданный только для того, чтобы определять запись |
| Внешний идентификатор | ID той же записи в другой системе, который хранят и сопоставляют |
| Нормализация (1НФ, 2НФ, 3НФ) | Размещение каждого факта там, где ему место: одно значение в поле, факты обо всем ключе, никаких фактов о других фактах |
| Денормализация | Намеренное копирование или уплощение данных по причине, которую можно назвать |
| Аномалия обновления | Один и тот же факт хранится во многих местах, поэтому после одного изменения часть копий оказывается неверной |
Проверьте себя
Заголовок раздела «Проверьте себя »Короткие сценарии в стиле курса. Определитесь с ответом, прежде чем открывать его.
1. Бизнес говорит вам, что бригада водит грузовик. Через шесть недель кто-то спрашивает, какая бригада была на грузовике 117 в определенный день. Что должно было быть в модели?
Назначение бригады: связь между бригадой и грузовиком как отдельная запись с датой начала, датой окончания и маршрутом. Во времени бригады и грузовики связаны «многие ко многим», и бизнесу важна история. Поле в грузовике было бы перезаписано. Перечитайте Время меняет связи.
2. Команда предлагает использовать номер телефона каждого получателя как уникальный ID, «потому что он уникален». Что вы скажете?
Он не проходит проверки: номера телефонов меняются и бывают общими, так что он не неизменный и не надежно уникальный, а еще это персональные данные, которые скопируются в каждую систему, связанную с записью. Используйте сгенерированный ID без смысла, а номер телефона держите как атрибут. Перечитайте Теперь нужно поговорить об уникальных ID.
3. У доставки есть поля «Позиция 1», «Позиция 2» и «Позиция 3». Приходит доставка с четырьмя позициями. В чем настоящая проблема и как ее исправить?
Модель спрятала повторяющуюся структуру внутри полей (проблема первой нормальной формы). Исправление — не поле «Позиция 4», а сущность позиция доставки, дочерняя для доставки, так что каждая позиция — это запись. Перечитайте Первая нормальная форма.
4. Каждая доставка хранит имя руководителя распределительного центра. Руководитель меняется. Что пошло не так?
Факт о другой вещи (распределительном центре) хранился в доставке: это проблема третьей нормальной формы, а теперь еще и аномалия обновления в сотнях записей. Руководителю место у распределительного центра; доставка ссылается на распределительный центр. Перечитайте Третья нормальная форма.
5. Виду остановки (только доставка, с установкой, с вывозом старой техники) нужны длительность, навыки бригады и чек-лист. Список выбора или объект?
Объект. У него больше одного столбца информации, им управляет бизнес, и он меняется по собственному графику. Статус доставки — короткий стабильный список меток — остается списком выбора. Перечитайте Lookup или список выбора?.
6. Партнеры хотят оценочную карту своевременности по регионам, а регион хранится в распределительном центре. Вы копируете регион в каждую доставку. Что вы должны решить?
Кому принадлежит истина, как копия остается синхронизированной и должны ли старые доставки сохранять регион, который был верен в момент доставки, или следовать за распределительным центром, если он переедет. Денормализация переместила сложность, а не убрала ее. Перечитайте Иногда побеждает отчетность.
7. Трюк вроде «Сидеть» может быть связан с сотнями тысяч питомцев. Master-detail или lookup от Трюка питомца к Трюку?
Lookup. Рекомендация Salesforce — не больше 10 000 дочерних записей у одного родителя, и популярный трюк ее превысит. Master-detail подходит для связи Трюка питомца с Питомцем, потому что трюк питомца никогда не переподчиняют и один питомец знает лишь несколько трюков; к тому же именно это позволяет питомцу сводить счетчик «Освоенные трюки». Перечитайте Сидеть, стоять, моделировать.
Дополнительно
Заголовок раздела «Дополнительно »- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (на английском, проверено 2026-09-25): официальный список целей и их весов. Всегда проверяйте актуальную версию, прежде чем записываться на экзамен.