《管理软件开发》课程设计报告
——个人记账管理系统
一、设计时间
20##年12月 26日-----12月30日
二、设计地点
湖南城市学院一实验楼 511机房
三、设计目的
1、运用所学的数据库基础知识，设计并编写一个《个人记账管理系统》的开发。
2、掌握数据库原理的相关理论和数据库的设计实现过程。
3、在实际项目中培养相关知识和综合应用的能力；
4、培养学生查阅资料的习惯，提高学生独立思考和解决问题的能力。
四、设计小组成员
0806402-04 江国丰 0806402-22欧阳明双 0806402-35姚凯
五、指导老师
吴宏斌老师 黄雪华老师
六、设计课题
通过对一些实际问题的软件设计，使学生能将课本的理论知识应用于实践，编制出较为实用的小系统《个人记账管理系统》：
1、记账管理增加；
2、记账管理修改；
3、记账管理删除；
4、记账管理查询；
七、基本思路及关键问题的解决方法
该系统总共分为四块，采用MVC模式编写的个人记账管理系统信息维护。我负责的个人记账管理系统信息维护的修改与删除：
UpdateDialog.java 修改信息
AccountDao.java 调用dao层的deleteAccount(String condition)删除函数
个人记账管理系统的思路及关键问题的解决方法：
对个人记账的财务收支进行管理，实现对个人财务的明细账单的增、删、改、查的功能。
八、算法及流程图
1、算法流程图
个人记账管理系统算法及流程图
2、功能模块图
个人记账管理系统功能模块图
3、ER图
记账信息表:记账ID,记账开销，收支费用，收支时间，收支方式，备注
个人记账管理系统ER图
九、调试过程中出现的问题及相应解决办法
1.修改后台数据不成功显示？
解决办法：连接后台数据出错，修改连接方式，数据库表的字段名称，调试后，成功已显示。
2.根据ID删除记录有问题，不能删除？
解决办法：进从后台获取id时出错，没读到后台数据库的id，修改调试代码，删除成功。
十、课程设计心得体会
本次数据库设计让我学到了很多，可以运用到平时的日常生活中，我感到很实用。而且我很喜欢这门课，老师也很好，让我学会了做事要拿出自己的态度，凡是要认真对待。
开始操作起来有些困难，每次去问老师，同学怎么操作，老师和同学都很认真的不厌其烦的讲解给我，我感到很开心，真心的学习到很多。
数据库课程设计主要的目标是利用课程中学到的数据库知识和技术较好的开发设计出数据库应用系统，去解决各行各业信息化处理的要求。通过这次的课程设计，可以巩固我们对数据库基本原理和基础理论的理解，掌握数据库应用系统设计开发的基本方法，进一步提高我们综合运用所学知识的能力。
这次课程设计，我收获还是蛮多的，感谢大家，感谢老师。
十一、源程序（每句语言要有详细解释）；
publicint updateAccount(Account account,String condition){
int result=0;
//更新SQL语句
String sql="update account set
type=?,money=?,aDate=?,partType=?,"
+"message=? where "+condition;
try {
PreparedStatement pstmt = DataBase.getCon().prepareStatement(sql);// SQL语句的执行
pstmt.setString(1, account.getType());
pstmt.setFloat(2, account.getMoney());
pstmt.setString(3, account.getADate().toString());
pstmt.setString(4, account.getPartType());
pstmt.setString(5, account.getMessage());
result = pstmt.executeUpdate();
pstmt.close();//关闭
} catch (SQLException ex) {
ex.printStackTrace();
}
return result;
}
参考文献
[1] 郭真，王国辉．JSP程序设计教程[M]．北京:人民电邮出版社，2011.
[2] 萨师煊，王珊．数据库系统概论[M]．北京:高等教育出版社，2004.
[3] 姜桂洪．SQL Server 2005数据库应用与开发[M]．北京:清华大学出版社，2005.
第二篇：数据库课程设计—零件管理系统
数据库原理课程设计
题 目 零件交易中心管理系统
学 院 信息工程学院
专 业 计算机科学与技术
班 级 计科072
学 号
学生姓名 指导教师
编写日期 2010-03-02
1.需求分析 ....................... 2
2.概念模型设计 ................... 3
1
3.逻辑设计 ....................... 4
4.物理设计 ....................... 5
5.测试阶段 ...................... 10
6.总结 .......................... 13
1.需求分析
1．供应商
供应商的操作流程图如图2-1所示。
图2-1 供应商操作分类表
2．顾客
顾客的地位和供应商几乎是对称的，所以功能分类上也很相似．顾客的操作流程图如图2-2所示。
图2-2 顾客操作分类表 3．交易员
交易员的工作就是提出交易和完成交易。这里需要仔细考虑的问题是：一个交易如何产生，并如何达成，可以用图2-3来说明这个问题．
我们在处理交易的时候可能面临如下问题：
(1)一个交易只能在交易双方都同意的情况下才可以进行，所以数据库中的供求信息只能作为达成某个交易的基础；
(2)交易的双方可能不同时使用这个系统，因此需要系统提供一个双方交换信息的方式；
(3)系统需要提供一种方便系统(交易员)向用户提出建议来促成交易的途径，并在保证数据库数据完整性的情况下达成交易。
2.1.
图3-1供应商和零件之间的联系(供应) E-R模型
2.顾客集和零件集之间的联系(求购)
图3-2 顾客和零件之间的联系(求购) E-R模型
3.交易(三元联系)
可以用E-R模型表述该模型的设计，E-R图如图3-3所示。
图3-3 全局E-R模型
3.逻辑设计
通过E/R模型到关系模型的转化，可以得到如下关系模式：
4
(1)零件实体集转换为关系：Part(ID，Color，Name，Weight，Intro)
(2)供应商实体集转换为关系Provider(ID，Name，Addtess，Tel，Intro)
(3)顾客实体集转换为关系Customer(ID，Name，Addtess，Tel)
(4)供应联系转换为关系Supply(PartlD，ProviderlD，Price，Quantity)
(5)求购联系转换为关系OfferToBuy(CustomerlD，PartID，Price，Quantity)
(6)交易联系转换为关系Business(CustomerlD，ProviderlD，PartID，Price，Quantity)
每个关系模式的主键码都用下划线标出。
同时，对于从联系导出的关系Supply(供应)，OfferToBuy(求购)和Business(交易)，使用与之相联系的实体集的主健码作为自己的键码，必须符合外键码约束。
对于Customer(顾客)，Provider(供应商)和Part(零件)之间，不存在直接的约束，所以可以存在没有供应商供应同时也没有顾客求购的零件。
4.物理设计
1．为了提高在表中搜索元组的速度，在实际实现的时候应该基于键码建立索引是各表中建立索引的表项：
(1)part(ID)
(2)Provider(ID)
(3)Customer(ID)
(4)Supply(PartID，ProviderID>
(5)OfferTOBuy(CustomerID，PartID)
(6)Business(CustomerlD，ProviderID，PartID)
2．用SQL实现设计
实现该设计的环境为Windows 2000 Perfessinal+MSSQLServer 2000.
（1）建立Part表
CREATE TABLE Part(
ID smallint IDENTITY(1,1) PRIMARY KEY CLUSTERED, Color varchar(20),
Name varchar(20) NOT NULL,
Weight int DEFAULT 0,
Intro text)
5
（2）建立Provider表
CREATE TABLE Provider(
ID smallint IDENTITY(1,1) PRIMARY KEY CLUSTERED, Name varchar(20) NOT NULL,
password varchar(8) NOT NULL,
Address varchar(30),
Tel varchar(20),
Intro text)
（3）建立Customer表
CREATE TABLE Customer(
ID Smallint IDENTITY(1,1) PRIMARY KEY CLUSTERED,
Name varchar(20) NOT NULL,
Address varchar(30),
TeL Varchar(20) )
（4）建立Supply表
CREATE TABLE Supply(
PartID Smallint,
ProviderID smallint,
Price int,
QUantity int,
CONSTRAINT PK_SUPPLY PRIMARY KEY CLUSTERED(PartID,ProviderID), CONSTRAINT FK_SUPPLY_PARTID FOREIGN KEY(PartID) REFERENCES
Part(ID),
CONSTRAINT FK_SUPPLY_PROVIDERID FOREIGN KEY(ProviderID) REFERENCES
Provider(ID))
（5）建立OfferToBuy表
CREATE TABLE OfferToBuy(
CustomerID smallint,
PartID Smallint,
Price int,
Quantity int,
CONSTRAINT PK_OFFERTOBUY PRIMARY KEY
CLUSTERED(CustomerID,PartID),
CONSTRAINT FK_OFFERTOBUY_CUSTOMERID FOREIGN KEY(CustomerID)
REFERENCES Customer(ID),
CONSTRAINT FK_OFFERTOBUY FOREIGN KEY(PartID)
REFERENCES Part(ID))
（6）建立Business表
CREATE TABLE Business(
CustomerID smallint,
ProviderID smallint,
PartID Smallint,
6
Price int,
Quantity int,
CONSTRAINT PK_BUSINEss PRIMARY KEY
ClUSTERED(CuscomerID,ProviderID,PartID),
CONSTRAINT FK_BUSINESS_CUSTOMERID FOREIGN KEY(CustomerID)
REFERENCES Customer(ID),
CONSTRAINT FK_BUSINESS_PROVIDERlD FOREIGN KEY(ProviderID)
REFERENCES Provider(ID),
CONSTRAINT FK_BUSINESS_PARTID FOREIGN KEY(PartID)
REFERENCES Part(ID))
（7）供应商操作
①注册(register)
INSERT INTO Provider(Name，password，Address，TeI，Intro)
VALUES(#Name，#password，#Address，#Tel，#Intro)
在登记操作后，供应商得到一个唯一的ID，可以根据这个ID采查询和修改供应商的数据。
②注销(unregister)
DELETE Provider WHERE(ID=#ID)；
③修改个人馆息(update)
UPdate Provider Set(Name=#Name,Address=#Address，Tel=#Tel，Intro=#Intro) WHERE(ID＝#ID)；
④增加供应项(add_supply_item)
INSERT INTO Supply(PartID，Providerid，Price，Quantity)
VALUES(#PartID，#ProvderlD，#Price；#Quantily)；
⑤删除供应项(delete_supply_item)
DELETE SupPly
WHERE(PartlD=#PartID AND ProvideID=#ProviderlD)；
⑥修改供应项(update_supply_item)
UPDATESupplySET(Price=#Price，Quantity=#Quantity)
WHERE(PartlD=#PartID AND ProviderID=#ProviderID)‘
很明显，系统并没有提供面向供应商修改零件信息的接口，所以供应商提供的零件必须已经在零件表中存在；可以这祥假设，交易所的管理员负责更新零件信息，而供应商可以向交易所申请增加某种零件的信息．事实上顾客也可以提出这样的要求。
（8）顾客操作
①注册(register)
INSERT INTO Customer(Name，Address，Tel)
7
VALUES(#Name，#Address，#Tel)；
在登记操作后，顾客得到一个唯一的ID，可以根据这个ID来查询和修改顾客的数据。
②注销(unregister)
DELETE Customer
WHERE<ID=#ID)；
③修改个人信息(update)
UPDATE Customer Set(Name=#Name，Address=#Address，Tel=#Tel)
WHERE(1D=#ID)；
④增加需求项(add_OfferToBuy_item)
INSERT INTO OfferToBuy(PartID,CustomeriD，Price，Quantity)
VALUES(#PartID，#CustomerID，#Price，#Quantity)'
⑤删除需求项(delete_OfferToBuy_iterm)
DELETE OfferToBuy
WHERE(PartlD=#PartlD AND CustomerlD=#CustomerID)；
⑥修改需求项(date_OfferToBuy_item)
UPDATE OfferToBuy SET(Price=#Price，Quantity=#Quantity
WHERE(PartlD=#PartID AND CustomeriD=#CustomerID)
（9）交易员
针对需求分析中提出的问题，我们提出了“协议书”的解决方案，方案的说明如下：
①每个交易在达成以前都作为协议书保存在数据库中，协议书具有和交易一样的完备信息，可以在条件成熟的情况下转为一个达成的交易；
②协议书只有在供应商和顾客都签字的情况下才有效；有效的协议书由交易员签发，协议书一经签发，就生效，表明一个交易的达成，数据库中的数据将同时予以修改；
③协议书可以由供应商、顾客或者交易员中的任意一个人提出申请。当协议书在双方没有都签字前，协议的双方或者交易员都可以删除这个协议书；但是，当协议书签字完毕后，协议书就不得删除(修改)，只能由交易员进行处理；
④协议书有可能在转成交易的过程中失败，因为在交易达成以前，数据库中的数据有可能因为其他交易而变化，一个协议书可能失效，这是允许的。
根据以上分析，对数据库的模型作一些修改，增加协议书表，其关系模式如下：
Agreement(CustomerlD，ProviderID，PartID，Price，Quantity，CustomerSign，ProviderSign)
8
对应的SQL描述为：
CREATE TABLE Agreement(
Customerm smallint，
ProviderlD smallint，
PartlD smallint，
Price int,
Quantity int，
CustomerSign int，
ProviderSign int，
CONSTRAINT PK_AGREEMENT PRIMARY KEY CLUSTERED(CustomerID，ProviderID，
PartID)，CONSTRAINT FK_AGREEMENT_CUSTOMERID FOREIGN KEY(CustomerID) REFERENCES Customer(ID)，CONSTRAINT FK_ AGREEMENT_PROVlDERID FOREIGN
KEY(ProviderID) REFERENCES Provider(ID)，CONSTRAINT FK_AGREEMENT_PARTID FOREIGN KEY(PartID)REFERENCES Part(ID))
与上述其他操作相比，对交易的操作对数据完整性要求比较高，其中需要注
意的地方是；要防止同一用户(供应商，顾客)的数据因两个交易而同时修改； 需要同时对供应数据库(Supply)、需求数据库(OfferToBuy)、交易数据库(Business)和协议数据库(Agreement)作出修改，而且需要保持这些修改的原子性；很显然，这些要求正是对于一个事务(transaction)的要求，所以可以用一个事务来完成签发一个协议的操作。事务的描述如下：
CREATE PROC PASS_AGREEMENT
@providerID int，
@customerid int，
@partlD int
AS
DECLARE @TransName VARCHAR(20)
SELECT @TransName='Pass_Agreement'
BEGIN TRANSACTION @TransName
DEClARE @price INT，@qUANTITY int
SELECT @price=price，@quantity=quantity FROM Agreement
WHERE prIVIderID=@providerID AND customerID=@customerID AND
PanID=@partID
1NSERT INTO Business(ProviderID，CustomerID，PartID，Price，Quantity)
VALues(@providerid，@customerID，@PartID，@price,@quantity)
UPDATE Supply SET quantity=quantity-@quantity
WHERE ProviderID=@prividerID AND partID=@partID
IF (SELECT quantity FROM Supply
WHERE Proiderid=@provider AND partID=@PartID)<0
ROLLBACK TRANSACTlON @TranSName
DELETE FROM Supply WHERE quantity=0
UPDATE OfferToBuy SET quantity=quanttity-@quantity
9
WHERE CustomerID=@customerid AND partlD=@partID
IF(SELECT quandtity FROM OfferToBuy
WHERE CustomerID=@CustomerID AND partID=@partlD)<0
ROLLBACK TRANSACTION @TransName
DELETE FROM OfferToBuy WHERE quantity=0
COMMIT TRANSACTION @TransName
为了使用方便,这里定义了一个存贮过程；功能是完成从Agreementt的一个元组到Business的一个元组的转化工作。这里考虑到了删除空的Suppiy和OfferTOBUY项，更加重要的是，这里考虑到了非法的Agreement的情况，在一段时间后，由于供应商或者顾客修改数据，Agreement可能就非法，这时就需要把这个事务废除，所以，这里检查了Supply表和OfferToBuy表中的数据，确保数据仍然正确。
另外交易员，或者说交易所必须承担的一项任务是更新零件列表。这里在考虑顾客和供应商的时候÷并没有给予他们修改零件列表的权利，所以他们必须根据数据库中已有的项更新自己的供求信息。
由于这个数据库实际上更加偏重于模型化，而不是一个实际环境中的数据库，所以在实现应用模型的时候我们还需要对这个数据库的模型作一些修改。
由于本实验在模型设计上使用了Microsoft Transact-SQL的语法，因此以上的数据库操作都是在SQLSERVER2000上测试通过的。
5.测试阶段
1．输入数据设计
（1）插入零件信息；
create procedure insert_lj
as
insert into Part(Color，Name，Weight，Intro)
values('black'，'stick'，'30'，'of steel')
显示刚插人的零件id：
exec insert_lj
id
----
1
(1 row(s) affected)
(不同的实验，id值可能不同。以后相应操作要保持前后一致就可以丁。)
（2）插入供应商信息：
create procedure insert_gys
10
as
insert into Provider(Name，password，Address，Tel，Intro)
values('coml'，'1234'，'北京'，6543210，'nothing')
显示刚插入的供应商id：
exec insert_gys
id
- - -
1
(1 row(s) affected)
（3）插入顾客信息：
create procedure insert_gk
as
insert into Customer(Name，Address，Tel)
values('cusl'，'北京'，'6666666')
显示刚插入的顾客id：
exec insert_gk
id
- - -
1
(1 row(S)affected)
（4）插入供应商供应信息：
create procedure insert_gysgy
as
insert into Supply(PartID，ProviderlD，Price，Quantity)
values(1，1，20，100)；
（5）插入顾客需求信息：
create procedure insert_gkxq
as
insert into OfferToBuy(PartlD，CustomerID，Priee，Quantity)
values(1，1，20，50)；
（6）插入协议信息：
create procedure insert_xyxx
as
insert into Agreement(CustomerID,ProviderID，PartlD，Price，Quantity，CustomerSign，ProviderSign)
values(1，1，1，20，30，1，1)；
2.执行交易操作设计
（1）执行交易存储过程PASS_AGREEMENT,参数为：1，1，1：
11
PASS_AGREEMENT 1，1，1;
(后面的三个参数分别对应前面选择出的供应商ID、顾客ID和零件ID。)
（2）结果：显示交易后供应信息和需求信息：
create procedure 交易后供应信息
@PartID int(8)
@ProviderID int(8)
as
select Quantity
from SUpply
where PartID=@PartID and ProviderID=@ProviderID
exec 交易后供应信息
Quantity
- - - -
70
(1 row(s) affected)
create procedure 交易后需求信息
@PartID int(8)
@CustomerID int(8)
as
select Quantity
from OfferToBuy
where PartlD=@PartID and CustomerID=@CustomerID
exec 交易后需求信息
Quantity
-----
20
(1 row(s) affected)
（3）分析结果：
首先，保存在Supply表中1D为1的零件供应量为100(参见Supply表的Insert语句)，保存在OfferToBuy表中ID为1的零件需求量为50(参见OFFERToBuy表的Insert语句)。在Agreement表中指出ID为1的供应商和ID为1的顾客要交易30个ID为1的零件。当执行存储过程PASS_AGREEMENT之后，Supply和OfferToBuy表中相应的数量都减少了30，交易成功。
（4）再次执行交易操作：
Create procedure Delete
as
12
delete from Business；
6.总结
本次课程设计调查从事零件产品的零售、批发等工作的企业，根据其具体情况，设计零件销售管理系统。加深了对数据库课程知识的理解。由于时间仓促，软件还有很多不足之处，如：零件信息查询部分不够完善，软件代码交冗余、效率不高等等，都相关功能缺乏认识造成的。在今后的学习中我们会加强理论的实践的结合，通过不断摸索来弥补自己在软件制作方面的差距。
通过此次数据库的课程设计，真正达到了学与用的结合，增强了对数据库方面应用的理解，对自己今后参与开发数据库系统积累了不少经验，在实验过程中，从建立数据开始，对灵据库设计理念及思想上有更高的认识，从需求分析，到概念设计和逻辑设计，E-R图的表示，数据字典的创建，懂得了不少有关数据库开发过程中的知识，在实验中建表，及其关系模式，关系代数的建立及理解，将SQL语的查询语句用得淋漓尽致，增强了自己在数据库中应用SQL语言的灵活性，其中包括，插入、删除、修改、查询,牵涉表和表之间的联系，主建与外主键的定义，约束项的设置，使逻辑更严密，在学习过程中，我也能过上网查了不少资料，也看了一些别人设计的图书馆管理信息系统的设计报告，学以致用，自我创新，独立完成了这份自己的报告，从中在学到用，从用又到学，不断修改，系统更新。虽然不能达到完善系统，但也做到了尽善尽美，加强理论学习对完善系统会有很多帮助，不管怎么说，对这次做的课程设计自己觉得还算满意。
13