TPC-H 标准 中文版.doc

TPC BENCHMARK H(决策支持)标准规范修订版2.0.0事务处理性能理事会（TPC）致谢TPC感谢TPC-D分会成员公司的工作，他们开发的第二版TCP-D规范是第一版TCP-H的基础。TPC-D分会包括来自Compaq，Data General，EMC，HP，IBM，Informix，Microsoft，NCR，Oracle，Sequent，SGL，Sun，Sybase，和Unisys各大公司的代表。另外，TPC还要感谢TCP-D分会的顾问Jack Stephens先生的贡献，感谢他在标准规范和DBGEN开发方面的工作。TPC成员文档历史日期版本描述1999年2月26草案1.0.0通过邮件投票得到的标准规范的草案1999年6月24修订版1.1.0对标准规范的第一个小修改2002年4月25修订版1.4.0对关键字的说明2002年7月12修订版1.5.0在8.6节附加了关于硬件EOL的东西2002年7月15修订版2.0.0通过邮件投票得到的三年维护定价的草案TPC BENCHMARK , TPC-H , QppH和QhpH都是事务处理委员会的标志。任何团体都可以免费复制本文的全部或部分，或者将本分的全部或部分分发给任何其他团体，只要：1、 复制和分发的主要目的是传播TPC的材料；2、 TPC的版权提示，出版物的标题以及发表日期，还有其他提示都出现在复制品中以表明它是得到TPC允许的。其它想复制或分发本文（包括哪些包含TPC问档内容但非TPC文档、规范或报告）而又不满足以上两个条件的团体必须得到TPC的书面许可。目录致谢2TPC成员2目录3条款0：概述50.1 前言50.2 一般系统实现原则60.3一般测量原则7条款1数据库逻辑设计71.1 商业和应用环境71.2 数据库实体，关系和特性81.3 数据类型定义91.4 表的规划101.5 执行的规则131.6 数据透明访问的要求15条款2.查询和更新函数152.1 查询的一般要求和定义152.2 查询一致性172.3 查询确认202.4 价格摘要报告查询（Q1）202.5最小代价供应者查询（Q2）212.6运送优先权查询（Q3）242.7订单优先权检查查询（Q4）252.8当地供应者数量查询（Q5）262.9预测收入变化查询（Q6）272.10货运量查询（Q7）282.11国家市场份额查询（Q8）292.12产品类型利润估量查询（Q9）312.13返回项目报告查询（Q10）322.14重要库存标志查询（Q11）342.15货运模式和命令优先查询（Q12）352.16消费者分配查询（Q13）362.17 促进效果查询（Q14）382.18 促进效果查询（Q15）392.19零件/供应商关系查询（Q16）402.20 小量订单收入查询（Q17）422.21 大订单顾客查询（Q18）422.22折扣收入查询(Q19)442.23潜在零件促进查询（Q20）452.24不能按时交货供应商查询（Q21）472.25全球销售机会查询（Q22）482.26更新函数的一般要求502.27新销售更新函数（RF1）512.28旧销售更新函数（RF2）512.29数据库处理进程51条款3：数据库系统特性523.1 ACID特性523.2 原子性需求543.3 一致性需求543.4 隔离性需求543.5 持久性需求57条款4 缩放和数据生成594.1 数据库定义和扩展594.2 DBGEN和数据库填充604.3 数据装载时间68条款5. 性能度量和执行规则705.1 术语定义705.2 配置规则705.3 执行规则725.4 度量76条款6SUT和驱动器786.1 测试配置模型786.2 被测试系统(SUT)定义796.3 驱动器定义80条款7定价817.1 被定价的系统817.2 定价方法83条款8完全公开报告858.1 报告要求858.2 格式指导858.3 完全公开报告的内容868.4 执行总结898.5 完整的公开报告的可用性928.6 完整的公开报告的修订92条款9 审计939.1一般性规则939.2 审计员的审核表94附录A：排序集96附录B：通过确认的查询变形97附录C：查询确认100附录D：数据和查询产生程序100附录E：简单执行摘要100条款0：概述0.1 前言TPC Benchmark H(TPC-H)是一个决策支持的基准，它由一系列面向商务应用的查询和并行数据修改组成。基准里选择的查询和组成数据库的数据在商业上都具有广泛的代表性并且易于实现。本基准阐明了决策支持系统的三个方面：分析大量的数据；执行高复杂度的查询；回答关键的、经常需要回答的商业问题。通过在可控环境下执行一系列针对标准数据库的查询，TPC-H评估各种决策支持系统的性能。TPC-H查询：回答现实商业问题；模拟生成随机查询（比如通过点击图形界面产生的查询）；比大多数OLTP事务复杂得多；包括各种各样的操作和选择性限制；在受测试系统的数据库服务器端产生高密度的活动；在某种遵守特定入口和有一定规模的数据库中执行；实现的时候带有由于与在线产品数据库同步而产生的限制。TPC-H操作模型如下：对于众多终端用户的查询和对数据库中所有表的修改而言，除了少量的维护时间之外，数据应该是每周7天，每天24小时不停工作的；在OLTP数据库执行更新操作的过程中，TPC-H数据库跟踪OLTP数据库的状态，这些更新操作会成批提交大量影响决策支持数据库某些部分的修改操作；存储在TPC-H数据库中的商业数据的共性导致查询和更新操作会在任何时候被执行，并且二者存在着一定的联系。另外，因为查询和更新可能并发执行，所以查询和更新操作的混合又受ACID特性的限制；为了达到性能和操作要求的最佳折衷，数据库管理员可以为查询和修改操作设定锁级别和并发调度规则。拥有10000个供应商的商业数据，这是运行本测试所要求的最小数据库。它的容量是一千万条记录也就是大约1G的数据量。像在4.1.3节定义的那样，运行基准测试可能会使用更大的数据库容量（比如100G）。TPC-H报告的性能度量单位称作TPC-H每小时完成复合查询性能指标，简称QphHSize（Size是测试数据库的大小），这一指标反映了系统处理查询的多方面的能力，这些方面包括执行查询所选择的数据库的大小，单步提交时的查询能力，以及多用户并行提交时的查询吞吐量。TPC-H价格性能比单位简写为$/QphHSize。为了与TPC-H标准一致，对于特定的配置，所有的对TPC-H结果的查询必须包含所有要求报告的部分（见5.4.6节）。TPC-H认为对于不同数据库大小的TPC-H结果的比较是具有误导性的，并且不主张这样的比较。TPC-H数据库必须使用市场上销售的数据库管理系统（DBMS）,并且查询的执行是通过一个使用动态SQL语言的接口。本规范适用于各种不同的SQL语言，因此并不要求实现者完完全全的实现标准SQL。TPC-H使用和其他基准相似的术语和单位，这些术语和单位由TPC和其他组织共同创建。这种在术语上的相似性并不是说TPC-H测试结果和其他测试结果具有可比性，唯一可与TPC-H结果相比较是其他采用同一修订版的TPC-H结果。虽然本基准提供了一个能够代表很多决策支持系统的环境，但是并没有反映决策支持的所有要求。另外，客户所取得的性能和销售商标明的性能的接近程度强烈依赖于客户应用环境和TPC-H环境的相似程度。这种从测试而来的相对性能与在其他工作量或环境下的性能不一定一致。任何对于其他环境下性能的推断是不可取的。测试结果很大程度上依赖于工作负荷，特定的应用要求，以及系统的设计与实现。系统性能会因为这样那样的因素而改变。因此，当用户在考虑关键能力计划或产品评估决定时TPC-H不应该被用作具体用户应用测试的代替品。测试发起者可以提供多个系统设计，只要它们遵守第6章描述的模型。像第8章说明的那样，系统实现细节的完整公开报告（FDR）必须和测试结果同时提供。注释1：为了保证主文档的可读性而被分离出去的注释和附录也是本标准的一部分，它们的规定也必须被遵守。注释2：有些附录的内容只提供了电子档，而不包含在本文档的印刷品中。0.2 一般系统实现原则TPC测试的目的是为商业界使用者提供客观的性能数据，为了达到这个目的，TPC测试规范要求测试由系统，产品，技术以及定价多个部分组成，并且这些：是用户可以普遍得到的；是和某个TPC基准所代表的市场类别相一致的；对于相应的市场类别里的用户而言，较容易实现。只要满足上面的要求，鼓励使用新的系统，产品，技术以及定价，但是严禁使用主要目的是为提高TPC测试性能而对于实际应用环境毫无实际用途的测试系统，产品，技术以及定价（以后统称为系统实现）。换句话说，就是所有仅以提高测试成绩为目的而不是以提高实际性能或改善实际定价为目的的“测试专用”系统实现是禁止的。根据下面的特征可以判断某个系统实现是不是“测试专用”。没必要每点都满足，但是证据越多就越容易甑别一个不可接受的系统实现。在这样一个复杂问题上作出判断并不需要绝对的确定或是基于某个合理疑点上的确定。这个问题必须这样回答：“基于手头上的证据，大部分的证据是否表明本系统实现是“测试专用”。”下面的这些特征可以判断一个系统实现是否是“测试专用”：a) 这个系统实现是不是普遍可得，有没有证明文件和技术支持？b) 在TPC测试之外，这个系统实现在使用或应用上有没有重大的会限制它的应用的约束？c) 整个系统实现或部分系统实现是不是很蹩脚的集成到更大的产品中？d) 这个系统实现是不是专门利用了TPC测试的有限性（如查询分布情况，查询混合，并发或竞争，隔离要求等）？而在某种意义上这种针对性措施对于测试所对应的应用环境而言并没有广泛的实用性。e) 这个系统实现是不是不为供应商看好？（这包括不能够成功地升级到和同类产品与技术水平相近地系统。）f) 这个系统实现有没有要求最终用户，程序员或系统管理员非常的熟练？g) 对于商家而言定价是不是非同寻常，或者和正常的商业行为而言定价是不是非同寻常？如下的定价行为是可疑的： 只有极少的客户可以得到的折扣； 折扣被证明是非同寻常的； 少量的得到超过25%的折扣而大量则会得到50%的折扣； 定价是特价或抛售；对于折价商品在产品运输，质保或维护上有非同寻常的限制；注释：本处列出的特征没有打算包括驱动和系统实现的特殊层，因为它们不一定是商业软件，而且它们有自己特殊的要求和在第六章中列举的限制。在第六章列出的特征和禁令用来判断驱动或系统实现的特殊层是不是“测试专用”。0.3一般测量原则TPC测试结果试图准确表现系统性能。因此在测量结果时应该遵守某些原则。测量时用到的步骤或方法不是在规范中明确描述就是留给测试发起者决定。如果在规范中没有描述，那么测量的步骤和方法必须满足以下要求：方法是公认的工程惯例或标准；方法不会增强结果；测量结果所使用的仪器必须按照质量标准校准；在报告结果中的异常时要精确而坦率，即使在测试要求中并没有特殊要求。注释：鼓励使用新方法只要它们满足上面的要求。条款1数据库逻辑设计1.1 商业和应用环境TPC Benchmark H测试由一系列商业查询组成，这些查询在某种意义上代表复杂的商业分析应用。这些查询给出了一个实际的环境，描绘了批发商的活动以帮助读者将该基准的组件联系起来。TPC-H不代表任何特定商业领域里的活动，而是可以被应用到任何需要管理，销售或在全球范围销售某种商品的行业。（比如汽车租赁，食品销售，供应商等）。但TPC-H并不是如何构建实际信息分析系统的模型。测试的目的是减少在信息分析应用中出现的操作的多样性，同时又保留应用最根本的性能特征，也就是：系统的利用率和操作复杂度。要完全管理一个商业分析环境需要执行大量不同类型和复杂度的查询。因为查询的运行时间，占用的系统资源以及被执行的频率（不符合决策支持的特性），许多查询的主要目的并不是性能分析。被选择的查询具有以下特征：它们非常复杂；它们选择各种各样的访问模式；它们带有在随机特性；它们检查可获得数据的大部分它们互不相同它们含有查询参数并在执行时变化所选择的查询要为下面各类商业分析提供答案：定价和促销；供货和需求管理；利润和收入管理；顾客满意度研究；市场份额研究；运输管理。虽然重点是信息分析，但本测试也认可数据库定期更新的需要。这个数据库既不是商业运作数据库的一次快照也不是一个支持OLTP程序并行操作的数据库。这个数据库必须能够全天候支持对所有表的查询和更新。虽然本测试模拟了一个视更新操作为数据维护不可分割的部分的商用环境。但是实际上，测试中的更新操作没有模拟商用环境的这个方面。它的目的更主要是展示DBMS的更新能力，同时评估维护辅助数据结构的性能代价，比如次索引。决策者注释：本测试不包含任何用来验证数据库连续性的测试，也没有特定的系统功能可以设置为用来测试数据库的连续性。持续性和全天候工作能力的定义包含在测试规范中，这为预期的决策支持系统描绘了一幅更完美的图画。一个系统实现即使没有全天候工作的能力，但只要它满足规范中描述的要求也能产生相应的测试结果。OLTP数据库OLTP事务商业操作商业分析决策支持数据库图一：上图说明了TPC-H所对应的商用环境，并且突出了TPC-H测试和其他TPC测试的根本区别。其他TPC基准模拟了商用环境的操作端，在这一端事务以实时的基础被执行。而TPC-H测试则模拟了商用环境的分析端，在这一部分计算出未来走势、产生了精炼的数据。然后这些东西被用于产生合理的商业决策。在OLTP测试中原始数据从四面八方流向OLTP数据库，在这里这些数据会保留一段时间。在TPC-H测试中，决策支持数据库（DSS）定期进行更新操作，它里面的内容被各式各样的决策者查询使用。1.2 数据库实体，关系和特性TPC-H数据库的组成被定义为由八个单独的表（基本表）组成。这些表的列与列之间的关系举例如图2：TPC-H模式图2：TPC-H模式图例：每个表名后面的括号内为这个表的列名的前缀;箭头指出表与表之间的一对多的关系;每个表名下方的数字或公式表示表的行数。一些是SF(Scale Factor)中的因子，用来获得数据库的大小。在LINEITEM表中的行数是近似值（详见4.2.5）。1.3 数据类型定义1.3.1 下列数据类型将应用于每个表的列的清单中：Identifier注释：一个默认的数据类型是整形。然而在SF大于300时，一些值将超出所支持的4个字节的整数。用户必须使用一些其他的数据类型比如8个字节的整数、小数或者字符串类型来实现。Integer意思是必须为整数（比如值的增长为1），取值范围为-2,147,483,646到2,147,483,647。Decimal意思是必须能够描述取值范围从-9,999,999,999.99到+9,999,999,999.99内、数值增长为0.01的所有有理数。Big Decimal是扩展的Decimal数据类型，它具有的附加特性是它必须足够大以至于能够描述存放在临时表中创建的查询变量的总数。Fixed Text，size N是用来存储一个固定长度为N的字符串类型。注释：如果字符串本身小于长度N，那么剩余的空间必须被存储在数据库中，或者数据库自动加上一些空间使得CHAR_LENGTH()函数的返回值为N。Variable text, size N是该列可以存储变量长度最长为N的字符串变量。被定义为“Variable text, size N”的列可以和定义为“fixed text, size N”一样执行。Date是一个可以被描述为YYYY-MM-DD的值，它所有的字符均为数字。一个日期必须能够描述连续的14年里的每一天，但是对日期的内部描述没有特殊的要求。注释：用户在选择数据类型时，申请的详细的数据类型定义必须由所有定义在模式中的数据类型的情况组成，除了标识列，它必须满足数据库缩放比例的要求。1.3.2 在这篇文档中使用的SF标记是用来描述数据库的比例因子的（详见条款4）。1.4 表的规划以下的列表定义了每个表所需要的结构（列的清单）。主键的注释及外键引用仅仅只是为了说明，而不是指定实现要求，例如完整性约束。PART表的规划列名 数据类型需求 注释P_PARTKEY identifier SF*200,000P_NAME variable text, size 55P_MFGR fixed text, size 25P_BRAND fixed text, size 10P_TYPE variable text, size 25P_SIZE integerP_CONTAINER fixed text, size 10P_RETAILPRICE decimalP_COMMENT variable text, size 23主键: P_PARTKEYSUPPLIER表的规划：列名 数据类型需求 注释S_SUPPKEY identifier SF*10,000S_NAME fixed text, size 25S_ADDRESS variable text, size 40S_NATIONKEY identifier 外键引用N_NATIONKEYS_PHONE fixed text, size 15S_ACCTBAL decimalS_COMMENT variable text, size 101主键: S_SUPPKEYPARTSUPP表的规划列名 数据类型需求 注释PS_PARTKEY identifier 外键引用P_PARTKEYPS_SUPPKEY identifier 外键引用S_SUPPKEYPS_AVAILQTY integerPS_SUPPLYCOST decimalPS_COMMENT variable text, size 199主键: PS_PARTKEY, PS_SUPPKEYCUSTOMER表的规划列名 数据类型需求 注释C_CUSTKEY identifier SF*150,000C_NAME variable text, size 25C_ADDRESS variable text, size 40C_NATIONKEY identifier 外码参照N_NATIONKEYC_PHONE fixed text, size 15C_ACCTBAL decimalC_MKTSEGMENT fixed text, size 10C_COMMENT variable text, size 117主键: C_CUSTKEYORDERS表的规划列名 数据类型需求 注释O_ORDERKEY identifier 少量的计算SF*1,500,000 O_CUSTKEY identifier 外键引用C_CUSTKEYO_ORDERSTATUS fixed text, size 1O_TOTALPRICE decimalO_ORDERDATE dateO_ORDERPRIORITY fixed text, size 15O_CLERK fixed text, size 15O_SHIPPRIORITY integerO_COMMENT variable text, size 79主键: O_ORDERKEY注释：并不是所有的顾客都会有订单。事实上，数据库中大约1/3的用户不会有任何订单。这些订单随机的分配给2/3的用户(详见条款4)。这样做的目的是为了在加入两个或更多的表时，数据库有能力操作“死数据”。LINEITEM表的规划列名 数据类型需求 注释L_ORDERKEY identifier 外键引用O_ORDERKEYL_PARTKEY identifier 外键引用P_PARTKEY，和L_SUPPKEY混合引用(PS_PARTKEY, PS_SUPPKEY)L_SUPPKEY identifier 外键引用S_SUPPKEY,和L_PARTKEY混合引用外键(PS_PARTKEY, PS_SUPPKEY)L_LINENUMBER integerL_QUANTITY decimalL_EXTENDEDPRICE decimalL_DISCOUNT decimalL_TAX decimalL_RETURNFLAG fixed text, size 1L_LINESTATUS fixed text, size 1L_SHIPDATE dateL_COMMITDATE dateL_RECEIPTDATE dateL_SHIPINSTRUCT fixed text, size 25L_SHIPMODE fixed text, size 10L_COMMENT variable text size 44混合的主键: L_ORDERKEY, L_LINENUMBERNATION表的规划：列名 数据类型需求 注释N_NATIONKEY identifier 组合25 nationsN_NAME fixed text, size 25N_REGIONKEY identifier 外键引用R_REGIONKEYN_COMMENT variable text, size 152主键: N_NATIONKEYREGION表的规划：列名 数据类型需求 注释R_REGIONKEY identifier 组装5 regionsR_NAME fixed text, size 25R_COMMENT variable text, size 152主键: R_REGIONKEY1.4.2 约束这些约束的使用是可选的。对于定义主键和外键或者检查约束没有指定的要求。然而，一旦使用了约束，它们必须满足以下的要求：它们必须使用SQL指定。没有指定的实现要求。比如：CREATE TABLE, ALTER TABLE,和CREATE TRIGGER都是合法的语句;约束必须语句级或者事务级上执行;在装载测试完成之前，所有定义的约束都必须被执行并且生效（详见5.1.1.2）。下面列出的任何约束的子集都必须在下面详细说明，不能使用任何附加的约束。1.4.2.1 Nulls：任何列都可以使用NOT NULL属性。1.4.2.2 主键：下列主键必须定义为主键（使用PRIMARY KEY句子或者其他等价的定义）： P_PARTKEY; S_SUPPKEY; PS_PARTKEY, PS_SUPPKEY; C_CUSTKEY; O_ORDERKEY; L_ORDERKEY, L_LINENUMBER; N_NATIONKEY; R_REGIONKEY.强制一列（或者一组列）包含唯一性的值仅仅只能在上面列出的主键中执行。1.4.2.3 外键：我们可以定义任何一个在条款1.4.1中列出的外键。对于添加和删除（比如RESTRICT, CASCADE, NO ACTION）没有特殊的要求。Check约束：可以定义它来限制数据库的内容。为了支持进一步的改进，检查约束必须不依赖于每个列的已知的枚举值。下面列出了检查约束允许的定义表达式：1.键为非负值 1.P_PARTKEY = 02.S_SUPPKEY = 03.C_CUSTKEY = 04.PS_PARTKEY = 05.R_REGIONKEY = 06.N_NATIONKEY = 02. 开区间约束1.P_SIZE = 02.P_RETAILPRICE = 03.PS_AVAILQTY = 04.PS_SUPPLYCOST = 05.O_TOTALPRICE = 06.L_QUANTITY = 07.L_EXTENDEDPRICE = 08.L_TAX = 03. 封闭区间的约束1.L_DISCOUNT 的范围从 0.00到1.004. 多列约束1.L_SHIPDATE = L_RECEIPTDATE注释：这些约束依赖于条款1.2中的图表和条款1.4中的描述。他们不是来自定义于条款4.2中的数据生成的详细知识。1.5 执行的规则1.5.1 数据库必须使用商业上可用的DBMS。1.5.2 数据库中的记录在不改变每个表的逻辑独立性的前提下，可以在物理方式上实现聚集。注释：该条的意图是允许在所有的表保留严格的逻辑视图的前提下对数据库的进行合适的物理设计。1.5.3 在装载测试结束时，所有的表应该具有在数据库比例因子和数据库的大小中定义的严密的行数，这些在条款4中有详细的说明。1.5.4 水平分割基本表或创建数据库辅助结构（详见1.5.7）是允许的。表和辅助结构中的行可以被分配给不同的文件、磁盘或空间。如果划分是基于一些表或者辅助结构中的数据上的函数，这些分配必须基于划分域的值。一个划分必须遵循且只能遵循以下条件中的一条：主键的定义见条款1.4.2.2外键的定义见条款1.4.1。对于删除/更新的操作（比如RESTRICT,CASCADE,NO ACTION等）没有特殊的要求。如果在一个实现中定义了任意一个外键的关系，那么所有的外键关系都必须在这个实现中定义。一个单独的日期列一些划分模式需要使用指令清楚的指定划分域的值。如果需要使用这些指令，它们必须满足以下的条件：它们不需要依赖任何有关表中数据存储的信息，除了划分域中需要使用的列的最大、最小值。这些列的最大、最小值的详细说明见条款4.2.3。由于整除的限制，它们必须定义给每个划分相等的部分，这些划分在划分列的最大值和最小值之间。这些设定必须允许插入划分列的值，且允许超出最大值、最小值的范围覆盖，数据库只要插入的数据值符合数据类型和条款1.3和1.4中的约束条件。基表的多级划分或者辅助结构只在每个划分都满足上面的定义，并且每级只引用一个上面定义的划分时才允许。如果实现了这样的恶化分，必须公开每个划分的细节。1.5.5 放置在持久介质上的数据是不能被审计的。使用SQL DDL显式地划分指令是被禁止的。行必须作为列集的原子逻辑。注释：上面的条款意味着不依赖于显式的划分指令时垂直划分是允许的。显式划分指令是指将某一行地一组列分配到不同的文件、磁盘或者分区，该行的其他列在别的文件、磁盘或者分区。1.5.6 除了在1.5.7中规定的情况以外，逻辑复制数据库对象（比如表，行或者列）都是不允许的。表的辅助数据结构的物理实现可以包括选定数据的复制，只要：所有复制的数据由DBMS、操作系统或者硬件管理;所有的复制对于数据处理操作来说是透明的;当更新数据的操作提交时，所有的逻辑备份都必须体现出数据被更改;所有备份中的数据总是维持完整的ACID属性。1.5.7 组成一个基表的一列或者多列数据的逻辑复制（如索引、物化视图、摘要表、用于强制相关完整性约束的结构）的辅助数据结构必须和条款1.5.6中规定的相一致。定义和创建这些结构的指令必须遵循以下的限制：它们不能引用超过一个表，不能引用其他的辅助结构;它们必须严格满足以下两个条件中的一个： 它们不能引用超过下面选择出基表列的一个： 主键就是当前列，或者它的一部分是由要求的表中定义的混合主键构成； 外键就是当前列，或者它的一部分是由要求的表中定义的混合外键构成； 一个列拥有条款1.3中定义的日期数据类型。 它们只能够在以下情况下引用一个基表的多个列：这些列刚好构成该表的组合主键或者组合外键（见条款1.4.1）在明确许可的列中可以包含函数或者表达式。在TPC-H脚本中，不允许使用使得辅助数据结构中的列（或者列的函数）成为物化列的指令（比如DDL，会话属性，全局变量），除非那些列是在上面的定义中明确许可的。此外，不允许使用使得来自多个表中的辅助数据结构的列成为物化列的指令。注释：数据库使用适当的指令产生辅助结构，这种实现通常包含嵌入的指针或者指向相应的基表行的引用。数据库显式的调用“row IDs”或者嵌入基表主键的值（来达到上述目的）的方法都是可以接受的。特别的，辅助结构的显式产生的嵌入的主键值是可物化的列。主键和外键列都定义在要求的表上。1.5.8 表名必须遵循条款1.4中规定。为了防止实现中保留字和表名冲突，可以选择插入分隔符或者改为另一个有相同意义的名字。1.5.9 在每个表中，列集必须包含所有定义在条款1.4中的规则。不允许向这些表中加入任何列。然而列的顺序是不作规定的。1.5.10 列名必须遵循条款1.41.5.11 在条款1.4中描述的列对于数据管理器来说都必须是逻辑不连续的而且相互独立。比如，C_ADDRESS和C_PHONE不能被当作单独的离散的列C_DATA的两个子部分实现。1.5.12 在条款1.4中定义的每个列都必须被数据管理器看作是单独的列。比如P_TYPE不能作为两个单独的列P_TYPE1和P_TYPE2来实现。1.5.13 数据库可以插入任意的数值，这些数值的数据类型和约束定义在条款1.3和条款1.4中。注释1：虽然更新函数（详见条款2.26）并不插入任何值并且也不修改所有的表，所有的表必须能够在性能测试中修改。注释2：该条款主要防止数据库模式定义不恰当的限制数据库中的数据生成。1.6 数据透明访问的要求1.6.1 数据透明访问是去除了查询文本的定位能力和划分数据的访问机制的系统属性。没有有限的测试可以证明系统支持数据的透明访问。要确定系统提供了透明的数据访问需要在下面描述（数据库）最少需要提供的能力。一个使用水平划分的操作必须遵循定义在条款1.6.2和条款1.6.3中的透明数据访问的需求。注释：该条款主要要求直接的且通过服务执行透明的访问物理和（或）逻辑的分区数据，这些服务可以由一些商业上可获得的途径提供，比如SQL、DBMS、操作系统、硬件或者以上这些的结合产品。1.6.2 遵循条款1.4中的定义的每个表都必须可以通过名字区分，并且和表的划分没有任何的关系。所有对数据处理进行的可执行查询文本操作中必须使用这些名字1.6.3 使用满足条款1.6.2的名字，任何非TPC-H查询必须能够引用任何行集或列集：在任意DBMS支持的情况下可标识；使用条款1、6、2所描述的名字，并且使用对于所有的表使用相同的数据操纵语义和语法。例如，在某个表中查询任意行集的语法和语义必须和查询其他任何表中行集的相同。注释：这一条款的目的是每个TPC-H查询使用通用机制来访问数据库中的数据条款2.查询和更新函数这一节介绍了22个决策支持查询和两个作为TPC-H标准的一部分被执行的数据库更新函数。2.1 查询的一般要求和定义2.1.1 查询概述2.1.1.1 每个查询由以下几部分构成：商业问题，它描述了使用该查询的商业环境；功能查询定义，它用SQL-92语言定义了查询执行的功能；替换参数，它描述了如何产生完成查询语法所需要的值；查询确认，它描述了如何确认查询是否违反了数据库的约束条件。2.1.1.2 对每个查询，测试发起者必须产生查询功能定义的一个实现，被称为可执行的查询文本。2.1.2 查询功能定义2.1.2.1 查询功能定义用SQL-92语言编写，在必要的地方用注解来指定要被返回的行的数目。它们定义了每个可执行查询文本必须执行的功能（见4.1.1节）。2.1.2.2 除了替换参数以外，如果一个可执行查询文本与指定的查询函数定义不同，那么它必须满足2.2节的要求。2.1.2.3 当一个查询函数定义包含一个新实体（如光标，视图，表）时，必须利用某一机制来确保新建的实体不会干扰其它执行流并且没有被多个执行流共享（见5.1.2.3节）。在这个文档里（QGEN也是如此，见2.1.4节）的查询功能定义通过把一个文本标记附加给新实体来实现这种分离。这个文本标记用大写字母表示，并且用中括号括在一起，如STREAM_ID。在查询函数定义中，文本标记一旦被发现，就必须用一个唯一的流标识数（从0开始）代替它以完成可执行查询文本。注释：一旦一个标识数被产生并且被分配给一个指定的查询流，那个流在测试期间就一直使用同样的标识数。2.1.2.4 当一个查询功能定义包含表的创建时，列的数据类型说明使用符号。符号的定义参见1.3.1节。2.1.2.5 在一个可执行查询文本中产生的任何实体都必须在这个可执行查询文本中删除。2.1.2.6 一个逻辑表空间是一系列逻辑上邻近的、不可分割的物理存储设备的集合。2.1.2.7 如果在查询过程中使用了CREATE TABLE语句，这些CREATE TABLE语句必须用一个表空间引用进行扩展（如，IN ）。对每一个表，必须使用唯一的表空间。注释：表空间仅仅应用于包含CREATE TABLE语句的变量。2.1.2.8 在查询执行过程中创建的所有表必须满足第3章定义的ACID特性。2.1.2.9 查询2，3，10，18和21要求返回给定的行数（如”Return the first 10 selected rows”）。如果N是要返回的行数，当符合条件的行数不小于N时，查询必须精确返回前N行；如果符合条件的行数小于N，则返回所有的行。有三种方法满足这种要求。一个测试发起者必须采用其中的一种方法，利用该方法来处理所有要求返回指定行数的查询。1.被测试发起者的交互式SQL界面支持的厂商特有的控制语句（如 SET ROWCOUNT n）可以用来限制返回的行数。2.被具体实现层（见6.2.4）识别、用于控制一个获得行的循环的控制语句可以用来限制返回的行数（如，while rowcount=n）。 3.把厂商特定SQL语法加入SELECT语句可以限制返回的行数（如，SELECT FIRST n）。这种语法不被认为是微小的查询更改，因为它完成了查询函数定义的功能要求。没有已经定义的标准语法。在其它方面，查询必须满足2.2节的要求。语法必须能够单独处理结果集，并且不能产生任何附加的对表、索引或访问路径的显式引用。2.1.3 替换参数和输出数据2.1.3.1 每个查询有一个或多个替换参数。当产生可执行查询文本时，每个替换参数都必须用一个值来代替。这些值必须被用来完成可执行查询文本。这些替换参数的名字用大写字母表示，并且用中括号括起来。例如，在Pricing Summary Report Query中（见2.4节），替换参数DELTA在查询功能定义的每一次出现都必须用为DELTA所产生的值来代替，以便完成可执行查询文本。 注释1：当日期是替换参数的一部分时，它们必须用年、月、日来表示，例如，YYYY-MM-DD。年、月、日之间的分隔符没有明确的规定。其它的日期表达方式是不允许的，例如，用1970-01-01以后的天数来表示。注释2：当一个替换参数在一个查询中出现多次时，为这个替换参数产生唯一的值，它的每一次出现都用同一个值来替换。注释3：产生可执行查询文本也可能包括附加的文本替换（见2.1.2.3节）。2.1.3.2 术语“随机选择”应用于替换参数的定义中，意思是从指定的值的范围或列表中随机选择。2.1.3.3 用来产生替换参数的随机数产生器必须用下面的方法产生种子： 初始种子（seed0）是数据库加载结束时的时间戳，用mmddhhmmss来表示，其中mm代表月，dd代表日，hh代表小时，mm代表分钟，ss代表秒。这个种子用来进行第一次运行的功率测试。以后的种子（用来进行吞吐量测试）这样来选择：seed0+1, seed0+2, seed0+s,其中s是指厂商选择的流的数目。这个过程产生具有s个流的测试程序的第一次运行所需要的s+1个种子。第二次运行的种子可以和第一次运行的种子相同（见5.3.2节）。然而，如果测试发起者决定第二次运行使用与第一次运行不同的种子，那么测试发起者必须使用一个与第一次运行类似的选择过程。种子必须是下面的形式：seed0,seed0+1, seed0+2, seed0+s,其中seed0是第一次运行结束的时间戳，表示方式与前面相同。 注释1：这一节的目的是防止由于多个流使用相同的种子或者使用由一个定义好的种子选择方法所产生的预先知道的种子而导致的性能优势。 注释2：QGEN是TPC（见2.1.4节）提供的产生可执行查询文本的一种工具。如果用一个发起者提供的工具来代替QGEN，它的种子的行为必须满足这一节所讲的，它的代码必须公布出来。执行完后，查询返回一行或多行。返回的行称为输出数据，它们或者是数据库中的行，或者是由数据库中的数据重新组成的行。2.1.3.4 查询的输出数据应该用一种即使一个计算机初学者也能容易理解的格式来表示。特别地，在查询确认（见2.3节）中，我们已经预知了查询结果，为了能够使真正的输出数据与预知的输出数据进行比较，输出数据的格式必须遵循下面的原则：a) 列按照查询函数定义或者经过核准的变量的SELECT语句所指定的顺序出现。列名可以选择。b) 包含价格的非整数表达式用小数来表示，小数点后至少有两位。c) 整数不包含前导0。d) 日期用年、月、日来表示，其中，年、月、日都是整数，如YYYY-MM-DD。年、月、日之间的分隔符没有明确指定。其它的日期表达方式是不允许的，如用1970-01-01之后的天数来表示。e) 字符串区分大小写；字符串的前面或后面可以有空格。f) 列之间的空白区域的大小没有指定。2.1.3.5 查询确认的输出数据中包含的数值的精确度必须符合下面的原则：a) 对于单一的列值和有COUNT运算得到的结果，其值必须与查询确认的输出数据精确匹配。b) 对于比值，结果必须在查询确认的输出数据的1以内。c) 对于由SUM运算得到的结果，其值必须在查询确认的输出数据的1%以内。d) 对于由AVG运算得到的结果，其值必须在查询确认的输出数据的1%以内。2.1.4 QGEN程序2.1.4.1 可执行查询文本必须按照2.1.2节和2.1.3节的要求来产生。附录D中提供的QGEN的源代码是一个可执行查询文本产生器的具体实现的例子。它是用ANSI C编写的，已经被应用到许多平台。如果使用QGEN，它的版本必须与标准说明书中的版本相一致。 注释1：强烈推荐使用QGEN。我们需要