1. データベース方式

(1) データベース

データベースの種類、3層スキーマ、データモデルについて学びます。

① データベースの種類と特徴
1. 関係データベース (RDB: Relational Database) 最重要

データを「表(テーブル)」形式で管理します。
現在のシステム開発で最も主流なデータベースです。
操作にはSQLという言語を使います。

2. 階層型データベース

データを「木(ツリー)構造」で管理します。
会社の組織図のように、親データと子データが「1対多」の関係になります。
検索は速いですが、柔軟な変更が苦手です。

3. ネットワーク型データベース

データを「網(ネットワーク)構造」で管理します。
親と子が「多対多」の関係を持つことができ、複雑な関係を表現できます。

NoSQL (Not only SQL)
RDB以外のデータベースの総称。ビッグデータ処理などで使われる「キーバリューストア (KVS)」などが有名です。
② 3層スキーマアーキテクチャ

データベースを「利用者」「設計者」「物理的な保存」の3つの視点(層)に分けて管理する考え方です。
これらを分けることで、例えば「ハードディスクを交換したり保存形式を変えたりしても(内部スキーマの変更)、利用者が見ている画面やプログラム(外部スキーマ)は書き換えなくて済む」といったデータの独立性を保つことができます。

外部スキーマ
利用者からの見た目

ユーザーやプログラムが必要とするデータの定義。
例:画面上の入力フォーム、帳票、ビュー(View)など。

概念スキーマ
論理的なデータ構造

データベース全体の定義。データの要素や関係性。
例:テーブル定義(列の名前や型)、E-R図。
※一般的に「スキーマ」と言うとこれを指します。

内部スキーマ
物理的な格納方法

データが記憶装置(ディスク)にどう記録されるか。
例:ファイル形式、インデックスの配置、データの圧縮など。

④ 関係モデル(Relational Model)

関係データベースの基礎となっている考え方(データモデル)です。
数学的な理論に基づいていますが、直感的には「すべてのデータを2次元の表(テーブル)で表現する」というシンプルなルールです。

なぜ「関係」モデル?

ここでいう「関係(リレーション)」とは、「表(テーブル)」のことです。
「データとデータの関係性」という意味ではなく、数学用語で「行と列の集まり」をリレーションと呼ぶことに由来しています。

< 顧客テーブル(リレーション)のイメージ >
顧客ID 氏名 住所 電話番号
001 山田 太郎 東京都... 090-xxxx...
002 佐藤 花子 大阪府... 080-xxxx...
003 鈴木 一郎 北海道... 070-xxxx...
縦の並び 列(属性 / カラム):項目を表す
横の並び 行(レコード / タプル):データ1件分を表す
重なり フィールド(実現値):行と列が交差する1つのデータ
用語の対応(試験によく出ます!)
一般的な呼び方 関係モデルでの専門用語 説明
表 (Table) 関係 (Relation) データの集まり全体。
行 (Row) / レコード タプル (Tuple) / 組 データ1件分。横の並び。
上の例では「佐藤花子さん」の1行分。
列 (Column) / カラム 属性 (Attribute) データの項目。縦の並び。
上の例では「氏名」や「住所」。
定義域(ドメイン)
ある属性(列)に入ることが許される「値の範囲」や「型」のこと。
例:「性別」列なら {男, 女, その他}、「年齢」列なら 0以上の整数、など。

(2) データベース管理システム (DBMS)

データベース(ただのデータの集まり)を、人間やプログラムが使いやすく、安全に管理するためのソフトウェア(ミドルウェア)です。
DataBase Management System の略です。

例えるなら「図書館の司書さん」

本(データ)が乱雑に置かれているだけでは、探すのが大変ですし、誰かが勝手に持ち出してしまうかもしれません。
司書さん(DBMS)がいることで、「この本はどこ?(検索)」「新しい本を登録して(登録)」「貸出中だから待って(排他制御)」といったやり取りがスムーズかつ安全に行えます。

DBMSの主な3つの機能
定義機能

「どんなデータを入れるか」という枠組み(スキーマ)を決めて作成する機能。
(例:本棚を用意する)

操作機能

データの検索、追加、更新、削除を行う機能。SQLなどを使います。
(例:本を探す、しまう)

制御機能

データの整合性を保ったり、壊れた時に復旧したり、アクセス権を管理したりする機能。
(例:貸出管理、本の修復)

代表的なDBMS製品
商用(有償)
  • Oracle Database
    オラクル社製。世界シェアNo.1。大規模システムで信頼性が高い。
  • Microsoft SQL Server
    マイクロソフト社製。Windows環境との親和性が高く、操作画面が充実している。
オープンソース(OSS/無償)
  • MySQL / MariaDB
    Webシステムでの採用実績が多く、世界的に普及している。
  • PostgreSQL
    機能が豊富で、複雑な処理にも強く、商用DBに迫る性能を持つ。
個人や小規模な利用では、Microsoft Officeに含まれる Microsoft Access や、アプリに組み込んで使う軽量な SQLite なども使われます。

過去問演習(データベース方式)

平成27年春期 問26

DBMSが,3層スキーマアーキテクチャを採用する目的として,適切なものはどれか。

  • 関係演算によって元の表から新たな表を導出し,それが実在しているように見せる。
  • 対話的に使われるSQL文を,アプリケーションプログラムからも使えるようにする。
  • データの物理的な格納構造を変更しても,アプリケーションプログラムに影響が及ばないようにする。
  • プログラム言語を限定して,アプリケーションプログラムとDBMSを緊密に結合する。
令和2年免除 問26

関係モデルとその実装である関係データベースの対応に関する記述のうち,適切なものはどれか。

  • 関係は,表に対応付けられる。
  • 属性も列も,左から右に順序付けられる。
  • タプルも行も,ともに重複しない。
  • 定義域は,文字型又は文字列型に対応付けられる。
平成30年春期 問27

DBMSが提供する機能のうち,データ機密保護を実現する手段はどれか。

  • 一連の処理を論理的単位としてまとめたトランザクションを管理する。
  • データに対するユーザーのアクセス権限を管理する。
  • データを更新するときに参照制約をチェックする。
  • データを更新する前に専有ロックをかける。

2. データベース設計

(1) データ分析

業務に必要なデータを洗い出し、整理します。

(2) データベースの設計

① 概念設計 (E-R図)

エンティティ(実体)リレーションシップ(関連)を使ってデータの構造を図示したものです。

エンティティ (Entity)
顧客

管理対象となるデータのまとまり(四角で表す)。

リレーションシップ (Relationship)
顧客
1
注文

エンティティ同士の関係(線で結ぶ)。
1対1、1対多、多対多がある。

② 論理設計(主キー・外部キー)

RDBなどの特定のモデルに合わせた設計です。ここでテーブルの定義やキーの設定を行います。

主キー(Primary Key)

表の中の行(レコード)を一意に識別するための列です。
データの「背番号」や「マイナンバー」のようなものです。
「主キーが決まれば、データが必ず1行に特定できる」という性質を持っています。

なぜ「名前」を主キーにしてはいけないの?
悪い例:名前を主キーにした表
氏名(PK?)住所
田中 健東京都...
田中 健大阪府...

区別できない!

同姓同名の人がいると、システムはどちらの「田中さん」か判断できません。
「大阪の田中さんを削除して」と命令しても、誤って東京の田中さんを消してしまう恐れがあります。
主キーは「絶対に被らない」必要があります。

「ID」なら大丈夫!
良い例:IDを主キーにした表
社員ID(PK)氏名住所
001田中 健東京都...
002田中 健大阪府...

区別できる!

「社員ID: 001の田中さん」「社員ID: 002の田中さん」として管理すれば、同姓同名でも別人として扱えます。
このように、現実世界で重複する可能性がある項目(名前、電話番号など)ではなく、システム専用の「ID(コード)」を主キーにするのが一般的です。

主キーの2つの絶対ルール
一意性制約 (Unique)
値が重複してはいけない

もし同じ「社員番号」の人が2人いたら、給料を振り込むときにどちらに振り込めばいいかわからなくなってしまいます。
だから、主キーは全員バラバラの値でなければなりません。

非NULL制約 (Not Null)
値が空(NULL)であってはいけない

「社員番号」が決まっていない(空っぽの)社員データは登録できません。
名無しのデータがあると、後でその人を指定して呼び出すことができないからです。

複合主キー

1つの列だけではデータを特定できない場合に、複数の列を組み合わせて主キーにすることです。

【例】学校のテスト結果テーブル

この表で、「誰が」「何の科目で」何点取ったかを管理したいとします。

学籍番号 科目 点数
A001 国語 80
A001 数学 90
B002 国語 75
  • 学籍番号だけだと...
    「A001」が2回出てくるので重複しています。主キーになれません。
  • 科目だけだと...
    「国語」が2回出てくるので重複しています。主キーになれません。
  • 学籍番号 + 科目 の組み合わせなら...
    「A001の国語」は1つしかありません。
    「A001の数学」も1つしかありません。
    この2つをセットにすれば、行を一意に特定できるので主キーになれます!これを複合主キーと呼びます。
外部キー(Foreign Key)

別の表の主キーを参照する列のことです。
関係データベースでは、1つの巨大な表を作るのではなく、テーマごとに表を分けて管理し、それらを外部キーで「関連付け」ます。

部署テーブル (主)
部署ID 主キー 部署名
D01営業部
D02開発部
D03総務部

参照
社員テーブル (従)
社員ID 氏名 部署ID 外部キー
001IT 太郎D02
002営業 花子D01
003ネットワーク 一郎D02

上の例では、社員テーブルの「部署ID」が外部キーです。ここに「D02」と入力することで、部署テーブルの「開発部」と関連付けられます。 いちいち「開発部」という文字を入力しなくて済むため、データに矛盾が生じにくくなります。

参照整合性制約

外部キーには、「参照先の表に存在しない値は登録できない」という重要なルールがあります。これを参照整合性制約と呼びます。

例えば、部署テーブルにない「D99」というコードを社員テーブルに入力しようとするとエラーになります。 また、社員テーブルで誰かが使っている「D01(営業部)」を、部署テーブルから勝手に削除することもできません(削除するには、先に社員の所属を外す必要があります)。

(3) データの正規化

正規化とは、「データの重複や矛盾をなくすために、表を適切な形に分割・整理すること」です。
正規化されていない表は、データの追加・更新・削除の際に不都合(更新時異常)が生じる可能性があります。

重要キーワード:関数従属

「ある項目(X)が決まれば、別の項目(Y)もただ1つに決まる」という関係を「YはXに関数従属している(X → Y)」と言います。
正規化では、この「従属関係」を見極めて表を分割していきます。

完全関数従属

主キーのすべてが決まって初めて値が決まる関係。

主キー

これが理想の状態!

部分関数従属

複合主キーの一部だけで値が決まってしまう関係。
(第2正規形で排除する)

主キーA 主キーB
推移的関数従属

主キー以外の項目によって、さらに別の値が決まる関係。
(第3正規形で排除する)

主キー 項目A
正規化の手順(実践例)

「注文伝票」を例にして、非正規形から第3正規形まで順を追って正規化してみましょう。

Step 0非正規形

1つの注文で複数の商品を買った場合、表の中に繰り返し部分が存在する状態です。

注文番号 顧客名 商品コード 商品名 単価 個数
001 Aさん P01 りんご 100 2
P02 みかん 200 1
002 Bさん P01 りんご 100 5
このままだと、1行1データの原則に反しており、RDBで扱いにくい!
Step 1第1正規化:繰り返しの排除

繰り返されている部分を分割し、すべての行が固定の列数になるようにします。
空白だったセルを埋めて、平らな表にします。

注文番号 顧客名 商品コード 商品名 単価 個数
001AさんP01りんご1002
001AさんP02みかん2001
002BさんP01りんご1005

主キー:{ 注文番号, 商品コード } の複合主キーになります。

まだ問題あり:主キーの一部である「商品コード」が決まれば「商品名・単価」が決まってしまう(部分関数従属)。
Step 2第2正規化:部分関数従属の排除

主キーの一部によって決まる項目を、別の表に切り出します。
「商品コード→商品名・単価」と、「注文番号→顧客名」を分離します。

注文商品テーブル
注文番号商品コード個数
001P012
001P021
商品テーブル
商品コード商品名単価
P01りんご100
P02みかん200
注文テーブル(仮)
注文番号顧客名顧客住所
001Aさん東京都...
まだ問題あり:「顧客名」が決まれば「顧客住所」が決まる(推移的関数従属)。顧客名が変わると全注文データの修正が必要になる。
Step 3第3正規化:推移的関数従属の排除

主キー以外の項目によって決まる項目を、別の表に切り出します。
「顧客名(本来は顧客IDなど)→顧客住所」の部分を分離します。

注文テーブル
注文番号顧客ID
001C01
002C02
顧客テーブル
顧客ID顧客名住所
C01Aさん東京都...
C02Bさん大阪府...
完了!これでデータの重複がなくなり、更新時の矛盾も起きなくなりました。

(4) データベースの物理設計

ディスク容量の見積もりや、性能向上のためのインデックス設計などを行います。

過去問演習(データベース設計)

令和4年免除 問27

部品在庫管理台帳における,部品,仕入先,在庫の三つのエンティティの関係をデータモデルとして記述した。エンティティa~cの組合せとして,適切なものはどれか。ここで,1 *は1対多の関連を表す。

E-R図と表
  • a=在庫, b=仕入先, c=部品
  • a=在庫, b=部品, c=仕入先
  • a=仕入先, b=部品, c=在庫
  • a=部品, b=在庫, c=仕入先
令和5年免除 問19

関係データベースの主キーの性質として,適切なものはどれか。

  • 主キーとした列に対して検索条件を指定しなければ,行の検索はできない。
  • 数値型の列を主キーに指定すると,その列は算術演算の対象としては使えない。
  • 一つの表の中に,主キーの値が同じ行が複数存在することはない。
  • 複数の列からなる主キーを構成することはできない。
平成28年春期 問29

関係データベースにおいて,外部キーを定義する目的として,適切なものはどれか。

  • 関係する相互のテーブルにおいて,レコード間の参照一貫性が維持される制約をもたせる。
  • 関係する相互のテーブルの格納場所を近くに配置することによって,検索,更新を高速に行う。
  • 障害によって破壊されたレコードを,テーブル間の相互の関係から可能な限り復旧させる。
  • レコードの削除,追加の繰返しによる,レコード格納エリアのフラグメンテーションを防止する。
令和5年免除 問20

次の関数従属を満足するとき,成立する推移的関数従属はどれか。ここで,"A→B"はBがAに関数従属していることを表す。

{注文コード,商品コード} → {顧客注文数量,注文金額}
注文コード → {注文日,顧客コード,注文担当者コード}
商品コード → {商品名,仕入先コード,商品販売価格}
仕入先コード → {仕入先名,仕入先住所,仕入担当者コード}
顧客コード → {顧客名,顧客住所}

  • 仕入先コード → 仕入担当者コード → 仕入先住所
  • 商品コード → 仕入先コード → 商品販売価格
  • 注文コード → 顧客コード → 顧客住所
  • 注文コード → 商品コード → 顧客注文数量
令和2年免除 問27

次の表はどこまで正規化されたものか。

従業員表
  • 第2正規形
  • 第3正規形
  • 第4正規形
  • 非正規形
令和6年免除 問19

“発注伝票”表を第3正規形に書き換えたものはどれか。ここで,下線部は主キーを表す。
発注伝票(注文番号商品番号,商品名,注文数量)

  • 発注(注文番号,注文数量)商品(商品番号,商品名)
  • 発注(注文番号,注文数量)商品(注文番号商品番号,商品名)
  • 発注(注文番号商品番号,注文数量)商品(商品番号,商品名)
  • 発注(注文番号商品番号,注文数量)商品(商品番号,商品名,注文番号)

3. データ操作

(1) データベースの操作

データベースに格納されているデータを操作することです。特に以下の3つの操作(関係演算)が重要です。

重要選択(Selection)

表からある特定の行(レコード)のみを取り出す操作です。

番号氏名電話
1山田090-1111
2佐藤090-2222
3鈴木090-3333

「番号2」を選択
番号氏名電話
2佐藤090-2222
重要射影(Projection)

表からある特定の列(フィールド)のみを取り出す操作です。

番号 氏名 電話
1山田...
2佐藤...
3鈴木...

「氏名」を射影
氏名
山田
佐藤
鈴木
重要結合(Join)

複数の表を1つにする操作です。

学生テーブル
氏名教員ID
山田3
佐藤1
教員テーブル
教員ID教員名
1田中
3伊藤

教員IDで結合
結合後のテーブル
氏名教員ID教員名
山田3伊藤
佐藤1田中

その他の基本的な操作:

  • 挿入:表に行を追加する。
  • 更新:行内のデータを変更する。
  • 削除:表から行を削除する。

(2) データベース言語 (SQL)

SQL(Structured Query Language)とは

リレーショナルデータベース(RDB)を操作するための国際標準の言語です。
「データをください」「データを登録して」「表を作って」といった命令を、英語に近い文法で記述します。

実際にSQLを動かしてみよう!

以下のサイトで、ブラウザ上で手軽にSQLを実行できます。
DB Fiddle (https://www.db-fiddle.com/)

1. データの準備 (Schema SQL)

画面左側の「Schema SQL」欄に以下をコピー&ペーストしてください。
「顧客」テーブルと「注文」テーブルを作成し、テストデータを入れます。

-- 顧客テーブル
CREATE TABLE 顧客 (
  顧客番号 INT,
  顧客名 TEXT,
  電話番号 TEXT
) DEFAULT CHARSET=utf8;
INSERT INTO 顧客 (顧客番号, 顧客名, 電話番号) VALUES 
(1, '石田', '03-1234-5678'),
(2, '高橋', '03-2345-6789'),
(3, '山本', '03-3456-7890'),
(4, '鈴木', '03-4567-8901');

-- 商品テーブル
CREATE TABLE 商品 (
  商品ID INT,
  商品名 TEXT,
  カテゴリ TEXT,
  単価 INT
) DEFAULT CHARSET=utf8;
INSERT INTO 商品 (商品ID, 商品名, カテゴリ, 単価) VALUES 
(1, 'パソコン', 'PC・家電', 150000),
(2, '冷蔵庫', 'PC・家電', 50000),
(3, 'Tシャツ', '衣類', 2000),
(4, 'ジーンズ', '衣類', 5000),
(5, 'ノート', '文房具', 200);

-- 注文テーブル
CREATE TABLE 注文 (
  注文ID INT,
  顧客番号 INT,
  商品名 TEXT,
  単価 INT,
  個数 INT
) DEFAULT CHARSET=utf8;
INSERT INTO 注文 (注文ID, 顧客番号, 商品名, 単価, 個数) VALUES 
(101, 1, 'パソコン', 150000, 1),
(102, 2, 'マウス', 3000, 2),
(103, 1, 'キーボード', 5000, 1),
(104, 3, 'モニタ', 20000, 2),
(105, 1, 'USBメモリ', 1000, 5);
2. SQLの実行 (Query SQL)

画面右側の「Query SQL」欄に、これから解説するSQL文を書いて「Run」ボタンを押すと結果が表示されます。

基本的なデータ操作 (SELECT文)

データベースからデータを取り出す(検索する)命令です。最もよく使います。

① 列を取り出す・別名をつける (SELECT)

必要な列だけを指定して取得します。「AS」を使うと列に見出し(別名)を付けられます。

▼ 解説例:顧客テーブルから氏名と住所を取り出す

SELECT 顧客名, 電話番号 AS 連絡先
FROM 顧客;
-- 結果: 石田 03-1234..., 高橋 03-2345... など (4件)

【問題】

「注文」テーブルから、「注文ID」と「商品名」の列だけを取り出してください。
その際、「商品名」の列名は「品物」という別名で表示してください。

答えを見る
SELECT 注文ID, 商品名 AS 品物
FROM 注文;
② 特定のレコードを取り出す (WHERE句)

条件を指定して、データを絞り込みます。

▼ 解説例1:顧客番号が2より大きい

SELECT * FROM 顧客
WHERE 顧客番号 > 2;
-- 結果: 山本(3), 鈴木(4)

▼ 解説例2:名前が「田」で終わる (LIKE)

SELECT * FROM 顧客
WHERE 顧客名 LIKE '%田';
-- 結果: 石田(1)  ※ %は任意の文字

▼ 解説例3:東京「または」大阪 (IN)

SELECT * FROM 顧客
WHERE 住所 IN ('東京', '大阪');
-- 結果: 石田(1), 高橋(2)

▼ 解説例4:単価が1000〜5000円 (BETWEEN)

SELECT * FROM 注文
WHERE 単価 BETWEEN 1000 AND 5000;
-- 結果: マウス, キーボード, USBメモリ

SELECT * の「*(アスタリスク)」は、「すべての列」という意味です。

比較演算子=(等しい), <>(等しくない), >=, <, BETWEEN(範囲), IN(リストに含まれる), LIKE(文字検索)
論理演算子AND(かつ), OR(または), NOT(否定)

【問題】

「注文」テーブルから、「単価」が 5,000円 以上 のデータを全て取り出してください。

答えを見る
SELECT * FROM 注文
WHERE 単価 >= 5000;
③ データを並べる (ORDER BY句)

結果を指定した順序で並べ替えます。

▼ 解説例1:顧客を番号の小さい順(昇順)に並べる

SELECT * FROM 顧客
ORDER BY 顧客番号 ASC;
-- 結果: 石田(1) → 高橋(2) → 山本(3) → 鈴木(4) の順
-- ※ASCは省略可能です(ORDER BY 顧客番号; と同じ)

▼ 解説例2:顧客を番号の大きい順(降順)に並べる

SELECT * FROM 顧客
ORDER BY 顧客番号 DESC;
-- 結果: 鈴木(4) → 山本(3) → 高橋(2) → 石田(1) の順

ASC (Ascending):昇順(小さい順・あいうえお順・古い順)
DESC (Descending):降順(大きい順・逆順・新しい順)

【問題】

「注文」テーブルを、「単価」が高い順(降順)に並べ替えて表示してください。

答えを見る
SELECT * FROM 注文
ORDER BY 単価 DESC;
④ データを集計する (集合関数)

データの個数や合計、平均などを計算します。

▼ 行数(件数)を数える:COUNT

SELECT COUNT(*) FROM 注文;
-- 結果: 5

▼ 合計を計算する:SUM

SELECT SUM(個数) FROM 注文;
-- 結果: 11 (個数の合計)

▼ 平均を計算する:AVG

SELECT AVG(単価) FROM 注文;
-- 結果: 35800 (単価の平均)

▼ 最大・最小を求める:MAX / MIN

SELECT MAX(単価), MIN(単価) FROM 注文;
-- 結果: 150000, 1000

【問題】

「注文」テーブルの「単価」の合計を計算してください。

答えを見る
SELECT SUM(単価)
FROM 注文;
⑤ グループ化と条件指定 (GROUP BY, HAVING)

データをある基準(カテゴリなど)でグループに分けて、グループごとに集計します。

▼ 解説例:商品テーブルから「カテゴリ」ごとの商品数を集計

SELECT カテゴリ, COUNT(*)
FROM 商品
GROUP BY カテゴリ
HAVING COUNT(*) >= 2; -- 集計結果に対する条件指定
-- 結果: PC・家電(2), 衣類(2) (文房具は1つなので除外)
重要なルール:SELECTに書ける列

GROUP BY を使う場合、SELECT に書けるのは以下の2つだけです。

  1. GROUP BY で指定した列(グループ化の基準)
  2. 集合関数(SUM, COUNT, AVGなど)
× 失敗例:
SELECT カテゴリ, 単価 FROM 商品 GROUP BY カテゴリ;
→ 「PC・家電」グループの中に「150000」と「50000」がある場合、どっちを表示していいか分からない(一つに決まらない)ためエラーになります。

試験テクニック
例えば、次のような問題があったとします。
SELECT 学生番号, AVG(点数) FROM 得点 GROUP BY [ a ]

SELECT に「学生番号」があるので、GROUP BY にも必ず 学生番号 が必要です。
選択肢に「ア:科目」「イ:科目」「ウ:学生番号」「エ:学生番号」とあれば、瞬時に「ウかエのどちらか」に絞り込めます。

※グループ化したの結果を絞り込むときは WHERE ではなく HAVING を使います。

【問題】

「注文」テーブルを使って、 「顧客番号」ごとにグループ化し、それぞれの「購入回数(レコード数)」を表示してください。
ただし、購入回数が2回以上の顧客のみ表示してください。

答えを見る
SELECT 顧客番号, COUNT(*)
FROM 注文
GROUP BY 顧客番号
HAVING COUNT(*) >= 2;
⑥ テーブルの結合 (JOIN)

複数のテーブルをくっつけて、ひとつの表として扱います。

▼ 解説例:注文テーブルと顧客テーブルをつなぐ

SELECT *
FROM 注文
JOIN 顧客 ON 注文.顧客番号 = 顧客.顧客番号;
-- 結果: 注文情報に顧客情報が連結される (5件)

「注文テーブル」には「顧客番号」しかありませんが、「顧客テーブル」と結合することで、「誰(氏名)」が注文したかが分かるようになります。

【問題】

「注文」テーブルと「顧客」テーブルを結合し、
「注文ID」「顧客名」「商品名」の3つの列を表示してください。
※両方のテーブルにある「顧客番号」を使って結合します。

答えを見る
SELECT 注文.注文ID, 顧客.顧客名, 注文.商品名
FROM 注文
JOIN 顧客 ON 注文.顧客番号 = 顧客.顧客番号;
⑦ ビューの作成 (CREATE VIEW)

複雑なSELECT文を保存して、あたかも「新しいテーブル」のように扱える機能です。
毎回長いSQLを書く必要がなくなります。

▼ 解説例:商品名だけのビューを作る

-- 1. ビューを作成する
CREATE VIEW 商品名リスト AS
SELECT 商品名 FROM 注文;

-- 2. 作成したビューを使う(普通のテーブルのように使える)
SELECT * FROM 商品名リスト;

【問題】

「注文」テーブルから、単価が 10,000円 以上 のデータのみを抽出したビュー「高級品リスト」を作成するSQLを書いてください。
※列はすべて (*) 含めてください。

答えを見る
CREATE VIEW 高級品リスト AS
SELECT * FROM 注文
WHERE 単価 >= 10000;

正しく作成できたか確認するには、続けて SELECT * FROM 高級品リスト; を実行してみてください。

その他の機能(概要)
GRANT(権限付与)

「誰に」「どのテーブルの」「どんな操作(参照、更新など)」を許可するかを設定する命令です。
GRANT SELECT ON 注文 TO ユーザA; のように使います。
(剥奪は REVOKE

CURSOR(カーソル)

SQLの検索結果(複数行)を、プログラムの中で「1行ずつ」取り出して処理するための仕組みです。
Webシステムなどではあまり使いませんが、バッチ処理などで利用されます。

過去問演習(データ操作)

令和元年秋期 問27

関係モデルにおいて,関係から特定の属性だけを取り出す演算はどれか。

  • 結合(join)
  • 射影(projection)
  • 選択(selection)
  • 和(union)
令和5年免除 問21

国語と数学の試験を実施し,2教科の成績は氏名とともに"得点"表に記録されている。1教科は平均点以上で,残りの1教科は平均点未満の生徒氏名を"得点"表から抽出するSQL文はどれか。ここで,条件文Aと条件文Bには,それぞれ次の条件が与えられているものとする。

〔条件文〕
A 国語の点数が国語の平均点以上
B 数学の点数が数学の平均点以上
  • SELECT 生徒氏名 FROM 得点 WHERE (A AND B) AND NOT (A AND B)
  • SELECT 生徒氏名 FROM 得点 WHERE (A AND B) AND NOT (A OR B)
  • SELECT 生徒氏名 FROM 得点 WHERE (A OR B) AND NOT (A AND B)
  • SELECT 生徒氏名 FROM 得点 WHERE (A OR B) AND NOT (A OR B)
令和元年秋期 問26

"得点"表から,学生ごとに全科目の点数の平均を算出し,平均が80点以上の学生の学生番号とその平均点を求める。aに入れる適切な字句はどれか。ここで,実線の下線は主キーを表す。 得点(学生番号科目,点数)

SELECT 学生番号,AVG(点数)
FROM 得点
GROUP BY a
  • 科目 HAVING AVG(点数) >= 80
  • 科目 WHERE 点数 >= 80
  • 学生番号 HAVING AVG(点数) >= 80
  • 学生番号 WHERE 点数 >= 80
令和6年免除 問20

RDBMSにおいて,特定の利用者だけに表を更新する権限を与える方法として,適切なものはどれか。

  • CONNECT文で接続を許可する。
  • CREATE ASSERTION文で表明して制限する。
  • CREATE TABLE文の参照制約で制限する。
  • GRANT文で許可する。
令和3年免除 問26

埋込みSQLにおいて,問合せによって得られた導出表を1行ずつ親プログラムに引き渡す操作がある。この操作と関係の深い字句はどれか。

  • CURSOR
  • ORDER BY
  • UNION
  • UNIQUE

4. トランザクション処理

(1) 同時実行制御(排他制御)

複数の人が同時に同じデータにアクセスしても、矛盾が起きないように制御する機能です。
もしこの機能がないと、データが壊れたり、あり得ない状態になったりしてしまいます。

もし制御しなかったら?(映画館の予約)
座席の空き:残り1席
  1. Aさんが「空き」を確認する。(よし、予約しよう!)
  2. その直後、Bさんも「空き」を確認する。(お、空いてる!)
  3. Aさんが予約処理をして「満席」にする。
  4. Bさんも予約処理をして「満席」にする。

→ 結果:1つの席に対して2人が予約できてしまう(ダブルブッキング)!

解決策:ロック(鍵)をかける

誰かがデータを使っている間は、他の人が触れないように「鍵(ロック)」をかけます。
「試着室」「トイレ」をイメージしてください。誰かが入っている間は鍵がかかっていて、他の人は待たなければなりません。

共有ロック (Shared Lock)

「読む」ための鍵

  • 自分が読んでいる間、他人も読むことはできる
  • ただし、他人は書く(更新する)ことはできない
  • みんなで回覧板を読んでいるような状態。
専有ロック (Exclusive Lock)

「書く」ための鍵

  • 自分が書いている間、他人は読むことも書くこともできない
  • 完全に独り占めする状態(試着室の中)。
ロックの粒度(りゅうど)

ロックをかけるデータの「範囲(大きさ)」のことです。
「テーブル全体」にかけるのか、「1行だけ」にかけるのかによって、システムの性能(待ち時間や負荷)が変わります。

表ロック(粒度が大きい)

特徴:テーブル全体に鍵をかける。
メリット:鍵が1つで済むので、管理が楽(負荷が低い)。
デメリット:他の人はテーブル内の「別の行」を使いたくても待たされる(待ち時間が長い)。

行ロック(粒度が小さい)

特徴:特定の行だけに鍵をかける。
メリット:他の人は別の行を自由に使える(待ち時間が短い / 同時実行性が高い)。
デメリット:たくさんの行をロックすると鍵の管理が大変(負荷が高い)。

ロックエスカレーション
行ロック(細かい鍵)の数が多すぎてシステムの負担が大きくなった時、DBMSが自動的に表ロック(粗い鍵)に切り替えて、鍵の数を減らす仕組みのこと。
デッドロック (Deadlock)

お互いに相手が持っているデータの「ロック解除」を待ち続けてしまい、どちらも動けなくなる状態(すくみ状態)。
例:Aさんが「右の箸」を持って「左の箸」が空くのを待つ。Bさんが「左の箸」を持って「右の箸」が空くのを待つ。→ 永遠にご飯が食べられない。

2相コミットメント (Two-Phase Commit)

分散データベース(データが複数のサーバーに分かれている)において、「全ての場所で更新が成功する」か、失敗するなら「全ての場所でキャンセル(元通り)する」かを保証し、データの一貫性を保つための仕組みです。

結婚式の誓いに例えると…
司会者(コーディネータ)が全体の進行を管理します
第1相 (Phase 1):準備確認 投票フェーズ
司会「新郎、準備いいですか?」→ 新郎「OK」
司会「新婦、準備いいですか?」→ 新婦「OK」
全員の「OK」を確認!
第2相 (Phase 2):実行指示 決定フェーズ
司会「では、結婚成立と認めます!」
全員一斉にコミット(確定)

※もしPhase 1で誰か一人でも「NO(失敗)」と答えたら、司会者は「では中止です」と宣言し、全員がロールバック(取り消し)します。

このように、「①準備確認」「②コミット指示」の2段階(2相)に分けて行うことで、ネットワークで離れた場所同士でもデータの整合性を保ちます。

(2) 障害回復

ログファイル(ジャーナル)を使ってデータを復旧します。

方式対象使うログ
ロールフォワード物理障害(HDD故障など)更新後ログ(バックアップ適用後に前進)
ロールバック論理障害(プログラムミスなど)更新前ログ(処理前に後退)

(3) トランザクション管理

トランザクション処理において、データの正しさを保証するために守るべき4つの性質を、頭文字をとってACID特性(アシッド特性)と呼びます。

Atomicity (原子性)
All or Nothing (全部やるか、なしか)

処理は「すべて完了」するか、「まったく実行されなかった状態」に戻るかのどちらかでなければなりません。中途半端は許されません。
例:送金処理で「A口座から減ったけど、エラーでB口座には増えていない」という状態になってはいけない。

Consistency (一貫性)
矛盾がないこと

処理の前後で、データの整合性が保たれていること。あらかじめ決められたルール(制約)に違反しないこと。
例:送金の前後で、銀行全体の預金残高の合計が変わってはいけない(お金が勝手に消えたり増えたりしない)。

Isolation (独立性)
邪魔されないこと

同時に複数の処理が実行されても、それぞれが影響し合わず、順番に実行したのと同じ結果になること。
例:同時に同じ口座から引き出そうとしても、残高計算がおかしくならない(排他制御で守られる)。

Durability (耐久性)
消えないこと

一度正常に完了(コミット)した処理結果は、その後にシステム障害(停電や故障)が起きても失われないこと。
例:振込完了画面が出た直後に停電しても、振込データはハードディスク等に記録されていて消えない。

コミットとロールバック

原子性(Atomicity)を保つための仕組みです。

コミット (Commit)
処理確定。
耐久性が保証される。
ロールバック (Rollback)
取り消し。
開始前の状態に戻る。

(4) データベースの性能向上(インデックス)

大量のデータから目的の行を素早く見つけるために、インデックス(索引)を作成します。
本の巻末にある索引と同じで、これがないと全ページをめくって探す(全表走査:フルスキャン)ことになり、時間がかかります。

インデックスのトレードオフ
検索(SELECT)は速くなりますが、データの追加・更新・削除(INSERT/UPDATE/DELETE)は遅くなります
(データ本体だけでなく、インデックスも書き換える必要があるため)
代表的なインデックスの種類
B-tree(B木)インデックス

最も一般的で汎用的なインデックスです。
データを「木(ツリー)構造」で管理し、根っこから枝をたどってデータを探します。

  • 特徴:データ量が増えても検索速度が落ちにくい(計算量が対数オーダー)。深さが一定になるようにバランスが保たれる。
  • 得意:等価検索(=)、範囲検索(>, <, BETWEEN)、前方一致検索(LIKE 'A%')。
  • 用途:RDBのデフォルトとして広く使われる。
ビットマップインデックス

値の有無をビット(0か1)の並びで表現します。

男性: 1 0 1 0 0 ...
女性: 0 1 0 1 1 ...
  • 得意:性別や都道府県など、値の種類が少ない(カーディナリティが低い)列。AND/ORなどの論理演算が高速。
  • 不得意:データの更新(ロック範囲が広いため更新処理が重い)。データウェアハウス等の分析用途向き。
ハッシュインデックス

検索キーをハッシュ関数にかけて、格納場所(アドレス)を直接計算します。

  • 特徴:計算一発で場所がわかるため非常に高速。
  • 得意:完全一致検索(=)。
  • 不得意範囲検索(>, <)はできない(ハッシュ値には順序性がないため)。

過去問演習(トランザクション処理)

平成28年春期 問30

DBMSにおいて,複数のトランザクション処理プログラムが同一データベースを同時に更新する場合,論理的な矛盾を生じさせないために用いる技法はどれか。

  • 再編成
  • 正規化
  • 整合性制約
  • 排他制御
令和4年免除 問29

データベースシステムにおいて,二つのプログラムが同一データへのアクセス要求を行うとき,後続プログラムのアクセス要求に対する並行実行の可否の組合せのうち,適切なものはどれか。ここで,表中の○は二つのプログラムが並行して実行されることを表し,×は先行プログラムの実行終了まで後続プログラムは待たされることを表す。

ア:ア
イ:イ
ウ:ウ
エ:エ
平成30年秋期 問29

ロックの粒度に関する説明のうち,適切なものはどれか。

  • データを更新するときに,粒度を大きくすると,他のトランザクションの待ちが多くなり,全体のスループットが低下する。
  • 同一のデータを更新するトランザクション数が多いときに,粒度を大きくすると,同時実行できるトランザクション数が増える。
  • 表の全データを参照するときに,粒度を大きくすると,他のトランザクションのデータ参照を妨げないようにできる。
  • 粒度を大きくすると,含まれるデータ数が多くなるので,一つのトランザクションでかけるロックの個数が多くなる。
平成29年春期 問28

分散データベースシステムにおいて,一連のトランザクション処理を行う複数サイトに更新処理が確定可能かどうかを問い合わせ,すべてのサイトが確定可能である場合,更新処理を確定する方式はどれか。

  • 2相コミット
  • 排他制御
  • ロールバック
  • ロールフォワード
令和3年免除 問27

データベースのトランザクションに関する記述のうち,適切なものはどれか。

  • 他のトランザクションにデータを更新されないようにするために,テーブルに対するロックをアプリケーションプログラムが解放した。
  • トランザクション障害が発生したので,異常終了したトランザクションをDBMSがロールフォワードした。
  • トランザクションの更新結果を確定するために,トランザクションをアプリケーションプログラムがロールバックした。
  • 複数のトランザクション間でデッドロックが発生したので,トランザクションをDBMSがロールバックした。
令和6年免除 問22

DBMSに実装すべき原子性(atomicity)を説明したものはどれか。

  • 同一データベースに対する同一処理は,何度実行しても結果は同じである。
  • トランザクション完了後にハードウェア障害が発生しても,更新されたデータベースの内容は保証される。
  • トランザクション内の処理は,全てが実行されるか,全てが取り消されるかのいずれかである。
  • 一つのトランザクションの処理結果は,他のトランザクション処理の影響を受けない。
平成26年秋期 問27

"売上"表への次の検索処理のうち,B+木インデックスよりもハッシュインデックスを設定した方が適切なものはどれか。ここで,インデックスを設定する列を<>内に示す。
売上 (伝票番号,売上年月日,商品名,利用者ID,店舗番号,売上金額)

  • 売上金額が1万円以上の売上を検索する。<売上金額>
  • 売上年月日が今月の売上を検索する。<売上年月日>
  • 商品名が'DB'で始まる売上を検索する。<商品名>
  • 利用者IDが'1001'の売上を検索する。<利用者ID>

5. データベース応用

(1) データベースの応用

データを分析・活用するための技術です。

  • データウェアハウス (DWH):意思決定のために、基幹システムからデータを集めて蓄積した「データの倉庫」。
  • データマイニング:大量のデータから未知の法則を発見する技術。
  • ビッグデータ:量(Volume)、多様性(Variety)、速度(Velocity)を備えた巨大なデータ群。
キーバリューストア (KVS: Key-Value Store)

NoSQLの一種。ビッグデータ処理などで活躍します。

データを「キー(Key)」「値(Value)」の単純なペアで管理するデータベースです。
RDBのように複雑な表結合はできませんが、その分、非常に高速に読み書きができ、データ量が増えてもサーバーを増やすことで性能を維持しやすい(スケーラビリティが高い)という特徴があります。

  • 用途:ショッピングカート、セッション管理、SNSのタイムラインなど。
Key: "user_001"
Value: "ログイン中"

Key: "cart_1"
Value: ["りんご", "みかん"]

(2) 分散データベース

地理的に離れた場所にデータベースを配置し、ネットワークで結んで一つのデータベースのように利用するシステムです。
透過性(ユーザが分散していることを意識しなくて良い性質)が求められます。

2相コミットメント (Two-Phase Commit)

全てのサイトがコミット可能(合意)ならコミット、一つでも不可(拒否)ならロールバックする制御。

(3) データ資源管理

企業が持つ膨大なデータを「資源」として有効活用するために、データそのものだけでなく、データの定義や保管場所などの情報(メタデータ)を管理することです。

データディクショナリ / リポジトリ

ソフトウェア開発や保守において、システムに関わる様々な情報(設計書、ソースコード、データ定義など)を一元的に管理するデータベース(貯蔵庫)のことです。

ソースコードリポジトリの例
  • Git:分散型バージョン管理システム。現在の主流。
  • Subversion (SVN):集中型バージョン管理システム。
データディクショナリ (DD)
リポジトリの中でも特に、データの名称、形式、意味などのメタデータ(定義情報)を管理する「データの辞書」です。
データの種類
  • 構造化データ
    ExcelやRDBの表のように、行と列で規則的に整理されたデータ。
  • 非構造化データ
    文章、画像、動画、音声など、決まった形式を持たないデータ。
  • 半構造化データ
    XMLやJSON、HTMLのように、タグなどで一定の構造は持つが、RDBほど厳密ではないデータ。

過去問演習(データベース応用)

令和6年免除 問18

企業の様々な活動を介して得られた大量のデータを整理・統合して蓄積しておき,意思決定支援などに利用するものはどれか。

  • データアドミニストレーション
  • データウェアハウス
  • データディクショナリ
  • データマッピング
令和5年免除 問18

ビッグデータの処理で使われるキーバリューストアの説明として,適切なものはどれか。

  • "ノード","リレーションシップ","プロパティ"の3要素によってノード間の関係性を表現する。
  • 1件分のデータを"ドキュメント"と呼び,個々のドキュメントのデータ構造は自由であって,データを追加する都度変えることができる。
  • 集合論に基づいて,行と列から成る2次元の表で表現する。
  • 任意の保存したいデータと,そのデータを一意に識別できる値を組みとして保存する。
令和5年免除 問35

ソフトウェア開発・保守工程において,リポジトリを構築する理由はどれか。

  • 各工程での作業手順を定義することが容易になり,開発・保守時の作業のミスを防止することができる。
  • 各工程での作業予定と実績を関連付けて管理することが可能になり,作業の進捗管理が容易になる。
  • 各工程での成果物を一元管理することによって、開発・保守作業の効率が良くなり,用語を統一することができる。
  • 各工程での発生不良を管理することが可能になり,ソフトウェアの品質分析が容易になる。