OODB - オブジェクト指向データベース
>>212
オブジェクトの永続化は変数の保存とかファイルのセーブなどとは
違う水準の発想だと思うけど。
「オブジェクト」はコンピュータを使う前から現実に存在している
もので、オブジェクト指向設計はそれをコンピュータでどうやって
管理するか、という考えだし。:-)
>>213
>「オブジェクト」はコンピュータを使う前から現実に存在している
いやーそういう原理主義は今は流行ってないよ。
でもデータ中心主義者のいう「エンティティ」と
オブジェクト指向主義者のいう「オブジェクト」って
似たり寄ったりの概念だよね
>>213
コンピュータを使う前はオブジェクトをどのように扱っていたのか教えてもらえませんか。
私にはそうした意味の「オブジェクト」とは非常に抽象化された概念で、「○
○すること」「○○するもの」と呼べるもの全般を指しているように思えます。
それはDBMSを使った実装とか開発等とは全然別のレイヤの概念で、それに無理
矢理「オブジェクト」と同じ呼称を付けて一緒くたにしているんじゃないでしょ
うか。
「オブジェクトの永続化」と「変数の保存」がどのように違う水準で議論
・考察・活用されているのか教えてください。
#クレクレ君ですいませんが。
OODBって問い合わせ言語は何使うの?
SQLじゃないよね? sqlも限定的に使えるのもあったんじゃなかったかな。
cacheかな。何せ使った事がないもんですみません。 >>219
OQLってのもあるけど、普通のオブジェクトと同様関連をたどっていくのが基本。 ODBってJAVAのbeanをそのままDBに格納するのですか?
格納するときはいいけど、selectとかしたらどうなるの?
beanの型でデータが返ってくるのですか?
(だとしたら、joinとかしたらどうなるのだろう・・・
新規のbean型を動的に生成するのだろうか?) ODBとオブジェクト指向言語の関係が今ひとつわからない。
要するにオブジェクトを永続させたいのか。
データベースの主張するところはとどのつまりデータの独立だった。
ここのところはどうなるか。それで唐突に思い出したのだが、
IBMシステム38がサンノゼ研究所で1970年代に開発された時、
最大の課題は「停電」だった、と言う話。
このメモリー(プログラム)とデータベースを一体に見ようとした
システムでの課題はデータの永続性だったということ。 >このメモリー(プログラム)と → このメモリーと >>225
(偏見に満ちたレスです。)
ODBとOOPLを考えるときに、アーキテクチャ全体がどうなっているかとか、
システムがどういう風に稼動・運用・活用されるのかということを考えてはい
けません。
目の前のエディタに表示されている作成中プログラムのコードだけに着目しま
しょう。オブジェクト指向で楽しくプログラミングしているのにSQLとか変な
ものが混ざってきて嫌ですよね。
そこで全てを「オブジェクト」にしてしまえば解決してしまいます。
SQLなんてコンピュータの都合で産まれたもので、それに比べればオブジェク
トというこの世に昔から存在しているものを活用すれば、全てがうまくいきます。
「データの独立性が云々」なんて考える必要はありません。
だってそもそもやりたいことはプログラミングなんだし。プログラムのおまけ
のデータなんて、適当にディスクへ吐き出しとけばいいんです。
仕事はコンパイルまでで終わりだし、論文や文献の実証実験にもなって一石二鳥ですね。
#一応「皮肉」で書いたつもり。OODBの利点を熱く語る人がいないとネタになっちゃうなぁ。
>>227 素敵なレスです。皮肉でなく。でもここだけは納得できません。
>SQLなんてコンピュータの都合で産まれたもので
SQLは論理式(まがい)です。オブジェクトを認識できるものが
論理から超越していることはあり得ません。
あなたの文章はしっかりしていますし、十分に論理的です。 ミドルウエアの適用というのは多分にイマジネーションの世界だと思うんだけど、
やっぱり現時点では具体的に使えそうな業務というか適応分野があまり見当たらないよ。
(別部署のシステムでGemStone+Smalltalkというシステムが1つあるけど、必然性を感じない)
それこそかつてのJavlinのようなEJBキャッシュみたいなニッチなところ(業務そのものの
データではなく、極めて基盤的なところ)にしか入り込めないという印象。
逆にOODBならではの事例集とかがあれば、もっとイマジネーションも沸くんだけどね。
>>225 >>227 >>228 >>229
オブジェクト指向プログラミングはオブジェクトの性質を記述するもの。
SQLは集合の性質を記述するもの(内包的な定義)。 >>225 商用システムでオブジェクトという概念を最初に持ち出したのが
システム38ですね。良かれ悪しかれ興味深いマシンでした。 いろいろ異論はあろうが、ざっくりと「オブジェクト=データ+手続き」と定義する。
データについては、表現方法を妥当なレベルで共通にできる。
しかし手続きは、言語や処理系によってその表現は異なる。なかなか共通させることはできない。
「オブジェクトの表現形式」を標準化し、それをいろんな処理系からアクセスできるようにする作業が必要になる。
で、それは技術的には可能だ。
だが実際問題としてそこまでやる必要性が薄い。
単にオブジェクトデータベースを使うだけならいつでもできるが、
広い普及はまだまだ無理な状況にある。 BFS1.0やWinFSってRDBだよねぇ。OODBがFSになるのはいつの日か・・・ OODBなファイルシステムっていまいちイメージがつかめんが、
Newtonのsoupとか、BTRONみたいなものかな? >> 234
データはオブジェクトごとに異なりますが、手続きは変わりませんよね。
オブジェクトの状態を復元するために、手続きは必ずしも永続化されている必要はありません。
また、255でもかかれているように、DBMSのそもそもの目的がデータの独立性であるならば、
むしろ手続きは永続化対象外でであるべきかと思います。
データのみが永続化対象であっても、オブジェクト指向で表現できるデータ構造をリレーショナル
モデルに変換するひつようがないのであれば価値があると感じます。
RDBMSで現実的なシステムを組むために
ストアドとかトリガみたいな機能が必要になったことが、
データと手続きが不可分であることを表していると思うのだが
久々に書きこもう。
>>238
実装(プログラミング)のためにはそうした方が便利という面はあると思う。
だけど実装のために必要になったデータ(ループ変数とかフラグとか関数間受
け渡しための変数とか)と、業務で必要なデータ(顧客名とかIDとか単価とか)
は概念上別なものとして認識するのが自然だと思うけど。
OOな人は何故か「とにかくプログラム上は一緒なんだから」という考えのよう
な気がして不思議。
OOな人の目的ってやっぱりプログラミング?
>>239
よく趣旨がわからないけど、OODBだろうがなんだろうが、永続化すべきデータに
違いはない。ただその格納方法に違いがあるだけ。それからOOな人だからといって
OODBを使いたがるとは限らないよ。 >>240
ここでの文脈はOODBかRDBかではなくて、データと手続きはどのように不可分
なのかということだと思います。
で、私は「永続化すべきデータに違いはない」とまるっきり区別しない事に、
違和感を感じていると書いたつもりです。
(この引用の仕方はU ◆CZtFsGiu0cさんの意図とは違っているかもしれません)
あと、OOな人がOODBを使いたがるわけではないかもしれませんが、RDBへの不
満はいっぱい持っていると思います。しかし私はそこに未だ合理的な理由を見
つけられなくて、単に「俺の好きなプログラミングのことだけ考えたい」とい
うような主張にしか見えないのです。
このスレで納得の行く理由をいつか誰かが出してくれないかなと期待してるん
ですが。
>>241
>ここでの文脈はOODBかRDBかではなくて、データと手続きはどのように不可分
なのかということだと思います。
よくわからないな。プログラム上データと手続きが不可分だとしても、永続化
すべきデータには違いはないですよ。永続化するのはあくまでデータなんだから。
>あと、OOな人がOODBを使いたがるわけではないかもしれませんが、RDBへの不
満はいっぱい持っていると思います。
これは、「インピーダンス・ミスマッチ」の一言につきると思います。
設計したモデルをデータストアの都合で崩さなければならない、ということに
不満がありますね。
それから細かいことを言うと、データストアがOODBでない場合はカプセル化を
破るか永続化するデータを持つクラスが永続化の手段を知っている必要がある
ので、それはあまり歓迎できないと言うのはあります。
>しかし私はそこに未だ合理的な理由を見
つけられなくて、単に「俺の好きなプログラミングのことだけ考えたい」とい
うような主張にしか見えないのです。
合理的かどうかはわからないけど、自分がやりやすい方法でやりたいのに
壁があるからなんとかできないか、と考えるのは自然ではないですか? >>242
> よくわからないな。プログラム上データと手続きが不可分だとしても、永続化
> すべきデータには違いはないですよ。永続化するのはあくまでデータなんだから。
データの中で概念的に違っているものがあれば、一緒にしないで別々の手段が
有るのが理想じゃないですか?それぞれの活用方法も違っているんだろうし。
> 合理的かどうかはわからないけど、自分がやりやすい方法でやりたいのに
> 壁があるからなんとかできないか、と考えるのは自然ではないですか?
プログラミング以外に、保守・メンテナンスやそれに伴う出力や顧客との意思
疎通とかいろんな問題があるはずです。
「自分の仕事が開発して納品することだから、周りの皆がその都合に合わせて
欲しい」というような主張にしか聞こえてこないんですよ。
>>243
>データの中で概念的に違っているものがあれば、一緒にしないで別々の手段が
有るのが理想じゃないですか?それぞれの活用方法も違っているんだろうし。
うーん、よくわからないです。概念(ってなに?)が違えば別のものになるのは
当たり前だと思うけど、具体的にはどういうことですか?
>プログラミング以外に、保守・メンテナンスやそれに伴う出力や顧客との意思
疎通とかいろんな問題があるはずです。
「顧客との意思疎通」はともかく、保守・運用やアドホックなデータ検索に
関しては今のOODBはダメダメですよ。それに関する認識はここにもさんざん
書きました。だからこそ、ObjectCacheやCacheに期待するところがあるん
ですけどね。
>「自分の仕事が開発して納品することだから、周りの皆がその都合に合わせて
欲しい」というような主張にしか聞こえてこないんですよ。
もしかしてデータベースの保守をやっている方ですか? 逆にデータベース側の
ことしか考えてないってことないですか? プログラムの保守についてはどう
思ってますか? データベースはシステムの一部にしか過ぎないんですよ。
>>244
> うーん、よくわからないです。概念(ってなに?)が違えば別のものになるのは
> 当たり前だと思うけど、具体的にはどういうことですか?
>>239で書いたようなことです。
「データと手続き」の場合大抵区別せずに話が進むので、念を押してます。
DBにおける「データ独立性」の「データ」とはニュアンスが違うと思います。
> もしかしてデータベースの保守をやっている方ですか? 逆にデータベース側の
> ことしか考えてないってことないですか? プログラムの保守についてはどう
> 思ってますか? データベースはシステムの一部にしか過ぎないんですよ。
保守では有りませんが、DBMSの販売に昔かかわっていた者です。
DBはシステムの一部ですが要です。
以下の点でプログラムの都合よりもDBの都合を優先させるのが自然だと思います。
・1つのDBに複数のプログラムがアクセスする場合が非常に多いこと
・システムの稼動に従ってデータ資産が増えていくが、その構造は簡単には変えられないこと
・CPUの速度よりもディスクの速度の方が圧倒的に遅いこと
プログラムだってシステムの一部に過ぎません。しかし「『一部』同士だから
検討の優先順位は同等だ」ということにはならないでしょう。
(無論個別の事情によってはいろいろと程度が変わってくると思いますが)
以上の点はDBのモデルやアクセスインタフェースに関係なく当てはまる話だと
思います。
>>245
>「データと手続き」の場合大抵区別せずに話が進むので、念を押してます。
DBにおける「データ独立性」の「データ」とはニュアンスが違うと思います。
そういうことですか。実装上必要な揮発性のデータを永続化するなんて
ありえない、というか「データと手続きが不可分」と言う言葉を曲解してる
ように思います。
>DBはシステムの一部ですが要です。
以下の点でプログラムの都合よりもDBの都合を優先させるのが自然だと思います。
特に反対することはないんですが、やはり誤解されていると思います。
OOでやってもエンティティはフローズンスポットになるのでそんなに
変更は入りませんし、既存のシステムは当然考慮しますよ。
つかってはみたが・・・
なれればそうリレーショナルデータベースと別物ってかんじではないなぁ・・・
まぁ、ちびっとしかつかってないのでこれから使ってみて判断セにゃいけんのだが・・ OQLの話題ってここ?
なんかオレ様の知らないうちにオブジェクトDBシステム用の
クエリ言語が標準化されてますた(・へ・)
http://www.odmg.org/
日本語の情報元知ってるひといたらキボンヌ
この辺も
「LDP」
http://lambda.uta.edu/lambda-DB/manual/
「出世魚」
http://www.db.is.kyushu-u.ac.jp/fish/expl/summary.html
あとFastDB試してみたらなかなか使いやすかった。
でも誰も使ってない予感
で、複雑で大量の事象と空間をシミュレーションするのに
今現在はどの組み合わせのシステムがベストなの?
多種多様のドキュメントを管理するには何がベスト?
業務処理するには何がベスト? ObjectStoreは,かつてのOO指向のイメージからリアルタイムデータ処理へと変貌した。 たとえば「注文」オブジェクトがあるとする。
注文番号
注文先
商品
単価
個数
消費税額
みたいなオブジェクトだとして。RDBMS だと、注文先番号 や 商品番号で
マスタとリレーションするよね。
O/R マッピングだと、マスタとジョインした結果を格納する、ってことができて、
RDBMS におけるメリット(マスタに変更があった場合、オブジェクトにもその
変更が反映できる)を受けられる。
OODBMS の形で、オブジェクトをまるごと格納しちゃう場合、マスタデータに
変更があったらどうするんだろう? マスタデータを表すオブジェクトを更新するだけじゃないの?
注文オブジェクトと商品マスタオブジェクトはN:1の関連を持つ別のオブジェクト
ということは、注文オブジェクトの方には、商品マスタオブジェクトのキーを保持
するってこと?
注文番号
注文先キー
商品キー
単価
個数
消費税額
って感じ? これだと、オブジェクトとしていまいちきれいじゃない感じがするなぁ。 キーっつうか、マスタオブジェクトへのリファレンスだろ?保持するのは。 ごめん。いまいちイメージがわかないや。
具体的にいうとリファレンスって何を保持するの?
public class Order {
int OrderNo;
Comany OrderCompany;
Product OrderProduct;
BigDecimal UnitPrice;
int Quantity;
BigDecimal Tax;
}
ってのを当初考えてたんだけど、これじゃ駄目だよね? それがまさにOODBってことなんだと思ってたんですが。
使ったことねえものわがらん。 当初それで考えてたんだけど、たとえば Product.Name が変更された
とするよね、永続化されてる Order クラスには、それがわからないと
思うのですよ。
と思ったんだけど、永続化されるのはあくまで Product クラスの参照であって、
Product クラスの変更は自動的に Order クラスにも伝播するってことかな?
XML への永続化とかだと、そうはならないんで、すっかり誤解してました。 クラスという言葉はまぎらわしいからオブジェクトと言ってくれ。
実装によって細部は異なると思うけど基本的には
productオブジェクトもorderオブジェクトも、
どちらも永続化されていて、永続化されたDBの中で参照関係が
保持されていると考えるのが普通じゃないかと。
>>259
それはヤバイ。製品仕様が変更になって、商品名が変わったときに、
以前に受けた注文の商品名が変わってしまうと、商売上、会計上
無茶苦茶になる。
業務知識に依存で、参照を持つ方法も取れるし、オブジェクト自体を持つ
事も出来るし、必要な項目だけコピーする事も出来る。
どれを選ぶかは、業務次第。 db4oのアンケート答えたら本が当った、わーい。
実はまともに触ったことないけど、
届いたらじっくり読んで遊んでみることにするよ。
英語苦手だけど。 J○1なんて、変更多かったりいろんなベンダー絡んでくるWEB系噛んでくると当然だが、まったく使えない。
「どうやって直しゃいいーの?やりようねーよ。」って・・・hahaha
でもって塩漬け OQLを使える組み込み可能なOODBって何がある? >>268
すまん
Javaのやつを探していたのでスルーしてた db4oがOQL使えれば最高なんだがな・・・NQってなんだよorz
コンパイル時にチェックできてもポータビリティがないじゃないか db4o、色々実験してみて気に入った。
仕事でも趣味でも使ってる人います? >>272
趣味で弄ろうとしてて苦戦中。
Javaで書いてるんだけどオブジェクトをsaveしたりopenしたりする専用のDAOクラス作った方がいいのかな?
>>273
本格的なプログラムの場合はDAO作った方がいいよ。
海外だと弄ってる人多そうだけど、日本は少ないね。
たしかリコーと提携して何かやるとかって話があったけど、
どうなったんだろう。 >>274
中国が積極的みたいだけど日本はね…
リコーは開発案件で積極的に導入してるぐらいだと思うけど。
しかしよくエンタープライズで使う気になるよなぁ 日本は盛り上がらんね。
日本語の開発者向けフォーラムもさっぱりだし。
リコーはエンプラじゃなくて組み込みじゃないかな? >>276
そうそう、サンプルが少ないから未だにDAOからオブジェクト追加出来ない俺…orz
組み込みなんだ?
自社製品になら納得。
>>277
サンプルってpdf読んだ?pdf+あっちのフォーラムで解決出来るよ。
Dao作ってる人はQBE?NQ?SODA?どれベースにした?
ソートとか考えるとSODAしかないのかな・・・ って1ヶ月前が最終レスか・・・やっぱSODAに行き着いたら離れてくか 最近さっぱりいじってないけど、俺はNQ
でもSODA併用にすると思う
NQを完全に捨てた場合は、離れたくなる気持ちも解る…
実はQBEが一番好みなんだが、単純なクエリにしか使えない >>280
全部のエンジン対応のBaseクラス実装してみた。
・・・Update、Deleteがスマートになった位。
>実はQBEが一番好みなんだが、単純なクエリにしか使えない
QBEは完全におまけだね、用意した意味がわからないレベル。
NQ→SODAも怪しい所があるらしいし。
・・・やっぱりH2+O/Rでいいやw Google Chrome + Google Gears 大人気だなw
Object Store Personal Edition で時代を切り開こうとしてたJava厨涙目www ちと質問。
OODBならGBのファイル管理も余裕ですよ!と謳っているけど何で?
DVDから直抜きしたエロ動画コレクションをOODBで管理すると仮定して
神イグザンプルを教えてエロイ人!!! 1件のデータが非常に大きいとしても、件数が数千、数万ならOODBでも余裕じゃね?
RDBじゃ無理とか言ってなければ別に嘘じゃない。 O/RマッパーとかいうクソみたいなFWが流行っちゃってるから
とっととOODBをもっと広めろやアホども。 PHPで使えるSQLiteのような手軽なOODBない? 継承できればオブジェクト指向というのは違う。
メッセージを送ってメソッドを呼び出せないなら
オブジェクト指向型じゃない。 >>294
だからSQLiteのような手軽なOODBが無いかと言ってんの。
OK? realmはここでいうオブジェクトデータベースになる? https://goo.gl/q9Ml0S
これは嘘でしょ?本当だったら落ち込むわ。。 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
66CFHAV81O ☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が3分の2を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆ まだあったのか
あと2年でRDBはOODBに置き換わると30年前に聞いたが
かつての推奨者はどう総括してくれるのかね
KVSやNoSQLはにぎやかだけど