概要
| この記事の結論 Accessでデータベースを作るには、まず管理する情報と1行の意味を決め、空のデータベースにテーブルを作成します。次に主キーとテーブル同士の関係を設定し、クエリで検索・集計、フォームで入力、レポートで出力する流れを組み立てます。最初から多機能にせず、顧客と対応履歴など小さな題材で一連の動作を完成させましょう。本記事では項目定義と操作例を示し、Excel取込、複数人利用、バックアップまで説明します。 Accessデータベースとは、データを保存するテーブルと、検索・入力・出力を行うオブジェクトを組み合わせた仕組みです。 画面名やリボンの配置はAccessの版で異なる場合があります。操作は変更前のコピーで試し、業務で利用する環境の結果を確認してください。 |
この記事でわかること
- 作る前に目的と1行の意味を決める
- 空のデータベースとテーブルを作成する
- 主キーとリレーションシップを設定する
- クエリで必要な履歴を取り出す
- 入力フォームと確認用レポートを作る
この記事の主な内容
- 作る前に目的と1行の意味を決める
- 空のデータベースとテーブルを作成する
- 主キーとリレーションシップを設定する
- クエリで必要な履歴を取り出す
- 入力フォームと確認用レポートを作る
- テストして共有とバックアップを整える
- よくある質問
想定読了時間：約19分～23分
1. 作る前に目的と1行の意味を決める
最初に決めるのは画面の見た目ではなく、何の情報を残し、何を探せるようにするかです。本記事では『顧客ごとの対応履歴を残し、未完了の対応を一覧で確認する』小さなデータベースを作ります。顧客管理、履歴入力、未完了一覧という一つの業務の流れを完成させてから機能を増やしましょう。
| 作るもの | 役割 | 今回の名前 |
|---|---|---|
| テーブル | 情報を保存する | T_顧客・T_対応履歴 |
| クエリ | 必要な情報を結び付けて取り出す | Q_未完了対応 |
| フォーム | 利用者が情報を入力する | F_顧客・F_対応履歴 |
| レポート | 確認用の一覧を印刷する | R_未完了対応 |
Accessのファイル名と、中に作るテーブルや画面の名前は別です。今回はファイルを『顧客対応管理.accdb』とし、その中に上表のオブジェクトを作ります。テーブルを作っただけでは使いやすい入力画面までは完成しないため、保存・検索・入力・出力の役割を分けて考えます。
顧客1件と対応1回を同じ行へ詰め込まない
1行に何を表すかを『粒度』と呼びます。T_顧客は1行が1顧客、T_対応履歴は1行が1回の対応です。顧客テーブルへ『対応1』『対応2』『対応3』と列を増やすと、4回目以降の対応や未完了の検索が扱いにくくなります。対応の回数が増える情報は、別テーブルへ行として追加します。
顧客名を対応履歴へ毎回直接入力すると、表記ゆれや修正漏れが起きます。代わりに顧客を識別するIDを履歴に保存し、表示するときに顧客名を取り出します。ただし、過去時点の住所や単価を証跡として固定したい業務では、当時の値を別に保存する設計もあります。『重複はすべて消す』と機械的に判断しないことが大切です。
2. 空のデータベースとテーブルを作成する
Accessを起動し、［空のデータベース］を選んでファイル名と保存先を指定します。最初は自分のPCの作業用フォルダーなど、場所が分かるところで試してください。テンプレートを利用する方法もありますが、ここでは仕組みを理解するために空の状態から作成します。
1. ［空のデータベース］を選択し、ファイル名を『顧客対応管理.accdb』にします。
2. 保存先を指定して［作成］を選びます。
3. ［作成］から［テーブルデザイン］を開き、以下の顧客テーブルのフィールドを入力します。
4. 顧客IDの行を選び、［主キー］を設定します。鍵のマークを確認します。
5. Ctrl＋Sで『T_顧客』として保存します。同じ流れで『T_対応履歴』も作成します。
顧客テーブルの項目例
| フィールド名 | データ型 | 設定例・目的 |
|---|---|---|
| 顧客ID | オートナンバー型 | 主キー。一般的な長整数の増分設定 |
| 顧客コード | 短いテキスト型 | 20文字。必須。インデックスは重複なし |
| 顧客名 | 短いテキスト型 | 100文字。必須。同名顧客を許容 |
| 電話番号 | 短いテキスト型 | 30文字。先頭の0やハイフンを保持 |
| 備考 | 長いテキスト型 | 説明を記録。必須にはしない |
対応履歴テーブルの項目例
| フィールド名 | データ型 | 設定例・目的 |
|---|---|---|
| 対応ID | オートナンバー型 | 主キー。対応1回を識別 |
| 顧客ID | 数値型 | フィールドサイズは長整数型。必須 |
| 対応日時 | 日付/時刻型 | 対応した日時を保存。必須 |
| 内容 | 長いテキスト型 | 相談・連絡の内容を記録 |
| 完了 | Yes/No型 | 既定値はFalse。未完了を区別 |
上表の文字数は説明用の設計例です。実際には使っている顧客コードの桁数や、保存する名称の長さに合わせます。電話番号や郵便番号は計算する数値ではないため、短いテキストにすると先頭の0を失いにくくなります。日付を文字列で保存すると並べ替えや期間抽出が扱いにくくなるため、日時は日付/時刻型にします。
必須項目は、空欄では業務が進められないものに絞ります。顧客名が必須なら、テキスト型の［値要求］に加えて［空文字列の許可］も確認します。すべてを必須にすると仮登録ができなくなる一方、必要な項目を任意にすると後工程が止まります。実際の入力の流れに合わせて判断してください。
3. 主キーとリレーションシップを設定する
主キーは、テーブル内の1行を一意に識別する項目です。今回は顧客IDと対応IDをそれぞれの主キーにします。対応履歴側の顧客IDは、どの顧客の対応かを示す『外部キー』です。顧客名には同名や変更があり得るため、名前そのものを行の識別子にしない設計にしています。
親はオートナンバー 子は長整数型
一般的な長整数のオートナンバー型を親の顧客IDに使う場合、子の顧客IDは数値型の長整数型にします。子もオートナンバーにすると、親の顧客を選ぶのではなく、別の番号が自動で付いてしまいます。ここを間違えると、画面が作れても顧客と履歴が正しく結び付かなくなります。
1. 開いているテーブルを閉じ、［データベースツール］の［リレーションシップ］を開きます。
2. T_顧客とT_対応履歴を追加して表示します。
3. T_顧客の顧客IDから、T_対応履歴の顧客IDへドラッグします。
4. 結び付けるフィールド名を確認し、［参照整合性］を有効にします。
5. 今回は連鎖削除を有効にせずに作成し、1対多の関係を確認して保存します。
参照整合性は、存在しない顧客IDを履歴へ登録するなどの不整合を防ぐための仕組みです。すでにデータがある場合、親に存在しないIDが子へ入っていると設定できないことがあります。警告を無視するのではなく、不一致データを調べてから設定してください。顧客を消すと履歴まで消える連鎖削除は、目的を理解せずに有効にしません。
クエリでテーブルを結ぶ線と、データベースのリレーションシップ設定は同じ意味ではありません。クエリの結合は取り出し方を指定し、参照整合性は保存データの関係を守ります。クエリが動くから整合性が保証されている、と判断しないようにしましょう。
4. クエリで必要な履歴を取り出す
未完了の対応だけを確認する選択クエリを作ります。選択クエリは、条件に合うデータを表示するためのものです。ここでは顧客名をT_顧客から、対応日時と内容をT_対応履歴から取り出し、完了がFalseの行に絞ります。元の履歴を削除する操作ではありません。
まず少量のサンプルデータを入れる
T_顧客へ『C001／青空商事』『C002／山川製作所』を登録し、自動採番された顧客IDを控えます。IDは必ず1、2になるとは限りません。T_対応履歴には実際に付いた顧客IDを指定し、青空商事の未完了1件、完了1件、山川製作所の未完了1件を登録します。以下の期待値はこの3件を前提とした説明例です。
1. ［作成］から［クエリデザイン］を開き、T_顧客とT_対応履歴を追加します。
2. 顧客ID同士の結合線があるか確認し、顧客コード・顧客名・対応日時・内容・完了を下段へ追加します。
3. 完了列の抽出条件にFalseを指定します。対応日時の並べ替えは昇順にします。
4. データシートビューで結果を確認し、未完了の2件だけが表示されることを確認します。
5. 『Q_未完了対応』という名前で保存します。
SELECT C.[顧客コード], C.[顧客名],
H.[対応日時], H.[内容], H.[完了]
FROM [T_顧客] AS C
INNER JOIN [T_対応履歴] AS H
ON C.[顧客ID] = H.[顧客ID]
WHERE H.[完了] = False
ORDER BY H.[対応日時], H.[対応ID];
SQLビューで作成する場合は、上記が同じ考え方の例になります。CとHは長いテーブル名を短く書くための別名です。履歴がない顧客はこの一覧には表示されません。『履歴がない顧客も含めた顧客一覧』が必要なら、左外部結合など、目的に合う別の取り出し方を検討します。
結果が予想より増える場合は、結合条件を確認します。顧客名のような重複し得る項目で結ぶと、同名の顧客同士で複数の組み合わせができる場合があります。まず主キーと外部キーの顧客IDで結び、1件の対応が一覧でも1件として表示されるかを確認してください。
5. 入力フォームと確認用レポートを作る
テーブルのデータシートは構造を確認するには便利ですが、日常の入力ではフォームを用意すると、入力する順序や説明を整えやすくなります。最初は自動生成やウィザードを利用し、動作を確認してから見た目を調整してください。未完了の一覧はクエリを元にレポートへ出力します。
顧客を選べる対応履歴フォームを作る
1. T_顧客を選択して［作成］の［フォーム］を使い、生成された画面をF_顧客として保存します。
2. T_対応履歴も同様にフォームを作成し、F_対応履歴として保存します。
3. F_対応履歴をデザインビューで開き、顧客IDの入力部品をコンボボックスに変更するか、連結コンボボックスを追加します。
4. コントロールソースを顧客ID、値集合ソースを顧客ID・顧客コード・顧客名を含む一覧に設定します。
5. 連結列を1、列数を3にし、ID列は非表示、コードと顧客名は見える列幅にします。
6. 顧客を選んで履歴を登録し、T_対応履歴には顧客名ではなく顧客IDが保存されることを確認します。
コンボボックスは、表示する文字と保存する値を分けられる部品です。今回は人が分かる顧客コード・顧客名を表示し、内部ではIDを保存します。顧客名が同じでもコードで見分けられるようにします。既存の顧客IDの文字欄と追加した部品が重なる場合は、設定を確認してから不要な方を整理してください。
未完了一覧をレポートへ出力する
Q_未完了対応を選択し、［作成］の［レポートウィザード］で必要な項目を選びます。対応日時の昇順、読みやすい列幅で作り、R_未完了対応として保存します。完了欄がFalseの行しか含まれないなら、印刷上は完了欄を省く選択もできます。ただし、元クエリの条件はそのまま残してください。
レポートを印刷プレビューで開き、クエリの2件と一致するか、長い内容が途中で切れないかを確認します。続いてフォームで1件を完了へ変更し、一覧を開き直して対象が1件になるか確認してください。保存・検索・入力・出力がつながることを確かめてから、色や装飾を整えます。
Excelの管理表が複数に分かれ、顧客や履歴の整理方法から迷っている場合は、現在の表と最終的に出したい一覧を用意してください。Accessの教科書へ相談する際も、画面の希望だけでなく、1行の意味と管理したい業務を共有すると、作成範囲を具体化しやすくなります。
6. テストして共有とバックアップを整える
完成の判断は、正常なデータが入力できることだけでなく、不正な入力を防ぎ、必要な一覧が再現できることです。次のように『操作』と『期待する結果』を対にして確認すると、初心者でも結果を判断しやすくなります。本番の個人情報を使わず、説明用データで試してください。
| 試す操作 | 期待する結果 | 確認する目的 |
|---|---|---|
| 同じ顧客コードを2回登録 | 重複が拒否される | 二重登録の防止 |
| 存在しない顧客IDで履歴を登録 | 参照整合性で拒否される | 不正な対応先の防止 |
| 履歴1件を完了へ変更 | 未完了一覧から外れる | 抽出条件の確認 |
| 履歴のある顧客を削除 | 連鎖削除なしなら削除が拒否される | 履歴の不用意な消失防止 |
Excel取込は小さな範囲で試す
既存のExcelを取り込む場合は、見出しを1行に揃え、結合セル、途中の小計、空白行を整理します。まず数件で試し、先頭の0、日付、空欄、重複コードが意図どおりか確認してください。取込先の項目定義を決めずに全件を移すと、自動判定されたデータ型が用途に合わないことがあります。
複数人利用では画面とデータを分ける
複数人で継続利用するなら、画面・クエリなどを持つフロントエンドと、保存データを持つバックエンドへ分ける構成を検討します。利用者ごとに画面側のコピーを持ち、共通データへ接続する考え方です。OneDriveなどの同期フォルダーに同じファイルを置いて直接同時編集する運用とは区別してください。
アクセス権や利用拠点、同時操作、データ量によっては、データの保存先をSQL Serverなどへ移す選択肢もあります。Accessの画面を残してデータだけを移す構成も可能です。単純に人数だけで決めず、ネットワーク品質、停止できる時間、復旧方法を含めて判断しましょう。
バックアップは日付付きで世代を残し、保存データ側と画面側の両方を対象にします。保存できたことだけでなく、コピーを別の場所へ戻して開き、必要なデータを読めるか確認してください。分割した場合はリンク先の再設定も復旧手順に含めます。担当者不在でも戻せるよう、保管先と手順を文書で残します。
最初の目標は、小さな題材で入力から一覧出力までを確実につなぐことです。1行の意味、データ型、主キー、関係を整えてから画面と帳票を作れば、後から機能を加える際にも修正範囲を判断しやすくなります。
7. よくある質問
同じではありません。データベースはデータを保存・利用する仕組み全体を指し、その中に情報を保存するテーブルがあります。Accessでは、テーブルに加えて、取り出し方を決めるクエリ、入力するフォーム、印刷するレポートなどを組み合わせます。例えば顧客対応管理の1ファイルの中に、顧客テーブルと対応履歴テーブルを作るイメージです。最初に各機能の役割を分けて理解すると、データを直す場所と画面の見た目を直す場所を取り違えにくくなります。
単純な一覧で、1行が何を表すか明確なら、1テーブルから始めることはできます。ただし、顧客に対して複数の対応履歴が付くように、同じ相手に情報が繰り返し発生する場合は、分けて保存する方が扱いやすくなります。顧客の行へ対応1・対応2と列を増やし続ける構造は避けましょう。最初から業務全体を作る必要はありませんが、1件と1回を区別して設計します。後から増える情報が列ではなく行として追加できるか、具体例を使って確認してください。
取込はできますが、Excelの見た目をそのままデータベースの構造にする前に整理が必要です。見出しを1行にし、結合セルや途中の小計、不要な空白行を除きます。電話番号やコードの先頭の0、日付、空欄、重複値を特に確認してください。最初は数件だけを試し、取込先のデータ型が目的に合うかを確かめてから全件を移します。既存テーブルへ追加する場合は、列の対応だけでなく、同じデータを再取込したときの重複防止方法も決めておきましょう。
顧客名は同じ名前の別顧客や名称変更があり得るため、一般的には主キーに向きません。顧客IDなど、各顧客を一意に識別し、後から変えない値を主キーにする方が扱いやすくなります。オートナンバーを使う場合でも、業務上の顧客コードが重複してよいことにはなりません。コードの重複を防ぐ設定は別に用意してください。名前で探せる画面を作ることと、内部でIDを使って関係を保つことは両立できます。同名顧客はコードや所在地で見分けます。
両方をオートナンバーにするのではありません。親の顧客IDが一般的な長整数のオートナンバー型なら、対応履歴側の顧客IDは数値型の長整数型にし、登録済みの顧客IDを保存します。履歴側もオートナンバーにすると、顧客の選択とは無関係に番号が付いてしまいます。なお、対応履歴自身を区別する対応IDは、別のオートナンバーの主キーとして持たせます。どの顧客かを示す番号と、どの対応かを示す番号の役割を分けると理解しやすくなります。
テーブル、選択クエリ、基本的なフォームやレポートは、デザイン画面やウィザードを使って作成できるため、最初からVBAが必須というわけではありません。本記事のように、小さな入力と一覧の流れを先に完成させる進め方が有効です。複雑な入力チェックや外部サービス連携などが必要になった段階で、マクロやVBAを検討します。コードを増やす前に、データ型、主キー、抽出条件などの基本設定で解決できないかを確認すると、保守もしやすくなります。
複数人利用は可能ですが、同じファイルをどこへ置いても安全に共有できるわけではありません。継続運用では、利用者ごとのフロントエンドと、共通データを保存するバックエンドへ分ける構成を検討します。OneDriveなどの同期を、データベースの同時更新の仕組みと同一視しないでください。ネットワーク、権限、利用拠点、復旧条件も確認します。必要に応じてAccessの画面を残し、データをSQL Serverなどへ移す方法も含めて判断しましょう。
日付を付けた世代管理で、データと画面の両方を残します。単体ファイルなら整合性のある状態でファイルを保存し、分割構成ならバックエンドとフロントエンドの保管を分けて考えてください。利用中ファイルの単純コピーで十分かは運用により異なるため、停止時間やバックアップ方法を決めます。復旧テストでは別の場所へ戻して開き、データと画面の接続も確認します。保存先、取得担当、保管期間、戻し方を記録しておくと、担当者不在の際にも役立ちます。
基本用語や関連操作を確認したい場合は、次の記事もあわせてご覧ください。
自分で設定できる範囲は、コピー環境で確認しながら進められます。複数の帳票・端末・業務データに影響する場合は、現在の状態と期待する結果、利用中のAccessの版を整理してご相談ください。
参考情報
Microsoft｜Create a new database
https://support.microsoft.com/en-us/access/create-a-new-database
Microsoft｜Database design basics
https://support.microsoft.com/en-us/access/database-design-basics
Microsoft｜Guide to table relationships
https://support.microsoft.com/en-us/access/guide-to-table-relationships
Microsoft｜Add or change a table’s primary key
https://support.microsoft.com/en-us/access/add-or-change-a-table-s-primary-key-in-access
Microsoft｜Split an Access database
https://support.microsoft.com/en-us/access/split-an-access-database