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.

Gestion dynamique des partitions OLAP avec SSIS

Sur des projets de haute volumétrie, le partitionnement des groupes de mesures est indispensable aussi bien :

• pour optimiser les temps de traitement d’un cube
• que pour minimiser les temps de requêtes

C’est une bonne pratique reconnue mais pas toujours bien mise en oeuvre.

Tout d’abord, utilisons les seuils indiqués par les différents « white papers ». Si tout le monde les lisait, nos projets ne s’en porteraient que beaucoup mieux. Encore faut-il aimer son job, s’y intéresser et investir un peu de son temps personnel (bon là je dérive …)

La bonne pratique veut que tout groupe de mesures de plus de 20 millions de lignes ou de plus de 250 Mo doit être partitionné. A cela s’ajoute aussi les considérations hardware, nombre de coeurs et de disques, de façon à s’assurer que les opérations de lecture/écriture (I/O) puissent être parallélisées. Bien sur, il ne s’agit que de valeurs indicatives mais cela vous aidera à déterminer s’il faut partitionner ou bien revoir la stratégie de partitionnement déjà en place.