Объединение нескольких баз данных Access в SQL Server

Question

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

Проблема в том, что при использовании мастера импорта / экспорта SQL Server первичные / внешние ключи не обновляются.Так, например, если один пользователь имеет эту таблицу:

1  Apple
2  Banana

, а другой пользователь имеет это:

1  Coconut
2  Cheeseburger

, результирующая таблица выглядит следующим образом:

1  Apple
2  Banana
1  Coconut
2  Cheeseburger

Аналогично, все, что ссылается на Banana по его первичному ключу (2), теперь ссылается и на Banana, и на Cheeseburger, что не сделает веганов очень счастливыми.

Есть ли способ автоматически обновлять ссылки на первичные / внешние ключи,импорт, кроме написания чрезвычайно длинного и сложного сценария импорта?

Answer 1

Закончилось создание проекта SSIS для этого. SSIS - это инструмент визуального программирования , созданный Microsoft (и часть их "Business Integration Studio", поставляемой с SQL Server) , предназначенный для решения именно таких проблем.

Answer 2

Почему бы не позволить Access использовать свой менеджер репликации для объединения баз данных? Это позволит вам определить конфликты и разрешить их перед импортом в SQL Server. Я вполне уверен, что он сохранит отношения с иностранными ключами. Если я правильно понимаю вашу ситуацию, и базы данных имеют одинаковую структуру с разными данными, вы можете загрузить объединенную базу данных в приложение и проверить данные перед переходом на SQL Server.

Какую версию Access вы используете? Вот ссылка на Access 2000. Используйте язык для настройки параметров поиска в соответствии с вашей версией.

http://technet.microsoft.com/en-us/library/cc751054.aspx

Answer 3

Нужна дополнительная информация о требованиях.

Мой основной вопрос: «Вам нужно сохранить оригинальный ключ записи?» например 1: яблоко в таблице T базы данных пользователей A; 1: кокос в таблице T пользовательской базы данных B. Предполагается, что таблица T имеет одинаковую структуру во всех экземплярах базы данных. Причины, по которым я могу предположить, что вы, возможно, захотите сохранить исходные данные: (а) у вас может быть требование ссылаться на исходные данные (возможно, визуальное представление для предыдущих отчетов), и / или (б) может существовать зависимость от данных в само приложение.

Если ответ «нет», то вы, вероятно, заинтересованы только в сохранении всех отдельных значений данных. Разрешить построение таблицы SQL с использованием нового ключа и ограничить поле таблицы SQL таким образом, чтобы оно содержало уникальные данные. Этот подход, похоже, сохраняет исходную структуру таблицы (но не исходное значение ключа или его «местоположение») и может быть достаточным для удовлетворения ваших требований.

Если ответ «да», я не вижу способа создания индекса, который бы сохранял указатель на исходную базу данных и ключ, который был создан в ее таблице T. Этот подход, по-видимому, требует модификации приложения.

Наилучший подход в этом случае, вероятно, состоит в том, чтобы разделить входящие данные на две таблицы: одну для идентификации базы данных и исходного ключа, другую для идентификации отдельных значений данных. Например: (база данных) таблица D содержит записи типа «A: 1: a», «A: 2: b», «B: 1: c», «B: 2: d», «B: 15: a». , '' C: 8: a '; (таблица данных) T1 содержит записи, такие как «a: яблоко», «b: банан», «c: кокос», «d: чизбургер», где «A» описывает исходное местоположение базы данных, «1 - исходное значение в location 'A,' и 'a' - это значение, которое приравнивает записи в таблице D и таблице T1. (В противном случае у вас есть много избыточных данных в одной таблице; например, A: 1: яблоко, B: 15: яблоко, C: 8: яблоко.) Кроме того, T1 имеет структуру, аналогичную исходной T, и кажется, что более полезный в приложении.

Answer 4

Если вам нужно сохранить их полностью разделенными, вам нужно назначить какой-нибудь столбец разделения для каждой таблицы. Есть ли причина, по которой ваш SQL Server должен иметь такую ​​же ссылочную целостность, что и Access? Вы просто импортируете в SQL Server отчеты только для чтения? В таком случае я бы не стал беспокоиться о РИ. Все запросы будут требовать partitionid / siteid / customerid. Вы могли бы применить это для доступа к одной сущности, оборачивая таблицы в UDF с табличным значением, для которого требовался partitionid. Для кросс-сайта, который не работает.

Если вы просто загружаете данные в SQL Server для составления отчетов, я бы также рассмотрел вопрос об изменении модели данных для поддержки отчетов (т. Е. Размерная модель иногда лучше, чем нормализованная модель) вместо того, чтобы беспокоиться об обработке транзакций.

Я думаю, нам нужно больше знать о базовых целях.