(57)【要約】階層構造の外部に維持される既存のデータには或る階層が明示的または内在的に反映されていることがある。このような階層をここで「先在階層」と称する。階層構造における先在階層を捕捉するための技術をここに記載する。先在階層の捕捉後には、階層を反映する独立した２組のデータ、すなわち外部階層定義および内部階層定義が存在する。いずれの階層定義を変更しても階層には変更が生じる。したがって、階層の整合的な反映を維持するために、外部階層定義になされた変更に応じて内部階層定義に変更を加え、内部階層定義になされた変更に応じて外部階層定義に変更を加える必要がある。これら２つの階層定義間で整合性を維持するためのさまざまな技術を記載する。
2005505042.tif 000002
【特許請求の範囲】
【請求項１】
データベースシステムにおいてデータを管理する方法であって、
情報階層に属するリソースを格納する１つ以上のリレーショナル表を識別するデータを受取るステップを含み、前記１つ以上のリレーショナル表内の或るデータは、前記リソース間の階層関係を確立する外部階層定義となり、前記方法はさらに、
前記階層内の階層関係を捕捉するステップを含み、前記捕捉するステップは、
前記或るデータを検索するために１つ以上の問合せを前記１つ以上のリレーショナル表に対して実行するステップと、
前記或るデータに基づいて、前記１つ以上のリレーショナル表とは別個の１つ以上の階層構造内に内部階層定義として前記情報階層を捕捉する情報を格納するステップとを行なうことによる、方法。
【請求項２】
前記情報階層を捕捉する情報を格納する前記ステップは、前記情報階層内の各々のノードについての行をリソース表内に格納するステップを含む、請求項１に記載の方法。
【請求項３】
前記情報階層を捕捉する情報を格納する前記ステップは、前記リソース間の親子関係を示す情報を１つ以上の階層構造に内に格納するステップを含む、請求項１に記載の方法。
【請求項４】
情報階層にあるリソースはリレーショナル表における行に対応し、
リソース間の親子関係は、リレーショナル表における２つ以上の列に格納された値によって表わされる、請求項１に記載の方法。
【請求項５】
前記１つ以上の問合せを実行するステップは、前記２つ以上の列間でCONNECT BY関係を指定する問合せを実行するステップを含む、請求項４に記載の方法。
【請求項６】
前記２つ以上の列は、関係における子を示すデータが入っている第１の列と、前記関係における親を示すデータが入っている第２の列とを含み、
前記問合せを実行するステップは、START WITH x IS NULL CONNECT BY PRIOR x=yの式の表現が入っている問合せを実行するステップを含み、
ｘは第２の列を表わし、ｙは第１の列を表わす、請求項５に記載の方法。
【請求項７】
情報階層における葉ノードに関連付けられたリソースはリレーショナル表における行に対応し、
情報階層内において、所与の葉ノードよりも上にある葉でないノードに関連付けられた値は、前記所与の葉ノードに対応する行に格納される、請求項１に記載の方法。
【請求項８】
葉でないノードに関連付けられた値は、前記リレーショナル表における１つ以上の列に格納され、
前記情報階層を捕捉する情報を格納する前記ステップは、情報階層における葉ノードに対応する列から、前記１つ以上の列内で、各々の別個の値についての行を、リソース表内に格納するステップを含む、請求項７に記載の方法。
【請求項９】
さらに、外部階層定義を構成するデータになされた変更に応じて、前記内部階層定義を構成するデータを更新するためのトリガを確立するステップを含む、請求項１に記載の方法。
【請求項１０】
さらに、内部階層定義を構成するデータになされた変更に応じて、前記外部階層定義を構成するデータを更新するためのトリガを確立するステップを含む、請求項１に記載の方法。
【請求項１１】
さらに、前記外部階層定義と前記内部階層定義との間に整合性を自動的に維持するステップを含む、請求項１に記載の方法。
【請求項１２】
前記整合性を自動的に維持するステップは、
前記１つ以上の表に対する演算が情報階層におけるノードに関連付けられたリソースを削除するときを検出するステップと、
前記演算の検出に応答して以下のステップを自動的に行なうステップとを含み、前記ステップは、
前記ノードに対応する行をリソース表において削除するステップと、
前記情報階層から前記ノードをなくすことによって１つ以上の他のノードが宙吊りになるかどうかを判断するステップと、
前記情報階層から前記ノードをなくすことによって１つ以上の他のノードが宙吊りになる場合、前記１つ以上の他のノードに対応する行をリソース表において削除するステップとを含む、請求項１１に記載の方法。
【請求項１３】
前記整合性を自動的に維持するステップは、
前記１つ以上の表に対する演算が情報階層における葉ノードに関連付けられたリソースを削除するときを検出するステップと、
前記演算の検出に応答して以下のステップを自動的に行なうステップとを含み、前記ステップは、
前記ノードに対応する行をリソース表において削除するステップと、
前記情報階層から前記葉ノードをなくすことによって、前記葉ノードの親ノードに他に子ノードがいなくなるかどうかを判断するステップと、
前記情報階層から前記葉ノードをなくすことによって、前記葉ノードの親ノードに他に子ノードがいなくなる場合、前記親ノードに対応する行をリソース表において削除するステップとを含む、請求項１１に記載の方法。
【請求項１４】
前記整合性を自動的に維持するステップは、
前記１つ以上の表に対する演算が情報階層においてノードに関連付けられたリソースを挿入するときを検出するステップと、
前記演算の検出に応答して以下のステップを自動的に行なうステップとを含み、前記ステップは、
リソース表において、前記ノードに対応する行を挿入するステップと、
前記情報階層からの前記ノードの追加が、前記情報階層への前記ノードについての１つ以上の子ノードの追加を引起こすかどうかを判断するステップと、
前記情報階層からの前記ノードの追加が、前記情報階層への前記ノードについての１つ以上の子ノードの追加を引起こす場合、リソース表において、前記１つ以上の子ノードに対応する行を挿入するステップとを含む、請求項１１に記載の方法。
【請求項１５】
データベースシステムにおいてデータを管理するための情報を保持するコンピュータ可読媒体であって、前記命令は、
情報階層に属するリソースを格納する１つ以上のリレーショナル表を識別するデータを受取るステップを行なうための命令を含み、前記１つ以上のリレーショナル表内の或るデータは、前記リソース間の階層関係を確立する外部階層定義となり、前記命令はさらに、
前記階層内の階層関係を捕捉するステップを行なう命令を含み、前記捕捉するステップは、
前記或るデータを検索するために１つ以上の問合せを前記１つ以上のリレーショナル表に対して実行するステップと、
前記或るデータに基づいて、前記１つ以上のリレーショナル表とは別個の１つ以上の階層構造内に内部階層定義として前記情報階層を捕捉する情報を格納するステップとを行なうことによる、コンピュータ可読媒体。
【請求項１６】
前記情報階層を捕捉する情報を格納する前記ステップは、前記情報階層内の各々のノードについての行をリソース表内に格納するステップを含む、請求項１５に記載のコンピュータ可読媒体。
【請求項１７】
前記情報階層を捕捉する情報を格納する前記ステップは、前記リソース間の親子関係を示す情報を１つ以上の階層構造内に格納するステップを含む、請求項１５に記載のコンピュータ可読媒体。
【請求項１８】
情報階層にあるリソースはリレーショナル表における行に対応し、
リソース間の親子関係は、リレーショナル表における２つ以上の列に格納された値によって表わされる、請求項１５に記載のコンピュータ可読媒体。
【請求項１９】
前記１つ以上の問合せを実行するステップは、前記２つ以上の列間でCONNECT BY関係を指定する問合せを実行するステップを含む、請求項１８に記載のコンピュータ可読媒体。
【請求項２０】
前記２つ以上の列は、関係における子を示すデータが入っている第１の列と、前記関係における親を示すデータが入っている第２の列とを含み、
前記問合せを実行するステップは、START WITH x IS NULL CONNECT BY PRIOR x=yの式の表現が入っている問合せを実行するステップを含み、
ｘは第２の列を表わし、ｙは第１の列を表わす、請求項１９に記載のコンピュータ可読媒体。
【請求項２１】
情報階層における葉ノードに関連付けられたリソースはリレーショナル表における行に対応し、
情報階層内において、所与の葉ノードよりも上にある葉でないノードに関連付けられた値は、前記所与の葉ノードに対応する行に格納される、請求項１５に記載のコンピュータ可読媒体。
【請求項２２】
葉でないノードに関連付けられた値は、前記リレーショナル表における１つ以上の列に格納され、
前記情報階層を捕捉する情報を格納する前記ステップは、情報階層における葉ノードに対応する列から、前記１つ以上の列内で、各々の別個の値についての行を、リソース表内に格納するステップを含む、請求項２１に記載のコンピュータ可読媒体。
【請求項２３】
さらに、外部階層定義を構成するデータになされた変更に応じて、前記内部階層定義を構成するデータを更新するためのトリガを確立するステップを行なうための命令を含む、請求項１５に記載のコンピュータ可読媒体。
【請求項２４】
さらに、内部階層定義を構成するデータになされた変更に応じて、前記外部階層定義を構成するデータを更新するためのトリガを確立するステップを行なうための命令を含む、請求項１５に記載のコンピュータ可読媒体。
【請求項２５】
さらに、前記外部階層定義と前記内部階層定義との間に整合性を自動的に維持するステップを行なうための命令を含む、請求項１５に記載のコンピュータ可読媒体。
【請求項２６】
前記整合性を自動的に維持するステップは、
前記１つ以上の表に対する演算が情報階層におけるノードに関連付けられたリソースを削除するときを検出するステップと、
前記演算の検出に応答して以下のステップを自動的に行なうステップとを含み、前記ステップは、
前記ノードに対応する行をリソース表において削除するステップと、
前記情報階層から前記ノードをなくすことによって１つ以上の他のノードが宙吊りになるかどうかを判断するステップと、
前記情報階層から前記ノードをなくすことによって１つ以上の他のノードが宙吊りになる場合、前記１つ以上の他のノードに対応する行をリソース表において削除するステップとを含む、請求項２５に記載のコンピュータ可読媒体。
【請求項２７】
前記整合性を自動的に維持するステップは、
前記１つ以上の表に対する演算が情報階層における葉ノードに関連付けられたリソースを削除するときを検出するステップと、
前記演算の検出に応答して以下のステップを自動的に行なうステップとを含み、前記ステップは、
前記ノードに対応する行をリソース表において削除するステップと、
前記情報階層から前記葉ノードをなくすことによって、前記葉ノードの親ノードに他に子ノードがいなくなるかどうかを判断するステップと、
前記情報階層から前記葉ノードをなくすことによって、前記葉ノードの親ノードに他に子ノードがいなくなる場合、前記親ノードに対応する行をリソース表において削除するステップとを含む、請求項２５に記載のコンピュータ可読媒体。
【請求項２８】
前記整合性を自動的に維持するステップは、
前記１つ以上の表に対する演算が、情報階層においてノードに関連付けられたリソースを挿入するときを検出するステップと、
前記演算の検出に応答して以下のステップを自動的に行なうステップとを含み、前記ステップは、
リソース表において、前記ノードに対応する行を挿入するステップと、
前記情報階層からの前記ノードの追加が、前記情報階層への前記ノードについての１つ以上の子ノードの追加を引起こすかどうかを判断するステップと、
前記情報階層からの前記ノードの追加が、前記情報階層への前記ノードについての１つ以上の子ノードの追加を引起こす場合、リソース表において、前記１つ以上の子ノードに対応する行を挿入するステップとを含む、請求項２５に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本願は、以下の米国仮特許出願の優先権を主張するものであり、これらの内容全体はあらゆる目的についてここに引用により援用される。
【０００２】
エリック・セドラー（Eric Sedlar）およびビスワナサン・クリシュナマーシー（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）」と題された、同日に出願の米国特許出願番号第 号（代理人事件番号第５０２７７−１９７５号）、
ラビ・マーシー、ムラリドハル・クリシュナプラサド、シバサンカラン・チャンドラセカル、エリック・セドラー、ビシュ・クリシュナマーシー（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）」と題された、同日出願の米国特許出願番号第 号（代理人事件番号第５０２７７−１９８１号）、
ニーマ・ジャラリ、エリック・セドラー、ニプン・アガーウォルおよびラビ・マーシーによる「リレーショナルデータベースシステムにおいて階層型アクセスを提供する構造化されたデータを効率的に索引付けする機構（MECHANISM TO EFFICIENTLY INDEX STRUCTURED DATA THAT PROVIDES HIERARCHICAL ACCESS IN A RELATIONAL DATABASE SYSTEM）」と題された、同日出願の米国特許出願番号第 号（代理人事件番号第５０２７７−１９８２号）。
【０００５】
発明の分野
この発明は、階層に従って組織された情報をリレーショナルデータベースに格納することに関し、より特定的には、階層を捕捉するメタデータを管理するための技術に関する。
【背景技術】
【０００６】
発明の背景
人間には情報を範疇に従って組織するという性向がある。そして情報を組織するのに用いる範疇自体もまた、或る形の階層内で互いに関連させて組織されることが多い。たとえば個々の動物は或る種に属し、この種は属に属し、属は科に属し、科は目に属し、そして目は綱に属する、といった具合である。
【０００７】
コンピュータシステムの到来に伴い、電子情報を格納するための技術は、この階層型組織に対する人間の欲求を大部分反映するように開発されてきた。たとえば一般的に、従来のコンピュータファイルシステムは階層に基づく組織原理を用いて実現されている。具体的には、典型的なファイルシステムは階層内に配置されたディレクトリを有し、文書がこのディレクトリに格納される。ディレクトリ間の階層関係は、ディレクトリに割当てられた意味同士の或る直感的にわかる関係を反映していることが理想的である。同様に、各々の文書をディレクトリ内に格納する際、この文書の内容と、この文書が格納されるディレクトリに割当てられた意味との或る直感的にわかる関係に基づいていることが理想的である。
【０００８】
図１は典型的なファイルシステムの一例を示す。ここに例示するファイルシステムは階層内に配置された数多くのディレクトリを含む。２つの文書１１８，１２２がディレクトリ内に格納される。具体的には、文書１１８，１２２の両方とも“Example.doc”と名称を与えられてそれぞれディレクトリ１１６，１２４内に格納され、これらはそれぞれ“Word”および“App4”と名称を与えられている。
【０００９】
このディレクトリ階層において、ディレクトリ１１６は、“Windows”と名称を与えられたディレクトリ１１４の子であり、ディレクトリ１１４はディレクトリ１１０の子である。同様に、ディレクトリ１２４は“ＶＭＳ”と名称を与えられたディレクトリ１２６の子であり、ディレクトリ１２６はディレクトリ１１０の子である。ディレクトリ１１０は「根（root）」ディレクトリと称されるが、それはこのディレクトリからその他すべてのディレクトリが降りていくからである。多くのシステムでは根ディレクトリを参照するのに記号“／”が用いられる。
【００１０】
電子情報が階層内に組織される場合、各々の情報項目の場所を探し当てるには、「パス」に従って階層内を通り、この項目が入っている実体にたどり着くことになる。階層型ファイルシステムにおいては、或る項目に至るパスは根ディレクトリから始まってディレクトリ階層を下って進み、最終的に当該の項目が入っているディレクトリに到着する。たとえば、ファイル１１８へのパスは順にディレクトリ１１０，１１４，１１６から構成される。
【００１１】
階層型記憶システムでは、異なる項目が同一名称を有してもよいことが多い。たとえば、図１に示すファイルシステムでは、文書１１８と文書１２２とは両方とも“Example.doc”の名称が与えられている。したがって、所与の文書を一義的に識別するには文書の名称以上のものが必要である。
【００１２】
階層型記憶システムに格納された情報の特定の項目を識別しその場所を突き止める従来のやり方として「パス名」を使用することが挙げられる。パス名は、或る項目を、階層を通じてこの項目に至るパスに基づいて一意に識別する簡潔な方策である。パス名は一連の名称から構成される。ファイルシステムに関しては、一連の名称における各々の名称は「ファイル名」である。「ファイル名」という用語はディレクトリの名称と文書の名称との両方を指すが、それはディレクトリも文書も「ファイル」とみなされるからである。
【００１３】
ファイルシステム内では、所与のパス名における一連のファイル名は根ディレクトリの名称から始まり、根ディレクトリから当該の項目に至るパス上にあるディレクトリすべての名称を含み、当該の項目の名称で終わる。一般的には、探査するディレクトリのリストは、或る種の分離子（たとえば‘／’、‘＼’または‘；’）によって互いに連結されてパス名をなす。したがって文書１１８についてのパス名は/Windows/Word/Example.docとなり、文書１２２についてのパス名は/VMS/App4/Example.docとなる。
【００１４】
ディレクトリ（ファイル）同士およびそこに入っている内容同士の関係は、階層型として組織されたシステムのタイプによって大幅に変わってくる。Windows（登録商標）およびＤＯＳファイルシステムなどさまざまな実現例で採用される１つのモデルでは、各々のファイルは正しく１つの親を有して木をなすことが必要である。より複雑なモデルにおいては、階層は、ファイルに多数の親がある有向グラフの形をとり、これはたとえばハードリンクを使用するＵＮＩＸ（登録商標）ファイルシステムに見られる。
【００１５】
電子情報を組織するための階層型の手法とは対照的に、リレーショナルデータベースでは情報は行および列からなる表（table）に格納される。各々の行は一意の行ＩＤによって識別される。各々の列はレコードの属性を表わし、各々の行は特定のレコードを表わす。データをデータベースから検索するには、データベースを管理するデータベース管理システム（ＤＢＭＳ）に問合せを提出する。問合せは、データベース管理システムがサポートするデータベース言語に適合している必要がある。多くの既存のデータベース管理システムがサポートするデータベース言語の一例として構造化問合せ言語（ＳＱＬ）がある。
【００１６】
記憶システムについての各々のタイプには利点と限界とがある。階層型として組織された記憶システムは単純で直感的にわかりやすく、かつ実現が容易であるため、ほとんどのアプリケーションプログラムで用いられる標準的なモデルとなっている。しかし残念ながら、この単純な階層型組織では複雑なデータ検索動作に必要なサポートが得られない。たとえば、特定のファイル名を有する特定の日に作成された文書すべてを検索するには各々のディレクトリの内容を調べなければならないであろう。ディレクトリをすべて探索しなければならないので、階層型組織は検索プロセスを容易にするのに全く寄与していない。
【００１７】
一方、リレーショナルデータベースは大量の情報の記憶および極めて柔軟なデータアクセスによく適している。階層型として組織されたシステムに対して、リレーショナルデータベースシステムからは、複雑な探索基準に合致するデータも容易かつ効率的に検索され得る。しかし問合せを作成してデータベースに提出するプロセスは、階層をなすディレクトリを単に探査するよりも直感的にわかりにくく、多くのコンピュータユーザにとっての技術的な快適度の埒外である。
【００１８】
過去において、階層型として組織されたシステムとリレーショナル型として組織されたシステムとは、互いに相容れない異なるやり方で実現されていた。しかしながら、いくらかの処理を追加することでリレーショナル型として組織されたシステムは階層型として組織されたシステムを模倣することができる。この種のエミュレーションは、リレーショナルシステムの記憶能力および柔軟性が必要でありかつ階層型システムの直感的なわかりやすさおよび遍在性が望まれる場合に特に望まれている。
【発明を実施するための最良の形態】
【００１９】
添付の図面の各図においてこの発明を示すが、これは例示的なものであって限定的なものではない。図面においては同様の参照番号は同様の要素を指す。
【００２０】
発明の実施例の詳細な説明
情報階層に属するリソースをリレーショナルデータベースシステム内の構造に格納するための方法およびシステムについて説明する。以下の記載においては、この発明の完全な理解をもたらすために説明上数多くの特定の詳細について述べる。しかしながら、この発明はこれら特定の詳細なしに実施可能であることが明らかであろう。他の場合には、この発明を不必要に不明瞭にすることを避けるために、周知の構造および装置をブロック図の形で示す。
【００２１】
機能の概観
リレーショナルデータベースシステム内での階層型データの管理を容易にするためのさまざまな技術をここに記載する。一実施例に従うと、階層に属するリソースの内容を格納するのに用いる記憶構造（「内容構造」）は、階層についての情報を捕捉するデータを格納するのに用いる記憶構造（「階層構造」）とは別個のものである。
【００２２】
状況によっては、階層構造の外部に維持される既存のデータ内に或る階層が明示的または内在的に既に反映されていることがある。このような階層をここで「先在（pre-existing）階層」と称する。このような状況では、この階層構造内の先在階層を捕捉して、階層構造をリソースへの代替的なアクセスパスとして使えるようにすることが望ましい。たとえば階層構造を用いてパス情報に基づきリソースにアクセスできる。さらに、リソースにアクセスするために問合せを内容構造に対して直接発行する場合でも、アクセス動作は、階層構造に関連付けられたあらゆる機能およびアクセス構造、たとえば階層構造内へ組込まれたあらゆる安全保護機構や、リソースへその階層内の位置に基づいてアクセスする動作の性能を向上させるように組込まれたあらゆる索引などから利益を得る。
【００２３】
各々の先在階層は、（１）階層構造の外部に常駐し、かつ（２）先在階層を反映する、データに関連付けられる。このようなデータをここでは「外部階層定義」と称する。階層構造にある先在階層を捕捉するには、外部階層定義に基づく階層構造にデータ（ここでは「内部階層定義」と称する）を追加する必要がある。
【００２４】
先在階層の捕捉後には、階層を反映する独立の２組のデータが存在する。すなわち外部階層定義および内部階層定義である。いずれの階層定義を変更しても階層の変更が生じる。したがって、階層の整合的な反映を維持するためには、外部階層定義になされた変更に応じて内部階層定義に変更を加える必要があり、内部階層定義になされた変更に応じて外部階層定義に変更を加える必要がある。これら両者の階層定義間で整合性を維持するためのさまざまな技術をここに記載する。
【００２５】
データベースシステム内の階層データの格納
図２は、この発明の実施例の理解を容易にするためにここに記載する例で用いられる階層２００を例示するブロック図である。階層２００は８個のノードを含む。階層における最高のノードを「根」ノードと称する。階層内で各々の枝の端にあるノードは「葉」ノードである。根ノードと葉ノードとの間にあるノードは「中間」ノードである。ここに示す階層では、ノード１，２，３が中間ノードであり、ノード４，５，６は葉ノードである。
【００２６】
情報階層においてノードは情報に対応する。一般的に、各々のノードに関連付けられた１つの情報は或る形の名称および或るタイプの内容を有することになる。たとえば、階層型ファイルシステムに対応する階層では、一般的にノードはファイルに対応することになる（ここで「フォルダ」または「ディレクトリ」はファイルの１種である）。各々のこのようなファイルは或る名称を有し、さらに或る形の内容を有することになる。
【００２７】
多くの状況下で、階層内のノードに関連付けられた名称は一意である必要はない。図２に示す例では、ノード１とノード７との両者の名称は“ａ”である。これらは同一名称を有してはいても別個の異なるノードであり、階層内において異なる位置を占め、全く異なる内容と関連付けられたものであり得る。
【００２８】
画一方式
図３は、リレーショナルデータベースシステムにおける階層２００を表現するのに用いられ得る２つの表（リソース表３０２およびリンク表３５０）のブロック図である。リソース表３０２は階層内の各々のノードにつき１つの行を含む。所与のノードについての行は、この所与のノードに関連付けられた名称と、所与のノードに関連付けられたデータを含む。たとえば行３０４はノード１に対応するものであり、ここには名称“ａ”と、ノード１に関連付けられたデータ３０６とが入っている。リソース表３０２は、階層内のすべてのリソースについてのデータがこれらリソースのデータタイプとは無関係に同じ構造内に格納される点で画一（one-size-fits-all）方式の例となっている。リソース表３０２の例では、リソースの内容を格納するのに用いられるデータ構造は単一の列３０８である。このような列についてのデータタイプはたとえばＬＯＢ（Large Object）タイプ、たとえばＢＬＯＢ（Binary LOB）またはＣＬＯＢ（Character LOB）であり得る。
【００２９】
リンク表３５０は、階層２００内の親子関係の各々につき１つの行を含む。親列３７８は親子関係における親を指定する値を保持し、子列３８０は親子関係における子を指定する値を保持する。たとえば行３５２は、根ノードがノード１の親であることを示す。同様に、行３５４および行３５６はそれぞれノード１がノード２およびノード３の親であることを示す。
【００３０】
階層構造の内容構造からの分離
表３０２および表３５０は階層２００の情報すべてをリレーショナル形式で捕捉する。しかし、階層２００に関連付けられたリソースの内容が、リソース表３０２に表わされる画一手法を用いて格納されていたのでは、リレーショナルデータベースシステムの力を最大限に利用できないことがある。具体的には、リソース表３０２は、階層２００内のノードに関連付けられたリソースの内容を格納するための単一の列を含む。ノードに関連付けられたリソースが単純なデータタイプ、たとえばストリングまたは整数であれば上記の記憶形式で十分であろう。しかし多くの状況下では、階層内のノードに関連付けられたリソースは複雑なデータタイプ、たとえば複雑なレコードまたはＸＭＬ文書である。このような状況下では、単一の列にリソース内容を格納していると、ユーザが内容に対して複雑な探索を実行しにくくなる。リレーショナルデータベースシステムが複雑なリソースの下位要素の値について単一の列内での探索をサポートしていたとしても、このような探索の性能は低下してしまう。
【００３１】
この発明の一実施例に従うと、情報階層に属する複雑なリソースの内容を格納および探索することに伴う問題は、ノードに関連付けられたリソースの内容を、階層情報を捕捉する表とは別個に格納することによって克服される。
【００３２】
たとえば図４は、リソース表３０２に類似するリソース表４０２を示す。しかしリソース表４０２はリソース表３０２と異なり、リソース表４０２は、各々のリソースの内容をこのリソースについての行の列にはもはや格納しない。むしろリソース表３０２の＜データ＞列の代わりに、リソース表４０２には２つの列＜データタイプ＞および＜データ参照＞が設けられる。
【００３３】
リソース表４０２における各々の行につき、＜データタイプ＞列には、当該の行で識別されるノードに関連付けられるリソースのタイプを示すデータが格納される。たとえば行４０４は階層２００のノード１に対応する。行４０４の＜データタイプ＞列は、ノード１に関連付けられたリソースがタイプＴ１のものであることを示す。同様に、行４０６はノード３に対応し、行４０６の＜データタイプ＞列は、ノード３に関連付けられたリソースがタイプＴ５のものであることを示す。
【００３４】
リソース表４０２における各々の行につき、＜データ参照＞列には、当該の行で識別されるノードに関連付けられたリソースに対する参照が格納される。ここで用いられる「参照」という用語は、一般的に、データベースシステム内において他のデータの場所を示すために使用されるあらゆるデータを指す。たとえば＜データ参照＞列にはポインタを格納することもあれば、またはより複雑な情報、たとえばオラクル（Oracle）のデータベースシステムがサポートする“ref”データタイプなどを格納することもできる。この発明は、階層内においてノードに関連付けられたリソースの場所を示すためのデータの特定のタイプには限定されない。
【００３５】
リソースの内容を、リソース間の階層関係を捕捉および反映するのに用いる階層構造とは別個に格納することでさまざまな利益が得られる。たとえば、リソースがリソース表４０２とは別個に格納されるため、リソースが格納される内容構造をリソースの性質に基づいて定義することができる。たとえば、ノード１に関連付けられたリソースは従業員レコードとされ、従業員レコードのフィールドの各々についての列を有する表４５０に格納される。一方、ノード３に関連付けられたリソースは会社レコードとされ、会社レコードのフィールドの各々についての列を有する表４５６に格納される。
【００３６】
また、階層構造（たとえば表４０２および表３５０）は内容構造（たとえば表４５０および表４５６）とは別個であるため、既存のリレーショナルデータについての階層を確立させる際、このデータの記憶への影響は最小限に抑えられ、かつこのデータにアクセスするのに用いる既存の問合せに変更を加える必要がない。たとえば、従業員表４５０は、情報を階層２００に配置する決定よりもはるか以前から存在していたということがあり得る。さらにこの決定に先立って多くの問合せおよびビューが表４５０にアクセスするように定義されていたということがあり得る。表３５０および表４０２は表４５０の既存の構造に影響を及ぼすことなく作成され得るため、表４５０に格納されたリソースを含む階層２００についての階層構造を確立させるために、表４５０や、または、表４５０にアクセスする既存の問合せおよびビューに変更を加える必要がない。
【００３７】
一実施例に従うと、リソース表４０２は、或るリソースのために画一手法を採用するやり方で実現することができ、ここに他のリソースの内容への参照を入れる。たとえば、ノード１に関連付けられたリソースの内容が表４５０に格納され、ノード２に関連付けられたリソースの内容が引続き表４０２内の単一のＬＯＢ列に格納されることがあり得る。＜データタイプ＞列に示すようなリソースのデータタイプは、リソース内容をリソース表４０２のＬＯＢ列内に格納するか、または１つ以上の別個の表に格納するかについて判断する上での１ファクタとしてデータベースサーバにより使用され得る。
【００３８】
先在階層
表４５０は、リソース表４０２およびリンク表３５０などの階層構造とは完全に独立して最初から存在していることがあり得る。この場合、階層構造は最初、表４５０内のデータが属し得るどの階層についてどのような情報をも捕捉していない。しかしながら、このような階層構造の外部に記憶されている情報が表４５０の行間の階層を明示的または内在的に確立させることがあり得る。
【００３９】
表４５０の場合には、このような階層は＜従業員ＩＤ＞および＜管理者＞の列に入っている情報によって内在的に確立される。具体的には、表４５０における＜従業員ＩＤ＞および＜管理者＞の列にあるデータが内在的な「管理階層」を確立し、ここで従業員ＩＤ１に関連付けられた従業員は従業員ＩＤ３に関連付けられた従業員のすぐ下にあり、従業員ＩＤ２に関連付けられた従業員は従業員ＩＤ１に関連付けられた従業員のすぐ下にあり、従業員ＩＤ３に関連付けられた従業員には管理者がいない（すなわち管理階層の根ノードである）。
【００４０】
この例では、管理階層は先在階層であり、＜従業員ＩＤ＞および＜管理者＞の列に格納されたデータは外部階層定義を構成する。この階層構造を使用して管理階層に基づき表４５０内のデータにアクセスするには、管理階層についての情報を階層表で捕捉する必要がある。以下に先在階層についての情報を捕捉するためのさまざまな技術をより詳細に説明する。
【００４１】
先在階層の捕捉
一実施例に従うと、先在階層の捕捉は、（１）先在階層内の各々のノードについての行をリソース表内に格納すること、および（２）先在階層のノード間の親子関係を捕捉する情報を階層構造（たとえば階層索引）に格納することを含む。さらに、先在階層が、階層構造に既に反映されているもっと大きな階層へと接木されている場合、階層構造にメタデータを追加して、先在階層の根ノードをこの大きな階層内の或るノードの子として確立する必要がある。
【００４２】
（１）先在階層内の各々のノードについての行をリソース表内に格納する作業と、（２）先在階層の根ノードをもっと大きな階層に接木するメタデータを追加する作業とを行なう演算は比較的単純である。その一方で、先在階層のノード間の親子関係を捕捉するのに用いられる技術は、外部階層定義の性質に基づいて変わり得る。たとえばＳＱＬリレーションが親子関係を定義している場合、親子情報は適当なCONNECT BY句を用いるＳＱＬコマンドを使用して捕捉され得る。これに代えて、親子関係が階層的に関係付けられたフィールドに基づいて内在していれば、親子情報は列挙法を用いて捕捉され得る。以下にCONNECT BYによる手法と列挙法とについてより詳細に説明する。
【００４３】
先在階層の自動捕捉
一実施例に従うと、データベースサーバは、先在階層についての或る情報を受取るのに応答して自動的に先在階層捕捉動作を行なうように構成される。具体的には、一実施例に従うと、データベースサーバは（１）先在階層に関連付けられた内容構造を識別する情報と、（２）指定された内容構造に入っているリソース間の親子関係を確立させるための基準を示す接続基準とを受取るのに応答して、自動的に捕捉動作を行なうように構成される。
【００４４】
例示のために、表４５０に関連付けられた管理階層を捕捉することが望まれていると仮定する。このような状況下では、（１）表４５０を識別するデータと、（２）表４５０における各々の所与の行が、この所与の行で指定される＜管理者＞に等しい＜従業員ＩＤ＞を有する行の子であることを示すデータとを受取るのに応答して、自動捕捉動作が行なわれ得る。以下、この情報に基づき先在階層を自動的に捕捉するのに用いられ得る技術について説明する。
【００４５】
CONNECT BYを用いた親子関係の捕捉
上述のように、或る先在階層の親子関係はＳＱＬ関係によって示され得る。たとえば、表４５０内のレコードの管理階層は、表４５０の＜管理者＞列に入っているデータによって確立される。このような場合、先在階層の親子関係を捕捉するには、適当なCONNECT BY句を用いたデータベースコマンドを使用することができる。
【００４６】
たとえば、管理階層の自動捕捉動作を行なうためには、（１）リソース表４０２内に、表４５０内の各行に対応するノードを表わす行を作成し、（２）CONNECT BY句を含むＳＱＬ文を実行することでこれらノード間の階層関係についてのメタデータを生成する。表４５０における特定の行についてのノードを表わすリソース表４０２内の各々の行はこの特定の行への参照を有する。たとえばリソース表４０２の行４０４は表４５０の行４２０についてのノードを表わし、したがって行４２０への参照を含んでいる。
【００４７】
先在階層に関連付けられたパス情報を生成することに関し、表４５０が「従業員」という名称を有し、定義として（従業員ＩＤ  INTEGER，名  VARCHAR2(80)，姓  VARCHAR2(80)，年齢  INTEGER，管理者  INTEGER）という列を含むようにされる、と仮定する。このような状況下では、（データに基づき可変の深さの）エントリの木が、CONNECT BY関係たとえば‘START WITH 管理者 IS NULL CONNECT BY PRIOR 管理者＝従業員ＩＤ’を用いて生成され得る。この状況においては、一般的にユーザはさらに或る列値を指定してパス要素の名称（たとえば「姓」）として用いることになる。
【００４８】
列挙法を用いた先在階層の捕捉
場合によっては、先在階層は互いに階層関係を有するフィールドによって内在的に規定され得る。たとえば、販売に供される製品のリストが入っているリレーショナル表について検討する。このような表はたとえば以下のように定義され得る。
【００４９】
CREATE TABLE 製品情報
（
製造業者 VARCHAR2(128)，
製品タイプ VARCHAR 2(48)，
製品名 VARCHAR 2(80)，
ＳＫＵ NUMBER
）;
このような表は、たとえば図５の表５００に例示するように生成され得る。この例では、階層は＜製造業者＞、＜製品タイプ＞、＜製品名＞および＜ＳＫＵ＞のフィールド間の階層関係に内在している。具体的に、各々のＳＫＵ値は、特定の＜製品名＞値と関連付けられた、多数であり得るＳＫＵ値の１つである。各々の＜製品名＞値は、特定の＜製品タイプ＞値と関連付けられた、多数であり得る＜製品名＞値の１つである。各々の＜製品タイプ＞値は、特定の＜製造業者＞値と関連付けられた、多数であり得る＜製品タイプ＞値の１つである。
【００５０】
表５００に入っている値に内在する「製品部門階層」を図６に示す。図６を参照して、表５００の４つの階層的に関係付けられたフィールドの各々は１つの階層レベルに対応し、＜製品業者＞フィールドが最高レベル（根ノードのすぐ下）であり、＜ＳＫＵ＞フィールドは最低のレベル（「葉」ノードを表わす）である。
【００５１】
先在階層がこのように定義されている場合、親子関係を捕捉するために列挙法を採用することができる。具体的には、階層内に含まれた列挙される値が入っている１つ以上の列を用いて「集合ノード（collection node）」を生成する。各々の列の各々の値は階層における特定の深さでの新たな「集合」であり、各々の列が階層内の新たなレベルについて用いられる。ここに与える最後の列は集合としてでなくファイルとして扱われる。
【００５２】
具体的に、階層の第１のレベルのノードを確立するには、＜製造業者＞列に入っている値に対してDISTINCT演算を行なえばよい。階層の第２のレベルのノードを確立するには、すべての行につき＜製造業者＞および＜製品タイプ＞の値を連結し、その結果得られた連結値に対してDISTINCT演算を行なえばよい。同様に、階層の第３のレベルのノードを確立するには、すべての行につき＜製造業者＞、＜製品タイプ＞および＜製品名＞の値を連結し、その結果得られた連結値に対してDISTINCT演算を行なえばよい。最後に、階層の葉レベルを確立するには、すべての行につき＜製造業者＞、＜製品タイプ＞、＜製品名＞および＜ＳＫＵ＞の値を連結し、その結果得られた連結値に対しDISTINCT演算を行なえばよい。
【００５３】
上述の連結演算は、所与のレベルでのノードの名称が一意となるように制約されてはいないという仮定の下で行なわれている。たとえば、＜製品タイプ＞値ＰＤ１の製品の名称は、＜製品タイプ＞値ＰＤ２の製品と同じであり得ると仮定している。しかし＜製品名＞列が一意となるように制約される場合、階層の＜製品名＞レベルのノードを得るには、＜製品名＞列の値に対してDISTINCT演算を行なうだけでよい。
【００５４】
なお、各々の葉ノードの相対的なパス名は、このノードについてのリソースを保持するリレーショナル表の行に格納された値によって表わされる。たとえば、行５０２（図５）はノード６０２（図６）についてのリソースを保持し、行５０２の列にある値はそれぞれ相対的なパス名／ＭＦ１／ＰＤ２／ＰＮ３／ＳＫＵ３に対応する。したがって、特定のノード（たとえばＭＦ１／ＰＤ２）の子を見つけるには、このノードについて用いられる列が子の選択に暗黙的に使用される（このように、ＭＦ１／ＰＤ２の子を見つけるのに使用されるＳＱＬは、‘SELECT FROM 製品情報 WHERE 製造業者＝‘ＭＦ１’ AND ‘製品タイプ’＝‘ＰＤ２’となる）。
【００５５】
整合性の維持
上述のように、先在する階層の捕捉後には、階層を反映する独立した２組のデータ、すなわち外部階層定義および内部階層定義が存在する。階層の整合的な反映を維持するためには、外部階層定義になされた変更に応じて内部階層定義に変更を加え、内部階層定義になされた変更に応じて外部階層定義に変更を加える必要がある。
【００５６】
たとえば、表４５０に関連付けられた管理階層は捕捉後には（１）階層構造内に格納されたデータ、および（２）表４５０の＜従業員ＩＤ＞列にあるデータと表４５０の＜管理者＞列にあるデータとの関係、で反映される。したがって、管理階層における変更を達成するには、（１）表４５０の＜従業員ＩＤ＞または＜管理者＞の列にある値を変更するか、または（２）階層構造における値を変更すればよい。階層構造内のデータと＜従業員ＩＤ＞および＜管理者＞の列内のデータとの整合性を維持するために、一方の組のデータになされた変更が、対応する変更を他方の組のデータに対して自動的に引起こすようにする機構を確立する。
【００５７】
一実施例に従うと、表４５０に変更を加えることによって、リソース表４０２を見て回ることの一部としてなされたいくつかの照合（たとえばセキュリティ照合）が、表４５０の探査についてもなされるようにする。データ操作言語（ＤＭＬ）トリガが表４５０において作成され、表４５０に対する挿入（insert）、更新（update）または削除（delete）の演算が階層構造内のデータに反映されるようにする。たとえば、表４５０から或る行が削除されると、照合を行なって、行が削除されたことで「宙吊りの行（dangling rows）」が生じないことを確実にする。たとえば管理階層において、行４２０に関連付けられたノードは、行４２２に関連付けられたノードの親である。したがって、行４２０が削除されると行４２２が管理階層から断切られて、行４２２は「宙吊り」となってしまう。宙吊りの行はもはや階層の一部でなくなるため、行４２２の削除により、行４２０と行４２２との両方に関係するデータが階層構造から削除される。
【００５８】
同様に、或る行を表４５０に挿入した場合、階層構造内の情報を更新して、作成された新たなパスについてのエントリを追加する。なお、新たな行が挿入されると、これは以前はアクセスできなかったサブ木へのアクセスを可能にするリンクを追加することがあり得る。たとえば、行４２０が削除された後に行４２０が再び挿入されると仮定する。行４２０を挿入すると行４２２が管理階層へ暗黙的に再び接木される。したがって、行４２０の挿入により、階層構造におけるデータが更新されて行４２０と行４２２との両方についてのノードおよびパスを含むようにされる。
【００５９】
内部階層定義と外部階層定義との整合性を維持するために行なわれる厳密な演算はさまざまな要因に基づいて変わることになる。整合性を維持するためにしなければならないことに影響を与える１つの要因として外部階層定義の性質がある。たとえば、表４５０に当てはまる管理階層はＳＱＬリレーションに基づき、表５００に当てはまる製品部門階層は列挙法に基づく。管理階層における或る葉ノードに関連付けられた行が削除された場合、リソース表の中でやはり削除されるべき行は一般的にこのノードに対応する行のみである。たとえば、製品部門階層における或る葉ノードに関連付けられた行が削除された場合、（１）リソース表におけるこのノードに対応する行が削除され、（２）削除された葉ノードの親にまだ他に子がいるかどうかが判断される。もし削除された葉ノードの親に他に子がいなければ、この親ノードに対応するリソース表内の行は削除される。親ノードに対応する行が削除されると、この親ノードの親に他に子がいるかどうかが判断される。もしこの親ノードの親に他に子がいなければ、この親ノードの親に関連付けられたリソース表内の行もまた削除される。このプロセスを繰返して、葉でないノードであって子のいないものをすべてなくす。
【００６０】
同様に、表内のすべての行の削除に関わるDROPおよびTRUNCATEの演算についても、削除（delete）演算について上記したものと類似する整合性維持の演算を行なう。
【００６１】
上述の例では、ＤＭＬトリガは、内容構造に対して行なわれる挿入、更新および削除の演算に基づいて階層構造内のデータに対して変更を行なう。このようなＤＭＬトリガはたとえば“INSTEAD OF”トリガで実現され得る。しかし、整合性を確実にするために、階層構造内のデータに対する挿入、更新および削除の演算の結果として対応する演算が内容構造内のデータに対して確実に行なわれるようにするためのトリガもまた作成する必要がある。
【００６２】
ハードウェア概観
図７は、この発明の一実施例が実現され得るコンピュータシステム７００を例示するブロック図である。コンピュータシステム７００は、バス７０２またはその他の情報通信用通信機構と、バス７０２と結合され情報を処理するためのプロセッサ７０４とを含む。コンピュータシステム７００はさらに主メモリ７０６、たとえばランダムアクセスメモリ（ＲＡＭ）またはその他の動的記憶装置を含み、これはバス７０２に結合されて、プロセッサ７０４の実行する命令および情報を記憶する。主メモリ７０６はさらに、プロセッサ７０４の実行する命令の実行中に一時変数またはその他の中間情報を記憶するのにも用いられ得る。コンピュータシステム７００はさらに、バス７０２と結合され、プロセッサ７０４のための静的情報および命令を記憶するための、読出専用メモリ（ＲＯＭ）７０８またはその他の静的記憶装置を含む。情報および命令を記憶するための記憶装置７１０、たとえば磁気ディスクまたは光ディスクが設けられてバス７０２に結合される。
【００６３】
コンピュータシステム７００はバス７０２を介して、情報をコンピュータユーザに対して表示するための表示装置７１２、たとえば陰極線管（ＣＲＴ）などに結合され得る。英数字式キーまたはその他のキーを含む入力装置７１４がバス７０２に結合され、情報およびコマンド選択をプロセッサ７０４へ通信する。もう１つの種類のユーザ入力装置としてカーソル操作装置７１６があり、これにはたとえばマウス、トラックボールまたはカーソルキーなどがあり、方向情報およびコマンド選択をプロセッサ７０４に通信し、表示装置７１２上のカーソルの動きを操作する。一般的にこの入力装置は、第１の軸（たとえばｘ）および第２の軸（たとえばｙ）の２本の軸上における２自由度を有し、これにより入力装置は或る平面上の位置を指定することができる。
【００６４】
この発明は、コンピュータシステム７００を使用してここに記載された技術を実現することに関する。この発明の一実施例に従うと、プロセッサ７０４が、主メモリ７０６に入っている１つ以上の命令からなる１つ以上のシーケンスを実行するのに応答して、ここに記載された技術がコンピュータシステム７００により実行される。このような命令は別のコンピュータ可読媒体、たとえば記憶装置７１０から主メモリ７０６に読込まれ得る。主メモリ７０６に入っている命令シーケンスの実行は、プロセッサ７０４がここに記載されたプロセスステップを行なうことを引起す。これに代わる実施例では、ソフトウェア命令の代わりに、またはこれと組合せて、ハードウェア回路を用いてこの発明を実現することもある。したがってこの発明の実施例は、ハードウェア回路およびソフトウェアのいかなる特定の組合せにも限定されない。
【００６５】
ここで用いる「コンピュータ可読媒体」という用語は、命令をプロセッサ７０４が実行できるようここに供給することに関与するあらゆる媒体を指す。このような媒体は多くの形態をとることができ、これには不揮発性媒体、揮発性媒体および伝送媒体が含まれるがこれに限定されない。不揮発性媒体にはたとえば、記憶装置７１０などの光ディスクまたは磁気ディスクが含まれる。揮発性媒体には主メモリ７０６などの動的記憶装置が含まれる。伝送媒体には同軸ケーブル、銅線および光ファイバが含まれ、これにはバス７０２を構成するワイヤが含まれる。伝送媒体はまた音波または光波の形態をとることもでき、これにはたとえば電波通信および赤外線データ通信の際に生成されるものなどがある。
【００６６】
コンピュータ可読媒体の一般的な形態にはたとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、またはその他任意の磁気媒体、ＣＤ−ＲＯＭ、その他任意の光媒体、パンチカード、紙テープ、その他任意の孔パターンによる物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、その他任意のメモリチップまたはカートリッジ、後に記載する搬送波、またはその他コンピュータが読出可能な任意の媒体が含まれる。
【００６７】
１つ以上の命令からなる１つ以上のシーケンスを、プロセッサ７０４が実行できるようここへ伝達することには、さまざまな形態のコンピュータ可読媒体が関与し得る。たとえば、命令はまず遠隔コンピュータの磁気ディスクに収められ得る。この遠隔コンピュータは命令を自分の動的メモリにロードして、モデムを用いて電話回線経由でこれら命令を送信し得る。コンピュータシステム７００に対してローカルなモデムが電話回線上のデータを受信し、赤外線送信機を用いてこのデータを赤外線信号に変換し得る。赤外線信号で搬送されたデータは赤外線検出器で受信されて、適当な回路がこのデータをバス７０２に出力することになる。バス７０２はデータを主メモリ７０６へと伝達し、ここからプロセッサ７０４は命令を検索および実行する。任意には、主メモリ７０６が受取った命令は、プロセッサ７０４による実行前または実行後に記憶装置７１０で記憶され得る。
【００６８】
コンピュータシステム７００はさらに、バス７０２に結合された通信インターフェイス７１８を含む。通信インターフェイス７１８は、ローカルネットワーク７２２に接続されたネットワークリンク７２０に対する２方向データ通信結合を行なうためのものである。たとえば通信インターフェイス７１８は統合デジタル通信サービス網（ＩＳＤＮ）カードまたはモデムであることがあり、これにより対応する種類の電話回線に対するデータ通信接続を行なう。別の例として、通信インターフェイス７１８はローカルエリアネットワーク（ＬＡＮ）カードであってもよく、これにより対応するＬＡＮに対するデータ通信接続を行なう。無線リンクもまた実現可能である。このような実現例のいずれにおいても、通信インターフェイス７１８は、さまざまな種類の情報を表わすデジタルデータの流れを搬送する電気信号、電磁信号または光信号を送受信する。
【００６９】
一般的にネットワークリンク７２０は、１つ以上のネットワーク経由で他のデータ装置に対するデータ通信を可能にする。たとえばネットワークリンク７２０はローカルネットワーク７２２経由で、ホストコンピュータ７２４、または、インターネットサービスプロバイダ（ＩＳＰ）７２６の動作させるデータ装置に対する接続を行ない得る。このＩＳＰ７２６は、現在一般的に「インターネット」と称される全世界規模パケットデータ通信網７２８を通じてデータ通信サービスを提供する。ローカルネットワーク７２２およびインターネット７２８はともに、デジタルデータの流れを搬送する電気信号、電磁信号または光信号を使用する。このようにさまざまなネットワークを経由する信号や、デジタルデータをコンピュータシステム７００に入出力するネットワークリンク７２０上および通信インターフェイス７１８経由の信号は、情報を運ぶ搬送波の形態の例である。
【００７０】
コンピュータシステム７００は、ネットワーク、ネットワークリンク７２０および通信インターフェイス７１８を通じてメッセージを送信し、プログラムコードを含むデータを受信することができる。インターネットの例では、サーバ５３０は或るアプリケーションプログラムについての要求されたコードを、インターネット７２８、ＩＳＰ７２６、ローカルネットワーク７２２、そして通信インターフェイス７１８経由で送信し得る。
【００７１】
受信されたコードは、受信されるとプロセッサ７０４により実行され、かつ／または記憶装置７１０もしくはその他の不揮発性記憶装置内で、後で実行されるように記憶され得る。このようにコンピュータシステム７００は搬送波の形でアプリケーションコードを入手し得る。
【００７２】
以上の明細書においては、この発明をその特定の実施例を参照して記載した。しかし、この発明のより広い意味および範囲から逸脱することなく、さまざまな変形および変更がこの発明で可能であることが明らかであろう。したがってこの明細書および図面は、限定としてでなく例示的な意味で考えられるべきである。
【図面の簡単な説明】
【００７３】
【図１】階層ファイルシステムを示すブロック図である。
【図２】リソースに関連付けられたノードの階層を示すブロック図である。
【図３】この発明の一実施例に従う、図２に示す階層を捕捉するために用いられ得るリレーショナル表のブロック図である。
【図４】この発明の一実施例に従う階層構造と内容構造との分離を例示するブロック図である。
【図５】情報階層における葉でないノードが、葉ノードに対応する行に格納された値で表わされ、リレーショナル表のブロック図である。
【図６】図５の表に格納されたデータに内在する階層を示すブロック図である。
【図７】この発明の実施例が実現され得るシステムを示すブロック図である。
【図２】
2005505042.tif 000003
【図３】
2005505042.tif 000004
【図４】
2005505042.tif 000005
【図５】
2005505042.tif 000006
【図６】
2005505042.tif 000007
【図７】
2005505042.tif 000008
【国際公開パンフレット】
2005505042.tif 000009
2005505042.tif 000010
2005505042.tif 000011
2005505042.tif 000012
2005505042.tif 000013
2005505042.tif 000014
2005505042.tif 000015
2005505042.tif 000016
2005505042.tif 000017
2005505042.tif 000018
2005505042.tif 000019
2005505042.tif 000020
2005505042.tif 000021
2005505042.tif 000022
2005505042.tif 000023
2005505042.tif 000024
2005505042.tif 000025
2005505042.tif 000026
2005505042.tif 000027
2005505042.tif 000028
2005505042.tif 000029
2005505042.tif 000030
2005505042.tif 000031
2005505042.tif 000032
2005505042.tif 000033
2005505042.tif 000034
2005505042.tif 000035
2005505042.tif 000036
2005505042.tif 000037
2005505042.tif 000038
2005505042.tif 000039
2005505042.tif 000040
2005505042.tif 000041
2005505042.tif 000042
【国際公開パンフレット（コレクトバージョン）】
2005505042.tif 000043
2005505042.tif 000044
【手続補正書】
【提出日】平成16年2月24日(2004.2.24)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
データベースシステムにおいてデータを管理する方法であって、
（ａ）１つ以上のリレーショナル表を、情報階層に属するリソースの内容に関連付けられたデータを格納する表として識別するデータと、
（ｂ）何が前記情報階層内での関係を構成するのかを示す接続基準と、をデータベースサーバで受取るステップを含み、
前記１つ以上のリレーショナル表は、前記リソースの内容に関連付けられたデータとともに、前記リソース間の階層関係を確立する外部階層定義となる或るデータを格納する少なくとも１つの表を含み、前記方法はさらに、
前記１つ以上のリレーショナル表を識別する前記データおよび前記接続基準を用いて前記階層内の階層関係を捕捉するステップを含み、前記捕捉するステップは、
前記或るデータを検索するために１つ以上の問合せを前記１つ以上のリレーショナル表に対して実行するステップと、
前記或るデータおよび前記接続基準に基づいて、前記１つ以上のリレーショナル表とは別個の１つ以上の階層構造内に内部階層定義として前記情報階層を捕捉する情報を格納するステップとを行なうことによる、方法。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１５
【補正方法】変更
【補正の内容】
【請求項１５】
データベースシステムにおいてデータを管理するための情報を保持するコンピュータ可読媒体であって、前記命令は、
（ａ）１つ以上のリレーショナル表を、情報階層に属するリソースの内容に関連付けられたデータを格納する表として識別するデータと、
（ｂ）何が前記情報階層内での関係を構成するのかを示す接続基準と、をデータベースサーバで受取るステップを行なうための命令を含み、
前記１つ以上のリレーショナル表は、前記リソースの内容に関連付けられたデータとともに、前記リソース間の階層関係を確立する外部階層定義となる或るデータを格納する少なくとも１つの表を含み、前記命令はさらに、
前記１つ以上のリレーショナル表を識別する前記データおよび前記接続基準を用いて前記階層内の階層関係を捕捉するステップを行なう命令を含み、前記捕捉するステップは、
前記或るデータを検索するために１つ以上の問合せを前記１つ以上のリレーショナル表に対して実行するステップと、
前記或るデータおよび前記接続基準に基づいて、前記１つ以上のリレーショナル表とは別個の１つ以上の階層構造内に内部階層定義として前記情報階層を捕捉する情報を格納するステップとを行なうことによる、コンピュータ可読媒体。
【国際調査報告】
2005505042.tif 000045
2005505042.tif 000046
2005505042.tif 000047