ラベル RDB の投稿を表示しています。 すべての投稿を表示
ラベル RDB の投稿を表示しています。 すべての投稿を表示

2009年8月9日日曜日

【DbiD】9 論理を少々

Relational Calculusを本書ではリレーショナル計算と訳しています。
Webを調べると、関係論理という訳語がより一般的なようです。

さて、関係代数は、集合論の演算子を主体に組み立てられていました。

関係論理では述語論理の語彙と意味を主体に組み立てられています。

集合論自体がその演算子の定義に内包表記と論理表現を使っていますので、まあ、これも可能と思います。

関係代数と関係論理は理論として等価となるように設計されているようです。
これは関係完備(relational complete)という用語の定義そのもので、関係論理は関係完備である、ということです。

さて、関係論理は述語論理ですが、一階述語論理そのものではありません。
例えば、限量子としてUNIQUEがあります。
また、部分集合を簡易に利用するためのRANGE OVERという語彙があります。
記述力として一階述語論理以下の理論と思いますが、形式的理論としては別物です。
(論理的語彙は一階述語論理以外のものもあるが、一階述語論理にて記述可能ということ)

関係代数との比較でいうと、タプルは登場しません。データは、述語、定項と変項で表現されます。
その点、Prologに、より近いのかもしれません。

これにて、読了、です。


さて、ぐだぐだな感じでの読了は初めてなのですが、いくつかアドバイスを。

  • C.J.Dateのリレーショナルモデルを学ぶなら、この本は適していません。完全な記述ではありませんし、エクスカリバー的なノイズに溢れています。
  • リレーショナルモデルを学ぶなら、C.J.Dateのものだけでなく、他のものも学ぶべきであろうことを感じました。
  • リレーショナルモデル自体は、おもしろいものですし、有用なものと思います。
  • もし、この本を読む場合は、訳書より原書がいいと思います。


こつこつ。

【DBiD】8 リレーショナルモデルとは何か

いままでの内容のまとめです。
新規のことはほとんどありません。

リレーショナルモデルの厳密な定義を示すということですが、
あまり厳密ではありません。

リレーショナルモデルのコンセプトや動機をまとめる、
といった方が適切でしょう。

訳書と肌が合わないので、原書を読みました。

こつこつ。

2009年8月7日金曜日

【DBiD】7 データベース設計理論 (その5)


** 7.4 正規化を支持する2つの理由
- 正規化の目標と達成
- うまく表現する。直感的に理解しやすく、将来の
変更に耐える。
- 達成していると考えられている。
- 冗長性を削減する。
- 正規化はよい出発点ではあるが、課題はある。
- 正規化だけですべての冗長性を回避できるわ
けではなく、設計にはヒューリスティックな
部分がる。
- 冗長性の削減と従属性の維持は競合すること
がある。
- 従属性の維持の目標
- FDを制約の表現として重視して、FDが維
持されるような分解に限る立場。正規化
はFDやJDを分解して消失せしめ、多重関
係制約に移行するものであるから、そも
そも対立している。
- 冗長性の削減によって、更新不整合を回避する。
- 前項と同じである。
- 整合性制約の記述と適用が簡潔となるようにする。
- 5NFにもっていくことによって、少なからぬ制約
がキーの一意性に帰着され、別途制約を書く必
要が無くなる。ゆえに効果的と言える。
- 正規化の位置付け
- よい評価
- 上記の目標をある程度達成している。
- まず正規化することを目指すべきである。その
上で、それでできないことに対処すべきである。
- 注意点
- JD以外の制約は表現できない。
** 7.5 直交性
- 直交性の原理 (訳書は誤訳なので私家版)

AとBが同じデータベースの異なる関係変数であるとす
る。AとBからそれぞれA1,...,AmおよびB1,...,Bnへの
無損失分解が存在するとする。このとき、AiとBjに同
じタプルが存在してはならない。

- 直交性の位置付け
- 正規化は、ひとつの関係変数に着目して、その中
の冗長性を削減する。直交性は、複数の関係変数
に跨る冗長性を削減することによって、正規化を
補完する。
- 直交性は、正規化ではケアできない冗長性のケア
をすることがある。例えば、次の3つの関係変数が
あるとする。

関係変数: S
関係:
| SNO | SNAME | STATUS | CITY |
|-----+-------+--------+--------|
| S1 | Smith | 20 | London |
| S2 | Jones | 10 | Paris |
| S3 | Blake | 30 | Paris |
候補キー:{SNO}

関係変数: SX
関係:
| SNO | SNAME | STATUS |
|-----+-------+--------|
| S1 | Smith | 20 |
| S2 | Jones | 10 |
| S3 | Blake | 30 |
候補キー:{SNO}

関係変数: SY
関係:
| SNO | SNAME | CITY |
|-----+-------+--------|
| S1 | Smith | London |
| S2 | Jones | Paris |
| S3 | Blake | Paris |
候補キー:{SNO}

ここで、SからSX,SYへの分解は、

- SX,SYは5NFであり、
- 無損失分解であり、
- 従属性を維持しており、
- Sの復元にはSX,SYの双方が必要である。

すなわち、正規化の観点から言えば、文句のつけ
ようがない分解である。しかるに、SNO,SNAMEに
は冗長性がある。これを禁止するのが直交性の原
理である。
** 7.6 物理設計の注意点
- リレーショナルモデルは物理モデルについては言及
しない。
- 物理設計は論理設計に従うべきである。現状、逆に
なっていることが散見される。
- 次のような概念のマッピングを盲目的に使わないほ
うがよい。

| リレーショナルモデル | 物理ファイル |
|----------------------+--------------|
| 基底関係変数 | 物理ファイル |
| 属性 | フィールド |
| タプル | レコード |

このマッピングは物理モデルの一例である。
- また、この物理モデルはあまり良くない。特に、デー
タ独立性をほとんど実現していない点。
- DateとしてはTransRelational Modelを推している。
** 7.7 まとめ
- データベース設計における理論的な部分は、正規化
と直交性である。
- 論理的な設計プロセスは次のとおり。
- 関係変数述語を定義する。
- 前項から関係変数と制約を立案する。制約は、
FD、MVDまたはJDとなる。
- データベースはアプリケーションから独立すべきで
ある。
- データベースはそれ自体が現実の状況と意味をあ
らわすものである。そのことをしっかり作り込む
べきである。
- アプリケーションは、将来必要となる未知のもの
を含めて、そこから情報と意味を得て、自身の文
脈で解釈をして処理をする。それはいろいろあり
得るので、そこにデータベースを依存させるべき
ではない。
- 正規化と直交性を実施することは、リレーショナルモ
デルにおいて、必須ではない。すなわち、正規化が
完全になされていない、または直交性を維持してい
ない関係変数もリレーショナルモデルの範疇である。


やっと7章を完了。
本体で1章、付録で1章。トータルあと2章!

こつこつ。

2009年8月6日木曜日

【DBiD】7 データベース設計理論 (その4)


** 7.3 結合従属性と第五正規形
- 第五正規形は結合従属性(JD)と呼ばれるものの総正
規形である。
- 結合従属性の定義
原文ままではなく、私家版。

A1,...,Anを関係変数Rの見出しの部分集合達であるとす
れば、Rの妥当な値であるすべての関係が、Aiを使った
その値の射影達の結合(A1,...,Anの全部を結合)に等し
い場合、そしてその場合に限り、RはA1,...,Anとの間に
結合従属性を満たすという。A1,...,Anとの結合従属性
を☆ { A1,...,An }と表記する。

- FDとJDの関係
- JDの定義は無損失分解に関する言明でもある。無損
失分解の観点で言うと、関係変数RがJD ☆{A,B,C}
をみたすということは、関係変数Rを、
- Aを見出しとする関係変数
- Bを見出しとする関係変数
- Cを見出しとする関係変数
に無損失分解可能であるということである。
- 関係変数Rが特定のFDを満たすということは、特定
の射影に無損失分解できるという定義であったか
ら、すべてのFDはJDでもある。

- 上位キーとJD (暗示)
- まず、上位キーを領域(入力)とするFDは常に存在
するものであった。
- すると、すべてのFDはJDでもあるわけだから、上
位キーを射影達(部分集合達)に含むJDも常に存在
することになる。
- 特に{A1,...,An}におけるすべてのAiが上位キーな
らば、☆{A1,...,An}である。このとき☆
{A1,...,An}は、上位キーによって暗示されるとい
う。(暗示はたぶん含意のことだな)
- 自明なJD
- { A1,...,An }のうちのいずれかのAiが見出しその
ものである場合、☆{ A1,...,An }である。これを
自明なJDと呼ぶ。
- 語彙の整理ができたところで、5NFの定義。(私家版)

関係変数Rは、Rによって満たされるJDのすべてがRのも
つ上位キーによって暗示される場合に、そしてその場合
に限り、5NFである。

- これはおもしろい。というのは、先に、1NF-5NFを予
習したときには、1NF-3NF,BCNFのグループと4NF,5NF
のグループは違う話題であり、後者は関連を表わす
テーブルに関するものだ、ということであった。
しかし、ここでのDateのような5NFの定義の仕方をす
れば、それは前者のグループも含んだ表現になって
いるということだ。

- BCNFと5NFに関する定理 (原文まま引用)

RがBCNFの関係変数であり、複合キー(複数の属性か
らなるキー)を持たないとすれば、Rは5NFである。

- 5NFは、理論的には、非常に重要である。結合従属性
に関する完全な正規形は5NF以外ないからだ。実用的
には、BCNFになった時点で5NFになっているのがほと
んどなので、あまり価値は無い。

- なお、5NFは別名として射影/結合正規形(PJNF)と呼
ばれることもある。

- Dateは6NFを提唱している。ここでは割愛しとく。


次回は7.4 正規化を支持する2つの理由。
だんだんおもしろくなってきた。

こつこつ。

2009年8月5日水曜日

【DBiD】7 データベース設計理論 (その3)


** 7.2 関数従属性とボイスコッド正規化
- 2NF,3NF,BCNFは関数従属性(FD)の概念に基づいている。
- FDの定義。(原文まま引用)

A,Bを関係変数Rの見出しの部分集合であるとすれば、Rの
妥当な値であるすべての関係において、Aに同じ値を持
つ2つのタプルがBにも同じ値を持つ場合に限り、関係変
数Rは関数従属性A -> Bを満たす。
- Aがキー(見出しの部分集合)のとき、A'⊃Aとなる
A'(見出しの部分集合)を上位キーと呼ぶ。
- A'⊇AかつB⊇B'ならばA' -> B'も自動的に成り立つ。
- ここでAがキーならばA'は上位キーであり、キーと非
キーの関係とから、上位キーから任意の部分集合(of
見出し)へのFDが成立することがわかる。
- 見出し⊇A⊇BのときA->Bは常にFDである。これは必
ず成り立つので、自明なFDと呼ぶ。
- BCNFの定義 (原文の定義は曖昧なので私家版)

関係変数Rは、Rによって満たされるすべての非自明FD A
-> B において、AとなるのがRの上位キーのみである場合
に、そしてその場合のみに、BCNFである。

- BCNFでないものをBCNFにする(これをBCNF化と呼ぶ)、
ということは、なんらかのFDを排除する、ということ
である。FDを排除する、ということがどういうことか
という、BCNFにする過程で、ある関係がそれよりも属
性数の少い関係達に分解されることにより、FDが関係
達から消失し、そのかわりに、多重関係変数制約が発
生するということである。

- BCNF化する際には関係変数の分解が発生する。
- 分解処理の実体は、射影にすぎない。
- BCNF化の分解にあたっては、分解後の関係変数達を
結合すると、分解前の関係変数に戻るようにする。
このような分解の仕方を無損失な分解と呼ぶ。

- 1NF,2NF,3NFはBCNFに包含されている。またBCNFはFD
について包括的である。よって1NF,2NF,3NFは歴史的
なものと考えてよく、理論的にも実践的にもBCNFを
考えればよい。
- RVAを含めれば、あらゆる関係は少なくとも1NFであ
り、非正規形テーブルなどは存在しない。
- RVAを避けた方が賢明なのはベース関係についての教
訓であり、仮想関係や結果として返る関係については、
どんどん使えばよい。


こつこつ。

2009年8月4日火曜日

【DBiD】7 データベース設計理論 (その2)


*** 各種正規化の基本情報

- 正規形の種類
- 非正規形
- 第1正規形 (1NF)
- 第2正規形 (2NF)
- 第3正規形 (3NF)
- ボイスコッド正規形 (BCNF)
- 第4正規形 (4NF)
- 第5正規形 (5NF/PJNF)

- 非正規形の例

注文テーブル
| 注文番号 | 注文日時 | 商品ID | 商品名 | 単価 | 数量 | 金額 | 合計金額 | 消費税 | 顧客ID | 名前 | 電話番号 | 支払い方法 |
|----------+----------+--------+------------+--------------+-------+--------------+----------+--------+--------+----------+--------------+------------|
| 101 | 2009-8-1 | 1 3 5 | 砂糖 塩 米 | 500 500 1000 | 1 1 1 | 500 500 1000 | 2000 | 100 | P02 | 山田花子 | 03-4567-8901 | クレジット |
| 102 | 2009-8-1 | 6 | 味噌 | 700 | 1 | 700 | 700 | 35 | P05 | 田中太郎 | 012-345-6789 | 代引 |
| 103 | 2009-8-2 | 6 5 | 味噌 米 | 700 1000 | 1 2 | 700 2000 | 2700 | 135 | P10 | 鈴木一浪 | 04-5678-9012 | クレジット |


- これが第一正規形でない理由
- 商品IDや商品名などについて、単一のフィールド
に複数の値が入っている。これを繰返しグループ
と呼ぶ。繰返しグループがあると非正規形である
と見做す。

- 第一正規形を作る手順
- 1. テーブルにキーを設定する。
- 2. テーブルの繰返しグループを別のテーブルに分
離する。
- 3. 導出項目を削除する。

- 第一正規形の例

注文テーブル
| 注文番号 | 注文日時 | 顧客ID | 名前 | 電話番号 | 支払い方法 |
|----------+----------+--------+----------+--------------+------------|
| 101 | 2009-8-1 | P02 | 山田花子 | 03-4567-8901 | クレジット |
| 102 | 2009-8-1 | P05 | 田中太郎 | 012-345-6789 | 代引 |
| 103 | 2009-8-2 | P10 | 鈴木一浪 | 04-5678-9012 | クレジット |
キー : 注文番号

注文明細テーブル
| 注文番号 | 商品ID | 商品名 | 単価 | 数量 |
|----------+--------+--------+------+------|
| 101 | 1 | 砂糖 | 500 | 1 |
| 101 | 3 | 塩 | 500 | 1 |
| 101 | 5 | 米 | 1000 | 1 |
| 102 | 6 | 味噌 | 700 | 1 |
| 103 | 6 | 味噌 | 700 | 1 |
| 103 | 5 | 米 | 1000 | 2 |
キー:{注文番号,商品ID}

- これが第二正規形でない理由
- 部分関数従属が存在する。部分関数従属とは、キー
の一部で確定する非キー属性が存在するというこ
と。
- ここでは、キーの一部である商品IDが決まれば商
品名と単価は決まってしまうということ。

- 第二正規形の例

注文テーブル
| 注文番号 | 注文日時 | 顧客ID | 名前 | 電話番号 | 支払い方法 |
|----------+----------+--------+----------+--------------+------------|
| 101 | 2009-8-1 | P02 | 山田花子 | 03-4567-8901 | クレジット |
| 102 | 2009-8-1 | P05 | 田中太郎 | 012-345-6789 | 代引 |
| 103 | 2009-8-2 | P10 | 鈴木一浪 | 04-5678-9012 | クレジット |
キー : 注文番号

注文明細テーブル
| 注文番号 | 商品ID | 数量 |
|----------+--------+------|
| 101 | 1 | 1 |
| 101 | 3 | 1 |
| 101 | 5 | 1 |
| 102 | 6 | 1 |
| 103 | 6 | 1 |
| 103 | 5 | 2 |
キー:{注文番号,商品ID}

商品テーブル
| 商品ID | 商品名 | 単価 |
|--------+--------+------|
| 1 | 砂糖 | 500 |
| 3 | 塩 | 500 |
| 5 | 米 | 1000 |
| 6 | 味噌 | 700 |
キー:{商品ID}

- これが第三正規形でない理由
- 推移関数従属がある。推移関数従属とは非キーど
うしの間に関数従属性があること。
- この例では、注文テーブルについて、顧客IDが決
まれば、名前などは定まる、というところ。

- 第三正規形の例

注文テーブル
| 注文番号 | 注文日時 | 顧客ID | 支払い方法 |
|----------+----------+--------+------------|
| 101 | 2009-8-1 | P02 | クレジット |
| 102 | 2009-8-1 | P05 | 代引 |
| 103 | 2009-8-2 | P10 | クレジット |
キー : 注文番号

顧客テーブル
| 顧客ID | 名前 | 電話番号 |
|--------+----------+--------------|
| P02 | 山田花子 | 03-4567-8901 |
| P05 | 田中太郎 | 012-345-6789 |
| P10 | 鈴木一浪 | 04-5678-9012 |
キー : 顧客ID


注文明細テーブル
| 注文番号 | 商品ID | 数量 |
|----------+--------+------|
| 101 | 1 | 1 |
| 101 | 3 | 1 |
| 101 | 5 | 1 |
| 102 | 6 | 1 |
| 103 | 6 | 1 |
| 103 | 5 | 2 |
キー:{注文番号,商品ID}

商品テーブル
| 商品ID | 商品名 | 単価 |
|--------+--------+------|
| 1 | 砂糖 | 500 |
| 3 | 塩 | 500 |
| 5 | 米 | 1000 |
| 6 | 味噌 | 700 |
キー:{商品ID}

- これがボイスコッド正規形でない理由
- 理由はない。これはボイスコッド正規形でもある。
- 第三正規形のほとんどがボイスコッド正規形でも
ある。

- 第三正規形だがボイスコッド正規形ではない例

注文明細テーブル
| 注文番号 | 商品ID | 数量 | 商品検査担当 |
|----------+--------+------+--------------|
| 101 | 1 | 1 | たろう |
| 101 | 3 | 1 | じろう |
| 101 | 5 | 1 | さぶろう |
| 102 | 6 | 1 | しろう |
| 103 | 6 | 1 | ごろう |
| 103 | 5 | 2 | とめきち |
キー:{注文番号,商品ID}

- 次のビジネスルールとする。
- 一つの注文番号には複数の商品が含まれる。
- 商品検査担当各人は、各自担当する商品IDはひ
とつとする。ひとつの商品IDについて、複数の
商品検査担当がいることはある。
- 一つの注文番号に同じ商品が複数個含まれると
きは、同じ商品IDについては一人の商品検査担
当者が担当する。

- このテーブルがBCNFでない理由。
- 非キー属性からキー属性への関数従属がある。
- すなわち、商品検査担当が決まると、商品IDが
決まる。

- BCNFの例

注文明細テーブル
| 注文番号 | 数量 | 商品検査担当 |
|----------+------+--------------|
| 101 | 1 | たろう |
| 101 | 1 | じろう |
| 101 | 1 | さぶろう |
| 102 | 1 | しろう |
| 103 | 1 | ごろう |
| 103 | 2 | とめきち |
キー:{注文番号,商品ID}

商品検査担当テーブル
| 商品検査担当 | 商品ID |
|--------------+--------|
| たろう | 1 |
| じろう | 3 |
| さぶろう | 5 |
| しろう | 6 |
| ごろう | 6 |
| とめきち | 5 |
キー:{商品検査担当}

- さて、この例が第四正規形でない理由
- これは第四正規形ではない。
- 第四正規形はテーブルの全ての属性がキーである
場合、すなわち、テーブル間の関連を規程するテー
ブルについての話だからだ。第五正規形も同じ。
- この例はそもそもそういうテーブルが無いので、
第四正規形ではない。

- 第四正規形ではない例

チーム-メンバ-道具関連テーブル
| チーム名 | メンバー名 | 道具名 |
|----------+------------+--------------|
| サクラ | 鈴木 | ポンポン |
| サクラ | 田中 | ポンポン |
| モモ | 佐々木 | バトン |
| サクラ | 鈴木 | ユニフォーム |
| モモ | 山本 | ユニフォーム |
| サクラ | 田中 | ユニフォーム |
| モモ | 山本 | バトン |
| モモ | 佐々木 | ユニフォーム |
キー:{チーム名,メンバー名,道具名}

- これは、現実を調べると、チーム名が決まれば、
メンバーがもつべき道具は決まるという状況であ
るとする。

チーム-メンバ-道具関連テーブル
| チーム名 | メンバー名 | 道具名 |
|----------+------------+--------------|
| サクラ | 鈴木 | ポンポン |
| サクラ | 鈴木 | ユニフォーム |
| サクラ | 田中 | ポンポン |
| サクラ | 田中 | ユニフォーム |
| モモ | 佐々木 | バトン |
| モモ | 佐々木 | ユニフォーム |
| モモ | 山本 | バトン |
| モモ | 山本 | ユニフォーム |
キー:{チーム名,メンバー名,道具名}

- そこで次のように分解するのが第四正規化。

チーム-メンバ関連テーブル
| チーム名 | メンバー名 |
|----------+------------|
| サクラ | 鈴木 |
| サクラ | 田中 |
| モモ | 佐々木 |
| モモ | 山本 |
キー:{チーム名,メンバー名}

チーム-道具関連テーブル
| チーム名 | 道具名 |
|----------+--------------|
| サクラ | ポンポン |
| サクラ | ユニフォーム |
| モモ | バトン |
| モモ | ユニフォーム |
キー:{チーム名,道具名}

- さて、第五正規化も関連テーブルについてである。
第四正規化とは別の状況についての正規化である。

チーム-会場-演目関連テーブル
| チーム名 | 会場 | 演目 |
|----------+------+----------------|
| チームA | 東京 | ポンポンダンス |
| チームA | 東京 | ブレイクダンス |
| チームB | 福岡 | チアリーダ |
| チームA | 静岡 | ポンポンダンス |
| チームB | 東京 | ブレイクダンス |
キー:{チーム名,会場,演目}

- この状況だとキーのすべての属性が決まらないとデー
タを投入できない。そこで決まった情報から投入で
きるようにするにはどういう分割をすればいいかと
いうのが第五正規化。答は次のとおり。

チーム-会場関連テーブル
| チーム名 | 会場 |
|----------+------|
| チームA | 東京 |
| チームB | 福岡 |
| チームA | 静岡 |
| チームB | 東京 |
キー:{チーム名,会場}

チーム-演目関連テーブル
| チーム名 | 演目 |
|----------+----------------|
| チームA | ポンポンダンス |
| チームA | ブレイクダンス |
| チームB | チアリーダ |
| チームB | ブレイクダンス |
キー:{チーム名,演目}

会場-演目関連テーブル
| 会場 | 演目 |
|------+----------------|
| 東京 | ポンポンダンス |
| 東京 | ブレイクダンス |
| 福岡 | チアリーダ |
| 静岡 | ポンポンダンス |
| 東京 | ブレイクダンス |
キー:{会場,演目}

- 以上で正規形の羅列はおしまい。

- さて、テーブルをなぜ正規化するかというモチベー
ションは次のとおり。
- データライフサイクルの問題
- 適切に正規化されていないと、データの登録や削
除が煩雑になったり、テーブルのデータが揃わな
いので部分的な情報を登録できなかったりなど
の支障がでる。
- 重複更新
- データ生存期間中であっても、適切に正規化さ
れていないことにより、ひとつの情報について
複数のテーブルや行を更新しなければいけない
ことが発生する。


うーん。これに時間をとられすぎた。
こつこつ。

2009年8月3日月曜日

【DBiD】7 データベース設計理論


* 7 データベース設計理論
- 「論理設計とは、述語をできるだけていねいに定義
し、それらの述語を関係変数や制約にマッピングす
るプロセスにほかならない」
- DateはE/R図もきらいだ。これには同意する。
- 各種正規化の基本については習熟済みと想定する。
説明しない。
** 7.1 設計理論の立場
- 設計理論そのものは、リレーショナルモデルに含ま
れない。
- 人は、データが重複していると不自然に感じる。
- よって、設計理論とは、冗長性をできるだけ排除する
ことにつきる。
- 「データベース設計はきわめて主観的である」


各種正規化の基本を勉強しなおしておいた方がよさそうだ。そこで、

第3回 素早く正規形を見抜く実践テクニック

をやることにする。
とりあえず、ざっと読んでみた。
次回、理解を確かにしたい。

こつこつ。

2009年8月2日日曜日

【DBiD】6 整合性制約

この本のC.J.Dateの語り口、どこかで見たような、何かに似てるようなと感じてた。それがわかった。SOUL EATERの聖剣エクスカリバーだ! すごいんだけど、、、(略)というところが、そっくり。


* 6 整合性制約
本文が散漫に思えるので、自分なりにまとめなおす。

- 整合性制約とは
- ブール式である。
- リレーショナルモデルのそこかしこで、とりうる
値の制限に用いられる。

- 整合性制約の分類
- 型制約
- 特定の型に属する値を定義する。
- 属性制約
- 関係におけるタプルの定義の際に、タプルの属
性の型を指定するが、それはその属性が取りう
る値を定義しているので、制約の一種と見做せ
る。
- データベース制約
- 特定のデータベースに格納できる値の制約。
- 例えば、特定のデータベースのある関係のある
属性の型の制約は[0,10000]であるが、ビジネス
ルールとして、この関係においてはそれが
[1,100]であるべきときなど。
- タプル制約
- データベース制約のうち、単独のタプルを調
べれば制約条件を判定できるものを、便宜上、
タプル制約と呼ぶことがある。
- (単一)関係変数制約
- 関係変数がひとつだけ含まれる制約のこと。
- 多重関係変数制約
- 関係変数が複数含まれる制約のこと。
- 遷移制約
- 関係変数を更新する際に、更新前と更新後の
間で満たさなければいけない制約のこと。
- 参照整合性制約
- 関係変数間で指定された外部キー制約が常に
存在し、成立すること。

- 型制約がチェックされるとき
- 型制約がチェックされるのは、何らかのセレクタが
呼び出されたときである。そのときに型制約とセレ
クタの値が比較されて、制約を満たしていれば処理
が進み、満たしていなければエラーとなる。

- データベース制約がチェックされるとき
- 単一関係変数制約
- 関係変数が更新されるとき。
- 多重関係変数制約
- 一般論
トランザクションの最後でチェックされる。す
なわち、そこまで先送りされる。
- Date論
トランザクションであっても、データベース制
約は即時チェックであり先送りすべきではない。
一般論は論理的に誤りがある。

- トランザクションとは
- リレーショナルモデルとは別の話題なので、この本
では説明しない、とのこと。知識の無い人は
"Transaction Processing: Concepts and
Techniques"を読め、と。
- トランザクションのACID特性
- Atomicity (原子性)
- トランザクション処理は、処理の単位として原
始的である。すなわちそれが、あるか、ないか
であり、分解はされない。
- Consistency (一貫性)
- トランザクション処理によって、データベース
の一貫性を壊さない。
- Isolation (分離性)
- トランザクション処理中であることは、並行し
て動く他の処理から隠蔽されている。すなわち
トランザクション処理中にデータベースに対す
る操作があったとしても、それは他の処理から
は見えず、無影響である。
- Durability (持続性)
- トランザクション処理が正常に完了(コミット)し
たならば、それはデータベース上の永続化まで
終わっており、システムクラッシュなどが発
生しても消えないことが保証されねばならな
い。


- 一般論とDateの相違点
- 一般論
- 複数の文を束ねてトランザクション処理を構成す
る。だから先送りが発生する。
- Date
- トランザクションはひとつの文で表すべきであ
る。リレーショナルモデルでは、文が整合性チェッ
クの原始的な単位であるから、それと一致して
おり、トランザクションを特別視していない。

- SQLでトランザクションを使うとき
- SQLでトランザクションを使うのは、複数文に処理
が跨り、処理中はデータベースの制約条件(一貫性)が
壊れているときだ。
- 例
BEGIN TRANSASCTION ;
UPDATE S SET CITY = 'Paris' WHERE SNO = SNO('S1') ;
UPDATE P SET CITY = 'Paris' WHERE PNO = PNO('P1') ;
COMMIT ;
- これはそもそも、値を作ることと代入することが分
離できていないことと、複数関係変数に対する代入
を一度に実施できないことに起因している。
- すなわち、SQLの記述力が低いから文を跨るトラン
ザクションが必要になるのだ。

- Tutorial Dの場合
- Tutorial Dには多重代入があるので、前項のSQLの
例は一文で書ける。
- 例
UPDATE S WHERE SNO = SNO('S1') (CITY := 'Paris'),
UPDATE P WHERE SNO = SNO('P1') (CITY := 'Paris');

- 制約と述語
- 関係に含まれるタプルは、意味論としては命題を
表わしていた。
- 関係と関係変数は同じ型を持ち、前項の意味論で
考えるとき関係変数は関係変数述語をもち、その
変項をタプルが指定していると考えられた。
- 現状のデータベース管理システムは、ユーザが投
入しようとしているタプルがこの意味論において
現実世界で真であることを確認することはできな
い。例えば、あるサプライヤの所在地が名古屋で
ある、ということを現実に確認することはできな
い。
- そこで、その正しさを維持することはユーザの責
任となっている。
- ただし、その作業の一部は制約として記述できれば、
データベース管理システムが代わりに実施すること
ができる。

- 制約によって、一貫性は確保できる。しかし上記
の議論からわかるように、正しさは確保できない。
- 一般的に、正しいデータベースは一貫性がある。
また、一貫性のないデータベースは正しくない。

- これらのことからDateの黄金律をDateは思い付い
た。黄金律は次のとおり。

「更新処理によってデータベース制約のいずれか
がFALSEに評価されるようなことがあってはならな
い」


こつこつ。

【DBiD】5 リレーショナル代数 (その5)


** 5.7 リレーショナル比較
- リレーショナル代数演算子とは別にリレーショナル
比較演算子がある。代数演算子は「ものども->関係」
だが、比較演算子は「ものども->真偽値」である。
まあ論理式ということですね。
- リレーショナル比較は、制限などで使う。
- WITH 構文 の紹介
- letみたいなもののようだ。
- 例
WITH (SP RENAME (SNO AS X)) AS R :
S WHERE (R WHERE X = SNO) {PNO} = P {PNO}
- SQLにはリレーショナル比較がほとんど存在しない。

** 5.8 リレーショナル代入
- 代入演算子は全ての型に使える。
- insert,delete,updateは、構文糖衣であり、紐解く
と代入演算子がいる。

** 5.9 ORDER BY 演算子
- ORDER (SQLではORDER BY)は、リレーショナル演算子
ではない。演算子ではある。機能としては、ソートを
指示するものである。

** 5.10 まとめ
- 特になし。


5章、刻んだなぁ。6章の制約は、論理と関係が深そうで、楽しみ。
こつこつ。

2009年7月31日金曜日

【DBiD】5 リレーショナル代数 (その4)


** 5.6 式の変換
- リレーショナル式を同値な別のリレーショナル式に
変換していく。それがオプティマイザの役割のひと
つでもある。
- 式の変換の例。
- 「部品P2を供給するサプライヤを、供給する部品
数とともに取得する」クエリ。

((S JOIN SP) WHERE PNO = PNO('P2')) {ALL BUT PNO}

- 濃度について、S:100、SP:100万、SPのうちP2であ
るのが500という状況を考える。
- この式を単純に評価すると次の手順となる。
- 1. SとSPを結合する。
- Sをread。(100タプル read)
- SひとつごとにSPをread。(100万タプル read)
- 結果として100万個のタプルをwrite。(100万タ
プル write)
- 2. 1の結果を制限する。
- 結果としての100万個のタプルをread。(100万
タプル read)
- 制限として500個がピックアップされ、それは
writeせずにメモリ保持と見做す。
- 3. 2の結果を射影する。
- これはメモリ上の処理。
- この手順でのタプルI/O数は、次の計算のとおり。
(+ 100
(* 100 1000000)
1000000
1000000) ; => 102000100
- 別の手順を考える。
- 1. SPを部品P2のタプルだけに制限する。
- SPで100万タプルread。
- 結果の500タプルはメモリ保持。
- 2. 1の結果とSを結合。
- Sで100タプルread。
- 結合してできた500タプルはメモリ保持。
- 3. 2の結果を射影する。
- これはメモリ上の処理。
- この手順でのタプルI/O数は、次の計算のとおり。
(+ 1000000
100) ; => 1000100
- I/Oの差。
(/ 102000100.0 1000100) ; => 101.98990100989901
- 2つめの手順を素直に表すように式を書き換える。

((S JOIN SP) WHERE PNO = PNO('P2')) {ALL BUT PNO} ; もともと
(S JOIN (SP WHERE PNO = PNO('P2'))) {ALL BUT PNO} ; 変更版

- オプティマイザというのはこういうことを知って
いて、その知識をもとに式変換を実施する。

- 式変換に使えるのはリレーショナル代数の演算子
どうしの性質である。
- 分配則
- 可換則
- 結合則
などがある。
- リレーショナル代数における最適化はDBの実装(物
理構造)によらない。


牛歩のごとくだなぁ。
こつこつ。

2009年7月30日木曜日

【DBiD】5 リレーショナル代数 (その3)


** 5.3 SQL式の評価
- えっと、この節は、SQLの意味をTutorial D (または
リレーショナル代数)が与えている、ということを言
いたいようだ。
- 違う言いかたをすると、SQLは実装により過ぎている、
ということかな。

** 5.4 拡張と要約
- 拡張と要約は、数値の加算などをリレーショナル代
数にて実施するための仕組み。
- 拡張はタプルどうしの計算をサポートする。
- 要約は「下位の属性」の計算をサポートする。

*** 5.4.1 拡張
- 構文
EXTEND <関係> ADD ( <表現> AS <属性名> )
- 例
EXTEND P ADD ( WEIGHT * 454 AS GMMT )
- 意味
Pに属性を追加した関係を表す。追加される属性の属
性名はGMMT、属性の型と値はWEIGHT * 454の型と値。
表現としてどういう語彙と構文が許されているかは
本書のここには記述されていない。

*** 5.4.2 要約
- 構文
SUMMARISE <関係1> PER (<関係2>)
ADD ( <要約表現> AS <属性名> )
- 例
SUMMARISE SP PER ( S { SNO } ) ADD ( COUNT ( ) AS P_COUNT )
- 意味
みてのとおり。すいません、言葉にするのが結構煩
雑なので割愛。

** 5.5 グループ化とグループ解除
- RVAについて、さわりだけ。
- 既存の関係からRVAを作る。
R1 GROUP ( { PNO } AS PNO_REL )
- RVAな関係をばらす。次の例ではR1が得られる。
R4 UNGROUP ( PNO_REL )


こつこつ。

2009年7月29日水曜日

【DBiD】5 リレーショナル代数 (その2)


** 5.2 オリジナルの演算子
- この節では、Coddが最初に定義したリレーショナル
演算子を概観する。

*** 5.2.1 制限
- 構文
<関係> WHERE <ブール式>
- 例
S WHERE CITY = 'Paris'
- 意味
ブール式が真となるタプルのみを含む関係。
*** 5.2.2 射影
- 構文
<関係> { <属性1>, <属性2>, ... }
<関係> { ALL BUT <属性1>, <属性2>, ... }
- 例
S { SNAME, CITY, STATUS }
S { ALL BUT SNO }
- 意味
指定された属性だけを含む関係。ALL BUTのとき
は、指定されていない属性だけを含む、となる。
*** 5.2.3 結合
- 構文
<関係1> JOIN <関係2>
- 例
P JOIN S
- 意味
見出しは、関係1と関係2の見出しの和集合とする。
和の際の重複としたくない見出しについてはさきんじ
てRENAMEしておくものとする。重複している見出
しについて、値が等しいタプルを両関係からピッ
クアップしてそれを属性に重複が無いように結合
したものにて本体を成す。
*** 5.2.4 交わり
- 構文
<関係1> INTERSECT <関係2>
- 例
S { CITY } INTERSECT P { CITY }
- 意味
同じ型の関係1と関係2について、両者で重複する
タプルを本体とした関係。結合で、関係1と関係2
が同じ型のときと同じふるまい。
*** 5.2.5 和
- 構文
<関係1> UNION <関係2>
- 例
S { CITY } UNION P { CITY }
- 意味
同じ型の関係1と関係2について、関係1に含まれ
るタプルも関係2に含まれるタプルも、両方とも
含めた本体をもつ関係。
*** 5.2.6 差
- 構文
<関係1> MINUS <関係2>
- 例
S { CITY } MINUS P { CITY }
- 意味
同じ型の関係1と関係2について、関係1の本体か
ら、関係2に含まれるタプルは除外したものを本
体にもつ関係。
*** 5.2.7 デカルト積
- デカルト積はCoddのオリジナルには含まれていな
いようだ。
- Tutorial Dにも含まれていない。
*** 5.2.8 商
- Dateは商が嫌みたいで、記述が投げやりなので、
割愛。
- リレーショナル比較という別の演算子にて、同じ
効果がより簡単に得られる、というのが、Dateが
やる気がない理由のようだ。
*** 5.2.9 プリミティブ演算子
- プリミティブ演算子というのは、それらがあれば、
他の演算子も表現できる、というようなミニマム
セットのことである。
- ここでのプリミティブ演算子は、制限、射影、結
合、和、半差、である。


こつこつ。

2009年7月27日月曜日

【DBiD】5 リレーショナル代数


* 5 リレーショナル代数

自分なりの言葉で書く

- リレーショナル代数の演算の特徴
- 閉包である。
- 非破壊的である。
- 関係変数は普通の意味での変数である。
- つまり、普通の代数ってことだろうな。
- こういうことを強調せざるを得ないのは、SQLがそう
じゃないから、と予測する。

- Tutorial D の設計について

- unionやjoinのように、オペランドの属性どうしが一
致しなければならない演算においては、該当属性は
型と属性名が一致していることを求める。例えば、

P JOIN S

としたとき、PとSにそのような属性があることをユー
ザが気をつけなければいけない。

- SQLにあるようなドット表記の名前は禁止。

** 5.1 閉包

- 閉包である、ということは、リレーショナル代数演
算にて演算子が連なるとき、それぞれの入出力が関
係であるということであった。
- しかしこれは概念上のことであり、実際の処理にお
いては、効率のために、処理系はなるべく中間の関
係を実体化しないように工夫するであろう。
- 閉包ということは、関係が持つ見出しの推論と関連が
ある。
- Tutorial Dにて、

---

(P JOIN S)
WHERE PNAME > SNAME

---

- という文を考えると、PNAME > SNAMEというのが問わ
れているのは、PでもSでもなく、(P JOIN S)が返す
関係だ。なので(P JOIN S)の見出しがなんなのかがP
とSから特定されねばならない。これが見出しの推論
である。
- 具体的には、そのJOINによって作られる集合の見出
しは、Pの見出しとSの見出しの和集合になる。

- Tutorial Dでは、代数演算において属性名が役割り
を果たすので、属性名の書き換えは重要である。そ
れはRENAMEで実施する。

S RENAME (CITY AS SCITY)


こつこつ。

2009年7月25日土曜日

【DBiD】4 関係変数


* 4 Relation Variables

この章、私にとってはけっこう難しい、というかDateが
結局何を言いたいのかが、訳書でも原書でも、すっと入っ
てこない。そこで、この章では、原書をベースにしつつ
訳書も参照するという二段がまえでいく。

例によって、このエントリは、読書メモよりも私的まと
めに近い。


- まずベース例をTutorial Dで記述する。

---
var S base relation
{ sno sno, sname name, status integer, city char }
key { sno };

var P base relation
{ pno pno, pname name, color color, weight weight, city char }
key { pno };

var SP base relation
{ sno sno, pno pno, qty qty }
key { sno, pno }

foreign key { sno } references S
foreign key { pno } references P;
---


** Updating Is Set-at-a-Time
- 一般のプログラミング言語と同じように、変数と値
を考えよ、ということ。
- insert, delete, update の説明がある。どうやら、
これらは非破壊的なようだ。
- すなわち、関係、タプルといったものは、それらに
演算子が作用すると結果としての関係やタプルが生
成される。そしてその結果を関係変数に代入するな
らば、関係変数が参照する値は更新されたことにな
る、と。

** More on Candidate Keys
- Candidate Keysの定義。原文まま引用。

---
Definition: Let K be a subset of the heading of
relvar R. Then K is a candidate key (or just key
for short) for R if and only if it posesses both
of the following properties:

Uniqueness
No possible value for R contains two distinct
tuples with the same value for K.

Irreducibility
No proper subset of K has the uniqueness property.
---

- ふむ。シンプル。

- 注意点をいくつか。
- キーが設定されるのは、関係ではなく、関係変数
である。これはおどろいた。理由としては、キー
を設定するということは、なにがしかの制約をか
けるということだが、制約は変数に所属すべきだ
から。なぜかというと、制約というのは何かを更
新するときに機能するが、更新されるのは値では
なく変数が何を参照するか、だから。納得!
- これがCommon Lispや他のプログラミング言語に
あるかどうか考えてみる。変数の型、はある意
味制約をかけている。Object指向のObjectなら
ば、実装としてそういう制約をつくることはで
きるといえばできる。
- キーの値となるのは、属性そのものではなく、その
属性のみをもつタプルである。今までの諸定義から
すればあたりまえのことだが、これも言われないと
意識されないことだなぁ。
- functional dependency (関数従属性)について。
自分なりにちゃんと書いてみる。

関係変数Rvが、値として関係Rをもち、キーとして
Kが設定されているとする。すると、関係Rに含まれ
るタプル値一般をTとあらわすとき、Tは次の二つの
タプルを含むと見ることが可能であり、それは、K
を見出しとして持つタプル(Tkと呼ぶ)と、Kに含ま
れない属性を見出しに持つタプル(Taと呼ぶ)である。
これら2つは属性に重なりはない。

さて、(a)関係Rに含まれるタプルについてTkとTaの
対応を写像ととらえることができて、それは、
(b)Tkの集合とTaの集合の間の写像であり、全射で
ある。

(a)(b)が成り立つ理由は、関係Rに含まれるタプル
にそもそも重複が無く、かつ、キーの値となるタ
プル達にキーの定義から重複が無いから。

** More on Foreign Keys
- 定義なので原文まま引用。

---

Definition: Let R1 and R2 be relvars, not
necessarily distinct, and let K be a key for
R1. Let FK be a subset of the heading of R2 that,
possibly after some attribute renaming, involeves
exactly the same attributes as K. Then FK is a
foreign key if and only if, at all times, every
tuple in R2 has an FK value that is equal to the K
value in some (necessarily unique) tuple in R1 at
the time in question.

---

- 外部キーというのは実践にて頻繁に使うので強調さ
れることが多いが、理論の立場から言えば、制約と
いうより多きな概念における例のひとつにすぎない。

** More on Views

- 定義なので原文まま引用。

---

Definition: A view or virtual V is a relvar whose
value at time t is the result of evaluating a
certain relational expression at that time t. The
expression in question is specified when V is
defined and must menthion at least one relvar.

---

- リレーショナルモデルにおいては、base relvarであ
るかvirtual relvarであるかということは、どちらを
先に定義して、どちらをそれを使った表現で定義する
かという違いだけであり、演算子における扱いや制約
の設定など、その使用方法(原文ではlook and feel)
にほぼ違いはない。これを

The Principle of Interchangeability (of base
and virtual relvars) [訳:交換可能性の原理]

という。

- SQLは、この原理のサポートが弱い。以下はその例。
- テーブルのrow IDに関すること。これがあると、
rowIDというのはbase relvarにしか存在しないはず
だから、原理から逸脱している。
- entity integrity(主キーの要素はnullではいけな
い)という制約も、base relvarに対する言明なの
で、これも原理から逸脱している。ただし、これ
はそもそもnullの存在をDateは否定しているので、
その観点でも却下なのだが。
- viewのupdateに関する機能が弱い。

- なお、viewのupdateについては、まだ論争が絶えな
い状態。Dateの見解の詳細は、The Third
Manifesto, Third Editionを参照のこと。

- relcon(関係定数)の紹介。

- snapshotの紹介。

** Relvars and Predicates

この節が一番もやもやするので、自分で完全にまとめ直
す。

- 関係に含まれるタプルは、それぞれ論理学の命題で
あると考えてみる。
- すると、関係は論理学における知識ベースに位置付
けられる。
- 関係に含まれるタプルは、全て真の命題である、と
言っても諸事情は整合する。
- この文脈にて、リレーショナルモデルでは、閉世界仮
説を採用している。すなわち、知識ベースに無い命
題は偽とする。
- 例えば、関係「商品」があって、その見出しに「商
品名」、「種類」、「在庫数」があるとすると、
タプル、

{商品名 あわあわ, 種類 石鹸, 在庫数 5}

は、商品名がキーであるとすると、

商品名あわあわは、種類が石鹸であり、在庫数が5で
ある。

という命題であり、これは真であるということだ。
- この文脈では、属性は自由変項をひとつ含んだ言明で
あり、その変項の領域が本体のタプル達が含む該当
属性の値になる。
- 属性A1,...,Anの言明版を、A1(X1),...A1(Xn)とする
と、その関係を参照している関係変数は、

A1(X1)^...^A1(Xn)

という言明を取扱っている、と言える。本体には、
これが真となるX1,...,Xnが全て格納されており、こ
こに格納されていないX1,...,Xnについては閉世界仮
説により全て偽となるからだ。
- ということは、関係変数は、ある言明(論理式といっ
てもよい)についての真偽を司っているものであり、
論理学でいうところの述語の定義の役割を果たして
いる。

- ここで私が「述語の定義の役割を果たしている」と書
いたのは、Dateの「関係変数の見出しは述語である」
というのと違っている。というのは、私はここで論理
学における意味で述語をつかっているからだ。そこで
は、述語は写像であり、論理式の中で、p(X,Y)や、
p(a,b)などと項を引数にとりつつ使われるものだから
だ。上の流れの説明においては、関係変数が参照して
いる関係は述語を定義していると言えるが、それ自体
が述語として運用される構文は提示されていない。

- ただし、Dateのrelvar predicate (関係変数述語)の
くだりは、私の組み立てと一致している。「関係変数
の見出しは述語である」というのはアジテーション
なだけなのかもしれない。

- さて、このように関係や関係変数を論理学の観点で
捉えるということは、リレーショナル式(relational
expression)によって表現されている関係についても
適用できる。

** More on Relations Versus Types
- Dateは、リレーショナルモデルは形式理論であり、
上で述べたように論理を取り扱うものだと言う。で
あるならば、形式理論として統語論と意味論を書き
くだしてもらった方がやっぱりわかりやすいなぁ。
- ちょっと説明が回りくどい気がするが、リレーショナ
ルモデルの型は、いわゆる形式理論の型である、とい
うことが言いたいようだ。

** Summary
- 特になし。


こつこつ。

2009年7月23日木曜日

【DBiD】3 タプルと関係


* 3 タプルと関係

** 私の雑感
この本はDateのアジというか、ノイズが多い。
このアジは、SQLをリレーショナルモデルと思い込んで
いる人に対する気付け薬的なものだろう。

そういう思い込みが無い人にとっては、アジはいいから、
もうちょっとすっきり整理して言いたいことを言って欲
しいなぁ、と感じさせるものではないか。実際私はそう
だ。しかしそれはこの本を読んでいる私の選択の問題だ
ろう。C.J.Dateは著書が豊富なので、その中にはすっき
り整理してある本もあるのだろう。

また、この本の訳書のタイトルはまずいかもしれない。
「データベース実践講義」というタイトルで期待するこ
とは、本書の内容とは違うことが多いのではないか。原
書の「Database in Depth」はそういう意味ではアリであ
る。訳書のタイトルのアンマッチが、読者の誤解や不評
に繋らなければよいのだが。私自身は原題の認識が先行
していたので、アジ以外は期待通り。

閑話休題。

という事情も加味しつつ、この章も自分なりのまとめを
書く。読書メモとはちょっと違うものです。


** タプルの定義
定義なので、原文まま引用。

---
T1,T2,...Tn (n>=0)が型名であり、それらが必ずしも異
なるとは限らないとする各Tiに識別可能な属性名Aiを関
連付ける。これによって生じるn個の属性名と型名の組
みは、それぞれ属性である。各属性をTi型の値viに関連
付ける。それによって生じるn個の属性と値の組みは、
それぞれコンポーネントである。そのように定義された
n個のコンポーネントからなる集合(t)は、属性
A1,A2,...,Anのタプル値(または略してタプル)である。
値nはtの次数であり、次数1のタプルは単項、次数2のタ
プルは2項、次数3のタプルは3項である。一般に、次数n
のタプルはn項である。n個の属性からなる集合は、tの
見出しである。
---

** タプルをCommon Lispのオブジェクトで表現してみる

- 型名
- これはatom。

T1 T2 T3

- 属性名
- これもatom。

A1 A2 A3

- 属性
- これはdotted pairにしてみる。

(T1 . A1)
(T2 . A2)
(T3 . A3)

- 値
- これもatomにしてみる。

v1 v2 v3

- コンポーネント
- dotted pair。

((T1 . A1) . v1)
((T2 . A2) . v2)
((T3 . A3) . v3)

- タプル値 (タプル)
- listで表現する。しかしタプル値としては集合な
ので、そこは表現しきれていない。

(((T1 . A1) . v1)
((T2 . A2) . v2)
((T3 . A3) . v3))

- 見出し

タプル値、

(((T1 . A1) . v1)
((T2 . A2) . v2)
((T3 . A3) . v3))

の見出しとは、

((T1 . A1)
(T2 . A2)
(T3 . A3))

である。listだが、集合として使うことを想定して
いる。

- タプル値というのは、super-boxedなデータみたいな
ものかな。型のみならず、現在の(DSLの意味での)
ドメインの名前(属性名)までもデータに入っている。
そうか、Common Lispとかの構造体と同じなのか。
例えば、HyperSpecから例をとると、構造体の定義は、

---
(defstruct ship
(x-position 0.0 :type short-float)
(y-position 0.0 :type short-float)
(x-velocity 0.0 :type short-float)
(y-velocity 0.0 :type short-float)
(mass *default-ship-mass* :type short-float :read-only t))
---

であり、一応生成された構造体のスロットも、自分
自身のスロット名やスロットの型を知っている。な
るほどなるほど。

** タプルに関するトピック

- nullを含むタプルは存在しない。
- そう決めるのは自由なのだが、Common Lispには
nilがあり、構造体の値にも使えたりする。

- タプルの部分集合はタプルである。
- 見出しの部分集合は見出しである。

- 次数がゼロのタプルを0タプルと呼ぶ。
Common Lisp的に表現すると、

()

かな。
- タプルの等価性は、Common Lispのequalp的に定義さ
れている。

** 関係の定義
定義なので原文まま引用。

---
{H}をタプルの見出しとし、t1,t2,...,tm (m >= 0)を見
出し{H}を持つ個々のタプルであるとする。{H}とタプル
の集合{t1,t2,...,tm}との組み合わせrは、属性
A1,A2,...,Anにおける関係値(または単に関係)である。
ここで、A1,A2,...,Anは{H}の属性である。rの見出しは
{H}である。rは見出しと同じ属性(よって、同じ属性名
と型)と、見出しと同じ次数を持つ。rの本体はタプルの
集合{t1,t2,...,tm}である。値mはrの濃度である。
---

- タプルの流れで、Common Lispで関係を表現すると、

まず、これが見出しで、

((T1 . A1)
(T2 . A2)
(T3 . A3))

タプル値が例えば、3つあるとするとそれらは、

(((T1 . A1) . v11)
((T2 . A2) . v12)
((T3 . A3) . v1))

(((T1 . A1) . v21)
((T2 . A2) . v22)
((T3 . A3) . v23))

(((T1 . A1) . v21)
((T2 . A2) . v22)
((T3 . A3) . v23))

なんぞであり、タプル値の集合が関係の本体なので、

((((T1 . A1) . v11)
((T2 . A2) . v12)
((T3 . A3) . v1))
(((T1 . A1) . v21)
((T2 . A2) . v22)
((T3 . A3) . v23))
(((T1 . A1) . v21)
((T2 . A2) . v22)
((T3 . A3) . v23)))

リストで集合を表現するとこれが本体。

この本体と見出しを組み合わせたのが関係だから、
それをリストであらわすと、

(((T1 . A1)
(T2 . A2)
(T3 . A3))

((((T1 . A1) . v11)
((T2 . A2) . v12)
((T3 . A3) . v1))
(((T1 . A1) . v21)
((T2 . A2) . v22)
((T3 . A3) . v23))
(((T1 . A1) . v21)
((T2 . A2) . v22)
((T3 . A3) . v23))))

これが関係。

** 関係に関するトピック
- 本体の部分集合はすべて本体である。
- 関係の中でのタプルの重複はリレーショナルモデル
では禁止されるべきである。Tutorial Dでは禁止さ
れている。SQLでは禁止されていない。

** nullを禁止すべき理由
- リレーショナルモデルは、2値論理(2VL)に基づくべ
きである。(その方が有用だから) そして実際に、リ
レーショナルモデルの中の各部は2値論理に基づいて
組みたてられている。
- nullを含むということは、述語の値が
true,false,unknownの3値になり3値論理(3VL)という
ことになる。
- 2値論理の機構と3値論理の機構が混在すると、期待
する正しい結果が得られないというか、保証されな
い場合がでてくる。実際、SQLではそういった例があ
る。
- よってnullはリレーショナルモデルに含まない方が
よい。
- nullが入っている状態はリレーショナルモデル以外
の何かであると認識した方がよい。

** TABLE_DUM と TABLE_DEE
- TABLE_DUMは、空の関係である。
Common Lispの表現の流れでは、

(() ())

である。次数ゼロなので、見出しは空集合である。ま
た、本体も何も含まないので、空集合である。

- TABLE_DEEは、次数ゼロで空のタプルを壱つ含む関係
である。
Common Lispの流れの表現では、

(() (()))

である。本体に空のタプルを壱つ含んでいるが、空
のタプルは空集合なので、このようになる。

- これらはリレーショナル代数において役割をもつ。
TABLE_DEEはゼロの役割を果す。
- 真理値の観点で言うと、TABLE_DUMはNO/FALSEの役割
を果たし、TABLE_DEEはYES/TRUEの役割を果たす。


こつこつ。

2009年7月21日火曜日

【DBiD】2 関係と型


* 2 関係と型
自分なりのポイントを自分なりの言葉で書く。

- まず、基本的には、リレーショナルモデルにもいわ
ゆる型がありますよ、ということ。

** Coddのオリジナルモデルからの修正
- Coddがドメインと呼んでいるものは型にすぎない
- Coddは、異なる型に属する属性間の比較を許してい
る(ドメインチェックオーバーライド)が、これは禁
止されるべきである。
- データの「原始性」という言葉にはちゃんとした意
味はない。
- 何が「原始的」かは、ユーザの観点というかニー
ズによる。

** リレーショナルモデルの型システム
- 型
- = 値の名前付き集合
- リレーショナルモデルの型システムの特色/注意点
- 強い型付けである。
- 本書ではすべての値は単独の型にのみ属するもの
とする。リレーショナルモデルの型継承及び型多
重継承については割愛する。(そんなものあるの
か?)
- すべての式は型をもつ。
- リレーショナルデータベースに含まれる変数は
関係変数のみである。他の変数は存在しない。
- 再帰的な型の定義を許さない。すなわち、関係r
の型がTであるとき、関係rの属性の型がTである
ことは許されない。
- ポインタ型は存在しない。この部分、記述が弱く
て正確には理解できないが、おそらくCのポイン
タのイメージだろう。メモリアドレスを取り扱
うような型ということかな。
- 型はスカラーと非スカラーに大別される。
- 非スカラー型
- = タプル型または関係型のこと。
- スカラー型
- = スカラー型以外の型。
- 属性へのアクセスはセレクタで行う。セレクタ
は例えばSNO('S1')など。
- 属性として関係も使える。これを関係値属性
(Relation-Valued Attributes)と言う。SQLでは
サポートされていない。


こつこつ。

2009年7月20日月曜日

【DBiD】1 概要

自分なりのポイントを自分なりの言葉で書く。


* 1 概要
- データベースの基礎の大部分はリレーショナルモデ
ルというものに属している。
- SQLはリレーショナルモデルではない。
- この本ではリレーショナルモデルを正しい用語
で正しく取り扱う。
- リレーショナルモデルの定義は徐々に変わりうるも
のである。(数学が進化するのと同じ意味で)
- この章ではE.F.Coddが提示したオリジナルモデルを紹介
する。後の章ではそれを発展させることもある。
- オリジナルモデルは、構造、整合性、操作の3つの基
本要素によって構成される。
- 構造の語彙
- 型 (ドメインとも)
- 関係
- 属性
- タプル
- キー
- 候補キー
- 主キー
- 外部キー
- 参照
- 整合性の語彙
- 整合性制約 (制約とも)
- 個々のDBに特有の制約
- 汎用的な制約
- 実体整合性
- null (Dateはnullの存在に批判的)
- 参照整合性
- 操作の語彙
リレーショナルモデルの操作は、リレーショナル代
数とリレーショナル代入から成る。
- リレーショナル代数
- 閉包性
- ネストしたリレーショナル式
- 最初に定義された8つの演算子
- 制限
- 射影
- 積
- 交わり
- 和
- 差
- 結合
- 商
- リレーショナル代入
- リレーショナル計算
- リレーショナル代数の代替物。
- 本書ではメインには扱わない。
- 本書の各所説明にてベースとなる例
- サプライヤと部品のデータベース
- 関係S
- 契約を結んでいるサプライヤを表す。
- 属性
- サプライヤ番号 (SNO)
- 名前 (SNAME)
- 評価または状態値 (STATUS)
- 所在地 (CITY)
- キー
- サプライヤ番号は主キーである。
- 関係P
- 部品の種類を表す。
- 属性
- 部品番号 (PNO)
- 部品名 (PNAME)
- 色 (COLOR)
- 重量 (WEIGHT)
- その部品の補完場所 (CITY)
- キー
- 部品番号は主キーである。
- 関係SP
- 出荷(出荷された部品とその部品を出荷したサ
プライヤ)を表す。
- 属性
- サプライヤ番号 (SNO)
- 部品番号 (PNO)
- 数量 (QTY)
- キー
- {SNO,PNO}は主キーである。
- この例では特定のサプライヤが特定の部
品を出荷できるのは1度まで、としている。
- データモデルの2つの意味
- 2つの意味の定義
1. リレーショナルモデルのこと。すなわち、リレー
ショナルモデルの3要素(構造、制約、操作)を抽
象機械を使って定義したもの。
2. 特定企業等の永続データのモデル。
- 本書では1の意味でデータモデルを用いる。
- 1の意味のモデルは、実装との分離を目的としたも
のである。これをデータ独立性と言う。
- 関係の語彙のチューンナップ
- 関係は見出しと本体とから構成される。
- 見出し
- = 属性の集合
- 次数/項数 (degree/arity)
- = 見出しに含まれる属性の数
- 本体
- = タプルの集合
- 濃度 (cardinality)
- = 本体に含まれるタプルの数
- 関係は常に第一正規形(1NF)である。
- 属性とタプルを指定する組は常にユニークであ
るということ。まあ、属性とタプルが集合なら
自然とそうであろう。
- リレーショナル代数の入出力がらみ
- リレーショナル代数によって関係から関係を作る
とき、素材になった関係を基底関係、作られた関
係を派生関係と呼ぶ。
- 派生関係にも名前をつけることができる。そのと
きそれをビューと呼んだり仮想関係と呼んだりす
ることもある。
- 関係と関係変数
- 関係はファーストクラスであり、名前をつけるこ
とができる。
- 語彙
- 関係変数 (テーブル変数とも)
- ソース式 (Tutorial Dの代入文の右辺のこと)
- ターゲット変数 (Tutorial Dの代入文の左辺のこと)
- 関係値
- relvar (関係変数の表記)

C.J.Date、ちょっとアジりすぎかも?
でも内容はおもしろそう。

こつこつ

2009年7月19日日曜日

データベース実践講義(Database in depth)を読む

Prologと論理のことが多少わかってきたところで、じゃあRDBって何なのさ、ということを探ってみたい。ぼやぼやーとした感じでよいので。

そこで、次の本を読むことにした。

C.J.Dateのデータベース実践講義

根を詰めると倒れるので、ぼやぼやーといきたい。

2009年1月11日日曜日

【初SQL】8 グループ化と集約化

そろそろSQL文が長くなってくるので、sql-mysqlモードを使いはじめることにする。
これはEmacs本体の配布に同梱されていて、M-x sql-mysqlで立ち上がる。使い勝手が悪いようなら、他の選択肢を探す。


  • 8.1 グループ化

    • なんかこのあたり、構文と意味がぐちゃぐちゃ。SQLは汚ないな。

  • 8.2 集約関数

    • この本を読んでいくなかで、徐々に徐々に違和感というか居心地の悪さが増していったのだが、その理由がわかった。やはり、スキーマというかサンプルデータベースの構造に関する説明なしに、データ取得用のSQLをどんどん繰り出されても、暗闇に何かをなげたら何かがかえってくるみたいな話になってしまっているからだ。なので、ここらへんで、勝手ながらサンプルデータベースの構造の理解を進めてみる。
    • Webでいろいろ調べてみることにする。米国の金融用語についてはまったく素人なので、間違っている可能性が少からずです。ご注意ください。

      • 付録AのER図を眺める。まあ、ER図はあまり役に立たないものだ。
      • LearningSQLExample.sqlを眺める。ポイントは次のとおり。

        • department(部門)とbranch(支社)とtitle(役職)は独立した概念である。
        • employeeのtitleは列挙型ではなく、varcharである。現況を調べる必要あり。

          • 現況。

            mysql> select title from employee group by title;
            +--------------------+
            | title |
            +--------------------+
            | Head Teller |
            | Loan Manager |
            | Operations Manager |
            | President |
            | Teller |
            | Treasurer |
            | Vice President |
            +--------------------+

          • President, Vice Presidentはわかる。
          • Teller: 出納係;出納主任;窓口係;計算係; と辞書にはある。これじゃ言葉の意味として多様すぎないか?
          • Head Teller: Tellerのリーダのことだろう。
          • Treasurer: 会計[出納]係, 経理[財務]部長; と辞書にはある。しかし、会計係と財務部長じゃずいぶん違わないか???
          • Loan Manager: 融資の責任者、だろう。
          • Operations Manager: このOperationは投機取引のことなのか、業務運用のことなのか、、、
          • 役職の階層構造をみる。

            mysql> select it.title, sup.title from employee it inner join employee sup on it.superior_emp_id = sup.emp_id;
            +--------------------+--------------------+
            | title | title |
            +--------------------+--------------------+
            | Vice President | President |
            | Treasurer | President |
            | Operations Manager | Treasurer |
            | Loan Manager | Operations Manager |
            | Head Teller | Operations Manager |
            | Teller | Head Teller |
            | Teller | Head Teller |
            | Teller | Head Teller |
            | Head Teller | Operations Manager |
            | Teller | Head Teller |
            | Teller | Head Teller |
            | Head Teller | Operations Manager |
            | Teller | Head Teller |
            | Teller | Head Teller |
            | Head Teller | Operations Manager |
            | Teller | Head Teller |
            | Teller | Head Teller |
            +--------------------+--------------------+
            17 rows in set (0.00 sec)

            役職と部門の関係もみる。

            mysql> select it.title, dep.name from employee it inner join department dep on it.dept_id = dep.dept_id;
            +--------------------+----------------+
            | title | name |
            +--------------------+----------------+
            | Operations Manager | Operations |
            | Head Teller | Operations |
            | Teller | Operations |
            | Teller | Operations |
            | Teller | Operations |
            | Head Teller | Operations |
            | Teller | Operations |
            | Teller | Operations |
            | Head Teller | Operations |
            | Teller | Operations |
            | Teller | Operations |
            | Head Teller | Operations |
            | Teller | Operations |
            | Teller | Operations |
            | Loan Manager | Loans |
            | President | Administration |
            | Vice President | Administration |
            | Treasurer | Administration |
            +--------------------+----------------+
            18 rows in set (0.00 sec)

            ああ、わかった。

            President (社長)
            ->Vice President (副社長)
            -> Treasurer (財務担当役員)
            -> Operations Manager (本部長)
            -> Loan Manager (融資部長)
            -> Head Teller (出納係統括)
            -> Teller (出納係)


          ということだ。
        • product_typeのnameは列挙型ではなく、varcharである。

          mysql> select * from product_type;
          +-----------------+-------------------------------+
          | product_type_cd | name |
          +-----------------+-------------------------------+
          | ACCOUNT | Customer Accounts |
          | LOAN | Individual and Business Loans |
          | INSURANCE | Insurance Offerings |
          +-----------------+-------------------------------+
          3 rows in set (0.00 sec)

          これはまんまだな。
        • productのproduct_cdもvarchar。調べる。

          mysql> select * from product;
          +------------+-------------------------+-----------------+--------------+--------------+
          | product_cd | name | product_type_cd | date_offered | date_retired |
          +------------+-------------------------+-----------------+--------------+--------------+
          | CHK | checking account | ACCOUNT | 2000-01-01 | NULL |
          | SAV | savings account | ACCOUNT | 2000-01-01 | NULL |
          | MM | money market account | ACCOUNT | 2000-01-01 | NULL |
          | CD | certificate of deposit | ACCOUNT | 2000-01-01 | NULL |
          | MRT | home mortgage | LOAN | 2000-01-01 | NULL |
          | AUT | auto loan | LOAN | 2000-01-01 | NULL |
          | BUS | business line of credit | LOAN | 2000-01-01 | NULL |
          | SBL | small business loan | LOAN | 2000-01-01 | NULL |
          +------------+-------------------------+-----------------+--------------+--------------+
          8 rows in set (0.00 sec)

          checking account (account): 当座預金 (手形や小切手の支払いを決済するためのもの)。transactional accountの北米名。
          savings account (account): 普通預金 (自由に預入・払戻ができる預金)
          money market acccout (account): 金融市場預金 (当座預金の一種。ただし、比較的ハイリスクハイリターン。銀行は金融市場への投資運用に利用する)
          cerificate of deposit (account):譲渡性預金証書 (定期預金のひとつ。預金者がこれを金融市場で事由に譲渡できる)
          home mortgage (loan): 住宅ローン
          auto loan (loan): 自動車ローン
          business line of credit (loan): 法人クレジットカード?
          small business loan (loan): 中小企業融資
        • officerって何?

          • どうやら、business(法人)における役員のこと。

        • accountのpending_balanceって何?

          • available balance: 利用可能残高? (払戻し等、利用できる金額)
          • pending balance: 銀行が処理待ちで保持しているものも勘案した残高? (小切手などを即時処理せずに、銀行が信用調査するなど?)

        • transactionのtxn_type_cdの'DBT'と'CDT'は何?

          • 簿記の、debit(借方)、credit(貸方)のことかな?

        • transactionのfunds_avail_dateは何?

          • そのtransaction(取引)の結果として利用可能と処理された資金が実際に利用可能となる日時かな。



    • PCLのときも書いたが、なぜ、オブジェクトやエンティティの説明のときに銀行や預金を持ち出すのか? 以上の用語の説明は、グーグル、Yahoo!、Wikipediaや金融機関サイトなどをいろいろ検索しまくって、それらかの情報をつぎはぎにしてやっと構成したものだ。用語体系として、または、概念体系として、英語のサイトですらちゃんと説明できているところが簡単には見付からないということだ。例えば、図書館の貸出システムとかの方が、例としてはマシなんじゃないか?
    • さて、進める。
    • 集約関数は、groupに対して作用する。

  • 8.3 グループの生成

    • この節、翻訳がいまいち。
    • roll-up:巻き上げ式
    • ドリルダウン:データの集計レベルを1つずつ掘り下げて集計項目をさらに詳細にする操作。
    • うーん。5.1では、with rollupの結果とwith cubeの結果が同じだ。。。

  • 8.4 グループのフィルタ条件

    • 集約関数など、グループ化された後に生成される値をフィルタ条件に用いるにはhaving節を使う。


こつこつ。

2009年1月10日土曜日

【初SQL】7 データの生成、変換、操作

前回は、MySQLが5.1になってもSQL標準にあまり準拠していなくて、へこんだ。
気をとりなおして、進む。


  • 前説

    • おお、文字列、数値、時間データの生成、変換、操作などについては、SQL言語には含まれていないんだ。。。

  • 7.1 文字列データの操作

    • 処理が進んじゃって、別途Warningがでる、というのはいやーな感じ。
    • お、quoteだ。
    • DBでは文字列のインデックスは1始まりなんだ。

  • 7.2 数値データの操作

    • 特になし。

  • 7.3 時間データの操作

    • 特になし。

  • 7.4 変換関数

    • ベンダー固有関数ではなくcastを使おう。



この章の内容をどう捉えるか。
まず、RDBMSが提供するSQL+αで情報の表示をカスタマイズするのには使える。また、その道具立てで、どう情報をRDBにいれるかというときにも使える。そうか、データの入出力関係、ということか。CLでいうと、基本的なデータ型のリテラルとそれらを引数とする関数、ということか。

こつこつ。