Transcript Document

背景
コンピュータアプリケーションが対象とする
データの多様化，複雑化，大規模化
↓
 アプリケーションが取り扱うべきデータをま
とめて管理して，効率的な共有とより高度な
利用を図りたい．
↓
データベースシステムの利用

2015/7/20
データベース論
1
データベースシステム
さまざまな分野で用いられている．
データベースシステムは，各種アプリケーション
システムにとって必要不可欠な要素である．
2015/7/20
データベース論
2
データベースシステムを用いるシステム

人事管理システム，在庫・販売管理システ
ム，生産管理システム．


コンビニなどのPOSシステム(Point Of Sales System)
では，商品の名前や値段などの情報を表すバーコード
をバーコードリーダーで読み込み，データベースで管理
する．
支店の売り上げ，売れ筋の商品，商品の在庫などの
データを容易に得る．

2015/7/20
最近はこれらのシステムを統合したERP (Enterprise
Resource Planning)パッケージが主流
データベース論
3
データベースシステムを用いるシステム

文書管理
企業が持つ大量の情報は，画像やワープロの
文書の形でコンピュータに格納されている．こ
れらをスムーズに共有するためにデータベース
システムを利用する．
 アクセス制限．
 文書の複数人による同時利用．

2015/7/20
データベース論
4
データベースシステムを用いるシステム

銀行のオンラインシステム
銀行のCD機で預金の引き出し，預け入れをし
た場合に残高データを正確に管理する．
 銀行のシステムは，銀行間のネットワークで繋
がっているので相互に利用が可能．

2015/7/20
データベース論
5
データベースシステムを用いるシステム

切符の予約システム
どの電車のどの席が空いているか，料金はいく
らか，出発時刻と到着時刻といったデータを瞬
時に得る．
 指定席のダブルブッキングを防ぐ．

2015/7/20
データベース論
6
データベースシステムを用いるシステム

Webページ管理、ブログ・SNSのシステム

誰でも簡単にWebページを作成・公開できる


Webページに書き込むと，そのまま公開出来る．


HTML等の知識は必要としない。
登録，検索，削除，更新
掲載内容（コンテンツ）をシステムで管理
ファイルで管理すると煩雑
 データベースを利用


2015/7/20
利用者からは見えない
データベース論
7
データベースシステムを用いるシステム

科学データ管理システム


化合物情報，遺伝子情報．
その他

2015/7/20
コンピュータネットワークの管理データシステム
など．
データベース論
8
データベース(database, DB)とは？
対象とする現実世界をコンピュータ上に表
現したもの。
 「複数の応用目的での共有を意図して組織
的かつ永続的に格納されたデータ群」


組織的：データが体系的に整理されている


永続的：電源を切っても消えない．

2015/7/20
様々なアプリケーションやユーザからアクセス可能．
ハードディスクなどの2次記憶装置に記録．
データベース論
9
データベース管理システム

Database Management System (DBMS)
データベースを管理するソフトウェアシステム．
 データベースシステムの概念



2015/7/20
図1.1を参照．
“データベース”という用語は，狭義にはデータ
ベースシステム中に蓄積されたデータ群を指す．
しかし，データベースシステム全体やデータ
ベース管理システムのことを指すことも多い．
データベース論
10
なぜデータベースを利用するか？

情報をコンピュータで保存する方法はほか
にも存在する．
最も一般的な例として，基本ソフト（OS）の“ファ
イルシステム”があげられる．
 ファイルシステムを利用するとさまざまな問題
が生じる．

2015/7/20
データベース論
11
ファイルシステムの問題点

データとアプリケーションの相互依存
データ格納やアクセス方法をアプリケーション
ごとに用意する必要がある．
 データの共有が難しい

データの形式がアプリケーションごとに異なる．
 統一性がない


冗長性の原因となる

2015/7/20
同じようなデータが複数のファイルに存在すると
データの更新などに問題が生じる．
データベース論
12
ファイルシステムの問題点

整合性維持機能の欠如

データの整合性を維持しにくい．
-> アプリケーションがすべて責任を持たなくて
はならい．
年齢が300歳の社員．
 不正な社員番号を持つ社員．

2015/7/20
データベース論
13
ファイルシステムの問題点

機密保護が不十分

データを複数のユーザで共有する
どのユーザが，どのデータに対して，どんな操作を
行えるかを管理できない．
 きめ細かな機密が保護できない．

2015/7/20
データベース論
14
ファイルシステムの問題点

複数ユーザの同時アクセス

データが複数のユーザから共有されている
何の統制もなく更新を行うとデータに矛盾が生じる．
 データの更新のタイミングが問題．

2015/7/20
データベース論
15
ファイルシステムの問題点
同時アクセスの障害例
前提）X = 10, Y = 20とする．
Aさんは，X = 100かつY = 200に変更したい．
Ｂさんは，X = 1000かつY = 2000に変更したい．
1）AさんがXを100に変更．
2)ＢさんがＸを1000に変更．
3）ＢさんがYを2000に変更．
4)AさんがYを200に変更．
X=100, Y=20
X=1000, Y=20
X=1000, Y=2000
X=1000, Y=200
A,B両方が予想していない結果になってしまう．矛
盾が起こらないように，アプリケーションをプログラ
ムする必要があるが，非常に手間がかかる．
2015/7/20
データベース論
16
ファイルシステムの問題点

不十分なデータ保護

コンピュータは壊れる（ソフトの停止，ディスクの
クラッシュなど）．
-> データの復旧，整合性のチェックが必要．
-> ファイルシステムでは障害が起こったときに対処
できない．
2015/7/20
データベース論
17
データベースシステムにおけるデータ管理

データベースシステムでは
データを体系的に組織化 -> データベース化
 各種のアプリケーションに提供


2015/7/20
データを独立化
データベース論
18
データベースシステムにおけるデータ管理

データを個々のアプリケーションから分離す
るメリット
1) データを独立した資源として管理
→ 多目的利用が容易
2) 関連するデータを統合 → 矛盾や無駄をなくす
3) データの意味やその相互関連を把握すること
を容易にする
4) データの表現方法やその管理方法を標準化し
やすくなる
2015/7/20
データベース論
19
DBMSが提供する機能
各種アプリケーションからの有効利用を行う
ための機能を提供．
 基盤となるデータ記述・操作系
データモデル(data model)


対象データとそれに対する操作を定めた共通
の枠組み
データの物理的な格納形態やデータ検索手順の詳
細に関与せずに論理的なレベルでのデータ記述と
操作が可能．
 実際のシステムの内部を詳細に知る必要がない。

2015/7/20
データベース論
20
DBMSが提供する機能

代表的なデータモデル
リレーショナルデータモデル（relational data
model：関係データモデル)
 図1．2参照
 表の形で対象を表現
 表 -> リレーション（関係)
 各アプリケーション固有のデータベース


2015/7/20
必要な部分のみを抜き出したデータベース。
データベース論
21
DBMSが提供する機能

効率のよいデータアクセス機構

大量に蓄積されたデータから必要なデータを高
速に取り出す機構

データを2次記憶（ハードディスクなど）に蓄える際に、



問い合わせ最適化 (query optimization)

2015/7/20
木構造、ハッシングなどを用いた格納方式（第6章)
キーを用いた検索（第2章)
ユーザの複雑な問い合わせをDBMSが解釈し、もっ
とも早く処理できる方法で検索する。
データベース論
22
DBMSが提供する機能

整合性の維持
一貫性制約
 データベースにデータが満たすべき条件を明
記


機密保護

2015/7/20
検索、挿入、削除、修正などをデータ毎にかつ
ユーザ毎に設定可能。
データベース論
23
DBMSが提供する機能

同時実行制御(concurrency control)

トランザクション(transaction)
アプリケーションから見たデータベースの処理単位
 送金処理のトランザクション




複数のトランザクションが並行処理されるので、
それぞれのトランザクション間で矛盾が起こら
ないようにする。 -> トランザクション管理

2015/7/20
送金前のそれぞれの口座の残高のチェック。
両方の口座の残高を送金後の値に書き換える。
ロックを用いた排他制御
データベース論
24
DBMSが提供する機能

障害回復
障害からの復旧
 トランザクションの中の処理のいずれかが失敗
した場合は、トランザクション全体をキャンセル。

2015/7/20
データベース論
25
データベースシステムに関係した基本概念
スキーマとインスタンス
大量のデータの管理 -> 同じデータをグループ化、
共通の構造や相互関連に注目することが有効。

スキーマ(schema)
データベース中のデータの構造、形式、関連、
整合性制約を記述したものをスキーマと呼ぶ。
 図1.2


インスタンス(instance)

2015/7/20
スキーマに基づいて格納されたデータ群
データベース論
26
データベースシステムに関係した基本概念
スキーマとインスタンス

データベースが採用しているデータモデルに応
じてスキーマの形式が決定される．
スキーマはインスタンスのデータ構造やそれが満た
すべき条件を記述しているともいえる。
 データのデータ -> メタデータ


データベースは現実世界をコンピュータ上に表
したもの
現実世界が変わればスキーマも変化しなければな
らない
 スキーマ変化が必要

2015/7/20
データベース論
27
データベースシステムに関係した基本概念
抽象化の3レベル

データベースシステムはデータを抽象化し論理的
レベルでデータ記述と操作を行うための枠組みを
提供する。
 社員に関する情報を表で表現し、検索できる。
-> 3つの抽象化レベルがある。

内部レベル(internal level)
計算機内部でデータをどう表現するか。
 内部スキーマ(internal schema)

2015/7/20
データベース論
28
データベースシステムに関係した基本概念
抽象化の3レベル

概念レベル(conceptual level)
データベース全体を論理的にとらえるレベル。
 概念スキーマ(conceptual schema)


外部レベル(external level)
各アプリケーションごとのデータベースに対す
る視点を表現
 外部スキーマ(external schema)、サブスキー
マ(sub schema)

2015/7/20
データベース論
29
データベースシステムに関係した基本概念
抽象化の3レベル

これら3つの抽象化のレベルをANSI/SPARCモデ
ルと呼ぶ．


2015/7/20
American National Standard of Institute / Standard
Planning And Requirement Committee
図1.3
データベース論
30
データベースシステムに関係した基本概念
概念スキーマと外部スキーマを分離する利点

基準となる概念スキーマに対して各アプリ
ケーションが自分に適した方法でデータ
ベースを操作できる．
外部スキーマはプログラミング言語の文法に
従って記述して，概念スキーマはどの言語から
も独立した方法で記述．
 データ独立を図る．


2015/7/20
アプリケーションプログラムの視点を外部スキーマ
で制限する．
データベース論
31
データベースシステムに関係した基本概念
概念スキーマと内部スキーマを分離する利点
概念スキーマの設計時にデータベースの実
現方法を考慮しなくても良い。
 内部スキーマの変更を行うことで，アプリ
ケーションプログラムを変更を行うことなくシ
ステム全体の性能を向上させることが可能
となる．

2015/7/20
データベース論
32
データベースシステムに関係した基本概念
データ独立性

データベースシステムではデータはアプリ
ケーションから分離して組織化される（図
1.1）。 -> データ独立性(data
independence)
2015/7/20
データベース論
33
データベースシステムに関係した基本概念
データ独立性

論理的データ独立性 (logical data independence)
外部レベルと概念レベル間の独立性
 外部スキーマ -> アプリケーションからのデータ
見方を記述。
 概念スキーマを変更したとしても外部スキーマ
が変更されない範囲であれば、アプリケーショ
ンと独立に行える。


物理的データ独立性 (physical …)

2015/7/20
図1.4
データベース論
34
データベースシステムに関係した基本概念
データベース言語(database language)

データ記述、データ操作の言語

データ定義言語(data definition language, DDL)
データ記述を行う言語
 スキーマの記述


データ操作言語(data manipulation language,
DML)
 インスタンス（データ）の操作

データ制御言語(data control language)

2015/7/20
機密保護、トランザクションの制御
データベース論
35
データベースシステムに関係した基本概念
データベース言語(database language)

リレーショナルデータベースにおける標準
言語
SQL （エス キュー エル）
 上記すべての機能を持っている。

2015/7/20
データベース論
36
データベースシステムに関係した基本概念
データベース言語の利用形態

対話的にユーザが直接使用


SQLを覚える必要がある．
CやFORTRANなどの汎用言語と組み合わせて
利用。




2015/7/20
複雑な操作を知らないユーザでも使えるシステムを提
供
データベース言語を一般の汎用言語のプログラムの中
に埋め込む
データベース言語 -> データサブ言語(data sublanguage)
汎用プログラム言語 -> ホスト言語
データベース論
37
データベースシステムの構成と利用
図1.5
 データベース管理者(database administrator)

スキーマの定義や変更
 物理的記憶領域管理及び各種チューニング
 ユーザの登録やアクセス権の設定
 各種整合性制約の設定
 データベースのバックアップや障害への対処

2015/7/20
データベース論
38
データベースシステムの構成と利用

データベースユーザの種類
アプリケーションプログラマ ->データベースアプ
リケーションを開発
 ナイーブユーザ(naive user) ->データベースア
プリケーションを利用して定型的な作業のみ
 カジュアルユーザ(casual user)
-> 必要に応じて非定型的な問い合わせを行う


システムカタログ

2015/7/20
スキーマに関する情報
データベース論
39
データモデリング

データモデル

データベース中のデータとそれに対する操作を
規定する枠組み
データ構造を記述する上での規約
 データに対する操作体系



整合性制約

2015/7/20
検索、更新、削除など
満たさなくてはならない条件
データベース論
40
データモデルの役割

DBMSのインターフェース


DBMSの内部構造や検索手順とDBの論理レ
ベルのデータ記述を分離
現実世界のモデル化のツール

モデル化

2015/7/20
対象の現実世界の情報の構造や意味をできるだけ
自然に表現するための枠組みを与えること。
データベース論
41
データモデルの役割

データベース構築のための設計
現実世界の複雑な情報構造や要求の調査・分析
 データベース化すべき情報を取捨選択し、構造化
 データベースとは上記の操作を経て作成された現
実世界のモデル、ミニチュアである。
 上記の一連の操作をデータモデリングと呼ぶ。

実世界
データ ベース
データ モデリ ン グ
（ 写像）
2015/7/20
データベース論
42
代表的なデータモデル
リレーショナルデータモデル（関係データモデル）

1970年Coddにより提案。単純、数学的基盤
が明確である。

図1.2参照
データベースはリレーション（関係）の集まり。
表がリレーションを表す。
 レコード型


2015/7/20
ひとまとまりのデータ項目のこと
データベース論
43
代表的なデータモデル
リレーショナルデータモデル（関係データモデル）

フィールドまたは属性(attribute)


レコード型を構成する要素
レコードオカレンス (record occurrence)

レコード型に格納されているデータの集まり
「サークル」レコード型は，サークル名、部室番
号、部室内線番号という属性を持つ．
 <“テニス”、101、1011>はレコードオカレンスで
ある。

2015/7/20
データベース論
44
代表的なデータモデル
リレーショナルデータモデル（関係データモデル）


リレーションスキーマ

リレーションＲ（テーブルR）が属性A1, …, Anを
持つときR(A1, … , An)と記述する。

サークル(サークル名、部室番号、部室内線番号)
タプル（組、tuple）

2015/7/20
リレーション（表）の各行のこと
データベース論
45
代表的なデータモデル
リレーショナルデータモデル（関係データモデル）

データ操作を規定した体系

リレーショナル（関係）代数


リレーショナル（関係）論理

2015/7/20
リレーションに対する基本操作を定義
一階述語論理
データベース論
46
代表的なデータモデル
ネットワークデータモデル (network data model)
ファイルシステムを高度化する方向で考え
られた初期のデータモデル
 CODASYL＆NDL

CODASYLのDBTGが1971年に提案したもの
が原型
 データベース言語NDL
-> 国際標準規格
 図2.1参照

レコードとレコード型
 バックマン線図(Bachman diagram)

2015/7/20
データベース論
47
代表的なデータモデル
階層データモデル (hierarchical data model)

レコード型を節点とする木構造を基本とす
る．
IBMのIMS、MRIのSYSTEM2000
 図2.2参照


セグメントとセグメント型
2015/7/20
データベース論
48
代表的なデータモデル
階層データモデル (hierarchical data model)

わかりやすい反面、複雑な構造を記述しに
くい。
1対Nの表現は容易だが、N対Mの表現は難し
い。
 論理関連、論理親、論理子
 図2.3

2015/7/20
データベース論
49
代表的なデータモデル
オブジェクト指向モデル (object-oriented model)
C++, Smalltalk-80などに代表されるオブジェク
ト指向プログラミング言語で導入されたオブジェ
クト，クラスの概念を用いて実世界の事象をそ
のままモデル化。
 オブジェクト指向プログラミング言語を用いるこ
とにより簡単にコンピュータ上に実現されると
いった特徴がある。
 幾種類ものデータベースが開発されてきたが、
それらのシステムの違いは採用しているデータ
モデルの違いである。

2015/7/20
データベース論
50
実世界のデータモデリング
データベース化には、データモデルによりデー
タ記述を行う必要あり。
 これまで述べてきたデータモデルには制約事
項が多い。


物理レベルと論理レベルの区別をしているものの、
コンピュータによる実装や実行効率による制限があ
る。
概念モデル記述言語
実世界
2015/7/20
データ ベース
管理者
概念
モデリ ン グ
データ モデル
概念
モデル
データ
モデリ ン グ
データベース論
論理
モデル
データ ベース
51
実世界のデータモデリング
現実世界の複雑な情報の分析から、DBMSが
サポートするデータモデルで直接のデータ記述
を求めることが非常に困難。
 さらに、DBMSのデータモデルの制約にとらわ
れない自然な表現機構を持つことは、データ
ベースの構造や意味を理解する意味でも有用。
-> 図2.4参照
 概念設計と概念モデル＆論理設計と論理モデ
ル

2015/7/20
データベース論
52
実体関連モデル（ERモデル）
実体関連モデル(Entity relationship
model)は概念設計に利用されるモデル。
 実体(entity)

存在を認識できる対象を包括的に述べたもの。
 大学の科目履修のデータベース

個々の学生、科目、実習課題などはすべて実体
 同一種類の実体の集まりを実体集合(entity set)


2015/7/20
「学生」、「科目」、「実習課題」などは実体集合ととらえ
ることができる。
データベース論
53
実体関連モデル（ERモデル）
属性 -> 実体の持つ各種の性質を表すもの
 実体集合ごとに属性の集合が決まる。

「科目」について科目番号、科目名、単位数
 属性Aのとりうる値全体を属性Aのドメイン（定義域）
という。


2015/7/20
科目番号のドメインは、001,002,003, …,00Nである。
データベース論
54

関連(relationship)
2つ以上の実体同士の相互関係を表したもの
 関連集合（テキストp.24参照）
 実体集合「学生」と「科目」の間の関連集合「履
修」
 関連集合にも属性を付加できる。例えば、履修
した科目の成績など。

2015/7/20
データベース論
55

実体関連図(entity relationship diagram)
実体関連モデルでモデル化した現実世界を視
覚的に表現する図式
 図2.5参照
 実体集合を矩形、関連集合を菱形、属性を楕
円で表記
 関連集合と実体集合の結びつきや実体集合や
関連集合とその属性の結びつきを線で表す。

2015/7/20
データベース論
56

2015/7/20
役割・ロール(role)

図2.6参照、p.25

関連集合に対して同一の実体集合が別の意味で複
数回関与する事がある。
データベース論
57

ERモデルにおける整合性制約
整合性制約を記述する仕組み。1,N,Mなどの
数字と記号
 参加制約 (participation constraint)

関連に関与しない実体を許すか許さないか。
 「学生」という実体集合と「履修」という関連集合


2015/7/20
「履修」に関与しない（1つも科目を履修しない）学生を許す
か許さないか。
データベース論
58
許さない場合（全員が科目を履修） -> 「学生」の
「履修」への参加は全面的(total)という。
 許す場合（全員が科目を履修しなし） -> 「学生」の
「履修」への参加は部分的(partial)という。
 (mix,max)による表記。図2.7、p.26

2015/7/20
データベース論
59

キー制約 (key constraint)
実体集合「学生」の各実体（学生）は異なる学籍番
号を持つ。
-> 学籍番号により一意に識別可能
 キー(key)：それを指定することにより、実体集合か
ら一つの実体を識別できる属性、または、その組み
合わせのうち極小なもの。




2015/7/20
実体集合によっては複数のキーを持つ。
学生の場合は、住所と氏名の組み合わせもキーの候補
-> 候補キー
候補キーのうちデータ管理上最適と思われるものを主
キー (primary key)と呼ぶ。
データベース論
60
図2.5、2.7では下線の付いた属性が主キー
 それ自身の持つ属性またはその組み合わせで主
キーを構成できる実体集合 -> 強実体集合(strong
entity set)

2015/7/20
データベース論
61
それ自身の持つ属性またはその組み合わせで主
キーを構成できない実体集合 -> 弱実体集合
(weak entity set)。
 2重の矩形。 p.26
 「実習課題」がその例。課題番号は科目毎に一意で
しかない。
 「実習課題」の実体は「科目」の実体との結びつきを
通してのみ識別できる。 -> 「科目」は「実習課題」
の識別上のオーナ(identifying owner)と呼ぶ。
 「課題番号」は「科目」が決まったときのみキーとして
利用できる
-> 部分キー(partial key)

2015/7/20
データベース論
62

汎化階層

実体集合間の階層的関係

「学生」と「TA」



ある学生は「TA」であると同時に「学生」の要素である。
学籍番号、氏名、専攻などは「学生」としての属性
経験年数、内線番号はTAとしての属性
図2.8
 継承(inherit)
 汎化と専化（特化）

2015/7/20
データベース論
63

概念モデル構築の意義

2015/7/20
コンピューターに実装することは考えないで実
世界をモデル化することができるので，実世界
の事物のデータ構造を素直に表現できる。
実世界のモデリングをデータベースのインプリ
メンテーションから切離して考えることが可能に
なる．
データベース論
64

DBMSのインプリメンテーションに関係のない
概念モデルまでさかのぼって新たなデータモデ
ルに変換することでモデル変換のコストを下げ
る。
データベースの構造やその環境は時代と共に変化
する．
 ネットワーク型のDBMSをリレーショナル型DBMSに
入れ変える。
 ネットワークデータモデルからリレーショナルデータ
モデルに変換直接すると作業が大変。

2015/7/20
データベース論
65
ネッ ト ワ ーク 型データ モデル
階層型データ モデル
納品数量
Ｍ
納品
商品
実世界
商品番号
商品名
価格
Ｎ
顧客
顧客番号
顧客名
E-R モデルによ る
概念モデル
2015/7/20
データベース論
関係型データ モデル
66
リレーショナルデータモデル

データモデル
データ構造
 整合性制約
 データ操作系
 Codd(1970)
 現在もっとも多くのDBMSが採用
 データベース操作言語 -> SQL


リレーション（関係、relation）

2015/7/20
n項関係の概念に基づく。
データベース論
67
リレーショナルデータモデル

n項関係
集合S1,…,Snがある時、{(X1,…, Xn) | X1∈S1
∧ … ∧ Xn∈Sn}を
S1×S2×… ×Snで表す。 -> 直積集合
 直積集合S1×… ×Snの部分集合をn項関係
と呼ぶ。
 S1={a, b}, S2={c, d}の時、S1×S2={(a,c),
(a,d), (b,c), (b,d)}であり、
{(a,c), (b,c)}はS1,S2上の２項関係である。

2015/7/20
データベース論
68

リレーションスキーマ
リレーションがもつ構造。->リレーション（表）の
構造の情報
 R(A1, … , An)

Rはリレーション名
 A1, … ,An：属性名または属性

一つのリレーションスキーマ中では属性名は一
意（一つに決まる）でなければならない。
 属性の個数 -> リレーションスキーマの次数
(degree)

2015/7/20
データベース論
69


ドメイン(定義域:domain) -> 属性がとりうる値の集合
リレーション

D1×D2×…×Dnの有限部分集合r⊆
D1×D2×…×Dn




2015/7/20
リレーションはリレーションスキーマのとりうる値の一部分
リレーションスキーマR(A1, … , An)のインスタンス
rの各要素 -> タプル
単項リレーション、２項リレーション、n項リレーション
データベース論
70

図3.1
表における各行の順番は意味がない。
 リレーションは集合である。 -> すべて同じ属
性値を持つタプル（行）は複数存在できない。
 属性の並ぶ順番も意味がない。

2015/7/20
データベース論
71

第１正規形：First Normal From(1NF)

図3.3

属性値は分解不可能な単純値のみ





属性値として集合やリレーションをもてない。
非正規リレーション
入れ子型リレーション（属性としてリレーションが存在する）
リレーショナルモデルでは第１正規形を対象とする。
-> 単純でわかりやすいデータ構造
NULL


2015/7/20
空値
取りうる値がわからない時などに用いる。
データベース論
72

リレーショナルデータベーススキーマ

リレーショナルスキーマの集合と整合性制約の
集合


リレーショナルデータベースインスタンス


表の構造に関する情報の集合と表同士の制約の集
合
整合性制約（条件）を満たすリレーションスキー
マのインスタンスの集合
図3.3
2015/7/20
データベース論
73
リレーショナルデータモデルの整合性制約

整合性制約



データの整合性を表現
実世界の正しい表現となるために満たさなければなら
ない条件
ドメイン制約


R(A1, …, An)中のタプルの成分はそれぞれA1,
… ,Anのドメインの要素でなければならない。
ドメイン：各属性が取りうる値の集合

データ型などを含む -> 不十分なことも多い

2015/7/20
成績のデータは整数値であるが、０から１００までという条件がさ
らに考えられる。
データベース論
74
リレーショナルデータモデルの整合性制約

キー制約

超キー(super key)
2つ以上のタプルが同一の値を持たない属性や属
性の集合
 リレーション学生(学籍番号、氏名、専攻、住所)では、
学籍番号、氏名と住所のペア、学籍番号と氏名の
ペア -> 全て超キー

2015/7/20
データベース論
75

候補キー(candidate key)
極小な超キー
 いかなる真部分集合も超キーとならないキー


主キー(primary key)
候補キーのうち、データ管理上もっとも都合のよいもの。
 空値（ＮＵＬＬ）になり得ないもの。


キー制約
候補キーの属性値が同じタプルが存在してはならない。
 主キーについてはNULLの値をもてない。


2015/7/20
実体整合性制約
データベース論
76

参照整合性制約

2015/7/20
外部キー

図3.3

「履修」における科目番号は必ず「科目」になければ
ならない。
データベース論
77

従属性

関数従属性

2015/7/20
-> 省く
R(…, X, Y, …)中の任意の２タプルに関して、Xが
等しいときYが必ず等しい。 -> 関数従属性X->Y
が成立する。
データベース論
78
リレーショナル代数

リレーショナルモデルにおけるデータ操作
の規定
リレーショナル代数 ◎
 リレーショナル論理


2015/7/20
タプルリレーショナル論理とドメインリレーショナル論
理
データベース論
79
リレーショナル代数
8つの基本的リレーショナル代数演算子
(1) 和(union) 図3.4

R∪S = {t | t∈R ∨ t∈S}
 RとSはリレーションとしての条件を満たす


ＲとＳの次数は同じ、対応する属性のドメインも同じ
でなければならない。 -> 和両立条件
(2) 差(difference) 図3.4

2015/7/20
R-S = {t | t∈R ∨ ￢t∈S}
データベース論
80
リレーショナル代数
(3) 直積（カルテシアン積: cartesian
product)

R×S = {t*u | t∈R ∧ u∈S}

2015/7/20
t*uはタプルtとuを連結したもの。
データベース論
図3.5
81
(4) 射影(projection)
リレーション R(A1,… ,An)が持つ属性（列）のう
ち、指定した属性のみを残し他を削除
 πA1’,… An’(R) = {t[A1’,… An’] | t∈R} 図3.6

(5) 選択 (selection)

2015/7/20
リレーション R(A1,… ,An)が持つタプル（行）の
うち、指定した条件を満たすタプルのみ残す。
図3.6
データベース論
82

選択条件

属性Aiと定数Cの比較演算子θによる式




Ai θAj
ドメインが同じで比較可能なもの。
上記を論理和、論理積、否定で組み合わせたもの。

2015/7/20
(＜, ≦, ＝, ≧, ＞, ≠)
ドメインが同じで比較可能なもの。
属性Aiと属性Ajの比較演算子θによる式

Ai θC
Ai <Aj ∨ Ai >C
データベース論
83

選択条件Fを用いた選択

σF(R) = {t | t∈R ∧ Pf(t)}
(6) 結合(join) 図3.7

直積R×SはRとSのタプルの全ての組み合わせ


実際にはあまり使わない。
直積R×Sの結果のリレーションのうち結合条件Fを
満たすものだけ。
R F S  {t * u | t  R  u  S  PF (t , u)}


2015/7/20
t*uはタプルtとuを連結したもの。
PF(t,u)はｔとuが条件Ｆを満足するときに真となる述語
データベース論
84

直積と選択の組み合わせで表現可能
R F S   F ( R  S )
結合条件の比較演算子が=
 それ以外
-> θ結合

2015/7/20
データベース論
-> 等結合
85

自然結合(natural join) 図3.8

等結合 -> 属性値の重複が生じる。


だいたいは属性名も同じである。
属性名が同じものは省く。
(7) 共通部分(intersection)
R∩S = {t | t∈R∧t∈S}
 RとSは和両立条件を満たす。
ＲとＳの次数は同じ、対応する属性のドメインも
同じでなければならない。
 R∩S = R - (R-S)で表現可能。

2015/7/20
データベース論
86
(8) 商(division)

R(A1,…,An), S(Am,…,An) 1<m<=nで同じ
名前の属性のドメインは等しい

R÷S = πA1,…, Am-1(R) - πA1,…, Am-1 ((πA1,…, Am1(R)×S) - R)

図3.9
2015/7/20
データベース論
87

登録されている全てのプロジェクトのメンバと
なっている人の従業員番号
プロジェクトメンバ÷プロジェクト

(R×S)÷S = Rが成立するので、商と呼ぶ。
2015/7/20
データベース論
88

δ（デルタ）
リレーションRの属性名AをBに変更
 δA←B(R)


リレーショナル代数式

2015/7/20
p45
データベース論
89
SQLの基本概念

リレーショナルデータモデルとの違い

重複したタプルの存在
リレーショナルデータモデルでは、リレーション（表）
はタプルの集合 ->全く同じ属性値の並びから成る
重複したタプルは存在が許されない。
 しかし、現実には重複したタプルが自動的に削除さ
れると都合が悪い



2015/7/20
属性値の平均を求めるとき。
重複した要素の存在を許す ー> マルチ集合(multi
set)
データベース論
90
SQLの基本概念

属性やタプルの順序づけ
リレーショナルモデル ー> 属性の順番は意味が
ない
 SQL -> 属性、属性値は明示的に順序づけられた
ものである。


タプルの順番も明示的に指定できる。
SQLではリレーションといわずに表（table）とい
う用語を使用する。
 タプルー>行(row)、 属性ー>列(column)と呼
ぶ。

2015/7/20
データベース論
91
SQLの利用形態

直接起動

sqlインタプリタを起動してユーザが直接SQLを入力。


シェル、コマンドプロンプト
埋め込みSQL


親言語に埋め込んで使用。
静的SQL


動的SQL

2015/7/20
予め決められたSQL文を実行
プログラム実行中にSQL文を生成
データベース論
92
2015/7/20
データベース論
93
リレーショナルデータベース設計論
ERモデルからのリレーショナルデータベーススキー
マの導出

概念モデルから論理モデルを導き出す方法の
ひとつ。
概念設計
論理設計
概念モデル記述言語
実世界
データ ベース
管理者
概念
モデリ ン グ
データ モデル
概念
モデル
データ
モデリ ン グ
ERモデル
によるモデリング
の結果
論理
モデル
データ ベース
リレーショナルデータ
ベーススキーマ
ERモデルからのリレーショナルデータベーススキーマの導出
実体集合の扱い(1)

A) 通常実体集合
通常実体集合Eに対してリレーションRを定義し
、Eのすべての属性をRの属性とする。
 図2.8 pg.28

学生(学籍番号、氏名、専攻、住所)
 科目(科目番号、科目名、単位数)

ERモデル図（図2.8 pg.28 ）
氏名
科目名
専攻
住所
学籍番号
学生
N
成績
履修
科目番号
M
U
TA
1
経験年数 内線番号
担当
1
科目
課題番号
単位数
1
実習
N
課題名
実習課題
ERモデルからのリレーショナルデータベーススキーマの導出
実体集合の扱い(2)

B) 弱実体集合

実体集合E’を識別上のオーナとする実体集合
Eに対してはリレーションRを作成し、Eのすべ
ての属性をRの属性とする。さらに、E’に対応
するリレーション主キーをRの属性に加え、これ
とEの部分キーの組み合わせをRの主キーとす
る。

実習課題(科目番号、課題番号、課題名)
ERモデルからのリレーショナルデータベーススキーマの導出
実体集合の扱い(3)

C) 汎化階層の扱い
実体集合Eに関する汎化階層があり、Eの上位
の実態集合E’が存在する
 E’に対応するリレーションの主キーをEに対応
するリレーションRに加えてこれをRの主キーと
する。


TA(学籍番号、経験年数、内線番号)
ERモデルからのリレーショナルデータベーススキーマの導出
関連集合の扱い(1)

A) 次数2の関連集合


[前提] 関連集合により関係づけられる二つの
実体集合に対応するリレーションをR1、R2とす
る。
➀ 1対1対応の場合

R1あるいはR2のいずれかにもう一方のリレーションの
主キーおよび関連集合の属性を付加する。

TA(学籍番号、経験年数、内線番号、科目番号)
ERモデルからのリレーショナルデータベーススキーマの導出
関連集合の扱い(2)

② 1対N対応の場合

R1およびR2がそれぞれ1側およびN側の実体
集合に対応したリレーションであるとする。

科目がR1、実習課題がR2

このとき、R2にR1の主キーおよび関連集合の
属性を付加する。

実習課題(科目番号、課題番号、課題名)

ここでは、（１）のB)ですでに主キーが挿入されてい
るので変化なし。
ERモデルからのリレーショナルデータベーススキーマの導出
関連集合の扱い(3)

③ N対M対応の場合
R1の主キー、R2の主キー、関連集合の属性
からなる新たなリレーションを定義する。
 新たなリレーションの主キーは、R1とR2の主キ
ーの組み合わせとなる。


履修(科目番号、学籍番号、成績)
ERモデルからのリレーショナルデータベーススキーマの導出
関連集合の扱い(4)
B) 次数3以上の関連集合
 次数2の③ N対M対応の場合と同様に新た
なリレーションを定義する

好ましくないリレーションスキーマ

概念モデル（ERモデル）から変換したスキ
ーマ
理解しやすいか？必要な性質を持っているか
？といったことは概念モデルのできに関わって
くる。
 場合によっては、好ましくないリレーションスキ
ーマが生成される。

好ましくないリレーションスキーマの例

pg.58の例
販売価格
商品
営業
顧客
営業マン
顧客
商品
変換
営業マン
営業
商品番号 顧客番号 社員番号 販売価格
営業の主キー：（商品番号、顧客番号）
リレーション「営業」にいくつかの問題点
リレーション「営業」の問題点(1)

(A) 修正不整合
(modification anomaly)


顧客cが購入する商品ごとに
担当のsの社員番号が繰り返
し格納される －＞ 冗長
担当が替わるときには、全て
の社員番号を変更する必要
がでてくる。
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
i1
c2
s2
120
i2
c1
s1
200
i2
c2
s2
210
i3
c1
s1
250
i3
c2
s2
250
i4
c1
s1
150
リレーション「営業」の問題点(2)

(B) 挿入不整合 (insertion
anomaly)


各顧客の営業担当の情報も
格納している。
商品は購入していないが、担
当が決まっている顧客のデー
タを入れることができない。

商品番号が主キーの一部
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
i1
c2
s2
120
i2
c1
s1
200
i2
c2
s2
210
i3
c1
s1
250
i3
c2
s2
250
c3
s1
リレーション「営業」の問題点(3)

(C) 削除不整合 (deletion
anomaly)



商品を一つだけ購入している
顧客（c4）がいたとする。
c4が購入していた商品を取り
扱い中止にしたとする。
c4の担当がs1であったという
情報まで消えてしまう。
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
i1
c2
s2
120
i2
c1
s1
200
i2
c2
s2
210
i3
c1
s1
250
i3
c2
s2
250
i4
c4
s1
150
更新不整合（update anomaly）
上記の(A), (B), (C)をまとめて更新不整合
と呼ぶ
 上記の例で更新不整合が発生する原因

顧客と担当の関係が商品の販売情報の中に
紛れ込んでいるため。
 リレーション「営業」には二つの独立した情報が
混在している。
 これを分割すればよい。

更新不整合の解決

「営業」を「販売」と「営業担当」
の二つに分ける。

販売


商品番号と顧客番号の組み合
わせが主キー
営業担当

営業
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
i1
c2
s2
120
i2
c1
s1
200
i2
c2
s2
210
i3
c1
s1
250
i3
c2
s2
250
i4
c1
s1
150
顧客番号が主キー
販売
商品番号 顧客番号 販売価格
i1
c1
100
i1
c2
120
i2
c1
200
i2
c2
210
i3
c1
250
i3
c2
250
i4
c1
150
営業担当
顧客番号 社員番号
c1
s1
c2
s2
二つに分けるとなぜ問題が解決するか？

新しい「販売」と「営業担当」は、更新不整合を解
消するためのある種の「正規形」に分類される形
式となっている。


様々な種類の正規形が存在する。詳細は後述。
二つに分けても、結合(join)を取ることで、商品、
顧客、担当を関係を一体として捉えることが
可能。

分解前のリレーションを再現できる
－＞ 無損失結合分解
無損失結合分解を用いて正規形に分解すること
で、元のスキーマと等価な情報をより管理しやす
い形に変換して管理できる。
 4.3節以降の内容




関数従属性とは？
正規形とは？
リレーションスキーマの表記について


R(A1, A2, A3, ..., An)
{A1, A2, A3, ..., An} ＜－ リレーション名を省いた表
記
関数従属性 (functional dependency (FD))

リレーションスキーマR(..., X, ..., Y, ...)が与えられた時（XとY
は単一の属性とは限らず、属性集合の場合もある） 、その任
意のインスタンス中の任意の2タプルに関して、もしそのXの値
が等しいならYの値も等しいという制約が成立する時、関数従
属性X→Yが成立するという。
R
X
a
Y
b
a
b
関数従属性

関数従属性が成立する時



XはYを関数的に決定するという
YはXに関数従属するという．
リレーション「営業」では


商品番号、顧客番号 －＞ 販売価格
顧客番号 －＞ 社員番号



「顧客番号」が決まれば「社員番号」が決まらなければならな
い。
一人の顧客は一人の社員が担当するというルールを表現。
関数従属性は一つの（一部の）タプルだけでは判
断できない。

リレーションスキーマ全体を見て判断する必要がある。
113
論理的に含意と閉包

関数従属性A→B, B→Cが成立するなら、明らかに、
A→Cが成立する。このような時、｛ A→B、 B→C ｝は
A→Cを論理的に含意(logically imply)するという。
｛ A→B、 B→C ｝|= A -> Cと表記する。


関数従属性の集合F




表に出てこない、暗黙のルールがある。
通常は、上記のような含意を含む。
これらを含めて全ての関数従属性をFの閉包(closure)と呼ぶ。
表記はF+
通常、 F+はたくさんありすぎて数え切れない。

F+を論理的に数え上げる規則があれば便利。
アームストロングの公理系

X,Y,Z⊆RSとして
① 反射律(reflexivity law)
Y⊆Xのとき、X→Yが成
立する。
② 増加律 (augmentation law)
X→Yのとき、XZ→YZ
(X∪Z→Y∪Z)が成立する。
RS
A
B
C
D
Y
X
RS
A B C D E F
X
Y
Z
アームストロングの公理系
③ 推移律 (transitivity law)
X→YかつY→Zのとき、 X→Zが成立する。
健全：関数従属性Fから公理系を利用して求められた全ての従属性はF+の要素で
ある。
完全：F+の全ての要素が公理系を用いて求められる。
RS
A B C D E F
X
Y
Z
アームストロングの公理系により、導き出される規則
① 合併律(union law)
X→YかつX→Zのとき、
X→YZが成立する。
② 擬推移律
(pseudotransitivity law)
X→YかつWY→Zのと
き、XW→Z が成立する。
RS
A B C D E F
X
Y
Z
RS
A B C D E F G H
X
Y
W
Z
アームストロングの公理系により、導き出される規則
③ 分解律 (decomposition law)
X→YかつZ⊆Yのとき、 X→Zが成立する。
RS
A B C D E H
X
Z
Y
等価 (equivalent)

関数従属性集合F、Gが与えられた時、
F+ = G+
が一致する時、FとGは等価である。


等価であることを調べるには、F+ ⊇ G+ かつF+ ⊆ G+ が
成立することをチェックすればよい。
ある従属性集合に等価な従属性集合のうち、冗
長性のない簡潔なものを求めたいという問題が発
生する。
－＞ 極小被覆 (minimal cover)
極小被覆 (minimal cover)
関数従属性Fに等価な関数従属性の集合のうち、
以下の条件を満たすMをFの極小被覆と呼ぶ。
(1) M中のすべての関数従属性の右辺は単一の属
性


X→A ∈ Mのとき、Aは単一の属性
（属性集合ではない）
(2) M中のいかなる関数従属性X→Aに対しても、
M – {X→A}とMは等価でない。

M中の要素には不要なものが一つも無い
極小被覆 (minimal cover)
(3) M中のいかなる関数従属性X→AおよびZ⊂X
に対しても、 M – {X→A}∪{Z→A}とMは等価で
ない。

MからX→Aを引いた後に、Z→Aを足しても等価で
はない。
RS
A B C D E H
X
Z
A
Y

関数従属性Fの極小被覆は複数個存在する。





{A,B,C}
F = {A->BC, B->C, C-> B}
条件(1)を満たすために 分解律
F= {A->B, A->C B->C, C->B}
条件(2)に違反しないように
= {A->C, B->C, C->B}
※A->BはA->CとC->Bで表現できる。
F= {A->B, A->C B->C, C->B} 条件(1)
= {A->B, B->C, C->B} 条件(2)
分解

RS={A1, ..., An}に対して、RSi⊆RS(1≦i≦m)なるリレ
ーションスキーマの集合ρ（ロウ）={RS1, ..., RSm}で
RS1∪...∪RSm=RSとなるものをRSの「分解」と呼び、
ρを求めることをRSを「分解する」という。
RS
A
B
A
RS1
B
C
D
RS2
C
A
D
分解
分解は更新不整合を解消したリレーション
を得る一つの手法。
 分解後のスキーマが元のリレーションスキ
ーマと同じ情報を表現することを保証できる
か？
－＞ 無損失結合分解

無損失結合分解

RSに関する関数従属性集合FとRSの分解｛RS1,
... ,RSm｝が与えられた時、Fを満足するRSの全て
のインスタンス（実際の行）Rについて、
R   RS1 (R)  RSm (R) が成立とき、分解ρはRS
の無損失結合分解である。
  RS ( R) は射影 pp.40-41
1
  は自然結合 pg.43
無損失結合分解の例
R   RS1 ( R)   RS 2 ( R) が成立する。
 ここで、RS1={氏名、所属、学年}、RS2={氏名、研究室}

R －＞
R －＞
氏名
重永
桑本
RS
所属 学年 研究室
教育
M2 情報処理
教育
4 情報工学
氏名
重永
桑本
RS1
所属
教育
教育
学年
M2
4
RS2
氏名 研究室
重永 情報処理
桑本 情報工学
無損失結合分解の性質
  RS1 ( R)   RS m ( R) がR中には無かったよ
うなタプルを含まずにちょうどRに一致す
る。

どんな分解が無損失結合分解となるか？

分解元のリレーションの関数従属性集合Fに応
じて決まる。
－＞ 定理4.1
定理4.1
ρ={RS1,RS2}をリレーションスキーマRSの分解と
し、FをRSに関する関数従属性集合とする。
 このとき、分解ρが無損失結合分解となる必要十
分条件は、
(RS1∩RS2 → RS1－RS2) ∈ F+

「RS1、RS2 の両方に含まれる属性が決まれば、RS1だけに含まれる属性が
決まる。」という関数従属性がF+に含まれる。
または
(RS1∩RS2 → RS2－RS1) ∈ F+
であることである。
定理4.1の応用例
販売
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
...
...
...
...

販売の極小被覆は、


R1
商品番号
i1
i1
…
R2
顧客番号 社員番号
c1
s1
c2
s2
顧客番号 販売価格
c1
100
c2
120
…
…
｛商品番号,顧客番号->販売価格、 顧客番号->社員番号｝
{R1(商品番号,顧客番号,販売価格)、
R2(顧客番号, 社員番号)}は販売の無損失結合分解
である。


RS1∩RS2=｛顧客番号｝、 RS2－RS1 ={社員番号}
(RS1∩RS2 → RS2－RS1) ∈ F+が成立
定理4.1の応用例
販売
商品番号 顧客番号 社員番号 販売価格
i1
c1
s1
100
...
...
...
...

販売の極小被覆は、


顧客番号
c1
…
R2
商品番号 社員番号 販売価格
i1
s1
100
…
…
…
｛商品番号,顧客番号->販売価格、 顧客番号->社員番号｝
{R1{商品番号,顧客番号}, R2{商品番号,社員番号,販売価格
}}は無損失結合分解ではない。



R1
商品番号
i1
…
RS1∩RS2=｛商品番号｝、 RS1－RS2={顧客番号}、
RS2－RS1 ={社員番号,販売価格}
よって、 (RS1∩RS2 → RS1－RS2) ∈ F+
(RS1∩RS2 → RS2－RS1) ∈ F+のいずれも成立しない。
分解にされたR1、R2からは元の「販売」を復元できない。
無損失結合分解以外の分解に関する性質

元のリレーションスキーマに関する関数従
属性集合として表現された整合性制約が、
分解により得られたスキーマ集合に関する
関数従属性集合として表現可能であるか？

整合性制約

データが満たさなければならない条件（pp.35-37）


ドメイン制約､キー制約など
この議論のために､「関数従属性の射影」という
概念を導入する。
関数従属性の射影

通常の射影 pp.40-41
スキーマRSとその関数従属性集合Fおよび属性集合
Z⊆RSが与えられた時、
πZ(F) = {X→Y ｜ XY⊆Z ∧ X→Y∈F+}
をFのX上への射影という。
 RS={A,B,C}, F={A->B, B->C, C->B}であるとき、


πAB(F)={A->B}、 πBC (F)={B->C, C->B}
πAC(F)={A->C}
※Fには含まれないがA->CはA->BとB->Cで表現されるのでF＋には含まれる
。
従属性保存分解

スキーマRSとその関数従属性集合F、RS
の分解ρ＝{RS1,...,RSm}が与えられた時、
任意の関数従属性X->Y∈Fに対して
πRS1(F)∪...∪πRSm(F) |= X→Y
が成立するなら、分解ρはFに関する従属性
保存分解であるという。

|= ．．．． 論理的に含意
従属性保存分解の例

RS={A,B,C}, F={A->B, B->C, C->B}であると
き、{RS1(A,B), RS2(B,C)}は従属性保存分解
πRS1(F) =πAB(F) = {A->B}
 πRS2(F) =πBC(F) = {B->C, C->B}
 よって、 πRS1(F)∪...∪πRSm(F) = {A->B, B->C,
C->B}
 これは、 X->Y∈Fに対して
πRS1(F)∪πRS2(F) |= X→Yである。

従属性保存分解の例

RS={A,B,C}, F={A->B, B->C, C->B}であるとき、
{RS1(A,B), RS2(A,C)}は従属性保存分解でない。





πRS1(F) =πAB(F) = {A->B}
πRS2(F) =πAC (F) = {A->C} ※A->CはF+に含まれる。
よって、 πRS1(F)∪...∪πRSm(F) = {A->B, A->C}
これは、 X->Y∈Fに対して
πRS1(F)∪πRS2(F) |= X→Yではない。
B->C、C->Bが表現できていない。
正規形

もともと、リレーショナルデータモデルにおいては､
第1正規形でなければならない。pp.33-34

各属性は分解不可能な単純値でなければならない。
第1正規形では、4.2節のような問題が生じる。
 4.2節で挙げられた問題点を伴わないための条件
を、従属性を用いて表現できる。


第一正規形の条件にさらに条件を付け足す。

高次の正規化
第3正規形

リレーショナルデータモデルの考案者が考
えた、最も基本的な正規形

更新不整合を解消する。
第3正規形

スキーマRSの属性のうちいずれかの候補キー
の構成要素となる属性を素属性と呼ぶ。



それ以外を非素属性という。
候補キー：超キーのうち極小なもの(pg.36)。
関数従属性X->A (X⊆RS、 A∈RS, A∉X)が成立
する場合に、以下のいずれかの条件が常に満た
される時、そのスキーマを第三正規形と呼ぶ。
1.
2.
XがRSの超キーである。
Aが素属性である。 －＞ 候補キーの構成要素
第3正規形の例（pg.59の図4.1）

営業(商品番号,顧客番号, 社員番号, 販売価格)

関数従属性 顧客番号->社員番号が成立


候補キーは、唯一｛商品番号,顧客番号｝


条件(1)を満たさない。
顧客番号->社員番号 社員番号は候補キーの構成要
素（素属性）ではない


商品番号と顧客番号が決まれば、販売のタプルが決定される。
顧客番号->社員番号 顧客番号は超キーではない。


顧客番号が決まれば社員番号が決まる
条件(2)を満たさない。
よって、このリレーションは第３正規形ではない。

したがって、更新不整合を生じる。
第3正規形の例
営業を分解して得られるリレーション
販売(商品番号,顧客番号,販売価格)、
営業担当(顧客番号, 社員番号)
 関数従属性の最小被覆は、


販売：商品番号、顧客番号 －＞ 販売価格


営業担当：顧客番号－＞社員番号


商品番号、顧客番号は販売の超キー。 条件(1)を満たす。
営業担当の候補キーは｛顧客番号、社員番号｝．よって、条件
(2)を満たす。
したがって、販売,営業担当は第3正規形である。

更新不整合がおきない。
第2正規形
第1正規形から第3正規形に至るまでの中間段
階。
 関数従属性X->A （X⊆RS, A∈RS, A∉X）が成り
立つ場合には、以下の条件いずれかが常に満
たされる。

1.
2.


XはRSのいかなる候補キーの真部分集合でもない。
Aが素属性である。 －＞ 候補キーの構成要素
(1)は第3正規形の条件(1)を緩めたもの。
第3正規形は、常に第2正規形でもある。
更新不整合を起こさないスキーマの設計

すべてのリレーションスキーマを第3正規形
とすればよい。
第2正規形では不十分。
 ただし、第3正規形にすることですべての更新
不整合が解決するわけではない。
 さらに高次の正規形が存在する


リレーションスキーマRS、関数従属性集合
Fが与えられたときに、第3正規形を求める
ためのアルゴリズムが知られている(pg.69)
。
第3正規形を求めるアルゴリズム (pg.69)
ρ:=φ
M:=Fの最小被覆
if XA=RSなるX->A∈Mが存在 then
ρ:={RS}
else
begin
for each X->A in M do
begin
ρ:= ρ∪{XA}
M:=M-{X->A}
end
if いかなるリレーションスキーマ∈ρもRSの候補キーを含まない then
ρ:= ρ∪{Rの任意の候補キー}
end
第3正規形を求めるアルゴリズム

リレーションスキーマRS={I, A, S, P}


Iは商品番号、Aは販売地域、Sは販売担当者、
Pは商品の製造メーカー
関数従属性集合F={IA->S, I->P, S->A}



商品と販売地域が決まれば、販売担当者が決まる。
商品が決まればメーカーが決まる。
担当者が決まれば販売地域が決まる。
上記アルゴリズムのforループで{{I,A,S},
{I,P},{A,S}}が得られる。
 {A,S}は{I, A, S}の部分集合であるので、実際に
は、{{I,A,S}, {I,P}}が解となる。

第3正規形を求めるアルゴリズム

本当に{{I,A,S}, {I,P}}が第3正規形であるか?

R1(I, A, S)、 R2(I, P)とする。

I->P∈Fであるので、
(RS1∩RS2 → RS2－RS1) ∈ F+となり、定理4.1よ
り、これは無損失結合分解。
 R1,R2の関数従属性集合は{IA->S, I->P, S->A}
で、この分解は従属性保存分解となっている。
 {{I,A,S}, {I,P}}は第3正規形の条件を満たしている
。

確認を各自しておくこと。