理修棟生活

前回
情報源の動的選択を"データのみを利用した","メタデータのみを利用した","データ・メタデータ双方利用した"の3カテゴリに分けて考えた。ここで、メタデータは表名、属性名を指す。今までの考えてきた情報源の動的選択は前回の記事参照。

○打ち合わせ後
情報源の動的選択を上記3カテゴリに分けることは出来ない。問合せにはメタデータを利用し、そのデータに対して処理するので、データのみを利用することはできない。

・FISQLと我々のアプローチの違いは？
FISQL
目的: スキーマ間の異なりを吸収した統合利用
問合せ処理過程中にメタデータをデータへと変換し、そのデータを処理することが可能（Down operatorによるメタデータ→データ変換処理）。情報源の動的選択を対象としていないが、Down operatorとgeneralized Unionを用いることで、特定の情報源を選択することが可能である。しかし、全情報源に対して、down operatorを適応し、outer Unionをかけることになり、コスト大

・Our approach
一方、我々の枠組みではメタデータに対する処理を行うことができない。選択対象情報源名とその取り出しルールを外部DBに蓄積し、必要に応じてメタデータを取り出し、情報源を選択することで、処理コストを低く抑えている。データストリームをリアルタイムに処理するためには、処理コストを低く抑えることは重要だ。

ruleDBは選択したい情報源名や属性を保持したDB
controllerはトリガとなるストリームデータとruleDBに対する何らかの処理をする。出力は選択したい情報源に関する情報（メタデータ）を含むデータ
ASSIGNは入力データから選択する情報源にアクセスし、その情報源に含まれるデータを入力データを直積を取って出力する

前回考えた"データのみを利用した","メタデータのみを利用した","データ・メタデータ双方を利用した"全てのアプローチは、controllerまでの部分で、選択対象の情報源名や取得する属性（メタデータ）を算出することで、すべて取り扱うことができる。例えば、文字ストリーム中に出現する情報源を選択したい場合は、controllerが文字を解析し、選択対象のメタデータを取得し、ASSIGNに渡す（ルールDBは使わない）

情報源の動的選択を拡張する場合には、このフレームワークで取り扱えない状況を考える必要がある。

・今後
前回のintegrationゼミと今回の打ち合わせでは情報源の動的選択について再確認した。
分散環境での実装をないがしろにしているので、ここを重点的にしなければいけない。時間が無いので、頑張らないと

○おまけ（メキシコについて）
・メキシコ
公用語: スペイン語
人口: 1億380万人（2004年)
・モンテレー
気候: 平均最高気温24.4度, 平均最低気温13度, 降水量19.5mm,降水日数3.4日

・観光
a)「司教の丘」と「司教の館」 (Cerro del Obispado / Palacio del Obispado) - モンテレー市街が一望できる丘の上に立つ「司教の館」は米墨戦争でも激戦地となった。夜景が絶景である。
b)政府庁舎 (Palacio de Gobierno)
c)メキシコ史博物館

a,b,c全て会場の近くにあり
map

View Larger Map
モンテレーの空港とホテルはタクシーで片道20ドル。30分程度