Используйте SSIS для миграции и нормализации базы данных

Question

У нас есть база данных MS Access, которую мы хотим перенести в базу данных SQL Server с новым дизайном БД. Часть приложения, которая использует базу данных SQL Server, уже написана.

Я оглянулся, чтобы выяснить, как наиболее просто выполнить этап миграции, и начал с Microsoft SQL Server Integration Services (SSIS). Теперь я дошел до того, что хочу разделить таблицу по вертикали по причинам нормализации.

Придуманный пример выглядит так

MS Access table человек

ID
Name
Street

Таблица SQL Server персона

id
name

Таблица SQL Server адрес

id
person_id
street

Как лучше всего выполнить эту задачу с SSIS? Столбцы идентификаторов являются столбцами идентификаторов (автоинкремент), поэтому я не могу вставить старый идентификатор. Как я могу поместить правильный внешний ключ person_id в таблицу адресов?

Может даже существовать таблица, которая должна быть разбита на три таблицы, где строка в table2 принадлежит table1, а строка в table3 принадлежит строке table2.

Является ли SSIS подходящим средством для этого?

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

Большинство данных решений включают множество ручных шагов и поэтому не подходят.

Answer 1

Для переноса таблиц Access в SQL Server используйте SSMA, а не мастер повышения из Access .
В вашем распоряжении будет гораздо больше инструментов.

Затем вы можете разбить ваши таблицы по очереди из SQL Server.
Я не уверен, есть ли какие-либо инструменты, которые могут помочь вам автоматически разделить ваши таблицы, по крайней мере, я не смог их найти, но это не так уж сложно сделать вручную, хотя объем работы зависит от того, как вы использовали исходные таблицы. в вашем коде VBA и формах в первую очередь.

Примечание:

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

Сколько адресов может иметь человек?
Если вы посчитаете домашний адрес, рабочий адрес, адрес доставки, адрес для выставления счета, это, вероятно, больше всего вам понадобится.
В этом случае лучше просто держать их в одной таблице. Нормализация этих данных просто потребует больше работы для рекомбинации и не принесет никакой пользы.
Конечно, бывают случаи, когда имеет смысл нормализовать, но я видел, как люди зашли в тупик с понятием (я тоже в этом виноват), а затем столкнулись с трудностями при построении более сложных запросов, чтобы объединить все это разделение данных, что усложняет разработку и обслуживание и часто приводит к снижению производительности в процессе.

Answer 2

Используйте задачу «Выполнить SQL» и напишите оператор самостоятельно.

Для родительской таблицы выполните Select into table from table..., а затем проделайте то же самое для остальных. Убедитесь, что вы установили идентификационную вставку на ON для родительской таблицы и повторно используете ваши старые идентификаторы. Это поможет вам сохранить целостность данных.

Answer 3

Доступ настолько удобен для пользователя, почему бы не нормализовать ваши таблицы в Access, а затем увеличить готовую структуру оттуда?

Answer 4

Вы также можете посмотреть на Jamie Thomson SSIS Normalizer компонент. Я только что узнал об этом сегодня (на самом деле еще не пробовал). Пример, который он публикует, очень похож на пример в вашем вопросе.

Answer 5

Я нашел другое решение, которое еще не было упомянуто и позволяет нам использовать все удобства и возможности задачи потока данных:

Если база данных назначения находится на локальном SQL Server, вы можете использовать задачу потока данных с назначением SQL Server вместо назначения OLE DB. Для места назначения SQL Server вы можете пометить опцию «сохранить идентификационные данные». (Я не знаю, правильны ли английские имена, потому что у нас есть немецкая версия.) При этом вы можете записать в идентификационные столбцы

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

Мы начинаем процесс с построения временной таблицы сопоставления со столбцами

new_id (identity)
old_id (int)
old_tablename (string)

Сначала мы заполняем все old_id для каждой таблицы, на которую ссылается внешний ключ в новой схеме. Значения new_id генерируются автоматически SQL Server.

Таким образом, мы можем использовать соединение для перевода из old_id в new_id, где это необходимо. Мы используем значения new_id, чтобы заполнить столбцы идентификаторов (первичный ключ) в новых таблицах с помощью параметра «сохранить идентификаторы» и можем просто найти их в нашей таблице сопоставления для внешних ключей путем объединения.