数据库课程设计零件管理系统.docx
《数据库课程设计零件管理系统.docx》由会员分享，可在线阅读，更多相关《数据库课程设计零件管理系统.docx（14页珍藏版）》请在冰豆网上搜索。
数据库课程设计零件管理系统
数据库原理课程设计
题目零件交易中心管理系统
学院信息项目学院
专业计算机科学与技术
班级计科072
学号
学生姓名
指导教师
编写日期2018-03-02
1.需求分析3
2.概念模型设计4
3.逻辑设计5
4.物理设计5
5.测试阶段10
6.总结13
1.需求分析
1．供应商
供应商的操作流程图如图2-1所示。
图2-1供应商操作分类表
2．顾客
顾客的地位和供应商几乎是对称的，所以功能分类上也很相似．顾客的操作流程图如图2-2所示。
图2-2顾客操作分类表
3．交易员
交易员的工作就是提出交易和完成交易。
这里需要仔细考虑的问题是：
一个交易如何产生，并如何达成，可以用图2-3来说明这个问题．
我们在处理交易的时候可能面临如下问题：
（1>一个交易只能在交易双方都同意的情况下才可以进行，所以数据库中的供求信息只能作为达成某个交易的基础；
（2>交易的双方可能不同时使用这个系统，因此需要系统提供一个双方交换信息的方式；
（3>系统需要提供一种方便系统（交易员>向用户提出建议来促成交易的途径，并在保证数据库数据完整性的情况下达成交易。
图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模型到关系模型的转化，可以得到如下关系模式：
（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实现设计
实现该设计的环境为Windows2000Perfessinal+MSSQLServer2000.
<1）建立Part表
CREATETABLEPart（
IDsmallintIDENTITY（1,1>PRIMARYKEYCLUSTERED,
Colorvarchar（20>,
Namevarchar（20>NOTNULL,
WeightintDEFAULT0,
Introtext>
<2）建立Provider表
CREATETABLEProvider（
IDsmallintIDENTITY（1,1>PRIMARYKEYCLUSTERED,
Namevarchar（20>NOTNULL,
passwordvarchar（8>NOTNULL,
Addressvarchar（30>,
Telvarchar（20>,
Introtext>
<3）建立Customer表
CREATETABLECustomer（
IDSmallintIDENTITY（1,1>PRIMARYKEYCLUSTERED,
Namevarchar（20>NOTNULL,
Addressvarchar（30>,
TeLVarchar（20>>
<4）建立Supply表
CREATETABLESupply（
PartIDSmallint,
ProviderIDsmallint,
Priceint,
QUantityint,
CONSTRAINTPK_SUPPLYPRIMARYKEYCLUSTERED（PartID,ProviderID>,
CONSTRAINTFK_SUPPLY_PARTIDFOREIGNKEY（PartID>REFERENCESPart（ID>,
CONSTRAINTFK_SUPPLY_PROVIDERIDFOREIGNKEY（ProviderID>REFERENCESProvider（ID>>
<5）建立OfferToBuy表
CREATETABLEOfferToBuy（
CustomerIDsmallint,
PartIDSmallint,
Priceint,
Quantityint,
CONSTRAINTPK_OFFERTOBUYPRIMARYKEYCLUSTERED（CustomerID,PartID>,
CONSTRAINTFK_OFFERTOBUY_CUSTOMERIDFOREIGNKEY（CustomerID>
REFERENCESCustomer（ID>,
CONSTRAINTFK_OFFERTOBUYFOREIGNKEY（PartID>
REFERENCESPart（ID>>
<6）建立Business表
CREATETABLEBusiness（
CustomerIDsmallint,
ProviderIDsmallint,
PartIDSmallint,
Priceint,
Quantityint,
CONSTRAINTPK_BUSINEssPRIMARYKEYClUSTERED（CuscomerID,ProviderID,PartID>,
CONSTRAINTFK_BUSINESS_CUSTOMERIDFOREIGNKEY（CustomerID>
REFERENCESCustomer（ID>,
CONSTRAINTFK_BUSINESS_PROVIDERlDFOREIGNKEY（ProviderID>
REFERENCESProvider（ID>,
CONSTRAINTFK_BUSINESS_PARTIDFOREIGNKEY（PartID>
REFERENCESPart（ID>>
<7）供应商操作
①注册（register>
INSERTINTOProvider（Name，password，Address，TeI，Intro>
VALUES（#Name，#password，#Address，#Tel，#Intro>
在登记操作后，供应商得到一个唯一的ID，可以根据这个ID采查询和修改供应商的数据。
②注销（unregister>
DELETEProviderWHERE（ID=#ID>；
③修改个人馆息（update>
UPdateProviderSet（Name=#Name,Address=#Address，Tel=#Tel，Intro=#Intro>
WHERE（ID＝#ID>；
④增加供应项（add_supply_item>
INSERTINTOSupply（PartID，Providerid，Price，Quantity>
VALUES（#PartID，#ProvderlD，#Price；#Quantily>；
⑤删除供应项（delete_supply_item>
DELETESupPly
WHERE（PartlD=#PartIDANDProvideID=#ProviderlD>；
⑥修改供应项（update_supply_item>
UPDATESupplySET（Price=#Price，Quantity=#Quantity>
WHERE（PartlD=#PartIDANDProviderID=#ProviderID>‘
很明显，系统并没有提供面向供应商修改零件信息的接口，所以供应商提供的零件必须已经在零件表中存在；可以这祥假设，交易所的管理员负责更新零件信息，而供应商可以向交易所申请增加某种零件的信息．事实上顾客也可以提出这样的要求。
<8）顾客操作
①注册（register>
INSERTINTOCustomer（Name，Address，Tel>
VALUES（#Name，#Address，#Tel>；
在登记操作后，顾客得到一个唯一的ID，可以根据这个ID来查询和修改顾客的数据。
②注销（unregister>
DELETECustomer
WHERE；
③修改个人信息（update>
UPDATECustomerSet（Name=#Name，Address=#Address，Tel=#Tel>
WHERE（1D=#ID>；
④增加需求项（add_OfferToBuy_item>
INSERTINTOOfferToBuy（PartID,CustomeriD，Price，Quantity>
VALUES（#PartID，#CustomerID，#Price，#Quantity>'
⑤删除需求项（delete_OfferToBuy_iterm>
DELETEOfferToBuy
WHERE（PartlD=#PartlDANDCustomerlD=#CustomerID>；
⑥修改需求项（date_OfferToBuy_item>
UPDATEOfferToBuySET（Price=#Price，Quantity=#Quantity
WHERE（PartlD=#PartIDANDCustomeriD=#CustomerID>
<9）交易员
针对需求分析中提出的问题，我们提出了“协议书”的解决方案，方案的说明如下：
①每个交易在达成以前都作为协议书保存在数据库中，协议书具有和交易一样的完备信息，可以在条件成熟的情况下转为一个达成的交易；
②协议书只有在供应商和顾客都签字的情况下才有效；有效的协议书由交易员签发，协议书一经签发，就生效，表明一个交易的达成，数据库中的数据将同时予以修改；
③协议书可以由供应商、顾客或者交易员中的任意一个人提出申请。
当协议书在双方没有都签字前，协议的双方或者交易员都可以删除这个协议书；但是，当协议书签字完毕后，协议书就不得删除（修改>，只能由交易员进行处理；
④协议书有可能在转成交易的过程中失败，因为在交易达成以前，数据库中的数据有可能因为其他交易而变化，一个协议书可能失效，这是允许的。
根据以上分析，对数据库的模型作一些修改，增加协议书表，其关系模式如下：
Agreement（CustomerlD，ProviderID，PartID，Price，Quantity，CustomerSign，ProviderSign>
对应的SQL描述为：
CREATETABLEAgreement（
Customermsmallint，
ProviderlDsmallint，
PartlDsmallint，
Priceint,
Quantityint，
CustomerSignint，
ProviderSignint，
CONSTRAINTPK_AGREEMENTPRIMARYKEYCLUSTERED（CustomerID，ProviderID，PartID>，CONSTRAINTFK_AGREEMENT_CUSTOMERIDFOREIGNKEY（CustomerID>REFERENCESCustomer（ID>，CONSTRAINTFK_AGREEMENT_PROVlDERIDFOREIGNKEY（ProviderID>REFERENCESProvider（ID>，CONSTRAINTFK_AGREEMENT_PARTIDFOREIGNKEY（PartID>REFERENCESPart（ID>>
与上述其他操作相比，对交易的操作对数据完整性要求比较高，其中需要注意的地方是；要防止同一用户（供应商，顾客>的数据因两个交易而同时修改；需要同时对供应数据库（Supply>、需求数据库（OfferToBuy>、交易数据库（Business>和协议数据库（Agreement>作出修改，而且需要保持这些修改的原子性；很显然，这些要求正是对于一个事务（transaction>的要求，所以可以用一个事务来完成签发一个协议的操作。
事务的描述如下：
CREATEPROCPASS_AGREEMENT
@providerIDint，
@customeridint，
@partlDint
AS
DECLARE@TransNameVARCHAR（20>
SELECT@TransName='Pass_Agreement'
BEGINTRANSACTION@TransName
DEClARE@priceINT，@qUANTITYint
SELECT@price=price，@quantity=quantityFROMAgreement
WHEREprIVIderID=@providerIDANDcustomerID=@customerIDANDPanID=@partID
1NSERTINTOBusiness（ProviderID，CustomerID，PartID，Price，Quantity>
VALues（@providerid，@customerID，@PartID，@price,@quantity>
UPDATESupplySETquantity=quantity-@quantity
WHEREProviderID=@prividerIDANDpartID=@partID
IF（SELECTquantityFROMSupply
WHEREProiderid=@providerANDpartID=@PartID><0
ROLLBACKTRANSACTlON@TranSName
DELETEFROMSupplyWHEREquantity=0
UPDATEOfferToBuySETquantity=quanttity-@quantity
WHERECustomerID=@customeridANDpartlD=@partID
IF（SELECTquandtityFROMOfferToBuy
WHERECustomerID=@CustomerIDANDpartID=@partlD><0
ROLLBACKTRANSACTION@TransName
DELETEFROMOfferToBuyWHEREquantity=0
COMMITTRANSACTION@TransName
为了使用方便,这里定义了一个存贮过程；功能是完成从Agreementt的一个元组到Business的一个元组的转化工作。
这里考虑到了删除空的Suppiy和OfferTOBUY项，更加重要的是，这里考虑到了非法的Agreement的情况，在一段时间后，因为供应商或者顾客修改数据，Agreement可能就非法，这时就需要把这个事务废除，所以，这里检查了Supply表和OfferToBuy表中的数据，确保数据仍然正确。
另外交易员，或者说交易所必须承担的一项任务是更新零件列表。
这里在考虑顾客和供应商的时候÷并没有给予他们修改零件列表的权利，所以他们必须根据数据库中已有的项更新自己的供求信息。
因为这个数据库实际上更加偏重于模型化，而不是一个实际环境中的数据库，所以在实现应用模型的时候我们还需要对这个数据库的模型作一些修改。
因为本实验在模型设计上使用了MicrosoftTransact-SQL的语法，因此以上的数据库操作都是在SQLSERVER2000上测试通过的。
5.测试阶段
1．输入数据设计
<1）插入零件信息；
createprocedureinsert_lj
as
insertintoPart（Color，Name，Weight，Intro>
values（'black'，'stick'，'30'，'ofsteel'>
显示刚插人的零件id：
execinsert_lj
id
----
1
（1row（s>affected>
（不同的实验，id值可能不同。
以后相应操作要保持前后一致就可以丁。
>
<2）插入供应商信息：
createprocedureinsert_gys
as
insertintoProvider（Name，password，Address，Tel，Intro>
values（'coml'，'1234'，'北京'，6543210，'nothing'>
显示刚插入的供应商id：
execinsert_gys
id
---
1
（1row（s>affected>
<3）插入顾客信息：
createprocedureinsert_gk
as
insertintoCustomer（Name，Address，Tel>
values（'cusl'，'北京'，'6666666'>
显示刚插入的顾客id：
execinsert_gk
id
---
1
（1row（S>affected>
<4）插入供应商供应信息：
createprocedureinsert_gysgy
as
insertintoSupply（PartID，ProviderlD，Price，Quantity>
values（1，1，20，100>；
<5）插入顾客需求信息：
createprocedureinsert_gkxq
as
insertintoOfferToBuy（PartlD，CustomerID，Priee，Quantity>
values（1，1，20，50>；
<6）插入协议信息：
createprocedureinsert_xyxx
as
insertintoAgreement（CustomerID,ProviderID，PartlD，Price，Quantity，CustomerSign，ProviderSign>
values（1，1，1，20，30，1，1>；
2.执行交易操作设计
<1）执行交易存储过程PASS_AGREEMENT,参数为：
1，1，1：
PASS_AGREEMENT1，1，1。
（后面的三个参数分别对应前面选择出的供应商ID、顾客ID和零件ID。
>
<2）结果：
显示交易后供应信息和需求信息：
createprocedure交易后供应信息
@PartIDint（8>
@ProviderIDint（8>
as
selectQuantity
fromSUpply
wherePartID=@PartIDandProviderID=@ProviderID
exec交易后供应信息
Quantity
----
70
（1row（s>affected>
createprocedure交易后需求信息
@PartIDint（8>
@CustomerIDint（8>
as
selectQuantity
fromOfferToBuy
wherePartlD=@PartIDandCustomerID=@CustomerID
exec交易后需求信息
Quantity
-----
20
（1row（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）再次执行交易操作：
CreateprocedureDelete
as
deletefromBusiness；
6.总结
本次课程设计调查从事零件产品的零售、批发等工作的企业，根据其具体情况，设计零件销售管理系统。
加深了对数据库课程知识的理解。
因为时间仓促，软件还有很多不足之处，如：
零件信息查询部分不够完善，软件代码交冗余、效率不高等等，都相关功能缺乏认识造成的。
在今后的学习中我们会加强理论的实践的结合，通过不断摸索来弥补自己在软件制作方面的差距。
通过此次数据库的课程设计，真正达到了学与用的结合，增强了对数据库方面应用的理解，对自己今后参与开发数据库系统积累了不少经验，在实验过程中，从建立数据开始，对灵据库设计理念及思想上有更高的认识，从需求分析，到概念设计和逻辑设计，E-R图的表示，数据字典的创建，懂得了不少有关数据库开发过程中的知识，在实验中建表，及其关系模式，关系代数的建立及理解，将SQL语的查询语句用得淋漓尽致，增强了自己在数据库中应用SQL语言的灵活性，其中包括，插入、删除、修改、查询,牵涉表和表之间的联系，主建与外主键的定义，约束项的设置，使逻辑更严密，在学习过程中，我也能过上网查了不少资料，也看了一些别人设计的图书馆管理信息系统的设计报告，学以致用，自我创新，独立完成了这份自己的报告，从中在学到用，从用又到学，不断修改，系统更新。
虽然不能达到完善系统，但也做到了尽善尽美，加强理论学习对完善系统会有很多帮助，不管怎么说，对这次做的课程设计自己觉得还算满意。
申明：
所有资料为本人收集整理，仅限个人学习使用，勿做商业用途。
升级会员 