帰ってきたネ申プレゼン！ #dbts2014 で @nippondanji 氏の「あなたが知らないリレーショナルモデル」と #meet_wow してきた。

f:id:garage-kid:20141113200034p:plain

今日は db tech showcase 2014 に参加してきました。

今回は諸事情により、フルデイ参加は厳しかったのでどうしても聞きたかった @nippondanji 氏のセッションだけ参加してきました。

だが、しかぁし！！

以前わたしが@nippondanji 氏の「データベース設計徹底指南！！」は神プレゼン！脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件！で紹介させていただいたプレゼン同様、期待を裏切らない素晴らしいセッションでした！

ちょっと無理しましたが、参加してきてよかった！

というわけでまず、わたしの感想から

間違いなくおカネのとれるコンテンツを無料で聞けて db tech show case 運営の方々と @nippondanji 氏に感謝！

リレーショナルモデルと聞いて何を思い浮かべるか？と聞かれて「テーブル同士の関係」とか「 2 次元のテーブルのデータを格納」とか答えちゃいそうな人は絶対に一読したほうがいいスライド。

DB 設計を蔑ろにしていると運用で泣きをみるのは言わずもがななので少しでも不安がある人は読んでみることをオススメしたい。

データベース設計徹底指南のエッセンシャル版（要約版）と思いきや、リレーショナルモデルの内の世界と外の世界という解釈、複雑さにどう対処したらいいかというテーマが追加されているエッセンシャル（洗練版）だったので、両方とも読むが吉という感想。

正規化、直交性等については今回は詳細が割愛されていましたが、それは先のデータベース設計徹底指南が詳しい。

先のプレゼンが 132 スライドだったものを 68 スライドに圧縮しているとは言え、 50 分に収めるのは脅威的でした。メモをとるのはまさに修行でした！

そして、ついに @nippondanji 氏の新著作「リレーショナルデータベース実践入門」のアナウンスが！

スケジュールはおしているらしく来春来年一月発売予定とのこと。これはマストバイ！！*1

リレーショナルモデルを勉強するための書籍はじつはあまりないので個人的に大変うれしい！

では以降に、こちらにわたしのとってきたメモも公開しておきます！
すでに @nipponanji 氏はスライド（あなたが知らないリレーショナルモデル）を公開されていますが、、よろしければといったところで。

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

リレーショナルデータベースが世の中に登場してから随分経ちますが、未だにそのデータモデルであるリレーショナルモデルがちゃんと理解されているとは言いがたい状況が続いています。リレーショナルデータベースがその真価を発揮するには、リレーショナルモデルに従ったデータベース設計が不可欠です。意外と誤解の多い（？）リレーショナルモデルについての解説をします。

朝一だけど満席！！
朝から地味なタイトルのセッションにきてくれてありがとう！！
100 枚以上のスライドを圧縮した
免責事項、会社とは関係ないものです。
自己紹介
- いわずとしれた @nippondanji
- 自由なソフトウェアの普及に燃える
リレーショナルモデルと聞いて何を思い浮かべるか
- テーブル同士の関係？
- 二次元のテーブルのデータを格納？
  - これらすべて誤解
誤解は何で起きる？
- RDB は覚えることが多すぎる
- 例えば、データモデル、 SQL 、トランザクション
- パフォーマンス・チューニング
- 製品もたくさん
- それぞれいっていることも違う
  - サロゲートキー vs ナチュラルキー
  - 正規化 vs 非正規化
目の前のタスクを優先した結果
- SQL の構文とトランザクションにだけ詳しくなっていく
  - そうするとデータモデルが歯抜け状態になっていく
    - データベースはただのいれものです
    - せっかくのレレ〜ショナルデータベースの恩恵がなくなる
リレーショナルモデルとは結局なに？
- リレーションという名前のデータ構造を用いてデータを表現するデータモデル
  - データの表現方法
- リレーションを単位として様々な演算を行う
  - リレーションはデータそのもの
  - テーブル同士の関係性のことではない
リレーションとは？
- 現実世界にある物事にたいする事実の集合
- テーブル≒リレーション
集合の性質（テーブルとの違い）
- 重複がない
- NULL がない
- 要素間に順序がない
  - 要素が含まれるかどうか、が重要
リレーションの構成部分
- リレーション＝見出し＋本体
- 見出し
  - 属性の集合
- 属性
- 属性値
  - 属性で定義された型をもつ≒列
- 組
  - 見出しに対応した属性値の集合≒行
- 本体
リレーションのイメージ (図解) →スライドをみられたい！
リレーションは二次元ではない
- n 個の属性をもつリレーションは n 次元空間にプロットされた点の集合
  - タプル＝点
- 2 次元にみえるのは縦横の軸がある表として存在だから
  - 紙に描かれた絵は 2 次元になる
用語の対応対応する概念だが、性質は異なる
- リレーショナルモデル : SQL
- リレーション : テーブル
- 属性 : 列
- 組 : 行
演算の単位はリレーションになる
リレーションの演算
- 演算の入力も出力もリレーション
  - 同じ性質のものが返る→クロージャ、という
  - 演算結果に対して、新たに演算を行うことができるという恩恵がある
  - それがリレーショナルモデルの真骨頂！
- 演算の種類
  - 制限 (RESTRICT)
    - 組の制限 (フィルタリング)
  - 射影 (PROJECT)
    - 属性のフィルタリング
    - 属性を減らすと値が重複することがある
      - 射影によって組も減ることがある
  - 拡張 (EXTEND)
  - 和 (UNION)
    - 複数のリレーションを対象とした演算
  - 積 (INTERSECT)
  - 差 (DIFFERENCE)
  - 直積 (PRODUCT)
  - 結合 (JOIN)
    - ザ・リレーショナルモデル、といった典型的演算
豆知識
- 直積と積はいずれも結合の特殊ケース
  - 直積：共通する属性がひとつもない
  - 積：すべての属性がまったく同じ
- リレーショナルモデルにおける Join は Innner Join だけ
リレーションの演算はわかったけど SQL とどう関係あるの？
- SELECT の基本形、実態は 3 つのリレーションの演算なのだ！
  - SELECT (射影)
  - FROM (直積)
  - WHERE (制限)
リレーショナルモデルを無視するとどうなってしまうのか？
- DB 設計がぐだぐだになる
  - セオリーを無視しているから
  - もちろんクエリもグダグダになる
- DB 設計がよくないと？
  - クエリをすっきり表現できない
  - スーパーテクニックが必要になってきてしまう
    - 他人がよめない
    - あとで自分もよめない
  - ストアドプロシージャが颯爽と登場！
    - スーパーテクニックを手続き型で書きなおしただけにすぎない
    - さらなる状況の悪化が起こりうる
Ruby で配列を操作するときの例
正しいやり方と、間違ったやり方を紹介
- 正しい時はスッキリと対象にアクセスできるが、間違ったやり方をしていると大変になる
- コードはムダに長くなるし、何をしてるかひと目でわからない
間違った設計は技術的負債を積み増すことになる！
クエリをスッキリ表現するには？
- 正しいデータ構造を用いる
  - データに矛盾がないこと
    - 集合と論理演算は一対一で対応する
    - 論理学に基づいていると知ろう
      - 述語論理
        
        命題
        
        述語
        
        命題関数
        
        閉世界仮説
        
        リレーションは事実の集合
        
        事実＝真となる命題
        
        リレーションには述語がある
        
        リレーションに含まれる組の属性値を代入→真
        
        それ以外の属性値を代入→すべて偽
        
        リレーションを組み合わせた結果得られる結果はすべて真
    - 集合演算＝論理演算に基づく表現
宣言型 vs 手続き型
- SQL は宣言型を使うべき
- 宣言型＝ WHAT
  - 論理演算で表現されたもの
    - クエリによってほしい解 (集合) に対する述語はなにか？
- 手続き型＝ HOW
  - 難解なテクニックを駆使した SELECT
  - ストアドプロシージャ
なんで手続き型になってしまうのか？
- DB 設計が間違ってるから
- 集合として表現されていないから
  - 欲しい解が論理演算で得られない
- 宣言型で表現できない時は、 DB 設計を見直す契機になる
正しい DB 設計
- 集合＝リレーションとして表現されたテーブル
  - NULL ない
  - 重複ない
  - 要素間に順序ない
  - 属性の値はドメイン要素のひとつ
  - そうすると第一正規形になっている
- リレーションになってるからリレーションの演算が適用可能
  - リレーションでないものにリレーションの演算は適用できない
正規化理論
- リレーションから重複を排除するための DB 設計理論
  - 重複は矛盾の原因になる
    - 重複＝同じ事実を複数回述べているということになる
    - 部分的に変更すると異なる事実を述べることになる
      - それすなわち矛盾
  - 矛盾が含まれていると論理演算によって正しい答えが導き出せない
    - 矛盾は論理の天敵
矛盾の例
- また刃牙！スライドみるべし
- データをみただけではどちらが正しいか判断できない、それが
正規形（今回は割愛されていた）
- 1NF から 6NF まで
- 1NF がスタート地点
  - テーブルがリレーションになっていること
- 2NF - BCNF 自明でない関数従属性を排除
- ４NF - 6NF
直交性
- 正規化は個々のリレーションの内部の重複をテーマ
- リレーション同士の重複に焦点をあてたのが直交性
  - 複数のリレーションにおいて同じ事実を述べていると矛盾の原因になる
リレーショナルモデルも万能のツールではない
- 集合の枠にあてはまらないものは表現できない
  - グラフ
    - ノードとエッジをつないだ構造を持つモデル
      - 単純グラフ
      - 非連結グラフ
      - 完全グラフ
      - 重み付きグラフ
    - データを格納するだけなら問題なく出来てしまう
      - グラフ＝ノード＋エッジの集合
      - 問題はクエリ
        
        グラフ特有の問題を SELECT で表現できない
        
        グラフ特有の問題をとくためには
        
        論理演算ではないアルゴリズムが必要になる
        
        ループと条件分岐
        
        解決策
        
        リレーショナルモデルでは解決できない
        
        ストアドプロシージャ
        
        グラフ DB
  - ツリー
  - 行列
  - 履歴
  - 全文検索
  - 正規表現
  - Sort
リレーショナルモデルの外の世界
- 現実世界のアプリケーション
  - リレーショナルモデルに適合するデータとそうでないものがある
  - リレーショナルモデルには定石がある
  - リレーショナルモデル以外の領域には決定的なやり方はない
    - 創意工夫が必要
- 外側の世界ではリレーショナルモデルは無理に適用するべきでない
- そこで SQL です
  - SQL　はリレーショナルモデル以外の分野も扱える
    - リレーショナルモデル≒SQL
      - 完全に同じではないから外側の世界も扱うことは可能
  - SQL ならできることがある
NoSQL を扱う上での注意点
- リレーショナルモデルは NoSQL にとっては外の世界
  - 論理的なデータの整合性を担保するのには苦労する
  - 壮大な車輪の再発明をすることになる
    - 正規化
    - トランザクション
インデックスとはなんなのか？
- インデックスはリレーショナルモデルの一部ではありません
  - データへの物理的なアクセス手段
- 論理＞物理
  - まず論理設計を優先することによって物理的なアクセス手段を考えることができる
- クエリが決まってからそれを実現するためのアクセス手段を考えよう
トランザクション
- データの整合性を保つための必須機能
- リレーショナルモデルとは全く異なる理論
- だが、それぞれ補完関係にある
- トランザクションを実現するものは2つ
  - 排他処理
  - クラッシュリカバリ
- ACID
  - 一貫性を保つためにリレーショナルモデル
複雑さに立ち向かうには！？
- アプリケーションの規模が大きくなると
  - スキーマの複雑化は避けられない
- データの整合性については見落としがち
  - 正規化
  - 直交性
- スキーマレスにしてもデータの複雑さから解放されるわけではない
  - むしろ問題のほうが大きい
    - スキーマの整合性を担保できない
    - データの整合性も担保できないから
まとめ
- リレーショナルモデルを実践しよう
  - クエリがすっきり
  - メンテナンス性向上
- テーブルはきっちり正規化しよう
  - データの保全
  - 複雑さ
- リレーショナルモデルの限界を知ろう
宣伝！
- リレーショナルデータベース実践入門
- 発売は来春予定！！！！！
QA は twitter で！