Vers une meilleure modélisation

Avant de rentrer dans le cœur du sujet, représentons les concepts et les bonnes pratiques de modélisation des liens entre attributs.

Les relations d’attributs

Tous les attributs sont liés directement ou indirectement à l’attribut clé. En créant des hiérarchies, il est facile de créer des relations redondantes.

Ainsi la relation Customer à City n’est pas redondante, ce qui n’est pas le cas pour la relation suivante Customer à Country qui peut être obtenu indirectement.

Cette redondance a bien sur un impact sur le stockage de la base de données.

De plus les attributs possèdent un type qui peut être qualifiés de rigide ou de flexible.

Une relation entre attribut est dite rigide si elle n’évolue pas dans le temps comme par exemple, le sexe d’une personne.

Lorsque les types de relation sont flexibles, les agrégats sont automatiquement supprimés lors du traitement de la dimension et doivent être reconstruit à l’aide de l’instruction « process index » contrairement aux relations rigides. Par défaut, le type de relation est flexible.

Ce point est important à prendre en compte lorsque la fenêtre pour traiter le cube est limitée.

Les hiérarchies naturelles

A partir de lien d’attributs, il est possible de définir des hiérarchies naturelles et non naturelles.

Une hiérarchie est dite naturelle lorsqu’une unicité est définie pour chaque parent de la hiérarchie.

Ainsi la hiérarchie Country-State-City-Customer est naturelle tandis que Age-Gender-Customer ne l’est pas. En effet, si nous remontons la hiérarchie, à partir d’un sexe donné, il n’est pas possible de définir le parent ; le seul moyen est de naviguer par l’attribut clé.

D’un point de vue performance, une hiérarchie naturelle est matérialisée alors qu’une hiérarchie non naturelle est calculée à la volée.

Sous SQL Server 2005, il était facile de créer une hiérarchie non naturelle car l’option de la dimension KeyDuplicate était à IgnoreError.

Comment implémenter les bonnes pratiques ?

Le nouvel outil BID 2008, Business Inelligence Developpment, propose une nouvelle interface simplifié afin de guider l’utilisateur dans l’implémentation des bonnes pratiques de conception.

Tout d’abord les assistants de création de cube et de dimension ont été simplifiés. Ainsi, sur un même écran, il est possible de définir un nombre de propriété important sur un un attribut comme son nom simplifié, son type, l’activation de la navigation. De plus des validations s’effectuent en temps réels comme par exemple un avertissement qui apparaît si un nom n’est pas spécifié lorsqu’une clé composite d’une dimension est définie.

clip_image002

Nous avons vu qu’il est important d’utiliser avec précaution des hiérarchies non naturelles et d’éviter de créer des attributs redondants, ce qui auraient des impacts négatifs sur les performances.

Afin d’avoir une synthèse des relations entre les attributs, BID propose un nouvel onglet, l’attribute relationShip designer.

Ainsi, sous la figure ci-dessous nous pouvons aisément voir à l’aide du message d’avertissement qu’il y a une redondance entre les relations MonthsàCalendar QuarteràCalendar Semester et Monthsà Calendar Semester.

clip_image004

Cette version apporte donc un ensemble de règles de validation de bonnes pratiques. L’utilisateur est donc guidé, ce qui continue à démocratiser la Business Intelligence.

Il est d’ailleurs possible d’accéder et de modifier ces règles de validation et en particuliers de les activer ou désactiver soit au niveau du projet ou alors au niveau d’un élément plus fin comme la dimension.