JP2001331315A

JP2001331315A - データ処理システム及び方法、並びに、記憶媒体

Info

Publication number: JP2001331315A
Application number: JP2000153295A
Authority: JP
Inventors: Curtis Eubanks; カーティスユーバンクス; Hideki Asazu; 英樹浅津
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2000-05-24
Filing date: 2000-05-24
Publication date: 2001-11-30

Abstract

(57)【要約】【課題】データ構造が経時的に変化する場合であって
も、アプリケーションのデータ・アクセスを許容する。【解決手段】第１のデータ構造仕様に従って構造化さ
れたデータに対してアクセス可能に記述されたアプリケ
ーションに対して、該第１のデータ構造仕様を変更した
第２のデータ構造仕様に従って構造化されたデータへの
アクセスを許容する。また、第２のデータ構造仕様に従
って構造化されたデータに対してアクセス可能に記述さ
れたアプリケーションに対して、第１のデータ構造仕様
に従って構造化されたデータへのアクセスを許容する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、オブジェクト指向
言語によって記述されたクラス及びインターフェースの
継承メカニズムを利用したデータ処理システム及び方法
に係り、特に、データ構造が経時的に変化する（データ
ベース・スキーマ・エボリューション）ような場合であ
っても、アプリケーションに対して構造化データへのア
クセスを許容することができる、クラス及びインターフ
ェースの継承メカニズムを利用したデータ処理システム
及び方法に関する。

【０００２】更に詳しくは、本発明は、古いアプリケー
ションが更新されたスキーマに従う新しいデータに対し
ても透過的にアクセスすることができるとともに、新し
いアプリケーションが古いデータ構造に従う古いデータ
に対しても透過的にアクセスすることができる、クラス
及びインターフェースの継承メカニズムを利用したデー
タ処理システム及び方法に関する。

【０００３】

【従来の技術】テレビジョンやラジオのようにアナログ
信号を受信する機器が出現してから既に久しい。この種
の機器は、アナログ・スタンダードを用いた映像プログ
ラムや音響プログラムを選局しデコードするようになっ
ているが、アナログ・スタンダードは逐次変更が加えら
れるという性質を持つ。

【０００４】例えば、１９５４年にＮＴＳＣ（National
Television System Committee）信号にカラー情報が付
加されたり、１９８５年にステレオ音響信号の放送が追
加されたように、米国においてテレビジョン放送スタン
ダードが変更したような場合において、一般消費者が更
新された放送スタンダードによってもたらされる新しい
特徴の利益を享受するためには、新しいテレビジョン・
セットを購入する必要があった。

【０００５】現在、デジタル・テレビジョン放送や、イ
ンターネットのような最新の放送／通信手段によれば、
メディア・コンテンツと一緒にアプリケーションやデー
タを送信することができる。しかしながら、技術革新
や、企業間の競合、独占的なメディア・フォーマットを
普及させようとする企業戦略などのために、メディアや
データのフォーマット変更が未曾有の頻度で行われるよ
うになってきている。インターネットのユーザは、デー
タ・フォーマットの新しいバージョンを用いてエンコー
ドされたＷｅｂコンテンツを閲覧するために、アプリケ
ーション・ソフトウェアを絶えずダウンロードし又はア
ップグレードするという処理には充分習熟している。

【０００６】米国では、衛星放送、地上放送、ケーブル
放送など伝統的な放送に関しては、ＦＣＣ（Federal Co
mmunications Commission：米国連邦通信委員会）のよ
うな中央集権的な機関が放送スタンダードに関し絶対的
な制御権を有しており、特定のデータ・フォーマットに
従うように命令することができる。しかしながら、イン
ターネットのように、権力が分散した環境下では、各サ
ービス・プロバイダに対して最新のデータ・フォーマッ
トのバージョンに従うように要求することは困難又は不
可能である。

【０００７】さらに、最近のデジタル・セットトップボ
ックス（ＳＴＢ）やホーム・サーバの中には、アプリケ
ーションやデータをダウンロードしたり、不揮発性のロ
ーカル・データ蓄積装置に保存したりする能力を備えた
ものがある。時間の経過とともにもデータ・フォーマッ
トが変更すると、以前のバージョンのデータ・フォーマ
ットを使用して格納されたアプリケーションやデータは
使用不能になってしまう。データ・プロバイダの中に
は、以前のバージョンのデータ・フォーマットのままで
データ供給を続けるものもあるが、アプリケーション・
プロバイダがアプリケーションのアップグレードを望ま
なかったり、既に事業から撤退している場合もある。

【０００８】

【発明が解決しようとする課題】本発明の目的は、オブ
ジェクト指向言語によって記述されたクラス及びインタ
ーフェースの継承メカニズムを利用した、優れたデータ
処理システム及び方法を提供することにある。

【０００９】本発明の更なる目的は、データ構造が経時
的に変化する（データベース・スキーマ・エボリューシ
ョン）ような場合であっても、アプリケーションに対し
て構造化データへのアクセスを許容することができる、
クラス及びインターフェースの継承メカニズムを利用し
た、優れたデータ処理システム及び方法を提供すること
にある。

【００１０】本発明の更なる目的は、古いアプリケーシ
ョンが更新されたスキーマに従う新しいデータに対して
も透過的にアクセスすることができるとともに、新しい
アプリケーションが古いデータ構造に従う古いデータに
対しても透過的にアクセスすることができる、クラス及
びインターフェースの継承メカニズムを利用した、優れ
たデータ処理システム及び方法を提供することにある。

【００１１】

【課題を解決するための手段】本発明は、上記課題を参
酌してなされたものであり、その第１の側面は、オブジ
ェクト指向言語及びプログラミング・インターフェース
を用いてデータベースに格納された構造化データにアク
セスするデータ処理システム又は方法であって、アプリ
ケーションを実行するアプリケーション実行手段又はス
テップと、データ構造の仕様をアプリケーションと分離
可能な形式で指定するデータ構造指定手段又はステップ
と、第１のデータ構造仕様に従って構造化されたデータ
にアクセス可能に記述されたアプリケーションに対し
て、該第１のデータ構造仕様を変更した第２のデータ構
造仕様に従って構造化されたデータへのアクセスを許容
するデータ構造進化手段又はステップと、第１のデータ
構造仕様を変更した第２のデータ構造仕様に従って構造
化されたデータに対してアクセス可能に記述されたアプ
リケーションに対して、第１のデータ構造仕様に従って
構造化されたデータへのアクセスを許容するデータ構造
退化手段又はステップと、を具備することを特徴とする
データ処理システム又は方法である。

【００１２】前記データ構造進化手段又はステップは、
第１のデータ構造仕様に従って構造化されたデータにア
クセス可能に記述されたアプリケーションに対して、該
第１のデータ構造仕様に複数回の変更を行った第２のデ
ータ構造仕様に従って構造化されたデータへのアクセス
を許容するようにしてもよい。

【００１３】また、前記データ構造退化手段又はステッ
プは、第１のデータ構造仕様に複数回の変更を行った第
２のデータ構造仕様に従って構造化されたデータにアク
セス可能に記述されたアプリケーションに対して、第１
のデータ構造仕様に従って構造化されたデータへのアク
セスを許容するようにしてもよい。

【００１４】また、前記データ構造進化手段又はステッ
プは、オブジェクト指向言語で記述されたクラス又はイ
ンターフェースの継承メカニズムで構成することができ
る。

【００１５】また、前記データ構造退化手段又はステッ
プは、該第１のデータ構造仕様を該第２のデータ構造仕
様に変換するアダプタ・クラス又はインターフェース
と、前記アダプタ・クラス又はインターフェースを管理
するアダプタ・マネージャとで構成されて、問合せに応
答して、第１のデータ構造仕様から第２のデータ構造仕
様に変換可能な１以上のアダプタを探索し及び／又は生
成するようにしてもよい。

【００１６】また、本発明の第１の側面に掛かるデータ
処理システムは、さらに、スキーマを識別する識別手段
と、格納されたデータに対する透過的なアクセスを提供
するデータベース・インターフェースと、データをイン
ポートする手段と、インポートされたデータとスキーマ
とを関連付ける手段と、データベースを格納する格納手
段と、を備えてもよい。

【００１７】また、本発明の第２の側面は、オブジェク
ト指向言語及びプログラミング・インターフェースを用
いてデータベースに格納された構造化データにアクセス
するデータ処理をコンピュータ・システム上で実行する
ためのコンピュータ・ソフトウェアをコンピュータ可読
形式で物理的に格納した記憶媒体であって、前記コンピ
ュータ・ソフトウェアは、アプリケーションを実行する
アプリケーション実行ステップと、データ構造の仕様を
アプリケーションと分離可能な形式でデータ構造を指定
するデータ構造指定ステップと、第１のデータ構造仕様
に従って構造化されたデータにアクセス可能に記述され
たアプリケーションに対して、該第１のデータ構造仕様
を変更した第２のデータ構造仕様に従って構造化された
データへのアクセスを許容するデータ構造進化ステップ
と、第１のデータ構造仕様を変更した第２のデータ構造
仕様に従って構造化されたデータに対してアクセス可能
に記述されたアプリケーションに対して、第１のデータ
構造仕様に従って構造化されたデータへのアクセスを許
容するデータ構造退化ステップと、を具備することを特
徴とする記憶媒体である。

【００１８】本発明の第２の側面に係る記憶媒体は、例
えば、様々なプログラム・コードを実行可能な汎用コン
ピュータ・システムに対して、コンピュータ・ソフトウ
ェアをコンピュータ可読な形式で提供する媒体である。
このような媒体は、例えば、ＣＤ（Compact Disc）やＦ
Ｄ（Floppy Disc）、ＭＯ（Magneto-Optical disc）な
どの着脱自在で可搬性の記憶媒体である。あるいは、ネ
ットワーク（ネットワークは無線、有線の区別を問わな
い）などの伝送媒体などを経由してコンピュータ・ソフ
トウェアを特定のコンピュータ・システムに提供するこ
とも技術的に可能である。

【００１９】このような記憶媒体は、コンピュータ・シ
ステム上で所定のコンピュータ・ソフトウェアの機能を
実現するための、コンピュータ・ソフトウェアと記憶媒
体との構造上又は機能上の協働的関係を定義したもので
ある。換言すれば、本発明の第２の側面に係る記憶媒体
を介して所定のコンピュータ・ソフトウェアをコンピュ
ータ・システムにインストールすることによって、コン
ピュータ・システム上では協働的作用が発揮され、本発
明の第１の側面に係るデータ処理システム又は方法と同
様の作用効果を得ることができる。

【００２０】

【作用】本発明は、古いアプリケーションが新しいバー
ジョンのデータにアクセスしたり、新しいアプリケーシ
ョンが古いバージョンのデータにアクセスすることがで
きる、"future proof"並びに"past proof"と呼ぶことが
できるデータ・フォーマット（以下では、「スキーマ
（schema）」とも言う）のメカニズムを提供するもので
ある。

【００２１】データ構造進化手段又はステップは、第１
のデータ構造仕様に従って構造化されたデータにアクセ
ス可能に記述されたアプリケーションに対して、該第１
のデータ構造仕様を変更した第２のデータ構造仕様に従
って構造化されたデータへのアクセスを許容することが
できる。

【００２２】また、データ構造退化手段又はステップ
は、第２のデータ構造仕様に従って構造化されたデータ
にアクセス可能に記述されたアプリケーションに対し
て、第１のデータ構造仕様に従って構造化されたデータ
へのアクセスを許容することができる。

【００２３】したがって、データ構造が時間の経過とと
もに変更していっても、アプリケーション自体には何ら
変更を加えることなく、古いバージョン及び新しいバー
ジョンの双方に対して透過的にアクセスすることができ
る。

【００２４】本発明のさらに他の目的、特徴や利点は、
後述する本発明の実施例や添付する図面に基づくより詳
細な説明によって明らかになるであろう。

【００２５】

【発明の実施の形態】以下、図面を参照しながら本発明
の実施例を詳解する。

【００２６】本発明が適用される環境は、データベース
や多数のアプリケーションを実行することができる機
器、又は、機器のネットワークである。以下では、この
ような機器又はネットワーク上の機器のことを「クライ
アント機器」と呼ぶことにする。

【００２７】クライアント機器は、好ましくは、Ｊａｖ
ａ（商標）プログラミング言語やＣ＋＋などのようなオ
ブジェクト指向言語で記述された新しいソフトウェア・
モジュールをダウンロードする能力を備えている。ま
た、クライアント機器は、外部機器からデータを受信す
る能力も備えている。

【００２８】図１には、本発明を実現するのに適したク
ライアント機器１００のハードウェア構成を模式的に示
している。

【００２９】このクライアント機器１００は、アプリケ
ーション・プログラムを実行したり、他のハードウェア
・モジュールに対して制御コマンドや状態コマンドを送
信したりするプロセッサ１を含んでいる。プロセッサ１
は、外部ネットワークから受信したプログラム・コード
を実行する能力を備えている。このような能力は、例え
ばＪａｖａ仮想マシンと呼ばれるようなバイト・コード
・インタープリタを実現するソフトウェアを利用するこ
とによって構成される。Ｊａｖａ仮想マシンは、標準Ｊ
ａｖａプログラミング言語で記述されたコードを解釈し
且つ実行することができる。

【００３０】プロセッサ１は、バス２に接続され、他の
ハードウェア構成要素との間でデータやプログラムの転
送を行うことができる。ＰＣＩ（Peripheral Component
Interconnect）バスやこれと同種のバスをバス２とし
て適用することができる。

【００３１】バス２は、プログラムやデータを一時的に
保持するメモリ３に接続されている。同様に、バス２
は、記憶装置コントローラ４にも接続されている。記憶
装置コントローラ４は、ＳＣＳＩ（Small Computer Sys
tem Interface）コントローラ又はＩＤＥ（Integrated
Drive Electronics）コントローラに相当し、バス６を
介して不揮発性記憶装置５に接続されている。バス６は
ＳＣＳＩバス又はＩＤＥバスに相当し、不揮発性記憶装
置５はＳＣＳＩハード・ディスク又はＩＤＥハード・デ
ィスクに相当する。複数台の不揮発性記憶装置をバス６
上に配設してもよいし、また、上記したＳＣＳＩやＩＤ
Ｅ以外の標準仕様に従うバス・インターフェースを使用
してもよい。また、不揮発性記憶装置５の中には、クラ
イアント機器１００から取り外し可能に構成されたもの
もある。

【００３２】バス２は、さらに１又はそれ以上のネット
ワーク・コントローラ７にも接続されている。ネットワ
ーク・コントローラ７は、例えばＩＰ（Internet Proto
col）ネットワークのような外部ネットワーク８を介し
てプログラムやデータを送信したり、受信したり、解釈
したりすることができる。ネットワーク・コントローラ
７は、例えばテレビジョン・チューナのような、プログ
ラムやデータを受信可能な放送メディア受信機であって
もよい。勿論、クライアント機器１００は、他のネット
ワークに接続された複数のネットワーク・コントローラ
を備えていてもよい。

【００３３】本明細書中では、「スキーマ」（"schem
a"）という用語は、データ構造及びデータ構造の各要素
のタイプを記述したものを指す。スキーマの進化（sche
ma evolution）は、スキーマ又はスキーマに従うデータ
が新しいスキーマ構造に変更することを意味する。ま
た、スキーマの退化（schema devolution）は、あるス
キーマに従うデータをスキーマの古いバージョンに従う
ように変更するような逆のプロセスを意味する。

【００３４】データ・サービスを考慮した場合、異なる
サービス・プロバイダが同じスキーマを使用する方が都
合がよいことがしばしばある。事実、例えば、ＭＰＥＧ
（Moving Picture Experts Group）−７のような標準的
なフォーマットでデータを表現することが要求されてい
るサービスもある。

【００３５】標準化されたデータ構造であっても、時間
の経過とともにニーズが変化したり技術が進歩すること
に伴って進化する。データ構造が新しいバージョンにア
ップグレードされたとき、データ・サービス・プロバイ
ダは、新しいデータ構造が使用できるようにすべてのデ
ータ・サービスを同時にアップデートするとは限らな
い。アプリケーション・サービス・プロバイダに関して
もこれと同様のことが当てはまる。アプリケーションが
使用するデータに対してアクセスを行っているユーザが
いる限り、アプリケーション・サービス・プロバイダが
事業から撤退したりアプリケーションのサポート停止を
決定した数ヶ月又は数年経過した後であっても、アプリ
ケーション・サービス・プロバイダは、既存の巨大なユ
ーザ基盤を持ち続ける場合もある。

【００３６】本発明は、多数のデータ・プロバイダ、ク
ライアント機器上で実行される多数のアプリケーショ
ン、並びに、クライアント機器のローカル・データベー
スに蓄積されたバージョンが異なるスキーマで記述され
たデータが存在するような環境におけるスキーマの進化
に対応するものである。図２には、２度のアップグレー
ドが行われたスキーマの例を示している。同図におい
て、原初的なスキーマ１０はバージョン１であり、これ
を拡張することによりバージョン２のスキーマ１１がで
きる。スキーマのバージョン２をさらに修正することに
より、バージョン３のスキーマ３ができる。

【００３７】図３には、データ・プロバイダ、クライア
ント機器上のローカル記憶装置、並びにクライアント機
器上で実行されるアプリケーションのそれぞれが異なる
バージョンのスキーマを使用している様子を図解してい
る。

【００３８】ある特定の時間においては、複数のデータ
・プロバイダＡ、Ｂ、及びＣの各々が同じスキーマの異
なるバージョンを用いてデータを提供している。図３に
示す例では、データ・プロバイダＡは原初的なバージョ
ン１に従うデータを供給している。同様に、データ・プ
ロバイダＢは同じスキーマのバージョン２を使用し、デ
ータ・プロバイダＣは同じスキーマのバージョン３を使
用している。

【００３９】クライアント機器２６は、図示の３つのす
べてのプロバイダからデータを受信する。したがって、
クライアント機器２６のローカル・データベースには、
同じスキーマについての３つのすべてのバージョンのデ
ータが蓄積されることになる。ここで、プロバイダが過
去に同時にバージョン１のデータを供給していたなら
ば、スキーマ２８のバージョン１に従うデータは、プロ
バイダＡ、Ｂ、及びＣのうちいずれからも受け取り得た
という点に留意されたい。

【００４０】さらにクライアント機器２６は、３種類の
アプリケーション・プログラムＸ、Ｙ、及びＺを含んで
いる。各アプリケーション・プログラムは、同じスキー
マの異なるバージョンを使用するように記述されている
ものとする。アプリケーションＸ（３１）はデータベー
ス・スキーマのバージョン１を使用する。同様に、アプ
リケーションＹ（３２）は当該スキーマのバージョン２
を使用し、アプリケーションＺ（３３）は当該スキーマ
のバージョン３を使用する。従来より、各アプリケーシ
ョンは、該アプリケーション向けのスキーマのバージョ
ンに従って記述されたデータに対してはアクセスするこ
とができた。しかしながら、それぞれのアプリケーショ
ンが同じスキーマのいかなるバージョンに従うデータに
対してもアクセスできることが好ましい。

【００４１】データベース・スキーマの進化に関連する
分野では、既に多くの提案がなされている。例えばＵＲ
Ｌ"http://www.informatik.uni-trier.de/~ley/db/dbim
pl/evolution.html"でアクセス可能なホームページに
は、当該技術の従来技術に関する参考文献が掲載されて
いる。また、Ｏｂｊｅｃｔｉｖｉｔｙ，Ｉｎｃ社は、デ
ータベース・スキーマの進化に関する新規のソリューシ
ョンを提案したが、これに関しては、ＵＲＬ"http://ww
w.objectivity.com/ObjectDatabase/WP/Schema/schema.
html"でアクセス可能なホームページに論文が掲載さ
れ、また、米国特許番号５，７９４，０３０号明細書
（発明の名称："System and method for maintenance a
nd deferred propagation of schema changes to the a
ffected objects in an object oriented database"）
で権利化されている。これらのソリューションによれ
ば、データベース・サーバを実行しているままの状態
で、スキーマを更新することができる。蓄積されている
データは、最終的には新しいスキーマのフォーマットに
変換される。このような変換はすべて同時に行われる
か、又は、"lazy propagation"メカニズムを使用するこ
とでデータに最初にアクセスしたときにのみ変換される
ようになっている。いずれの場合であっても、古いスキ
ーマを使用したデータは新しいスキーマに変換されるの
で、依然として古いスキーマを使用するアプリケーショ
ンは変換後のデータに対してもはやアクセスできなくな
るという問題がある。

【００４２】オブジェクト指向言語は当該技術分野にお
いて既に広く知られているが、ここで、オブジェクト指
向言語に関する基本的な概念について考察してみる。

【００４３】例えば、Ｊａｖａプログラミング言語やＣ
＋＋などのようなオブジェクト指向言語では、クラスの
定義を行うことができる。図４には、Ｊａｖａプログラ
ミング言語で記述されたクラス定義の例を示している。

【００４４】クラスとは、クラスの特定の動作（behavi
or）を表現したプログラム・コード（すなわちクラスの
メソッド）とともに、データのメモリ上での記憶領域
（すなわちクラスのフィールド）を定義したものであ
る。図４に示す例では、"Foo"と呼ばれるクラスが、整
数（integer）フィールドを定義する"attribute1"、並
びに、文字列（String）フィールドを定義する"attribu
te2"という２つのフィールドを有している。タイプFoo
のすべてのオブジェクトは、attribute1並びにattribut
e2に割り当てられた保管場所を持つことになる。また、
タイプFooのすべてのオブジェクトは、method1及びmeth
od2の実装を持つことになる。

【００４５】図５には、クラス継承の例を示している。
同図に示す"Bar"というクラスは、上述のクラス"Foo"を
継承するものであり、これはクラスFooのすべてのフィ
ールド及びメソッドがクラスBarのインスタンスにおい
ても同様に利用可能であることを意味する。付言すれ
ば、継承したクラスにはフィールドやメソッドを追加し
たり、メソッドの実装コードをオーバーライド（再定
義）したりすることができる。図示のBarクラスの場
合、"attribute3"というフィールドと、"method3"とい
うメソッドをそれぞれ追加している。クラスBarのこと
をクラスFooに由来する（derived from）と言うことも
できる。図６には、クラス継承の関係をブロック図形式
で示している。

【００４６】またオブジェクト指向言語によっては、ク
ラスのフィールドや個々のメソッドの実装の詳細は記述
せずに、オブジェクトが備えるべきメソッドのセットの
みを定義するための機構を備えている場合もある。Ｊａ
ｖａプログラミング言語では、インターフェースを用い
ることでかかるメカニズムが実現される。本明細書中で
は、要求されたメソッドのセットを記述するためのメカ
ニズムを指す用語としてインターフェースを使用するこ
とにする。

【００４７】図７には、Ｊａｖａ構文を用いたインター
フェースの例を示している。"HasDuration"と名づけら
れたインターフェースは、getDurationとsetDurationと
いう２つのメソッドを定義しているが、これらのメソッ
ドをどのように実装すべきかについては指定していな
い。いかなるクラスもHasDurationを実装することがで
きるし、HasDurationで定義しているメソッドを用い
て、例えば、持続時間の長さを比較するコードを記述す
ることができる。

【００４８】図８には、クラスBarを継承するとともに
インターフェースHasDurationを実装したクラス"TimedB
ar"に関するクラス定義の例を示している。この例で
は、Timeオブジェクトを記憶するフィールドTimedBarが
定義される。このフィールドは、setDurationがコール
されたときにセットされ、getDurationがコールされた
ときに読み出される。Ｊａｖａ構文では、クラス定義に
関して、クラスに由来するときには"extends"（拡張）
というキーワードが使用され、インターフェースに由来
するときには"implements"（実装）というキーワードが
使用される。

【００４９】図９には、クラスTimedBarの継承木、すな
わち親クラスFooを拡張するとともに親インターフェー
スHasDurationを実装した様子を図解している。

【００５０】本発明に係るアプリケーションで使用され
るデータは、スキーマに基づいて構造化されている。図
１０には、スキーマの規定するデータ構造を有効グラフ
の形式で図解している。矩形のノードは、整数や文字列
などのような基本タイプを表す端点ノードである。一
方、円形で表されるノードは複数の属性を持つ構造を持
ったデータを表している。図１０において、属性はノー
ド間のリンクとして表しており、属性名はそのラベルと
記されている。ノードのスキーマは各ノードが持つべき
属性とそのタイプを規定する。

【００５１】図１０に示す例では、最上位レベルのスキ
ーマ"TVProgram"は、番組タイトル（title）と、持続時
間（duration）と、シーン（Scene）の一覧で構成され
る。さらに、シーン・スキーマは、開始時刻と終了時刻
で構成される。

【００５２】本発明では、スキーマの定義とデータへの
アクセスのために、オブジェクト指向プログラミング言
語におけるクラスとインターフェースを使用する。ま
た、新しいスキーマ・バージョンを古いバージョンに翻
訳するためにアダプタというクラスを使用する。

【００５３】本実施例におけるスキーマは、インターフ
ェースによって表現することができる。図１１には、"T
VProgram"並びに"Scene"というスキーマをＪａｖａイン
ターフェースによって記述した例を示している。

【００５４】スキーマが一旦インターフェースとして定
義されると、インターフェースを実装するとともに保管
とデータベースへの自動的なアクセスを提供するような
クラスを定義することができる。

【００５５】オブジェクト指向における継承という概念
によれば、スキーマの進化をごく自然な形式で実装する
ことができる。標準的なオブジェクト指向データベース
の場合、アプリケーションは、データベースにアクセス
する代わりに、クラス・オブジェクトとしてデータにア
クセスする。アプリケーションがクラス・インスタンス
の属性を取り出すようにコールしたときには、該クラス
はデータベースから適切なフィールドを自動的に読み出
す。

【００５６】本発明では、図１２に示すように、すべて
のデータ・クラスはNodeクラスを継承する。図示の例で
は、Nodeクラスの実装は、データベース中における各ノ
ード固有の識別子を表現するためのフィールドを定義し
ているだけである。通常のオブジェクト指向データベー
スの実情によれば、データベース中の各データ・オブジ
ェクトには、オブジェクトが最初にデータベース中に書
き込まれるときに、ルックアップ・キーとして機能する
ような固有に識別子が自動的に与えられるようになって
いる。データ・クラスの実装者またはアプリケーション
は、このような固有識別子フィールドを明確にセットす
る必要はない。

【００５７】Nodeクラスを継承することに加えて、デー
タ・クラスはその構造を定義するスキーマ・インターフ
ェースも実装しなければならない。図１３には、以前既
に導入されているTVProgramインターフェースを継承し
たクラスTVProgramImplのリストを示している。getTitl
eというメソッドは、データベース・キーとして固有識
別子を用いて、データベース中から当該オブジェクトに
対応するタイトルを読み出す。図示の例では、後述する
他のすべてのプログラミング例と同様に、変数ｄｂで表
される単一のデータベースを想定しており、以下の単純
なインターフェースを提供する。

【００５８】

【数１】get<TYPE> Attribute(Class schemaInterface,
int nodeID, String attributeName) set<TYPE> Attribute(Class schemaInterface, int nod
eID, String attributeName,<TYPE> newValue)

【００５９】ここで、<TYPE>は、適切なデータ・タイプ
で置き換えられる。上記の例では、文字列、時間、及
び、オブジェクトという３種類のタイプが使用される。
また、schemaInterfaceは、属性のタイプ（スキーマ）
を指定するインターフェースである。また、nodeIDは、
読み出し又は書き込まれるノードに関するデータベース
中での固有の整数識別子である。また、attributeName
は、読み出し又は書き込まれる属性の名前である。ま
た、newValueは、書き込まれた属性の新しい値である。
オブジェクト指向データベースのほとんどは、少なくと
もこのような最小限の機能を提供している。データベー
スに関する他の機能については後述に譲る。

【００６０】setTitleというメソッドは、固有識別子を
キーとして用いながら、データベース中にタイトル・パ
ラメータを書き込む。同様に、durationという属性は、
getDurationというメソッドによってデータベースから
読み出されるとともに、setDurationというメソッドに
よってデータベースに書き込まれる。Sceneのリスト
は、オブジェクトの配列としてデータベースに書き込ま
れる。ここで、Ｊａｖａ言語ではオブジェクトの配列も
オブジェクトとして扱われる点に留意されたい。

【００６１】次いで、スキーマの変更について説明す
る。本発明では、属性が追加されるようなスキーマの変
更についてのみ考慮し、例えば属性の削除、タイプの変
更といった既存の属性に関する変更については考慮しな
いものとする。（一般には、属性のタイプの変更は許容
されないが、属性のタイプをサブタイプに変更すること
は許される。詳細は後述に譲る）。もしこういった変更
が必要な場合には、新たな属性を別の名前で追加した上
で、元の属性を無視すれば済むので、このような方策は
限定的とは言えない。

【００６２】図１４には、例示したスキーマを変更した
例を示している。図示の通り、TVProgramスキーマに対
して新しい属性"broadcaster name"を追加することによ
って、新しいスキーマTVProgram2が生成される。この新
しい属性は、ユーザが特定の放送局を指定してプログラ
ムを検索するような場合においてとりわけ有効である。
このようなスキーマの変更は、TVProgramスキーマにの
み影響し、該スキーマに埋め込まれている"scene"スキ
ーマには影響しないという点に留意されたい。

【００６３】修正されたスキーマを記述するインターフ
ェースは図１５のようになる。このインターフェースに
は、"getBroadcasterName"及び"setBroadcasterName"と
いう２つのメソッドが追加される。図１６には、対応す
る実装クラスTVProgramImpl2のリストを示している。ま
た、図１７には、この実施例に係るインターフェースと
クラス間の関係を図解している。

【００６４】アプリケーションは、データベースに直接
アクセスすることは許されず、ローカル・データベース
中のデータにアクセスするためには、スキーマ・インタ
ーフェースで定義されているメソッドを用いなければな
らない。この規則に従うならば、上述したような継承を
使用することによってスキーマの進化を当然にして実現
することができる。この例に係るTVProgramインターフ
ェースを用いて記述されたいかなるアプリケーションも
また、TVProgramインターフェースを継承して修正され
たスキーマに従うオブジェクトを使用することができ
る。

【００６５】次いで、スキーマの退化の場合について説
明する。より新しいバージョンのスキーマ・インターフ
ェースに合わせて記述されたアプリケーションは、古い
データにアクセスするためには、スキーマの退化（すな
わちダウングレード）を行う必要がある。このような場
合、古いデータは、アプリケーションか要求する新しい
メソッド（又はフィールド）を含んでいない点に問題が
ある。このような問題を解決するために、本発明では、
アダプタという概念を導入する。アダプタ・クラスは他
のデータ（adaptee）への参照を持ち、そのスキーマ・
インターフェースを更新された新しいスキーマ・インタ
ーフェースへと翻訳する機能を持つ。アダプタ・クラス
自身も更新されたスキーマ・インターフェースを継承す
るので、アダプタ・クラスのインスタンスはちょうど新
しいクラスのインスタンスとして機能することができ
る。開発者が古いスキーマを継承する新しいスキーマを
定義した場合、開発者はそのスキーマについてのアダプ
タ・クラスを提供することが望まれる。

【００６６】図１８には、すべてのアダプタ・クラスが
実装すべきインターフェースを示している。fromInterf
aceは、アダプタが翻訳するインターフェースを返すメ
ソッドである。また、toInterfaceは、アダプタが提供
するインターフェースを返すメソッドである。またsetA
dapteeは、変換の対象となるデータ・オブジェクト（ad
aptee）を設定するためのメソッドである。

【００６７】図１９には、TVProgramオブジェクトを新
しいTVProgram2オブジェクトに翻訳するアダプタの例を
示している。TVProgram2オブジェクトとして動作するた
めに、TVProgram1to2AdapterクラスはTVProgram2インタ
ーフェースを継承する。該クラスは、アップグレードさ
れたTVProgramインスタンスを参照するときに使用するa
dapteeフィールドを定義する。

【００６８】本実施例では、例えばgetTitle、setTitl
e、getDuration、setDuration、getScene、setSceneと
言った古いスキーマが実装したメソッドは、単にadapte
eのメソッドをコールするだけである。TVProgram2によ
って追加されたメソッドもここで実装しなければならな
い。getBroadcasterNameというメソッドは、デフォルト
の文字列を返すように実装される。しかしなから、開発
者はさらに洗練されたメソッドを自由に記述することが
できる。例えば、メソッドgetBroadcasterNameを、Ｗｅ
ｂベースのデータベースを用いて放送局名を探索するよ
うに構成してもよい。

【００６９】古いオブジェクトは放送曲名属性を保管す
るための記憶領域を含んでいないので、setBroadcaster
NameはUnsupportedOperationException（非サポート例
外）を投げるように記述される。あるいは、このメソッ
ドが呼び出された時点で、データベースに格納されてい
るデータを新しいスキーマのデータに書き換えた上で、
該当する属性の値を書きかえてもよい。

【００７０】図２０には、スキーマ・インターフェー
ス、及びその実装クラスの異なるバージョン、及びアダ
プタ・クラス関係について図解している。

【００７１】同図において、TVProgram１００は元のス
キーマである。TVProgramImplクラス１０２は、TVProgr
amを実装したクラスであり、そのインスタンスはデータ
ベース中のオブジェクトに対応する。TVProgramImpl
は、Nodeクラスを継承しており,TVProgramImplに対する
メソッド・コールは、データの読み出し及び書き込みを
行うデータベース・トランザクションとなる。

【００７２】TVProgram2インターフェース１０３は、ア
ップグレードされたスキーマである。該インターフェー
スは、TVProgramインターフェース１００を継承したも
のである。TVProgram2Impl１０４は、TVProgram2インタ
ーフェース１０３を実装し、TVProgramImplクラス１０
２を継承したクラスである。TVProgram1to2Adapterクラ
ス１０５も、TVProgram2インターフェース１０５を実装
したものである。該クラスは、TVProgramImplクラス１
０２のインスタンスを指すadapteeフィールド１０６を
備えている。

【００７３】以上は既存のスキーマに新たな属性を追加
する場合について述べた。次に既存の属性のスキーマ
（サブスキーマ）を更新する場合について述べる。図２
１には、TVProgramスキーマを更新したTVProgram2スキ
ーマを更に修正したTVProgram3について図解している。
今回の修正では、Sceneサブスキーマ８３に対して、キ
ー・フレーム属性９０を追加するように修正が加えられ
ている。ここで言うキー・フレームとは、ビデオ・シー
ンにおける代表フレームを意味する。本明細書中では、
修正されたスキーマ８９のことをScene2を呼ぶことにす
る。Sceneサブスキーマの更新に伴って、TVProgram2ス
キーマについてもその"scene"の属性のタイプが更新さ
れる。

【００７４】図２２には、新しいスキーマ・インターフ
ェースを記述したプログラム・リストの例を示してい
る。Scene2インターフェースは、以前の例に対して新し
いメソッドgetKeyFrame及びsetKeyFrameを追加してでき
る。一方、本来ならばTVProgram3インターフェースは、
Sceneオブジェクトの代わりに、Scene2オブジェクトの
配列を返すようにgetScenesをオーバーライド（再定
義）すべきである。しかしながら、Ｊａｖａプログラミ
ング言語では、異なるタイプを返すようなオーバーライ
ドするのは、たとえその返値のタイプが元のタイプのサ
ブタイプである場合であっても許されていない。そこ
で、この例においては、実質的な変更を伴わないダミー
のサブインターフェースTVProgram3を定義している。こ
の場合、getScenes関数を呼ぶ側が返値に対し明示的に
型のキャストを行うことになる。なお、Ｃ＋＋のような
他の言語ではメソッドに対するこのようなオーバーライ
ドが許されている場合もある。

【００７５】図２３には、TVProgram3スキーマ・インタ
ーフェースを実装したTVProgram3Implの実装コードを示
している。TVProgram3ImplはさらにTVProgram2Implを継
承し、getScenesメソッドをオーバーライドしている。
このメソッドは、親クラスによって使用されるSceneオ
ブジェクトの代わりにデータベースからScene2オブジェ
クトの配列を読み出す。

【００７６】図２４には、Scene2に関するクラス及びイ
ンターフェース、並びにその親クラス及びインターフェ
ースの構成図を示している。また、図２５には、TVProg
ramインターフェース及びそのサブインターフェースに
関する新しい継承木を図解している。

【００７７】TVProgram2に関しては、TVProgram2インタ
ーフェースからTVProgram3インターフェースへの翻訳を
行うアダプタ・クラスを生成する必要がある。図２６に
は、このクラスのプログラム・リストを示している。TV
Program2to3Adapterでは、getScenesメソッドを実装す
る際にすべてのSceneオブジェクトをScene2オブジェク
トに翻訳するために何らかの特別な処理を行う必要があ
る。これは、Scene1to2Adapterインスタンスの配列を生
成することによって実現される。（Scene1to2Adapterク
ラスに関しては後述する）。この例で示したように、属
性のタイプをアップグレードする場合は、その属性のデ
ータ・オブジェクトのスキーマをアップグレードするの
に必要な新たなアダプタを生成し、それを返すようにす
る。

【００７８】他のすべてのメソッドは、以前の例と同
様、単にadapteeの同じメソッドをコールするだけであ
る。図２７には、Scene2to3Adapterに関するクラス継承
図を示している。

【００７９】図２８には、Scene1to2Adapterを実装した
プログラム・リストを示しているが、これは、TVProgra
m1to2Adapterと同様のパターンとなる。また、図２９に
は、Scene1to2Adapterのクラス継承を図解している。

【００８０】本実施例に係るシステムでは、従来のオブ
ジェクト指向データベースで用いられたものと同様のパ
ラダイムによりデータ・アクセスが実現される。ほとん
どのオブジェクトは、他のオブジェクトからの参照によ
ってアクセスされるが、参照の起点となる"root"オブジ
ェクトについては、文字列で指定される名前によって参
照される。”root”オブジェクトにアクセスするための
アプリケーション・コードの例を以下に示しておく。

【００８１】

【数２】Database db; /* initialize database */ ......... /* retrieve top level object by name */ TVProgram p = db.getRoot("the Simpsons EPISODE AAB
F13",TVProgram.class);

【００８２】上記の例では、データベースは、ノード名
及びスキーマ・インターフェースを指定して”root”ノ
ードを取り出すための、getRootメソッドを提供してい
る。

【００８３】getRootメソッドでは、引数で指定された
ノードのタイプを調べ、それが指定されたスキーマ・イ
ンターフェースに適合する場合には、通常のオブジェク
ト指向データベースと同様に、そのノードを表すオブジ
ェクトをデータベースから取り出し、アプリケーション
に返す。

【００８４】一方、データベース中のノードのタイプと
引数でしてされたスキーマ・インターフェースの型が適
合しない場合には、以下に述べる手順に従い、オブジェ
クトを翻訳することができる適切なアダプタ・クラスを
探索する。１つのアダプタ・クラスが見つかった場合に
は、データベースはこれをインスタンス化して戻り値と
する。他方、適切なアダプタ・クラスがまったく見つか
らなかった場合には、探索に失敗する。

【００８５】アダプタ・クラスの探索を可能にするため
には、すべてのアダプタ・クラスをアダプタ・マネージ
ャに登録しておかなければならない。この登録手続き
は、アダプタ・クラスがシステムに最初にロードされる
ときに自動的に行うべきである。

【００８６】図３０には、簡易で且つ効果的なアダプタ
・マネージャの実装例を図解している。このアダプタ・
マネージャは、キー値の組に高速アクセスするためのマ
ッピング・テーブルを含んでいる。ここで使用されるキ
ーは、アダプタが翻訳する"fromInterface"インターフ
ェースと"toInterface"インターフェースの組合せであ
る。図３０では、キーは内部クラスAdapterKeyとして示
されている。AdapterKeyは、fromInterfaceとtoInterfa
ce両方を同時に比較するためequalメソッドをオーバー
ライドしている。

【００８７】registerAdapterは、アダプタ・クラスを
登録すラメのメソッドで、引数として渡されたアダプタ
・クラスの”fromInterface”インターフェース, “toI
nterface”インターフェースに基づいてキーを生成し、
内部のマッピング・テーブルへ格納する。またunregist
erAdapterメソッドは、該マッピング・テーブルからア
ダプタ・エントリを取り除くメソッドである。

【００８８】createAdapterは、所定の"from"及び"to"
インターフェースに該当するアダプタを探し出すメソッ
ドである。図３０に示した実装例では、極めて簡素なテ
ーブル探索で実現する。アダプタが見つかったときに
は、呼び出し元に対してこれを返す。また、該当するア
ダプタが見つからなかったときには例外が投じられる。
createAdapterの他の実装例では、一連のアダプタ・ク
ラスを照合するため処理をより洗練することができるで
あろう。

【００８９】これまでに説明した実施例では、TVProgra
mスキーマ・インタフェースは２度修正されている。す
なわち、１度目の修正では放送局名属性が追加され（TV
Program2インターフェースに帰する）、２度目の修正で
は、キー・フレーム属性がサブスキーマに追加されてい
る（TVProgram3インターフェースに帰する）。

【００９０】TVProgramインターフェースに関してのみ
知るアプリケーションであっても、これよりも新しいTV
Program2インターフェースやTVProgram3インターフェー
スに従って記述されたデータを使用することができる。
何故ならば、これら新しいインターフェースは、TVProg
ramインターフェースを実装しているからである。一般
に、オブジェクト指向言語のクラス継承特性によれば、
スキーマの古いバージョンを使用するアプリケーション
は、スキーマの新しいバージョンを使用するデータ・オ
ブジェクトのメソッドをコールすることができる。何故
ならば、新しいバージョンは同じインターフェースを継
承しているからである。

【００９１】ここで、TVProgram3インターフェースを使
用するように記述されたアプリケーションの場合につい
て考察してみる。上述では、スキーマをあるバージョン
から以前のバージョンにアップグレードするためにアダ
プタ・クラスをどのように使用することができるかにつ
いて説明してきた。しかし、複数の変更が行われたよう
な場合、例えば、TVProgram3インターフェースに適合さ
せるためにTVProgramデータを２回にわたってアップグ
レードした場合は、どのようにすればよいであろうか。

【００９２】この件に関して、少なくとも２通りの解決
法が可能である。新しいスキーマの開発者は、アダプタ
・マネージャに登録されている"TVProgram1to3"アダプ
タ・クラスを提供することができる。しかしながら、ス
キーマの以前のすべてのバージョンのために記述された
アダプタ・クラスを要求することは、アプリケーション
開発者にとって過大な負担である。

【００９３】アダプタ・マネージャは、既存のTVProgra
m1to2アダプタ及びTVProgram2to3アダプタのクラスを用
いることで、新しいアダプタを生成することができる。
この際、TVProgram2to3アダプタのadapteeフィールドに
はTVProgram1to2アダプタのインスタンスをセットす
る。一般に、新しいスキーマ・インターフェースについ
て、その直近の親インターフェースに対するアダプタが
用意されてさえいれば、それらのアダプタを入れ子状に
組み合わせることにより、任意の祖先との間でのアダプ
タを生成することができる。図３１には、このようなこ
とを実現するプログラミング・コードのリストを示して
いる。createAdapterの新しいバージョンは、fromInter
faceをtoInterfaceに変換するのに必要なアダプタのセ
ットを再帰的に探索する。アダプタをチェーン状に連結
していく。この時、各アダプタの”adaptee”フィール
ドは、最後のアダプタを除いてチェーン上での次のアダ
プタとなる。アダプタの入れ子構造が発見されなかった
場合には、例外が投じられる。

【００９４】TVProgram1からTVProgram3へのアダプタを
生成する例について説明する。但し、TVProgram1to2Ada
pter及びTVProgram2to3Adapterの各アダプタは既にアダ
プタ・マネージャに登録されていると仮定する。ここ
で、以下に示すコードについて考察してみる。

【００９５】

【数３】/* AdapterManager instance owned by the da
tabase */ AdapterManager manager; /* An instance that implements TVProgram */ TVProgram1Impl tv1; /* assume manager and tv1 are initialized elsewher
e */ ............ Adapter exampleAdapter =Manager.createAdapter(TVPr
ogram.class, TVProgram3.class, tv1);

【００９６】図３２〜図３５には、このコードの動作を
図解している。

【００９７】図３２では、引数"toInterface"がTVProgr
am2３０２にセットされ、引数"fromInterface"がTVProg
ram3３００にセットされ、所望のアダプタ３０３は未知
とする。

【００９８】図３１にプログラム・リストを示したcrea
teAdapterメソッドを用いて、行番号０２において、TVP
rogram1及びTVProgram3のクラス・オブジェクトを使用
するアダプタに関するアダプタ・マネージャの内部テー
ブルを引くためのキーを生成する。TVProgram1をTVProg
ram3に翻訳するアダプタが登録されていないので、行番
号０３において該テーブルを検索したときにgetメソッ
ドはＮＵＬＬを返す。

【００９９】行番号０８では、fromInterface（TVProgr
am1）がtoInterface（TVProgram3）のスーパーインター
フェースか否かをチェックする。fromInterfaceがtoInt
erfaceへのサブインターフェースである場合には、アダ
プタが生成できない（アダプタを利用する必要がない）
ため処理は失敗に終わる。但し、ここではTVProgram1は
TVProgram3のスーパーインターフェースであり、行番号
１０に相当する処理へと続く。

【０１００】行番号１０〜１２では、toInterfaceの直
近の親インターフェースがfromInterfaceと同じである
か否かをチェックする。もし判断結果が真であれば、ア
ダプタを生成できないことを意味する。何故ならば、行
番号０３における検索によって、"fromInterface"から"
toInterface"までの間にはアダプタは存在しないと判定
されているからである。ここでは、図３２からも分かる
ように、TVProgram2がtoInterface（TVProgram3）に対
する直近の親となる。

【０１０１】処理の実行はさらに行番号１４〜１６へと
続き、問合せに照合する一連のアダプタを構築するため
に、再帰的探索を実行する。この時点における実行状況
は、図３２に示す通りである。行番号１４では、行番号
３０〜４５で定義されている、toInterfaceの直近の親
スキーマ・インターフェースを戻すユーティリティ機能
を使用する。（該ユーティリティ機能getParentSchemaI
nterfaceは、実際には、引数として渡されたクラスの実
装するアダプタ・クラスではない最初のインターフェー
スを返す。より簡潔に言えば、各クラスは、単一のスキ
ーマ・インターフェースのみを実装するものと仮定す
る。）

【０１０２】行番号１５では、最初の再帰的検索を実行
して、createMethodを再帰的にコールすることによっ
て、fromInterfaceであるTVProgram３００からtoInterf
aceの親インターフェース（すなわちTVProgram2３０
１）までのアダプタ・クラスの生成を試行する。図３３
には、最初の再帰的コールについて図解している。TVPr
ogram1to2Adapterは既にTVProgramをTVProgram2に変換
するアダプタとして登録されているので、TVProgram1to
2Adapter３０５が瞬時に返される。TVProgram1to2Adapt
erはチェーン上の最後のアダプタなので、tv1すなわち
元のadapteeにセットされたadapteeフィールドを持つこ
とになるという点に留意されたい。

【０１０３】図３４には、TVProgram2３０１をTVProgra
m3３０２に変換することができるアダプタを探索する様
子を示している。createMethodをコールすると、すぐに
TVProgram2to3Adapter３０４が見つけ出されて返され
る。この時点では、行番号１５における探索の結果すな
わちアダプタ・クラスａが、行番号１６における探索結
果のadapteeとして用いられる。この結果として図３５
に示すように、TVProgram３００をTVProgram3３０２に
変換するアダプタ３０６が、TVProgram1to2Adapter３０
５とTVProgram2to3Adapter３０４の組み合わせとして形
成されたことになる。

【０１０４】新たに生成されたアダプタｂは、行番号１
７において、呼び出し元に返される。

【０１０５】exampleAdapterに対して適用されるすべて
のTVProgramメソッド・コールは、まず最初にTVProgram
2to3Adapterのadapteeフィールドを通過し、アダプタａ
３０５のadapteeフィールドに渡される。次いで、アダ
プタａは、これらのコールをさらにaのadapteeフィルド
で参照されるオブジェクトに委譲する。この例では、ア
ダプタａのadapteeフィルドが tv1 に設定されている。

【０１０６】exampleAdapterに対して適用されるTVProg
ram2メソッド・コールは、同様に、exampleAdapterのad
apteeフィールドで参照されるTVProgram1to2Adapterに
委譲される。TVProgram1to2Adapterは、これらをtv1に
は渡さず、その代わりに、getBroadcasterNameメソッド
に代わるデフォルト値を供給することによって自ら処理
する。

【０１０７】exampleAdapterに対して適用されるTVProg
ram3メソッド・コールは、他に委譲されることはない。
これらのコールは、TVProgram2to3Adapterによって直接
処理され、Scene1to2Adapterのオブジェクトの新しい配
列を返す。図２６にはこの点について図解している。

【０１０８】上記のcreateAdapterの処理は、スキーマ
が何代にも渡って更新された場合であっても適用でき
る。さらには図３６に示すように、スキーマのバージョ
ンが分岐している、すなわち複数のスキーマが同じ親ス
キーマを継承して定義されている場合であっても以下に
述べるように、前述の方法を拡張することで対応でき
る。

【０１０９】図３６において、円形はスキーマを表して
いる。この図において、スキーマ４００から、異なる２
つのバージョン４０１および４０２が派生している。同
様にスキーマ４０１から派生して４０３、４０４という
二つのバージョンが定義されている。さらにスキーマ４
０４に対し、４０６、４０７という２つの派生スキーマ
が定義されるている。

【０１１０】このような複数のスキーマへの分岐が発生
するような、より一般的な場合では、以下のようにcrea
teAdapterメソッドを変更することによって処理するこ
とができる。まず最初に"fromInterface"及び"toInterf
ace"の最も近い共通の祖先インターフェースを求める。
次に前述の方法により祖先インターフェースと”toInte
rface”へのアダプタを求める。ここで”fromInterfac
e”はこの祖先インターフェースを継承しているの
で、”fromInterface”から祖先インターフェースへと
翻訳すのに特にアダプタは必要としない。従って祖先イ
ンタフェースから”toInterface”へと翻訳するアダプ
タを用いて”fromInterface”から”toInterface”への
翻訳を実現することが可能となる。

【０１１１】図３６に示す例では、４０３から４０７へ
変換したい場合には、まず最初に最も近い共通の祖先と
して４０１を見つけ出す。次に、４０１から４０７への
アダプタを生成し、このアダプタの”adaptee”フィー
ルドを４０３のデータ・オブジェクトへの参照へと設定
する。

【０１１２】本明細書中並びに添付図面でＪａｖａプロ
グラミング言語形式で記述されたスキーマの例では、説
明を簡単にするため、sceneオブジェクトのグループを
表現するために配列を使用しているが、その代わりにJa
va Collectionインターフェース又はこれの等価物を使
用してもよい。Collectionインターフェースは、Collec
tionに対する要素の追加や削除によってデータベースに
対するオブジェクトの追加や削除を自動化することがで
きるので、より柔軟性に富んでいる。オブジェクト指向
プログラミングに精通した当業者であれば、より適切な
Collectionオブジェクトに対して本発明を適用できるこ
とを理解できるであろう。

【０１１３】［追補］以上、特定の実施例を参照しなが
ら、本発明について詳解してきた。しかしながら、本発
明の要旨を逸脱しない範囲で当業者が該実施例の修正や
代用を成し得ることは自明である。すなわち、例示とい
う形態で本発明を開示してきたのであり、限定的に解釈
されるべきではない。本発明の要旨を判断するために
は、冒頭に記載した特許請求の範囲の欄を参酌すべきで
ある。

【０１１４】

【発明の効果】以上詳記したように、本発明によれば、
オブジェクト指向言語によって記述されたクラス及びイ
ンターフェースの継承メカニズムを利用した、優れたデ
ータ処理システム及び方法を提供することができる。

【０１１５】また、本発明によれば、データ構造が経時
的に変化する（データベース・スキーマ・エボリューシ
ョン）ような場合であっても、アプリケーションに対し
て構造化データへのアクセスを許容することができ、ク
ラス及びインターフェースの継承メカニズムを利用し
た、優れたデータ処理システム及び方法を提供すること
ができる。

【０１１６】また、本発明によれば、古いアプリケーシ
ョンが更新されたスキーマに従う新しいデータに対して
も透過的にアクセスすることができるとともに、新しい
アプリケーションが古いデータ構造に従う古いデータに
対しても透過的にアクセスすることができ、クラス及び
インターフェースの継承メカニズムを利用した、優れた
データ処理システム及び方法を提供することができる。

【図面の簡単な説明】

【図１】本発明を実現するのに適したクライアント機器
１００のハードウェア構成を模式的に示した図である。

【図２】２度のアップグレードが行われたスキーマの例
を示した図である。

【図３】データ・プロバイダ、クライアント機器上のロ
ーカル記憶装置、並びにクライアント機器上で実行され
るアプリケーションのそれぞれが異なるバージョンのス
キーマを使用している様子を示した図である。

【図４】Ｊａｖａプログラミング言語で記述されたクラ
ス定義の例を示した図である。

【図５】クラス継承の例を示した図である。

【図６】クラス継承の関係を示したブロック図である。

【図７】Ｊａｖａ構文を用いたインターフェースの例を
示した図である。

【図８】クラスＢａｒを継承するとともにインターフェ
ースHasDurationを実装したクラス"TimedBar"に関する
クラス定義の例を示した図である。

【図９】クラスTimedBarの継承木、すなわち親クラスFo
oを継承するとともに親インターフェースHasDurationを
実装した様子を示した図である。

【図１０】スキーマの構造を有効グラフの形式で示した
図である。

【図１１】"TVProgram"並びに"Scene"というスキーマを
Ｊａｖａインターフェースによって記述した例を示した
図である。

【図１２】すべてのデータ・クラスがノード・クラスを
継承する例を示した図である。

【図１３】以前既に導入されているTVProgramインター
フェースを継承したクラスTVProgramImplのリストを示
した図である。

【図１４】スキーマを変更した例を示した図である。

【図１５】修正されたスキーマを記述するインターフェ
ースを示した図である。

【図１６】実装クラスTVProgramImpl2のリストを示した
図である。

【図１７】インターフェースとクラス間の関係を示した
図である。

【図１８】すべてのアダプタ・クラスが実装しなければ
ならないアダプタ・インターフェースを示した図であ
る。

【図１９】TVProgramオブジェクトを新しいTVProgram2
オブジェクトに翻訳するアダプタの例を示した図であ
る。

【図２０】TVProgramスキーマ・インターフェース、ク
ラス、及びアダプタの異なるバージョン間の関係につい
て示した図である。

【図２１】TVProgramスキーマの第２番目の修正を示し
た図である。

【図２２】新しいインターフェースを記述したプログラ
ム・リストの例を示した図である。

【図２３】TVProgram3インターフェースを実装したTVPr
ogramImplの実装形態を示した図である。

【図２４】Scene2に関するクラス及びインターフェー
ス、並びにその親クラス及びインターフェースの構成図
である。

【図２５】TVProgramインターフェース及びそのサブイ
ンターフェースに関する新しい継承木を示した図であ
る。

【図２６】TVProgram2インターフェースからTVProgram3
インターフェースへの翻訳を行うアダプタ・クラスのプ
ログラム・リストである。

【図２７】Scene1to2Adapterに関するクラス継承図であ
る。

【図２８】Scene1to2Adapterを実装したプログラム・リ
ストである。

【図２９】Scene1to2Adapterのクラス継承図である。

【図３０】簡易で且つ効果的なアダプタ・マネージャの
実装例を示した図である。

【図３１】インターフェースとその祖先との間でアダプ
タの生成を実現するプログラミング・コードのリストで
ある。

【図３２】TVProgram1からTVProgram3へのアダプタを生
成するcreateAdapterをコールする様子を示した図であ
り、より具体的には、再帰的探索を開始した時点におけ
る実行状況を示した図である。

【図３３】TVProgram1からTVProgram3へのアダプタを生
成するcreateAdapterをコールする様子を示した図であ
り、より具体的には、最初の再帰的コールを行う様子を
示した図である。

【図３４】TVProgram1からTVProgram3へのアダプタを生
成するcreateAdapterをコールする様子を示した図であ
り、より具体的には、TVProgram2３０１をTVProgram3３
０２に変換することができるアダプタを探索する様子を
示した図である。

【図３５】TVProgram1からTVProgram3へのアダプタを生
成するcreateAdapterをコールする様子を示した図であ
り、より具体的には、TVProgram３００をTVProgram3３
０２に変換することができる単一のアダプタ３０６が形
成される様子を示した図である。

【図３６】複数のスキーマへの分岐が発生するような、
より一般的なスキーマ家系図の例である。

【符号の説明】

１…プロセッサ２…バス３…メモリ４…記憶装置コントローラ５…不揮発性記憶装置６…バス７…ネットワーク・コントローラ８…ネットワーク１００…クライアント機器

Claims

【特許請求の範囲】

【請求項１】オブジェクト指向言語及びプログラミング
・インターフェースを用いてデータベースに格納された
構造化データにアクセスするデータ処理システムであっ
て、アプリケーションを実行するアプリケーション実行手段
と、データ構造の仕様をアプリケーションと分離可能な形式
で指定するデータ構造指定手段と、第１のデータ構造仕様に従って構造化されたデータにア
クセス可能に記述されたアプリケーションに対して、該
第１のデータ構造仕様を変更した第２のデータ構造仕様
に従って構造化されたデータへのアクセスを許容するデ
ータ構造進化手段と、第１のデータ構造仕様を変更した第２のデータ構造仕様
に従って構造化されたデータに対してアクセス可能に記
述されたアプリケーションに対して、第１のデータ構造
仕様に従って構造化されたデータへのアクセスを許容す
るデータ構造退化手段と、を具備することを特徴とする
データ処理システム。
【請求項２】前記データ構造進化手段は、第１のデータ
構造仕様に従って構造化されたデータにアクセス可能に
記述されたアプリケーションに対して、該第１のデータ
構造仕様に複数回の変更を行った第２のデータ構造仕様
に従って構造化されたデータへのアクセスを許容するこ
とを特徴とする請求項１に記載のデータ処理システム。
【請求項３】前記データ構造退化手段は、第１のデータ
構造仕様に複数回の変更を行った第２のデータ構造仕様
に従って構造化されたデータにアクセス可能に記述され
たアプリケーションに対して、第１のデータ構造仕様に
従って構造化されたデータへのアクセスを許容すること
を特徴とする請求項１に記載のデータ処理システム。
【請求項４】前記データ構造進化手段は、オブジェクト
指向言語で記述されたクラス又はインターフェースの継
承メカニズムであることを特徴とする請求項１に記載の
データ処理システム。
【請求項５】前記データ構造退化手段は、該第１のデー
タ構造仕様を該第２のデータ構造仕様に変換するアダプ
タ・クラス又はインターフェースと、前記アダプタ・ク
ラス又はインターフェースを管理するアダプタ・マネー
ジャとで構成されて、問合せに応答して、第１のデータ
構造仕様から第２のデータ構造仕様に変換可能な１以上
のアダプタを探索し及び／又は生成することを特徴とす
る請求項１に記載のデータ処理システム。
【請求項６】さらに、スキーマを識別する識別手段と、格納されたデータに対する透過的なアクセスを提供する
データベース・インターフェースと、データをインポートする手段と、インポートされたデータとスキーマとを関連付ける手段
と、データベースを格納する格納手段と、を備えることを特
徴とする請求項１に記載のデータ処理システム。
【請求項７】オブジェクト指向言語及びプログラミング
・インターフェースを用いてデータベースに格納された
構造化データにアクセスするデータ処理方法であって、アプリケーションを実行するアプリケーション実行ステ
ップと、データ構造の仕様をアプリケーションと分離可能な形式
でデータ構造を指定するデータ構造指定ステップと、第１のデータ構造仕様に従って構造化されたデータにア
クセス可能に記述されたアプリケーションに対して、該
第１のデータ構造仕様を変更した第２のデータ構造仕様
に従って構造化されたデータへのアクセスを許容するデ
ータ構造進化ステップと、第１のデータ構造仕様を変更した第２のデータ構造仕様
に従って構造化されたデータに対してアクセス可能に記
述されたアプリケーションに対して、第１のデータ構造
仕様に従って構造化されたデータへのアクセスを許容す
るデータ構造退化ステップと、を具備することを特徴と
するデータ処理システム。
【請求項８】前記データ構造進化ステップでは、第１の
データ構造仕様に従って構造化されたデータにアクセス
可能に記述されたアプリケーションに対して、該第１の
データ構造仕様に複数回の変更を行った第２のデータ構
造仕様に従って構造化されたデータへのアクセスを許容
することを特徴とする請求項７に記載のデータ処理方
法。
【請求項９】前記データ構造退化ステップでは、第１の
データ構造仕様に複数回の変更を行った第２のデータ構
造仕様に従って構造化されたデータにアクセス可能に記
述されたアプリケーションに対して、第１のデータ構造
仕様に従って構造化されたデータへのアクセスを許容す
ることを特徴とする請求項７に記載のデータ処理方法。
【請求項１０】前記データ構造進化ステップは、オブジ
ェクト指向言語で記述されたクラス又はインターフェー
スの継承メカニズムを用いて実現されることを特徴とす
る請求項７に記載のデータ処理方法。
【請求項１１】前記データ構造退化ステップは、該第１
のデータ構造仕様を該第２のデータ構造仕様に変換する
サブステップと、前記アダプタ・クラス又はインターフ
ェースを管理するサブステップとで構成されて、問合せ
に応答して、第１のデータ構造仕様から第２のデータ構
造仕様に変換可能な１以上のアダプタを探索し及び／又
は生成することを特徴とする請求項７に記載のデータ処
理方法。
【請求項１２】オブジェクト指向言語及びプログラミン
グ・インターフェースを用いてデータベースに格納され
た構造化データにアクセスするデータ処理をコンピュー
タ・システム上で実行するためのコンピュータ・ソフト
ウェアをコンピュータ可読形式で物理的に格納した記憶
媒体であって、前記コンピュータ・ソフトウェアは、アプリケーションを実行するアプリケーション実行ステ
ップと、データ構造の仕様をアプリケーションと分離可能な形式
でデータ構造を指定するデータ構造指定ステップと、第１のデータ構造仕様に従って構造化されたデータにア
クセス可能に記述されたアプリケーションに対して、該
第１のデータ構造仕様を変更した第２のデータ構造仕様
に従って構造化されたデータへのアクセスを許容するデ
ータ構造進化ステップと、第１のデータ構造仕様を変更した第２のデータ構造仕様
に従って構造化されたデータに対してアクセス可能に記
述されたアプリケーションに対して、第１のデータ構造
仕様に従って構造化されたデータへのアクセスを許容す
るデータ構造退化ステップと、を具備することを特徴と
する記憶媒体。