JP2004246755A - データベースシステムの設計装置 - Google Patents
データベースシステムの設計装置 Download PDFInfo
- Publication number
- JP2004246755A JP2004246755A JP2003037756A JP2003037756A JP2004246755A JP 2004246755 A JP2004246755 A JP 2004246755A JP 2003037756 A JP2003037756 A JP 2003037756A JP 2003037756 A JP2003037756 A JP 2003037756A JP 2004246755 A JP2004246755 A JP 2004246755A
- Authority
- JP
- Japan
- Prior art keywords
- template
- field
- customization
- tables
- database system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】データベース設計の作業労力を軽減する。
【解決手段】所定の基本フィールドの構造を定義した情報からなる雛形テーブルＡ〜Ｃを複数種類格納した格納手段１０を用意しておき、雛形テーブル選択手段２０によって任意の雛形テーブルを選択する。雛形テーブルの基本フィールド間には、必要なリレーションシップも定義しておく。カスタマイズテーブル作成手段３０を用いて、必要に応じて、選択した雛形テーブルＡに対するカスタマイズを行い、カスタマイズテーブルＡＡを作成する。カスタマイズは、追加フィールドＸ１の付加や、基本フィールドの構造修正によって行う。データベース構築手段４０は、こうして得た雛形テーブルやカスタマイズテーブルを組み合わせることにより、データベースＤＢを構築する。
【選択図】 図３
【解決手段】所定の基本フィールドの構造を定義した情報からなる雛形テーブルＡ〜Ｃを複数種類格納した格納手段１０を用意しておき、雛形テーブル選択手段２０によって任意の雛形テーブルを選択する。雛形テーブルの基本フィールド間には、必要なリレーションシップも定義しておく。カスタマイズテーブル作成手段３０を用いて、必要に応じて、選択した雛形テーブルＡに対するカスタマイズを行い、カスタマイズテーブルＡＡを作成する。カスタマイズは、追加フィールドＸ１の付加や、基本フィールドの構造修正によって行う。データベース構築手段４０は、こうして得た雛形テーブルやカスタマイズテーブルを組み合わせることにより、データベースＤＢを構築する。
【選択図】 図３
Description
【０００１】
【発明の属する技術分野】
本発明はデータベースシステムの設計装置に関し、特に、複数のテーブルから構成されるリレーショナル型データベースシステムを設計する装置に関する。
【０００２】
【従来の技術】
現在、様々な分野におけるデータ管理に、データベースシステムが導入されており、大小様々な規模のデータベースシステムが稼働している。特に、一般的な事務処理には、レコードとフィールドとによって構成されるテーブル形式でデータを取り扱うリレーショナル型データベースが広く利用されており、通常、複数のテーブルによってデータベースシステムの構築が行われる。たとえば、個々の顧客ごとの売上を管理するデータベースシステムの場合、顧客となる企業名、住所、電話番号、担当者名などを管理する顧客情報テーブルと、売上伝票に掲載される日付、販売商品名、個数、単価、売上額などを管理する売上情報テーブルと、によってデータベースを構築することができる。
【０００３】
多くのソフトハウスは、クライアント企業から、所望のデータベースシステムの受注を受け、当該クライアント企業の業務形態に合致したオーダーメイドのデータベースシステムを設計する作業を行っている。また、このような設計作業の労力を軽減するための効率的なデータベースの構築方法や設計装置などが提案されている。たとえば、下記の特許文献１には、固有のプロセスを用いたデータベースの構築方法が開示されており、特許文献２には、データベースの管理システムが開示されている。
【特許文献１】
特開平５−０２７９６０号公報
【特許文献２】
特開平９−１６７１１３号公報
【０００４】
【発明が解決しようとする課題】
上述したように、レコードとフィールドとによって構成されるテーブル形式でデータを取り扱うリレーショナル型データベースは、種々の事務処理で広く利用されているデータベースであるが、特定の企業の業務形態に合致したオーダーメイドのデータベースシステムを設計するには、多大な労力と時間を要するのが実情である。これは、個々の企業の業務形態は千差万別であるため、オーダーメイドのデータベースシステムを受注した場合には、受注先である特定の企業の特定の業務形態に最適なテーブルを設計する必要があり、しかも、個々のテーブルを設計する際には、各フィールドの構造を定義するとともに、フィールド間のリレーションシップの定義を行わねばならないためである。
【０００５】
そこで本発明は、設計作業の労力をできるだけ軽減することが可能なデータベースシステムの設計装置を提供することを目的とする。
【０００６】
【課題を解決するための手段】
（１） 本発明の第１の態様は、複数のテーブルから構成されるデータベースシステムを設計するデータベースシステムの設計装置において、
所定の基本フィールドの構造を定義した情報からなる雛形テーブルを複数種類格納した雛形テーブル格納手段と、
この雛形テーブル格納手段から、設計者の指示に基づいて、所定の雛形テーブルを選択する雛形テーブル選択手段と、
この雛形テーブル選択手段によって選択された雛形テーブルに対して、設計者の指示に基づいて、所定の追加フィールドの構造を定義する情報を付加することにより、基本フィールドと追加フィールドとの双方の構造を定義した情報からなるカスタマイズテーブルを作成するカスタマイズテーブル作成手段と、
雛形テーブル選択手段によって選択された雛形テーブルもしくはカスタマイズテーブル作成手段によって作成されたカスタマイズテーブルを、設計対象となるデータベースシステムを構成する実テーブル群として用い、データベースを構築するデータベース構築手段と、
を設けるようにしたものである。
【０００７】
（２） 本発明の第２の態様は、上述の第１の態様に係るデータベースシステムの設計装置において、
雛形テーブル格納手段内に格納されている複数種類の雛形テーブル間に、予め所定のリレーションシップを定義しておくようにしたものである。
【０００８】
（３） 本発明の第３の態様は、上述の第１または第２の態様に係るデータベースシステムの設計装置において、
カスタマイズテーブル作成手段が、雛形テーブル選択手段によって選択された雛形テーブルの基本フィールドに対して、設計者の指示に基づいて、構造の修正を行うことにより、カスタマイズテーブルを作成する機能を有するようにしたものである。
【０００９】
（４） 本発明の第４の態様は、上述の第３の態様に係るデータベースシステムの設計装置において、
基本フィールドに対する構造修正に制限を設け、設計者から、この制限の許容範囲外の修正指示が与えられた場合には、当該指示が無視されるようにしたものである。
【００１０】
（５） 本発明の第５の態様は、上述の第１〜第４の態様に係るデータベースシステムの設計装置において、
１つもしくは複数の雛形テーブルを包含するグループを定義し、雛形テーブル選択手段が、グループ単位で雛形テーブルの選択を行うことができるようにしたものである。
【００１１】
（６） 本発明の第６の態様は、上述の第１〜第５の態様に係るデータベースシステムの設計装置において、
カスタマイズテーブル作成手段が、同一の雛形テーブルにそれぞれ異なる追加フィールドを追加することにより、もしくは、同一の雛形テーブルにそれぞれ異なる修正を加えることにより、互いに異なる複数のカスタマイズテーブルを作成する機能を有し、
データベース構築手段が、これら複数のカスタマイズテーブルを実テーブル群として用いてデータベースの構築を行うようにしたものである。
【００１２】
（７） 本発明の第７の態様は、上述の第１〜第６の態様に係るデータベースシステムの設計装置において、
各フィールドの構造として、少なくとも、フィールド名、フィールドサイズ、フィールド属性を定義するようにしたものである。
【００１３】
【発明の実施の形態】
以下、本発明を図示する実施形態に基づいて説明する。図１は、複数のテーブルから構成される一般的なデータベースシステムの一例を示すブロック図である。この例は、クレジットカード会社が、各会員ごとのクレジットカードの利用に関する事務処理を行うための単純なシステム構成例である。図示のとおり、このシステムにおけるデータベースの本体部分は、３つのテーブルＴ１，Ｔ２，Ｔ３によって構成されている。
【００１４】
テーブルＴ１は、「個人情報テーブル」なる名称を付されたテーブルであり、個々の会員の個人情報を登録するためのものである。したがって、１名の会員について、１レコード分のデータが作成される。図示の例では、この個人情報テーブルＴ１には、個人ＩＤ、住所、氏名、生年月日、電話番号、家族構成といった６つのフィールドが定義されており、このテーブルＴ１の各レコードには、この６つのフィールドに関するデータが登録されることになる。
【００１５】
また、テーブルＴ２は、「クレジットアカウントテーブル」なる名称を付されたテーブルであり、個々のクレジットアカウントに関する書誌的情報を登録するためのものである。したがって、１アカウントについて、１レコード分のデータが作成される。図示の例では、このクレジットアカウントテーブルＴ２には、アカウント番号、個人ＩＤ、カード番号、有効期限、利用限度額、引落口座といった６つのフィールドが定義されており、このテーブルＴ２の各レコードには、この６つのフィールドに関するデータが登録されることになる。
【００１６】
一方、テーブルＴ３は、「利用履歴情報テーブル」なる名称を付されたテーブルであり、会員が特定の加盟店において、クレジットカードによる決済を行うごとに、当該決済に関する情報を登録するためのものである。したがって、１決済ごとに、レコード分のデータが作成される。図示の例では、この利用履歴情報テーブルＴ３には、伝票番号、加盟店ＩＤ、カード番号、利用年月日、利用金額といった５つのフィールドが定義されており、このテーブルＴ３の各レコードには、この５つのフィールドに関するデータが登録されることになる。
【００１７】
このように、複数のテーブルから構成されるデータベースでは、通常、テーブル間に所定のリレーションシップが定義されている。たとえば、図示の例の場合、太線の矢印で示す関係が、相互のリレーションシップを示している。具体的には、テーブルＴ１の「個人ＩＤ」なるフィールドとテーブルＴ２の同名のフィールドとの間にリレーションシップが定義され、テーブルＴ２の「カード番号」なるフィールドとテーブルＴ３の同名のフィールドとの間にリレーションシップが定義されている。このようなリレーションシップの定義により、たとえば、テーブルＴ３内の特定のレコードについて、カード番号に関するリレーションシップを利用して、テーブルＴ２内の特定のレコードを参照することができ、更に、このテーブルＴ２内の特定のレコードについて、個人ＩＤに関するリレーションシップを利用して、テーブルＴ１内の特定のレコードを参照することができる。結局、このようなリレーションシップを利用して、テーブルＴ３内の特定のレコードに対応する決済を行った会員のアカウントや住所氏名などを認識することが可能になる。
【００１８】
データベースシステムには、このようなデータベース本体部分の他に、このデータベースをアクセスするためのアプリケーションインターフェイスが必要になる。オペレータは、このアプリケーションインターフェイスに対して操作を行うことにより、新たなレコードの登録、レコードの内容更新、レコードの検索などの作業を行うことができる。
【００１９】
さて、このような構造をもったデータベースシステムを設計するためには、まず、どのようなテーブルを定義し、個々のテーブルにはどのようなフィールドを定義するか、ということを決める必要がある。特に、フィールドに関しては、フィールド名のみを決めるだけでは不十分であり、個々のフィールドの構造設計までも行わねばならない。具体的には、個々のフィールドについて、フィールド名、フィールドサイズ、フィールド属性を定義し、その構造を明確にしなければならない。
【００２０】
図２は、図１に示す個人情報テーブルＴ１を構成する６つのフィールドに関する構造定義の一例を示す表である。図示のとおり、６つのフィールドのそれぞれについて、フィールド名、フィールドサイズ、フィールド属性が定義されている。この例では、フィールド名として、項目名とコード名との２とおりの名前を定義するようにしているが、項目名には、そのフィールドに登録されるデータの内容をオペレータに認識させるために相応しい文字列が用いられ、コード名には、データベースをコンピュータで取り扱うために適したコードが用いられる。フィールドサイズは、各フィールドの最大のバイト長を示すものである。また、フィールド属性は、各フィールドの様々な属性を定義するためのものであり、図示の例では、型、暗号化、ユニーク、ＮＵＬＬ、検索対象なる５種類の属性が定義されている。
【００２１】
ここで、型という属性は、当該フィールドに登録されるデータの型を示すものであり、整数か、文字列か、日付か、といった型の分類が定義される。暗号化という属性は、データを格納する際に暗号化をしておく必要があるか否かを示すものであり、あり／なしのいずれかが定義される。ユニークという属性は、データが唯一無二のユニークな値をとる必要があるか否かを示すものであり、ＹＥＳ／ＮＯのいずれかが定義される。ＮＵＬＬという属性は、空のデータが許可されるか否かを示すものであり、許可／不許可のいずれかが定義される。検索対象という属性は、検索時に、検索キーとして利用するか否かを示すものであり、ＹＥＳ／ＮＯのいずれかが定義される。
【００２２】
このように、各フィールドに属性を定義しておくのは、アプリケーションインターフェイスを介してデータベースへのアクセスを行う際に、属性に応じた取り扱いを行うことができるようにするためである。たとえば、暗号化ありのフィールドにデータを入力して格納する際には、所定のアルゴリズムにより暗号化処理を施して格納する必要が生じてくるし、このデータを読み出すときには、復号化処理を施す必要が生じてくる。また、ユニークなデータが要求されるフィールドに、ユニークでないデータが入力された場合や、ＮＵＬＬが不許可となっているフィールドにデータが入力されていない場合は、その旨の警告を行う必要が生じる。
【００２３】
結局、特定の事務処理業務に用いるデータベースシステムの設計を委託された設計者は、当該事務処理業務を行うためには、どのようなテーブルを定義し、個々のテーブルにはどのようなフィールドを定義するかを決定した上で、個々のフィールドについて、図２に示すような構造定義を行い、更に、フィールド間に必要なリレーションシップの定義を行う必要がある。本発明は、このような設計者の労力を軽減させるためのデータベースシステムの設計装置に係るものであり、そのポイントは、所定の基本フィールドの構造を定義した情報からなる雛形テーブルを用意しておき、設計者が、この雛形テーブルを必要に応じてカスタマイズしながら利用することにより、全体のデータベースシステムを設計できるようにする点にある。
【００２４】
図３は、本発明の一実施形態に係るデータベースシステムの設計装置の基本構成を示すブロック図である。図示のとおり、この設計装置の基本構成要素は、雛形テーブル格納手段１０、雛形テーブル選択手段２０、カスタマイズテーブル作成手段３０、データベース構築手段４０である。実際には、これらの各手段は、コンピュータのハードウエアとソフトウエアとの融合により実現される手段であるが、ここでは、説明の便宜上、本発明をこれらの各機能ブロックの集合として捉えて説明する。
【００２５】
雛形テーブル格納手段１０は、所定の基本フィールドの構造を定義した情報からなる雛形テーブルを複数種類格納した手段であり、図には、３種類の雛形テーブルＡ，Ｂ，Ｃが格納された状態が示されている（実際には、より多種類の雛形テーブルが用意される）。各雛形テーブルには、予め、いくつかの基本フィールドの構造定義が完了している。たとえば、雛形テーブルＡには、図示のとおり、３つの基本フィールドＡ１，Ａ２，Ａ３の構造定義がなされている。すなわち、これら基本フィールドについては、図２に示す例のように、フィールド名、フィールドサイズ、フィールド属性が既に設定されていることになる。
【００２６】
また、実用上は、雛形テーブル格納手段１０内に格納されている複数種類の雛形テーブル間に、予め所定のリレーションシップも定義しておくのが好ましい。図４は、３種類の雛形テーブルＡ，Ｂ，Ｃについて予め定義されたリレーションシップの一例を太線の矢印で示すブロック図である。この例では、雛形テーブルＡの基本フィールドＡ１と雛形テーブルＢの基本フィールドＢ２との間と、雛形テーブルＢの基本フィールドＢ３と雛形テーブルＣの基本フィールドＣ３との間に、それぞれリレーションシップが定義されている。通常、相互にリレーションシップが定義されたフィールドには同一の項目名が付与される。
【００２７】
一方、雛形テーブル選択手段２０は、雛形テーブル格納手段１０から、設計者の指示に基づいて、所定の雛形テーブルを選択する機能を果たす構成要素である。実用上は、雛形テーブル格納手段１０内に格納されている複数種類の雛形テーブルのリストを画面上に表示し、必要があれば、各雛形テーブルを構成する基本フィールドの構造を画面上に表示し、設計者の操作により、特定の雛形テーブルを選択する処理が行われるようにするのが好ましい。図３のブロック図では、説明の便宜上、雛形テーブル選択手段２０によって、雛形テーブルＡが選択された状態が示されている。
【００２８】
カスタマイズテーブル作成手段３０は、雛形テーブル選択手段２０によって選択された雛形テーブルに対して、設計者の指示に基づいて、所定の追加フィールドの構造を定義する情報を付加することにより、基本フィールドと追加フィールドとの双方の構造を定義した情報からなるカスタマイズテーブルを作成する機能をもった構成要素である。たとえば、図３には、雛形テーブル選択手段２０によって選択された雛形テーブルＡに対して、新たに追加フィールドＸ１の構造を定義する情報（具体的には、フィールド名、フィールドサイズ、フィールド属性を定義する情報）を付け加えることにより、カスタマイズテーブルＡＡを作成した状態が示されている。このカスタマイズテーブルＡＡは、もとの雛形テーブルＡで定義されていた基本フィールドＡ１，Ａ２，Ａ３と、新たに定義された追加フィールドＸ１との双方をもったテーブルということになる。
【００２９】
データベース構築手段４０は、雛形テーブル選択手段２０によって選択された雛形テーブルもしくはカスタマイズテーブル作成手段３０によって作成されたカスタマイズテーブルを、設計対象となるデータベースシステムを構成する実テーブル群として用い、データベースＤＢを構築する機能をもった構成要素である。データベースＤＢは、雛形テーブルのみの組み合わせで構築してもよいし、カスタマイズテーブルのみの組み合わせで構築してもよいし、両者を取り混ぜた形で構築してもかまわない。もちろん、設計者が新たに作成したテーブルを取り混ぜた形で構築してもよい。また、このデータベース構築手段４０では、必要に応じて、各テーブル間に所定のリレーションシップを定義する処理も行われる。
【００３０】
結局、最終的なデータベースＤＢは、データベース構築手段４０に対して、設計者が具体的な指示操作を与えることにより構築されることになるが、従来のデータベースシステムの設計装置では、個々のテーブル、フィールド構造、リレーションシップを、すべて設計者が一から指示して定義してゆく必要があったのに対して、本発明に係る設計装置では、雛形テーブルをそのまま利用したり、一部をカスタマイズして取り入れたりすることが可能になるので、すべてのテーブルを設計者が一から設計してゆく必要はなくなる。このため、設計者の作業負担は大幅に軽減されることになる。
【００３１】
一般に、事務処理用のデータベースシステムでは、個々の顧客の個人情報を管理するテーブルとか、個々の伝票を管理するテーブルというように、大半の事務処理で共通して利用可能なテーブルが多く存在する。そこで、そのような共通して利用可能なテーブルを予め雛形テーブルとして用意しておけば、多くの場合、これを流用することが可能になる。また、そのような共通利用可能なテーブルには、共通利用可能なフィールドがいくつか存在する。そこで本発明では、そのようなフィールドを予め基本フィールドとして用意しておき、この基本フィールドだけでは十分でない場合には、カスタマイズテーブル作成手段３０によって、任意の追加フィールドを追加定義できるようにしてある。したがって、設計者は、雛形テーブルをそのまま流用したのでは不十分であるような場合にも、適宜カスタマイズしてこれを流用することが可能になる。
【００３２】
なお、この実施形態では、カスタマイズテーブル作成手段３０によって実行されるカスタマイズ処理は、任意の追加フィールドを追加する処理だけに限らない。すなわち、カスタマイズテーブル作成手段３０は、雛形テーブル選択手段２０によって選択された雛形テーブルの基本フィールドに対して、設計者の指示に基づいて、構造の修正を行うことにより、カスタマイズテーブルを作成する機能を有している。
【００３３】
たとえば、図２に示すような構造定義がなされた基本フィールドからなる雛形テーブルがあった場合、設計者は、これら基本フィールドの任意の構造に対して修正を行うことができる。具体的には、氏名のフィールドサイズを増加させたり、住所の暗号化属性を「あり」に変更したり、といった修正を加えることができる。
【００３４】
結局、カスタマイズテーブル作成手段３０は、同一の雛形テーブルにそれぞれ異なる追加フィールドを追加したり、異なる修正を加えたりすることにより、互いに異なる複数のカスタマイズテーブルを作成することが可能であり、データベース構築手段４０は、これら複数のカスタマイズテーブルを実テーブル群として用いてデータベースＤＢの構築を行うことが可能である。
【００３５】
もっとも、雛形テーブル内の各基本フィールドに対する構造修正を無制限に認めてしまうと、実用上、好ましくないケースもある。たとえば、相互にリレーションシップが定義された２つの基本フィールドがあった場合、一方に対する構造修正のみが勝手に行われると、整合性を欠くことになる。したがって、実用上は、基本フィールドに対する構造修正に制限を設け、設計者から、この制限の許容範囲外の修正指示が与えられた場合には、当該指示が無視されるような構成にするのが好ましい。
【００３６】
更に、雛形テーブルの内容によっては、単独で利用しても意味がなく、相互に関連した別の雛形テーブルと一緒に利用してはじめて価値のあるようなテーブルも存在する。このように、相互に関連した複数の雛形テーブルについては、必ず同時に選択されるようにしておくのが好ましい。そのためには、１つもしくは複数の雛形テーブルを包含するグループを定義し、雛形テーブル選択手段２０が、グループ単位で雛形テーブルの選択を行うことができるようにすればよい。
【００３７】
図５は、このようなグループ定義を行った例を示すブロック図である。図示の例では、雛形テーブルＡ，ＢはグループＧ１に所属し、雛形テーブルＣは単独でグループＧ２に所属し、雛形テーブルＤ，Ｅ，ＦはグループＧ３に所属している。雛形テーブル格納手段１０に、このようなグループ定義がなされた雛形テーブルが格納されていた場合、雛形テーブル選択手段２０による選択は、グループ単位で行われることになる。したがって、たとえば、雛形テーブルＡとＢとは、単独で用いても意味がなく、常に一緒に利用する必要があるテーブルであるような場合、このようなグループ定義を行っておくことにより、有効なテーブル選択が可能になる。
【００３８】
最後に、本発明に係るデータベースシステムの設計装置を利用した設計作業を、より具体的な実施例に基づいて説明しよう。いま、雛形テーブル格納手段１０内に、図６に示すような３種類の雛形テーブルが格納されていたとしよう。第１の雛形テーブルは、「顧客情報用雛形テーブル」と呼ばれるテーブルであり、インターネットを介してアクセスしてくる顧客に関する情報を登録するのに適したテーブルである。図示の例では、顧客ＩＤ，アカウント，パスワードなる３つの基本フィールドの構造定義が予めなされている。第２の雛形テーブルは、「注文情報用雛形テーブル」と呼ばれるテーブルであり、物品等の注文を受けた場合に、１回の注文ごとの統括的な情報を登録するのに適したテーブルである。図示の例では、注文ＩＤ，顧客ＩＤ，金額総計なる３つの基本フィールドの構造定義が予めなされている。第３の雛形テーブルは、「注文詳細情報用雛形テーブル」と呼ばれるテーブルであり、物品等の注文を受けた場合に、個々の物品ごとの個別情報を登録するのに適したテーブルである。図示の例では、詳細注文ＩＤ，注文ＩＤなる２つの基本フィールドの構造定義が予めなされている。
【００３９】
ここで、「注文情報用雛形テーブル」と「注文詳細情報用雛形テーブル」とは、相互に関連した雛形テーブルであり、常に一緒に利用する必要があるテーブルである。いわば、「注文情報用雛形テーブル」は、複数の物品を注文したときの伝票の上部に設けられた記入欄（伝票番号、注文主名、合計金額を記入する欄）に記載される情報を格納するためのテーブルというべきものであり、「注文詳細情報用雛形テーブル」は、この伝票の個別項目欄の個々の行に記載される品名、単価、数量などの情報を格納するためのテーブルというべきものである。したがって、１枚の注文伝票を構成するには、これら２つのテーブルの情報が必要になる。そこで、図６に示す例では、「顧客情報用雛形テーブル」は単独でグループＧ１を構成しているのに対して、「注文情報用雛形テーブル」と「注文詳細情報用雛形テーブル」とは、２つ一緒にしてグループＧ２を構成している。
【００４０】
さて、ここでは、インターネットにおいて仮想ショッピングモールを運営している事業者からの依頼を受けて、当該仮想ショッピングモールでの受注処理に利用するためのデータベースシステムを設計する作業を考えてみよう。より具体的に、この仮想ショッピングモールには、本屋、肉屋、パン屋の３件の仮想ショップが存在し、それぞれ書籍、食肉、パンをインターネット上で販売しているものとし、このモールでの受注処理用データベースシステムを設計することにしよう。
【００４１】
この場合、設計者は、まず雛形テーブル選択手段２０によって、グループＧ１を選択し、「顧客情報用雛形テーブル」を抽出してくる。ここで、依頼主から、顧客については、顧客ＩＤ，アカウント，パスワード，住所，氏名という５つのフィールドを設定して欲しい旨の指示が与えられていたとすると、図６に示す「顧客情報用雛形テーブル」には、顧客ＩＤ，アカウント，パスワードは基本フィールドとして既に定義されているので、住所，氏名という２つのフィールドを、新たに追加フィールドとして設定すればよいことがわかる。そこで、カスタマイズテーブル作成手段３０を利用して、「顧客情報用雛形テーブル」に対するカスタマイズを行ってカスタマイズテーブルを作成し、これを「顧客情報用実テーブル」として用いるようにすればよい。
【００４２】
図７は、このようなカスタマイズ作業を行うための画面構成例を示す平面図である。設計者がカスタマイズテーブル作成手段３０に対して、「顧客情報用雛形テーブル」に対するカスタマイズ作業を行う旨の指示を与えると、ディスプレイ画面上に図示のような内容が表示されることになる。ここで、上段３１の表には、３つの基本フィールドである「顧客ＩＤ，アカウント，パスワード」について、予め設定されている構造定義の内容が示されている。設計者は、必要に応じて、任意の構造をもった新たなフィールドを追加フィールドとして付加したり、既存の基本フィールドの構造に修正を加えたりする操作を行うことができる。
【００４３】
図７に示す例では、中段３２の領域に、フィールドの構造定義を行うための入力欄が設けられている。新たなフィールドを追加する際には、これらの入力欄にそれぞれ所望の内容を入力して構造定義を行う。具体的には、項目名、コード名、サイズの各欄には、キーボードから所望の内容を入力する作業を行えばよいし、型の欄については、三角形の矢印をクリックすることにより出現するポップアップメニューから所望の型を選択すればよい。また、暗号化、ユニーク、ＮＵＬＬ、検索対象の欄については、肯定的な設定を行う場合に先頭の四角枠内をクリックしてチェックを入れるようにすればよい。こうして、新たに追加するフィールドについての構造定義が完了したら、下段３３の領域の登録ボタンをクリックすれば、当該追加フィールドが新たに追加されることになり、上段３１の表に、その内容が表示されることになる。
【００４４】
一方、上段３１の表において、いずれかの行をクリックして選択状態にした後、下段３３の変更ボタンをクリックすれば、中段３２の各欄の入力内容によって、上段３１の選択行の内容が書き換えられ、構造定義の変更を行うことができる。また、下段３３のクリアボタンは、中段３２の各欄をクリアするためのボタンであり、削除ボタンは、上段３１で選択状態にした行の内容を削除するためのボタンである。設計者が、こうしてカスタマイズを完了した後、下段３３の保存ボタンをクリックすれば、カスタマイズテーブルが作成され、保存されることになる。なお、下段３３の戻るボタンは、雛形テーブル選択手段２０による選択操作に戻るためのボタンである。
【００４５】
なお、ここに示す実施形態では、あるフィールドについて、暗号化の欄を「あり」に設定した場合には、当該フィールドについては、検索対象の欄を「ＹＥＳ」にする設定ができないような制限を課するようにしている。具体的には、中段３２の暗号化の四角枠内の欄にチェックが入れられた後は、検索対象の欄にチェックを入れるような指示が与えられても、当該指示は無視され、検索対象の欄にはチェックが入らないようにしている。また、既に、検索対象の欄にチェックが入れられた状態において、暗号化の欄にチェックが入れられたときには、検索対象の欄のチェックがキャンセルされる仕様にしてある。これは、暗号化を「あり」に設定したフィールド内のデータは、所定の暗号化アルゴリズムに基づいて暗号化された後、データベースＤＢ内に格納されることになるため、当該データを検索キーとする検索処理を行うことができないためである。
【００４６】
同様に、暗号化の欄を「あり」に設定した場合には、ユニークの欄を「ＹＥＳ」にする設定ができないような制限も課せられるようにしている。これは、やはり暗号化を「あり」に設定したフィールド内のデータが、暗号化された状態でデータベースＤＢ内に格納されることになり、当該フィールド内のデータがユニークであるか否かを確認することができなくなるためである。このように、基本フィールドに対する構造修正に制限を設け、設計者から、この制限の許容範囲外の修正指示が与えられた場合には、当該指示が無視されるような仕様にしておけば、不適切なカスタマイズ作業が実施されることを事前に防ぐことができ便利である。
【００４７】
また、一般に、何らかのデータに対して暗号化処理を行うと、暗号化されたデータは元のデータよりもデータ量が大きくなる。そこで、本実施形態では、暗号化の欄を「あり」に設定したフィールドについては、暗号化処理後のデータ量に適合した格納領域を確保したテーブル構築を行う機能をもたせている。
【００４８】
以上、カスタマイズテーブル作成手段３０によるカスタマイズ操作を行うための表示画面の一例を示したが、もちろん、本発明を実施する上では、どのような表示画面でカスタマイズを実施してもかまわない。図７は、具体的な画面構成の一例を示すものであり、本発明は、このような画面構成に何ら限定されるものではない。
【００４９】
図８は、このようなカスタマイズ操作を行うことにより、合計５つの実テーブルを作成し、データベース構築手段４０によって、実際のデータベースＤＢを構築した状態を示すブロック図である。図示のとおり、このデータベースＤＢは、顧客情報用実テーブルＴ１，注文情報用実テーブルＴ２，注文詳細情報用実テーブル（本屋）Ｔ３，注文詳細情報用実テーブル（肉屋）Ｔ４，注文詳細情報用実テーブル（パン屋）Ｔ５という５つの実テーブルによって構成されている。
【００５０】
この図８において、太線枠で示すフィールドは、雛形テーブル格納手段１０内の各雛形テーブルに予め用意されていた基本フィールドを示し、太線の矢印は、予め定義されていたリレーションシップを示す。したがって、これらの各フィールドやリレーションシップについては、設計者は設定作業を行う必要はない。
【００５１】
顧客情報用実テーブルＴ１は、図６に示す「顧客情報用雛形テーブル」に、住所，氏名という２つの追加フィールドを付加するカスタマイズ作業により得られたカスタマイズテーブルであり、注文情報用実テーブルＴ２は、図６に示す「注文情報用雛形テーブル」に、注文日という追加フィールドを付加するカスタマイズ作業により得られたカスタマイズテーブルである。もっとも、「注文情報用雛形テーブル」はグループＧ２に所属するテーブルであるため、「注文詳細情報用雛形テーブル」も同時に選択されることになる。
【００５２】
図８に示す注文詳細情報用実テーブル（本屋）Ｔ３，注文詳細情報用実テーブル（肉屋）Ｔ４，注文詳細情報用実テーブル（パン屋）Ｔ５は、いずれも図６に示す「注文詳細情報用雛形テーブル」に対するカスタマイズ作業により得られたカスタマイズテーブルであるが、それぞれ追加フィールドが異なっている。すなわち、注文詳細情報用実テーブル（本屋）Ｔ３では、ＩＳＢＮ，冊数，定価という書籍の注文に適した追加フィールドが付加されており、注文詳細情報用実テーブル（肉屋）Ｔ４では、部位，単価，ｇ数という食肉の注文に適した追加フィールドが付加されており、注文詳細情報用実テーブル（パン屋）Ｔ５では、種類、価格、個数というパンの注文に適した追加フィールドが付加されている。このように、同一の雛形テーブルを用いても、カスタマイズの内容が異なれば、それぞれ異なる実テーブルを作成することができる。ただ、基本フィールドについて予め定義されていたリレーションシップは、そのまま維持されており、図示の例では、テーブルＴ３，Ｔ４，Ｔ５のいずれについても、それぞれの注文ＩＤフィールドと、テーブルＴ２の注文ＩＤフィールドとの間に、リレーションシップが定義された状態になっている。
【００５３】
このように、図８に示すデータベースＤＢを、図６に示す雛形テーブルを利用して作成すれば、設計者によって行うべき、フィールド構造定義やリレーションシップ定義の作業が極力減らされることになり、設計者の作業負担を大幅に軽減することができる。しかも、必要に応じてカスタマイズを行うことにより、本屋，肉屋，パン屋といった異なるジャンルの商品の注文にも柔軟に対応したデータベースの構築が可能になる。
【００５４】
【発明の効果】
以上のとおり、本発明に係るデータベースシステムの設計装置によれば、予め用意された雛形テーブルを利用した設計を行うことができるようにしたため、設計者の作業の労力をできるだけ軽減することが可能になる。
【図面の簡単な説明】
【図１】複数のテーブルから構成される一般的なデータベースシステムの一例を示すブロック図である。
【図２】図１に示す個人情報テーブルＴ１を構成する６つのフィールドに関する構造定義の一例を示す表である。
【図３】本発明の一実施形態に係るデータベースシステムの設計装置の基本構成を示すブロック図である。
【図４】３種類の雛形テーブルＡ，Ｂ，Ｃについて予め定義されたリレーションシップの一例を太線の矢印で示すブロック図である。
【図５】図３に示すデータベースシステムの設計装置における雛形テーブル格納手段１０内に格納する各雛形テーブルにグループ定義を行った例を示すブロック図である。
【図６】図３に示すデータベースシステムの設計装置における雛形テーブル格納手段１０内に格納されている雛形テーブルの具体例を示すブロック図である。
【図７】図６に示す顧客情報用雛形テーブルに対するカスタマイズ作業を行うための画面構成例を示す平面図である。
【図８】図６に示す各雛形テーブルに対して、それぞれカスタマイズ操作を行うことにより、合計５つの実テーブルを作成し、実際のデータベースを構築した状態を示すブロック図である。
【符号の説明】
１０…雛形テーブル格納手段
２０…雛形テーブル選択手段
３０…カスタマイズテーブル作成手段
３１…カスタマイズ作業画面の上段
３２…カスタマイズ作業画面の中段
３３…カスタマイズ作業画面の下段
４０…データベース構築手段
Ａ〜Ｆ…雛形テーブル
ＡＡ…カスタマイズテーブル
Ａ１〜Ａ３，Ｂ１〜Ｂ３，Ｃ１〜Ｃ３…基本フィールド
Ｇ１〜Ｇ３…雛形テーブルのグループ
ＤＢ…データベース
Ｔ１〜Ｔ５…データベースを構成する実テーブル
Ｘ１…追加フィールド
【発明の属する技術分野】
本発明はデータベースシステムの設計装置に関し、特に、複数のテーブルから構成されるリレーショナル型データベースシステムを設計する装置に関する。
【０００２】
【従来の技術】
現在、様々な分野におけるデータ管理に、データベースシステムが導入されており、大小様々な規模のデータベースシステムが稼働している。特に、一般的な事務処理には、レコードとフィールドとによって構成されるテーブル形式でデータを取り扱うリレーショナル型データベースが広く利用されており、通常、複数のテーブルによってデータベースシステムの構築が行われる。たとえば、個々の顧客ごとの売上を管理するデータベースシステムの場合、顧客となる企業名、住所、電話番号、担当者名などを管理する顧客情報テーブルと、売上伝票に掲載される日付、販売商品名、個数、単価、売上額などを管理する売上情報テーブルと、によってデータベースを構築することができる。
【０００３】
多くのソフトハウスは、クライアント企業から、所望のデータベースシステムの受注を受け、当該クライアント企業の業務形態に合致したオーダーメイドのデータベースシステムを設計する作業を行っている。また、このような設計作業の労力を軽減するための効率的なデータベースの構築方法や設計装置などが提案されている。たとえば、下記の特許文献１には、固有のプロセスを用いたデータベースの構築方法が開示されており、特許文献２には、データベースの管理システムが開示されている。
【特許文献１】
特開平５−０２７９６０号公報
【特許文献２】
特開平９−１６７１１３号公報
【０００４】
【発明が解決しようとする課題】
上述したように、レコードとフィールドとによって構成されるテーブル形式でデータを取り扱うリレーショナル型データベースは、種々の事務処理で広く利用されているデータベースであるが、特定の企業の業務形態に合致したオーダーメイドのデータベースシステムを設計するには、多大な労力と時間を要するのが実情である。これは、個々の企業の業務形態は千差万別であるため、オーダーメイドのデータベースシステムを受注した場合には、受注先である特定の企業の特定の業務形態に最適なテーブルを設計する必要があり、しかも、個々のテーブルを設計する際には、各フィールドの構造を定義するとともに、フィールド間のリレーションシップの定義を行わねばならないためである。
【０００５】
そこで本発明は、設計作業の労力をできるだけ軽減することが可能なデータベースシステムの設計装置を提供することを目的とする。
【０００６】
【課題を解決するための手段】
（１） 本発明の第１の態様は、複数のテーブルから構成されるデータベースシステムを設計するデータベースシステムの設計装置において、
所定の基本フィールドの構造を定義した情報からなる雛形テーブルを複数種類格納した雛形テーブル格納手段と、
この雛形テーブル格納手段から、設計者の指示に基づいて、所定の雛形テーブルを選択する雛形テーブル選択手段と、
この雛形テーブル選択手段によって選択された雛形テーブルに対して、設計者の指示に基づいて、所定の追加フィールドの構造を定義する情報を付加することにより、基本フィールドと追加フィールドとの双方の構造を定義した情報からなるカスタマイズテーブルを作成するカスタマイズテーブル作成手段と、
雛形テーブル選択手段によって選択された雛形テーブルもしくはカスタマイズテーブル作成手段によって作成されたカスタマイズテーブルを、設計対象となるデータベースシステムを構成する実テーブル群として用い、データベースを構築するデータベース構築手段と、
を設けるようにしたものである。
【０００７】
（２） 本発明の第２の態様は、上述の第１の態様に係るデータベースシステムの設計装置において、
雛形テーブル格納手段内に格納されている複数種類の雛形テーブル間に、予め所定のリレーションシップを定義しておくようにしたものである。
【０００８】
（３） 本発明の第３の態様は、上述の第１または第２の態様に係るデータベースシステムの設計装置において、
カスタマイズテーブル作成手段が、雛形テーブル選択手段によって選択された雛形テーブルの基本フィールドに対して、設計者の指示に基づいて、構造の修正を行うことにより、カスタマイズテーブルを作成する機能を有するようにしたものである。
【０００９】
（４） 本発明の第４の態様は、上述の第３の態様に係るデータベースシステムの設計装置において、
基本フィールドに対する構造修正に制限を設け、設計者から、この制限の許容範囲外の修正指示が与えられた場合には、当該指示が無視されるようにしたものである。
【００１０】
（５） 本発明の第５の態様は、上述の第１〜第４の態様に係るデータベースシステムの設計装置において、
１つもしくは複数の雛形テーブルを包含するグループを定義し、雛形テーブル選択手段が、グループ単位で雛形テーブルの選択を行うことができるようにしたものである。
【００１１】
（６） 本発明の第６の態様は、上述の第１〜第５の態様に係るデータベースシステムの設計装置において、
カスタマイズテーブル作成手段が、同一の雛形テーブルにそれぞれ異なる追加フィールドを追加することにより、もしくは、同一の雛形テーブルにそれぞれ異なる修正を加えることにより、互いに異なる複数のカスタマイズテーブルを作成する機能を有し、
データベース構築手段が、これら複数のカスタマイズテーブルを実テーブル群として用いてデータベースの構築を行うようにしたものである。
【００１２】
（７） 本発明の第７の態様は、上述の第１〜第６の態様に係るデータベースシステムの設計装置において、
各フィールドの構造として、少なくとも、フィールド名、フィールドサイズ、フィールド属性を定義するようにしたものである。
【００１３】
【発明の実施の形態】
以下、本発明を図示する実施形態に基づいて説明する。図１は、複数のテーブルから構成される一般的なデータベースシステムの一例を示すブロック図である。この例は、クレジットカード会社が、各会員ごとのクレジットカードの利用に関する事務処理を行うための単純なシステム構成例である。図示のとおり、このシステムにおけるデータベースの本体部分は、３つのテーブルＴ１，Ｔ２，Ｔ３によって構成されている。
【００１４】
テーブルＴ１は、「個人情報テーブル」なる名称を付されたテーブルであり、個々の会員の個人情報を登録するためのものである。したがって、１名の会員について、１レコード分のデータが作成される。図示の例では、この個人情報テーブルＴ１には、個人ＩＤ、住所、氏名、生年月日、電話番号、家族構成といった６つのフィールドが定義されており、このテーブルＴ１の各レコードには、この６つのフィールドに関するデータが登録されることになる。
【００１５】
また、テーブルＴ２は、「クレジットアカウントテーブル」なる名称を付されたテーブルであり、個々のクレジットアカウントに関する書誌的情報を登録するためのものである。したがって、１アカウントについて、１レコード分のデータが作成される。図示の例では、このクレジットアカウントテーブルＴ２には、アカウント番号、個人ＩＤ、カード番号、有効期限、利用限度額、引落口座といった６つのフィールドが定義されており、このテーブルＴ２の各レコードには、この６つのフィールドに関するデータが登録されることになる。
【００１６】
一方、テーブルＴ３は、「利用履歴情報テーブル」なる名称を付されたテーブルであり、会員が特定の加盟店において、クレジットカードによる決済を行うごとに、当該決済に関する情報を登録するためのものである。したがって、１決済ごとに、レコード分のデータが作成される。図示の例では、この利用履歴情報テーブルＴ３には、伝票番号、加盟店ＩＤ、カード番号、利用年月日、利用金額といった５つのフィールドが定義されており、このテーブルＴ３の各レコードには、この５つのフィールドに関するデータが登録されることになる。
【００１７】
このように、複数のテーブルから構成されるデータベースでは、通常、テーブル間に所定のリレーションシップが定義されている。たとえば、図示の例の場合、太線の矢印で示す関係が、相互のリレーションシップを示している。具体的には、テーブルＴ１の「個人ＩＤ」なるフィールドとテーブルＴ２の同名のフィールドとの間にリレーションシップが定義され、テーブルＴ２の「カード番号」なるフィールドとテーブルＴ３の同名のフィールドとの間にリレーションシップが定義されている。このようなリレーションシップの定義により、たとえば、テーブルＴ３内の特定のレコードについて、カード番号に関するリレーションシップを利用して、テーブルＴ２内の特定のレコードを参照することができ、更に、このテーブルＴ２内の特定のレコードについて、個人ＩＤに関するリレーションシップを利用して、テーブルＴ１内の特定のレコードを参照することができる。結局、このようなリレーションシップを利用して、テーブルＴ３内の特定のレコードに対応する決済を行った会員のアカウントや住所氏名などを認識することが可能になる。
【００１８】
データベースシステムには、このようなデータベース本体部分の他に、このデータベースをアクセスするためのアプリケーションインターフェイスが必要になる。オペレータは、このアプリケーションインターフェイスに対して操作を行うことにより、新たなレコードの登録、レコードの内容更新、レコードの検索などの作業を行うことができる。
【００１９】
さて、このような構造をもったデータベースシステムを設計するためには、まず、どのようなテーブルを定義し、個々のテーブルにはどのようなフィールドを定義するか、ということを決める必要がある。特に、フィールドに関しては、フィールド名のみを決めるだけでは不十分であり、個々のフィールドの構造設計までも行わねばならない。具体的には、個々のフィールドについて、フィールド名、フィールドサイズ、フィールド属性を定義し、その構造を明確にしなければならない。
【００２０】
図２は、図１に示す個人情報テーブルＴ１を構成する６つのフィールドに関する構造定義の一例を示す表である。図示のとおり、６つのフィールドのそれぞれについて、フィールド名、フィールドサイズ、フィールド属性が定義されている。この例では、フィールド名として、項目名とコード名との２とおりの名前を定義するようにしているが、項目名には、そのフィールドに登録されるデータの内容をオペレータに認識させるために相応しい文字列が用いられ、コード名には、データベースをコンピュータで取り扱うために適したコードが用いられる。フィールドサイズは、各フィールドの最大のバイト長を示すものである。また、フィールド属性は、各フィールドの様々な属性を定義するためのものであり、図示の例では、型、暗号化、ユニーク、ＮＵＬＬ、検索対象なる５種類の属性が定義されている。
【００２１】
ここで、型という属性は、当該フィールドに登録されるデータの型を示すものであり、整数か、文字列か、日付か、といった型の分類が定義される。暗号化という属性は、データを格納する際に暗号化をしておく必要があるか否かを示すものであり、あり／なしのいずれかが定義される。ユニークという属性は、データが唯一無二のユニークな値をとる必要があるか否かを示すものであり、ＹＥＳ／ＮＯのいずれかが定義される。ＮＵＬＬという属性は、空のデータが許可されるか否かを示すものであり、許可／不許可のいずれかが定義される。検索対象という属性は、検索時に、検索キーとして利用するか否かを示すものであり、ＹＥＳ／ＮＯのいずれかが定義される。
【００２２】
このように、各フィールドに属性を定義しておくのは、アプリケーションインターフェイスを介してデータベースへのアクセスを行う際に、属性に応じた取り扱いを行うことができるようにするためである。たとえば、暗号化ありのフィールドにデータを入力して格納する際には、所定のアルゴリズムにより暗号化処理を施して格納する必要が生じてくるし、このデータを読み出すときには、復号化処理を施す必要が生じてくる。また、ユニークなデータが要求されるフィールドに、ユニークでないデータが入力された場合や、ＮＵＬＬが不許可となっているフィールドにデータが入力されていない場合は、その旨の警告を行う必要が生じる。
【００２３】
結局、特定の事務処理業務に用いるデータベースシステムの設計を委託された設計者は、当該事務処理業務を行うためには、どのようなテーブルを定義し、個々のテーブルにはどのようなフィールドを定義するかを決定した上で、個々のフィールドについて、図２に示すような構造定義を行い、更に、フィールド間に必要なリレーションシップの定義を行う必要がある。本発明は、このような設計者の労力を軽減させるためのデータベースシステムの設計装置に係るものであり、そのポイントは、所定の基本フィールドの構造を定義した情報からなる雛形テーブルを用意しておき、設計者が、この雛形テーブルを必要に応じてカスタマイズしながら利用することにより、全体のデータベースシステムを設計できるようにする点にある。
【００２４】
図３は、本発明の一実施形態に係るデータベースシステムの設計装置の基本構成を示すブロック図である。図示のとおり、この設計装置の基本構成要素は、雛形テーブル格納手段１０、雛形テーブル選択手段２０、カスタマイズテーブル作成手段３０、データベース構築手段４０である。実際には、これらの各手段は、コンピュータのハードウエアとソフトウエアとの融合により実現される手段であるが、ここでは、説明の便宜上、本発明をこれらの各機能ブロックの集合として捉えて説明する。
【００２５】
雛形テーブル格納手段１０は、所定の基本フィールドの構造を定義した情報からなる雛形テーブルを複数種類格納した手段であり、図には、３種類の雛形テーブルＡ，Ｂ，Ｃが格納された状態が示されている（実際には、より多種類の雛形テーブルが用意される）。各雛形テーブルには、予め、いくつかの基本フィールドの構造定義が完了している。たとえば、雛形テーブルＡには、図示のとおり、３つの基本フィールドＡ１，Ａ２，Ａ３の構造定義がなされている。すなわち、これら基本フィールドについては、図２に示す例のように、フィールド名、フィールドサイズ、フィールド属性が既に設定されていることになる。
【００２６】
また、実用上は、雛形テーブル格納手段１０内に格納されている複数種類の雛形テーブル間に、予め所定のリレーションシップも定義しておくのが好ましい。図４は、３種類の雛形テーブルＡ，Ｂ，Ｃについて予め定義されたリレーションシップの一例を太線の矢印で示すブロック図である。この例では、雛形テーブルＡの基本フィールドＡ１と雛形テーブルＢの基本フィールドＢ２との間と、雛形テーブルＢの基本フィールドＢ３と雛形テーブルＣの基本フィールドＣ３との間に、それぞれリレーションシップが定義されている。通常、相互にリレーションシップが定義されたフィールドには同一の項目名が付与される。
【００２７】
一方、雛形テーブル選択手段２０は、雛形テーブル格納手段１０から、設計者の指示に基づいて、所定の雛形テーブルを選択する機能を果たす構成要素である。実用上は、雛形テーブル格納手段１０内に格納されている複数種類の雛形テーブルのリストを画面上に表示し、必要があれば、各雛形テーブルを構成する基本フィールドの構造を画面上に表示し、設計者の操作により、特定の雛形テーブルを選択する処理が行われるようにするのが好ましい。図３のブロック図では、説明の便宜上、雛形テーブル選択手段２０によって、雛形テーブルＡが選択された状態が示されている。
【００２８】
カスタマイズテーブル作成手段３０は、雛形テーブル選択手段２０によって選択された雛形テーブルに対して、設計者の指示に基づいて、所定の追加フィールドの構造を定義する情報を付加することにより、基本フィールドと追加フィールドとの双方の構造を定義した情報からなるカスタマイズテーブルを作成する機能をもった構成要素である。たとえば、図３には、雛形テーブル選択手段２０によって選択された雛形テーブルＡに対して、新たに追加フィールドＸ１の構造を定義する情報（具体的には、フィールド名、フィールドサイズ、フィールド属性を定義する情報）を付け加えることにより、カスタマイズテーブルＡＡを作成した状態が示されている。このカスタマイズテーブルＡＡは、もとの雛形テーブルＡで定義されていた基本フィールドＡ１，Ａ２，Ａ３と、新たに定義された追加フィールドＸ１との双方をもったテーブルということになる。
【００２９】
データベース構築手段４０は、雛形テーブル選択手段２０によって選択された雛形テーブルもしくはカスタマイズテーブル作成手段３０によって作成されたカスタマイズテーブルを、設計対象となるデータベースシステムを構成する実テーブル群として用い、データベースＤＢを構築する機能をもった構成要素である。データベースＤＢは、雛形テーブルのみの組み合わせで構築してもよいし、カスタマイズテーブルのみの組み合わせで構築してもよいし、両者を取り混ぜた形で構築してもかまわない。もちろん、設計者が新たに作成したテーブルを取り混ぜた形で構築してもよい。また、このデータベース構築手段４０では、必要に応じて、各テーブル間に所定のリレーションシップを定義する処理も行われる。
【００３０】
結局、最終的なデータベースＤＢは、データベース構築手段４０に対して、設計者が具体的な指示操作を与えることにより構築されることになるが、従来のデータベースシステムの設計装置では、個々のテーブル、フィールド構造、リレーションシップを、すべて設計者が一から指示して定義してゆく必要があったのに対して、本発明に係る設計装置では、雛形テーブルをそのまま利用したり、一部をカスタマイズして取り入れたりすることが可能になるので、すべてのテーブルを設計者が一から設計してゆく必要はなくなる。このため、設計者の作業負担は大幅に軽減されることになる。
【００３１】
一般に、事務処理用のデータベースシステムでは、個々の顧客の個人情報を管理するテーブルとか、個々の伝票を管理するテーブルというように、大半の事務処理で共通して利用可能なテーブルが多く存在する。そこで、そのような共通して利用可能なテーブルを予め雛形テーブルとして用意しておけば、多くの場合、これを流用することが可能になる。また、そのような共通利用可能なテーブルには、共通利用可能なフィールドがいくつか存在する。そこで本発明では、そのようなフィールドを予め基本フィールドとして用意しておき、この基本フィールドだけでは十分でない場合には、カスタマイズテーブル作成手段３０によって、任意の追加フィールドを追加定義できるようにしてある。したがって、設計者は、雛形テーブルをそのまま流用したのでは不十分であるような場合にも、適宜カスタマイズしてこれを流用することが可能になる。
【００３２】
なお、この実施形態では、カスタマイズテーブル作成手段３０によって実行されるカスタマイズ処理は、任意の追加フィールドを追加する処理だけに限らない。すなわち、カスタマイズテーブル作成手段３０は、雛形テーブル選択手段２０によって選択された雛形テーブルの基本フィールドに対して、設計者の指示に基づいて、構造の修正を行うことにより、カスタマイズテーブルを作成する機能を有している。
【００３３】
たとえば、図２に示すような構造定義がなされた基本フィールドからなる雛形テーブルがあった場合、設計者は、これら基本フィールドの任意の構造に対して修正を行うことができる。具体的には、氏名のフィールドサイズを増加させたり、住所の暗号化属性を「あり」に変更したり、といった修正を加えることができる。
【００３４】
結局、カスタマイズテーブル作成手段３０は、同一の雛形テーブルにそれぞれ異なる追加フィールドを追加したり、異なる修正を加えたりすることにより、互いに異なる複数のカスタマイズテーブルを作成することが可能であり、データベース構築手段４０は、これら複数のカスタマイズテーブルを実テーブル群として用いてデータベースＤＢの構築を行うことが可能である。
【００３５】
もっとも、雛形テーブル内の各基本フィールドに対する構造修正を無制限に認めてしまうと、実用上、好ましくないケースもある。たとえば、相互にリレーションシップが定義された２つの基本フィールドがあった場合、一方に対する構造修正のみが勝手に行われると、整合性を欠くことになる。したがって、実用上は、基本フィールドに対する構造修正に制限を設け、設計者から、この制限の許容範囲外の修正指示が与えられた場合には、当該指示が無視されるような構成にするのが好ましい。
【００３６】
更に、雛形テーブルの内容によっては、単独で利用しても意味がなく、相互に関連した別の雛形テーブルと一緒に利用してはじめて価値のあるようなテーブルも存在する。このように、相互に関連した複数の雛形テーブルについては、必ず同時に選択されるようにしておくのが好ましい。そのためには、１つもしくは複数の雛形テーブルを包含するグループを定義し、雛形テーブル選択手段２０が、グループ単位で雛形テーブルの選択を行うことができるようにすればよい。
【００３７】
図５は、このようなグループ定義を行った例を示すブロック図である。図示の例では、雛形テーブルＡ，ＢはグループＧ１に所属し、雛形テーブルＣは単独でグループＧ２に所属し、雛形テーブルＤ，Ｅ，ＦはグループＧ３に所属している。雛形テーブル格納手段１０に、このようなグループ定義がなされた雛形テーブルが格納されていた場合、雛形テーブル選択手段２０による選択は、グループ単位で行われることになる。したがって、たとえば、雛形テーブルＡとＢとは、単独で用いても意味がなく、常に一緒に利用する必要があるテーブルであるような場合、このようなグループ定義を行っておくことにより、有効なテーブル選択が可能になる。
【００３８】
最後に、本発明に係るデータベースシステムの設計装置を利用した設計作業を、より具体的な実施例に基づいて説明しよう。いま、雛形テーブル格納手段１０内に、図６に示すような３種類の雛形テーブルが格納されていたとしよう。第１の雛形テーブルは、「顧客情報用雛形テーブル」と呼ばれるテーブルであり、インターネットを介してアクセスしてくる顧客に関する情報を登録するのに適したテーブルである。図示の例では、顧客ＩＤ，アカウント，パスワードなる３つの基本フィールドの構造定義が予めなされている。第２の雛形テーブルは、「注文情報用雛形テーブル」と呼ばれるテーブルであり、物品等の注文を受けた場合に、１回の注文ごとの統括的な情報を登録するのに適したテーブルである。図示の例では、注文ＩＤ，顧客ＩＤ，金額総計なる３つの基本フィールドの構造定義が予めなされている。第３の雛形テーブルは、「注文詳細情報用雛形テーブル」と呼ばれるテーブルであり、物品等の注文を受けた場合に、個々の物品ごとの個別情報を登録するのに適したテーブルである。図示の例では、詳細注文ＩＤ，注文ＩＤなる２つの基本フィールドの構造定義が予めなされている。
【００３９】
ここで、「注文情報用雛形テーブル」と「注文詳細情報用雛形テーブル」とは、相互に関連した雛形テーブルであり、常に一緒に利用する必要があるテーブルである。いわば、「注文情報用雛形テーブル」は、複数の物品を注文したときの伝票の上部に設けられた記入欄（伝票番号、注文主名、合計金額を記入する欄）に記載される情報を格納するためのテーブルというべきものであり、「注文詳細情報用雛形テーブル」は、この伝票の個別項目欄の個々の行に記載される品名、単価、数量などの情報を格納するためのテーブルというべきものである。したがって、１枚の注文伝票を構成するには、これら２つのテーブルの情報が必要になる。そこで、図６に示す例では、「顧客情報用雛形テーブル」は単独でグループＧ１を構成しているのに対して、「注文情報用雛形テーブル」と「注文詳細情報用雛形テーブル」とは、２つ一緒にしてグループＧ２を構成している。
【００４０】
さて、ここでは、インターネットにおいて仮想ショッピングモールを運営している事業者からの依頼を受けて、当該仮想ショッピングモールでの受注処理に利用するためのデータベースシステムを設計する作業を考えてみよう。より具体的に、この仮想ショッピングモールには、本屋、肉屋、パン屋の３件の仮想ショップが存在し、それぞれ書籍、食肉、パンをインターネット上で販売しているものとし、このモールでの受注処理用データベースシステムを設計することにしよう。
【００４１】
この場合、設計者は、まず雛形テーブル選択手段２０によって、グループＧ１を選択し、「顧客情報用雛形テーブル」を抽出してくる。ここで、依頼主から、顧客については、顧客ＩＤ，アカウント，パスワード，住所，氏名という５つのフィールドを設定して欲しい旨の指示が与えられていたとすると、図６に示す「顧客情報用雛形テーブル」には、顧客ＩＤ，アカウント，パスワードは基本フィールドとして既に定義されているので、住所，氏名という２つのフィールドを、新たに追加フィールドとして設定すればよいことがわかる。そこで、カスタマイズテーブル作成手段３０を利用して、「顧客情報用雛形テーブル」に対するカスタマイズを行ってカスタマイズテーブルを作成し、これを「顧客情報用実テーブル」として用いるようにすればよい。
【００４２】
図７は、このようなカスタマイズ作業を行うための画面構成例を示す平面図である。設計者がカスタマイズテーブル作成手段３０に対して、「顧客情報用雛形テーブル」に対するカスタマイズ作業を行う旨の指示を与えると、ディスプレイ画面上に図示のような内容が表示されることになる。ここで、上段３１の表には、３つの基本フィールドである「顧客ＩＤ，アカウント，パスワード」について、予め設定されている構造定義の内容が示されている。設計者は、必要に応じて、任意の構造をもった新たなフィールドを追加フィールドとして付加したり、既存の基本フィールドの構造に修正を加えたりする操作を行うことができる。
【００４３】
図７に示す例では、中段３２の領域に、フィールドの構造定義を行うための入力欄が設けられている。新たなフィールドを追加する際には、これらの入力欄にそれぞれ所望の内容を入力して構造定義を行う。具体的には、項目名、コード名、サイズの各欄には、キーボードから所望の内容を入力する作業を行えばよいし、型の欄については、三角形の矢印をクリックすることにより出現するポップアップメニューから所望の型を選択すればよい。また、暗号化、ユニーク、ＮＵＬＬ、検索対象の欄については、肯定的な設定を行う場合に先頭の四角枠内をクリックしてチェックを入れるようにすればよい。こうして、新たに追加するフィールドについての構造定義が完了したら、下段３３の領域の登録ボタンをクリックすれば、当該追加フィールドが新たに追加されることになり、上段３１の表に、その内容が表示されることになる。
【００４４】
一方、上段３１の表において、いずれかの行をクリックして選択状態にした後、下段３３の変更ボタンをクリックすれば、中段３２の各欄の入力内容によって、上段３１の選択行の内容が書き換えられ、構造定義の変更を行うことができる。また、下段３３のクリアボタンは、中段３２の各欄をクリアするためのボタンであり、削除ボタンは、上段３１で選択状態にした行の内容を削除するためのボタンである。設計者が、こうしてカスタマイズを完了した後、下段３３の保存ボタンをクリックすれば、カスタマイズテーブルが作成され、保存されることになる。なお、下段３３の戻るボタンは、雛形テーブル選択手段２０による選択操作に戻るためのボタンである。
【００４５】
なお、ここに示す実施形態では、あるフィールドについて、暗号化の欄を「あり」に設定した場合には、当該フィールドについては、検索対象の欄を「ＹＥＳ」にする設定ができないような制限を課するようにしている。具体的には、中段３２の暗号化の四角枠内の欄にチェックが入れられた後は、検索対象の欄にチェックを入れるような指示が与えられても、当該指示は無視され、検索対象の欄にはチェックが入らないようにしている。また、既に、検索対象の欄にチェックが入れられた状態において、暗号化の欄にチェックが入れられたときには、検索対象の欄のチェックがキャンセルされる仕様にしてある。これは、暗号化を「あり」に設定したフィールド内のデータは、所定の暗号化アルゴリズムに基づいて暗号化された後、データベースＤＢ内に格納されることになるため、当該データを検索キーとする検索処理を行うことができないためである。
【００４６】
同様に、暗号化の欄を「あり」に設定した場合には、ユニークの欄を「ＹＥＳ」にする設定ができないような制限も課せられるようにしている。これは、やはり暗号化を「あり」に設定したフィールド内のデータが、暗号化された状態でデータベースＤＢ内に格納されることになり、当該フィールド内のデータがユニークであるか否かを確認することができなくなるためである。このように、基本フィールドに対する構造修正に制限を設け、設計者から、この制限の許容範囲外の修正指示が与えられた場合には、当該指示が無視されるような仕様にしておけば、不適切なカスタマイズ作業が実施されることを事前に防ぐことができ便利である。
【００４７】
また、一般に、何らかのデータに対して暗号化処理を行うと、暗号化されたデータは元のデータよりもデータ量が大きくなる。そこで、本実施形態では、暗号化の欄を「あり」に設定したフィールドについては、暗号化処理後のデータ量に適合した格納領域を確保したテーブル構築を行う機能をもたせている。
【００４８】
以上、カスタマイズテーブル作成手段３０によるカスタマイズ操作を行うための表示画面の一例を示したが、もちろん、本発明を実施する上では、どのような表示画面でカスタマイズを実施してもかまわない。図７は、具体的な画面構成の一例を示すものであり、本発明は、このような画面構成に何ら限定されるものではない。
【００４９】
図８は、このようなカスタマイズ操作を行うことにより、合計５つの実テーブルを作成し、データベース構築手段４０によって、実際のデータベースＤＢを構築した状態を示すブロック図である。図示のとおり、このデータベースＤＢは、顧客情報用実テーブルＴ１，注文情報用実テーブルＴ２，注文詳細情報用実テーブル（本屋）Ｔ３，注文詳細情報用実テーブル（肉屋）Ｔ４，注文詳細情報用実テーブル（パン屋）Ｔ５という５つの実テーブルによって構成されている。
【００５０】
この図８において、太線枠で示すフィールドは、雛形テーブル格納手段１０内の各雛形テーブルに予め用意されていた基本フィールドを示し、太線の矢印は、予め定義されていたリレーションシップを示す。したがって、これらの各フィールドやリレーションシップについては、設計者は設定作業を行う必要はない。
【００５１】
顧客情報用実テーブルＴ１は、図６に示す「顧客情報用雛形テーブル」に、住所，氏名という２つの追加フィールドを付加するカスタマイズ作業により得られたカスタマイズテーブルであり、注文情報用実テーブルＴ２は、図６に示す「注文情報用雛形テーブル」に、注文日という追加フィールドを付加するカスタマイズ作業により得られたカスタマイズテーブルである。もっとも、「注文情報用雛形テーブル」はグループＧ２に所属するテーブルであるため、「注文詳細情報用雛形テーブル」も同時に選択されることになる。
【００５２】
図８に示す注文詳細情報用実テーブル（本屋）Ｔ３，注文詳細情報用実テーブル（肉屋）Ｔ４，注文詳細情報用実テーブル（パン屋）Ｔ５は、いずれも図６に示す「注文詳細情報用雛形テーブル」に対するカスタマイズ作業により得られたカスタマイズテーブルであるが、それぞれ追加フィールドが異なっている。すなわち、注文詳細情報用実テーブル（本屋）Ｔ３では、ＩＳＢＮ，冊数，定価という書籍の注文に適した追加フィールドが付加されており、注文詳細情報用実テーブル（肉屋）Ｔ４では、部位，単価，ｇ数という食肉の注文に適した追加フィールドが付加されており、注文詳細情報用実テーブル（パン屋）Ｔ５では、種類、価格、個数というパンの注文に適した追加フィールドが付加されている。このように、同一の雛形テーブルを用いても、カスタマイズの内容が異なれば、それぞれ異なる実テーブルを作成することができる。ただ、基本フィールドについて予め定義されていたリレーションシップは、そのまま維持されており、図示の例では、テーブルＴ３，Ｔ４，Ｔ５のいずれについても、それぞれの注文ＩＤフィールドと、テーブルＴ２の注文ＩＤフィールドとの間に、リレーションシップが定義された状態になっている。
【００５３】
このように、図８に示すデータベースＤＢを、図６に示す雛形テーブルを利用して作成すれば、設計者によって行うべき、フィールド構造定義やリレーションシップ定義の作業が極力減らされることになり、設計者の作業負担を大幅に軽減することができる。しかも、必要に応じてカスタマイズを行うことにより、本屋，肉屋，パン屋といった異なるジャンルの商品の注文にも柔軟に対応したデータベースの構築が可能になる。
【００５４】
【発明の効果】
以上のとおり、本発明に係るデータベースシステムの設計装置によれば、予め用意された雛形テーブルを利用した設計を行うことができるようにしたため、設計者の作業の労力をできるだけ軽減することが可能になる。
【図面の簡単な説明】
【図１】複数のテーブルから構成される一般的なデータベースシステムの一例を示すブロック図である。
【図２】図１に示す個人情報テーブルＴ１を構成する６つのフィールドに関する構造定義の一例を示す表である。
【図３】本発明の一実施形態に係るデータベースシステムの設計装置の基本構成を示すブロック図である。
【図４】３種類の雛形テーブルＡ，Ｂ，Ｃについて予め定義されたリレーションシップの一例を太線の矢印で示すブロック図である。
【図５】図３に示すデータベースシステムの設計装置における雛形テーブル格納手段１０内に格納する各雛形テーブルにグループ定義を行った例を示すブロック図である。
【図６】図３に示すデータベースシステムの設計装置における雛形テーブル格納手段１０内に格納されている雛形テーブルの具体例を示すブロック図である。
【図７】図６に示す顧客情報用雛形テーブルに対するカスタマイズ作業を行うための画面構成例を示す平面図である。
【図８】図６に示す各雛形テーブルに対して、それぞれカスタマイズ操作を行うことにより、合計５つの実テーブルを作成し、実際のデータベースを構築した状態を示すブロック図である。
【符号の説明】
１０…雛形テーブル格納手段
２０…雛形テーブル選択手段
３０…カスタマイズテーブル作成手段
３１…カスタマイズ作業画面の上段
３２…カスタマイズ作業画面の中段
３３…カスタマイズ作業画面の下段
４０…データベース構築手段
Ａ〜Ｆ…雛形テーブル
ＡＡ…カスタマイズテーブル
Ａ１〜Ａ３，Ｂ１〜Ｂ３，Ｃ１〜Ｃ３…基本フィールド
Ｇ１〜Ｇ３…雛形テーブルのグループ
ＤＢ…データベース
Ｔ１〜Ｔ５…データベースを構成する実テーブル
Ｘ１…追加フィールド
Claims (7)
- 複数のテーブルから構成されるデータベースシステムを設計する装置であって、
所定の基本フィールドの構造を定義した情報からなる雛形テーブルを複数種類格納した雛形テーブル格納手段と、
前記雛形テーブル格納手段から、設計者の指示に基づいて、所定の雛形テーブルを選択する雛形テーブル選択手段と、
前記雛形テーブル選択手段によって選択された雛形テーブルに対して、設計者の指示に基づいて、所定の追加フィールドの構造を定義する情報を付加することにより、基本フィールドと追加フィールドとの双方の構造を定義した情報からなるカスタマイズテーブルを作成するカスタマイズテーブル作成手段と、
前記雛形テーブル選択手段によって選択された雛形テーブルもしくは前記カスタマイズテーブル作成手段によって作成されたカスタマイズテーブルを、設計対象となるデータベースシステムを構成する実テーブル群として用い、データベースを構築するデータベース構築手段と、
を備えることを特徴とするデータベースシステムの設計装置。 - 請求項１に記載の設計装置において、
雛形テーブル格納手段内に格納されている複数種類の雛形テーブル間に、予め所定のリレーションシップが定義されていることを特徴とするデータベースシステムの設計装置。 - 請求項１または２に記載の設計装置において、
カスタマイズテーブル作成手段が、雛形テーブル選択手段によって選択された雛形テーブルの基本フィールドに対して、設計者の指示に基づいて、構造の修正を行うことにより、カスタマイズテーブルを作成する機能を有することを特徴とするデータベースシステムの設計装置。 - 請求項３に記載の設計装置において、
基本フィールドに対する構造修正に制限を設け、設計者から、この制限の許容範囲外の修正指示が与えられた場合には、当該指示が無視されるようにしたことを特徴とするデータベースシステムの設計装置。 - 請求項１〜４のいずれかに記載の設計装置において、
１つもしくは複数の雛形テーブルを包含するグループを定義し、雛形テーブル選択手段が、グループ単位で雛形テーブルの選択を行うことができるようにしたことを特徴とするデータベースシステムの設計装置。 - 請求項１〜５のいずれかに記載の設計装置において、
カスタマイズテーブル作成手段が、同一の雛形テーブルにそれぞれ異なる追加フィールドを追加することにより、もしくは、同一の雛形テーブルにそれぞれ異なる修正を加えることにより、互いに異なる複数のカスタマイズテーブルを作成する機能を有し、
データベース構築手段が、前記複数のカスタマイズテーブルを実テーブル群として用いてデータベースの構築を行うことを特徴とするデータベースシステムの設計装置。 - 請求項１〜６のいずれかに記載の設計装置において、
各フィールドの構造として、少なくとも、フィールド名、フィールドサイズ、フィールド属性が定義されることを特徴とするデータベースシステムの設計装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003037756A JP2004246755A (ja) | 2003-02-17 | 2003-02-17 | データベースシステムの設計装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003037756A JP2004246755A (ja) | 2003-02-17 | 2003-02-17 | データベースシステムの設計装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004246755A true JP2004246755A (ja) | 2004-09-02 |
Family
ID=33022458
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003037756A Pending JP2004246755A (ja) | 2003-02-17 | 2003-02-17 | データベースシステムの設計装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004246755A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011008443A (ja) * | 2009-06-24 | 2011-01-13 | Mitsubishi Electric Corp | データベース定義生成装置及びデータベース設計装置及びデータベース構築システム及びコンピュータプログラム及びデータベース定義生成方法 |
| US8375057B2 (en) | 2009-12-09 | 2013-02-12 | Toshiba Tec Kabushiki Kaisha | Database system, server device, terminal device, and data presentation method |
| US8380746B2 (en) | 2009-12-15 | 2013-02-19 | Toshiba Tec Kabushiki Kaisha | Database system, terminal apparatus, and method of generating display image |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1125126A (ja) * | 1997-07-08 | 1999-01-29 | N T T Data:Kk | システム設計ツール及びデータウエアハウス設計システム及び方法 |
| JP2000285128A (ja) * | 1999-03-31 | 2000-10-13 | Toshiba System Kaihatsu Kk | 業務分析システム |
| JP2002334112A (ja) * | 2001-03-02 | 2002-11-22 | Smart Internet Solutions Kk | データベース管理システム及びプログラム |
-
2003
- 2003-02-17 JP JP2003037756A patent/JP2004246755A/ja active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1125126A (ja) * | 1997-07-08 | 1999-01-29 | N T T Data:Kk | システム設計ツール及びデータウエアハウス設計システム及び方法 |
| JP2000285128A (ja) * | 1999-03-31 | 2000-10-13 | Toshiba System Kaihatsu Kk | 業務分析システム |
| JP2002334112A (ja) * | 2001-03-02 | 2002-11-22 | Smart Internet Solutions Kk | データベース管理システム及びプログラム |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011008443A (ja) * | 2009-06-24 | 2011-01-13 | Mitsubishi Electric Corp | データベース定義生成装置及びデータベース設計装置及びデータベース構築システム及びコンピュータプログラム及びデータベース定義生成方法 |
| US8375057B2 (en) | 2009-12-09 | 2013-02-12 | Toshiba Tec Kabushiki Kaisha | Database system, server device, terminal device, and data presentation method |
| US8380746B2 (en) | 2009-12-15 | 2013-02-19 | Toshiba Tec Kabushiki Kaisha | Database system, terminal apparatus, and method of generating display image |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8370378B2 (en) | Data display server, data display method and program thereof | |
| US5765167A (en) | Data file update processing apparatus | |
| US20030105771A1 (en) | Attribute driven dynamic tree structure | |
| KR20070105252A (ko) | 전자 상거래 시스템 | |
| JP2004070504A (ja) | 個人プロファイル情報に基づく情報検索方法及びシステム | |
| JP2009146334A (ja) | 電子商取引における商品情報選択画面の編集方法、電子商取引システムおよび電子商取引における商品情報選択画面の編集プログラム | |
| US6892357B2 (en) | Logistics management method and system | |
| JP2004246755A (ja) | データベースシステムの設計装置 | |
| JP2002133290A (ja) | 電子商取引を支援する方法、および電子商取引支援システム | |
| JP2004046540A (ja) | 家計簿作成支援システム | |
| GB2373071A (en) | Online shopping | |
| JP2004145646A (ja) | 電子本棚管理システム、電子本棚管理方法および電子本棚管理用プログラム | |
| JP7471602B2 (ja) | 情報処理装置及び情報処理方法 | |
| JPH09223175A (ja) | 販売業務支援方法 | |
| WO2000046720A2 (en) | Targeting and profiling participants in a modular system and method for processing transactions | |
| JP6197351B2 (ja) | 表示プログラム、表示方法及び表示装置 | |
| JP3047398B2 (ja) | ファイル処理装置 | |
| CN102893279A (zh) | 数据库,数据管理服务器,及数据管理程序 | |
| WO2000046723A2 (en) | Modular system and method for processing transactions | |
| JP6787768B2 (ja) | 文書管理システム、検索装置及び検索プログラム | |
| JP2002366805A (ja) | 電子商取引システム | |
| JP2007133792A (ja) | 電子商取引システムおよび方法並びにプログラム | |
| JP2007156639A (ja) | 外食産業向け業務管理システム、外食産業向け業務管理方法、外食産業向け業務管理プログラム | |
| Freeman et al. | SportsStore: Modifying and Deleting Data | |
| JP2003016315A (ja) | 容器包装製品開発システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060807 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061017 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070313 |