データベースの属性とは？カラム・項目との違いと設計の基本

データベースの「属性」とは、テーブルの列が表すデータ項目の種類のことです。usersテーブルなら、ユーザー名やメールアドレス、登録日時の一つひとつが属性にあたります。検索で多いのは「属性とカラムは何が違うのか」「属性にはどんな種類があるのか」「設計でどう決めればいいのか」という3つの疑問です。この記事は定義から用語の違い、データ型・キー・制約、そして避けるべき設計まで、SQLの例を交えて順に答えます。なお、属性を扱う前提となるデータベース全体の種類と選び方はデータベースとはの解説で整理しています。

まとめ

先に要点を示します。詳しい根拠と具体例は本文で解説します。

• 属性とは、テーブルの列が表す「各レコードが共通して持つデータ項目の種類」。関係モデルでは関係（テーブル）の見出しを構成する要素を指す。
• 「カラム」はほぼ同義だが視点が違う。属性は設計・概念上の呼び名、カラムは実装上の列を指すことが多い。フィールドは1行分の値、項目は属性の言い換え、プロパティはツールやGISで列の性質を指す呼び名。
• 属性には種類（単一値・複合・多値・導出・キー属性）とデータ型（数値・文字列・日付・真偽）がある。型は格納する値の性質で選ぶ。
• 主キー・外部キー・候補キー（主キーになりうる一意な属性）は役割を持つ属性。NOT NULLやUNIQUEなどの制約で値の整合性を守る。
• 避けるべき設計の代表が「単一参照テーブル」。意味の異なる属性を1つの汎用テーブルに押し込む手法で、外部キーが効かず保守を難しくする。

以降では、まず属性の定義と用語の違いを確認し、続いて種類・データ型・キー・制約、そして避けるべき設計の順に掘り下げます。

データベースの属性とは何か

属性は、テーブルを構成する縦方向の列であり、その列に入る値が「何を表すか」を定義します。たとえば社員テーブルなら、社員番号・氏名・所属部署・入社日がそれぞれ属性です。1つの属性は、すべてのレコード（行）が共通して持つ1種類のデータに対応します。氏名の列にメールアドレスを混ぜないように、属性は「1つの意味」を担当します。

下のusersテーブルでは、id・username・email・created_atの4つが属性です。各行（レコード）はこの4属性の値の組で1人のユーザーを表します。

CREATE TABLE users (
    id INT PRIMARY KEY,
    username VARCHAR(50) NOT NULL,
    email VARCHAR(100) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

リレーショナルモデルにおける属性の定義

関係モデル（リレーショナルモデル）では、テーブルを「関係（リレーション）」と呼び、その見出し部分を構成するのが属性です。各属性には定義域（ドメイン）があり、これは属性が取りうる値の範囲を意味します。created_atの定義域は日時、idの定義域は整数、という具合です。属性とドメインを先に決めておくと、入ってよい値・いけない値が明確になり、後段の型や制約の判断がぶれません。値の意味と範囲を定義する単位、それが属性です。

属性とカラム・フィールド・項目・プロパティの違い

これらは重なりの大きい用語で、現場では同義に使われることもあります。違いは「どの視点から呼んでいるか」にあります。混乱しやすい順に整理します。

実務での使い分けはシンプルです。設計やデータモデルの話をするときは「属性」、SQLでテーブルを作る話なら「カラム」で通じます。「項目」は仕様書で属性とほぼ同じ意味で使われます。フィールドは1行分の具体的な値を指すため、属性（列の種類）とは粒度が違う点に注意してください。プロパティは、GeoJSONのpropertiesのようにGISや一部ツールで対象の性質を指す呼び名で、データベースの会話ではあまり使いません。

属性の種類とデータ型

属性は「どんな構造を持つか（種類）」と「どんな値を入れるか（データ型）」の2つの軸で整理できます。種類は設計の概念、データ型は実装の選択です。

属性の種類（単一値・複合・多値・導出・キー属性）

関係モデルでは、属性をその構造で次のように分けます。設計時にどれに当たるかを見極めると、列の分割やテーブルの切り出し判断がしやすくなります。

• 単一値属性：1つの値だけを持つ。年齢や生年月日など、多くの属性はこれ。
• 複合属性：複数の意味を含む。住所（都道府県・市区町村・番地）が典型で、検索や集計に使うなら分割する。
• 多値属性：1件に対し値が複数。電話番号を2つ以上持つ場合などで、別テーブルに切り出すのが基本。
• 導出属性：他の属性から計算で求まる。生年月日から出す年齢が代表で、保存せず都度算出する設計も選べる。
• キー属性：行を一意に識別する。社員番号のように、後述する主キーの候補になる属性。

複合属性と多値属性は、そのまま1列に詰め込むと検索や更新で詰まります。最初の設計で「この属性は単一値か」を確認しておくと、後からの作り直しを避けられます。

属性のデータ型（数値・文字列・日付・真偽）

データ型は、属性が格納する値の性質に合わせて選びます。型を適切に決めると、不正な値の混入を防ぎ、検索や並べ替えも正しく動きます。代表的な対応は次のとおりです。

金額に浮動小数ではなくDECIMALを使うのは、誤差を避けるためです。登録日時のcreated_atにTIMESTAMPを選び、DEFAULT CURRENT_TIMESTAMPを付ければ、行の作成時刻が自動で記録されます。文字列は最大長が読める範囲ならVARCHAR、長文ならTEXTと使い分けます。

キーとなる属性と制約

すべての属性が同じ重みではありません。行を識別したりテーブル同士をつないだりする「キー」の役割を担う属性があり、さらに各属性には値のルールを課す制約があります。

主キー・外部キー・候補キー

キーは、どの行かを特定し、テーブル間の関係を成立させる属性です。役割で次のように分かれます。

• 主キー（PRIMARY KEY）：行を一意に識別する属性。重複と空値を許さない。usersのidが該当する。
• 候補キー：主キーになりうる一意な属性。メールアドレスのように、実質的に重複しない属性が候補になる。
• 外部キー（FOREIGN KEY）：他テーブルの主キーを参照する属性。下のpostsのuser_idがusersのidを指し、1対多（1:N）の関係を作る。

CREATE TABLE posts (
    id INT PRIMARY KEY,
    user_id INT,
    title VARCHAR(200) NOT NULL,
    body TEXT,
    FOREIGN KEY (user_id) REFERENCES users(id)
);

主キーの候補が複数あるときは、値が変わらず短いものを選びます。メールアドレスは候補キーですが変更されうるため、主キーには変わらないidを使うのが定石です。

属性に課す制約（NOT NULL・UNIQUE・DEFAULT・CHECK）

制約は、属性に入る値のルールを宣言し、データの整合性をデータベース側で守らせる仕組みです。アプリ側のチェックだけに頼らず、列の定義で担保するのが安全です。

• NOT NULL：空値を禁止する。氏名やメールのように必須の属性に付ける。
• UNIQUE：重複を禁止する。メールアドレスを一意にしたいときに使う。
• DEFAULT：未指定時の既定値を入れる。created_atに現在時刻を入れる用途が代表。
• CHECK：値の条件を課す。数量を0以上に限る、といった範囲制限ができる。

ただし制約だけでは守れない整合性もあります。複数の処理が同時に同じ行を更新する場面では、トランザクションとロックによる整合性管理が別途必要です。属性の制約は「1行の中の正しさ」、ロックは「同時更新の中の正しさ」と役割を分けて考えると整理できます。

良い属性設計の判断基準

属性設計の良し悪しは、感覚ではなく原則で判断できます。核になるのは「1属性1事実」です。1つの属性は1つの意味だけを持ち、複数の事実を1列に混ぜないという考え方です。

この原則を形式化したのが原子性（第1正規形）です。属性の値はそれ以上分割しても意味をなさない最小単位にします。住所を「東京都千代田区…」と1列に入れると、都道府県での集計ができません。市区町村での絞り込みが要件にあるなら、属性を分けるべきです。要件に無ければ分けない、という判断も同じ基準から導けます。

もう1つの軸が関数従属です。「ある属性の値が決まれば、別の属性の値が一意に決まる」関係を指し、その決め手になる側を決定項と呼びます。社員番号が決まれば氏名が決まるなら、社員番号は氏名の決定項です。決定項でない属性に他の属性がぶら下がっていると、更新時に矛盾が起きやすくなります。正規化とは、この関数従属を手がかりに属性を正しいテーブルへ振り分ける作業にほかなりません。迷ったら「この属性は、このテーブルの主キーだけに従属しているか」を問うのが実務的な判断基準です。

属性設計で避けるべきアンチパターン

原則の裏返しとして、やってはいけない設計があります。代表例を、なぜ避けるべきかまで具体的に挙げます。

最も典型的なのが単一参照テーブルです。区分値や種別といった性質の異なるマスタを、1つの汎用テーブルにまとめて持たせる手法で、SQLアンチパターン（One True Lookup Table）として知られています。下のように「区分種別」と「値」を1テーブルに詰めると、外部キーで参照先を限定できず、商品区分の列が誤って都道府県コードを参照しても止められません。

-- 避けたい設計：意味の異なる区分を1テーブルに集約
CREATE TABLE all_codes (
    code_type VARCHAR(50),
    code_value VARCHAR(50),
    label VARCHAR(100),
    PRIMARY KEY (code_type, code_value)
);

結論として、区分ごとに専用のマスタテーブルを作り、外部キーで縛る設計を採るべきです。テーブルが増えても、参照の正しさをデータベースが保証してくれる利点が上回ります。

もう1つは多値のカンマ詰めです。「タグ」属性に赤,青,緑のようにカンマ区切りで複数値を入れると、特定タグでの検索や件数集計が文字列処理になり、外部キーも効きません。多値属性は中間テーブルに切り出すのが正解で、ここを横着すると後から必ず作り直しになります。汎用的すぎる「予備カラム」「memo何でも入れ列」も、意味が定義されないまま肥大化するため避けます。

属性と関係（1:1・1:N・N:N）の対応

属性設計は、テーブル間の関係づくりと表裏一体です。外部キー属性をどこに置くかで、関係の種類が決まります。3つのパターンを最小例で示します。

• 1:1：社員と社員証のように、互いに1件ずつ対応。一方のテーブルに相手の主キーを外部キーとして持たせ、UNIQUEを付ける。
• 1:N：ユーザーと投稿のように、1件が複数を持つ。「多」側（投稿）に外部キー属性を置く。
• N:N：著者と書籍のように、双方が複数を持つ。両者の主キーを属性に持つ中間テーブルを作って分解する。

-- N:N を中間テーブルで分解する
CREATE TABLE author_book (
    author_id INT,
    book_id INT,
    PRIMARY KEY (author_id, book_id),
    FOREIGN KEY (author_id) REFERENCES authors(id),
    FOREIGN KEY (book_id) REFERENCES books(id)
);

N:Nを中間テーブルなしで表そうとすると、多値のカンマ詰めに逆戻りします。関係の種類を見極めてから外部キー属性の置き場所を決める、という順序を守ると設計が安定します。

属性を決めるデータベース設計の手順

属性は思いつきで足すのではなく、要件から順に導きます。実務でぶれない手順は次の通りです。

1. 要件を洗い出し、システムが扱う「もの・こと」を言葉で書き出す。
2. そこからエンティティ（テーブルの候補）を抽出する。「ユーザー」「投稿」「商品」など。
3. 各エンティティが持つ属性を列挙し、1属性1事実になっているか確認する。
4. 属性ごとにデータ型と制約（NOT NULL・UNIQUE等）を決める。
5. 関数従属を手がかりに正規化し、属性を正しいテーブルへ振り分ける。
6. 主キー・外部キーを定め、テーブル定義書にまとめる。

運用が始まった後は、アクセス頻度の高い属性にインデックスを張るなどの調整が効いてきます。属性ごとのアクセスのされ方は、データベースのバッファヒット率のような性能指標にも表れるため、設計時点で「どの属性で頻繁に検索するか」を見立てておくと後の負荷対策が楽になります。

よくある質問

データベースの属性とは何ですか？

テーブルの列が表す、各レコードが共通して持つデータ項目の種類です。社員テーブルなら社員番号・氏名・入社日がそれぞれ属性にあたります。関係モデルでは関係（テーブル）の見出しを構成する要素を指し、各属性には取りうる値の範囲であるドメインがあります。

属性とカラムの違いは何ですか？

指すものはほぼ同じ列ですが、視点が違います。属性は設計やデータモデルの概念として、カラムはSQLや実装上の列として使われることが多い言葉です。設計の会話では「属性」、テーブル作成の会話では「カラム」と使い分ければ自然に通じます。

属性と項目は同じ意味ですか？

多くの場面で同じ意味です。仕様書や業務の現場では、属性を「項目」と言い換えることがよくあります。一方「フィールド」は1レコード内の1つの値を指すため、列の種類を表す属性とは粒度が異なる点に注意してください。

関係モデルの属性とは何を指しますか？

関係（リレーション＝テーブル）の見出しを構成する各列が属性です。1件のデータである行は「タプル」と呼ばれ、各属性に対する値を1つずつ並べた組として表されます。属性が縦の枠組み、タプルがその枠を埋めた横一列、という関係になります。

単一参照テーブルはなぜ避けるべきですか？

意味の異なる区分値を1つの汎用テーブルに集約するため、外部キーで参照先を限定できず、誤った値の参照を防げないからです。区分ごとに専用マスタを作り外部キーで縛るほうが、テーブル数は増えても整合性をデータベースが保証してくれます。

関連記事

• トランザクションとロックの関係とデッドロックの防止策
• データベースのバッファヒット率とは何か？データバッファの基本概念から役割・メリットまで徹底解説ガイド
• スロークエリログとは？基本的な概要と役割の説明