XMLデータベース開発方法論(1) Page 1/4
序章、データ処理技法の地政学
川俣 晶
株式会社ピーデー
2005/6/28
本連載は、XMLデータベースの開発方法論を展開する内容である。全6回の連載の前半3回では、なぜXMLデータベースを採用すべきなのかという根元的な認識を読者と共有し、後半3回においてXMLデータベース構築に特化した開発方法論を展開する。(編集局)
常識を信じていては、カラは破れない。 明日の行方は無限大であることを… 固まることなく、半熟であるべきことを…! ゲーム「半熟英雄4 〜7人の半熟英雄〜」(スクウェア・エニックス)より |
主な内容 --Page 1--
本連載の目的本連載の価値観「すべきである」対「せざるを得ない」 本連載のお約束 筆者の立場と議論の進め方 XMLデータベースの定義 --Page 2--
ここがスタートライン、データ処理技法の個人史対照的な2つのデータ表現方法 例外的処理こそが重要である --Page 3--
AWK、使い捨てデータ処理の切り札問題を認識する領域 --Page 4--
RDBとAWKの中間ポイントに位置するXMLさまざまな技術たち 挫折、XMLはAWKの不満を解消し得なかった 結末、そしてXMLデータベースへ 次回予告 |
本連載の目的は、XMLデータベースから可能な限り多くの価値を引き出す指針を示すことである。つまり、本連載で示された指針に沿ってXMLデータベースを扱えば、「ああ、確かに(ほかの技術ではなく)XMLデータベースを採用してよかった」と思っていただけることが筆者たる私の目標ということになる。
それとは別に、本来の意図とはやや異なるもう1つの目標がある。それは、日本におけるXMLデータベースへの期待を盛り上げるムードづくりである。残念ながら、XMLデータベースへの注目度は高いものの、入手可能なソフトウェアの種類は少なく、商用ソフトには目の玉が飛び出るほど高価なものが多い。しかし、値段というものは、利用者が増えれば下がるものである。また、オープンソースなどの非営利プロジェクトであっても、やはり利用者が多ければモチベーションも高まり、より優れたソフトウェアが生まれてくることが期待できる。そのようなムードを盛り上げ、ぜひともXMLデータベースを安価かつ安心して利用できる環境を実現したいと願うものである。
(そして、安価かつ優れたXMLデータベースソフトを最も切実に欲しているのは実は筆者自身である。つまり、本連載は公平無私ではあるが空虚な理想論ではなく、私的ではあるが泥臭い現実の要求に立脚して進められる。いい換えれば、地に足が着いたレベルの切実なる要求を出発点としている)
よく誤解されるのだが、筆者は「すべきである」という立場をあまり取らない。「すべきである」というのは、素晴らしいがなくても差し当たって困らない理想を推進する態度である。そうではなく、大抵の場合、筆者は「せざるを得ない」という態度を取る。「せざるを得ない」とは、さまざまな制約を考え合わせると、それを選択するしかない状況を意味する。
この点はしっかり踏まえていただきたいと思う。つまり、本連載においてRDBではなくXMLデータベースを使うということは、RDBでも処理できるデータに何かすてきな(しかし必須ではない)付加価値を付けるために行われるのではない。そうではなく、RDBを含む多くのデータ処理手法が条件に合わないために候補から脱落した結果、XMLデータベースを「使わざるを得ない」状況が出現し、XMLデータベースを使うということである。
この状況は、筆者だけの特別な事例ではなく、条件さえ合えば誰にでも起こり得る状況ではないかと考えている。そして、ここ数年、そのような条件に合致するシチュエーションが発生しやすくなっているのではないかと考えている。つまり、10年前にはそのような状況はなかったとしても、来年には読者のあなたがその状況に直面する可能性はあり得るということである。
これについて詳細は、連載の中で述べることになる。
本連載は、ある種のパラダイムシフトを含むことを意図している。パラダイムとは「ある一時代の人々のものの見方・考え方を根本的に規定している概念的枠組み」であり、パラダイムシフトとはそのような枠組みが変化することをいう。つまり、これまで常識とされてきたいくつかのことを、本連載では覆すことを意図している。
例えば、データベースを選定するといえば、Oracle、SQL Server、DB2……とRDBの製品の中から選ぶことだと思っていた読者がいるとすれば、それとはまったく異なるテキストベースのデータ処理の長い歴史が存在することを知っていただかねばならない。そして、テキストベースのデータ処理が万能であると考える読者には、その限界を認識してもらわねばならない。
そのため、本連載を読むに当たっては、その前提としている世界観、テクノロジー、問題意識などを把握する前に反論を試みないように約束していただきたい。本連載の文章は、読者のあなたが前提とする常識の上に書かれてはいないかもしれないのである。議論を行うために必要な情報は、現在の予定では、全6回の連載中の第3回までに語り終える予定である。
このような議論の土台は、おそらく本連載に限らず、異なるバックグラウンドを持つソフトウェア技術者同士が議論を行う際にも有用であろう。現実的に、同じソフトウェア技術者であっても、かかわる世界が異なるとまったく常識が異なっていて、そもそも議論が成立せずに、宗教論争的な状況が引き起こされることがある(XML界における貴族とボヘミアンの問題など)。議論の前に、共有される共通の土台を持つことは、このような不毛な対立を回避する効能もあると信じたい。
これを書いている筆者の立場は、1人のプログラマであり、1人のプログラム言語ミーハーであり、1人のXML好きであり、1人の自称技術思想家である。しかし、情報工学を体系的に学んだことはなく、データベースに関してはプロフェッショナルというわけでもない。
筆者が、XMLデータベースに関して何かを語り得る根拠があるとすれば、それは実際にソフトウェア開発のプランを練っているときに、どうしてもXMLデータベースが必要であるという状況に陥った生々しい体験にあるだろう。だからこそ、空虚な理想論に陥らずに切実な必要性を語ることができるという長所があるが、一方で専門教育を受けた者であれば誰もが知っているはずの常識がどこかで欠けている可能性があるという短所もある。ここでは、短所を踏まえたうえで、長所にこそ大きな価値があると信じて先に進もう。
さて、そのような立場より書かれるため、本連載は以下のような議論の進め方を取る。まず、個人的体験をベースにし、それに考察や分析を加えることで、一般論としての結論に展開させていく。いうまでもなく、その際の方法論は、根拠のない「であるべき」論ではなく、条件によって制約された「せざるを得ない」論となる。XMLデータベースの利用実績が少ないいま、こう使ってうまくいったという実績を基にした話はあまりできないのだが、逆に制約を基にして、できないことを回避するために、こうせざるを得ないという話は可能なのである。
議論を行う際の基本中の基本は、そこで使われる用語の定義を参加者がきちんと合意していることである。それを踏まえないで議論を行うと、悲惨な結末になりかねない。例えば、XMLについて議論をしているときに、XMLという3文字が示す内容に食い違いがあることは日常茶飯事である。ある人はXML 1.0勧告のことだけがXMLだと思っていて、別の人はXMLとはいわゆるWebサービス(SOAPなど)だと思っていて、別の人はタグを自分で決められるHTMLのことだと思っていたりすることがある。
同様に、XMLデータベースという言葉も、人によって受け止め方が異なるケースが見られる。そこで、「XMLデータベース」という用語について、本連載での定義を与えよう。
XMLデータベースとは……。
- XMLのデータモデルに含まれる情報を欠落することなく扱える
- XMLのデータモデルに沿った情報の追加、更新、検索、削除などができる
- 保存されるファイル形式が、テキスト形式のXML文書の書式に適合する必要はない
- いつでもXML勧告が示すテキスト形式のXML文書と相互変換できる
なお、この定義は、本連載内だけの定義であり、世の中の正しい用語の定義を決めるという意図はない。
ちなみに、ここでいうXMLデータベースは、ネイティブXMLデータベースと呼ばれるカテゴリにほぼ一致すると考えてよいと思う。
さて、見慣れない言葉が出てきたと思うので、それを説明しよう。XMLのデータモデルとは、簡単にいえば、XML文書が表現しているデータの構造のことをいう。例えば、XMLのデータモデルは、要素や属性といった単位を組み合わせて実現されたツリー構造である。一方、RDBのデータモデルはフィールドやレコードから構成されている。ここでは詳細には立ち入らないが、両者は異なるデータモデルとなる。ただし、1つのデータベースが、常に1つのデータモデルだけを採用しているわけではないことに注意が必要である。RDBの1つのフィールドが、XMLのデータモデルに一致するデータを保持するといった折衷型のモデルもあり得るし、実際にSQL Server 2005はそのような構造になっている。しかし、折衷型モデルについて考えることができるのは、2つのデータモデルの特徴を把握した後の話になるので、これは横に置いて先に進むことにしよう。
最後にXML文書を扱うにもかかわらず、この定義に合致しないデータベースについて説明しておこう。XML文書を扱うことができるデータベースの中には、XML文書の内容をRDBのデータベースにマッピングすることで実現するものがある。例えば、XML文書の<名前>要素を、RDBの「名前」フィールドに関連付ける(マッピングする)ようなシステムである。このようなシステムは、関連付けが存在しない情報を扱えないため、XMLのデータモデルに含まれる情報を「欠落することなく扱える」という条件を満たさない。ここでは、このようなデータベースはXMLデータベースとは見なさない、という前提で話を進めることにする。(次ページへ続く)
1/4 |
Index | |
XMLデータベース開発方法論(1) 序章、データ処理技法の地政学 |
|
Page 1 ・本連載の目的 ・本連載の価値観「すべきである」対「せざるを得ない」 ・本連載のお約束 ・筆者の立場と議論の進め方 ・XMLデータベースの定義 |
|
Page 2 ・ここがスタートライン、データ処理技法の個人史 ・対照的な2つのデータ表現方法 ・例外的処理こそが重要である |
|
Page 3 ・AWK、使い捨てデータ処理の切り札 ・問題を認識する領域 |
|
Page 4 ・RDBとAWKの中間ポイントに位置するXML ・さまざまな技術たち ・挫折、XMLはAWKの不満を解消し得なかった ・結末、そしてXMLデータベースへ ・次回予告 |
XMLデータベース開発論 |
- Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか (2017/7/26)
データベース管理システムの運用でトラブルが発生したらどうするか。DBサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle SE2の「CPUスレッド数制限」がどんな仕組みで行われるのかを検証します - ドメイン参加後、SQL Serverが起動しなくなった (2017/7/24)
本連載では、「SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ドメイン参加後にSQL Serverが起動しなくなった場合の対処方法」を解説します - さらに高度なSQL実行計画の取得」のために理解しておくべきこと (2017/7/21)
日本オラクルのデータベーススペシャリストが「DBAがすぐ実践できる即効テクニック」を紹介する本連載。今回は「より高度なSQL実行計画を取得するために、理解しておいてほしいこと」を解説します - データベースセキュリティが「各種ガイドライン」に記載され始めている事実 (2017/7/20)
本連載では、「データベースセキュリティに必要な対策」を学び、DBMSでの「具体的な実装方法」や「Tips」などを紹介していきます。今回は、「各種ガイドラインが示すコンプライアンス要件に、データベースのセキュリティはどのように記載されているのか」を解説します
|
|