Качество данных и управление ими
Также доступно на 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 редактируемыми: гибридная золотая запись. И я знаю, что поле только для чтения на странице 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; детерминированное шифрование позволяет фильтровать; зашифрованные поля не могут управлять правилами общего доступа на основе критериев. (Шифрование — это средство контроля, а не соответствие требованиям)
- Я знаю, что не нужно копировать чувствительные данные рабочей среды в песочницы и что Data Mask заменяется на Data Mask & Seed. (Не копируйте риски рабочей среды в песочницу)
- Я знаю разницу между отслеживанием истории полей (до 20 полей на объект; 18 месяцев, 24 — только через API; для длинного текста фиксируется только факт редактирования) и Field Audit Trail (до 200 полей, хранится, пока вы ее не удалите). (История — тоже данные)
- Я знаю сроки хранения журналов Event Monitoring (1 день без дополнительного модуля для некоторых событий, 30 дней по умолчанию с ним, до 365 при продлении) и что события нужно выгружать в SIEM до того, как они понадобятся: платные журналы нельзя получить за период до начала контракта. (Аудит и мониторинг — не одно и то же)
За пределами экзамена
Заголовок раздела «За пределами экзамена »Экзамен — это пол, а не потолок. Вот привычки из этой главы, которые нужны архитектору, независимо от того, спросят ли о них когда-нибудь на экзамене.
- Политика без точки обеспечения — это по большей части пожелание.
- Владельцы устанавливают политику, архитекторы ее обеспечивают. Не придумывайте политику и не играйте в юриста.
- Управление данными никогда не завершено. Оно идет приливами и отливами; проектируйте обратную связь.
- Не полагайтесь на хорошее поведение. Постройте контроль: люди, интеграции и агенты — все ошибаются.
- Управляйте достаточно, а не всем.
- Сначала предотвращайте дорогие ошибки. Дубликат с двумя годами истории — это большая проблема.
- Различайте то, что читают люди, и то, на основе чего решают машины.
- Документируйте широко; классифицируйте осознанно.
- Дешевле всего управлять теми чувствительными данными, которые вы никогда не копировали.
- Согласие — это данные, и разрешение на использование данных должно быть представимо в виде данных.
- Прежде всего контролируйте, куда попадают персональные данные, потому что удаление — редкое и трудное дело.
- Соответствие требованиям — это не продукт.
- Сбор → Классификация → Защита → Использование → Хранение → Удаление → Аудит.
- Собирайте доказательства до того, как их кто-то попросит.
Ключевые термины
Заголовок раздела «Ключевые термины »| Термин | В одной строке |
|---|---|
| Управление данными (data governance) | Политики для данных и архитектура, которая делает их правдой |
| Владелец данных | Человек или подразделение, отвечающее за определенный вид данных |
| Стюард данных | Человек, который ежедневно поддерживает данные в здоровом состоянии |
| Хранитель данных (custodian) | Команда, которая эксплуатирует системы, где хранятся данные |
| RACI | Responsible, Accountable, Consulted, Informed (исполняет, отвечает, консультирует, информируется) |
| Предварительная запись | Запись, созданная до того, как ее приняла авторитетная система |
| Бизнес-словарь | Согласованные определения важных терминов бизнеса |
| Происхождение данных (lineage) | Откуда пришло значение и что с ним произошло по пути |
| Классификация данных | Пометка данных по чувствительности и категории соответствия требованиям, чтобы к ним применялись правильные средства контроля |
| Таксономия | Набор меток, которые организация использует для классификации данных |
| Персональные данные | Информация, которая идентифицирует человека или может быть с ним связана |
| Псевдонимизация | Замена идентификаторов при сохранении пути назад; данные остаются персональными |
| Анонимизация | Устранение разумной возможности идентифицировать человека |
| Модель данных согласия | Объекты Salesforce для согласия по человеку, каналу, точке контакта и цели |
| Право на забвение | Право человека, там, где его дает закон, на удаление своих персональных данных |
| Гибридная золотая запись | Одна запись с полями мастер-системы и собственными полями Salesforce, у каждого вида один источник |
| Бизнес- / технические метаданные | Что данные означают и кто ими владеет / как они устроены и как движутся |
| Field Audit Trail | Более долгая история полей: до 200 полей на объект, хранится до удаления |
| Event Monitoring | Журналы входов, выгрузок, вызовов API и просмотров, хранящиеся ограниченное время |
| SIEM | Хранилище для безопасности, где журналы событий хранятся и анализируются |
Проверьте себя
Заголовок раздела «Проверьте себя »Короткие сценарии в стиле курса. Решите, каким будет ваш ответ, прежде чем его открыть.
1. Политика говорит, что юридическое название клиента может менять только финансовый отдел. Команда планирует рассказать об этом на обучении. Чего не хватает?
Точки обеспечения. Обучение — это не контроль: используйте доступ на уровне полей, поле, которое пишет только интеграция, правило проверки или контролируемый процесс. Владельцы устанавливают политику; архитектор делает ее механически верной. Перечитайте Управление данными должно стать механическим.
2. Клиенты ведутся в ERP. Торговым представителям нужно сразу начинать продавать новым потенциальным клиентам. Как им это позволить, чтобы мастер-запись не создавали две системы?
Позвольте представителям создавать организацию с предварительным типом записи, а затем преобразуйте ее через контролируемый процесс: финансовый отдел утверждает, или интеграция отправляет ее в ERP, которая сопоставляет или создает клиента и возвращает авторитетный ID. Перечитайте Средний путь.
3. Новое обязательное поле заполняется значениями «N/A» и «999999». Что произошло и что вы сделали бы вместо этого?
Пользователей заставили отвечать раньше, чем они узнали ответ. Требуйте значение позже в процессе, пусть его предоставит другая система, используйте предварительное состояние или разрешите явное Unknown (неизвестно), когда это настоящий ответ. Перечитайте Не позволяйте обязательным полям создавать фальшивые данные.
4. Команда заменила имена токенами и говорит, что данные анонимизированы, поэтому запрос на удаление выполнен. Так ли это?
Нет, если токены можно связать обратно с человеком: это псевдонимизация, и данные остаются персональными. Точно скажите, что делает система и где хранится сопоставление, а решение, удовлетворяет ли это требованию, оставьте юристам. Перечитайте Анонимизированные, псевдонимизированные, зашифрованные, замаскированные.
5. Получатель согласен на SMS о доставке, но не на маркетинг. Как модель должна это хранить?
С помощью модели данных согласия, а не одного флажка: человек, канал (SMS), конкретный номер и цель использования данных (уведомления о доставке, не маркетинг). И решите, какая система авторитетна для согласия, чтобы отзыв доходил до каждой системы, которая на него опирается. Перечитайте Используйте модель, которую Salesforce уже построил.
6. Специалистам по соответствию требованиям нужно фильтровать отчеты по зашифрованному полю с номером социального страхования (Social Security). Поле использует схему шифрования по умолчанию. В чем проблема?
Вероятностное шифрование не позволяет фильтровать в предложениях 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 и законы, на которых основаны его факты, с датой проверки.
