JP2009545042A - データベース、殊にナビゲーションデータベースの更新方法 - Google Patents

Abstract

本発明は、複数のセグメント（１７；２４，２６；２８，２７；３０，３１）に分割されている分散型のデータベース（１０；１１）、例えばナビゲーションデータベースを、相応のセグメントに分割されている中央のデータベースから分散型のデータベースに更新されたセグメントを伝送し、且つこの更新されたセグメントを分散型のデータベースに記憶することによって更新する方法に関する。この方法においては、セグメントを分散型のデータベースにおいて階層的なモデルにマッピングし、セグメントの更新の際に、このセグメントが依存するセグメントも更新することによって、段階的な更新時の非一貫性が回避される。

Description

本発明は、セグメントに分割されている分散型のデータベース、殊にナビゲーションデータベースを、相応のセグメントに分割されている中央のデータベースから分散型のデータベースに更新されたセグメントを伝送し、更新されたセグメントを分散型のデータベースに記憶することによって更新する方法に関する。

今日のナビゲーションシステムは大規模なデータベースを有しており、そのようなデータベースには例えばディジタルマップのデータ、目標地点を入力するためのデータ、ルート検索およびルート表示のためのデータならびに車両の現在地を表示しながら目的地に案内するためのデータが記憶されている。さらにデータベースはドライバアシスタンスシステムのための付加的なデータも包含することができる。

データベースの利用者はデータベースに包含されている情報が最新の情報であるかということについて関心を持つ。例えば、データベースの基礎をなす道路網が変更されているか、ナビゲーションのデータベースが一時的な交通障害に関する情報を有していないためにそのような情報を考慮することができない場合、ドライバにとってナビゲーションデータベースの価値は低下する。別の例は最新のデータに依存しているコンピュータアプリケーションである。

分散型のデータベースは通常の場合、データセンタにおいて新しいデータのアベイラビリティが検査され、必要に応じてデータベースの新しいバージョンが提供されるように更新される。データベースの新しいバージョンが使用可能である場合には、データベースが統合されて更新データベースに記憶される。分散型のシステム、例えば車両内のナビゲーションシステムは適切な更新データをこの更新データベースからロードし、それらのデータを自身の分散型のデータベースにリンクさせる。

データベースの更新を完全に、または部分的に行うことができる。

完全な更新は全てのデータセットが相互に調整されているという利点を提供する。しかしながら、完全な更新は利用者にとって不必要なコスト的および時間的な負担に繋がることが多いという欠点を有する。このことは例えば、変更されていないデータ、または利用者にとって必要ないデータが伝送され、その費用がデータ容量に依存する場合である。

したがって１回の更新ステップにおいて生じるデータ量を低減するために、データベース全体を１回のステップでは更新させずに、データベースはその都度部分的に更新される。このために、データベースの内容が地理的な観点および／または主題の観点から、もしくはそれらを組み合わせて個々のセグメントに分割される。

もっとも部分的なステップで更新が行われる場合には、データベースがその一貫性を失う可能性があるので問題が発生する虞がある。つまり、部分領域の更新によって別のセグメントとの考えられる関係が消去される可能性がある。例えば、更新の際に一方のセグメントにおいてはある道路区分が消去され、他方の更新されていないセグメントが道路連結部によってその消去された道路区分を依然として示すことが考えられる。この種の非一貫性は部分的なステップで更新が行われる場合には回避されなければならない。

データベースの更新の際に非一貫性を回避するための現行のやり方では、データベースを重複しない複数のセグメントに分割し、それらのセグメントにそれぞれ１つのバージョン識別子を対応付けている。データベースの個々のセグメント間の依存性に基づき、バージョンの全ての組合せが一貫性のある状態を生じさせるものではない。したがってデータセンタおよび／または分散型のシステムは、分散型のデータベースを更新する度にバージョンの一貫性のある組合せが生じることを保証しなければならない。このような保証の手間は個々のセグメント間の依存性が増すにつれ上昇する。その種の依存性を低減するために、更新の際に検査されなければならないデータベースのセグメントは、セグメント間の関係の数が最小になるように形成される。

部分的なステップでデータベースを更新する際の別の問題はいわゆるなだれ効果である。このなだれ効果とは、利用者がデータベースのセグメントを１つだけ更新したいにもかかわらず、バージョンの一貫性のある組み合わせを達成するためにデータベースの複数のセグメントの複数のバージョンも同様に更新しなければならないことと解される。これによりやはりコストが高まり、また時間的な手間も増すことになる。

なだれ効果はデータベースが比較的小さいセグメントに分割されることにより限定することができる。しかしながら、バージョンの検査が必要になるデータベースの比較的小さいセグメントはその種のセグメントの数を増加させることになる。したがってバージョン管理のためのメンテナンスの手間および必要とされるメモリスペースも増加する。さらには、そのバージョンが検査されるデータベースのセグメントの付加または除去と解される、いわゆる構造変更の可能性も増す。構造変更は補助構造を用いてのみ管理することができる。

このような背景での本発明の課題は、データベースの任意のセグメントの改善された一貫性のある更新を実現することである。

この課題は、冒頭で述べた形式の方法により、分散型のデータベースにおけるセグメントが階層的なモデルにマッピングされ、分散型のデータベースにおけるセグメントの更新の際にそのセグメントが依存するセグメントも更新されることによって解決される。これによって１つのセグメントの更新がデータベースの非一貫性を生じさせることはない。何故ならば、その１つのセグメントが依存するそれぞれのセグメントも同様に更新されるからである。

階層的なデータ構造はさらに相対経路の記憶も実現し、これによって更新されたセグメントの記憶および伝送が従来に比べより効率的に行われ、データベースのメンテナンスの手間も低減される。好適には分散型のデータベースがツリー構造にマッピングされる。

セグメントへの分割を、分散型のデータベースにおいていわゆるバージョン付けされたノードが決定され、セグメントがルートとしてのそれぞれ１つのバージョン付けされたノードと、バージョン付けされていないノードである全ての下位ノードおよびその後続のノードとから形成されることによって実施することができる。ノードおよびルートという概念はツリー構造に制限されるものではなく、ここでは一般的に階層的なデータ構造に対して使用される。その他にノードはデータエレメントまたはデータベースのデータセットを表す。

データベース全体のルートとは階層的にデータベースの最高レベルに配置されているノードと解され、セグメントのルートとはそのセグメント内の階層的に最高レベルに配置されているノードと解される。バージョン付けされたノードとはデータツリーの全てのノードの１つのサブセットであり、そのデータツリーの要素にツリーのルートが属している。

バージョン付けされたノードの数およびデータベース内のその分配は個々の事例において有効性の観点に従い選択することができる。好適には、バージョン付けされたノードの数および決定は、頻繁に更新されることが予想されるデータが、下位のセグメントを有していない、または殆ど有していないセグメント内に存在するように行われる。このようにして、セグメントの更新がなだれ状の更新に発展することを阻止することができる。データベースの部分、例えばグローバルインデクスを前述のバージョン付けから除くことも排除されていない。この部分においては別のやり方で、これらのデータの部分が更新される場合に非一貫性が生じないことを保証しなければならない。

所定のセグメントのバージョンを区別できるようにするために各セグメントにはバージョン識別子が対応付けられる。例えばバージョン識別子を整数から構成することができる。

上位のセグメント（Ａ）が変更された場合に下位のセグメント（Ｂ）のバージョン識別子を変更する種々の可能性が存在する：１）セグメント（Ｂ）が変更されなかった場合には、セグメント（Ｂ）のバージョン識別子は変更されないままである；セグメント（Ｂ）が変更された場合には、セグメント（Ｂ）のバージョン識別子が高められる。２）セグメント（Ｂ）が変更されたか否かに依存せずにセグメント（Ｂ）のバージョン識別子がリセットされる（いわゆるリセット；例えば０へのリセット）。リセットによってセグメント（Ａ）の下位の全てのセグメントのバージョン識別子もリセットされる。３）セグメント（Ｂ）のバージョン識別子は選択的に変更されないままであるか、リセットされる。選択を任意に行うことができるか、状況に応じて行うことができる。

しかしながらバージョン識別子が別の情報、例えばセグメント内のデータの内容およびフォーマットに関する情報および／または下位のセグメントの構造に関する情報も含むことができる。バージョン識別子は所属のセグメント内に記憶されるか、分散型のデータベースの中央のリストに記憶される。これによってセグメントのバージョン識別子が後の時点にも使用される。

有利な実施形態においては、データセンタにおいてセグメントの各新しいバージョン識別子に関して、別のセグメントのどのバージョンが新しいバージョンと一致するかが検査される。このタスクを例えば更新コンパイラによって実施することができる。一方ではこれによって、分散型のデータベースの一貫性が保証される。他方では、分散型のシステムにおいて一貫性に関する付加的な検査を必要とすることなく、データベースの変更、殊に内容変更、フォーマット変更および／または構造変更を行うことができる。

一貫性の検査に関しては、バージョン付けされたセグメントのバージョンを一義的にアドレッシングできることが必要である。このことをバージョン経路によって行うことができる。バージョン経路はバージョン付けされたセグメントのバージョン識別子および下位のバージョン付けされた全てのセグメントのバージョン識別子からその成分が構成されているベクトルである。これによって依存関係にある下位のバージョンが認められる。しかしながら、バージョン付けされたセグメントのバージョンをそのバージョンのバージョン識別子、例えば整数によってアドレッシングすることも可能である。

分散型のデータベースを有するシステム、例えばナビゲーションシステムの高いモビリティを実現するために、有利には更新されたセグメントの伝送が無線で実施される。このことは例えばラジオもしくは無線伝送、または移動通信コネクションを介して実施することができる。択一的に、交換可能な記憶媒体を介したデータ伝送も考えられる。しかしながらまた、更新されたセグメントをインターネットによって伝送することも考えられる。

以下では添付の図面を参照しながら本発明を詳細に説明する。

更新システムの概観を示す。 階層的に構造化されたデータベースの一例を示す。 下位の更新セグメントの付加を概略的に示したものである。 下位の更新セグメントの変更を概略的に示したものである。 下位の更新セグメントの除去を概略的に示したものである。

以下の説明はナビゲーションシステムを基礎とする。しかしながら本発明はナビゲーションシステムに制限されるものではなく、更新されたデータが必要とされ、且つデータベースに追加されなければならない分野であればどのような分野にも使用することができる。例として、インターネットからのゲームまたはアプリケーションプログラムの更新されたバージョンのダウンロードが挙げられる。

図１にはデータセンタ１が示されている。データセンタにおいてナビゲーションデータベースが作成される。ナビゲーションデータベースは例えば道路網に関する情報、またはいわゆる関心拠点すなわちＰＯＩ（Points of Interest）、例えばガソリンスタンド、ホテルまたは名所などの位置に関する情報を含む。

データセンタ１はデータを収集および編成するデータコンパイラ２を有する。データコンパイラ２はナビゲーションデータベースに必要とされるデータまたはナビゲーションデータベースにとって有用なデータ、例えば前述の道路網に関するデータを収集する。これらのデータからデータコンパイラ２はナビゲーションデータベースの生データの更新データ３，４，５を構成する。図１においては、３つの円筒が連続する３年間にわたるナビゲーションデータベースの３つの更新データ３，４，５を表している。各更新データ３，４，５は基礎をなすナビゲーションデータベースの生データの全てのデータセットを含む。前年の更新データ３，４に対するデータの変更は全てのデータセットに関係していてはならない。つまり、生データは地域全体に関する道路網を含んでいるにもかかわらず、道路網のデータは局地定な領域においてしか変更されていないことが考えられる。

更新コンパイラ６は、先行の更新データ３，４と比べてデータセットはどこが変更されたかについて、データコンパイラ２によって収集された更新データ３，４，５を検査する。更新コンパイラ６は変更を確認すると、更新データ３，４，５を更新データベース７に供給する。更新データベース７からそれらのデータを分散型のシステム８に伝送することができるか、分散型のシステム８からそれらのデータを呼び出すことができる。

分散型のシステム８は図示されている実施例においては車両内に設置されているナビゲーションシステムである。分散型のシステム８は更新インテグレータ９を有し、この更新インテグレータ９は更新データベースからデータを呼び出し、分散型のシステム８に伝送する。更新インテグレータ９は続いて、分散型のシステム８内の分散型のデータベース１０、この実施例ではすなわち車両内のナビゲーションデータベースを更新する。

図２には、データベース１１がデータツリーの構造、詳細にはバイナリツリーの構造にマッピングされており、このデータツリーにおいてはノード１２から最大で２つの下位ノード１３が分岐している。

しかしながら本発明にとって、データベース１１がツリー構造にマッピングされることは必要条件ではない。データベースが階層的なデータ構造であるか、少なくとも階層的なデータ構造に変更できることのみが必要とされる。階層的に配置されていないデータ構造を階層的な構造に投影するための簡単な手段は、データベース全体をツリーのルートとみなし、データベースの各セグメントをルートの直下に配置されるノードとして処理することである。しかしながら比較的深いデータ構造が所望されることも考えれる。これは例えばＸＭＬ（拡張可能なマークアップ言語；Extensible Markup Language）を用いて達成することができる。各ＸＭＬ要素を階層的なデータモデルにおけるノードとみなすことができる。

データベース１１はノード１４，１５について２つの異なるクラスを有する。一方のクラスはバージョン付けされたノード１４のセットを形成し、他方のクラスはバージョン付けされていないノード１５のセットを形成する。データベース１１内のバージョン付けされたノード１４の数および分配はデータベース１１の更新の際に考慮されなければならないデータの相互的な依存性を決定する。２つのクラスへの区分は、ルート１６がバージョン付けされたノード１３を示さなければならないことを除き任意である。

バージョン付けされたノード１４およびバージョン付けされていないノード１５はバージョン付けされたセグメント１７に統合されている。バージョン付けされたセグメント１７は図２において点状に示されている。各バージョン付けされたセグメント１７はバージョン付けされたノード１２，１４，１６、また必要に応じて、これらのバージョン付けされたノード１２，１４，１６に依存する、すなわち下位のバージョン付けされていない全てのノード１５ならびにそれらの後続のバージョン付けされていない全てのノードから構成されている。したがって各バージョン付けされたセグメント１７はバージョン付けされたノード１２，１４，１６を１つだけ有する。バージョン付けされたセグメント１７の意義は、そのセグメント１７のデータの一部しか変更されなかった場合であっても、その全体を更新する必要があるということにある。

以下ではデータベース１１をナビゲーションデータベースに関するデータに基づき詳細に説明する。

データツリーのルート１６は最高レベル１８、いわゆるデータベースレベルを形成する。ルート１６は地域全体の道路地図を表す。第２レベル１９、いわゆるリストレベルにおいてはノード１４が地域における地理的に限定された領域を表す。次に下位のレベル２０、いわゆるファイルレベルにはバージョン付けされたノード２０が存在し、このノード２０はノード１４の下位に設けられており、またノード１４によって表される地理的な領域の関心拠点に関する情報を有する。バージョン付けされたノード１４は、地理的な領域の道路地図についての情報を含む別の下位のノード２１を有する。ノード２１は下位のノード２２を有し、この下位のノード２２は第４レベル２３、いわゆるエレメントレベルに位置する。ノード２２はノード２１によって表される道路にある家の３Ｄ表示を含む。データツリーは別のレベル、例えば付加的なリストレベルまたは属性レベルを有していても良い。

以下では、データベース１１の個々のバージョン付けされたセグメント１７への区分がどのような結果をもたらすかを詳細に説明する。

利用者がノード１４によって表される地理的な領域の関心拠点にもはや関心を有していないことに基づきデータベース１１が変更される場合には、ルートとしてのバージョン付けされたノード２０によって決定されるバージョン付けされたセグメントをバージョン付けされたセグメント１７の更新を必要とすることなく消去することができる。このことは、消去された関心拠点はバージョン付けされたセグメント１７の下位に位置するバージョン付けされたセグメントに属することから結論される。これに対してノード２１内の道路地図についてのデータが変更されるべき場合には、バージョン付けされたセグメント１７全体を更新する必要がある。

図３においては、左側の四角に所定の時点におけるバージョン付けされたセグメント２４が示されている。データベースは一度更新され、このことは矢印２５によって示唆されている。この更新によってデータバンクにバージョン付けされたセグメント２６が付加される。バージョン付けされたセグメント２６はバージョン付けされたセグメント２４の直下に配置されている。つまり、それらのノード間にレベルは存在しない。各バージョン付けされたセグメント２４，２６は自身の固有のバージョンを有しており、その固有のバージョンはそれぞれのバージョン付けされたセグメント２４，２６に記憶されているか、バージョン付けされたセグメント２４，２６の外部にある中央のリストに記憶されている。更新の前に、バージョン付けされたセグメント２４はバージョン識別子ｎを有している。ここでｎは整数を表す。下位のバージョン付けされたセグメント２６の付加後にバージョン付けされたセグメント２４のバージョン識別子は１高められる。つまりバージョン付けされたセグメント２４はその時点においてバージョン識別子ｎ＋１を有する。付加されたバージョン付けされたセグメント２６はそれ以前に存在していなかったのでバージョン識別子１を得る。

バージョン付けされたセグメント２４，２６は段階的にバージョンアップを伴うことによってしか適切に更新することはできないので、個々のバージョン付けされたセグメント２４，２６のバージョンを記憶することは重要である。これによって、バージョン付けされたセグメントのバージョン番号を識別した際にこのバージョン付けされたセグメントの時間的な状態を再構成することができる。

図４においては、所定の時点におけるバージョン付けされたセグメント２７が示されており、このバージョン付けされたセグメント２７の下位にはバージョン付けされたセグメント２８が配置されている。バージョン付けされたセグメント２７はバージョン識別子ｎを有し、バージョン付けされたセグメント２８はバージョン識別子ｍを有する。ここでｍおよびｎは整数である。矢印２９によって示唆されている更新の間にバージョン付けされたセグメント２８が変更される。この理由からバージョン付けされたセグメント２８のバージョン識別子は１高められるので、このバージョン付けされたセグメント２８はバージョン識別子ｍ＋１を有する。バージョン付けされたセグメント２７のバージョン識別子は変更されないままである。

図５においては、所定の時点におけるバージョン付けされたセグメント３１を有するバージョン付けされたセグメント３０が示されている。バージョン付けされたセグメント３０はバージョン識別子ｎを有し、バージョン付けされたセグメント３１はバージョン識別子ｍを有する。ここでｍおよびｎは整数である。矢印３２によって示唆されている更新の間にバージョン付けされたセグメント３１が除去されている。バージョン付けされたセグメント３０のバージョン識別子はこれによって１高められ、ｎ＋１を有する。

Claims (7)

1. 複数のセグメント（１７；２４，２６；２８，２７；３０，３１）に分割されている分散型のデータベース（１０；１１）、例えばナビゲーションデータベースを、相応のセグメント（１７；２４，２６；２８，２７；３０，３１）に分割されている中央のデータベースから前記分散型のデータベース（１０；１１）に更新されたセグメント（１７；２４，２６；２８，２７；３０，３１）を伝送し、且つ該更新されたセグメント（１７；２４，２６；２８，２７；３０，３１）を前記分散型のデータベース（１０；１１）に記憶することによって更新する方法において、
   前記セグメント（１７；２４，２６；２８，２７；３０，３１）を前記分散型のデータベース（１０；１１）において階層的なモデルにマッピングし、前記セグメント（１７；２４，２６；２８，２７；３０，３１）の更新の際に、該セグメント（１７；２４，２６；２８，２７；３０，３１）が依存するセグメント（１７；２４，２６；２８，２７；３０，３１）も更新することを特徴とする、方法。
2. 前記階層的なモデルはツリー構造を有する、請求項１記載の方法。
3. 前記分散型のデータベース（１０；１１）においてバージョン付けされたノード（１２，１４，１６，２０，２２）を決定し、前記セグメント（１７；２４，２６；２８，２７；３０，３１）を、ルートとしてのそれぞれ１つのバージョン付けされたノード（１２，１４，１６，２０，２２）と、バージョン付けされていないノード（１２，１４，１６，２０，２２）である全ての下位ノード（１５，２１）および該下位ノードの後続のノードとから形成する、請求項１または２記載の方法。
4. 各セグメント（１７；２４，２６；２８，２７；３０，３１）に１つのバージョンを対応付ける、請求項１から３までのいずれか１項記載の方法。
5. 前記バージョンを整数によって表す、請求項４記載の方法。
6. 前記バージョンを所属の前記セグメント（１７；２４，２６；２８，２７；３０，３１）に記憶するか、前記分散型のデータベース（１０；１１）の中央のデータ構造に記憶する、請求項３から５までのいずれか１項記載の方法。
7. データセンタ（１）において、セグメント（１７；２４，２６；２８，２７；３０，３１）の各新しいバージョンに関して、別のセグメントのどのバージョンが前記新しいバージョンと一致するかを検査する、請求項３から６までのいずれか１項記載の方法。

Images