Sql-server – Distributed database implementation in sql server

Might be preferable to store PERS_INFO as a single table under the covers, so that the tables resulting from decomposition can be implemented as mappings to that. But current technology doesn’t give clean separation of physical storage from logical design.

He's talking about the dbms storing it as a single table, not you storing it as a single table.

The relational model itself says nothing about physical storage. It only requires that "the database be perceived by the user as tables. . . . At the physical level, in fact, the system is free to store the data any way it likes . . ." (An Introduction to Database Systems, 7th ed., CJ Date, p 61)

So Darwen is saying that if the database designer declares a set of 6NF tables, along with their

• candidate keys,
• distributed keys,
• foreign keys,
• foreign distributed keys,
• and so on,

then the dbms is free to

• implement that set of 6NF tables as a single table in a SQL tablespace,
• hide that single-table implementation from the user, and
• expose to the users a set of updatable views that are indistinguishable from the 6NF tables the database designer declared.

Having said all that, you might be able to work around the lack of dbms support by creating a single table on top of the covers (so to speak), and create a set of updatable views that are indistinguishable from your 6NF design. Revoke permissions on the single table, and require all users to use only the updatable views. What you can't do is have the dbms take care of all those details based solely on a series of logically correct, 6NF CREATE TABLE statements.

I have more than 8 databases and all are in a SQL Server environment. I need to extract data from specific tables (more than 50 tables) of each database and dump into a central database for reporting and analysis purposes (a one way transfer).

Table structures are the same in all databases.

REPLICATION : If the objects (tables) you are replicating are not undergoing frequent schema changes then you can use many-to-one replication using T-Rep (this is a very thorough answer that I wrote with scripts and end result), provided you can slightly modify your table schema. This will give you a near-to-realtime data transfer to your central server.

SSIS : If you dont need a near-to-realtime data transfer, then you can look into SSIS - Incremental load using Lookup transform as described in Updating Rows in Incremental Loads – Level 4 of the Stairway to Integration Services. ALso, refer to this excellent series : Stairway to Integration Services for more details. Alternatively, you can test out Change Data Capture (SSIS) (as @srutzky suggested).