维度表中的主键通常有两种选择：自然键（Natural Key），它是业务系统中已经存在的，通常是具有一定业务含义的一个字符型的标志符，可以唯一地标志维度表中的每一条记录。比如机构的代码、缩写、时间标签等。另一种是代理键（Surrogate Key），通常是数据库系统赋予的一个数值，是自增型的，按顺序分配，没有内置含义但也可以唯一地标识一条维度信息。
项目经验，推荐采用第二种，即代理键。原因如下：
首先，自然键虽然在逻辑上可以唯一地标识出一条维度信息，但它通常是字符型的，且一般比较长，若用它作为维度表中的主键，那就意味着在事实表中也要加入同样的外键信息，而事实表记录行数往往是巨大的，在多个维度表上重复这样的做法会使事实表由于列宽过于膨胀而导致性能的急剧下降。
其次，代理键可以作为数据仓库与源系统之间的“缓冲”。自然键通常具有一定的业务含义，但日久天长，这些信息是有可能发生变化的，比如身份证号码，由最初的15位变成了现在的18位。如果这种主键一旦发生了变化，由于它同时作为事实表中的外键，必然会对事实表产生影响，因为已有的事实记录已经找不到与之匹配的维度记录，这就带来了很大的麻烦。但若采用代理键作为维度表中的主键，就完全可以把这些变化屏蔽在维度表内，不会对事实表产生任何影响（当然这个还要结合缓慢变化维度的处理）。
最后，从关联效率考虑，数值型的关联要比字符型的关联快很多。
键约束的取舍也是数据仓库设计过程中一个很值得注意的问题。在OLTP系统环境中，数据的完整性通常靠两种方式来保证，一是应用程序的逻辑保证，另一个是数据库结构自身的约束机制。这两种方式相互补充，而数据仓库环境中的情况则完全不同，数据仓库中数据的完整性更依赖于应用程序，也就是ETL系统的保证。
首先，ETL系统运行时间虽然很长，但其结构是简单的，重复地抓取、清洗、转换、加载动作。与其相比，OLTP系统可能同时在一张表上执行大量并行业务操作。
其次，事实表的唯一入口是维度表，按照维度建模的思路实现ETL程序，只会产生不准确的维度信息，不可能在事实表中产生重复记录。第三，与OLTP系统相比，数据仓库系统没有交互式人机录入界面，不存在“人为”错误。
因此，在我们比较关注数据加载时间的情况下，最好从数据仓库中删除一些不必要的约束，其中包括主键约束、外键约束及唯一索引约束，这些约束规则可以在外部得以实施。