マイナーなCREATE文
CREATE ASSERTION
SQL92で標準化された。1つ以上、複数のテーブルに対して制約をかける「表明」を定義する。
実装しているDBMSが少ないため知名度は低いが、DB側で複雑な制限をかけれるため処理速度の改善に繋がるらしい。
ストアドプロシージャとかと同じ理屈か？
（この「表明」と言う考え方はC++などのASSERTチェック等に近いものだと思われる。データ操作時にある条件を判定し、異常である場合はエラーを投げる。)
設定した条件が偽の場合にエラーを発生させることができ、SELECT文を使った複雑な制約を定義することができる。
CREATE ASSERTION 入力値チェック CHECK (NOT EXIST(SELECT * FROM 価格票,限界値 WHERE 価格表.商品コード = 限界値.商品コード AND 価格票.価格 <= 限界値.上限価格))
※表明名が「入力値チェック」、CHECK以降の文が条件である。上記例だと価格票テーブルと限界値テーブルを商品コードで結合して価格が上限価格以下であることを判定している。上限価格以上の価格が設定された場合はエラーを投げる。
CREATE DOMAIN
SQL92で標準化された。ユーザ定義のデータ型を作成する。
実装しているDBMSが少ないため知名度は低いが、DB側で入力値チェックを行えるため処理速度の改善に繋がるらしい。
ASSERTIONと合わせてリファクタリングに使えそう。
CREATE DOMAINをコールしたユーザがそのドメインの管理を行うが、使用に関しては全ユーザが行える。(場合が多い模様。DBMS依存。)
※18〜99までしか値を取らないユーザデータ型「AGE」を作成する。
※条件文で使用する変数名についてはSQL92では未定義?
(PostgreSQLではVALUEだった。というか他のDBMSで例を見つけられなかった。とりあえずPostgreSQLの仕様で例を記載)
三層スキーマ(アーキテクチャ)
ユーザやクライアントプログラムとのI/F
＋
概念化したデータの定義
＋
物理装置(ファイルシステム)へのI/F
をOSの機能とマッピングするソフトウェアがDBMSであると言えるかもしれない。
概念スキーマとか似たような単語がデータモデルのほうでも出てくるので混同しそうになるが、データモデルはモデリングする際の段階、あるいは技法のことなのでこれとは位置付けが違う。別物。
三層スキーマアーキテクチャは以下の3つで構成される。
概念スキーマ
データベースに格納する対象のデータ構造を概念的に定義したもの。
実世界の情報を抽象化した成果物。
すなわち、リレーショナルデータベースなら正規化したテーブルやリレーションシップの構造そのものを指す。
一見論理データモデルと同じ意味の単語に聞こえるが、意味合いとしては別物。
データモデル
データの表現方法をモデル化したもののこと。
三層スキーマアーキテクチャと混同しやすいが実は別物っぽい。
DB設計においては以下の3段階に分類される。
概念データモデル
実社会のデータを抽象化して表現したモデル。
このレベルでは論理データモデルの種類（リレーショナルとかネットワークとか階層とか）は意識しない。
基本的には実社会の事象(リレーション)とその関連(エンティティ)で表現する。
モデリング手法としてはER図が一般的。UMLで書く場合もあるらしい。
論理データモデル
概念データモデルをデータを扱う方式(技術)に落とし込んだモデル。
具体的には概念データモデルから意味的な側面を抽出し、
リレーショナルデータモデルの表現とかオブジェクトモデルの表現とかに落とし込む。
ここでのモデリング手法は適用するデータモデルにより異なる。
例えば、リレーショナルデータモデルの場合だとテーブルとリレーションシップで表現するし、
適用させるデータモデルがオブジェクトモデルであれば、クラスと属性を用いた図で表現したものが論理データモデルとなる。
物理データモデル
論理データモデルの具体的な実装方法を決定するモデル。
難しく言うとデータの永続化を行う方法を決定する。
ぶっちゃけるとDBMSとして何を使うか。MySql使うとかPostgreSQL使うとか。
これを決定することによりデータ型の定義方法、Viewの定義方法、インデックスの設計方法。
果てはパーティションの使い方、CPUの割り振り方。場合によっては性能指標とかロールバック方法とかも決定する。
テクニカルエンジニア(データベース)を受けようと思います。
勉強ログ。
遅いとか言わない。
主に言葉の定義を突き詰めていければいいかな。と。
嘘ついてても怒らないでコメントしてください必死で直します。
