ダイアグラムの一貫性と、システムの最小単位、並列作業関連をまとめました。

　最近、このブログでやっている

　●各種ダイアグラムの一貫性について
　●システム開発に必要なもの（システムの最小単位）
　●並列処理と一貫性

の話を、以下のサイトにまとめました（といっても、ブログのリンクだけど）

システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm

実は、この３つの話、つながっているんです。

---

■システム開発に必要なもの（システムの最小単位）

　ここでは、まず「システム開発に必要な最小限の情報はなにか？」という話をしています。
　とくれば、ふつうは、チャーチのテーゼを出してきて、原始帰納的関数から、複雑なプロセスを作り出して行けるという話にもっていく（計算論 計算可能性とラムダ計算みたいなかんじ）。

　だけど、実際、チャーチのテーゼのように、入力と出力が決まれば、プログラムが書けるのか？っていうと、書けない。

３に４を足して５をかけたものを出力してください。

といわれても、「どこに？」となってしまう。

まあ、常識的に考えれば、コンソールだが、Webのページかも知んないし、ファイルかもしんない。ということで、出力するメディアがきまんないと、書きだせない。
　一方処理については、条件や順番が大事。

　３と５を入れ替えて、５に４を足して３をかけたものは、ぜんぜん違う値になる。

　なので、順番大事。

　そうすると、前に書いたように、プログラムを記述するには、

・データ（メディア、型、値＝変数と定数）
・プロセス（入力データ、出力データ、起動順序・条件）

で、逆にこれが決まってくると、プログラムにかけたり、書けない理由がわかったりする（出力、入力を行うライブラリ、フレームワークがない）。

---

■各種ダイアグラムの一貫性について

　では、

・データ（メディア、型、値＝変数と定数）
・プロセス（入力データ、出力データ、起動順序・条件）

　を記述したものはあるのか？という話になるが、ある。
　それが業務流れ図である。

　では、業務流れ図から、プログラムを起こせるのか？起こせるとした場合、どんな情報が必要になるのかというのが、次の話題である。

このとき、
・業務流れ図に一貫性があり
・入出力メディアを実現するライブラリ、フレームワークが存在すれば
プログラムを起こせるという話を、ここでは展開していく。

　プログラムを生成するため、業務流れ図などをRDBに入れ、一貫性チェックを行い、すでに登録してあるフレームワークの流れ図（も図なのでRDBに入る）合成していくという話だ。
　実は、プログラムだけでなく、UMLなど、ほかの図も生成できる。

---

■並列処理と一貫性

　ここでは、上記につくったダイアグラムがはいったRDBの応用になる。
　並列処理をさせたとき、一貫性を持たせるには、どうしたらよいか？

　これは、あるプロセスがあるデータを読み込み中のときに、ほかのサイトから、書きだし、更新を行わないことによって防止できるが、このことは、上記のRDBから検索可能なのか？という話を展開していく。

---

　なお上記２つが、大学院修士の論文にしようとして、結局すべて捨てた（ゴミ箱行き）お話、最後の「並列処理と一貫性」が新作ということになります。

　ってなことで、明日から３つをテキトーに書いていきます。

システムが「作れる」ことと「使える」ことと「使ってもらえる」ことは意味が違う

　前のブログでは、システムを「作る」のに必要な基本的情報は、

・データ（メディア、型、値＝変数と定数）
・プロセス（入力データ、出力データ、起動順序・条件）

と書いた。

　ところが、以前書いた、ことばと業務流れ図、ＵＭＬ、ユースケースシナリオの関係では、

　「業務流れ図で、表現するもの」は、

　　　●いつ
　　　●だれが
　　　●なにを
　　　●どのように

　であると書いた。このうち、「いつ」は、起動順序、条件に（上記の業務流れ図の話においても時間を絶対的時間でなく、相対的な時間＝手順としてとらえている）、「なにを」はデータ、「どのように」は、入力データから、出力データを導きだすプロセスとして表現される。なので、対応関係はある。

　でも、「だれが」・・・がない？なぜ？

---

これは、データとプロセスは、システムを「作る」条件として必要なことをあげているのに対して、業務流れ図は、システムを「使う」ときの様子を記述しているからだ。

　つまり、「作る」と「使う」では違う。誰が、使うか？が問題になってくるのだ。

　例えば、仕訳を入力して、決算関係書類（損益計算書、貸借対照表）を出力するシステムは作成できる。っていうか、ある、売ってる（＝いわゆる財務システム）

　でも、この仕訳入力、簿記をしらない人が入力することはできないし、
　まったく関係ない会社の人が、領収書とか、そーいう財務資料なしに入力することもできない。

　会社の、簿記を知ってる人が入力しないとシステムは使えない。

　このように、「誰が」というのは、システムにデータを入出力可能か、つまり簡単に言うと使えるのかを判断するのに必要になる。

---

　さらに、使ってもらえるとなると、知らなきゃいけない条件は増える。

　検索かけました・・・１時間たっても、何も返ってきません。

　ということがつづくと、使ってもらえるかどうか？？？になってくる。

　そうなると、システムの目的や費用、納期など、

　　　いつ
　　　どこで
　　　だれが
　　　何を
　　　なぜ
　　　どうする
　　　いくらで？

　という、5W2Hが必要になる。

システム開発を行うには・・・

　思いついたことのメモメモ・・・

　システムは、情報を処理するものなので、それを開発するには、

　　どのような情報を、
　　どう処理するか？

　ということが必要になる。

---

　どのような情報・・・とはデータのことになる。

　データは、値そのものも重要だが、その値がどう表現されているかということも重要である。
　従来、情報処理では、これを型として扱ってきた。そのような側面も重要だが、システムを実現するには、そのデータを表現するメディアが重要になる。メモリ上に展開するのか、DBなのか、画面なのか、帳票なのか・・・？である。
　つまり、
　　　「氏名を画面に、文字型で出力する」
　みたいな形でデータを考えないといけないってことになる。

　なお、データは、固定の値のこともあるが、前に処理した値を使うこともある。
　前に処理した値は、変数に入れるので、データの値は、定数と変数からなる。
　

---

　一方、「どう処理するか」は、プロセスになる。

　プロセスは、入力データ項目、出力データ項目で定義されるが、その他に、起動する順序と条件が必要になる。

　３に４を足して５をかける（３＋４）＊５と、
　４に５をかけて３を足す（４＊５）＋３

では、出力が違う。また、起動する条件、IF文やSWITCH文がないと、プログラムは記述できない。

---

まとめると、

システムは、以下のことが決まらないと作れない。

　　・データ（メディア、型、値＝変数と定数）
　　・プロセス（入力データ、出力データ、起動順序・条件）

　プロセスは、さらに細かく詳細化され、最終的に、プログラミング言語で記述できるまでに詳細化されないと、システムは作れない。

---

逆に、これだけのことが決まると、作れるのか？

　メディアである画面や帳票には、システム化する実現方法があり、それらの方法の中には、競合するもの、実現できないものもある。実現できるかどうかは、その入出力を実現するライブラリやフレームワークが存在するかどうかである。

　しかし、その競合が起こらなければ、入出力データは、フレームワークやライブラリを使って、プログラムにデータを供給したり、データを受け取って表示したりできる。

XMLDBより階層型DBにXMLを入れたほうが早くね？

　XMLの格納としてはXMLDBと考えるのが普通だけど、
むしろ、RDBよりも前に流行った、階層型DBにXMLを入れたほうが早くね？
ノードは、パラメータ、テキスト、子ノードを含んでいるけど、

たとえば、
　　　テキストは#text,
　　　パラメータは、$のあとに、パラメータ名をつけるとすると

ノード　－　＄パラメータ１　－　値
　　　　　　　：
　　　　　　　：
　　　　－　＄パラメータ１　－　値
　　　　－　＃Text　－　テキスト値
　　　　－　子ノード・・・・
　　　　　　　：
　　　　　　　：

みたいな感じで、階層的に入れられるような気がするし・・・

並行状況における一貫性確保と論理削除

　いま、いろいろと、データや処理の一貫性について、議論しているが、この議論は、並行状況におけるものではない。

　つまり、
　　Ａのプロセスで、Ｘ，Ｙを出力し、
　　Ｂのプロセスで、ＸとＹを入力し、Ｚを出力
　　Ｃのプロセスで、ＹとＺを入力し、Ｗを出力する

場合、Ｂよりも前に、Ａが行われるはずであり（でないとＸ、Ｙが入力できない）
　　　Ｃよりも前に、Ｂが行われるはずである（でないと、Ｚが入力できない）

なので、Ａ、Ｂ，Ｃの順におこなわれるはずであるというののチェックの話をしている。

---

しかし、ここで、Ｂのプロセスについて、細かに考えよう。
Ｂのプロセスでは

（１）まず、Ｘを入力する
（２）Ｘをある程度処理し、Ｖにする
（３）つぎにＹを入力する
（３）ＶとＹを処理してＺを作成する

という手順だったとする。

このとき、（２）のときに、他のプロセスがＹを削除してしまったらどうなるか。。。
（３）が処理できず、エラーになる。

ということで、並行処理の場合には、問題が起こる。

---

　この解決法の１つとして、論理削除がある。
　物理的に削除するのでなく、削除フラグをＯＮにするだけなら、
（３）の状態で（削除フラグＯＮになった）Ｙを利用すればよいだけなので、問題ない。

　その際、Ｙがたとえばファイル名だとしたら、論理削除する場合、同名のファイル名をつけられる可能性があるので（（論理）削除後、同名のファイルを新規作成した）、ファイル名のようなものではなく、論理削除したものも含めて、一意にする必要がある（Ａｕｔｏインクリメントすればいい）

　この場合、プロセスの開始時に、入力資源のＩＤをすべて確保しておくことになる。

　そして、論理削除の場合、じゃ、実際に物理的にいつ削除するの？っていうのが問題になる。

---

　変数を上書きするのでなく、１回代入して、次、代入するときは、同じ変数名でも別領域をとる（たしか、ＭＬってそうじゃなかったっけ？）もおんなじ理屈？

“２ちゃんねるなども摘発対象に” ＵＲＬ書くだけで逮捕 － じゃ、トラックバックは？

ここの痛いニュース
“２ちゃんねるなども摘発対象に” ＵＲＬ書くだけで逮捕、「ｔｔｐ：」などでもアウト…児童ポルノ法
http://blog.livedoor.jp/dqnplus/archives/1282013.html

この記事のあとのほうに、奥村弁護士が、このことが、「著作権の問題」に広がったら？といっているが、

それもあるけど、ＵＲＬを書くだけでアウトなら、

検索サイトも、
ブログのトラックバックもアウト！！だよねえ・・・

もし、「トラックバックは除外」ってしてしまうと、
テキトーなブログを作って、リンク集を作れるので
（あるサイトからブログへ、そのサイトとはぜんぜん関係ない人からでもトラックバックを貼れる
　ということは、自分でテキトーなブログをつくり、
　そのブログにリンク集で作ったら”やばやば”なサイトを、
　トラックバックすることは、容易にできる）

そっちのほうが、やばくね？

Strutsで、HashMapのArrayList→logic:iterate

　まえに、「データアクセスと処理との間の中間層のインターフェースは、ハッシュマップとその配列に集約する」 というのを書いたけど、そうすると、何がいいのか？について書かなかった。

　たとえば、Strutsで考えると、これらハッシュマップと、ハッシュマップの配列をsessionにいれておくと、

　画面のＪＳＰ内で、strutsタグで、

●ハッシュマップであれば、

　　＜bean:write name="セッション名" property="ハッシュマップのキー値" scope="session" /＞

　で、ハッシュマップの値が出力できる。

●一方、ハッシュマップの配列やハッシュマップのArrayListをセッションに入れた場合は、

　＜logic:iterate id="変数名" name="セッション名" scope="session" indexId="インデックス変数"＞
　　　　＜bean:write name="変数名" property="ハッシュマップのキー値" /＞
　＜/logic:iterate＞

　レコード分、ハッシュマップのキー値を書き出す。
　何レコード目かを出す場合は、インデックス変数を出力する、つまり

　＜logic:iterate id="変数名" name="セッション名" scope="session" indexId="インデックス変数"＞
　　　　＜bean:write name="インデックス変数名" /＞
　＜/logic:iterate＞

　でＯＫ（このとき、昨日書いたエラーになることあり）

（ここまで　＜　＞　は、本当は半角）

---

　ということは、つまり、

　ＳＱＬを引数として渡すと、結果をハッシュマップの配列で返すメソッドがあれば、

　ＳｔｒｕｔｓのＡｃｔｉｏｎで、入力値などから、そのクラスを呼び出し、
　その結果をセッションに入れて、
　次画面ＪＳＰで、上記のように記述すれば、

　ＳＱＬを考えるだけで、あとは自動的に、画面上にデータを出力させることが出来ます。

　っていうメリットがあるんですねえ・・・

　つまり、入出力のインピーダンスを大幅に提言することが出来る。

グーグル、ネットブックＯＳ「Google Chrome OS」を発表

ここの記事
【速報】グーグル、「Google Chrome OS」を発表――来年には搭載ネットブックがお目見え
http://headlines.yahoo.co.jp/hl?a=20090708-00000003-cwj-sci
（以下斜体は上記サイトより引用）

アプリケーション開発者に対して「Chrome OSの開発プラットフォームはWebである」と説明していることから、同社のWebブラウザ「Google Chrome」のみが起動するシンプルなOSであるとも考えられる。


そーなると、クラウド＆シンクライアントっぽいね。

strutsで「MESSAGE に対するメッセージリソースが見つかりません」というときの対策

以下のエラー

javax.servlet.jsp.JspException: キー org.apache.struts.action.MESSAGE に対するメッセージリソースが見つかりません

を、メッセージリソース関係を一切使っていないのに出る場合
（というか、使ってないから出るんだけど・・・）
の対策。

・使っていないことはわかってるけど、struts-config.xmlに、 ＜message-resources parameter="resources.application"/＞ （上記＜　＞　は、本当は半角） を記述する。

このリソースファイルは、あってもなくてもＯＫ。
なくても、上記エラーは消え、正常に実行する

いや、このあと、あるサンプルを書こうと思って、今プログラムつくってたら、
このエラーが出て（logic:iterateで、indexIdを使い、そのidをbean:writeしたら出た）、
みんな、？？？と思っているみたいなので、書いてみた。

UML等各種ダイアグラムのエラーチェック体系化（その１１：ダイアグラムをグラフ理論化－２）

　前回までの話、いろんなダイアグラムをＲＤＢにいれよう！化計画、

　今、ダイアグラムの構成要素を、ノード、リレーション（エッジ）、属性、属性値に分けようとしています。

　そして、前回、
　　その構成要素単独で意味をなすもの
　をノードとしました。

　今回は、その反対、つまり
　　その構成要素単独で意味をなさないもの
　について考えます。

---

■その構成要素単独で意味をなさないもの

　これはつまり、ある構成要素と他の構成要素を結びつけたり、
　ある構成要素の説明になっているようなものがあります。

　今回は特に、「ある構成要素と他の構成要素を結びつけ」る物について考えます。
　言い換えれば、これは、２つ（以上）の構成要素を結びつけるものです。

　これを、ここでは、リレーションと呼びます。グラフ理論のエッジです。

　これの例としては、
　・ＥＲ図のリレーション
　・ＤＦＤのデータフロー
　・流れ図などで書く→線
　・音符の連符のところについている、音符間の線（って、なんていうんだろう　＾＾；）

---

■みえないけど、ひかれているリレーション

　なお、前ノードの上に、ノードが載っていることもあると書きましたが、その場合、
２つのノード間に関係があって結びついていれば、リレーションがあるとみなします。
　つまり、線が引かれているとみなします。

　前回、落書きした場合について書きました。その際、たまたま上に書かれていても
落書きは、ドキュメントと内容が関係なければ、上にあっても関係ないと書いた理由は、
このように、ドキュメントと落書きが関係なければ、リレーションがないからです。
（関係があれば、みえないリレーションがあると考えます）

　また、ある構成要素について、詳しく書かれている場合や、続きが書かれている場合も、
　見えないけど、リレーションがひかれていると考えます。
　ＤＦＤなどで、あるプロセスを別のＤＦＤとして書く場合です。
　また、絵と、絵の上にある１ピクセルも、リレーションで結びついていると考えます。

---

　次回は、「その構成要素単独で意味をなさないもの」で、１つの構成要素に結びついている「属性」についてです。

データアクセスと処理との間の中間層のインターフェースは、ハッシュマップとその配列に集約する

　この前書いた、ＲＤＢとかに直接アクセスしないで、デバイスを意識しないデータアクセス層を作る話だけど、こうすると、

ひとつのメリットとしては、
　　・ＫＶＳとか、どこに分散されてるかとか、ファイルかとか意識しないでアクセスできる
　　　　→みんながアクセス法をしらなくてもいい

そのほかにも
　　・もし、ＤＢ上で変更が起こったとき、入出力が集約しているので、対応しやすい
　　　　→場合によっては、変更をこの層で吸収できる。

なんていうメリットがある。

さらに、
　　・すべてのデータを同じように表現できる

ということがある。このメリットはさておき、まず、デバイスにかかわらず、
どう表現すると、データを同じように表現できるのかについて、述べてみたいと思います。

---

■データは、ハッシュマップ（連想配列）とその配列で表現できる。

　たとえば、ＲＤＢのデータは、１レコードを１ハッシュマップとし
　（項目がキー、値がvalueになる）、それの配列で、テーブル、ビュー、検索結果が表現できます。

　ＫＶＳは、まさにハッシュマップ

　プロパティファイルはハッシュマップ

　ＣＳＶの場合は、１レコード１ハッシュマップにして、
　キーに項目番号１、２、３・・・値に、その項目のセルの値をセット

　ＸＭＬはいやらしい形なのですが、

　１ノード１ハッシュマップ。
　そのときのパラメータをキー、値にセット
　テキスト部分はキーを#text#1のような形で
　　（テキストが、２つの部分に分かれてれば#text#2,３つなら＃３・・・）
　子ノードは、キーに子ノード名#1(同名の２番目のノード#2・・・）
　　　　　　　値に子ノードのハッシュマップ

　という形でいれられないこともないです。

　こんなかんじで、大体のデータは、ハッシュマップ（連想配列）とその配列で表現できます。

---

さらにまとめると、ハッシュマップだけで表現されているものも、要素１個の
ハッシュマップの配列にできるので、これだけで表現できるともいえます。

で、こうやって、ハッシュマップの配列にすると、何が楽しいのかについては、
今度書きます。

リーナス・トーバルズ氏が10月にくるみたいだけど、申し込んだ？

ここのニュース
リーナス・トーバルズ、10月に来日
http://headlines.yahoo.co.jp/hl?a=20090629-00000017-zdn_ep-sci
（以下斜体は上記ニュースより引用）


Linuxカーネルの生みの親にしてThe Linux Foundationのフェローでもあるリーナス・トーバルズ氏が10月に東京で開催される国際技術シンポジウム「第1回 Japan Linux Symposium」の基調講演のため来日することが明らかとなった。

　このシンポジウムは、The Linux Foundationが10月21～23日にかけて開催するもの


で、どうも、キーノートスピーチに出るみたいで、
（基調講演は！！）無料のようなので、（セミナーは有料）
無料の基調講演を、申し込んだ。

第1回Japan Linux Symposium
2009年10月21～23日－日本、東京
http://events.linuxfoundation.jp/events/japan-linux-symposium
で、参加登録タグをクリック。

で、メールが送られてきたんだけど・・・
当日、これもってけばOKなの？

Please print this email for your records.

って、書いてあるけど、会場に持ってこいとは、書いてないが・・・

・・・ま、印刷して、持ってけば、大丈夫なんだろう、と信じよう（＾＾；）

Registration IDも書いてあるし
。。。って、こんなに申し込んでるの？
これまさか、このキーノースピーチだけの参加者の連番じゃないよねえ・・・

RSAってさあ、桁数が増えると、ほんとーに安全なの？

　つまりさ、RSA１０２４より、RSA２０４８のほうが、素因数分解しにくいので安全っていうじゃない？

　たしかに、カギにする素数をランダムに、一様につくっているなら、その通りだけど、

　常識的に考えて、桁数が多い素数ほど、（解読されにくいかもしれないけど）つくりにくいじゃない？

　ってことは、それを高速で作るってことは、なんらかの規則とかアルゴリズムに基づいて作っているか、素数のプールがあるってことじゃないの？
　じゃあ、その素数生成の規則、アルゴリズムがわかってしまった場合、そこから公開鍵と元となる素数を再現できないのかなあ？？

　さらに、素数のプールから２つ選んで作ってるとすると、桁数が多いほど、素数のプール中にある素数は（つくりにくくなるので）減るだろうから・・・

安全なのかなあ？

データとプロセスの一貫性の検証としてのCRUD図

　ちょっとおもいついたことなんで、メモメモ。

---

　システムを開発するには、まず、その目的から、ゴールを設定する。
　ゴールは成果物であり、出力となる。
　出力される帳票、画面などには、データがあるのがふつうで、それが出力データとなる。

　出力データから、プロセスを切りだし、入力データを割り出す方法としては、

　（１）出力データが、いつ生成、読み込み、変更、削除されるかを考える
　　　　→そのときがイベントになり、そのイベントにプロセスが対応してくる

　（２）出力データが生成される際、自動的に作り出すことができず、
　　　　　　　誰かが入力する必要があれば、それは入力データになる。
　　　　そのときのイベントは（１）でわかっているので、そこが入力画面になる

　（３）入力データ＋出力データ中、データを保存する必要があれば、
　　　　　それは保存項目となる→正規化→ER図→ファイル・DB(テーブル）

このとき、（１）で生成(C)、読み込み(R)、変更(U)、削除(D)のタイミングを表すのに、
データとプロセスを直行させて、そこにCRUDを入れていくのが、CRUD図。
　なので、データとプロセスの一貫性（データがあるということは、どこかで生成されているはずだが、その生成されているプロセスがあるかどうか）をCRUD図で、しめすことができる。

---

　一方、現実的には、すべての出力データを明確にすることはむずかしく（＝ゴールを明確化することは難しく）、玉虫色のゴールにして、システム開発を行う。
　この場合、プロセスをどんどん詳細にしていく。

この場合、逆に、
（１）そのプロセスで扱うデータをCRUDにまとめていくと、

（２）結果として、生成（C）されていて、削除（D）されてないデータを、
　　　出力出たとすることができる

（３）そこで、出力できるデータからゴールとなる、
　　　目的の成果物ができればいいんだけど・・

この場合でも、（１）の段階で、データとプロセスを直行させて、CRUD図を作成すれば、データとプロセスの一貫性ををCRUD図で、しめすことができる。

---

　ということで、データとプロセスの一貫性を示すには、CRUD図ってことになるけど、実はこの図、作成するのがめんどっちいので作成しない。
　このへんが、簡単に作成できるようになると、システム開発の精度は上がってくると思う。

ＡＳＩＤ特性が必要な場合ＲＤＢ，いらなければファイルで、それらを意識せずアクセスしない？

うん？？と思った記事があるんで、ちょっと確認。

ここの話
「クラウドによるIT補完計画」とは
http://slashdot.jp/it/09/07/02/173247.shtml
なんだけど、元ネタは、ここ

もう1つの、DBのかたち、分散Key-Valueストアとは
http://www.atmarkit.co.jp/fjava/rensai4/bigtable01/01.html

ってことで、まあ、元ネタのほうで考えましょうか（以下斜体は上記@ITの記事から引用）

---

クラウドなどで使われる、分散ＫＶＳ（Key-Valueストア）というのがある。
で、こいつは、ＲＤＢにくらべ、

トランザクションによる「ACID特性」の確保も分散KVSが苦手な分野です。


ってかいてあるけど、つーか、もともと、ＡＣＩＤ特性を確保するためにＲＤＢが
出てきたので、そうでなきゃ、ファイルシステムでＯＫ。


　ＡＣＩＤ特性はつまり、中途半端にデータベースがコミットされることはないってことであり
（たとえば、給与振込みで、会社の残金－給与額と、従業員の残金＋給与が同時に
　行われるってこと。会社の残金から給与分が減っている＝会社的には振り込んだのに、
　従業員の給与は増えていない（従業員から見ると振り込まれていない）ということがない）
　
　これを実現するために、トランザクションのコミット、ロールバック、排他制御がしっかり入っている。

　現在の事務系アプリにおいて、たとえば、給料を支払ったのに振り込まれてない、なんていうことは
まず許されないから、このＡＣＩＤ特性が担保されないっていうのは、超困る。
　そこで、事務系アプリにおいては、たいていＲＤＢを使う。

---

　でも、もし、ＡＳＩＤ特性を担保しなくてよい場合（データ検索など）では、ＲＤＢがある前のシステム、つまり、ファイルシステムでよい。

　ファイルシステムは、ファイル名をキーとし、中身をバリューと考えると、すでに、キーバリューの形になっている。そして、ファイルシステムはすでに分散されている。

　早い検索を行いたければ、インデックスを作るけど、実は、Ｌｉｎｕｘなどでは、これはリンクにより
実現できる（同じキーに複数値があることがある場合、ディレクトリがキーになる場合があるけど）

　ただ、ファイルシステムでは問題ありありという場合は、ＸＭＬ（ＸＭＬＤＢ）というアプローチもある。

　ってことで、分散ＫＶＳ（Key-Valueストア）は、こちらのほうに属する技術だろう・・・

---

　ただ、今のアプリ開発側から見ると、データベース、ファイルの差異をなくすため、ＤＡＯ(データアクセスオブジェクト＝ってか、データアクセス層）を作ってアクセスする

　　　　　　　　　　　　　　　　　　　　　　業務アプリ
　　　　　　　　　　　　　　　　　　　　　　　　｜（入出力）
　　　　　　　　　データアクセス層（ＨａｓｈＭａｐの配列などでデータを渡したり、ＤＯＭで渡したり）
　　　　　　　　　　　｜　　　　｜　　　　　　　　　｜　　　　｜　　　　｜　　
　　　　　　　　　　ＲＤＢ　　プロパティファイル　ＣＳＶ　　ＸＭＬ　分散ＫＶＳ？？

　ＤＢに直接アクセスするのでなく、１回抽象化した層を挟む。
　そして、パフォーマンスなどによって、ＲＤＢにするか、ファイルにするか、オンメモリにするか（＝セッションに入れておくなど）を決める。
※セッションに入れたくても、ロードバランシングで、さまざまなサーバーにデータが飛ぶ場合、セッションに入れられず、分散ファイルに保存するなんてこともある。なので、一概にどれがいいとはいえない。

　もし、データアクセス層を作らないと、開発者全員が、アクセス方法を知らないといけなくなり、人月単価が高くなり、ソフト開発競争力がなくなる。そこで、簡単にアクセスできるＤＡＯを作成し、差を吸収する。

　ということで、別に分散ＫＶＳが出てきたところで、データアクセス層で差を吸収してしまうので、たいした問題でなく、「出来損ないの群体として行き詰まったITシステムを、完全な単体インフラへ人工進化させる」（クラウドによるIT補完計画）というほどのはなしかあ？ってなります。いや、ＡＳＩＤ特性をばっちり持った超高速アップデート方式が見つかれば、そっちのほうが、利用価値は高いです。

　なので、それを実現する、分散型インメモリ・データグリッド・ソリューションである、Oracle Coherenceのほうが、話的には面白いと思うけどなあ・・・