CMU 15-445/645 (FALL 2018)Database Systems - 01 Relational Data Modelノート
TLの詳しい方が勧めていたのでちょっと見てみました。
DB はこの講義を受講すればかなり詳しくなれるよ✋(´・ω・`) https://t.co/1cI6nxWZ9a
— なゆたいむ (@nayutime) 2019年5月19日
スケジュールを見るとかなり本格的でLogging,Concurrency Control,MVCC,はたまた分散OLTP/OLAPと続き、Course informationの所に
The course is appropriate for students with strong systems programming skills.
とあるのでついていけるか不明だが、とりあえず取り組んでみようと思います。 最終的には制作課題?的な感じでC++11でstrage managerを作るらしい。
- 動機
- ちょっとだけ入門したC++を活かす機会
- 英語のリスニングの良い機会
- DBの基礎力向上
- CC本読書会がなくなった事による穴埋め
Concurrency Control and Recovery in Database Systems
- 作者: Philip A. Bernstein,Vassos Hadzilacos,Nathan Goodman
- 出版社/メーカー: Addison-Wesley
- 発売日: 1987/02/01
- メディア: ハードカバー
- この商品を含むブログを見る
- papa本はDBの基礎というには特殊な知識に偏りすぎている気がする*1
Theory of Database Concurrency Control
- 作者: Christos Papadimitriou
- 出版社/メーカー: Computer Science Pr
- 発売日: 1986/07/01
- メディア: ハードカバー
- この商品を含むブログを見る
などをモチベーションに、お昼ご飯とか洗い物とか手が塞がってる時など隙間時間にちょくちょく進めてみます。
早速第一回を見た。第一回はRDBMSの歴史、リレーションとは何か、という話とリレーショナル代数の説明で終わった。
relational model
- E.COD提唱
A Relational Model of Data for Large Shared Data Banks
tuple
- 粒度的には行に相当
- set of attribute
relation
- 粒度的には表に相当(この例えはたまに怒られますが、分かりやすく 例えると。)
- ただしunordered set
- 厳密な意味を知りたければcoddの論文を読む必要がある
- 1個以上のtupeの集合(つまりテーブル)のn項関係関係(つまりjoin)を意図しているように見える。(joinしていないテーブルも含んでいると思われる)
The term relation is used here in its accepted mathematical sense. Given sets S1 , S2, , . . . , Sn, (not necessarily distinct), R is a relation on these n sets if it is a set of n-tuples each of which has its first element from S1, its second element from S2 , and so on.(1.3. A RELATIONAL VIEW OF DATA より抜粋)
attribute
- 列に相当するもの
- 通常atomic/scalarな値をとる
- json型やArray型の登場により、現代のDBではこの制限はゆるくなりつつある。
この論文はRDBMSの源流を探る意味で読む価値はありそうだが、今回ここは掘り下げない。
リレーショナル代数
Syntax | 意味 | SQL |
---|---|---|
σ | Select | WHERE句 |
Π | Projection | SELECT句 |
∪ | Union | UNION演算子 |
∩ | Intersection | INTERSECTION演算子 |
- | Difference | EXCEPTまたはMINUS演算子 |
× | Product | CROSS JOIN |
⋈ | Join | Natural JOIN(オリジナルはこれらしい) |
Select(σ)
- Relationからtupleを述語を使って選択する。Where句に相当
- Syntax:σ predicate(R)
Projection(Π )
- 特定のattributesを使ったrelationを作成する。
- attributesの順の並び替えも可能
- 値の操作も可能。(select a-100 from t_table的な)
- SQLではSelect句に相当。
- Syntax:ΠA1,A2,…,An(R)
Union(∪)
- binary operator.(2つのテーブルをinputにとる演算子)
- どちらかのrelationまたは両方のrelationに出現するentityを表示
- Syntax:(R ∪ S)
Intersection(∩)
- binary operator
- 2つのinputのrelation双方に共通するtupleから成るrelationを生成する
- Syntax:(R ∩ S)
Difference(-)
- binary operator
- 最初のinputのrelationに存在し、かつ2つめのinputに存在しないtupleから成るrelationを作成する
- Syntax:(R - S)
Product(×)
- 2つのrelationの組み合わせから成るrelationを作成する
- Syntax:(R × S)
- 一見使えなさそうに見えるが何に役立つだろうか?という設問が投げられた
- 全組み合わせを試したいテストの時に役立つだろうという話になった。
Join(⋈)
- Syntax:(R ⋈ S)
- 最初にnatural joinを定義したらしい
- equal join, straight joinという呼び名もある
- 2つのrelationの1組み以上の共通のattributeで同じ値をもつtupleの組み合わせから成るrelationを作成する
- 要約すると、同じカラム名の列に関して同じ値を持っているtuple同士を結合させる
- 授業では以下の例で説明された
R
a_id | b_id |
---|---|
a1 | 101 |
a2 | 102 |
a3 | 103 |
S
a_id | b_id |
---|---|
a3 | 103 |
a4 | 104 |
a5 | 105 |
(R ⋈ S)
a_id | b_id |
---|---|
a3 | 103 |
- intersectionも同じテーブルの例を使っており、結果が全く同じになってしまっていた(授業で使う例としては分かりにくい)
- 違いは何か?という質問が学生から挙げられた
- intersectionでは全てのattributeの順、値が一致するtupleのみから成るrelationを作成する
- natural joinでは共通する名前のattributeが一致すれば良い。
- 違いは何か?という質問が学生から挙げられた
Extra Operator
originalのrelational operatorで表現できなかったものが後年に追加された
- 対応しているSQLは以下のスライドなどを参考に書き足している。
https://courses.cs.washington.edu/courses/cse444/10sp/lectures/lecture16.pdf
name | operator | SQL |
---|---|---|
Rename | ρ | ASに相当。DDL(ALTER)ではない |
Assignment | R←S | INSERT |
Duplicate Elimination | δ | distinct。UNIONなどにつけるALLではない |
Aggregation | γ | Group by |
Sorting | τ | Order by |
Division | R÷S | 構文としてはない |
自分の知っている範囲では関係除算(Division)は構文としてはないのでSQL上で結合とかEXISTSとかを駆使して表現する。
感想
relation
RDBMSの文脈でRelationという言葉がよく出てくるが、正直今日までよく意味がわからなかった。
- 実装(実際のRDBMSやSQL)⇨モデル(relationa model)の順番で勉強しているのがそもそも誤解を招いている原因だと思いますが。
- テーブルのこと、や結合のこと、写像のことなど、出現する時々に様々なコンテキストを持って出てくるのでますます混乱する。
とりあえず今回はCoddのオリジナルの定義に当たれたのと、今回のビデオコースでの文脈である程度意味を絞り込りこむことができた。
関係代数はrelationを操作するためのもの。relationから値を取り出したり、新たにrelationを作るのに使う。
- この時のrelationという意味に限定して使うのがより厳密。
- SQLでは
<Query Expression>
がもっとも近いと思う*2