(57)【要約】【課題】ネットワーク型データベースに格納されたデータをリレーショナルデータベースに格納してＳＱＬで操作する際に、ネットワークデータベース向けのアプリケーションプログラムのレコード取り出し論理を適用可能としながらネットワークデータベースと同様のトランザクションレスポンスを保証する技術を提供する。【解決手段】テーブル形式のデータベースシステムにおける階層型データのマッピング方法であって、前記階層型データに対応して別々に格納された複数のテーブルから所望の関連レコードを取り出すための共通カラムを定義し、各レコードに付与する共通カラム付与ステップと、前記共通カラム付与ステップで付与した共通カラム値をキーとして前記関連レコードを抽出し、一つのセグメントを形成するセグメント化ステップと、前記セグメントをデータベースへのアクセス単位として格納するセグメント格納ステップとを有することを特徴とする階層型データのマッピング方法。【選択図】      図１
2004259075.tif 000002
【特許請求の範囲】
【請求項１】
テーブル形式のデータベースシステムにおける階層型データのマッピングプログラムであって、
コンピュータに、
前記階層型データに対応して別々に格納された複数のテーブルから所望の関連レコードを取り出すための共通カラムを定義し、各レコードに付与する共通カラム付与ステップと、
前記共通カラム付与ステップで付与した共通カラム値をキーとして前記関連レコードを抽出し、一つのセグメントを形成するセグメント化ステップと、
前記セグメントをデータベースへのアクセス単位として格納するセグメント格納ステップと
を実行させる階層型データのマッピングプログラム。
【請求項２】
前記共通カラム付与ステップにおいて、複数のテーブルに指定する前記共通カラムは、前記セグメント内の各テーブル毎の取り出し順序を指定する順序カラム、および構造型データに対応する上位のテーブルのレコードを関連付ける関連カラムが含まれることを特徴とする請求項１記載の階層型データのマッピングプログラム。
【請求項３】
テーブル形式のデータベースシステムにおける階層型データのマッピング装置であって、
前記階層型データに対応して別々に格納された複数のテーブルから所望の関連レコードを取り出すための共通カラムを定義し、各レコードに付与する共通カラム付与手段と、
前記共通カラム付与手段で付与した共通カラム値をキーとして前記関連レコードを抽出し、一つのセグメントを形成するセグメント化手段と、
前記セグメントをデータベースへのアクセス単位として格納するセグメント格納手段と
を有することを特徴とする階層型データのマッピング装置。
【請求項４】
テーブル形式のデータベースシステムにおける階層型データのマッピング方法であって、
前記階層型データに対応して別々に格納された複数のテーブルから所望の関連レコードを取り出すための共通カラムを定義し、各レコードに付与する共通カラム付与ステップと、
前記共通カラム付与ステップで付与した共通カラム値をキーとして前記関連レコードを抽出し、一つのセグメントを形成するセグメント化ステップと、
前記セグメントをデータベースへのアクセス単位として格納するセグメント格納ステップと
を有することを特徴とする階層型データのマッピング方法。
【請求項５】
テーブル形式のデータベースシステムにおける階層型データのマッピングプログラムを記録した記録媒体であって、
コンピュータに、
前記階層型データに対応して別々に格納された複数のテーブルから所望の関連レコードを取り出すための共通カラムを定義し、各レコードに付与する共通カラム付与ステップと、
前記共通カラム付与ステップで付与した共通カラム値をキーとして前記関連レコードを抽出し、一つのセグメントを形成するセグメント化ステップと、
前記セグメントをデータベースへのアクセス単位として格納するセグメント格納ステップと
を実行させる階層型データのマッピングプログラムを記録したコンピュータ読取可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク型データベースに格納されたデータをリレーショナルデータベースに格納してＳＱＬで操作する際に、ネットワーク型データベース向けのアプリケーションプログラムのレコード取り出し論理を適用可能としながらネットワーク型データベースと同様のトランザクションレスポンスを保証する技術分野に関する。
【０００２】
【従来の技術】
従来から日常的に使用されるデータベースに、代表的にネットワーク型データベース（ＮＤＢ：Ｎｅｔｗｏｒｋ  Ｄａｔａｂａｓｅ）やリレーショナルデータベース（ＲＤＢ：Ｒｅｌａｔｉｏｎａｌ  Ｄａｔａｂａｓｅ  ）がある。
ネットワーク型データベースは、図８の銀行取引における銀行口座レコードの例に示すように、親レコードの名義人１を頂点として、子レコードとしての口座種別１、２、孫レコードとしての取引履歴１〜５など、関連するレコードを下位に連結した三角形の階層構造をなしており、該階層構造を格納・取り出しの物理的な入出力単位として管理している。各レコードの階層関係を基にポインタを利用してレコード間を管理するため、検索のスピードが速く、レスポンスを重視する基幹業務の処理に適している。しかし、ネットワーク型データは、こうした階層データ構造と順序性を保持したクローズなデータベースであるがため、複雑であり、アクセスロジックもプログラムに大きく依存しており、システムの設計負担が大きい。
【０００３】
一方、リレーショナルデータベースでは、レコードは２次元のテーブル形式で表現され、親子関係はキーで管理される。そして、異なるテーブル間も各データに設けたキーによって関係付けられるため、目的に応じた柔軟な検索を可能としており、オープンなシステムに向いている。ハードの高性能化にともない、オープンシステムでのデータベースとして主流となっているが、取り出し対象のレコードを特定するための結合キーの処理に、ＣＰＵの処理時間が増大する欠点がある。
【０００４】
これに対し、従来、ネットワーク型データベースのもつ高速性を生かしつつ、そのデータをシンプルなリレーショナルデータベースへ移行させる技術の提案もなされている（例えば、特許文献１参照）。
このようなネットワーク型データベースのデータを従来のリレーショナルデータベースに移行する場合には、各階層のレコード毎に構造が異なるため、物理的にも論理的にも別々のテーブルにマッピングして格納している。
リレーショナルデータベースにおいて、ネットワーク型データベースのアプリケーションプログラムの資産（  論理）  を継承するには、頂点のレコードを起点とした下位層のレコードの関係、およびその取り出し順序を考慮した設計が必要となる。
【０００５】
すなわち、ネットワーク型データベースで格納ロジックとして規定されていた各レコードの関連づけ（  図８のように、名義人レコードの下には、必ずその名義人が持つ口座レコードが連結されている）をリレーショナルデータベースで行うには、別々のテーブルのレコード同志を結合するための共通のカラムを定義して関連づけるように設計する必要がある。
【０００６】
図９の従来のマッピング例に示すように、取引履歴のようなレコードの場合、ユーザが取り出し順を制御（  例えば、最新の取引履歴から順に取り出す  ）できなければならない。名義人テーブルと口座テーブルを結合するカラムとして結合キー１が、口座テーブルと取引履歴テーブルを結合するカラムとして結合キー２が設定されている。このように、ネットワーク型データベースでは、格納時にレコードを連結することで実現されていたが、リレーショナルデータベースの場合には、取り出しの順番を規定するカラムを定義することによって、レコードの取り出し順を制御している。
【０００７】
【特許文献１】
特開２００１−３２５１３３号公報（第２〜６頁）
【０００８】
【発明が解決しようとする課題】
しかしながら、従来、ネットワーク型データベースの階層型データをリレーショナルデータベースにマッピングした場合、
１）ネットワーク型データベースでは１  つの入出力単位であったのものが物理的に分断されるため、データ取り出し時の記憶装置へのアクセスが頻発する、
２）ネットワーク型データベースで格納ロジックにより規定されていたレコード間の関係や取り出し順を、テーブルのカラムとその値としてユーザが規定する必要があり、設計コストが高くなる、
３）別々のテーブルのレコード間の関係をカラム値として規定するのに、上位層のレコードに関連する下位層のレコードを取り出すテーブルの結合が必須となり、ネットワーク型データベースと比較して取り出し対象のレコードを特定するためのＣＰＵの処理時間が増大する、
等の問題をかかえていた。
【０００９】
つまり、ネットワーク型データベースの各階層のレコードをリレーショナルデータベースの別テーブルに分割して格納することになり、テーブル間の結合に伴う性能面での問題が残されていた。
そこで、これらの上記問題を解決するため、本発明では、同一セグメントに関連レコードを集約して格納し、同一セグメント内のレコードのみをテーブル結合することで、Ｉ／Ｏ（  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）  のアクセス回数を減らし、効率化と高速化を実現するマッピング技術を提供する。
【００１０】
【課題を解決するための手段】
第一の発明は、テーブル形式のデータベースシステムにおける階層型データのマッピングプログラムであって、コンピュータに、前記階層型データに対応して別々に格納された複数のテーブルから所望の関連レコードを取り出すための共通カラムを定義し、各レコードに付与する共通カラム付与ステップと、前記共通カラム付与ステップで付与した共通カラム値をキーとして前記関連レコードを抽出し、一つのセグメントを形成するセグメント化ステップと、前記セグメントをデータベースへのアクセス単位として格納するセグメント格納ステップとを実行させる階層型データのマッピングプログラムに関する。
【００１１】
すなわち、第一の発明によれば、関連して取り出したい複数のテーブルに属するレコードを、物理的にまとめて一つのセグメント（  二次記憶へのアクセス単位  ）に格納する。その場合、関連レコードをまとめて格納するセグメントを規定するために、各テーブルに共通のカラム（  セグメントカラム  ）を定義させ、格納するページをユーザが指定可能としている。
【００１２】
これにより、ユーザは関連して取り出したいレコードを物理的に集約して格納することが可能となり、取り出し時には上記カラムを条件に指定してアクセス範囲を絞り込むことで、二次記憶へのアクセスが大幅に削減されることとなる。
第二の発明は、前記共通カラム付与ステップにおいて、複数のテーブルに指定する前記共通カラムは、前記セグメント内の各テーブル毎の取り出し順序を指定する順序カラム、および構造型データに対応する上位のテーブルのレコードを関連付ける関連カラムとが含まれることを特徴とする上記第一の発明に記載の階層型データのマッピングプログラムに関する。
【００１３】
すなわち、第二の発明によれば、テーブル定義時の指定により、ユーザがテーブルに指定したカラムに加えて、順序カラムおよび関連カラムの仮想カラムを追加する。順序カラムは、セグメント内の各テーブル毎の順序がシステムにより自動的に格納されるカラムであり、関連カラムは、関連づけられている上位のテーブルのレコードが持つ順序カラムの値を格納するカラムである。これらを付与することによって、ユーザはテーブル間の関連づけやレコードの取り出し順を意識したテーブル設計が不要となり、かつ、関連するレコードを取り出すためのテーブルの結合も同一セグメント内に限られ負荷が大きく削減される。
【００１４】
【発明の実施の形態】
以下、図面にもとづいて本発明の実施形態を説明する。
図１は、本発明の基本システム構成を示す。本発明のデータのマッピング方法を具現化するシステムは、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ  ）をベースとしたアプリケーションプログラム１、データをマッピングする各手段を有するデータベースシステム２、およびデータベース３とで構成される。また、データベースシステム２におけるマッピングは、共通カラム付与手段２１、セグメント化手段２２、セグメント格納手段２３、およびデータ取り出し手段２４によって実行される。さらに、データベース３は、ネットワークデータベースからの階層型データを取得して格納したデータテーブル３１、およびセグメントデータ３２を備える。
【００１５】
ここで、データベースシステム２は、コンピュータであり、予め内蔵されたプログラムがコンピュータ上で実行され、共通カラム付与手段２１、セグメント化手段２２、セグメント格納手段２３、およびデータ取り出し手段２４の各手段が実現される。そして、当該プログラムは、フロッピーディスク、コンパクトディスク、ＣＤ−ＲＯＭ等のコンピュータ読取可能な記録媒体に記録され、図には示していないが、内蔵あるいは、外部接続された媒体読取装置にセットしインストールすることによって実行可能な状態としてもよい。
【００１６】
図２は、本発明の実施の形態になるセグメント構成の概念図である。格納された複数のテーブル１、２・・・ｎに渡って、例えば、名義人氏名等のような共通のカラムを定義し、定義した共通のカラムを有する取り出したい関連のレコードを集めて、セグメント１、２・・・ｎを形成し、該セグメント単位でデータベース３に格納する。
【００１７】
このように定義された共通のカラムを有する複数のレコードを集めて、セグメント単位でデータベース３に格納することによってマッピングする方法は、別々のテーブルに分散して格納し、結合キーによって複数のレコードを関係付ける従来の方法に比べ、ネットワーク型データベースの効率性を保ちつつ、リレーショナルデータベースにおいて、簡便なアプリケーションプログラムによるアクセスを可能とする。
【００１８】
図３は、本発明の実施の形態になる各テーブルにおける共通カラムの定義例を示す。名義人テーブル１１、口座テーブル１２、および取引履歴テーブル１３の各テーブルに対し、共通に、セグメントカラム、順序カラム、および関連カラムを設ける。
また、テーブル定義時の指定により、セグメントカラムに加えて、セグメント内の各テーブル毎の順序がシステムにより自動的に格納される順序カラム、および上位のテーブルのレコードが持つ前記順序カラムの値を格納する関連カラムが付与される。
【００１９】
これにより、テーブル間の関連づけやレコードの取り出し順を意識しなくて済み、また、関連するレコードを取り出すためのテーブル結合による負荷も軽減され、ユーザとって、システムの設計が大変簡便化される。
図４は、本発明の実施の形態になるリレーショナルデータベースにおける階層型データの格納フローチャートを示す。まず、格納されたネットワーク型の階層型データに対応した複数のテーブルにおける各レコードに共通のカラムを定義し付与する（ステップＳ１０１）。つぎに、この共通カラムの値をキーとして、複数のテーブルから関連のレコードを抽出して一つのセグメントとする  （ステップＳ１０２）。さらに、抽出した複数のレコードを集めたセグメントをアクセス単位としてデータベース３に格納する（ステップＳ１０３）。
【００２０】
以上、セグメントを一つの単位としてアクセスさせることによって、リレーショナルデータベースにおいて、高速、かつ、簡単に階層型データが扱えるデータベースシステムが実現される。
図５は、本発明の実施の形態になるセグメントを格納したデータベースの構造例を示す。ネットワーク型データベースの階層型データは、セグメント単位でデータベース３に格納され、図３の定義に基づき、１つのセグメントとして、名義人レコード、口座レコード、および取引履歴レコードが、それぞれ、セグメントカラム、レコードの順序カラム、および上位レコードとの関連カラムを有する構造となっている。
【００２１】
図５を用いて、さらに、具体的に説明すると、”富士通夫”で定義されたセグメント２に関する複数のレコードが集められ、まず、名義人レコードでは、セグメントカラムは２、順序カラムは１、関連カラムはブランクで表現される。つぎの口座レコードでは、セグメントカラムは２、順序カラムは、普通預金、定期預金の取引発生順に、自動的にそれぞれ１、２が記入され、関連カラムは、その上位の名義人レコードが１つであるので、その順序カラムの番号がそのまま挿入される。取引履歴レコードでは、同様に、順序カラムは、取引発生順に番号が自動的に記入され、関連カラムは、上位の順序カラムが転記される。
【００２２】
上記のようにデータベース３に格納した図５に示すデータは、ＳＱＬによって以下のように取り出すことができる。
以下の例は、“富士通夫”である名義人データを取り出す場合を示す。
ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  名義人  ＴＡＢＬＥ  ＷＨＥＲＥ  セグメント  ＝  ２
また、氏名が“富士通夫”の取引額を“普通預金に限定して”、“取引年月日の降順に”取り出す場合、以下のように問い合わせる。
【００２３】
ＳＥＬＥＣＴ  取引履歴．  取引額
ＦＲＯＭ  取引履歴  ＴＡＢＬＥ
ＷＨＥＲＥ  取引履歴  ＴＡＢＬＥ．セグメント  ＝  ２
ＡＮＤ  取引履歴  ＴＡＢＬＥ．  関連  ＝（ＳＥＬＥＣＴ  口座  ＴＡＢＬＥ．  順序  ＦＲＯＭ  口座  ＴＡＢＬＥ
ＷＨＥＲＥ  口座  ＴＡＢＬＥ．  セグメント  ＝  ２
ＡＮＤ  口座  ＴＡＢＬＥ．  口座種別  ＝普通預金  ）
ＯＲＤＥＲ  ＢＹ    取引履歴  ＴＡＢＬＥ．  取引年月日  ＤＥＳＣ；  ←降順の取り出し
上記の問い合わせは、テーブルを結合しているにもかかわらず物理的には全てセグメント２の中で完結している。また、ユーザは順序カラムや関連カラムの“値”を意識することなく、単純に条件に指定することで問い合わせ結果を得ることができる。
【００２４】
さらに、“富士通夫”の“普通預金の口座”の取引履歴を“履歴の先頭に”追加する場合には以下のようになる。
ＳＥＬＥＣＴ  口座  ＴＡＢＬＥ．  順序            ←普通預金の口座の特定
ＦＲＯＭ  口座  ＴＡＢＬＥ
ＷＨＥＲＥ    口座  ＴＡＢＬＥ．  セグメント  ＝  ２
ＡＮＤ    口座  ＴＡＢＬＥ．  口座種別  ＝普通預金  ；
ＩＮＳＥＲＴ  ＩＮＴＯ    取引履歴（  セグメント，  取引年月日，  取引額，  …  ）
ＶＡＬＵＥＳ（              ２，                      ←富士通夫の
２００２／０９／１０，  ￥１００００，  …，
ＦＩＲＳＴ，                ←履歴の先頭に
口座ＴＡＢＬＥ．順序  ）；      ←普通預金の口座の
上記の場合、図６に示すように、セグメント２  の各取引履歴レコードは、自動的に変更される。図６は、本発明の実施の形態になる格納テーブルの先頭へのレコードの追加例を示している。
【００２５】
特徴的なことは、順序カラムにＦＩＲＳＴ  を指定して追加したことで、セグメント２内の取引履歴レコードの順序カラムが全体的に変更されている点である。これは、システムにより自動的にメンテナンスされる仮想的なカラムとしたことによるものであり、同様のカラムを実体としてユーザが定義した場合には、他のレコードの同カラムの値が全てメンテナンスされることになる。
【００２６】
図７は、本発明の実施の形態になる上位のレコードの順序カラムの変更例を示す。関連カラムについても、ユーザは関連づけたい上位の普通預金レコードの順序カラムの値を指定するだけで“値”をとくに意識する必要はない。これは、たとえば“富士通夫”が“当座預金”口座を新規に開設し、口座レコードの先頭（  順序カラム  ＝  １  ）にレコードが追加された場合でも、自動的にメンテナンスされるためである。
【００２７】
【発明の効果】
以上、ネットワークデータベースの階層構造のデータをリレーショナルデータベースにマッピングさせるプログラム、方法、および装置において、関連して取り出したい複数のテーブルに属するレコードを、物理的にまとめて一つのセグメント（  データベースへのアクセス単位  ）に格納し、関連レコードをまとめて格納するセグメントを規定するために、各テーブルに共通のカラム（  セグメントカラム  ）を定義させ、格納するページをユーザが指定できるようにした。これにより、利用者は関連して取り出したいレコードを物理的に集約して格納することが可能となり、取り出し時には上記カラムを条件に指定してアクセス範囲を絞り込むことで、データベースへのアクセスが大幅に削減される。
【００２８】
すなわち、本発明によれば、同一セグメントに関連レコードを集約して格納し、同一セグメント内のレコードのみをテーブル結合することで、Ｉ／Ｏアクセス回数を減らし、効率化と高速化が実現できる。
また、テーブル定義時の指定により、ユーザがテーブルに指定したカラムに加えて、仮想的なカラムとして、セグメント内の各テーブル毎の順序がシステムにより自動的に格納される順序カラム、および上位のテーブルのレコードの関連カラムを導入することにより、ユーザは、テーブル間の関連づけやレコードの取り出し順を意識する必要はなく、かつ、関連するレコードを取り出すためのテーブルの結合の負担が軽減され、設計工数を大幅に縮小できる。
【図面の簡単な説明】
【図１】本発明になる基本システム構成を示す図である。
【図２】本発明の実施の形態になるセグメント構成の概念図である。
【図３】本発明の実施の形態になる各テーブルにおける共通化カラムの定義例を示す図である。
【図４】本発明の実施の形態になるリレーショナルデータベースにおける階層型データの格納フローチャートである。
【図５】本発明の実施の形態になるセグメントを格納したデータベースの構造例を示す図である。
【図６】本発明の実施の形態になる格納テーブルの先頭へのレコード追加の例を示す図である。
【図７】本発明の実施の形態になる上位テーブルのレコードの順序カラムの変更例を示す図である。
【図８】ネットワーク型データベースの従来例を示す図である。
【図９】ネットワーク型データベースからリレーショナルデータベースへのマッピングの従来例を示す図である。
【符号の説明】
１  アプリケーションプログラム
２  データベースシステム
３  データベース
２１  共通化カラム付与手段
２２  セグメント化手段
２３    セグメント格納手段
２４  データ取り出し手段
３１  データテーブル
３２  セグメントデータ
【図１】
2004259075.tif 000003
【図２】
2004259075.tif 000004
【図３】
2004259075.tif 000005
【図４】
2004259075.tif 000006
【図５】
2004259075.tif 000007
【図６】
2004259075.tif 000008
【図７】
2004259075.tif 000009
【図８】
2004259075.tif 000010
【図９】
2004259075.tif 000011