北京理工大学计算机学院数据库开发实验报告3Word格式.docx

上传人:wj 文档编号:13035603 上传时间:2022-10-03 格式:DOCX 页数:9 大小:242.14KB
下载 相关 举报
北京理工大学计算机学院数据库开发实验报告3Word格式.docx_第1页
第1页 / 共9页
北京理工大学计算机学院数据库开发实验报告3Word格式.docx_第2页
第2页 / 共9页
北京理工大学计算机学院数据库开发实验报告3Word格式.docx_第3页
第3页 / 共9页
北京理工大学计算机学院数据库开发实验报告3Word格式.docx_第4页
第4页 / 共9页
北京理工大学计算机学院数据库开发实验报告3Word格式.docx_第5页
第5页 / 共9页
点击查看更多>>
下载资源
资源描述

北京理工大学计算机学院数据库开发实验报告3Word格式.docx

《北京理工大学计算机学院数据库开发实验报告3Word格式.docx》由会员分享,可在线阅读,更多相关《北京理工大学计算机学院数据库开发实验报告3Word格式.docx(9页珍藏版)》请在冰豆网上搜索。

北京理工大学计算机学院数据库开发实验报告3Word格式.docx

整张表的核心是合同信息,它将企业与客户、企业与产品的联系描述。

合同中的产品因为其数量不定,应有一个合同产品关系表,记录产品数量、价格、折扣、维修时长。

部门信息表DEPT:

其属性分别为部门编号、部门名称、地址、电话;

客户信息表,其属性分别为客户编号、姓名、地址、电话;

厂商信息,属性分别为厂商编号、名称、电话、地址。

三张表的共同特征是主键皆为外键组织信息表的主键组织编号。

产品表PRODUCT:

在企业合同管理中,产品也是一个很重要而具有独立特征的实体,其属性为产品编号(主键)、产品名称、产品价格、厂商编号(外键)。

产品编号用于区别产品,而厂商编号是用于区别同种产品。

合同信息表CONTRACT:

其属性为合同编号(主键)、合同名称、客户编号(外键)、销售员工编号(外键)、技术审核员工编号(外键)、商务审核员工编号(外键)、合同日期、合同金额。

合同产品关系表CONTRACT_PRODUCT:

合同信息表中未涉及合同中的产品信息,原因是合同中的产品可能不止一件,故应该另有一张表用以记录合同中所包含的产品信息。

其属性为产品编号(外键、联合主键)、合同编号(外键、联合主键)、交易价格、交易折扣、交易数量、保修时长。

其中保修时长是添加上的属性,用以实现查询产品是否在保修期内功能,之后也会具体说明。

付款信息表PAYMENT:

其属性为付款单编号(主键)、付款金额、付款日期、合同编号(外键)。

付款信息对于售后服务中判断产品是否在保修期内是很关键的。

这里的付款信息表应该是针对全额付款的情况,而与之相对应的则是部分付款(分期付款)。

已收付款表PAID:

其属性为已收付款单编号(主键)、收款金额、收款日期、合同编号(外键)。

这个表格针对于分期付款的客户。

仔细看两个表发现差别不大,也可以像之前组织信息表那样集成,不过表单属性较少且简单,这样设计反而更有利于企业催款与企业现有价值统计。

以上是对参考的合同管理系统数据模型的理解。

下面是主要针对售后服务管理系统数据模型设计的阐述。

二、售后服务部分

售后服务这个过程主要分为服务记录和服务过程。

实体服务记录生成了唯一的服务编号,它将服务与客户、服务与产品间的联系描述。

实体服务过程主要记录服务中所涉及到的需记录的事项。

然而报修单上不可缺少的修理内容即产品编号,因其不唯一的性质,故另起一表用来记录服务产品。

下面是我对于每个表的具体说明及设计的思路:

1.服务过程表SERVER_PROCESS:

在服务过程中,应该有起到唯一标识作用的主键,即为服务编号。

服务类型,因为服务过程表不止是针对某一种特定服务所设计的表,为了区别不同的服务,设置了这样一个属性,以此来将服务分类。

自然也要有技术工程师编号,一项工作无论结果好坏、效率高低,都应由人来做,所以要记录技术工程师的编号。

服务内容,记录服务过程中的工作内容,是知道用户使用产品还是上门维修机器,

应该有大致记录,这对于之后的员工评比也很重要。

下面是服务过程表的属性:

① 服务编号,设为整型,我的ER图中服务过程表中的服务编号为外键,引用自表服务记录。

因为服务编号的唯一性,起标识作用。

服务过程表中每一条记录都与服务编号表中的一条记录相对应。

只要服务记录表中有记录,也就是说明有这样的一次服务存在,故服务过程中也会有相对应的记录。

② 服务类型为整型,值为“1”时,说明服务类型为咨询;

值为“2”时,说明服务类型为上门维修。

当然也可以设置其他的服务类型,如接听电话。

③ 技术工程师编号,为整型外键,引用自员工信息表。

必须是公司的员工才能是技术工程师。

此处不能为空,用来记录是谁做的此项工作。

④ 服务内容,为varchar型,默认长度为50,用于简明记录工作内容。

2. 服务记录表SERVER_RECORD:

标识服务记录的最好方式就是给它一个编号,所以就设置了属性服务编号,这个编号是整个售后服务中很重要的一个属性,它是唯一的。

服务记录中应该有记录产生的时间的属性,我在表中设计为致电日期。

这个属性作用是可以将同一个客户的不同时间来电都记录下来。

比如说,可以查询出相同合同相同产品的报修记录,如2012年1月有一条服务记录等。

也可以根据致电频率来评估产品质量及客户消耗产品速度,这样可以合理调整产品价位。

一次电话接听服务,需要由接听员工来负责。

如果服务出现意外,如用户单位并没有报修,但企业却派出了技术工程师,对企业造成的损失需要有人承担。

又如,员工评比时,可以由记录数量作为接听员工的工作量凭据。

下面是服务记录表的属性:

① 服务编号为整型,具体说明在服务过程表中。

② 致电日期,设为datetime,记录用户来电日期。

③ 接听员工编号,外键引用自员工信息表,接听员工也必是企业员工。

此属性不能为空,因为每次电话接听都有一个接听者。

④ 客户编号,外键引用自组织信息表,表中可以依次查询到组织地址、电话号码等信息。

所以记录一个客户编号比记录客户名称更方便且高效。

3. 维修产品表SERVER_PRODUCT:

服务产品表主要是依据合同产品关系表设计的,由产品编号、合同编号和服务编号联合标识表中记录,确定唯一服务对象。

出于对员工工作量统计方面和费用方面考虑,需要记录一次服务中的维修特定产品

的数量。

也可以根据此来评估产品质量,对企业营销计划提供凭据。

下面是服务产品表的属性:

维修产品数,设为整型,条件是值必须大于零。

4.付款完成表CONTRACT_FINISH:

用于记录合同金额是否付款完成,最后一次付款完成后即为维修开始时间。

下面是付款完成表的属性:

付款完成,设为整型,为'

0'

即为未完成,为'

1'

为完成。

ER售后服务模型

结合所设计的ER图回答下面问题:

(1) 如何实现售后服务中的产品服务期限的?

在售后服务模型中,加入了付款完成表CONTRACT_FINISH表,根据PAID表判断当前合同是否付款完毕,根据最后一次付款完成的日期,即为服务开始的日期。

当企业售后部门给某一客户提供服务,无论其服务类型,自动生成一个“服务编号”。

则每次服务都会产生相应记录。

为了"

合同编号”方便观察,企业先前在产品上刻有或者贴有标签上记录着“合同编号”。

“合同编号”也是唯一的。

“服务编号”生成后,就可以向数据库中录入信息了。

客户联系人需要提供故障产品名称,可以根据产品名称在产品信息表中查到产品编号;

或者直接给出“产品编号”(产品编号也可以随“合同编号”一起印在产品上)。

此时我们就有了“产品编号”和“合同编号”,它们是合同产品关系表的主键,故可以凭此查询表中信息,得到产品的“保修时长”,通过已得到的最后一次付款完成的日期,这样通过简单的减法运算,即可得出产品是否在保修期内。

(2) 如何记录售后服务的产品信息?

针对整个服务过程,设计了服务过程表SERVER_PROCESS,建立此表处于以下考虑:

一方面,一次服务中可能会涉及到不止一件产品需要维修,那么一栏产品属性是不足以记录所有的服务对象的;

另一方面,当企业的技术工程师已经按照单位工作安排完成了A客户单位的B产品维修,此时A单位发现C产品也出了问题,提出要求维修,此时也需要记录下服务产品信息。

服务产品表是用来记录维修过程中所服务的产品对象信息的。

根据服务编号我们就可以轻松查到某次服务中所有服务产品对象的信息。

(3) 如何记录技术服务工程师(包括服务专员)的信息?

首先是针对记录技术服务工程师的基本信息,在员工信息表中就记录着详细信息。

表中默认是每次服务企业只派一个技术专员来完成该项工作。

服务过程表中有记录每次服务的技术专员的编号,根据这个编号就可以在员工信息表中查询到相关信息。

当然也可以仿照服务产品表,建一个服务工程师表,其中记录每次服务所有工程师的信息。

(4) 一个完整的服务信息(如维修一个磁盘可能包括第一次打电话咨询、维修等由多

个小服务组成一个大服务)是如何记录的?

一个完整服务,是针对某个合同上的某一类产品的。

即只要是有合同,那么对于该合同产品企业方就应该有相应的服务信息。

设计中对于大服务的记录就是用每一个小服务来记录的,最后根据合同编号和产品编号联合属性进行查询。

这样,对于特定合同的某一产品,客户方针对其打过几次电话,要求过几次上门维修服务,以及致电频率和每次服务结果都一目了然。

首先在服务产品表中即可以根据合同编号和产品编号查询到所有关于特定产品的服务编号记录。

然后根据这些服务编号我们可以在服务记录表中查询到所有的来电日期,同时在服务过程表中查询到所有的服务信息,如服务结果。

这几次查询都可以通过主键服务编号来连接,将想要查询的信息表连接在一起,关于特定合同的某一产品的完整服务信息即可显示,最后将数据按照服务记录表中的致电日期升序排列,则可以按照时间顺序查看服务信息。

用Windows系统下的登录连接数据库服务器。

在SSMS中新建一个名为

ContractManagement的数据库。

三、ER物理模型导入数据库

创建数据库之后,打开Erwin中设计好的ER物理模型。

单击菜单栏上的ActionsDatabaseConnection,出现下图中的界面。

手动输入服务器名称,再在DataBase(数据库)那一栏中填上SSMS中已存在的数据库名称。

当然也可以不用填,ER模型会自动生成到数据库master中。

我在DataBase中填上ContractManagement,这个刚才创建的数据库。

单击Connect即连接成功。

此时连接上了数据库,但是还没有完成生成SQL语句并且在SQLServer中建表。

下面单击菜单栏上的Actions-ForwardEngineer-Schema出现下图界面。

因为版本问题,单击Trigger标签,将右栏界面中ErwinGenerated勾掉。

如下图:

此时可以单击Preview预览SQL语句,可以进行相应修改,检查无误后即可单击Generate键即可在数据库中生成相应表格。

打开SSMS截图如下,说明表成功建立。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > PPT模板 > 国外设计风格

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1