Contenu connexe Similaire à あなたが知らない リレーショナルモデル (20) Plus de Mikiya Okuno (20) あなたが知らない リレーショナルモデル3. 自己紹介
● MySQL サポートエンジニア
– 日々のしごと
● トラブルシューティング全般
● Q&A回答
● パフォーマンスチューニング
など
● ライフワーク
– 自由なソフトウェアの普及
● オープンソースではない
● ブログ
今日は個人として
参加しています。
– 漢のコンピュータ道
– http://nippondanji.blogspot.com/
6. リレーショナルモデルは
誤解されている!!
● リレーショナルデータベースは覚えることが多すぎる
– データモデル
– SQL
– アプリケーションプログラムとの融合
– トランザクション
– 実装、応用
– 製品もいっぱいある
etc etc
● 言ってることがみんな違う
– サロゲートキーvs ナチュラルキー
– 正規化するべき派vs 正規化しなくても良い派
– NULL許容派vsNULL否定派
– ロジックは全部ストアドプロシージャで書け派vs
ストアドプロシージャ使ったら負け派
etc etc
7. 目の前のタスクを優先した結果
● SQL の構文とトランザクションだけとても詳しくなる
– データモデル不在
● データベースはタダの入れ物です。
– 正規化などどこ吹く風
● せっかくのリレーショナルデータベースのパワーが・・
リレーショナルモデルが蔑ろに!!
10. 集合の性質
● 重複がない
● NULL がない
– 実際に存在する値のみ
● 要素間に順序がない
– 例え数値でも
米国
ベトナム
日本
オーストラリア
スウェーデン
カメルーン
要素が含まれるか
どうかだけが重要
11. リレーションの構成部品
● リレーション=見出し(ヘッダ)+本体(ボディ)
● 見出し(ヘッダ、headding )
– 属性の集合
● 属性(アトリビュート)
– 名前と型(タイプ)
● 属性値
– 属性で定義された型を持つ値
– ≒列(カラム)
● 組(タプル)
– 見出しに対応した属性値の集合
– ≒行(ロー)
● 本体(ボディ)
– 組(タプル)の集合
12. リレーションのイメージ
見出し国名/文字列国番号/整数
本体
地域/文字列
国名:日本,
国番号:81,
地域:アジア
国番号:84,
国名:ベトナム
地域:アジア
国番号:61,
国名:オーストラリア,
地域:オセアニア
国名:米国,
国番号:1,
地域:北米
地域:アフリカ,
国名:カメルーン,
国番号:237
地域:欧州,
国名:スウェーデン,
国番号:46
13. リレーションは2 次元ではない
● n 個の属性を持つリレーションは、n 次元空間にプロットさ
れた点(のようなもの)の集合
– タプル = 点
● 2次元に見えるのは縦横の軸がある表として表現するから
– 紙に描かれた絵は2次元になる
– 絵が表すものが2次元だとは限らない
● 風景や人物などはすべて3次元
16. リレーションの演算
● 演算の入力も結果もリレーション
– n 個のリレーションの演算の結果、1 個のリレーションが
返る
● クロージャ(閉包)
● 整数と整数の足し算の結果が整数なのと同じ
– 演算結果に対して新たに別の演算を適用できる
● 集合操作に基づく演算
– 和、差、直積、射影、制限、結合etc
17. リレーションのイメージ(再掲)
見出し国名/文字列国番号/整数
本体
地域/文字列
国名:日本,
国番号:81,
地域:アジア
国番号:86,
国名:中華人民共和国,
地域:アジア
国番号:61,
国名:オーストラリア,
地域:オセアニア
国名:米国,
国番号:1,
地域:北米
地域:アフリカ,
国名:カメルーン,
国番号:237
地域:欧州,
国名:スウェーデン,
国番号:46
25. 拡張( EXTEND )
国名/文字列人口/整数
面積 /
実数 (km2)
人口密度 /
実数 (人/km2)
36. 豆知識
● 直積( Product )と積( Intersect )はいずれも結合( Join)
の特殊なケース
– 直積・・・共通する属性がひとつも存在しないケース
– 積・・・すべての属性がまったく同じケース
● リレーショナルモデルに存在するJoin はInner Join だけ
40. リレーショナルモデルを
無視するとどうなるか
● データベース設計がぐだぐだになる。
– セオリー無視
– データとそれに対する操作はセット
● 結果、クエリもぐだぐだになる。
● データベース設計が良くないと・・・
– クエリがすっきりと表現できない
– クエリを書くのに様々なスーパーテクニックが必要に
● 他の人が見たら「なんじゃこりゃ!!?」
● 自分が後から見ても「なんじゃこりゃ!!?」
● 結果、メンテナンスが地獄
– ストアドプロシージャが颯爽と登場!!
● スーパーテクニックを駆使したクエリを手続き型で書き
なおしただけ。
● 状況はさらに悪化
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
●無駄に長い
●何をしている処理なのかが一目で
分からない
●読みづらい
●間違い(バグ)を犯しやすい
●メンテナンスが大変
44. クエリをすっきり表現するには
● 正しいデータ構造を用いる
– リレーショナルデータベース上では正しいデータ構造は
たったひとつ
– リレーション!!
● テーブルがリレーションになっていること
● 矛盾がないこと
● 集合演算=論理演算に基づく表現
– SELECT 射影 FROM 直積 WHERE 制限
45. 述語論理
● 命題
– ある物事について記述した文章で、その意味が正しいかどうか、つま
り真なのか偽なのかを問えるもののこと
– 例)ポチは犬である
● 述語
– 命題の中の固有名詞をパラメータ化したもの
– 例) x は犬である
● 命題関数
– 述語から意味を取り除いて関数化したもの。値を代入した場
合の評価結果は述語と同じ。
– 例) F(x)
● 閉世界仮説
– リレーションは事実の集合
● 事実=真となる命題
– リレーションには述語がある
● リレーションに含まれる組の属性値を代入 → 真
● それ以外の属性値を代入 → すべて偽
46. 宣言型vs 手続き型
● SQL は宣言型で使うべき。
● 宣言型=WHAT
– 欲しいデータはSELECT一発でゲット!!
– 論理演算で表現されたもの
● クエリによって欲しい解(集合)に対する述語は何か?
● 手続き型=HOW
– 難解なテクニックを駆使したSELECT
– ストアドプロシージャ
– 論理演算で欲しい解を導出することができない
● 条件分岐
● ループ
47. 何故手続き型になってしまうか
● データベース設計が間違っている!!
– 欲しい解が論理演算で得られるのは、データベースがそ
のように設計されているから
– 集合として表現する
● 集合と述語は1:1 で対応
● 集合として表現されていないと・・・
– 欲しい解は論理演算では得られない
– カーソルをスクロールさせて探す羽目に
● 宣言型で書けない場合にはデータベース設計を見直す兆
候かも
48. 正しいデータベース設計
● 集合=リレーションとして表現されたテーブル
– NULL がない
– 重複がない
– 要素(タプル、属性)間に順序がない
– 属性の値はドメインの要素のひとつ
– 第1正規形
● リレーションになっているからリレーションの演算が適用可能
– リレーションの演算=集合演算=論理演算
– リレーションでないものに対してリレーションの演算は適
用できない!
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が重複の元
55. グラフ
● グラフとは
– ノード(頂点)をエッジ(辺)でつないだ構造を持つモデル
b
d
c
e
エッジ
ノードa
ループ
多重辺
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
応用まで