Перейти до вмісту
SteveTechArcSteveTechArc Courses

Побудуйте логічну модель

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

Five different dog collars on pegs by a home's front door, each with its own blank metal tag, beside a leash, a brush and a water bowl.
Зображення згенеровано ШІ

Модуль 3 з 6 розділу Моделювання даних заради змісту, розділ 2 курсу Data Architect. Кожен модуль самостійний. Попередній: Намалюйте зв’язки · Наступний: Розмістіть дані там, де їм місце

Питання, на яке відповідає цей модуль: Як перетворити концептуальну модель на логічну модель даних?

Концептуальна модель сказала нам, що існує в Steve Trucking і як воно пов’язане: роздрібні партнери та їхні розподільчі центри, маніфести й доставки, отримувачі, маршрути й зупинки, бригади, вантажівки й призначення бригад. Цього достатньо для дуже продуктивної розмови з бізнесом. Але зрештою мені потрібно більше деталей. Що нам треба знати про доставку? Чим один розподільчий центр відрізняється від іншого? Як ідентифікувати отримувача? Що належить до призначення бригади, а не до бригади чи вантажівки? Ці запитання ведуть нас від концептуальної моделі до логічної моделі даних, і ми все ще не будуємо Salesforce.

Сидіти, чекати, моделювати

Section titled “Сидіти, чекати, моделювати ”

Спершу повернімося до собак. У нас є прямокутники й лінії. Тепер два нові запитання: що ми знаємо про кожну річ і як відрізнити одну від іншої?

Що її описує? У собаки є кличка і дата народження. У власника — ім’я, номер телефону й адреса. У трюку — назва і складність. Кожен факт іде на той прямокутник, який він описує.

Потім об’єкт-з’єднувач. Наскільки добре Bella виконує «Сидіти» і коли вона цього навчилася: це описує Bella? Не зовсім; одні трюки вона виконує краще за інші. Це описує «Сидіти»? Ні; кожна собака виконує «Сидіти» по-своєму. Це описує Bella і «Сидіти» разом, тож належить до Трюку собаки: рівень навички і дата навчання. Ось навіщо існує з’єднувач: деякі факти належать лише парі.

Яка собака яка? Спершу спробуйте кличку. Собак на ім’я Max дуже багато, тож кличка не унікальна. Телефон власника? У Marcus дві собаки на одному номері, люди змінюють номери, і це чиїсь персональні дані, які копіювалися б у кожну систему, що колись посилається на собаку. Номер мікрочипа виглядає краще: він унікальний і не змінюється. Але нове цуценя може ще не мати чипа, а ключ не може бути порожнім. Тож мікрочип лишається як те, під чим собака також відома, а собака отримує власний ID собаки: номер, що виконує одну нудну роботу — відрізняє одну собаку від іншої.

Модель собак із ключами та атрибутами Модель собак як детальна модель даних. Кожен прямокутник має свій ID запису і кілька полів. Власник: ID власника, ім’я, телефон, поштовий індекс, місто. Заводчик: ID заводчика, ім’я, місто. Собака: ID собаки, також відома за номером мікрочипа, ID власника і ID заводчика, кличка, дата народження. Порода, ще не пов’язана: ID породи, назва, розмір. Трюк: ID трюку, назва, складність. Трюк собаки, між Собакою і Трюком: ID трюку собаки, ID собаки та ID трюку, рівень навички, дата навчання. Оцінка трюку, під Трюком собаки: її ID, ID трюку собаки, дата, рівень навички, хто оцінив. Лінії ті самі, що й раніше: Власник володіє Собаками, Заводчик розводить Собак (Собака має нуль або одного Заводчика), Собака знає Трюки собаки, Трюк відомий у Трюках собаки, а Трюк собаки перевіряється в Оцінках трюку. володіє розводить знає відомий у перевіряється в Власник ID власника ID ЗАПИСУ Ім’я Телефон ZIP Місто Заводчик ID заводчика ID ЗАПИСУ Ім’я Місто Собака ID собаки ID ЗАПИСУ Номер мікрочипа ТАКОЖ ВІДОМИЙ ЯК ID власника ID заводчика Кличка Дата народження Порода ID породи ID ЗАПИСУ Назва Розмір Трюк собаки ID трюку собаки ID ЗАПИСУ ID собаки ID трюку Рівень навички Дата навчання Трюк ID трюку ID ЗАПИСУ Назва Складність Оцінка трюку ID оцінки трюку ID ЗАПИСУ ID трюку собаки Дата Рівень навички Хто оцінив рівно один нуль або один один або багато нуль або багато © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Це ті самі запитання, які ми зараз поставимо Steve Trucking, а причини, з яких кличка, телефон і мікрочип не годяться, складаються в правило, якого я дотримуюся роками.

Концептуальна модель каже, що існує; логічна — що це означає як дані

Section titled “Концептуальна модель каже, що існує; логічна — що це означає як дані ”

Візьміть Вантажівку. Що мені треба знати про вантажівку? Можливо, її бортовий номер, VIN, марку, модель, рік випуску, номерний знак, поточний пробіг і статус. Це атрибути Вантажівки.

Тепер візьміть Доставку. Можливо, номер замовлення роздрібного партнера, дату доставки, обіцяне вікно, фактичний час прибуття, статус і чи входить у неї встановлення або вивезення старого. Знову атрибути.

Концептуальна модель сказала нам, що Доставка існує. Логічна модель починає казати, що доставка означає як дані. Простий прямокутник на кшталт Вантажівки чи Доставки може позначати цілий набір полів.

Від прямокутників до сутностей з атрибутами Три концептуальні прямокутники ліворуч (Вантажівка, Доставка, Розподільчий центр), кожен з’єднаний лінією «стає» з логічною сутністю праворуч, де перелічено її атрибути. Вантажівка: бортовий номер, VIN, марка, модель, рік випуску, номерний знак, поточний пробіг, статус. Доставка: номер замовлення партнера, дата доставки, обіцяне вікно, фактичне прибуття, статус, зі встановленням, з вивезенням старого. Розподільчий центр: назва, адреса, ринок, телефон. КОНЦЕПТУАЛЬНА: ЩО ІСНУЄ ЛОГІЧНА: ЩО ЦЕ ОЗНАЧАЄ ЯК ДАНІ стає стає стає Вантажівка транспортний засіб Вантажівка Бортовий номер VIN Марка Модель Рік випуску Номерний знак Поточний пробіг Статус Доставка одне замовлення одному отримувачу Доставка Номер замовлення партнера Дата доставки Обіцяне вікно Фактичне прибуття Статус Зі встановленням З вивезенням старого Розподільчий центр звідки виїжджають доставки Розподільчий центр Назва Адреса Ринок Телефон Більшість наших діаграм лишає простий прямокутник: поля множаться, застарівають і несуть деталі (API-ім’я, мітка, тип, довжина). © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Попри це, на більшості наших діаграм прямокутники лишаються простими — з трьох причин. Кількість полів зростає. Поля швидко застарівають. І кожне поле має деталі, які важко показати в об’єктній моделі: API-ім’я, мітку, тип даних і довжину. Ці деталі неодмінно зафіксують, просто не в першій моделі даних. Коли показ кількох ключових полів справді допомагає розповісти історію, я малюю детальну модель даних: сфокусований зріз лише з тими полями, що важливі для цього моменту.

Атрибути мають описувати сутність

Section titled “Атрибути мають описувати сутність ”

Ось просте запитання, яке я ставлю, дивлячись на атрибут: що це описує? Марка вантажівки явно описує вантажівку. А імена членів бригади на доставці? Вони описують доставку? Чи бригаду, яка мала призначення, що покривало маршрут, до якого входила ця зупинка?

Саме тут модель даних починає викривати речі, що на екрані виглядають цілком розумно. Координатор каже: «Я хочу бачити імена бригади на доставці». Це обґрунтована вимога до користувацького досвіду. Але це не обов’язково вимога зберігати імена бригади на доставці. Це дві різні речі, і ми повернемося до цього з нормалізацією. Поки що звикайте питати, яку саме річ описує цей факт. Це запитання вбереже вас від багатьох проблем.

Далі треба поговорити про унікальні ID

Section titled “Далі треба поговорити про унікальні ID ”

Атрибути описують речі. Але є ще одна задача: як мені знати, яка річ яка?

Двох отримувачів звуть John Smith. Це та сама людина? Можливо; а можливо, ні. Імені недостатньо. Адреса? Люди переїжджають. Номери телефонів змінюються. Адреси електронної пошти змінюються. Навіть назва роздрібного партнера може змінитися.

Це підводить нас до ключів: того, що дає змогу унікально ідентифікувати щось у моделі. Це сфера, де за роки в мене склалася досить тверда думка. Від ідентифікатора я хочу чотирьох речей:

Унікальний. Незмінний. Без змісту. Ніколи не персональні дані.

Унікальний. Ідентифікатор має ідентифікувати рівно одну річ. Якщо дві доставки можуть мати однакове значення, це ненадійний ідентифікатор доставки. Імена зазвичай не унікальні, адреси не обов’язково унікальні, а номерами телефонів діляться. Навіть значення, що здаються унікальними сьогодні, можуть такими не бути, коли даних стане достатньо. Тож питайте: чи можуть дві такі речі колись мати однакове значення? Якщо так, будьте дуже обережні з використанням його як унікального ID запису.

Незмінний. Цей пункт часто пропускають. Якщо ми ідентифікуємо роздрібного партнера за назвою, а партнер перейменовується, чи з’явився в нас новий партнер? Ні. Бізнес-сутність лишилася тією самою; змінився один з її атрибутів. Унікальний ID запису має переживати зміни речі, яку він ідентифікує, а це виключає імена, адреси електронної пошти, номери телефонів, адреси й імена користувачів, хоч би якими зручними вони здавалися, коли ми тільки будуємо систему.

Без змісту. Почувши це вперше, ви здивуєтеся. Навіщо мені ідентифікатор без змісту? Бо зміст змінюється. Уявіть, що хтось будує ID доставки, який кодує DC, роздрібного партнера, дату доставки і порядковий номер: PHX-KEY-20261002-0042. Виглядає кмітливо. А потім отримувач переносить доставку на п’ятницю. Ми змінюємо ідентифікатор? Якщо ні, він нам бреше. Якщо так, ми змінили унікальний ID доставки, бо змінився один з її атрибутів, і кожна система, що зберегла старий ID, щойно її загубила. Ідентифікатор намагався виконувати дві роботи: ідентифікувати доставку і описувати її. Я волію, щоб доставку описували атрибути, а ідентифікатор виконував одну нудну роботу: ідентифікував її. Нудні ідентифікатори — добрі ідентифікатори.

Ніколи не персональні дані. Цей пункт настільки важливий, що я тримаю його окремо. Не використовуйте персональні дані як ідентифікатор лише тому, що вони здаються унікальними. У Steve Trucking спокусливо впізнавати отримувача за номером телефону. Але ключ копіюється всюди, де системам треба пов’язати записи: інтеграції, експорти, журнали, файли статусів назад до роздрібних партнерів, сховище даних, тестові дані. Зробіть номер телефону ключем — і ви розповсюдили персональні дані отримувача по всій архітектурі.

Ключ також має бути в кожному записі: ніколи не null і не порожній. Якщо деякі люди не дадуть вам значення або не повинні його давати, це значення не може бути ключем. Тому системи видають власні внутрішні ідентифікатори, а персональні дані, якщо вони взагалі потрібні, стають захищеним атрибутом.

Тож моє правило: унікальний, незмінний, без змісту, ніколи не персональні дані.

Природні й сурогатні ключі

Section titled “Природні й сурогатні ключі ”

У людей із баз даних є назви для частини цього. Природний ключ уже існує в бізнес-даних: VIN вантажівки — добрий приклад. Наш застосунок його не вигадав, і він уже має зміст. Сурогатний ключ створюють спеціально для ідентифікації запису; він нічого не описує, він лише ідентифікує.

У більшості архітектур я віддаю перевагу сурогатному ключу як внутрішньому ID запису, а важливі природні ідентифікатори тримаю як атрибути. Це не робить природні ідентифікатори поганими; часто вони надзвичайно важливі. Просто я не роблю їх автоматично унікальним ID запису. Запитайте, що станеться, якщо значення виправлять, переформатують, замінять, використають повторно, якщо його не буде або якщо воно надійде з кількох систем-джерел. Саме тут простецьке на вигляд рішення стає архітектурним.

Одна річ може мати кілька корисних ідентифікаторів

Section titled “Одна річ може мати кілька корисних ідентифікаторів ”

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

Ці ідентифікатори важливі. Нам треба їх зберігати й правильно зіставляти, бо оновлення статусу має повертатися кожному партнерові під його номером. Але не всі вони мають ставати унікальним ID доставки. На запитання «який у неї ID?» може бути більше однієї відповіді, і архітектор має знати, який ID авторитетний у якому контексті. Ми повернемося до цього з основними даними та інтеграцією.

Зв’язки залежать від унікальних ID

Section titled “Зв’язки залежать від унікальних ID ”

Тепер поверніться до намальованих ліній. Маніфест містить доставки. Отримувач отримує доставки. Бригада має призначення. Ці зв’язки працюють лише тому, що ми можемо надійно ідентифікувати речі на обох кінцях.

Ось де це боляче кусає в Steve Trucking. Роздрібний партнер переглядає маніфест у день доставки: замовлення скасовано, позицію замінено, нова адреса. Якщо ми не можемо зіставити переглянутий рядок із доставкою, яка вже є, за номером замовлення партнера, ми створюємо другу доставку для того самого холодильника, і бригада може приїхати двічі. Прямокутники, атрибути, ключі й зв’язки — не окремі ідеї. Усе це частини однієї моделі.

Детальна сфокусована модель даних Детальна сфокусована модель даних для Steve Trucking у трьох групах. Кожна сутність має свій ID запису (згенерований внутрішній унікальний ID), усе, за чим її також знають, і кілька ключових полів. Роздрібний партнер (назва, платіжна адреса, статус) керує Розподільчими центрами і надсилає Доставки. Доставку також знають за номером замовлення партнера та ID доставки в RouteDesk; вона доставляється до Отримувача (ім’я, адреса, телефон, ел. пошта), виїжджає з Розподільчого центру (назва, адреса, ринок) і містить Позиції доставки (продукт, кількість, зі встановленням). Бригада виконує Призначення бригади, а Вантажівка (також відома за VIN і бортовим номером) використовується в Призначеннях бригади, які мають дату початку і дату завершення. ДАНІ КЛІЄНТІВ ТРАНЗАКЦІЙНІ ДАНІ ДОВІДКОВІ ДАНІ керує надсилає доставляється до виїжджає з містить виконує використовується в Роздрібний партнер ID роздрібного партнера ID ЗАПИСУ Назва Платіжна адреса Статус Отримувач ID отримувача ID ЗАПИСУ Ім’я Адреса Телефон Ел. пошта Доставка ID доставки ID ЗАПИСУ Номер замовлення партнера ТАКОЖ ВІДОМИЙ ЯК ID доставки в RouteDesk ТАКОЖ ВІДОМИЙ ЯК Дата доставки Обіцяне вікно Статус Позиція доставки ID позиції доставки ID ЗАПИСУ Продукт Кількість Зі встановленням Призначення бригади ID призначення бригади ID ЗАПИСУ Дата початку Дата завершення Розподільчий центр ID розподільчого центру ID ЗАПИСУ Назва Адреса Ринок Бригада ID бригади ID ЗАПИСУ Назва Статус Вантажівка ID вантажівки ID ЗАПИСУ VIN ТАКОЖ ВІДОМИЙ ЯК Бортовий номер ТАКОЖ ВІДОМИЙ ЯК Марка Модель Номерний знак Статус рівно один нуль або один один або багато нуль або багато © 2026 Twinshark LLC · stevetecharc.com
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 фізично це реалізує — пізніший крок.

Що тут вирішує архітектор

Section titled “Що тут вирішує архітектор ”

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

  • Які атрибути справді описують кожну сутність.
  • Як кожна сутність унікально ідентифікується і чи достатньо стабільний цей ідентифікатор, щоб бути її унікальним ID.
  • Які бізнес-ідентифікатори (номери замовлень партнерів, застарілі ID) треба зберігати й зіставляти.
  • Чи не використовується чутлива інформація як ключ.
  • Чи пов’язують зв’язки сутності через надійні унікальні ID.

Тепер у нас є сутності, зв’язки, атрибути й унікальні ID: зачатки справжньої логічної моделі даних. Але проблема ще лишається. Дуже легко покласти цілком коректні дані не в те місце. Тут і з’являється нормалізація.

Додаткові матеріали

Section titled “Додаткові матеріали ”