CS(Case Sensitivity) にしたいと思ってもできないのです。なぜならサービスで提供されている環境だし、バラバラのセッティングすべてへのサポートは合理的ではないから、SQL Server Analysis Services (SSAS) や Azure Analysis Services (AAS) のようにカスタマイズできないのある。言語ごとに既定の照合順序が設定されているのでそのまま使う。で、どうするかって話。
設定は？
Power BI Desktop の [オプション] - [グローバル] - [地域の設定] - [モデルの言語] で選択。言語を選択するだけだから個別に変更できないのだ。
CI / AS / KS / WS
どうなっているかを確認
インポートするとこうなる。CI / KS / WS でしょう。
- CI : 大文字小文字は区別しない
- KS : かなカナは区別する
- WS : 全角半角は区別する
- サンプルを用意するの忘れたけどたぶん AS
CS にできないので
照合順序の指定ができないのだけど、CS のようにしたいときどうするか。
行の識別子を追加してもダメですよ
列ごとにエンコードされるだけだし、行の識別子があろうがなかろうが関係ないのです。
ゼロ幅スペース 足しときゃいいんじゃね？
列に含まれる値(文字列)は ハッシュタイプ のエンコード。照合順序で同一とみなしくない値は表示に影響がない程度に変更しディクショナリーに登録されるようにすればよいかなと。フィルタ条件がちょい手間になるけど、ディメンジョン テーブルであれば行の識別子で。
let
Source = #table(
type table [ id = Int64.Type, 全部あっぷる = text ],
{
{ 1, "APPLE" },
{ 2, "apple" },
{ 3, "ＡＰＰＬＥ" },
{ 4, "ａｐｐｌｅ" },
{ 5, "アップル" },
{ 6, "ｱｯﾌﾟﾙ" },
{ 7, "あっぷる" }
}
),
#"Added Custom" = Table.AddColumn(
Source, "全部あっぷる改",
each
[全部あっぷる]
& Text.Repeat( Character.FromNumber( 8203 ), [id] ),
type text
)
in
#"Added Custom"
CI なんだけど比較式は
なんとか大文字小文字は区別してインポートできたとしても、メジャーなどDAX 式については引き続き照合順序に基づき評価される。
EXACT 関数 (DAX) や CONTAINSSTRINGEXACT 関数 (DAX) という、大文字小文字区別して評価する関数が用意されているので必要に応じて使えばよい。
// true
"APPLE" = "apple"
// true
"APPLE" == "apple"
// false
EXACT( "APPLE", "apple" )
// true
CONTAINSSTRING( "PINEAPPLE", "apple" )
// false
CONTAINSSTRINGEXACT( "PINEAPPLE", "apple" )
emoji はどうするか
ちょっと面倒だなと思うことは起きる。照合順序の挙動により置き換わってしまう絵文字とかあるんだよね。UnicodeのEmojiの一覧 - Wikipediaにあるうちで確認するとだいたい150程が影響を受けるんですよ。ただし、[モデルの言語]が英語であるとき影響はなくて、私たちが一番多く使うであろう[モデルの言語]が日本語であるとき。たぶん 英語以外はすべてで影響がある。
なぜ置き換わる動作が発生するかについては、インポートモードのエンコードの仕組みについて知っておくとよい
ゼロ幅スペースを追加して区別させるとよいかもしれない。
データがインポートされるとき照合順序で区別されるようにすればよいのだから、大文字小文字の区別同様ゼロ幅スペースを追加して区別させるとよいかもしれない。
Table1 =
{
( "⭕", "⭕" ),
( "❌" ,"❌" & UNICHAR( 8203 ) ),
( "⚾うぇーぃ", "⚾うぇーぃ" & REPT( UNICHAR( 8203 ), 0 ) ),
( "う⚽ぇーぃ", "う⚽ぇーぃ" & REPT( UNICHAR( 8203 ), 1 ) ),
( "うぇ⛵ーぃ", "うぇ⛵ーぃ" & REPT( UNICHAR( 8203 ), 2 ) ),
( "うぇー⛳ぃ", "うぇー⛳ぃ" & REPT( UNICHAR( 8203 ), 3 ) ),
( "うぇーぃ❔", "うぇーぃ❔" & REPT( UNICHAR( 8203 ), 4 ) )
}
いっそのことモデルの言語を英語に
もっとも手間がかからなそうなのがモデルの言語を英語にしてしまうこと。ただ、モデルの言語が日本語であるときの特有の動作と照合順序が異なる可能性から期待する評価にならないことはあるかもしれない。そのことで困ったことはないし、FORMAT 関数(DAX)の日付書式文字列の一部(元号 ggge や 曜日 aaaa)が使えなくても何とかなるでしょ。
モデルの言語に限らずDAX式の評価 -emoji-
// false
"⚽" = "🏀"
"⚽" == "🏀"
EXACT ( "⚽", "🏀" )
CONTAINSSTRINGEXACT( "⚽", "🏀" )
// true
"⚽" = "⚾"
"⚽" == "⚾"
// false
EXACT( "⚽", "⚾" )
// true
CONTAINSSTRINGEXACT( "⚽", "⚾" )
思ったこと🙄
いろいろ試して調べていて、モデルの言語(Culture)が日本語であるとき、照合順序(Collation)は Japanese_XJIS_100_CI_AS_KS_WS って感じかなと。
SSAS では _100 / _90 とか BIN2 で Collation の設定ができるから、Power BI データモデルでも技術的には可能なんだけど、インポートされるときやDAX式が評価されるときの照合順序が影響してしまうから、思ってもない結果を得る場合がある。Power BI で Collation を変更することはやってはいけないことではある。でも勉強にはなる。