LoginSignup
1
0

【個人開発】WEBオーダーアプリのデータベース設計をやってみる

Posted at

モバイルオーダーのアプリのデータベース設計を考える際、最も基本的な機能として「商品の管理」、「ユーザーの管理」、「注文の管理」が考えられます。以下はそれを基にしたシンプルなデータベース設計です。

  1. 商品テーブル (products)

    • product_id: 主キー。ユニークな商品ID。
    • product_name: 商品名。
    • price: 商品の価格。
  2. ユーザーテーブル (users)

    • user_id: 主キー。ユニークなユーザーID。
    • username: ユーザー名。
    • password: パスワード (ハッシュ化されていることが望ましい)。
    • email: ユーザーのメールアドレス。
  3. 注文テーブル (orders)

    • order_id: 主キー。ユニークな注文ID。
    • user_id: 外部キー。どのユーザーが注文したかを示す。
    • total_amount: 注文の合計金額。
    • order_date: 注文日。
  4. 注文詳細テーブル (order_details)

    • detail_id: 主キー。ユニークな注文詳細ID。
    • order_id: 外部キー。どの注文に関連するかを示す。
    • product_id: 外部キー。どの商品を注文したかを示す。
    • quantity: 注文した商品の数。
    • sub_total: 商品の小計 (price x quantity)。

こうすることで、ユーザーは商品を選び、それに対して数量を指定して注文を行うことができます。注文が完了すると、orders テーブルに注文の概要が、order_details テーブルには注文の詳細情報が格納されます。

実際の運用においては、セキュリティ対策や拡張性を考慮した設計変更が必要となることもありますので、上記はあくまで基本的な例としての提案です。

完成したER図

ダウンロード.png

ER図のコード

from eralchemy import render_er
from IPython.display import Image

# ER図の定義
er_code = """
[products]
product_id
product_name
price

[users]
user_id
username
password
email

[orders]
order_id
user_id
total_amount
order_date

[order_details]
detail_id
order_id
product_id
quantity
sub_total

users 1--* orders
users 1--* order_details
products 1--* order_details
orders 1--* order_details
"""

# ER図の定義を一時ファイルに書き出し
with open('er_definition.er', 'w') as f:
    f.write(er_code)

# ER図をファイルに出力
output_file = "er_diagram.png"
render_er('er_definition.er', output_file)

# 画像の表示
Image(filename=output_file)

要件定義で考慮したこと

上記のデータベース設計の要件定義で考慮したことは以下の通りです:

  1. 基本的な機能の確立:

    • ユーザーの商品選択、数量指定、注文といった最も基本的なオーダーの流れをカバーできる設計としています。
  2. データの独立性:

    • 商品、ユーザー、注文、注文詳細の情報はそれぞれ独立したテーブルに格納することで、データの管理と更新が効率的に行えるようにしています。
  3. データの関連性の明確化:

    • 各テーブル間の関連性を外部キーを使用して明確に表現しました。これにより、例えばどのユーザーがどの商品を何個注文したかといった情報を正確に追跡できます。
  4. ユーザーセキュリティ:

    • ユーザーのパスワードはハッシュ化することが望ましいと指摘しており、これによりユーザーデータのセキュリティを高めることを意識しています。
  5. 注文の詳細性:

    • order_detailsテーブルを導入することで、1つの注文に対して複数の商品を関連付けることができます。これにより、注文の詳細な情報を正確に捉えることができます。
  6. データの正確性と完全性:

    • 小計をsub_totalとしてorder_detailsテーブルに持たせることで、注文ごとの商品の価格と数量を乗算した正確な価格情報を持つことができます。
  7. 将来的な拡張性:

    • 上記の設計は基本的なものとしていますが、商品のカテゴリ、プロモーション、ユーザーの住所情報や注文のステータスなど、追加の情報や機能が必要になった場合にも容易にテーブルやカラムを追加できる構造にしています。

要件定義の段階での考慮点は、アプリケーションの主要な機能とデータの関連性、セキュリティ、拡張性など、データベース設計の基盤となる部分をしっかりと構築することでした。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0