项目实施过程中的数据管理

项目实施过程中的数据管理

管理信息系统实施成功三大因素依次为：人、数据、技术，也许有些人不完全认同，但是数据的重要性是大家不可否认的。我下面为大家整理了关于项目实施过程数据管理的文章，希望对你有所帮助！

1. 数据管理的组织机构的建立

为了更好的进行软件系统的数据管理，应该从组织机构角度来做考虑，建立单独的组织机构来管理数据相关工作，或者在实施小组里面专人总负责。

软件开发商和客户核心的业务骨干一起制定数据规范，客户提供符合规范的业务数据，只有符合规范的数据才能进入系统。

2. 数据管理的原则

强调客户和软件开发商的2方项目组成员做到”不能有‘我以为’的思想“，一旦有如此思想，很容易陷入闭门造车，项目需求很容易走样，因为客户à所有的客户，也是在‘我以为 ’。项目组要想做到控制住需求，一定要抛开自己的设想。所以任何一个项目组成员，第一句话就告诉他，不要有”我以为“的想法。把‘我以为’变成‘客户认为 ’(最好是客户和软件提供商一致认为)，这才是最重要的。

这又回到了项目管理上。我在这里实际上只是想从数据管理这个更具体的角度来阐述问题。

3. 数据入口的单一性

同一数据必须一次、一处进入系统，保证其准确性，及时性和完整性和入口的单一性。管理控制一体化是系统的目的，如果一个数据在多个地方存储，很容易造成数据的不一致。

4. 数据副本管理/数据版本管理

虽然上面提到了数据存储的单一性，但是有些时候也需要存储副本数据。存储这些副本数据的目的就是为了在使用数据副本的地方不受到数据源的变化的影响。

例如：数据1在业务A进入系统，业务B使用到了数据1，但是为了避免在业务B使用了数据1后，业务A又把数据1的修改影响到业务B，那就需要业务B在使用数据1时候保存副本。

比如：城市拆迁资源计划系统的拆迁合同在使用房源业务录入的房源房屋面积信息时，就使用了副本机制，在合同使用房屋面积时候，把面积信息存储下来，当合同构筑完成时候，如果相应的房屋面积信息发生了变动，就用另外的业务来处理这个数据变动的相应处理(比如，使用房源的差价款合同来处理)。

有朋友建议用配置管理系统，把数据版本机制引入了业务数据里面。做过J2EE的项目，都知道很多地方可以通过配置来进行管理。其实这个思想延伸到数据库模型的设计时候，就体现出来了业务数据的配置管理的思想的使用。

我们其实也有是用这个思想，但是主要体现在 在基于数据表级别上用数据级别+历史编号 来识别有效的数据。1个很简单的例子：

一个员工的姓名原来 是aa, 后来改委bb，可以通过历史编号 找到原来 的信息是bb通过数据级别识别现在的有效数据是aa，我们把数据版本控制更多的是采用‘数据级别’加‘历史编号’另外还加上了一个‘生效日期’， ‘截止日期’这2个时间戳另外，实际软件系统的历史业务数据进入系统就比较烦，可能需要使用版本管理机制来处理才行得通。

5.建立数据等级制度

软件项目实施中业务规则经常会陷入一个两难的境地，如果业务规则加强，很多数据数据达不到规范化的要求，无法入机如果放宽控制，很多垃圾数据就进入了，大家都明白一个道理，对于软件系统，垃圾数据进去，肯定是垃圾数据出来，统计查询结果肯定是这样的。

可以建立数据的等级制度，制定数据进入系统的最低要求。达到最低要求才能进入系统，比如：

业务A,需要数据a1,数据a2,,数据a3, 数据4。我们可以制定进入系统的关于业务A的条件是必须要有数据a1,a2才可以进入系统(也就是最低要求)，如果提供的业务数据同时有数据a1,数据 a2, ,数据a3,那就是更高一级的数据(第二级数据)，如果业务数据在满足第二级数据的基础上，提供了数据4，那就是第三级数据。

如果用过J2EE平台的同行理解起来就比较容易，这实际上就是JMS基于主题的消息管理思想用于软件系统一个具体例子而已，这里不过是强调的是用于管理数据的信任等级而已。

其实很多软件项目开始制定的的数据规范，一般到后来都执行不下去，主要是太理想化了，也许只有到系统真正用起来了，系统数据的信任等级才能上去。所以我觉 得应该在系统开始时候就把数据分等级，不同的等级，业务给与适当不同的处理，这样也便于后期的业务进行查询统计分析或者数据挖掘。

这种思想实际上就是将数据可以信任的程度进行分类而一般的软件系统是把数据定义为两类，可以进入系统，不可以进入系统我在这里设想的是，从数据可以信 任的角度出发，分成多种类别，使用了一个小数来描述信任程度，而不是一个二值逻辑变量来描述这样从建立软件系统整体模型的时候，把数据信任管理纳入考虑 之内，在进一步作业务分析，决策支持或者数据挖掘时候是比较有好处的当然进一步延伸可能就需要从OLTP/OLAP混合建模来考虑，不过真要到那个高 度，可能项目范围就扩大了很多，具体怎样 *** 作，还要看项目具体情形。

当然，在软件项目实际 *** 作的时候，可能还会遇到另外一个问题，很可能用户会乱用这个数据信任程度的概念，我个人的建议是在项目实施中如果可能的话，优先进 入信任等级高的数据，然后才是信任程度低的数据当然也可以从人员来角度作为切入点，信任等级越低的数据，进入系统就需要的业务更熟悉的人员来 *** 作录入， 而且经过的业务处理步骤就越多。一句话，数据信任程度越低，就应该受到的审查/检察越多。

在现实中稍微规模大一点的软件系统涉及到的组织机构都是比较大的，有很多还可能是松散的组织管理模式。在这类组织机构中，同样的业务数据可能很多部门都会是数据录入点和数据分析点，为此可以从数据采集/来源角度来描述数据本身。

从当前项目利益来说，数据来源管理方便数据查询分类，长期来说可以建立起数据信任等级。

对于数据来源的识别，一般需要有特定信息来记录数据的来源，特别是一些大型企业当然分支机构较多的公司企业政府，也应该这样来管理。

事实上，数据来源管理是数据信任管理的进一步延伸，是数据信任管理的前置条件。一个数据，可以是来自于A部门的也可能是来自于B部门的。为了方便统计查询和数据信任管理的加强，应该记录下数据的来源地。

6.具体 *** 方式可以有以下几种：

1) 数据录入人员的工作人员编号，知道了数据录入人员的编号，就知道数据的来源地。

当然，实际工作种存在人员调动，替 *** 作(1个人用另外一个人的身份进入系统数录入)，这些都有可能需要考虑到，否则可能造成数据来源管理失效。

2)另外一种方式就是直接记录数据录入的部门编号。

这种方式弊端就是不能记录下数据的具体 *** 作人员。

其它说明：如果系统中引入了工作流产品，数据来源这部分工作可以由工作流来担任。具体例子：在现实的软件系统中可能存在一个主数据库/数据中心，若干分数 据库/数据中心，系统在每过一定时间进行数据上传/下载，为了进行数据合并和控制数据的修改，应该每个分数据中心只能处理修改自己的数据，可以查询总数据 中心/其他分数据中心的数据。如果没有引入数据来源管理(数据属地管理)和数据版本的控制机制，不知道系统在作数据中心合并会怎样子?

7.数据项的分类编码

数据项的分类编码，实际上是数据项来源管理的一个具体延伸。数据项编码的目的'就是更快更好的识别数据代表的业务意思。一个典型的例子就是ERP中的BOM表(基本物料清单)。

数据项的分类编码，不只是在系统模型建立上有指导意义，在进入系统的业务数据的规范化同样有指导意义。

数据项的业务编码和系统编码分离。业务编码很多时候只是为了识别业务数据的需要，很难保证业务数据的唯一性要求。而且业务编码可能会发生变动，有些单位的 总体规划从调研到讨论制订、到项目审批通过，再到最终实施，常常几年过去了，需求发生变化，这种编码规则不发生变动几乎不可能。2000年我参与的一个企 业软件系统，就一个产品编码规则2个月就发生了5次变动。从更长的时间范围内来说，应该考虑数据产生时期问题，不同时间阶段产生的业务数据，使用的业务规 则不一样，数据编码这个层次很多时候很难识别数据当时的业务环境。

以一个简单的例子来说明：

业务数据表的primary key系统应该是系统定义的，而数据项的业务编码只能作为索引或者备用键使用，这样就减少了数据业务编码规则的变动对系统影响减少到更小的程度。

8.算法的版本化

本来我打算在前面的基础上，再谈一下业务流程的管理设置问题，不过，现在工作流思想深入人心，我也就跳过了。我打算从数据的核心业务处理，算法处理角度来阐述。

其实在现实中的软件项目中，大家提到的较多的BPR,工作流这些东西，但是很少提到算法这个单词。当然，不可否认，很多软件项目，特别是电子政务/OA的 业务主要是体现在流程/文件上，算法这部分比较简单(当然，我这样说，有人可能不认可，暂且就不争论它了)，就没有必要去强调算法的重要性了。

为了避免垃圾数据进入系统，垃圾数据出来，有必要对数据进行分类管理。正如前面提到的那样，对于进入系统的数据，进行信任等级划分，数据来源的分类但是 对于系统出口，为了避免出现垃圾数据，需要在数据处理阶段，也要进行分类处理，这里就引入了算法的版本化，来适应不同的数据/业务需要。

在实际项目中，可能不同信任等级的数据，采用不同的算法去处理数据，这样才使得数据的处理更有针对性，更符合实际需要。

从需求变更的角度出发，软件开发商可以先实现一些数据信任程度低的算法，然后再根据项目实际情况，决定是否实现更高一级数据等级的算法。在现实软件项目， 数据信任等级低的采用的算法也会简单一些，由于需求变更，增加了新的数据信任等级更高的数据，这时候可以考虑暂时采用低等级的算法进行处理，然后再结合人 工干预，达到数据处理的要求。大家都明白一点，算法复杂，测试的难度就大，但是使用这些更高等级的算法的几率是很少的，处于成本的原因可以把这些算法的实 现滞后。

当然我这样说，并不是意味着放弃高等级的算法，一些根据项目实际情形需要来 *** 作。

数据根据信任程度分成等级，呵呵，这就是所谓工厂方法模式嘛，算法也分成等级结构，这就是所谓的模板方法模式。

数据在处理后，应该记录下被使用的算法版本，这样才便于以后统计查询分析或者数据挖掘之类工作的开展。

例如：在一个商品交易中，一个商品可能被购买的价格是正常价格，节假日优惠价，会员优惠价，在交易流水账中，应该记录下交易时候是采用的那个价格类型，原始价格多少，实际购买价格多少。记录下原始价格，是因为，商品的原始价格本身可能是变化的。

再以拆迁资源计划系统为例，房屋补偿的价格价格可能是来自于管理参数，也可能是来自于申请，实际到底是来自于哪个，算法应该记录下来。

9.业务规则使用的版本化

前面已经提到了数据录入的版本化，还有算法的版本化，也就是计算结果的版本化。但是还没有谈到一点，到底啥时间该采用哪个版本算法。

在J2EE项目中，一般是采用配置文件的方式来控制版本。从配置管理角度的来说，一切都根据配置文件来决定使用哪个版本的数据录入的分级(数据信任程度分级)，然后根据配置文件决定数据处理使用的算法版本。

其实在J2EE项目中，可以采用类似apache commons-validator这样的包，来进行数据录入的信任等级建立。

前面都已经提到了从工厂方法模式的角度来建立数据信任等级制度，但是并没有解决到底啥时间采用哪个方法处理数据。也许有人建议，采用工厂方法模式的思想， 把数据当成产品，把算法当成工厂，来处理(注意：不是制造)数据。这个想法也许能够满足一些系统的需要，但是更多时候是失效。

为此，我觉得有必要把算法的分配使用当成为一个业务管理策略来管理，通过单独的业务模块去设置业务的算法管理策略，可以把这些策略保存为配置文件或者直接 保存到数据表在J2EE项目中，常用的方式使用XML的格式保存为配置文件，但是如果这个策略比较复杂的时候建议还是保存到数据表。

VSS6.0现在是作为Microsoft Visual Studio6.0这个开发产品家族的一员，如Visual C++6.0和Visual J++6.0一样。

1. VSS的简单工作原理

Microsoft的VSS6.0解决了软件开发小组长期所面临的版本管理问题，它可能有效地帮助项目开发组的负责人对项目程序进行管理，将所有的项目源文件（包括各种文件类型）以特有的方式存入数据库。开发组的成员不能对该数据库中的文件进行直接的修改，而是由该版本管理器将该项目的源程序或是子项目的源程序拷贝到各个成员自己的工作目录下进行调试和修改，然后将修改后的项目文件作Checkin提交给VSS，由它进行综合更新。VSS也支持多个项目之间文件的快速高效的共享。当某个成员向VSS中添加文件时，该文件将会被备份到数据库中，以便所有的成员都能共享该文件。而且每个成员对所有的项目文件所作的修改都将被记录到数据库中，从而使得修改的恢复和撤销在任何时刻，任何位置都成为可能。小组的成员可能得到该项目的最新版本，对它进行修改，并保存一个新的版本。

VSS的项目组织管理使得开发小组的协调变得简单容易且很直观，当一个和一组文件发放给另一个成员，小组，W eb站点或是任何其他的地址，VSS确保他们之间的真正共享及所选的一组文件的不同版本的安全性。现在，越来越多的开发者可以通过他们的开发环境来访问VSS的功能。而且VSS可以很容易地于Microsoft Access、 Vi sual Basic、 Visual C++、Visual FoxPro和其他的开发工具集成在一起，一旦VSS 集成到开发环境中，就可以象控件一样使用，能够很好地体现出VSS的易用性和强大功能。

2.VSS中的几个重要概念

为了更好的了解VSS，有必要对如下一些概念给予说明。

首先是项目的概念，所谓的项目是一组存在VSS中的文件（任何类型），可以在项目中或是项目之间进行文件的添加、删除、编辑和共享。一个项目与 *** 作系统的文件夹有很多的相似之处，但它更好地支持文件合并、历史和版本控制。所有的文件存在VSS数据库的项目中，开发组成员不能在VSS中的主备份文件上工作（除了检查和版本比对等特殊情况外）而是VSS为每个成员在各自的工作目录下提供一个拷贝以供工作。尽管在没有工作目录的情况下也可以查看某个文件，但如要真正在VSS管理下工作，就必须要创建一个工作目录。

VSS能够维护一个文件的多个版本，包括一个从不同版本之间进行修改的记录。版本控制包括如下方面：

组内协调-在一般情况下，确保在任何时刻都只有一个成员对某个特定的文件进行修改，这样可以防止文件被其他成员的修改意外更新。当然，VSS管理员可以改变此缺省设置以允许对单个文件同时有多个Checkout，并且仍禁止对他人的修改进行覆盖。

版本跟踪-对老版本的源代码和其他文件进行归档和跟踪，而且这些版本能够被重新得到以便进行bug跟踪或其他目的。

跨平台开发-支持同一代码在跨多个开发平台时的版本控制。

重用或面向对象代码-跟踪哪些程序使用了哪些代码可被重用的模块。

版本控制的涵义在以后的章节中将会得到更进一步的论述。

我们已经知道，VSS提供版本控制和历史服务，以保证一个文件的每个版本都是可恢复的。VSS用日期/时间戳来记录文件是何时被Checkout或是何时被修改的，它主要有三种方法来跟踪文件和项目的版本：

版本号：这是由VSS维护的内部数码，用户对它没有控制权。每个文件和项目的每个版本都有一个版本号，这些版本号总是一个整数且是递增的。

标签：这些是用户赋给某个项目或文件的某个版本的一个字符串，可以是任何格式的长度不超过31字符的字符串。

日期/时间戳：它给出了一个文件何时最后被修改的信息，或者是一个文件何时被Checkin。VSS同时支持 12小时和24小时的时间格式。

工作目录是用户真正对项目文件进行调试修改的地方，当用户Checkout或提取一个文件时，VSS将该项拷贝到用户的工作目录下，当用户修改了该文件并将其Checkin或提交时，VSS再将它从用户的工作目录拷回到VSS 的数据库中。在用户作Checkout时，VSS将会自动管理他的工作目录，诸如创建必要的子目录。而且工作目录可以随时创建或修改。

3. VSS6.0的一些新增的特征和功能

归档和恢复-在VSS6.0中这两个 *** 作是在一个用户界面友好的VSS管理员wizard中进行的，而在以前的版本中，它们只能通过命令行来实现。

移动文件-当用户移动文件时，VSS6.0自动将该文件共享到一个新的项目中，并在原项目中将其删除。在新项目中，该文件的属性是共享的。

多个项目之间的差异比较-该功能允许用户在不同的项目之间进行差异比较。

单个文件的展开-在以前的版本中，VSS只能展开一个目录（文件夹），在VSS6.0中，同时可以展开一个文件。

快速提取-由于VSS6.0在性能上的提高，现在的文件提取速度比以往VSS版本的快两倍左右。

历史信息过滤-VSS6.0支持查看那些没有标签的文件和项目的历史。

清除临时文件夹选项-该新功能可使用户很方便地清除临时文件夹。

检查外部的超连接-在VSS的较早的版本中，只有内部的超连接和项目内的跳转才得到检查，VSS6.0允许用户检查项目之外的超连接和跳转。

创建打开VSS数据库的快捷键-用户可以使用VSS Explorer中该新功能创建一个打开某个特定VSS 数据库的桌面快捷键。

HTML格式的帮助-VSS的以往版本使用的是WinHelp格式。

配置MMT环境变量如下：

MIGRATIONS_HOME: D:\Software\mybatis-migrations-3.2.0

Path： %MIGRATIONS_HOME%\bin

打开命令行窗口执行"migrate --help"测试MMT如下：

进入项目目录执行'migrate init'初始化MMT环境目录。

初始化后，MMT创建drivers，environments和scripts三个目录。其中drivers目录用来存放数据库驱动所依赖的jar包，environments目录用户配置数据库信息，scripts目录则用来存放数据库脚本。将准备好的数据驱动包放入drivers目录，这里以mysql为例。打开environments目录下的development.properties文件配置开发环境数据源信息如下：

如需要配置其他环境如test、demo、staging、production等，只需要复制development.properties文件修改相应的数据库链接即可。至此MMT的配置工作已经完成，我们可以使用其强大的数据库脚本版本控制功能了。

---