各种类型数据的高等界面,后来逐渐演变成满足所有数据访问需要的完整解datamodule4.adoquery2.sql.add('SELECT借书证号,密码FROM[user]WHERE(借书证号=:tt)');
datamodule4.adoquery2.parameters[0].value:=username;
datamodule4.adoquery2.open;
在为TQuery或TADOquery部件设置SQL属性时调用Close方法总是很安全的,如果TQuery或TADOquery部件已经被关闭了,调用Close方法时不会产生任何影响。在应用程序中为SQL属性设置新的SQL命令语句时,必须要调用Clear方法以清除SQL属性中现存的SQL命令语句,如果不调用Clear方法,便调用Add方法向SQL属性中设置SQL命令语句,那么新设置的SQL命令语句会追加在现存SQL命令语句后面,在程序运行时常常会出现出乎意料的查询结果甚至程序无法运行下去。
在这里要特别注意的,一般情况下TQuery或TADOquery部件的SQL属性只能包含一条完整的SQL语句,它不允许被设置成多条SQL语句。当然有些数据库服务器也支持在TQuery或TADOquery部件的SQL属性中设置多条SQL语句,只要数据库服务器允许这样,我们在编程时可以为SQL属性设置多条SQL语句。
在为TQuery或TADOquery部件设置完SQL属性的属性值之后,也即编写好适当的SQL程序之后,可以有多种方式来执行SQL程序。
在设计过程中,设置完TQuery或TADOquery部件的SQL属性之后将其Active属性的值置为True,这样便可以执行SQL属性中的SQL程序,如果应用中有与TQuery或TADOquery部件相连的数据浏览部件(如TDDGridTDBEdit等)那么在这些数据浏览部件中会显示SQL程序的执行结果。
在应用程序运行过程中,通过程序调用TQuery或TADOquery组件的Open方法或ExecSQL方法可以执行其SQL属性中的SQL程序。Open方法和ExecSQL方法是不一样的。Open方法只能用来执行SQL语言的查询语句(Select命令),并返回一个查询结果集,而ExecSQL方法还可以用来执行其它常用的SQL语句(如INSERT,UPDATE,DELETE等命令),例如:
Query1.Open(这样会返回一个查询结果集)
如果调用Open方法,而没有查询结果时,会出错。此时应该调用ExecSQL方法来代替Open方法。如:
Query1.ExecSQL(没有返回结果)
当然在设计应用程序时,程序设计人员是无法确定TQuery或TADOquery组件中的SQL语句是否会返回一个查询结果的。对于这种情况应当用Try…Except模块来设计程序。在Try部分调用Open方法,而在Except部分调用ExceSQL方法,这样才能保证程序的正确运行。
例如:
Try
Query1.Open
Except
Query1.ExecSQL
End
通过Tquery或TADOquery组件可以获得两种类型的数据:
u“活动”的数据
这种数据就跟通过TTable部件获得的数据一样,用户可以通过数据浏览部件来编辑修改这些数据,并且当调用Post方法或当焦点离开当前的数据浏览部件时,用户对数据的修改自动地被写回到数据库中。
u非活动的数据(只读数据)
用户通过数据浏览部件是不能修改其中的数据。在缺省情况下,通过TQuery部件获得的查询结果数据是只读数据,要想获得“活动”的数据,在应用程序中必须要设置Tquery或TADOquery组件的RequestLive属性值为True,然而并不是在任何情况下(通过设置RequestLive的属值True)都可以获得“活动”的数据的,要想获得“活动”的数据,除了将TQuery部件的RequestLive属性设置为True外,相应的SQL命令还要满足以下条件。
本地SQL语句查询情况下,要得到可更新的数据集,SQL语句的限制为:
n查询只能涉及到一个单独的表
nSQL语句中不能包含ORDERBY命令
nSQL语句中不能含聚集运算符SUM或AVG
n在Select后的字段列表中不能有计算字段
n在Select语句WHERE部分只能包含字段值与常量的比较运算,这些比较运算符是:Like,>,<,>=,<=。各比较运算之间可以有并和交运算:AND和OR
当通过SQL语句查询数据库服务器中的数据库表:
n查询只能涉及到一个单独的表
nSQL语句中不能包含ORDERBY命令
nSQL语句中不能含聚集运算符SUM或AVG运算
另外,如果是查询Sybase数据库中的表,那么被查询的表中只能有一个索引。
如果在应用程序中要求TQuery或TADOquery组件返回一个“活动”的查询结果数据集,但是SQL命令语句不满足上述约束条件时,对于本地数据库的SQL查询,BDE只能返回只读的数据集。对于数据库服务器中的SQL查询,只能返回错误的代码。当Tquery或TADOquery组件返回一个“活动”的查询结果数据集时,它的CanModIfy属性的值会被设置成True。
§3.4MSSQLServer简述
SQLServer是一个后台数据库管理系统,它功能强大操作简便,日益为广大数据库用户所喜爱。越来越多的开发工具提供了与SQLServer的接口。SQLServer是一个关系数据库管理系统,它最初是由Microsoft、Sybase和Ashton-Tate三家公司共同开发的。于1988年推出了第一个OS/2版本,在WindowsNT推出后,Microsoft与Sybase在SQLServer的开发上就分道扬镳了,Microsoft将SQLServer移植到WindowsNT系统上,专注于开发推广SQLServer的WindowsNT版本。
SQLServer2000是Microsoft公司推出的SQLServer数据库管理系统的最新版本,该版本继承了SQLServer7.0版本的优点,同时又比它增加了许多更先进的功能、具有使用方便、可伸缩性好与相关软件集成程度高等优点。可跨越从运行MicrosoftWindows98的膝上型电脑到运行MicrosoftWindows2000的大型多处理器的服务器等多种平台使用。MSSQLServer不但可以应用于大中型数据库管理中,建立分布式关系数据库,并且也可以开发桌面数据库。事实上,SQLServer数据库处理的基本结构,采取关系型数据库模式,尽管如此,相信大家都可以轻易的发现,在SQLServer的数据库处理方式,则是使用面向对象的操作方式与精神,也就是说,SQLServer的所有功能,都可以基于系统已经建立好的一些对象来达成,是相当OO(面向对象)的一个系统结构。
SQLServer企业管理器是SQLServer的主要管理工具,它提供了一个遵从MMC标准的用户界面,使用户得以:
·定义SQLServer实例组。
·将个别服务器注册到组中。
·为每个已注册的服务器配置所有SQLServer选项。
·在每个已注册的服务器中创建并管理所有SQLServer数据库、对象、登录、用户和权限。
·在每个已注册的服务器上定义并执行所有SQLServer管理任务。
·通过唤醒调用SQL查询分析器,交互地设计并测试SQL语句、批处理和脚本。
·唤醒调用为SQLServer定义的各种向导。
·
第三章图书管理系统设计分析
§4.1应用需求分析
图书管理系统需要满足来自三方面的需求,这三个方面分别是图书借阅者、图书馆工作人员和图书馆管理人员。图书借阅者的需求是查询图书馆所存的图书、个人借阅情况及个人信息的修改;图书馆工作人员对图书借阅者的借阅及还书要求进行操作,同时形成借书或还书报表给借阅者查看确认;图书馆管理人员的功能最为复杂,包括对工作人员、图书借阅者、图书进行管理和维护,及系统状态的查看、维护并生成催还图书报表。
图书借阅者可直接查看图书馆图书情况,如果图书借阅者根据本人借书证号和密码登录系统,还可以进行本人借书情况的查询和维护部分个人信息。一般情况下,图书借阅者只应该查询和维护本人的借书情况和个人信息,若查询和维护其他借阅者的借书情况和个人信息,就要知道其他图书借阅者的借书证号和密码。这些是很难得到的,特别是密码,所以不但满足了图书借阅者的要求,还保护了图书借阅者的个人隐私。
图书馆工作人员有修改图书借阅者借书和还书记录的权限,所以需对工作人员登陆本模块进行更多的考虑。在此模块中,图书馆工作人员可以为图书借阅者加入借书记录或是还书记录,并打印生成相应的报表给用户查看和确认。
图书馆管理人员功能的信息量大,数据安全性和保密性要求最高。本功能实现对图书信息、借阅者信息、总体借阅情况信息的管理和统计、工作人员和管理人员信息查看及维护。图书馆管理员可以浏览、查询、添加、删除、修改、统计图书的基本信息;浏览、查询、统计、添加、删除和修改图书借阅者的基本信息,浏览、查询、统计图书馆的借阅信息,但不能添加、删除和修改借阅信息,这部分功能应该由图书馆工作人员执行,但是,删除某条图书借阅者基本信息记录时,应实现对该图书借阅者借阅记录的级联删除。并且还应具有生成催还图书报表,并打印输出的功能。
在本系统中由于没有打印机设备供试验,所以预先把报表打印改成报表预览。
设计不同用户的操作权限和登陆方法
对所有用户开放的图书查询
借阅者维护借阅者个人部分信息
借阅者查看个人借阅情况信息
维护借阅者个人密码
根据借阅情况对数据库进行操作并生成报表
根据还书情况对数据库进行操作并生成报表
查询及统计各种信息
维护图书信息
维护工作人员和管理员信息
维护借阅者信息
处理信息的完整性
对借阅过期的图书生成报表
图4-2图书管理系统数据库应用需求的总结
根据以上所做的需求分析,并略掉一些细节(如不考虑用户的登录;对记录的维护),得出以下的三层数据流图。
§4.2系统功能模块划分
系统功能框图如图4-10所示。
§4.3系统数据库设计
4.3.1概念设计
在概念设计阶段中,设计人员从用户的角度看待数据及处理要求和约束,产生一个反映用户观点的概念模式。然后再把概念模式转换成逻辑模式。将概念设计从设计过程中独立开来,使各阶段的任务相对单一化,设计复杂程度大大降低,不受特定DBMS的限制。
利用ER方法进行数据库的概念设计,可分成三步进行:首先设计局部ER模式,然后把各局部ER模式综合成一个全局模式,最后对全局ER模式进行优化,得到最终的模式,即概念模式。
(1)设计局部ER模式
实体和属性的定义:
图书(图书编号,图书名称,作者,出版社,出版日期,备注,价格,数量,)
借阅者(借书证号,姓名,性别,身份证,联系电话,密码)
身份(身份编号,身份描述,最大借阅数)
图书类别(图书类别编号,类别描述)
ER模型的“联系”用于刻画实体之间的关联。一种完整的方式是对局部结构中任意两个实体类型,依据需求分析的结果,考察局部结构中任意两个实体类型之间是否存在联系。若有联系,进一步确定是1:N,M:N,还是1:1等。还要考察一个实体类型内部是否存在联系,两个实体类型之间是否存在联系,多个实体类型之间是否存在联系,等等。联系定义如图4-5所示。解释如下:
u一个借阅者(用户)只能具有一种身份,而一种身份可被多个借阅者所具有;
u一本图书只能属于一种图书类别(类别),而一种图书类别可以包含多本图书;
u一个用户可以借阅多本不同的书,而一本书也可以被多个不同的用户所借阅。
(2)设计全局ER模式
所有局部ER模式都设计好了后,接下来就是把它们综合成单一的全局概念结构。全局概念结构不仅要支持所有局部ER模式,而且必须合理地表示一个完整、一致的数据库概念结构。
1)确定公共实体类型
为了给多个局部ER模式的合并提供开始合并的基础,首先要确定各局部结构中的公共实体类型。在这一步中我们仅根据实体类型名和键来认定公共实体类型。一般把同名实体类型作为公共实体类型的一类候选,把具有相同键的实体类型作为公共实体类型的另一类候眩
2)局部ER模式的合并
合并的原则是:首先进行两两合并;先和合并那些现实世界中有联系的局部结构;合并从公共实体类型开始,最后再加入独立的局部结构。
3)消除冲突
冲突分为三类:属性冲突、结构冲突、命名冲突。
设计全局ER模式的目的不在于把若干局部ER模式形式上合并为一个ER模式,而在于消除冲突,使之成为能够被所有用户共同理解和接受的同一的概念模型。
3)全局ER模式的优化
在得到全局ER模式后,为了提高数据库系统的效率,还应进一步依据处理需求对ER模式进行优化。一个好的全局ER模式,除能准确、全面地反映用户功能需求外,还应满足下列条件:实体类型的个数要尽可能的少;实体类型所含属性个数尽可能少;实体类型间联系无冗余。
综上所述,“图书管理系统”的全局ER模式如图4-13所示。
4.3.2关系数据库的逻辑设计
由于概念设计的结果是ER图,DBMS一般采用关系型(本人所使用的MSSQLServer就是关系型的DBMS),因此数据库的逻辑设计过程就是把ER图转化为关系模式的过程。由于关系模型所具有的优点,逻辑设计可以充分运用关系数据库规范化理论,使设计过程形式化地进行。设计结果是一组关系模式的定义。
(1)导出初始关系模式
book(图书编号#,图书名称,图书类别#,作者,出版社,出版日期,备注,价格,数量)class(图书类别#,类别名)user(借书证号#,姓名,性别,身份编号#,身份证,联系电话,密码)ID(身份编号#,身份描述,最大借阅数)Owner(借书证号#,图书编号#,借书日期)
图4-14关系模式集
(2)产生子模式
子模式是用户所用到的那部分数据的描述。除了指出用户用到的数据外,还应指出数据与概念模式中相应数据的联系,即指出概念模式与子模式之间的对应性。
借书子模式(借书证号#,姓名,图书编号#,图书名称,借书日期)
图4-15部分子模式
(3)根据设计中出现的问题本人在写系统时还加入了ä¸