JP5655811B2 - データ処理装置、データ処理方法、及びデータ処理プログラム - Google Patents

Description

本発明は、データ処理装置、データ処理方法、及びデータ処理プログラムに関する。

従来、利用者の現在位置から目的地に至る経路を案内するナビゲーション装置の如きデータ処理装置においては、地名データや施設データの如き様々な膨大な検索データを、ユーザが検索可能な構造であって、かつ、効率よく更新可能な構造で、構成する必要がある。

このような点に鑑みて、従来のデータは、集合型データ又は分散型データとして構成されていた。集合型データは、比較的大きな単位のファイル（エリアファイル）として集合的に構成された検索データであり、この検索データの内部の参照先データを特定する場合には、検索データに格納された参照先特定用のデータ（先頭データからの相対的な位置を示すオフセット）を利用するデータである（例えば、特許文献１参照）。一方、分散型データは、比較的小さな単位の複数のファイルとして分散的に構成された検索データであり、この検索データの内部の参照先データを特定する場合には、これら複数のファイルとは別途に設定したファイル特定用のファイルを利用するデータである。

特開２００４−１９８８４１号公報

しかしながら、集合型データと分散型データのいずれの検索データに関しても問題があった。すなわち、集合型データに関しては、エリアファイルの内部の特定のデータを更新する場合、当該データ以降のデータに対応する全てのオフセットを更新する必要があり、膨大な更新時間を有するという問題があった。また、分散型データに関しては、全体としてファイル数が膨大になるために、ナビゲーション装置のデータベースのファイル数の制限を超えてしまい、分散型データの利用自体ができない場合があった。

本発明は、上記に鑑みてなされたものであって、データを構成するファイルの数が少なくても、データの検索や更新を容易に行うことが可能になる、データ処理装置、データ処理方法、及びデータ処理プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、請求項１に記載のデータ処理装置は、同一のファイルの内部に格納されたデータであって、少なくとも一つのデータレコードを含む複数のデータテーブルを階層構造化して構成されたデータを少なくとも格納するデータ格納手段と、前記データ格納手段にて格納された複数のデータテーブルの中から、参照対象のデータテーブルの先頭位置を特定する特定手段とを備え、前記データ格納手段は、前記複数のデータテーブルを、最上位階層のデータテーブルを先頭として、同一系統のデータテーブルを上位階層から下位階層に至る順に前記ファイルに格納し、前記複数のデータテーブルの各々は、当該データテーブルと同一系統に属するデータテーブルであって、当該データテーブルより一つだけ下位階層のデータテーブルを一意に識別するための識別情報と、当該データテーブルより一つだけ下位階層のデータテーブルのデータサイズである次段サイズと、当該データテーブルより下位階層の全てのデータテーブルのデータサイズの合計値である配下サイズとを含み、前記最上位階層のデータテーブルは、当該データテーブルのデータサイズを含み、前記特定手段は、特定対象のデータテーブルの識別情報が所定方法で指定された場合に、前記データ格納手段にて格納された前記データテーブルの前記配下サイズを、前記最上位階層のデータテーブルから、前記識別情報に基づいて識別された前記特定対象のデータテーブルより一つ前の格納位置に格納されたデータテーブルに至るまで、前記データ格納手段における前記データテーブルの格納順に加算することで、前記ファイルにおける前記最上位階層のデータテーブルの先頭位置から前記特定対象のデータテーブルの先頭位置までの相対的な位置を特定する。

請求項２に記載のデータ処理装置は、請求項１に記載のデータ処理装置において、前記データ格納手段は、データ処理の対象になる実データと、データ処理の対象になる実データの位置を特定するためのインデックスデータとを格納し、前記実データは、文字データを含む複数の実データレコードを当該文字データにおける文字位置及び文字語順に基づいた整列順序で整列して構成されると共に、前記データ格納手段において前記ファイルとは異なる実データファイルに格納され、前記インデックスデータは、前記データとして構成されると共に、前記文字データの前記整列順序に応じて階層構造化され、前記インデックスデータの複数のデータテーブルの各々は、自己に対応する前記実データレコードのサイズである実サイズを含み、前記特定手段は、前記最上位階層のデータテーブルの先頭位置から前記特定対象のデータテーブルの先頭位置までの相対的な位置を特定した後、前記データ格納手段にて格納された前記データテーブルの前記実サイズを、前記最上位階層のデータテーブルから、当該特定された相対的な位置に対応する前記データテーブルより一つ前の格納位置に格納されたデータテーブルに至るまで、前記データ格納手段における前記データテーブルの格納順に加算することで、前記実データファイルにおける最初の実データの先頭位置から、前記特定対象の実データの先頭位置までの相対的な位置を特定する。

請求項３に記載のデータ処理装置は、請求項１に記載のデータ処理装置において、前記複数のデータレコードの一部のデータレコードが更新された場合、当該更新されたデータレコードが属するデータテーブルと同一系統に属するデータテーブルであって、当該データテーブルより上位階層の全てのデータテーブルの前記次段サイズと前記配下サイズとを、当該更新されたデータレコードのデータサイズに基づいて更新する更新手段を備えた。

請求項４に記載のデータ処理装置は、請求項２に記載のデータ処理装置において、前記複数の実データレコードの一部の実データレコードが更新された場合、当該更新された実データレコードに対応するインデックステーブルの前記実サイズと、当該インデックステーブルと同一系統に属するインデックステーブルであって、当該インデックステーブルより上位階層の全てのインデックステーブルの前記実サイズとを、当該更新された実データレコードのデータサイズに基づいて更新する更新手段を備えた。

請求項５に記載のデータ処理方法は、同一のファイルの内部に格納されたデータであって、少なくとも一つのデータレコードを含む複数のデータテーブルを階層構造化して構成されたデータを少なくともデータ格納手段に格納するデータ格納ステップと、前記データ格納ステップにて格納された複数のデータテーブルの中から、参照対象のデータテーブルの先頭位置を特定する位置特定ステップとを含み、前記データ格納ステップにおいては、前記複数のデータテーブルを、最上位階層のデータテーブルを先頭として、同一系統のデータテーブルを上位階層から下位階層に至る順に前記ファイルに格納し、前記複数のデータテーブルの各々は、当該データテーブルと同一系統に属するデータテーブルであって、当該データテーブルより一つだけ下位階層のデータテーブルを一意に識別するための識別情報と、当該データテーブルより一つだけ下位階層のデータテーブルのデータサイズである次段サイズと、当該データテーブルより下位階層の全てのデータテーブルのデータサイズの合計値である配下サイズとを含み、前記最上位階層のデータテーブルは、当該データテーブルのデータサイズを含み、前記位置特定ステップにおいては、特定対象のデータテーブルの識別情報が所定方法で指定された場合に、前記データ格納ステップにて格納された前記データテーブルの前記配下サイズを、前記最上位階層のデータテーブルから、前記識別情報に基づいて識別された前記特定対象のデータテーブルより一つ前の格納位置に格納されたデータテーブルに至るまで、前記データ格納手段における前記データテーブルの格納順に加算することで、前記ファイルにおける前記最上位階層のデータテーブルの先頭位置から前記特定対象のデータテーブルの先頭位置までの相対的な位置を特定する。

請求項６に記載のデータ処理プログラムは、請求項５に記載の方法をコンピュータに実行させるプログラムである。

請求項１に記載のデータ処理装置、請求項５に記載のデータ処理方法、及び請求項６に記載のデータ処理プログラムによれば、同一のファイルの内部に格納されたデータであって、少なくとも一つのデータレコードを含む複数のデータテーブルを階層構造化して構成されたデータを用いて、ファイルにおける最上位階層のデータテーブルの先頭位置から特定対象のデータテーブルの先頭位置までの相対的な位置を特定することができるので、データを構成するファイルの数を一つに抑制することができると共に、データの検索を容易に行うことが可能になる。

請求項２に記載のデータ処理装置によれば、データ格納手段は、データ処理の対象になる実データと、データ処理の対象になる実データの位置を特定するためのインデックスデータとを格納し、実データファイルにおける最初の実データの先頭位置から、特定された実データの先頭位置までの相対的な位置を特定することができるので、データを構成するファイルの数を二つに抑制することができると共に、データの検索を容易に行うことが可能になる。

請求項３に記載のデータ処理装置によれば、複数のデータレコードの一部のデータレコードが更新された場合、上位階層の全てのデータテーブルの次段サイズと配下サイズとを更新することで、データの更新が完了するので、データの更新を容易に行うことが可能になる。

請求項４に記載のデータ処理装置によれば、複数の実データレコードの一部の実データレコードが更新された場合、インデックステーブルの実サイズと、上位階層の全てのインデックステーブルの前記実サイズとを更新することで、データの更新が完了するので、データの更新を容易に行うことが可能になる。

本発明の実施の形態１に係るナビゲーションシステムを例示するブロック図である。 検索データの階層構造を示す図である。 検索データファイルにおける検索データの格納順序を示す図である。 特定処理のフローチャートである。 更新処理のフローチャートである。 実施の形態２に係るナビゲーションシステムを例示するブロック図である。 実データの階層構造を示す図である。 実データファイルにおける実データの格納順序を示す図である。 インデックスデータの階層構造を示す図である。 インデックスデータファイルにおけるインデックスデータの格納順序を示す図である。 特定処理のフローチャートである。 図１１に続く、特定処理のフローチャートである。 更新処理のフローチャートである。

以下、本発明に係るデータ処理装置、データ処理方法、及びデータ処理プログラムの各実施の形態について図面を参照しつつ詳細に説明する。ただし、各実施の形態によって本発明が限定されるものではない。なお、本発明に係るデータ処理装置、データ処理方法、及びデータ処理プログラムの適用対象は任意であるが、例えば、地図データを処理するナビゲーション装置に適用することが考えられる。以下の各実施の形態では、データ処理装置がナビゲーション装置として構成された場合を例に挙げて説明する。

〔実施の形態１〕
最初に、実施の形態１について説明する。この実施の形態１は、データ処理の対象になるデータ自身のデータサイズに基づいて、データの位置を特定する形態である。

（構成）
まず、実施の形態１に係るデータ処理装置としてのナビゲーション装置を用いたナビゲーションシステムの構成を説明する。図１は、実施の形態１に係るナビゲーションシステムを例示するブロック図である。図１に示すように、ナビゲーションシステム１は、現在位置取得部２、タッチパネル３、ディスプレイ４、スピーカ５、及びデータ処理装置としてのナビゲーション装置６を備えている。

（構成−現在位置取得部）
現在位置取得部２は、ナビゲーション装置６が取り付けられた車両（以下、自車両）の現在地点を検出する現在地点検出手段である。具体的には、現在位置取得部２は、ＧＰＳ、地磁気センサ、距離センサ、又はジャイロセンサ（いずれも図示省略）の少なくとも一つを有し、現在の自車両の位置（座標）及び方位等を公知の方法にて検出する。

（構成−タッチパネル）
タッチパネル３は、ユーザの指等で押圧されることにより、当該ユーザから各種手動入力を受け付けるものである。このタッチパネル３は、透明又は半透明状に形成され、ディスプレイ４の前面において当該ディスプレイ４の表示面と重畳するように設けられている。このタッチパネル３としては、例えば抵抗膜方式や静電容量方式等による操作位置検出手段を備えた公知のタッチパネルを使用することができる。

（構成−ディスプレイ）
ディスプレイ４は、ナビゲーション装置６によって案内された画像を表示する表示手段である。ディスプレイ４の具体的な構成は任意であり、公知の液晶ディスプレイや有機ＥＬディスプレイの如きフラットパネルディスプレイを使用することができる。

（構成−スピーカ）
スピーカ５は、ナビゲーション装置６の制御に基づいて各種の音声を出力する出力手段である。スピーカ５より出力される音声の具体的な態様は任意であり、必要に応じて生成された合成音声や、予め録音された音声を出力することができる。

（構成−ナビゲーション装置）
ナビゲーション装置６は、車両の走行経路を案内する案内装置であると共に、データ処理を行うデータ処理装置であり、制御部７及びデータ記録部８を備えている。

（構成−データ処理装置−制御部）
制御部７は、ナビゲーション装置６を制御する制御手段であり、具体的には、ＣＰＵ、当該ＣＰＵ上で解釈実行される各種のプログラム（ＯＳなどの基本制御プログラムや、ＯＳ上で起動され特定機能を実現するアプリケーションプログラムを含む）、及びプログラムや各種のデータを格納するためのＲＡＭの如き内部メモリを備えて構成されるコンピュータである。特に、実施の形態に係るデータ処理プログラムは、任意の記録媒体又はネットワークを介してナビゲーション装置６にインストールされることで、制御部７の各部を実質的に構成する。

この制御部７は、機能概念的に、特定部９と更新部１０を備える。特定部９は、後述する検索情報ＤＢ１２にて格納された複数のデータテーブルの中から、参照対象のデータテーブルの先頭位置を特定する特定手段である。更新部１０は、複数のデータレコードの一部のデータレコードが更新された場合、当該更新されたデータレコードが属するデータテーブルと同一系統に属するデータテーブルであって、当該データテーブルより上位階層の全てのデータテーブルの次段サイズと配下サイズとを、当該更新されたデータレコードのデータサイズに基づいて更新する更新手段である。これらの制御部７の各部によって実行される処理の詳細や、データレコード、データテーブル、次段サイズ、及び配下サイズの詳細については、後述する。

（構成−データ処理装置−データ記録部）
データ記録部８は、ナビゲーション装置６の動作に必要なプログラム及び各種のデータを格納するデータ格納手段であり、例えば、外部記録装置としてのハードディスク（図示省略）を用いて構成されている。ただし、ハードディスクに代えてあるいはハードディスクと共に、磁気ディスクの如き磁気的記録媒体、又はＤＶＤやブルーレイディスクの如き光学的記録媒体を含む、その他の任意の記録媒体を用いることができる。

このデータ記録部８は、地図情報データベース（以下、データベースを「ＤＢ」と表記する）１１と、検索情報ＤＢ１２を格納する。

地図情報ＤＢ１１は、地図データを格納するデータ格納手段である。「地図データ」とは、地図をディスプレイ４に表示したり、走行経路の探索や案内を行うために必要なデータであり、例えば、ノードデータ（ノード番号、座標）や、リンクデータ（リンク番号、接続ノード番号、道路座標、道路種別、車線数、走行規制等）、地物データ（信号機、道路標識、ガードレール、建物等）、地形データ、地図をディスプレイ４に表示するための地図表示データ等を含んで構成されている。

検索情報ＤＢ１２は、検索データを格納するデータ格納手段である。実施の形態１における「検索データ」とは、場所（番地）を検索するためのデータであって、少なくとも一つのデータレコードを含む複数のデータテーブルを階層構造化して構成されており、検索情報ＤＢ１２の検索データファイル１３に格納されている。

図２は、検索データの階層構造を示す図である。この図２に示すように、検索データは、一つの最上位階層（第１階層）のデータテーブルＤＴ１と、このデータテーブルＤＴ１に対して一つだけ下位階層（第２階層）に位置付けられたデータテーブルＤＴ２、ＤＴ５と、このデータテーブルＤＴ２、ＤＴ５に対してさらに一つだけ下位階層（第３階層）に位置付けられたデータテーブルＤＴ３、ＤＴ４、ＤＴ６、ＤＴ７とを含んでいる。これらデータテーブルＤＴ１〜ＤＴ７は、検索データが示す場所の地理的階層に対応した階層で構造化されたものであって、検索データが示す場所の地理的階層に対応したデータを含むものである。すなわち、第１階層のデータテーブルＤＴ１は、日本の都道府県を検索するためのデータを含む。第２階層のデータテーブルＤＴ２、ＤＴ５は、市区町村を検索するためのデータを含む。第３階層のデータテーブルＤＴ３、ＤＴ４、ＤＴ６、ＤＴ７は、市区町村より一つ下の下位の地理的階層を検索するためのデータを含む（以下、データテーブルの符号ＤＴ１〜ＤＴ７を省略する）。

各データテーブルのデータレコードは、具体的には、一つの親のデータレコード（以下、親レコード）と、一つ以上の子のデータレコード（以下、子レコード）とを含んで構成されている。例えば、第１階層のデータテーブルは、親レコード「ｒｏｏｔ」と、子レコード「北海道」及び子レコード「青森県」を含む。また、第２階層のデータテーブル「北海道」は、親レコード「北海道」と、子レコード「札幌市」及び子レコード「旭川市」を含む。また、第３階層のデータテーブル「札幌市」は、親レコード「札幌市」と、子レコード「中央区」及び子レコード「西区」を含む。

各データテーブルの親レコードは、当該親レコードが属するデータテーブルの参照用データを含むレコードである。「参照用データ」とは、各データテーブルや各データレコードを参照するために使用されるデータであり、例えば、当該親レコードと同じデータテーブルに含まれる子レコードのレコード数を含んでおり、この子レコードのレコード数を用いて、後述する各処理において子レコードを取得する際における当該子レコードの読み込み終了位置を管理している。

各データテーブルの子レコードは、検索用テキストデータ、識別コード、次段サイズ、及び配下サイズを含む。「検索用テキストデータ」とは、場所（番地）を検索するためにディスプレイ４等に表示されるテキストデータであり、例えば、データテーブル「ｒｏｏｔ」の子レコード「北海道」は、検索用テキストデータ「北海道」を含む。「識別コード」とは、各データテーブル（具体的には、各子レコード）を一意に識別するための識別情報である。「次段サイズ」とは、当該子レコードと同一系統に属するデータテーブルであって、当該子レコードが属するデータテーブルより一つだけ下位階層のデータテーブルのデータサイズである。「配下サイズ」とは、当該子レコードと同一系統に属するデータテーブルであって、当該データテーブルより下位階層の全てのデータテーブルのデータサイズの合計値である。

ここで、「同一系統」とは、上位階層のデータテーブルの子レコードと、当該データテーブルより一つだけ下位階層のデータテーブルの親レコードとが、直接的な階層関係を有する系統（図２では矢印で直接的に結ばれた系統）である。例えば、データテーブル「ｒｏｏｔ」−データテーブル「北海道」−データテーブル「札幌市」は相互に同一系統に属し、データテーブル「ｒｏｏｔ」−データテーブル「北海道」−データテーブル「旭川市」は相互に同一系統に属するが、データテーブル「札幌市」とデータテーブル「旭川市」は同一系統には属していない。

この次段サイズに関して、例えば、図２の例では、データテーブル「ｒｏｏｔ」の子レコード「北海道」は、データテーブル「北海道」のデータサイズ＝８２００Ｂｙｔｅを次段サイズとして有し、データテーブル「北海道」の子レコード「札幌市」は、データテーブル「札幌市」のデータサイズ＝５００Ｂｙｔｅを次段サイズとして有する。なお、データテーブル「札幌市」の子レコード「中央区」は、それより下位階層のデータテーブルが存在しないことから、データサイズ＝０Ｂｙｔｅを次段サイズとして有する。

また、この配下サイズに関して、例えば、図２の例では、データテーブル「ｒｏｏｔ」の子レコード「北海道」は、データテーブル「北海道」のデータサイズ＝８２００Ｂｙｔｅ、データテーブル「札幌市」のデータサイズ＝５００Ｂｙｔｅ、及びデータテーブル「旭川市」のデータサイズ＝２２０００Ｂｙｔｅ、の合計値＝３０７００Ｂｙｔｅを配下サイズとして有する。あるいは、データテーブル「北海道」の子レコード「札幌市」は、データテーブル「札幌市」のデータサイズ＝５００Ｂｙｔｅを配下サイズとして有する。なお、最上位階層のデータテーブル「ｒｏｏｔ」の親レコード「ｒｏｏｔ」は、当該データテーブル「ｒｏｏｔ」のデータサイズ＝２５０Ｂｙｔｅを含む。

このように階層構造化された検索データは、一つの検索データファイル１３に格納されている。図３は、検索データファイル１３における検索データの格納順序を示す図である。この図３に示すように、検索データファイル１３には、複数のデータテーブルが、最上位階層のデータテーブルを先頭として、同一系統のデータテーブルを上位階層から下位階層に至る順に格納されている。より具体的には、検索データファイル１３の先頭位置には、最上位階層のデータテーブル「ｒｏｏｔ」が格納されている。また、検索データファイル１３の次の位置には、同一系統のデータテーブル「北海道」−データテーブル「札幌市」が、当該階層順に格納されている。また、次の位置には、同一系統のデータテーブル「北海道」−データテーブル「旭川市」が、当該階層順に格納されるが、データテーブル「北海道」は既に格納されているためにデータテーブル「旭川市」のみが格納されている。また、次の位置には、同一系統のデータテーブル「青森県」−データテーブル「青森市」が、当該階層順に格納されている。また、次の位置には、同一系統のデータテーブル「青森県」−データテーブル「むつ市」が、当該階層順に格納されるが、データテーブル「青森県」は既に格納されているためにデータテーブル「むつ市」のみが格納される。

なお、図２、３には検索データの一部のみを例示しており、実際の検索データには、例えば、データテーブル「秋田県」等のその他の都道府県に対応するデータテーブルや、これら都道府県の市区町村に対応するデータテーブルのデータテーブルが格納される。また、各データテーブルの子レコードにも、実際にはさらに多くの子レコードが含まれ、例えば、データテーブル「むつ市」には、子レコード「旭町」、子レコード「大曲」、子レコード「大湊」以外にも、「むつ市」に属する地理的階層に対応する子レコードが含まれる。このように構成される検索データは、地図作成業者等によって構成されデータ記録部８に格納される。

（処理）
次に、このように構成されるナビゲーション装置６によって実行されるデータ処理について説明する。この処理は、参照対象となるデータレコードを特定するための特定処理と、データレコードを更新するための更新処理に大別される。以下の処理の説明において、制御主体を特記しない処理については、ナビゲーション装置６の制御部７にて実行されるものとし、情報の取得元や取得経路を特記しない場合については、公知のタイミング及び公知の方法にて、ナビゲーション装置６のデータ記録部８に予め格納されており、あるいは、ナビゲーション装置６のタッチパネル３を介してユーザ等によって入力されるものとする。また、ステップを「Ｓ」と略記する。

（処理−特定処理）
最初に、特定処理について説明する。図４は、特定処理のフローチャートである。この特定処理は、ナビゲーションシステム１のユーザによって地名検索の操作が所定方法で行われた場合に起動される。以下の説明では、ユーザが検索したい地名が「青森県むつ市」である場合を、具体例に交えて説明する。

この処理において、特定部９は、現在参照しているデータテーブル（以下、カレントデータテーブル）の親レコードを取得する（ＳＡ１）。最初のカレントデータテーブルは、検索データファイル１３に格納されている最上位階層のデータテーブルとする。例えば、カレントデータテーブル「ｒｏｏｔ」の親レコード「ｒｏｏｔ」を取得する。

次いで、特定部９は、カレントデータテーブルの全ての子レコードを取得し、当該子レコードに基づいて選択用画面を生成してディスプレイ４に表示する（ＳＡ２）。例えば、カレントデータテーブル「ｒｏｏｔ」の子レコード「北海道」と子レコード「青森県」を取得して、これら子レコードから検索用テキストデータである「北海道」と「青森県」をそれぞれ取得し、当該取得した検索用テキストデータ「北海道」と「青森県」をリスト形式で含んだ選択用画面を生成してディスプレイ４に表示する。また、選択用画面には、地名の検索の終了を指示するためのボタンを表示する。このようなボタンとしては、例えば、地名の検索を終了すると共に、その時点で最終的に検索されている地名に対する操作を行うための操作ボタン（例えば、検索された地名に対応する地図データを地図情報ＤＢ１１から取得してディスプレイ４に表示するための表示ボタン）を表示する。

次いで、特定部９は、ユーザにより検索したい地名が選択されたか否かを判定する（ＳＡ３）。そして、検索したい地名が選択された場合には（ＳＡ３、Ｙｅｓ）、ＳＡ４に移行する。例えば、検索したい地名が「青森県むつ市」である場合、ユーザは、ディスプレイ４に表示された検索用テキストデータ「青森県」を、タッチパネル３を介して選択する。この場合には、検索したい地名が選択されたと判定される。

検索したい地名が選択されたと判定した場合（ＳＡ３、Ｙｅｓ）、特定部９は、ユーザによって選択された検索用テキストデータに対応する子レコードから、当該子レコードの識別コードを取得する（ＳＡ４）。例えば、検索用テキストデータ「青森県」が選択された場合には、当該検索用テキストデータ「青森県」に対応する子レコード「青森県」から、当該子レコード「青森県」の識別コードを取得する。

次いで、特定部９は、カレントデータテーブルのデータサイズをオフセット値に加算する（ＳＡ５）。オフセット値とは、ユーザが検索したい地名に対応するデータテーブルの位置を特定するための情報であり、具体的には、検索データファイル１３に格納されている最上位階層のデータテーブルの先頭位置を基準とする、ユーザが検索したい地名に対応するデータテーブルの先頭位置までの、相対的な位置である。なお、オフセット値の初期値は０とする。また、最上位階層のデータテーブルのデータサイズは、最上位階層のデータテーブルの親レコードから取得する。例えば、データテーブル「ｒｏｏｔ」の親レコード「ｒｏｏｔ」に含まれているデータサイズ＝２５０Ｂｙｔｅをオフセット値に加算し、オフセット値＝０＋２５０＝２５０Ｂｙｔｅとする。

次いで、特定部９は、目的の子レコード（つまり、ＳＡ３でユーザによって選択された検索用テキストデータに対応する子レコード）に辿り付くまで、ＳＡ６〜ＳＡ１０のループ処理を繰り返す。具体的には、特定部９は、カレントデータテーブルの子レコードの中から、収納順序の上位順に一つの子レコードを取得し、当該取得した子レコードをカレント子レコードに設定する（ＳＡ７）。例えば、最初に、カレントデータテーブル「ｒｏｏｔ」の子レコード「北海道」をカレント子レコードに設定する。

そして、当該設定したカレント子レコードが目的の子レコードであるか否かを判定する（ＳＡ８）。この判定は、ＳＡ４で取得した識別コードが、ＳＡ７で設定したカレント子レコードに含まれる識別コードに一致するか否かに基づいて行われる。例えば、ＳＡ４で取得した子レコード「青森県」の識別コードが、ＳＡ７で設定したカレント子レコード「北海道」の識別コードに一致するか否かを判定する。この例の場合には、一致しないことから、カレント子レコードが目的の子レコードではないと判定する。

カレント子レコードが目的の子レコードではないと判定した場合（ＳＡ８、Ｎｏ）、特定部９は、カレント子レコードの配下サイズをオフセット値に加算する（ＳＡ９）。例えば、ＳＡ４で取得した子レコード「青森県」の識別コードが、ＳＡ７で設定したカレント子レコード「北海道」の識別コードに一致しないために、目的の子レコードではないと判定した場合には、カレント子レコード「北海道」の配下サイズ＝３０７００Ｂｙｔｅを加算して、オフセット値＝２５０＋３０７００＝３０９５０Ｂｙｔｅとする。

一方、カレント子レコードが目的の子レコードであると判定した場合（ＳＡ８、Ｙｅｓ）、特定部９は、ＳＡ６〜ＳＡ１０のループ処理を抜けて、その時点におけるオフセット値の位置へ、カレントデータテーブルの位置を移動する（ＳＡ１１）。例えば、上述のように、カレント子レコード「北海道」が目的の子レコードではないと判定した場合、次のループ処理において、ＳＡ４で取得した子レコード「青森県」の識別コードが、カレントデータテーブル「ｒｏｏｔ」の子レコードの中で、収納順序が二番目であるカレント子レコード「青森県」の識別コードに一致するために、目的の子レコードであると判定した場合には、検索データファイル１３に格納されている最上位階層のデータテーブルの先頭位置から、その時点におけるオフセット値＝３０９５０Ｂｙｔｅの位置を先頭位置とするデータテーブル「青森県」を、カレントデータテーブルとする。

次いで、ＳＡ１に戻り、特定部９は、カレントデータテーブルの親レコードを取得する（ＳＡ１）。例えば、カレントデータテーブル「青森県」の親レコード「青森県」を取得する。

また、特定部９は、カレントデータテーブルの全ての子レコードを取得し、当該子レコードに基づいて選択用画面を生成してディスプレイ４に表示する（ＳＡ２）。例えば、カレントデータテーブル「青森県」の子レコード「青森市」と子レコード「むつ市」を取得して、これら子レコードから検索用テキストデータである「青森市」と「むつ市」をそれぞれ取得し、当該取得した検索用テキストデータ「青森市」と「むつ市」をリスト形式で含んだ選択用画面を生成してディスプレイ４に表示する。また、選択用画面には、地名の検索の終了を指示するためのボタンを表示する。

次いで、特定部９は、ユーザにより、検索したい地名が選択されたか否かを判定する（ＳＡ３）。そして、検索したい地名が選択された場合には（ＳＡ３、Ｙｅｓ）、ＳＡ４に移行する。例えば、検索したい地名が「青森県むつ市」である場合、ユーザは、ディスプレイ４に表示された検索用テキストデータ「むつ市」を、タッチパネル３を介して選択する。この場合には、検索したい地名が選択されたと判定される。

検索したい地名が選択されたと判定した場合（ＳＡ３、Ｙｅｓ）、特定部９は、ユーザによって選択された検索用テキストデータに対応する子レコードから、当該子レコードの識別コードを取得する（ＳＡ４）。例えば、検索用テキストデータ「むつ市」が選択された場合には、当該検索用テキストデータ「むつ市」に対応する子レコード「むつ市」から、当該子レコード「むつ市」の識別コードを取得する。

次いで、特定部９は、カレントデータテーブルのデータサイズをオフセット値に加算する（ＳＡ５）。２回目及びそれ以降のＳＡ５の処理においては、データサイズは、その時点のカレント子レコードの次段サイズから取得する。例えば、カレントデータテーブル「青森県」のデータサイズ＝２０００Ｂｙｔｅを、その時点のカレント子レコード「青森県」から取得してオフセット値に加算し、オフセット値＝３０９５０＋２０００＝３２９５０Ｂｙｔｅとする。

その後、特定部９は、目的の子レコード（つまり、ＳＡ３でユーザによって選択された検索用テキストデータに対応する子レコード）に辿り付くまで、ＳＡ６〜ＳＡ１０のループ処理を繰り返す。具体的には、特定部９は、カレントデータテーブルの子レコードの中から、収納順序の上位順に一つの子レコードを取得し、当該取得した子レコードをカレント子レコードに設定する（ＳＡ７）。例えば、最初に、カレントデータテーブル「青森県」の子レコード「青森市」を取得する。

そして、当該取得したカレント子レコードが目的の子レコードであるか否かを判定する（ＳＡ８）。例えば、ＳＡ４で取得した子レコード「むつ市」の識別コードが、ＳＡ７で設定したカレント子レコード「青森市」の識別コードに一致するか否かを判定する。この例の場合には、一致しないことから、カレント子レコードが目的の子レコードではないと判定する。

カレント子レコードが目的の子レコードではないと判定した場合（ＳＡ８、Ｎｏ）、特定部９は、カレント子レコードの配下サイズをオフセット値に加算する（ＳＡ９）。例えば、ＳＡ４で取得した子レコード「むつ市」の識別コードが、ＳＡ７で設定したカレント子レコード「青森市」の識別コードに一致しないために、目的の子レコードではないと判定した場合には、カレント子レコード「青森市」の配下サイズ＝１５００Ｂｙｔｅを加算して、オフセット値＝３２９５０＋１５００＝３４４５０Ｂｙｔｅとする。

一方、カレント子レコードが目的の子レコードであると判定した場合（ＳＡ８、Ｙｅｓ）、特定部９は、ＳＡ６〜ＳＡ１０のループ処理を抜けて、その時点におけるオフセット値の位置へ、カレントデータテーブルの位置を移動する（ＳＡ１１）。例えば、上述のように、カレント子レコード「青森市」が目的の子レコードではないと判定した場合、次のループ処理において、ＳＡ４で取得した子レコード「むつ市」の識別コードが、カレントデータテーブル「ｒｏｏｔ」の子レコードの中で、収納順序が二番目であるカレント子レコード「むつ市」の識別コードに一致するために、目的の子レコードであると判定した場合には、検索データファイル１３に格納されている最上位階層のデータテーブルの先頭位置から、その時点におけるオフセット値＝３４４５０Ｂｙｔｅの位置を先頭位置とするデータテーブル「むつ市」を、カレントデータテーブルとする。

次いで、特定部９は、カレントデータテーブルの親レコードを取得する（ＳＡ１）。例えば、カレントデータテーブル「むつ市」の親レコード「むつ市」を取得する。

次いで、特定部９は、カレントデータテーブルの全ての子レコードを取得し、当該子レコードに基づいて選択用画面を生成してディスプレイ４に表示する（ＳＡ２）。例えば、カレントデータテーブル「むつ市」の子レコード「旭町」、子レコード「大曲」、及び子レコード「大湊」等を取得して、これら子レコードから検索用テキストデータである「旭町」、「大曲」、及び「大湊」等をそれぞれ取得し、当該取得した検索用テキストデータ「旭町」、「大曲」、及び「大湊」等をリスト形式で含んだ選択用画面を生成してディスプレイ４に表示する。また、選択用画面には、地名の検索の終了を指示するためのボタンを表示する。

次いで、特定部９は、ユーザにより、検索したい地名が選択されたかを判定する（ＳＡ３）。例えば、検索したい地名が「青森県むつ市」である場合、ユーザは、ディスプレイ４に、「むつ市」に属する「旭町」、「大曲」、及び「大湊」等が既に表示されていることから、それ以上の検索を行う必要はないと判断し、地名の検索の終了を指示するためのボタンを選択する。この場合には、検索したい地名が選択されなかった（検索の終了が指示された）と判定される。このように選択が行われると、特定処理を終了する。

このように特定処理が終了した時点において設定されているオフセット値により、検索データの最上位階層のデータテーブルの先頭位置から参照対象のデータテーブルの先頭位置までの相対的な位置が特定されるので、制御部７は、この参照対象のデータテーブルの親レコードや子レコードを取得して、所定の処理に利用することが可能になる。例えば、最上位階層のデータテーブル「ｒｏｏｔ」の先頭位置から、オフセット値＝３４４５０Ｂｙｔｅの位置のデータテーブルを取得することで、データテーブル「むつ市」を取得することができる。このため、検索データの検索を効率よく行うことが可能になる。

（処理−更新処理）
次に、更新処理について説明する。図５は、更新処理のフローチャートである。この更新処理は、更新情報（更新対象となるデータレコードの内容、更新の種類（追加、書き換え、又は削除）、及び更新対象となるデータレコードの位置を含む情報）が指定された場合に起動される。例えば、ナビゲーションシステム１のユーザが公知の通信手段を介して検索データの更新操作をタッチパネル３を介して行った場合、図示しないセンター装置から更新情報が送信され、この更新情報に基づいて更新を行うために更新処理が起動される。以下の説明では、データテーブル「むつ市」における子データレコード「大曲」の次の位置に、子データレコード「大湊」を追加する場合を、具体例に交えて説明する。

最初に、更新部１０は、更新情報に基づいてデータレコードを更新する（ＳＢ１）。すなわち、更新対象となるデータレコードを、更新対象となるデータレコードの位置において、更新の種類に応じて追加、書き換え、又は削除する。

次いで、更新部１０は、追加や書き換えが行われたデータレコードに対して、配下のデータテーブルが存在する場合には、配下のデータテーブルを参照して、次段サイズと配下サイズを算定して当該更新対象となるデータレコードに記録する（ＳＢ２）。

次いで、更新部１０は、当該更新されたデータレコードが属するデータテーブルのデータサイズを更新する（ＳＢ３）。つまり、データレコードが追加された場合には、当該データレコードのサイズを当該データテーブルのデータサイズに加算し、データレコードが書き換えられた場合には、当該データレコードの書き換えによるサイズの増減に応じて、当該データテーブルのデータサイズを増減させ、データレコードが削除された場合には、当該データレコードのサイズを当該データテーブルのサイズから減算する（以下、次段サイズと配下サイズの更新も同様）。例えば、子データレコード「大湊」のサイズ＝３００Ｂｙｔｅであり、データテーブル「むつ市」のデータサイズ＝１０００Ｂｙｔｅである場合、当該データテーブル「むつ市」のデータサイズ＝１０００＋３００＝１３００Ｂｙｔｅに更新する。

次いで、更新部１０は、当該更新されたデータレコードが属するデータテーブルと同一系統に属するデータテーブルであって、当該データテーブルより上位階層の全てのデータテーブルの子データレコードの次段サイズと配下サイズを更新する（ＳＢ４）。例えば、子データレコード「大湊」のサイズ＝３００Ｂｙｔｅであり、データテーブル「青森県」の子データレコード「むつ市」の次段サイズと配下サイズ＝１０００Ｂｙｔｅである場合、子データレコード「むつ市」の次段サイズ＝１０００＋３００＝１３００Ｂｙｔｅに更新し、子データレコード「むつ市」の配下サイズ＝１０００＋３００＝１３００Ｂｙｔｅに更新する。また、データテーブル「ｒｏｏｔ」の子データレコード「青森県」の次段サイズ＝２０００Ｂｙｔｅで配下サイズ＝４５００Ｂｙｔｅである場合、子データレコード「青森県」の次段サイズ＝２０００＋３００＝２３００Ｂｙｔｅに更新し、子データレコード「青森県」の配下サイズ＝４５００＋３００＝４８００Ｂｙｔｅに更新する。これにて更新処理を終了する。

この更新処理の終了後、必要に応じて、上述した特定処理を行うことで、更新されたデータテーブルのデータサイズ、次段サイズ、及び配下サイズに基づいて、参照対象のデータテーブルの位置を正しく特定することが可能になる。

（効果）
このように実施の形態１によれば、同一のファイルの内部に格納されたデータであって、少なくとも一つのデータレコードを含む複数のデータテーブルを階層構造化して構成されたデータを用いて、ファイルにおける最上位階層のデータテーブルの先頭位置から特定対象のデータテーブルの先頭位置までの相対的な位置を特定することができるので、データを構成するファイルの数を一つに抑制することができると共に、データの検索を容易に行うことが可能になる。

また、複数のデータレコードの一部のデータレコードが更新された場合、上位階層の全てのデータテーブルの次段サイズと配下サイズとを更新することで、データの更新が完了するので、データの更新を容易に行うことが可能になる。

〔実施の形態２〕
次に、実施の形態２について説明する。この実施の形態２は、データ処理の対象になるデータとは別に、データ処理の対象になるデータの位置を特定するためのインデックスデータを設け、このインデックスデータに基づいて、データ処理の対象になるデータの位置を特定する形態である。ただし、実施の形態２の構成と処理の中で、実施の形態１の構成と処理と同じ部分については、必要に応じて実施の形態１で使用したものと同じ符号を付し、その説明を省略する。

（構成）
まず、実施の形態２に係るデータ処理装置としてのナビゲーション装置を用いたナビゲーションシステムの構成を説明する。図６は、実施の形態２に係るナビゲーションシステムを例示するブロック図である。図６に示すように、ナビゲーションシステム２０は、現在位置取得部２、タッチパネル３、ディスプレイ４、スピーカ５、及びデータ処理装置としてのナビゲーション装置２１を備えている。ナビゲーション装置２１は、制御部２２とデータ記録部２５を備えている。

（構成−データ処理装置−制御部）
制御部２２は、ナビゲーション装置２１を制御する制御手段である。この制御部２２は、機能概念的に、特定部２３と更新部２４を備える。特定部２３は、後述する検索情報ＤＢ２６にて格納された複数のデータテーブルの中から、参照対象のデータテーブルの先頭位置を特定する特定手段である。更新部２４は、複数の実データレコードの一部の実データレコードが更新された場合、当該更新された実データレコードに対応するインデックステーブルの実サイズと、当該インデックステーブルと同一系統に属するインデックステーブルであって、当該インデックステーブルより上位階層の全てのインデックステーブルの実サイズとを、当該更新された実データレコードのデータサイズに基づいて更新する更新手段である。これらの制御部２２の各部によって実行される処理の詳細や、実データレコード、インデックステーブル、実サイズの詳細については、後述する。

（構成−データ処理装置−データ記録部）
データ記録部２５は、地図情報ＤＢ１１と検索情報ＤＢ２６を格納する。検索情報ＤＢ２６は、検索データを格納するデータ格納手段である。実施の形態２における「検索データ」とは、施設を検索するためのデータであって、実データとインデックスデータを含んで構成されている。より具体的には、検索情報ＤＢ２６において、実データは実データファイル２７に格納され、インデックスデータはインデックスデータファイル２８に格納されている。

「実データ」とは、データ処理の対象になるデータであり、例えば、施設の名称を含んで構成されている。この実データは、文字データを含む複数の実データレコードを当該文字データにおける文字位置及び文字語順に基づいた整列順序で整列して構成されている。図７は、実データの階層構造を示す図である。この図７に示すように、実データは、第１階層の実データテーブルを含んで構成されている。各第１階層の実データテーブルは、実データに含まれる施設の名称であってひらがなで表記された名称における第１文字目に対応する実データテーブルであり、これら複数の第１階層の実データテーブルは五十音順に整列されている。例えば、実データは、第１階層の実データテーブルとして、実データテーブル「あ」、実データテーブル「い」、及び実データテーブル「う」を含んでおり、これらの第１階層の実データテーブルは、「あ」「い」「う」の五十音順に整列されている。

また、各第１階層の実データテーブルは、第２階層の実データテーブルを含んで構成されている。各第２階層の実データテーブルは、実データに含まれる施設の名称であってひらがなで表記された名称における第２文字目に対応する実データテーブルであり、これら複数の第２階層の実データテーブルは、五十音順に整列されている。例えば、実データは、第１階層の実データテーブル「い」の第２階層の実データテーブルとして、実データテーブル「あ」、実データテーブル「い」、実データテーブル「う」、実データテーブル「え」、及び実データテーブル「お」を含んでおり、これらの第２階層の実データテーブルは、「あ」「い」「う」「え」「お」の五十音順に整列されている。

また、各第２階層の実データテーブルは、実データレコードを含んで構成されている。各実データレコードは、実データに含まれる施設の名称であってひらがなで表記された名称に対応する実データテーブルであり、これら複数の実データレコードは、五十音順に整列されている。例えば、実データは、第１階層の実データテーブル「い」の第２階層の実データテーブル「あ」の実データレコードとして、実データレコード「いあ」及び実データレコード「いあつ」を含んでおり、これらの実データレコードは、「いあ」、「いあつ」の五十音順に整列されている。

このように階層構造化された複数の実データテーブルは、インデックスデータファイル２８とは異なる一つの実データファイル２７に格納されている。図８は、実データファイル２７における実データの格納順序を示す図である。この図８に示すように、実データファイル２７には、その先頭位置に第１階層の実データテーブル「あ」が格納されている。より具体的には、この第１階層の実データテーブル「あ」の下位の第２階層の実データテーブル「あ」に含まれる実データレコード「あ」と実データレコード「ああ」が順次格納され、次いで、第１階層の実データテーブル「あ」の下位の第２階層の実データテーブル「い」に含まれる実データレコード「あい」と実データレコード「あいかわ」が順次格納され、以下同様に、第１階層の実データテーブル「あ」の下位の第２階層の実データテーブル「う」に含まれる実データレコード等が格納される。そして、第１階層の実データテーブル「あ」の次の位置に、第２階層の実データテーブル「い」と、第１階層の実データテーブル「う」が、第１階層の実データテーブル「あ」の格納と同じ規則により、順次格納される。

また、図６のインデックスデータファイル２８は、インデックスデータを格納するファイルである。「インデックスデータ」とは、実データの位置を特定するためのデータである。

特に、実施の形態２におけるインデックスデータは、実施の形態１の検索データと同様の構造で構成されている。すなわち、インデックスデータは、少なくとも一つのデータレコードを含む複数のデータテーブルを階層構造化して構成されている。図９は、インデックスデータの階層構造を示す図である。この図９に示すように、インデックスデータは、一つの最上位階層（第１階層）のデータテーブルＤＴ１０と、このデータテーブルＤＴ１０に対して一つだけ下位階層（第２階層）に位置付けられたデータテーブルＤＴ１１、ＤＴ１２とを含んでいる。これらデータテーブルＤＴ１０〜ＤＴ１２は、インデックスデータが示す実データの階層に対応した階層で構造化されたものであって、インデックスデータが示す実データの階層に対応したデータを含むものである。すなわち、第１階層のデータテーブルＤＴ１０は、施設の名称のひらがな表記の第１文字目に対応した階層のデータであり、第２階層のデータテーブルＤＴ１１、ＤＴ１２は、施設のひらがな表記の第２文字目に対応した階層のデータである（以下、データテーブルの符号ＤＴ１０〜ＤＴ１２を省略する）。

各データテーブルのデータレコードは、具体的には、一つの親レコードと、一つ以上の子レコードとを含んで構成されている。例えば、第１階層のデータテーブルは、親レコード「ｒｏｏｔ」と、子レコード「あ」、子レコード「い」、及び子レコード「う」を含む。また、第２階層のデータテーブル「い」は、親レコード「い」と、子レコード「あ」、子レコード「い」、子レコード「う」、子レコード「え」、及び子レコード「お」を含む。なお、実際には、第１階層のデータテーブルは、第２階層のデータテーブル「あ」を含んでいるが、以下の説明では、第２階層のデータテーブル「あ」を省略する。

各データテーブルの親レコードは、当該親レコードが属するデータテーブルの参照用データを含むレコードである。「参照用データ」とは、各データテーブルや各データレコードを参照するために使用されるデータであり、例えば、当該親レコードと同じデータテーブルに含まれる子レコードのレコード数を含んでおり、この子レコードのレコード数を用いて、後述する各処理において子レコードを取得する際における当該子レコードの読み込み終了位置を管理している。

各データテーブルの子レコードは、検索用テキストデータ、識別コード、次段サイズ、配下サイズ、及び実サイズを含む。「検索用テキストデータ」とは、施設を検索するためにディスプレイ４等に表示されるテキストデータであり、例えば、データテーブル「ｒｏｏｔ」の子レコード「あ」は、検索用テキストデータ「あ」を含む。「識別コード」、「次段サイズ」、及び「配下サイズ」は、実施の形態１と同じである。「実サイズ」とは、各子レコードに対応する実データ（各子レコードによって位置が特定される実データ）のサイズである。すなわち、第１階層のデータテーブルの各子レコードは、図７の実データの第１階層の実データテーブルに対応しており、第２階層のデータテーブルの各子レコードは、図７の実データの第２階層の実データテーブルに対応している。具体的には、第１階層のデータテーブル「ｒｏｏｔ」の各子レコード「あ」は、実データの第１階層の実データテーブル「あ」、第１階層のデータテーブル「ｒｏｏｔ」の各子レコード「い」は、実データの第１階層の実データテーブル「い」、第１階層のデータテーブル「ｒｏｏｔ」の各子レコード「う」は、実データの第１階層の実データテーブル「う」に対応している。また、第２階層のデータテーブル「ｒｏｏｔ」の各子レコード「あ」は、実データの第１階層の実データテーブル「あ」、第１階層のデータテーブル「い」の各子レコード「あ」〜「お」は、実データの第１階層の実データテーブル「い」の第２階層の実データテーブル「あ」〜「お」に対応している。そして、例えば、第１階層のデータテーブル「ｒｏｏｔ」の各子レコード「あ」は、実サイズとして、実データの第１階層の実データテーブル「あ」のデータサイズである１００ＫＢｙｔｅを含んでいる。

このように階層構造化されたインデックスデータは、実データの実データファイル２７とは異なる一つのインデックスデータファイル２８に格納されている。図１０は、インデックスデータファイル２８におけるインデックスデータの格納順序を示す図である。この図１０に示すように、インデックスデータファイル２８には、複数のデータテーブルが、最上位階層のデータテーブルを先頭として、同一系統のデータテーブルを上位階層から下位階層に至る順に格納されている。より具体的には、検索データファイルの先頭位置には、最上位階層のデータテーブル「ｒｏｏｔ」が格納されている。また、検索データファイルの次の位置には、同一系統の第２階層のデータテーブル「い」が格納されている。また、次の位置には、同一系統の第２階層のデータテーブル「う」が格納されている。

なお、図９、１０には検索データの一部のみを例示しており、実際の検索データには、例えば、第１階層のデータテーブルとして、「え」及びそれ以降の各ひらがなに対応する第１階層のデータテーブルや、これら第１階層のデータテーブルに含まれる第２階層のデータテーブルとして、「か」及びそれ以降の各ひらがなに対応する第２階層のデータテーブルが含まれる。このように構成される検索データは、地図作成業者等によって構成されデータ記録部２５に格納される。

（処理）
次に、このように構成されるナビゲーション装置２１によって実行されるデータ処理について説明する。この処理は、参照対象となるデータレコードを特定するための特定処理と、データレコードを更新するための更新処理に大別される。

（処理−特定処理）
最初に、特定処理について説明する。図１１、１２は、特定処理のフローチャートである。以下の説明では、ユーザが検索したい施設の名称のひらがな表記が「いう」で始まる名称である場合を、具体例に交えて説明する。

この処理において、特定部２３は、現在参照しているデータテーブル（以下、カレントデータテーブル）の親レコードを取得する（ＳＣ１）。最初のカレントデータテーブルは、検索データファイルに格納されている最上位階層のデータテーブルとする。例えば、カレントデータテーブル「ｒｏｏｔ」の親レコード「あ」を取得する。

次いで、特定部２３は、カレントデータテーブルの全ての子レコードを取得し、当該子レコードに基づいて選択用画面を生成してディスプレイ４に表示する（ＳＣ２）。例えば、カレントデータテーブル「ｒｏｏｔ」の子レコード「あ」と、子レコード「い」、及び子レコード「う」を取得して、これら子レコードから検索用テキストデータである「あ」、「い」、及び「う」をそれぞれ取得し、当該取得した検索用テキストデータ「あ」、「い」、及び「う」をリスト形式で含んだ選択用画面を生成してディスプレイ４に表示する。

次いで、特定部２３は、ユーザにより、検索したい施設の名称のひらがな表記のＮ文字目が選択されたかを判定する（ＳＣ３）。ここで、「Ｎ」は、ＳＣ３が実行された回数に対応する正の整数であり、ＳＣ３が最初に実行された場合にはＮ＝１、ＳＣ３が２回目に実行された場合にはＮ＝２となる。そして、検索したい施設の名称のひらがな表記のＮ文字目が選択された場合には（ＳＣ３、Ｙｅｓ）、ＳＣ４に移行する。例えば、検索したい施設の名称がひらがな表記が「いう」で始まる名称である場合、ユーザは、ディスプレイ４に表示された検索用テキストデータ「い」を、タッチパネル３を介して選択する。この場合には、検索したい施設の名称のひらがな表記のＮ文字目が選択されたと判定される。

検索したい施設の名称のひらがな表記のＮ文字目が選択されたと判定した場合（ＳＣ３、Ｙｅｓ）、特定部２３は、ユーザによって選択された検索用テキストデータに対応する子レコードから、当該子レコードの識別コードを取得する（ＳＣ４）。例えば、検索用テキストデータ「い」が選択された場合には、当該検索用テキストデータ「い」に対応する子レコード「い」から、当該子レコード「い」の識別コードを取得する。

次いで、特定部２３は、カレントデータテーブルのデータサイズをインデックス用オフセット値に加算する（ＳＣ５）。インデックス用オフセット値とは、ユーザが検索したい施設の名称に対応するデータテーブルの位置を特定するための情報であり、具体的には、インデックスデータファイル２８に格納されている最上位階層のデータテーブルの先頭位置を基準とする、ユーザが検索したい施設の名称に対応するデータテーブルの先頭位置までの、相対的な位置である。なお、インデックス用オフセット値の初期値は０とする。また、最上位階層のデータテーブルのデータサイズは、最上位階層のデータテーブルの親レコードから取得する。例えば、データテーブル「ｒｏｏｔ」の親レコード「ｒｏｏｔ」に含まれているデータサイズ＝６００Ｂｙｔｅをオフセット値に加算し、オフセット値＝０＋６００＝６００Ｂｙｔｅとする。

次いで、特定部２３は、目的の子レコード（つまり、ＳＣ３でユーザによって選択された検索用テキストデータに対応する子レコード）に辿り付くまで、ＳＣ６〜ＳＣ１１を繰り返す。具体的には、特定部２３は、カレントデータテーブルの子レコードの中から、収納順序の上位順に一つの子レコードを取得し、当該取得した子レコードをカレント子レコードに設定する（ＳＣ７）。例えば、最初に、カレントデータテーブル「ｒｏｏｔ」の子レコード「あ」をカレント子レコードに設定する。

そして、当該設定したカレント子レコードが目的の子レコードであるか否かを判定する（ＳＣ８）。この判定は、ＳＣ４で取得した識別コードが、ＳＣ７で取得したカレント子レコードに含まれる識別コードに一致するか否かに基づいて行われる。例えば、ＳＣ４で取得した子レコード「い」の識別コードが、ＳＣ７で設定したカレント子レコード「あ」の識別コードに一致するか否かを判定する。この例の場合には、一致しないことから、カレント子レコードが目的の子レコードではないと判定する。

カレント子レコードが目的の子レコードではないと判定した場合（ＳＣ８、Ｎｏ）、特定部２３は、カレント子レコードの配下サイズをインデックス用オフセット値に加算する（ＳＣ９）。例えば、ＳＣ４で取得した子レコード「い」の識別コードが、ＳＣ７で設定したカレント子レコード「あ」の識別コードに一致しないために、目的の子レコードではないと判定した場合には、カレント子レコード「あ」の配下サイズ＝０Ｂｙｔｅを加算して、オフセット値＝６００＋０＝６００Ｂｙｔｅとする。

また、特定部２３は、当該カレント子レコードの実サイズを、実データ取得用オフセット値に加算する（ＳＣ１０）。ここで「実データ取得用オフセット値」とは、ユーザが検索したい施設の名称のひらがな表記に対応する実データテーブルの位置を特定するための情報であり、具体的には、実データファイル２７に格納されている最上位階層の実データテーブルの先頭位置を基準とする、ユーザが検索したい施設の名称のひらがな表記に対応する実データテーブルの先頭位置までの、相対的な位置である。この実データ取得用オフセット値の初期値は０とする。例えば、カレント子レコード「あ」の実サイズ＝１００ＫＢｙｔｅを実データ取得用オフセット値に加算し、実データ取得用オフセット値＝０＋１００Ｋ＝１００ＫＢｙｔｅとする。

一方、カレント子レコードが目的の子レコードであると判定した場合（ＳＣ８、Ｙｅｓ）、特定部２３は、ＳＣ６〜ＳＣ１１のループを抜けて、その時点におけるオフセット値の位置へ、カレントデータテーブルの位置を移動する（ＳＣ１２）。例えば、上述のように、カレント子レコード「あ」が目的の子レコードではないと判定した場合、次のループ処理において、ＳＣ４で取得した子レコード「い」の識別コードが、カレントデータテーブル「ｒｏｏｔ」の子レコードの中で、収納順序が二番目であるカレント子レコード「い」の識別コードに一致するために、目的の子レコードであると判定した場合には、検索データファイルに格納されている最上位階層のデータテーブルの先頭位置から、その時点におけるインデックス用オフセット値＝６００Ｂｙｔｅの位置を先頭位置とするデータテーブル「い」を、カレントデータテーブルとする。

次いで、ＳＣ１に戻り、特定部２３は、カレントデータテーブルの親レコードを取得する（ＳＣ１）。例えば、カレントデータテーブル「い」の親レコード「い」を取得する。

また、特定部２３は、カレントデータテーブルの全ての子レコードを取得し、当該子レコードに基づいて選択用画面を生成してディスプレイ４に表示する（ＳＣ２）。例えば、カレントデータテーブル「い」の子レコード「あ」、子レコード「い」、子レコード「う」、子レコード「え」、及び子レコード「お」を取得して、これら子レコードから検索用テキストデータである「あ」、「い」、「う」、「え」、「お」をそれぞれ取得し、当該取得した検索用テキストデータ「あ」、「い」、「う」、「え」、「お」をリスト形式で含んだ選択用画面を生成してディスプレイ４に表示する。

次いで、特定部２３は、ユーザにより、検索したい施設の名称のひらがな表記のＮ文字目が選択されたかを判定する（ＳＣ３）。そして、検索したい施設の名称のひらがな表記のＮ文字目が選択された場合には（ＳＣ３、Ｙｅｓ）、ＳＣ４に移行する。例えば、検索したい施設の名称がひらがな表記が「いう」で始まる名称である場合、ユーザは、ディスプレイ４に表示された検索用テキストデータ「う」を、タッチパネル３を介して選択する。この場合には、検索したい施設の名称のひらがな表記のＮ文字目が選択されたと判定される。

検索したい施設の名称のひらがな表記のＮ文字目が選択されたと判定した場合（ＳＣ３、Ｙｅｓ）、特定部２３は、ユーザによって選択された検索用テキストデータに対応する子レコードから、当該子レコードの識別コードを取得する（ＳＣ４）。例えば、検索用テキストデータ「う」が選択された場合には、当該検索用テキストデータ「う」に対応する子レコード「う」から、当該子レコード「う」の識別コードを取得する。

次いで、特定部２３は、カレントデータテーブルのデータサイズをインデックス用オフセット値に加算する（ＳＣ５）。２回目及びそれ以降のＳＣ５の処理においては、データサイズは、その時点のカレント子レコードの次段サイズから取得する。例えば、カレントデータテーブル「い」のデータサイズ＝６５０Ｂｙｔｅを、その時点のカレント子レコード「い」から取得してインデックス用オフセット値に加算し、インデックス用オフセット値＝６００＋６５０＝１２５０Ｂｙｔｅとする。

その後、特定部２３は、目的の子レコード（つまり、ＳＣ３でユーザによって選択された検索用テキストデータに対応する子レコード）に辿り付くまで、ＳＣ６〜ＳＣ１１のループ処理を繰り返す。具体的には、特定部２３は、カレントデータテーブルの子レコードの中から、収納順序の上位順に一つの子レコードを取得し、当該取得した子レコードをカレント子レコードに設定する（ＳＣ７）。例えば、最初に、カレントデータテーブル「い」の子レコード「あ」を取得する。

そして、当該取得したカレント子レコードが目的の子レコードであるか否かを判定する（ＳＣ８）。例えば、ＳＣ４で取得した子レコード「う」の識別コードが、ＳＣ７で設定したカレント子レコード「い」の識別コードに一致するか否かを判定する。この例の場合には、一致しないことから、カレント子レコードが目的の子レコードではないと判定する。

カレント子レコードが目的の子レコードではないと判定した場合（ＳＣ８、Ｎｏ）、特定部２３は、カレント子レコードの配下サイズをインデックス用オフセット値に加算する（ＳＣ９）。例えば、ＳＣ４で取得した子レコード「う」の識別コードが、ＳＣ７で設定したカレント子レコード「い」の識別コードに一致しないために、目的の子レコードではないと判定した場合には、カレント子レコード「い」の配下サイズ＝０Ｂｙｔｅを加算して、オフセット値＝１２５０＋０＝１２５０Ｂｙｔｅとする。

また、特定部２３は、当該カレント子レコードの実サイズを、実データ取得用オフセット値に加算する（ＳＣ１０）。例えば、カレント子レコード「あ」の実サイズ＝２０ＫＢｙｔｅを実データ取得用オフセット値に加算し、実データ取得用のオフセット値＝１００＋２０Ｋ＝１００ＫＢｙｔｅとする。

一方、カレント子レコードが目的の子レコードであると判定した場合（ＳＣ８、Ｙｅｓ）、特定部２３は、ＳＣ６〜ＳＣ１１のループ処理を抜けて、その時点におけるインデックス用オフセット値の位置へ、カレントデータテーブルの位置を移動する（ＳＣ１２）。例えば、上述のように、カレント子レコード「い」が目的の子レコードではないと判定した場合、次のループ処理において、ＳＣ４で取得した子レコード「う」の識別コードが、ＳＣ７で設定したカレント子レコード「う」の識別コードに一致するために、目的の子レコードであると判定した場合には、検索データファイルに格納されている最上位階層のデータテーブルの先頭位置から、その時点におけるインデックス用オフセット値＝１２５０Ｂｙｔｅの位置を先頭位置とするデータテーブル「う」を、カレントデータテーブルとする。

次いで、特定部２３は、カレントデータテーブルの親レコードを取得する（ＳＣ１）。例えば、カレントデータテーブル「う」の親レコード「う」を取得する。

次いで、特定部２３は、カレントデータテーブルの全ての子レコードを取得し、当該子レコードに基づいて選択用画面を生成してディスプレイ４に表示する（ＳＣ２）。例えば、カレントデータテーブル「う」の子レコードを取得して、これら子レコードから検索用テキストデータをそれぞれ取得し、当該取得した検索用テキストデータをリスト形式で含んだ選択用画面を生成してディスプレイ４に表示する。ここで、カレントデータテーブル「う」の子レコードは存在しないために、特定部２３は、施設の検索が終了したものと判定する（ＳＣ３、Ｎｏ）。

そして、この時点において設定されている実データ取得用オフセット値に基づいて、参照対象のデータテーブルの位置を決定する（ＳＣ１３）。すなわち、この時点において設定されている実データ取得用オフセット値により、例えば、実データの最初のデータテーブルの先頭位置から参照対象のデータテーブルの先頭位置までの相対的な位置が特定されるので、制御部２２は、この参照対象のデータテーブルの親レコードや子レコードを取得して、所定の処理に利用することが可能になる。例えば、実データの最初のデータテーブル「あ」の先頭位置から、実データ取得用オフセット値＝１５０ＫＢｙｔｅの位置のデータテーブルを取得することで、実データテーブル「いう」を取得することができ、このデータテーブル「いう」の親レコードや子レコードに基づいて「いう」にて始まる名称の施設をディスプレイ４に表示等することができる。これにて特定処理を終了する。

（処理−更新処理）
次に、更新処理について説明する。図１３は、更新処理のフローチャートである。以下の説明では、実データテーブル「い」−実データテーブル「い」における子データレコード「いいかわ」の次の位置に子データレコード「いう」を追加する場合を、具体例に交えて説明する。

最初に、更新部２４は、更新情報に基づいて実データレコードを更新する（ＳＤ１）。すなわち、更新対象となる実データレコードを、更新対象となる実データレコードの位置において、更新の種類に応じて追加、書き換え、又は削除する。

次いで、更新部２４は、当該更新された実データレコードに対応するインデックスレコードの実サイズを更新する（ＳＤ２）。つまり、実データレコードが追加された場合には、当該実データレコードに対応するインデックスレコードの実サイズに当該更新された実データレコードのデータサイズを加算し、実データレコードが書き換えられた場合には、当該実データレコードの書き換えによるサイズの増減に応じて、当該実データレコードに対応するインデックスレコードの実サイズを増減させ、実データレコードが削除された場合には、当該実データレコードのサイズを当該実データレコードに対応するインデックスレコードの実サイズから減算する。例えば、子データレコード「いう」のサイズ＝１５ＫＢｙｔｅであり、インデックスデータテーブル「う」の子レコード「う」の実サイズ＝１５ＫＢｙｔｅである場合、当該子レコード「う」の実サイズ＝１５Ｋ＋１５Ｋ＝３０ＫＢｙｔｅに更新する。

次いで、更新部２４は、当該更新されたインデックスデータレコードが属するデータテーブルと同一系統に属するデータテーブルであって、当該データテーブルより上位階層の全てのデータテーブルの子データレコードの実サイズを更新する（ＳＤ３）。例えば、子データレコード「いう」のサイズ＝１５ＫＢｙｔｅであり、インデックスデータテーブル「あ」の子レコード「い」の実サイズ＝１０５ＫＢｙｔｅである場合、当該子レコード「い」の実サイズ＝１５Ｋ＋１０５Ｋ＝１２０ＫＢｙｔｅに更新する。これにて更新処理を終了する。この更新処理の終了後、必要に応じて上記特定処理を行うことで、更新されたデータテーブルの実サイズに基づいて、参照対象のデータテーブルの位置を正しく特定することが可能になる。

（効果）
このように実施の形態２によれば、データ格納手段は、データ処理の対象になる実データと、データ処理の対象になる実データの位置を特定するためのインデックスデータとを格納し、実データファイル２７における最初の実データの先頭位置から、参照対象となる実データの先頭位置までの相対的な位置を特定することができるので、データを構成するファイルの数を二つに抑制することができると共に、データの検索を容易に行うことが可能になる。

また、複数の実データレコードの一部の実データレコードが更新された場合、インデックステーブルの実サイズと、上位階層の全てのインデックステーブルの前記実サイズとを更新することで、データの更新が完了するので、データの更新を容易に行うことが可能になる。

〔実施の形態に対する変形例〕
以上、本発明に係る実施の形態について説明したが、本発明の具体的な構成及び手段は、特許請求の範囲に記載した各発明の技術的思想の範囲内において、任意に改変及び改良することができる。以下、このような変形例について説明する。

（解決しようとする課題や発明の効果について）
まず、発明が解決しようとする課題や発明の効果は、上述の内容に限定されるものではなく、発明の実施環境や構成の細部に応じて異なる可能性があり、上述した課題の一部のみを解決したり、上述した効果の一部のみを奏することがある。例えば、データの検索や更新に関する所定の判定を従来より正確にできない場合であっても、データの検索や更新を従来とは異なる技術により達成できている場合には、本願発明の課題が解決されている。

（分散や統合について）
また、上述した各電気的構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散や統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散や統合して構成できる。例えば、データ処理装置の各構成要素を、複数の装置に分散して構成したり、センター装置に組み込んでも良い。

（データの種類や内容について）
上記各実施の形態では、検索データとして、地名や施設名称を検索するデータを例示したが、このデータの種類や内容は任意に変更することができる。また、ナビゲーション装置に関するデータに限定されず、任意の装置における任意の目的のために使用するデータを対象とすることができる。

１、２０ ナビゲーションシステム
２ 現在位置取得部
３ タッチパネル
４ ディスプレイ
５ スピーカ
６、２１ ナビゲーション装置
７、２２ 制御部
８、２５ データ記録部
９、２３ 特定部
１０、２４ 更新部
１１ 地図情報ＤＢ
１２、２６ 検索情報ＤＢ
１３ 検索データファイル
２７ 実データファイル
２８ インデックスデータファイル
ＤＴ１〜ＤＴ７、ＤＴ１０〜ＤＴ１２ データテーブル

Claims (6)

1. 同一のファイルの内部に格納されたデータであって、少なくとも一つのデータレコードを含む複数のデータテーブルを階層構造化して構成されたデータを少なくとも格納するデータ格納手段と、
   前記データ格納手段にて格納された複数のデータテーブルの中から、参照対象のデータテーブルの先頭位置を特定する特定手段とを備え、
   前記データ格納手段は、前記複数のデータテーブルを、最上位階層のデータテーブルを先頭として、同一系統のデータテーブルを上位階層から下位階層に至る順に前記ファイルに格納し、
   前記複数のデータテーブルの各々は、当該データテーブルと同一系統に属するデータテーブルであって、当該データテーブルより一つだけ下位階層のデータテーブルを一意に識別するための識別情報と、当該データテーブルより一つだけ下位階層のデータテーブルのデータサイズである次段サイズと、当該データテーブルより下位階層の全てのデータテーブルのデータサイズの合計値である配下サイズとを含み、
   前記最上位階層のデータテーブルは、当該データテーブルのデータサイズを含み、
   前記特定手段は、特定対象のデータテーブルの識別情報が所定方法で指定された場合に、前記データ格納手段にて格納された前記データテーブルの前記配下サイズを、前記最上位階層のデータテーブルから、前記識別情報に基づいて識別された前記特定対象のデータテーブルより一つ前の格納位置に格納されたデータテーブルに至るまで、前記データ格納手段における前記データテーブルの格納順に加算することで、前記ファイルにおける前記最上位階層のデータテーブルの先頭位置から前記特定対象のデータテーブルの先頭位置までの相対的な位置を特定する、
   データ処理装置。
2. 前記データ格納手段は、データ処理の対象になる実データと、データ処理の対象になる実データの位置を特定するためのインデックスデータとを格納し、
   前記実データは、文字データを含む複数の実データレコードを当該文字データにおける文字位置及び文字語順に基づいた整列順序で整列して構成されると共に、前記データ格納手段において前記ファイルとは異なる実データファイルに格納され、
   前記インデックスデータは、前記データとして構成されると共に、前記文字データの前記整列順序に応じて階層構造化され、
   前記インデックスデータの複数のデータテーブルの各々は、自己に対応する前記実データレコードのサイズである実サイズを含み、
   前記特定手段は、前記最上位階層のデータテーブルの先頭位置から前記特定対象のデータテーブルの先頭位置までの相対的な位置を特定した後、前記データ格納手段にて格納された前記データテーブルの前記実サイズを、前記最上位階層のデータテーブルから、当該特定された相対的な位置に対応する前記データテーブルより一つ前の格納位置に格納されたデータテーブルに至るまで、前記データ格納手段における前記データテーブルの格納順に加算することで、前記実データファイルにおける最初の実データの先頭位置から前記特定対象の実データの先頭位置までの相対的な位置を特定する、
   請求項１に記載のデータ処理装置。
3. 前記複数のデータレコードの一部のデータレコードが更新された場合、当該更新されたデータレコードが属するデータテーブルと同一系統に属するデータテーブルであって、当該データテーブルより上位階層の全てのデータテーブルの前記次段サイズと前記配下サイズとを、当該更新されたデータレコードのデータサイズに基づいて更新する更新手段を備えた、
   請求項１に記載のデータ処理装置。
4. 前記複数の実データレコードの一部の実データレコードが更新された場合、当該更新された実データレコードに対応するインデックステーブルの前記実サイズと、当該インデックステーブルと同一系統に属するインデックステーブルであって、当該インデックステーブルより上位階層の全てのインデックステーブルの前記実サイズとを、当該更新された実データレコードのデータサイズに基づいて更新する更新手段を備えた、
   請求項２に記載のデータ処理装置。
5. 同一のファイルの内部に格納されたデータであって、少なくとも一つのデータレコードを含む複数のデータテーブルを階層構造化して構成されたデータを少なくともデータ格納手段に格納するデータ格納ステップと、
   前記データ格納ステップにて格納された複数のデータテーブルの中から、参照対象のデータテーブルの先頭位置を特定する位置特定ステップとを含み、
   前記データ格納ステップにおいては、前記複数のデータテーブルを、最上位階層のデータテーブルを先頭として、同一系統のデータテーブルを上位階層から下位階層に至る順に前記ファイルに格納し、
   前記複数のデータテーブルの各々は、当該データテーブルと同一系統に属するデータテーブルであって、当該データテーブルより一つだけ下位階層のデータテーブルを一意に識別するための識別情報と、当該データテーブルより一つだけ下位階層のデータテーブルのデータサイズである次段サイズと、当該データテーブルより下位階層の全てのデータテーブルのデータサイズの合計値である配下サイズとを含み、
   前記最上位階層のデータテーブルは、当該データテーブルのデータサイズを含み、
   前記位置特定ステップにおいては、特定対象のデータテーブルの識別情報が所定方法で指定された場合に、前記データ格納ステップにて格納された前記データテーブルの前記配下サイズを、前記最上位階層のデータテーブルから、前記識別情報に基づいて識別された前記特定対象のデータテーブルより一つ前の格納位置に格納されたデータテーブルに至るまで、前記データ格納手段における前記データテーブルの格納順に加算することで、前記ファイルにおける前記最上位階層のデータテーブルの先頭位置から前記特定対象のデータテーブルの先頭位置までの相対的な位置を特定する、
   データ処理方法。
6. 請求項５に記載の方法をコンピュータに実行させるデータ処理プログラム。

Images