(57)【要約】      （修正有）【課題】 任意の単位でマスタデータを更新することが可能であると共に、同時進行する編集の競合を事前に把握することができる。【解決手段】編集システムにおいて、利用者は、マスタＤＢ１からマスタデータの一部を編集前部分文書１０として取得し、編集を行うことで編集後部分文書２０を作成する。サーバ３０は編集前部分文書１０と編集後部分文書２０とに基づいて差分情報を検出する。そして、サーバ３０は、検出した差分情報に基づいて、利用者が行った編集の履歴を複数のレコードから構成される編集履歴として編集履歴ＤＢ４へ記憶する。さらに、サーバ３０は、各レコードに対して編集の状態を示すステータスに基づいて競合する編集があるか否かを判定する。競合する編集がある場合、サーバ３０は、ステータスの再設定を行う。一方、競合する編集がない場合、マスタＤＢ１に記憶されたマスタデータの更新を行う。【選択図】    図２
2006163912.tif 000002
【特許請求の範囲】
【請求項１】
端末及び当該端末とデータの送受信が可能なサーバから構成される編集システムであって、
前記サーバは、
階層構造の文書をマスタデータとして記憶するマスタ記憶部と、
前記文書は階層構造の一部を部分的に編集することが可能であって、編集前部分文書と編集後部分文書の差分情報を取得する差分情報取得手段と、
前記差分情報に基づいて、前記編集の履歴を複数レコードから構成される編集履歴として記憶する編集履歴記憶部と、
前記レコードの編集状態を示すステータスを設定する初期ステータス設定手段と、
前記レコードのステータスに基づいて、前記編集が競合しているか否かを判定する競合判定手段と、
前記競合判定手段が競合があると判定した場合に、競合している編集に対応するレコードのステータスを再設定した後、前記競合判定手段により、前記編集が競合しているか否かを再度判定するステータス再設定手段と、
前記編集後部分文書を取得する編集後部分文書取得手段と、
前記競合判定手段が競合がないと判定した場合に、前記レコード及び前記編集後部分文書に基づいて前記マスタデータを更新するマスタ更新手段と、を備え、
前記端末は、
前記マスタ記憶部から、前記マスタデータの一部を前記編集前部分文書として抽出する編集前部分文書抽出手段と、
前記編集前部分文書を編集し、編集後部分文書を作成する編集後部分文書作成手段と、
前記編集前部分文書と前記編集後部分文書の差分情報を取得する差分情報取得手段と、
前記差分情報をサーバへ送信する差分情報送信手段と、
前記編集後部分文書を送信する編集後部分文書送信手段と、を備えることを特徴とする編集システム。
【請求項２】
端末及び当該端末とデータの送受信が可能なサーバから構成される編集システムであって、
前記サーバは、
階層構造の文書をマスタデータとして記憶するマスタ記憶部と、
前記文書は階層構造の一部を部分的に編集することが可能であって、編集前部分文書と編集後部分文書の差分情報を取得する差分情報取得手段と、
前記差分情報に基づいて、前記編集の履歴を複数レコードから構成される編集履歴として記憶する編集履歴記憶部と、
前記レコードの編集状態を示すステータスを設定する初期ステータス設定手段と、
前記レコードのステータスに基づいて、前記編集が競合しているか否かを判定する競合判定手段と、
前記競合判定手段が競合があると判定した場合に、競合している編集に対応するレコードのステータスを再設定した後、前記競合判定手段により、前記編集が競合しているか否かを再度判定するステータス再設定手段と、
前記編集後部分文書を取得する編集後部分文書取得手段と、
前記競合判定手段が競合がないと判定した場合に、前記レコード及び前記編集後部分文書に基づいて前記マスタデータを更新するマスタ更新手段と、を備え、
前記端末は、前記マスタ記憶部から、前記マスタデータの一部を前記編集前部分文書として抽出する編集前部分文書抽出手段と、
前記編集前部分文書を編集し、編集後部分文書を作成する編集後部分文書作成手段と、
前記編集後部分文書を送信する編集後部分文書送信手段と、を備えることを特徴とする編集システム。
【請求項３】
階層構造の文書をマスタデータとして記憶するマスタ記憶部と、
前記文書は階層構造の一部を部分的に編集することが可能であって、編集前部分文書と編集後部分文書の差分情報を取得する差分情報取得手段と、
前記差分情報に基づいて、前記編集の履歴を複数レコードから構成される編集履歴として記憶する編集履歴記憶部と、
前記レコードの編集状態を示すステータスを設定する初期ステータス設定手段と、
前記レコードのステータスに基づいて、前記編集が競合しているか否かを判定する競合判定手段と、
前記競合判定手段が競合があると判定した場合に、競合している編集に対応するレコードのステータスを再設定した後、前記競合判定手段により、前記編集が競合しているか否かを再度判定するステータス再設定手段と、
前記編集後部分文書を取得する編集後部分文書取得手段と、
前記競合判定手段が競合がないと判定した場合に、前記レコード及び前記編集後部分文書に基づいて前記マスタデータを更新するマスタ更新手段と、を備えることを特徴とするサーバ。
【請求項４】
階層構造の文書をマスタデータとして記憶するマスタ記憶部と、
前記文書は階層構造の一部を部分的に編集することが可能であって、前記編集後部分文書を取得する編集後部分文書取得手段と、
編集前部分文書と前記編集後部分文書の差分情報を検出する差分情報検出手段と、
前記差分情報に基づいて、前記編集の履歴を複数レコードから構成される編集履歴として記憶する編集履歴記憶部と、
前記レコードの編集状態を示すステータスを設定する初期ステータス設定手段と、
前記レコードのステータスに基づいて、前記編集が競合しているか否かを判定する競合判定手段と、
前記競合判定手段が競合があると判定した場合に、競合している編集に対応するレコードのステータスを再設定した後、前記競合判定手段により、前記編集が競合しているか否かを再度判定するステータス再設定手段と、
前記競合判定手段が競合がないと判定した場合に、前記レコード及び前記編集後部分文書に基づいて前記マスタデータを更新するマスタ更新手段と、を備えることを特徴とするサーバ。
【請求項５】
前記マスタデータは、編集を管理する単位となる要素毎に要素ＩＤが付与されており、
前記レコードは、対応する要素ＩＤ、更新の種別を示す更新種別、複数の要素から構成されるグループ毎に付与されたグループＩＤとを有しており、
前記差分検出手段は、
前記編集前部分文書において前記差分検出の対象となる対象要素に、当該対象要素より１つ下の階層に位置しており、前記要素ＩＤが付与された子要素が存在するか否かを判定する編集前子要素判定手段と、
前記編集前子要素判定手段が存在すると判定した場合に、前記編集前部分文書から前記要素ＩＤが付与された子要素を取得する編集前子要素取得手段と、
取得した子要素に付与された要素ＩＤを取得するＩＤ取得手段と、
取得した要素ＩＤが、前記編集後部分文書において対応する前記対象要素の子要素に付与された要素ＩＤとして存在するか否かを判定する編集後ＩＤ判定手段と、
前記編集後ＩＤ判定手段が存在しないと判定した場合に、前記編集前部分文書における前記子要素と、当該子要素より下位階層に位置しており、前記要素ＩＤが付与された子孫要素とに対応するレコードの更新種別に削除を設定する削除設定手段と、
前記編集後ＩＤ判定手段が存在しないと判定した場合に、前記編集前部分文書における前記子要素と前記子孫要素とに対応するレコードのグループＩＤに、当該子要素のＩＤを設定する削除グループＩＤ設定手段と、をさらに備えることを特徴とする請求項４に記載のサーバ。
【請求項６】
前記レコードは、対応する要素より１つ上の階層に位置した親要素の要素ＩＤである親要素ＩＤをさらに有しており、
前記差分検出手段は、
前記編集後部分文書において前記差分検出の対象となる対象要素に、当該対象要素より１つ下の階層に位置しており、前記要素ＩＤが付与された子要素が存在するか否かを判定する編集後子要素判定手段と、
前記編集後子要素判定手段が存在すると判定した場合に、前記編集後部分文書から前記要素ＩＤが付与された子要素を取得する編集後子要素取得手段と、
取得した子要素に付与された要素ＩＤを取得するＩＤ取得手段と、
取得した要素ＩＤが、前記編集前部分文書において対応する前記対象要素の子要素に付与された要素ＩＤとして存在するか否かを判定する編集前ＩＤ判定手段と、
前記編集前ＩＤ判定手段が存在しないと判定した場合に、前記編集後部分文書における前記子要素と、当該子要素より下位階層に位置しており、前記要素ＩＤが付与された子孫要素とに対応するレコードの更新種別に追加を設定する追加設定手段と、
前記編集前ＩＤ判定手段が存在しないと判定した場合に、前記編集後部分文書における前記子要素と前記子孫要素とに対応するレコードのグループＩＤに、当該子要素の要素ＩＤを設定する追加グループＩＤ設定手段と、
前記編集前ＩＤ判定手段が存在しないと判定した場合に、前記編集後部分文書における前記子要素に対応するレコードの親要素ＩＤに、当該子要素の親要素の要素ＩＤを設定する親要素ＩＤ設定手段と、をさらに備えることを特徴とする請求項５に記載のサーバ。
【請求項７】
前記差分検出手段は、
編集前部分文書において下位階層に前記要素ＩＤが付与されていないデータが存在する要素を対象要素として設定する対象要素設定手段と、
前記対象要素配下の要素ＩＤが付与されていないデータを、前記編集後部分文書の当該要素ＩＤに対応する要素配下の要素ＩＤが付与されていないデータと比較する比較手段と、
前記比較手段による比較の結果、差があると判定した場合に、前記対象要素に対応するレコードの更新種別に修正を設定する修正設定手段と、を備えることを特徴とする請求項５又は６に記載のサーバ。
【請求項８】
前記マスタデータは、要素毎にデータバージョンが付与されており、
前記レコードは、前記データバージョンと、部分文書毎の編集プロセスであるジョブのＩＤであるジョブＩＤをさらに備え、
前記ステータスは、放棄、更新対象及び更新完了のいずれか１つが設定されるものであって、
前記初期ステータス設定手段は、
前記ステータスが未設定であって、ジョブＩＤ、グループＩＤ及び更新種別が同一の全てのレコードを、同一のステータスを設定する同ステータスレコード群に設定する第１レコード群設定手段と、
前記ステータスが未設定であって、ジョブＩＤ及び要素ＩＤが同一のレコードを、前記同ステータスレコード群に設定する第２レコード群設定手段と、
前記編集履歴記憶部に、前記同ステータスレコード群に属するレコードと異なるジョブＩＤであって、データバージョンが一致するレコードが存在するか否かを判定するジョブＩＤ判定手段と、
前記ジョブＩＤ判定手段が存在すると判定した場合に、前記同ステータスレコード群に属するレコードと異なるジョブＩＤであってデータバージョンが一致するレコードの中に、ステータスが更新完了のレコードが存在するか否かを判定する更新完了判定手段と、
前記更新完了判定手段が存在すると判定した場合に、前記同ステータスレコード群に属する全てのレコードに放棄を設定する放棄設定手段と、
前記ジョブＩＤ判定手段及び前記更新完了判定手段のいずれか１つ以上が存在しないと判定した場合に、前記同ステータスレコード群に属する全てのレコードに更新対象を設定する更新対象設定手段と、をさらに備えることを特徴とする請求項５乃至７のいずれか一項に記載のサーバ。
【請求項９】
前記競合判定手段は、前記編集履歴記憶部に、ステータスが更新対象であって、ジョブＩＤが異なり、要素ＩＤ及びデータバージョンが一致するレコードが複数存在する場合に前記編集が競合していると判定するものであって、
前記ステータス再設定手段は、ジョブＩＤ、グループＩＤ及び更新種別が同一のレコード、並びに、ジョブＩＤ及び要素ＩＤが同一のレコードには同一のステータスを設定することを特徴とする請求項５乃至８のいずれか一項に記載のサーバ。
【請求項１０】
前記マスタ更新手段は、
前記編集履歴記憶部から、ステータスが更新対象であって、更新種別が削除であるレコードを抽出する削除レコード抽出手段と、
前記削除レコードに基づいて、グループＩＤと要素ＩＤが一致するか否かを判定する削除ＩＤ判定手段と、
前記削除ＩＤ判定手段が一致すると判定した場合に、当該削除レコードのＩＤに対応するマスタデータの要素を削除する削除手段と、
前記削除レコードのステータスを更新完了に設定する削除完了設定手段と、を備えることを特徴とする請求項５乃至９のいずれか一項に記載のサーバ。
【請求項１１】
前記マスタ更新手段は、
前記編集履歴記憶部から、ステータスが更新対象であって、更新種別が追加であるレコードを抽出する追加レコード抽出手段と、
前記追加レコードに基づいて、グループＩＤと要素ＩＤが一致するか否かを判定する追加ＩＤ判定手段と、
前記追加ＩＤ判定手段が一致すると判定した場合に、当該追加レコードのＩＤに対応する編集後部分文書の要素を、前記マスタデータに親要素ＩＤの子要素として追加する追加手段と、
前記追加レコードのステータスを更新完了に設定する追加完了設定手段と、
前記追加手段が追加した要素のデータバージョンを更新する追加更新手段と、を備えることを特徴とする請求項６乃至１０のいずれか一項に記載のサーバ。
【請求項１２】
前記マスタ更新手段は、
前記編集履歴記憶部から、ステータスが更新対象であって、更新種別が修正であるレコードを抽出する修正レコード抽出手段と、
前記修正レコードの要素ＩＤに対応する要素配下の要素ＩＤが付与されていないデータを、前記マスタデータから削除する修正削除手段と、
前記編集後部分文書における修正レコードの要素ＩＤに対応する要素配下の要素ＩＤが付与されていないデータを、前記マスタデータに追加する修正追加手段と、
前記修正レコードのステータスを更新完了に設定する修正完了設定手段と、
前記修正追加手段が追加したデータに対応する要素のデータバージョンを更新する修正更新手段と、を備えることを特徴とする請求項７乃至１１のいずれか一項に記載のサーバ。
【請求項１３】
前記削除レコード抽出手段、前記削除ＩＤ判定手段、前記削除手段及び前記削除完了設定手段は、前記追加レコード抽出手段、前記追加ＩＤ判定手段、前記追加手段、前記追加完了設定手段及び前記追加更新手段より前に行われることを特徴とする請求項１１及び１２に記載のサーバ。
【請求項１４】
コンピュータにより実行されるプログラムであって、
階層構造の文書をマスタデータとして記憶するマスタ記憶手段、
前記文書は階層構造の一部を部分的に編集することが可能であって、編集前部分文書と編集後部分文書の差分情報を取得する差分情報取得手段、
前記差分情報に基づいて、前記編集の履歴を複数レコードから構成される編集履歴として記憶する編集履歴記憶手段、
前記レコードの編集状態を示すステータスを設定する初期ステータス設定手段、
前記レコードのステータスに基づいて、前記編集が競合しているか否かを判定する競合判定手段、
前記競合判定手段が競合があると判定した場合に、競合している編集に対応するレコードのステータスを再設定した後、前記競合判定手段により、前記編集が競合しているか否かを再度判定するステータス再設定手段、
前記編集後部分文書を取得する編集後部分文書取得手段、
前記競合判定手段が競合がないと判定した場合に、前記レコード及び前記編集後部分文書に基づいて前記マスタデータを更新するマスタ更新手段、として前記コンピュータを機能させることを特徴とするプログラム。
【請求項１５】
コンピュータにより実行されるプログラムであって、
階層構造の文書をマスタデータとして記憶するマスタ記憶手段、
前記文書は階層構造の一部を部分的に編集することが可能であって、前記編集後部分文書を取得する編集後部分文書取得手段、
編集前部分文書と前記編集後部分文書の差分情報を検出する差分情報検出手段、
前記差分情報に基づいて、前記編集の履歴を複数レコードから構成される編集履歴として記憶する編集履歴記憶手段、
前記レコードの編集状態を示すステータスを設定する初期ステータス設定手段、
前記レコードのステータスに基づいて、前記編集が競合しているか否かを判定する競合判定手段、
前記競合判定手段が競合があると判定した場合に、競合している編集に対応するレコードのステータスを再設定した後、前記競合判定手段により、前記編集が競合しているか否かを再度判定するステータス再設定手段、
前記競合判定手段が競合がないと判定した場合に、前記レコード及び前記編集後部分文書に基づいて前記マスタデータを更新するマスタ更新手段、として前記コンピュータを機能させることを特徴とするプログラム。
【請求項１６】
前記マスタデータは、編集を管理する単位となる要素毎に要素ＩＤが付与されており、
前記レコードは、対応する要素ＩＤ、更新の種別を示す更新種別、複数の要素から構成されるグループ毎に付与されたグループＩＤとを有しており、
前記プログラムは、
前記編集前部分文書において前記差分検出の対象となる対象要素に、当該対象要素より１つ下の階層に位置しており、前記要素ＩＤが付与された子要素が存在するか否かを判定する編集前子要素判定手段、
前記編集前子要素判定手段が存在すると判定した場合に、前記編集前部分文書から前記要素ＩＤが付与された子要素を取得する編集前子要素取得手段、
取得した子要素に付与された要素ＩＤを取得するＩＤ取得手段、
取得した要素ＩＤが、前記編集後部分文書において対応する前記対象要素の子要素に付与された要素ＩＤとして存在するか否かを判定する編集後ＩＤ判定手段、
前記編集後ＩＤ判定手段が存在しないと判定した場合に、前記編集前部分文書における前記子要素と、当該子要素より下位階層に位置しており、前記要素ＩＤが付与された子孫要素とに対応するレコードの更新種別に削除を設定する削除設定手段、
前記編集後ＩＤ判定手段が存在しないと判定した場合に、前記編集前部分文書における前記子要素と前記子孫要素とに対応するレコードのグループＩＤに、当該子要素のＩＤを設定する削除グループＩＤ設定手段、としてさらに前記コンピュータを機能させることを特徴とする請求項１５に記載のプログラム。
【請求項１７】
前記レコードは、対応する要素より１つ上の階層に位置した親要素の要素ＩＤである親要素ＩＤをさらに有しており、
前記プログラムは、
前記編集後部分文書において前記差分検出の対象となる対象要素に、当該対象要素より１つ下の階層に位置しており、前記要素ＩＤが付与された子要素が存在するか否かを判定する編集後子要素判定手段、
前記編集後子要素判定手段が存在すると判定した場合に、前記編集後部分文書から前記要素ＩＤが付与された子要素を取得する編集後子要素取得手段、
取得した子要素に付与された要素ＩＤを取得するＩＤ取得手段、
取得した要素ＩＤが、前記編集前部分文書において対応する前記対象要素の子要素に付与された要素ＩＤとして存在するか否かを判定する編集前ＩＤ判定手段、
前記編集前ＩＤ判定手段が存在しないと判定した場合に、前記編集後部分文書における前記子要素と、当該子要素より下位階層に位置しており、前記要素ＩＤが付与された子孫要素とに対応するレコードの更新種別に追加を設定する追加設定手段、
前記編集前ＩＤ判定手段が存在しないと判定した場合に、前記編集後部分文書における前記子要素と前記子孫要素とに対応するレコードのグループＩＤに、当該子要素の要素ＩＤを設定する追加グループＩＤ設定手段、
前記編集前ＩＤ判定手段が存在しないと判定した場合に、前記編集後部分文書における前記子要素に対応するレコードの親要素ＩＤに、当該子要素の親要素の要素ＩＤを設定する親要素ＩＤ設定手段、としてさらに前記コンピュータを機能させることを特徴とする請求項１６に記載のプログラム。
【請求項１８】
前記プログラムは、
編集前部分文書において下位階層に前記要素ＩＤが付与されていないデータが存在する要素を対象要素として設定する対象要素設定手段、
前記対象要素配下の要素ＩＤが付与されていないデータを、前記編集後部分文書の当該要素ＩＤに対応する要素配下の要素ＩＤが付与されていないデータと比較する比較手段、
前記比較手段による比較の結果、差があると判定した場合に、前記対象要素に対応するレコードの更新種別に修正を設定する修正設定手段、としてさらに前記コンピュータを機能させることを特徴とする請求項１６又は１７に記載のプログラム。
【請求項１９】
前記マスタデータは、要素毎にデータバージョンが付与されており、
前記レコードは、前記データバージョンと、部分文書毎の編集プロセスであるジョブのＩＤであるジョブＩＤをさらに備え、
前記ステータスは、放棄、更新対象及び更新完了のいずれか１つが設定されるものであって、
前記初期ステータス設定手段は、
前記ステータスが未設定であって、ジョブＩＤ、グループＩＤ及び更新種別が同一の全てのレコードを、同一のステータスを設定する同ステータスレコード群に設定する第１レコード群設定手段、
前記ステータスが未設定であって、ジョブＩＤ及び要素ＩＤが同一のレコードを、前記同ステータスレコード群に設定する第２レコード群設定手段、
前記編集履歴記憶部に、前記同ステータスレコード群に属するレコードと異なるジョブＩＤであって、データバージョンが一致するレコードが存在するか否かを判定するジョブＩＤ判定手段、
前記ジョブＩＤ判定手段が存在すると判定した場合に、前記同ステータスレコード群に属するレコードと異なるジョブＩＤであってデータバージョンが一致するレコードの中に、ステータスが更新完了のレコードが存在するか否かを判定する更新完了判定手段、
前記更新完了判定手段が存在すると判定した場合に、前記同ステータスレコード群に属する全てのレコードに放棄を設定する放棄設定手段、
前記ジョブＩＤ判定手段及び前記更新完了判定手段のいずれか１つ以上が存在しないと判定した場合に、前記同ステータスレコード群に属する全てのレコードに更新対象を設定する更新対象設定手段、としてさらに前記コンピュータを機能させることを特徴とする請求項１６乃至１８のいずれか一項に記載のプログラム。
【請求項２０】
前記競合判定手段は、前記編集履歴記憶部に、ステータスが更新対象であって、ジョブＩＤが異なり、要素ＩＤ及びデータバージョンが一致するレコードが複数存在する場合に前記編集が競合していると判定するものであって、
前記ステータス再設定手段は、ジョブＩＤ、グループＩＤ及び更新種別が同一のレコード、並びに、ジョブＩＤ及び要素ＩＤが同一のレコードには同一のステータスを設定することを特徴とする請求項１６乃至１９のいずれか一項に記載のプログラム。
【請求項２１】
前記プログラムは、
前記編集履歴記憶手段から、ステータスが更新対象であって、更新種別が削除であるレコードを抽出する削除レコード抽出手段、
前記削除レコードに基づいて、グループＩＤと要素ＩＤが一致するか否かを判定する削除ＩＤ判定手段、
前記削除ＩＤ判定手段が一致すると判定した場合に、当該削除レコードのＩＤに対応するマスタデータの要素を削除する削除手段、
前記削除レコードのステータスを更新完了に設定する削除完了設定手段、として前記コンピュータを機能させることを特徴とする請求項１６乃至２０のいずれか一項に記載のプログラム。
【請求項２２】
前記プログラムは、
前記編集履歴記憶手段から、ステータスが更新対象であって、更新種別が追加であるレコードを抽出する追加レコード抽出手段、
前記追加レコードに基づいて、グループＩＤと要素ＩＤが一致するか否かを判定する追加ＩＤ判定手段、
前記追加ＩＤ判定手段が一致すると判定した場合に、当該追加レコードのＩＤに対応する編集後部分文書の要素を、前記マスタデータに親要素ＩＤの子要素として追加する追加手段、
前記追加レコードのステータスを更新完了に設定する追加完了設定手段、
前記追加手段が追加した要素のデータバージョンを更新する追加更新手段、としてさらに前記コンピュータを機能させることを特徴とする請求項１７乃至２１のいずれか一項に記載のプログラム。
【請求項２３】
前記プログラムは、
前記編集履歴記憶手段から、ステータスが更新対象であって、更新種別が修正であるレコードを抽出する修正レコード抽出手段、
前記修正レコードの要素ＩＤに対応する要素配下の要素ＩＤが付与されていないデータを、前記マスタデータから削除する修正削除手段、
前記編集後部分文書における修正レコードの要素ＩＤに対応する要素配下の要素ＩＤが付与されていないデータを、前記マスタデータに追加する修正追加手段、
前記修正レコードのステータスを更新完了に設定する修正完了設定手段、
前記修正追加手段が追加したデータに対応する要素のデータバージョンを更新する修正更新手段、としてさらに前記コンピュータを機能させることを特徴とする請求項１８乃至２２のいずれか一項に記載のプログラム。
【請求項２４】
前記削除レコード抽出手段、前記削除ＩＤ判定手段、前記削除手段及び前記削除完了設定手段は、前記追加レコード抽出手段、前記追加ＩＤ判定手段、前記追加手段、前記追加完了設定手段及び前記追加更新手段より前に行われることを特徴とする請求項２２及び２３に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、１つのマスタデータを複数人が並行して編集する場合の競合を制御するための技術に関する。
【背景技術】
【０００２】
第１に、文書を動的に編集する技術として、構造化文書をツリー表示する等、構造とテキストとを関連付けて編集する仕組みが多数存在している（特許文献１乃至３）。しかし、構造化文書全体をＤＯＭ（Document Object Model）等を用いてメモリに展開し、ツリー表示や編集を行う仕組みにおいては、当該構造化文書のサイズが大きい場合に大量のハードウェアリソースを要し、動作が悪くなるといった問題が生じていた。
【０００３】
第２に、共有文書を複数人で編集する技術として、構造化文書の構造を反映したまま格納するＸＭＬ（eXtensible Markup Language）ＤＢやＯＤＢが存在している。このようなＤＢやＸＭＬエディタ、ワープロソフト等では、複数のトランザクションによる更新処理を排他制御することができる。また、共有文書を複数人で同時に編集する際に、他者による更新の通知手法も公開されている。具体的には、共有文書を同時に参照・編集する仕組みにおいて、所定の利用者が当該文書を参照中に、別の利用者によって当該文書が更新された場合には、その内容を通知する手法が公開されている（特許文献４及び５）。
しかし、既存のＸＭＬＤＢやＸＭＬエディタ等では、複数のトランザクションによる更新処理を排他制御することができるに止まり、正常に更新された文書の内容が他人によって意図せず上書きされることは問題としていない。例えば、要素Ａと、要素Ａを子要素に持つ要素Ｂを含む構造化文書を編集する場合において、要素Ａを編集中の編集者ａと、要素Ｂを編集中の編集者ｂが存在した際に、編集者ａが更新を行った後、編集者ｂが更新を行うことで、要素Ｂによって要素Ａの内容が上書きされることは問題としていない。即ち、既存の技術では、このような競合に適切に対応することができない。
【０００４】
第３に、差分情報から文書を更新する技術として、構造化文書の編集前後の差分情報から当該構造化文書を更新する手法が知られている。具体的に、特許文献６には、差分情報による構造化文書更新方法が記載されているが、この手法では、要素内のテキストの修正やテキスト要素を持つ新しい要素の追加には対応できない。即ち、構造変換のみしか対応できない点が問題である。一方、特許文献７には、ＤＯＭインタフェースを利用し、予め決められた構造の文書の指定要素について更新通知を受け、通知があった要素にのみアクセスして更新する方法が公開されている。しかし、この方法では、構造変換は不可能であり、さらに、構造変換された文書については更新することもできない点が問題である。たとえ、特許文献６及び７の発明を組み合わせたとしても、特許文献６の仕組みに基づいて構造が変化する毎に、特許文献７の仕組みを作り変えなければならず、また、特許文献７で更新すべきテキスト要素の変更箇所を検出する新たな手法を考案しなくてはならない。
【０００５】
【特許文献１】特公平０７-１５６８６号公報
【特許文献２】特開平０７-１６０７０３号公報
【特許文献３】特開２００１-２９０８０３号公報
【特許文献４】特開平７-２３４８１０号公報
【特許文献５】特開平１１-３０６１７３号公報
【特許文献６】特開２００３-２５６２４９号公報
【特許文献７】特開２００１-２１１４３１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、以上の点に鑑みてなされたものであり、差分情報及び編集後データから、任意の単位でマスタデータを更新することが可能であると共に、同時進行する編集の競合を事前に把握することが可能なシステムを提供することを課題とする。
【課題を解決するための手段】
【０００７】
本発明の１つの観点では、端末及び当該端末とデータの送受信が可能なサーバから構成される編集システムであって、前記サーバは、階層構造の文書をマスタデータとして記憶するマスタ記憶部と、前記文書は階層構造の一部を部分的に編集することが可能であって、編集前部分文書と編集後部分文書の差分情報を取得する差分情報取得手段と、前記差分情報に基づいて、前記編集の履歴を複数レコードから構成される編集履歴として記憶する編集履歴記憶部と、前記レコードの編集状態を示すステータスを設定する初期ステータス設定手段と、前記レコードのステータスに基づいて、前記編集が競合しているか否かを判定する競合判定手段と、前記競合判定手段が競合があると判定した場合に、競合している編集に対応するレコードのステータスを再設定した後、前記競合判定手段により、前記編集が競合しているか否かを再度判定するステータス再設定手段と、前記編集後部分文書を取得する編集後部分文書取得手段と、前記競合判定手段が競合がないと判定した場合に、前記レコード及び前記編集後部分文書に基づいて前記マスタデータを更新するマスタ更新手段と、を備え、前記端末は、前記マスタ記憶部から、前記マスタデータの一部を前記編集前部分文書として抽出する編集前部分文書抽出手段と、前記編集前部分文書を編集し、編集後部分文書を作成する編集後部分文書作成手段と、前記編集前部分文書と前記編集後部分文書の差分情報を取得する差分情報取得手段と、前記差分情報をサーバへ送信する差分情報送信手段と、前記編集後部分文書を送信する編集後部分文書送信手段と、を備える。
【０００８】
また、本発明の別の観点では、階層構造の文書をマスタデータとして記憶するマスタ記憶部と、前記文書は階層構造の一部を部分的に編集することが可能であって、編集前部分文書と編集後部分文書の差分情報を取得する差分情報取得手段と、前記差分情報に基づいて、前記編集の履歴を複数レコードから構成される編集履歴として記憶する編集履歴記憶部と、前記レコードの編集状態を示すステータスを設定する初期ステータス設定手段と、前記レコードのステータスに基づいて、前記編集が競合しているか否かを判定する競合判定手段と、前記競合判定手段が競合があると判定した場合に、競合している編集に対応するレコードのステータスを再設定した後、前記競合判定手段により、前記編集が競合しているか否かを再度判定するステータス再設定手段と、前記編集後部分文書を取得する編集後部分文書取得手段と、前記競合判定手段が競合がないと判定した場合に、前記レコード及び前記編集後部分文書に基づいて前記マスタデータを更新するマスタ更新手段と、を備える。
【０００９】
上述のように構成された編集システム及びサーバにおいて、端末とは、利用者がマスタデータの一部である部分文書の編集のために使用しており、サーバとデータの送受信が可能なパソコンやＰＤＡ（Personal Digital Assistants）等である。また、サーバは、マスタ記憶部及び編集履歴記憶部を有している。編集システムにおいて、利用者は、まず、端末を使用してサーバのマスタ記憶部からマスタデータの一部を編集前部分文書として取得する。さらに、利用者は、端末を使用して、当該編集前部分文書に所定の編集を行うことで編集後部分文書を作成し、編集前部分文書と編集後部分文書の差分情報を検出する。そして、利用者は、端末を使用して、検出した差分情報及び編集後部分文書をサーバへ送信する。
【００１０】
サーバは、端末から取得した差分情報に基づいて、利用者が行った編集の履歴を複数のレコードから構成される編集履歴として編集履歴記憶部へ記憶する。さらに、サーバは、編集履歴記憶部に記憶された各レコードに対して編集の状態を示すステータスを設定し、当該ステータスに基づいて競合する編集があるか否かを判定する。競合する編集がある場合、サーバは、競合する編集がなくなるまでステータスの再設定を行う。一方、競合する編集がない場合、サーバは、編集履歴記憶部に記憶されたレコード及び編集後部分文書に基づいて、マスタ記憶部に記憶されたマスタデータの更新を行う。即ち、利用者が端末において行った編集をマスタデータに反映させる。
【００１１】
このように、本発明によれば、マスタデータが階層構造の文書となっているため、１つのマスタデータから取得したそれぞれ異なる部分文書を複数人で並行して編集することができる。また、編集前部分文書と編集後部分文書の差分情報と、編集後部分文書とに基づいてマスタデータを更新することができる。さらに、この差分情報に基づく編集履歴にステータスを設定することで、同時進行する編集の競合を事前に把握して回避するように制御することができる。
【００１２】
本発明の別の観点では、端末及び当該端末とデータの送受信が可能なサーバから構成される編集システムであって、前記サーバは、階層構造の文書をマスタデータとして記憶するマスタ記憶部と、前記文書は階層構造の一部を部分的に編集することが可能であって、編集前部分文書と編集後部分文書の差分情報を取得する差分情報取得手段と、前記差分情報に基づいて、前記編集の履歴を複数レコードから構成される編集履歴として記憶する編集履歴記憶部と、前記レコードの編集状態を示すステータスを設定する初期ステータス設定手段と、前記レコードのステータスに基づいて、前記編集が競合しているか否かを判定する競合判定手段と、前記競合判定手段が競合があると判定した場合に、競合している編集に対応するレコードのステータスを再設定した後、前記競合判定手段により、前記編集が競合しているか否かを再度判定するステータス再設定手段と、前記編集後部分文書を取得する編集後部分文書取得手段と、前記競合判定手段が競合がないと判定した場合に、前記レコード及び前記編集後部分文書に基づいて前記マスタデータを更新するマスタ更新手段と、を備え、前記端末は、前記マスタ記憶部から、前記マスタデータの一部を前記編集前部分文書として抽出する編集前部分文書抽出手段と、前記編集前部分文書を編集し、編集後部分文書を作成する編集後部分文書作成手段と、前記編集後部分文書を送信する編集後部分文書送信手段と、を備える。
【００１３】
また、本発明の別の観点では、階層構造の文書をマスタデータとして記憶するマスタ記憶部と、前記文書は階層構造の一部を部分的に編集することが可能であって、前記編集後部分文書を取得する編集後部分文書取得手段と、編集前部分文書と前記編集後部分文書の差分情報を検出する差分情報検出手段と、前記差分情報に基づいて、前記編集の履歴を複数レコードから構成される編集履歴として記憶する編集履歴記憶部と、前記レコードの編集状態を示すステータスを設定する初期ステータス設定手段と、前記レコードのステータスに基づいて、前記編集が競合しているか否かを判定する競合判定手段と、前記競合判定手段が競合があると判定した場合に、競合している編集に対応するレコードのステータスを再設定した後、前記競合判定手段により、前記編集が競合しているか否かを再度判定するステータス再設定手段と、前記競合判定手段が競合がないと判定した場合に、前記レコード及び前記編集後部分文書に基づいて前記マスタデータを更新するマスタ更新手段と、を備える。
【００１４】
上述のように構成された編集システム及びサーバにおいて、利用者は、まず、端末を使用してサーバのマスタ記憶部からマスタデータの一部を編集前部分文書として取得する。さらに、利用者は、端末を使用して、当該編集前部分文書に所定の編集を行うことで編集後部分文書を作成し、当該編集後部分文書をサーバへ送信する。サーバは、編集前部分文書と、端末から取得した編集後部分文書とに基づいて差分情報を検出する。そして、サーバは、検出した差分情報に基づいて、利用者が行った編集の履歴を複数のレコードから構成される編集履歴として編集履歴記憶部へ記憶する。さらに、サーバは、編集履歴記憶部に記憶された各レコードに対して編集の状態を示すステータスを設定し、当該ステータスに基づいて競合する編集があるか否かを判定する。競合する編集がある場合、サーバは、競合する編集がなくなるまでステータスの再設定を行う。一方、競合する編集がない場合、サーバは、編集履歴記憶部に記憶されたレコード及び編集後部分文書に基づいて、マスタ記憶部に記憶されたマスタデータの更新を行う。即ち、利用者が端末において行った編集をマスタデータに反映させる。これによれば、端末は、マスタデータの一部である部分文書を編集した後、編集後部分文書をサーバに送信することで、容易に当該編集をマスタデータへ反映することができる。即ち、端末に差分情報検出機能を持たせる必要がなく、端末の負荷を軽減することができる。
【００１５】
上記サーバの一態様では、前記マスタデータは、編集を管理する単位となる要素毎に要素ＩＤが付与されており、前記レコードは、対応する要素ＩＤ、更新の種別を示す更新種別、複数の要素から構成されるグループ毎に付与されたグループＩＤとを有しており、前記差分検出手段は、前記編集前部分文書において前記差分検出の対象となる対象要素に、当該対象要素より１つ下の階層に位置しており、前記要素ＩＤが付与された子要素が存在するか否かを判定する編集前子要素判定手段と、前記編集前子要素判定手段が存在すると判定した場合に、前記編集前部分文書から前記要素ＩＤが付与された子要素を取得する編集前子要素取得手段と、取得した子要素に付与された要素ＩＤを取得するＩＤ取得手段と、取得した要素ＩＤが、前記編集後部分文書において対応する前記対象要素の子要素に付与された要素ＩＤとして存在するか否かを判定する編集後ＩＤ判定手段と、前記編集後ＩＤ判定手段が存在しないと判定した場合に、前記編集前部分文書における前記子要素と、当該子要素より下位階層に位置しており、前記要素ＩＤが付与された子孫要素とに対応するレコードの更新種別に削除を設定する削除設定手段と、前記編集後ＩＤ判定手段が存在しないと判定した場合に、前記編集前部分文書における前記子要素と前記子孫要素とに対応するレコードのグループＩＤに、当該子要素のＩＤを設定する削除グループＩＤ設定手段と、をさらに備える。
【００１６】
上述のように構成されたサーバにおいて、マスタ記憶部に記憶されたマスタデータは、編集を管理する要素毎に、当該要素を識別する要素ＩＤが付与されている。また、編集履歴部に記憶されたレコードは、各レコードが示す編集に対応する要素の要素ＩＤ、更新種別、グループＩＤ、ステータスが設定されている。差分検出手段において、サーバは、編集前部分文書の対象要素に、要素ＩＤが付与された子要素が存在するか否かを判定する。ここで、子要素とは、対象要素より１つ下の階層に存在する要素のことである。つまり、子要素とは、対象要素より下位階層に存在する全ての要素を指すのではない。一方、子孫要素とは、子要素を含め、対象要素より下位階層に存在する全ての要素のことである。また、親要素とは、子要素より１つ上の階層に存在する要素のことである。つまり、親要素とは、子要素より上位階層に存在する全ての要素を指すのではない。対象要素に要素ＩＤが付与された子要素が存在する場合、サーバは、編集前部分文書からＩＤ付与子要素と、当該子要素に付与された要素ＩＤを取得する。そして、サーバは、編集後部分文書において対象要素に対応する要素の子要素として、取得したＩＤが付与された子要素が存在するか否かを判定する。存在しない場合、サーバは、編集前部分文書における当該子要素及びその子孫要素とに対応するレコードの更新情報として削除を設定する。さらに、サーバは、編集前部分文書における当該要素及びその子孫要素とに対応するレコードのグループＩＤとして、当該子要素に付与された要素ＩＤを設定する。
【００１７】
このように、要素毎に編集前部分文書と編集後部分文書を比較することにより、どの要素が削除されたかを差分情報として検出することができる。さらに、編集履歴を構成するレコードの更新種別として削除を設定することで、サーバは容易にどのような編集が行われたかを把握することができる。また、マスタデータは階層構造であるため、ある要素が削除されることで、その子孫要素も削除される。よって、レコードにグループＩＤを設定し、グループＩＤの要素を削除することで、このような階層構造を考慮して効率的にマスタデータの更新ができる。
【００１８】
上記サーバの他の一態様では、前記レコードは、対応する要素より１つ上の階層に位置した親要素の要素ＩＤである親要素ＩＤをさらに有しており、前記差分検出手段は、前記編集後部分文書において前記差分検出の対象となる対象要素に、当該対象要素より１つ下の階層に位置しており、前記要素ＩＤが付与された子要素が存在するか否かを判定する編集後子要素判定手段と、前記編集後子要素判定手段が存在すると判定した場合に、前記編集後部分文書から前記要素ＩＤが付与された子要素を取得する編集後子要素取得手段と、取得した子要素に付与された要素ＩＤを取得するＩＤ取得手段と、取得した要素ＩＤが、前記編集前部分文書において対応する前記対象要素の子要素に付与された要素ＩＤとして存在するか否かを判定する編集前ＩＤ判定手段と、前記編集前ＩＤ判定手段が存在しないと判定した場合に、前記編集後部分文書における前記子要素と、当該子要素より下位階層に位置しており、前記要素ＩＤが付与された子孫要素とに対応するレコードの更新種別に追加を設定する追加設定手段と、前記編集前ＩＤ判定手段が存在しないと判定した場合に、前記編集後部分文書における前記子要素と前記子孫要素とに対応するレコードのグループＩＤに、当該子要素の要素ＩＤを設定する追加グループＩＤ設定手段と、前記編集前ＩＤ判定手段が存在しないと判定した場合に、前記編集後部分文書における前記子要素に対応するレコードの親要素ＩＤに、当該子要素の親要素の要素ＩＤを設定する親要素ＩＤ設定手段と、をさらに備える。
【００１９】
上述のように構成されたサーバは、まず、編集後部分文書の対象要素に、要素ＩＤが付与された子要素が存在するか否かを判定する。対象要素に要素ＩＤが付与された子要素が存在する場合、サーバは、編集後部分文書からＩＤ付与子要素と、当該子要素に付与された要素ＩＤを取得する。そして、サーバは、編集前部分文書において対象要素に対応する要素の子要素として、取得したＩＤが付与された子要素が存在するか否かを判定する。存在しない場合、サーバは、編集後部分文書における当該子要素及びその子孫要素とに対応するレコードの更新情報として追加を設定する。さらに、サーバは、編集後部分文書における当該子要素及びその子孫要素とに対応するレコードのグループＩＤとして、当該子要素に付与された要素ＩＤを設定する。また、サーバは、編集後部分文書における当該子要素に対応するレコードの親要素ＩＤとして、当該子要素の親要素に付与された要素ＩＤを設定する。
【００２０】
このように、要素毎に編集前部分文書と編集後部分文書を比較することにより、どの要素が追加されたかを差分情報として検出することができる。さらに、編集履歴を構成するレコードの更新種別として追加を設定することで、サーバは容易にどのような編集が行われたかを把握することができる。また、マスタデータは階層構造であるため、ある要素が追加されることで、その子孫要素も追加される。よって、レコードにグループＩＤを設定し、グループＩＤの要素を追加することで、このような階層構造を考慮して効率的にマスタデータの更新ができる。さらに、レコードに親要素ＩＤを設定することで、編集後部分文書の要素をマスタデータのどの位置に追加すればよいか容易に認識することができる。
【００２１】
上記サーバの他の一態様では、前記差分検出手段は、編集前部分文書において下位階層に前記要素ＩＤが付与されていないデータが存在する要素を対象要素として設定する対象要素設定手段と、前記対象要素配下の要素ＩＤが付与されていないデータを、前記編集後部分文書の当該要素ＩＤに対応する要素配下の要素ＩＤが付与されていないデータと比較する比較手段と、前記比較手段による比較の結果、差があると判定した場合に、前記対象要素に対応するレコードの更新種別に修正を設定する修正設定手段と、を備える。これによれば、要素毎に、当該要素配下のＩＤが付与されていないデータを比較することで、どの要素配下のデータが修正されたかを差分情報として検出することができる。さらに、編集履歴を構成するレコードの更新種別として修正を設定することで、サーバは容易にどのような編集が行われたかを把握することができる。
【００２２】
上記サーバの他の一態様では、前記マスタデータは、要素毎にデータバージョンが付与されており、前記レコードは、前記データバージョンと、部分文書毎の編集プロセスであるジョブのＩＤであるジョブＩＤをさらに備え、前記ステータスは、放棄、更新対象及び更新完了のいずれか１つが設定されるものであって、前記初期ステータス設定手段は、前記ステータスが未設定であって、ジョブＩＤ、グループＩＤ及び更新種別が同一の全てのレコードを、同一のステータスを設定する同ステータスレコード群に設定する第１レコード群設定手段と、前記ステータスが未設定であって、ジョブＩＤ及び要素ＩＤが同一のレコードを、前記同ステータスレコード群に設定する第２レコード群設定手段と、前記編集履歴記憶部に、前記同ステータスレコード群に属するレコードと異なるジョブＩＤであって、データバージョンが一致するレコードが存在するか否かを判定するジョブＩＤ判定手段と、前記ジョブＩＤ判定手段が存在すると判定した場合に、前記同ステータスレコード群に属するレコードと異なるジョブＩＤであってデータバージョンが一致するレコードの中に、ステータスが更新完了のレコードが存在するか否かを判定する更新完了判定手段と、前記更新完了判定手段が存在すると判定した場合に、前記同ステータスレコード群に属する全てのレコードに放棄を設定する放棄設定手段と、前記ジョブＩＤ判定手段及び前記更新完了判定手段のいずれか１つ以上が存在しないと判定した場合に、前記同ステータスレコード群に属する全てのレコードに更新対象を設定する更新対象設定手段と、をさらに備える。
【００２３】
上記のように構成されたサーバにおいて、マスタデータは、要素毎に、当該要素のバージョンを示すデータバージョンが付与されている。このデータバージョンは、マスタデータが更新される度に更新される。また、編集履歴部に記憶されたレコードは、各レコードが示す編集に対応する要素の要素ＩＤ、更新種別、グループＩＤ、ステータスに加え、データバージョン、ジョブＩＤが設定されている。初期ステータス設定手段は、まず、ステータスが未設定であって、ジョブＩＤ、グループＩＤ及び更新種別が同一のレコードを、同一のステータスを設定する必要がある同ステータスレコード群に設定する。さらに、ステータスが未設定であって、ジョブＩＤ及び要素ＩＤが同一のレコードも、同一のステータスを設定する必要がある同ステータスレコード群に設定する。そして、初期ステータス設定手段は、編集履歴部に基づいて、当該同ステータスレコード群に属するレコードと異なるジョブＩＤであって要素ＩＤ及びデータバージョンが同一のレコードが複数存在するか否かを判定する。存在しない場合、当該同ステータスレコード群に属する全てのレコードのステータスに更新対象を設定する。一方、存在する場合、そのレコードの中に、ステータスとして更新完了が設定されているレコードが存在するか否かを判定する。存在しない場合、当該同ステータスレコード群に属する全てのレコードのステータスに更新対象を設定する。一方、存在する場合、ステータスが設定されていない当該同ステータスレコード群に属する全てのレコードのステータスに放棄を設定する。ここで、ステータス「更新対象」とは、マスタデータにレコードをまだ反映させていない状態を表す。また、ステータス「更新完了」とは、マスタデータにレコードを既に反映させた状態を表す。一方、ステータス「放棄」とは、マスタデータにレコードを反映させることなく放棄する状態を表す。つまり、サーバは、初期ステータス設定手段により、各レコードにステータスを設定することにより、競合する編集を把握すると共に、既に更新されたマスタデータの要素が上書きされる問題を回避することができる。
【００２４】
上記サーバの他の一態様では、前記競合判定手段は、前記編集履歴記憶部に、ステータスが更新対象であって、ジョブＩＤが異なり、要素ＩＤ及びデータバージョンが一致するレコードが複数存在する場合に前記編集が競合していると判定するものであって、前記ステータス再設定手段は、ジョブＩＤ、グループＩＤ及び更新種別が同一のレコード、並びに、ジョブＩＤ及び要素ＩＤが同一のレコードには同一のステータスを設定することを特徴とする。これによれば、サーバは、編集履歴記憶部に記憶されたレコードのステータス、ジョブＩＤ、要素ＩＤ及びデータバージョンに基づいて編集が競合するレコードを的確に抽出することができる。そして、サーバは、編集の競合を回避するため、ステータスの再設定を行う。このとき、サーバは、ジョブＩＤ、グループＩＤ及び更新種別が同一のレコード、並びに、ジョブＩＤ及び要素ＩＤが同一のレコードは連動して同一のステータスを設定するものとする。これにより、サーバは、マスタデータへの更新を効率的に行うことができ、且つ、競合しないようにレコードのステータスを設定することができる。
【００２５】
上記サーバの他の一態様では、前記マスタ更新手段は、前記編集履歴記憶部から、ステータスが更新対象であって、更新種別が削除であるレコードを抽出する削除レコード抽出手段と、前記削除レコードに基づいて、グループＩＤと要素ＩＤが一致するか否かを判定する削除ＩＤ判定手段と、前記削除ＩＤ判定手段が一致すると判定した場合に、当該削除レコードのＩＤに対応するマスタデータの要素を削除する削除手段と、前記削除レコードのステータスを更新完了に設定する削除完了設定手段と、を備える。これによれば、サーバは、編集履歴記憶部に記憶されたレコードに基づいて、マスタデータは階層構造であることを考慮した上で、容易に当該マスタデータの一部を削除する更新を行うことができる。
【００２６】
上記サーバの他の一態様では、前記マスタ更新手段は、前記編集履歴記憶部から、ステータスが更新対象であって、更新種別が追加であるレコードを抽出する追加レコード抽出手段と、前記追加レコードに基づいて、グループＩＤと要素ＩＤが一致するか否かを判定する追加ＩＤ判定手段と、前記追加ＩＤ判定手段が一致すると判定した場合に、当該追加レコードのＩＤに対応する編集後部分文書の要素を、前記マスタデータに親要素ＩＤの子要素として追加する追加手段と、前記追加レコードのステータスを更新完了に設定する追加完了設定手段と、前記追加手段が追加した要素のデータバージョンを更新する追加更新手段と、を備える。これによれば、サーバは、編集履歴記憶部に記憶されたレコードに基づいて、マスタデータは階層構造であることを考慮した上で、容易に当該マスタデータの一部を追加する更新を行うことができる。
【００２７】
上記サーバの他の一態様では、前記マスタ更新手段は、前記編集履歴記憶部から、ステータスが更新対象であって、更新種別が修正であるレコードを抽出する修正レコード抽出手段と、前記修正レコードの要素ＩＤに対応する要素配下の要素ＩＤが付与されていないデータを、前記マスタデータから削除する修正削除手段と、前記編集後部分文書における修正レコードの要素ＩＤに対応する要素配下の要素ＩＤが付与されていないデータを、前記マスタデータに追加する修正追加手段と、前記修正レコードのステータスを更新完了に設定する修正完了設定手段と、前記修正追加手段が追加したデータに対応する要素のデータバージョンを更新する修正更新手段と、を備える。これによれば、サーバは、編集履歴記憶部に記憶されたレコードに基づいて、容易に、要素ＩＤが付与されていないデータの修正をマスタデータに反映させることができる。
【００２８】
上記サーバのさらに他の一態様では、前記削除レコード抽出手段、前記削除ＩＤ判定手段、前記削除手段及び前記削除完了設定手段は、前記追加レコード抽出手段、前記追加ＩＤ判定手段、前記追加手段、前記追加完了設定手段及び前記追加更新手段より前に行われることを特徴とする。これによれば、最終処理であるレコードからのマスタ更新手段では、必ず削除、追加の順に処理を行わなくてはならない。換言すると、追加の処理の後、削除の処理を行ってはならない。これは、追加の処理の後、削除の処理を行うと、追加したデータを削除する等整合性が取れなくなる可能性があるからである。
【００２９】
本発明の別の観点では、コンピュータにより実行されるプログラムであって、階層構造の文書をマスタデータとして記憶するマスタ記憶手段、前記文書は階層構造の一部を部分的に編集することが可能であって、編集前部分文書と編集後部分文書の差分情報を取得する差分情報取得手段、前記差分情報に基づいて、前記編集の履歴を複数レコードから構成される編集履歴として記憶する編集履歴記憶手段、前記レコードの編集状態を示すステータスを設定する初期ステータス設定手段、前記レコードのステータスに基づいて、前記編集が競合しているか否かを判定する競合判定手段、前記競合判定手段が競合があると判定した場合に、競合している編集に対応するレコードのステータスを再設定した後、前記競合判定手段により、前記編集が競合しているか否かを再度判定するステータス再設定手段、前記編集後部分文書を取得する編集後部分文書取得手段、前記競合判定手段が競合がないと判定した場合に、前記レコード及び前記編集後部分文書に基づいて前記マスタデータを更新するマスタ更新手段、として前記コンピュータを機能させる。
【００３０】
本発明のさらに別の観点では、コンピュータにより実行されるプログラムであって、階層構造の文書をマスタデータとして記憶するマスタ記憶手段、前記文書は階層構造の一部を部分的に編集することが可能であって、前記編集後部分文書を取得する編集後部分文書取得手段、編集前部分文書と前記編集後部分文書の差分情報を検出する差分情報検出手段、前記差分情報に基づいて、前記編集の履歴を複数レコードから構成される編集履歴として記憶する編集履歴記憶手段、前記レコードの編集状態を示すステータスを設定する初期ステータス設定手段、前記レコードのステータスに基づいて、前記編集が競合しているか否かを判定する競合判定手段、前記競合判定手段が競合があると判定した場合に、競合している編集に対応するレコードのステータスを再設定した後、前記競合判定手段により、前記編集が競合しているか否かを再度判定するステータス再設定手段、前記競合判定手段が競合がないと判定した場合に、前記レコード及び前記編集後部分文書に基づいて前記マスタデータを更新するマスタ更新手段、として前記コンピュータを機能させる。
【００３１】
上記プログラムをコンピュータにより実行することにより、上述のサーバを実現することができる。また、上述のサーバの各態様も同様に実現することができる。
【発明の効果】
【００３２】
本発明によれば、差分情報及び編集後データから、任意の単位でマスタデータを更新することが可能であると共に、同時進行する編集の競合を事前に把握することができる。
【発明を実施するための最良の形態】
【００３３】
以下、図面を参照して本発明の好適な実施の形態について説明する。
【００３４】
[編集システム]
まず、本実施形態に係る編集システムについて図１及び図２を参照して説明する。図１は、編集システムの概略構成であり、図２は、編集システムの内部構成を示すブロック図である。編集システム１００は、１つのマスタデータから取得したそれぞれ異なる部分文書を複数人で並行して編集した場合に、編集前部分文書と編集後部分文書の差分情報と、当該編集後部分文書とに基づいて、任意の要素単位で当該マスタデータを更新することができるシステムである。また、編集システム１００は、差分情報、各要素に付与された要素ＩＤ及びデータバージョンに基づいて、同時進行する編集の競合を事前に把握することができるシステムである。
【００３５】
なお、本発明は、大容量の構造化文書を複数人で同時編集するような場合であって、特に、編集箇所を取得した時点ではどこがどのように編集されるかが分からないような場合に最適である。具体的には、辞典、事典、教材、マニュアル、約款、規約、法規等に適用することが考えられる。例えば、辞典データの編集では、同一の単語について複数の意味が存在し、それぞれ異なる分野の複数の専門家が編集を追加、削除、修正等を行った場合に、構造変更を伴う編集の競合が発生し得るからである。
【００３６】
図１に示すように、編集システム１００において、利用者端末Ａ及びＢはネットワーク３００を介してサーバ３０と通信可能に接続されている。ネットワーク３００の１つの好適な例はインターネットである。ここで、利用者端末Ａ及びＢは、各利用者が部分文書の編集のために使用しており、ネットワーク３００を介して他の利用者端末やサーバ３０とメールやデータの送受信が可能なパソコンやＰＤＡ等である。また、サーバ３０は、マスタデータベース（以下、「ＤＢ」と呼ぶ。）１及び編集履歴ＤＢ４に接続されている。
【００３７】
なお、図１では、利用者端末Ａ及びＢのみを記載しているが、本発明はこれに限定されるものではなく、ネットワーク３００を介して、複数の利用者が使用する複数の利用者端末が通信可能に接続されているものとする。
【００３８】
図２に示すように、編集システム１００の利用者端末４０は、編集機２を有している。また、サーバ３０は、マスタＤＢ１、差分情報検出部３、編集履歴ＤＢ４、更新処理実行部５、編集競合検査部６、ステータス制御部７及びステータス入出力部８を有している。
【００３９】
マスタＤＢ１は、編集対象となるマスタデータを記憶している。マスタデータは階層構造の文書であり、編集を管理したい単位要素及びその直系の先祖要素には、要素ＩＤ及びデータバージョンが付与されている。ここで、要素ＩＤとは、管理したい単位となる要素の識別情報であり、任意に設定することができる。また、データバージョンは、要素のバージョンを示すデータである。
【００４０】
利用者端末４０は、マスタデータの部分構造となる編集前部分文書１０を取得し、編集機２で編集を行うことで、編集後部分文書２０を作成する。そして、利用者端末４０は、編集後部分文書２０をサーバ３０へ送信する。サーバ３０は、このような部分文書毎の編集プロセスをジョブという単位で管理し、編集履歴ＤＢ４に記憶する。具体的には、差分情報検出部３で、編集前部分文書１０及び編集後部分文書２０の差分を検出し、差分情報を編集履歴ＤＢ４に記憶する。
【００４１】
更新処理実行部５では、編集履歴ＤＢ４と編集後部分文書２０から、マスタデータについて変更があった部分のみ更新する。ここで、変更とは、追加、削除、修正のことである。編集競合検査部６は、編集履歴ＤＢ４を参照し、要素ＩＤ及びデータバージョンが同一の要素の編集が、他の編集プロセス（ジョブ）で進行していないかを検査し、競合があればステータス制御部７に通知する。ステータス制御部７では、編集履歴ＤＢ４を参照し、編集作業の状態を示すステータスを設定すると共に、外部入力されるステータス制御情報を編集履歴ＤＢ４に記憶する。ステータス入出力部８は、ステータス制御部７に対して、ステータスの入力や自動判断したステータスの通知を行う。また、ステータス入出力部８は、ステータス制御部７による制御結果の利用者への通知を行う。
【００４２】
[編集処理]
次に、編集システム１００による編集処理について図３を参照して説明する。図３は、編集処理のフローチャートである。
【００４３】
利用者は、まず、利用者端末４０を使用したマスタＤＢ１から編集前部分文書１０を取得する（ステップＳ１）。このとき編集前部分文書１０は、編集管理単位以上の要素、又はその集合であるグループを任意のルート要素でまとめたもので取得する。さらに、利用者は、利用者端末４０の編集機２により編集前部分文書１０を編集することで、編集後部分文書２０を作成する。そして、利用者端末４０は、編集後部分文書２０を、ネットワーク３００を介してサーバ５へ送信する。
【００４４】
サーバ３０は、差分情報検出部３で差分情報検出処理を行い、編集前部分文書１０と編集後部分文書２０とを比較することで差分情報を検出する（ステップＳ３）。ここで、差分情報とは、要素ＩＤやデータバージョン等の編集された要素を特定する情報と、編集の種類（テキストの修正、要素の削除、追加）を示す情報である。差分情報は、編集履歴ＤＢ４に記憶される（ステップＳ４）。なお、差分情報が記憶される際同時に、編集前部分文書１０の編集プロセスをジョブとして管理し、当該ジョブを識別するジョブＩＤも編集履歴ＤＢ４に記憶される。サーバ３０は、ステータス制御部７で、編集履歴ＤＢ４に記憶された情報に基づいて初期ステータスを設定する（ステップＳ５）。
【００４５】
そして、サーバ３０は、編集競合検査部６で、編集履歴ＤＢ４に記憶された情報に基づいて、編集が競合しているか否かを判定する（ステップＳ６）。具体的には、編集を行った要素を他のジョブで編集していないかをチェックする。編集が行われている場合には、編集が競合しているとして（ステップＳ６；Ｙｅｓ）、ステータス入出力部８を通してステータスコントロールを行い、どの編集を優先させるか、どの編集を放棄するかを決定する。このようなステータスコントロールの後、サーバ３０は、ステータス制御部７で再度ステータスの設定を行い、ステップＳ６へ進む。一方、編集が行われていない場合には、編集が競合していないとして（ステップＳ６；Ｎｏ）、更新処理実行部５により、編集履歴ＤＢ４に記憶された情報と、編集後部分文書２０とに基づいてマスタＤＢ１に記憶されているマスタデータを上書きすることで更新を行う。そして、サーバ３０は、マスタデータの更新が完了した要素について、編集履歴ＤＢ４上の対応するステータスに更新完了を記憶する（ステップＳ９）。これにより、編集処理は完了する。
【００４６】
[マスタデータ]
次に、サーバ３０に接続されたマスタＤＢ１に記憶されたマスタデータについて、図４を参照して詳細に説明する。図４は、マスタデータと編集用部分文書を模式的に示す図である。
【００４７】
マスタデータは、ＸＭＬやＳＧＭＬ、又はこれらのサブセットであるような構造化文書である。構造は任意であり、図示のとおり、同じタグ名の要素がネストしている、入れ子構造を持つ文書も対象である。マスタデータには、図示のとおり、編集を管理する単位要素及びその直系の先祖要素に要素ＩＤ（ＩＤ）とデータバージョン（ｖｅｒ）が付与される。要素ＩＤは、要素を識別する情報であるため、一度付与されたら変更されることはないが、データバージョンは、その要素に編集が行われる度に更新される。なお、データバージョンは、マスタデータが更新された日時を利用する等任意に設定することができる。
【００４８】
編集前部分文書１０は、図示のとおり、マスタデータを管理する単位要素を含むような任意の階層の要素、又はその集合であるグループを任意のルート要素でまとめた構造化文書である。
【００４９】
なお、マスタデータは、テキスト形式で管理してもよいし、ＸＭＬ-ＤＢ等のＸＭＬ形式のデータを扱うＤＢに格納して管理してもよい。
【００５０】
[差分情報検出部]
次に、サーバ３０の構成要素である差分情報検出部３について、図５乃至図９を参照して詳細に説明する。図５（ａ）は、編集前部分文書１０を、図５（ｂ）は、編集後部分文書２０を模式的に示す図である。なお、図５において、楕円は要素ＩＤが付与された要素、丸や四角は要素ＩＤが付与されていないデータを表している。また、楕円の中に記載されている数字が要素ＩＤである。
【００５１】
差分情報検出部３では、図５に示すような、編集前部分文書１０と編集後部分文書２０とを比較することで、差分情報検出処理を行う。差分情報検出処理は、削除要素を検出する削除検出処理、追加要素を検出する追加検出処理及び修正要素を検出する修正検出処理から構成されている。図６は削除検出処理のフローチャート、図７は追加検出処理のフローチャート、図８は修正検出処理のフローチャートである。これら３つの処理は全て、編集前部分文書１０をルート要素から下位方向に探索し、各ＩＤ付与要素を対象要素として、その子要素を編集後部分文書２０と比較する。
【００５２】
まず、図６を参照して、削除検出処理について説明する。削除検出処理をスタートする際には、まず、対象要素を編集前部分文書１０のルート要素に設定する（ステップＳ１０）。そして、差分情報検出部３は、編集前部分文書１０の対象要素にＩＤ付与子要素が存在するか否かを判定する（ステップＳ１１）。ＩＤ付与子要素が存在しない場合（ステップＳ１１；Ｎｏ）、削除検出処理は終了する。一方、ＩＤ付与子要素が存在する場合（ステップＳ１１；Ｙｅｓ）、編集前部分文書１０のＩＤ付与子要素を全て取得する（ステップＳ１２）。そして、差分情報検出部３は、ＩＤ付与子要素のＩＤを１つ取得し（ステップＳ１４）、当該ＩＤの子要素が編集後部分文書２０に対象要素の子要素に付与されたＩＤとして存在するか否かを判定する（ステップＳ１５）。
【００５３】
存在しないと判定した場合（ステップＳ１５；Ｎｏ）、差分情報検出部３は、当該ＩＤの子要素（消失要素）及びその子孫要素全てから「削除」という更新情報を検出する（ステップＳ１６）。この消失要素とその子孫の要素は１つのグループとして取り扱い、当該グループを識別する情報としてグループＩＤを付与する。このグループＩＤは、最上位の消失要素のＩＤ、つまり「削除」を検出したＩＤ付与子要素のＩＤを設定する。そして、差分情報検出部３は、ステップＳ１３へ進み、ステップＳ１２で取得した全ての子要素をチェックしたか否かを判定する（ステップＳ１３）。全ての子要素をチェックしていない場合（ステップＳ１３；Ｎｏ）、差分情報検出部３は、ステップＳ１４乃至Ｓ１７の処理を繰り返し行う。一方、全ての子要素をチェックした場合（ステップＳ１３；Ｙｅｓ）、差分情報検出部３は、削除検出処理を完了する。
【００５４】
なお、削除検出処理では、「削除」の更新情報が検出された要素については、その子孫に同じ更新情報を適用するため、子孫に対して再帰的な処理は行わない。
【００５５】
一方、ステップＳ１５において存在すると判定した場合（ステップＳ１５；Ｙｅｓ）、差分情報検出部３は、当該ＩＤの子要素にＩＤ付与子孫要素があるか否かを判定する（ステップＳ１８）。ＩＤ付与子孫要素がない場合（ステップＳ１８；Ｎｏ）、差分情報検出部３は、ステップＳ１３へ進む。一方、ＩＤ付与子孫要素がある場合（ステップＳ１８；Ｙｅｓ）、差分情報検出部３は、当該ＩＤの子要素を対象要素に設定し、削除検出処理を再帰コールする（ステップＳ１９）。即ち、再帰的に下位階層要素をチェックする。そして、差分情報検出部３は、対象要素を変えて上述と同様の削除検出処理を行うとともに、ステップＳ１３へ進む（ステップＳ２０）。これにより、編集前部分文書１０に含まれる全てのＩＤ付与子要素についてチェックを行うことができる。
【００５６】
次に、図７を参照して追加検出処理について説明する。追加検出処理は、基本的には削除検出処理と同じであるが、編集後部分文書２０を基準にする点で異なる。追加検出処理では、編集後部分文書２０には存在するが、編集前部分文書１０には存在しないＩＤ付与要素をチェックし、このような要素（追加要素）が存在した場合には、追加要素及びその全てのＩＤ付与子孫要素に対して「追加」という更新情報を検出する。削除検出処理と同様に、この追加要素及びそのＩＤ付与子孫要素は１つのグループとして取り扱い、グループＩＤとして最上位の追加要素のＩＤを設定する。さらに、追加検出処理では、編集後部分文書２０における追加要素の親要素のＩＤも取得する必要がある。
【００５７】
図７によれば、追加検出処理をスタートする際には、まず、対象要素を編集後部分文書２０のルート要素に設定する（ステップＳ２１）。そして、差分情報検出部３は、編集後部分文書２０の対象要素にＩＤ付与子要素が存在するか否かを判定する（ステップＳ２２）。ＩＤ付与子要素が存在しない場合（ステップＳ２２；Ｎｏ）、追加検出処理は終了する。一方、ＩＤ付与子要素が存在する場合（ステップＳ２２；Ｙｅｓ）、編集後部分文書２０のＩＤ付与子要素を全て取得する（ステップＳ２３）。そして、差分情報検出部３は、ＩＤ付与子要素のＩＤを１つ取得し（ステップＳ２５）、当該ＩＤの子要素が編集前部分文書１０に対象要素の子要素に付与されたＩＤとして存在するか否かを判定する（ステップＳ２６）。
【００５８】
存在しないと判定した場合（ステップＳ２６；Ｎｏ）、差分情報検出部３は、当該ＩＤの子要素（追加要素）及びその子孫要素全てから「追加」という更新情報を検出する（ステップＳ２７）。この追加要素とその子孫要素は１つのグループとして取り扱い、当該グループを識別する情報としてグループＩＤを付与する。このグループＩＤは、最上位の追加要素のＩＤ、つまり「追加」を検出したＩＤ付与子要素のＩＤを設定する（ステップＳ２８）。さらに、差分情報検出部３は、追加要素の親要素のＩＤを親要素ＩＤとして設定する。そして、差分情報検出部３は、ステップＳ２４へ進み、ステップＳ２３で取得した全ての子要素をチェックしたか否かを判定する（ステップＳ２４）。全ての子要素をチェックしていない場合（ステップＳ２４；Ｎｏ）、差分情報検出部３は、ステップＳ２５乃至Ｓ２８の処理を繰り返し行う。一方、全ての子要素をチェックした場合（ステップＳ２４；Ｙｅｓ）、差分情報検出部３は、追加検出処理を完了する。
【００５９】
なお、追加検出処理では、「追加」の更新情報が検出された要素については、その子孫に同じ更新情報を適用するため、子孫に対して再帰的な処理は行わない。
【００６０】
一方、ステップＳ２６において存在すると判定した場合（ステップＳ２６；Ｙｅｓ）、差分情報検出部３は、当該ＩＤの子要素にＩＤ付与子孫要素があるか否かを判定する（ステップＳ２９）。ＩＤ付与子孫要素がない場合（ステップＳ２９；Ｎｏ）、差分情報検出部３は、ステップＳ２４へ進む。一方、ＩＤ付与子孫要素がある場合（ステップＳ２９；Ｙｅｓ）、差分情報検出部３は、当該ＩＤの子要素を対象要素に設定し、追加検出処理を再帰コールする（ステップＳ３０）。即ち、再帰的に下位階層要素をチェックする。そして、差分情報検出部３は、対象要素を変えて上述と同様の追加検出処理を行うとともに、ステップＳ２４へ進む（ステップＳ３１）。これにより、編集後部分文書２０に含まれる全てのＩＤ付与子要素についてチェックすることができる。
【００６１】
次に、図８を参照して修正検出処理について説明する。修正検出処理は、所定のＩＤ付与要素について、その子孫であってＩＤが付与されていないデータに対して、編集前部分文書１０と編集後部分文書２０に差があった場合には、当該ＩＤ付与要素に対して「修正」という更新情報を検出する。これらのチェックをルートから順に下位層に対して行い、全てのＩＤ付与要素について行う。
【００６２】
図８によれば、修正検出処理をスタートする際には、まず、対象要素を編集前部分文書１０のルート要素に設定する（ステップＳ４０）。そして、差分情報検出部３は、編集前部分文書１０の対象要素にＩＤ付与されていないデータが存在するか否かを判定する（ステップＳ４１）。ＩＤ付与されていないデータが存在すると判定した場合（ステップＳ４１；Ｙｅｓ）、対象要素配下のＩＤが付与されていないデータを、対応する編集後部分文書２０のデータと比較する（ステップＳ５１）。比較の結果、編集後部分文書２０のデータと差がある場合（ステップＳ５２；Ｙｅｓ）、差分情報検出部３は、対象要素から「修正」という更新情報を検出する（ステップＳ５３）。一方、比較の結果、編集後部分文書２０のデータと差がない場合（ステップＳ５２；Ｎｏ）、差分情報検出部３は、ステップＳ４２へ進む。
【００６３】
ステップＳ４１において、対象要素にＩＤ付与されていないデータが存在しないと判定した場合（ステップＳ４１；Ｎｏ）、差分情報検出部３は、対象要素にＩＤ付与子要素が存在するか否かを判定する（ステップＳ４２）。ＩＤ付与子要素が存在しない場合（ステップＳ４２；Ｎｏ）、差分情報検出部３は、修正検出処理を終了する。一方、ＩＤ付与子要素が存在する場合（ステップＳ４２；Ｙｅｓ）、差分情報検出部３は、編集前部分文書１０のＩＤ付与子要素を全て取得する（ステップＳ４３）。そして、差分情報検出部３は、ＩＤ付与子要素のＩＤを１つ取得し、当該ＩＤの子要素にＩＤ付与子孫要素があるか否かを判定する（ステップＳ４５）。ＩＤ付与子孫要素があると判定した場合（ステップＳ４５；Ｙｅｓ）、差分情報検出部３は、当該ＩＤの子要素を対象要素に設定し、修正検出処理を再帰コールする（ステップＳ４９）。即ち、再帰的に下位階層要素をチェックする。そして、差分情報検出部３は、対象要素を変えて上述と同様の修正検出処理を行うとともに、ステップＳ４４へ進む（ステップＳ５０）。これにより、編集前部分文書１０に含まれる全てのＩＤ付与子要素についてチェックすることができる。
【００６４】
一方、ステップＳ４５において、ＩＤ付与子孫要素がないと判定した場合（ステップＳ４５；Ｎｏ）、差分情報検出部３は、当該ＩＤの子要素配下のＩＤが付与されていないデータを、対応する編集後部分文書２０のデータと比較する（ステップＳ４６）。比較の結果、編集後部分文書２０のデータと差がある場合（ステップＳ４７；Ｙｅｓ）、差分情報検出部３は、対象要素から「修正」という更新情報を検出し（ステップＳ４８）、ステップＳ４４へ進む。一方、比較の結果、編集後部分文書２０のデータと差がない場合（ステップＳ４７；Ｎｏ）、差分情報検出部３は、ステップＳ４４へ進む。ステップＳ４４では、ステップＳ４３で取得した全ての子要素をチェックしたか否かを判定する（ステップＳ４４）。全ての子要素をチェックしていない場合（ステップＳ４４；Ｎｏ）、差分情報検出部３は、ステップＳ４５乃至Ｓ４８を繰り返し行う。一方、全ての子要素をチェックした場合（ステップＳ４４；Ｙｅｓ）、差分情報検出部３は、修正検出処理を完了する。
【００６５】
なお、上述の例では、修正検出処理を、編集前部分文書１０を元に行っているが、本発明はこれに限定されるものではなく、編集後部分文書２０を元に行うこととしてもよい。
【００６６】
この差分情報検出処理について、図５を参照して説明する。図５は、編集前部分文書１０と、編集後部分文書２０の構造を模式的に示す図である。なお、本実施形態では図５に示すように、編集前部分文書１０に対して「削除」、「修正」及び「追加」の編集を行った結果が編集後部分文書２０であるものとする。図中の「削除」、「修正」及び「追加」の文字や破線は説明の便宜上記載したものである。
【００６７】
差分情報検出部３は、まず、編集前部分文書１０を基準として、ルート要素から下位階層の要素へと探索を行い、「削除」と「修正」を検出する。そして、編集前部分文書１０の要素ＩＤ１の要素「以下、「要素１」と呼ぶ。他の要素も同様。）を対象要素に設定する。要素１の子要素には変更がないので、差分情報は検出されない。
【００６８】
次に、要素２を対象要素に設定する。要素２では、配下のＩＤが付与されていないデータに修正が行われているため、「修正」という更新情報が検出される。即ち、差分情報検出部３は、要素２について「修正」の更新情報を検出する。
【００６９】
次に、要素３は、ＩＤ付与子要素がないので、次の要素４を対象要素に設定する。要素４では、要素５及び６を子要素に持つが、それらのうち、要素５は編集後部分文書２０において、要素４の子要素として存在しない。よって、要素５が削除されたことがわかり、要素５及びその子孫要素７について「削除」の更新情報を検出する。このとき、要素５及び要素７にはグループＩＤとして「５」が設定される。削除検出処理において、編集前部分文書１０における要素５及び要素７の「削除」は、グループＩＤ５の１つのグループを形成すると捉える。
【００７０】
なお、「修正」の検出は全対象要素で行うが、便宜上、検出されなかったレコードについては説明を省略する。
【００７１】
差分情報検出部３は、次に、編集後部分文書２０を基準として、ルート要素から下位階層の要素へと探索を行い、「追加」を検出する。そして、編集後部分文書２０の要素１を対照要素に設定する。要素１の子要素には変更がないので、差分情報は検出されない。
【００７２】
次に、要素２にはＩＤ付与子要素がないので、次の要素３を対象要素とする。要素３では、要素５を子要素として持つが、要素５は、編集前部分文書１０において、要素３の子要素として存在しない。よって、要素５が追加されたことがわかり、要素５及びその子孫要素７について「追加」の更新情報を検出する。このとき、要素５及び要素７にはグループＩＤとして「５」が設定される。また、要素５には、親要素ＩＤとして「３」が設定される。追加検出処理において、編集後部分文書２０における要素５及び要素７の「追加」は、グループＩＤ５の１つのグループを形成すると考えられる。最後に要素４については、その子要素には変更がないので、差分情報は検出されない。
【００７３】
図５に示す編集前部分文書１０及び編集後部分文書２０に基づいて検出した差分情報を図９に示す。図９は、複数のレコードから構成される差分情報のデータ構造を模式的に示す図である。図９に示すような差分情報に基づいて、編集履歴ＤＢ４に編集履歴に関する情報が記憶される。
【００７４】
なお、図９では、差分情報は、要素ＩＤ、更新種別、グループＩＤ及び親要素ＩＤから構成されることとしているが、本発明はこれに限定されるものではなく、要素ＩＤの代わりにＸＰａｔｈや要素名を構成要素とすることもできる。これらを構成要素とすることにより、要素ＩＤより簡単に要素を特定することが可能となる。
【００７５】
[編集履歴ＤＢ]
次に、サーバ３０に接続された編集履歴ＤＢ４について、図１０を参照して詳細に説明する。
【００７６】
図１０は、編集履歴ＤＢ４のデータ構造を模式的に示す図である。編集履歴ＤＢ４には、図９に示す差分情報に加えて、さらに、要素のデータバージョン、部分文書毎の編集プロセスであるジョブを特定するジョブＩＤ、各レコードのステータスを記憶している。
【００７７】
なお、図１０に示すジョブＩＤ１００のレコード群は図５の編集、ジョブＩＤ２００のレコード群は後述する図１３の編集に対応する。本実施形態では、詳細は後述するが、ジョブＩＤ１００の編集と、ジョブＩＤ２００の編集が競合するものであって、ステータスコントロール処理によってステータスを変更することで競合を回避することを説明する。図１０に示す編集履歴ＤＢ４は、差分情報に基づいてレコードが記憶された直後であって、後述するステータスコントロール処理前の状態である。
【００７８】
ここで、編集履歴ＤＢ４に記憶されているデータバージョンとは、編集前部分文書１０をマスタＤＢ１から取得したときの各要素のデータバージョンである。ステータスとは、各レコードの編集状態である。ステータスとしては、マスタＤＢに反映されていない「更新対象」、既にマスタＤＢに反映された「更新完了」、マスタＤＢに反映しない「放棄」の少なくとも３つの状態がある。具体的に、「更新完了」は、正常にマスタＤＢ１に記憶されているマスタデータ更新が完了した状態を表している。「更新対象」は、マスタデータ更新が行われていないレコードであって、そのジョブのレコードを他のジョブより優先して更新することを表している。一方、「放棄」は、他のジョブで既に更新が完了しているか、マスタデータ更新を放棄することを表している。即ち、ステータスとして「放棄」が設定されたレコードに基づいて、マスタデータが更新されることはない。
【００７９】
このようなステータスは、詳細は後述するが、ステータス制御部７で設定される。
【００８０】
なお、本発明はこれに限定されるものではなく、適宜この３つ以外のステータスを設けることも可能である。
【００８１】
[ステータス制御部]
次に、サーバ３０の構成要素であるステータス制御部７について詳細に説明する。
【００８２】
ステータス制御部７は、図２の編集処理におけるステップＳ４において、差分情報に基づいて編集履歴ＤＢ４に新たなレコードが記憶される度に、当該レコードに初期ステータスを設定する。ステータス制御部７が行う初期ステータス設定処理について、図１１及び図１２を参照して説明する。図１１は、初期ステータス設定処理のフローチャートである。また、図１２は、初期ステータス設定処理によるステータス設定例である。
【００８３】
図１１に示すように、ステータス制御部７は、まず、編集履歴ＤＢ４にステータス未設定のレコードが存在するか否かを判定する（ステップＳ５４）。未設定のレコードが存在しない場合（ステップＳ５４；Ｎｏ）、ステータス制御部７は、初期ステータス設定処理を終了する。一方、未設定のレコードが存在する場合（ステップＳ５４；Ｙｅｓ）、ステータス制御部７は、編集履歴ＤＢ４から未設定のレコードを１レコード取得する（ステップＳ５５）。さらに、ステータス制御部７は、取得したレコードと、同ステータスを設定するべき範囲のレコードを同ステータスレコード群として取得する。ここで、同ステータスレコード群は、ステップＳ５５で取得したレコードも含む。
【００８４】
なお、ジョブＩＤ、グループＩＤ及び更新種別が同一のレコードは、同ステータスレコード群に設定される。また、ジョブＩＤ及び要素ＩＤが同一のレコードも、同ステータスレコード群に設定される。具体的には、図１２（ａ）に示すように、ジョブＩＤ１００、グループＩＤ１及び更新種別「削除」の４レコードは同グループのレコード群「削除グループ」であり、同ステータスを設定するべき同ステータスレコード群である。また、図１２（ａ）に示すように、ジョブＩＤ１００、グループＩＤ５及び更新種別「追加」の２レコードは同グループのレコード群「追加グループ」であり、同ステータスを設定すべき同ステータスレコード群である。
【００８５】
さらに、ジョブＩＤ１００及び要素ＩＤ１のレコードが「削除グループ」と「追加グループ」にそれぞれ２レコード存在するが、これらも同ステータスレコード群であり、同じステータスが設定されなければならない。よって、結果として、「削除グループ」及び「追加グループ」を合わせた６レコード全てが同ステータスレコード群となり、同じステータスが設定されなければならない。
【００８６】
そして、ステータス制御部７は、取得した同ステータスレコード群の中に、１つでも他のジョブＩＤであって、要素ＩＤ及びデータバージョンが一致するレコードが存在するか否かを判定する（ステップＳ５７）。存在しない場合（ステップＳ５７；Ｎｏ）、ステータス制御部７は、同ステータスレコード群全てのステータスに「更新対象」を設定する（ステップＳ６０）。一方、存在する場合（ステップＳ５７；Ｙｅｓ）、他のレコード、即ち他の編集と競合しているため、他のレコードのステータスが「更新完了」であるか否かを判定する（ステップＳ５８）。判定の結果、他のレコードのステータスが「更新完了」でない場合（ステップＳ５８；Ｎｏ）、ステータス制御部７は、同ステータスレコード群全てのステータスに「更新対象」を設定する（ステップＳ６０）。
【００８７】
なお、これによれば、異なるジョブＩＤであって、要素ＩＤ及びデータバージョンが一致する複数のレコードのステータスが「更新対象」となってしまうが、後述するステータスコントロール処理によって、競合の問題は回避することが可能である。
【００８８】
一方、ステップ５８の判定の結果、他のレコードのステータスが「更新完了」である場合（ステップＳ５８；Ｙｅｓ）、ステータス制御部７は、同ステータスレコード群全てのステータスに「放棄」を設定する（ステップＳ５９）。ステップＳ５９及びＳ６０によりステータスが設定されると、ステータス制御部７は、ステップＳ５４へ進む。そして、ステータス制御部７は、ステータス未設定のレコードが存在しないと判定した場合（ステップＳ５４；Ｎｏ）、初期ステータス設定処理を完了する。
【００８９】
このような初期ステータス設定処理によれば、図１２（ｂ）に示すように、ジョブＩＤ１００及び要素１のレコードは、既にステータスが「更新完了」となっているジョブＩＤ２００及び要素１のレコードと競合しているため、ステータスは「放棄」となる。また、図示のように、ジョブＩＤ１００及び要素１のレコードと同ステータスレコード群に属する他の５つのレコードのステータスも全て「放棄」となる。これにより、既に更新されているマスタデータが、後から行われた編集のレコードに基づいて上書きされるという問題を回避することができる。
【００９０】
[編集競合検査部]
次に、サーバ３０の構成要素である編集競合検査部６について、図１３乃至図１７を参照して詳細に説明する。図１３は、ジョブＩＤ２００により修正された編集前部分文書１０と編集後部分文書２０のデータ構造を模式的に示す図である。また、図１４は、修正競合検査部６、ステータス制御部７及びステータス入出力部８により実行されるステータスコントロール処理のフローチャートである。
【００９１】
サーバ３０は、図１４に示すように、検査が要求された任意のタイミングで編集履歴ＤＢ４を参照し、要素ＩＤ及びデータバージョンが一致し、ステータスが「更新対象」であるレコードが複数ジョブに存在するか否かを判定する（ステップＳ６１）。即ち、マスタＤＢ１に記憶されたマスタデータに反映していない編集のレコードの中で競合するものがあるか否かを判定する。複数ジョブに存在しない場合（ステップＳ６１；Ｎｏ）、即ち競合状態でない場合は、ステータスコントロールを行う必要がないため、ステータスコントロール処理を終了する。一方、複数ジョブに存在する場合（ステップＳ６１；Ｙｅｓ）、即ち競合状態の場合、サーバ３０は、警告を発し、ステータスコントロールを促す（ステップＳ６２）。これは、このままステータスコントロールを行わずにマスタデータへの更新処理を実行してしまうと、ステータスが「更新対象」のレコード全てがマスタデータに反映されることになり、編集内容が意図せず上書きされてしまうからである。
【００９２】
このような問題を回避するため、ステータスコントロールが行われる（ステップＳ６３）。つまり、ステータスコントロールとは、競合する複数のレコードにおいて、ステータスが「更新対象」のレコードを１つに集約する処理である。よって、ステータスコントロールでは、最優先するジョブＩＤのレコードのみステータスに「更新対象」を設定し、その他のジョブＩＤのレコードのステータスには「放棄」を設定する。
【００９３】
このステータスコントロールは、ステータス入出力部８を通して行われるが、図１５に示すような画面を設け、管理者が人為的に各レコードの編集意図を考慮して手動で行うこととしてもよい。図１５は、ステータスコントロール時の画面例であって、各レコードにラジオボタンやチェックボックスが対応付けられており、人為的に当該ラジオボタンやチェックボックスを選択することで、選択したレコードのステータスが「更新対象」となり、競合する他のレコードのステータスが「放棄」となるように設計されている。また、マスタデータへの反映を最初に行うことを明示したジョブＩＤのレコードのステータスを「更新対象」に設定する等のルールを予め設けておくことで、「更新対象」の選択を自動で行うこととしてもよい。自動で行った場合には、選択結果をメール等で管理者に通知することとしてもよい。
【００９４】
ステータスコントロールにおいて、管理者が手動でステータスを「更新対象」とするレコードを選択した場合、図１６（ａ）に示すように、ステータスを「放棄」とするレコードに対する必要作業を行ったか否かを確認するポップアップ画面を表示させることができる。ステータスが「放棄」となったレコードはマスタデータに反映されることがないため、ここでいう必要作業とは、ステータスが「放棄」となったレコードに対応する編集を反映されるレコードに対応する部分文書上に転記すること、利用者に自身の編集が反映されない旨通知すること等が考えられる。なお、必要作業はこれに限定されるものではなく、任意に設定することができる。
【００９５】
一方、ステータスコントロールにおいて、自動でステータスを「更新対象」とするレコードが選択される場合、図１６（ｂ）に示すように、ステータスが「放棄」となるレコードのリストを放棄リストとして画面上に表示し、管理者にどのレコードがマスタデータに反映されないかを通知させることができる。これによれば、管理者は、一定のルールに従って自動的に行われたステータスコントロールの内容を的確に把握し、必要作業を行うことができる。
【００９６】
なお、ステータスコントロールにおいて「更新対象」を選択する際、グループＩＤが存在するレコードでは、同一のグループＩＤ、ジョブＩＤ及び更新種別のレコードは１つのグループとして取り扱われるため、連動して全て同一のステータスが設定される。また、同一のジョブＩＤ及び要素ＩＤのレコードも、連動して全て同一のステータスが設定される。このように、同一のステータスが設定されるべきレコードを同ステータスレコード群と呼ぶ。このようにグループＩＤやジョブＩＤに基づいてステータスの設定を連動させることで、階層構造を考慮した上書きのコントロールも制御することが可能となる。よって、図１４に示すステータスコントロール処理においても、サーバ３０は、ステータスコントロールを行ったレコードがグループＩＤを保有しているか否かを判定する（ステップＳ６４）。判定の結果、グループＩＤを保有している場合（ステップＳ６４；Ｙｅｓ）、同ステータスレコード群に属するレコード全てに同一のステータスを設定し（ステップＳ６５）、競合状態がなくなるまで、ステップＳ６１乃至Ｓ６５の処理を繰り返し行う（ステップＳ６１）。また、判定の結果、グループＩＤを保有していない場合（ステップＳ６４；Ｎｏ）も同様に、競合状態がなくなるまで、ステップＳ６１乃至Ｓ６５の処理を繰り返し行う（ステップＳ６１）。そして、競合状態がなくなると（ステップＳ６１；Ｎｏ）、サーバ３０は、ステータスコントロール処理を完了する。
【００９７】
なお、ステータスを編集履歴ＤＢ４に記憶するタイミングは、必ずしもマスタデータへの更新処理の前である必要はない。例えば、マスタデータへの更新処理を最初に行うジョブＩＤのレコードを自動で「更新対象」とみなし、当該レコードをマスタデータへ反映させた直後にステータスを設定する運用でも構わない。
【００９８】
次に、ステータスコントロール処理について、具体的に図１０を参照して説明する。図１０に示す編集履歴ＤＢ４では、初期ステータスとして全てのレコードのステータスに「更新対象」が設定されている。このような編集履歴ＤＢ４では、要素２及び７において、ジョブＩＤ１００とジョブＩＤ２００にそれぞれステータスが「更新対象」のレコードが存在しているため、競合状態である。ここで、要素２のレコードについては、ジョブＩＤ２００のレコードを集約先とし、ジョブＩＤ１００のレコードを放棄したとする。その結果、ジョブＩＤ２００のレコードのステータスには「更新対象」が設定され、ジョブＩＤ１００のレコードのステータスには「放棄」が設定される。
【００９９】
一方、要素７のレコードについては、ジョブＩＤ１００のレコードを集約先とし、ジョブＩＤ２００のレコードを放棄したとする。ジョブＩＤ１００の要素７のレコードは、編集履歴ＤＢ４に２レコード存在し、これらは同じステータスでなくてはならない。また、それぞれがグループＩＤを「５」とする「削除」と「追加」のグループに属しているので、グループ内でも同じステータスにならなくてはならない。その結果、ジョブＩＤ１００のレコードでは、同ステータスレコード群に属する全てのレコードのステータスに「更新対象」が設定される。一方、ジョブＩＤ２００の要素ＩＤ７のレコードはグループに属していないので、要素ＩＤのレコードのみのステータスに「放棄」が設定される。このようにステータスコントロール処理により競合状態を回避するようにステータスが設定された編集履歴ＤＢ４は、図１７に示すようになる。図１７は、ステータスコントロール処理後の編集履歴ＤＢ４のデータ構造を模式的に示す図である。
【０１００】
[更新処理実行部]
次に、サーバ３０の構成要素である更新処理実行部５について、図１８乃至図２０を参照して詳細に説明する。
【０１０１】
更新処理実行部５は、ジョブ単位の複数のレコードから構成される編集履歴ＤＢ４と編集後部分文書２０に基づいて、マスタＤＢ１に記憶されたマスタデータについて変更があった部分のみを更新する。即ち、更新処理実行部５は、編集履歴ＤＢ４の更新種別毎にマスタデータに対して異なる上書き処理を行う。更新処理は、更新種別「削除」のレコードをマスタデータに反映する削除更新処理、更新種別「追加」のレコードをマスタデータに反映する追加更新処理、更新種別「修正」のレコードをマスタデータに反映する修正更新処理から構成されている。図１８は削除更新処理のフローチャート、図１９は追加更新処理のフローチャート、図２０は修正更新処理のフローチャートである。
【０１０２】
まず、図１８を参照して、削除更新処理について説明する。削除更新処理は、グループＩＤを参照してグループ単位で処理を行う。具体的には、グループＩＤと要素ＩＤとが一致するレコードに対してのみ、対応するマスタデータの要素を削除する処理を行う。グループＩＤの要素が削除されることで、その子孫要素も削除されるからである。
【０１０３】
図１８に示すように、削除更新処理において更新処理実行部５は、まず、編集履歴ＤＢ４から、ステータスが「更新対象」であって、更新種別が「削除」のレコードを１つ取得する（ステップＳ７１）。そして、更新処理実行部５は、当該レコードのグループＩＤと要素ＩＤが一致するか否かを判定する（ステップＳ７２）。一致すると判定した場合（ステップＳ７２；Ｙｅｓ）、当該レコードの要素ＩＤに対応するマスタデータの要素を削除する（ステップＳ７３）。一方、一致しないと判定した場合（ステップＳ７３；Ｎｏ）、マスタデータの更新は行わず、ステップＳ７４へ進む。ステップＳ７４において更新処理実行部５は、当該レコードのステータスを「更新完了」に設定する（ステップＳ７４）。そして、更新処理実行部５は、ステータスが「更新対象」であって、更新種別が「削除」のレコード全てを参照したか否かを判定し（ステップＳ７５）、参照していない場合（ステップＳ７５;Ｎｏ）、ステップＳ７１乃至Ｓ７５の処理を繰り返し行う。一方、参照した場合（ステップＳ７５；Ｙｅｓ）、削除更新処理を完了する。これにより、異なる複数のジョブで進行している削除の競合を制御することができる。
【０１０４】
次に、図１９を参照して、追加更新処理について説明する。追加更新処理は、グループＩＤを参照してグループ単位で処理を行う。具体的には、グループＩＤと要素ＩＤとが一致するレコードに基づいてのみ、編集後部分文書２０の対応する要素を、対応するマスタデータに追加する。グループＩＤの要素が追加されることで、その子孫要素も追加されるからである。
【０１０５】
図１９に示すように、追加更新処理において更新処理実行部５は、まず、編集履歴ＤＢ４から、ステータスが「更新対象」であって、更新種別が「追加」のレコードを１つ取得する（ステップＳ８１）。そして、更新処理実行部５は、当該レコードのグループＩＤと要素ＩＤが一致するか否かを判定する（ステップＳ８２）。一致すると判定した場合（ステップＳ８２；Ｙｅｓ）、当該レコードの要素ＩＤに対応する編集後部分文書２０の要素を、対応するマスタデータに親要素ＩＤの子要素として追加する（ステップＳ８３）。一方、一致しないと判定した場合（ステップＳ８２；Ｎｏ）、マスタデータの更新は行わず、ステップＳ８４へ進む。ステップＳ８４において更新処理実行部５は、当該レコードのステータスを「更新完了」に設定する（ステップＳ８４）。さらに、更新処理実行部５は、マスタデータに追加した要素のデータバージョンを更新する（ステップＳ８５）。そして、更新処理実行部５は、ステータスが「更新対象」であって、更新種別が「追加」のレコード全てを参照したか否かを判定し（ステップＳ８６）、参照していない場合（ステップＳ８６；Ｎｏ）、ステップＳ８１乃至Ｓ８６の処理を繰り返し行う。一方、参照した場合（ステップＳ８６；Ｙｅｓ）、追加更新処理を完了する。これにより、異なる複数のジョブで進行している追加の競合を制御することができる。
【０１０６】
次に、図２０を参照して、修正更新処理について説明する。修正更新処理は、修正レコードの要素ＩＤに対応する要素配下の要素ＩＤが付与されていないデータをマスタデータから削除すると共に、編集後部分文書２０における修正レコードの要素ＩＤに対応する要素配下の要素ＩＤが付与されていないデータをマスタデータに追加する処理である。
【０１０７】
図２０に示すように、修正更新処理において更新処理実行部５は、まず、編集履歴ＤＢ４から、ステータスが「更新対象」であって、更新種別が「修正」のレコードを１つ取得する（ステップＳ９１）。そして、更新処理実行部５は、当該レコードのＩＤに対応する要素配下のＩＤが付与されていないデータをマスタデータから全て削除する（ステップＳ９２）。さらに、更新処理実行部５は、編集後部分文書２０における当該レコードのＩＤに対応する要素配下のＩＤが付与されていないデータを、マスタデータに追加する（ステップＳ９３）。このようにして当該レコードをマスタデータに反映させた後、更新処理実行部５は、当該レコードのステータスを「更新完了」に設定する（ステップＳ９４）。さらに、マスタデータ上に追加したデータの親要素のデータバージョンを更新する（ステップＳ９５）。そして、更新処理実行部５は、ステータスが「更新対象」であって、更新種別が「修正」のレコード全てを参照したか否かを判定し（ステップＳ９６）、参照していない場合（ステップＳ９６；Ｎｏ）、ステップＳ９１乃至Ｓ９６の処理を繰り返し行う。一方、参照した場合（ステップＳ９６；Ｙｅｓ）、修正更新処理を完了する。これにより、異なる複数のジョブで進行している修正の競合を制御することができる。
【０１０８】
なお、更新処理において、追加更新処理と削除更新処理では、必ず削除更新処理を先に行う必要がある。修正更新処理は、特に順番は問わず、追加更新処理及び削除更新処理の前又は後のどちらに行っても構わない。
【０１０９】
次に、図１７に示す編集履歴ＤＢ４に基づいて上述の更新処理を行う場合について、図２１を参照して具体的に説明する。図２１（ａ）は更新前のマスタデータを、図２１（ｂ）は更新後のマスタデータの構造を模式的に示す図である。
【０１１０】
図１７は、ジョブＩＤ１００の編集とジョブＩＤ２００の編集が競合していたため、ステータスコントロール処理を行われたレコードが記憶されている編集履歴ＤＢ４のデータ構造を模式的に示す図である。ジョブＩＤ１００の編集内容は図５、ジョブＩＤ２００の編集内容は図１３に示されている。なお、図５及び図１３における編集前部分文書１０は、図２１（ａ）に示すような更新前のマスタデータから取得されたものとする。
【０１１１】
図１７に示す編集履歴ＤＢ７に記憶されたレコードのうち、ステータスに「更新対象」が設定されているレコードは、ジョブＩＤ１００の要素５及び要素７と、ジョブＩＤ２００の要素２とに対応するレコードである。このようなレコードにおいて、特に更新種別に着目する。
【０１１２】
更新種別が「修正」である要素２は、ジョブＩＤ１００のレコードとジョブＩＤ２００のレコードとが存在しているが、この場合、ステータスが「更新対象」に設定されているジョブＩＤ２００のレコードのみをマスタデータに反映させる。即ち、ステータスが「放棄」に設定されているジョブＩＤ１００のレコードはマスタデータに反映させることなく放棄する。そこで、更新処理実行部５は、図２１（ａ）及び（ｂ）に示すように、マスタデータの要素２配下のＩＤが付与されていないデータを削除し、ジョブＩＤ２００のレコードに基づいて、対応する編集後部分文書２０の要素２配下のＩＤが付与されていないデータを追加する。即ち、マスタデータの一部を編集後部分文書２０の一部で置換する。このとき、置換されたデータの親要素である要素２のデータバージョンが更新される。
【０１１３】
その他のレコードとして更新種別が「削除」と「追加」の２種類が存在するが、「削除」のレコードを先に処理する。この場合においても、ステータスに「更新対象」が設定されているレコードのみを処理し、ステータスに「放棄」が設定されているレコードはマスタデータに反映させない。よって、ジョブＩＤ１００のグループＩＤ５のグループについて削除更新処理を行う。このグループでは、要素ＩＤがグループＩＤと一致する、即ち要素ＩＤ５であるレコードについてのみ処理を行うため、図２１（ａ）に示すマスタデータの要素５を削除する。これに伴い、要素５の子要素である要素７も同時に削除される。
【０１１４】
次に、更新種別が「追加」のレコードに基づいて追加更新処理を行う。この場合においても、ステータスに「更新対象」が設定されているレコードのみを処理し、ステータスに「放棄」が設定されているレコードはマスタデータに反映させない。よって、ジョブＩＤ１００のグループＩＤ５のグループについて追加更新処理を行う。このグループでは、要素ＩＤがグループＩＤと一致する、即ち要素ＩＤ５であるレコードについてのみ処理を行うため、図２１（ｂ）に示すように、マスタデータの要素３を親要素とする位置に、編集後部分文書２０の要素５を追加する。これに伴い、要素５の子要素である要素７も同時に追加される。このとき、追加された要素５及び要素７のデータバージョンが更新される。このような追加更新処理を行うことで、マスタデータが、編集履歴ＤＢ４の内容を反映したものに更新されることになる。
【０１１５】
なお、本実施形態では、図２に示すように、サーバ３０が差分情報検出部３を有することとしているが、本発明はこれに限定されるものではなく、利用者端末４０が差分情報検出部３を有することとしても構わない。この場合であっても、利用者端末４０は、編集後部分文書２０をサーバ３０へ送信する必要がある。
【０１１６】
また、本実施形態では、「削除」、「追加」及び「修正」の３つを更新種別として設定しているが、本発明はこれに限定されるものではなく、さらに「移動」という更新種別を設定してもよい。「移動」は、編集前後で要素ＩＤの消失及び新規追加を伴わない構造変更を含んだ更新であり、「削除」及び「追加」双方の更新種別のレコードが編集履歴ＤＢ４に記憶されている要素について設定する。この場合、グループは、「削除」及び「追加」の更新種別のレコードのいずれかのグループに入れることとする。更新処理実行部５は、更新種別「移動」に対して、削除更新処理及び追加更新処理の双方を実行するが、これらの順序や実行すべきレコードは、いずれのグループに入れたかにより任意である。
【０１１７】
また、本実施形態では、編集の競合が検出できないパターンとして、「更新種別「追加」のレコードの親要素が別のジョブで削除されている」という編集が考えられる。例えば、図５に示すようなマスタデータにおいて、要素５の追加を行うジョブと、要素３の削除を行うジョブとが同時に存在するような場合である。このような編集が存在した場合、双方の編集をマスタデータに反映させると、当該マスタデータは意図しない状態に更新されてしまうことがある。よって、この状態を回避するためには、更新種別が「追加」のレコードの親要素ＩＤが、別のジョブで削除されていないかを編集履歴ＤＢ４で確認する必要がある。
【０１１８】
このように本発明によれば、マスタデータが階層構造の文書となっているため、１つのマスタデータから取得したそれぞれ異なる部分文書を複数人で並行して編集することができる。また、編集前部分文書１０と編集後部分文書２０の差分情報と、編集後部分文書２０とに基づいて、任意の要素単位でマスタデータを更新することができる。さらに、この差分情報に、編集単位の要素ＩＤやデータバージョンを関連付けることで、同時進行する編集の競合を事前に把握して回避するように制御することができる。よって、本発明により、大容量の構造化文書であっても、必要な箇所のみを部分文書として取得し、任意の階層の要素で容易に編集や更新が可能である。また、差分情報を編集履歴ＤＢ４に記憶することで、複数のプロセスで進行している編集作業の競合を、階層構造を考慮して事前に把握することができる。
【産業上の利用可能性】
【０１１９】
この編集システムによれば、差分情報及び編集後データから、任意の単位でマスタデータを更新することが可能であると共に、同時進行する編集の競合を事前に把握することができる。
【図面の簡単な説明】
【０１２０】
【図１】本発明における編集システムの概略構成を示す図である。
【図２】編集システムを構成するサーバ及び利用者端末の内部構成を示すブロック図である。
【図３】本発明における編集処理のフローチャートである。
【図４】本発明のマスタデータの構造を模式的に示す図である。
【図５】ジョブＩＤ１００における編集前部分文書及び編集後部分文書のデータ構造を模式的に示す図である。
【図６】本発明における削除検出処理のフローチャートである。
【図７】本発明における追加検出処理のフローチャートである。
【図８】本発明における修正検出処理のフローチャートである。
【図９】差分情報のデータ構造を模式的に示す図である。
【図１０】ステータスコントロール処理前の編集履歴ＤＢのデータ構造を模式的に示す図である。
【図１１】本発明における初期ステータス設定処理のフローチャートである。
【図１２】初期ステータス設定処理によるステータス設定例である。
【図１３】ジョブＩＤ２００における編集前部分文書及び編集後部分文書のデータ構造を模式的に示す図である。
【図１４】本発明におけるステータスコントロール処理のフローチャートである。
【図１５】更新対象を選択する際の表示画面例である。
【図１６】更新対象を選択する際の表示画面及び放棄リストの例である。
【図１７】ステータスコントロール処理後の編集履歴ＤＢのデータ構造を模式的に示す図である。
【図１８】本発明における削除更新処理のフローチャートである。
【図１９】本発明における追加更新処理のフローチャートである。
【図２０】本発明における修正更新処理のフローチャートである。
【図２１】更新前マスタデータと更新後マスタデータのデータ構造を模式的に示す図である。
【符号の説明】
【０１２１】
１…マスタＤＢ
２…編集機
３…差分情報検出部
４…編集履歴ＤＢ
５…更新処理実行部
６…編集競合検査部
７…ステータス制御部
８…ステータス入出力部
１０…編集前部分文書
２０…編集後部分文書
３０…サーバ
４０…利用者端末
【図１】
2006163912.tif 000003
【図２】
2006163912.tif 000004
【図３】
2006163912.tif 000005
【図４】
2006163912.tif 000006
【図５】
2006163912.tif 000007
【図６】
2006163912.tif 000008
【図７】
2006163912.tif 000009
【図８】
2006163912.tif 000010
【図９】
2006163912.tif 000011
【図１０】
2006163912.tif 000012
【図１１】
2006163912.tif 000013
【図１２】
2006163912.tif 000014
【図１３】
2006163912.tif 000015
【図１４】
2006163912.tif 000016
【図１５】
2006163912.tif 000017
【図１６】
2006163912.tif 000018
【図１７】
2006163912.tif 000019
【図１８】
2006163912.tif 000020
【図１９】
2006163912.tif 000021
【図２０】
2006163912.tif 000022
【図２１】
2006163912.tif 000023