Migration vers Analysis Services 2005 : Microsoft TechNet - SQL Server TechCenter

Paru le 19 août 2005

Par Michael Young, Proclarity Corporation, et Dave Wickert, Microsoft Corporation

Article technique SQL Server
S'applique à : SQL Server 2005

Résumé : Cet article vous guide tout au long du processus de migration vers Analysis Services dans SQL Server 2005. Le modèle dimensionnel unifié (UDM, Unified Dimensional Model) offre de nouvelles opportunités en matière de conception aux développeurs de cubes. Le modèle UDM associe les fonctions de génération de rapports relationnels et OLAP dans un environnement unifié, adapté aux deux types de requêtes de données. La compréhension des nouvelles options de conception et de leur impact sur votre entreprise permettra d'optimiser la migration. L'Assistant Migration est un outil rapide et performant pour le transfert de vos cubes existants vers Analysis Services 2005. Cet article en présente les fonctionnalités et vous permet ainsi d'en évaluer l'utilité dans votre contexte. Il est parfois préférable de redéfinir intégralement la conception du système pour tirer pleinement parti des nouvelles fonctionnalités d'Analysis Services 2005.

Sur cette page

À propos de Project REAL
Introduction
Problèmes de conception des cubes à prendre en compte dans la migration
Outils de migration
Migration vers Project REAL
Migration et redéfinition
Conclusion

À propos de Project REAL

Project REAL désigne une initiative destinée à faire connaître les bonnes pratiques de développement d'applications d'aide à la décision basées sur Microsoft® SQL Server™ 2005. Elle consiste à établir des mises en œuvre de référence à partir de cas observés chez les clients. Cette démarche implique de récupérer les données des clients et de les utiliser pour traiter des problèmes identiques à ceux qu'ils rencontrent lors du déploiement, à savoir :

• la conception des schémas ;

• la mise en œuvre d'un processus d'extraction, de transformation et de chargement de données (ETL - Extract Transform Load) ;

• le dimensionnement des systèmes pour la production ;

• la gestion et la maintenance en continu des systèmes.

L'utilisation de scénarios de déploiement réels permet un apprentissage complet des outils. Notre objectif est de traiter l'ensemble des problèmes auxquels sont confrontées les grandes entreprises durant le déploiement. Cet article décrit le rôle joué par la migration dans Project REAL. Project REAL s'appuie sur les données de deux clients utilisateurs d'applications d'aide à la décision de Microsoft. La phase 1 du projet a pris pour modèle un important distributeur de produits électroniques dont les informations relatives aux ventes et aux stocks sont conservées dans un Data Warehouse Microsoft SQL Server 2000. Les services DTS (Data Transformation Services) de SQL Server 2000 servent à gérer le flux de données vers la base de données relationnelle, et depuis celle-ci vers les cubes Analysis Services de SQL Server 2000 pour la production de rapports et la consultation interactive. Dans son entrepôt relationnel, ce client stocke environ 200 Go de données, qui sont toutes traitées ultérieurement dans des cubes Analysis Services. Lors de la mise en œuvre de la phase 1, l'accent est mis principalement sur les problèmes rencontrés par les utilisateurs de SQL Server 2000 lors de la migration vers SQL Server 2005. Nos résultats donnent une large part à la migration des fonctionnalités existantes, avec quelques fonctionnalités nouvelles, si nécessaire. Pour la migration d'Analysis Services, les données cubes ont été transférées vers Analysis Services 2005 en utilisant principalement l'Assistant Migration. Les cubes ont été dotés de fonctionnalités supplémentaires après leur migration vers la nouvelle version.

La phase 2 de Project REAL s'appuie sur le jeu de données plus étendu d'un autre client et exploite davantage de nouvelles fonctionnalités de SQL Server 2005 que la phase 1. En effet, la phase 2 porte essentiellement sur une nouvelle mise en œuvre d'une solution SQL Server 2005. L'objectif de la phase 2 était de faire la démonstration de nombreuses fonctionnalités nouvelles d'Analysis Services. Une redéfinition des cubes s'est avérée nécessaire en phase 2 et l'Assistant Migration n'a pas été utilisé. D'autres articles sur Project REAL seront disponibles ultérieurement.

Introduction

Analysis Services 2005 offre une approche innovante d'OLAP qui répond à toutes vos exigences en matière de production de rapports OLAP et de rapports relationnels. Avec Analysis Services 2005, la gestion des cubes devient moins prépondérante tandis que l'expérience de l'utilisateur final est valorisée. L'application du modèle dimensionnel unifié (UDM, Unified Dimension Modeling) à la conception permet de relier en toute transparence les environnements de production de rapports relationnels et OLAP. Cette approche a fondamentalement changé la manière de structurer les cubes.

Les nouvelles fonctionnalités d'Analysis Services 2005 permettent de mieux appréhender les modèles de navigation partagés. Elles répondent largement aux besoins en matière de production de rapports relationnels et OLAP. Elles traitent des types de données uniques et diminuent la surcharge de mémoire induite par la fourniture de données d'analyse.

Ce livre blanc vous guidera tout au long du processus de migration et vous permettra de déterminer le mode opératoire le mieux adapté à votre entreprise. Vous pouvez procéder à la migration en utilisant les outils intégrés à cet effet ou en redéfinissant les cubes existants. Cet article décrit les modifications apportées à la conception d'Analysis Services 2005 ainsi que leur impact sur votre structure de cubes actuelle.

Cet article présente les principales étapes de l'Assistant Migration. Il indique également les questions à se poser pour évaluer la pertinence de cet Assistant dans votre contexte.

Cet article permet de déterminer s'il est préférable d'utiliser l'Assistant Migration comme point de départ ou de redéfinir intégralement les cubes.

Problèmes de conception des cubes à prendre en compte dans la migration

Les cubes présents dans Analysis Services 2005 sont très différents de ceux des versions antérieures du produit. Lorsque la migration s'effectue à l'aide de l'Assistant Migration, Analysis Services tente de dupliquer vos cubes existants dans le nouvel environnement. Ceci permet d'accéder rapidement à la nouvelle plate-forme, mais sans pouvoir bénéficier de toutes les nouvelles fonctionnalités d'Analysis Services 2005.

Analysis Services 2005 introduit la notion de modèle dimensionnel unifié (UDM). L'UDM a pour fonction d'unifier les environnements de production de rapports relationnels et OLAP. Les environnements OLAP fournissent généralement des chemins de navigation parfaitement adaptés à l'extraction des données vers le haut et vers le bas. Les informations sont stockées sur différents niveaux. L'environnement relationnel convient parfaitement à la production de rapports qui n'imposent pas de contrainte de positionnement des champs.

Les rapports OLAP posent problème lorsque les champs pertinents pour les utilisateurs ne cadrent pas avec les hiérarchies définies par l'administrateur des cubes. Lorsque ces champs clés ne s'intègrent pas naturellement à d'autres champs dans la hiérarchie, comment peuvent-ils être englobés dans l'analyse ? Pour lever ces difficultés, l'entreprise peut adopter deux approches différentes, ayant en commun l'utilisation d'un outil OLAP et d'un outil relationnel, par exemple.

L' UDM résout le problème de l'intégration des rapports analytiques et relationnels à la source, en traitant tous les champs pertinents comme des attributs de première classe. L'UDM offre un niveau de flexibilité inégalé. L'UDM comprend plusieurs composants de haut niveau qui offrent une grande souplesse en matière de conception. En voici la liste :

• Hiérarchies d'attributs et hiérarchies définies par l'utilisateur

• Attributs liés

• Vues de sources de données

• Groupes de mesures

• Perspectives

Les paragraphes suivants décrivent l'impact de chacun de ces composants sur la conception des cubes dans Analysis Services 2005. Ceci vous permettra de déterminer le chemin de migration optimal.

Hiérarchies d'attributs

Analysis Services 2005 permet de créer des attributs à partir de tous les champs que vous souhaitez intégrer à l'analyse. Les attributs peuvent être ainsi exploités dans votre analyse ou dans un rapport relationnel. En outre, vous pouvez hiérarchiser les attributs afin de fournir un chemin de navigation. En matière de navigation, les hiérarchies d'attributs et les hiérarchies définies par l'utilisateur remplacent la notion de dimension présente dans Analysis Services 2000: C'est pourquoi les cubes comporteront souvent de très nombreuses hiérarchies d'attributs. En fait, les cubes volumineux et complexes peuvent contenir des centaines d'attributs. Dans Analysis Services 2000, il était souvent recommandé d'utiliser un ensemble de dimensions réduit, et ce pour deux raisons :

• Pour une gestion performante de la mémoire. Toutes les dimensions relevaient par défaut d'un stockage MOLAP, et chaque membre était chargé en mémoire. Le faible nombre de dimensions partagées a permis d'accélérer le traitement et le temps de réponse des requêtes.

• Pour enrichir le contexte mis à la disposition des utilisateurs. Les utilisateurs peuvent difficilement conceptualiser plus de six ou huit dimensions et gérer le contexte tout en extrayant les données vers le haut et le bas.

  L'UDM modifie radicalement cette situation. Tous les champs à faire figurer dans l'analyse peuvent être ajoutés en tant qu'attributs dans le cube, et le seront dans la plupart des cas. Il est alors possible de choisir plusieurs attributs et de les insérer dans des hiérarchies définies par l'utilisateur (hiérarchies traditionnelles, hiérarchies fortes, où plusieurs enfants sont rattachés à un seul parent, ou encore hiérarchies de navigation, dans lesquelles les attributs peuvent être positionnés sur différents chemins de navigation, indépendamment de la cardinalité entre parent et enfant). Cette méthode de conception offre les avantages suivants :

• Les champs peuvent être placés dans n'importe quelle partie du rapport ou de la vue des données. Il est très simple de prendre un champ et de le positionner sur des lignes et des colonnes indépendantes d'autres champs de la hiérarchie.

• Les cubes peuvent être plus représentatifs du Data Warehouse ou du magasin de données. Le cube Analysis Service 2005 peut contenir un grand nombre d'attributs, de hiérarchies définies par l'utilisateur et de mesures (provenant de plusieurs tables de faits), ce qui lui permet de représenter plus fidèlement les données sources.

• Les cubes peuvent contenir des données issues de plusieurs tables de dimension et de plusieurs tables de faits. Vous bénéficiez ainsi d'une liberté presque totale pour concevoir toutes sortes de cubes.

• Il est possible de définir des chemins de navigation pour tous les types de données. Les types de hiérarchies créés ne sont plus soumis à des limitations.

• Les propriétés de membre et les dimensions virtuelles ne sont plus nécessaires à la production de rapports. Pour doter les rapports de colonnes supplémentaires, les administrateurs des cubes Analysis Services 2000 étaient souvent tenus d'ajouter des propriétés de membre, puis des dimensions virtuelles. Cela n'est plus nécessaire, puisque les attributs constituent la base des analyses et de la production de rapports, et qu'ils sont généralement représentatifs d'une seule colonne.

Attributs liés

Le concept de propriétés de membre est plus développé dans Analysis Services 2005. La propriété de membre traditionnelle est désormais disponible sous forme de relation d'attribut. L'exécution d'une requête sur les propriétés de membre vous permettra d'obtenir, en plus des propriétés de membre traditionnelles, la totalité des relations d'attributs. Les relations d'attributs sont utilisées par l'Assistant Agrégation pour localiser les possibilités d'agrégation. Il sera nécessaire d'établir des relations d'attributs entre attributs organisés par niveau. Une hiérarchie client peut par exemple être constituée des niveaux Pays, Région, Département, Commune et Client. Le niveau Commune doit comporter un relation d'attribut avec le niveau Région pour que les fonctions d'agrégation soient pleinement exploitées. L'Assistant Formule utilise également les relations d'attributs afin de déterminer la meilleure manière d'effectuer un calcul.

Les propriétés de membre ont souvent été utilisées pour faciliter la production de rapports sous Analysis Services 2000. Pour afficher une colonne non comprise dans la hiérarchie, il était possible d'utiliser une propriété de membre qui en affichait la valeur. La propriété de membre pouvait être affichée sous la forme d'un membre calculé, de dimension virtuelle ou via un outil tiers qui la faisait apparaître en mode natif. Avec l'UDM, il n'est plus nécessaire de créer des propriétés de membre pour la production de rapports, puisque toute colonne pertinente peut aisément être ajoutée en tant qu'attribut. Ces attributs sont ensuite placés sur des lignes et des colonnes afin de faciliter les analyses.

Vues de sources de données

Analysis Services 2005 insère une couche d'abstraction supplémentaire entre le cube et la source de données. La vue de source de données permet d'établir une séparation logique entre le cube et ses sources de données. Une ou plusieurs sources de données peuvent être combinées dans une vue de source de données afin de fournir une représentation logique de ces données. La vue de source de données peut être soit une sélection de tables issues de sources de données, soit une requête nommée. La requête nommée est une instruction SQL que vous rédigerez pour charger les données comme vous le souhaitez (de manière semblable à une vue relationnelle, à cette différence près qu'une vue de source de données contient une requête nommée). Le cube est alors construit à partir de la vue de source de données.

Les vues de sources de données :

• fournissent une couche d'abstraction à partir des sources de données ;

• peuvent être constituées de différentes sources de données, telles que plusieurs bases de données sur le même serveur ou des bases de données de différents serveurs ;

• fournissent des requêtes nommées permettant d'écrire les requêtes utilisées par Analysis Services pour charger les données, ce qui peut servir à filtrer, à limiter ou à optimiser le chargement de données à partir de la source ;

• peuvent servir à renommer les données afin de fournir une couche d'affectation de noms distincte de la source réelle des données ;

• permettent à la représentation des clés logiques d'établir une relation entre les tables de faits et les tables de dimension ;

• prennent en charge les calculs nommés, qui contiennent chacun une expression utilisée pour définir la colonne ;

• fournissent une base de construction du cube.

Groupes de mesures

L'un des principaux points à aborder dans la définition de nouveaux cubes est le contexte de visualisation des données par l'utilisateur. Il est possible de construire un cube à partir de plusieurs tables de faits, dont chacune peut posséder plusieurs mesures et un niveau de granularité spécifique. Ainsi, le cube pourra comporter non seulement plusieurs centaines d'attributs, mais également des mesures issues de plusieurs tables de faits et représentatives de différents niveaux de granularité.

Supposons que vous disposiez d'un cube doté d'un groupe de mesures Ventes réelles applicable aux niveaux de détail Produit, Magasin, Clients et Jour (qui a acheté quoi, où et quand ?). Le cube est également doté d'un groupe de mesures Prévision applicable aux niveaux de détail Type de produit, Magasin et Mois (que vendra-t-on dans les prochains mois et où ?). De plus, il comporte un groupe de mesures Stock applicable aux niveaux de détail Produit, Magasin et Semaine (quelles quantités étaient disponibles, où et quand ?). Il est possible de visualiser les tendances en combinant ces trois groupes de mesures dans le même cube. Par exemple, les ruptures de stock ont-elles un impact sur les ventes et en quoi influent-elles sur les prévisions ? Il est possible d'obtenir des réponses à ces questions, car tous ces faits peuvent être combinés dans le même cube. Dans Analysis Services 2000, il fallait créer deux cubes et les combiner ensuite dans un cube virtuel. Dans Analysis Services 2005, il suffit d'un seul cube doté de plusieurs groupes de mesures (un groupe par table de faits).

Ce mode de fonctionnement offre une réelle souplesse au créateur du cube, mais ne fournit pas toujours le contexte attendu par les utilisateurs finals, qui ne sont pas, pour la plupart, familiarisés avec la structure des Data Warehouses ou des magasins de données. Les groupes de mesures peuvent servir à différencier les différents critères d'évaluation de façon à fournir un contexte significatif pour l'utilisateur. Des mesures de niveaux de granularité semblables peuvent être regroupées et traitées (sur le plan administratif) comme une seule entité. Par défaut, les groupes de mesures sont structurés en fonction de la table de faits dont ils sont issus. Les mesures extraites d'une même table de faits doivent présenter un niveau de granularité semblable. Toutes les mesures contenues dans une table de faits donnée appartiendront au même groupe de mesures. Les groupes de mesures procurent les avantages suivants :

• Les mesures peuvent provenir de plusieurs tables de faits.

• Les mesures peuvent être regroupées par granularité.

• Un seul cube de base peut comporter plusieurs niveaux de granularité.

• Il est possible d'appliquer un niveau de sécurité à des groupes de mesures spécifiques.

• Les groupes de mesures peuvent être présentés selon une ou plusieurs perspectives et associés selon des dimensions pertinentes pour l'utilisateur final. Les groupes de mesures permettent de fournir un contexte significatif pour l'utilisateur final.

Perspectives

Dans Analysis Services 2000, les cubes étaient souvent définis avec un nombre restreint de dimensions et un nombre fixe de mesures issues d'une seule table de faits. Pour ajouter des mesures de granularité multiple ou pour visualiser de nombreuses dimensions issues de différents cubes, il était possible de créer un cube virtuel combinant plusieurs cubes de base qui le faisaient paraître beaucoup plus volumineux. Vous étiez alors en mesure de constituer le résultat final. Ce processus permettait de résoudre les problèmes de granularité mais aussi de consommation de mémoire dans Analysis Services 2000.

L'UDM vient modifier cette situation. Un cube peut désormais comporter des centaines de hiérarchies d'attributs et de hiérarchies définies par l'utilisateur, ainsi que plusieurs groupes de mesures issus de différentes tables de faits. Ces caractéristiques apportent une grande souplesse à la conception des cubes. Néanmoins, le problème du contexte utilisateur reste entier. À un moment donné, il convient d'affiner la vue des données afin de la rendre significative pour l'utilisateur. La vue des données doit offrir un moyen simple à l'utilisateur de répondre aux besoins de son projet.

Les Perspectives fournissent un contexte à l'utilisateur final. Une perspective est un ensemble d'attributs, de hiérarchies définies par l'utilisateur, d'actions et de groupes de mesures que vous voulez regrouper sous forme de collection logique. Les perspectives fournissent une base pour les analyses ainsi qu'un contexte pour l'utilisateur. Comme les cubes sont souvent volumineux, avec de nombreuses mesures et des centaines d'attributs, vous devez créer un grand nombre de perspectives afin que les utilisateurs puissent interagir avec la collection de données pertinente pour leur activité. L'UDM est destiné aux administrateurs des cubes, tandis que les perspectives s'adressent aux utilisateurs finals. Les perspectives ne doivent pas servir à mettre en œuvre des mesures de sécurité.

Résumé des problématiques de conception

Dans Analysis Services 2005, les cubes peuvent comporter un grand nombre d'attributs, de hiérarchies définies par l'utilisateur et de mesures. L'UDM combine les meilleures fonctionnalités d'OLAP et des rapports relationnels pour vous offrir une liberté totale en matière de conception de cubes et parfois d'une couverture fonctionnelle bien plus étendue que les besoins exprimés par les utilisateurs. Les groupes de mesures et les perspectives peuvent vous servir à fournir un contexte significatif aux utilisateurs. Dans la plupart des cas, leur environnement de travail s'articulera essentiellement autour des perspectives.

Outils de migration

Analysis Services 2005 offre une série d'outils conçus pour vous assister tout au long du processus de migration. Lors de l'installation par défaut d'Analysis Services 2005 sur une machine déjà équipée d'Analysis Services 2000, vous êtes invité à exécuter l'Assistant Migration. Si vous choisissez de ne pas utiliser cet Assistant lors de l'installation, vous pourrez vous en servir ultérieurement comme outil autonome.

L'Assistant Migration permet de faire migrer un cube Analysis Services 2000 vers la nouvelle version ou de créer un script XMLA (XML for Analysis, XML pour l'analyse) en vue d'une migration ultérieure. Les Assistants sont des outils rapides et performants. Vous devrez déterminer si le résultat final correspond à vos attentes. Dans certains cas, l'Assistant Migration s'avère une bonne base de départ et, même s'il est parfois utile de redéfinir les cubes, il est néanmoins judicieux de lancer cet Assistant : le fait de voir comment procède l'Assistant pour convertir vos objets constituera déjà une expérience utile et enrichissante. Vous pouvez finalement décider de ne pas suivre les directives de l'Assistant Migration et de redéfinir les cubes à l'aide des Assistants de conception habituels. Cependant, vous aurez vu sa manière de procéder même si ses décisions finales ne vous conviennent pas.

Analysis Services 2005 intègre deux outils de migration. Le premier est l'option de migration mise en œuvre lors de l'installation d'Analysis Services 2005.

Le second est l'Assistant Migration, processus autonome exécuté comme l'un des principaux outils du groupe de programmes SQL Server 2005.

Assistant Migration

L'Assistant Migration s'efforce de dupliquer au mieux les cubes existants dans Analysis Services 2000. Son objectif n'est pas de fournir un cube Analysis Services 2005 conforme aux préconisations. La compréhension de cet état de fait rend les choix effectués par cet Assistant plus lisibles. Après avoir utilisé l'Assistant, il vous reste à déterminer les autres mesures à prendre pour mieux tirer parti de toutes les fonctionnalités d'Analysis Services 2005.

L'Assistant vous invite à sélectionner les bases de données OLAP à faire migrer. Après avoir sélectionné les bases de données OLAP, vous devez déterminer si vous souhaitez les faire migrer directement vers Analysis Services 2005 ou si préférez générer un script XMLA. Le script peut être lancé ultérieurement à partir de SQL Server Management Studio.

Lancement de l'Assistant Migration

1. Dans le groupe de programmes SQL Server 2005, ouvrez l'Assistant Migration. L'Assistant Migration est l'un des outils disponibles dans Analysis Services. L'Assistant doit s'afficher comme indiqué sur la figure 1.

   

   Figure 1 : L'Assistant Migration d'Analysis Services 2005 effectue la migration des cubes Analysis Services 2000.

2. Cliquez sur Suivant pour afficher la section relative aux pages Source et Destination de l'Assistant.

3. Spécifiez la source et la destination des données comme indiqué sur la figure 2. La source des données doit être votre instance Analysis Services 2000. Leur destination doit être la nouvelle instance Analysis Services 2005. Vous pouvez sélectionner un fichier de script plutôt qu'une destination. Dans ce cas, l'Assistant génèrera un script XMLA que vous pourrez exécuter ultérieurement pour créer vos cubes.

   

   Figure 2 : La migration sera basée sur la source et la destination des données que vous aurez indiquées.

4. Après avoir indiqué une source et une destination, cliquez sur Suivant. L'Assistant lit les métadonnées de votre source de données, puis affiche la fenêtre Select Databases to Migrate (Sélection des bases de données à faire migrer).

5. Sélectionnez les bases de données à faire migrer. Par défaut, le nom de la base de données destination est généré automatiquement. L'Assistant tente de créer une base de données portant le même nom. Si une base de données du même nom existe déjà, l'Assistant en génère un autre et ajoute à la fin de son nom une valeur incrémentale en commençant par 1. Pour fournir un nom, cliquez dans la cellule Destination database (Base de données destination) et entrez-en un comme indiqué sur la figure 3.

   

   Figure 3 : Vous pouvez attribuer à la base de données de destination le nom à utiliser dans Analysis Services 2005.

6. Après avoir entré les noms des bases de données à faire migrer et ceux des bases de données de destination, cliquez sur Suivant.

7. L'Assistant commence alors à valider les objets. Cette opération peut prendre un certain temps, en fonction de la quantité de métadonnées présentes dans les sources de données. Une fois les objets validés, l'Assistant affiche des messages d'avertissement et d'erreur relatifs aux données susceptibles de poser problème. Vous pouvez visualiser le détail des modifications apportées par l'Assistant à vos données. Si, par exemple, une dimension est renommée, un message d'avertissement indiquant son nouveau nom s'affiche. Les problèmes susceptibles de survenir durant l'exécution de l'Assistant Migration seront évoqués plus loin dans cet article.

   Vous pouvez utiliser les fonctions Afficher le journal et Enregistrer le journal pour visualiser les détails, les filtrer et les enregistrer à des fins de consultation ultérieure. Après avoir visualisé ces détails, cliquez sur Suivant.

8. La fenêtre Migrating Database (Migration de la base de données) s'affiche alors. L'Assistant effectue la migration et les métadonnées sont générées. Cependant, les données ne sont pas transférées. Il vous faudra traiter les nouveaux cubes pour y insérer des données.

9. Après avoir fait migrer les bases de données, cliquez sur Suivant pour terminer l'Assistant.

   Remarque :  une fois la migration des bases de données OLAP effectuée, les métadonnées du cube migrent vers Analysis Services 2005. Après cette migration, vous devrez traiter le cube. Les données seront ensuite chargées à partir de la source vers le cube et vous pourrez les consulter.

L'Assistant ne fait pas migrer les éléments suivants :

• partitions distantes ;

• cubes liés ;

• options d'extraction.

Au cours de la migration, l'Assistant fait correspondre les anciennes fonctionnalités avec les nouvelles selon certains critères. Il convient de prendre en compte les points suivants :

• Les propriétés de membre migrent vers des relations d'attributs. Il est à noter que l'expression relation d'attribut est principalement utilisée dans Business Intelligence Development Studio. Une requête adressée à l'API sur les propriétés de membre renverra toutes les relations d'attributs. En plus de l'ensemble de propriétés de membre d'origine, chaque niveau hiérarchique sera doté d'une relation d'attribut supplémentaire pour son niveau parent. Le moteur d'agrégation utilise la relation d'attribut pour relier vos points de données. Ces relations sont nécessaires aux calculs effectués lors des consolidations. Les attributs liés ne doivent pas être supprimés. Si vous avez ajouté d'autres propriétés de membre pour les besoins de la production de rapports, vous pouvez supprimer les attributs correspondant à ces rapports puisque leurs colonnes doivent également être définies comme des dimensions d'attribut.

• Des calculs nommés peuvent être créés à votre attention dans la vue de source de données. Ces derniers contiennent l'expression utilisée pour construire la colonne. Ils seront appelés colonnex (colonne1 étant le nom de la première colonne de chaque table). Cette situation se produit en présence d'un nom ou d'un identifiant de membre pour un niveau qui est obtenu à partir d'une expression dans Analysis Services 2000. Dans cet environnement, les zones de propriétés du nom et de l'identificateur de membre ont permis d'utiliser les déclarations SQL pour résoudre des problèmes tels que la concaténation. Celles-ci sont à présent stockées sous la forme d'expressions. Le cube Supermarché en offre un exemple dans sa dimension Clients. Lors de la migration, vous remarquerez qu'une nouvelle colonne, appelée Colonne1, apparaît dans la table Client (dans la vue de source de données et également ajoutée en tant qu'attribut). L'examen des propriétés permet de constater que la source est une concaténation des colonnes Prénom et Nom de famille.

• La quasi-totalité des colonnes de la source de données sont ajoutées en tant que dimensions d'attributs. Les colonnes non prises en compte sont celles dont le type de donnée est considéré par Analysis Service comme non pertinent : horodatage, identifiant_unique et table. Toutes les colonnes de type numérique, date et caractère sont des attributs ajoutés.

• Les cubes virtuels deviennent des cubes lors de la migration. Les groupes de mesures ne sont pas ajoutés au cube. La migration en fait des groupes de mesures liés qui pointent de nouveau vers le cube de base. À tout cube de base référencé par le cube virtuel d'origine correspondra un cube de mesure lié qui pointera de nouveau vers la base.

• Les dimensions virtuelles sont soumises aux règles de fusion des dimensions. Les dimensions virtuelles étaient auparavant basées sur les propriétés de membre et pouvaient comporter un ou plusieurs niveaux. Une dimension virtuelle à un seul niveau sera fusionnée dans la dimension sur laquelle elle était basée. Une dimension virtuelle à plusieurs niveaux sera convertie en dimension réelle. Prenons l'exemple d'une base de données Supermarché dotée de trois dimensions virtuelles. En guise d'illustration, nous allons étudier plus particulièrement les dimensions Emplacement (à plusieurs niveaux) et Surface du magasin en m² (à un seul niveau). Lors de la migration, la dimension Emplacement est créée en tant que nouvelle dimension. La dimension Surface du magasin en m² est fusionnée dans la dimension Magasin. L'unité m² est ajoutée en tant qu'attribut de la dimension.

• Chaque action fera l'objet d'un envoi de message indiquant sa migration sous forme de commande. Dans l'interface utilisateur d'Analysis Services 2005, celles-ci sont encore évoquées en termes d'actions.

• Les vues de sources de données sont créées automatiquement et créeront des requêtes nommées afin de représenter un ensemble de colonnes d'une table. Les vues de sources de données ainsi créées comprennent la totalité des tables de faits et des tables de dimensions qui étaient utilisées auparavant dans la base de données OLAP d'Analysis Services 2000.

• Les partitions font l'objet d'une migration, bien que les scripts utilisés pour les créer automatiquement migrent en tant que scripts XMLA. Les partitions utilisent une liaison de requête qui utilisent la déclaration SQL générée par Analysis Services 2000 pour procéder à la partition.

• Les rôles migrent avec la sécurité des cubes et des dimensions. Analysis Services 2005 permet de mettre en œuvre davantage d'options de sécurité. La mise en œuvre de l'une de ces nouvelles options ne peut être effectuée qu'après la migration.

• La migration de dimensions à plusieurs hiérarchies est possible, mais ces dimensions ne sont pas toujours renommées de la manière souhaitée. Par exemple, les dimensions intitulées Temps.Année fiscale et Temps.Année calendaire dans Analysis Services 2000 seront probablement nommées Temps et Temps 1 après leur migration. S'il existait une hiérarchie appelée Temps, elle migrerait vers Temps TempsDim et TempsDim1. Ceci peut être source d'erreurs. Si ce résultat n'est pas conforme à vos attentes, il est très facile de renommer les dimensions.

Après la fin de l'Assistant Migration, vous pouvez aller dans Business Intelligence Development Studio consulter les résultats et procéder à des modifications si nécessaire. Les tâches à effectuer après la migration sont les suivantes :

• Renommer les dimensions afin de les rendre conformes à votre convention d'appellation.

• Déterminer si les hiérarchies définies par l'utilisateur se trouvent dans les dimensions appropriées. Dans certains cas, l'Assistant Migration crée plus de dimensions que nécessaire. Vous pouvez alors consolider certaines hiérarchies définies par l'utilisateur et supprimer les dimensions supplémentaires. Ceci permet de s'assurer que les noms des nouvelles dimensions n'affectent pas les requêtes MDX existantes et ne les font pas échouer.

• Donner un nom aux calculs nommés. Colonnex est le nom attribué à chaque calcul nommé qui s'ajoute à votre vue de source de données. Vous pourrez nommer ces derniers de manière appropriée par rapport à la colonne.

• Paramétrer l'extraction comme une action. L'extraction s'effectue à présent comme une action et nécessitera une configuration.

Pour renommer une dimension dans Business Intelligence Development Studio, utilisez la procédure suivante.

Pour visualiser votre nouveau cube et renommer une dimension

1. Dans le groupe de programmes SQL Server 2005, ouvrez Business Intelligence Development Studio.

2. Lors du lancement de cet outil, la page de démarrage de Visual Studio s'affichera probablement.

3. Pour ouvrir votre cube, cliquez sur Ouvrir dans le menu Fichier. Cliquez sur Base de données Analysis Services comme indiqué sur la figure 4.

   

   Figure 4 : Vous pouvez ouvrir une base de données Analysis Services existante à partir de Business Intelligence Development Studio.

1. Vous êtes invité à créer une base de données (Create a Database) ou à ouvrir une base de données existante (Open an existing database). Sélectionnez Open an Existing Database et entrez les informations relatives à votre instance et à votre base de données.

2. Avec Solution Explorer, vous pourrez visualiser votre base de données ainsi que la liste des dimensions et des cubes générés.

3. Pour renommer une dimension, cliquez dessus avec le bouton droit, puis cliquez sur Rename (Renommer). Vous pouvez alors entrer un nouveau nom, comme indiqué sur la figure 5.

   

   Figure 5 : Il est facile de renommer les objets dans Analysis Services 2005.

L' Assistant Migration met en œuvre peu de nouvelles fonctionnalités puisque celles-ci n'ont pas d'équivalent dans Analysis Services 2000. Ces fonctionnalités sont accessibles dans les onglets et les boîtes de propriétés des outils d'administration d'Analysis Services. Parmi les fonctionnalités avancées non mise en œuvre, citons :

• les indicateurs de performances clés (KPI) ;

• les traductions ;

• les dimensions plusieurs à plusieurs ;

• les dimensions de rôle actif ;

• les mesures semi-additives.

Migration vers Project REAL

Les bases de données et les cubes OLAP précédemment utilisés dans Project REAL ont été redéfinis. Les Assistants disponibles dans Analysis Services 2005 ont servi de base à la conception du cube. L'Assistant Migration a été utilisé en parallèle avec un échantillon de données de la chaîne de librairies Barnes and Noble, dans le but de comparer les résultats. Dans une large mesure, les données exploitées possédaient les mêmes dimensions, dont beaucoup étaient virtuelles. L'Assistant Migration a permis de faire les observations suivantes :

• Chaque dimension virtuelle était basée sur des propriétés de membre issues d'une table d'articles. Lors de la migration, elles ont toutes été fusionnées (ou renommées) sous la forme de dimension d'article. Chaque dimension virtuelle a été ajoutée en tant que hiérarchie définie par l'utilisateur dans la dimension d'article. Elles ont toutes été rendues visibles par défaut et peuvent être référencées comme avant la migration. La probabilité selon laquelle vos requêtes précédentes continueront de fonctionner par simple recours au nouveau fournisseur s'en trouve accrue.

• Une vue de source de données unique a été créée à partir de la source de données unique qui était utilisée dans Analysis Services 2000. Cette vue de source de données représentait toutes les tables utilisées par la source de données existante.

• Le cube virtuel unique a migré vers un cube dans Analysis Services 2005. Chaque cube de base a migré sous la forme d'un groupe de mesures spécifique (un pour les Ventes magasin, un pour le Stock magasin, un pour le Stock du centre de distribution).

• La migration de toutes les informations relatives à la sécurité telles que les rôles et les options de sécurité des données s'est déroulée correctement.

• À l'exception de la dimension temps, renommée Temps.Année Fiscale et Temps.Année calendaire (comme décrit précédemment dans l'exemple des hiérarchies multiples), les dimensions ne présentaient pas de conflit d'affectation de noms. Elles portaient donc le même nom dans Analysis Services 2005 que dans Analysis Services 2000.

• L'ensemble du processus s'est déroulé de manière simple et rapide, aboutissant à la création dans Analysis Services 2005 des cubes existants dans Analysis Services 2000.

• Dans les données de stock, les nouvelles mesures semi-additives ont été utilisées pour attribuer la valeur DernierEnfantNonVide à toutes les mesures en stock et sur commande. Comme il s'agit d'une fonctionnalité nouvelle d'Analysis Services 2005, les calculs complexes utilisés pour les consolidations semi-additives sur une période donnée ont été supprimés.

Migration et redéfinition

L'Assistant Migration offre un bon aperçu de vos données dans les cubes Analysis Services 2005. Cependant, il convient de noter que les cubes créés avec l'Assistant Migration sont censés dupliquer les cubes construits avec Analysis Services 2000, ce qui n'est pas toujours le but recherché. Dans certains cas, il vous suffira d'effectuer la migration avec l'Assistant avant l'ajout des fonctionnalités souhaitées. Dans d'autres cas, il sera préférable de redéfinir les cubes dans la nouvelle architecture. La liste de questions suivante vous permettra de déterminer si l'Assistant Migration constitue une bonne base de départ ou s'il vaut mieux vous contenter de redéfinir les cubes.

• Disposez-vous de plusieurs petits cubes aux dimensions et aux mesures limitées ? Les administrateurs de cubes Analysis Services 2000 construisaient généralement des cubes de taille plus réduite. L'Assistant les fera migrer vers des cubes individuels dans Analysis Services 2005. Vous ne souhaiterez peut-être pas disposer d'un grand nombre de petits cubes puisqu'Analysis Services 2005 n'impose pas de contraintes en termes d'utilisation de la mémoire, des mesures de tables de faits uniques, des comptes distincts et des propriétés de membre. Vos données seront plus significatives si elles figurent dans un petit nombre de cubes plus volumineux, dotés de perspectives reflétant le contexte utilisateur. Si vous utilisiez de nombreux cubes pour représenter le contexte utilisateur, vous aurez intérêt à les redéfinir dans Analysis Services 2005.

• Avez-vous ajouté une grande quantité de propriétés de membre à vos dimensions en vue de produire des rapports ? Les colonnes peuvent à présent être ajoutées en tant que dimensions d'attributs, ce qui leur confère une utilité pour la mise en page des rapports et la navigation. Toutes les propriétés de membre ne doivent pas être nécessairement des attributs liés. Comme ceci peut demander de nombreuses opérations de nettoyage manuel après la migration, il peut être préférable de redéfinir vos cubes.

• Utilisiez-vous des dimensions privées sur une grande quantité de cubes ? Après la migration, les dimensions privées deviendront des dimensions. Si vous avez utilisé un grand nombre de dimensions privées et un seul type de dimension pour différents cubes, vous remarquerez que le système dupliquera ces dimensions en tant que dimensions dans Analysis Services 2005. Il sera donc nécessaire de nettoyer les noms de dimension et de modifier les cubes. Dans ce cas, vous envisagerez probablement de redéfinir vos cubes.

• Disposez-vous d'un nombre important de membres calculés, désormais autorisés en tant que mesures ? Les mesures bénéficient à présent de nombreuses fonctions d'agrégation. La liste des fonctions d'agrégation s'est développée à partir de la liste d'origine : Somme, Compte, Compte distinct, Min, Max. Elle comporte à présent les fonctions suivantes : Moyenne des enfants, Aucun, Premier enfant, Dernier enfant, Premier enfant non vide et Dernier enfant non vide. Si vous avez créé des membres calculés qui sont désormais utilisables comme mesures, vous pouvez peut-être envisager de redéfinir vos cubes, ou au moins estimer l'ampleur d'une opération de nettoyage après la migration.

• Avez vous modifié de manière significative votre processus ETL ou avez-vous créé des vues dans votre base de données relationnelle afin de créer une source de données unique pour votre cube ? Si vous souhaitez que vos données proviennent de plusieurs sources, il est sans doute préférable de redéfinir vos cubes et de charger vos données en construisant des requêtes nommées dans vos vues de sources de données.

• Avez-vous dû recourir à des comptes distincts ? Dans Analysis Services 2000, les comptes distincts exigeaient beaucoup d'attention. Il n'en fallait qu'un par cube, et il était recommandé de placer ce compte distinct dans son propre cube en l'associant à d'autres mesures dans un cube virtuel. Cette limitation n'existe plus et il se peut que la solution de remplacement ne vous convienne pas.

• Utilisez-vous un grand nombre de dimensions et de cubes virtuels ? La migration aura pour effet de les convertir en dimensions et en cubes réels. Pour les dimensions virtuelles, le résultat obtenu n'est probablement pas conforme à vos attentes, puisque la colonne peut aisément être créée en tant que dimension d'attribut. Pour les cubes virtuels, vous devrez probablement procéder à leur nettoyage ou à celui des cubes de base, puisque les données ont été dupliquées. Si ce nettoyage s'avère fastidieux, il est probablement préférable de redéfinir le cube.

• Êtes-vous satisfait de la conception de votre cube tout en souhaitant utiliser les nouvelles fonctionnalités d'Analysis Services 2005 ? Si vos cubes vous conviennent et semblent adaptés aux nouvelles exigences d'Analysis Services 2005 en termes de conception, vous pouvez faire migrer vos données vers la nouvelle version avec l'Assistant Migration. Vous pourrez alors ajouter les nouvelles fonctionnalités que vous souhaitez. Consultez la documentation du produit pour obtenir la liste détaillée de ses nouvelles fonctionnalités.

Conclusion

Avec l'UDM, le passage entre les environnements de production relationnels et OLAP s'effectue sans problème. Les nouvelles options d'Analysis Services 2005 offrent une liberté totale en matière de conception et font bénéficier l'utilisateur final de fonctions d'analyse et de production de rapports nettement améliorées. L'Assistant Migration est un excellent outil qui vous accompagne tout au long de ce processus. À l'aide de cet Assistant, le portage des bases de données OLAP vers la nouvelle version s'effectue très facilement afin de vous faire rapidement bénéficier de ses nouvelles fonctionnalités. L'Assistant Migration s'efforce de recréer au mieux vos cubes de données dans Analysis Services 2005. Au final, vous devrez décider, selon l'importance des changements de structure des cubes, si vous préférez reprendre le processus depuis l'origine plutôt que d'utiliser l'Assistant Migration. L'évaluation de votre environnement actuel et des modifications à lui apporter dans Analysis Services 2005 vous permettra de déterminer s'il vaut mieux redéfinir les cubes ou utiliser l'Assistant.

Pour plus d'informations, consultez le site :
https://www.microsoft.com/france/sql/