诚挚邀请,小明同学以及各位SAP顾问参与指导,谢谢
Thanks to the presence of leader yang. I am so honnered. :-)
目的:
为当前自主开发的业务系统中,数据划分的不合理之处提出建议和参考,也做为通用业务系统的设计和处理模式的研究。
希望我们做出的系统早日达到,合理的业务、清晰逻辑,以及核心业务分离、设计松散耦合的光辉境界。
讨论范围:
分类处理数据基本理论和实践,以及与设计模式的关系
名词解释:
前言:
随着软件在企业应用中的加深,用户直接描述的业务场景描述的复杂度也不断提高。在进行业务到系统的构思和分析过程中,各种各样分析方法论,为我们提供了多种的分析问题的手段,例如传统UP理论提倡的UML(主要是usercase、swimlane等),AP方法论中提倡的user stories(个人了解不多),另外M$去年(也许是前年)提出来的DSL(Domain Specific Languages)应该也有其方法论(针对vs2005 platform 推出的,资料目前很少,学习中)。而另一方面,传统软件工程(可以参见《Software Engineering Apractitioner's Approace》一书)中的分析手段,关注数据的输入和输出的分析手段,无法适应快速响应的软件项目过程(看来还是AP适合)。但是,是否传统的分析方法就一无是处了呢?鄙人觉得在传统的方式对于数据的处理上有着不可替代的作用,特别在分析和设计核心业务分离、松散耦合等方面,仍然可以发挥重要的作用。(从SAP的系统设计上可见一斑)
企业应用中的业务系统的逻辑划分:
企业应用中,可以从逻辑上划分为业务系统与业务分析系统(多半是OLAP)。(大型应用中通常是逻辑和物理上同时划分)。业务系统,深入到业务环节(涉及业务的部门),处理企业应用的相关事务,并产生日常业务数据。而业务分析系统,在业务系统的基础上对业务系统产生出的数据进行再加工和处理并得出有用的信息,供企业进行自身管理监控、方案战略调正等(领导们专用的东东啊)。业务系统产生的数据是原始数据,在数据挖掘中称之为plain data (印象中的事情,写错别打我),而业务分析系统处理的数据常称为 refined data,是plain data进行经过特殊目的精炼出来的精华。通常情况下,一般的业务系统都包含有简单的报表功能,提供简单的分析数据,在更高级应用中,建立其数据挖掘的引擎后,才具有更深层次的分析能力。从数据挖掘理论上说,任何的数据在某个条件下都具有意义的信息,数学上称之为信息熵(上学时Dr.Daniel说的,至今不会算这个东西);而实际上业务系统不可能做到任何数据都保留。但如果业务系统没有得到的原始数据,不论分析系统如何努力也是搞不东西来的。这之间就存在一个矛盾的平衡点,如何取舍如何划分。本文主要侧重业务系统数据的内容划分和一些的设计原则。
数据类型的定义:
企业应用中较为通用的数据划分方式,是将数据定义为三种类型:系统数据 system data、主数据 master data、业务数据 biz data。而SAP在其系统上,将组织机构的数据(Organization data)分离出来,做为一个较为独立的概念,是不无道理的。而业务数据,也提出业务主数据的概念,进行中也区别对待。
系统数据:
系统数据是指用于系统自身正常运行所需要的数据,缺少这部分的数据、或者这部分数据的不完整都将造成系统不能运行、或运行不正常,并且这部分数据在开发的最初阶段就被基本确定下来,在以后的阶段中基本不会变化。(R/3中定义为 System data:It is the data which R/3 system needs for itself.)最为常见的就是系统的配置文件(例如系统菜单结构的数据,一般认为流程的配置也属于系统数据),对于Java、dotNet平台,通常倾向于使用的xml数据做为系统数据。
系统数据与业务在逻辑上,没有必然的关联性,是完全分离的。在很多业务系统中,容易混淆的是将人员数据、权限数据,还有所谓的“代码数据”(如:亲友的类型配置),认为是系统数据。
组织机构数据:
组织机构数据,从字面上就可以完全理解了。它是指业务系统中,组织机构的配置的数据;它是在系统配置阶段,同时由客户进行定义而进入系统的,进入系统后,这部分数据就很少发生改变。( It is a customizing data which is entered in the system when the system is configured and is then rarely changed. )
从系统数据中划分出组织机构数据,有非常重要的意义。组织机构从本源上来说,同时具有主数据和系统数据的性质。但是组织机构数据有别于一般的主数据之处在于,“极少变化”组织机构数据,一旦发生变化(特别是层次关系的变化),对于整个系统中的业务关系,业务角色的指责分配,就会产生相应的变化。其变动的影响范围的大小,因一个系统的规模的大小,即系统应用到的业务范围的大小(是单独的物料系统,还是有关联的MIS,还是业务更紧密的ERP),的不同而不同。其中常见的影响较大的,将会是人员、角色、权限、流程的数据,而反映到系统业务层。在当前很多系统中流程与核心业务的掺杂的模式,还有权限与核心业务胶浊的情况下,这种影响都将是毁灭性的。
@TODO
主数据定义,作用,核心地位
国外对主数据处理的研究方向,成熟方案简介(包括SAP)
@TODO
业务数据,产生的过程,对于后起数据处理的意义。
核心业务数据(业务主数据)与非核心业务数据的关系。
业务数据取数的设计原则。
@TODO
如何为OLAP取数,设计合理的业务数据内容
Thanks to the presence of leader yang. I am so honnered. :-)
目的:
为当前自主开发的业务系统中,数据划分的不合理之处提出建议和参考,也做为通用业务系统的设计和处理模式的研究。
希望我们做出的系统早日达到,合理的业务、清晰逻辑,以及核心业务分离、设计松散耦合的光辉境界。
讨论范围:
分类处理数据基本理论和实践,以及与设计模式的关系
名词解释:
前言:
随着软件在企业应用中的加深,用户直接描述的业务场景描述的复杂度也不断提高。在进行业务到系统的构思和分析过程中,各种各样分析方法论,为我们提供了多种的分析问题的手段,例如传统UP理论提倡的UML(主要是usercase、swimlane等),AP方法论中提倡的user stories(个人了解不多),另外M$去年(也许是前年)提出来的DSL(Domain Specific Languages)应该也有其方法论(针对vs2005 platform 推出的,资料目前很少,学习中)。而另一方面,传统软件工程(可以参见《Software Engineering Apractitioner's Approace》一书)中的分析手段,关注数据的输入和输出的分析手段,无法适应快速响应的软件项目过程(看来还是AP适合)。但是,是否传统的分析方法就一无是处了呢?鄙人觉得在传统的方式对于数据的处理上有着不可替代的作用,特别在分析和设计核心业务分离、松散耦合等方面,仍然可以发挥重要的作用。(从SAP的系统设计上可见一斑)
企业应用中的业务系统的逻辑划分:
企业应用中,可以从逻辑上划分为业务系统与业务分析系统(多半是OLAP)。(大型应用中通常是逻辑和物理上同时划分)。业务系统,深入到业务环节(涉及业务的部门),处理企业应用的相关事务,并产生日常业务数据。而业务分析系统,在业务系统的基础上对业务系统产生出的数据进行再加工和处理并得出有用的信息,供企业进行自身管理监控、方案战略调正等(领导们专用的东东啊)。业务系统产生的数据是原始数据,在数据挖掘中称之为plain data (印象中的事情,写错别打我),而业务分析系统处理的数据常称为 refined data,是plain data进行经过特殊目的精炼出来的精华。通常情况下,一般的业务系统都包含有简单的报表功能,提供简单的分析数据,在更高级应用中,建立其数据挖掘的引擎后,才具有更深层次的分析能力。从数据挖掘理论上说,任何的数据在某个条件下都具有意义的信息,数学上称之为信息熵(上学时Dr.Daniel说的,至今不会算这个东西);而实际上业务系统不可能做到任何数据都保留。但如果业务系统没有得到的原始数据,不论分析系统如何努力也是搞不东西来的。这之间就存在一个矛盾的平衡点,如何取舍如何划分。本文主要侧重业务系统数据的内容划分和一些的设计原则。
数据类型的定义:
企业应用中较为通用的数据划分方式,是将数据定义为三种类型:系统数据 system data、主数据 master data、业务数据 biz data。而SAP在其系统上,将组织机构的数据(Organization data)分离出来,做为一个较为独立的概念,是不无道理的。而业务数据,也提出业务主数据的概念,进行中也区别对待。
系统数据:
系统数据是指用于系统自身正常运行所需要的数据,缺少这部分的数据、或者这部分数据的不完整都将造成系统不能运行、或运行不正常,并且这部分数据在开发的最初阶段就被基本确定下来,在以后的阶段中基本不会变化。(R/3中定义为 System data:It is the data which R/3 system needs for itself.)最为常见的就是系统的配置文件(例如系统菜单结构的数据,一般认为流程的配置也属于系统数据),对于Java、dotNet平台,通常倾向于使用的xml数据做为系统数据。
系统数据与业务在逻辑上,没有必然的关联性,是完全分离的。在很多业务系统中,容易混淆的是将人员数据、权限数据,还有所谓的“代码数据”(如:亲友的类型配置),认为是系统数据。
组织机构数据:
组织机构数据,从字面上就可以完全理解了。它是指业务系统中,组织机构的配置的数据;它是在系统配置阶段,同时由客户进行定义而进入系统的,进入系统后,这部分数据就很少发生改变。( It is a customizing data which is entered in the system when the system is configured and is then rarely changed. )
从系统数据中划分出组织机构数据,有非常重要的意义。组织机构从本源上来说,同时具有主数据和系统数据的性质。但是组织机构数据有别于一般的主数据之处在于,“极少变化”组织机构数据,一旦发生变化(特别是层次关系的变化),对于整个系统中的业务关系,业务角色的指责分配,就会产生相应的变化。其变动的影响范围的大小,因一个系统的规模的大小,即系统应用到的业务范围的大小(是单独的物料系统,还是有关联的MIS,还是业务更紧密的ERP),的不同而不同。其中常见的影响较大的,将会是人员、角色、权限、流程的数据,而反映到系统业务层。在当前很多系统中流程与核心业务的掺杂的模式,还有权限与核心业务胶浊的情况下,这种影响都将是毁灭性的。
@TODO
主数据定义,作用,核心地位
国外对主数据处理的研究方向,成熟方案简介(包括SAP)
@TODO
业务数据,产生的过程,对于后起数据处理的意义。
核心业务数据(业务主数据)与非核心业务数据的关系。
业务数据取数的设计原则。
@TODO
如何为OLAP取数,设计合理的业务数据内容