1.
あなたが知らない
リレーショナルモデル
@dbtech showcase tokoy 2014
奥野 幹也
Twitter: @nippondanji
mikiya (dot) okuno (at) gmail (dot) com

2.
免責事項
本プレゼンテーションにおいて示されている見解は、私
自身の見解であって、オラクル・コーポレーションの見
解を必ずしも反映したものではありません。ご了承くだ
さい。

3.
自己紹介
● MySQL サポートエンジニア
– 日々のしごと
● トラブルシューティング全般
● Q&A回答
● パフォーマンスチューニング
など
● ライフワーク
– 自由なソフトウェアの普及
● オープンソースではない
● ブログ
今日は個人として
参加しています。
– 漢のコンピュータ道
– http://nippondanji.blogspot.com/

4.
リレーショナルモデル
と聞いて
何を思い浮かべますか？

5.
リレーショナルモデルとは？
● テーブル同士の関係を表現する方法？
● 2 次元のテーブルにデータを格納する？
● ER図を使ってモデリングすること？
● ストアドプロシージャを使ってナンボ？
すべて誤解です！！

6.
リレーショナルモデルは
誤解されている！！
● リレーショナルデータベースは覚えることが多すぎる
– データモデル
– SQL
– アプリケーションプログラムとの融合
– トランザクション
– 実装、応用
– 製品もいっぱいある
etc etc
● 言ってることがみんな違う
– サロゲートキーvs ナチュラルキー
– 正規化するべき派vs 正規化しなくても良い派
– NULL許容派vsNULL否定派
– ロジックは全部ストアドプロシージャで書け派vs
ストアドプロシージャ使ったら負け派
etc etc

7.
目の前のタスクを優先した結果
● SQL の構文とトランザクションだけとても詳しくなる
– データモデル不在
● データベースはタダの入れ物です。
– 正規化などどこ吹く風
● せっかくのリレーショナルデータベースのパワーが・・
リレーショナルモデルが蔑ろに!!

8.
リレーショナルモデルとは！
● リレーションという名前のデータ構造を用いてデータを表現
するデータモデル
– データモデル ≠ モデリング
– データモデル ＝ データの表現方法
● リレーションを単位として様々な演算を行う
– リレーションはデータそのもの
– テーブル同士の関係性（リレーションシップ）ではない

9.
リレーションとは
● 現実世界のある物事に対する事実の集合
テーブル
≒
リレーション

10.
集合の性質
● 重複がない
● NULL がない
– 実際に存在する値のみ
● 要素間に順序がない
– 例え数値でも
米国
ベトナム
日本
オーストラリア
スウェーデン
カメルーン
要素が含まれるか
どうかだけが重要

11.
リレーションの構成部品
● リレーション＝見出し（ヘッダ）＋本体（ボディ）
● 見出し（ヘッダ、headding ）
– 属性の集合
● 属性（アトリビュート）
– 名前と型（タイプ）
● 属性値
– 属性で定義された型を持つ値
– ≒列（カラム）
● 組（タプル）
– 見出しに対応した属性値の集合
– ≒行（ロー）
● 本体（ボディ）
– 組（タプル）の集合

12.
リレーションのイメージ
見出し国名/文字列国番号/整数
本体
地域/文字列
国名：日本,
国番号：81,
地域：アジア
国番号：84,
国名：ベトナム
地域：アジア
国番号：61,
国名：オーストラリア,
地域：オセアニア
国名：米国,
国番号：1,
地域：北米
地域：アフリカ,
国名：カメルーン,
国番号：237
地域：欧州,
国名：スウェーデン,
国番号：46

13.
リレーションは2 次元ではない
● n 個の属性を持つリレーションは、n 次元空間にプロットさ
れた点（のようなもの）の集合
– タプル ＝ 点
● ２次元に見えるのは縦横の軸がある表として表現するから
– 紙に描かれた絵は２次元になる
– 絵が表すものが２次元だとは限らない
● 風景や人物などはすべて３次元

14.
用語の対応
リレーショナルモデルSQL
関係（リレーション） 表（テーブル）
属性[値] （アトリビュート） 列（カラム）
組（タプル） 行（ロー）
対応する概念だが性質は異なる。

15.
演算の単位はリレーション
入力出力
リレーションR1
リレーションR2
・・・
リレーションRX
演算

16.
リレーションの演算
● 演算の入力も結果もリレーション
– n 個のリレーションの演算の結果、1 個のリレーションが
返る
● クロージャ（閉包）
● 整数と整数の足し算の結果が整数なのと同じ
– 演算結果に対して新たに別の演算を適用できる
● 集合操作に基づく演算
– 和、差、直積、射影、制限、結合etc

17.
リレーションのイメージ（再掲）
見出し国名/文字列国番号/整数
本体
地域/文字列
国名：日本,
国番号：81,
地域：アジア
国番号：86,
国名：中華人民共和国,
地域：アジア
国番号：61,
国名：オーストラリア,
地域：オセアニア
国名：米国,
国番号：1,
地域：北米
地域：アフリカ,
国名：カメルーン,
国番号：237
地域：欧州,
国名：スウェーデン,
国番号：46

18.
制限（ RESTRICT ）

19.
制限（ RESTRICT ）

20.
射影（ PROJECT ）

21.
射影（ PROJECT ）

22.
属性名変更（ RENAME ）
国名/文字列国番号/整数大陸/文字列

23.
属性名変更（ RENAME ）
国名/文字列国番号/整数地域/文字列

24.
拡張（ EXTEND ）
国名/文字列人口/整数
面積 /
実数 (km2)

25.
拡張（ EXTEND ）
国名/文字列人口/整数
面積 /
実数 (km2)
人口密度 /
実数 (人/km2)

26.
和（ UNION ）

27.
和（ UNION ）

28.
積（ INTERSECT ）

29.
積（ INTERSECT ）

30.
差（ DIFFERENCE ）

31.
差（ DIFFERENCE ）

32.
直積（ PRODUCT ）
a b
c d
x
y
z

33.
直積（ PRODUCT ）
a b x
a b y a b z
c d x c d y
c d z

34.
結合（JOIN ）
a x
b y
c z
w 1
x 2
y 3

35.
結合（JOIN ）
a x 2
b y 3

36.
豆知識
● 直積（ Product ）と積（ Intersect ）はいずれも結合（ Join)
の特殊なケース
– 直積・・・共通する属性がひとつも存在しないケース
– 積・・・すべての属性がまったく同じケース
● リレーショナルモデルに存在するJoin はInner Join だけ

37.
リレーションの演算は
分かったけど
SQL とどう関係あるの？

38.
SELECT の基本形
SELECT select_list
FROM table_reference
WHERE where_condition

39.
SELECT の実態
＝ 3 つのリレーション演算
SELECT
射影
FROM
直積
WHERE
制限

40.
リレーショナルモデルを
無視するとどうなるか
● データベース設計がぐだぐだになる。
– セオリー無視
– データとそれに対する操作はセット
● 結果、クエリもぐだぐだになる。
● データベース設計が良くないと・・・
– クエリがすっきりと表現できない
– クエリを書くのに様々なスーパーテクニックが必要に
● 他の人が見たら「なんじゃこりゃ！！？」
● 自分が後から見ても「なんじゃこりゃ！！？」
● 結果、メンテナンスが地獄
– ストアドプロシージャが颯爽と登場！！
● スーパーテクニックを駆使したクエリを手続き型で書き
なおしただけ。
● 状況はさらに悪化

41.
Ruby で配列を操作する
a = Array.new
# 要素の挿入
a.push('要素')
# N番目の要素
a[N]
スッキリ！！

42.
Ruby で配列を操作する
誤ったやり方
a = ''
# 要素の挿入
a = a << (a.size == 0 ? '要素' : “,#{要素}”)
# N番目の要素
n = 0
s = ''
a.each_char do |c|
if c == ','
return s if n == N
n += 1
s = ''
else
s << c
end
end
return s if n == N
●無駄に長い
●何をしている処理なのかが一目で
分からない
●読みづらい
●間違い（バグ）を犯しやすい
●メンテナンスが大変

43.
誤った設計は
技術的負債を生む

44.
クエリをすっきり表現するには
● 正しいデータ構造を用いる
– リレーショナルデータベース上では正しいデータ構造は
たったひとつ
– リレーション！！
● テーブルがリレーションになっていること
● 矛盾がないこと
● 集合演算＝論理演算に基づく表現
– SELECT 射影 FROM 直積 WHERE 制限

45.
述語論理
● 命題
– ある物事について記述した文章で、その意味が正しいかどうか、つま
り真なのか偽なのかを問えるもののこと
– 例）ポチは犬である
● 述語
– 命題の中の固有名詞をパラメータ化したもの
– 例） x は犬である
● 命題関数
– 述語から意味を取り除いて関数化したもの。値を代入した場
合の評価結果は述語と同じ。
– 例） F(x)
● 閉世界仮説
– リレーションは事実の集合
● 事実＝真となる命題
– リレーションには述語がある
● リレーションに含まれる組の属性値を代入 → 真
● それ以外の属性値を代入 → すべて偽

46.
宣言型vs 手続き型
● SQL は宣言型で使うべき。
● 宣言型＝WHAT
– 欲しいデータはSELECT一発でゲット！！
– 論理演算で表現されたもの
● クエリによって欲しい解（集合）に対する述語は何か？
● 手続き型＝HOW
– 難解なテクニックを駆使したSELECT
– ストアドプロシージャ
– 論理演算で欲しい解を導出することができない
● 条件分岐
● ループ

47.
何故手続き型になってしまうか
● データベース設計が間違っている！！
– 欲しい解が論理演算で得られるのは、データベースがそ
のように設計されているから
– 集合として表現する
● 集合と述語は1:1 で対応
● 集合として表現されていないと・・・
– 欲しい解は論理演算では得られない
– カーソルをスクロールさせて探す羽目に
● 宣言型で書けない場合にはデータベース設計を見直す兆
候かも

48.
正しいデータベース設計
● 集合＝リレーションとして表現されたテーブル
– NULL がない
– 重複がない
– 要素（タプル、属性）間に順序がない
– 属性の値はドメインの要素のひとつ
– 第1正規形
● リレーションになっているからリレーションの演算が適用可能
– リレーションの演算＝集合演算＝論理演算
– リレーションでないものに対してリレーションの演算は適
用できない！

49.
正規化理論
● リレーションから重複を排除するためのデータベース設計
理論
– 重複は矛盾の原因になる。
● 重複＝同じ事実を複数回述べている
● 部分的に変更すると異なる事実を述べることになる
– 矛盾が含まれていると、論理演算によって正しい答えが
導き出せない
● 矛盾は論理学の天敵
● クエリの結果が正しくない可能性がある

50.
矛盾の例
名前格闘スタイル年齢
範馬刃牙総合格闘技19
範馬勇次郎総合格闘技38
愚地独歩空手57
ビスケットオリバ怪力40
ビスケットオリバ柔道42
花山薫素手喧嘩19
烈海王中国拳法30
烈海王ボクシング30
どっちが
正しい？
データそのものを見ただけでは
どちらが正しいのかが分からない

51.
正規形（ Normal Forms ）
● 第一正規形(1NF)~第六正規形(6NF)
– より高次の正規形のほうが重複が少ない（望ましい）状態
になる。
– 3NF と4NFの間にBCNF というものがある。超重要。
– ただし最終目標は5NF
● 1NF ・・・テーブルがリレーションになっていること
– スタート地点
● 2NF~BCNF ・・・自明でない関数従属性（ FD ）を排除する
● 4NF~6NF ・・・自明でない結合従属性（JD ）を排除する
● 自明でないFD とJDが重複の元

52.
直交性
● 正規化は個々のリレーションの内部の重複をテーマにしたも
の
● リレーション同士の重複に焦点を当てたのが直交性
– 複数のリレーションにおいて同じ事実を述べていると、一
部だけを更新すると矛盾になる

53.
リレーショナルモデルは
万能薬ではない

54.
リレーショナルモデルでは
表現できないものがある
● グラフ
● ツリー
● 行列
● 履歴
● 全文検索
● 正規表現
● ソート
● 集計
● 空間データ
etc etc

55.
グラフ
● グラフとは
– ノード（頂点）をエッジ（辺）でつないだ構造を持つモデル
b
d
c
e
エッジ
ノードa
ループ
多重辺

56.
様々なグラフ
単純グラフ非連結グラフ
完全グラフ重み付きグラフ
b d
c
f
a
e
8
3
7
9
3
5
3
4
8
8

57.
データを格納するだけなら
できなくはない
● グラフ ＝ ノードの集合 ＋ エッジの集合
Nodes Edges
Node
a
b
c
d
e
f
Node1 Node2 Weight
a b 3
a e 8
b c 3
b d 8
b e 7
c d 4
c f 8
d e 5
d f 3
e f 9

58.
問題はクエリ・・・
● グラフ特有の問題をSELECT で表現できない
– グラフが連結かどうか
– 閉路はあるか
– 2 つのノード間の最短距離はどれか
– 全てのノードを通り、距離が最短になる経路はどれか
● グラフ特有の問題を解くためには・・・
– 論理演算でないアルゴリズムが必要
– ループと条件分岐
● 解決策
– リレーショナルモデル上では解決策はない！！
● ストアドプロシージャ
● グラフデータベース

59.
リレーショナルモデルの
外側の世界
● 現実世界のアプリケーション
– リレーショナルモデルに適合するデータと、そうでない
データが入り乱れている。
– リレーショナルモデルには定石がある
– リレーショナルモデル以外の領域に決定的なやりかた
（ DB設計、クエリの書き方等）はない
● 創意工夫が必要
● 外側の世界ではリレーショナルモデルを無理に実践すべき
ではない！！
– そもそも無理
– うまく行ったように見えても技術的負債に
● 両者の境界線を見極めることが重要。
– リレーショナルモデルで解決できる部分はリレーショナル
モデルを適用すべし！！
– そうでない部分はリレーショナルモデルを適用してはなら
ない！！

60.
リレーショナルモデルの
外側の世界 （つづき）
● SQL はリレーショナルモデル以外の分野も扱える
– リレーショナルモデル≒ SQL
● 完全に同じではないから外側の世界も扱うことが可能
– 重複OK
– NULL OK
– 手続き型の処理すら可能
– SQL なら非常に容易なものもある
● 例）GROUP BY, ORDER BY
– ストアドプロシージャは頼りになる
● NoSQL との連携もアリ
– 餅は餅屋

61.
NoSQL について
● リレーショナルデータベースが苦手とするようなデータを容
易に扱えるケースがある
– リレーショナルモデルの外側の世界は、NoSQL のテリト
リーかも知れない
● グラフデータベース
● ドキュメント型データベース
etc
● リレーショナルモデルはNoSQL にとっては外側の世界
– 論理的なデータの整合性を担保するのは苦労する
– 壮大な車輪の再発明が必要
● 正規化
● トランザクション
etc

62.
インデックスとは何か
● インデックスはリレーショナルモデルの一部ではない
– リレーショナルモデル＝データの論理的な表現
– インデックス＝データの物理的なアクセス手段
● ＝実装
● 論理＞物理
● クエリ（何のデータが欲しいか）が決まってから、それを実現
するためのアクセス手段を考える
– 良くある失敗：既にあるインデックスを使ってどういう風に
クエリを書くかを考える
– どのカラムの組み合わせに対してどんなインデックスが
必要なのかはクエリ次第

63.
トランザクション
● データの整合性を保つために必須の機能
– リレーショナルモデルとは全く異なる理論
– 補完関係にある
● トランザクションが実現するものは2 つ
– 同時実行制御（排他処理）
– クラッシュリカバリ
● ACID特性
– 原子性（ Atomicity ）
– 一貫性（Consistency ）
– 独立性（ Isolation ）
– 永続性（ Durability ）
一貫性を考える上で
データモデルが
重要になる

64.
複雑さに立ち向かう
● アプリケーションの規模が大きくなるとデータが複雑に
– スキーマの複雑化は避けられない
● アプリケーションのコードとの整合性
– スキーマばかりにとらわれがち
● データの整合性について見落としがち
– トランザクションが重要だということはよく把握されている
– 正規化は？
● 正規化が必要な理由はデータの整合性を保つ
● アプリケーションのコードではなくDB設計で整合性を担
保するのが正規化
● スキーマレスにしてもデータの複雑さから解放されるわけで
はない
– むしろ問題点のほうが大きい
● スキーマの整合性を担保できない
● データの整合性を担保できない

65.
まとめ：上手にRDB を使うために
● リレーショナルモデルを実践する
– クエリがすっきりと表現できる
– メンテナンス性向上
● テーブルはきっちり正規化する
– データの保全を考える
– 複雑さへの対処
● リレーショナルモデルの限界を知る
– リレーショナルモデルのセオリーが通用しない世界がある
– リレーショナルモデル以外の重要な機能について知る
● インデックス
● トランザクション

66.
おすすめの書籍
● SQL and Relational Theory
– データベースの実践講義は内容が少ないし古いのでおす
すめはしない。
● The Art of SQL
● プログラマのためのSQL
● SQL アンチパターン
● WEB+DB PRESS
– Vol.68 ~

67.
宣伝：新書籍の紹介
● リレーショナルデータベース実践入門
– リレーショナルモデル、SQL 、そしてDB 設計が主なテーマの書籍です。
– どうやってリレーショナルデータベースを使いこなすか！
● リレーショナルモデル基礎編
– SQL とリレーショナルモデル
– 述語論理とリレーショナルモデル
– 正規化1: 関数従属性
– 正規化2: 結合従属性
– 直交性
– ドメインの設計
etc
● アプリケーション開発実践編
基礎の基礎から
よくある間違いを
指摘しつつ
– 履歴
– グラフ
– インデックスの設計
– ウェブアプリケーションのためのデータ構造
etc
応用まで

68.
Q&A
ご静聴ありがとうございました。