La Migration (2)

a un peu matière à interprétation concernant la manière dont FoodMart doit être mise en oeuvre dans SSAS 2005, mais la plupart des personnes s’accordent à reconnaître que la base de données migrée de la figure 1 ne représente pas la meilleure conception. Les éléments suivants documentent certaines des observations générales :

• En raison de la capacité de SSAS 2005 à créer des cubes plus complets que SSAS 2000, les quatre cubes réguliers doivent être fondus en un seul. Il est possible d’argumenter sur le fait que le cube HR peut rester à part.
• Les cubes virtuels dans SSAS 2000 ont été migrés en tant que cubes car SSAS 2005 ne propose aucun équivalent à cette fonctionnalité. Nous ne devrions pas avoir besoin de cubes virtuels si les cubes SSAS 2000 sont consolidés dans un seul cube SSAS 2005.
• Plusieurs des dimensions obtenues sont des variantes de ce que doit être une dimension unique dans SSAS 2005. Par exemple, Gender (Sexe), Education Level (Niveau d’études), Marital Status (Situation de famille) et Yearly Income (Revenus annuels) doivent devenir des hiérarchies d’attributs dans un seule dimension Customer (Client). Notez que ces attributs apparaissent en réalité dans la dimension Customer car ils ont été définis comme propriétés de membres dans SSAS 2000.

Un autre problème est la possibilité d’ajouter facilement de nouvelles dimensions d’attributs (lesquelles constituent la pierre angulaire de SSAS 2005) à n’importe quelle dimension de base. La vue de source de données (DSV) créée par le Migration Wizard inclut seulement les colonnes qui prennent en charge les objets migrés. La table Customer dans la base de données relationnelle source FoodMart 2000 contient plusieurs colonnes qui peuvent servir d’option d’analyse intéressantes, notamment city (ville), state (État), customer region (région du client), total children (nombre total d’enfants), houseowner (propriétaire), number of cars owned (nombre de voitures détenues) et bien plus encore.

Vous pouvez mettre à jour la vue de source de données pour inclure toutes les colonnes des tables source en cliquant avec le bouton droit de la souris sur l’arrière-plan dans le concepteur de vue de source de données et en sélectionnant Refresh (Actualiser). Mais attention, le risque n’est pas nul car certaines propriétés des attributs pré-existants peuvent changer. Il vous semblera peut-être plus facile de simplement remplacer des tables de dimension spécifiques dans la vue de source de données (cliquez avec le bouton droit de la souris sur la table, sélectionnez Replace Table, With Other Table [Remplacer la table par une autre table], puis sélectionnez la même table). Une fois que vous avez mis à jour la vue avec l’ensemble des colonnes disponibles, il vous faut modifier chaque dimension afin d’ajouter les hiérarchies d’attributs souhaitées à partir des nouvelles colonnes disponibles.

En dépit des aspects négatifs, beaucoup de choses positives se sont produites lors de la migration. Tous les calculs MDX que nous avons définis dans les membres calculés ont été migrés correctement (examinez sous l’onglet Calculations le cube Sales dans BIDS). Il en va de même pour nos dimensions parent/enfant (Account et Employees). De plus, les partitions et conceptions d’agrégations, les actions, les opérateurs unaires et les propriétés de membres ont été conservés et sont opérationnels. Enfin, il convient de noter que le Migration Wizard migre uniquement les métadonnées. Les cubes migrés doivent être traités entièrement afin de les remplir avec des données.