| 【発明の名称】 |
データベースアクセス処理方法 |
| 【発明者】 |
【氏名】中島 千昌
|
| 【要約】 |
【課題】データベースに定義された物理的な構造をアプリケーションが意識せずに、データベースからのデータの参照、及びデータベースへのデータの追加、更新、及び削除処理を一括して管理するデータベースアクセス処理方法を提供することを目的とする。
【解決手段】データベースに定義された物理的な構造とアプリケーションが使用する論理的な構造が異なるシステムにおけるデータベースアクセス処理方法において、アプリケーションからデータベースを参照または更新するとき、データベースに定義された物理的な構造をアプリケーションが使用する論理的な構造へ変換し、またはアプリケーションが使用する論理的な構造をデータベースに定義された物理的な構造へ変換するようにする。 |
【特許請求の範囲】
【請求項１】データベースに定義された物理的な構造とアプリケーションが使用する論理的な構造が異なるシステムにおけるデータベースアクセス処理方法において、アプリケーションからデータベースを参照または更新するとき、データベースに定義された物理的な構造をアプリケーションが使用する論理的な構造へ変換し、またはアプリケーションが使用する論理的な構造をデータベースに定義された物理的な構造へ変換するステップを備えたことを特徴とするデータベースアクセス処理方法。
【請求項２】データベースに定義された物理的な構造とアプリケーションが使用する論理的な構造が異なるシステムにおけるデータベースアクセス処理方法において、アプリケーションからデータベースを参照するときに、データベースに対してアクセスするべきデータのアクセス情報として、テーブルＩＤ及びアクセスキーをアプリケーションから取得するステップと、前記テーブルＩＤ及びアクセスキーを用いてデータベースから対象データを検索するステップと、検索された対象データを、データベースに定義された物理的な構造からアプリケーションが使用する論理的な構造へ変換するステップと、論理的な構造とした対象データをアプリケーションへ返すステップとを備えたことを特徴とするデータベースアクセス処理方法。
【請求項３】データベースに定義された物理的な構造とアプリケーションが使用する論理的な構造が異なるシステムにおけるデータベースアクセス処理方法において、アプリケーションからデータベースにデータを追加するときに、データベースに対してアクセスするべきデータのアクセス情報として、テーブルＩＤ、アクセスキー、及び追加データをアプリケーションから取得するステップと、前記追加データを、アプリケーションが使用する論理的な構造からデータベースに定義された物理的な構造へ変換するステップと、前記テーブルＩＤ及びアクセスキーを用いてデータベースに対象データを追加するステップとを備えたことを特徴とするデータベースアクセス処理方法。
【請求項４】データベースに定義された物理的な構造とアプリケーションが使用する論理的な構造が異なるシステムにおけるデータベースアクセス処理方法において、アプリケーションからデータベースにデータを更新するときに、データベースに対してアクセスするべきデータのアクセス情報として、テーブルＩＤ、アクセスキー、及び更新データをアプリケーションから取得するステップと、前記更新データを、アプリケーションが使用する論理的な構造からデータベースに定義された物理的な構造へ変換するステップと、前記テーブルＩＤ及びアクセスキーを用いて前記更新データでデータベースの対象データを更新するステップとを備えたことを特徴とするデータベースアクセス処理方法。
【請求項５】請求項１から４の何れか１つに記載のデータベースアクセス処理方法において、データベースの参照データをアプリケーションに返すとき、またはアプリケーションから追加／更新データをデータベースに渡すとき、それらのデータの格納場所を示すポインタを授受することでデータの授受を行うことを特徴とするデータベースアクセス処理方法。
|
【発明の詳細な説明】【０００１】
【発明の属する技術分野】本発明は、モバイルコンピュータなど小型の携帯端末上で稼動するシステムにおいて、処理性能を向上させる際に重要な要素となるデータベースの定義方法、及びデータベースへのアクセス処理方法に関する。
【０００２】
【従来の技術】データベースを使用したシステム開発では、システムの処理性能を向上させる過程でデータベースへのアクセス処理時間の対策が不可欠となる。例えば、画面表示処理及び画面終了処理において、データベースへのアクセスに要する処理時間は、画面表示に要する処理時間と比較して比重が大きいといえる。従って、データベースへのアクセス処理時間を短縮することが、全体の処理時間の短縮に最も有効な手段となる。
【０００３】また、データベースを使用したシステムにおいて、使用されるデータベースのモデルは、コンピュータの処理性能の高速化から、クエリの最適化、並列処理、及びデータの分散化等の高度な機能を備えたリレーショナルデータベースが主流となっている。リレーショナルデータベースが広く支持されてきた理由は、データベースの物理的な構造が隠され、アプリケーションは二次元の単純な表としての論理的な構造のみを意識すれば、ＳＱＬという非手続き型の問い合わせ言語により必要とするデータを容易にアクセスできることにある。
【０００４】
【発明が解決しようとする課題】モバイルコンピュータなどとして使用する小型の携帯端末は、より持ち歩きやすくするためにコンピュータ本体の大きさを小型化し、より長時間のバッテリー駆動を可能にするために低消費電力のＣＰＵを使用している。その結果、ノート型のコンピュータと比較して、より高い携帯性とより効率的なパワーマネージメントを実現している。その反面、前記の低消費電力ＣＰＵの処理性能は、ノート型のコンピュータに搭載されるＣＰＵと比較して低速であるという弱点がある。このような環境で動作するシステム開発においてリレーショナルデータベースを使用する場合、ＣＰＵの処理性能がネックとなるため、データベースへのアクセス処理の性能を確保するには、Ｉ／Ｏ数を抑えるためのテーブル構造の見直し、及び項目の統合を行い物理的なカラム数を最小限にするためのレコード構造の見直しといったデータベース設計が必要となる。
【０００５】アプリケーションの製造工程は、データベース設計が完了してから着手するのが一般的だが、携帯端末上で稼動するシステムの開発では、データベースへのアクセス処理性能を常に意識しなければならず、データベースの再設計が随時発生することになり、テーブル構造の見直しが発生する度に、多大な修正工数が発生するという問題がある。
【０００６】また、データベースに定義する性能を考慮したデータ構造とアプリケーションが使用するのに適しているデータ構造とが異なる場合、アプリケーションはデータベースに定義している物理的なデータ構造を意識することになり、データベースの物理的な構造を隠すことが可能であるというリレーショナルデータベースの長所を活用できなくなるという問題がある。
【０００７】本発明の目的は、データベースに定義された物理的な構造をアプリケーションが意識せずに、データベースからのデータの参照、及びデータベースへのデータの追加、更新、及び削除処理を一括して管理するデータベースアクセス処理方法を提供することである。
【０００８】
【課題を解決するための手段】上記目的を達成するために、請求項１に係る発明は、データベースに定義された物理的な構造とアプリケーションが使用する論理的な構造が異なるシステムにおけるデータベースアクセス処理方法において、アプリケーションからデータベースを参照または更新するとき、データベースに定義された物理的な構造をアプリケーションが使用する論理的な構造へ変換し、またはアプリケーションが使用する論理的な構造をデータベースに定義された物理的な構造へ変換するステップを備えたことを特徴とする。
【０００９】請求項２に係る発明は、データベースに定義された物理的な構造とアプリケーションが使用する論理的な構造が異なるシステムにおけるデータベースアクセス処理方法において、アプリケーションからデータベースを参照するときに、データベースに対してアクセスするべきデータのアクセス情報として、テーブルＩＤ及びアクセスキーをアプリケーションから取得するステップと、前記テーブルＩＤ及びアクセスキーを用いてデータベースから対象データを検索するステップと、検索された対象データを、データベースに定義された物理的な構造からアプリケーションが使用する論理的な構造へ変換するステップと、論理的な構造とした対象データをアプリケーションへ返すステップとを備えたことを特徴とする。
【００１０】請求項３に係る発明は、データベースに定義された物理的な構造とアプリケーションが使用する論理的な構造が異なるシステムにおけるデータベースアクセス処理方法において、アプリケーションからデータベースにデータを追加するときに、データベースに対してアクセスするべきデータのアクセス情報として、テーブルＩＤ、アクセスキー、及び追加データをアプリケーションから取得するステップと、前記追加データを、アプリケーションが使用する論理的な構造からデータベースに定義された物理的な構造へ変換するステップと、前記テーブルＩＤ及びアクセスキーを用いてデータベースに対象データを追加するステップとを備えたことを特徴とする。
【００１１】請求項４に係る発明は、データベースに定義された物理的な構造とアプリケーションが使用する論理的な構造が異なるシステムにおけるデータベースアクセス処理方法において、アプリケーションからデータベースにデータを更新するときに、データベースに対してアクセスするべきデータのアクセス情報として、テーブルＩＤ、アクセスキー、及び更新データをアプリケーションから取得するステップと、前記更新データを、アプリケーションが使用する論理的な構造からデータベースに定義された物理的な構造へ変換するステップと、前記テーブルＩＤ及びアクセスキーを用いて前記更新データでデータベースの対象データを更新するステップとを備えたことを特徴とする。
【００１２】請求項５に係る発明は、請求項１から４の何れか１つに記載のデータベースアクセス処理方法において、データベースの参照データをアプリケーションに返すとき、またはアプリケーションから追加／更新データをデータベースに渡すとき、それらのデータの格納場所を示すポインタを授受することでデータの授受を行うことを特徴とする。
【００１３】
【発明の実施の形態】以下、本発明の実施の形態について図面に従って説明する。
【００１４】図１は、本発明の実施の形態に係る携帯端末の構成を示すブロック図である。この携帯端末は、図１に示すように、ＣＰＵ１０５及び内部記憶装置１０６を有する処理装置１０１と、業務データを格納しているデータベース１０７を有する外部記憶装置１０２と、データの表示装置として使用するディスプレイ１０３と、データの入力装置として使用するタッチペン１０４とを備えている。
【００１５】処理装置１０１内のＣＰＵ１０５及び内部記憶装置１０６は、携帯端末をより持ち歩きやすくするために、小型かつ低消費電力のものを使用している。また、ディスプレイ１０３は、タッチペン１０４を使用したタップ操作による入力を可能としているため、ここでは入力装置としてキーボードは使用しない。本実施の形態では、このような携帯端末を例とするが、もちろん一般的な表示機能のみのディスプレイとキーボードを備えた携帯端末であってもよい。
【００１６】図２は、データベースアクセスモジュールとアプリケーションの処理構成図である。図１の携帯端末において、個々の処理が使用するデータの構造と、個々の処理に適したデータ構造に変換されている様子を示している。以下、データベース１０７に定義された物理的な構造を物理構造２０５と、アプリケーションが使用する論理的な構造を論理構造２０６と呼ぶ。
【００１７】内部記憶装置１０６には、アプリケーション２０１、データ領域２０２、データベース参照モジュール２０３、及びデータベース更新モジュール２０４が、記憶あるいは確保されている。アプリケーション２０１は、データを操作するための領域としてデータ領域２０２を確保している。
【００１８】個々の処理で使用するデータ構造は、破線で示したように論理構造２０６を使用する処理群と物理構造２０５を使用する処理群に大別することができる。つまり、データベース１０７に対してテーブル定義の見直し等の原因により物理構造２０５に変更があった場合、データベース参照モジュール２０３の物理定義及びデータベース更新モジュール２０４の物理定義に対する改修に絞られるため、データベース１０７の変更に対する極めて柔軟な対応を可能とした処理構成となっている。
【００１９】図３は、データベースアクセスモジュールとアプリケーションの処理内容を示すフローチャートである。データベース１０７より取得したデータをディスプレイ１０３に表示し、入力データをデータベース１０７に反映する更新処理を例として、図２の処理構成図を用いて説明する。
【００２０】まず、アプリケーション２０１は、データベース参照モジュール２０３を起動する（ステップ３０１）。この際、アプリケーション２０１が確保しているデータ領域２０２のポインタを引き渡す。
【００２１】起動されたデータベース参照モジュール２０３は、データベース１０７から対象データを取得して、取得したデータをデータ領域２０２へ格納する（ステップ３０２）。格納処理が終了した時点で、データベース参照モジュール２０３を終了し、アプリケーション２０１の処理を継続する。
【００２２】データをディスプレイ１０３に表示する場合、アプリケーション２０１はデータ領域２０２に格納されている論理構造２０６のデータを使用する（ステップ３０３）。また、ディスプレイ１０３においてタッチペン１０４による入力があった場合、アプリケーション２０１は入力されたデータでデータ領域２０２を更新する（ステップ３０４）。次に、入力データをデータベース１０７へ反映するために、データベース更新モジュール２０４を起動する（ステップ３０５）。この際、入力データを格納しているデータ領域２０２のポインタを引き渡す。
【００２３】起動されたデータベース更新モジュール２０４は、データ領域２０２に格納された対象データを取得して、取得したデータでデータベース１０７を更新する（ステップ３０６）。更新処理が終了した時点で、データベース更新モジュール２０４を終了し、アプリケーション２０１の処理は完了する。
【００２４】次に、データベース参照モジュール２０３とデータベース更新モジュール２０４の処理内容の詳細を、図４及び図５のフローチャートを使用して説明する。
【００２５】図４は、データベース参照モジュール２０３の処理内容を示すフローチャートである。アプリケーション２０１から起動されたデータベース参照モジュール２０３は、アプリケーション２０１から引数としてアクセス情報４０８を取得する（ステップ４０１）。アクセス情報４０８には、対象のテーブルＩＤ、対象データのアクセスキー、アクセス方法、及び、参照データの格納場所を示すポインタをセットする。ここでは、アクセス方法には「参照」が設定されている。
【００２６】次に、テーブルＩＤ及びアクセスキーを使用したＳＱＬを発行して、データベース１０７から対象データを検索する（ステップ４０２）。ここで、データベース１０７に対象データが存在するか判定する（ステップ４０３）。対象データが存在しなかった場合は、処理が失敗したと判断し、ステップ４０７へジャンプする。対象データが存在した場合は、データベース１０７から対象データを物理構造２０５で取得する（ステップ４０４）。更に、取得したデータを物理構造２０５から論理構造２０６へ変換する（ステップ４０５）。そして、論理構造２０６へ変換した取得データを、ポインタで指定されたデータ領域２０２に格納する（ステップ４０６）。
【００２７】最後に、処理結果４０９を戻り値としてアプリケーション２０１へ返す（ステップ４０７）。処理結果４０９には、成功または失敗を示す識別情報をセットする。
【００２８】図５は、データベース更新モジュール２０４の処理内容を示すフローチャートである。アプリケーション２０１から起動されたデータベース更新モジュール２０４は、アプリケーション２０１から引数としてアクセス情報５１４を取得する（ステップ５０１）。アクセス情報５１４には、対象のテーブルＩＤ、対象データのアクセスキー、アクセス方法、追加／更新データの格納場所を示すポインタをセットする。アクセス方法には、追加、更新、及び削除等の情報が設定される。次に、アクセス方法の判定結果で処理が分岐する（ステップ５０２）。アクセス方法が追加の場合はステップ５０３へ、更新の場合はステップ５０７へ、削除の場合はステップ５１１へ分岐する。
【００２９】まず、アクセス方法が追加の場合の処理内容を説明する。最初に、データベース１０７に対象データが存在するか判定する（ステップ５０３）。対象データが存在した場合、キーが重複するため処理が失敗したと判断し、ステップ５１３へジャンプする。対象データが存在しなかった場合は、ポインタで指定されたデータ領域２０２から、論理構造２０６の追加データを取得する（ステップ５０４）。更に、取得した追加データを論理構造２０６から物理構造２０５へ変換する（ステップ５０５）。そして、テーブルＩＤ及びアクセスキーを使用したＳＱＬを発行して、物理構造２０５へ変換した追加データをデータベース１０７へ追加する（ステップ５０６）。
【００３０】次に、アクセス方法が更新の場合の処理内容を説明する。最初に、データベース１０７に対象データが存在するか判定する（ステップ５０７）。対象データが存在しなかった場合、処理が失敗したと判断し、ステップ５１３へジャンプする。対象データが存在した場合は、ポインタで指定されたデータ領域２０２から、論理構造２０６の更新データを取得する（ステップ５０８）。更に、取得した更新データを論理構造２０６から物理構造２０５へ変換する（ステップ５０９）。そして、テーブルＩＤ及びアクセスキーを使用したＳＱＬを発行して、物理構造２０５へ変換した更新データでデータベース１０７へ更新する（ステップ５１０）。
【００３１】更に、アクセス方法が削除の場合の処理内容を説明する。最初に、データベース１０７に対象データが存在するか判定する（ステップ５１１）。対象データが存在しなかった場合、処理が失敗したと判断し、ステップ５１３へジャンプする。対象データが存在した場合はテーブルＩＤ及びアクセスキーを使用したＳＱＬを発行して、データベース１０７から対象データを削除する（ステップ５１２）。
【００３２】最後に、追加、更新、及び削除処理における処理結果５１５を戻り値としてアプリケーション２０１へ返す（ステップ５１３）。処理結果５１５には、成功または失敗を示す識別情報をセットする。
【００３３】次に、図４のステップ４０５、図５のステップ５０５及びステップ５０９におけるデータ構造の変換処理の詳細を、図６の説明図を使用して説明する。
【００３４】図６は、物理定義、及び論理定義の概要構成を説明するための説明図である。データベース参照モジュール２０３とデータベース更新モジュール２０４には、データベース１０７に定義されているテーブル群の構造体が、物理定義６０３及び論理定義６０１として定義してある。それぞれの構造の定義例は、ソースコード６０２及びソースコード６０４に示す。データ構造を変換する場合、ソースコード６０２及びソースコード６０４を使用して変換処理を行う。
【００３５】次に、テーブル構造の見直しが発生した場合の改修手順を、図７のフローチャートと図８の説明図を使用して説明する。
【００３６】図７は、テーブル構造の見直しが発生した場合の改修手順を示すフローチャートである。テーブル構造の見直しは、性能向上等の対策として発生すると考えられる（ステップ７０１）。まず、テーブル構造の見直し結果を、データベース１０７のテーブル定義へ反映させる（ステップ７０２）。次に、データベース参照モジュール２０３とデータベース更新モジュール２０４の物理定義６０３を修正する（ステップ７０３、ステップ７０４）。以上の手順で、改修作業は完了する。物理構造２０５を使用している部分のみが修正の対象となるため、アプリケーション２０１に対する修正作業は発生しない。
【００３７】図８は、物理定義の変更例を説明するための説明図である。例えば、見直し前の項目Ｘ８０１と項目Ｙ８０２を、見直し後の項目Ｚ８０４に統合するとする。データベース参照モジュール２０３とデータベース更新モジュール２０４では、見直し前のソースコード８０３及び見直し後のソースコード８０４に示すように、構造体に定義している項目名及び桁数をそれぞれ修正する。以上が、データベース参照モジュール２０３とデータベース更新モジュール２０４に対する修正内容である。この物理定義の変更に伴って、アプリケーション２０１に対する修正作業は発生しない。
【００３８】
【発明の効果】以上説明したように、本発明によれば、アプリケーションからデータベースを参照または更新するとき、データベースに定義された物理的な構造をアプリケーションが使用する論理的な構造へ変換し、またはアプリケーションが使用する論理的な構造をデータベースに定義された物理的な構造へ変換するようにしているので、データベースの再設計が随時発生することによりテーブル構造の見直しが発生した場合、アプリケーションから独立したデータベース参照モジュールの物理定義及びデータベース更新モジュールの物理定義に対する改修に絞ることで、データベースの変更に対する極めて柔軟な対応を可能としている。また、アプリケーションはデータベースに定義している物理的なデータ構造を意識する必要がなく、アプリケーションが使用するのに適したデータ構造のみを意識すればよいことになり、データベースの物理的な構造を隠すことが可能であるという、リレーショナルデータベースの長所を活用することを可能としている。
|
| 【出願人】 |
【識別番号】０００２３３０５５
【氏名又は名称】日立ソフトウエアエンジニアリング株式会社
|
| 【出願日】 |
平成１２年９月２９日（２０００．９．２９） |
| 【代理人】 |
【識別番号】１０００９６９５４
【弁理士】
【氏名又は名称】矢島 保夫
|
| 【公開番号】 |
特開２００２−１０８６６９（Ｐ２００２−１０８６６９Ａ） |
| 【公開日】 |
平成１４年４月１２日（２００２．４．１２） |
| 【出願番号】 |
特願２０００−２９７９１９（Ｐ２０００−２９７９１９） |
|