欢迎来到毕设资料网! | 帮助中心 毕设资料交流与分享平台
毕设资料网
全部分类
  • 毕业设计>
  • 毕业论文>
  • 外文翻译>
  • 课程设计>
  • 实习报告>
  • 相关资料>
  • ImageVerifierCode 换一换
    首页 毕设资料网 > 资源分类 > DOCX文档下载
    分享到微信 分享到微博 分享到QQ空间

    数据库设计外文翻译

    • 资源ID:125611       资源大小:41.92KB        全文页数:13页
    • 资源格式: DOCX        下载积分:100金币
    快捷下载 游客一键下载
    账号登录下载
    三方登录下载: QQ登录
    下载资源需要100金币
    邮箱/手机:
    温馨提示:
    快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
    如填写123,账号就是123,密码也是123。
    支付方式: 支付宝   
    验证码:   换一换

     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。

    数据库设计外文翻译

    1、湖北大学本科毕业论文(设计)外文翻译 外文翻译: 索 引 原文来源 : Thomas Kyte Expert Oracle Database Architecture 2nd Edition 译文正文 : 什么情况下使用 B*树索引 ? 我并不盲目地相信“法则” (任何法则都有 例外 ), 对于什么时候该用 B*索引,我没有经验可以告诉你。为了证明为什么这个方面我无法提供 任何经验, 下面给出两种等效作法 : 使用 B*树索引,如果你想通过索引的方式去获得表中所占比例很小的那些行。 使用 B *树索引,如果你要处理的表和索引许多可以代替表中使用的行 。 这些规则似乎提供相互矛盾的意见,但在现实

    2、中,他们不 是这样的 ,他们只是涉及两个极为不同的情况。有两种方式使用上述意见给予索引 : 作为获取表中某些行的手段。你将读取索引去获得表中的某一行。在这里你想获得表中所占比例很小的行。 作为获取查询结果的手段。 这个索引包含足够信息来回复整个查询 ,我们将不用去查询全表。 这个索引将作为该表的一个 瘦 版本。 还有其他方式 例如,我们使用索引去检索表的所有行,包括那些没有建索引的列。这似乎违背了刚提出的两个规则。这种方式获得将是一个真正的交互式 应用 程序。 该应用中,其中你 将获取 其中的某些行, 并展示它们,等等。你想获取的是针对初始响应时间的查询优化,而不是针对整个查询吞吐量的。 在第

    3、一种情况(也就是你想通过索引获得表中一小部分的行)预示着如果你有一个表 T(使用与早些时候使用过的相一致的表 T) ,然后你获得一个像这样查询的执行计划: ops$tkyte%ORA11GR2 set autotrace traceonly explain ops$tkyte%ORA11GR2 select owner, status 2 from t 3 where owner = USER; Execution Plan - Plan hash value: 1049179052 - | Id | Operation | Name | Rows | Bytes | - | 0 | SELE

    4、CT STATEMENT | | 2120 | 23320 | | 1 | TABLE ACCESS BY INDEX ROWID |T | 2120 | 23320 | | *2 | INDEX RANGE SCAN | DESC_T_IDX | 8 | | - Predicate Information (identified by operation id): - 2 - access(SYS_OP_DESCEND(OWNER)=SYS_OP_DESCEND(USER!) filter(SYS_OP_UNDESCEND(SYS_OP_DESCEND(OWNER)=USER!) 你应该访问

    5、到该表的一小部分。这个问题在这里看是 INDEX (RANGE SCAN) 紧跟在湖北大学本科毕业论文(设计)外文翻译 TABLE ACCESS BY INDEX ROWID 之后。这也意味着 Oracle 先读取索引,然后获取索引项。该索引项将执行一个数据库块读(逻辑或者物理的 I/O)去获取行数据。如果你 想通过索引去访问数据表 T 中的大部分数据,这不是最高效的方式 (我们将很快定义什么是大部分的数据) 。 第二种情况,(也就是你想通过索引去代替表),你将通过索引去处理 100%(事实上可以是任何比例)的行。也许你想通过索引索引去获得一个缩小版的表。接下来的查询证明了这种方式: ops$

    6、tkyte%ORA11GR2 select count(*) 2 from t 3 where owner = user; Execution Plan - Plan hash value: 293504097 - |Id | Operation. | Name | Rows | Bytes .| Cost (%CPU)| Time | - | 0 | SELECT STATEMENT | | 1 | 6 | 17 (0) | 00:00:01 | | 1 | SORT AGGREGAT E | | 1 | 6 | . | .| | * 2 | INDEX RANGE SCAN | T_IDX

    7、 | 2 120 | 12720 | 17 (0) | 00: 00: 01 | - Predicate Information (identified by operation id): - 2 - access(OWNER=USER!) 这里 ,仅仅是使用索引去作为查询的返回集 -现在再也不在乎我们 只通过索引的方式, 想访问多少比例的 行。从执行计划中可以看到,查询语句从未访问过表,仅仅扫描 索引结构本身。 理解两种概念的区别很重要。当 执行 TABLE ACCESS BY ROWID 操作 时,我们必须确保仅访问表中一小部分的块,也就相当于仅访问一小部分的行或者是尽量块地获取第一的数据

    8、。(最终的用户将会为了这几行数据等得不耐烦的)。如果想通过访问比较高比例的行(所占比例高于 20%),使用 B*索引的话,它将花费比全表扫描更多的时间。 使用第二种查询方式,那些在索引中可以找到所需结果的,情况就完全不同了。我们读取索引块,然后拾取其中的很多行 进行处理 , 如此继续下一个索引块,从不访问表。某些情况下,还可以在索引上执行一个快速全面扫描。快速全面扫描是指,数据库不按特定的顺序读取索引块,只是开始读取它们。这里不再是将索引只当一个索引,此时更像是一个表。如果采用全表扫描,将不会按索引项来顺序获取行。 一般来讲, B*树索引将会被放在查询时频繁使用的列上。而且我们希望从表中只返回

    9、少量的数据或者最终用户的请求想立即得到反馈。在一个瘦表(也就是一个含有很少 的列或者列很小) 中,这个比例 可能很小。 一个查询 ,使用该索引应该 可以在表中取回约 2% 3%或更少的行。在一个胖表(也就是含有很多列或者列很宽) 中,这个比例将一直上升到该表的 20%25%。以上建议并不对每个人都有作用。这个比例并不直观,但很精确。索引根据索引键进行排序存储。索引会按键的有序顺序进行访问。索引指向的块都随机存储在堆中。因此,我们通过索引访问表时,会执行大类分散、随机的 I/O。这里的“分散”是指,索引会告诉我们读取块 1,然后是块1000,块 205,块 1,块 1032,块 1 等等。它们不

    10、会要求我们按 照块 1,块 2 然后块 3 的方式。我们将以一种非常随意的方式读取和重新读取块,这种块 I/O 可能非常慢。 湖北大学本科毕业论文(设计)外文翻译 让我们看一下简化版的例子,假设我们通过索引读取一个瘦表,而且要读取表中的 20%的行。若这个表中有 100000 行,这个表得 20%就是 20000 行。如果行大小约为 80 个字节,在一个块大小为 8KB 的数据库中,我们将在每个块中获得 100 行数据。这也就意味着这个表有 1000 个块。 了解这些,计算起来就很容易了。我们想通过索引去读取 2000 行,这也就意味着几乎相当于 20000 次的 TABLE ACCESS B

    11、Y ROWID 操作。这将导致执行这个操作要处理 20000 个表块。不过,这个表总共才只有 1000 块。我们将对表的每个块要执行读和处理 20 次。即时把行的大小提高到一个数量级,达到每行 800 字节,这样每块有 10 行,那样这个表现在有 10000 块。要通过索引 20000 行,仍要求我们把每一块平均读取 2 次。在这种情况下,全表扫描就比使用索引高效得多。因为每个块只会命中一次。如果把查询使用这个索引 来访问数据,效率都不会高,除非对应 800 字节的行,平均只访问表中不到 5%的数据(这样一来,我们访问的大概为 5000 块),如果是 80 字节的行,则 访问的数据应当只占更小

    12、的百分比(大约 0.5%或更少)。 什么情况下使用位图索引 ? 位图索引是最适合于低相异基数数据的情形(也就是说,与整个数据集得基数相比,这个数据只有很少几个不同的值)。对此作出量化是不太可能的 换句话说,就是很难定义这个低相异基数数据有到底多么不同。在一个有几千条记录的数据集中, 2 就是一个低相异基数,但是在一个只有两行记录的数据表中, 2 就不再是低相异基数了。而在一个上千万或者上亿条记录的表中,甚至 100,000 都能作为一个低相异基数。所以,多大才算是低相异基数,这要相对于结果集得大小来说。这里是指行集中不同项的个数除以行数应该是一个很小的数(接近于 0)。例如, GENDER 列

    13、可能取值为 M、 F 和 NULL。如果一个表中有 20,000 条员工记录,那么你将会发现 3/20,000=0.00015。同样地, 10,000,000 中 100,000 个不同值得比例为 0.01, 同样 , 值很小。这些列就可以建立位图索引。他们可能不合适建立 B*树索引,因为每个值可能会获取表中的大量数据。如同前面所述, B*数索引一般来讲是选择性的。位图索引 不带有选择性的 相反,一般是“没有选择性”的。 位图索引 在有很多即时 查询的时候极其有用,尤其是在查询涉及很多列或者会生成诸如COUNT 之类的聚会。例如,假设有一个含有 GENDER, LOCATION,和 AGE_G

    14、ROUP 三个字段的大表。在这个表中, GENDER 的值为 M 或者 F, LOCATION 可以选取 1 到 50 之间的值,AGE_GROUP 为代表 18 岁及以下, 19-25, 26-30, 31-40,和 40 岁及以上的代码。现在不得不通过以下的方式执行大量的即时查询: Select count(*) from T where gender = M and location in ( 1, 10, 30 ) and age_group = 41 and over; select * from t where ( ( gender = M and location = 20 ) or ( gender = F and location = 22 ) and age_group = 18 and under; select count(*) from t where location in (11,20,30); select count(*) from t where age_group = 41 and over and gender = F;


    注意事项

    本文(数据库设计外文翻译)为本站会员(泛舟)主动上传,毕设资料网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请联系网站客服QQ:540560583,我们立即给予删除!




    关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们
    本站所有资料均属于原创者所有,仅提供参考和学习交流之用,请勿用做其他用途,转载必究!如有侵犯您的权利请联系本站,一经查实我们会立即删除相关内容!
    copyright@ 2008-2025 毕设资料网所有
    联系QQ:540560583