Как сопоставить поля двух таблиц с помощью ИИ

Как сопоставить поля двух таблиц с помощью ИИ: выгрузите обе схемы и образцы строк, опишите правила владельца данных, попросите модель построить карту source-to-target с типами, преобразованиями, политикой пустот и списком открытых вопросов, затем проверьте каждое соответствие вручную по исходнику. Готовый документ описывает перенос и остаётся проектом: запись в базу выполняется отдельно и под контролем человека.

Назначение карты переноса и её границы

Итоговый документ — карта source-to-target. В ней для каждого поля исходной таблицы указано, куда оно попадает в целевой, каким типом там представлено, какое преобразование применяется, что делать с пустотой и какой справочник подставляет осмысленное значение. Airbyte в своём руководстве по data mapping описывает назначение такой работы через понимание потока данных, качество данных и поддержку требований управления и соответствия. Там же сказано, что сопоставление связывает элементы данных между источниками и системами и обеспечивает аккуратное перемещение данных при миграциях и интеграциях. Это описание задачи, которую решает документ.

Границы важнее полноты. Карта описывает соответствия, типы, преобразования, пропуски и неизвестные коды. Она не пишет в базу автоматически и не подменяет семантику сходством названий: поле status_code и поле status похожи буквами, а означают разные вещи, пока справочник не подтвердил связь. Airbyte отдельно отмечает, что современные платформы с ИИ обнаруживают дрейф схемы, предлагают совпадения полей и адаптируют сопоставления по мере изменения структур. Предложение совпадения остаётся предложением, которое принимает человек.

Документация Azure Data Factory по сопоставлению схемы и типов в действии копирования описывает два режима. При сопоставлении по умолчанию имена полей сопоставляются с учётом регистра; если приёмник не существует, имена исходных полей становятся именами приёмника, а если приёмник уже есть, он обязан содержать все копируемые колонки. Такое сопоставление поддерживает гибкие схемы и дрейф схемы от запуска к запуску. Явное сопоставление позволяет скопировать часть исходных данных, сопоставить поля с другими именами и изменить форму табличных или иерархических данных. Эти два режима задают развилку: автоматика по именам работает на совпадающих названиях, ручная карта нужна там, где имена и единицы расходятся.

Ещё одна граница — единицы измерения. Документация AWS Database Migration Service по правилам трансформации перечисляет поддерживаемые типы данных для преобразования колонок, включая bytes, date, time, datetime, int1, int2, int4, int8, numeric, real4, real8, string, uint1, uint2, uint4, uint8, wstring, blob, nclob, clob, boolean, set, list, map, tuple. Там же указано, что преобразование между типами возможно только в поддерживаемых форматах: дата представляется как YYYY:MM:DD или YYYY-MM-DD, дата-время — как YYYY:MM:DD HH:MM:SS или YYYY-MM-DD HH:MM:SS, время — как HH:MM:SS. Карта обязана фиксировать формат строкой, иначе перенос упрётся в разбор.

Третья граница — запрет на автоматическую запись. Документация AWS DMS предупреждает, что использование одной и той же таблицы как источника и приёмника в правиле трансформации ведёт к неожиданным и потенциально вредным результатам, включая непреднамеренные изменения данных таблицы, модификацию структур и удаление таблиц. Карта переноса — документ согласования. Исполнение отдельно, с правами, бэкапом и точкой возврата.

Сбор и проверка исходных данных

Работа начинается с двух схем и небольшого набора строк. Схема A в учебном примере: order_no, created_local, total_kopeks, status_code. Схема B: id, created_at_utc, total_rub, status. Четыре поля против четырёх, и ни одно имя не совпадает буквально. Это типичная ситуация, в которой автоматическое сопоставление по именам даёт пустой или неверный результат, а модель с описанием правил справляется.

Правила владельца данных нужно записать до обращения к модели. В учебном примере они такие: исходная дата хранится в московском времени, смещение UTC+3; сумма хранится целыми копейками; статусы закодированы числами, где 1 — new, 2 — paid, 9 — cancelled. Без этих трёх строк модель начнёт угадывать: решит, что дата уже в UTC, что сумма в рублях, что код статуса читается по смыслу числа. Документация Airbyte называет среди ключевых целей сопоставления обеспечение качества данных и поддержку управления и соответствия; качество начинается с явного описания единиц и справочников.

Образцы строк показывают конкретные значения и помогают проверить объявленные типы. Возьмите по пять-десять строк из каждой таблицы, включая краевые случаи: пустую дату, неизвестный код статуса, ноль в сумме, длинное значение идентификатора. В учебном примере входная строка выглядит как A17|2026-11-11 09:00|12345|2. Из неё видно, что дата записана без указания зоны, сумма — целое число без разделителя, статус — одна цифра.

Проверка исходных данных до модели включает четыре шага. Первый: убедитесь, что выгрузка содержит заголовки колонок. Документация Azure Data Factory отмечает, что для копирования данных из текстовых файлов с разделителями без строки заголовка колонки представляются порядковым номером вместо имени. Если заголовков нет, карта строится по позициям, и это надо зафиксировать. Второй: проверьте кодировку и разделитель. Третий: посчитайте строки и убедитесь, что выгрузка не обрезана. Четвёртый: сохраните исходник без изменений — он понадобится для ручной сверки результата.

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

Готовый учебный артефакт: карта A → B

Ниже — заполненная карта для учебного примера. Она описывает перенос четырёх полей, содержит преобразования, политику пустот, справочник статусов и открытые вопросы. Значения условные и служат образцом формы, которую читатель наполняет своими данными. Политики отправки пустых и отрицательных значений на разбор предложены для этого учебного проекта и требуют согласования с владельцем. Они не описывают уже включённые ограничения базы.

Ожидаемый выход для входной строки A17|2026-11-11 09:00|12345|2 — A17|2026-11-11T06:00:00Z|123.45|paid. Разберём каждое преобразование. Идентификатор A17 переносится без изменений, потому что правило владельца задаёт прямое соответствие order_no → id. Дата 2026-11-11 09:00 записана в московском времени; вычитание трёх часов даёт 2026-11-11 06:00, а формат целевого поля требует суффикс Z, который обозначает UTC. Сумма 12345 хранится целыми копейками; деление на сто даёт 123.45 рубля. Код 2 по справочнику превращается в paid.

Документация Azure Data Factory описывает явное сопоставление как способ скопировать часть исходных данных, сопоставить поля с разными именами и изменить форму табличных или иерархических данных. Наша карта делает ровно это: четыре поля с разными именами, два преобразования и один справочник. Для иерархических источников та же документация упоминает выражение JSON path для каждого поля, которое нужно извлечь или сопоставить, и отдельно описывает случай, когда несколько объектов с одинаковым шаблоном из массива разворачиваются в несколько записей табличного результата. Если ваши таблицы приходят из REST или документной базы, карта дополняется путями, и это отдельный столбец.

Altova MapForce, графический инструмент сопоставления данных, в описании на своём сайте указывает, что проект сопоставления может иметь несколько входов и несколько выходов и объединять совершенно разные типы данных. Там же сказано, что интерфейс включает панель проектирования, где сопоставление задаётся графически, добавляются функции и фильтры, а соединения протягиваются между исходным и целевым форматами. Для читателя это альтернативный способ зафиксировать ту же карту: таблица в документе либо схема в графическом редакторе. Таблица переносима в текстовый файл и в систему контроля версий, схема нагляднее для сложных ветвлений.

Копируемый промпт с указанными входами

Промпт ниже просит модель построить карту по описанным входам. Он требует перечислить источник, цель, тип, преобразование, политику пустот, справочник, проверку и открытый вопрос, взять единицы и часовой пояс из описания, показать ожидаемый выход для конкретной строки и оставить неизвестный код без преобразования.

Ты готовишь карту переноса полей между двумя таблицами.

Схема A (источник): order_no, created_local, total_kopeks, status_code.
Схема B (цель): id, created_at_utc, total_rub, status.

Учебная исходная строка A: A17|2026-11-11 09:00|12345|2.
В указанной строке секунды равны нулю; целевое время представь в UTC как YYYY-MM-DDTHH:MM:SSZ.
Пустую дату отправляй на разбор, сохраняя исходник; отсутствующее значение не угадывай.

Правила владельца данных:
- created_local хранится в московском времени, смещение UTC+3;
- total_kopeks хранится целыми копейками;
- status_code: 1 = new, 2 = paid, 9 = cancelled.

Построй таблицу со столбцами: source, target, type, transform, null policy,
lookup, validation, open question.
Единицы измерения и часовой пояс бери из описания выше.
Для каждой строки укажи ожидаемый выход.
Не преобразуй код, которого нет в справочнике: отправь строку на разбор.
Не пиши в базу и не предлагай автоматическое исполнение.
В конце перечисли открытые вопросы, ответы на которые нужны от владельца данных.

Что менять под себя: списки полей в схемах A и B, правила владельца, набор кодов справочника. Если целевое поле имеет ограничение длины, добавьте его в правила и в столбец проверки. Если источник иерархический, добавьте путь к полю и укажите это в правилах.

Вариации той же задачи:

• Промпт для сверки двух карт: подайте две карты, построенные разными людьми, и попросите перечислить расхождения по каждому полю с указанием, какая карта что утверждает.
• Промпт для проверки типов: подайте карту и список типов целевой базы, попросите отметить преобразования, которые могут потерять точность или переполнить тип.
• Промпт для поиска пустот: подайте карту и образцы строк, попросите перечислить поля, где пустота встречается, и предложить политику для каждого случая.
• Промпт для неизвестных кодов: подайте справочник и список встреченных кодов, попросите выделить коды вне справочника и сформулировать вопрос владельцу данных.
• Промпт для обратного переноса: попросите построить карту B → A и отметить преобразования, которые не восстанавливаются однозначно.

Документация AWS DMS по правилам трансформации перечисляет действия, применимые к колонкам: add-column, include-column, remove-column, rename, convert-lowercase, convert-uppercase, add-prefix, remove-prefix, replace-prefix, add-suffix, remove-suffix, replace-suffix, define-primary-key, change-data-type, add-before-image-columns и три действия маскирования данных. Этот список полезен как словарь: если ваше преобразование не сводится ни к одному из действий, оно требует отдельного описания в карте. Там же указано, что имена таблиц и колонок в правилах трансформации чувствительны к регистру, а для Oracle и Db2 имена задаются в верхнем регистре.

Отрицательный пример и неизвестные данные

Разберём две ошибки, которые модель допускает охотно.

Первая ошибка — сумма. Модель видит total_kopeks со значением 12345 и целевое поле total_rub, после чего переносит число без деления. В карте появляется 12345 рублей вместо 123.45. Причина в том, что имя исходного поля содержит единицу измерения, а имя целевого — другую, и без явного правила модель опирается на сходство основы слова. Лечится строкой правила: сумма хранится целыми копейками, целевое поле — в рублях, преобразование — деление на сто. Документация AWS DMS отдельно предупреждает, что преобразование между типами возможно только в поддерживаемых форматах, и приводит форматы даты, даты-времени и времени; для числовых единиц правило задаёт владелец данных.

Вторая ошибка — время. Модель видит created_local со значением 2026-11-11 09:00 и целевое поле created_at_utc, после чего оставляет 09:00Z. Суффикс Z означает UTC, и такая запись сдвигает событие на три часа вперёд относительно реального момента. Правильный выход — 2026-11-11T06:00:00Z. Причина ошибки в том, что исходное значение не содержит указания зоны, и модель достраивает её по умолчанию. Лечится строкой правила: исходная дата в московском времени, смещение UTC+3, преобразование — вычитание трёх часов.

Неизвестные данные обрабатываются отдельно от известных. В учебном примере код 7 отсутствует в справочнике, а пустая дата не поддаётся преобразованию. Оба случая отправляют строку на разбор: значение не угадывается, подстановка наугад запрещена. Это правило стоит в промпте прямой строкой. Документация Azure Data Factory описывает сопоставление по умолчанию, которое поддерживает дрейф схемы от запуска к запуску; Дрейф схемы относится к изменениям структуры, например новым колонкам или типам. Неизвестные значения кодов проверяются отдельно по справочнику; обе проверки нужно включить в карту.

Третья частая ошибка — подмена семантики сходством названий. Связь между status_code и status в этом примере подтверждается справочником владельца. Документация AWS DMS по правилам трансформации отмечает, что нельзя применять больше одного действия к одному объекту на одном уровне, за исключением маскирования данных и действий add-column, include-column и remove-column, которые сочетаются с другими. Если два правила меняют один и тот же атрибут колонки, результат зависит от версии движка: на 3.6.1 и новее применяется правило с большим rule-id, на более ранних версиях — с меньшим. Для карты это означает, что конфликтующие преобразования одного поля нужно свести в одно правило до исполнения.

Ручная проверка результата по исходнику

Для проверки откройте исходную выгрузку рядом с картой. Возьмите сохранённую выгрузку и для каждой строки пройдите цепочку преобразований вручную. В учебном примере цепочка короткая: A17 остаётся A17, 2026-11-11 09:00 минус три часа даёт 2026-11-11T06:00:00Z, 12345 делённое на сто даёт 123.45, 2 по справочнику даёт paid. Результат A17|2026-11-11T06:00:00Z|123.45|paid совпадает с ожидаемым выходом в карте.

Проверьте краевые строки отдельно. Строку с пустой датой отправьте на разбор без подстановки даты. Код 7 отправьте на разбор и сохраните в исходном виде. Нулевая сумма сохраняется числовым нулём; её нужно отличать от пропуска. Отрицательная сумма, если она встречается, требует решения владельца: сторно, возврат или ошибка выгрузки.

Сверьте количество строк. Сложите число строк, успешно прошедших преобразование, с числом строк, отправленных на разбор. Эта сумма должна совпасть с исходным количеством; каждая исходная строка учитывается ровно в одной группе. Расхождение означает, что часть строк потерялась на этапе фильтрации или соединения.

Проверьте типы на целевой стороне. Документация AWS DMS перечисляет поддерживаемые типы для преобразования колонок и указывает, что преобразование возможно только в поддерживаемых форматах. Если целевое поле имеет точность и масштаб, убедитесь, что преобразованное значение помещается. Документация Azure Data Factory отмечает, что промежуточный тип данных исходной или целевой колонки в общем случае не требует указания или изменения; это значит, что приведение типов берёт на себя инструмент, а карта фиксирует намерение.

Проверьте регистр имён. Документация AWS DMS указывает, что имена таблиц и колонок в правилах трансформации чувствительны к регистру, а для Oracle и Db2 имена задаются в верхнем регистре. Если целевая база чувствительна к регистру, id и ID — разные колонки, и карта должна называть их точно. Там же отмечено, что трансформации не поддерживаются для имён колонок с письмом справа налево и не выполняются для колонок со специальными символами в имени, например #, \, /, -. Такие поля попадают в отдельный список и переносятся без преобразования имени.

Наконец, проверьте, что карта не описывает запись в базу. Документ содержит соответствия, типы, преобразования, политику пустот, справочники и открытые вопросы. Исполнение — отдельный шаг с правами, бэкапом и проверкой на копии.

Сохранение и согласование результата

Карта сохраняется как текстовый файл в системе контроля версий. Формат — таблица с фиксированными столбцами, чтобы изменения читались построчно. Рядом с картой хранится исходная выгрузка, по которой шла проверка, и список открытых вопросов. Документация Airbyte описывает сопоставление данных как способ установить связи между элементами данных и поддерживать целостность на протяжении процесса; сохранённая карта делает эту целостность проверяемой при повторном запуске.

Согласование проходит по открытым вопросам. В учебном примере их четыре: есть ли дубли order_no, все ли строки записаны в московском времени, бывают ли отрицательные суммы, какие коды встречаются помимо 1, 2 и 9. Каждый вопрос адресуется владельцу данных, и ответ попадает в карту как правило. Пока ответа нет, соответствующее поле помечается как требующее ручного разбора.

Документация AWS DMS по правилам трансформации отмечает, что для существующей задачи действия, изменяющие схему целевой таблицы, такие как remove-column, rename или add-prefix, не вступают в силу до перезапуска задачи, а при возобновлении без перезапуска возможно неожиданное поведение изменённой колонки, вплоть до отсутствия данных. Если карта исполняется существующей задачей AWS DMS и новое правило меняет схему приёмника, применяется указанное требование перезапуска задачи. Для других инструментов порядок применения изменений проверяют по их документации. Карта версионируется вместе с правилами.

Документация Azure Data Factory указывает, что сопоставление настраивается в интерфейсе авторинга через действие копирования. Если вы переносите карту в инструмент, сверьте имена полей и порядок колонок с тем, что показывает интерфейс. Расхождение между документом и настройкой инструмента — источник ошибок при следующем запуске.

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

Частые вопросы

Чем карта переноса отличается от самого переноса данных?
Карта описывает соответствия полей, типы, преобразования, политику пустот и справочники. Перенос выполняет эти правила над данными и пишет результат в целевую таблицу. Карта согласуется и версионируется отдельно, перенос запускается после согласования и проверки на копии.

Что делать, если имена полей в таблицах совпадают, а смысл разный?
Сходство имён служит подсказкой для поиска кандидатов, а связь подтверждает владелец данных. Для каждой пары с совпадающим именем проверьте единицы измерения, формат даты, справочник значений и допустимые пустоты. Расхождение по любому пункту означает, что нужно явное преобразование.

Как ИИ предлагает соответствия полей?
Документация Airbyte отмечает, что современные платформы с ИИ обнаруживают дрейф схемы, предлагают совпадения полей и адаптируют сопоставления по мере изменения структур. Модель опирается на имена, типы и образцы значений. Предложение проверяется человеком, потому что сходство имён не подтверждает совпадение семантики.

Что делать с кодом, которого нет в справочнике?
Отправьте строку на разбор и оставьте значение без преобразования. Подстановка ближайшего известного кода искажает данные и скрывает проблему. Открытый вопрос владельцу данных фиксирует, какой код встретился и какое значение ему соответствует.

Как проверить карту перед исполнением?
Пройдите по исходной выгрузке вручную и сравните результат с ожидаемым выходом для каждой строки. Проверьте краевые случаи: пустые значения, неизвестные коды, ноль и отрицательные суммы. Сверьте количество строк до и после преобразования и убедитесь, что карта не содержит правил записи в базу.