Googleデータポータルの計算フィールドで条件分岐にはまる

Googleデータポータルには計算フィールドがある。

CASE文による条件分岐も可能である。

なので、以下の問題を簡単に解決できると思っていた。

あるフィールドに数字が12桁入っている場合最後の3桁を除いた先頭9桁を抽出する

同じフィールドにアルファベットを含む文字列が入っていた場合は小文字にするだけで桁数は変更しない

CASE
WHEN REGEXP_MATCH(SKU,'^([0-9]{12}$')
THEN LEFT_TEXT(SKU,9)
ELSE LOWER(SKU)
END

　まぁこんな感じで楽勝と思っていた。

　しかしやってみるとエラーで使えない。

　データポータルのCASE文ではTHENやELSEに数式や関数を含めることが出来ないとの事。

　え？

　それじゃあ分岐しても出来ることが限られる。

　この仕様を回避するためにはTHENの結果とELSEの結果をあらかじめ計算フィールドで作っておいて呼び出す必要がある。

　そうすると目的を達成するためには三つの計算フィールドが必要になってしまう。

　こんな単純な処理を実現するために三つも計算フィールドを作るのはなんか変な感じがする。それほど大変な作業ではないけど、無闇にフィールドが増えるのは管理が煩雑になる。

　なのでなんとか他の方法で解決できないか考えてみた。

　REGEXP_REPLACE関数でなんとかなるような気がした

　こんな感じで数字12桁の時は9桁に削る

　regexp_replace(SKU,'^([0-9]{9})([0-9]{3}$)','\\1')

　いける気がしたが、計算フィールドにはregexp_replaceは一つしか設置出来ないようで文字列が含まれる場合に対応できないのと、そもそも置換文字列にフィールドや関数を含めることは出来ないっぽい

　上の9桁に削る例でもleft_text関数とフィールドではなく、先頭9文字をキャプチャーして利用している。

　まぁこれでこの計算フィールドにlower関数を行うだけの計算フィールドを作れば計算フィールドの数は２に削減される。三つ作るよりはマシか。

　精度を無視すればlower(left_text(SKU,9))で、一つの計算フィールドですんでしまうんだけど、これの精度を上げようと思った瞬間になんと面倒なことになることかと今回実感した。

整理すると以下のようになる

SKU（元のフィールド）

SKUlower（元のフィールドを小文字化する計算フィールド）

lower(SKU)

SKU9（SKUlowerに対して数字12桁のみ9桁に削る計算フィールド）

regexp_replace(SKUlower,'^([0-9]{9})([0-9]{3}$)','\\1')

　これで問題なく課題は解決した。

　作ってしまえば計算フィールドが一つ増えただけで精度はぐっと高まった。

　lower(left_text(SKU,9))だけで処理していた時は文字が含まれても9桁にしていた為失われていたデータがあるかもと思ったが、実際変更してみたら多くの失われていたデータが表面化した。

　面倒でも精度を高めるという事はとても重要だなぁと、今まで放置していた事を反省した。

　そして、GoogleデータポータルのCASE文による条件分岐は機能がシンプルすぎて使いづらい事が良くわかった。

　ただ、割り切って計算フィールドをどんどん作ってしまうならばそれなりに複雑な処理をこなすことも可能。

　今回色々と試行錯誤してみて計算フィールドを多数作ることがGoogleデータポータルの作法なのかなと思った。

四海のほとり