SQL2005とAccess：

もしかして各ユーザーがそこそこスキルがあって、リンクテーブルを元に自分たちで好き勝手にクエリを組むような状況でしょうか。

人によってはフォームやレポートで何か作ったり。

うちがちょうどそういう状況なんですが、もしそういう状況であれば、そこそこ諸刃の剣なので体験的な注意点をいくつか。

ユーザー権限はきちんと設定されていますか？

saアカウントやdbo権限を持つアカウントに適切にパスワードが設定されていますか？お勧めはActive Directoryと連動させたセキュリティ接続で、YourDomain\Domain Usersに必要なテーブルの読み取り権限（場合によっては部分的な書き込み権限）を与えることです。読み取り専用のユーザーIDを作成してパスワードを布告した場合、情報の流出などがあっても誰がアクセスしたかを判断するのは困難になりますので注意してください。パスワードを保存したMDBを配布したとしてもバイナリを見るとパスワード丸見えなので注意。

SQLServerは基幹システムではないですか？

もし接続させようとしているSQLServerが基幹システムや重要なシステムが動いているサーバーであれば、ユーザーの処理内容によっては負荷の影響が無視できません。アクセスにはパススルークエリという手法もあり、組み方によってはSQLServerをダウンさせるような膨大な処理量のSQLを投げることも可能です。

根幹的なデータには直接アクセスさせない

「現状のデータをインポート」とあるので、おそらく副次的なデータだとは思うのですが、もしそのデータの損失が経営に大きく影響するようなものであれば、ユーザーに直接リンクさせるべきではありません。SQLServerのユーザー権限を適切に設定すれば読み取り専用にすることもできますが、二重化の意味も含め、日次バッチなどで別データベースに複製したものにアクセスさせるのをお勧めします。

本当にその処理は効率的ですか？（書き込み編）

複数のユーザーがリンクテーブルに対して直接データを登録しているのなら、もしかしたらきちんとアプリケーションにする必要があるのかもしれません。また、「特定のデータがあること」を前提として処理をしたものの、他のユーザーがデータを変更・削除して、誤った結果になっていても気づかないかもしれません。リンクテーブル経由で書き込みを認める場合は、業務ルールをしっかり定める必要があります。

本当にその処理は効率的ですか？（読み取り編）

取り扱うレコード数にもよるのですが、アクセス上のテーブルとリンクテーブルを結合した処理は、あまりよい動作をしません。例えばアクセス独自の関数を使った集計クエリなどはSQLServerのリンクテーブルに対して、アクセス上にいったん全データを取得する動作をします。IIFを含んだ1000万件のレコードのSumとか考えたくもないですｗ。ユーザーは最終的なデータが取得できれば「仕事ができている」と思いがちですが、実は1クエリに30分かかるような処理がパススルークエリを使えば10秒で終わったりもします。アクセスはクエリ待ちの間CPUリソースを食い潰すので他の作業ができず、実は効率が落ちていたりします。ユーザーがどんな処理をしているか拾い上げて、こまめに指導したほうがよいかもしれません。

ユーザーや業務の流動性を考慮していますか？

上記の内容に対して「ユーザーはそこまでできないから大丈夫」「ユーザーは理解しているから大丈夫」と手抜きしていませんか？いまは大丈夫でも、人事異動などですばらしく技術の高いユーザー、致命的な処理を平気でするユーザーが来るかもしれません。どんな人が来ても対応できる（最低限教育できる）ようにしておきましょう。

書けばいくらでもあるのですが、これ以上はどこまでの作業をどのレベルで許可するかでまったく違うので、具体的な事例があるようであれば、また別途質問を立ててください。

答えられる範囲で答えますー