RDBMSの生みの親Edger F. Codd博士、死去 92
ストーリー by Oliver
すべては表である 部門より
すべては表である 部門より
Anonymous Coward曰く、"The Mercury Newsの記事によると、現在のデータベースのメインストリームであるRDBMSの生みの親、Edger F.Codd博士が亡くなったそうだ。件の記事にもあるが、現在の社会のITシステムの多くはRDBMSを利用しており、その業績の偉大さは簡単には言葉にできないほどだろう。謹んでご冥福をお祈りする。"
RDBMSのRはCodd博士による1970年発表の論文A Relational Model of Data for Large Shared Data Banksから始まった。その概要はIBMのページにうまくまとめられている。
追悼 (スコア:3, 興味深い)
計算機の基礎を作った人たちが次々と世を去っていく。
あと、１００年もたてば、彼らはモーツアルトやベートーベン
のように学校の歴史で語られたり、計算機室の壁に写真を飾られ
たりするだろう。
直接講演を聴いたりする機会はなかったが、未来の伝説の偉人たち
と同じ時代にプログラマーであったことを誇りに思う。
100年後の計算機室の壁の写真 (スコア:2, おもしろおかしい)
「つーかヅラだろ？」
(そ、そうなのか？)
# まぁモーツァルトやベートーベンの時代はヅラが正装だったわけだが…
Re:100年後の計算機室の壁の写真 (スコア:1)
「夜中、計算機室のCodd博士の写真の目が動く」
といったものが出来上がると。
Re:100年後の計算機室の壁の写真 (スコア:1)
Re:100年後の計算機室の壁の写真 (スコア:1)
＃昨日帰る前は動いてたんです、本当なんです。
哀悼 (スコア:2, 参考になる)
下記のようなページがありました。参考まで：
・ちえの和Web：コンピュータ偉人伝 E.F.コッド [chienowa.co.jp]
・関係データベースの開拓者は創業者利益を享受したか [ulis.ac.jp]
Re:哀悼 (スコア:0)
もちろん、IBM DB2あたりの開発に関係しているとは思うが。
全てが表だと困っちゃう (スコア:1)
それでもRDBってものには複雑な(おいそれと賛美できない)気持ちを持たずにはいられないです俺。
なまじ表構造なもんだから、表と相性が良いとは限らないTreeだのNetworkだのの様々な構造を
取り得るデータ…最近の流行だとObjectですが…との間で、いわゆる
意味的インピーダンスミスマッチを、抱えさせられるんですよね。アプリ作ってると。これが辛い。
というわけでRDBもほどほどにしてOODBなりなんなりの時代になって欲しいなあ。
ええと。俺の理解が間違ってなければ(笑)、細かく言うと、
紹介された http://www-6.ibm.com/jp/gto/seibu/it/020311.html の中に書かれている
「規則9 データは論理的に独立している」を、積極的に人間の直感に従って崩す(笑)のが、
OODBへの第一歩かなという気がしています。
ほら。クラス分析/設計って、あいかわらずヒューリスティックな作業でしょ(笑)。
あの人間くささが良いわけでして。#本気か俺？
#制約条件はMethodで実現するし、保全はガベコレで本質的には実現可能だし。
#キーという概念も、「Objectを検索する」という概念が実装されてる系では別に珍しくないし。
というわけで今日も我々はO-Rマッピングで苦労させられるわけですが、
やっぱり1クラス1テーブル方式は(目先の処理効率は良いけど)弱点も多すぎますね。
http://rwiki.jin.gr.jp/cgi-bin/rw-cgi.rb?cmd=view&;name=PRb
みたいな方向性じゃないと長い目で見ればきついんじゃないかな。
Re:全てが表だと困っちゃう (スコア:2, すばらしい洞察)
八つ当たりですが
PL/SQL(オフトピ) (スコア:1)
個人的には、Oracle というより、PL/SQL が使えるかどうかで設計が全然違ってきちゃいますね。開発も楽になるし、メンテ時の作業効率も圧倒的に良いし。そういう意味では、情けないくらい完全に取り込まれちゃってます。
一旦 PL/SQL で組むと、他の RDBMS への移行が困難(というか、事実上無理)だしなぁ...
# しかし、僖奪院璽献?璽愁襪陵僅任砲肋，討覆い里任后▲肇曠
-- cooper
Re:PL/SQL(オフトピ) (スコア:1)
# しかし、パッケージカーソルの誘惑には勝てないのです、トホホ
でした。
-- cooper
Re:PL/SQL(オフトピ) (スコア:1)
という感じですよね。言語仕様そのものはあんまり格好良い言語ってわけでもないような気がする。
あれ？Oracleのサーバー側手続き言語を、PL/SQLからJava(かなんか)に交換しちゃうっていう話が、
有ったような気がしたけど、気のせいかな？
Javaのほうが言語としては数段便利だろうなとは思います。はい。
Re:PL/SQL(オフトピ) (スコア:1)
やっぱり、Java Stored Procedure だと、なにかこう奥歯に物が挟まったような気持ちになるんですよね、うまく表現できないんですけれど...
そこらへんについてちょっと書いてあるコラムはこちら：
http://otn.oracle.com/oramag/oracle/03-jan/o13java.html
-- cooper
Re:PL/SQL(オフトピ) (スコア:1)
うーん。なんだろうこれは？
面倒さは、どっちかってーと、周辺のツール(の整備度?)とか言語仕様とかが面倒さを醸し出しているような気がしました。
プログラムをサーバーに突っ込む手順がもっと楽になればだいぶ良い感じになるんじゃないかなあ？
Classのソースを全部自分で書かないとならないのだとしたらウザイから、
該当Methodの中身のコードだけ書いたら、その外枠は勝手に生成してくれる、というツールが
あればいいんだろうな、という感じかなと。
あと、Javaだとクドイというかなんというか、な面はあるかも知れません。
それこそRubyみたいな軽いノリの言語のほうが更に嬉しいかもと思う。
Re:全てが表だと困っちゃう (スコア:2, すばらしい洞察)
（中略）O-Rマッピングで苦労なさっているというご主張について、そもそもそのTreeだのNetworkだの
を関係モデルとして正規化（Normalize or Normalization）若しくは非正規化（一応断っておきますが、
「非正規化」は「非正規形」のまま放置することではなく、一旦正規化したデータモデルを、さまざまな
目的から、その正規を崩すことを意味しています。）が十分でないからではないでしょうか？という疑問を
抱きました。
また、OODBについて言及なさっていますが、果たしてOODBとOOPは相性が良いのでしょうか？
（私はいまだに良くわかりません。それほど経験をつんでいないもので...）
それから、規則9（の日本語訳）のあなたの理解は読みきれませんが、後続の記述から類推すると誤解
されているようです。規則9のココロは、従前のアプリケーションとデータの一体化状態から脱却しての
独立性という意味です。
Re:全てが表だと困っちゃう (スコア:1)
>を関係モデルとして正規化（Normalize or Normalization）
OO的なやりかただと、正規化とか非正規化という考え方を(普通は)しないんですよね。
OO勢がやってる分析や設計は、とどのつまりは「直感」です。
直感的にすっきり納得できるデータの並べ方ならOK、という感じです。
#Objectをいったん全部ばらしてRDBに格納するという前述のやりかたならば話は別ですが、
#あーゆーやりかたは主流じゃないようなのでここでは置いておきます。
#素朴に1クラス1テーブルにするか、それの亜種的なやりかた、あたりが主流だと思います。
そして、直感から離れるようなヤリカタは、たとえそれが正規化やそれ以外の何かであろうとも、
あんまり受け入れられてない、と思って良いと思います。
正規化とかの論理的に裏付けられたヤリカタに、あえて(かどうかはともかく)背を向けてるという印象です。
冷静に考えれば、おっかない話ではあるんですが(笑)。
俺としてはOOP(というかOOA/OOD)は、「児戯指向」だと思っています。
つまり幼稚園児でも判るような(笑)直感のみに従ったヤリカタを選択しがち。
これ、OOPの元々の考え方であるシミュレーションやメタファというものが、
元来そういうものである、という面が有るせいだと思います。
そういやSmalltalkは子供でも使える言語を目指したものでしたっけね。
＃とはいえ、だから悪いと思うことも出来ない俺。OOPって、馬鹿だから可愛い子みたいな感じなんですよ(^^;
まあ、高速化のためのノウハウも存在しますし、Objectであるがゆえに却って性能的に得をする面もある
(なんせObjectはそれ自体が何らかの情報のCacheみたいなもんですから、うまく使えば色々と…)んで、
悲観することもないかなーという気もしています。
というか、正規化とかの方向は、コッチ(笑)から見れば、
「やりすぎて人間様に理解しにくくなってしまった最適化」
みたいに見えちゃったりするんですよね。その捉え方が正しいかどうかは別として。
>OODBについて言及なさっていますが、果たしてOODBとOOPは相性が良いのでしょうか？
まともな奴なら、「そのまま」保存するように作られてるはずですから。
O-Rのようにマッピングをする必要が無いわけです。
>規則9のココロは、従前のアプリケーションとデータの一体化状態から脱却
ああ。そっちですか。
でもOO勢なら、そういう場合は「ドメイン領域のデータのクラス」という括り方をするだろうな。
ネジクギトンカチ的なクラスは「アプリに依存しないクラス」として作られて当然ですが、
ドメイン領域のデータでありながら同時にアプリ依存性を薄くした「直感的でない(笑)」クラスの作り方は、
OO勢はあんまり得意としていないんじゃないかな。
なんでもかんでもモデリング「して」しまうってゆー感じ。
後で変更したくなったらどうすんだ？とクビを傾げることが時折。
#数年越しの永続クラスの設計を(欠点が判っても)今更変更できなくて喘いでいるG7
（オフトピ）OOは直感か？ (スコア:1)
> OO勢がやってる分析や設計は、とどのつまりは「直感」です。
> 直感的にすっきり納得できるデータの並べ方ならOK、という感じです。
オブジェクトというのを最初に素人に説明するときは、直感とか「もの」とかいう話になりますが、「分析と設計」ってことになると、モジュール化でしょう。coupling & cohesion. （定着してる訳は知らないけど、多分モジュール結合度と凝集度。）一つのクラスで色々やらないで、別々に分ける。(hi cohesion)で、なるべく他人の内部構造に依存しない。(lo coupling)
でも、クラスに色々機能を持たせなくちゃならないことも多いので、そこで継承を使うか、別のクラスにするかみたいな話になって、んじゃ定石集めてパターン(design patterns)作りましょうって事になり、結局データベースで言うところの正規化とかみたいな話になるのでは？
なにが言いたいかっていうと、「直感」なんかじゃないぞって話。
Re:（オフトピ）OOは直感か？ (スコア:1)
>めてパターン(design patterns)作りましょうって事になり、結局データベースで言うところの正規化とかみたいな話になるのでは？
>なにが言いたいかっていうと、「直感」なんかじゃないぞって話。
いや、直感という言い方は確かにちょっとアレだったかもですが、
パターンは今度は「経験」の世界であるわけで、
それが機械的論理的に決まる世界ではないという点において、直感とは同類ですね。
つまり、自分ひとりのではないのだけど、大勢の人々の直感(笑)の集積物っす。
定石と論理的帰結とは同じではないわけで。
もしパターンが正規化と同じような位置付けのものだとしたら、
パターンは単純に「究極の答え」と「それを崩したもの」とに分かれていたんじゃないかな。
でも実際のデザパタは、「トレードオフ」の世界ですね。
2つのパターンの採用を比較検討するとき、しばしばどっちも究極の答えではない、という世界です。
#もちろん、論外に間違った選択もありえますが、そういうのはここでは数にいれる意味がないんでパス。
てゆーか、パターンの数がこんなに何十個もある(さらに、自作することも可能(笑)だし、
世間でも日々新たなパターンが作られてる(大袈裟?)わけだし)のを見れば、
「ああ、これはプリミティブでもなんでもないんだ」と思うモンなんじゃないかな。
#元素の数が多すぎるんで「原子は究極の単位ではないのでは？」と昔の科学者は思ったのだとか...
正規化って、パターンのような、直感だか伝統だか経験だか自然発生だかによって生まれたものじゃないですよね。
よだん：
正規化と同じくらいに究極の答えがもしOOPにもあるなら、
ある1つの分野におけるクラスライブラリは、そうそう何種類も作る余地が無かったのではないかな？
でも実際には色々なカタチのものがあるわけです。
それだけ恣意または偶然(笑)によって如何様にも出来る世界だということじゃないかなあ？
Re:全てが表だと困っちゃう (スコア:1)
だけど実際には、サポートやらネームバリューやらのせいで先にRDB（主にoracle）に決定するケースが多いんですよね。
OODBに特化した製品もあるのに推進するだけの(材料||件名)にならないという（汗
（oracleのOODBに関する動きだとoo4oをwrapするくらい？識者の意見を求む）
私の場合は、某Ｆ社のメインフレーム上での開発がメインだった時期があるのですが、当時のNDBの方が今のRDBよりもoopsにフィットする気がしますね。
---- 何ぃ！ザシャー
Re:全てが表だと困っちゃう (スコア:1)
選択肢が有ればいいんですがね(^^;。
Transactionがきちんと有って、しかも普通の奴らの上を行ってない(そのせいで選択してもらえる(笑))ような
DBとなると、やっぱり今はRDBが多いでしょうね。
同様にObject指向言語に拘る必要もないわけなんだが、いまどき使い物になって、しかも普通の(中略)
言語となると、OOP言語が多いかな。
ところでプログラムの性質といっても、Collection(OOP言語風に言えば)の能力で大勢が決するって面が有りますね(^^;
まあGreenspun's Tenth Rule of Programming [dreamhost.com]ということだそうで。
Re:RDBじゃないと恐ろしい (スコア:1)
>データ構造自体が表に出来ない場合はそこだけオンメモリにしたりして、
>主なところだけを表にするようにしないとダメ。
そんな無茶な…
オンメモリにしちゃえってのは、そこを永続化するために別の工夫が要るってことですか？
なんか、何もするなといわれてるような気がしてならないなあ。
>じゃなければ物理デバイス自体を改良しないと。
「物理」まで手を出す必要あるんですかね？
それって(DBのデータ塊を置く場所である)ファイルそのものが
RDBには向いているけど他のDBには向いていない、と
言ってるようなもんだと思いますが、そこまで言えるもんなんでしたっけ？
#むしろRDBのデータファイルが古典的な「ファイル」に(効率よく)収まることのほうが俺には不可思議なんですが…
>新生代のデータベースなりデータ構造なりというものは、モデルに対してこれまたある種の「制限」を課すことによって生まれるんじゃないかな。
それは勘弁願いたいな。ODBが先祖がえりに過ぎないロクでもないものだってのは確かに言えます(笑)が、
だからって逆に、進化の方向が常に制限で縛られて使いにくい方向にしか向かない、なんていう真っ暗な未来も
ちょっと想像したくないです。
せっかくプログラミングが昔に比べてこれだけ楽になったというのに、
それを永続化しようとしたとたんに地獄っすか？
それは人としてどうよ？という感じ。
余談：
そんなことするくらいなら、人はもっと違う世界に逃げようとするんじゃないかな。
例えばSmalltalkみたいに(笑)とりあえずメモリ上のObjectを全部そのままファイルに書くだけの世界。
それじゃ困るという声が生じそうですが、サーバーサイドなんかは特に、「ファイルに」落とす必要が
どれだけあるかってのを再考したほうがいいんじゃないかなと思います。
つまりshutdownするまではオンメモリでやっちゃえと。
そうすりゃついでにOOP言語でサーバーサイドロジックも素直に(ローコストで)書けますしね。
OSはワンレベルストアを提供してくれりゃそれでいいかも。ん？物理的って、このことですかね？
>なんでもありの OO からはおそらく何も生まれない。RDB もデータ構造を大胆にむりやり表にして相互に関係づけさせることで生まれたわけで、
OOは何でも有りってほど何でも有りではないですけどね(^^;。
＃「このくらいいいじゃん！」という感じかな(笑)
ただ、こないだも書いたけど、OOとRDBのマッピングについても、素朴な1クラス1テーブルとは
全然違うヤリカタにすると、それはそれで面白い世界が拓けてくるんじゃないかとも思うので。
余談：
あのPRbの説明を読むとむしろ、OOPも
「データ構造をむりやりObjectと参照(属性名)の連鎖にして相互に関連づけさせる(Binding)ことで生まれた」
などと言えるような気がします。
その軸は、いわゆるユーザーのモデリングの恣意性とは無縁の世界なんで。
>エンジニアが自分の直感でシステムのデザインを決めるような時代は絶対に来ないし来ても意味がない。
「来ない」というのが何を指しているのかちょっと不明なんですけど。
なにせ、今がまさにその「直感で決めてる」時代なのですから、もう「来ています」ですよ？(^^;
良し悪しはさておき。
おもて (スコア:0, おもしろおかしい)
s/Edger/Edgar/ (スコア:0)
Re:冥福 (スコア:1, フレームのもと)
死を悼む気持ちを、こんな言葉でしか表すことができないこともあるのでは。
ことば自体はごまかしかもしれないけど。
ptosh
Re:冥福 (スコア:2)
ただ、宗教(宗派)によっては「冥福を祈る」ことをしない(してはいけない)と聞いたことがあります。
とりあえず「冥福を祈る」でぐぐった [google.co.jp]結果からいくつか見てみると、
真宗 [kyoto-inet.or.jp]とかキリスト教 [home.ne.jp]とか浄土真宗 [houon.net]とか。
「この科学の時代に」 (スコア:1)
人類は誕生以来ずっと科学と共に歩んできたはずだし、別に最近になって神の存在が否定されたわけでもない。（もちろん証明されたこともない。）
一方、天体の運行や天候、生物の営みでさえ宗教の対象になりえたりするわけですが。
いずれにせよ、今がとりわけ「科学の時代」なんてことは全然ないと思う。
Re:「この科学の時代に」 (スコア:1)
科学は事象の説明の方法であり多くの宗教は人々の救済。
相容れないものでもないし、対象自体がちがうかな、と。、
kusanagi shin
Re:「この科学の時代に」 (スコア:1)
そうでもないと思います。
暦などは元々は宗教が作り出したものです。
宗教も自然の事象の説明を試みてきましたし、より良い生活をするために
気象すらもコントロールしようとしてきました。
その他にも例をあげると多数あります。
それに効果があったかは『神のみぞ知るところ』かもしれませんが
本質的には科学と同質のものでは無いでしょうか。
李 露星
Re:「この科学の時代に」 (スコア:0)
(宗教を持っている人の科学は、神を証ための手段のようだ)
すべての事は、科学で説明できるとか？
単純な式が正解とか？
科学は宗教でないとか？
ちなみに神がいないと考えるのも、無神教という宗教と考える。
ただ、理由もなく信じている。ように見える点が共通。
Re:冥福 (スコア:1, すばらしい洞察)
現代は科学万能の時代に思われるかもしれませんが、「祈る」という行為をおこなう人や、死後の世界の存在を信じている人は、現代でも、いっぱいいます。むしろ、そのような人のほうが大多数かもしれません。
ですので、「この科学の時代に」というのは誤りだと思います。
しかし、そうでない人もいます。「私は神の存在を信じていません」とか「死後の世界の存在は信じていません」とか。日本ではそういう人のほうが大多数ですので (いわゆる「先進国」では、一般にそういう傾向にあるんじゃないかと想像します)、今回の「冥福を祈る」という表現はたんなる慣用句として使われたのか、それとも本当に死後の世界の存在を信じていて書いた言葉なのかは判断がつきかねます。が、どちらにせよ「冗談」のつもりではなかったはずです。
というわけで、「冗談」と決めつけるのも誤り。
しかし、「冥福を祈る」ことが「冗談」にしか思えないような宗教観の持ち主がいる (#303307) のは確かなことです。それはとくに少数だとは思いませんし、また、少数であるから無視していいというのは誤りです。そういう人にとって、「冥福を祈る」という表現が万人に受け入れられるものであるとみんなが誤解するのは耐えられないことでしょうから、こういう場で、なんらかの形で異議を唱えるのは正当な権利だと思います。ただ、異議を唱えるのを通り越して、他の宗教を否定してかかるようだといけない。だから
「おれは死後の世界も冥土も信じてないから冥福なんておれにとってはちゃんちゃらおかしいし、祈るという行為も同様だ。おまえらが冥福を信じようが祈ろうが知ったこっちゃないが、全員が全員そんな人ばかりじゃないということくらいは知っておいてほしい」
というくらいの表現が妥当じゃないでしょうかね。今回のタレコミ文は「冥福を祈ります」なので、タレコミ者自身が個人的に冥福を祈っているだけで、読者に冥福を祈ることを要求しているわけではないですから。
Re:冥福 (スコア:0)
Re:冥福 (スコア:0)
壁のスイッチを押すと、部屋の照明が付く仕組みも知らないくせにね。
Re:冥福 (スコア:0, フレームのもと)
悪気があって言ってる言葉じゃないんだから、しょーもない茶々いれるのやめよーぜ。
Re:冥福 (スコア:0)
どっかの大国みたいになっちゃいますよ。
「冥福なんてない」という宗教の人や
もっと積極的に「冥福なんてものを祈られたら困る」
宗教の人なんかもいるので。
お亡くなりになられました。
哀悼の意を表します。
ならまず問題はないわけですよ。
Re:冥福 (スコア:1)
> 「冥福なんてない」という宗教の人や
> もっと積極的に「冥福なんてものを祈られたら困る」
> 宗教の人なんかもいるので。
そこまで知っているのなら、もう一歩何故踏み込まない？
> お亡くなりになられました。
> 哀悼の意を表します。
> ならまず問題はないわけですよ。
問題が無いとは言いきれないでしょう。例えば、「死とは人が神になることであって、悲しむべきことではない」と考える宗教が在っても全然不思議は無く(実際、そう言う宗教は在る)、そういう宗教観では「哀悼の意など表してもらっては困る」かもしれませんね(そこまで狭量な宗教は寡聞にして知らないけど)。
どんな言い回しをしようと、全く問題が無いわけは無い。世の中には自分の予想しないような考えを持っている人も居るかもしれないのだから。それを絶対に回避しようとすれば、何も言えなくなりますね。だから実際的には、程度問題で片付けるしかないわけです。
と、ここまでは一般論ですが、Codd博士は、そう言う冥福を祈るのを許さないような宗教観の持ち主だったのでしょうか？そうでないのなら、気の使いすぎですね。
Re:冥土は存在するか? (スコア:1)
それと同じで、哀悼の意を表すことを許さない宗教観もあるかもしれません。無神論者にもそう言う生死感を持つ人も居るかもしれませんね。冥福を祈ると怒る人がいるかもしれない、という心配をするなら、哀悼の意を表したって起こる人がいるかもしれない、という心配だって妥当です。
私の主張はそう言うものなのですが、私の意見のどの部分に対して反論なり賛同なりを示しているのか、#303533は少々意味不明です。#303533のACさんって、#303495のACさんと同一人物なの？その辺りから不明なので訳が解らんのですが。
ま、他人の死に対して哀悼に意を表したり、冥福を祈ったりすることは、一般常識として良くあることで、それに対して不寛容にもいきなり怒り出すような人は少ないでしょう。普通は怒り出す前に、自分の宗教感をを説明するなりして、訂正を求めるでしょう。そう言う人がいれば、そのとき改めて訂正すれば良いと思います。それが現実解というものでしょう。違いますか？
もし、相手が怒る可能性があることを一切してはいけないというのであれば、一切の発言を止めるべき、という結論に行きつかざるを得ませんよ。
Re:冥福 (スコア:0)
言葉狩りもいい加減にしてくれんかね。
「冥福なんてない」という宗教の人や
もっと積極的に「冥福なんてものを祈られたら困る」
宗教の人なんかもいるので。
具体的にはどこよ？
で、そんな宗教の信者が/.には居るわけ？
Re:リレーショナルってなに? (スコア:2, 参考になる)
・「田中さん」「山田さん」「鈴木さん」というデータの集合（ドメイン）
・「鼻が大きい」「鼻が赤い」というデータの集合（ドメイン）
があったとします。この二つの集合のすべての組み合わせを考えると（直積）、
・田中さん―鼻が大きい
・田中さん―鼻が赤い
・山田さん―鼻が大きい
・山田さん―鼻が赤い
・鈴木さん―鼻が大きい
・鈴木さん―鼻が赤い
が考えられますが、現実世界の田中さんたちを見てみると、上のすべての組み合わせが正しいわけではなくて、その部分集合の、
・田中さん―鼻が大きい（鼻は赤くない）
・山田さん―鼻が赤い（鼻は大きくない）
・鈴木さん―鼻が赤い（鼻は大きくない）
という結びつきしかなかったとします。この部分集合を現実世界の「関係」を表現するものであると、定義したんだと思います。
データベースの勉強をしていると、「関係」「関連」って言葉が色々なところで微妙に違うニュアンスで出てくるので、紛らわしいです。
# 表と表との結びつきを「リレーションシップ」と言う事が
# あることから、それをもってRDBの「R」だと言っている
# 参考書がありますね。あれってウソですよね？＞識者
Re:リレーショナルってなに? (スコア:1, 参考になる)
#上へ辿るとちょっとそれてきますが...
Re:参考文献 (スコア:2, 参考になる)
>（日英どちらでもかまいません。多分読めると思います。）
英語でいいんだったら、
JOE CELKO'S SQL FOR SMARTIES 2nd ed. ISBN 1558605762
とか。
著者は長年のDBコンサル経験をふまえ、DB言語SQLについて
数学的定義と、実用的データを使った実例の、両方をきっちり書いてる教科書です。
DBの本ってたいてい1NF, 2NF, BCNFまではきちんと書いてるけど、
3NF～5NFまで、なんでそんな正規化すると良い事あるのか、正規化前と正規化後を
具体的データを使って説明してある本は、私にはこの本以外見つからなかったので、買いました。
続編のJOE CELKO'S SQL PUZZLES & ANSWERS なんか、全問解いたら既にプロ、みたいな本。
ま、初心者向け最初の一冊としては、もっととっつきやすい本が他にあると思いますが。
Re:参考文献 (スコア:1)
やゆよ記念財団 [nifty.ne.jp]
Re:参考文献 (スコア:1)
という教科書です。これ一冊でおおまかに理解はできるかと思います。
読んだあとは、Postgresなんかをいじってみると面白いです。こっちは翔泳社
発行"PostgreSQLによるLinuxデータベース構築"なんかが参考になるかと
思います。両方買っても5千円ほど。
Re:参考文献 (スコア:1)
あと"What DB DBMS relational"をキーワードにgoogle
で検索かけると"What is a DBMS"というPDFが見つかりました。
http://www.cis.gsu.edu/~shong/teaching/cis814/slides/intro1.pdf
ちゃんとは読んでいないですが、DBMS全般の説明としてよさそうです。
Re:とらわれちゃうとねぇ (スコア:1)
設計はいやですけど個人レベルでもSQL叩いて手軽にデータをい
じれるようになったのでとても重宝します。
大きなシステムで重宝するのもありますけど、手軽にデータと
ロジックを分離する（か、その前提）ツールとして使ってるよ
うな気がします。
taka4
Re:とらわれちゃうとねぇ (スコア:1)
>設計はいやですけど個人レベルでもSQL叩いて手軽にデータをい
>じれるようになったのでとても重宝します。
昔、Niftyで(笑)、
SQLを使えば、 DBをアドホックにいじれるし、言語として難しくない(比較対象はC/C++など)から
ぜんぜんプログラマじゃない人でも手を出せるので、よってRDBは大変便利なDBシステムなのだ、
とかいう議論を展開した人がいました。
その時は俺も旨い反論が思いつかなかった(その頃からRDBには違和感を感じていたので
反論したかったんですが)のですが…
それから幾らかして、C++やjavaみたいな言語とは一味違う言語の世界が、
Object指向のほうにも存在する、ということを知りました。
つまり反論する(笑)ためのネタが身についたわけです。
何の事はない、「扱い易い言語」ならば、いいんですよね。
それがRDBを対象としたSQL言語でも、OOPを対象としたSmalltalkやRuby(笑)でも、
本質的には同じなんだろうなと。
というわけで、例えば「個人レベルでRuby叩いて手軽にプログラム」という世界も、悪くないと思っています。
扱い易く、動的で、さらりと短く書ける言語(最近ではLightWeight言語ってんでしたっけ?)なら、
そういうやりかたを採れるのが期待できそう。
さらに、(なんらかのOODBと接続して)Rubyで永続オブジェクトを叩けば、それもんの人(???)も幸せになるはずです。
# WordClass.search("Filename like '*123.doc'").each{|file| file.delete } なんて書けると結構幸せなのでG7
Re:とらわれちゃうとねぇ (スコア:1)
>それがRDBを対象としたSQL言語でも、OOPを対象としたSmalltalkやRuby(笑)でも、
>本質的には同じなんだろうなと。
スケーラビリティって言うんでしょうか。扱うデータ量で、OOPとDBでは雲泥の差が出ます。
データ数が百万超えたらDBなしで生きていけません。OOPは、扱えるデータ数上限が百万でしょうが、
DBにとってはデータ数百万なんてカスみたいなもんです。
ほら、例えばデータ数が高々千だったら、プログラミングのプの字も知らないおじさん、おねーさんが
Excelでしこしこ「情報処理」できちゃうじゃないですか。
定型データが1000以上あるからこそ、(かつ、それなりのレスポンスが求められているからこそ)
プログラミングする価値があるわけで。
つまり、Excel < OOP < DB って感じですね。
Re:とらわれちゃうとねぇ (スコア:1)
あのー？
OOPをそのままスケールするために(モデル変換も大きなコストも無くそのまま永続化できる仕組みがあれば
スケールするための助けになるだろうと考えて)、RDBならぬODBが(メジャーになって)欲しいぞ、
という感じですので、OOPとDBとを比較されても困ります。
もしかしてs/DB/RDB/gですか？
だったら1つの主張として理解は出来ます(ので以下そういう仮定で書きます：それ以外の場合は知りません)が。
# DBといったらRDBしか思いつかない人が目の前にいたらムカツクのでG7
# DBといったらOracleしか思いつかない人と、そう違わないんだよな…
>定型データが1000以上あるからこそ、(かつ、それなりのレスポンスが求められているからこそ)
>プログラミングする価値があるわけで。
うーむ。Excel(表計算)の限界は、表ってものは構造化がされていないせい、ですよね。
で、同じような質的な決定的違いが、RDBとOOPの間に、何か有るんでしょうか？
やはり児戯指向(笑)である点を弱点だと見なすべきでしょうかね？
# 同一性という概念は、(100%俺の想像ですが(笑))算数習ってない人でも、理解できると思うんです。
# それを中心に据えたOOPは、良くも悪くも児戯指向なんだと思います。
# で、問題はおそらく、同一性という概念がDBに対してどれだけ足引っ張りになってしまうか？という点なんじゃないかと。
# たくさん引っ張るのか、少しだけなのか、が。
# まあ確かに、DBに限らず一般に「永続化」は、同一性との相性が悪いことが既に知られてはいます。DB空間に複製を取った瞬間に、同一性が崩れるわけで。
## 参照の解決が厄介なのも、この同一性の問題が原因ですし。
あと、レスポンスについては、Intel様(笑)が速度をたたき出すおかげで、
一昔前には「プロが(アセンブラだのCだので)コーディングしないと」使い物にならなかった場面でも
今やScript言語とかでスカスカ書けて実用になるわけでして、たぶん別問題じゃないかなと。
Re:とらわれちゃうとねぇ (スコア:1)
世界中の*123.docが消滅するとか・・
冗談はおいといて、OODBというのをあまり知らないのですが、その
コードは例えばファイルシステムをRDBで構成したとして、それを
ラッピングしたFileSystemClass（内部でSQLを叩いてデータを返す）
を用意して、
# FileSystemClass.search("*123.doc").each{|file| file.delete }
なんてやってみるのと何か違うでしょうか？
むしろこの方がOO的な気がしますが・・・これなら実装がRDBでも他
のファイルシステムでもいいですが。
個人的にはSQLはデータを取り出すまでが仕事で、その出力を
そのまま表示して終わりみたいな使い方はしないのですが、
SQLを「叩く側の言語」はRubyはじめOOな言語は重宝すると思
います。
取り出したデータのセットがオブジェクトになってくれればい
いわけで。そういうクラスがあればいいわけですから。
OODBってそういうのをDB自身が装備したものでしょうか？
（・・・自分で調べろって）
taka4
Re:とらわれちゃうとねぇ (スコア:1)
どーでもいいですが、せっかくFileSystemという概念を持ち込むならば、
FileSystemClassじゃなくtheFileSystemという FileSystemクラスのInstanceであるほうが、嬉しいような気がしてます。
FileSystemはFileSystemItemのコンテナであり、FileSystemItemのサブクラスにはFileやDirやSymLinkがある…と。
さて。
>なんてやってみるのと何か違うでしょうか？
>むしろこの方がOO的な気がしますが・・・これなら実装がRDBでも他のファイルシステムでもいいですが。
あはは。ご指摘の通りで、実はそう違いません(^^;
ただし、見た目はです。中はぐちゃぐちゃしたコーディングをしないとなりませんし、
ラッパーの生成を自動化したり実行時解決するようにしたとしても、効率の悪さの問題は残ります。
たとえばRDBは、ツリーというか数珠繋ぎというかのデータ(構造?)を扱うのが苦手(コストが高くつく)ですが、
だからってアプリが数珠繋ぎ構造データ(の永続化)を放棄するのは本末転倒なので、
遅いけど我慢して使う羽目になります。
足回りも含めて交換したくなるってのは、そういう事情があるから。
# O-Rマッピング自動化クラスをJavaで書いて疲れたんでG7
あと、以下はマッピングをどうやるかによって違ってくる話です(が主流なマッピングのやりかただと抱えてしまう問題です)が、
「関連」をどう保存しようか？という問題が残ります。
関連ってのは、RDB用語のほうじゃなく、OO用語の「オブジェクト同士の繋がり」のほうの話です。
これをどう扱うか？っていう問題。
ここでOOとRの根本的な差が効いてきます。
全てのケースを円満解決して処理効率も良いような決定版的マッピング技術てのは、無いっぽい。
仕方ないんで毎回毎回逃げを打ちます。
ObjectIDを持たせてそれをポインタ代わりに使う、ってのが一番楽そうですが、
「違うクラス(=違うテーブル)でもUniqなID」を生成したり唯一性チェックしたりするのは
(それが出来ないと、多態をサポートできませんから、使い物にならん。)
それなりの仕掛が要りますし、その仕掛自体の処理コストも馬鹿にならない。
それにDBファイルのサイズ効率を気にする客から「IDみたいな余計なフィールド持たせるなよ」と怒られがちだし。
# 自作マッピングでは結構逃げたのでG7
# 「参照先のObjectはどのタイミングでメモリにロードするか」とか、結構悩ましい問題が多いんですよー(T_T)
## HollowObjectを導入しなかった時点で敗北とも言うが(笑)。
もともとOOにとってはObjectIDは暗黙のうちに存在する(他の属性がなんぼ同じでも、同一性と同値性は別ものだと捉える)
のが王道ですが、一方RDBは、(レコードとかの)同一性と同値性をいかに区別しないか(笑)が味噌なんだと思います。
だから select distinct みたいな考え方が生じる。モデル違いすぎ。
余談：
UMLの関連は、普通のOOP言語の関連とも違って、むしろRDBのほうに通じるものがあるように思います。
UMLを考えた人たちが一体何を考えていたのか、俺には不思議でなりません。
OOP開発を支援するためにUMLは作られたんじゃないのか??
余談2：
そういやRDBのほうも、レコードの同一性という情報が結局欲しくなって、それを補ってる製品が結構ありますよね。
行IDってものがある製品、ありますよね。
やっぱり(OOPには最初からある)IDという概念は必要なんだな！と感動した(笑)ものでした。
>そのまま表示して終わりみたいな使い方はしないのですが、
>SQLを「叩く側の言語」はRubyはじめOOな言語は重宝すると思います。
「叩く側」と言ってしまうと、(あなたの意図はさておき世間全般(?)から見れば)二通りの意味に取れると思います。
つまり、上記のようなO-Rマッピングをしたいという話と、
もう一つは、単にRDBアクセス機能を提供する仕組みをOOPなクラスライブラリとして実装すると
すっきりしますよ、という世界の話。
後者はJDBCやDelphiのDBコンポの話ですね。オブジェクトを「使って」RDBアクセスをすると、
使わずにアクセスするよりも数段楽に、アプリ書けますです。アクセスの単位や検索結果の保持が
凄く管理しやすくなるんで。
そういうクラス類は、べつにOOPの青年の主張はしません。
単にRDBというもの自体の構造をモデリングしたクラス群ですから、意味的ミスマッチを生じるはずがない。
(生じていたらただの設計ミス)
で、もう一方の(たぶんそういうものを土台にして)逆にRDBを「使って」オブジェクト(の永続化)を扱う場合は、
OO側でのモデリングをどうRDBに落とすか？で悩む、
Re:とらわれちゃうとねぇ (スコア:1)
私もOODBに興味が出てきたので、時間が取れたら調
べてみます（笑
#ひきこまれるな～
taka4