本站原创逻辑建模是指企业级会计信息系统的概念模型被转换为面向对象的数据库管理系统、RDBMS（Rational Database Management System,关系型数据库管理系统）,或者不使用任何数据库管理系统的程序代码段.本文拟论述的是将REA概念模型转换为RDBMS的逻辑模型过程中出现的问题及其对策.物理建模就是将数据库设计结果在某个特定应用软件包中实现,比如利用SQL Server 2005或Microsoft Access 2010数据库管理系统来创建逻辑模型中的所有数据表及其表间连接.
一、REA模型转化过程中的问题
RDBMS是Codd在集合理论和谓词逻辑基础上开发的.RDBMS的基本组成部分是各种关系及其连接.关系是一种二维的数据存储结构,通常称为数据表,或简称为表.一张数据表表示一个实体（如企业的存货）,或者表示若干个实体间的连接（如存货资源与采购事件的连接）.在RDBMS内部,会计信息实际上不是以凭证、账簿、报表的格式存储的,而是被分解成资源、事件、参与者三方面的信息组件,与非会计数据一起分别存储在多个数据表中.会计人员需要凭证等会计资料的时候,RDBMS先从多个数据表中分别读取出这些会计信息组件,再组合拼装成账、证、表格式的会计信息,以查询和视图的方式输出给会计人员浏览或打印.传统会计账户间的借贷关系通过数据表之间的连接实现.RDBMS中各数据表之间通过主键和外键相连接.主键是能够唯一确定实体中每个实例的一个或多个属性,如“存货”数据表中的“InvID”属性.外键是在本数据表中不是主键,而在连接的数据表中必须是主键,如“存货”数据表中的外键――“PurID”属性,一定是“采购”数据表的主键.逻辑模型的优劣评价标准应综合为三个方面：重复录入会计信息（冲突）；会计信息的缺失（空值）；RDBMS占用的系统软硬件资源（数据表及其连接的个数）.
（1）会计信息的冲突和缺失.在逻辑建模阶段,企业级会计信息系统的分析设计人员通常将外键和对应数据表中的主键名称设置一致,这样可以提高会计信息查询的可靠性,如“存货”数据表中的外键――“PurID”属性.此时RDBMS对会计信息的录入有两个要求：一是参照完整性――各数据表中的外键属性取值,要么取空值,要么取关联数据表中存在或发生的属性值,如会计人员在录入“存货”数据表中的“PurID”属性值时,要么先空着（不录入）,要录入只能重复录入采购数据表中已经存在的采购.二是实体完整性――每个数据表的主键不能取空值,必须录入会计信息.空值会导致会计信息的缺失,录入了相关数据表中没有的数据会导致会计信息间彼此矛盾,产生冲突.会计人员在录入信息时通常意识不到自己录入的信息会产生冲突.比如同一会计科目名称,会计人员一次录入“实收资本（股本）”,而另一次录入“实收资本(股本)”.这两条会计信息在会计人员看来是相同信息,而在企业级会计信息系统内部,只要有一点差异,哪怕只是括号的不同,企业级会计信息系统一律认为是不同的信息,于是产生了信息的冲突问题.在实务界,空值问题尤为普遍.空值占用了大量的存储空间,就像工厂里闲置的仓库或生产设备一样,直接导致系统运行缓慢.
（2）违反“同一张数据表中,相同会计信息只能出现一次”规则.RDBMS对会计信息录入的另一个要求,也是最重要的一条规则是：同一张数据表中,同一事实只能出现一次.事实是指若干个非主键属性值的配对,如“开户银行”与“银行地点”的取值为“中国工商银行海淀区双安储蓄所”在“海淀区北三环西路2号”,这两条信息的组合就称为一个事实.违反这一重要规则的情形通常分为以下两类：一是多条会计信息记录中含有同一事实.如果在同一张数据表中出现了两条或两条以上的记录中,同时含有“中国工商银行海淀区双安储蓄所”在“海淀区北三环西路2号”信息,则该数据表违反了“同一张数据表中,同一事实只能出现一次”的规则.这样的会计信息是不允许输入企业级会计信息系统的,但会计人员确实需要系统存储和处理这些信息,如何将其分解或转化,并录入企业级会计信息系统中是一个非常棘手的问题.二是一条会计信息记录中含有多个事实.这种违反规则的情形称为重复组,即一条记录中的同一属性中录入多个值.如在“客户”数据表的“联系”属性中,同一条客户记录中录入了办公、住宅、手机3个不同的属性值.违反这一规则的后果是：导致关系型的数据表退化为非关系型,而非关系型数据表中,不能根据集合理论和谓词逻辑来查询和操作会计数据,直接导致会计信息存储、处理和输出时间延长,会计信息输出的及时性急剧降低,或者造成查询输出的会计信息不准确或相互矛盾,甚至引起企业级会计信息系统的操作异常,还能导致宕机和系统瘫痪.非关系型数据操作有时会产生不可预知的错误,直接影响会计信息的可靠性和相关性,操作异常和所产生的会计信息的高度不确定性,很容易让会计人员失去对企业级会计信息系统的信任和放弃使用.
二、REA模型转化过程中的整体对策：规范逻辑建模流程
如果企业级会计信息系统的分析设计人员能遵守下述“五步法”的建模流程,那么绝大多数上面提及的问题都可以规避掉.
（1）为概念模型中的每个实体单独创建一张数据表.这个步骤又可进一步细分为两个分步骤：实体中的每个属性都设置为一个属性列；实体中的每个实例都转换为数据表中的一条记录.如将存货资源和采购事件分别设置为两个单独的数据表,将存货数据表的主键设置为InvID,将采购数据表中主键设置为PurID.
（2）创建一个单独的数据表阐述概念模型中的每个多对多的关系.如存货资源和采购事件之间,因为一次可以采购多种存货,一种存货可以分多次采购,所以这两个实体间是多对多的关系.此时需要另外创建一个“存货采购”数据表,存储存货和采购之间的多对多关系的采购量、单位采购成本等信息.
（3）对于概念模型中那些参与基数为“（1,1）――（1,1）”的会计事项,再次考虑是否要将其合并为一个实体,只创建一个数据表.如果确实仍然分别使用两个实体表示,就将其中一个实体数据表的主键加入到另一个实体数据表中,充当外键.比如,某一特定企业只允许现销,不允许客户分期付款,而且企业也不从其他渠道取得收入,销售事件和收款事件又需要分别存储不同的会计信息.此时,基于REA本体论的概念模型中就用“（1,1）销售――（1,1）收款”来表达销售与收款两个会计事项之间的关系.本概念模型片段转化为逻辑模型时,就将收款数据表中的主键CashReceiptID,加入到销售数据表中作为外键.
（4）在剩下的关系中,对于有一方实体的参与基数为（1,1）的关系,将另外一方实体的主键放入（1,1）一方的实体数据表中作为外键,这种现象称为载入.比如,销售数据表和客户数据表之间,每次销售有且只有一个客户,而同一客户可以多次采购,客户信息（如信用等级等）允许在销售事件发生前就录入到企业级会计信息系统中.此时,销售事件和客户参与者之间的关系就可表示为“（1,1）销售――（0,N）客户”,并将客户数据表的主键CusID加入到销售数据表中作为外键.
（5）对于剩下的关系,如果关系的一方或双方的参与基数都是（0,1）,有两种可能结果：将另一实体的主键载入（0,1）一方的实体中作为外键；单独创建一张数据表,并将两个实体的主键都放入该表中作为联合主键.
比如,某企业采购后,或者付款,或者退货.平均有98%的采购后付款,只有2%是退货.企业可以赊购,但不能分期付款.企业可以一次同时退回以前多次采购的货物.则采购、付款、退货之间的关系在任务级的REA概念模型中表示为“（0,1）采购――（0,1）付款”和“（0,1）采购――（1,N）退货”.对于关系“（0,1）采购――（0,1）付款”,存在两种可能方案：将采购表的主键载入到付款表中,或者将付款表中的主键载入到采购表中；对于关系“（0,1）采购――（1,N）退货”,也存在两种可能方案：将退货表主键载入到采购表中,或者单独创建一个数据表.
三、REA模型转化过程中局部对策：载入性视角下的权衡机制
针对上述五步法中的第五步,由于存在两种以上的可能方案,必须权衡和选择.在此笔者引入载入性来作为抉择依据.载入性是指除了空值外,某个属性可能的取值个数.如果属性的大多数取值都是非空的,浪费的存储空间就小,该属性的载入性就高.如果载入性高的属性正好是（0,1）对边的数据表的主键,那么该主键就非常适合载入到（0,1）一边实体数据表作为外键.此时的抉择是：载入优于增加数据表,举例阐述如下：
对于“（0,1）采购――（0,1）付款”关系,如果该企业签发的支票中,有2/3是支付给非采购业务的,如员工工资、股利分红、偿还贷款等.也就是说,如果将采购表中的主键PurID添加到付款表中,将有2/3的PurID属性值是空值,只有1/3是真正有用的信息,即浪费了2/3的存储空间,这样的载入性很低.再考察将付款表中的主键DbsID添加到采购表中.从上面给出的信息可知,有98%的DbsID属性值是非空的有用信息,只浪费了2%的空间,这时的载入性很高.于是做出抉择――载入：将付款表中的主键DbsID载入到采购表中作为外键.
对于“（0,1）采购――（1,N）退货”关系,根据前面给出的信息,大约有2%的采购退回,这个2%的载入性太低了,如果将销售退回表中的主键RetID添加到采购表中作为外键,添加后的表中的RetID列的属性值中有98%是空值,这将要浪费98%的数据库空间.如果多建一个“预留”数据表,采购数据表中将会有2%的数据记录被加入到该预留表中,也就是说新建这个表只多占用了2%的数据库空间,但会使得查询变复杂些.实施经验告诉人们,浪费98%的数据库空间的数据表处理效率比多创建一个数据表还要低.两害相权取其轻,因此这种情况下的最优选择是：单独创建一个数据表来表示采购与退货之间的预留关系.