Я понимаю, что вы спрашиваете, что если у вас есть поле в Схеме 1, такое как Customer.Country, в котором есть значения "США", "Канада" и "Мексика", вам нужен список всехстолбцы в схеме 2, которые имеют значения «США», «Канада» и «Мексика».Звучит правильно?
Исходя из моего понимания того, что вы спрашиваете, это может в значительной степени зависеть от того, какой тип картирования был сделан и насколько он сложен.Вот несколько примеров, основанных на некоторых проектах по изменению схемы, которые я видел:
Объединение : если в схеме 1 Shoe_Customers и Boot_Customers, а схема 2 объединяет их в одну таблицу клиентов, то находит картудля Shoe_Customers.Customer_Name придется искать подмножество значений в Customers.Name.Точно так же, если в схеме Schema 1 Customers.Country была заменена универсальной таблицей поиска стран на схеме 2, и кто-то заполнил эту таблицу полным списком стран, то вы бы искали подмножество для соответствия Customers.Country и Странам..Name (или они совпадают?).
Подмножество : При использовании противоположного подхода, если в Схеме 1 есть Клиенты, а в Схеме 2 это разделено на Shoe_Customers и Boot_Customers, то вы найдете только подмножество значений Схемы 1 в любомданный столбец схемы 2. Я не уверен, как бы вы определили здесь случай успеха.
Количество элементов : Если вы пытаетесь отследить довольно уникальные данные, например, «Клиент».Назовите, тогда у вас довольно высокие шансы на успех с помощью автоматизированного подхода.Все, что имеет низкий уровень кардинальности, может дать вам больше ложных указаний, чем вы того стоите.Если Gender равен M или F, а Discount_Code равен AZ, как и Sole_Style, Heel_Style и т. Д., То отслеживание этих данных с помощью автоматического сопоставления данных будет огромной тратой времени.Это ухудшится с числовыми данными, особенно с низкими показателями количества элементов, такими как проценты.
Изменения типов данных : Я предполагаю, что вы спрашиваете об этом, потому что это включает в себя сотни или тысячи изменений столбцов,с большим количеством данных.Если идея состоит в том, чтобы сравнить все «строковые данные» со всеми остальными «строковыми данными» и все «числовые данные» со всеми остальными «числовыми данными», то это будет масштабно.Если изменение схемы исключило изменения типа данных (например, недопустимо: Customer.Country был varchar (15), а теперь - Country.Name - varchar (50)), то у вас есть возможность выполнить задачу.
Это то, что приходит на ум в данный момент.Ваша ситуация может сделать все эти факторы неактуальными, или ваша ситуация может иметь эти факторы как только верхушку айсберга.Лично я немного скептически отношусь к полностью автоматизированному подходу для большинства ситуаций.Мое предложение было бы написать хранимую процедуру, которая принимает два имени таблицы / столбца, по одному от каждой схемы, и расскажет вам, какое покрытие значений схемы 1 имеется в схеме 2, охват значений схемы 2 в схеме 1, какой-то видизмерения кардинальности и т. д. В сочетании с небольшим влиянием человека вы сможете получить некоторую долю сопоставленных столбцов, вероятно, за меньшее время, чем полноценное универсальное решение с множеством тупиковых ситуаций.
Удачи,
Терри.