使用整数键值代表维度成员的一个原因是减少事实表的大小。同样，整数键允许将看似重复的成员存储在同一个维度表中。例如，在“顾客”维度中，可以有两个都叫Tom的顾客，但每个人都分配了唯一的“顾客”键，保证了维度表中成员键只出现一次。
当然，由于数据仓库是通过提取业务系统的中数据产生的，上述两个Tom毫无疑问已经有了唯一的键值。其中一个可能是C12323A，另一个可能是F23454B。这些键称作为程序键（application key）或业务键（bussiness key）,因为他们来源于用于经营业务的应用程序键。数据仓库为何还要产生新的代理键呢？有三个理由：
<1>代理键可以使整数
<2>代理键使能够整合来自多个系统的数据
<3>代理键拥有渐变维度
即应用程序键不是整数，代理见也可以是整数。这能使数据仓库的事实表占用更小的空间。存储如54352这样的整数占用的空间比存储C125423A这样的字符串更小。当然这是创建代理键的次要原因。
数据仓库整合来自多个系统的数据。源系统常常对相同的维度成员使用不同的应用程序键，或者相反，对不同的维度成员使用相同的应用程序键。如果为每个维度成员产生代理键，则可以不用依赖于应用程序键。例如，在销售系统中，产品应用程序键A543可能指代一辆Mountain-500的自行车；而在制造系统（由完全不同的一群人创建的）中，产品应用程序键A543可能会只带一辆Road-650的自行车。一个更普通的例子是两家公司合并。在母公司的销售系统中，顾客C125423A指的是John Smith,而在子公司的销售系统中，C125423A可能巧合的指的是Abigail Torres。甚至每个美国人唯一拥有的社会保险号也能被授权给另一个人使用。如果政府确定原来拥有这个号码的人已经死亡。在数据仓库使用代理键能预防这样的不测事件。
在数据仓库中使用代理键最具说服力的原因是处理属性随着时间改变的情况。属性值随着改变的维度称作渐变维度（slowly changing demension）.例如，去年Hitch Rack的标价是110美元，但今年变成了120美元。在订单系统中，只要在主产品清单里将标签才从110美元改成129美元，新的订单就会使用新的价格。在数据仓库中，则需要考虑历史因素。是假设Hitch Rack总是按120美元销售的还是反映去年的价格是110美元的相关情况。如果简单的使用应用程序键来代替Hitch Rack,就没有过多的选择。然而，如果有预见性的为该产品创建了代理键，当标价变化时，只需要用新的代理键来创建新的记录，来表示完全相同但只是更贵的Hitch Rack，同时将应用程序键作为另一个属性保存。对单个产品、顾客或其他维度成员来创建多个实例（instance），这得益于代理键的使用。这对于在数据仓库中维护历史信息也是特别重要的。
代理键使大多数数据仓库设计中的关键一部分。这样事实表的外键和维度表中的主键才能完全受数据仓库的控制。