[SSIS] Funzionalità bridge tra basi di dati diverse

giovedì 14 febbraio 2008 - 17.03

Defkon1 Profilo | Newbie

sto testando l'ambiente SSIS per un'applicazione enterprise e sto cercando di capire se il motore ETL è in grado di fornirmi funzionalità di bridge tra basi di dati diverse.

in pratica sto cercando di collegare l'applicativo ad altre basi di dati in modo continuativo, affinché l'applicazione Alfa possa passare a Beta delle anagrafiche e recuperare da Beta le elaborazioni giornaliere su tali dati.

ho provato a rimappare le entità semplici, e non ho trovato grossi problemi; ad esempio sono riuscito a far viaggiare i dati di AlfaDB.Workers alla mia BetaDB.Workers senza particolari intoppi.

il problema fondamentale è che AlfaDB monta nelle proprie tabelle delle chiavi alfanumeriche, mentre nel mio progetto ho previsto solo ed esclusivamente chiavi numeriche con identity. Nel trasferimento di entità complesse diventa quindi indispensabile poter mantenere l'integrità referenziale sulle foreign key, altrimenti i dati non saranno più coerenti.

SSIS è in grado di farlo?
Se sì, in che modo?
Se no, qualcuno ha nomi di software (ovviamente anche commerciali) che abbiano tale funzionalità?

alx_81 Profilo | Guru

Ciao Defkon1! Benvenuto su DotNetHell!

>sto testando l'ambiente SSIS per un'applicazione enterprise e sto cercando di capire se il motore ETL è in grado di fornirmi
>funzionalità di bridge tra basi di dati diverse.
Questo sicuro, ho anche usato spostare dati da oracle, office, db2 su as400, ecc..
>
>ho provato a rimappare le entità semplici, e non ho trovato grossi problemi; ad esempio sono riuscito a far viaggiare i dati di
>AlfaDB.Workers alla mia BetaDB.Workers senza particolari intoppi.
SSIS in questo ti semplifica molto la vita, e gli intoppi (almeno per quanto riguarda la mia esperienza) sono nati dal fatto che da una parte è un prodotto giovane, mentre dall'altra ci sono alcune "cosine" un pochino macchinose e dure da "mandar giù" per chi è abituato soprattutto con il vecchio DTS. Personalmente ritengo potentissimo il motore di SSIS e credo che la sua architettura porti in realtà tantissimi vantaggi in fase di porting di moli molto elevate di dati.
>
>il problema fondamentale è che AlfaDB monta nelle proprie tabelle delle chiavi alfanumeriche, mentre nel mio progetto ho previsto
>solo ed esclusivamente chiavi numeriche con identity. Nel trasferimento di entità complesse diventa quindi indispensabile poter mantenere l'integrità referenziale sulle foreign key, altrimenti i dati non saranno più coerenti.
Quello che dici è corretto. Per mantenere la coerenza tra i tuoi database è necessario mantenere valida la medesima integrità referenziale. Però, partendo da un'ipotetica base dati X arrivando ad una Y, se le chiavi cambiano, SSIS non può esserti di aiuto. Credo proprio che tu debba rimboccarti le maniche e tenere allineati i tuoi database. Quando passavo da una piattaforma ad un'altra (da una parte avevo chiavi alfanumeriche e dall'altra identity DB2 --> SQL Server 2005) utilizzavo la stessa chiave di partenza come chiave logica della tabella di destinazione e la chiave primaria surrogata della tabella di destinazione era comunque un identity. In questo modo, ragionavo sulla chiave logica per fare i lookup, le aggregazioni, ecc.. ed in base a quello, l'id che avevo dalla parte di sql server non aveva poi così tanta importanza. Le foreign key erano sempre legate alle chiavi surrogate (e quindi agli id), ma le informazioni e la logica di porting si basavano sulle chiavi logiche (sulle quali ovviamente creavo degli indici unique).

>Se no, qualcuno ha nomi di software (ovviamente anche commerciali)
>che abbiano tale funzionalità?
Sinceramente non ne conosco avendo sempre fatto a manina in fase di modellazione del database di destinazione.

Alx81 =)

http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

Defkon1 Profilo | Newbie

>Ciao Defkon1! Benvenuto su DotNetHell!

grazie, tra l'altro ti ho addato su skype... ;-)

> Quando passavo da una piattaforma ad un'altra
>(da una parte avevo chiavi alfanumeriche e dall'altra identity
>DB2 --> SQL Server 2005) utilizzavo la stessa chiave di partenza
>come chiave logica della tabella di destinazione e la chiave
>primaria surrogata della tabella di destinazione era comunque
>un identity. In questo modo, ragionavo sulla chiave logica per
>fare i lookup, le aggregazioni, ecc.. ed in base a quello, l'id
>che avevo dalla parte di sql server non aveva poi così tanta
>importanza. Le foreign key erano sempre legate alle chiavi surrogate
>(e quindi agli id), ma le informazioni e la logica di porting
>si basavano sulle chiavi logiche (sulle quali ovviamente creavo
>degli indici unique).

questa per me non può essere una strada praticabile, in quanto il mio software deve poter lavorare sia in modalità stand-alone, sia pescando i dati esternamente. Nella prima modalità di funzionamento pertanto non avrei chiavi (al di fuori dalle mie) su cui operare le logiche di FK...

credo proprio che dovrò mettere in piedi un metamotore di traduzione entità... :-(

alx_81 Profilo | Guru

>credo proprio che dovrò mettere in piedi un metamotore di traduzione
>entità... :-(
Potresti pensare ad uno strato su cui porre delle transcodifiche, e se non ci sono, usi solo le tue chiavi..

Alx81 =)

http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

Defkon1 Profilo | Newbie

infatti pensavo di mettere un mid-tier che (operando magari su business objects a questo punto) possa transcodificare le entità in ingresso e uscita dal sistema...
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2023
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5