2003年 6月16日 | 「キー の定義表」 の記入例 | >> 目次 (作成日順) |
以下の データ 構造を前提にする。 顧客 { 顧客番号、顧客名称 } [ R ] 商品 { 商品番号、商品名称、商品単価 } [ R ] 受注 { 受注番号、顧客番号 (R)、商品番号 (R)、受注日、受注数 } [ E ] 以下の情報 (画面) を前提にする。 |
受注照会画面 | |||
顧客番号: | 顧客名称: | ||
受注番号: | 受注日: | ||
商品番号: | 商品名称: | 受注数: | 商品単価: |
以下の 「キー の定義表」 を作成する。
|
顧客テーブル | N+M | |||||||||
顧客番号 | ||||||||||
顧客名称 |
受注テーブル | N+M | |||||||||
受注番号 | ||||||||||
顧客番号 (R) | ||||||||||
品目番号 (R) | ||||||||||
受注日 | ||||||||||
受注数 |
商品テーブル | N+M | |||||||||
商品番号 | ||||||||||
商品名称 | ||||||||||
商品単価 |
「キー の定義表」 は以下の手順に従って記入する。 (1) それぞれの テーブル に対して、データ の 「一意性の検証」 をするのかしないのか、を判断する。
もし、「一意性の検証」 をするのであれば、「N+M」 の カラム のなかに 「ユニーク・キー」 を定義する。 上述の例で言えば、「受注」 テーブル に関して、受注番号が顧客単位に連続番号を附番されているとすれば、受注番号だけを使って 「一意性の検証」 をすることができないので、「ユニーク・キー」 は 「顧客番号+受注番号」 の複合 キー となる、という前提とする。 「一意性の検証」 を記述したら、次に以下の記入をする。 (2) 画面のなかに記述されている データ の順序どおりに 「一般 キー」 を定義する。
「一般 キー」 とは、「キー の定義表」 のなかで 「N+M」 以外の カラム を使って定義される キー をいう。
- 「顧客」 テーブル では、「顧客番号→顧客名称」 の並びである。 したがって、「キー の定義表」 は以下のように記入される。 |
受注照会画面 | |||
顧客番号: | 顧客名称: | ||
受注番号: | 受注日: | ||
商品番号: | 商品名称: | 受注数: | 商品単価: |
以下の 「キー の定義表」 を作成する。
|
顧客 テーブル | N+M | key-1 | ||||||||
顧客番号 | ○ | 1 | ||||||||
顧客名称 | 2 |
受注テーブル | N+M | key-1 | ||||||||
受注番号 | 2 | 2 | ||||||||
顧客番号 (R) | 1 | 1 | ||||||||
品目番号 (R) | 3 | |||||||||
受注日 | 4 | |||||||||
受注数 | 5 |
商品テーブル | N+M | key-1 | ||||||||
商品番号 | ○ | 1 | ||||||||
商品名称 | 2 | |||||||||
商品単価 | 3 |
|
<< もどる | HOME | すすむ >> | |
ベーシックス |