ECサイトとER図の関係〜担当者は必須じゃないけど、便利な知識

ER図とはデータベース設計を考える時に基本となる設計図の記述法です。

ECサイトはデータベースを活用して構築されています。表面に見える情報だけでなく、顧客情報、商品情報、決済情報、在庫管理情報など様々なデータを効果的に組み合わせて機能するようにできています。設計時にはエンジニアがこうしたER図を用いてサイトの構築を行っているかもしれません。

ここではER図についてECサイトの構築や運営の視点で解説します。

ECサイトはデータベースでできている

まずはECサイトの構造を考えてみましょう。表面に見えるトップページや商品ページがあります。そして決済後には顧客情報に基づいて発送の作業をします。

商品には仕入れ先や在庫数などそれぞれに属性情報があります。顧客に対しては連絡先や支払い住所、発送先などの情報があります。他にも決済方法、配送方法などがあります。これらが関係して連動し、ECサイトとして機能します。つまりどの機能もそれぞれの情報を持つデータベースを連結して機能しているわけです。

そのため、ECサイトを作るという場合はデータベースを関連付けて構築していく必要が根本的な部分としてあります。

最近では無料ASPなども普及しています。そのため個人で始める小規模のECサイトで一から作ることはあまりないでしょう。そのため、実際にこうしたように考えてECサイトの構築に取り組ことはエンジニア以外ではあまりないかもしれません。

エンジニアにはおなじみの設計図記法がER図

データベースを構築するエンジニアであれば、データベースを整理してそれぞれのつながりを考えるということが日常的な作業といえます。また、実際に作業を進めるにしても、何のきっかけも設計図もなくサイトを作ることはできません。

そこでそうしたWEBに関わるエンジニアの間で利用されている設計図の書き方がER図です。ER図はそれぞれのデータベースを分類して整理し、それぞれの関連性をどのように紐付けして機能するかを示すための図面です。データベースを運用できるようにするためにいきなり作業するのではなく、こうしてER図で設計図を書いて行います。

基本的には建築の設計図などと同じで、最初はざっくりと書き、どんどんブラッシュアップして最終的な設計図とします。

「ER図」なんて言い方をすると、いろいろ身構えてしまうかもしれません。実際には、概要を掴めさえすれば、プログラム言語を学ぶことなどと比較すると、よりずっと簡単に概要を理解し習得できます。

また、あくまでER図は設計図です。それだけで業務が完了するわけではないので、シンプルに理解していくことが重要です。

ER図の基本

データのまとまりを示す「エンティティ」を□で表現し、「リレーション」という線で表記して2つのエンティティ同士を繫ぐのが基本です。そしてリレーションに「カーディナリティ」という関係性を示す記号を加えてそれぞれのエンティティの間にある関係性を示します。

ちょうど箱同士を線で繋ぎ、線の種類と表記でその繋がりの意味を示すイメージです。

カーディナリティはそれぞれのエンティティとの関係がどうなりたつのかを示します。表示されるときに「なし」と表示されるようなことが成立する場合は、これに対して０という言い方でカーディナリティ上に表現します。１以上の多ということもあります。そうしたことを記号化して表現します。

エンティティ自体はそれぞれ「アトリビュート（属性）」からできています。アトリビュートは「主キー」と「外部キー」とに分かれます。

多くの場合、主キーはエンティティの中では上部に記載して囲みをいれて表現します。またエンティティそれぞれが主従関係にある場合は従属するエンティティの角を丸くするなどでわかるように表現します。

詳しく書き方などがわからなくても、見るとどういったことを表しているのかなんとなくはわかるかもしれません。

複数の記法がある

ER図の記述方法は一種類ではなく、１0種類程度の記法があります。そのうち主に普及しているのは2種類です。実際のところ、どの記法が優れているというものではありません。

その2種類は「IE記法」と「IDEF1X記法」です。基本的な仕組みは一緒ですが、カーディナリティの表記の仕方に違いがあります。いろんな現場を体験している熟練のエンジニアであれば、複数の記法に精通していることも少なくありません。

実際に企業側のEC担当者レベルであれば、データベース設計に携わる頻度は決して高くありません。そのため、ER図の記法は1種類も知らないということもあります。

担当者であっても必須な知識ではない

データベース業務に関わるエンジニアにとっては必須のER図ですが、おそらくもうおわかりのようにEC運営担当者にとって必須の知識ではありません。

ER図について知らなくても運営には一切支障がないといえます。複数のサイトを常時構築している、専門的にそうした仕事についているのであれば、日頃から触れるので、覚えていけば、実用的ですし、そうした知識もやはり求められます。

しかし、EC運営にかかわる担当者は構築時やリニューアル時にしか触れ合いません。そうしたことに対してリソースを割いて覚えたとしても、日頃使わないので忘れてしまうことのほうが多いかもしれません。

実際のところ一生懸命細かく厳密に覚えるメリットはほぼないと言ってもいいでしょう。

情報の整理には便利—考え方は参考にしてもいい

それでも、ER図をもし理解出来るのであればとても便利です。利用する目的としては構築後にどういった構造になっているのかを把握することができます。考えを整理したりする場合にも役に立つことは少なくないでしょう。

どういった情報同士が紐づいているのかがわかれば、問題点の洗い出しもしやすく、WEB制作会社などに依頼して改修するような場面でも、その関連性がわかりやすくなります。

外部に制作依頼を出した場合には、ER図がもし手元になければ、あるかどうか確認し、あれば貰っておくと、もしもの時に便利に使える可能性もあります。

また、ER図に記載する時の考え方なども参考になることは少なくありません。ER図を書くためには、まずシステムシナリオを考えて進めます。そこでは、システムがどのように機能するかを表現する「ユースケース図」をまずは考えます。例えばユーザーの行動を捉えて図示したり、そこからユースケース記述を搔き出したりしていきます。その上で実行のパターンを図式化したアクティヴィティ図を作成してER図に落とし込んでいきます。

こうして、それぞれのデータベースに対し、エンティティやアトリヴュートを定義づけ、それぞれの関係に落とし込んで開発をすすめていきます。

実はECサイトの担当者としては、こうした考え方を商品のカテゴリ分けなどでも使えます。カテゴリ分けが重要なECサイトの業務でも有効といえるでしょう。

ER図までとはいかなくとも、こうしてシステムシナリオを考えていくことで作業は明確化されていきます。ロジカルに考えることで、見えてくるものや、行動の指針が明確になることもあります。

そう考えると、記載方法を学ぶというよりも、考え方を知ることは有効です。

もちろん、こうした考え方自体は業務に生かすことができます。また、ER図自体も役に立ちます。運営に必ず必要というものではありませんが、知っていれば便利なものです。

実際にER図を書くためのアプリケーションもありますが、多くの場合、EC運営の担当者にそこまでは必要ないでしょう。