本日は関係スキーマのうち、試験問題の実例・正規形について書く。
今までの振り返り（再掲）
- データベーススペシャリスト試験の学習優先順位。①論理設計・②SQL・③物理設計の順。論理設計は午後2で1題出て、午後1でもコンパクトになったものが出るし、データベース設計の入り口でもあるから。
- ①論理設計を初めて学ぶとき。午後2試験の最初に「①-1 ER図の表記ルール」「①-2 関係スキーマの表記ルール」が出てくる。まずこの2つを理解すること。次に実際に午後2問題を見て感覚を掴むこと。最後に60点以上目標に解き方のコツを体得すること。（できれば、各業種のパターンに慣れておくとなお良い）
- ①-1 ER図について簡潔におさらい。データのまとまりがテーブル。テーブルは集合（意味のあるまとまり）であり関数（入力に対し一意の出力）。 テーブル間のつながりを図示したものがER図。つながりは1:1か1:多。都合にあわせ分類するときサブタイプという概念を用いることも。詳しくは4月25日、4月26日挑戦ログに記載
- 本日は①-2 関係スキーマについて書く。
関係スキーマについて（再掲）
- 午後2試験の論理設計問題は、本文・ER図・関係スキーマの3つから構成
- 関係スキーマはテーブルの属性とその関係を箇条書きで示したもの
- 基本的には本文・ER図の鏡像なので、重要な概念は変わらない
- テキストに沿って、関数従属性・キー・正規化についておさらいしていく
試験問題の実例
- 関係図を読み、候補キーを列挙させる問題。午後１試験の定番の時期があり、令和3年復活。抑えるルールは「関係図における一意性とは、→の元が一つ決まれば、→の先も一つに決まること」と「候補キーは、一意性を確保するためのミニマムな組み合わせ」であること。つまり関係図の→の始点を全て洗い出し、全ての属性が一意に決まるか見ていけば良い。なお、↔の場合は属性の置き換えが発生する。
- 主キーや外部キーを示す問題。毎年必ず、午前2・午後1・午後2で出題される。主キーや外部キーはかなりの部分名称でアテはつく。あとは問題文中の記述からそれが正しいか確認する。
正規形について
- 正規形の基本は4月24日挑戦ログで整理のとおり。
- 少し専門用語を使うと、更新時異常が発生しないように、情報無損失分解すること。
- 更新時異常とは。かみ砕けば、「ごった煮テーブルだと情報量が多すぎて、情報の追加・修正・削除が大変」だということ。
- 情報無損失分解とは。かみ砕けば、「分解と組み立てを繰り返せる、復元性がある」こと。
- 試験問題の実例。あるテーブルについて第○正規形である根拠を説明する問題。ひな形に沿って文章を作れば良い。
- －第１正規形：全ての属性が単一値で、候補キー｛A,B｝の一部であるBに非キー属性のCが部分関数従属するため
- －第２正規形：全ての属性が単一値で、候補キーからの部分関数従属がなく、推移的関数従属性A→B→Cがあるため
- －第３正規形：全ての属性が単一値で、候補キーからの部分関数従属がなく、候補キーからの推移的関数従属性もないため
- なお、実務面・情報処理技術者試験面のいずれにおいても、第３正規形にとどめておくのが基本。
更新時異常について
- 「ごった煮テーブルだと情報量が多すぎて、情報の追加・修正・削除が大変」だということ。
- たとえば第１正規形である「顧客ID（主キー）、注文連番（主キー）、注文日、顧客名」のテーブル。顧客IDから顧客名への部分関数従属がある。
- このとき何が困るか。
- －挿入のとき、挿入できない。たとえば「新しい顧客ID・顧客名」を追加したいとき、注文は発生してないのでNULLだが、主キーはNULLを許容していないため登録できない
- －修正のとき、整合性が失われるリスクがある。たとえば「顧客ID・顧客名」が間違っていたとき、テーブル内の全ての情報を同時に修正しなければならない
- －削除のとき、情報が失われるリスクがある。たとえば顧客Cさんからの注文が1件だけだったして、その注文情報（行）を削除するとCさんの顧客名まで消えてしまう
考察
- あらためて、情報処理試験はITの筋トレのようなものだと感じる。筋トレは基礎体力向上・脳の活性化・自己肯定感向上などに役立つからだ。たとえば「データベース活用の基礎」は経済データ分析やビジネスデータ分析に応用できる。トレーニングと実践を続け「使えるチカラ」を身につけるようにしていきたい。
参考書籍
- データベーススペシャリスト2022年版/三好康之/翔泳社 ※この記事は2章P305-P350を整理したもの
コメント