JP2015200978A - データベースアクセス制御プログラム、データベースアクセス制御方法、及び情報処理装置 - Google Patents

Abstract

【課題】ＮＤＢに対するＳＱＬによるデータ操作の自由度を向上させるデータベースアクセス制御技術を提供する。【解決手段】レコード型間で親子関係が形成されたデータ構造を有するＮＤＢにおける、データ操作対象となる複数のレコード型に対する、第１データ操作言語による第１操作情報を取得し、レコード型に含まれる項目情報と、レコード型の親のレコード型のレコードである親レコードを特定する親特定情報と、親レコードに属する子レコードの順序を示す子順序情報とが定義された関係定義情報を用いて、複数のレコード型間の関係を解析し、解析した関係と第１操作情報とに基づいて、ＮＤＢに対する第２データ操作言語による第２操作情報を生成し、生成した第２操作情報をＮＤＢへ出力することにより、上記課題の解決を図る。【選択図】図４

Description

本発明は、データベースへのアクセス制御に関する。

オープン技術の発展に伴い、ネットワーク型データベース（ＮＤＢ）技術者が減少している。このような背景の下、オープン技術を用いてメインフレームのＮＤＢの既存資産（ＮＤＢ資源）の保守及び運用を実現する手法がいくつか考案されている。

しかし、これらの手法のいずれも、ＮＤＢの特徴であるレコードの順序を意識した操作をできないか、もしくは厳しい条件付きで一部の機能しか実現できていない。ＮＤＢのメリットを生かせながらオープンインタフェースであるＳＱＬを使った、より汎用的かつ実用的なアクセス手法が求められている。

例えば、第１の技術として、階層ネットワーク型データベースシステムをリレーショナル型データベースとみなし、検索・更新する技術がある（例えば、特許文献１）。第１の技術では、検索、更新、追加、削除等の条件の指示をなす入力問合せ文を解析手段により解析する。この解析結果から第１の出力として得られかつ当該条件に関与する個々のフィールドを有する夫々のレコードに対して、レコード間の関連を示すレコード関連木を結合手段にて生成して記憶手段に記憶する。更に、上記解析結果から第２の出力として得られかつ当該条件を二項演算の集合に分解してこの二項演算を構成する演算子を節とする条件木を結合手段にて生成し、レコード関連木と条件木とから階層ネットワーク型データベースをアクセスするための条件と手順を示すアクセスブロック並びを生成手段により生成する。このブロック並びを実行手段により順次解釈しつつ実行する。

また、第２の技術として、ネットワーク型データベースシステムにＳＱＬ言語を用いた操作インターフェースを提供する際に、ＮＤＢでのレコードのリンク順序が持つ意味に対応したレコードの追加処理を可能にする技術がある（例えば、特許文献２）。

また、第３の技術として、ＮＤＢをＳＱＬでアクセスする場合、次の処理を行う技術がある（例えば、特許文献３）。第３の技術では、親レコードにデータベース内で一意となる検索キーが存在しなくても、親子となっているレコードから導出した表間ではＳＱＬ文で表の結合を指定することができ、更にその表結合の処理においてはセットを利用した高速なアクセスを可能にする。

また、第４の技術として、ネットワークデータベースとリレーショナルデータベースをアクセスするアプリケーション処理を一元的に管理する技術がある（例えば、特許文献３）。第４の技術では、データベースシステムは、データ部から成る各テーブルの各行に固有なポインタデータを持ち、データ表と順序関係表とを備える。データ表は、該ポインタデータをデータ部と共に記憶する。順序関係表は、ポインタデータをもとにネットワークデータベースに於ける階層関係とレコード間の順序関係を記憶する。データベースシステムは、ネットワークデータベースをアクセスするアプリケーション処理に於けるＤＭＬ命令を、ＳＱＬ命令組立手段によりＳＱＬ命令に組立て、順序関係表を介してデータ表にアクセスする。

特開平４−２９９４５９号公報 特開２００１−２７３１７８号公報 特開平６−２８２５７６号公報 特開２００１−３２５１３３号公報

しかしながら、第１〜第４の技術では、ＳＱＬによりデータ操作できるＮＤＢのデータ構造が限られている。したがって、ＮＤＢに対して、リレーショナルデータベースに対するＳＱＬによるデータ操作と同様に、レコード型の関係や項目数を意識せずに、ＳＱＬによりデータ操作することができない。

本発明は、一側面として、ＮＤＢに対するＳＱＬによるデータ操作の自由度を向上させるデータベースアクセス制御技術を提供する。

本発明の一側面にかかるデータベースアクセス制御プログラムは、コンピュータに次の処理を実行させる。すなわち、コンピュータは、レコード型間で親子関係が形成されたデータ構造を有するネットワーク型データベースにおける、データ操作対象となる複数のレコード型に対する、第１データ操作言語による第１操作情報を取得する。

コンピュータは、関係定義情報が格納された格納部から取得した関係定義情報を用いて、複数のレコード型間の関係を解析する。関係定義情報には、レコード型に含まれる項目情報と、レコード型の親のレコード型のレコードである親レコードを特定する親情報と、親レコードに属する子レコードの順序を示す順序情報とが、レコード型毎に定義されている。コンピュータは、解析した関係と第１操作情報とに基づいて、ネットワーク型データベースに対する第２データ操作言語による第２操作情報を生成する。コンピュータは、生成した前記第２データ操作情報を前記ネットワーク型データベースへ出力する。

本発明の一側面に係るデータベースアクセス制御技術によれば、ＮＤＢに対するＳＱＬによるデータ操作の自由度を向上させる。

第１の技術を適用して、ＳＱＬを用いて、ＮＤＢのレコードにアクセスする場合の問題点を説明するための図である。 ２つのレコードタイプ間の関係が「１：１」の関係にあるＮＤＢの場合について説明するための図である。 本実施形態に係る仮想表について説明するための図である。 本実施形態における情報処理装置の一例を示す。 本実施形態（実施例１）における情報処理装置のブロック図の一例である。 本実施形態（実施例１）におけるＳＱＬ−ＤＭＬ変換テーブルの一例を示す。 本実施形態（実施例１）における１つの親レコードタイプに対して子レコードタイプが複数存在する場合のＮＤＢのデータ構造を説明するための図である。 図７の各レコードタイプに対応する仮想表定義の一例を示す。 図８の仮想表定義に基づいてユーザ側から認識される仮想表の一例を示す。 本実施形態（実施例１）における仮想表に対するデータ操作を行うためのＳＱＬの一例を示す。 本実施形態（実施例１）におけるＳＱＬによるＮＤＢへの問合せ結果の一例を示す。 本実施形態（実施例１）における業務手順のフローチャートを示す。 本実施形態（実施例１）における仮想表定義生成処理（Ｓ４）の詳細フローチャートの一例を示す。 本実施形態（実施例１）におけるＮＤＢへの問合せ処理のフローチャートの一例を示す。 本実施形態（実施例１）におけるＳＱＬ−ＤＭＬ変換処理（Ｓ３３）のフローチャートの一例を示す。 本実施形態（実施例２）における、複数の親レコードタイプに対して複数の子レコードタイプが存在する場合のＮＤＢのデータ構造を説明するための図である。 本実施形態（実施例２）における仮想表定義生成処理（Ｓ４）の詳細フローチャートの一例を示す。 本実施形態（実施例２）における、親レコードタイプ：子レコードタイプ＝Ｎ：Ｎの関係の場合に生成される仮想表定義の一例を示す。 図１８の仮想表定義に基づいてユーザ側から認識される仮想表の一例を示す。 本実施形態（実施例２）における、仮想表に対するデータ操作を行うためのＳＱＬの一例を示す。 本実施形態（実施例２）におけるＳＱＬによるＮＤＢへの問合せ結果の一例を示す。 本実施形態の実施例１，２におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。

第１の技術では、ＮＤＢのレコードの必要な項目を抽出し、一つのリレーショナルデータベース（ＲＤＢ）のテーブルに見せかけて、ＳＱＬによる検索、更新、追加、削除を可能にする。

しかしながら、第１の技術では、ＳＱＬによるアクセスは、事前に決めた項目しかアクセスできない。例えば、図１（Ａ）に示すように、Ａレコードタイプのレコードには項目Ａ１、Ａ２、Ａ３があるとする。仮想的なテーブルイメージがＡ１、Ａ３、Ｂ１が抽出されて構成されている場合は、Ａ２をＳＱＬで操作することはできない。

また、第１の技術では、ＮＤＢにおいて、レコードタイプ間の関係が「１：１」の関係しか対応できない。したがって、図１（Ｂ）に示すように、第１の技術は、１つのレコードタイプに複数のレコードタイプが関係付けられている「１：Ｎ」（Ｎは、２以上の整数）の関係には対応できない。

また、第１の技術では、ＮＤＢの階層や項目数が多くなるほど、生成される論理レコードイメージのサイズが大きくなり、ＲＤＢの列数の制限によって生成できない場合がある。

第２の技術では、事前にキーを決めて、昇順か降順でソートすることで、ＮＤＢの順序を意識した操作をできるようにする。しかしながら、第２の技術の場合も、第１の技術と同様に、レコードタイプ間の関係が「１：１」しか対応できない。なお、ソートは生成された仮想表全体単位でしかできず、特定の親レコードに関して子レコードの順番を意識した操作ができない場合がある。

順番を意識して正しく業務処理を行うには、利用者がＮＤＢの構造を十分に理解し、適切な項目をキーに指定する必要がある。

例えば、図２（Ａ）に示すように、レコードタイプＡとレコードタイプＢを有し、２つのレコードタイプ間の関係が「１：１」の関係のデータ構造であるＮＤＢの場合について考える。レコードタイプＡには２つのレコードａ１，ａ２があり、レコードタイプＢにはｂ１、ｂ２、ｂ３、及びｂ４の四つのレコードがある。レコードタイプＡ，Ｂ間の親子関係は、図２（Ｂ）で示している。レコードタイプＡ，Ｂを組み合わせて、図２（Ｃ）に示す仮想表にある。Ｂタイプの項目ｂをキーに降順で指定すると、図２（Ｄ）のようにレコードがソートされて順序がつけられる。この順序は項目ではなく、レコードの並びの順番で示されている。

また、第２の技術は、複数の利用パターンに適さない場合がある。例えば図２（Ｄ）の場合、ｂ項目をキーに指定したことで、ｂの最大値を持つレコードを出力するなどの操作は容易になるが、ａ１の子レコードの２番目のレコードを更新するなどの操作はできなくなる。

第３の技術では、レコードタイプ１つにつき表１つが用いられ、表結合形式が採用されている。第３の技術では、それぞれのレコードタイプにキーかユニークとなる項目もしくは項目の組み合わせが必要となる。

しかしながら、ＮＤＢの場合、最上位のレコードにエントリーキーが存在するケースは多いけど、下層の子レコードにキーやユニークとなる項目が一般的に存在せず、利用できない。また、ユニークな項目の選定などで、ＮＤＢを熟知している設計者の介入が必要であり、設計者に負担がかかる。

第４の技術では、ＮＤＢのレコードタイプ毎に、データ表と順序関係表２つの表を生成し、その組み合わせで、ＮＤＢの順序を意識した操作を実現している。また、第４の技術では、順序関係表に親レコードのポインタデータ、次のデータレコードへのポインタと自分をポイントしているデータレコードへの逆ポインタを格納することで、ＮＤＢの順序を表現している。

しかしながら、第４の技術では、レコード間の関係が「１：１」の関係のデータ構造しか対応できない。第４の技術では、基本的に親レコードが決まっていると想定している。例えば、レコード間の関係が「ｎ：１」の関係のデータ構造型の場合、すなわち１つの子レコードに複数の親レコードが存在する場合、親レコードのポインタデータの項目にどの親レコードの値を入れるかは決められない。

また、第４の技術では、レコード番号指定時の性能が悪い。ＮＤＢはレコードの順番を指定する使い方がある。例えば、Ａレコードタイプの１００番目のレコードを取り出す場合、Ａレコードタイプの先頭レコードからポインタを９９回辿る必要があり、使い勝手がよくない。

上述のように、第１〜第４の技術では、以下の２つの問題点がある。
（１）ＮＤＢにおける親レコードタイプと子レコードタイプとの間の全ての型の関係には対応できない。

例えば、図１（Ｂ）に示すように、親レコードタイプと子レコードタイプとが「１：ｎ」型の場合、ＢレコードタイプはＡレコードタイプと関係がある（関連性がある）が、Ｃレコードタイプとは関連性がない。同様に、ＣレコードタイプはＡレコードタイプと関係がある（関連性がある）が、Ｂレコードタイプとは関連性がない。

このような「１：ｎ」型のレコードタイプを一つの表にまとめるのは容易ではない。ＢとＣのレコードタイプを全部掛け合わせることも考えられるが、冗長なデータを作り出すことになるので、ＲＤＢの仕様には合わない。

このように、第１〜第４の技術では、ＮＤＢにおける親レコードタイプと子レコードタイプとの間の全ての型には対応できない。

（２）レコードに順序を付けるにはＮＤＢのレコードに一意性を有するキーとなる項目が存在しないといけない。

例えば、キーとなる項目によりレコードをソートすることによって、レコードの順番で、元のＮＤＢの順序を表すことが考えられる。しかし、キーとなる項目（一意性）が存在しない場合、つまり、一意性が保証されない項目をソートする場合、ソートの論理によっては、同じ値の項目を持つレコードの順序が前後することがある。その場合、レコードの順序が元のＮＤＢの順序とは異なる可能性があるので、誤った情報を表示することなり、最悪の場合、ＤＢ破壊につながるおそれがある。

本実施形態では、レコードタイプ毎に仮想表定義を生成する。仮想表定義には、そのレコードタイプに含まれる全ての項目と、さらに親レコードを特定できる仮想ＪＯＩＮキーと、その親レコードの何番目の子レコードであるかを示す仮想順序キーとが含まれる。入力されたＳＱＬのテーブル名から、情報処理装置は、操作対象となる仮想表名（すなわち、レコードタイプ）を特定し、仮想ＪＯＩＮキーに基づいて、レコードタイプ間の親子関係を特定する。

さらに、情報処理装置は、仮想順序キーにより、ユーザ側から見える仮想的なリレーショナルデータベースと、情報処理装置側で実際に取り扱う物理的なＮＤＢとの間で子レコードの並びの整合がとられる仕組みになっている。

一方、ユーザ（例えば、設計者等）側において、ＮＤＢのデータ構造及びＮＤＢのインターフェースを意識せずに、ＲＤＢと同様に、ＲＤＢのインターフェースを用いてＮＤＢを利用することができる。これにより、設計者がＮＤＢを知らなくても、ＲＤＢについての知識があれば、業務アプリケーションの開発保守を容易にすることができる。

また、仮想ＪＯＩＮキーと仮想順序キーの組み合わせにより、ＮＤＢのレコードタイプ間の関係が表現される。そのため、子レコードにユニークとなる項目が存在しなくても、仮想ＪＯＩＮキーがあれば、レコードタイプ間の関連付けはできる。仮想表同士のＪＯＩＮ方式を採用することで、ユーザ側において、標準ＳＱＬを用いて、ＮＤＢの全データへアクセスすることができる。

例えば、図３（Ａ）に示すように、レコードタイプＡとレコードタイプＢを有し、２つのレコードタイプ間の関係が「１：１」のデータ構造を有するＮＤＢについて考える。図３（Ａ）及び図３（Ｂ）は、図２（Ａ）及び図２（Ｂ）と同様なので、その説明を省略する。本実施形態によれば、図３（Ａ）及び図３（Ｂ）のような関係にあるレコードタイプＡとＢそれぞれについて、図３（Ｃ）及び図３（Ｄ）に示す仮想表が論理的に存在する。ここで、仮想表が論理的に存在すると表現したのは、ユーザ側からは、レコードタイプＡとレコードタイプＢについて、あたかも仮想表Ａ，Ｂがあるように見えるが、情報処理装置内部では、実際には物理的には存在しないからである。

例えば、図３（Ｃ）において、ユーザがａ１レコードの２番目の子レコードを操作（ＵＰＤＡＴＥ）したい場合は、仮想ＪＯＩＮキーにａ１を指定し、仮想順序キーに２を指定する。これにより、標準ＳＱＬを用いてＮＤＢに対する操作を行うことができ、特許文献２を解決できる。

このように、本実施形態によれば、仮想ＪＯＩＮキーと仮想順序キーによるＪＯＩＮ方式を採用することにより、ＮＤＢに対するユーザ側のインターフェースとしてリレーショナルデータベースに対して用いるＳＱＬを利用することができる。この場合、レコード間の関係が「１：１」の関係だけでなく、ＮＤＢにおける親レコードタイプと子レコードタイプとの間の全ての型に対しても、本実施形態を適用することができる。

また、本実施形態によれば、子レコードにキーとなる項目が存在しなくても、子レコード間で順序を付けることが可能になる。

図４は、本実施形態における情報処理装置の一例を示す。情報処理装置１は、操作情報取得部２、格納部３、生成部５、及び出力部６を含む。

操作情報取得部２は、レコード型間で親子関係が形成されたデータ構造を有するネットワーク型データベースにおける、データ操作対象となる複数のレコード型に対する、第１データ操作言語による第１操作情報を取得する。操作情報取得部２の一例として、受付部１３が挙げられる。

格納部３は、関係定義情報４を格納する。関係定義情報４は、レコード型に含まれる項目情報と、レコード型の親のレコード型のレコードである親レコードを特定する親情報と、親レコードに属する子レコードの順序を示す順序情報とが、レコード型毎に定義されている。格納部３の一例として、格納部１９が挙げられる。関係定義情報４の一例として、仮想表定義２１が挙げられる。

生成部５は、格納部３から取得した関係定義情報４を用いて、複数のレコード型間の関係を解析する。生成部５は、解析した関係と第１操作情報とに基づいて、ネットワーク型データベースに対する第２データ操作言語による第２操作情報を生成する。生成部５の一例として、データ変換部１７が挙げられる。

出力部６は、生成した第２データ操作情報をネットワーク型データベースへ出力する。出力部６の一例として、データ変換部１７が挙げられる。

このように構成することにより、ＮＤＢに対するＳＱＬによるデータ操作の自由度を向上させることができる。また、親レコードタイプ：子レコードタイプ＝１：Ｎの関係に本実施形態を適用することができる。

情報処理装置１は、さらに、定義情報取得部７と、関係定義生成部８を含む。
定義情報取得部７は、ネットワーク型データベースのデータ構造が定義されたデータベース定義情報を取得する。定義情報取得部７の一例として、生成部１５が挙げられる。

関係定義生成部８は、取得したデータベース定義情報から、レコード型毎に、レコード型の項目情報を抽出し、抽出した項目情報に、親特定情報と子順序情報とを追加した関係定義情報４を生成する。関係定義生成部８の一例として、生成部１５が挙げられる。

このように構成することにより、ユーザ側のインターフェースとしてのリレーショナルデータベースで用いるテーブルを仮想的に存在させるための仮想表定義を生成することができる。

関係定義生成部８は、レコード型に複数の親のレコード型が存在する場合、親のレコード型毎に、親特定情報と子順序情報とを関係定義情報に追加する。

このように構成することにより、親レコードタイプ：子レコードタイプ＝１：Ｎの関係だけでなく、親レコードタイプ：子レコードタイプ＝Ｎ：Ｎの関係の場合も、本実施形態を適用することができる。

以下に、本実施形態の実施例について説明する。
（実施例１）
図５は、本実施形態（実施例１）における情報処理装置のブロック図の一例である。情報処理装置１０には、入出力装置１２が接続されている。入出力装置１２は、ユーザがＮＤＢ２２への操作を要求するためのＳＱＬを入力するためのキーボード等の入力デバイス及びディスプレイ等の出力デバイスの総称である。

情報処理装置１０は、ＳＱＬ変換制御部１１、格納部１９、ＮＤＢ２２、ＮＤＢ用データベースマネジメントシステム（ＤＢＭＳ）２５を含む。情報処理装置１０の中央処理演算装置（ＣＰＵ）は、格納部１９から、本実施形態に係るプログラムを読み出して、そのプログラムを実行すると、ＳＱＬ変換制御部１１として機能する。

ＳＱＬ変換制御部１１は、受付部１３、解析部１４、生成部１５、実行部１６として機能する。受付部１３は、入出力装置１２から、ＮＤＢ上のレコードタイプを仮想的な表としてユーザが認識できるようにするための仮想表定義２１の作成指示を受け付けたり、入力されたＳＱＬを受け付けたりする。

生成部１５は、受付部１３からの指示に応じて、ＮＤＢ２２から読み出したＮＤＢ定義２４に基づいて、レコードタイプ毎に仮想表定義２１を生成し、その仮想表定義２１を格納部１９に格納する。

解析部１４は、受付部１３で受け付けたＳＱＬ（ＳＥＬＥＣＴ文，ＵＰＤＡＴＥ文，ＩＮＳＥＲＴ文，ＤＥＬＥＴＥ文等）の構文を解析する。

実行部１６は、解析部１４で解析されたＳＱＬをＮＤＢ用の操作言語（Data Manipulation Language：ＤＭＬ）に変換し、そのＮＤＢ用ＤＭＬを用いてＤＢＭＳ２５へ問合せを行う。実行部１６は、データ変換部１７、レコード順序制御部１８を含む。

データ変換部１７は、格納部１９から読み出したＳＱＬ−ＤＭＬ変換テーブル２０及び仮想表定義２１に基づいて、解析部１４で解析されたＳＱＬからＮＤＢ用ＤＭＬへ変換する。データ変換部１７は、その変換したＮＤＢ用ＤＭＬを用いてＤＢＭＳ２５に問合せを行う。データ変換部１７は、その問合せに対して、ＤＢＭＳ２５から、ＮＤＢ２２で用いる所定の形式で定義されたデータ（ＮＤＢデータ）を受けると、次の処理を行う。すなわち、データ変換部１７は、そのＮＤＢデータをＲＤＢで用いる所定の形式で定義されるデータ（ＲＤＢデータ）に変換する（データ型の変換も含む）。

レコード順序制御部１８は、データ変換部１７によってＮＤＢデータがＲＤＢデータへ変換され、そのＲＤＢデータのレコードを仮想表に出力する場合、レコードの出力順を制御する。

格納部１９には、ＳＱＬ−ＤＭＬ変換テーブル２０、仮想表定義２１、本実施形態に係るプログラム、その他のデータ等が格納されている。ＳＱＬ−ＤＭＬ変換テーブル２０は、ＳＬＱとＮＤＢ用ＤＭＬとを相互に変換するために用いるテーブルである。仮想表定義２１は、レコードタイプ毎に生成されるＲＤＢで使用される仮想的なテーブル構造を管理するためのテーブルである。

ＤＢＭＳ２５は、ＮＤＢ２２を構築するためのデータベース運用及び管理を行う。ＤＢＭＳ２５は、実行部１６から渡されたＮＤＢ用ＤＭＬによる問合せ要求に基づいてＮＤＢ２２へアクセスし、ＮＤＢ２２から問合せ要求に応じたＮＤＢデータを取得する。

ＮＤＢ２２は、ネットワーク型データベースである。ＮＤＢ２２は、レコードデータ２３、ＮＤＢ定義２４を含む。レコードデータ２３は、ＮＤＢ２２が保持する各レコードタイプの実データである。

ＮＤＢ定義２４は、データベース定義言語（ＤＤＬ）を用いて記述されたＮＤＢ２２についてのデータベース定義情報である。ＮＤＢ定義２４には、ＮＤＢ２２における、レコードタイプが保持する項目、レコードタイプ間の親子関係等の定義が設定されている。

図６は、本実施形態（実施例１）におけるＳＱＬ−ＤＭＬ変換テーブルの一例を示す。ＳＱＬ−ＤＭＬ変換テーブル２０は、「Ｎｏ．」、「ＳＱＬ」、「ＤＭＬ」の項目を含む。項目「Ｎｏ．」には、ＳＱＬ−ＤＭＬ変換テーブル２０の各レコードに割り振られた番号が格納されている。項目「ＳＱＬ」には、リレーショナル型データベースで用いるＳＱＬで用いる構文（ＳＥＬＥＣＴ文、ＵＰＤＡＴＥ文，ＤＥＬＥＴＥ文，ＩＮＳＥＲＴ文，ＦＥＴＣＨ文、等）が格納されている。項目「ＤＭＬ」には、ネットワーク型データベースで用いるＤＭＬであって、項目「ＳＱＬ」に設定されたＳＱＬ文に対応するＤＭＬが格納されている。

図７は、本実施形態（実施例１）における１つの親レコードタイプに対して子レコードタイプが複数存在する場合のＮＤＢのデータ構造を説明するための図である。図７（Ａ）に示すように、「会社」という親レコードタイプに対して、「幹部社員」と「一般社員」との２つの子レコードタイプがあるとする。

図７（Ｂ）に示すように、ＮＤＢ２４定義には、親レコードタイプ「会社」の定義情報と、子レコードタイプ「一般幹部」及び「一般社員」の定義情報が示されている。各定義情報にはレコードの項目情報が設定されている。

図８は、図７の各レコードタイプに対応する仮想表定義の一例を示す。生成部１５は、ＮＤＢ定義２４を読み出して、レコードタイプ毎の仮想表定義２１を生成する。具体的に、生成部１５は、ＮＤＢ２２からＮＤＢ定義２４を読み出し、ＮＤＢ定義２４から、レコードタイプ毎に、項目情報を取得し、その項目情報に基づいて、ＳＱＬのＣＲＥＡＴＥ文に相当する定義文を用いて、仮想表定義２１を生成する。

このとき、子レコードタイプの仮想表定義２１には、一意のキーとして、仮想ＪＯＩＮキー及び仮想順序キーが定義されている。仮想ＪＯＩＮキーは、親レコードを特定するためのキー情報であり、外部キーに相当する。図８において、仮想表「幹部社員」及び「一般社員」の場合、仮想ＪＯＩＮキーは、親レコードタイプの仮想表「会社」の会社コードと結合している。仮想順序キーは、その親レコードの何番目の子レコードであるかを示すキー情報である。

図９は、図８の仮想表定義に基づいてユーザ側から認識される仮想表の一例を示す。ユーザ側では、ＮＤＢ２２に保持されている情報は、仮想表定義２１を介することにより、仮想表で管理された情報、すなわち、図９（Ａ）（Ｂ）（Ｃ）に示すように、あたかもリレーショナルＤＢ上のテーブルで管理されている情報のように見える。

これにより、ユーザは、図９（Ａ）（Ｂ）（Ｃ）の仮想表に対して、ＳＱＬ文でアクセスし、ＲＤＢのようにＮＤＢ２２へアクセスすることができる。

仮想表の使い方の一例として、次がある。「親のＵＮＩＱＵＥ ＫＥＹ＝子の仮想ＪＯＩＮキー」という条件で、親レコードタイプに対応する仮想表（親仮想表）と子レコードタイプに対応する仮想表（子仮想表）とがＪＯＩＮされる。これにより、親仮想表と子仮想表とを結び付けることができる。

更に、子仮想表にて、仮想順序キーを使用することで、子レコードの順番を表現でき、ＳＱＬでＮＤＢのようなデータの格納順を考慮した操作が可能となる。また、親のＵＮＩＱＵＥ ＫＥＹと子の仮想ＪＯＩＮキーは外部キーで結び付けられているので、ユーザはＮＤＢ上のレコードタイプ間の子関係を意識する必要はない。

次に、仮想表に対するデータ操作について説明する。
図１０は、本実施形態（実施例１）における仮想表に対するデータ操作を行うためのＳＱＬの一例を示す。例えば、図９（Ａ）（Ｂ）に示す仮想表から会社名「ＡＢＣ」の幹部社員一覧を出力する場合は、図１０に示すＳＱＬ文が実行される。

すると、ユーザ側では、仮想表「会社」から会社名「ＡＢＣ」が抽出され、その会社コードと仮想表「幹部社員」の仮想ＪＯＩＮキーとにより、「ＡＢＣ」についての仮想表「会社」「幹部社員」とが結合されるように見える。さらに、その結合したテーブルから「会社名」、「（幹部社員の）氏名」、順番（「仮想順序キー」の名称を変更したもの）の項目を取得したレコードが取得され、出力されるように見える。

図１１は、本実施形態（実施例１）におけるＳＱＬによるＮＤＢへの問合せ結果の一例を示す。図１０のＳＱＬによるＮＤＢへの問合せに対して、図１１に示すように、その結果をＲＤＢへの問合せと同様のテーブル形式で得ることができる。これにより、ＮＤＢからの出力においても、ＲＤＢと同じインターフェースで出力データを得ることができる。

図１２は、本実施形態（実施例１）における業務手順のフローチャートを示す。ユーザは、入出力装置１２を用いて、データ操作を行う対象とするＮＤＢ２２を指定する（Ｓ１）。ユーザは、その指定したＮＤＢ２２に対応する仮想表定義２１が格納装置２０に存在するか否かを判定する（Ｓ２）。

その指定したＮＤＢに対応する仮想表定義２１が格納装置２０に存在しない場合（Ｓ２で「Ｎｏ」）、ユーザは、ＮＤＢ定義２４に基づいて、仮想表定義２１を自動生成する旨の指示を入出力装置１２に入力する（Ｓ４）。Ｓ４の詳細については、図１３で説明する。

その指定したＮＤＢに対応する仮想表定義２１が格納装置２０に存在する場合（Ｓ２で「Ｙｅｓ」）、ユーザは、その仮想表定義２１が最新のＮＤＢ定義２４に対応する仮想表定義であるか否かを判定する（Ｓ３）。

その仮想表定義２１が最新のＮＤＢの定義に対応する仮想表定義でない場合（Ｓ３で「Ｎｏ」）、ユーザは、ＮＤＢ定義２４に基づいて、仮想表定義２１を自動生成する旨の指示を入出力装置１２に入力する（Ｓ４）。Ｓ４の詳細については、図１３で説明する。

その仮想表定義２１が最新のＮＤＢ定義２４に対応する仮想表定義である場合（Ｓ３で「Ｙｅｓ」）、またはＳ４にて仮想表定義２１が生成された場合、ユーザは、次を行う。すなわち、ユーザは、入出力装置１２によりＳＱＬを入力すると、情報処理装置１０は、仮想表定義２１及びＳＱＬ−ＤＭＬ変換テーブル２０を用いて、ＮＤＢ２２へアクセスする（Ｓ５）。

図１３は、本実施形態（実施例１）における仮想表定義生成処理（Ｓ４）の詳細フローチャートの一例を示す。生成部１５は、ＮＤＢ２２からＮＤＢ定義２４を取得し、そのＮＤＢ定義２４から最上位階層のレコードタイプの定義情報を読み出す（Ｓ１１）。

生成部１５は、その読み出した最上位階層のレコードタイプの定義情報から、そのレコードタイプの列定義を全部取り出す（Ｓ１２）。生成部１５は、取り出した列定義を参照して、その列定義にエントリーキー（一意のキー）が存在するかを判定する（Ｓ１３）。

取り出した列定義にエントリーキーが存在する場合（Ｓ１３で「Ｙｅｓ」）、生成部１５は、エントリーキーをユニークキーとして定義する（Ｓ１４）。取り出した列定義にエントリーキーが存在しない場合（Ｓ１３で「Ｎｏ」）、生成部１５は、列定義に、シーケンシャルな値を持つ１つの列（仮想順序キー）を追加し、その列に設定される値をユニークキーとして定義する（Ｓ１５）。

生成部１５は、Ｓ１４またはＳ１５で調整した列情報に基づいて、ＣＲＥＡＴＥ文を用いて仮想表（ＲＤＢ表）定義２１を作成する（Ｓ１６）。

生成部１５は、取得したＮＤＢ定義２４から、次の階層のレコードタイプの定義情報が存在するかを判定する（Ｓ１７）。次の階層のレコードタイプの定義情報が存在する場合（Ｓ１７で「Ｙｅｓ」）、生成部１５は、そのレコードタイプの定義情報を読み込む（Ｓ１８）。

生成部１５は、Ｓ１８で読み込んだレコードタイプの定義情報から、そのレコードタイプの列定義を全部取り出す（Ｓ１９）。

生成部１５は、Ｓ１８で読み込んだレコードタイプの１つ上の階層のレコードタイプに対応する仮想表定義２１に定義されたユニークキーを有する列情報を、Ｓ１８で読み込んだレコードタイプの列定義に追加し、その列情報を外部キーとして定義する（Ｓ２０）。この外部キーとして追加した列情報は、仮想ＪＯＩＮキーに相当する。

生成部１５は、さらに、列定義に、シーケンシャルな値を持つ１つの列（仮想順序キー）を追加する（Ｓ２１）。

生成部１５は、Ｓ２０及びＳ２１で追加した仮想ＪＯＩＮキーと仮想順序キーとをユニークキーとして定義し、仮想表（ＲＤＢ表）定義２１を作成する（Ｓ２２）。

これにより、ＮＤＢ２２に格納されたＮＤＢ定義２４を用いて、最上位階層のレコードタイプから下位階層のレコードタイプに向かって順次、レコードタイプ毎の仮想表定義２１が作成される。

図１４は、本実施形態（実施例１）におけるＮＤＢへの問合せ処理のフローチャートの一例を示す。ユーザは、入出力装置１２を用いて、ＮＤＢ２２へ問い合わせるためのＳＱＬ文（ＳＥＬＥＣＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ、ＩＮＳＥＲＴ、ＦＥＴＣＨ等）を入力する。例えば、図１０に示すＳＱＬが入力される。受付部１３は、入出力装置１２から入力されたＳＱＬ文を受け付ける（Ｓ３１）。

解析部１４は、受け付けたＳＱＬ文の構文を解析し、ＳＱＬで記載された条件を抽出する（Ｓ３２）。

データ変換部１７は、仮想表とＮＤＢの列名との対応関係、及びＳＱＬ−ＤＭＬ変換表２０に基づいて、解析したＳＱＬ文をＮＤＢ用ＤＭＬに変換する（Ｓ３３）。Ｓ３３の処理については、図１５で詳述する。

データ変換部１７は、変換したＮＤＢ用ＤＭＬを用いて、ＤＢＭＳ２５にアクセス要求をする。ＤＢＭＳ２５は、そのアクセス要求に応じてそのＮＤＢ用ＤＭＬを実行し、ＮＤＢ２２からＮＤＢデータを取り出し、そのＮＤＢデータを実行部１６へ渡す。データ変換部１７は、ＤＢＭＳ２５からＮＤＢデータを受け取る（Ｓ３４）。

データ変換部１７は、ＤＢＭＳ２５からＮＤＢデータを受け取ると、そのＮＤＢデータをＲＤＢ形式に変換する（Ｓ３５）。

実行部１６は、変換して得られたＲＤＢデータを、入出力装置１２に応答する（Ｓ３６）。

図１５は、本実施形態（実施例１）におけるＳＱＬ−ＤＭＬ変換処理（Ｓ３３）のフローチャートの一例を示す。データ変換部１７は、取得したＳＱＬから、操作（選択、更新、挿入、削除等）の対象となる仮想表の名称及びその仮想表の項目名を抽出する（Ｓ４１）。

データ変換部１７は、格納部１９から、抽出した仮想表名に対応する仮想表定義２１を取得し、仮想表定義２１から仮想表名に対応するレコードタイプ名を取得する（Ｓ４２）。データ変換部１７は、仮想表定義２１から、抽出した項目名に対応する項目を検索する（Ｓ４３）。

データ変換部１７は、ＳＱＬ−ＤＭＬ変換テーブル２０から、ＳＱＬの種類に対応するＮＤＢ用ＤＭＬを取得する（Ｓ４４）。データ変換部１７は、ＳＱＬの条件式をＮＤＢ用ＤＭＬの条件式に変換する（Ｓ４５）。

例えば、仮想表ＡＡ，ＢＢから項目Ａ１＝ＸＸＸのレコード（項目Ａ１，Ｂ１）を抽出する場合、データ変換部１７は、ＳＱＬ文「ＳＥＬＥＣＴ Ａ１，Ｂ１ ＦＲＯＭ ＡＡ，ＢＢ ＷＨＥＲＥ Ａ１＝ＸＸＸ」を取得する。この場合、データ変換部１７は、仮想表定義２１の仮想ＪＯＩＮキーから仮想表ＡＡ，ＢＢの関係、すなわち親子関係を判別する。それから、データ変換部１７は、「ＭＯＶＥ」により親レコードタイプＡＡの親レコードから子レコードタイプＢＢの先頭レコードへ移動し、「ＧＥＴ ＡＮＹ」により子レコードから、項目Ａ１＝ＸＸＸを有する子レコードを検索するＤＭＬを作成する。

また、例えば、仮想表ＡＡから項目Ａ１＝ＸＸＸのレコードの項目Ａ１の値をＺに更新する場合、データ変換部１７は、ＳＱＬ文「ＵＰＤＡＴＥ ＡＡ ＳＥＴ Ａ１＝Ｚ ＷＨＥＲＥ Ａ１＝ＸＸＸ」を取得する。この場合、データ変換部１７は、「ＭＯＶＥ」によりレコードタイプＡＡの先頭レコードへ移動し、「ＧＥＴ ＡＮＹ」「ＧＥＴ ＮＥＸＴ」により項目Ａ１＝ＸＸＸのレコードを検索して読み込み、「ＮＯＤＩＦＹ」によりＡ１の値をＺに更新するＤＭＬを作成する。

また、例えば、仮想表ＡＡから項目Ａ１＝ＸＸＸのレコードを削除する場合、データ変換部１７は、ＳＱＬ文「ＤＥＬＥＴＥ ＦＲＯＭ ＡＡ ＷＨＥＲＥ Ａ１＝ＸＸＸ」を取得する。この場合、データ変換部１７は、「ＭＯＶＥ」によりレコードタイプＡＡの先頭レコードへ移動し、「ＧＥＴ ＡＮＹ」「ＧＥＴ ＮＥＸＴ」により項目Ａ１＝ＸＸＸのレコードを検索して読み込み、「ＥＲＡＳＥ」によりそのレコードを削除するＤＭＬを作成する。

また、例えば、仮想表ＡＡに項目Ａ１＝ＸＸＸのレコードを追加する場合、データ変換部１７は、ＳＱＬ文「ＩＮＳＥＲＴ ＩＮＴＯ ＡＡ ＳＥＬＥＣＴ Ａ１＝ＸＸＸ」を取得する。この場合、データ変換部１７は、「ＭＯＶＥ」によりレコードタイプＡＡの先頭レコードへ移動し、「ＳＴＯＲＥ」により項目Ａ１＝ＸＸＸを有するレコードを、子レコード群の先頭または末尾に追加するＤＭＬを作成する。

データ変換部１７は、Ｓ４４〜Ｓ４５で取得したＤＭＬ及び変換した条件文を実行可能なように整形する（Ｓ４６）。

実施例１によれば、ＮＤＢのデータ操作について、あたかもＲＤＢにおけるテーブルに対するデータ操作を行うように、ＳＱＬを使用することができる。その結果、ＮＤＢについてのデータ構造やＮＤＢの入出力に関するインターフェースを認識せずに、ユーザ側としては、ＮＤＢをＲＤＢとして使用することができる。

（実施例２）
実施例１では、１つの親レコードタイプに対して、１または複数の子レコードタイプが存在する場合における仮想表の利用形態について説明した。それに対して、実施例２では、複数の親レコードタイプに対して、１または複数の子レコードタイプが存在する場合における仮想表の利用形態について説明する。なお、実施例２の情報処理装置の構成及び機能に関して、実施例１と同様のものは同じ符号を付し、その説明を省略する。

図１６は、本実施形態（実施例２）における、複数の親レコードタイプに対して複数の子レコードタイプが存在する場合のＮＤＢのデータ構造を説明するための図である。図１６（Ａ）で示しているのは複数の親レコードタイプに対して子レコードタイプも複数存在するパターンである。親レコードタイプ「銀行」に対して、２つの子レコードタイプ「企業」、「個人」がある。また、親レコードタイプ「証券」に対して、２つの子レコードタイプ「企業」、「個人」がある。

逆に、「個人」という子レコードタイプに対して、２つの親レコードタイプ「銀行」、「証券」が存在する。図１６（Ａ）の各レコードタイプの項目情報は、図１６（Ｂ）で示している。また、子レコードタイプ「企業」に対して、２つの親レコードタイプ「銀行」、「証券」も存在する。

このように、図１６（Ａ）は、親レコードタイプ：子レコードタイプ＝Ｎ：Ｎのパターンである。なお、親レコードタイプ：子レコードタイプ＝Ｎ：１のパターンは、「銀行」、「証券」、「個人」の３つのレコードタイプ、または「銀行」、「証券」、「企業」の３つのレコードタイプで表せる。親レコードタイプ：子レコードタイプ＝Ｎ：１のパターンについて処理の流れや使い方は、親レコードタイプ：子レコードタイプ＝Ｎ：Ｎと同じである。

次に、親レコードタイプ：子レコードタイプ＝Ｎ：Ｎの関係の場合の仮想表定義の生成について説明する。親レコードタイプ：子レコードタイプ＝Ｎ：Ｎの関係の場合も、図１３のフローを用いて、仮想表定義を生成する。この場合、図１３のフローを最上位階層のレコードタイプ毎行う。

図１７は、本実施形態（実施例２）における仮想表定義生成処理（Ｓ４）の詳細フローチャートの一例を示す。実施例２において、実施例１と相違する処理は、Ｓ４において、以下で説明する処理であり、それ以外は実施例１と同じである。

生成部１５は、ＮＤＢ２２からＮＤＢ定義２４を取得し、そのＮＤＢ定義２４から最上位階層のレコードタイプのうち、未処理の１つのレコードタイプの定義情報を読み出す（Ｓ１１ａ）。その後、図１３のＳ１２〜Ｓ２２を行う。これにより、１つの最上位階層のレコードタイプから下位階層のレコードタイプに向かって順次、レコードタイプ毎の仮想表定義が作成される。

そのＮＤＢ定義２４に、未処理の最上位階層のレコードタイプがある場合（Ｓ２３で「Ｙｅｓ」）、生成部１５は、ＮＤＢ定義２４から、次の未処理の最上位階層のレコードタイプの定義情報を取得し（Ｓ１１ａ）、Ｓ１２〜Ｓ２２の処理を行う。

生成部１５は、最上位階層のレコードタイプの全てについて、Ｓ１２〜Ｓ２２の処理を実行する。

図１８は、本実施形態（実施例２）における、親レコードタイプ：子レコードタイプ＝Ｎ：Ｎの関係の場合に生成される仮想表定義の一例を示す。図１８の仮想表定義は、図１６（Ａ）、（Ｂ）で示されるＮＤＢのデータ構造を図１７の処理により生成された仮想表定義である。

図１８に示すように、親レコードタイプ：子レコードタイプ＝Ｎ：Ｎの関係の場合、親レコードタイプの仮想表定義は、親レコードタイプ：子レコードタイプ＝１：Ｎの場合と同じである。しかし、子レコードタイプの仮想表定義には、親レコードタイプ毎に、仮想ＪＯＩＮキーと仮想順序キーとが含まれる。

図１９は、図１８の仮想表定義に基づいてユーザ側から認識される仮想表の一例を示す。図１８の仮想表定義に基づくと、ＮＤＢのデータベースは、図１９のように見える。仮想表の使い方は１：Ｎの場合と同様である。

次に、図２０及び図２１を用いて、親レコードタイプ：子レコードタイプ＝Ｎ：Ｎの関係の場合の仮想表の使い方の一例を説明する。

図２０は、本実施形態（実施例２）における、仮想表に対するデータ操作を行うためのＳＱＬの一例を示す。例えば、企業毎の総資産を出力しようとする場合は、図２０のＳＱＬ文を実行する。

図２１は、本実施形態（実施例２）におけるＳＱＬによるＮＤＢへの問合せ結果の一例を示す。図２０のＳＱＬ文を実行した場合、図２１の結果が得られる。

実施例２によれば、複数の親レコードタイプに対して複数の子レコードタイプが存在する場合のＮＤＢのデータ構造に対しても、実施例１と同様に仮想表定義を作成することができる。これにより、ＮＤＢのデータ構造に関わらず、ＳＱＬによりＮＤＢのデータ操作を行うことができる。

本実施形態（実施例１，２）によれば、レコード型の項目に、親レコード型のレコードの特定情報と、子レコードの順序情報とを加えた関係定義を用いてＳＱＬをＮＤＢ用ＤＭＬに変換する。これにより、ＮＤＢ２２に対するＳＱＬによるデータ操作の自由度を向上させることができる。また、ユーザ側からは、ＮＤＢのデータ構造やレコードタイプの列数等を意識せずに、ＲＤＢのインターフェースを用いて、ＮＤＢに対するデータ操作を行うことができる。また、レコードタイプ間の関係も、仮想ＪＯＩＮキーを用いて、あたかも仮想表をＪＯＩＮする感覚で取り扱うことができる。また、子レコードも仮想順序キーにより管理されているので、ユーザは、ＮＤＢにおける子レコードの順序に依存するデータ操作も、仮想表に対するデータ操作で取り扱うことができる。

図２２は、本実施形態の実施例１，２におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。コンピュータ１１は、ＣＰＵ３２、ＲＯＭ３３、ＲＡＭ３６、通信Ｉ／Ｆ３４、記憶装置３７、出力Ｉ／Ｆ３１、入力Ｉ／Ｆ３５、読み取り装置３８、バス３９、出力機器４１、入力機器４２によって構成されている。

ここで、ＣＰＵは、中央演算装置を示す。ＲＯＭは、リードオンリメモリを示す。ＲＡＭは、ランダムアクセスメモリを示す。Ｉ／Ｆは、インターフェースを示す。バス３９には、ＣＰＵ３２、ＲＯＭ３３、ＲＡＭ３６、通信Ｉ／Ｆ３４、記憶装置３７、出力Ｉ／Ｆ３１、入力Ｉ／Ｆ３５、及び読み取り装置３８が接続されている。読み取り装置３８は、可搬型記録媒体を読み出す装置である。出力機器４１は、出力Ｉ／Ｆ３１に接続されている。入力機器４２は、入力Ｉ／Ｆ３５に接続にされている。

記憶装置３７としては、ハードディスク、フラッシュメモリ、磁気ディスクなど様々な形式の記憶装置を使用することができる。記憶装置３７またはＲＯＭ３３には、ＣＰＵ３２をＳＱＬ変換制御部１１として機能させるプログラム、ＮＤＢ２２、ＳＱＬ−ＤＭＬ変換テーブル２０、仮想表定義２１等が格納されている。

ＣＰＵ３２は、記憶装置３７等に格納した上記実施形態で説明した処理を実現するプログラムを読み出し、当該プログラムを実行する。

上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワーク４０、および通信Ｉ／Ｆ３４を介して、例えば記憶装置３７に格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読み取り装置３８にセットされて、ＣＰＵ３２によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＩＣカード、ＵＳＢメモリ装置など様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読み取り装置３８によって読み取られる。

また、入力機器４２には、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサ、タブレットなどを用いることが可能である。また、出力機器４１には、ディスプレイ、プリンタ、スピーカなどを用いることが可能である。また、ネットワーク４０は、インターネット、ＬＡＮ、ＷＡＮ、専用線、有線、無線等の通信網であってよい。

なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

１ 報処理装置
２ 操作情報取得部
３ 格納部
４ 関係定義情報
５ 生成部
６ 出力部
７ 定義情報取得部
８ 関係定義生成部
１０ 情報処理装置
１１ ＳＱＬ変換制御部
１２ 入出力装置
１３ 受付部
１４ 解析部
１５ 生成部
１６ 実行部
１７ データ変換部
１８ レコード順序制御部
１９ 格納部
２０ ＳＱＬ−ＤＬ変換テーブル
２１ 仮想表定義
２２ ＮＤＢ
２３ レコードデータ
２４ ＮＤＢ定義
２５ ＤＢＭＳ

Claims (5)

1. コンピュータに、
   レコード型間で親子関係が形成されたデータ構造を有するネットワーク型データベースにおける、データ操作対象となる複数のレコード型に対する、第１データ操作言語による第１操作情報を取得し、
   前記レコード型に含まれる項目情報と、該レコード型の親のレコード型のレコードである親レコードを特定する親情報と、該親レコードに属する子レコードの順序を示す順序情報とが、レコード型毎に定義された関係定義情報が格納された格納部から取得した該関係定義情報を用いて、前記複数のレコード型間の関係を解析し、解析した前記関係と前記第１操作情報とに基づいて、前記ネットワーク型データベースに対する第２データ操作言語による第２操作情報を生成し、
   生成した前記第２データ操作情報を前記ネットワーク型データベースへ出力する
   処理を実行するデータベースアクセス制御プログラム。
2. 前記コンピュータに、さらに、
   前記ネットワーク型データベースのデータ構造が定義されたデータベース定義情報を取得し、
   取得した前記データベース定義情報から、前記レコード型毎に、前記レコード型の項目情報を抽出し、抽出した該項目情報に、前記親特定情報と前記子順序情報とを追加した前記関係定義情報を生成する
   ことを特徴とする請求項１に記載のデータベースアクセス制御プログラム。
3. 前記レコード型に複数の親のレコード型が存在する場合、該親のレコード型毎に、前記親特定情報と前記子順序情報とを前記関係定義情報に追加する
   ことを特徴とする請求項１に記載のデータベースアクセス制御プログラム。
4. レコード型間で親子関係が形成されたデータ構造を有するネットワーク型データベースにおける、データ操作対象となる複数のレコード型に対する、第１データ操作言語による第１操作情報を取得する操作情報取得部と、
   前記レコード型に含まれる項目情報と、該レコード型の親のレコード型のレコードである親レコードを特定する親情報と、該親レコードに属する子レコードの順序を示す順序情報とが、レコード型毎に定義された関係定義情報を格納する格納部と、
   前記格納部から取得した前記関係定義情報を用いて、前記複数のレコード型間の関係を解析し、解析した前記関係と前記第１操作情報とに基づいて、前記ネットワーク型データベースに対する第２データ操作言語による第２操作情報を生成する生成部と、
   生成した前記第２データ操作情報を前記ネットワーク型データベースへ出力する出力部と、
   を備えることを特徴とする情報処理装置。
5. コンピュータが、
   レコード型間で親子関係が形成されたデータ構造を有するネットワーク型データベースにおける、データ操作対象となる複数のレコード型に対する、第１データ操作言語による第１操作情報を取得し、
   前記レコード型に含まれる項目情報と、該レコード型の親のレコード型のレコードである親レコードを特定する親情報と、該親レコードに属する子レコードの順序を示す順序情報とが、レコード型毎に定義された関係定義情報が格納された格納部から取得した該関係定義情報を用いて、前記複数のレコード型間の関係を解析し、解析した前記関係と前記第１操作情報とに基づいて、前記ネットワーク型データベースに対する第２データ操作言語による第２操作情報を生成し、
   生成した前記第２データ操作情報を前記ネットワーク型データベースへ出力する
   ことを特徴とするデータベースアクセス制御方法。

Images