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

Accessで複数人が同時に利用することを想定した業務ツールを作る際、データを安全かつ効率的に共有・管理するために非常に重要なのが「リンクテーブル」の活用です。

この記事では、そんなリンクテーブルについて、

「そもそも何？」という基本的な理解
「どうやって使うの？」という具体的な活用方法

を、わかりやすく解説していきます。

リンクテーブルとは
リンクテーブルの活用メリット
具体的な設定方法
1. リンクテーブルの接続
まとめ

リンクテーブルとは

現在開いているAccessファイルの中で、別のAccessファイルに保存されているテーブルを参照して利用することを「リンクテーブル」といいます。リンクテーブルを設定すると、あたかも自分のAccessファイル内にそのテーブルが存在するかのように操作できますが、実際には元の別のAccessファイルにデータがあります。イメージとしては、以下の図のようになります。

例えば、同じネットワーク上にPC A、PC B、NAS（ネットワーク接続ストレージ）があり、それぞれの場所にAccessファイルが保存されているとします。

この時、PC Aの「111.accde」が、PC Bから「テーブルB」を、NASから「テーブルC」をリンクテーブルとして参照すると、PC Aの「111.accdb」内では「テーブルA」「テーブルB」「テーブルC」の3つのテーブルを、自分のテーブルのように扱うことができるようになります。

重要な点として、リンクテーブルのデータの実体は、あくまでリンク元のPC BやNASにあるということです。そのため、PC Aでリンクテーブルのデータを更新した場合、その変更はリンク元であるPC BやNASの元のデータに直接反映されます。

以上がリンクテーブルの概要です。次項ではリンクテーブルをどのような場面で使用すべきかについて、具体例を交えて解説します。

リンクテーブルの活用メリット

もしPC Aのパソコンの中（ローカルディスク）に「111.accdb」があって、「テーブルA」「テーブルB」「テーブルC」というデータが入っていたとします。この場合、当然ながらこの「111.accdb」を直接使えるのはPC Aだけです。一人で仕事が完結するならこれでOKですが、複数の人がデータを見たり、一緒に作業したりする必要がある場合は、このままでは困ってしまいます。

そこで、よくある対応として、ローカルにあった「111.accdb」というAccessファイルを、みんながアクセスできるネットワーク上のフォルダに移動することが考えられます。こうすれば確かに、複数の人が同じAccessファイルを同時に開いて操作できるようになります。

しかし、使う人数が2～3人くらいなら特に問題は感じにくいかもしれませんが、もっと多くの人が同時にアクセスするようになると、動作が遅くなったり、最悪の場合、データが壊れてしまうといったリスクが出てきます。

こんな時にこそ、リンクテーブルが役に立ちます。次の項目で詳しく説明していきます。

リンクテーブルにより疑似的なクライアント/サーバー型を作る

Accessで業務用ツールを作成する際の定石があります。それは、ユーザインターフェイスを担うフロントエンド（フォーム・レポート）とデータ保存場所であるバックエンド（テーブル）を分離する方法です。これは疑似的なクライアント/サーバー型のデータベースを構築する手法ともいえます。

クライアント/サーバー型とは

サーバーがデータ管理と処理を行い、クライアントはネットワーク経由でサーバー側に操作を要求する仕組みです。複数ユーザーでのデータ共有や集中管理に適しています。本格的なデータベースシステムで一般的に採用されている仕組です。

《具体的には》

リンクテーブルを活用した、疑似的なクライアント/サーバー型のイメージは、こんな↓感じです。

「111.accdb」はフォームやレポートといったオブジェクトで構成され、テーブルは基本的にリンクテーブルです。本ツールの画面を通じて入力されたデータは、ネットワーク上のNASに格納された別のAccessファイルがリアルタイムで更新されます。

こういった方法をとるうえでのメリットには次のようなものがあります。

複数ユーザの共有が行いやすい

各自が利用するAccessツール（今回の事例「111.accdb」）は個々の端末のローカルに配置されるため、1つのAccessファイルを複数人で共有するよりも、一般的に処理パフォーマンスが向上します。
リンク元のテーブルへのアクセスは複数人による同時利用が想定されますが、通常の業務ツールには複数の機能があり、それぞれの機能で利用するテーブルも異なっていると考えられます。そのため、テーブルへのアクセス頻度やタイミングも自然と分散することが期待でき、その意味でも利用人数が2～3人を超えても、比較的安定して利用できる可能性が高まります。

エラー対応（データ破損時）へのリスク軽減

前項では複数人で利用する際のハードルが下がる点について説明しましたが、それでも大人数での同時アクセスなどを原因とするデータ破損といったトラブルは皆無ではありません。単一のAccessファイルで破損などが起きた場合、復旧の対象はテーブルだけでなく、フォームやレポートといったオブジェクトにも及ぶ可能性があり、その影響は決して小さくありません。一方、フロントエンドとバックエンドを分離している構成であれば、エラーの原因を特定しやすく、原因がテーブルであればバックエンド側のみの修正で済むため、エラー対応における復旧作業の負担を軽減できます。

バックアップファイルの保存容量軽減

前項で、エラー対応の負担が減るという話をしましたが、そもそもエラーが実際に発生した際の影響を可能な限り小さくするためには、日々のバックアップ作業が必須です。Accessファイルにおけるバックアップは、単にファイルの複製を数世代保管することですが、全てのオブジェクトが一体となっているAccessファイルを数世代複製することは、記憶領域の利用効率から考えて非効率でしょう。
疑似的なクライアント/サーバー型であれば、基本的にデータ本体（テーブル）のみ複製すれば良いので、その分の記憶容量を節約できます。

ファイル容量の制約

Accessファイルには、保存できる容量に2GBという制約があります。大規模な業務ツールをAccessで作成する場合、この制限は大きな課題となります。しかし、リンクテーブルを活用することで、テーブルを複数のAccessファイルに分割し、ツール側のAccessファイル（フォーム、レポートなどのフロントエンド）のファイルサイズを抑えることができます。