【テーブル】テーブルの概要と設計手順

テーブルはACCESSにおけるデータ保存場所として、全てのオブジェクトの起点となる重要なオブジェクトです。テーブルを作成する作業を”テーブル設計”といいますが、この工程が甘いと非常に扱いづらい業務システムになります。
この記事ではAccessのテーブルに関する基本的事項を網羅したうえで、テーブル設計におけるポイントを入門者にも理解しやすいよう丁寧に解説します。

Accessにおけるテーブルの役割

Accessは様々なオブジェクトを組み合わせながら使用することが基本となりますが、まずは各オブジェクトとテーブルの関係性を把握しておきましょう。

オブジェクト	解説
テーブル	データを格納する場所です。Access活用するうえでテーブルが全ての起点となります。データが無いと何も始まりませんから、当たり前といえば当たり前ですね。
クエリ	テーブルのデータに対して `集計` `抽出` `加工` といった様々なデータ操作を行うことができます。
フォーム	テーブルのデータを操作する”ユーザインターフェイス”としての役割を担います。フォームから入力したデータをテーブルに保存したり、テーブルのデータをフォームに表示するといったことができます。（フォームを通さず直接テーブルを展開してデータ登録や参照を行うこともできます。）
レポート	テーブルのデータを、様々なレイアウトで印刷することができます。

momongacat

オブジェクト を料理に例えると、データが入ったテーブルは原材料そのもの！
クエリは調理で、フォームやレポートは器かな。

テーブルがAccess活用の起点であり中核ということが上記からもお分かりいただけたと思います。つまり「ものすごく重要なオブジェクト」ということを認識しておきましょう！

テーブルの画面構成

次にテーブルの画面構成についてです。テーブルは縦軸と横軸で構成されており、それぞれの名称と役割は下表のとおりです。

軸	名称	内容
横軸	フィールド	格納されるデータの内容を示す
縦軸	レコード	格納されているデータそのもの　縦にどんどん追加していく

テーブル自体の見た目はExcelのシートと似ていますが、Excelはシート内のどこでも自由に入力できるのに対して、Accessは１行分（1レコード）を1件としてカウントします。

Excelとの違いはこちらの記事を参照してください。

仕事におけるExcelとAccessの使い分け

「Excelは簡単 Accessは難しい」という声があります。両アプリはそのような視点で捉えるのではなく、それぞれの特徴を踏まえた上で使い分けることができれば飛躍的に業務能率の向上につながります。この記事では使い分けについて徹底解説します。

テーブルの種類

テーブルには形態や用途に応じていくつかの種類があります。

形態上の種類

テーブルの”実態”がどこにあるかによって リンクテーブル と ローカルテーブル に分けられます。下図はAccessのナビゲーションウインドウですが、表示されるテーブル名左端の矢印の有無により見分けられます。

リンクテーブル

現在自身が操作しているAccessファイルとは別の場所に存在するテーブルをリンクテーブルといい、外にあるテーブルをまるで自身のデータベースの一部のように扱うことができます。リンク可能なテーブルは同じAccessはもちろん、OracleやSQLServerといったリレーショナルデータベース、Excelやテキストファイルまでリンクすることができます。

1つのAccessファイルの容量は2GBが上限ですが、リンクテーブルはその上限に含まれないため、うまく活用することで、規模の大きな業務システムも構築することができます。また、リンクテーブルをネットワーク上に置くことで、複数人でデータ共有することができます。

リンクテーブルの詳細については、こちら↓の記事をご覧ください。

【テーブル】リンクテーブルの基本と活用方法

Accessのリンクテーブルについて、基本と活用するうえでのメリットを中心に解説します。

ローカルテーブル

現在自身で操作しているAccessファイル内に作成するテーブルをローカルテーブル（またはそのまま”テーブル”）といいます。複数人で共有する必要がない場合は基本的にローカルテーブルとして作成します。

自身のAccessファイル内に実態が存在するテーブルであるためネットワーク負荷等の影響を受けず、リンクテーブルと比較して処理が高速です。反面、ファイル容量上限に含まれるため、データ件数の大きいテーブルは保持しきれない等のデメリットもあります。

用途上の種類

テーブルの作成手順自体に違いはありませんが、テーブルをどういう用途で使用するかによって便宜上に区分けしたものです。マスタテーブル トランザクションテーブル ワークテーブル の3種類に分けられます。

マスタテーブル

顧客マスタ、商品マスタ、社員マスタといった、あまり頻繁に更新されない、データベースの基本となる情報を格納するテーブルです。他のテーブルから参照されることが多く、データベース全体の整合性を保つ上で重要な役割を果たします。

sachiko

社員マスタだと社員の退職や採用時に更新されるだけなので頻繁ではないですね

トランザクションテーブル

受注データ、請求データ、在庫管理データといった、日々の業務で発生するデータを記録するテーブルです。頻繁にデータの追加や更新が行われ、基本的にマスタテーブルと連携する前提で使用するテーブルです。

ワークテーブル

一時的なデータを格納するテーブルです。様々な使用方法がありますが、トランザクションテーブルへの新規追加前の確認などに使用します。使用後はデータ削除を行うため、普段は空のテーブルとして存在します。

テーブル設計のポイント

さぁ、ここから実際のテーブル設計に入っていきます。

ところでAccessに限らず様々な作業において、「まずはざっくり作っておいて、細部はあとで調整しよう」という進め方があると思います。スピーディーにモノゴトを進めるには有効ですが、データベースのテーブル設計に関してはなるべく最終形を想定して作る必要があります。なぜなら、後工程の段階でテーブル修正を行うと、様々なオブジェクトに連鎖的な修正が発生し、大変な労力が伴うからです。

まずはその点を念頭に置きながら、テーブル設計のポイントを確認していきましょう。テーブル設計を行う上で重要なポイントは次の４点です。

POINT

必要となるフィールドを決める
各フィールドのデータ型を決める
各フィールドのサイズを決める
主キーを決める
インデックスを決める

必要となるフィールドを決める

業務用のデータベースであれば、まずその業務にどういったデータが必要となるのか”要件”を整理します。例えば「顧客管理」を行うためにはどういったデータが必要か考えてみましょう。

フィールド	必要な理由
顧客名	顧客管理なので名前は必要
住所	客先への出張や郵便物発送を行うため必要
電話番号	電話連絡する際に必要
担当者	直接の対応相手を把握するため必要
メールアドレス	Eメールを送る際に必要

上記のように必要な理由を根拠建てながら洗い出していきましょう。きっとまだまだあると思います。こうすることで本来保持する必要のない不要なフィールドを持つことも防止できます。このように、あくまで業務視点で必要フィールドを洗い出していきます。

洗い出した必要フィールドは、全て一つのテーブルに保持する訳ではなく、通常は複数のテーブルに分割して管理します。分割に関しては”正規化”というルールがあります。

業務に必要なフィールドの他にも、定番として備えておくべきフィールドがいくつかありますのでご紹介します。

削除フラグ

テーブルからデータを削除する場合、”物理削除”と”論理削除”という二つの考え方があります。

削除種別	解説
物理削除	物理的にデータを削除すること。削除履歴が残らず、基本的に復元も不可。削除することでデータベースの空き容量は増える
論理削除	物理的には削除されずフラグを設定することで、見かけ上は削除されたように振る舞う削除方法。削除の履歴が残り、必要に応じて削除から復活させることもできる

テーブルに格納したデータを削除する場合は慎重に行う必要があります。
特にマスタテーブルの場合は他のテーブルと結合して使用しているケースが多く、むやみに削除すると思わぬ影響を与えます。目的や状況により物理と論理を使い分ける必要があるため、その選択肢を取れるように”削除フラグ”フィールドを備えておきましょう。

ＩＤ（連番）

ID は数字の 1 から開始される連続番号のフィールドのことです。（※必ずしも単純な連番とは限らず A0001 など目的に応じて作り込まれた番号でもOKです。）

ID を設けることで下記のような使い方をすることができます。

・データの並び順を維持できる
・主キーを割り当てるフィールドとして使用できる（後述）

テーブルに格納されているデータには明確な並び順は存在しませんが、いずれかのフィールドをキーにして昇順・降順に並び替えることはできます。ID を昇順で並び替えることにより登録順にデータを並び替えることができます。
また主キーとして利用できるフィールドが無い場合は、ID を主キーとすることでテーブルに主キーを保持することができます。主キーについては後述します。

更新日付/更新者

データベースを複数人で運用する場合、日々行われる様々なデータ更新を全て把握できる訳ではありません。特にマスタテーブルは他テーブルへの影響も大きいため、その更新内容を把握したいケースも多いでしょう。 更新日付 や 更新者 フィールドを設けておけば、そのデータに誰がいつ手を加えたかについて把握することができます。

ただしこの場合把握できるのは「何らかの変更が加えられた」という事実のみで、更新内容まではわかりません。業務運用上より詳しい更新履歴が必要な場合は、更新履歴テーブルという別テーブルに記録していく手段を取る必要があります。

備考

データベースを運用していると補足事項や特記事項、一時的なメモといった、いずれのフィールドにも馴染まないデータを記録したい場合があります。そういったケースへの対応として登録内容に縛りを持たせない 備考 を設けておくと便利です。

備考 には基本的にどのようなデータでも格納できますが、本来用意すべきであったフィールドの代替えとして使用するのは避けましょう。なぜなら、データ内容の一貫性が担保できず、データ活用がし難いからです。

備考はあくまで、参考程度の情報を付記するためのフィールドとして活用しましょう。

各フィールドのデータ型を決める

必要なフィールドが洗い出せたら、次は各フィールドのデータ型を決めましょう。”データ型”とは各フィールドに格納するデータ種別のことです。AccessはExcelと異なり、各フィールドに格納できるデータの種類を定める必要があります。

データ型には多くの種類がありますが、使用頻度が高いものは以下のとおりです。

データ型	説明	フィールド例
短いテキスト	最大255文字までの文字列を格納	氏名、住所、電話番号など
長いテキスト	1GBまでの文字列を格納	備考など
数値	数値を格納	数量、在庫数、仕入数など
日付/時刻	日付と時刻のデータを格納	生年月日、登録日、注文日時など
Yes/No	真偽値（Yes/No、True/False）を格納	チェックボックス、二者択一など

そもそもなぜデータ型を設定する必要があるのか？またデータ型種類の詳細については、こちらの記事で詳しく解説しています。

【テーブル】14種類のデータ型概要と使い分け

テーブル作成時に設定するデータ型について、全14種類の特徴と使用例を説明することで使い分けをお伝えします。

各フィールドのサイズを決める

短いテキスト や 数値型 の場合は、そのフィールドに格納できる文字数上限等を設定する必要があります。上限を設定するうえで”大は小を兼ねる”的に大きい文字数を設定しておけばいいだろう、と考えるのはお勧めしません。フィールドサイズを大きく設定すると、実際に格納されるデータよりも多くのストレージ領域が割り当てられます。例えば最大100文字までしか入力しないフィールドに255文字のフィールドサイズを設定すると未使用の領域が無駄になります。無駄な領域が増えると、データベースファイル全体のサイズも大きくなり、様々な処理のパフォーマンスにも影響を与える場合がありますので、適切なサイズ設定を心がけましょう。

momongacat

最近はPCの性能があがってそこまで神経質になる必要もないようですが、手を抜かずしっかり押さえておきましょう

短いテキストの場合

初期値として 255 が設定されており、全角半角問わず 255 文字分が格納できます。例えば電話番号欄であれば基本的に XXX-XXXX-XXXX 形式ですから、ハイフンを入れても 13 文字分あれば事足ります。255 のままでもデータ格納に支障はないですが、前述したとおり領域確保し過ぎとなるため 15 あたりに設定しておくとよいでしょう。

数値型の場合

初期値として 長整数型 が設定されています。長整数は”-2,147,483,648 ～ 2,147,483,647”範囲の整数を格納することができます。桁数の大きさによりバイト型 → 整数型 → 長整数型 → 単精度浮動小数点型 → 倍精度浮動小数点型の順番にデータ型が用意されています。

一般的には整数のみであれば 長整数型 、小数点も用いる場合は 倍精度浮動小数点型 に設定するのがセオリーです。

数値型のフィールドサイズについては、前述したデータ型の関連記事でも詳しく解説しています。

主キーを決める

前述した「必要となるフィールドを決める」で洗い出したフィールドの中から、”主キー（プライマリーキーともいう）”となるフィールドを決めましょう。主キーを設定することによりデータの整合性や検索処理のパフォーマンスを向上させることができます。主キーの主な特徴は以下の通りです。

・一意である：同じ値を持つレコードは複数存在できない。
・NULL値が許可されない：必ず何らかの値が入力されている必要がある。
・検索の効率化：主キーを基にした検索は高速に行われる。

なぜ上記の特徴があることで、データの整合性が確保できるのでしょうか？これは実際の業務視点から考えると分かりやすいです。

例えば社員管理のテーブルを運用する場合、当然のことながら同一社員を重複して登録してはいけない訳です。そこで通常は”社員コード”を設定し、同姓同名であっても別人として登録できるようにします。ただし社員コード自体を重複で登録してしまう可能性もあります。「重複したデータも存在する可能性がある」という事実は社員管理マスタとしては致命的です。本事例の場合は社員コードを主キーとすることで、物理的に重複登録は不可となり、必ず一意のデータであることが担保されます。

先生

主キーにできそうなフィールドが無い場合はID（連番）を作って主キーにしよう

また、主キーはNULL値も許可されません。そのため、社員コードの入力漏れや誤削除といったうっかりミスも防止することができます。「データが欠落していない」これもマスタデータの前提条件として重要でしょう。

最後に検索効率化ですが、主キーとしたフィールドは自動的にインデックスが適用されるため、検索時の処理速度が向上します。インデックスに関しては後述で詳しく説明します。

主キーのように、データベースにおいてデータの整合性等を担保する仕組みを「制約」といいます。こちらの記事ではデータベースで扱う6種類の制約について解説しています。

【テーブル】制約を理解する（主キー/外部キー/一意制約他）

データベースには、データの信頼性を高めるうえで重要な「制約」という概念があります。本記事では制約の概要や、Accessでの具体的な設定方法を解説します。

インデックスを決める

フィールドには任意で”インデックス”を設定することができます。インデックスとは本の巻末にある索引のようなもので、索引があれば目的の情報を素早く見つけ出せるように、インデックスもデータの並び替えや検索を高速に行うことができます。前項で説明した主キーはインデックスとしての要素も持ち合わせています。

こんなに便利なら全てのフィールドにとりあえずインデックスを設定しておけばいい、と考える方がいるかもしれませんがインデックスを設定することにはデメリットもあります。

本の索引と同様に、インデックス情報というものをシステム内部に保持することとなります。インデックスを設定し過ぎるとインデックス情報自体が大きくなりファイルサイズの肥大化にもつながります。また、フィールドのデータ更新が頻繁に行われると、その都度インデックス情報も更新する必要があるため、場合によっては検索速度のパフォーマンスが低下することもあります。

インデックスを設定する対象フィールドは、検索条件やデータ並び替えに使う想定のフィールドに限定することによって、バランスよくデータ活用を行うことができます。

設計書にまとめる

テーブル設計で説明した４つのポイントがある程度まとまったら、その内容を設計書（定義書や仕様書ともいいます。）にまとめましょう。設計書を作りながら各項目を決めて行ってもOKです。

設計書の目的と効果

そもそもなぜ設計書を作成する必要があるのか、また作成したらどういう効果があるのかについて説明します。

テーブル作成作業をスムーズにする

実際のテーブル作成作業にあたり、何の資料もなく思いつくまま進めると重要な見落としがあったり、そもそも考えながら作業するので時間的にも不効率です。必要な要件をまずは設計書の形に落とし込む。さらに共同開発者がいれば、その内容を確認/共有することでより齟齬のないものとなります。設計書を手元に置きながら作業を進めることができるので、開発効率が向上します。