3

売り手、買い手、本という 3 つのエンティティ (クラス) を持つ書店を構築します。データベースを次のように設計しました。
- 買い手と売り手の両方が、それぞれ 1 冊以上の本を売買できます。
- 購入者が本を販売したい場合、販売者アカウントが必要です。
- 買い手は自分の価格を提示し、売り手は最高の買い手に売りたいので、これらのすべての情報を保存する必要があります。 

このモデルでは、プロセスクラスは他の 3 つのクラス コネクタになります。
    売り手の本の買い手
   ------- ------ -------
     sID* bID* byID*
     名前 --> sID     


これは私の最初の考えでしたが、バイヤーが同時に複数の本を購入できるため、このスキーマがプロセスで失敗することがわかりました。また、他の理由もありました。だから私はそれを変更しました：



このモデルでは、プロセスクラスは他の 3 つのクラス コネクタになります。
     ______ ______ ________ ________
    |売り手| | | 本 | |プロセス | | | バイヤー |
    -------- -------- ---------- ---------
    | | SID* | | | bID* | | | pID* | | | byID* |
    | | 名前 | | | XXX | --> | SID | |日付 &..|
                              ----------
(*) は主キーを示します  




これはうまくいくと思いますが、価格オファーで作業するにはどうすればよいですか? 

はい、プロセスクラスにオファーを追加できるので、気が変わってこのモデルが登場しました: (長い説明で申し訳ありません)



*Offer* フィールドが *process* クラスに追加されます。
     ______ ______ __________ ________  
    |売り手| | | 本 | |プロセス | | | バイヤー |
    -------- -------- ----------- ----------  
    | | SID* | | | bID* | | | pID* | | | byID* |   
    | | 名前 | | | XXX | --> | SID | | | オファー |
                              | | 日付 &..|
                              -----------       
(*) は主キーを示します

初めてなので、データベースの設計に完全に混乱しています。これでシステムのニーズを満たすことができますか? いいえの場合、どのように機能させることができますか? はいの場合、より良いデザインはありますか？

どんな提案でも大歓迎です、事前に感謝します:)

更新- ここで最良の回答を選択することはできません。すべて役に立ちました。たくさんの人に感謝します。よろしくお願いします^o^

4

6 に答える 6

1

次のようなドメイン モデルが必要だと思います。

Buyer(BuyerId, ... buyer details ... )
Seller(SellerId, ... seller details ... )
Book(BookId, ... book details ... )
Bid(BidId, BuyerId, BookId, Price, Expiry)
Offer(OfferId, SellerId, BookId, Price, Expiry

どのように機能するかは、ユーザー (買い手または売り手) が必要に応じてビッドまたはオファーを作成できることです。したがって、バイヤーの場合は、利用可能なオファーを検索することから始めることができます。気に入ったものがあれば、それを受け入れてチェックアウトに進むことができます。おそらく、どのオファーも気に入らないかもしれませんが、希望する価格に近いオファーが 1 つあります。入札を作成し、それをオファーの作成者に送信して検討してもらうことができます。

または、バイヤーとしての要件に近いものがない場合は、入札を作成してシステムに残して、潜在的な売り手が選択した有効期限まで閲覧/検索して検討できるようにすることができます。

Bid クラスと Offer クラスを追加しましたが、その利点は自明だと思います。しかし、さらに詳しい説明が必要な場合は、お気軽にコメントを残してください。返信します。有効期限フィールドは必須ではありませんが、ほとんどの場合、すべてのビッドとオファーに時間制限があり、その場合に必要になります。

クラス/テーブルの数を増やしましたが、システムの管理と拡張がはるかに簡単になっていることがわかると思います。

于 2009-04-11T14:59:54.720 に答える
1

買い手が売り手になることができる場合 (およびその逆)、アカウントの種類のフラグのセットを含む単一の顧客テーブルを持たないのはなぜですか?

書籍が一意である場合 (つまり、Moby Dick の 1 つのコピーが別のコピーとは別に表示されます... Amazon よりも eBay に似ています)、 book テーブルに買い手と売り手の外部キーを含めることができます。あなたの店の最もシンプルなデザインは、今では 2 つのテーブルしかありません。例えば：

Cust table
cust_id
name
is_buyer
is_seller

Book table
book_id
description
seller_cust_id
buyer_cust_id

編集: 1 人の買い手/売り手が 2 つのアカウントを持っていなければならない場合でも、この解決策は変わらないと思います。顧客が買い手と売り手の両方になることはできないという制限をアプリに追加するだけです。1 つのテーブルの良いところは、セキュリティ/ログインなどを複製する必要がないことです。ロジック...

編集 2 : また、買い手が複数の本を購入できる場合、買い手が購入した各本を格納するショッピング カート テーブルを用意する方が理にかなっているでしょうか?

于 2009-04-11T14:40:43.877 に答える
0

データモデル、オブジェクトモデル、機能および非機能の仕様と要件、それぞれの一部について説明しているので、少し混乱しているように見えます。記法とデザイン要素をきれいに、明確に、そして分離してください。

于 2009-05-23T00:53:16.673 に答える
0

私の理解が正しければ、買い手は売り手が何かをする前にオファーを出します。その後、売り手は保留中のオファーの 1 つを受け入れることができます。購入者 ID をプロセスに追加し (実際、購入者がオファーを出すとプロセスが作成されます)、書籍 ID と提示価格も追加します。その後、売り手が取引を成立させると、プロセスは sID フィールドを使用して売り手にリンクできます。このようにして、バイヤーは異なる本で同時に複数のオファーを保持できます。

于 2009-04-11T14:54:23.267 に答える
0

LuckyLindy のコメントをさらに一歩進めて、単一の Customer テーブルを使用し、Order というテーブル (おそらく Process テーブルに似ている) と OrderItem というテーブルを作成します。購入者と販売者はすべて顧客です...注文が厳密に 2 人の間で行われる場合、注文テーブルには購入者と販売者のフィールドを含めることができます。Order の各アイテムについて、OrderItem にタプルがあります (グループをバインドするための ID が Order に返されます)。

Customer    Order         OrderItem
--------    -----------   ---------
id          id (pk)       id
name        date          order_id (fk)
            buyer (fk)    book
            seller (fk)   price
            total

これは実際には初歩的な例ですが、一般的なショッピング カートのデザインを使用するだけで要件が満たされるようになりつつあります。グーグルで見つけることができる多くの例があります。

于 2009-04-11T14:55:05.120 に答える