JP2008015870A - レイアウト変換機能を有するデータ処理装置およびデータ管理部品プログラムとそのプログラムを記録した記録媒体 - Google Patents

Abstract

【課題】大規模業務処理システムにおいて，通信電文や業務マスタのレイアウト変更に伴う改修を不要とし，既存システムの容易な再構築を可能にする。
【解決手段】個別業務アプリ１０から呼び出されるデータ管理部品モジュール２０は，電文や業務マスタ１６などの外部から固定のレイアウトで入力されるデータを，予めレイアウトごとに設定されたレイアウト変換方法を示すナビゲーションテーブル記憶部３０に格納されたナビゲーション情報に従って内部データ形式に変換して内部形式データ記憶部２１に保持し，個別業務アプリ１０に対して，内部データ形式に変換されたデータの参照，更新，削除の処理機能を提供し，個別業務アプリ１０がそれらのデータを，レイアウト可変で扱うことができるようにする。
【選択図】図１

Description

本発明は，レイアウト変換機能を有するデータ処理装置およびデータ管理部品プログラムとそのプログラムを記録した記録媒体に関し，特に，多数の業務アプリケーションプログラム（以下，業務アプリという）が存在するシステムにおいて，通信電文や業務マスタのレイアウト変更に伴う改修を不要とし，既存システムの容易な再構築を可能にするためのコンピュータ技術に関する。

図１５は，従来システムの例を示す図である。サーバ１００は，複数の個別業務アプリ１１０を搭載し，これらの個別業務アプリ１１０によって各種の業務処理を遂行する。サーバ１００は，ネットワークを介して複数のクライアント４０または他のコンピュータ・システム（以下，他システムという）４１に接続され，クライアント４０または他システム４１との間でそれぞれ電文を送受信することにより，業務処理を行う。通信パッケージ１１３は，クライアント４０または他システム４１との通信プロトコルに応じた通信制御を行うモジュールである。電文制御部１１４は，電文の送受信先に応じた電文の振り分け制御を行うモジュールである。

各クライアント４０または他システム４１との間の電文は，それぞれシステムまたは業務ごとに予めデータのレイアウト（フォーマット）が決められており，例えば個別業務アプリ１１０が異なれば，電文のレイアウトも異なっていることが多かった。

業務マスタ１１６は，個別業務アプリ１１０による業務処理において参照または更新されるデータベースであり，アクセス部品１１５は，業務マスタ１１６へアクセスするためのデータベース管理システムが提供するプログラム群である。業務マスタ１１６に格納されるデータのレイアウト，すなわちデータベースの各レコードも予め固定的に決められており，各個別業務アプリ１１０は，データのレイアウトを意識して業務処理を遂行していた。

したがって，従来，電文や業務マスタ１１６のレイアウト変更が必要になると，それに伴い，個別業務アプリ１１０を必ず改修しなければならなかった。

また，このようなサーバ１００のシステムは，規模が大きくなればなるほど，長い年月にわたって継続的に使用されることが多いため，機能改良や機能拡張または新しい他のシステムとの接続などに伴い，個別業務アプリ１１０の本数が増え，プログラム資産が膨大なものになる傾向がある。これらの多数の個別業務アプリ１１０の中には，類似したプログラムが多数存在し，もし，システムの再構築によって，類似する個別業務アプリ１１０の統合・共通化を図ることができれば，プログラム資産の数量を削減し，プログラム群の保守を含むプログラム資産の管理が容易になると考えられるが，電文や業務マスタ１１６のデータのレイアウトの相違から，共通化を図るのは大規模システムにおいては極めて難しい状況にあるのが現状である。

業務処理アプリケーションの新規導入や，改版・改修の影響が少なく，人事異動，組織変更に柔軟に対応できる業務処理システムの統合管理方式を実現するものとして，下記の特許文献１に記載された技術がある。しかし，この技術は，主としてユーザインタフェースの統一化や簡略化を図るものであり，クライアントや他システムのとの間のインタフェースに影響を与えないで，段階的に既存システムを再構築するような場合に用いることができる技術ではない。

また，統合システムに統合が容易な形式のシステムアーキテクチャに基づいて管理システムを構築し，重複機能の共通化，データ連動に対する高信頼度化，および機能の拡張性に対する高い柔軟性を備えるシステムを実現するものとして，下記の特許文献２に記載された管理システムのデータ階層構造およびデータ階層構築方法がある。しかし，この技術も，クライアントや他システムのとの間のインタフェースに影響を与えないで，段階的に既存システムを再構築するような場合に用いることができる技術ではない。
特開２０００−２５０８７２号公報 特開２００３−９１６３４号公報

例えば，図１５に示すシステムにおいて，あるクライアント４０からくる電文Ｘが“項目ａ，項目ｂ，項目ｃ”の順番のレイアウトＡ１であり，他のクライアント４０からくる電文Ｙが“項目ａ，項目ｃ，項目ｂ”の順番のレイアウトＡ２であったとする。この場合，電文Ｘ，Ｙの実質的な内容はａ，ｂ，ｃというように同じであっても，電文Ｘ，ＹのレイアウトがＡ１，Ａ２と異なるため，従来，それぞれ異なる個別業務アプリ（Ａ１）１１０および個別業務アプリ（Ａ２）１１０で各電文が処理されていた。

サーバ１００のシステムを再構築し，ほとんど類似する機能を持つ個別業務アプリ（Ａ１）１１０および個別業務アプリ（Ａ２）１１０を一つに統合して，プログラム資源の整理を図る方法の一つとして考えられるのは，クライアント４０側の電文Ｘ，Ｙのいずれかのレイアウトを変更して，レイアウトＡ１またはＡ２のいずれか一つに統合することである。

しかしながら，クライアント４０や他システム４１などとの電文の外部インタフェースは，必ずしもいつも容易に変更することができるとは限らず，外部条件によっては非常に変更が困難である場合や変更ができない場合がある。例えば，クライアント４０や他システム４１の数が数百台〜数千台というように数が多い場合や，クライアント４０や他システム４１において送受信する電文がさらに他のサーバ・システムでも同じ固定のレイアウトで利用されているような場合である。

クライアント４０や他システム４１などとの電文の外部インタフェースに影響を与えないで，すなわち各クライアント４０や他システム４１の電文のレイアウトは既存の形式のままで，類似した個別業務アプリ１１０を一本化することができれば，非常に膨大になり過ぎたプログラム資産の整理・統合が実用的なレベルで実現可能になると考えられる。特に，外部インタフェースに影響を与えないで，プログラム資産の整理・統合が可能になれば，既存のサーバ１００の膨大なプログラム資産からなるシステムを段階的に再構築することができるようになり，一度にすべてのシステムを置き換えるような必要がなくなるため，継続的にしかも安全にシステム全体の改版を行うこともできるようになると考えられる。

また，新しい個別業務アプリを開発し，システムに追加する場合にも，電文のレイアウトが可変であれば，異なるレイアウトの電文を送受信する複数のクライアントや他システムにも新しい個別業務アプリが対応することができ，個別業務アプリの共通化，汎用化が可能になると考えられる。

以上では，電文のレイアウトに関する問題を述べたが，電文のレイアウトに限らず，業務マスタ１１６におけるデータのレイアウト，すなわちレコードのデータ形式（レコードフォーマット等）の違いについても，同様にプログラム資産が増大化する原因の一つとなっている。個別業務アプリ１１０が，業務マスタ１１６におけるデータの物理的なデータ構成であるレイアウトを意識することなく，論理的な識別情報だけでデータ処理を行うことができれば，システムの再構築による個別業務アプリ１１０の統合が可能になると考えられる。

さらにまた，各個別業務アプリ１１０に共通化した処理を，統一的に行うことができるような仕組みがあれば，無駄なプログラム資産のさらなる削減が可能になる。

本発明は，従来システムにおける電文／業務マスタのレイアウトの相違が，業務アプリの共通化を阻害し，プログラム資産の増加を招いているという問題，また，電文／業務マスタのレイアウトの変更で，プログラム資産の改修が発生するという問題，また，他システムインタフェースや共通の業務マスタの変更要件による束縛から，容易にプログラムを整備することができないという問題の解決を図り，特に，段階的に多数の個別業務アプリからなるシステムの再構築を可能とする手段を提供することを目的とする。

本発明は，上記課題を解決するため，電文や業務マスタなどの外部から固定のレイアウトで入力されるデータを，予めレイアウトごとに設定されたレイアウト変換方法を示すナビゲーション情報に従って内部データ形式に変換して保持し，個別業務アプリに対して，内部データ形式に変換されたデータの参照，更新，削除の処理機能を提供し，個別業務アプリがそれらのデータを，レイアウト可変で扱うことができるようにするためのデータ管理部品処理手段をデータ処理装置に組み込み，各個別業務アプリが，データ管理部品処理手段を利用することによってデータをアクセスするようにしたことを特徴とする。

詳しくは，本発明は，端末もしくは他のコンピュータシステムまたは外部記憶装置との間で，それぞれ予め定められたレイアウトに従って構成されたデータを入出力し，アプリケーションプログラムを実行するプロセスによってデータを処理するデータ処理装置において，前記レイアウトのデータ構成情報と，前記レイアウトとは独立した当該データ処理装置内で保持される内部データ形式を定めるデータ構成情報との対応情報を，レイアウト変換のナビゲーション情報として記憶するナビゲーション情報記憶手段と，前記アプリケーションプログラムのプロセスによって呼び出され，端末もしくは他のコンピュータシステムまたは外部記憶装置から入力されたデータを，前記ナビゲーション情報記憶手段が記憶するナビゲーション情報に従って，前記入力されたデータのレイアウトに対応する前記内部データ形式のデータに変換して内部のデータ記憶部に格納するレイアウト変換の処理を行い，端末もしくは他のコンピュータシステムまたは外部記憶装置へデータを出力する際に，前記内部のデータ記憶部に格納されている出力対象となっている内部データ形式のデータを，前記ナビゲーション情報記憶手段が記憶するナビゲーション情報に従って，出力先のレイアウトに対応するデータに変換して出力する処理を行い，かつ，前記アプリケーションプログラムのプロセスからの要求に従って，前記内部のデータ記憶部に格納されたデータの少なくとも参照，更新または削除の処理を行うデータ管理部品処理手段とを備えることを特徴とする。

また，上記レイアウト変換機能を有するデータ処理装置において，前記内部データ形式のデータには，前記レイアウト変換時に，各データを一意に識別するリソースＩＤと，各データにおける個々の項目を一意に識別するアイテムＩＤとが付与され，前記リソースＩＤは，前記レイアウトの種別に応じたハッシュ値によってアクセスされるリソースハッシュテーブルによって管理され，前記アイテムＩＤは，前記各リソースＩＤごとの各アイテム種別に応じたハッシュ値によってアクセスされるアイテムハッシュテーブルによって管理され，前記内部データ形式のデータは，前記アイテムハッシュテーブルの配下に接続される領域に各アイテムのデータ値が格納される構成で管理されることを特徴とする。

また，上記レイアウト変換機能を有するデータ処理装置において，前記ナビゲーション情報記憶手段に記憶されるナビゲーション情報は，前記内部データ形式のデータの項目ごとに，暗号化するか否かを示す設定情報を含み，前記データ管理部品処理手段は，前記内部データ形式のデータの項目に対し暗号化する旨の情報が設定されている場合に，レイアウトの変換時にその項目を暗号化して前記内部のデータ記憶部に格納し，前記アプリケーションプログラムのプロセスからのアクセス時および前記内部データ形式から所定のレイアウトへの逆変換時に，その項目を復号化して出力する暗号化／復号化変換手段を有することを特徴とする。

また，上記レイアウト変換機能を有するデータ処理装置において，前記ナビゲーション情報記憶手段に記憶されるナビゲーション情報は，前記レイアウトごとに，データが圧縮されているか否かを示す設定情報を含み，前記データ管理部品処理手段は，変換対象となっているレイアウトに対し，データが圧縮されている旨の情報が設定されている場合に，そのデータを非圧縮状態に復元してからレイアウト変換の処理を行う圧縮／非圧縮変換手段を有することを特徴とする。

また，上記レイアウト変換機能を有するデータ処理装置において，前記ナビゲーション情報記憶手段に記憶されるナビゲーション情報は，前記内部データ形式のデータの項目ごとに，入力項目をチェックする場合の条件に関する設定情報を含み，前記データ管理部品処理手段は，前記内部データ形式のデータの項目に対し，入力項目をチェックする場合の条件に関する設定情報が設定されている場合に，設定されている条件に従って，レイアウト変換対象となっているデータの項目が正しいかどうかのチェックを行う入力項目チェック手段を有することを特徴とする。

以上のレイアウト変換機能を有するデータ処理装置は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することも，ネットワークを通して提供することも可能である。

本発明によれば，電文や業務マスタのデータのレイアウトを，個別業務アプリが意識する必要がなくなるので，業務処理の共通化が容易になる。また，電文や業務マスタのデータのレイアウト変更において，個別業務アプリが変更項目を直接使用しない場合には，個別業務アプリの改修は不要となる。したがって，システムの保守性が向上する。

特に，各レイアウトごとのレイアウト変換に関するナビゲーション情報の設定によって，既存の電文や業務マスタのデータのレイアウトを変更することなく，段階的に個別業務アプリの統廃合，改良を行うことができるので，大規模業務処理システムにおける現実的なシステムの再構築手法として，本発明は有用である。

図１は，本発明の実施の形態を示すシステム構成の概要図である。サーバ１は，複数の個別業務アプリ１０を搭載し，これらの個別業務アプリ１０によって各種の業務処理を遂行する。サーバ１は，ネットワークを介して複数のクライアント４０または他システム４１に接続され，クライアント４０または他システム４１との間でそれぞれ電文を送受信することにより，業務処理を行う。

通信パッケージ１３は，クライアント４０または他システム４１との通信プロトコルに応じた通信制御を行うモジュールである。電文制御部１４は，電文の送受信先に応じた電文の振り分け制御を行うモジュールである。

業務マスタ１６は，個別業務アプリ１０による業務処理において参照または更新されるデータベースであり，アクセス部品１５は，業務マスタ１６へアクセスするためのデータベース管理システムが提供するプログラム群である。

各クライアント４０または他システム４１との間の電文は，それぞれシステムまたは業務ごとに予めデータのレイアウト（フォーマット）が決められている。また，業務マスタ１６に格納されるデータのレイアウト，すなわちデータベースの各レコードのフォーマット等も予め固定的に決められている。

以上のクライアント４０，他システム４１，通信パッケージ１３，電文制御部１４，アクセス部品１５，業務マスタ１６は，図１５を用いて説明した従来システムのものと同様である。

本発明では，個別業務アプリ１０が，予め固定的に定められている電文のレイアウトおよび業務マスタ１６のデータのレイアウトを意識しないで，電文および業務マスタのデータの作成，参照，更新，削除などの処理を行うことができるように，主にレイアウトの変換と，各個別業務アプリ１０に共通な処理を行うための，データ管理部品モジュール２０が設けられている。データ管理部品モジュール２０は，電文の入出力時や業務マスタ１６のデータの入出力時に呼び出されて，電文および業務マスタ１６のデータのレイアウト変換を行う。ナビゲーションテーブル記憶部３０には，後に詳しく説明するように，このレイアウト変換に必要となる各種のテーブルが記憶されている。

予め固定的に定められている電文のレイアウトおよび業務マスタ１６に格納されているデータのレイアウトを，ここでは外部形式または外部データ形式と呼ぶ。データ管理部品モジュール２０が行うレイアウト変換とは，個別業務アプリ１０がデータを入力するときに，外部形式のデータを統一的に定められた内部形式（内部データ形式ともいう）に変換して保持し，また，個別業務アプリ１０がデータを出力するときに，前記内部形式のデータを出力先に応じた外部形式に変換して出力することである。なお，本明細書においては，後者の変換をレイアウトの逆変換ということもある。

一つの電文や業務マスタ１６のレコードを単位とするデータの内容をリソースといい，リソース中の個々の項目をアイテムという。外部形式では，一つの電文や業務マスタ１６のレコードにおけるアイテムの物理的な位置やサイズ，すなわちレイアウトが固定的に定められているのに対し，内部形式では，各アイテムの物理的な位置やサイズが捨象された情報として保持される。このような外部形式から内部形式への変換，また内部形式から外部形式への変換のための情報は，ナビゲーションテーブルとして，ナビゲーションテーブル記憶部３０に予め登録しておく。外部形式から内部形式へのデータの変換を，データの正規化という。具体的には，以下のとおりである。

内部形式では，アイテムの物理的な位置を個別業務アプリ１０が意識しなくてもデータにアクセスできるように，個々のアイテムを識別するアイテムＩＤでそのデータを参照，更新することができるようにする。また，内部形式においては，アイテムのサイズはナビゲーションテーブルによって定められる。ナビゲーションテーブルには，複数の個別業務アプリ１０が共通に利用するアイテムに対して，それらが必要とするサイズの最大サイズを予測してサイズ情報を設定してもよい。また，共通化のために，必要に応じてデータ形式を変換する情報をナビゲーションテーブルに設定しておくようにしてもよい。例えば，数値データを２進数で保持するか，文字型データで保持するか，内部１０進形式で保持するかというような情報である。

個別業務アプリ１０における主プロセス１１は，個別業務アプリ１０における全体の制御を司るメインのプログラム実行部であり，サブプロセス１２は，各電文に応じて主プロセス１１から呼び出され，業務マスタ１６の参照，更新等の具体的な業務処理を行うプログラムの実行部である。一般に，個別業務アプリ１０は，一つの主プロセス１１と複数のサブプロセス１２とを有する。

図１に示すシステムにおいて，個別業務アプリ１０が，あるクライアント４０から通信パッケージ１３，電文制御部１４を介して，一つの電文を受信すると，個別業務アプリ１０における主プロセス１１は，データ管理部品モジュール２０を呼び出し，受信した電文のレイアウト変換を指示する。データ管理部品モジュール２０は，ナビゲーションテーブル記憶部３０に格納されたナビゲーションテーブルを参照し，受信した電文のデータを外部形式から内部形式に変換して，内部形式データ記憶部２１に保持する。このとき，内部形式に変換された電文のデータに対して，データを一意に識別するためのリソースＩＤが付与される。

主プロセス１１は，その電文を処理するサブプロセス１２を呼び出す。サブプロセス１２は，データ管理部品モジュール２０が提供する検索機能を使用して，処理対象とする内部形式に変換された電文のリソースＩＤを取得する。以後，サブプロセス１２は，そのリソースＩＤにより，データ管理部品モジュール２０を介してその電文のデータにアクセスする。したがって，サブプロセス１２は，電文の物理的なレイアウトを意識することなく，電文のデータを処理することができる。すなわち，電文のレイアウトが変わっても，ナビゲーションテーブルを変更するだけで，自動的に新しい外部形式から正規化された内部形式へのデータの変換が行われるため，サブプロセス１２は，レイアウトの変更前と同様にデータを使用することができ，レイアウト可変になる。

電文を個別業務アプリ１０が作成し，個別業務アプリ１０からクライアント４０または他システム４１へ送信する場合，サブプロセス１２は，データ管理部品モジュール２０を用いて内部形式で電文のデータを作成する。内部形式で作成されたデータは，電文の送信時にナビゲーションテーブルに従って外部形式に変換され，電文制御部１４を通して出力される。

上記処理において，主プロセス１１からサブプロセス１２を呼び出すときに，パラメータでリソースＩＤを引き渡すようにしてもよい。しかし，本実施の形態のように，主プロセス１１とサブプロセス１２との入出力パラメータにリソースＩＤを用いないようにすれば，サブプロセス１２の独立性を高め，共通化がさらに容易になる。この場合，サブプロセス１２では，後述するデータ管理部品モジュール２０の検索機能を使用して電文のデータを示すリソースＩＤを取得するが，主プロセス１１が戻り電文を編集する場合にも，同様に検索機能で戻り電文のデータのリソースＩＤを取得し，戻り電文を編集することになる。

個別業務アプリ１０において，業務マスタ１６のレコードを参照，更新する場合にも，同様にナビゲーションテーブルを利用することにより，入出力データの外部形式から内部形式への変換およびその逆変換が行われる。

例えば，サブプロセス１２が，電文を処理するために業務マスタ１６のデータを参照する場合，データ管理部品モジュール２０を呼び出すことにより，業務マスタ１６へのアクセスを行う。データ管理部品モジュール２０は，アクセス部品１５を使用して業務マスタ１６のデータを読み込み，そのデータを業務マスタ１６のレコードフォーマットである外部形式から，ナビゲーションテーブルで指定された内部形式に変換して，内部形式データ記憶部２１に格納する。サブプロセス１２は，その内部形式に変換されたデータを利用する。一方，サブプロセス１２が業務マスタ１６にデータを書き込む場合，同様にデータ管理部品モジュール２０を呼び出す。データ管理部品モジュール２０は，内部形式で保持しているデータをナビゲーションテーブルに従って外部形式に変換し，アクセス部品１５を用いて業務マスタ１６に書き込む。

ナビゲーションテーブルには，電文または業務マスタ１６のレコードのレイアウト変換を行うか行わないかの情報も設定可能になっており，ナビゲーションテーブルにレイアウト変換不要が設定されている場合には，データ管理部品モジュール２０は，外部形式から内部形式への変換，および内部形式から外部形式への変換は行わない。この場合，個別業務アプリ１０は，電文のレイアウトおよび業務マスタ１６のデータのレイアウトに従った処理を行う。すなわち，従来システムと同様のレイアウトを意識した処理を行う。

したがって，個別業務アプリ１０を段階的に改版していくような場合に，改版前には，ナビゲーションテーブルにレイアウト変換不要を設定しておき，既存の個別業務アプリ１０のプログラムによって業務処理を遂行し，改版後には，ナビゲーションテーブルにレイアウト変換要を設定して，レイアウト可変とした新しい個別業務アプリ１０のプログラムによって業務処理を遂行することができるようになる。このようなレイアウト変換の処理手段を用いることにより，既存のプログラムと新しいプログラムとが混在した状態でシステムを運用することができ，段階的なシステムの再構築が可能になる。

図２は，本発明に関連する部分の詳細な構成例を示す図である。図２において，図１と同符号のものは図１に示すものに対応する。

データ管理部品モジュール２０は，レイアウト変換部２２，運転管理部２３，ログ編集部２４，入力項目チェック部２５，圧縮／非圧縮変換部２６，暗号化／復号化変換部２７を備える。ログ情報記憶部２８は，ログ編集部２４によって編集されたログ情報を記憶する装置である。個別業務アプリ１０における共通部品群２９は，個別業務アプリ１０がデータ管理部品モジュール２０の機能を利用するための種々のプログラム部品であり，個別業務アプリ１０のプログラムとデータ管理部品モジュール２０とのソフトウェアインタフェースである。実装上は，例えばマクロ命令，関数呼出し，またはサブルーチン呼出しなどによって実現される。

レイアウト変換部２２は，上述したように，ナビゲーションテーブル記憶部３０に格納されたナビゲーションテーブルに従って，電文や業務マスタ１６のデータを，外部形式から内部形式に変換して内部形式データ記憶部２１に格納する処理，また，内部形式データ記憶部２１に格納された内部形式のデータを，外部形式に変換して出力するための変換処理を行う。さらに，レイアウト変換部２２は，レイアウトの変換に付随して，入力項目チェック部２５，圧縮／非圧縮変換部２６，暗号化／復号化変換部２７を呼び出すことにより，それぞれ入力項目チェック，データの圧縮／非圧縮，データの暗号化／復号化のための処理を行わせるための処理機能を持つ。

運転管理部２３は，レイアウト変換のためのテーブルをメモリに展開する初期設定処理や，統計情報の照会に対する処理，ログ解析情報の照会に対する処理などを行う。ログ編集部２４は，レイアウト変換に伴う各種のログ情報，例えば不正電文の情報やデータ使用情報などを収集し，ログ情報記憶部２８に格納する処理を行う。入力項目チェック部２５は，ナビゲーションテーブルに入力項目をチェックすることが指定されている場合に，設定されたチェック条件に従って，入力項目の形式が正しいかどうかをチェックする。また，圧縮／非圧縮変換部２６は，ナビゲーションテーブルに従って，レイアウト変換時におけるデータの領域単位に圧縮または非圧縮の処理を行う。暗号化／復号化変換部２７は，ナビゲーションテーブルに従って，レイアウト変換時にデータの項目単位に暗号化または復号化の処理を行う。

ナビゲーションテーブル記憶部３０には，レイアウト変換のための各種のテーブルが予め登録され，記憶される。このナビゲーションテーブルの作成・登録は，管理用端末５０から行われる。システムの開発者または管理者は，各種の電文のレイアウトや業務マスタ１６のレコードのレイアウト情報，および入力項目チェックの要否，データの圧縮／非圧縮の要否，データの暗号化／復号化の要否などが記載された設計書５６をもとに，管理用端末５０からナビゲーションテーブルの作成に必要な情報を入力する。

管理用端末５０の条件入力画面表示部５１は，ナビゲーションテーブルに設定する情報を入力するための画面を表示する。条件入力部５２は，表示した条件入力画面から入力されたレイアウト変換条件の情報を取得する。ナビゲーションテーブル生成部５３は，条件入力部５２によって入力された情報をもとに，詳しくは後述する各種のナビゲーションテーブルを生成し，ナビゲーションテーブル記憶部３０に格納する。これらのナビゲーションテーブルの生成処理は，ＧＵＩ（Graphical User Interface）を用いて行われるので，レイアウトの変換に必要な情報を容易に入力することができる。

また，設計書５６のデータが電子化されている場合には，そのデータから直接的にナビゲーションテーブルを自動生成することもできる。なお，このようなテーブルの自動生成プログラムは，入力情報と出力情報とが明らかであれば，容易に作成することができるので，ここではテーブル自動生成方法の詳細な処理手続きの説明は省略する。この場合，設計ドキュメントからナビゲーションテーブルを自動生成することにより，テーブルの設定誤りが防止され，高品質化が可能になる。また，テーブルのメンテナンスの運用稼動コストを削減することができる。

また，管理用端末５０は，統計情報照会部５４および解析情報照会部５５を備える。統計情報照会部５４は，データ管理部品モジュール２０の運転管理部２３に対し，データ使用状況や各種メモリ情報等の問い合わせを行い，その問い合わせ結果を出力する。また，解析情報照会部５５は，例えば個別アプリ１０がシグナル等で異常終了した場合に，その時点のアクセス・データ等の解析情報を運転管理部２３に照会し，異常の原因を解析するための解析情報を運転管理部２３から受け取り，出力する。これにより，トラブル解析を容易に行うことができるようになる。

統計情報照会部５４によって，電文種類ごとの件数を統計情報として収集することができるので，データの負荷分散を目的にナビゲーションテーブルの最適化（ハッシュ値の最適値設定）が可能になる。また，統計情報照会部５４によって，項目ごとにユーザ入力誤り（電文の誤り）などの件数を統計情報として収集することにより，誤操作防止を目的とした画面仕様の改善などに統計情報を活用することができる。すなわち，ユーザ入力誤りの集中傾向を分析し，例えば「項目の入力方法を，直接入力から選択入力に変える」とか，「クライアント上の入力チェック機能を補完し，誤入力そのものを抑止する」というように，画面入力仕様の改善に活かすことができる。

図２に示すデータ管理部品モジュール２０を，個別業務アプリ１０から共通部品群２９を介して利用することができるようにすることにより，以下のような効果がある。
(1) 電文や業務マスタ１６のデータのレイアウトを，個別業務アプリ１０が意識する必要がないので，業務処理の共通化が容易になり，保守性が向上する。
(2) 電文や業務マスタ１６のデータのレイアウト変更において，個別業務アプリ１０が変更項目を直接使用しない場合には，個別業務アプリ１０の改修は不要となり，保守性が向上する。
(3) ナビゲーションテーブルで暗号化の対象／対象外が設定可能であるため，例えば氏名，電話番号，口座番号等の個人情報に該当する項目を，ナビゲーションテーブルへの設定だけで暗号化することができ，個別業務アプリ１０の改修を行わないで，個人情報等に対するセキュリティレベルを上げることができるようになる。業務マスタ１６は，ナビゲーションテーブルの条件に従って暗号化したデータを格納し，個別業務アプリ１０では，自動的に復号されたデータを利用することができるようにすることも可能であるため，個別業務アプリ１０における暗号化データの利用を容易化することができる。
(4) データ管理部品モジュール２０において，ナビゲーションテーブルへの設定条件により，入力項目チェックがレイアウト変換時に自動的に行われるため，個別業務アプリ１０が個々に入力項目チェックのロジックを持つ必要がなくなり，個別業務アプリ１０が簡素化され保守性が向上する。
(5) ナビゲーションテーブルに従って，領域の圧縮／非圧縮が自動的に行われるため，個別業務アプリ１０が個々に圧縮／非圧縮のロジックを持つ必要がなく，保守性が向上する。

図３は，ナビゲーションテーブルとして用いられる各テーブルのデータ構成の例を示す図である。レイアウト変換方法を示すナビゲーション情報が登録されるナビゲーションテーブルとして，本実施の形態では，図３に示すような電文管理テーブル３１，業務マスタ管理テーブル３２，アクション管理テーブル３３，レイアウト変換テーブル３４，アイテム管理テーブル３５，条件設定テーブル３６が用いられる。

各テーブルは，ナビゲーションテーブル記憶部３０に記憶される。図中，矢印に沿って（１：１）と記載されているのは，テーブルが１対１の関係であることを示し，矢印に沿って（１：ｎ）と記載されているのは，テーブルが１対ｎ（ｎは１以上の整数）の関係であることを示す。また，各テーブルにおいて，（キー）と記載された項目は，そのテーブルにおいてユニークなキーとなる項目であることを示す。また，各テーブルにおいて，（ｎ）と記載された項目は，１つのテーブルに同じ項目がｎ個繰り返されることを示す。

電文管理テーブル３１は，業務の種類および電文の種類ごとに用意されるテーブルであり，業務ＩＤ，電文ＩＤ，およびレイアウト変換方法を識別するアクションＩＤなどの情報から構成される。業務ＩＤは，電文を処理する業務を識別する識別情報である。電文ＩＤは，電文の種類を識別する識別情報である。アクションＩＤは，対応するアクション管理テーブル３３を特定する情報である。

業務マスタ管理テーブル３２は，業務マスタ１６を管理するテーブルであり，業務マスタＩＤ，ＤＢアクセスＩＤ，アクションＩＤなどの情報から構成される。業務マスタＩＤは，業務マスタ１６を識別する情報である。ＤＢアクセスＩＤは，業務マスタ１６のデータベースを識別する識別情報である。アクションＩＤは，対応するアクション管理テーブル３３を特定する情報である。なお，電文管理テーブル３１と業務マスタ管理テーブル３２は，それぞれ電文および業務マスタ１６ごとに用意されるテーブルであるので，ナビゲーションテーブル記憶部３０とは別に，例えば電文制御部１４またはアクセス部品１５と個別業務アプリ１０との間のインタフェース部（システム固有部）で参照するテーブルとして設けてもよい。

アクション管理テーブル３３は，電文や業務マスタ１６に対して，どのようなレイアウト変換方法を用いるかを示すアクションを管理するテーブルであり，アクションＩＤ，レイアウト種別，レイアウト変換要否，入力項目チェック要否，暗号化機能要否などの情報から構成される。アクションＩＤは，電文または業務マスタ１６に対するレイアウト変換のポリシーを特定する情報である。レイアウト種別は，電文または業務マスタ１６のレイアウトを特定する情報である。レイアウト変換要否は，電文または業務マスタ１６のレイアウト変換を行うか否かを示す情報である。入力項目チェック要否は，電文または業務マスタ１６のデータの入力項目チェックを行うか否かを示す情報である。暗号化機能要否は，電文または業務マスタ１６のデータの暗号化を行うか否かを示す情報である。

レイアウト変換テーブル３４は，レイアウト変換対象のデータ構成情報を管理するテーブルである。レイアウト種別，レイアウト区分，レイアウトハッシュ値，外部領域数，変換区分，外部内部変換領域ＩＤ，内部外部変換領域ＩＤ，初期値，外部領域位置，外部領域サイズ，領域繰返し数などの情報から構成される。

レイアウト種別は，レイアウトを特定する情報である。レイアウト区分は，そのレイアウトが何に関するレイアウトなのかを示す情報である。レイアウト区分は，本実施の形態では，レイアウト区分の値に応じて，
１：電文，
２：業務マスタ，
３：作業域，
４：電文（圧縮済み），
となっている。レイアウト区分＝４の場合には，入力電文のデータが圧縮されているので，非圧縮後にレイアウト変換を行う。

レイアウトハッシュ値は，内部形式に変換されたリソース（電文等）の管理に必要となる情報である。レイアウトハッシュ値の詳細は後述する。外部領域数は，外部形式のデータの項目の種類数を示す情報である。以下の情報は，データの項目ごとの情報となる。

変換区分は，レイアウト変換時にその項目のデータを転送（コピー）するのか別に固定値を設定するのかなどを指定する情報である。外部内部変換領域ＩＤは，外部形式から内部形式にレイアウト変換を行う場合に，内部形式のデータに設定するアイテム種別を示す情報である。内部外部変換領域ＩＤは，内部形式から外部形式にレイアウト変換を行う場合に，外部形式のデータとして設定する内部形式のデータのアイテム種別を示す情報である。初期値は，その項目に初期値として設定する値の情報である。外部領域位置は，その項目の外部領域での位置を示す情報である。外部領域サイズは，その項目の外部領域でのサイズを示す情報である。領域繰返し数は，その項目のデータの数を示す情報である。

アイテム管理テーブル３５は，内部形式に変換されるデータの項目を示すアイテムのデータ構成情報を管理するテーブルである。レイアウト種別，アイテム種別，領域条件（暗号化要否など），領域属性，領域サイズ，コードチェック条件，相関チェック条件などの情報から構成される。

レイアウト種別は，そのアイテムが変換されるときのレイアウトを特定する情報である。アイテム種別は，個々のアイテムをユニークに識別する識別情報である。領域条件は，そのアイテムのアイテム値（データ）の暗号化の要否等を指定する情報である。領域条件は，本実施の形態では領域条件の値に応じて，
１：暗号化項目（内部形式へのレイアウト変換時に暗号化する），
２：暗号化項目（暗号化済み），
０：暗号化の対象外，
となっている。領域条件＝１，２の場合，個別業務アプリ１０から参照要求があったときには該当アイテムを復号化して引き渡す。また，個別業務アプリ１０からの更新要求があったときには該当アイテムを暗号化して内部形式データ記憶部２１に格納する。この領域条件により，例えば個人情報のような場合，メモリ上の内部領域を含め，暗号化し，個別業務アプリ１０が処理するときにだけ復号する。

クライアント４０／他システム４１が非暗号化で，領域条件＝１のケースでは，電文（非暗号化状態），内部形式のデータ（暗号化状態），個別業務アプリ１０のアクセスデータ（非暗号化状態），業務マスタ１６のデータ（暗号化状態）となる。

クライアント４０／他システム４１が暗号化で，領域条件＝２のケースでは，電文（暗号状態），内部形式のデータ（暗号化状態），個別業務アプリ１０のアクセスデータ（非暗号化状態），業務マスタ１６のデータ（暗号化状態）となる。

領域属性は，アイテムの属性（文字，数値など）を示す情報である。領域サイズは，内部形式でのアイテムの領域のサイズを示す情報である。コードチェック条件は，アクション管理テーブル３３において入力項目チェック要となっている場合に，入力項目のコードが正しい範囲内のものになっているかどうかをチェックする条件を示す情報である。後述する条件設定テーブル３６の一つをポイントする。また，相関チェック条件は，アクション管理テーブル３３において入力項目チェック要となっている場合に，入力項目が他の項目との関係で正しいかどうかをチェックする条件を示す情報である。後述する条件設定テーブル３６の一つをポイントする。コードチェック条件または相関チェック条件として，条件設定テーブル３６が指定されている場合，その条件設定テーブル３６を使用して入力項目チェックが行われる。

条件設定テーブル３６は，検索の条件やソートの条件および前述した入力項目チェックの条件を設定するテーブルであり，条件設定ＩＤ，条件区分，レイアウト種別，アイテム種別，アイテム値，比較条件，チェック方法，連結条件（ＡＮＤ，ＯＲ），次条件設定ＩＤなどの情報から構成される。

条件設定ＩＤは，各条件設定を一意に識別する情報である。条件区分は，設定された条件が何の条件（検索条件やソート条件など）であるかを示す情報である。レイアウト種別は，条件として指定されたレイアウト種別を示す情報である。アイテム種別は，条件として指定されたアイテム種別を示す情報である。アイテム値は，条件として指定されたアイテムの値を示す情報である。比較条件は，例えば＝，≠，＜，≦，＞，≧など，アイテム値をどのように比較するかを示す情報である。

チェック方法は，例えば相関チェック条件に従った入力項目チェックのために，専用のチェックプログラムを利用する必要があるような場合に，そのチェックプログラムを呼び出すためのプログラムを指定する情報である。連結条件は，複数の条件設定テーブル３６で条件を指定する場合に，他の条件設定テーブル３６とどのように連結されるか（ＡＮＤ条件，ＯＲ条件かなど）を示す情報である。次条件設定ＩＤは，他の条件設定テーブル３６と連結される場合に，連結先となる条件設定テーブル３６の条件設定ＩＤを指定する情報である。

図４は，リソース入力時のレイアウト変換の例を説明する図である。電文などのリソースは，外部形式のデータであり，データ管理部品モジュール２０によって，内部形式のデータにレイアウト変換され，内部形式データ記憶部２１に記憶される。

図５は，内部形式のデータの構成の例を示す図である。ここで，図５を用いて，図４に示されている各データの構成の例を説明しておく。図５（Ａ）はリソースハッシュテーブル２１０の構成例を示し，図５（Ｂ）はリソース情報２１１の構成例を示し，図５（Ｃ）はリソースＩＤ２１２の構成例を示す。また，図５（Ｄ）はアイテムハッシュテーブル２１３の構成例を示し，図５（Ｅ）はアイテム情報２１４の構成例を示し，図５（Ｆ）はアイテムＩＤ２１５の構成例を示す。

図５（Ａ）に示すように，リソースハッシュテーブル２１０では，エントリごとに，件数，ポインタの情報が記録される。件数は，そのエントリに属するリソースの件数である。ポインタは，そのエントリに属するリソースのうち，先頭のリソース情報２１１の領域へのポインタである。件数の初期値は０であり，ポインタの初期値はｎｕｌｌである。リソース情報２１１をリソースハッシュテーブル２１０のどのエントリに接続するかは，レイアウトハッシュ値によって決める。本実施の形態におけるレイアウトハッシュ値は，あるキーとなる情報からランダムに定める値ではなく，予めレイアウト種別ごとにシステム開発者または管理者が決める値であり，リソースハッシュテーブル２１０の何番目のエントリであるかを示すエントリ番号（Ｎｏ．）である。

リソースハッシュテーブル２１０の使用により，各リソースへのアクセス性能のバラツキをなくすことができる。また，レイアウト変換テーブル３４におけるレイアウトハッシュ値を変更することで，プログラムの改修を行わずに，リソースハッシュテーブル２１０配下の資源分散を行うことが可能となる。

リソース情報２１１は，図５（Ｂ）に示すように，リソースＩＤ２１２，次ポインタ，下位ポインタの情報から構成される。リソースＩＤ２１２は，そのリソースを一意に識別する識別情報である。次ポインタは，そのリソースの次にリソースハッシュテーブル２１０の同じエントリに属することになったリソースのリソース情報２１１の領域へのポインタである。下位ポインタは，そのリソースに属するアイテムを管理するためのアイテムハッシュテーブル２１３の領域へのポインタである。そのリソースの後にリソースハッシュテーブル２１０の同じエントリに属するリソースがまだ入力されていない場合には，次ポインタはｎｕｌｌとなる。

リソースＩＤ２１２は，図５（Ｃ）に示すように，レイアウト種別，リソース通番，レイアウトハッシュ値の情報から構成される。レイアウト種別は，そのリソースのレイアウト種別である。リソース通番は，リソースハッシュテーブル２１０内で一意の値である。ここでは，入力された順に１，２，... とリソース通番を設定するものとする。レイアウトハッシュ値は，レイアウト種別をもとにレイアウト変換テーブル３４から得られる値である。リソースＩＤ２１２にレイアウトハッシュ値を持たせることにより，個別業務アプリ１０がテーブルを参照せずに各アイテムにアクセスすることを可能とする。

図５（Ｄ）に示すように，アイテムハッシュテーブル２１３では，エントリごとに，件数，ポインタの情報が記録される。件数は，そのエントリに属するアイテムの件数である。ポインタは，そのエントリに属する先頭のアイテム情報２１４の領域へのポインタである。アイテム情報２１４を，アイテムハッシュテーブル２１３におけるどのエントリに接続するかは，アイテムハッシュ値によって決められる。アイテムハッシュ値は，アイテム種別から予め定められた計算式によって算出される。アイテムハッシュテーブル２１３の使用により，各アイテムへのアクセス性能のバラツキをなくすことができる。

アイテム情報２１４は，図５（Ｅ）に示すように，アイテムＩＤ２１５，アイテム値，次ポインタの情報から構成される。アイテムＩＤ２１５は，そのアイテムを一意に識別する識別情報である。アイテム値は，そのアイテムの持つ実際のデータ値である。次ポインタは，そのアイテムの次にアイテムハッシュテーブル２１３の同じエントリに属することになったアイテム情報２１４の領域へのポインタである。そのアイテムの後にアイテムハッシュテーブル２１３の同じエントリに属するアイテムがない場合には，次ポインタはｎｕｌｌとなる。

アイテムＩＤ２１５は，図５（Ｆ）に示すように，レイアウト種別，リソース通番，レイアウトハッシュ値，アイテム種別，アイテム通番，領域条件の情報から構成される。レイアウト種別は，そのアイテムが属するリソースのレイアウト種別である。リソース通番は，そのアイテムが属するリソースのリソース通番である。レイアウトハッシュ値は，そのアイテムが属するリソースのレイアウトハッシュ値である。アイテム種別は，そのアイテムの項目名などの種別である。アイテム通番は，アイテムハッシュテーブル２１３内で各アイテムに一意に付与される番号である。領域条件は，そのアイテムに設定された暗号化要否等の情報である。

以下，図５に示すような各データの構成を踏まえて，図４に示すリソース入力時のレイアウト変換の例を説明する。

図４において，リソース（１），（２），（３）は，レイアウト種別Ａのデータであり，アイテム種別Ａ，Ｂ，Ｃ，Ｄのアイテムからなる。リソース（４）は，レイアウト種別Ｂのデータであり，アイテム種別Ａ，Ｅのアイテムからなる。リソース（５），（６）は，レイアウト種別Ｃのデータであり，アイテム種別Ｆ，Ｇ，Ｈのアイテムからなる。

データ管理部品モジュール２０は，その起動時に，予めリソースハッシュテーブル２１０の領域を動的に確保し，初期化しておく。リソースハッシュテーブル２１０の領域は，レイアウト変換テーブル３４の各レコードのリソースハッシュ値の最大値分の領域を確保する。ここでは，エントリ１〜４の領域が確保されている。

最初にリソース（１）が入力されると，そのリソース（１）のリソース情報２１１の領域が動的に確保される。リソース（１）のレイアウト種別はＡであるので，そのレイアウト種別Ａでレイアウト変換テーブル３４を検索し，レイアウトハッシュ値を取得する。取得されたレイアウトハッシュ値に該当するリソースハッシュテーブル２１０のエントリが１であるものとすると，エントリ１のポインタ部に，確保されたリソース（１）のリソース情報２１１の領域のアドレスが設定され，エントリ１の件数がインクリメント（０→１）される。また，リソース通番のインクリメント（０→１）が行われ，そのリソース通番とレイアウト種別とレイアウトハッシュ値とからリソース（１）のリソースＩＤ２１２が作成される。作成されたリソースＩＤ２１２は，リソース（１）のリソース情報２１１に設定される。なお，リソース（１）のリソース情報２１１の次ポインタは，この時点で初期値（ｎｕｌｌ）である。

本実施の形態では，アイテムハッシュテーブル２１３とアイテム情報２１４の格納領域は，連続領域として動的に確保する。そこで，レイアウト変換テーブル３４と各アイテム管理テーブル３５とから，アイテムハッシュテーブル２１３と全アイテム情報２１４との格納領域のサイズを計算し，メモリから動的に領域を確保する。リソース（１）の場合には，アイテムハッシュテーブル２１３としてエントリ１〜３の領域が確保され，エントリ１に属するアイテム情報２１４の領域としてアイテム種別Ａの領域が，エントリ２に属するアイテム情報２１４の領域としてアイテム種別Ｂ，Ｄの領域が，エントリ３に属するアイテム情報２１４の領域としてアイテム種別Ｃの領域が確保される。

アイテムハッシュテーブル２１３の各エントリのポインタに，それぞれ先頭のアイテム情報２１４の領域のアドレスが設定され，アイテム種別Ｂのアイテム情報２１４の次ポインタに，アイテム種別Ｄのアイテム情報２１４の領域のアドレスが設定される。アイテムハッシュテーブル２１３の各エントリの件数に，それぞれ属するアイテムの件数が設定される。また，リソース（１）のリソース情報２１１の下位ポインタに，確保されたアイテムハッシュテーブル２１３の領域のアドレスが設定される。

リソース（１）のリソースＩＤ２１２，レイアウト変換テーブル３４，アイテム管理テーブル３５をもとに，各アイテム情報２１４にアイテムＩＤ２１５が設定される。また，リソース（１）の各アイテムの値（データ）が，各アイテム情報２１４のアイテム値に設定される。

次にリソース（２）が入力されると，そのリソース（２）のリソース情報２１１の領域が動的に確保される。リソース（２）のレイアウト種別はＡであるので，リソース（１）と同じリソースハッシュテーブル２１０のエントリ１に属することになる。リソースハッシュテーブル２１０のエントリ１のポインタにはすでにリソース（１）のリソース情報２１１の領域のアドレスが設定されているので，リソース（１）のリソース情報２１１の次ポインタに，リソース（２）のリソース情報２１１の領域のアドレスが設定される。リソースハッシュテーブル２１０のエントリ１の件数がインクリメント（１→２）される。また，リソース通番がインクリメント（１→２）され，リソース（２）のリソースＩＤ２１２のリソース通番は２となる。リソース（１）の場合と同様に，アイテムに関する処理を行う。

次にリソース（４）が入力されると，そのリソース（４）のリソース情報２１１の領域が動的に確保される。リソース（４）のレイアウト種別はＢであるので，そのレイアウト種別Ｂでレイアウト変換テーブル３４を検索し，レイアウトハッシュ値を取得する。取得されたレイアウトハッシュ値に該当するリソースハッシュテーブル２１０のエントリが３であるものとすると，エントリ３のポインタに，確保されたリソース（４）のリソース情報２１１の領域のアドレスが設定され，エントリ３の件数がインクリメント（０→１）される。また，リソース通番がインクリメント（２→３）され，リソース（４）のリソースＩＤ２１２のリソース通番は３となる。リソース（１）の場合と同様に，アイテムに関する処理を行う。

次にリソース（３）が入力されると，そのリソース（３）のリソース情報２１１の領域が動的に確保される。リソース（３）のレイアウト種別はＡであるので，リソース（１）と同じリソースハッシュテーブル２１０のエントリ１に属することになる。リソースハッシュテーブル２１０のエントリ１のポインタにはすでにリソース（１）のリソース情報２１１の領域のアドレスが設定されているので，リソース（２）のリソース情報２１１の次ポインタに，リソース（３）のリソース情報２１１の領域のアドレスが設定される。リソースハッシュテーブル２１０のエントリ１の件数がインクリメント（２→３）される。また，リソース通番がインクリメント（３→４）され，リソース（３）のリソースＩＤ２１２のリソース通番は４となる。リソース（１）の場合と同様に，アイテムに関する処理を行う。

次にリソース（５）が入力されると，そのリソース（５）のリソース情報２１１の領域が動的に確保される。リソース（５）のレイアウト種別はＣであるので，そのレイアウト種別Ｃでレイアウト変換テーブル３４を検索し，レイアウトハッシュ値を取得する。ここで，取得されたレイアウトハッシュ値に該当するリソースハッシュテーブル２１０のエントリが，レイアウト種別がＢであるリソース（４）と同じ３であるものとする。リソースハッシュテーブル２１０のエントリ３のポインタにはすでにリソース（４）のリソース情報２１１の領域のアドレスが設定されているので，リソース（４）のリソース情報２１１の次ポインタに，リソース（５）のリソース情報２１１の領域のアドレスが設定される。リソースハッシュテーブル２１０のエントリ３の件数がインクリメント（１→２）される。また，リソース通番がインクリメント（４→５）され，リソース（５）のリソースＩＤ２１２のリソース通番は５となる。リソース（１）の場合と同様に，アイテムに関する処理を行う。

次にリソース（６）が入力されると，そのリソース（６）のリソース情報２１１の領域が動的に確保される。リソース（６）のレイアウト種別はＣであるので，リソース（５）と同じリソースハッシュテーブル２１０のエントリ３に属することになる。リソースハッシュテーブル２１０のエントリ３のポインタにはすでにリソース（４）のリソース情報２１１の領域のアドレスが設定されているので，リソース（５）のリソース情報２１１の次ポインタに，リソース（６）のリソース情報２１１の領域のアドレスが設定される。リソースハッシュテーブル２１０のエントリ３の件数がインクリメント（２→３）される。また，リソース通番がインクリメント（５→６）され，リソース（６）のリソースＩＤ２１２のリソース通番は６となる。リソース（１）の場合と同様に，アイテムに関する処理を行う。

以上の処理により，図４に示すように，外部形式のデータがデータ管理部品モジュール２０によって内部形式のデータにレイアウト変換され，内部形式データ記憶部２１に記憶される。図４の例では，リソースハッシュテーブル２１０，アイテムハッシュテーブル２１３を用いることにより，アクセス性能のバラツキをなくしている。

図６は，運転管理部２３が行う運転管理処理フローチャートである。図６の運転管理処理は，レイアウト変換処理のための準備を行う処理であり，データ管理部品モジュール２０の初回起動時に実行される。

運転管理部２３は，ナビゲーションテーブル記憶部３０のナビゲーションテーブル（電文管理テーブル３１，業務マスタ管理テーブル３２，アクション管理テーブル３３，レイアウト変換テーブル３４，アイテム管理テーブル３５，条件設定テーブル３６）を，メモリに展開する（ステップＳ１０）。

次に，レイアウト変換テーブル３４からレイアウトハッシュ値の最大値を取得し（ステップＳ１１），取得した最大値分のリソースハッシュテーブル２１０の領域を動的に確保する（ステップＳ１２）。確保したリソースハッシュテーブル２１０の領域を初期化し（ステップＳ１３），処理を終了する。

図７は，レイアウト変換部２２が行うレイアウト変換処理フローチャートである。図７のレイアウト変換処理は，入力された外部形式のデータであるリソースを，内部形式のデータに展開する処理の例である。なお，ここでは説明を簡単にするために，暗号化／復号化変換の処理，圧縮／非圧縮変換の処理，入力項目チェックの処理は省略している。電文についてのレイアウト変換の例を説明するが，業務マスタ１６のデータのレイアウト変換も同様である。

レイアウト変換部２２は，入力されたリソースの電文ＩＤで電文管理テーブル３１を検索し，アクションＩＤを取得する（ステップＳ２０）。取得したアクションＩＤでアクション管理テーブル３３を検索し，レイアウト種別を取得する（ステップＳ２１）。取得したレイアウト種別でレイアウト変換テーブル３４を検索し，該当するレイアウト変換テーブル３４を抽出する（ステップＳ２２）。リソース情報２１１の領域を動的に確保する（ステップＳ２３）。

ステップＳ２２で抽出されたレイアウト変換テーブル３４に保持されたレイアウトハッシュ値に該当するリソースハッシュテーブル２１０のエントリのポインタがｎｕｌｌであれば（ステップＳ２４），ステップＳ２３で動的に確保されたリソース情報２１１の領域のアドレスを該当エントリのポインタに設定する（ステップＳ２５）。

ステップＳ２２で抽出されたレイアウト変換テーブル３４に保持されたレイアウトハッシュ値に該当するリソースハッシュテーブル２１０のエントリのポインタがｎｕｌｌでなければ（ステップＳ２４），エントリのポインタからリンクを追い，最終のリソース情報２１１の次ポインタに，ステップＳ２３で動的に確保されたリソース情報２１１の領域のアドレスを設定する（ステップＳ２６）。

アイテムハッシュテーブル２１３とアイテム情報２１４の格納領域のサイズを計算し，アイテムハッシュテーブル２１３とアイテム情報２１４の格納領域を動的に確保する（ステップＳ２７）。

ステップＳ２２で抽出されたレイアウト変換テーブル３４の情報をリソース情報２１１の領域に設定し，リソース情報２１１を編集する（ステップＳ２８）。リソース通番をインクリメントし，リソース情報２１１の領域に設定し，リソース情報２１１を編集する（ステップＳ２９）。アイテムハッシュテーブル２１３の領域のアドレスを，リソース情報２１１の領域に設定し，リソース情報２１１を編集する（ステップＳ３０）。

アイテムハッシュテーブル２１３の各エントリのポインタに，それぞれ属するアイテムのアイテム情報２１４の領域のアドレスを設定する（ステップＳ３１）。このとき，複数のアイテムが同じエントリに属する場合には，アイテム情報２１４の次ポインタを用いてつないでいく。ステップＳ２２で抽出されたレイアウト変換テーブル３４を参照し，入力されたリソースの値を切り出して，各アイテム情報２１４に設定する（ステップＳ３２）。リソースハッシュテーブル２１０の該当リソースが属するエントリの件数をインクリメントする（ステップＳ３３）。

なお，ここでは説明を簡単化したが，実際にはステップ３２のリソースの値を切り出す処理において，アクション管理テーブル３３および各アイテム管理テーブル３５の設定情報に従って，必要であれば，入力項目チェック部２５の呼び出し，圧縮／非圧縮変換部２６の呼び出し，暗号化／復号化変換部２７の呼び出しを行い，アイテム情報２１４に設定するアイテム値について，入力項目チェックの処理，非圧縮の処理，暗号化の処理などを行う。また，ログ編集部２４は，随時，トラブル解析等に有用な情報をログ情報として編集し出力する処理を行う。

図８，図９は，外部形式のデータから内部形式のデータへのレイアウト変換を説明する図である。図８は，レイアウト変換テーブル３４，アイテム管理テーブル３５の具体例を示し，図９は，図８のテーブルに従って，外部形式のデータ（レイアウト固定）を内部形式のデータ（レイアウト可変）に変換する例を示す。ここでは，電文を内部形式のデータに変換する例を説明する。

図８（Ａ）は，単純転送を示すレイアウト変換テーブル３４，アイテム管理テーブル３５である。単純転送では，外部形式の領域から内部形式の領域にそのままデータ値を複写する。図８（Ａ）のレイアウト変換テーブル３４とアイテム管理テーブル３５とにより，図９に示すように，Ａ項目の値“ＡＡ”が，内部形式のアイテム種別“Ｒ００Ａ”のアイテム値に複写される。

図８（Ｂ）は，繰返し転送を示すレイアウト変換テーブル３４，アイテム管理テーブル３５である。繰返し転送では，複数データの項目を外部形式の領域から内部形式の領域に設定する。図８（Ｂ）のレイアウト変換テーブル３４では，領域繰返し数として３が設定されている。そのため，図８（Ｂ）のレイアウト変換テーブル３４とアイテム管理テーブル３５とにより，図９に示すように，Ｂ項目−１，Ｂ項目−２，Ｂ項目−３のそれぞれの値“１００”，“２００”，“３００”が，内部形式の３つのアイテム種別“Ｒ００Ｂ”のアイテム値に，繰返し設定される。

図８（Ｃ）は，固定値設定を示すレイアウト変換テーブル３４，アイテム管理テーブル３５である。固定値設定では，固定値を内部形式の領域に設定する。図８（Ｃ）のレイアウト変換テーブル３４では，変換区分が２（固定値設定）に設定され，初期値として“１２３４”が設定されている。図９の外部形式のデータに示すように，Ｃ項目はダミーエントリとなっている。すなわち，外部領域サイズが０であり，実際には存在しない。しかし，内部形式では，個別業務アプリ１０の処理において，例えば互換性や共通化のために必要とするため，図８（Ｃ）のレイアウト変換テーブル３４とアイテム管理テーブル３５とにより，図９に示すように，内部形式のアイテム種別“Ｒ００Ｃ”のアイテム値に，固定値として，任意の値の“１２３４”を設定できるようにしている。

図８（Ｄ）は，領域切り捨てを示すレイアウト変換テーブル３４，アイテム管理テーブル３５である。領域切り捨てでは，内部形式の領域サイズに合わせて外部形式のデータを切り捨てて設定する。図８（Ｄ）のレイアウト変換テーブル３４では，外部領域サイズが３となっている。これに対して図８（Ｄ）のアイテム管理テーブル３５では，領域サイズが２となっている。図８（Ｄ）のレイアウト変換テーブル３４とアイテム管理テーブル３５とにより，図９に示すように，Ｄ項目の値“ＢＢＢ”が内部形式の領域サイズ２に合わせて切り捨てられ，アイテム種別“Ｒ００Ｄ”のアイテム値に“ＢＢ”として設定される。

図８（Ｅ）は，暗号化項目を示すレイアウト変換テーブル３４，アイテム管理テーブル３５である。暗号化項目では，内部形式の領域への設定時に暗号化を行う。図８（Ｅ）のアイテム管理テーブル３５では，領域条件が１（内部変換時に暗号化）となっている。図８（Ｅ）のレイアウト変換テーブル３４とアイテム管理テーブル３５とにより，図９に示すように，Ｅ項目の値“１２３４５６”が暗号化され，アイテム種別“Ｒ００Ｅ”のアイテム値に“ＸＸＸＸＸＸ”として設定される。

図１０，図１１は，内部形式のデータから外部形式のデータへのレイアウト変換を説明する図である。図１０は，レイアウト変換テーブル３４，アイテム管理テーブル３５の具体例を示し，図１１は，図１０のテーブルに従って，内部形式のデータ（レイアウト可変）を外部形式のデータ（レイアウト固定）に変換する例を示す。ここでは，内部形式のデータを外部形式である業務マスタ１６のレコードに変換する例を説明する。

図１０（Ａ）は，単純転送を示すレイアウト変換テーブル３４，アイテム管理テーブル３５である。単純転送では，内部形式の領域から外部形式の領域にそのままデータ値を複写する。図１０（Ａ）のレイアウト変換テーブル３４，アイテム管理テーブル３５により，図１１に示すように，アイテム種別“Ｒ００Ａ”のアイテム値“ＡＡ”が，外部形式のＡ項目に複写される。

図１０（Ｂ）は，繰返し転送を示すレイアウト変換テーブル３４，アイテム管理テーブル３５である。繰返し転送では，複数データのアイテム種別を内部形式の領域から外部形式の領域に設定する。図１０（Ｂ）のレイアウト変換テーブル３４では，領域繰返し数として３が設定されている。そのため，図１０（Ｂ）のレイアウト変換テーブル３４，アイテム管理テーブル３５により，図１１に示すように，３つのアイテム種別“Ｒ００Ｂ”のアイテム値“１００”，“２００”，“３００”が，それぞれ外部形式のＢ項目−１，Ｂ項目−２，Ｂ項目−３に繰返し設定される。

図１０（Ｃ）は，固定値設定を示すレイアウト変換テーブル３４，アイテム管理テーブル３５である。内部形式の領域への設定時に固定値設定を行った場合には，外部形式の領域への設定は行わない。図１０（Ｃ）のレイアウト変換テーブル３４では，変換区分が２（固定値設定）に設定されている。そのため，図１０（Ｃ）のレイアウト変換テーブル３４，アイテム管理テーブル３５により，図１１に示すように，外部形式のデータでは，Ｃ項目はダミーエントリとなる。

図１０（Ｄ）は，内部変換時と異なる領域を示すレイアウト変換テーブル３４，アイテム管理テーブル３５である。内部変換時と異なる領域では，アイテム種別を変えて外部形式の領域に設定する。図１０（Ｄ）のレイアウト変換テーブル３４では，外部内部変換領域ＩＤが“Ｒ００Ｄ”であるのに対し，内部外部変換領域ＩＤが“Ｒ００Ａ”となっている。図１０（Ｄ）のレイアウト変換テーブル３４，アイテム管理テーブル３５により，図１１に示すように，アイテム種別“Ｒ００Ｄ”のアイテム値“ＢＢ”ではなく，アイテム種別“Ｒ００Ａ”のアイテム値“ＡＡ”が，外部形式のＤ項目に設定される。

図１０（Ｅ）は，暗号化項目を示すレイアウト変換テーブル３４，アイテム管理テーブル３５である。アイテム管理テーブル３５の領域条件の値が１または２の暗号化項目の場合，内部形式の領域では暗号化済みのアイテム値を保持する。したがって，アイテム種別“Ｒ００Ｅ”のアイテム値は，すでに暗号済みの状態であるので，図１０（Ｄ）のレイアウト変換テーブル３４，アイテム管理テーブル３５により，図１１に示すように，アイテム種別“Ｒ００Ｅ”のアイテム値“ＸＸＸＸＸＸ”が，外部形式のＥ項目に設定される。なお，領域条件の値が２の暗号化項目は，外部形式において暗号化された値が保持されることを示す。

図１２は，個別業務アプリと内部形式のデータとの関連を説明する図である。ここでは，入力電文，業務マスタ１６，出力電文のそれぞれについて，個別業務アプリ１０が内部形式のデータをどのように扱うかを説明する。個別業務アプリ１０の入出力インタフェースは，リソースＩＤ２１２を用いてデータへのアクセスを行う。このため，個別業務アプリ１０は，電文や業務マスタ１６のレイアウトを意識したコーディングが不要となる。

まず，入力電文について説明する。入力電文があると，個別業務アプリ１０の主プロセス１１は，電文取込機能により，データ管理部品モジュール２０を用いて，入力電文を内部形式に変換する（手順ａ）。これにより，例えば図１２の内部形式データ記憶部２１に示すように，リソースハッシュテーブル２１０のエントリ１配下に，入力電文が内部形式で展開されることになる。

主プロセス１１は，内部形式に変換された入力電文を処理するために，入力電文の種類に応じたサブプロセス１２の呼び出しを行う（手順ｂ）。個別業務アプリ１０のサブプロセス１２は，リソース検索機能により，入力電文のリソースＩＤ２１２を検索する（手順ｃ）。入力電文を特定する検索条件を指定することにより，入力電文のリソースＩＤ２１２を取得することができる。また，サブプロセス１２は，リソース参照機能とアイテム参照機能により，入力電文のアイテムＡを参照する（手順ｄ）。アイテム参照機能では，入力電文のアイテムＡのアイテムＩＤ２１５を指定することにより，そのアイテムのアイテム値を得ることができる。

次に，業務マスタ１６のアクセスについて説明する。サブプロセス１２は，アクセス部品１５を用い，アイテムＡのアイテム値をキーに業務マスタ１６を参照する（手順ｅ）。ここでは，アイテムＡのアイテム値を含む業務マスタ１６のリソースが検出されたものとする。サブプロセス１２は，業務マスタ取込機能により，業務マスタ１６を内部形式に変換する（手順ｆ）。この例では，図１２の内部形式データ記憶部２１に示すように，リソースハッシュテーブル２１０のエントリ３配下に，業務マスタ１６が内部形式で展開されるものとする。

次に，出力電文について説明する。サブプロセス１２は，リソース作成機能により，出力電文のリソースを作成する（手順ｇ）。この例では，図１２の内部形式データ記憶部２１に示すように，リソースハッシュテーブル２１０のエントリ４配下に，出力電文のリソースが内部形式で作成されている。リソース作成時のアイテム情報は，初期値となる。サブプロセス１２は，アイテム更新機能により，出力電文のアイテムを更新する（手順ｈ））。このとき，アイテムＩＤ２１５で更新するアイテムを指定し，該当するアイテムのアイテム情報のアイテム値を更新する。

サブプロセス１２から主プロセスに戻る（手順ｉ）。主プロセス１１は，電文編集機能により，出力電文を外部形式に変換する（手順ｊ）。このとき，出力電文のリソースＩＤ２１２で内部形式のデータを指定し，外部形式のデータに変換する。

図１３は，個別業務アプリが利用可能なデータ管理部品モジュール２０の機能を説明する図である。個別業務アプリ１０は，共通部品群２９を用いることにより，図１３に示すような様々なデータ管理部品モジュール２０が提供する機能を利用することができる。これらの「機能」は，関数，サブルーチンもしくはマクロ命令と読み替えてもよい。例えば，電文取込機能は，電文取込関数と読み替えることができ，個別業務アプリ１０が電文取込関数を発行することにより，データ管理部品モジュール２０内の電文取込プログラムが電文取込の処理を実現するようになっている。

図１３に示すように，データ管理部品モジュール２０による外部内部変換としては，電文取込機能，業務マスタ取込機能がある。電文取込機能は，電文領域のデータをサーバの内部形式にレイアウト変換し，リソースＩＤ２１２を返却する機能である。業務ＩＤ，電文ＩＤ，電文領域を入力パラメータとし，リソースＩＤ２１２を返却値とする。業務マスタ取込機能は，業務マスタ領域のデータをサーバの内部形式にレイアウト変換し，リソースＩＤ２１２を返却する。業務マスタＩＤ，ＤＢアクセスＩＤ，業務マスタ領域を入力パラメータとし，リソースＩＤ２１２を返却値とする。

内部外部変換としては，電文編集機能，業務マスタ編集機能がある。電文編集機能は，電文領域のデータを外部形式にレイアウト変換し，電文領域を返却する機能である。リソースＩＤ２１２を入力パラメータとし，業務ＩＤ，電文ＩＤ，電文領域を返却値とする。業務マスタ編集機能は，業務マスタ領域のデータを外部形式にレイアウト変換し，業務マスタ領域を返却する機能である。リソースＩＤ２１２を入力パラメータとし，業務マスタＩＤ，ＤＢアクセスＩＤ，業務マスタ領域を返却値とする。

検索機能としては，リソース検索機能がある。リソース検索機能は，検索条件に該当するリソースを，ソート条件の順序で検索する機能である。ソート条件は任意であり，ソート条件が指定されていれば，検索結果のリソースＩＤ２１２をソート条件の順序で出力する。検索条件，ソート条件を入力パラメータとし，１または複数のリソースＩＤ２１２を返却値とする。

参照機能としては，リソース参照機能，アイテム参照機能がある。リソース参照機能は，指定されたリソース配下のアイテムを参照する機能である。リソースＩＤ２１２を入力パラメータとし，リソース配下のアイテムＩＤ２１５，アイテム値を返却値とする。アイテム参照機能は，指定されたアイテムのアイテム値を参照する機能である。アイテムＩＤ２１５を入力パラメータとし，アイテム値を返却値とする。

更新機能としては，リソース作成機能，リソース複写機能，アイテム更新機能がある。リソース作成機能は，リソース通番を払出し，新規にリソースを作成する機能である。このとき，作成されるリソース配下の各アイテムは，初期値で作成される。レイアウト種別を入力パラメータとし，リソースＩＤ２１２を返却値とする。リソース複写機能は，複写元のリソースから複写先のリソースに，各アイテムを複写する機能である。複写元のリソースＩＤ２１２，複写先のリソースＩＤ２１２を入力パラメータとする。アイテム更新機能は，指定されたアイテムの作成や更新を行う機能である。アイテムＩＤ２１５，アイテム値を入力パラメータとする。

削除機能としては，リソース削除機能，アイテム削除機能がある。リソース削除機能は，検索条件に該当するリソースを削除する機能である。検索条件を入力パラメータとし，削除したリソースＩＤ２１２を返却値とする。アイテム削除機能は，指定されたアイテムを削除する機能である。アイテムＩＤ２１５を入力パラメータとする。

条件設定としては，条件設定機能，条件解除機能がある。条件設定機能は，検索条件またはソート条件を設定する機能である。条件区分，条件設定値を入力パラメータとし，条件設定ＩＤを返却値とする。条件区分は，検索条件であるかソート条件であるかの区分を示す。条件解除機能は，設定済みの検索条件またはソート条件を解除する機能である。条件設定ＩＤを入力パラメータとする。

図１４は，条件設定機能による検索条件の例を示す図である。ここでは，図１３に示す条件設定機能を用いて検索条件を設定する例を説明する。検索条件は，条件設定テーブル３６（図３参照）に設定される。なお，図１４の例では，条件設定ＩＤ，条件区分，レイアウト種別，チェック方法の情報は省略されており，次条件設定ＩＤは，次ポインタとして示している。

図１４（ａ）は，アイテム種別Ａのアイテム値が１０以上かつ２０未満であるリソースを対象とする検索条件の例である。（ａ１）の条件設定テーブル３６では，アイテム種別がＡ，アイテム値が１０，比較条件が≧（〜以上）であることから，アイテム種別Ａのアイテム値が１０以上という条件が示されている。また，（ａ１）の条件設定テーブル３６の次ポインタで指定された（ａ２）の条件設定テーブル３６では，アイテム種別がＡ，アイテム値が２０，比較条件が＜（〜未満）であることから，アイテム種別Ａのアイテム値が２０未満という条件が示されている。

（ａ１）の条件設定テーブル３６の連結条件がＡＮＤ条件であることから，（ａ１）の条件設定テーブル３６と，（ａ２）の条件設定テーブル３６とがＡＮＤ条件で連結されていることがわかる。したがって，これらの２つの条件設定テーブル３６のＡＮＤ条件から，アイテム種別Ａのアイテム値が１０以上，かつ，２０未満という条件が設定されていることになる。

図１４（ｂ）は，アイテム種別Ｂのアイテム値が３０またはアイテム種別Ｃのアイテム値が４０であるリソースを対象とする検索条件の例である。（ｂ１）の条件設定テーブル３６では，アイテム種別がＢ，アイテム値が３０，比較条件が＝であることから，アイテム種別Ｂのアイテム値が３０という条件が示されている。また，（ｂ１）の条件設定テーブル３６の次ポインタで指定された（ｂ２）の条件設定テーブル３６では，アイテム種別がＣ，アイテム値が４０，比較条件が＝であることから，アイテム種別Ｃのアイテム値が４０という条件が示されている。

（ｂ１）の条件設定テーブル３６の連結条件がＯＲ条件であることから，（ｂ１）の条件設定テーブル３６と（ｂ２）の条件設定テーブル３６とがＯＲ条件で連結されていることがわかる。したがって，これらの２つの条件設定テーブル３６のＯＲ条件から，アイテム種別Ｂのアイテム値が３０，または，アイテム種別Ｃのアイテム値が４０という条件が設定されていることになる。

本発明のレイアウト変換機能を有するデータ処理装置およびデータ管理部品プログラムは，多数の業務アプリケーションプログラムによって，多種類の電文や各種のデータベースのレコードを処理するシステムに用いることができる。また，例えばＸ会社とＹ会社とが合併し，Ｘ会社が使用していたコンピュータ・システムとＹ会社が使用していたコンピュータ・システムとを一つのシステムに統合するような場合に，この統合のためのシステムの再構築を容易化するための現実的な技術的解法となり得る。

本発明の実施の形態を示すシステム構成の概要図である。 本発明に関連する部分の詳細な構成例を示す図である。 各テーブルのデータ構成の例を示す図である。 リソース入力時のレイアウト変換の例を説明する図である。 内部形式のデータの構成の例を示す図である。 運転管理処理フローチャートである。 レイアウト変換処理フローチャートである。 外部形式のデータから内部形式のデータへのレイアウト変換を説明する図である。 外部形式のデータから内部形式のデータへのレイアウト変換を説明する図である。 内部形式のデータから外部形式のデータへのレイアウト変換を説明する図である。 内部形式のデータから外部形式のデータへのレイアウト変換を説明する図である。 個別業務アプリと内部形式のデータとの関連を説明する図である。 個別業務アプリが利用可能なデータ管理部品モジュールの機能を説明する図である。 条件設定機能による検索条件の例を示す図である。 従来システムの例を示す図である。

符号の説明

１ サーバ（ＣＰＵ／メモリ）
１０ 個別業務アプリ
１１ 主プロセス
１２ サブプロセス
１３ 通信パッケージ
１４ 電文制御部
１５ アクセス部品
１６ 業務マスタ
２０ データ管理部品モジュール
２１ 内部形式データ記憶部
２２ レイアウト変換部
２３ 運転管理部
２４ ログ編集部
２５ 入力項目チェック部
２６ 圧縮／非圧縮変換部
２７ 暗号化／復号化変換部
２８ ログ情報記憶部
２９ 共通部品群
３０ ナビゲーションテーブル記憶部
３１ 電文管理テーブル
３２ 業務マスタ管理テーブル
３３ アクション管理テーブル
３４ レイアウト変換テーブル
３５ アイテム管理テーブル
３６ 条件設定テーブル
４０ クライアント
４１ 他システム
５０ 管理用端末
５１ 条件入力画面表示部
５２ 条件入力部
５３ ナビゲーションテーブル生成部
５４ 統計情報照会部
５５ 解析情報照会部
５６ 設計書
２１０ リソースハッシュテーブル
２１１ リソース情報
２１２ リソースＩＤ
２１３ アイテムハッシュテーブル
２１４ アイテム情報
２１５ アイテムＩＤ

Claims (11)

1. 端末もしくは他のコンピュータシステムまたは外部記憶装置との間で，それぞれ予め定められたレイアウトに従って構成されたデータを入出力し，アプリケーションプログラムを実行するプロセスによってデータを処理するデータ処理装置において，
   前記レイアウトのデータ構成情報と，前記レイアウトとは独立した当該データ処理装置内で保持される内部データ形式を定めるデータ構成情報との対応情報を，レイアウト変換のナビゲーション情報として記憶するナビゲーション情報記憶手段と，
   前記アプリケーションプログラムのプロセスによって呼び出され，端末もしくは他のコンピュータシステムまたは外部記憶装置から入力されたデータを，前記ナビゲーション情報記憶手段が記憶するナビゲーション情報に従って，前記入力されたデータのレイアウトに対応する前記内部データ形式のデータに変換して内部のデータ記憶部に格納するレイアウト変換の処理を行い，端末もしくは他のコンピュータシステムまたは外部記憶装置へデータを出力する際に，前記内部のデータ記憶部に格納されている出力対象となっている内部データ形式のデータを，前記ナビゲーション情報記憶手段が記憶するナビゲーション情報に従って，出力先のレイアウトに対応するデータに変換して出力する処理を行い，かつ，前記アプリケーションプログラムのプロセスからの要求に従って，前記内部のデータ記憶部に格納されたデータの少なくとも参照，更新または削除の処理を行うデータ管理部品処理手段とを備える
   ことを特徴とするレイアウト変換機能を有するデータ処理装置。
2. 請求項１記載のレイアウト変換機能を有するデータ処理装置において，
   前記内部データ形式のデータには，前記レイアウト変換時に，各データを一意に識別するリソースＩＤと，各データにおける個々の項目を一意に識別するアイテムＩＤとが付与され，前記リソースＩＤは，前記レイアウトの種別に応じたハッシュ値によってアクセスされるリソースハッシュテーブルによって管理され，前記アイテムＩＤは，前記各リソースＩＤごとの各アイテム種別に応じたハッシュ値によってアクセスされるアイテムハッシュテーブルによって管理され，前記内部データ形式のデータは，前記アイテムハッシュテーブルの配下に接続される領域に各アイテムのデータ値が格納される構成で管理される
   ことを特徴とするレイアウト変換機能を有するデータ処理装置。
3. 請求項１または請求項２に記載のレイアウト変換機能を有するデータ処理装置において，
   前記ナビゲーション情報記憶手段に記憶されるナビゲーション情報は，前記内部データ形式のデータの項目ごとに，暗号化するか否かを示す設定情報を含み，
   前記データ管理部品処理手段は，前記内部データ形式のデータの項目に対し暗号化する旨の情報が設定されている場合に，レイアウトの変換時にその項目を暗号化して前記内部のデータ記憶部に格納し，前記アプリケーションプログラムのプロセスからのアクセス時および前記内部データ形式から所定のレイアウトへの逆変換時に，その項目を復号化して出力する暗号化／復号化変換手段を有する
   ことを特徴とするレイアウト変換機能を有するデータ処理装置。
4. 請求項１，請求項２または請求項３に記載のレイアウト変換機能を有するデータ処理装置において，
   前記ナビゲーション情報記憶手段に記憶されるナビゲーション情報は，前記レイアウトごとに，データが圧縮されているか否かを示す設定情報を含み，
   前記データ管理部品処理手段は，変換対象となっているレイアウトに対し，データが圧縮されている旨の情報が設定されている場合に，そのデータを非圧縮状態に復元してからレイアウト変換の処理を行う圧縮／非圧縮変換手段を有する
   ことを特徴とするレイアウト変換機能を有するデータ処理装置。
5. 請求項１から請求項４までのいずれか１項に記載のレイアウト変換機能を有するデータ処理装置において，
   前記ナビゲーション情報記憶手段に記憶されるナビゲーション情報は，前記内部データ形式のデータの項目ごとに，入力項目をチェックする場合の条件に関する設定情報を含み，
   前記データ管理部品処理手段は，前記内部データ形式のデータの項目に対し，入力項目をチェックする場合の条件に関する設定情報が設定されている場合に，設定されている条件に従って，レイアウト変換対象となっているデータの項目が正しいかどうかのチェックを行う入力項目チェック手段を有する
   ことを特徴とするレイアウト変換機能を有するデータ処理装置。
6. 端末もしくは他のコンピュータシステムまたは外部記憶装置との間で，それぞれ予め定められたレイアウトに従って構成されたデータを入出力し，アプリケーションプログラムを実行するプロセスによってデータを処理するデータ処理装置のコンピュータに実行させるためのデータ管理部品プログラムであって，
   前記コンピュータを，
   前記レイアウトのデータ構成情報と，前記レイアウトとは独立した当該データ処理装置内で保持される内部データ形式を定めるデータ構成情報との対応情報を，レイアウト変換のナビゲーション情報として記憶するナビゲーション情報記憶手段と，
   前記アプリケーションプログラムのプロセスによって呼び出され，端末もしくは他のコンピュータシステムまたは外部記憶装置から入力されたデータを，前記ナビゲーション情報記憶手段が記憶するナビゲーション情報に従って，前記入力されたデータのレイアウトに対応する前記内部データ形式のデータに変換して内部のデータ記憶部に格納するレイアウト変換の処理を行い，端末もしくは他のコンピュータシステムまたは外部記憶装置へデータを出力する際に，前記内部のデータ記憶部に格納されている出力対象となっている内部データ形式のデータを，前記ナビゲーション情報記憶手段が記憶するナビゲーション情報に従って，出力先のレイアウトに対応するデータに変換して出力する処理を行い，かつ，前記アプリケーションプログラムのプロセスからの要求に従って，前記内部のデータ記憶部に格納されたデータの少なくとも参照，更新または削除の処理を行うデータ管理部品処理手段として，
   機能させるためのデータ管理部品プログラム。
7. 請求項６記載のデータ管理部品プログラムであって，
   前記内部データ形式のデータには，前記レイアウト変換時に，各データを一意に識別するリソースＩＤと，各データにおける個々の項目を一意に識別するアイテムＩＤとが付与され，前記リソースＩＤは，前記レイアウトの種別に応じたハッシュ値によってアクセスされるリソースハッシュテーブルによって管理され，前記アイテムＩＤは，前記各リソースＩＤごとの各アイテム種別に応じたハッシュ値によってアクセスされるアイテムハッシュテーブルによって管理され，前記内部データ形式のデータは，前記アイテムハッシュテーブルの配下に接続される領域に各アイテムのデータ値が格納される構成で管理され，
   前記コンピュータを，
   前記内部データ形式のデータの管理手段として
   機能させるためのデータ管理部品プログラム。
8. 請求項６または請求項７に記載のデータ管理部品プログラムであって，
   前記ナビゲーション情報記憶手段に記憶されるナビゲーション情報は，前記内部データ形式のデータの項目ごとに，暗号化するか否かを示す設定情報を含み，
   前記コンピュータを，
   前記内部データ形式のデータの項目に対し暗号化する旨の情報が設定されている場合に，レイアウトの変換時にその項目を暗号化して前記内部のデータ記憶部に格納し，前記アプリケーションプログラムのプロセスからのアクセス時および前記内部データ形式から所定のレイアウトへの逆変換時に，その項目を復号化して出力する暗号化／復号化変換手段を有する前記データ管理部品処理手段として，
   機能させるためのデータ管理部品プログラム。
9. 請求項６，請求項７または請求項８に記載のデータ管理部品プログラムであって，
   前記ナビゲーション情報記憶手段に記憶されるナビゲーション情報は，前記レイアウトごとに，データが圧縮されているか否かを示す設定情報を含み，
   前記コンピュータを，
   変換対象となっているレイアウトに対し，データが圧縮されている旨の情報が設定されている場合に，そのデータを非圧縮状態に復元してからレイアウト変換の処理を行う圧縮／非圧縮変換手段を有する前記データ管理部品処理手段として，
   機能させるためのデータ管理部品プログラム。
10. 請求項６から請求項９までのいずれか１項に記載のデータ管理部品プログラムであって，
    前記ナビゲーション情報記憶手段に記憶されるナビゲーション情報は，前記内部データ形式のデータの項目ごとに，入力項目をチェックする場合の条件に関する設定情報を含み，
    前記コンピュータを，
    前記内部データ形式のデータの項目に対し，入力項目をチェックする場合の条件に関する設定情報が設定されている場合に，設定されている条件に従って，レイアウト変換対象となっているデータの項目が正しいかどうかのチェックを行う入力項目チェック手段を有する前記データ管理部品処理手段として，
    機能させるためのデータ管理部品プログラム。
11. 請求項６から請求項１０までのいずれか１項に記載のデータ管理部品プログラムを記録したコンピュータ読み取り可能な記録媒体。
    

Images