JPH06110749A - デ―タベ―スの再構成システム - Google Patents
デ―タベ―スの再構成システムInfo
- Publication number
- JPH06110749A JPH06110749A JP4261334A JP26133492A JPH06110749A JP H06110749 A JPH06110749 A JP H06110749A JP 4261334 A JP4261334 A JP 4261334A JP 26133492 A JP26133492 A JP 26133492A JP H06110749 A JPH06110749 A JP H06110749A
- Authority
- JP
- Japan
- Prior art keywords
- relation
- attribute
- key
- normal form
- dependency
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【目的】既に定義されたリレーションを第3正規形リレ
ーションに正規化し、リレーショナルデータベースを再
構成する。 【構成】データベース再構成システム17は、リレーシ
ョナルデータベース151のテーブルを正規化すること
によって第3正規形のリレ―ションを生成するためのも
のであり、デ―タベ―ス管理システム16と独立して存
在する。データベース再構成システム17は、リレ―シ
ョナルデ―タベ―ス管理システム16の提供するSQL
のようなデ―タ操作言語を用いて、デ―タベ―ス151
にアクセスする。デ―タベ―スの再構成時に、デ―タベ
―ス管理者は、指定したリレ―ションの正規化をデータ
ベース再構成システム17に要求する。データベース再
構成システム17は、指定されたリレーションを関数従
属性にしたがって第3正規形に変換する機能を提供す
る。
ーションに正規化し、リレーショナルデータベースを再
構成する。 【構成】データベース再構成システム17は、リレーシ
ョナルデータベース151のテーブルを正規化すること
によって第3正規形のリレ―ションを生成するためのも
のであり、デ―タベ―ス管理システム16と独立して存
在する。データベース再構成システム17は、リレ―シ
ョナルデ―タベ―ス管理システム16の提供するSQL
のようなデ―タ操作言語を用いて、デ―タベ―ス151
にアクセスする。デ―タベ―スの再構成時に、デ―タベ
―ス管理者は、指定したリレ―ションの正規化をデータ
ベース再構成システム17に要求する。データベース再
構成システム17は、指定されたリレーションを関数従
属性にしたがって第3正規形に変換する機能を提供す
る。
Description
【0001】
【産業上の利用分野】本発明は、リレ―ショナル・デ―
タベ―スの再構成に関する。
タベ―スの再構成に関する。
【0002】
【従来の技術】リレ―ショナルデ―タベ―スの構成に関
わる基礎理論として、正規化理論が良く知られている。
この正規化理論は、例えば、増永良文著、リレ―ショナ
ル・デ―タベ―ス入門、デ―タモデル・SQL・管理シ
ステム、サイエンス社発行に記載されている。
わる基礎理論として、正規化理論が良く知られている。
この正規化理論は、例えば、増永良文著、リレ―ショナ
ル・デ―タベ―ス入門、デ―タモデル・SQL・管理シ
ステム、サイエンス社発行に記載されている。
【0003】同著にも記載されているように、リレ―シ
ョナルデ―タベ―スを設計する時には、第3正規形のリ
レ―ションを定義することが必要となる。もし、第3正
規形でないリレ―ションが定義されそのリレ―ションが
使用されると、リレ―ションを記憶するために必要な記
憶領域の増大、更新が必要となるテーブル内タプル数の
増大、といった問題が引き起こされる。この問題の発生
理由を説明するために、まず、正規化理論について簡単
に説明する。
ョナルデ―タベ―スを設計する時には、第3正規形のリ
レ―ションを定義することが必要となる。もし、第3正
規形でないリレ―ションが定義されそのリレ―ションが
使用されると、リレ―ションを記憶するために必要な記
憶領域の増大、更新が必要となるテーブル内タプル数の
増大、といった問題が引き起こされる。この問題の発生
理由を説明するために、まず、正規化理論について簡単
に説明する。
【0004】リレ―ショナルデ―タベ―スにおいて、関
数従属性に関して定義されるリレーションの正規形に
は、第1正規形、第2正規形、第3正規形がある。リレ
ーションが第1正規形(first normal f
orm)であるとは、リレーションのどの属性の値もそ
れ以上は分解できない値となっていることをいう。従っ
て、属性の値に集合が現れたり、構造を持つデータが現
れるリレーションは第1正規形ではない。このことは、
前著では、リレ―ショナルデ―タベ―スにおいて第1正
規形であるリレ―ションは、“属性値として属性の値域
の直積、巾集合、直積の巾集合をとってはならない”と
規定している。
数従属性に関して定義されるリレーションの正規形に
は、第1正規形、第2正規形、第3正規形がある。リレ
ーションが第1正規形(first normal f
orm)であるとは、リレーションのどの属性の値もそ
れ以上は分解できない値となっていることをいう。従っ
て、属性の値に集合が現れたり、構造を持つデータが現
れるリレーションは第1正規形ではない。このことは、
前著では、リレ―ショナルデ―タベ―スにおいて第1正
規形であるリレ―ションは、“属性値として属性の値域
の直積、巾集合、直積の巾集合をとってはならない”と
規定している。
【0005】リレーションが第2正規形(second
normal form)であるとは、第1正規形の
リレーションの全てのキー無縁な属性が、そのリレーシ
ョンのどの候補キーにも全関数従属であることをいう。
また、リレーションが第3正規形(second no
rmal form)であるとは、第1正規形のリレー
ションにおいて、どの属性もいずれかの候補キーに狭義
推移従属になることがないことをいう。具体的には、次
の通りである。
normal form)であるとは、第1正規形の
リレーションの全てのキー無縁な属性が、そのリレーシ
ョンのどの候補キーにも全関数従属であることをいう。
また、リレーションが第3正規形(second no
rmal form)であるとは、第1正規形のリレー
ションにおいて、どの属性もいずれかの候補キーに狭義
推移従属になることがないことをいう。具体的には、次
の通りである。
【0006】例えば、図19に示すリレ―ション[人事
給与表]において、属性[氏名]は、姓という値域と名
という値域の直積から値を取るので、そのリレ―ション
[人事給与表]は第1正規形ではない。このリレ―ショ
ンを第1正規形に正規化すると図20に示すリレ―ショ
ン[人事給与]になる。
給与表]において、属性[氏名]は、姓という値域と名
という値域の直積から値を取るので、そのリレ―ション
[人事給与表]は第1正規形ではない。このリレ―ショ
ンを第1正規形に正規化すると図20に示すリレ―ショ
ン[人事給与]になる。
【0007】図20のリレ―ション[人事給与]におい
て属性[従業員番号、支給月]が主キ―である。ここで
主キ―は、リレ―ションに1つ以上存在する候補キ―か
ら一つ選ばれる。ただし、候補キ―とは、タプルを唯一
つに識別できる最少の属性集合である。主キ―の値はヌ
ルでないという制約がある。
て属性[従業員番号、支給月]が主キ―である。ここで
主キ―は、リレ―ションに1つ以上存在する候補キ―か
ら一つ選ばれる。ただし、候補キ―とは、タプルを唯一
つに識別できる最少の属性集合である。主キ―の値はヌ
ルでないという制約がある。
【0008】さて、図20に示す第1正規形リレ―ショ
ン[人事給与]では、次のような問題が発生する。い
ま、新しい従業員である木村五郎を採用し、その従業員
番号を1006、その配属先を営業二課とする。この情
報をタプルとしてリレ―ションに格納しようとすると、
まだ給料を支給していないので、属性[支給月]の値は
ヌルになる。これは主キ―はヌルではないという上記の
制約に矛盾し、タプルを挿入できない。また、鈴木太郎
が営業二課に移動したとすると、鈴木太郎に関する3つ
のタプルを同時に変更しなければならない。これは、1
つのデ―タの変更にも関わらず、複数のタプルを変更し
なければならないことを意味する。さらに、佐藤花子は
実は4月に採用された社員であり、3月に給料を受けて
いなかったとすると、そのタプルを削除しなければなら
ない。しかし、タプルを削除すると佐藤花子が設計二課
に属し、大阪で働いているという情報は消えてしまう。
このような問題をリレ―ションの更新不整合(update a
nomaly )と呼ぶ。
ン[人事給与]では、次のような問題が発生する。い
ま、新しい従業員である木村五郎を採用し、その従業員
番号を1006、その配属先を営業二課とする。この情
報をタプルとしてリレ―ションに格納しようとすると、
まだ給料を支給していないので、属性[支給月]の値は
ヌルになる。これは主キ―はヌルではないという上記の
制約に矛盾し、タプルを挿入できない。また、鈴木太郎
が営業二課に移動したとすると、鈴木太郎に関する3つ
のタプルを同時に変更しなければならない。これは、1
つのデ―タの変更にも関わらず、複数のタプルを変更し
なければならないことを意味する。さらに、佐藤花子は
実は4月に採用された社員であり、3月に給料を受けて
いなかったとすると、そのタプルを削除しなければなら
ない。しかし、タプルを削除すると佐藤花子が設計二課
に属し、大阪で働いているという情報は消えてしまう。
このような問題をリレ―ションの更新不整合(update a
nomaly )と呼ぶ。
【0009】第1正規形リレ―ション[人事給与]では
上記のような更新時異常が発生するので、これを図21
に示す2つの第2正規形リレ―ション[人事]と[給
与]に分割する。ここで、第2正規形リレ―ションと
は、前述したように、第1正規形リレ―ションであり、
非キ―属性が任意の候補キ―に完全従属するようなリレ
―ションである。ただし、属性Bが属性Aに完全従属す
るとは、属性Aの値が属性Bの値を関数的に決定し(属
性Bの値が属性Aの値に関数的に従属し)、属性Aの任
意の真部分集合である属性A′の値が属性Bの値を関数
的に決定しない(属性Bの値が属性A′の値に関数的に
従属しない)ことを言う。なお、このような属性間の従
属性を、関数従属性と呼ぶ。
上記のような更新時異常が発生するので、これを図21
に示す2つの第2正規形リレ―ション[人事]と[給
与]に分割する。ここで、第2正規形リレ―ションと
は、前述したように、第1正規形リレ―ションであり、
非キ―属性が任意の候補キ―に完全従属するようなリレ
―ションである。ただし、属性Bが属性Aに完全従属す
るとは、属性Aの値が属性Bの値を関数的に決定し(属
性Bの値が属性Aの値に関数的に従属し)、属性Aの任
意の真部分集合である属性A′の値が属性Bの値を関数
的に決定しない(属性Bの値が属性A′の値に関数的に
従属しない)ことを言う。なお、このような属性間の従
属性を、関数従属性と呼ぶ。
【0010】例えば、リレ―ション[人事給与]では非
キ―属性[氏名、所属、所在地]は候補キ―(主キ―)
[従業員番号、支給月]に対して関数従属であるだけで
なく、その真部分集合である属性[従業員番号]に対し
ても関数従属であるので、完全従属でない。したがっ
て、リレ―ション[人事給与]は第2正規形でない。
キ―属性[氏名、所属、所在地]は候補キ―(主キ―)
[従業員番号、支給月]に対して関数従属であるだけで
なく、その真部分集合である属性[従業員番号]に対し
ても関数従属であるので、完全従属でない。したがっ
て、リレ―ション[人事給与]は第2正規形でない。
【0011】一方、リレ―ション[人事]では非キ―属
性[氏名、属性、所在地]は候補キ―[従業員番号]に
対して完全従属であり、リレ―ション[給与]では非キ
―属性[給料]は候補キ―[従業員番号、支給月]に対
して完全従属であるから、リレ―ション[人事]はとも
に第2正規形である。
性[氏名、属性、所在地]は候補キ―[従業員番号]に
対して完全従属であり、リレ―ション[給与]では非キ
―属性[給料]は候補キ―[従業員番号、支給月]に対
して完全従属であるから、リレ―ション[人事]はとも
に第2正規形である。
【0012】ところで、第2正規形リレ―ション[人
事]でも、次のような更新不整合(更新時異常)が起こ
る。例えば、営業三課が新しく名古屋にできたとする。
この情報をタプルとしてそのリレ―ションに挿入しよう
とすると、主キ―である[従業員番号]の値がヌルにな
ってしまい、主キ―はヌルではないという上記の制約に
反する。また、リレ―ション[人事]において経理課の
田中二郎が退職したとすると、そのタプルを削除するこ
とにより、経理課が東京であるという情報がなくなって
しまう。さらに、営業一課の所在地が千葉に移ったとす
ると、営業一課に属する人に対応するタプルをすべて更
新しなければならない。
事]でも、次のような更新不整合(更新時異常)が起こ
る。例えば、営業三課が新しく名古屋にできたとする。
この情報をタプルとしてそのリレ―ションに挿入しよう
とすると、主キ―である[従業員番号]の値がヌルにな
ってしまい、主キ―はヌルではないという上記の制約に
反する。また、リレ―ション[人事]において経理課の
田中二郎が退職したとすると、そのタプルを削除するこ
とにより、経理課が東京であるという情報がなくなって
しまう。さらに、営業一課の所在地が千葉に移ったとす
ると、営業一課に属する人に対応するタプルをすべて更
新しなければならない。
【0013】第2正規形リレ―ション[人事]ではこの
ような更新時異常が起こるので、それを図22に示す2
つの第3正規形のリレ―ション[従業員]と[組織]に
分割する。ここで、第3正規形リレ―ションとは、前述
したように、第2正規形リレ―ションであり、任意の非
キ―属性はそれ以外の非キ―属性に対して関数従属でな
いようなリレ―ションである。
ような更新時異常が起こるので、それを図22に示す2
つの第3正規形のリレ―ション[従業員]と[組織]に
分割する。ここで、第3正規形リレ―ションとは、前述
したように、第2正規形リレ―ションであり、任意の非
キ―属性はそれ以外の非キ―属性に対して関数従属でな
いようなリレ―ションである。
【0014】例えば、リレ―ション[人事]では、非キ
―属性[所在地]は非キ―属性[所属]に対して関数従
属であるから、それは第3正規形でない。一方、図22
に示すリレ―ション[従業員]と[組織]では、ともに
非キ―属性が非キ―属性に対して関数従属でないので、
それらは第3正規形である。また、図21に示すリレ―
ション[給与]もまた第3正規形である。したがって、
リレ―ション[従業員]、[組織]、[給与]からなる
デ―タベ―スでは、リレ―ションの更新時異常は起こら
ない。
―属性[所在地]は非キ―属性[所属]に対して関数従
属であるから、それは第3正規形でない。一方、図22
に示すリレ―ション[従業員]と[組織]では、ともに
非キ―属性が非キ―属性に対して関数従属でないので、
それらは第3正規形である。また、図21に示すリレ―
ション[給与]もまた第3正規形である。したがって、
リレ―ション[従業員]、[組織]、[給与]からなる
デ―タベ―スでは、リレ―ションの更新時異常は起こら
ない。
【0015】以上、リレ―ショナル・デ―タベ―スにお
ける正規化理論について述べた。第3正規形でないリレ
―ションが存在すると、上記のような更新時異常が起こ
る。したがって、従来からリレ―ショナルデ―タベ―ス
の設計時には、すべてのリレ―ションを第3正規形とな
るように属性を定義することが望まれていた。
ける正規化理論について述べた。第3正規形でないリレ
―ションが存在すると、上記のような更新時異常が起こ
る。したがって、従来からリレ―ショナルデ―タベ―ス
の設計時には、すべてのリレ―ションを第3正規形とな
るように属性を定義することが望まれていた。
【0016】しかし、実際には、リレ―ションを定義す
るときに、属性間の関数従属性、完全従属性を正確に見
つけることは難しい作業である。また、多数のリレ―シ
ョンが多数の属性を持つ場合にはより困難な作業とな
る。それゆえ、リレ―ショナルデ―タベ―スの設計段階
で、すなわち、各リレ―ションの属性を定義する段階
で、定義されたリレ―ションの中に第3正規形でないも
のが存在する可能性は従来から高かった。そして、いく
つかの第3正規形でないリレ―ションを定義し、デ―タ
ベ―スを運用している場合でも、デ―タベ―ス管理者が
第3正規形でないリレ―ションの存在に気づかないこと
があった。例を用いてそのような場合を説明する。
るときに、属性間の関数従属性、完全従属性を正確に見
つけることは難しい作業である。また、多数のリレ―シ
ョンが多数の属性を持つ場合にはより困難な作業とな
る。それゆえ、リレ―ショナルデ―タベ―スの設計段階
で、すなわち、各リレ―ションの属性を定義する段階
で、定義されたリレ―ションの中に第3正規形でないも
のが存在する可能性は従来から高かった。そして、いく
つかの第3正規形でないリレ―ションを定義し、デ―タ
ベ―スを運用している場合でも、デ―タベ―ス管理者が
第3正規形でないリレ―ションの存在に気づかないこと
があった。例を用いてそのような場合を説明する。
【0017】いま、デ―タベ―ス設計者が、図20に示
すリレ―ション[人事給与]を定義したとする。そし
て、アプリケ―ションプログラマがリレ―ション[人事
給与]に対して次のようなプログラムを作成したとす
る。 ・プログラム1
すリレ―ション[人事給与]を定義したとする。そし
て、アプリケ―ションプログラマがリレ―ション[人事
給与]に対して次のようなプログラムを作成したとす
る。 ・プログラム1
【0018】新しい従業員を採用した時には、その従業
員に新しい従業員番号を付け、属性[従業員番号、氏
名、支給月]に値を持つタプルをリレ―ション[人事給
与]に挿入する。ただし、属性[支給月]の値はダミ―
の値である9999.99とする。 ・プログラム2
員に新しい従業員番号を付け、属性[従業員番号、氏
名、支給月]に値を持つタプルをリレ―ション[人事給
与]に挿入する。ただし、属性[支給月]の値はダミ―
の値である9999.99とする。 ・プログラム2
【0019】従業員に給与を支給した時には、その従業
員に対するタプルを検索する。その従業員が新入社員の
場合には、検索したタプルの属性[給料、支給月]の値
を更新する。そうでない場合には、新しいタプルを作
り、挿入する。 ・プログラム3 従業員の所属を変更した時には、その従業員に対するタ
プルの属性[所属、所在地]の値を更新する。 ・プログラム4 従業員が退職した時には、その従業員に対するタプルを
削除する。このとき、例えば次のようなタプルの挿入、
更新、削除操作を実行することができる。
員に対するタプルを検索する。その従業員が新入社員の
場合には、検索したタプルの属性[給料、支給月]の値
を更新する。そうでない場合には、新しいタプルを作
り、挿入する。 ・プログラム3 従業員の所属を変更した時には、その従業員に対するタ
プルの属性[所属、所在地]の値を更新する。 ・プログラム4 従業員が退職した時には、その従業員に対するタプルを
削除する。このとき、例えば次のようなタプルの挿入、
更新、削除操作を実行することができる。
【0020】1.木村五郎を新たに採用した場合には、
プログラム1を用いてタプル(1006、木村五郎、N
ULL、NULL、NULL、9999.99)を挿入
する。
プログラム1を用いてタプル(1006、木村五郎、N
ULL、NULL、NULL、9999.99)を挿入
する。
【0021】2.木村五郎に対して1992年4月に2
00,000円の給料を支給した場合には、プログラム
2を用いてタプルを(1006、木村五郎、NULL、
NULL、200,000、1992.4)に更新す
る。
00,000円の給料を支給した場合には、プログラム
2を用いてタプルを(1006、木村五郎、NULL、
NULL、200,000、1992.4)に更新す
る。
【0022】3.木村五郎が営業二課に配属された場合
には、プログラム3を用いてタプルを(1006、木村
五郎、営業二課、大阪、200,000、1992.
4)に更新する。
には、プログラム3を用いてタプルを(1006、木村
五郎、営業二課、大阪、200,000、1992.
4)に更新する。
【0023】4.以前から働いている鈴木太郎に対して
1992年4月に350,000円の給料を支給した場
合には、プログラム2を用いてタプル(1001、鈴木
太郎、営業一課、東京、350,000、1992.
4)を挿入する。 5.鈴木太郎の所属を営業二課に移動した場合には、プ
ログラム3を用いて従業員番号が1001であるタプル
をすべて更新する。 6.佐藤花子が退職した場合には、プログラム4を用い
て従業員番号が1002であるタプルをすべて削除す
る。
1992年4月に350,000円の給料を支給した場
合には、プログラム2を用いてタプル(1001、鈴木
太郎、営業一課、東京、350,000、1992.
4)を挿入する。 5.鈴木太郎の所属を営業二課に移動した場合には、プ
ログラム3を用いて従業員番号が1001であるタプル
をすべて更新する。 6.佐藤花子が退職した場合には、プログラム4を用い
て従業員番号が1002であるタプルをすべて削除す
る。
【0024】このようにリレ―ション[人事給与]に対
する挿入、更新、削除操作を実行することができるの
で、デ―タベ―ス管理者はそれが第3正規形でないこと
に気づかない。
する挿入、更新、削除操作を実行することができるの
で、デ―タベ―ス管理者はそれが第3正規形でないこと
に気づかない。
【0025】リレ―ショナルデ―タベ―スの設計時に第
3正規形でないリレ―ションを定義し、そのリレ―ショ
ンをそのまま用いている場合には、次のような問題があ
る。 1) リレ―ションを記憶するための領域が大きくな
る。 2) ある更新操作に対して、更新すべきタプル数が多
くなる。
3正規形でないリレ―ションを定義し、そのリレ―ショ
ンをそのまま用いている場合には、次のような問題があ
る。 1) リレ―ションを記憶するための領域が大きくな
る。 2) ある更新操作に対して、更新すべきタプル数が多
くなる。
【0026】まず、第1の問題点について説明する。ま
ず、図20から図22までに示すリレ―ションの記憶領
域を考える。図20に示す第1正規形リレ―ション[人
事給与]には、従業員10000人に対する5年間(5
×12か月)の情報が保持されているとする。このと
き、タプル数は 10000×5×12=600000(Tuples ) であり、各属性の大きさが10Byte であるとすれば、
このリレ―ションに対して 600000×10×6=36(MByte )
ず、図20から図22までに示すリレ―ションの記憶領
域を考える。図20に示す第1正規形リレ―ション[人
事給与]には、従業員10000人に対する5年間(5
×12か月)の情報が保持されているとする。このと
き、タプル数は 10000×5×12=600000(Tuples ) であり、各属性の大きさが10Byte であるとすれば、
このリレ―ションに対して 600000×10×6=36(MByte )
【0027】の記憶領域が必要である。リレ―ション
[人事給与]と同じ情報を図21に示す2つのリレ―シ
ョンで保持するためには、リレ―ション[人事]に10
000タプル、リレ―ション[給与]に600000タ
プル必要であるから、リレ―ション[人事]には、 10000×10×4=400(KByte ) の記憶領域が必要となり、リレ―ション[給与]には、 600000×10×3=18(MByte ) の記憶領域が必要である。
[人事給与]と同じ情報を図21に示す2つのリレ―シ
ョンで保持するためには、リレ―ション[人事]に10
000タプル、リレ―ション[給与]に600000タ
プル必要であるから、リレ―ション[人事]には、 10000×10×4=400(KByte ) の記憶領域が必要となり、リレ―ション[給与]には、 600000×10×3=18(MByte ) の記憶領域が必要である。
【0028】次に、リレ―ション[人事]と同じ情報を
図22に示すリレ―ション[従業員]と[組織]で保持
する場合を考える。いま、リレ―ション[人事]は従業
員が20人ずつ500の課にそれぞれ配属されていると
すれば、リレ―ション[従業員]に10000タプル、
リレ―ション[組織]に500タプル保存されるから、
それぞれ 10000×10×3=300(KByte ) 500×10×2=10(KByte ) の記憶領域が必要である。
図22に示すリレ―ション[従業員]と[組織]で保持
する場合を考える。いま、リレ―ション[人事]は従業
員が20人ずつ500の課にそれぞれ配属されていると
すれば、リレ―ション[従業員]に10000タプル、
リレ―ション[組織]に500タプル保存されるから、
それぞれ 10000×10×3=300(KByte ) 500×10×2=10(KByte ) の記憶領域が必要である。
【0029】したがって、第1正規形リレ―ションの場
合に36MByte の記憶領域が必要であった情報を、第
2正規形まで正規化すると18.4MByte の記憶領域
で保持することができ、さらに第3正規形まで正規化す
ると18.31MByte の記憶領域で保持することがで
きる。このように第3正規形まで正規化されていないリ
レ―ションは、無駄な記憶領域を使用する。次に第2の
問題点について説明する。
合に36MByte の記憶領域が必要であった情報を、第
2正規形まで正規化すると18.4MByte の記憶領域
で保持することができ、さらに第3正規形まで正規化す
ると18.31MByte の記憶領域で保持することがで
きる。このように第3正規形まで正規化されていないリ
レ―ションは、無駄な記憶領域を使用する。次に第2の
問題点について説明する。
【0030】図20に示すリレ―ション[人事給与]が
5年間の給与情報を保持しているとすると、例えば従業
員番号が1001である鈴木太郎に対して60タプル存
在する。このとき鈴木太郎の所属を営業一課から営業二
課に変更すれば、60タプルをすべて更新しなければな
らない。一方、図21に示すリレ―ション[人事]で
は、従業員番号が1001である鈴木太郎に対するタプ
ルは1つしかなく、それを更新するだけでよい。また、
リレ―ション[人事]が営業一課に配属された従業員に
対するタプルを20タプル保持しているとする。このと
き営業一課の所在地を東京から横浜へ移したとすれば、
その20タプルをすべて更新しなければなない。一方、
図22に示すリレ―ション[組織]では、営業一課に対
するタプルは1つしかなく、それを更新するだけでよ
い。
5年間の給与情報を保持しているとすると、例えば従業
員番号が1001である鈴木太郎に対して60タプル存
在する。このとき鈴木太郎の所属を営業一課から営業二
課に変更すれば、60タプルをすべて更新しなければな
らない。一方、図21に示すリレ―ション[人事]で
は、従業員番号が1001である鈴木太郎に対するタプ
ルは1つしかなく、それを更新するだけでよい。また、
リレ―ション[人事]が営業一課に配属された従業員に
対するタプルを20タプル保持しているとする。このと
き営業一課の所在地を東京から横浜へ移したとすれば、
その20タプルをすべて更新しなければなない。一方、
図22に示すリレ―ション[組織]では、営業一課に対
するタプルは1つしかなく、それを更新するだけでよ
い。
【0031】このように正規化されていないリレ―ショ
ンほど、更新操作において更新しなければならないタプ
ル数が多くなる。一般にアクセスすべきタプル数が多く
なるほどディスク入出力回数が多くなるので、正規化さ
れていないリレ―ションでは、ディスク入出力回数の増
加によってデータベース処理性能の低下が引き起こされ
る。
ンほど、更新操作において更新しなければならないタプ
ル数が多くなる。一般にアクセスすべきタプル数が多く
なるほどディスク入出力回数が多くなるので、正規化さ
れていないリレ―ションでは、ディスク入出力回数の増
加によってデータベース処理性能の低下が引き起こされ
る。
【0032】
【発明が解決しようとする課題】従来では、デ―タベ―
スの設計時に第3正規形でないリレ―ションが定義され
た場合には、そのリレ―ションがそのままデータベース
演算処理に使用されるので、そのリレ―ションを記憶す
るために必要な記憶領域の増大、および更新操作に対し
て更新すべきタプル数の増加が引き起こされる欠点があ
った。
スの設計時に第3正規形でないリレ―ションが定義され
た場合には、そのリレ―ションがそのままデータベース
演算処理に使用されるので、そのリレ―ションを記憶す
るために必要な記憶領域の増大、および更新操作に対し
て更新すべきタプル数の増加が引き起こされる欠点があ
った。
【0033】この発明はこのような点に鑑みてなされた
もので、定義されたリレ―ションを関数従属性に従って
正規化できるようにし、たとえデ―タベ―ス管理者が第
3正規形でないリレーションを定義した場合でもそのリ
レーションを第3正規形のリレーションに自動変換する
ことができるデ―タベ―スシステムを提供することを目
的とする。
もので、定義されたリレ―ションを関数従属性に従って
正規化できるようにし、たとえデ―タベ―ス管理者が第
3正規形でないリレーションを定義した場合でもそのリ
レーションを第3正規形のリレーションに自動変換する
ことができるデ―タベ―スシステムを提供することを目
的とする。
【0034】
【課題を解決するための手段および作用】本発明は、各
タプルを属性ごとに2次元のリレ―ションとして管理
し、各リレ―ションがタプルを唯一つに識別できる属性
の組である候補キ―を持つようなリレ―ショナルデ―タ
ベ―スの再構成システムであって、リレ―ションに既に
存在しているタプルの値を参照することにより、ある属
性集合が別の属性集合に関数従属であるかどうか判定す
る手段と、指定した属性集合に対する射影演算を行なう
ことにより、1つのリレ―ションを2つのリレ―ション
に分割する手段と、リレ―ションに含まれる互いに素な
属性集合AとBに対して、属性集合Aが前記候補キ―の
真部分集合であり、属性集合Bが前記候補キ―の補集合
である非キ―属性集合の部分集合であること、あるい
は、属性集合AとBがともに非キ―属性集合の真部分集
合であることを判定する手段を備え、このような性質を
満たすと判定された属性集合AとBに対して、属性集合
Bが属性集合Aに関数従属であるかどうかを判定し、関
数従属であれば属性集合Bの補集合による射影と、属性
集合AとBの和集合による射影とにリレ―ションを分割
することを特徴とする。
タプルを属性ごとに2次元のリレ―ションとして管理
し、各リレ―ションがタプルを唯一つに識別できる属性
の組である候補キ―を持つようなリレ―ショナルデ―タ
ベ―スの再構成システムであって、リレ―ションに既に
存在しているタプルの値を参照することにより、ある属
性集合が別の属性集合に関数従属であるかどうか判定す
る手段と、指定した属性集合に対する射影演算を行なう
ことにより、1つのリレ―ションを2つのリレ―ション
に分割する手段と、リレ―ションに含まれる互いに素な
属性集合AとBに対して、属性集合Aが前記候補キ―の
真部分集合であり、属性集合Bが前記候補キ―の補集合
である非キ―属性集合の部分集合であること、あるい
は、属性集合AとBがともに非キ―属性集合の真部分集
合であることを判定する手段を備え、このような性質を
満たすと判定された属性集合AとBに対して、属性集合
Bが属性集合Aに関数従属であるかどうかを判定し、関
数従属であれば属性集合Bの補集合による射影と、属性
集合AとBの和集合による射影とにリレ―ションを分割
することを特徴とする。
【0035】このシステムにおいては、あるリレ―ショ
ンにおいて、属性集合Aに対して属性集合Bが関数的に
従属することを命題X、属性集合Aの値が等しいタプル
が複数存在する場合ならば、それのタプルの属性集合B
の値は等しいことを命題Yとする。命題Xは命題Yに対
して十分条件であるが、必要条件でない。つまり、命題
Xが成り立つならば常に命題Yは成り立つが、命題Yが
成り立つからといって常に命題Xが成り立つとは限らな
い。しかし、リレ―ションのタプル数が多い場合には、
命題Yが成り立つならば、命題Xが成り立つ可能性が高
い。なぜならば、この場合には、数多くのタプルに対し
て、属性集合Aの値を決定すれば、対応するタプルの属
性集合Bの値を唯一つに決定できるという関数属性の性
質を確認できるからである。したがって、既にタプルが
存在するリレ―ションの属性集合間の関数従属性を判定
する手段として、判定すべき属性集合の値を用いること
ができる。関数従属性を判定できるならば、完全従属性
も判定できる。以上により、少なくとも第1正規形であ
るリレ―ションから、属性間の従属性を判定し、適切な
リレ―ションの分割を行なうことにより、第3正規形の
リレ―ションを作り上げることができる。
ンにおいて、属性集合Aに対して属性集合Bが関数的に
従属することを命題X、属性集合Aの値が等しいタプル
が複数存在する場合ならば、それのタプルの属性集合B
の値は等しいことを命題Yとする。命題Xは命題Yに対
して十分条件であるが、必要条件でない。つまり、命題
Xが成り立つならば常に命題Yは成り立つが、命題Yが
成り立つからといって常に命題Xが成り立つとは限らな
い。しかし、リレ―ションのタプル数が多い場合には、
命題Yが成り立つならば、命題Xが成り立つ可能性が高
い。なぜならば、この場合には、数多くのタプルに対し
て、属性集合Aの値を決定すれば、対応するタプルの属
性集合Bの値を唯一つに決定できるという関数属性の性
質を確認できるからである。したがって、既にタプルが
存在するリレ―ションの属性集合間の関数従属性を判定
する手段として、判定すべき属性集合の値を用いること
ができる。関数従属性を判定できるならば、完全従属性
も判定できる。以上により、少なくとも第1正規形であ
るリレ―ションから、属性間の従属性を判定し、適切な
リレ―ションの分割を行なうことにより、第3正規形の
リレ―ションを作り上げることができる。
【0036】
【実施例】図1に本発明のデータベースシステムの構成
を示す。このデータベースシステムは、ホストコンピュ
ータ11およびこれに接続された端末12を含むコンピ
ュータシステムによって実現される。ホストコンピュー
タ11は、CPU13、メインメモリ14、および磁気
ディスク装置15を備えている。CPU13は、このホ
ストコンピュータ11全体の動作を制御するためのもの
であり、メインメモリ14に格納されたプログララムの
実行によって、データベース処理に係わる種々の演算、
および磁気ディスク装置15の入出力制御を実行する。
を示す。このデータベースシステムは、ホストコンピュ
ータ11およびこれに接続された端末12を含むコンピ
ュータシステムによって実現される。ホストコンピュー
タ11は、CPU13、メインメモリ14、および磁気
ディスク装置15を備えている。CPU13は、このホ
ストコンピュータ11全体の動作を制御するためのもの
であり、メインメモリ14に格納されたプログララムの
実行によって、データベース処理に係わる種々の演算、
および磁気ディスク装置15の入出力制御を実行する。
【0037】メインメモリ14には、データベース管理
システム16およびデータベース再構成システム17が
それぞれ実行対象のプロセスとして格納される。データ
ベース管理システム16は、SQLのようなデ―タ操作
言語を用いて磁気ディスク装置15のリレーショナルデ
ータベース151の検索、更新等の各種のリレーショナ
ルデータベース演算をデータベース管理者に提供する。
また、データベース管理システム16は、ビュー機能を
サポートする。このビュー機能は、端末12を操作する
データベース管理者に対して様々な視点のテーブルの視
像を画面表示する機能である。バッファ161に読み出
されたリレーショナルデータベース151のテーブルは
その論理構造が異なるビューに変換され、それが端末1
2に画面表示される。データベース管理者は、画面表示
されたビューを参照しながらデータベースの検索等を行
なうことができる。また、データベース管理者は、デー
タベース管理システム16を用いて、リレーショナルデ
ータベース設計のためのテーブル定義を行なう。
システム16およびデータベース再構成システム17が
それぞれ実行対象のプロセスとして格納される。データ
ベース管理システム16は、SQLのようなデ―タ操作
言語を用いて磁気ディスク装置15のリレーショナルデ
ータベース151の検索、更新等の各種のリレーショナ
ルデータベース演算をデータベース管理者に提供する。
また、データベース管理システム16は、ビュー機能を
サポートする。このビュー機能は、端末12を操作する
データベース管理者に対して様々な視点のテーブルの視
像を画面表示する機能である。バッファ161に読み出
されたリレーショナルデータベース151のテーブルは
その論理構造が異なるビューに変換され、それが端末1
2に画面表示される。データベース管理者は、画面表示
されたビューを参照しながらデータベースの検索等を行
なうことができる。また、データベース管理者は、デー
タベース管理システム16を用いて、リレーショナルデ
ータベース設計のためのテーブル定義を行なう。
【0038】データベース再構成システム17は、リレ
ーショナルデータベース151のテーブルを正規化する
ことによって第3正規形のリレ―ションを生成するため
のものであり、デ―タベ―ス管理システム16と独立し
て存在する。データベース再構成システム17は、リレ
―ショナルデ―タベ―ス管理システム16の提供するS
QLのようなデ―タ操作言語を用いて、デ―タベ―ス1
51にアクセスする。デ―タベ―スの再構成時に、デ―
タベ―ス管理者は、指定したリレ―ションの正規化をデ
ータベース再構成システム17に要求する。デ―タベ―
ス管理者はこのときリレ―ションが第3正規形でないこ
とを認識している必要はない。なお、指定されたリレ―
ションには、既に多数のタプルが存在しているはずであ
る。データベース再構成システム17は、デ―タベ―ス
管理者からの要求を受けて、まず指定されたリレ―ショ
ンの候補キ―を見つける。次に、リレ―ションを第1正
規形から第2正規形あるいは第3正規形に変換するため
に、属性間の関数従属性を判定し、リレ―ションを分割
する。もし、リレ―ションが既に第2正規形あるいは第
3正規形ならば、属性間の関数従属性を判定した段階で
それがわかる。次に、第2正規形のリレ―ションを第3
正規形に変換するために、属性間の関数従属性を判定
し、リレ―ションを分割する。もし、リレ―ションが既
に第3正規形ならば、属性間の関数従属性を判定した段
階でそれがわかる。最後に、データベース再構成システ
ム17は、分割の結果としてできた複数のリレ―ション
から元のリレ―ションと同じビュ―を作成する。
ーショナルデータベース151のテーブルを正規化する
ことによって第3正規形のリレ―ションを生成するため
のものであり、デ―タベ―ス管理システム16と独立し
て存在する。データベース再構成システム17は、リレ
―ショナルデ―タベ―ス管理システム16の提供するS
QLのようなデ―タ操作言語を用いて、デ―タベ―ス1
51にアクセスする。デ―タベ―スの再構成時に、デ―
タベ―ス管理者は、指定したリレ―ションの正規化をデ
ータベース再構成システム17に要求する。デ―タベ―
ス管理者はこのときリレ―ションが第3正規形でないこ
とを認識している必要はない。なお、指定されたリレ―
ションには、既に多数のタプルが存在しているはずであ
る。データベース再構成システム17は、デ―タベ―ス
管理者からの要求を受けて、まず指定されたリレ―ショ
ンの候補キ―を見つける。次に、リレ―ションを第1正
規形から第2正規形あるいは第3正規形に変換するため
に、属性間の関数従属性を判定し、リレ―ションを分割
する。もし、リレ―ションが既に第2正規形あるいは第
3正規形ならば、属性間の関数従属性を判定した段階で
それがわかる。次に、第2正規形のリレ―ションを第3
正規形に変換するために、属性間の関数従属性を判定
し、リレ―ションを分割する。もし、リレ―ションが既
に第3正規形ならば、属性間の関数従属性を判定した段
階でそれがわかる。最後に、データベース再構成システ
ム17は、分割の結果としてできた複数のリレ―ション
から元のリレ―ションと同じビュ―を作成する。
【0039】このように、データベース再構成システム
17は、指定されたリレーションを関数従属性にしたが
って第3正規形に変換する機能を提供する。この機能
は、リレーション正規化プロセス171、関数従属性判
定プロセス172、リレーション分割プロセス173、
およびビュー作成プロセス174よって提供される。
17は、指定されたリレーションを関数従属性にしたが
って第3正規形に変換する機能を提供する。この機能
は、リレーション正規化プロセス171、関数従属性判
定プロセス172、リレーション分割プロセス173、
およびビュー作成プロセス174よって提供される。
【0040】リレ―ション正規化プロセス171は、属
性間の関数従属性を判定するために、関数従属性判定プ
ロセス172を呼び出す。関数従属性判定プロセス17
2は、指定された属性の値をデ―タベ―スから参照し、
属性間に関数従属性が存在するかどうか判定する。ま
た、リレ―ション正規化プロセス1711は、リレ―シ
ョンを分割するために、リレ―ション分割プロセス17
3を呼び出す。さらに、リレ―ション正規化プロセス1
71は、分割した結果できた複数のリレ―ションから元
のリレ―ションと同じビュ―を作成するためにビュ―作
成プロセス174をを呼び出す。
性間の関数従属性を判定するために、関数従属性判定プ
ロセス172を呼び出す。関数従属性判定プロセス17
2は、指定された属性の値をデ―タベ―スから参照し、
属性間に関数従属性が存在するかどうか判定する。ま
た、リレ―ション正規化プロセス1711は、リレ―シ
ョンを分割するために、リレ―ション分割プロセス17
3を呼び出す。さらに、リレ―ション正規化プロセス1
71は、分割した結果できた複数のリレ―ションから元
のリレ―ションと同じビュ―を作成するためにビュ―作
成プロセス174をを呼び出す。
【0041】図2に、データベース再構成システム17
のリレ―ション正規化処理のフロ―を示す。図2におい
て、ステップ102からステップ105までが、第1正
規形リレ―ションを第2リレ―ションに正規化するため
の処理であり、ステップ106から109までが、第2
正規形リレ―ションを第3正規形リレ―ションに正規化
するための処理であることに注意されたい。
のリレ―ション正規化処理のフロ―を示す。図2におい
て、ステップ102からステップ105までが、第1正
規形リレ―ションを第2リレ―ションに正規化するため
の処理であり、ステップ106から109までが、第2
正規形リレ―ションを第3正規形リレ―ションに正規化
するための処理であることに注意されたい。
【0042】まずステップ101では、指定されたリレ
―ションの候補キ―が調べられる。ここで、リレ―ショ
ン正規化プロセス171は、デ―タベ―スのシステム・
カタログを参照する質問を実行する。その結果、主キ―
である属性集合を見つけることができる。そして、主キ
―の補集合である属性集合の任意の部分集合に対して、
および主キ―の任意の真部分集合と主キ―の補集合であ
る属性集合の任意の部分集合との和集合に対して、その
属性値がすべてのタプルで異なるかどうかを調べる。例
えば、属性集合A、B、C、D、E、F、Gを持つリレ
―ションRの主キ―がA、B、Cである場合に、候補キ
―を探すための組合せは、図3に示す通りである。すべ
てのタプルで属性値が異なれば、その属性集合は候補キ
―である。すべての候補キ―を見つけたあと、その和集
合の補集合が非キ―属性の集合である。こうして見つけ
た候補キ―と非キ―属性集合をキ―属性情報として保存
する。
―ションの候補キ―が調べられる。ここで、リレ―ショ
ン正規化プロセス171は、デ―タベ―スのシステム・
カタログを参照する質問を実行する。その結果、主キ―
である属性集合を見つけることができる。そして、主キ
―の補集合である属性集合の任意の部分集合に対して、
および主キ―の任意の真部分集合と主キ―の補集合であ
る属性集合の任意の部分集合との和集合に対して、その
属性値がすべてのタプルで異なるかどうかを調べる。例
えば、属性集合A、B、C、D、E、F、Gを持つリレ
―ションRの主キ―がA、B、Cである場合に、候補キ
―を探すための組合せは、図3に示す通りである。すべ
てのタプルで属性値が異なれば、その属性集合は候補キ
―である。すべての候補キ―を見つけたあと、その和集
合の補集合が非キ―属性の集合である。こうして見つけ
た候補キ―と非キ―属性集合をキ―属性情報として保存
する。
【0043】次にステップ102では、リレーション正
規化プロセス171は、キ―属性情報を参照して、候補
キ―の任意の真部分集合と非キ―属性の任意の組合せを
作り、要素数の小さな候補キ―の真部分集合から順に組
合せを並べ換え、属性組合せ情報として保存する。図3
において、リレ―ションRの候補キ―はA、B、Cのみ
である場合に、属性組合せ情報は図4に示す通りであ
る。ここで、図4において、矢印の右側に1つの属性と
して現れていないことに注意されたい。これは、関数従
属性に関して、A、B、Cの真部分集合とD、E、F、
Gの部分集合の任意の組合せが、図4に示す組合せによ
り被覆されるからである。被覆の概念については、例え
ば、J.ULLMAN著、國井、大保訳、デ―タベ―ス
・システムの原理、第7章、日本コンピュ―タ協会発行
にも記載されているように、当業者によって良く知られ
ているので、ここではその詳細な説明は省略する。
規化プロセス171は、キ―属性情報を参照して、候補
キ―の任意の真部分集合と非キ―属性の任意の組合せを
作り、要素数の小さな候補キ―の真部分集合から順に組
合せを並べ換え、属性組合せ情報として保存する。図3
において、リレ―ションRの候補キ―はA、B、Cのみ
である場合に、属性組合せ情報は図4に示す通りであ
る。ここで、図4において、矢印の右側に1つの属性と
して現れていないことに注意されたい。これは、関数従
属性に関して、A、B、Cの真部分集合とD、E、F、
Gの部分集合の任意の組合せが、図4に示す組合せによ
り被覆されるからである。被覆の概念については、例え
ば、J.ULLMAN著、國井、大保訳、デ―タベ―ス
・システムの原理、第7章、日本コンピュ―タ協会発行
にも記載されているように、当業者によって良く知られ
ているので、ここではその詳細な説明は省略する。
【0044】ステップ103では、属性組合せ情報の先
頭の組合せに対して、関数従属性が存在するかどうか調
べるために、リレーション正規化プロセス171が関数
従属性判定プロセス172を呼び出す。関数従属性判定
プロセス172は、例えば属性の組合せA→Dが与えら
れると、属性Dが属性Aに関数属性であるかどうか調べ
るために、次のようなSQL文を実行する。 select A,count (distinct D) from R group by A having count(distinct D)>1;
頭の組合せに対して、関数従属性が存在するかどうか調
べるために、リレーション正規化プロセス171が関数
従属性判定プロセス172を呼び出す。関数従属性判定
プロセス172は、例えば属性の組合せA→Dが与えら
れると、属性Dが属性Aに関数属性であるかどうか調べ
るために、次のようなSQL文を実行する。 select A,count (distinct D) from R group by A having count(distinct D)>1;
【0045】このSQL文を実行した結果、1つもタプ
ルを検索できなければ、属性Dは属性Aに関数従属であ
るが、タプルを検索できれば、属性Dは属性Aに関数従
属でない。関数従属である場合には、A→Dを従属性情
報として保存する。そして、属性組合せ情報からA→
D、および矢印の右側がDであり、矢印の左側がAの超
集合であるAB→D、CA→Dを削除する。これは、ア
―ムストロングの公理系により、A→Dが関数従属なら
ば、AB→D、CA→Dもまた関数従属であることを導
けるからである(ア―ムストロングの公理系について
は、J.ULLMAN著、國井、大保訳、デ―タベ―ス
・システムの原理、第7章、日本コンピュ―タ協会発行
を参照のこと)。関数従属ではない場合には、A→Dを
属性組合せ情報から削除する。属性組合せ情報の要素が
なくなるまでステップ103を実行する。
ルを検索できなければ、属性Dは属性Aに関数従属であ
るが、タプルを検索できれば、属性Dは属性Aに関数従
属でない。関数従属である場合には、A→Dを従属性情
報として保存する。そして、属性組合せ情報からA→
D、および矢印の右側がDであり、矢印の左側がAの超
集合であるAB→D、CA→Dを削除する。これは、ア
―ムストロングの公理系により、A→Dが関数従属なら
ば、AB→D、CA→Dもまた関数従属であることを導
けるからである(ア―ムストロングの公理系について
は、J.ULLMAN著、國井、大保訳、デ―タベ―ス
・システムの原理、第7章、日本コンピュ―タ協会発行
を参照のこと)。関数従属ではない場合には、A→Dを
属性組合せ情報から削除する。属性組合せ情報の要素が
なくなるまでステップ103を実行する。
【0046】ステップ104では、従属性情報におい
て、矢印の右側が同じ属性であるすべての組合せから、
その左側の属性集合の和集合を計算する。その結果が候
補キ―に一致する場合には、それの組合せを従属性情報
から削除する。候補キ―に一致しない場合には、矢印の
両側がそれぞれの和集合であるような組合せに置換す
る。次に、矢印の左側が同じ属性集合であるすべての組
合せから、その右側の属性の和集合を計算し、矢印の両
側がそれぞれの和集合である組合せに置換する。
て、矢印の右側が同じ属性であるすべての組合せから、
その左側の属性集合の和集合を計算する。その結果が候
補キ―に一致する場合には、それの組合せを従属性情報
から削除する。候補キ―に一致しない場合には、矢印の
両側がそれぞれの和集合であるような組合せに置換す
る。次に、矢印の左側が同じ属性集合であるすべての組
合せから、その右側の属性の和集合を計算し、矢印の両
側がそれぞれの和集合である組合せに置換する。
【0047】例えば、図5に示すような従属性情報がス
テップ103で得られた場合には、まず矢印の右側が属
性FであるAB→F、BC→Fから、矢印の左側の属性
集合ABとBCの和集合を計算する。その結果はABC
であり、これは候補キ―に一致するので、AB→F、B
C→Fを従属性情報から削除する。次に、矢印の左側が
属性AであるA→D、A→E、A→Gから、その右側の
属性DとEとGの和集合を計算する。その結果はDEG
であるので、A→D、A→E、A→GをA→DEGに置
換する。結局、従属性情報は図6に示すようになる。
テップ103で得られた場合には、まず矢印の右側が属
性FであるAB→F、BC→Fから、矢印の左側の属性
集合ABとBCの和集合を計算する。その結果はABC
であり、これは候補キ―に一致するので、AB→F、B
C→Fを従属性情報から削除する。次に、矢印の左側が
属性AであるA→D、A→E、A→Gから、その右側の
属性DとEとGの和集合を計算する。その結果はDEG
であるので、A→D、A→E、A→GをA→DEGに置
換する。結局、従属性情報は図6に示すようになる。
【0048】ステップ105では、従属性情報の先頭の
関数従属性を用いてリレ―ションを分割するために、リ
レ―ション分割プロセス173を呼び出す。リレ―ショ
ン分割プロセス173は、元のリレ―ションを、関数従
属性を満たす属性集合への射影と、関数従属性を満たす
非キ―属性以外の属性集合への射影とに分割する。例え
ば、関数従属性A→DEGによりリレ―ションRを分割
するために、リレ―ション分割プロセス173は次のS
QL文を実行する。ただし、新しく作成されるリレ―シ
ョンをS、T、属性集合Aのデ―タ型をTYPE(A)
で表すとする。 create table S(ATYPE(A),BTYPE
(B),CTYPE(C),FTYPE(F)); insert into S(A,B,C,F) select A,B,C,F from R; create table T(ATYPE(A),DTYPE
(D),ETYPE(E),GTYPE(G)); insert into T(A,D,E,G) select A,D,E,G fromR; drop tableR;
関数従属性を用いてリレ―ションを分割するために、リ
レ―ション分割プロセス173を呼び出す。リレ―ショ
ン分割プロセス173は、元のリレ―ションを、関数従
属性を満たす属性集合への射影と、関数従属性を満たす
非キ―属性以外の属性集合への射影とに分割する。例え
ば、関数従属性A→DEGによりリレ―ションRを分割
するために、リレ―ション分割プロセス173は次のS
QL文を実行する。ただし、新しく作成されるリレ―シ
ョンをS、T、属性集合Aのデ―タ型をTYPE(A)
で表すとする。 create table S(ATYPE(A),BTYPE
(B),CTYPE(C),FTYPE(F)); insert into S(A,B,C,F) select A,B,C,F from R; create table T(ATYPE(A),DTYPE
(D),ETYPE(E),GTYPE(G)); insert into T(A,D,E,G) select A,D,E,G fromR; drop tableR;
【0049】上記のSQLから元のリレ―ションをどの
ように分割したかという情報を分割情報として保存す
る。また、分割後にそれぞれのリレ―ションに対してキ
―属性情報を作成し、従属性情報から先頭の関数従属性
を取り除く。そして、ステップ105を従属性情報がな
くなるまで実行する。
ように分割したかという情報を分割情報として保存す
る。また、分割後にそれぞれのリレ―ションに対してキ
―属性情報を作成し、従属性情報から先頭の関数従属性
を取り除く。そして、ステップ105を従属性情報がな
くなるまで実行する。
【0050】ステップ106では、各リレ―ションに関
するキ―属性情報を参照し、非キ―属性の数が2つ以上
であるリレ―ションについて以下の処理を行なう。キ―
属性情報を参照し、任意の非キ―属性集合の真部分集合
とその補集合の要素である属性との組合せを作り、要素
数が小さな集合から順に組合せを並べ換え、属性組合せ
情報として保存する。上記の分割を行なった後、非キ―
属性の数が2つ以上であるのはリレ―ションTだけであ
るので、リレ―ションTについて図7に属性組合せ情報
を示す。図7において、矢印の右側に1つの属性しか現
れないのは、ステップ102で述べた理由と同じであ
る。
するキ―属性情報を参照し、非キ―属性の数が2つ以上
であるリレ―ションについて以下の処理を行なう。キ―
属性情報を参照し、任意の非キ―属性集合の真部分集合
とその補集合の要素である属性との組合せを作り、要素
数が小さな集合から順に組合せを並べ換え、属性組合せ
情報として保存する。上記の分割を行なった後、非キ―
属性の数が2つ以上であるのはリレ―ションTだけであ
るので、リレ―ションTについて図7に属性組合せ情報
を示す。図7において、矢印の右側に1つの属性しか現
れないのは、ステップ102で述べた理由と同じであ
る。
【0051】ステップ107では、ステップ106で作
成した属性組合せ情報の先頭の組合せに対して、関数従
属性が存在するかどうかを調べるために、関数従属性判
定手段2を呼び出す。関数従属性判定手段2は、例えば
属性の組合せD→Eが与えられると、属性Eが属性Dに
関数従属であるかどうか調べるために、次のようなSQ
L文を実行する。 select D,count (distinctE) from T group byD having count(distinctE)>1;
成した属性組合せ情報の先頭の組合せに対して、関数従
属性が存在するかどうかを調べるために、関数従属性判
定手段2を呼び出す。関数従属性判定手段2は、例えば
属性の組合せD→Eが与えられると、属性Eが属性Dに
関数従属であるかどうか調べるために、次のようなSQ
L文を実行する。 select D,count (distinctE) from T group byD having count(distinctE)>1;
【0052】このSQL文を実行した結果、1つもタプ
ルを検索できなければ、属性Eは属性Dに関数従属であ
るが、タプルを検索できれば、属性Eは属性Dに関数従
属でない。関数従属である場合には、D→Eを従属性情
報をして保存する。そして、属性組合せ情報からD→E
と、矢印の右側がEであり左側がEの超集合であるGD
→Eを削除する。さらに、矢印の右側が逆であるE→D
と、矢印の右側がDであり左側がEの超集合であるEG
→Dを削除する。関数従属でない場合には、D→Eを属
性組合せ情報から削除する。属性組合せ情報の要素がな
くなるまでステップ107を実行する。
ルを検索できなければ、属性Eは属性Dに関数従属であ
るが、タプルを検索できれば、属性Eは属性Dに関数従
属でない。関数従属である場合には、D→Eを従属性情
報をして保存する。そして、属性組合せ情報からD→E
と、矢印の右側がEであり左側がEの超集合であるGD
→Eを削除する。さらに、矢印の右側が逆であるE→D
と、矢印の右側がDであり左側がEの超集合であるEG
→Dを削除する。関数従属でない場合には、D→Eを属
性組合せ情報から削除する。属性組合せ情報の要素がな
くなるまでステップ107を実行する。
【0053】ステップ108では、従属性情報におい
て、ある関数従属性Xにおいて矢印の右側の属性が、別
の関数従属性Yにおける矢印の左側の属性集合の部分集
合である場合には、ア―ムストロングの公理系を用いて
関数従属性Yを変換し、関数従属性Xにおける矢印の右
側の属性が関数従属性Yの矢印の左側に現れないように
する。例えば、図8に示すような従属性情報がステップ
107で得られた場合には、関数従属性D→Eの右側の
属性Eは別の関数従属性E→Gの左側の属性と等しいの
で、ア―ムストロングの公理系(推移律)を用いて、関
数従属性E→GをD→Gに置換する。その結果の従属性
情報を図9に示す。
て、ある関数従属性Xにおいて矢印の右側の属性が、別
の関数従属性Yにおける矢印の左側の属性集合の部分集
合である場合には、ア―ムストロングの公理系を用いて
関数従属性Yを変換し、関数従属性Xにおける矢印の右
側の属性が関数従属性Yの矢印の左側に現れないように
する。例えば、図8に示すような従属性情報がステップ
107で得られた場合には、関数従属性D→Eの右側の
属性Eは別の関数従属性E→Gの左側の属性と等しいの
で、ア―ムストロングの公理系(推移律)を用いて、関
数従属性E→GをD→Gに置換する。その結果の従属性
情報を図9に示す。
【0054】ステップ109では、従属性情報の先頭の
関数従属性を用いてリレ―ションを分割するために、リ
レ―ション分割プロセス173を呼び出す。リレ―ショ
ン分割プロセス173は、元のリレ―ションを、関数従
属性を満たす属性集合への射影と、関数従属性の矢印の
右側にある属性以外の属性集合への射影とに分割する。
例えば、関数従属性D→Eにより上記のリレ―ションS
(A,D,E,G)を分割するために、リレ―ション分
割手段3は次のSQL文を実行する。 create table U(ATYPE(A),DTYPE
(D),GTYPE(G)); insert into U(A,D,G) selectA,D,G fromS; create table V(DTYPE(D),ETYPE
(E)); insert into V(D,E) select D,E from S; drop table S;
関数従属性を用いてリレ―ションを分割するために、リ
レ―ション分割プロセス173を呼び出す。リレ―ショ
ン分割プロセス173は、元のリレ―ションを、関数従
属性を満たす属性集合への射影と、関数従属性の矢印の
右側にある属性以外の属性集合への射影とに分割する。
例えば、関数従属性D→Eにより上記のリレ―ションS
(A,D,E,G)を分割するために、リレ―ション分
割手段3は次のSQL文を実行する。 create table U(ATYPE(A),DTYPE
(D),GTYPE(G)); insert into U(A,D,G) selectA,D,G fromS; create table V(DTYPE(D),ETYPE
(E)); insert into V(D,E) select D,E from S; drop table S;
【0055】上記のSQLから元のリレ―ションをどの
ように分割したかという情報を分割情報として保存す
る。また、従属性情報から先頭の関数従属性を取り除
く。そして、ステップ109を従属性情報がなくなるま
で実行する。
ように分割したかという情報を分割情報として保存す
る。また、従属性情報から先頭の関数従属性を取り除
く。そして、ステップ109を従属性情報がなくなるま
で実行する。
【0056】ステップ110では、分割されたリレ―シ
ョンの集合から分割される前のリレ―ションと同じビュ
―を作成するために、ビュ―作成プロセス174を呼び
出す。ビュ―作成プロセス174は、分割情報を参照し
て、元のリレ―ションと同じビュ―を作成する。例え
ば、上記のように分割したリレ―ションT(A,B,
C,F)、U(A,D,G)、V(D,E)から元のリ
レ―ションRと同じビュ―を提供するために、次のよう
なSQL文を実行する。 create view R(A,B,C,D,E,F,G)as selectT.A,T.B,T.C,U.D,V.E,T.
F,U.G fromT,U,V where T.A=U.A&U.D=V.D; これにより、リレ―ションの分割をユ―ザ透過にでき
る。以上、リレ―ション正規化処理の手順について説明
した。次に、図20に示すリレ―ションを例として用
い、さらに具体的に正規化の手順を説明する。
ョンの集合から分割される前のリレ―ションと同じビュ
―を作成するために、ビュ―作成プロセス174を呼び
出す。ビュ―作成プロセス174は、分割情報を参照し
て、元のリレ―ションと同じビュ―を作成する。例え
ば、上記のように分割したリレ―ションT(A,B,
C,F)、U(A,D,G)、V(D,E)から元のリ
レ―ションRと同じビュ―を提供するために、次のよう
なSQL文を実行する。 create view R(A,B,C,D,E,F,G)as selectT.A,T.B,T.C,U.D,V.E,T.
F,U.G fromT,U,V where T.A=U.A&U.D=V.D; これにより、リレ―ションの分割をユ―ザ透過にでき
る。以上、リレ―ション正規化処理の手順について説明
した。次に、図20に示すリレ―ションを例として用
い、さらに具体的に正規化の手順を説明する。
【0057】まず、リレ―ション正規化プロセス171
は、システム・カタログに対してリレ―ション[人事給
与]の属性に関する情報を問い合わせる。その結果、属
性[従業員番号、支給月]の組が主キ―であることが分
かる。そして、{氏名、所属、所在地、給料}の部分集
合と、({氏名、所属、所在地、給料}の部分集合と
{従業員番号、給料}の真部分集合の直積)との和集合
は、システム・カタログに対してリレ―ション[人事給
与]の属性に関する情報を問い合わせる。その結果、属
性[従業員番号、支給月]の組が主キ―であることが分
かる。そして、{氏名、所属、所在地、給料}の部分集
合と、({氏名、所属、所在地、給料}の部分集合と
{従業員番号、給料}の真部分集合の直積)との和集合
【0058】の各要素である属性の組合せについて、そ
の属性値を調べる。その結果、属性値がすべてのタプル
で異なるような属性の組合せは存在しないことがわか
る。したがって、リレ―ション[人事給与]では、主キ
―が唯一の候補キ―であり、{氏名、所属、所在地、給
料}が非キ―属性集合である。
の属性値を調べる。その結果、属性値がすべてのタプル
で異なるような属性の組合せは存在しないことがわか
る。したがって、リレ―ション[人事給与]では、主キ
―が唯一の候補キ―であり、{氏名、所属、所在地、給
料}が非キ―属性集合である。
【0059】次に、リレ―ション正規化プロセス171
は、候補キ―{従業員番号、支給月}の真部分集合であ
る{従業員番号}、{支給月}と非キ―属性である{氏
名}、{所属}、{所在地}、{給料}の組合せを作
る。その結果を図10に示す。図10に示す属性組合せ
情報の先頭にある組合せ従業員番号→氏名に対して、関
数従属性判定プロセス172を用いて関数従属性を判定
する。関数従属性プロセス判定プロセス172は、まず
次のようなSQL文をデ―タベ―ス管理システムに問い
合わせる。 select従業員番号,count(distinct氏名) from人事給与 group by従業員番号 baving count(distinct氏名)>1;
は、候補キ―{従業員番号、支給月}の真部分集合であ
る{従業員番号}、{支給月}と非キ―属性である{氏
名}、{所属}、{所在地}、{給料}の組合せを作
る。その結果を図10に示す。図10に示す属性組合せ
情報の先頭にある組合せ従業員番号→氏名に対して、関
数従属性判定プロセス172を用いて関数従属性を判定
する。関数従属性プロセス判定プロセス172は、まず
次のようなSQL文をデ―タベ―ス管理システムに問い
合わせる。 select従業員番号,count(distinct氏名) from人事給与 group by従業員番号 baving count(distinct氏名)>1;
【0060】この質問は、1つのタプルを選択せずに終
了する。ゆえに、属性[氏名]は、[従業員番号]に関
数従属である。そこで、従属性情報に従業員番号→氏名
を保存し、属性組合せ情報から従業員番号→氏名を削除
する。次に、属性組合せ情報の先頭にある組合せ従業員
番号→所属に対して関数従属性を判定する。このような
判定を、属性組合せ情報のすべての組合せに対して行な
う。その結果、図11に示す従属性情報が得られる。
了する。ゆえに、属性[氏名]は、[従業員番号]に関
数従属である。そこで、従属性情報に従業員番号→氏名
を保存し、属性組合せ情報から従業員番号→氏名を削除
する。次に、属性組合せ情報の先頭にある組合せ従業員
番号→所属に対して関数従属性を判定する。このような
判定を、属性組合せ情報のすべての組合せに対して行な
う。その結果、図11に示す従属性情報が得られる。
【0061】図11に示す従属性情報において、矢印の
右が同じ属性である組合せは存在しない。矢印の左側が
同じ属性[従業員番号]である組合せは存在するので、
それら組合せを、左側の和集合{従業員番号}と右側の
和集合{氏名、所属、所在地}からなる組合せ従業員番
号→氏名・所属・所在地で置き換える(図12)。図1
2に示す関数従属性を用いてリレ―ションを分割する。
そこで、リレ―ション分割プロセス173は次のような
SQL文を実行する。 create table人事(従業員番号NUMBER,氏名CH
ARACTER,所属CHARACTER,所在地CH
ARACTER); insert into 人事(従業員番号、氏名、所属、所在地) select従業員番号、氏名、所属、所在地 from人事給与; create table給与(従業員番号NUMBER,支給月D
ATE,給料NUMBER); insert into 給与(従業員番号、支給月、給料) select従業員番号、支給月、給料 from人事給与; drop table人事給与;
右が同じ属性である組合せは存在しない。矢印の左側が
同じ属性[従業員番号]である組合せは存在するので、
それら組合せを、左側の和集合{従業員番号}と右側の
和集合{氏名、所属、所在地}からなる組合せ従業員番
号→氏名・所属・所在地で置き換える(図12)。図1
2に示す関数従属性を用いてリレ―ションを分割する。
そこで、リレ―ション分割プロセス173は次のような
SQL文を実行する。 create table人事(従業員番号NUMBER,氏名CH
ARACTER,所属CHARACTER,所在地CH
ARACTER); insert into 人事(従業員番号、氏名、所属、所在地) select従業員番号、氏名、所属、所在地 from人事給与; create table給与(従業員番号NUMBER,支給月D
ATE,給料NUMBER); insert into 給与(従業員番号、支給月、給料) select従業員番号、支給月、給料 from人事給与; drop table人事給与;
【0062】このSQL文を実行した結果を図21に、
分割情報を図13に、分割後の各リレ―ションのキ―属
性情報を図14に示す。そして、図12の従属性情報か
らこの関数従属性を取り除く。従属性情報はもはや存在
しないので、次に進む。
分割情報を図13に、分割後の各リレ―ションのキ―属
性情報を図14に示す。そして、図12の従属性情報か
らこの関数従属性を取り除く。従属性情報はもはや存在
しないので、次に進む。
【0063】リレ―ション[給与]には非キ―属性が1
つしかないので、以下ではリレ―ション[人事]につい
てのみ考える。リレ―ション[人事]の非キ―属性集合
は{氏名、所属、所在地}であるので、それらから図1
5に示す属性組合せ情報を作る。そして、図15の属性
組合せ情報の先頭にある組合せ氏名→所属に対して、関
数従属性判定手段は次のSQLを実行する。 select氏名,count(distinct所属) from人事 group by氏名 baving count(distinct所属)>1;
つしかないので、以下ではリレ―ション[人事]につい
てのみ考える。リレ―ション[人事]の非キ―属性集合
は{氏名、所属、所在地}であるので、それらから図1
5に示す属性組合せ情報を作る。そして、図15の属性
組合せ情報の先頭にある組合せ氏名→所属に対して、関
数従属性判定手段は次のSQLを実行する。 select氏名,count(distinct所属) from人事 group by氏名 baving count(distinct所属)>1;
【0064】その結果を図16に示す。この場合タプル
が検索されるので、所属は氏名に関数従属でない。そこ
で、氏名→所属を属性組合せ情報から削除し、次に、先
頭である組合せ氏名→所在地に対して、関数従属性を判
定する。この場合も関数従属でないので、その組合せを
属性組合せ情報から削除する。次に、先頭である組合せ
所属→所在地に対して関数従属性を判定する。この場合
には関数従属であるので、その組合せを従属性情報とし
て保存する。そして属性組合せ情報から、所属→所在地
と矢印の右側が所在地で左側が所属の超集合{氏名、所
属}である組合せ氏名・所属、→所在地を削除する。さ
らに、所在地→所属と氏名・所在地→所属も削除する。
これらの組合せを削除した後の属性組合せ情報を図17
に示す。このような処理を図17に示す属性組合せ情報
の組に対して実行する。
が検索されるので、所属は氏名に関数従属でない。そこ
で、氏名→所属を属性組合せ情報から削除し、次に、先
頭である組合せ氏名→所在地に対して、関数従属性を判
定する。この場合も関数従属でないので、その組合せを
属性組合せ情報から削除する。次に、先頭である組合せ
所属→所在地に対して関数従属性を判定する。この場合
には関数従属であるので、その組合せを従属性情報とし
て保存する。そして属性組合せ情報から、所属→所在地
と矢印の右側が所在地で左側が所属の超集合{氏名、所
属}である組合せ氏名・所属、→所在地を削除する。さ
らに、所在地→所属と氏名・所在地→所属も削除する。
これらの組合せを削除した後の属性組合せ情報を図17
に示す。このような処理を図17に示す属性組合せ情報
の組に対して実行する。
【0065】上記の処理の結果、従属性情報は図18に
示す関数従属性のみとなる。これを用いてリレ―ション
[人事]を分割する。そこで、リレ―ション分割プロセ
ス173は次のSQL文を実行する。 create table従業員(従業員番号NUMBER),氏名
CHARACTER,所属CHARACTER); insert into 従業員(従業員番号、氏名、所属) select従業員番号、氏名、所属 from人事; create table組織(課CHARACTER,所在地CH
ARACTER); insert into 組織(課、所在地) select所属、所在地 from人事; drop table人事;
示す関数従属性のみとなる。これを用いてリレ―ション
[人事]を分割する。そこで、リレ―ション分割プロセ
ス173は次のSQL文を実行する。 create table従業員(従業員番号NUMBER),氏名
CHARACTER,所属CHARACTER); insert into 従業員(従業員番号、氏名、所属) select従業員番号、氏名、所属 from人事; create table組織(課CHARACTER,所在地CH
ARACTER); insert into 組織(課、所在地) select所属、所在地 from人事; drop table人事;
【0066】この結果を図22に示す。分割情報を保存
し、従属性情報からこの関数従属性を削除する。従属性
情報に関数従属性がなくなるので、リレ―ションの分割
は終了する。
し、従属性情報からこの関数従属性を削除する。従属性
情報に関数従属性がなくなるので、リレ―ションの分割
は終了する。
【0067】最後に、リレ―ション[従業員]、[組
織]、[給与]から、元のリレ―ション[人事給与]と
同じビュ―を作成する。ビュ―作成プロセス174は、
分割情報を用いて、次のSQL文を実行する。 create view 人事給与(従業員番号、氏名、所属、所在
地、給料、支給月)as select従業員.従業員番号、従業員.氏名、従業員.所
属、組織.所在地、給与.給料、給与.支給月 from従業員、組織、給料 where 従業員.従業員番号=給与.従業員番号& 従業員.所属=組織.課; これにより、リレ―ションの分割はユ―ザに透過にな
る。
織]、[給与]から、元のリレ―ション[人事給与]と
同じビュ―を作成する。ビュ―作成プロセス174は、
分割情報を用いて、次のSQL文を実行する。 create view 人事給与(従業員番号、氏名、所属、所在
地、給料、支給月)as select従業員.従業員番号、従業員.氏名、従業員.所
属、組織.所在地、給与.給料、給与.支給月 from従業員、組織、給料 where 従業員.従業員番号=給与.従業員番号& 従業員.所属=組織.課; これにより、リレ―ションの分割はユ―ザに透過にな
る。
【0068】以上のように、この実施例においては、属
性集合Aに対して属性集合Bが関数的に従属することを
命題X、属性集合Aの値が等しいタプルが複数存在する
場合ならば、それのタプルの属性集合Bの値は等しいこ
とを命題Yとした場合において、リレ―ションのタプル
数が多い場合には、命題Yが成り立つならば、命題Xが
成り立つ可能性が高いという性質を利用しており、関数
従属性を判定する手段として、判定すべき属性集合の値
を用いている。
性集合Aに対して属性集合Bが関数的に従属することを
命題X、属性集合Aの値が等しいタプルが複数存在する
場合ならば、それのタプルの属性集合Bの値は等しいこ
とを命題Yとした場合において、リレ―ションのタプル
数が多い場合には、命題Yが成り立つならば、命題Xが
成り立つ可能性が高いという性質を利用しており、関数
従属性を判定する手段として、判定すべき属性集合の値
を用いている。
【0069】これにより、関数従属性を判定できるよう
になり、関数従属性を指標としてテーブルの分割を行な
うことができる。したがって、第1正規形であるリレ―
ションから、第3正規形のリレ―ションを作り上げるこ
とができる。以上説明した実施例に対して、例えば次の
ような追加、変更が可能である。 ・リレ―ションのタプル数がある値より大きくなった時
に自動的にリレ―ションの正規化を実行する手段を追加
する、あるいはそのように変更する。 ・リレ―ションが非正規形である場合にはリレ―ション
を第1正規形に変換する手段を追加する。 ・デ―タベ―ス管理者が、関数従属性の判定結果、リレ
―ションの分割結果などを確認し、必要ならばその結果
を変更できる手段を追加する。 ・第3正規形より高いレベルの正規化(ボイス・コッド
の正規形)を行なう手段を追加する。
になり、関数従属性を指標としてテーブルの分割を行な
うことができる。したがって、第1正規形であるリレ―
ションから、第3正規形のリレ―ションを作り上げるこ
とができる。以上説明した実施例に対して、例えば次の
ような追加、変更が可能である。 ・リレ―ションのタプル数がある値より大きくなった時
に自動的にリレ―ションの正規化を実行する手段を追加
する、あるいはそのように変更する。 ・リレ―ションが非正規形である場合にはリレ―ション
を第1正規形に変換する手段を追加する。 ・デ―タベ―ス管理者が、関数従属性の判定結果、リレ
―ションの分割結果などを確認し、必要ならばその結果
を変更できる手段を追加する。 ・第3正規形より高いレベルの正規化(ボイス・コッド
の正規形)を行なう手段を追加する。
【0070】・リレ―ションにおける更新時異常を検出
する手段を追加する。そして、デ―タベ―ス管理者から
の要求だけでなく、更新時異常検出手段からの要求を受
けてリレ―ションを正規化するように変更する。 ・ヌル値が存在する属性を除外して、上記の実施例を適
用できるように変更する。なお、本発明は、上記の実施
例に限定されるものではなく、その要旨を逸脱しない範
囲で変更可能である。
する手段を追加する。そして、デ―タベ―ス管理者から
の要求だけでなく、更新時異常検出手段からの要求を受
けてリレ―ションを正規化するように変更する。 ・ヌル値が存在する属性を除外して、上記の実施例を適
用できるように変更する。なお、本発明は、上記の実施
例に限定されるものではなく、その要旨を逸脱しない範
囲で変更可能である。
【0071】
【発明の効果】従来、デ―タベ―スの設計時に第3正規
形でないリレ―ションを定義し、そのリレ―ションをそ
のまま用いるような状況が多かった。そのためリレ―シ
ョンを記憶するための領域が大きくなり、またある更新
操作において更新されるタプル数が多くなるという問題
点があった。本発明により、デ―タベ―ス管理者が第3
正規形でないことを認識していないリレ―ションに対し
ても、リレ―ションの属性間の関数従属性を見つけ出
し、リレ―ションの分割による正規化を行なうことがで
きる。これにより、情報を損失することなくリレ―ショ
ンを記憶するための領域を小さくでき、また更新操作に
おける更新タプル数を少なくできる。
形でないリレ―ションを定義し、そのリレ―ションをそ
のまま用いるような状況が多かった。そのためリレ―シ
ョンを記憶するための領域が大きくなり、またある更新
操作において更新されるタプル数が多くなるという問題
点があった。本発明により、デ―タベ―ス管理者が第3
正規形でないことを認識していないリレ―ションに対し
ても、リレ―ションの属性間の関数従属性を見つけ出
し、リレ―ションの分割による正規化を行なうことがで
きる。これにより、情報を損失することなくリレ―ショ
ンを記憶するための領域を小さくでき、また更新操作に
おける更新タプル数を少なくできる。
【図1】本発明の一実施例に係わるデータベースシステ
ムの構成を示すブロック図。
ムの構成を示すブロック図。
【図2】同実施例に設けられたデータベース再構成シス
テムによる正規化処理動作を説明するフローチャート。
テムによる正規化処理動作を説明するフローチャート。
【図3】同実施例における候補キ―を探すための属性の
組合せの一例を示す図。
組合せの一例を示す図。
【図4】同実施例における属性組合せ情報の一例を示す
図。
図。
【図5】同実施例における従属性情報の一例を示す図。
【図6】同実施例における置換後の従属性情報一例を示
す図。
す図。
【図7】同実施例における属性組合せ情報の一例を示す
図。
図。
【図8】同実施例における従属性情報の一例を示す図。
【図9】同実施例における置換後の従属性情報の一例を
示す図。
示す図。
【図10】同実施例における属性組合せ情報の一例を示
す図。
す図。
【図11】同実施例における従属性情報の一例を示す
図。
図。
【図12】同実施例における置換後の従属性情報の一例
を示す図。
を示す図。
【図13】同実施例における分割情報の一例を示す図。
【図14】同実施例におけるキ―属性情報の一例を示す
図。
図。
【図15】同実施例における属性組合せ情報の一例を示
す図。
す図。
【図16】同実施例におけるSQL文の実行結果の一例
を示す図。
を示す図。
【図17】同実施例における関数従属性判定途中での属
性組合せ情報の一例を示す図。
性組合せ情報の一例を示す図。
【図18】同実施例における従属性情報の一例を示す
図。
図。
【図19】通常の非正規形リレ―ションの一例を示す
図。
図。
【図20】通常の第1正規形リレ―ションの一例を示す
図。
図。
【図21】通常の第2正規形リレ―ションと第3正規形
リレ―ションの一例を示す図。
リレ―ションの一例を示す図。
【図22】通常の第3正規形リレ―ションの一例を示す
図。
図。
11…ホストコンピュータ、12…端末、13…CP
U、14…メインメモリ、15…ディスク、16…デー
タベース管理システム、17…データベース再構成シス
テム、171…リレーション正規化プロセス、172…
関数従属性判定プロセス、173…リレーション分割プ
ロセス、174…ビュー作成プロセス。
U、14…メインメモリ、15…ディスク、16…デー
タベース管理システム、17…データベース再構成シス
テム、171…リレーション正規化プロセス、172…
関数従属性判定プロセス、173…リレーション分割プ
ロセス、174…ビュー作成プロセス。
Claims (2)
- 【請求項1】 各タプルを属性ごとに2次元のリレ―シ
ョンとして管理し、各リレ―ションがタプルを唯一つに
識別できる属性の組である候補キ―を持つようなリレ―
ショナルデ―タベ―スの再構成システムであって、 リレ―ションに既に存在しているタプルの値を参照する
ことにより、ある属性集合が別の属性集合に関数従属で
あるかどうかを判定する手段と、 指定した属性集合に対する射影演算を行なうことによ
り、1つのリレ―ションを2つのリレ―ションに分割す
る手段と、 リレ―ションに含まれる互いに素な属性集合AとBに対
して、属性集合Aが前記候補キ―の真部分集合であり、
属性集合Bが前記候補キ―の補集合である非キ―属性集
合の部分集合であること、あるいは、属性集合AとBが
ともに非キ―属性集合の真部分集合であることを判定す
る手段と、 この手段によって性質を満たすと判定された属性集合A
とBに対して、属性集合Bが属性集合Aに関数従属であ
るかどうかを判定し、関数従属であれば属性集合Bの補
集合による射影と、属性集合AとBの和集合による射影
とにリレ―ションを分割することを特徴とするデ―タベ
―スの再構成システム。 - 【請求項2】 各タプルを属性ごとに2次元のリレ―シ
ョンとして管理し、各リレ―ションがタプルを唯一つに
識別できる属性の組である候補キ―を持つようなリレ―
ショナルデ―タベ―スの再構成方法であって、 再構成対象のリレーションから候補キ―とそれ以外の非
キ―属性との属性集合を抽出し、 前記抽出された候補キ―の新部分集合と前記非キ―属性
の部分集合との組み合わせを作成し、 タプルの値を参照することにより、作成された属性の組
み合わせそれぞれについて非キ―属性が候補キ―に関数
属性であるか否かを調べ、 前記リレーションを、関数従属性を満たす属性集合への
射影と、関数従属性を満たす非キ―属性以外の属性集合
への射影とに分割するステップとを具備するデ―タベ―
ス再構成方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP4261334A JPH06110749A (ja) | 1992-09-30 | 1992-09-30 | デ―タベ―スの再構成システム |
US08/128,198 US5481703A (en) | 1992-09-30 | 1993-09-29 | Database restructuring system for detecting functionally dependent relations and converting them into third normal form |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP4261334A JPH06110749A (ja) | 1992-09-30 | 1992-09-30 | デ―タベ―スの再構成システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH06110749A true JPH06110749A (ja) | 1994-04-22 |
Family
ID=17360379
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP4261334A Pending JPH06110749A (ja) | 1992-09-30 | 1992-09-30 | デ―タベ―スの再構成システム |
Country Status (2)
Country | Link |
---|---|
US (1) | US5481703A (ja) |
JP (1) | JPH06110749A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0895766A (ja) * | 1994-09-21 | 1996-04-12 | Nec Corp | 正規化データベース更新プログラム製造装置 |
JP2007249531A (ja) * | 2006-03-15 | 2007-09-27 | Hitachi Software Eng Co Ltd | テーブル構造決定及び通知システム |
US8972363B2 (en) | 2012-05-14 | 2015-03-03 | Nec Corporation | Rule discovery system, method, apparatus and program |
JPWO2014141608A1 (ja) * | 2013-03-12 | 2017-02-16 | 株式会社Adeka | 透明製品用塩化ビニル系樹脂組成物 |
US9767411B2 (en) | 2012-05-14 | 2017-09-19 | Nec Corporation | Rule discovery system, method, apparatus, and program |
Families Citing this family (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5634049A (en) * | 1995-03-16 | 1997-05-27 | Pitkin; John R. | Method and apparatus for constructing a new database from overlapping databases |
US5740421A (en) * | 1995-04-03 | 1998-04-14 | Dtl Data Technologies Ltd. | Associative search method for heterogeneous databases with an integration mechanism configured to combine schema-free data models such as a hyperbase |
US5819264A (en) * | 1995-04-03 | 1998-10-06 | Dtl Data Technologies Ltd. | Associative search method with navigation for heterogeneous databases including an integration mechanism configured to combine schema-free data models such as a hyperbase |
US5797137A (en) * | 1996-03-26 | 1998-08-18 | Golshani; Forouzan | Method for converting a database schema in relational form to a schema in object-oriented form |
US5778375A (en) * | 1996-06-27 | 1998-07-07 | Microsoft Corporation | Database normalizing system |
FR2764719B1 (fr) * | 1997-06-12 | 2001-07-27 | Guillaume Martin | Dispositif d'analyse et d'organisation de donnees |
US6292829B1 (en) * | 1998-07-15 | 2001-09-18 | Nortel Networks Limited | Method and device for network management |
US6393605B1 (en) * | 1998-11-18 | 2002-05-21 | Siebel Systems, Inc. | Apparatus and system for efficient delivery and deployment of an application |
US6466931B1 (en) * | 1999-07-30 | 2002-10-15 | International Business Machines Corporation | Method and system for transparently caching and reusing query execution plans efficiently |
US6567816B1 (en) * | 2000-03-07 | 2003-05-20 | Paramesh Sampatrai Desai | Method, system, and program for extracting data from database records using dynamic code |
US7110936B2 (en) * | 2001-02-23 | 2006-09-19 | Complementsoft Llc | System and method for generating and maintaining software code |
KR20030008111A (ko) * | 2001-07-16 | 2003-01-24 | 한국전자통신연구원 | 메모리상주 분산데이터베이스의 데이터 검사방법 및 시스템 |
US7873628B2 (en) * | 2006-03-23 | 2011-01-18 | Oracle International Corporation | Discovering functional dependencies by sampling relations |
US9471639B2 (en) * | 2013-09-19 | 2016-10-18 | International Business Machines Corporation | Managing a grouping window on an operator graph |
FR3024914A1 (ja) * | 2014-08-18 | 2016-02-19 | Sebastian Link |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5010478A (en) * | 1986-04-11 | 1991-04-23 | Deran Roger L | Entity-attribute value database system with inverse attribute for selectively relating two different entities |
US5247665A (en) * | 1988-09-30 | 1993-09-21 | Kabushiki Kaisha Toshiba | Data base processing apparatus using relational operation processing |
US5369761A (en) * | 1990-03-30 | 1994-11-29 | Conley; John D. | Automatic and transparent denormalization support, wherein denormalization is achieved through appending of fields to base relations of a normalized database |
US5295261A (en) * | 1990-07-27 | 1994-03-15 | Pacific Bell Corporation | Hybrid database structure linking navigational fields having a hierarchial database structure to informational fields having a relational database structure |
US5261093A (en) * | 1990-11-05 | 1993-11-09 | David Saroff Research Center, Inc. | Interactive relational database analysis with successive refinement steps in selection of ouput data from underlying database |
US5295256A (en) * | 1990-12-14 | 1994-03-15 | Racal-Datacom, Inc. | Automatic storage of persistent objects in a relational schema |
US5367675A (en) * | 1991-12-13 | 1994-11-22 | International Business Machines Corporation | Computer automated system and method for optimizing the processing of a query in a relational database system by merging subqueries with the query |
-
1992
- 1992-09-30 JP JP4261334A patent/JPH06110749A/ja active Pending
-
1993
- 1993-09-29 US US08/128,198 patent/US5481703A/en not_active Expired - Fee Related
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0895766A (ja) * | 1994-09-21 | 1996-04-12 | Nec Corp | 正規化データベース更新プログラム製造装置 |
JP2007249531A (ja) * | 2006-03-15 | 2007-09-27 | Hitachi Software Eng Co Ltd | テーブル構造決定及び通知システム |
JP4749899B2 (ja) * | 2006-03-15 | 2011-08-17 | 株式会社日立ソリューションズ | テーブル構造決定及び通知システム |
US8972363B2 (en) | 2012-05-14 | 2015-03-03 | Nec Corporation | Rule discovery system, method, apparatus and program |
US9767411B2 (en) | 2012-05-14 | 2017-09-19 | Nec Corporation | Rule discovery system, method, apparatus, and program |
JPWO2014141608A1 (ja) * | 2013-03-12 | 2017-02-16 | 株式会社Adeka | 透明製品用塩化ビニル系樹脂組成物 |
Also Published As
Publication number | Publication date |
---|---|
US5481703A (en) | 1996-01-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JPH06110749A (ja) | デ―タベ―スの再構成システム | |
US6374252B1 (en) | Modeling of object-oriented database structures, translation to relational database structures, and dynamic searches thereon | |
US8108367B2 (en) | Constraints with hidden rows in a database | |
Phipps et al. | Automating data warehouse conceptual schema design and evaluation. | |
US7650644B2 (en) | Object-based access control | |
US7188116B2 (en) | Method and apparatus for deleting data in a database | |
US5758144A (en) | Database execution cost and system performance estimator | |
US5485610A (en) | Physical database design system | |
EP2863311B1 (en) | Domain centric test data generation | |
US6694310B1 (en) | Data flow plan optimizer | |
JPH0667951A (ja) | データベース管理システム | |
US7366741B2 (en) | Method and apparatus for redefining a group of related objects in a relational database system | |
JP2003500741A (ja) | 単一の集計プロセスで複数のデータマートを実装するための方法および装置 | |
US11841836B2 (en) | Target environment data seeding | |
US5884311A (en) | Method and system for dynamically configuring a relational database | |
JP5033322B2 (ja) | 連結関係情報を用いた情報管理方法及び装置 | |
US11971909B2 (en) | Data processing system with manipulation of logical dataset groups | |
US20040015508A1 (en) | Object-level conflict detection in an object-relational database system | |
US7225194B2 (en) | Composite record identifier generator | |
KR100490810B1 (ko) | 참조 무결성에 관련된 테이블 공간을 점검하는 방법 | |
US20240256576A1 (en) | Data processing system with manipulation of logical dataset groups | |
JP2017010376A (ja) | マートレス検証支援システムおよびマートレス検証支援方法 | |
JPH01147621A (ja) | プログラム自動生成方法 | |
Gorman et al. | Constraints, Keys, and Relationships | |
JP2004303117A (ja) | 名寄せデータベース設計支援方法およびシステム |