JP4168522B2

JP4168522B2 - アクティブ記憶装置とその記憶制御方法及びこれを用いた異種データ統合利用システム

Info

Publication number: JP4168522B2
Application number: JP07310799A
Authority: JP
Inventors: 格西澤; 衛杉江; 暢俊佐川; 宏明小田原; 茂和猪原; フレデリコマシエル; 直企渡辺; 亜紀富田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1999-03-18
Filing date: 1999-03-18
Publication date: 2008-10-22
Anticipated expiration: 2019-03-18
Also published as: US6519598B1; JP2000267907A

Description

【０００１】
【発明の属する技術分野】
本発明は、データ処理機能を内蔵した能動型記憶制御方法、特に、データ形式変換を内部で実行する記憶制御方法とこれを用いた能動型（アクティブ）記憶装置に関する。
【０００２】
【従来の技術】
計算機システムの普及に伴い、さまざまなデータがデジタル化され格納されるようになってきた。このようなデータを管理するためには、磁気ディスク、磁気テープ、ＭＯ、ＣＤ−ＲＯＭなどの多種多様なメディアが利用されているが、高速ランダムアクセスが可能で、読み書きが自由に行え、容量当たりの単価が安い磁気ディスクが現在のデータ記憶媒体の主流となっている。外部から与えられたデータを磁気ディスクに格納し、外部からの要求に応じて磁気ディスクからデータを読み出し、出力する磁気ディスク装置が広く使われている。
【０００３】
従来の磁気ディスク装置は、そのデータ入出力単位がブロックと呼ばれる物理的な単位であったため、磁気ディスク装置に格納したデータをクライアント側の計算機システム（以下、クライアント計算機）で利用するためには、該磁気ディスク装置をサーバ側の計算機システム（以下、サーバ計算機）に接続し、該サーバ計算機が磁気ディスク装置へのデータ入出力を管理する必要があった。以下、サーバ計算機が磁気ディスク装置を管理し、クライアント計算機からの要求を処理する形態をＳＡＤ（Ｓｅｒｖｅｒ−ＡｔｔａｃｈｅｄＤｉｓｋｓ）と呼ぶ。
【０００４】
ここで、ネットワークを介して各種のデータを利用する前記クライアント計算機が多数存在する環境を考える。このような環境は、ネットワーク技術の発展に伴って広く利用されているクライアント−サーバシステムに代表される各種システムでも前提とされている、現在最も一般的な環境である。このような環境におけるＳＡＤではサーバ計算機が処理のボトルネックとなり、システム全体のスケーラビリティがあがらないという問題が明らかになりつつある。例えばＧ．Ａ．Ｇｉｂｓｏｎ、Ｄ．Ｆ．Ｎａｇｌｅ、Ｋ．Ａｍｉｒｉ、Ｆ．Ｗ．Ｃｈａｎｇ、Ｈ．Ｇｏｂｉｏｆｆ、Ｅ．Ｒｉｅｄｅｌ、Ｄ．Ｒｏｃｈｂｅｒｇ、Ｊ．Ｚｅｌｅｎｋａ著、″ＦｉｌｅｓｙｓｔｅｍｓｆｏｒＮｅｔｗｏｒｋ−ＡｔｔａｃｈｅｄＳｅｃｕｒｅＤｉｓｋｓ″、ＴｅｃｈｎｉｃａｌＲｅｐｏｒｔＣＭＵ−ＣＳ−９７−１１８、Ｃａｒｎｅｇｉｅ−ＭｅｌｌｏｎＵｎｉｖｅｒｓｉｔｙ（以下、文献１）では、サーバ計算機上のファイルをＮＦＳ（ＮｅｔｗｏｒｋＦｉｌｅＳｙｓｔｅｍ）サービスを利用してクライアントがアクセスした場合、クライアントと磁気ディスク装置の組が４台以上となった場合には、ＳＡＤでは性能が頭打ちになってしまったという実験結果をあげている。この場合、サーバでの処理の大半は磁気ディスク装置へのＩ／Ｏ処理、サーバ計算機でのデータ変換処理、およびサーバ計算機とクライアント計算機の通信処理で占められる。
【０００５】
以上のような背景から、システム全体のスケーラビリティをあげるために、クライアント計算機がサーバ計算機を介さずに磁気ディスク装置にアクセスし、データを利用できるような方式が提案されている。例えば、文献１で説明されているＮＡＳＤ（Ｎｅｔｗｏｒｋ−ＡｔｔａｃｈｅｄＳｅｃｕｒｅＤｉｓｋｓ）はサーバ計算機からアクセス権を受け取ったクライアント計算機システムと磁気ディスク装置が論理的なオブジェクトという単位で直接データ転送を行うことにより、システム全体のスケーラビリティが向上するようにしている。
【０００６】
さらに、Ｅ．Ｒｉｅｄｅｌ、Ｇ．Ｇｉｂｓｏｎ、Ｃ．Ｆａｌｏｕｔｓｏｓ著、″ＡｃｔｉｖｅＳｔｏｒａｇｅＦｏｒＬａｒｇｅ−ＳｃａｌｅＤａｔａＭｉｎｉｎｇａｎｄＭｕｌｔｉｍｅｄｉａＡｐｐｌｉｃａｔｉｏｎｓ″、ＴｅｃｈｎｉｃａｌＲｅｐｏｒｔＣＭＵ−ＣＳ−９８−１１１、ＣａｒｎｅｇｉｅＭｅｌｌｏｎＵｎｉｖｅｒｓｉｔｙ（以下、文献２）で説明されているＡｃｔｉｖｅＤｉｓｋではこれに加えて、画像のエッジ切出しなど、従来はサーバで行っていた処理の一部を磁気ディスク装置側で行うことにより、システム全体のスケーラビリティを上げている。
【０００７】
【発明が解決しようとする課題】
磁気ディスク装置で一部の処理を行おうとする場合に、該処理を行う装置を磁気ディスク装置内に静的に組み込んでしまうと、利用する計算機資源、およびアプリケーション、現在のシステム負荷に応じて処理の単位、方法を切り替えることが困難となる。これらの処理を実現する際にハードウェアとしての処理を行うモジュールを組み込んでしまうと、処理毎に別の装置を作成する必要が出てくるために該装置は汎用とはなり得ず、装置の開発コストが高くなる。
【０００８】
前記サーバ計算機を介さずに前記クライアント計算機と直接データ転送を行う磁気ディスク装置はシステムのスケーラビリティを向上させるが、実際にクライアント計算機でデータを利用する場合には、クライアントの所望の形式にデータ形式を変換する処理が不可欠である。
【０００９】
従って本発明の第１の目的は、クライアント計算機の要求するデータ形式に効率よくデータを変換する機構を提供し、クライアント計算機およびネットワークの負荷を削減できるようなアクティブ記憶装置（例：磁気ディスク装置）を提供することである。
【００１０】
さらに、本発明の第２の目的は、前記データ変換機構を持つ磁気ディスク装置の価格性能比を向上させることである。
【００１１】
【課題を解決するための手段】
前記第１の目的を達成するため、本発明ではアクティブ記憶装置（例：磁気記憶装置）内部にクライアント計算機からの要求を受け付け解析するデータ要求解析部と、データ変換プログラム作成部と、データ変換部を設ける。
【００１２】
データ変換プログラム作成部は、データ要求解析部での解析結果に基づいて、データ変換プログラムを作成する。クライアント計算機の要求に応じたデータ変換プログラムを作成するために、前記データ変換プログラム作成部はまず、該磁気ディスク装置が保持するプログラムモジュール群の中から前記変換プログラムを作成するためのプログラムモジュールを検索する。
適切な前記プログラムモジュールが該磁気ディスク装置内に存在しない場合には、該データを要求した前記クライアント、もしくはプログラムモジュール群を管理する計算機（以下、プログラムモジュールサーバ）から前記プログラムモジュールを検索し、ネットワーク経由で該プログラムモジュールをダウンロードし、該プログラムモジュールを組み合わせて前記データ変換プログラムを作成する。
【００１３】
データ変換部は、前記データ変換プログラム作成部で作成された変換プログラムをダウンロードし、該プログラムを用いて磁気記憶媒体から読み出したデータを変換し、ネットワークインターフェースを介してクライアント計算機に形式変換後のデータを直接転送する。さらに、ネットワークの輻輳への対応のためデータ変換部とネットワークインタフェースの間にバッファ管理部１１２を設けて前記変換データをキャッシュし、必要に応じて再送処理を行う。クライアント計算機からの要求が、変換データの他の記憶装置へのコピーである場合には、変換データはネットワークインタフェースを介してコピー対象となる該記憶装置へ転送される。
【００１４】
さらに、前記第２の目的を達成するためには、アクティブ記憶装置（例：磁気ディスク装置）の汎用性を高める必要がある。つまり、各処理専用のハードウェアを製造する方法ではハードウェア１台あたりの価格が高くなってしまい、価格性能比を大きくできない。そこで、汎用性を高めるために前記サーバ計算機、もしくは前記クライアント計算機で必要なデータ変換処理をプログラムとしてソフトウェアで記述し、該データ変換プログラムを前記磁気ディスク装置上で実行するという方式を採用する。第１の目的を達成する手段でも説明したように、磁気ディスク装置上に適切なデータ変換プログラムが存在しない場合には、データ変換プログラムをプログラムモジュールの形でネットワーク経由でダウンロードし、前記データ変換プログラム作成部で該プログラムモジュールを組み合わせてデータ変換プログラムを作成する。
【００１５】
【発明の実施の形態】
図１は、本発明によるネットワーク直結型のアクティブ記憶装置（以下、磁気ディスク装置を例にして説明する）のブロック構成を示す。クライアント計算機１０１〜１０２、磁気ディスク装置１０８、データ変換プログラムサーバ１０４はネットワーク１０３に接続される。クライアント計算機１０１〜１０２、およびデータ変換プログラムサーバ１０４はＨｉｔａｃｈｉＦＬＯＲＡなどのパーソナルコンピュータ、Ｈｉｔａｃｈｉ３０５０クリエイティブワークステーションなどの任意のコンピュータ・システムでよく、ネットワークはイーサネット、光ファイバで接続されるローカルエリアネットワークでよい。磁気ディスク装置１０８は、磁気ディスク装置のネットワークへの接続と前記クライアント計算機、および前記データ変換プログラムサーバとの通信を保証するネットワークインタフェースと、クライアントからのデータ要求を解析するデータ要求解析部と、前記データ要求解析部での解析結果に基づいてデータ変換プログラムを作成するデータ変換プログラム作成部と、該データ変換プログラムをダウンロードし磁気ディスク媒体１０７に格納されているデータの変換を行うデータ変換部１１０と、データ変換部で変換されたデータをクライアントに転送する際に必要に応じて該変換データのキャッシングを行うためのキャッシュメモリを内蔵したバッファ管理部１１２と、該磁気ディスク装置に格納されているデータに関する情報を管理する格納データ管理部１１３と、前記磁気記憶媒体１０７にアクセスし、データを読み出すデータアクセス部１１１とを含む。磁気ディスク装置１０８における各処理部は、１ＣＰＵで実行できるが、Ｉ／Ｏ処理のみさらに別のＣＰＵで実行しても良い。
【００１６】
図１および図５および図６を用いて、本発明によるネットワーク直結型の磁気ディスク装置１０８の動作を説明する。クライアント計算機１０１が磁気ディスク装置１０８に格納されているデータを取得する場合（図５の処理５０１）、該クライアント計算機は要求するデータの名前、または型が既知でない場合（判定処理５０２でＮｏが選択された場合）には、前記磁気ディスク装置１０８に要求するデータの名前および型を問合せる（５０３）。該磁気ディスク装置の格納データ管理部１１３は、図８に示すデータプロパティ管理テーブル８０１および図９に示す物理マッピング管理テーブル９０１を管理する。該データプロパティ管理テーブルは、該磁気ディスクの格納しているデータのアクセスに必要な情報を提供する。関係データベースにおいては、前記クライアントの要求するデータの名前は表名８０２および列名８０４に相当し、データの型は列の型８０５に相当する。さらに、図８には、列に関する意味情報８０６を保持することとしている。該意味情報を用いると、該磁気ディスク装置のデータを他のデータと統合利用する際に、より高度なマッピングが行えデータ統合の支援となる。しかしながら、該意味情報は本発明を実施するにあたっては必須のものではない。
【００１７】
物理マッピング管理テーブルは、表名９０２、レコードＩＤ（９０３）、ブロック９０４、オフセット９０５の情報を管理し、論理的なデータ要求を物理的なデータ要求に変更し、データアクセス部７０３が、データが格納されている磁気記憶媒体７０４にアクセスする際に必要な情報を提供する。例えば、Ｅｍｐｌｏｙｅｅ表に対して９０６のような問合せが与えられ、条件に合致するレコードのＩＤが１００である場合には、物理マッピング管理テーブルを参照することにより、該レコードは前記磁気記憶媒体の第５３７ブロックのオフセット１２８００の位置にあることがわかり、磁気記憶媒体７０４から格納されたデータを取り出せる。
【００１８】
前記磁気ディスク装置へのデータの名前もしくは型の問合せ処理（５０３）の終了後、もしくは前記クライアント計算機は、要求するデータの名前、および型を既知の場合（判定処理５０２でＹｅｓが選択された場合）に、クライアントは磁気ディスク装置へのデータ要求を発行する。データ要求の例を図１０に示す。データ要求は、データ出力フォーマット１００１と、データ取得条件１００２と、データ形式変換１００３との３つの指定を含む。例えば、１番目のエントリ１００４は、出力されるデータのフォーマットはレコードで、該データの取得条件は１９６０年の１月１日以降に生まれたＨ社の従業員の全カラムで、データ形式変換は行わないことを表し、２番目のエントリ１００５は出力されるデータのフォーマットはカラム値で、該データの取得条件は名が”Ｉｔａｒｕ”のＨ社の従業員ＩＤであり、出力データ形式をＣｈａｒ（１５）に変換することを表し、３番目のエントリ１００６は出力されるデータのフォーマットは文書定義指定の無いＸＭＬ文書で、該データの取得条件は１９６０年の１月１日以降に生まれたＨ社の従業員の全カラム情報であり、出力データ形式の変換は行わないことを示し、４番目のエントリ１００７は出力されるデータのフォーマットは、文書定義がインターネット上のサイトｈｔｔｐ：／／ｈｉｔａｃｈｉ．ｃｏ．ｊｐ／ｅｍｐ．ｄｔｄにあるＤＴＤ（ＤｏｃｕｍｅｎｔＴｙｐｅＤｅｆｉｎｉｔｉｏｎ）で与えられるＸＭＬ文書であり、該データの取得条件は１９６０年の１月１日以降に生まれたＨ社の従業員のＩＤとＮａｍｅ（名前）であり、姓Ｆａｍ＿ｎａｍｅと名Ｆｉｒ＿Ｎａｍｅを、空白をはさんでつなげたものをＮａｍｅに変換することを表している。
【００１９】
クライアント計算機は前記データ形式要求を発行した後、磁気ディスク装置で形式変換されたデータを取得し（５０５）、データ取得処理を終了する（５０６）。
【００２０】
次に、磁気ディスク装置でのデータ変換処理（６０１）について説明する。磁気ディスク装置ではクライアント計算機からのデータ形式要求を受け付け（６０２）、該データ変換を行うためのプログラムが該磁気ディスク上に存在するかを判定する。該判定を行うため、前記データ変換プログラム作成部１０９内のプログラムモジュール管理部１１０１は、図１２に例を示す出力フォーマット変換モジュール管理テーブル１１０２と、図１３に例を示すデータ形式変換モジュール管理テーブル１１０３を管理し、出力フォーマットが指定された場合、前記出力フォーマット変換モジュール管理テーブルと、前記データ形式変換モジュール管理テーブル参照して（１１０７）必要となるデータ形式変換モジュールを、該データ変換プログラム作成部内のプログラムモジュール保存部１１０４が既に保持しているかどうかをチェックする（１１０８）。ここで該プログラムモジュール保存部は、該磁気ディスク装置内のメモリを利用して実現しても、磁気記憶媒体の一部を利用して実現しても差し支えない。
【００２１】
前記プログラムモジュール保存部が、必要となるデータ形式変換モジュールを既に保持している場合（判定処理６０３でＹｅｓが選択された場合）には、データ変換プログラム作成部内のプログラム合成部１１０５で該モジュールを用いてデータ変換プログラムを作成し、データの変換を行う（６０７）。ここで、データ変換プログラムとフォーマット変換モジュールおよびデータ形式変換モジュール（以下、該２つの変換モジュールをプログラムモジュールと呼ぶ）の関係について、図１２および図１３を用いて説明する。クライアント計算機からのデータ要求によって、データ出力フォーマットが指定されるが、該出力フォーマットにデータを変換するためには一般的に複数の処理を行う必要がある。例えば、エントリ１２０５に示すカラム値の切出しを行うためには、レコード選択処理とカラム切出し処理を行う必要がある。これらの各々の処理を行うプログラム単位をプログラムモジュールと呼ぶ。モジュールは出力するデータのフォーマットに応じて適切な組み合わせを選択することができる。例えば、エントリ１２０５および１２０６は共にカラム値の抽出であるが、エントリ１２０５はカラムがＶＡＲＣｈａｒ（可変長文字列）であるという前提で、カラム切出し用のプログラムモジュールとしてＰｒｏｊ＿Ｃｏｌｕｍｎ＿ＮｏＶａｒ（）を利用しているのに対し、エントリ１２０６ではカラムがＶＡＲＣｈａｒであるという前提でＰｒｏｊ＿Ｃｏｌｕｍｎ（）を利用している。一般的にＰｒｏｊ＿Ｃｏｌｕｍｎ＿ＮｏＶａｒ（）はＰｒｏｊ＿Ｃｏｌｕｍｎ（）よりも高速であるので、適切にプログラムモジュールを切り替えて変換プログラムを作成する効果は大きい。図１３はデータ形式変換モジュールを管理するデータ形式変換モジュール管理テーブルである。データ形式変換モジュールは、データの形式を変換するためのユーティリティ関数のように利用される。
【００２２】
再び図６に戻り、前記データ変換プログラム作成部が前記データ形式変換モジュールの一部または全部を保持していない場合（判定処理６０３でＮｏが選択された場合）には、前記プログラムモジュール管理部が、データ形式の変換要求を発行したクライアントが該データ変換プログラムモジュールを提供するかどうかをネットワークインタフェース１１０６経由で問合せ、該クライアントが該データ変換プログラムモジュールを提供する場合（判定処理６０４でＹｅｓが選択された場合）には、該提供されたプログラムモジュールをダウンロードし、前記プログラム合成部で変換プログラムを作成する。該クライアントが該データ変換プログラムモジュールを提供しない場合（判定処理６０４でＮｏが選択された場合）には、前記プログラムモジュール管理部はさらに、ネットワーク上のデータ変換プログラムサーバ１０４に前記プログラムモジュールが存在するかを問合せ、存在する場合（判定処理６０５でＹｅｓが選択された場合）には、該データ変換プログラムサーバから該プログラムモジュールをダウンロードして、前記プログラム合成部でデータ変換プログラムを作成し（６０６）、該作成されたプログラムを用いてデータ変換処理を行う（６０７）。該データ変換プログラムサーバ上にも前記プログラムモジュールが存在しない（判定処理６０５でＮｏが選択される）場合にはデータ変換プログラムを作成せずにデータ変換処理は行えない旨をクライアント計算機に通知する（６０９）。
【００２３】
プログラムモジュールの記述に関しては、好適な実施例としてＭａｒｙＣａｍｐｉｏｎｅ、ＫａｔｈｙＷａｌｒａｔｈ著、″ＴｈｅＪａｖａＴｕｔｏｒｉａｌ″、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ、ＩＳＢＮ０−２０１−６３４５４−６の４節（以下、文献３）で説明されているようなプログラミング言語を用いることにより、セキュリティーを保ち、しかもプラットフォーム非依存のプログラムモジュールを作成することができる。但し、磁気ディスク装置のアーキテクチャ依存のプログラムモジュールを準備し、磁気ディスク装置が必要なモジュールをダウンロードする形態でも差し支えない。
【００２４】
次に、磁気ディスク装置における、レコード選択処理とカラム切出し処理について説明する。
【００２５】
図３は、レコード選択処理とカラム切出し処理を、データベースマネージメントシステム（以下、ＤＢＭＳ）に適用した従来方式と、本発明の磁気ディスク装置に適用した例とを並べて示す。図３（Ａ）（従来方式）では、磁気ディスク装置３０８においてはデータアクセス部３０６でブロック単位のアクセスしか行えないため、入出力インタフェース３０５を介して、ＤＢＭＳ（３０１）には必要とするデータを含むブロック３２２が転送される（３０４）。
【００２６】
ＤＢＭＳのレコード選択、カラム切出し処理部３０３においてレコード選択処理およびカラム切出し処理（３１２）が施され、切出されたカラムがデータベース処理部３０２に転送される。一方、図３（Ｂ）の本発明では、磁気ディスク装置３２０中のデータ変換部３１６において、レコード選択処理とカラム切出し処理３１９が実行されるため、入出力インタフェース３２３を介してＤＢＭＳ（３１３）に転送されるのは切出されたカラム３２１となり、転送のためのネットワーク３１５の負荷を削減できる。本実施例では３１５はＤＢＭＳと磁気ディスク装置を接続する内部ネットワークを想定しているが、先に述べたように磁気ディスク装置がネットワーク直結型の形態を取る場合には３０４および３１５はＬＡＮあるいはインターネットとなる場合も考えられるため、ネットワーク負荷削減の効果はさらに大きくなる。さらに加えて、本発明の形態ではＤＢＭＳではレコード選択、カラム切出し処理を省略することができる。レコード選択およびカラム切出し処理は関係データベースシステムにおける基本的な処理であり、ほとんどの問合せ処理で実行する必要があるため、ＤＢＭＳの負荷削減に効果が大きい。なお、本実施例ではレコード選択処理とカラム切出し処理を磁気ディスク装置上で実行したが、本発明における磁気ディスク装置へのプログラムモジュールのダウンロードとデータ変換プログラムの作成、および実行方式を用いれば、ＤＢＭＳの負荷が軽い場合には、磁気ディスク装置上ではレコード選択処理のみを実行するとか、反対にＤＢＭＳの負荷が重い場合には、さらに集計処理も磁気ディスク装置上で行うなど、処理単位を柔軟に切り替え得る効果もある。
【００２７】
次に、文書定義指定が無い場合のＸＭＬ文書生成の実施例を図４により説明する。図４では前記ＤＢＭＳ（４０６）およびＷＥＢＳｅｒｖｅｒをはじめとするＸＭＬアプリケーション４１０がネットワーク４１４経由で磁気ディスク装置４０１に接続されている。まず、ＤＢＭＳが４０８に示すようなデータ要求を発行する場合を考える。データ出力フォーマットがカラム値であるため、図１２で説明したように、レコード選択処理４０３およびカラム切出し処理４０４用のフォーマット変換モジュールを適用し、データ取得要求の条件を満足する値（４０７）がネットワークを介してＤＢＭＳに返される（４０９）。これに対して、前記ＸＭＬアプリケーションが文書定義の指定無しでＸＭＬデータを要求すると、図１２で説明したようにレコード選択処理、カラム切出し処理を適用した後、データ取得条件を満たすカラム値に、表名、および列名でタグ付けしたカラム値を、さらに行ごとにタグ付けしたＸＭＬ文書（４１１）を作成し、ＸＭＬアプリケーションに返す（４１３）。本実施例では、Ｅｍｐｌｏｙｅｅ表の第１から第３のエントリはすべてデータ取得条件を満足しているため、表名＜Ｅｍｐｌｏｙｅｅ＞、行＜Ｒｏｗ＞、および列名でタグ付けされたＸＭＬ文書として出力される。
【００２８】
文書定義指定が有る場合のＸＭＬ文書生成の実現例を図１４を用いて説明する。ＤＢＭＳ側は図４の場合と同様であるので、ここでは省略する。前記ＸＭＬアプリケーションがＸＭＬ文書定義指定とデータ形式変換の指定を含むデータ要求１４１２を発行すると、磁気ディスク装置１４０１側では、文書定義指定が無い場合と同様の処理である、レコード選択１４０３、カラム切出し１４０４、ＸＭＬタグ付与１４０５に加えて、ＸＭＬタグマッピングおよびデータ形式変換１４１５をプログラムモジュールとして適用し、変換後のＸＭＬ文書１４１１を前記ＸＭＬアプリケーションに返す。本実施例では、条件は図４に示した場合と同一であるので、出力されるエントリは同一であるが、指定された文書定義に従うように変換されたＸＭＬ文書として出力が行われる。ここでは、格納されていた列名Ｆａｍ＿Ｎａｍｅ（姓）とＦｉｒ＿Ｎａｍｅ（名）を一つの空白をはさんで連結した新たな文字列をＮａｍｅ（名前）と定義しているため、例えば１番目のエントリは表名＜Ｅｍｐｌｏｙｅｅ＞、行＜Ｒｏｗ＞に続いて、＜Ｎａｍｅ＞タグに挟まれた”ＮｉｓｈｉｚａｗａＩｔａｒｕ”という文字列がＸＭＬ文書１４１１中に出現している。
【００２９】
最後に、図２に示した計算機接続型の本発明における磁気ディスク装置について説明する。図２に示す構成は、図１に示すネットワーク直結型の本発明における磁気ディスク装置と本質的に同一である。つまり、図１の構成におけるネットワークインタフェース１０６が、図２の構成においては計算機２０１との入出力インタフェース２０２に対応する。図２の構成においては、データ変換プログラムのダウンロード対象が、ネットワーク上のクライアント計算機１０１及びデータ変換プログラムサーバ１０４の代わりに計算機２０１となるだけであり、動作については図１で説明したネットワーク直結型と同一であるので、説明を省略する。さらに、本実施例の効果も、計算機と磁気ディスク装置間の転送負荷を削減できる、計算機の処理負荷を削減できるなど、ネットワーク直結型の場合と同様である。
【００３０】
なお、本実施例では、データ取得条件をＳＱＬ（ＳｔｒｕｃｔｕｒｅｄＱｕｅｒｙＬａｎｇｕａｇｅ）言語を用いて記述したが、他の言語を用いて記述しても差し支えない。
【００３１】
また、文書定義に関しても本実施例ではＤＴＤを用いたが、ＤＣＤ（ＤｏｃｕｍｅｎｔＣｏｎｔｅｎｔＤｅｓｃｒｉｐｔｉｏｎｓ）など他の記法でもよいことは自明で、さらに、本実施例では、磁気記憶媒体に格納されたデータが関係データベースのレコード形式の例を取り上げたが、該データが例えばＨＴＭＬなど既にタグ付けされた言語の場合には、本実施例におけるタグマッピング以降の処理を変換プログラムとすることで対応可能なことも自明である。
【００３２】
図１５は複数のクライアント計算機１５０１〜１５０２、本発明の磁気ディスク装置１５０５、１５０６、ストレージサーバ１５０７、およびデータ変換プログラムサーバ１５０４がネットワーク１５０３に接続された実施形態である。本構成において、クライアント計算機１５０１は磁気ディスク装置１５０５に対してデータを所望の形式に変換して、他の磁気ディスク装置１５０６、もしくはストレージサーバ１５０７に格納するというリクエストを発行することも可能であり、この場合には磁気ディスク装置１５０５からクライアント計算機１５０１にデータが直接転送されることはない。つまり、本発明はクライアント計算機からのリクエストに対して必ず磁気ディスク装置から該クライアント計算機に直接データ転送が行われる場合に限定されるわけではない。
【００３３】
本発明のアクティブ記憶装置を利用した異種データ統合システムを図１６，図１７を用いて説明する。図１６において，アクティブ記憶装置１６０１，１６０２はそれぞれ表型データ１６０８，ＸＭＬドキュメント１６０９を含む。今，あるユーザがクライアント計算機１６０５から，表現，構造が異なるこの２つのデータを統合利用しようとする場合を考える。ユーザはこの２つのデータを新しい構造を持つＮｅｗＤｏｃという名前のデータとして利用したいとすると，例えば１６０６のように指定することにより，１６０８中のＦｉｒ＿ＮａｍｅとＦａｍ＿Ｎａｍｅを結合し，１６０９のデータと合わせた形で新しいデータ１６０４を取得できる。
１６０６ではユーザが答えをすぐに取得したいという指定を行っているため，新データはユーザに直ちに送信される。
【００３４】
一方、図１７の例では，ユーザは新データを生成してストレージサーバＡ（１７０４）に格納せよという指定を行っている。この指定は，（１）変換対象のデータ量が多く変換に時間がかかる場合，（２）変換後のデータが一時的なものではなく，何度も参照するために保存しておきたい場合，（３）管理者が他のユーザのためによく利用されるデータを作成しておきたい場合などに有効である。
【００３５】
【発明の効果】
本発明によれば、以下の効果がある。
【００３６】
（１）クライアント計算機の要求に柔軟に対処し得る汎用的なアクティブ記憶装置（例：磁ディスク装置）を提供できる。
【００３７】
（２）データ変換をアクティブ記憶装置内で行うことにより、サーバ計算機の処理のボトルネックが解消でき、システム全体のスケーラビリティが向上する。
【００３８】
（３）データを利用する側のクライアント計算機でのデータ変換処理を省略でき、該クライアント計算機における処理効率が向上する。
【図面の簡単な説明】
【図１】本発明におけるネットワーク直結型の磁気ディスク装置の構成を示す図。
【図２】本発明における計算機接続型磁気ディスク装置の構成を示す図。
【図３】本発明における磁気ディスク装置と従来型の磁気ディスク装置での処理方式の比較を示す図。
【図４】本発明の実施例における、文書定義指定が無い場合のＸＭＬデータの生成方法を示す図。
【図５】本発明におけるクライアント計算機のデータ取得処理手順を示すフローチャート。
【図６】本発明における磁気ディスク装置でのデータ変換処理手順を示すフローチャート。
【図７】本発明の実施例における、格納データ管理部の構成を示す図。
【図８】本発明の実施例における、データプロパティ管理テーブルを示す図。
【図９】本発明の実施例における、物理マッピング管理テーブルを示す図。
【図１０】本発明の実施例における、クライアント計算機からのデータ要求を示す図。
【図１１】本発明における、データ変換プログラム作成部の構成を示す図。
【図１２】本発明の実施例における、出力フォーマット変換モジュール管理テーブルを示す図。
【図１３】本発明の実施例における、データ形式変換モジュール管理テーブルを示す図。
【図１４】本発明の実施例における、文書定義指定が有る場合のＸＭＬデータの生成方法を示す図。
【図１５】本発明の実施例における、ネットワーク直結型のアクティブ記憶装置のデータ変換とストレージサーバへの格納の応用例を示す図。
【図１６】本発明の実施例における、異種データ統合システムのシステム構成図。
【図１７】本発明の実施例における、他の異種データ統合システムのシステム構成図。
【符号の説明】
１０１，１０２，１５０１，１５０２、１６０５，１７０６…クライアント計算機，
１０７，２０７，３０７，３１８，４０１，７０４，１４０１…磁気記憶媒体，
１０３，４１４，１４１４，１５０３、１６０７，１７０５…ネットワーク，
１０４，１５０４…データ変換プログラムサーバ，
２０１…計算機，７０１…データプロパティ管理テーブル，７０２…物理マッピング管理テーブル，１１０２…出力フォーマット変換モジュール管理テーブル，
１１０３…データ形式変換モジュール管理テーブル，
１５０５，１５０６…磁気ディスク装置，
１５０７、１７０４…ストレージサーバ。

Claims

クライアント計算機が接続されたネットワークに接続する機能を備えた磁気ディスク装置の動作制御方法において、
当該磁気ディスク装置は、
データが記憶される記憶媒体と、
前記ネットワークに接続されるためのインタフェースと、
当該磁気ディスク装置の動作を制御するためのＣＰＵと、
前記クライアント計算機から受け付けたデータ要求を処理するために必要なプログラムを格納するためのメモリとを有し、
前記ＣＰＵは、
（１）前記インタフェースから受け付けた前記クライアント計算機のデータ要求を解析し、前記クライアント計算機から与えられた前記データの取得条件の指定、データ出力フォーマットの指定、ならびに必要な場合のデータ形式変換の指定を取得する処理と、
（２）当該データ取得条件に従って、前記データ要求により要求されたデータを前記記憶媒体から読み出す処理と、
（３）前記データ出力フォーマットの指定を満足し、また前記データ形式変換の指定があった場合に更にその指定を満足するのに必要なプログラムモジュールを前記メモリないし前記記憶媒体より検索してダウンロードする処理と、
（４）ダウンロードしたプログラムモジュールを用いて変換プログラムを作成し、実行することにより前記記憶媒体から読み出したデータを前記データ出力フォーマットの指定に沿って変換する処理と、
（５）当該変換されたデータを前記クライアント計算機に送信する処理と、
を実行することを特徴とする磁気ディスク装置の動作制御方法。
請求項１に記載の磁気ディスク装置の動作制御方法において、前記変換する処理は、前記記録媒体から読み出したデータに、ＸＭＬタグを付与してＸＭＬ言語に変換する処理であることを特徴とする磁気ディスク装置の動作制御方法。
請求項１に記載の磁気ディスク装置の動作制御方法において、前記検索の結果、前記変換プログラムを構成するプログラムモジュールが前記メモリないし前記記憶媒体に存在しないと判明した場合には、前記ＣＰＵは、前記ネットワーク上のプログラムサーバに該存在しないプログラムモジュールの有無を問い合わせ、有ればダウンロードして前記変換プログラムの生成に用いることを特徴とする磁気ディスク装置の制御方法。