特集：VBでOracle Database開発入門（前編） .NETによるOracle Database開発とは？ 初音 玲 2008/11/11

Page1 Page2 Page3

　業務システムの構築において、使用する開発言語とデータベースの選定は、特に重要な事項の1つだろう。ここで業務システムの特性と合わないものを選んでしまったり、組み合わせを間違えたりすると、開発期間の長期化や稼働が不安定なシステムになるなどの問題が発生する可能性がある。

　そこで本特集では、開発言語「Visual Basic 2005／2008」とデータベース「Oracle Database 11g Release 1」の組み合わせが、実際どのような業務システムに対して、どれくらい有効なのかについて考えてみたいと思う。

■.NETで、なぜデータベースが必要なのか？

　すごく基本的なことだが、そもそも業務システムの構築にはOracle DatabaseやSQL Serverなどのデータベース（製品）がなぜ必要なのだろうか。まずは、データベースがなかったころまで時代をさかのぼってみよう。

●データベースが出現する前の時代

　データベースが存在する前にも、システム構築は行われていた。そして当然ながら、そのようなシステムでも業務データをどこかに保管する必要があった。

　コンピュータ・システムが登場した当初は、ハード・ディスクなどの記憶媒体は高価であったし（ハード・ディスクが存在しなかった時期もある）、扱うデータ量もいまと比べたら少ないものだったので、データの保管は紙テープやパンチ・カード、磁気テープなどの外部記憶媒体を利用していた。

　例えばパンチ・カードの利用では、オペレータが必要なデータをパンチ・カードの中から探し出し、管理番号順に並び変えてからパンチ・カード・リーダにかけるということが行われていた。「業務システム」という言葉を人間系（＝人による作業）も含めた「ある業務を遂行するための全体の仕組み」とするならば、このときのオペレータの仕事はまさに、パンチ・カードの束という「テーブル」から、特定のパンチ・カードという「レコード」を探し出すというデータベース（DBMS：データベース管理システム）の検索機能を担っていたといえるだろう。いうなれば、このパンチ・カードは初期のデータベースだったといえる。

図1　パンチ・カードのデータベース

　このように業務システムがコンピュータで動き始めた初期のころからすでに、データベースに相当する仕組みは業務システムにとって必要不可欠だったが、その当時はまだそれをコンピュータ上のシステムとして実装するまでにはハードもソフトも成熟していなかった。

　時代が進み、DASD（Direct Access Storage Device：直接アクセス記憶装置）と呼ばれる内部記憶装置の容量も増大し、汎用機でさまざまな業務システムが動くようになってくると、それぞれの業務システムの構築時には独自のデータベースを構築するようになってきた。もちろん、その機能や性能は、担当開発者のスキルに依存してしまっていたが、データの絶対量が少なかったので試行錯誤による性能改善であっても必要な性能を確保できていたのがこの時代だ。

　しかしこのような独自のデータベースでは、マルチユーザーによる同時アクセス時の排他の問題を解決したり、データ件数の増加に合わせて効率的なデータ管理のための機能を追加したりしていくうちに、データベース周りのコード量が肥大化し、メンテナンス性や品質の問題が表面化してきた。

　そこで登場してきたのが、業務システムと切り離すことのできる汎用性の高いデータベース製品（DBMS：DataBase Management System）だ。データベース周りの機能を開発対象から除外し、その部分に既存のデータベース製品を導入することで、開発期間が短縮できるだけではなく、バグの発生を抑えることもでき、少しでも早い完成を待ち望んでいる顧客の元に、より高品質な業務システムを提供できるようになった。

　このような背景と経緯が「汎用性を保ちつつ性能を向上させる」というデータベース製品の永遠ともいえる命題を生んだのだ。

●データベースとは？

　データベースの現在の主流は、リレーショナル・データベース（RDBMS:Relational DataBase Management System）だ。リレーショナル・データベースは、1970年に米国IBMのDr. E.F.Codd氏が提案した「リレーショナル・モデル」と呼ばれる考え方に基づいたデータベースで、1980年ころから実用化され始めた。

　リレーショナル・モデルの特徴は、現実世界の情報を複数の「テーブル（表）」として管理し、表と表の関係は「リレーションシップ」として管理するという点だ。

　例えば、社員テーブルと（月ごとの）給与テーブルの2つの表があったときには、社員と給与データの間には「1対n」というリレーションシップがあるとするのがリレーション・モデルだ。次の図はこのモデルを図示したものだ。

図2　社員テーブル−給与テーブルのリレーションシップ

　リレーション・モデルの良いところは、個人の特定を氏名のようにコンピュータが不得意な同字異義語ではなく、社員No（社員番号）を主キーにすることで区別できる点、テーブル間のリレーションシップ（外部キー）により存在しない社員Noのレコードが給与テーブルに格納できないように定義できる点だ。

　このような仕組みにより、複数のテーブルに情報が分かれていても情報の一元管理が可能になり、また、情報の特性ごとにテーブルが分かれているため仕様変更の範囲が限定され、仕様変更に対する自由度も向上している。

　以上のように、リレーショナル・データベースは、選択したモデルも優れており、SQLという非手続き型問い合わせ言語の採用もあって「開発者に優しい」ものだったので、現在の主流となり得たと考えられる。現在、RDBMSの代表的な製品としては、例えば、オラクル社によるOracle Database、マイクロソフトによるSQL ServerなどがRDBMSの代表的な製品である。

●SQLとは？

　SQL（Structured Query Language）の基本は、ある条件を満たした集合に対する操作の実行だ。例えば、1レコードを取り出すSQL文とは、特定の1レコードのみの集合を作成する操作だといえる。

　ちなみに、SQL（エスキューエル）の起源はIBM社のデータベース用言語であるSEQUEL（シーケル）だが、データベースの発展とともに一般化され、現在ではANSIやISOで規定される言語になった。ただし、規格化はされているが各ベンダが独自に拡張してしまっているため、ベンダ間に共通の汎用言語であるという認識は持たない方がよい。

　本特集では、Oracle Databaseにスポットを当てているので、記事中のSQL文は、特に断りがなければOracle Database版SQLである「PL/SQL」を使って記述している（ちなみにSQL ServerではT-SQLというSQLが使われる）。

●なぜ、Microsoft Office Accessではいけないのか

　Oracle DatabaseやSQL Serverなどのデータベースが（自動車の）トラックだとすれば、Microsoft Office Accessは原動機付自転車のようなものだ。原動機付自転車は、トラックが運ぶような大量の荷物を運ぶことはできない代わりに、ピザやソバなどのような小さな荷物を出前するのには向いている。同様にAccessも個人が生活の中で取り扱う程度の少量データであれば問題はないが、企業の基幹システムには不向きだ。

　基幹システムに向かない最も顕著な例が、ファイル・サーバの共有フォルダに.MDBファイル（＝Access用のデータベース）を配置して、複数のクライアントから同じ.MDBファイルを使うようにしたシステムだ。このときのシステム構成のイメージを図示すると次の図のようになる。

図3　Accessのネットワーク対応

VB＆Accessから.MDBファイルと入出力するときは次のような流れになる。 　（1）VB＆AccessからCOM連携でDAOを呼び出す 　（2）DAOは内部的にJetエンジン（AccessのDBエンジン）を操作する 　（3）Jetエンジンは.MDBファイルとファイル入出力を行う Acceesのネットワーク対応は（3）のファイル入出力の部分で発生する。

　図3の「現実の姿」にあるように、Access自体にはネットワーク対応機能はなく、実際にはデータベースのエンジン部分（Jetエンジン）はクライアント側にあり、.MDBファイルだけがサーバ側にあるという状態になる。

　そのため、複数のクライアントから.MDBファイルを更新するような場合、サーバ側にあるデータベースが複数のクライアントからの依頼を集中的に処理するのではなく、それぞれのクライアントにあるデータベース・エンジンがおのおの依頼を処理するために.MDBファイルにアクセスすることになる。

　つまり、複数のクライアントで同時に依頼が発生した場合に、その競合を解消するためのベースは、データベースの機能ではなくファイル・サーバのファイル共有がベースとなっている（.MDBファイルを使用しているときは.LDBファイルを作成してほかのクライアントに「使用中」をアピールするなど）。そのため、このような共有ベースの形態では（確実な競合回避が保証されず）.MDBファイルが壊れることがあるなどの問題が指摘されている。

　一方、SQL ServerやOracle Databaseでは、図3の「誤解されている姿」のようにデータベース・エンジンはサーバ側に1つだけ存在し、各クライアントからの依頼を一括して処理する形態になる。この形態であればデータが実際に格納されているファイルに対する入出力はデータベースが一括管理することになるので、ファイルが壊れる可能性は低くなる。

　以上の説明で分かるように、業務システムではやはり（Accessではなく）RDBMSが必要である。

　それではいよいよ、RDBMSの1つである「Oracle Database」について説明していこう。まずOracle Databaseの製品について紹介し、その後、Oracle Databaseを利用する場合のプログラミング環境について解説する。

INDEX
	[特集］VBでOracle Database開発入門（前編）
	.NETによるOracle Database開発とは？
	1．.NETで、なぜデータベースが必要なのか？
	2．Oracle Databaseの歴史と最新のOracle 11gとは
	3．Oracleデータベース開発のテクノロジ
	[特集］VBでOracle Database開発入門（後編）
	SQL Server開発者のためのOracle DB入門
	1．SQL Server開発者から見たOracle Databaseの特徴
	2．Oracle DatabaseとSQL Serverのコードの主な違い
	3．VB6×Oracleから.NET×Oracle 11g移行のポイント

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）