PostgreSQL リーダ SELECT Statement の使い方

[TJ]

FME 2017.0.1.1
PostgreSQL 9.5

いつも WHERE Clause しか使っていないので、あまり気にしたことがないのですが、PostgreSQL リーダのパラメータ設定画面に SELECT Statement のオプションんがあります。これの使い道及び使い方を教えていただけますでしょうか。

[Takashi Iijima]

そのフィーチャータイプが属するリーダーのデータセットとして指定したデータベースに対するSQLクエリ (select 文) を指定すると、フィーチャータイプを作成するときに指定したテーブルのスキーマとは無関係に、そのクエリの結果が出力されます。

ただし、出力されるフィーチャーのフィーチャータイプ名 (fme_feature_type 属性の値) は、フィーチャータイプを作成したときのテーブル名のままです。

例えば、データベースに次の２テーブルがあるとき

public.abc (列: a, b, c)

public.xyz (列: x, y, z)

キャンバスに public.abc フィーチャータイプ (属性: a, b, c) を追加し、その SELECT Statement に次のSQL文を設定して実行すると、

select * from public.xyz

public.xyz テーブルの全レコード = 属性 x, y, z を持ったフィーチャー (fme_feature_type = public.abc) が出力されます。

Workbench 画面上に表示される属性名は a, b, c のままですが、それらは <missing> となり、x, y, z を後続のトランスフォーマーで参照するには、どこかで expose する必要があります。

SQLCreator/SQLExecutor トランスフォーマーが導入される前に、SQL文によるテーブル結合などを行うために設けられたパラメーターが引き継がれているのではないかと想像しています。

現在は、SQLCreator/SQLExecutor でSQL文が実行できるので、このパラメーターを使わなければならない場面はないと思います。

効果的な使い方を発見したら、教えてください。

[TJ]

詳細なご解説ありがとうございました。

でも確かにそのような使い方でしたら、SQLCreator/SQLExecutor トランスフォーマーのほうがより使いやすいと思います。なかなか使い場面思いつきませんね。

[Takashi Iijima]

FME Knowledge Center Q&A Forum でも類似の質問がありました。

Example SQLITE reader with SQL Parameters

このパラメーターの典型的な用途としては、多数のフィールドを持つテーブルから必要なフィールドのみを読み込むようなケースが想定されているのかも知れません。

全てのフィールド (属性) を読み込んでから AttributeRemover または AttributeKeeper で不要な属性を削除するよりは、SELECT 文によって、はじめから必要なフィールドだけを読んだ方が、通常は効率が良いと考えられますから。

[Takashi Iijima]

その他、select文に order by 句を含めることによって入力フィーチャーをソートするのも、このパラメーターの比較的効果的な使い方かも知れませんね。

しかし、いずれにしても SQLCreator/SQLExecutor で対応できることなので、どうしてもこのパラメーターを使わなければならない、というわけではありません。

[TJ]

追加情報をいただき、ありがとうございます。

テーブル結合、SQL属性を絞りたい、属性ソートなどの場面では、確かに SELECT Statement を指定したほうが効率的だと思います。これは当初このパラメータが設計された理由かもしれませんね。

しかし、両者を比較してみて、以下の３点により、SQLCreator/SQLExecutor のほうが使い勝手がいいと私が思います。

1. データベースリーダの SELECT Statement の Text Editor 画面では、指定したデータベースのテーブル名、属性名が左側に表示されないため、SQL 文に使用するテーブル名、属性名など全て手入力しないといけません。SQLCreator/SQLExecutor トランスフォーマーの場合、SQL Statement の編集画面では、指定したデータベースのテーブル名、属性名が左側の Database Tables カテゴリに表示されます。マウス操作で簡単に基本の SQL 文を作成可能です。
   
   
2. データベースリーダの場合、SQL の結果にリーダ指定テーブル以外の属性が含まれている場合、リーダの後、AttributeExposer を接続して、手動で属性の公開を行わなければいけません。SQLCreator/SQLExecutor トランスフォーマーの場合、Attributes to Exprose の Populate from SQL Query から、指定した SQL 文より、属性名を自動取得可能です。
   
   
3. SQLExecutor トランスフォーマーの場合、フィーチャごとに個別 SQL 文を実行可能です。
   

[Takashi Iijima]

同感です。私も、SQLCreator/SQLExecutor の方が使い易いと思います。

ただ、これらのトランスフォーマーは、最初からこんなに使い易かったわけではありません。

SQLCreator/SQLExecutor に「マウス操作で簡単に基本の SQL 文を作成」する機能が追加されたのは、比較的最近（FME2015 か 2016）のことです。

ベータ版の段階で、データベースのタイプによるSQL構文の微妙な違いがきちんと反映されるよう、何度か Safe 社とやりとりしたことを記憶しています。

また、はっきりとは覚えていませんが、Populate from SQL Query が導入されたのも、そんなに古いことではなかったと思います。

これらのトランスフォーマーのアップグレードにあわせて、相対的にリーダーの SELECT Statement パラメーターを使うメリットは小さくなった、ということなんだと思います。