Rails、Hibernate、EJB スキーママッピングあれこれ

久し振りの更新。普段、突発的にものを書きたくなる衝動をブログにぶつけていたのですが、最近はそれがTwitterに吸収されてしまっています。短い単発コメントより、まとまった文章がある方が本当は価値が高いんですけどね。今日はTwitterが重いので、ブログに戻ってきました。

閑話休題。

SIGMOD2008に参加してみて不思議だったのは、Schema Mappingの研究が想像以上に盛んだったこと。これは、データベースのスキーマ（テーブル構造情報）を、他のスキーマへと変換するときに使います。データベースの移行とか、アプリケーションに合わせて形を書き換えるとか。

でも、そもそもマッピングって、足し算が入るだけでも、不可逆変換なんですよね。1+2を合わせて、「3」というデータを作ったとき、この「3」というデータは、1+2の結果か、2+1の結果かわからなくなる。そうすると、マッピングに使える演算の種類は限られてきます。

SIGMOD2007のベストペーパー、Compiling Mappings to Bridge Applications and Databasesにあるように、テーブルデータ　-> オブジェクトというマッピングをし、オブジェクトの更新結果をテーブルデータに正しく反映させるといった、roundtrip制約を入れると、使えるマッピングの種類を限定せざるを得ません。Join演算なんてもってのほかです。

問題を、オブジェクト（Javaのクラスなど）とテーブルデータ(relational database)の構造の違い(impedance mismatch)の吸収に絞ると、すでに世間で実用化されている技術がいくつかあります。Ruby on Rails, EJB3.0 (Enterprise Java Beans), Hibernateなどがその代表でしょう。

それぞれの一長一短(pros and cons)

Rails: テーブルの列名に対応したメソッドを自動追加するので(Person.id, Person.name, ...などでアクセス)、簡単なスキーマ変更（カラムを増やす、など）なら、ソースコードの変更が不要。ただし、実行時に初めてわかるメソッドなので、コンパイラによる静的チェックの恩恵が受けられない。実際に、動かしてみるまでプログラムが正しく動くかどうかわかりません。

EJB3.0: Javaのクラス定義と、テーブルデータをAnnotationなどを駆使して対応させます。テーブル名、カラム名とクラス名、メソッド名が食い違う場合はAnnotationを使って細かい対応付けができるのが売り。Data Access Objectを通して、オブジェクトを更新、テーブルに反映させるという手順。ただし、１つのオブジェクト定義でも、文脈に応じて、別々のテーブルに格納したいことがあります。たとえば、Personクラスを、student, teacherテーブルへ。student（Personクラスに対応）の一部を、alumniテーブルに格納したい、などなど。クラス定義の中に対応するテーブル名やカラム名を含める設計だと、この目的には対応できません。ここはぜひ分離してほしいところ。（Railsも、クラスに対応するテーブル名は決め打ちです。プログラミングはとても簡単な反面、オブジェクトの使いまわしは難しい。一応、オブジェクトに対応するテーブル名は設定可能ですが）

Hibernate： 僕はこのtutorialを読むだけでがっかりしました。こちらにも解説書のサンプルがあります。Javaのクラスと、テーブルデータベースの違いを吸収するのに、XMLで書かれたマッピングファイルが必要なんです。EJB3.0も裏でHibernateを使っているようです。なんだ、なんだ？。これだと、クラスを書き換えたら、XMLも書き換える必要がある。そのXMLファイルをクラスファイルから自動生成できるのかもしれないけれど、Javaのリフレクションを使えばXMLをあらかじめ用意する必要なんてないはず。設定ファイルが多い（ある）という点で、Railsほどの簡潔さ、わくわく感はありません。


明示的であれ暗黙的であれ設定項目を把握するまで動作が理解できないスキーママッピングなら、技術としての重要性は低いように思う。Railsのようにマッピングを決め打ちできる状況は多いと感じるし、テーブル型データとオブジェクト間のimpedance mismatchがそれほどあるとも思えません。現に、Object-Relational Databaseというように、Reational databaseは、様々な形のオブジェクトを保存できるように成長しています。


データベースのデータを扱うのが、プログラム言語中であるなら、プログラム中で使うクラス定義（オブジェクト）がスキーマそのものです。オブジェクトをそのまま保存できれば事足ります。テーブル名、カラム名なんてプログラム中で気にする必要はないはず。それに加えて、オブジェクトをどのような位置（コンテキスト）に保存するかが選択できればよい。たとえば、2007年度のデータ、2008年度のデータなど、フォルダでファイルを管理するのと同じように、データを保存する位置を決める。この2点ができれば、データベースの機能としては十分なんじゃないかと思います。

コンテキストを表す能力が高いのはXMLだし、定型データを扱うのはRelational Databaseの得意技。データベースの研究者として、両者の融合をもう少し進めていきたいところです。

研究者インタビューを受けました

SIGMODに論文が採択されたこともあって、インタビューを受ける機会がありました。(電子情報通信学会 データ工学研究会のニュースレター)。

インタビューと編集はNTTサイバー研の鬼塚さんがしてくれたのですが、本当にお疲れ様です。普段SIGMOD Recordなどで研究者インタビューを読む分には気楽なのですが、いざ自分が受けてみたり、編集の様子などを見ると、裏では、相当な努力があることがわかりました。

鬼塚さんの努力の甲斐あって、今回が初回のニュースレターは、かなり読み応えのあるものになっています。喜連川先生のアドバイスには、研究者として大事なことがたくさん含まれてい ます。top confereceを目指すことは重要、でも、研究者としてできることは、それだけではない。

小杉さんのＰＣ(Programming Commitee)体験談でも、immediate rejectは本当にあっさりしているんだな、と。また、今回のSIGMODのPC ChairであるDennis Shashaが提示したという査読、採否の方針はとても参考になります：

1. 査読にあたってはそのペーパの良い部分を見つけるように心がけること。rejectする際は、技術的な誤りなどの正当な理由や、killer referencesを示すと共に、some words of encouragement を忘れないこと。
2. innovative ideaを重視し、短期間で修正可能なミスを主原因としてrejectしないこと
3. 既存のアルゴリズムのバリエーションで、ちょっと思いついた、程度のものは、大規模な性能改善がない限りあまり重視しないこと
4. 実験に関しては、
　i) 統計的に意味のある母数で実験がおこなわれていること
　ii) 可能な範囲で標準的なデータセットとクエリを用いていること
　iii) 更新とクエリシナリオがテストされていることが満足されていることを重視すること

それにしても投稿数が去年の3割増しとは。。。PCも大変だ。論文を投稿するときは、読みやすい論文にすることを心がけて、PCの負担を減らしてあげるようにしないといけないですね。また、自分が査読する側に回った際も、良い部分を見つけるようにして、研究コミュニティの良いサイクルを回していくことがとても大切。

結婚

友人の結婚式に参列しました。

自分以外の結婚式に参加するのは初めてでしたが、料理も美味しいし、それぞれの催しに新郎新婦の思いがこもっていて、本当にいい結婚式でした。

こちらがお祝いするのはもちろんなのだけど、それ以上に向こうから幸せをたくさんもらったように思います。結婚式って、こんなにいいものなんだと実感。妻を大事にする気持ちの大切さを再認識させられました。

前日まで、スピーチを考えて練習したり（本番は、インタビュー形式で、司会の人が助けてくれたので拍子抜けしましたが。。。）着ていくものを準備したり、子供がいるので、買い物に行く時間がなかなかとれなくて、かなりばたばたしていたけれど、間に合ってよかった。


披露宴では、スクエアの懐かしい曲！（Sweet Sorrow）に乗せて、新郎が自分で作成したという、写真のスライドショー。自分も一緒に移っているサークルのコンサートの時の写真を乗せてくれて昔を思い出せました。

彼自身もピアノを披露してくれました。いつの間に！と驚くとともに、何故か負けないぞ！という気分にもさせられたり。何を競ってるんだかわからないけれど(笑）環境が変わるにつれて、エレクトーンも昔のようには弾かなくなってしまっているので、再開するにはいい刺激になりました。

結婚式、自分ももう一度したいな！と思わされたけれど、一度だからこそ思いを注げるし、いいものになるんですよね。昔の友人にも再会して話も弾んだし、至福のひとときでした。

あなたの大切なファイルに、突然「さよなら」と言われないために

三浦しをんさんのブログを眺めていたところ、彼女の原稿ファイルが壊れてしまったという話がありました。小説家にはとっても痛い話でしょう。そんな悲劇を少しでも防ぐために、ファイルの変更履歴を管理するためのシステムSubversionについて、以前に僕が書いた簡単な使い方のページを紹介します。

http://www.xerial.org/trac/Xerial/wiki/Subversion

情報系学生向けの内容なので、英語で、しかもコマンド入力形式を前提に書いているので、一般のパソコン利用者には読んで理解するのは大変かと思うのですが、こういうものがあるんだよということをぜひ知ってもらいたいです。

Windowsなら、TortoiseSVNという、マウスクリックで使えるSubversionもあるので、こちらをインストールして使ってください。

簡単な概念の説明

• 適当な位置に、リポジトリ(repository)と呼ばれるものを作ります。これは、あなたのファイルとその変更履歴を保存するデータベースのようなものです。
• 普段の執筆作業、ファイルの編集等は、ワーキングコピー(working copy)と呼ばれる、リポジトリの中身のコピーに対して行います。ワーキングコピー内のファイルをいくら編集したり、削除しようと、リポジトリには影響を与えません。
• ワーキングコピーを作成するには、まず、チェックアウト(checkout)という操作を行い、リポジトリからあなたのファイルのコピーを取り出します。
  
• ワーキングコピー上のファイルの編集結果を、リポジトリに反映させてもいいと判断したら、コミット(commit)と呼ばれる操作を行い、ワーキングコピー上での編集内容を、リポジトリに送ります。
• ワーキングコピー上の新しいファイルは、自分でリポジトリに追加(add)する、と選択しない限り、リポジトリには送られません。
• リポジトリには、コミットする前と後のファイルの内容がすべて記録されています。従って、一ヶ月前の原稿を取り出したい、という要求にもこたえることができます。1回のコミットごとに、リビジョン(revision)の番号が更新されていきます。
  
• ファイルを元に戻したい、というときには、リポジトリから復元(revert)操作を行います。誤って消してしまったファイルや、修正結果などを元に（リポジトリに保存されている状態に）戻せます。
  
• 定期的にリポジトリのエクスポート(export)を行って、最新の状態のファイルのバックアップをDVDなどの外部メディアに保存しておくと良いでしょう。更新履歴を含めたリポジトリ全体のバックアップが必要なときは、svnadmin dumpコマンドを使えるように設定する必要があります（詳細は公式ページや、onlineのsubversion解説書で）。

（サーバーに設置するとき）

• リポジトリは、Webサーバー上に作成するといたるところで自分のファイルにアクセスできるようになるので、利便性が高まります（Apache + mod_dav_svnなど）。あるいは、sshログインできるサーバー上に、リポジトリを作っておくと設定要らずで簡単です（svn+ssh://(server address)/home/leo/svn/repository というようなURLでアクセスできる）。
• Webサーバーなんて設置できない、という人は、最近はUSBメモリが大容量化しているので、こちらにリポジトリを作成してもよいのかもしれません。ただ、盗難、紛失によってデータを失うリスクが高いので、あまりお勧めできません。
  
• 複数の人（自分一人の場合でも、自宅、会社のPCなど）のコミット後の更新結果を手元のワーキングコピーに反映させるには、更新(update)を実行します。自宅と会社で同じファイルを編集してしまった場合は、コミットや、更新を行ったときに警告が出されます。両者の変更を簡単に合成(G: merGed)できるときもありますが、そうでないときはC（Conflict）マークが出ます。その際は、手作業で更新がぶつかった箇所を編集して、conflict resolvedという操作を行わないと、そのファイルはコミットできなくなります。人の更新結果を使って、手元の更新結果を無視して上書き、なんてこともできます。

何箇所かのPCにワーキングコピーが残っていれば、いざリポジトリが入っているディスクが故障したときでも、ワーキングコピーから新しいリポジトリを作ればいいだけなので、完全ではないとは言え、ラフなバックアップ効果があります。

文章やプログラムを書くという作業は、もうSubversionがないと怖くてできません。でも、世の中の大半の人は、まだこの恩恵にあずかれていないのかと思うと、少し悲しくなってきます。リポジトリの置き場所、バージョン管理って何？という面で、やや敷居が高いのですが、 あなたの大切な「パートナー」のことですので、真剣に考えてあげてくださいね。

大学の若手研究者ができる４つのこと・実践編

情報関連の研究では、日本は欧米を中心としたコミュニティから取り残されています。このことは、ここ数年のTop Conference/Journalでの日本のpresence（存在感）をみるだけでもよくわかります。この状態を危惧して、tatemuraさんが「大学の若手研究者ができること」と題して以下の4つを提言しています。

（１）英語のレジュメを書いてみる（書かせてみる）
（２）日本語論文を書かない（書かせない）
（３）無駄な学会を退会する
（４）官僚との付き合いを減らす

「日本語論文を書かない」という点については、僕自身、既に6年実践しています。そもそも、東京大学 の情報科学科というところ（大学院ではComputer Scienceという名称）は、学部の卒業論文から英語で書かせる伝統があって、英語で論文を書くということは、研究をする上でのボトムラインという感覚が染み付いています。この意味では、「英語で書かせる」というのは、教育的にはいい方法だと思います。

東大生と言えど、皆が英語が流暢なわけでも、英文を書き慣れているわけでもないので、最初に出来上がってくる文章はひどいものですが、経験を積んでいくと、だんだんいい文章が書けるようになってくるようです。ここで苦労している時点で既に、英語圏で普通に研究をしている人たちに差をつけられているので、日本語で書く暇があったら、日頃から英語で書く練習をしないと、ますます差がついてしまいます。

tatemuraさんも言っていますが、日本人の頭脳や技術力が必ずしも劣っているとは、僕も思えません。（とある先生に同じ話をしたところ、向こうの研究者はもっと賢いんだよ、と言われましたが（汗））。それはともかく、新しい技術や、自ら開拓した研究分野を、「英語」で「わかりやすく」伝える技術を併せ持った人が、日本にどれだけいるのでしょうか？ という話です。SIGMOD, VLDBのようなデータベースのtop conferenceに通すためには、英語のnativeと言えども、数ヶ月を書けて論文を、個々のフレーズに至るまで吟味するそうです。ミーティングで文章を議論して、２時間でようやく1パラグラフ進んだという話も聞きます。僕としても、「日本語で書かない」を実践した、というよりはもっと単純な理由で、「日本語でまで論文を書く余裕がない」というのが本音です。

研究者として、一番面白くないことは、自分の仕事（論文）に対して何も反応がないことだと思っています。ブログを書く動機だったり、絵や音楽などの作品を作る情熱だって、何らかの反応を求めてるから生まれてくるものだと思います。ビジネスだったら、売れる、ということ。だから、たとえ論文が採録されたとしても、Reviewerの反応が素っ気なかったり、後続研究が出なかったら（つまり売れなかったら）がっかりするものです。（ブログに関しては、直接のコメント等がなくても、のちのち、いろいろなキーワードで検索されていることを知ると楽しいものですが）

日本語でわかりやすく研究を伝えるのも大事な仕事ですが、それはどう頑張っても日本の閉じたコミュニティでしか売れないことを覚悟しないといけません。読む側の立場から見ても、SIGMOD, VLDBの文献を追うだけでもかなりの労力を要するので、英語論文に決して引用できない日本語文献は、必然的に読まなくなっていきます。国際的に影響力のある人が、日本語で発表できているなら、世界の風が日本にも流れてきて良いのだと思いますが、現在のようにそのルートが閉ざされてくると、コミュニティは国内に閉じる一方なんだと思います。

ただ、研究者を目指す人にとって、日本における博士課程までの学生生活というのは必ずしも、経済的に恵まれたものではありません。比較的、財政的に豊かな東京大学ですら、博士課程の学生の授業料を全員免除するには至っていませんし、アルバイトをしながら、PhDや、職を得るために、通しやすい日本語で論文を書いている、という事情もあると思います。学生という理由だけで、保育園へ子供を入れる優先順位が他の人より下げられてしまうなど、社会全体として、世界最先端の研究者を育てる風潮がないのも確かだと思います。高校生までの教育問題は報道等で好き勝手に論じても、大学以降の、特に情報系の現在のようなpresenceの低い状態や、学生の待遇については、世間で議論されている様子はちっとも伺えません。

「無駄な学会を退会する」 は、まだ学会のPCを依頼されるような、一人前の研究者にはなっていないので、そういう身分になってから考えます。ただ、Fellowならまだしも、ただ の学会の会員というのには、どんな価値があるのかよくわからない、というのがあるので、メーリングリストを読む以上の会員にはなっていません。

「官僚との付き合いを減らす」というのも、まだ、どうコメントしていいかよくわからないところです。日本の劣勢を覆す土台となる学生の研究生活の改善のためには、社会的地位の低い学生として博士を取得する苦労を知っている人が、官僚となって働いている方が都合が良いと思うことが多々あるからです。むしろ、現状を鑑みる限り、もっと学者が参政しないといけないと感じています。

最後に、「英語のレジュメを書いてみる」という点。これが実践できていないことが、ここのところ心残りだったので、今日、自分のCurriculum Vitae (CV：履歴書)を書いてみました。海外の若手研究者と比べると寂しい限りですが（tatemuraさんの記事は、この寂しさを認識させたいという意図でしょう）、このCVを充実させ、常に世界に向けて情報を発信していくことを念頭に努力していきたいと思います。