JP4598612B2 - データ処理方法、データ処理プログラムおよびデータベースサーバ - Google Patents

Description

本発明は、在庫管理や経営情報をモニタリングする場合に、ステータスポイントおよびフローポイントを用いて、モノの状態やモノの流れを含む、モノに関するデータを処理する方法、そのプログラムおよびデータベースサーバに関する。

時系列に蓄積された大量の業務データを対象に各データ項目間の関連性を分析するシステム技術として、例えば、データウェアハウスがある。現在利用されているデータウェアハウスおよびその関連サービスの事例として、経営情報をモニタリングする経営コックピットシステムが知られている。これは、ＥＲＰ（Enterprise Resource Planning）やＳＣＭ（Supply Chain Management）などの管理システムから取得したデータを収集してデータウェアハウスを構築し、分析やモニタリングなどのサービスを提供するものである。

例えば、特許文献１には、経営ソリューションシステムを実現する技術が開示されている。これは、データベースから取得した経営情報を様々な表示形態により提供するものであり、これによって経営者が的確に経営判断を実施できるとされる。また、特許文献２には、データマートを自動生成することを可能にする技術が開示されている。これは、データマートをユーザ側で自動生成させる機能であるため、ユーザごとに検索したい情報を持つことができることから、汎用性の高いシステムが構築できるとされる。
特開２００４−１３３６５２号公報（段落００１７〜００２２、図１） 特開２００２−３６６４０１号公報（段落００２４〜００２７、図１）

しかしながら、従来の技術では、企業間の統廃合や、配送センタの統廃合などによりデータフローに変更が生じた際に、既存システムの大幅な修正または新規システムの構築を行わなければならないという問題がある。例えば、企業間の統廃合が生じた場合、これまでに構築してきた経営コックピットシステムや在庫管理システムは、データフローに修正が入ることを前提に作られていないために、データウェアハウスを作成するプログラムに修正を加える必要がある。というのは、データウェアハウスは、モノの保管倉庫や資産元に関するデータを含む場合、配送センタの統廃合などによって影響を受けるからである。なお、モノに関するデータがあったときに、そのデータの属性の１つとしてモノの保管倉庫や資産元に関する定義を行うものとする。

次に、システム担当者が代わった場合、システムを容易にメンテナンスできないという問題がある。例えば、配送センタＡを新設するような場合、データウェアハウスを構築するプログラムについては、配送センタＡに関する処理を既存システムに追記しなければならない場合がある。また、従来システムは、システム内容に合わせたデータ粒度（データベース項目の詳細度）で管理されているために、新たに構築するシステムのデータ粒度がこれまでのシステムと違う場合、データウェアハウスを再構築しなければならない。

さらに、従来のデータ構造では、例えば、粗利や損益などの計算ロジックに修正が入った場合、データウェアハウスやデータマートの作成処理が階層的または段階的に定義されていないために、仕様修正による影響度が不明確になるので、計算元となる最初のデータから再処理を実施しなければならない問題がある。

そこで、本発明は、前記問題に鑑み、モノに関するデータを処理するシステムにおいて、データの属性や粒度に変更が発生してもプログラムの修正を必要とせず、個々の処理に変更が発生しても処理のやり直しを最小限に抑える手段を提供することを課題とする。

前記課題を解決する本発明は、モノに関するデータを処理するデータベースサーバに用いられるデータ処理方法であって、データベースサーバの記憶部が、モノに関するデータと、モノの状態を定義したステータスポイントと、モノの流れを定義したフローポイントとを格納し、データベースサーバの処理部が、モノの状態またはモノの流れに変更が発生した場合に記憶部のステータスポイントまたはフローポイントの定義を変更するステップと、記憶部のモノに関するデータにステータスポイントおよびフローポイントを属性として付与するステップと、ステータスポイントおよびフローポイントが付与されたデータに対して所定の処理を行うステップとを含んで実行することを特徴とする。

また、本発明は、階層構造を有するデータベースを備え、その各層のデータベース間で、モノに関するデータの処理を行うデータベースサーバであって、データベースサーバが、データベースを格納する記憶部と、データベース間でデータの入力、加工および出力を行う処理部とを含んで構成され、記憶部が、階層構造として、処理部によって入力されたモノに関するデータを登録するインタフェース層データベースと、インタフェース層データベースに登録されたデータに対して属性が付与されたデータを登録するデータウェアハウス層データベースと、データウェアハウス層データベースに登録されたデータに対してレート変換が実施されたデータを登録するワーク層データベースと、ワーク層データベースに登録されたデータに対してその利用方法に応じて加工されたデータを登録するデータマート層データベースとを備えることを特徴とする。なお、本発明は、その他のデータ処理方法、プログラムおよびデータベースサーバを含むものとする。

本発明によれば、モノの状態やモノの流れに変更が発生しても、ステータスポイントやフローポイントの定義を変更することによって対応できるので、データを処理するプログラムを変更しなくて済む。また、データベースサーバで処理するデータの粒度が変わったとしても、ステータスポイントやフローポイントの定義を変更することによって調整できるので、データを処理するプログラムを変更しなくて済む。

また、各データベース間が階層的になっていて、そのデータベース間の処理が段階的に実施されるようになっているので、個々の処理に変更が発生してもその処理を行う前のデータベースからやり直せばよいため、最初から処理をやり直す必要はなく、やり直しを最小限に抑えることができる。

以下、本発明を実施するための最良の形態について図面を参照して詳細に説明する。

≪実施の形態の概要≫
本発明は、企業間の統廃合などに伴ってモノの状態やモノの流れが変更になった際に、迅速な対応を行うために、ステータスポイントやフローポイントを属性としてデータに付与するとともに、データの処理内容およびデータベースの登録内容を段階的に定義したデータベースシステムに関するものである。

本発明の実施の形態において、ステータスポイントは、ある時点におけるモノの状態やモノが存在する場所を部品、半製品、製品、配送センタといった属性として示すものである。フローポイントは、定義されたステータスポイント間のモノの流れ（ステータスポイント間の受払い）を、モノの属性として示すものである。ステータスポイントおよびフローポイントはモノごとに定義されるため、モノにはそれを特定するための一意な番号が定義されているものとする。

次に、データベースシステムに他システムからデータを取り込む際に、ある時点におけるステータスポイント別の情報と、そのステータスポイントからの受払い計算をするための情報とが付与されているものとする。また、他システムから取り込むデータには、モノの受け払い計算を可能とする情報と、ステータスポイントごとにモノの員数が把握できる情報とが含まれるものとする。さらに、リアルタイムに情報を取得したい場合には、モノが別のステータスポイントへ移動するたびに、他システムからデータを取り込むものとする。この実施の形態によれば、例えば、モノの状態や流れに変更が生じた際には、マスタテーブルで定義したステータスポイント、フローポイントの定義を変更することで対応することが可能となる。

≪システムの構成と概要≫
図１は、本発明の実施の形態に係るデータベースシステムの構成と概要を示す図である。ＤＢ（Data Base）システム１００は、クライアントＣ、ＡＰ（Application）サーバＳおよびＤＢサーバ１を含んで構成される。クライアントＣ、ＡＰサーバＳおよびＤＢサーバ１は、ネットワークＮを介して接続されている。ネットワークＮは、ＬＡＮ（Local Area Network）やインターネットなどによって実現される。

クライアントＣは、利用者がＤＢシステム１００によるデータの分析やモニタリングなどのサービスを受けるための端末であり、ＰＣ（Personal Computer）などによって実現される。クライアントＣは、画面表示部Ｃ１および入力部Ｃ２を含んで構成される。画面表示部Ｃ１は、ネットワーク接続機器（図示せず）およびネットワークＮを介して、ＡＰサーバＳから取得した画面データをディスプレイに表示する。これによって、利用者は分析やモニタリングの結果を参照することができる。入力部Ｃ２は、利用者がディスプレイに表示された画面データに対して行う、キーボードやマウスなどの操作に対応して、所定のデータ入力やメニュー選択などを受け付ける。なお、画面表示部Ｃ１および入力部Ｃ２は、ＣＰＵ（Central Processing Unit）が所定のメモリに格納されたプログラムを実行することによって実現される。

ＡＰサーバＳは、クライアントＣが表示する画面データを生成するアプリケーションサーバであり、サーバ用コンピュータなどによって実現される。ＡＰサーバＳは、画面生成部Ｓ１およびデータ取得部Ｓ２を含んで構成される。画面生成部Ｓ１は、データ取得部Ｓ２からデータを取得し、その取得したデータに従って画面データを生成する。そして、その生成した画面データをネットワーク接続機器（図示せず）およびネットワークＮを介してクライアントＣに送信する。データ取得部Ｓ２は、ネットワーク接続機器（図示せず）およびネットワークＮを介してＤＢサーバ１からデータを受信し、その受信したデータを画面生成部Ｓ１に渡す。なお、画面生成部Ｓ１およびデータ取得部Ｓ２は、例えば、ＣＰＵが所定のメモリに格納されたプログラムを実行することによって実現される。

ＤＢサーバ１は、他システム２００からモノに関するデータを入力し、その入力したデータを分析、加工し、その結果のデータを保持する。そして、ＡＰサーバＳからの要求に応じて、そのデータをＡＰサーバＳに送信する。ＤＢサーバ１は、サーバ用コンピュータなどによって実現され、処理部Ｐおよび記憶部Ｍを含んで構成される。処理部Ｐは、ＣＰＵが所定のメモリに格納されたプログラムを実行することによって実現される。記憶部Ｍは、１層ＤＢ３、２層ＤＢ５、３層ＤＢ７、４層ＤＢ９、ステータスポイントマスタＤＢ１０、フローポイントマスタＤＢ１１、倉庫マスタＤＢ１２、資産元マスタＤＢ１３および為替レートＤＢ１４を含んで構成される。なお、記憶部Ｍは、ハードディスク装置などの不揮発性記憶装置によって実現され、各ＤＢはその不揮発性記憶装置内に構築される。

１層ＤＢ３は、インタフェース層とも呼ばれ、他システム２００の入力ファイル２０１やデータベース２０２から入力したデータを格納するＤＢである。なお、必ずしも他システム２００から入力したデータである必要はなく、ＤＢサーバ１内またはＤＢシステム１００内のいずれかにあるデータを入力してもよい。２層ＤＢ５は、データウェアハウス層とも呼ばれ、１層ＤＢ３のデータに必要な属性を付与したデータを格納するＤＢである。３層ＤＢ７は、ワーク層とも呼ばれ、２層ＤＢ５のデータをレート変換したデータを格納するＤＢである。４層ＤＢ９は、データマート層とも呼ばれ、３層ＤＢ７のデータを画面表示に適するように加工したデータを格納するＤＢである。なお、必ずしも画面表示に適するように加工するだけでなく、その他の利用方法（データの分析など）に応じて加工してもよい。

ステータスポイントマスタＤＢ１０は、ステータスポイントのマスタ情報を格納するＤＢである。フローポイントマスタＤＢ１１は、フローポイントのマスタ情報を格納するＤＢである。倉庫マスタＤＢ１２は、倉庫に関するマスタ情報を格納するＤＢである。資産元マスタＤＢ１３は、資産元に関するマスタ情報を格納するＤＢである。為替レートマスタＤＢ１４は、為替レートに関するマスタ情報を格納するＤＢである。

次に、ＤＢサーバ１の処理概要を説明する。図１に示すように、処理部Ｐは、まず、他システム２００の入力ファイル２０１やデータベース２０２からデータを抽出し、その抽出したデータを１層ＤＢ３にそのまま取り込む（ステップＳ２）。次に、１層ＤＢ３に取り込んだデータを各種マスタＤＢ（１０、１１、１２、１３）のマスタ情報と比較照合して、必要な属性を付与した後、そのデータを２層ＤＢ５に取り込む（ステップＳ４）。そして、２層ＤＢ５に取り込んだデータを為替レートマスタＤＢ１４のレートによりレート変換し、そのデータを３層ＤＢ７に取り込む（ステップＳ６）。さらに、３層ＤＢ７のデータから画面表示に適するデータマートを作成し、そのデータを４層ＤＢ９に取り込む（ステップＳ８）。

≪マスタＤＢの構成≫
図２は、本発明の実施の形態に係るＤＢ項目およびサンプルデータの一覧を示す図である。表中にアンダーラインが引いてある項目は、主キー項目を示している。

図２（ａ）に示すステータスポイントマスタテーブル一覧２１は、ステータスポイントコードを定義するマスタ情報であり、ＤＢ項目としてステータスポイントコードおよびステータスポイント名称を有する。ステータスポイントコードは、モノの各状態を定義するコードである。ステータスポイント名称は、コードによる定義内容を示すものであり、部品、半製品、製品だけでなく、配送センタＡや顧客Ａのような在庫拠点や販売チャネルなどに対しても定義する。なお、ステータスポイントマスタテーブル一覧２１は、ステータスポイントマスタＤＢ１０（図１参照）に格納される。

図２（ｂ）に示す倉庫マスタテーブル一覧２２は、モノを管理している場所を倉庫コードとして定義するマスタ情報であり、ＤＢ項目として倉庫コードおよび倉庫名称を有する。倉庫コードは、倉庫を定義するコードである。倉庫名称は、コードによる定義内容を示すものであり、モノが存在している場所を示し、その場所ごとに定義する。なお、倉庫マスタテーブル一覧２２は、倉庫マスタＤＢ１２（図１参照）に格納される。

図２（ｃ）に示すフローポイント倉庫関連一覧２３は、モノの流れをフローポイントコードとして定義するマスタ情報であり、ＤＢ項目として品目コード、倉庫コード（ＦＲＯＭ）、倉庫コード（ＴＯ）およびフローポイントコードを有する。品目コードは、モノを一意に定めるように定義するコードである。倉庫コード（ＦＲＯＭ）および倉庫コード（ＴＯ）は、それぞれモノの移動元および移動先の倉庫を示すコードである。フローポイントコードは、モノの流れにおける「流れ」を定義するコードであり、倉庫コード（ＦＲＯＭ）および倉庫コード（ＴＯ）の組合せによって一意に定まる。これによると、モノの流れは、モノごとに移動元および移動先の倉庫コードとして定義される。なお、フローポイント倉庫関連一覧２３は、フローポイントマスタＤＢ１１（図１参照）に格納される。

図２（ｄ）に示す資産元マスタテーブル一覧２４は、モノの資産元を資産元コードとして定義するマスタ情報であり、ＤＢ項目として資産元コードおよび資産元名称を有する。資産元コードは、資産元を定義するコードである。資産元名称は、コードによる定義内容を示すものであり、資産元の名称を示す。なお、資産元マスタテーブル一覧２４は、資産元マスタＤＢ１３（図１参照）に格納される。

図２（ｅ）に示すステータスポイント倉庫関連一覧２５は、品目コードで定義されるモノの状態を、倉庫コード、資産元コードおよびステータスポイントコードで定義するマスタ情報であり、ＤＢ項目として品目コード、倉庫コード、資産元コードおよびステータスポイントコードを有する。各ＤＢ項目については、既に説明した通りである。なお、ステータスポイント倉庫関連一覧２５は、ステータスポイントマスタＤＢ１０（図１参照）に格納される。

これらマスタ情報で定義するＤＢ項目は、実際にデータを使用する粒度である必要がある。本実施の形態では、ステータスポイントおよびフローポイントで必須となる品目コード以外に、倉庫コードおよび資産元コードを定義している。これは、倉庫ごとの情報を使用すること、資産元ごとの情報を必要とすることを想定したためである。例えば、組立加工業では、製品情報や機種情報などを追加することが考えられる。このように、データを使用する場合に適する粒度にするには、ステータスポイントおよびフローポイントに関して定義するマスタ情報を変更することによって対応できるので、ＤＢサーバ１の処理部Ｐで実行されるプログラムを修正する必要はない。

≪ＤＢサーバの処理≫
図３は、ＤＢサーバの処理を示すフローチャートである。図３に沿って、ＤＢサーバ１における処理部Ｐの処理について説明する（適宜図１、図２参照）。処理部Ｐは、まず、他システム２００から元となるデータを抽出する（ステップＳ３１）。次に、その抽出したデータを１層ＤＢ３に登録する（ステップＳ３２）。そして、各マスタＤＢを用いて、１層ＤＢ３のデータに属性を付与する（ステップＳ３３）。具体的には、フローポイント倉庫関連一覧２３およびステータスポイント倉庫関連一覧２５を使用して、１層ＤＢ３のデータにステータスポイントコードおよびフローポイントコードを付与する。そのデータをデータウェアハウスとなる２層ＤＢ５に登録する（ステップＳ３４）。続いて、その登録した２層ＤＢ５のデータに対して、為替レートマスタＤＢ１４を参照してレート変換を行う（ステップＳ３５）。そのレート変換したデータを３層ＤＢ７に登録する（ステップＳ３６）。さらに、その登録した３層ＤＢ７のデータから画面表示用のデータマートを作成するために、画面表示に適するようなデータ加工を行う（ステップＳ３７）。その加工したデータを４層ＤＢ９に登録する（ステップＳ３８）。

ここで、画面表示に適するようなデータ加工とは、例えば、データの粒度を粗くすることで画面表示に使用しないデータ項目を除去したり、複数のテーブルにまたがるデータを１つのテーブルに集約したりして、利用者が参照するのに適したデータにすることをいう。

図４は、１層ＤＢへのデータ登録に必要なテーブルの構成を示す図である。ＤＢ項目に引いたアンダーラインは、ＤＢの主キー項目を示すものである。他システム２００からのデータを１層ＤＢ３に格納する場合に必要となるテーブルには、図４（ａ）に示すステータスポイント別インタフェーステーブル４１および図４（ｂ）に示すフローポイント別受払インタフェーステーブル４２がある。

ステータスポイント別インタフェーステーブル４１は、品目コード、倉庫コード、資産元コードおよび年月日を主キー項目としたテーブルであり、非キー項目として通貨、金額および数量がある。これは、その「年月日」における、「品目コード」によって定義されるモノの状態を示すテーブルである。フローポイント別受払インタフェーステーブル４２は、品目コード、倉庫コード（ＦＲＯＭ）、倉庫コード（ＴＯ）および年月日を主キー項目としたテーブルであり、非キー項目として通貨、受払金額および受払数量がある。これは、その「年月日」における、「品目コード」によって定義されるモノの流れを示すテーブルである。これらのテーブルで定義されているＤＢ項目は、事前に他システム２００で付与されていると仮定する。

ここで、ＤＢサーバ１の処理部Ｐは、ステータスポイント別インタフェーステーブル４１を随時登録するわけではなく、所定の時点におけるモノの状態として一旦１層ＤＢ３に登録した後は、随時フローポイント別受払インタフェーステーブル４２を用いて、１層ＤＢ３のステータスポイント別インタフェーステーブル４１のデータを更新する。なお、フローポイント別受払インタフェーステーブル４２については、受払（モノの移動）があるごとに他システム２００から入力して用いる。

図５は、２層ＤＢおよび３層ＤＢへのデータ登録に必要なテーブルの構成を示す図である。データ項目に引いたアンダーラインはデータベースの主キー項目である。データウェアハウス層である２層ＤＢ５で必要となるテーブルには、図５（ａ）に示すステータスポイント別品目状態テーブル５１および図５（ｂ）に示すフローポイント別受払テーブル５２がある。

ステータスポイント別品目状態テーブル５１は、ステータスポイントコード、品目コード、倉庫コード、資産元コードおよび年月日を主キー項目としたテーブルであり、非キー項目として通貨、金額および数量がある。ステータスポイント別品目状態テーブル５１は、ステータスポイント倉庫関連一覧２５（図２参照）を用いて、ステータスポイント別インタフェーステーブル４１（図４参照）にステータスポイントコードを付与した結果を２層ＤＢ５に格納したものである。

フローポイント別受払テーブル５２は、フローポイントコード、品目コード、倉庫コード（ＦＲＯＭ）、倉庫コード（ＴＯ）および年月日を主キー項目としたテーブルであり、非キー項目として通貨、受払金額および受払数量がある。フローポイント別受払テーブル５２は、フローポイント倉庫関連一覧２３（図２参照）を用いて、フローポイント別受払インタフェーステーブル４２（図４参照）にフローポイントコードを付与した結果を２層ＤＢ５に格納したものである。

また、３層ＤＢ７で必要となるテーブルには、図５（ｃ）に示すレート別ステータスポイント別品目状態テーブル５３および図５（ｄ）に示すレート別フローポイント別受払テーブル５４がある。レート別ステータスポイント別品目状態テーブル５３は、ステータスポイントコード、品目コード、倉庫コード、資産元コードおよび年月日を主キー項目としたテーブルであり、非キー項目として通貨、金額および数量がある。レート別フローポイント別受払テーブル５４は、フローポイントコード、品目コード、倉庫コード（ＦＲＯＭ）、倉庫コード（ＴＯ）および年月日を主キー項目としたテーブルであり、非キー項目として通貨、受払金額および受払数量がある。レート別ステータスポイント別品目状態テーブル５３およびレート別フローポイント別受払テーブル５４は、２層ＤＢ５に格納されたステータスポイント別品目状態テーブル５１およびフローポイント別受払テーブル５２の各データに対して、それぞれ為替レートマスタＤＢ１４に登録されている通貨とレートを用いてレート変換した結果を３層ＤＢ７に格納したものである。なお、図５には、為替レートを１ドル＝１００円としてレート変換した例を示している。

図６は、ステータスポイントおよびフローポイントの変更処理を示すフローチャートである。本処理の特徴は、図３に示すＤＢサーバ１の処理の内容を変更することなく、各マスタＤＢ（１０、１１、１２、１３）のメンテナンスのみで対応可能な点である。処理部Ｐは、最初に、倉庫名称の変更、追加、削除などがある場合に倉庫マスタテーブル一覧２２（図２参照）のメンテナンス（保守のための修正）を行う（ステップＳ６１）。次に、資産元名称の変更、追加、削除などがある場合に資産元マスタテーブル一覧２４のメンテナンスを行う（ステップＳ６２）。そして、ステップＳ６１の処理に伴って変更となるフローポイント倉庫関連一覧２３の修正を行う（ステップＳ６３）。さらに、ステップＳ６１およびＳ６２の処理に伴って変更となるステータスポイント倉庫関連一覧２５の修正を行う（ステップＳ６４）。

ここでは、ステータスポイントおよびフローポイントの両方を持ち、それぞれを変更することによって、モノの状態およびモノの流れの変更に対応するように説明したが、ステータスポイントまたはフローポイントのいずれか一方を持ち、モノの状態またはモノの流れのいずれか一方の変更に対応するようにしてもよい。

４層ＤＢ９へのデータ登録に必要なテーブルについては、３層ＤＢ７のデータを元に表示したい内容によって自由に定義を定める。図７および図８を参照して、入庫高および出庫高のデータを切り出すデータマートの一例について説明する。

図７は、データフローモデル例を示す図である。ステータスポイントとして、Ｓ００１：部品購入元７１、Ｓ００２：部品７２、Ｓ００３：半製品７３、Ｓ００４：製品７４およびＳ００５：配送センタ７５を定義する。フローポイントとして、Ｆ００１：部品購入元７１からの部品７２への受け払い、Ｆ００２：部品７２からの半製品７３への受け払い、Ｆ００３：半製品７３からの製品７４への受け払いおよびＦ００４：製品７４からの配送センタ７５への受け払いを定義する。ここで、入庫高は、部品購入元７１からの部品７２への受け払い量として定義することとする。また、出庫高は、製品７４からの配送センタ７５への受け払い量として定義することとする。

図８は、図７のデータフローモデルを元に生産高／出庫高の情報を切り出すために作成した４層ＤＢ９のデータ構造を示す図である。入庫高および出庫高は、図７のＦ００１およびＦ００４の受け払い量から算出することができるため、３層ＤＢ７のレート別フローポイント別受払テーブル５４（図５参照）からフローポイントがＦ００１またはＦ００４であるレコードのみをビュー日別入庫高／出庫高テーブル８１に格納する。受払金額を合算することにより入庫高／出庫高を算出することが可能となる。本例では、入庫高が８０（＝５０＋３０）円となり、出庫高が８００（＝１００＋７００）円となる。

≪マスタメンテナンス画面の構成≫
図９は、マスタメンテナンス画面のうち、フローポイント倉庫関連一覧マスタ登録画面を示す図である。この画面は、利用者が、クライアントＣのディスプレイに表示されたＷＥＢブラウザを用いて、フローポイント倉庫関連一覧２３（図２参照）をメンテナンスする画面である。品目コード入力欄９１は、クライアントＣのキーボードなどから品目コードを直接入力するテキストボックスである。倉庫コード（ＦＲＯＭ）選択欄９２は、倉庫コード（ＦＲＯＭ）を選択できるプルダウンメニューであり、倉庫マスタテーブル一覧２２（図２参照）の内容を一覧表示する。倉庫コード（ＴＯ）選択欄９３は、倉庫コード（ＴＯ）を選択できるプルダウンメニューであり、倉庫マスタテーブル一覧２２の内容を一覧表示する。フローポイントコード入力欄９４は、クライアントＣのキーボードなどからフローポイントコードを直接入力するテキストボックスである。データ登録ボタン９５は、データを登録するためのボタンであり、利用者によってデータ登録ボタン９５が押下されたとき、９１ないし９４に入力または選択されたデータをフローポイント倉庫関連一覧２３に格納する。

図１０は、マスタメンテナンス画面のうち、ステータスポイント倉庫関連一覧マスタ登録画面を示す図である。この画面は、利用者が、クライアントＣのディスプレイに表示されたＷＥＢブラウザを用いて、ステータスポイント倉庫関連一覧２５（図２参照）をメンテナンスする画面である。品目コード入力欄１０１は、クライアントＣのキーボードなどから品目コードを直接入力するテキストボックスである。倉庫コード選択欄１０２は、倉庫コードを選択できるプルダウンメニューであり、倉庫マスタテーブル一覧２２の内容を一覧表示する。資産元コード選択欄１０３は、資産元コードを選択できるプルダウンメニューであり、資産元マスタテーブル一覧２４の内容を一覧表示する。ステータスポイントコード入力欄１０４は、クライアントＣのキーボードなどからステータスポイントコードを直接入力するテキストボックスである。データ登録ボタン１０５は、データを登録するためのボタンであり、利用者によってデータ登録ボタン１０５が押下されたとき、１０１ないし１０４に入力または選択されたデータをステータスポイント倉庫関連一覧２５に格納する。

以上によれば、ステータスポイントおよびフローポイントを用いてモノの状態や流れを定義することで、ステータスポイントおよびフローポイントの粒度で経営情報をモニタリングすることが可能となり、システム仕様の変更にはステータスポイントおよびフローポイントを定義するマスタ情報の変更または追加により対応可能となる。すなわち、処理プログラムの変更を行うことなく、システム対応が可能となる。企業間の統廃合などによってデータフローに変更が発生した場合にも、同様に対応可能である。

次に、ＤＢを処理内容および登録内容に応じて４階層に分けることで、例えば、２層部分の処理に変更が発生した場合に、１層で登録したデータを元に処理をやり直すことができ、処理変更への対応を最小限に抑えることが可能となる。また、処理が明確になっている点で、変更箇所を特定することが容易となるので、システム担当者が変更になった際の引継ぎ、システムのメンテナンスや運用が容易となる。

以上本発明の実施の形態について説明したが、図１に示すクライアントＣ、ＡＰサーバＳおよびＤＢサーバ１のそれぞれで実行されるプログラム（データ処理プログラムを含む）をコンピュータによる読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、本発明の実施の形態に係るＤＢシステム１００が実現されるものとする。なお、プログラムをインターネットなどのネットワーク経由でコンピュータシステムに提供するようにしてもよい。

以上本発明について好適な実施の形態について一例を示したが、本発明は前記実施の形態に限定されず、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

本発明の実施の形態に係るデータベースシステムの構成と概要を示す図である。 ＤＢ項目およびサンプルデータの一覧を示す図であり、（ａ）はステータスポイントマスタテーブル一覧であり、（ｂ）は倉庫マスタテーブル一覧であり、（ｃ）はフローポイント倉庫関連一覧であり、（ｄ）は資産元マスタテーブル一覧であり、（ｅ）はステータスポイント倉庫関連一覧である。 ＤＢサーバの処理を示すフローチャートである。 １層ＤＢへのデータ登録に必要なテーブルの構成を示す図であり、（ａ）はステータスポイント別インタフェーステーブルであり、（ｂ）はフローポイント別受払インタフェーステーブルである。 ２層ＤＢおよび３層ＤＢへのデータ登録に必要なテーブルの構成を示す図であり、（ａ）はステータスポイント別品目状態テーブルであり、（ｂ）はフローポイント別受払テーブルであり、（ｃ）はレート別ステータスポイント別品目状態テーブルであり、（ｄ）はレート別フローポイント別受払テーブルである。 ステータスポイントおよびフローポイントの変更処理を示すフローチャートである。 データフローモデル例を示す図である。 生産高／出庫高の情報を切り出すために作成した４層ＤＢのデータ構造を示す図である。 フローポイント倉庫関連一覧マスタ登録画面を示す図である。 ステータスポイント倉庫関連一覧マスタ登録画面を示す図である。

符号の説明

１ ＤＢサーバ（データベースサーバ）
３ １層ＤＢ（インタフェース層データベース）
５ ２層ＤＢ（データウェアハウス層データベース）
７ ３層ＤＢ（ワーク層データベース）
９ ４層ＤＢ（データマート層データベース）
Ｍ 記憶部
Ｐ 処理部

Claims (4)

1. モノに関するデータを処理するデータベースサーバに用いられるデータ処理方法であって、
   前記データベースサーバの記憶部は、
   モノに関するデータと、
   モノの状態を、当該モノが存在している場所を示す情報および当該モノの所有者または受託者である資産元を示す情報の組合せによって定義したステータスコードと、
   モノの流れを、当該モノの移動元である前記場所を示す情報および当該モノの移動先である前記場所を示す情報の組み合わせによって、または当該モノのある状態と当該モノの前記ある状態の直後の状態の組合せによって定義したフローコードと、
   を相互に関連付けて格納しており、
   前記データベースサーバの処理部は、
   モノの状態またはモノの流れに変更が発生した場合に前記記憶部のステータスコードまたはフローコードの定義を変更するステップと、
   前記記憶部のモノに関するデータに前記ステータスコードおよび前記フローコードを属性として付与するステップと、
   前記ステータスコードおよび前記フローコードが付与されたデータに対して、前記モノの状態または前記モノの流れごとに、所定の処理を行うステップと、
   を含んで実行する
   ことを特徴とするデータ処理方法。
2. コンピュータに請求項１に記載のデータ処理方法を実行させることを特徴とするデータ処理プログラム。
3. モノに関するデータを処理するデータベースサーバであって、
   モノに関するデータと、
   モノの状態を、当該モノが存在している場所を示す情報および当該モノの所有者または受託者である資産元を示す情報の組合せによって定義したステータスコードと、
   モノの流れを、当該モノの移動元である前記場所を示す情報および当該モノの移動先である前記場所を示す情報の組み合わせによって、または当該モノのある状態と当該モノの前記ある状態の直後の状態の組合せによって定義したフローコードと、
   を相互に関連付けて格納している記憶部と、
   モノの状態またはモノの流れに変更が発生した場合に前記記憶部のステータスコードまたはフローコードの定義を変更する処理と、
   前記記憶部のモノに関するデータに前記ステータスコードおよび前記フローコードを属性として付与する処理と、
   前記ステータスコードおよび前記フローコードが付与されたデータに対して、前記モノの状態または前記モノの流れごとに、所定の処理を行う処理と、
   を含んで実行する処理部と、
   を有することを特徴とするデータベースサーバ。
4. 階層構造を有するデータベースを備え、その各層のデータベース間で、モノに関するデータの処理を行うデータベースサーバであって、
   前記データベースサーバは、
   前記データベースを格納する記憶部と、
   前記データベース間でデータの入力、加工および出力を行う処理部と、
   を含んで構成され、
   前記記憶部は、前記階層構造として、
   前記処理部によって入力されたモノに関するデータを登録するインタフェース層データベースと、
   前記インタフェース層データベースに登録されたデータに対して、
   モノの状態を、当該モノが存在している場所を示す情報および当該モノの所有者または受託者である資産元を示す情報の組合せによって定義したステータスコード、ならびに、
   モノの流れを、当該モノの移動元である前記場所を示す情報および当該モノの移動先である前記場所を示す情報の組み合わせによって、または当該モノのある状態と当該モノの前記ある状態の直後の状態の組合せによって定義したフローコードのうちの少なくとも一方が付与されたデータを登録するデータウェアハウス層データベースと、
   前記データウェアハウス層データベースに登録されたデータに対してレート変換が実施されたデータを登録するワーク層データベースと、
   前記ワーク層データベースに登録されたデータに対してその利用方法に応じて加工されたデータを登録するデータマート層データベースと、
   を備え、
   前記インタフェース層データベースをもとに前記データウェアハウス層データベースを作成し、前記データウェアハウス層データベースをもとに前記ワーク層データベースを作成し、前記ワーク層データベースをもとに前記データマート層データベースを作成する
   ことを特徴とするデータベースサーバ。

Images