概要
| この記事の結論 Accessの主キーは、テーブルの各レコードを重複なく識別するためのフィールド、またはフィールドの組み合わせです。値の重複やNullは許可されません。主キーはテーブルごとに1つですが、複数列で構成できます。顧客名や電話番号のように重複・変更する項目より、安定したIDを選ぶと関連データを管理しやすくなります。 |
この記事でわかること
- 重複とNullを許可しない
- オートナンバーと主キーは別の概念
- 複合主キーも設定できる
- 変更時は外部キーへの影響を調べる
この記事の主な内容
- 主キーが必要になる理由
- 主キーとオートナンバーと外部キーの違い
- 主キーを設定する方法
- 複合主キーと業務上の重複を設計する
- 主キーを設定できない原因と対処
- 既存システムの主キーを変更する前の確認
- よくある質問
想定読了時間：約7分～9分
1 主キーが必要になる理由
顧客名だけでデータを区別すると、同姓同名の人が登録されたときに判別できません。主キーがあれば、名前が同じでも顧客IDが違う別レコードとして管理できます。画面の何行目に表示されるかは並べ替えで変わるため、行番号をそのまま識別子にはしません。
テーブルには主キーを設定せず保存することもできます。ただし、継続して更新する業務データでは、どの1件を修正・削除するかを確実に特定できる設計が重要です。一時的な取り込み表と、正式な顧客マスターではキーの要件を分けて考えます。
参考：Microsoft テーブルの主キーを追加または変更する
2 主キーとオートナンバーと外部キーの違い
主キーは行を識別する役割、オートナンバーは値を自動で割り当てるデータ型です。両者はよく組み合わせますが同じ意味ではありません。また、別のテーブルの主キーを参照する項目を外部キーと呼びます。
| 項目 | 役割 | 設計例 |
|---|---|---|
| 主キー | 自分のテーブルの行を識別 | 顧客テーブルの顧客ID |
| オートナンバー | 新しい値を自動採番 | 顧客IDを自動採番にする |
| 外部キー | 別テーブルの行を参照 | 受注テーブルの顧客ID |
標準的な長整数型のオートナンバーを主キーにする場合、参照先の外部キーは通常、数値型の長整数型にします。外部キーもオートナンバーにすると、それぞれで別の番号が発生してしまいます。大きい数値など別の型を使用する設計では、双方の型の対応を確認します。
オートナンバーは欠番のない伝票番号を保証する仕組みではありません。欠番が生じても主キーとしての役割は果たせます。伝票番号の連続性が業務上必要なら、内部IDとは別に採番・取消のルールを設計しましょう。
3 主キーを設定する方法
新しく設計するテーブルでは、安定したIDを主キーにする方法から検討できます。既存データに主キーを追加する場合は、先に重複と空欄を確認してから設定します。作業前にはデータベースのコピーを保存してください。
1. ナビゲーションウィンドウで対象テーブルを右クリックし、［デザインビュー］を開きます。
2. 主キーにするフィールドの左端の行セレクターを選びます。新しいID列を使う場合は列名とデータ型を設定します。
3. ［テーブルデザイン］の［主キー］を選び、鍵のマークを確認します。
4. テーブルを保存し、データシートビューで既存データを確認します。
5. 複製した環境で重複やNullを登録できないこと、画面が正常に動くことを確認します。
氏名、電話番号、メールアドレスは重複や変更があり得ます。業務上の一意性と不変性が確認できない項目を、見た目が識別しやすいという理由だけで主キーにしないようにします。
参考：Microsoft テーブルの主キーを追加または変更する
4 複合主キーと業務上の重複を設計する
複数の列を組み合わせて1行を識別するものを複合主キーと呼びます。例えば「受注ID＋行番号」なら、同じ受注内で行番号が重複しないようにできます。設定時はCtrlキーを押しながら複数の行セレクターを選び、［主キー］を押します。
「受注ID＋商品ID」が適切かは業務によります。同じ商品を別納期や別単価で複数行に分けるなら、その組み合わせでは必要な入力まで拒否します。重複を禁じる単位を、画面ではなく業務ルールで決めることが先です。
別の方法として、明細IDを主キーにし、受注IDと行番号の組み合わせに一意インデックスを付ける設計もあります。内部の識別と業務上の重複防止を分けられます。索引の設定はインデックスに関する関連記事で説明します。
複数テーブルや複数端末への影響が分からない場合は、変更目的と現状の構成を整理してお気軽にご相談ください。
5 主キーを設定できない原因と対処
設定エラーの代表例は、主キー候補に重複やNullがあることです。エラーを消すために元データをまとめて削除せず、どのレコードを残すべきか、関連する受注などをどちらへ結び直すかを決めます。
重複候補を調べるSQLの例
次のSQLは、説明用の「T_顧客」にある顧客コードの重複を抽出します。データを削除・更新する処理ではありません。実際のテーブル名とフィールド名に置き換え、作業用コピーで確認してください。
SELECT [顧客コード], Count(*) AS [件数]
FROM [T_顧客]
GROUP BY [顧客コード]
HAVING Count(*) > 1;
Nullは別途、抽出条件Is Nullで確認します。テキストの場合は空文字や前後の空白も点検します。氏名の一致だけで同一人物と決めつけず、業務上の識別情報を突き合わせてから補正してください。
6 既存システムの主キーを変更する前の確認
主キーの変更は、そのテーブルだけの設定変更とは限りません。リレーションシップ、フォームの検索処理、更新クエリ、VBA、CSV連携などで旧キーを使用している可能性があります。変更前に参照先を一覧にします。
- 旧キーと新キーの対応表を作り、関連データが迷子にならないようにする。
- 親子テーブルのデータ型と参照整合性を確認する。
- 連鎖更新・連鎖削除の影響範囲を調べる。
- 更新停止、バックアップ、切替後の件数照合を計画する。
主キーを外すためだけにリレーションを削除し、そのまま運用を再開してはいけません。参照整合性まで含めて復元・検証します。既存システムで影響範囲が分からない場合は、先にテーブル構造と利用箇所の調査を行いましょう。
よくある質問（FAQ)
いいえ。条件を満たす既存のコードなども使えます。主キーの役割と自動採番の方式は別です。
主キーは1つです。ただし、その1つを複数のフィールドで構成する複合主キーにできます。
一意に識別できれば主キーとして問題ありません。欠番が許されない業務番号は別のルールで管理します。
主キー設定を外すだけならフィールド自体は残ります。ただし一意性の制約や関連付けへの影響を事前に確認してください。
主キー・重複データの設計見直しが必要な場合
この記事の手順を作業用コピーで確認しても解決しない場合や、業務への影響が大きく自社だけで判断しにくい場合は、お気軽にご相談ください。Accessの現在の構成、発生している症状、変更したい内容をもとに、調査・改修の範囲を整理します。
ご相談時は、Accessの製品名・Build・bit数、エラーの内容、対象ファイルの構成、直前に変えた設定を分かる範囲でお知らせください。機密データやパスワードは公開フォーム等へそのまま記載しないでください。