请教数据表的规划

todaynew

简 发表于 2011-5-26 10:32
我知道，为了避免数据的重复，实施参照完整性，在数据表里需要采用一对多，一对一等关系，我想了解两个问题 ...

1、无关系不成方圆。但是否在关系视图中建立关系不是最重要的，也就是说除了在关系视图中建立关系外，还可以在查询视图中建立关系，还可以在主子窗体中建立关系，还可以利用筛选建立关系等等。这个都是建立关系的手段和方法，但是不能想象完全没有关系的若干数据表能有什么用处。通常在关系视图中建立表或查询之间的关系是最简单、最直观的，一般来说还是应该利用关系视图来建立表间的关系，定义表间关系的属性。

2、单独的工序与工人建立一个数据表是没什么实际意义的。工序与加工的产品有关系，工人也与加工的产品有关系，也就是说只有存在一个加工任务，工人与工序才能联系起来，所以工人与工序的联系是在有关描述加工的数据表中存在的。
   这种存在可以根据情况出现两种表达方式，最通常的一种表达方式是基于工人所从事的工序是多种，此类情形中，工人和工序的特征字段（也就是ID值或者姓名）需要进入加工表中。另外一种情形是工人的工序岗位完全确定不会变化，这种情形下，工序应该存在与工人表中，也就是说每个工人都只对应一个工序。那么在加工表中只需要工人的特征字段就可以了。

3、以下的示例是基于第一种情形做的表结构设计：




4、在数据库表结构设计时，不应局部的看问题，更不应该割裂出一个局部来讨论全局性的问题。这样的话，永远说不清道不明。工序和工人是两个局部问题，如果没有一个加工任务的话，工序只存在于工艺设计员的设计方案中，工人也只是坐在车间喝茶聊天。这种情况下，工人和工序并不发生什么关系。只有生产任务下达了，工艺的加工图纸到了工人手中，材料齐备、设备启动，工人才会来到钳台或机器旁按照图纸进行他们的工作，工序和工人才发生了关系。这样去观察问题，就有了全局的和实际的视角，数据表的设计也就不是什么难事了。

todaynew

简 发表于 2011-5-27 21:30
我想再请教一下，以todaynew老汉的表结构数据库为例，我想统计加工表中工序id为刨的个数，其程序代码该怎么 ...

呵呵，鬼打架的，你也不能一口气搞这么多问题呀。

1、统计问题应该如下解法：
Dcount("*","加工表","工序id=" & Dlookup("工序id","工序表","工序='刨'"))

2、组合框或列表框的绑定值和其显示的字段可以不一样，通常我们都是将记录的ID作为绑定值，但又不想显示出id（因为id枯燥无味可理解性很差）。于是乎我们就将id的列宽度设置为0，而将要显示的字段列宽度设置为一定的长度。这个设置在表、查询的查阅中设置，如果是窗体的组合框或列表框控件，则在数据属性和格式属性中设置。
这个问题要这样去理解，你的组合框或列表款给你显示的值并不一定是保存的值，而绑定的值（也许你看不见它）才是你保存的值。

3、一个表的ID是标识一条记录唯一性的字段，也是若干张数据表之间建立关系的字段。所以通常外键要使用主表中的ID，这个观点与后期的数据查询和其他方面的使用方便与否没什么大的关系，或者说这一方法已经为数据的后期使用奠定了基础。比如说你希望查询出某个工序的数据，而加工表中又只有ID没有工艺名称，那么你可以以加工表为基础将工艺表和工人表拖入到查询设计视图中，将工艺名称和工人姓名字段拖入到查询中以此建立一个名曰“加工查询”的查询，并以这个查询作为子窗体的数据源就可以了。

todaynew

简 发表于 2011-5-28 23:49
还有：

我看前面有两个朋友认为，只需要tblgx表(工序表)和tblgxgr表(工序下的工人)两个表即可，为什么他 ...

你还没有理解数据库设计的基本原理，呵呵。对于你的这几个问题，需要用倒叙来加以说明了。先从最后的问题来说吧。

　　1、所谓工人表其实不应该是工人表，而应该是员工表。一个管理系统通常需要涉及到人，为什么呢？因为人是生产力的第一要素，没有人什么事情都办不成。就一个企业来看，人员所从事的工作是多方面的，有从事管理的管理干部、销售人员、财务人员、劳资人员等等，有从事技术工作的设计人员、检验人员等，还有从事一线生产人员的工人等等。人员有其共性，比如他们都有姓名、性别、年龄、岗位、隶属的部门等等，员工表所起的作用就是独立的保存这些有共性的信息。
　　也就是说，我们通常应该把具有相同属性的一类对象用一张数据表来保存数据，企业管理的要素无法是人财物，以及人财物相互作用的各种过程各种结果。这些东西经过合理的分类，都可以形成相对独立而又有联系的对象，数据库的设计就是将这些对象数据化的分配到各个数据表中，并通过关系这样一些手段，来描述他们之间的联系。
　　数据表大体上可以分为两类，一类是诸如员工表、部门表、产品表、材料表、工艺表、检验项目表等等，他们的特点是与时间的联系不紧密，也就是相对于时间的变化很小，这些数据表我们称之为基础资料。还有一类数据表是与时间紧密联系的（可能时间是隐形的），比如订单表、销售表、入库表、加工表等等，这些数据表我们可称之为动态数据。
　　一般来讲，动态数据的数据表中都会存在基础资料数据表的ID，比如课程表中存在班级ID、学科ID和教师ID，加工表中存在工序ID、员工ID、材料ID。保存基础资料表中的ID，而不是保存基础资料表中的部分字段或全部字段，就是为了减少数据冗余。由于数据表的ID唯一性的定义了一条记录，所以保存数据表的ID也就是保存了该条记录。
　　数据表的ID是强调数据表中记录的唯一性，但并不是说数据表的其他字段不能替代这个功能，比如说工艺表的工艺名称，员工表的姓名（只要企业内没有重名的职工），所以在某些情形下，数据表是可以不必单建ID字段的。但是通常我们都愿意单独建立ID字段，这又是为什么呢？这是因为对每个数据表单独建立ID可以统一ID的数据类型和编码规则，这样就对后期的编程按照统一的规则进行数据处理提供了方便。
　　简言之，一个管理系统中一定需要建立一个人员表（可以叫做学生表、教师表、员工表、用户表等等），也一定需要设一个人员ID字段。

　　2、简化操作特别是简化录入操作的问题，与数据表结构设计有关系但不是影响数据表设计的根本原因，也就是说在数据表设计阶段可以暂不考虑录入问题的简化，只需考虑一般的设计规范。筛选人员的方法有多种手段，比如可以用姓氏筛选，还可以用拼音助记码筛选，还可以用部门组合框加人员组合框联级筛选等等，工序的筛选和统计也是一样。这些操作都与数据表设计没什么太大关系，只是后期的处理技巧而已。

　　3、DCount("*", "加工表", "[工序]= '刨'")的简单与Dcount("*","加工表","工序id=" & Dlookup("工序id","工序表","工序='刨'"))的麻烦，实际上是一个战略和战术的问题。红军长征时四渡赤水，连续走了几个大的迂回，当时部分指战员包括林彪、彭德怀等军团司令员都不理解，认为不应该走弓背而应该走弓弦。但最后的实践证明，毛泽东在运动中调动敌人消灭敌人摆脱敌人的战略是正确的。也就是局部的麻烦，不代表全局的麻烦，牺牲局部才可能带来全局的胜利。这就是我前面反复强调的全局性的观念、全局性的视角、全局性的思维。加工表中我们不用一个文本型的汉字字段作为ID，而以一个自动编号的数字型的字段作为ID，在统计时可能有些麻烦，但在做筛选、运算、排序等等方面都极大的简化了。花费了一个语句的麻烦，带来了几个语句，数十种处理的简化，你说是麻烦还是简单呢？
　　在数据库设计时，要有进得去出得来的本领。所谓进得去，是指能关注到细微末梢的各种情况各类情形；所谓出得来，是指能忽略细节，站在全局的高度看问题。只有这样才能不畏浮云遮望眼，只缘身在最高层，否则就是一叶障目不见泰山了。

　　4、最后再强调两点。第一点是数据库的设计一定要以表结构设计为基础，这个问题通常被初学者所忽视，我经常看见版友上传的问题实例中，表结构不合理的占绝大多数。不合理的表结构会带来一系列的麻烦，而合理的表结构可使程序极大的简化。第二点是初学者一定要使用关系视图来建立表间关系，Access中的这个工具非常好，它图示化的直观描述了数据关系，对于判断表结构是否合理有重要作用。我个人的体会是，如果关系视图中的连线交错的特别复杂，一定是表结构设计出现了问题，在这种情况下我会对表结构进行调整，使表间关系简洁明了。

todaynew

简 发表于 2011-5-29 16:11
谢谢老汉，让你费心了，能不能将就我的例子进行修改，让我再好好学习与消化呢。

14楼的例子应该能说明问题了。

todaynew

简 发表于 2011-5-30 09:22
老汉，我还有些疑惑没有解决。

以你的表结构为例，当我在工序id里选择刨时，我希望工人id组合框里显示 ...

呵呵，怎么还不明白。筛选和表结构没什么关系。
1、前面的示例不是已经可以完成筛选功能：


2、这个示例就是基于工人可能从事多工种设计的，表结构不需做什么修改，你可以在这个示例中测试一个工人多工种的情况。

3、对于工序ID和工人ID不能同时输入的处理方法有多种，常用的有这样两种方法。第一种方法是，在关系视图中编辑关系属性，将“实施参照完整性”的勾选去掉。第二种方法是，在工人表中的工人字段加一个【待确定】的记录（如果工艺开始录入时也存在不确定的情况可以比照处理），录入数据不能确定时就选这条记录。当能确定工人后，再对该条记录进行更改。我一般喜欢采用第二种方法，《下里巴人》一文中有这样的处理，可以参见一下。

4、你目前所提到的所有问题，都不对表结构设计产生实质性的影响。所以还是那句话，先从数据分类的合理性出发建立表结构，不必操心后期的处理，后期处理可依据数据表结构有丰富多彩的手段。

todaynew

简 发表于 2011-5-30 13:06
我想你可能没完全明白我的意思。
我这个筛选不用于模糊查询，我希望是在输入数据时，比如在你的子窗体里 ...

那很简单嘛。先做一些数据到加工表中，工人ID与工序ID就建立了关系，然后用加工表为基础来联机筛选就可以了。

todaynew

简 发表于 2011-5-30 13:06
我想你可能没完全明白我的意思。
我这个筛选不用于模糊查询，我希望是在输入数据时，比如在你的子窗体里 ...

1、联级筛选可利用加工表的数据进行，实例中已处理。

2、关于复制粘贴的问题，可以采用选定记录后追加部分字段的数据的方法来解决。如果不想另外设计按钮，可以采用自定义窗体快捷菜单的方式来解决。具体方法是写两个函数，一个函数叫做复制其功能是记住选定记录的ID值（记住的方法可以采用一个全局变量，点击快捷菜单的复制按钮时，将ID值赋值给这个变量），另一个函数叫做粘贴（粘贴函数实际就是一个追加查询代码），然后将这个两个函数给快捷菜单的复制和粘贴按钮作为其操作功能。实例中做了一个类似的例子。

3、关于工人ID在录入时可能不完全确定的情况下，用一个【待确定】进行替代的例子在实例中进行了处理。