データベース、階層構造、ビッグデータ等について

質問

下記の記述は間違いで、下に説明がありますが、何を言っているのかイメージがわきません。もう少し何かに例えて、わかりやすく御説明していただけないでしょうか

「XMLデータベースとは、XMLの階層構造をRDBの階層構造にマッピングして利用するデータベースである。」

上記の記述は誤り。ＸＭＬデータをＲＤＢＭＳで扱うために>マッピングをするので，ＸＭＬデータベースではラッピングをしない。

補足ですが、この解答のラッピングはマッピングの間違いではないでしょうか？

回答No.1

hue2011 · ベストアンサー

解答のほうも間違ってるじゃないかと思いますが。マッピングの間違いというレベルではなくて。

DBに関して軽い解説をしたほうが早いと思います。そうでないとRDBに頭を毒された連中にはめられます。

昔からデータというものはありました。名簿でも商品一覧でも。

それをコンピュータで扱いたいと考えたときに発想が生まれたわけです。

商品一覧なら商品一覧だけをまとめて管理しよう、顧客リストなら顧客リストで管理しようという神経です。
とりあえずこれは正しい、とみんな思ったわけです。
管理するために、商品コードを付けておこう、顧客番号をいれよう、という発想が起きます。

わかりやすいように、病院だとしてみましょうか。患者が来たら、診察券を発行します。そのうえに番号が振ってあります。
その番号でカルテを作り、そのページを足していきます。

ふつう、あいうえお順でカルテを棚に置いておきます。
そして、診察券発行記録は別にノートを作っています。

これによって、診察券番号で問い合わせても、名前でといあわせてもその人の情報にたどり着くわけです。

ただのデータですが、なぜすぐに使えるかというと、片方は名前順、片方は番号順になっているものがあるからです。
しかし、診察券発行記録ではその人の病名や診療記録はわかりません。

ここでISAMというデータ管理様式が現れます。ここからデータベースの始まりです。
データは積みあがるだけです。
診察券番号というインデックスがあると、そのインデックスで情報が引き当てられます。
名前、というインデックスがあると、そのインデックスで情報が引き当てられます。
Index Sequentialed Acess Methodの略です。

これはインデックスはいくつも作れますが、インデックスは別箱にあり、データはそのままです。

それを一つのファイル内でやりたいと思ったのがデータベースです。
そういう管理システムを持っている中にテーブルというのを作るのです。
同じ内部にインデックスを持ち、データが追加修正されるたびにそのインデックスを作り直しソートしておくわけです。
その代わり、何をどういう仕様で持つ、というのがかなり固定的になります。
たとえば、患者名を、苗字と名前、という2欄で管理するようにするならそれきりになりがちです。
外国人でリチャード・カーライル・ショーティという人がきたら、カーライルは捨てられることになります。

その病院では、面倒にならないように、内科の患者テーブル、外科の患者テーブル、耳鼻咽喉科の患者テーブル、というように別々に持つとします。
通常これが普通でしょう。

インデックスをつけたものを検索するのはきわめて早い。
だけどそうでない項目を探すなら、頭から最後まで読んでいかなければいけません。これが宿命です。
1行を読む、何かをする、という行動を全行にやる必要があるのです。

薬に副作用や障害があると発表された場合、その処方をした患者がどれだけいるか探さなければなりませんがその場合はこういうことになります。

ある人が、自分のところは内科だけど、他で何か処方されていないか調べたい場合がでたりする。
そのとき、診察券番号は一緒ですけど、外科のテーブル、産科のテーブル、と他のテーブルの同じ番号のカルテがどうなっているかしりたい場合が出ます。
インデックスがあれば簡単で、別のテーブルをその番号で調べればいいだけです。
いま内科のデータが表示可能になっていて、それに並べて耳鼻咽喉科や泌尿器科のものもほしい。
それは関連付けることになりますから、リレーションというわけです。

そういうことが簡単にできるのがRDBです。リレーショナルデータベースというわけです。

いいですか。話はここからです。
このRDBには致命的な問題が二つあります。

ひとつは、一度DB仕様を決めたら簡単には変更できないということです。

もう一つは、インデックス管理を常時していなければいけないため、異常に処理が遅くなるということです。

最初のほうを解決する手段として考えられたのがXMLでデータ構造を表現するやり方です。

HTMLで<table>を使う場合の簡単さで考えてもらえばわかりますが、項目の1列追加なんて簡単であり、それがいままでのページ処理に大きく被害を及ぼすなんてありません。
RDBの場合はスキーマというものがあり、それを改造するとあちこちに影響が出ます。

ここでよく考えてもらえばわかることですけど、RDBのテーブルの中にXMLを入れることも可能です。
また、XMLの処理の中にRDBの機能を埋め込むことも可能です。
RDBのテーブルで設計された概念を、RDBを捨て去ってXMLだけで表現することも可能です。

データの階層構造をどう作るかはセンスの問題にすぎません。

マッピングをやらせる、という発想はすでにRDBの思想に頭が汚染されているのです。
マッピング、はインデクシングということですので。

ラッピングは、まだしもかぶせて使うということですから、ユーザーインターフェースの改善という意味はあります。
しかしこの著者にはそういう感覚がないと見えます。

理論のための理論、なんて何の価値があるんですか。

記事は長いので次に続きます。

お礼

わかりやすい御説明ありがとうございます。コンピュータの世界のお話も楽しく読ませていただいております

これからもよろしく宜しくお願い致します。

補足

流れがわかりました。ありがとうございます。

回答No.2

hue2011

回答その２です。

致命的な問題のもう一つのほうを言います。

仮に何十億というデータがやってきた場合、全部のデータをみていくという繰り返しをやるならとんでもない時間がかかります。
ひまわり８号から送られてくるデータは数日でテラバイトになるんですよ。

毎日ネット上に流れているデータなんて、ひとつひとつ調べていたら、発生のスピードに追い付きません。

だけど、その中で「ポケモンGO」だけを探したいときに、RDBの発想をしていたら話になりません。
毎秒次つぎに発生するデータをいちいちDBに登録なんか不可能です。

この場合に役に立つのが、おなじみのgrepです。

linuxでは始終つかうgrepですけど、原理はなんだと思いますか。

ざる、とかフルイです。
石ころが、かぞえたらどうにもならない数河原に敷き詰められています。
この中から、たとえば3センチ球形の小石を選ぼうと思ったらどうしますか。
一粒一粒ひろって調べますか。

3センチの円の穴をいくつも持つ篩を作りませんか。
そして上からざぶざぶ石を流し込みます。
ひらべったいものとか小さいものはすべて流れ出します。
のこっているのは3センチ以上の石ころです。

次に、3センチよりちょっと大きい穴のあいたざるに残っている全部を流します。
そうすると、3センチの球形のものだけが下に落ちてきます。

それとgrepは同じことなんです。
ある文字列の穴を情報の渦に差し出しているだけです。

ひとつひとつのものなんか見てません。

自分の握っているものだけを大事なものとし、インデックスを始終作り変えているRDBとは神経が違います。
ちいさい箱のデータなんか見ていない。

それを「ビッグデータ」という考えかたとするのです。

RDBを作る場合、大事なもの、使い物、をその箱に入れようとします。
そして使いもしないようなものは捨てます。処理が遅くなるから。
そうして、人間の名前のミドルネームなんか捨てられたわけです。

だけど、それでいいのか。

そういう考え方が、想定外という言葉を盾にして責任逃れをする方向と地続きです。

想定外の言葉、あるいはいままでゴミだと思っていたけど注目したほうがいい言葉を拾えないとまずい。
これがビッグデータ発想です。

そのかわり、個々の石ころの顔なんて見ていません。

いままで思考方向の違うやりかたを説明しました。

だけど、どれが優れていてどれがまずいということはありません。

よくありがちなのは、新手法がすばらしくていままでのはクソだといういいかたをしがちなことです。

問題解決の方向性によって選択肢があるということです。

お礼

勉強になりました。ありがとうございます。

補足

早速の御回答ありがとうございます。問題提起で深く考察することが出来ました。