JPH0916692A - 事務処理系システムのデータベース生成装置 - Google Patents

Abstract

(57)【要約】 【目的】 専門知識を有する技術者がいなくとも、実用
上問題のない性能のユーザＤＢを自動生成することがで
きるデータベース生成装置を提供する。 【構成】 伝票の構造を定めた所定の設計ルールに基づ
いて各伝票の型式情報及びアイテム情報を含むデータベ
ース（以下、ＤＢ）設計情報を定義する設計情報定義部
１０と、この定義されたＤＢ設計情報を伝票単位に格納
して成るリポジトリ１１と、該リポジトリ１１より読み
込んだＤＢ設計情報を解析して該当伝票の構造に対応す
るＤＢテーブルを生成するＤＢ生成モジュール１２とで
構成し、操作端末の画面から伝票を定義するだけでＤＢ
テーブルをユーザＤＢ１３に作成できるようにした。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、事務処理系システムに
おいて、伝票又は帳票作成用アプリケーションの基礎と
なるデータベース（以下、ＤＢ）を自動生成する装置に
関する。

【０００２】

【従来の技術】最近、アプリケーション作成の基礎とな
るユーザＤＢを設計、構築する際に、当該アプリケーシ
ョンを走行させる業務処理系システムの開発にあわせて
４ＧＬ（第四世代言語）ツールやグラフィック・ユーザ
・インタフェースの設計支援ツールを利用することが多
くなっている。この場合、設計、構築の担当者として、
ＤＢ構造に関する専門知識を有する技術者が割り当てら
れ、しかも、その担当者は、システムのプロジェクト内
に専用に配されるのが通常であった。

【０００３】

【発明が解決しようとする課題】上述のように、従来
は、専用に割り当てられた担当者自身が、設計支援ツー
ルを利用してユーザＤＢを設計した後にその構築を行っ
ていた。また、４ＧＬ系ツールを使用する場合には、構
築したユーザＤＢを利用して伝票や帳票定義を行ってア
プリケーションプログラムを作成していた。そのため、
ＤＢ設計やその構築にかかる時間は、システム開発のか
なりの部分を占め、開発コストを低減する上で大きな問
題になっていた。また、ユーザＤＢの性能が担当者の技
術レベルに依存するため、場合によってはデータ保全が
必ずしも十分に図れないという問題があった。

【０００４】本発明の課題は、事務処理系システムの開
発に際して、専門知識を有する技術者がいなくとも、実
用上問題のない性能のユーザＤＢを自動生成することが
できるＤＢ生成装置を提供することにある。

【０００５】

【課題を解決するための手段】上記課題を解決する本発
明のＤＢ生成装置は、伝票の構造を定めた所定の設計ル
ールに基づいて各伝票の型式情報及びアイテム情報を含
むＤＢ設計情報を定義する設計情報定義部と、前記定義
されたＤＢ設計情報を伝票単位に格納して成るリポジト
リと、該リポジトリより読み込んだＤＢ設計情報を解析
して該当伝票の構造に対応するＤＢテーブルを生成する
ＤＢ生成モジュールと、を有することを特徴とする。

【０００６】ここで設計ルールとは、例えば、伝票の繰
り返し部分と非繰り返し部分のテーブル対応ルール、繰
り返し部分が複数ある場合の認識ルール、ネスト型の場
合の分離ルール、テーブル統合ルール、不要アイテムの
削除基準、テーブル間の関連付け手順等をいう。

【０００７】この構成において、ＤＢ生成モジュール
は、例えば、前記リポジトリより読み込んだ型式情報に
基づいて該当伝票間の統合関係の有無を判定し、統合関
係にあるときは当該伝票の情報と共に統合用情報を生成
して第１メモリ上に展開する第１の手段と、前記アイテ
ム情報に基づいて該当伝票間の参照関係の有無を判定
し、参照関係があるときは参照先の伝票の識別情報を生
成して前記統合用情報に付加する第２の手段と、前記第
１メモリ上に展開された該当伝票の情報のアイテム解析
を行い、少なくともアイテム間、伝票間又は伝票と帳票
間のリンク情報を含むアイテム解析情報を生成して第２
メモリ上に展開する第３の手段と、を有し、前記第２メ
モリ上に展開されたアイテム解析情報に基づいて前記伝
票の構造に対応するデータベーステーブルを生成するも
のである。なお、前記統合用情報、前記参照先の伝票の
識別情報、前記アイテム間又は伝票間のリンク情報等を
前記リポジトリの該当領域に格納する第４の手段を更に
有する構成であってもよい。

【０００８】

【作用】設計情報定義部にＤＢ設計情報を定義すると、
その定義内容がリポジトリに格納され、同時にＤＢ生成
モジュールが起動する。ＤＢ生成モジュールは、リポジ
トリから伝票情報を読み込み、これをメモリ上に展開し
て型式情報の解析を行う。解析の結果、該当伝票が統合
の対象である場合は、統合用情報を生成する。また、ア
イテム情報を読み込んでメモリ上の該当伝票の参照関係
の有無を判断し、参照関係があるときは参照先の伝票の
識別情報を生成して統合用情報に付加する。その後、メ
モリ上に展開された情報に基づいて所定のアイテム解析
を行い、その結果であるアイテム解析情報をメモリ上に
展開する。その後、アイテム解析情報に基づいて該当伝
票の構造に対応するＤＢテーブルを自動生成する。

【０００９】

【実施例】次に、図面を参照して本発明の実施例を詳細
に説明する。ユーザＤＢ設計の基本となる伝票や帳票の
構造は、大別すると、顧客コードや顧客名等のヘッダ部
と、商品明細などの繰り返し項目部等のボディ部と、合
計等のフッタ部とから構成されている。そこで、以下に
説明する実施例では、ユーザＤＢの設計ルールに基づい
て上記三つの部分と、リポジトリに格納されているリレ
ーショナルＤＢのテーブル構造との関連付けを行うとと
もに、この関連付けからＳＱＬ文を生成、実行し、ユー
ザＤＢ構築を自動的に行う。

【００１０】図１に、本実施例に係るＤＢ生成装置の構
成図を示す。このＤＢ生成装置は、設計情報定義部１０
と、リポジトリ１１と、ＤＢ生成モジュール１２と、ユ
ーザＤＢ１３とで構成される。設計情報定義部１０は、
伝票の構造を定めた所定の設計ルールに基づいて各伝票
の型式情報及びアイテム情報を含むＤＢ設計情報を定義
するものであり、リポジトリ１１は、図２に示すよう
に、伝票の定義情報を格納する伝票／帳票情報ブロック
１１１、伝票等の各アイテムの定義情報を格納するアイ
テム情報ブロック１１２、ＤＢ生成モジュール１２が生
成したテーブル関連情報等を格納するリレーション情報
ブロック１１３、及びＤＢ生成モジュール１２が生成し
たテーブルの各カラムに関する情報を格納するカラム情
報ブロック１１４から構成されるものである。これらの
各ブロックは、例えば論理伝票名をキー情報にしてリン
クしており、いずれか一つのブロックを特定することに
より関連する他のブロック内の格納情報が索出できるよ
うになっている。

【００１１】まず、上記設計ルールの詳細について、図
３〜図９を参照して説明する。 （１）繰り返し部分と非繰り返し部分の分離 定義時には、図３に示すように、ヘッダ部（顧客コー
ド）、フッタ部を１テーブルとし、ボディ（繰り返し）
部も１テーブルとして第１正規のテーブルを生成する。

【００１２】（２）複数ボディの認識 ボディ部が２つ以上あるときは、図４に示すように、ヘ
ッダ部、フッタ部で１テーブル、各ボディ部で各１テー
ブルが生成される。例えば図示のように、ボディ部が２
つ以上あれば、ヘッダ部、フッタ部１テーブル、ボディ
部２テーブルの計３テーブルが生成される。

【００１３】（３）ネスト型 部品展開のように、ボディ部のあるアイテムに対して、
さらにその明細となるボディ部がある形態のことを、本
実施例ではネスト型と呼ぶ。このネスト型の場合には、
図５に示すように、メイン伝票のヘッダ部、フッタ部で
１テーブル、メイン伝票のボディ部とサブ伝票のフッタ
部で１テーブル、サブ伝票のボディ部で１テーブルを生
成する。

【００１４】（４）テーブル統合 各関連部署を持ち回り、各関連部署共通アイテムと各関
連部署特定アイテムがあるような伝票を本実施例では親
子関係の伝票と呼ぶ。この場合、親伝票Ａでは、当該部
署用に伝票を定義するが、共通アイテムがあるので、図
６に示すように、それぞれの伝票Ａ，Ｂのヘッダ部、フ
ッタ部を１テーブル、各伝票Ａ，Ｂのボディ部を１テー
ブルとし、複数の伝票が定義されてもヘッダ部、フッタ
テーブル、ボディテーブルの２テーブルのみを生成す
る。

【００１５】（５）不要アイテムの削除 例えば図７に示すように、単価×数量から小計が求める
ことができる場合には、関係定義で「結合・参照（実体
なし）」、「参照・参照（実体なし）」の指定を行う。
これらの定義は、ＤＢテーブルへのアクセス条件の一態
様であり、（実体なし）とは実際にデータがない（格納
しない）ことを意味する。この場合には、ＤＢテーブル
中には、小計のアイテムを生成せず、画面表示する場合
に、所定の計算結果が表示されるようにテーブルを生成
する。

【００１６】図１に戻り、ＤＢ生成モジュール１２につ
いて、詳細に説明する。このＤＢ生成モジュール１２
は、上記設計ルールに基づいてＤＢ生成のためのＳＱＬ
文を作成し、作成したＳＱＬ文によりユーザＤＢ１３内
に複数のテーブルとインデックスとを生成するととも
に、ＤＢアクセスの際に必要となるＤＢ上のテーブル情
報、インデックス情報等をリポジトリ１１に格納するも
のである。

【００１７】そのための具体的手法として、リポジトリ
１１の格納情報（設計情報）を読み込むリポジトリ情報
読込部１２１， リポジトリ１１へリレーション情報及
びカラム情報を書き込むリポジトリ情報書込部１２２，
読み込んだ伝票の型式情報（タイプ）を解析し、破線で
示すメモリ上に該当伝票情報を展開する伝票タイプ解析
部１２３（以上第１の手段），メモリに展開された情報
に基づき、伝票間、あるいはアイテム間の参照関係を解
析する参照関係解析部１２４（第２の手段），メモリに
展開された情報に基づき、所定のアイテム解析してその
結果を表すアイテム解析情報をメモリ上に展開するアイ
テム解析部１２６（第３の手段），このアイテム解析情
報に基づいて生成したＳＱＬ文を実行してユーザＤＢ１
３上にテーブルを生成するＳＱＬ文生成・実行部１２７
を構成する。なお、ＳＱＬ文は例示であって、必ずしも
これに限定されるものではない。

【００１８】次に、上記構成の本実施例のＤＢ生成装置
の動作を、伝票ＡＰに対応するユーザＤＢを生成する場
合を例に挙げて具体的に説明する。

【００１９】設計情報定義部１０にＡＰ対応のレイアウ
トやアイテム情報を含むＤＢ設計情報を定義すると、設
計情報定義部１０は、その定義情報をリポジトリ１１の
該当領域に設定し、設定完了後にＤＢ生成モジュール１
２へその旨を通知する。ＤＢ生成モジュール１２は、こ
の通知を契機に起動して所要の処理を行う。ＤＢ生成モ
ジュール１２による処理手順を図１０及び図１１をも参
照しながら説明する。

【００２０】図１０において、リポジトリ情報読込部１
２１は、リポジトリ１１から伝票情報を読み込み（Ｓ１
０１）、伝票タイプ解析部１２３に処理を移す。伝票タ
イプ解析部１２３は、伝票情報をメモリ上に展開し、伝
票タイプの解析を行う（Ｓ１０２）。解析の結果、該当
伝票が統合の対象であるか否かを判定し（Ｓ１０３）、
統合対象である場合（Ｓ１０３：Ｙｅｓ）、例えばＡ部
署で処理した伝票をＢ部署に引き継ぎ、Ｂ部署ではＡ部
署の処理項目に加えてＢ部署での必要項目を入力するタ
イプの伝票（本実施例では、Ａ部署で処理した伝票を親
伝票、Ｂ部署で処理した伝票を子伝票と称する）にある
場合は、関連伝票情報、例えば親と子の伝票を集めて
（Ｓ１０４）、統合に必要な情報を生成する。統合の対
象でない場合（Ｓ１０３：Ｎｏ）、あるいは新たに統合
する伝票がない場合は、参照関係解析部１２４に処理を
移す。

【００２１】参照関係解析部１２４では、リポジトリ情
報読込部１２１を介してアイテム情報を読み込み（Ｓ１
０５）、メモリ上の該当伝票の参照関係の有無を、上記
読み込んだアイテム情報から判断し、繰り返し部を持つ
か、親子関係にあるかの情報を生成する（Ｓ１０６）。
また、該当伝票が統合の対象か否か、例えば親子関係に
あるか否かを判定し（Ｓ１０７）、統合対象である場
合、例えば親子関係にある場合（Ｓ１０７：Ｙｅｓ）
は、関連する伝票のカラム情報を事前にリポジトリのカ
ラム情報に追加する（Ｓ１０８）。統合対象でない場合
（Ｓ１０７：Ｎｏ）は、アイテム解析部１２５に処理を
移す。

【００２２】アイテム解析部１２５では、メモリ上に展
開された情報に基づいてアイテム解析を行う（Ｓ１０
９）。すなわち、該当アイテムのデータ型を決定し、さ
らに該当アイテムが、登録すべきＤＢ上のアイテムとし
て不要か否かの検査をして（Ｓ１１０）、必要であれば
リポジトリ１１のカラム情報に追加する（Ｓ１１１）。
なお、不要なアイテムと判定されるのは、上述のルール
において、参照関係が「参照、実体なし」の場合であ
る。その後、リポジトリ１１の該当アイテムのアイテム
情報の参照関係を検査し（Ｓ１１２）、参照関係がある
場合（Ｓ１１２：Ｙｅｓ）は、参照先の正当性を確認す
る（Ｓ１１３）とともに、参照先情報をリポジトリ１１
のリレーション情報に追加する（Ｓ１１４）。次いで、
システムカラム情報をリポジトリ１１のカラム情報に追
加する（Ｓ１１５）。ここに、システムカラム情報と
は、設計情報定義部１０がデータ処理に使用するカラム
情報であり、データ入力順のシーケンシャル番号や伝票
の入力が確定（以後の変更不能状態）したかどうかの確
定フラグ、帳票で出力済みかどうかの帳票出力済みフラ
グ、ヘッダ部と明細部の関係付けをするキー情報をい
う。

【００２３】以上の処理を対象となる全アイテムについ
て繰り返し（Ｓ１１６）、処理が完了した場合（Ｓ１１
６：Ｙｅｓ）は、リポジトリ１１のカラム情報をテーブ
ル単位にソートし（Ｓ１１７）、そのソート結果でアイ
テムのオフセット計算を行い（Ｓ１１８）、計算結果を
リポジトリ１１のカラム情報に付加する（Ｓ１１９）。
このオフセットは、ＤＢアクセスモジュールがデータア
クセス時に使用するものである。

【００２４】次に、テーブル情報生成部１２６におい
て、リポジトリ１１のカラム情報に基づくＤＢテーブル
生成用のＳＱＬ文を生成し（Ｓ１２０）、さらにインデ
ックス生成用のＳＱＬ文も生成する（Ｓ１２１）。そし
て、生成したＳＱＬ文を実行してＤＢ１３上でテーブル
の生成を行い（Ｓ１２２）、テーブル生成が完了した時
点でＤＢ生成処理を終える。

【００２５】このように、本実施例によれば、設計情報
定義部にＡＰ対応のレイアウトやアイテム情報を定義す
るだけでユーザＤＢが自動的に生成されるので、ＤＢ設
計の時間が削減されるだけでなく、ＤＢ技術者がいなく
とも実用上問題のないレベルの性能のユーザＤＢを得る
ことができる。

【００２７】

【発明の効果】以上の説明から明らかなように、本発明
のＤＢ生成装置によれば、伝票を定義するだけでＤＢテ
ーブルが自動生成されるので、ＤＢ設計の時間が削減さ
れ、ＤＢ設計者や技術者がいなくとも実用上問題のない
性能のＤＢを容易に構築することができる。

【図面の簡単な説明】

【図１】本発明の一実施例に係るＤＢ生成装置のブロッ
ク構成図。

【図２】本実施例のＤＢ生成装置が備えるリポジトリの
構造説明図。

【図３】伝票定義時に有効となるテーブル作成ルールの
説明図。

【図４】伝票定義時に有効となる複数ボディの認識ルー
ルの説明図。

【図５】伝票定義時に有効となるネスト型の場合のテー
ブル分離ルールの説明図。

【図６】テーブル統合ルールの説明図。

【図７】不要アイテムの削除基準の説明図。

【図８】本実施例のＤＢ生成モジュールによる処理手順
図。

【図９】本実施例のＤＢ生成モジュールによる処理手順
図。

【符号の説明】

１０ 設計情報定義部 １１ リポジトリ １１１ 伝票定義情報ブロック １１２ アイテム情報ブロック １１３ リレーション情報ブロック １１４ カラム情報ブロック １２ ＤＢ生成モジュール １２１ リポジトリ情報読込部 １２２ リポジトリ情報書込部 １２３ 伝票タイプ解析部 １２４ 参照関係解析部 １２５ アイテム解析部 １２６ テーブル情報生成部 １２７ ＳＱＬ文生成・実行部 １３ ユーザＤＢ

Claims (3)

【特許請求の範囲】
1. 【請求項１】 伝票の構造を定めた所定の設計ルールに
   基づいて各伝票の型式情報及びアイテム情報を含むデー
   タベース設計情報を定義する設計情報定義部と、前記定
   義されたデータベース設計情報を伝票単位に格納して成
   るリポジトリと、該リポジトリより読み込んだデータベ
   ース設計情報を解析して該当伝票の構造に対応するデー
   タベーステーブルを生成するデータベース生成モジュー
   ルと、を有することを特徴とする事務処理系システムの
   データベース生成装置。
2. 【請求項２】 前記データベース生成モジュールは、 前記リポジトリより読み込んだ型式情報に基づいて該当
   伝票間の統合関係の有無を判定し、統合関係にあるとき
   は当該伝票の情報と共に統合用情報を生成して第１メモ
   リ上に展開する第１の手段と、 前記アイテム情報に基づいて該当伝票間の参照関係の有
   無を判定し、参照関係があるときは参照先の伝票の識別
   情報を生成して前記統合用情報に付加する第２の手段
   と、 前記第１メモリ上に展開された該当伝票の情報のアイテ
   ム解析を行い、少なくともアイテム間、伝票間又は伝票
   と帳票間のリンク情報を含むアイテム解析情報を生成し
   て第２メモリ上に展開する第３の手段と、を有し、 前記第２メモリ上に展開されたアイテム解析情報に基づ
   いて前記伝票の構造に対応するデータベーステーブルを
   生成する請求項１記載の事務処理系システムのデータベ
   ース生成装置。
3. 【請求項３】 少なくとも前記統合用情報、前記参照先
   の伝票の識別情報、前記アイテム間又は伝票間のリンク
   情報を前記リポジトリの該当領域に格納する第４の手段
   を有する請求項２記載の事務処理系システムのデータベ
   ース生成装置。