Data Model / DAXの基礎 2_ルールいろいろ②

前回の続きで、今回はネーミングロジックについて話をしていきます。DAXを実際に記述する前に抑えておきたい必読コンテンツとなります。

前回記事は以下より

marshal115.hatenablog.com

ネーミングロジック

ネーミングロジックとは難しそうに聞こえますが、実際には

メジャー名・テーブル名・列名を日本語にするか、英語にするか

という選択を意味します。

結論から言いますと、私の中では、

英語表記が最も運用しやすい

と考えています。理由は単純で以下3つがメリットとなります。

  1. DAXを多く記述する必要が場合、圧倒的に効率が高い
  2. メジャーを検索する場合、フィルター機能で素早く見つけ出すことが可能
  3. 英語表記であっても、レポート上では日本語表記に直すことが可能

特に1と2が最も重要で、自分が書きたいDAXで対象列を参照する場合や書いたDAXを検索する際に、英語表記で書いたほうが圧倒的にパフォーマンスが良く、かつ、ストレスを減らすことができるのです。

ここで「ストレスを減らす」という表現をしましたが、DAXを素早く検索したい場合、日本語だと漢字で検索しないとDAXを見つけることができなくなり、アルファベットで検索したほうが効率的ということです。

1. DAXの記述

まずはDAXの記述について、具体例を見てみましょう。例えば、売上高というメジャーを作るとします。「売上実績」という日本語テーブルと「Sales」という英語テーブルにそれぞれ、①日本語、②英語で同じメジャーを記述します。

f:id:marshal115:20210425011134p:plain

どちらの場合でもテーブルを選択して右クリック > 新しいメジャーと選択し、以下のようにそれぞれメジャーを作ります。ここまで話してきたDAX記述に関するルールに従って、「テーブル名 + 列名」DAXを書こうとした場合、上記①と②を比較すると、日本語ベースで作ったテーブル(①)ではテーブル名がインテリセンス(Excelの関数のように、途中まで入力すると候補が提示される機能)で出てこないことに対して、英語ベースのテーブルでは即座ににテーブル名が出現し、インテリセンスを享受することができます。

f:id:marshal115:20210425012635p:plain

その結果、②のほうでは簡単に[SalesAmt]というメジャーを作ることができました。なお、Excelの関数入力時と同様、途中でインテリセンスが出現した場合、Tabキーをクリックすると項目がフルで抽出されるようになります。

f:id:marshal115:20210425011727p:plain

一方、①のほうで同様に[売上高]というメジャーを作る場合、テーブル名「売上高」を記入しても、なぜかインテリセンスが働かず、一番下までスクロールしないとテーブルを指定できません。

f:id:marshal115:20210425013542p:plain

ここで鋭い人は「売上実績」テーブルの前に「'」が入っていることに気が付くはずですが、実はSUM ( の後にこの「'」を最初に入れてからでないと、日本語テーブル名を一番上に持ってくることができないのです。ただ、この場合も漢字入力をするためには変換キーを押す必要があり、②のSUM ( Salesを入力する手間より約1秒以上も時間が掛かってしまいます。

DAXを数十個程度しか使わないというケースであれば、この場合あまり気にならないかもしれませんが、取引実績テーブルが複数ある場合にはDAXで作るメジャーが余裕で数百個を超える場合もあり、私だったら非常にストレスを感じてしまいます。これが英語テーブルを使用した場合、圧倒的に効率が良いと言われる理由となります。

ちなみに、上記のように、テーブルを右クリックして「新しいメジャー」を作成した場合、メジャーは必ずそのテーブルに格納されるようになっており、誤って[SalesAmt]というメジャーをdCalender(日付テーブル)等のテーブルに作ってしまう心配はありません。一方、下図のように、「ホーム」> 「新しいメジャー」という流れでもメジャーを作ることは可能ですが、期待するテーブルとは異なるテーブルにメジャーを作ってしまう可能性があり、気付かずに大量に作ってしまってから、メジャーの大移動なんてことも起こりえます。 

f:id:marshal115:20210425011342p:plain

そうなった場合には、以下のようにホームテーブルを移動してあげる必要があり、この無駄な作業をしないため、メジャーを作るときは必ず、

そのメジャーと同じ属性のテーブルにメジャーを作る

ことを心がけてください。

f:id:marshal115:20210425014821p:plain

なお、同じ属性でないテーブルにメジャーを作っても、計算結果に全く影響はないのですが、例えばメジャーを検索する際に[SalesAmt]というメジャーがSalesテーブルにきっと存在するという考え方ができなくなってしまい、メジャー検索時のストレスの原因となります。

※ 最後に勘違いしてほしくないのですが、ここまでの話はDAXを数年間ひたすら書き続けてきた私の私見であり、英語が苦手、どうしても日本語でのネーミング(テーブル・メジャー)が良いという方はそちらを採択して全く問題ありません。

2. メジャーの検索

上述の通り、DAXの記述は好みが分かれるところですが、記述後のDAXを検索する場合について見てみます。まずは②の英語テーブルにある英語メジャーを検索する場合、以下のようにPower BIの一番右にあるフィールドの下にある検索ウィンドウにSalesと半分打ち込んだだけで、Salesというキーワードを含むテーブルや全てのメジャーが全てフィルターされた状態で出現してきます。

f:id:marshal115:20210425020345p:plain

英語で検索できるようにしておくと、メジャ数ーが多いデータモデルでものすごく効率的に対象となるメジャーを探し出すことが可能となりますので、個人的にはここでもやはり英数字ベースでのメジャーを作ることをお勧めします。
なお、英語ベースのメジャーは自分にしか中身が分からないという一見するとデメリットがあるようですが、実は

  • 簡単なメジャー名(例:SalesAmt(売上高)、InvAmt(在庫高)、GM%(粗利益率)、等)であれば名称を見た瞬間、それとなく分かってしまう
  • 複雑なメジャーの場合、コメントを残しておくことが良い対応(下図)

    f:id:marshal115:20210425021100p:plain

  • DAXに慣れてくると、DAXコードを見ただけで何を計算しているかが分かるようになる

等のことができるようになります。一方で、①のように日本語で検索しようとすると、年次総計売上が英語表記であればmatと入力しただけですぐさま検索できてしまうことに対して、日本語で検索する場合は入力ミスや変換作業が発生するため、一発で検索できないがゆえにストレスが溜まってしまうことが多々あります。このことから、やはり英語ベースのネーミングを使用したほうがメリットは高いと個人的に思います。

3. メジャーのレポート上の日本語表記

最後に、英語メジャーを作ってもレポート上でビジュアル化した際、英語を日本語に変更することができることについて見ていきます。上記[SalesAmt][MAT.Sales1]とうメジャーを下記のように、テーブルビジュアルにした場合、①のようにそのままのヘッダー名が表示されてしまいます。そこで、②のように値フィードルでダブルクリックし、名前を変更してあげれば、③の通り、ヘッダー名が日本に変換された状態となりますので、前述の通り、メジャー名を英語表記にしても問題がない、というわけです。

f:id:marshal115:20210425192712p:plain

ここで元のメジャー名が分からなくなったので、後で見直す時に大変であると思われるかもしれませんが、その場合には以下のように、値フィールドにカーソルを合わせると、元のメジャー名が表示されますので、迷うことはなくなります。

f:id:marshal115:20210425193147p:plain

これで冒頭の1~3のメリットについて全て述べてきましたが、英語表記が日本語表記よりも便利であることが分かったかと思います。ただし、今回の話は個人の好みによる部分もあるので、一概にこの通りにすべきである、ということを言いたいのではありません。むしろ、「ルールいろいろ②」よりも「ルールいろいろ①」を徹底することが重要であり、そちらのコンテンツが「~すべき」と認識して頂くことが大事です。

まとめ

  • 英語表記でテーブル名、列名を定義したほうが効率が高い場合が多い
  • 必ずしもこのルールに従う必要はないが、まずは参考にしていただき、あとは個人の使い勝手で判断して頂くのがベスト

DAXに関する細かいルールはまだまだあり、今後も少しずつ紹介していきたいと思います。