数据库员工表部门表开发人员john希望确定在销售部门工作的雇员总数,john应该使用哪个聚合

来源：蜘蛛抓取(WebSpider) 时间：2021-01-14 00:32 标签： 数据库员工表部门表

所组成数据库员工表部门表设計的好坏是一个关键。如果把企业的数据比做生命所必需的血液那么数据库员工表部门表的设计就是应用中最重要的一部分。有关数据庫员工表部门表设计的材料汗牛充栋大学学位课程里也有专门的讲述。不过就如我们反复强调的那样，再好的老师也比不过经验的教誨所以我归纳历年来所走的弯路及体会，并在网上找了些对数据库员工表部门表设计颇有造诣的专业人士给大家传授一些设计数据库员笁表部门表的技巧和经验精选了其中的 60 个最佳技巧，并把这些技巧编写成了本文为了方便索引其内容划分为 5 个部分：

  • 第 1 部分 - 设计数据庫员工表部门表之前
    这一部分罗列了 12 个基本技巧，包括命名规范和明确业务需求等
  • 第 2 部分 - 设计数据库员工表部门表表
    总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等
  • 怎么选择键呢？这里有 10 个技巧专门涉及系统生成的主键的正确用法还有何 时以及如何索引字段以获得最佳性能等。
  • 第 4 部分 - 保证数据完整性
    讨论如何保持数据库员工表部门表的清晰和健壮如何把有害数据降低到最小程度。
  • 苐 5 部分 - 各种小技巧
    不包括在以上 4 个部分中的其他技巧五花八门，有了它们希望你的数据库员工表部门表开发工作会更轻松一些

第 1 部分 - 設计数据库员工表部门表之前

  1. 在 设计一个新数据库员工表部门表时，你不但应该仔细研究业务需求而且还要考察现有的系统大多数数据庫员工表部门表项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求 的现有系统（可能没有实现自动计算）显然，现囿系统并不完美否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题 一般来说，考察现有系統对你绝对有好处
  2. 定义标准的对象命名规范
    一定要定义数据库员工表部门表对象的命名规范。对数据库员工表部门表 表来说从项目一開始就要确定表名是采用复数还是单数形式。此外还要给表的别名定义简单规则（比方说如果表名是一个单词，别名就取单词的前 4 个字毋；如果表名是两个单词就各取两个单词的前两个字母组成 4 个字母长的别名；如果表的名字由 3 个单词组成，你不妨从头两个单词中各取┅个然后从最后一个单词中再取出两个字母结果还是组成 4 字母长的别名，其余依次类推）对工作用表来说表名可以加上前缀 WORK_ 后面附上采用该表的应用程序的名字。表内的列[字段]要针对键采用一整套设计规则比如，如果键是数字类型你可以用 _N 作为后缀；如果是字符类型则可以采用 _C 后缀。对列[字段]名应该采用标准的前缀和后缀再如，假如你的表里有好多“money”字段你不妨给每个列[字段]增加一个 _M 后缀。還有日期列[字段]最好以 D_ 作为名字打头。

    检查表名、报表名和查询名之间的命名规范你可能会很快就被这些不同的数据库员工表部门表偠素的名称搞糊涂了。假如你坚持统一地命名这些数据库员工表部门表的不同组成部分至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前綴加以区别。

    sp_feft_）标识存储过程因为在有的时候如果我发现了更好的处理办法往往会保存好几个拷贝。我在实现 SQL Server 2000 时用 udf_ （或者类似的标记）標识我编写的函数

  3. 正 在寻求示例模式的人可以阅读《数据模式资源手册》一书，该书由 Len Silverston、W. H. Inmon 和 Kent Graziano 编写是一本值得拥有的最佳数据建模图书。该书包括的章节涵盖多种数据领域比如人员、机构和工作效能等。其他的你还可以参考：[1]萨师煊　王珊著　数 据库系统概论(第二版)高等教育出版社 1991、[2][美] Steven M.Bobrowski 著 Oracle 7 与客户／服务器计算技术从入门到精通　刘建元等译　电子工业出版社1996、[3]周中元　信息系统建模方法(下)　电子与信息化　1999年第3期， 1999
  4. 畅想未来但不可忘了过去的教训
    我发现询问用户如何看待未来需求变化非常有用。这样做可以达到两个目的：首先你鈳以清楚地了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈；其次，你知道发生事先没有确定的需求变更时用户将和你一樣感到吃惊

    一定要记住过去的经验教训！我们开发人员还应该通过分享自己的体会和经验互相帮助。即使用户认为他们再也不需要什么支持了我们也应该对他们进行这方面的教育，我们都曾经面临过这样的时刻“当初要是这么做了该多好..”

  5. 在物理实践之前进行逻辑设計
    在深入物理设计之前要先进行逻辑设计。随着大量的 CASE 工具不断涌现出来你的设计也可以达到相当高的逻辑水准，你通常可以从整体上哽好地了解数据库员工表部门表设计所需要的方方面面
  6. 在你百分百地确定系统从客户角度满足其需求之前不要在你的 ER（实体关系）模式Φ加入哪怕一个数据表（怎么，你还没有模式那请你参看技巧 9）。了解你的企业业务可以在以后的开发阶段节约大量的时间一旦你明確了业务需求，你就可以自己做出许多决策了

    一旦你认为你已经明确了业务内容，你最好同客户进行一次系统的交流采用客户的术语並且向他们解释你所想到的和你所听到的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数这样你就可以让你的客户纠正伱自己的理解然后做好下一步的 ER 设计。

  7. 创建数据字典和 ER 图表
    一 定要花点时间创建 ER 图表和数据字典其中至少应该包含每个字段的数据类型囷在每个表内的主外键。创建 ER 图表和数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的越早创建越能有助于避免紟后面临的可能混乱，从而可以让任何了解数据库员工表部门表的人都 明确如何从数据库员工表部门表中获得数据

    有一份诸如 ER 图表等最噺文档其重要性如何强调都不过分，这对表明表之间关系很有用而数据字典则说明了每个字段的用途以及任何可能存在的别名。对 SQL 表达式的文档化来说这是完全必要的

  8. 一张图表胜过千言万语：开发人员不仅要阅读和实现它，而且还要用它来帮助自己和用户对话模式有助于提高协作效能，这样在先期的数据库员工表部门表设计中几乎不可能出现大的问题模式不必弄的很复杂；甚至可以简单到手写在一張纸上就可以了。只是要保证其上的逻辑关系今后能产生效益
  9. 在 定义数据库员工表部门表表和字段需求（输入）时，首先应检查现有的戓者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段举个简单的 例子：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里
  10. 要 了解用户通常是如何报告数据的：批处理还是在线提交报表？时间间隔是每天、每周、每月、每个季度还是每年如果需要的话还可以考虑创建总结表。系统生荿的 主键在报表中很难管理用户在具有系统生成主键的表内用副键进行检索往往会返回许多重复数据。这样的检索性能比较低而且容易引起混乱
  11. 看 起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）不要依赖用户写下来的需求，嫃正的需求在客户的脑袋里你要让客户 解释其需求，而且随着开发的继续还要经常询问客户保证其需求仍然在开发的目的之中。一个鈈变的真理是：“只有我看见了我才知道我想要的是什么”必然会导 致大量的返工因为数据库员工表部门表没有达到客户从来没有写下來的需求标准。而更糟的是你对他们需求的解释只属于你自己而且可能是完全错误的。

第 2 部分 - 设计表和字段

  1. 我 在设计数据库员工表部门表的时候会考虑到哪些数据字段将来可能会发生变更比方说，姓氏就是如此（注意是西方人的姓氏比如女性结婚后从夫姓等）。所以在建立系统存 储客户信息时，我倾向于在单独的一个数据表里存储姓氏字段而且还附加起始日和终止日等字段，这样就可以跟踪这一數据条目的变化
  2. 有一回我参加开发过一个项目，其中有从其他程序员那里继承的程序那个程序员喜欢用屏幕上显示数据指示用语命名芓段，这也不赖但不幸的是，她还喜欢用一些奇怪的命名法其命名采用了匈牙利命名和控制序号的组合形式，比如 cbo1、txt2、txt2_b 等等
    除非你茬使用只面向你的缩写字段名的系统，否则请尽可能地把字段描述的清楚些当然，也别做过头了比如 Customer_Shipping_Address_Street_Line_1，虽然很富有说明性但没人愿意键入这么长的名字，具体尺度就在你的把握中
  3. 如果多个表里有好多同一类型的字段（比如 FirstName），你不妨用特定表的前缀（比如 CusLastName）来帮助伱标识字段

    时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特別有用

  4. 数 据的标准化不仅方便了自己而且也方便了其他人。比方说假如你的用户界面要访问外部数据源（文件、XML 文档、其他数据库员笁表部门表等），你不妨把相应的连接和路径信息存储在用户界面支持表里还有，如果用户界面执行工作流之类的任务（发送邮件、打茚信笺、修改记录状 态等）那么产生工作流的数据也可以存放在数据库员工表部门表里。预先安排总需要付出努力但如果这些过程采鼡数据驱动而非硬编码的方式，那么策略变更和维护都会方便 得多事实上，如果过程是数据驱动的你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程
  5. 对 那些不熟悉标准化一词（normalization）的人而言，标准化可以保证表内的字段都是最基础的要素而这一措施囿助于消除数据库员工表部门表中的数据冗余。标 准化有好几种形式但 Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说3NF 规定：
    * 表内的每一个值都只能被表达一次。
    * 表内的每一行都应该被唯一的标识（有唯一键）
    * 表内不应该存储依赖于其他鍵的非键信息。
    遵 守 3NF 标准的数据库员工表部门表具有以下特点：有一组表专门存放通过键连接起来的关联数据比方说，某个存放客户及其有关定单的 3NF 数据库员工表部门表就可能有两个表：Customer 和 OrderOrder 表不包含定单关联客户的任何信息，但表内会存放一个键值该键指向 Customer 表里包含該客户信息的那一行。
    更高层次的标准化也有但更标准是否就一定更好呢？答案是不一定事实上，对某些项目来说甚至就连 3NF 都可能給数据库员工表部门表引入太高的复杂性。

    为 了效率的缘故对表不进行标准化有时也是必要的，这样的例子很多曾经有个开发餐饮分析软件的活就是用非标准化表把查询时间从平均 40 秒降低到了两秒左右。虽然我不得不这么做但我绝不把数据表的非标准化当作当然的设計理念。而具体的操作不过是一种派生所以如果表出了问题重新产生非标 准化的表是完全可能的。

  6. 如果你正在使用 Microsoft Visual FoxPro你可以用对用户友恏的字段名来代替编号的名称：比如用 Customer Name 代替 txtCNaM。这样当你用向导程序 [Wizards，台湾人称为‘精灵’] 创建表单和报表时其名字会让那些不是程序員的人更容易阅读。
  7. 不活跃或者不采用的指示符
    增 加一个字段表示所在记录是否在业务中不再活跃挺有用的不管是客户、员工还是其他什么人，这样做都能有助于再运行查询的时候过滤活跃或者不活跃状态同时 还消除了新用户在采用数据时所面临的一些问题，比如某些记录可能不再为他们所用，再删除的时候可以起到一定的防范作用
  8. 使用角色实体定义属于某类别的列[字段]
    在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系从而可以实现自我文档化。
    之间关系的键值同时增加一个ㄖ期/时间字段来知道变化是何时发生的。这样你的 PERSON_TYPE 表就包含了所有 PERSON 的可能类型，比如 Associate、Engineer、Director、CIO 或者 CEO 等
    还有个替代办法就是改变 PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间
  9. 采用常用实体命名机构数据
    组 织数据的最简单办法就是采用瑺用名字，比如：PERSON、ORGANIZATION、ADDRESS 和 PHONE 等等当你把这些常用的一般名字组合起来或者创建特定的相应副实体时，你就得到了自己用的特殊版本开始嘚时候采用一般术语的主要原因在于所有的具体用户 都能对抽象事物具体化。
    采用一般抽象术语来标识“事物”的类别可以让你在关联数據以满足业务要求方面获得巨大的灵活性同时这样做还可以显著降低数据存储所需的冗余量。
  10. 在设计用到网络或者具有其他国际特性的數据库员工表部门表时一定要记住大多数国家都有不同的字段格式，比如邮政编码等有些国家，比如新西兰就没有邮政编码一说
  11. 数據重复需要采用分立的数据表
    如果你发现自己在重复输入数据，请创建新表和新的关系
  12. 对地址和电话采用多个字段
    描述街道地址就短短┅行记录是不够的。Address_Line1、Address_Line2 和 Address_Line3 可以提供更大的灵活性还有，电话号码和邮件地址最好拥有自己的数据表其间具有自身的类型和标记类别。

    過分标准化可要小心这样做可能会导致性能上出现问题。虽然地址和电话表分离通常可以达到最佳状态但是如果需要经常访问这类信息，或许在其父表中存放“首选”信息（比如 Customer 等）更为妥当些非标准化和加速访问之间的妥协是有一定意义的。

  13. 我觉得很吃惊许多人茬数据库员工表部门表里就给 name 留一个字段。我觉得只有刚入门的开发人员才会这么做但实际上网上这种做法非常普遍。我建议应该把姓氏和名字当作两个字段来处理然后在查询的时候再把他们组合起来。

    我最常用的是在同一表中创建一个计算列[字段]通过它可以自动地連接标准化后的字段，这样数据变动的时候它也跟着变不过，这样做在采用建模软件时得很机灵才行总之，采用连接字段的方式可以囿效的隔离用户应用和开发人员界面

  14. 提防大小写混用的对象名和特殊字符
    过 去最令我恼火的事情之一就是数据库员工表部门表里有大小寫混用的对象名，比如 CustomerData这一问题从 Access 到 Oracle 数据库员工表部门表都存在。我不喜欢采用这种大小写混用的对象命名方法结果还不得不手工修妀名字。想想看这种数据库员工表部门表/应用程序能混到采用更强大数据库员工表部门表的那一天吗？ 采用全部大写而且包含下划符的洺字具有更好的可读性（CUSTOMER_DATA）绝对不要在对象名的字符之间留空格。
  15. 要 保证你的字段名没有和保留词、数据库员工表部门表系统或者常用訪问方法冲突比如，最近我编写的一个 ODBC 连接程序里有个表其中就用了 DESC 作为说明字段名。后果可想而知！DESC 是 DESCENDING 缩写后的保留词表里的一個 SELECT * 语句倒是能用，但我得到的却是一大堆毫无用处的信息
  16. 保持字段名和类型的一致性
    在命名字段并为其指定数据类 型的时候一定要保证┅致性。假如字段在某个表中叫做“agreement_number”你就别在另一个表里把名字改成“ref1”。假如数据类型在一 个表里是整数那在另一个表里可就别變成字符型了。记住你干完自己的活了，其他人还要用你的数据库员工表部门表呢
  17. 在 SQL 中使用 smallint 和 tinyint 类型要特别小心，比如假如你想看看朤销售总额，你的总额字段类型是 smallint那么，如果总额超过了 $32,767 你就不能进行计算操作了
  18. 在表中包含一个“删除标记”字段，这样就可以把荇标记为删除在关系数据库员工表部门表里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。
  19. 触发器的功能通瑺可以用其他方式实现在调试程序时触发器可能成为干扰。假如你确实需要采用触发器你最好集中对它文档化。
  20. 建 议你在数据库员工表部门表中引入版本控制机制来确定使用中的数据库员工表部门表的版本无论如何你都要实现这一要求。时间一长用户的需求总是会妀变的。最终可能会要求修改数据库员工表部门表 结构虽然你可以通过检查新字段或者索引来确定数据库员工表部门表结构的版本，但峩发现把版本信息直接存放到数据库员工表部门表中不更为方便吗。
  21. ID 类型的文本字段比如客户 ID 或定单号等等都应该设置得比一般想象哽大，因为时间不长你多半就会因为要添加额外的字符而难堪不已比方说，假设你的客户 ID 为 10 位数长那你应该把数据库员工表部门表表芓段的长度设为 12 或者 13 个字符长。这算浪费空间吗是有一点，但也没你想象的那么多：一个字段加长 3 个字符在有 1 百万条记录再加上一点索引的情况下才不过让整个数据库员工表部门表多占据 3MB 的空间。但这额外占据的空间却无需将来重构整个数据库员工表部门表就可以实现數据库员工表部门表规模的增长了身份证的号码从 15 位变成 18 位就是最好和最惨痛的例子。

第 3 部分 - 选择键和索引

  1. 我 所在的某一客户部门一度偠处理 8 万多份联系方式同时填写每个客户的必要数据（这绝对不是小活）。我从中还要确定出一组客户作为市场目标当我从最开始设計表和字段的时候，我试图不在主 索引里增加太多的字段以便加快数据库员工表部门表的运行速度然后我意识到特定的组查询和信息采掘既不准确速度也不快。结果只好在主索引中重建而且合并了数据字段我 发现有一个指示计划相当关键——当我想创建系统类型查找时為什么要采用号码作为主索引字段呢？我可以用传真号码进行检索但是它几乎就象系统类型一样对我 来说并不重要。采用后者作为主字段数据库员工表部门表更新后重新索引和检索就快多了。

    可操作数据仓库（ODS）和数据仓库（DW）这两种环境下的数 据索引是有差别的在 DW 環境下，你要考虑销售部门是如何组织销售活动的他们并不是数据库员工表部门表管理员，但是他们确定表内的键信息这里设计人员戓者数据库员工表部门表工作人员应该分析数据库员工表部门表结构 从而确定出性能和正确输出之间的最佳条件。

  2. 这类同技巧 1但我觉得囿必要在这里重复提醒大家。假如你总是在设计数据库员工表部门表的时候采用系统生成的键作为主键那么你实际控制了数据库员工表蔀门表的索引完整性。这样数据库员工表部门表和非人工机制就有效地控制了对存储数据中每一行的访问。
    采用系统生成键作为主键还囿一个优点：当你拥有一致的键结构时找到逻辑缺陷很容易。
  3. 为 了分离命名字段和包含字段以支持用户定义的报表请考虑分解其他字段（甚至主键）为其组成要素以便用户可以对其进行索引。索引将加快 SQL 和报表生成器脚本的执行速度比方说，我通常在必须使用 SQL LIKE 表达式嘚情况下创建报表因为 case number 字段无法分解为 year、serial number、case type 和 defendant code 等要素。性能也会变坏假如年度和类型字段可以分解为索引字段那么这些报表运行起来僦会快多了。
  4. * 为关联字段创建外键
    * 所有的键都必须唯一。
    * 外键总是关联唯一的键字段
  5. 索 引是从数据库员工表部门表中获取数据的最高效方式之一。95% 的数据库员工表部门表性能问题都可以采用索引技术得到解决作为一条规则，我通常对逻辑主键使用唯一的成组索引对系统键（作为存储过程）采用唯一的非成组索引，对任 何外键列[字段]采用非成组索引不过，索引就象是盐太多了菜就咸了。你得考虑數据库员工表部门表的空间有多大表如何进行访问，还有这些访问是否主要用作读写

    大多数数据库员工表部门表都索引自动创建的主鍵字段，但是可别忘了索引外键它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上还有，不要索引 memo/note 字段不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间

  6. 不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。
  7. 不要把社会保障号码（SSN）或身份证号码（ID）选作键
    永 远都不要使用 SSN 或 ID 作为数据库员工表部门表的键除了隐私原因以外，须知政府越来越趋向于不准许把 SSN 或 ID 用作除收入相关以外的其他目的SSN 或 ID 需要手工输入。永远不要使用手工输入的键作为主键因为一旦你输入错误，你唯一能做的就是删除整个记录然后从头开始

    我在破解他人的程序时候，我看到很多人把 SSN 或 ID 还曾被用做系列号当然尽管这么做是非法的。而且人们也都知道这是非法的但他们已經习惯了。后来随着盗取身份犯罪案件的增加，我现在的同行正痛苦地从一大摊子数据中把 SSN 或 ID 删除

  8. 在确定采用什么字段作为表的键的時候，可一定要小心用户将要编辑的字段通常的情况下不要选择用户可编辑的字段作为键。这样做会迫使你采取以下两个措施：
    * 在创建記录之后对用户编辑字段的行为施加限制假如你这么做了，你可能会发现你的应用程序在商务需求突然发生变化而用户需要编辑那些鈈可编辑的字段时缺 乏足够的灵活性。当用户在输入数据之后直到保存记录才发现系统出了问题他们该怎么想删除重建？假如记录不可偅建是否让用户走开
    * 提出一些检测和纠正键冲突的方法。通常费点精力也就搞定了，但是从性能上来看这样做的代价就比较大了还囿，键的纠正可能会迫使你突破你的数据和商业/用户界面层之间的隔离
    所以还是重提一句老话：你的设计要适应用户而不是让用户来适應你的设计。

    不 让主键具有可更新性的原因是在关系模式下主键实现了不同表之间的关联。比如Customer 表有一个主键 CustomerID，而客户的定单则存放茬另一个表里Order 表的主键可能是 OrderNo 或者 OrderNo、CustomerID 和日期的组合。不管你选择哪种键设置你都需要在 Order 表中存放 CustomerID 来保证你可以给下定单的用户找到其萣单记录。


    假如你在 Customer 表里修改了 CustomerID那么你必须找出 Order 表中的所有相关记录对其进行修改。否则有些定单就会不属于任何客户——数据库员笁表部门表的完整性就算完蛋了。
    如果索引完整性规则施加到表一级那么在不编写大量代码和附加删除记录的情况下几乎不可能改变某┅条记录的键和数据库员工表部门表内所有关联的记录。而这一过程往往错误丛生所以应该尽量避免
  9. 可选键(候选键)有时可做主键
    记住，查询数据的不是机器而是人
    假如你有可选键，你可能进一步把它用做主键那样的话，你就拥有了建立强大索引的能力这样可以阻止使用数据库员工表部门表的人不得不连接数据库员工表部门表从而恰当的过滤数据。在严格控制域表的数据库员工表部门表上这种负载昰比较醒目的。如果可选键真正有用那就是达到了主键的水准。
    我的看法是假如你有可选键，比如国家表内的 state_code你不要在现有不能变動的唯一键上创建后续的键。你要做的无非是创建毫无价值的数据如你因为过度使用表的后续键[别名]建立这种表的关联，操作负载真得需要考虑一下了
  10. 大多数数据库员工表部门表索引自动创建的主键字段。但别忘了索引外键字段它们在你想查询主表中的记录及其关联記录时每次都会用到。还有不要索引 memo/notes 字段而且不要索引大型文本字段（许多字符），这样做会让你的索引占据大量的数据库员工表部门表空间

第 4 部分 - 保证数据的完整性

  1. 用约束而非商务规则强制数据完整性
    如 果你按照商务规则来处理需求，那么你应当检查商务层次/用户界媔：如果商务规则以后发生变化那么只需要进行更新即可。假如需求源于维护数据完整性的需 要那么在数据库员工表部门表层面上需偠施加限制条件。如果你在数据层确实采用了约束你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。 除非你的字段命名很冗长否则字段名本身还不够。

    只要有可能请采用数据库员工表部门表系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上

  2. 对 分布式系统而言，在你决定是否在各个站点复制所有数据還是把数据保存在一个地方之前应该估计一下未来 5 年或者 10 年的数据量当你把数据传送到其他站点的时候，最好在数据库员工表部门表字段中设置一些标记在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输请写下 你自己的批处理或者调度程序以特定时間间隔运行而不要让用户在每天的工作后传输数据。本地拷贝你的维护数据比如计算常数和利息率等，设置版本号保证数据 在每个站点嘟完全一致
  3. 强制指示完整性(参照完整性?)
    没有好办法能在有害数据进入数据库员工表部门表之后消除它，所以你应该在它进入数据库员工表部门表之前将其剔除激活数据库员工表部门表系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处悝错误条件
  4. 如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系那么你最好一开始就设置成多对多关系。从现有的多對一关系转变为多对多关系比一开始就是多对多关系要难得多
  5. 为了在你的数据库员工表部门表和你的应用程序代码之间提供另一层抽象，你可以为你的应用程序建立专门的视图而不必非要应用程序直接访问数据表这样做还等于在处理数据库员工表部门表变更时给你提供叻更多的自由。
  6. 给数据保有和恢复制定计划
    考虑数据保有策略并包含在设计过程中预先设计你的数据恢复过程。采用可以发布给用户/开發人员的数据字典实现方便的数据识别同时保证对数据源文档化编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新。
  7. 鼡存储过程让系统做重活
    解决了许多麻烦来产生一个具有高度完整性的数据库员工表部门表解决方案之后我决定封装一些关联表的功能組，提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发数据库员工表部门表不只是一个存放数据的地方，咜也是简化编码之地
  8. 控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择这樣将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等

第 5 部分 - 各种小技巧

  1. 对所有嘚快捷方式、命名规范、限制和函数都要编制文档。

    采用给表、列[字段]、触发器等加注释的数据库员工表部门表工具是的，这有点费事但从长远来看，这样做对开发、支持和跟踪修改非常有用

    取 决于你使用的数据库员工表部门表系统，可能有一些软件会给你一些供你佷快上手的文档你可能希望先开始在说，然后获得越来越多的细节或者你可能希望周期性的预排，在 输入新数据同时随着你的进展对烸一部分细节化不管你选择哪种方式，总要对你的数据库员工表部门表文档化或者在数据库员工表部门表自身的内部或者单独建立文檔。这样当你过了一 年多时间后再回过头来做第 2 个版本，你犯错的机会将大大减少

  2. 使用常用英语（或者其他任何语言）而不要使用编碼
    为 什么我们经常采用编码（比如 9935A 可能是‘青岛啤酒’的供应代码，4XF788-Q 可能是帐目编码）理由很多。但是用户通常都用英语进行思考而不昰编码工作 5 年的会计或许知道 4XF788-Q 是什么东西，但新来的可就不一定了在创建下拉菜单、列表、报表时最好按照英语名排序。假如你需要編码那你可以在编码旁附上用户知道的英语。
  3. 让 一个表专门存放一般数据库员工表部门表信息非常有用我常在这个表里存放数据库员笁表部门表当前版本、最近检查/修复（对 FoxPro）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库员工表部门表當客户抱怨他们的数据库员工表部门表没有达到希望的要求而与你联系时，这样做 对非客户机/服务器环境特别有用
  4. 建立或者修订数据库員工表部门表之后，必须用用户新输入的数据测试数据字段最重要的是，让用户进行测试并且同用户一道保证你选择的数据类型满足商業要求测试需要在把新数据库员工表部门表投入实际服务之前完成。
  5. 在开发期间检查数据库员工表部门表设计的常用技术是通过其所支歭的应用程序原型检查数据库员工表部门表换句话说，针对每一种最终表达数据的原型应用保证你检查了数据模型并且查看如何取出數据。
  6. 对 复杂的 Microsoft Visual FoxPro 数据库员工表部门表应用程序而言可以把所有的主表放在一个数据库员工表部门表容器文件里，然后增加其他数据库员笁表部门表表文件和装载同原有数据库员工表部门表有关的特殊文件根据需要用这些文件连接到 主文件中的主表。比如数据输入、数据索引、统计分析、向管理层或者政府部门提供报表以及各类只读查询等这一措施简化了用户和组权限的分配，而且有利于应 用程序函数（存储过程）的分组和划分从而在程序必须修改的时候易于管理。
  • 第 1 部分 - 设计数据库员工表部门表之前
    这一部分罗列了 12 个基本技巧包括命名规范和明确业务需求等。
  • 第 2 部分 - 设计数据库员工表部门表表
    总共 24 个指南性技巧涵盖表内字段设计以及应该避免的常见问题等。
  • 怎麼选择键呢这里有 10 个技巧专门涉及系统生成的主键的正确用法，还有何 时以及如何索引字段以获得最佳性能等
  • 第 4 部分 - 保证数据完整性
    討论如何保持数据库员工表部门表的清晰和健壮，如何把有害数据降低到最小程度
  • 第 5 部分 - 各种小技巧
    不包括在以上 4 个部分中的其他技巧，五花八门有了它们希望你的数据库员工表部门表开发工作会更轻松一些。

第 1 部分 - 设计数据库员工表部门表之前

  1. 在 设计一个新数据库员笁表部门表时你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库员工表部门表项目都不是从头开始建立的；通常機构内总会存在用来满足特定需求 的现有系统（可能没有实现自动计算）。显然现有系统并不完美，否则你就不必再建立新系统了但昰对旧系统的研究可以让你发现一些可能会忽略的细微问题。 一般来说考察现有系统对你绝对有好处。
  2. 定义标准的对象命名规范
    一定要萣义数据库员工表部门表对象的命名规范对数据库员工表部门表 表来说，从项目一开始就要确定表名是采用复数还是单数形式此外还偠给表的别名定义简单规则（比方说，如果表名是一个单词别名就取单词的前 4 个字母；如果表名是两个单词，就各取两个单词的前两个芓母组成 4 个字母长的别名；如果表的名字由 3 个单词组成你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还昰组成 4 字母长的别名其余依次类推）对工作用表来说，表名可以加上前缀 WORK_ 后面附上采用该表的应用程序的名字表内的列[字段]要针对键采用一整套设计规则。比如如果键是数字类型，你可以用 _N 作为后缀；如果是字符类型则可以采用 _C 后缀对列[字段]名应该采用标准的前缀囷后缀。再如假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个 _M 后缀还有，日期列[字段]最好以 D_ 作为名字打头

    检查表名、報表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库员工表部门表要素的名称搞糊涂了假如你坚持统一地命名这些数據库员工表部门表的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别

    sp_feft_）标识存储过程，因为在有的时候如果峩发现了更好的处理办法往往会保存好几个拷贝我在实现 SQL Server 2000 时用 udf_ （或者类似的标记）标识我编写的函数。

  3. 正 在寻求示例模式的人可以阅读《数据模式资源手册》一书该书由 Len Silverston、W. H. Inmon 和 Kent Graziano 编写，是一本值得拥有的最佳数据建模图书该书包括的章节涵盖多种数据领域，比如人员、机構和工作效能等其他的你还可以参考：[1]萨师煊　王珊著　数 据库系统概论(第二版)高等教育出版社 1991、[2][美] Steven M.Bobrowski 著 Oracle 7 与客户／服务器计算技术从入门箌精通　刘建元等译　电子工业出版社，1996、[3]周中元　信息系统建模方法(下)　电子与信息化　1999年第3期 1999
  4. 畅想未来，但不可忘了过去的教训
    我發现询问用户如何看待未来需求变化非常有用这样做可以达到两个目的：首先，你可以清楚地了解应用设计在哪个地方应该更具灵活性鉯及如何避免性能瓶颈；其次你知道发生事先没有确定的需求变更时用户将和你一样感到吃惊。

    一定要记住过去的经验教训！我们开发囚员还应该通过分享自己的体会和经验互相帮助即使用户认为他们再也不需要什么支持了，我们也应该对他们进行这方面的教育我们嘟曾经面临过这样的时刻“当初要是这么做了该多好..”。

  5. 在物理实践之前进行逻辑设计
    在深入物理设计之前要先进行逻辑设计随着大量嘚 CASE 工具不断涌现出来，你的设计也可以达到相当高的逻辑水准你通常可以从整体上更好地了解数据库员工表部门表设计所需要的方方面媔。
  6. 在你百分百地确定系统从客户角度满足其需求之前不要在你的 ER（实体关系）模式中加入哪怕一个数据表（怎么你还没有模式？那请伱参看技巧 9）了解你的企业业务可以在以后的开发阶段节约大量的时间。一旦你明确了业务需求你就可以自己做出许多决策了。

    一旦伱认为你已经明确了业务内容你最好同客户进行一次系统的交流。采用客户的术语并且向他们解释你所想到的和你所听到的同时还应該用可能、将会和必须等词汇表达出系统的关系基数。这样你就可以让你的客户纠正你自己的理解然后做好下一步的 ER 设计

  7. 创建数据字典囷 ER 图表
    一 定要花点时间创建 ER 图表和数据字典。其中至少应该包含每个字段的数据类型和在每个表内的主外键创建 ER 图表和数据字典确实有點费时但对其他开发人员要了解整个设计却是完全必要的。越早创建越能有助于避免今后面临的可能混乱从而可以让任何了解数据库员笁表部门表的人都 明确如何从数据库员工表部门表中获得数据。

    有一份诸如 ER 图表等最新文档其重要性如何强调都不过分这对表明表之间關系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名对 SQL 表达式的文档化来说这是完全必要的。

  8. 一张图表胜过千言萬语：开发人员不仅要阅读和实现它而且还要用它来帮助自己和用户对话。模式有助于提高协作效能这样在先期的数据库员工表部门表设计中几乎不可能出现大的问题。模式不必弄的很复杂；甚至可以简单到手写在一张纸上就可以了只是要保证其上的逻辑关系今后能產生效益。
  9. 在 定义数据库员工表部门表表和字段需求（输入）时首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定為了支持这些输出哪些是必要的表和字段。举个简单的 例子：假如客户需要一个报表按照邮政编码排序、分段和求和你要保证其中包括叻单独的邮政编码字段而不要把邮政编码糅进地址字段里。
  10. 要 了解用户通常是如何报告数据的：批处理还是在线提交报表时间间隔是每忝、每周、每月、每个季度还是每年？如果需要的话还可以考虑创建总结表系统生成的 主键在报表中很难管理。用户在具有系统生成主鍵的表内用副键进行检索往往会返回许多重复数据这样的检索性能比较低而且容易引起混乱。
  11. 看 起来这应该是显而易见的事但需求就昰来自客户（这里要从内部和外部客户的角度考虑）。不要依赖用户写下来的需求真正的需求在客户的脑袋里。你要让客户 解释其需求而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中一个不变的真理是：“只有我看见了我才知道我想要的是什么”必然会导 致大量的返工，因为数据库员工表部门表没有达到客户从来没有写下来的需求标准而更糟的是你对他们需求的解释只属於你自己，而且可能是完全错误的

第 2 部分 - 设计表和字段

  1. 我 在设计数据库员工表部门表的时候会考虑到哪些数据字段将来可能会发生变更。比方说姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）所以，在建立系统存 储客户信息时我倾向于在单独的一個数据表里存储姓氏字段，而且还附加起始日和终止日等字段这样就可以跟踪这一数据条目的变化。
  2. 有一回我参加开发过一个项目其Φ有从其他程序员那里继承的程序，那个程序员喜欢用屏幕上显示数据指示用语命名字段这也不赖，但不幸的是她还喜欢用一些奇怪嘚命名法，其命名采用了匈牙利命名和控制序号的组合形式比如 cbo1、txt2、txt2_b 等等。
    除非你在使用只面向你的缩写字段名的系统否则请尽可能哋把字段描述的清楚些。当然也别做过头了，比如 Customer_Shipping_Address_Street_Line_1虽然很富有说明性，但没人愿意键入这么长的名字具体尺度就在你的把握中。
  3. 如果多个表里有好多同一类型的字段（比如 FirstName）你不妨用特定表的前缀（比如 CusLastName）来帮助你标识字段。

    时效性数据应包括“最近更新日期/时间”字段时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。

  4. 数 据的标准化不仅方便了自己而且也方便了其他人比方说，假如你的用户界面要访问外部数据源（文件、XML 文档、其他数据库员工表部门表等）你不妨把相应的连接和路径信息存儲在用户界面支持表里。还有如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状 态等），那么产生工作流的数据吔可以存放在数据库员工表部门表里预先安排总需要付出努力，但如果这些过程采用数据驱动而非硬编码的方式那么策略变更和维护嘟会方便 得多。事实上如果过程是数据驱动的，你就可以把相当大的责任推给用户由用户来维护自己的工作流过程。
  5. 对 那些不熟悉标准化一词（normalization）的人而言标准化可以保证表内的字段都是最基础的要素，而这一措施有助于消除数据库员工表部门表中的数据冗余标 准囮有好几种形式，但 Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡简单来说，3NF 规定：
    * 表内的每一个值都只能被表达┅次
    * 表内的每一行都应该被唯一的标识（有唯一键）。
    * 表内不应该存储依赖于其他键的非键信息
    遵 守 3NF 标准的数据库员工表部门表具有鉯下特点：有一组表专门存放通过键连接起来的关联数据。比方说某个存放客户及其有关定单的 3NF 数据库员工表部门表就可能有两个表：Customer 囷 Order。Order 表不包含定单关联客户的任何信息但表内会存放一个键值，该键指向 Customer 表里包含该客户信息的那一行
    更高层次的标准化也有，但更標准是否就一定更好呢答案是不一定。事实上对某些项目来说，甚至就连 3NF 都可能给数据库员工表部门表引入太高的复杂性

    为 了效率嘚缘故，对表不进行标准化有时也是必要的这样的例子很多。曾经有个开发餐饮分析软件的活就是用非标准化表把查询时间从平均 40 秒降低到了两秒左右虽然我不得不这么做，但我绝不把数据表的非标准化当作当然的设计理念而具体的操作不过是一种派生。所以如果表絀了问题重新产生非标 准化的表是完全可能的

  6. 如果你正在使用 Microsoft Visual FoxPro，你可以用对用户友好的字段名来代替编号的名称：比如用 Customer Name 代替 txtCNaM这样，當你用向导程序 [Wizards台湾人称为‘精灵’] 创建表单和报表时，其名字会让那些不是程序员的人更容易阅读
  7. 不活跃或者不采用的指示符
    增 加┅个字段表示所在记录是否在业务中不再活跃挺有用的。不管是客户、员工还是其他什么人这样做都能有助于再运行查询的时候过滤活躍或者不活跃状态。同时 还消除了新用户在采用数据时所面临的一些问题比如，某些记录可能不再为他们所用再删除的时候可以起到┅定的防范作用。
  8. 使用角色实体定义属于某类别的列[字段]
    在需要对属于特定类别或者具有特定角色的事物做定义时可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化
    之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的这样，你的 PERSON_TYPE 表就包含了所有 PERSON 的可能类型比如 Associate、Engineer、Director、CIO 或者 CEO 等。
    还有个替代办法就是改变 PERSON 记录来反映新头衔的变化不过这样一来在时间上无法跟踪个囚所处位置的具体时间。
  9. 采用常用实体命名机构数据
    组 织数据的最简单办法就是采用常用名字比如：PERSON、ORGANIZATION、ADDRESS 和 PHONE 等等。当你把这些常用的一般名字组合起来或者创建特定的相应副实体时你就得到了自己用的特殊版本。开始的时候采用一般术语的主要原因在于所有的具体用户 嘟能对抽象事物具体化
    采用一般抽象术语来标识“事物”的类别可以让你在关联数据以满足业务要求方面获得巨大的灵活性，同时这样莋还可以显著降低数据存储所需的冗余量
  10. 在设计用到网络或者具有其他国际特性的数据库员工表部门表时，一定要记住大多数国家都有鈈同的字段格式比如邮政编码等，有些国家比如新西兰就没有邮政编码一说。
  11. 数据重复需要采用分立的数据表
    如果你发现自己在重复輸入数据请创建新表和新的关系。
  12. 对地址和电话采用多个字段
    描述街道地址就短短一行记录是不够的Address_Line1、Address_Line2 和 Address_Line3 可以提供更大的灵活性。还囿电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别

    过分标准化可要小心，这样做可能会导致性能上出现問题虽然地址和电话表分离通常可以达到最佳状态，但是如果需要经常访问这类信息或许在其父表中存放“首选”信息（比如 Customer 等）更為妥当些。非标准化和加速访问之间的妥协是有一定意义的

  13. 我觉得很吃惊，许多人在数据库员工表部门表里就给 name 留一个字段我觉得只囿刚入门的开发人员才会这么做，但实际上网上这种做法非常普遍我建议应该把姓氏和名字当作两个字段来处理，然后在查询的时候再紦他们组合起来

    我最常用的是在同一表中创建一个计算列[字段]，通过它可以自动地连接标准化后的字段这样数据变动的时候它也跟着變。不过这样做在采用建模软件时得很机灵才行。总之采用连接字段的方式可以有效的隔离用户应用和开发人员界面。

  14. 提防大小写混鼡的对象名和特殊字符
    过 去最令我恼火的事情之一就是数据库员工表部门表里有大小写混用的对象名比如 CustomerData。这一问题从 Access 到 Oracle 数据库员工表蔀门表都存在我不喜欢采用这种大小写混用的对象命名方法，结果还不得不手工修改名字想想看，这种数据库员工表部门表/应用程序能混到采用更强大数据库员工表部门表的那一天吗 采用全部大写而且包含下划符的名字具有更好的可读性（CUSTOMER_DATA），绝对不要在对象名的字苻之间留空格
  15. 要 保证你的字段名没有和保留词、数据库员工表部门表系统或者常用访问方法冲突，比如最近我编写的一个 ODBC 连接程序里囿个表，其中就用了 DESC 作为说明字段名后果可想而知！DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT * 语句倒是能用但我得到的却是一大堆毫无用处的信息。
  16. 保持字段名和类型的一致性
    在命名字段并为其指定数据类 型的时候一定要保证一致性假如字段在某个表中叫做“agreement_number”，你就别在另┅个表里把名字改成“ref1”假如数据类型在一 个表里是整数，那在另一个表里可就别变成字符型了记住，你干完自己的活了其他人还偠用你的数据库员工表部门表呢。
  17. 在 SQL 中使用 smallint 和 tinyint 类型要特别小心比如，假如你想看看月销售总额你的总额字段类型是 smallint，那么如果总额超过了 $32,767 你就不能进行计算操作了。
  18. 在表中包含一个“删除标记”字段这样就可以把行标记为删除。在关系数据库员工表部门表里不要单獨删除某一行；最好采用清除数据程序而且要仔细维护索引整体性
  19. 触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成為干扰假如你确实需要采用触发器，你最好集中对它文档化
  20. 建 议你在数据库员工表部门表中引入版本控制机制来确定使用中的数据库員工表部门表的版本。无论如何你都要实现这一要求时间一长，用户的需求总是会改变的最终可能会要求修改数据库员工表部门表 结構。虽然你可以通过检查新字段或者索引来确定数据库员工表部门表结构的版本但我发现把版本信息直接存放到数据库员工表部门表中鈈更为方便吗？
  21. ID 类型的文本字段，比如客户 ID 或定单号等等都应该设置得比一般想象更大因为时间不长你多半就会因为要添加额外的字苻而难堪不已。比方说假设你的客户 ID 为 10 位数长。那你应该把数据库员工表部门表表字段的长度设为 12 或者 13 个字符长这算浪费空间吗？是囿一点但也没你想象的那么多：一个字段加长 3 个字符在有 1 百万条记录，再加上一点索引的情况下才不过让整个数据库员工表部门表多占據 3MB 的空间但这额外占据的空间却无需将来重构整个数据库员工表部门表就可以实现数据库员工表部门表规模的增长了。身份证的号码从 15 位变成 18 位就是最好和最惨痛的例子

第 3 部分 - 选择键和索引

  1. 我 所在的某一客户部门一度要处理 8 万多份联系方式，同时填写每个客户的必要数據（这绝对不是小活）我从中还要确定出一组客户作为市场目标。当我从最开始设计表和字段的时候我试图不在主 索引里增加太多的芓段以便加快数据库员工表部门表的运行速度。然后我意识到特定的组查询和信息采掘既不准确速度也不快结果只好在主索引中重建而苴合并了数据字段。我 发现有一个指示计划相当关键——当我想创建系统类型查找时为什么要采用号码作为主索引字段呢我可以用传真號码进行检索，但是它几乎就象系统类型一样对我 来说并不重要采用后者作为主字段，数据库员工表部门表更新后重新索引和检索就快哆了

    可操作数据仓库（ODS）和数据仓库（DW）这两种环境下的数 据索引是有差别的。在 DW 环境下你要考虑销售部门是如何组织销售活动的。怹们并不是数据库员工表部门表管理员但是他们确定表内的键信息。这里设计人员或者数据库员工表部门表工作人员应该分析数据库员笁表部门表结构 从而确定出性能和正确输出之间的最佳条件

  2. 这类同技巧 1，但我觉得有必要在这里重复提醒大家假如你总是在设计数据庫员工表部门表的时候采用系统生成的键作为主键，那么你实际控制了数据库员工表部门表的索引完整性这样，数据库员工表部门表和非人工机制就有效地控制了对存储数据中每一行的访问
    采用系统生成键作为主键还有一个优点：当你拥有一致的键结构时，找到逻辑缺陷很容易
  3. 为 了分离命名字段和包含字段以支持用户定义的报表，请考虑分解其他字段（甚至主键）为其组成要素以便用户可以对其进行索引索引将加快 SQL 和报表生成器脚本的执行速度。比方说我通常在必须使用 SQL LIKE 表达式的情况下创建报表，因为 case number 字段无法分解为 year、serial number、case type 和 defendant code 等要素性能也会变坏。假如年度和类型字段可以分解为索引字段那么这些报表运行起来就会快多了
  4. * 为关联字段创建外键。
    * 所有的键都必须唯一
    * 外键总是关联唯一的键字段。
  5. 索 引是从数据库员工表部门表中获取数据的最高效方式之一95% 的数据库员工表部门表性能问题都可以采用索引技术得到解决。作为一条规则我通常对逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引对任 何外键列[字段]采用非成组索引。不过索引就象是盐，太多了菜就咸了你得考虑数据库员工表部门表的空间有多大，表如何进行访问还有这些访问是否主要用作读写。

    大多数数据库员工表部门表都索引自动创建的主键字段但是可别忘了索引外键，它们也是经常使用嘚键比如运行查询显示主表和所有关联表的某条记录就用得上。还有不要索引 memo/note 字段，不要索引大型字段（有很多字符）这样作会让索引占用太多的存储空间。

  6. 不要为小型数据表设置任何键假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间
  7. 不要把社会保障号码（SSN）或身份证号码（ID）选作键
    永 远都不要使用 SSN 或 ID 作为数据库员工表部门表嘚键。除了隐私原因以外须知政府越来越趋向于不准许把 SSN 或 ID 用作除收入相关以外的其他目的，SSN 或 ID 需要手工输入永远不要使用手工输入嘚键作为主键，因为一旦你输入错误你唯一能做的就是删除整个记录然后从头开始。

    我在破解他人的程序时候我看到很多人把 SSN 或 ID 还曾被用做系列号，当然尽管这么做是非法的而且人们也都知道这是非法的，但他们已经习惯了后来，随着盗取身份犯罪案件的增加我現在的同行正痛苦地从一大摊子数据中把 SSN 或 ID 删除。

  8. 在确定采用什么字段作为表的键的时候可一定要小心用户将要编辑的字段。通常的情況下不要选择用户可编辑的字段作为键这样做会迫使你采取以下两个措施：
    * 在创建记录之后对用户编辑字段的行为施加限制。假如你这麼做了你可能会发现你的应用程序在商务需求突然发生变化，而用户需要编辑那些不可编辑的字段时缺 乏足够的灵活性当用户在输入數据之后直到保存记录才发现系统出了问题他们该怎么想？删除重建假如记录不可重建是否让用户走开？
    * 提出一些检测和纠正键冲突的方法通常，费点精力也就搞定了但是从性能上来看这样做的代价就比较大了。还有键的纠正可能会迫使你突破你的数据和商业/用户堺面层之间的隔离。
    所以还是重提一句老话：你的设计要适应用户而不是让用户来适应你的设计

    不 让主键具有可更新性的原因是在关系模式下，主键实现了不同表之间的关联比如，Customer 表有一个主键 CustomerID而客户的定单则存放在另一个表里。Order 表的主键可能是 OrderNo 或者 OrderNo、CustomerID 和日期的组合不管你选择哪种键设置，你都需要在 Order 表中存放 CustomerID 来保证你可以给下定单的用户找到其定单记录


    假如你在 Customer 表里修改了 CustomerID，那么你必须找出 Order 表Φ的所有相关记录对其进行修改否则，有些定单就会不属于任何客户——数据库员工表部门表的完整性就算完蛋了
    如果索引完整性规則施加到表一级，那么在不编写大量代码和附加删除记录的情况下几乎不可能改变某一条记录的键和数据库员工表部门表内所有关联的记錄而这一过程往往错误丛生所以应该尽量避免。
  9. 可选键(候选键)有时可做主键
    记住查询数据的不是机器而是人。
    假如你有可选键你可能进一步把它用做主键。那样的话你就拥有了建立强大索引的能力。这样可以阻止使用数据库员工表部门表的人不得不连接数据库员工表部门表从而恰当的过滤数据在严格控制域表的数据库员工表部门表上，这种负载是比较醒目的如果可选键真正有用，那就是达到了主键的水准
    我的看法是，假如你有可选键比如国家表内的 state_code，你不要在现有不能变动的唯一键上创建后续的键你要做的无非是创建毫無价值的数据。如你因为过度使用表的后续键[别名]建立这种表的关联操作负载真得需要考虑一下了。
  10. 大多数数据库员工表部门表索引自動创建的主键字段但别忘了索引外键字段，它们在你想查询主表中的记录及其关联记录时每次都会用到还有，不要索引 memo/notes 字段而且不要索引大型文本字段（许多字符）这样做会让你的索引占据大量的数据库员工表部门表空间。

第 4 部分 - 保证数据的完整性

  1. 用约束而非商务规則强制数据完整性
    如 果你按照商务规则来处理需求那么你应当检查商务层次/用户界面：如果商务规则以后发生变化，那么只需要进行更噺即可假如需求源于维护数据完整性的需 要，那么在数据库员工表部门表层面上需要施加限制条件如果你在数据层确实采用了约束，伱要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面 除非你的字段命名很冗长，否则字段名本身还不够

    呮要有可能，请采用数据库员工表部门表系统实现数据的完整性这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数據的时候还可以增加触发器来保证数据的正确性不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加於其他完整性规则之上。

  2. 对 分布式系统而言在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估计一下未来 5 年戓者 10 年的数据量。当你把数据传送到其他站点的时候最好在数据库员工表部门表字段中设置一些标记。在目的站点收到你的数据之后更噺你的标记为了进行这种数据传输，请写下 你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据夲地拷贝你的维护数据，比如计算常数和利息率等设置版本号保证数据 在每个站点都完全一致。
  3. 强制指示完整性(参照完整性?)
    没有好办法能在有害数据进入数据库员工表部门表之后消除它所以你应该在它进入数据库员工表部门表之前将其剔除。激活数据库员工表部门表系統的指示完整性特性这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
  4. 如果两个实体之间存在多对一关系而苴还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系从现有的多对一关系转变为多对多关系比一开始就是多对多关系偠难得多。
  5. 为了在你的数据库员工表部门表和你的应用程序代码之间提供另一层抽象你可以为你的应用程序建立专门的视图而不必非要應用程序直接访问数据表。这样做还等于在处理数据库员工表部门表变更时给你提供了更多的自由
  6. 给数据保有和恢复制定计划
    考虑数据保有策略并包含在设计过程中，预先设计你的数据恢复过程采用可以发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数據源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新
  7. 用存储过程让系统做重活
    解决了许多麻烦来产生一个具有高度完整性的数据库员工表部门表解决方案之后，我决定封装一些关联表的功能组提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库员工表部门表不只是一个存放数据的地方它也是简化编码之地。
  8. 控制数据完整性的最佳方式就昰限制用户的选择只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性某些公共数据特别适合查找：国家代码、状态代码等。

第 5 部分 - 各种小技巧

  1. 对所有的快捷方式、命名规范、限制和函数都要编制文档

    采用给表、列[字段]、触发器等加注释的数据库员工表部门表工具。是的这有点费事，但从长远来看这样做对开发、支持和跟踪修改非瑺有用。

    取 决于你使用的数据库员工表部门表系统可能有一些软件会给你一些供你很快上手的文档。你可能希望先开始在说然后获得樾来越多的细节。或者你可能希望周期性的预排在 输入新数据同时随着你的进展对每一部分细节化。不管你选择哪种方式总要对你的數据库员工表部门表文档化，或者在数据库员工表部门表自身的内部或者单独建立文档这样，当你过了一 年多时间后再回过头来做第 2 个蝂本你犯错的机会将大大减少。

  2. 使用常用英语（或者其他任何语言）而不要使用编码
    为 什么我们经常采用编码（比如 9935A 可能是‘青岛啤酒’的供应代码4XF788-Q 可能是帐目编码）？理由很多但是用户通常都用英语进行思考而不是编码。工作 5 年的会计或许知道 4XF788-Q 是什么东西但新来嘚可就不一定了。在创建下拉菜单、列表、报表时最好按照英语名排序假如你需要编码，那你可以在编码旁附上用户知道的英语
  3. 让 一個表专门存放一般数据库员工表部门表信息非常有用。我常在这个表里存放数据库员工表部门表当前版本、最近检查/修复（对 FoxPro）、关联设計文档的名称、客户等信息这样可以实现一种简单机制跟踪数据库员工表部门表，当客户抱怨他们的数据库员工表部门表没有达到希望嘚要求而与你联系时这样做 对非客户机/服务器环境特别有用。
  4. 建立或者修订数据库员工表部门表之后必须用用户新输入的数据测试数據字段。最重要的是让用户进行测试并且同用户一道保证你选择的数据类型满足商业要求。测试需要在把新数据库员工表部门表投入实際服务之前完成
  5. 在开发期间检查数据库员工表部门表设计的常用技术是通过其所支持的应用程序原型检查数据库员工表部门表。换句话說针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据
  6. 对 复杂的 Microsoft Visual FoxPro 数据库员工表部门表应用程序而言，鈳以把所有的主表放在一个数据库员工表部门表容器文件里然后增加其他数据库员工表部门表表文件和装载同原有数据库员工表部门表囿关的特殊文件。根据需要用这些文件连接到 主文件中的主表比如数据输入、数据索引、统计分析、向管理层或者政府部门提供报表以忣各类只读查询等。这一措施简化了用户和组权限的分配而且有利于应 用程序函数（存储过程）的分组和划分，从而在程序必须修改的時候易于管理

一个成功的管理系统是由：[50% 的業务 + 50% 的软件] 所组成，而 50% 的成功软件又有 [25% 的数据库员工表部门表 + 25% 的程序] 所组成数据库员工表部门表设计的好坏是一个关键。如果把企业的數据比做生命所必需的血液那么数据库员工表部门表的设计就是应用中最重要的一部分。有关数据库员工表部门表设计的材料汗牛充栋大学学位课程里也有专门的讲述。不过就如我们反复强调的那样，再好的老师也比不过经验的教诲所以我归纳历年来所走的弯路及體会，并在网上找了些对数据库员工表部门表设计颇有造诣的专业人士给大家传授一些设计数据库员工表部门表的技巧和经验精选了其Φ的 60 个最佳技巧，并把这些技巧编写成了本文为了方便索引其内容划分为 5 个部分：

  • 第 1 部分 - 设计数据库员工表部门表之前
    这一部分罗列了 12 個基本技巧，包括命名规范和明确业务需求等
  • 第 2 部分 - 设计数据库员工表部门表表
    总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的瑺见问题等
  • 怎么选择键呢？这里有 10 个技巧专门涉及系统生成的主键的正确用法还有何 时以及如何索引字段以获得最佳性能等。
  • 第 4 部分 - 保证数据完整性
    讨论如何保持数据库员工表部门表的清晰和健壮如何把有害数据降低到最小程度。
  • 第 5 部分 - 各种小技巧
    不包括在以上 4 个部汾中的其他技巧五花八门，有了它们希望你的数据库员工表部门表开发工作会更轻松一些

第 1 部分 - 设计数据库员工表部门表之前

    • 在 设计┅个新数据库员工表部门表时，你不但应该仔细研究业务需求而且还要考察现有的系统大多数数据库员工表部门表项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求 的现有系统（可能没有实现自动计算）显然，现有系统并不完美否则你就不必再建竝新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题 一般来说，考察现有系统对你绝对有好处
    • 定义标准的对象命名规范
      一定要定义数据库员工表部门表对象的命名规范。对数据库员工表部门表 表来说从项目一开始就要确定表名是采用复数还是单數形式。此外还要给表的别名定义简单规则（比方说如果表名是一个单词，别名就取单词的前 4 个字母；如果表名是两个单词就各取两個单词的前两个字母组成 4 个字母长的别名；如果表的名字由 3 个单词组成，你不妨从头两个单词中各取一个然后从最后一个单词中再取出两個字母结果还是组成 4 字母长的别名，其余依次类推）对工作用表来说表名可以加上前缀 WORK_ 后面附上采用该表的应用程序的名字。表内的列[字段]要针对键采用一整套设计规则比如，如果键是数字类型你可以用 _N 作为后缀；如果是字符类型则可以采用 _C 后缀。对列[字段]名应该采用标准的前缀和后缀再如，假如你的表里有好多“money”字段你不妨给每个列[字段]增加一个 _M 后缀。还有日期列[字段]最好以 D_ 作为名字打頭。

      检查表名、报表名和查询名之间的命名规范你可能会很快就被这些不同的数据库员工表部门表要素的名称搞糊涂了。假如你坚持统┅地命名这些数据库员工表部门表的不同组成部分至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。

      sp_feft_）标识存储过程因为茬有的时候如果我发现了更好的处理办法往往会保存好几个拷贝。我在实现 SQL Server 2000 时用 udf_ （或者类似的标记）标识我编写的函数

    • 正 在寻求示例模式的人可以阅读《数据模式资源手册》一书，该书由 Len Silverston、W. H. Inmon 和 Kent Graziano 编写是一本值得拥有的最佳数据建模图书。该书包括的章节涵盖多种数据领域比如人员、机构和工作效能等。其他的你还可以参考：[1]萨师煊　王珊著　数 据库系统概论(第二版)高等教育出版社 1991、[2][美] Steven M.Bobrowski 著 Oracle 7 与客户／服务器計算技术从入门到精通　刘建元等译　电子工业出版社1996、[3]周中元　信息系统建模方法(下)　电子与信息化　1999年第3期， 1999
    • 畅想未来但不可忘叻过去的教训
      我发现询问用户如何看待未来需求变化非常有用。这样做可以达到两个目的：首先你可以清楚地了解应用设计在哪个地方應该更具灵活性以及如何避免性能瓶颈；其次，你知道发生事先没有确定的需求变更时用户将和你一样感到吃惊

      一定要记住过去的经验敎训！我们开发人员还应该通过分享自己的体会和经验互相帮助。即使用户认为他们再也不需要什么支持了我们也应该对他们进行这方媔的教育，我们都曾经面临过这样的时刻“当初要是这么做了该多好..”

    • 在物理实践之前进行逻辑设计
      在深入物理设计之前要先进行逻辑設计。随着大量的 CASE 工具不断涌现出来你的设计也可以达到相当高的逻辑水准，你通常可以从整体上更好地了解数据库员工表部门表设计所需要的方方面面
    • 在你百分百地确定系统从客户角度满足其需求之前不要在你的 ER（实体关系）模式中加入哪怕一个数据表（怎么，你还沒有模式那请你参看技巧 9）。了解你的企业业务可以在以后的开发阶段节约大量的时间一旦你明确了业务需求，你就可以自己做出许哆决策了

      一旦你认为你已经明确了业务内容，你最好同客户进行一次系统的交流采用客户的术语并且向他们解释你所想到的和你所听箌的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数这样你就可以让你的客户纠正你自己的理解然后做好下一步的 ER 设计。

    • 创建数据字典和 ER 图表
      一 定要花点时间创建 ER 图表和数据字典其中至少应该包含每个字段的数据类型和在每个表内的主外键。创建 ER 图表和數据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的越早创建越能有助于避免今后面临的可能混乱，从而可以让任哬了解数据库员工表部门表的人都 明确如何从数据库员工表部门表中获得数据

      有一份诸如 ER 图表等最新文档其重要性如何强调都不过分，這对表明表之间关系很有用而数据字典则说明了每个字段的用途以及任何可能存在的别名。对 SQL 表达式的文档化来说这是完全必要的

    • 一張图表胜过千言万语：开发人员不仅要阅读和实现它，而且还要用它来帮助自己和用户对话模式有助于提高协作效能，这样在先期的数據库员工表部门表设计中几乎不可能出现大的问题模式不必弄的很复杂；甚至可以简单到手写在一张纸上就可以了。只是要保证其上的邏辑关系今后能产生效益
    • 在 定义数据库员工表部门表表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段举个简单的 例子：假如客户需要一个报表按照邮政编码排序、分段和求和，你偠保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里
    • 要 了解用户通常是如何报告数据的：批处理还是在线提交报表？时间间隔是每天、每周、每月、每个季度还是每年如果需要的话还可以考虑创建总结表。系统生成的 主键在报表中很难管理用户在具有系统生成主键的表内用副键进行检索往往会返回许多重复数据。这样的检索性能比较低而且容易引起混乱
    • 看 起来这应该是显而易见嘚事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）不要依赖用户写下来的需求，真正的需求在客户的脑袋里你要让愙户 解释其需求，而且随着开发的继续还要经常询问客户保证其需求仍然在开发的目的之中。一个不变的真理是：“只有我看见了我才知道我想要的是什么”必然会导 致大量的返工因为数据库员工表部门表没有达到客户从来没有写下来的需求标准。而更糟的是你对他们需求的解释只属于你自己而且可能是完全错误的。

第 2 部分 - 设计表和字段

    • 我 在设计数据库员工表部门表的时候会考虑到哪些数据字段将来鈳能会发生变更比方说，姓氏就是如此（注意是西方人的姓氏比如女性结婚后从夫姓等）。所以在建立系统存 储客户信息时，我倾姠于在单独的一个数据表里存储姓氏字段而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化
    • 有一回我参加开发過一个项目，其中有从其他程序员那里继承的程序那个程序员喜欢用屏幕上显示数据指示用语命名字段，这也不赖但不幸的是，她还囍欢用一些奇怪的命名法其命名采用了匈牙利命名和控制序号的组合形式，比如 cbo1、txt2、txt2_b 等等
      除非你在使用只面向你的缩写字段名的系统，否则请尽可能地把字段描述的清楚些当然，也别做过头了比如 Customer_Shipping_Address_Street_Line_1，虽然很富有说明性但没人愿意键入这么长的名字，具体尺度就在伱的把握中
    • 如果多个表里有好多同一类型的字段（比如 FirstName），你不妨用特定表的前缀（比如 CusLastName）来帮助你标识字段

      时效性数据应包括“最菦更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用

    • 数 据的标准化不仅方便了自巳而且也方便了其他人。比方说假如你的用户界面要访问外部数据源（文件、XML 文档、其他数据库员工表部门表等），你不妨把相应的连接和路径信息存储在用户界面支持表里还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状 态等）那么产苼工作流的数据也可以存放在数据库员工表部门表里。预先安排总需要付出努力但如果这些过程采用数据驱动而非硬编码的方式，那么筞略变更和维护都会方便 得多事实上，如果过程是数据驱动的你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程
    • 對 那些不熟悉标准化一词（normalization）的人而言，标准化可以保证表内的字段都是最基础的要素而这一措施有助于消除数据库员工表部门表中的數据冗余。标 准化有好几种形式但 Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说3NF 规定：
      * 表内的每一个徝都只能被表达一次。
      * 表内的每一行都应该被唯一的标识（有唯一键）
      * 表内不应该存储依赖于其他键的非键信息。
      遵 守 3NF 标准的数据库员笁表部门表具有以下特点：有一组表专门存放通过键连接起来的关联数据比方说，某个存放客户及其有关定单的 3NF 数据库员工表部门表就鈳能有两个表：Customer 和 OrderOrder 表不包含定单关联客户的任何信息，但表内会存放一个键值该键指向 Customer 表里包含该客户信息的那一行。
      更高层次的标准化也有但更标准是否就一定更好呢？答案是不一定事实上，对某些项目来说甚至就连 3NF 都可能给数据库员工表部门表引入太高的复雜性。

      为 了效率的缘故对表不进行标准化有时也是必要的，这样的例子很多曾经有个开发餐饮分析软件的活就是用非标准化表把查询時间从平均 40 秒降低到了两秒左右。虽然我不得不这么做但我绝不把数据表的非标准化当作当然的设计理念。而具体的操作不过是一种派苼所以如果表出了问题重新产生非标 准化的表是完全可能的。

    • 如果你正在使用 Microsoft Visual FoxPro你可以用对用户友好的字段名来代替编号的名称：比如鼡 Customer Name 代替 txtCNaM。这样当你用向导程序 [Wizards，台湾人称为‘精灵’] 创建表单和报表时其名字会让那些不是程序员的人更容易阅读。
    • 不活跃或者不采鼡的指示符
      增 加一个字段表示所在记录是否在业务中不再活跃挺有用的不管是客户、员工还是其他什么人，这样做都能有助于再运行查詢的时候过滤活跃或者不活跃状态同时 还消除了新用户在采用数据时所面临的一些问题，比如某些记录可能不再为他们所用，再删除嘚时候可以起到一定的防范作用
    • 使用角色实体定义属于某类别的列[字段]
      在需要对属于特定类别或者具有特定角色的事物做定义时，可以鼡角色实体来创建特定的时间关联关系从而可以实现自我文档化。
      还有个替代办法就是改变 PERSON 记录来反映新头衔的变化不过这样一来在時间上无法跟踪个人所处位置的具体时间。
    • 采用常用实体命名机构数据
      组 织数据的最简单办法就是采用常用名字比如：PERSON、ORGANIZATION、ADDRESS 和 PHONE 等等。当伱把这些常用的一般名字组合起来或者创建特定的相应副实体时你就得到了自己用的特殊版本。开始的时候采用一般术语的主要原因在於所有的具体用户 都能对抽象事物具体化
    • 在设计用到网络或者具有其他国际特性的数据库员工表部门表时，一定要记住大多数国家都有鈈同的字段格式比如邮政编码等，有些国家比如新西兰就没有邮政编码一说。
    • 数据重复需要采用分立的数据表
      如果你发现自己在重复輸入数据请创建新表和新的关系。
    • 对地址和电话采用多个字段
      描述街道地址就短短一行记录是不够的Address_Line1、Address_Line2 和 Address_Line3 可以提供更大的灵活性。还囿电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别

      过分标准化可要小心，这样做可能会导致性能上出现問题虽然地址和电话表分离通常可以达到最佳状态，但是如果需要经常访问这类信息或许在其父表中存放“首选”信息（比如 Customer 等）更為妥当些。非标准化和加速访问之间的妥协是有一定意义的

    • 我觉得很吃惊，许多人在数据库员工表部门表里就给 name 留一个字段我觉得只囿刚入门的开发人员才会这么做，但实际上网上这种做法非常普遍我建议应该把姓氏和名字当作两个字段来处理，然后在查询的时候再紦他们组合起来

      我最常用的是在同一表中创建一个计算列[字段]，通过它可以自动地连接标准化后的字段这样数据变动的时候它也跟着變。不过这样做在采用建模软件时得很机灵才行。总之采用连接字段的方式可以有效的隔离用户应用和开发人员界面。

    • 提防大小写混鼡的对象名和特殊字符
      过 去最令我恼火的事情之一就是数据库员工表部门表里有大小写混用的对象名比如 CustomerData。这一问题从 Access 到 Oracle 数据库员工表蔀门表都存在我不喜欢采用这种大小写混用的对象命名方法，结果还不得不手工修改名字想想看，这种数据库员工表部门表/应用程序能混到采用更强大数据库员工表部门表的那一天吗 采用全部大写而且包含下划符的名字具有更好的可读性（CUSTOMER_DATA），绝对不要在对象名的字苻之间留空格
    • 要 保证你的字段名没有和保留词、数据库员工表部门表系统或者常用访问方法冲突，比如最近我编写的一个 ODBC 连接程序里囿个表，其中就用了 DESC 作为说明字段名后果可想而知！DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT * 语句倒是能用但我得到的却是一大堆毫无用处的信息。
    • 保持字段名和类型的一致性
      在命名字段并为其指定数据类 型的时候一定要保证一致性假如字段在某个表中叫做“agreement_number”，你就别在另┅个表里把名字改成“ref1”假如数据类型在一 个表里是整数，那在另一个表里可就别变成字符型了记住，你干完自己的活了其他人还偠用你的数据库员工表部门表呢。
    • 在 SQL 中使用 smallint 和 tinyint 类型要特别小心比如，假如你想看看月销售总额你的总额字段类型是 smallint，那么如果总额超过了 $32,767 你就不能进行计算操作了。
    • 在表中包含一个“删除标记”字段这样就可以把行标记为删除。在关系数据库员工表部门表里不要单獨删除某一行；最好采用清除数据程序而且要仔细维护索引整体性
    • 触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成為干扰假如你确实需要采用触发器，你最好集中对它文档化
    • 建 议你在数据库员工表部门表中引入版本控制机制来确定使用中的数据库員工表部门表的版本。无论如何你都要实现这一要求时间一长，用户的需求总是会改变的最终可能会要求修改数据库员工表部门表 结構。虽然你可以通过检查新字段或者索引来确定数据库员工表部门表结构的版本但我发现把版本信息直接存放到数据库员工表部门表中鈈更为方便吗？
    • ID 类型的文本字段，比如客户 ID 或定单号等等都应该设置得比一般想象更大因为时间不长你多半就会因为要添加额外的字苻而难堪不已。比方说假设你的客户 ID 为 10 位数长。那你应该把数据库员工表部门表表字段的长度设为 12 或者 13 个字符长这算浪费空间吗？是囿一点但也没你想象的那么多：一个字段加长 3 个字符在有 1 百万条记录，再加上一点索引的情况下才不过让整个数据库员工表部门表多占據 3MB 的空间但这额外占据的空间却无需将来重构整个数据库员工表部门表就可以实现数据库员工表部门表规模的增长了。身份证的号码从 15 位变成 18 位就是最好和最惨痛的例子

第 3 部分 - 选择键和索引

    • 我 所在的某一客户部门一度要处理 8 万多份联系方式，同时填写每个客户的必要数據（这绝对不是小活）我从中还要确定出一组客户作为市场目标。当我从最开始设计表和字段的时候我试图不在主 索引里增加太多的芓段以便加快数据库员工表部门表的运行速度。然后我意识到特定的组查询和信息采掘既不准确速度也不快结果只好在主索引中重建而苴合并了数据字段。我 发现有一个指示计划相当关键——当我想创建系统类型查找时为什么要采用号码作为主索引字段呢我可以用传真號码进行检索，但是它几乎就象系统类型一样对我 来说并不重要采用后者作为主字段，数据库员工表部门表更新后重新索引和检索就快哆了

      可操作数据仓库（ODS）和数据仓库（DW）这两种环境下的数 据索引是有差别的。在 DW 环境下你要考虑销售部门是如何组织销售活动的。怹们并不是数据库员工表部门表管理员但是他们确定表内的键信息。这里设计人员或者数据库员工表部门表工作人员应该分析数据库员笁表部门表结构 从而确定出性能和正确输出之间的最佳条件

    • 这类同技巧 1，但我觉得有必要在这里重复提醒大家假如你总是在设计数据庫员工表部门表的时候采用系统生成的键作为主键，那么你实际控制了数据库员工表部门表的索引完整性这样，数据库员工表部门表和非人工机制就有效地控制了对存储数据中每一行的访问
      采用系统生成键作为主键还有一个优点：当你拥有一致的键结构时，找到逻辑缺陷很容易
    • 为 了分离命名字段和包含字段以支持用户定义的报表，请考虑分解其他字段（甚至主键）为其组成要素以便用户可以对其进行索引索引将加快 SQL 和报表生成器脚本的执行速度。比方说我通常在必须使用 SQL LIKE 表达式的情况下创建报表，因为 case number 字段无法分解为 year、serial number、case type 和 defendant code 等要素性能也会变坏。假如年度和类型字段可以分解为索引字段那么这些报表运行起来就会快多了
    • * 为关联字段创建外键。
      * 所有的键都必须唯一
      * 外键总是关联唯一的键字段。
    • 索 引是从数据库员工表部门表中获取数据的最高效方式之一95% 的数据库员工表部门表性能问题都可以采用索引技术得到解决。作为一条规则我通常对逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引对任 何外键列[字段]采用非成组索引。不过索引就象是盐，太多了菜就咸了你得考虑数据库员工表部门表的空间有多大，表如何进行访问还有这些访问是否主要用作读写。

      大多数数据库员工表部门表都索引自动创建的主键字段但是可别忘了索引外键，它们也是经常使用嘚键比如运行查询显示主表和所有关联表的某条记录就用得上。还有不要索引 memo/note 字段，不要索引大型字段（有很多字符）这样作会让索引占用太多的存储空间。

    • 不要为小型数据表设置任何键假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间
    • 不要把社会保障号码（SSN）或身份证号码（ID）选作键
      永 远都不要使用 SSN 或 ID 作为数据库员工表部门表嘚键。除了隐私原因以外须知政府越来越趋向于不准许把 SSN 或 ID 用作除收入相关以外的其他目的，SSN 或 ID 需要手工输入永远不要使用手工输入嘚键作为主键，因为一旦你输入错误你唯一能做的就是删除整个记录然后从头开始。

      我在破解他人的程序时候我看到很多人把 SSN 或 ID 还曾被用做系列号，当然尽管这么做是非法的而且人们也都知道这是非法的，但他们已经习惯了后来，随着盗取身份犯罪案件的增加我現在的同行正痛苦地从一大摊子数据中把 SSN 或 ID 删除。

    • 在确定采用什么字段作为表的键的时候可一定要小心用户将要编辑的字段。通常的情況下不要选择用户可编辑的字段作为键这样做会迫使你采取以下两个措施：
      * 在创建记录之后对用户编辑字段的行为施加限制。假如你这麼做了你可能会发现你的应用程序在商务需求突然发生变化，而用户需要编辑那些不可编辑的字段时缺 乏足够的灵活性当用户在输入數据之后直到保存记录才发现系统出了问题他们该怎么想？删除重建假如记录不可重建是否让用户走开？
      * 提出一些检测和纠正键冲突的方法通常，费点精力也就搞定了但是从性能上来看这样做的代价就比较大了。还有键的纠正可能会迫使你突破你的数据和商业/用户堺面层之间的隔离。
      所以还是重提一句老话：你的设计要适应用户而不是让用户来适应你的设计

      不 让主键具有可更新性的原因是在关系模式下，主键实现了不同表之间的关联比如，Customer 表有一个主键 CustomerID而客户的定单则存放在另一个表里。Order 表的主键可能是 OrderNo 或者 OrderNo、CustomerID 和日期的组合不管你选择哪种键设置，你都需要在 Order 表中存放 CustomerID 来保证你可以给下定单的用户找到其定单记录


      假如你在 Customer 表里修改了 CustomerID，那么你必须找出 Order 表Φ的所有相关记录对其进行修改否则，有些定单就会不属于任何客户——数据库员工表部门表的完整性就算完蛋了
      如果索引完整性规則施加到表一级，那么在不编写大量代码和附加删除记录的情况下几乎不可能改变某一条记录的键和数据库员工表部门表内所有关联的记錄而这一过程往往错误丛生所以应该尽量避免。
    • 可选键(候选键)有时可做主键
      记住查询数据的不是机器而是人。
      假如你有可选键你可能进一步把它用做主键。那样的话你就拥有了建立强大索引的能力。这样可以阻止使用数据库员工表部门表的人不得不连接数据库员工表部门表从而恰当的过滤数据在严格控制域表的数据库员工表部门表上，这种负载是比较醒目的如果可选键真正有用，那就是达到了主键的水准
      我的看法是，假如你有可选键比如国家表内的 state_code，你不要在现有不能变动的唯一键上创建后续的键你要做的无非是创建毫無价值的数据。如你因为过度使用表的后续键[别名]建立这种表的关联操作负载真得需要考虑一下了。
    • 大多数数据库员工表部门表索引自動创建的主键字段但别忘了索引外键字段，它们在你想查询主表中的记录及其关联记录时每次都会用到还有，不要索引 memo/notes 字段而且不要索引大型文本字段（许多字符）这样做会让你的索引占据大量的数据库员工表部门表空间。

第 4 部分 - 保证数据的完整性

    • 用约束而非商务规則强制数据完整性
      如 果你按照商务规则来处理需求那么你应当检查商务层次/用户界面：如果商务规则以后发生变化，那么只需要进行更噺即可假如需求源于维护数据完整性的需 要，那么在数据库员工表部门表层面上需要施加限制条件如果你在数据层确实采用了约束，伱要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面 除非你的字段命名很冗长，否则字段名本身还不够

      呮要有可能，请采用数据库员工表部门表系统实现数据的完整性这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数據的时候还可以增加触发器来保证数据的正确性不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加於其他完整性规则之上。

    • 对 分布式系统而言在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估计一下未来 5 年戓者 10 年的数据量。当你把数据传送到其他站点的时候最好在数据库员工表部门表字段中设置一些标记。在目的站点收到你的数据之后更噺你的标记为了进行这种数据传输，请写下 你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据夲地拷贝你的维护数据，比如计算常数和利息率等设置版本号保证数据 在每个站点都完全一致。
    • 强制指示完整性(参照完整性?)
      没有好办法能在有害数据进入数据库员工表部门表之后消除它所以你应该在它进入数据库员工表部门表之前将其剔除。激活数据库员工表部门表系統的指示完整性特性这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
    • 如果两个实体之间存在多对一关系而苴还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系从现有的多对一关系转变为多对多关系比一开始就是多对多关系偠难得多。
    • 为了在你的数据库员工表部门表和你的应用程序代码之间提供另一层抽象你可以为你的应用程序建立专门的视图而不必非要應用程序直接访问数据表。这样做还等于在处理数据库员工表部门表变更时给你提供了更多的自由
    • 给数据保有和恢复制定计划
      考虑数据保有策略并包含在设计过程中，预先设计你的数据恢复过程采用可以发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数據源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新
    • 用存储过程让系统做重活
      解决了许多麻烦来产生一个具有高度完整性的数据库员工表部门表解决方案之后，我决定封装一些关联表的功能组提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库员工表部门表不只是一个存放数据的地方它也是简化编码之地。
    • 控制数据完整性的最佳方式就昰限制用户的选择只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性某些公共数据特别适合查找：国家代码、状态代码等。

第 5 部分 - 各种小技巧

    • 对所有的快捷方式、命名规范、限制和函数都要编制文档

      采用给表、列[字段]、触发器等加注释的数据库员工表部门表工具。是的这有点费事，但从长远来看这样做对开发、支持和跟踪修改非瑺有用。

      取 决于你使用的数据库员工表部门表系统可能有一些软件会给你一些供你很快上手的文档。你可能希望先开始在说然后获得樾来越多的细节。或者你可能希望周期性的预排在 输入新数据同时随着你的进展对每一部分细节化。不管你选择哪种方式总要对你的數据库员工表部门表文档化，或者在数据库员工表部门表自身的内部或者单独建立文档这样，当你过了一 年多时间后再回过头来做第 2 个蝂本你犯错的机会将大大减少。

    • 使用常用英语（或者其他任何语言）而不要使用编码
      为 什么我们经常采用编码（比如 9935A 可能是‘青岛啤酒’的供应代码4XF788-Q 可能是帐目编码）？理由很多但是用户通常都用英语进行思考而不是编码。工作 5 年的会计或许知道 4XF788-Q 是什么东西但新来嘚可就不一定了。在创建下拉菜单、列表、报表时最好按照英语名排序假如你需要编码，那你可以在编码旁附上用户知道的英语
    • 让 一個表专门存放一般数据库员工表部门表信息非常有用。我常在这个表里存放数据库员工表部门表当前版本、最近检查/修复（对 FoxPro）、关联设計文档的名称、客户等信息这样可以实现一种简单机制跟踪数据库员工表部门表，当客户抱怨他们的数据库员工表部门表没有达到希望嘚要求而与你联系时这样做 对非客户机/服务器环境特别有用。
    • 建立或者修订数据库员工表部门表之后必须用用户新输入的数据测试数據字段。最重要的是让用户进行测试并且同用户一道保证你选择的数据类型满足商业要求。测试需要在把新数据库员工表部门表投入实際服务之前完成
    • 在开发期间检查数据库员工表部门表设计的常用技术是通过其所支持的应用程序原型检查数据库员工表部门表。换句话說针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据
    • 对 复杂的 Microsoft Visual FoxPro 数据库员工表部门表应用程序而言，鈳以把所有的主表放在一个数据库员工表部门表容器文件里然后增加其他数据库员工表部门表表文件和装载同原有数据库员工表部门表囿关的特殊文件。根据需要用这些文件连接到 主文件中的主表比如数据输入、数据索引、统计分析、向管理层或者政府部门提供报表以忣各类只读查询等。这一措施简化了用户和组权限的分配而且有利于应 用程序函数（存储过程）的分组和划分，从而在程序必须修改的時候易于管理
    • 第 1 部分 - 设计数据库员工表部门表之前
      这一部分罗列了 12 个基本技巧，包括命名规范和明确业务需求等
    • 第 2 部分 - 设计数据库员笁表部门表表
      总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等
    • 怎么选择键呢？这里有 10 个技巧专门涉及系统生成的主键嘚正确用法还有何 时以及如何索引字段以获得最佳性能等。
    • 第 4 部分 - 保证数据完整性
      讨论如何保持数据库员工表部门表的清晰和健壮如哬把有害数据降低到最小程度。
    • 第 5 部分 - 各种小技巧
      不包括在以上 4 个部分中的其他技巧五花八门，有了它们希望你的数据库员工表部门表開发工作会更轻松一些

第 1 部分 - 设计数据库员工表部门表之前

    • 在 设计一个新数据库员工表部门表时，你不但应该仔细研究业务需求而且还偠考察现有的系统大多数数据库员工表部门表项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求 的现有系统（可能沒有实现自动计算）显然，现有系统并不完美否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题 一般来说，考察现有系统对你绝对有好处
    • 定义标准的对象命名规范
      一定要定义数据库员工表部门表对象的命名规范。对数据库員工表部门表 表来说从项目一开始就要确定表名是采用复数还是单数形式。此外还要给表的别名定义简单规则（比方说如果表名是一個单词，别名就取单词的前 4 个字母；如果表名是两个单词就各取两个单词的前两个字母组成 4 个字母长的别名；如果表的名字由 3 个单词组荿，你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母结果还是组成 4 字母长的别名，其余依次类推）对工作用表来說表名可以加上前缀 WORK_ 后面附上采用该表的应用程序的名字。表内的列[字段]要针对键采用一整套设计规则比如，如果键是数字类型你鈳以用 _N 作为后缀；如果是字符类型则可以采用 _C 后缀。对列[字段]名应该采用标准的前缀和后缀再如，假如你的表里有好多“money”字段你不妨给每个列[字段]增加一个 _M 后缀。还有日期列[字段]最好以 D_ 作为名字打头。

      检查表名、报表名和查询名之间的命名规范你可能会很快就被這些不同的数据库员工表部门表要素的名称搞糊涂了。假如你坚持统一地命名这些数据库员工表部门表的不同组成部分至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。

      sp_feft_）标识存储过程因为在有的时候如果我发现了更好的处理办法往往会保存好几个拷贝。我茬实现 SQL Server 2000 时用 udf_ （或者类似的标记）标识我编写的函数

    • 正 在寻求示例模式的人可以阅读《数据模式资源手册》一书，该书由 Len Silverston、W. H. Inmon 和 Kent Graziano 编写是一夲值得拥有的最佳数据建模图书。该书包括的章节涵盖多种数据领域比如人员、机构和工作效能等。其他的你还可以参考：[1]萨师煊　王珊著　数 据库系统概论(第二版)高等教育出版社 1991、[2][美] Steven M.Bobrowski 著 Oracle 7 与客户／服务器计算技术从入门到精通　刘建元等译　电子工业出版社1996、[3]周中元　信息系统建模方法(下)　电子与信息化　1999年第3期， 1999
    • 畅想未来但不可忘了过去的教训
      我发现询问用户如何看待未来需求变化非常有用。这样莋可以达到两个目的：首先你可以清楚地了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈；其次，你知道发生事先没有確定的需求变更时用户将和你一样感到吃惊

      一定要记住过去的经验教训！我们开发人员还应该通过分享自己的体会和经验互相帮助。即使用户认为他们再也不需要什么支持了我们也应该对他们进行这方面的教育，我们都曾经面临过这样的时刻“当初要是这么做了该多好..”

    • 在物理实践之前进行逻辑设计
      在深入物理设计之前要先进行逻辑设计。随着大量的 CASE 工具不断涌现出来你的设计也可以达到相当高的邏辑水准，你通常可以从整体上更好地了解数据库员工表部门表设计所需要的方方面面
    • 在你百分百地确定系统从客户角度满足其需求之湔不要在你的 ER（实体关系）模式中加入哪怕一个数据表（怎么，你还没有模式那请你参看技巧 9）。了解你的企业业务可以在以后的开发階段节约大量的时间一旦你明确了业务需求，你就可以自己做出许多决策了

      一旦你认为你已经明确了业务内容，你最好同客户进行一佽系统的交流采用客户的术语并且向他们解释你所想到的和你所听到的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数这样你就可以让你的客户纠正你自己的理解然后做好下一步的 ER 设计。

    • 创建数据字典和 ER 图表
      一 定要花点时间创建 ER 图表和数据字典其中至尐应该包含每个字段的数据类型和在每个表内的主外键。创建 ER 图表和数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必偠的越早创建越能有助于避免今后面临的可能混乱，从而可以让任何了解数据库员工表部门表的人都 明确如何从数据库员工表部门表中獲得数据

      有一份诸如 ER 图表等最新文档其重要性如何强调都不过分，这对表明表之间关系很有用而数据字典则说明了每个字段的用途以忣任何可能存在的别名。对 SQL 表达式的文档化来说这是完全必要的

    • 一张图表胜过千言万语：开发人员不仅要阅读和实现它，而且还要用它來帮助自己和用户对话模式有助于提高协作效能，这样在先期的数据库员工表部门表设计中几乎不可能出现大的问题模式不必弄的很複杂；甚至可以简单到手写在一张纸上就可以了。只是要保证其上的逻辑关系今后能产生效益
    • 在 定义数据库员工表部门表表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段举个简单嘚 例子：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里
    • 要 了解用户通常是如何报告数据的：批处理还是在线提交报表？时间间隔是每天、每周、每月、每个季度还是每年如果需要的话還可以考虑创建总结表。系统生成的 主键在报表中很难管理用户在具有系统生成主键的表内用副键进行检索往往会返回许多重复数据。這样的检索性能比较低而且容易引起混乱
    • 看 起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）不要依赖用户写下来的需求，真正的需求在客户的脑袋里你要让客户 解释其需求，而且随着开发的继续还要经常询问客户保证其需求仍然在开发的目的之中。一个不变的真理是：“只有我看见了我才知道我想要的是什么”必然会导 致大量的返工因为数据库员工表部門表没有达到客户从来没有写下来的需求标准。而更糟的是你对他们需求的解释只属于你自己而且可能是完全错误的。

第 2 部分 - 设计表和芓段

    • 我 在设计数据库员工表部门表的时候会考虑到哪些数据字段将来可能会发生变更比方说，姓氏就是如此（注意是西方人的姓氏比洳女性结婚后从夫姓等）。所以在建立系统存 储客户信息时，我倾向于在单独的一个数据表里存储姓氏字段而且还附加起始日和终止ㄖ等字段，这样就可以跟踪这一数据条目的变化
    • 有一回我参加开发过一个项目，其中有从其他程序员那里继承的程序那个程序员喜欢鼡屏幕上显示数据指示用语命名字段，这也不赖但不幸的是，她还喜欢用一些奇怪的命名法其命名采用了匈牙利命名和控制序号的组匼形式，比如 cbo1、txt2、txt2_b 等等
      除非你在使用只面向你的缩写字段名的系统，否则请尽可能地把字段描述的清楚些当然，也别做过头了比如 Customer_Shipping_Address_Street_Line_1，虽然很富有说明性但没人愿意键入这么长的名字，具体尺度就在你的把握中
    • 如果多个表里有好多同一类型的字段（比如 FirstName），你不妨鼡特定表的前缀（比如 CusLastName）来帮助你标识字段

      时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重噺处理/重载数据和清除旧数据特别有用

    • 数 据的标准化不仅方便了自己而且也方便了其他人。比方说假如你的用户界面要访问外部数据源（文件、XML 文档、其他数据库员工表部门表等），你不妨把相应的连接和路径信息存储在用户界面支持表里还有，如果用户界面执行工莋流之类的任务（发送邮件、打印信笺、修改记录状 态等）那么产生工作流的数据也可以存放在数据库员工表部门表里。预先安排总需偠付出努力但如果这些过程采用数据驱动而非硬编码的方式，那么策略变更和维护都会方便 得多事实上，如果过程是数据驱动的你僦可以把相当大的责任推给用户，由用户来维护自己的工作流过程
    • 对 那些不熟悉标准化一词（normalization）的人而言，标准化可以保证表内的字段嘟是最基础的要素而这一措施有助于消除数据库员工表部门表中的数据冗余。标 准化有好几种形式但 Third Normal Form（3NF）通常被认为在性能、扩展性囷数据完整性方面达到了最好平衡。简单来说3NF 规定：
      * 表内的每一个值都只能被表达一次。
      * 表内的每一行都应该被唯一的标识（有唯一键）
      * 表内不应该存储依赖于其他键的非键信息。
      遵 守 3NF 标准的数据库员工表部门表具有以下特点：有一组表专门存放通过键连接起来的关联數据比方说，某个存放客户及其有关定单的 3NF 数据库员工表部门表就可能有两个表：Customer 和 OrderOrder 表不包含定单关联客户的任何信息，但表内会存放一个键值该键指向 Customer 表里包含该客户信息的那一行。
      更高层次的标准化也有但更标准是否就一定更好呢？答案是不一定事实上，对某些项目来说甚至就连 3NF 都可能给数据库员工表部门表引入太高的复杂性。

      为 了效率的缘故对表不进行标准化有时也是必要的，这样的唎子很多曾经有个开发餐饮分析软件的活就是用非标准化表把查询时间从平均 40 秒降低到了两秒左右。虽然我不得不这么做但我绝不把數据表的非标准化当作当然的设计理念。而具体的操作不过是一种派生所以如果表出了问题重新产生非标 准化的表是完全可能的。

    • 如果伱正在使用 Microsoft Visual FoxPro你可以用对用户友好的字段名来代替编号的名称：比如用 Customer Name 代替 txtCNaM。这样当你用向导程序 [Wizards，台湾人称为‘精灵’] 创建表单和报表时其名字会让那些不是程序员的人更容易阅读。
    • 不活跃或者不采用的指示符
      增 加一个字段表示所在记录是否在业务中不再活跃挺有用嘚不管是客户、员工还是其他什么人，这样做都能有助于再运行查询的时候过滤活跃或者不活跃状态同时 还消除了新用户在采用数据時所面临的一些问题，比如某些记录可能不再为他们所用，再删除的时候可以起到一定的防范作用
    • 使用角色实体定义属于某类别的列[芓段]
      在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系从而可以实现自我文档化。
      還有个替代办法就是改变 PERSON 记录来反映新头衔的变化不过这样一来在时间上无法跟踪个人所处位置的具体时间。
    • 采用常用实体命名机构数據
      组 织数据的最简单办法就是采用常用名字比如：PERSON、ORGANIZATION、ADDRESS 和 PHONE 等等。当你把这些常用的一般名字组合起来或者创建特定的相应副实体时你僦得到了自己用的特殊版本。开始的时候采用一般术语的主要原因在于所有的具体用户 都能对抽象事物具体化
    • 在设计用到网络或者具有其他国际特性的数据库员工表部门表时，一定要记住大多数国家都有不同的字段格式比如邮政编码等，有些国家比如新西兰就没有邮政编码一说。
    • 数据重复需要采用分立的数据表
      如果你发现自己在重复输入数据请创建新表和新的关系。
    • 对地址和电话采用多个字段
      描述街道地址就短短一行记录是不够的Address_Line1、Address_Line2 和 Address_Line3 可以提供更大的灵活性。还有电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别

      过分标准化可要小心，这样做可能会导致性能上出现问题虽然地址和电话表分离通常可以达到最佳状态，但是如果需要經常访问这类信息或许在其父表中存放“首选”信息（比如 Customer 等）更为妥当些。非标准化和加速访问之间的妥协是有一定意义的

    • 我觉得佷吃惊，许多人在数据库员工表部门表里就给 name 留一个字段我觉得只有刚入门的开发人员才会这么做，但实际上网上这种做法非常普遍峩建议应该把姓氏和名字当作两个字段来处理，然后在查询的时候再把他们组合起来

      我最常用的是在同一表中创建一个计算列[字段]，通過它可以自动地连接标准化后的字段这样数据变动的时候它也跟着变。不过这样做在采用建模软件时得很机灵才行。总之采用连接芓段的方式可以有效的隔离用户应用和开发人员界面。

    • 提防大小写混用的对象名和特殊字符
      过 去最令我恼火的事情之一就是数据库员工表蔀门表里有大小写混用的对象名比如 CustomerData。这一问题从 Access 到 Oracle 数据库员工表部门表都存在我不喜欢采用这种大小写混用的对象命名方法，结果還不得不手工修改名字想想看，这种数据库员工表部门表/应用程序能混到采用更强大数据库员工表部门表的那一天吗 采用全部大写而苴包含下划符的名字具有更好的可读性（CUSTOMER_DATA），绝对不要在对象名的字符之间留空格
    • 要 保证你的字段名没有和保留词、数据库员工表部门表系统或者常用访问方法冲突，比如最近我编写的一个 ODBC 连接程序里有个表，其中就用了 DESC 作为说明字段名后果可想而知！DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT * 语句倒是能用但我得到的却是一大堆毫无用处的信息。
    • 保持字段名和类型的一致性
      在命名字段并为其指定数据类 型的時候一定要保证一致性假如字段在某个表中叫做“agreement_number”，你就别在另一个表里把名字改成“ref1”假如数据类型在一 个表里是整数，那在另┅个表里可就别变成字符型了记住，你干完自己的活了其他人还要用你的数据库员工表部门表呢。
    • 在 SQL 中使用 smallint 和 tinyint 类型要特别小心比如，假如你想看看月销售总额你的总额字段类型是 smallint，那么如果总额超过了 $32,767 你就不能进行计算操作了。
    • 在表中包含一个“删除标记”字段这样就可以把行标记为删除。在关系数据库员工表部门表里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性
    • 觸发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰假如你确实需要采用触发器，你最好集中对它文档化
    • 建 议伱在数据库员工表部门表中引入版本控制机制来确定使用中的数据库员工表部门表的版本。无论如何你都要实现这一要求时间一长，用戶的需求总是会改变的最终可能会要求修改数据库员工表部门表 结构。虽然你可以通过检查新字段或者索引来确定数据库员工表部门表結构的版本但我发现把版本信息直接存放到数据库员工表部门表中不更为方便吗？
    • ID 类型的文本字段，比如客户 ID 或定单号等等都应该设置得比一般想象更大因为时间不长你多半就会因为要添加额外的字符而难堪不已。比方说假设你的客户 ID 为 10 位数长。那你应该把数据库員工表部门表表字段的长度设为 12 或者 13 个字符长这算浪费空间吗？是有一点但也没你想象的那么多：一个字段加长 3 个字符在有 1 百万条记錄，再加上一点索引的情况下才不过让整个数据库员工表部门表多占据 3MB 的空间但这额外占据的空间却无需将来重构整个数据库员工表部門表就可以实现数据库员工表部门表规模的增长了。身份证的号码从 15 位变成 18 位就是最好和最惨痛的例子

第 3 部分 - 选择键和索引

    • 我 所在的某┅客户部门一度要处理 8 万多份联系方式，同时填写每个客户的必要数据（这绝对不是小活）我从中还要确定出一组客户作为市场目标。當我从最开始设计表和字段的时候我试图不在主 索引里增加太多的字段以便加快数据库员工表部门表的运行速度。然后我意识到特定的組查询和信息采掘既不准确速度也不快结果只好在主索引中重建而且合并了数据字段。我 发现有一个指示计划相当关键——当我想创建系统类型查找时为什么要采用号码作为主索引字段呢我可以用传真号码进行检索，但是它几乎就象系统类型一样对我 来说并不重要采鼡后者作为主字段，数据库员工表部门表更新后重新索引和检索就快多了

      可操作数据仓库（ODS）和数据仓库（DW）这两种环境下的数 据索引昰有差别的。在 DW 环境下你要考虑销售部门是如何组织销售活动的。他们并不是数据库员工表部门表管理员但是他们确定表内的键信息。这里设计人员或者数据库员工表部门表工作人员应该分析数据库员工表部门表结构 从而确定出性能和正确输出之间的最佳条件

    • 这类同技巧 1，但我觉得有必要在这里重复提醒大家假如你总是在设计数据库员工表部门表的时候采用系统生成的键作为主键，那么你实际控制叻数据库员工表部门表的索引完整性这样，数据库员工表部门表和非人工机制就有效地控制了对存储数据中每一行的访问
      采用系统生荿键作为主键还有一个优点：当你拥有一致的键结构时，找到逻辑缺陷很容易
    • 为 了分离命名字段和包含字段以支持用户定义的报表，请栲虑分解其他字段（甚至主键）为其组成要素以便用户可以对其进行索引索引将加快 SQL 和报表生成器脚本的执行速度。比方说我通常在必须使用 SQL LIKE 表达式的情况下创建报表，因为 case number 字段无法分解为 year、serial number、case type 和 defendant code 等要素性能也会变坏。假如年度和类型字段可以分解为索引字段那么这些报表运行起来就会快多了
    • * 为关联字段创建外键。
      * 所有的键都必须唯一
      * 外键总是关联唯一的键字段。
    • 索 引是从数据库员工表部门表中獲取数据的最高效方式之一95% 的数据库员工表部门表性能问题都可以采用索引技术得到解决。作为一条规则我通常对逻辑主键使用唯一嘚成组索引，对系统键（作为存储过程）采用唯一的非成组索引对任 何外键列[字段]采用非成组索引。不过索引就象是盐，太多了菜就鹹了你得考虑数据库员工表部门表的空间有多大，表如何进行访问还有这些访问是否主要用作读写。

      大多数数据库员工表部门表都索引自动创建的主键字段但是可别忘了索引外键，它们也是经常使用的键比如运行查询显示主表和所有关联表的某条记录就用得上。还囿不要索引 memo/note 字段，不要索引大型字段（有很多字符）这样作会让索引占用太多的存储空间。

    • 不要为小型数据表设置任何键假如它们經常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间
    • 不要把社会保障号码（SSN）戓身份证号码（ID）选作键
      永 远都不要使用 SSN 或 ID 作为数据库员工表部门表的键。除了隐私原因以外须知政府越来越趋向于不准许把 SSN 或 ID 用作除收入相关以外的其他目的，SSN 或 ID 需要手工输入永远不要使用手工输入的键作为主键，因为一旦你输入错误你唯一能做的就是删除整个记錄然后从头开始。

      我在破解他人的程序时候我看到很多人把 SSN 或 ID 还曾被用做系列号，当然尽管这么做是非法的而且人们也都知道这是非法的，但他们已经习惯了后来，随着盗取身份犯罪案件的增加我现在的同行正痛苦地从一大摊子数据中把 SSN 或 ID 删除。

    • 在确定采用什么字段作为表的键的时候可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键这样做会迫使你采取以下两個措施：
      * 在创建记录之后对用户编辑字段的行为施加限制。假如你这么做了你可能会发现你的应用程序在商务需求突然发生变化，而用戶需要编辑那些不可编辑的字段时缺 乏足够的灵活性当用户在输入数据之后直到保存记录才发现系统出了问题他们该怎么想？删除重建假如记录不可重建是否让用户走开？
      * 提出一些检测和纠正键冲突的方法通常，费点精力也就搞定了但是从性能上来看这样做的代价僦比较大了。还有键的纠正可能会迫使你突破你的数据和商业/用户界面层之间的隔离。
      所以还是重提一句老话：你的设计要适应用户而鈈是让用户来适应你的设计

      不 让主键具有可更新性的原因是在关系模式下，主键实现了不同表之间的关联比如，Customer 表有一个主键 CustomerID而客戶的定单则存放在另一个表里。Order 表的主键可能是 OrderNo 或者 OrderNo、CustomerID 和日期的组合不管你选择哪种键设置，你都需要在 Order 表中存放 CustomerID 来保证你可以给下定單的用户找到其定单记录


      假如你在 Customer 表里修改了 CustomerID，那么你必须找出 Order 表中的所有相关记录对其进行修改否则，有些定单就会不属于任何客戶——数据库员工表部门表的完整性就算完蛋了
      如果索引完整性规则施加到表一级，那么在不编写大量代码和附加删除记录的情况下几乎不可能改变某一条记录的键和数据库员工表部门表内所有关联的记录而这一过程往往错误丛生所以应该尽量避免。
    • 可选键(候选键)有时鈳做主键
      记住查询数据的不是机器而是人。
      假如你有可选键你可能进一步把它用做主键。那样的话你就拥有了建立强大索引的能力。这样可以阻止使用数据库员工表部门表的人不得不连接数据库员工表部门表从而恰当的过滤数据在严格控制域表的数据库员工表部门表上，这种负载是比较醒目的如果可选键真正有用，那就是达到了主键的水准
      我的看法是，假如你有可选键比如国家表内的 state_code，你不偠在现有不能变动的唯一键上创建后续的键你要做的无非是创建毫无价值的数据。如你因为过度使用表的后续键[别名]建立这种表的关联操作负载真得需要考虑一下了。
    • 大多数数据库员工表部门表索引自动创建的主键字段但别忘了索引外键字段，它们在你想查询主表中嘚记录及其关联记录时每次都会用到还有，不要索引 memo/notes 字段而且不要索引大型文本字段（许多字符）这样做会让你的索引占据大量的数據库员工表部门表空间。

第 4 部分 - 保证数据的完整性

    • 用约束而非商务规则强制数据完整性
      如 果你按照商务规则来处理需求那么你应当检查商务层次/用户界面：如果商务规则以后发生变化，那么只需要进行更新即可假如需求源于维护数据完整性的需 要，那么在数据库员工表蔀门表层面上需要施加限制条件如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面 除非你的字段命名很冗长，否则字段名本身还不够

      只要有可能，请采用数据库员工表部门表系统实现数据的完整性这鈈但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。

    • 对 分布式系统而言在你决定是否在各个站點复制所有数据还是把数据保存在一个地方之前应该估计一下未来 5 年或者 10 年的数据量。当你把数据传送到其他站点的时候最好在数据库員工表部门表字段中设置一些标记。在目的站点收到你的数据之后更新你的标记为了进行这种数据传输，请写下 你自己的批处理或者调喥程序以特定时间间隔运行而不要让用户在每天的工作后传输数据本地拷贝你的维护数据，比如计算常数和利息率等设置版本号保证數据 在每个站点都完全一致。
    • 强制指示完整性(参照完整性?)
      没有好办法能在有害数据进入数据库员工表部门表之后消除它所以你应该在它進入数据库员工表部门表之前将其剔除。激活数据库员工表部门表系统的指示完整性特性这样可以保持数据的清洁而能迫使开发人员投叺更多的时间处理错误条件。
    • 如果两个实体之间存在多对一关系而且还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。
    • 为了在你的数据库员工表部门表和你的应用程序代码之间提供另一层抽象你可以为你的应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库员工表部门表變更时给你提供了更多的自由
    • 给数据保有和恢复制定计划
      考虑数据保有策略并包含在设计过程中，预先设计你的数据恢复过程采用可鉯发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数据源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以偅新处理更新
    • 用存储过程让系统做重活
      解决了许多麻烦来产生一个具有高度完整性的数据库员工表部门表解决方案之后，我决定封装一些关联表的功能组提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库员工表部门表不只是一个存放数据的地方它也是简化编码之地。
    • 控制数据完整性的最佳方式就是限制用户的选择只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性某些公共数据特别适合查找：国家代码、状态代码等。

第 5 部分 - 各種小技巧

    • 对所有的快捷方式、命名规范、限制和函数都要编制文档

      采用给表、列[字段]、触发器等加注释的数据库员工表部门表工具。是嘚这有点费事，但从长远来看这样做对开发、支持和跟踪修改非常有用。

      取 决于你使用的数据库员工表部门表系统可能有一些软件會给你一些供你很快上手的文档。你可能希望先开始在说然后获得越来越多的细节。或者你可能希望周期性的预排在 输入新数据同时隨着你的进展对每一部分细节化。不管你选择哪种方式总要对你的数据库员工表部门表文档化，或者在数据库员工表部门表自身的内部戓者单独建立文档这样，当你过了一 年多时间后再回过头来做第 2 个版本你犯错的机会将大大减少。

    • 使用常用英语（或者其他任何语言）而不要使用编码
      为 什么我们经常采用编码（比如 9935A 可能是‘青岛啤酒’的供应代码4XF788-Q 可能是帐目编码）？理由很多但是用户通常都用英語进行思考而不是编码。工作 5 年的会计或许知道 4XF788-Q 是什么东西但新来的可就不一定了。在创建下拉菜单、列表、报表时最好按照英语名排序假如你需要编码，那你可以在编码旁附上用户知道的英语
    • 让 一个表专门存放一般数据库员工表部门表信息非常有用。我常在这个表裏存放数据库员工表部门表当前版本、最近检查/修复（对 FoxPro）、关联设计文档的名称、客户等信息这样可以实现一种简单机制跟踪数据库員工表部门表，当客户抱怨他们的数据库员工表部门表没有达到希望的要求而与你联系时这样做 对非客户机/服务器环境特别有用。
    • 建立戓者修订数据库员工表部门表之后必须用用户新输入的数据测试数据字段。最重要的是让用户进行测试并且同用户一道保证你选择的數据类型满足商业要求。测试需要在把新数据库员工表部门表投入实际服务之前完成
    • 在开发期间检查数据库员工表部门表设计的常用技術是通过其所支持的应用程序原型检查数据库员工表部门表。换句话说针对每一种最终表达数据的原型应用，保证你检查了数据模型并苴查看如何取出数据
    • 对 复杂的 Microsoft Visual FoxPro 数据库员工表部门表应用程序而言，可以把所有的主表放在一个数据库员工表部门表容器文件里然后增加其他数据库员工表部门表表文件和装载同原有数据库员工表部门表有关的特殊文件。根据需要用这些文件连接到 主文件中的主表比如數据输入、数据索引、统计分析、向管理层或者政府部门提供报表以及各类只读查询等。这一措施简化了用户和组权限的分配而且有利於应 用程序函数（存储过程）的分组和划分，从而在程序必须修改的时候易于管理

　　1.哪个层次的管理人员更多的負责利用既定资源在规定日期内完成某一特定任务

　　2.衡量责任中心业绩的办法很多。衡量方法的恰当选择取决于被衡量部门的性质即它是成本中心、收入中心、利润中心还是投资中心。某部门是负责收入、成本和投资基数的投资中心只适合该中心的业绩衡量标准是：

　　3.某信息系统审计人员在对软件使用与许可进行复核过程中发现，大量电脑包含未经授权使用的软件以下哪一项是该审计人员应当艏先采取的措施：

　　A、采取个人行为删除所有未授权软件的副本

　　B、通知被审计方未授权软件的使用情况，并跟踪确认是否删除

　　C、向被审计方管理当局报告发现的未授权软件并明确指出必须禁止此类事件再次发生

　　D、不采取任何行动，因为这只是一种众所周知嘚行为而且经营当局负责监测该类软件的使用

　　4.生物测定系统能够实现以下程序：

　　A、衡量空气污染物

　　B、实地访问安全控制

　　C、监控温度和湿度水平

　　D、检测特定区域的危险电磁场

　　5.利用电脑软件发现审计线索的意义在于：

　　A、改善用户反应时间

　　B、確定交易处理的可计量性和责任划分

　　C、由于审计线索不占用磁盘空间，因此可以改善系统有效性

　　D、为希望进行交易追溯的审计人員提供有价值信息

　　6.利用审计软件对生产程序进行编码对比是为了测试程序的：

　　7.在当今的高技术环境中要想成功的激励团队项目經理应该采用哪种激励理论才能维持一个愉快的；高效率的团队？

　　A、期望理论与X理论

　　B、Y理论与马斯洛的需要层次理论

　　C、Y理论、期望理论与海兹伯格的卫生因素理论

　　D、期望理论与海兹伯格的保健理论

　　8.销售部门的经理在评估顾客服务组的工作好坏时下列准则中的哪一个是最有用的？

　　A、顾客永远是对的

　　B、顾客的投诉应该立即处理

　　C、与顾客打交道时雇员应保持积极的态度

　　D、对顾客的询问应在收到的七天内予以答复

　　9.某部门应用回归分析用月广告支出来预测月产品销售额（均以百万元为单位）。结果得到嘚回归系数为0.8试问该系数值的含义是什么？

　　A、所抽样本的月广告支出为80万美元

　　B、月广告支出为平均值时月产品销售额为80万美え

　　C、平均来说，每增加一美元广告费用销售额的增加为0.8美元

　　D、因为系数小，广告费用不是销售额良好预测指标

　　10.对于负责系統软件安装和维持的程序员缺乏充分监督会导致的最大风险是：

　　A、系统程序员可能没有全面理解应用系统用户需求

　　B、应用程序可能不适用

　　C、程序员所用系统实用程序可能有能力在不留下审计线索的前提下进行变动

　　D、硬盘和网络设施更有可能不足以应付生产笁作

　　11.出于增强对顾客需求敏感程度的竞争动机，现在许多公司把内部个人电脑网络通过大型主机与外部网络连起来这一做法的风險是：

　　A、病毒将进入公司的系统中

　　B、上装文件不能正确编译而无效

　　C、下装到个人电脑上的信息过时

　　D、个人电脑上的软件維修费用增加

　　12.为了适当地对优秀员工进行奖励，支付系统应考虑个人的

　　13.一个组织的决策层适合使用以下哪一种信息系统

　　C、高级经理支持系统

　　14.某利用电子数据交换系统工程（EDI） 的公司实行如下控制：追踪贸易伙伴对交易的确认，并对在一定期限内仍未得到確认的交易给出警告信息该项控制是为了防范什么风险？

　　A、不是从合法的贸易伙伴出发的交易信息可能会进入EDI网络

　　B、通过EDI系统姠贸易伙伴传输交易额信息有时会失败

　　C、交易双方可能会对该EDI交易能否形成合法有效的合同存在分歧

　　D、EDI系统的数据可能不能被EDI系統正确、完整地处理

　　15.下面是公司最近一个月生产活动的数据：

　　每磅产成品的直接人工标准为4小时

　　每小时工资标准为4.80美元

　　計划产量为15000磅

　　实际产量为15500磅

　　实际直接人工费用$75250（实际每磅产成品需要6.25小时）

　　公司当月的直接人工工资率差是：

　　A、$10不利差異

　　B、$240不利差异

　　C、$248不利差异

　　D、$250不利差异

　　16.在以业务活动量为基础的成本分配系统中以下哪一个是把材料的处理成本分配到巳生产的产品中的合理基础？

　　B、每个已完工的产品的组织部件数

　　C、生产单位产品所需的时间

　　D、单位产成品的制造费用

　　17.某公司对一些经常应用的数据进行了快照复制（snapshot copies）将它们放置在服务器上可以获取的文件中。经授权的用户可以将数据下载这种提供数據访问权的风险是：

　　A、数据复制品可能无法实现同步

　　B、零散数据可能缺乏完整性

　　C、数据交易的进行可能欠成熟

　　D、数据的時效性可能没有得到维护

　　18.以下哪项内容将为保证资金电汇过程中数据只送给经过授权的用户提供最强有力的控制？

　　A、要求接受方金融机构使用回拨系统

　　B、要求汇出方和接受方均有确定的代码

　　C、允许国际互联网协议在路由器安装表中重新引导命令

　　D、数据均加密传送以防止窃听

　　19.内部审计师可以通过确定哪一方面来评价管理当局的控制职能：

　　A、部门行动是否符合部门目标

　　B、管悝当局对于不同完成情况是否可以提供快速反馈

　　C、人员流动率趋势是否得以分析，对其不利影响是否进行调查

　　D、是否对预料的问題进行讨论明确签定，并且通过可能的解决方法进行评估

　　20.再决定经济订货批量时所用的方法是：

　　C、马尔可夫链分析

　　21.某分支機构的管理层对而且只对收入和成本负责该分支机构属于：

　　22.某电话公司由于信息系统（IS）的开发拖延超过两年，市场部提出自己承擔查询与报告系统的开发该系统可进入公司主机的相关数据库员工表部门表。系统运行一年多以来市场部对其目标市场内的需求与销售预测经常失误，造成公司的生产与实际销售总不相符高估时造成产品积压以至过时，低估时顾客不能得到满足只能到其它公司寻求服務与购买产品市场部把这归因于不能及时得到有关顾客、销售量、服务水平和产品维修记录方面的信息。

　　由于查询与报告系统的应鼡市场分析员业务量大为减轻，平常作一次分析（设计、书写和完成报告）仅需不到一个小时市场部经理对此很满意，但他发现较为複杂的分析报告总不精确请问这有可能是由于下列哪一方面的不足所引起的？

　　23.一个系统应有能力使其用户对所做的工作承担责任鉯下哪项控制的实施将最有助于达到这一控制目标？

　　24.某工程部门实施总体质量管理项目对于该部门，质量管理的重要因素不包括：

　　A、在已完成项目数量的基础上进行业绩评估

　　B、与其他工程部门相对照进行考核

　　C、在工程部门内部创设质量委员会

　　D、对业績进行项目后调查

　　25.某公司正对各责任中心进行评价方法是应用投资回报衡量业绩。中心经理可以采取行动提高投资回报，但这些荇动不包括：

　　26.某公司聘请外部咨询公司设计引进商业财务系统以取代现有的内部开发系统在对开发建议程序进行复核的过程中，以丅哪一项最为重要：

　　A、用户控制验收测试

　　B、质量规划不属于合同约定成果

　　C、最初的引进阶段并不包括所有功能

　　D、运用原型法确认系统是否满足经营需求

　　27.对于经常进行新产品开发的企来来说同时按产品和职能划分部门以及实施双重授权制是比较适宜的。在以下组织结构中最适合于该类型企业的是：

　　A、专业人士（官僚）式

　　D、技术人士（官僚）式

　　28.某生产经营家庭日常用品的夶型跨国公司，将财务汇总与报告系统从总部的大型主机系统移到带有文件服务的局部网络（LANS）大型主机系统每月能处理20万宗交易，但進行批处理则较困难且耗机时，而且由于软、硬件的不可兼容总部主机与子公司之间（尤其是与国外子公司之间）设有自动连接设备。

　　系统转换的目的是：

　　1.将月底结帐时间从10个工作日减少到5个

　　2.利用较少资源来完成财务汇总与报告

　　3.将各子公司的会计资料彙总登记总分类帐并编制合并会计图表

　　4.对财务报告进行管理以便及时形成并及时传送财务报告、报表

　　5.允许各子公司制定自己的报表

　　6.进行自动货币兑换

　　7.减少各子公司间信息交换的费用

　　仔细检查了6个供应商的合并财务报告软件之后公司选择了表格结构财務报表软件而不是通用财务报表软件。虽然开始阶段通用财务软件看起来较熟悉但表格结构财务软件能够合并不同行业子公司的帐目。洏且表格财务软件更易于各子公司自编制独立于总部的补充性表格

　　a.相关系统 b.工作站存储；

　　c.大型系统 d.软件配置；

　　e.光导纤维导線； f.变动控制程序；

　　g.书面文件资料； h.服务模块；

　　i.触发过程； j.点访问；

　　k.局部网（LAN）服务； l.终端仿真。

　　开发小组先前没有考慮到操作员需要同时运行多个应用程序多个应用程序的连续运作意味着操作员一种新的工作方式，这在先前的大型主机系统是无法实现嘚使这个同时运行多种应用程序的工作方式可行的最可能方式是通过：

　　29.两位经理在讨论为提高雇员工作业绩而设立目标的利弊，一位认为无须确立具体目标只需确立总体目标，以便保持灵活性；一位认为只有确立具体目标才能达到好的效果随着讨论的继续，他们叒得出了其他一些确立目标的方法在以下方法中，最好的是：

　　A、经理应确定总体目标

　　B、经理应确定具体目标

　　C、雇员应制定總体目标并取得管理部门的同意

　　D、雇员应制定具体目标，并取得管理部门的同意

　　30.生产率定义为生产过程的产出与投入之比

　　假定某生产过程现在每天用500工时生产2000单位的产品。如设计为每天用600工时生产2520单位的产品则生产率提高：

　　31.某食品公司的5名品牌经理萣期开会确定被竞争对手压低的价位内容以及配赠促销的进展情形。他们需要分析每月从各零售连锁店发来的50千兆字节的日销售点 （POS）品牌经理均能熟练应用微机上的电子数据表和数据库员工表部门表软件。他们考虑选用其他几个替代性软件来接收与处理数据以解答相关問题

　　某经理怀疑某些商店的销售点数据有错，因其许多产品的波动较大而其它店却相当稳定验证这些产品的POS数据正确性的最佳方法是比较：

　　A、同等规模商店的销售量

　　B、销售量与已运送产品量

　　C、连续几年的销售量

　　D、同时期相似产品的销售量

　　32.弹性預算是什么计划的量化表现？

　　A、根据预算标准与实际水平而编制的计划

　　B、包括预算收入和预算支出的计划

　　C、强调生产、销售、售后服务成本的计划

　　D、预测在将来对现有做法程序有所改变的计划

　　33.以顾客为中心倡导革新，更新观念勇于进取，提供广泛哆样的人员培训都是企业改革的基本要素。确立这些要素主要是为了：

　　A、学飞优秀企业的先进经验，以便更好地与之竞争

　　B、致力于产品和服务的全面质量管理

　　C、同时兼顾经营的效率性和效果性从而间接地提高利润

　　D、加强产品和服务的成本管理，力求降低成本

　　34.由于设备故障和维修会引起产生延误限制着一延误的方式是：

　　A、给予生产能力安排生产

　　B、基于设备修理情况对维護活动作出计划

　　C、事先批准设备维护和加时费

　　D、对所有生产设备建立预防性维护计划

　　35.经理发现给予下属的只是未被采纳，检查原因是发现自己在发出指示时曾被几个电话打断在沟通的术语中，这种打断是：

　　36.当一个组织的人员不断增加组织结构也随之变嘚越复杂，规章制度也就越规范为指导不断增加的下属人员而雇用的督导人员也越多。请问组织大小与结构的关系是：

　　B、一旦人员超过二百人结构就固定不变

　　C、开口向上的抛物线关系

　　37.某制造公司使用分步成本系统公司的产品经过部门1和2加工成产成品。在部門2的整个制造过程中加工成本均匀发生当加工程度达80%时，所加入的直接材料-防腐剂并不改变产品的体积。最终检测程序发现有否废品並确认相关成本本月实物流动状况下：

　　期初部门2的在产品 14000（已达加工成本的90%）

　　期末部门2在产品 8500（已达加工成本的60%）

　　如果公司使用加权平均法，部门2本月直接材料的约当产量为：

　　38.在下面那种组织结构中全面质量管理最有效？

　　B、相同专业人员组成的工莋团队

　　C、不同专业人员组成的工作团队

　　39.两公司之间有关事故恢复系统签订互惠处理程序协议可能带来的最大风险是：

　　A、系统開发有可能导致硬件与软件不兼容

　　B、无法在需要的时刻获取必要的资源

　　C、无法对事故恢复系统加以测试

　　D、不同公司的基础安铨设施不同

　　40.以下哪项技术支持程序员与终端电脑操作员之间的互动程序编码与汇编：

　　41.负责应用程序维护审计的信息系统审计人员對手写程序变动记录日志进行复核的目的是为了确认：

　　A、授权程序变动的次数

　　B、现有目标模型的创建日期

　　C、实际程序变动的佽数

　　D、现有源程序的创建日期

　　42.信息系统审计人员正在对涉及支付计算的生产系统模型的一项重大修订过程的测试结果进行评估審计人员发现50%的计算结果与预先设定的结果不符。以下哪一措施是最可能接着实施的审计步骤：

　　A、针对计算结果出错的项目设计进一步测试

　　B、确认其他导致测试结果不符的因素

　　C、进一步核查计算出错项目以确认结论

　　D、记录结论撰写有关检查结果、结论及建议报告

　　43.某公司面临扩大工厂的生产能力以跟上快速增长的决策。几个不同的未来的产品需求预测和三个不同的扩展计划以及每一個计划又有几个地址的选择，使决策更加复杂化用于分析这种情形的有用工具是：

　　44.审计业务中的磋商方法强调：

　　A、矫正性措施嘚强制执行

　　B、与被审单位共同研究改进方法

　　D、政策和程序的执行

　　45.下面哪种方法不合适的时间序列预测方法

　　46.对于销售商而訁，在以下哪一项产品组织定价战略中其接受任何超过产品存储和运输成本的价格就是适当的？

　　47.某部门运用回归分析法根据每月廣告支出来预测每月产品销售额（均用百万美元作单位）。结果表明该自变量的回归系数等于0.8.该系数说明：

　　A、在本例中平均每月广告支出为$800，000

　　B、当每月广告支出处于平均水平时产品销售将是$800，000

　　C、一般而言每增加$1广告支出，销售额就会增加$0.8

　　D、由于回归系数太小因此广告支出不是销售额的预测因子

　　48.以下哪种组织结构最适合应用全面质量管理？

　　B、相同专业人员组成的组织结构

　　C、不同专业人员组织的组织结构

　　D、专家独立工作的组织结构

　　49.与电子基金转帐（EFT）系统相比手工处理系统的哪种风险更大：

　　A、快照（为配置对数据库员工表部门表进行复制）

　　B、复制（在多个存储单元上产生和保持重复拷贝）

　　C、标准化（为让用户更方便处理将数据库员工表部门表分成多个逻辑表）

　　D、分段存储（将数据库员工表部门表分成多个部份，并在需要的地方进行配置）

　　50.鉯下关于电子邮件安全性的各项陈述哪一项是正确的？

　　1.电子邮件的安全性不会比其所在的计算机系统的安全性更高

　　2.机密的电孓邮件信息应以电子邮件形式保存在邮件服务器中，保存期限等同于纸性文档的保存期限

　　3.在大型的企业，往往根据不同的密级设置幾个电子邮件管理员和信箱

　　51.某经理拟组建一个工作小组。为了使这个小组能长期高效地运作该经理采取以下哪一项措施最有效？

　　A、委派一名出色的管理人员作为小组的总负责人指导小组制定工作目标以及进行人员分工，以便提高小组的工作效率

　　B、选择有楿似资历、背景的人员作为小组成员以便使他们更好地相处与合作

　　C、充分放权，让小组自选制定其自身的目标

　　D、给小组制定明確的目标并给予充分的时间使小组工作从起步逐步过度到完善

　　52.嵌入审计模块可：

　　A、识别不能执行的计算机码

　　B、有助于应用系统的调试

　　C、分析程序的效率

　　D、能对交易过程进行连续的监控

　　53.某种使用加权平均方法对下期数据进行预测，这种预测的依据昰使实际数据和预测数据之间的误差最小这种预测方法称为：

　　54.在经常停电情形下最有可能维持电脑系运作的更新措施是安装：

　　C、不间断电源（USP）

　　55.关于组织中的矩阵结构，以下哪种说法是不正确的

　　A、可以减少公司结构混乱而导致的权力斗争

　　B、有助于應用高水平的专业技术人员参与项目

　　C、有助于在大规模的组织中实现信息的分享

　　D、有助于组织发挥规模经济

　　56.两个经理正在讨論为提高员工工作质量而设定的绩效目标。一个经理认为不应该制定具体的目标而应制定灵活综合性目标；另一个认为明确的、较难实現的目标会产生最好的结果。因为讨论仍在继续所以必须考虑其他制定目标的方法。选择制定目标的最好方法：

　　A、经理应该抽出综匼性目标

　　C、员工应该采用综合性目标

　　D、员工应该采用明确的、较难实现的目标并获得管理认同

　　57.一个大型企业正考虑实施重大嘚组织变革谁在实施该变革中无须承担责任：

　　58.某公司生产和销售100，000件单位变动成本是$20的部件其中，1200件超过了公司允许的误差标准，发生返工成本每个$12.返工部件以$45售出正品的售价是$50.如果公司实施质量保证程序，确保所有部件都符合标准公司从这些部件中产生的邊际贡献应当至少增加

　　59.某制造公司有几个相互独立的分公司，这些分公司不但与外部竞争而且相互之间也展开竞争。公司总裁希望各分公司经理努力使公司和其分公司的绩效达到最大在这种情况下，若进行内部交易交易价格为：

　　B、全部生产成本+加成

　　C、变動成本+加成

　　D、产品的市场价格

　　60.非正常损耗是

　　A、在使用标准成本时不会发生的

　　B、一般不受生产主管的控制

　　C、不现实的苼产标准的结果

　　D、在高效运营情况下是不会发生的

　　61.当连接两个或更多的电子邮件系统时，下列哪一项是主要的安全问题

　　A、鈈能对网关间传输的消息加密

　　B、丢失消息中的关键文本

　　C、信息接收者不能自动告知信息发送者信息已经收到

　　D、不能保存信息嘚备份

　　62.在收入法下，国内生产总值（GDP）等于

　　A、折旧和间接经营税收+工资+房租+利息+对境外净收入调整后的利润

　　B、工资+房租+利息+利润

　　C、折旧和间接经营税收+工资+房租—利息+利润

　　D、工资+房租+利息—对境外净收入调整后的利润

　　63.某人每年的收入是$23000，所得税昰$8000.现在，其每年收入达到$30000，要缴纳$10000所得税。那么适用于此人的个人所得税是

　　64.依靠反病毒软件的主要风险是反病毒软件

　　A、鈈能检测出某些病毒

　　B、使软件的安装变得过于复杂

　　C、干扰系统的正常操作

　　D、耗费太多的系统资源

　　65.在现今的ERP系统中，其客戶/服务器的可能特征是什么

　　I、瘦客户机，局域网单服务器。

　　II、胖客户机广域网，多服务器

　　III、胖客户机，经由因特网連接单服务器。

　　66.为了获取客户数据操作系统从-个包含键值及对应物理地址的文件中找到主键，

　　在这种情况下最有可能的客戶数据组织形式是

　　67.那些没有变成产成品、同时经济价值很小的投人材料被划分为

　　68.当所有特征都相同时，下列哪类特征的企业对外融资的要求最低

　　A、较低的盈利留存率

　　B、较高的销售增长率

　　C、较低的资本密集度

　　69.适合这种疽用的最佳网络是

　　A、局域網（LAN）

　　B、广域网（WAN）

　　C、增值网络（VAN）

　　D、专用分组交换机（PBX）

　　70.时间系列预测模式可以包括以下哪些内容？

　　（2）季节性變动；

　　A、只有（1）是对的

　　B、只有（1）和（2）是对的

　　C、只有（2）和（3）是对的

　　D、（1）、（2）、（3）都对

　　71.某食品公司的5洺品牌经理定期开会确定被竞争对手压低的价位内容以及配赠促销的进展情形他们需要分析每月从各零售连锁店发来的50千兆字节的日销售点 （POS）。品牌经理均能熟练应用微机上的电子数据表和数据库员工表部门表软件他们考虑选用其他几个替代性软件来接收与处理数据鉯解答相关问题。

　　可选软件不可能采用分层数据库员工表部门表系统因为：

　　A、该软件需要多个连接

　　B、程序质询太耗成本和時间

　　C、销售点数据对程接口太敏感

　　D、销售点数据的汇总解决不了问题

　　72.某大型财产保险公司设有多处地区性中心供顾客打电话來索取赔偿。虽然中心并不处于事故易发区公司仍需有灾害恢复计划，以便在灾害发生或扩大时能够及时回应顾客要求最好的办法就昰将顾客的电话转发至：

　　A、拥有双重设施的冷门地点

　　B、拥有双重设施的热门地点

　　C、第三者的服务中心

　　D、不受灾害影响的哋区性中心

　　73.下面哪个例子属于或有负债？

　　A、零售店向大卖场支付少量的或最小的月租金并按销售额的一定比例缴纳其余租金

　　B、公司拒绝支付年度审计费用，因为公司认为这一数额比与事务所合伙人协议的价格要高

　　C、公司在中期年报应计应付所得税

　　D、租凭合同要求承租方补足相对于租凭期内资产残值的差值

　　74.任何关于库存评价的风险模型一定包括以下哪一项

　　A、产品质量保证书

　　75.假如债券折价出售，折价摊稍采用实际利率法那么利息费用

　　C、等于现金利息支付

　　D、每期将小于现金利息支付

　　76.风险资产嘚回报率和无风险资产的期望回报率之间的差额是

　　77.假如公司使用先进先出法（FIFO）来计算存货，那么存货的期末价值是

　　2004年CIA考试模拟題

　　在1月1号公司没有期初存货，当年的采购业务如下

　　在12月还剩下10000个存货

　　78.当比较两家公司时，如果其他情况都一样公司有較高的红利支付率意味着着

　　A、高的资本成本率

　　C、较高投资机会的考虑

　　D、较高的价格/盈余

　　79.以下哪项是制造业的一种产品成夲？

　　A、公司总部建筑物的保障费

　　C、销售工人的车辆折旧

　　D、销售经理的薪水

　　80.假设其他条件都不变不销售增长率增长时，高利润率的公司需要较少的融资；如果利润率再增加的话图中所表示的融资需求线将如何变化？

　　A、向上变化且变得较平缓

　　B、向仩变化且变得更陡

　　C、向下变化且变得较平缓

　　D、向下变化且变得更陡

　　81.下哪项管理方法将注意力集中在需要注意的领域而对那些與预期一致的领域给予较少的关注

　　82.当下列那个因素提高时企业的经济价值（市值）会提高？

　　83.融资需求线不会通过原点除非公司有：

　　A、利润全部用于现金分红支出的红利政策

　　B、利润都不用于现金分红支出的红利政策

　　C、100%的销售增长率

　　D、0%的销售增长率

　　A、两个机构之间直接的业务交易电脑间交换

　　B、在机构管理层设置的能混合数据并拥有复杂分析模块以支持半结构化和末结构化決策的电脑系统

　　C、对数据进行管理的技术和操作方面，包括数据库员工表部门表的实际设计和操作

　　D、旨在通过一些决策者集中共哃努力解决未结构化问题的人机对话电脑系统

　　85.在监督公司对金融衍生工具的投资情况时，可以应用的最佳监督控制是以下哪项内容

　　A、管理层审批所有与投资金融衍生工具有关的政策

　　B、所有超过一定金额的投资都必须得到公司金融部副主任的批准

　　C、财务主管向董事会提交季度报告，详细说明金融投资的损益并概述公司目前的投资状况

　　D、管理层每周收到关于公司金融衍生工具投资损益及公司目前的投资状况

　　86.以下哪项不是典型的输出控制

　　A、审查计算机处理记录，以确定所有正确的计算机作业都得到正确执行

　　B、将输入数据与主文件上的信息进行匹配并将不对应的项目放入暂记文件中

　　C、定期对照输出报告，以确认有关总额格式和关键細节的正确性及其与输入信息的一致性

　　D、通过正式的程序和文件指明输出报告，支票或其他关键文件的合法接收者

　　87.某因特网站的莋用是根据查询台的要求给顾客提供信息为该网站提供安全的最为有效的方式是什么？

　　A、根据数据的敏感度实施多层次口令

　　B、應用充分的存取控制制止未经授权的数据变化

　　C、要求对访问该网站的用户进行生物统计身份确定

　　D、不再进一步添加安全控制，洇为没有涉及业主数据

　　88.应用计算机辅助软件工程技术的一大好处是它可以保证

　　A、文件中不会出现过期的数据区域

　　B、用户坚定哋使用新系统

　　C、所有程序的效率得到优化

　　D、数据一致性规则得到连贯应用

　　89.一家公司近来购买了竞争者一部分股票从长期来看该公司条算收购竞争者，然而近来该股票的市价不断下跌，该公司可以通过如下哪种方式规避市价下跌的风险

　　A、购买该股票的買权

　　B、购买该股票的卖权

　　C、出售该股票的卖权

　　D、得到该股票的认股权

　　90.要阅览互联网具储存的一份超文本文件，以下那项能提供最佳工具

　　A、互联网搜索引擎

　　C、远程通讯网对话

　　91.好的计划可以帮助组织在中断运作之后恢复计算机工作，良好的修复計划可以确保：

　　A、工作流程已经设置了备用或重新启动的程序

　　B、变动控制程序不会被操作人员遗漏

　　C、计划设备工作能力的变動与设计好的工作量相容

　　D、与应用程序所有者达成服务程度书面协议

　　92.项目B的内部回报率大约是

　　93.以下哪种说法最好地描述了全媔质量管理的重点

　　B、实施更好的统计质量控制技术

　　C、每项工作都一次作对

　　D、鼓励开展跨部门的团队工作

　　94.某公司的专业銷售人员可能滥用手机，导致公司电话费增幅惊人以下哪项控制最不可能制止这种滥用现象？

　　A、为管理层编制定期报告说明每名專业销售人员所打电话的种类、通话时间和通话次数，并附上相关的总额和比较数字

　　B、要求专业销售人员先自己支付每月的手机费嘫后通过费用报告程序申请报销与业务有关的手机费

　　C、要求销售管理人员在支付手机费之前先对每月电话单进行审批，解释实际手机費与预算的差额并对本月增加的手机费金额进行解释

　　D、规定必须经过公司的电信部门经理授权才能支付手机费

　　95.假如公司使作用後进先出法（LIFO）来计算存货，那么当年的销货成本是：

　　96.在战略规划中关于横向联合的哪种说法是正确的？

　　A、只有多样化的公司財需要进行横向联合

　　B、横向联合增加了公司目标得到了实现的机会

　　C、只有在使命陈述发生变化时才需要进行横向联合

　　D、只有茬同时实现纵向联合时才能实现横向联合

　　97.为减少长期管理费用一个组织想通过提前退休来削减工人总数。减少工人总数的最佳方案昰：

　　A、为满足一定退休条件的工人提供金钱激励

　　B、如果高级雇员不自愿退休就以解雇威胁他们

　　C、为个人提供怎样对待退休囷新的工作培训的咨询服务

　　D、与组织中的工会谈判

　　98.领导、管理层、外部审计师以及内部审计师在创建适当的控制过程中起着重要莋用。高层管理者的首要职责是：

　　A、建立和保持组织文化

　　B、审核财务和经营信息的可靠性和完整性

　　C、确保外部审计师和内部審计师监督风险管理和控制过程系统的管理

　　D、实施和监督由董事会设计的控制

　　99.进行计算机集成制造（CIM）投资的一个主要原因是：

　　A、降低废品成本、返修成本及废料成本

　　B、减少工厂设备的账面价值的折旧费

　　100.组织结构通常服从于整体战略一个极端是结构松散的有机式组织，另一个极端是高度集权的严格控制的机械型组织某公司是激光和机器人技术两者的领先者，公司的科研和工程人员擁有很多专利他们在引进新产品的同时，也持续地寻求各种方式来改进现有产品最适合该公司的结构类型是：

　　101.某制造公司生产两種主要产品并通过一道附加工序生产一种联产品。主产品1可立即销售而主产品2在销售前尚需另行加工。公司使用预计可实现销售额来分配附加工序的费用联产品的实际净销售额用来冲销联产品成本。本月资料如下：

　　（1）联产品成本$75000（为本月生产产品而发生）

　　（2）副产品销售费用为$0.05／加仑

　　（3）副产品销售价格为$0.55／加仑；在上一问题中所用的有关联产品分配的会计方法中，联产品价值在总分類账中的确

　　（4） 副产品产量为10000加仑

　　（5） 主产品1的净可实现销售额为$80，000

　　（6） 主产品2的净可实现销售额为$320000本月分摊主产品1的聯产品成本为

　　102.从以下四个选项中选择一组，要求它们是分配公司资源的决策支持系统的系统计划和开发的组成部分

　　A、物理系统設计和变化分析

　　B、程序开发和复杂限制

　　C、可行性评估和远程信息处理设计

　　D、信息需求分析和数据库员工表部门表设计

　　103.当┅个应用软件被生成，并且广泛在一个大型组织中使用的时候信息系统部门与组织内其他部门的主要联系人是：

　　B、应用软件程序师

　　104.能对源程序进行语法检查，并将其翻译成目标代码的程序是：

　　105.以下哪种操作程序增加了—个组织感染计算机病毒的可能性：

　　A、对数据文件加密

　　B、对文件经常备份

　　C、从互联网上下载软件

　　D、在硬盘上安装软件的原装拷贝

　　106.在组建小组调查公司是否可能采纳作业成本制时在小组中包括一名内部审计师的最佳理由是审计师拥有以下哪方面知识？

　　A、作业与成本驱动因素

　　C、现行产品成本结构

　　D、内部控制的不同选择

　　107.某公司股东代表对管理层所管理的内容进行监督以下哪项内容是对这种监督程序的最佳描述？

　　108.根据以下资料回答：某公司以每单位$40的价格销售其惟一的产品在其生产计划中采用本量利分析。公司上年度税后净利润为 $1188，000適用税率为40％，下一年度产品制造与销售的成本费用如下：单位变动成本：直接材料成本$5.00/直接人工成本$4.00制造费用$6.00销售与管理费用$3.00/单位成夲总计$18.00；年固定运营费用：制造费用 $6，200000；销售与管理费用 $3，700000；年固定成本总计 $9，900000；公司已了解到使用一种新型材料可以提高产品的質量。使用新型材料将使单位产品直接材料成本增加$3公司将把产品单价提高至 $50，同时增加$1575，000的广告宣传费如果公司要获得10％的税前銷售利润率，则需卖出多少单位的产品

　　109.运用以下资料回答问题：公司当年运营情况的有关数据如下：销售收入：（150，000个）$9000，000；变動成本：直接材料 $1800，000 直接人工 $720000 制造费用 $1，080000 销售费用 $450，000固定成本：制造费用 $600000 管理费用 $567，840 销售费用 $352800 所得税率 40%.公司估计下一年度直接材料成本将上升10％，直接人工成本将每个上升0.60元达到每个5.40元，固定销售费用将上升29520元。所有其他成本将保持与本年同样的比例或金额公司需要多大的销售额才能使2000年的净利润与1999年持平？

　　110.马斯洛需要理论的顶点被称为（）

　　111.内部审计部门可以连续参加系统开发茬各开发阶段结束时参加系统，在系统实施时参加系统或根本不参加系统开发相对于其他两种参加方式，内审部门连续参加的好处是

　　A、审计参与的成本可以降到最低程度

　　B、存在可以发表审计意见的明确时间点

　　C、重新设计成本可以降到最低程度

　　D、缺乏审计獨立性的威胁可以降到最低程度

　　112.以下那种数据加密标准实施过程最为简单

　　A、电子密码锁定ECB

　　B、密码锁定序列CBC

　　C、密码反馈CFB

　　D、结果反馈OFB

　　113.某公司的经营管理层希望降低单位可变成本，为此他们应该从以下那个领域开始工作最有可能获得成功？

　　114.某机構的年度需求是25000个单位其经济定货数量已被正确计算为400个单位，安全存货是50各单位定货间隔为5天。假设一年有250个工作日那么重新定貨点应该是：

　　115.防止非法利用数据文件的最有效控制措施是（）

　　116.以下哪项技术最适合评价成本中心的业绩表现：

　　117.一个电子公司想通过使用应用软件快速开发技术来实施新的系统。以下哪项应该包括在新系统的开发过程中：

　　A、在最终模块完成之前拖延系统文件的准备

　　B、从系统开发团队中去掉项目管理的责任

　　C、一个模块一个模块地逐渐进行系统开发，直到系统开发的完成

　　D、使用对潒开发技术减少对以前编码的使用

　　118.为强化安全意识撰写的安全政策不包括以下那一项

　　A、电脑软硬件索引

　　B、管理层支持政策實施的首肯

　　C、访问电脑信息的认证过程

　　D、基于需求满足的安全保障意识哲学

　　119.标准化审计软件协助审计人员从事以下那项活动

　　A、对应用程序执行过程加以监控

　　B、针对所有真实和虚拟实体的主控文件实施数据测试

　　C、对文件数据实施抽样并核查计算过程

　　D、在常规应用程序中加入特定审计程序

　　120.图像处理系统能够减少组织内纸张的使用量。为了减小错误地使用其它图像的可能性管悝部门采取适当的控制，以保证：

　　A、图像数据的易读性

　　B、图像数据的可访问性

　　C、索引数据的完整性

　　D、索引数据的最初的連续性

　　121.采用以下哪种方法可以防止对在线记录进行未经授权的修改

　　B、计算机连续性检查

　　C、计算机匹配检查

　　D、数据库员笁表部门表访问控制

　　122.为了从时间序列数据中消除季节差异的影响，原始数据应该：

　　A、增加增加的幅度为季节因子

　　B、减少，減少的幅度为季节因子

　　123.由于设备故障和维修会引起生产延误限制这一延误的方式是：

　　A、基于生产能力安排生产

　　B、基于对设備修理订单的分析，对维护活动做出计划

　　C、事先批准设备维护和加班费

　　D、对所有生产设备建立预防性维护计划

　　124.最有可能保证呮按批准的金额开具职工工资支票的控制措施是：

　　A、对工资单上的职工名册进行周期性的核对

　　B、要求将未交付的支票交还给出纳員

　　C、要求监督部门核准出勤时间卡

　　D、定期现场观察工资支票的发放

　　125.全面质量管理中团队的使用是重要的这是因为：

　　A、管理良好的团队可能具有高的创造性，与个体相比能够更好地处理复杂问题

　　B、团队易于做出决策，因此有助于缩短决策周期

　　C、團队成员的激励比个体要高

　　D、团队的使用消除了监督的必要因此允许公司日益精益和增加盈利能力

我要回帖

更多关于 数据库员工表部门表 的文章

 

随机推荐