覚えたことを、
つなげてみよう。

DBMS

DBMSがデータベースを管理するソフトウェアです。保存されたデータ自体とは区別します。

• DNS：DNSはドメイン名の名前解決などを担います。
• ブラウザ：ブラウザはWebページを利用するソフトです。
• 主キー：主キーは表の行を識別する項目です。

レコード

一件の注文を表す行がレコードです。

• フィールド：フィールドは注文IDや数量などの列です。
• DBMS：DBMSは管理用ソフトです。
• データ型：データ型は文字列や整数などの値の種類です。

3

データの行数を数えるので3レコードです。見出しは含めません。

• 1：表全体で一件ではありません。
• 4：見出しをレコードに数えません。
• 9：セルの数ではなく行数を数えます。

0や小数など、この数量欄で許さない値を防ぐ

許容する値を定める制約です。入力が現実と一致するかは別に確認が必要です。

• すべての注文の事実確認を不要にする：型や範囲が正しくても注文内容の誤りはあり得ます。
• 顧客を一意に識別する：数量は顧客の識別子ではありません。
• 表を必ず高速化する：速度改善を必ず保証するものではありません。

注文ID

注文IDは注文ごとに異なり、一行を一意に識別します。

• 顧客名：同姓同名や同じ人の再注文を区別できません。
• 数量：同じ数量の注文は複数あります。
• 顧客ID：一人の顧客が複数回注文するため重複します。

よい。この例では外部キーの重複を許す

一対多の関係なので、注文表の外部キーC01は複数行に現れます。

• 主キーなので不可：注文表の主キーは注文IDです。
• 注文IDも同じならよい：注文IDは各注文を識別するため重複できません。
• 顧客表にもC01を2行作る必要がある：顧客表の主キーC01は一行のままです。

行を一意に識別し、NULLを許さない

主キーは重複せず、NULLを許しません。複数列の組合せの場合もあります。

• NULLを必ず一行に許す：主キーにNULLは許しません。
• 同じ値を何行でも許す：重複すると行が一意に決まりません。
• 必ず氏名にする：氏名は同姓同名などがあり、この例の主キーにはしません。

顧客IDの外部キー制約

顧客表への外部キー制約が参照先の存在を確認します。

• 数量の整数型だけ：数量の型では顧客の存在を確認できません。
• 表の表示順：表示順は参照整合性を保証しません。
• 顧客名の文字色：見た目の設定はデータの制約ではありません。

更新の不整合

同じ現在の事実が二通りになり、整合しなくなっています。

• 暗号化：データを暗号で保護する話ではありません。
• 名前解決：ドメイン名の解決ではありません。
• 認証の成功：本人確認の成否とは別です。

顧客表を独立させる

顧客の存在と注文の発生を別の表で表すと、注文なしでも顧客を登録できます。

• 架空の注文を必ず作る：存在しない注文を作るとデータの意味が壊れます。
• 顧客名を数量欄に入れる：数量欄の意味と型に合いません。
• 全顧客を同じIDにする：顧客を区別できなくなります。

依存関係を考えて重複による不整合などを防ぎやすくする

データの意味と依存関係に沿って表を整理します。単純な見た目の分割ではありません。

• 表を必ず一つにまとめる：一つにまとめることが目的ではありません。
• すべての検索を必ず高速化する：速度は処理内容や索引などにも依存します。
• 列を同じ数に分ける：列数をそろえても依存関係が整理されるとは限りません。

過去と現在の事実を区別して扱う

時点の異なる事実は区別します。履歴の値を現在値に揃えると、当時の情報を失います。

• 過去の配送先も必ず上書きする：履歴を残す目的に反します。
• すべての注文を消す：連絡先変更は注文消去の理由ではありません。
• 主キーを削除する：主キーを失うと注文の識別に支障が出ます。

選択

条件に合う行を取り出すので選択です。元データの削除ではありません。

• 射影：射影は列を取り出します。
• 結合：この操作では別の表をつないでいません。
• 削除：結果を取り出しているだけです。

射影

必要な列に着目した操作が射影です。

• 結合：複数の表を関連づける操作ではありません。
• 選択：条件で行を絞る話ではありません。
• 更新：値を書き換えていません。

顧客IDの一致

顧客IDという対応する値で表をつなぎます。表示順には依存しません。

• 上から同じ位置の行：並べ替えだけで対応が変わってしまいます。
• 文字色：見た目は表の関係を保証しません。
• 数量の大きい順：数量の順序は顧客との対応を示しません。

C01とC02の2種類

関係代数の射影では同じ行を重複させないので、C01とC02の2種類です。

• C01だけ：C02も元の表にあります。
• O101、O102、O103：注文IDではなく顧客IDを取り出します。
• C01が2行、C02が1行：この設問は関係代数の射影で、重複するC01をまとめます。

コミット

コミットでトランザクションを確定します。

• ロールバック：未確定の変更を取り消す操作です。
• 射影：必要な列を取り出す操作です。
• 名前解決：DNSなどで行う処理です。

ロールバック

未確定の一連の変更をロールバックし、途中の更新だけを残さないようにします。

• コミット：成功として確定する操作なので目的と逆です。
• 結合：表の対応をつなぐ操作ではありません。
• 顧客表の全削除：無関係な顧客情報を削除する必要はありません。

原子性

一連の処理を全部反映するか、反映しないかとして扱うのが原子性です。

• 耐久性：耐久性は確定した結果を保持する性質です。
• 射影：列を取り出す操作です。
• 正規化：表の依存関係を整理する設計の考え方です。

排他制御や条件付き更新などで同時実行を調整する

適切な同時実行制御と更新結果の確認が必要です。処理をまとめるだけでは不十分な場合があります。

• 画面の文字色だけ変える：表示だけではDB更新の競合を防げません。
• 顧客IDを全員同じにする：顧客を識別できなくなり、競合も解決しません。
• トランザクションと書けば実装に関係なく解決する：分離レベルや更新方法などの設計が必要です。