怎样为租车网专门设计数据库系统

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

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

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

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

5. 顾客在订车前需先进行注册，包括姓名，身份z号，驾照号，性别，手机号，固定电话，家庭住址，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相同。

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

可以向到就近的派出所查询一下你的新的身份z是否已经上传全国人口信息网，如果已经上传了，说明对方用的互联网数据未更新。如果派出所查询不到你的信息已经上传全国人口信息网，说明你转户籍时户籍部门未及时上传，可以要求及时上传数据。（但是估计这个可能性不大，应该属于前一种情况）

---