JP4351530B2 - リレーショナルデータベースシステム内の階層型データにアクセスするための効率的な索引構造 - Google Patents

Description

関連出願
本願は、２００２年５月２８日にエリック・セドラー（Eric Sedlar）により出願され「リレーショナルシステムにおける階層索引の維持（Maintenance of Hierarchical Index in a Relational System）」と題された米国特許出願番号第１０／１７１，７２８号（代理人事件番号第５０２７７−１９８５号）の一部継続出願であり、これの内容はその全体においてここに引用により援用される。

本願は、１９９９年２月１８日にエリック・セドラーにより出願され、「リレーショナルシステム内の階層型として組織された情報にアクセスするための階層的索引付け（Hierarchical Indexing for Accessing Hierarchically Organized Information in a Relational System）」と題された米国特許出願番号第０９／２５１，７５７号、米国特許第６，４２７，１２３号（代理人事件番号第０２８８号）の一部継続出願であり、これの内容はその全体においてここに引用により援用され、かつこれは先に参照した米国特許出願番号第１０／１７１，７２８号と同時係属である。

本願は、エリック・セドラーおよびビスワナサン・クリシュナマーシー（Viswanathan Krishnamurthy）による「データベースシステムで提供されるファイルベースのアクセス（File Based Access Provided With a Database System）」と題された、２００１年９月２８日出願の米国仮特許出願番号第６０／３２６，０５２号の優先権を主張する。

本願は、ニプン・アガーウォル（Nipun Agarwal）、ラビ・マーシー（Ravi Murthy）、エリック・セドラー、シバサンカラン・チャンドラセカル（Sivasankaran Chandrasekar）、フェイ・ゲー（Fei Ge）、シアム・パンナラ（Syam Pannala）、ニーマ・ジャラリ（Neema Jalali）およびムラリドハル・クリシュナプラサド(Muralidhar Krishnaprasad）による「ファイルシステム抽出を提供するデータへのＳＱＬアクセス（SQL Access to Data that Provides a File System Abstraction）」と題された、２００２年５月７日出願の米国仮特許出願番号第６０／３７８，８００号の優先権を主張する。

本願はまた以下の米国特許出願に関連し、これらの内容全体はすべての目的についてここに引用により援用される。

ニプン・アガーウォル、ラビ・マーシー、エリック・セドラー、シバサンカラン・チャンドラセカルおよびフェイ・ゲーによる「リレーショナルシステムにおける階層型データにアクセスするための演算子（OPERATORS FOR ACCESSING HIERARCHICAL DATA IN A RELATIONAL SYSTEM）」と題された、同日出願の米国特許出願番号第 号（代理人事件番号第５０２７７−１９７５号）、
ニプン・アガーウォル、エリック・セドラー、ラビ・マーシーおよびナミット・ジェイン（Namit Jain）による「リレーショナルデータの整合的な階層抽出の提供（PROVIDING A CONSISTENT HIERARCHICAL ABSTRACTION OF RELATIONAL DATA）」と題された、同日出願の米国特許出願第 号（代理人事件番号第５０２７７−１９７６号）、
ラビ・マーシー、ムラリドハル・クリシュナプラサド、シバサンカラン・チャンドラセカル、エリック・セドラー、ビシュ・クリシュナマーシー（Vishu Krishnamurthy）およびニプン・アガーウォルによる「ＸＭＬスキーマをオブジェクト・リレーショナルデータベースシステムに対応付けるための機構（MECHANISM FOR MAPPING XML SCHEMAS TO OBJECT-RELATIONAL DATABASE SYSTEMS）」と題された、同日出願の米国特許出願番号第 号
（代理人事件番号第５０２７７−１９７７号）、
ニプン・アガーウォル、エリック・セドラーおよびラビ・マーシーによる「バージョンによるデータをデータベースシステムで効率的に管理するための索引付け（INDEXING TO EFFICIENTLY MANAGE VERSIONED DATA IN A DATABASE SYSTEM）」と題された、同日出願の米国特許出願番号第 号（代理人事件番号第５０２７７−１９７８号）、
ラビ・マーシー、エリック・セドラー、ニプン・アガーウォルおよびニーマ・ジャラリによる「階層型として組織されたリソースの内容およびプロパティを記憶するための機構（MECHANISMS FOR STORING CONTENT AND PROPERTIES OF HIERARCHICALLY ORGANIZED RESOURCES）」と題された、 に出願された米国特許出願番号第 号（代理人事件番号第５０２７７−１９７９号）、
ラビ・マーシー、エリック・セドラー、ニプン・アガーウォル、サム・イディキュラ（Sam Idicula）およびニコラス・モントーヤ（Nicolas Montoya）による「データベースシステムにおける均一なアクセス制御のための機構（MECHANISM FOR UNIFORM ACCESS CONTROL IN A DATABASE SYSTEM）」と題された、同日出願の米国特許出願番号第 号（代理人事件番号第５０２７７−１９８０号）、
シアム・パンナラ、エリック・セドラー、ブシャン・カラドカル（Bhushan Khaladkar）、ラビ・マーシー、シバサンカラン・チャンドラセカルおよびニプン・アガーウォルによる「ＸＭＬ文書のレイジー表明のためのロード可能ユニット（LOADABLE UNITS FOR LAZY MANIFESTATION OF XML DOCUMENTS）」と題された、同日出願の米国特許出願番号第 号（代理人事件番号第５０２７７−１９８１号）。

発明の分野
この発明はリレーショナルデータベースシステムに関し、より特定的に、リレーショナルデータベースシステム内の階層型データを索引付けするための技術に関する。

発明の背景
人間には情報を範疇に従って組織するという性向がある。そして情報を組織するのに用いる範疇自体もまた、或る形の階層内で互いに関連させて組織されることが多い。たとえば個々の動物は或る種に属し、この種は属に属し、属は科に属し、科は目に属し、そして目は綱に属する、といった具合である。

コンピュータシステムの到来に伴い、電子情報を格納するための技術は、この階層型組織に対する人間の欲求を大部分反映するように開発されてきた。たとえば一般的に、従来のコンピュータファイルシステムは階層に基づく組織原理を用いて実現されている。具体的には、典型的なファイルシステムは階層内に配置されたディレクトリを有し、文書がこのディレクトリに格納される。ディレクトリ間の階層関係は、ディレクトリに割当てられた意味同士の或る直感的にわかる関係を反映していることが理想的である。同様に、各々の文書をディレクトリ内に格納する際、この文書の内容と、この文書が格納されるディレクトリに割当てられた意味との或る直感的にわかる関係に基づいていることが理想的である。

図１は典型的なファイルシステムの一例を示す。ここに例示するファイルシステムは階層内に配置された数多くのディレクトリを含む。２つの文書１１８，１２２がディレクトリ内に格納される。具体的には、文書１１８，１２２の両方とも“Example.doc”と名称を与えられてそれぞれディレクトリ１１６，１２４内に格納され、これらはそれぞれ“Word”および“App4”と名称を与えられている。

このディレクトリ階層において、ディレクトリ１１６は、“Windows”と名称を与えられたディレクトリ１１４の子であり、ディレクトリ１１４はディレクトリ１１０の子であ
る。同様に、ディレクトリ１２４は“ＶＭＳ”と名称を与えられたディレクトリ１２６の子であり、ディレクトリ１２６はディレクトリ１１０の子である。ディレクトリ１１０は「根（root）」ディレクトリと称されるが、それはこのディレクトリからその他すべてのディレクトリが降りていくからである。多くのシステムでは根ディレクトリを参照するのに記号“／”が用いられる。

電子情報が階層内に組織される場合、各々の情報項目の場所を探し当てるには、「パス」に従って階層内を通り、この項目が入っている実体にたどり着くことになる。階層型ファイルシステムにおいては、或る項目に至るパスは根ディレクトリから始まってディレクトリ階層を下って進み、最終的に当該の項目が入っているディレクトリに到着する。たとえば、ファイル１１８へのパスは順にディレクトリ１１０，１１４，１１６から構成される。

階層型記憶システムでは、異なる項目が同一名称を有してもよいことが多い。たとえば、図１に示すファイルシステムでは、文書１１８と文書１２２とは両方とも“Example.doc”の名称が与えられている。したがって、所与の文書を一義的に識別するには文書の名称以上のものが必要である。

階層型記憶システムに格納された情報の特定の項目を識別しその場所を突き止める従来のやり方として「パス名」を使用することが挙げられる。パス名は、或る項目を、階層を通じてこの項目に至るパスに基づいて一意に識別する簡潔な方策である。パス名は、パス要素と称される一連の名称から構成される。ファイルシステムに関しては、一連の名称における各々の名称は「ファイル名」である。「ファイル名」という用語はディレクトリの名称と文書の名称との両方を指すが、それはディレクトリも文書も「ファイル」とみなされるからである。

ファイルシステム内では、所与のパス名における一連のファイル名は根ディレクトリの名称から始まり、根ディレクトリから当該の項目に至るパス上にあるディレクトリすべての名称を含み、当該の項目の名称で終わる。一般的には、探査するディレクトリのリストは、或る種の分離子（たとえば‘／’、‘＼’または‘；’）によって互いに連結されてパス名をなす。したがって文書１１８についてのパス名は/Windows/Word/Example.docとなり、文書１２２についてのパス名は/VMS/App4/Example.docとなる。

ディレクトリ（ファイル）同士およびそこに入っている内容同士の関係は、階層型として組織されたシステムのタイプによって大幅に変わってくる。Windows（登録商標）およびＤＯＳファイルシステムなどさまざまな実現例で採用される１つのモデルでは、各々のファイルは正しく１つの親を有して木をなすことが必要である。より複雑なモデルにおいては、階層は、ファイルに多数の親がある有向グラフの形をとり、これはたとえばハードリンクを使用するＵＮＩＸ（登録商標）ファイルシステムに見られる。

電子情報を組織するための階層型の手法とは対照的に、リレーショナルデータベースでは情報は行および列からなる表（table）に格納される。各々の行は一意の行ＩＤによって識別される。各々の列はレコードの属性を表わし、各々の行は特定のレコードを表わす。データをデータベースから検索するには、データベースを管理するデータベースサーバに問合せを提出する。問合せは、データベースサーバがサポートするデータベース言語に適合している必要がある。多くの既存のデータベース管理システムがサポートするデータベース言語の一例として構造化問合せ言語（ＳＱＬ）がある。

記憶システムについての各々のタイプには利点と限界とがある。階層型として組織された記憶システムは単純で直感的にわかりやすく、かつ実現が容易であるため、ほとんどの
アプリケーションプログラムで用いられる標準的なモデルとなっている。しかし残念ながら、この単純な階層型組織では複雑なデータ検索動作に必要なサポートが得られない。たとえば、特定のファイル名を有する特定の日に作成された文書すべてを検索するには各々のディレクトリの内容を調べなければならないであろう。ディレクトリをすべて探索しなければならないので、階層型組織は検索プロセスを容易にするのに全く寄与していない。

一方、リレーショナルデータベースは大量の情報の記憶および極めて柔軟なデータアクセスによく適している。階層型として組織されたシステムに対して、リレーショナルデータベースシステムからは、複雑な探索基準に合致するデータも容易かつ効率的に検索され得る。しかし問合せを作成してデータベースに提出するプロセスは、階層をなすディレクトリを単に探査するよりも直感的にわかりにくく、多くのコンピュータユーザにとっての技術的な快適度の埒外である。

過去において、階層型として組織されたシステムとリレーショナル型として組織されたシステムとは、互いに相容れない異なるやり方で実現されていた。しかしながら、リレーショナル型として組織されたシステムのいくつかには、このシステムが階層型として組織されたシステムを模倣できるようにする機能が組込まれている。この種のエミュレーションは、リレーショナルシステムの記憶能力および柔軟性が必要でありかつ階層型システムの直感的なわかりやすさおよび遍在性が望まれる場合に特に望まれている。

このような機能としては、ＳＱＬにより定義されるCONNECT BY句に基づくものがある。CONNECT BY句によりユーザは、階層型組織に基づきデータを要求する問合せを発行することができる。データは階層型組織を反映するやり方でリレーショナルデータベースによって返される。CONNECT BYは、階層型組織が基づく階層関係を定義する条件を指定するために使用される。

しかしながら、CONNECT BY句を用いて問合せを作成することには欠点もある。第１に、このような問合せの処理には多数のJOIN演算の処理が伴うことがあるが、このプロセスはこの問合せを処理するデータベースサーバにとって多大なコストがかかるおそれがあるものである。さらに、CONNECT BY句の使用はより多くの負担をユーザに強いる。CONNECT BY句を問合せに組込むことで、そうでなくても複雑な作業である問合せの作成がさらに複雑になる。

したがって、リレーショナルデータベースシステムが階層型として組織されたシステムを模倣できるようにする機構であって、この種のエミュレーションについて従来の機構よりも効率的なやり方によるものを提供することが望まれている。さらに、この種のエミュレーションが、階層型として組織されたデータを要求しかつ返す問合せを作成する複雑さを軽減させるやり方で提供されることが望まれている。

添付の図面の各図においてこの発明を示すが、これは例示的なものであって限定的なものではない。図面においては同様の参照番号は同様の要素を指す。

発明の詳細な説明
リレーショナルデータベースシステム内に格納された階層型情報にアクセスするための方法および装置について説明する。以下の記載においては、この発明の完全な理解をもたらすために説明上数多くの特定の詳細について述べる。しかしながら、この発明はこれら特定の詳細なしに実施可能であることが明らかであろう。他の場合には、この発明を不必要に不明瞭にすることを避けるために、周知の構造および装置をブロック図の形で示す。

概観
リレーショナルデータベースシステムにより模倣された階層の階層関係を捕捉する階層索引の新たな実現法をここに記載する。この階層索引は、階層索引のエントリとなる行が入っているデータベース表を用いて実現される。もう１つの表には、この階層内のノードに関連付けられた行がある。階層索引内の各々のエントリは、階層内の或るノードに対応する行へ対応付けする。階層内のノードは、１つ以上の子ノードを有する親ノードであり得る。この場合、階層索引内の対応するエントリには索引内の他のエントリを識別する識別子が入っており、これら他のエントリは当該の親ノードの子ノードに関連付けられた行に対応する。

さらに、索引には、階層に関連付けられた行にユーザがどのようにアクセスできるかについての情報が入っている。この情報を用いることで、この索引が関わる演算を行なう間におけるユーザのアクセス権限を判定し、こうして演算と、アクセス権限の判定の作業との両方を全体的により効率的に行なうことが可能となる。

さらに、データベースサーバは階層索引を用いて、データベースサーバのサポートする在来の索引のように文を実行することができる。このようにサポートされ得る種類の文には、データ定義言語（ＤＤＬ）文およびデータ操作言語（ＤＭＬ）文が含まれる。両方の種類の文がＳＱＬなどのデータベース言語によって書かれる。

システム概観
図２は、この発明の実施例の理解を容易にするためにここに記載される例で用いられる階層２００を例示するブロック図である。階層２００は８個のノードを含む。階層内の最高のノードは「根」ノードと称される。階層内の各々の枝の端にあるノードは「葉」ノードである。根ノードと葉ノードとの間にあるノードは「中間」ノードである。ここに示す階層では、ノード１，２，３が中間ノードであり、ノード４，５，６，７は葉ノードである。

情報階層においてノードは情報に対応する。一般的に、各々のノードに関連付けられた１つの情報は或る形の名称および或るタイプの内容を有することになる。たとえば、階層型ファイルシステムに対応する階層では、一般的にノードはファイルに対応する（「フォルダ」または「ディレクトリ」はファイルの一種である）。各々のこのようなファイルは名称および或る形の内容を有する。

図３は、階層型データベースシステムにおける階層２００を表現するのに用いられ得る２つの表３０２，３５０のブロック図である。表３０２は階層２００内の各々のノードにつき１つの行を含む。行ＩＤの擬似列である＜Ｒ行ＩＤ＞は、表３０２内の行を識別する行ＩＤを有する。列＜ノード＞には、階層２００内のノードを一意に識別する論理識別子（ここでは「ノードＩＤ」）が入っている。列＜ノード＞は主キー値が入っている主キーであり得る。列＜データ＞には、或るノードに関連付けられたデータを表わす値が入っている。表３０２内の所与のノードについての行は、この行の行ＩＤと、このノードを識別するノードＩＤと、このノードに関連付けられたデータとを含む。たとえば、「行ＩＤ」のＲ１で識別される行３０４は、ノード１と、ノード１に関連付けられたデータ３０６と、その内容とに対応する。表３０２内の行をここではそのそれぞれの行ＩＤで参照する。

表３５０は、階層２００内の親子関係を各々定義する行を含む。＜親＞および＜子＞の列にはノード識別子が入っている。列＜子名＞には、階層２００内の特定の親子関係についての子の「子名」が入っている。表３５０内の或る行により定義される特定の親子関係につき、列＜親＞には親ノードを識別するノードＩＤが入っており、列＜子＞には子ノードを識別するノードＩＤが入っており、＜子名＞にはこの特定の親子関係における当該の
子の子名が入っている。そのように行３５４および行３５６はそれぞれ、ノード１がノード２およびノード３の親であることを示す。行３５４において＜子名＞は、行３５４で表わされる親子関係におけるノード２の名称は“ｂ”であることを指定する。

階層２００では明示的に示さないが、ノードは階層内に多数の親を有し、これら親子関係の各々につき異なる子名を有することがある。たとえばノード４はノード１の子であって、この親子関係については子名Ｚを有することがあり得る。したがって、この親子関係で表わされるパスは“／ａ／Ｚ”である。この親子関係を表わす表３５０の行について、＜親＞には１、＜子＞には４、および＜子名＞にはＺが入っている。

子名はリンクプロパティの一例であり、すなわち親または子ではなくて親子関係に特有のプロパティである。別の実施例では、表３５０には他のリンクプロパティについての他の列が入っていることもある。たとえばリンクプロパティは、システムのアクセス局の最高レベルを有する者（たとえばシステム管理者）以外の者に親子関係が見えるかどうかを指定し得る。または、リンクプロパティは、親子関係が固定であり、すなわちエンドユーザによって変更不可能であると指定することもある。このような固定の親子関係についての表３５０内の行は変更される見込みが極めて低いため、揮発性メモリで半永久的にキャッシュされ得る。

階層索引
図４は、この発明の一実施例に従う表３０２および表３５０で表わされる階層２００の階層関係を記述する階層索引４０２を示す。索引４０２は、多数の列および多数の行を含む表である。各々の行は索引エントリである。階層２００内の各々の中間ノードにつき、索引４０２内のその対応するエントリは、中間ノードの子ノードの索引エントリと、この子ノードに対応する表３０２内の行とを識別する。索引４０２には葉ノードについてのエントリは入っていない。

索引４０２内の列＜Ｉ行ＩＤ＞は、索引４０２内の或るエントリを識別する行ＩＤを有する行ＩＤの擬似列である。列＜ノードＩＤキー＞には索引４０２についての主キー値が入っており、これらキー値は表３０２の列＜ノード＞におけるノードＩＤである。列＜子ＩＤ＞には複合ＩＤの集合が入っており、各々の複合ＩＤには、子ノードの子名と、もしあればこの子ノードに対応する索引４０２内のエントリを識別する行ＩＤと、この子ノードに対応する表３０２内の行を識別する行ＩＤとが入っている。子ＩＤはたとえば「文字大バイナリオブジェクト（character large binary object）」のデータタイプの列として実現され得る。このデータタイプでは、所与のエントリにつき多くの複合ＩＤを或る列に格納することができる。列＜アクセス情報＞には、ノードと、表３０２内のその対応する行とにアクセスするためのアクセス情報が入っている。

所与のノードと、索引４０２内のその対応するエントリとにつき、エントリには、所与のノードの子ノードに対応する索引４０２内の他のエントリを識別する複合ＩＤが入っているが、これはこれら子ノードが中間ノードである場合に限られる。たとえばエントリ４０８では、列＜ノードＩＤキー＞にはノードＩＤ値１が入っている。したがってエントリ４０８はノード１に対応する。エントリ４０８内の＜子ＩＤ＞には複合ＩＤ｛“ｂ”，ｒ２，Ｒ２｝および｛“ｃ”，ｒ３，Ｒ３｝が入っており、これら複合ＩＤは、それぞれ中間ノード２，３に各々が対応するエントリ４１２，４１４を識別する。ノード２はノード１の子である。複合ＩＤ｛“ｂ”，ｒ２，Ｒ２｝は、表３０２内の行Ｒ２が子ノード２に対応しその子名が“ｂ”であると指定する。エントリ４１２では、＜ノードＩＤキー＞には値２が入っており、＜子ＩＤ＞には｛“ｄ”，，Ｒ４｝，｛“ｅ”，，Ｒ５｝が入っている。複合ＩＤ｛“ｄ”，，Ｒ４｝および｛“ｅ”，，Ｒ５｝は索引４０２内のいずれのエントリも識別せず、対応する子ノードが葉ノードであることを示している。複合ＩＤ｛
“ｄ”，，Ｒ４｝は、表４０２内の行Ｒ４に対応するノード、すなわちノード４を子ノードとして識別する。ノード４は葉ノードである。

表３０２，３５０および索引４０２は階層２００の情報をリレーショナル形式で捕捉する。以下にこの発明のいくつかの実施例について、階層２００、表３０２，３５０および索引４０２を参照した例を用いて説明するが、このような実施例は単に例示的なものである。リレーショナルデータベースシステムが階層についての情報を格納するやり方は実現例によって変わり得るため、この技術はいかなる特定の実現例にも限定されない。

索引の探査例
索引４０２を探査することにより、階層２００内のノードの位置に基づいた要求に応答して階層２００内のノードにアクセスできる。たとえば、パス“／ａ／ｂ”で識別されるノードであるノード２の子ノードに関連付けられたデータを要求する問合せを発行する。このような問合せを作成するには、ニプン・アガーウォル、ラビ・マーシー、エリック・セドラー、シバサンカラン・チャンドラセカルおよびフェイ・ゲーによる「リレーショナルシステムにおける階層型データにアクセスするための演算子」と題された、同日出願の米国特許出願番号第 号（代理人事件番号第５０２７７−１９７５号）に記載の演算子を用いることができる。子ノードを得るには、“ａ”の名称を有するノードに対応する索引エントリであるエントリ４０８にアクセスする。このパス内の次のノードに対応する索引４０２内のエントリは、エントリ４０８の列＜子ＩＤ＞内の複合ＩＤを調べることで判定される。複合ＩＤ｛“ｂ”，ｒ２，Ｒ２｝はパス“／ａ／ｂ”内の次のノードに合致する子名が入っており、エントリ４１２の行ＩＤである行ＩＤｒ２を識別する。次にエントリ４１２にアクセスする。エントリ４１２の＜子ＩＤ＞内の複合ＩＤは｛“ｄ”，，Ｒ４｝および｛“ｅ”，，Ｒ５｝であり、これらは、子ノードとしてノード２に関連付けられた表３０２内の行、すなわち行Ｒ４，Ｒ５を識別する。行Ｒ４，Ｒ５はノード４，５に対応し、それぞれパス“／ａ／ｂ／ｄ”，“／ａ／ｂ／ｆ”で識別される。これら行へその行ＩＤを用いてアクセスし、これら行内の要求されたデータを検索する。

多数の行ＩＤを１つのセル内に格納する利益
索引４０２の利点として、或る親ノードの子ノードの表３０２内の行および索引エントリを識別するデータが１つのデータブロック内に常駐できることが挙げられる。データブロックはデータベースにより管理されるデータベースデータを格納するための記憶のアトミックな単位であり、静的記憶装置から揮発性メモリへロードされ得る粒度の最低のレベルでのデータの単位である。データブロックは静的記憶装置から揮発性メモリへロードされなければならないことがあるため、データブロックへのアクセスは多大なコストのかかる動作であり得る。データブロックにアクセスするプロセスについては、このプロセスの実行に必要なデータブロックの数を減少させることで大幅な効率性の向上が実現され得る。したがって、或る親ノードの子ノードの表３０２内の行および索引エントリを識別するのに必要なデータすべてを格納できれば、このデータを得るにはただ１つのデータブロックにアクセスするだけでよく、これは有利な特徴である。

この特徴は特に、「パス解決（path resolution）」または「パスを解決する」と呼ばれるプロセスで有利である。パス解決とは、或るパスによって１つ以上のどの実体が識別されるかを判断するために行なわれる１組の演算を指す。これは或るパスに基づく階層型として組織されたデータにアクセスするあらゆるシステムによって行なわれる一般的で重要な機能である。したがってその効率の向上は特に重要である。

たとえば、パス“／ａ／ｂ”を解決するには、ノードａに対応する索引エントリであるエントリ４０８にアクセスする。エントリ４０８の＜子ＩＤ＞にある複合ＩＤを評価し、これらがノードｂについてのエントリを識別するｒ２を含んでいると判断する。こうして
パスは有効なノードを識別し、表３０２内の行Ｒ４が、パス“／ａ／ｂ”を解決して得られるデータ構造である。

上述のように、パス“／ａ／ｂ”の解決には、最後を除きパス内の各々のレベルにつき、１つの索引エントリおよび１つのデータブロックへアクセスすることが必要である。したがって、索引４０２を用いてパスを解決するためにアクセスされるデータブロックの数は、このパス内のレベルの数に線形比例する。

この線形比例が存在するのは、すべての子ノード索引エントリを識別するのに必要な行ＩＤが１つのデータブロックに格納され得る場合であり、この条件はデータベースサーバに典型的に記憶される階層型として組織されたデータについてほぼ当てはまる。たとえば、一般的なデータベースサーバの平均ブロックサイズは８ｋ（キロバイト）であり、平均行ＩＤサイズは１６バイトであり得る。したがって１つのデータブロックには、およそ５００の子ノードのエントリを識別するために十分な行ＩＤを格納できる。子ノード数についてのこのしきい値が、所与の親につき、データベースサーバによって表現されるほとんどの階層において超過される見込みは低い。

索引４０２のもう１つの有利な特徴は、これがデータベースサーバによって表として構成および管理されることである。これによって、データベース表への効率的な同時アクセスを可能にする在来の強力な機能を用いて索引４０２へ同時的にアクセスすることが可能となる。このような機能の一例が行レベル同時実行である。行レベル同時実行では、表内の行にアクセスするにはプロセスはこの行をロックするだけでよい。もう１つの形の、効率性に劣り得る同時実行が表レベル同時実行である。表レベル同時実行では、表またはその任意の部分にある行にアクセスするには、プロセスは表全体をロックしなければならない。一般的に、多数の同時実行プロセスは、同じデータ構造に同時的にアクセスできる場合においてより効率的に実行され得る。行レベル同時実行では、多数のプロセスは表内の異なる行にアクセスする場合にテーブルへ同時的にアクセスできる。行をロックするプロセスは、別の行へのアクセスを必要とするプロセスをブロックしない。しかし表レベル同時実行では、行にアクセスするには、プロセスは表全体をロックして、表内のいずれかの行へのアクセスを必要とする他のプロセスもブロックしなければならず、表をロックしているプロセスによって必要とされていないまたはアクセスされない行にアクセスする必要のあるプロセスすらもブロックしてしまう。

コミット前キャッシュ
データベースシステム上で実行するトランザクションは、親子関係と、この親子関係を表わす表３０２，３５０内の行とを変化させる。一般的に、トランザクションが行を変化させると、この行はトランザクションのコミット前にロックされる。たとえば、或るトランザクションによってノード１とノード２との間の親子関係が変化させられると、行３５４およびエントリ４０８がロックされる。行３５４のロックにより、ノード１とノード２との間の親子関係を変化させようとする他のプロセスがブロックされる。しかしエントリ４０８へのロックによって、この親子関係を変化させようとしているプロセスだけでなく、その他の、ノード１とノード３との間の親子関係についてのものもブロックされる。親子関係を変化させる目的のために、表４０２にある行のロックは親レベルで生じ、一方で表３５０にある行のロックは、より低い粒度のレベルである親子関係レベルで起こる。

親子関係の変化を反映させるためになされる表４０２内の行の変化に付随するブロックの影響を減少させると同時に同時実行性を向上させるために、トランザクションが変化させる行のロックは、トランザクションがコミットしようとするときまで据え置かれる。トランザクションによりなされる行の変化は「コミット前キャッシュ」において追跡される。トランザクションがコミットしようとするときになってはじめて、変化した行はロック
され、こうしてトランザクションのために行がロックされる全体的な時間と、他では生じるであろう付随的なブロックの影響とが減少する。

階層索引の探査中におけるアクセス制御データの使用
列＜アクセス情報＞には、ユーザアクセス権限、すなわち、ユーザ、ユーザグループまたはユーザクラスが階層２００内のノードにどのようにアクセスできるか、について判断するために用いられるアクセス制御データが入っている。索引４０２内の特定のエントリにつき＜アクセス情報＞には、或るノードについてのユーザ権限と、このノードに対応する行とを判定するために用いられるデータが入っている。このデータは、ユーザアクセス権限を明示的に指定するデータか、アクセス制御データのソースに関するデータか、これらの組合せかの形を取り得る。

この発明の一実施例に従うと、データベースサーバによって、表３５０およびその他このデータベースサーバの管理する表にアクセスするためのアクセス制御データが管理および維持される。このようなアクセス制御データをここで表アクセス制御データと称する。或る表についての表アクセス制御データは、たとえば表内の１つ以上の列に少なくとも部分的に格納され得る。

＜アクセス情報＞に格納されたデータは、表３５０についての表アクセス制御データを反映（すなわちこれと整合）する。したがって、特定のエントリについて、＜アクセス情報＞に格納されたアクセス制御データは、当該の行についての表アクセス制御データにより指定されるユーザ権限と整合するユーザアクセス権限を示す。たとえばエントリ４０８についての＜アクセス情報＞内のデータにおいて、ユーザがノード１内のデータを読出すことはできても書込むことができないと示されていれば、行Ｒ１についての表アクセス制御データには、同じユーザが行Ｒ１から読出すことはできてもここにデータを書込むことはできないことが示される。

この発明の一実施例に従うと、階層型およびリレーショナル型として組織されたデータへのアクセスを支配するアクセス制御データは、ラビ・マーシー、エリック・セドラー、ニプン・アガーウォル、サム・イディキュラ（Sam Idicula）およびニコラス・モントーヤ（Nicolas Montoya）による「データベースシステムにおける均一なアクセス制御のための機構」と題された、同日出願の米国特許出願番号第 号（代理人事件番号第５０２７７−１９８０号）に記載されたように実現され得る。

＜アクセス情報＞内のアクセス制御により定義されるユーザアクセス権限には、ノードの内容を読出す権利、ノードの内容を書込む権利、ノードについてのユーザ権限を定義する権利、ノードを削除する権利、およびノードを探査する権利が含まれるが、これに限定はされない。ノードを探査する権利とは、ノードの子孫へのあらゆる種類のアクセスを行なう能力を指す。たとえばノード１に関して、ユーザはノード１を探査する権利を有するが、その内容を読出しまたは書込みする権利を有さない。ユーザはノード１の子であるノード２およびノード３にアクセスできるが、ノード１の内容を読出す、すなわち行Ｒ１を読出すことはできない。

＜アクセス情報＞にアクセス制御データを格納することで、パス解決など索引４０２の探査が関わる演算を行なう間においてユーザアクセス権限をより効率よく判定することができる。探査中に既にアクセスされている索引４０２のエントリの中にアクセス制御データが格納されるため、パスの最後のノードを除き別のソースからのアクセス制御データ、たとえば表３０２に格納されたアクセス制御データを得る必要がなくなる。たとえば、パス“／ａ／ｂ”を解決するには、エントリ４０８にアクセスするが、パスの最後のノードであるノード２についての＜アクセス情報＞内のアクセス制御情報が入っているエントリ
４１２にはアクセスしない。その代わりにこの情報はテーブル３０２から入手される。

パス解決は、パスにより指定されるノードを識別することだけでなく、このノードが関わる特定の種類の演算を行なうために必要な特定のユーザ権限をユーザが有しているかどうかを判断することをも含むアトミックな演算として行なわれ得る。＜アクセス情報＞内のアクセス制御データによって、この種のパス解決はより効率的に行なわれ得る。たとえば、階層索引４０２を探査して或るユーザについてのパス“ａ／ｂ／ｃ”を解決している間にエントリ４０８へのアクセスが行なわれる。＜アクセス情報＞内のデータを調べて、ユーザがノード１を探査できると判断する。次にエントリ４１２にアクセスする。エントリ４１２についての＜アクセス情報＞内のデータを調べて、ユーザがノード２を探査できないと判断する。こうしてユーザは、ノード２の、パスにより識別される子ノードであるノード３も含む子のいずれを見ることもできない。パス解決は終了し、索引４０２を引続き探査する必要はない。このようにして、パス解決を行なう際、表３５０についての表アクセス制御データへのアクセスを回避するだけでなく、パスにおける各々のパス要素に対応するエントリを完全に探査することを回避している。

アクセス制御データの階層索引での格納は、アクセス制御情報を入れることができる索引の種類の一例である。他の種類の索引、たとえばＢ木索引には、索引付けされる項目についてのアクセス制御情報を入れることができる。索引探査およびアクセス制御の両方が関わるプロセスを改良するためには他の種類の索引に格納されたアクセス制御情報を使用してもよい。したがってこの発明は、アクセス制御情報を階層索引に格納することには限定されない。

階層索引の統合
データベースサーバによりサポートされる在来の索引の利点としては、データベースサーバがこれら索引を用いて、索引を使用できるかどうかおよびどのように使用するかを指定していないデータベース文を実行できることがある。これができることにより、ユーザは索引を使用するのに必要な演算を指定する問合せを作成する作業の負担から解放される。たとえばデータベースサーバは、索引を使用するかどうかまたはどのように使用するかを指定していない問合せを実行する要求を受取る。次にデータベースサーバは、演算子と、タスクを実行する１組の演算の定義と、上記演算子を実行する順番とを定義する実行プランを生成する。演算子は、特定の索引にアクセスするための演算子を含む。実行プランを生成する際にデータベースサーバは効率に影響を与えるさまざまな要因を評価する。実行プランが生成されれば、このプランにある、索引のアクセス用の演算子を含む演算子をデータベースが実行する。

索引を使用するかどうかまたはどのように使用するかをデータベース文が指定する必要なしに、データベースサーバが自動的に索引を使用してデータベース文を実行する場合、索引またはその使用は「データベース言語層よりも下」または「ＳＱＬ層よりも下」にあると呼ばれる。

データベースコマンド層よりも下にある態様の索引をサポートするには、データベースサーバ用のソフトウェアはこのように索引をサポートするようプログラムされ得る。この種のサポートを可能にするもう１つのやり方は、拡張可能な索引付けと称される機構を使用することによるものである。拡張可能な索引付けについては、ジャガナサン・スリニバサン（Jagannathan Srinivasan）、ラビ・マーシー、チン・ホン（Chin Hong）、サミュエル・デファツィオ（Samuel DeFazio）およびアニール・ノリ（Anil Nori）に対して１９９９年４月６日に発行された「拡張可能索引付け（Extensible Indexing）」と題された米国特許第５，８９３，１０４号に記載があり、これの内容はここに引用により援用される。拡張可能な索引付けにより、或る索引タイプをサポートするための組込サポートを
有していないデータベースサーバは、その索引能力を拡張して新たな索引タイプをサポートできるようにすることが可能だが、これのためには、データベースサーバに呼出されると索引タイプの実例である索引を使用およびサポートする索引タイプおよび索引ルーチン（たとえばオブジェクトメソッド）を登録する。一般的に、索引ルーチンには、索引の定義を作成、削除および変更するルーチン（ＤＴＬ索引ルーチン）、既存の索引にあるデータに変更を加えるルーチン（ＤＭＬ索引ルーチン）、既存の索引からデータを検索するルーチン（問合せ処理索引ルーチン）、および、呼出されると実行プランを生成および評価するルーチン（問合せ最適化索引ルーチン）が含まれる。

拡張可能な索引付けにより、データベースサーバは、特定の索引タイプの索引を使用およびサポートするのに必要な演算を、自動的かつデータベース言語層よりも下で行なうことができる。たとえばデータベースサーバは、表３５０にDROPまたはTRUNCATEを行なうＤＤＬ文を受取る。ＤＤＬ文は索引４０２でなく表３０２を参照する。データベースサーバがＤＤＬ文を実行すると、ＤＤＬ索引ルーチンを呼出して実行することにより索引には自動的にDROPまたはTRUNCATEが行なわれる。データベースサーバは或る問合せを受取ると実行プランを評価して生成し、これを行なっている間に、索引４０２を使用するかどうかまたはどのように使用するかについての評価に参加する問合せ最適化索引ルーチンを呼出す。データベースサーバは実行プランを生成すると実行プランを実行し、実行プランを行なうのに必要な問合せ処理索引ルーチンを呼出す。

索引を作成するには、ユーザはCREATE INDEXのＤＤＬ文を発行する。この発明の一実施例に従うと、階層索引についてのCREATE INDEX文は、リソース表およびリンク表を仮数として指定する。表３０２などのリソース表には、階層２００などの階層内にノードの内容が（論理的、物理的に、またはその組合せで）入っている。表３５０などのリンク表は、親ノードを表わす行を、この親ノードの子ノードを表わす行にリンクする。データベースサーバはリソース表の表オブジェクトタイプ（リソース表タイプ）と、リンク表についての表オブジェクトタイプ（リンク表タイプ）とを定義する。階層索引についてのCREATE INDEXのＤＤＬコマンドは、リソース表タイプの実例である表と、リンク表タイプの実例である表とを指定する。リンク表タイプは、親ノードを子ノードに対応付けるためのノードＩＤを保持する列属性（たとえば表３０２の＜親＞および＜子＞）を定義する。リソース表タイプはノードＩＤについての列属性（表３０２の＜ノード＞）を定義する。階層索引を作成するためのＤＤＬ索引ルーチンは、タイプリソース表タイプおよびリンク表タイプの仮数を取る。

ハードウェア概観
図５は、この発明の一実施例が実現され得るコンピュータシステム５００を例示するブロック図である。コンピュータシステム５００は、バス５０２またはその他の情報通信用通信機構と、バス５０２と結合され情報を処理するためのプロセッサ５０４とを含む。コンピュータシステム５００はさらに主メモリ５０６、たとえばランダムアクセスメモリ（ＲＡＭ）またはその他の動的記憶装置を含み、これはバス５０２に結合されて、プロセッサ５０４の実行する命令および情報を記憶する。主メモリ５０６はさらに、プロセッサ５０４の実行する命令の実行中に一時変数またはその他の中間情報を記憶するのにも用いられ得る。コンピュータシステム５００はさらに、バス５０２と結合され、プロセッサ５０４のための静的情報および命令を記憶するための、読出専用メモリ（ＲＯＭ）５０８またはその他の静的記憶装置を含む。情報および命令を記憶するための記憶装置５１０、たとえば磁気ディスクまたは光ディスクが設けられてバス５０２に結合される。

コンピュータシステム５００はバス５０２を介して、情報をコンピュータユーザに対して表示するための表示装置５１２、たとえば陰極線管（ＣＲＴ）などに結合され得る。英数字式キーまたはその他のキーを含む入力装置５１４がバス５０２に結合され、情報およ
びコマンド選択をプロセッサ５０４へ通信する。もう１つの種類のユーザ入力装置としてカーソル操作装置５１６があり、これにはたとえばマウス、トラックボールまたはカーソルキーなどがあり、方向情報およびコマンド選択をプロセッサ５０４に通信し、表示装置５１２上のカーソルの動きを操作する。一般的にこの入力装置は、第１の軸（たとえばｘ）および第２の軸（たとえばｙ）の２本の軸上における２自由度を有し、これにより入力装置は或る平面上の位置を指定することができる。

この発明は、コンピュータシステム５００を使用してここに記載された技術を実現することに関する。この発明の一実施例に従うと、プロセッサ５０４が、主メモリ５０６に入っている１つ以上の命令からなる１つ以上のシーケンスを実行するのに応答して、ここに記載された技術がコンピュータシステム５００により実行される。このような命令は別のコンピュータ可読媒体、たとえば記憶装置５１０から主メモリ５０６に読込まれ得る。主メモリ５０６に入っている命令シーケンスの実行は、プロセッサ５０４がここに記載されたプロセスステップを行なうことを引起す。これに代わる実施例では、ソフトウェア命令の代わりに、またはこれと組合せて、ハードウェア回路を用いてこの発明を実現することもある。したがってこの発明の実施例は、ハードウェア回路およびソフトウェアのいかなる特定の組合せにも限定されない。

ここで用いる「コンピュータ可読媒体」という用語は、命令をプロセッサ５０４が実行できるようここに供給することに関与するあらゆる媒体を指す。このような媒体は多くの形態をとることができ、これには不揮発性媒体、揮発性媒体および伝送媒体が含まれるがこれに限定されない。不揮発性媒体にはたとえば、記憶装置５１０などの光ディスクまたは磁気ディスクが含まれる。揮発性媒体には主メモリ５０６などの動的記憶装置が含まれる。伝送媒体には同軸ケーブル、銅線および光ファイバが含まれ、これにはバス５０２を構成するワイヤが含まれる。伝送媒体はまた音波または光波の形態をとることもでき、これにはたとえば電波通信および赤外線データ通信の際に生成されるものなどがある。

コンピュータ可読媒体の一般的な形態にはたとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、またはその他任意の磁気媒体、ＣＤ−ＲＯＭ、その他任意の光媒体、パンチカード、紙テープ、その他任意の孔パターンによる物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、その他任意のメモリチップまたはカートリッジ、後に記載する搬送波、またはその他コンピュータが読出可能な任意の媒体が含まれる。

１つ以上の命令からなる１つ以上のシーケンスを、プロセッサ５０４が実行できるようここへ伝達することには、さまざまな形態のコンピュータ可読媒体が関与し得る。たとえば、命令はまず遠隔コンピュータの磁気ディスクに収められ得る。この遠隔コンピュータは命令を自分の動的メモリにロードして、モデムを用いて電話回線経由でこれら命令を送信し得る。コンピュータシステム５００に対してローカルなモデムが電話回線上のデータを受信し、赤外線送信機を用いてこのデータを赤外線信号に変換し得る。赤外線信号で搬送されたデータは赤外線検出器で受信されて、適当な回路がこのデータをバス５０２に出力することになる。バス５０２はデータを主メモリ５０６へと伝達し、ここからプロセッサ５０４は命令を検索および実行する。任意には、主メモリ５０６が受取った命令は、プロセッサ５０４による実行前または実行後に記憶装置５１０で記憶され得る。

コンピュータシステム５００はさらに、バス５０２に結合された通信インターフェイス５１８を含む。通信インターフェイス５１８は、ローカルネットワーク５２２に接続されたネットワークリンク５２０に対する２方向データ通信結合を行なうためのものである。たとえば通信インターフェイス５１８は統合デジタル通信サービス網（ＩＳＤＮ）カードまたはモデムであることがあり、これにより対応する種類の電話回線に対するデータ通信
接続を行なう。別の例として、通信インターフェイス５１８はローカルエリアネットワーク（ＬＡＮ）カードであってもよく、これにより対応するＬＡＮに対するデータ通信接続を行なう。無線リンクもまた実現可能である。このような実現例のいずれにおいても、通信インターフェイス５１８は、さまざまな種類の情報を表わすデジタルデータの流れを搬送する電気信号、電磁信号または光信号を送受信する。

一般的にネットワークリンク５２０は、１つ以上のネットワーク経由で他のデータ装置に対するデータ通信を可能にする。たとえばネットワークリンク５２０はローカルネットワーク５２２経由で、ホストコンピュータ５２４、または、インターネットサービスプロバイダ（ＩＳＰ）５２６の動作させるデータ装置に対する接続を行ない得る。このＩＳＰ５２６は、現在一般的に「インターネット」と称される全世界規模パケットデータ通信網５２８を通じてデータ通信サービスを提供する。ローカルネットワーク５２２およびインターネット５２８はともに、デジタルデータの流れを搬送する電気信号、電磁信号または光信号を使用する。このようにさまざまなネットワークを経由する信号や、デジタルデータをコンピュータシステム５００に入出力するネットワークリンク５２０上および通信インターフェイス５１８経由の信号は、情報を運ぶ搬送波の形態の例である。

コンピュータシステム５００は、ネットワーク、ネットワークリンク５２０および通信インターフェイス５１８を通じてメッセージを送信し、プログラムコードを含むデータを受信することができる。インターネットの例では、サーバ５３０は或るアプリケーションプログラムについての要求されたコードを、インターネット５２８、ＩＳＰ５２６、ローカルネットワーク５２２、そして通信インターフェイス５１８経由で送信し得る。

受信されたコードは、受信されるとプロセッサ５０４により実行され、かつ／または記憶装置５１０もしくはその他の不揮発性記憶装置内で、後で実行されるように記憶され得る。このようにコンピュータシステム５００は搬送波の形でアプリケーションコードを入手し得る。

以上の明細書においては、この発明をその特定の実施例を参照して記載した。しかし、この発明のより広い意味および範囲から逸脱することなく、さまざまな変形および変更がこの発明で可能であることが明らかであろう。したがってこの明細書および図面は、限定としてでなく例示的な意味で考えられるべきである。

階層型ファイルシステムを例示するブロック図である。 情報階層を例示するブロック図である。 この発明の一実施例に従うリレーショナルシステム内で、図２に例示する情報階層を捕捉するために用いられ得る表を例示するブロック図である。 この発明の一実施例に従う階層索引となるデータベース表のブロック図である。 この発明の実施例が実現され得るシステムのブロック図である。

Claims (18)

1. 索引を有するコンピュータ可読媒体であって、
   前記索引は、１つ以上のフィールドを含む表を索引付けし、
   前記索引は、前記１つ以上のフィールドのうち少なくとも１つに関連付けられたキー値に基づいて配置されて順序付けられ、
   前記索引には複数の索引エントリが入っており、前記索引エントリの各エントリは、
   前記表内の少なくとも１つの対応する行へ対応付けし、かつ、
   前記キー値とは独立に定義されたデータであって、前記少なくとも１つの対応する行にアクセスするためのユーザアクセス権限を定義する第１のアクセス制御データを含む、コンピュータ可読媒体。
2. 前記表には、階層内のノードに関連付けられた行が入っており、
   前記索引に格納されていない第２のアクセス制御データは、前記表における前記行にアクセスするためのユーザアクセス権限を定義し、
   前記第１のアクセス制御データは、前記第２のアクセス制御データにより定義される前記ユーザアクセス権限を反映する、請求項１に記載のコンピュータ可読媒体。
3. 前記複数の索引エントリは階層内のノードに関連付けられ、
   前記第１のアクセス制御データは、１人以上のユーザが、前記ノードのうち１つ以上のノードを探査するためのユーザアクセス権限を有することを示す、請求項１に記載のコンピュータ可読媒体。
4. 一連のパス要素を有するパス名を解決するために用いられる方法であって、
   前記一連のパス要素からの特定のパス要素に対応する索引内の第１のエントリにアクセスするステップと、
   前記第１のエントリ内のアクセス制御データに基づいて、ユーザが、特定のやり方で前記特定のパス要素に関連付けられた第１の項目にアクセスできるかどうかを判断するステップとを含み、
   前記索引は、データベース文に応答してデータベースサーバにより更新可能であり、前記データベースサーバは、前記索引を用いて前記データベース文を実行し、
   前記データベース文は、前記索引を参照することなく、前記一連のパス要素に含まれる少なくとも１つのパス要素の内容を含む表を参照し、前記表を使用する演算を特定する、方法。
5. 少なくとも１つのパス要素は前記一連のパス要素のうちの前記特定のパス要素に従い、
   前記ユーザが前記特定のやり方で前記第１の項目にアクセスできる場合にのみ、前記少なくとも１つのパス要素に対応する前記索引内のエントリにアクセスすることを試みるステップをさらに含む、請求項４に記載の方法。
6. 前記第１の項目は、階層内のノードに対応する行が入っている表内の行である、請求項４に記載の方法。
7. 項目は階層内のノードに対応し、前記第１の項目は前記階層内の特定のノードに対応し、
   ユーザが第１の項目にアクセスできるかどうかを判断する前記ステップは、ユーザが前記特定のノードについてのいずれかの子孫ノードにアクセスすることを許されているかどうかを判断するステップを含む、請求項４に記載の方法。
8. 一連のパス要素を有するパス名を解決するための方法をコンピュータに実現させるためのプログラムを格納したコンピュータ可読媒体であって、前記プログラムは１つ以上のプロセッサに、
   前記一連のパス要素からの特定のパス要素に対応する索引内の第１のエントリにアクセスするステップと、
   前記第１のエントリ内のアクセス制御データに基づき、ユーザが特定のやり方で前記特定のパス要素に関連付けられた第１の項目にアクセスできるかどうかを判断するステップと、を実行させる、コンピュータ可読媒体。
9. 少なくとも１つのパス要素は前記一連のパス要素のうちの前記特定のパス要素に従い、
   前記ユーザが前記特定のやり方で前記第１の項目にアクセスできる場合にのみ、前記少なくとも１つのパス要素に対応する前記索引内のエントリにアクセスすることを試みるステップをさらに含む、請求項８に記載のコンピュータ可読媒体。
10. 前記第１の項目は、階層内のノードに対応する行が入っている表内の行である、請求項８に記載のコンピュータ可読媒体。
11. 項目は階層内のノードに対応し、前記第１の項目は前記階層内の特定のノードに対応し、
    ユーザが第１の項目にアクセスできるかどうかを判断する前記ステップは、ユーザが前記特定のノードについてのいずれかの子孫ノードにアクセスすることを許されているかどうかを判断するステップを含む、請求項８に記載のコンピュータ可読媒体。
12. データベースシステムであって、
    索引をデータベースに含み、
    前記索引は、１つ以上のフィールドを含み、
    前記索引は、複数の索引エントリを含み、
    前記索引は、前記１つ以上のフィールドのうちの少なくとも１つに関連付けられたキー値に基づいて配列されて順序付けられており、
    前記複数の検索エントリの各々は、表内の少なくとも１つの対応する行に対応しており、
    前記複数の検索エントリの各々は、前記キー値とは独立に定義された第１のアクセス制
    御データを含み、前記第１のアクセス制御データは、前記少なくとも１つの対応する行にアクセスするための権限を規定しており、
    前記データベースシステムは、データベース文に応答して前記索引を更新するように構成されており、前記データベースシステムは、前記索引を用いて前記データベース文を実行し、
    前記データベース文は、前記索引を参照することなく前記一連のパス要素に含まれる少なくとも１つのパス要素の内容を含む表を参照し、前記表を使用する演算を特定する、データベースシステム。
13. 前記表は、階層内のノードに関連付けられた行を含み、
    前記データベースは、第２のアクセス制御データを含み、前記第２のアクセス制御データは、前記索引の外部に格納されており、前記行にアクセスするためのユーザアクセス権限を定義しており、
    前記第１のアクセス制御データは、前記第２のアクセス制御データにより定義された前記ユーザアクセス権限を反映している、請求項１２に記載のデータベースシステム。
14. 前記複数の索引エントリは、階層内の複数のノードに関連付けられており、
    前記第１のアクセス制御データは、１人以上のユーザが前記複数のノードのうちの１つ以上のノードを探査するためのユーザアクセス権限を有していることを示している、請求項１２に記載のデータベースシステム。
15. データベースシステムであって、
    索引を含み、
    前記データベースシステムは、一連のパス要素を有するパス名を解決するように構成されており、
    前記データベースシステムは、
    前記一連のパス要素から特定のパス要素に対応する索引において第１のエントリにアクセスするように、および、
    前記第１のエントリにおけるアクセス制御データに基づいて、ユーザが特定の方法で前記特定のパス要素に関連付けられた第１の項目にアクセスできるか否かを判断するように構成されることにより、一連のパス要素を有するパス名を解決するように構成されており、
    前記データベースシステムは、データベース文に応答して前記索引を更新するように構成されており、前記データベースシステムは、前記索引を用いて前記データベース文を実行し、
    前記データベース文は、前記索引を使用することなく、前記一連のパス要素に含まれる少なくとも１つのパス要素の内容を含む表を参照し、前記表を使用する操作を特定する、データベースシステム。
16. 少なくとも１つのパス要素は、前記一連のパス要素における前記特定のパス要素に続き、
    前記ユーザが前記特定の方法で前記第１の項目にアクセスできる場合にのみ、前記データベースシステムは、前記少なくとも１つのパス要素に対応する前記索引におけるエントリにアクセスすることを試みるように構成されている、請求項１５に記載のデータベースシステム。
17. 前記第１の項目は、階層内のノードに対応する行を含む表の１つの行である、請求項１５に記載のデータベースシステム。
18. 前記第１の項目は、階層内の特定のノードに対応しており、
    前記第１のエントリにおけるアクセス制御データに基づいて、ユーザが、特定の方法で前記特定のパス要素に関連付けられた第１の項目にアクセスできるか否かを判断するように構成されていることは、前記ユーザが、前記特定のノードの子孫ノードのいずれかにアクセスすることが許可されているか否かを判断するように構成されていることを含む、請求項１５に記載のデータベースシステム。

Images