グローバルSCMを展開する日本企業において、利用する業務アプリケーションが日本語以外の言語を取り扱えること（多言語対応）は必須の要件です。アプリケーションとしては、国際化「i18n（Internationalization）」を実現していることが最低限の条件になります。

「i18n」とは、ある特定の１カ国語しか扱うことができないソフトウェアを、それ以外の言語圏で利用できるように対応することで、同時に複数の言語を扱えるようにする、あるいは各国語への対応が行いやすいように予め準備をしておくことです。
蛇足ですが、ソフトウェアの分野で扱われる国際化（Internationalization）の単語は、スペルが長いので縮めて書くことが考案され、「i18n（英語ではアイ・エイティーン・エヌ）」という表記法が生まれたそうです。i18nの「18」は、internationalizationの先頭のiと、語尾のnの間に18文字があることを意味しています。

i18nを実現するには、プログラムから言語や文化に依存する部分を取り除き、エラーメッセージなどのテキストをプログラムのソースコードから完全に分離して、簡単に翻訳や変更ができるようにするなど、ソースコードレベルでの作業が必要になります。i18nが実現されたプログラムは、そのまま、もしくは最小限の修正で世界中の地域で利用することが可能になります。
逆に、i18nが考慮されていないプログラムは、異なる言語ごとに個別の変更作業が必要となるため、様々な言語のバージョンが乱立してしまい、開発・保守の手間がかかるといったデメリットがあります。

XA FrameManager Platformが提供する「国際化フレームワーク」は、このi18nを実現すべく用意されたもので、クライアントのロケール（言語・国）に合わせて画面表示を容易に切替える機能を実現し、ロケール毎に辞書ファイルを用意しておくことで、ラベル、レイアウト、フォーマット、メッセージを一括で切替えることができます。
これにより、画面やメッセージダイアログに表示される文字列の言語変換はもちろんのこと、英語圏の日付表示や桁数形式なども変換されます。ロケールは、MCFrame XAのログイン時に指定出来るため、ユーザはシステムで用意された任意の言語を選択してMCFrame XAを起動することが可能です。

また、プログラム中でロケールを明示的に指定して読み込むための機能も標準で提供しているため、帳票の表示を得意先（国）ごとに切替えるといった、画面の表示以外についても国際化に対応したアプリケーションの作成が可能になります。データベースについては、Oracleデータベースのキャラクタ・セットをUNICODEにして構築すれば、任意の主要な言語情報を格納出来るようになりますので、これ以外の特別な配慮は必要ありません。

さらに2010年春リリース予定のMCFrame XA生産管理のベースとなるXA FrameManager（最新版）からはマスターデータの表示名称をロケールに応じて切り替えるような「データの国際化」の機能が追加されます。これはXA FrameManager DeveloperのDB自動生成ツール"DBBuilder"が生成する「データ国際化テーブル」を利用することにより、ロケール毎の表示名称を保持することが可能になるというものです。
例えば品目マスタであれば、データ本体を格納する「品目マスタテーブル」とロケールに応じて切り替える品名格納用の「データ国際化テーブル」の２つのテーブルによって「データの国際化」を実現します。そのデータアクセスには適切な表示名称を抽出するビューを利用するため、アプリケーションはロケールに応じた表示名称を特別に意識することなく簡易な実装が可能になります。

DBコンテナフレームワーク

Javaなどのオブジェクト指向言語を使って、リレーショナルデータベース（RDB）にデータを格納する業務アプリケーションの開発では、データベースへのアクセスを行う処理の実装が繁雑になりがちです。その理由は、オブジェクト指向とRDBの設計思想（データモデル）の違いにあります。

RDBの設計では、業務で扱うデータの構造や流れに着目して、「データ」の検索・登録・更新処理に最適なデータモデルを定義します。データモデルとは、データベースのテーブルと同様の構造を持ったデータの表現方法をモデル化したものです。対するオブジェクト指向の設計では、現実社会における物体（業務）の特性とその物体にかかわるプロセスを「オブジェクト」として定義し、データとそれを操作する処理を一体にしてモデル化します。両者の違いを簡単に言えば、データベースを中心に考えるか、オブジェクトを中心に考えるかということになります。
また、それぞれのデータモデルはデータの保持方法が異なります。オブジェクト指向では関連する情報を１つのオブジェクトに保持しますが、RDBでは関連するデータを複数の表に分割して保持することがあります。このように、設計思想の違いからRDBのデータ構造とオブジェクト指向言語のデータ構造には、データモデル上の違いが生じてしまうのです（これを「インピーダンスミスマッチ」と呼びます）。

この違いを埋めるために、異なる２つデータモデルを結びつけるために生まれたのが「O/Rマッピング（Object / Relational Mapping）」と呼ばれるツールです。
O/Rマッピングツールが登場する前までは、データモデルの差を埋めるために、Javaプログラム中に表形式のデータをオブジェクト形式のデータに対応付けるマッピングコードを作成する必要がありました。この作業はデータ構造が複雑になると大変煩雑な作業になってしまう上、単調な繰り返しである場合が多いため、気付かぬうちにバグを埋め込んでしまうという危険性がありました。

それからもう一つ、データベースアクセス処理の実装を効率化する方法として、DAO（Data Access Object）と呼ぶデザインパターンがあります。これは、Javaの業務ロジックとRDBの間にデータアクセス専用のインターフェース（DAO）を用意して、データアクセスを全てこのインターフェース経由で行うというものです。
DAOパターンを採用すると、これまで業務ロジックで記述・生成していたSQL文をDAOに閉じ込めて局所化するだけでなく、業務ロジックに対してデータベースのテーブル構造を隠蔽することが出来るようになります。これにより、業務ロジックとデータベースへのアクセス処理が分離され、業務ロジック内に記述するデータの受け渡し処理がシンプルなものとなります。また、データベースのテーブル定義の変更が発生しても業務ロジックの修正が不要になるので、開発・保守の効率が向上します。

ここまで書くと良いことずくめですが、弱点はあります。O/RマッピングツールとDAOを利用することで、業務ロジックの実装がシンプルになっても、マッピングされる表の多さ・複雑さや扱うデータボリュームによっては、実行時のパフォーマンスが悪くなってしまう場合があります。また、SQLを書くことが得意な設計・開発者がO/Rマッピングツールを使った場合には、慣れるまでは思い通りのSQLを簡単に表現できないため、開発作業やトラブル発生時のデバッグなどには手間がかかります。
このように、O/RマッピングツールとDAOは完成された万全な仕組みとは言い切れず、性質を良く理解して適材適所で活用する必要があります。そこで、XA FrameManager Platformでは、O/RマッピングとDAOの思想を一部取り入れ、DBアクセスの手間を軽減する仕組みとして「DBコンテナフレームワーク」を用意しました。

図は、DBコンテナを使用しない場合（上）と、使用した場合（下）のイメージになります。
「DBコンテナ」が「DAO」に相当し、業務ロジックとデータベースの仲介役となって、両者の構造的な違いを吸収し、かつデータのマッピング（O/Rマッピングに相当）とSQLの自動生成・発行を行います。DBコンテナを利用すれば、変更に強いシンプルなプログラム構造になり、単純なSQLの開発やメンテナンスが不要になるため、SQL開発のコストを大幅に低減させることができるようになります。
特に、データベースのテーブル構造が単純で、複雑なSQLを必要としない処理であればSQLレスの開発が可能となりますので、マスタ管理画面のような比較的単純な画面の開発では大変効率の良い開発ができます。

今回はMCFrameXAの「開発フレームワーク」のうちの「国際化フレームワーク」「DBコンテナフレームワーク」についてご紹介しました。画面の実装や業務ロジックの実装を複雑なものにすることなく国際化対応やDBアクセスが可能なことがお分かりいただけたでしょうか。

前回と今回で「開発フレームワーク」をご説明する予定でしたが、２回分のコラム紙面では説明が納まらなくなってしまったため、次回も引き続き「開発フレームワーク」についてご説明したいと思います。

• 第5回コラム「XA FrameManager Platformの開発フレームワーク（３）」に続く