JP4306281B2 - リレーショナルデータベースにおける階層型データのマッピングプログラム、装置、および方法 - Google Patents
リレーショナルデータベースにおける階層型データのマッピングプログラム、装置、および方法 Download PDFInfo
- Publication number
- JP4306281B2 JP4306281B2 JP2003050215A JP2003050215A JP4306281B2 JP 4306281 B2 JP4306281 B2 JP 4306281B2 JP 2003050215 A JP2003050215 A JP 2003050215A JP 2003050215 A JP2003050215 A JP 2003050215A JP 4306281 B2 JP4306281 B2 JP 4306281B2
- Authority
- JP
- Japan
- Prior art keywords
- segment
- column
- hierarchical data
- common column
- database
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク型データベースに格納されたデータをリレーショナルデータベースに格納してＳＱＬで操作する際に、ネットワーク型データベース向けのアプリケーションプログラムのレコード取り出し論理を適用可能としながらネットワーク型データベースと同様のトランザクションレスポンスを保証する技術分野に関する。
【０００２】
【従来の技術】
従来から日常的に使用されるデータベースに、代表的にネットワーク型データベース（ＮＤＢ：Network Database）やリレーショナルデータベース（ＲＤＢ：Relational Database ）がある。
ネットワーク型データベースは、図８の銀行取引における銀行口座レコードの例に示すように、親レコードの名義人１を頂点として、子レコードとしての口座種別１、２、孫レコードとしての取引履歴１〜５など、関連するレコードを下位に連結した三角形の階層構造をなしており、該階層構造を格納・取り出しの物理的な入出力単位として管理している。各レコードの階層関係を基にポインタを利用してレコード間を管理するため、検索のスピードが速く、レスポンスを重視する基幹業務の処理に適している。しかし、ネットワーク型データは、こうした階層データ構造と順序性を保持したクローズなデータベースであるがため、複雑であり、アクセスロジックもプログラムに大きく依存しており、システムの設計負担が大きい。
【０００３】
一方、リレーショナルデータベースでは、レコードは２次元のテーブル形式で表現され、親子関係はキーで管理される。そして、異なるテーブル間も各データに設けたキーによって関係付けられるため、目的に応じた柔軟な検索を可能としており、オープンなシステムに向いている。ハードの高性能化にともない、オープンシステムでのデータベースとして主流となっているが、取り出し対象のレコードを特定するための結合キーの処理に、ＣＰＵの処理時間が増大する欠点がある。
【０００４】
これに対し、従来、ネットワーク型データベースのもつ高速性を生かしつつ、そのデータをシンプルなリレーショナルデータベースへ移行させる技術の提案もなされている（例えば、特許文献１参照）。
このようなネットワーク型データベースのデータを従来のリレーショナルデータベースに移行する場合には、各階層のレコード毎に構造が異なるため、物理的にも論理的にも別々のテーブルにマッピングして格納している。
リレーショナルデータベースにおいて、ネットワーク型データベースのアプリケーションプログラムの資産( 論理) を継承するには、頂点のレコードを起点とした下位層のレコードの関係、およびその取り出し順序を考慮した設計が必要となる。
【０００５】
すなわち、ネットワーク型データベースで格納ロジックとして規定されていた各レコードの関連づけ( 図８のように、名義人レコードの下には、必ずその名義人が持つ口座レコードが連結されている）をリレーショナルデータベースで行うには、別々のテーブルのレコード同志を結合するための共通のカラムを定義して関連づけるように設計する必要がある。
【０００６】
図９の従来のマッピング例に示すように、取引履歴のようなレコードの場合、ユーザが取り出し順を制御( 例えば、最新の取引履歴から順に取り出す )できなければならない。名義人テーブルと口座テーブルを結合するカラムとして結合キー１が、口座テーブルと取引履歴テーブルを結合するカラムとして結合キー２が設定されている。このように、ネットワーク型データベースでは、格納時にレコードを連結することで実現されていたが、リレーショナルデータベースの場合には、取り出しの順番を規定するカラムを定義することによって、レコードの取り出し順を制御している。
【０００７】
【特許文献１】
特開２００１−３２５１３３号公報（第２〜６頁）
【０００８】
【発明が解決しようとする課題】
しかしながら、従来、ネットワーク型データベースの階層型データをリレーショナルデータベースにマッピングした場合、
１）ネットワーク型データベースでは1 つの入出力単位であったのものが物理的に分断されるため、データ取り出し時の記憶装置へのアクセスが頻発する、
２）ネットワーク型データベースで格納ロジックにより規定されていたレコード間の関係や取り出し順を、テーブルのカラムとその値としてユーザが規定する必要があり、設計コストが高くなる、
３）別々のテーブルのレコード間の関係をカラム値として規定するのに、上位層のレコードに関連する下位層のレコードを取り出すテーブルの結合が必須となり、ネットワーク型データベースと比較して取り出し対象のレコードを特定するためのＣＰＵの処理時間が増大する、
等の問題をかかえていた。
【０００９】
つまり、ネットワーク型データベースの各階層のレコードをリレーショナルデータベースの別テーブルに分割して格納することになり、テーブル間の結合に伴う性能面での問題が残されていた。
そこで、これらの上記問題を解決するため、本発明では、同一セグメントに関連レコードを集約して格納し、同一セグメント内のレコードのみをテーブル結合することで、Ｉ／Ｏ（ Input／Output) のアクセス回数を減らし、効率化と高速化を実現するマッピング技術を提供する。
【００１０】
【課題を解決するための手段】
第一の発明は、リレーショナルデータベースシステムにおいてネットワークデータベースの階層型データをマッピングするマッピングプログラムであって、コンピュータに、前記ネットワークデータベースから取得した階層型データに対応して別々に格納された複数のテーブルから所望の関連レコードを取り出すための共通カラムを定義し、各レコードに付与する共通カラム付与ステップと、前記共通カラム付与ステップで付与した共通カラム値をキーとして前記関連レコードを抽出し同一のセグメントに集約するセグメント化ステップと、前記セグメント内のレコードのみをテーブル結合させ、前記セグメントをアクセス単位としてデータベースに格納するセグメント格納ステップと、を実行させる階層型データのマッピングプログラムに関する。
【００１１】
すなわち、第一の発明によれば、関連して取り出したい複数のテーブルに属するレコードを、物理的にまとめて一つのセグメント( 二次記憶へのアクセス単位 )に格納する。その場合、関連レコードをまとめて格納するセグメントを規定するために、各テーブルに共通のカラム( セグメントカラム )を定義させ、格納するページをユーザが指定可能としている。
【００１２】
これにより、ユーザは関連して取り出したいレコードを物理的に集約して格納することが可能となり、取り出し時には上記カラムを条件に指定してアクセス範囲を絞り込むことで、二次記憶へのアクセスが大幅に削減されることとなる。
第二の発明は、前記共通カラム付与ステップにおいて、複数のテーブルに共通に定義される前記共通カラムは、前記セグメントカラム、前記セグメント内の各テーブル毎の取り出し順序を指定する順序カラム、および構造型データに対応する上位のテーブルのレコードを関連付ける関連カラムであることを特徴とする上記第一の発明に記載の階層型データのマッピングプログラムに関する。
【００１３】
すなわち、第二の発明によれば、テーブル定義時の指定により、ユーザがテーブルに指定したカラムに加えて、順序カラムおよび関連カラムの仮想カラムを追加する。順序カラムは、セグメント内の各テーブル毎の順序がシステムにより自動的に格納されるカラムであり、関連カラムは、関連づけられている上位のテーブルのレコードが持つ順序カラムの値を格納するカラムである。これらを付与することによって、ユーザはテーブル間の関連づけやレコードの取り出し順を意識したテーブル設計が不要となり、かつ、関連するレコードを取り出すためのテーブルの結合も同一セグメント内に限られ負荷が大きく削減される。
【００１４】
【発明の実施の形態】
以下、図面にもとづいて本発明の実施形態を説明する。
図１は、本発明の基本システム構成を示す。本発明のデータのマッピング方法を具現化するシステムは、ＳＱＬ（Structured Query Language ）をベースとしたアプリケーションプログラム１、データをマッピングする各手段を有するデータベースシステム２、およびデータベース３とで構成される。また、データベースシステム２におけるマッピングは、共通カラム付与手段２１、セグメント化手段２２、セグメント格納手段２３、およびデータ取り出し手段２４によって実行される。さらに、データベース３は、ネットワークデータベースからの階層型データを取得して格納したデータテーブル３１、およびセグメントデータ３２を備える。
【００１５】
ここで、データベースシステム２は、コンピュータであり、予め内蔵されたプログラムがコンピュータ上で実行され、共通カラム付与手段２１、セグメント化手段２２、セグメント格納手段２３、およびデータ取り出し手段２４の各手段が実現される。そして、当該プログラムは、フロッピーディスク、コンパクトディスク、ＣＤ−ＲＯＭ等のコンピュータ読取可能な記録媒体に記録され、図には示していないが、内蔵あるいは、外部接続された媒体読取装置にセットしインストールすることによって実行可能な状態としてもよい。
【００１６】
図２は、本発明の実施の形態になるセグメント構成の概念図である。格納された複数のテーブル１、２・・・ｎに渡って、例えば、名義人氏名等のような共通のカラムを定義し、定義した共通のカラムを有する取り出したい関連のレコードを集めて、セグメント１、２・・・ｎを形成し、該セグメント単位でデータベース３に格納する。
【００１７】
このように定義された共通のカラムを有する複数のレコードを集めて、セグメント単位でデータベース３に格納することによってマッピングする方法は、別々のテーブルに分散して格納し、結合キーによって複数のレコードを関係付ける従来の方法に比べ、ネットワーク型データベースの効率性を保ちつつ、リレーショナルデータベースにおいて、簡便なアプリケーションプログラムによるアクセスを可能とする。
【００１８】
図３は、本発明の実施の形態になる各テーブルにおける共通カラムの定義例を示す。名義人テーブル１１、口座テーブル１２、および取引履歴テーブル１３の各テーブルに対し、共通に、セグメントカラム、順序カラム、および関連カラムを設ける。
また、テーブル定義時の指定により、セグメントカラムに加えて、セグメント内の各テーブル毎の順序がシステムにより自動的に格納される順序カラム、および上位のテーブルのレコードが持つ前記順序カラムの値を格納する関連カラムが付与される。
【００１９】
これにより、テーブル間の関連づけやレコードの取り出し順を意識しなくて済み、また、関連するレコードを取り出すためのテーブル結合による負荷も軽減され、ユーザとって、システムの設計が大変簡便化される。
図４は、本発明の実施の形態になるリレーショナルデータベースにおける階層型データの格納フローチャートを示す。まず、格納されたネットワーク型の階層型データに対応した複数のテーブルにおける各レコードに共通のカラムを定義し付与する（ステップＳ１０１）。つぎに、この共通カラムの値をキーとして、複数のテーブルから関連のレコードを抽出して一つのセグメントとする (ステップＳ１０２）。さらに、抽出した複数のレコードを集めたセグメントをアクセス単位としてデータベース３に格納する（ステップＳ１０３）。
【００２０】
以上、セグメントを一つの単位としてアクセスさせることによって、リレーショナルデータベースにおいて、高速、かつ、簡単に階層型データが扱えるデータベースシステムが実現される。
図５は、本発明の実施の形態になるセグメントを格納したデータベースの構造例を示す。ネットワーク型データベースの階層型データは、セグメント単位でデータベース３に格納され、図３の定義に基づき、１つのセグメントとして、名義人レコード、口座レコード、および取引履歴レコードが、それぞれ、セグメントカラム、レコードの順序カラム、および上位レコードとの関連カラムを有する構造となっている。
【００２１】
図５を用いて、さらに、具体的に説明すると、”富士通夫”で定義されたセグメント２に関する複数のレコードが集められ、まず、名義人レコードでは、セグメントカラムは２、順序カラムは１、関連カラムはブランクで表現される。つぎの口座レコードでは、セグメントカラムは２、順序カラムは、普通預金、定期預金の取引発生順に、自動的にそれぞれ１、２が記入され、関連カラムは、その上位の名義人レコードが１つであるので、その順序カラムの番号がそのまま挿入される。取引履歴レコードでは、同様に、順序カラムは、取引発生順に番号が自動的に記入され、関連カラムは、上位の順序カラムが転記される。
【００２２】
上記のようにデータベース３に格納した図５に示すデータは、ＳＱＬによって以下のように取り出すことができる。
以下の例は、“富士通夫”である名義人データを取り出す場合を示す。
SELECT * FROM 名義人 TABLE WHERE セグメント = 2
また、氏名が“富士通夫”の取引額を“普通預金に限定して”、“取引年月日の降順に”取り出す場合、以下のように問い合わせる。
【００２３】
SELECT 取引履歴. 取引額
FROM 取引履歴 TABLE
WHERE 取引履歴 TABLE.セグメント = 2
AND 取引履歴 TABLE. 関連 =(SELECT 口座 TABLE. 順序 FROM 口座 TABLE
WHERE 口座 TABLE. セグメント = 2
AND 口座 TABLE. 口座種別 =普通預金 )
ORDER BY 取引履歴 TABLE. 取引年月日 DESC; ←降順の取り出し
上記の問い合わせは、テーブルを結合しているにもかかわらず物理的には全てセグメント２の中で完結している。また、ユーザは順序カラムや関連カラムの“値”を意識することなく、単純に条件に指定することで問い合わせ結果を得ることができる。
【００２４】
さらに、“富士通夫”の“普通預金の口座”の取引履歴を“履歴の先頭に”追加する場合には以下のようになる。
上記の場合、図６に示すように、セグメント2 の各取引履歴レコードは、自動的に変更される。図６は、本発明の実施の形態になる格納テーブルの先頭へのレコードの追加例を示している。
【００２５】
特徴的なことは、順序カラムにFIRST を指定して追加したことで、セグメント２内の取引履歴レコードの順序カラムが全体的に変更されている点である。これは、システムにより自動的にメンテナンスされる仮想的なカラムとしたことによるものであり、同様のカラムを実体としてユーザが定義した場合には、他のレコードの同カラムの値が全てメンテナンスされることになる。
【００２６】
図７は、本発明の実施の形態になる上位のレコードの順序カラムの変更例を示す。関連カラムについても、ユーザは関連づけたい上位の普通預金レコードの順序カラムの値を指定するだけで“値”をとくに意識する必要はない。これは、たとえば“富士通夫”が“当座預金”口座を新規に開設し、口座レコードの先頭( 順序カラム = 1 )にレコードが追加された場合でも、自動的にメンテナンスされるためである。
【００２７】
【発明の効果】
以上、ネットワークデータベースの階層構造のデータをリレーショナルデータベースにマッピングさせるプログラム、方法、および装置において、関連して取り出したい複数のテーブルに属するレコードを、物理的にまとめて一つのセグメント( データベースへのアクセス単位 )に格納し、関連レコードをまとめて格納するセグメントを規定するために、各テーブルに共通のカラム( セグメントカラム )を定義させ、格納するページをユーザが指定できるようにした。これにより、利用者は関連して取り出したいレコードを物理的に集約して格納することが可能となり、取り出し時には上記カラムを条件に指定してアクセス範囲を絞り込むことで、データベースへのアクセスが大幅に削減される。
【００２８】
すなわち、本発明によれば、同一セグメントに関連レコードを集約して格納し、同一セグメント内のレコードのみをテーブル結合することで、Ｉ／Ｏアクセス回数を減らし、効率化と高速化が実現できる。
また、テーブル定義時の指定により、ユーザがテーブルに指定したカラムに加えて、仮想的なカラムとして、セグメント内の各テーブル毎の順序がシステムにより自動的に格納される順序カラム、および上位のテーブルのレコードの関連カラムを導入することにより、ユーザは、テーブル間の関連づけやレコードの取り出し順を意識する必要はなく、かつ、関連するレコードを取り出すためのテーブルの結合の負担が軽減され、設計工数を大幅に縮小できる。
【図面の簡単な説明】
【図１】本発明になる基本システム構成を示す図である。
【図２】本発明の実施の形態になるセグメント構成の概念図である。
【図３】本発明の実施の形態になる各テーブルにおける共通化カラムの定義例を示す図である。
【図４】本発明の実施の形態になるリレーショナルデータベースにおける階層型データの格納フローチャートである。
【図５】本発明の実施の形態になるセグメントを格納したデータベースの構造例を示す図である。
【図６】本発明の実施の形態になる格納テーブルの先頭へのレコード追加の例を示す図である。
【図７】本発明の実施の形態になる上位テーブルのレコードの順序カラムの変更例を示す図である。
【図８】ネットワーク型データベースの従来例を示す図である。
【図９】ネットワーク型データベースからリレーショナルデータベースへのマッピングの従来例を示す図である。
【符号の説明】
１ アプリケーションプログラム
２ データベースシステム
３ データベース
２１ 共通化カラム付与手段
２２ セグメント化手段
２３ セグメント格納手段
２４ データ取り出し手段
３１ データテーブル
３２ セグメントデータ
【発明の属する技術分野】
本発明は、ネットワーク型データベースに格納されたデータをリレーショナルデータベースに格納してＳＱＬで操作する際に、ネットワーク型データベース向けのアプリケーションプログラムのレコード取り出し論理を適用可能としながらネットワーク型データベースと同様のトランザクションレスポンスを保証する技術分野に関する。
【０００２】
【従来の技術】
従来から日常的に使用されるデータベースに、代表的にネットワーク型データベース（ＮＤＢ：Network Database）やリレーショナルデータベース（ＲＤＢ：Relational Database ）がある。
ネットワーク型データベースは、図８の銀行取引における銀行口座レコードの例に示すように、親レコードの名義人１を頂点として、子レコードとしての口座種別１、２、孫レコードとしての取引履歴１〜５など、関連するレコードを下位に連結した三角形の階層構造をなしており、該階層構造を格納・取り出しの物理的な入出力単位として管理している。各レコードの階層関係を基にポインタを利用してレコード間を管理するため、検索のスピードが速く、レスポンスを重視する基幹業務の処理に適している。しかし、ネットワーク型データは、こうした階層データ構造と順序性を保持したクローズなデータベースであるがため、複雑であり、アクセスロジックもプログラムに大きく依存しており、システムの設計負担が大きい。
【０００３】
一方、リレーショナルデータベースでは、レコードは２次元のテーブル形式で表現され、親子関係はキーで管理される。そして、異なるテーブル間も各データに設けたキーによって関係付けられるため、目的に応じた柔軟な検索を可能としており、オープンなシステムに向いている。ハードの高性能化にともない、オープンシステムでのデータベースとして主流となっているが、取り出し対象のレコードを特定するための結合キーの処理に、ＣＰＵの処理時間が増大する欠点がある。
【０００４】
これに対し、従来、ネットワーク型データベースのもつ高速性を生かしつつ、そのデータをシンプルなリレーショナルデータベースへ移行させる技術の提案もなされている（例えば、特許文献１参照）。
このようなネットワーク型データベースのデータを従来のリレーショナルデータベースに移行する場合には、各階層のレコード毎に構造が異なるため、物理的にも論理的にも別々のテーブルにマッピングして格納している。
リレーショナルデータベースにおいて、ネットワーク型データベースのアプリケーションプログラムの資産( 論理) を継承するには、頂点のレコードを起点とした下位層のレコードの関係、およびその取り出し順序を考慮した設計が必要となる。
【０００５】
すなわち、ネットワーク型データベースで格納ロジックとして規定されていた各レコードの関連づけ( 図８のように、名義人レコードの下には、必ずその名義人が持つ口座レコードが連結されている）をリレーショナルデータベースで行うには、別々のテーブルのレコード同志を結合するための共通のカラムを定義して関連づけるように設計する必要がある。
【０００６】
図９の従来のマッピング例に示すように、取引履歴のようなレコードの場合、ユーザが取り出し順を制御( 例えば、最新の取引履歴から順に取り出す )できなければならない。名義人テーブルと口座テーブルを結合するカラムとして結合キー１が、口座テーブルと取引履歴テーブルを結合するカラムとして結合キー２が設定されている。このように、ネットワーク型データベースでは、格納時にレコードを連結することで実現されていたが、リレーショナルデータベースの場合には、取り出しの順番を規定するカラムを定義することによって、レコードの取り出し順を制御している。
【０００７】
【特許文献１】
特開２００１−３２５１３３号公報（第２〜６頁）
【０００８】
【発明が解決しようとする課題】
しかしながら、従来、ネットワーク型データベースの階層型データをリレーショナルデータベースにマッピングした場合、
１）ネットワーク型データベースでは1 つの入出力単位であったのものが物理的に分断されるため、データ取り出し時の記憶装置へのアクセスが頻発する、
２）ネットワーク型データベースで格納ロジックにより規定されていたレコード間の関係や取り出し順を、テーブルのカラムとその値としてユーザが規定する必要があり、設計コストが高くなる、
３）別々のテーブルのレコード間の関係をカラム値として規定するのに、上位層のレコードに関連する下位層のレコードを取り出すテーブルの結合が必須となり、ネットワーク型データベースと比較して取り出し対象のレコードを特定するためのＣＰＵの処理時間が増大する、
等の問題をかかえていた。
【０００９】
つまり、ネットワーク型データベースの各階層のレコードをリレーショナルデータベースの別テーブルに分割して格納することになり、テーブル間の結合に伴う性能面での問題が残されていた。
そこで、これらの上記問題を解決するため、本発明では、同一セグメントに関連レコードを集約して格納し、同一セグメント内のレコードのみをテーブル結合することで、Ｉ／Ｏ（ Input／Output) のアクセス回数を減らし、効率化と高速化を実現するマッピング技術を提供する。
【００１０】
【課題を解決するための手段】
第一の発明は、リレーショナルデータベースシステムにおいてネットワークデータベースの階層型データをマッピングするマッピングプログラムであって、コンピュータに、前記ネットワークデータベースから取得した階層型データに対応して別々に格納された複数のテーブルから所望の関連レコードを取り出すための共通カラムを定義し、各レコードに付与する共通カラム付与ステップと、前記共通カラム付与ステップで付与した共通カラム値をキーとして前記関連レコードを抽出し同一のセグメントに集約するセグメント化ステップと、前記セグメント内のレコードのみをテーブル結合させ、前記セグメントをアクセス単位としてデータベースに格納するセグメント格納ステップと、を実行させる階層型データのマッピングプログラムに関する。
【００１１】
すなわち、第一の発明によれば、関連して取り出したい複数のテーブルに属するレコードを、物理的にまとめて一つのセグメント( 二次記憶へのアクセス単位 )に格納する。その場合、関連レコードをまとめて格納するセグメントを規定するために、各テーブルに共通のカラム( セグメントカラム )を定義させ、格納するページをユーザが指定可能としている。
【００１２】
これにより、ユーザは関連して取り出したいレコードを物理的に集約して格納することが可能となり、取り出し時には上記カラムを条件に指定してアクセス範囲を絞り込むことで、二次記憶へのアクセスが大幅に削減されることとなる。
第二の発明は、前記共通カラム付与ステップにおいて、複数のテーブルに共通に定義される前記共通カラムは、前記セグメントカラム、前記セグメント内の各テーブル毎の取り出し順序を指定する順序カラム、および構造型データに対応する上位のテーブルのレコードを関連付ける関連カラムであることを特徴とする上記第一の発明に記載の階層型データのマッピングプログラムに関する。
【００１３】
すなわち、第二の発明によれば、テーブル定義時の指定により、ユーザがテーブルに指定したカラムに加えて、順序カラムおよび関連カラムの仮想カラムを追加する。順序カラムは、セグメント内の各テーブル毎の順序がシステムにより自動的に格納されるカラムであり、関連カラムは、関連づけられている上位のテーブルのレコードが持つ順序カラムの値を格納するカラムである。これらを付与することによって、ユーザはテーブル間の関連づけやレコードの取り出し順を意識したテーブル設計が不要となり、かつ、関連するレコードを取り出すためのテーブルの結合も同一セグメント内に限られ負荷が大きく削減される。
【００１４】
【発明の実施の形態】
以下、図面にもとづいて本発明の実施形態を説明する。
図１は、本発明の基本システム構成を示す。本発明のデータのマッピング方法を具現化するシステムは、ＳＱＬ（Structured Query Language ）をベースとしたアプリケーションプログラム１、データをマッピングする各手段を有するデータベースシステム２、およびデータベース３とで構成される。また、データベースシステム２におけるマッピングは、共通カラム付与手段２１、セグメント化手段２２、セグメント格納手段２３、およびデータ取り出し手段２４によって実行される。さらに、データベース３は、ネットワークデータベースからの階層型データを取得して格納したデータテーブル３１、およびセグメントデータ３２を備える。
【００１５】
ここで、データベースシステム２は、コンピュータであり、予め内蔵されたプログラムがコンピュータ上で実行され、共通カラム付与手段２１、セグメント化手段２２、セグメント格納手段２３、およびデータ取り出し手段２４の各手段が実現される。そして、当該プログラムは、フロッピーディスク、コンパクトディスク、ＣＤ−ＲＯＭ等のコンピュータ読取可能な記録媒体に記録され、図には示していないが、内蔵あるいは、外部接続された媒体読取装置にセットしインストールすることによって実行可能な状態としてもよい。
【００１６】
図２は、本発明の実施の形態になるセグメント構成の概念図である。格納された複数のテーブル１、２・・・ｎに渡って、例えば、名義人氏名等のような共通のカラムを定義し、定義した共通のカラムを有する取り出したい関連のレコードを集めて、セグメント１、２・・・ｎを形成し、該セグメント単位でデータベース３に格納する。
【００１７】
このように定義された共通のカラムを有する複数のレコードを集めて、セグメント単位でデータベース３に格納することによってマッピングする方法は、別々のテーブルに分散して格納し、結合キーによって複数のレコードを関係付ける従来の方法に比べ、ネットワーク型データベースの効率性を保ちつつ、リレーショナルデータベースにおいて、簡便なアプリケーションプログラムによるアクセスを可能とする。
【００１８】
図３は、本発明の実施の形態になる各テーブルにおける共通カラムの定義例を示す。名義人テーブル１１、口座テーブル１２、および取引履歴テーブル１３の各テーブルに対し、共通に、セグメントカラム、順序カラム、および関連カラムを設ける。
また、テーブル定義時の指定により、セグメントカラムに加えて、セグメント内の各テーブル毎の順序がシステムにより自動的に格納される順序カラム、および上位のテーブルのレコードが持つ前記順序カラムの値を格納する関連カラムが付与される。
【００１９】
これにより、テーブル間の関連づけやレコードの取り出し順を意識しなくて済み、また、関連するレコードを取り出すためのテーブル結合による負荷も軽減され、ユーザとって、システムの設計が大変簡便化される。
図４は、本発明の実施の形態になるリレーショナルデータベースにおける階層型データの格納フローチャートを示す。まず、格納されたネットワーク型の階層型データに対応した複数のテーブルにおける各レコードに共通のカラムを定義し付与する（ステップＳ１０１）。つぎに、この共通カラムの値をキーとして、複数のテーブルから関連のレコードを抽出して一つのセグメントとする (ステップＳ１０２）。さらに、抽出した複数のレコードを集めたセグメントをアクセス単位としてデータベース３に格納する（ステップＳ１０３）。
【００２０】
以上、セグメントを一つの単位としてアクセスさせることによって、リレーショナルデータベースにおいて、高速、かつ、簡単に階層型データが扱えるデータベースシステムが実現される。
図５は、本発明の実施の形態になるセグメントを格納したデータベースの構造例を示す。ネットワーク型データベースの階層型データは、セグメント単位でデータベース３に格納され、図３の定義に基づき、１つのセグメントとして、名義人レコード、口座レコード、および取引履歴レコードが、それぞれ、セグメントカラム、レコードの順序カラム、および上位レコードとの関連カラムを有する構造となっている。
【００２１】
図５を用いて、さらに、具体的に説明すると、”富士通夫”で定義されたセグメント２に関する複数のレコードが集められ、まず、名義人レコードでは、セグメントカラムは２、順序カラムは１、関連カラムはブランクで表現される。つぎの口座レコードでは、セグメントカラムは２、順序カラムは、普通預金、定期預金の取引発生順に、自動的にそれぞれ１、２が記入され、関連カラムは、その上位の名義人レコードが１つであるので、その順序カラムの番号がそのまま挿入される。取引履歴レコードでは、同様に、順序カラムは、取引発生順に番号が自動的に記入され、関連カラムは、上位の順序カラムが転記される。
【００２２】
上記のようにデータベース３に格納した図５に示すデータは、ＳＱＬによって以下のように取り出すことができる。
以下の例は、“富士通夫”である名義人データを取り出す場合を示す。
SELECT * FROM 名義人 TABLE WHERE セグメント = 2
また、氏名が“富士通夫”の取引額を“普通預金に限定して”、“取引年月日の降順に”取り出す場合、以下のように問い合わせる。
【００２３】
SELECT 取引履歴. 取引額
FROM 取引履歴 TABLE
WHERE 取引履歴 TABLE.セグメント = 2
AND 取引履歴 TABLE. 関連 =(SELECT 口座 TABLE. 順序 FROM 口座 TABLE
WHERE 口座 TABLE. セグメント = 2
AND 口座 TABLE. 口座種別 =普通預金 )
ORDER BY 取引履歴 TABLE. 取引年月日 DESC; ←降順の取り出し
上記の問い合わせは、テーブルを結合しているにもかかわらず物理的には全てセグメント２の中で完結している。また、ユーザは順序カラムや関連カラムの“値”を意識することなく、単純に条件に指定することで問い合わせ結果を得ることができる。
【００２４】
さらに、“富士通夫”の“普通預金の口座”の取引履歴を“履歴の先頭に”追加する場合には以下のようになる。
【００２５】
特徴的なことは、順序カラムにFIRST を指定して追加したことで、セグメント２内の取引履歴レコードの順序カラムが全体的に変更されている点である。これは、システムにより自動的にメンテナンスされる仮想的なカラムとしたことによるものであり、同様のカラムを実体としてユーザが定義した場合には、他のレコードの同カラムの値が全てメンテナンスされることになる。
【００２６】
図７は、本発明の実施の形態になる上位のレコードの順序カラムの変更例を示す。関連カラムについても、ユーザは関連づけたい上位の普通預金レコードの順序カラムの値を指定するだけで“値”をとくに意識する必要はない。これは、たとえば“富士通夫”が“当座預金”口座を新規に開設し、口座レコードの先頭( 順序カラム = 1 )にレコードが追加された場合でも、自動的にメンテナンスされるためである。
【００２７】
【発明の効果】
以上、ネットワークデータベースの階層構造のデータをリレーショナルデータベースにマッピングさせるプログラム、方法、および装置において、関連して取り出したい複数のテーブルに属するレコードを、物理的にまとめて一つのセグメント( データベースへのアクセス単位 )に格納し、関連レコードをまとめて格納するセグメントを規定するために、各テーブルに共通のカラム( セグメントカラム )を定義させ、格納するページをユーザが指定できるようにした。これにより、利用者は関連して取り出したいレコードを物理的に集約して格納することが可能となり、取り出し時には上記カラムを条件に指定してアクセス範囲を絞り込むことで、データベースへのアクセスが大幅に削減される。
【００２８】
すなわち、本発明によれば、同一セグメントに関連レコードを集約して格納し、同一セグメント内のレコードのみをテーブル結合することで、Ｉ／Ｏアクセス回数を減らし、効率化と高速化が実現できる。
また、テーブル定義時の指定により、ユーザがテーブルに指定したカラムに加えて、仮想的なカラムとして、セグメント内の各テーブル毎の順序がシステムにより自動的に格納される順序カラム、および上位のテーブルのレコードの関連カラムを導入することにより、ユーザは、テーブル間の関連づけやレコードの取り出し順を意識する必要はなく、かつ、関連するレコードを取り出すためのテーブルの結合の負担が軽減され、設計工数を大幅に縮小できる。
【図面の簡単な説明】
【図１】本発明になる基本システム構成を示す図である。
【図２】本発明の実施の形態になるセグメント構成の概念図である。
【図３】本発明の実施の形態になる各テーブルにおける共通化カラムの定義例を示す図である。
【図４】本発明の実施の形態になるリレーショナルデータベースにおける階層型データの格納フローチャートである。
【図５】本発明の実施の形態になるセグメントを格納したデータベースの構造例を示す図である。
【図６】本発明の実施の形態になる格納テーブルの先頭へのレコード追加の例を示す図である。
【図７】本発明の実施の形態になる上位テーブルのレコードの順序カラムの変更例を示す図である。
【図８】ネットワーク型データベースの従来例を示す図である。
【図９】ネットワーク型データベースからリレーショナルデータベースへのマッピングの従来例を示す図である。
【符号の説明】
１ アプリケーションプログラム
２ データベースシステム
３ データベース
２１ 共通化カラム付与手段
２２ セグメント化手段
２３ セグメント格納手段
２４ データ取り出し手段
３１ データテーブル
３２ セグメントデータ
Claims (5)
- リレーショナルデータベースシステムにおいてネットワークデータベースの階層型データをマッピングするマッピングプログラムであって、
コンピュータに、
前記ネットワークデータベースから取得した階層型データに対応して別々に格納された複数のテーブルから所望の関連レコードを取り出すための共通カラムを定義し、各レコードに付与する共通カラム付与ステップと、
前記共通カラム付与ステップで付与した共通カラム値をキーとして前記関連レコードを抽出し同一のセグメントに集約するセグメント化ステップと、
前記セグメント内のレコードのみをテーブル結合させ、前記セグメントをアクセス単位としてデータベースに格納するセグメント格納ステップと、
を実行させる階層型データのマッピングプログラム。 - 前記共通カラム付与ステップにおいて、複数のテーブルに共通に定義される前記共通カラムは、前記セグメントカラム、前記セグメント内の各テーブル毎の取り出し順序を指定する順序カラム、および構造型データに対応する上位のテーブルのレコードを関連付ける関連カラムであることを特徴とする請求項１記載の階層型データのマッピングプログラム。
- リレーショナルデータベースシステムにおいてネットワークデータベースの階層型データをマッピングするマッピング装置であって、
前記ネットワークデータベースから取得した階層型データに対応して別々に格納された複数のテーブルから所望の関連レコードを取り出すための共通カラムを定義し、各レコードに付与する共通カラム付与手段と、
前記共通カラム付与手段で付与した共通カラム値をキーとして前記関連レコードを抽出し同一のセグメントに集約するセグメント化手段と、
前記セグメント内のレコードのみをテーブル結合させ、前記セグメントをアクセス単位としてデータベースに格納するセグメント格納手段と、
を実行させる階層型データのマッピング装置。 - リレーショナルデータベースシステムにおいてネットワークデータベースの階層型データをマッピングするマッピング方法であって、
前記ネットワークデータベースから取得した階層型データに対応して別々に格納された複数のテーブルから所望の関連レコードを取り出すための共通カラムを定義し、各レコードに付与する共通カラム付与ステップと、
前記共通カラム付与ステップで付与した共通カラム値をキーとして前記関連レコードを抽出し同一のセグメントに集約するセグメント化ステップと、
前記セグメント内のレコードのみをテーブル結合させ、前記セグメントをアクセス単位としてデータベースに格納するセグメント格納ステップと、
を有することを特徴とする階層型データのマッピング方法。 - リレーショナルデータベースシステムにおいてネットワークデータベースの階層型データをマッピングするマッピングプログラムを記録した記録媒体であって、
コンピュータに、
前記ネットワークデータベースから取得した階層型データに対応して別々に格納された複数のテーブルから所望の関連レコードを取り出すための共通カラムを定義し、各レコードに付与する共通カラム付与ステップと、
前記共通カラム付与ステップで付与した共通カラム値をキーとして前記関連レコードを抽出し同一のセグメントに集約するセグメント化ステップと、
前記セグメント内のレコードのみをテーブル結合させ、前記セグメントをアクセス単位としてデータベースに格納するセグメント格納ステップと、
を実行させる階層型データのマッピングプログラムを記録したコンピュータ読取可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003050215A JP4306281B2 (ja) | 2003-02-27 | 2003-02-27 | リレーショナルデータベースにおける階層型データのマッピングプログラム、装置、および方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003050215A JP4306281B2 (ja) | 2003-02-27 | 2003-02-27 | リレーショナルデータベースにおける階層型データのマッピングプログラム、装置、および方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004259075A JP2004259075A (ja) | 2004-09-16 |
| JP4306281B2 true JP4306281B2 (ja) | 2009-07-29 |
Family
ID=33115687
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003050215A Expired - Fee Related JP4306281B2 (ja) | 2003-02-27 | 2003-02-27 | リレーショナルデータベースにおける階層型データのマッピングプログラム、装置、および方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4306281B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4681338B2 (ja) * | 2005-04-13 | 2011-05-11 | 株式会社日立ソリューションズ | データベース移行方法 |
| JP6287506B2 (ja) * | 2014-04-04 | 2018-03-07 | 富士通株式会社 | データベースアクセス制御プログラム、データベースアクセス制御方法、及び情報処理装置 |
| CN109657015B (zh) * | 2018-12-25 | 2023-05-02 | 四川效率源信息安全技术股份有限公司 | 一种基于oracle行迁移和行连接的数据提取方法 |
-
2003
- 2003-02-27 JP JP2003050215A patent/JP4306281B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004259075A (ja) | 2004-09-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7689574B2 (en) | Index and method for extending and querying index | |
| US8886617B2 (en) | Query-based searching using a virtual table | |
| US5682524A (en) | Databank system with methods for efficiently storing non-uniform data records | |
| US6122644A (en) | System for halloween protection in a database system | |
| EP1176523A2 (en) | System for providing extended file attributes | |
| US9477729B2 (en) | Domain based keyword search | |
| JP2002501256A (ja) | データベース装置 | |
| WO2018097846A1 (en) | Edge store designs for graph databases | |
| AU2014201593A1 (en) | Shared cache used to provide zero copy memory mapped database | |
| MX2010012866A (es) | Compaginacion de datos jerarquicos. | |
| CN102955792A (zh) | 一种实时全文搜索引擎事务处理的实现方法 | |
| JP5075653B2 (ja) | データベース管理方法、データベース管理装置、データベース管理プログラム、及び、データベースシステム | |
| EP1091295B1 (en) | Data management system using a plurality of data operation modules | |
| CN112612845A (zh) | 一种组织机构视图实现方法、装置、电子设备及可读存储介质 | |
| WO2023179787A1 (zh) | 分布式文件系统的元数据管理方法和装置 | |
| CN113934713A (zh) | 一种订单数据索引方法、系统、计算机设备以及存储介质 | |
| JP4306281B2 (ja) | リレーショナルデータベースにおける階層型データのマッピングプログラム、装置、および方法 | |
| JPH0358249A (ja) | フアイルのアクセス方法 | |
| JP2014130492A (ja) | インデックスの生成方法及び計算機システム | |
| Torp et al. | Modification semantics in now-relative databases | |
| JP3653333B2 (ja) | データベース管理方法およびシステム | |
| US11151168B2 (en) | Hierarchical search folders for a document repository | |
| JP3552318B2 (ja) | 文書検索方法およびシステム | |
| US20100205197A1 (en) | Two-valued logic database management system with support for missing information | |
| WO2013069149A1 (ja) | データ検索装置、データの検索方法及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20040610 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20040610 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060215 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20081222 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090106 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090304 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090414 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090427 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120515 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |