【ITパスポート練習問題 6.3対応】(2) データの設計

【解説】

正解: 2 エンティティ間の関係

この問題は、データベース設計において広く使われる「E-R図（Entity-Relationship Diagram）」の基本的な構成要素を理解しているかを問うものです。

正解は「エンティティ間の関係」です。E-R図は、「エンティティ（実体）」と呼ばれるデータのまとまり（例：顧客、商品）と、それらが互いにどのようなつながりを持っているかを示す「リレーションシップ（関連）」（例：顧客は商品を注文する）を図式化したものです。

選択肢1の「テーブルのインデックス」や選択肢3の「データベースのバックアップ」は、物理的なデータベースの実装や運用に関する要素であり、E-R図で表現される論理的な構造や関係性とは異なります。

【解説】

正解: 2 データの関連を整理し視覚化するため

この問題は、システム開発の上流工程でなぜE-R図を作成するのか、その目的とメリットを理解しているかを確認するものです。

正解は「データの関連を整理し視覚化するため」です。複雑な業務データを図として可視化することで、開発者と利用者の間でデータ構造の認識を合わせたり、設計の漏れや矛盾を発見しやすくしたりする効果があります。

選択肢1の「データベースのリカバリ手順を記録するため」は運用マニュアルの役割です。選択肢3の「テーブルのパフォーマンスを最適化するため」は、インデックス設計やSQLチューニングの目的であり、E-R図の直接的な目的ではありません。

【解説】

正解: 3 インデックスの設定

この問題は、概念データモデルや論理データモデルとしてのE-R図において、重要な要素とそうでない要素（物理的な詳細）を区別できるかを問うものです。

正解は「インデックスの設定」です。E-R図はあくまで「どのようなデータがあり、どう関連しているか」を示す設計図です。検索を速くするための「インデックス」をどの列に貼るかといった物理的な実装詳細は、E-R図の段階では重要視されません（または記述しません）。

選択肢1の「エンティティの属性（データの項目名など）」や、選択肢2の「エンティティの数」は、E-R図を構成する本質的な要素であり、これらが欠けると正しい設計図になりません。

【解説】

正解: 2 データを一意に識別するため

この問題は、システム開発における「コード設計（コード化）」の根本的な目的を理解しているかを問うものです。コードとは、商品コードや社員番号などのことです。

正解は「データを一意に識別するため」です。名前や商品名などの文字情報は同姓同名や表記揺れがあるため、コンピュータで正確に識別・処理するには不向きです。重複しないユニークな「コード」を割り振ることで、データを確実に見分けることができます。

選択肢1の「データの誤りを検出するため」はチェックディジットなどの機能ですが、コード設計全体の主目的ではありません。選択肢3の「テーブルのサイズを削減するため」も副次的な効果に過ぎません。

【解説】

正解: 3 コードの物理配置

この問題は、良いコードを設計するために必要な要件（コードの設計指針）を理解しているかを確認するものです。

適切でない要素は「コードの物理配置」です。コード自体がデータベースのディスク上のどこに保存されるかといった物理的な配置は、DBMSが管理することであり、コードの体系（桁数や文字種など）を設計する際には考慮する必要はありません。

選択肢1の「コードの一意性（重複がないこと）」は最も重要な要件です。選択肢2の「コードの可読性（人間が見てわかりやすいか）」も、運用ミスを防ぐために考慮すべき重要なポイントです。

【解説】

正解: 1 リレーショナル設計

この問題は、コード設計において一般的に考慮される手法やアプローチについての知識を問うものです。

正解は「リレーショナル設計」です。これはデータベース設計の手法ですが、コード設計においても、親コードと子コードの関連性（例：都道府県コードと市区町村コード）など、データ間の関係性を考慮して体系を作るという意味で関連が深いです。

選択肢2の「階層型設計」もコード体系（大分類・中分類・小分類など）としては使われますが、現代のシステム開発ではリレーショナルデータベースが主流であるため、リレーショナルな観点での設計が一般的です。選択肢3の「セマンティックデザイン」はWebデザインなどの分野で使われる用語です。

【解説】

正解: 2 レコード内の個々のデータ項目を管理するため

この問題は、データベースの基本構造である「フィールド（列、カラム）」の定義と役割を理解しているかを問うものです。

正解は「レコード内の個々のデータ項目を管理するため」です。例えば「社員」テーブルにおいて、「社員番号」「氏名」「入社日」といった一つ一つの項目がフィールドに当たります。フィールドはデータの属性を定義する最小単位です。

選択肢1の「データの一意性を確保するため」は主キーの役割です。選択肢3の「テーブル間の関係を定義するため」は外部キーの役割です。

【解説】

正解: 2 データの内容

この問題は、フィールドの設計において最も重要となる「データ型（数値型、文字列型、日付型など）」の決定要因を理解しているかを確認するものです。

正解は「データの内容」です。そのフィールドに何が入るのか（金額なのか、名前なのか、日付なのか）によって、適切なデータ型が決まります。適切な型を選ぶことで、データの整合性を保ち、無駄な容量を省くことができます。

選択肢1の「テーブルのサイズ」や選択肢3の「データの一意性」は、データ型を決定する直接的な要因ではありません。

【解説】

正解: 3 エンティティ

この問題は、データベース用語の階層構造や同義語の関係を正しく整理できているかを問うものです。

関連しない概念は「エンティティ」です。エンティティは「実体」という意味で、データベース設計では「テーブル」全体に相当する概念です。一方、フィールドはテーブルの中の構成要素（列）です。

選択肢1の「カラム」はフィールドの別名（列）であり、同じ意味で使われます。選択肢2の「セル」は、レコード（行）とフィールド（列）が交差する、データが格納されるマス目のことであり、フィールドと密接に関連します。

【解説】

正解: 2 データベース内の一つの行

この問題は、リレーショナルデータベースにおける「レコード（行、ロー）」の定義を理解しているかを問うものです。

正解は「データベース内の一つの行」です。テーブルの中で、1件分のデータ（例：特定の社員1人分の全情報）のまとまりを指します。

選択肢1の「データベース内の列」はフィールドのことです。選択肢3の「データベースの全体構造」はスキーマなどのことです。

【解説】

正解: 3 テーブルのフィールドの値

この問題は、レコードの実体として何が格納されているか、その構成要素を理解しているかを確認するものです。

正解は「テーブルのフィールドの値」です。1つのレコードは、そのテーブルに定義された各フィールド（氏名、年齢、住所など）に対応する具体的な値（「田中」「30歳」「東京」など）の集合で構成されています。

選択肢1の「テーブルのインデックス」や選択肢2の「テーブルのスキーマ（構造定義）」は、データそのものではなく、データを管理するための付加情報や定義情報です。

【解説】

正解: 1 レコードの追加

この問題は、レコードに対して行うことができる基本的なデータベース操作（CRUD）を理解しているかを問うものです。

正解は「レコードの追加（INSERT）」です。データベース操作の基本である4つの操作（作成、読み取り、更新、削除）のうちの一つで、新しい行をテーブルに挿入する操作です。

選択肢2の「テーブルの結合」はデータの参照（読み取り）時に行う操作であり、レコードそのものに対する操作ではありません。選択肢3の「インデックスの生成」はデータベース構造に対する定義変更操作（DDL）です。

【解説】

正解: 2 データの論理的な整理

この問題は、データベースシステムにおいて「ファイル」という概念がどのように扱われるか、その役割を問うものです。

正解は「データの論理的な整理」です。データベースの実体はOS上のファイルとして保存されますが、データベース管理システム（DBMS）はこれを論理的な単位（表領域やデータファイルなど）として管理・整理し、ユーザーが物理的なディスク構造を意識せずに使えるようにしています。

選択肢1の「データのアクセス制御」はDBMSの権限管理機能です。選択肢3の「データのバックアップ」は運用管理機能の一つです。

【解説】

正解: 1 レコードの集合

この問題は、データベースファイルの中身が論理的に何で構成されているかを理解しているかを確認するものです。

正解は「レコードの集合」です。データベースのデータファイルには、テーブルに格納された多数のレコード（行データ）が集まって保存されています。

選択肢2の「インデックスの設定」はインデックスファイルなどに保存されることが一般的です。選択肢3の「ユーザー権限のリスト」はシステムカタログ（データディクショナリ）などの管理領域に保存されます。

【解説】

正解: 3 データの分割

この問題は、大規模なデータベースを効率的に管理するための手法についての知識を問うものです。

正解は「データの分割（パーティショニングなど）」です。巨大なテーブルを単一のファイルで管理するとパフォーマンスが低下するため、日付や地域などの条件で複数のファイルに分割して保存・管理する手法がとられます。

選択肢1の「データの圧縮」も機能としてありますが、管理手法の「主な」ものというよりは補助機能です。選択肢2の「データのカプセル化」はオブジェクト指向プログラミングの概念です。

【解説】

正解: 1 データの集合体

この問題は、リレーショナルデータベースにおける「テーブル（表）」の本質的な意味を理解しているかを問うものです。

正解は「データの集合体」です。テーブルは、同じ種類のデータ（例：すべての商品データ）を集めて整理した器であり、データの集合体そのものを表します。

選択肢2の「データの操作手順」はプログラムやクエリのことです。選択肢3の「データのバックアップ戦略」は運用計画のことです。

【解説】

正解: 2 特定のデータ項目を表す

この問題は、テーブルを構成する「列（カラム）」の役割について、行（レコード）との違いを明確に理解しているかを確認するものです。

正解は「特定のデータ項目を表す」です。列は「商品名」「単価」といったデータの属性（項目）を定義します。列が決まることで、そのテーブルでどのような情報を管理するかが決まります。

選択肢1の「データの挿入順序を管理する」ことは列の役割ではありません（RDBMSでは順序は保証されません）。選択肢3の「テーブルのバックアップを管理する」も列の役割ではありません。

【解説】

正解: 1 テーブルの結合

この問題は、リレーショナルデータベースの最大の特徴である、複数のテーブルを使った操作について理解しているかを問うものです。

正解は「テーブルの結合（JOIN）」です。正規化によって分割された複数のテーブル（例：売上テーブルと商品テーブル）を、共通のキーを使って結びつけ、あたかも一つの表のように扱ってデータを取り出す操作です。

選択肢2の「データの正規化」は設計段階の作業です。選択肢3の「クエリの実行」はデータベースに対する命令全般を指す用語です。

【解説】

正解: 2 テーブル内で一意である

この問題は、データベース設計の要となる「主キー（Primary Key）」の最も重要な制約（ルール）を理解しているかを確認するものです。

正解は「テーブル内で一意である」です。主キーに設定された列の値は、そのテーブルの中で重複することが許されません。これにより、特定の1行（レコード）を確実に特定することができます。

選択肢1の「重複した値を許容する」は主キーの定義に反します。選択肢3の「任意の列に設定できる」は誤りで、一意性があり、かつNULL（空値）を含まない列である必要があります。

【解説】

正解: 3 任意の列を主キーとして選定する

この問題は、主キーを設計する際の適切な判断基準（ベストプラクティス）を理解しているかを問うものです。

不適切な指針は「任意の列を主キーとして選定する」です。主キーはレコードを一意に識別するための重要な列であり、重複の可能性がある列や、値が頻繁に変わる列、NULLが入る列などは主キーとして不適切です。慎重に選定する必要があります。

選択肢1の「自然キーを使用する（既存のコードなどを使う）」や、選択肢2の「必要に応じて複合キーを使用する（複数の列を組み合わせて主キーにする）」は、一般的な設計手法です。

【解説】

正解: 1 ユニーク制約

この問題は、主キーを設定するとデータベースシステム側で自動的にどのような制約（ルール）が適用されるかを知っているかを問うものです。

正解は「ユニーク制約（一意性制約）」です。主キーはデータを一意に識別するためのものなので、重複する値を入力しようとするとエラーになるよう、システムが強制力を持ちます（同時にNOT NULL制約も適用されます）。

選択肢2の「チェック制約」はデータの値の範囲などを制限するものです。選択肢3の「外部キー制約」は他のテーブルとの整合性を保つためのものです。

【解説】

正解: 2 テーブル間の関係を定義する

この問題は、リレーショナルデータベースにおいてテーブル同士をつなぐ役割を持つ「外部キー（Foreign Key）」の機能を理解しているかを確認するものです。

正解は「テーブル間の関係を定義する」です。あるテーブルの列に、別のテーブルの主キーの値を格納することで、「このデータはあちらのデータの詳細である」といった親子関係や参照関係を定義します。

選択肢1の「データの一意性を保証する」は主キーやユニーク制約の役割です（外部キー自体は重複しても構いません）。選択肢3の「インデックスを生成する」は必須ではありません（パフォーマンス向上のために作成することはあります）。

【解説】

正解: 3 テーブルのバックアップスケジュール

この問題は、外部キー制約を設定する際に、技術的に整合性をとるために必要な条件を理解しているかを問うものです。

考慮すべきでない（関係のない）要素は「テーブルのバックアップスケジュール」です。これは運用の話であり、テーブル設計や制約の設定とは無関係です。

選択肢1の「参照するテーブルの主キー」は、外部キーがどこを指すのかを指定するために必須です。選択肢2の「外部キーを設定する列のデータ型」も、参照先の主キーと同じ型でなければならないため、重要な考慮事項です。

【解説】

正解: 2 操作が失敗する

この問題は、外部キー制約が存在することで、データの不整合を防ぐガード機能がどのように働くか（参照整合性）を理解しているかを問うものです。

正解は「操作が失敗する（エラーになる）」です。例えば、親テーブル（商品マスタ）に存在しない商品コードを子テーブル（売上データ）に入力しようとしたり、子テーブルで使われている親データを削除しようとしたりすると、データベースは整合性を守るためにその操作を拒否します。

選択肢1の「レコードが自動的に修正される」ことは通常ありません（設定により削除に連動させる「カスケード」などはありますが、勝手に修正されるわけではありません）。選択肢3の「別のテーブルにデータが移動される」こともありません。

【解説】

正解: 1 データの検索を効率化する

この問題は、データベースのパフォーマンスチューニングにおいて最も基本的な技術である「インデックス（索引）」の目的を理解しているかを確認するものです。

正解は「データの検索を効率化する」です。本の巻末にある索引と同じように、データの在り処を整理したリスト（インデックス）を作成しておくことで、大量のデータの中から目的の行を高速に見つけ出すことができます。

選択肢2の「テーブルのサイズを削減する」は誤りで、インデックスデータを作成する分、逆にサイズは増加します。選択肢3の「データの一意性を保証する」はユニークインデックスの機能ですが、インデックス全般の「主な役割」としては検索の高速化が第一です。

【解説】

正解: 2 データの更新速度の向上

この問題は、インデックスのメリットだけでなく、デメリット（トレードオフ）についても正しく理解しているかを問うものです。

適切でない（誤っている）影響は「データの更新速度の向上」です。インデックスを作成すると、データの追加・更新・削除を行うたびに、インデックス側の情報も書き換える処理が発生します。そのため、検索速度は上がりますが、更新処理の速度は逆に低下します。

選択肢1の「データの検索速度の向上」はインデックスの主目的です。選択肢3の「データベースサイズの増加」は、インデックス情報の分だけディスク容量を消費するため、正しい記述です。

【解説】

正解: 2 必要な列にのみインデックスを作成する

この問題は、インデックスの効果的な運用方法について、パフォーマンスの観点から適切な判断ができるかを確認するものです。

正解は「必要な列にのみインデックスを作成する」です。検索条件（WHERE句）や結合条件（JOIN句）で頻繁に使われる列、並べ替え（ORDER BY）に使われる列などに絞って作成するのが定石です。

選択肢1の「すべての列にインデックスを作成する」は、更新処理が極端に遅くなり、ディスク容量も圧迫するため推奨されません。選択肢3の「インデックスを使用しない」は、データ量が増えた際に検索が著しく遅くなるため、適切な最適化とは言えません。