データベース技術第5回（2015.10.27）

1

データベース設計の手順•データとその関連（ER）を分析する

•表を作る

•表を正規化する-第一正規形

-第二正規形

-第三正規形

2

データとその関連（ER）の分析•ERモデル

-現実世界をEntity（実体）とRelationship（関連）　　という概念を使って考える

-現状の世界からにEntity（実体）をとらえる• 例：商品（商品コード、商品名、単価）• 例：輸出先（輸出先コード、輸出先名）

-実体同士のRelationship（関連）について考える• 例：売上

3

ERモデル•Entity（実体）とRelationship（関連）

商品

商品コード

商品名

単価

輸出先輸出先コード

輸出先名

売上 個数

M

N

・多数の商品が多数の輸出先　に売られる・多数の輸出先は多数の商品　を買っている

多対多の関係

※商品がひとつの場合、　1対多の関係となります※商品ひとつ輸出先ひとつの場合、　1対1の関係となります

4

非正規形•繰り返し項目が排除されていない表

•リレーショナルデータベースでは、非正規形の表はうまく処理できない報告書コード 日付 輸出先コード 輸出先名 商品コード 商品名 単価 個数

1101 3/5 12 アメリカ 101 メロン ￥800 1,1001101 3/5 12 アメリカ

102 いちご ￥150 3001102 3/7 23 中国 103 りんご ￥120 1,7001103 3/8 25 フランス 104 レモン ￥200 500

1行分のデータの中に2つの商品のデータが存在する

正規化する：1行に1つの値が入る表にすること5

正規化•現実世界のデータをリレーショナルデータベースの表に落とし込む作業

•1行に1つの値が入る表の形にする

•非正規形の表をデータの矛盾が発生しないよう複数の表に分割する

6

第一正規形•表を2次元の単純な表としたもの

•1行に１つの値が入るようにした表

報告書コード 日付 輸出先コード 輸出先名

1101 3/5 12 アメリカ1102 3/7 23 中国1103 3/8 25 フランス

報告書コード 商品コード 商品名 単価 個数1101 101 メロン ￥800 1,1001101 102 いちご ￥150 3001102 103 りんご ￥120 1,7001103 104 レモン ￥200 500

「売上」表 「売上明細」表（第一正規形①） （第一正規形②）

7

第二正規形（1）•主キーによってほかの列の値が決まるように　した表

•関数従属している-「ある列の値によってほかの列の値が決まる」こと

•第二正規形では、主キーにほかの列が関数従属するように表を分割する

8

第二正規形（2）•主キーによって他の列の値がきまる

-「商品」表は、「商品コード」列の値が決まると　「商品名」と「単価」の値が決まる

-「売上明細」表は、「報告書コード」列と「商品コード」列の値が決まると「個数」の値が決まる

商品コード 商品名 単価101 メロン ￥800102 いちご ￥150103 りんご ￥120104 レモン ￥200

報告書コード 商品コード 個数1101 101 1,1001101 102 3001102 103 1,7001103 104 500

「商品」表 「売上明細」表（第二正規形①） （第二正規形②）

9

第三正規形•各項目の値が、主キーのみで決まる表

•推移従属している-「ある列の値にによって間接的にほかの列の値が　　決まる」こと

•第三正規形では、推移従属を除くように表を　分割する

報告書コード 日付 輸出先コード

1101 3/5 12輸出先コード 輸出先名

12 アメリカ

「売上」表（第三正規形①） 「輸出先」表（第三正規形②）

10

第三正規形にした表•リレーショナルデータベースではこの表を使う

報告書コード 日付 輸出先コード

1101 3/5 121102 3/7 231103 3/8 25

輸出先コード 輸出先名

12 アメリカ23 中国25 フランス

「売上」表 「輸出先」表

商品コード 商品名 単価101 メロン ￥800102 いちご ￥150103 りんご ￥120104 レモン ￥200

報告書コード 商品コード 個数1101 101 1,1001101 102 3001102 103 1,7001103 104 500

「商品」表「売上明細」表

参照

参照

参照

11

データベースの設計について•データベース設計はシステム設計の一部

業務の分析

要件定義

基本設計

論理設計

詳細設計

今の業務はどうなっているのか

何をしたいのか

どんなシステムにすべきか

どのように実現するか

方法を明確にする

データベース設計はこの段階に含まれるデータベースの設計＝データベースの構造を設計する

12

スキーマ•データベースの構造をスキーマと呼ぶ

•スキーマは3つの構造に分類される-概念スキーマ

• 論理的な構造を定義する• ER図の作成、テーブルの設計、論理設計、概念設計

-外部スキーマ• ユーザから見たデータベースを定義する• ビューの設計

-内部スキーマ• コンピュータ内部から見たデータベースを定義する• 物理的な部分を定義する• 容量、メモリ設計、物理設計、物理配置設計、インデックス設計

13

概念スキーマ•データの論理的な構造を設計する段階

-現実世界をいかにコンピュータに置き換えるか考える-情報の流れを分析し、データベース化する部分を決定

•表を作って正規化する

•ER図を書く

•各テーブルのデータの型や長さを決定する

14

表を作って正規化する•例：果物の輸出に関するデータ

報告書コード 日付 輸出先コード

1101 3/5 121102 3/7 231103 3/8 25

輸出先コード 輸出先名

12 アメリカ23 中国25 フランス

「売上」表 「輸出先」表

商品コード 商品名 単価101 メロン ￥800102 いちご ￥150103 りんご ￥120104 レモン ￥200

報告書コード 商品コード 個数1101 101 1,1001101 102 3001102 103 1,7001103 104 500

「商品」表「売上明細」表

15

ER図を書く

商品コード商品名単価

輸出先コード輸出先名

報告書コード日付輸出先コード

「商品」表

「輸出先」表「売上」表

1

＊

1＊

報告書コード商品コード個数

「売上明細」表

1＊

16

データの型や長さを決める（1）•データ型（MySQLの場合の一部）

型 説明INT 整数型（別名：INTEGER）

DOUBLE 浮動小数点数型DATE 日付型（フォーマット：'YYYY-MM-DD'）

DATETIME 日付時刻型（フォーマット：'YYYY-MM-DD HH:MM:SS'）TIME 時刻型（フォーマット：'HH:MM:SS'）

CHAR文字列型（指定文字数以下の文字を格納した場合は末尾に空白を付け加える）

VARCHAR文字列型（指定文字数以下の文字を格納しても空白を加えない）

17

データの型や長さを決める（2）•制約の種類

制約 説明

PRIMARY KEY主キー。一意に行を指定可能であることを保証する。複数列指定でもOK。NULLデータは扱えない。

FOREIGN KEY外部キー。外部のテーブルの主キーを指定する。表と表の関係を明示するために使う。

UNIQUE値の重複禁止を保証する。ただし、NULL値は複数OK。

CHECK挿入される値をチェックし、該当しないものははじく。（例：CHECK(社員ID > 0) =>マイナス値は不可）

NOT NULL NULL値でないことを保証する。18

データの型や長さを決める（3）

「輸出先」表

「売上」表フィールド名 データ型 長さ 制約報告書コード INT 10 PRIMARY KEY, NOT NULL, AUTO_INCREMENT日付 DATE NOT NULL

輸出先コード INT 3 FOREIGN KEY

フィールド名 データ型 長さ 制約輸出先コード INT 3 PRIMARY KEY, NOT NULL輸出先名 VARCHAR 40 NOT NULL

※ AUTO_IMCREMENT：自動的に連番が格納される※ PRIMARY KEYを指定すると、自動的にNOT NULL, UNIQUEと判断される。　ここでは NOT NULLを明示している。

19

データの型や長さを決める（3）

「商品」表フィールド名 データ型 長さ 制約商品コード INT 4 PRIMARY KEY, NOT NULL商品名 VARCHAR 40 NOT NULL単価 INT 10

「売上明細」表フィールド名 データ型 長さ 制約報告書コード INT 10 PRIMARY KEY, NOT NULL商品コード INT 4 PRIMARY KEY, NOT NULL個数 INT 5 NOT NULL

※「売上明細」表は報告書コードと商品コードを主キーとしている（複合キー）。　これは扱い難い場合があるので、明細IDなどを主キーとして設けることもある。

20

スキーマ•データベースの構造をスキーマと呼ぶ

•スキーマは3つの構造に分類される-概念スキーマ

• 論理的な構造を定義する• ER図の作成、テーブルの設計、論理設計、概念設計

-外部スキーマ• ユーザから見たデータベースを定義する• ビューの設計

-内部スキーマ• コンピュータ内部から見たデータベースを定義する• 物理的な部分を定義する• 容量、メモリ設計、物理設計、物理配置設計、インデックス設計

21

外部スキーマ•ユーザから見やすいデータベースを設計する

-概念スキーマで設計された表は効率の良い形だが、　ユーザにはわかり難い

-外部スキーマではユーザが扱いやすい「見える」表（ビュー View）を定義する

日付 輸出先コード 商品コード 個数3/5 12 101 1,1003/6 25 102 300

日付 輸出先名 商品名 個数3/5 アメリカ メロン 1,1003/6 フランス いちご 300

わかり難い

わかりやすい22

内部スキーマ•コンピュータ内部の物理的な設計を行う

-ディスクのどこに作成するか？

-データベースのファイル名は？

-データサイズはどのくらいか？

-バックアップメディアは何を使うか？

•ハード的な仕様の決定は重要-データベースの処理速度に大きな影響を持つ場合がある

23

データベースの設計について•データベース設計はシステム設計の一部

業務の分析

要件定義

基本設計

論理設計

詳細設計

今の業務はどうなっているのか

何をしたいのか

どんなシステムにすべきか

どのように実現するか

方法を明確にする

データベース設計はこの段階に含まれるデータベースの設計・概念スキーマ ←今ここ・外部スキーマ・内部スキーマ

24

Work：概念スキーマを作成する•各自でテーマを決定する

•データベースの概念スキーマを定義しましょう-表を作って正規化する

- ER図を書く

-各テーブルのデータの型や長さを決定する

25