OODB - オブジェクト指向データベース

OODB - オブジェクト指向データベース (311ﾚｽ)
上下前次 1-新
通常表示 512ﾊﾞｲﾄ分割ﾚｽ栞

104: NAME IS NULL [age] 04/07/26 14:10 ID:???

>>95
> 　研究者の方ですか？
研究者ではないです。昔とあるDBMSの営業とかユーザサポートなどをしていたことがあります。製品比較したり
導入支援する必要上「そもそもなにか」を調べたりしたので、開発者よりは研究者に半歩近いところで書き込ん
でいるかもしれません。

OODB出始めは本当にアカデミック方面しか資料が無かったし。

でも書き込み内容から方式屋とか(2ch風なら)呆れたSEみたいに思われるかもしれないと思ったけど、研究者と
くるとは、、、

> 　えーっと、無理です。きっぱり無理です。遅くとも１０年前ほどから現実的にも論理的にも不可能です。
> 人間は既に文明のない世界では生きる能力を失っているのと同じ理屈です。

もちろん今なくしたら目茶苦茶になります。ですがシステムで扱っているデータは本来そうしたものだという話
です。

カード決済の集計をしているシステムを見ているとものすごい勢いで売上が上がっていますが、それはシステム
の中のプログラムの中で自然に発生しているものじゃないです。

企業間取引でも必要に応じてちゃんと判を押した請求書は作るし、入金は経理でチェックして消しこみ処理しま
す。

データはシステムの外で発生していて、最後はシステムの外に出て人間が判断するために使います。ものすごく
便利な手段があるからといって、目的と混同すべきではないです。

> お金は銀行ができる前から存在していていますが、いざとなれば銀行がこの世から無くなっても社会が成り立つでしょうか？

少なくとも銀行業界を維持するためにお金を流通させているわけではないと思います。

> 経済はお金ができる前から（物々交換など）存在していますが、いざとなればお金がこの世から無くなっても、、
> 水道は、電気は、車は、

水道管の耐久度を上げるために水の中に大量の防錆剤を入れるようなことはしないでしょう。
＃極少量だったら入ってるんだったかな?ここまでくるとたとえが適切かどうか自信が持てませんが。

> ちなみに、現在の金融市場ではコンピュータにより決済が行われており、実際に紙幣や硬貨のやりとりなんてありません。
> もしコンピュータが無くなれば、世界中の経済がたちどころに崩壊してしまいます。マネーサプライとGDPを比較するまでもありません。

実際の紙幣は使われず、数値だけになったとしても請求書・領収書はちゃんとあるし、伝票もちゃんとあります。
コンピュータの中だけが実体として残っていると思うのは、システムの外や人間を見てないからじゃないですか?

システム化によって伝票処理が数万倍便利になったとしてもGDPが数万倍になるわけじゃありません。IT化は人
間が行っている業務を支援するための手段で、目的じゃありません。
＃制御系の話はよく分からないんでパス。

> 　不勉強なのでObjectStoreは知らないのですが、ディスクに格納されたデータはどのように抽出とかするのでしょうか？
> ディスクと同じだけのメモリが必要なのでしょうか？ だったらある意味すごいです。

パンフレットレベルの知識ですが、プログラム実行時の仮想メモリアクセスでPage faultが起こったのをキャッ
チして、サーバのディスクからページを転送してくるらしいです。私はOS内部の仮想メモリとスワップを管理す
るレイヤに近い機能だと思います。この方式を取っているのはObjectStoreだけで、それ以外のOODBではオブジェ
クト単位で管理していたと思います。

相変わらず疑問なのは、「Cの変数は保存しようと思わなかったけれどC++の変数は保存したいのは何故?」とか
「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると認識していたんだろう?」というあたりです。

http://mevius.5ch.net/test/read.cgi/db/1057157392/104

107: NAME IS NULL [sage] 04/07/26 20:31 ID:???

>相変わらず疑問なのは、「Cの変数は保存しようと思わなかったけれどC++の変数は保存したいのは何故?」とか

C++は挫折しました。
Javaに置き換えて考えてみますと、言語自体の特徴でしょうね。
データがあって、それを操作するのがCとかのプログラミングでした。
Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。

>「Cの中にSQLを埋め込んでいた人は、何のためにどう実行されると認識していたんだろう?」というあたりです。

外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
esql/c でもpro*cでもいいですが、プリプロセッサです。

>プログラミングのためにそういうインタフェース/ラッパーを用意しようとい
>うのであれば賛成ですが、オブジェクトそのものを格納するのは反対です。

これはOODBの場合って話ですか？　なぜでしょう？
私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。
先ほどのObjectStoreのページフォルトが発生すれば自動的にってのも、それに合致した発想であると思います。

>Model Driven Architecture(だったかな?)。

JavaWorldの５月号に特集を見つけました。今度読んでみます。

>> ビジネスの世界ではコストより時間が優先されがちです。
>> 時間＝コストと考えれば、コストですね。
>
>すると話を元に戻すと、ある変更が起こった場合にオブジェクト指向ならば既
>存のものを修正するよりもスクラッチ&ビルドした方が開発が速くなる(場合が
>沢山出て来そう)ということでしょうか。

いえいえ。オブジェクト指向どうこうに関係なく違います。
例えば、
・一から作り直したら最適なものが作れる。ただし５ヶ月かかる。
・今のをむりやりにでも動くように修正すれば１ヶ月でできる。でも問題先送り。ぐっちゃぐちゃ。
この場合、４ヶ月の時間差（＝コスト）がありますが、システムとしては上の方が最適なわけですが、
下と比べてその差に４ヶ月分だけの価値（＝利益）があるかどうかって意味です。
もちろん、判断する人によってROIは違いますけどね。

http://mevius.5ch.net/test/read.cgi/db/1057157392/107

109: NAME IS NULL [] 04/07/27 00:40 ID:f4b3F8Gz

非常に面白いスレですね。OODB未経験ですが割り込ませてください。
（U◆CZtFsGiu0cさんお久しぶりです。以前ム板のCORBAスレでよく質問に応えていただきました。）

今のOODB製品の中で、最も初心者向け・・・というかユーザビリティが優れているものはどれなんでしょうか？

実は私は比較的小規模なシステムに対してならユーザにプロポーサルできる立場にあるので、
機会があればOODBをプロトタイプシステムとして実験的に導入してみたいと思っています。
（最終的にはCORBA/CCMまで絡ませたい）
なので実際にまず1つのOODB製品に目をつけて、それを利用したパイロットシステムを作成して
ユーザにデモを行いたいのですが、このようなデモの際に非常に重要となるポイントが、
「直感的で優れたユーザビリティを持っていることをユーザにアピールすること（ユーザインターフェイスを含む）」なのです。
（以前はEAI製品についてもこのようなデモを行っていたのですが、舶来製品の多くがその能力如何に関わらず、このあたりがネックでダメ出しをくらいました。）

ユーザを巻き込んで開発する現場では、開発フェーズと運用フェーズのそれぞれに対して優れたユーザビリティを提供していなければ、
たとえどんなに優秀なミドルウエアでも採用がためらわれてしまいます。
（MSのミドルウエア製品がなんだかんだいってシェアを伸ばしているのはこのあたりが優れているからでしょう）。
「構成管理」や「運用監視」といった管理運用担当向けのツールが揃っていて、
なおかつ開発者向けのユーティリティ（例えばSQL*PlusやAccessのような、格納されたデータを簡単に参照するためのツール）が
提供されていることは必須だと思います。
で、実際問題としてそのようなOODB製品というのはあるのでしょうか？
昔のDBマガジンの付属についていたような、ObjectStore for PSEやObjectivityの評価版では正直苦しくて、
「ちょっとユーザには見せられないよなぁ」というレベルです。
（ミドルウエア製品の完成度ってGUIツールの完成度に比例するような気がします）

http://mevius.5ch.net/test/read.cgi/db/1057157392/109

113: NAME IS NULL [age] 04/07/27 16:41 ID:???

>>107
> Javaはデータではなくオブジェクトを表現し、オブジェクトを扱うものだからです。

まだ良く分かりません。データだろうがオブジェクトだろうがシステム化の対
象は違わないし、保存する必要性も変わらないと思います。

> 　外にあるデータを取ってくるために、そのインターフェイスとしてSQLを利用していました。
> esql/c でもpro*cでもいいですが、プリプロセッサです。

開発環境とか、プログラミング規約みたいなものとしてしか認識されないということ?

> 　これはOODBの場合って話ですか？　なぜでしょう？
> 私はオブジェクトそのものを格納できるのであればそれが理想であると考えます。

いくつか考えられますが。

１：DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。
オブジェクト指向で設計した成果はどの程度流用可能になりそうでしょうか。
また、仕様変更・追加が起こった場合でも最初に作った設計をどの程度守れる
でしょうか。

最初に作った人はハッピーなんでしょうけど。

いわゆる昔ながらのレコード設計とか正規化とかが出てくる話の方が、アプリ
ケーションの設計よりも御破算になる可能性は低いと思います。

２：オブジェクト指向設計の成果はアプリケーション言語に依存している可能
性がある。もともとホスト言語との依存性が高くて拡張性に乏しくなる、とい
う反省から言語と独立してDBモデルを作るようになりました。Javaで作ったオ
ブジェクトをそのまま格納したとして、C、C++、VisualBasic、Perlなどから
アクセスする場合、どんな解決策が良いでしょうか？

システムの寿命の間、追加開発する場合の開発環境が、仕様が分かる前から決
まってしまっているというのは嫌過ぎます。開発環境を統一するとしても、そ
んな制限とは別次元のはずです。

３：基本的にオブジェクト指向技法はプログラミングを暗黙の想定にしている
と思うので、設計者はストックに当たる部分を慎重に決める意識はあまりない
と想像しています。これはおそらく文化の問題で、レコード設計よりもジャン
プテーブル設計に近い世界かな? 電源切ったらおしまい。

思いついた順に並べてるので整理し切れてないですが、とりあえずこの辺で。

> 先ほどのObjectStoreのページフォルトが発生すれば自動的にってのも、それに合致した発想であると思います。

このばあい、更にクライアントやサーバのOSにも制約を受けます。性能チュー
ニングのためにページサイズを変更することさえままならない。
コンパイラのバージョンまで制限されそうです。

＃実際の製品がここまで制約を受けるとは信じがたいので何かうまいことやっ
＃てるはずだとは思うんですが、使ったことのある人のコメントがあるとありがたい。

http://mevius.5ch.net/test/read.cgi/db/1057157392/113

115: U ◆CZtFsGiu0c  [sage] 04/07/27 19:23 ID:???

>>113
>１：DBサーバは複数のアプリケーションから利用されます。全く別のプロジェ
クトの人員が同じDBを使うかもしれない。ところがDBの中にはある特定の設計
に基づいた過去のデータが入っています。

確かにDBに入れたオブジェクトはアプリケーションに特化したものになり
がちです。ですので、再利用はかなり難しいと思ったほうがいいと思います。

>２：オブジェクト指向設計の成果はアプリケーション言語に依存している可能
性がある。

これも確かにその通りで、ObjectStoreでは格納した言語からしか取得も
できません。その意味ではOODBよりもXMLDBの方が今後成長する可能性は
高いと思います。

>>114
>CADが有力アプリケーションと出始めの頃から聞きますが、いまいちアプリケー
ションのイメージがつかめないんですよね。
CADソフトを使ってその成果をファイル単位で管理するのに比べて何が便利なんだろう。

一つには、今まで出てきたとおりオブジェクトをそのまま永続化できるのが
一つ。もう一つはキャッシュ間での更新通知機能により、複数クライアント
間で同一データを扱っている際に、更新を即時に反映できることです。
通信系システムで採用されている理由も同じでしょうね。
＃もう一つ共通点としては「データの再利用」や「アドホックな操作」が
＃不要なことも挙げられます

>買ってきた製品パッケージなら、どこかの設定で最大利用メモリ量を指定して
おけばうまいことやりくりしてくれると期待してしまうんですが、そういうの
は無いんでしょうか。

ObjectStoreでは環境変数でメモリの最大値を指定できますが、それを超える
とプログラムが異常終了します:-P

>この利用例のアーキテクチャはどうなっているでしょうか。

まず、ObjectStoreのキャッシュアーキテクチャはご存知でしょうか。

>個人的には
ObjectStoreはスタンドアロン組み込み用途に向いた特性を持っていると思う
ので、そうであれば合点がいくのですが。

すいません、つながりがよくわかりません。

http://mevius.5ch.net/test/read.cgi/db/1057157392/115

上下前次 1-新書関写板覧索設栞歴

あと 195 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.016s