コンテンツにスキップ

EC-SPOKE データベース定義書

概要

EC-SPOKEプロジェクトのデータベース設計書です。EC-CUBEの優れた設計を参考にしつつ、柔軟性と拡張性を重視した設計となっています。

設計方針

EC-CUBEからの改善点

  • 商品バリエーションシステム: EC-CUBEの2軸制限を解消し、3軸以上の柔軟なバリエーションに対応
  • 階層カテゴリ: 無制限階層のカテゴリ構造
  • 商品画像: 複数画像対応（EC-CUBEは1枚のみ）
  • 商品タグ: タグ機能の追加

ディレクトリ構成

  • docs/
  • 01_商品系/ - 商品管理関連テーブル（カテゴリ含む）
  • 02_会員管理/ - 会員管理関連テーブル
  • マスター/ - システム共通マスターテーブル
  • DB定義概要.md - このファイル（全体のまとめ）

各システムのDB定義書

📦 商品系システム

ファイル: PRODUCT_README.md

商品管理に関連するテーブル定義： - 商品バリエーションシステム（3軸以上対応） - 商品マスター・画像・タグ管理 - カテゴリ階層構造

👥 会員管理系システム

ファイル: MEMBER_README.md

会員管理に関連するテーブル定義： - 会員情報管理 - 配送先管理 - ポイント履歴管理

テーブル:

🛒 注文系システム（将来実装）

ファイル: 03_注文系/ORDER_README.md（未作成）

注文・決済管理に関連するテーブル定義： - 注文管理 - 決済・配送管理 - カート機能

予定テーブル:

  • orders - 注文マスター
  • order_items - 注文明細
  • shippings - 配送情報
  • carts - カート
  • cart_items - カート明細
  • payments - 支払方法
  • deliveries - 配送業者

🎫 プロモーション系システム（将来実装）

ファイル: 04_プロモーション/PROMOTION_README.md（未作成）

プロモーション・マーケティングに関連するテーブル定義： - クーポン管理 - 商品レビュー

予定テーブル:

  • coupons - クーポン
  • coupon_products - クーポン対象商品
  • coupon_orders - クーポン利用履歴
  • product_reviews - 商品レビュー

注: ポイント管理は会員管理系システムで実装済み

📄 コンテンツ系システム（将来実装）

ファイル: 05_コンテンツ/CONTENT_README.md（未作成）

コンテンツ管理に関連するテーブル定義： - 固定ページ - お知らせ - ブロック管理

予定テーブル:

  • pages - 固定ページ
  • news - お知らせ
  • blocks - ブロック

⚙️ マスター系システム

ファイル: MASTER_README.md

システム全体で使用する共通マスターデータを管理： - 通貨マスター - 配送方法マスター - 支払方法マスター - 国・地域マスター

実装状況

システム 状況 進捗
📦 商品系 ✅ 完了 DB定義書作成済み
⚙️ マスター系 ✅ 完了 通貨マスター定義済み
👥 会員管理系 ✅ 完了 DB定義書作成済み
🛒 注文系 🔄 計画中 設計検討中（未作成）
🎫 プロモーション系 🔄 計画中 設計検討中（未作成）
📄 コンテンツ系 🔄 計画中 設計検討中（未作成）

実装優先順位

フェーズ1: コア機能（必須）

  1. 商品系システム ✅
  2. マスター系システム ✅
  3. 会員管理系システム ✅
  4. 注文系システム（会員管理系完了後）

フェーズ2: 付加機能（推奨）

  1. プロモーション系システム
  2. コンテンツ系システム

設計原則

1. 命名規則

  • 商品系: product_* プレフィックス
  • 会員管理系: customer_* プレフィックス（配送先等）、point_* プレフィックス（ポイント関連）
  • 注文系: order_* プレフィックス
  • N:N中間テーブル: {テーブル1}_{テーブル2}_rel 形式（_relサフィックス必須）

N:N中間テーブルの命名規則

  • 形式: {テーブル1}_{テーブル2}_rel（_relサフィックス必須）
  • 理由:
  • 中間テーブルであることを明示し、実テーブルとの区別を容易にする
  • データベース直接操作時やER図での可読性向上
  • EC特化システムでは中間テーブルが多数存在するため、識別の明確化を優先
  • 注意:
  • LaravelのbelongsToMany()では第2引数でテーブル名を明示的に指定する必要がある
  • 例: $this->belongsToMany(Category::class, 'category_product_rel')

2. 共通カラム

  • id: BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY
  • created_at, updated_at: TIMESTAMP
  • deleted_at: TIMESTAMP（Soft Delete用）

3. インデックス設計

  • 検索・ソート対象カラムに必ず設定
  • 複合インデックスでパフォーマンス最適化

テーブル定義記載ルール

外部キー制約の記載方法

記載項目: 名称、対象カラム、参照先、ON DELETE、ON UPDATE、説明

ルール:

  • 物理的外部キー制約のみを記載する（ON_DELETE、ON_UPDATEに「─」は存在しない）
  • デフォルトのRESTRICTでも必ず明記する

フォーマット:

名称 対象カラム 参照先 ON DELETE ON UPDATE 説明
fk_products_brand brand_id brands(id) SET NULL RESTRICT ブランド削除時はNULL

リレーションの記載方法

記載項目: 関連先、関連タイプ、外部キー、参照先、ON DELETE、ON UPDATE、説明

ルール:

  • 親→自身、自身→子の双方を記載する
  • 論理的関係性も含める
  • デフォルトのRESTRICTでも必ず明記する

関連先の記載ルール:

関連タイプ 記載対象
1:N 子
N:1 親
N:N 親（中間テーブル経由も親として記載）

外部キー・参照先の記載ルール:

関連タイプ 外部キー 参照先 ON DELETE ON UPDATE
1:N 子の列 自分の列 記載要 記載要
N:1 自分の列 親の列 記載要 記載要
N:N 自分の列 親の列 ─ ─

フォーマット:

関連先テーブル 関連タイプ 外部キー 参照先 ON DELETE ON UPDATE 説明
brands N:1 brand_id id SET NULL RESTRICT 商品は1つのブランドに属する
product_vars 1:N id product_id CASCADE RESTRICT 1つの商品は複数のバリエーションを持つ
category_product_rel 1:N product_id id CASCADE RESTRICT 商品削除時に中間テーブル側も削除
categories N:N category_id id（category_product_rel経由） ─ ─ 商品は複数のカテゴリに属する

N:Nリレーション表記の詳細ルール

N:Nリレーションを表現する際は、中間テーブル自体のリレーション（1:N）も明記する必要があります。

理由:

  • 物理的な外部キー制約情報（CASCADE/RESTRICT等）を保持するため
  • 中間テーブルの削除挙動を明確にするため
  • データベース設計の厳密性を向上させるため

表記順序:

  1. 自己参照（ある場合）: 親・子リレーション
  2. N:1（親テーブル）: 直接の外部キー参照
  3. 1:N（中間テーブル）: N:Nの物理実装部分
  4. N:N（最終目的地）: 論理的な多対多関係
  5. 1:N（子テーブル）: このテーブルを参照する子

ON DELETE/UPDATE カラムの記載ルール:

  • 1:N（中間テーブル）: 実際の外部キー制約値（CASCADE, RESTRICT等）を記載
  • N:N（論理関係）: ─ を記載（物理制約は中間テーブル行で表現済み）

更新履歴

  • 2024-01-XX: 初版作成（商品系のみ）
  • 2024-01-XX: DB定義概要.md構造化、階層化
  • 2024-01-XX: テーブル定義記載ルールを策定・追記