[SSAS] Généralités : Concepts de base

Ce billet aborde brièvement différents concepts-clés associés à SQL Server Analysis Services (SSAS).

Petite introduction sur SSAS

Intérêt de SSAS

Au sein de beaucoup d’organisations se trouvent principalement 2 types de systèmes de données : un pour les traitements transactionnels (OLTP, OnLine Transactional Processing) d’informations détaillées dans une base de données relationnelle, un autre pour les traitements analytiques (OLAP, OnLine Analytical Processing) d’informations historiques dans un entrepôt de données (datawarehouse). Là où les traitements transactionnels sont optimisés pour des opérations d’insertions, mises-à-jour ou suppressions rapides, celles analytiques le sont principalement pour les lectures (ou explorations) de données.

SSAS est une des fonctionnalités de la suite Microsoft BI offrant la possibilité d’effectuer une analyse rapide et approfondie de données issues d’un (ou plusieurs) datawarehouses. Mais au-delà de ces aspects, quel est donc l’intérêt concret de l’utilisation de SSAS ?

Prenons le cas de commandes de produits, et admettons que l’on souhaite connaître la quantité de produits commandés par catégorie pour chaque trimestre de chaque année. L’écriture d’une requête SQL traditionnelle peut permettre de récupérer les informations en question ; cependant, les temps de réponse peuvent s’en ressentir, l’optimiseur SQL étant amené à parcourir toutes les données commandées au cours de chaque période sélectionnée et à ensuite effectuer des opérations d’agrégations afin de déterminer la quantité des commandes de chaque catégorie de produits. Et c’est encore plus vrai si l’on souhaite lire des résultats sous différents angles : par mois/semaine/jour/heure… pour chaque client, vendeur,…

A contrario, si, pour chaque catégorie de produits, les données agrégés (et précalculées pour réutilisation) sont stockées au sein d’une base de données multidimensionnelle – joliment appelée cube – les résultats seront produits plus rapidement, les données pouvant être explorées à travers différents axes. Un axe pouvant représenter chaque produit (hiérarchisé ou non, par catégorie), un autre chaque période (trimestre, mois,…), un autre chaque client, etc… On peut alors parler d’exploration multidimensionnelle de données.

L’utilisation de cubes OLAP pour l’analyse de données est d’autant très avantageuse que lors de leur traitement, les agrégats préalablement calculés et stockés sont réutilisés favorisant ainsi les temps de réponse.

    Modes de stockage et performances OLAP

SSAS supporte principalement 3 types de stockage OLAP : multidimensionnel (MOLAP), relationnel (ROLAP), hybride (HOLAP). Le tableau ci-dessous résume les caractéristiques essentielles de ces modes de stockage :

Stockage de données Stockage d’agrégats Performance des requêtes d’exploration de données
MOLAP Cube/base de données multidimensionnelle. Cube/base de données multidimensionnelle. Elevée.
ROLAP Base de données relationnelle. Base de données relationnelle. Basse.
HOLAP Base de données relationnelle. Cube/base de données multidimensionnelle. Moyenne.

Comme l’indique le tableau ci-dessous, MOLAP offre les meilleures performances pour l’exploration de données (pour les raisons explicitées dans la sous-section précédente) et ROLAP les plus mauvaises. HOLAP est à mi-chemin entre les 2 autres modes de stockage.

En revanche, l’intérêt de ROLAP (et de HOLAP) par rapport à MOLAP, au niveau des performances, est qu’il offre des temps de latence moins élevés avec la (ou les) source(s) de données. L’utilisation de la technique de la mise-en-cache proactive (proactive caching) peut permettre de bénéficier à la fois des avantages en termes de performances de MOLAP avec ceux en termes de temps de latence de ROLAP, si le besoin est d’avoir un cube OLAP régulièrement et suffisamment à jour. Plus de détails ici : http://msdn.microsoft.com/en-us/library/ms174769.aspx.

Notions de…

    … Datawarehouse et datamart

Un datawarehouse est un entrepôt de données qui sert de base de données relationnelle au sein de laquelle seront puisées les informations destinées au cube. Un datamart correspond, quant à lui, à un ensemble dénormalisé de données. Le but d’un datamart est de permettre de répondre à un besoin spécifique d’utilisateurs métiers, en fournissant une structure de données qui leur est familière.

Pour faire la différence entre un datawarehouse et un datamart il suffit de partir du principe, à juste titre, que :

  • Un datawarehouse se conçoit à partir de l’analyse des données existantes, de la façon dont elles devront être traitées. Il fait office de système central d’agrégats de données dont la structure peut évoluer durablement.
  • Un datamart se conçoit à partir de l’analyse des besoins des utilisateurs. Il s’agit d’un receptacle de données pouvant dériver d’une base de données relationnelle ou non, et devant répondre à un besoin immédiat.

… Cube

Plus haut, le terme de cube a souvent été employé, mais un mot persiste : késako ?

Un cube correspond à un système de stockage et d’analyse qui fait office de collection de données. Données qui ont été agrégées afin de retourner des résultats (souvent complexes) plus rapidement. De manière générale, l’agrégation de données se fait par secteur géographique, période, titre, service, catégorie,… permettant ainsi au cube de répondre rapidement à des questions du style : « Combien me rapporte annuellement chaque catégorie de sandwiches que je vends à Trifouillis-Les-Oies et Trouperdu depuis 2005 à Tartanpion ? ».

Tout cube est constitué de dimensions et de mesures (ou faits).

Et tout cube peut se voir créer un sous-ensemble de fonctionnalités appelé perspective. Pour faire simple, les vues sont aux bases de données relationnelles là où les perspectives sont aux cubes : des objets destinés à consulter un ensemble pertinent de données d’une base de données/d’un cube.

    … Dimension et table de dimensions

Une dimension fait référence à une catégorie de données métiers à analyser. Plus exactement, elle permet de catégoriser ou ordonner des mesures.

Quelques exemples classiques de dimensions : le temps, le secteur géographique,…

Toute dimension est construite à partir d’au moins une table de dimensions, qui contient des attributs (année, trimestre, couleur,…) et, éventuellement, des hiérarchies.

    … Mesure et table de faits

Une mesure correspond à un fait et est donc stockée au sein de ce qu’on appelle une table de faits qui forme une collection d’informations quantifiées et utilisées pour résumer des besoins.

Quelques exemples classiques de mesures : informations relatives à une commande (son prix, sa quantité,…), une population (âge,,taille,…), une ville (nombre d’habitants, superficie,…), etc… En clair, toute table contenant des informations quantifiables peut faire office de table de faits.

… Groupes de mesures, partitions

Les groupes de mesures forment un ensemble de mesures issues de tables de faits, tandis que les partitions sont des unités de stockage représentant un sous-ensemble d’une base de données analytique. Tous les groupes de mesures ont, par défaut, une simple partition contenant toutes les données mesurées ou agrégats. Et en cas de création de plusieurs partitions, les groupes de mesures deviennent une combinaison de données mesurées stockées dans toutes ces partitions.

Il n’y a pas de règle empirique permettant de statuer sur la nécessité d’une création ou non d’une partition, mais généralement, quand un groupe de mesures génère plusieurs vingtaine de millions de lignes de résultats et que les temps de traitements deviennent longs, la création de partitions peut s’avérer bénéfique, afin de notamment réduire les temps I/O (SSAS ne se concentrant que sur la partition possédant les données demandées).

    … Attributs, hiérarchies et niveaux

Les attributs caractérisent les propriétés d’une dimension, et une dimension possède généralement plusieurs attributs. Un exemple classique d’attributs est :

  • Pour une dimension relative à une période : Année, Trimestre, Mois, Semaine,…
  • Pour une dimension relative à un employé : Titre, Nom, Prénom,…
  • Etc…

Chaque attribut peut être relié à un ou plusieurs autres attributs. Par exemple, une année avec un trimestre, ce qui correspond à une relation parent-enfant.

Les hiérarchies, quant à elles, jouent un rôle important dans l’amélioration des performances des traitements analytiques lors de la navigation de données, puisque SSAS peut calculer des agrégations avant la réception d’une requête lancée.

Les hiérarchies sont créées à partir d’attributs reliés entre eux. Il s’agit d’une relation parent-enfant entre attributs, où l’attribut parent permet de consolider les autres membres de la hiérarchie qui font office d’enfants.

Un attribut parent peut, bien sûr, être l’enfant d’un autre attribut parent. Par exemple, Année est le parent de Trimestre qui est le parent de Mois qui est le parent de Semaine,…

La relation parent-enfant est définie par ce qu’on appelle des niveaux, où, dans notre exemple, Année possède le niveau le plus élevé (niveau 1), Trimestre le niveau 2, Mois le niveau 3,… Le but d’un niveau est donc de déterminer le positionnement d’un attribut au sein d’une hiérarchie.

… KPIs

Les KPIs (Key Performance Indicators) sont des indicateurs de performances utilisés pour quantifier le succès d’une activité (économique, commerciale,…). Il s’agit d’un ensemble d’agrégats associés à un groupe de mesures au sein d’un cube, pour évaluer, par exemple, l’efficacité des actions entreprises par les métiers sur une période donnée, un secteur géographique, etc…

… Schéma analytique

Comme évoqué plus haut, un cube possède des dimensions et de mesures. La relation entre ces objets forme ce qu’on appelle un schéma, pouvant se décliner en 2 types :

  • Schéma en étoile : chaque table de dimension est reliée à (au moins) une table de faits contenant des mesures. Il s’agit d’un schéma dénormalisé.


  • Schéma en flocon : quelques tables de dimensions sont reliées indirectement à (au moins) une table de faits. Il s’agit d’un schéma normalisé.


Le choix du schéma dépend beaucoup des besoins attendus au niveau métier. En règle générale, si le niveau de granularité de la (ou des) table(s) de faits est la même pour toutes les dimensions, alors un schéma en étoile est plus commode ; dans le cas échéant, un schéma en flocon peut être favorisé.

Nous n’aborderons pas dans ce billet le débat schéma en étoile contre schéma en flocon.

Et le mode tabulaire dans tout ça ?

Une version tabulaire de SSAS est apparue à partir de SQL Server 2012. Il s’agit d’une base de données de type in-memory (basé sur le moteur analytique xVelocity, pour être exact)
faisant office de croisement entre une base de données relationnelle et une base de données multidimensionnelle (ou cube).

Tout modèle tabulaire supporte donc des tables, des relations, mesures, KPIs (voir plus loin),… le tout destiné à produire rapidement et efficacement des données en harmonie avec une variété d’outils comme Excel, PowerPivot, SSRS (SQL Server Reporting Services),…

Plus de détails ici : http://technet.microsoft.com/en-us/library/hh212945.aspx.

Nous aborderons cela en détail dans un autre billet.

Pour aller plus loin…

Ce billet a permis d’aborder quelques concepts-clés associés à SSAS. Des aspects pratiques associés aux différents concepts traités (et bien d’autres) seront traités dans des billets dédiés.

Gardez un œil ici.

Publicités

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