Intégration de données hétérogènes

Mis à jour : 14 avril 2006

De nombreuses entreprises et organisations disposent de données stockées dans des bases de données pour de nombreux fournisseurs. L'intégration de ces données est souvent un composant clé permettant aux systèmes d'une organisation de fonctionner ensemble. La réplication vous permet d'intégrer des données hétérogènes de deux manières :

• En utilisant Oracle comme source de données pouvant être répliquée sur des bases de données Microsoft SQL Server, IBM et Oracle.
• En utilisant SQL Server comme source de données pouvant être répliquée sur des bases de données IBM et Oracle.

Le type de configuration de réplication utilisé pour l'intégration de données hétérogènes dépend de la source et de la ou des destinations des données :

• Le diagramme suivant illustre la réplication de données de SQL Server sur IBM DB2 et Oracle.
  
• Le diagramme suivant illustre la réplication de données d'une base de données Oracle sur d'autres bases de données. Les données sont d'abord répliquées sur une base de données SQL Server et peuvent ensuite être répliquées sur d'autres bases de données y compris SQL Server, IBM DB2, et Oracle.
  

Exemple Adventure Works Cycles

Adventure Works Cycles est une société de fabrication fictive utilisée pour illustrer des scénarios et des concepts de base de données. Pour plus d'informations, consultez Exemples et exemples de base de données.

Adventure Works Cycles a récemment acquis la société mexicaine Importadores Neptuno pour tenter de développer leur infrastructure afin de soutenir la croissance prévue de la société. Importadores Neptuno utilise une base de données Oracle pour conserver les données de fabrication et financières. Cependant, des éléments essentiels de ces données doivent être partagés afin de conserver une planification précise et des données d'inventaire dans l'application de planification des ressources de fabrication (MRP) de Adventure Works Cycles.

Alors qu'il n'existe aucun plan actuel pour migrer les bases de données Importadores Neptuno, Adventure Works Cycles a besoin de transmettre et de recevoir des données tous les jours et de transférer ces informations sur leurs bases de données SQL Server de traitement transactionnel en ligne (OLTP) et de traitement analytique en ligne (OLAP). Adventure Works Cycles répliquera les données d'une base de données Oracle sur des bases de données SQL Server au bureau central.

Conditions communes requises pour ce scénario

Les applications qui impliquent l'intégration de données hétérogènes ont en général les conditions requises suivantes, qu'une solution de réplication appropriée doit résoudre :

• Le système doit permettre de répliquer les données entre les bases de données de différents fournisseurs.
• Le système doit maintenir la cohérence transactionnelle.
• Le traitement de la réplication ne doit nécessiter qu'une charge minimale sur le serveur source.
• Le système doit avoir une latence faible si la réplication de modifications incrémentielles est requise.
• Le système doit avoir un débit élevé si la réplication de modifications incrémentielles est requise : il doit pouvoir gérer la réplication d'un grand nombre de transactions.
• Les données requises sur les serveurs de destination peuvent être un sous-ensemble des données disponibles sur le serveur source.

Type de réplication à utiliser pour ce scénario

SQL Server utilise une métaphore de l'industrie de la publication pour décrire les composants du système de réplication. Les composants comprennent le serveur de publication, le serveur de distribution, les abonnés, les publications et articles, et les abonnements.

• Dans le premier diagramme ci-dessus, la base de données Oracle est le serveur de publication. Tout ou partie des données sur la base de données Oracle est incluse dans la publication, chaque table de données étant un article. Les données sont répliquées sur le premier SQL Server (configuré comme serveur de distribution), puis distribuées sur l'autre SQL Server et sur les bases de données IBM et Oracle. Chacune de ces bases de données est un Abonné à la publication et reçoit un schéma et des données comme abonnement.
• Dans le second diagramme ci-dessus, la base de données SQL Server est le serveur de publication, et les bases de données IBM et Oracle sont les abonnés.

Pour plus d'informations sur les composants du système, consultez Présentation du modèle de publication de réplication.

SQL Server offre différents types de réplication pour différents besoins d'application : la réplication de capture instantanée, la réplication transactionnelle et la réplication de fusion. Ce scénario est mieux implémenté avec les fonctionnalités de réplication hétérogène de la réplication de capture instantanée et/ou de la réplication transactionnelle, ces dernières étant particulièrement bien adaptées pour gérer les conditions requises soulignées dans la section précédente :

• Si votre application nécessite la réplication des modifications incrémentielles au fur et à mesure qu'elles se produisent, utilisez la réplication transactionnelle.
  Pour une publication Oracle, la réplication transactionnelle assure le suivi des modifications sur le serveur de publication à l'aide de déclencheurs et de tables de suivi des modifications. Pour plus d'informations sur la réplication transactionnelle, consultez Présentation de la réplication transactionnelle, Fonctionnement de la réplication transactionnelle et Flux de travail de réplication transactionnelle pour serveurs de publication Oracle.
• Si votre application nécessite que les données ne soient répliquées qu'une seule fois (par exemple lors de la migration de données), ou qu'elles soient mises à jour périodiquement plutôt qu'incrémentiellement, utilisez la réplication de capture instantanée.
  Comme la réplication de capture instantanée n'assure pas de suivi et ne délivre pas de modifications incrémentielles, les déclencheurs ne sont pas utilisés sur les tables publiées. Pour plus d'informations sur la réplication de capture instantanée, consultez Présentation de la réplication transactionnelle et Fonctionnement de la réplication transactionnelle.

Par défaut, la réplication de capture instantanée et transactionnelle abordent les conditions requises principales de ce scénario :

• Réplication entre bases de données de différents fournisseurs
• Homogénéité des transactions
• Charge minimale

La réplication transactionnelle aborde les conditions supplémentaires requises pour les systèmes nécessitant des mises à jour incrémentielles :

• Faible latence
• Débit élevé

L'option principale à considérer pour ce scénario est le filtrage. La réplication de capture instantanée et de réplication vous permettent de filtrer les colonnes et les lignes, afin que les tables des abonnés ne contiennent que les données nécessaires à votre application. Pour plus d'informations, consultez Filtrage des données publiées.

Étapes d'implémentation de ce scénario

Pour implémenter ces scénarios, vous devez d'abord créer une publication et des abonnements, puis initialiser chaque abonnement. Cliquez sur les liens ci-dessous pour plus d'informations.

• Publication Oracle :
  • Présentation de la publication Oracle
  • Configuration d'un serveur de publication Oracle
• Abonnés Oracle et IBM DB2 :
  • Abonnés non-SQL Server
  • Abonnés Oracle
  • Abonnés IBM DB2

Une fois que l'abonnement est initialisé et que les données circulent entre le serveur de publication et les abonnés, vous devrez peut-être consulter les rubriques suivantes afin d'obtenir des informations sur les tâches communes d'administration et d'analyse :

• Gestion de la réplication
• Stratégies de sauvegarde et de restauration de la réplication transactionnelle et de capture instantanée
• Sauvegarde et restauration des serveurs de publication Oracle
• Résolution des problèmes de réplication
• Dépannage des serveurs de publication Oracle
• Suppression de la réplication

Voir aussi

Autres ressources

Réplication des données dans un environnement de serveur à serveur

Aide et Informations

Assistance sur SQL Server 2005