前回は「Clayデータベースモデリング」Eclipseプラグインを用いて「リバースエンジニアリング」を行い、osCommerceのデータベースからE-R図を生成してみた。今回は引き続き、具体的にosCommerceで注文データがどう保存されるかを見ていこう。

図にしてみるとよくわかるが、osCommerceのような高機能なアプリケーションでも、データベースのテーブル構造は意外とシンプルなものである。リレーショナルデータベースでは、設計段階でデータの無駄な冗長性を極力排除するよう「正規化」が行われるため、正しく設計されたデータベースは誰が作ってもほぼ同様な構成になる。つまり、良いシステムのデータベースは、シンプルで理解しやすいものになるはずなのである。そして、osCommerceのデータベースも、非常にシンプルかつ美しく設計されている。

E-R図をざっと眺めてわかるのは、「customers」「orders」「products」ではじまる名前のついたテーブルが多いことだ。これらがそれぞれ「顧客」「注文」「商品」の情報に関係するデータを扱うテーブル群であることは、名前からすぐ推測できるだろう。今シリーズのテーマである「推売システム」では、過去の販売実績から一定の傾向を導く処理を行う必要があるので、特に「注文」データが重要になる。まずは注文のデータがどう処理されるかを確認するために、osCommerceから、何か商品を注文してみよう。後の説明の都合上、できれば複数の商品を発注しておくとよい。

注文が完了したら、"orders"ではじまる名前の各テーブルを順番に見ていこう。まず「orders」テーブルには、以下のように配送先や請求先のデータが登録されているはずだ。

実際の購入商品の情報はordersテーブルではなく、「orders_products」テーブルに格納されている。

ひとつの注文で複数の商品を購入できることから、注文と購入商品は「1:n」の関係になる。よって、正規化されたテーブルはこのように分割され、互いに「orders_id(注文ID)」列で関係付けられているわけだ。

他にも、注文毎の合計金額を保持する"orders_total"、受けた注文の処理履歴を保持する"orders_status_history"といったテーブルがあるが、これらはさほど重要なデータではない。実際のデータを見てみると、あくまでもordersとorders_productsが、注文に対する中心的な役割を担っていることがわかるだろう。

あとは、ordersテーブルと「customers_id」で関係付けられている「customers(顧客)」テーブル、orders_productsテーブルと「products_id」で関係づけられている「products(商品)」テーブルあたりが、osCommerceの「販売」の処理の中で中心となる。実際の販売傾向は、これらのテーブルのデータを元に分析すればよい、ということになるだろう。次回からはいよいよ、このデータをMUSASHIに引き渡して分析していく手順を考えてみたい。