|
发信人: hunter__fox(雁回西楼) 整理人: hunter__fox(2003-01-18 15:36:03), 站内信件 |
| VFP是用于开发数据应用系统的。开发数据应用系统就离不开数据。
如何管理数据，自然而然就成为了开发数据应用系统的重点。要想管理好好数据，我们 就必需先对数据进行分析，让数据的组组合理化。如果把数据比作机器零件，那么，好的数 据结构让这一堆零件组装成一部机器，坏的数据结构让它们仍然是一堆零件（当然，如果你 是零件供应商的话这个比喻就不适你你）。 于是，我们现在就接触到一个问题：如何组织我们需要处理的数据？ 一般而言，组织数据的方式主要有两类。一类是按数据之间的关系来进行分类、联合。 另一种方式则是按数据的表达性质来进行分类、组织。 我们先来说说后者。这一种方式的代表形式就是EXCEL 电子表格了。请想象一下，如果 要做一个EXCEL 表，用来处理设备维护记录。那么，可能会是这样： 
这样的数据信息，以按照表达和理解的方便性来进行组织的。基本上，在EXCEL 中，建 立这种类型的数据型式是很方便的。它的特点很明显：使用方便。 组织这样的数据很容易，将所需要的数据罗列出来，同样的含义的数据在一起，便于参 照和修改，也便于进行对比。基于Excel 的特点，我们能够很方便的在里面添加一个列或者 一行，用于存放新的东西。 出于它结构上的灵活和表达上的直观，很多人能够很快掌握这种数据结构的架设方法。 于是，一夜之间，办公自动化就成了用Excel 做表格的代名词。 另一种对数据的组织方式源于结构化理念。这种方式的重点地于结构而不是数据（从上 图可以看出，Excel 的处理重点是数据）。这种观点认为，所有相关联的数据，一旦能够从 关系上将数据进行区分，那么，就能够从数据的海洋中通过这个关系链来找到我们想要找到 的任何一滴水。这种数据与数据之间的关系，就构成了数据系统的结构。 随着这种概念的完善，我们就知道了"关系数据库"这样的个名词。 如同Internet上的计算机能够通过网线实现远距离互想通讯一样，在这种数据库里，我 们能够通过数据之间的关系从一组数据达到数据库中的任何另一组数据。在这一过程中，我 们将我们得到的用于达到最终我们想要的数据前得经历的数据，统称为"数据链"。这个数据 链中的每一组数据，就像网络上的一台计算机，它们相互之间的关系，就象是网线。 现在，我们列出一个数据链，让我们看看，我们怎么通过一份去年的设备维修费用（起 点数据）到达今年最新进厂员工的学历信息（目标数据）的。 1.去年的设备维修费---------------起点 2.全年费用合计-------------------回溯（通过费用关系） 3.今年费用累计-------------------跳转（通过时间关系），这里到达了最顶层 4.本月工资预算-------------------子项数据 5.工资预算详表-------------------进一步子项数据 6.最后的一名员工-----------------时间关系 7.此人详细信息-------------------员工编号关联 8.学历---------------------------目标数据 经历了这一过程，我们看到，我们确实能够从一个数据到达看似无关的另一组数据。当 然，这并不是我们的目的。这只能表明我们的数据库中的数据确实是互相有联系的。 当然，一般情况下我们是不会这样的找数据。我们会设定一些特别的起点。这些起点与 其它的数据之间的数据链都很短。这样，我们就能够很快的从一个合适的数据起点到我我们 想要的目标数据。 数据系统中，我们的菜单项，或者说功能按钮，就是这样的数据起点的入口了。 那么，是不是我们将所有的目标数据都做成入口，我们就能用最快的速度到达任何数据 了吗？ 不是。 数据之间的关系不但让我们能够找到另一份数据，它也让我们从众多的数据里过滤出我 们想要的数据。 正如"我的汽车"和"汽车"所包含的内容明显不可能相同一样，从"我"开始，找到的信息 必然是很少的。 所以，设计入口时，我们应当让可能的选项少一些。就像是一棵树，从树的根部开始， 我们能到达这棵树的任何一个地方，这其中每经过一次分支，我们的数据量就会减少一些， 只至最后，我们只能看到我们想要的数据。 在关系数据库中，数据之间的关系，并不是仅仅表现在设计数据库时的那些线条上，它 也可能存在于数据库的应用代码里。 但我不建议大家把所有的关系都用代码来做。这样到少有两点不利： 第一，我们无法直观的了解到数据与数据之间的关系了。当我们不能这样时，我们设计 时功能时，就不得不凭借自己的记忆来确定通过什么样的数据链来达到目标数据。这样的做 法显没有通过有一张图上找一条线来得方便。 第二，我们需要应用数据时，不得不重复的编写代码来实现这些关联。这就让代码中有 很多重复的内容了，而它们，原来是可以没有的。 像SQL这样的数据库，正是严格按这种概念来搭建的。在SQL中，你可以通过一组条件来 定位记录，它们可能是一条，也可能是多条。如果要从从条记录中再定位一条记录，我们需 要找到这条记录的特征。 在设计数据库时（假设我们已经弄清楚我们需要管理哪些数据），我们应当按照数据之 间的关系来搭建数据库的结构，而不是数据的相似性。 我们可以将大量的数据先分为几个组，整理出它们之间的关系。然后，对每一部分再进 行细分，并确定它们之间的关系，然后，我不重复这一步骤，直到数据不能再被分解。 到了这一步，我们的数据也许还存在一些数据集合，它们包含的数据信息很大。我们需 要再用另一种方式来分解它们。这一部分的做法，请看本文的参考文章1。 关于如何理解数据的关系，如何在数据应用中利用这种关系，如何在开发前去发掘这种 数据关系，在以后的时间里，我们将陆续进行一些尝试性的讲解。 也请在这些方面有一定经历的朋友整理出自己的见解，大家共同进步。 参考文章1：hunter__fox【雁回西楼】 ※ 来源: 网易虚拟社区 广州站． ※ 个人天地 流水情怀[ccbyy] 灌水精英 NO:003 ※ 编程开发 VFP[VFP] |
|
[关闭][返回] |