长春大学计算机学院网络工程专业
数据库原理 实验报告
附：实验报告参考示例
零件交易中心管理系统实验报告
一、实验目的
通过完成从用户需求分析、数据库设计到上机编程、调试和应用等全过程，进一步理解和掌握数据库的设计过程及方法。
二、实验内容
零件交易中心管理系统主要提供顾客和供应商之间完成零件交易的功能，其中包括供应商信息、顾客信息以及零件信息。
供应商信息包括供应商、供应商号、地址、电话、简介；
顾客信息包括顾客号、顾客名、地址、电话；
零件信息包括零件号、零件名、重量、颜色、简介等。
此系统可以让供应商增加、删除和修改所提供的零件产品，还可以让顾客增加、删除和修改所需求的零件。交易员可以利用顾客提出的需求信息和供应商提出的供应信息来提出交易的建议，由供应商和顾客进行确认后完成交易。
三、实验过程
1． 需求分析
(1)供应商
供应商的操作流程如图1所示。
图1
(2)顾客
顾客的地位和供应商几乎是对称的，所以功能分类上也很相似。顾客的操作流程如图2所示：
图2
(3)交易员
交易员的工作就是提出交易和完成交易。需要仔细考虑的问题是：一个交易如何产生，并如何达成。这可以用图3来说明。
图3
处理交易的时候可能面临如下问题：
a.一个交易只能在交易双方都同意的情况下才可以进行，所以数据库中的供求信息只能作为达成某个交易的基础；
b.交易的双方可能不同时使用这个系统，因此需要系统提供一个双方交换信息的方式；
c.系统需要提供一种方便系统(交易员)向用户提出建议来促成交易的途径，并在保证数据库数据完整性的情况下达成交易。
2．概念模型设计
数据库需要表述的信息有以下几种：
(1)零件信息；(2)供应商信息；(3)顾客信息；(4)供应商零件之间的联系(供应)
(5)顾客和零件之间的联系(求购)；(6)交易(三元联系)
用E-R模型表述该模型的设计，E-R图如图4所示。
图4
3．逻辑设计
通过E-R模型到关系模型的转化，可以得到如下关系模式：
(1)零件关系：part(ID，color，name，weight，intro)
(2)供应商关系：provider(ID，name，address，tele，intro)
(3)顾客关系：customer(ID，name，address，tele)
(4)供应关系：supply(partID,provideID，price，quantity)
(5)求购关系：after(customerID，partID，price，quantity)
(6)交易关系：Business(customerID，provideID，partID，price，quantity)
每个关系模式的主码都用下划线标出。同时，对于从联系导出的关系供应，求购和交易，使用与之相联系的实体集的码作为自己的主码，必须符合外码的约束。
对于顾客，供应商和零件之间，不存在直接的约束，所以可以存在没有供应商供应同时也没有顾客求购的零件。
4．物理设计
为了提高在表中搜索元组的速度，在实际实现的时候应该基于码建立索引。下面是各表中建立索引的表项。
part(ID) provider(ID) customer(ID)
supply(partID,provideID) after(customerID，partID)
Business(customerID，provideID，partID
5．用SQL实现设计
实现该设计的环境为Windows 2000 Professional +MS SQL Server 2000。
(1)建立各表
①建立零件表
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);
②建立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);
③建立Customer表
CREATE TABLE Customer(ID smallint identity(1,1)
PRIMARY KEY CLUSTERED,
Name varchar(20) NOT NULL,
Password varchar(8) NOT NULL,
Address varchar(30),
Tel varchar(20));
④建立Supply表
CREATE TABLE Supply(PartID smallint,ProvideID smallint,
Price int, Quantity int ,
CONSTRAINT PK_SUPPLY
PRIMARY KEY CLUSTERED(PartID,ProvideID),
CONSTRAINT PK_SUPPLY_PARTID
FOREIGN KEY(PartID) REFERENCES Part(ID),
CONSTRAINT PK_SUPPLY_PROVIDERID
FOREIGN KEY(ProvideID) REFERENCES Provider(ID));
⑤建立After表
CREATE TABLE After(CustomerID,smallint,PartID smallint,
Price int, Quantity int ,
CONSTRAINT PK_AFTER
PRIMARY KEY CLUSTERED(CustomerID, PartID),
CONSTRAINT PK_AFTER_CUSTOMERID
FOREIGN KEY(CustomerID) REFERENCES Customer(ID),
CONSTRAINT PK_AFTER_PARTID
FOREIGN KEY(PartID) REFERENCES Part(ID));
⑥建立Business表
CREATE TABLE Business(
CustomerID,smallint,
PartID smallint,
ProvideID smallint,
Price int, Quantity int ,
CONSTRAINT PK_BUSSINESS
PRIMARY KEY CLUSTERED(CustomerID,ProvideID,PartID),
CONSTRAINT PK_ BUSSINESS _CUSTOMERID
FOREIGN KEY(CustomerID) REFERENCES Customer(ID),
CONSTRAINT PK_BUSSINESS_PROVIDERID
FOREIGN KEY(ProvideID) REFERENCES Provider(ID));
CONSTRAINT PK_BUSSINESS_PARTID
FOREIGN KEY(PartID) REFERENCES Part(ID));
⑦供应商操作
a.注册(Register)
INSERT INTO Provider(Name,Address,Tel,Intro)
VALUES(#Name,#Address,#Tel,#Intro)
在登记操作后，供应商得到一个惟一的ID，可以根据这个ID来查询和修改供应商的数据。
b.注销(UnRegister)
DELETE Provider WHERE ID=#ID;
c.修改个人信息(Update)
UPDATE Provider
Set Name=#Name,Address=#Address,Tel=#Tel,Intro=#Intro
WHERE ID=#ID
d.增加供应项(Add_Supply_Item)
INSERT INTO Supply(PartID,ProviderID,Price,Quantity)
VALUES(#PartID,#ProviderID,#Price,#Quantity))
e.删除供应项(Delete_Supply_Item)
DELETE Supply
WHERE PartID=#PartID and ProvideID=#ProvideID);
f.修改供应项(Update_Supply_Item)
UPDATE Supply SET Price=#Price,Quantity=#Quantity)
WHERE PartID=#PartID and ProvideID=#ProvideID;
很明显，系统并没有提供商品面向供应商修改零件信息的接口，所以供应商提供的零件必须已经在零件表中存在；可以这样假设，交易所的管理员负责更新零件信息，而供应商可以向交易所申请增加某种零件的信息。事实上顾客也可提出这样的要求。
⑧顾客
a.注册(Register)
INSERT INTO Customer(Name,Address,Tel)
VALUES(#Name,#Address,#Tel)
在登记操作后，供应商得到一个惟一的ID，可以根据这个ID来查询和修改供应商的数据。
b.注销(UnRegister)
DELETE Customer WHERE ID=#ID;
c.修改个人信息(Update)
UPDATE Customer Set Name=#Name,Address=#Address,Tel=#Tel
WHERE ID=#ID
d.增加需求项(Add_After_Item)
INSERT INTO After(PartID,CustomerID,Price,Quantity)
VALUES(#PartID,#ProviderID,#Price,#Quantity))
e.删除需求项(Delete_After_Item)
DELETE After
WHERE PartID=#PartID and CustomerID=#CustomerID);
f.修改需求项(Update_After_Item)
UPDATE After SET Price=#Price,Quantity=#Quantity)
WHERE PartID=#PartID and CustomerID=#CustomerID;
⑨交易员
针对需求分析中提出的问题，提出了“协议书”的解决方案，方案的说明如下：
每个交易在达成以前都作为协议书保存在数据库中，协议书具有和交易一样的完备信息，可以在条件成熟的情况下转为一个达成的交易；
协议书只有在供应商和顾客都签字的情况下才有效；有效的协议书由交易员签发，协议书一经签发，就生效，表明一个交易的达成，数据库中的数据将同时予以修改；
协议书可以由供应商、顾客或者交易员中的任意一个人提出申请。当协议书在双方没有都签字前，协议的双方或者交易员都可以删除这个协议书；但是，当协议书签字完毕后，协议书就不得删除(修改)，只能由交易员进行处理；
协议书有可能在转成交易的过程中失败，因为在交易达成以前，数据库中的数据有可能因为其他交易而变化，一个协议书可能失败，这是允许的。
根据以上分析，对数据库的模型作一些修改，增加协议书表，其关系模式如下：
Agreement(CustomerID,ProviderID,PartID,Price,Quantity,CustomerSign,ProviderSign)
对应的SQL描述为：
CREATE TABLE Agreement(
CustomerID,smallint,
PartID smallint,
ProvideID smallint,
Price int,
Quantity int ,
CustomerSign int ,
ProviderSign int,
CONSTRAINT PK_AGREEMENT
PRIMARY KEY CLUSTERED(CustomerID,ProvideID,PartID),
CONSTRAINT PK_ AGREEMENT_CUSTOMERID
FOREIGN KEY(CustomerID) REFERENCES Customer(ID),
CONSTRAINT PK_ AGREEMENT_PROVIDERID
FOREIGN KEY(ProvideID) REFERENCES Provider(ID));
CONSTRAINT PK_ AGREEMENT_PARTID
FOREIGN KEY(PartID) REFERENCES Part(ID));
与上述其他操作相比，交易的操作对数据完整性要求比较高，其中需要注意的地方是：
要防止同一用户(供应商，顾客)的数据因两个交易而同时修改；
需要同时对供应数据库(S upply)、需求数据库(After)、交易数据库(Business)和协议数据库(Agreement)作出个性而且需要保持这些修改的原子性；
很显然，这些要求正是对一个事务(Transaction)的要求，所以可以用一个事务来完成签发一个协议的操作。事务的描述如下：
CREATE PROC PASS_AGREEMENT
@providerID int,
@customerID int,
@partID 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 provideID=@providerID and customerID=@customerID
AND partID=@partID
INSERTINTOBusiness(ProviderID,customerID,PartID,
Price,Quantity)
VALUES(@ProviderID, @CustomerID,@PartID,@Price,@Quantity)
UPDATE Supply
SET quantity=quantity-@quantity
WHERE ProviderID=@ProviderID AND partID=@partID
IF(SELECT quantity
FROM Supply
WHERE provideID=@providerID AND partID=@partID)<9
ROLLBACK TRANSACTION @TransName
DELETE FROM Supply
WHERE quantity=0
UPDATE after
SET quantity=quantity-@quantity
WHERE CustomerID=@CustomerID AND partID=@partID
If(SELECT quantity FROM After
WHERE CustomerID=@CustomerID AND partID=@partID)<0
ROLLBACK TRANSACTION @TransName
DELETE FROM A fter
WHERE quantity=0
COMMIT TRANSACTION @TransShow
GO
为了使用方便，这里定义了一个存储过程，功能是完成从Agreement的一个元组到期Business的每个元组的转化工具。这里考虑到了删除空的Supply和After项，更加重要的是，这里考虑到了非法的Agreement的情况，在一段时间后，由于供应商式或者顾客修改数据，Agreement可能就非法，这时就需要把这个事务废除，所以这里检查Supply表和After表中的数据，确保数据仍然正确。
另外，交易员，或者说交易所必须承担的一项任务是更新零件列表，这里在考虑顾客和供应商的时候，并没有给予他们修改零件列表的权利，他们必须根据数据库中已有的项实现应用模式的供应信息。
由于这个数据库实际上更加偏重于模型化，而不是一个实际环境中的数据库，所以在实现应用模型的时候还需要对这个数据库的模型作一些修改。
6．实验数据示例
插入零件信息：
INSERT INTO part(color，name，weight，intro)
VALUES(‘black’,’stick’,30,’of steel’);
显示插入的零件ID：
select id from part where name=’stick’;
以下操作同上，信息自定：
插入供应商信息：
INSERT INTO provider(name，password,address,tel,intro)
VALUES(‘com1’,’1234’,’北京’,’’86784012’,’noting’);
显示供应商ID：
select id from provider where name=’com1’;
插入顾客信息：
INSERT INTO customer(name,address,tel)
VALUES(‘cus1’,’北京’,’67584612’);
显示顾客ID
select id from provider where name=’cus1’;
插入供应商供应信息
INSERT INTO supply(partID,provideID，price，quantity)
VALUES (1,1,20,100);
插入顾客需求信息
INSERT INTO after(customerID，partID，price，quantity)
VALUES(1,1,20,50)
插入协议信息
INSERT INTO Agreement(CustomerID,ProviderID,PartID,Price,
Quantity,CustomerSign,ProviderSign)
VALUES(1,1,1,20,30,1,1)
执行交易操作
PASS_AGREEMENT 1,1,1
(后面3个参数分别前面选择出的供应商ID，顾客ID和零件ID)
显示交易后供应信息：
select quantity from supply where pardID=1 and providerID=1
需求信息：
select quantity from after where pardID=1 and customerID=1
分析上面的结果：
首先，保存在supply表中的ID的零件供应量为100，保存在after表中ID为1的零件需求量为50。在Agreement表中指出ID为1的顾客要交易30人ID为1的零件。当执行存储过程PASS_AGREEMENT之后， supply和after表中相应的数量都减少了30，交易成功。
7．实验总结
通过此次实验，完成从用户需求分析、数据库设计到上机的编程、调试和应用等全过程，进一步理解和掌握了数据库的各方面知识，并提高了实践能力。
本文来源：https://www.2haoxitong.net/k/doc/58d3c9310c22590103029dc3.html
文档为doc格式