Not only NoSQL

JIT

NoSQL

SQL RDB

TODAY

purpose

• SQL is not RDB

• SQL is not well defined

• RDB can be better than SQL

(potential)

• RDB is truly mathematics

(SQL product)

Talk about SQL

• 制定された年ごとに SQL86, SQL89, SQL92, SQL1999, SQL2003, SQL2008 などの規格がある。

• SQL は、 RDBMS （ SQLMS ）において、データの操作や定義を行うための問い合わせ言語である

• 主な製品として、 Oracle 、 DB2 、 MySQL など。

by wikipedia

Talk about NoSQL

• NoSQL とは、 SQL の長い歴史を打破するものとして、広い意味での非 SQL な理論、製品、プログラムの総称である。

• 主な製品として、 CouchDB 、 HBase 、Memcachedb 、 MongoDB など

by wikipedia

Happy?

tuning

• 「 WEB 応答が遅い」• 「バッチ処理が遅い」

　　⇒　 NoSQL?

• 実装に惑わされるな、理論に従え

NoSQL 　＆　 REST

• アーキテクチャ指向（ scale out ）• ソフトウエア（ cash, kvs, bigtable ）• ステートレス（冪等、独立）• bigdata(Object)• 複雑性（ XML 、 JSON 、 YAML ）

確かに素晴らしい。これがなくては現在の世の中は成り立たない。しかし本当に RDB と直交する概念か！？

mathematics

theory

architecture

programming

ideal

もっと光を！

ヨハン・ヴォルフガング・フォン・ゲーテ詩劇『ファウスト』

& リレーショナル理論

SQL ｖｓ　 RDB

• SQL はリレーショナル理論の部分実装• SQL はリレーショナル理論の直交拡張　　こうではない。　　　 Class SQL extends RDB{

}

• SQL は混乱する。 ( 私だけ？ )

fantasy

• SQL は第一正規形• SQL は NOT 　 NULL 制約を持つ• SQL はトリガー（型強制）を持つ• SQL は関数型言語• SQL は数学に基礎を置く• SQL は ACID 、トランザクションを持つ• SQL は統計情報から最適化される

atom

• atom は非分解、つまり原子

• SQL で認められている atom は string,integer,boolean,decimal,date など

• SQL では論外

ID Name Hobby

1001 Jhon tennis piano 　

1002 May book movie poem

1003 Bob girl boy 　

Is atom undividable?

helium

Check your atom

• 文字列型「少年易老學難成」 ⇒ 「少」、「年」、、、、

• 日付型「 2011/11/28 」 ⇒年 2011 、月 11 、日 28

• 真理値型「イルカは魚または動物」⇒命題として分解

• 数値型「 100 」⇒素因数分解 (2^2×5^2)

context

• 原子性は context に依存する• 時間、人、物、空間、によって妥当な原

子性の深さが異なる。

• SQL は様々な context を無視し、ある、独断で原子性を定義

　（そんな乱暴な第一正規形に従うな！）

complexity

• 複雑さの復権　 bigtable 、 Object 、 XML 、 JSON だけ

が複雑性の拠り所ではない。

• リレーショナル理論こそ、複雑性の代名詞といえる。（ e.g 　表現力）

Who?

Edgar Frank Codd 1923 ・ 8 ・ 23 - 2003 ・ 4 ・18

Mathematician

In Set theory

Set theory

Set theory

• 集合は任意の対象（要素）の集まり• 集合は任意の型を包含可• 集合は集合を包含可• 集合は要素の重複を許さない• 集合は要素数が 0 を認める• 集合は対象が未定（ NULL) を許さない• 集合には集合命題がある　　⊂、∈など• 集合には集合演算がある　　∪、∩など

dimension

• SQL のテーブルは、 2 次元（項、列）• 集合の次元は多次元に拡張可能　自然数　 N={1,2,3,4,5,……}　整数　　　 Z= -N {0} N∪ ∪ 有理数　 Q= Z × Z デカルト座標　 D= Q× Q　※実際には実数　※ Q×Q を Q^2 と書く

relation

• 関係の項とは、組み合わせの一つの要素• 関係とは、集合の内積に他ならない

（ 1001,Jhon,tennis ）∈ ID×NAME×HOBBY

ID Name Hobby1001 J hon tennis1002 May book1003 Bob girl

Cartesian coordinate system ID

Name

Hobby

1001

J hon

tennis

1001,J hon,tennis（ ）

N 次元の座標系の一点として定義※ 重複を許さな

い根拠

（ 1001,Null,tennis ）が何処をポイントする

かわからない！Null を許容しない根拠

depth

• 集合は集合間の包含において、任意の深さを取れる。

A: 集合A B∈ ：集合　　つまり {A, A’, A’’,….}

B C∈ ：集合・・・・・・

Again, complexity

• Hobby Hobbies∈

※ Hobbies ≠ Hobby ^3

・ Object・ XML・ JSON・ Bigdata

に表現力は遜色ない。※ すごい似てる！

ID Name Hobbies

1001 J hon

1002 May

1003 Bob

Hobbytennispiano

Hobbybookmoviepoem

Hobbygirlboy

Select

ID,

Name

From Person

WHERE

‘tennis’ Hobbies.Hobby∈

Person

ID Name Hobbies

1001 J hon

1002 May

1003 Bob

Hobbytennispiano

Hobbybookmoviepoem

Hobbygirlboy

Sample

※SQL で無理やり書くとこんな感じかな、、、、

logic

• Null が怖い• Null は嫌い

⇒ 　正解です。

NULL

• Null を扱った命題では、結果として True 、 False のいずれかが返される保証がない。

例）Where

　 NULL ＞ 100AND NULL = NULL

この Where 句は真に評価される？偽に評価される？

⇒UNKNOWN

three valued logic

• SQL は UNKNOWN 、 TRUE 、 FALSE の 3 値論理。

• リレーショナル理論（集合論など古典数学）では2 値論理

• 3 値論理は非常に危険！既存の数学的な論拠が使えない。

　　例）背理法が使えない。俳中律の崩壊。⇒ 数学を基盤にしているとはとても言えない、、、• 現世界のコンピュータは 2 値論理で稼動している。

（ 2 値に抑えればクエリ高速化に繋がる可能性）

Type

Type(SQL)

• 型の有益は、言及するまでもない。• SQL に型は備わっているか？　 YES ：しかしユーザ定義型が弱い　（トリガーでごまかされている気がす

る。）• 強力な型が欲しい！• リレーショナル理論では型の表現が自由

literal

• リテラルとはコンストラクタである。例）文字列型：「 hello world 」• 複雑な型表現は？　例）デカルト座標　　　　　　　

θ

Y

X

ｒ

コンストラクタのオーバーロードが欲し

い。極座標

Type （ relational ）• コンストラクタの候補表現（オーバー

ロード）• 強力な型制約をつけられる。　 Constraint R15 {

age <= 15 ： Exception

　 } on Person.AgeID Name Age1001 J hon 101002 May 221003 Bob 37

Age には年齢制限があるため、このタプルを含む集合を Person に代入しようとした時点で例外発生

Constraint

• 関係にも制約をつけれる。　 Constraint R25 {

age <= 25 　 AND 　 ID%2==0 ： Exception

} on Person

Domain

• 二つのリレーションが合った場合、両方に共通した Domain が現れることがある。

• これらのドメイン（ ID) を、同じ型で表現する。

• 豊かな型表現により、プリミティブでない項目表現が可能

ID LessonID Lesson1001 A gym1001 B music1003 B music

ID Name1001 J hon1002 May1003 Bob

semantics

optimization

• SQL ：統計情報による。（コストベース）

• 等価 SQL ： SQLA SQLB⇒• 簡単な（コストの低い） SQL に変換し結果を出す。

• 関係（ relational ）では、型制約、関係制約を持っていることから、意味論（ semantics ）的な最適化が出来る。

Semantics optimization

ID Name Hobbies

1001 J hon

1002 May

1003 Bob

Hobbytennispiano

Hobbybookmoviepoem

Hobbygirlboy

• もし、 R15 指定があったとしたら、、、

• 「 movie を趣味に持つ人を取得」にクエリ変換できる。

• これが意味論的最適化⇒ 　高速化の期待！

•「 movie を趣味に持つ 16歳以上の人を取得」

finally

• SQL は、リレーショナル理論の完全な実装ではなかった。

• SQL ベンダーは高速化に挑んでいるが、数学的根拠なきベースからは厳しい戦いになっているようだ。

• 理論、とっても大切！つねに頭に数学を！