本篇文章6656字，读完约17分钟

在所有的软件系统中，最重要的是信息管理系统。最难的部分是信息管理系统。

这里提到的信息管理系统远远不止是发票、管理信息系统、his、mrp、erp和crm。所有的数据和信息管理、处理和呈现都是我们所说的信息管理系统。

如何做好信息管理系统是所有软件公司和软件人员最头疼的问题。最大的困难在于如何满足客户不断变化和发展的需求。事实上，在项目开始时，客户无法给出完整准确的解释，软件公司的软件人员也不熟悉客户业务本身，那么如何开发软件来应对这种情况呢？

这篇文章是给技术人员的一堂课，也是我多年应用软件开发实践的积累、研究和提炼。这个班的学费可以值10000元，可以和这里的每个人分享。当然，国务院为此买单。如果你对这门课漠不关心或不理解，在那个国家总共1万元的学费将是免费的；如果这门课被听到，学生们将会得到50，000英镑；如果这门课不仅被听，而且被理解和消化，它将值10万元。如果这个类可以使用，它将值500，000或更多。

在这节课中，我不会用传统的方式谈论需求、功能和接口，但是我会告诉你如何用一种全新的方式做好数据和信息管理系统，这就是“组织”。

关于认证

让我们来谈谈发生在我们身边的一个例子。我国的深化改革已经从政治、国防、经济、科技等领域渗透到政府职能部门的管理简化之中。在过去，我们可能要随时申请一堆证书来证明你是你自己。现在这些事情已经逐渐改变，我们需要申请的证书越来越少。

让我们先看看这张照片

事实上，每个家庭的户籍信息都保存在公安户籍系统中；民政局记录了每个人的婚礼和葬礼信息；房屋委员会保存着谁卖了什么房间的信息；人事局还负责每个人的工作调动，调动的进出顺序；出入境管理局给我们发了护照，上面记录了每个人的出入境情况。

那我们为什么要做这么多的证明呢？就因为没有信息共享吗？将这些信息结合在一起难道不是信息共享吗？从不同的存储位置将这些数据放在一起很容易，但是如果它们放在一起呢？

回顾我们自己的信息管理系统，难道不是所有的信息和数据都在我们自己的数据库中吗？然而，我们仍然很难把软件做好。事实上，这不是数据在哪里的问题，也不是信息是否可以共享的问题。
信息系统的要素

要建立一个好的数据和信息管理系统(以下简称管理系统)，最重要的是要弄清楚应该用什么方法来构建这个系统，而这个方法必须是科学有效的。

事实上，信息系统的组成有五个要素:要素、组织、逻辑、模板和蓝图。剩下的三个具体问题是:如何构建这些元素，如何处理这些元素之间的关系，以及如何很好地利用这些元素。

元素

元素是管理系统要处理的对象，这显然是我们的数据和信息。具体来说，可以是数据库中的数据表(如前面提到的户籍信息数据表和婚姻登记表)，也可以是随时可以生成的一些数据(如出入境信息)。

至于元素，我们不必担心它们应该是什么。我们只需要澄清两点:这些元素的位置和保存位置(例如数据库中的表)，或者这些数据的来源(例如，通过接口、通过数据推送、通过实时同步/异步数据交换)。总之，只要管理系统需要涉及和管理的东西是元素，关键就在于理解这些数据是如何被触及的。

我们用一个公司人力资源管理的例子来说明这五个要素。

在企业人力资源管理中，我们首先必须有一个公司员工的花名册，这实际上是一个数据库表。我们将为它命名为“元素A-员工信息表”。这张桌子是我们的元素之一。在此表单中，有许多字段，如姓名、出生日期、性别、就业时间、就业部门、职位、工资和在职状态(在职或休假)。当然，填写表格的日期和时间是必不可少的。这些属性我们称之为元素。

这是我们的第一个要素。这个元素，我们可以想象这样一个场景:我们打印了厚厚的一叠员工信息表，当一个新员工来的时候，我们会拿一个并填写一个。

那么，a-雇员信息表是管理系统的一个组成部分。当然，这个元素可以存储在关系数据库(mysql)中。如何在数据库中建立一个表应该是每个人都熟悉的，所以我们不在这里讨论它。
组织

组织是指按照一定的规则将元素组织在一起。我们可以把一个组织理解为一个活页夹，它需要五个关键点:组织的名称、范围、条件、分类和逻辑。

我们可以在这里看到“组织”，即根据“年龄”将所有填写好的员工信息表放在这个活页夹中。
这个组织的作用是帮助我们快速掌握公司所有员工的信息表。因此，组织存在的目的是为了解决我们的特定需求。

为了便于管理，我们需要设计另一个组织:

名称:公司管理层

范围:员工信息表

条件:作业=经理

排序:按年龄

逻辑:没有

这个组织是为了让我们更容易掌握公司管理的基本信息。

通过类比，我们可以找到许多组织:

我们需要强调的是，元素放在组织中是一种“影射”关系。简而言之，张三的这种形式只是一种复制，而原件仍在原来的地方。这个原件可以无限制地复制。
公司中有许多员工信息表，例如:

这很容易理解。经过一段时间，我们已经收集了很多这样的信息。接下来的问题是:如果我们想了解员工张三的方方面面，我们应该怎么做？你怎么一眼就知道了？显然，我们做不到。我们只能这样做:

我们的管理系统通常会这样做。虽然我们的管理系统并不缺乏所有的功能，但它看起来很笨拙。
我们可以在单个要素上设置组织，如“所有员工信息”、“2015年工作总结”、“去年体检报告”、“去年考核”、“最近三个月人事调动”、“今年离职”，也可以在多个要素上设置组织，如[/h/。

本组织的五大要素是:

姓名:王武档案

范围:员工信息表、工作总结、部门考核、年度考核、体检报告、调令和辞职通知

条件:姓名=王武

排序:员工信息表是第一个，其他的是基于填写表格的日期

逻辑:没有

当然，我们也可以为张三和李四建立自己的档案。这很容易，因为只有条件不同，其他都一样。

我们可以看到，只要条件改成“名字=张三”，就一定是张三档案。一个组织很容易被反复“引用”。如果引用时条件发生了变化，它将成为另一个组织，但不管条件如何变化，这个组织的意义是相同的，但内容是不同的。这种组织被称为“同类组织”。

我们稍后将更多地讨论该组织。在这里，我们首先讨论一个关于组织的非常重要的概念:一旦一个组织形成(创建)，它的内容必须是确定的和有限的。换句话说，如果一些信息是未知和不确定的，我们就不能创建一个组织并把它放进去。我们稍后会解释原因。例如，组织“王武档案”必须是王武自己的档案；“张三档案”只能有张三的资料，档案中有多少内容必须是确定的，可以统计的，即使有更多，也不会是无限的。

如果我们将组织对应到关系数据库的物理表，那么组织实际上是一个带有条件和排序的多表视图。这里不讨论如何创建视图。

逻辑

组织一旦形成，我们就可以为组织创建逻辑。假设我们有组织王武档案。一天，一纸“调令”把王武从行政部经理调到上海分公司担任总经理，他的工资增加了1000元。

首先，这个顺序一旦出现，它自然会被放入组织王武档案(因为这个组织的范围包括这个顺序)。这时，问题来了。当调令出现时，王武的“部门”和“工资”发生了变化。假设还有一个组织涉及到王武，比如行政部。那么，当转移订单到来时会发生什么呢？当然，正确的答案是:一旦转移订单来了，

①员工信息表需要重新填写，部门和工资需要修改，其余不变；

(2)行政部没有王武的位置，如果有这样的机构，她必须去上海分公司。

这里需要注意的是，员工信息表不是“修改”的，而是“重新填写”的。原来的员工信息表单已经成为历史，历史不能被篡改，只能被记住。

我们必须注意这样一个事实，即逻辑必须是组织中的逻辑。即使发出一百张三的指示，也不会对王五有任何影响，因为这不是王五档案中所发生的事。现在不难理解，如果我们有一个“薪资调整通知”，那么逻辑就是重新创建员工信息，薪资=薪资调整通知和新的薪资。一个组织可以有多种逻辑共存。

逻辑有什么特点？让我们总结一下:

(1)逻辑必须是一个组织的逻辑，并且它是以组织为基础的，而没有组织的逻辑是不存在的；

②在一个组织中，可以同时存在多个逻辑，并且它们都具有相同的优先级；

③逻辑条件是元素，但结果可以是元素，但也可以是其他东西；

然后，一个新的问题来了。现在有两个“员工基本信息”。我们应该如何识别和区分它们？事实上，这不是问题。我们可以给这个元素添加一个属性。该属性用于指示“当前”或“历史”。

让我们用刚才王武的例子。“调令”出台后，出现了新旧两个版本的《工作人员基本信息》，但两个版本都是同时在王武档案馆组织的。这是一个合理的做法，因为文件本身就反映了王武在公司的每一个变化和成长成熟过程。从技术角度来说，这是一种非常合理的方法，可以“准确、完整地描述特定信息对象的生命周期。”

话虽如此，我们需要谈谈“组织”的两个概念，即开放和封闭:这是两种行动和两种状态。

开放是组织的开端
从刚才的例子中，我们可以看出员工基本信息表对于建立王武档案是不可或缺的。如果基本信息表丢失，该文件显然是一个严重不完整的文件。让我们换一种说法。假设我们为每个员工的档案设计了一个组织，那么王武档案是什么时候产生的呢？当我们填好第一张“员工基本信息表”后，当我们可以申报王武的档案时，这个组织就正式成立了。这可以理解为:我们拿出一个新的文件夹，在文件夹的封面上写着“王武档案”，并把王武的第一个基本资料放在里面。

close是组织的结束

假设我们收到王武的辞职通知。此时，除了辞职通知外，王武档案中实际上还有一个新版的员工基本信息表，该表的在职状态改为“辞职”。从那以后，王武的档案里就没有新的东西了。我们可以关闭并封存王武的档案。也许这份文件需要转到王武的下一个工作单位？这时，我们可以关闭王武档案馆了。档案关闭后，如果人事部门发出任何调薪通知或命令，那将是一个笑话。

综上所述，王武档案馆是开放的；从填写王武员工基本信息表时开始；而关自王武的辞职通知出现后。这也是组织逻辑的一个内容，称为文件打开/文件关闭逻辑。

我们查看前面提到的一个组织的“所有员工档案”。来到王武的传送命令后，这个组织增加了一个王武的基本信息表；王武的辞职通知来了，这个组织增加了一个王武的基本信息表。请注意，这三个表中，两个是“历史”，只有一个是“当前”。在“当前”版本的基本信息表中，王武的状态已经是“离开”。

为了避免人事部门的失误，提高已经离开公司的王武的工资其实很简单。我们设计了一个组织“在职员工”供他们使用，并且不让他们使用“所有员工信息”，这样就不会出错:

名:在职员工

范围:员工信息表

条件:在用状态=在用，版本=当前

排序:根据灌装日期

逻辑:没有

到目前为止，我们有必要强调和整理逻辑的概念。逻辑是元素之间的关联和影响，而不是组织之间的。例如，当王武的调拨订单出现时，需要重新填写(而不是更新)王武的基本信息。这里的转移顺序和基本信息是元素，可能是关系数据库中的物理表或其他东西。没有王武档案，调拨订单只能是调拨订单，信息表就是信息表。

在刚才的例子中，让我们知道“版本”的概念。版本实际上是一个属性，表示它是历史还是现在。当然，我们也可以用其他方式来处理现在和历史问题，例如，使用修订，最大的数字是现在。

我们可能不得不再次面对新的问题。人力资源部发布了新形式的员工基本信息表。这可能是信息管理系统最害怕遇到的一个问题，但是他们必须遇到。试试看。没有组织解决这个问题不容易。

一旦“员工基本信息表”有了新的格式，我该怎么办？事实上，这很简单。让我们重新打印一叠新表格，把旧表格放好，下次填写新表格。该表仍称为“员工基本信息表”。如果填写好了，我应该放在哪个组织中，或者应该放在哪个组织中？我之前应该做什么？我现在该怎么办？

有许多方法可以在软件中实现它。如果是关系数据库，我们将设计一个新的表。只需要调整组织设计，修改组织的范围，并将范围扩展到新的表中，其他一切都不会改变。应该注意的是，一旦用新版本的替换启用了元素，就不会为原始元素生成新的信息实例，并且之前生成的信息实例的数量是有限的。

在这里，我们应该理解信息系统要处理的信息对象。“过去”是一个要素，“现在”应该是一个组织。让我们先讨论另一个组织的要素:

模板

模板是元素或组织的表示形式。此处的演示文稿可以阅读(参见)或书写(填写)。元素模板可以有读写模板，而组织只能有读写模板。

这似乎没什么问题。简单地说，如果我们想根据一个元素创建信息，我们需要设计一种风格。我们可以把它理解为我们打印的一叠表格的外观。

模板和元素之间的关系是什么？这个图只描述了一个简单的关系，一个数据表对应一个模板，这当然是真的。事实上，模板和元素之间的关系是灵活的，没有必要一一对应。一个模板可以对应多个元素；一个元素也可以对应多个模板。这个的规划和设计完全取决于实际情况。

让我们以员工的基本信息表为例。当然，我们可以逐项填写。然而，如果我们有一个身份证阅读器，我们可以做两个模板。

因此，模板可以是一个用户界面、一个表单或其他东西，也许是一个带有数据接口和处理接口的程序。这是一个元素对应多个模板的情况。

多个元素对应一个经常使用的模板。当我们需要手动输入信息时，我们可以设计一个模板并输入一次。但是，提交保存时，它会同时保存到多个元素的信息实例中。

总的来说， 元素和模板之间的对应关系很简单。无论是一对一、一对多还是多对一，我们都很熟悉。更复杂的是模板和组织之间的关系。为了澄清这个问题，我们必须首先理解一个非常重要的概念，即组织之间的关系。

我们一直强调信息管理系统管理的信息对象是组织，而不是元素。当然，组织可以是基于单一元素的组织。这样做的目的是为了方便我们以灵活统一的方式合理地描述和显示信息对象。

在解释与组织的关系之前，我们应该澄清和加深对几个概念的理解:要素和要素实例、组织和组织实例。

元素实例来自元素的设计，它是一个具体的元素。我们可以把它理解为关系数据库表中的一个特定记录(如王武的基本信息)；一个组织实例，也来源于一个组织的设计，是一个具体的组织(如王武档案)。组织包含元素的实例，这些实例可能来自一个或多个元素设计。

我们还应该记住一个最重要的想法，那就是改变我们以前在信息管理系统方面的做法。我们应该关心的信息对象不是一个元素实例，而是一个组织实例。即使它是一个元素，我们也把它放在一个组织中。

我们仍然用刚才的例子来说明组织之间的关系。首先，我们建立了一个名为“在职员工”的组织，它来源于“员工基本信息”，其内容都是当前在职员工。

我们可以理解，在这个组织中，我们只选择了在职员工的姓名和部门，而没有包括许多其他细节。

现在，我们可以感觉到，组织的设计不是遵循葫芦画，而是提炼元素。这就是我们所说的“抽象”。哦，我们突然意识到原始组织中包含的信息实际上是元素的总结。此摘要称为“组织项目”。

我们将建立另一个名为档案馆的组织。其中的例子有张三档案、李四档案和王武档案。我们将在此级别扩展内容。

这个组织以前出现过多次，应该很熟悉。这是一个包含许多元素的组织。我们应该注意到这个组织中包含的具体内容实际上是这些元素的总结。每个抽象实际上是对应于一个元素的一个实例。

让我们做一个图表来总结我们上面所说的。为了方便我们后面的叙述，我们不再区分元素设计和元素实例，也不再区分组织设计和组织实例。

从这个图表中，我们可以看到组织和元素之间的关系。第一种关系是一个组织的一个组织项目可以对应另一个组织；第二种关系是组织的组织项也可以对应于元素(实例)。

组织项目实际上并不是一个新概念，但我们在这里引入它是因为到目前为止，我们已经理解了组织的含义，而在这里我们只是将组织的内容具体化。事实上，这是我们用来展示我们组织的模板。当然，我们可以使用其他方法。例如，我们可以一一展示，但这是不合理和不必要的。

通常，我们使用组织项目来显示组织的内容；组织项是元素的汇总。

我们从未解释过如何使用关系数据库从头到尾实现组织，因为这是完全不必要的。只要你理解它，无论你用什么方法，实现它都不是问题。

事实上，任何信息管理系统都不复杂，但是在现实中，我们的软件设计人员感觉复杂，用户感觉更复杂，因为我们没有采用合适的方法。结果，它像滚雪球一样越滚越大，越来越不知道该解决什么问题。

在下一期中，我们将以一家专业商务旅行服务公司的信息管理系统为例，详细说明我们应该如何以组织的方式实施一个非常复杂的业务系统。请继续关注“知识产权联盟”~