数据库课程设计指导书

第五章课程设计

5.1实验简介

实验名称：管理系统的后台数据库设计

建议学时：一周

实验目的：

本实验的目的是为了让学生能够全面了解数据库应用系统的整个开发过程，逐步掌握系统开发的以下相关技术：

(一)巩固数据库理论知识，熟悉一种具体的数据库管理系统（例如：SQL Server）的使用方法。

(二)掌握针对特定应用环境数据库的设计。

(三)综合使用SQL Server中数据库、表、视图、索引、触发器、存储过程的创建使用方法。

(四)体会运用软件工程的设计思想进行软件系统开发的过程与方法。

通过本课程设计，有助于学生巩固数据库系统的理论，掌握数据库的设计方法及数据库的运用和开发技术。

实验内容及步骤:

针对某部门或公司的实践调研，通过系统需求分析、数据库概念设计、逻辑设计, 用SQL上机编程、调试和应用实现数据库的设计,最终完成某管理系统的后台数据库设计。

(一)系统需求分析和系统设计

用软件工程的方法进行系统需求分析和系统设计得出系统的数据流图数据字典和信息模型。

(二)数据库设计

按数据库设计方法和规范化理论得出符合3NF的逻辑模型，外模型和物理模型。

(三)数据库定义和数据安全性与完整性定义

定义数据库、基本表、视图和安全性、完整性约束的要求。

(四)应用程序设计和程序调试

设计并编写输入/输出、查询/统计、数据维护等功能模块的应用程序，要求至少使用表、视图、索引的创建命令，表中数据的增、删、改、查询的命令，存储过程的创建和使用命令，触发器的创建和使用命令。

(五)撰写课程设计报告

对系统的各个功能模块进行集成、总调试，撰写课程设计报告。

课程设计安排：

三人为一组，每组一个课题，每组设组长一名，负责该组设计工作的协调、分工等，小组成员分工需明确，确保每个成员都有一定的任务量。课程设计建议持续一周（7天），具体日程安排如表5.1所示。

考核形式：

通过程序实现、总结报告和学习态度，并结合学生的动手能力，独立分析解决问题的能力和创新精神综合考评。考核方式采用平时检查、程序检查和课程设计报告检查结合的办法。成绩分优、良、中、及格和不及格五等。

考核标准包括：

1、程序代码（50%）

2、学生的工作态度、动手能力、创新精神及出勤率（30%）

3、课程设计报告（20%）

5.2参考选题及功能要求

1.机票预定信息系统

系统功能的基本要求：

航班基本信息，包括航班的编号、飞机名称、机舱等级等；机票信息，包括票价、折扣、当前预售状态及经手业务员等；客户基本信息，包括姓名、联系方式、证件及号码、付款情况等。需实现基本信息的录入、修改和删除，需按照一定条件查询、统计符合条件的航班、机票等信息，实现机票的预订、退订功能。

2.长途汽车信息管理系统

系统功能的基本要求：

线路信息，包括出发地、目的地、出发时间、所需时间等；汽车信息，包括汽车的种类及相应的票价、最大载客量等；票价信息，包括售票情况、查询、打印相应的信息。需实现基本信息的录入、修改和删除，需按照一定条件查询、统计符合条件的汽车及车票等信息，实现车票的预订、退订功能。

3.人事信息管理系统

系统功能基本要求：

员工各种信息，包括员工的基本信息，如编号、姓名、性别、学历、所属部门、毕业院校、健康情况、职称、职务、奖惩等。需实现员工各种信息的录入、修改；对转出、辞退、退休员工信息的删除；需按照一定条件查询、统计符合条件的员工信息。

4.超市会员管理系统

系统功能的基本要求：

会员的基本信息，包括姓名、性别、年龄、工作单位、联系方式等；加入会员的基本信息，包括成为会员的基本条件、优惠政策、优惠时间等；会员购物信息，包括购买物品编号、物品名称、所属种类，数量，价格等；会员返利信息，包括会员积分的情况，享受优惠的等级等。需实现基本信息的录入、修改和删除；能按照一定条件查询符合条件的会员信息；需对货物流量及消费人群进行统计输出。

5.客房管理系统

系统功能的基本要求：

客房各种信息，包括客房的类别、当前的状态、负责人等；客房信息的查询和修改，包括按房间号查询住宿情况、按客户信息查询房间状态等。需要实现退房、订房、换房等信息的修改。对查询、统计结果打印输出。

6.药品存销信息管理系统

系统功能基本要求：

药品信息，包括药品编号、药品名称、生产厂家、生产日期、保质期、用途、价格、数量、经手人等；员工信息，包括员工编号、姓名、性别、年龄、学历、职务等；客户信息，包括客户编号、姓名、联系方式、购买时间、购买药品编号、名称、数量等；入库和出库信息，包括当前库存信息、药品存放位置、入库数量和出库数量等。需实现基本信息的录入、修改和删除；需按照一定条件查询、统计符合条件的药品、客户、入库、出库的信息。

7.学生选课管理信息系统

系统功能基本要求：

教师信息，包括教师编号、教师姓名、性别、年龄、学历、职称、毕业院校，健康状况等；学生信息，包括学号、姓名、所属院系、已选课情况等；教室信息，包括可容纳人数、空闲时间等；选课信息，包括课程编号、课程名称、任课教师、选课的学生情况等；成绩信息，包括课程编号、课程名称、学分、成绩。需实现基本信息的录入、修改和删除；需按照一定条件查询，统计学生的选课情况、成绩情况、教师情况和教室情况。

8.图书管理系统

系统功能基本要求：

图书信息，包括图书编号、图书名称、所属类别等；读者信息，包括读者编码、姓名、性别、专业等；借还书信息，包括图书当前状态、被借还次数、借阅时间等。需实现基本信息的录入、修改和删除；需按照一定条件查询，统计图书信息、读者信息和借还书信息。能实现借书、还书功能。

9.学生成绩管理系统

系统功能基本要求：

学生信息，学号、姓名、性别、专业、年级等；学生成绩信息，包括学号、课程编号、课程名称、分数等；课程信息，包括课程编号、课程名称、任课教师等。需实现基本信息的录入、修改和删除；需按照一定条件查询，统计学生成绩，但不能任意修改成绩。

10.网上书店管理信息

系统功能基本要求：

书籍信息，包括图书编号、图书种类、图书名称、单价、内容简介等；购书者信息，包括购买编号、姓名、性别、年龄、联系方式购买书的名称等；购买方式，包括付款方式、发货手段等。需实现基本信息的录入、修改和删除；根据读者信息查询购书情况、书店的销售情况。

11.教室管理信息系统

系统功能基本要求：

教室信息，包括教室容纳人数、教室空闲时间、教室设备等；教师信息，包括教师姓名、教授课程、教师职称、安排上课时间等；教室安排信息，包括何时空闲、空闲的开始时间、结束时间等。需实现基本信息的录入、修改和删除；需按照一定条件查询，统计教室使用情况。

12论坛管理信息系统

系统功能基本要求;

作者信息，包括作者昵称、性别、年龄、职业、爱好等；贴子信息，包括贴子编号、发贴日期、时间、等级等；回复信息，包括回复作者昵称、回复时间等。需实现基本信息的录入、修改和删除；需按照一定条件查询，统计作者信息、帖子情况和回复情况。

13.职工考勤管理信息系统

系统功能基本要求:

职工信息，包括职工编号、职工姓名、性别、年龄、职称等；出勤记录信息，包括上班打卡时间，下班打卡时间，缺勤记录等；出差信息，包括出差起始时间、结束时间、统计总

共天数等；请假信息，包括请假开始时间，结束时间，统计请假天数等；加班信息，包括加班开始时间、结束时间、统计加班总时间。需实现基本信息的录入、修改和删除；需按照一定条件查询，统计职工的考勤情况和加班情况。

14.个人信息管理系统

系统功能基本要求:

通讯录信息，包括通讯人姓名、联系方式、工作地点、城市、备注等；备忘录信息，包括什么时间、事件、地点等；日记信息，包括时间、地点、事情、人物等；个人财物管理，包括总收入，消费项目、消费金额、消费时间、剩余资金等。需实现基本信息的录入、修改和删除；需按照一定条件查询，统计个人信息。

15. 办公室日常管理信息系统

系统功能基本要求:

文件管理信息，包括文件编号、文件种类、文件名称、存放位置等；考勤管理，包括姓名、年龄、职务、日期、出勤情况等；需查询员工的出勤情况。会议记录，包括会议时间、参会人、记录员、会议内容等；办公室日常事务管理，包括时间、事务、记录人。需按条件查询，统计。

16.轿车销售信息管理系统

系统功能基本要求:

轿车信息，包括轿车的编号、型号、颜色、生产厂家、出厂日期、价格等；员工信息，包括员工编号、姓名、性别、年龄、籍贯、学历等；客户信息，包括客户名称、联系方式、地址、业务联系记录等；轿车销售信息，包括销售日期、轿车类型、颜色、数量、经手人等。需实现基本信息的录入、修改和删除；需按条件查询，统计销售情况。

17.高校学生宿舍管理系统

系统功能基本要求:

宿舍楼信息，包括楼号，层数，寝室数等；学生信息，包括学号、姓名、性别、院系、班级、所在宿舍号等；宿舍信息，包括宿舍号，所在楼号，所在层数，床位数，实际人数等；宿舍事故信息，包括宿舍号，事故原因，事故时间，是否解决等。需实现宿舍信息的添加、修改、删除及查询；学生信息的添加、修改、删除及查询；宿舍备品及事故的查询等功能。

18.员工工资管理系统

系统功能基本要求:

员工基本信息，包括员工号，员工名，性别，出生日期，职称，职务等；员工考勤信息，包括员工号，迟到，早退，旷工，请假等；员工工种信息，包括员工的工种、等级，基本工资等信息；员工津贴信息，包括员工的加班时间，加班类别、加班天数、津贴情况等；员工月工资，包括员工号，基本工资，津贴，扣款，应发工资，实发工资等。要求能够设定员工每个工种的基本工资；管理加班津贴，根据加班时间和类型给予不同的加班津贴；按照不同工种的基本工资情况、员工的考勤情况产生员工的每月的月工资；生成员工的年终奖金，员工的年终奖金计算公式＝（员工本年度的工资总和＋津贴的总和）/12；生成企业工资报表。能够查询单个员工的工资情况、每个部门的工资情况、按月的工资统计；

5.3实验报告要求

1．封面（含实验课程名称、专业、班级、小组成员的学号及姓名、指导教师及职称、开课学期、完成时间）；

2．设计题目；

3．实验目的；

4．软硬件环境；

5．实验设计简述（简要说明设计题目的基本情况）；

6．系统需求分析与功能设计（根据课题的要求进行简单的需求分析，设计相应的数据流图，得出相应的系统功能需要，系统数据流图）；

7．概念模型设计（按数据库设计方法和规范化理论，从实践概括抽象出ER模型）；

8．逻辑模型设计（按数据库设计方法和规范化理论得出符合3NF的逻辑模型，ER图设计，ER图转化为相应的关系模式，设计数据库的逻辑模型）；

9．物理模型设计（存储记录结构设计，物理文件的安排和建立索引）；

10．实现（数据库结构设计的程序代码，增、删、改、查等基本操作的程序代码）；

11．实验总结（主要对本实验开发过程进行归纳和总结，还应包括在设计过程中所遇到的技术难点及解决方法，尚存在的问题以及进一步开发的见解与建议。）；

12．参考文献。

13．系统功能基本要求：

5.4参考实例——交易中心管理系统

（一）实验目的

针对零件交易中心的实践调研，通过系统需求分析、数据库概念设计、逻辑设计到上机编程、调试和应用等全过程完成零件交易中心管理系统的后台数据库设计。

（二）实验设计简述

零件交易中心管理系统主要提供顾客和供应商之间完成零件交易的功能，其中包括供应商信息、顾客信息以及零件信息。此系统可以让供应商增加、删除和修改所提供的零件产品，还可以让顾客增加、删除和修改所需求的零件。交易员可以利用顾客提出的需求信息和供应商提出的供应信息来提出交易的建议，由供应商和顾客进行确认后即完成这笔交易。

（三）系统需求分析

l．供应商

供应商的操作流程图如图5-1所示。

图5-1 供应商操作分类表

2．顾客

顾客的地位和供应商几乎是对称的，所以功能分类上也很相似．顾客的操作流程图如图5-2所示。

图5-2 顾客操作分类表

3．交易员

交易员的工作就是提出交易和完成交易。这里需要仔细考虑的问题是：一个交易如何产生，并如何达成，可以用图5-3来说明这个问题。

在处理交易的时候可能面临如下问题：

(1)一个交易只能在交易双方都同意的情况下才可以进行，所以数据库中的供求信息只能作为达成某个交易的基础；

(2)交易的双方可能不同时使用这个系统，因此需要系统提供一个双方交换信息的方式；

(3)系统需要提供一种方便系统(交易员)向用户提出建议来促成交易的途径，并在保证数据库数据完整性的情况下达成交易。

图5-3 交易员操作图

（四）概念模型设计

数据库需要表述的信息有以下几种：

(1)零件信息

(2)供应商信息

(3)顾客信息

(4)供应商集和零件集之间的供应联系ER模型如图5-4所示。

图5-4供应商和零件之间的联系(供应) ER模型

(5)顾客集和零件集之间的求购联系ER图如图5-5所示。

图5-5

顾客和零件之间的联系(

求购) ER 模型

(6)交易(三元联系)

可以用E/R 模型表述该模型的设计，E/R 图如图5-6所示。

图5-6 全局ER 模型

（五）逻辑模型设计

通过ER 模型到关系模型的转化，可以得到如下关系模式：

(1)，Name ，Weight ，Intro) (2)Name ，Addtess ，Tel ，Intro) (3)Name ，Addtess ，Tel)

(4)Price ，Quantity)

(5)求购联系转换为关系OfferToBuy (CustomerlD ，PartID ，Price ，Quantity)

(6)Price ，Quantity) 每个关系模式的主键码都用下划线标出。

同时，对于从联系导出的关系Supply(供应)，OfferToBuy(求购)和Business(交易)，使用与之相联系的实体集的主键码作为自己的键码，必须符合外键码约束。

对于Customer(顾客)，Provider(供应商)和Part(零件)之间，不存在直接的约束，所以可以存在没有供应商供应同时也没有顾客求购的零件。

（六）物理模型设计 1．存储记录结构设计

表5.2 Part 表

其他表类似。

2．为了提高在表中搜索元组的速度，在实际实现的时候应该基于键码建立索引是各表中建立索引的表项：

(1)part(ID)

(2)Provider(ID)

(3)Customer(ID)

(4)Supply(PartID，ProviderID>

(5)OfferTOBuy(CustomerID，PartID)

(6)Business(CustomerlD，ProviderID，PartID)

（七）实现

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)

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_SUPPL Y PRIMARY KEY CLUSTERED(PartID,ProviderID),

CONSTRAINT FK_SUPPL Y_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,

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．供应商操作

(1)注册(register)

INSERT INTO Provider(Name，password，Address，TeI，Intro)

V ALUES(#Name，#password，#Address，#Tel，#Intro)

在登记操作后，供应商得到一个唯一的ID，可以根据这个ID采查询和修改供应商的数据。

(2)注销(unregister)

DELETE Provider WHERE(ID=#ID)；

(3)修改个人馆息(update)

UPdate Provider Set(Name=#Name,Address=#Address，Tel=#Tel，Intro=#Intro)

WHERE(ID＝#ID)；

(4)增加供应项(add_supply_item)

INSERT INTO Supply(PartID，Providerid，Price，Quantity)

V ALUES(#PartID，#ProvderlD，#Price；#Quantily)；

(5)删除供应项(delete_supply_item)

DELETE SupPly

WHERE(PartlD=#PartID AND ProvideID=#ProviderlD)；

(6)修改供应项(update_supply_item)

UPDATESupplySET(Price=#Price，Quantity=#Quantity)

WHERE(PartlD=#PartID AND ProviderID=#ProviderID)…

很明显，系统并没有提供面向供应商修改零件信息的接口，所以供应商提供的零件必须已经在零件表中存在；可以这祥假设，交易所的管理员负责更新零件信息，而供应商可以向交易所申请增加某种零件的信息．事实上顾客也可以提出这样的要求。

8．顾客操作

(1)注册(register)

INSERT INTO Customer(Name，Address，Tel)

V ALUES(#Name，#Address，#Tel)；

在登记操作后，顾客得到一个唯一的ID，可以根据这个ID来查询和修改顾客的数据．

(2)注销(unregister)

DELETE Customer

WHERE

(3)修改个人信息(update)

UPDATE Customer Set(Name=#Name，Address=#Address，Tel=#Tel)

WHERE(1D=#ID)；

(4)增加需求项(add_OfferToBuy_item)

INSERT INTO OfferToBuy(PartID,CustomeriD，Price，Quantity)

V ALUES(#PartID，#CustomerID，#Price，#Quantity)'

(5)删除需求项(delete_OfferToBuy_iterm)

DELETE OfferToBuy

WHERE(PartlD=#PartlD AND CustomerlD=#CustomerID)；

(6)修改需求项(叩date_OfferToBuy_item)

UPDATE OfferToBuy SET(Price=#Price，Quantity=#Quantity

WHERE(PartlD=#PartID AND CustomeriD=#CustomerID)

9．交易员

针对需求分析中提出的问题，我们提出了“协议书”的解决方案，方案的说明如下：

(1)每个交易在达成以前都作为协议书保存在数据库中，协议书具有和交易一样的完备信息，可以在条件成熟的情况下转为一个达成的交易；

(2)协议书只有在供应商和顾客都签字的情况下才有效；有效的协议书由交易员签发，协议书一经签发，就生效，表明一个交易的达成，数据库中的数据将同时予以修改；

(3)协议书可以由供应商、顾客或者交易员中的任意一个人提出申请。当协议书在双方没有都签字前，协议的双方或者交易员都可以删除这个协议书；但是，当协议书签字完毕后，协议书就不得删除(修改)，只能由交易员进行处理；

(4)协议书有可能在转成交易的过程中失败，因为在交易达成以前，数据库中的数据有可能因为其他交易而变化，一个协议书可能失效，这是允许的。

根据以上分析，对数据库的模型作一些修改，增加协议书表，其关系模式如下：

Agreement(CustomerlD，ProviderID，PartID，Price，Quantity，CustomerSign，ProviderSign)

对应的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))

与上述其他操作相比，对交易的操作对数据完整性要求比较高，其中需要注意的地方是：（1）要防止同一用户(供应商，顾客)的数据因两个交易而同时修改；

（2）需要同时对供应数据库(Supply)、需求数据库(OfferToBuy)、交易数据库(Business)

（3）和协议数据库(Agreement)作出修改，而且需要保持这些修改的原子性；

很显然，这些要求正是对于一个事务(transaction)的要求，所以可以用一个事务来完成签发一个协议的操作。事务的描述如下：

CREATE PROC PASS_AGREEMENT

@providerID int，

@customerid int，

@partlD int

AS

DECLARE @TransName V ARCHAR(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

INSERT INTO Business(ProviderID，CustomerID，PartID，Price，Quantity) V ALues(@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

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的语法，因此以上的数据库操作都是在SQLSERVER2012上测试通过的。

（八）实验数据示例：测试阶段

1．实验方案设计

（1）输入数据设计：

1）插入零件信息；

insert into Part(Color，Name，Weight，Intro)

values('black'，'stick'，'30'，'of steel')；

显示刚插人的零件id：

select id from Part where name='stick'；

id

----

1

(1 row(s) affected)

(不同的实验，id值可能不同。以后相应操作要保持前后一致就可以丁。)

2）插入供应商信息：

insert into Provider(Name，password，Address，Tel，Intro)

values('coml'，'1234'，'北京'，6543210，'nothing')；

显示刚插入的供应商id：

select id from Provider where name='coml'；

id

- -

1

(1 row(s) affected)

3）插入顾客信息：

insert into Customer(Name，Address，Tel)

values('cusl'，'北京'，'6666666')'

显示刚插入的顾客id：

select id from Customer where name

d

- -

1

(1 row(S)affected)

4）插入供应商供应信息：

insert into Supply(PartID，ProviderlD，Price，Quantity)

values(1，1，20，100)；

5）插入顾客需求信息：

insert into OfferToBuy(PartlD，CustomerID，Priee，Quantity)

values(1，1，20，50)；

6）插入协议信息：

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：

PASS_AGREEMENT 1，1，1;

(后面的三个参数分别对应前面选择出的供应商ID、顾客ID和零件ID。)

2）结果：显示交易后供应信息和需求信息：

select Quantity from Supply where PartlD＝1 and ProviderlD=1;

Quantity

- - -

70

(1 row(s) affected)

select Quantity from OfferToBuy where PartlD=l and CustomerID；

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）再次执行交易操作：

delete from Business；