Словник, походження і класифікація
Також доступно 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 розділу Якість даних і врядування, розділ 5 курсу Data Architect. Кожен модуль самостійний. Попередній: Як не пустити погані дані · Наступний: Закони про приватність формують дизайн
Питання, на яке відповідає цей модуль: Як зафіксувати, що означають дані, звідки вони походять і наскільки вони чутливі?
Ви успадкували org. На Account 900 полів, серед них Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c і Account_Status__c. Котре каже вам, чи хтось справді клієнт? Ви відкриваєте описи. Три порожні. Один каже «Customer Type». Дякую. Один каже, що поле прийшло з ERP; інше створила шість років тому людина, що давно пішла. А тепер уявіть, що ви не архітектор, а інтеграція, команда звітності чи агент. Даних в організації вдосталь. Це не означає, що вона знає, що вони означають.
Тут метадані стають архітектурою — через три запитання, пов’язані, але не однакові:
- Словник: що означають ці дані?
- Походження (lineage): звідки вони?
- Класифікація: як із ними треба поводитися?
Два види метаданих
Section titled “Два види метаданих ”Метадані бувають двох видів, і вам потрібні обидва. Бізнесові метадані — це те, що дані означають для бізнесу: визначення, власник, правила використання, наскільки вони чутливі. Технічні метадані — це те, як дані побудовані й рухаються: об’єкт і поле, тип і довжина, ім’я API, схема, мапінг з однієї системи в іншу, походження від джерела до цілі. Ім’я API і тип поля кажуть розробникові, як ним користуватися; його визначення і власник кажуть усім іншим, чи варто. Коли вони розходяться або одного бракує, саме там і ламаються інтеграції та звіти.
Варто знати для іспиту. Відрізняйте бізнесові метадані (зміст, визначення, власник, правила, чутливість: бізнес-словник і класифікація) від технічних метаданих (об’єкти, поля, типи, імена API, схеми, мапінги й походження).
Почніть зі змісту
Section titled “Почніть зі змісту ”Розділ 3 встановив правило: кожне поле отримує опис. Не «Customer Status» для поля з назвою Customer Status, а щось на кшталт «Поточні комерційні стосунки партнера зі Steve Trucking. Встановлюється з ERP після активації. Не використовувати для кваліфікації потенційних клієнтів». Тепер я знаю, що воно означає, звідки береться і для чого його не використовувати. Це початок бізнес-словника: спільних визначень для даних, що важливі. Що таке клієнт? Активний клієнт? Що означає «Доставлено»? Що вважається вчасним? Це звучить очевидно, доки не зберете в кімнаті п’ять відділів: у фінансів одне визначення, у продажів друге, в операцій третє, у сховища даних четверте, а хтось збудував дашборд на п’ятому. Проблема не в тому, що ніхто не розмовляє англійською. Проблема в тому, що підприємство не домовилося про зміст.
Словник може жити в таблиці чи інструменті документації, але його важливі визначення мають бути поруч із місцем, де люди користуються даними. На платформі це описи полів, текст довідки й метадані класифікації. В аналітиці це ще важливіше: «дохід» не може означати одне на дашборді керівництва, а інше в запиті аналітика. Для цього існує семантичний шар, і семантичні моделі Data 360 тримають керовані визначення — метрики, виміри й зв’язки — над фізичними даними (Create a Semantic Model in Data 360 (opens in a new tab)). Технології змінюються; вимога — ні: важливим даним потрібен узгоджений зміст.
І починайте зі змісту, а не з технології. Словник, що починається з об’єкта, поля, типу й API-імені, документує реалізацію. Той, що починається з бізнес-термінів, документує підприємство:
| Бізнес-термін | Зміст | Де відображено |
|---|---|---|
| Роздрібний партнер | Роздрібна мережа, для якої Steve Trucking доставляє за договором | Account у Salesforce; клієнт у фінансовій ERP |
| Доставка | Одна доставка одному отримувачеві, за однією адресою, в один день | Сьогодні RouteDesk; робоче замовлення, щойно доставки переїдуть у Salesforce |
| Отримувач | Людина, що отримує доставку | Дані отримувача на доставці |
| Доставлено | Завершено відповідно до узгодженого операційного визначення | Статус доставки |
| Вчасна доставка | Завершено в межах узгодженого вікна доставки | Обчислювана метрика |
Один зміст, багато технічних представлень.
Потім запитайте, звідки це
Section titled “Потім запитайте, звідки це ”Щойно я знаю, що означає значення, я хочу знати, звідки воно. Це походження. Юридична назва партнера в Salesforce: її ввів продавець, надіслала ERP, перетворила інтеграція, уніфікував Data 360, її обчислили, згенерував ШІ? Від цього залежить, наскільки я їй довіряю і що можу з нею робити. Згадайте тимчасові записи з модуля 2: два акаунти можуть обидва казати «Keystone», один створив продавець учора, інший прийшов з ERP з авторитетним ідентифікатором. Той самий текст, різне походження, різне поводження.
Походження — не лише діаграма тисячі таблиць від інженера даних. Для важливих даних я хочу відповідати на практичні запитання: де вони почалися, яка система авторитетна, що їх перетворило, які системи отримали копії, що змінило їх востаннє і чи можу я простежити обчислене значення до його джерел? Ландшафт із розділу 4 каже, що системи з’єднані. Походження каже, що сталося з даними дорогою.
Частина походження дістається безкоштовно: ID ERP на акаунті, Created By і Last Modified By, журнали інтеграцій, документи зіставлення. Data 360 додає до своїх об’єктів даних поля походження, що фіксують джерело даних і об’єкт-джерело для кожного запису (Data Lineage Fields (opens in a new tab)). Але не припускайте, що походження з’являється, бо системи інтегровані. Іноді найкорисніше походження — одне поле: Source System = Keystone. А якщо джерело важливе для врядування, зробіть його механічно надійним — нехай його встановлює інтеграція, а не вводить людина.
Обчислюваним даним походження потрібне найбільше. Скажімо, Steve Trucking обчислює ризик запізнення доставки з позиції вантажівки, вікна доставки й історії маршруту, а диспетчеризація використовує його для пріоритетів. Звідки взялося «високий»? Додайте агента, що каже отримувачеві «ваша доставка запізнюється», і вам треба знати, на чому це ґрунтувалося і наскільки свіжим було. Що далі ви відходите від збережених значень до обчислених, уніфікованих, прогнозованих і згенерованих, то важливіше походження.
Класифікація відповідає на інше запитання
Section titled “Класифікація відповідає на інше запитання ”Тепер: як із цим треба поводитися? Ім’я отримувача, адреса доставки, номер телефону, нотатки до доставки, статус доставки, номер вантажівки, розподільчий центр, роздрібний партнер, фото: вони не однаково чутливі. «У дорозі» — не номер телефону, а код DC — не фото інтер’єру чийогось дому. Salesforce дає записати це на кожному полі, стандартному чи користувацькому: Data Owner, Field Usage, Data Sensitivity Level і Compliance Categorization (Data Classification Metadata Fields (opens in a new tab)). Розділ 3 назвав їх полями таксономії і пояснив, чому вони важливі: позначте поле як PII чи GDPR, і процеси зможуть його знайти — від інструментів маскування до шару довіри ШІ від Salesforce, який може не допустити позначені значення до великої мовної моделі. Одне застереження з розділу 3: Salesforce тепер вимикає це маскування для LLM в агентів, бо воно може прибрати контекст, потрібний агентові (Класифікуйте важливе: поля таксономії). Тож класифікація все одно має керувати іншими контролями.
Моя позиція тут свідома: класифікуйте чутливі поля, а не кожне поле. Я не хочу, щоб три місяці пішли на класифікацію тисяч полів, аби хтось звітував «100% класифіковано», а ніхто цим не користувався. Номер телефону отримувача: так. Домашня адреса: так. Нотатки до доставки, що можуть містити коди воріт і «собака у дворі»: так. Фото, що можуть показувати людей чи дім: безумовно. Внутрішня мітка для відображення? Не туди має йти енергія врядування. Це не робить незадокументовані поля прийнятними. Дві різні роботи: документація широка; класифікація свідома. Саме це тримає класифікацію змістовною.
Таксономія, якою люди можуть користуватися
Section titled “Таксономія, якою люди можуть користуватися ”Класифікації потрібен словник — таксономія. Стандартні значення Salesforce — Public, Internal, Confidential, Restricted і MissionCritical; ваша організація може захотіти власних міток. Я їх не приписую. Тримайте їх зрозумілими: якщо категорій 47 і ніхто поза командою приватності не відрізнить категорію 31 від 32, це не допомагає. Добра таксономія пов’язує мітку з поведінкою. Якщо поле містить чутливі персональні дані: хто може його бачити, чи може воно йти в sandbox, залишати регіон, з’являтися в аналітиці, як довго його зберігають, чи може агент ним користуватися? Тепер класифікація працює.
Класифікація без забезпечення — прикраса
Section titled “Класифікація без забезпечення — прикраса ”Позначте номер телефону отримувача чутливим і більше нічого не змініть — і ви написали документацію. Корисно, але врядування йде далі: класифікація має керувати дозволами, маскуванням, шифруванням, зберіганням, згодою, переміщенням даних, використанням sandboxes, аудитом і доступом ШІ. Частина цього — проєктне рішення архітектора; деякі платформи тепер застосовують теги й класифікації прямо в політиках, як це робить врядування Data 360 (Data Governance in Data 360 (opens in a new tab)). І позначка поля як Restricted нікого не зупиняє від його читання. Класифікація каже, як із полем треба поводитися; безпека робить це так. Послідовність така: визначте дані, зрозумійте їх, класифікуйте важливе, а потім застосуйте контролі, яких вимагає ця класифікація.
Три запитання про ваші дані, і третє має чимось керувати.
Довідковим даним теж потрібні метадані
Section titled “Довідковим даним теж потрібні метадані ”Коди країн, статуси доставок, коди DC, ідентифікатори партнерів, причини скасування: вони здаються простими, доки дві системи не розійдуться. Одна каже CANCELLED, інша CANCELED, третя CNCL, четверта 9. Довідковим даним потрібні визначення, власник, джерело, життєвий цикл там, де значення змінюються, і зіставлення, коли системи відображають їх по-різному. Маленькі значення можуть керувати дуже великими процесами. Розділ 6 іде далі.
Усі три разом
Section titled “Усі три разом ”Візьміть номер телефону отримувача. Словник: номер, за яким зв’язуються з людиною, що отримує конкретну доставку. Походження: з маніфесту роздрібного партнера. Класифікація: персональні дані. Тепер можливі архітектурні запитання: чи може бригада його бачити і як довго (бриф каже: лише для своїх зупинок і лише того дня); чи може він іти в sandbox; чи потрібен він Snowflake; чи може агент ним користуватися; що станеться, коли доставку завершено?
Тепер візьміть статус доставки. Словник: поточний операційний стан доставки. Походження: встановлюється процесом доставки Steve Trucking і надсилається назад кожному партнерові через його інтеграцію. Класифікація: операційний, не чутливий. Різні дані, різне поводження. У цьому суть.
Я не вважаю метадані документацією, яку пишуть після того, як справжню архітектуру завершено. Якщо я не можу сказати, що означає поле, я не розумію модель даних. Якщо я не знаю, звідки значення, я не розумію інтеграцій. Якщо я не знаю, чи воно чутливе, я не розумію безпеки. Метадані описують архітектуру, а іноді й керують нею.
За межами іспиту: що змінює ШІ. Класифікація стає перемикачем того, що агент може отримати чи повторити, а походження має сягати аж до відповіді чи дії агента. Якщо агент каже отримувачеві, що доставка запізнюється, архітектура має вміти сказати, на чому це ґрунтувалося, звідки це походить і чи мав агент право цим користуватися. «Десь у Salesforce» — не походження, а «дані клієнтів» — не класифікація.
Що тут вирішує архітектор
Section titled “Що тут вирішує архітектор ”- Яким бізнес-термінам потрібні керовані визначення, щоб системи й команди не давали одному слову різні значення.
- Як важливі значення зберігають достатньо походження, щоб показати своє джерело, авторитетність і перетворення.
- Які поля несуть зміст щодо чутливості чи відповідності і тому отримують явну класифікацію.
- Яку таксономію використовує організація і чи можуть люди застосовувати її послідовно.
- Як класифікація керує справжніми контролями, а не лежить без діла.
Перш ніж керувати даними, знайте, що у вас є: що вони означають, звідки походять, як із ними треба поводитися. Документуйте широко, класифікуйте свідомо, зберігайте походження там, де це важливо. Інакше ви не керуєте даними. Ви просто їх маєте.
Додаткові матеріали
Section titled “Додаткові матеріали ”- Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (англійською, перевірено 2026-10-14).
- Salesforce Help, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) і Create a Semantic Model in Data 360 (opens in a new tab) (англійською, перевірено 2026-10-14).