コッドの12の規則
コッドの12の規則 (Codd's 12 Rules) とは、DBMS (データベース管理システム) が関係に基づいたシステム (RDBMS; 関係データベース管理システム) であると判断するために必要な基準として、エドガー・F・コッドが提唱した規則である。
コッドは、関係データベースについての自分の考えが不十分なままで普及しつつあることを防ぐための個人的な活動の一環として、この12の規則を提唱した。
コッドの認識では、1980年代前半に多くの DBMS 開発企業が、自社の既存の DBMS 製品を、関係に基づいているよう見せかけた偽の RDBMS に改変する傾向が、強くなっていた。 コッドは、特にこうした傾向に対する反論として、この12の規則を考案した。
しかし実際には、コッドの12の規則は非常に厳しい基準であり、データベース言語 SQL のみをデータベースにアクセスするインタフェースとするシステムでさえ、コッドの12の規則のいくつかを満たすことはできていない。
規則 0: システムは、「関係に基づく」「データベース」を「管理するシステム」としての条件を備えていなければならない
システムは関係データベース管理システムとしての条件を備えていなければならない。
すなわちシステムは関係に基づく機能のみを使ってデータベースを管理できければならない。
規則 1: 情報の規則
データベースに格納されるあらゆる情報は、ただ一つの方法で表現されなければならない。
すなわち、表 (table) に含まれる行 (row) のおのおのの列 (column) に含まれる値として表現されなければならない。
規則 2: アクセス保証の規則
あらゆるデータへのアクセスには曖昧さがあってはならない。
この規則は、主キー (primary key) が本質的に必要であることを、本質的な文章で言い替えたものである。
この規則は、データベースに格納されるあらゆるスカラ値には、その値をもつ表の名前と列の名前とその主キーの値を指定することで、論理的に一意にアクセスできなければならないことを、述べている。
規則 3: null値を体系的に扱う
システムは、あらゆる列においてnull値 (もしくは空値) を格納できなければならない。
システムは「欠損値と不適切な値」の表現であるnull値を、体系的に、他の全ての適切な値と区別して扱わなければならない (例えば、数値型のnull値については0や他の実数と区別して、文字列型のnull値については空文字列と区別して、扱わなければならない) 。
この規則は、列のデータ型が何であろうと達成されなければならない。
この規則ではまた、システムはnull値を体系的に扱わなければならないことも、含意している。
規則 4: 関係モデルに基づいた動的なオンラインカタログ
システムは、カタログ (データベースの構造の情報) を、関係モデルに基づいて提供しなければならない。
権限を与えられた利用者は、カタログに対して、データベースのデータにアクセスする方法と同じ要領で、データベース言語を使うことでアクセスできなければならない。
規則 5: 強力な、データを扱う言語の規則
システムは、少なくとも1種類の、関係を扱う言語を提供しなければならない。
その言語は、 線形な構文で (QBE; Query by Example のような2次元の構文ではなく) 、 対話的な使うことも、アプリケーションソフトウェアから使うこともでき、 データ定義 (ビューの定義も含む) 、データ操作 (検索および更新) 、セキュリティおよび整合性制約の定義、トランザクション管理の機能 (begin、commitおよびrollback) を、提供しなければならない。
規則 6: ビュー更新の規則
システムは、理論的に更新可能なビューを、更新できるようにしなければならない。
規則 7: 高水準の挿入、更新、削除
システムは、集合 (複数行) 単位でのデータの挿入、更新、削除の演算機能を提供しなければならない。
これは次のことを意味する。
複数の表、複数の行で構成されるデータベースのデータを、集合単位で検索できる。
検索した集合単位のデータをもとにして、データベースのデータを一度の操作で挿入、更新、削除できなければならない。
1つの表に対して行単位で処理するような必要は無い。
規則 8: 物理的データ独立
データベースの物理的な水準における変更 (ハードウェアやデータの格納方法の変更) をしても、そのデータベースを使うアプリケーションを変更する必要がないようにしなければならない。
規則 9: 論理的データ独立
ビューを使うことで、データベースの論理的な水準における変更 (表や列などの変更) をしても、そのデータベースを使うアプリケーションを変更する必要がないようにすることができなければならない。
規則 10: 整合性の独立
整合性制約を、アプリケーションが関与することなく、定義してカタログに制約情報を格納できなければならない。
必要に応じて整合性制約の変更を、既存のアプリケーションに対する無用な影響を与えること無く、実行できなければならない。
規則 11: 分散の独立
データベースをいくつかの場所に分割して分散した形で構成する場合、データベースの利用者がデータベースの分散を意識せずに利用できなければならない。
次のような場合でも、既存のアプリケーションは問題なく動くようにしなければならない。
これまで集中型の DBMS (データベース管理システム) を使っていて、分散 DBMS に変更する場合。
分散 DBMS で分散して格納していたデータを、再分散配置する場合。
規則 12: 破壊防止の規則
システムが低水準のインタフェース (行単位のアクセスなど) を提供している場合、そのインタフェースを通したアクセスによってシステムが破壊されることが無いようにしなければならない。
システムのセキュリティや整合性制約を迂回したデータベースへのアクセスによってシステムが破壊されることを許してはならない。