(57)【要約】【課題】リレーショナルデータベースを構築する複数の監視制御システムにおいて、新たに設計するデータのデータ属性が既存のデータと類似していれば、異なる設計者が設計する場合でも同様にデータベース化できるデータベース再利用方法を得る。【解決手段】監視制御システムに関連する空間データ１１をリレーショナルデータベースで構築するとき、空間データ１１を階層化されたクラス１３、１４によって構成し、各クラスで共通なデータ属性を上位クラス１３で定義し、クラス固有のデータ属性を下位クラス１４に定義して、別の監視制御システムでも利用しやすくしたものである。【選択図】図１
2009146045.tif 000002
【特許請求の範囲】
【請求項１】
監視制御システムに関連するデータをリレーショナルデータベースで構築し、このリレーショナルデータベースを再利用するデータベース再利用方法において、上記データを階層化されたクラスによって構成し、各クラスで共通なデータ属性を上位クラスで定義し、クラス固有のデータ属性を下位クラスで定義したことを特徴とするデータベース再利用方法。
【請求項２】
上記階層化されたクラスに基づき、計算機に実装されるデータベースである実装テーブルと、上記各クラスの参照及び変更用のアプリケーションプログラミングインターフェースとが自動的に生成されることを特徴とする請求項１記載のデータベース再利用方法。
【請求項３】
上記階層化されたクラスを有するモデルが複数作成される場合に、異なるモデル間のクラス同士には依存関係がないようにすることを特徴とする請求項１記載のデータベース再利用方法。
【請求項４】
上記上位クラスと上記下位クラスから、テキスト形式の表示用データベースを生成することを特徴とする請求項１記載のデータベース再利用方法。
【請求項５】
一つの上記クラスに対応して、正規化された複数の上記実装テーブルを生成することを特徴とする請求項１記載のデータベース再利用方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、監視制御システムで利用されるリレーショナルデータベース（ＲＤＢ）を、複数の監視制御システム間で相互に共有するデータベース再利用方法に関するものである。
【背景技術】
【０００２】
従来のリレーショナルデータベース管理システムでは、いくつかのデータ型（文字列、数値など）が用意され、利用者はこれらの中から適当なものを選択するものの、新たなデータ型の追加ができなかった。特許文献１には、これに対して、新たなデータ型の追加など簡便で高度な利用を可能にすることが記載されている。
特許文献１では、各クラスが階層を有し、上位のクラスで定義されたメソッドを下位のクラスで用いるメソッドの継承を可能にしている。
【０００３】
【特許文献１】特開平８−９５９９６号公報（第３〜７頁、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
類似の複数の監視制御システムのデータベースを異なる担当者が設計するとき、後から設計した担当者は、先行して設計されたデータベースの解釈やソフトウェアへの影響範囲が見えにくいため、完全に新規に設計した方が効率的であった。そのため、類似のデータベースにもかかわらず、完全に新規のデータベースとなり、ソフトウェアもそれに合わせて作り直さざるを得ないという問題があった。
この点は、特許文献１のものでも、同様であった。
【０００５】
この発明は、上述のような課題を解決するためになされたものであり、リレーショナルデータベースを構築する複数の監視制御システムにおいて、新たに設計するデータのデータ属性が既存のデータと類似していれば、異なる設計者が設計する場合でも同様にデータベース化できるデータベース再利用方法を得ることを目的にしている。
【課題を解決するための手段】
【０００６】
この発明に係わるデータベース再利用方法においては、監視制御システムに関連するデータをリレーショナルデータベースで構築し、このリレーショナルデータベースを再利用するデータベース再利用方法において、データを階層化されたクラスによって構成し、各クラスで共通なデータ属性を上位クラスで定義し、クラス固有のデータ属性を下位クラスで定義したものである。
【発明の効果】
【０００７】
この発明は、以上説明したように、監視制御システムに関連するデータをリレーショナルデータベースで構築し、このリレーショナルデータベースを再利用するデータベース再利用方法において、データを階層化されたクラスによって構成し、各クラスで共通なデータ属性を上位クラスで定義し、クラス固有のデータ属性を下位クラスで定義したので、新たに設計するデータのデータ属性が既存のデータと類似したものであれば、上位クラスの定義を利用することができ、データベースの再利用を行うことができる。
【発明を実施するための最良の形態】
【０００８】
実施の形態１．
図１は、この発明の実施の形態１によるデータベース再利用方法を示す図である。
図１において、監視制御システムにおける空間データ１１（データ）は、雨量ＤＢ（データベース）・水位ＤＢ・風速ＤＢのクラス１２の各データベースを有している。クラス１２は、空間データ１１の中で代表的な雨量・水位・風速ＤＢを示すクラスであり、それぞれ必要とするデータ属性が定義されている。このクラス１２は、階層化前のデータベース群を示している。
クラス１２を階層化したものが、上位のクラス１３と下位のクラス１４である。クラス１３は、空間データ１１の中ですべてのデータベースに共通するデータ属性だけを集約した観測局ＤＢのクラスである。クラス１４は、空間データ１１の中で雨量・水位・風速に固有なデータ属性だけを定義した雨量・水位・風速ＤＢのクラスであり、クラス１３の下位に位置する。
【０００９】
次に、動作について説明する。
図１のデータベースに、例えば、流量ＤＢを追加する必要があるとき、階層化前の空間データ１１であれば、雨量ＤＢ・水位ＤＢ・風速ＤＢとは全く無関係に、新たに流量ＤＢのクラスを定義する必要がある。したがって、雨量・水位・風速ＤＢに含まれる場所や観測局名称の既存のデータ属性を再度定義する必要があることになり、再度定義したデータ属性を参照するための仕組みは、再度作成することとなる。
これに対して、階層化したクラス構造の場合は、流量ＤＢのデータ属性として「場所」「観測局名称」「流量」「流速」があるとすると、「場所」「観測局名称」の属性は、すでに上位の観測局ＤＢのクラス１３において定義済みであるため、流量ＤＢのクラスでは、「流量」と「流速」を定義し、これら「流量」と「流速」を参照するための仕組みのみ追加開発すればよいことになり、生産効率が向上する。
さらに、流量ＤＢを上位クラスにして、下位クラスを生成することで、流量ＤＢクラスの持つデータ属性とそれを参照する仕組みを下位クラスで完全に再利用することも可能である。
【００１０】
実施の形態１によれば、このように、データベースの階層化を繰り返すことで、一度生産した空間データを全く異なる監視制御システムでも利用することができるようになる。
【００１１】
実施の形態２．
図２は、この発明の実施の形態２によるデータベース再利用方法を示す図である。
図２において、データベース設計者のクラス設計作業２１により、データベースのクラス２２がデータ属性を定義することにより作成される。このクラス２２は、図１に示すように階層化されたクラスである。作画データ２３は、クラス２２からテキストデータとして出力され、クラス内のデータ属性の定義情報であるクラス定義と、クラス間の関係を示す図であるクラス図からなる。アプリケーションプログラミングインターフェース（ＡＰＩ）群２４は、パソコン（計算機）に実装される最終的なデータベースである実装テーブルを参照・変更するためのＡＰＩであり、クラス２２から自動生成される。
ＡＰＩ群２４は、大きく分けて、ＤＢアクセスライブラリと、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）テンプレートが存在する。ＤＢアクセスライブラリは、データベースの参照及び変更を行うための改変不可能なＡＰＩである。そのまま使うことで、データベースの参照・変更ができる。
ＳＱＬテンプレートは、データベースを参照するための改変可能なＡＰＩである。そのまま使うのではなく、一定のユーザカスタマイズが必要である。テーブル作成ツール２５は、クラス定義とクラス図をもとにして、パソコンに実装される最終的なデータベースである実装テーブル２６を作成するためのツールである。
【００１２】
次に、動作について説明する。
実施の形態２は、設計された階層化クラスから、パソコンに実装される最終的なデータベースである実装テーブルを自動生成するようにしたものである。この実装テーブルには、図１のような階層化されたクラスを基にして、パソコンに実装される雨量テーブル、水位テーブル、風速テーブルなどが含まれる。
図２において、データベース設計者は、最初にデータ属性を定義してクラス設計を実施し、階層クラスからなるクラス２２を作成する。クラス設計が完了すると、最終的なデータベースである実装テーブル２６とＤＢアクセスライブラリ・ＳＱＬテンプレート２４が自動的にツールによって生成される。
【００１３】
図２において、設計者が実施しなければならない作業は、データ属性を定義して階層化されたクラス２２を設計するクラス設計作業２１だけである。クラス設計作業２１は、あらかじめ資産蓄積された空間データクラスが用意されているため、監視制御システムにおいては、そのシステム固有のクラスを新たに作成するか、既存のクラスに含まれるデータ属性を追加・削除する作業のみを実施すればよい。
したがって、同等な空間データを利用する監視制御システムにおいては、毎回実施するクラス設計作業を同一の手順に固定化することが可能である。その結果として、実装テーブルやＡＰＩの生成を自動化することが可能となり、システム全体の生産効率向上につながる。
【００１４】
実施の形態２によれば、必要のつど毎回実施されるクラス設計作業を同一の手順に固定化することが可能であり、その結果、実装テーブルやＡＰＩの生成を自動化することが可能となり、システム全体の生産効率向上につながる。
【００１５】
実施の形態３．
図３は、この発明の実施の形態３によるデータベース再利用方法を示す図である。
図３において、モデル３１は、それぞれのモデルが、図１の階層化されたクラスを持っている。モデル３１は、システム内で何種類でも持つことができる。クラス（親）３２は、モデル３１の中の最上位クラスであり、その下位にクラス（子）が構成されている。
【００１６】
次に、動作について説明する。
実施の形態３は、図１のような階層化されたクラスの集合をモデルとし、複数のモデルが形成されるようにしたものである。各モデルでは、改変作業を行ったときの影響範囲を、視覚的に把握することができる。
図３においては、異なるモデルに存在するクラス同士には、一切の依存関係はないルールを持たせている。そのため、モデルＡにおけるクラス内のデータ属性を変更したとしても、モデルＢ、Ｃ、Ｄ、Ｅは、データベースだけでなく、クラスを使う上での機能的な影響も一切受けることがない。
従来技術の場合、データベースとこれを使う機能の間の関係を示すためのマトリックスを作成し、それぞれの改変作業を実施したときの影響範囲を把握していたため、データベースの設計とは別にマトリックス作成作業を行う必要があった。
しかし、本発明によって、クラスまたはこれを使う機能の改変作業を行ったときの影響範囲を、クラス図を作成しただけで、視覚的に把握することができるようになる。
【００１７】
実施の形態３によれば、モデルごとにクラスを視覚化したので、クラスまたはこれを使う機能で改変作業を行ったときの影響範囲を視覚的に把握することができる。
【００１８】
実施の形態４．
図４は、この発明の実施の形態４によるデータベース再利用方法を示す図である。
図４において、モデル４１は、局クラス４２を最上位クラスにしたモデルである。局クラス４２の管理データと名称一覧データは、実装時のテーブルを示す。雨量局クラス４３は、局クラス４２を上位クラスにもつ下位クラスであり、雨量局クラス４３の管理データと時間雨量蓄積データと累加雨量蓄積データは、実装時のテーブルを示す。表示用データベース４４は、ユーザにとって利用しやすいテキスト形式のデータベースで、“表示用データベース”と呼ばれる。
【００１９】
次に、動作について説明する。
実施の形態４は、表示用データベースの自動生成についてのものである。
図４において、設計者が実施しなければならない設計作業は、階層化されたクラスをもつモデル４１の設計であり、これにより、表示用データベース４４の構築は、自動的に実行される。
モデル４１では、階層化されたクラスをもつため、表示用データベース４４を上位クラスと下位クラスの各データ属性を単純に集約するだけで生成することができる。
局クラス４２から作成される実装テーブル及び雨量局クラス４３から作成される実装テーブルは、それぞれ局クラス４２の中のデータ属性及び雨量局クラス４３の中のデータ属性だけでテーブル作成される。
表示用データベース４４は、局クラス４２と雨量局クラス４３のデータ属性が集約されたテキストデータとして作成される。
【００２０】
監視制御システムにおけるデータベースの役割には、入力される監視データが蓄積しやすいことと、表示される監視データが参照しやすいことの両立が求められる。クラスから生成される実装テーブルは、表示側の都合を考えた構造とすると、同一の種類のデータ属性をクラスとしてまとめることが難しくなるため、一般的に蓄積しやすい形に設計されることが多い。そのため、表示側の都合を考えたデータベースを別途設けないと、表示性能の劣化につながる。実施の形態４は、このため、表示用データベースを自動生成するものである。
【００２１】
実施の形態４によれば、表示用データベースが自動生成されることで、上記の問題が自動的に解決される。
【００２２】
実施の形態５．
図５は、この発明の実施の形態５によるデータベース再利用方法を示す図である。
図５において、クラス設計５１は、水位クラスと、雨量クラスと、流量クラスを設計している。このとき、それぞれのクラスには必要なデータ属性が定義されているだけである。データベース登録５２は、水位クラスと雨量クラスと流量クラスから、それぞれをデータベース内で同じ情報が複数回記録されないように正規化して、複数の実装テーブル（データベース）に変換したものであり、それぞれ複数の水位テーブル、雨量テーブル、流量テーブルが登録されている。
【００２３】
次に、効果について説明する。
このようにクラスから、データベース内で同じ情報が複数回記録されないように正規化した複数の実装テーブルを自動的に生成するため、クラス設計時には、監視制御システムを構築するために必要なデータ属性を集める作業だけに集中し、それを実装したときの実装イメージを考える必要がなくなる。どの程度、正規化を進めるかは、クラス内のグループの指定によって変更が可能である。
【００２４】
実施の形態５によれば、正規化作業とデータ属性収集の作業を明確に分離することで、データベースの生産効率を高めることができる。
【００２５】
なお、以上の説明では、空間データの設計について述べたが、本発明は、空間データに限るものではなく、他のデータの設計であってもよい。
【図面の簡単な説明】
【００２６】
【図１】この発明の実施の形態１によるデータベース再利用方法を示す図である。
【図２】この発明の実施の形態２によるデータベース再利用方法を示す図である。
【図３】この発明の実施の形態３によるデータベース再利用方法を示す図である。
【図４】この発明の実施の形態４によるデータベース再利用方法を示す図である。
【図５】この発明の実施の形態５によるデータベース再利用方法を示す図である。
【符号の説明】
【００２７】
１１  空間データ
１２  クラス
１３  上位クラス
１４  下位クラス
２１  クラスの設計作業
２２  クラス
２３  作画データ
２４  アプリケーションプログラミングインターフェース
２５  テーブル作成ツール
２６  実装テーブル
３１  モデル
３２  最上位クラス
４１  モデル
４２  局クラス
４３  雨量局クラス
４４  データベース
５１  クラス設計
５２  データベース登録
【図１】
2009146045.tif 000003
【図２】
2009146045.tif 000004
【図３】
2009146045.tif 000005
【図４】
2009146045.tif 000006
【図５】
2009146045.tif 000007