Шаблон маппинга данных описывает, как каждое поле источника превращается в поле целевой системы: откуда берётся значение, какое преобразование разрешено и что делать, если значение нельзя использовать. Стрелка от «Идентификатор клиента» к «ID» — только начало. Её недостаточно для реализации и проверки импорта.
В примере ниже небольшой CSV-файл с клиентами переносится в новую таблицу. Мы разберём правила для полей, одну принятую запись, отклоняемые значения и универсальную карточку маппинга. Все организации и записи в примере вымышлены.
Что должно быть в описании соответствий полей
Начните с определений источника и целевой системы, а не только со снимков заголовков столбцов. Для каждого поля укажите тип данных, обязательность, преобразование, допустимые значения и обработку ошибок. Разместите исходные поля, правила и целевые поля на общем холсте для технических схем в Boardmix, чтобы поставщик и получатель данных обсуждали один и тот же маппинг.
Схема фиксирует договорённость о переносе данных. Сама миграция на ней не выполняется. Скрипт импорта или интеграционный инструмент должен реализовать правила и сформировать принятые и отложенные записи.
Различайте три связанных документа:
- ER-диаграмма описывает сущности, атрибуты и связи в модели данных.
- Диаграмма потоков данных показывает движение данных между процессами, хранилищами и внешними участниками.
- Маппинг «источник — приёмник» определяет, что происходит с отдельными полями при переносе.
Эти документы могут располагаться рядом, но связь между Клиентом и Заказом не объясняет разработчику, как преобразовать старый код статуса в новое значение.
Пример: пять полей при импорте клиентов
Предположим, старая система выгружает по одной строке на клиента. Новая система ожидает пять полей. Это однократный импорт в пустую таблицу, а не обновление или объединение с существующими записями.
| Поле исходного CSV | Целевое поле и тип | Значение |
|---|---|---|
| source_ref | customer_id — текст | Стабильный идентификатор клиента |
| company_label | display_name — текст | Название организации, которое видят пользователи |
| country | country_code — текст | Код из допустимого списка стран целевой системы |
| joined | joined_date — дата | Дата регистрации клиента без времени |
| state | account_status — текст | Признак активной или неактивной учётной записи |
В этом примере все пять целевых полей обязательны. Система принимает только коды стран GB, JP и ES, а также статусы active и inactive. Это намеренно короткие учебные списки, а не рекомендация ограничить реальную клиентскую базу тремя странами.
Идентификатор остаётся текстом, даже если состоит только из цифр. Преобразование «0017» в число 17 изменило бы идентификатор. Тип данных определяет смысл, а не только внешний вид значения.
Опишите преобразование и ошибку для каждого поля
| Соответствие | Преобразование | Отложить строку, если… |
|---|---|---|
| source_ref → customer_id | Убрать пробелы по краям; сохранить остальные символы, включая ведущие нули. | Результат пуст или встречается во входном файле более одного раза. |
| company_label → display_name | Убрать пробелы по краям; сохранить внутренние пробелы, написание и диакритические знаки. | Результат пуст. |
| country → country_code | После удаления пробелов по краям заменить United Kingdom → GB, Japan → JP, Spain → ES. | Значения нет в этом точном списке соответствий. |
| joined → joined_date | После удаления пробелов принять существующую календарную дату в формате YYYY-MM-DD. | Дата отсутствует, неоднозначна, невозможна или записана в другом формате. |
| state → account_status | После удаления пробелов заменить A → active, I → inactive. | Код отсутствует или отличается от A и I. |
В этом примере неизвестные значения не исправляются автоматически. Строка со строчной «a» откладывается, поскольку спецификация источника допускает только прописные A и I. Если команда хочет не учитывать регистр, нужно явно изменить правило и добавить соответствующий тест. Удобная настройка инструмента не должна сама определять эту политику.
Аналогично нельзя угадывать значение «03/09/26» по региональным настройкам компьютера, с которого запускается импорт. Эта запись может означать разные даты. Попросите владельца источника предоставить согласованный формат либо зафиксируйте известный формат источника до преобразования.
Сопоставление названий полей и преобразование типов — разные задачи. В документации Microsoft по маппингу схем и типов данных это различие показано на конкретном интеграционном инструменте. Настройки зависят от платформы, но ожидаемый результат нужно согласовать ещё до их выбора.
Проследите одну запись от входа до результата
Вот полная исходная запись. Кавычки помогают увидеть пробелы по краям; сами кавычки не входят в хранимые значения.
- source_ref: « 0017 »
- company_label: «Orion Studio »
- country: «United Kingdom»
- joined: «2026-09-03»
- state: «A»
Если ни у одной другой строки после удаления внешних пробелов не получается идентификатор 0017, принятая целевая запись будет такой:
- customer_id: «0017»
- display_name: «Orion Studio»
- country_code: «GB»
- joined_date: 2026-09-03
- account_status: «active»
Преобразование не разделяет название организации на части, не переводит его на английский и не превращает идентификатор в число. Это были бы дополнительные правила, а не безобидная очистка. Сохраните исходную строку в материалах импорта, чтобы каждый результат можно было связать с его источником.
Предусмотрите отложенные записи
Если маппинг показывает только успешные строки, важная часть работы остаётся неопределённой. В нашем примере ошибка в одном поле откладывает всю строку. Частичная запись клиента в целевую систему не попадает.
| Проблема на входе | Ожидаемое действие | Код причины |
|---|---|---|
| joined содержит «2026-02-30» | Отложить строку; не переносить дату на март. | INVALID_JOINED_DATE |
| country содержит «UK» | Отложить строку: такого значения нет в исходном списке примера. | UNMAPPED_COUNTRY |
| state пуст | Отложить строку; не считать учётную запись активной автоматически. | MISSING_STATUS |
| Две строки дают customer_id «0017» после удаления пробелов | Отложить обе, пока владелец источника не разберётся с дубликатом. | DUPLICATE_CUSTOMER_ID |
Код объясняет проблему, но в результате обработки также нужны ссылка на исходную строку и название поля. Не включайте лишние персональные данные в сообщения об ошибках. Для реальной миграции используйте разрешённые тестовые данные и принятые в организации настройки доступа, а не копируйте клиентские записи на открытую доску.
Обработку дубликатов нужно описать отдельно от преобразования полей. Правило «сохранить последнюю строку» кажется простым, но делает результат зависимым от порядка файла. Если правильная запись определяется проверенной меткой времени или другим бизнес-правилом, опишите и способ разрешения равенства. Без такого критерия лучше отложить конфликтующие записи, чем выбирать произвольно.
Карточка маппинга для каждого поля
Широкая таблица удобна для обзора множества полей, а небольшая карточка — для обсуждения сложного преобразования. В ней остаётся та же необходимая информация:
- Идентификатор: M-03
- Источник: customer_export.country, текст
- Приёмник: customer.country_code, обязательное текстовое поле
- Смысл: классификация страны, принятая в целевой системе
- Правило: убрать внешние пробелы; применить соответствия United Kingdom/GB, Japan/JP и Spain/ES
- Пустое или неизвестное значение: отложить всю исходную строку
- Пример: « Japan » становится «JP»; «JPN» откладывается
- К кому обращаться: к ответственному за значения стран в источнике
Если преобразование зависит от нескольких полей, перечислите их на одной карточке. Поле full_name, составленное из given_name и family_name, — не два независимых прямых соответствия. Вместе задайте порядок частей, разделители и поведение при отсутствии одной из частей. Для поиска значения в другой таблице укажите ключ и действия при нуле или нескольких совпадениях.
Разберите с командой успешный и ошибочный набор
На доске Boardmix расположите схему источника слева, а целевую схему справа. Между ними разместите карточки преобразований и подписанные связи. Принятую запись оставьте под основным потоком, а путь отложенных записей вынесите отдельно. Так становится ясно, в чём именно разногласие: в имени поля, его бизнес-смысле или некорректном значении.
Попросите владельца источника объяснить значения, а владельца целевой системы — её требования. Затем проведите примеры через каждое правило. Если один участник ожидает принятия «UK», а другой — откладывания строки, согласуйте справочник до запуска импорта.
При первой проверке реализации сопоставьте количество исходных строк с суммой принятых и отложенных. В этом примере каждая строка должна оказаться ровно в одной из двух групп. Сравните также идентификаторы и значения полей: правильные итоговые количества не обнаружат клиента, которому присвоили неверный статус.
Откройте Boardmix, чтобы составить и обсудить маппинг источника и целевой системы, а затем передайте согласованные правила и ожидаемые результаты разработчику миграции. Схема фиксирует договорённость; тест импорта показывает, соблюдает ли её реализация.
