1.
背景
日常数据功能开发过程中，会经常要开发人员自己设计物理存储模型（底层模型），在设计过程中往往会遇到一些设计共性问题，比如：物理模型需要的主键采用自然键还是业务键、相关时间戳字段（业务相关表和非业务相关表）、冗余字段是否需要、是否要保留 “历史台账信息”、在使用PowerDesigner设计物理表过程中常遇到的问题等等。
2. 规范要点
2.1自然键OR代理建
自然键：由现有实体存在的属性组成的键值，在业务概念上是唯一的。
代理键：不具有业务含义的键值表示数据唯一。
一个典型的例子，对于自然人唯一性的判别，可以以姓名+身份证件类型+身份证件号码为主唯一标识，但实际我们存储的时候并没有采用这三个属性字段作为唯一键，而是采用了自增序列的代理键，登记序号作为唯一键。
对于自然键，它不需要引入一个新的“非自然”列，并且与业务直接紧密耦合，很清楚透过自然键就可以明确业务上唯一的标准。但是，自然键正是由于直接对接业务属性值，当业务需求发生变更时，可能导致属性发生变更，唯一键可能就要重新指定。
对于代理键，需要引入一个新的“非自然”列，它不与业务直接耦合，更容易维护。当业务需求发生变更时，不会对它产生影响。从某种意义上讲代理键可以看做是直接物理存储唯一性的键值。但其自身由于跟业务没有直接耦合，通常是“不可读”的，无法通过一个代理键值直接定位出数据的业务含义。
这两种键类型，并没有说哪种是最优的，在模型设计中，该如何选用根据实际情况来定夺，选择更合适的。
2.2 时间戳字段
数据的变化一般是发生在字段一级的，在字段一级添加跟踪时间，即给每一个字段盖上一个时间戳。该方法是反映数据变化最详细的记录标识，但也因此会大大增加数据存储量，一般不会采用。我们一般会在行级添加时间戳，当数据发生变化时，此字段同时被修改。在数据抽取程序中，时间戳是非常重要的字段，通过系统时间与时间戳字段的值来决定抽取哪些数据。数据库快照就是在该层次上隐式或显式地加盖时间戳，所有时间推移线上的数据库变化，基本都是基于时间戳来体现。
2.3 可变性质冗余字段保留与否
2.4 元数据字段的统一性
元数据是数据仓库环境的一个重要组成部分。所谓元数据就是数据的数据（可以理解为定义数据的数据）。对于目前我们使用的自然库来说，最为重要并且目前问题较多的地方在于，同一种实体的某种属性（ERD的关键字物理上暂时理解为字段列）在物理化为不同物理存储时发生了变化，这种变化即有名称上的变化也有属性度量上的变化。即：物理表从源端归集到自然库时，对于相同意义的字段，在不同表里定义不一致。
在数据仓库中，相同意义的字段属性应该统一定义，或者定义为具有关联性的字段。前期建设或后期扩建时进行统一处理转化定义。对于提到的统一定义，即名称和字段长度属性保持一致，在元数据中只有一条定义数据与实体属性对应。例如：自然人的姓名字段，在DJ_ZRR表中定位XM，在其他表里涉及到此字段对应的属性时也应该统一使用XM定义。实际中在不同的表里定义是不同的，比如在核心征管中涉及到自然人姓名的定义各式各样不尽相同。这样的数据，如果归集到自然库不做统一处理转化时，就会出现当姓名发生定义的变更时，很难全部将所有自然人姓名进行修改，总会那么几个被遗漏。
在实际设计中，我们经常会遇到在源系统中同一物理字段对应着不同ERD实体的属性。比如：DJXH在源系统中，企业登记表与自然人登记表不同物理表里存储的数据对象完全不一样，但是字段定义却一致。当两种数据放到同一个物理表时为了加以区分就会做名称的调整，在原有字段前面加上来源命名简称前缀做以区分，这样就涉及到了在元数据统一时做到关联性。如：DJXH ----- DJXH_ZRR、DJXH_QY。当发生DJXH定义调整时，就可关联到所有DJXH相关定义的字段，对其进行统一修改。
当一张物理表某几个字段被冗余到另外一张物理表中，为了与被冗余表的相同字段（或者不相同，为了区分是被冗余的字段）加以区分，一般是将冗余表表名或者简称加到字段后边，如：SB_SBXX表的LRRQ字段，冗余到SB_KJGRSDSBGB_MX表中，字段命名为LRRQ_SBXX。
2.5 分区表主键OR唯一分区索引
对于分区表不建议使用主键，因为在创建主键的同时，会自动创建全局唯一索引，当删除分区、TRUNCATE分区、交换分区等会造成主键和全局索引的失效。事后要重建，则会因为数据量非常大导致重建主键要花很长时间，并且有时在删除主键重建时发现，主键被成功删除，但唯一索引却没有被同时删掉。所以，建议采用本地分区唯一索引，如果分区字段设计合理，使用分区索引要比全局索引效率高一些，而且主键和唯一分区索引的效率大体相当，当发生上述的删除分区、分区交换等操作时，只会对相关分区产生影响，重建时也只需要重建相关分区对应的唯一索引。
创建分区唯一索引时，只需要建立唯一索引时包含分区键即可。如：SDFX_ZRRNSD表，主键为：PK_SDFX_ZRRNSD （CYZXH+SDNF+GRSDSSDXM_DM），由于已经包含分区键SDNF，可以直接修改为分区唯一索引：
CREATE UNIQUE INDEX IDX_SDFX_ZRRNSD_1
ON SDFX_ZRRNSD(CYZXH,GRSDSSDXM_DM,SDNF)
LOCAL TABLESPACE TS_GS_ZRRSJK_IDX;
2.6 命名规范
2.6.1 表命名
2.6.2 视图命名
3. 使用PowerDesign设计过程中的注意事项
在使用PowerDesign设计物理表过程中，对于物理表的code、name、comment 以及字段相关的code、name、comment、default value是否要默认等都有一定的规范和要求。主键所带的唯一索引要指定索引表空间、普通索引、唯一索引也要指定索引表空间以及命名规范等。
3.1 物理模型设计
3.1.1物理表设计
表名的code要大写、name 为中文名称、表的comment为表的详细说明
对于表的Owner不建议勾选，默认为None
字段的comment为字段详细注释、name为字段简要说明、字段的code要大写
字段类型要大写
不建议在模型表里，直接定义default value 的值
主键定义：PK + table Name 如：PK_DJ_ZRR；同时应该指定主键使用索引存储表空间
索引定义：IDX_ 开头，后面跟表名（可以简写）加上字段名，同时指定存储的索引表空间
对于本地分区索引有个local属性需要添加，这个在PowerDesign上不好加，可以选择在索引的【Physical Option】里的SQL框里直接填写，如：
3.1.2视图设计
视图的name为中文名称、code需要大写、comment为视图的详细说明
视图的Owner默认为None
视图的Usage默认为updatable
视图模型的【oracle】属性中勾选强制建立的【Force】选项
视图SQL定义的末尾不要出现结束的分号“；”以及注释
分号以及注释会导致PowerDesign生成视图定义语句时报错
日常数据功能开发过程中，会经常要开发人员自己设计物理存储模型（底层模型），在设计过程中往往会遇到一些设计共性问题，比如：物理模型需要的主键采用自然键还是业务键、相关时间戳字段（业务相关表和非业务相关表）、冗余字段是否需要、是否要保留 “历史台账信息”、在使用PowerDesigner设计物理表过程中常遇到的问题等等。
2. 规范要点
2.1自然键OR代理建
自然键：由现有实体存在的属性组成的键值，在业务概念上是唯一的。
代理键：不具有业务含义的键值表示数据唯一。
一个典型的例子，对于自然人唯一性的判别，可以以姓名+身份证件类型+身份证件号码为主唯一标识，但实际我们存储的时候并没有采用这三个属性字段作为唯一键，而是采用了自增序列的代理键，登记序号作为唯一键。
对于自然键，它不需要引入一个新的“非自然”列，并且与业务直接紧密耦合，很清楚透过自然键就可以明确业务上唯一的标准。但是，自然键正是由于直接对接业务属性值，当业务需求发生变更时，可能导致属性发生变更，唯一键可能就要重新指定。
对于代理键，需要引入一个新的“非自然”列，它不与业务直接耦合，更容易维护。当业务需求发生变更时，不会对它产生影响。从某种意义上讲代理键可以看做是直接物理存储唯一性的键值。但其自身由于跟业务没有直接耦合，通常是“不可读”的，无法通过一个代理键值直接定位出数据的业务含义。
这两种键类型，并没有说哪种是最优的，在模型设计中，该如何选用根据实际情况来定夺，选择更合适的。
2.2 时间戳字段
数据的变化一般是发生在字段一级的，在字段一级添加跟踪时间，即给每一个字段盖上一个时间戳。该方法是反映数据变化最详细的记录标识，但也因此会大大增加数据存储量，一般不会采用。我们一般会在行级添加时间戳，当数据发生变化时，此字段同时被修改。在数据抽取程序中，时间戳是非常重要的字段，通过系统时间与时间戳字段的值来决定抽取哪些数据。数据库快照就是在该层次上隐式或显式地加盖时间戳，所有时间推移线上的数据库变化，基本都是基于时间戳来体现。
2.3 可变性质冗余字段保留与否
2.4 元数据字段的统一性
元数据是数据仓库环境的一个重要组成部分。所谓元数据就是数据的数据（可以理解为定义数据的数据）。对于目前我们使用的自然库来说，最为重要并且目前问题较多的地方在于，同一种实体的某种属性（ERD的关键字物理上暂时理解为字段列）在物理化为不同物理存储时发生了变化，这种变化即有名称上的变化也有属性度量上的变化。即：物理表从源端归集到自然库时，对于相同意义的字段，在不同表里定义不一致。
在数据仓库中，相同意义的字段属性应该统一定义，或者定义为具有关联性的字段。前期建设或后期扩建时进行统一处理转化定义。对于提到的统一定义，即名称和字段长度属性保持一致，在元数据中只有一条定义数据与实体属性对应。例如：自然人的姓名字段，在DJ_ZRR表中定位XM，在其他表里涉及到此字段对应的属性时也应该统一使用XM定义。实际中在不同的表里定义是不同的，比如在核心征管中涉及到自然人姓名的定义各式各样不尽相同。这样的数据，如果归集到自然库不做统一处理转化时，就会出现当姓名发生定义的变更时，很难全部将所有自然人姓名进行修改，总会那么几个被遗漏。
在实际设计中，我们经常会遇到在源系统中同一物理字段对应着不同ERD实体的属性。比如：DJXH在源系统中，企业登记表与自然人登记表不同物理表里存储的数据对象完全不一样，但是字段定义却一致。当两种数据放到同一个物理表时为了加以区分就会做名称的调整，在原有字段前面加上来源命名简称前缀做以区分，这样就涉及到了在元数据统一时做到关联性。如：DJXH ----- DJXH_ZRR、DJXH_QY。当发生DJXH定义调整时，就可关联到所有DJXH相关定义的字段，对其进行统一修改。
当一张物理表某几个字段被冗余到另外一张物理表中，为了与被冗余表的相同字段（或者不相同，为了区分是被冗余的字段）加以区分，一般是将冗余表表名或者简称加到字段后边，如：SB_SBXX表的LRRQ字段，冗余到SB_KJGRSDSBGB_MX表中，字段命名为LRRQ_SBXX。
2.5 分区表主键OR唯一分区索引
对于分区表不建议使用主键，因为在创建主键的同时，会自动创建全局唯一索引，当删除分区、TRUNCATE分区、交换分区等会造成主键和全局索引的失效。事后要重建，则会因为数据量非常大导致重建主键要花很长时间，并且有时在删除主键重建时发现，主键被成功删除，但唯一索引却没有被同时删掉。所以，建议采用本地分区唯一索引，如果分区字段设计合理，使用分区索引要比全局索引效率高一些，而且主键和唯一分区索引的效率大体相当，当发生上述的删除分区、分区交换等操作时，只会对相关分区产生影响，重建时也只需要重建相关分区对应的唯一索引。
创建分区唯一索引时，只需要建立唯一索引时包含分区键即可。如：SDFX_ZRRNSD表，主键为：PK_SDFX_ZRRNSD （CYZXH+SDNF+GRSDSSDXM_DM），由于已经包含分区键SDNF，可以直接修改为分区唯一索引：
CREATE UNIQUE INDEX IDX_SDFX_ZRRNSD_1
ON SDFX_ZRRNSD(CYZXH,GRSDSSDXM_DM,SDNF)
LOCAL TABLESPACE TS_GS_ZRRSJK_IDX;
2.6 命名规范
2.6.1 表命名
2.6.2 视图命名
3. 使用PowerDesign设计过程中的注意事项
在使用PowerDesign设计物理表过程中，对于物理表的code、name、comment 以及字段相关的code、name、comment、default value是否要默认等都有一定的规范和要求。主键所带的唯一索引要指定索引表空间、普通索引、唯一索引也要指定索引表空间以及命名规范等。
3.1 物理模型设计
3.1.1物理表设计
表名的code要大写、name 为中文名称、表的comment为表的详细说明
对于表的Owner不建议勾选，默认为None
字段的comment为字段详细注释、name为字段简要说明、字段的code要大写
字段类型要大写
不建议在模型表里，直接定义default value 的值
主键定义：PK + table Name 如：PK_DJ_ZRR；同时应该指定主键使用索引存储表空间
索引定义：IDX_ 开头，后面跟表名（可以简写）加上字段名，同时指定存储的索引表空间
对于本地分区索引有个local属性需要添加，这个在PowerDesign上不好加，可以选择在索引的【Physical Option】里的SQL框里直接填写，如：
3.1.2视图设计
视图的name为中文名称、code需要大写、comment为视图的详细说明
视图的Owner默认为None
视图的Usage默认为updatable
视图模型的【oracle】属性中勾选强制建立的【Force】选项
视图SQL定义的末尾不要出现结束的分号“；”以及注释
分号以及注释会导致PowerDesign生成视图定义语句时报错