この記事でわかること
「EC-CUBEのデータベース構造はどうなっているのか」「顧客別価格を追加したいが、どこを触るべきか」「基幹連携をする場合、どのテーブルが中心になるのか」——EC-CUBEをカスタマイズする際、データ構造の理解は出発点になります。この記事では、EC-CUBE4系の主要なテーブル構造と、コアを直接変更せずにカスタマイズするためのEntity設計の考え方を解説します。
この記事を読むと分かること
- EC-CUBE4系のDBがDoctrine ORMでどう扱われるか
- 商品・顧客・受注などの主要テーブルの役割
- コアを直接変更しない、Entity拡張の考え方
EC-CUBE4系全体の構造については、EC-CUBE4系のアーキテクチャ解説もあわせてご覧ください。
前提：EC-CUBE4系はDoctrine ORMを採用している
EC-CUBE4系は、Doctrine ORMというライブラリを採用しています。ORM（Object-Relational Mapping）とは、データベースのテーブルを、プログラム上のオブジェクト（Entity）として扱う仕組みです。EC-CUBE4系では、EntityやRepositoryを通じてデータを扱う構成が基本です。要件によっては、QueryBuilderやDBALなどを利用する場合もあります。
この仕組みのため、EC-CUBE4系では、テーブルの構造を理解することが、そのままEntityの構造を理解することにつながります。そして、カスタマイズでデータ項目を追加する場合も、EC-CUBE本体のEntityクラスを直接編集するのではなく、拡張用の仕組みを使ってEntityに項目を追加する方法が用意されています（この点は後述します）。
EC-CUBE4系の主要なテーブル構造
EC-CUBEのデータベースは、大きく次のドメインに分かれます。テーブル名は、データを格納するものが「dtb_」、マスタデータが「mtb_」で始まる命名になっています。
- 商品関連
- 顧客関連
- 受注関連
- マスタ関連
- プラグイン・設定関連
商品関連テーブル
商品情報は、主に2つのテーブルに分かれています。この分かれ方が、EC-CUBEのデータ構造を理解するうえでのポイントの一つです。
| テーブル | 主に持つ情報 |
|---|---|
| dtb_product（商品） | 商品名、公開状態、説明文など、商品一覧に必要な情報 |
| dtb_product_class（商品規格） | 販売価格、在庫数、規格（サイズ・色など） |
販売価格や在庫は、商品（dtb_product）ではなく、商品規格（dtb_product_class）側で管理されています。BtoBの価格拡張や、数量別価格を設計する場合は、この構造を理解しておくことが役立ちます。
顧客関連テーブル
顧客情報は、dtb_customer（顧客）に、氏名・住所・メール・会員ステータスなどが格納されます。BtoBサイトでは、顧客ごとの属性（取引先コード、担当者など）の追加が必要になることがあります。
顧客別価格を実装する場合は、対応するプラグインを利用する方法や、顧客区分と価格の対応関係を管理する独自のテーブル・Entityを設計する方法などが考えられます。いずれの場合も、EC-CUBE本体のEntityクラスを直接編集するのではなく、プラグインやEntity拡張で対応する方法があります。
受注関連テーブル
| テーブル | 主に持つ情報 |
|---|---|
| dtb_order（受注） | 注文日時、顧客、合計金額、ステータスなど |
| dtb_order_item（受注明細） | 商品、数量、単価など、注文された商品ごとの情報 |
受注情報を基幹システムと連携する場合は、dtb_orderとdtb_order_itemが主な確認対象になります。BtoBサイトでは、承認ステータスや与信管理などの情報を、受注に関連づけて追加する設計が必要になることがあります。
マスタ関連テーブル
配送方法、支払方法、税率、都道府県などは、マスタテーブル（mtb_）で管理されています。業務ルールの変更が、これらのマスタ設定の範囲で対応できる場合もあります。
EC-CUBEのDB設計の特徴
ここからは、EC-CUBE標準のデータ設計に見られる特徴を整理します。
役割ごとにテーブルが分かれている
EC-CUBEでは、商品・商品規格・受注・受注明細など、役割に応じてデータが複数のEntity・テーブルに分かれています。前述の商品（dtb_product）と商品規格（dtb_product_class）の分かれ方も、その一例です。
受注時のスナップショット保存
受注データは、注文された時点の価格や税率などを保持します。そのため、後からマスタ（商品価格や税率など）を変更しても、過去の注文履歴の内容は変わりません。これは、受注データの正確性を保つうえで重要な仕組みです。
Entityによる拡張
EC-CUBE4系では、テーブルにデータ項目を追加したい場合、EC-CUBE本体のEntityクラスを直接編集するのではなく、拡張用のtrait（EntityExtension）を作成して項目を定義する方法が、公式に案内されています。この方法であれば、本体のコードを直接書き換えずに、Entityに項目を追加できます（追加した項目を永続化する際は、Doctrineのスキーマ更新などによって、対応するテーブルにカラムが追加されます）。
拡張時に確認したいこと
ここからは、DBまわりをカスタマイズする際に、確認しておきたい点です。
本体のEntityクラス・コードを直接編集しない
EC-CUBE本体のEntityクラスやコアのコードを直接編集すると、バージョンアップ時に、その変更と競合することがあります。前述のEntity拡張（trait）の仕組みを使うことで、本体のコードを直接編集せずに項目を追加できます。バージョンアップ時の影響については、バージョンアップで確認したい6つのポイントでも解説しています。
外部コード・識別子の対応関係を整理する
基幹システムと連携する場合、重要になるのは、基幹側の商品コード・得意先コードと、EC-CUBE側の識別子（商品ID・顧客IDなど）を、どう対応づけるかです。この対応関係を整理しておくことが、後の連携や拡張で役立ちます。コード体系がECと基幹で食い違っていると、連携時に確認・調整する範囲が広がることがあります。
インデックス設計
商品数や受注数が増えると、検索の速度に影響が出ることがあります。実際の検索条件やクエリの実行状況を確認し、必要に応じてインデックスを検討します。インデックスは、クエリの内容やデータ件数、絞り込みの条件によって効果が変わるため、実際の状況に応じて設計することが大切です。
BtoB拡張時の設計ポイント
BtoBサイトでは、次のようなデータの追加が必要になることがあります。
- 顧客別価格・契約価格を管理する仕組み
- 契約価格の履歴
- 承認フローの管理
- 与信の管理
これらは、既存の受注ロジックとどう関係するかを整理したうえで、設計することが大切です。ここを整理せずに拡張すると、後のバージョンアップやAPI連携のときに、確認・調整する範囲が広がることがあります。BtoB固有の設計論点は、EC-CUBEでBtoBサイトを構築する際の注意点9選でも整理しています。
API・基幹連携との関係
DB設計は、API連携や基幹連携とも関係します。マスタの一意性（同じものが重複していないか）、データ型の統一、論理削除の扱いなどが整理されていないと、連携の設計時に確認・調整する項目が増えることがあります。基幹連携を予定している場合は、早い段階でデータ構造を確認しておくことをおすすめします。連携の設計については、基幹・在庫システムを連携する方法で解説しています。
EC-CUBEのデータ設計から、ご相談ください。
「顧客別価格を追加したい」「基幹連携に向けてデータ構造を確認したい」「他社が作ったサイトの構造を把握したい」といったご相談に対応しています。現在の構成を確認したうえで、拡張の方針をご提案します。
よくある質問
EC-CUBEのテーブルに、独自のカラムを追加できますか？
できます。EC-CUBE4系では、EC-CUBE本体のEntityクラスを直接編集するのではなく、拡張用のtrait（EntityExtension）を使って、Entityに項目を追加する方法が公式に用意されています。この方法であれば、本体のコードを書き換えずに項目を追加できます。なお、追加した項目を永続化する際は、Doctrineのスキーマ更新などによって、対応するテーブルにカラムが追加されます。
顧客別価格を実装したいのですが、どこを触ればよいですか？
価格は、商品（dtb_product）ではなく、商品規格（dtb_product_class）側で管理されています。顧客別価格を実装する場合は、対応するプラグインを利用する方法や、顧客区分と価格の対応関係を管理する独自のテーブル・Entityを設計する方法などが考えられます。いずれの場合も、EC-CUBE本体のEntityクラスを直接編集せず、プラグインやEntity拡張で対応する設計をおすすめします。要件によって適した設計が変わるため、まず何を実現したいかを整理することが大切です。
基幹連携では、どのテーブルが中心になりますか？
受注情報を連携する場合は、dtb_order（受注）とdtb_order_item（受注明細）が主な確認対象になります。ただし、出荷・配送、商品、顧客など、連携する業務によって、対象となるEntity・テーブルは変わります。まず何を連携するかを整理したうえで、対象を確認することが大切です。連携では、これらのデータのID・コード体系が、ECと基幹で対応づけられるかも論点になります。
過去の注文の価格は、商品価格を変更すると変わってしまいますか？
変わりません。EC-CUBEの受注データは、注文された時点の価格や税率などを保持する設計になっています（スナップショット保存）。そのため、後から商品のマスタ価格を変更しても、過去の注文履歴の金額は変わりません。
まとめ
EC-CUBE4系のデータベースは、商品系・顧客系・受注系・マスタ系を中心に、Doctrine ORMで管理されています。カスタマイズの際に大切なのは、EC-CUBE本体のEntityクラスを直接編集せず、Entity拡張（trait）の仕組みを使うこと、そして、外部コードとの対応関係や、将来の連携・拡張を見据えてデータ構造を整理しておくことです。
データ構造は、EC-CUBEのカスタマイズや、基幹連携を考えるうえでの土台になる部分です。私たちサンクユーは、EC-CUBEのデータ設計や、BtoB向けの拡張、基幹連携に対応しています。他社が構築したサイトの構造把握や、拡張の相談にも対応していますので、お気軽にご相談ください。
投稿者プロフィール
- サンクユーのEC-CUBE担当。15年以上にわたりEC-CUBE開発に従事し、2系・3系・4系すべてに精通。難易度の高いカスタマイズや、他社構築サイトの改修・再設計も多数対応しています。
Javaでの業務システム開発を起点に、PHP・Perl・フロントエンド・CMSまで横断的に対応。基幹システム連携や業務フローを踏まえた設計を得意とし、複雑な要件にも柔軟に対応可能です。
ChatGPT CODEXを活用し、開発スピードと品質の両立を実現しています。
