Контрольная точка 1. Нарисуйте и защитите дизайн данных Steve Trucking

Также доступно на 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)

Оригинальная практика на основе сценария. Она никогда не строится по образцу настоящих экзаменационных вопросов. Она написана в стиле «Как бы я это спроектировал»: смысл в том, чтобы сделать видимым ваше суждение, а не выбрать букву. Это задание завершает часть 1 курса Data Architect; мой разбор — в контрольной точке 1, поэтому сначала попробуйте сами.

Сценарий

Steve Trucking — компания доставки «последней мили». Крупные розничные сети — розничные партнеры (Retail Partners) — продают бытовую технику, телевизоры и мебель; бригады Steve Trucking из двух человек доставляют их покупателям розничных партнеров (получателям, Recipients), часть товаров устанавливают, а старые вывозят. Прочитайте описание Steve Trucking, разделы 1–8. Раздел 9 (поздние изменения) пока не трогайте; до него дойдет очередь в конце курса.

Требования

Все из раздела 5 описания (R1–R15) и раздела 6 (S1–S5). Те, на которые эта контрольная точка опирается больше всего:

R1. Принимать манифесты каждого розничного партнера в его собственном формате (файл по SFTP, API, EDI) и превращать их в маршруты, остановки и позиции без ручного перенабора.
R3. Менеджеры распределительных центров (DC) каждого розничного партнера видят на портале свои доставки, исключения, фотографии и претензии — и никогда не видят данных другого партнера.
R4. Манифесты пересматриваются в день доставки; изменения после построения маршрутов должны обрабатываться.
S2. Розничный партнер никогда не должен видеть доставки, цены, объемы или получателей другого партнера.
S3. Ссылка для отслеживания у получателя показывает только эту одну доставку, без учетной записи, и имеет срок действия.
S4. Адреса, телефоны получателей и примечания к доставке — персональные данные; бригады видят их только для своих остановок и только в день доставки.

Ограничения

Около 3 300 доставок в рабочий день, миллион в год, рост 30 % в год; в среднем около 1,6 позиции и восемь смен статуса на доставку; четыре-пять миллионов фотографий в год; около 200 000 GPS-отметок в день.
Один org Salesforce в США, где уже работают Service Cloud, Field Service и партнерский портал; MuleSoft лицензирован; Data 360 лицензирован, но не внедрен.
Три розничных партнера, три стиля интеграции; девять распределительных центров.

Ваша задача

Нарисуйте и защитите дизайн части 1. Используйте то, что вы узнали в главах 1–6:

Ландшафт (глава 4): нарисуйте текущее состояние системного ландшафта Steve Trucking в раскладке Steve, подписав каждую стрелку: что передается и как.
Модель (глава 2): смоделируйте домен доставок сначала концептуально, затем логически. Розничные партнеры, распределительные центры, манифесты, доставки, позиции, маршруты, грузовики, бригады, чек-листы установки, фотографии, подписи, исключения и получатели. (Задание D1.)
Физический дизайн (глава 3): что из этого — стандартные объекты (в Field Service есть рабочие заказы, сервисные встречи, сервисные ресурсы и сервисные территории), а что — пользовательские? Какие лицензии нужны партнерским пользователям и получателям? Где живет каждый вид данных: в org, вне ядра, в хранилище данных?
Ключ (эта глава): какой ключ сопоставляет строку заказа розничного партнера с вашей доставкой и что происходит, когда манифест пересматривают после построения маршрутов? (Задание D3.)
Получатель (эта глава): контакт, персональная учетная запись (Person Account) или ни то ни другое? Обоснуйте выбор через отношения, объем, изоляцию партнеров и жизненный цикл данных.
Унифицировать или нет (эта глава): получатели появляются в манифестах нескольких партнеров, иногда больше одного раза в год. Вы бы их унифицировали или сознательно не стали бы? В чем риск с учетом S2? (Задание DC1, без поздних изменений.)
Полномочия: для пяти ключевых полей (номер заказа у партнера, статус доставки, телефон получателя, окно доставки, юридическое название партнера) скажите, кто его создает, кто им владеет, какая система авторитетна и кто может его менять.

Запишите каждое решение в виде двух вариантов, а затем своего выбора: «по моему профессиональному мнению…»

Обсуждение

Мой разбор — Контрольная точка 1. Steve Trucking: как бы я это спроектировал. Сравнивайте рассуждения, а не только прямоугольники. Там, где вы выбрали иначе, можете ли вы сказать, что выиграете и чем пожертвуете?

Ревью дизайна

Пока отложите свой дизайн. Часть 2 проверит его на объем, запросы, интеграцию, миграцию, транзакции и безопасность, а карточка ревью в главе 18 проверит его на третьем году работы.

Отработанные цели экзамена

DM-1, DM-2 (проектирование модели данных; модель учитывает общий доступ)
MDM-1, MDM-2, MDM-3, MDM-4 (мастеринг, полномочия, сопоставление, прослеживаемость)
SDM-1 (лицензии), SDM-3 (единое представление и когда его не строить)