前篇回顧

在租車信息系統數據庫設計（1）與租車信息系統數據庫設計（2）中我們列出了租車信息系統的12條需求，并相應做了數據庫設計，最后得到的表關系圖如下：

在租車信息系統數據庫設計（2）的最后提出了3個新問題：

1. 出入庫管理還能豐富，車輛買入，車輛報廢，送修，還有不同門店之間的車輛拆借（如門店A向門店B臨時借用某輛車），如何更好的記錄這些StoreTransaction信息？

2. 顧客對于租車費用的支付信息如何記錄，顧客可以通過預先充值后消費的方式來支付（這也是區分會員級別的關鍵），又該如何支持？

3. 我們在第一篇中暫時沒考慮“送車上門和上門取車”服務，要支持這一功能，我們對數據庫結構要做些什么改動？

就這3個問題，今天我給出自己的解決方案與大家進行討論。

更細致的出入庫管理

對于問題1，可以通過細分StoreTransaction來解決。

• 在Table_StoreTransaction表中增加StoreTransaction_Type列來存放進出庫類型，我把進出庫類型分為3種（Purchase，Adjustment，Rental）。相應還需要加入兩張表Table_Purchase（記錄買入車輛的信息），Table_Adjustment（記錄車輛拆借、送修、報廢信息）。
• Table_StoreTransaction表中的StoreTransaction_ReferenceID列根據不同的進出庫類型指向不同表中的記錄。

下表羅列了各種情況的進出庫類型和Reference ID指向的表：

?	進出庫類型	Reference ID指向的表記錄
車輛出租	Rental(In/Out)	Table_Order
車輛買入	Purchase(In)	Table_Purchase
車輛拆借	Adjustment(In/Out)	Table_Adjustment
車輛送修	Adjustment(In/Out)	Table_Adjustment
車輛報廢	Adjustment(Out)	Table_Adjustment

我們來看一下需要新建的表的字段。實際上，除了要新建Table_Purchase，Table_Adjustment之外，還會間接引入Table_AdjustmentType表。

• Table_Purchase:

列名	解釋
Purchase_ID	Identity字段
Store_ID	入庫門店ID
Car_VIN	車輛唯一編號
CarCategory_ID	車輛型號ID
Purchase_Date	購買日期
Purchase_Price	購買價格
Purchase_Currency	貨幣
Purchase_CreatedBy	購車申請人
Purchase_AuthorisedBy	購車批準人
Purchase_Comment	購車備注

注意：

1. Table_Purchase表中沒有Car_ID字段是因為在車輛買入之前，Table_Car中還沒有對應記錄。

2. 為了簡化，我們的設計中Table_Purchase只記錄成功購買車輛的信息。如果想對車輛購買進行像Order一樣的流程控制，就需要增加些新的字段和表，如購車狀態信息（記錄Purchase的狀態，如新建，審批通過，取消或完成等），大家自己根據需要添加。

• Table_Adjustment:

列名	解釋
Adjustment_ID	Identity字段
AdjustmentType_ID	調庫類型ID，指向Table_AdjustmentType記錄
Store_ID	入庫/出庫門店ID
Car_ID	車輛ID
Adjustment_Date	調庫日期
Adjustment_ExpectDate	預期歸還時間
Adjustment_CreatedBy	調庫申請人
Adjustment_AuthorisedBy	調庫批準人
Adjustment_Comment	調庫備注

注意：

1. Adjustment_ExpectDate表示預期歸還時間，此字段只有在Adjustment Type對應為Borrow In, Lend Out, Send to Repair中有意義。當為其他Adjustment Type時，此字段置為NULL。

2. 在此設計中，當某車輛從一個門店Adjust Out后，Table_Car中對應的車輛記錄的車輛狀態變為Inactive。當某車輛被Adjust In到一個門店后，Table_Car中會相應插入一條車輛記錄(也有可能只需做Update)，且該車輛狀態為Ready。

3. 對于公司各門店之間的拆借，上述方式之外，大家也可以考慮把個門店也看作內部客戶，一個門店可以向另一個門店創建Order，走Order流程。但借入車輛的門店需要有一種機制來把車輛收入門店，大家可以思考，并比較兩種方式的優劣。

• Table_AdjustmentType:

列名	解釋
AdjustmentType_ID	Identity字段
AdjustmentType_Name	調庫類型，包括：借入Borrow In，借出Lend Out，歸還Return In，返還Return Out，送修Send to Repair，修完入庫Return after Repair，報廢Scrap
AdjustmentType_InOutFlag	進出庫標簽

注意：

本設計中Adjustment Type分得較細，通過Adjustment Type就能區分是入庫還是出庫。

另一種設計是用較少的Adjustment Type來區分調庫的種類(如只有Borrow，Return，Repair，Scrap四種)，通過InOutFlag來區分進/出庫。若要這么做就需要把InOutFlag字段放到Table_Adjustment中。至于兩種方式的有缺點，大家可以思考。

新的表關系圖

由于加入新的表之后，表關系鏈接出現了交錯。所以我使用了數據庫的‘自動整理表’功能把關系圖重新排列了一下，得到下圖：

• 其中用紅色框圈出的表是這次新加入的表。
• 其中用黃色圈出的幾個字段是我們需要注意的：

1. 在先前的Table_Car中(本文開始的關系圖)，有字段Car_PurchasePrice, Car_Currency。我們引入了Table_Purchase表之后，這兩個字段的信息有冗余，可以省去。我把其中的Car_PurchasePrice改為了Car_CurrentPrice，用于記錄每年折損后的車輛價值。

2. 在租車信息系統數據庫設計（2）中，Table_StoreTransaction表中的StoreTransaction_ReferenceID字段對于車輛買入，車輛拆借、車輛報廢和送修造成的出入庫沒有對應的信息。現在對于上述情況，此字段將引用Table_Purchase或Table_Adjustment的ID列。

下篇預告

沒想到第一個問題就寫了這么多，剩下的問題來不及寫了，只能留到下一篇中討論。

2. 顧客對于租車費用的支付信息如何記錄，顧客可以通過預先充值后消費的方式來支付（這也是區分會員級別的關鍵），該如何支持？

3. 我們在第一篇中暫時沒考慮“送車上門和上門取車”服務，要支持這一功能，我們對數據庫結構要做些什么改動？

轉載于:https://www.cnblogs.com/DBFocus/archive/2010/11/25/1888209.html

總結

以上是生活随笔為你收集整理的租车信息系统数据库设计（3）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。