Discussion :

[cana13]

Bonjour à tous,

Je rencontre le problème suivant :

J'ai une table client contenant 3 colonnes structurée de la maniere suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Code_client  Branche  Société
C1..............B1..........S1
C2..............B2..........S1
C3..............B1..........S2
C4..............B3..........S2
...

Les clients appartiennent à des branches et à des sociétés.
La clé unique de ma table est le code client

Je crée ma dimension client avec mes 3 attributs Code_client, branche et société.

Je passe à mes hiérarchies :
Si je crée une hiérarchie simple Société - client, ça marche
Si je crée Branche - Client ça marche aussi
mais dés que je veux faire Société - branche - client je me heurte sans cesse au problème de doublon sur des clés d'attribut.
Je précise que j'ai créé mes relation d'attribut de la façon suivante : client -> branche -> région.

J'ai lu qu'il fallait modifier le keycolumns de mes attributs pour le rendre unique en mettant des clés composites. J'ai essayé 36 combinaisons mais rien ne fonctionne : help ! comment faut il faire ?

je m'arrache les cheveux depuis ce matin sur ce problème !

[FrancoisJehl]

C'est un petit peu le même problème que ce sujet là: http://www.developpez.net/forums/d92...es-dattributs/

A savoir simplement que SSAS procède de cette manière avec les AttributeRelationships: il part du niveau le plus fin et cherche le membre parent en suivant les chemins d'aggrégations que tu as défini.

Dans ton cas il part du client, C1 par exemple, et cherche son "parent", le niveau supérieur, à savoir Branche. Il regarde la KeyColumn, il n'y a qu'un client C1, le parent est donc B1.
Il continue, il prend tous les membres de "Branche" qui s'appellent B1 (i.e. KeyColumn=B1) et cherche le parent... et là patatras: B1 a deux parents possibles, S1 et S2 et ça c'est interdit.

J'ai lu qu'il fallait modifier le keycolumns de mes attributs pour le rendre unique

Bien vu, pour que chaque membre de chaque niveau dans le design d'aggrégation n'ai qu'un seul parent pour une KeyColumn donnée. Cela signifie que le niveau branche n'a pas pour clé uniquement la colonne Branche (tu as deux branches de même clé qui sont en réalité différentes, car de sociétés différentes). Tu dois prendre les colonnes Branche et Société, et là tu as bien B1S1 et B1S2 qui sont deux branches différentes, disposant chacune d'une société mère unique pour leur KeyColumn.

[cana13]

Ok, je comprends bien le mécanisme pour une hiérarchie et je vais essayer de le mettre en œuvre.

Par contre, j'ai la même erreur sur une dimension qui ne contient pas de hiérarchie. Et effectivement, en regardant le message déjà posté dont tu fournis le lien
http://www.developpez.net/forums/d92...es-dattributs/

certains attributs peuvent se retrouver plusieurs fois de manière identique dans des enregistrements différents. par exemple j'ai un statut = 0 actif et = 1 inactif. Si je met une clé unique au niveau du Keycolum, je ne vais plus avoir d'erreur mais lorsque l'utilisateur voudra filtrer sur ce statut, il verra n fois actif et n fois inactif dans la liste déroulante, non ?

[FrancoisJehl]

En relisant le thread que tu as reposté j'ai été un peu rapide en besogne. Dit rapidement il y a deux raisons pour se prendre le doublon de clés d'attributs:
- Un problème d'AttributeRelationships (cf plus haut, souvent dans le cas où on a mis en place des hiérarchies U mais l'un est l'autres peuvent exister séparément)
- Un problème de NameColumn: quand à une valeur de KeyColumn peuvent correspondre plusieurs valeurs de NameColumn: comment choisir lequel afficher. Cas typique:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Annee;Mois;Label
2001;01;Janvier 2001
...
2002;01;Janvier 2002

Si je ne prends que Mois comme KeyColumn et Label comme NameColumn SSAS crashe en m'expliquant que pour le membre de clé 01 il existe plus d'un label possible.

[cana13]

oui, je comprends bien tes explications mais :

1/ cela ne répond pas à la problématique posé : si j'ai une colonne avec un statut = 0 actif et = 1 inactif, en mettant une clé unique ça résout l'erreur mais lorsque l'on navigue sur cet élément de la hiérarchie, on voit des dizaines de fois la même valeur s'afficher (dans mon exemple des dizaines de 0 et des dizaines de 1) alors qu'il n' y a en fait que 2 statut distinct...

2/ c'est à ni rien comprendre ! : dans ma dimension j'ai d'autres colonnes dans le même cas (avec des doublons à la pèle) et cela passe comme dans du beurre lors du traitement de la dimension ! et dans ce cas le résultat attendu dans la navigation est celui que j'escompte : il fait un distinct sur la liste et les éléments n'apparaissent bien qu'une fois. Comment expliquer ces différences ?

[FrancoisJehl]

Je te confirme tu as parfaitement le droit d'avoir un membre qui n'est pas unique dans une hiérarchie... Et heureusement! Ton attribut Statut n'a bien une attribute relationship qu'avec l'attribut clé? Dans ce cas KeyColumn sur statut et ca devrait passer... Tu as quoi comme erreur exactement sur statut? Son libellé c'est quoi?

[cana13]

La, c'est tout simple, je ne suis même pas sur une hiérarchie. J'ai ma dimension AFFAIRE qui contient un attribut AVANCEMENT (= 0 pour actif , = 1 pour inactif). Pour le moment il n'y a pas de libellé.
Ma keyColumns est AVANCEMENT. Mon NameColumn est <aucun>.

le message d'erreur est :
Un doublon de clé d'attribut a été trouvé lors du traitement de*: Table*: 'dbo_DIM_AFFAIRE', Colonne*: 'AVANCEMENT', Valeur*: '0'. L'attribut est 'AVANCEMENT'.

dans ma relation d'attribut j'ai : CODE AFFAIRE -> AVANCEMENT

en pièce jointe les 2 copy d'écran correspondantes :

[cana13]

Je crois avoir trouvé ! il y avait des valeurs null dans mon attribut AVANCEMENT. En remplaçant dans ma table les valeurs null par 0 je n'ai plus l'erreur. Ce qui explique que je n'avais pas le problème sur d'autres attributs qui eux étaient tous renseignés.

Crois tu que cela puisse venir de la ?

[FrancoisJehl]

Je te confirme AS pète aussi cette erreur quand tu as des NULL en KeyColumn je n'y pensais plus!

[cana13]

Un grand merci pour ton aide. Je vais avancer sur mon cube.

Bonne journée.

[Jinroh77]

On se fait souvent avoir par cette gestion des NULL.
Cela oblige à remplir la colonne avec une autre valeur qui n'est pas utile alors que cela prendra beaucoup plus de place que du NULL.

[cana13]

Oui, tout à fait. C'est curieux que SSAS microsoft n'ai rien prévu pour gérer ce cas. Il aurait pu prévoir un UnknownMember un peu comme dans la définition d'une relation entre table de fait et dimension.

Et c'est d'autant plus étrange que sur certains autres attributs, j'ai des null et ça passe très bien au traitement (allez savoir pourquoi !).

[Jinroh77]

Ça va dépendre des relations que tu as.
Si un NULL dans un champs implique systématiquement les mêmes valeurs dans les autres champs, c'est ok.

[cana13]

C'est à dire ?

j'ai une dimension simple, sans hiérarchie. elle possède un quinzaine d'attributs, tous de type regular et wchar. Aucun de ces attributs ne pointe ou n'est en relation avec autre chose que ma clé de dimension. dans ma table, j'ai des valeurs NULL + des valeurs renseignées pratiquement sur chacun de ces attributs. Certains ne passent pas (j'ai du forcer des valeurs par défaut lors de l'alimentation de ma base décisionnelle) d'autres oui ...

que veut dire :

Si un NULL dans un champs implique systématiquement les mêmes valeurs dans les autres champs,

[patriceharel]

Bonjour,

Cela dépend pour beaucoup du type de la colonne SQL source. C'est souvent parce que c'est une colonne de type bit (boolean) que les null ne peuvent être processés par AS.
Généralement ce que je fais, c'est une colonne dérivée avec des string 'yes'/'no'.

[FrancoisJehl]

Bah de toute manière le principal problème vient du NullProcessing de ton attribut: basiquement avec un NullProcessing en Automatic (le défaut), cela fonctionne en mode ZeroOrBlank pour les attributs: les chaînes NULL sont converties en '' (chaîne vide), et les types numériques en 0.
Or si tu as déjà une "vraie" valeur de KeyColumn qui vaut 0 ou '' ça pète car comme cette conversion a lieu après la requête SELECT DISTINCT du processing sur la colonne source tu te retrouves avec deux valeurs identiques. Idem avec une vraie valeur à chaîne vide.
C'est souvent pour ça que les gens se mangent l'erreur: une valeur à NULL et une à 0 coexistant qui sont reconverties en 0 toutes les deux. D'où l'idée d'éviter des NULL dans ce qu'on envoie à AS.

[patriceharel]

Nickel, c'est l'info que je cherchais :

cette conversion a lieu après la requête SELECT DISTINCT du processing

Je ne comprenais pas pourquoi mes attributs booléens posaient problème. Maintenant c'est bon.

Merci François