リレーショナル完備

本文中で言及されていた論文があったのでメモ。

A relational model of data for large shared data banks

依存権限の CASCADE はく奪

P. 50 辺りまで読む。
与えた権限 (privilege) をはく奪する（REVOKE コマンド) 際、CASCADE オプションで権限委譲したユーザからもはく奪されるとある。ふと疑問に思ったんだけど、もし甲の権限をはく奪した場合、委譲対象であるユーザ乙が他ユーザ丙からも委譲されていた場合どうなるんだろうか ?

予想したパターンは二つ。

1. 丙から与えられていた権限のみが残る
2. 既に与えられた権限と重複するものを新たに持つことはできず、結果として甲が権限を失った段階で、乙もすべての権限を失う

本によれば、リレーションレベルの権限は SQL で規格化されているとのこと。

PostgreSQL 8.4.1文書 REVOKE

グラントオプション付きの権限を保持しているユーザが、その権限を他ユーザに与えていた場合、与えられたユーザが保持する権限は依存権限と呼ばれます。

権限を依存権限と呼ぶらしい。

この再帰的な権限の取り消しは、ユーザ権限の連鎖を通じて与えられた権限の中でも、REVOKEを実行されたユーザから追跡可能な範囲にのみ影響します。したがって、依存権限を持つユーザが他のユーザからも同じ権限を与えられている場合は、REVOKEが実行された後もその権限を保持している可能性があります。

Oracle互換 開発者ガイド

この再帰的な権限の取り消しは、ユーザ権限の連鎖を通じて与えられた権限の中でも、REVOKEを実行されたユーザから追跡可能な範囲にのみ影響します。したがって、依存権限を持つユーザが他のユーザからも同じ権限を与えられている場合は、REVOKEが実行された後もその権限を保持している可能性があります。

あれ、ほとんど同じ文章じゃない ?
とりあえず、ほとんどの場合は (1) の結果になると考えておくべきか。

これは関係データベースの話

つい忘れるので多分書いておく。
データ化したい物事 (リレーショナルデータベース入門でいうところの実世界) をいかにデータとするかと、個々のデータを離れた関係データベースという発想、両者は「データベースを扱えるようになる」という観点からは同じカテゴリに入るものである。しかし、基本的にこの本は後者の話をしている (今のところ) 。それを忘れると、昨日の記事みたいな混乱を来すことになる。
いかにモデルを設計するかの話もちょくちょく出ない訳ではない (うろ覚え) けど、そういう話をメモする時は明記しておこう。

なんだか日記っぽくなってきた。まあ日記なんだけど。

多値従属性

多値従属性、関数従属性はいずれも一貫性制約の一種だけど、リレーショナルデータベース入門では 4章で触れられる概念である。大分先だ。
しかしながら、ここで触れておかないと忘れてしまいそうなので、ちょっと途中を流し読みして先に見てみた。

[命題 2] R ⊇ R₁ * R₂ が成立するための必要かつ十分条件は, t[A₁A₂…A_l] = t'[A₁A₂…A_l] を満たす R の任意の2タップルtとt'について, それから構成される次の2タップルwとw'がまた R のタップルであること:
w = (t[A₁A₂…A_lB₁B₂…B_m], t'[C₁C₂…C_n])
w' = (t'[A₁A₂…A_lB₁B₂…B_m], t[C₁C₂…C_n])

(P. 83)

多値従属性と書いておきながら、その前段の 4.4 リレーションの情報無損失分解についての話なんだけど、どうでもいいところで激しく迷ってしまった。
タップルの初出は P. 27 なんだけど、その節では括弧で括られた単なるリストとして記述されている。とりあえず、リレーション 犬[名前, 飼い主, 犬種, 年齢] みたいな記述があるので、t[…] = t'[…] はインスタンスに関係ない話と考えていいんだろうか。多分今までの話の流れからしてそうだろうなあ。

一貫性制約と DDL

一貫性制約とは、データベースに収める情報に意図した性質を保たせるよう設けるルール。キー制約や外部キー制約もその一部。データ定義言語 (Data Definition Language, DDL) により定義され、通常 SQL で記述される。

検査制約・表明・トリガ

当然のことながら、一貫性制約は新たなデータが挿入される度に検討されねばならない。リレーショナルデータベースにおいてそれを実現する機能は、検査制約、表明、トリガの 3種類に大分される。検査制約は単一の、表明 (assertion) は複数のリレーションにまたがる性質を保持するために働く。トリガは ECA (event-condition-action) ルールを実装する。
いろいろごちゃごちゃ例が書いてあるけど、SQL 文はまだ理解できないので後で。

外部キー制約

引き続きリレーショナルデータベース入門新訂版から。
外部キー - Wikipedia
いろいろ書いてあるのはいいんだけど、具体的にどのような場合に適用されるのかが分かりづらい。例を見てみよう例を。というわけで、書籍 (P. 38) で挙げられたケースを引用しておく。

• リレーション 社員の所属値には、リレーション 部門に登録されている部門番号か、空値しか入り得ない。
• リレーション 部門の部門長値には、リレーション 社員に登録されている社員番号か、空値しか入り得ない。

実際のデータベースでは、空値になった場合には NULL の代わりに、あらかじめ設定された既定値を設定させる (SQL:2003 なら SET DEFAULT) こともできるようだ。

キー制約

リレーショナルデータベース入門新訂版を読んいでる。
データベース設計 (もちろん、中に収める情報の方を指す) の制約について細切れに出てくるので、なるべくメモしておきたい。まずはタイトルに出てくるキー制約から。

(P. 36)

(1) 主キーはタップルの唯一識別能力を備えていること
(2) 主キーを構成する属性の値は空値(null value)をとらないこと

(1) はともかくとして、(2) はうっかりすると忘れそうだ。
主キー制約という言い方の方が一般的みたい。