(57)【要約】【課題】  テーブル毎に共通のインタフェースを提供することができる汎用性に優れたテーブル操作用インタフェースプログラム（ＡＰＩ）を提供すること【解決手段】  ユーザアプリケーションプログラムから構造体のメンバ毎に１枚のカード型構造体により構成される複数のカード型構造体を受取り、その受け取った各カード型構造体に格納された型情報によって各メンバの値の格納サイズを計算し、計算結果のメンバ値を格納する構造体の格納領域を作成する第１の手段と、前記複数のカード型構造体のそれぞれで指定されたメンバ値を下位層のデータベース等から取得する第２の手段と、取得したメンバ値を前記第１の手段で作成した格納領域の構造体に格納し、前記ユーザアプリケーションプログラムに返す第３の手段とを備える。【選択図】      図１
2008217439.tif 000002
【特許請求の範囲】
【請求項１】
ユーザアプリケーションプログラムから構造体のメンバ毎に１枚のカード型構造体により構成される複数のカード型構造体を受取り、その受け取った各カード型構造体に格納された型情報によって各メンバの値の格納サイズを計算し、計算結果のメンバ値を格納する構造体の格納領域を作成する第１の手段と、前記複数のカード型構造体のそれぞれで指定されたメンバ値を下位層のデータベース等から取得する第２の手段と、取得したメンバ値を前記第１の手段で作成した格納領域の構造体に格納し、前記ユーザアプリケーションプログラムに返す第３の手段としてコンピュータを機能させるステップを備えることを特徴とするテーブル操作用インタフェースプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザアプリケーションプログラムから任意のテーブルを操作するためのテーブル操作用インタフェースプログラム（テーブル操作用ＡＰＩ）に係り、特に、Ｃ言語の構造体を使用したテーブル操作用インタフェースプログラムに関するものである。
【背景技術】
【０００２】
Ｃ言語のプログラム開発において、複数の項目を一度に扱う場合は、一般的に構造体を使用することが多い。しかし、構造体は型情報と名前情報しか持っておらず、各メンバがどの領域に配置されるのか確定されないため、不都合が生じることがある。
例えば、データベースで表されるデータの取得・設定を行うテーブル操作用ＡＰＩを考える。これは、ユーザアプリケーションプログラムとデータベース（以下、ＤＢと略記）を繋ぐ中継関数となる。ユーザアプリケーションプログラムは構造体を使用してデータの受け渡しを行い、ＤＢは構造体ではなくメンバごとの詳しい情報（型、サイズ、名前）を使う。
中継関数を用いた場合、実ＤＢに依存しないＡＰＩを作成することができ、またＤＢアクセス用の専用コマンド（ＳＱＬ等）を習得する必要が無い、などの利点が挙げられる。
ところが、このような中継関数を実装するためには、ユーザアプリケーションである上位層に構造体形式のデータを返却しなくてはならない。そのため、上位に返却する構造体の型を中継関数が予め知っていなくてはならない。つまり、任意の構造体に対応した汎用関数は作成できないこととなる。
【０００３】
このような問題を踏まえ、従来においては、使用するテーブル、取得するデータごとにＡＰＩを持つＤＡＯ（Data Access Object）などが提案されている。これは、テーブル毎に専用のＡＰＩ（Application Programming Interface）を作成する仕組みである。
例えば、図６のような構成を持ち、ユーザアプリケーションプログラム６０１が直接にＤＢ依存Ｉｎｔｅｒｆａｃｅ６０４を呼び出すことを禁止する。代わりに、ＤＡＯクラス６０２と呼ばれるクラスをテーブル６０３ごとに自動生成し、ユーザアプリケーションプログラム６０１はＤＡＯクラス６０２のメソッドを経由してデータにアクセスする。こうすることでＤＢ層の実体が変わってもユーザアプリケーションプログラム６０１を変更することなく動作させることができる。
また、下記特許文献１のように、共通ＡＰＩを作成して下位レイヤを入れ替えられるようにした発明も提案されている。これもテーブルごとにＡＰＩの作成が必要であり、任意のテーブルに対応したものとはなっていない。
【０００４】
【特許文献１】特開平１０−４９４１０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ＤＢから取得した値を上位層に返却するテーブル操作用ＡＰＩを作成する場合、従来はＤＡＯのような仕組みが使われていた。この仕組みでは、テーブルごとに新しいメソッドを定義する必要があり、テーブル毎に共通のインタフェースを提供することができないという問題がある。
【０００６】
本発明の目的は、テーブル毎に共通のインタフェースを提供することができる汎用性に優れたテーブル操作用インタフェースプログラム（ＡＰＩ）を提供することにある。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、本発明に係るテーブル操作用インタフェースプログラム（以下、テーブル操作用ＡＰＩ）は、ユーザアプリケーションプログラムから構造体のメンバ毎に１枚のカード型構造体により構成される複数のカード型構造体を受取り、その受け取った各カード型構造体に格納された型情報によって各メンバの値の格納サイズを計算し、計算結果のメンバ値を格納する構造体の格納領域を作成する第１の手段と、前記複数のカード型構造体のそれぞれで指定されたメンバ値を下位層のデータベース等から取得する第２の手段と、取得したメンバ値を前記第１の手段で作成した格納領域の構造体に格納し、前記ユーザアプリケーションプログラムに返す第３の手段としてコンピュータを機能させるステップを備えることを特徴とする。
【発明の効果】
【０００８】
本発明のテーブル操作用ＡＰＩによれば、次の効果がある。
上位層のユーザアプリケーションプログラムはメンバ毎の構造体を用いてデータアクセスが可能となる。そのため、既存のシステムを壊すことなく、下位層の変更が可能となる。
ミドルウェア層では、上位で使用する構造体の形式を事前に決めることなく、任意の構造体を上位層から受け取ることができる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明を図示する実施の形態に基づいて詳細に説明する。
図１は、本発明の一実施の形態を示すシステム構成図である。
この実施形態のシステムでは、移動体通信装置１１０上で動作するユーザアプリケーション１２０と、ＳＱＬを解釈できるＤＢ部１５０と、ＤＢ部１５０とユーザアプリケーション１２０を結ぶためのテーブル操作用ＡＰＩ１４０と、テーブル操作用ＡＰＩ１４０の中に組み込んだ構造体計算部１４１、構造体への値格納部１４２、値解析部１４３、ＤＢ制御部１４４と、ＤＢのファイルシステム１６０とを移動体通信装置１１０内のメモリ（図示しない）に備えている。
例えば、移動体通信装置の代表例である携帯電話機へ始めてデータベースを搭載することを考える。従来の携帯電話機用プログラムの開発ではデータベースを用いていなかった。そのため、上位層アプリケーションではアドレス帳、スケジューラなどのデータアクセスには構造体を用いている。一方、ＤＢでアクセスするためには、テーブル名、カラム名、カラムの型、サイズなど、細かい情報が必要になる。ＤＢをアクセスするための汎用ミドル関数を作成する場合には、どのようなテーブルでもアクセスできるよう、テーブル名、カラム名などのＤＢ情報を保持し、その情報を元に取得した値を上位層に返却しなくてはならない。
【００１０】
図１では、移動体通信装置１１０が携帯電話機に相当し、ＤＢ制御部１４４以下がすべて新規作成となる。ユーザアプリケーション１２０はできるだけ既存のプログラムを流用できるようにしておきたい。
ユーザアプリケーション１２０は、テーブル操作を行うために、カード型構造体２３１を作成し、内部で保持する。また、出力結果を得るため、構造体型２３１の領域を確保する。
【００１１】
カード型構造体２３１では、以下のような情報を持つ。
（１）フィールド番号、（２）名前、（３）型種別（dword,worDByte,stringなど）。
それぞれの型種別ごとに格納サイズは決まる。dwordであれば４バイト、wordは２バイト、byteは１バイト。string型の場合はサイズが決まらないため、別途サイズを格納する領域が必要である。３２バイト分の文字列を格納するためには”string(32)”型と表記する。
構造体型１３２はＣ言語で使用される通常の構造体である。構造体のメンバは任意のものを受け取ることができる。構造体の詳細情報についてはカード型構造体１３１が持つ。
構造計算部１４１では、ユーザアプリケーション１２０から渡されたカード型構造体２３１から、実構造体の格納領域を計算する。
構造体への値格納部１４２では、ＤＢ制御部１４４によって、ＤＢのファイルシステム１６０からＤＢ部１５０を経由して取得されたデータを値解析部１４３で構造体格納用の値に変換し、構造体型１３２の領域に格納する。その際、構造体への格納は、名前参照を用いず直接アドレスを指定して値を格納する。指定する値は、構造計算部１４１で得られたメンバごとのオフセット値を、構造体の先頭アドレスに足したものを使用する。
【００１２】
値解析部１４３では、ＤＢのファイルシステム１６０から取得した値を構造体型１３２に格納できる形に変換する。
ＤＢ制御部１４４では、ＤＢ部１５０が受け取れる形式であるＳＱＬ文を作成し、直接にＤＢ部１５０を操作する。
ＤＢ部１５０はデータベースエンジンであり、ＳＱＬ文を受け付けて、ファイルシステム１６０に結果を記録する。
【００１３】
図２は、構造体メンバのオフセット計算で使用される各データの構成図である。
カード型構造体１３１は、構造体メンバごとに１枚のカードを持ち、その中に型情報をすべて格納しておく。そのカードを複数枚束ねると、テーブルを表現するための表形式となる。
表形式型２０１はデータ構造と値の両方を持つ。先頭行の項目名がデータ名を持ち、それぞれの型（word,dwordなど）が決まっている。次の行からは実際のデータが格納される。表形式はＤＢが使用する形式であり、実体の構造はユーザアプリケーション１２０から見えなくなっている。
構造体型１３２はユーザアプリケーション１２０が使用しやすいように構造体でアクセスできるようにしたデータ構造となる。ここにはデータの値のみが格納され、データの構造についてはヘッダファイル等に記載されることになる。構造体型１３２はカード型構造体１３１の値情報のみを取り出したものとみなすことができる。このように、カード型構造体１３１を経由することで、表形式型と構造体型との相互変換を可能にする。
【００１４】
図３はテーブル操作用ＡＰＩ１４０が上位から呼出しを受けてから値を返却するまでの処理の流れを示したフローチャートである。
まず、テーブル操作用ＡＰＩ１４０が上位からの呼出しを受け、カード型構造体１３１の配列と構造体を受け取る（ステップ３０１）。
次に、構造計算部１４１が、引数で渡されたカード型構造体１３１の配列から構造体メンバのオフセットを計算する（ステップ３０２）。
次にＤＢのファイルシステム１６０から値を取得し、得た結果を構造体型１３２に格納可能な型に変換する（ステップ３０３）。
次に、取得した結果を引数で渡された構造体型１３２の領域に格納する（ステップ３０４）。その際、格納する領域はステップ３０２で計算されたオフセット値を使用する。
以上の手順により、カード型構造体１３１を受けて、構造体型１３２を返却するテーブル操作用ＡＰＩ機能を実現することができる。
【００１５】
図４は、図３のステップ３０２におけるオフセットを計算する処理の流れを示すフローチャートである。
構造体のメンバを配置する規則は規定されていないが、一般的なコンパイラでは以下のような規則がある。
（１）dword型のデータは４バイト境界に乗せる。
（２）word型のデータは２バイト境界に乗せる。
（３）byte型データは規定しない。
（４）string型データも規定しない。なおここで、string型はＣ言語のchar型配列で格納されるものと想定している。
バイト境界に乗らないデータがあった場合は、バイト境界に合わせるため、メンバ格納領域の直前に埋め草を作る。例えば、byte型の後にword型が来た場合、byte型の後に１バイトの埋め草が挿入される。
【００１６】
この動作を前提として、オフセット値を計算する方法を以下に説明する。
まず、初期オフセットを“０”とする（ステップ４０１）。
次に、カードを１枚参照し、型を調べる（ステップ４０２）。そして、現在のオフセットが、型のバイト境界に入っているかどうかを調べる（ステップ４０３）。例えば、当該型がwordであったとき、オフセットが“２”で割り切れるかどうかを調べる。バイト境界が正しい場合は、現在のオフセットに値を格納する。正しくない場合は、バイト境界が正しくなるまで、オフセットを“＋１”していく（ステップ４０４）。
次に、型のサイズ分、オフセットを増加する（ステップ４０５）。例えば、ｗｏｒｄであれば“＋２”、ｄｗｏｒｄであれば“＋４”増加する。
カード型構造体の配列データがなくなるまでステップ４０２から繰り返す（ステップ４０６）。
【００１７】
図５は上記手順を元に、実例を示したものである。
カード型構造体データ５１０を用意する。オフセット計算５２０でメンバを１つずつ参照する。ステップ５２１では、byte型であるため、オフセットは“０”となり、次オフセットを“１”にする。
ステップ５２２では、オフセット１のところに、word型が出現したため、埋め草を挿入する。deptcdのオフセットは“２”となり、次オフセットは“４”となる。
ステップ５２３では、オフセット４のところに、dword型が出現したため、workのオフセットは“４”となる。
以上の手順により計算結果５３０が決定される。
【００１８】
なお、本発明は上述した機能に限定されるものではない。例えば、オフセット計算の計算規則を変更することで、埋め草の入れ方を使用するコンパイラに合わせることができる。また、入れ方を複数通り準備しておくことにより、オフセット計算規則が定まっていない環境での計算規則を推測することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の一実施形態を示すシステム構成図である。
【図２】本発明で使用する３つのデータ型を示すデータ構成図である。
【図３】テーブル操作用ＡＰＩの処理手順を示すフローチャートである。
【図４】図３におけるオフセット計算手順の詳細を示すフローチャートである。
【図５】オフセット計算の実例を示す説明図である。
【図６】従来におけるＤＡＯシステムの概要を示す説明図である。
【符号の説明】
【００２０】
１１０…移動体通信装置、１２０…ユーザアプリケーション、１３１…カード型構造体、１３２…構造体型、１４０…テーブル操作ＡＰＩ、１４１…構造計算部、１４２…構造体への値格納部、１４３…値解析部、１４４…ＤＢ制御部、１５０…ＤＢ部、１６０…ＤＢのファイルシステム、３０１…テーブル、５１０…カード型データ、５２０…オフセット計算処理、５３０…計算結果６０１…ユーザアプリケーションプログラム、６０２…ＤＡＯクラス、６０３…テーブル型データ、６０４…ＤＢ依存Interface。
【図１】
2008217439.tif 000003
【図２】
2008217439.tif 000004
【図３】
2008217439.tif 000005
【図４】
2008217439.tif 000006
【図５】
2008217439.tif 000007
【図６】
2008217439.tif 000008