応用情報暗記無料で始める

テーブル・レコード・フィールドとは？テーブル・レコード・フィールド

テーブル・レコード・フィールドとは、リレーショナルモデルの関係（リレーション）・組（タプル）・属性（アトリビュート）に、実装上の呼び名としてテーブル・レコード（行）・フィールド（列、カラム）が対応する。SQLではテーブルが操作の単位で、SELECTが対象とする列の集合がフィールド、WHEREで絞り込まれ結果として返る単位がレコードになる。理論上のリレーションは組の集合なので重複行も行順も存在しないが、SQLのテーブルは主キー制約を課さない限り重複行を許し、ORDER BYを書かなければ行順も不定である——この「モデルと実装のずれ」が設計判断の分かれ目になる。フィールドには定義域（ドメイン）としてデータ型・NOT NULL・CHECK制約を与え、レコードを一意に識別する属性の組を主キーとして選ぶ。1つのフィールドに複数の値を詰め込まない（第1正規形）ことが、以降の正規化と結合の前提になる。

最終更新：2026-10-06

試験情報

応用情報技術者試験の過去問では9回出題され、ほかに3問の解説で触れられています（2018年度〜2025年度）。

応用情報技術者試験の頻出用語／テクノロジ系

別名：Table、Record、Field、カラム、フィールド

この語が出る過去問を解く →

背景

初期のデータベース（階層型・網型）はデータの並び順やポインタの構造をアプリケーションが知っている必要があり、格納方法を変えるとプログラムを直す羽目になった。この物理構造への依存を断つために、データを「表の集合」という数学的な関係として定義し、どう格納されているかを利用者から隠したのがリレーショナルモデルである。だからテーブル・レコード・フィールドは単なる呼び名ではなく、SQLがなぜ「どう取るか」ではなく「何が欲しいか」だけを書けばよいのかの根拠にあたる。応用情報で理論用語と実装用語の対応が問われるのは、この非手続的な問い合わせと正規化理論がどちらもこのモデルを前提にしているためである。

具体例

ECサイトの注文機能を作るとき、注文テーブルの1レコードが1件の注文、注文明細テーブルの1レコードが「その注文の中の1商品」になる。注文明細に商品を3行入れるか、注文テーブルの商品コード欄にカンマ区切りで3つ入れるかが設計の分岐点で、後者にすると「この商品を買った人」を出すのに文字列の部分一致検索が要り、インデックスが効かず商品コードの桁変更にも耐えられない。明細を別レコードに分ける設計を選ぶ理由はここにある。

試験での引っ掛け

「カラム＝フィールド」と実務では同義に使うが、試験の文脈では属性（列の定義）と、ある行のその列の値（フィールド値）を区別して問うことがある。また「テーブル＝リレーション」と即答すると誤りになる場面がある。重複行を許すかどうか、行順を持つかどうかで両者は異なり、DISTINCTやUNION（重複を除く）とUNION ALL（除かない）の差もここに由来する。記述式では「なぜ1フィールドに複数値を入れないのか」を、検索性・更新時異常・インデックスの効き方のどれか一つに絞って30〜50字で言い切れるようにしておく。

関連用語

出た過去問

問題文で直接問われたものと、解説の中で触れられたものが含まれます。

出典・参考

公式シラバスの3 技術要素 ＞ 2. データベース設計 ＞ (2) データベースの設計に掲載されている用語です。

解説は資格暗記が独自に作成しています。過去問の出典は各問題に記載のとおりです。

この語が出る過去問を解く →

試験での特徴
  • 試験では9回出題（2018年度〜2025年度）
  • 分野：テクノロジ系
  • 「カラム＝フィールド」と実務では同義に使うが、試験の文脈では属性（列の定義）と、ある行のその列の値（フィールド値）を区別して問うことがある。

作成：たにこ