|
||||||||||
| 1 2 3 次のページ | ||||||||||
| はじめに | ||||||||||
|
前回、ナレッジワーカーが情報を的確に探し出せない主たる要因は、情報の大半がドキュメント(ファイル)という様態で存在し、「探し出される」ための「適正な管理(データベースに格納)」が行われていない状態で放置されていることを指摘した。また、従来のドキュメントが非公開かつ独自仕様の「バイナリ形式」で保存されることが、的確な検索/再利用が行えない要因であったことも指摘した。 的確な検索/再利用を行うためには、まずはファイルフォーマットの「公開性/透明性」が保証されたXML形式で保存される必要があること、ならびにXML形式でドキュメントを作成する場合には、「the 2007 Microsoft Office system(Office 2007)」より提供される「Open XML Formats(Office XML)」を用いることで、エンドユーザは表面上では特に難しいことを意識することなく、従来どおりの使い勝手でXMLドキュメントを作成できることを解説してきた。 |
||||||||||
| ドキュメントをデータベースで管理する | ||||||||||
|
そこで2回目の今回は、従来データベースでの管理に不向きと考えられてきた「ドキュメント(ここではOffice XML)」を管理するために、何が求められるのかについて見て行くこととしたい。 「第1回:ドキュメント管理が変わる〜Office2007がもたらす変化〜」ではデータベースでの管理に適した情報とは、あらかじめ「厳密な構造」として一意に定義された定型情報であることを示した。ところが、今回のテーマであるドキュメント型の情報については、基本的に「章/項/節」のような汎用的な階層構造こそあるが、必ずしもその個々の要素が「一意に定義されている」訳ではない。 このような不確定さを含む情報様態であるドキュメントを、データベース(ここでは一般的なリレーショナル・データベース)に格納する場合、「ドキュメント作成者の情報入力の利便性」を犠牲にするか「ドキュメントの検索性」を犠牲にするかの何らか、もしくは双方の犠牲を伴う必要があった。 例えば前者のケースでは、検索性は高いものの、情報の入力に際し「データベース側の都合」で設けられた制約に準じた「専用の入力ツール」が別途必要となるなど、ドキュメント作成者がWordなどの既存の「使い慣れたツールの利便性」を享受できないといった事態が容易に起こりうる。 他方で、「ファイルをそのままデータベースに格納する方式(BLOB: Binary Large Object)」を採用することで、ドキュメントの作成はWordなどのツールをそのまま利用できるようにはなるが、当該方式で格納された場合、本来の目的である「検索性」が犠牲になるという問題が起こりうる。 |
||||||||||
|
1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||

