もっとも、修士の頃ってむちゃくちゃ勉強したからな。その一環と言う感じ。Jim GrayのTransaction、DateのDatabase、Atomic Transaction、Nested Transaction とか。
データベースってのは三つの幻想の上に成り立つスキームでしかない。
http://tinyurl.com/cjrakx
[独立性] プログラムとデータは独立
[整合性] ある時刻を取ると、すべてのデータがちゃんとしている
[完全性] そのデータベースに関するどんな質問にも必ず答えられる
これは幻想ってよりは、まぁ、そういうものを達成しましょうという目標みたいなものだな。
これは完全性を持つ理論の一種なので、数学基礎論/記号論理学の人達が作った一階述語論理のサブセットを使って、そういうものを構築出来ます。それが、関係論理とか関係代数(両方は同等なのでどちらでも良い)というもの。関数のない述語論理みたいなものか。
でも、そこに導入されたIBMな構文は最低。当時のPL/Iに影響されたSQLは、読みづらい、わからない、勝手に拡張されるというものだね。DATALOGの方がかっこ良いし使いやすいと思うが、そういうものは広がりません。
もちろん幻想だし、関係論理は一階述語論理に比べれば極めて狭いし、と言うわけなので、このたりの制限を緩めないと実際には使い物になりません。
プログラムとデータは独立なので「プログラムを変更せずに、データベースとSQLを変更するだけで良い」というアプローチもありえます。うげげだが。表示はどうするんだよ。
で、その揺り返しで、Persistent Programming Language というのが考えられた時があった。普通のプログラムの中で使われるデータを持続的にしてやればデータベースなんて要らないじゃんってやつ。これもうまくいきませんでした。データの互換性はどうするんだよ? OODBも、まぁ、似たようなものだな。
今は、JDBCとかで、データベースはRDBにして、それをプログラム内のオブジェクトにマッピングするが主流か? もっとも自分では必要としないので使ったことないです。settter/getterってのは、O/Rマップに整合させるためのプログラム言語側からの一種の制約だと思う。オブジェクトの状態遷移のきっかけ(trigger)が欲しいだけ。でも、SQLとJavaと両方使わなければならないのは結局同じ。
自分ではデータは、Flat textなファイル上に持っていることが多い。XMLは、それにXeroxっぽい使いにくさを付加したものだな。
XMLのダメなところは本質的にキーがないところだと思う。汎用性を損なうけど、必ずキーがあると規定するべきだったと思う。Uniqueを要求するかどうかは微妙だけど。そうすれば、XMLデータベースも少しは使われるか?
No comments:
Post a Comment