Utilité des schémas SQL Server en BI

Je me sens bien seul ….Suis-je le seul à trouver un réel intérêt à utiliser les schémas sous SQL Server ?

J’en ai bien l’impression, j’ai beau écluser les projets MS BI je ne vois cette fonctionnalité utilisée que trop rarement.

Un Datawarehouse n’est pas seulement une grosse boite noire destinée à l’implémentation de cubes ou de rapports. Les utilisateurs avancés (analystes) doivent pouvoir aussi y accéder. Et c’est d’autant plus vrai dans le contexte actuel. Les utilisateurs BI sont soumis à différentes pressions business et se doivent d’être le plus réactif possible. C’est là tout le sujet de la BI Self-Service à mon sens. Elle permet de répondre à un besoin précis voir ponctuel dans un temps très court sans avoir à subir les contraintes de charge et de planning de l’IT.

Par conséquent, ce type d’utilisateur, va vouloir accéder au Datawarehouse de façon à cruncher la donnée en détail et l’enrichir avec des informations non présentes dans l’entrepôt. Pour cela, deux options s’offrent à lui :

  • soit directement via des requêtes SQL et des TCD Excel à tire larigot
  • soit, encore mieux, par l’intermédiaire d’un modèle d’analyse tabulaire type PowerPivot.

Par conséquent, l’entrepôt se doit d’être organisé, structuré et sécurisé correctement. Et c’est en cela que les schémas SQL Server vont vous aider.

Dans votre entrepôt, vous aller avoir :

  1. des tables/vues techniques
    • pour piloter l’intégration des données, je les rattache au schéma « Adm »
    • pour tracer l’intégration des données, je les rattache au schéma « Log »
    • pour faire des update en masse ou des alimentations de partitions, je les rattache au schéma « Tmp » ou « Stg »
  2. des tables/vues communes à tous les métiers de l’entreprise, je les rattache au schéma « Common »;  il s’agit des dimensions (axes d’analyse) pouvant être utilisées par toute la société
  3. des tables/vues spécifiques à certains services, je les rattache à un schéma ;  il s’agit des tables de fait et de certaines dimensions

Exemple sur un entrepôt contenant :

  • des données commerciales (ventes, objectifs commerciaux, …)
  • des données de merchandising (stock, achat de marchandises, objectif de stock …)

N.B : il va de soit qu’il ne faut pas oublier de mettre en place une convention de nommage sur tous les autres objets SQL Server (tables, colonnes, vues, proc stock, fonctions …), n’oublier que ce sont des utilisateurs qui vont utilisateur l’entrepôt, le nom des objets doit donc être fonctionnellement parlant et compréhensible par tout le monde.

J’en profite pour glisser un lien bien utile : http://msdn.microsoft.com/en-us/library/xzf533w0(VS.71).aspx

Pour ma part, je ne saurais que vous conseiller d’appliquer les quelques règles suivantes : éviter les espaces, les accents, les underscore _ et tout autre caractère spécial, simplifiez vous la vie et mettez tout au singulier et suffixer vos champs par leur type d’utilisation (exemple : Id ou SKey pour un identifiant technique, Cd ou Bkey pour une clé métier, Nm pour un libellé ….). Je ne saurais donc que vous orienter vers le Pascal Case ou le Camel Case, mais cela n’engage que moi.

Bon revenons à nos moutons; bien entendu, l’intérêt des schémas n’est pas que structurel, il est aussi sécuritaire. Ci-dessous quelques fonctions de bases de manipulation des schémas :

  • Création d’un schéma : CREATE SCHEMA [Nomdu schéma]
  • Suppression d’un schéma : DROP SCHEMA [Nomdu schéma]
  • Attribution de droit sur un schéma : GRANT [ALTER|CONTROL|SELECT|DELETE|INSERT|UPDATE|REFERENCES] ON SCHEMA::[Nomdu schéma] TO [group or user login]
  • Transfert d’objet d’un schéma vers un autre : ALTER SCHEMA [Nom du schéma de destination] TRANSFERT [Nom du schéma source].[Nom objet]

Au passage je vous invite à reporter le nom des schémas sur les groupes de mesures de vos cubes :

  • pour simplifié et rendre la structure plus lisible; les données sont regroupées par périmètre fonctionnel, l’utilisateur accède donc plus rapidement à l’information
  • pour accroitre la maintenabilité de votre projet

Schémas + conventions de nommage => succès assuré

7 réflexions sur “Utilité des schémas SQL Server en BI

  1. Hello camarade!
    Pour les schémas, j’ai beau savoir que tu as raison, j’ai toujours la flemme et je laisse tout sur dbo… Faut que je me motive🙂

    Pour le nom des colonnes (dans les dim et ft), je suis la recommandation de Ralph et je mets les noms tels qu’ils sont attendus par les utilisateurs. Oui ça veut dire que tu pourras trouver une colonne [Numéro d’Article].

    Au delà des considérations légitimes vis à vis des utilisateurs, ça m’apporte la grande satisfaction de voir les dba s’arracher les cheveux… Ça n’a pas de prix😀

  2. Salut Florian,
    Les recommandations de Ralph s’applique bien à la langue anglaise, qui est dénuée d’accents et permet d’avoir un tri naturel des attritbuts par ordre alphabétique [Country ID], [Country Code], [Country Label], [Start Date]. En supprimant donc l’espace pour faire du Pascal Case, on est vraiment très proche du nom désiré par les utilisateurs. Ce qui permet de reconcilier tout le monde : dba, BI Team et nos très chers utilisateurs.
    Malheureusement ce n’est pas le cas de notre très chère langue de Molière et on se retrouve bien vite sous SSAS avec des attributs de dimensions et des mesures organisés n’importe comment (même si on utilise les Display Folder) et ayant des noms à ralonge (pas tip top dans les TCD).
    Par ailleurs, SSAS gère très bien le Pascal Case et ajoute automatiquement des espaces entre chaque mots. Dommage qu’il n’y ai pas de continuité sur l’ensemble des produits MS (SSRS et PowerPivot notamment).
    Maintenant voir un dba s’arracher les cheveux çà vaut le coup !😉

    • J’avais jamais tilté sur le coup de l’impact de la langue française sur les conseils de nomenclature du barbu. Tu viens de me révolutionner le truc là…

      Mais ne suis-je pas trop vieux pour changer maintenant? L’avenir le dira!
      En tout cas merci pour ce nouvel éclairage sur un sujet que je pensais défintivement clos😉

  3. Pour compléter, il y a un autre problème majeur à l’utilisation des caractères un peu spéciaux (simple quote, caractères accentués) dans le nommage des colonnes car SSAS ne les supporte pas. J’ai donc tendance à tout nommer en anglais (table, colonne dans SQL, dimensions, attributs, hiérarchies, niveaux, mesures… dans SSAS) pour éviter de me retrouver avec des noms d’attribut farfelus du type « Mois de l annee » (sans accent et sans simple quote !!!) ce qui est moche. Ensuite j’utilise les traductions dans SSAS pour mettre en place les libellés corrects (puisque c’est supporté). C’est évidemment un solution qui ne fonctionne qu’en Edition Enterprise et ça impose de l’anglais là où on aurait peut-être désiré du français mais c’est ce qui me semble le plus « propre ». En tout cas, ça ajoute une pierre à ce que tu mentionnes Frédéric et ça remet en cause ton nommage de gros coquin qui aime se friter avec les DBA, Flo, désolé :o)

    • Oui et c’est d’autant plus vrai dans le contexte économique actuel de mondialisation/globalisation.
      La langue internationale étant l’anglais, il vaut mieux « designer » la base en conséquence.
      Encore faut-il ne pas faire de traduction approximative des termes fonctionnels😉
      Et puis je n’ai pas encore rencontré de version Standard chez les clients😀

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