租車資訊系統資料庫設計（4）
2010-12-12 20:22
知行思新
閱讀(4840)
評論(5)
編輯
收藏
舉報
前篇回顧
在租車資訊系統資料庫設計（3）中我們實作了更為細緻的車輛出入庫管理。
本篇将試圖解決剩下的2個問題：
1. 顧客對于租車費用的支付資訊如何記錄，顧客可以通過預先充值後消費的方式來支付（這也是區分會員級别的關鍵），該如何支援？
2. 我們在第一篇中暫時沒考慮“送車上門和上門取車”服務，要支援這一功能，我們對資料庫結構要做些什麼改動？
1. 支付管理
對于租車費用的支付，我想到了如下幾個關鍵點：
1. 顧客可以預先向會員卡充值，之後進行消費。
2. 對于一個訂單的費用，支付來源可以有多個。例如：訂單總費用2500元，顧客選擇先用完會員卡中的1000元，再刷卡1500元進行支付。
3. 對于顧客的一次支付，可以對應多個Order。例如：顧客租用了2輛車，在我們的系統中會對應2個Order，顧客可以1次刷卡支付這2個Order的全部費用。
對于關鍵點1，我們要在系統中為每個顧客建立賬戶（Account），顧客向會員卡充值或使用會員卡消費都對于一筆流水（Transaction）。
對于關鍵點2、3，說明了訂單與顧客支付之間是一種多對多關系。
我的解決方案如下：
1. 在原先的Table_Customer表中增加Customer_AccountBalance，Customer_AccountCurrency字段，存放顧客賬戶結餘。需要注意的是這個字段的資訊是可以通過累加該顧客所有的賬戶流水得到，有些備援但能提高擷取賬戶餘額的性能。Customer_AccountBalance和賬戶流水之間是總賬和明細賬的關系，需要計劃一些時間點進行結算（即總賬與明細賬軋平）。
2. 增加Table_AccountTransaction表，即賬戶流水表，顧客每次充值與支付都會在該表中增加一條記錄。在本設計中，我把顧客支付某Order時的現場刷卡或付現金行為也作為該顧客對自己賬戶的先充值，之後再從顧客賬戶扣款支付Order。這種設計方式能減少表的數量、好了解，但所用的顧客刷卡或付現都進入到了總賬，之後再與Order關聯，無法很明确的得到顧客的某次刷卡是為了支付哪個特定的Order（你隻能通過時間和金額來推測）。大家對此可以進行思考，給出解決方案，并比較優劣。
Table_AccountTransaction字段
列名 解釋 AccountTransaction_ID Identity字段 Customer_ID 顧客ID，外鍵 AccountTransactionType_ID 流水類型ID，外鍵 AccountTransaction_Date 流水産生日期 AccountTransaction_Amount 流水金額（正值為充值，負值為支付） AccountTransaction_ReferenceID 參考号碼
1. 充值流水
信用卡：卡号
支票：支票号
現金：為空，
2. 支付流水
為空
3. 對于Table_AccountTransaction中的AccountTransactionType_ID字段對應新增表Table_AccountTransactionType中的記錄。
Table_AccountTransactionType字段
列名 解釋 AccountTransactionType_ID Identity字段 AccountTransactionType_InOutFlag 0為支付，1為充值 AccountTransactionType_Name 賬戶流水類型名：
1. Cash：現金充值，對應AccountTransactionType_InOutFlag：1
2. Credit Card：信用卡充值，對應AccountTransactionType_InOutFlag：1
3. Check：支票充值，對應AccountTransactionType_InOutFlag：1
4. Pay Order：支付訂單，對應AccountTransactionType_InOutFlag：0
AccountTransactionType_Description 賬戶流水類型描述 4. 增加Table_PaymentApplication表，這張表建立了Order與AccountTransaction之間的多對多關系。
Table_PaymentApplication字段
列名 解釋 PaymentApplication_ID Identity字段 Order_ID 訂單ID，外鍵 AccountTransaction_ID 賬戶流水ID，外鍵 PaymentApplication_Amount 支付金額 PaymentApplication_Date 支付日期
加入支付管理功能後的表關系圖
其中用紅色标出了新增加的表，用黃色标出了新增加的列。
注意：
1. 一般在一個表中有金額字段時，我都會加一個對應的Currency字段來表示貨币類型。在這次新增的Table_AccountTransaction和Table_PaymentApplication中雖有金額字段，但沒有對應的Currency字段，這是因為我預設這些記錄的Currency與Table_Customer表中新增的Customer_AccountCurrency一緻。大家可以根據需要加上Currency字段。
2. 這個支付管理的設計我總感覺不是最好，就如上文解決方案中所說的。我試圖給出了另一種設計（增加Table_Payment表，用以記錄使用者的支付來源，如信用卡資訊等。簡化Table_AccountTransaction表，隻保留金額與時間，對于充值記錄對應Table_Payment的ID。對于Table_PaymentApplication，可能有兩種來源一種是直接的Payment，對應Table_Payment記錄，另一種是使用者Account，對應Table_AccountTransaction記錄），但也并不滿意。大家可以進行更多的嘗試，并歡迎分享。
2. 送車上門和上門取車
這個功能是之前省略的，但現在的市場競争如此激烈。提供這樣的功能來提升使用者滿意度還是必須的。
對于這個功能有3個要求：
1. 系統應允許顧客在建立Order時選擇送車上門和上門取車服務，并提供輸入界面。
2. 顧客首次輸入一個新位址後，該位址應被記錄系統，供使用者下次選擇（就像淘寶送貨位址一樣）。
3. 顧客可以存儲多個位址，并能改變位址的優先級（影響顯示順序），或設定Default位址。
解決方案：
1. 增加一個Table_CustomerAddress表，記錄顧客多個可選位址。
Table_CustomerAddress字段
列名 解釋 CustomerAddress_ID Identity列 Customer_ID 顧客ID，外鍵 CustomerAddress_Country 國家 CustomerAddress_Province 省 CustomerAddress_City 城市 CustomerAddress_Address 詳細位址 CustomerAddress_Rank 位址等級（數字越小等級越高，顯示在最前面。1為Default位址） 2. 有了Table_CustomerAddress表，Table_Customer中的Customer_Address可以去除。
3. 在Table_Order中，把Order_BorrowStore字段名改為：Order_GetCarLocation，增加Order_IsGetCarAtHome是否送車上門字段（bit類型字段），若該字段為1，則Order_GetCarLocation字段記錄顧客選擇的送車上門位址ID，若為0，則記錄門店ID。同理，把Order_ReturnStore字段名改為：Order_ReturnCarLocation，增加Order_IsReturnCarAtHome是否上門取車字段。
加入送車上門和上門取車功能後的表關系圖
圖中用黃色标出了相應做的改變。
下篇預告
至此租車資訊系統資料庫設計基本完成了。
下一篇我們以這個設計為基礎來寫一些常見的查詢，如：顧客試圖預訂某型号車，并給出了需要租借的時間段，寫一個查詢來查找該車型的車輛相應時間是否有檔期，如果有則建立相應的Order（如果有該車型的多輛車有檔期，安排哪輛車能使車輛使用率最高呢？這個需要進一步思考）。
思考這些查詢也算是驗證先前的設計，一般在這個過程中有時會發現一些設計上的疏漏。