最近在看《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相同。
这些方案会影响到系统使用的灵活性，易用性和可追溯性。大家可以对这些方案的优点和缺点进行思考和讨论。
时间差不多了，要去干活了。到现在为止，这一数据模型还远未达到基本可使用的阶段。我们将在其后的篇目中进一步讨论，提出新的需求和挑战，并修改、完善这一设计。
