【コラム】3) GeneXusを使う意義

ちょっと大げさなタイトルです。

意義とは「その事柄にふさわしい価値」とあります。ですから「GeneXusを使うにふさわしい(使うに見合う)価値」とはなんでしょうか?

これはテーマが広いですね。例えば、プログラムコード自動生成? アジャイル開発? ナレッジベース? マルチプラットフォーム? 超高速開発ツール?

人によって享受しようとしている価値はそれぞれだと思います。ここではスコープを狭くして、前回話をしましたデータモデルとSQLという点にフォーカスします。

GeneXusではデータを抽出したい項目属性を列挙するだけで抽出対象となるテーブルの指定とか、テーブル間のJOINなどを自動的に推論しSQLを生成してくれます。



世の中的には(営業的には?)GeneXusは自動化=プログラムコード生成とかジェネレータといった部分がよく取り上げられますが、個人的にはプログラム(ソースコード)の自動生成よりもSQLの自動生成のほうが重要で、且つ、他のツールには無い、GeneXusらしい特徴だと思っています。

ところが、そのGeneXusであっても、先に出てきたようなリレーションが無いデータモデルだとか、すっ飛ばしたリレーションのデータモデルが前提であったりすると、必要とする項目属性を指定するだけではデータが取り出せなくなります。

例えば、for eachコマンドでリレーションが無いテーブル間のそれぞれの項目属性が指定してあると、ビルド時にエラー(spc0027 No relationship found among attributes in ….)となってしまいます。これは指定された項目属性が属するテーブル同士でリレーションが無い。つまり、SQLとしてJOINする事が出来ない。というエラーです。

なのでこうなると、必要な項目属性の列挙だけではデータ抽出処理(SELECT)が実現できませんので、テーブルごとにSELECTするとか、プログラムロジック側でデータを結合するといった対応が必要になります。

この結果、開発工数もかかり実行時のパフォーマンスも劣ってしまうような事態になってしまいます。つまり、GeneXusを使っているのに美味しい所が「全く使えていない」事になります。


SQLの自動生成を実現するための発想は

SQLを自動生成したい(開発工数の削減、実行パフォーマンスの向上)
↑
(そのためには)正規化された正しいリレーションのデータモデルが必要
↑
(そのためには)正規化処理をGeneXusが機械的に・例外なく対応
↑
(そのためには)正しい結果(正規化処理)を求めるために正しいインプットが必要

といった流れになります。

とはいえ、正しいインプットを実現するために、難しい理論とかテクニックが必要だと本末転倒です。そこで、GeneXusの生みの親であるGonda(ゴンダ)氏はユーザービューという考え方を編み出しました。

次回はユーザービューについてです。