Постройте логическую модель

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

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 3 из 6 главы Моделирование данных ради смысла, глава 2 курса Data Architect. Каждый модуль самостоятелен. Назад: Нарисуйте связи · Далее: Поместите данные туда, где им место

Вопрос, на который отвечает этот модуль: Как превратить концептуальную модель в логическую модель данных?

Концептуальная модель рассказала нам, что существует в Steve Trucking и как это связано: розничные партнеры и их распределительные центры, манифесты и доставки, получатели, маршруты и остановки, бригады, грузовики и назначения бригад. Этого достаточно для очень продуктивного разговора с бизнесом. Но рано или поздно мне нужно больше деталей. Что нам нужно знать о доставке? Чем один распределительный центр отличается от другого? Как мы определяем получателя? Что относится к назначению бригады, а не к бригаде или грузовику? Эти вопросы ведут нас от концептуальной модели к логической модели данных, и мы все еще не строим Salesforce.

Сидеть, стоять, моделировать

Сначала вернемся к собакам. У нас есть прямоугольники и линии. Теперь два новых вопроса: что мы знаем о каждой вещи и как отличить одну от другой?

Что ее описывает? У собаки есть кличка и дата рождения. У владельца есть имя, номер телефона и адрес. У трюка есть название и сложность. Каждый факт помещается в тот прямоугольник, который он описывает.

Теперь связующая сущность. Насколько хорошо Bella выполняет «Сидеть» и когда она это выучила — описывает ли это Bella? Не совсем: одни трюки у нее получаются лучше, чем другие. Описывает ли это «Сидеть»? Нет: каждая собака выполняет «Сидеть» по-своему. Это описывает Bella и «Сидеть» вместе, поэтому место этому — в Трюке собаки: уровень навыка и дата, когда трюк выучен. Именно поэтому связующая сущность и существует: некоторые факты принадлежат только паре.

Какая собака какая? Попробуем сначала кличку. Собак по кличке Max очень много, так что кличка не уникальна. Номер телефона владельца? У Marcus две собаки на одном телефоне, люди меняют номера, и это чьи-то персональные данные, которые скопируются в каждую систему, которая когда-либо будет ссылаться на собаку. Номер микрочипа выглядит лучше: он уникален и не меняется. Но у нового щенка может еще не быть чипа, а ключ не может быть пустым. Поэтому микрочип остается тем, под чем собаку также знают, а собака получает собственный ID собаки: число, которое делает одну скучную работу — отличает одну собаку от другой.

Click to enlarge

Те же вопросы мы сейчас зададим Steve Trucking, а причины, по которым кличка, телефон и микрочип не подходят, превращаются в правило, которого я придерживаюсь уже много лет.

Концептуальная модель говорит, что существует; логическая — что это значит как данные

Возьмем грузовик. Что мне нужно знать о грузовике? Возможно, его бортовой номер, VIN, марку, модель, год выпуска, госномер, текущий пробег и статус. Это атрибуты грузовика.

Теперь возьмем доставку. Возможно, номер заказа розничного партнера, дату доставки, обещанное окно, фактическое время прибытия, статус и то, включает ли она установку или вывоз старой техники. Опять атрибуты.

Концептуальная модель сказала нам, что доставка существует. Логическая модель начинает говорить, что доставка означает как данные. Простой прямоугольник вроде «Грузовик» или «Доставка» может стоять за целым набором полей.

Click to enlarge

И все же на большинстве наших диаграмм прямоугольники остаются простыми, по трем причинам. Число полей растет. Поля быстро устаревают. А у каждого поля есть детали, которые трудно показать в объектной модели: его API-имя, метка, тип данных и длина. Эти детали обязательно будут зафиксированы, просто не в первой модели данных. Когда показ нескольких ключевых полей действительно помогает рассказать историю, я рисую детальную модель данных: сфокусированный срез только с теми полями, которые важны для мысли.

Атрибуты должны описывать сущность

Вот простой вопрос, который я задаю, глядя на атрибут: что это описывает? Марка грузовика явно описывает грузовик. А имена членов бригады в доставке? Описывают ли они доставку? Или они описывают бригаду, у которой было назначение бригады, которое покрывало маршрут, в который входила эта остановка?

Именно здесь модель данных начинает вскрывать вещи, которые на экране выглядят совершенно разумно. Координатор говорит: «Я хочу видеть имена бригады в доставке». Это законное требование к пользовательскому опыту. Но это не обязательно требование хранить имена бригады в доставке. Это две разные вещи, и мы вернемся к этому при нормализации. А пока выработайте привычку спрашивать, какую вещь на самом деле описывает этот факт. Этот вопрос избавит вас от множества проблем.

Теперь нужно поговорить об уникальных ID

Атрибуты описывают вещи. Но есть еще одна задача: как понять, какая вещь какая?

Двух получателей зовут John Smith. Это один и тот же человек? Может быть, а может быть, и нет. Имени недостаточно. Адрес? Люди переезжают. Номера телефонов меняются. Адреса электронной почты меняются. Даже название розничного партнера может измениться.

Это подводит нас к ключам: тому, что позволяет однозначно определить что-то в нашей модели. За годы у меня сложилось довольно твердое мнение на этот счет. От идентификатора я хочу четырех вещей:

Уникальный. Неизменный. Без смысла. Никогда не PII.

Уникальный. Идентификатор должен указывать ровно на одну вещь. Если у двух доставок может быть одно и то же значение, это ненадежный идентификатор доставки. Имена обычно не уникальны, адреса не обязательно уникальны, а номерами телефонов пользуются совместно. Даже значения, которые выглядят уникальными сегодня, могут перестать быть такими, когда данных станет достаточно много. Поэтому спросите: могут ли у двух таких когда-нибудь совпасть значения? Если ответ «да», будьте очень осторожны, делая это уникальным ID записи.

Неизменный. Это требование часто упускают. Если мы определяем розничного партнера по названию, а партнер переименовался, появился ли у нас новый партнер? Нет. Бизнес-сущность осталась той же; изменился один из ее атрибутов. Уникальный ID записи должен переживать изменения той вещи, которую он определяет, а это исключает имена, адреса электронной почты, номера телефонов, адреса и имена пользователей, какими бы удобными они ни казались, когда мы только строим систему.

Без смысла. Когда слышишь это впервые, звучит странно. Зачем мне идентификатор без смысла? Потому что смысл меняется. Представьте, что кто-то строит ID доставки, в котором закодированы DC, розничный партнер, дата доставки и порядковый номер: PHX-KEY-20261002-0042. Выглядит умно. А потом получатель переносит доставку на пятницу. Меняем идентификатор? Если нет, он нам врет. Если да, мы изменили уникальный ID доставки потому, что изменился один из ее атрибутов, и каждая система, сохранившая старый ID, только что ее потеряла. Идентификатор пытался делать две работы: определять доставку и описывать ее. Я предпочитаю, чтобы описывали атрибуты, а идентификатор делал одну скучную работу: определял. Скучные идентификаторы — хорошие идентификаторы.

Никогда не PII. Это настолько важно, что я выделяю это отдельно. Не используйте персональные данные (PII) как идентификатор только потому, что они выглядят уникальными. В Steve Trucking соблазнительно узнавать получателя по номеру телефона. Но ключ копируется везде, где системам нужно связывать записи: в интеграции, выгрузки, журналы, файлы статусов, которые уходят обратно розничным партнерам, хранилище данных, тестовые данные. Сделайте номер телефона ключом — и вы разнесете персональные данные получателя по всей архитектуре.

Кроме того, ключ должен быть у каждой записи: никогда не null и не пустой. Если некоторые люди не захотят или не обязаны давать вам какое-то значение, это значение не может быть ключом. Поэтому системы выдают собственные внутренние идентификаторы, а персональные данные, если они вообще нужны, становятся защищенным атрибутом.

Итак, мое правило: уникальный, неизменный, без смысла, никогда не PII.

Естественные и суррогатные ключи

У специалистов по базам данных для этого есть названия. Естественный ключ уже существует в бизнес-данных: VIN грузовика — хороший пример. Его придумало не наше приложение, и у него уже есть смысл. Суррогатный ключ создается специально, чтобы определять запись; он ничего не описывает, он только определяет.

В большинстве архитектур я предпочитаю суррогатный ключ в качестве внутреннего ID записи, а важные естественные идентификаторы держу как атрибуты. Это не делает естественные идентификаторы плохими; часто они чрезвычайно важны. Просто я не делаю их автоматически уникальным ID записи. Спросите, что произойдет, если значение исправят, переформатируют, заменят, используют повторно, если его не окажется или если оно придет из нескольких систем-источников. Вот где простое на вид решение становится архитектурным.

У одной вещи может быть несколько полезных идентификаторов

Внутренний ID записи — не обязательно тот идентификатор, которым пользуются все остальные системы. Внутри Steve Trucking доставка может определяться сгенерированным ID. Каждый розничный партнер знает ту же доставку по собственному номеру заказа: Keystone — в своем CSV-манифесте, Redrock — в своем API, Brightwave — в своих EDI-сообщениях. А восемь лет истории в RouteDesk, старом инструменте диспетчеризации, используют собственные ID доставок RouteDesk.

Эти идентификаторы важны. Нам нужно хранить их и правильно сопоставлять, потому что обновление статуса должно уходить каждому партнеру под его номером. Но им не обязательно всем становиться уникальным ID доставки. На вопрос «какой у нее ID?» может быть больше одного ответа, и архитектор должен знать, какой ID авторитетен в каком контексте. Мы вернемся к этому, когда будем говорить о мастер-данных и интеграции.

Связи зависят от уникальных ID

Теперь вернитесь к линиям, которые мы нарисовали. Манифест перечисляет доставки. Получатель получает доставки. У бригады есть назначения бригады. Эти связи работают только потому, что мы можем надежно определить вещи на обоих концах.

Вот где это больно бьет по Steve Trucking. Розничный партнер правит манифест в тот же день: заказ отменен, позиция заменена, новый адрес. Если мы не можем сопоставить исправленную строку с уже существующей доставкой по номеру заказа партнера, мы создаем вторую доставку того же холодильника, и бригада может приехать дважды. Прямоугольники, атрибуты, ключи и связи — это не отдельные идеи. Это части одной модели.

Click to enlarge

Здесь вы, возможно, думаете: «Salesforce дает ID каждой записи». Верно, и мы до этого дойдем. Если данные живут в Salesforce, каждая запись получает ID, сгенерированный Salesforce. Он загадочный и плохо читается, поэтому обычно мы дополнительно показываем поле ID, которым могут пользоваться люди, например номер доставки D-000184227 — поле Auto Number. Люди часто думают, что этот номер и есть ID записи, но это не так: ID Salesforce по-прежнему лежит под ним. У внешней системы или базы данных, Oracle или SQL Server, тоже есть свои уникальные ID. Но со временем в архитектуру могут войти Salesforce, финансовая ERP, Snowflake, Data 360, системы партнеров и системы, которых еще не существует. Логическая модель описывает бизнес-данные, не ставя каждое решение в зависимость от одной технологии. Как Salesforce физически это реализует — следующий шаг.

Что здесь решает архитектор

Превращая концептуальную модель в логическую, я решаю:

• Какие атрибуты действительно описывают каждую сущность.
• Как однозначно определяется каждая сущность и достаточно ли стабилен этот идентификатор, чтобы быть ее уникальным ID.
• Какие бизнес-идентификаторы (номера заказов партнеров, ID из старых систем) нужно хранить и сопоставлять.
• Не используется ли конфиденциальная информация как ключ.
• Соединяют ли связи сущности через надежные уникальные ID.

Теперь у нас есть сущности, связи, атрибуты и уникальные ID: начало настоящей логической модели данных. Но проблема все еще есть. Очень легко положить совершенно корректные данные не в то место. Здесь и появляется нормализация.

Дополнительно

• Custom Field Types (opens in a new tab), Salesforce Help (на английском, проверено 2026-10-09): Auto Number присваивает каждой записи уникальный номер в заданном формате отображения, например с префиксом и ведущими нулями; это не ID записи в Salesforce. См. также Auto-Number Fields Are Not Always Sequential (opens in a new tab) (на английском, проверено 2026-10-09).