数据库设计实践

① 在系统实施中，数据库设计的原则

1. 原始单据与实体之间的关系
可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。
在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。
这里的实体可以理解为基本表。

〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。 这就是“一张原始单证对应多个实体”的典型例子。

2. 主键与外键
一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键 (因为它无子孙), 但必须要有外键(因为它有父亲)。

主键与外键的设计，在全局数据库的设计中，占有重要地位。主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。

3. 基本表的性质
基本表与中间表、临时表不同，因为它具有如下四个特性：
(1) 原子性。基本表中的字段是不可再分解的。
(2) 原始性。基本表中的记录是原始数据（基础数据）的记录。
(3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。
(4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。
理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。

4. 范式标准
基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。
为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。

〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式， 因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段， 可以提高查询统计的速度，这就是以空间换时间的作法。 在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和 “数量”这样的列被称为“数据列”。
5. 通俗地理解三个范式
通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解
三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：
第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；
第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。

没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降
低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理
数据模型设计时考虑。降低范式就是增加字段，允许冗余。

6. 要善于识别与正确处理多对多的关系
若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一
个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个
实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识别多对多的关系，但能处
理多对多的关系。

〖例3〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。这两个实体之间的关系，是一 个典型的多对多关系：一本图书在不同时间可以被多个读者借阅，一个读者又可以借多本图书。为此，要在二者之 间增加第三个实体，该实体取名为“借还书”，它的属性为：借还时间、借还标志(0表示借书，1表示还书)，另外， 它还应该有两个外键(“图书”的主键，“读者”的主键)，使它能与“图书”和“读者”连接。

7. 主键PK的取值方法
PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义
的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引 占用空间大，而且速度也慢。

8. 正确认识数据冗余
主键与外键在多表中的重复出现, 不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。

〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余，而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性，因为同一数据，可 能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反对低级冗余(重复性冗余)。

9. E--R图没有标准答案
信息系统的E--R图没有标准答案，因为它的设计与画法不是惟一的，只要它覆盖了系统需求的业务范围和功能内容，就是可行的。反之要修改E--R图。尽管它没有惟一的标准答案，并不意味着可以随意设计。好的E—R图的标准是： 结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。

10 . 视图技术在数据库设计中很有用
与基本表、代码表、中间表不同，视图是一种虚表，它依赖数据源的实表而存在。视图是供程序员使用数据库的 一个窗口，是基表数据综合的一种形式, 是数据处理的一种方法，是用户数据保密的一种手段。为了进行复杂处理、 提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。

对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完 成物理设计之后，立即在基本表上建立第一层视图，这层视图的个数和结构，与基本表的个数和结构是完全相同。 并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握的“安全钥匙”， 才能直接在基本表上操作。

11. 中间表、报表和临时表
中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓 库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员 自己用程序自动维护。

12. 完整性约束表现在三个方面
域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通 过它定义字段的值城。
参照完整性：用PK、FK、表级触发器来实现。
用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。

13. 防止数据库设计打补丁的方法是“三少原则”
(1) 一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E--R图少而精，去掉了重复的多余的 实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计；

(2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组 合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间；

(3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗 余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许 多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简 单，有的人就是不习惯、不采纳、不执行。 数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点， 不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功 能，一百个实体(共一千个属性) 的E--R图，肯定比二百个实体(共二千个属性) 的E--R图，要好得多。 提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成 为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。集成的程度越高，数据 共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E—R图中实体的个数、主键的个数、属性的个数就会越少。

提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据库变成了随意设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。 “三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的 原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝用“打补丁方法”
设计数据库的理论依据。

14. 提高数据库运行效率的办法
在给定的系统硬件和系统软件条件下，提高数据库系统的运行效率的办法是：
(1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。
(2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文件系统方 式用C++语言计算处理完成之后，最后才入库追加到表中去。这是电信计费系统设计的经验。
(3) 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键 PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则垂直分割该表，将原来的一个表分解为两个表。
(4) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。
(5) 在使用面向数据的sql语言进行程序设计时，尽量采取优化算法。
总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个层次上同时下功夫。

上述十四个技巧，是许多人在大量的数据库分析与设计实践中，逐步总结出来的。对于这些经验的运用，读者不能生帮硬套，死记硬背，而要消化理解，实事求是，灵活掌握。并逐步做到：在应用中发展，在发展中应用。

② 论文数据库设计怎么写

论文数据库设计需要按照以下数据内容按顺序排列即可。链迅

1、学院数据实体：学院名称、负责人、办公电话、学院编号。

2、学生数据实体：学号、密码、姓名、性别、民族、籍贯、出生日期、身份证号、联系电话、Email、备注、学院编号、所在班级、角色名称、论文编号。

3、教师数据实体：教师编号、密码、学院编号、所在科室、发布选题、教育程度、职称、姓名、性别、政治面貌、联系电话、Email、角色名称、备注。

4、角色数据实体：角色名称、权限名称。权限数据实体：权限名称、角色名称。以上的实体都是基本的数据实体。

由于操作模块的名称对应该权限，在程序初始化时这些数据都应该添加，教师论文管理系统的目的进行论文管理，因此还要包括如下的几个数据实体：

1、论文数据实体：论文编号、学院、作者、刊物名称、论文题目、收录情况、教师编号、学号、影响力、影响因子、引用次数、备注。

2、评审数据实体：教师编号、学号、论文编号、论文题目、评审意见、总分。

将数据概念结构设计转化为SQLSERVER2005数据库系统所支持的实际数据库模型，就是数据库的逻辑结构。轮唤培在实体以及实体之间的关系基础上，形成数据库中的表格以腊唯及各个表格之间的关系。

(2)数据库设计实践扩展阅读：

论文数据库设计注意事项：

1、标题。标题应鲜明、准确、精练地直接概括所进行的研究实践的主要内容和结果，正标题一般不超过20个字，如需有副标题，副标题一般不超过28个字。

2、内容提要。在主体内容前用200－500字扼要介绍论文的主要内容、采用的方法和得出的主要结论。

3、关键词。按照与论文内容紧密程度，另行依次列出3－5个关键词。

4、英文翻译内容。中文的标题、作者姓名、指导教师姓名、内容提要、关键词应翻译成英文。

③ 数据库原理设计心得体会

这段时间的设计与制作，给了你怎样的一些心得体会呢？那么记录下来吧！下面是由我为大家整理的“数据库原理设计心得体会”，仅供参考，欢迎大家阅读。

数据库原理设计心得体会（一）

在我看来，数据库课程设计主要的目标是利用课程中学到的数据库知识和技术较好的开发设计出数据库应用系统，去解决各行各业信息化处理的要求。通过这次的课程设计，可以巩固我们对数据库基本原理和基础理论的理解，掌握数据库应用系统设计开发的基本方法，进一步提高我们综合运用所学知识的能力。

当我们这组决定做大学生就业咨询系统时，我们并没有着手写程序。而是大家一起商量这个系统概述、系统目标、系统需求、业务流程分析、数据流程分析和数据词典。当这些都准备好了之后，我们进行模块的分工。每个人都有自己的模块设计，而且写出来的代码要求可以实现相应模块的功能，得到理想的效果。当每个人都把自己的分工做好了，最后会由一个人把这些全部组合搭建在一起。我们使用的是Html和php相互嵌套使用，当一个系统做好了之后，我会好好地把程序都看一遍，理会其中的奥秘。

我所负责的是数据库的备份和还原还有一些界面的实现。还记得自己刚接触html的时候，觉得很感兴趣，所以有一段时间几乎到了痴迷的程度。然而Php是我刚接触不久的一种编程语言。不过觉得它的功能真的很强大，可以开发出很多大型的系统。但是在做备份和还原的时候，要考虑的东西还是很多的。当我遇到错误的时候，感到很受打击。值得欣慰的是，在同学的帮助和大量参考书的查阅下，我把自己的模块做好了。这就是我收获最大的地方。而且，我明白了遇到困难永不放弃的重要性，我知道了团队合作的重要性，我领悟了只有坚持不懈才会取得胜利。

知识的获得是无止境的，只要你想学，只要你行动，没有什么会难倒我们的。回首这一个多星期的课程设计，我很欣慰。因为我有了动力，有了勇气。谢谢老师对我们的不懈帮助，谢谢学校给了我们这一次实践的机会，也谢谢组员们的关怀。这些美好的回忆美好的东西将永远伴随着我。

数据库原理设计心得体会（二）

两个星期的时间非常快就过去了，这两个星期不敢说自己有多大的进步，获得了多少知识，但起码是了解了项目开发的部分过程。虽说上过数据库上过管理信息系统等相关的课程，但是没有亲身经历过相关的设计工作细节。这次实习证实提供了一个很好的机会。

通过这次课程设计发现这其中需要的很多知识我们没有接触过，去图书馆查资料的时候发现键岁我们前边所学到的仅仅是皮毛，还有很多需要我们掌握的东西我们根本不知道。同时也发现有很多已经学过的东西我们没有理解到位，不能灵活运用于实际，不能很好的用来解决问题，这就需要我们不断的大量的实践，通过不断的自学，不断地发现问题，思考问题，进而解决问题。在这个过程中我们将深刻理解所学知识，同时也可以学到不少很实用的东西。

从各种文档的阅读到开始的需求分析、概念结构设计、逻辑裂旦结构设计、物理结构设计。亲身体验了一回系统的设计开发过稿源睁程。很多东西书上写的很清楚，貌似看着也很简单，思路非常清晰。但真正需要自己想办法去设计一个系统的时候才发现其中的难度。经常做到后面突然就发现自己一开始的设计有问题，然后又回去翻工，在各种反复中不断完善自己的想法。

我想有这样的问题不止我一个，事后想想是一开始着手做的时候下手过于轻快，或者说是根本不了解自己要做的这个系统是给谁用的。因为没有事先做过仔细的用户调查，不知道整个业务的流程，也不知道用户需要什么功能就忙着开发，这是作为设计开发人员需要特别警惕避免的，不然会给后来的工作带来很大的麻烦，甚至可能会需要全盘推倒重来。所以以后的课程设计要特别注意这一块的设计。

按照要求，我们做的是机票预订系统。说实话，我对这个是一无所知的，没有订过机票，也不知道航空公司是怎么一个流程。盲目开始设计的下场我已经尝过了，结果就是出来一个四不像的设计方案，没有什么实际用处。没有前期的调查，仅从指导书上那几条要求着手是不够的。

在需求分析过程中，我们通过上网查资料，去图书馆查阅相关资料，结合我们的生活经验，根据可行性研究的结果和客户的要求，分析现有情况及问题，采用client/server结构，将机票预定系统划分为两个子系统：客户端子系统，服务器端子系统。在两周的时间里，不断地对程序及各模块进行修改、编译、调试、运行，其间遇到很多问题：由于忘记了一些java语言的规范使得在调试过程中一些错误没有发现，通过这次课程设计，我对调试掌握得更加熟练了，意识到了程序语言的规范性以及我们在编程时要有严谨的态度，同时在写程序时如有一定量的注释，既增加了程序的可读性，也可以使自己在读程序时更容易。

我们学习并应用了sql语言，对数据库的创建、修改、删除方法有了一定的了解，通过导入表和删除表、更改表学会了对于表的一些操作，为了建立一个关系数据库信息管理系统，必须得经过系统调研、需求分析、概念设计、逻辑设计、物理设计、系统调试、维护以及系统评价的一般过程，为毕业设计打下基础。

很多事情不是想象中的那么简单的，它涉及到的各种实体、属性、数据流程、数据处理等等。很多时候感觉后面的设计根本无法继续，感觉像是被前面做的各种图限制了。在做关系模型转换的时候碰到有些实体即可以认为是实体又可以作为属性，为了避免冗余，尽量按照属性处理了。

物理结构设计基本没有碰到问题，这一块和安全性、完整性不觉就会在物理结构设计中添加一些安全设置：主键约束、check约束、default定义等。最后才做索引的部分，对一些比较经常使用搜索的列，外键上建立索引，这样可以明显加快检索的速度，最后别忘记重要的安全性设置，限制用户访问权限，新建用户并和数据库用户做相应的映射。

不管做什么，我们都要相信自己，不能畏惧，不能怕遇到困难，什么都需要去尝试，有些你开始认为很难的事在你尝试之后你可能会发现原来她并没有你以前觉得的那样，自己也是可以的。如果没有自信，没有目标，没有信心就不可能把事情做好，当其他人都在迷茫的时候，自己一定要坚信目标，大学毕业出去即面临找工作，从学习这个专业，到以后从事这方面的工作都需要不断地去学习去实践，这次实践可以给我们敲一个警钟，我们面临毕业，面临择业，需要这些实践经验，在困难面前要勇于尝试，这是这次课程设计给我的最大感想！

以上基本是这次实习的体会了，设计进行的非常艰难，编码非常不容易，才发现做一个项目最重要的不在于如何实现，而是实现之前的需求分析和模块设计。创新很难，有些流行的系统其实现并不难，难的在于对市场的分析和准确定位。设计，是一个任重道远的过程。

数据库原理设计心得体会（三）

数据库课程设计大赛尘嚣渐渐远去，怀着对这次大赛些许不舍，怀着对当初课程设计开始时候豪情万丈决心留恋，怀着通过这次课程设计积累信心与斗志，我开始写这篇文章，为自己足迹留下哪怕是微不足道但是对自己弥足珍贵痕迹并期望与大家共勉。

首先，让我记忆追溯到大二暑假，在老大指引下（老大劝我学ASP（ASP培训）net），我接触到microsoft公司net产品。那个时候我已经学过vc和asp，因为windows程序设计实验课关系，接触过VB（VB培训），但是没有专门去学他，因为习惯了c++里面class，int，觉得vbsub，var看着就不是很顺心。我是一个好奇心很强人，突然看到了一个号称“。net是用于创建下一代应用程序理想而又现实开发工具”，而且主推c#语言，由于对c语言一贯好感，我几乎是立刻对他产生了兴趣。我就开始了对c#学习，任何语言都不是孤立存在，所以数据交互是很重要，暑假时候我把我们这学期课本数据库系统概论看了一遍。我记得以前用c语言编程时候，数据是在内存中申请空间，譬如使用数组等等。很耗费内存空间。这个时候就是数据库站出来时候啦，于是我又装上了sql server2000，以前学asp时候用是access，那个时候只是照着人家做，理论是什么也不是很清楚。

开发时候我想过用什么架构，c/s模式？模式有很多，怎么选择？我就上网搜索现在最流行架构是什么。结果搜到了mvc架构，就是你啦。我决定用这个架构，不会，没关系，咱学。just do it！前期工作准备好后，那么我就得把我暑假学net加以实践。这个时候我更加深入了解了利用ado、net操纵数据库知识。并且对数据库里面存储过程有了比较深入了解。经过大概2个多星期奋斗，我完成了我数据库课程设计——基于net数据集图书馆管理系统。并最后非常荣幸获得了大赛一等奖以及以及新技术应用奖。

与其临渊羡鱼，不如退而结网。这次数据库课程设计给我最大印象就是如果自己有了兴趣，就动手去做，困难在你勇气和毅力下是抬不了头。从做这个数据库开始无论遇到什么困难，我都没有一丝放弃念头。出于对知识渴望，出于对新技术好奇，出于对一切未知求知。我完成了这次数据库课程设计，不过这只是我学习路上驿站，未来十年net核心技术就是xml[至少微软是这么宣传]，我会继续学习它，包括jave公司j2ee我也很想试试，语言本来就是相通，just do it！语言并不重要毕竟它仅仅是工具，用好一个工具并不是一件值得为外人道事情，主要是了解学习思想。古语说好：学无止境啊。

实际上从学习经历来看，我们接触知识体系都是属于比较老或比较传统，与现在发展迅速IT行业相比很多情况已不再适用，尤其是当开源模式逐渐走近开发者后更是如此。虽然是一个数据库课程设计，由于本人在选择项目时候是本着对自己有实际应用价值角度考虑，所以其中也涉及到一些数据库以外设计。总而言之，这次数据库设计心得体会不能用语言完全表达。

④ 求一篇基于web的数据库设计社会实践调查报告

《基于web的数据库设计实践》
The Database Design Based On WEB Used In Remote Concurrent Design

Abstract: the paper analyses the database characteristics used in the remote concurrent proct design system based on Internet, deeply researches the database structure, interface and the method of the data safety.

Keywords: Internet, remote concurrent design, database based on Web

近年来，随着Web技术的蓬勃发展，人们已不满足于只在浏览器上获取静态的信息，想要通过它发表意见、查询数据。随着电子商务的普及人们开始参与一些网络商务活动，这就迫切需要实现Web与数据库的互连[1]。产品异地并行设计对数据的要求有一定的特殊性，主要有（1）产品数据多种多样。产品设计，特别是机械产品设计常常是大型而又复杂，在异地通过不同的设计小组，按不同的分工设计同一产品，所要管理和通讯的数据类型随着分工的不同而有不同的表现形式，如常规的数字组成的数据集，以图形、图象形式表达的产品模型数据，以文字形式描述设计的文档，还有图表、公式等形式，复杂多样。（2）产品数据交换频繁，流量大。产品设计是一个协同工作的创造性集体智慧凝聚的过程，要使设计顺利进行，分布在异地的不同设计小组之间就要经常性地进行数据交换，并且有些形式表达的产品数据是较大的文件。（3）产品数据的一致性要求高。分工合作的不同设计小组之间的设计任务是彼此关联，互相依赖的。如果其中一个数据改变了，相关联的数据必须跟着改变，在Web数据库设计时必须考虑数据的一致性问题。（4）产品数据的并发性访问频繁。由于异地产品设计的特殊属性，数据的并发性访问非常频繁。所以，进行基于Internet的产品异地并行设计的Web数据库设计与一般的电子商务不同，要充分考虑以上属性。本文结合我们近期开发的机械产品异地并行设计系统（RCDS, Remote Concurrent Design System），综合比较了多种当今流行的网络数据存取技术，设计出可靠安全的数据库系统。

1 Web数据库连接方案

1.1数据库连接方案选择

RDO、DAO和ADO是比较常见的Web数据库访问技术。

DAO (Data Access Objects) 数据访问对象是第一个面向对象的接口，它含有 Microsoft Jet 数据库引擎（由 Microsoft Access 所使用），并允许 Visual Basic 开发者通过 ODBC 象连接到其他数据库一样，直接访问到 Access 表。DAO 最适用于单系统应用程序或小范围本地分布使用，对大范围的异地并行设计显得功能不够强大。

RDO (Remote Data Objects) 远程数据对象是一个到 ODBC 的、面向对象的数据访问接口，它同易于使用的 DAO style组合在一起，提供了一个接口，形式上展示出所有 ODBC 的底层功能和灵活性。RDO 在访问 Jet 或 ISAM 数据库方面有一定的限制，而且它只能通过现存的 ODBC 驱动程序来访问关系数据库。但是，RDO 已被证明是许多 SQL Server、Oracle

以及其他大型关系数据库开发者经常选用的最佳接口。RDO 提供了用来访问存储过程和复杂结果集的更多和更复杂的对象、属性，以及方法。对异地并行设计Web数据库来说也不是十分理想。

ADO（ActiveX Data Objects）为ActiveX组件中数据库访问组件，ASP就是通过它实现对数据库的访问。ADO 是 DAO、RDO 的后继产物。ADO 2.0在功能上与 RDO 更相似，而且一般来说，在这两种模型之间有一种相似的映射关系。ADO “扩展”了 DAO 和 RDO 所使用的对象模型，这意味着它包含较少的对象、更多的属性、方法（和参数），以及事件。例如，ADO 没有与 rdoEngine 和 rdoEnvironment 对象相等同的对象，可以包含 ODBC 驱动程序管理器和 hEnv 接口。尽管事实上接口可能是通过 ODBC OLE DB 服务提供程序实现的，但目前也不能从 ADO 中创建 ODBC 数据源。ADO 是为 Microsoft最新和最强大的数据访问范例 OLE DB 而设计的，是一个便于使用的应用程序层接口。OLE DB 为任何数据源提供了高性能的访问，这些数据源包括关系和非关系数据库、电子邮件和文件系统、文本和图形、自定义业务对象等等。ADO 在关键的 Internet 方案中使用最少的网络流量，并且在前端和数据源之间使用最少的层数，所有这些都是为了提供轻量、高性能的接口。同时 ADO 使用了与 DAO和 RDO相似的约定和特性，简化的语义使它更易于学习。

ADO最早是在IIS中引入的，主要用于ASP，用ADO可以使服务器端的脚本通过ODBC存取和操纵数据库服务器的数据。使用ADO的对象可以建立和管理数据库的连接，从数据库服务器请求和获取数据，执行更新、删除、添加数据、获取ODBC的错误信息等。ADO是ASP方案中最具吸引力的数据库连接控件，它为用户提供了连接任何兼容ODBC的数据库以及创建全功能数据库应用程序的能力。

ADO具有简单易用、高速、占用资源少等的优点。不同于DAO和RDO，ADO有着更高的执行效率。ADO 对象模型如图1a所示。每个 Connection、Command、Recordset 和 Field 对象都有 Properties 集合，如图1b所示。

a) b)

图1 ADO对象模型及属性

应该说，ADO是微软的下一代数据库连接技术，用来全面取代RDO和DAO的数据访问工具。从发展趋势来看，ADO今后将逐步替代老的DAO特别是RDO数据访问接口，成为新的远程数据访问方法。所以，选择ADO作为产品异地并行设计的Web数据库接口技术是合适的。

1.2 ADO应用分析

ADO 并不是自动和现存的数据访问应用程序代码兼容的。当 ADO 封装 DAO 和 RDO 的功能性的时候，必须将许多语言要素转换为 ADO 语法。在某些情况下，这将意味着要对现存代码的某些功能做一个简单转换。在其他情况下，最佳的做法可能是用 ADO 的新功能重写该应用程序。

包含在 DAO 和 RDO 模型中的许多功能被合并为单个对象，这样就生成了一个简单得多的对象模型。然而，由于这个原因，起初可能会觉得找到合适的 ADO 对象、集合、属性、方法，或事件非常困难。与 DAO 和 RDO不同的是，尽管 ADO 对象是分层结构的，但在分层结构范围之外也是可以创建的。同时，也应当注意，ADO 当前并不支持 DAO 的所有功能。ADO 主要包括 RDO 风格的功能性，以便和 OLE DB 数据源交互，另外还包括远程和 DHTML 技术。

一般说来，在 ADO 的演化过程中，马上把大多数 DAO 应用程序（except possibly是那些使用 ODBCDirect 的应用程序）移植到 ADO 上为时太早，因为当前的 ADO 并不支持数据定义 (DDL)、用户、组等等。不过，如果只将 DAO 用于客户—服务器应用程序，并不依赖于 Jet 数据库引擎或不使用 DDL，那么就可能移植到 ADO。最终，Microsoft 将提供一个 ADO DDL 组件来帮助进行 DAO 到 ADO 的移植，并为 OLE DB 供应商提供一般的 DDL 支持。

在ASP中使用ADO技术来访问Web数据库，其应用前景是无可估量的。原理图如下：

图2 ADO在ASP程序中的应用

2 Web数据库管理系统

常见的数据库类型有面向对象的数据库（OODB）和关系型数据库。OODB对主流数据库应用开发来说是相当新颖的，使用OODB使应用程序中的数据对象与现实世界中的对象一一对应，面向对象数据库扩充了对象模型。一个常用的对象模型是由对象数据库管理组（ODMG）开发出来，具有比传统的关系数据库更优越的性能，但毕竟在目前还是一种探索阶段，暂时还未有相应的技术普及。

关系数据库已经是数据库体系的世界标准。当开发一个数据驱动应用程序时，大多数情况下用户需要访问网络（如Internet、Intranet等）上的数据信息，就RCDS就是建立在网络的信息通讯之上，是完全的客户机/服务器应用程序。

SQL Server是一个可缩放、高性能的关系型数据库管理系统（RDBMS），它的设计是为了满足分布式客户/服务器计算的需要，允许客户应用程序使用几个特定的工具和技术控制从服务器检索的数据。这些包括触发器、存储过程和规则的选项。因此，系统采用MS SQL Server7.0作为后台数据库。

3 Web数据库结构

数据模型通常有层次模型、网状模型、关系模型及OO（面向对象）模型等。其中关系模型是建立在数学概念基础之上的一种模型，由若干个关系框架组成的集合,它也是到目前为止最为成熟的一种数据库类型。本文RCDS采用MS SQL Server作为后台数据库，根据数据库工具和数据库特点，开发出一套可靠健壮的数据存储方案。

整个数据库共有AdminData、ChatNames、DesignUnits、Message、OnlineUnits、Procts、RqtTasks、RqtTaskUnits、RqtDesignUnits、ShareData、Tasks、TaskUnits和UploadFiles等表格。在建立数据模型的时候首先考虑是要避免重复数据，也就是建立规范化数据库。规范化数据库可以通过被称为范式水平的指标来衡量，级别有第一范式、第二范式和第三范式，通常第三范式就是要达到的目标，因为它提供了数据冗余和开发简易性之间的最好折衷。

RCDS数据库正是按照第三范式标准来设计的，它保证了模型的精简和表格的紧凑性。而第三范式标准也最大发挥了关系数据库的优势，图3是部分表格的视图链接情况。

图3 关系表格视图

4.1 并发控制的处理

在多个用户同时访问一个数据库时就产生并发问题，特别是在其中一些用户对数据库有添加或删除修改等操作时，那么其他所获得的数据可能是一塌糊涂，甚至造成整个数据访问的冲突、终止，从而使系统发生混乱以至崩溃。RCDS采用的解决办法是锁定技术，总体上分为共享锁定和排它锁定两种类型（如图4）。前者是指同时有几个过程共享一个锁定，比如一个用户（或客户）正在读取一个数据，虽然在这之前他已经对该数据设置了锁（LOCK），但其他用户同样可以（也只能是）读取它。而排他锁定一般应用于对数据进行修改或更新（包括添加删除等）操作，即是用户在修改一个数据之前设置了锁定，在一定的时间里其他用户是不能访问到该数据的，只有等待锁定解除（UNLOCK）才能进行访问到它，当然在计算机处理的时候，其他的用户一般是感觉不到有这个等待时间的。通过这样的处理，就保证了数据的一致性。

a) 共享锁定

b) 排它锁定

图4 安全锁定类型

在ADO进行数据库操作时，它的锁定类型相对来说复杂一些。打开记录集时，可以指定锁定类型。锁定类型决定了当不止一个用户同时试图改变一个记录时，数据库应如何处理。ADO中的锁定主要有以下四种类型：

l AdLockReadOnly 指定你不能修改记录集中的记录

l AdLockPessimistic 指定在编辑一个记录时，立即锁定它

l AdLockOptimstic 指定只有调用记录集的Update方法时，才锁定记录

l AdLockBatchOptimstic 指定记录只能成批地更新

在缺省情况下，记录集使用只读锁定。要指定不同的锁定类型，可以在打开记录集时包含这些锁定常量之一。部分代码如下：

… …

Set MyConn=Sever.CreateObject(“ADODB.Connection”)

//定义数据库连接MyConn

Set RS=Sever.CreateObject(“ADODB.RecordSet”)

//定义返回数据记录集

MyConn.Open “ByktDB.dsn”//建立应用程序与数据源的连接

RS.Open “SELECT * FROM Mytable”, MyConn, adOpenDynamic， adLockPessimistic

//进行数据库操作，并且设置锁定

RS.Close

MyConn.Close

… …

4.2产品数据一致性处理

数据的安全因素除了前面所提到的并行控制之外，还要考虑事务处理。网络数据库有其不同的地方，例如：假设某个时间有一个设计人员在你的站点上索取一些设计信息，有关的设计信息存储在两个表中。一个表用来保存该设计者的信息，另一个表包含了要索取的设计信息。该设计人员的信息已经输入了第一个表中。但是，就在这时，发生了意外情况，一道闪电击中了你的服务器，使第二个表没有被更新。在这种情况下，一个健壮的系统就必须保证最后的结果是两个表都没有被更新过。这时候事务处理就发挥了重要的功效。

使用事务处理，你可以防止第二个表没有被更新而第一个表被更新的情况出现：当一组语句构成一个事务处理时，如果一个语句没有执行成功，则所有的语句都不成功。不管是针对多个表，还是进行表内多个记录的操作，它们所需要的安全保证是一样的。事务处理的实现代码如下：

… …

Set MyConn=Sever.CreateObject(“ADODB.Connection”)

MyConn.Open “ByktDB.dsn”

MyConn.BeginTrans //事务处理开始

MyConn.Execute “INSERT DataTable(Num) Values(‘3628’)”

MyConn.Execute “INSERT Shipping (Address) VALUES(‘Paris,France’)”

MyConn.CommitTrans //事务处理结束

MyConn.Close

… …

在上面这段代码中，用BeginTrans方法和CommitTrans方法来标记事务处理的开始和结束。在BeginTrans方法被调用之后，CommitTRans方法被调用之前，不管出现什么错误，两个表都不会被更新，在这个过程中所有处理的数据都保持了完全可靠的一致性。

⑤ 数据库课程设计实例

数据库课程设计

题目：小型超市管理系统
1、项目计划
1.1系统开发目的
（1）大大提高超市的运作效率；
（2）通过全面的信息采集和处理，辅助提高超市的决策水平；
（3）使用本系统，可以迅速提升超市的管理水平，为降低经营成本， 提高效益，增强超市扩张力， 提供有效的技术保障。
1.2背景说明
21世纪，超市的竞争也进入到了一个全新的领域，竞争已不再是规模的竞争，而是技术的竞争、管理的竞争、人才的竞争。技术的提升和管理的升级是超市业的竞争核心。零售领域目前呈多元发展趋势，多种业态：超市、仓储店、便利店、特许加盟店、专卖店、货仓等相互并存。如何在激烈的竞争中扩大销售额、降低经营成本、扩大经营规模，成为超市营业者努力追求的目标。
1.3项目确立
针对超市的特点，为了帮助超市解决现在面临的问题，提高小型超市的竞争力，我们将开发以下系统：前台POS销售系统、后台管理系统，其中这两个子系统又包含其它一些子功能。
1.4应用范围
本系统适应于各种小型的超市。
1.5 定义
（1）商品条形码：每种商品具有唯一的条形码，对于某些价格一样的商品，可以使用自定义条形码。
（2）交易清单：包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号。
（3）商品积压：在一定时期内，远无法完成销售计划的商品会造成积压。
（4）促销：在一定时期内，某些商品会按低于原价的促销价格销售。
库存告警提示：当商品的库存数量低于库存报警数量时发出提示。
（5）盘点：计算出库存、销售额、盈利等经营指标。
1.6 参考资料
《数据库原理及设计》 陶宏才编 清华大学出版社
《SQL Server 2000 实用教程》范立南编 清华大学出版社
《SQL Server 2000 编程员指南》李香敏编 北京希望电子出版社
《轻松搞定 SQL Server 2000 程序设计》Rebecca M.Riordan编
《软件工程规范》Watts S.Humphrey编 清华大学出版社
《软件工程理论与实践》 Shari Lawrence Pfleeger编 清华大学出版社
《软件需求分析》 Swapna Kishore编 机械工业出版社
《软件工程思想》 林锐编

2、逻辑分析与详细分析
2.1系统功能
（1）、零售前台（POS）管理系统，本系统必须具有以下功能：
 商品录入：根据超巿业务特点制定相关功能，可以通过输入唯一编号、扫描条形码、商品名称等来实现精确或模糊的商品扫描录入。该扫描录入方法可以充分保证各种电脑操作水平层次的人员均能准确快速地进行商品扫描录入。
 收银业务：通过扫描条形码或者直接输入商品名称（对于同类多件商品采用一次录入加数量的方式）自动计算本次交易的总金额。在顾客付款后，自动计算找零，同时打印交易清单（包括交易的流水账号、每类商品的商品名、数量、该类商品的总金额、交易的时间、负责本次收银的员工号）。如果顾客是本店会员并持有本人会员卡，则在交易前先扫描会员卡，并对所购物品全部实行95折优惠，并将所购物品的总金额累计到该会员的总消费金额中。 会员卡的有效期限为一年，满一年未续卡者，该会员卡将被注销。
 安全性：OS登陆、退出、换班与操作锁定等权限验证保护；断电自动保护最大限度防止意外及恶意非法操作。
 独立作业：有的断网收银即在网络服务器断开或网络不通的情况下，收银机仍能正常作业
(2)、后台管理系统，本系统必须具备以下功能
 进货管理： 根据销售情况及库存情况，自动制定进货计划（亦可手工制定修改），可以避免盲目进货造成商品积压。 按计划单有选择性地进行自动入库登记。 综合查询打印计划进货与入库记录及金额。
 销售管理： 商品正常销售、促销与限量、限期及禁止销售控制。 综合查询各种销售明细记录、各地收银员收银记录以及交结账情况等。 按多种方式统计生成销售排行榜，灵活察看和打印商品销售日、月、年报表。
 库存管理： 综合查询库存明细记录。 库存状态自动告警提示。如库存过剩、少货、缺货等。软件为您预警，避免库存商品积压损失和缺货。 库存自动盘点计算。
 人员管理： 员工、会员、供货商、厂商等基本信息登记管理。 员工操作权限管理。 客户销售权限管理。

（3）系统结构
系统总体结构

模块子系统结构

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

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

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

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

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

功能描述：人员管理子系统提供基本信息登记管理，员工操作权限管理，客户销售权限管理的功能。
2.2、流程图
前台管理系统

顶层DFD图

第0层DFD图

第1层DFD图

2.3、户类型与职能
（1）、员工（营业员）：
 通过商品条形码扫描输入商品到购买清单
 操作软件计算交易总金额
 操作软件输出交易清单
 对会员进行会员卡扫描以便打折
（2）、：超市经理
 操作软件录入商品，供货商，厂商
 操作软件制定进货计划
 查询打印计划进货与入库记录
 操作软件控制商品销售与否
 查询打印销售情况
 操作软件生成销售排行榜
 查询库存明细记录
 根据软件发出的库存告警进行入货
 操作软件进行盘点计算
（3）、总经理：
 基本信息登记管理
 员工操作权限管理
 客户销售权限管理
2.4、统开发步骤
 确定参与者和相关的用况
 为每个用况设计过程
 建立顺序图，确定每个脚本中对象的协作
 创建类，确定脚本中的对象
 设计, 编码, 测试, 集成类
 为过程编写系统测试案例
 运行测试案例，检验系统
2.5、系统环境需求
 系统模式

本系统采用C/S模式作为开发模式
 硬件环境
服务器端：
高性能的计算机一台，
普通的双绞线作为连接。
客户端： 普通的计算机或者工作站，
普通的双绞线作为连接。
 软件环境
服务器端：安装SQL Server 2000的服务器版本，
安装windows 2000服务器版本，
配置了诺顿等必须的防毒软件。
客户端： 安装SQL Server2000的服务器版本，
安装了VB等可视化开发工具软件，
安装windows2000服务器版本。

2.6、系统安全问题
信息系统尽管功能强大，技术先进，但由于受到自身体系结构，设计思路以及运行机制等限制，也隐含许多不安全因素。常见因素有：数据的输入，输出，存取与备份，源程序以及应用软件，数据库，操作系统等漏洞或缺陷，硬件，通信部分的漏洞，企业内部人员的因素，病毒，“黑客”等因素。因此，为使本系统能够真正安全，可靠，稳定地工作，必须考虑如下问题：为保证安全，不致使系统遭到意外事故的损害，系统因该能防止火，盗或其他形式的人为破坏。
 系统要能重建
 系统应该是可审查的
 系统应能进行有效控制，抗干扰能力强
 系统使用者的使用权限是可识别的
3、基于UML的建模
3.1语义规则
用例模型（use cases view）（用例视图）的基本组成部件是用例（use case）、角色(actor)和系统(system)。用例用于描述系统的功能，也就是从外部用户的角度观察，系统应支持哪些功能，帮助分析人员理解系统的行为，它是对系统功能的宏观描述，一个完整的系统中通常包含若干个用例，每个用例具体说明应完成的功能，代表系统的所有基本功能（集）。角色是与系统进行交互的外部实体，它可以是系统用户，也可以是其它系统或硬件设备，总之，凡是需要与系统交互的任何东西都可以称作角色。系统的边界线以内的区域（即用例的活动区域）则抽象表示系统能够实现的所有基本功能。在一个基本功能（集）已经实现的系统中，系统运转的大致过程是：外部角色先初始化用例，然后用例执行其所代表的功能，执行完后用例便给角色返回一些值，这个值可以是角色需要的来自系统中的任何东西。
UML：是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示；它不是一种可视化的程序设计语言而是一种可视化的建模语言；不是工具或知识库的规格说明而是一种建模语言规格说明是一种表示的标准；不是过程也不是方法但允许任何一种过程和方法使用它。

用例（use case）：

参与者（actor）：

3.2、UML模型
3.21、系统UML模型

3.22、子系统UML模型
（1）零售前台（POS）管理系统用例视图

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

3.3、系统实现图

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\SuperMarketdb.mdf',
size=100MB,
maxsize=200MB,
filegrowth=20MB
)
log on
(
name=SuperMarketlog,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.ldf',
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 Stock.StockID as SID,
MerchInfo.MerchName as 商品名称,
MerchInfo.BarCode as 条形码,
Factory.FactoryName as 厂商,
Provide.ProvideName as 供货商,
Stock.MerchNum as 计划进货数量,
Stock.PlanDate as 计划进货日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=0
GO
/*创建用于查询销售明细记录的视图*/
CREATE VIEW v_Sale
AS
SELECT MerchInfo.MerchName as 商品名称,
MerchInfo.BarCode as 条形码,
MerchInfo.MerchPrice as 商品价格,
Sale.SalePrice as 销售价格,
Sale.SaleNum as 销售数量,
Sale.SaleDate as 销售日期
FROM Sale INNER JOIN
MerchInfo ON Sale.MerChID = MerchInfo.MerchID
GO
/*创建用于查询入库情况的视图*/
CREATE VIEW v_Stock
AS
SELECT MerchInfo.MerchName as 商品名称,
MerchInfo.BarCode as 条形码,
Factory.FactoryName as 厂商,
Provide.ProvideName as 供货商,
Stock.MerchPrice as 入库价格,
Stock.MerchNum as 入库数量,
Stock.TotalPrice as 入库总额,
Stock.StockDate as 入库日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=1
GO

7、小结
和传统管理模式相比较，使用本系统，毫无疑问会大大提高超市的运作效率，辅助提高超市的决策水平，管理水平，为降低经营成本， 提高效益，减少差错，节省人力，减少顾客购物时间，增加客流量，提高顾客满意度，增强超市扩张能力， 提供有效的技术保障。
由于开发者能力有限，加上时间仓促，本系统难免会出现一些不足之处，例如：
 本系统只适合小型超市使用，不能适合中大型超市使用；
 超市管理系统涉及范围宽，要解决的问题多，功能复杂，实现困难，但由于限于时间，本系统只能做出其中的一部分功能；
对于以上出现的问题，我们深表歉意，如发现还有其它问题，希望老师批评指正。

⑥ 数据库课程设计心得体会范文

通过数据库课程设计的完成，我们从中获得了不少的感慨，通过对所学知识的体会，能够明显感觉到自己比以往进步了不少。以下是由我为大家整理的“数据库课程设计心得体会范文”，仅供参考，欢迎大家阅读。

数据库课程设计心得体会范文（一）

在我看来，数据库课程设计主要的目标是利用课程中学到的数据库知识和技术较好的开发设计出数据库应用系统，去解决各行各业信息化处理的要求。通过这次的课程设计，可以巩固我们对数据库基本原理和基础理论的理解，掌握数据库应用系统设计开发的基本方法，进一步提高我们综合运用所学知识的能力。

当搏棚我们这组决定做大学生就业咨询系统时，我们并没有着手写程序。而是大家一起商量这个系统概述、系统目标、系统需求、业务流程分析、数据流程分析和数据词典。当这些都准备好了之后，我们进行模块的分工。每个人都有自己的模块设计，而且写出来的代码要求可以实现相应模块的功能，得到理想的效果。当每个人都把自己的分工做好了，最后会由一个人把这些全部组合搭建在一起。我们使用的是html和php相互嵌套使用，当一个系统做好了之后，我会好好地把程序都看一遍，理会其中的奥秘。

我所负责的是数据库的备份和还原还有一些界面的实现。还记得自己刚接触html的时候，觉得很感兴趣，所以有一段时间几乎到了痴迷的程度。然而php是我刚接触不久的一种编程语言。不过觉得它的功能真的很强大，可以开发出很多大型的系统。但是在做备份和还原的时候，要考虑的东西还是很多的。当我遇到错误的时候，感到很受打击。值得欣慰的是，在同学的帮助和大量参考书的查阅下，我把自己的模块做好了。这就是我收获最大的地方。而且，我明白了遇到困难永不放弃的重要性，我知道了团队合作的重要性，我领悟了只有坚持不懈才会取得胜利。

知识的获得是无止境的，只要你想基渣则学，只要你行动，没有什么会难倒我们的。回首这一个多星期的课程设计，我很欣慰。因为我有了动力，有了勇气。谢谢老师对我们的不懈帮助，谢谢学校给了我们这一次实践的机会，也谢谢组员们的关怀。这些美好的回忆美好的东西将永远伴随着我。

数据库课程设计心得体会范文（二）

本次课程设计，使我对《数据结构》这门课程有了更深入理解。《数据结构》是一门实践性较强课程，为了学好这门课程，必须在掌握理论知识同时，加强上机实践。

我课程设计题目是线索二叉树运算。刚开始做这个程序时候，感到完全无从下手，甚至让我觉得完成这次程序设计根本就是不可能，于是开始查阅各种资料以及参考文献，之后便开始着手写程序，写完运行时有很多问题。特别是实现线索二叉树删除运算时很多情况没有考虑周全，经常运行出现错误，但通过同学间帮助最终基本解决问题。

在本课程设计中，我明白了理论与实际应用相结合重要性，并提高了自己组织数据及编写大型程序能力。培养了基本、良好程序设计技能以及合作能力。这次课程设计同样提高了我综合运用所学知识能力。并对VC有了更深入了解。《数据结构》是一门实践性很强课程，上机实习是对学生全面综合素质进行训练一种最基本方法，是与课梁衡堂听讲、自学和练习相辅相成、必不可少一个教学环节。

上机实习一方面能使书本上知识变“活”，起到深化理解和灵活掌握教学内容目；另一方面，上机实习是对学生软件设计综合能力训练，包括问题分析，总体结构设计，程序设计基本技能和技巧训练。此外，还有更重要一点是：机器是比任何教师更严厉检查者。因此，在“数据结构”学习过程中，必须严格按照老师要求，主动地、积极地、认真地做好每一个实验，以不断提高自己编程能力与专业素质。

通过这段时间课程设计，我认识到数据结构是一门比较难课程。需要多花时间上机练习。这次程序训练培养了我实际分析问题、编程和动手能力，使我掌握了程序设计基本技能，提高了我适应实际，实践编程能力。总来说，这次课程设计让我获益匪浅，对数据结构也有了进一步理解和认识。

数据库课程设计心得体会范文（三）

一周的课程设计结束了，在这次的课程设计中不仅检验了我所学习的知识，也培养了我如何去把握一件事情，如何去做一件事情，又如何完成一件事情的方法和技巧。在设计过程中，和同学们相互探讨，相互学习，相互监督。我学会了运筹帷幄，学会了宽容，学会了理解，也学会了做人与处世，这次课程设计对我来说受益良多。

课程设计是我们专业课程知识综合应用的实践训练，着是我们迈向社会，从事职业工作前一个必不少的过程。“千里之行始于足下”，通过这次课程设计，我深深体会到这句千古名言的真正含义。我今天认真的进行课程设计，学会脚踏实地迈开这一步，就是为明天能稳健地在社会大潮中奔跑打下坚实的基础。我这次设计的科目是数据结。

数据结构，是一门研究非数值计算的程序设计问题中计算机的操作对象（数据元素）以及它们之间的关系和运算等的学科，而且确保经过这些运算后所得到的新结构仍然是原来的结构类型。“数据结构”在计算机科学中是一门综合性的专业基础课。数据结构是介于数学、计算机硬件和计算机软件三者之间的一门核心课程。数据结构这一门课的内容不仅是一般程序设计（特别是非数值性程序设计）的基础，而且是设计和实现编译程序、操作系统、数据库系统及其他系统程序的重要基础。通过这次模具设计，我在多方面都有所提高。

在界面设置中使用函数调用while。其中文本显示颜色和背景颜色都可以任意按照自己的喜好，任意改变，但改变的时候必须采用标准英文大写，同时在制作显示菜单的窗口，大小根据菜单条数设计。最后采用printf输出程序设计界面。

这次的程序软件基本上运行成功，可以简单的建立链式循环链表，并进行输出，及循环语句的运用和选择语句的控制。由于时间和知识上的限制，使得程序规模相对较小，即功能还不很全面，应用也不很普遍。原来C语言可是涉及很多知识，而不是枯燥无聊的简单的代码部分而已，利用C语言方面的知识，我们可以设计出更完善的软件。

通过这次的课程设计，更是让我深刻认识到自己在学习中的不足，同时也找到了克服这些不足的方法，这也是一笔很大的资源。在以后的时间中，我们应该利用更多的时间去上机实验，加强自学的能力，多编写程序，相信不久后我们的编程能力都会有很大的提高能设计出更多的更有创新的作品。

⑦ 数据库表单设计实验目的及意义

数据库表单设计实验目的及意义是为了配合数据库原理及应用开发而设置的，是计算机科学与技术、网络工程、信息安全、物联网工程、软件工程等专业集中实践的教学环节，是将关系数据库理论知识转化为解决实际问题能力的重要环节。数据库系统课程设计目的在于加深对关系数据库理论知识的理解，通过使用具体的 DBMS，掌握一种实际的数据库管理系统并掌握其操作技术，熟练掌握使用数据库前端开发工具（如 VB、 C++、 Java、 Delphi、 PowerBuilder等），进一步提高同学们运用数据库技术解决实际问题的能力。