数据库课程设计实例

数据库课程设计

题目：小型超市管理系统

1、项目计划

11系统开发目的

（1）大大提高超市的运作效率；

（2）通过全面的信息采集和处理，辅助提高超市的决策水平；

（3）使用本系统，可以迅速提升超市的管理水平，为降低经营成本， 提高效益，增强超市扩张力， 提供有效的技术保障。

12背景说明

21世纪，超市的竞争也进入到了一个全新的领域，竞争已不再是规模的竞争，而是技术的竞争、管理的竞争、人才的竞争。技术的提升和管理的升级是超市业的竞争核心。零售领域目前呈多元发展趋势，多种业态：超市、仓储店、便利店、特许加盟店、专卖店、货仓等相互并存。如何在激烈的竞争中扩大销售额、降低经营成本、扩大经营规模，成为超市营业者努力追求的目标。

13项目确立

针对超市的特点，为了帮助超市解决现在面临的问题，提高小型超市的竞争力，我们将开发以下系统：前台POS销售系统、后台管理系统，其中这两个子系统又包含其它一些子功能。

14应用范围

本系统适应于各种小型的超市。

15 定义

（1）商品条形码：每种商品具有唯一的条形码，对于某些价格一样的商品，可以使用自定义条形码。

（2）交易清单：包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号。

（3）商品积压：在一定时期内，远无法完成销售计划的商品会造成积压。

（4）促销：在一定时期内，某些商品会按低于原价的促销价格销售。

库存告警提示：当商品的库存数量低于库存报警数量时发出提示。

（5）盘点：计算出库存、销售额、盈利等经营指标。

16 参考资料

《数据库原理及设计》 陶宏才编 清华大学出版社

《SQL Server 2000 实用教程》范立南编 清华大学出版社

《SQL Server 2000 编程员指南》李香敏编 北京希望电子出版社

《轻松搞定 SQL Server 2000 程序设计》Rebecca MRiordan编

《软件工程规范》Watts SHumphrey编 清华大学出版社

《软件工程理论与实践》 Shari Lawrence Pfleeger编 清华大学出版社

《软件需求分析》 Swapna Kishore编 机械工业出版社

《软件工程思想》 林锐编

2、逻辑分析与详细分析

21系统功能

（1）、零售前台（POS）管理系统，本系统必须具有以下功能：

 商品录入：根据超巿业务特点制定相关功能，可以通过输入唯一编号、扫描条形码、商品名称等来实现精确或模糊的商品扫描录入。该扫描录入方法可以充分保证各种电脑 *** 作水平层次的人员均能准确快速地进行商品扫描录入。

 收银业务：通过扫描条形码或者直接输入商品名称（对于同类多件商品采用一次录入加数量的方式）自动计算本次交易的总金额。在顾客付款后，自动计算找零，同时打印交易清单（包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号）。如果顾客是本店会员并持有本人会员卡，则在交易前先扫描会员卡，并对所购物品全部实行95折优惠，并将所购物品的总金额累计到该会员的总消费金额中。 会员卡的有效期限为一年，满一年未续卡者，该会员卡将被注销。

 安全性：OS登陆、退出、换班与 *** 作锁定等权限验证保护；断电自动保护最大限度防止意外及恶意非法 *** 作。

 独立作业：有的断网收银即在网络服务器断开或网络不通的情况下，收银机仍能正常作业

(2)、后台管理系统，本系统必须具备以下功能

 进货管理： 根据销售情况及库存情况，自动制定进货计划（亦可手工制定修改），可以避免盲目进货造成商品积压。 按计划单有选择性地进行自动入库登记。 综合查询打印计划进货与入库记录及金额。

 销售管理： 商品正常销售、促销与限量、限期及禁止销售控制。 综合查询各种销售明细记录、各地收银员收银记录以及交结账情况等。 按多种方式统计生成销售排行榜，灵活察看和打印商品销售日、月、年报表。

 库存管理： 综合查询库存明细记录。 库存状态自动告警提示。如库存过剩、少货、缺货等。软件为您预警，避免库存商品积压损失和缺货。 库存自动盘点计算。

 人员管理： 员工、会员、供货商、厂商等基本信息登记管理。 员工 *** 作权限管理。 客户销售权限管理。

（3）系统结构

系统总体结构

模块子系统结构

功能描述：商品录入子系统要求能快速录入商品，因此必须支持条形码扫描。

功能描述：收银业务子系统能计算交易总额，打印交易清单，并根据会员卡打折。

功能描述：进货管理子系统可以根据库存自动指定进货计划，进货时自动等级，以及提供查询和打印计划进货与入库记录的功能。

功能描述：销售管理子系统可以控制某商品是否允许销售，查询每种商品的销售情况并产生年、月、日报表，同时可以生成销售排行榜。

功能描述：库存管理子系统提供查询库存明细记录的基本功能，并根据库存的状态报警，以及自动盘点计算。

功能描述：人员管理子系统提供基本信息登记管理，员工 *** 作权限管理，客户销售权限管理的功能。

22、流程图

前台管理系统

顶层DFD图

第0层DFD图

第1层DFD图

23、户类型与职能

（1）、员工（营业员）：

 通过商品条形码扫描输入商品到购买清单

 *** 作软件计算交易总金额

 *** 作软件输出交易清单

 对会员进行会员卡扫描以便打折

（2）、：超市经理

 *** 作软件录入商品，供货商，厂商

 *** 作软件制定进货计划

 查询打印计划进货与入库记录

 *** 作软件控制商品销售与否

 查询打印销售情况

 *** 作软件生成销售排行榜

 查询库存明细记录

 根据软件发出的库存告警进行入货

 *** 作软件进行盘点计算

（3）、总经理：

 基本信息登记管理

 员工 *** 作权限管理

 客户销售权限管理

24、统开发步骤

 确定参与者和相关的用况

 为每个用况设计过程

 建立顺序图，确定每个脚本中对象的协作

 创建类，确定脚本中的对象

 设计, 编码, 测试, 集成类

 为过程编写系统测试案例

 运行测试案例，检验系统

25、系统环境需求

 系统模式

本系统采用C/S模式作为开发模式

 硬件环境

服务器端：

高性能的计算机一台，

普通的双绞线作为连接。

客户端： 普通的计算机或者工作站，

普通的双绞线作为连接。

 软件环境

服务器端：安装SQL Server 2000的服务器版本，

安装windows 2000服务器版本，

配置了诺顿等必须的防毒软件。

客户端： 安装SQL Server2000的服务器版本，

安装了VB等可视化开发工具软件，

安装windows2000服务器版本。

26、系统安全问题

信息系统尽管功能强大，技术先进，但由于受到自身体系结构，设计思路以及运行机制等限制，也隐含许多不安全因素。常见因素有：数据的输入，输出，存取与备份，源程序以及应用软件，数据库， *** 作系统等漏洞或缺陷，硬件，通信部分的漏洞，企业内部人员的因素，病毒，“黑客”等因素。因此，为使本系统能够真正安全，可靠，稳定地工作，必须考虑如下问题：为保证安全，不致使系统遭到意外事故的损害，系统因该能防止火，盗或其他形式的人为破坏。

 系统要能重建

 系统应该是可审查的

 系统应能进行有效控制，抗干扰能力强

 系统使用者的使用权限是可识别的

3、基于UML的建模

31语义规则

用例模型（use cases view）（用例视图）的基本组成部件是用例（use case）、角色(actor)和系统(system)。用例用于描述系统的功能，也就是从外部用户的角度观察，系统应支持哪些功能，帮助分析人员理解系统的行为，它是对系统功能的宏观描述，一个完整的系统中通常包含若干个用例，每个用例具体说明应完成的功能，代表系统的所有基本功能（集）。角色是与系统进行交互的外部实体，它可以是系统用户，也可以是其它系统或硬件设备，总之，凡是需要与系统交互的任何东西都可以称作角色。系统的边界线以内的区域（即用例的活动区域）则抽象表示系统能够实现的所有基本功能。在一个基本功能（集）已经实现的系统中，系统运转的大致过程是：外部角色先初始化用例，然后用例执行其所代表的功能，执行完后用例便给角色返回一些值，这个值可以是角色需要的来自系统中的任何东西。

UML：是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示；它不是一种可视化的程序设计语言而是一种可视化的建模语言；不是工具或知识库的规格说明而是一种建模语言规格说明是一种表示的标准；不是过程也不是方法但允许任何一种过程和方法使用它。

用例（use case）：

参与者（actor）：

32、UML模型

321、系统UML模型

322、子系统UML模型

（1）零售前台（POS）管理系统用例视图

（2）后台管理系统用例视图

33、系统实现图

4、超市销售系统概念设计文档

（1）、系统ER图

（2）、系统ER图说明

1) 商店中的所有用户（员工）可以销售多种商品，每种商品可由不同用户（员工）销售；

2) 每个顾客可以购买多种商品，不同商品可由不同顾客购买；

3) 每个供货商可以供应多种不同商品，每种商品可由多个供应商供应。

（3）、视图设计

1) 交易视图(v_Dealing)——用于查询交易情况的视图；

2) 计划进货视图(v_PlanStock)——用于查询进货计划的视图；

3) 销售视图(v_Sale)——用于查询销售明细记录的视图；

4) 入库视图(v_Stock)——用于查询入库情况的视图。

5、逻辑设计文档

（1）、系统关系模型

a) 商品信息表（商品编号，商品名称，价格，条形码，促销价格，促销起日期，促销止日期，允许打折，库存数量，库存报警数量，计划进货数，允许销售，厂商编号，供货商编号）

b) 用户表（用户编号，用户名称，用户密码，用户类型）

c) 会员表（会员编号，会员卡号，累积消费金额，注册日期）

d) 销售表（销售编号，商品编号，销售数量，销售金额，销售日期）

e) 交易表（交易编号，用户名称，交易金额，会员卡号，交易日期）

f) 进货入库表（入库编号，入库商品编号，入库数量，单额，总额，入库日期，计划进货日期，入库状态）

g) 供货商表（供货商编号，供货商名称，供货商地址，供货商电话）

h) 厂商表（厂商编号，厂商名称，厂商地址，厂商电话）

（2）、系统数据库表结构

数据库表索引

表名 中文名

MerchInfo 商品信息表

User 用户表

Menber 会员表

Sale 销售表

Dealing 交易表

Stock 进货入库表

Provide 供货商表

Factory 厂商表

商品信息表(MerchInfo)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

MerchID int 4 P Not null 商品编号

MerchName Varchar 50 Not null 商品名称

MerchPrice Money 4 Not null 价格

MerchNum Int 4 Not null 库存数量

CautionNum Int 4 Not null 库存报警数量

PlanNum Int 4 null 计划进货数

BarCode Varchar 50 Not null 条形码

SalesProPrice Money 4 促销价格

SalesProDateS Datetime 8 促销起日期

SalesProDateE Datetime 8 促销止日期

AllowAbate Int 4 Not null 允许打折

AllowSale Int 4 Not null 允许销售

FactoryID Varchar 10 F Not null 厂商编号

ProvideID Varchar 10 F Not null 供货商编号

用户表(User)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

UserID varchar 10 P Not null 用户编号

UserName Varchar 25 Not null 用户名称

UserPW Varchar 50 Not null 用户密码

UserStyle Int 4 Not null 用户类型

会员表(Menber)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

MemberID Varchar 10 P Not null 会员编号

MemberCard Varchar 20 Not null 会员卡号

TotalCost Money 4 Not null 累积消费金额

RegDate Datetime 8 Not null 注册日期

销售表(Sale)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

SaleID Varchar 10 P Not null 销售编号

MerChID Varchar 10 F Not null 商品编号

SaleDate Datetime 8 Not null 销售日期

SaleNum Int 4 Not null 销售数量

SalePrice Money 4 Not null 销售单额

交易表(Dealing)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

DealingID Varchar 10 P Not null 交易编号

DealingPrice Money 4 Not null 交易金额

DealingDate Money 4 Not null 交易日期

MemberID Varchar 10 会员卡号

UserName Varchar 10 F Not null 用户名称

入库纪录表(Stock)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

StockID Varchar 10 P Not null 入库编号

MerchID Varchar 10 F Not null 入库商品编号

MerchNum Int 4 Not null 入库数量

MerchPrice Money 4 Not null 单额

TotalPrice Money 4 Not null 总额

StockDate Datetime 8 Datetime 入库日期

PlanDate Datetime 8 Datetime 计划进货日期

StockState Int 4 Not null 入库状态

供货商表(Provide)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

ProvideID varchar 10 P Not null 供货商编号

ProvideName Varchar 50 Not null 供货商名称

ProvideAddress Varchar 250 供货商地址

ProvidePhone Varchar 25 供货商电话

厂商表(Provide)

字段名 字段类型 长度 主/外键 字段值约束 对应中文名

FactoryID varchar 10 P Not null 厂商编号

FactoryName Varchar 50 Not null 厂商名称

FactoryAddress Varchar 250 厂商地址

FactoryPhone Varchar 25 厂商电话

6、物理设计文档

/----------创建数据库----------/

create database SuperMarketdb

on primary

(

name=SuperMarketdb,

filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdbmdf',

size=100MB,

maxsize=200MB,

filegrowth=20MB

)

log on

(

name=SuperMarketlog,

filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdbldf',

size=60MB,

maxsize=200MB,

filegrowth=20MB

)

go

/----------创建基本表----------/

use [SuperMarketdb]

go

/创建交易表/

CREATE TABLE Dealing (

DealingID int identity(1,1) Primary key ,

DealingDate datetime NOT NULL ,

DealingPrice money NOT NULL ,

UserName varchar(25) NULL ,

MemberCard varchar(20) NULL

)

GO

/创建厂商表/

CREATE TABLE Factory (

FactoryID varchar(10) Primary key ,

FactoryName varchar(50) NOT NULL ,

FactoryAddress varchar(250) NULL ,

FactoryPhone varchar(50) NULL

)

GO

/创建会员表/

CREATE TABLE Member (

MemberID varchar(10) Primary key ,

MemberCard varchar(20) NOT NULL ,

TotalCost money NOT NULL ,

RegDate datetime NOT NULL

)

GO

/创建商品信息表/

CREATE TABLE MerchInfo (

MerchID int identity(1,1) Primary key ,

MerchName varchar(50) Unique NOT NULL ,

MerchPrice money NOT NULL ,

MerchNum int NOT NULL ,

CautionNum int NOT NULL ,

PlanNum int NOT NULL ,

BarCode varchar(20) Unique NOT NULL ,

SalesProPrice money NULL ,

SalesProDateS datetime NULL ,

SalesProDateE datetime NULL ,

AllowAbate int NOT NULL ,

AllowSale int NOT NULL ,

FactoryID int NOT NULL ,

ProvideID int NOT NULL

)

GO

/创建供应商表/

CREATE TABLE Provide (

ProvideID varchar(10) Primary key ,

ProvideName varchar(50) NOT NULL ,

ProvideAddress varchar(250) NULL ,

ProvidePhone varchar(25) NULL

)

GO

/创建销售表/

CREATE TABLE Sale (

SaleID int identity(1,1) Primary key ,

MerChID int NOT NULL ,

SaleDate datetime NOT NULL ,

SaleNum int NOT NULL,

SalePrice money NOT NULL

)

GO

/创建入库表/

CREATE TABLE Stock (

StockID int identity(1,1) Primary key ,

MerchID int NOT NULL ,

MerchNum int NOT NULL ,

MerchPrice money NULL ,

TotalPrice money NULL ,

PlanDate datetime NULL ,

StockDate datetime NULL,

StockState int NOT NULL

)

GO

/创建用户表/

CREATE TABLE User (

UserID varchar(10) Primary key ,

UserName varchar(25) NOT NULL ,

UserPW varchar(50) NOT NULL ,

UserStyle int NOT NULL ,

)

GO

/----------创建表间约束----------/

/商品信息表中厂商编号、供应商编号分别与厂商表、供应商表之间的外键约束/

ALTER TABLE MerchInfo ADD

CONSTRAINT [FK_MerchInfo_Factory] FOREIGN KEY

(

[FactoryID]

) REFERENCES Factory (

[FactoryID]

),

CONSTRAINT [FK_MerchInfo_Provide] FOREIGN KEY

(

[ProvideID]

) REFERENCES Provide (

[ProvideID]

)

GO

/销售表中商品编号与商品信息表之间的外键约束/

ALTER TABLE Sale ADD

CONSTRAINT [FK_Sale_MerchInfo] FOREIGN KEY

(

[MerChID]

) REFERENCES MerchInfo (

[MerchID]

) ON DELETE CASCADE

GO

/入库表中商品编号与商品信息表之间的外键约束/

ALTER TABLE Stock ADD

CONSTRAINT [FK_Stock_MerchInfo] FOREIGN KEY

(

[MerchID]

) REFERENCES MerchInfo (

[MerchID]

) ON DELETE CASCADE

GO

/----------创建索引----------/

/在交易表上建立一个以交易编号、交易日期为索引项的非聚集索引/

CREATE nonclustered INDEX IX_Dealing ON Dealing(DealingID, DealingDate)

GO

/在商品信息表上建立一个以商品编号为索引项的非聚集索引/

CREATE nonclustered INDEX IX_MerchInfo ON MerchInfo(MerchID)

GO

/在销售表上建立一个以销售编号、销售日期为索引项的非聚集索引/

CREATE nonclustered INDEX IX_Sale ON Sale(SaleID, SaleDate)

GO

/在入库表上建立一个以入库编号、入库日期、商品编号为索引项的非聚集索引/

CREATE nonclustered INDEX IX_Stock ON Stock(StockID, StockDate, MerchID)

GO

/----------创建视图----------/

/创建用于查询交易情况的视图/

CREATE VIEW v_Dealing

AS

SELECT DealingDate as 交易日期,

UserName as 员工名称,

MemberCard as 会员卡号,

DealingPrice as 交易金额

FROM Dealing

GO

/创建用于查询进货计划的视图/

CREATE VIEW v_PlanStock

AS

SELECT StockStockID as SID,

MerchInfoMerchName as 商品名称,

MerchInfoBarCode as 条形码,

FactoryFactoryName as 厂商,

ProvideProvideName as 供货商,

StockMerchNum as 计划进货数量,

StockPlanDate as 计划进货日期

FROM Stock,MerchInfo,Provide,Factory

Where StockMerchID = MerchInfoMerchID

and ProvideProvideID=MerchInfoProvideID

and FactoryFactoryID=MerchInfoFactoryID

and StockStockState=0

GO

/创建用于查询销售明细记录的视图/

CREATE VIEW v_Sale

AS

SELECT MerchInfoMerchName as 商品名称,

MerchInfoBarCode as 条形码,

MerchInfoMerchPrice as 商品价格,

SaleSalePrice as 销售价格,

SaleSaleNum as 销售数量,

SaleSaleDate as 销售日期

FROM Sale INNER JOIN

MerchInfo ON SaleMerChID = MerchInfoMerchID

GO

/创建用于查询入库情况的视图/

CREATE VIEW v_Stock

AS

SELECT MerchInfoMerchName as 商品名称,

MerchInfoBarCode as 条形码,

FactoryFactoryName as 厂商,

ProvideProvideName as 供货商,

StockMerchPrice as 入库价格,

StockMerchNum as 入库数量,

StockTotalPrice as 入库总额,

StockStockDate as 入库日期

FROM Stock,MerchInfo,Provide,Factory

Where StockMerchID = MerchInfoMerchID

and ProvideProvideID=MerchInfoProvideID

and FactoryFactoryID=MerchInfoFactoryID

and StockStockState=1

GO

7、小结

和传统管理模式相比较，使用本系统，毫无疑问会大大提高超市的运作效率，辅助提高超市的决策水平，管理水平，为降低经营成本， 提高效益，减少差错，节省人力，减少顾客购物时间，增加客流量，提高顾客满意度，增强超市扩张能力， 提供有效的技术保障。

由于开发者能力有限，加上时间仓促，本系统难免会出现一些不足之处，例如：

 本系统只适合小型超市使用，不能适合中大型超市使用；

 超市管理系统涉及范围宽，要解决的问题多，功能复杂，实现困难，但由于限于时间，本系统只能做出其中的一部分功能；

对于以上出现的问题，我们深表歉意，如发现还有其它问题，希望老师批评指正。

一个好的数据库产品不等于就有一个好的应用系统 如果不能设计一个合理的数据库模型 不仅会增加客户端和服务器段程序的编程和维护的难度 而且将会影响系统实际运行的性能 一般来讲 在一个MIS系统分析 设计 测试和试运行阶段 因为数据量较小 设计人员和测试人员往往只注意到功能的实现 而很难注意到性能的薄弱之处 等到系统投入实际运行一段时间后 才发现系统的性能在降低 这时再来考虑提高系统性能则要花费更多的人力物力 而整个系统也不可避免的形成了一个打补丁工程 笔者依据多年来设计和使用数据库的经验 提出以下一些设计准则 供同仁们参考

命名的规范

不同的数据库产品对对象的命名有不同的要求 因此 数据库中的各种对象的命名 后台程序的代码编写应采用大小写敏感的形式 各种对象命名长度不要超过 个字符 这样便于应用系统适应不同的数据库

游标（Cursor）的慎用

游标提供了对特定集合中逐行扫描的手段 一般使用游标逐行遍历数据 根据取出的数据不同条件进行不同的 *** 作 尤其对多表和大表定义的游标（大的数据集合）循环很容易使程序进入一个漫长的等特甚至死机 笔者在某市《住房公积金管理系统》进行日终帐户滚积数计息处理时 对一个 万个帐户的游标处理导致程序进入了一个无限期的等特（后经测算需 个小时才能完成）(硬件环境 Alpha/ Mram Sco Unix Sybase ) 后根据不同的条件改成用不同的UPDATE语句得以在二十分钟之内完成 示例如下

Declare Mycursor cursor for select  count_no from COUNT

Open Mycursor

Fetch Mycursor into @vcount_no

While (@@sqlstatus= )

Begin

If  @vcount_no=   条件

*** 作

If  @vcount_no=   条件

*** 作

Fetch Mycursor into @vcount_no

End

改为

Update COUNT set  *** 作 for 条件

Update COUNT set  *** 作 for 条件

在有些场合 有时也非得使用游标 此时也可考虑将符合条件的数据行转入临时表中 再对临时表定义游标进行 *** 作 可时性能得到明显提高 笔者在某地市〈电信收费系统〉数据库后台程序设计中 对一个表（ 万行中符合条件的 多行数据）进行游标 *** 作(硬件环境 PC服务器 PII Mram NT Ms Sqlserver ) 示例如下

Create #tmp   / 定义临时表 /

(字段

字段

)

Insert into #tmp select from TOTAL where

条件  / TOTAL中 万行 符合条件只有几十行 /

Declare Mycursor cursor for select from #tmp

/对临时表定义游标/

索引(Index)的使用原则

创建索引一般有以下两个目的 维护被索引列的唯一性和提供快速访问表中数据的策略 大型数据库有两种索引即簇索引和非簇索引 一个没有簇索引的表是按堆结构存储数据 所有的数据均添加在表的尾部 而建立了簇索引的表 其数据在物理上会按照簇索引键的顺序存储 一个表只允许有一个簇索引 因此 根据B树结构 可以理解添加任何一种索引均能提高按索引列查询的速度 但会降低插入 更新 删除 *** 作的性能 尤其是当填充因子（Fill Factor）较大时 所以对索引较多的表进行频繁的插入 更新 删除 *** 作 建表和索引时因设置较小的填充因子 以便在各数据页中留下较多的自由空间 减少页分割及重新组织的工作

数据的一致性和完整性

为了保证数据库的一致性和完整性 设计人员往往会设计过多的表间关联（Relation） 尽可能的降低数据的冗余 表间关联是一种强制性措施 建立后 对父表（Parent Table）和子表(Child Table)的插入 更新 删除 *** 作均要占用系统的开销 另外 最好不要用Identify 属性字段作为主键与子表关联 如果数据冗余低 数据的完整性容易得到保证 但增加了表间连接查询的 *** 作 为了提高系统的响应时间 合理的数据冗余也是必要的 使用规则（Rule）和约束（Check）来防止系统 *** 作人员误输入造成数据的错误是设计人员的另一种常用手段 但是 不必要的规则和约束也会占用系统的不必要开销 需要注意的是 约束对数据的有效性验证要比规则快 所有这些 设计人员在设计阶段应根据系统 *** 作的类型 频度加以均衡考虑

事务的陷阱

事务是在一次性完成的一组 *** 作 虽然这些 *** 作是单个的 *** 作 SQL Server能够保证这组 *** 作要么全部都完成 要么一点都不做 正是大型数据库的这一特性 使得数据的完整性得到了极大的保证

众所周知 SQL Server为每个独立的SQL语句都提供了隐含的事务控制 使得每个DML的数据 *** 作得以完整提交或回滚 但是SQL Server还提供了显式事务控制语句

BEGIN TRANSACTION 开始一个事务

MIT TRANSACTION 提交一个事务

ROLLBACK TRANSACTION 回滚一个事务

事务可以嵌套 可以通过全局变量@@trancount检索到连接的事务处理嵌套层次 需要加以特别注意并且极容易使编程人员犯错误的是 每个显示或隐含的事物开始都使得该变量加 每个事务的提交使该变量减 每个事务的回滚都会使得该变量置 而只有当该变量为 时的事务提交（最后一个提交语句时） 这时才把物理数据写入磁盘

数据库性能调整

在计算机硬件配置和网络设计确定的情况下 影响到应用系统性能的因素不外乎为数据库性能和客户端程序设计 而大多数数据库设计员采用两步法进行数据库设计 首先进行逻辑设计 而后进行物理设计 数据库逻辑设计去除了所有冗余数据 提高了数据吞吐速度 保证了数据的完整性 清楚地表达数据元素之间的关系 而对于多表之间的关联查询（尤其是大数据表）时 其性能将会降低 同时也提高了客 户端程序的编程难度 因此 物理设计需折衷考虑 根据业务规则 确定对关联表的数据量大小 数据项的访问频度 对此类数据表频繁的关联查询应适当提高数据冗余设计

数据类型的选择

数据类型的合理选择对于数据库的性能和 *** 作具有很大的影响 有关这方面的书籍也有不少的阐述 这里主要介绍几点经验

Identify字段不要作为表的主键与其它表关联 这将会影响到该表的数据迁移

Text 和Image字段属指针型数据 主要用来存放二进制大型对象（BLOB） 这类数据的 *** 作相比其它数据类型较慢 因此要避开使用

日期型字段的优点是有众多的日期函数支持 因此 在日期的大小比较 加减 *** 作上非常简单 但是 在按照日期作为条件的查询 *** 作也要用函数 相比其它数据类型速度上就慢许多 因为用函数作为查询的条件时 服务器无法用先进的性能策略来优化查询而只能进行表扫描遍历每行

例如 要从DATA_TAB 中（其中有一个名为DATE的日期字段）查询 年的所有记录

lishixinzhi/Article/program/Oracle/201311/17929

答：（1）需求分析阶段：需求收集和分析，得到数据字典和数据流图。 （2）概念结构设计阶段：对用户需求综合、归纳与抽象，形成概念模型，用E-R图表示。（3）逻辑结构设计阶段：将概念结构转换为某个DBMS所支持的数据模型。（4）数据库物理设计阶段：为逻辑数据模型选取一个最适合应用环境的物理结构。（5）数据库实施阶段：建立数据库，编制与调试应用程序，组织数据入库，程序试运行。（6）数据库运行和维护阶段：对数据库系统进行评价、调整与修改。

随着计算机技术越来越广泛地应用于国民经济的各个领域 在计算机硬件不断微型化的同时 应用系统向着复杂化 大型化的方向发展 数据库是整个系统的核心 它的设计直接关系系统执行的效率和系统的稳定性 因此在软件系统开发中 数据库设计应遵循必要的数据库范式理论 以减少冗余 保证数据的完整性与正确性 只有在合适的数据库产品上设计出合理的数据库模型 才能降低整个系统的编程和维护难度 提高系统的实际运行效率 虽然对于小项目或中等规模的项目开发人员可以很容易地利用范式理论设计出一套符合要求的数据库 但对于一个包含大型数据库的软件项目 就必须有一套完整的设计原则与技巧

一 成立数据小组

大型数据库数据元素多 在设计上有必要成立专门的数据小组 由于数据库设计者不一定是使用者 对系统设计中的数据元素不可能考虑周全 数据库设计出来后 往往难以找到所需的库表 因此数据小组最好由熟悉业务的项目骨干组成

数据小组的职能并非是设计数据库 而是通过需求分析 在参考其他相似系统的基础上 提取系统的基本数据元素 担负对数据库的审核 审核内容包括审核新的数据库元素是否完全 能否实现全部业务需求 对旧数据库（如果存在旧系统）的分析及数据转换 数据库设计的审核 控制及必要调整

二 设计原则

规范命名 所有的库名 表名 域名必须遵循统一的命名规则 并进行必要说明 以方便设计 维护 查询

控制字段的引用 在设计时 可以选择适当的数据库设计管理工具 以方便开发人员的分布式设计和数据小组的集中审核管理 采用统一的命名规则 如果设计的字段已经存在 可直接引用 否则 应重新设计

库表重复控制 在设计过程中 如果发现大部分字段都已存在 开发人员应怀疑所设计的库表是否已存在 通过对字段所在库表及相应设计人员的查询 可以确认库表是否确实重复

并发控制 设计中应进行并发控制 即对于同一个库表 在同一时间只有一个人有控制权 其他人只能进行查询

必要的讨论 数据库设计完成后 数据小组应与相关人员进行讨论 通过讨论来熟悉数据库 从而对设计中存在的问题进行控制或从中获取数据库设计的必要信息

数据小组的审核 库表的定版 修改最终都要通过数据小组的审核 以保证符合必要的要求

头文件处理 每次数据修改后 数据小组要对相应的头文件进行修改（可由管理软件自动完成） 并通知相关的开发人员 以便进行相应的程序修改

三 设计技巧

分类拆分数据量大的表 对于经常使用的表（如某些参数表或代码对照表） 由于其使用频率很高 要尽量减少表中的记录数量 例如 银行的户主账表原来设计成一张表 虽然可以方便程序的设计与维护 但经过分析发现 由于数据量太大 会影响数据的迅速定位 如果将户主账表分别设计为活期户主账 定期户主账及对公户主账等 则可以大大提高查询效率

索引设计 对于大的数据库表 合理的索引能够提高整个数据库的 *** 作效率 在索引设计中 索引字段应挑选重复值较少的字段 在对建有复合索引的字段进行检索时 应注意按照复合索引字段建立的顺序进行 例如 如果对一个 万多条记录的流水表以日期和流水号为序建立复合索引 由于在该表中日期的重复值接近整个表的记录数 用流水号进行查询所用的时间接近 秒 而如果以流水号为索引字段建立索引进行相同的查询 所用时间不到 秒 因此在大型数据库设计中 只有进行合理的索引字段选择 才能有效提高整个数据库的 *** 作效率

数据 *** 作的优化 在大型数据库中 如何提高数据 *** 作效率值得关注 例如 每在数据库流水表中增加一笔业务 就必须从流水控制表中取出流水号 并将其流水号的数值加一 正常情况下 单笔 *** 作的反应速度尚属正常 但当用它进行批量业务处理时 速度会明显减慢 经过分析发现 每次对流水控制表中的流水号数值加一时都要锁定该表 而该表却是整个系统 *** 作的核心 有可能在 *** 作时被其他进程锁定 因而使整个事务 *** 作速度变慢 对这一问题的解决的办法是 根据批量业务的总笔数批量申请流水号 并对流水控制表进行一次更新 即可提高批量业务处理的速度 另一个例子是对插表的优化 对于大批量的业务处理 如果在插入数据库表时用普通的Insert语句 速度会很慢 其原因在于 每次插表都要进行一次I/O *** 作 花费较长的时间 改进后 可以用Put语句等缓冲区形式等满页后再进行I/O *** 作 从而提高效率 对大的数据库表进行删除时 一般会直接用Delete语句 这个语句虽然可以进行小表 *** 作 但对大表却会因带来大事务而导致删除速度很慢甚至失败 解决的方法是去掉事务 但更有效的办法是先进行Drop *** 作再进行重建

数据库参数的调整 数据库参数的调整是一个经验不断积累的过程 应由有经验的系统管理员完成 以Informix数据库为例 记录锁的数目太少会造成锁表的失败 逻辑日志的文件数目太少会造成插入大表失败等 这些问题都应根据实际情况进行必要的调整

必要的工具 在整个数据库的开发与设计过程中 可以先开发一些小的应用工具 如自动生成库表的头文件 插入数据的初始化 数据插入的函数封装 错误跟踪或自动显示等 以此提高数据库的设计与开发效率

避免长事务 对单个大表的删除或插入 *** 作会带来大事务 解决的办法是对参数进行调整 也可以在插入时对文件进行分割 对于一个由一系列小事务顺序 *** 作共同构成的长事务（如银行交易系统的日终交易） 可以由一系列 *** 作完成整个事务 但其缺点是有可能因整个事务太大而使不能完成 或者 由于偶然的意外而使事务重做所需的时间太长 较好的解决方法是 把整个事务分解成几个较小的事务 再由应用程序控制整个系统的流程 这样 如果其中某个事务不成功 则只需重做该事务 因而既可节约时间 又可避免长事务

适当超前 计算机技术发展日新月异 数据库的设计必须具有一定前瞻性 不但要满足当前的应用要求 还要考虑未来的业务发展 同时必须有利于扩展或增加应用系统的处理功能

lishixinzhi/Article/program/SQL/201311/16498

设计一个数据库需要我们耐心收集和分析数据，仔细理清数据间的关系，消除对数据库应用不利的隐患等等。在整个设计过程中，我们必须按步骤认真完成。一个数据库的设计好坏将直接影响将来基于该数据库的应用。

另外，数据库也不是独立存在的，它总是与具体的应用相关的，为具体的应用而建立的。因此在设计数据库之前我们必须明确应用的目的，在设计数据库的时候也应时刻考虑用户需求，数据库与具体应用之间是相辅相成的关系。

数据库的设计过程一般包括以下几个步骤：

确定建立数据库的目的和收集数据；

建立概念模型；

建立数据模型；

实施与维护数据库；

1．确定建立数据库的目的和收集数据

数据库设计过程的第一个阶段是确定建立数据库的目的和收集数据。通常，我们也把确定建立数据库的目的称为需求分析。需求分析的任务就是通过详细调查要处理的对象来明确用户的各种需求。并且通过调查、收集和分析信息，以了解在数据库中需要存储哪些数据，要完成什么样的数据处理功能。这一过程是数据库设计的起点，它将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。

确定目的之后就需要根据目的收集有用的数据。在着手收集数据之前最重要的就是要调查用户的实际需求，然后分析与表达这些需求。调查用户需求的方法有很多，如查阅记录、访谈、开调查会、设计调查表请用户填写或回答相关问题等。其中比较有效的方法是访谈，我们可以借助一些设计合理的调查表来与用户直接交流。通过充分交流，可以了解他们平时是如何使用数据库的，以及对当前信息的要求，进而设计满足用户需求的字段，并根据设计的字段收集数据。

2．建立概念模型

确定建立数据库的目的以及完成数据收集后，就进入数据库设计过程的第二阶段——建立概念模型。这一阶段是整个数据库设计的关键。设计时，一般先根据应用的需求，画出能反映每个应用需求的E-R图，其中包括确定实体、属性和联系的类型。然后优化初始的E-R图，消除冗余和可能存在的矛盾。概念模型是对用户需求的客观反映，并不涉及具体的计算机软、硬件环境。因此，在这一阶段中我们必须将注意力集中在怎样表达出用户对信息的需求，而不考虑具体实现问题。

3．建立数据模型

完成上一阶段后，我们得到了一个与具体计算机软、硬件无关的概念模型。接着我们就可以着手建立数据库模型了，这是数据库设计过程的第三个阶段。在这一阶段中我们要将概念模型中得到的E-R图转换成具体的数据模型。通过前面的学习，我们已经了解到数据模型一般分为层次、网状、关系和面向对象模型等。目前比较常用的是关系数据模型，我们通常将E-R图转换成关系数据模型，实际上就是要将实体、实体的属性和实体之间的联系转换为关系模式。

4．实施与维护数据库

最后一个阶段是实施与维护数据库。完成数据模型的建立后，我们就必须对字段进行命名，确定字段的类型和宽度，并利用数据库管理系统或数据库语言创建数据库结构、输入数据和运行等，因此数据库的实施是数据库设计过程的“最终实现”。如果数据库运行很成功，则表明数据库设计任务基本结束，以后的重点就是数据库的维护工作，包括做好备份工作、数据库的安全性和完整性调整、改善数据库性能等。

数据库的设计在数据库应用系统的开发中占有很重要的地位。只有设计出合理的数据库，才能为建立在数据库上的应用提供方便。不过数据库的设计过程从来都不会有真正的结束，因为随着用户需求和具体应用的变化和扩大，数据库的结构也可能会随之变化。

数据库基本的功能：

信息浏览和查询；

信息的修改、添加和删除；

信息的统计、汇总等。

设计数据库时要注意保留以下内容：

设计文档、内容 *** 作说明，实例数据库、帮助及过程性文件（如下载的资源、工作日志）等。

数据库设计主要包括需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库的实施和数据库的运行和维护，具体内容如下：

1、需求分析

内容：调查和分析用户的业务活动和数据的使用情况，弄清所用数据的种类、范围、数量以及它们在业务活动中交流的情况，确定用户对数据库系统的使用要求和各种约束条件等，形成用户需求规约。

2、概念设计

内容：对用户要求描述的现实世界，通过对其中诸处的分类、聚集和概括，建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。

3、逻辑设计

内容：主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。

4、物理设计

内容：根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。

5、验证设计

内容：收集数据并具体建立一个数据库，运行一些典型的应用任务来验证数据库设计的正确性和合理性。一般，一个大型数据库的设计过程往往需要经过多次循环反复。当设计的某步发现问题时，可能就需要返回到前面去进行修改。

6、运行与维护设计

内容：在数据库系统正式投入运行的过程中，必须不断地对其进行调整与修改。除了关系型数据库已有一套较完整的数据范式理论可用来部分地指导数据库设计之外，尚缺乏一套完善的数据库设计理论、方法和工具，以实现数据库设计的自动化或交互式的半自动化设计。

扩展资料：

重要性

1、有利于资源节约

对计算机软件数据库设计加以重视不仅可减少软件后期的维修，达到节约人力与物力的目的，同时还有利于软件功能的高效发挥。

2、有利于软件运行速度的提高

高水平的数据库设计可满足不同计算机软件系统对于运行速度的需求，而且还可充分发挥并实现系统功能。计算机软件性能提高后，系统发出的运行指令在为用户提供信息时也将更加快速有效，软件运行速度自然得以提高。

3、有利于软件故障的减少

加强数据库设计可有效减少软件故障的发生几率，推动计算机软件功能的实现。

参考资料来源：百度百科-数据库设计

以上就是关于数据库课程设计实例全部的内容，包括:数据库课程设计实例、大型数据库设计原则、什么是数据库设计试述数据库设计的步骤等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！