まず始めに、本明細書で使用される用語であって、特に重要な用語について、以下の様に定義する。
「質問フォーム」とは、データ入力領域が配置された定型のフォームを言う。
「質問タグ」とは、各データ入力領域に付されるものであり、各データ入力領域を識別可能にするものを言う。
「質問階層タグ」とは、データ入力領域の階層構造を定義するためのものであり、階層的に下位に属する「質問タグ」又は「質問階層タグ」から紐づけられるものを言う。
「回答データ」とは、データ入力領域に入力されたデータを言う。
「回答データ階層タグ」とは、「回答データ」の階層を定義するもためのものであり、階層的に下位に属する「回答データ」又は「回答データ階層タグ」から紐づけられるものを言う。
以下、本発明の各実施形態について適宜図を用いて説明をする。なお、本発明はこれらの実施形態に何ら限定されるものではなく、その要旨を逸脱しない範囲において、様々な実施をすることが可能である。
<<実施形態1>>
<概要>
図1は、本実施形態のデータベースシステム生成装置の概要を示す図である。この図にあるように、本実施形態は、サーバ装置および当該サーバ装置と通信するクライアント端末によって構成される。クライアント端末は2種類存在し、1種類目は、質問フォームをデザインして、データベースシステムを設計するためのシステム設計端末。2種類目の端末は、システム設計端末により設計されたデータベースシステムを使用するためのシステム使用端末である。すなわち、サーバ装置は、システム設計端末から受信した質問フォームのデザイン情報を元に、質問フォーム定義情報を作成し、質問フォーム定義テーブルに格納、さらに質問フォーム画面を作成することにより、自らの内部にデータベースシステムを生成する。そして、システム使用端末からシステム使用のリクエストがあれば、作成した質問フォーム画面をシステム使用端末に出力し、システム使用端末から回答データが返信されれば回答データテーブルに格納する。
なお、以下、本サーバ装置及びクライアント端末の各構成を説明するが、これらの構成が様々なハードウェア及びソフトウェアの組み合わせによって実現できることは当然である。例えば、サーバ装置は業務用サーバであってもよいし、通常のパソコンであってもよい。クラインアント端末は通常のパソコンであってもよいし、スマートフォンであってもよいし、専用の携帯端末(PDA)であってもよい。システム設計端末とシステム使用端末を同一の機器によって構成してもよいし、サーバ装置に直接ディスプレイやキーボードなどの入出力のための装置を接続してこれを端末としてもよい。データを格納するための記録媒体はハードディスクであってもよいし、不揮発性メモリであってもよいし、揮発性メモリとハードディスク又は不揮発性メモリの組み合わせであってもよい。データベースは一般に流通しているデータベースソフトを用いてもよいし、自ら開発したデータベースソフトを用いてもよい。また、インメモリデータグリッドのようなリレーショナルデータベースに準ずる構成を実現するシステムを本実施形態のデータベースとして使用してもよい。プログラムの構成については、単一のプログラムによって構成されてもよいし、複数のプログラムによって構成されてもよい。さらには、サーバと端末に異なる役割のプログラムを配置し、これらを連携させる構成としてもよいし、サーバにすべてのプログラムを配置し、端末にはブラウザ等のインターフェースのみを置くこととしてもよい。その他、本実施形態は、その要旨を逸脱しない範囲において、あらゆるハードウェア及びソフトウェアの組み合わせによって実現してよいものである(以降に列記する他の実施形態についても同様)。
<機能的構成>
本発明は、質問フォーム定義テーブルおよび回答データテーブルのデータ構造に大きな特徴がある。よって、本実施形態についても、当該データ構造から説明する。ただし、当該データ構造は、従来の正規化されたデータ構造とは、根本的に異なる発想から生み出されたものであり、いきなりこれを理解するのは容易ではない。したがって、以下の説明では、まず、従来の正規化されたデータ構造について具体的構成例を示し、合わせてその構造の問題点を説明する。次に、この具体的構成例を本発明のデータ構造によって置き換えた場合の構成例を示しつつ、従来のデータ構造と対比して本発明のデータ構造の意義を説明するものとする。
図2aおよび図2bは、顧客情報と顧客の購入履歴情報について、従来の考え方に基づいて設計したデータ構造の簡単な例である。図2aは、顧客テーブルであり、「顧客ID」格納列、「氏名」格納列、「カナ」格納列および「住所」格納列を有している。なお、上記「顧客ID」は顧客の会員番号のようなものではなく、あくまでもテーブル内のレコードの識別番号としてのIDであり、システム内のデータ管理のための情報である。
図2bは購入履歴テーブルであり、「購入履歴ID」格納列、「顧客ID」格納列、「商品名」格納列、「購入数」格納列、「金額」格納列および「購入年月日」格納列を有している。上記「購入履歴ID」および「顧客ID」は、テーブル内のレコードの識別番号としてのIDであり、システム内のデータ管理のための情報である。ここで重要な点は、購入履歴テーブルの「顧客ID」は、顧客テーブルの「顧客ID」と対応しており、この「顧客ID」によって、両テーブルが紐づけられている、という点である。
図3aは、従来の顧客テーブルおよび購入履歴テーブルの、データ内容の具体例を示したものである。表に記載された矢印は紐づけ関係を示している。すなわち、顧客テーブルの顧客ID「1」の情報に、購入履歴テーブルの購入履歴ID「1」および「2」のデータが、当該顧客ID「1」によって紐付けられており、また、顧客テーブルの顧客ID「2」の情報には、購入履歴テーブルの購入履歴ID「3」および「4」のデータが、当該顧客ID「2」によって紐付けられている。
この階層構造を展開したものが図3bである。すなわち、氏名「山田太郎」なる顧客は、「2012年7月1日」に「歯ブラシA」を「2」個「1200」円で、同じく「2012年7月1日」に「歯磨き粉A」を「2」個「800」円で購入していると分かる。同様に氏名「田中一郎」なる顧客は、「2012年6月1日」に「歯ブラシB」を「1」個「700」円で、「2012年7月1日」には「歯磨き粉B」を「2」個「900」円で購入していると分かる。
従来の正規化構造は、このようにして、上位の情報と下位の情報を別のテーブルとして管理する。そして、下位の情報テーブルに格納した各データには、対応する上位の情報テーブルのデータの識別IDを保持させる構造をとる。つまり、下位の情報テーブルのデータに、上位の情報テーブルのデータとの紐付け情報を保持させることにより、階層化されたデータ構造を表現していたのである。
しかし、このような方法によってデータ階層を表現しようとすれば、データベースシステムのプログラムは、上位の情報テーブルと下位の情報テーブルを連携して一体的に取り扱わなければならなくなり、設計に当たって様々な困難が生じることになる。
例えば、新規データ登録時に、なんらかのシステムトラブルにより、下位の購入履歴テーブルに対するデータ登録には成功したが、上位の顧客テーブルに対するデータ登録には失敗してしまったとする。このような場合、顧客情報に紐づかない購入履歴情報が存在してしまうことになり、データ構造に矛盾が起きてしまう。よって、通常のデータベースシステムでは、片方のテーブルに対する登録処理が失敗した場合には、いったん他方のテーブルに対する成功した登録処理をロールバックして元の状態に戻し、改めて両方のテーブルに対する登録処理をやり直す、という処理を実装しておく。また、この処理が完了するまで、他のユーザがテーブル操作を行えないよう、テーブル操作をロックする、という処理を実装しておく。しかし、これらの処理は、データの階層構造が増えるほど複雑になり、また、テーブル操作のロックは、システム全体の機能を停止しかねない危険な行為でもあるので、ベテランの技術者が設計を行わねばならないものであった。
また、複数のテーブルをIDによって紐付けて操作する場合、紐付け用のIDに対してインデックスを設定するなど、データベースをチューニングしなければ十分なパフォーマンスを発揮させることができない。しかし、このインデックスの貼り方も、インデックスを大量に貼りすぎれば、逆にパフォーマンスが低下してしまうこともあり、階層構造の多いデータベースに対するチューニングは熟練の技術を要するものだった。
対して、本発明では、データの管理単位ごと又はデータの階層ごとにテーブルを作成することはしない。あらかじめ用意された質問フォーム定義テーブルと回答データテーブルのみで、すべてのデータ構造に対応する。以下、本発明のデータ構造について説明する。
図4aは、質問フォーム定義テーブルの概要設計を示したものである。この質問フォーム定義情報は、従来のデータ構造にはないものであり、あえて従来のデータ構造に対応づけるならば、テーブル構造についての情報、すなわち、データ構造を定義するメタデータであると言える。
質問フォーム定義テーブルは、少なくとも「レコードID」格納列、「タグ」格納列および「質問階層情報」格納列の三つの列から構成される。「レコードID」は、テーブル内のレコードの識別番号としてのIDであり、システム内のデータ管理のための情報である。「タグ」には、「質問階層タグ」および「質問タグ」の2種類がある。従来の正規化されたデータ構造で言えば、「質問階層タグ」は「テーブル名」、「質問タグ」は「列名」にあたると言うこともできる。すなわち、従来のテーブル名である「購入履歴」や従来の列名である「商品名」および「数量」などがここに格納される。「質問階層情報」は、上位階層の質問階層タグが格納された「レコードID」である。これは言わば、同じ質問フォーム定義テーブルの中に存在する上位階層情報と下位階層情報を紐付けるための情報である。以下、具体例を用いて説明する。
図5aは質問フォーム定義テーブルの内容の具体例を示したものである。これは、上記従来の正規化された顧客テーブルおよび購入履歴テーブルと同じデータ階層構造を表現している。「レコードID」格納列には、テーブル内のレコードの識別番号「1」から「9」が格納されている。
「タグ」格納列には、質問階層タグ、すなわち従来で言えば、テーブル名として、レコードID「1」のレコードには「顧客」が、レコードID「5」のレコードには「購入履歴」が格納されている。また、レコードID「2」から「4」のレコードには、顧客テーブルの列名に当たる情報が、レコードID「6」から「9」のレコードには、購入履歴テーブルの列名に当たる情報がそれぞれ格納されている。
「質問階層情報」格納列には、自らの上位階層を示す情報として、レコードID「2」から「5」のレコードに、質問階層タグ「顧客」のレコードID「1」が、レコードID「6」から「9」のレコードには、質問階層タグ「購入履歴」のレコードID「5」が、格納されている。
図6aは、上記質問フォーム定義テーブルの内容を展開したものである。質問階層タグ「顧客」の下位に、質問タグである「氏名」、「カナ」、「住所」、および質問階層タグである「購入履歴」の情報が紐づき、さらに当該「購入履歴」の下位に質問タグ「商品名」、「数量」、「金額」、「購入年月日」が紐づいていることが分かる。質問階層タグを従来のテーブル名、質問タグを従来の列名と考えると、上記展開された階層構造は、従来の正規化された構造と同様の構造を表現しているものである。
次に、回答データテーブルについて説明する。図4bは、回答データテーブルの概要設計を示したものである。この回答データは、従来のデータ構造におけるデータの中身に当たる。ただし、従来のデータ構造においては、「顧客」、「購入履歴」など異なるデータ集合に属するデータは、異なるテーブルに格納しており、さらに同じデータ集合内でも「氏名」、「住所」など異なる種別のデータは異なる列に格納していたが、回答データテーブルでは、すべて一つの列に格納する点で大きく相違する。
回答データテーブルは、少なくとも「レコードID」格納列、「回答データ」格納列、「回答データ階層情報」格納列および「質問テーブル紐付け情報」格納列の四つの列から構成される。「レコードID」は、テーブル内のレコードの識別番号としてのIDであり、システム内のデータ管理のための情報である。「回答データ」には、2種類の情報が格納される。質問フォーム定義テーブルの質問タグに対する回答データおよび、質問階層タグに対する回答データ階層タグである。「回答データ階層情報」は、上位階層の回答データ階層タグが格納された「レコードID」である。これは言わば、同じ回答データテーブルの中に存在する上位階層情報と下位階層情報を紐付けるための情報である。「質問テーブル紐付け情報」は、回答データおよび回答データ階層タグに対応する質問タグおよび質問階層タグのレコードIDである。以下、具体例を用いて説明する。
図5bは回答データテーブルの内容の具体例を示したものである。これは、上記質問フォーム定義テーブルの具体例と対応しているものである。「レコードID」格納列には、テーブル内のレコードの識別番号「1」から「28」が格納されている。
「回答データ」格納列には、質問フォーム定義テーブルの質問タグに対する回答データおよび、質問階層タグに対する回答データ階層タグが格納されている。例えば、レコードID「2」から「4」の「山田太郎」「ヤマダタロウ」および「東京都千代田区XXX」は、質問フォーム定義テーブルにおける質問タグ「氏名」、「カナ」および「住所」に対する回答データである。また、レコードIDである「1」の「顧客」は、質問フォーム定義テーブルにおける質問階層タグ「顧客」に対応する回答データ階層タグである。なお、レコードID「15」においても回答データ階層タグ「顧客」が格納されている、これはレコードID「1」とは別の顧客を表しているものである。すなわちレコードID「1」には、氏名「山田太郎」なる顧客の情報が紐づいており、レコードID「15」には、氏名「田中一郎」なる顧客の情報が紐づいている。同一の回答データ階層タグは、従来の正規化されたデータ構造のテーブルで言えば、レコードの数だけ存在することになる。
「回答データ階層情報」格納列には、自らの属する階層を示す情報が格納されている。例えば、レコードID「2」から「4」の氏名「山田太郎」なる顧客に係る情報を格納したレコードには、回答データ階層タグ「顧客」のレコードID「1」が格納されている。また、レコードID「6」から「9」の商品名「歯ブラシA」の購入履歴に係る情報を格納したレコードには、回答データ階層タグ「購入履歴」のレコードID「5」が格納されている。そして、この回答データ階層タグ「購入履歴」のレコードには、上位階層の回答データ階層タグ「顧客」のレコードID「1」が格納されている。なお、レコードID「1」および「15」の「回答データ階層情報」格納列には「0」が格納されている。これはレコードID「1」および「15」が最上位の階層であることを示している。
「質問テーブル紐付け情報」格納列には、回答データおよび回答データ階層タグに対応する質問タグおよび質問階層タグのレコードIDが格納されている。例えば、レコードID「1」および「15」の回答データ階層タグ「顧客」には、質問フォーム定義テーブルにおける質問階層タグ「顧客」のレコードIDである「1」が紐付けられている。また、レコードID「2」から「4」の「山田太郎」「ヤマダタロウ」および「東京都千代田区XXX」は、質問フォーム定義テーブルにおける質問タグ「氏名」、「カナ」および「住所」のレコードIDである「2」、「3」および「4」がそれぞれ格納されている。レコードID「16」から「18」の「田中一郎」、「タナカイチロウ」および「東京都文京区XXX」についても同様である。
図6bは、回答データテーブルの内容を展開したものである。すなわち、氏名「山田太郎」なる顧客は、「2012年7月1日」に「歯ブラシA」を「2」個「1200」円で、同じく「2012年7月1日」に「歯磨き粉A」を「2」個「800」円で購入していると分かる。同様に氏名「田中一郎」なる顧客は、「2012年6月1日」に「歯ブラシB」を「1」個「700」円で、「2012年7月1日」には「歯磨き粉B」を「2」個「900」円で購入していると分かる。このように、展開された階層構造は、従来の正規化された構造と同様の構造を表現しているものである。
このように、本発明のデータ構造は、従来の正規化されたデータ構造と根本的に異なる構造であるにも関わらず、従来の正規化されたデータ構造を正確に置き換えて再現することが可能である。しかも、データの管理単位ごと又はデータの階層ごとにテーブルを作成することはせず、あらかじめ用意された質問フォーム定義テーブルと回答データテーブルのみで、すべてのデータ構造に対応するため、従来の様々な問題を解決しているものである。
本発明の基本的なデータ構造の説明は以上である。以降は当該データ構造を踏まえたうえでの本実施形態の処理フロー、すなわち、質問フォームをデザインしてシステムを生成するフローについての説明をするものとする。
図7は質問フォームをデザインしてシステムを生成するフローを示したものである。本実施形態では、ユーザはまず、質問フォームの新規作成処理を行い、デザイン対象となる質問フォームのデザイン画面を表示する。なお、この質問フォームにはユーザが自由に名称を設定できるようにする。この名称は内部データ的には質問階層タグとして扱われるため、設定は必須とする。
図8が、本実施形態における質問フォームデザイン画面の一例である。この質問フォームデザイン画面は、入力領域オブジェクトを選択するための入力領域オブジェクト選択パレット(0802)と、入力領域オブジェクトを配置するための質問フォームデザインキャンバス(0801)からなる。ユーザはマウス操作によって、入力領域オブジェクト選択パレット(0802)から、配置すべき入力領域オブジェクトを選択する。そして選択した入力領域オブジェクトを質問フォームデザインキャンバス(0801)に配置することにより、質問フォームをデザインする。
配置した各入力領域オブジェクト(例:0803)にはラベルを自由に設定できる。このラベルとは、入力領域に対してどのような情報を入力すべきかを表示するものであり、例えば「住所」の入力領域には、「住所」などが設定されるべきものである。なお、このラベルは内部データ的には質問タグとして扱われるため、設定は必須とする。
下位階層のフォームを作成したいときは、デザイン画面の質問フォームデザインキャンバス(0802)のいずれかの場所をクリックする。これにより、下位階層のフォームとして、新しいデザイン画面が開く。この新しいデザイン画面には、属性情報として、元のデザイン画面のフォーム名称、すなわち上位階層の質問階層タグが保持されている。これはフォームの階層関係を明らかにするために必要だからである。
下位階層のフォームとして新しく開いたデザイン画面においては、上位階層フォームとまったく同じ操作が可能となっている。ユーザは入力領域オブジェクトを自由に配置することができるし、好きなだけさらに下位の階層フォームを作成することもできる。このような仕組みにより、ユーザは一切の制約なく、複雑な階層構造を有する質問フォームをデザインすることが可能となるのである。
質問フォームのデザイン情報をサーバ装置に受け渡す方法は、デザインに変更を加えるたびにリアルタイムでデータのやりとりを行う方法でもよいし、フォーム上に一時的にデータを保持しておき、登録ボタンの押下などによって、まとめてサーバ装置に送信する方法でもよい。いずれの方法を採用した場合でも、基本的には、以下に説明する方法で必要なデータ処理が可能である。
質問フォームのデザイン情報を受け取ったサーバ装置は、質問フォーム定義テーブルに質問フォーム定義情報を格納する。前述の通り、質問フォームデザイン情報には、質問フォームを定義するための質問タグ(入力領域のラベル)および質問階層タグ(質問フォームの名称)の情報が埋め込まれている。したがって、質問フォームのデザイン情報は、質問タグと質問階層タグからなる階層構造に容易に変換できる。
例えば、まず、質問フォームの名称として設定されている質問階層タグを、質問フォームのデザイン情報の中から抽出する。さらに、下位の階層フォームについては、上位階層のフォーム名称、すなわち上位階層の質問階層タグが埋め込まれているのでこれもあわせて抽出する。そして、この上位階層の質問階層タグ情報を用いて、質問階層タグ同士を上位下位の関係で紐付け、質問階層タグの階層構造を作成しておく。
次に入力領域オブジェクトのラベルとして設定されている各質問タグを、質問フォームのデザイン情報の中から抽出する。そして、これら各質問タグを、入力領域オブジェクトが配置されている質問フォームの名称である質問階層タグに紐付ける。これで各質問タグと質問階層タグとが紐づけられた構造が作成される。最後に上記質問階層タグの階層構造と、当該各質問タグと質問階層タグとが紐づけられた構造をマージすることにより、質問タグと質問階層タグからなる階層構造が完成する。あとは、完成した階層構造を通常のデータベース機能によって質問フォーム定義テーブルに格納すればよい。
データ格納後は、質問フォーム定義情報に基づいて、システム使用端末に表示するための質問フォーム画面を作成する。ただし、本実施形態が生成するデータベースシステムはWEBシステムであるため、必ずしもこの時点で画面を作成しておく必要はなく、システム使用のリクエストがあるたびに、質問フォーム定義テーブルの情報を参照し、リアルタイムに質問フォーム画面を作成するようにしてもよい。
以下、あらかじめ質問フォーム画面を作成しておく場合について簡単に説明する。本実施形態が生成するデータベースシステムはWEBシステムであるため、質問フォームはHTMLタグ又はスクリプトのコンポーネント等のソースコードをブラウザが読み込んで解釈することにより、ブラウザの機能によって表示される。
したがって、質問フォーム画面を作成するに当たっては、ベースとなる質問フォームテンプレートに、入力データ領域を生成するための、HTMLタグ又はブラウザが解釈可能なスクリプトのコンポーネント等のソースコードを追記する方法をとる。例えば、テキスト入力フィールドを表示するためのHTMLタグを、テンプレート内に追記する。
この際には、各入力領域の配置情報を、属性情報としてHTMLタグ又はブラウザが解釈可能なスクリプトのコンポーネント等に付加しておくことより、デザインされた通りの配置を再現できるようにする。さらには、入力領域の付近にラベルを表示するようにし、回答データに対する紐付け情報としての質問タグを埋め込んでおく。
フォームの階層表現について補足しておくと、下位階層フォームを、上位階層フォームの中に埋め込んでもよいし、上位階層フォームには下位階層フォームを開くためのボタンだけを配置し、それをクリックすると別画面で下位階層フォームが開くようにしてもよい。下位階層フォームを、上位階層フォームに埋め込む場合はHTMLタグ又はブラウザが解釈可能なスクリプトのコンポーネントのコード等を入れ子状に配置すればよいし、上位階層フォームと下位階層フォームを分ける場合には、別々のフォームとして作成し、リンクをはればよい。ただし、いずれの場合にも、データ受取時において、回答データの階層が明確となるように、下位階層のフォームには対応する質問階層タグを属性情報として埋め込んでおくことが必要である。
作成された質問フォーム画面は、質問フォーム定義情報と紐付けてサーバ装置の質問フォーム画面格納領域に格納しておく。このようにして、システム使用端末からの質問フォーム使用のリクエストに迅速に答えられるようにする。
最後に、本実施形態においては、質問フォームごとに個別のデータ処理プログラムを生成することはしない。前述の通り、本発明は回答データテーブルと質問フォーム定義テーブルのみからなる。あらゆる質問フォームに対するデータ処理が共通のプログラムによって可能となるため、データベースシステムはあらかじめ準備された当該共通のプログラムを使用すればよいのである。
念のため、上記共通のプログラムについて簡単に説明しておく。前述の通り、質問フォーム画面には、質問タグおよび質問階層タグが埋め込まれているため、システム使用ユーザから返信されてくる回答データは、必然的に質問タグおよび質問階層タグと紐づいていることになる。したがって、上記共通のプログラムは、質問タグおよび質問階層タグに係る階層情報を用いることにより、容易に回答データ階層タグを作成し、回答データを階層化することができる。
例えば、まず、質問フォームに埋め込まれている質問階層タグを抽出する。下位の階層フォームについては、上位階層の質問階層タグが埋め込まれているのでこれもあわせて抽出する。そして、この上位階層の質問階層タグ情報を用いて、質問階層タグ同士を上位下位の関係で紐付け、質問階層タグの階層構造を作成しておく。本実施形態では回答データ階層タグは質問階層タグと同じデータで構わないので、上記質問階層タグの階層構造をそのまま回答データ階層タグの階層構造として用いて構わない。
次に回答データを、入力領域オブジェクトに埋め込まれている質問タグとセットで抽出する。そして、これら回答データと質問タグのセットを、質問フォームに埋め込まれている質問階層タグに紐付ける。これで各回答データおよび質問タグと、質問階層タグとが紐づけられた構造が作成される。最後に上記質問階層タグの階層構造(すなわち、回答データ階層タグの階層構造)と、当該各回答データ及び質問タグと質問階層タグとが紐づけられた構造をマージすることにより、回答データの階層構造が完成する。
あとは、上記階層化された各回答データに、ユニークな番号を与えてレコードIDとし、データ間の階層関係を当該レコードIDに置きかえて回答データ階層情報とし、さらに質問タグおよび質問階層タグのIDを質問テーブル紐付け情報とすれば、回答データテーブルに格納できるデータとなる。そして最後に、当該データを通常のデータベース機能によって回答データテーブルに格納すればよいのである。
本実施形態の機能的構成に関する説明は以上で終了とする。ただし、上記説明においては本発明の実施に必要な機能的構成を説明したものであり、本構成に当業者にとって当然の機能の追加、改良を行ってよいことは当然である。例えば質問フォームのデザインを修正するための機能を有してもよいし、質問フォームに対する回答データを修正するための機能を有してもよい。また、ユーザ管理のためのユーザテーブルを有してもよいし、ユーザのログイン画面を有してもよい。また、質問フォーム定義テーブルに、入力領域の入力制限や入力ルールを格納する列を増やしてもよいし、質問フォームのデザインに関する付属情報、例えば入力領域の配置場所、サイズ、表示形式、色を格納する列を増やしてもよい。もちろんこれらの情報は別テーブルで管理することとしてもよい。回答データテーブルおよび質問フォーム定義テーブルにインデックスを張ってもよいことは当然であるし、また、回答データテーブルの回答データ格納列や質問フォーム定義テーブルのタグ格納列は必ずしも1列で構成する必要はなく、例えば回答データと回答データ階層タグを別の列に格納するように2列で構成してもよい。さらには、回答データ階層タグや質問階層タグはIDのみで表現することとし、タグを空文字として設定することにしてもよい。このほか、本構成には、当業者にとって当然のあらゆる機能の追加、改良を行ってよいことは当然である(以降に列記する他の実施形態についても同様)。
<効果>
主に以上のような構成をとる本実施形態によって、ユーザは一切の制約なく簡単なGUI操作のみで、自由にデータベースシステムを構築できる。また、システム運用の途中でデータベース構造を変更する必要が生じた場合でも、システム運用を停止することなく、データコンバート処理を行うことなく、即座に必要な変更を反映することができる。さらには、XMLデータベースを用いた場合の様な、パフォーマンスの低下が起こることもなく、リレーショナルデータベース特有の高度なレプリケーション機能やクラスタリング機能を活用することができる。
<<実施形態2>>
<概要>
本実施形態は、実施形態1の構成に加え、質問タグに他の質問タグを紐付ける手段を有することにより、当該質問タグに対する回答を、当該他の質問タグに対する回答データの中から選択可能とした質問フォームを生成することができるデータベースシステム生成装置に係るものである。
<機能的構成>
本実施形態においては、質問フォームデザイン画面において、リストボックス、ラジオボタン、あるいは選択用サブウィンドウなどの選択式入力領域オブジェクトが配置できるようになっている。そして、この選択式入力領域オブジェクトには、表示すべき選択肢として、他の質問フォームの回答データを指定することができる。
ここで、他の質問フォームの回答データとは、例えば、質問フォーム「商品マスタ」の質問「商品名」に対する回答データである。すなわち、この選択式入力領域オブジェクトを使用するためには、あらかじめ「商品マスタ」のような質問フォームを作成しておく必要がある。そして、この商品マスタに商品名「歯ブラシA」「歯ブラシB」などを登録しておくと、これらのデータが当該選択式入力領域の選択肢として表示されるようになるのである。
質問フォームデザイン画面上の選択式入力領域オブジェクトには、上記回答データの参照先を示す情報である質問タグのレコードID(例えば、質問フォーム「商品マスタ」の質問「商品名」に対する回答データを表示する場合は、「商品名」の質問タグのレコードID)が保持される。この質問タグのレコードIDは、質問フォームのデザイン情報登録の際に、質問フォームデザイン情報と共にサーバ装置に送信される。
質問フォームデザイン情報と上記質問タグのレコードIDを受け取ったサーバ装置は、これらを一体として、質問フォーム定義テーブルに格納する。すなわち、図9にあるように、本実施形態においては、質問フォーム定義テーブルが「参照質問タグ情報」格納列を有している。ここに上記質問タグのレコードIDを合わせて格納することにより、質問フォーム定義情報が質問タグのレコードIDに紐づけられた状態で格納されるのである。このような構成をとることにより、選択式入力領域オブジェクトは、常に上記質問タグに対する回答データと連携できるようになる。例えば、上記質問タグについての回答データに登録、修正があれば即座に当該選択式入力領域オブジェクトの選択肢も追加、修正されるようになる。
最後に、本実施形態では、選択式入力領域に常に最新の選択肢を表示できるように質問フォーム画面を生成する。これを実現するためには、さまざまな方法を用いて構わない。例えば、選択式入力領域を表示するためのブラウザが解釈可能なスクリプトのコンポーネントに参照先の質問タグIDを保持しておいて、システム使用端末から常に当該質問タグIDと紐づけられた回答データを取得するようにしてもよいし、システム使用端末から質問フォームの使用リクエストがあるたびに、サーバ装置側で表示選択肢を作成し直すようにしてもよい。さらには、マスタ更新のたびにサーバ装置側で表示選択肢を作成し直すようにしてもよい。
<効果>
主に以上のような構成をとる本実施形態によって、選択形式の入力領域を含む質問フォームを作成できるようになる。入力領域が選択形式であれば、システム使用者のデータ入力の手間を大幅に削減することができるし、タイプミスなどの入力ミスを減らすこともできる。さらに本実施形態においては、選択肢自体が質問フォームから登録・編集できるようになっているため、いわゆるマスタテーブルとして使用することができ、極めて便利である。
<<実施形態3>>
<概要>
本実施形態は、実施形態1および2の構成に加え、質問タグ又は質問階層タグにシステム識別情報を紐付ける手段を有することにより、複数のデータベースシステムを単一の質問フォーム定義テーブルおよび単一の回答データテーブルで管理可能となるように生成することができるデータベース自動生成システムに係るものである。
<機能的構成>
図10は、本実施形態のシステム生成フローである。すなわち、本実施形態では、ユーザは、まずシステムの登録を行う。一度登録されたシステムは、システム生成画面の端末に一覧表示されるようになり、以後はシステムを選択してから、質問フォーム画面をデザインすることになる。質問フォームデザイン画面には、選択したシステムのシステムIDが埋め込まれており、質問フォームのデザイン情報登録の際に、質問フォームデザイン情報と共にサーバ装置に送信される。
質問フォームデザイン情報と上記システムIDを受け取ったサーバ装置は、これらを一体として、質問フォーム定義テーブルに格納する。すなわち、図11にあるように、本実施形態においては、質問フォーム定義テーブルが「システム識別情報」格納列を有している。ここに上記システムIDを合わせて格納することにより、各質問フォーム定義情報がシステムIDを紐づけられた状態で格納されるのである。このような構成をとることにより、単一の質問フォーム定義テーブルによって、複数のシステムの質問フォームが定義できるようになる。また、質問フォーム定義情報と紐付けられている回答データについても、質問フォーム定義情報を通して、結果的にシステムIDと紐づけられるため、単一の回答データテーブルで複数のシステムの回答データを管理できるようになる。
最後に、本実施形態では、システム使用者が複数のシステムに区別的にアクセスできるように、ログイン先システム選別処理をデータベースシステムに付加する。このログイン先システム選別処理には、さまざまな方法を用いて構わない。すなわちシステム一覧を表示しユーザに選択させるようにしてもよいし、あるいは、別途にログイン権限管理用のユーザテーブルを設け、このユーザにシステムIDを紐付けることによってログイン先のシステムを変更するようにしてもよい。さらに、システムごとに異なるURLのログイン画面を生成するようにしてもよい。
<効果>
主に以上のような構成をとる本実施形態によって、まったくデータ構造の異なる情報を管理する複数のシステムを、単一のデータベースによって運用することができるようになる。このことにより、システム運用の管理コストを大幅に削減できることができる。さらには、近年課題となっている複数のシステムに渡るデータの統合的な管理も可能となり、一石二鳥である。特にクラウド上で多数のユーザを対象として何種類ものカスタマイズされたシステム運用を行う場合などは、これらの効果がより顕著に表れると言える。
<<実施形態4>>
<概要>
本実施形態は、実施形態1乃至3の構成に加え、指定した質問タグ又は質問階層タグに対応する回答データ又は回答データ階層タグの一覧、集計結果またはXML形式データを入出力する手段を有するデータベースシステム生成装置に係る。
<機能的構成>
本実施形態においては、サーバ装置は、以下の三つのプログラムを有する。すなわち、第一に指定した質問タグ又は質問階層タグに対応する回答データ又は回答データ階層タグの一覧を出力することができるプログラムであり、第二に指定した質問タグ又は質問階層タグに対応する回答データ又は回答データ階層タグを集計して出力することができるプログラムであり、第三に回答データ又は回答データ階層タグをXML形式データとして入出力することができるプログラムの三つのプログラムである。
これらのプログラムについては、システム設計端末からのみ利用できるような構成にしてもよいし、システム設計端末とシステム使用端末の両方で利用できるような構成にしてもよい。さらには、システム使用端末での使用を、システム設計端末から一部許可できるような構成にしてもよい。例えば、プログラムごとに利用を許可できようにしてもよいし、質問階層タグおよび質問タグごとに利用を許可できるようにしてもよい。さらには別途ユーザテーブルを用いて、ユーザごとに使用できる機能を変更できるようにしてもよい。いずれにしても、この三つのプログラムは、あらゆる構造の回答データに対応することができるため、利用の可否設定を変更するだけで、いつでもデータベースシステムに機能追加できるものである。以下、上記三つのプログラムの処理について簡単に説明する。
指定した質問タグ又は質問階層タグに対応する回答データ又は回答データ階層タグの一覧を出力することができるプログラムの処理について簡単に説明すると以下の通りである。
本プログラムでは、まず、質問タグを指定されたか、質問階層タグを指定されたかを判別し処理を分岐させる。質問タグが指定されたと判別された場合、単純に当該質問タグに紐付けられている回答データを抽出し、システム使用端末に送信すればよい。一方、質問階層タグが指定されたと判別された場合は、まず、当該質問階層タグに紐付けられている回答データ階層タグを抽出し、次に、回答データ階層タグごとに、当該回答データ階層タグに紐づけられている各回答データを抽出しリスト化する。最後に完成したリストをシステム使用端末に送信すればよい。
指定した質問タグ又は質問階層タグに対応する回答データ又は回答データ階層タグを集計して出力することができるプログラムの処理について簡単に説明すると以下の通りである。
本プログラムでは、まず、質問タグを指定されたか、質問階層タグを指定されたかを判別し処理を分岐させる。質問タグが指定されたと判別された場合、単純に当該質問タグに紐付けられている回答データを抽出し、これらを足し合わせるなどの演算を行った結果をシステム使用端末に送信すればよい。一方、質問階層タグが指定されたと判別された場合は、まず、当該質問階層タグに紐付けられている回答データ階層タグを抽出し、次に、回答データ階層タグごとに、当該回答データ階層タグに紐づけられている各回答データを抽出しリスト化する。さらに、当該リストについて、分類に用いるべき回答データごとに、演算対象となる回答データを足し合わせるなどの演算を行う。最後に演算結果のリストをシステム使用端末に送信すればよい。なお、本プログラムについては、分類に用いるべき回答データと、演算対象の回答データが識別可能である必要があるが、その識別方法についてはさまざまな方法を用いてよい。例えば、あらかじめ質問定義テーブルにおいて質問タグごとに定義しておいても良いし、プログラムの実行の都度ユーザが選択できるようにしてもよい。
回答データおよび回答データ階層タグをXMLとして入出力するプログラムの処理について簡単に説明すると以下の通りである。
まず、出力の場合について説明すると本プログラムでは、回答データテーブルのデータを取り出し、回答データ階層情報を用いて回答データの上位下位を結びつけ、各データの階層情報を整理する。次に、適切な形式に変換した質問タグで各回答データを挟み込む。例えば回答データが「歯ブラシA」で対応する質問タグが「商品名」だったら「<商品名>歯ブラシA</商品名>」などとする。この形式のデータは回答データ階層タグごとにまとめておく。そして、適切な形式に変換した質問階層タグで、上記まとめた各データを挟み込む。これにより、例えば図12のようなXMLファイルが完成する。あとはこの完成したXMLファイルをシステム使用端末に送信すればよい。
次に、入力の場合について説明すると、だいたい出力の場合と同様の手順を取ればよい。すなわち、まず入力されたXMLデータの回答データ階層タグを識別し、回答データ階層タグの位置関係から、各データの階層情報を整理する。次に、回答データ階層タグに挟み込まれた質問タグと回答データ、例えば「<商品名>歯ブラシA</商品名>」などを抽出し、質問タグ「商品名」と回答データ「歯ブラシA」に分解する。最後に、各回答データ階層タグおよび各回答データのレコードIDを取得し、さらに回答データ階層情報や質問タグなどの情報をIDに変換して、回答データ格納テーブルに格納すればよい。
<効果>
主に以上のような構成をとる本実施形態によって、ユーザは回答データテーブルに蓄積されたデータを有効に活用できる。また、さまざまな形式でデータ出力が可能となることにより、他のアプリケーションソフト、例えば、統計分析用のソフトなどとの連携も容易となる。
最後に、実施形態1乃至4のサーバ装置のハードウェアおよびソフトウェア構成についてその一例を示す。なお、これは実施形態1乃至4のサーバ装置を、いかにプログラムによって動作させるかという観点から説明するものでもある。
図13がその一例の概要図である。すなわち、実施形態1乃至4のサーバ装置のハードウェアは主に、CPU、RAM(一時メモリ)、HDDおよびUSBポートやCOMポート、LANポートなどの入出力インターフェースから構成され、ソフトウェアは、RAM上に展開された各プログラム、およびこれらのプログラムからアクセス可能なHDD上のデータベースによって構成される。また、LANポートなどの入出力インターフェースにはネットワークを通じてクライアント端末が接続されており、各種プログラムとクライアント端末との連携が可能となっている。
各プログラムの機能を簡単に説明すると、まず、「質問フォームデザイン情報受信プログラム」は、入出力インターフェースを通して送信されてくる質問フォームのデザイン情報を受信するステップを構成する。また、「質問フォーム定義情報作成プログラム」は、当該質問フォームのデザイン情報から、質問フォーム定義情報を作成するステップを構成する。 「質問フォーム定義情報格納プログラム」は当該質問フォーム定義情報をHDD上の質問フォーム定義テーブルに格納するステップを構成する。
「質問フォーム画面作成プログラム」は、上記質問フォーム定義テーブルに対応する質問フォーム画面を作成するステップを構成する。また、「質問フォーム画面出力プログラム」は、当該作成された質問フォーム画面を、入出力インターフェースを通して出力するステップを構成する。
「回答データ受信プログラム」は、上記質問フォーム画面に対する回答データを受信するステップを構成する。また、「回答データ格納プログラム」は、当該回答データを回答データテーブルに格納するステップを構成する。そして、「回答データ一覧出力プログラム」「回答データ集計結果出力プログラム」「回答データXML出力プログラム」は、それぞれリクエストに応じて、回答データの一覧、集計結果、XML形式のデータを出力するステップを構成する。