スポンサーリンク
TechGO（テックゴー）

【応用情報技術者試験】データベースを学ぼう！　　　　　~第1章~データベースの基礎

データベース（DB）は、特定のルールに基づいて整理・構造化されたデータの集合体であり、コンピュータ上で電子的に管理されます。大量のデータを高速に検索・追加・更新・削除できるため、ビジネスの顧客情報や在庫管理などに必須の技術です。主にリレーショナルデータベース（RDB）やNoSQLが使われ、DBMS（データベース管理システム）で運用されます。

データベースの主な特徴とメリット

  • 効率的なデータ管理: 大量のデータを分類し、検索や分析を高速に行える。
  • データの共有と一元化: 複数ユーザーが同時に最新のデータにアクセスできる。
  • データの整合性と安全性: 重複や不整合を防ぎ、セキュリティや障害復旧機能を備える。
  • 構造化データ: 行と列（テーブル）で整理され、関係性を持たせた管理が得意。

画像参照：https://business.ntt-east.co.jp/content/cloudsolution/column-386.html

データベースの目的

データベース（DB）の主な目的は、膨大な情報を構造化して安全に蓄積し、必要なデータを迅速に検索・共有・活用できるようにすることです。データの重複や矛盾（不整合）を防ぎ、複数人での同時アクセスや、セキュリティを確保しながら効率的なデータ管理を実現する基盤となります。 

データベースの具体的な目的とメリットは以下の通りです。

主要な目的

  • データの体系的な整理と保存: 関連するデータをルールに基づき整理し、大量のデータも整然と保管する。
  • 高速な検索と抽出: 必要な情報を瞬時に見つけ出し、業務効率を向上させる。
  • 複数人での同時共有・編集: 複数ユーザーが同じデータを同時に閲覧・更新でき、業務の属人化を防ぐ。
  • データの安全性・一貫性の維持: 誤入力を防ぎ（データ整合性）、不正アクセスやデータ破損のリスクを低減する。
  • データ分析と活用: 蓄積されたデータを基に、迅速かつ高精度な意思決定をサポートする。 

3層スキーマアーキテクチャー

3層スキーマアーキテクチャは、データベースの構造を「外部」「概念」「内部」の3つの階層に分けて定義する設計モデルです。ANSI/SPARCが提唱したこの仕組みにより、物理的なデータの保存形式を変更しても、ユーザーやアプリケーション側に影響を与えない「データの独立性」を確保し、管理・運用を容易にします。 

3層の構成要素

  • 外部スキーマ (External Schema): ユーザーやアプリケーションから見た、カスタマイズされたデータの見え方（ビュー）。
  • 概念スキーマ (Conceptual Schema): データベース全体の論理的なデータ構造や整合性、関連性（テーブル定義やER図）。
  • 内部スキーマ (Internal Schema): データを物理的にストレージにどう格納するか（ファイル編成、インデックス）。 

目的とメリット

  • データ独立性の確保: 物理的格納構造の変更（内部）が論理構造（概念）やアプリケーション（外部）に影響しない、あるいは論理構造の変更がアプリケーションに影響しない。
  • 保守性の向上: データベースの改善や拡張が、他の層に影響を及ぼさずに容易にできる。
  • セキュリティ強化: 外部スキーマを分けることで、ユーザーごとに必要なデータのみを表示できる。

関係データベース

関係データベース（RDB：Relational Database）は、データを「顧客テーブル」「商品テーブル」のような行と列を持つ表形式（テーブル）で管理し、複数の表を「顧客ID」などの共通項目で関連付けて（リレーションを持たせて）柔軟に操作・管理するデータベース方式です。データの整合性と正確性が高く、現代のデータベースの主流です。 

基本構成と特徴

  • 表形式（テーブル）管理: データを2次元の表（行=レコード、列=フィールド/属性）で構成し、人間にとって理解しやすい構造になっています。
  • リレーション（関係）: 複数のテーブルを関連させて一元管理します。
  • SQLによる操作: データの検索、追加、削除、更新には、SQL（Structured Query Language）という言語を使用します。
  • データの整合性: 参照整合性などのルールにより、データの一貫性を保ち、正しい情報を維持します。
  • 代表的なRDBMS: 関係データベースを管理するシステム（RDBMS）には、Oracle Database、MySQL、PostgreSQL、SQL Server、Microsoft Accessなどがあります。 

メリットとデメリット

  • メリット:
    • データ構造の変更が比較的容易（行単位の追加/削除）。
    • 複雑なクエリ（データ抽出・結合）が迅速に処理可能。
    • データの整合性と正確性が維持されやすい。
  • デメリット:
    • 複雑な関係性を持つ大規模データを扱うと、サーバーへの負荷が大きくなる傾向がある。 

代表的なRDBMS製品

  • Oracle Database
  • Microsoft SQL Server
  • PostgreSQL
  • MySQL
  • IBM DB2
  • Google Cloud SQL / Cloud Spanner 

1970年にエドガー・F・コッド（Edgar F. Codd）博士によって提案された「リレーショナル理論」が基盤となっています。

重要用語（RDB）

主キー

主キー（プライマリキー）は、リレーショナルデータベース（RDB）のテーブルにおいて、各レコード（行）を1つに特定するための一意な識別子です。重複やNULL（空値）は許されず、データの整合性保持や効率的な検索に不可欠な設計要素であり、通常は従業員IDや通し番号などが指定されます。 

詳細なポイント

  • 一意性（ユニーク）: テーブル内の全レコードで値が異なる必要がある。
  • 非NULL性: 空の値を設定できない。
  • 用途: 特定の行を検索、更新、削除する際に使用される。また、他のテーブルからこの値を参照することで関係性（リレーション）を定義する。
  • 設定: 1つのテーブルに1つの主キーが基本だが、複数の列の組み合わせ（複合主キー）も可能。
  • 候補キー: 主キーとして定義できる複数の候補のうち、1つが選ばれる。 

データベース設計において、主キーの適切な選択はデータの正確な管理において非常に重要です。

外部キー

外部キー（Foreign Key）は、リレーショナルデータベース（RDB）で2つのテーブルを関連付け、データの整合性を保つための「しるし」となる列です。親テーブルの主キーを参照し、子テーブルに存在しないデータが入るのを防ぐ制約（外部キー制約）として機能し、正確なデータ管理に不可欠です。 

概要と特徴

  • 定義: あるテーブル（子）の列が、別のテーブル（親）の主キーを参照する関係。
  • 役割: データの不整合（存在しない親IDを子テーブルに登録するなど）を防ぐ。
  • 主な制約: 親テーブルのデータ削除・更新時に、子テーブルのデータを自動削除（CASCADE）したり、削除を禁止（RESTRICT）したりできる。
  • 設定方法: SQLの FOREIGN KEY 句を使用する。 

メリット

  1. データの整合性: 親テーブルに存在しない値が子テーブルに登録されることを防ぐ。
  2. データの一貫性: 親データを変更・削除した際に、子データも追随して変更・削除が可能。
  3. 効率的なデータ構造: データを複数のテーブルに分割して正規化でき、重複を避ける。 

具体的な使用例

「従業員テーブル（子）」と「部署テーブル（親）」がある場合。

  • 部署テーブル: 部署ID(主キー), 部署名
  • 従業員テーブル: 従業員ID, 氏名, 部署ID(外部キー) 

従業員テーブルの「部署ID」に、部署テーブルに存在しない「99」という値を入れようとするとエラーとなり、データベースが整合性を守ります。

ビュー

ビュー（View）は、1つ以上の実テーブルからデータを抽出・結合し、名前を付けた仮想的なテーブルです。物理的なデータは持たず、SELECTクエリを保存して利用する仕組みで、複雑なクエリの簡素化やセキュリティ目的（特定列のみ表示）で多用されます。 

特徴とメリット

  • 仮想テーブル: ビュー自体はデータを保持しない（SELECT結果を都度表示）。
  • 複雑な処理を簡素化: 複数テーブルの結合（JOIN）やデータ集計（SUM/AVG等）を予めビューにしておき、SQLを単純化できる。
  • セキュリティと制限: 全データではなく、特定の列や行だけを見せることでアクセス制御を行う。
  • テーブル構成変更の隠蔽: 実テーブルの列名を変更しても、ビュー定義を更新すれば、ビューを使うアプリケーション側を修正せずに済む。 

定義方法（SQL例）

CREATE VIEW 営業部社員ビュー AS
SELECT 社員ID, 名前, 部署名
FROM 社員テーブル
WHERE 部署名 = '営業部';

上記作成後、SELECT * FROM 営業部社員ビュー で利用可能。 

注意点とデメリット

  • パフォーマンス: ビューのSELECTが遅いと、結果を表示するビューも遅くなる。
  • 更新の制限: ビュー経由でのデータ更新（INSERT/UPDATE）は、GROUP BYや複雑な結合がある場合に制限される。
  • マテリアライズドビューとの違い: データを持つ実体化されたビュー（Materialized View）とは異なる。 

ビューは、データ分析の集計処理や、画面ごとに表示する項目を分ける開発環境で特に有効です。

キーバリューストア

キーバリューストア（KVS）は、一意な「キー」と「値（バリュー）」のペアでデータを保存する、シンプルで高速なNoSQLデータベースです。辞書や連想配列のように機能し、スキーマ定義が不要で、高速な読み書きと高い水平スケーラビリティを実現するため、キャッシュや大規模データ処理に最適です。

主な特徴

  • シンプルなデータ構造: {"Key": "Value"} のペアのみ。
  • NoSQL: テーブル形式（RDB）ではなく、スキーマ定義が不要。
  • 超高速: キーによる直接アクセスにより、データの検索や保存が極めて高速。
  • 高い柔軟性: 値には画像、バイナリファイル、JSONなど、様々なデータを格納可能。
  • スケーラビリティ: データを複数のサーバに分散（シャーディング）させることで、容量と処理能力を容易に拡張可能。

主な用途

  • キャッシュ (Cache): Redis や Amazon ElastiCache などを利用し、DB負荷を軽減。
  • セッション管理: Webアプリケーションにおけるユーザーセッション情報。
  • プロファイル情報: ユーザー設定やプロフィール。
  • リアルタイム・ビッグデータ: 大量のデータを短時間で処理する用途。 

代表的なKVS製品

  • Redis: 高速なインメモリKVS。
  • DynamoDB: AWSが提供するフルマネージド型NoSQL。
  • Riak, Voldemort: 分散型KVS。

RDBとの違い

特徴 RDB (リレーショナルデータベース)KVS (キーバリューストア)
データ構造表形式（行・列）キーと値のペア
スキーマ事前に定義が必要不要（柔軟）
クエリSQL（複雑な検索が可能）キーによる直接アクセス（単純）
処理速度中～高超高速
スケーリング垂直（サーバー強化）水平（サーバー追加）

メリットと注意点

  • メリット: 高いパフォーマンス、拡張性、柔軟なデータ形式。
  • 注意点: 複雑なクエリ（JOINなど）や範囲検索は苦手。値を直接検索したりフィルタリングしたりすることはできない。

コメント