ObjectStoreの怖い噂

弊社内に、ObjectStore(Progress SoftwareのOODB製品)上に構築されたシステムの保守を担当しているチームがある。
ObjectStoreにはJavaオブジェクトをそのまま出し入れできるのだが、永続化クラスにプロパティが増えたりしたら既存のデータはどうなってしまうのか聞いたら、何と全件リストアしなくてはならないのだそうだ。
顧客クラスに「携帯メールアドレス」というデータ項目が１個増えたら、数ギガあるデータベースを作り直さなくてはならない...て、本気なのだろうか。
ObjectStoreのマニュアルをちゃんと読んだら簡単な移行手順がどっかに書いてあるのではないかと思ったが、もともとこのシステムを開発した会社が残したドキュメントには、これこれの手順で全件リストアする、とほんとに書いてある。ここはウチより数段開発力のある会社なので、アーキテクトの人がObjectStoreの機能を把握していないとは思えない。
データがプログラムの道連れでゴミになってしまうのなら、RDB以前への先祖返りではないの。

リレーショナルモデルを真に実装したRDBは、階層構造を持つデータを出し入れできる、という説

上記のシステムは、RDBでは階層のあるデータ構造が自然に表現できないということで、OODBを導入したのだそうだ。
だが、「データベース実践講義」によれば、リレーショナルモデルでも階層構造のあるデータを自然に表現できるのだそうだ。
以下はC.J.Dateの言い分。
第1正規形の条件は、全タプルの各属性が"atomic"な値を持つことだが、このatomicという概念は厳密に定義されていない。
Coddは「それ以上小さく分解できない」データがatomicであると言っているが、文字列型は文字に分解できるし、日付型は年月日時分秒に分解できる。
もし文字列を型として認めるのならば、配列(集合)は全て型ということになる。
集合が何でも型ならば、リレーションも型ということになる。つまり、リレーションの１属性の値が別のリレーションであってもよい。
というわけで、RDBはテーブルの入れ子構造を実現できるべきであり、「これこそ正しいリレーショナルシステムにほかならない。」とのこと。
DBMSの実装がものすごく大変そうだけど、そんなRDBが出てきたらアプリケーションの設計から実装までえらく生産性が上がりそうだ。受注ヘッダの１属性として受注明細の集合が格納されているとか、人間が自然に感じる形でデータを読み書きできる。