Якість даних і врядування

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

Зображення згенеровано ШІ

Перекладено ШІ. Спільнота ще не перевірила. Читати англійською

Навчальний посібник до розділу 5 курсу Data Architect. Спершу прочитайте шість модулів; ця сторінка допоможе перевірити, що запам’яталося.

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

Цей розділ несе частину іспиту Data Governance (10%) і частини Data Modeling (метадані) та Salesforce Data Management (узгодженість). Також тут закони про приватність зустрічаються з моделлю даних. Це архітектура, а не юридична порада: юристи вирішують, що діє, а архітектор робить це таким, що можна забезпечити. Числа платформи змінюються, тож перевіряйте актуальні, перш ніж на них покладатися.

Для іспиту

Позначайте їх у міру просування. Кожен пункт веде туди, де його пояснено.

GOV-2: проєктування програми врядування

• Я знаю, що власник запису (механізм доступу платформи) — не власник даних (відповідальний за дані як бізнес-актив) і що кожне поле може фіксувати Data Owner. (Власник запису — не власник даних)
• Я можу розрізнити власника даних (встановлює політику), стюарда даних (підтримує, щоб усе працювало) і адміністратора (веде систему). (Власник, стюард, адміністратор)
• Варто знати для іспиту: я знаю три способи вести програму врядування, централізований, федеративний (децентралізований) і гібридний, і що кожен означає для того, хто встановлює політику і де живуть спільні визначення. (Як працює програма)
• Я можу використати RACI, щоб відповісти, де дані створюються, редагуються і де на них посилаються. (Нехай RACI заслужить своє місце)
• Я можу назвати точку забезпечення для політики врядування (дозволи, перевірка, поля лише для інтеграції, історія полів), а не лише навчання. (Врядування має стати механічним)
• Я знаю, що вимірювати варто ті сигнали якості, на які хтось відреагує. (Вимірюйте те, на що хтось відреагує)

SDM-2 і MDM-4: як не пустити погані дані

• Я можу вирішити, чи має створення акаунтів бути відкритим чи закритим, і знаю шлях тимчасового типу запису для акаунтів, що керуються в ERP. (Відкрите чи закрите?, Середній шлях)
• Я можу захистити керовані атрибути (ID в ERP, юридичну назву), лишивши власні поля Salesforce доступними для редагування: це гібридний golden record. І я знаю, що поле лише для читання на сторінці Dynamic Forms — не забезпечення; забезпечення — це безпека на рівні полів або правило перевірки. (Захистіть керований запис, Тип запису для кожного потоку)
• Я знаю, що двобічні потоки найскладніші: якщо полем керує ERP, Salesforce просить його змінити, а колізії потрібне правило (перемагає ERP, відхилити, якщо змінилося, або розв’язує людина). (Захистіть керований запис)
• Я знаю, що обов’язкові поля можуть створювати фальшиві дані (N/A, 999999), і знаю альтернативи. (Не дайте обов’язковим полям створювати фальшиві дані)
• Я можу вирішити, що стається з вхідними даними, що не пройшли перевірки: прийняти, відхилити чи поставити на карантин, і хто володіє винятком. (Кожній межі даних потрібне рішення про якість)
• Я знаю, що довідковим даним теж потрібні метадані: визначення, власник, джерело і зіставлення між системами. (Довідковим даним теж потрібні метадані)

DM-3: бізнес- і технічні метадані

• Варто знати для іспиту: я відрізняю бізнесові метадані (зміст, визначення, власник, правила, чутливість) від технічних метаданих (об’єкти, поля, типи, імена API, схеми, мапінги, походження). (Два види метаданих)
• Я знаю різницю між бізнес-словником (що це означає), походженням (звідки це) і класифікацією (як із цим треба поводитися). (Знайте свої дані)
• Я знаю поля класифікації Salesforce: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization — на стандартних і користувацьких полях. (Класифікація відповідає на інше запитання)
• Я знаю, що треба класифікувати чутливі поля, а не кожне поле, і що класифікація без забезпечення — прикраса. (Класифікація без забезпечення — прикраса)

GOV-1: персональні й чутливі дані

• Я впізнаю основні закони (GDPR, CCPA/CPRA, PIPEDA, LGPD, австралійський Privacy Act, HIPAA, PCI DSS, SOX, COPPA), знаю, що GDPR може поширюватися на організації за межами ЄС, і знаю, що в законах спільного: права, передавання, повідомлення про витік і підзвітність. (Регулювання, яке треба впізнавати, Закони не зупиняються на кордоні)
• Я знаю різницю між шифруванням, маскуванням, псевдонімізацією й анонімізацією і що псевдонімізовані дані досі персональні. (Анонімізоване, псевдонімізоване, зашифроване, замасковане)
• Я знаю, що збирати менше — це контроль приватності, а зберігання проєктують заздалегідь. (Збирати менше — архітектурне рішення, Зберігання — частина моделі)
• Я знаю модель даних згоди: глобальна згода на Individual, згода на тип каналу, згода на контактну точку і мета використання даних. (Використовуйте модель, яку Salesforce уже збудував)
• Я знаю, що запити мають строки (GDPR: один місяць, із можливістю продовжити ще на два), тож карта копій має існувати заздалегідь. (Годинник цокає)
• Я знаю, що право на забуття означає знайти кожну копію (історію, архіви, аналітику, журнали, файли, вільний текст) і що політики Privacy Center виконуються по кожному об’єкту щодо запису клієнта. (А тепер людина каже: забудьте мене, Privacy Center — інструмент)
• Я знаю компроміси Shield Platform Encryption: імовірнісні поля не можна фільтрувати, групувати чи сортувати в SOQL; детерміноване шифрування дозволяє фільтрування; зашифровані поля не можуть керувати спільним доступом на основі критеріїв. (Шифрування — контроль, а не відповідність)
• Я знаю, що не можна копіювати чутливі дані продакшну в sandboxes і що Data Mask замінюється на Data Mask & Seed. (Не копіюйте ризик продакшну в sandbox)
• Я знаю відстеження історії полів (до 20 полів на об’єкт; 18 місяців, 24 — лише через API; для довгого тексту записується лише факт редагування) проти Field Audit Trail (до 200 полів, зберігається, доки ви не видалите). (Історія — теж дані)
• Я знаю строки зберігання журналів Event Monitoring (1 день без доповнення для деяких подій, 30 днів за замовчуванням із ним, до 365 у разі продовження) і що події треба експортувати в SIEM, перш ніж вони знадобляться: платні журнали не можна отримати за період до початку контракту. (Аудит і моніторинг — не одне й те саме)

За межами іспиту

Іспит — це підлога, а не стеля. Ось звички з цього розділу, потрібні архітекторові, незалежно від того, чи спитають про них колись на іспиті.

• Політика без точки забезпечення — здебільшого побажання.
• Власники встановлюють політику; архітектори її забезпечують. Не вигадуйте політику і не грайте в юриста.
• Врядування ніколи не завершене. Воно йде припливами й відпливами; проєктуйте зворотний зв’язок.
• Не покладайтеся на добру поведінку. Будуйте контроль: люди, інтеграції й агенти — усі помиляються.
• Керуйте достатньо, а не всім.
• Спершу запобігайте дорогим помилкам. Дублікат із дворічною історією — велика проблема.
• Відрізняйте те, що читають люди, від того, на основі чого вирішують машини.
• Документуйте широко; класифікуйте свідомо.
• Найдешевші для врядування чутливі дані — ті, яких ви ніколи не копіювали.
• Згода — це дані, і дозвіл використовувати дані має бути представлений як дані.
• Спершу контролюйте, куди йдуть персональні дані, бо видалення рідкісне й складне.
• Відповідність — не продукт.
• Збір → Класифікація → Захист → Використання → Зберігання → Видалення → Аудит.
• Фіксуйте докази, перш ніж хтось про них попросить.

Ключові терміни

Термін	Одним реченням
Врядування даних	Політики щодо даних і архітектура, що робить їх правдою
Власник даних	Людина чи функція, відповідальна за певний вид даних
Стюард даних	Людина, що день у день підтримує дані здоровими
Адміністратор (custodian)	Команда, що експлуатує системи, в яких зберігаються дані
RACI	Responsible, Accountable, Consulted, Informed
Тимчасовий запис	Запис, створений до того, як його прийняла авторитетна система
Бізнес-словник	Узгоджені визначення важливих бізнес-термінів
Походження (lineage)	Звідки значення і що з ним сталося дорогою
Класифікація даних	Позначення даних за чутливістю й категорією відповідності, щоб вони отримали правильні контролі
Таксономія	Набір міток, якими організація класифікує дані
Персональні дані	Інформація, що ідентифікує людину або може бути з нею пов’язана
Псевдонімізація	Заміна ідентифікаторів, коли шлях назад досі існує; досі персональні дані
Анонімізація	Прибирання розумної можливості ідентифікувати людину
Модель даних згоди	Об’єкти Salesforce для згоди за людиною, каналом, контактною точкою і метою
Право на забуття	Право людини, там, де його дає закон, на видалення своїх персональних даних
Гібридний golden record	Один запис із полями головної системи і власними полями Salesforce, кожне з одним джерелом
Бізнесові / технічні метадані	Що дані означають і хто ними володіє / як вони побудовані й рухаються
Field Audit Trail	Довша історія полів: до 200 полів на об’єкт, зберігається до видалення
Event Monitoring	Журнали входів, експортів, викликів API й переглядів, що зберігаються обмежений час
SIEM	Репозиторій безпеки, де зберігають і аналізують журнали подій

Перевірте себе

Короткі сценарії в стилі курсу. Визначтеся з відповіддю, перш ніж розгорнути її.

1. Політика каже, що лише фінанси можуть змінювати юридичну назву клієнта. Команда планує розповісти про це на навчанні. Чого бракує?

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

2. Клієнти керуються в ERP. Продавцям треба одразу почати продавати новим потенційним клієнтам. Як це дозволити, щоб дві системи не створювали головний запис?

Дозвольте продавцям створювати акаунт як тимчасовий тип запису, а потім перетворюйте його через контрольований процес: фінанси погоджують, або інтеграція подає його в ERP, яка зіставляє чи створює клієнта й надсилає назад авторитетний ID. Перечитайте Середній шлях.

3. Нове обов’язкове поле заповнюється «N/A» і «999999». Що сталося і що б ви зробили натомість?

Користувачів змусили відповідати, перш ніж вони знали відповідь. Вимагайте поле пізніше в процесі, дайте іншій системі його надати, використайте тимчасовий стан або дозвольте явне «Невідомо», коли це справжня відповідь. Перечитайте Не дайте обов’язковим полям створювати фальшиві дані.

4. Команда замінила імена токенами й каже, що дані анонімізовано, тож запит на видалення виконано. Це так?

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

5. Отримувач погоджується на SMS про доставку, але не на маркетинг. Як модель має це тримати?

Через модель даних згоди, а не одну позначку: людина, канал (SMS), конкретний номер і мета використання даних (сповіщення про доставку, не маркетинг). І вирішіть, яка система авторитетна щодо згоди, щоб відкликання доходило до кожної системи, що на ній діє. Перечитайте Використовуйте модель, яку Salesforce уже збудував.

6. Фахівцям із відповідності треба фільтрувати звіти за зашифрованим полем із номером соціального страхування США. Поле використовує стандартну схему шифрування. У чому проблема?

Імовірнісне шифрування не дозволяє фільтрування в клаузах SOQL WHERE чи у фільтрах керування даними. Детерміноване шифрування дозволяє фільтрування за невелику ціну в стійкості. Шифрування — проєктне рішення з компромісами, а не позначка наприкінці. Перечитайте Шифрування — контроль, а не відповідність.

7. Через пів року після інциденту хтось питає, хто експортував набір записів. Ніхто не налаштував зберігання Event Monitoring. Що ви можете сказати?

Мабуть, нічого: журнали подій зберігаються обмежений час (щонайбільше рік, навіть із продовженням), тож усе старіше зникло, якщо його не експортували. Налаштуйте Event Monitoring і надсилайте події в SIEM, перш ніж вони знадобляться. Перечитайте Аудит і моніторинг — не одне й те саме.

8. Менеджер просить Salesforce змінити юридичну назву клієнта, якою керує ERP. У ті самі хвилини хтось змінює її в ERP. Що має казати дизайн?

Що Salesforce просив, а не змінював: полем керує ERP. Визначте правило для колізій заздалегідь (перемагає ERP, відхилити, якщо значення змінилося, або розв’язує людина) і чи їдуть пов’язані поля разом. Перечитайте Захистіть керований запис.

9. Надходить запит людини на видалення. Команда планує почати з’ясовувати, де живуть її дані. У чому проблема?

Годинник уже цокає: за GDPR — один місяць, із можливістю продовжити ще на два для складних запитів. Карта копій має існувати ще до того, як надійде запит. Перечитайте Годинник цокає.

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

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (англійською, перевірено 2026-09-25): офіційний перелік цілей та їхньої ваги. Завжди перевіряйте актуальну версію, перш ніж записатися на іспит.
• Розділ «Додаткові матеріали» кожного модуля перелічує документацію Salesforce і закони, що стоять за фактами, з датою перевірки.