Technical Capabilities Tech Blog

#検証#機能紹介:DBRET(DBリバースエンジニアリングツール)③

2022年04月25日

こんにちは、植田です。
前回に引き続き外部システムのDBMSと連携した時のデータ取得の挙動について理解を深めていきます。

前回記事:検証#機能紹介:DBRET(DBリバースエンジニアリングツール)

前回記事:検証#機能紹介:DBRET(DBリバースエンジニアリングツール)②

今回の検証は下記に挙げた2番目のテーマについて進めていきます。

  1. 実行時に外部テーブル同士の結合はどのようになるのか?
  2. 外部テーブルと内部テーブルを名寄せした時にどのような結合になるのか

それでは試していきましょう。

2.外部テーブルと内部テーブルを名寄せした時にどのような結合になるのか

前回まで実装してきたトランザクション配下の通りです。

  • 会員(MnbTR)- システム内定義トランザクション
  • 国(M_CTRY)- 外部DBMS①
  • 地域(M_AREA)- 外部DBMS②

国と地域は共に外部DBMSからリバースしたテーブルで、国は1つの地域を保持する関係で繋がっています。
今回はこの状態から国と会員情報を繋げていきます。

【会員(MnbTR)改修前】

会員トランザクションで定義した独自の国情報をリバースした国トランザクションの項目に名寄せします。

この状態でDiagramオブジェクトを作成し、会員と国情報が繋がったことを確認してみます。
会員情報と外部DBMS上のテーブルが相関関係にあることが確認できますね。

データ内容をメッセージで表示する簡単なWebPanelを作成し、これらのデータが取得できているか確認します。

因みに再編成は項目の置き換えが発生しましたので以下の様になっています。

実行結果がこちらです。データはしっかり取得できていますね!

log4netで表示個所のSQLを見てみます。

【ログ出力】

//会員情報取得個所

①GeneXus.Data.ADO.GxConnectionManager - GxConnectionManager.IncOpenHandles handle '9', datasource 'Default', openhandles 1

②GeneXus.Data.GxConnectionCache - AddPreparedStmt, totalCachedStmtCursors:2, cursorId: 1073741830, stmt:SELECT [Ctry], [MnbId], [MnbNm], [MnbSeiNm] FROM [MnbTR] ORDER BY [MnbId]

①でDBコネクションの接続先、②で実際のSQLステートメントが確認できます。
ここでは会員データを取得するためにシステム内部のDBから情報取得していますね。

続きまして国と地域に関するログを参照してみます。

【ログ出力】

//国情報取得個所

①GeneXus.Data.ADO.GxConnectionManager - GxConnectionManager.IncOpenHandles handle '9', datasource 'DataStore1', openhandles 1

②GeneXus.Data.GxConnectionCache - AddPreparedStmt, totalCachedStmtCursors:0, cursorId: 1073741827, stmt:SELECT [Area], [CtryNm] FROM dbo.[M_CTRY] WHERE [Ctry] = @Ctry

//地域情報取得個所

①GeneXus.Data.ADO.GxConnectionManager - GxConnectionManager.IncOpenHandles handle '9', datasource 'DataStore1', openhandles 1

②GeneXus.Data.GxConnectionCache - AddPreparedStmt, totalCachedStmtCursors:1, cursorId: 1073741828, stmt:SELECT [AreaNm] FROM dbo.[M_AREA] WHERE [Area] = @Area

こちらも①と②でコネクションの接続先とSQLステートメントが確認できます。
ただこちらで注目したいのは前回では出来ていた国と地域の内部結合がされていない所です。
内部システム上のDBと外のDBを繋げると、外部DB上のテーブルはそれぞれ単独で取得されることがわかります。

対応策

このままだともっと外部から取得する情報が多い場合にレスポンスが気になるところですので
少し対策を考えてみました。

通常ですと取得した情報をGridコントロール上で表示したり、一括処理をProcedureオブジェクトで記述することが
多いと思いますのでGrid表示上の処理について以下の様に実装してみました。

【画面レイアウト】

画面上には外部から取得する項目を変数としてGridオブジェクトに配置し、EventsエレメントのLoadイベントにて
読み込んだ行に対しデータ取得するように記述しています。

【Eventエレメントの定義】

【実行結果】

【ログ出力】

①GeneXus.Data.ADO.GxConnectionManager - GxConnectionManager.IncOpenHandles handle '1', datasource 'DataStore1', openhandles 1

②DEBUG GeneXus.Data.GxConnectionCache - GetPreparedCommand stmt:SELECT T1.[Area], T1.[Ctry], T1.[CtryNm], T2.[AreaNm] FROM (dbo.[M_CTRY] T1 INNER JOIN dbo.[M_AREA] T2 ON T2.[Area] = T1.[Area]) WHERE T1.[Ctry] = @Ctry ORDER BY T1.[Ctry]

都度取得するように処理を工夫したことでこちらは内部結合で情報取得できていることが確認できました!

まとめ

ここまでの検証結果を纏めると

  • 外部DBMSのデータ定義はDBRET(リバースエンジニアリングツール)を使用することで簡単に可能
  • 外部DBMS同士で名寄せされているテーブル同士は内部結合で取得される
  • 但し内部システムのテーブルと結合する場合は工夫が必要

ということになりますね。
今回はユースケースとしては大変機会の多いパターンだと思いますので検証してみて
非常に興味深い結果となりました。

是非こちらの情報がお役に立てれば幸いです。

最後までご覧頂きありがとうございました!

Tech Blog一覧