Намалюйте зв’язки
Також доступно 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 з 6 розділу Моделювання даних заради змісту, розділ 2 курсу Data Architect. Кожен модуль самостійний. Попередній: Слухайте іменники · Наступний: Побудуйте логічну модель
Питання, на яке відповідає цей модуль: Як перетворити кандидатів у сутності на концептуальну модель даних?
У нас на дошці іменники. Тепер я хочу знати про лінії між прямокутниками, бо набір сутностей — це ще не модель даних. Чимало змісту живе саме у зв’язках. Роздрібний партнер має розподільчі центри. Маніфест містить доставки. Доставка йде до отримувача. Бригада працює на вантажівці. Кожне з цих тверджень каже мені щось про бізнес, і кожне дає ще одне запитання.
Почніть із мови бізнесу
Section titled “Почніть із мови бізнесу ”Я все ще не хочу говорити про Salesforce. Я не питаю, чи має це бути зв’язок lookup чи master-detail, не думаю про об’єкти-з’єднувачі Salesforce (Salesforce Junction Object) і не вирішую, що станеться, коли видалять батьківський запис. Я намагаюся зрозуміти бізнес-зв’язок.
Візьміть «роздрібний партнер має розподільчі центри». Звучить просто. Але чи може роздрібний партнер мати один DC чи багато? У Steve Trucking кожен роздрібний партнер має регіональний розподільчий центр у кожному регіоні, який обслуговує Steve Trucking, тож багато. Чи може DC належати більш ніж одному роздрібному партнерові? Чи важливий DC сам по собі, з власним персоналом та історією, чи це просто адреса? Якщо роздрібний партнер піде, чи будуть нас ще цікавити його DC?
Це не запитання про Salesforce. Це бізнес-запитання, і відповіді можуть повністю змінити модель.
Читайте лінії
Section titled “Читайте лінії ”Перш ніж іти глибше, я хочу дати вам мову, якою ми користуватимемося на кожній діаграмі відтепер. Вона невелика. Лінія між двома прямокутниками каже, що дві речі пов’язані, а позначки на її кінцях кажуть, скільки.
Почніть із простої лінії, без жодних позначок. З неї я починаю на дошці: я знаю, що ці два іменники пов’язані, просто ще не запитав як. Потім на кінцях з’являються позначки. Одна риска поперек лінії означає один. «Воронячі лапки» — кінець, що розгалужується на три, як пташина лапа, — означають багато. Пізніше в цьому модулі ви побачите, як поруч із першою з’являється друга позначка, риска чи кружечок, і вона відповідає на інше запитання: чи може не бути жодного?
Одне правило, яке треба запам’ятати: кожну позначку читають біля того прямокутника, якого вона торкається. Позначка, найближча до прямокутника, — це максимум; наступна позначка — мінімум.
Сидіти, чекати, моделювати
Section titled “Сидіти, чекати, моделювати ”Перш ніж до Steve Trucking, повернімося до собак із модуля 1. У нас було п’ять прямокутників: Власник, Заводчик, Собака, Порода і Трюк. Тепер я питаю про лінії між ними.
Один чи багато? Власник може мати більше однієї собаки; в Ana їх дві. Собака має одного власника, принаймні в нашій моделі. Це «один до багатьох»: риска біля Власника, «воронячі лапки» біля Собаки. Заводчик має таку саму форму: один заводчик виводить багато собак.
Чи може не бути жодного? Max — із притулку, тож заводчика в нього взагалі немає. Кінець біля Заводчика отримує кружечок: собака має нуль або одного заводчика. Але кожна собака має власника, тож той кінець отримує другу риску: рівно один.
Багато до багатьох? Собака знає багато трюків, а трюк, скажімо «Сидіти», знає багато собак. Це «багато до багатьох», і саме там я шукаю приховане поняття. Чи є щось про те, що ця собака знає цей трюк? Наскільки добре вона його виконує і коли навчилася. Зв’язок має власні факти, тож він стає окремою річчю: Трюк собаки, з назвою собаки першою, бо саме собака його визначає.
Що означає кожна лінія? Власник володіє собакою. Заводчик її виводить. Собака знає свої трюки. Назвіть лінії, і будь-хто зможе переказати вам модель.
Зараз чи з часом? Чи когось цікавить, наскільки добре Bella виконує «Сидіти» сьогодні, чи як вона до цього дійшла? Якщо дресирувальник перевіряє її кожні кілька місяців, кожна перевірка — окремий запис: Оцінка трюку з датою, рівнем навички і тим, хто перевіряв, під Трюком собаки, до якого вона належить. Навіть зв’язок, що став річчю, може мати власну історію.
Породу я поки лишаю непов’язаною. Це досі запитання з модуля 1 — окремий прямокутник чи слово на собаці, — і модуль 4 його розв’яже.
Кожне з цих запитань так само працює для справжнього бізнесу. Тепер поставмо їх Steve Trucking.
Питайте «один чи багато?»
Section titled “Питайте «один чи багато?» ”Одне з перших, що я хочу зрозуміти про зв’язок, — його кардинальність. Це термін із баз даних; саме запитання набагато простіше: скільки цих може бути пов’язано зі скількома тих? На концептуальному рівні є три базові шаблони.
Це важливий крок у процесі: візьміть два різні іменники й зрозумійте їхній зв’язок. У більшості ситуацій це «один до багатьох» або «багато до одного». Лише в рідкісних випадках ви натрапите на «один до одного».
«Один до багатьох» — усюди. Один роздрібний партнер має багато розподільчих центрів. Один маніфест містить багато доставок. Один маршрут має близько десяти зупинок. Почувши таке, я починаю малювати лінію.
А тепер лінія отримує позначки. Кожен кінець каже, скільки є того прямокутника, якого він торкається: риска для одного, «воронячі лапки» для багатьох. Читайте від кожного прямокутника: один роздрібний партнер має багато розподільчих центрів.
Зв’язки «один до одного» існують, але вони рідкісні, і, знайшовши такий, я ставлю запитання. Це справді два різні іменники чи той самий? Якщо різні, який зв’язок «один до одного» між ними? І чи завжди він буде «один до одного», чи лише зараз? Це ключові запитання в проєктуванні моделі даних. Бригада і вантажівка здаються «один до одного» будь-якого ранку: двоє людей, одна вантажівка, один маршрут. За місяць — ні, і саме там ховається найцікавіший зв’язок цієї моделі.
Зв’язки «багато до багатьох» особливо цікаві, бо часто кажуть нам, що в бізнесі є ще одне поняття. Чи може бригада з часом їздити на кількох вантажівках? Так. Чи може на вантажівці їздити кілька бригад? За її життя — безперечно. Тож бригади й вантажівки мають зв’язок «багато до багатьох». Але тепер я хочу знати більше. Чи важливо бізнесу, коли бригада мала вантажівку? Для якого маршруту, якого дня? Хто зробив призначення? Якщо сам зв’язок несе важливу для нас інформацію, ми знайшли ще одне бізнес-поняття: Призначення бригади.
Це важлива звичка моделювання. Іноді найцікавіше — не один з іменників, які ми почули спочатку. Воно ховається у зв’язку між двома іменниками.
Зв’язки можуть ставати речами
Section titled “Зв’язки можуть ставати речами ”Це одне з місць, де я хочу, щоб адміністратори почали мислити інакше. У Salesforce ми звикли говорити про об’єкти й поля, тож легко вважати прямокутники важливою частиною, а лінії — сантехнікою. Але сам зв’язок може мати бізнес-зміст.
Розгляньмо доставку і продукти в ній. Доставка може містити кілька продуктів, скажімо пральну машину і сушарку. Продукт, та сама модель холодильника, з’являється в тисячах доставок. Досить просто. Але що, як мені треба знати, скільки одиниць цього продукту в цій доставці, чи його встановлюють, чи вивозять старий? Мене вже цікавить не лише зв’язок між Доставкою і Продуктом. Мене цікавить Позиція доставки, і це поняття заслуговує на власну сутність.
Якщо ви прийшли із Salesforce, то, можливо, вже думаєте: «Це об’єкт-з’єднувач». І ви не помиляєтеся. Але я не хочу з цього починати. Позиція доставки — це бізнес-поняття, перш ніж стати об’єктом-з’єднувачем Salesforce (Salesforce Junction Object). Спершу бізнес, потім реалізація.
Кілька моїх звичок щодо таких сутностей-зв’язків, хоч би де їх зрештою збудували.
Назвіть її. Якщо в бізнесу вже є для неї слово, беріть його. Якщо немає, візьміть назви двох батьків і поєднайте їх. Подумайте про замовлення і продукт. Те, що між ними, — Order Item: замовлення і позиція в замовленні. Це дочірній запис обох батьків, і в Salesforce він може стати об’єктом-з’єднувачем Salesforce. Але яка назва йде першою: Item Order чи Order Item? Подивіться, що це за вид даних у кожного батька. Продукт — довідкові дані; замовлення — транзакційні, і саме замовлення визначає зв’язок. Тож це Order Item, або Order Product, так само як у Salesforce є Opportunity Product. У Steve Trucking це Позиція доставки (Delivery Item). Визначальна назва йде першою, і запис сортується поруч зі своїм власником у кожному списку, який ви колись побачите.
Дайте їй власний ключ. Спокусливо сказати, що Позиція доставки ідентифікується Доставкою плюс Продуктом, і на цьому зупинитися. Це складений ключ, а зі складеними ключами працювати набагато важче: кожна система, що посилається на запис, мусить нести обидві половини. Дайте сутності-зв’язку власний ідентифікатор, а Доставку плюс Продукт лишіть як правило унікальності, а не як ідентичність.
Зверніть увагу, чого на ній немає: серійного номера. Кількість і серійний номер не належать до одного запису. Кількість рахує кілька одиниць речі; серійний номер ідентифікує одну конкретну річ. Якщо бізнесу потрібні серійні номери, кожна одиниця стає окремим записом, і п’ять холодильників — це п’ять записів. Я не бачу сенсу в Позиції доставки з Деталлю позиції доставки під нею. Або одне, або інше: агрегат із кількістю або один запис на одиницю. Тут — кількість.
Стежте за атрибутами, яким потрібна історія. Деякі сутності-зв’язки після створення вже не змінюються: пральна машина в цій доставці лишається пральною машиною в цій доставці. Інші змінюються постійно. Цього тижня бригада має вантажівку 117, а наступного тижня вантажівка переходить до іншої бригади. Коли зв’язок змінюється, а бізнесу важливо, яким він був, сутності-зв’язку потрібні дати, і стежити варто саме за Призначенням бригади. Запитайте рано, чи важливе бізнесу зараз чи з часом; ми до цього зараз повернемося.
Зв’язки мають зміст не лише в кардинальності
Section titled “Зв’язки мають зміст не лише в кардинальності ”«Один до багатьох» — недостатньо, щоб зрозуміти зв’язок. Я також хочу знати, що зв’язок означає.
Доставка має місце. Яке? Розподільчий центр, з якого вона виїжджає? Дім отримувача, куди вона їде? Це не взаємозамінні речі. Дві моделі можуть мати однакові прямокутники й однакову кардинальність, а лінії — означати зовсім різне. Тому добра модель — не просто прямокутники, з’єднані лініями. Лінії потребують назв. Якщо я дам іншому архітекторові свою діаграму, йому не доведеться вгадувати, що означає зв’язок, а якщо я показую її бізнесу, вона має говорити знайомою йому мовою.
Обов’язковість теж важлива
Section titled “Обов’язковість теж важлива ”У запитанні «скільки?» ховається ще одне: чи зв’язок обов’язковий? Чи може доставка існувати до того, як її поставили в маршрут? Мусить: маніфест приходить за день-два до доставки, а маршрути остаточно формують напередодні ввечері. Чи може доставка існувати без роздрібного партнера? Ні; кожна доставка походить із маніфесту партнера. Це обов’язковість.
Знову ж таки, не стрибайте одразу до позначки Required у Salesforce. Є різниця між «кожна доставка мусить мати роздрібного партнера» і «Salesforce має вимагати поле роздрібного партнера під час створення запису». Вони можуть закінчитися однаковою реалізацією, але це не однакові твердження. Перше — бізнес-правило; друге — один зі способів його забезпечити. Як архітектори ми хочемо зрозуміти перше, перш ніж вирішувати друге.
На діаграмі обов’язковість — це друга позначка на кожному кінці. Позначка, найближча до прямокутника, — максимум: риска для одного, «воронячі лапки» для багатьох. Наступна — мінімум: ще одна риска означає щонайменше один, кружечок — може бути нуль. Тож кожна Доставка є рівно в одному Маніфесті, а Маніфест містить одну або багато Доставок. Доставка є на нуль або одній Зупинці, на жодній, доки її не поставили в маршрут, а на Зупинці залишають нуль або багато Доставок.
Час змінює зв’язки
Section titled “Час змінює зв’язки ”Ось запитання, яке я ставлю часто: ви маєте на увазі зараз чи з часом?
Бригада працює на вантажівці. Зараз? На сьогоднішньому маршруті? Доки ці двоє працюють разом? Це дає різні моделі. Якщо бізнесу важливо лише, яку вантажівку бригада має сьогодні, модель може лишатися простою. Якщо потрібна кожна вантажівка, на якій бригада їздила, коли і на якому маршруті, нам потрібна історія, і знайдене нами Призначення бригади раптом стає дуже важливим.
Це поширене джерело помилок моделювання. Ми моделюємо поточний стан, бо його видно на екрані. А за кілька тижнів роздрібний партнер подає претензію про пошкодження, і хтось питає: «Яка бригада мала вантажівку 117 17 березня?» І ми виявляємо, що перезаписували відповідь щоразу, коли змінювалося призначення.
Один зі способів зберегти цю історію — зробити призначення окремим записом. Коли бригаду призначають, ми створюємо Призначення бригади з датою початку. Коли призначення змінюється, ставимо дату завершення на старий запис і створюємо новий із власною датою початку. Тепер «хто мав це призначення пів року тому?» — просте запитання, а не розкопки в історії полів чи журналі змін даних. А щойно в бригади багато призначень, хтось запитає, яке з них поточне, тож я додав би ще прапорець Active.
Тож коли мені розповідають про зв’язок, я питаю не лише, як речі пов’язані. Я питаю: чи змінюється цей зв’язок і чи важлива нам його історія?
Малюйте, перш ніж налаштовувати
Section titled “Малюйте, перш ніж налаштовувати ”Наша модель Steve Trucking стає корисною. Ми знаємо, які зв’язки «один до багатьох», де «багато до багатьох» ховає ще одне поняття, які зв’язки необов’язкові і які змінюються з часом. І ми досі не створили жодного об’єкта Salesforce. Це навмисно.
Цю діаграму я маю могти показати бізнесу, і людям не треба знати Salesforce, щоб сказати мені, чи вона правильна. Якщо вони не можуть її перевірити, бо вона повна термінології Salesforce, я надто швидко перейшов до фізичного дизайну.
Що тут вирішує архітектор
Section titled “Що тут вирішує архітектор ”Опрацьовуючи зв’язки в концептуальній моделі, я вирішую:
- Як основні бізнес-сутності пов’язані між собою.
- Чи кожен зв’язок «один до одного», «один до багатьох» чи «багато до багатьох» — зараз і з часом.
- Чи кожен зв’язок обов’язковий чи необов’язковий.
- Чи не ховає зв’язок «багато до багатьох» змістовне бізнес-поняття.
- Чи змінюється зв’язок з часом і чи потрібна нам його історія.
Lookup чи master-detail, налаштування об’єкта-з’єднувача, каскадна поведінка і спільний доступ — це фізичні рішення; ми до них дійдемо. Зараз ми ще відповідаємо на важливіше запитання: як насправді працює цей бізнес? Щойно ми розуміємо сутності й зв’язки між ними, можна починати додавати деталі, що їх описують. Тоді наша концептуальна модель починає ставати логічною моделлю даних.