来月2月20日、PASSJカンファレンスで、『 Access からのステップアップ』（ビギナートラック）というテーマで、お話をすることになりました。参加費は無料ですので、ぜひ皆様のご出席を期待しております。

今回のセッションでは、Access の MDBファイル共有でシステムを構築している方々が、そろそろ Access から SQL Server や MSDE に移行することを検討していることを想定しています。

移行するときの一番の問題は、データベースの物理アーキテクチャをどのように設計を行うかだと思います。

Access の MDB データベースでは、物理設計という概念は一切ありませんでした。このため MDB データベースでは、テーブルの設計に主眼を置いて、システムを構築してきたと思います。ここでいう物理設計とは、テーブルのさらに下の次元の話で、テーブルに記憶されるデータと、実際の記憶装置に作成される物理ファイルとを、どのように対応させるのかというお話です。

◎どうして必要？

もちろん SQL Server や MSDE でも、物理設計を省略してすべてをデータベースサーバーに任せてしまう方法もあります。

例えば、データベースを作成するときに

          CREATE DATABASE データベース名
          （ほかのパラメータは全部省略）

という SQL文を実行した場合、データベースを記憶する物理ファイル（データ ファイル１個とトランザクションログファイル１個）は、システムの既定のフォルダに作成されます。このようにして作成されたデータベースは、物理設計が省略されたといいます。

この例では、このデータベースに作成されたテーブルに記憶されるレコードのデータや検索用インデックスの情報は、すべて同じデータファイルの中に記憶されます。

テーブルの個数が多くなったり、レコードが多くなったりすると、１個のデータファイルの中をあっちこっち探すことになります。ファイルの中を移動するだけで、ものすごく時間的損失が発生しているのが予想できます。

このような状態では、せっかくのデータベースのエンジン性能を生かすことができない場面が出てきます。特に、マルチ CPU 環境や SCSI 系高速 DISK などを使用する、いわゆるデータベースサーバー専用機では、せっかくのハードウェア性能が生かしきれません。データベースの物理設計が必要になるわけです。

◎ぜひ、この機会に物理設計のマスターを！

一般的にデータベースの物理設計は、理解するのは非常に難しいと言われております。しかし SQL Server / MSDEでは、その設計概念が驚くほどシンプルになり、有識者から講義を受ければ、すんなりと理解できるようやさしくなりました。でも、初学者が独学で覚えるには多少難しいかもしれません。

またデータベースの物理設計が理解できると、運用中のデータベースサーバーに新しく DISK を増設して、そちらに引越しを行うときにはどうすればよいのかなど、サーバー全体のメンテナンス作業が理解できるようになります。

ぜひこのセッションに参加して頂いて、データベースの物理設計をマスターして頂きたいと思います。

（2004/01/15）