Modélisation Cube – Exposer vos données par des vues

Analysis Services, que ce soit en mode Multidimensionnel ou Tabular, vous permet de vous connecter à votre entrepôt et d’importer les données en sélectionnant des tables, des vues ou bien des requêtes.

Certes l’utilisation de requêtes peut-être très pratique pour :

  • restreindre le périmètre des données à remonter dans le cube,
  • ajouter des colonnes calculées,
  • substituer certains libellés (en règle générale les booléens sont remplacés par des valeurs textuelles)
  • modifier certaines règles de gestions en cas de maintenance correctives afin de corriger une anomalie,
  • etc.

Cela semble tellement attractif que je n’ai pas souvenir d’avoir travaillé sur un cube dénué de requêtes nommées (sauf ceux que j’ai désignés :))

Malheureusement, plus la solution Analysis Services devient complexe, plus la maintenance devient casse-tête et l’on se retrouve rapidement avec une Data Source View (pour les cubes multidim) ou un Data Model (pour les cubes Tabular) utilisant ces trois types d’objet (tables, vues, requêtes nommées). Cela devient alors rapidement de la fouille archéologique lorsque vous n’avez pas implémenté la solution et qu’on vous demande de corriger un bug. Il vous sera donc nécessaire de déterminer si votre source de donnée est une requête nommée, une vue ou bien une table avant de pouvoir requêter votre entrepôt et de vous assurer de la véracité ou pas du bug puis de déterminer les actions correctives à entreprendre.

Autre inconvénient des requêtes nommées, c’est qu’elles ne sont accessibles que dans la base SSAS dans laquelle elles sont déclarées. Par conséquent, si vous avez plusieurs bases SSAS connectées sur votre entrepôt, vous risquez d’avoir à ré-implémenter les requêtes nommées dans vos différentes solutions. Je vous laisse imaginer les possibilités d’erreur de report d’une solution à l’autre; et cela sans prendre en compte le versionning de vos codes sources (entre les développements en cours, et la ou les solutions actuellement en production).

Il est donc important d’appliquer un Design Pattern, qui vous permettra :

  • de réduire ces risques
  • et d’être, par la même occasion, un accélérateur de résolution d’incident.

Le principe est tout bête, il suffit de mettre en place une couche d’abstraction sur votre entrepôt, en exposant les données aux cubes par l’intermédiaire de vues.

Modelisation Cube - Exposer vos données par des vues

Ainsi, toutes modifications des règles de gestion non structurantes sur les métadonnées peuvent être effectuées sans avoir à redéployer le(s) cube(s).

Astuce : je ne saurai que vous conseiller d’utiliser de(s) schéma(s) SQL Server spécifique(s) pour vos vues (cf. article )

11 réflexions sur “Modélisation Cube – Exposer vos données par des vues

  1. Je suis plutôt DSV, mais juste pour la facilité de déploiement (on est sûr de ne pas oublier de déployer les vues :p ), mais je suis d’accord avec toi sur l’utilisation des vues.

    Par contre, là où c’est le bordel et qu’on voit encore souvent, c’est quand il y a la fois des vues et des requêtes nommées. Dans le genre j’en mets partout et je croise les doigts pour que je retrouve mes petits🙂

    • Il est vrai qu’on trouve souvent des plats de spaghettis bien collants et difficile à démêler🙂. D’où la nécessité de mettre en place un Design Pattern et de s’y tenir.

  2. Fred, je suis un peu embêté. Pour moi : avoir une base propre > intercaler des vues > utiliser la DSV. En allant de celui qui demande le plus d’effort (redescendre toutes les modifs en base et dans l’ETL) mais le plus propre et pérenne (lean), au plus facile et moche.

    Or j’ai l’impression que tu recommandes de toujours intercaler des vues. C’est le cas ?

    Et sinon je suis bien d’accord avec toi, la DSV doit être utilisée au minimum. Le seul cas particulier étant celui où l’équipe SSAS n’est pas la même que celle du DWH, et qu’elles ne travaillent pas au même rythme. Dans ce cas la DSV sert de degré de liberté pour répondre au changement de manière temporaire, en attendant la répercussion des évolutions en base.

    • Salut Florian,

      Oui je recommande toujours d’intercaler des vues. Mais attention, il ne s’agit pas de mettre en place un fourre tout, il faut donc veiller au grain pour que tout le monde les utilise intelligemment🙂.

      J’y vois surtout les avantages suivants :

      – Filtrage des données à exposer à SSAS (par ex : volonté du client à conserver l’ensemble de l’historique et à n’exposer dans le cube que les 2 dernières années)

      – « Défloconisation » du modèle (je n’aime pas vraiment les flocons, mais quand on arrive après la bataille… Dans ce cas, il faudra mener un projet de restructuration de l’entrepôt)

      – Mise en place de patchs correctifs intermédiaires avant correction et déploiement des lots SSIS

      – Avoir un entrepôt commun mais exposer des modèles de données optimisés en fonction du moteur SSAS utilisé (Tabular / Multidim). Cela fera l’objet d’un prochain article.

      Mais je te rejoins complètement, les vues ne doivent pas se substituer à l’ETL. Ce dernier doit garder la main mise sur l’implémentation des règles de transformation ; ce qui est le plus propre et le plus pérenne.

      • Ok, vu comme ça c’est en effet intéressant.
        Mais tu ne m’en voudras pas si je t’avoue que même si je respecte ta démarche, tu ne m’as pas convaincu :p

      • Je suis concerné de près dans le projet sur lequel je travaille actuellement, les applicatifs financiers utilisent des vues actuellement, je souhaite mettre en place des outils de reporting PowerPivot et Analysis Services en tabular mode via SSDT, dans quelle mesure faut-il utiliser un ETL ? Quelles méthodes employées pour utiliser les vues dans les reporting PowerPivot soit SSAS in Tabular mode ? Je suis très intéressé par le sujet mais je trouve la façon de l’aborder pas assez précise, pouvez préciser les étapes de la démarche à suivre ?
        Peut-on se permettre d’utiliser un ETL qui ne s’occupe dans un premier temps du chargement des données brutes en Staging puis dans un deuxième temps du chargement d’un datamart avec les tables de dimensions et de faits, ce qui est recommandé et qui éviterait les problèmes des requêtes nommées associés à uniquement au cube SSAS où elles sont écrites.

        Merci de me répondre. La réponse est très importante pour la suite de mon projet.

      • Bonjour Moustapha,
        Alors je précise que cet article traite de l’utilisation de vues pour exposer les données de l’entrepôt vers Analysis Services. Les données ont donc déjà été transformées et modélisées en étoile.
        Je te confirme donc que SSIS (euhhhh l’ETL) est de rigueur pour récupérer toutes les données sources dans un ODS (ou base de staging), puis effectuer toutes les transformations nécessaires pour les charger dans l’entrepôt.
        Les solutions décisionnelles ne doivent, en aucun cas, charger ni stresser les applications opérationnelles lors de leur plage d’utilisation.
        Cela reste aussi valable pour des besoins d’analyse en (quasi) temps réel, pour lesquels il existe des design pattern (replication + déclenchement de packages SSIS pour alimenter l’entrepôt + cube en ROLAP, StreamInsight pour charger l’entrepôt + cube en ROLAP, et bien d’autre encore)
        Donc oui : ETL avec ODS + DWH

  3. Complètement d’accord avec la démarche… les gens qui m’ont mis le pied à l’étrier sur AS utilisaient les vues (pas de DSV sur SQL SERVER 2000…. oui j’suis vieux!) et je continue a les utiliser car malheureusement la DSV n’apporte pas le même niveau de découplage et de fonctionnalités….
    Haaa et puis, le designer de Named Query n’est pas très très intelligent, si je me rappelle bien il ne supporte pas les Window function SQL…. sniff!

  4. Je suis très intéressé par ce que tu viens d’écrire, je souhaite mettre en place du temps réel.
    Pourrais-tu me donner plus de précisions sur le design pattern (replication + déclenchement de packages SSIS pour alimenter l’entrepôt + cube en ROLAP, StreamInsight pour charger l’entrepôt + cube en ROLAP etc…) ? Est-ce qu’il y aurait des sources d’informations sur le sujet : blogs, articles, documents, ou autres ?

    Merci pour ton aide.

    Cela reste aussi valable pour des besoins d’analyse en (quasi) temps réel, pour lesquels il existe des design pattern (replication + déclenchement de packages SSIS pour alimenter l’entrepôt + cube en ROLAP, StreamInsight pour charger l’entrepôt + cube en ROLAP, et bien d’autre encore)

    fbrossard :
    Bonjour Moustapha,
    Alors je précise que cet article traite de l’utilisation de vues pour exposer les données de l’entrepôt vers Analysis Services. Les données ont donc déjà été transformées et modélisées en étoile.
    Je te confirme donc que SSIS (euhhhh l’ETL) est de rigueur pour récupérer toutes les données sources dans un ODS (ou base de staging), puis effectuer toutes les transformations nécessaires pour les charger dans l’entrepôt.
    Les solutions décisionnelles ne doivent, en aucun cas, charger ni stresser les applications opérationnelles lors de leur plage d’utilisation.
    Cela reste aussi valable pour des besoins d’analyse en (quasi) temps réel, pour lesquels il existe des design pattern (replication + déclenchement de packages SSIS pour alimenter l’entrepôt + cube en ROLAP, StreamInsight pour charger l’entrepôt + cube en ROLAP, et bien d’autre encore)
    Donc oui : ETL avec ODS + DWH

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s