Access Upsizing Toolがもたらすデータベースアプリケーションのシフトをめぐる考察

秋月 巌 AKIZUKI, Iwao
首都圏コンピュータ技術者共同組合

　時々「なぜ（ORACLE7ではなく）SQL Serverなのか?」と考えることがある．「なぜ（UNIXではなく）WindowsNTなのか?」という問いに対してなら容易に説明できるのに，ORACLE7 Workgroup serverに対するSQL Serverの優位性ははっきりしない．また，その逆も明確でない．

　こんなことをいうと怒られてしまいそうだが，多分，RDBMSはORACLEだろうが，Microsoftだろうが，たいして差がないのだろう．ある人がORACLE7のロックシステムの優秀性を言えば，別の人はSQL Serverの低価格や，接続の容易さを長所としてあげるだろう．だが，システム内蔵のレコードロックシステムが必須になるケースはそう多くないし，世間がORACLE7に対して抱いている高価格というイメージは，UNIX版に対するものから生じる誤解が含まれてはいないだろうか．

　もっとも，クライアントの開発ツールにVisual Basicを選択した場合は，SQL Serverのメリットが活きてくる．Visual Basicアプリケーションから見たとき，SQL Serverは1つの巨大なOLEオブジェクトだということができるし，RDOを使ってODBC経由でサーバーにアクセスする場合，ODBCドライバの安定性も大きなポイントになる．Visual Basicが今後，クライアント／サーバーシステム開発ツールの主流になるのは間違いがないから，クライアントツールに合わせてSQL Serverが選ばれるというケースもありえる．

　ただ，そういった本末転倒な理由だけでなく，WindowsNT Serverを導入した企業が，SQL Serverを導入するケースはますます増えるはずである．それは，今後，SQL Serverが受け入れられていく市場が，過去の資産との互換性を必要としないということの他に，OEACLEというブランドの神通力が通じない世界であるということにも関係がある．

　さらには，小規模向けシステム構築に向いたベストセラーのRDBMSパッケージであるところのMicrosoft Accessの存在も，SQL Server導入の引き金になる公算が高い．

　Accessは低価格，多機能なRDBMSだが，SQL Serverとは設計されているコンセプトが違う．これらの2つの違いを説明するのに，デスクトップPCとPCサーバーを引き合いにだすことが多い．この2種類のPCは機能も性能も違わないのに価格には4倍の開きがある．この価格差は，主に信頼性や対（耐）障害性のために費やされている．

　SQL ServerとAccessの差も，これに類する．機能はAccessの方が多いくらいである．そのため，MicrosoftはAccessによってSQL Severを操作したり，プログラミングをしたりするための仕掛けを用意している．一部はAccessのネイディブな機能として提供され，残りはAccess Developer*s Toolkit（ADT）のAccess Upsizing Tool（AUT）として提供される．

　ただ，Microsoftは，Accessでシステム開発をしておいて，必要に応じてAUTでアップサイズすれば，デスクトップシステムがC/Sシステムとして完成すると宣伝しているが，これはほとんどまやかしである．そうではなくて，AUTはSQL Serverを正しく理解している人が作業工数を減らすために使うべきものである．

　つまり，Accessがわかっていれば，SQL Serverが使えるといいたげなキャッチフレーズはMicrosoftのマーケティング戦略以外の何ものでもない．しかし，このマーケティングは圧倒的な成功を納めるだろう．少なくとも，新規に導入するユーザーが，まるっきり新しいものよりは，少しは身近にあるものを選択することは容易に想像がつく．

　確かに，導入時にAccessの機能を使うと，SQL Serverは本当に簡単に動きはじめる．インストールは簡単だし，接続だって，ODBCの設定でサーバー名さえ指定すれば，ほとんど何の問題もなく終了するはずである．

　しかし，SQL Serverはバックアップ一つとってみても，Accessのようにファイルをコピーをしておけばいいというものではない．正しくバックアップの手順を踏み，メンテナンス計画を立てる必要がある．それ以前にデータベースを作成するためだけでも，データベースデバイスの作成や，データベースの設定を行なう必要がある．

　AccessユーザーがSQL Serverを使うべきでないと言っているのではない．何にでも入口は大切だし，チャレンジ精神はもっと重要だ．しかも，SQL Serverの必要性のある現場は多いのに，エンジニアがいないというだけの理由で導入できない企業も現実的に多い．ただ，それなりの覚悟が必要であり，導入した後も学習のための努力を維持する必要がある．もし，それが無理ならば，Access単体で処理する方が効果的であることは断言する．

図1：SQL Enterprise Manager

　SQL Serverにはデータベースを操作するためのSQL Enterprise Manager（図1）が付属する．これはSQL Serverに特化したデータベース操作ツールで，SQL Serverの標準装備とみなすことができる．SQL Serverのエンジニアは，通常このSQL Enterprise Managerを操作し，データベースやテーブルを作成したり管理するようになる．一方，SQL ServerにはインタラクティブSQLと呼ばれるツールが付属し（SQL Server6.5からはインタラクティブSQLの機能もSQL Enterprise Managerに統合された），SQLを使って，データベースの操作をおこなえる．つまり，インタラクティブSQLはCUIツールで，SQL Enterprise Managerは，そのGUIバージョンと呼ぶことができる．

　一方，AccessはJetデータベースエンジンを標準で装備するが，汎用的なデータベースマネージメントツールである．というのは，Jetデータベースエンジン自体がドライバの開発により，汎用的に使用できるような設計になっているからである．PARADOXテーブルや，xbaseテーブルのような代表的なファイル共有データベーステーブルにアクセスできるほか，ODBCを経由してSQLデータベースサーバーにリンクすることもできる．

　だから，Accessネイティブの機能だけでも，SQL Serverに対してテーブルのインポート／エクスポートが可能である．テーブルのインポート／エクスポートができるということは，Accessでテーブルを作成しておいてSQL Serverに出力すれば，SQL Serverのテーブル作成をAccessでできるということになる．オートナンバー型のような互換性のないデータ型は使えないが，通常使うようなデータ型は互換性があるので，問題が起きることはあまりないだろう．

図2：アドインツール

　このようなAccessの特徴を活かし，SQL Server用に機能を拡張したものがAUTである．AUTに付属する機能には，SQL Serverブラウザとアップサイジングウィザードがある．これらはAUTをインストールすると，Accessのアドインとして登録される（図2）．

図3：SQL Serverブラウザ

　SQL Serverブラウザ（図3）は，SQL Enterprise Managerの機能の一部をAccessのインターフェイス上で提供するものである．ODBCを経由してSQL Serverに接続すると，普段Accessのテーブルが表示されているデータウインドウにはSQL Serverのオブジェクトが表示される．操作はAccessのスタイルのまま，Accessのオブジェクトを扱う要領でSQL Serverのオペレーションができる．また，SQL Enterprise Managerではデータを参照するためにSQLを書かなければならないが，SQL Serverブラウザなら，データウインドウからボタンのクリックで参照できる．ただ，SQL Executiveの設定や，バックアップの指定など，SQL Enterprise Managerでなければ利用できない機能も多い．Accessだけで，すべてがこと足りるわけではない．

図4：アップサイジングウィザードで新規データベースを作成

　もう1つのツールであるアップサイジグウィザード（図4）は，Accessで構築したデータベースをSQL Serverに移植するためのエキスパートシステムである．アップサイジングする際に新規にデータベースデバイスやデータベースの作成ができるため，SQLブラウザと組み合わせて使うことにより，SQL Serverをスタートさせるための処理はほとんどAccessで代行してしまえる．

　AUTはアップサイズしたデータベースを，そのままAccessのMDBファイルにリンクを張るので，今までアクセスで構築していたシステムが，そのままSQL Serverを使って運用できる．ただ，このような安直な方法はC／Sシステムとしてはまともに動作しない．それはJetデータベースエンジン経由でサーバーにアクセスすることにパフォーマンスの問題があるのが主な要因だが，それ以外にも多くの条件が複雑に絡み合う．

　現実的な話として，オープンシステムはまともに動けば「運がいい」というレベルのものである．大手ベンターのあるセールスマンは「オープンシステムが動くのは奇跡」と言い切っている．コンピュータジャーナリズムはオープンシステムのメリットを主張することに存在意義を見出していたが，その影には多くの失敗例がある．

　ネットワークを使用するシステムを設計するときに考慮すべき条件は多い．

　これ以外にもオペレータの習熟度などシステム以外の条件も考慮しながら，全体を設計する必要がある．このようにケースごとに異なる条件をまったく考慮にいれず，一律にAUTがおこなうアップサイズの結果が満足に機能するわけはない．パフォーマンスチューニングはシステムを完成してからおこなうものではなく，設計の段階で配慮しておくべきものなのである．

　AUTによるアップサイズが成功するにはいくつかの条件が必要である．

　もちろん，こんな条件が得られるならば，アップサイジングなどする必要はない．数少ないメリットは信頼性の向上だろう．

　こんなAUTだが，アップサイズのメカニズムは優秀である．ただし，それを理解するためには，アップサイズとエキスポートの違いについて理解することが不可欠の要素となる．

　まず，Accessの機能であるエクスポートは，Jetデータベースエンジンのオブジェクトであるテーブルの構造とデータを他のデータベースに出力する．

　それに対し，AUTがおこなうアップサイジングはテーブルの構造だけでなく，インデックス，入力規則，デフォルト値などの属性も同時にエクスポート先のテーブルに付加する．また，テーブル間のリレーションが設定されている場合は，そのリレーションに該当する機能をエキスポート先のデータベースに設定する．

　機能的にSQL ServerとAccessで一致しない場合，AUTはSQL Serverにない機能をトリガを使用してシミュレートする（表1）．この処理はAccessのオートナンバー型フィールドをテーブルに設定している場合も適用される．

図5：テーブルに入力規則を設定

図6：アッフサイジングのオプション

図7：トリガの生成

　更新，挿入トリガには次のコードが生成される．このコードは「Zip」フィールドに0以下の値がコミットされたら，エラーを発生させ，処理を取消すことを指示している．

IF (SELECT Count(*) FROM inserted WHERE NOT (Zip>0)) > 0
    BEGIN
        RAISERROR(777685, 16, 1)
        ROLLBACK TRANSACTION
    END

　このようにAccessで設定した機能を処理するために，AUTはプログラムを生成する．たとえば，親テーブルのレコードを削除したら，それにリンクしている子テーブルのリンクレコードも自動的に削除するといったトリガの生成も，Accessにリレーションを設定することで可能となる．

  if exists (select * from sysobjects where id = ⇒
  object_id('dbo.Name_挿入トリガ') and sysstat & 0xf = 8)
	drop trigger dbo.Name_挿入トリガ
  GO

  CREATE TRIGGER Name_挿入トリガ ON Name FOR INSERT AS

  /*
   * ﾌｨｰﾙﾄﾞ 'Zip' の入力規則
   */
  IF (SELECT Count(*) FROM inserted WHERE NOT (Zip>0)) > 0  
    BEGIN

        RAISERROR(777685, 16, 1)
        ROLLBACK TRANSACTION
    END

  GO

 注：⇒箇所は画面の都合で折返してます

  if exists (select * from sysobjects where id = ⇒
  object_id('dbo.Name_更新トリガ') and sysstat & 0xf = 8)
	drop trigger dbo.Name_更新トリガ
  GO

  CREATE TRIGGER Name_更新トリガ ON Name FOR UPDATE AS


  /*
   * ﾌｨｰﾙﾄﾞ 'Zip' の入力規則
   */
  IF (SELECT Count(*) FROM inserted WHERE NOT (Zip>0)) > 0  
    BEGIN
        RAISERROR(777685, 16, 1)
        ROLLBACK TRANSACTION
    END
  GO

 注：⇒箇所は画面の都合で折返してます

図8：IISアドインメニュー

図9-1：作成するシステムのタイプを選択

図9-2：入力する対象フィールドを選択

図10：生成された入力フォーム

　もう一つ，マイクロソフト株式会社のホームページからダウンロードできるAccess 95 Value Packに付属しているIISアドインについて触れておきたい．このツールもまた，Accessのアドインプログラムとして動作し（図8），IDCプログラムに必要なIDCファイル，フォームつきのHTMLファイル， 結果のテンプレートとなるHTXファイルを自動生成する．AUTのWeb専用版という訳ではもちろんないが，Accessデータベースのシフトという観点では関連があり，用途を絞った分だけむしろ利用されるケースは多いのではだろうか．

　IDC（Internet Database Conector）は前々号でも説明したが，Microsoft Internet Information ServerとODBCを接続するISAPIアプリケーションである．IDCを利用することで，容易にWEBからデータベースへとアクセスするためのシステムが構築できる．

　IDCはODBC汎用に設計されているため，ODBCドライバのあるデータベースならば，どのデータベースにでも接続できる． AccessのIISアドインはIDCシステム作成に必要なファイルを，Jetデータベースエンジンを元に作成する．これらのファイルはJetデータベースエンジンを使用することを前提に生成されるが，テーブルの構造さえ一致していれば，無変更でSQL Serverに利用できる．

　IISアドインが提示する質問（図9）に答えていけば，入力フォーム（図10）やクエリー処理に必要なファイル（リスト3）を作成する．

　作成できるのは次のようなタイプのページである．

　これらを上手に利用すれば，有効なイントラネットデータベースシステムを短時間で作成できる．生成されるフォームのクォリティは十分高い．ただ，高度なシステムを作成しようと思つたら，動的に作成されるページが次の入力フォームになる必要があるが，そのようなアーキテクチャには対応していない．

  Datasource: Web SQL
  Template: ZipCode.htx
  DefaultParameters:
  SQLStatement:
  +INSERT INTO "Zip" ("郵便番号", "住所")
  +VALUES ('%郵便番号%', '%住所%');
  #IDC-Insert FrontHTM-ZipCode.htm ReportHTX-ZipCode.htx  

　AccessはSQL Serverのフロントエンドとして開発されたわけではない．独立したRDBMSなのだが，SQL Serverを活用するために利用できる機能が装備されている．それにアドインとして機能するAUTは動作の不安定な部分もあり，信用できるツールとはいいにくい．それでも，わずらわしい処理を代行したり，Accessのユーザーフレンドリな環境とSQL Serverをつなぐブリッジの役割を果たす効果は大きい．

　アップサイジングツールという言葉に惑わされさえしなければ，使用する価値のあるツールである．アップサイジングという言葉には，オーバードライブプロセッサのように，簡単な差し替えだけで性能が劇的にアップするようなイメージがある．AUTにそのような効果はない．それでも，使いなれた操作環境で，より大規模なシステムに対応できるRDBMSを操作できるのは，Accessユーザーにとって大きなメリットだろう．

VB Magazineライブラリ | Visual Basicコースホームページ
int21 ホームページ | PCDN ホームページ