JP3709510B2 - Relational database management method and relational database system - Google Patents
Relational database management method and relational database system Download PDFInfo
- Publication number
- JP3709510B2 JP3709510B2 JP04326197A JP4326197A JP3709510B2 JP 3709510 B2 JP3709510 B2 JP 3709510B2 JP 04326197 A JP04326197 A JP 04326197A JP 4326197 A JP4326197 A JP 4326197A JP 3709510 B2 JP3709510 B2 JP 3709510B2
- Authority
- JP
- Japan
- Prior art keywords
- file
- relational database
- data
- database management
- plug
- 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
Description
【０００１】
【発明の属する技術分野】
本発明は、リレーショナルデータベース管理方法およびリレーショナルデータベースシステムに関し、リレーショナルデータベースと、リレーショナルデータベース管理システムがサポートしていないユーザ定義のデータ型のデータとを共に管理することが出来るリレーショナルデータベース管理方法およびリレーショナルデータベースシステムに関する。
【０００２】
【従来の技術】
リレーショナルデータベースのデータベース操作言語であるＳＱＬ（Ｓtructured Ｑuery Ｌanguage）は、ＩＳＯ（International Ｏrganization for Ｓtandardization）によりＳＱＬ規格として規格化されている。
リレーショナルデータベースをサポートしているリレーショナルデータベース管理システムにおいては、前記ＳＱＬ規格に準拠した仕様でリレーショナルデータベースのサポートが図られている。
【０００３】
図１２に示すように、リレーショナルデータベースは、行と列からなる表形式で表現される。列には、ＳＱＬ規格で規定されている列属性を定義することができる。そして、その列に定義した列属性に合致したデータだけがその列に格納される。
図１２の例では、列１の列属性は整数型（ＩＮＴＥＧＥＲ型）であり、列２の列属性は小数点型（ＤＥＣＩＭＡＬ型）であり、列３の列属性は固定長文字型（ＣＨＡＲ型）であり、列４の列属性は可変長文字型（ＶＡＲＣＨＡＲ型）である。
【０００４】
さて、ＳＱＬ規格で規定されていない列属性のデータ（例えば画像，音声，文書，図形，マルチメディアデータ，それらを種々の形式で圧縮したデータなど）が出現したとき、その度にＳＱＬ規格で規格化することは煩雑であり、現実的ではない。このため、ＳＱＬ規格で規定されていない列属性のデータも、規定されている列属性のデータと同一のデータベース内に混在させられるように、ＳＱＬ３においてＳＱＬ規格の機能拡張が検討されている。すなわち、ＳＱＬ３によれば、ユーザが表の定義時に列属性として任意にデータ型を定義でき、その列に定義したデータ型のデータを格納し且つアクセスできるようになる。
図１３の表は、列２と列４とにユーザがデータ型を定義した例である。
【０００５】
図１３の表に対する行の追加は次のように行う。
(１)アプリケーションプログラムが、追加行の各列に相当するデータを設定し、行追加のＳＱＬコマンド（ＩＮＳＥＲＴ）を発行することにより、ＲＤＢＭＳが起動される。
(２)ＲＤＢＭＳは、列１と列３のデータについては、ＲＤＢＭＳ自身が表に格納するための形式であるデータに変換し、追加行（ｎ＋１）の列１と列３とに格納する。列２と列４のデータについては、ユーザによって指定された列２をアクセスするプラグイン関数と列４をアクセスするプラグイン関数とを起動する。
(３)起動された各プラグイン関数は、列２のデータ及び列４のデータを、表に格納するための形式のデータに変換し、ＲＤＢＭＳにリターンする。
(４)ＲＤＢＭＳは、列２と列４のデータを追加行（ｎ＋１）の列２と列４に格納する。
【０００６】
図１３の表に対する行の検索は次のように行う。
(１)アプリケーションプログラムが、例えば列１のデータに特定の値をもつ行を抽出するためのＳＱＬコマンド（ＳＥＬＥＣＴ）を発行することにより、ＲＤＢＭＳが起動される。
(２)ＲＤＢＭＳは、列１のデータに指定の値をもつ行の抽出を行うが、抽出した行には列２と列４とが存在するため、ユーザによって指定された列２をアクセスするプラグイン関数と列４をアクセスするプラグイン関数とを起動する。
(３)起動された各プラグイン関数は、列２のデータ及び列４のデータをアプリケーションプログラムが操作できるデータに変換し、ＲＤＢＭＳに戻す。
(４)ＲＤＢＭＳは、当該行をアプリケーションプログラムに渡す。
(５)上記の操作を抽出する各行について行う。
【０００７】
上記のように、ユーザ定義のデータ型の列を含む表のアクセスを実現するため、ＲＤＢＭＳは、プラグイン関数と連携する。すなわち、プラグイン関数とは、ユーザが定義したデータ型のデータを操作するためにデータベース管理システムに組み込むプログラムのことをいう。
プラグイン関数は、ユーザ定義のデータ型の列に格納したデータに効率よくアクセスするための情報たとえばインデクスを独自に作成してそれを利用することもできる。
次に、プラグイン関数によるインデクスの作成と利用を説明するが、説明の簡単化のために、図１３に示す表から列４を削除した表を操作対象に想定し、ユーザ定義のデータ型である文書データが列２に格納されており、その文書データに関するインデクスを作成し利用するものとする。
図１４は、ユーザ定義のデータ型の列のデータである文書データをＤＢ領域（データベース領域）２１の表の列２に文書データ７４として格納すると共にその文書データに関する情報をインデクス２４に追加する動作の説明図である。
インデクス２４は、インデクスの構造および性質上、表形式のデータとはできないデータ群である。換言すれば、インデクス２４は、データベース管理システム１０がサポートしていないデータベースすなわちデータベース管理システム管轄外のデータベースであり、ＯＳ提供のファイルアクセスメソドを利用してプラグイン関数１９が直接アクセスするＯＳ管理のファイルである。
(１)アプリケーションプログラム２８は、追加行の各列に相当するデータを設定し、行追加のＳＱＬコマンド（ＩＮＳＥＲＴ）を発行し、ＲＤＢＭＳ１０を起動する。
(２)ＲＤＢＭＳ１０は、列１と列３のデータについては、ＲＤＢＭＳ１０自身が表に格納するための形式であるデータに変換し、ＤＢ領域２１の表の列１と列３とに格納する。列２のデータについては、そのデータを構成する入力文書や文書番号をパラメタに指定して、列２のデータを処理するプラグイン関数１９を起動する。
(３)プラグイン関数１９は、指定されたパラメタに基づき、ＯＳ提供のファイルアクセスメソドを利用して、列２のデータに関する文書情報をインデクス２４に追加する。また、パラメタで指定された入力文書をＤＢ領域２１の表に格納するための形式に変換して文書データとし、その文書データをＤＢＭＳ１０への戻り値とする。
(４)ＤＢＭＳ１０は、戻り値である文書データを受け取り、それをＤＢ領域２１の表の列２に文書データ７４として格納する。
【０００８】
図１５は、インデクス２４を利用して、ユーザ定義のデータ型の列のデータである文書データをＤＢ領域２１の表から検索する動作の説明図である。
(１)アプリケーションプログラム２８は、列２を対象とした検索条件を指定したＳＱＬコマンド（ＳＥＬＥＣＴ）を発行し、ＤＢＭＳ１０を起動する。
(２)ＤＢＭＳ１０は、ユーザ定義のデータ型である列２を対象とした検索条件であるため、検索条件をパラメタに指定して、列２のデータを処理するプラグイン関数１９を起動する。
(３)プラグイン関数１９は、指定されたパラメタに基づいてインデクス２４を検索し、検索条件に合致する列２のデータの行番号や存在位置情報を得て、この行番号や存在位置情報を戻り値としてＤＢＭＳ１０に戻る。
(４)ＤＢＭＳ１０は、受取った行番号や存在位置情報を利用してＤＢ領域２１の表の中から検索条件を満たす列１，列３のデータおよび文書データ７４を取り出す。そして、文書データ７４は、プラグイン関数１９に戻す。
(５)プラグイン関数１９は、文書データ７４をアプリケーションプログラム２８が操作できるデータに変換して、それを戻り値としてＤＢＭＳ１０に戻る。
(６)ＤＢＭＳ１０は、列１，列３のデータおよびプラグイン関数１９から戻されたデータをアプリケーションプログラム２８に渡す。
【０００９】
【発明が解決しようとする課題】
上記のように、従来は、ユーザ定義のデータ型のデータに依存した特殊な構造をしたデータ（インデクス２４）は、データベース管理システム（ＤＢＭＳ１０）が管理するデータベース（ＤＢ領域２１）に格納することができないため、プラグイン関数（プラグイン関数１９）が独自に管理するファイルとしている。
【００１０】
しかし、このような管理方法では、次の問題が発生する。
・排他制御
データベース管理システムの管理外のファイルであっても、データベース管理システムが管理するデータベースと連動して更新され且つ複数ユーザ間で共用される情報が格納されるため、当該ファイルに対して排他制御を行ってシリアライズ（順序化）する必要がある。しかし、データベース管理システムと別個に排他制御を行うと、同時実行性が低下するという問題が発生する。なお、当該ファイルの全体でなく部分的に排他制御を行えば、同時実行性の低下を最小限に出来るが、そのようなロジックをプラグイン関数の中に組み入れることは簡単には出来ない。
・整合性
データベース管理システムが管理するデータベースとデータベース管理システムの管理外のファイルの両方を更新したトランザクションがロールバックした場合、前記データベースの内容はデータベース管理システムが自動的にトランザクション開始時点の状態に戻すが、前記ファイルについてはデータベース管理システムは何もしない。従って、整合性をとるために、別の手段で前記ファイルをトランザクション開始時点の状態に戻す必要がある。この手段としては、前記ファイルをトランザクション開始時点の状態へ戻す機能をプラグイン関数に設ければよいが、そのようなロジックをプラグイン関数の中に組み入れることは簡単ではない。また、別の手段として、手作業で前記ファイルをトランザクション開始時点の状態へ戻すことが考えられるが、これはユーザの負担が過大になる。
・障害回復
データベース管理システムが管理するデータベースあるいはデータベース管理システムの管理外のファイルに物理的な障害が発生した場合、それぞれのバックアップによる回復を図る。このとき、前記データベースについては、データベース管理システムが取得している更新情報を利用して障害発生直前の状態にまで回復できるが、前記ファイルについては、データベース管理システムが更新情報を取得していないため、バックアップを落とし込むことでバックアップ取得時の状態に戻すだけである。従って、データベースとファイルの整合性をとるために、別の手段で前記ファイルを障害発生直前の状態にまで回復する必要がある。この手段としては、前記ファイルを障害発生直前の状態にまで回復する機能をプラグイン関数に設ければよいが、そのようなロジックをプラグイン関数の中に組み入れることは簡単ではない。また、別の手段として、手作業で前記ファイルを障害発生直前の状態にまで回復することが考えられるが、これはユーザの負担が過大になる。
【００１１】
結局のところ、従来のリレーショナルデータベース管理方法では、システムとしての信頼性や運用性を損わないためには、ユーザの負担が重くなり、リレーショナルデータベースと、リレーショナルデータベース管理システムがサポートしていないユーザ定義のデータ型のデータとを共に管理することが難しい問題点があった。
そこで、本発明の目的は、リレーショナルデータベースと、リレーショナルデータベース管理システムがサポートしていないユーザ定義のデータ型のデータとを共に管理することが出来るリレーショナルデータベース管理方法およびリレーショナルデータベースシステムを提供することにある。
【００１２】
【課題を解決するための手段】
第１の観点では、本発明は、ユーザによるデータ型の定義とそのユーザ定義データ型のデータに対する操作を行うプラグイン関数とを組み込む機能を有し、表形式で表されるリレーショナルデータベースを管理するリレーショナルデータベース管理システムにおけるリレーショナルデータベース管理方法において、前記プラグイン関数が使用するファイルを、前記リレーショナルデータベース管理システムの管理するデータを格納するデータベース領域に前記プラグイン関数に対して送られたデータ型の定義に基づいて作成し、前記ファイルに対するアクセスは前記プラグイン関数が前記リレーショナルデータベース管理システムの提供するファイル操作マクロを発行して行い、前記リレーショナルデータベース管理システムは前記発行されたファイル操作マクロを実行するとともに前記ファイルに対して前記リレーショナルデータベース管理システムによる排他制御を行うことを特徴とするリレーショナルデータベース管理方法を提供する。
上記第１の観点によるリレーショナルデータベース管理方法では、ユーザ定義のデータ型のデータを操作するためにプラグイン関数が管理するファイルを、データベース管理システムが管理するデータベース領域に、プラグイン関数に対して送られたデータ型の定義に基づいて作成し、そのファイルをリレーショナルデータベースと同時にデータベース管理システムが排他制御を行うようにした。この結果、排他制御に関してはデータベース管理システムが管理するため、システムとしての信頼性や運用性が高くなり、ユーザの負担が軽くなり、リレーショナルデータベースと、リレーショナルデータベース管理システムがサポートしていないユーザ定義のデータ型のデータ（のファイル）とを共に管理することが容易になる。
【００１３】
第２の観点では、本発明は、上記第１の観点によるリレーショナルデータベース管理方法において、前記プラグイン関数が前記ファイルを更新した際に前記ファイルの更新情報を出力しておき、前記リレーショナルデータベースへのアクセスを行ったトランザクションがロールバックした場合には前記更新情報を用いて前記ファイルおよび前記リレーショナルデータベースについてトランザクション開始時点の状態に回復することを特徴とするリレーショナルデータベース管理方法を提供する。
上記第２の観点によるリレーショナルデータベース管理方法では、トランザクションがロールバックした場合に、ユーザ定義のデータ型のデータを操作するためにプラグイン関数が管理するファイルの更新情報から当該ファイルを回復しうるから、リレーショナルデータベースと、リレーショナルデータベース管理システムがサポートしていないユーザ定義のデータ型のデータ（のファイル）とを相互に整合性がとれている状態に回復できる。この結果、ロールバックに関して、システムとしての信頼性や運用性が高くなり、ユーザの負担が軽くなり、リレーショナルデータベースと、リレーショナルデータベース管理システムがサポートしていないユーザ定義のデータ型のデータ（のファイル）とを共に管理することが容易になる。
【００１４】
第３の観点では、本発明は、上記第１の観点によるリレーショナルデータベース管理方法において、前記リレーショナルデータベース領域内に格納されている前記リレーショナルデータベース管理システムが管理するデータおよび前記ファイルを外部記憶装置に出力してバックアップを作成しておき、前記プラグイン関数が前記ファイルを更新した際に前記ファイルの更新情報をログファイルに出力しておき、前記バックアップと前記ログファイルから取り出した更新情報とにより前記リレーショナルデータデータと前記ファイルとを回復することを特徴とするリレーショナルデータベース管理方法を提供する。
上記第３の観点によるリレーショナルデータベース管理方法では、障害が発生した場合に、データベース管理システムが提供するユティリティを使うことで、ユーザ定義のデータ型のデータを操作するためにプラグイン関数が管理するファイルのバックアップと更新情報から当該ファイルを回復しうるから、リレーショナルデータベースと、リレーショナルデータベース管理システムがサポートしていないユーザ定義のデータ型のデータ（のファイル）とを相互に整合性がとれている状態に回復できる。この結果、障害に関して、システムとしての信頼性や運用性が高くなり、ユーザの負担が軽くなり、リレーショナルデータベースと、リレーショナルデータベース管理システムがサポートしていないユーザ定義のデータ型のデータ（のファイル）とを共に管理することが容易になる。
【００１５】
第４の観点では、本発明は、上記第１の観点によるリレーショナルデータベース管理方法において、前記リレーショナルデータベース領域内に格納されている前記リレーショナルデータベース管理システムが管理する前記リレーショナルデータベースおよび前記ファイルの内容を外部記憶装置に出力し、その出力した内容の再登録により前記リレーショナルデータベースおよび前記ファイルの内容を再編成することを特徴とするリレーショナルデータベース管理方法を提供する。
上記第４の観点によるリレーショナルデータベース管理方法では、例えばフラグメンテーションが発生した場合に、データベース管理システムが提供するユティリティを使うことで、ユーザ定義のデータ型のデータを操作するためにプラグイン関数が管理するファイルの外部記憶装置に出力していた内容から当該ファイルの内容を再編成しうるから、前記フラグメンテーションを解消できる。この結果、システムとしての信頼性や運用性が高くなり、ユーザの負担が軽くなり、リレーショナルデータベースと、リレーショナルデータベース管理システムがサポートしていないユーザ定義のデータ型のデータ（のファイル）とを共に管理することが容易になる。
【００１６】
第５の観点では、本発明は、表形式で表されるリレーショナルデータベースと、ユーザによるデータ型の定義とそのユーザ定義データ型のデータに対する操作を行うプラグイン関数とを組み込む機能を有し前記リレーショナルデータベースを管理するリレーショナルデータベース管理システムとを含むリレーショナルデータベースシステムにおいて、前記データベース管理システムは、前記プラグイン関数が使用するファイルを自己の管理するデータを格納するデータベース領域に前記プラグイン関数に対して送られたデータ型の定義に基づいて作成し、自己の提供するファイル操作マクロを前記プラグイン関数が自己に対して発行すると、そのファイル操作マクロを実行して前記ファイルに対するアクセスを行うと共に前記ファイルに対して排他制御を行うことを特徴とするリレーショナルデータベースシステムを提供する。
上記第５の観点によるリレーショナルデータベースシステムでは、ユーザ定義のデータ型のデータを操作するためにプラグイン関数が管理するファイルを、データベース管理システムが管理するデータベース領域に、前記プラグイン関数に対して送られたデータ型の定義に基づいて作成し、そのファイルをリレーショナルデータベースと同時にデータベース管理システムが排他制御を行うようにした。この結果、排他制御に関してはデータベース管理システムが管理するため、システムとしての信頼性や運用性が高くなり、ユーザの負担が軽くなり、リレーショナルデータベースと、リレーショナルデータベース管理システムがサポートしていないユーザ定義のデータ型のデータ（のファイル）とを共に管理することが容易になる。
【００１７】
【発明の実施の形態】
以下、本発明の実施の形態を図面を用いて具体的に説明する。なお、これにより本発明が限定されるものではない。
図１は、本発明の一実施形態のリレーショナルデータベースシステムの構成図である。
このリレーショナルデータベースシステム１００は、磁気ディスク装置２０のＤＢ領域２１に表データ２２として構築されたリレーショナルデータベースと、リレーショナルデータベースを管理するリレーショナルデータベース管理システムであるＤＢＭＳ１０とプラグイン関数１９とを含むＤＢサーバ９と、アプリケーションプログラム２８が実行され前記ＤＢＭＳ１０にＳＱＬコマンド処理の実行を要求するクライアント２７と、ユーザがコマンド入力などの操作を行うコンソール３０と、それらを接続するネットワーク２９とを具備して構成されている。
【００１８】
前記ＤＢＭＳ１０に接続された磁気ディスク装置２０には、ＤＢＭＳ１０が管理するＤＢ領域２１が割り当てられている。そのＤＢ領域２１中には、ＤＢＭＳ１０が直接的に操作するリレーショナルデータベースである表データ２２と、ユーザ定義のデータ型のデータを操作するためのプラグイン関数１９が直接的に操作するデータのファイル２４とが格納されている。
前記ファイル２４は、ユーザがコンソール３０からファイル作成コマンド（図４）を入力することにより作成され、また、ファイル削除コマンド（図５）を入力することにより削除される。
【００１９】
また、前記ＤＢＭＳ１０に接続された磁気ディスク装置２５には、前記表データ２２および前記ファイル２４の更新情報であるログファイル２６を格納している。
【００２０】
前記ＤＢＭＳ１０は、トランザクションを制御するトランザクション制御１１と、そのトランザクション制御１１が受け付けたＳＱＬコマンドを解析しデータベース操作の実行を制御するＳＱＬ制御１２と、そのＳＱＬ制御１２からの要求を受けて表データ２２の操作を行うデータ操作１３と、プラグイン関数１９を制御するプラグイン関数制御１７と、プラグイン関数１９からのファイル操作要求を受け付けるファイル操作１８と、表データ２２およびファイル２４の整合性を維持するための排他管理を行う排他管理１４と、表データ２２およびファイル２４の更新時に更新情報をログファイル２６へ出力するログ管理１５と、前記データ操作１３が表データ２２を参照・更新したり前記ファイル操作１８がファイル２４を参照・更新するためにＤＢ領域２１の操作を行うＤＢ領域操作１６とを具備している。
【００２１】
図２は、プラグイン関数１９がファイル２４を参照する参照処理の流れ図である。
この参照処理は、ユーザ定義のデータ型の列が存在する表データ２２にアクセスするＳＱＬコマンドをデータアプリケーションプログラム２８から受け取ったＤＢＭＳ１０により、プラグイン関数制御１７を通して、起動される。
ステップ３１では、プラグイン関数１９は、ファイル２４を参照用としてオープンする。
ステップ３２では、位置と長さを指定してファイル２４の対象データをバッファ上に参照読み込みする。この参照読み込みの場合、ＤＢＭＳ１０の排他管理１４が、対象データの格納ページに対し、参照用の排他を確保する。
ステップ３３では、バッファ上の対象データを参照する。
ステップ３４では、対象データを全て参照したか否か判定し、まだ残っていれば前記ステップ３２に戻り、全て参照したならステップ３５へ進む。
ステップ３５では、ファイル２４をクローズする。そして、参照処理を終了する。
【００２２】
図３は、プラグイン関数１９がファイル２４を更新する更新処理の流れ図である。
この更新処理は、ユーザ定義のデータ型の列が存在する表データ２２にアクセスするＳＱＬコマンドをデータアプリケーションプログラム２８から受け取ったＤＢＭＳ１０により、プラグイン関数制御１７を通して、起動される。
ステップ４１では、プラグイン関数１９は、ファイル２４を更新用としてオープンする。
ステップ４２では、位置と長さを指定してファイル２４の対象データをバッファ上に更新読み込みする。この更新読み込みの場合、ＤＢＭＳ１０の排他管理１４が、対象データの格納ページに対し、更新用の排他を確保する。
ステップ４３では、バッファ上の対象データを参照する。
ステップ４４では、対象データを更新すべきか否かを判断し、更新すべきならステップ４５へ進み、更新が不要ならステップ４７へ進む。
ステップ４５では、バッファ上の対象データの内容を更新する。
ステップ４６では、バッファ上の更新した対象データをファイル２４に書き込む。この時、ＤＢＭＳ１０のログ管理１５が、ファイル２４の更新前後内容を更新情報としてログファイル２６へ出力する。
ステップ４７では、対象データを全て更新したか否か判定し、まだ残っていれば前記ステップ４２に戻り、全て更新したならステップ４８へ進む。
ステップ４８では、ファイル２４をクローズする。そして、更新処理を終了する。
【００２３】
上記参照処理および更新処理において、オープン／読み込み／書き込み／クローズ等のファイル２４に対して使用するマクロをプラグイン関数１９が発行すると、制御がＤＢＭＳ１０のファイル操作１８に移る。
ＤＢＭＳ１０のファイル操作１８は、ファイル２４に対するマクロの種類を調べ、マクロに応じた処理を実行した後、マクロ要求に相当する要求をＯＳ提供のファイルアクセスメソドに対して行う。
【００２４】
図４は、ファイル作成コマンドの説明図である。
ファイル作成コマンドは、コマンド部「ｄｂｆｍａｋｅ」とパラメタ部とからなり、パラメタ部には「作成するファイル２４を格納するＤＢ領域２１の名称／作成するファイル２４の名称」および「作成するファイル２４の容量」を指定する。
このファイル作成コマンドをコンソール３０からＤＢＭＳ１０に入力すると、ファイル操作１８が起動され、ＤＢ領域操作１６を介して、ＤＢ領域２１にファイル２４が作成される。
【００２５】
図５は、ファイル削除コマンドの説明図である。
ファイル削除コマンドは、コマンド部「ｄｂｆｒｅｍｏｖｅ」とパラメタ部からなり、パラメタ部には「削除するファイル２４が格納されているＤＢ領域２１の名称／削除するファイル２４の名称」を指定する。
このファイル削除コマンドをコンソール３０からＤＢＭＳ１０に入力すると、ファイル操作１８が起動され、ＤＢ領域操作１６を介して、ＤＢ領域２１のファイル２４が削除される。
【００２６】
図６は、ファイルオープンマクロの説明図である。
ファイルオープンマクロは、マクロ命令部「ｄｂｆｏｐｅｎ」とパラメタ部からなり、パラメタ部には「オープンするファイル２４が格納されているＤＢ領域２１の名称／オープンするファイル２４の名称」および「使用目的に合った排他制御を実現するめたのオープンタイプ」を指定する。
オープンタイプには、他ユーザの参照・更新を許すことなくファイル２４を参照・更新するための“ＥＸ”（独占更新）と、他ユーザの参照・更新を許してファイル２４を参照・更新するための“ＳＵ”（共用更新）と、他ユーザの参照のみを許してファイル２４を参照・更新するための“ＰＵ”（保護更新）と、他ユーザの参照・更新を許してファイル２４を参照するための“ＳＲ”（共用参照）と、他ユーザからの参照のみを許してファイル２４を参照するための“ＰＲ”（保護参照）の５種類がある。
例えば図２の参照処理のステップ３１ではオープンタイプ“ＳＲ”を指定し、図３の更新処理のステップ４１ではオープンタイプ“ＳＵ”を指定することになる。
オープンタイプと参照更新時の排他単位の関係を表１に示す。また、オープンタイプの同時実行可能性を表２に示す。
【００２７】
【表１】
【００２８】
【表２】
【００２９】
ファイルオープンマクロは、戻り値として、ファイルロケータを応答する。この後のファイル操作では、マクロのパラメタとして、ファイルロケータを指定する。
ＳＱＬ実行時にＤＢＭＳ１０のプラグイン関数制御１７より起動されたプラグイン関数１９がファイルオープンマクロを発行すると、ファイル操作１８が起動され、そのファイル操作１８は排他管理１４を起動し、オープンタイプに従った排他を確保する。
ファイルオープンマクロの戻り値は、オープン成功時はファイルロケータ（正値）であり、オープン失敗時は負値である。
オープンしたファイルは、ファイルクローズマクロ（図９）またはトランザクションの終了によりクローズ（未オープン）状態になる。
【００３０】
図７は、ファイル参照マクロの説明図である。
ファイル参照マクロは、マクロ命令部「ｄｂｆｒｅａｄ」とパラメタ部からなり、パラメタ部には「データを受け取るための入力バッファ領域のアドレス」「対象データのファイル２４上での位置」「データ長」「ＤＢＭＳ１０が参照目的別に適切な排他制御を行うための参照タイプ」および「ファイルオープン時に得たファイルロケータ」を指定する。
参照タイプには、参照だけを目的とする“Ｒ”と、そのデータを更新してファイルに反映する“Ｕ”の２種類がある。
例えば図２の参照処理のステップ３２では参照タイプ“Ｒ”を指定し、図３の更新処理のステップ４２では参照タイプ“Ｕ”を指定することになる。
オープンタイプと参照タイプと確保する排他の関係を表３に示す。
【００３１】
【表３】
【００３２】
ファイルオープンを行ったプラグイン関数１９がファイル参照マクロを発行することでファイル操作１８が起動される。ファイル操作１８は、排他管理１４を起動して、オープンタイプと参照タイプにしたがって対象データが格納されているページに対して排他を確保するか又は排他を行わない。この後、ファイル操作１８は、ＤＢ領域操作１６を起動する。ＤＢ領域操作１６は、ＯＳ提供のファイルアクセスメソドを使用して、パラメタにより指定されたＤＢ領域２１中にあるファイル２４のデータ位置のページ（内容）を読み出して、データ受け取り用のバッファ領域に保持する。
ファイル参照マクロの戻り値は、参照成功時は“０”値であり、参照失敗時は負値である。
【００３３】
図８は、ファイル更新マクロの説明図である。
ファイル更新マクロは、マクロ命令部「ｄｂｆｗｒｉｔｅ」とパラメタ部からなり、パラメタ部には「ファイル２４に出力するデータを設定したバッファ領域のアドレス」「ファイル２４上での対象データの位置」「データ長」「ＤＢＭＳ１０がファイル更新に際して行う更新情報（ログ）の取得方法を指示する更新タイプ」および「ファイルオープン時に得たファイルロケータ」を指定する。
更新タイプには、ＤＢＭＳ１０が更新対象部分について更新前と更新後のログを取得する“ＬＡ”と、更新前のログだけを取得する“ＬＢ”と、更新後のログだけを取得する“ＬＦ”と、更新した部分のログを取得しない“ＮＬ”の４種類があり、障害発生時のファイル回復の運用方法やプラグイン関数１９の更新処理方式に合ったログ取得方法を更新タイプで指定することができる。
例えば図３の更新処理のステップ４６では、ロールバックとＤＢ回復ユティリティ５３による回復処理の両方を行うため、更新タイプには“ＬＡ”を指定することになる。
【００３４】
なお、図３の更新処理のステップ４２でのファイル参照マクロの参照タイプに“Ｒ”を指定した後、ステップ４２でファイル更新マクロを発行すると、ＤＢＭＳ１０は、参照タイプに“Ｕ”を指定したときと同様の排他を確保し直す。
ファイル参照マクロを行ったプラグイン関数１９がバッファ領域上のデータを更新し、ファイル更新マクロを発行することでファイル操作１８が起動される。
ファイル操作１８は、ファイル２４へのデータ出力を行うため、ＤＢ領域操作１６を起動する。ＤＢ領域操作１６は、ＯＳ提供のファイルアクセスメソドを使用して、パラメタにより指定されたバッファ領域の内容をパラメタにより指定されたＤＢ領域２１中にあるファイル２４のデータ位置に書き込む。
ファイル更新マクロの戻り値は、更新成功時は“０”値であり、更新失敗時は負値である。
【００３５】
図９は、ファイルクローズマクロの説明図である。
ファイルクローズマクロは、マクロ命令部「ｄｂｆｃｌｏｓｅ」とパラメタ部からなり、パラメタ部には「ファイルオープン時に得たファイルロケータ」を指定する。
ファイル２４に対する参照・更新が完了したプラグイン関数１９がファイルクローズマクロを発行することでファイル操作１８が起動される。ファイル操作１８は、ファイルオープン時に確保した資源を解放してファイル２４をクローズすることによってファイル２４をオープン前の状態に戻す。このとき、キャッシュ上にあるページでオープン中に更新したものはファイル２４に反映する。また、ファイルあるいはページに対して確保した排他は解放しない（トランザクションの終了時に解放する）。
ファイルクローズマクロの戻り値は、クローズ成功時は“０”値であり、クローズ失敗時は負値である。
【００３６】
図１０は、ＤＢ領域２１のバックアップの取得とログファイル２６（ＤＢ領域２１の更新情報）のアンロード処理とＤＢ領域２１の物理的障害に対する回復時のデータの流れを示す説明図である。
ＤＢバックアップユティリティ５１は、ＤＢ領域２１中の表データ２２およびファイル２４を含めたＤＢ領域２１全体の物理的なバックアップ５５を外部記憶媒体に作成する。
ログアンロードユティリティ５２は、ログファイル２６に格納されているＤＢ領域２１の更新情報をログアンロードファイル５７として外部記憶媒体に作成する。
ＤＢ回復ユティリティ５３は、ＤＢ領域２１に物理的障害が発生した場合、前記バックアップ５５とログアンロードファイル５７とを入力としてＤＢ領域２１の内容を障害発生前の状態にする回復処理を行う。
【００３７】
図１１は、ＤＢ領域２１の再編成処理時のデータの流れの説明図である。
ＤＢ再編成ユティリティ６１は、ＤＢ領域２１を入力として、それに含まれている表データ２２の１／２と２／２のデータおよびファイル２４の両方について論理的な内容をアンロードファイル６４として外部記憶媒体に作成するアンロード処理を行う。
ＤＢ再編成ユティリティ６２は、前記アンロードファイル６４を入力として、ＤＢ領域２１に表データ２２のデータおよびファイル２４のデータを格納し直すことによりＤＢ領域２１に格納されている全データについて物理的な格納位置を整えるリロード処理を行う。
【００３８】
以上のリレーショナルデータベースシステム１００によれば、プラグイン関数１９が管理するファイル２４をＤＢＭＳ１０が管理するＤＢ領域２１に作成し、ＤＢＭＳ１０が管理する表データ２２と同時にＤＢＭＳ１０が排他制御を行う。すなわち、ファイル２４についてもＤＢＭＳ１０が排他制御を管理するため、システムとしての信頼性や運用性が高くなり、ユーザの負担が軽くなる。また、ロールバックや回復や再編成に際しても、ファイル２４を特別に意識することなく運用できるため、システムとしての信頼性や運用性が高くなり、ユーザの負担が軽くなる。従って、リレーショナルデータベースと、リレーショナルデータベース管理システムがサポートしていないユーザ定義のデータ型のデータ（のファイル）とを共に管理することが容易になる。
【００３９】
【発明の効果】
本発明のリレーショナルデータベース管理方法およびリレーショナルデータベースシステムによれば、リレーショナルデータベース管理システムがサポートしていないユーザ定義のデータ型のデータ（のファイル）に対しても、排他制御やログ取得が実現できるため、ユーザは信頼性の高いプラグイン関数組込みのデータベースシステムを構築できる。また、既存のプラグイン関数の移植が簡単にできる。
【図面の簡単な説明】
【図１】 本発明の一実施形態にかかるリレーショナルデータベースシステムの構成図である。
【図２】 プラグイン関数がファイルを参照する参照処理の流れ図である。
【図３】 プラグイン関数がファイルを更新する更新処理の流れ図である。
【図４】 ファイル作成コマンドの説明図である。
【図５】 ファイル削除コマンドの説明図である。
【図６】 ファイルオープンマクロの説明図である。
【図７】 ファイル参照マクロの説明図である。
【図８】 ファイル更新マクロの説明図である。
【図９】 ファイルクローズマクロの説明図である。
【図１０】 ＤＢ領域のバックアップの取得とログファイルのアンロード処理とＤＢ領域の物理的障害に対する回復時のデータの流れを示す説明図である。
【図１１】 ＤＢ領域の再編成処理時のデータの流れの説明図である。
【図１２】 ユーザ定義のデータ型の列が存在しないリレーショナルデータベースの例示図である。
【図１３】 ユーザ定義のデータ型の列が存在するリレーショナルデータベースの例示図である。
【図１４】 ユーザ定義のデータ型の文書データをＤＢ領域に格納すると共にその文書データに関する情報をインデクスに追加する動作の説明図である。
【図１５】 インデクスを利用してユーザ定義のデータ型の文書データをＤＢ領域の表から検索する動作の説明図である。
【符号の説明】
９：ＤＢサーバ
１０：リレーショナルデータベース管理システム（ＤＢＭＳ）
１１：トランザクション制御部
１２：ＳＱＬ制御部
１３：データ操作制御部
１４：排他管理部
１５：ログ管理部
１６：ＤＢ領域操作部
１７：プラグイン関数制御部
１８：ファイル操作部
１９：プラグイン関数
２０：磁気ディスク装置
２１：ＤＢ領域
２２：表データ
２３：インデクス
２４：ファイル
２５：磁気ディスク装置
２６：ログファイル
２７：クライアント
２８：アプリケーションプログラム
１００：リレーショナルデータベースシステム[0001]
BACKGROUND OF THE INVENTION
The present inventionRelational database management method and relational database system, relational database management method and relational data management method capable of managing both relational database and user-defined data type data not supported by relational database management systemIt relates to the database system.
[0002]
[Prior art]
SQL (Structured Query Language), which is a database operation language of a relational database, is standardized as an SQL standard by ISO (International Organization for Standardization).
In a relational database management system that supports a relational database, the relational database is supported by a specification based on the SQL standard.
[0003]
As shown in FIG. 12, the relational database is expressed in a table format composed of rows and columns. A column attribute defined in the SQL standard can be defined in the column. Only data that matches the column attribute defined for that column is stored in that column.
In the example of FIG. 12, the column attribute of column 1 is an integer type (INTEGER type), the column attribute of column 2 is a decimal point type (DECIMAL type), and the column attribute of column 3 is a fixed-length character type (CHAR type). The column attribute of column 4 is a variable length character type (VARCHAR type).
[0004]
Now, whenever data with column attributes not defined in the SQL standard (for example, images, audio, documents, graphics, multimedia data, data compressed in various formats, etc.) appear, the standard is specified in the SQL standard. It is complicated and unrealistic. For this reason, the SQL standard function expansion is being studied in SQL3 so that column attribute data not defined in the SQL standard can also be mixed in the same database as the column attribute data defined. That is, according to SQL3, a user can arbitrarily define a data type as a column attribute when defining a table, and can store and access data of the data type defined in the column.
The table in FIG. 13 is an example in which the user defines data types in columns 2 and 4.
[0005]
The addition of rows to the table of FIG. 13 is performed as follows.
(1) The RDBMS is activated when the application program sets data corresponding to each column of the additional row and issues a row addition SQL command (INSERT).
(2) The RDBMS converts the data in the columns 1 and 3 into data in a format that the RDBMS itself stores in the table, and stores the data in the columns 1 and 3 of the additional row (n + 1). For the data in columns 2 and 4, a plug-in function that accesses column 2 specified by the user and a plug-in function that accesses column 4 are activated.
(3) Each activated plug-in function converts the data in column 2 and the data in column 4 into data in a format for storing in a table, and returns to the RDBMS.
(4) The RDBMS stores the data of column 2 and column 4 in column 2 and column 4 of the additional row (n + 1).
[0006]
A row search for the table of FIG. 13 is performed as follows.
(1) The RDBMS is activated when the application program issues a SQL command (SELECT) for extracting a row having a specific value in the data in column 1, for example.
(2) The RDBMS extracts a row having a specified value in the data of the column 1, but since the extracted row includes the column 2 and the column 4, the plug that accesses the column 2 specified by the user. The in function and the plug-in function that accesses the column 4 are activated.
(3) Each activated plug-in function converts the data in column 2 and the data in column 4 into data that can be manipulated by the application program, and returns the data to the RDBMS.
(4) The RDBMS passes the row to the application program.
(5) The above operation is performed for each row to be extracted.
[0007]
As described above, the RDBMS cooperates with a plug-in function in order to realize access to a table including a column of a user-defined data type. That is, the plug-in function refers to a program incorporated in the database management system in order to operate data of a data type defined by the user.
The plug-in function can also create and use information uniquely for efficiently accessing data stored in a user-defined data type column, for example, an index.
Next, the creation and use of an index using a plug-in function will be described. For the sake of simplicity, assume that a table in which column 4 is deleted from the table shown in FIG. It is assumed that certain document data is stored in column 2, and an index related to the document data is created and used.
FIG. 14 shows an operation of storing document data, which is data in a column of a user-defined data type, as document data 74 in column 2 of the table of the DB area (database area) 21 and adding information relating to the document data to the index 24 It is explanatory drawing of.
The index 24 is a data group that cannot be tabular data due to the structure and nature of the index. In other words, the index 24 is a database that is not supported by the database management system 10, that is, a database outside the jurisdiction of the database management system, and is an OS management file that is directly accessed by the plug-in function 19 using a file access method provided by the OS. It is.
(1) The application program 28 sets data corresponding to each column of the additional row, issues an SQL command (INSERT) for adding a row, and starts the RDBMS 10.
(2) The RDBMS 10 converts the data in the columns 1 and 3 into data in a format for the RDBMS 10 itself to store in the table, and stores the data in the columns 1 and 3 of the table in the DB area 21. For the data in column 2, the input document constituting the data and the document number are designated as parameters, and the plug-in function 19 for processing the data in column 2 is activated.
(3) The plug-in function 19 adds document information related to the data in column 2 to the index 24 using the file access method provided by the OS based on the designated parameter. Also, the input document specified by the parameter is converted into a format for storing in the table of the DB area 21 to be document data, and the document data is used as a return value to the DBMS 10.
(4) The DBMS 10 receives the document data as a return value, and stores it as the document data 74 in the column 2 of the table in the DB area 21.
[0008]
FIG. 15 is an explanatory diagram of an operation for searching document data, which is data in a column of a user-defined data type, from the table in the DB area 21 using the index 24.
(1) The application program 28 issues a SQL command (SELECT) specifying a search condition for the column 2 and activates the DBMS 10.
(2) Since the DBMS 10 is a search condition for the column 2 that is a user-defined data type, the plug-in function 19 that processes the data in the column 2 is activated by specifying the search condition as a parameter.
(3) The plug-in function 19 retrieves the index 24 based on the designated parameter, obtains the row number and location information of the data in the column 2 that matches the retrieval condition, and uses this row number and location information. Return to DBMS 10 as a return value.
(4) The DBMS 10 takes out the data in the columns 1 and 3 and the document data 74 satisfying the search condition from the table in the DB area 21 using the received row number and location information. Then, the document data 74 is returned to the plug-in function 19.
(5) The plug-in function 19 converts the document data 74 into data that can be operated by the application program 28, and returns it to the DBMS 10 as a return value.
(6) The DBMS 10 passes the data in columns 1 and 3 and the data returned from the plug-in function 19 to the application program 28.
[0009]
[Problems to be solved by the invention]
As described above, conventionally, data (index 24) having a special structure depending on user-defined data type data can be stored in a database (DB area 21) managed by the database management system (DBMS 10). Since this is not possible, the file is uniquely managed by the plug-in function (plug-in function 19).
[0010]
However, such a management method causes the following problems.
·exclusion control
Even if the file is not managed by the database management system, information that is updated in conjunction with the database managed by the database management system and shared among multiple users is stored. Need to be serialized. However, if exclusive control is performed separately from the database management system, there arises a problem that concurrency decreases. Note that if exclusive control is performed on a part of the file instead of the entire file, the decrease in concurrency can be minimized, but such logic cannot be easily incorporated into the plug-in function.
・ Consistency
When a transaction that updates both a database managed by the database management system and a file that is not managed by the database management system rolls back, the contents of the database are automatically returned to the state at the start of the transaction by the database management system. The database management system does nothing with the file. Therefore, in order to maintain consistency, it is necessary to return the file to the state at the start of the transaction by another means. As this means, a function for returning the file to the state at the start of the transaction may be provided in the plug-in function, but it is not easy to incorporate such logic in the plug-in function. Further, as another means, it is conceivable to manually return the file to the state at the start of the transaction, but this imposes an excessive burden on the user.
・ Disaster recovery
When a physical failure occurs in a database managed by the database management system or a file outside the management of the database management system, recovery is performed by each backup. At this time, for the database, the update information acquired by the database management system can be used to recover to the state immediately before the occurrence of the failure, but the database management system has not acquired the update information for the file. By dropping the backup, it just returns to the state at the time of backup acquisition. Therefore, in order to ensure consistency between the database and the file, it is necessary to restore the file to a state immediately before the occurrence of the failure by another means. As this means, a function for recovering the file to the state immediately before the occurrence of the failure may be provided in the plug-in function, but it is not easy to incorporate such logic in the plug-in function. As another means, it may be possible to manually restore the file to the state immediately before the occurrence of the failure, but this imposes an excessive burden on the user.
[0011]
After all, conventionalrelationalIn the database management method, in order not to impair the reliability and operability of the system, the burden on the user becomes heavy,It is difficult to manage both relational databases and user-defined data types that are not supported by relational database management systemsThere was a problem.
Therefore, the object of the present invention is toRelational database management method and relational database capable of managing both relational database and user-defined data type data not supported by relational database management systemTo provide a system.
[0012]
[Means for Solving the Problems]
In the first aspect, the present invention has a function of incorporating a data type definition by a user and a plug-in function for performing an operation on the data of the user-defined data type.And relational databases that manage relational databases represented in tabular formThe databasemanagementsystemRelational database management methodInSaidThe file used by the plug-in functionRelationalDatabase area for storing data managed by the database management systemBased on the data type definition sent to the plug-in function inThe plug-in function creates and accesses the filerelationalIssuing a file operation macro provided by the database management system,relationalThe database management system executes the issued file operation macro and performs processing on the file.According to the relational database management systemIt is characterized by exclusive controlrelationalProvide a database management method.
According to the first aspectrelationalIn the database management method, a file that is managed by a plug-in function to manipulate data of a user-defined data type.Le, In the database area managed by the database management system, Based on the data type definition sent to the plug-in functionCreate and file thatRelational databaseAt the same time, the database management system now performs exclusive control. As a result, the exclusive control is managed by the database management system, so the reliability and operability of the system is increased, and the burden on the user is reduced.It becomes easy to manage both a relational database and data (files) of user-defined data types not supported by the relational database management system.
[0013]
In a second aspect, the present invention is according to the first aspect.relationalIn the database management method, when the plug-in function updates the file, the update information of the file is output,relationalThe databaseToWhen the accessed transaction is rolled back, the file is updated using the update information.And the relational databaseIt is characterized by recovering to the state at the start of the transactionrelationalProvide a database management method.
According to the second aspectrelationalIn the database management method, if the transaction is rolled backToFiles managed by plug-in functions to manipulate data of user-defined data typesLeSince the file can be recovered from the update information,Relational database and data of user-defined data type not supported by relational database management system (file)Can be restored to a state in which they are consistent with each other. As a result, with regard to rollback, the reliability and operability of the system is increased, and the burden on the user is reduced.It becomes easy to manage both a relational database and data (files) of user-defined data types not supported by the relational database management system.
[0014]
In a third aspect, the present invention is according to the first aspect.relationalIn the database management method,relationalStored in the database arearelationalThe data managed by the database management system and the file are output to an external storage device to create a backup, and when the plug-in function updates the file, the update information of the file is output to a log file. The update information extracted from the backup and the log filerelationalData dataWhenThe fileWhenCharacterized by recoveringrelationalProvide a database management method.
According to the third aspectrelationalIn the database management method, a file managed by a plug-in function to operate user-defined data types by using the utility provided by the database management system in the event of a failure.LeSince the file can be recovered from backup and update information,Relational database and data of user-defined data type not supported by relational database management system (file)Can be restored to a state in which they are consistent with each other. As a result, regarding the failure, the reliability and operability of the system will increase, reducing the burden on the user,It becomes easy to manage both a relational database and data (files) of user-defined data types not supported by the relational database management system.
[0015]
In a fourth aspect, the present invention is according to the first aspect.relationalIn the database management method,relationalStored in the database arearelationalManaged by database management systemRelationaldatabaseAnd output the contents of the file to an external storage device, and re-register the output contents.relationaldatabaseAnd reorganizing the contents of the filerelationalProvide a database management method.
According to the fourth aspectrelationalIn the database management method, for example, when fragmentation occurs, a file that is managed by a plug-in function to operate data of a user-defined data type by using a utility provided by the database management system.LeSince the contents of the file can be reorganized from the contents output to the external storage device, the fragmentation can be eliminated. As a result, the reliability and operability of the system is improved, and the burden on the user is reduced.It becomes easy to manage both a relational database and data (files) of user-defined data types not supported by the relational database management system.
[0016]
In a fifth aspect, the present invention provides:A relational database represented in tabular form;A function that incorporates a user-defined data type definition and a plug-in function that performs operations on the user-defined data type data.Relational database management system for managing the relational databaseIn the database system,SaidDatabase management systemSaidDatabase area for storing data managed by the plug-in functionBased on the data type definition sent to the plug-in function inWhen the plug-in function issues and issues a file operation macro provided by itself to the self, the file operation macro is executed to access the file and perform exclusive control on the file. TorelationalProvide a database system.
According to the fifth aspectrelationalIn a database system, files managed by plug-in functions to manipulate data of user-defined data typesLe, In the database area managed by the database management system, Based on the data type definition sent to the plug-in functionmake,The file is a relational databaseAt the same time, the database management system now performs exclusive control. As a result, the exclusive control is managed by the database management system, so the reliability and operability of the system is increased, and the burden on the user is reduced.It becomes easy to manage both a relational database and data (files) of user-defined data types not supported by the relational database management system.
[0017]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. Note that the present invention is not limited thereby.
FIG. 1 shows an embodiment of the present invention.relationalIt is a block diagram of a database system.
thisrelationalThe database system 100A relational database constructed as table data 22 in the DB area 21 of the magnetic disk device 20 and a relational database management system for managing the relational database.The DB server 9 including the DBMS 10 and the plug-in function 19, the client 27 that executes the application program 28 and requests the DBMS 10 to execute the SQL command processing, the console 30 on which the user performs an operation such as command input, and the like And a network 29 to be connected.
[0018]
A DB area 21 managed by the DBMS 10 is allocated to the magnetic disk device 20 connected to the DBMS 10. In the DB area 21, the DBMS 10 operates directly.relationalTable data 22 which is a databaseWhen,Plug-in function 19 for manipulating user-defined data type directly manipulatesDataFile 24WhenIs stored.
The file 24 is created when a user inputs a file creation command (FIG. 4) from the console 30, and is deleted when a file deletion command (FIG. 5) is entered.
[0019]
Further, the magnetic disk device 25 connected to the DBMS 10 stores a log file 26 that is update information of the table data 22 and the file 24.
[0020]
The DBMS 10 receives a request from the SQL control 12, a transaction control 11 that controls a transaction, a SQL control 12 that analyzes a SQL command received by the transaction control 11 and controls execution of a database operation, and receives table data 22 The data operation 13 for performing the above operation, the plug-in function control 17 for controlling the plug-in function 19, the file operation 18 for receiving a file operation request from the plug-in function 19, and the consistency of the table data 22 and the file 24 are maintained. Exclusive management 14 for performing exclusive management, log management 15 for outputting update information to the log file 26 when the table data 22 and the file 24 are updated, and the data operation 13 refer to / update the table data 22 File operation 18 references / updates file 24 It has and a DB area operation 16 for operating the DB area 21 in order.
[0021]
FIG. 2 is a flowchart of a reference process in which the plug-in function 19 refers to the file 24.
This reference processing is started through the plug-in function control 17 by the DBMS 10 that has received an SQL command for accessing the table data 22 in which a column of a user-defined data type exists from the data application program 28.
In step 31, the plug-in function 19 opens the file 24 for reference.
In step 32, the position and length are specified, and the target data of the file 24 is read into the buffer. In the case of this reference reading, the exclusion management 14 of the DBMS 10 secures a reference exclusion for the storage page of the target data.
In step 33, the target data on the buffer is referred to.
In step 34, it is determined whether or not all the target data has been referred to. If there is still data, the process returns to step 32, and if all have been referred to, the process proceeds to step 35.
In step 35, the file 24 is closed. Then, the reference process ends.
[0022]
FIG. 3 is a flowchart of the update process in which the plug-in function 19 updates the file 24.
This update process is activated through the plug-in function control 17 by the DBMS 10 that has received from the data application program 28 an SQL command for accessing the table data 22 in which a column of a user-defined data type exists.
In step 41, the plug-in function 19 opens the file 24 for update.
In step 42, the position and length are specified, and the target data of the file 24 is updated and read onto the buffer. In the case of this update reading, the exclusion management 14 of the DBMS 10 secures the exclusion for updating the storage page of the target data.
In step 43, the target data on the buffer is referred to.
In step 44, it is determined whether or not the target data should be updated. If so, the process proceeds to step 45. If no update is required, the process proceeds to step 47.
In step 45, the contents of the target data on the buffer are updated.
In step 46, the updated target data on the buffer is written to the file 24. At this time, the log management 15 of the DBMS 10 outputs the contents before and after the update of the file 24 to the log file 26 as update information.
In step 47, it is determined whether or not all the target data has been updated. If there is any remaining data, the process returns to step 42, and if all have been updated, the process proceeds to step 48.
In step 48, the file 24 is closed. Then, the update process ends.
[0023]
In the reference processing and update processing, when the plug-in function 19 issues a macro to be used for the file 24 such as open / read / write / close, control is transferred to the file operation 18 of the DBMS 10.
The file operation 18 of the DBMS 10 checks the type of macro for the file 24, executes a process corresponding to the macro, and then makes a request corresponding to the macro request to the file access method provided by the OS.
[0024]
FIG. 4 is an explanatory diagram of a file creation command.
The file creation command includes a command part “dbfmake” and a parameter part. The parameter part includes “name of the DB area 21 storing the file 24 to be created / name of the file 24 to be created” and “capacity of the file 24 to be created. "Is specified.
When this file creation command is input from the console 30 to the DBMS 10, the file operation 18 is activated, and the file 24 is created in the DB area 21 via the DB area operation 16.
[0025]
FIG. 5 is an explanatory diagram of a file deletion command.
The file deletion command includes a command part “dbremove” and a parameter part. The parameter part designates “the name of the DB area 21 in which the file 24 to be deleted / the name of the file 24 to be deleted”.
When this file deletion command is input from the console 30 to the DBMS 10, the file operation 18 is activated, and the file 24 in the DB area 21 is deleted via the DB area operation 16.
[0026]
FIG. 6 is an explanatory diagram of a file open macro.
The file open macro includes a macro instruction part “dbfopen” and a parameter part. The parameter part includes “name of the DB area 21 storing the file 24 to be opened / name of the file 24 to be opened” and “suitable for the purpose of use. "Open type to achieve exclusive control" is specified.
In the open type, “EX” (exclusive update) for referencing / updating the file 24 without allowing other users to refer / update, and for referencing / updating the file 24 while permitting other users to refer / update. "SU" (shared update), "PU" (protection update) for referencing / updating the file 24 while allowing only other users to refer to it, and referencing the file 24 while allowing other users to refer to / update. There are five types: “SR” (shared reference) for reference and “PR” (protection reference) for referring to the file 24 while allowing only reference from other users.
For example, the open type “SR” is designated in step 31 of the reference process in FIG. 2, and the open type “SU” is designated in step 41 of the update process in FIG.
Table 1 shows the relationship between the open type and the exclusive unit at the time of reference update. Table 2 shows the possibility of simultaneous execution of the open type.
[0027]
[Table 1]
[0028]
[Table 2]
[0029]
The file open macro returns a file locator as a return value. In subsequent file operations, a file locator is specified as a macro parameter.
When the plug-in function 19 activated by the plug-in function control 17 of the DBMS 10 issues a file open macro during SQL execution, the file operation 18 is activated, and the file operation 18 activates the exclusive management 14 and follows the open type. Ensure exclusion.
The return value of the file open macro is a file locator (positive value) when the open is successful, and a negative value when the open fails.
The opened file is brought into a closed (unopened) state when the file close macro (FIG. 9) or the transaction ends.
[0030]
FIG. 7 is an explanatory diagram of a file reference macro.
The file reference macro includes a macro instruction part “dbread” and a parameter part. The parameter part includes “address of input buffer area for receiving data”, “position of target data on file 24”, “data length”, “DBMS10”. Specifies the "reference type for performing appropriate exclusive control for each reference purpose" and "file locator obtained when opening the file".
There are two types of reference: “R” for reference only and “U” for updating the data and reflecting it in the file.
For example, the reference type “R” is designated in step 32 of the reference process of FIG. 2, and the reference type “U” is designated in step 42 of the update process of FIG.
Table 3 shows the relationship between the open type and the reference type to be secured.
[0031]
[Table 3]
[0032]
The file operation 18 is activated when the plug-in function 19 that has opened the file issues a file reference macro. The file operation 18 activates the exclusion management 14 and secures or does not perform exclusion on the page in which the target data is stored according to the open type and the reference type. Thereafter, the file operation 18 activates the DB area operation 16. The DB area operation 16 reads the page (content) of the data position of the file 24 in the DB area 21 specified by the parameter using the file access method provided by the OS, and holds it in the buffer area for receiving data. To do.
The return value of the file reference macro is a “0” value when the reference is successful, and a negative value when the reference fails.
[0033]
FIG. 8 is an explanatory diagram of a file update macro.
The file update macro includes a macro instruction part “dbfwrite” and a parameter part. The parameter part includes “address of buffer area where data to be output to the file 24 is set” “position of target data on the file 24” “data length” “Specify the update type for instructing the method of acquiring update information (log) performed by the DBMS 10 when updating the file” and “the file locator obtained when the file is opened”.
The update type includes “LA” in which the DBMS 10 acquires the pre-update and post-update logs for the update target portion, “LB” in which only the pre-update log is acquired, and “LF” in which only the post-update log is acquired. There are four types of “NL” that do not acquire the log of the updated part, and specify the log acquisition method that matches the file recovery operation method and the update processing method of the plug-in function 19 when the failure occurs with the update type Can do.
For example, in step 46 of the update process of FIG. 3, since both rollback and recovery process by the DB recovery utility 53 are performed, “LA” is designated as the update type.
[0034]
When “R” is designated as the reference type of the file reference macro in step 42 of the update process of FIG. 3 and then the file update macro is issued in step 42, the DBMS 10 designates “U” as the reference type. Secure the same exclusion as.
The plug-in function 19 that has performed the file reference macro updates the data in the buffer area, and issues a file update macro to activate the file operation 18.
The file operation 18 activates the DB area operation 16 in order to output data to the file 24. The DB area operation 16 uses the file access method provided by the OS to write the contents of the buffer area specified by the parameter to the data position of the file 24 in the DB area 21 specified by the parameter.
The return value of the file update macro is a “0” value when the update is successful, and a negative value when the update fails.
[0035]
FIG. 9 is an explanatory diagram of a file close macro.
The file close macro includes a macro instruction part “dbfclose” and a parameter part, and “file locator obtained when the file is opened” is designated in the parameter part.
The file operation 18 is activated when the plug-in function 19 that has completed the reference / update to the file 24 issues a file close macro. The file operation 18 returns the file 24 to the state before opening by releasing the resources secured when the file is opened and closing the file 24. At this time, a page on the cache that is updated while being opened is reflected in the file 24. Also, the exclusion secured for the file or page is not released (released at the end of the transaction).
The return value of the file close macro is “0” when close is successful, and is negative when close is unsuccessful.
[0036]
FIG. 10 is an explanatory diagram showing the flow of data at the time of recovery for a physical failure in the DB area 21, acquisition of backup of the DB area 21, unload processing of the log file 26 (update information of the DB area 21).
The DB backup utility 51 creates a physical backup 55 of the entire DB area 21 including the table data 22 and the file 24 in the DB area 21 on an external storage medium.
The log unload utility 52 creates update information of the DB area 21 stored in the log file 26 on the external storage medium as a log unload file 57.
When a physical failure occurs in the DB area 21, the DB recovery utility 53 performs a recovery process in which the backup 55 and the log unload file 57 are input and the contents of the DB area 21 are in a state before the failure occurs.
[0037]
FIG. 11 is an explanatory diagram of the flow of data during the reorganization process of the DB area 21.
The DB reorganization utility 61 receives the DB area 21 as an input, and externally stores the logical contents of both the data 1/2 and 2/2 of the table data 22 included in the DB area 21 and the file 24 as an unload file 64. Unload processing to be created on the medium.
The DB reorganization utility 62 receives the unload file 64 as an input, and stores the data of the table data 22 and the data of the file 24 in the DB area 21 so that all data stored in the DB area 21 are physically stored. Reload processing to adjust the storage position.
[0038]
More thanrelationalAccording to the database system 100, the file 24 managed by the plug-in function 19 is created in the DB area 21 managed by the DBMS 10, and the DBMS 10 performs exclusive control simultaneously with the table data 22 managed by the DBMS 10. That is, since the DBMS 10 manages exclusive control for the file 24 as well, the reliability and operability of the system is improved, and the burden on the user is reduced.TheIn addition, since the file 24 can be operated without special awareness during rollback, recovery, and reorganization, the reliability and operability of the system is improved, and the burden on the user is reduced.The Therefore, it becomes easy to manage both the relational database and the user-defined data type data (file) not supported by the relational database management system.
[0039]
【The invention's effect】
Of the present inventionrelationalDatabase management method andrelationalAccording to the database systemEven for user-defined data types (files) that are not supported by the relational database management system,Since exclusive control and log acquisition can be realized, the user can construct a highly reliable database system incorporating a plug-in function. Also, existing plug-in functions can be ported easily.
[Brief description of the drawings]
1 is an embodiment of the present invention.relationalIt is a block diagram of a database system.
FIG. 2 is a flowchart of a reference process in which a plug-in function refers to a file.
FIG. 3 is a flowchart of an update process in which a plug-in function updates a file.
FIG. 4 is an explanatory diagram of a file creation command.
FIG. 5 is an explanatory diagram of a file deletion command.
FIG. 6 is an explanatory diagram of a file open macro.
FIG. 7 is an explanatory diagram of a file reference macro.
FIG. 8 is an explanatory diagram of a file update macro.
FIG. 9 is an explanatory diagram of a file close macro.
FIG. 10 is an explanatory diagram showing a data flow during DB area backup acquisition, log file unload processing, and recovery for a physical failure in the DB area;
FIG. 11 is an explanatory diagram of a data flow at the time of DB area reorganization processing;
FIG. 12: User-defined data type column does not existrelationalIt is an illustration figure of a database.
FIG. 13: User-defined data type column existsrelationalIt is an illustration figure of a database.
FIG. 14 is an explanatory diagram of an operation of storing document data of a user-defined data type in a DB area and adding information related to the document data to an index.
FIG. 15 is an explanatory diagram of an operation of searching for document data of a user-defined data type from a table in a DB area using an index.
[Explanation of symbols]
9: DB server
10:relationalDatabase management system (DBMS)
11: Transaction control unit
12: SQL control unit
13: Data operation control unit
14: Exclusive management department
15: Log management department
16: DB area operation unit
17: Plug-in function controller
18: File operation section
19: Plug-in function
20: Magnetic disk device
21: DB area
22: Table data
23: Index
24: File
25: Magnetic disk device
26: Log file
27: Client
28: Application program
100:relationalDatabase system
Claims (5)
前記プラグイン関数が使用するファイルを、前記リレーショナルデータベース管理システムの管理するデータを格納するデータベース領域に前記プラグイン関数に対して送られたデータ型の定義に基づいて作成し、
前記ファイルに対するアクセスは前記プラグイン関数が前記リレーショナルデータベース管理システムの提供するファイル操作マクロを発行して行い、
前記リレーショナルデータベース管理システムは前記発行されたファイル操作マクロを実行するとともに前記ファイルに対して前記リレーショナルデータベース管理システムによる排他制御を行うことを特徴とするリレーショナルデータベース管理方法。 Possess the ability to incorporate a plug-in functions to perform operations data types defined for the data of the user-defined data types by the user, in a relational database management method in a relational database management system for managing a relational database represented in tabular form ,
The file in which the plug-in function is used, prepared on the basis of transmitted data type defined for the plug-in function in the database area which stores data managed by the relational database management system,
Access to the file is performed by issuing a file operation macro provided by the relational database management system by the plug-in function,
The relational database management method and performing exclusive control by the relational database management system to the file with a relational database management system to perform file operations macros said issued.
前記データベース管理システムは、前記プラグイン関数が使用するファイルを自己の管理するデータを格納するデータベース領域に前記プラグイン関数に対して送られたデータ型の定義に基づいて作成し、自己の提供するファイル操作マクロを前記プラグイン関数が自己に対して発行すると、そのファイル操作マクロを実行して前記ファイルに対するアクセスを行うと共に前記ファイルに対して排他制御を行うことを特徴とするリレーショナルデータベースシステム。 A relational database represented in tabular form, and a relational database management system have a function that incorporates the plug-in functions to perform operations data types defined for the data of the user-defined data types by the user to manage the relational database In relational database system including
Said database management system, the created based on file plugin function is used to define the data type sent to the plug-in function in the database area which stores data managed by own, providing the self When the file operation macro said plug-in function issued to self, relational database system and performs exclusive control on the file with and executes the file operation macro performs an access to the file.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP04326197A JP3709510B2 (en) | 1997-02-27 | 1997-02-27 | Relational database management method and relational database system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP04326197A JP3709510B2 (en) | 1997-02-27 | 1997-02-27 | Relational database management method and relational database system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10240586A JPH10240586A (en) | 1998-09-11 |
| JP3709510B2 true JP3709510B2 (en) | 2005-10-26 |
Family
ID=12658917
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP04326197A Expired - Fee Related JP3709510B2 (en) | 1997-02-27 | 1997-02-27 | Relational database management method and relational database system |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3709510B2 (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7117197B1 (en) * | 2000-04-26 | 2006-10-03 | Oracle International Corp. | Selectively auditing accesses to rows within a relational database at a database server |
-
1997
- 1997-02-27 JP JP04326197A patent/JP3709510B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10240586A (en) | 1998-09-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6062855B2 (en) | MySQL database-heterogeneous log-based replication | |
| US7257595B2 (en) | Transactional file system | |
| US6088694A (en) | Continuous availability and efficient backup for externally referenced objects | |
| US6014674A (en) | Method for maintaining log compatibility in database systems | |
| US6564215B1 (en) | Update support in database content management | |
| US10642696B2 (en) | Copying compressed pages without uncompressing the compressed pages | |
| JP4912026B2 (en) | Information processing apparatus and information processing method | |
| US20060129618A1 (en) | Method and a computer system for synchronising backups of objects and of meta data about the objects | |
| CN105556520A (en) | Mirroring, in memory, data from disk to improve query performance | |
| CN105556519A (en) | Multi-version concurrency control on in-memory snapshot store of ORACLE in-memory database | |
| JP2001511552A (en) | Database Method | |
| JP2002519765A (en) | High-speed storage resident processing method and processing system for transaction data | |
| US20050125458A1 (en) | Chronological data record access | |
| US7188124B2 (en) | Method, system, computer product for recovering dropped database table specifying one or more table spaces, recovering the table space being restored using the dropped table history data structure | |
| US11947823B2 (en) | System and methods for providing a memory slice data structure for use with diverse memory and storage media | |
| US7194486B2 (en) | Method and system for data processing with data replication for the same | |
| JP3709510B2 (en) | Relational database management method and relational database system | |
| US7693883B2 (en) | Online data volume deletion | |
| JP2004062759A (en) | Database log management method, its device and its program | |
| JP2002116939A (en) | Distributed database system | |
| JP4306023B2 (en) | Storage method and apparatus for transaction processing, transactional storage | |
| Vassilakis et al. | Transaction support in a temporal DBMS | |
| KR20030095704A (en) | Method of management for the spatial database | |
| JP2004302919A (en) | Replication system and program therefor | |
| Berkeley | Oracle Berkeley DB |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040413 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040609 |
|
| 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: 20050726 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050727 |
|
| 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: 20080819 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090819 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100819 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100819 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110819 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120819 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130819 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |