(57)【要約】【課題】  アプリケーションプログラムが各種のデータベース管理システムにアクセスできるようにするアプリケーションプログラミングインタフェース（API）を提供することを目的とする。【解決手段】  本発明は、SQL入力クエリーを通して、階層データストアに記憶されているデータにアクセスできるようにするオープンデータベースコネクティヴィティ（ODBC）ドライバ。ドライバは、SQL入力に基づいて、階層データストアをリレーショナルデータベーステーブルに変換する。望ましくは、テーブルは、階層データストアに記憶されている実際のデータを指し示すポインタを保持している。【選択図】  図１
2005285141.tif 000002
【特許請求の範囲】
【請求項１】
ＳＱＬ入力を用いることによって、メモリーデバイス上に駐在している階層データストアに記憶されているデータにアクセスするコンピュータで実行される方法において、
ＳＱＬ入力を受け取る工程と、
受け取られたＳＱＬ入力に基づいて、階層データストアをリレーショナルデータベースのテーブルに変換する工程と、
変換されたテーブルを用いて、ＳＱＬ入力を実行する工程と、
を含むコンピュータで実行される方法。
【請求項２】
受け取られたＳＱＬ入力を解析して、階層データストア内のオブジェクトのうちの少なくとも一つを選択し、リレーショナルデータベースのテーブルに変換する工程、
を含むこととする請求項１に記載の方法。
【請求項３】
受け取られたＳＱＬ入力を解析する工程は、階層データストア内のオブジェクトのうちの少なくとも一つを選択するが、全ては選択しない工程を含むこととする請求項２に記載の方法。
【請求項４】
変換する工程は、
受け取られたＳＱＬ入力を解析して、階層データストア内の問合せられるべきオブジェクトクラスを決定する工程と、
受け取られたＳＱＬ入力を解析して、受け取られたＳＱＬ入力によって参照されるコラムを決定する工程と、
問合せられるべきオブジェクトクラスのために少なくとも一つのテーブルを生成する工程であって、該テーブルは、上記オブジェクトクラス内の属性を表す少なくとも一つのコラムを有している工程と、
該少なくとも一つのテーブル内の一つの外来キーのために少なくとも一つのコラムを合成する工程と、
を含むこととする請求項１に記載の方法。
【請求項５】
階層データストア内のオブジェクトにおけるスケーラ属性をテーブルに変換する工程であって、該テーブルは、該スケーラ属性用の少なくとも一つのコラムおよび該オブジェクトに関連した外来キー用の少なくとも一つのコラムを有している工程、
をさらに含むこととする請求項４に記載の方法。
【請求項６】
階層データストア内のオブジェクトにおけるベクトル属性をテーブルに変換する工程であって、該テーブルは、該ベクトルにおける少なくとも一つの値のための少なくとも一つのコラムおよび上記オブジェクトに関連した外来キー用の少なくとも一つのコラムを有している工程、
をさらに含むこととする請求項４に記載の方法。
【請求項７】
実際のデータの少なくとも一つのインスタンスをテーブルに格納する工程、
をさらに含むこととする請求項４に記載の方法。
【請求項８】
データに対する少なくとも一つのポインタをテーブルに格納する工程、
をさらに含むこととする請求項４に記載の方法。
【請求項９】
少なくとも一つのテーブルは、ＳＱＬ入力が参照する属性のそれぞれのためのコラムを含むこととする請求項４に記載の方法。
【請求項１０】
実行する工程は、少なくとも一つのテーブルに対して、該ＳＱＬ入力を実行する工程を含むこととする請求項４に記載の方法。
【請求項１１】
受け取る工程は、外部ＳＱＬステートメントを受け取る工程を含むこととする請求項１に記載の方法。
【請求項１２】
変換する工程は、
ＳＱＬステートメントを解析して、該ＳＱＬステートメントが要求するデータを提供するには、階層データストア内のどのオブジェクトを処理しなければならないかを決定する工程と、
それぞれの決定されたオブジェクトをテーブルに変換する工程であって、該テーブルは、少なくとも、該テーブル用の基本キーとして働く一意の識別子を含むコラム、および、もし有る場合には、該所有オブジェクトに遡る外来キーレファレンスを含むコラムを含んでいる工程と、
オブジェクトの各非レファレンススケーラ属性を、上記テーブル内のコラムに変換する工程であって、該テーブルは、そのオブジェクト用の変換テーブルである工程と、
オブジェクトの各非レファレンスベクトル属性を、テーブルに変換する工程であって、該テーブルは、そのテーブル用の基本キーの少なくとも一部であるシーケンスコラム、上記所有オブジェクトに遡る外来キーレファレンスを含み、かつ、上記基本キーの少なくとも一部でもあるコラムを有している工程と、
オブジェクトの各レファレンス属性を基に、該参照されたオブジェクトから該レファレンス属性を所有する該オブジェクトまでの外来キー関係を算出する工程と、
上記テーブルを、次のもの、すなわち、実際のデータ、実際のデータへのレファレンス、または、実際のデータと実際のデータへのレファレンスの組合せのうちの一つと共にポピュレートする工程と、
を含むこととする請求項１に記載の方法。
【請求項１３】
階層データストア内の属性のうちの少なくともいくつか、しかし全てではない、が、リレーショナルデータベースのテーブルに変換されることとする請求項１２に記載の方法。
【請求項１４】
実行する工程は、テーブルに対して、ＳＱＬ入力を実行する工程を含むこととする請求項１２に記載の方法。
【請求項１５】
機械によって読取り可能なプログラム記憶装置であって、該機械によって実行可能な命令のプログラムを有形に具体化して、ＳＱＬ入力を用いて階層データストア内に格納されたデータにアクセスする方法を遂行するプログラム記憶装置において、
ＳＱＬ入力をメモリーデバイスに受け取る手段と、
該受け取られたＳＱＬ入力に基づいて、階層データストアをリレーショナルデータベースのテーブルに変換する手段と、
該変換されたテーブルを用いて、上記ＳＱＬ入力を実行する手段と、
を含むことを特徴とするプログラム記憶装置。
【請求項１６】
変換する手段は、
ＳＱＬステートメントを解析して、該ＳＱＬステートメントが要求するデータを提供するには、階層データストア内のどのオブジェクトを処理しなければならないかを決定する手段と、
それぞれの決定されたオブジェクトをテーブルに変換する手段であって、該テーブルは、少なくとも、該テーブル用の基本キーとして働く一意の識別子を含むコラム、および、もし有る場合には、上記所有オブジェクトに遡る外来キーレファレンスを含むコラムを含んでいる該手段と、
オブジェクトの各非レファレンススケーラ属性を、該テーブル内のコラムに変換する手段であって、該テーブルは、そのオブジェクト用の該変換テーブルである該手段と、
オブジェクトの各非レファレンスベクトル属性を、テーブルに変換する手段であって、該テーブルは、そのテーブル用の該基本キーの少なくとも一部であるシーケンスコラム、該所有オブジェクトに遡る外来キーレファレンスを含み、かつ、上記基本キーの少なくとも一部でもあるコラムを有している該手段と、
オブジェクトの各レファレンス属性を基に、参照されたオブジェクトからレファレンス属性を所有する該オブジェクトまでの外来キー関係を算出する手段と、
上記テーブルを、次のもの、すなわち、実際のデータ、実際のデータへのレファレンス、または、実際のデータと実際のデータへのレファレンスの組合せのうちの一つと共にポピュレートする手段と、
を含むこととする請求項１５に記載のプログラム記憶装置。
【請求項１７】
変換する手段は、
受け取られたＳＱＬ入力を解析して、階層データストア内の問合せられるべきオブジェクトクラスを決定する手段と、
上記受け取られたＳＱＬ入力を解析して、該受け取られたＳＱＬ入力によって参照されるコラムを決定する手段と、
問合せられるべきオブジェクトクラスのために少なくとも一つのテーブルを生成する手段であって、該テーブルは、上記オブジェクトクラス内の属性を表す少なくとも一つのコラムを有している該手段と、
上記少なくとも一つのテーブル内の一つの外来キーのために少なくとも一つのコラムを合成する手段と、
を含むこととする請求項１５に記載のプログラム記憶装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース管理システム、および、より詳しくは、アプリケーションプログラムが各種のデータベース管理システムにアクセスできるようにするアプリケーションプログラミングインタフェース（API）に関する。
【背景技術】
【０００２】
オープンデータベースコネクティヴィティ（ODBC）は、データベース管理システムに基づく各種のストラクチャクウィアリー言語（SQL）にアクセスするための共通のインターフェースを設けるアプリケーションプログラミングインタフェース（API）である。大方の販売会社は、彼らのリレーショナルデータベースに、ODBCを追加して来た。
【特許文献１】発見できず
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来のODBCの大きな欠点の一つは、クエリーの際に、標準のSQL言語を使用するリレーショナルデータベース管理システムにアクセスするよう設計されており、リレーショナルデータベースの外で使用するには、SQLが、データベースのリレーショナル特性を仮定しているため、大きな問題があったことである。
【０００４】
したがって、階層オブジェクト／属性モデルなどの非リレーショナルデータストアへのアクセスが可能なODBCインタフェースあるいはドライバを設けるためのシステムおよび方法を供給するのが望ましい。
【課題を解決するための手段】
【０００５】
本発明は、SQL入力クエリーを通して、階層データストアに記憶されているデータにアクセスできるようにするドライバを供給する。ドライバは、SQL入力に基づいて、階層データストアをリレーショナルデータベーステーブルに変換する。望ましくは、テーブルは、階層データストアに記憶されている実際のデータを指し示すポインタを保持している。次いで、変換されたテーブルを用いて、SQL入力が実行される。
【発明の効果】
【０００６】
本発明は、以上のように構成されるので、アプリケーションプログラムが各種のデータベース管理システムにアクセスできるようにするアプリケーションプログラミングインタフェース（API）を得る。
【発明を実施するための最良の形態】
【０００７】
階層データストアは、オブジェクトおよび属性のグラフとして表される。オブジェクトは、他のオブジェクトにより所有されてもよく、また、他のオブジェクトに概念的に集合されてもよい。属性は、オブジェクトにより所有されてもよく、また、オブジェクトに集合されてもよい。図３には、このような階層データストアの表現および等価なリレーショナルデータベースのそれが含まれている。
【０００８】
図３の階層データストアは、得意先およびそれらの注文情報のモデルである。データストアには、オブジェクトまたはそれぞれ一意的な内部識別番号「int_id」を有する「Customer」と命名されたオブジェクトのグループが含まれている。「Customer」オブジェクトには、三つの属性、すなわち、一つのスケーラ属性、および二つのベクトル属性が有る。一つのスケーラ属性は、定義によってただ一つの値しか保持できない「Name」タイプの属
性である。第一のベクトル属性は、定義によって多数の値が保持できる「Phone_number」タイプの属性である。第二のベクトル属性は、同様に多数の値が保持できる「Order_ref」タイプの属性である。「Order_ref」の各値は、「Order」と命名された別のオブジェクトを参照するポインタである。「Order」オブジェクトは、発行された特定のオーダーの日付を記憶する「DateOrdered」タイプの属性を有している。リレーショナルデータベース内の等価なデータストアは、図３の右側に示した三つの別個のテーブルとして表すことができる。「Customer」テーブルには、「Id」および「Name」と命名された二つのコラムが有り、「Order」テーブルには、「Order _id」、「DateOrdered」および「Cust」と命名された三つのコラムが有り、「Phone」テーブルには、「Cust」、「Seq」および「Phone_number」と命名された三つのコラムが有る。三つのテーブルは、同じ値を有するCustomerの「Id」、Phoneの「Cust」、およびOrderの「Cust」を通して、互いに他にリンクされている。
【０００９】
図１は、SQLレポートジェネレータ２および階層データストア４の間にインターフェース接続されたODBCドライバ６を示すブロック図である。上述したように、従来のODBCは、標準のSQL言語クエリーを用いて、リレーショナルデータベースにアクセスするよう設計されている。本発明のODBCドライバ６では、図２のステップによる階層データストア４などの標準のオブジェクト／情報の属性モデルに対して、SQLレポートジェネレータ２からの、標準のSQL言語クエリーを使用することが可能である。ステップ１０では、ドライバ６は、ジェネレータ２からのSQL入力を受け取る。ステップ１２では、ドライバ６は、受け取ったSQL入力に基づいて処理すべきオブジェクトのクラスおよびそれらの属性を識別する。ステップ１４では、階層データストア４は、各種のコラムを有するリレーショナルデータベースのテーブルに変換され、その結果、階層データストア４は、SQLレポートジェネレータ２に対して、リレーショナルデータベースのようになる。好適な実施形態においては、ステップ１４では、下記の操作が行われ、したがって、階層的に記憶されたデータベースは、リレーショナルデータベースのテーブルに変換される。
【００１０】
１．  各クラスのオブジェクトは、テーブルに変換される。このタイプの各テーブルは、二つの擬似コラム、すなわち、このインスタンスの一意的な識別子を含み、かつ、基本キーである「Id」、および所有オブジェクトに遡る外来キーレファレンスを含む「Owner」を有しており、
２．  オブジェクトの各非レファレンススケーラ属性は、オブジェクトのクラステーブルのコラムとなり、かつ、
３．  プロジェクトの各非レファレンスベクトル属性は、テーブルに変換される。このタイプの各テーブルは、二つの擬似コラム、すなわち、ベクトルの各エレメントのシーケンス値を含み、かつ、テーブルの基本キーの一部である「Sequence」、および所有オブジェクトに遡る外来キーを含み、かつ、基本キーの一部である「Owner」を有しており、かつ、
４．  各レファレンス属性（スケーラとベクトルの両方）を用いて、参照されたオブジェクトからレファレンス属性を所有するオブジェクトまでの外来キー関係を求めることができる。
【００１１】
必要なテーブルおよびコラムを生成／変換する場合は、それらが、階層データストアに存在する実際のデータを指し示すポインタを有し、データそれ自体は保持しないことが望ましい。変換されたテーブルのステップ１６では、次いで、SQL入力に含まれるクエリーが実行される。ステップ１８では、この実行の結果が、SQL入力を送出したレポートジェネレータ２に渡される。
【００１２】
以下、一対のSQL入力を例に取って、図２をさらに詳しく説明する。一例として、ODBCドライバ６が、SQLレポートジェネレータ２から送出された下記のSQL入力クエリーを受け
取る、と仮定しよう。
Select DataOrdered from Order a, Customer b where a.Cust=b.Id and b.Name=”Doe”
【００１３】
上記のSQL入力は、ジェネレータが、「Doe」が出した全ての注文に対してDateOrderedの受取りを望んでいることを意味している。言い換えれば、CustomerテーブルとOrderテーブルを接続あるいは接合するやり方は、Orderテーブルの「Cust」コラムの値を、Customerテーブルの「Id」コラムの値に一致させるやり方である。「Id」は、Customerテーブルの基本キーであり、「Cust」は、Orderテーブルの外来キーである。従来技術に普通に熟練した人なら分かるように、図３の階層データストアは、従来のODBCインタフェースで直ちに使用できる形態には構成されていない。これは、本発明によるODBCドライバ６が解決している問題の一つである。
【００１４】
ODBCドライバ６は、受け取ったSQL入力を解析し、処理の必要が有るオブジェクトクラスを識別する。ODBCドライバ６は、次いで、各オブジェクトクラスをテーブルに送出する。言い換えれば、オブジェクトクラスは、テーブルに写像されるため、識別された各オブジェクトクラスに対して、データベーステーブルが生成される。上の例では、「Customer」および「Order」の、二つのオブジェクトが有る。したがって、「Customer」および「Order」と命名された二つのテーブルが生成される。受け取られたSQL言語において、どのコラムが参照されているかを解析することにより、また、コラムは、属性に写像されるため、オブジェクトクラスの属性を解析することによって、テーブルのコラムが、変換処理の一部として、部分的に生成される。さらに、内部識別番号「int_id」は、対応するテーブルのコラムに写像される。変換の結果として、ODBCドライバは、図３に示したように、「id」および「Name」コラムを有する「Customer」テーブル、および「Order _id」、「DateOrdered」および「Cust」コラムを有する「Order」テーブルを生成する。Customerオブジェクトの「int_id」および「Name」は、「Customer」テーブルの「int_id」および「Name」コラムに写像され、また、Orderオブジェクトの「int_id」および「DateOrdered」は、「Order」テーブルの「Order _id」、「DateOrdered」コラムに写像される。
【００１５】
この点で、我々が合成しなければならない唯一のコラムは、Orderテーブルの「Cust」コラムである。しかしながら、階層データストアのCustomer属性は、Orderオブジェクトには、存在しない。言い換えれば、Customerオブジェクトの「Cust（int_id）」を遡って指し示すOrderオブジェクトには、いかなる属性も存在しない。事実、それは、リレーショナルデータベースの逆である。なぜなら、Orderオブジェクトを指し示すのは、Customerオブジェクトであるからである。これは、リレーショナルデータベースと階層データストアなどのオブジェクト／属性モデルの間の、トポロジーの違いである。
【００１６】
この場合、「Cust」コラムは、リレーショナルデータベースの外来キーである、と認識される。外来キーの概念は、「Customer」オブジェクトの「Order_ref」属性など、階層データストアのレファレンス属性と同様である。クエリーが、外来キーを遡って要求していることが認識されると、「Customer」オブジェクトの「Order_ref」属性が読み取られ、逆の関係が合成され、次いで、Customerオブジェクトの「int_id」を用いて、「Cust」コラムが合成または生成される。
【００１７】
必要なテーブルおよびコラムが完全に出来上がった状態で、テーブルは、階層データストアに存在する実際のデータを指し示すポインタを保持し、データそれ自体は保持しないことが望ましい。別法として、実際のデータをテーブルに保持してもよい。
【００１８】
SQL言語入力のもう一つの例では、ODBCドライバ６が、以下のものを受け取る、と仮定しよう。
【００１９】
Select phone_number from Customer a, Phone b where a.id=b.Cust and a.Name=”Sears”
【００２０】
この例では、ベクトル属性「phone_number」が参照されるため、異なる変換が生ずる。上記のように、各非レファレンスベクトル属性は、テーブルに変換される。属性それ自体は、「phone_number」と命名されたコラムに写像される。さらに二つのコラムが合成される。その一つ、「Cust」と命名されたコラムは、「phone_number」を所有していたオブジェクト（「Customer」）のid（「int_id」）であり、別の一つ、「seq」と命名されたコラムは、任意の増大する番号であり、したがって、同じオブジェクトに対して、異なる電話番号が識別可能である。
【００２１】
第一例の場合のように、必要なテーブルおよびコラムがひとたび完全に出来上がった状態では、テーブルは、階層データストアに存在する実際のデータを指し示すポインタを保持していることが望ましい。次いで、変換されたテーブルを用いて、SQL入力が実行される。SQL入力の選択基準に合致したデータは、変換されたテーブルに保持されているポインタが指し示す階層データストアから選択され、レポートジェネレータ２に渡される。この場合も、実際のデータをテーブルに保持してもよい。
【００２２】
ここでは、例証のため、本発明の特定の実施形態を説明したが、本発明の意図および範囲を逸脱することなしに、各種の修正が可能であることが、上記のことから理解されよう。
【図面の簡単な説明】
【００２３】
【図１】本発明による、SQLレポートジェネレータと階層データストアの間にインタフェース接続されたODBCドライバを示すブロック図である。
【図２】本発明によるODBCドライバのフローチャートを示す。
【図３】階層データストアの表現および等価なリレーショナルデータベースのそれを示す。
【符号の説明】
【００２４】
２  SQLレポートジェネレータ
４  階層データストア
６  ODBCドライバ
【図１】
2005285141.tif 000003
【図２】
2005285141.tif 000004
【図３】
2005285141.tif 000005