JP2002175297A - Ｘｍｌを用いた情報資源管理方法及びシステム、コンピュータプログラム製品 - Google Patents

Abstract

(57)【要約】 【課題】 複数種類の情報資源を統合管理するととも
に、情報内容を閲覧する者の操作上の便宜を図ることが
できる情報資源管理システムを実現する。 【解決手段】 複数種類のプラットホームで広範囲に発
生する複数種類の情報資源に、その管理目的に応じた任
意の情報を定義し、このＸＭＬタグで情報資源を括っ
て、ＸＭＬデータベースＤＢに集中的に格納する。情報
要求があった場合は、ＸＭＬデータベース内の情報資源
をＸＭＬタグで定義した情報を通じて読み出し、読み出
した情報資源の内容を要求元のデータ端末ＤＴのブラウ
ザ宛に統一形式で出力する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、企業内又は異なる
企業間において広範囲に発生する複数種類の情報資源を
統合してこれを一元管理する情報資源の管理技術に関す
る。本明細書にいう「管理」とは、目的に応じた情報資
源の加工、編集、格納容器への格納及びその読み出し、
出力に関する一連の処理作業をいう。

【０００２】

【発明の背景】企業等で作成される資源には、ドキュメ
ント、システム設計書、モデル図、イメージ図、フロー
チャート、ＪＯＢ、ロードモジュール、プログラムソー
ス、データベース、ファイル等がある。企業でこれらの
資源が作成された場合、その資源がどこに格納されてい
るか、格納されている資源の種類はどの位あるか、それ
はどんな容器に格納されているか、容器の大きさはどの
位か、資源及び容器の名称は何か、他のどのようなもの
と関連があるか、・・・・のように、当該資源に付随す
る情報も種々発生する。このような情報は、情報資源
（論理的な資源）と捉えることができる。

【０００３】情報資源の中には、実際には、目に見え
ず、手に触れることもできないが、誰もがそれを必要と
認知できる概念的な資源がある。例えば企業の業務を分
析したとき、それをイメージとして作成するモデル図等
は情報資源である。このような情報資源は企業の資産で
あり、これを有効に活用できるかどうかは、企業の活動
基盤を支える上で重要である。

【０００４】情報資源をコンピュータを用いて管理する
システムは、従来より存在していた。しかし、実際に管
理できる情報資源の多くは、当該管理システムを実現す
るコンピュータの枠に限定される。ここで挙げるコンピ
ュータとは、メインフレーム（Mainframe）と呼ばれる
大型の汎用コンピュータや、クライアントサーバ（Clie
nt Server）と呼ばれる比較的汎用的な高性能のコンピ
ュータを指す。

【０００５】情報資源として管理対象となるものは、メ
タデータ（Metadata）が中心となる。メタデータには、
コンピュータシステムで処理されるデータに関するデー
タ系のメタデータと、プロセス系のメタデータとがあ
る。データ系のメタデータは、以下のようなものであ
る。例えば従業員データベースがあり、その中で「社員
番号」という項目があるとすると、社員番号は、当該企
業の中で社員を一意に認識するための番号であり、その
桁数が何桁でどのように表すかという属性の情報をも
つ。また、企業のどのような分類の労働者に対して、ど
のように採番されるのか、コンピュータ上でどのように
処理されるのかというルールをもつ。このような「社員
番号」という項目に対する情報は、企業の中でただ１つ
であり、人によってそのルールが異なったり、無闇に変
更されたりすることはない。従業員データベースにおい
て「社員番号」が対象となる項目に着目すると、この
「社員番号」には、定められたルールに従って採番され
た社員の番号が入る。桁数が５桁で、採番のルールが西
暦下２桁＋連番であったとすると、最大９９９人用の
「社員番号」には、西暦２０００年の場合には「０００
０１」から「００９９９」までの値が入る。このよう
に、実際に取り得る値を実現値（「インスタンス」）と
呼ぶ。これに対し、社員番号というデータに対する意味
や属性・桁数・ルールなどの定義体がメタデータであ
る。インスタンスの範囲は広範囲であるが、メタデータ
は、その企業の中で１つとなる。

【０００６】プロセス系のメタデータは、例えば、ある
処理を機械的に行わせるプログラムが、どんな実行サイ
クルで運用されるのか、日次・随時・週次・月次なの
か、どんなプログラミング言語で作成されており、どの
ようなデータベースやファイルを参照し、更新、出力し
ているのか、そのプログラムのありかはどこで、どのよ
うな容器に格納されているか等である。

【０００７】インスタンスは大量に存在し、目的別や処
理速度を考慮して分散したり、集合させておく必要があ
る。そのため、通常は、データベースという格納容器に
格納されて、コンピュータの中で、一定のルールに沿っ
て処理される。メタデータも、データベースほどのデー
タ量ではないにしても、何らかの格納容器に格納するこ
とが必要である。何故ならば、メタデータを人間が常に
間違い無く記憶しておけるという保証はないし、実際に
企業の人事異動なども考慮した場合には、人間に依存し
てメタデータの把握をさせるのではなく、何らかの技術
的手段で格納して、それを多くの利用者に公開（閲覧）
させるべきだからである。

【０００８】メタデータの公開や格納の際の処理速度
は、実際の業務処理速度までは要求されない。しかし、
速いにこしたことはないし、できるだけ運用コストが押
さえられることが望ましい。何故ならば、メタデータを
何処かで管理して、利用者に公開し、企業等で共有すべ
き情報として知らしめることで、例えば、共通の定めら
れたルールを元に、開発担当者はプログラムの処理を記
述したり、システムのデータ入力画面や出力帳票の項目
をコーディングするなど、活用することが可能になるた
めである。また、それらの共有された部品を使用して構
築されたシステムは、部品を通じて影響分析作業が行い
やすく、実際のメンテナンス作業にも役立てることも期
待できるからである。

【０００９】メタデータの格納容器は、インスタンスと
同様、データベースとすることができる。つまり、メタ
データ専用の構造を設計して格納することができる。最
近は、「リポジトリ」と呼ばれる格納容器が使用される
場合もある。

【００１０】従来、多くの企業では、メタデータのよう
な情報を管理するためのシステムを既存の製品の中から
自由に選択することはできなかった。これは、製品とし
ての管理システムの設計思想が、それぞれ既定の方法論
に縛られていることが主たる原因となっている。方法論
の中には、処理されるデータに着目して、その振る舞い
やルールを分析し、そこからシステム化を図る「データ
中心アプローチ」と呼ばれるものと、処理（プロセス）
に注目したシステム化を図る「プロセス中心アプロー
チ」と呼ばれるものとがあり、これらの中でも、さらに
様々な論理に分かれる。最近は、「オブジェクト中心ア
プローチ」と呼ばれる方法論も登場している。

【００１１】方法論を限定していない管理システムは、
そのまま使用することはできない。何故なら、企業がど
のようなデータ又はプロセスを管理対象とし、これらか
ら何の目的で、どのような効果を狙うのかという、戦略
から掘り下げた、詳細な目標を定めなければ、格納容器
の構造を決めることができないからである。このような
掘り下げにはかなりの時間を必要とし、専門のコンサル
タントなどの知識を必要とするので、企業は、そのため
にかなりの投資をしなければならなかった。また、従来
の管理システムは、後で企業文化にカスタマイズされる
ことを想定としているため、特定の企業のニーズに適合
したユーザインタフェース（画面）は用意されていな
い、もしくは、用意されていても、企業の要求に応えら
れない場合が多かった。

【００１２】格納容器にも、メインフレームやクライア
ントサーバ等によって、文字コードの違いやメーカ別の
制限がある。また、格納容器への格納は、通常は、文字
ベースに変換して行う必要があるため、面倒で時間がか
かるうえに、文字ベースに変換できない画像等は管理で
きなかった。そのため、情報資源を管理するシステムで
ありながら、実際には、部分的な情報資源の管理に留ま
り、広範囲な情報資源の管理ができなかった。格納容器
の構造を仮に統一できたとしても、その運用を維持する
ことは難しい。上述のように、運用に際しては、利用者
に使用ルールを守らせて、格納容器に格納するためのユ
ーザインタフェース（画面）を作成し、使用させる方法
を用いる企業が殆どであるが、従来は、その作成に膨大
な時間を費やしていた。これらの方法論にとらわれない
自由度の高い管理システムでは、実際に格納作業を着手
するまでに期間がかかっていた。また、企業で企業文化
に沿った管理システムの周辺部分をプログラムなどで作
りこんだ場合、その容器本体のバージョンアップの影響
を受け、この資源管理システムの維持やメンテナンスに
従事する部門の負荷が増大する。そもそも資源管理に対
する工数削減や、運用支援等に用意した格納容器や管理
システムであるのに、それを維持するためのコストが増
加するという相反する状況を招くケースも少なくはなか
った。

【００１３】さらに、データ系のメタデータの場合、管
理対象となるデータとして、手書きのドキュメントや設
計書、イメージ図、モデル図を、文字ベースに変換し、
これを容器に格納することは不可能ではないが、かなり
困難な作業を要する。このようなデータを管理する場合
には、一つ一つ手入力でデータの格納を行わなければな
らないので、データ格納に要する時間や労力が多大にな
る問題があった。反面、クライアントサーバ側には、手
書きのドキュメントや設計書・イメージ図・モデル図を
格納できる管理システムはあるものの、ドキュメントは
ドキュメントのみの単体が管理対象であり、モデル図等
は、論理や開発の手法に限定されていた。

【００１４】つまり、従来の管理システムは、各々のデ
ータやプロセスが存在する環境や、限定され範囲での管
理しかできないでいた。

【００１５】さらに、従来の管理システムには、メタデ
ータとドキュメントとを紐付けて、統合管理できるよう
なものは存在しなかった。つまり、メタデータが他のシ
ステムに存するドキュメントとどのように関連している
のかという、当該管理システム内だけではない他の管理
システムとの関連を定義することはできなかった。これ
は、従来の管理システムは、他社製品や独自に作成され
た他の管理システムとの共存や連携を考慮していないこ
とが主たる原因である。そのため、管理システムでは、
その中に格納されるメタデータの関連を捉えると表現し
ながらも、あるデータ項目からそれを使用するシステム
までの縦階層の構造の考慮にとどまっていた。このよう
な縦階層の構造の管理システムでは企業内での業務シス
テムに限定された関連は把握できても、システム間や企
業間で共通する横の繋がりを捕らえることができない。
結局、メタデータの関連は、そのメタデータが格納され
る製品の範囲に自ずと限定される。

【００１６】また、メインフレームに存在している格納
容器を用いて管理する場合、メインフレームのものとは
異なるＯＳ（オペレーティングシステム）を搭載した装
置側からメタデータを得ようとするときは、エミュレー
タというテクノロジーを使用しなければならないし、勿
論、メインフレームでの操作手続きを知らなければ操作
することもできなかった。

【００１７】企業内で管理している情報資源を利用者に
公開する場合、従来の管理システムでは、広範囲に公開
しようとすればするほど、費用もかかり、かつ、利用者
に対する操作方法の指導や、実際の使用に関する監視な
どに、人員が多く必要とされる。このように、企業内で
発生する情報資源の管理を支援する技術であるべき「資
源管理」は、部分的な資源管理に留まってしまったため
に、経営者からすると投資に対する効果を認識すること
ができなかった。統合した情報資源の管理ができないた
めに、利用者は、それぞれの管理システムが存在してい
る場所別に、操作方法や格納ルールを学習、記憶しなけ
ればならなかった。利用者はその煩わしさから、システ
ム離れの傾向を示したりするようになり、点在管理され
た情報は、有効活用されにくかった。

【００１８】既存の管理システムや製品に対して限界を
感じて、企業の既存のデータベースを基盤とし、理想の
統合管理できる格納容器を作成したとしても、管理シス
テム内に対象としたい資源は後になって増加したり、不
用になったりと拡張要求が高いために、その要求に応じ
て追従させることが、技術的にも、対応するマンパワー
的にも殆ど不可能であった。実際には、企業の中には、
管理システムだらけ、格納容器だらけ、製品だらけとい
う現状が起こっていた。

【００１９】本発明は、上記のような背景に鑑み、広範
囲な情報資源を統合的に管理するための情報資源管理技
術を提供することを主たる課題とする。

【００２０】

【課題を解決するための手段】本発明は、情報資源、例
えばプロセス系又はデータ系のメタデータの格納容器と
してＸＭＬ（eXtensible Markup Language）データベ
ースを使用し、複数種類のプラットホームで広範囲に発
生する複数種類の情報資源をＸＭＬデータベースで統合
的に格納し、これを情報要求者のブラウザ宛に統一形式
で出力する、ＸＭＬを用いた情報資源管理方法を提供す
ることにより、上記課題の解決を図る。

【００２１】ＸＭＬは、HTML（Hypertext Markup Langu
age）のような、定義内容が決まった固定的なタグを使
うマークアップ言語ではなく、その内容を任意に定義す
ることができるタグ（「ＸＭＬタグ」）を使う拡張型マ
ークアップ言語である。本発明では、ＸＭＬタグに、情
報資源の管理目的に応じた任意の情報を定義し、このＸ
ＭＬタグで当該情報資源を括って、ＸＭＬデータベース
に集中的に格納する。情報要求があった場合は、ＸＭＬ
データベース内の情報資源をＸＭＬタグで定義した情報
を通じて読み出し、読み出した情報資源の内容を要求元
のブラウザ宛に統一形式で出力する。

【００２２】これにより、情報資源の種類、その存在環
境等に拘束されない統合的な情報管理が可能になる。Ｘ
ＭＬデータベースは、拡張性が高く、このデータベース
の中に格納された情報をＸＭＬ形式にして、外部出力す
ることで、他の製品やＸＭＬデータベース同士の情報の
受け渡しが容易となる。また、情報資源をシステム同士
でやり取りでき、しかも変換にあたって失われるものが
何もないため、今までなかったようなアプリケーション
の可能性が広がる。例えば、従来は単体で目的別に管理
していたドキュメントや設計書・フロー・イメージ図・
モデル図と、システムのメタデータとを統一した形態
で、しかも、それぞれの関連を紐付て格納しておくこと
が可能になるので、異なるプラットホーム間で情報を共
有することが容易になる。

【００２３】情報資源をＸＭＬタグで括って格納するた
め、ＸＭＬデータベースに格納するプログラムの概念や
設計は、従来に比べて簡単、完結であり、拡張要求を受
け入れた場合の変更も容易となる。これらのＸＭＬデー
タベースと情報資源を格納するためのプログラムを合わ
せてテンプレートとし、この情報資源管理システムを必
要とする利用者に提供することで、各々の利用者によっ
て自由かつ簡単に拡張することが可能である。また、従
来は、不可能であった、メインフレームのみに存する管
理システム内の情報資源と他のデータベースに格納され
ている情報資源とのリアルタイムな連携が可能となる。
これによって、既存のシステムとその管理対象が異なっ
ていても、連携作用によって、相互に検索したい情報を
受け渡しながら検索することが可能となる。なお、ＸＭ
Ｌデータベースは、内部に格納したデータをＸＭＬ形式
で渡すことができるので、ＸＭＬデータベース同士での
情報のやりとりだけでなく、Ｗ３Ｃの標準から世の中の
製品にはＸＭＬに対応する準備がどんどん用意されてく
るので、その分、連携も容易となってくることが予想さ
れる。

【００２４】ＸＭＬデータベースに格納する情報資源の
種類を拡張したい場合は、ＸＭＬタグの種類を増やすこ
とで、容易に対応することが可能である。

【００２５】ＸＭＬタグに定義する情報としては、以下
のものが挙げられる。 ・収容容器の構造、及び／又は、当該格納容器内の格納
領域の使用ルールを含む属性 ・マークアップを構成する要素の出現回数、及び／又
は、出現順序 ・一の情報資源に関連する他の情報資源又は電子情報と
の間の縦横関係 ＸＭＬタグに定義した情報の一部又は全部は、それをキ
ーワードに指定することでキーワード検索の対象にする
ことができる。以上のように定義することで、格納容器
に格納されている情報資源を検索する際に、ＸＱＬ（Ｘ
ＭＬデータベースの中に格納された電子情報を問い合わ
せる言語）を実行するだけで、簡単に結果を取得するこ
とができるようになる。

【００２６】本発明は、情報資源管理システム及びコン
ピュータプログラム製品として実施することも可能であ
る。情報資源管理システムは、複数種類のプラットホー
ムのいずれかに存在し管理目的に応じて任意に定義され
たＸＭＬタグで括られている情報資源の入力を受け付け
る受付手段と、受け付けた各情報資源を集中的に格納す
るためのＸＭＬデータベースと、要求に応じてＸＭＬデ
ータベース内の情報資源を前記ＸＭＬタグに定義された
情報を通じて読み出し、読み出した情報資源を要求元に
統一形式で出力させる出力制御手段とを備えてなるもの
である。

【００２７】前記受付手段は、通常、プロセス系のメタ
データ及び／又はデータ系のメタデータを情報資源とし
て受け付けるように構成される。この場合、ＸＭＬデー
タベースは、プロセス系のメタデータとその縦階層の関
連情報を格納するための第１の構造、データ系のメタデ
ータとその縦階層の関連情報を格納するための第２の構
造、第１及び第２構造とは独立した横階層の構造であっ
てデータ系及びプロセス系のメタデータに関連するドキ
ュメントを格納するための第３の構造、メタデータ間を
横階層で紐付けるための第４の構造の少なくとも１つの
構造を有するように構成される。前記第４の構造は、例
えば、プロセス系のメタデータ間、データ系のメタデー
タ間、プロセス系及びデータ系のメタデータ間を、横階
層で紐付けるようにしてなる。

【００２８】上記のようにＸＭＬという共通の形式でメ
タデータ等を管理するので、情報資源管理システムと既
存の管理システムの管理対象が異なっていても、連携作
用によって、相互に検索したい情報をやり取りして検索
することも可能となる。他のシステムについても可能な
限り、利用者が管理対象としたい情報を格納できるよう
にしているので、利用者が管理対象と考える全ての情報
に対して、存在場所や理論・手法にこだわらずに統合的
な情報と資源の管理が実現できる。勿論、この他製品に
は、情報資源管理だけではなく、データウェアハウス
（Data Warehouse）をするときに、利用者のシステムの
データベースからダウンロードする実際のデータをどこ
のデータベースに格納するかのマッピング情報として使
用させたり、利用者のシステムを連携する際の、各々の
データ受け渡しを定義する情報として、活用させること
ができる。

【００２９】本発明の情報資源管理システムでは、スタ
イルシートを利用できるようにする。すなわち、ＸＭＬ
データベースに格納されたデータ自身は、それをどのよ
うに表示させるかの情報は持っていないので、利用者
が、必要な情報を取り出したり、表組みとしてレイアウ
トしたり等、どのように見せるかを指定するためにスタ
イルシートを利用できるようにする。このスタイルシー
トを用いることで、利用者の要求に応じたデータを簡単
に表現できるようになる。

【００３０】従来の管理システムでは、情報を格納する
ためには手作業が必要になり、作業負荷が大きかった。
これに対し、本発明の情報資源管理システムでは、取り
こめる情報はなるべく機械的に行い、人間が判断しなけ
ればならない部分のみを手入力とすることができるた
め、広範囲に情報資源を取り込むことができる。例え
ば、メインフレームのＣＯＢＯＬというプログラミング
言語で記述されたシステムで、それらの記述がどの管理
システムにも格納されていない場合は、ＣＯＢＯＬのプ
ログラムソースを読みこんで、その中で使用されている
データ項目やファイルの構成等を格納することができ
る。

【００３１】より好ましい実施の形態では、外部情報処
理システムに存在する情報資源をＴＣＰ／ＩＰを通じて
取り込む手段と、外部情報処理システムから取り込んだ
情報資源及び自システムにおいて発生した情報資源に前
記ＸＭＬタグを埋め込む編集手段と、上記のスタイルシ
ートを保持する手段と、上記のテンプレートを保持する
手段と、スタイルシート又はテンプレートを選択的に読
み出す手段とをさらに備えて情報資源管理システムを構
成する。

【００３２】本発明のコンピュータプログラム製品は、
複数種類の情報資源の各々をその管理目的に応じて任意
に定義したＸＭＬタグで括る処理、各情報資源を前記Ｘ
ＭＬタグと共にコンピュータ読みとり可能な格納容器に
集中的に格納する処理、要求された前記格納容器内の情
報資源を前記ＸＭＬタグで定義した情報を通じて読み出
す処理、読み出した情報資源の内容を要求元のブラウザ
宛に統一形式で出力する処理をコンピュータに実行させ
るためのプログラムが記録されたものである。

【００３３】

【発明の実施の形態】図１は、本発明を適用した情報資
源管理システムの構成図である。この情報資源管理シス
テム１は、Ｗｅｂブラウザと繋げることができるオペレ
ーティングシステムを搭載したコンピュータ本体２と、
本発明のコンピュータプログラム製品３とによって実現
することができる。コンピュータ本体２は、ＣＰＵ、Ｒ
ＡＭ、ＲＯＭを搭載した処理装置２１を備え、さらに、
キーボード、マウス、ディスクドライブ等の入力装置２
２、半導体メモリやハードディスク装置等の記憶装置２
３、ディスプレイやプリンタ等の出力装置２４、通信制
御機構２５と接続可能なものである。通信制御機構２５
は、Ｗｅｂブラウザを搭載した各種データ端末ＤＴとの
間でネットワーク回線Ｌを介して行われる双方向通信を
制御するものである。

【００３４】本実施形態では、ユーザインタフェース
（画面）はＷｅｂブラウザを基本とする。そのため、デ
ータ端末ＤＴに対して、Ｗｅｂブラウザ機能を搭載した
ＩＥ（インターネットエクスプローラ：マイクロソフト
社の商標）を使用する環境を提供することができる。こ
れにより、管理された情報資源の内容を広範囲に、簡単
に公開可能となり、利用者も、統一的な操作によってそ
の情報を簡単に取得できるようになるので、従来のよう
な本システムを利用する際の訓練を行う必要もなくな
る。

【００３５】本実施形態では、コンピュータ本体のＣＰ
Ｕが、コンピュータプログラム製品３の一例である可搬
性記録媒体又は上記のＲＯＭに記録されているプログラ
ム、あるいは図示しないプログラムサーバから読み込ん
だプログラムによって、記憶装置にＸＭＬデータベース
ＤＢを構築するとともに、処理装置２１においてＸＭＬ
データベースＤＢを基盤とした情報資源管理に関する諸
機能を形成する。

【００３６】本実施形態により形成される機能は、図２
に示されるようなものである。すなわち、本実施形態の
情報資源管理システム１は、通信制御部１１、情報受付
処理部１２、編集処理部１３、スタイルシート管理部１
４、テンプレート管理部１５、ツール管理部１６、出力
制御部１７の機能を備えて構成される。

【００３７】通信制御部１１は、データ端末ＤＴその他
の外部情報処理システムとの間で、ＴＣＰ／ＩＰのネッ
トワーク回線Ｌを通じて相互に存する情報をメッセージ
として行き来させる。メインフレームとクライアントサ
ーバのようにＯＳが異なる場合、従来は、ファイル転送
という機能を使用して情報の受け渡しを行うとともに、
メインフレームやクライアントサーバに対してその命令
を実行させる作業を手で入力して行ってきた。このよう
な手法は、定期的な情報の受け渡しならば、さして支障
はないが、随時の受け渡しの場合には手間がかかり、利
用者にとって簡単な手段ではなかった。そこで、情報資
源管理システム１では、通信制御部１１を通じて情報を
メッセージとして行き来させることにより、これを解決
する。この場合の情報は、文字データ、画像データ、手
書データ、音データ及びこれらの組み合わせである。

【００３８】情報受付処理部１２は、管理目的に応じて
任意に定義されたＸＭＬタグで括られている情報資源の
入力を受け付ける。情報資源は、プロセス系のメタデー
タ、データ系のメタデータ、各種ドキュメントを含む電
子情報である。

【００３９】編集処理部１３は、外部情報処理システム
から取り込んだ情報資源及び自システムにおいて発生し
た情報資源のうち、管理目的に応じて既に定義されたＸ
ＭＬタグが埋め込まれているものについては、必要に応
じてその内容を編集し、ＸＭＬタグが埋め込まれていな
いものについては、ＸＭＬタグを定義するとともに管理
対象となる情報資源の部分をＸＭＬタグで括る処理を行
う。ＸＭＬタグの定義のうち、情報構造にはDTD（Docum
ent Type Definition）を用いることができる。ＤＴＤ
は、人間が共通な認識のもとに正しい意味を理解した
り、プロセスを行わせるためにどのような要素をどのよ
うな規則でマークアップするかを明らかにするファイル
構造定義情報である。なお、ＤＴＤを用いてＸＭＬタグ
を定義するパターンとしては、既存のＤＴＤを活用する
パターン、既存のＤＴＤを一部変更するパターン、新規
にＤＴＤを設計するパターンの３パターンがあり、目的
に応じて使い分ける。

【００４０】図３は、データ項目及びその属性を表現す
るDTDの構造例を示した図である。図中、「＃ＲＥＱ」
は必須の項目であることを示す文字、「？」は０回もし
くは１回に限り出現する項目であることを示す文字、
「＊」は０回以上任意に出現する項目であることを示す
文字である。この図３の構造のＤＴＤを記述した例が図
４である。編集処理部１３では、このような記述をも行
うようになっている。なお、外部から取り込んだ情報
に、既にＸＭＬタグが埋め込まれていて、編集処理も必
要ない場合は、ここでの処理はパスされる。

【００４１】スタイルシート管理部１４は、スタイルシ
ートを作成して保持するとともに、それを利用する際
に、複数のスタイルシートのいずれかを選択的に読み出
す。利用する度に作成してそれを使用することもでき
る。スタイルシートは、XSL (eXtensible Style Langua
ge) を使って作成する。通常は、XMLファイル作成者に
よって作成するが、ブラウザ側での再定義も可能であ
る。例えば図５のようなＸＭＬファイルがあったとす
る。これは、ある企業の従業員データベース（ＸＭＬデ
ータベース）内に格納される「従業員ファイル」であ
る。カナ名称では「＜ＫＡＮＡ＞ジュウギョウインファ
イル＜／ＫＡＮＡ＞」、漢字名称では「＜ＫＡＮＪＩ＞
従業員ファイル＜／ＫＡＮＪＩ＞」というように、ＸＭ
Ｌタグで括って格納されている。このようなファイルの
内容に対応するスタイルシートは、図６のようになる。
このスタイルシートによって出力装置２４（ディスプレ
イ）には、図７のような画面が表示される。

【００４２】テンプレート管理部１５は、テンプレート
を保持するものである。ツール管理部１６は、スタイル
シート又はテンプレートを選択的に読み出す。

【００４３】出力制御部１７は、要求に応じてＸＭＬデ
ータベースＤＢ内の情報資源をＸＭＬタグに定義された
情報を通じて読み出し、読み出した情報資源を要求元に
統一形式で出力させる。

【００４４】図８は、ＸＭＬデータベースＤＢの構造例
を示した図である。本実施形態では、既存の管理システ
ムの基盤や環境の違い、企業内にとどまらない企業間と
の情報資源の連携を考慮して、従来の縦階層構造に依存
した管理構造だけでなく、横階層の繋がりを実現させる
ための構造をあわせたデータベース構造とする。具体的
には、図５に示されるように、受け付けた複数種類の情
報資源（ＸＭＬタグが埋め込まれたもの）を階層的な構
造に分割して格納できるようにする。分割部分をコレク
ションと呼ぶ。また、コレクションの下位層に関連付け
られた「SYSTEM・PROGRAM・MODULE」、「FILE・GROUP・ITE
M」、「DOCUMENT」、「CLIP」をそれぞれドキュメント
タイプと呼ぶ。

【００４５】＜コレクションの構造＞「PROCESS-HIERAR
CHY」コレクションは、プロセス系のメタデータとその
縦階層の関連情報を格納するための構造であり、「DATA
-HIERARCHY」コレクションは、業務システムのデータ系
のメタデータとその縦階層の関連情報を格納する構造で
ある。これらの２つのコレンクションを分割したのは、
次のような要求に応じるためである。

【００４６】・既に管理システムが存在し、プロセス系
・データ系どちらかの情報だけをこの統合資源管理シス
テムに格納し、相互を連携させたい。 ・新しく情報資源管理システムにメタデータを格納した
いが、これをデータ系・プロセス系のどちらかだけに重
点をおいて管理させたい。

【００４７】このような要求に柔軟に対応できるように
するため、情報資源管理システム１では、縦階層の構造
を、「PROCESS-HIERARCHY」コレクションと、「DATA-HI
ERARCHY」コレクションとに分割させている。

【００４８】「DOCUMENNT-HIERARCHY」コレクション
は、データ系及びプロセス系のメタデータに関連するド
キュメントについての情報を格納させるために採用され
る。このコレクションをデータ系・プロセス系の構造か
ら分離させて独立させたのは、以下の現状を考慮したた
めである。

【００４９】・メタデータとドキュメントの関連を紐付
けて格納できる管理システムは、現在のところ存在しな
い。何故ならば、これまでの資源管理では、情報の縦階
層の関連には強くても、メタデータとドキュメントのよ
うな横の繋がりは考慮されていないからである。 ・メタデータとドキュメントを関連させて管理させる場
合、１メタデータの定義内に関連するドキュメントを取
り込んでしまうと、大量に格納されるメタデータ全てに
対して、人間がドキュメント情報を入力するか、複雑な
プログラムを作成して、メタデータとドキュメントをつ
き合わせて格納させる必要が生じる。このような構造
は、メタデータやドキュメントの改定時の反映を複雑に
させ、かつ、複雑なプログラムのメンテナンス工数を増
加させる。本実施形態の情報資源管理システムでは、そ
のような煩雑な手法は選択しない。可能な限り機械的に
情報を格納させ、相互の情報は人間の判断によって関連
性を定義させることで、解決させている。

【００５０】「CLIP-HIERARCHY」コレクションは、従来
は基本的に考慮されていなかった、データ系・プロセス
系・ドキュメントとは異なった構造である。このコレン
クションでは、メタデータの種類や関連するドキュメン
トとの繋がりではなく、それぞれの情報を紐付ける（Ｃ
ＬＩＰ）構造である。例えば、Ａ社とＢ社という企業が
業務提携や合併したと仮定する。どちらにもごく一般的
に、基幹系の業務システムや同業種であれば、同じよう
な業種に沿ったシステムが既に構築運用されているはず
である。これらの既存のシステムは、そもそも同じ種
類、例えば、経理や営業支援、物流などのシステムであ
るにも関わらず、Ａ社・Ｂ社で呼び方も異なれば、それ
を動かすプログラムの言語も異なり、そのプログラムを
構成するファイルやデータ項目の記述方法も異なってい
ることが十分考えられる。

【００５１】両者の今後の事業展開を検討する経営者か
らすれば、例えば「受注」についての関連する情報を一
まとめにして得たいと要求していることを想定してみよ
う。「受注」がプログラム内では「JYU」と記述されて
いても、「JYUCYU-KINGAKU」と記述されていても、その
ような記述を経営者は考えもしないが、「受注」という
言葉で情報を集めたいと考えている。また、それはＡ社
の情報だけではなく、Ｂ社の情報も欲している。この場
合、双方のメタデータにおける上下関係の検索方法で
は、検索する範囲が広く、階層も深いために、その処理
をするためのプログラムが膨大かつ複雑に作成されてし
まうおそれがある。そこで、「CLIP-HIERARCHY」につな
がるドキュメントタイプのＣＬＩＰの管理対象で「受
注」を定義して、受注に関するＡ社・Ｂ社のシステム・
プログラム・モジュール・ファイル等を紐付しておくこ
とにより、「受注」という用件で関連する情報を全て入
手することができるようになる。このような管理対象を
基本構造として用意しておくことで、検索するプログラ
ムも比較的簡単に作成することが可能となる。

【００５２】ＸＭＬデータベースＤＢに対する構造の表
現方法は、それぞれの管理対象の縦階層の関連や横階層
の関連が、見て捉えにくい。図９に示される論理的な構
造図から、データ系・プロセス系の縦階層の関連情報
と、ドキュメントや広範囲の情報の関連を表すＣＬＩＰ
を絡めた、縦横の構造が表現できる。これらの図では、
構造図に対して「テンプレート」と記述している。これ
は、以下の点を考慮したためである。

【００５３】・各企業で管理対象としたい情報は様々
で、全てを網羅することは不可能である。 ・全てを網羅したとしても、管理対象に対する拡張要求
は終わりがない。

【００５４】これらの要求を考慮して、本発明者は、情
報資源管理システム１の管理対象構造は、最低これだけ
の要素があれば、メタデータの縦階層の関連と横階層の
関連を捉えることができるという管理対象に限定して構
造を考慮し、テンプレートと定めている。もちろん、テ
ンプレートに対して不足がある場合は、それぞれのドキ
ュメントタイプを追加することで、簡単に拡張が可能で
ある。それは、メタデータの関連のみならず、横階層の
関連のＣＬＩＰでも同様である。

【００５５】＜利点＞本実施形態の情報資源管理システ
ム１では、企業内又は企業間で既存の管理システムによ
り管理されている情報資源、管理されていないが実際の
情報資源としてシステムで運用されているものを取り込
み、新しい管理対象であるメタデータやドキュメント・
設計書・仕様書・モデル図・イメージ図を、それらの存
在場所に関わらず、統合管理することができる。このこ
とにより、以下のような利点が得られる。

【００５６】（１）企業内及び企業間で個別的に管理し
ていた情報資源の統合管理が可能になる。また、情報資
源管理システム１を汎用のブラウザがアクセス可能な領
域に配備するようにしているので、ユーザインタフェー
スとしてブラウザを使用することができる。そのため、
情報資源の管理者は情報公開を容易に行え、利用者はデ
ータ端末ＤＴを操作する際に特別な訓練を経ずとも必要
な情報を取得できるようになる。この点が、まず従来の
管理システムと異なる点である。

【００５７】（２）統合管理された資源を共有化した、
システム開発及び再構築の開発支援が可能になる。管理
対象としたい情報資源をＸＭＬタグで括って格納するた
め、実際にＸＭＬデータベースＤＢに格納するプログラ
ムの概念や設計は、従来に比べて簡単且つ完結的であ
り、拡張要求を受け入れた場合の変更も容易に可能であ
る。また、事前にテンプレートを作成しておき、このシ
ステムを必要とする企業に提供することで、それぞれの
企業内でも自由かつ簡単に拡張することが可能となる。

【００５８】（３）共有化された情報資源の関連性の検
索による波及分析が可能になる。ＸＭＬタグに情報資源
の縦階層のみならず、横のつながりも把握できるので、
関連する情報の検索が容易になる。 （４）不用資源検索による資産整理が可能になる。複数
種類の情報資源を統合する際に、重複しているもの、あ
るいは長い間使わなくなっているものが判るので、これ
らの整理が容易になる。 （５）複数管理された情報資源を統合管理することによ
る企業の各種業務の標準化支援が可能になる。企業の各
種業務に関連する情報資源をＸＭＬという統一形式で管
理できるため、業務の標準化の支援に寄与することがで
きる。 （６）データウェアハウスでの企業のデータを採掘し、
分析における利用者のデータに対する参照情報としての
活用が可能になる。これもＸＭＬ化したことに伴う利点
である。 （７）企業の業務提携における、各業務システムの連結
における、データ各々の参照情報としての活用が可能に
なる。データの閲覧の際の操作がきわめて容易であり、
しかも各情報間の繋がりも容易に把握できるので、デー
タの有効活用が可能になる。 （８）企業間の各業務システムを連結した場合の、それ
ぞれの企業内の利用者に、日本語による情報提供を行う
ことができる。スタイルシートの活用により、日本語に
よる情報提供が可能になる。 （９）その他、各種コンピュータシステム製品の論理的
な情報の紐つけと管理が容易になる利点がある。

【００５９】

【実施例】次に、上記の情報資源管理システム１の実施
例を説明する。 （第１実施例）第１実施例では、メタデータの拡張を行
うことが容易であることを示す例を挙げる。すなわち、
あるデータを取り扱う項目が、その桁数を事後的に拡張
しなくてはならなくなったとする。例えば、郵便番号が
５桁であったのが、桁数が足りなくなって、７桁に拡張
して補う作業が必要になったとする。このような作業が
発生した場合、まず、「郵便番号」というデータを取り
扱う項目のメタデータから、そのメタデータが関連して
いるファイル情報や、プログラム、システム、ジョブの
情報をＸＭＬタグをもとに探索する。探索結果として得
られた情報には、縦横の関係が定義されているので、そ
の内容を参照することで、関連するドキュメントや設計
書まで辿って特定し、それらを呼び出して表示し、利用
者に確認させることが容易に実現可能である。この場
合、取り込める情報は、既存の管理対象とされる情報よ
りも広範囲なものとなり得る。例えば、メインフレーム
のＣＯＢＯＬというプログラミング言語で記述されたシ
ステムで、それらの記述がどの管理システムにも格納さ
れていない場合は、ＣＯＢＯＬのプログラムソースを読
みこんで、その中で使用されているデータ項目やファイ
ルの構成等をも取り込めるようになる。

【００６０】（第２実施例）情報資源管理システムは、
企業内及び企業間の業務やシステムに関する情報を統合
し、各々の企業のシステムの設計・開発・運用に役立て
ることができる。このことだけでなく、今まで実現でき
にくかった様々なシステムや製品に対する連携が実現で
きる。例えば、上記のデータウェアハウスをするときの
データの抽出に利用したり、抽出したデータの起源や算
出ルールを知ることにも役立てられ、データウェアハウ
スで多種多様の履歴をもった情報を抽出するときに、抽
出先の格納容器へのデータ変換に役立てられる。また、
企業内で拠点別に複数のシステムを持っている場合や、
企業が業務提携した場合等の、企業間のシステムを繋げ
るときに、実際のシステムを繋げるだけでなく、各々が
どのような繋がりを持っているかを、それを知りたいと
考える利用者が、日本語で、それらの意味やルーツ・ル
ートなどの情報を見ることができるようになる。

【００６１】このように、情報資源管理システム１を活
用することにより、膨大な企業間及び企業内の情報資源
に対する利用者の様々な要求を満たせるようになる。

【００６２】

【発明の効果】以上の説明から明らかなように、この発
明によれば、企業情報等の広範囲な情報を方法論や開発
手法にとらわれずに、一元管理を容易に実現する情報資
源管理形態を提供することができるようになる。

【図面の簡単な説明】

【図１】本発明を適用した情報資源管理システムの構成
図。

【図２】本実施形態によるＸＭＬデータベースの概念
図。

【図３】ＤＴＤの構造例を示した図。

【図４】図３の構造に基づくＤＴＤの例を示した図。

【図５】実際にＸＭＬタグが埋め込まれて格納されるＸ
ＭＬファイルの一例（従業員ファイル）を示した図。

【図６】図５のＸＭＬファイルに対応するスタイルシー
トの一例を示した図。

【図７】図６のスタイルシートに基づいて表示される画
面例を示した図。

【図８】ＸＭＬデータベースの構造例を示した図。

【図９】ＸＭＬデータベースにおける論理的構造図

【符号の説明】

１ 情報資源管理システム ２ コンピュータ本体 ３ コンピュータプログラム製品 １１ 通信制御部 １２ 情報受付処理部 １３ 編集処理部 １４ スタイルシート保持部 １５ テンプレート保持部 １６ 開発支援処理部 １７ 出力制御部 ２１ 処理装置 ２２ 入力装置 ２３ 記憶装置 ２４ 出力装置 ２５ 通信制御機構 ＤＢ ＸＭＬデータベース ＤＴ データ端末

───────────────────────────────────────────────────── フロントページの続き (72)発明者 小河原 智子 東京都新宿区西新宿１−６−１ 株式会社 ビーコンインフォメーションテクノロジー 内 Ｆターム(参考） 5B075 KK07 ND20 NR03 NR20 PQ02 PQ20 PQ42 5B082 AA11 BA09 GA07

Claims (15)

【特許請求の範囲】
1. 【請求項１】 複数種類の情報資源の各々を管理目的に
   応じて任意に定義したＸＭＬタグで括り、各情報資源を
   当該ＸＭＬタグと共にコンピュータ読みとり可能な格納
   容器に集中的に格納する段階と；要求された前記格納容
   器内の情報資源を前記ＸＭＬタグで定義した情報を通じ
   て読み出し、読み出した情報資源の内容を要求元のブラ
   ウザ宛に統一形式で出力する段階と；を含む、ＸＭＬを
   用いた情報資源管理方法。
2. 【請求項２】 前記格納容器の構造、及び／又は、当該
   格納容器内の格納領域の使用ルールを含む属性を当該情
   報資源を括ったＸＭＬタグに定義することを特徴とす
   る、 請求項１記載の情報資源管理方法。
3. 【請求項３】 マークアップを構成する要素の出現回
   数、及び／又は、出現順序を当該情報資源を括ったＸＭ
   Ｌタグに定義することを特徴とする、 請求項１記載の情報資源管理方法。
4. 【請求項４】 一の情報資源に関連する他の情報資源又
   は電子情報との間の縦横関係を当該情報資源を括ったＸ
   ＭＬタグに定義することを特徴とする、 請求項１記載の情報資源管理方法。
5. 【請求項５】 前記格納容器に格納されている情報資源
   をＸＱＬを実行することによって読み出すことを特徴と
   する、 請求項１ないし４のいずれかの項記載の情報資源管理方
   法。
6. 【請求項６】 前記ＸＭＬタグで括られた情報資源の内
   容を所定の表示装置に表示させる形態を定めたスタイル
   シートを保持しておき、当該情報資源の利用を望む者が
   指定した所望のスタイルシートを特定する段階と；前記
   格納されている情報資源を前記特定されたスタイルシー
   トを通じて前記表示装置へ表示させる段階と；をさらに
   含む、 請求項１記載の情報資源管理方法。
7. 【請求項７】 前記格納容器はＷｅｂブラウザを搭載し
   た装置がアクセス可能な領域に存するＸＭＬデータベー
   スであり、前記情報資源を出力する段階において、前記
   装置からの要求に応じて前記ＸＭＬデータベースに格納
   されている情報資源を読み出し、読み出した情報資源を
   前記Ｗｅｂブラウザ上に表示させることを特徴とする、 請求項１記載の情報資源管理方法。
8. 【請求項８】 前記ＸＭＬタグで括られた情報資源とそ
   の情報資源の存在領域を表す情報との組をテンプレート
   として保持し、保持されているテンプレートを新たなコ
   ンピュータシステムの構築又は機能拡張の基礎資源とし
   て用いることを特徴とする、 請求項１記載の情報資源管理方法。
9. 【請求項９】 前記情報資源をプロセス系のメタデータ
   及び／又はデータ系のメタデータを含む電子情報とし、
   データ系のメタデータを文字データ、図形データ、手書
   データを含む画像データ、音データの少なくとも１つと
   することを特徴とする、 請求項１ないし８のいずれかの項記載の情報資源管理方
   法。
10. 【請求項１０】 前記情報資源をプロセス系のメタデー
    タ及び／又はデータ系のメタデータを含む電子情報と
    し、 前記格納容器に、 プロセス系のメタデータとその縦階層の関連情報、デー
    タ系のメタデータとその縦階層の関連情報、これらの関
    連情報とは独立した存在であってデータ系及びプロセス
    系のメタデータに関連するドキュメント、データ系のメ
    タデータと当該メタデータに横階層で関連するドキュメ
    ントとを紐付ける情報の一部又は全部を格納することを
    特徴とする、 請求項１ないし８のいずれかの項記載の情報資源管理方
    法。
11. 【請求項１１】 複数種類のプラットホームのいずれか
    に存在し管理目的に応じて任意に定義されたＸＭＬタグ
    で括られている情報資源の入力を受け付ける受付手段
    と、 受け付けた各情報資源を集中的に格納するためのＸＭＬ
    データベースと、 要求に応じて前記ＸＭＬデータベース内の情報資源を前
    記ＸＭＬタグに定義された情報を通じて読み出し、読み
    出した情報資源を要求元に統一形式で出力させる出力制
    御手段とを備えてなる、 ＸＭＬを用いた情報資源管理システム。
12. 【請求項１２】 前記受付手段は、プロセス系のメタデ
    ータ及び／又はデータ系のメタデータを前記情報資源と
    して受け付けるものであり、 前記ＸＭＬデータベースが、プロセス系のメタデータと
    その縦階層の関連情報を格納するための第１の構造、デ
    ータ系のメタデータとその縦階層の関連情報を格納する
    ための第２の構造、第１及び第２構造とは独立した横階
    層の構造であってデータ系及びプロセス系のメタデータ
    に関連するドキュメントを格納するための第３の構造、
    メタデータ間を横階層で紐付けるための第４の構造の少
    なくとも１つの構造を有するものである、 請求項１１記載の情報資源管理システム。
13. 【請求項１３】 前記第４の構造は、プロセス系のメタ
    データ間、データ系のメタデータ間、プロセス系及びデ
    ータ系のメタデータ間を、横階層で紐付けるようにして
    なる、 請求項１２記載の情報資源管理システム。
14. 【請求項１４】 外部情報処理システムに存在する情報
    資源をＴＣＰ／ＩＰを通じて取り込む手段と、 前記外部情報処理システムから取り込んだ情報資源及び
    自システムにおいて発生した情報資源に前記ＸＭＬタグ
    を埋め込む編集手段と、 前記ＸＭＬタグで括られた情報資源の内容を所定の表示
    装置に表示させる形態を定めたスタイルシートを保持す
    る手段と、 前記ＸＭＬタグで括られた情報資源とその情報資源の格
    納領域を表す情報との組をテンプレートとして保持する
    手段と、 前記スタイルシート又は前記テンプレートを選択的に読
    み出す手段とをさらに備えてなる、 請求項１１ないし１３のいずれかの項記載の情報資源管
    理システム。
15. 【請求項１５】 複数種類の情報資源の各々をその管理
    目的に応じて任意に定義したＸＭＬタグで括る処理、 各情報資源を前記ＸＭＬタグと共にコンピュータ読みと
    り可能な格納容器に集中的に格納する処理、 要求された前記格納容器内の情報資源を前記ＸＭＬタグ
    で定義した情報を通じて読み出す処理、 読み出した情報資源の内容を要求元のブラウザ宛に統一
    形式で出力する処理をコンピュータに実行させるための
    プログラムが記録された、 コンピュータプログラム製品。