(57)【要約】【課題】  投入された外部データを効率的にチェックできるデータベースクライアントを提供する。【解決手段】  本発明のデータベースクライアントは、外部データの妥当性をチェックするデータベースクライアントにおいて、前記外部データが投入されたデータベースサーバ内の対象表の各データカラムに対して、設定されているデータの種類を集計するデータ種類集計手段と、前記データ種類集計手段により集計された設定データの種類について、予め正常データとして設定データの種類が定義された情報に基づいて、正常であるか否かを判定する正常性判定手段と、前記正常性判定手段により正常でないと判定されたデータをエラーデータとして検出するエラーデータ検出手段とを有することを特徴とする。【選択図】      図４
2017174322.tif 000002
【特許請求の範囲】
【請求項１】
外部データの妥当性をチェックするデータベースクライアントにおいて、
前記外部データが投入されたデータベースサーバ内の対象表の各データカラムに対して、設定されているデータの種類を集計するデータ種類集計手段と、
前記データ種類集計手段により集計された設定データの種類について、予め正常データとして設定データの種類が定義された情報に基づいて、正常であるか否かを判定する正常性判定手段と、
前記正常性判定手段により正常でないと判定されたデータをエラーデータとして検出するエラーデータ検出手段と
を有することを特徴とするデータベースクライアント。
【請求項２】
外部データの妥当性をチェックするデータベースクライアントに搭載されるコンピュータを、
前記外部データが投入されたデータベースサーバ内の対象表の各データカラムに対して、設定されているデータの種類を集計するデータ種類集計手段と、
前記データ種類集計手段により集計された設定データの種類について、予め正常データとして設定データの種類が定義された情報に基づいて、正常であるか否かを判定する正常性判定手段と、
前記正常性判定手段により正常でないと判定されたデータをエラーデータとして検出するエラーデータ検出手段と
して機能させることを特徴とするデータベースクライアントプログラム。
【請求項３】
外部データの妥当性をチェックするデータベースクライアントに使用するデータベースクライアント制御方法において、
データ種類集計手段、正常性判定手段、及びエラーデータ検出手段を有し、
前記データ種類集計手段は、前記外部データが投入されたデータベースサーバ内の対象表の各データカラムに対して、設定されているデータの種類を集計し、
前記正常性判定手段は、前記データ種類集計手段により集計された設定データの種類について、予め正常データとして設定データの種類が定義された情報に基づいて、正常であるか否かを判定し、
前記エラーデータ検出手段は、前記正常性判定手段により正常でないと判定されたデータをエラーデータとして検出する
ことを特徴とするデータベースクライアント制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースクライアント、データベースクライアントプログラム、及びデータベースクライアント制御方法に関し、例えば、データチェックを行いながら、外部データを取り込むデータベースクライアント、データベースクライアントプログラム、及びデータベースクライアント制御方法に適用し得る。
【背景技術】
【０００２】
一般に、データベースサーバ・クライアントシステム（以下、「ＤＢ−Ｓ／Ｃシステム」と呼ぶ）における、システム移行では、一度に多量のデータ移行が実施される。
【０００３】
例えば、旧システムから新システムにデータを移行するケースでは、新旧システムにおいて、データベースソフトウェアが異なる可能性があるため、旧システムからデータを一旦ＣＳＶ形式にて出力し、新システムに投入するような手法が用いられる。
【０００４】
また、新システムでは、移行対象データの正常性を確認するため、読み込んだデータファイルの全レコード、全カラムについて、値のチェックを実施し、移行対象データの正常性を担保する。
【０００５】
例えば、あるデータベース表の定義に基づいたデータを移行する際には、新システムは、任意のカラムの設定値が、データベースのカラム定義に準じた値であるか等のチェックを実施する。チェックの条件は、各カラムの定義によって種々様々であり、例えば、都道府県をデータとして設定するカラムであれば、４７種の都道府県名の何れかに該当するはずである。また、年齢を設定するカラムであれば、人間の寿命を考慮して、最大３桁の数値と定義されているかもしれない。さらに、別なケースでは、年齢層を示すデータとして、１０歳未満であれば「０」、１０代であれば「１」、２０代であれば「２」、といった定義カラムを持つかもしれない。このカラムに設定される値域を考えると、「０」から、現時点では最大でも「１３」という値までを想定すれば十分となり、持ちうる値域は「０」〜「１３」と定義することができる。
【０００６】
このように、新システムでは、データ移行の際、種々の条件に基づきデータをチェックしなければならず、データ量が多いことも相俟って、効率的にチェックを実施しなければならない。従来のチェック方法として、例えば、特許文献１に記載の方法が挙げられる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１２−０２２３８６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献１に記載のチェック方法は、カラム単位でレコードを順次チェックしていくが、結局は全レコードの全カラムをチェックすることになる。例えば、１レコード４カラムで構成された５レコード分のデータについては、チェック回数は、４×５の全２０回となる。
【０００９】
近年の大規模システムにおいては、扱うデータ量が多量なものとなるため、そのデータ量に比例して、チェック処理に時間が掛かることになる。
【００１０】
そのため、投入された外部データを効率的にチェックできるデータベースクライアント、データベースクライアントプログラム、及びデータベースクライアント制御方法が望まれている。
【課題を解決するための手段】
【００１１】
第１の本発明は、外部データの妥当性をチェックするデータベースクライアントにおいて、（１）前記外部データが投入されたデータベースサーバ内の対象表の各データカラムに対して、設定されているデータの種類を集計するデータ種類集計手段と、（２）前記データ種類集計手段により集計された設定データの種類について、予め正常データとして設定データの種類が定義された情報に基づいて、正常であるか否かを判定する正常性判定手段と、（３）前記正常性判定手段により正常でないと判定されたデータをエラーデータとして検出するエラーデータ検出手段とを有することを特徴とする。
【００１２】
第２の本発明のデータベースクライアントプログラムは、外部データの妥当性をチェックするデータベースクライアントに搭載されるコンピュータを、（１）前記外部データが投入されたデータベースサーバ内の対象表の各データカラムに対して、設定されているデータの種類を集計するデータ種類集計手段と、（２）前記データ種類集計手段により集計された設定データの種類について、予め正常データとして設定データの種類が定義された情報に基づいて、正常であるか否かを判定する正常性判定手段と、（３）前記正常性判定手段により正常でないと判定されたデータをエラーデータとして検出するエラーデータ検出手段として機能させることを特徴とする。
【００１３】
第３の本発明は、外部データの妥当性をチェックするデータベースクライアントに使用するデータベースクライアント制御方法において、データ種類集計手段、正常性判定手段、及びエラーデータ検出手段を有し、（１）前記データ種類集計手段は、前記外部データが投入されたデータベースサーバ内の対象表の各データカラムに対して、設定されているデータの種類を集計し、（２）前記正常性判定手段は、前記データ種類集計手段により集計された設定データの種類について、予め正常データとして設定データの種類が定義された情報に基づいて、正常であるか否かを判定し、（３）前記エラーデータ検出手段は、前記正常性判定手段により正常でないと判定されたデータをエラーデータとして検出することを特徴とする。
【発明の効果】
【００１４】
本発明によれば。投入された外部データを効率的にチェックできる。
【図面の簡単な説明】
【００１５】
【図１】実施形態のＤＢ−Ｓ／Ｃシステムの全体構成を示すブロック図である。
【図２】実施形態のデータベースに記憶されるデータベース表を示す説明図である。
【図３】実施形態のデータベースに記憶されるデータベース表に外部ファイルのデータが登録された例を示している。
【図４】実施形態のＤＢクライアントＡＰＬの特徴動作（データチェック処理）を示すフローチャートである。
【図５】実施形態のＤＢクライアントＡＰＬの特徴動作により、カラム毎のデータの種類を集計した集計データを示す説明図である。
【発明を実施するための形態】
【００１６】
（Ａ）主たる実施形態
以下、本発明によるデータベースクライアント、データベースクライアントプログラム、及びデータベースクライアント制御方法の一実施形態を、図面を参照しながら詳述する。
【００１７】
（Ａ−１）実施形態の構成
図１は、この実施形態のＤＢ−Ｓ／Ｃシステム１の全体構成を示すブロック図である。
【００１８】
ＤＢ−Ｓ／Ｃシステム１は、データベースクライアント（以下、「ＤＢクライアント」と呼ぶ）１０及びデータベースサーバ（以下、「ＤＢサーバ」と呼ぶ）２０を有している。また、ＤＢクライアント１０、ＤＢサーバ２０は、それぞれネットワークＮに接続しているものとする。
【００１９】
ＤＢ−Ｓ／Ｃシステム１は、ＤＢクライアント１０から、ＤＢサーバ２０にデータベースのデータ更新や登録などのトランザクションが与えられ、処理が行われる環境である。
【００２０】
ＤＢクライアント１０は、ＤＢサーバ２０にデータベースに係るトランザクションを与えるものである。なお、図１においては、ＤＢクライアント１０は１つとなっているが、その数は限定されないものである。ＤＢクライアント１０は、例えば、パソコン等の情報処理装置（１台に限定されず、複数台を分散処理し得るようにしたものであっても良い。）上に、クライアントプログラムをインストールすることにより、構築される。また、ＤＢクライアント１０は、ＤＢクライアントＡＰＬ１０Ａを有する。
【００２１】
ＤＢクライアントＡＰＬ１０Ａは、データベースに対する種々様々な処理（ＳＱＬの処理等）を実行するアプリケーションである。また、ＤＢクライアントＡＰＬ１０Ａは、データベースから取得したデータについてデータチェック処理を行う。
【００２２】
ＤＢサーバ２０は、ＤＢクライアント１０（ＤＢクライアントＡＰＬ１０Ａ）から与えられたトランザクションの処理を行うものであり、ＲＤＢＭＳ２１とデータベース２２を有している。
【００２３】
ＲＤＢＭＳ２１は、リレーショナルデータベース管理システムの機能を担っており、例えば、ＤＢクライアント１０から受けた取ったトランザクションの処理を行うものである。
【００２４】
データベース２２は、データ（レコード）の記憶部である。図２は、データベース２２に記憶されるデータベース表を示す説明図である。データベース表Ｔ１は、ＤＢクライアントＡＰＬ１０Ａによって、所定のデータの登録や削除等が実施されるテーブルである。
【００２５】
データベース表Ｔ１は、一般消費者のアンケート結果（データ）を蓄積するテーブルである。データベース表Ｔ１は、アンケートを行った消費者が在住する都道府県を示す「都道府県」と、消費者の年齢層を示す「年齢層」と、アンケートの第１問目の回答を示す「問１」と、アンケートの第２問目の回答を示す「問２」のカラムを有する。なお、データベース表Ｔ１は例示であって、データベース２２が保持するテーブルは、これに限定されず、種々様々な１又は複数のテーブルを保持して良い。
【００２６】
次に、ＤＢクライアント１０（ＤＢクライアントＡＰＬ１０Ａ）から、外部ファイルＦを、ＤＢサーバ２０（データベース２２）に投入（インポート）する手順について説明する。なお、外部ファイルＦのファイル形式は限定されないものであるが、例えば、ＣＳＶ（Ｃｏｍｍａ−Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅｓ）ファイル形式を適用することができる。また、外部ファイルＦは、旧ＤＢ−Ｓ／Ｃシステムで記憶されたデータを所定のファイル形式でエクスポートしたデータであっても良いし、人の手により入力されたデータであっても良い。
【００２７】
まず、ＤＢクライアントＡＰＬ１０Ａは、外部ファイルＦを既存の専用ツール（例えば、ＣＳＶファイル形式から、各データのＩＮＳＥＲＴ文を生成してトランザクションを発行するツール）を用いて、データベース２２（データベース表Ｔ１）に対して、データを一旦登録する。図３は、外部ファイルＦのデータが、一旦データベース表Ｔ１に登録された例を示している。
【００２８】
次に、ＤＢクライアントＡＰＬ１０Ａは、データベース表Ｔ１に登録したデータのチェックを行う。
【００２９】
ＤＢクライアントＡＰＬ１０Ａは、データベース表Ｔ１に登録されたデータをカラム単位で重複データを排除して集計する。例えば、ＤＢクライアントＡＰＬ１０Ａは、データベース表Ｔ１の「都道府県」のカラムについて、「東京、埼玉、横浜」の３種類、３つのデータを取得する。
【００３０】
続いて、ＤＢクライアントＡＰＬ１０Ａは、集計したデータについて、データベース表Ｔ１の各カラムの定義に基づき、入力値の妥当性をチェックする。例えば、ＤＢクライアントＡＰＬ１０Ａは、データベース表Ｔ１の「都道府県」カラムの集計した各データについて、４７都道府県のいずれかと一致していれば、データの入力値は妥当性があると判定する。なお、「東京、埼玉、横浜」について、「東京、埼玉」は４７都道府県と一致するが、「横浜」は一致しないため、ＤＢクライアントＡＰＬ１０Ａは、「横浜」をエラーデータとして検出する。
【００３１】
なお、ＤＢクライアントＡＰＬ１０Ａは、各カラムの集計したデータと比較する値（「都道府県」のカラムであれば、４７都道府県の値）については、チェックデータとして、予め比較する値が入力されたデータ配列を定義して、使用すれば良い。また、ＤＢクライアントＡＰＬ１０Ａは、これに限らず、例えば、各カラムに対応した比較値を入力した比較テーブルを用意（定義）しても良い。ＤＢクライアントＡＰＬ１０Ａは、データチェックを行う毎に比較テーブルから現在チェックしているデータの比較値を取得して比較することになる。
【００３２】
ＤＢクライアントＡＰＬ１０Ａは、データベース表Ｔ１の全てのカラムについて、上記チェック処理を行う。なお、ＤＢクライアントＡＰＬ１０Ａは、エラーデータについて、例えば、ログとしてテキストファイルに記憶したり、該当するエラーデータをデータベース表Ｔ１から削除する処理等の例外処理を行っても良い。
【００３３】
（Ａ−２）実施形態の動作
次に、以上のような構成を有するこの実施形態のＤＢ−Ｓ／Ｃシステム１の動作を説明する。以下では、外部ファイルＦのデータが、予めデータベース表Ｔ１に登録（つまり、図３の状態）されていることを前提として説明する。
【００３４】
図４は、実施形態のＤＢクライアントＡＰＬ１０Ａの特徴動作（データチェック処理）を示すフローチャートである。
【００３５】
ＤＢクライアントＡＰＬ１０Ａは、ＤＢサーバ２０からデータベース表Ｔ１に登録されたデータをカラム単位で重複データを排除して取得する（言い換えれば、カラムデータの種類を集計する）（Ｓ１０１）。なお、この例では、ＤＢクライアントＡＰＬ１０Ａは、データベース表Ｔ１の各カラム（ここでは、都道府県カラム、年齢層カラム、問１カラム、問２カラム）のデータ種類の集計を順に行い、集計結果のデータをチェックすることになる。具体的に、ＤＢクライアントＡＰＬ１０Ａは、各カラムのデータの種類を集計する手順について、例えば、ＯＲＡＣＬＥ（登録商標）データベースであれば、以下のＳＱＬにて取り出すことができる。
【００３６】
ＤＢクライアントＡＰＬ１０Ａは、都道府県カラムの設定データの種類を取得する際には、「ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  都道府県  ＦＲＯＭ  表Ｔ１」のＳＱＬ文をＤＢサーバ２０（データベース２２）に発行する。これに対して、ＤＢクライアントＡＰＬ１０Ａは、ＤＢサーバ２０から「東京、埼玉、横浜」のデータが返信される。
【００３７】
また、ＤＢクライアントＡＰＬ１０Ａは、年齢層カラムの設定データの種類を取得する際には、「ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  年齢層  ＦＲＯＭ  表Ｔ１」のＳＱＬ文をＤＢサーバ２０（データベース２２）に発行する。これに対して、ＤＢクライアントＡＰＬ１０Ａは、ＤＢサーバ２０から「１、２、３、３０」のデータが返信される。
【００３８】
さらに、ＤＢクライアントＡＰＬ１０Ａは、問１カラムの設定データの種類を取得する際には、「ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  問１  ＦＲＯＭ  表Ｔ１」のＳＱＬ文をＤＢサーバ２０（データベース２２）に発行する。これに対して、ＤＢクライアントＡＰＬ１０Ａは、ＤＢサーバ２０から「Ｙ、Ｎ、×」のデータが返信される。
【００３９】
同様に、ＤＢクライアントＡＰＬ１０Ａは、問２カラムの設定データの種類を取得する際には、「ＳＥＬＥＣＴ  ＤＩＳＴＩＮＣＴ  問２  ＦＲＯＭ  表Ｔ１」のＳＱＬ文をＤＢサーバ２０（データベース２２）に発行する。これに対して、ＤＢクライアントＡＰＬ１０Ａは、ＤＢサーバ２０から「１、２、３、５」のデータが返信される。
【００４０】
ＤＢクライアントＡＰＬ１０Ａは、先述のステップＳ１０１の処理により集計したカラム（カラム名）の判定を行う（Ｓ１０２）。ＤＢクライアントＡＰＬ１０Ａは、データベース表Ｔ１の各カラムの定義に基づき、集計したカラムが、「都道府県」の場合には後述するステップＳ１０３の処理を、「年齢層」の場合には後述するステップＳ１０４の処理を、「問１」の場合には後述するステップＳ１０５の処理を、「問２」の場合には後述するステップＳ１０６の処理を実行する。
【００４１】
ＤＢクライアントＡＰＬ１０Ａは、都道府県カラムの場合には、先に説明した通り、４７都道府県と一致するか否か判定する（Ｓ１０３）。ＤＢクライアントＡＰＬ１０Ａは、カラムデータが４７都道府県と一致しないデータが存在する場合には後述するステップＳ１０７の処理を実行し、一致する場合には後述するステップＳ１０８に処理を移行する。
【００４２】
また、ＤＢクライアントＡＰＬ１０Ａは、年齢層カラムの場合には、「年齢層」を示す値と一致するか否か判定する（Ｓ１０４）。なお、この実施形態では、「年齢層」を示す値として、１０歳未満を示す「０」、１０代を示す「１」から、最大でも１３０代を示す「１３」までの値（「０」〜「１３」）が定義されているものとする。ＤＢクライアントＡＰＬ１０Ａは、カラムデータが「年齢層」を示す値と一致しないデータが存在する場合には後述するステップＳ１０７の処理を実行し、一致する場合には後述するステップＳ１０８に処理を移行する。
【００４３】
さらに、ＤＢクライアントＡＰＬ１０Ａは、問１カラムの場合には、「問１」を示す値と一致するか否か判定する（Ｓ１０５）。なお、この実施形態では、「問１」を示す値として、あるアンケートの質問について、肯定の意を示す「Ｙ」と、否定の意を示す「Ｎ」が定義されているものとする。ＤＢクライアントＡＰＬ１０Ａは、カラムデータが「問１」を示す値と一致しないデータが存在する場合には後述するステップＳ１０７の処理を実行し、一致する場合には後述するステップＳ１０８に処理を移行する。
【００４４】
同様に、ＤＢクライアントＡＰＬ１０Ａは、問２カラムの場合には、「問２」を示す値と一致するか否か判定する（Ｓ１０５）。なお、この実施形態では、「問２」を示す値として、あるアンケートの質問ついて、３択の回答を示す、「１」〜「３」のいずれかが定義されているものとする。ＤＢクライアントＡＰＬ１０Ａは、カラムデータが「問２」を示す値と一致しないデータが存在する場合には後述するステップＳ１０７の処理を実行し、一致する場合には後述するステップＳ１０８に処理を移行する。
【００４５】
図５は、先述のステップＳ１０３〜Ｓ１０６の処理により、カラム毎のデータの種類を集計した集計データＴ２を示す説明図である。集計データＴ２では、集計前のデータベース表Ｔ１のデータに比べて、チェックするデータの数が２０から１４に減少している。言い換えれば、ＤＢクライアントＡＰＬ１０Ａは、１４件分のデータのみチェックを行えば良いことになる。なお、図４の例では、都道府県カラムの「横浜」のデータと、年齢層カラムの「３０」のデータと、問１カラムの「ｘ」のデータと、問２カラムの「５」のデータがエラーデータとして判断される。
【００４６】
ＤＢクライアントＡＰＬ１０Ａは、先述のステップＳ１０３〜Ｓ１０６の処理により各カラムで定義した値以外のデータが発見された場合には、所定のエラー処理を行う（Ｓ１０７）。例えば、ＤＢクライアントＡＰＬ１０Ａは、先述のステップＳ１０３〜Ｓ１０６のエラー結果（エラー値）をそのまま端末に表示すれば良い（又はログとして記憶すれば良い）。
【００４７】
一方、ＤＢクライアントＡＰＬ１０Ａは、データベース表Ｔ１からエラー値が設定されたデータ（レコード）を全て抽出したい場合には、ＳＱＬ文の条件文にエラー値を設定してＳＱＬ文をＤＢサーバ２０（データベース２２）に発行すれば良い。例えば、ＤＢクライアントＡＰＬ１０Ａは、先述のステップＳ１０３の処理により、データベース表Ｔ１から「東京、埼玉、横浜」のデータを取得した後、４７都道府県では無い「横浜」をエラー値と判断する。そうすると、ＤＢクライアントＡＰＬ１０Ａは、都道府県カラムのエラー値である「横浜」のデータを取得する際には、「ＳＥＬＥＣＴ  ＊  ＦＲＯＭ  表Ａ  ＷＨＥＲＥ  都道府県＝‘横浜’」のＳＱＬ文をＤＢサーバ２０（データベース２２）に発行すれば良い。
【００４８】
また、ＤＢクライアントＡＰＬ１０Ａは、エラー値が設定されたデータについて、「ＤＥＬＥＴＥ  ＊  ＦＲＯＭ  表Ａ  ＷＨＥＲＥ  都道府県＝‘横浜’」のＳＱＬ文をＤＢサーバ２０（データベース２２）に発行して、エラーデータを削除しても良い。他のデータカラムについても、同様の方法でエラーレコードを取得（又は削除）することが可能である。
【００４９】
ＤＢクライアントＡＰＬ１０Ａは、全カラムのチェックが終了した場合には、チェック処理を終了し、未チェックのカラムが存在する場合には、ステップＳ１０１からチェック処理を行う（Ｓ１０８）。
【００５０】
（Ａ−３）実施形態の効果
本実施形態によれば、ＤＢクライアントＡＰＬ１０Ａは、外部から取り込んだデータについて、そのまま全データをチェックするので無く、集約したデータをチェックすることにしたので、従来に比べて効率的にデータをチェックすることが可能となった。例えば、先述の図５で示した通り、図３で示すデータよりも２０件から１４件にチェックする数を減らすことが可能となった（つまり、６件分チェックする回数が減少）。この関係は、外部から投入されるデータ数が多くなれば、多くなる程より顕著になる（例えば、１０００倍のデータが投入されれば、６０００件分のチェック数を省略することができる）。
【００５１】
また、データカラムに設定されるデータの種類が少ないほど、その効果は高くなると言える。例えば、外部ファイルから取り込んだデータについて、都道府県カラムのデータ種類が「東京、横浜」の場合には、集計データＴ２の数は１４から１３件に減少するし、都道府県カラムのデータ種類が「東京」のみの場合には、集計データＴ２の数は１４から１２件に減少することになる。
【００５２】
（Ｂ）他の実施形態
上記の実施形態に加えて、さらに、以下に例示するような変形実施形態も挙げることができる。
【００５３】
（Ｂ−１）上記の実施形態では、ＤＢクライアントＡＰＬ１０Ａは、外部ファイルＦを、直接データベース表Ｔ１に投入して、データチェックを行っていたが、変形例として、一旦データベース表Ｔ１と同じデータ構造を持つ一時テーブルにデータを投入して、先述の図４で示したデータチェック処理を行っても良い。この場合には、ＤＢクライアントＡＰＬ１０Ａは、データチェック処理終了後、エラーデータを排除したデータのみをデータベース表Ｔ１に再度投入することになる。
【００５４】
（Ｂ−２）上記の実施形態では、ＤＢクライアントＡＰＬ１０Ａは、システム移行に伴う多量データをチェックする場合を想定して説明したが、本発明を適用するケースはこれに限定されず、例えば、バッチ処理において多量データをチェックする処理に対しても適用可能である。
【符号の説明】
【００５５】
１…ＤＢ−Ｓ／Ｃシステム、１０…ＤＢクライアント、１０Ａ…ＤＢクライアントＡＰＬ、２０…ＤＢサーバ、２１…ＲＤＢＭＳ、２２…データベース、Ｆ…外部ファイル、Ｎ…ネットワーク、Ｔ１…データベース表、Ｔ２…集計データ。
【図１】
2017174322.tif 000003
【図２】
2017174322.tif 000004
【図３】
2017174322.tif 000005
【図４】
2017174322.tif 000006
【図５】
2017174322.tif 000007