Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
あなたが知らない
リレーショナルモデル
@dbtech showcase tokoy 2014 
奥野 幹也 
Twitter: @nippondanji 
mikiya (dot) okuno (at) gmail (dot) com
免責事項 
本プレゼンテーションにおいて示されている見解は、私 
自身の見解であって、オラクル・コーポレーションの見 
解を必ずしも反映したものではありません。ご了承くだ 
さい。
自己紹介 
● MySQL サポートエンジニア 
– 日々のしごと 
● トラブルシューティング全般 
● Q&A回答 
● パフォーマンスチューニング 
など 
● ライフワーク 
– 自由なソフトウェアの普及 
● オープンソースではない ...
リレーショナルモデル 
と聞いて 
何を思い浮かべますか?
リレーショナルモデルとは? 
● テーブル同士の関係を表現する方法? 
● 2 次元のテーブルにデータを格納する? 
● ER図を使ってモデリングすること? 
● ストアドプロシージャを使ってナンボ? 
すべて誤解です!!
リレーショナルモデルは 
誤解されている!! 
● リレーショナルデータベースは覚えることが多すぎる 
– データモデル 
– SQL 
– アプリケーションプログラムとの融合 
– トランザクション 
– 実装、応用 
– 製品もいっぱいある...
目の前のタスクを優先した結果 
● SQL の構文とトランザクションだけとても詳しくなる 
– データモデル不在 
● データベースはタダの入れ物です。 
– 正規化などどこ吹く風 
● せっかくのリレーショナルデータベースのパワーが・・ 
リ...
リレーショナルモデルとは! 
● リレーションという名前のデータ構造を用いてデータを表現 
するデータモデル 
– データモデル ≠ モデリング 
– データモデル = データの表現方法 
● リレーションを単位として様々な演算を行う 
– リ...
リレーションとは 
● 現実世界のある物事に対する事実の集合 
テーブル 
≒ 
リレーション
集合の性質 
● 重複がない 
● NULL がない 
– 実際に存在する値のみ 
● 要素間に順序がない 
– 例え数値でも 
米国 
ベトナム 
日本 
オーストラリア 
スウェーデン 
カメルーン 
要素が含まれるか 
どうかだけが重要
リレーションの構成部品 
● リレーション=見出し(ヘッダ)+本体(ボディ) 
● 見出し(ヘッダ、headding ) 
– 属性の集合 
● 属性(アトリビュート) 
– 名前と型(タイプ) 
● 属性値 
– 属性で定義された型を持つ値 ...
リレーションのイメージ 
見出し国名/文字列国番号/整数 
本体 
地域/文字列 
国名:日本, 
国番号:81, 
地域:アジア 
国番号:84, 
国名:ベトナム 
地域:アジア 
国番号:61, 
国名:オーストラリア, 
地域:オセアニ...
リレーションは2 次元ではない 
● n 個の属性を持つリレーションは、n 次元空間にプロットさ 
れた点(のようなもの)の集合 
– タプル = 点 
● 2次元に見えるのは縦横の軸がある表として表現するから 
– 紙に描かれた絵は2次元にな...
用語の対応 
リレーショナルモデルSQL 
関係(リレーション) 表(テーブル) 
属性[値] (アトリビュート) 列(カラム) 
組(タプル) 行(ロー) 
対応する概念だが性質は異なる。
演算の単位はリレーション 
入力出力 
リレーションR1 
リレーションR2 
・・・ 
リレーションRX 
演算
リレーションの演算 
● 演算の入力も結果もリレーション 
– n 個のリレーションの演算の結果、1 個のリレーションが 
返る 
● クロージャ(閉包) 
● 整数と整数の足し算の結果が整数なのと同じ 
– 演算結果に対して新たに別の演算を適...
リレーションのイメージ(再掲) 
見出し国名/文字列国番号/整数 
本体 
地域/文字列 
国名:日本, 
国番号:81, 
地域:アジア 
国番号:86, 
国名:中華人民共和国, 
地域:アジア 
国番号:61, 
国名:オーストラリア, ...
制限( RESTRICT )
制限( RESTRICT )
射影( PROJECT )
射影( PROJECT )
属性名変更( RENAME ) 
国名/文字列国番号/整数大陸/文字列
属性名変更( RENAME ) 
国名/文字列国番号/整数地域/文字列
拡張( EXTEND ) 
国名/文字列人口/整数 
面積 / 
実数 (km2)
拡張( EXTEND ) 
国名/文字列人口/整数 
面積 / 
実数 (km2) 
人口密度 / 
実数 (人/km2)
和( UNION )
和( UNION )
積( INTERSECT )
積( INTERSECT )
差( DIFFERENCE )
差( DIFFERENCE )
直積( PRODUCT ) 
a b 
c d 
x 
y 
z
直積( PRODUCT ) 
a b x 
a b y a b z 
c d x c d y 
c d z
結合(JOIN ) 
a x 
b y 
c z 
w 1 
x 2 
y 3
結合(JOIN ) 
a x 2 
b y 3
豆知識 
● 直積( Product )と積( Intersect )はいずれも結合( Join) 
の特殊なケース 
– 直積・・・共通する属性がひとつも存在しないケース 
– 積・・・すべての属性がまったく同じケース 
● リレーショナルモ...
リレーションの演算は 
分かったけど 
SQL とどう関係あるの?
SELECT の基本形 
SELECT select_list 
FROM table_reference 
WHERE where_condition
SELECT の実態 
= 3 つのリレーション演算 
SELECT 
射影 
FROM 
直積 
WHERE 
制限
リレーショナルモデルを 
無視するとどうなるか 
● データベース設計がぐだぐだになる。 
– セオリー無視 
– データとそれに対する操作はセット 
● 結果、クエリもぐだぐだになる。 
● データベース設計が良くないと・・・ 
– クエリが...
Ruby で配列を操作する 
a = Array.new 
# 要素の挿入 
a.push('要素') 
# N番目の要素 
a[N] 
スッキリ!!
Ruby で配列を操作する 
誤ったやり方 
a = '' 
# 要素の挿入 
a = a << (a.size == 0 ? '要素' : “,#{要素}”) 
# N番目の要素 
n = 0 
s = '' 
a.each_char do ...
誤った設計は 
技術的負債を生む
クエリをすっきり表現するには 
● 正しいデータ構造を用いる 
– リレーショナルデータベース上では正しいデータ構造は 
たったひとつ 
– リレーション!! 
● テーブルがリレーションになっていること 
● 矛盾がないこと 
● 集合演算=...
述語論理 
● 命題 
– ある物事について記述した文章で、その意味が正しいかどうか、つま 
り真なのか偽なのかを問えるもののこと 
– 例)ポチは犬である 
● 述語 
– 命題の中の固有名詞をパラメータ化したもの 
– 例) x は犬である...
宣言型vs 手続き型 
● SQL は宣言型で使うべき。 
● 宣言型=WHAT 
– 欲しいデータはSELECT一発でゲット!! 
– 論理演算で表現されたもの 
● クエリによって欲しい解(集合)に対する述語は何か? 
● 手続き型=HOW...
何故手続き型になってしまうか 
● データベース設計が間違っている!! 
– 欲しい解が論理演算で得られるのは、データベースがそ 
のように設計されているから 
– 集合として表現する 
● 集合と述語は1:1 で対応 
● 集合として表現され...
正しいデータベース設計 
● 集合=リレーションとして表現されたテーブル 
– NULL がない 
– 重複がない 
– 要素(タプル、属性)間に順序がない 
– 属性の値はドメインの要素のひとつ 
– 第1正規形 
● リレーションになってい...
正規化理論 
● リレーションから重複を排除するためのデータベース設計 
理論 
– 重複は矛盾の原因になる。 
● 重複=同じ事実を複数回述べている 
● 部分的に変更すると異なる事実を述べることになる 
– 矛盾が含まれていると、論理演算に...
矛盾の例 
名前格闘スタイル年齢 
範馬刃牙総合格闘技19 
範馬勇次郎総合格闘技38 
愚地独歩空手57 
ビスケットオリバ怪力40 
ビスケットオリバ柔道42 
花山薫素手喧嘩19 
烈海王中国拳法30 
烈海王ボクシング30 
どっちが ...
正規形( Normal Forms ) 
● 第一正規形(1NF)~第六正規形(6NF) 
– より高次の正規形のほうが重複が少ない(望ましい)状態 
になる。 
– 3NF と4NFの間にBCNF というものがある。超重要。 
– ただし最終...
直交性 
● 正規化は個々のリレーションの内部の重複をテーマにしたも 
の 
● リレーション同士の重複に焦点を当てたのが直交性 
– 複数のリレーションにおいて同じ事実を述べていると、一 
部だけを更新すると矛盾になる
リレーショナルモデルは 
万能薬ではない
リレーショナルモデルでは 
表現できないものがある 
● グラフ 
● ツリー 
● 行列 
● 履歴 
● 全文検索 
● 正規表現 
● ソート 
● 集計 
● 空間データ 
etc etc
グラフ 
● グラフとは 
– ノード(頂点)をエッジ(辺)でつないだ構造を持つモデル 
b 
d 
c 
e 
エッジ 
ノードa 
ループ 
多重辺
様々なグラフ 
単純グラフ非連結グラフ 
完全グラフ重み付きグラフ 
b d 
c 
f 
a 
e 
8 
3 
7 
9 
3 
5 
3 
4 
8 
8
データを格納するだけなら 
できなくはない 
● グラフ = ノードの集合 + エッジの集合 
Nodes Edges 
Node 
a 
b 
c 
d 
e 
f 
Node1 Node2 Weight 
a b 3 
a e 8 
b c...
問題はクエリ・・・ 
● グラフ特有の問題をSELECT で表現できない 
– グラフが連結かどうか 
– 閉路はあるか 
– 2 つのノード間の最短距離はどれか 
– 全てのノードを通り、距離が最短になる経路はどれか 
● グラフ特有の問題を...
リレーショナルモデルの 
外側の世界 
● 現実世界のアプリケーション 
– リレーショナルモデルに適合するデータと、そうでない 
データが入り乱れている。 
– リレーショナルモデルには定石がある 
– リレーショナルモデル以外の領域に決定的...
リレーショナルモデルの 
外側の世界 (つづき) 
● SQL はリレーショナルモデル以外の分野も扱える 
– リレーショナルモデル≒ SQL 
● 完全に同じではないから外側の世界も扱うことが可能 
– 重複OK 
– NULL OK 
– ...
NoSQL について 
● リレーショナルデータベースが苦手とするようなデータを容 
易に扱えるケースがある 
– リレーショナルモデルの外側の世界は、NoSQL のテリト 
リーかも知れない 
● グラフデータベース 
● ドキュメント型デー...
インデックスとは何か 
● インデックスはリレーショナルモデルの一部ではない 
– リレーショナルモデル=データの論理的な表現 
– インデックス=データの物理的なアクセス手段 
● =実装 
● 論理>物理 
● クエリ(何のデータが欲しいか...
トランザクション 
● データの整合性を保つために必須の機能 
– リレーショナルモデルとは全く異なる理論 
– 補完関係にある 
● トランザクションが実現するものは2 つ 
– 同時実行制御(排他処理) 
– クラッシュリカバリ 
● AC...
複雑さに立ち向かう 
● アプリケーションの規模が大きくなるとデータが複雑に 
– スキーマの複雑化は避けられない 
● アプリケーションのコードとの整合性 
– スキーマばかりにとらわれがち 
● データの整合性について見落としがち 
– ト...
まとめ:上手にRDB を使うために 
● リレーショナルモデルを実践する 
– クエリがすっきりと表現できる 
– メンテナンス性向上 
● テーブルはきっちり正規化する 
– データの保全を考える 
– 複雑さへの対処 
● リレーショナルモ...
おすすめの書籍 
● SQL and Relational Theory 
– データベースの実践講義は内容が少ないし古いのでおす 
すめはしない。 
● The Art of SQL 
● プログラマのためのSQL 
● SQL アンチパター...
宣伝:新書籍の紹介 
● リレーショナルデータベース実践入門 
– リレーショナルモデル、SQL 、そしてDB 設計が主なテーマの書籍です。 
– どうやってリレーショナルデータベースを使いこなすか! 
● リレーショナルモデル基礎編 
– S...
Q&A 
ご静聴ありがとうございました。
Upcoming SlideShare
Loading in …5
×

あなたが知らない リレーショナルモデル

24,802 views

Published on

dbtech showcase 2014で使ったスライドです。

Published in: Software
  • Be the first to comment

あなたが知らない リレーショナルモデル

  1. 1. あなたが知らない リレーショナルモデル @dbtech showcase tokoy 2014 奥野 幹也 Twitter: @nippondanji mikiya (dot) okuno (at) gmail (dot) com
  2. 2. 免責事項 本プレゼンテーションにおいて示されている見解は、私 自身の見解であって、オラクル・コーポレーションの見 解を必ずしも反映したものではありません。ご了承くだ さい。
  3. 3. 自己紹介 ● MySQL サポートエンジニア – 日々のしごと ● トラブルシューティング全般 ● Q&A回答 ● パフォーマンスチューニング など ● ライフワーク – 自由なソフトウェアの普及 ● オープンソースではない ● ブログ 今日は個人として 参加しています。 – 漢のコンピュータ道 – http://nippondanji.blogspot.com/
  4. 4. リレーショナルモデル と聞いて 何を思い浮かべますか?
  5. 5. リレーショナルモデルとは? ● テーブル同士の関係を表現する方法? ● 2 次元のテーブルにデータを格納する? ● ER図を使ってモデリングすること? ● ストアドプロシージャを使ってナンボ? すべて誤解です!!
  6. 6. リレーショナルモデルは 誤解されている!! ● リレーショナルデータベースは覚えることが多すぎる – データモデル – SQL – アプリケーションプログラムとの融合 – トランザクション – 実装、応用 – 製品もいっぱいある etc etc ● 言ってることがみんな違う – サロゲートキーvs ナチュラルキー – 正規化するべき派vs 正規化しなくても良い派 – NULL許容派vsNULL否定派 – ロジックは全部ストアドプロシージャで書け派vs ストアドプロシージャ使ったら負け派 etc etc
  7. 7. 目の前のタスクを優先した結果 ● SQL の構文とトランザクションだけとても詳しくなる – データモデル不在 ● データベースはタダの入れ物です。 – 正規化などどこ吹く風 ● せっかくのリレーショナルデータベースのパワーが・・ リレーショナルモデルが蔑ろに!!
  8. 8. リレーショナルモデルとは! ● リレーションという名前のデータ構造を用いてデータを表現 するデータモデル – データモデル ≠ モデリング – データモデル = データの表現方法 ● リレーションを単位として様々な演算を行う – リレーションはデータそのもの – テーブル同士の関係性(リレーションシップ)ではない
  9. 9. リレーションとは ● 現実世界のある物事に対する事実の集合 テーブル ≒ リレーション
  10. 10. 集合の性質 ● 重複がない ● NULL がない – 実際に存在する値のみ ● 要素間に順序がない – 例え数値でも 米国 ベトナム 日本 オーストラリア スウェーデン カメルーン 要素が含まれるか どうかだけが重要
  11. 11. リレーションの構成部品 ● リレーション=見出し(ヘッダ)+本体(ボディ) ● 見出し(ヘッダ、headding ) – 属性の集合 ● 属性(アトリビュート) – 名前と型(タイプ) ● 属性値 – 属性で定義された型を持つ値 – ≒列(カラム) ● 組(タプル) – 見出しに対応した属性値の集合 – ≒行(ロー) ● 本体(ボディ) – 組(タプル)の集合
  12. 12. リレーションのイメージ 見出し国名/文字列国番号/整数 本体 地域/文字列 国名:日本, 国番号:81, 地域:アジア 国番号:84, 国名:ベトナム 地域:アジア 国番号:61, 国名:オーストラリア, 地域:オセアニア 国名:米国, 国番号:1, 地域:北米 地域:アフリカ, 国名:カメルーン, 国番号:237 地域:欧州, 国名:スウェーデン, 国番号:46
  13. 13. リレーションは2 次元ではない ● n 個の属性を持つリレーションは、n 次元空間にプロットさ れた点(のようなもの)の集合 – タプル = 点 ● 2次元に見えるのは縦横の軸がある表として表現するから – 紙に描かれた絵は2次元になる – 絵が表すものが2次元だとは限らない ● 風景や人物などはすべて3次元
  14. 14. 用語の対応 リレーショナルモデルSQL 関係(リレーション) 表(テーブル) 属性[値] (アトリビュート) 列(カラム) 組(タプル) 行(ロー) 対応する概念だが性質は異なる。
  15. 15. 演算の単位はリレーション 入力出力 リレーションR1 リレーションR2 ・・・ リレーションRX 演算
  16. 16. リレーションの演算 ● 演算の入力も結果もリレーション – n 個のリレーションの演算の結果、1 個のリレーションが 返る ● クロージャ(閉包) ● 整数と整数の足し算の結果が整数なのと同じ – 演算結果に対して新たに別の演算を適用できる ● 集合操作に基づく演算 – 和、差、直積、射影、制限、結合etc
  17. 17. リレーションのイメージ(再掲) 見出し国名/文字列国番号/整数 本体 地域/文字列 国名:日本, 国番号:81, 地域:アジア 国番号:86, 国名:中華人民共和国, 地域:アジア 国番号:61, 国名:オーストラリア, 地域:オセアニア 国名:米国, 国番号:1, 地域:北米 地域:アフリカ, 国名:カメルーン, 国番号:237 地域:欧州, 国名:スウェーデン, 国番号:46
  18. 18. 制限( RESTRICT )
  19. 19. 制限( RESTRICT )
  20. 20. 射影( PROJECT )
  21. 21. 射影( PROJECT )
  22. 22. 属性名変更( RENAME ) 国名/文字列国番号/整数大陸/文字列
  23. 23. 属性名変更( RENAME ) 国名/文字列国番号/整数地域/文字列
  24. 24. 拡張( EXTEND ) 国名/文字列人口/整数 面積 / 実数 (km2)
  25. 25. 拡張( EXTEND ) 国名/文字列人口/整数 面積 / 実数 (km2) 人口密度 / 実数 (人/km2)
  26. 26. 和( UNION )
  27. 27. 和( UNION )
  28. 28. 積( INTERSECT )
  29. 29. 積( INTERSECT )
  30. 30. 差( DIFFERENCE )
  31. 31. 差( DIFFERENCE )
  32. 32. 直積( PRODUCT ) a b c d x y z
  33. 33. 直積( PRODUCT ) a b x a b y a b z c d x c d y c d z
  34. 34. 結合(JOIN ) a x b y c z w 1 x 2 y 3
  35. 35. 結合(JOIN ) a x 2 b y 3
  36. 36. 豆知識 ● 直積( Product )と積( Intersect )はいずれも結合( Join) の特殊なケース – 直積・・・共通する属性がひとつも存在しないケース – 積・・・すべての属性がまったく同じケース ● リレーショナルモデルに存在するJoin はInner Join だけ
  37. 37. リレーションの演算は 分かったけど SQL とどう関係あるの?
  38. 38. SELECT の基本形 SELECT select_list FROM table_reference WHERE where_condition
  39. 39. SELECT の実態 = 3 つのリレーション演算 SELECT 射影 FROM 直積 WHERE 制限
  40. 40. リレーショナルモデルを 無視するとどうなるか ● データベース設計がぐだぐだになる。 – セオリー無視 – データとそれに対する操作はセット ● 結果、クエリもぐだぐだになる。 ● データベース設計が良くないと・・・ – クエリがすっきりと表現できない – クエリを書くのに様々なスーパーテクニックが必要に ● 他の人が見たら「なんじゃこりゃ!!?」 ● 自分が後から見ても「なんじゃこりゃ!!?」 ● 結果、メンテナンスが地獄 – ストアドプロシージャが颯爽と登場!! ● スーパーテクニックを駆使したクエリを手続き型で書き なおしただけ。 ● 状況はさらに悪化
  41. 41. Ruby で配列を操作する a = Array.new # 要素の挿入 a.push('要素') # N番目の要素 a[N] スッキリ!!
  42. 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. 43. 誤った設計は 技術的負債を生む
  44. 44. クエリをすっきり表現するには ● 正しいデータ構造を用いる – リレーショナルデータベース上では正しいデータ構造は たったひとつ – リレーション!! ● テーブルがリレーションになっていること ● 矛盾がないこと ● 集合演算=論理演算に基づく表現 – SELECT 射影 FROM 直積 WHERE 制限
  45. 45. 述語論理 ● 命題 – ある物事について記述した文章で、その意味が正しいかどうか、つま り真なのか偽なのかを問えるもののこと – 例)ポチは犬である ● 述語 – 命題の中の固有名詞をパラメータ化したもの – 例) x は犬である ● 命題関数 – 述語から意味を取り除いて関数化したもの。値を代入した場 合の評価結果は述語と同じ。 – 例) F(x) ● 閉世界仮説 – リレーションは事実の集合 ● 事実=真となる命題 – リレーションには述語がある ● リレーションに含まれる組の属性値を代入 → 真 ● それ以外の属性値を代入 → すべて偽
  46. 46. 宣言型vs 手続き型 ● SQL は宣言型で使うべき。 ● 宣言型=WHAT – 欲しいデータはSELECT一発でゲット!! – 論理演算で表現されたもの ● クエリによって欲しい解(集合)に対する述語は何か? ● 手続き型=HOW – 難解なテクニックを駆使したSELECT – ストアドプロシージャ – 論理演算で欲しい解を導出することができない ● 条件分岐 ● ループ
  47. 47. 何故手続き型になってしまうか ● データベース設計が間違っている!! – 欲しい解が論理演算で得られるのは、データベースがそ のように設計されているから – 集合として表現する ● 集合と述語は1:1 で対応 ● 集合として表現されていないと・・・ – 欲しい解は論理演算では得られない – カーソルをスクロールさせて探す羽目に ● 宣言型で書けない場合にはデータベース設計を見直す兆 候かも
  48. 48. 正しいデータベース設計 ● 集合=リレーションとして表現されたテーブル – NULL がない – 重複がない – 要素(タプル、属性)間に順序がない – 属性の値はドメインの要素のひとつ – 第1正規形 ● リレーションになっているからリレーションの演算が適用可能 – リレーションの演算=集合演算=論理演算 – リレーションでないものに対してリレーションの演算は適 用できない!
  49. 49. 正規化理論 ● リレーションから重複を排除するためのデータベース設計 理論 – 重複は矛盾の原因になる。 ● 重複=同じ事実を複数回述べている ● 部分的に変更すると異なる事実を述べることになる – 矛盾が含まれていると、論理演算によって正しい答えが 導き出せない ● 矛盾は論理学の天敵 ● クエリの結果が正しくない可能性がある
  50. 50. 矛盾の例 名前格闘スタイル年齢 範馬刃牙総合格闘技19 範馬勇次郎総合格闘技38 愚地独歩空手57 ビスケットオリバ怪力40 ビスケットオリバ柔道42 花山薫素手喧嘩19 烈海王中国拳法30 烈海王ボクシング30 どっちが 正しい? データそのものを見ただけでは どちらが正しいのかが分からない
  51. 51. 正規形( Normal Forms ) ● 第一正規形(1NF)~第六正規形(6NF) – より高次の正規形のほうが重複が少ない(望ましい)状態 になる。 – 3NF と4NFの間にBCNF というものがある。超重要。 – ただし最終目標は5NF ● 1NF ・・・テーブルがリレーションになっていること – スタート地点 ● 2NF~BCNF ・・・自明でない関数従属性( FD )を排除する ● 4NF~6NF ・・・自明でない結合従属性(JD )を排除する ● 自明でないFD とJDが重複の元
  52. 52. 直交性 ● 正規化は個々のリレーションの内部の重複をテーマにしたも の ● リレーション同士の重複に焦点を当てたのが直交性 – 複数のリレーションにおいて同じ事実を述べていると、一 部だけを更新すると矛盾になる
  53. 53. リレーショナルモデルは 万能薬ではない
  54. 54. リレーショナルモデルでは 表現できないものがある ● グラフ ● ツリー ● 行列 ● 履歴 ● 全文検索 ● 正規表現 ● ソート ● 集計 ● 空間データ etc etc
  55. 55. グラフ ● グラフとは – ノード(頂点)をエッジ(辺)でつないだ構造を持つモデル b d c e エッジ ノードa ループ 多重辺
  56. 56. 様々なグラフ 単純グラフ非連結グラフ 完全グラフ重み付きグラフ b d c f a e 8 3 7 9 3 5 3 4 8 8
  57. 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. 58. 問題はクエリ・・・ ● グラフ特有の問題をSELECT で表現できない – グラフが連結かどうか – 閉路はあるか – 2 つのノード間の最短距離はどれか – 全てのノードを通り、距離が最短になる経路はどれか ● グラフ特有の問題を解くためには・・・ – 論理演算でないアルゴリズムが必要 – ループと条件分岐 ● 解決策 – リレーショナルモデル上では解決策はない!! ● ストアドプロシージャ ● グラフデータベース
  59. 59. リレーショナルモデルの 外側の世界 ● 現実世界のアプリケーション – リレーショナルモデルに適合するデータと、そうでない データが入り乱れている。 – リレーショナルモデルには定石がある – リレーショナルモデル以外の領域に決定的なやりかた ( DB設計、クエリの書き方等)はない ● 創意工夫が必要 ● 外側の世界ではリレーショナルモデルを無理に実践すべき ではない!! – そもそも無理 – うまく行ったように見えても技術的負債に ● 両者の境界線を見極めることが重要。 – リレーショナルモデルで解決できる部分はリレーショナル モデルを適用すべし!! – そうでない部分はリレーショナルモデルを適用してはなら ない!!
  60. 60. リレーショナルモデルの 外側の世界 (つづき) ● SQL はリレーショナルモデル以外の分野も扱える – リレーショナルモデル≒ SQL ● 完全に同じではないから外側の世界も扱うことが可能 – 重複OK – NULL OK – 手続き型の処理すら可能 – SQL なら非常に容易なものもある ● 例)GROUP BY, ORDER BY – ストアドプロシージャは頼りになる ● NoSQL との連携もアリ – 餅は餅屋
  61. 61. NoSQL について ● リレーショナルデータベースが苦手とするようなデータを容 易に扱えるケースがある – リレーショナルモデルの外側の世界は、NoSQL のテリト リーかも知れない ● グラフデータベース ● ドキュメント型データベース etc ● リレーショナルモデルはNoSQL にとっては外側の世界 – 論理的なデータの整合性を担保するのは苦労する – 壮大な車輪の再発明が必要 ● 正規化 ● トランザクション etc
  62. 62. インデックスとは何か ● インデックスはリレーショナルモデルの一部ではない – リレーショナルモデル=データの論理的な表現 – インデックス=データの物理的なアクセス手段 ● =実装 ● 論理>物理 ● クエリ(何のデータが欲しいか)が決まってから、それを実現 するためのアクセス手段を考える – 良くある失敗:既にあるインデックスを使ってどういう風に クエリを書くかを考える – どのカラムの組み合わせに対してどんなインデックスが 必要なのかはクエリ次第
  63. 63. トランザクション ● データの整合性を保つために必須の機能 – リレーショナルモデルとは全く異なる理論 – 補完関係にある ● トランザクションが実現するものは2 つ – 同時実行制御(排他処理) – クラッシュリカバリ ● ACID特性 – 原子性( Atomicity ) – 一貫性(Consistency ) – 独立性( Isolation ) – 永続性( Durability ) 一貫性を考える上で データモデルが 重要になる
  64. 64. 複雑さに立ち向かう ● アプリケーションの規模が大きくなるとデータが複雑に – スキーマの複雑化は避けられない ● アプリケーションのコードとの整合性 – スキーマばかりにとらわれがち ● データの整合性について見落としがち – トランザクションが重要だということはよく把握されている – 正規化は? ● 正規化が必要な理由はデータの整合性を保つ ● アプリケーションのコードではなくDB設計で整合性を担 保するのが正規化 ● スキーマレスにしてもデータの複雑さから解放されるわけで はない – むしろ問題点のほうが大きい ● スキーマの整合性を担保できない ● データの整合性を担保できない
  65. 65. まとめ:上手にRDB を使うために ● リレーショナルモデルを実践する – クエリがすっきりと表現できる – メンテナンス性向上 ● テーブルはきっちり正規化する – データの保全を考える – 複雑さへの対処 ● リレーショナルモデルの限界を知る – リレーショナルモデルのセオリーが通用しない世界がある – リレーショナルモデル以外の重要な機能について知る ● インデックス ● トランザクション
  66. 66. おすすめの書籍 ● SQL and Relational Theory – データベースの実践講義は内容が少ないし古いのでおす すめはしない。 ● The Art of SQL ● プログラマのためのSQL ● SQL アンチパターン ● WEB+DB PRESS – Vol.68 ~
  67. 67. 宣伝:新書籍の紹介 ● リレーショナルデータベース実践入門 – リレーショナルモデル、SQL 、そしてDB 設計が主なテーマの書籍です。 – どうやってリレーショナルデータベースを使いこなすか! ● リレーショナルモデル基礎編 – SQL とリレーショナルモデル – 述語論理とリレーショナルモデル – 正規化1: 関数従属性 – 正規化2: 結合従属性 – 直交性 – ドメインの設計 etc ● アプリケーション開発実践編 基礎の基礎から よくある間違いを 指摘しつつ – 履歴 – グラフ – インデックスの設計 – ウェブアプリケーションのためのデータ構造 etc 応用まで
  68. 68. Q&A ご静聴ありがとうございました。

×