JP2014149613A

JP2014149613A - 項目間関連解析装置

Info

Publication number: JP2014149613A
Application number: JP2013017190A
Authority: JP
Inventors: Yukari Murata; 由香里村田; Kazuko Yamamoto; 和子山元; Yoshio Yamanaka; 美穂山中; Shinya Shigemura; 進也重村
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2013-01-31
Filing date: 2013-01-31
Publication date: 2014-08-21

Abstract

【課題】表形式ファイル間の相互関係を参照したり、ファイル全体を通した検索が可能な項目間関連解析装置を提供する。
【解決手段】表−ＤＢ変換部１２は、複数のフォーマットを、データベース構造に変換してデータベーステーブルを生成し、このデータベーステーブルを元に、フォーマットとデータベースを対応付けした表−ＤＢ入力対応表及びデータベース構造を定めるスキーマ定義テーブルを生成する。対象となる表データを入力すると、ＤＢ構造解析部１３は、データベースの参照関係に基づいてデータベース構造を解析し、データ項目間の参照関係を示すデータ関係図を提示するとともに、ユーザによるデータベース構造の修正を受け付け、この修正を反映させた新たなスキーマ定義を生成する。入力部１１は、表データをＣＳＶに変換し、表−ＤＢ入力対応表に基づきデータベースに格納する。
【選択図】図１

Description

本発明の実施形態は、項目間関連解析装置に関する。

今日、業務や設計等、あらゆるシーンにおいて情報を整理するために個人利用が簡単な表形式（例えば、Excel（登録商標）ファイル)によりデータ記述が行われている。

しかし、記述当初は問題なくデータを収集・整理できるが、データ量が多くなってくると、同一情報を記述しているファイル全体としてデータを整理・収集し、分析する必要性がでてくる。

また、データ項目が追加・削除されるにつれて、関連する複数ファイルにおいてデータが正しく更新されているか、データ項目間の関係がどのようになっているかが、わからなくなってくる。

さらに、運用年数が長くなり、様々な表形式でのデータ収集や整理をするためには、表形式ファイル間の相互関係を参照したり、ファイル全体を通した検索等が必要となってくる。

そこで、複数の表形式で表されたデータ（例えば、Excel（登録商標）ファイル）において、データ検索や抽出を行いたい。複数の表形式で表されたデータ項目間の関係性を俯瞰できるようにしたい。複数の表形式で表されたデータ項目間の整合性をチェックできるようにしたい、とのニーズがある。

特開平７−２８１８８１号公報

「DBAnything」「WorksheetWalker」住商情報システム株式会社 http://www.itmedia.co.jp/enterprise/articles/0509/07/news106.html

本発明が解決しようとする課題は、表形式ファイル間の相互関係を参照したり、ファイル全体を通した検索が可能な項目間関連解析装置を提供することである。

実施形態の項目間関連解析装置は、複数のフォーマットを、データベース構造に変換してデータベーステーブルを生成し、このデータベーステーブルを元に、フォーマットとデータベースを対応付けした表-ＤＢ入力対応表及びデータベース構造を定めるスキーマ定義テーブルを生成する表-ＤＢ変換部と、対象となる表データを入力し、前記表-ＤＢ入力対応表に定義されているファイル名のデータとする入力部と、データベースの参照関係に基づいて前記データベース構造を解析し、データ項目間の参照関係を示すデータ関係図を提示するとともに、ユーザによるデータベース構造の修正を受け付け、この修正を反映させた新たなスキーマ定義を生成するＤＢ構造解析部と、ユーザが定義した、データベーステーブル間の多重度の定義を元に、複数の表データにおけるデータ項目間の矛盾をチェックする項目関係チェック部と、前記項目関係チェック部から受け取ったチェック内容を表示する表示部と、前記データベーステーブル、前記表-ＤＢ入力対応表及びスキーマ定義を登録する登録部とを、備える。

本発明の実施形態に係る項目間関連解析装置の概略構成を示すブロック図である。データベーステーブルの一例を示す図である。表−ＤＢ入力対応表の一例を示す図である。スキーマ定義テーブルの一例を示す図である。表−ＤＢ変換部における処理の流れを示すフローチャートである。登録部に登録されるスキーマ定義を模式化して表した図である。入力部における処理を図示したものである。入力部における処理の流れを示すフローチャートである。登録部に登録されるデータベーステーブルを表した図である。データ関係図の一例を示す図である。データ項目間の参照関係を示すデータ関係図の提示までの処理の流れを示すフローチャートである。ユーザによる修正後のデータ関係図の一例を示す図である。修正後のＤＢ構造に基づくスキーマ定義の生成・データベーステーブルの登録を示す図である。修正後のＤＢ構造を元にしたＤＢ構造解析部における処理の流れを示すフローチャートである。項目関係チェック部の処理の流れを示すフローチャートである。

以下、本発明の一実施の形態について、図面を参照して説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。

まず、本実施形態で用いる主要な用語について説明する。

「フォーマット」とは、フィールドの並び方、フィールドの数、フィールド名を表すものである。

「ユニークキー」とは、リレーショナルデータベース（ＲＤＢ）において、列の中で一意（他のものと重複せず）である列をいう。本実施形態によってデータベース（以下、概ねＤＢと称する）毎に、ユニークキーが抽出される。

「主キー」とは、ＤＢの中から、一意に識別するものとして設定される列をいう。本実施形態では、ユニークキーの中から、ユーザによって任意に設定される。

「外部キー」とは、ＲＤＢでテーブルのある列に、別のテーブルの特定の列に含まれる項目しか入力できないようにする列をいう。

「スキーマ」とは、ＤＢの枠組み（構造）であり、データベース管理システム (DBMS) でサポートされている形式言語で記述される。ＲＤＢでは、スキーマは関係 (表) と関係内の属性 (フィールド) 、属性や関係の関連を定義する。スキーマを定義することでＤＢの枠組み（構造）が定まる。

「多重度」とは、データ項目間で一方がもう一方を参照している程度を表すもので、例えば１対０または１、１対０以上３以下のように表す。

本実施形態においては、Excel（登録商標）等に代表される複数の表形式ファイル間で定義される同一データ項目を識別し、一括してＲＤＢ化し、データ項目間の関係性を識別し、ユニークキーやデータ項目間の多重度について可視化するものである。

図１は、本発明の実施形態に係る項目間関連解析装置の概略構成を示すブロック図である。この装置は汎用のコンピュータ（例えばパーソナルコンピュータ（ＰＣ）等）と、同コンピュータ上で動作するソフトウェアとを用いて実現される。コンピュータとしては、ＣＡＤ（Computer Aided Design）やＣＡＥ（Computer Aided Engineering）に好適なエンジニアリングワークステーション（ＥＷＳ）等も含む。本実施形態はこのようなコンピュータに、データ項目間の関係性の提示処理、ユーザによるＤＢ構造の修正の受付、修正内容を反映させたデータ項目間の多重度の可視化に係る一連の処理を実行させるプログラムとして実施することもできる。

図１に示すように、本実施形態に係る項目間関連解析装置１００は、主として、入力部１１、表−ＤＢ変換部１２、ＤＢ構造解析部１３、項目関係チェック部１４、表示部１５、登録部１６、修正入力部１７より構成されている。

入力部１１は、対象となる表データを入力するものである。入力した表データは、後述する処理を経て、登録部１６に登録される。

表−ＤＢ変換部１２は、複数のフォーマットを解析してＤＢ構造に変換するものである。作成されたＤＢテーブルを元に、いずれも後述する表−ＤＢ入力対応表及びスキーマ定義テーブルを生成する。表−ＤＢ入力対応表、スキーマ定義は、登録部１６に登録される。

ＤＢ構造解析部１３は、ＤＢの参照関係に基づいてＤＢ構造を解析し、データ項目間の参照関係を示すデータ関係図を提示する。データ関係図によれば、データ項目間の多重度、ユニークキーを把握することができる。さらに、ユーザによるＤＢ構造の修正を受け付け、新たなスキーマ定義を生成する。詳細は後述する。

項目関係チェック部１４は、ユーザが定義した、ＤＢテーブル間の多重度の定義を元に、複数ファイルにおけるデータ項目間の矛盾をチェックする。チェックした結果は、表示部１５に送られる。

表示部１５は、項目関係チェック部１４から受け取ったチェック内容を表示する。

登録部１６は、表−ＤＢ入力対応表、ＤＢテーブル及びスキーマ定義を登録するものである。

修正入力部１７は、ＤＢを構成するＤＢ構造について、ユーザからの修正を受け付けるものである。修正内容は、ＤＢ構造解析部１３に送られる。

次に、以上のように構成された項目間関連解析装置１００における項目間の関連解析処理について説明する。

＜表−ＤＢ変換部１２の処理＞
表−ＤＢ変換部１２では、フォーマット毎に、データ項目の種別等を表す列名（フィールド名）を読み取ってＤＢテーブルを生成する。図２は、ＤＢテーブルの一例を示す図である。図２に示す例では、フォーマット“会員名簿”については、“会員ＩＤ”、“名前”、“ＴＥＬ”をフィールド名として“会員名簿”ＤＢテーブルが生成されている。同様に、フォーマット“図書一覧”については、“図書ＩＤ”、“図書名”をフィールド名として“図書一覧”ＤＢテーブルが生成されている。また、フォーマット“貸出台帳”については、“貸出ＩＤ”、“会員ＩＤ”、“図書ＩＤ”、“貸出日”、“返却日”をフィールド名として“貸出台帳”ＤＢテーブルが生成されている。これらのＤＢテーブルは、登録部１６に登録される。

表−ＤＢ変換部１２では、作成されたＤＢテーブルを元に、表−ＤＢ入力対応表及びスキーマ定義テーブルを生成する。図３は、表−ＤＢ入力対応表の一例を示す図である。図３に示すように、フォーマットが各ＤＢに対応付けされている。図４は、スキーマ定義テーブルの一例を示す図である。このスキーマ定義によってＤＢの構造が定まり、スキーマ定義を修正すれば、ＤＢ構造が変わることになる。

図５は、表−ＤＢ変換部１２における処理の流れを示すフローチャートである。

まず、対象となる表形式のデータを入力する（ステップＳ５１）。

次に、入力した表形式のデータから、ファイル名と列名を抽出する（ステップＳ５２）。

次に、図３に示すように、表−DB入力対応表のフォーマット側、DB側それぞれに「ファイル名：列名」を追加する（ステップＳ５３）。

次いで、スキーマ定義テーブルとして、以下の文字列のうちファイル名と列名を置き変える。尚、列名の一文は随時追加される（ステップＳ５４）。

次いで、全ての列名を登録したかを判定する（ステップＳ５５）。登録していない列名があれば（ステップＳ５５でＮｏ）、ステップＳ５３に戻る。

全ての列名を登録したならば（ステップＳ５５でＹｅｓ）、全ての表データを入力したかを判定する（ステップＳ５６）。入力していない表データがあれば（ステップＳ５６でＮｏ）、ステップＳ５１に戻る。

全ての表データを入力したならば（ステップＳ５６でＹｅｓ）、スキーマを定義（ステップＳ５７）して登録部１６に登録する。スキーマの定義は、Create文をSQLコマンドにて実行して行う。スキーマの定義後、表-ＤＢ変換部１２における処理を終了する。

図６は、登録部１６に登録されるスキーマ定義を模式化して表した図である。

＜入力部１１の処理＞
入力部１１は、図２に示す表形式のデータを、言わば生（なま）データのまま入力する。入力した表形式のデータは、図３に示す表−ＤＢ入力対応表に定義されているファイル名のデータとして、登録部１６に登録される。

図７は、入力部１１における処理を図示したものである。また、図８は、入力部１１における処理の流れを示すフローチャートである。

まず、対象となる表データを入力する（ステップＳ８１）。

次に、表データを表-ＤＢ入力対応表に定義されたフォーマット側の[ファイル名:列名]の順番でCSV形式に出力する（ステップＳ８２）。CSV形式は、データをカンマで区切って並べた汎用性の高いファイル形式である。

次いで、出力されたCSVファイルを表-ＤＢ入力対応表に定義されたファイル名のDB側のデータとしてSQLで流し込む（ステップＳ８３）。

次に、全ての表データを入力したかを判定する（ステップＳ８４）。入力していない表データが残っていれば（ステップＳ８４でＮｏ）、ステップＳ８１に移行する。

全ての表データを入力したならば（ステップＳ８４でＹｅｓ）、入力部１１の処理を終了する。

図９は、登録部１６に登録されるＤＢテーブルを表した図である。

＜データ項目間の参照関係を示すデータ関係図の提示＞
まず、ＤＢ構造解析部１３による処理のうち、データ項目間の参照関係を示すデータ関係図の提示について説明する。

ＤＢ構造解析部１３では、各テーブルでユニークキーとなっているフィールドを解析する。例えば、“会員名簿”の場合、「select count(*) from 会員名簿」の数と「select count(Count(*)) from 会員名簿 group by 会員ID」の数が同等の場合、ユニークと判断する。

ユニークキーの解析後、テーブル間でフィールド名が同じものに対する多重度の解析を実行する。例えば、“会員名簿”と“貸出台帳”の場合、「Select count(貸出ID) from table 貸出台帳 group by 会員ID」によって、“会員名簿”に対する“貸出台帳”の多重度を算出する。また、「Select count(会員ID) from table 貸出台帳 group by 貸出ID」によって、“貸出台帳”に対する“会員名簿”の多重度を算出する。

算出した多重度とユニークキーの解析結果を元に、データ項目間の参照関係を示すデータ関係図を提示する。データ関係図により、データ項目間の多重度、ユニークキーの可視化が図られる。

図１０は、データ関係図の一例を示す図である。図１０によれば、“会員名簿”では、“会員ID”がユニークキーとして抽出されている。“貸出台帳”では、“貸出ID”と“図書ID”がユニークキーとして抽出されている。“図書一覧”では、“図書ID”がユニークキーとして抽出されている。

“会員名簿”と“貸出台帳”との参照関係については、“会員名簿”から見ると“会員ID”の１項目が“貸出台帳”によって参照され、一方、“貸出台帳” から見ると“会員名簿”の０項目が参照されていることがわかる。“図書一覧”と“貸出台帳”との参照関係については、“図書一覧” から見ると“図書ID” の１項目が“貸出台帳”によって参照され、一方、“貸出台帳” から見ると“図書一覧”の０〜１項目が参照されていることがわかる。

図１１は、データ項目間の参照関係を示すデータ関係図の提示までの処理の流れを示すフローチャートである。

まず、各ＤＢテーブルのフィールドのデータがユニークかどうか検索する（ステップＳ１１１）。例えば、「select count(*) from テーブル名」の数と「select count(Count(*)) from テーブル名 group by フィールド名」の数が同等の場合、フィールドはユニークキーと判断する。

次いで、全てのフィールドを走査したかを判定する（ステップＳ１１２）。走査していないフィールドがあれば（ステップＳ１１２でＮｏ）、ステップＳ１１１に戻る。

全てのフィールドを走査したならば（ステップＳ１１２でＹｅｓ）、あるＤＢテーブルのユニークキーのフィールド名と同じフィールド名があるＤＢテーブルを抽出する（ステップＳ１１３）。

次に、同じフィールド名をユニークキーがいくつ参照しているかカウントする（ステップＳ１１４）。

具体的には、SQL「Select count(主キー) from 同フィールド名を持つテーブルgroup by 同フィールド名」でカウントする。

次いで、同じフィールド名を持つＤＢテーブルに対する主キーを持つＤＢテーブルの多重度を算出する（ステップＳ１１５）。

次に、全てのフィールド名を走査したかを判定する（ステップＳ１１６）。走査していないフィールド名があれば（ステップＳ１１６でＮｏ）、ステップＳ１１３に戻る。

全てのフィールド名を走査したならば（ステップＳ１１６でＹｅｓ）、データ関係図を提示して（ステップＳ１１７）、ＤＢ構造の修正受付前までの処理を終了する。

＜ユーザによるＤＢ構造修正の反映＞
ＤＢ構造解析部１３は、提示されたデータ関係図について、ユーザからの修正を受け付ける。ユーザは、例えば、主キーの指定、外部キーの指定、データ項目間の多重度の変更を行うことができる。そして、主キーが同じであったら、同一レコードを表しているので、マージする必要がある。

ユーザによる修正内容を反映し、例えば、図１０に示すデータ関係図が、図１２に示す修正後のデータ関係図となったとする。図１２に示す例では、“会員名簿”では“会員ID”が主キーとして指定されている。“貸出台帳”では“貸出ID” が主キーとして指定され、“会員ID”と“図書ID”が外部キーとして指定されている。“図書一覧”では“図書ID”が主キーとして指定されている。さらに、“会員名簿”と“貸出台帳”との参照関係については、“貸出台帳” から見て“会員名簿”の０〜１０のデータ項目が参照可能なように変更されていることがわかる。

ＤＢ構造解析部１３は、修正されたＤＢ構造を元に、新たなスキーマ定義を生成する。図１３は、修正後のＤＢ構造に基づくスキーマ定義の生成・ＤＢテーブルの登録を示す図である。図１３（ａ）に示す修正後のＤＢ構造を元に、図１３（ｂ）に示す新たなスキーマ定義が生成され、登録部１６には新たなスキーマ定義に基づいて、図１３（ｃ）に示すＤＢテーブルが登録される。

図１４は、修正後のＤＢ構造を元にしたＤＢ構造解析部１３における処理の流れを示すフローチャートである。

まず、ユーザは、データ項目間の多重度を変更し、主キー、外部キーを指定する（ステップＳ１４１）。

次に、データ関係図のデータを入力する（ステップＳ１４２）。

次に、テーブル名とフィールド名を抽出する（ステップＳ１４３）。

次いで、スキーマ定義テーブルとして、以下の文字列のうちテーブル名、フィールド名を置き変える。尚、フィールド名の定義部分は随時追加される。また、Not NULL制約は、関連先の多重度が１の場合に定義される（ステップＳ１４４）。

次に、全てのフィールド名を登録したかを判定する（ステップＳ１４５）。

全てのフィールド名を登録したならば（ステップＳ１４５でＹｅｓ）、全てのＤＢテーブル名を登録したかを判定する（ステップＳ１４６）。全てのフィールド名を登録していなければ（ステップＳ１４５でＮｏ）、ステップＳ１４４に戻る。

全てのテーブル名を登録していなければ（ステップＳ１４６でＮｏ）、ステップＳ１４３に戻る。全てのＤＢテーブル名を登録したならば（ステップＳ１４６でＹｅｓ）、登録部１６に登録されるＤＢテーブルCreate文をSQLコマンドにて実行し、スキーマを定義（ステップＳ１４７）して、修正されたＤＢ構造を元にした処理を終了する。

＜項目関係チェック部１４の処理＞
ここでの処理は、ユーザが定義したＤＢテーブル間の多重度の定義を元に、複数のファイルにおけるデータ項目間の矛盾をチェックする。

例えば、図１２に示すデータ関係図において、ＤＢテーブル間の多重度のルールが、次のように定義されているとする。
（１）“貸出台帳”のレコードは、ただ１つの“会員名簿”のレコードと関連する。
（２）“貸出台帳”のレコードは、ただ１つの“図書一覧”のレコードと関連する。
（３）“会員名簿”のレコードは、１０項目以下の“貸出台帳”のレコードと関連する。

項目関係チェック部１４では、上記のように定義されたルール（ここでは、多重度に関するルール）に基づいてデータ項目間の矛盾の有無をチェックする。

ルール（１）については、フィールドのNot NULL制約によりチェックする。ルール（２）については、フィールドのNot NULL制約によりチェックする。ルール（３）については、多重度を調べるため、以下のSQLを作成してチェックする。

10 < select Max(count(会員ID)) from 貸出台帳 group by 会員ID;
生成されたＳＱＬをチェックした結果は、例えば、以下のように出力される。
（ａ）“貸出台帳”の“貸出ID××”が１つの“会員ID”と関連していません。
（ｂ）“貸出台帳”の“図書ID××”が１つの“会員ID”と関連していません。
（ｃ）“会員名簿”の会員ID××が１０項目以上の“貸出ID”と関連しています。

図１５は、項目関係チェック部１４の処理の流れを示すフローチャートである。

まず、データ関係図のデータを入力する（ステップＳ１５１）。

次に、ＤＢテーブル間の多重度を抽出する（ステップＳ１５２）。

続いて、以下のルールに対するSQL文を作成する（ステップＳ１５３）。

（１）１対１なら、互いに一意制約をつける。
（２）２..３等の直接数指定の場合は、その数の間に関連がおさまるかどうかをチェックする。

次に、全ての多重度を走査したか否かを判定する（ステップＳ１５４）。全ての多重度を走査していなければ（ステップＳ１５４でＮｏ）、ステップＳ１５２に戻る。

全ての多重度を走査したならば（ステップＳ１５４でＹｅｓ）、DBの実データに対してSQLを発行する（ステップＳ１５５）。

次に、チェックルールに違反しているか否かを判定する（ステップＳ１５６）。チェックルールに違反していれば（ステップＳ１５６でＹｅｓ）、エラーを出力する（ステップＳ１５７）。

チェックルールに違反していなければ（ステップＳ１５６でＮｏ）、項目関係チェック部１４の処理を終了する。

本実施形態によれば複数の表ファイル間のＤＢ構造を解析することができ、検索の高速化とデータ項目間の矛盾の有無をチェックすることができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１００・・・項目間関連解析装置
１１・・・入力部
１２・・・表−ＤＢ変換部
１３・・・ＤＢ構造解析部
１４・・・項目関係チェック部
１５・・・表示部
１６・・・登録部

Claims

複数のフォーマットを、データベース構造に変換してデータベーステーブルを生成し、このデータベーステーブルを元に、フォーマットとデータベースを対応付けした表−ＤＢ入力対応表及びデータベース構造を定めるスキーマ定義テーブルを生成する表−ＤＢ変換部と、
対象となる表データを入力し、前記表−ＤＢ入力対応表に定義されているファイル名のデータとする入力部と、
データベースの参照関係に基づいて前記データベース構造を解析し、データ項目間の参照関係を示すデータ関係図を提示するとともに、ユーザによるデータベース構造の修正を受け付け、この修正を反映させた新たなスキーマ定義を生成するＤＢ構造解析部と、
ユーザが定義した、データベーステーブル間の多重度の定義を元に、複数の表データにおけるデータ項目間の矛盾をチェックする項目関係チェック部と、
前記項目関係チェック部から受け取ったチェック内容を表示する表示部と、
前記データベーステーブル、前記表−ＤＢ入力対応表及びスキーマ定義を登録する登録部とを、
備える項目間関連解析装置。
前記データ関係図は、データ項目間の多重度、ユニークキーを表示する請求項１記載の項目間関連解析装置。
前記データベーステーブルは、フォーマット毎に、データ項目の種別等を表す列名を読み取って生成される請求項１又は請求項２記載の項目間関連解析装置。
さらに、
前記データベース構造について、ユーザからの修正を受け付ける修正入力部を備え、前記修正入力部は、修正内容を前記ＤＢ構造解析部へ送る請求項１乃至請求項３のいずれか１項に記載の項目間関連解析装置。
前記入力部は、表データをCSV形式に換え、該CSVファイルを前記表-ＤＢ入力対応表に定義されたファイル名のデータベース側のデータとする請求項１乃至請求項４のいずれか１項に記載の項目間関連解析装置。
前記ＤＢ構造解析部では、各テーブルでユニークキーとなっているフィールドを解析し、ユニークキーの解析後、テーブル間でフィールド名が同じものに対する多重度を解析する請求項１乃至請求項５のいずれか１項に記載の項目間関連解析装置。