多对多关系以及多表查询优化处理
前言：这两天机器坏了，正在送修中，写个系列的大型网站架构的文章，希望对有志在互联网做出一番事业的站长朋友们一些帮助。
注意：这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了，我们以高负载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或者.NET环境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架构都是必须要面对的。
文入正题：
首先讨论一下大型网站需要注意和考虑的问题
A. 海量数据的处理。
众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update 就可以解决我们面对的问题，本身负载量不是很大，最多再加几个索引就可以搞定。对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。
B. 数据并发的处理
在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然而在我们进行修改的时候就，如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及缓存策略。
另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。
C. 文件存贮的问题
对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文件按照日期和类型进行存贮。但是当文件量是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是一个巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。如果这个时候还涉及上传，磁盘很容易就over了。
也许用raid和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度如何解决？如果做分布式，那么我们的文件索引以及架构该如何规划。
所以我们不得不承认，文件存贮是个很不容易的问题
D. 数据关系的处理
我们可以很容易的规划出一个符合第三范式的数据库，里面布满了多对多关系，还能用GUID来替换INDENTIFY COLUMN 但是，多对多关系充斥的2.0时代，第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。
E. 数据索引的问题
众所周知，索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是，在高UPDATE的情况下，update和delete付出的成本会高的无法想想，笔者遇到过一个情况，在更新一个聚焦索引的时候需要10分钟来完成，那么对于站点来说，这些基本上是不可忍受的。
索引和更新是一对天生的冤家，问题A，D，E这些是我们在做架构的时候不得不考虑的问题，并且也可能是花费时间最多的问题，
F. 分布式处理
对于2.0网站由于其高互动性，CDN实现的效果基本上为0，内容是实时更新的，我们常规的处理。为了保证各地的访问速度，我们就需要面对一个绝大的问题，就是如何有效的实现数据同步和更新，实现各地服务器的实时通讯有是一个不得不需要考虑的问题。
G. Ajax的利弊分析
成也AJAX，败也AJAX，AJAX成为了主流趋势，突然发现基于XMLHTTP的post 和get是如此的容易。客户端get或者post到服务器数据，服务器接到数据请求之后返回来，这是一个很正常的AJAX请求。但是在AJAX处理的时候，如果我们使用一个抓包工具的话，对数据返回和处理是一目了然。对于一些计算量大的AJAX请求的话，我们可以构造一个发包机，很容易就可以把一个webserver干掉。
H. 数据安全性的分析
对于HTTP协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G问题来说的话，加密的过程就可能是明文了（比如我们知道的QQ，可以很容易的判断他的加密，并有效的写一个跟他一样的加密和解密方法出来的）。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来之后，那么所谓的外挂，所谓的群发就会接踵而来（从qq一开始的群发可见端倪）。也许我们可以很的意的说，我们可以采用更高级别的判断甚至HTTPS来实现，注意，当你做这些处理的时候付出的将是海量的database，io以及CPU的成本。对于一些群发，基本上是不可能的。笔者已经可以实现对于百度空间和qq空间的群发了。大家愿意试试，实际上并不是很难。
I. 数据同步和集群的处理的问题
当我们的一台databaseserver不堪重负的时候，这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问题了，数据基于网络传输根据数据库的设计的不同，数据延迟是很可怕的问题，也是不可避免的问题，这样的话，我们就需要通过另外的手段来保证在这延迟的几秒或者更长的几分钟时间内，实现有效的交互。比如数据散列，分割，内容处理等等问题K．数据共享的渠道以及OPENAPI趋势
Openapi已经成为一个不可避免的趋势，从google，facebook，myspace到海内校内，都在考虑这个问题，它可以更有效的留住用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的途径了，而在开放的接口的情况保证数据的安全性和性能，又是一个我们必须要认真思考的问题了。
当然还有更多需要考虑的问题，我这里就写一个最需要考虑的问题，欢迎补充。
首先澄清上篇中关于几个朋友的评论。
上篇疯狂代码介绍的基于AJAX的攻击很多人提出疑问，比如不能跨域，减轻负担之类。Ajax是通过简单的GET和POST进行数据传递的，采用HTTPDEBUGGER，抓取数据，然后采用如下方案，顺便写个示例的攻击代码．比传统的webform，我们更容易构造一些，其实对于webform和ajax的处理和发包过程是一样的，ajax数据量相对小，速度也快一些。
结合SharpPcap和HttpWebRequest我们构造一个合理的正常的IP数据包过去,代码很长，我们用伪代码简单的表达一下。
request.CreateUrl(Ajax处理页面);
request.Method=”GetORPost”;
request.refere=”网页来源”;
SharpPcap.SetLinkConnection(伪造IP地址);
String content = request.GetResponseStream() 如果作为一个多线程的应用程序对对方的WEB构成批量发包的话（假如是DEDECMS），足可以把Dedecms的数据库搞垮
文入正题：
对于上回书提到要解决问题A，我们先讲解一下电信公司ADSL的布局方案。机器上没有装VISIO，我简单的用文字描述一下流程。
Adsl用户Aè输入用户名密码è远程连接到账户数据库（在天津）è账户数据库连接计费数据库并返回状è如果成功，连接PPPOE服务器，并进一步连接计费数据库è认证服务并连接。
这里没有什么特别的地方，但是和qq通讯服务是一样的，就是采用了统一的用户验证服务器，同时对于用户验证的信息数据库是只读的，我们从其中可以想到什么吗？
以上是个简单的例子，下面开始谈具体的架构策略，首先对于上篇提到的问题A，我们首先以用户数据库为例来做解释和要求。
首先做用户量估算需求，假如我们做的是学术社区，那么这个用户量不会很大，可能我们不需要考虑这个，对于用户量的级别，我们暂时把用户量级别定为三种，百万级别（M）和千万界别（S），以及亿万级别（Q），并考虑用户登录验证以及查询常用的操作，对M和S进行扩充以及了解。
众所周知，在这个情况下，对于用户数据的负载其实并非可行而不可行的问题，而是如何最大化的保证查询和更新以及各个服务器之间的数据同步。这里我们不再讲解如何优化如何索引，只介绍架构初期的方案，下面介绍的方案如果涉及全表查询，可以采用分区视图的方案，大家可以具体搜索相关资料。
对于M级别来说，现有的DBMS经过合理的布局完全可以满足需求。我们需要解决的问题的关键其实是处理IO方面的问题，处理方案相对简单一些，对数据库的FILE文件分磁盘存贮（不是分区，是不同的硬盘），根据负载量大小，我们可以适当的控制硬盘的数量和文件分区的数量。
对于S级别，上个处理方案已经不能完全满足需求了，这个时候我们需要对注册和入库的流程进行简单的修改了，解决方案是数据散列和分区视图的概念，具体概念大家去google一下，我不详细说明了。
我们常用的方案有三种。第一种是等容扩充法，在用户注册控制的基础上，保证每个库的用户容量不超过500万，超过之后入第二个库，以此类推，这个方案可以保证系统有效的扩充性，但不能保证数据被有效的索引。第二种就是共区
索引方案，其实和第一种方案有异曲同工的之说但是讲第一种方案进行了合理的优化，按照用户名进行分库存贮。比如我们可以建立26的数据库，按照用户名的索引来控制用户数据入哪个库。假如用户名是CrazyCoder，那么就讲该用户名的数据存放在用户表C中，在数据存贮的时候可以很方便的根据用户名进行相应的数据查询，方案二可以有效的解决数据索引问题。方案三是一个更具模型化的方案，结合方案一和方案二，进行用户ID的编码，不是INDENTIFY Cloumn，我们用一种序列化的方案将用户名以编码的形式存贮，比如用户名是CrazyCoder,我们的编码方案就是通过算法进行数字化，将CrazyCoder按照C，R,A,….存贮为数字索引，然后进行分区存贮，数字类型的数据在数据库中可以更有效的被查询和被更新和共享，结合方案一和方案二这个就是方案三。
对于Q级别。数据量已经是足够海量了，这个时候无论用哪种方案都是一个让人头大的数据，不能简单的用查询的方案来处理了，可以参考S级别的进行处理。但这个时候我们采用的方案是根据用户活跃度的权值结合数据量进行临时数据表的存放。如果一个非意外的数据情况下，每天登录的用户量不会上千万。这个时候我们需要做的是一个简单的数据代理程序。一个临时的用户验证数据库，每天执行一次批处理，将活跃度高的用户账户提取到临时数据库中，查询的时候先查询临时库，如果没有在进行全库查询。这个根据系统的负载情况来估计阈值，不同的系统估算方案也不尽相同。
上面对于，M,S,Q三种界别进行了简单的概述，下面介绍一个在其之上更高级的一个查询方案，数据缓存服务器，我们也可以把它理解为缓冲服务器，数据做为只读来使用。
具体实现方案如下：以为涉及了海量，DBMS常规的缓存方案已经不符合我们的要求了，那么我们需要一个有效的缓存方案，这个时候处理的流程其实就是讲最常用最直接的数据直接存放在缓存服务器中，而这个缓存服务器定时从主服务器获取并更新信息。这个是一个简单的查询，我们还可以更深入的讲缓存服务器做二次缓存，也就是一次性处理输入并存放到ＬＩＳＴ数据中，作为全局变量放到内存中进行查询，同时用ＨＡＳＨＴＡＢＬＥ或者数组进行数据组索引（可以是多级），根据查询分布到各个变量中。直接从内存中读取数据。
以笔者的经验来说的话，对于ITEM数据不超过10K的来说，每个列表最佳的存放范围是0到6万之间。
这里简单的介绍了一下DBMS基本架构，里面具体细节处理的还有很多，这里只介绍个大概的纲要。有问题请给我发邮件(Heroqst # https://www.doczj.com/doc/d67112575.html,)，请讲#替换为@。
这里只是简单的介绍了一下ＤＢＭＳ的基本布局，下章讲具体对我们常见的多对多关系数据库进行具体配置说明。
首先介绍一下问题的大概，比如对于文章和标签，每个文章可以有多个标签，而每个标签下又会有多个文章，那么数据量将是文章数乘以标签数，这个时候如何进行处理并有效的索引，将是下章要介绍的内容。
疯狂代码，大型网站架构系列，同步发布于(https://www.doczj.com/doc/d67112575.html,和https://www.doczj.com/doc/d67112575.html,) ，转载请注明出处。
上篇以用户数据表为例介绍了基本的数据分割方案以及基本的配置方案。但
是在2.0时代，这种简单的列表索引已经远远实现起来是问题的，多对多关系将是最常见的关系。现在我们针对web2.0数据中广泛存在的多对多关系进行阐述和具体行为判断，比如一个很简单的例子，在2.0时代，好友功能是最常被用到的，每个用户会有很多的好友，同时也会是很多人的好友，那么这个数据量将会是用户数的平方的级别。同样，对于文章标签，每个文章可以有多个标签，而每个标签又可以有多个文章，这又是一个几何乘积，数据量又会是个天文数字。这里不再介绍基于硬件,IO,集群方面的问题，我们以项目开发的角度来实现他。
这里先介绍一个基本的施行方案，而后我们进一步的对它进行扩充以满足我们的以后的具体需求。
对于多对多关系，传统的处理方案有三种，一种是通过SEARCH的方法来实现，第二一种是通过另建一个索引表，存贮对应的ID以进行存贮，第三种是通过二次归档缓冲来实现（本人不知道用什么语言来描述这种处理方法，姑且如此吧）。
对于第一种方案，因为要涉及大量的LIKE查询，性能不敢恭维，基于全文索引的方式可能解决这个问题，但是利用第三方的数据可能未必能适合我们的胃口，我们也可能没有足够的时间和精力来独立开发实现。
第二种的情况下，数据库的行的数量也是惊人海量级别的，维护索引表的散列处理，并且要跨表跨区查询，还要维护数据的唯一性，数据处理过程相当的复杂性能也就不言而喻了。
文入正题，下面以一个简单的例子解释下第三种方案，对数据多对多关系举出来具体的解决方案，我们这里以标签和文章之间的多对多关系为例来讲解，大家可以举一反三的思考群组和用户之间，相册和被圈用户之间等等复杂的多对多关系，如下方案可能不是最好的方案，但是实践证明还是综合时间和开发成本是最合理的。
首先滤清一下流程，在传统的数据库设计中我们是如下走的：当一篇博文发布的时候并插入标签的时候一般是三步走（也可以理解为四步，以为还要判断标签是否存在的问题），第一步插入文章数据库并获取文章的ID，第二步插入标签数据库同时查询标签是否存在，如果存在就取出标签的ID，否则的话插入新标签并取出ID，第三部，将文章的ID和标签的ID插入索引表来建立关联。如果这个时候在索引表上建立了索引的话就是灾难性的，特别是在数据量大的情况下，尽管它可以有效的提高查询速度，但是发布的速度可能就会让人无法忍受了。
我们处理的方法也是四部曲，对多对多关系进行进一步的处理。
用标签的时候，我们用的最多的就是查询标签下的文章和显示文章的标签，所以我们实现这例就成了。
第一步，数据冗余
老生常谈的话题，对文章做冗余，加一个TAG列，我们可以讲TAG的标签如下写[TagID,TagName]| [TagID,TagName]| [TagID,TagName] 同样对于TAG表，我们做如下冗余加个Article字段，如下内容[ArticleID,Title]| [ArticleID, Title]| [ArticleID, Title],在需要增加的时候我们只要APPEND一下就可以了，至于ARTICLE的结构和TAG的结构可以参考我上一篇文章的介绍。其实根据需要还可以存贮更多。
有人会问，为什么要存贮TagName和ArticleTitle呢，其实是为了避免跨表查询和INNERJOIN查询来做的，In查询和跨表查询会造成全表遍历，所以我们在执行的时候In查询是必须要找到一个有效的替代方法的。关于数据冗余的
问题，我们可能还会做的更变态一些，这个后面慢慢说。
第二步：异步存贮。
在设计模式下我们常思考的是单件模式，我们采用另类的单件模式思维来处理，也就是把文章和标签之间的索引作为专门的进程来做，异步的实现。
为了避免文章在发布的时候以为要检查TAG表而造成的线程拥堵，我们需要采取延迟加载的方案来做。服务器应该维护一个进程专业的对标签和文章地段的查询和索引，我们在发布文章的时候应该把标签同步这一块托管给另外的一个进程或者服务器进行处理，并进行索引。
第三步：二次索引：
对于频繁的判断标签去或者热门的标签我们还可以在内存里组织一套有效的索引，比如对于标签“疯狂代码”,我们用树来把它表示出来。对于疯狂代码我们索引一个疯,其实用程序表达就是疯狂代码[0]。而在数组”疯”中存贮以疯开头的标签组，以”傲”的数组中存贮以”傲”开头的标签。如果量更大的话还可以再做N级索引，将这些常用的标签对应设计内存索引，我们可以把它想象的理解为内存中的Suggest（比如google搜索时的Suggest），使用中我们可以直接拿来使用
第四步:针对跨表查询的处理
很多情况下，我们可能避免不了多表查询，或者IN，or查询，除去业务层封装的分区视图集群之外，我们还可以处理的更好，在很多情况下，我们的查询会是非常频繁非常统一的（这里的统一指热门查询），比如在SNS中常见的性别，嗜好等多条件搜索，而这些数据可能存贮在多个数据表结构中，而这样会吧不可避免的会产生全表遍历查询。
处理方法也很简单，把原来散列的垂直分割的表再合并起来，合并到另外的只读的订阅服务器上，然后做适当的结构优化和索引，剩下的大家应该明白我的意思了，虽然简单，但是这种处理方法非常适合以后服务器的横向扩充。
以上是对多对多关系和多表查询的一个简单的架构说明，肯定有人会问，如果这样做的话工作量不是太大了吗，分词处理什么的，对每个多对多关系进行处理。
OK，咱们可以进一步的把它来抽象化，我们用TableA 表示Article表，用TagbleT表示Tag表，我们可以讲字段抽象化出来，也就是一个ID,一个Tag的String 同理对于标签表也是如此。朋友们应该可以理解我的意思了。
对，就是做个代码生成器把对应的多对多关系给生成出来，这个很好写的，几个Append就可以搞定。如果想更方便的处理，那么把这个东西做成单件的模式抽象化出来，然后再违反一下原则，做成基类，其他关系继承这个基类。。。。。剩下的应该很简单了，具体实现大家思考吧。
让并发来的更猛烈些吧，高并发环境下的数据处理方案
对于高并发性质的网站，在sns特别是webgame方面应该是最容易也是最难处理的地方了，容易处理的是如果是纯粹基于数据库驱动也就是select和update的问题，而难的地方也是不是select而是update，在高并发的驱动下，update经常会超时，虽然我们可以在finally把它处理掉，让人郁闷的是，数据库连接池仍然会饱和，数据仍然会丢失….
上面的情况是非常常见的web项目失败的原因之一，在数据飞速膨胀和并发
呈几何级增长的情况下，制约我们的可能是io，database本身的问题了，让我们头痛的是不管是哪种数据库，Oracle也好，mysql也好，sqlserver也好都会timeout，而且是频繁的timeout频繁的Exception。这个时候就需要我们的应用程序在处理的前期就应该考虑到的，一个好的数据缓存策略常常决定了我们的成败，而缓存策略也是web项目最难以测试和最容易出错的地方。
在大型网站架构中，最关键最核心的也是缓存策略了，介于其复杂性，这里只简单的介绍一下基于高并发数据库缓存方案，后面的将详细介绍常用的缓存策略。这个方法与其叫缓存不如叫数据缓冲，其实也是异步更新数据，根据负载情况不同，我们哪怕仅仅将数据缓冲1秒，带来的负载提升就已经非常好了。
实现原理很简单，将并发的更新首先缓存到一个应用程序池中，然后定时查询（注意这里的方案应和缓存方案具体结合，这里只介绍概要情况）。
传统的update请求处理流程是：请求—》应用程序—》更新数据库,如下图：数据缓冲和更新部分可以在数据层里独立实现，也就是update的传递的时候首先传递缓冲池，然后定时更新，这里需要注意的数据缓冲池的还要做的另外一份工作就是全局的数据缓存，缓存数据更新到数据这段的时间间隔，我们可以理解为临时表，再提取上下文请求的即时信息的时候首先从缓冲池里读取（这里有很多技巧，比如巧妙的利用cookie，session做；临界条件判断），流程如下图所示
上面简单的介绍了一下基于数据更新缓存的处理，下篇具体详细介绍基于并发更新机制的详细缓存处理机制
经典表关联与多表查询 目的： 1.掌握从多个表查询数据的基本知识 2.了解和学习外连接(out join) 3.掌握内连接 授课内容： 1.对多于一个表的数据查询 1.1现实情况中，在数据库应用中，数据存在于多个相关联的表中。基本上没有数据只 存在于一个表中的情况。小的应用系统一般也有十几个表，大型系统一般有上千个表。 1.2你经常要作的就是在多个表中进行数据查询。 1.3Oracle对多表查询使用表连接的技术（table join） 1.4表连接的基本条件： (1)2个表必须有公共字段（同名字段或不同名字段） (2)在一个表中，这个公共字段必须是主键（PK） 1.5二个表中的公共字段，在一个表中是主键，在另外一个表中就是外键(FK)。 1.6二表关联中，公共字段是主键的表称为父表（主表）。是外键的表称为子表（详细 表）。 1.7研究一下scott下的emp和dept表的关系。 1.8研究一下oe下的表： CATEGORIES_TAB CUSTOMERS INVENTORIES ORDERS ORDER_ITEMS PRODUCT_DESCRIPTIONS PRODUCT_INFORMATION 1.9多表查询的语法 select 子句 from 表1[ 别名]，表2[ 别名]，视图[ 别名]，（select 子句）别名 where 连接语句 and 其他条件语句 [oupy by 分类项目] [having 子句] [order by 子句] 1.10任务：查询每个员工的编号，姓名，部门名称，部门位置 select empno,ename, dname,loc from emp a,dept b where=
数据库表关系模型解析6——多对多 狼奔代码生成器是一款为程序员设计的前期开发辅助工具，是一个软件项目智能开发的平台，它可以自动生成https://www.doczj.com/doc/d67112575.html,页面及后台代码。 实践开发过程中，我们使用PowerDesigner设计数据库模型。狼奔代码生成器就是读取PowerDesigner设计的数据库模型，分析其中的表与表之间的关系模型，分析其中的表和字段的说明信息中的关键字，自动生成不同的页面。 表与表之间的关系模型包括 1.单表数据模型 2.自连接数据模型 3.一对一数据模型 4.一对多数据模型 5.一对多数据模型中的一张表是自连接 6.多对多数据模型 7.多对多数据模型中的一张表是自连接 关键字包括 1.查询 2.状态 3.上传 4.工作流
架构图 数据访问层(DAL) 数据实体Entity Framework 业务实体和校验元数据 业务逻辑层(BLL) 业务处理 工作流 事务 接口层(IBLL)服务契约 展示层（App ）View （视图） Controller （控制器） Models （页面实体）对其他系统暴露服务Service （服务） 公共组件 安全组件 日志记录 异常捕获 公共类库(Common) 组件说明
图表1项目组件说明图 1)App——页面展示层 采用MVC框架，使用Jquery脚本库，控件选用Easyui。 2)WcfHost——服务宿主(后期扩展) 为对外的服务提供宿主，使用WCF技术，HTTPS通讯协议。 3)IBLL——业务接口层 业务逻辑层的方法对外暴露的接口和服务契约。 4)BLL——业务逻辑层 业务逻辑的操作，包括业务处理，事务，日志。 5)DAL——数据访问层 数据库访问的操作，数据实体，业务实体，数据校验，使用Entity Framework。6)Common——公共组件层 整个应用程序使用的公共辅助方法。 7)WFActivitys——工作流活动层(后期扩展) 定义了工作流需要的活动，使用微软WF技术。 8)WFDesigner——工作流设计器(后期扩展) 可以让实施人员自由配置工作流的设计器，使用微软WPF技术。 采购计划明细和分发的作用 业务需求：将采购计划明细中的物资分发到不同的站点 采购计划明细和分发之间有一张关联表，这三张表就构成了一个典型的“多对多数据模型” 下面我们以分发为例子分析“多对多数据模型”数据模型，代码已在生成的文件中，并且注释详备，此文不再赘述 数据模型 采购计划明细和分发之间是多对多的关系
第四章关系系统及其查询优化 习题 1．试给出各类关系系统的定义：最小关系系统；关系完备上的系统；全关系型的关系系统。 2．试述全关系型系统应满足的十二条准则，以及十二条基本准则的实际意义和理论意义。 3．试述查询优化在关系数据库中的重要性和可能性。 4．对学生-课程数据库有如下的查询： SELECT Cname FROM Student，Course，SC WHERE Student。Sno=SC。Sno AND SC。Cno=Course。Cno AND Student。Sdept=’IS’； 此查询要求信息系学生选修了的所有课程名称。试画出用关系代数表示的语法树，并用关系代数表达式优化算法对原始的语法树进行优化处理，画出优化后的标准优化树。 5．试述查询优化的一般准则。 6．试述查询优化的一般步骤。 参考答案 1．答：最小关系系统。 一个系统可定义为最小关系系统，当且仅当它： （1）支持关系数据库（关系数据结构），从用户观点看，关系数据库由表构成，并且只有表这一种结构 （2）支持选择、投影和（自然）连接运算，对这些运算不必要求定义任何物理存取路径。 关系上完备的系统： 这类系统支持关系数据结构和所有的关系代数操作（或者功能上与关系代数等价的操作）。 全关系型的关系系统： 这类系统支持关系模型的所有特征。即不仅是关系上完备的而且支持数据结构中域的概念，支持实体完整和参照完整性。 2．答：关系模型的奠基人E。F。Codd具体地给出了全关系型的关系系统应遵循的十二条基本准则。从实际意义上看，这十二条准则可以作为评价或购买关系型产品的标准。从理论意义上看，它是对关系数据模型具体而又深入的论述，是从理论和实际紧密结合的高度对关系型DBMSR 评述。 准则0 一个关系型的DBMS必须能完全通过它的关系能力来管理数据库。 准则1信息准则。关系型DBMS的所有信息都应在逻辑一级上用一种方法即表中的值显式地表示。 准则2保证访问准则。依靠表名、主码和列名的组合，保证能以逻辑方式访问关系数据库中的每个数据项（分量值）。 准则3空值的系统化处理。全关系型的DBMS应支持空值的概念，并用系统化的方式处理空值。 准则4基于关系模型的动态的联机数据字典。数据库的描述在逻辑级应该和普通数据采用同样的方式，使得授权用户可以使用查询一般数据所用的关系语言来查询数据库的描述信息。 准则5统一的数据语言准则。 准则6视图更新准则。所有理论上可更新的视图也应该允许由系统更新。 准则7高级的插入、修改和删除操作。 准则8数据物理独立性。无论数据库的数据在存储表示或存取方法上作任何变化，应用程序和终端活动都保持逻辑上的不变性。 准则9数据逻辑独立性。当对基本关系进行理论上信息不受损的任何改变时，应用程序和终端活动都保持逻辑上的不变性。
第9章关系查询处理和查询优化 1．试述查询优化在关系数据库系统中的重要性和可能性。 答：查询优化在关系数据库系统中的重要性： 关系系统的查询优化既是RDBMS实现的关键技术，又是关系系统的优点所在。它减轻了用户选择存取路径的负担。用户只要提出“干什么”，不必考虑如何最好地表达查询以获取较好的效率，而且系统可以比用户程序的“优化”做得更好。 查询优化在关系数据库系统中的可能性： （1）优化器可以从数据字典中获取许多统计信息，例如关系中的元组数、关系中每个属性的分布情况、这些属性上是否有索引（B＋树索引、HASH索引、唯一索引或组合索引）等。优化器可以根据这些信息选择有效的执行计划，而用户程序则难以获得这些信息。 （2）如果数据库的物理统计信息改变了，系统可以自动对查询进行重新优化以选择相适应的执行计划。在非关系系统中必须重写程序，而重写程序在实际应用中往往是不太可能的。 （3）优化器可以考虑数十甚至数百种不同的执行计划，从中选出较优的一个，而程序员一般只能考虑有限的几种可能性。 （4）优化器中包括了很多复杂的技术，这些优化技术往往只有最好的程序员才能掌握。系统的自动优化相当于使得所有人都拥有这些优化技术。 2．对学生-课程数据库有如下的查询：
此查询要求信息系学生选修了的所有课程名称。 试画出用关系代数表示的语法树，并用关系代数表达式优化算法对原始的语法树进行优化处理，画出优化后的标准语法树。 答：学生-课程数据库用关系代数表示的语法树如图9-1所示： 图9-1 关系代数语法树 优化后的标准语法树如图9-2所示：
图9-2 优化后的语法树 3．试述RDBMS查询优化的一般准则。 答：下面的优化策略一般能提高查询效率： （1）选择运算应尽可能先做； （2）投影运算和选择运算同时进行； （3）投影同其前或其后的双目运算结合起来； （4）某些选择同在它前面要执行的笛卡尔积结合起来成为一个连接运算；（5）找出公共子表达式； （6）选取合适的连接算法。 4．试述RDBMS查询优化的一般步骤。
数据库建表-- 一对多/多对一/一对一/多对多关系 关联映射：一对多/多对一存在最普遍的映射关系，简单来讲就如球员与球队的关系；一对多：从球队角度来说一个球队拥有多个球员即为一对多多对一：从球员角度来说多个球员属于一个球队即为多对一数据表间一对多关系如下图： 关联映射：一对一关系就如球队与球队所在地址之间的关系，一支球队仅有一个地址，而一个地址区也仅有一支球队。数据表间一对一关系的表现有两种，一种是外键关联，一种是主键关联。图示如下： 一对一外键关联： 一对一主键关联：要求两个表的主键必须完全一致，通过两个表的主键建立关联关系 关联映射：多对多 多对多关系也很常见，例如学生与选修课之间的关系，一个学生可以选择多门选修课，而每个选修课又可以被多名学生选择。数据库中的多对多关联关系一般需采用中间表的方式处理，将多对多转化为两个一对多。 数据表间多对多关系如下图：
---------------------------------------------------------------------------------------------------------- 前言：多对多关系至少需要3个表，我们把一个表叫做主表，一个叫做关系表，另外一个叫做字典表或者副表（字典表是纪录比较少，而且基本稳定的，例如：版块名称；副表是内容比较多，内容变化的，例如）。按照数据库的增删查改操作，多对多关系的查找都可以用inner join或者 select * from 主表where id in (select 主表id from 关系表) 1，角色任命型 特点：关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键，有一个表是字典类型的表。 界面特点：显示主表，用checkbox或多选select设置多选关系。 例如：任命版主（用户表-关系表-版块名称表），角色权限控制等，用户是5个版块版主，只要关系表5行纪录就可以确立，关系表的两个外键具有联合主键性质。 增加关系：如果没有组合纪录，insert之。 删除关系：如果有组合纪录，删除之。 2，集合分组型 特点：同角色任命型类似，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。区别是主副表都不是字典表，可能都很大不固定。 界面特点：显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。 例如：歌曲专集（专集表-关系表-歌曲表）。手机分组（分组表-关系表-手机表）。用户圈子（圈子表-关系表-用户表）。文章标签（文章表-关系表-标签表） 增加关系：同版主任命型。 删除关系：同版主任命型。 3，明细帐型
多表之间的关系操作总结 经典例子： 一对一：身份证号码与人 一对多：城市与大学，订单与订单项，部门与员工，班级与学生等等。 多对一：一对多的反面。订单项与订单，大学与城市，员工与公司，学生与班级。多对多：学生与老师 一对多：单向、双向。 一对多关系中单向与双向的区别: 单向体现在程序中就是你可以通过一方得到另一方，但不能通过另一方得到这一方双向就是彼此都能得到对方，相互都有关于对方的一个引用。（外键） 什么时候需要用单向，什么时候需要用双向。 网友答： 只需要从一方获取另一方的数据时就使用单向关联 双方都需要获取对方数据时就使用双向关系 部门---人员 使用人员时 如果只需要获取对应部门信息(user.getDeptarment()) 不需要从部门下的人员信息时，就配置成单向多对一 使用部门时 如果只需要获取部门下人员信息(deptartmanet.getUsers()) 不需要从人员获取部门信息时，就配置成单向一对多 既要获取部门下人员 deptartmanet.getUsers() 又要从人员获取部门信息 user.getDeptarment() 那就配置成双向一对多,也就是双向多一
看需求来配置了。 单向多对一”、“单向一对多，其实概念一样，记得在多的一端配置 双向一对多就是两边都要配，做到你中有我我中有你 弄清楚：关系维护端和关系被维护端。 1—m：多的一方是关系维护端，关系维护端负责外键记录的更新，关系被维护端没有权利更新外键字段。 不管是一对多，还是多对一，外键一定建在多的那方。外键一定是另一张表中已经存在的主键。 关于@mappedBy和@JoinColumn 表示声明一对多关系由对方维护，自己将不再维护，就算在自己这端设置值，保存到数据库后外键依然是null @mappedBy注解的作用：在JPA中，在@OneToMany里加入mappedBy属性可以避免生成一张中间表。 网上： a）只有OneT oOne,OneT oMany,ManyToMany上才有mappedBy属性，ManyToOne不存在该属性； b）mappedBy标签一定是定义在the owned side（被拥有方，也叫关系被维护端，即一的一方），他指向theowning side（拥有方，也叫关系维护端，即多的一方）； c）关系的拥有方负责关系的维护，在拥有方建立外键。所以用到@JoinColumn d）mappedBy跟JoinColumn/JoinTable总是处于互斥的一方，可以理解为正是由于拥有方的关联被拥有方的字段存在，拥有方才拥有了被拥有方。mappedBy这方定义JoinColumn/JoinT able总是失效的，不会建立对应的字段或者表。 @JoinColumn所在实体是关系拥有方，name的值即拥有方对应表到参考表的外键名称。@ mappedBy所在实体是关系的被拥有方，value值owner中表示被拥有类的属性。 举例子：创建两个实体类 一对多时，建立实体类时：一的一方需要一个Set或者List集合存储多的对象，多的一方需要定义一个一的对象。需要设置外键的一方需要加上@JoinColoumn注解。 例子： 城市与大学：一对多
关系查询处理和查询优化小结 一．关系查询优化的概述 1. 查询优化在关系数据库中的重要性及必要性 关系系统的查询优化既是 RDBMS实现的关键技术又是关系系统的优点所在。它减轻了用户选择存取路径的负担。查询优化极大地影响RDBMS的性能。用户只要提出“干什么”，不必指出“怎么干”。查询优化的优点不仅在于用户不必考虑如何最好地表达查询以获得较好的效率，而且在于系统可以比用户程序的“优化’夕做得更好。 2.查询优化的可能性和优点 1)优化器可以从数据字典中获取许多统计信息，而用户程序则难以获得 这些信息 2)如果数据库的物理统计信息改变了，系统可以自动对查询重新优化以 选择相适应的执行计划。在非关系系统中必须重写程序，而重写程序在实际应用中往往是不太可能的。 3)优化器可以考虑数百种不同的执行计划，程序员一般只能考虑有限的 几种可能性。 4)优化器中包括了很多复杂的优化技术，这些优化技术往往只有最好的程序员才能掌握。系统的自动优化相当于使得所有人都拥有这些优化技术；3.查询优化的一般准则 ( l ）选择运算应尽可能先做； ( 2 ）把投影运算和选择运算同时进行； ( 3 ）把投影同其前或其后的双目运算结合起来执行； ( 4 ）把某些选择同在它前面要执行的笛卡儿积结合起来成为一个连接运算；( 5 ）找出公共子表达式； ( 6 ）选取合适的连接算法。 4. 查询优化的一般步骤 ( l）把查询转换成某种内部表示，通常用的内部表示是语法树。
( 2）把语法树转换成标准（优化）形式。即利用优化算法，把原始的语法树转换成优化的形式。 ( 3）选择低层的存取路径。 ( 4）生成查询计划，选择代价最小的。 5.代价模型 一般DBMS采用基于代价的优化算法： 集中式数据库 单用户系统 总代价 = I/O代价 + CPU代价 多用户系统 总代价 = I/O代价 + CPU代价 + 内存代价 分布式数据库 总代价 = I/O代价 + CPU代价[+ 内存代价] + 通信代价 二．关系数据库查询优化方法 1.代数优化 关系代数表达式等价指用相同的关系代替两个表达式中相应的关系所得到的结果是相同的 1）查询树启发式优化，一般规则有 选择运算应尽可能先做(最重要，最根本) 目的：减小中间关系 投影运算和选择运算同时做 目的：避免重复扫描关系 将投影运算与其前面或后面的双目运算结合 目的：减少扫描关系的遍数 在执行连接操作前对关系适当进行预处理 按连接属性排序 在连接属性上建立索引 某些选择运算＋在其前面执行的笛卡尔积 ===> 连接运算 2）查询树的启发式优化—算法 （1）分解选择运算 （2）通过交换选择运算，将其尽可能移到叶端 （3）通过交换投影运算，将其尽可能移到叶端 （4）合并串接的选择和投影，以便能同时执行或在一次扫描中完成 （5）对内结点分组 （6）生成程序
学科实验报告 班级2010级金融姓名陈光伟学科管理系统中计算机应用实验名称数据库的创建与表间关系的各种操作 实验工具Visual foxpro 6.0 实验目的1、掌握数据库结构的创建方式 2、表间的关联关系 实验步骤一、建立数据库。 1、在项目管理器中建立数据库。首先选择数据库，然后单击“新建”建立数据库，出现的界面提示用户输入数据库的名称，按要求输入后单击“保存”则完成数据库的建立，并打开i“数据库设计器”。 2、从“新建”对话框建立数据库。单击工具栏上的“新建”按钮或者选择菜单“文件——新建”打开“新建”对话框，首先在“文件类型”组框中选择“数据库”，然后单击“新建文件”建立数据库，后面的操作和步骤与1相同。 3、用命令交互建立数据库。命令是create database【databasename ▏？】 二、表间关系的各种操作。 1、创建索引文件。可以再创建数据表时建立其结构复合索引文件，但是也可以先建立好数据表，以后再创建或修改索引文件。 2、索引的操作。A、打开与关闭。要使用索引，必须先要打开索引。一旦数据表文件关闭所有相应的索引文件也就自动关闭了。B、确定主控索引。可以使用命令确定当前主控索引。命令格式1：set order to 【tag】<索引标识>【ascending| desceding】命令格式2：use<表文件名>order【tag】<索引标识>【ascending | esceding】C、删除索引标识。要删除结构复合索引文件中的索引标识，应当打开数据表文件，并打开其表设计器对话框。在“索引”页面中选定要删除的索引标识后，单击“删除”按钮删除。 3、创建关联。在创建数据表之间的关联时，把当前数据表叫做父表，而把要关联的表叫做子表。必须保证两个要建立关系的数据表中存在能够建立联系的同类字段；同时要求每个数据表事先分别以该字段建立了索引。A、建立表间的一对一的关系。在“数据库设计器”窗口中选择M表中的字段，并按住左键拖到关联表H中对应字段上，放开鼠标左键。这是可以看到在两个表之间的相关字段上产生了一条连线，表明两个表之间已经建立了“一对一”关系。B、建立表间一对多的关系。将M表的名称字段MC设定为主索引，或者候选索引；H表中的JG字段已经设置成普通索引。在“数据库设计器”窗口中将MC字段拖到关联表中对应字段JG上，放开鼠标左键。这时可以看到在两个表之间的相关字段上产生了一条显然与“一对一”关联不同形式的连线，表明两个表之间已经建立了“一对多”关系。 4、调整或删除关联。A、删除关联。在数据库设计器对话框窗口中，首先必须用鼠标左键单击关联线，该连线变粗了说明它已被选中。如果要删除可敲【del】。也可以单击鼠标右键在弹出对话框窗口中单击“删除关联”选项。B、编辑关联。在数据库设计器对话框窗口中，首先必须用鼠标左键单击关联线，该连线变粗了说明已被选中。在主菜单“数据库”选项的下拉菜单中的“编辑关系”选项，也可以单击鼠标右键在弹出对话框窗口中单击“编辑关系”选项。 5、设置数据表之间的参照完整性。在对数据库表建立关联关系后，就可以设置两个相关数据表之间操作的有效性原则。这些规则可以控制相关表中的记录的插入、删除或修改。
一对多的自身关联 一的一方和多的一方都属于同一个类 这种结构就类似于树状结构 每一个对象内部本身包括 一个父节点对象(此时这个原本的对象对于这个父节点对象是多对一的关系) 一个子节点的集合(此时这个对象对于子节点集合来说又是一对多的关系） 创建表 create table creature( id bigint primary key, name varchar(15), parent_creature_id bigint ); 一对一关联第一种关联方式通过一个表的主键由另一个表来产生 第一张表 create table husband( id varchar(100) primary key,
name varchar(100) default '' )character set utf8 collate utf8_general_ci;---能插入中文字符 create table wife( id varchar(100) primary key, name varchar(100) default '' )character set utf8 collate utf8_general_ci; Husband.hbm中uuid方式产生主键
第 4 章关系系统及其查询优化 1. 试给出各类关系系统的定义：最小关系系统；关系上完备的系统；全关系型的关系系统。 2. 试述全关系型系统应满足的十二条准则，以及十二条基本准则的实际意义和理论意义。 3. 试述查询优化在关系数据库系统中的重要性和可能性。 4. 试述查询优化的一般准则。 5. 试述查询优化的一般步骤。 答案 1．最小关系系统：一个系统可定义为最小关系系统，当且仅当它： （1）支持关系数据库（关系数据结构）。从用户观点看，关系数据库由表构成，并且只有表这一种结构。 （2）支持选择、投影和（自然）连接运算，对这些运算不必要求定义任何物理存取路径。 关系上完备的系统：这类系统支持关系数据结构和所有的关系代数操作（或者功能上与关系代数等价的操作）。 全关系型的关系系统：这类系统支持关系模型的所有特征。即不仅是关系上完备的而且支持数据结构中域的概念，支持实体完整性和参照完整性。 2．关系模型的奠基人 E.F.Codd 具体地给出了全关系型的关系系统应遵循的十二条基本准则。从实际意义上看，这十二条准则可以作为评价或购买关系型产品的标准。从理论意义上看，它是对关系数据模型的具体而又深入的论述，是从理论和实际紧密结合的高度对关系型DBMS 的评述。 准则 0 一个关系型的 DBMS 必须能完全通过它的关系能力来管理数据库。 准则 1 信息准则。关系型 DBMS 的所有信息都应在逻辑一级上用一种方法即表中的值显式地表示。 准则 2 保证访问准则。依靠表名、主码和列名的组合，保证能以逻辑方式访问关系数据库中的每个数据项 ( 分量值 ) 。 准则 3 空值的系统化处理。全关系型的 DBMS 应支持空值的概念，并用系统化的方式处理空值。 准则 4 基于关系模型的动态的联机数据字典。数据库的描述在逻辑级上应该和普通数据采用同样的表示方式，使得授权用户可以使用查询一般数据所用的关系语言来查询数据库的描述信息。 准则 5 统一的数据子语言准则。 准则 6 视图更新准则。所有理论上可更新的视图也应该允许由系统更新。 准则 7 高级的插入、修改和删除操作。 准则 8 数据物理独立性。无论数据库的数据在存储表示或存取方法上作任何变化，应用程序和终端活动都保持逻辑上的不变性。 准则 9 数据逻辑独立性。当对基本关系进行理论上信息不受损害的任何改变时，应用程序和终端活动都保持逻辑上的不变性。 准则 l0 数据完整性的独立性。关系数据库的完整性约束条件必须是用数据库语言定义并存储在数据字典中的，而不是在应用程序中加以定义的。 准则 11 分布独立性。关系型 DBMS 具有分布独立性。 准则 12 无破坏准则。如果一个关系系统具有一个低级 ( 指一次一个记录 ) 语言，则这个低级语言不能违背或绕过完整性准则。
第九章关系查询处理和查询优化 内容概述 通过实例讲解关系数据库查询优化的重要性和可能性。讲解RDBMS的查询处理步骤，即查询分析、查询检查、查询优化和查询执行；查询优化的基本概念，查询优化包括代数优化和物理优化；代数优化是指关系代数表达式的优化；物理优化则是指存取路径和底层操作算法的选择，所以先讲解实现查询操作的主要算法，主要是选择操作和连接操作的主要算法思想，然后讲解关系代数表达式等价变换规则，关系代数表达式的优化，物理优化方法（基于启发式规则的存取路径选择优化，操作算法的执行代价估算方法，基于代价的优化方法）。 本章目标 本章并不要求学生掌握RDBMS查询处理和查询优化的内部实现技术，因此没有详细讲解技术细节。 本章的目的是希望学生了解RDBMS查询处理的基本步骤，查询优化的概念、基本方法和技术，为数据库应用开发中利用查询优化技术提高查询效率和系统性能打下基础。 重点和难点 重点：了解关系数据库查询优化的重要性。掌握查询处理各个步骤的主要功能。能够把SQL语句转换成查询树，对查询树进行代数优化，转换成优化的查询树。掌握物理优化的基本方法。 难点：能运用本章学习的查询优化知识，对于比较复杂的查询，尤其是涉及连接和嵌套的查询，写出适合
RDBMS自动优化的SQL语句。对于RDBMS不能优化的查询需要重写查询语句，进行手工调整以优化性能。不要把优化的任务全部放在RDBMS上。 实验内容 实验9 查询优化通过本章实验，了解你安装使用的RDBMS的查询优化方法和查询计划表示，能够利用它分析查询语句的实际执行方案和查询代价，进而通过建立索引或者修改SQL语句来降低查询代价，达到优化系统性能的目标。 具体实验内容： 1. 对单表查询例如以下的查询(可以自己给出查询语句) select * from student where age>20； 2. 连接查询，普通的两表连接查询或多表连接查询 3. 嵌套查询，自己写几个带有子查询的例子，主要考虑带有IN和EXISTS谓词的子查询，包括相关子查询和不相关子查询。也可以使用《数据库系统概论》书上列举的例子。 对以上各种查询，通过建立索引或者删除索引（单表查询语句）、修改连接顺序（连接查询语句）、重写SQL语句即查询重写(嵌套查询)；比较不同查询计划执行的性能差异，达到降低查询代价，优化性能的目标。
例： Person表和Dept部门表 一个部门里可以有多个person 一对多的关系 多个person可以属于同一个部门多对一的关系 public class Person { private Integer id; private String name; private int sex; private String degree; private Date birthday; private int salary=10000; private Dept dept; //与Dept表的关联 } public class Dept { private Integer id; private String deptName; private Set
none: 所有情况下均不进行关联操作。这是默认值。 save-update: 在执行save/update/saveOrUpdate时进行关联操作。 delete: 在执行delete 时进行关联操作。 Dept.hbm.xml
一单项选择题 1 设E是关系代数表达式，F1，F2是选取条件表达式，则有______。 A σF1（σF2（E））≡σF1∨F2（E） B σF1（σF2（E））≡σF1∧F2（E） C σF1（σF2（E））≡σF1（E） D σF1（σF2（E））≡σF2（E） 2 设E是关系代数表达式，F是选取条件表达式，并且只涉及A1，…，An属性，则有____。 A σF（πA1，…，An（E））≡πA1，…，An（σF（E）） B σF（πA1，…，An（E））≡πA1，…，An（E） C σF（πA1，…，An（E））≡πA1（σF（E）） D πA1，…，An（σF（E））≡πA1，…，An（σF（πA1，…，An，B1，…Bm（E））） 3 如果条件F形为F1∧F2，F1仅涉及到E1中的属性，F2仅涉及到E2中的属性，则有_____。 A σF（E1×E2）≡σF1（E1）×σF2（E2） B σF（E1×E2）≡σF1（σF1（E1）×σF2（E2）） C σF（E1×E2）≡σF2（σF1（E1）×σF2（E2）） D σF（E1×E2）≡σF1（E2）×σF2（E1） 4 如果一个系统定义为关系系统，则它必须___________。 A 支持关系数据库 B 支持选择、投影和连接运算 C A和B均成立 D A和B都不需要 5 如果一个系统为表式系统，则它支持__________。 A 关系数据结构 B A与选择、投影和连接运算 C A与所有的关系代数操作 D C与实体完整性、参照完整性 6 如果一个系统为关系完备系统，那么它支持___________。 A 关系数据结构 B A与选择、投影和连接运算 C A与所有的关系代数操作 D C与实体完整性、参照完整性 7 如果一个系统为全关系系统，那么它支持___________。 A 关系数据结构 B A与选择、投影和连接运算 C A与所有的关系代数操作 D C与实体完整性、参照完整性 8 关系代数表达式的优化策略中，首先要做的是__________。 A 对文件进行预运算 B 尽早执行选择运算 C 执行笛卡尔积运算 D 投影运算 9 在关系代数运算中，最费时间和空间的是_________________。 A 选择和投影运算 B 除法运算 C 笛卡尔积和连接运算 D 差运算 10 在关系代数表达式的等价优化中，不正确的叙述是____________。 A 尽可能早的执行连接运算 B 尽可能早的执行选择运算 C 尽可能早的执行投影运算 D 把笛卡尔积和随后的选择合并成连接运算 11 根据系统所提供的存取路径，选择合理的存取策略，这种优化方式称为__________。 A 物理优化 B 代数优化 C 规则优化 D 代价估算优化 二填空题 1 关系系统的查询优化既是关系数据库管理系统实现的关键技术，又是关系系统的优点。因为用户只要提出_____________，不必指出______________。 2 在关系代数运算中，___________和__________________运算最费时间和空间。究竟应采用什么样的策略才能节省时间和空间，这就是优化的准则。
第四章 关系查询处理和查询优化 1、给出各类关系系统的定义：最小关系的系统；关系完备的系统；全关系型的 关系系统。答：(最小)关系系统：仅支持关系数据结构和三种关系操作。许多 微机关系数据库系统如FoxBASE，FoxPro等就属于这一类。 关系完备的系统： 这类系统支持关系数据结构和所有的关系代数操作(功能 20世纪90年代初的许多关系数据库管理系统属于这一类。 上与关系代数等价)。 全关系系统：这类系统支持关系模型的所有特征。即不仅是关系上完备的 而且支持数据结构中域的概念，支持实体完整性和参照完整性。目前，大多数 关系系统已不同程度上接近或达到了这个目标。 2、试述查询优化在关系数据库系统中的重要性和可能性。 答：查询优化在关系数据库系统中有着非常重要的地位。关系数据库系统和 非过程化的SQL语言能够取得巨大的成功， 关键是得益于查询优化技术的发展。 关系查询优化是影响RDBMS性能的关键因素。 优化对关系系统来说既是挑战又是机遇。所谓挑战是指关系系统为了达到用户 可接受的性能必须进行查询优化。由于关系表达式的语义级别很高，使关系系 统可以从关系表达式中分析查询语义，提供了执行查询优化的可能性。这就为 关系系统在性能上接近甚至超过非关系系统提供了机遇。 3．对学生-课程数据库有如下的查询： 查询信息系学生选修的所有课程名称: SELECT Cname FROM St,Course,SC WHERE St.Sno=SC.Sno AND https://www.doczj.com/doc/d67112575.html,o=https://www.doczj.com/doc/d67112575.html,o AND St.Sdept=’IS’ 试画出用关系代数表示的语法树，并用关系代数表达式优化算法对原始的语法 树进行优化处理，画出优化后的标准语法树。 答：关系代数表达式如下： πcname(бSt.sdept=’IS’(бst.sno=sc.Sno(бhttps://www.doczj.com/doc/d67112575.html,o=https://www.doczj.com/doc/d67112575.html,o(ST×SC ×COURSE))) 用关系代数表示的语法树如下左图： πcname πcname бSt.sdept=’IS’ бhttps://www.doczj.com/doc/d67112575.html,o=https://www.doczj.com/doc/d67112575.html,o бst.sno=sc.Sno × бsc．Cno=https://www.doczj.com/doc/d67112575.html,o бSt.sno=sc.sno πcno,cname × × Course × Course πsno πsno,cno St Sc St.sdept=’IS’ Sc St 用关系代数表达式优化算法对原关系代数表达式进行优化，优化后的关系
数据库设计多对多关系的几种形态(转) 前言：多对多关系至少需要3个表，我们把一个表叫做主表，一个叫做关系表，另外一个叫做字典表或者副表（字典表是纪录比较少，而且基本稳定的，例如：版块名称；副表是内容比较多，内容变化的，例如）。按照数据库的增删查改操作，多对多关系的查找都可以用inner join或者select * from 主表where id in (select 主表id from 关系表) 1，角色任命型 特点：关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键，有一个表是字典类型的表。 界面特点：显示主表，用checkbox或多选select设置多选关系。 例如：任命版主（用户表-关系表-版块名称表），角色权限控制等，用户是5个版块版主，只要关系表5行纪录就可以确立，关系表的两个外键具有联合主键性质。 增加关系：如果没有组合纪录，insert之。 删除关系：如果有组合纪录，删除之。 2，集合分组型 特点：同角色任命型类似，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。区别是主副表都不是字典表，可能都很大不固定。 界面特点：显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。 例如：歌曲专集（专集表-关系表-歌曲表）。手机分组（分组表-关系表-手机表）。用户圈子（圈子表-关系表-用户表）。文章标签（文章表-关系表-标签表） 增加关系：同版主任命型。 删除关系：同版主任命型。 3，明细帐型
特点：关系表可以有重复纪录，关系表一般有时间字段，有主键，可能还有文字型的字段用来说明每次发生关系的原因（消费）。 界面特点：显示关系表，用radio或下拉设置单选关系。 例如：现金消费明细帐或订单（用户表-订单表-消费原因表），用户可能多次在同一事情上重复消费。积分变化纪录也属于这类。 增加关系：不管有没有组合纪录，insert之，纪录时间。 删除关系：根据关系表PK删除。 4，评论回复型 特点：同明细帐型关系表一般有时间字段，有主键，区别是重点在文字型的字段用来说明每次发生关系的内容（评论回复）。 界面特点：回复文本框。 例如：论坛回复（用户表-回复表-帖子表），用户可能多次在不同帖子上评论回复费。 增加关系：不管有没有组合纪录，insert之，纪录时间和文字。 删除关系：根据关系表（回复表）PK删除。 5，站内短信型 特点：主副表是同一个，关系表一般有时间字段，有主键，重点在关系表文字型的字段用来说明每次发生关系的内容（消息）或者其他标记位来表示文字已读状态时间等。 界面特点：回复文本框。 例如：站内短信（用户表-短信表-用户表），用户可能给用户群发或者单发，有标记位来表示文字已读状态时间等。 增加关系：不管有没有组合纪录，insert之，纪录时间和文字。 删除关系：根据关系表（回复表）PK删除。 6，用户好友型
第四章数据库与表的基本操作 实验4－1 数据库及表的操作 （一）实验目的 1．掌握创建数据库的基本操作方法。 2．熟练掌握创建表结构和输入记录的操作方法。 3．熟练掌握修改表结构、浏览和修改表记录数据的操作。 4．熟练掌握建立索引的操作。 5．掌握创建表间联系的操作。 （二）实验内容及步骤 1．创建数据库 【实例4－1】在实验2－1所建立的“教学管理.pjx”项目中，创建一个“学生成绩.dbc”数据库。 操作步骤如下： （1）打开“教学管理.pjx”项目。 （2）在“项目管理器”窗口中，选择“数据库”，然后单击“新建”按钮，打开“新建数据库”对话框，单击其中的“新建数据库”按钮，打开“创建”对话框，如图4－1所示。 图4－1“创建”对话框 （3）在“保存在”文本框中，选择保存数据库的文件夹“程序VX”；在“数据库名”文本框中，输入数据库名称“学生成绩”。 （4）单击“保存”按钮，即在指定位置建立一个“学生成绩.dbc”数据库文件。 此时，在VFP主窗口中弹出一个“数据库设计器”窗口，同时还激活了“数据库设计器”工具栏，如图4－2所示。
18 数据库应用学习与实训指导 图4－2“数据库设计器”窗口 2．创建数据表 【实例4－2】在“教学管理.pjx”项目中，创建学生表（Student.dbf）、成绩表（Grade.dbf）、课程表（Course.dbf）、授课表（Teach.dbf）和教师表（Teacher.dbf）。各个表的结构和数据记录如图4－3、图4－4、图4－5、图4－6、图4－7、图4－8、图4－9、图4－10、图4-11和图4－12所示。 图4－3学生表（Student.dbf）的结构 图4－4学生表（Student.dbf）的记录浏览窗口
SQL多表连接 应用背景 数据库是由多张表组成的存储结构，并通过多张表之间的关系建立起完整的有效的数据存储形式，形成关系型数据库。作为数据查询语言SQL，提供了功能强大的数据表连接查询功能，使多张表格之间形成有效的数据联系，使得关系数据库在大型数据库应用中占据了主角地位。 一个普通的大型数据库应用程序所使用的数据库中，有多达几百张表的数据，那么如何将这些表高效的有机的联系起来，就成为设计关系数据库的一个重要指标。优良的数据库设计指标包括： 1．减少数据冗余，去除掉多余的数据冗余，可以通过建立表之间的连接关系完成。 2．数据更新正确，不能因为表之间存在关系后，使得更新记录出现不正常的数据。 3．添加数据正常，添加数据过程中，应该保持数据表之间的关系，确定表之间的连接。 4．查询简便灵活，在建立数据连接的查询过程中，连接清晰简便，操作灵活准确。 数据库设计是应用软件成功与否的一项重要标志。设计数据库，除与系统分析结果，设计员的水平等有关外，还可以参考一些规范的设计范式，下面简单介绍数据库的2个基本设计范式： 1．第一范式：要求表的每列都是不可再分的简单数据项，所以1对N 关系就必须用多表表示，而不能用一张表表示。 2．第二范式：表中的每一个非主键列必须完全函数依赖于主键，就是说表中除主键之外的其他列，都必须通过主键能够唯一确定。 数据库的设计非常复杂，没有一成不变的东西，需要就地取材，解决问题，简单化问题。 知识要点 (1) 传统连接 连接就是将多个表中的数据连接到一起的查询，即连接操作可以在一个Select语句中完成从多个表中查找和处理数据，使用连接时可以使用名字相同的不同表的列，也可以不同，但要求连接的列不需可连接，即数据类型相同。 传统的连接语法如下： Select * from Tblname1 T1,Tblname2 T2 where T1.column=T2.column 连接SQL语句的明显标志为在From子句后边，有多个表Tblname1,