Erreur "clé d'attribut en double" lorsque l'attribut n'est pas une clé
Je reçois le message d'erreur suivant lors du traitement d'une dimension:
Erreurs dans le moteur de stockage OLAP: une clé d'attribut en double a été trouvé lors du traitement: Tableau: 'dbo_Orders', Colonne: 'Projet', Valeur: «service à la clientèle». L'attribut est 'Projet'.
'Projet' est un attribut de la dimension 'Ordres', mais pas une clé. Nulle part je n’ai indiqué que la colonne Projet est une clé! Je devrais pouvoir avoir autant de doublons que nécessaire, tout comme un champ de prénom.
Je suis nouveau dans le projet Analysis Services et j'ai vraiment besoin de dépasser le fait que SSAS se plaint constamment de valeurs en double alors qu'il devrait être parfaitement correct d'avoir des valeurs en double. Je suis sûr que cela doit être quelque chose de simple que je néglige.
Edit: Je me rends compte qu’il est possible de définir KeyDuplicate = ReportAndContinue/ReportAndStop et de définir KeyColumns et NameColumns. Mais ce processus en plusieurs étapes semble très fastidieux car ce qui semble être une opération très normale, telle que l’ajout d’Adresse1, Adresse2, Adresse3, Prénom, Code postal et autres champs normalement dupliqués. Je ne peux pas croire que ce processus fastidieux doive être appliqué à tous ces domaines?
Merci d'avance.
Cela est généralement dû à la présence de blancs et de valeurs NULL dans la table/vue source.
SSAS le fait essentiellement pour chaque attribut SELECTIONNER LA COALESCE DISTINCTE (attr, '') DE LA SOURCE
Analysis Services convertit par défaut les valeurs NULL en blancs, ce qui entraîne des blancs en double dans le flux résultant, d'où l'erreur.
Je suis d'accord que ça craint et est une douleur majeure pour les nouveaux joueurs.
Solution: supprimez toutes les valeurs NULL de la source de données, par exemple en utilisant ISNULL/COALESCE partout, en filtrant les lignes contenant la valeur null à l'aide de la clause where ou en exécutant l'instruction update pour remplacer toutes les valeurs NULL par des valeurs avant le traitement du cube, etc.
Faites un clic droit sur l'attribut et sélectionnez "Propriétés". Recherchez "KeyColumn" qui se trouve sous la catégorie "Source" dans la fenêtre Propriétés. Editez la propriété "KeyColumn", elle affichera une fenêtre conviviale.
Supprimez l'attribut du côté droit (Colonnes clés) de la fenêtre et remplacez-le par la colonne id actuelle du côté gauche (Colonnes disponibles).
Puis éditez la propriété "NameColumn", la même fenêtre apparaîtra. Déplacez la colonne d'attribut (les données réelles que vous souhaitez afficher) de gauche à droite.
Testé dans VS 2010 Shell SSDT.
J'avais le même problème et il n'y avait pas de valeur vide ou NULL dans l'attribut ..__ Après analyse, j'ai constaté que certaines chaînes avaient un caractère de saut de ligne à la fin. Ainsi, si 2 valeurs de l'attribut sont presque identiques, mais que l'une d'elles possède un caractère de saut de ligne à la fin et l'autre pas, SSAS génère l'erreur «Duplicate attribute key».
Il peut être corrigé en supprimant le caractère de saut de ligne de l'attribut.
J'ai créé la colonne calculée avec la définition suivante:
REPLACE(REPLACE(ISNULL([AttributeColumn], ''), CHAR(13), ''), CHAR(10), '')
J'ai utilisé cette colonne calculée dans le cube et l'erreur a disparu.
Cela m'est arrivé aujourd'hui et m'a égratigné la tête pendant un moment, aucune des solutions ici ne fonctionnant. Enfin résolu et pensé que j'ajouterais ma solution pour toute autre personne googler cette erreur et arriver ici juste comme je l'ai fait.
Dans mon cas, ce n'étaient pas des chaînes NULL et des chaînes vierges, car la valeur [NullProcessing] était déjà définie sur "UnknownMember". C'était plutôt la valeur [Trimming], dans mon cas, elle était réglée sur "Right".
Bien que je sache comment j'ai résolu (?), Je ne suis pas sûr à 100% de la raison, mais je suppose que lorsque SQL Server utilise SELECT DISTINCT(col) FROM source et que la valeur [Rogner] est définie comme telle, Analysis Server supprime entre end (ce que RTRIM dans SQL Server ne fait pas, par exemple) et aboutit à des doublons.
Donc régler [Découper] sur "Aucun" pourrait résoudre le problème, puisque les onglets étaient des données dont je n’avais pas besoin (mes données sont analysées/lues/entrées à partir de sources externes). Bien encore.
Alors que mon autre solution sur cette page fonctionne (et selon les situations, elle pourrait être plus idéale), voici une solution alternative:
Voici un extrait d'une partie de mon erreur:
Column: 'attribute1_name', Value: 'Search String'
J'ai fait une recherche rapide pour:
SELECT dim_id,
dim_name,
dim_attribute1.id,
dim_attribute1.name,
dim_attribute2.id,
dim_attribute2.name
FROM dim_table
INNER JOIN dim_attribute1 ON dim.attribute1_id = dim_attribute1.id
INNER JOIN dim_attribute2 ON dim.attribute2_id = dim_attribute2.id
WHERE UPPER(dim_attribute1.name) = UPPER('Search String')
Il s'avère qu'il y a deux entrées différentes pour dim_attribute1.name qui correspondent à ceci:
- Chaîne de recherche
- chaîne de recherche
La première solution les scinde sans problème, c'est donc une solution efficace (plus le bonus de performance). Cependant, une alternative (si l'on veut conserver les valeurs de texte en tant que clés) est de changer le classement:
Key Columns → Column Name → Source → Collation
Pour inclure 'sensible à la casse'.
D'autres problèmes similaires peuvent être des caractères d'espacement et d'autres faciles à ne pas repérer les changements subtils dans le texte.
J'ai eu le problème après avoir joué avec l'ajout d'un ID dans la colonne clé d'un attribut. Depuis, j'avais retiré la clé, mais j'avais constaté que l'instruction select en cours de traitement faisait toujours référence à l'ID, rendant l'attribut non unique. Je ne pouvais pas trouver un moyen de résoudre ce problème via les propriétés d'attribut. J'ai donc supprimé la dimension entière et l'ai recréée. Cela a résolu le problème.
J'ai eu le même problème et j'ai trouvé une solution de contournement.
Clic droit dans "Cube" => "Processus" => "Modifier les paramètres" => "Erreurs de clé de dimension"
Active "Configuration d'erreur personnalisée par l'utilisateur"
Définissez "Ignorer les erreurs" pour cette liste déroulante "Clé introuvable" "Clé dupliquée" "Clé nulle convertie en inconnue" "Clé nulle non autorisée"
Le problème avec les clés sera ignoré.
J’ai eu un problème similaire aujourd’hui (même message d’erreur); pour que tous les autres qui s’y rendent avec le même problème, j’ai mis quelques notes sur mon wiki: http://www.david-halliday.co.uk/wiki/ doku.php? id = bases de données: Oracle & # select_dates_for_ssas_include_hierarchy
Mon cas était SQL (simplifié et reformulé pour défendre l'innocent):
SELECT dim_id,
dim_name,
dim_attribute1.name,
dim_attribute2.name
FROM dim_table
INNER JOIN dim_attribute1 ON dim.attribute1_id = dim_attribute1.id
INNER JOIN dim_attribute2 ON dim.attribute2_id = dim_attribute2.id
La chose étrange était que l'erreur se produisait dans certains cas de dim_attribute1_name mais pas dim_attribute2_name. Cependant, dans ce cas particulier, l'attribut était exactement le même. En fin de compte, la solution consistait à modifier le code SQL en:
SELECT dim_id,
dim_name,
dim_attribute1.id,
dim_attribute1.name,
dim_attribute2.id,
dim_attribute2.name
FROM dim_table
INNER JOIN dim_attribute1 ON dim.attribute1_id = dim_attribute1.id
INNER JOIN dim_attribute2 ON dim.attribute2_id = dim_attribute2.id
Puis utilisez dans la dimension (masquant les identifiants dans la liste) la valeur id pour la clé de l'attribut et le nom du nom de l'attribut. Je n'ai jamais vu cela auparavant, mais pour une raison quelconque, c'est arrivé ici. À mon avis, cette solution est préférable à la configuration du cube afin qu’il traite en ignorant les erreurs de clé en double.
Je présume que si l’on construit une dimension en joignant des tables, cela donnera de meilleures performances/fiabilité. Mais ne me citez pas là-dessus.
Veuillez lire ce blog: une clé d'attribut en double a été trouvée ... . Regardez la longue explication de la raison 1. Cela expliquera pourquoi cela se produit exactement.
Merci les gars
Ned
J'ai résolu en spécifiant la COLLATION sur mes vues sur la base de données relationnelle comme suit.
COALESCE ([Description de la transaction], '') COLLATE Latin1_General_CI_AI
Si cela peut aider d’autres quasi-débutants comme moi, je vais exposer une solution que j’ai finalement trouvée après avoir eu du mal avec le message d’erreur «Clé d’attribut d’attribut» tout en essayant de déployer une dimension Date sur plusieurs années. Le message d'erreur indiquait, par exemple, que j'avais des clés d'attribut en double dans mon attribut CalendarQuarter. Au début, cela me confondait parce que chaque année complète comportait quatre trimestres (c’est-à-dire 1, 2, 3 et 4), donc j’avais bien sûr des doublons. J'ai finalement compris que c'était là le problème - autrement dit (et contrairement au titre du fil), l'attribut WAS était la clé. Je l'ai résolu en ajoutant une colonne de calcul nommée «CalendarQuarterKey» à la table Date de mon DSV afin de générer des clés uniques pour mon attribut CalendarQuarter, par exemple. «20171» au lieu de «1» pour le premier trimestre 2017, «20172» au lieu de «2» pour le deuxième trimestre 2017, etc. Idem avec l'attribut CalendarMonth: chaque année complète a douze mois (c.-à-d. 1, 2, 3 ... , 11, 12), bien sûr, j’y ai également eu des doublons. Même solution: j’ai ajouté une colonne de calcul nommée «CalendarMonthKey» à la table Date de mon DSV afin de générer des clés uniques pour l’attribut CalendarMonth, par exemple. «201701» au lieu de «1» pour janvier 2017, «201702» au lieu de «2» pour février 2017, etc. Ensuite, j'ai utilisé mes nouvelles colonnes «CalendarQuarterKey» et «CalendarMonthKey» en tant que KeyColumn pour mes CalendarQuarter et CalendarMonth. attributs respectivement. Ce n'est peut-être pas la solution préférée, mais cela a fonctionné pour moi et je peux enfin revenir à la construction de mon cube.
J'ai rencontré cette erreur à plusieurs reprises pour diverses raisons, mais j'ai récemment rencontré une cause assez obscure: la présence du caractère bêta ß dans une colonne de texte. Malgré le fait que les milliers de mots uniques de la colonne utilisaient un mélange incontrôlé de tous les codes ASCII obscurs sous le soleil, SSAS n'était étouffé que lors du traitement des valeurs de colonne incluant le symbole ß. Les nullités, les doublons, les découpages, etc., ont tous été systématiquement exclus. Ceci est vraisemblablement lié à un problème insondable et non résolu traité dans l'erreur de clé de duplication SSAS 2012 du thread MSDN avec 'ss' et 'ß' , dans lequel SSAS interprétait les valeurs ß comme 's' pour une raison lorsque les paramètres de classement étaient corrects. Dans mon cas, la définition du classement dans les propriétés de la colonne SSAS pour correspondre au classement de la colonne source SQL_Latin1_General_CP1_CS_AS du côté relationnel n'a pas résolu le problème; Je devais également modifier le classement pour l'ensemble du serveur. Cette solution de contournement peut s'avérer pénible dans certains environnements où d'autres colonnes dépendent de collations différentes, mais elle a contourné ce problème dans mon cas et m'a permis de traiter la dimension sans accroc. J'espère que cela aidera la prochaine personne à trébucher sur le même "gotcha".
Rien de ce qui précède n'a été résolu pour moi. Ce qui a fonctionné était quelque chose de similaire à ce que Eric W. a suggéré.
Je devais configurer plusieurs colonnes de clé pour mes attributs. Par exemple, l'attribut "Ville" nécessite les colonnes de clé "Pays", "État" et "Ville".
Plus d'informations ici: https://www.mssqltips.com/sqlservertip/3271/sql-server-analysis-server-ssas-keyas-column-vs-namecolumn-vs-valuecolumn/
un certain temps nécessitant une clé composite dans keyColumns pour résoudre la clé d'attribut en double
Si vos données contiennent à la fois des valeurs NULL et que '' SSAS attribue une clé d'attribut en double, car il considère que les valeurs NULL sont ''. Vous n'avez pas à toucher vos données pour résoudre ce problème. Vous pouvez accéder à la vue de votre source de données et ajouter un calcul nommé avec l'expression COALESCE (mycolumn, ''), puis l'utiliser dans votre dimension au lieu de la colonne d'origine. Cela résoudra le problème au niveau de la vue de la source de données et la dimension sera traitée correctement.
Si vous souhaitez continuer avec le déploiement et la navigation dans les cubes, donnez-moi une solution. Sous la fenêtre 'Process Cube', modifiez les paramètres d'erreur relatifs aux clés de dimension en personnalisant… ... Le compromis… ici est que vous pourriez ne pas obtenir les résultats escomptés.