views:

1434

answers:

5

We have an MS Access database that we want to migrate to a SQL Server Database with a new DB design. A part of the application that uses the SQL Server DB is already written.

I looked around to find out how to do the migration step most easily and started with Microsofts SQL Server Integration Services (SSIS). Now I have gotten to the point that I want to split a table vertically for normalization reasons.

A made up example looks like this

MS Access table person

ID
Name
Street

SQL Server table person

id
name

SQL Server table address

id
person_id
street

How can I complete this task best with SSIS? The id columns are identity (autoincrement) columns, so I cannot insert the old ID. How can I put the correct person_id foreign key in the address table?

There might even be a table which has to be broken up into three tables, where a row in table2 belongs to table1 and a row in table3 belongs to a row table2.

Is SSIS the appropriate means for this?

EDIT Although this is a one-time migration, we need to have an automated and repeatable process, because the production database is under heavy usage and we are working on the migration in our development environment with recent, but not up-to-date data. We plan for one test run of the migration and have the customer review the behaviour. If everything is fine, we will go for the real migration.

Most of the given solutions include lots of manual steps and are thus not appropriate.

+3  A: 

Use the execute SQL Task and write the statement yourself.

For the parent table do Select into table from table... then do the same for the rest as you progress. Make sure you set identity insert to ON for the parent table and reuse your old ID's. That will help you keep your data integrity.

Eppz
That is a good idea, but if I get it right, I need to import the Access DB into SQL Server first!? There is no source and destination connection for an SQL Task.
GrGr
Yes - a lot of times it's better to import the original tables first and then do the manipulations all in SQL Server
DJ
true, so import the access db first, but set all the table names to something else so that you can remove them once you've split up your data.
Eppz
+3  A: 

For migrating your Access tables into SQL Server, use SSMA, not the Upsizing Wizard from Access.
You'll get a lot more tools at your disposal.

You can then break up your tables one by one from within SQL Server.
I'm not sure if there are any tools that can help you split your tables automatically, at least I couldn't find any, but it's not too difficult to do manually although how much work is required depends on how you used the original tables in your VBA code and forms in the first place.

A side note

Regarding normalization, don't go overboard with it: I know your example was just that but normalizing customer addresses is not always (rarely?) needed.

How many addresses can a person have?
If you count a home address, business address, delivery address, billing address, that's probably the most you'll ever need.
In that case, it's better to just keep them in the same table. Normalizing that data will just require more work to recombine and offers no benefit.
Of course, there are cases where it would make sense to normalise but I've seen people going overboard with the notion (I've been guilty of it as well) and then find themselves struggling to build more complex queries to join all that split data, making development and maintenance harder and often suffering a performance penalty in the process.

Renaud Bompuis
The side note is true and I am aware of it. Concerning the addresses, it is the other way around. We have five different entities which have addresses, all stored within the entities table. We want to unify that and allow for easy copy of addresses between entities.
GrGr
I just saw, that my made up example suggests that we want to have many addresses for one person and not that we have some address for multiple entities. But as you said. The example was just that.
GrGr
+1  A: 

Access is so user-friendly, why not normalize your tables in Access, and then upsize the finished structure from there?

David-W-Fenton
We want to have a repeatable / automated process for the migration. I cannot see, how to do this within Access.
GrGr
Access happens to have a rather flexible programming language that should allow you to do whatever you need. Of course, you might have some different language that makes it easier for you to automate it in some other database.
David-W-Fenton
A: 

I found a different solution which was not mentioned yet and allows us to use all the comfort and options of the dataflow task:

If the destination database is on a local SQL Server, you can use a dataflow task with SQL Server destination instead of an OLE DB destination. For a SQL Server destination you can mark the "keep identities" option. (I do not know if the english names are correct, because we have a german version.) With this you can write into identity columns

We found that we cannot use the old primary keys everywhere, because we have some tables that take a union of records from multiple tables.

We start the process by building a temporary mapping table with columns

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

We first fill in all the old_id s for every table that is referenced by a foreign key in the new schema. The new_id values are generated automatically by SQL Server.

So we can use a join to translate from old_id to new_id where needed. We use the new_id values to fill the identity (primary key) columns in the new tables with the "keep identities" option and can simply look them up in our mapping table for the foreign keys by a join.

GrGr
A: 

You might also look at Jamie Thomson's SSIS Normalizer component. I just found out about it today (haven't actually tried it yet). The example he posts looks a lot like the one in your question.

ranomore