JPH06110749A - デ―タベ―スの再構成システム - Google Patents

Abstract

(57)【要約】 【目的】既に定義されたリレーションを第３正規形リレ
ーションに正規化し、リレーショナルデータベースを再
構成する。 【構成】データベース再構成システム１７は、リレーシ
ョナルデータベース１５１のテーブルを正規化すること
によって第３正規形のリレ―ションを生成するためのも
のであり、デ―タベ―ス管理システム１６と独立して存
在する。データベース再構成システム１７は、リレ―シ
ョナルデ―タベ―ス管理システム１６の提供するＳＱＬ
のようなデ―タ操作言語を用いて、デ―タベ―ス１５１
にアクセスする。デ―タベ―スの再構成時に、デ―タベ
―ス管理者は、指定したリレ―ションの正規化をデータ
ベース再構成システム１７に要求する。データベース再
構成システム１７は、指定されたリレーションを関数従
属性にしたがって第３正規形に変換する機能を提供す
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、リレ―ショナル・デ―
タベ―スの再構成に関する。

【０００２】

【従来の技術】リレ―ショナルデ―タベ―スの構成に関
わる基礎理論として、正規化理論が良く知られている。
この正規化理論は、例えば、増永良文著、リレ―ショナ
ル・デ―タベ―ス入門、デ―タモデル・ＳＱＬ・管理シ
ステム、サイエンス社発行に記載されている。

【０００３】同著にも記載されているように、リレ―シ
ョナルデ―タベ―スを設計する時には、第３正規形のリ
レ―ションを定義することが必要となる。もし、第３正
規形でないリレ―ションが定義されそのリレ―ションが
使用されると、リレ―ションを記憶するために必要な記
憶領域の増大、更新が必要となるテーブル内タプル数の
増大、といった問題が引き起こされる。この問題の発生
理由を説明するために、まず、正規化理論について簡単
に説明する。

【０００４】リレ―ショナルデ―タベ―スにおいて、関
数従属性に関して定義されるリレーションの正規形に
は、第１正規形、第２正規形、第３正規形がある。リレ
ーションが第１正規形（ｆｉｒｓｔ ｎｏｒｍａｌ ｆ
ｏｒｍ）であるとは、リレーションのどの属性の値もそ
れ以上は分解できない値となっていることをいう。従っ
て、属性の値に集合が現れたり、構造を持つデータが現
れるリレーションは第１正規形ではない。このことは、
前著では、リレ―ショナルデ―タベ―スにおいて第１正
規形であるリレ―ションは、“属性値として属性の値域
の直積、巾集合、直積の巾集合をとってはならない”と
規定している。

【０００５】リレーションが第２正規形（ｓｅｃｏｎｄ
ｎｏｒｍａｌ ｆｏｒｍ）であるとは、第１正規形の
リレーションの全てのキー無縁な属性が、そのリレーシ
ョンのどの候補キーにも全関数従属であることをいう。
また、リレーションが第３正規形（ｓｅｃｏｎｄ ｎｏ
ｒｍａｌ ｆｏｒｍ）であるとは、第１正規形のリレー
ションにおいて、どの属性もいずれかの候補キーに狭義
推移従属になることがないことをいう。具体的には、次
の通りである。

【０００６】例えば、図１９に示すリレ―ション［人事
給与表］において、属性［氏名］は、姓という値域と名
という値域の直積から値を取るので、そのリレ―ション
［人事給与表］は第１正規形ではない。このリレ―ショ
ンを第１正規形に正規化すると図２０に示すリレ―ショ
ン［人事給与］になる。

【０００７】図２０のリレ―ション［人事給与］におい
て属性［従業員番号、支給月］が主キ―である。ここで
主キ―は、リレ―ションに１つ以上存在する候補キ―か
ら一つ選ばれる。ただし、候補キ―とは、タプルを唯一
つに識別できる最少の属性集合である。主キ―の値はヌ
ルでないという制約がある。

【０００８】さて、図２０に示す第１正規形リレ―ショ
ン［人事給与］では、次のような問題が発生する。い
ま、新しい従業員である木村五郎を採用し、その従業員
番号を１００６、その配属先を営業二課とする。この情
報をタプルとしてリレ―ションに格納しようとすると、
まだ給料を支給していないので、属性［支給月］の値は
ヌルになる。これは主キ―はヌルではないという上記の
制約に矛盾し、タプルを挿入できない。また、鈴木太郎
が営業二課に移動したとすると、鈴木太郎に関する３つ
のタプルを同時に変更しなければならない。これは、１
つのデ―タの変更にも関わらず、複数のタプルを変更し
なければならないことを意味する。さらに、佐藤花子は
実は４月に採用された社員であり、３月に給料を受けて
いなかったとすると、そのタプルを削除しなければなら
ない。しかし、タプルを削除すると佐藤花子が設計二課
に属し、大阪で働いているという情報は消えてしまう。
このような問題をリレ―ションの更新不整合（update a
nomaly ）と呼ぶ。

【０００９】第１正規形リレ―ション［人事給与］では
上記のような更新時異常が発生するので、これを図２１
に示す２つの第２正規形リレ―ション［人事］と［給
与］に分割する。ここで、第２正規形リレ―ションと
は、前述したように、第１正規形リレ―ションであり、
非キ―属性が任意の候補キ―に完全従属するようなリレ
―ションである。ただし、属性Ｂが属性Ａに完全従属す
るとは、属性Ａの値が属性Ｂの値を関数的に決定し（属
性Ｂの値が属性Ａの値に関数的に従属し）、属性Ａの任
意の真部分集合である属性Ａ′の値が属性Ｂの値を関数
的に決定しない（属性Ｂの値が属性Ａ′の値に関数的に
従属しない）ことを言う。なお、このような属性間の従
属性を、関数従属性と呼ぶ。

【００１０】例えば、リレ―ション［人事給与］では非
キ―属性［氏名、所属、所在地］は候補キ―（主キ―）
［従業員番号、支給月］に対して関数従属であるだけで
なく、その真部分集合である属性［従業員番号］に対し
ても関数従属であるので、完全従属でない。したがっ
て、リレ―ション［人事給与］は第２正規形でない。

【００１１】一方、リレ―ション［人事］では非キ―属
性［氏名、属性、所在地］は候補キ―［従業員番号］に
対して完全従属であり、リレ―ション［給与］では非キ
―属性［給料］は候補キ―［従業員番号、支給月］に対
して完全従属であるから、リレ―ション［人事］はとも
に第２正規形である。

【００１２】ところで、第２正規形リレ―ション［人
事］でも、次のような更新不整合（更新時異常）が起こ
る。例えば、営業三課が新しく名古屋にできたとする。
この情報をタプルとしてそのリレ―ションに挿入しよう
とすると、主キ―である［従業員番号］の値がヌルにな
ってしまい、主キ―はヌルではないという上記の制約に
反する。また、リレ―ション［人事］において経理課の
田中二郎が退職したとすると、そのタプルを削除するこ
とにより、経理課が東京であるという情報がなくなって
しまう。さらに、営業一課の所在地が千葉に移ったとす
ると、営業一課に属する人に対応するタプルをすべて更
新しなければならない。

【００１３】第２正規形リレ―ション［人事］ではこの
ような更新時異常が起こるので、それを図２２に示す２
つの第３正規形のリレ―ション［従業員］と［組織］に
分割する。ここで、第３正規形リレ―ションとは、前述
したように、第２正規形リレ―ションであり、任意の非
キ―属性はそれ以外の非キ―属性に対して関数従属でな
いようなリレ―ションである。

【００１４】例えば、リレ―ション［人事］では、非キ
―属性［所在地］は非キ―属性［所属］に対して関数従
属であるから、それは第３正規形でない。一方、図２２
に示すリレ―ション［従業員］と［組織］では、ともに
非キ―属性が非キ―属性に対して関数従属でないので、
それらは第３正規形である。また、図２１に示すリレ―
ション［給与］もまた第３正規形である。したがって、
リレ―ション［従業員］、［組織］、［給与］からなる
デ―タベ―スでは、リレ―ションの更新時異常は起こら
ない。

【００１５】以上、リレ―ショナル・デ―タベ―スにお
ける正規化理論について述べた。第３正規形でないリレ
―ションが存在すると、上記のような更新時異常が起こ
る。したがって、従来からリレ―ショナルデ―タベ―ス
の設計時には、すべてのリレ―ションを第３正規形とな
るように属性を定義することが望まれていた。

【００１６】しかし、実際には、リレ―ションを定義す
るときに、属性間の関数従属性、完全従属性を正確に見
つけることは難しい作業である。また、多数のリレ―シ
ョンが多数の属性を持つ場合にはより困難な作業とな
る。それゆえ、リレ―ショナルデ―タベ―スの設計段階
で、すなわち、各リレ―ションの属性を定義する段階
で、定義されたリレ―ションの中に第３正規形でないも
のが存在する可能性は従来から高かった。そして、いく
つかの第３正規形でないリレ―ションを定義し、デ―タ
ベ―スを運用している場合でも、デ―タベ―ス管理者が
第３正規形でないリレ―ションの存在に気づかないこと
があった。例を用いてそのような場合を説明する。

【００１７】いま、デ―タベ―ス設計者が、図２０に示
すリレ―ション［人事給与］を定義したとする。そし
て、アプリケ―ションプログラマがリレ―ション［人事
給与］に対して次のようなプログラムを作成したとす
る。 ・プログラム１

【００１８】新しい従業員を採用した時には、その従業
員に新しい従業員番号を付け、属性［従業員番号、氏
名、支給月］に値を持つタプルをリレ―ション［人事給
与］に挿入する。ただし、属性［支給月］の値はダミ―
の値である９９９９．９９とする。 ・プログラム２

【００１９】従業員に給与を支給した時には、その従業
員に対するタプルを検索する。その従業員が新入社員の
場合には、検索したタプルの属性［給料、支給月］の値
を更新する。そうでない場合には、新しいタプルを作
り、挿入する。 ・プログラム３ 従業員の所属を変更した時には、その従業員に対するタ
プルの属性［所属、所在地］の値を更新する。 ・プログラム４ 従業員が退職した時には、その従業員に対するタプルを
削除する。このとき、例えば次のようなタプルの挿入、
更新、削除操作を実行することができる。

【００２０】１．木村五郎を新たに採用した場合には、
プログラム１を用いてタプル（１００６、木村五郎、Ｎ
ＵＬＬ、ＮＵＬＬ、ＮＵＬＬ、９９９９．９９）を挿入
する。

【００２１】２．木村五郎に対して１９９２年４月に２
００，０００円の給料を支給した場合には、プログラム
２を用いてタプルを（１００６、木村五郎、ＮＵＬＬ、
ＮＵＬＬ、２００，０００、１９９２．４）に更新す
る。

【００２２】３．木村五郎が営業二課に配属された場合
には、プログラム３を用いてタプルを（１００６、木村
五郎、営業二課、大阪、２００，０００、１９９２．
４）に更新する。

【００２３】４．以前から働いている鈴木太郎に対して
１９９２年４月に３５０，０００円の給料を支給した場
合には、プログラム２を用いてタプル（１００１、鈴木
太郎、営業一課、東京、３５０，０００、１９９２．
４）を挿入する。 ５．鈴木太郎の所属を営業二課に移動した場合には、プ
ログラム３を用いて従業員番号が１００１であるタプル
をすべて更新する。 ６．佐藤花子が退職した場合には、プログラム４を用い
て従業員番号が１００２であるタプルをすべて削除す
る。

【００２４】このようにリレ―ション［人事給与］に対
する挿入、更新、削除操作を実行することができるの
で、デ―タベ―ス管理者はそれが第３正規形でないこと
に気づかない。

【００２５】リレ―ショナルデ―タベ―スの設計時に第
３正規形でないリレ―ションを定義し、そのリレ―ショ
ンをそのまま用いている場合には、次のような問題があ
る。 １） リレ―ションを記憶するための領域が大きくな
る。 ２） ある更新操作に対して、更新すべきタプル数が多
くなる。

【００２６】まず、第１の問題点について説明する。ま
ず、図２０から図２２までに示すリレ―ションの記憶領
域を考える。図２０に示す第１正規形リレ―ション［人
事給与］には、従業員１００００人に対する５年間（５
×１２か月）の情報が保持されているとする。このと
き、タプル数は １００００×５×１２＝６０００００（Ｔuples ） であり、各属性の大きさが１０Ｂyte であるとすれば、
このリレ―ションに対して ６０００００×１０×６＝３６（ＭＢyte ）

【００２７】の記憶領域が必要である。リレ―ション
［人事給与］と同じ情報を図２１に示す２つのリレ―シ
ョンで保持するためには、リレ―ション［人事］に１０
０００タプル、リレ―ション［給与］に６０００００タ
プル必要であるから、リレ―ション［人事］には、 １００００×１０×４＝４００（ＫＢyte ） の記憶領域が必要となり、リレ―ション［給与］には、 ６０００００×１０×３＝１８（ＭＢyte ） の記憶領域が必要である。

【００２８】次に、リレ―ション［人事］と同じ情報を
図２２に示すリレ―ション［従業員］と［組織］で保持
する場合を考える。いま、リレ―ション［人事］は従業
員が２０人ずつ５００の課にそれぞれ配属されていると
すれば、リレ―ション［従業員］に１００００タプル、
リレ―ション［組織］に５００タプル保存されるから、
それぞれ １００００×１０×３＝３００（ＫＢyte ） ５００×１０×２＝１０（ＫＢyte ） の記憶領域が必要である。

【００２９】したがって、第１正規形リレ―ションの場
合に３６ＭＢyte の記憶領域が必要であった情報を、第
２正規形まで正規化すると１８．４ＭＢyte の記憶領域
で保持することができ、さらに第３正規形まで正規化す
ると１８．３１ＭＢyte の記憶領域で保持することがで
きる。このように第３正規形まで正規化されていないリ
レ―ションは、無駄な記憶領域を使用する。次に第２の
問題点について説明する。

【００３０】図２０に示すリレ―ション［人事給与］が
５年間の給与情報を保持しているとすると、例えば従業
員番号が１００１である鈴木太郎に対して６０タプル存
在する。このとき鈴木太郎の所属を営業一課から営業二
課に変更すれば、６０タプルをすべて更新しなければな
らない。一方、図２１に示すリレ―ション［人事］で
は、従業員番号が１００１である鈴木太郎に対するタプ
ルは１つしかなく、それを更新するだけでよい。また、
リレ―ション［人事］が営業一課に配属された従業員に
対するタプルを２０タプル保持しているとする。このと
き営業一課の所在地を東京から横浜へ移したとすれば、
その２０タプルをすべて更新しなければなない。一方、
図２２に示すリレ―ション［組織］では、営業一課に対
するタプルは１つしかなく、それを更新するだけでよ
い。

【００３１】このように正規化されていないリレ―ショ
ンほど、更新操作において更新しなければならないタプ
ル数が多くなる。一般にアクセスすべきタプル数が多く
なるほどディスク入出力回数が多くなるので、正規化さ
れていないリレ―ションでは、ディスク入出力回数の増
加によってデータベース処理性能の低下が引き起こされ
る。

【００３２】

【発明が解決しようとする課題】従来では、デ―タベ―
スの設計時に第３正規形でないリレ―ションが定義され
た場合には、そのリレ―ションがそのままデータベース
演算処理に使用されるので、そのリレ―ションを記憶す
るために必要な記憶領域の増大、および更新操作に対し
て更新すべきタプル数の増加が引き起こされる欠点があ
った。

【００３３】この発明はこのような点に鑑みてなされた
もので、定義されたリレ―ションを関数従属性に従って
正規化できるようにし、たとえデ―タベ―ス管理者が第
３正規形でないリレーションを定義した場合でもそのリ
レーションを第３正規形のリレーションに自動変換する
ことができるデ―タベ―スシステムを提供することを目
的とする。

【００３４】

【課題を解決するための手段および作用】本発明は、各
タプルを属性ごとに２次元のリレ―ションとして管理
し、各リレ―ションがタプルを唯一つに識別できる属性
の組である候補キ―を持つようなリレ―ショナルデ―タ
ベ―スの再構成システムであって、リレ―ションに既に
存在しているタプルの値を参照することにより、ある属
性集合が別の属性集合に関数従属であるかどうか判定す
る手段と、指定した属性集合に対する射影演算を行なう
ことにより、１つのリレ―ションを２つのリレ―ション
に分割する手段と、リレ―ションに含まれる互いに素な
属性集合ＡとＢに対して、属性集合Ａが前記候補キ―の
真部分集合であり、属性集合Ｂが前記候補キ―の補集合
である非キ―属性集合の部分集合であること、あるい
は、属性集合ＡとＢがともに非キ―属性集合の真部分集
合であることを判定する手段を備え、このような性質を
満たすと判定された属性集合ＡとＢに対して、属性集合
Ｂが属性集合Ａに関数従属であるかどうかを判定し、関
数従属であれば属性集合Ｂの補集合による射影と、属性
集合ＡとＢの和集合による射影とにリレ―ションを分割
することを特徴とする。

【００３５】このシステムにおいては、あるリレ―ショ
ンにおいて、属性集合Ａに対して属性集合Ｂが関数的に
従属することを命題Ｘ、属性集合Ａの値が等しいタプル
が複数存在する場合ならば、それのタプルの属性集合Ｂ
の値は等しいことを命題Ｙとする。命題Ｘは命題Ｙに対
して十分条件であるが、必要条件でない。つまり、命題
Ｘが成り立つならば常に命題Ｙは成り立つが、命題Ｙが
成り立つからといって常に命題Ｘが成り立つとは限らな
い。しかし、リレ―ションのタプル数が多い場合には、
命題Ｙが成り立つならば、命題Ｘが成り立つ可能性が高
い。なぜならば、この場合には、数多くのタプルに対し
て、属性集合Ａの値を決定すれば、対応するタプルの属
性集合Ｂの値を唯一つに決定できるという関数属性の性
質を確認できるからである。したがって、既にタプルが
存在するリレ―ションの属性集合間の関数従属性を判定
する手段として、判定すべき属性集合の値を用いること
ができる。関数従属性を判定できるならば、完全従属性
も判定できる。以上により、少なくとも第１正規形であ
るリレ―ションから、属性間の従属性を判定し、適切な
リレ―ションの分割を行なうことにより、第３正規形の
リレ―ションを作り上げることができる。

【００３６】

【実施例】図１に本発明のデータベースシステムの構成
を示す。このデータベースシステムは、ホストコンピュ
ータ１１およびこれに接続された端末１２を含むコンピ
ュータシステムによって実現される。ホストコンピュー
タ１１は、ＣＰＵ１３、メインメモリ１４、および磁気
ディスク装置１５を備えている。ＣＰＵ１３は、このホ
ストコンピュータ１１全体の動作を制御するためのもの
であり、メインメモリ１４に格納されたプログララムの
実行によって、データベース処理に係わる種々の演算、
および磁気ディスク装置１５の入出力制御を実行する。

【００３７】メインメモリ１４には、データベース管理
システム１６およびデータベース再構成システム１７が
それぞれ実行対象のプロセスとして格納される。データ
ベース管理システム１６は、ＳＱＬのようなデ―タ操作
言語を用いて磁気ディスク装置１５のリレーショナルデ
ータベース１５１の検索、更新等の各種のリレーショナ
ルデータベース演算をデータベース管理者に提供する。
また、データベース管理システム１６は、ビュー機能を
サポートする。このビュー機能は、端末１２を操作する
データベース管理者に対して様々な視点のテーブルの視
像を画面表示する機能である。バッファ１６１に読み出
されたリレーショナルデータベース１５１のテーブルは
その論理構造が異なるビューに変換され、それが端末１
２に画面表示される。データベース管理者は、画面表示
されたビューを参照しながらデータベースの検索等を行
なうことができる。また、データベース管理者は、デー
タベース管理システム１６を用いて、リレーショナルデ
ータベース設計のためのテーブル定義を行なう。

【００３８】データベース再構成システム１７は、リレ
ーショナルデータベース１５１のテーブルを正規化する
ことによって第３正規形のリレ―ションを生成するため
のものであり、デ―タベ―ス管理システム１６と独立し
て存在する。データベース再構成システム１７は、リレ
―ショナルデ―タベ―ス管理システム１６の提供するＳ
ＱＬのようなデ―タ操作言語を用いて、デ―タベ―ス１
５１にアクセスする。デ―タベ―スの再構成時に、デ―
タベ―ス管理者は、指定したリレ―ションの正規化をデ
ータベース再構成システム１７に要求する。デ―タベ―
ス管理者はこのときリレ―ションが第３正規形でないこ
とを認識している必要はない。なお、指定されたリレ―
ションには、既に多数のタプルが存在しているはずであ
る。データベース再構成システム１７は、デ―タベ―ス
管理者からの要求を受けて、まず指定されたリレ―ショ
ンの候補キ―を見つける。次に、リレ―ションを第１正
規形から第２正規形あるいは第３正規形に変換するため
に、属性間の関数従属性を判定し、リレ―ションを分割
する。もし、リレ―ションが既に第２正規形あるいは第
３正規形ならば、属性間の関数従属性を判定した段階で
それがわかる。次に、第２正規形のリレ―ションを第３
正規形に変換するために、属性間の関数従属性を判定
し、リレ―ションを分割する。もし、リレ―ションが既
に第３正規形ならば、属性間の関数従属性を判定した段
階でそれがわかる。最後に、データベース再構成システ
ム１７は、分割の結果としてできた複数のリレ―ション
から元のリレ―ションと同じビュ―を作成する。

【００３９】このように、データベース再構成システム
１７は、指定されたリレーションを関数従属性にしたが
って第３正規形に変換する機能を提供する。この機能
は、リレーション正規化プロセス１７１、関数従属性判
定プロセス１７２、リレーション分割プロセス１７３、
およびビュー作成プロセス１７４よって提供される。

【００４０】リレ―ション正規化プロセス１７１は、属
性間の関数従属性を判定するために、関数従属性判定プ
ロセス１７２を呼び出す。関数従属性判定プロセス１７
２は、指定された属性の値をデ―タベ―スから参照し、
属性間に関数従属性が存在するかどうか判定する。ま
た、リレ―ション正規化プロセス１７１１は、リレ―シ
ョンを分割するために、リレ―ション分割プロセス１７
３を呼び出す。さらに、リレ―ション正規化プロセス１
７１は、分割した結果できた複数のリレ―ションから元
のリレ―ションと同じビュ―を作成するためにビュ―作
成プロセス１７４をを呼び出す。

【００４１】図２に、データベース再構成システム１７
のリレ―ション正規化処理のフロ―を示す。図２におい
て、ステップ１０２からステップ１０５までが、第１正
規形リレ―ションを第２リレ―ションに正規化するため
の処理であり、ステップ１０６から１０９までが、第２
正規形リレ―ションを第３正規形リレ―ションに正規化
するための処理であることに注意されたい。

【００４２】まずステップ１０１では、指定されたリレ
―ションの候補キ―が調べられる。ここで、リレ―ショ
ン正規化プロセス１７１は、デ―タベ―スのシステム・
カタログを参照する質問を実行する。その結果、主キ―
である属性集合を見つけることができる。そして、主キ
―の補集合である属性集合の任意の部分集合に対して、
および主キ―の任意の真部分集合と主キ―の補集合であ
る属性集合の任意の部分集合との和集合に対して、その
属性値がすべてのタプルで異なるかどうかを調べる。例
えば、属性集合Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇを持つリレ
―ションＲの主キ―がＡ、Ｂ、Ｃである場合に、候補キ
―を探すための組合せは、図３に示す通りである。すべ
てのタプルで属性値が異なれば、その属性集合は候補キ
―である。すべての候補キ―を見つけたあと、その和集
合の補集合が非キ―属性の集合である。こうして見つけ
た候補キ―と非キ―属性集合をキ―属性情報として保存
する。

【００４３】次にステップ１０２では、リレーション正
規化プロセス１７１は、キ―属性情報を参照して、候補
キ―の任意の真部分集合と非キ―属性の任意の組合せを
作り、要素数の小さな候補キ―の真部分集合から順に組
合せを並べ換え、属性組合せ情報として保存する。図３
において、リレ―ションＲの候補キ―はＡ、Ｂ、Ｃのみ
である場合に、属性組合せ情報は図４に示す通りであ
る。ここで、図４において、矢印の右側に１つの属性と
して現れていないことに注意されたい。これは、関数従
属性に関して、Ａ、Ｂ、Ｃの真部分集合とＤ、Ｅ、Ｆ、
Ｇの部分集合の任意の組合せが、図４に示す組合せによ
り被覆されるからである。被覆の概念については、例え
ば、Ｊ．ＵＬＬＭＡＮ著、國井、大保訳、デ―タベ―ス
・システムの原理、第７章、日本コンピュ―タ協会発行
にも記載されているように、当業者によって良く知られ
ているので、ここではその詳細な説明は省略する。

【００４４】ステップ１０３では、属性組合せ情報の先
頭の組合せに対して、関数従属性が存在するかどうか調
べるために、リレーション正規化プロセス１７１が関数
従属性判定プロセス１７２を呼び出す。関数従属性判定
プロセス１７２は、例えば属性の組合せＡ→Ｄが与えら
れると、属性Ｄが属性Ａに関数属性であるかどうか調べ
るために、次のようなＳＱＬ文を実行する。 select Ａ，count （distinct Ｄ） from Ｒ group by Ａ having count（distinct Ｄ）＞１；

【００４５】このＳＱＬ文を実行した結果、１つもタプ
ルを検索できなければ、属性Ｄは属性Ａに関数従属であ
るが、タプルを検索できれば、属性Ｄは属性Ａに関数従
属でない。関数従属である場合には、Ａ→Ｄを従属性情
報として保存する。そして、属性組合せ情報からＡ→
Ｄ、および矢印の右側がＤであり、矢印の左側がＡの超
集合であるＡＢ→Ｄ、ＣＡ→Ｄを削除する。これは、ア
―ムストロングの公理系により、Ａ→Ｄが関数従属なら
ば、ＡＢ→Ｄ、ＣＡ→Ｄもまた関数従属であることを導
けるからである（ア―ムストロングの公理系について
は、Ｊ．ＵＬＬＭＡＮ著、國井、大保訳、デ―タベ―ス
・システムの原理、第７章、日本コンピュ―タ協会発行
を参照のこと）。関数従属ではない場合には、Ａ→Ｄを
属性組合せ情報から削除する。属性組合せ情報の要素が
なくなるまでステップ１０３を実行する。

【００４６】ステップ１０４では、従属性情報におい
て、矢印の右側が同じ属性であるすべての組合せから、
その左側の属性集合の和集合を計算する。その結果が候
補キ―に一致する場合には、それの組合せを従属性情報
から削除する。候補キ―に一致しない場合には、矢印の
両側がそれぞれの和集合であるような組合せに置換す
る。次に、矢印の左側が同じ属性集合であるすべての組
合せから、その右側の属性の和集合を計算し、矢印の両
側がそれぞれの和集合である組合せに置換する。

【００４７】例えば、図５に示すような従属性情報がス
テップ１０３で得られた場合には、まず矢印の右側が属
性ＦであるＡＢ→Ｆ、ＢＣ→Ｆから、矢印の左側の属性
集合ＡＢとＢＣの和集合を計算する。その結果はＡＢＣ
であり、これは候補キ―に一致するので、ＡＢ→Ｆ、Ｂ
Ｃ→Ｆを従属性情報から削除する。次に、矢印の左側が
属性ＡであるＡ→Ｄ、Ａ→Ｅ、Ａ→Ｇから、その右側の
属性ＤとＥとＧの和集合を計算する。その結果はＤＥＧ
であるので、Ａ→Ｄ、Ａ→Ｅ、Ａ→ＧをＡ→ＤＥＧに置
換する。結局、従属性情報は図６に示すようになる。

【００４８】ステップ１０５では、従属性情報の先頭の
関数従属性を用いてリレ―ションを分割するために、リ
レ―ション分割プロセス１７３を呼び出す。リレ―ショ
ン分割プロセス１７３は、元のリレ―ションを、関数従
属性を満たす属性集合への射影と、関数従属性を満たす
非キ―属性以外の属性集合への射影とに分割する。例え
ば、関数従属性Ａ→ＤＥＧによりリレ―ションＲを分割
するために、リレ―ション分割プロセス１７３は次のＳ
ＱＬ文を実行する。ただし、新しく作成されるリレ―シ
ョンをＳ、Ｔ、属性集合Ａのデ―タ型をＴＹＰＥ（Ａ）
で表すとする。 create table Ｓ（ＡＴＹＰＥ（Ａ），ＢＴＹＰＥ
（Ｂ），ＣＴＹＰＥ（Ｃ），ＦＴＹＰＥ（Ｆ））； insert into Ｓ（Ａ，Ｂ，Ｃ，Ｆ） select Ａ，Ｂ，Ｃ，Ｆ from Ｒ； create table Ｔ（ＡＴＹＰＥ（Ａ），ＤＴＹＰＥ
（Ｄ），ＥＴＹＰＥ（Ｅ），ＧＴＹＰＥ（Ｇ））； insert into Ｔ（Ａ，Ｄ，Ｅ，Ｇ） select Ａ，Ｄ，Ｅ，Ｇ fromＲ； drop tableＲ；

【００４９】上記のＳＱＬから元のリレ―ションをどの
ように分割したかという情報を分割情報として保存す
る。また、分割後にそれぞれのリレ―ションに対してキ
―属性情報を作成し、従属性情報から先頭の関数従属性
を取り除く。そして、ステップ１０５を従属性情報がな
くなるまで実行する。

【００５０】ステップ１０６では、各リレ―ションに関
するキ―属性情報を参照し、非キ―属性の数が２つ以上
であるリレ―ションについて以下の処理を行なう。キ―
属性情報を参照し、任意の非キ―属性集合の真部分集合
とその補集合の要素である属性との組合せを作り、要素
数が小さな集合から順に組合せを並べ換え、属性組合せ
情報として保存する。上記の分割を行なった後、非キ―
属性の数が２つ以上であるのはリレ―ションＴだけであ
るので、リレ―ションＴについて図７に属性組合せ情報
を示す。図７において、矢印の右側に１つの属性しか現
れないのは、ステップ１０２で述べた理由と同じであ
る。

【００５１】ステップ１０７では、ステップ１０６で作
成した属性組合せ情報の先頭の組合せに対して、関数従
属性が存在するかどうかを調べるために、関数従属性判
定手段２を呼び出す。関数従属性判定手段２は、例えば
属性の組合せＤ→Ｅが与えられると、属性Ｅが属性Ｄに
関数従属であるかどうか調べるために、次のようなＳＱ
Ｌ文を実行する。 select Ｄ，count （distinctＥ） from Ｔ group byＤ having count（distinctＥ）＞１；

【００５２】このＳＱＬ文を実行した結果、１つもタプ
ルを検索できなければ、属性Ｅは属性Ｄに関数従属であ
るが、タプルを検索できれば、属性Ｅは属性Ｄに関数従
属でない。関数従属である場合には、Ｄ→Ｅを従属性情
報をして保存する。そして、属性組合せ情報からＤ→Ｅ
と、矢印の右側がＥであり左側がＥの超集合であるＧＤ
→Ｅを削除する。さらに、矢印の右側が逆であるＥ→Ｄ
と、矢印の右側がＤであり左側がＥの超集合であるＥＧ
→Ｄを削除する。関数従属でない場合には、Ｄ→Ｅを属
性組合せ情報から削除する。属性組合せ情報の要素がな
くなるまでステップ１０７を実行する。

【００５３】ステップ１０８では、従属性情報におい
て、ある関数従属性Ｘにおいて矢印の右側の属性が、別
の関数従属性Ｙにおける矢印の左側の属性集合の部分集
合である場合には、ア―ムストロングの公理系を用いて
関数従属性Ｙを変換し、関数従属性Ｘにおける矢印の右
側の属性が関数従属性Ｙの矢印の左側に現れないように
する。例えば、図８に示すような従属性情報がステップ
１０７で得られた場合には、関数従属性Ｄ→Ｅの右側の
属性Ｅは別の関数従属性Ｅ→Ｇの左側の属性と等しいの
で、ア―ムストロングの公理系（推移律）を用いて、関
数従属性Ｅ→ＧをＤ→Ｇに置換する。その結果の従属性
情報を図９に示す。

【００５４】ステップ１０９では、従属性情報の先頭の
関数従属性を用いてリレ―ションを分割するために、リ
レ―ション分割プロセス１７３を呼び出す。リレ―ショ
ン分割プロセス１７３は、元のリレ―ションを、関数従
属性を満たす属性集合への射影と、関数従属性の矢印の
右側にある属性以外の属性集合への射影とに分割する。
例えば、関数従属性Ｄ→Ｅにより上記のリレ―ションＳ
（Ａ，Ｄ，Ｅ，Ｇ）を分割するために、リレ―ション分
割手段３は次のＳＱＬ文を実行する。 create table Ｕ（ＡＴＹＰＥ（Ａ），ＤＴＹＰＥ
（Ｄ），ＧＴＹＰＥ（Ｇ））； insert into Ｕ（Ａ，Ｄ，Ｇ） selectＡ，Ｄ，Ｇ fromＳ； create table Ｖ（ＤＴＹＰＥ（Ｄ），ＥＴＹＰＥ
（Ｅ））； insert into Ｖ（Ｄ，Ｅ） select Ｄ，Ｅ from Ｓ； drop table Ｓ；

【００５５】上記のＳＱＬから元のリレ―ションをどの
ように分割したかという情報を分割情報として保存す
る。また、従属性情報から先頭の関数従属性を取り除
く。そして、ステップ１０９を従属性情報がなくなるま
で実行する。

【００５６】ステップ１１０では、分割されたリレ―シ
ョンの集合から分割される前のリレ―ションと同じビュ
―を作成するために、ビュ―作成プロセス１７４を呼び
出す。ビュ―作成プロセス１７４は、分割情報を参照し
て、元のリレ―ションと同じビュ―を作成する。例え
ば、上記のように分割したリレ―ションＴ（Ａ，Ｂ，
Ｃ，Ｆ）、Ｕ（Ａ，Ｄ，Ｇ）、Ｖ（Ｄ，Ｅ）から元のリ
レ―ションＲと同じビュ―を提供するために、次のよう
なＳＱＬ文を実行する。 create view Ｒ（Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆ，Ｇ）as selectＴ．Ａ，Ｔ．Ｂ，Ｔ．Ｃ，Ｕ．Ｄ，Ｖ．Ｅ，Ｔ．
Ｆ，Ｕ．Ｇ fromＴ，Ｕ，Ｖ where Ｔ．Ａ＝Ｕ．Ａ＆Ｕ．Ｄ＝Ｖ．Ｄ； これにより、リレ―ションの分割をユ―ザ透過にでき
る。以上、リレ―ション正規化処理の手順について説明
した。次に、図２０に示すリレ―ションを例として用
い、さらに具体的に正規化の手順を説明する。

【００５７】まず、リレ―ション正規化プロセス１７１
は、システム・カタログに対してリレ―ション［人事給
与］の属性に関する情報を問い合わせる。その結果、属
性［従業員番号、支給月］の組が主キ―であることが分
かる。そして、｛氏名、所属、所在地、給料｝の部分集
合と、（｛氏名、所属、所在地、給料｝の部分集合と
｛従業員番号、給料｝の真部分集合の直積）との和集合

【００５８】の各要素である属性の組合せについて、そ
の属性値を調べる。その結果、属性値がすべてのタプル
で異なるような属性の組合せは存在しないことがわか
る。したがって、リレ―ション［人事給与］では、主キ
―が唯一の候補キ―であり、｛氏名、所属、所在地、給
料｝が非キ―属性集合である。

【００５９】次に、リレ―ション正規化プロセス１７１
は、候補キ―｛従業員番号、支給月｝の真部分集合であ
る｛従業員番号｝、｛支給月｝と非キ―属性である｛氏
名｝、｛所属｝、｛所在地｝、｛給料｝の組合せを作
る。その結果を図１０に示す。図１０に示す属性組合せ
情報の先頭にある組合せ従業員番号→氏名に対して、関
数従属性判定プロセス１７２を用いて関数従属性を判定
する。関数従属性プロセス判定プロセス１７２は、まず
次のようなＳＱＬ文をデ―タベ―ス管理システムに問い
合わせる。 select従業員番号，count(distinct氏名） from人事給与 group by従業員番号 baving count（distinct氏名）＞１；

【００６０】この質問は、１つのタプルを選択せずに終
了する。ゆえに、属性［氏名］は、［従業員番号］に関
数従属である。そこで、従属性情報に従業員番号→氏名
を保存し、属性組合せ情報から従業員番号→氏名を削除
する。次に、属性組合せ情報の先頭にある組合せ従業員
番号→所属に対して関数従属性を判定する。このような
判定を、属性組合せ情報のすべての組合せに対して行な
う。その結果、図１１に示す従属性情報が得られる。

【００６１】図１１に示す従属性情報において、矢印の
右が同じ属性である組合せは存在しない。矢印の左側が
同じ属性［従業員番号］である組合せは存在するので、
それら組合せを、左側の和集合｛従業員番号｝と右側の
和集合｛氏名、所属、所在地｝からなる組合せ従業員番
号→氏名・所属・所在地で置き換える（図１２）。図１
２に示す関数従属性を用いてリレ―ションを分割する。
そこで、リレ―ション分割プロセス１７３は次のような
ＳＱＬ文を実行する。 create table人事（従業員番号ＮＵＭＢＥＲ，氏名ＣＨ
ＡＲＡＣＴＥＲ，所属ＣＨＡＲＡＣＴＥＲ，所在地ＣＨ
ＡＲＡＣＴＥＲ）； insert into 人事（従業員番号、氏名、所属、所在地） select従業員番号、氏名、所属、所在地 from人事給与； create table給与（従業員番号ＮＵＭＢＥＲ，支給月Ｄ
ＡＴＥ，給料ＮＵＭＢＥＲ）； insert into 給与（従業員番号、支給月、給料） select従業員番号、支給月、給料 from人事給与； drop table人事給与；

【００６２】このＳＱＬ文を実行した結果を図２１に、
分割情報を図１３に、分割後の各リレ―ションのキ―属
性情報を図１４に示す。そして、図１２の従属性情報か
らこの関数従属性を取り除く。従属性情報はもはや存在
しないので、次に進む。

【００６３】リレ―ション［給与］には非キ―属性が１
つしかないので、以下ではリレ―ション［人事］につい
てのみ考える。リレ―ション［人事］の非キ―属性集合
は｛氏名、所属、所在地｝であるので、それらから図１
５に示す属性組合せ情報を作る。そして、図１５の属性
組合せ情報の先頭にある組合せ氏名→所属に対して、関
数従属性判定手段は次のＳＱＬを実行する。 select氏名，count(distinct所属） from人事 group by氏名 baving count（distinct所属）＞１；

【００６４】その結果を図１６に示す。この場合タプル
が検索されるので、所属は氏名に関数従属でない。そこ
で、氏名→所属を属性組合せ情報から削除し、次に、先
頭である組合せ氏名→所在地に対して、関数従属性を判
定する。この場合も関数従属でないので、その組合せを
属性組合せ情報から削除する。次に、先頭である組合せ
所属→所在地に対して関数従属性を判定する。この場合
には関数従属であるので、その組合せを従属性情報とし
て保存する。そして属性組合せ情報から、所属→所在地
と矢印の右側が所在地で左側が所属の超集合｛氏名、所
属｝である組合せ氏名・所属、→所在地を削除する。さ
らに、所在地→所属と氏名・所在地→所属も削除する。
これらの組合せを削除した後の属性組合せ情報を図１７
に示す。このような処理を図１７に示す属性組合せ情報
の組に対して実行する。

【００６５】上記の処理の結果、従属性情報は図１８に
示す関数従属性のみとなる。これを用いてリレ―ション
［人事］を分割する。そこで、リレ―ション分割プロセ
ス１７３は次のＳＱＬ文を実行する。 create table従業員（従業員番号ＮＵＭＢＥＲ），氏名
ＣＨＡＲＡＣＴＥＲ，所属ＣＨＡＲＡＣＴＥＲ）； insert into 従業員（従業員番号、氏名、所属） select従業員番号、氏名、所属 from人事； create table組織（課ＣＨＡＲＡＣＴＥＲ，所在地ＣＨ
ＡＲＡＣＴＥＲ）； insert into 組織（課、所在地） select所属、所在地 from人事； drop table人事；

【００６６】この結果を図２２に示す。分割情報を保存
し、従属性情報からこの関数従属性を削除する。従属性
情報に関数従属性がなくなるので、リレ―ションの分割
は終了する。

【００６７】最後に、リレ―ション［従業員］、［組
織］、［給与］から、元のリレ―ション［人事給与］と
同じビュ―を作成する。ビュ―作成プロセス１７４は、
分割情報を用いて、次のＳＱＬ文を実行する。 create view 人事給与（従業員番号、氏名、所属、所在
地、給料、支給月）as select従業員．従業員番号、従業員．氏名、従業員．所
属、組織．所在地、給与．給料、給与．支給月 from従業員、組織、給料 where 従業員．従業員番号＝給与．従業員番号＆ 従業員．所属＝組織．課； これにより、リレ―ションの分割はユ―ザに透過にな
る。

【００６８】以上のように、この実施例においては、属
性集合Ａに対して属性集合Ｂが関数的に従属することを
命題Ｘ、属性集合Ａの値が等しいタプルが複数存在する
場合ならば、それのタプルの属性集合Ｂの値は等しいこ
とを命題Ｙとした場合において、リレ―ションのタプル
数が多い場合には、命題Ｙが成り立つならば、命題Ｘが
成り立つ可能性が高いという性質を利用しており、関数
従属性を判定する手段として、判定すべき属性集合の値
を用いている。

【００６９】これにより、関数従属性を判定できるよう
になり、関数従属性を指標としてテーブルの分割を行な
うことができる。したがって、第１正規形であるリレ―
ションから、第３正規形のリレ―ションを作り上げるこ
とができる。以上説明した実施例に対して、例えば次の
ような追加、変更が可能である。 ・リレ―ションのタプル数がある値より大きくなった時
に自動的にリレ―ションの正規化を実行する手段を追加
する、あるいはそのように変更する。 ・リレ―ションが非正規形である場合にはリレ―ション
を第１正規形に変換する手段を追加する。 ・デ―タベ―ス管理者が、関数従属性の判定結果、リレ
―ションの分割結果などを確認し、必要ならばその結果
を変更できる手段を追加する。 ・第３正規形より高いレベルの正規化（ボイス・コッド
の正規形）を行なう手段を追加する。

【００７０】・リレ―ションにおける更新時異常を検出
する手段を追加する。そして、デ―タベ―ス管理者から
の要求だけでなく、更新時異常検出手段からの要求を受
けてリレ―ションを正規化するように変更する。 ・ヌル値が存在する属性を除外して、上記の実施例を適
用できるように変更する。なお、本発明は、上記の実施
例に限定されるものではなく、その要旨を逸脱しない範
囲で変更可能である。

【００７１】

【発明の効果】従来、デ―タベ―スの設計時に第３正規
形でないリレ―ションを定義し、そのリレ―ションをそ
のまま用いるような状況が多かった。そのためリレ―シ
ョンを記憶するための領域が大きくなり、またある更新
操作において更新されるタプル数が多くなるという問題
点があった。本発明により、デ―タベ―ス管理者が第３
正規形でないことを認識していないリレ―ションに対し
ても、リレ―ションの属性間の関数従属性を見つけ出
し、リレ―ションの分割による正規化を行なうことがで
きる。これにより、情報を損失することなくリレ―ショ
ンを記憶するための領域を小さくでき、また更新操作に
おける更新タプル数を少なくできる。

【図面の簡単な説明】

【図１】本発明の一実施例に係わるデータベースシステ
ムの構成を示すブロック図。

【図２】同実施例に設けられたデータベース再構成シス
テムによる正規化処理動作を説明するフローチャート。

【図３】同実施例における候補キ―を探すための属性の
組合せの一例を示す図。

【図４】同実施例における属性組合せ情報の一例を示す
図。

【図５】同実施例における従属性情報の一例を示す図。

【図６】同実施例における置換後の従属性情報一例を示
す図。

【図７】同実施例における属性組合せ情報の一例を示す
図。

【図８】同実施例における従属性情報の一例を示す図。

【図９】同実施例における置換後の従属性情報の一例を
示す図。

【図１０】同実施例における属性組合せ情報の一例を示
す図。

【図１１】同実施例における従属性情報の一例を示す
図。

【図１２】同実施例における置換後の従属性情報の一例
を示す図。

【図１３】同実施例における分割情報の一例を示す図。

【図１４】同実施例におけるキ―属性情報の一例を示す
図。

【図１５】同実施例における属性組合せ情報の一例を示
す図。

【図１６】同実施例におけるＳＱＬ文の実行結果の一例
を示す図。

【図１７】同実施例における関数従属性判定途中での属
性組合せ情報の一例を示す図。

【図１８】同実施例における従属性情報の一例を示す
図。

【図１９】通常の非正規形リレ―ションの一例を示す
図。

【図２０】通常の第１正規形リレ―ションの一例を示す
図。

【図２１】通常の第２正規形リレ―ションと第３正規形
リレ―ションの一例を示す図。

【図２２】通常の第３正規形リレ―ションの一例を示す
図。

【符号の説明】

１１…ホストコンピュータ、１２…端末、１３…ＣＰ
Ｕ、１４…メインメモリ、１５…ディスク、１６…デー
タベース管理システム、１７…データベース再構成シス
テム、１７１…リレーション正規化プロセス、１７２…
関数従属性判定プロセス、１７３…リレーション分割プ
ロセス、１７４…ビュー作成プロセス。

Claims (2)

【特許請求の範囲】
1. 【請求項１】 各タプルを属性ごとに２次元のリレ―シ
   ョンとして管理し、各リレ―ションがタプルを唯一つに
   識別できる属性の組である候補キ―を持つようなリレ―
   ショナルデ―タベ―スの再構成システムであって、 リレ―ションに既に存在しているタプルの値を参照する
   ことにより、ある属性集合が別の属性集合に関数従属で
   あるかどうかを判定する手段と、 指定した属性集合に対する射影演算を行なうことによ
   り、１つのリレ―ションを２つのリレ―ションに分割す
   る手段と、 リレ―ションに含まれる互いに素な属性集合ＡとＢに対
   して、属性集合Ａが前記候補キ―の真部分集合であり、
   属性集合Ｂが前記候補キ―の補集合である非キ―属性集
   合の部分集合であること、あるいは、属性集合ＡとＢが
   ともに非キ―属性集合の真部分集合であることを判定す
   る手段と、 この手段によって性質を満たすと判定された属性集合Ａ
   とＢに対して、属性集合Ｂが属性集合Ａに関数従属であ
   るかどうかを判定し、関数従属であれば属性集合Ｂの補
   集合による射影と、属性集合ＡとＢの和集合による射影
   とにリレ―ションを分割することを特徴とするデ―タベ
   ―スの再構成システム。
2. 【請求項２】 各タプルを属性ごとに２次元のリレ―シ
   ョンとして管理し、各リレ―ションがタプルを唯一つに
   識別できる属性の組である候補キ―を持つようなリレ―
   ショナルデ―タベ―スの再構成方法であって、 再構成対象のリレーションから候補キ―とそれ以外の非
   キ―属性との属性集合を抽出し、 前記抽出された候補キ―の新部分集合と前記非キ―属性
   の部分集合との組み合わせを作成し、 タプルの値を参照することにより、作成された属性の組
   み合わせそれぞれについて非キ―属性が候補キ―に関数
   属性であるか否かを調べ、 前記リレーションを、関数従属性を満たす属性集合への
   射影と、関数従属性を満たす非キ―属性以外の属性集合
   への射影とに分割するステップとを具備するデ―タベ―
   ス再構成方法。