酒店管理数据库设计
一、设计说明
目前大多数酒店提供的服务多种多样，规模大小也各不相同，但稍具规模的酒店必含下面三类服务：饮食、住宿和娱乐。对此次数据库设计简单模仿中等规模的酒店设计管理系统，并将其抽象成一个由四个部门（饮食、住宿、娱乐和经理）组成、实现三大服务的系统。
二、部门的划分
1． 饮食部门
它是酒店基本部门之一。它提供服务的特点是实时性强、持续时间短，强调效率。例如，顾客人数、顾客所用的菜及其它饮料等种类繁多，数量不等；后勤各种活动如采购等频繁发生。通过分析可发现，用人工完成此类操作比计算机更具实效与时效，且此类信息也没有长时间保留的必要，因此这些信息没有必要采用数据库管理。对于饮食部门，需要较长时间保留的信息主要是财务信息，一方面便于期末汇总，另一方面便于向上级报告。
在规模较大的酒店餐饮服务部分，餐厅可分成几个等级或几个小部门，然后各自形成小系统，本系统为了简单起见，把饮食部门作为一个子系统，不再细分。
2． 住宿管理部门
它也是酒店基本部门之一。住宿管理部门的主要职责有：A.给个房间布置各种设备、分类、编号、制定收费标准、分配服务人员。B.登记旅客信息，确认其身份，登记其入住、退房时间。C.统计各类房间的客满程度。D.对本部门的财务流动进行登记处理。以上信息处理可以通过计算机完成，其他不便于计算机操作的在此没有列出。
3． 娱乐管理部门
娱乐是酒店非主流服务，它的存在除了赢利，更多的是为了吸引顾客食宿。娱乐部门的特点与饮食部门很相似，不便于使用计算机进行操作。可以用计算机完成并且有必要用计算机完成的有：A.制定收费标准，分配负责人.B.收入支出财务处理：编号、财务来源去处的摘要、数量、单价、数额、结余、经手人等。这些信息都需要长时间保留并上报。
4． 经理部门
经理部门的功能虽然不是面向顾客、不是酒店的服务项之一，但它的存在却是必不可少的。它的主要职责有：A.管理员工。给员工编号，登记其基本信息；根据员工的平时表现及工龄确定工资；此外，还要给员工分配工作部门及职务等等。B.划分部门。给个部门编号、命名、确定其职责范围、任命部门经理、分配员工。C.对本部门的财务进行核算（支付工资等）。D.期末对酒店的收益情况进行核算。
三、各子系统的功能
虽然酒店按功能可以划分成四个部门，但是饮食部门的大部分工作手工操作比计算机操作更具有效率，如上所述，便于电脑操作只有财务处理。在划分子系统时，考虑到各子系统都有各自的财务处理，且有相似性，所以就把它们归为统一的一个“财务子系统”。同时“饮食子系统”取消，因为它的所有需要涵盖的功能都已包含在“财务子系统”中。因此系统共划分为四部分：总经理子系统、财务子系统、住宿子系统和娱乐子系统。
1． 总经理子系统
A. 对新来的员工进行编号、登记、分配工作。
{员工号、姓名、性别、年龄、工龄、级别、部门号、职务、其他备注}
B. 对于被辞退的员工从系统中级联删除其信息，如从员工表中删除其基本信息，从它所服务的工作部门中删除该员工的工作名额，结算支付其工资、奖金；同时补充新的员工，代替它的工作。
C. 对新增部门作各种初始工作。如编号、命名、任命经理等。
{部门号、名称、部门经理、员工数量}
D. 取消某个部门时，核算该部门的财务情况，并作备份；同时对该部门的员工重新分配工作。
E. 其他情况的处理。
2． 财务子系统
A. 每天的收入、支出登记
{编号、发票号、摘要、数量、单位、数额、经手人、日期}
B. 期末各子系统的财务汇总
{编号、上月余额、总收入、总支出、余额、经手人、日期}
C. 期末酒店汇总个部门的财务报表，结算本酒店收益
(编号、部门号、部门名称、收入、支出、净收入、经手人、日期)
3． 住宿子系统
A. 来客登记
若多人住同一房间，只作一个记录。
客人信息{房间号、房间类别、客人数量、联系人名、身份、证件名称（类型）、证件号码、入住时间、退出时间}
B. 房间管理
旅客入住（旅客退出）除了登记（删除）客人信息之外，还应对相关的记录进行修改，如房间的状态等。
房间类别{类别号、名称、设备、收费标准、总数量、剩余量、管理人员}
房间{房间号，房间类型、状态}
( 该部门的财务处理与饮食子系统同，归到财务子系统)
4． 娱乐子系统
A. 添加新的娱乐项目
娱乐项目{娱乐项目号、名称、收费标准、负责人}
B. 取消某娱乐项目
（财务处理 （同饮食子系统） 归到财务子系统 )
四、数据字典
1． 数据项
数据项有待按各子系统分类列表。
2． 数据结构
3． 数据流
4． 数据存储
5． 处理过程
概念结构设计过程
本公司开发酒店管理系统,经过可行性分析、详细调查以及多次讨论,确定了该系统由娱乐管理部门、经理管理部门、宿舍管理部门和财务管理部门四个子系统组成。
本过程结构设计过程采用自底向上的设计方法,即首先定义各局部应用的概念结构,然后将它们集成起来,得到全局概念结构.
下面给出各个子系统的分析及分E-R图的设计及对其进行的各项调整。
经理管理部门子系统
本开发小组成员经过调查、信息流程分析、数据收集，并结合需求分析，明确了——
子系统的功能:
A.管理员工:给员工编号，登记其基本信息。根据员工的平时表现确定其出勤工资及根据等级确定其固定工资，从而确定其实际工资，此外还要给员工分配工作部门等。
B.划分部门:给各部门编号、命名、确定其职责范围、任命部门经理、分配员工。
C.对本部门的财务进行核算（支付工资等）。
根据要求分析给出的数据流图,参照数据字典中的详细描述,给出经理管理部门的分E-R图:
对E-R图调整的准则:
现实世界中的事物能作为属性对待的尽量作为属性对待；
属性和实体的划分：属性中不具有需要描述的信息，即属性是不可分的数据项，不再包含其他信息。
实体属性定义:
员工(员工号、姓名、性别、年龄、工龄、级别、部门、职务、备注)
工资(员工号、等级、实际工资、基本工资、出勤工资)
部门(部门号、名称、部门经理、员工数量)
账单（编号、发票号、摘要、收入数、支出数、日期、经手人、备注）
具体调整如下:
1. 本来员工还应对应一个领导关系,但这里为了简便,就用员工的”等级”属性来表示员工之间的领导关系；
2. 工资本应作为员工的一个属性，但这里需强调员工对应的出勤工资（由出勤情况决定），因此将它单独作为一个实体；
3. 部门对应的账单本应属于财务子系统的内容，这里为了简化财务子系统，先在各个子系统中进行财务总结，因此，将账单也作为一个实体。
娱乐管理部门子系统
本开发小组成员经过调查、信息流程分析、数据收集,并结合需求分析，明确了——
子系统的功能:
A.为各个项目制定收费标准，分配负责人；
B.收入支出财务处理：编号、财务来源去处的摘要、数量、单价、数额、结余、经手人等信息；
C.对在部门内进行娱乐的顾客进行收费，并根据折扣规则给与顾客相应的折扣；
D.对部门内部进行帐务处理；
根据要求分析给出的数据流图,参照数据字典中的详细描述,给出经理管理部门的分E-R图:
实体属性定义:
项目(编号、名称、所在位置、收费标准、负责人)
员工(员工号、姓名、性别、年龄、工龄、级别、部门、职务、备注)
顾客(顾客号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、使用时间、备注)
款项(顾客号、级别、使用时间、应收款、实际收款、折扣)
折扣规则(级别、折扣情况)
账单（编号、发票号、摘要、收入数、支出数、日期、经手人、备注）
对E-R图调整的准则:
现实世界中的事物能作为属性对待的尽量作为属性对待；
属性和实体的划分：属性中不具有需要描述的信息，即属性是不可分的数据项，不再包含其他信息。
具体调整如下:
1．本来员工还应对应一个领导关系,但这里为了简便,就用员工的“等级”属性来表示员工之间的领导关系；
2．款项本可以作为顾客的一个属性来设置，但这里为了强调对顾客的折扣情况，需要对款项进行进一步的描述，因此这里作为一个实体；
3．对顾客所采取的折扣规则，本应该根据顾客的实际消费量来划定，这里为了方便起见，给每位顾客添加了一个“级别”属性，用以对应采取的折扣规则；
4．部门对应的账单本应属于财务子系统的内容，这里为了简化财务子系统，先在各个子系统中进行财务总结，因此，将账单也作为一个实体；
住宿管理部门子系统
本开发小组成员经过调查、信息流程分析、数据收集,并结合需求分析，明确了——
子系统的功能:
A.给个房间布置设备、分类、编号、制定收费标准、分配服务人员。
B.登记旅客信息，确认其身份，登记其入住、退出时间；
C.接受顾客的预定服务，对于已预定的客房进行登记的处理；
D.统计各类房间的客满程度；
E.对本部门的财务流动进行登记处理。
根据需求分析给出的数据流图,参照数据字典中的详细描述,给出经理管理部门的分E-R图:
实体属性定义:
顾客(顾客号、级别、姓名、年龄、性别、证件类型、证件号码、入住时间、退出时间、备注)
客房（客房号、类别、位置、设备、收费标准、管理人员、状态）
员工(员工号、姓名、性别、年龄、工龄、级别、部门、备注)
款项(顾客号、级别、使用时间、应收款、实际收款、折扣)
折扣规则(级别、折扣情况，折扣数)
订单(订单号、时间、房间号、经手人、备注)
账单（编号、发票号、摘要、收入数、支出数、日期、经手人、备注）
对E-R图调整的准则:
现实世界中的事物能作为属性对待的尽量作为属性对待；
属性和实体的划分：属性中不具有需要描述的信息，即属性是不可分的数据项，不再包含其他信息。
具体调整如下:
1．本来员工还应对应一个领导关系,但这里为了简便,就用员工的“等级”属性来表示员工之间的领导关系；
2．款项本可以作为顾客的一个属性来设置，但这里为了强调对顾客的折扣情况，需要对款项进行进一步的描述，因此这里作为一个实体；
3．对顾客所采取的折扣规则，本应该根据顾客的实际消费量来划定，这里为了方便起见，给每位顾客添加了一个“级别”属性，用以对应应采取的折扣规则；
4．部门对应的账单本应属于财务子系统的内容，这里为了简化财务子系统，先在各个子系统中进行财务总结，因此，将账单也作为一个实体。
财务管理子系统
本开发小组成员经过调查、信息流程分析、数据收集,并结合需求分析，明确了——
子系统的功能:
A. 对各个部门上交上来的收支情况进行汇总，得出各个部门的损益情况；
B. 对整个酒店各个部门的损益情况进行汇总登记，得出本期酒店的损益；
C. 将整个酒店的收益情况下发给各个部门，帐务公开，集思广益。
分E-R图如下:
实体属性定义:
部门(部门号、名称、部门经理、员工数量)
员工(员工号、姓名、性别、年龄、工龄、级别、部门、职务、备注)
账单（编号、发票号、摘要、收入数、支出数、日期、经手人、备注）
总帐(编号、部门号、收入、支出、净利、日期、经手人、备注)
财务状况（时期、总收入、总支出、净利润）
对E-R图调整的准则:
现实世界中的事物能作为属性对待的尽量作为属性对待；
属性和实体的划分：属性中不具有需要描述的信息，即属性是不可分的数据项，不再包含其他信息。
具体调整如下:
员工应对应一个领导关系,但为了简便起见,就用员工的“等级”属性来表示员工之间的领导关系。
视图集成
以上便是四个子系统的分E-R图设计及其调整的整个过程，接着要做的就是将所有的分E-R图进行综合,合成一个系统的总E-R图.
由于本系统比较简单,分E-R图规模也比较小,所以E-R图合成过程采用一次将四个子系统分E-R图集成总E-R图的方式.
分两步进行：
第一步：合并。
解决各分E-R图之间的冲突，将各分E-R图合并起来生成初步E-R图。
各分E-R图之间的冲突主要有三类：
1． 属性冲突：
（1）属性域冲突，即属性值的类型、取值范围或取值集合不同。由于本系统较简单，所以并不存在这种冲突；
（2）属性取值单位冲突。由于本系统较简单，不存在这类冲突；
2． 命名冲突：
（1） 同名异义：由于本系统较简单，所以不存在这类冲突；
（2） 异名同义：由于本系统较小，所以不存在这类冲突；
3． 结构冲突：
（1） 同一对象在不同应用中具有不同的抽象：本系统在需求分析阶段原本存在这种冲突，考虑到后期的简化合并，我们在设计各个分E-R图就早先解决了这个问题，即将在任何一个分E-R图中作为实体出现的属性全部作为实体；
（2） 同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同：由于本系统较简单，所以并不存在这种冲突；
第二步：修改和重构。
消除不必要的冗余，生成基本E-R图。
由于本系统涵盖的内容比较少，基本不存在冗余的现象，所以初步E-R图就是基本E-R图，不必再进行调整。下面给出E-R图。
总E-R图:
员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；
工资(员工号、等级、实际工资、基本工资、出勤工资)；
部门(部门号、名称、部门经理、员工数量、财务状况编号)；
项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号)；
顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、使用时间、备注)；
客房（客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态）；
款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款)；
折扣规则(折扣级别、折扣情况，折扣数)；
订单(订单号、顾客号、经手人号、备注)；
账单（账单编号、总帐编号、发票号、收入数、支出数、日期、经手人号、备注）；
总帐(总帐编号、部门号、财务状况编号、收入、支出、净利、日期、经手人号、备注)；
财务状况（财务状况编号、时期、总收入、总支出、净利润）；
逻辑结构设计
一.与总E-R图对应的关系模式
1、实体所对应的关系模式：
员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；
工资(员工号、等级、实际工资、基本工资、出勤工资)；
部门(部门号、名称、部门经理、员工数量、财务状况编号)；
项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号)；
顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、使用时间、备注)；
客房（客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态）；
款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款)；
折扣规则(折扣级别、折扣情况，折扣数)；
订单(订单号、顾客号、经手人号、备注)；
账单（账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注）；
总帐(总帐编号、部门号、财务状况编号、收入、支出、净利、日期、经手人号、备注)；
财务状况（财务状况编号、时期、总收入、总支出、净利润）；
说明：1.下加横线部分表示关系的码
2.以上关系的详细内容说明请参照概念结构设计中的具体内容
3.上面的各个关系对概念结构设计中的相关内容了作了修改，主要加了各个实体中间的联系，尤其是一对多的联系，纳为属性。
2、联系所对应的关系模式：
1）、把客房和订单之间的n : m的预约联系转化为相应的关系模式如下：
预约（订单号、客房号、始定时间、结束时间）；
2）、把顾客和房间之间的n : m的住宿联系转化为相应的关系模式如下：
住宿（顾客号、房间号码、住宿时间）；
3）、把顾客和项目之间的n : m的选择联系转化为相应的关系模式如下：
选择（顾客号、项目号、发生时间、经受人号、备注）；
4）、其他联系处理说明如下：
工资和员工之间的1：1联系与员工关系合并；
顾客和订单之间的1：1联系与订单关系合并；
折扣规则和款项之间的1：1联系与款项关系合并；
员工和部门之间的n：1联系与员工关系合并；
部门和财务状况之间的n：1联系与部门关系合并；
客房和部门之间的n：1联系与客房关系合并；
项目和部门之间的n：1联系与项目关系合并；
总帐和财务状况之间的n：1联系与总帐关系合并；
帐单和总帐之间的n：1联系与帐单关系合并；
帐单和项目之间的n：1联系与项目关系合并；
二.优化后的数据模型
1、按照数据依赖对关系模式进行逐一分析，并进行极小化处理：
员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；BCNF
工资(员工号、等级、实际工资、基本工资、出勤工资、工资年月)；BCNF
部门(部门号、名称、部门经理、员工数量、财务状况编号)；BCNF
项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号)；BCNF
顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、备注)；BCNF
优化说明：删除了使用时间，一是因为“使用时间”对于顾客的属性必要性不强，二是因为使用时间在别的关系中也可以查询到。
客房（客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态）；BCNF
款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款)；BCNF
折扣规则(折扣级别、折扣情况，折扣数)；BCNF
订单(订单号、顾客号、经手人号、备注)；BCNF
账单（账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注）；BCNF
总帐(总帐编号、部门号、财务状况编号、收入、支出、日期、经手人号、备注)；BCNF
优化说明：删除了净利, 这一项可以根据收入、支出可以计算，而且并不经常对它进行查询。
财务状况（财务状况编号、时期、总收入、总支出、净利润）；1NF
优化说明：净利润没有删除, 因为在这一项上查询比较频繁, 如果每次查询都计算, 必然使系统计算增加，性能降低。保留下来虽然造成了一定的冗余, 但提高了查询的效率，利大于弊。
预约（订单号、客房号、始定时间、结束时间）；3NF
住宿（顾客号、房间号码、住宿时间）；3NF
选择（顾客号、项目号、发生时间、经受人号、备注）；3NF
2、对关系模式进行必要的分解：
因公司内人员进行查询时，一般只用到自己所属单位的信息，故可把“人员”关系按部门进行水平分解，以提高查询效率。
水平分解：员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)
改为：负责人员(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；
服务人员(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；
经手人员(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；
三、用户子模式设计
1．经理子系统用户子模式
员工(员工号、姓名、级别、部门号、职务、部门经理、实际工资)；
因为经理对于员工其他情况不会经常关注，经常使用的只有以上各项，所以在经理子系统上设立员工关系。
2．住宿子系统用户子模式
客房（客房号、位置、设备、收费标准、管理人员号、状态）；
因为管理员工对于客房的其他情况不会经常使用，经常使用的只有以上各项，所以在住宿子系统上设立客房关系
3．经营管理子系统用户子模式
顾客（顾客编号、住宿号、姓名、级别、应收款、使用时间、备注）
因为对于顾客的情况管理经常使用是以上各项，所以在经营管理子系统上设立顾客关系。
物理结构设计
一. 存储结构设计
经过分析可知,本酒店管理系统中信息处理的特点如下：
（１）饮食、住宿、娱乐三大部门的数据不仅经常需要查询,而且更新速度快,例如住宿部门的来客查询与登记，房间的动态分配等。
（２）各个部门信息要求共享的信息较多。例如员工信息,来客信息等。但财务信息一般不共享。
（３）经理部门有一定的特殊职能：汇总财务信息；对于被辞退的员工从系统中级联删除其信息、如从员工表中删除其基本信息、从它所服务的工作部门中删除该员工的工作名额，结算支付其工资、奖金；同时补充新的员工，代替它的工作。
针对这些特点，设计如下:
1. 确定数据库的存放位置
为了提高系统性能，现根据应用情况将数据按照易变部分和稳定部分、经常存取部分和存取频率较低的部分分别在两个磁盘上存放。同时，考虑到本系统是多用户的，为了提高效率，数据库的备份的数据和日志文件将保存在磁带中。
l 经常存取部分：
员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；
工资(员工号、等级、实际工资、基本工资、出勤工资)；
客房（客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态）；
款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款)；
折扣规则(折扣级别、折扣情况，折扣数)；
项目(项目编号、部门号码、名称、所在位置、收费标准、负责人号)；
顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、备注)；
l 存取频率较低的部分：
部门(部门号、名称、部门经理、员工数量、财务状况编号)；
账单（账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注）；
订单(订单号、顾客号、经手人号、备注)；
总帐(总帐编号、部门号、财务状况编号、收入、支出、日期、经手人号、备注)；
财务状况（财务状况编号、时期、总收入、总支出、净利润）；
2. 确定系统配置
酒店管理系统需要的微机数量和规模都不必太大，但在系统设计时应考虑到酒店的发展需求，在选择硬件设备、服务器操作系统、数据库时都考虑到能够逐步的增加和扩展。
本酒店管理系统选用了Windows9x系统作为微机的操作系统，它能够有较好的使用界面并能够充分发挥出微机硬件的作用，比较适合酒店这样的机构；另外，选用了目前应用最多的SQL SERVER 数据库。
由于涉及到酒店的财务管理，数据的完整性和安全性显得尤其重要。系统中的数据一旦丢失，将需要很长时间进行恢复，有时甚至使信息系统不得不从系统初始化阶段重新开始运行。每天进行数据备份是保障系统安全的重要手段。数据备份需要严格按照事先制定的备份与故障恢复策略进行，并落实备份登记和检查措施。
具体的系统配置应当根据系统实际运行情况做进一步的调整。
二. 存取路径设计
1. 存取方式的分析:
对饮食、住宿、娱乐三个子系统的各个关系最经常的操作是查找，假设现有n个住宿房间的信息，如果采取顺序查找，平均查找n/2次；建立B+树索引，则平均查找次数为B+树的层数log2n+1。
所以选择B+树作为索引,具体设计如下：
l 对以下经常在查询中出现的关系的码建立索引＜说明：下加横线部分表示关系的码＞
员工(员工号、姓名、性别、年龄、工龄、级别、部门号、职务、备注)；
工资(员工号、等级、实际工资、基本工资、出勤工资)；
部门(部门号、名称、部门经理、员工数量、财务状况编号)；
客房（客房号、类别、部门号、位置、设备、收费标准、管理人员号、状态）；
款项(款项编号、顾客号、项目号、折扣级别、使用时间、应收款、实际收款)；
折扣规则(折扣级别、折扣情况，折扣数)；
财务状况（财务状况编号、时期、总收入、总支出、净利润）；
l 以下经常进行连接操作的关系的码建立索引:
员工号、客房号、部门号等
l 由于下面几个关系模式的更新频率很高,所以没有定义索引:
顾客(顾客编号、级别、姓名、年龄、性别、证件号码、证件名称、所选项目、备注)；
订单(订单号、顾客号、经手人号、备注)；
账单（账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注）；
三. 数据库关键字的定义说明：
员工(员工号：类型char宽度4 编号格式为:
A001、A002… )；
部门(部门号: 类型char宽度4 编号格式为:
B001、B002…)；
客房（客房号: 类型char宽度4 编号格式为:
K0001、K0002…）；
款项(款项编号: 类型char宽度10 编号格式为:
K051214-1、K051214-2…K051214-123、K051214-124…)；
说明：款项编号由年月日加数字序号构成，其中取年份后两位，月份两位，月内日期号两位，后面的数字序号由系统根据当前顾客的到来顺序依资编号。这样的好处可以直接根据序号知道顾客是那天款项结账的。
折扣规则(折扣级别：类型char宽度5 编号格式为:
Z00001、Z00002…)；
财务状况（财务状况编号：类型char宽度10 编号格式为:
A200512-1、A200512-2…A200512-123、A200512-124…）；
说明：财务状况编号由字母A+年号（四位）+月号+‘-’+编号序号构成。
顾客(顾客编号：类型char宽度10 编号格式为(作用参照款项编号):
G051214-1、G051214-2…G051214-123、G051214-124…)；
订单(订单号: 类型char宽度10 编号格式为(作用参照款项编号):
D051214-1、D051214-2…D051214-123、D051214-124…)；
账单（账单编号: 类型char宽度10 编号格式为(作用参照款项编号):
S051214-1、S051214-2…S051214-123、S051214-124…)；
总账（总账编号: 类型char宽度10 编号格式为(作用参照款项编号):
Z051214-1、Z051214-2…Z051214-123、Z051214-124…)；
项目（项目编号: 类型char宽度5 编号格式为:
X0001、X0002、X0003……；)
四. 表设计附图
最后方案在SQL2000系统中完成，其表间关系可通过给定关系图得出
