TOPICS10・リレーショナルの設定入門5

トップページ　★MSアクセスウエッブカレッジ｜サンプル(ダウンロードする）|業務統合4in1｜小さな会社用『感嘆！』　

■★■ＭＳアクセスマクロ・TOPICS■★■

10.・・・リレーションシップ設定その５「参照整合性」

リレーションシップの説明長くなっていますが、リレーションシップはシステムの要だと思うんです。小さいシステムでは、余り大きな問題になりませんが、本格的な（何が本格的かって？まあ、とにかく本格的な）システムでは、リレーションシップが、大切になってきます。

どうしてかよく分からない方は、失礼ながら、そのレベルということかも知れません。又は、データベースの特徴を使い切っていないのかもしれません。奥の深いのが、このリレーションシップだと思います。それでかどうかわかりませんが、読者の方から、「よくぞリレーションシップの話をして下さった。ありがとう」とのメールも多数よせられました。

　
●「参照整合性」
　今回はリレーションシップの最もリレーションシップらしいところ、「参照整合性」のお話です。

リレーションシップの設定されたテーブル間において、リレーションシップが設定されたフイルドから、そのレコードは特例される、つまり「参照整合性」があることになります。
事例の、生徒マスタテーブルにある「担当教師番号」と、教師マスタテーブルの教師番号は、「１対多の設定」（教師マスタテーブルが１で生徒マスタテーブルの担当教師番号は多）になっている。

　教師マスタテーブルには、
　　１　長島重雄
　　２　山本工事と入力されているとして、
　生徒マスタテーブルが
　　１　浅井顕示　　で担当教師番号　は１
　　２　井上　亮　　で担当教師番号　は１

の場合、「参照整合性」がとれていることになります。「参照整合性」がとれない場合はどこを変えれば、エラーメッセージ「参照整合性」が取れてませんがでるでしょう。リレーションシップのポイントはデータを重複してもたないことでしたよね、

上記のように生徒マスタテーブルの担当教師は、番号で持っています。もし番号でもっていない場合、名前、長島重雄で持たなくては生りません、１番の生徒も２番の生徒も、長島重雄で持たなくてはなりません。これを番号でもてば，すごくメモリーの節約になりますよね。メモリー使用が少ないということは、それだけコンピュータ処理も早いことになります。

でも、いい時代になりましたね、、メモリーもＣＰＵ処理スピードも上がり、
余り気にしなくても、なんとかつかえるようになりました。不完全なリレーショ
ンシップでも、案外使えていることが、結果オーライなわけです。

●「参照整合性」はレコードが対象

ここで、注意が必要なのが、「参照整合性」はレコードに対してのチェックだということ。
ある２つのテーブル間で、複数のリレーションシップが設定されている場合、その複数のリレーションシップが達成されてはじめて「参照整合性」が取れていることになります。「クラブマスタテーブル」があったとして、生徒マスタテーブルにクラブ番号を（多）として、「クラブマスタテーブルのクラブ番号を（１）としてリレーションシップを設定した場合で、クラブが１から３番まで登録したとしてみる。

ここで生徒マスタテーブルに対して、２つのテーブルとリレーションシップが結ばれたことになります。このとき「参照整合性」は、３つのテーブル間で完全かどうかのチェックが行われます。

「参照整合性」でのポイントは２つ。

１つは、「参照整合性」のリレーションシップが作れない場合があります。これは、「1対多」「1対１」のフイルドの設定が違っているかをチェックしましょう。

1側は重複なしです。多側は重複ありです。
フイルドの型式も一致していなければなりません。数値型でも、整数型は整数型同士でない、リレーションシップは作れません。全く同じにすることで解決」します。

もう一つは、テーブルにデータがある場合、テーブルにデータがある状態で、リレーションシップを作ろうとすると、なかなか、うまく作れません。それは、すでにあるデータが作ろうとする「参照整合性」にすでに合っていないデータがあるからです。私も、よくこの状態になることがあります。データがある状態で、リレーションシップがうまくできない場合。データを削除又は、どこかに移してから設定します。

データがある場合で、「参照整合性」が組めない場合、よくあることは、追加したマスタテーブルにデータがないことがあります。マスタテーブルを追加作成して、リレーションシップを追加する場合です。すでにデータがるため、これからつくろうとする「参照整合性」に合うように、又は臨時的に合うようにしてから、リレーションシップを組みます。

●「フイールドの連鎖更新」と「レコードの連鎖削除」

もう一つの設定があります。それが上記の連鎖処理です。１側のレコードを削除すると、多がわのレコードが削除され、多側のレコードを削除すると、１側のレコードも削除されます。結合の種類によって、変化するので、注意が必要となりますが、多く使うのが、１側のレコードを削除したとき、多側のレコードも削除するケケースです。

ただ、事例のような、マスタテーブルの場合、連鎖削除は余り行いません。多くは、データレコードに適用します。例えば販売データと販売明細データのような場合、販売データの削除をすると、リレーションシップされた販売明細データも削除される。

「連鎖削除」を設定していない場合は、販売明細データも削除（クエリー）しなければなりません。

これがよく分からない場合、設定項目チェックをはずしておけばよい。

★サンプルのダウンロード
　ftp://mscn.net/pub/rl.mdb

★今までのの関連記事