JPH0769920B2 - 文書管理処理装置 - Google Patents

Description

【発明の詳細な説明】 〔概要〕 クライアントとサーバとの連携システム等において，サ
ーバ側に論理構造で多数の文書群を管理するデータベー
スを持たせ，マルチメディア対応の文書を自由に扱うこ
とができるようにした文書管理処理装置に関し， 文書または文書要素間の論理的関係を自由に操作し，長
大文書の管理や版数管理，共用管理などの文書の管理を
体系的に行うことができるようにすることを目的とし， 文書または文書要素間の論理的関係を，クラスと，クラ
ス配下の複数のサブクラスと，クラスまたはサブクラス
配下に接続される文書または文書要素に対応するエンテ
ィティとの結び付きからなる木構造の論理構造により管
理する論理構造管理手段と，木構造についての操作を行
う木構造操作手段と，木構造による論理構造を文書また
は文書要素の実際の物理的な格納場所を示す物理構造に
マッピングするための格納構造を管理する格納構造管理
手段とを備えるように構成する。

〔産業上の利用分野〕

本発明は，クライアントとサーバとの連携システム等に
おいて，サーバ側に論理構造で多数の文書群を管理する
データベースを持たせ，マルチメディア対応の文書を自
由に扱うことができるようにした文書管理処理装置に関
する。

計算機システムおける応用分野の多様化により，単なる
数値文字データが格納されたファイルの管理や，プログ
ラムの格納されたファイルの管理だけでなく，テキスト
文書，線画，グラフ，イメージといった各種のメディア
種に応じた文書の管理を柔軟に行うことができる文書管
理システムが，必要とされている。

〔従来の技術〕

第９図は従来の文書管理システムの例，第10図は従来の
文書の管理ファイル構成例を示す。

初期の文書管理システムは，メディア種（テキスト文
書，線画，グラフ，イメージなど）ごとに異なるファイ
ル編成で，複数のファイルと各々のファイルを扱う複数
のプログラムから構成されていた。このようなメディア
種ごとのばらばらな管理では，計算機を使用しない場合
の実際の事務処理における紙ファイルの管理などと全く
異なる管理形態になるため，事務処理の計算機システム
化にスムーズに移行できないなどといった問題があっ
た。

そこで，最近，例えば第９図に示すように，多種類のメ
ディアを格納できるキャビネット61という概念を導入し
た文書管理システムが考えられている。応用プログラム
60は，実際のデータが格納されている媒体の物理構造を
意識することなく，キャビネット61というデータの入れ
物を意識して，文書処理を実行できるようになってい
る。

その外部ビューは，以下のとおりである。

キャビネット61は，オフィスのキャビネットの概念を，
計算機上で実現したもので，この入れ物（保管庫）は，
さらにドロア62a,62bとフォルダ63a〜63cというよう
に，階層化されている。この入れ物の中に格納するデー
タを，オブジェクト65と呼ぶ。

キャビネット61は，文書を構成する多種類のメディアや
従来のプログラム資源も格納できるので，一種のマルチ
メディア格納ファイルともいえる。キャビネット，ドロ
ア，フォルダの３階層から構成される入れ物は，その配
下に格納する他の入れ物やオブジェクトの数を管理する
ディレクトリに相当すると考えてよい。入れ物には，大
きさの概念がある。

オブジェクト65は，実体データの管理や検索のために使
用するメディアに依存しない管理情報66と，メディアに
依存する実体であるメディアデータ67から構成される。
管理情報66およびメディアデータ67は，いずれも標準化
により，ホスト処理装置とワークステーション（WS）間
で持ち回ることが可能である。

キャビネット61に対する操作は，大別すると，検索，入
れ物の操作およびオブジェクト65単位の操作である。検
索については，入れ物の一覧検索（キャビネット一覧→
ドロア一覧→フォルダ一覧→オブジェクト一覧）と，入
れ物内のオブジェクト65の管理情報66による検索が可能
である。入れ物とオブジェクト65の操作は，登録，取り
出し，削除，管理情報の変更，複写，移動，退避，復元
などである。

キャビネット61を実現する内部ビューについては，以下
のとおりである。

オブジェクト65を実際に構成するメディア自身は，非数
値文字データと呼び，これをバイナリデータの塊として
捉えて，その構造に依存しない管理を行う。この非数値
文字データを格納する物理資源は，イメージ格納用ファ
イル69と呼び，磁気ディスク装置70や光ディスク装置71
などの媒体に，このファイルを割り当てる。このイメー
ジ格納用ファイル69に対するアクセス法では，一般のデ
ータ管理とは異なり，レコードの概念がなく，任意デー
タ長での入出力が可能である。

また，入れ物の中には，従来のプログラムソースやプロ
グラムデータなども，一般ファイル72として，組み込む
ことができる。これは，入れ物の単位で，任意のファイ
ルに割り当て可能である。また，入れ物情報やオブジェ
クト65の管理情報66は，キャビネット61単位に割り当て
た管理ファイル68に格納している。

管理ファイル68内の管理データの構成は，第10図（イ）
に示すようになっている。

キャビネット，ドロア，フォルダの各入れ物およびオブ
ジェクトに対応して，それらの属性および配下の入れ物
に対する関係情報を持つキャビネット属性ファイル80,
ドロア属性ファイル81,フォルダ属性ファイル82,文書属
性ファイル83の属性ファイルがある。

例えば第10図（ロ）に示すように，文書本体ファイル84
の割り当ては，キャビネット属性ファイル80中のレコー
ド内に保持されるキャビネット名やパスワードにより，
行われる。

各文書本体85−１〜85−ｎは，文書属性ファイル83中の
属性情報レコードの持つイメージ識別子IIDにより，関
連付けられる。

〔発明が解決しようとする課題〕

キャビネット，ドロア，フォルダという概念を導入した
階層化された入れ物による文書管理により，マルチメデ
ィアの格納や管理が可能になったが，従来方式には，ま
だ次のような問題がある。

応用プログラムが入れ物構造に依存し，容量拡張や入れ
物再編成による構造変化で，プログラムの変更が必要と
なる。

オブジェクトの管理単位は,1つの文書であるため，長大
な文書を複数人で同時に更新できない。

キャビネットの入れ物は,3階層であるため，さらに詳細
な分類を行うことができない。

文書の版数管理や動的に文書同士を関係付けることがで
きない。

本発明は上記問題点の解決を図り，文書または文書要素
間の論理的関係を自由に操作し，長大文書の管理や版数
管理，共用管理などの文書の管理を体系的に行うことが
できるようにすることを目的としている。

〔課題を解決するための手段〕

第１図は本発明の原理説明図である。

第１図において,10はCPUおよびメモリなどを備えたデー
タ処理装置,11は文書または文書要素を管理する木構造
についての操作を行う木構造操作手段,12は論理構造管
理手段,13は格納構造管理手段,14はキャビネット,15a,1
5bはドロア,16は物理構造管理手段,17は磁気ディスク装
置,18は光ディスク装置を表す。

本発明では，文書データと応用プログラムの独立性を強
くし，応用プログラムの生産性を向上するために，文書
ファイルから文書データベースへのアプローチを取る。
そして，第１図に示すように，ユーザビューとして論理
構造を設け，さらに格納構造，物理構造の３階層レイヤ
による文書データベースによって，マルチメディア対応
の文書または文書要素を管理する。

論理構造管理手段12は，クラスC1と，クラス配下の複数
のサブクラスS1〜S10と，クラスまたはサブクラス配下
に接続される文書または文書要素に対応するエンティテ
イE1〜E7との結び付きからなる木構造の論理構造によ
り，文書または文書要素間の論理的関係を表現し，記憶
しておくものである。

クラス全体は，体系化された文書群や構造化された長大
文書に対応づけるもので，クラス自身は，それの代表で
ある。サブクラスは，クラスを構造化するもので，複数
階層を形成することができる。エンティティは，基本的
にデータの実体であり,1文書全体または文書の１要素に
対応する。また，エンティティが実体のある所在情報を
示す場合もある。

格納構造管理手段13は，論理構造が直接的に物理構造の
影響を受けないようにするために導入されたものであ
り，論理構造を物理構造にマッピングするものである。
これには，例えば従来実現してきたキャビネット14の構
成を使用する。論理構造のクラスを，どのようなキャビ
ネット14に割り当てるかは，格納構造定義の中で行う。
これは，メディアの種別やサブクラス単位などで入れ物
を割り当てる。

物理構造管理手段16は，従来実現してきた機能を使用し
て，キャビネット14の入れ物を，磁気ディスク装置17や
光ディスク装置18に設けた物理ファイルにマッピングす
るものである。この定義では，入れ物に対するアクセス
方法，スペース量，アクセス頻度，格納コストなどの入
れ物の特性を考慮して，物理ファイルを定義する。

木構造操作手段11は，論理構造管理手段12が管理する木
構造について，クラス単位またはサブクラス単位で，そ
の作成・更新・削除などの操作を行う処理手段である。

第１図の例では，クラスC1の文書群が,CAB1の名前を持
つキャビネット14に対応づけられており，さらにキャビ
ネット14内に，テキスト文書用の名前がDTEXTであるド
ロア15aと，イメージ文書用の名前がDIMAGEであるドロ
ア15bとが設けられ，ドロア15a内にエンティティE1〜E
4,ドロア15b内にエンティティE5〜E7が収納されるよう
になっている。

キャビネット14などの入れ物に関する格納構造と，物理
構造とのマッピングは，従来の文書管理システムにおけ
る管理と同様である。

〔作用〕

キャビネット，ドロア，フォルダといった概念による階
層化された入れ物による文書データの管理は，従来の一
般的なファイル管理におけるディレクトリの考え方を改
良，発展させたものと考えることができる。本発明で
は，さらにこのファイル構造に依存しない論理構造を，
既存のキャビネット等にアド・オンする形で構築するこ
とにより，文書または文書要素間の論理的関係を，木構
造で表現できるようにしている。

この木構造の表現により，次のようなことが実現可能で
ある。

クラス，サブクラスおよびエンティティには，検索のた
めに数値・文字の項目を設定することができる。このと
き，下位層の項目は，上位層の定義項目を引き継ぐこと
ができる。

エンティティは，複数のクラスやサブクラスから，共用
できる。

クラス，サブクラスおよびエンティティは，複数人から
同時アクセスが可能で，このとき，その各々の単位で排
他制御することができる。

動的にエンティティ同士を関係付けし，新規のサブクラ
スを生成できる。

版数管理のためのクラスを，システムクラスとして用意
し，版数管理の対象となるエンティティを，このクラス
の中で管理することができる。

〔実施例〕

第２図は本発明の一実施例に係る文書データベースの論
理構造の例，第３図は本発明の一実施例による木構造の
管理テーブルの例，第４図は本発明の一実施例による動
的リンク管理テーブルの例，第５図は本発明の一実施例
による版数管理テーブルの例，第６図は本発明の一実施
例による共用管理テーブルの例，第７図は本発明の一実
施例における格納構造を管理するデータ構造の例，第８
図は本発明の一実施例システム構成を示す。

本発明による文書データベースの論理構造は，例えば第
２図に示すような木構造により，管理されるようになっ
ている。第２図において，●はシステムクラスであっ
て，システムが定義するもの，○はクラスまたはサブク
ラスであって，利用者が定義するもの，□はエンティテ
ィであって,1文書の全体または文書の１要素に対応する
ものを表す。エンティティは，基本的にデータの実体で
あり，また，実体のある所在情報を示す場合もある。

クラス，サブクラスおよびエンティティは，各々名前で
識別する。クラス名はシステムで一意，サブクラス名と
エンティティ名はそのクラス内で一意である。これによ
って，サブクラス名は“クラス名．サブクラス名”と，
エンティティ名は“クラス名．エンティティ名”と簡単
に指定することができる。

第２図（ａ）に示すように，あるクラスの配下に，エン
ティティをまとめて，文書同士を関係付けることができ
る。

AAのエンティティは,X.X1.AAでも,Y.Y1.AAでもアクセス
することができ，これは共用文書である。

また，（ｂ）に示すように，クラスＹ全体が１つの文書
として見えるような構造化された長大文書の管理が可能
である。（ｃ）は，クラスＺのもとに，体系化された多
数の文書群を管理する例である。

（ｄ）は，システムクラスＷのもとに，版数管理を行う
例を示しており，文書Ｈに対して，第１版（H.1）と第
２版（H.2）が存在する。文書Ｉも同様である。

本実施例の場合，第２図に示す論理構造を，システム内
部では，リレーショナルデータベースを用いて実現して
いる。そして，論理構造の操作は,SQL言語を利用する。

第３図は，クラスの木構造を管理するリレーショナルデ
ータベースによる部品展開型テーブルの例を示してい
る。第３図に示す例は，第２図に示すクラスＺのサブク
ラスZ2についてのテーブルの構成例である。

この部品展開型テーブルは，システムが固定に用意する
項目と，利用者が指定する項目からなる。システム固定
の項目は，次の意味を持つ。

−「識別名」は，クラス，サブクラスまたはエンティテ
ィのいずれかを示し，システム生成の一意名である。

−「所属名」は，サブクラスまたはエンティティが所属
する識別名である。あるサブクラス配下のすべてのサブ
クラス名やエンティティ名を検索する処理を高速化する
ために，所属名は複数個持つことがある。

−「種別」は，値１がクラス，値２がサブクラス，値３
がエンティティを表す。

−「格納位置」は，各エンティティの格納位置を，入れ
物名で示す。

−「論理名」は，利用者が指定した名前である。サブク
ラス名，エンティティ名は，クラス内で一意である。

利用者が指定する項目１〜項目ｎは，利用者が自由に属
性などを設定できるフィールドであり，キーワードを設
定して検索などにも用いることができる。

クラス，サブクラスまたはエンティティの排他制御は，
「識別名」に対して排他要求を出すことにより行う。こ
の場合，対象となる集合を代表する最上位層のみを排他
することにより，排他性能を向上させることができる。

第４図は，第２図に示す木構造におけるクラスＸの文書
同士を動的にリンクするための動的リンク管理テーブル
の例を示している。この部品展開型テーブルの構成は，
第３図の例と同様である。

関係付けられる文書の元の文書は，常に１つであり，こ
の例では，文書B,C,E,Fが関係付けられた文書である。

第２図に示す版数管理のために用意されたシステムクラ
スＷは，第５図に示すような版数管理テーブルが表され
る。

システムが固定で管理する項目として，第３図に示す部
品展開型テーブルの項目の他に，「版数」および「派生
名」の追加がある。

−「版数」は，版数管理されるエンティティ（文書）の
版数である。

−「派生名」は，当該版数の派生元のエンティティ（文
書）を識別名で示す。

−「種別」の値４は，版数管理されたエンティティ（文
書）を意味する。

共用文書は，第６図に示すような共用管理テーブルによ
って管理される。

同一文書を複数のサブクラス間で共用する場合，実体を
重複しないで保持し，文書アクセス時には，排他制御を
行う。第２図に示す文書AAは，第６図（イ）に示す木構
造の管理テーブルで表される。「種別」の値５は，共用
する文書であることを意味する。この場合，第６図
（ロ）に示す部品展開型テーブルにより，その文書が所
属する複数個のクラスまたはサブクラスを管理する。

第６図（ロ）に示す「識別名」は，共用文書の識別名で
ある。「所属名」は，共用文書の所属するクラスまたは
サブクラスの識別名を表す。

本発明における格納構造は，論理構造が直接的に物理構
造の影響を受けないようにするために導入されている。
これには，従来実現されているキャビネットの構成をそ
のまま使用する。論理構造のクラスをどのようなキャビ
ネットに割り当てるかは，格納構造定義の中で行う。こ
こでは，メディアの種別やサブクラス単位などで入れ物
を割り当てる。

以下，メディアの種別で格納構造を定義する例を述べ
る。

クラスＺには，テキストとイメージデータが混在すると
仮定し，キャビネットCAB1内の入れ物として，テキスト
文書用ドロアDTEXTとイメージ文書用ドロアDIMAGEの２
個用意されているものとする。キャビネットCAB1に格納
されるメディアの種別によって，テキストならば，入れ
物CAB1.DTEXTに格納し，イメージデータならば，入れ物
CAB1.DIMAGEに格納する。

メディアの種別をキーにして，クラスと入れ物を対応付
ける場合，第７図（イ）に示すようなデータ構造で実現
することができる。

一方，サブクラスを直接，入れ物に対応づける場合，第
７図（ロ）に示すようなデータ構造で実現することがで
きる。ここで，各フィールドは，次の意味を持つ。

−「クラス識別名」は，木構造の管理テーブルにおける
識別名である。この識別名によって，論理構造を格納構
造と対応付けることができる。

−「入れ物名」は，キャビネットの入れ物名である。

−「オブジェクト数」は，「入れ物名」で示した入れ物
の大きさで，キャビネットのオブジェクト数で表され
る。

−「オブジェクト種別」は，「入れ物名」で示した入れ
物に格納するメディアの種別である。キャビネット内に
格納するオブジェクト種別で示す。

−「媒体種別」は，「入れ物名」で示した入れ物に割り
当てる媒体特性を示す。

−「保管期間」は，一時，短期，長期の３段階で設定す
る。

物理構造の管理では，従来技術で実現してきたのと同様
に，メディアの特性に適合した物理ファイルを，入れ物
に定義することによって，非数値データ専用のファイ
ル，イメージデータ専用の光ディスク，一般ファイルな
どを選択できるようにする。

以上のような文書データベースが動作するシステムの全
体構成は，例えば第８図に示すようになっている。

第８図において,30はワークステーション（WS）,31は文
書処理を行う応用プログラム,32はクライアントインタ
フェース,40はホスト処理装置,41はモニタ（OS）,42は
文書管理機能を提供する文書管理サーバ,43はSQLインタ
フェース,44はリレーショナルデータベース管理サブシ
ステム,45はキャビネット管理インタフェース,46はキャ
ビネット管理部,47はテキスト検索インタフェース,48は
テキスト検索部,50は本発明に係る文書データベース,51
は構造管理ファイル,52はキャビネット等の入れ物,53は
検索用の単語情報などが格納された検索ファイルを表
す。

ワークステーション30上では，文書を作成，編集，印刷
する応用プログラム31が動作する。クライアントインタ
フェース32は，応用プログラム31に対して，文書データ
ベース50のアクセスインタフェース（）を提供する。

クライアントが，文書データベース50のアクセスを依頼
すると，ホスト処理装置50は，文書管理サーバ42によっ
て，文書データベース50をアクセスして，結果を応答す
る。これを，依頼と応答のプロトコル（）と呼ぶ。

これまでの文書管理システムを発展させて，文書データ
ベースシステムとするため，ホスト処理装置40側に文書
データベースの論理構造を実現する構造管理ファイル51
とテキスト検索を実現する検索ファイル53を用意する。
構造管理ファイル51には，第３図ないし第７図で説明し
たような論理構造および格納構造を管理するための部品
展開型テーブルが格納されている。

文書管理サーバ42は，文書データベース50のアクセス法
として,SQLインタフェース43,キャビネット管理インタ
フェース45,テキスト検索インタフェース47を使用す
る。なお，テキスト検索インタフェース47,テキスト検
索部48,検索ファイル53は，なくてもよい。

特に，文書管理サーバ42は，構造管理ファイル51に格納
された木構造の論理構造に関する管理情報について，ク
ラス単位またはサブクラス単位での作成・更新・削除・
複写・移動・分離・結合などの操作処理機能を持つ。こ
の処理の詳細については，周知のSQL言語によるテーブ
ル操作機能で容易に実現できるので，これ以上の説明を
省略する。

階層検索の場合，例えば次のような処理となる。第２図
に示す木構造のクラスＺのサブクラスZ2の次の階層一覧
を求めるものとする。以下の，，は，第８図に示
す〜のインタフェースに対応する。

応用プログラムの記述 次のようなsearch関数は，クライアントが用意するイン
タフェースである。

ret＝search（＆result,“Z.Z2",“NEXT", “CREATEDATE＞＝19890801"） ret:処理の復帰コード ＆result:一覧結果の返却域 “Z.Z2":階層名の指定 “NEXT":階層検索の指示 “CREATEDATE＞＝19890801":管理情報による検索の指示
（作成日が1989年08年01日以降）。

依頼プロトコル 回線上のデータストリームは，以下のとおりである。

SQL文に展開し，部品展開型テーブルを検索する。

応答プロトコル 回線上のデータストリームは，以下のとおりである。

復帰コード・集合名・検索件数・階層一覧情報の並びで
ある。

応用プログラム retに復帰コード0,＆resultに集合名・検索件数・階層
一覧情報の検索結果が返却される。

〔発明の効果〕

ホスト・ワークステーション連携システムにおいて，現
在の実用レベルの文書処理は，個人のオフィスワーカの
利用が中心であり，扱う文書も少量で共用性も低い場合
が多い。しかしながら，今後は，オフィスだけでなく，
研究開発部門や設計・製造部門にも，文書処理が適用さ
れてくることが予想される。この分野では，少量文書を
扱うオフィス分野とは異なり，長大文書や多数文書群を
扱うことが多いと考えられる。長大文書は，複数人が共
同で作成する論理的にひとまとまりの文書で，例えば製
品のマニュアルなどである。長大文書は，構造化されて
おり，この構造の最小単位での操作が，長大文書の管理
機能として要求される。また，多数文書群は，組織内で
運用している各種の規格文書の集合のようなもので，組
織の多部門で作成される文書を体系的に管理することが
必要とされる。

本発明によれば，このような要求に応ずることができる
ようになり，クライアント／サーバ型のシステムなどに
適用して，文書管理における新しいニーズを満たす環境
を実現することが可能になる。

【図面の簡単な説明】

第１図は本発明の原理説明図， 第２図は本発明の一実施例に係る文書データベースの論
理構造の例， 第３図は本発明の一実施例による木構造の管理テーブル
の例， 第４図は本発明の一実施例による動的リンク管理テーブ
ルの例， 第５図は本発明の一実施例による版数管理テーブルの
例， 第６図は本発明の一実施例による共用管理テーブルの
例， 第７図は本発明の一実施例における格納構造を管理する
データ構造の例， 第８図は本発明の一実施例システム構成， 第９図は従来の文書管理システムの例， 第10図は従来の文書の管理ファイル構成例を示す。 図中,10はデータ処理装置,11は木構造操作手段,12は論
理構造管理手段,13は格納構造管理手段,14はキャビネッ
ト,15a,15bはドロア,16は物理構造管理手段,17は磁気デ
ィスク装置,18は光ディスク装置を表す。

Claims (2)

【特許請求の範囲】
1. 【請求項１】複数階層の入れ物により，複数の文書を管
   理する機能を有するデータ処理システムにおける文書管
   理処理装置であって， 複数の文書または文書要素間の論理的関係を，クラス
   と，クラス配下の複数のサブクラスと，クラスまたはサ
   ブクラス配下に接続される文書または文書要素に対応す
   るエンティティとの結び付きからなる木構造の論理構造
   により管理する論理構造管理手段と， 上記木構造について，少なくとも作成・更新・削除を含
   む操作を行う木構造操作手段と， 上記木構造による論理構造を文書または文書要素の実際
   の物理的な格納場所を示す物理構造にマッピングするた
   めの格納構造を管理する格納構造管理手段とを備えた ことを特徴とする文書管理処理装置。
2. 【請求項２】文書または文書要素の実際の物理的な記憶
   媒体における格納場所を管理する物理構造管理手段を備
   えた ことを特徴とする特許請求の範囲第１項記載の文書管理
   処理装置。