B2B網站的資料流流向圖(Data Flow Diagram)與實體關係圖(Entity Relationship Diagram)應該怎麼畫?

之前練習過了進貨單的DFD及ERD，也練習過了線上商店的UML，現在來看看B2B網站的Data Flow Diagram跟線上商店有何差異。

先問Bing Chat，來看看他會不會回答這個問題。

我問 : b2b 網站的 data flow diagram 會有哪些entity? 哪些 process? 哪些 data store?

Bing Chat回答 : 資料流程圖（Data Flow Diagram，縮寫為DFD）是描述系統中數據流程的一種圖形工具，它標誌了一個系統的邏輯輸入和邏輯輸出，以及把邏輯輸入轉換邏輯輸出所需的加工處理。數據流圖有四種基本圖形符號：箭頭表示數據流；圓或橢圓表示加工；雙槓或者單槓表示數據儲存；矩形框表示數據的源點或終點，即外部實體1。 然而，我無法找到有關B2B網站的具體DFD實例。您可以提供更多信息嗎？

如下圖 : 

顯然網路上沒有相關訊息，而Bing也不懂該怎麼做。

所以先把問題切開，問他是否知道 : b2b跟b2c網站，會有什麼不同的entity?

Bing Chat回答 : B2B（企業對企業）和B2C（企業對消費者）網站的不同之處在於它們的目標客戶群。 B2B網站旨在促進企業之間的交易，而B2C網站則旨在促進企業與消費者之間的交易1。 然而，我無法找到有關您問題中提到的具體實體（entity）信息。您可以提供更多信息嗎？

如下圖 : 

顯然Bing也不知道我在問什麼。

再換另外一個方式問 : 電商網站在繪製data flow diagram時，會有哪些entity? 哪些 process? 哪些 data store?

Bing Chat回答 : 資料流程圖（Data Flow Diagram，縮寫為DFD）是描述系統中數據流程的一種圖形工具，它標誌了一個系統的邏輯輸入和邏輯輸出，以及把邏輯輸入轉換邏輯輸出所需的加工處理。數據流圖有四種基本圖形符號：箭頭表示數據流；圓或橢圓表示加工；雙槓或者單槓表示數據儲存；矩形框表示數據的源點或終點，即外部實體。 然而，我無法找到有關電子商務網站DFD中具體實體（entity）、過程（process）和數據存儲（data store）的信息。您可以提供更多信息嗎？

如下圖 : 

很意外的，他可以回答進貨單的Data Flow Diagram，但是卻無法回答電商網站的Data Flow Diagram問題。

我再換一個方式詢問 : b2c網站要畫data flow diagram，會有什麼external entity? 會有什麼process?

Bing Chat回答 : 在B2C網站的資料流程圖中，外部實體（external entity）通常是消費者或客戶。過程（process）可能包括訂單處理、付款、庫存管理、發貨和退貨等。但是，具體的實體和過程取決於您要描述的系統或流程。

如下圖 : 

狀況有好一些了，但是還是無法套用在B2B網站上。

你有沒有辦法從B2C的Data Flow Diagram，推演出B2B的Data Flow Diagram呢?

B2B網站的DFD與ERD應該怎麼畫呢? 

以下是UML練習範例的線上商店DFD : 

以下是線上商店ERD : 

對於B2B來說，DFD與ERD會有什麼不同呢? 

B2C網站的External Entity有會員及非會員 (以蝦皮為例)，B2B網站的External Entity也會有會員及非會員 (以阿里巴巴為例)。

最大的差別在於B2C網站將商品加入購物車後可以[結帳]，但是B2B網站的主要程序是[詢價]。

我們先忽略阿里巴巴的B2C功能，只討論B2B的部分，其DFD應該如下 : 

上圖也不是一次就寫出來的，其實修改了好多次，例如原本Quotation Process沒有連接Member Data Store，但是如果要Quotation只允許會員才能操作，就必須要連接Member Data Store才能判斷是否會員，因此必須透過Login這個程序，才能進行詢價。

至於上圖是否已經完全無誤，其實還可以透過各不同Level的DFD再來修正更多細節，上圖應該只是Level 1的DFD而已。

B2B的DFD說明如下 : 

(1) 會員(Member)與非會員(Non-member)都可以瀏覽產品(Browsing)。

(2) 瀏覽產品的過程會寫入瀏覽歷史(Browsing History data store)。

(3) 瀏覽產品時需要從產品(Product)與供應商(Supplier)的data store中抓出資料。

(4) 只有會員登入(Login)後才可以詢價(Quotation)，因此必須先進行註冊(Registration)程序，註冊後資料會寫入Member data store。

(5) 會員可以去Member System編修會員資料。

(6) 會員進行詢價後會通知廠商，再由廠商透過詢價(Quotation)程序回報。所以會員與廠商只能透過系統溝通，不能私下報價，詢價與報價資料就會寫入Quotation data store。

(7) 廠商可以操作Supplier Administration程序，進行產品與供應商資料編修。

其中就有Supplier、Product、Browsing history、Member、Quotation等五個data store，這些data store的ERD繪製如下 : (只是簡要版，因為太多屬性會畫不下去)

並把Browsing history省略，把Quotation拆為Quotation與Quotation_item兩個data store (一張詢價單可以向一個廠商詢價多種產品)。在B2B網站中，如果沒有Quotation_item，就是一個產品一個詢價，其實也是可以的，完全看你的B2B網站想提供什麼樣子的功能。

以上的ERD轉換成資料庫的邏輯結構如下 (只是簡化的欄位):

member (member_id, member_name, member_email, member_password, member_date)

product (product_id, product_name, price_reference)

supplier (supplier_id, supplier_name, supplier_email, supplier_password)

quotation (quotation_id, supplier_id, member_id, quotation_date)

quotation_item (item_id, quotation_id, product_id, item_price, item_amount)

這個資料庫結構允許一家廠商(supplier)一張詢價單(quotation)，每張詢價單可以有多個產品。當然這個結構不一定跟每個B2B公司的需求會相同，你可以再思考以下的問題 : 

(1) 如果你希望B2B網站中，會員只能一張詢價單向一家廠商詢價一個產品，data store應該怎麼設計? 程序應該是如何? 

(2) 如果你希望B2B網站中，會員可以一張詢價單向一家廠商詢價多個產品，data store應該怎麼設計? 程序應該是如何? 

(3) 如果你希望B2B網站中，會員可以一張詢價單向多家廠商詢價多個產品，data store應該怎麼設計? 程序應該是如何? 

(4) 但是如果你再由B2B詢價的實際情況思考，通常產品的價格並不是一個price欄位可以完成的，因為可能是在某些訂購量下多少錢，可能是在某些時間內訂購會是多少錢，也可能是在某些付款條件下多少錢，如果考慮這些實際情況，以上的ERD會有什麼改變?