Словарь, происхождение и классификация

🌐 Также доступно на 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): откуда они пришли?
• Классификация: как с ними нужно обращаться?

Два вида метаданных

Метаданные бывают двух видов, и нужны оба. Бизнес-метаданные — это то, что данные означают для бизнеса: определение, владелец, правила использования, степень чувствительности. Технические метаданные — это то, как данные устроены и как движутся: объект и поле, тип и длина, имя API, схема, сопоставление одной системы с другой, происхождение от источника до цели. Имя API и тип поля говорят разработчику, как его использовать; его определение и владелец говорят всем остальным, стоит ли. Когда они расходятся или чего-то не хватает, именно там интеграции и отчеты начинают ошибаться.

Знать к экзамену. Отличайте бизнес-метаданные (смысл, определения, владелец, правила, чувствительность: бизнес-словарь и классификация) от технических метаданных (объекты, поля, типы, имена API, схемы, сопоставления и происхождение).

Начните со смысла

Глава 3 установила правило: у каждого поля есть описание. Не «Customer Status» для поля под названием Customer Status, а что-то вроде «Текущие коммерческие отношения партнера со Steve Trucking. Устанавливается из ERP после активации. Не использовать для квалификации потенциальных клиентов». Теперь я знаю, что оно означает, откуда берется и для чего его не использовать. Это начало бизнес-словаря: общих определений для данных, которые важны. Что такое клиент? Активный клиент? Что означает «Доставлено»? Что считается вовремя? Все это кажется очевидным, пока вы не соберете пять отделов в одной комнате: у финансов одно определение, у продаж другое, у операционного отдела третье, у хранилища четвертое, а кто-то построил дашборд на пятом. Проблема не в том, что никто не говорит по-английски. Проблема в том, что предприятие не договорилось о смысле.

Словарь может жить в таблице или в инструменте документирования, но его важные определения должны находиться рядом с тем местом, где люди используют данные. На платформе это описания полей, текст справки и метаданные классификации. В аналитике это еще важнее: «выручка» не может означать одно на дашборде руководства и другое в запросе аналитика. Для этого и нужен семантический слой, а семантические модели Data 360 хранят управляемые определения — метрики, измерения и связи — над физическими данными (Create a Semantic Model in Data 360 (opens in a new tab)). Технологии меняются; требование — нет: у важных данных должен быть согласованный смысл.

И начинайте со смысла, а не с технологии. Словарь, который начинается с объекта, поля, типа и имени API, документирует реализацию. Словарь, который начинается с бизнес-терминов, документирует предприятие:

Бизнес-термин	Значение	Где он представлен
Розничный партнер (Retail Partner)	Розничная компания, для которой Steve Trucking выполняет доставки по договору	Организация (Account) в Salesforce; клиент в финансовой ERP
Доставка (Delivery)	Одна доставка одному получателю, по одному адресу, в один день	Сегодня в RouteDesk; рабочий заказ, когда доставки переедут в Salesforce
Получатель (Recipient)	Человек, который получает доставку	Данные получателя в доставке
Доставлено (Delivered)	Выполнено в соответствии с согласованным операционным определением	Статус доставки
Доставка вовремя	Выполнена в пределах согласованного окна доставки	Производная метрика

Click to enlarge

Один смысл, много технических представлений.

Затем спросите, откуда это пришло

Когда я знаю, что означает значение, я хочу знать, откуда оно пришло. Это происхождение данных (lineage). Юридическое название партнера в 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 вычисляет риск опоздания доставки по положению грузовика, окну доставки и истории маршрута, а диспетчерская служба использует его, чтобы расставлять приоритеты. Откуда взялось «высокий»? Добавьте агента, который говорит получателю «ваша доставка задерживается», и вам нужно знать, на чем это было основано (grounding) и насколько свежими были данные. Чем дальше вы уходите от хранимых значений к вычисленным, унифицированным, спрогнозированным и сгенерированным, тем важнее происхождение.

Классификация отвечает на другой вопрос

Теперь: как с ними нужно обращаться? Имя получателя, адрес доставки, номер телефона, заметки к доставке, статус доставки, номер грузовика, распределительный центр, розничный партнер, фотография — они не одинаково чувствительны. «В пути к получателю» — это не номер телефона, а код распределительного центра — не фотография внутри чьего-то дома. 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 % классифицировано», а пользоваться этим никто не стал. Номер телефона получателя: да. Домашний адрес: да. Заметки к доставке, в которых могут быть коды от ворот и «во дворе собака»: да. Фотографии, на которых могут быть люди или дом: безусловно. Внутренняя отображаемая метка? Не туда нужно тратить энергию управления данными. Это не значит, что недокументированные поля допустимы. Это две разные работы: документирование — широкое; классификация — осознанная. Именно это сохраняет классификацию осмысленной.

Таксономия, которой люди могут пользоваться

Классификации нужен словарь — таксономия. Значения Salesforce по умолчанию: Public, Internal, Confidential, Restricted и MissionCritical; вашей организации могут понадобиться свои метки. Я их не предписываю. Делайте их понятными: если категорий 47 и никто за пределами команды по конфиденциальности не может отличить категорию 31 от 32, толку нет. Хорошая таксономия связывает метку с поведением. Если поле — это чувствительные персональные данные, кто может его видеть, может ли оно попасть в песочницу, покинуть регион, появиться в аналитике, как долго оно хранится, может ли агент его использовать? Вот теперь классификация работает.

Классификация без обеспечения — лишь украшение

Пометьте номер телефона получателя как чувствительный и больше ничего не меняйте — и вы написали документацию. Полезно, но управление данными идет дальше: классификация должна управлять разрешениями, маскированием, шифрованием, хранением, согласием, перемещением данных, использованием песочниц, аудитом и доступом ИИ. Часть этого — решение архитектора при проектировании; некоторые платформы теперь применяют теги и классификации прямо в политиках, как это делает управление данными в Data 360 (Data Governance in Data 360 (opens in a new tab)). И пометка поля как Restricted никому не мешает его читать. Классификация говорит, как нужно обращаться с полем; безопасность делает так, чтобы так и было. Последовательность такая: определите данные, поймите их, классифицируйте важное, а затем примените средства контроля, которых требует классификация.

Click to enlarge

Три вопроса о ваших данных, и третий должен чем-то управлять.

Справочным данным тоже нужны метаданные

Коды стран, статусы доставки, коды распределительных центров, идентификаторы партнеров, причины отмены: они выглядят простыми, пока две системы не начнут расходиться. Одна говорит CANCELLED, другая CANCELED, третья CNCL, четвертая 9. Справочным данным нужны определения, владелец, источник, жизненный цикл на случай изменения значений и сопоставления, когда системы представляют их по-разному. Маленькие значения могут управлять очень большими процессами. Глава 6 идет дальше.

Все три вместе

Возьмем номер телефона получателя. Словарь: номер, по которому можно связаться с человеком, получающим конкретную доставку. Происхождение: из манифеста розничного партнера. Классификация: персональные данные. Теперь можно задавать архитектурные вопросы: может ли бригада его видеть и как долго (в брифе сказано: только для своих остановок и только в день доставки); может ли он попасть в песочницу; нужен ли он Snowflake; может ли агент его использовать; что происходит, когда доставка выполнена?

Теперь возьмем статус доставки. Словарь: текущее операционное состояние доставки. Происхождение: устанавливается процессом доставки Steve Trucking и отправляется обратно каждому партнеру через его собственную интеграцию. Классификация: операционные данные, не чувствительные. Другие данные — другое обращение. В этом и смысл.

Я не отношусь к метаданным как к документации, которую составляют после того, как настоящая архитектура готова. Если я не могу сказать, что означает поле, я не понимаю модель данных. Если я не знаю, откуда пришло значение, я не понимаю интеграции. Если я не знаю, чувствительно ли оно, я не понимаю безопасность. Метаданные описывают архитектуру, а иногда и управляют ею.

За пределами экзамена: что меняет ИИ. Классификация становится переключателем того, что агент может извлекать или повторять, а происхождение должно дотягиваться до ответа или действия агента. Если агент говорит получателю, что доставка задерживается, архитектура должна быть способна сказать, на чем это было основано, откуда это пришло и было ли агенту разрешено это использовать. «Где-то в Salesforce» — это не происхождение, а «данные клиентов» — не классификация.

Что здесь решает архитектор

• Каким бизнес-терминам нужны управляемые определения, чтобы системы и команды не вкладывали в одно слово разный смысл.
• Как важные значения сохраняют достаточно сведений о происхождении, чтобы показать свой источник, полномочия и преобразования.
• Какие поля несут смысл чувствительности или соответствия требованиям и поэтому получают явную классификацию.
• Какую таксономию использует организация и могут ли люди применять ее последовательно.
• Как классификация управляет реальными средствами контроля, а не лежит без дела.

Прежде чем управлять данными, знайте, что у вас есть: что они означают, откуда пришли, как с ними нужно обращаться. Документируйте широко, классифицируйте осознанно, сохраняйте происхождение там, где это важно. Иначе вы не управляете данными. Вы просто ими располагаете.

Дополнительно

• 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).