Partager via


Entreposage de données et rapports

La réplication est souvent utilisée dans les applications d'entreposage de données et de création de rapports aux fins suivantes :

  • Consolider les données afin de pouvoir les transformer et les déplacer dans l'environnement d'entreposage de données.

  • Distribuer les données à des bases de données en lecture seule dans le cadre de la création de rapports.

  • Distribuer les données à une base de données de traitement analytique en ligne (OLAP).

Même si la réplication ne réplique pas les objets Microsoft SQL Server 2008 Analysis Services (SSAS) (par exemple, des dimensions ou des cubes), elle est souvent utilisée pour distribuer des données à partir de bases de données de traitement transactionnel en ligne (OLTP) vers des bases de données temporaires et des bases de données utilisées à des fins de rapports, d'aide à la décision et d'analyse.

Le diagramme suivant illustre une scénario classique de réplication de données d'un serveur de traitement en ligne vers un serveur de rapports et un serveur intermédiaire destiné à l'analyse OLAP et ROLAP.

Réplication de données vers un serveur de rapports

Exemple de la société 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 de bases de données AdventureWorks.

Adventure Works Cycles utilise l'entreposage des données et les rapports dans plusieurs services, dont la fabrication et les ressources humaines.

Le service de fabrication stocke des données historiques sur les vices de fabrication et toute une série d'autres mesures de performance et de qualité. Les données sont répliquées à partir des serveurs de l'usine de production vers un serveur intermédiaire hébergé au siège de la société. À partir de là, les données sont transformées et chargées dans des cubes OLAP à des fins d'analyse.

Le département des ressources humaines génère actuellement des rapports à l'aide d'une application tierce. Il est prévu de remplacer cette application par Reporting Services. Ils envisagent également de développer les fonctionnalités de rapport afin d'effectuer les types d'analyse suivants :

  • l'analyse des avantages sociaux et des indemnités, y compris l'impact des taux de change de devises étrangères ;

  • la planification des effectifs ;

  • des prévisions et des simulations du coût de la main d'œuvre.

Ils ont l'intention de mettre en ligne un nouveau serveur afin de gérer les besoins accrus de la société en matière de rapports. Les données des ressources humaines et d'autres services seront répliquées vers ce serveur de rapports en lecture seule central.

Conditions générales requises pour ce scénario

En règle générale, les applications d'entreposage de données et de rapports présentent les exigences suivantes, que la solution de réplication doit satisfaire :

  • Le système doit assurer la cohérence des transactions.

  • Il doit présenter une latence faible : les mises à jour effectuées sur le serveur de traitement en ligne doivent être rapidement transmises aux serveurs intermédiaires et de rapports.

  • Le système doit disposer d'un débit élevé : il doit être en mesure de gérer la réplication d'un gros volume de transactions.

  • La charge de traitement de la réplication sur le serveur de traitement en ligne doit être réduite au minimum.

  • Le flux des modifications des données doit être unidirectionnel : du serveur de traitement en ligne vers les serveurs intermédiaires et de rapports.

  • Les données requises sur les serveurs intermédiaires et de rapports peuvent représenter un sous-ensemble des données disponibles sur le serveur de traitement en ligne.

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

SQL Server utilise la terminologie de l'édition pour décrire les composants d'un système de réplication. Les composants incluent un serveur de publication, des abonnés, des publications, des articles et des abonnements.

Dans le diagramme ci-dessus, le serveur de traitement en ligne est le serveur de publication. Une partie ou l'ensemble des données hébergées sur le serveur de traitement en ligne sont incluses dans deux publications (l'une destinée au serveur intermédiaire et l'autre au serveur de rapports), chaque table de données représentant une article (les articles peuvent également être d'autres objets de base de données, par exemple des procédures stockées). Le serveur intermédiaire et le serveur de rapports sont les Abonnés à l'une des publications, chaque serveur recevant des données et un schéma en tant qu'abonnement. Pour plus d'informations sur les composants du système, consultez Présentation du modèle de publication de réplication.

SQL Server propose différents types de réplication adaptés aux diverses exigences des applications : la réplication de capture instantanée, la réplication transactionnelle et la réplication de fusion. Ce scénario met en œuvre la réplication transactionnelle, qui satisfait aux conditions décrites dans la section précédente. Pour plus d'informations sur la réplication transactionnelle, consultez Présentation de la réplication transactionnelle et Fonctionnement de la réplication transactionnelle.

Par sa conception, la réplication transactionnelle permet de satisfaire aux principales conditions de ce scénario :

  • Homogénéité des transactions

  • Latence faible

  • Débit élevé

  • Charge minimale

La principale option à prendre en compte dans ce scénario est le filtrage. La réplication transactionnelle permet de filtrer les colonnes et les lignes. De cette façon, le serveur intermédiaire et le serveur de rapports ne contiennent que les données requises par votre application. Pour plus d'informations, consultez Filtrage des données publiées.

Étapes de mise en œuvre de ce scénario

Pour mettre en œuvre ce scénario, vous devez commencer par créer une publication et des abonnements avant d'initialiser chaque abonnement. Cliquez sur les liens ci-dessous pour plus d'informations sur les différentes étapes :

Une fois que l'abonnement est initialisé et que les données commencent à circuler entre le serveur de publication et les Abonnés, reportez-vous aux rubriques suivantes pour en savoir plus sur les tâches d'analyse et d'administration courantes :