特許 7410919 系統メタデータの生成、アクセス、及び表示

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-12-26

(45)【発行日】2024-01-10

(54)【発明の名称】系統メタデータの生成、アクセス、及び表示

(51)【国際特許分類】

   G06F 16/38 20190101AFI20231227BHJP

   G06F 16/28 20190101ALI20231227BHJP

【ＦＩ】

G06F16/38

G06F16/28

【請求項の数】 9

【外国語出願】

(21)【出願番号】P 2021191498

(22)【出願日】2021-11-25

(62)【分割の表示】P 2019525760の分割

【原出願日】2017-12-01

(65)【公開番号】P2022033825

(43)【公開日】2022-03-02

【審査請求日】2021-12-22

(31)【優先権主張番号】62/428,860

(32)【優先日】2016-12-01

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】509123208

【氏名又は名称】アビニシオ テクノロジー エルエルシー

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(72)【発明者】

【氏名】クレメンス，デイビッド

(72)【発明者】

【氏名】ラディヴォイェヴィック，ドゥサン

(72)【発明者】

【氏名】ガラルノー，ネイル

【審査官】三橋 竜太郎

(56)【参考文献】

【文献】特表２０１１－５１７３５２（ＪＰ，Ａ）

【文献】特開２００６－１９０２６１（ＪＰ，Ａ）

【文献】特表２０１６－５２０８９０（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１４／０２７９９７９（ＵＳ，Ａ１）

【文献】米国特許出願公開第２００９／０２２４９４１（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００－１６／９５８

(57)【特許請求の範囲】

【請求項1】

データ処理機器によって実行される方法であって、
特定のデータ要素の系統の要求を含むクエリを受信すること、
前記系統の種類の識別を受信すること、
前記識別される系統の種類にどの種類のノード及び辺が関連するのかを識別する情報を受信することであって、前記情報は、辺の異なる種類について辺をたどり又は収集するための条件を特定し、かつ、１）辺の種類に対応する少なくとも１つの識別情報、２）前記辺の種類に関する横断方向に対応する少なくとも１つの識別情報、及び３）前記辺を横断するとき取るべきアクションに対応する少なくとも１つのインジケータを含む、こと、
前記条件に従って、ノード及び辺を横断することであって、前記ノードがランダムアクセスメモリ内に記憶されるデータ構造のそれぞれのインスタンスに対応し、前記辺が前記データ構造のそれぞれのインスタンスに対応する前記ランダムアクセスメモリ内のそれぞれのアドレスへのそれぞれのポインタに対応する、こと、及び
前記ノード及び辺の前記横断に基づいて、前記クエリに対する応答を生成することであって、前記応答は、前記特定のデータ要素の系統を表すデータを含む、こと、
を含む、方法。

【請求項2】

前記ノードがデータ構造のそれぞれのインスタンスに対応し、前記辺が前記データ構造のそれぞれのインスタンスへのそれぞれのポインタに対応する、請求項１に記載の方法。

【請求項3】

前記データ構造のインスタンスが、
対応するノードを識別する識別値、
前記対応するノードのそれぞれの特性を表す１つ又は複数の特性値、及び
それぞれの識別値への１つ又は複数のポインタであって、各ポインタは前記対応するそれぞれの識別値によって識別されるノードに関連する辺を表す、１つ又は複数のポインタ
を含む、請求項２に記載の方法。

【請求項4】

前記情報が、前記クエリによって識別される前記特定のデータ要素のデータの種類に基づいて選択される、請求項１～３の何れか一項に記載の方法。

【請求項5】

前記情報が構造化文書を含む、請求項１～４の何れか一項に記載の方法。

【請求項6】

実行可能命令を記憶する少なくとも１つの非一時的コンピュータ可読記憶媒体と、
前記命令を実行するように構成される１つ又は複数のプロセッサと
を含むシステムであって、
前記命令を実行することが、請求項１～５の何れか一項に記載のステップの実施を引き起こす、システム。

【請求項7】

命令を記憶する非一時的コンピュータ可読記憶装置であって、
実行されるとき、請求項１～５の何れか一項に記載のステップを実施する、非一時的コンピュータ可読記憶装置。

【請求項8】

ソフトウェアプグラムであって、
実行されるとき、請求項１～５の何れか一項に記載のステップを実施する、ソフトウェアプログラム。

【請求項9】

システムであって、
特定のデータ要素の系統の要求を含むクエリを受信する手段と、
前記系統の種類の識別を受信する手段と、
前記識別される系統の種類にどの種類のノード及び辺が関連するのかを識別する情報を受信する手段であって、前記情報は、辺の異なる種類について辺をたどり又は収集するための条件を特定し、かつ、１）辺の種類に対応する少なくとも１つの識別情報、２）前記辺の種類に関する横断方向に対応する少なくとも１つの識別情報、及び３）前記辺を横断するとき取るべきアクションに対応する少なくとも１つのインジケータを含む、手段と、
前記条件に従って、ノード及び辺を横断する手段であって、前記ノードがランダムアクセスメモリ内に記憶されるデータ構造のそれぞれのインスタンスに対応し、前記辺が前記データ構造のそれぞれのインスタンスに対応する前記ランダムアクセスメモリ内のそれぞれのアドレスへのそれぞれのポインタに対応する、手段と、
前記ノード及び辺の前記横断に基づいて、前記クエリに対する応答を生成する手段であって、前記応答は、前記特定のデータ要素の系統を表すデータを含む、手段と
を含む、システム。

【発明の詳細な説明】

【技術分野】

【0001】

技術分野
本願は系統メタデータ、例えばデータ記憶システム内に記憶されるデータ要素の系統を生成し、それにアクセスし、それを表示するためのデータ構造及び方法に関する。

【背景技術】

【0002】

背景
企業はデータを管理するためにデータウェアハウジング、顧客関係管理、データマイニング等のデータ処理システムを使用する。多くのデータ処理システムにおいて、データはデータベースファイル、運用システム、フラットファイル、インターネット、他の情報源等の多くの異なるデータソースから中央リポジトリ内にプルされる。多くの場合、データシステム内にロードされる前にデータが変換される。変換は、クレンジング、統合、及び抽出を含む。データ、データのソース、及びデータシステム内に記憶されるデータに生じている変換を追跡するためにメタデータを使用することができる。メタデータ（「データに関するデータ」と呼ばれることもある）とは、他のデータの属性、形式、元、履歴、相互関係等を記述するデータである。メタデータの管理は複雑なデータ処理システムにおいて中心的な役割を果たし得る。

【0003】

利用者は特定のデータが様々なデータソースからどのように導出されるのかを調査したい場合がある。例えば利用者はデータセット又はデータオブジェクトがどのように生成されたのか、又はどのソースからデータセット又はデータオブジェクトがインポートされたのかを知りたい場合がある。導出元のソースまでデータセットを追跡することをデータ系統追跡（又は「アップストリームデータ系統追跡」）と呼ぶ。利用者は特定のデータセットがどのように使用されているのか、例えばどのアプリケーションが所与のデータセットを読み出したのかを調査したい場合がある（「ダウンストリームデータ系統追跡」又は「インパクト解析」と呼ばれる）。利用者は或るデータセットが他のデータセットとどのように関係するのかを知ることに興味がある場合もある。例えば利用者はデータセットが修正されているのかどうかや、どのテーブルが影響を受けるのかを知りたい場合がある。

【0004】

一種のメタデータである系統は、データ系統に関する質問（例えば「所与の値がどこから来たのか？」、「出力値はどのように計算されたのか？」や、「どのアプリケーションがこのデータを作り出し、このデータに依存するのか？」）に対する回答を利用者が得ることを可能にする。利用者は提案された修正（例えば「この部分が変更された場合、他の何処が影響を受けるのか？」や「このソースフォーマットが変更される場合、どのアプリケーションが影響を受けるのか？」）の結果を理解することができる。利用者は技術上のメタデータ及びビジネス上のメタデータの両方が関与する回答への質問も得ることができる（例えば「どのグループがこのデータを作成し使用する責任を負うのか？」、「このアプリケーションを最後に変更したのは誰か？」や、「どのような変更を彼らは加えたのか？」）。

【0005】

これらの質問に対する回答は複雑なデータ処理システムを解析し、その問題に対処するのを助けることができる。例えば或るデータ要素が異常値を有する場合、任意の数の過去の入力又はデータ処理ステップがその異常値に関与している可能性がある。従って、関心のあるデータ要素を表す視覚要素、並びに関心のあるデータ要素に影響を及ぼす又は関心のあるデータ要素の影響を受ける他のデータ要素を表す視覚要素を含む図の形式で系統を利用者に提示する場合がある。利用者はその図を見て、関心のあるデータ要素に影響を及ぼす他のデータ要素及び／又は変換を視覚的に識別することができる。一例として、この情報を使用することにより、利用者はデータ要素及び／又は変換の何れかが異常値の原因であり得るかどうかを知り、問題が発見される場合は根底にあるデータ処理ステップの何れかを訂正する（又は訂正するためにフラグを立てる）ことができる。別の例として、この情報を使用することにより、利用者はシステムの一部に必須であり得る（例えばそのためシステムからそれらを除去することで関心のあるデータ要素が影響を受けることになる）任意のデータ要素若しくは変換、及び／又はシステムの一部に必須ではない可能性がある（例えばそのためシステムからそれらを除去しても関心のあるデータ要素は影響を受けない）データ要素若しくは変換を識別することができる。

【発明の概要】

【課題を解決するための手段】

【0006】

概要
とりわけ本発明者らはデータ処理機器によって実行される方法を記載し、その方法は、データソースからメタデータの一部を受信することであって、メタデータの一部はノード及び辺を記述し、辺の少なくとも一部は或るノードに対する別のノードの影響をそれぞれ表し、各辺は単一の方向を有する、受信すること、メタデータの一部を表すデータ構造のインスタンスを生成することであって、データ構造の少なくとも１つのインスタンスは対応するノードを識別する識別値、対応するノードのそれぞれの特性を表す１つ又は複数の特性値、及びそれぞれの識別値に対する１つ又は複数のポインタを含み、各ポインタは対応するそれぞれの識別値によって識別されるノードに関連する辺を表す、生成すること、データ構造のインスタンスをランダムアクセスメモリ内に記憶すること、少なくとも１つの特定のデータ要素の識別を含むクエリを受信すること、及び特定のデータ要素の系統の表現をコンピュータシステムのディスプレイに表示させるためにデータ構造の少なくとも１つのインスタンスを使用することを含む。

【0007】

これらの技法は、方法として、システムとして、及び／又はコンピュータ可読記憶装置上に記憶されるコンピュータプログラム製品としてを含む幾つかのやり方で実装することができる。

【0008】

これらの技法の態様は以下の利点の１つ又は複数を含み得る。系統メタデータは、系統メタデータに対するクエリに応答するとき速度及び効率を得るように設計された専用データ構造を使用して記憶することができる。系統メタデータはメモリ内に記憶することができ、そのため系統メタデータを記憶するコンピュータシステムは、系統メタデータがメモリ内に記憶されていない場合（例えば系統メタデータがハードディスク又は別の種類の記憶技法の中に記憶されそこからアクセスされる場合）よりも速く系統メタデータに対するクエリに応答することができる。本明細書に記載する技法を使用し、系統データを他の技法よりもはるかに速く、例えば５００倍速く取得することができる。

【図面の簡単な説明】

【0009】

図面の説明

【図1A】メタデータの処理環境を示す。

【図1B】メタデータの処理環境を示す。

【図1C】メタデータの処理環境を示す。

【図1D】メタデータの処理環境を示す。

【図2A】メタデータの閲覧環境内で表示される情報の一例を示す。

【図2B】メタデータの閲覧環境内で表示される情報の一例を示す。

【図2C】メタデータの閲覧環境内で表示される情報の一例を示す。

【図2D】メタデータの閲覧環境内で表示される情報の一例を示す。

【図2E】メタデータの閲覧環境内で表示される情報の一例を示す。

【図3】データ構造の一例を示す。

【図4】ウォークプランの一例を示す。

【図5A】専用データ構造によって定められる形式で系統メタデータを記憶するための手続きを表す流れ図を示す。

【図5B】系統メタデータを表示させるための手続きを表す流れ図を示す。

【図6】専用データ構造の形式で記憶される系統メタデータを横断するための手続きを表す流れ図を示す。

【発明を実施するための形態】

【0010】

様々な図面の中の同様の参照番号は同様の要素を示す。

【0011】

説明
メタデータへのアクセスを管理するシステムは特定のデータ要素の系統を要求する利用者からクエリを受信し、それに応答してデータ要素の系統を表す図を送ることができる。データ要素が相対的に大量のデータを記憶するデータ記憶システムに属する場合、メタデータへのアクセスを管理するシステムはデータ要素の系統を処理し、対応する図を生成するために大量の処理時間を費やす必要があり得る。しかし、系統メタデータを処理することに充てられその種の処理に最適化されるシステムを導入することにより、その処理を加速しより効率的にすることができる。従って本明細書は、専用のシステムを使用しない場合よりも概して高速且つ効率的なやり方で系統メタデータを処理し記憶するために専用のシステムを使用する技法を記載する。

【0012】

図１Ａは、系統メタデータを記憶し、それを環境内の他のシステムに提供する系統サーバ１０２を含むメタデータ処理環境１００を示す。メタデータ処理環境１００は、メタデータを得るための要求に概して応答するメタデータサーバ１０４も含む。メタデータサーバ１０４は、メタデータデータベース１０８内に記憶されるメタデータ１０６にアクセスできる。メタデータ１０６は、メタデータデータベース１０８にメタデータ１１２Ａ～Ｃを継続的に与えるデータソース１１０Ａ～Ｃから来る。例えばデータソース１１０Ａ～Ｃは、リレーショナルデータベース、フラットファイル、ネットワークソース等の任意の組合せとすることができる。

【0013】

使用中、メタデータサーバ１０４は利用者１１８によって操作されるユーザ端末１１６から受信されるクエリ１１４に応答する。例えばユーザ端末１１６は、パーソナルコンピュータ、ラップトップコンピュータ、タブレット装置、スマートフォン等の計算装置とすることができる。一部の例では、例えばメタデータサーバ１０４がネットワーク上でデータへのアクセスを提供するように構成され、ウェブブラウザとインタフェース可能なウェブサーバを含む又はウェブサーバと通信する場合、ユーザ端末１１６がウェブブラウザ等のネットワークベースのユーザアプリケーションを動作させる。概して、本明細書に記載のコンピュータシステム間の対話の多くは、インターネット又はその種のネットワーク上で一般に使用される通信プロトコルを使用する同様の通信ネットワークを使用して行われ得る。

【0014】

メタデータサーバ１０４は、複数の種類のメタデータに対するクエリに応答するように構成される。一種のメタデータは系統メタデータなので、メタデータサーバ１０４は、メタデータデータベース１０８内に記憶される特定のデータ要素の系統を記述するメタデータ１０６にアクセスすることにより、特定のデータ要素、例えばデータソース１１０Ａ～Ｃの１つによって記憶されるデータ要素１２０の系統を要求するクエリ１１４を処理することができる。次いでメタデータサーバ１０４はユーザ端末１１６に系統メタデータ１２２、例えば系統図形式の系統メタデータを提供することができる（図２Ａ～図２Ｅに関して以下で説明する）。

【0015】

一部の例では、系統メタデータに関するクエリ１１４を処理することは、メタデータサーバ１０４の相対的に大量の処理時間を必要とし及び／又は相対的に大量の処理資源を使用するタスクである。例えばクエリ１１４を処理するために、メタデータサーバ１０４はメタデータデータベース１０８内に記憶されるメタデータ１０６にアクセスする必要があり得る。この例では、必要なメタデータの全てにアクセスするために、メタデータサーバ１０４がメタデータデータベース１０８に対するクエリを生成する処理資源を費やす必要がある。更に、メタデータデータベース１０８にクエリを伝送し、応答を待つプロセスはレイテンシ、例えば通信ネットワークレイテンシを発生させる。加えて一部の例では、系統図を作成するのに必要なメタデータを抽出するために、メタデータデータベース１０８から受信されるメタデータをメタデータサーバ１０４が処理しなければならない。例えばメタデータデータベース１０８は系統メタデータ以外に様々な種類のメタデータを記憶するので、メタデータデータベース１０８から受信されるメタデータは関心のあるデータ要素の系統に直接関係しない情報を含む場合があり、そのため系統に関係しない情報を識別し除去するために追加の処理時間が使われる。

【0016】

一部の実装形態では、例えばメタデータ処理環境１００の性能を改善するために、系統サーバ１０２を使用してメタデータサーバ１０４に系統メタデータを提供する。系統サーバ１０２は、系統サーバを使用しない技法よりも概して高速且つ効率的にアクセス可能な形式で系統メタデータ１２４を記憶する専用のシステムである。具体的には、系統サーバ１０２は、系統メタデータに対するクエリに応答するとき速度及び効率を得るように設計された専用データ構造を使用して系統メタデータ１２４を記憶する。特定のデータ構造を使用して記憶される全てのデータが同じやり方で構成されるように、データ構造はデータの構成を定める。データ構造の技法については図３に関して以下でより詳細に説明する。

【0017】

使用中、系統メタデータ１２８を取得するために系統サーバ１０２がメタデータデータベース１０８にクエリ１２６を伝送する。系統サーバ１０２は、理想的には広範な多数の、例えばデータソース１１０Ａ～Ｃによって記憶されるデータ要素１２０の殆ど又は全てに関する系統メタデータを記憶する。このようにして、系統サーバ１０２はクエリが行われ得るデータ要素１２０の殆どについて系統のクエリに応答することができる。系統サーバ１０２がメタデータデータベース１０８から系統メタデータ１２８を受信すると、系統サーバ１０２は記憶済みの系統メタデータ１２４を含む自らのデータ構造を更新する。一部の例では、相対的に最新の多数の系統メタデータを記憶するために、系統サーバ１０２がメタデータデータベース１０８に新たなクエリ１２６を定期的に、例えば毎時、毎日、又は別の間隔で送信する。例えばこの間隔は、例えば系統サーバ１０２によって保持されるスケジュールデータに対応するスケジュール済みの間隔であり得る。

【0018】

図１Ｂでより詳細に示すように、メタデータサーバ１０４は系統メタデータに対するクエリ１１４（例えばユーザ端末１１６上で系統図を表示するために使用可能な系統メタデータに対するクエリ）を受信し、そのクエリ１１４を系統サーバ１０２に提供することができる。次いで系統サーバは、クエリ１１４に応答して系統メタデータ１２２を返すことができる。メタデータサーバ１０４は、系統メタデータをメタデータデータベース１０８から取得すること等の他の技法を使用して取得される系統メタデータと比較し、受信した系統メタデータ１２２をユーザ端末１１６に提供する前に準備するのに処理時間をさほど費やす必要がなく、処理資源をさほど使用する必要がない。

【0019】

図１Ｃ及び図１Ｄは、系統サーバ１０２及びメタデータサーバ１０４の要素並びにそれらがどのように対話するのかを示す。上記のように、メタデータサーバ１０４は特定のデータ要素の系統を要求するクエリ１１４を受信する。クエリ１１４は、系統が要求された特定のデータ要素（例えば図１Ａのデータ要素１２０のうちの１つ）を識別する。メタデータサーバ１０４はデータ要素の識別を使用して、そのデータ要素に関係する系統メタデータを集めるために使用可能な１組のウォークプラン１３２からウォークプラン１３０を選択する。ウォークプラン１３０は、１組の系統メタデータを特定のやり方で横断（「ウォーク」）する方法を記述するデータ構造（例えばＸＭＬ文書等のタグ付き部分を含む構造化文書）である。一部の例では、データ要素のデータの種類に基づいてウォークプランを選択することができる。例えば特定のデータの種類がウォークプラン１３２のうちの特定のものに関連し得る（例えばメタデータサーバ１０４にとってアクセス可能な関連のインデックス内に記憶される関連）。ウォークプラン１３２については図４に関して以下で詳細に説明する。

【0020】

ウォークプラン１３０が選択されると、メタデータサーバ１０４が系統サーバ１０２にクエリ１１４及びウォークプラン１３０を伝送する。それに応答し、系統サーバ１０２が、自らの系統メタデータのデータ構造１３４の中からクエリ１１４に関連する系統メタデータを識別する。データ構造１３４は、系統メタデータに対するクエリに応答するのに必要な如何なるデータも省くことなしに、系統メタデータを含むのに必要な記憶空間量を最小化するやり方で構成される系統メタデータの表現である。従って、系統サーバ１０２は典型的には自らのデータ構造１３４内に記憶されるデータを使用して、クエリ１１４に応答するためにメタデータサーバ１０４が必要とする系統メタデータの全てをメタデータサーバ１０４に提供することができる。データ構造１３４については図３に関して以下で詳細に説明する。

【0021】

一部の実装形態では、データ構造１３４が高速アクセス（例えばデータの高速の読出し及び書込み）のために系統サーバ１０２のメモリ１３５内にロードされる。メモリの一例はランダムアクセスメモリである。ランダムアクセスメモリは、同じサイズ（例えばバイトやワード）の他の任意の項目とほぼ同じ時間で各データ項目にアクセスできるようなやり方でデータ項目を記憶する。対照的に、磁気ディスク等の他の種類のデータ記憶域は、ディスクの現在の物理的状態（例えば磁気リード／ライトヘッドの位置）にもよるが、一部のデータ項目にアクセスするのに他のデータ項目よりも長い時間がかかることを生じさせる物理的制約を有する。ランダムアクセスメモリ内に記憶されるデータ項目は、典型的にはそのデータ項目に固有のアドレスに又は少数のデータ項目間で共有されるアドレスに記憶される。ランダムアクセスメモリは典型的には揮発性であり、そのためランダムアクセスメモリがアクティブ電源から切断される（例えばコンピュータシステムが受電できなくなる）場合、ランダム内に記憶されるデータが失われる。対照的に、磁気ディスク及び他の一部の種類のデータ記憶域は不揮発性であり、アクティブ電源なしでもデータを保持する。

【0022】

系統サーバ１０２はデータ構造１３４をメモリ１３５内に記憶するので、系統サーバ１０２はデータ構造をメモリ１３５内に記憶しない技法よりも速く系統メタデータを読み書きすることができる。具体的には、データ使用量を最小化するやり方でデータ構造１３４が構成される。例えばデータ構造１３４は、メタデータサーバ１０４から得られる元の系統メタデータ内にあるテキスト文字列等のデータを省くことができる。従って系統サーバ１０２の使用中、データ構造１３４の全て、例えば系統メタデータを表すデータの全てをメモリ１３５内に記憶することができる。コンピュータシステムは、（例えばアドレス指定の制限により）所与の時間に使用可能なランダムアクセスメモリの量に関する制約を概して有する。更に、ランダムアクセスメモリは他の種類のデータ記憶域（例えば磁気ディスク）よりも１バイト当たり高価である傾向がある。従ってランダムアクセスメモリを使用した場合、データ構造１３４は特定のコンピュータシステム上でのその合算したサイズについて上限を有する可能性がある。従って、本明細書に記載の技法（例えば図３に関して以下で説明する技法）はデータ構造のサイズを最小化するが、クエリ１１４によって要求され得る系統に関する情報は保つ。

【0023】

一部の実装形態では、メタデータサーバ１０４が系統メタデータ１３７（例えば図１Ａに示すメタデータデータベース１０８から受信される系統メタデータ）も記憶する。しかしメタデータサーバ１０４は、例えば系統サーバ１０２のデータ構造を使用しないので、自らの記憶済みの系統メタデータ１３７の殆どをランダムアクセスメモリ内に記憶しない。従ってメタデータサーバ１０４も幾らかの系統メタデータ１３７を記憶しても、メタデータサーバ１０４はメタデータサーバ１０４にローカルに記憶されていない任意のメタデータを得るために系統サーバ１０２の系統メタデータ１２４にアクセスすることができる。系統サーバ１０２が使用されていない場合、幾らかの系統メタデータ１３７を記憶するメタデータサーバ１０４はメタデータデータベース１０８（図１Ａ）内に記憶される系統メタデータに概してアクセスし、そのことには上記のように系統サーバ１０２を使用することと比べて性能の不利益があり得る。

【0024】

ここではランダムアクセスメモリを主たる例として使用したが、他の種類のメモリも系統サーバ１０２と共に使用することができる。例えば別の種類のメモリはフラッシュメモリである。ランダムアクセスメモリと異なり、フラッシュメモリは不揮発性である。しかし、フラッシュメモリは典型的にはデータ項目にアクセスすることに対する制約を有する。一部の種類のフラッシュメモリは、個々にアクセス可能なデータ項目とは対照的に、データ項目の集合（例えばデータ項目のブロック）が一度にアクセス可能な最小データ単位であるやり方で構成される。例えば一部の種類のフラッシュメモリ上でデータ項目を削除するために、全ブロックを削除しなければならない。残りのデータ項目を保つには、残りのデータ項目をフラッシュメモリに再書込みすることができる。

【0025】

系統サーバ１０２はウォークプラン１３０を使用してデータ構造１３４を横断し、クエリ１１４に応答するデータ構造内に記憶される系統メタデータを収集する。図１Ｄに示すように、次いで系統サーバ１０２が系統メタデータ１３９を含む応答１３８をメタデータサーバ１０４に送り返す。メタデータサーバ１０４は系統メタデータ１３９を使用してクエリ１１４に対する自らの応答１４０を生成することができる。応答１４０は幾つかある形式のうちの１つを取り得る。一部の例では応答１４０が、系統サーバ１０２から受信される同じ系統メタデータ１３９を例えば最小限の後処理を伴う形式で含む。一部の例では、メタデータサーバ１０４が系統メタデータ１３９に対する後処理を実行する。例えば人間が読めない符号化形式で系統メタデータ１３９が受信される場合、例えばメタデータサーバ１０４は系統メタデータ１３９の形式を人間が読める形式に変更することができる。一部の例では、メタデータサーバ１０４が系統メタデータ１３９に基づいて系統図を生成し、系統図を表すデータを応答１４０に組み込む。（図２Ａ～図２Ｅに関して以下で詳細に説明するように）例えば応答１４０が系統図である場合、一部の例では応答１４０がユーザ端末１１６（図１Ａ）に伝送される。一部の例では、応答１４０が中間システムに伝送されてからユーザ端末に伝送され及び／又はユーザ端末に伝送するのに適した形式に処理される。

【0026】

図２Ａは、メタデータの閲覧環境内で表示される情報の一例を示す。一部の例では、メタデータの閲覧環境がユーザ端末、例えば図１Ａに示すユーザ端末１１６上で実行されるインタフェースである。図２Ａの例では、メタデータの閲覧環境がデータ系統図２００Ａに関する情報を表示する。メタデータの閲覧環境の一例は、利用者（例えば図１Ａに示す利用者１１８）がメタデータを視覚化し編集することを可能にするウェブベースのアプリケーションである。メタデータの閲覧環境を使用し、利用者は標準のウェブブラウザを使用して企業内の何処からでもメタデータを探索し、解析し、管理することができる。メタデータオブジェクトのそれぞれの種類は１つ又は複数のビュー又は視覚的表現を有する。図２Ａのメタデータの閲覧環境は、標的要素２０６Ａに関する系統図を示す。

【0027】

例えばこの系統図は、メタデータサーバ１０４（図１Ａ）内に記憶されるメタデータオブジェクトを表すデータ及び／又は処理ノードに関する端から端までの系統、つまり所与の開始オブジェクトが依存するオブジェクト（そのソース）及び所与の開始オブジェクトが影響を及ぼすオブジェクト（その標的）を表示する。この例では、メタデータオブジェクトの２つの例であるデータ要素２０２Ａと変換２０４Ａとの間のつながりが示されている。これらのメタデータオブジェクトは図中のノードによって表現されている。データ要素２０２Ａは例えばデータセット、データセット内のテーブル、テーブル内のカラム、及びファイル、メッセージ、レポート内のフィールドを表し得る。変換２０４Ａの一例は、単一のデータ要素出力がどのように作成されるのかを記述する実行ファイル（executable）の要素である。ノード間のつながりはメタデータオブジェクト間の関係に基づく。

【0028】

図２Ｂは、図２Ａに示す同じ標的要素２０６Ａに関する対応する系統図２００Ｂを示すが、各要素２０２Ｂがグループ化され、コンテキストに基づいてグループ内に表示されている。例えばデータ要素２０２Ｂは、データセット２０８Ｂ（例えばテーブル、ファイル、メッセージ、レポート）、（グラフ、計画、プログラム等の実行ファイル及びそれらが作用するデータセットを含む）アプリケーション２１０Ｂ、及びシステム２１２Ｂ内でグループ化されている。システム２１２Ｂは、データ及びデータを処理するアプリケーションの機能上のグループ化であり、システムはアプリケーション及びデータグループ（例えばデータベース、ファイルグループ、メッセージングシステム、データセットのグループ）で構成される。変換２０４Ｂが、実行ファイル２１４Ｂ、アプリケーション２１０Ｂ、及びシステム２１２Ｂ内でグループ化される。グラフ、計画、プログラム等の実行ファイルはデータセットを読み書きする。既定でどのグループを展開し、どのグループを折り畳むのかをパラメータが設定することができる。不要な詳細度を除去することにより、かかるパラメータの設定は利用者が自分にとって重要なグループの詳細だけを見ることを可能にする。

【0029】

データ系統の計算を行うためにメタデータの閲覧環境を使用することは幾つかの理由から有用である。例えばデータ要素と変換との間の関係を計算し示すことは、報告された値が所与のフィールドレポートに関してどのように計算されたのかを利用者が突き止めるのを助け得る。利用者はどのデータセットが特定の種類のデータを記憶するのか、及びどの実行ファイルがそのデータセットに対して読み書きするのかを見ることもできる。ビジネス用語の場合、データ系統図はどのデータ要素（例えばカラムやフィールド）が特定のビジネス用語（例えば企業内での定義）に関連するのかを示すことができる。

【0030】

メタデータの閲覧環境内で示されるデータ系統図はインパクト解析でも利用者を助けることができる。とりわけ利用者は、データセットにカラム又はフィールドが追加される場合にどのダウンストリーム実行ファイルが影響を受けるのか、及び誰が通知される必要があるのかを知りたい場合がある。インパクト解析は所与のデータ要素がどこで使用されるのかを明らかにすることができ、そのデータ要素を変更する分岐（ramification）も明らかにすることができる。同様に、利用者は実行ファイル内の変更によってどのデータセットが影響を受けるのか、又は製作から特定のデータベーステーブルを除去しても大丈夫かどうかを見ることができる。

【0031】

データ系統図を生成するためにメタデータの閲覧環境を使用してデータ系統の計算を行うことはビジネス用語を管理するのに有用である。例えば或る企業内の従業員にとって、その企業の全体にわたるビジネス用語の意味、それらの用語間の関係、及びそれらの用語が指すデータについて一致をみることが望ましい場合が多い。ビジネス用語を整合的に使用することは企業データの透明性を高めることができ、ビジネス要件の伝達を助ける。従って、ビジネス用語の基礎を成す物理データを何処で見つけることができるのか、及びどのビジネスロジックが計算に使用されるのかを知ることが重要である。

【0032】

データノード間の関係を見ることはメタデータを管理し維持する際にも有用であり得る。例えば利用者は誰がメタデータ片を変更したのか、メタデータ片のソース（又は「レコードのソース」）は何なのか、又は外部ソースからメタデータをロードし若しくはリロードするときどのような変更が加えられたのかを知りたい場合がある。メタデータを維持する際、指定の利用者がメタデータオブジェクト（ビジネス用語等）を作成できるようにすること、メタデータオブジェクトの特性（他のオブジェクトに対するオブジェクトの記述や関係等）を編集できるようにすること、又は使われなくなったメタデータオブジェクトを削除できるようにすることが望ましい場合がある。

【0033】

メタデータの閲覧環境はオブジェクトの幾つかのグラフィカルビューを提供し、利用者がメタデータを探索し解析することを可能にする。例えば利用者はシステム及びアプリケーションのコンテンツを閲覧し、任意のオブジェクトの詳細を探索することができ、上記のデータ系統解析やインパクト解析等の様々な種類の依存性解析を利用者が容易に行うことを可能にするデータ系統ビューを使用してオブジェクト間の関係も見ることができる。オブジェクトの階層構造も見ることができ、特定のオブジェクトについて階層構造を検索することができる。オブジェクトが見つかると、そのオブジェクトに利用者が容易に戻ることを可能にするブックマークをオブジェクトについて作成することができる。

【0034】

適切な許可により、利用者はメタデータの閲覧環境内でメタデータを編集することができる。例えば利用者はオブジェクトの記述を更新し、ビジネス用語を作成し、オブジェクト間の関係を定め（ビジネス用語をレポート内のフィールドやテーブル内のカラムにリンクすること等）、オブジェクトを移動し（例えば或るアプリケーションから別のアプリケーションにデータセットを移動すること）、又はオブジェクトを削除することができる。

【0035】

図２Ｃでは、標的要素２０６Ａに関する対応する系統図２００Ｃを示すが、標的データ要素２０６Ａの計算に関与しているアプリケーションに合わせて分解能のレベルが設定されている。とりわけアプリケーション２０２Ｃ、２０４Ｃ、２０６Ｃ、２０８Ｃ、及び２１０Ｃを示しており、それはそれらのアプリケーションだけが標的データ要素２０６Ａに関する計算に直接関与するからである。（例えば図中に更に多くの又は少ない詳細を表示するために）利用者が異なる分解能のレベルで系統図の任意の部分を見たい場合、利用者は対応する展開／折畳ボタン２１２Ｃを活性化することができる。

【0036】

図２Ｄは、異なる分解能のレベルでの対応する系統図２００Ｄを示す。この例では展開／折畳ボタン２１２Ｃが利用者によって活性化されており、メタデータの閲覧環境が今度も同じ系統図を表示しているが、アプリケーション２０２Ｃ内のデータセット２１４Ｄ及び実行ファイル２１６Ｄを表示するためにアプリケーション２０２Ｃが展開されている。

【0037】

図２Ｅは、異なる分解能のレベルでの対応する系統図２００Ｅを示す。この例ではカスタム展開によって展開される全てのものを表示することに利用者が決めている。最終的なデータソースである（例えばアップストリームシステムを有さない）任意のフィールド又はカラムが展開される。加えて、特定のフラグが立てられているフィールドも展開される。この例では、系統内の重要な中間点にあるデータセット及びフィールド上に特定のフラグが立てられており、１つのカラムは系統が表示されているカラムである。

【0038】

系統の他の例が、参照によりその全体を本明細書に援用する「VISUALIZING RELATIONSHIPS BETWEEN DATA ELEMENTS AND GRAPHICAL REPRESENTATIONS OF DATA ELEMENT ATTRIBUTES」と題された米国特許出願第１２／６２９，４６６号の中で記載されている。

【0039】

メタデータの閲覧環境内で要素及び関係を見ることは、それらを表すノードの各々に関連する情報を追加することによってより有用にされ得る。関連情報をノードに追加する１つの例示的なやり方は特定のノード上に情報をグラフィカルにオーバレイすることである。これらのグラフィックはノードによって表されるデータの幾らかの値又は特性を示すことができ、メタデータデータベース内の任意の特性であり得る。この手法には、通常は共通点のない２つ以上の情報片（データのノードとノードによって表されるデータの特性との間の関係）を組み合わせ、有用な情報を「脈絡内に」おこうとする利点がある。例えばデータノード間の関係の視覚的表現と共に、メタデータの品質、メタデータの新しさ、レコード情報のソース等の特性を表示することができる。この情報の一部は表形式でアクセス可能とすることができるが、データの様々なノード間の関係と共にデータの特性を見ることの方が利用者にとって役立つ可能性がある。利用者は、メタデータの閲覧環境内のデータ要素及び／又は変換ノード上にデータのどの特性を表示するのかを選ぶことができる。どの特性を表示するのかは既定のシステム設定に従って設定することもできる。

【0040】

図１Ａに関して上記で説明したように、系統サーバ１０２はデータ構造１３４を使用して系統メタデータをメモリ（例えばランダムアクセスメモリ）内に記憶する。図３はデータ構造３００の一例を示す。使用中、系統サーバ１０２はデータ構造３００の多くのインスタンスを含む。データ構造のインスタンスは、データ構造によって定められるやり方でフォーマットされるデータの集合（例えばビットの集合）である。本明細書に記載のデータ構造３００のインスタンスは「ノード」と呼ぶ場合がある。

【0041】

データ構造３００の各インスタンスはメタデータオブジェクト、例えば図２Ａに示すデータ要素２０２Ａ又は変換２０４Ａの１つを表す。一部の例では、データ構造３００の各インスタンスは系統図、例えば図２Ａ～図２Ｅに示す図２００Ａ～２００Ｅの中で表示され得るノードを表す。

【0042】

使用中、系統サーバ１０２はデータ構造に固有のメモリ位置３０２に各データ構造３００を記憶する。各データ構造３００は典型的には他のデータ構造のメモリ位置を指す。

【0043】

データ構造３００は幾つかのフィールドで構成される。フィールドとはデータの集合、例えばデータ構造３００のインスタンスを作るビットのサブセットである。識別情報フィールド３１０は、データ構造３００のインスタンスに関する一意識別情報を表すデータを含む。種類フィールド３１２は、データ構造３００の対応するインスタンスによって表されるメタデータオブジェクトの種類を表すデータを含む。一部の例では、種類は「データ要素」や「変換」等であり得る。一部の例では、種類フィールド３１２がデータ構造３００のインスタンス内に含まれる前進辺及び後退辺の数も示す。特性フィールド３１４は、データ構造３００の対応するインスタンスによって表されるメタデータオブジェクトの様々な特性をそれぞれ表す。特性フィールド３１４の例は、メタデータオブジェクトを識別するテキストラベルを含む「名前」フィールド、及びメタデータオブジェクトのサブタイプ、例えばメタデータオブジェクトがファイルオブジェクトを表すのか、実行ファイルオブジェクトを表すのか、データベースオブジェクト又は別のサブタイプを表すのかを示す「サブタイプ」フィールドを含み得る。他の種類の特性も使用することができる。概して、種類フィールド３１２及び特性フィールド３１４は系統サーバ１０２の特定のインスタンスについてカスタマイズすることができ、本明細書で挙げる例に制限されない。

【0044】

データ構造は、前進辺３１６Ａ～Ｃ及び後退辺３１６Ｄ～Ｆを表すフィールドも含む。これらの辺フィールド３１６Ａ～Ｆは、系統サーバ１０２がデータ構造からデータ構造に「ウォーク」し、系統メタデータを集めるときデータ構造のデータを収集することを可能にする。最も広い意味で、部分データを「収集する」ことに言及する場合、将来のアクション（例えば収集したデータを伝送すること）に関係するものとしてデータの一部を識別することを意味する。データの一部を収集することはデータを複製すること、例えば将来のアクションに使用されるバッファ又は待ち行列にデータを複製することを含む場合がある。

【0045】

それぞれの辺フィールド３１６Ａ～Ｆは、ポインタフィールド３２０Ａ～Ｂを含む。ポインタフィールド３２０Ａ～Ｂは、それぞれのメモリ位置３２２Ａ～Ｂのアドレスを記憶する。概して、ポインタフィールド３２０Ａ～Ｂによって参照されるメモリ位置３２２Ａ～Ｂは、データ構造３００の別のインスタンスを記憶するメモリの部分を指す。このようにして、メタデータオブジェクトを表すデータ構造の或るインスタンスが、他のメタデータオブジェクトを表すデータ構造の１つ又は複数の他のインスタンスに「リンク」される。従って辺３１６Ａ～Ｄは、例えば図２Ａ～図２Ｅの系統図の例２００Ａ～Ｅの中で示すメタデータオブジェクト間の関係に対応し得る。例えば前進辺３１６Ａは、メタデータオブジェクト（例えばデータ構造３００のこのインスタンスによって表されるメタデータオブジェクト）が別のメタデータオブジェクト（例えばメモリ位置３２２Ａにあるデータ構造のインスタンスによって表されるメタデータオブジェクト）に有する影響を表す。別の例として、後退辺３１６Ｄは、別のメタデータオブジェクト（例えばメモリ位置３２２Ｂにあるデータ構造のインスタンスによって表されるメタデータオブジェクト）がデータ構造３００のこのインスタンスのメタデータオブジェクトに対して有する影響を表す。

【0046】

それぞれの辺フィールド３１６Ａ～Ｆは１つ又は複数のフラグ３２４も含む。フラグ３２４は、その関連する辺に関する情報のインジケータである。一部の例では、フラグ３２４の１つが、複数のあり得る種類から選択される関連する辺の種類を示し得る。多くの種類の辺があり得る。例えば一部の種類の辺は、入力／出力辺（或るオブジェクトからの出力及び別のオブジェクトへの入力を表す）、要素／データセット辺（要素と要素が属するデータセットとの間の関連を表す）、及びアプリケーション／親辺（実行可能アプリケーションとアプリケーションに関連するデータセットも含むコンテナ等のコンテナとの間の関連を表す）である。

【0047】

データ構造３００の要素の多くは典型的には相対的に少量のデータを使用する。例えば識別情報フィールド３１０、種類フィールド３１２、及び特性フィールド３１４に関連するデータは合わせても数バイト、例えば３２バイトにしかならない可能性がある。これらのフィールドは僅か数ビットの中に一般に使用される情報を符号化し、例えばノードについて８個のあり得る種類しかない場合、種類フィールド３１２は僅か３ビット長とすることができる。ノードの種類を表すテキストの文字列等のより複雑なデータは使用する必要がない。更に、メモリ位置３２２Ａ～Ｃに関連するデータは、典型的にはデータ構造３００をインスタンス化するソフトウェアを実行するコンピュータシステムの種類に関連するメモリアドレスの長さと同じデータ量である。従って、系統メタデータを記憶するための他の技法によって使用されるデータと比較し、データ構造３００の殆どの又は全てのインスタンスが相対的に少量のデータを合計で使用し得る。

【0048】

図４は、ウォークプラン４００の一例を示す。図１Ｃに関して上記で説明したように、ウォークプラン４００は典型的にはメタデータサーバ１０４によって記憶される。使用中、メタデータサーバ１０４は系統メタデータを要求するとき系統サーバ１０２にウォークプランを提供する。

【0049】

ウォークプラン４００は、系統サーバ１０２の記憶済みのデータ構造１３４を横断するとき系統サーバ１０２によって使用される情報を記述する。概して、系統メタデータ、例えば特定のメタデータオブジェクトに関係する系統メタデータに対するクエリを受信した場合、それに応答して全ての種類の系統メタデータを返す必要はない。一部の例では、クエリにもよるが、一部の種類の辺に関連する系統メタデータをクエリに応答したものではないことを理由に返す必要がない場合がある。

【0050】

従ってウォークプラン４００は、系統サーバ１０２によって記憶される系統メタデータによって表される辺の種類の中にあり得る辺の種類ごとにレコード４０２Ａ～Ｃを含む。レコード４０２Ａは、レコード４０２Ａに対応する辺の種類を示すデータを含む辺の種類フィールド４０４を含む。レコード４０２Ａは、前進方向４１０に関してフォローフラグ４０６、ノード収集フラグ４０８、及び辺収集フラグ４０９も含み、後退方向４１６に関してフォローフラグ４１２、ノード収集フラグ４１４、及び辺収集フラグ４１５も含む。

【0051】

フォローフラグ４０６、４１２は、系統サーバ１０２が自らのデータ構造１３４を横断するときこの辺の種類の辺をたどるべきかどうかを示す。言い換えれば、前進方向４１０のフォローフラグ４０６は系統サーバ１０２が、図３を参照してデータ構造３００のインスタンスの前進辺フィールド３１６Ａのポインタフィールド３２０Ａによって識別されるメモリ位置３２２Ａにアクセスすべきかどうかを示す。同様に、後退方向４１６のフォローフラグ４１２は系統サーバ１０２が、図３を参照してデータ構造３００のインスタンスの後退辺フィールド３１６Ｄのポインタフィールド３２０ｂによって識別されるメモリ位置３２２ｂにアクセスすべきかどうかを示す。

【0052】

ノード収集フラグ４０８、４１４は、系統サーバ１０２が自らのデータ構造１３４を横断するとき、この辺の種類によって指される「ノード」と呼ばれることがあるデータ構造３００（図３）のインスタンスを収集すべきかどうかを示す。データ構造３００のインスタンスを収集することに言及する場合、クエリを処理する系統サーバ１０２（図１Ａ）がクエリを処理することに応答して返されるデータにインスタンス（又はノード）のデータが追加されることを意味する。従ってノードが収集される場合、データ構造３００のインスタンスによって表されるメタデータオブジェクトに関連するデータは、系統サーバ１０２によって返される系統メタデータの中にある。

【0053】

辺収集フラグ４０９、４１５は、系統サーバ１０２が（例えばデータ構造３００のインスタンスのポインタフィールド３２０Ａに対応する）辺を収集すべきかどうかを示す。辺が収集される場合、辺を表すデータは系統サーバ１０２によって返される系統メタデータの中にある。一部の実装形態では、辺がノード間のデータフローを表さない場合はその辺を収集しなくても良い。例えば辺は、（或るノードによって表される）データオブジェクトと（別のノードによって表している）データオブジェクトのコンテナとの間の関連を表すことができる。このようにして、ウォークプラン４００内でノード収集フラグ４０８、４１４及び辺収集フラグ４０９、４１５を使用することにより、系統メタデータ内に含めるために収集される場合もされない場合もあるノードを様々なやり方で互いに関連させることができ、ノードは系統メタデータ内に含めるために収集される場合もされない場合もある様々なデータを表し得る。

【0054】

一部の実装形態では、使用中、ウォークプラン４００を１つ又は複数のＸＭＬ（拡張マーク付け原語）文書形式で表すことができる。ＸＭＬ文書は「タグ」によって分けられた部分の集合である。タグは典型的にはラベル（例えばタグの種類を識別するラベル）を含み、１つ又は複数の属性も含み得る。タグは開始タグ及び終了タグの形式で、開始タグが対応する終了タグと対にされるようにもたらされることがある。このようにしてタグは階層的とすることができ、そのため例えば別のタグの開始タグと終了タグとの対の間にタグを配置することにより、タグが他のタグの中に「ネスト」される。

【0055】

ＸＭＬ文書形式のウォークプランの一例を以下に示す：
<lineageServerPlan direction=“both”conditionalOnArg=“!autoFilterEnabled”replacesQueries=“walk”>
<useEdge name=“DE-Tr”>
<condition special=“ExelnterfaceCallStack” />
<condition special=“ControlFilter” />
<condition special=“Summarization” />
</useEdge>
<useEdge name=“Tr-DE”>
<condition special=“ExelnterfaceCallStack” />
<condition special=“ControlFilter” />
<condition special=“Summarization” />
</useEdge>
<useEdge name=“DE-DS”direction=“forward”collectEdge=“false”
conditionalOnArg=“walkDSlevel” />
<useEdge name=“Tr-Exe”direction=“forward”collectEdge=“false”
conditionalOnArg=“walkDSlevel” />
<useEdge name=“DS-Exe”conditionalOnArg=“walkDSlevel”>
<condition special=“ExeInterfaceCallStack” />
<condition special=“DSLevelIfNoDE” />
</useEdge>
<useEdge name=“Exe-DS”conditionalOnArg=“walkDSlevel”>
<condition special=“ExeInterfaceCallStack” />
<condition special=“DSLevelIfNoDE” />
</useEdge>
<useEdge name=“DE-DS”direction=“backward”collectEdge=“false”>
<condition special=“DSLevelIfNoDE” />
</useEdge>
<useEdge name=“Tr-Exe”direction=“backward”collectEdge=“false”>
<condition special=“DSLevelIfNoDE” />
</useEdge>
</lineageServerP1an>

【0056】

この例では、「useEdge」タグは所与の種類の辺に関する情報を指定する。各「useEdge」タグはレコード（例えばウォークプラン４００のレコード４０２Ａ～Ｃ）に対応し得る。「name」属性は辺の種類（例えば辺の種類４０４）を指定し、「direction」属性は方向（例えば前進方向４１０や後退方向４１６）を指定し、「collectEdge」属性は辺を収集するかどうかを指定する（例えば収集フラグ４０８、４１４）。他のタグも使用することができる。例えば上記の例の中で示した「condition special」タグは、指定の辺の種類の辺がたどられる場合に実行されるカスタム規則を指定するために使用される。一部の例では、辺をたどるべきかどうか及び／又は収集すべきかどうかを判定するための条件をカスタム規則が指定し得る。

【0057】

図５Ａは、専用データ構造、例えば図３に示すデータ構造３００によって定められる形式で系統メタデータを記憶するための手続き５００を表す流れ図を示す。手続き５００は、例えば図１Ａに示す系統サーバ１０２のコンポーネントによって実行され得る。

【0058】

この手続きは、メタデータソースに系統メタデータを要求する（５０２）。例えばメタデータソースは図１Ａに示すメタデータデータベース１０８とすることができる。この要求は定期的な間隔又は半定期的な間隔、例えば毎時、１０分ごと、１分ごと、又は他の任意の間隔で行われる要求であり得る。一部の例では、この要求がイベント、例えばメタデータソースにおいて新たなメタデータを入手できるという通知等のイベントに応答して行われ得る。

【0059】

系統メタデータは典型的には各ノードがメタデータオブジェクトを表すようにノード及び辺を記述し、辺は或るノードに対する別のノードの単向の影響をそれぞれ表し、例えばそのため各辺は単一の方向を有する。

【0060】

一部の例では、例えば系統サーバ１０２が系統メタデータを表す１組の最初のデータ構造をまだ生成していない場合、この要求はデータソースによって記憶されている全ての系統メタデータに対する要求である。一部の例では、例えば系統サーバ１０２が１組の既存の記憶済みデータ構造を更新している場合、この要求は前回の要求から追加され又は変更されている系統メタデータに対する要求である。

【0061】

この手続きはメタデータソースからデータ、例えば系統メタデータを受信する（５０４）。例えば系統メタデータは、メタデータオブジェクト及びメタデータオブジェクト間の関係を表すデータであり得る。

【0062】

この手続きはデータ構造、例えば図３に示すデータ構造３００のインスタンスを生成する（５０６）。例えばデータ構造は、メタデータソースから受信されるデータに対応する情報を含み得る。一部の例では、データ構造の各インスタンスがメタデータソースから受信されるそれぞれのノードに対応する。データ構造は識別値、例えばデータ構造のインスタンスに対応するノードを識別する識別値のためのフィールドを含み得る。データ構造は、データ構造のインスタンスに対応するノードの特性を表す特性フィールドも含み得る。データ構造は、他のノードの識別値へのポインタも可能であり、そのためポインタはそれぞれの識別値に対応するノードへの辺を表す。

【0063】

この手続きはデータ構造を記憶する（５０８）。例えばデータ構造はメモリ、例えば図１Ｃに示すメモリ１３５内に記憶することができる。一部の例では、データ構造がランダムアクセスメモリ内に記憶される。データ構造は系統メタデータを記憶するために使用されるので、系統に関係しない任意のデータ（例えばメタデータソースに記憶されている他の種類のメタデータ）を省き、データ構造を記憶するのに必要なデータ量を減らすことができる。

【0064】

使用中、この手続きは例えば定期的にスケジュールされた次の間隔で、メタデータソースに系統メタデータを要求すること（５０２）に戻る。

【0065】

図５Ｂは、系統メタデータを表示させるための手続き５２０を表す流れ図を示す。手続き５２０は、例えば図１Ａに示す系統サーバ１０２のコンポーネントによって実行され得る。概して系統サーバは特定のデータ要素、例えばメタデータオブジェクトの系統を記述するメタデータを含む、クエリに対する応答を返すように構成される。一部の例では、メタデータはノード及び辺のシーケンスを記述し、そのシーケンスのノードのうちの１つは特定のデータ要素を表す。一部の例では、図５Ａに関して上記で説明した手続き５００によって記憶される系統メタデータにアクセスするために手続き５２０が使用される。

【0066】

この手続きはクエリ、例えば系統メタデータに対するクエリを受信する（５２２）。一部の例では、このクエリは系統メタデータが要求されるメタデータオブジェクトを識別する。

【0067】

一部の実装形態では、このクエリは系統の種類の識別、及び識別される系統の種類にどの種類の辺が関連するのかを識別するウォークプランを含む。一部の例では、ウォークプランは、対応するノードのそれぞれの特性を表す１つ又は複数の特性値に基づいて辺をたどり又は収集するための条件を含む。ウォークプラン４００の一例を図４に示す。

【0068】

この手続きは系統メタデータを集める（５２４）。例えば、受信クエリのメタデータオブジェクトを表すノードにアクセスしそれを収集することができ、他のノードを収集するために辺（例えばメモリ位置へのポインタ）を横断することができる。系統メタデータを集めることについては図６に関して以下でより詳細に説明する。

【0069】

この手続きは、集めた系統メタデータを伝送する（５２６）。例えば、集めた系統メタデータはクエリを発行したコンピュータシステムに伝送することができる。

【0070】

集めた系統メタデータの伝送後、集めた系統メタデータがコンピュータシステム、例えば図１Ａに示すユーザ端末１１６上で表示させられる場合がある（５２８）。例えば系統メタデータは、図２Ａ～図２Ｅに示す系統図２００Ａ～２００Ｅ等の系統図の形式で表示することができる。

【0071】

図６は、専用データ構造、例えば図３に示すデータ構造３００のインスタンスの形式で記憶される系統メタデータを横断するための手続き６００を表す流れ図を示す。手続き６００は、例えば図１Ａに示す系統サーバ１０２のコンポーネントによって実行され得る。

【0072】

この手続きはクエリ及びウォークプラン、例えば図１Ｃに示すクエリ１１４及びウォークプラン１３０を受信する（６０２）。この手続きは、クエリ１１４によって参照されるメタデータオブジェクトを表す初期ノード（例えば図３に示すデータ構造３００のインスタンス）にアクセスアクセスする（６０４）。例えば初期ノードは、メタデータオブジェクトに関連するデータを記憶する識別情報フィールド３１０（図３）によって識別され得る。次いでその初期ノードが「現在の」ノードとして使用され、待ち行列から現在のノードが選択され、現在のノードに操作が適用されるこのプロセスの再帰的な部分が始まる。言い換えれば、初期ノードは待ち行列の最初のノードとして待ち行列内に配置され、この手続きが実行されるにつれて他のノードが続いて待ち行列に追加される。

【0073】

この手続きは、現在のノード内に残っている前進辺ポインタ（例えばまだアクセスされていない前進辺ポインタ）があるかどうかを判定する（６０６）。かかる前進辺ポインタがある場合、この手続きはまだアクセスされていない次のポインタにアクセスし（６０８）、例えばポインタのメモリ位置にアクセスしてそのメモリ位置に記憶されているデータを取得する。この手続きは、例えばポインタに関連する辺の種類に従い、（図４に関して上記で説明した）ウォークプランに基づいてそのポインタにおけるノードを「ウォーク」（例えば処理）するかどうかを判定する（６１０）。ウォークしない場合、この手続きは別のポインタにアクセスする（６０８）。ウォークする場合、この手続きはそのポインタにおけるノードを収集するかどうかを判定する（６１１）。収集する場合、この手続きはクエリに応答して返されるノードのデータを記憶し（６１２）、次いでそのポインタにアクセスできるようにそのノードを待ち行列内に配置する（６１４）。収集しない場合、この手続きはノードを待ち行列内に入れるだけである。

【0074】

現在のノード内の前進辺ポインタの全てが横断されると、この手続きは現在のノード内に残っている後退辺ポインタがあるかどうかを判定する（６１６）。かかる後退辺ポインタがある場合、この手続きは次の後退辺ポインタにアクセスする（６０８）。

【0075】

前進辺ポインタ又は後退辺ポインタが残っていない場合、この手続きは待ち行列内にノードがどれか残っているかどうかを判定する（６１８）。残っている場合、この手続きは待ち行列内の次のノードにアクセスし（６２０）、待ち行列内の次のノードを現在のノードとして使用して上記の操作を実行する。ノードが残っていない場合、この手続きは他のシステムに伝送するために収集済みのデータを準備する（６２２）。例えば収集済みのデータは伝送されるので、特定の形式で構成することができる。別の例として、収集済みのデータ内の符号化データを復号することができる。例えば符号化値を含むデータフィールドは値に対応するテキスト文字列に変換することができる。

【0076】

データを伝送する準備ができると、例えば図５Ｂのデータ伝送５２６に関して説明したようにデータを伝送することができる。

【0077】

本明細書に記載したシステム及び技法は、例えば適切なソフトウェア命令を実行するプログラム可能計算システムを使用して実装することができ、書替え可能ゲートアレイ（ＦＰＧＡ）等の適切なハードウェアによって実装することができ、又は何らかの混成形式で実装することができる。例えばプログラムされた手法では、１つ又は複数のプログラムされた計算システム又はプログラム可能な計算システム（分散、クライアント／サーバ、又はグリッド等の様々なアーキテクチャのものであり得る）上で実行される１つ又は複数のコンピュータプログラム内の手続きをソフトウェアが含むことができ、かかる計算システムは少なくとも１個のプロセッサ、（揮発性及び／又は不揮発性のメモリ及び／又は記憶要素を含む）少なくとも１つのデータ記憶システム、（少なくとも１つの入力装置又はポートを使用して入力を受け付け、少なくとも１つの出力装置又はポートを使用して出力を行うための）少なくとも１つのユーザインタフェースをそれぞれ含む。ソフトウェアは、例えばデータフローグラフの設計、構成、及び実行に関係するサービスを提供するより大きいプログラムの１つ又は複数のモジュールを含み得る。プログラムのモジュール（例えばデータフローグラフの要素）は、データリポジトリ内に記憶されるデータモデルに従うデータ構造又は他の組織化されたデータとして実装され得る。

【0078】

揮発性記憶媒体や不揮発性記憶媒体又は他の任意の非一時的媒体の中に具体化されるもの等、或る期間（例えばダイナミックＲＡＭ等のダイナミックメモリ装置のリフレッシュ期間の間の時間）にわたって媒体の物理的特性（例えば表面ピット及びランド、磁区、電荷）を使用してソフトウェアを非一時的な形式で記憶することができる。命令をロードすることに備えて、ソフトウェアは、（例えば汎用又は専用の計算システム又は計算装置によって読出し可能な）ＣＤ－ＲＯＭや他のコンピュータ可読媒体等の有形の非一時的媒体上に与えることができ、又はソフトウェアがそこで実行される計算システムの有形の非一時的媒体までネットワークの通信媒体上で届けられ得る（例えば伝搬信号内に符号化される）。処理の一部又は全てが専用コンピュータ上で、又はコプロセッサ、書替え可能ゲートアレイ（ＦＰＧＡ）、専用の特定用途向け集積回路（ＡＳＩＣ）等の専用ハードウェアを使用して実行され得る。処理は分散式に実装されても良く、その場合ソフトウェアによって指定される計算の異なる部分が異なる計算要素によって実行される。本明細書に記載した処理を実行するために記憶装置媒体がコンピュータによって読み出されるときコンピュータを構成し動作させるために、そのような各コンピュータプログラムは、好ましくは汎用又は専用のプログラム可能コンピュータによってアクセス可能な記憶装置のコンピュータ可読記憶媒体（例えばソリッドステートメモリ又は媒体、磁気媒体、光学媒体）上に記憶され又はかかるコンピュータ可読記憶媒体にダウンロードされる。本発明のシステムは、コンピュータプログラムで構成される有形の非一時的媒体として実装されると考えられる場合もあり、そのように構成される媒体は本明細書に記載した処理ステップの１つ又は複数を実行するようにコンピュータを特定の且つ既定のやり方で動作させる。

【0079】

本発明の幾つかの実施形態を説明してきた。それでもなお、上記の説明は添付の特許請求の範囲によって定める本発明の範囲を限定するのではなく例示することを目的としていることを理解すべきである。従って他の実施形態も以下の特許請求の範囲に含まれる。例えば本発明の範囲から逸脱することなしに様々な修正を加えることができる。加えて、上記のステップの一部は順序に依存しない場合があり、従って説明したのと異なる順序で実行することができる。

【図1A】

【図1B】

【図1C】

【図1D】

【図2A】

【図2B】

【図2C】

【図2D】

【図2E】

【図3】

【図4】

【図5A】

【図5B】

【図6】