Spécification des relations entre attributs dans une hiérarchie définie par l'utilisateur

Comme vous l'avez déjà appris au cours de ce didacticiel, vous pouvez organiser les hiérarchies d'attributs en niveaux au sein des hiérarchies utilisateur pour mettre à disposition des utilisateurs d'un cube des chemins de navigation. Une hiérarchie utilisateur peut représenter une hiérarchie naturelle, telle que ville, état et pays, ou simplement un chemin de navigation tel que nom d'employé, titre et nom de division. Du point de vue de l'utilisateur qui navigue au sein d'une hiérarchie, ces deux types de hiérarchies utilisateur sont identiques.

Avec une hiérarchie naturelle, si vous définissez des relations d'attributs entres les attributs qui composent les niveaux, Microsoft SQL Server 2005 Analysis Services (SSAS) peut utiliser l'agrégation d'un attribut pour obtenir les résultats à partir d'un attribut connexe. S'il n'existe aucune relation entre les attributs, Analysis Services agrège tous les attributs non clé à partir de l'attribut clé. En outre, comme vous l'avez déjà appris, lorsque vous définissez une relation de ce type, vous pouvez spécifier si la relation est souple ou rigide. Si vous définissez une relation rigide, Analysis Services conserve les agrégations une fois la dimension mise à jour. Si une relation rigide change, Analysis Services génère une erreur au cours du traitement, excepté si la dimension est traitée entièrement. En spécifiant des relations et des propriétés de relations adaptées, il est possible d'augmenter les performances des requêtes et des traitements. Pour plus d'informations, consultez Définition et configuration d'une relation d'attributs et Configuration des propriétés des hiérarchies définies par l'utilisateur.

Au cours des tâches de cette rubrique, vous allez définir des relations d'attributs pour les attributs des hiérarchies utilisateur naturelles dans le projet du didacticiel Analysis Services. Il s'agit de la hiérarchie Customer Geography dans la dimension Customer, de la hiérarchie Sales Territory dans la dimension Sales Territory, de la hiérarchie Product Model Lines dans la dimension Product et des hiérarchies Fiscal Time et Calendar Time dans la dimension Time. Ces hiérarchies utilisateur sont toutes des hiérarchies naturelles.

Définition des relations d'attributs pour les attributs dans la hiérarchie Customer Geography

Pour définir des relations d'attributs pour les attributs dans la hiérarchie Customer Geography

  1. Affichez le Concepteur de dimensions pour la dimension Customer, puis cliquez sur l'onglet Structure de dimension.

    Dans le volet Hiérarchies et niveaux, notez les niveaux de la hiérarchie Customer Geography définie par l'utilisateur. Cette hiérarchie est simplement un chemin d'exploration pour les utilisateurs - aucune relation entre les niveaux et les attributs n'est définie.

  2. Dans le volet Attributs, développez Geography.

    Notez les quatre relations d'attributs qui lient les attributs non clé de la table Geography à l'attribut clé de la table Geography.

  3. Dans le volet Attributs, développez Full Name.

    Notez que l'attribut Geography est lié à l'attribut Full Name. Notez également que l'attribut Postal Code est lié indirectement à l'attribut Full Name par le biais de l'attribut Geography, car l'attribut Postal Code est lié à l'attribut Geography et l'attribut Geography à l'attribut Full Name.

  4. Faites glisser la relation d'attributs Postal Code de l'attribut Geography vers la balise <nouvelle relation d'attributs> pour l'attribut Full Name.

    L'attribut Postal Code est maintenant lié directement à l'attribut Full Name. Dans la fenêtre des propriétés, notez que la propriété RelationshipType de cet attribut a la valeur Flexible. Cette valeur convient car la relation entre un client et un code postal est susceptible de changer dans le temps.

  5. Dans le volet Attributs, développez l'attribut Postal Code.

    L'attribut City est actuellement lié à l'attribut Postal Code par le biais de l'attribut Geography au lieu de lui être lié directement.

  6. Faites glisser la relation d'attributs City de l'attribut Geography vers la balise <nouvelle relation d'attributs> pour l'attribut Postal Code.

    L'attribut City est maintenant lié directement à l'attribut Postal Code. Dans la fenêtre des propriétés, notez que la propriété RelationshipType de cet attribut a la valeur Flexible. Cette valeur convient car la relation entre une ville et un code postal est susceptible de changer dans le temps.

  7. Dans le volet Attributs, développez City.

    L'attribut State-Province est actuellement lié à l'attribut City par le biais des attributs Full Name et Geography.

  8. Faites glisser la relation d'attributs State Province Name de l'attribut Geography vers la balise <nouvelle relation d'attributs> pour l'attribut City, puis remplacez la valeur de la propriété RelationshipType de cette relation d'attributs par la valeur Rigid.

    La valeur de la propriété RelationshipType pour cette relation d'attributs doit être Rigid, car la relation entre une ville et un état ne change pas dans le temps.

  9. Dans le volet Attributs, développez State-Province, faites glisser la relation d'attributs Country-Region de l'attribut Geography vers la balise <nouvelle relation d'attributs pour l'attribut State-Province, puis remplacez la valeur de la propriété RelationshipType pour cette relation d'attributs par la valeur Rigid.

    La valeur de la propriété RelationshipType pour cette relation d'attributs doit être Rigid, car la relation entre une ville et un état/une province et un pays/une région ne change pas dans le temps.

  10. Dans le volet Attributs, supprimez l'attribut Geography.

    Cet attribut n'est plus nécessaire.

ms166553.note(fr-fr,SQL.90).gifRemarque :
Au cours de cette tâche, vous avez déplacé les relations d'attributs de l'attribut Geography vers les autres attributs au lieu de créer de nouvelles relations d'attributs pour chacun de ces attributs. Définir des relations redondantes n'ajoute généralement aucune valeur et augmente le temps de traitement inutilement.

Définition des relations d'attributs pour les attributs dans la hiérarchie Sales Territory

Pour définir des relations d'attributs pour les attributs dans la hiérarchie Sales Territory

  1. Affichez le Concepteur de dimensions pour la dimension Sales Territory, puis cliquez sur l'onglet Structure de dimension.

  2. Dans les volets Niveaux et Hiérarchies, cliquez sur la hiérarchie Sales Territories et développez Sales Territory Region et Sales Territory Country.

    Remarquez que Sales Territory Group est lié directement à Sales Territory Region, l'attribut clé, et n'est pas lié à l'attribut Sales Territory Country.

  3. Faites glisser la relation d'attributs Sales Territory Group de l'attribut Sales Territory Region vers la balise <nouvelle relation d'attributs> pour l'attribut Sales Territory Country.

    L'attribut Sales Territory Group est maintenant lié à l'attribut Sales Territory Country et l'attribut Sales Territory Country est maintenant lié à l'attribut Sales Territory Region. La propriété RelationshipType de chacune de ces relations doit avoir la valeur Flexible, car le regroupement des régions d'un pays peut changer dans le temps et parce que le regroupement des pays dans les groupes peut également changer dans le temps.

    Remarque   Vous pouvez définir des relations d'attributs pour les hiérarchies définies par l'utilisateur dans le volet Attributs ou le volet Hiérarchies et Niveaux.

Définition des relations d'attributs pour les attributs dans la hiérarchie Product Model Lines

Pour définir des relations d'attributs pour les attributs dans la hiérarchie Product Model Lines

  1. Affichez le Concepteur de dimensions pour la dimension Product, puis cliquez sur l'onglet Structure de dimension.

  2. Dans le volet Attributs, développez les attributs Model Name et Product Name.

  3. Faites glisser la relation d'attributs Product Line de l'attribut Product Name vers la balise <nouvelle relation d'attributs> pour l'attribut Model Name.

    La valeur de la propriété RelationshipType pour cette relation d'attributs doit être Flexible, car la relation entre une ligne de produits et un nom de modèle peut changer dans le temps.

Définition des relations d'attributs pour les attributs dans la hiérarchie Fiscal Time

Pour définir des relations d'attributs pour les attributs dans la hiérarchie Fiscal Time

  1. Affichez le Concepteur de dimensions pour la dimension Time, puis cliquez sur l'onglet Structure de dimension.

  2. Dans le volet Attributs, développez les attributs suivants :

    • Date
    • Month Name
    • Fiscal Quarter
    • Fiscal Semester
  3. Faites glisser la relation d'attributs Fiscal Quarter de l'attribut Date vers la balise <nouvelle relation d'attributs> pour l'attribut Month Name, puis affectez à la propriété RelationshipType la valeur Rigid pour cet attribut.

  4. Faites glisser la relation d'attributs Fiscal Semester de l'attribut Date vers la balise <nouvelle relation d'attributs> pour l'attribut Fiscal Quarter, puis affectez à la propriété RelationshipType la valeur Rigid pour cet attribut.

  5. Faites glisser la relation d'attributs Fiscal Year de l'attribut Date vers la balise <nouvelle relation d'attributs> pour l'attribut Fiscal Semester, puis affectez à la propriété RelationshipType la valeur Rigid pour cet attribut.

Définition des relations d'attributs pour les attributs dans la hiérarchie Calendar Time

Pour définir des relations d'attributs pour les attributs dans la hiérarchie Calendar Time

  1. Dans le volet Attributs, développez Month Name, Calendar Quarter et Calendar Semester.

  2. Faites glisser la relation d'attributs Calendar Quarter de l'attribut Date vers la balise <nouvelle relation d'attributs> pour l'attribut Month Name, puis affectez à la propriété RelationshipType la valeur Rigid pour cet attribut.

  3. Faites glisser la relation d'attributs Calendar Semester de l'attribut Date vers la balise <nouvelle relation d'attributs> pour l'attribut Calendar Quarter, puis affectez à la propriété RelationshipType la valeur Rigid pour cet attribut.

  4. Faites glisser la relation d'attributs Calendar Year de l'attribut Date vers la balise <nouvelle relation d'attributs> pour l'attribut Calendar Semester, puis affectez à la propriété RelationshipType la valeur Rigid pour cet attribut.

Définition des relations d'attributs pour les attributs dans la hiérarchie Geography

Pour définir des relations d'attributs pour les attributs dans la hiérarchie Geography

  1. Affichez le Concepteur de dimensions pour la dimension Geography, puis cliquez sur l'onglet Structure de dimension.

  2. Dans le volet Attributs, développez les attributs suivants :

    • City
    • Geography Key
    • Postal Code
    • State-Province
  3. Faites glisser la relation d'attributs City de l'attribut Geography Key vers la balise <nouvelle relation d'attributs> pour l'attribut Postal Code.

    Étant donné que les codes postaux d'une ville sont susceptibles de changer dans le temps, la valeur appropriée pour la propriété RelationshipType de cet attribut est :Flexible.

  4. Faites glisser la relation d'attributs State-Province de l'attribut Geography Key vers la balise <nouvelle relation d'attributs> pour l'attribut City, puis affectez à la propriété RelationshipType la valeur Rigid pour cet attribut.

  5. Faites glisser la relation d'attributs Country-Region de l'attribut Geography Key vers la balise <nouvelle relation d'attributs> pour l'attribut State-Province, puis affectez à la propriété RelationshipType la valeur Rigid pour cet attribut.

  6. Définissez l'attribut Geography Key sur non visible, non optimisé, non ordonné.

  7. Déployez le projet Didacticiel Analysis Services.

Tâche suivante de la leçon

Définition du membre inconnu et des propriétés de traitement Null

Voir aussi

Autres ressources

Définition et configuration d'une relation d'attributs
Configuration des propriétés des hiérarchies définies par l'utilisateur

Aide et Informations

Assistance sur SQL Server 2005