JP4467257B2

JP4467257B2 - データベース管理方法および装置並びにその処理プログラム

Info

Publication number: JP4467257B2
Application number: JP2003177458A
Authority: JP
Inventors: 孝板谷; 茂人平賀
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2002-06-28
Filing date: 2003-06-23
Publication date: 2010-05-26
Anticipated expiration: 2023-06-23
Also published as: US7831618B2; JP2004086872A; US7127462B2; US20070038631A1; US20040054922A1

Description

【０００１】
【発明の属する技術分野】
本発明はデータベースのアクセス権限を管理するデータベース管理技術に関する。
【０００２】
【従来の技術】
データベースのアクセス権限を管理するデータベース管理システムにおいて、データベースへのアクセス権限は、データベース所有者及びデータベース所有者からアクセス権限を許可された者が持つことができ、テーブル毎やユーザ毎のデータベースへのアクセス権限の設定や管理を行うためには極めて有用である。
【０００３】
しかし、更新を不可としたいデータベースに対して、所有者や更新権限を許可された者またはこれらの者になりすました者が、不正にまたは誤って更新されてしまうことがある。分散データベースにおけるデータベースへの不正なアクセスを防止しようとする技術として、特許文献１のような技術が開示されている。
【０００４】
【特許文献１】
米国特許5,924,094号
【０００５】
【発明が解決しようとする課題】
従来の技術においては、更新を不可としたいデータに対して、表所有者や更新権限を譲渡された者またはこれらの者になりすました者が、不正にまたは誤って更新することを防ぐことはできないという課題があった。
【０００６】
本発明の目的は、改竄防止属性が設定された場合、不正にまたは誤ってデータベースへの処理が実行されることを防ぐことにある。
【０００７】
【課題を解決するための手段】
本発明は、データベース定義時に改竄防止属性を指定した場合に、データベースの属性としてディクショナリに登録し、データ更新要求時にデータベースの属性をチェックし、当該データベースが改竄防止属性有りの場合は、データベースの所有者であっても表の変更を不可とする。これにより、不正にまたは誤って表データを更新することを防ぐことが可能となる。
【０００８】
また、データベース定義時に改竄防止属性に加え行削除禁止期間及び行挿入日時保持列名を指定した場合、これらの情報をデータベースの属性としてディクショナリに登録し、行挿入時に行挿入日時保持列にデータベース管理システムが行挿入日時を設定し、データベース所有者またはデータベース所有者から表更新権限を譲渡された者であっても当該列データを更新不可とする。そして、行削除要求時に表の属性及び行挿入日時をチェックし、当該データベースが改竄防止属性を持ち、かつ、行削除禁止期間を指定されている場合は、行挿入後、行削除禁止期間を経過するまでの間は、データベース所有者であっても行の削除を不可とすることが可能となる。これにより、データが挿入された日より一定の期間すなわち行削除禁止期間で指定した期間、当該データの削除を禁止することが可能となる。
【０００９】
さらに、データベースのアクセス制御情報が格納されているディクショナリに登録した改竄防止属性情報を参照することで、データベース定義削除又はデータベース定義変更によるデータの不正削除・更新を防ぐことが可能となる。
【００１０】
さらに、アンロード日時をステータスファイル及び外部記憶媒体に記録し、ディクショナリに登録した改竄防止属性情報を参照することで、リロード時に不正に改竄防止属性有りのデータを削除又は更新することを防ぐことが可能となる。
【００１１】
【発明の実施の形態】
以下、本発明の一実施例を図１から図１０を参照しながら説明する。
【００１２】
本発明に係わるデータベース管理方法及び装置を図１に示す。データベース管理システムは、ＣＰＵ、メモリ、端末装置、ハードディスク装置等から構成される電子計算機システムにおいて、オペレーティングシステム上で動作し、論理的なデータベース格納領域及び表や格納領域の定義情報を格納するディクショナリは、ハードディスク装置上に割り当てられる。
【００１３】
ディクショナリは、データベースのテーブル構造、列定義、インデクス定義などを含むデータベース設計仕様を格納するものであり、データベース参照・更新時にディクショナリの情報が必要となる。本発明の特徴となる改竄防止情報を管理するディクショナリ表は、表名列、改竄防止属性列、行削除禁止期間列、行挿入日時保持列名列から構成され、ディクショナリに格納される。このディクショナリ表は、図２における２０２に相当する。本発明はリレーショナル・データベースを一例に説明しているがリレーショナル・データベースに限定されることなく種々のデータベースに適用可能である。ここでは、改竄防止とは、データベース所有者およびデータベース所有者から権限を許可されたものについてもデータベースに登録済みのデータの変更を許可しないアクセス権限の機能をいう。この改竄防止属性は、データベース所有者およびデータベース所有者から権限を許可されたものでは変更不可能であり、更に上位のデータベース管理者のレベルでないと変更はできない。
【００１４】
図２は、本発明の特長を表す表定義文の一例と、改竄防止定義情報がディクショナリに格納されている様子を示す図である。ＳＱＬ１に示す表１及びＳＱＬ２に示す表２は、２０１に示すパラメタ名Ｐ１にＹを指定することで、改竄防止属性有りの表となり、ディクショナリ２０２の改竄防止属性列にその旨を示す「Ｙ」が格納される。また、表２には改竄防止属性に加え、２０１に示すパラメタ名Ｐ２に行削除禁止期間を指定し、かつ２０１に示すパラメタ名Ｐ３に行挿入日時保持列を指定することで、行挿入後、削除禁止期間を経過した行のみ削除可能となる表となり、ディクショナリの行削除禁止期間列及び行挿入日時保持列名列に各々指定された値が格納される。本例では、リレーショナルデータベースの例で説明したので行挿入、行削除の例を説明したが、データベース一般にはデータの挿入、削除についても同様にデータの挿入は許可するがデータの削除は禁止することになる。なお、図２においてはパラメタＰ３をユーザ設定とする例としているが、ユーザ設定とはせずシステムで暗黙的に自動設定とすることも可能である。
【００１５】
表データ更新不可・行削除不可の表を定義する場合のＳＱＬの一例がＳＱＬ１である。ＳＱＬ１で定義される表１は、行挿入および検索（もしくは参照）は可能であるが、表データ更新および行削除は不可の表となる。一方、表データ更新不可である点はＳＱＬ１と同様であるが、挿入後、一定期間を経過した行に限り削除可能となるオプションを指定したＳＱＬの一例がＳＱＬ２である。このＳＱＬ例では、行挿入後、３年を経過した行に限り削除可能となる。ＳＱＬ２で定義される表２は、行挿入・検索は可能、表データ更新は不可である点は表１と同様であるが、行挿入後、一定期間を経過した行については削除可能となる点が表１とは異なる。ＳＱＬ２のＳＱＬ例では、行削除禁止期間に「３ＹＥＡＲＳ（３年）」を指定し、行挿入履歴保持列名として「カルテ作成日」を指定している。これにより、表２に行挿入時、行挿入日時が「カルテ作成日」にシステムにより自動的に格納され、表２の行削除要求時、「カルテ作成日」に格納された行挿入日時に３年を加算した結果と行削除要求日時とを比較し、削除しようとする行が挿入後３年を経過した行であれば削除可能となる。データベースに設定されたこれらの属性は、当該データベースの所有者やその権限を許可されたものでは変更することができない。つまり、一度設定されると、当該データベースの所有者やその権限を許可されたものでは変更することができないことになる。このようにすることにより、データベースが不正にまたは誤って変更されることを防ぐ。
【００１６】
図３は、表に対するデータ挿入処理の流れを示す図である。表に対しデータを挿入する場合、まず改竄防止属性有りの表か否かをチェックし（３０１）、改竄防止属性無しの場合はそのままデータ挿入処理を実行する（３０４）。３０１で改竄防止属性有りの表の場合は、行削除禁止期間の指定が有るか否かチェックし（３０２）、行削除禁止期間の指定が無い場合はデータ挿入処理を実行する。３０２で行削除禁止期間の指定が有る場合は、行挿入履歴保持列に格納するデータ（時刻印）を作成後、データ挿入処理を実行する。ここで、行挿入履歴保持列に格納するデータをユーザが指定することはできない。例え指定されていたとしても、指定値を無視し、システムが作成したデータを格納する。具体例としては、図４の表２は、「カルテＩＤ」列が「００１」の行を２００２年６月１日に挿入し、同様に「カルテＩＤ」列が「００２」の行を２００２年６月１０日に挿入、「カルテＩＤ」列が「００３」の行を２００２年６月１８日に挿入した場合の例である。
【００１７】
図２で定義した表１及び表２にデータ挿入後、表データの更新ＳＱＬ及び行削除ＳＱＬを実行した場合の例を図４に示す。ここで、ＳＱＬ１は表１のある行に対する更新を指示するＳＱＬ、ＳＱＬ２は表１のある行の削除を指示するＳＱＬ、ＳＱＬ３は表２のある行に対する更新を指示するＳＱＬ、ＳＱＬ４は表２の「カルテＩＤ」列の値が「００１」である行の削除を指示するＳＱＬである。改竄防止属性有りの表１又は表２に対し、表データ更新を指示するＳＱＬ（ＳＱＬ１又はＳＱＬ３）を実行した場合、データベース管理システムはＵＰＤＡＴＥ不可の旨を示す情報をＵＡＰに返す（４０１）。行削除禁止期間指定無しの表１に対し、行削除を指示するＳＱＬ（ＳＱＬ２）を実行した場合、データベース管理システムはＤＥＬＥＴＥ不可の旨を示す情報をＵＡＰに返す。行削除禁止期間有りの表２に対し、行削除を指示するＳＱＬ（ＳＱＬ４）を実行した場合、削除対象の行が行削除禁止期間経過前であればデータベース管理システムはＤＥＬＥＴＥ不可の旨をＵＡＰに返し、削除対象の行が行削除禁止期間経過後であればデータベース管理システムはＤＥＬＥＴＥ処理を実施する。
【００１８】
図５は、表データの更新処理の流れを示す図である。表データ更新要求があった場合、まず改竄防止属性有りの表か否かをチェックし（５０１）、改竄防止属性無しの場合は表データ更新実行者が表の所有者か否かチェックし（５０２）、表の所有者であれば更新処理を実行する（５０４）。５０２で表の所有者でない場合は、表データ更新実行者が表の所有者から当該表に対する更新権限を譲渡されているかチェックし（５０３）、譲渡されていれば更新処理を実行し（５０４）、譲渡されていなければ更新不可とする（５０５）。一方、５０１で改竄防止属性有りの場合は、例え表の所有者であったとしても更新不可となる（５０６）。具体例として、図４のＳＱＬ１及びＳＱＬ３のＳＱＬ例では、５０１のチェックでＹＥＳとなり、更新不可となる。
【００１９】
図６は、行削除処理の流れを示す図である。行削除要求があった場合、まず改竄防止属性有りの表か否かをチェックし（６０１）、改竄防止属性無しの場合は行削除実行者が表の所有者か否かチェックし（６０２）、表の所有者であれば行削除処理を実行する（６０４）。６０２で表の所有者でない場合は、行削除実行者が表の所有者から当該表に対する行削除権限を譲渡されているかチェックし（６０３）、譲渡されていれば更新処理を実行し（６０４）、譲渡されていなければ行削除不可とする（６０５）。一方、６０１で改竄防止属性有りの場合は、次に行削除禁止期間指定有りの表か否かをチェックし（６０６）、行削除禁止期間の指定が無しであれば、例え表の所有者であったとしても削除不可となる（６０８）。６０６で行削除禁止期間の指定が有りの場合は、削除対象の行中の行挿入日時保持列の値に行削除禁止期間列の値を加算し行削除実行日と比較することで、削除禁止期間を経過した行か否かをチェックし（６０７）、削除禁止期間を経過した行であれば６０２の処理に分岐し、削除禁止期間を経過していない行であれば行削除不可とする（６０８）。具体例として、図４のＳＱＬ２のＳＱＬ例では、６０１でＹＥＳ、６０６でＮＯとなり、行削除不可となり、ＳＱＬ３のＳＱＬ例では、６０１でＹＥＳ、６０６でＹＥＳ、６０７の判定で削除禁止期間を経過後の行ではＹＥＳとなり表所有者又は表所有者から削除権限を譲渡されている者であれば行削除可、削除禁止期間を経過前の行ではＮＯとなり行削除不可となる。
【００２０】
図７は、表定義の削除処理の流れを示す図である。表定義削除要求があった場合、まず改竄防止属性有りの表か否かをチェックし（７０１）、改竄防止属性無しの場合は表定義削除実行者が表の所有者又はＤＢＡ権限者か否かをチェックし（７０２）、表の所有者又はＤＢＡ権限者であれば表定義削除処理を実行する（７０３）。ここでの「ＤＢＡ権限者」とは、データベース管理システムにおける管理者権限を持つユーザのことである。通常、データベース管理システムにおいては、「ＤＢＡ権限者」と「一般利用者」に大別され、ＤＢＡ権限者は一般利用者には利用できないデータベースを管理する機能を利用することが可能である。７０２で表の所有者又はＤＢＡ権限者でない場合は、表定義削除不可となる（７０４）。一方、７０１で改竄防止属性有りの表の場合は、表にデータがあるか否かをチェックし（７０５）、表にデータが有る場合は、例え表の所有者又はＤＢＡ権限者であったとしても表定義削除不可となる（７０６）。７０５で表にデータが１件も無い場合は、７０２に分岐する。具体例として、図４の表１・表２に対する表定義削除要求があった場合を考える。この場合、７０１でＹＥＳ、７０５でＹＥＳとなり表定義削除不可となる。
【００２１】
図８は、表定義の変更処理の流れを示す図である。表定義変更要求があった場合、まず改竄防止属性有りの表か否かをチェックし（８０１）、改竄防止属性無しの場合は表定義変更実行者が表の所有者又はＤＢＡ権限者か否かをチェックし（８０２）、表の所有者又はＤＢＡ権限者であれば表定義変更処理を実行する（８０３）。８０２で表の所有者又はＤＢＡ権限者でない場合は、
表定義変更不可となる（８０４）。一方、８０１で改竄防止属性有りの表の場合は、表名の変更、改竄防止属性の解除、行削除禁止期間の変更、又は行挿入日時保持列の削除のいずれかであるか否かをチェックし（８０５）、８０５のいずれかに合致する場合は、例え表の所有者又はＤＢＡ権限者であったとしても表定義変更不可となる（８０６）。８０５でいずれの条件にも合致しない場合は、８０２に分岐する。具体例として、図４の表１・表２に対する表定義変更要求（表名の変更、改竄防止属性の解除、行削除禁止期間の変更、又は行挿入日時保持列の削除）があった場合を考える。この場合、８０１でＹＥＳ、８０５でＹＥＳとなり表定義変更不可となる。
【００２２】
図９は、本発明における表データのアンロード・リロード処理を示す図である。ここで、ステータスファイルとは、データベース管理システムの状態やデータベースの状態等の情報を格納し、データベース管理システムを再起動するときに参照するファイルのことである。また、アンロードとは、データベースの内容を、磁気テープ等の外部記憶媒体に複写することであり、バックアップとも呼ばれる。また、リロードとは、アンロードしたデータをデータベースに書き戻すことを言う。図９では、改竄防止属性有りの表（表１及び表２）と改竄防止属性無しの表（表３）をそれぞれ２００２年６月２０日、同２５日、同１８日にアンロードし、その後の表１及び表３のアンロード媒体の各表へにおけるリロード可否について説明する。まず、改竄防止属性有りの表（表１）のデータをアンロードする場合について説明する。アンロードユティリティ９０１は、改竄防止属性有りの表１のデータを外部記憶媒体９０３にコピーする。この時、アンロードユティリティは、表名及びアンロード日時をステータスファイル（９０５）及び外部記憶媒体９０３に記録する。９０３をリロードユティリティ９０２でデータベースに書き戻す際、同一表（表１）へのリロードは、ステータスファイル中のアンロード日時と９０３中のアンロード日時及び表名とが一致する場合にのみ実行できる。他の改竄防止属性有りの表（表２）へのリロードは不可となる。改竄防止属性無しの他表（表３）へのリロードは可である。次に、改竄防止属性無しの表（表３）のデータをアンロードする場合について説明する。アンロードユティリティで表３のデータを９０４にコピーする。９０４は、改竄防止属性無しの表に対してはリロード可能であるが、改竄防止属性有りの表（表１又は表２）に対してはリロードできない。
【００２３】
図１０は、リロード処理の流れを示す図である。リロード処理では、まずアンロード元が改竄防止属性有りの表か否かをチェックし（１００１）、アンロード元が改竄防止属性無しの表の場合は次にリロード先が改竄防止属性有りの表か否かをチェックし（１００２）、リロード先が改竄防止属性無しの表であればリロード処理を実行する（１００３）。１００２で改竄防止属性有りの表の場合は、リロード不可（１００４）となる。１００１で改竄防止属性有りの表の場合は、次にリロード先が改竄防止属性有りの表か否かをチェックし（１００５）、リロード先が改竄防止属性無しの表であればリロード処理を実行する（１００３）。１００５でリロード先が改竄防止属性有りの表であれば、次にアンロード元の表名とリロード先の表名が同じか否かチェックし（１００６）、表名が異なればリロード不可（１００８）となる。１００６で表名が同じ場合は、次にステータスファイル中の当該ファイルのアンロード日時と外部記憶媒体中のそれとを比較し（１００７）、一致する場合はリロード処理を実行し、不一致の場合はリロード不可（１００８）となる。具体例として、図９の表１をアンロードした９０３を表２にリロードする場合を考える。アンロード元の表１は改竄防止属性有りの表なので１００１でＹＥＳ、リロード先の表２も改竄防止属性有りの表なので１００５でＹＥＳ、表１と表２は表名が異なるので１００６でＮＯとなり、リロード不可となる。さらに具体例として、図９の表１をアンロードした９０３を表１自身にリロードする場合を考える。この場合は、１００１でＹＥＳ、１００５でＹＥＳ、１００６でＹＥＳとなり、９０３中のアンロード日時とステータスファイル中の表１アンロード日時とが一致するため１００７でＹＥＳとなりアンロード可となる。表１に対する古い世代のアンロード媒体を使用した場合、１００７でアンロード日時が不一致となるため、アンロード不可となる。さらに具体例として、図９の表３をアンロードした９０４を表１にリロードする場合を考える。アンロード元の表３は改竄防止属性無しのため１００１でＮＯ、リロード先の表１は改竄防止属性有りのため１００２でＹＥＳとなり、リロード不可となる。
【００２４】
以上述べたように処理することにより、ディクショナリに表の属性として改竄防止属性、行削除禁止期間、及び行挿入日時保持列名を持ち、表データ更新または行削除要求時に表の属性及び行挿入日時をチェックすることで、更新を不可としたい表データに対し、表所有者や更新権限を譲渡された者であっても更新を不可とし、不正にまたは誤って更新することを防ぐことを可能とし、また、行挿入後、一定期間行データを削除不可としたい表データに対し、表所有者や行削除権限を譲渡された者であっても行削除を不可とし、不正にまたは誤って行を削除することを防ぐことを可能とする。
【００２５】
図１１から図１４は図２から図８と同様に改竄防止属性有りの表に対するデータ更新を不可とする実施例を示す図であるが、図２から図８と異なり、図２に示すパラメタＰ３を利用者が指定をしなくともパラメタＰ１の指定の有無により暗黙的に設定する実施例、およびデータ挿入日であればデータの更新を可能とする実施例、および列単位で改竄防止属性の定義を可能とする実施例である。
【００２６】
図１１は図２と同様に本発明の特長を表す表定義文の一例と、改竄防止定義情報がディクショナリに格納されている様子を示す図であり、パラメタＰ３を利用者が指定をしなくともパラメタＰ１の指定の有無により暗黙的に設定する一例および列単位で改竄防止属性の定義を可能とする一例である。ＳＱＬ１は、図２で示した表２と同じ属性を持ち、パラメタＰ３を指定せずに定義する場合のＳＱＬの一例である。このＳＱＬ例では、行挿入後、３年を経過した行に限り削除可能となる。ＳＱＬ１では、行削除禁止期間に「３ＹＥＡＲＳ（３年）」を指定し、行挿入履歴保持列名は指定していない。ＤＢ定義処理１１０４はＳＱＬ中にパラメタＰ２が指定され、かつパラメタＰ３が指定されていない場合は、行挿入日時保持列を暗黙的に設定する必要があると判断し、行挿入保持列として列「ＸＸＸＸＸ」を暗黙的に定義する。これにより、ディクショナリ１１０２の表３に対応する行挿入日時保持列名列に「ＸＸＸＸＸ」が格納される。本例では、ＤＢ定義処理１１０４が行挿入日時保持列名として「ＸＸＸＸＸ」を定義する例を示したが、一般的なデータベース管理システムにおいては、利用者が任意に列名の変更や追加を行うことが可能である。従って、ＤＢ定義処理１１０４が行挿入日時保持列名を暗黙的に設定する際の列名称に関しては、利用者が指定できない名称にするなどの配慮が必要となる。ＳＱＬ２に示す表４は１１０１に示すパラメタ名Ｐ１を列単位に指定することにより、列単位で改竄防止属性の設定を可能とする例である。表４は「カルテＩＤ」に対し「Ｙ」を指定することで、改竄防止属性有りの表でかつ、列「カルテＩＤ」は改竄防止属性有りの列となり、ディクショナリ１１０２の改竄防止属性列にその旨を示す「Ｙ」が格納され、さらに列の定義情報を管理するディクショナリ表１１０３の改竄防止属性列にその旨を示す「Ｙ」が格納される。また、表４は改竄防止属性に加え、１１０１に示すパラメタ名Ｐ２に行削除禁止期間が指定されているが、行削除禁止期間の定義の流れについては表３と同じであるため説明は省略する。
【００２７】
図１２は図１１で定義した列単位に改竄防止属性を定義した表４にデータ挿入後、表データの更新ＳＱＬを実行した場合の例を示し、さらに改竄防止属性有りの表あるいは改竄防止表あり列に対する表データ更新を行挿入日当日であれば可能とする例を示す。図２においては、表全体を改竄防止属性とする例を示したが、例えば人員管理データベースにおいて、姓と名を列を分けているような場合、婚姻等により姓が変更となる場合は姓の変更、すなわちデータの更新を必要とする場合が想定される。また、図４においては行挿入後、削除禁止期間内は一切の更新を不可とする例を示したが、挿入したデータ中にキー入力ミスなどによる誤りがあり、データの修正および更新をしたい場合が実際の運用上では少なくないと想定される。ここで、ＳＱＬ１は表４の改竄星属性有りの列に対する更新を指示するＳＱＬ、ＳＱＬ２は表４の改竄防止属性無しの列に対する更新を指示するＳＱＬである。行削除ＳＱＬ実行時の流れについては、図４と同じであるため説明は省略する。改竄防止属性有りの表４に対し、改竄防止属性有りの列に対する表データ更新を指示するＳＱＬ（ＳＱＬ１）を実行した場合、データベース管理システムは更新対象となる行が挿入日当日であればＵＰＤＡＴＥ可、挿入日当日でなければ不可の旨を示す情報をＵＡＰに返す（１２０１）。改竄防止属性有りの表４に対し、改竄防止属性有りの列に対する表データ更新を指示するＳＱＬ（ＳＱＬ２）を実行した場合、データベース管理システムはＵＰＤＡＴＥ可の旨を示す情報をＵＡＰに返す。（１２０１）
図１３は、図５と同様に表データの更新処理の流れを示す図であり、列単位での改竄防止属性の有無により更新可／不可の制御を行い、かつ行挿入日当日であれば表データの更新を可能とする例を示す。図５においては、表データ更新要求があった場合、まず改竄防止属性有りの表か否かをチェック（５０１）し、更新不可（５０６）としているが、行挿入当日であれば表データの更新を可能とする場合においては、改竄防止属性有りの表か否かをチェック後に更新する行の挿入日が行を挿入した当日であるかどうかのチェック（１３０６）を加えることで実現できる。表データ更新要求があった場合、まず改竄防止属性有りの表か否かをチェックし（１３０１）、改竄防止属性無しの場合は表データ更新実行者が表の所有者か否かチェックし（１３０２）、表の所有者であれば更新処理を実行する（１３０４）。１３０２で表の所有者でない場合は、表データ更新実行者が表の所有者から当該表に対する更新権限を譲渡されているかチェックし（１３０３）、譲渡されていれば更新処理を実行し（１３０４）、譲渡されていなければ更新不可とする（１３０５）。１３０１で改竄防止属性有りの場合は、更新する行の挿入日が行納入当日であるかをチェックし（１３０６）、行挿入当日の場合は１３０２以降の処理を実行する。行挿入当日でない場合は、更新する列が改竄防止属性有りの列であるかをチェックし（１３０７）、改竄防止属性有りの列である場合は例え表の所有者であったとしても更新不可となる（１３０８）。改竄防止属性有りの列でない場合は１３０２以降の処理を実行する。本実施例では、改竄防止属性有りの表においての行の更新猶予期間を行挿入日当日としているが、行挿入日時保持列を持つ表であれば、行挿入日時から２４時間以内や１２時間以内など、詳細な更新猶予期間を設けることも可能である。この場合は、更新する行の挿入日が行挿入当日であるかどうかのチェック（１３０６）内容を「行挿入日時保持列が持つ日時から２４時間以内か」などに変更することで実現可能である。以上、図１２および図１３では、列単位で改竄防止属性が設定されている場合での更新猶予期間を設ける実施例を示したが、図２に示すような列単位での改竄防止属性が設定されていない場合においては、列単位での改竄防止属性が設定がされていないことを改竄防止属性ありと見なし、図１３中の更新する列が改竄防止属性有りの列であるかをチェック（１３０７）に、「または、改竄防止属性が設定されていない列か」という条件を加えることで実現可能である。
【００２８】
図１４は、列単位での改竄防止属性が定義されている表への表定義の変更処理の流れを示す図である。表定義変更要求があった場合、まず改竄防止属性有りの表か否かをチェックし（１４０１）、改竄防止属性無しの場合は表定義変更実行者が表の所有者又はＤＢＡ権限者か否かをチェックし（１４０２）、表の所有者又はＤＢＡ権限者であれば表定義変更処理を実行する（１４０３）。ここでの「ＤＢＡ権限者」とは、データベース管理システムにおける管理者権限を持つユーザのことである。通常、データベース管理システムにおいては、「ＤＢＡ権限者」と「一般利用者」に大別され、ＤＢＡ権限者は一般利用者には利用できないデータベースを管理する機能を利用することが可能である。１４０２で表の所有者又はＤＢＡ権限者でない場合は、表定義変更不可となる（１４０４）。１４０１で改竄防止属性有りの表の場合は、表名の変更、改竄防止属性の解除、行削除禁止期間の変更、又は行挿入日時保持列の削除のいずれかであるか否かをチェックし（１４０５）、１４０５のいずれかに合致する場合は、例え表の所有者又はＤＢＡ権限者であったとしても表定義変更不可となる（１４０８）。１４０５でいずれの条件にも合致しない場合は、列の定義変更であるかをチェックし（１４０６）、列の定義である場合は改竄防止属性有りの列かをチェックし（１４０７）、改竄防止有りの列である場合は、例え表の所有者又はＤＢＡ権限者であったとしても表定義変更不可となる（１４０８）。１４０７にて、改竄防止属性有りの列ではない場合は、１４０２以降の処理を行う。１４０６にて、列の定義変更で無い場合は、例え表の所有者又はＤＢＡ権限者であったとしても表定義変更不可となる（１４０８）。
【００２９】
【発明の効果】
不正にまたは誤ってデータベースへの処理が実行されることを防ぐことが可能となる。
【図面の簡単な説明】
【図１】本発明に係わるデータベース管理方法及び装置である。
【図２】改竄防止を定義する定義文と改竄防止情報を格納するディクショナリ表の内容の一例である。
【図３】データ挿入時における流れを示す図である。
【図４】表データ削除ＳＱＬ及び行削除ＳＱＬを実行した場合の例である。
【図５】データ更新時における流れを示す図である。
【図６】行削除時における流れを示す図である。
【図７】表定義削除時における流れを示す図である。
【図８】表定義変更時における流れを示す図である。
【図９】アンロード・リロード処理を実行した場合の例である。
【図１０】リロード処理における流れを示す図である。
【図１１】改竄防止を定義する定義文と改竄防止情報を格納するディクショナリ表の内容の一例である。
【図１２】表データ更新ＳＱＬを実行した場合の例である。
【図１３】データ更新時における流れを示す図である。
【図１４】表定義変更時における流れを示す図である。
【符号の説明】
９０１：アンロードユティリティ
９０２：リロードユティリティ
９０３：外部記憶媒体
９０４：外部記憶媒体

Claims

データベースを格納する記憶装置及び前記データベースへのアクセスに関する管理情報を格納する管理情報記憶部と通信可能に接続され、通信線を介して接続された少なくとも１つの端末装置からの前記データベースへのアクセス要求を前記管理情報に基づいて制御する制御部を有するデータベース管理装置のデータベース管理方法であって、
前記制御部が、
前記少なくとも１つの端末装置から、前記データベースに含まれる表を特定する識別情報と前記データベースに含まれる表のアクセス属性情報とを含む表定義要求を受信するステップと、
該アクセス属性情報が改竄防止属性である場合、該改竄防止属性を前記管理情報記憶部に記憶し、当該表に対するデータ挿入及びデータ参照のアクセスを前記少なくとも１つの端末装置に許可するとともに当該表に挿入されたデータの更新、削除又は前記データの更新及び削除の両方を禁止する属性を設定するステップと、
前記設定後、前記少なくとも１つの端末装置から前記表の表定義を削除する要求を受信する場合、該表定義に関して、前記改竄防止属性が設定されているか否かを判断するステップと、
該判断の結果、該改竄防止属性が設定されている場合、前記設定後に受信した表定義を削除する要求を不可とするステップと、
を含むことを特徴とするデータベース管理方法。
請求項１に記載のデータベース管理方法であって、
前記表定義要求の改竄防止属性は、前記削除を禁止する属性情報とともに該表に挿入されたデータの削除を禁止する期間を示す削除禁止期間情報を更に含み、
前記制御部が、
前記削除禁止期間情報を前記管理情報記憶部に記憶するステップと、
前記データを前記表に挿入した時刻情報を記憶するステップと、
前記少なくとも１つの端末装置からの前記データに対する削除要求に対し、該データを前記データベースに含まれる表に挿入した時刻情報及び前記削除禁止期間情報に基づいて、該データの削除禁止期間が経過しているか否かを判断するステップと、
該判断の結果、該削除禁止期間が経過している場合、前記データの削除を許可し、該削除禁止期間を経過していない場合、前記データの削除を禁止するステップと、
を更に含むことを特徴とするデータベース管理方法。
請求項１又は２に記載のデータベース管理方法であって、
前記表定義要求の改竄防止属性は、データ更新猶予期間を更に含み、
前記制御部が、
前記少なくとも１つの端末装置から前記データベースに含まれる表のデータに対するデータ更新要求を受け付け、該データ更新要求の受付時間が、前記データ更新猶予期間内であるか否かを判断するステップと、
該判断の結果が、前記データ更新猶予期間内である場合、前記更新要求されたデータのデータ更新を行い、前記データ更新猶予期間内でない場合、前記更新要求されたデータのデータ更新を行わないステップと、
を更に含むことを特徴とするデータベース管理方法。
請求項１〜３のいずれか一項に記載のデータベース管理方法であって、
前記データベース管理装置は、前記記憶装置に格納されたデータベースのデータのアンロード先である他の記憶装置と更に接続され、
前記制御部が、
前記データベースに含まれる表のデータを前記他の記憶装置にアンロードする際、該データベースに含まれる表に前記改竄防止属性が設定されているか否かを判断するステップと、
該判断の結果が、設定されているものである場合、前記データベースのデータ及びアンロード時間を前記他の記憶装置に記憶するとともに該アンロード時間を前記データベースの状態情報を記憶する状態情報記憶部に記憶するステップと、
前記他の記憶装置に記憶されたデータを前記データベースにリロードする際、該他の記憶媒体に記憶されたアンロード時間と前記状態情報記憶部に記憶されたアンロード時間が一致するか否かを判定するステップと、
該判定の結果、前記アンロード時間が一致する場合、前記他の記憶装置に記憶されたデータベースのデータをリロードするステップと、
を更に含むことを特徴とするデータベース管理方法。
請求項４に記載のデータベース管理方法であって、
前記制御部が、
前記データベースに含まれる表を前記他の記憶装置にアンロードする際、該データベースに含まれる表に改竄防止属性が設定されているか否かを判断するステップでの判断結果が、設定されていないとするものである場合、前記データベースのデータを前記他の記憶装置に記憶するステップと、
前記他の記憶装置に記憶されたデータを前記データベースに含まれる表にリロードする際、該データベースに含まれる表に前記改竄防止属性が設定されているか否かを判断するステップと、
前記判断の結果、前記改竄防止属性が設定されていない場合、前記他の記憶装置に記憶されたデータを前記データベースにリロードし、前記改竄防止属性が設定されている場合、前記他の記憶装置に記憶されたデータを該データベースにリロードすることを禁止するステップと、
を更に含むことを特徴とするデータベース管理方法。
請求項１〜５のいずれか一項に記載のデータベース管理方法であって、
前記改竄防止属性は、前記データベースに含まれる表における列に設定することを特徴とするデータベース管理方法。
データベースを格納する記憶装置及び前記データベースへのアクセスに関する管理情報を格納する管理情報記憶部と通信可能に接続され、通信線を介して接続された少なくとも１つの端末装置からの前記データベースへのアクセス要求を前記管理情報に基づいて制御する制御部を有するデータベース管理装置であって、
前記制御部が、
前記少なくとも１つの端末装置から、前記データベースに含まれる表を特定する識別情報と前記データベースに含まれる表のアクセス属性情報とを含む表定義要求を受信する手段と、
該アクセス属性情報が改竄防止属性である場合、該改竄防止属性を前記管理情報記憶部に記憶し、当該表に対するデータ挿入及びデータ参照のアクセスを前記少なくとも１つの端末装置に許可するとともに当該表に挿入されたのデータの更新、削除又は前記データ更新及び削除の両方を禁止する属性を設定する手段と、
前記設定後、前記少なくとも１つの端末装置から前記表の表定義を削除する要求を受信する場合、該表定義に関して、前記改竄防止属性が設定されているか否かを判断する手段と、
該判断の結果、該改竄防止属性が設定されている場合、前記設定後に受信した表定義を削除する要求を不可とする手段と、
を有することを特徴とするデータベース管理装置。
データベースを格納する記憶装置及び前記データベースへのアクセスに関する管理情報を格納する管理情報記憶部と通信可能に接続され、通信線を介して接続された少なくとも１つの端末装置からの前記データベースへのアクセス要求を前記管理情報に基づいて制御する制御部を有するデータベース管理装置の前記制御部に、
前記少なくとも１つの端末装置から、前記データベースに含まれる表を特定する識別情報と前記データベースに含まれる表のアクセス属性情報とを含む表定義要求を受信する機能と、
該アクセス属性情報が改竄防止属性である場合、該改竄防止属性を前記管理情報記憶部に記憶し、当該表に対するデータ挿入及びデータ参照のアクセスを前記少なくとも１つの端末装置に許可するとともに当該表に挿入されたのデータの更新、削除又は前記データ更新及び削除の両方を禁止する属性を設定する機能と、
前記設定後、前記少なくとも１つの端末装置から前記表の表定義を削除する要求を受信する場合、該表定義に関して、前記改竄防止属性が設定されているか否かを判断する機能と、
該判断の結果、該改竄防止属性が設定されている場合、前記設定後に受信した表定義を削除する要求を不可とする機能と、
を実現させることを特徴とするプログラム。