最近在看《Database modeling & design:logical design》一书，其中有一道练习题是对简单租车系统进行数据库逻辑设计并画出ER图。

　　这道题给我挺多遐想的，所以我在这里把这些想法记录下来，也试着设计一把。

　　要进行数据库设计，首先要对需求进行分析。需求分析一般会需要对业务人员进行随访，收集信息。我没办法进行随访，就通过自己的遐想来假设需求场景(可能会有错误与遗漏)。

　　最初想到的：

　　1. 租车公司有多个租车门店，分布于多个不同的地区，并有各自的租车电话。

　　2. 每个租车门店有多辆汽车可供租赁。

　　3. 供租赁的车辆需要登记车辆识别代号(VIN)，购入时间，所属门店，车辆型号，车辆状态(可租Ready，维修中Repair，租出Inuse，无效Inactive)

　　4. 车辆的租用费用基本由车辆型号和日期类型(平日，周末，还是节假日)来决定。

　　5. 顾客在订车前需先进行注册，包括姓名，身份证号，驾照号，性别，手机号，固定电话，家庭住址，Email。

　　6. 注册顾客可通过系统下租车单，预约某车型，若干天的租赁(预约期最远为6个月)。

　　7. 租车单需记录顾客编号，车辆编号，租赁起始日期，租赁结束日期，提车门店，还车门店，租赁费用，预付款金额，订单状态(输入Entered，提交Booked，预约Reserved，使用中Inuse，交还Returned，取消Cancelled)。注：暂不提供送车上门和上门取车服务。

　　对于上述需求，比较明显的需创建的表有：车辆(Table_Car)，门店(Table_Store)，顾客(Table_Customer)，订单(Table_Order)。

　　除此之外，车辆型号，车辆状态，日期类型和订单状态分别创建成四张枚举表Table_CarCategory，Table_CarStatus，Table_DateType，Table_OrderStatus。

　　还应有一张租车价位对照表(Table_BasePrice)，其中会包含两个外键分别指向Table_CarCategory，Table_DateType。

　　简单表关系图如下：

　　

　　大部分字段的含义大家可以从命名中猜测到。其中需要注意的有两点：

　　1. 这一设计中有4张枚举表(Table_DateType,Table_CarCategory,Table_OrderStatus,Table_CarStatus)，在实际的信息系统或业务系统中这样的枚举表可能非常多。把这些枚举表整合到一张配置表中会带来哪些好处与哪些坏处?是否还有其他解决方案?大家可以进行思考。

　　2. 租车价位对照表在图中被设计成Table_BasePrice。其主键为一联合键，包括CarCategory_ID(表明车型，如：乐风 1.6 MT)，DateType_ID(表明是平日，周末或节日)，BasePrice_StartDate(表明从哪个时间点开始顾客在系统页面看到新的价格)，其中CarCategory_ID，DateType_ID同时为外键。这是一种设计方式。

　　另有2种可选的设计方式：

　　待选方案1. 把Table_BasePrice中的DateType_ID去除，Table_BasePrice只存某种车型的初始租价。在Table_DateType中多加一列DateType_AdjustRate，存放一个大于等于1的比率，如：平日比率为1.0，双休日为1.1。某一日的基本租价为：比率×初始租价。

　　待选方案2. 在待选方案1的基础上，直接去除Table_BasePrice表。把BasePrice_Price放到Table_CarCategory中(可改名为CarCategory_Price)。其他修改和方案1相同。

　　这些方案会影响到系统使用的灵活性，易用性和可追溯性。大家可以对这些方案的优点和缺点进行思考和讨论。