C_CUSTKEY identifier SF*150,000 C_NAME variable text, size 25 C_ADDRESS variable text, size 40
C_NATIONKEY identifier 外码参照N_NATIONKEY C_PHONE fixed text, size 15 C_ACCTBAL decimal
C_MKTSEGMENT fixed text, size 10 C_COMMENT variable text, size 117 主键: C_CUSTKEY
ORDERS表的规划
列名 数据类型需求 注释
O_ORDERKEY identifier 少量的计算SF*1,500,000 O_CUSTKEY identifier 外键引用C_CUSTKEY O_ORDERSTATUS fixed text, size 1 O_TOTALPRICE decimal O_ORDERDATE date
O_ORDERPRIORITY fixed text, size 15 O_CLERK fixed text, size 15 O_SHIPPRIORITY integer
O_COMMENT variable text, size 79 主键: O_ORDERKEY
注释：并不是所有的顾客都会有订单。事实上，数据库中大约1/3的用户不会有任何订单。这些订单随机的分配给2/3的用户(详见条款4)。这样做的目的是为了在加入两个或更多的表时，数据库有能力操作“死数据”。
LINEITEM表的规划
列名 数据类型需求 注释
L_ORDERKEY identifier 外键引用O_ORDERKEY L_PARTKEY identifier 外键引用P_PARTKEY，
和L_SUPPKEY混合引用(PS_PARTKEY, PS_SUPPKEY)
L_SUPPKEY identifier 外键引用S_SUPPKEY,
和L_PARTKEY混合引用外键(PS_PARTKEY, PS_SUPPKEY)
L_LINENUMBER integer L_QUANTITY decimal L_EXTENDEDPRICE decimal L_DISCOUNT decimal L_TAX decimal
L_RETURNFLAG fixed text, size 1 L_LINESTATUS fixed text, size 1 L_SHIPDATE date L_COMMITDATE date L_RECEIPTDATE date
L_SHIPINSTRUCT fixed text, size 25 L_SHIPMODE fixed text, size 10
11
L_COMMENT variable text size 44 混合的主键: L_ORDERKEY, L_LINENUMBER
NATION表的规划：
列名 数据类型需求 注释
N_NATIONKEY identifier 组合25 nations N_NAME fixed text, size 25
N_REGIONKEY identifier 外键引用R_REGIONKEY N_COMMENT variable text, size 152 主键: N_NATIONKEY
REGION表的规划：
列名 数据类型需求 注释
R_REGIONKEY identifier 组装5 regions R_NAME fixed text, size 25 R_COMMENT variable text, size 152 主键: R_REGIONKEY 1.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 >= 0
2.S_SUPPKEY >= 0 3.C_CUSTKEY >= 0
12
4.PS_PARTKEY >= 0 5.R_REGIONKEY >= 0 6.N_NATIONKEY >= 0 2. 开区间约束
1.P_SIZE >= 0
2.P_RETAILPRICE >= 0 3.PS_AVAILQTY >= 0 4.PS_SUPPLYCOST >= 0 5.O_TOTALPRICE >= 0 6.L_QUANTITY >= 0
7.L_EXTENDEDPRICE >= 0 8.L_TAX >= 0 3. 封闭区间的约束
1.L_DISCOUNT 的范围从 0.00到1.00 4. 多列约束
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中的约束条件。
基表的多级划分或者辅助结构只在每个划分都满足上面的定义，并且每级只引用一个上
13
面定义的划分时才允许。如果实现了这样的恶化分，必须公开每个划分的细节。 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.4
1.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）并不插入任何值并且也不修改所有的表，所有的表必须能够在性能测试中修改。
14
注释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开始）代替它以完成可执行查询文本。
注释：一旦一个标识数被产生并且被分配给一个指定的查询流，那个流在测试期间就一
15