1.2.1 TPC-C 数据库的部件是为组成9个单独的数据基本表。在下面的实体关联表中阐述了这些基本表之间的联系并遵从条款1.4的指定规则。
•所有的数据展示说明了数据库数据量要求（参照条款4.3）。.
• 在实体块种的数字表明了基本表的集的势（组的数量）。这些数字从W得到（大商店的数字）用来阐述数据库的规模（见第四章）。
• 在关联箭头上的数字表明关联的集的势（每个父节点对应的子集平均数字）。
• 加号（+）用在关联的集的势后或者数据表中用来阐述这个数字在再测量区间之上的（见5.5）初始数据库量中服从于小的变化如已经插入或删除的组。
1.3 表的设计
1.3.1 接下来的列表定义了各种表的最小限度的构造（属性列表）：
• N unique IDs 意思是这个属性必须拥有所有的ID再最小的N unique IDs装置中、不考虑物理属性的表现（例如：二进位、集合小数、照字母顺序等）。
• variable text, size N 意思是必须能够支持任何可变长长度为N的字符串。如果属性列是定长字符串并且串中字符长度小于N，它必须用空格填补。
• fixed text, size N 意思是属性列必须能支持定长长度为N的字符串。
• date and time 意思是属性列必须能支持在之间的至少精确到秒的日期时间。
• numeric, N digits 意思是属性列必须能支持任何小数位数为N的值。数字域包含的货币单位（W_YTD, D_YTD, C_CREDIT_LIM, C_BALANCE, C_YTD_PAYMENT, H_AMOUNT, OL_AMOUNT, I_PRICE）必须能用数据类型给出精确的表达，要求精确到当前执行基准所规定的流通的最小货币单位。例如美元中的C_BALANCE可以表达（12.2）带符号的十进制位（带有固定的缩放比例）、精确到41比特的分币大小的整数或者精确到双精度实数64比特的分币 。
• null 意思是为给定的属性且总是同一个属性值所提供的越界值
注释 1: 对于每个接下来可以贯彻执行任何订单的属性列表用被测试的物理系统来提供表现。
注释2: 基本表和属性名仅仅用做阐述的用途，可能执行会用到不同的名字。
大商店基本表设计
域名
域定义
注释
W_ID
2*W unique IDs
W Warehouses are populated
W_NAME
variable text, size 10
W_STREET_1
variable text, size 20
W_STREET_2
variable text, size 20
W_CITY
variable text, size 20
W_STATE
fixed text, size 2
W_ZIP
fixed text, size 9
W_TAX
numeric, 4 digits
Sales tax
W_YTD
numeric, 12 digits
Year to date balance
主键： W_ID
管区基本表设计
域名 域定义 注释
D_ID 20 unique IDs 10 are populated per warehouse
D_W_ID 2*W unique IDs
D_NAME variable text, size 10
D_STREET_1 variable text, size 20
D_STREET_2 variable text, size 20
D_CITY variable text, size 20
I D_STATE fixed text, size 2
D_ZIP fixed text, size 9
D_TAX numeric, 4 digits Sales tax
D_YTD numeric, 12 digits Year to date balance
D_NEXT_O_ID 10,000,000 unique IDs Next available Order number
主键：: (D_W_ID, D_ID)
D_W_ID 外部码, 参考 W_ID
消费者基本表设计
域名 域定义 注释
C_ID 96,000 unique IDs 3,000 are populated per district
C_D_ID 20 unique IDs
C_W_ID 2*W unique IDs
C_FIRST variable text, size 16
C_MIDLE fixed test,size 2
历史纪录基本表设计
注释： 在历史纪录基本表的行中没有上下文连贯的主键，在这个表里不需要唯一的组的区分。
注意: TPC-C 申请表没有利用C_ID属性幅度增加到6,000之外的能力。
新订单基本表的设计
订单基本表的设计
订单线路基本表的设计
条款基本表的设计
库存基本表的设计
1.4 执行标准
1.4.1 在所允许的数据库中记录的物理聚簇
1.4.2 避开合理的读/写组的表现观点被拒绝
注释： 这个条款的目的是为了确保应用程序能够执行合理操作所定义在没有利用这个观点将一些操作合并成一个操作的交易侧面的数字。
1.4.3 所有的数据基本表必须由适当规模的由数据库量要求定义的组（见4.3节）。
1.4.4 允许横向分割基本表。基本表中的行组可以被分配到不同的文件、磁盘或者区域中。如果执行这一分割那么这个区分的细节必须要透露。
1.4.5 允许纵向分割基本表。基本表中的属性组（columns）可以被分配到不同于表的其他属性的存储域的文件、磁盘或者区域中。如果执行这一分割那么这个区分的细节必须要透露（参见1.4.9节有关于局限性）。
注释： 在上面的两个条款中(1.4.4 和 1.4.5)把分配数据到不同的文件、磁盘或者区域中的操作如果不是基于逻辑的数据结构的知识（例如：组或属性边界的知识）不被考虑执行。例如：在若干存储有一个或者多个基本表的物理文件的磁盘上分配或脱模在这个分配被没有合理的结构物理文件知识的情况下由硬件或者操作系统执行完的情况下是不被考虑划分。
1.4.6 所有表格允许复制。所有的基本表的备份必须符合所有的要求，这些要求包括：原子性、一致性和独立性，这些在第三章有定义。如果执行那么这个区分的细节必须要透露。
注释: 仅基本表的一个备份需要长久的符合第3章定义的条件。
1.4.7 当一些变化不会被改进的时候属性可能会被从一个基本表附加到和/或复制到另一个基本表。
1.4.8 每一个像在1.3.1节叙述的属性必需逻辑上分散并且独立的易于数据管理者理解。例如：W_STREET_1 和 W_STREET_2因为是两个离散的W_STREET的属性不能被执行。
1.4.9 每一个像在1.3.1节叙述的属性作为单一属性必需容易被数据管理者所理解。例如：S_DATA 像两个离散属性S_DATA_1 和 S_DATA_2一样不能被执行。从属属性不包括在这个属性之内。纵向划分不能在这两个属性之间定义执行这些例外。
• 所有属性包括一个日期时间值（例如：C_SINCE, H_DATE, O_ENTRY_D, and OL_DELIVERY_D）用来执行合并两个属性：日期属性和时间属性。
• C_DATA 属性可以被执行两个明显同样大小并且用相同数据类型的属性。
1.4.10 每个基本表的主键必须不能直接表现组或任何空闲的物理磁盘地址。应用程序可能不会用相对寻址方式涉及组即便它们只是简单的相对于起始的存储位置有偏移。这并不排除用在为添加、删除和更改记录等普通的处理过程所预备的散列表方案或其他文件组织。例外：历史记录数据能够被用来相对寻址但是其他的必须申请。
注释1: 条款的目的是应用程序（见2.1.7节）执行对所有的存取不用物理标识符但是有合理的标识符的交易或提交交易请求，并且不包括使用者为了解释或帮助关联组的合理的键在表内的位置写的密码。例如：建造逻辑地址到物理地址的转换表来提高性能对于应用程序是不合理的。
注释2: 内在的记录或组的标识符，例如Tuple IDs 或cursors可能会被用在下面的情形下：
1. 对于每个事务处理的执行，所有组最初的访问必须经由在事务处理大纲和其他属性中详细说明的键。最初的访问包括组的插入、删除、恢复和更新。
2. 1.4.10条款不能被违反。
1.4.11 当插入和删除没有在所有的基本表上进行时，系统必须不能被设定在这些事务执行期间来执行特别有利的条件。虽然插入会受到固有的系统配置的存储量供应的限制，但是这肯定没有限制在任何一个最小数目的组等于基本表集的势的5%的和最小键值为两倍于基本表提供的键值的基本表上插入。
注释: 这个需要为基本表的5%的集的势提供的空间配置来为测试运行和定价（如固定空间每条款4.2.3）所遵循。对于空间被设定的和在稍后自动分配空间的系统，当定价时这块空间必须被考虑用来分配和包含为静态空间。
1.4.12 对任何一种估计的像应用程序的一部分的最小的小数精度必须是所有单独条款在估计中最大的小数精度。
1.4.13 在这个文献中的其他特殊标准将应用于执行（例如：3.3节的一致性原则）。
1.5 完整性标准
1.5.1 在任何可能的情况下，在各基本表中主键的值必须是唯一的。例如：在横向分割的基本表中组在所有的划分中的主键值必须是唯一的。
1.5.2 在任何可能的情况下，不许有毛病的组存在于数据库中。当任何一个属性的值不能被决定时说明有毛病的组出现。例如：在纵向分割的基本表情况下一个组肯定存在于所有的部分。
1.6 数据存取透明度需求
数据存取透明度是从应用程序移交的有关部分数据定位和存取机制的系统的性质。用必须符合透明度数据存取当地描写要求的纵向或/和横向的划分的执行。
有限的系列测试不能够证明系统完全支持数据存取透明度。在最小容量描述下必要条件需要设立，这样系统就可以提供数据存取透明度。
注释：这个条款的意图是需要存取物理的和/或逻辑的分区数据会被在像数据文件管理器（DBMS）、操作系统、硬件、或者其他的联合一样的应用程序下的服务性执行被商业利用层直接的且鲜明的提供。
1.6.1 在条款1.3中描述的每九个基本表必须通过对于各基本表分区没有关联的名字来确认。在应用程序（见2.1.7节）中的所有的数据操作必须只能用这些名字。
1.6.2 系统必须防止任何数据操作执行用名字描述会导致违背数据完整性的条款1.6.1（见1.5节）。例如：系统必须预防由纵向划分的基本表的插入一个组时提交的非TPC-C 应用程序除非所有的组已经被插入。
1.6.3 用满足条款1.6.1名字，任何武断的非TPC-C应用程序必须能够操作一些批的组或纵行。
• 可以确定由DBMS潜在支持的任何武断的条件。
• 对所有的基本表利用条款1.6.1所描述的名字并利用同样的数据语义和语法操作。
例如：用来校正对某个基本表的组武断的设置必须同样适合于其他的组的语义和语法。
注释： TPC-C 应用程序用一般的效果机制来操作数据库中的数据。
