5.2 电子商务系统设计的基本过程
电子商务系统设计工作通常由系统架构师/系统分析员（SA）与程序员一起完成。电子商务系统设计的内容主要包括5方面，即电子商务系统总体架构设计、软件模块结构设计、软件业务编码设计、数据库设计以及软件之I/O界面设计。
5.2.1 电子商务系统总体架构设计
电子商务系统总体架构设计主要任务包括：系统总体布局设计、系统计算模式设计、硬件配置设计和软件平台设计。
1. 系统总体布局设计
在进行系统总体布局设计时除了要明确是集中式还是分布式系统，还要考虑系统用户的地理分布、用户的业务处理方式、数据存储方式、硬件配置及软件配置。
从信息资源管理的集中程度来看电子商务系统体系结构主要有：集中式系统（Centralized Systems）和分布式系统（Distributed Systems），从信息处理的方式来看主要有：批处理方式（Batch processing）和联机处理方式（On-line Processing）.
电子商务系统的总体布局按照应用程序与数据资源的集中程度划分，可将其分为集中式系统(Centralized Systems) 和分布式系统(Distributed Systems)两种。信息资源在空间上集中配置的系统称为集中式系统；利用计算机网络把分布在不同地点的计算机硬件、软件、数据等信息资源联系在一起服务于一个共同的目标而实现相互通信和资源共享，就形成了管理电子商务系统的分布式结构，具有分布结构的系统称为分布式系统。集中式系统可以使信息资源集中，管理方便，规范统一；专业人员集中使用，有利于发挥他们的作用，便于组织人员培训和提高工作；信息资源利用率高；系统安全措施实施方便。但是随着系统规模的扩大和功能的提高，集中式系统的复杂性迅速增长，给管理、维护带来困难；对组织变革和技术发展的适应性差，应变能力弱；不利于发挥用户在系统开发、维护、管理方面的积极性与主动精神；系统比较脆弱，主机出现故障时可能使整个系统停止工作。
电子商务系统的总体布局按照信息处理方式可分为批处理方式（Batch processing）和联机处理方式（Online Processing）。批处理是线下的、非实时交易，就是按规定的顺序自动执行若干个指定的计算机指令或程序，即是把原来一个一个执行的命令汇总起来，成批的执行。联机处理方式主要分为联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）；OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易；OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。
2. 系统计算模式设计
在进行计算模式设计的时候要明确是B/S还是C/S计算模式，具体对比如图 5.1 所示：
图 5.1: 计算模式对比
3. 电子商务系统硬件配置设计
硬件配置设计的时候要考虑电子商务系统硬件配置清单，下面是需考虑的几点：
①服务器端主机的选择（服务器的CPU、内存最低容量，服务器集群方式）
②客户端主机的选择（PC机的CPU、内存、硬盘最低容量）
③联机存储设备的选择（服务器磁盘阵列容量）
④脱机备份设备的选择（磁带机、磁带库容量）
4. 电子商务系统软件配置设计
在软件平台设计时候要考虑电子商务系统软件配置清单，包括系统软件和应用软件的选择。
系统软件的选择：
- 服务器和客户端操作系统的选择（服务器端windows server、Linux等）
- 数据库的选择（Oracle、DB2 、SQLserver、MYSQL等）
- 中间件的选择（视软件架构及开发方式而定）
应用软件的选择：
- 外购成型软件选择（视业务需求的复杂程度及企业的人力及财力状况）
- 软件开发工具的选择（代码编写工具：C、C++、JAVA、Python等）
5.2.2 软件模块结构设计
软件模块结构设计又称系统结构设计，核心任务是完成电子商务系统中软件模块结构设计，即将系统划分为若干个子系统，再将子系统分解成功能单一、彼此相对独立的模块，形成具有层次关系的模块结构，确定系统模块的组成、模块的功能和模块间的相互关系。通常采用结构化设计方法（Structured Design），即“自上而下，逐步求精”。设计工作主要包括模块结构图、从数据流程图向模块结构图的转换及系统结构的完善与优化。
1. 软件模块的基本构成
软件模块是将一个系统分解成若干彼此独立，且又具有一定联系，能够完成某项特定任务的组成部分。这些组成部分就称为功能模块，简称模块。
模块（module）又称组件（component），一般具有如下三个基本属性：功能属性（描述该模块实现什么功能），逻辑属性（描述模块内部功能怎么实现），状态属性（描述该模块使用时的环境和条件）。一个模块的规模可大可小。它可以是一个程序，也可以是程序中的一个程序段或一个函数、过程或子程序。模块是模块结构图中最基本、最主要的元素；作为系统文档的一部分，模块结构图清楚地反映出系统中模块之间的层次调用关系和数据交换关系。模块结构图的基本符号如图 5.2 示意：
图 5.2: 模块结构图
模块间的信息传递过程是当一个模块调用另一个模块时，调用模块把数据或控制信号传送给被调用模块，以使被调用模块能够运行。在模块的箭头尾部标以一个菱形符号，表示模块有条件地调用另一个模块。当一个在调用箭头尾部标以一个弧形符号，表示模块循环调用另一个模块。图 5.3 描绘了模块调用及通信关系：
图 5.3: 模块调用及通信关系
2. 软件模块的特性
模块的耦合度：模块之间相互联系的紧密程度，又称模块联结。
模块的聚合度：模块内各个组成部分之间的凝聚程度，表示模块功能的专一化程度。
模块的独立性越低就越不易维护，其独立性一般用耦合度与聚合度来衡量；模块独立性比较强的模块应是高内聚低耦合的模块。
模块耦合度和聚合度类别如图 5.4 所示：
图 5.4: 模块耦合度和聚合度类别
5.2.3 软件编码设计
编码是指代表事物名称、属性和状态等的符号，即给特定实例一个唯一的标识或编号。一般用数字、字母或它们的组合表示编码。编码类型有数字型、字母型、混合型。编码具有鉴别功能，可以提高信息处理效率，也是人机交互工具，并且有专用含义。
编码分为顺序码、系列顺序码、区间码和助记码。顺序码代码简短，使用方便，易于管理，易添加，对分类对象无任何特殊规定；缺点是代码本身没有给出对象的任何其他信息。系列顺序码是一种特殊的顺序码，它将顺序码分为若干段并与分类对象的分段一一对应，给每段分类对象赋给一定的顺序代码。区间码是将分类对象按照其不同的属性进行代码编制，每个属性给予一个特定的区间，这些区间按照相互之间是否有关分成上下关联区间码和多面码。助记码这种代码将代码对象名或缩写符号作为代码的一部分，其作用往往仅是便于记忆。 代码的设计原则如下：
惟一性：每个编码对象仅有一个代码；每个代码只唯一表示一个编码对象。在现实世界中有很多东西如果我们不加标识是无法区分的，这时机器处理就十分困难。所以能否将原来不能确定的东西，唯一地加以标识是编制代码的首要任务。
可扩充性：必须留有适当的后备容量，以便适应不断扩充的需要。
简单性：代码结构要简单，节省计算机存储空间，减少代码的差错率，提高计算机处理效率。
适用性：尽可能反应编码对象的特点。
规范性：在一个分类编码标准中，代码的类型、结构、编写格式必须统一。
除了满足以上原则，还要在逻辑上必须满足用户需要，在结构上应当与处理的方法相一致。 代码作为计算机的重要输入内容之一，其正确性直接影响到整个处理工作的质量。为了保证正确输入，有意识地在编码设计结构中原有代码的基础上，另外加上一个校验位，校验位是通过事先规定的数学方法计算出来，使它事实上变成代码的一个组成部分。代码一旦输入，计算机会用同样的数学运算方法将输入的代码数字计算出校验位，并将它与输入的校验位进行比较，以证实输入是否有错。
在进行编码设计时，要确定编码的对象，确定系统中哪些信息应系统化、应提高效率以及标准化。同时还要确定编码参照标准、选择编码的种类与类型、增加编码的检错功能和编写编码表。
5.2.4 数据库设计
数据库设计是数据模型从现实到概念模型，从概念模型到逻辑模型，从逻辑模型到物理模型的转换过程。具体如图 5.5 所示：
图 5.5: 从逻辑模型到物理模型的转换过程
而在信息世界中，对上述的表示方法用实体—联系方法进行抽象化，将其转换为关系模式。一般采用ER图来表示，包括实体、属性、联系三种基本元素，矩形框表示实体集，椭圆形框表示属性，菱形框表示实体之间的联系，线段来连接图形。
数据库的概念设计（conceptual design of DB）是指对用户要求描述的对象(一个企业、一个业务部门等)建立抽象的概念数据模型。这个概念模型应反映对象的信息结构、信息流动情况、信息间的互相制约关系以及不同用户对信息增、删、改、查的要求等。此步骤常等同于绘制 E-R 图，形成用户对要开发系统的概念框架。
数据库的逻辑设计（logical design of DB）是指将概念设计阶段完成的的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。 此步骤通常指将 E-R 图转换为数据库表结构。
数据库的物理设计（phsical design of DB）是指根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。这一步设计的结果就是所谓“物理数据库”。 此步骤通常指生成某个具体数据库（如Oracle、MySQL等）要求的库表结构。
数据库的设计首先开展概念设计，之后逻辑设计，最后物理设计，三者逐层递进，缺一不可。概念设计是前提，逻辑设计是桥梁，将概念设计和物理设计紧密联系起来，物理设计的结果就是最终能使用的“物理数据库”。
1. E-R图基本概念
实体(Entity)：任何客观存在并可相互区分的事物叫实体。如学生张三、工人李四等。
属性(Attribute)：实体所具有的某一特性一个实体可以由若干个属性来刻画。例如，学生可由学号、姓名、年龄、系等组成。
联系(Relationship)：实体之间的相互关联万物之间有联系。如学生与老师间的授课关系，学生与学生间有班长关系联系也可以有属性，如学生与课程之间有选课联系，每个选课联系都有一个成绩作为其属性。同类联系的集合称为联系集。其中联系可分为一对一联系(1 ∶1)、一对多联系(1 ∶N)、多对多联系(M ∶N)三种。
码(Key)/键：能唯一标识实体的属性集称作码。如学号是学生实体的码。
2. 绘制E-R图需注意的问题
联系的属性：联系可以有属性，也可以没有属性。如学生与课程间的联系——选课，其属性为成绩；学生与系间的联系——学生-系/属于，就可以用入学日期做属性，或者不用属性。
确定实体和属性：实体与属性间并没有截然划分的界限。一个数据项在某些情况下，可以做属性，也可以做实体。值得注意的是属性与其所描述的实体间只能是单值联系；属性没有再进一步描述的性质；属性除了它所描述的实体以外，不能再与其它实体具有联系。
正确确定多元联系：对于涉及多个实体的问题，必须正确理解所处的条件，确定是定义为一个多元联系，还是定义为多个二元联系。能定义为一个多元联系的问题，一般不应定义为多个二元联系来代替。
E-R图的绘制首先要依据系统分析中完成的数据流程图（DFD）设计局部E-R图，其次合并局部E-R图（消除各局部E-R图之间的冲突），最后修改与重构，生成全局E-R图。将E-R图中的各实体及其对应属性转换为二维数据表结构，利用工具软件（如Powerdesigner等）生成数据库及数据表的脚本执行文件，以建立数据库实体。图 5.6 给出了订单处理的局部E-R图转换为销售处理的全局E-R图示范：
图 5.6: 订单处理的局部E-R图转换为销售处理的全局E-R图
销售计划：计划编号、计划名、商品名称、数量
库存：商品名称、商品编号、货架号
订单：订单编号客户名称商品名称数量
修改：订单编号、商品编号、货架号
图5.7为销售系统全局E-R图
图 5.7: 销售系统全局E-R图
销售计划：计划编号、计划名、商品名称、数量
库存：商品名称、商品编号、货架号
订单：订单编号、客户名称、商品名称、数量
修改：订单编号、商品编号、货架号
客户：客户名称、客户编号、联系人
关系数据库，是建立在关系模型基础上的数据库，而关系模型是指二维表格模型，因而一个关系型数据库就是由二维表及其之间的联系组成的一个数据组织。当前主流的关系型数据库有Oracle、Microsoft SQL Server、Microsoft Access、MySQL。
通常情况下，可以从两个方面来判断数据库是否设计的比较规范。一是看是否拥有大量的窄表，二是宽表的数量是否足够的少。若符合这两个条件，则说明这个数据库的规范化水平比较高。除了这些宽泛的判断外，从实践应用来考量，为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求：
要求一：表中应该避免可为空的列。
虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候，需要进行特殊的处理。如此的话，就会增加数据库处理记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。因此，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。
一是通过设置默认值的形式，来避免空字段的产生。如在一个人事管理系统中，有时候身份证号码字段可能允许为空。因为不是每个人都可以记住自己的身份证号码。而在员工报到的时候，可能身份证没有带在身边。所以，身份证号码字段往往不能及时提供。为此，身份证号码字段可以允许为空，以满足这些特殊情况的需要。但是，在数据库设计的时候，则可以做一些处理。如当用户没有输入内容的时候，则把这个字段的默认值设置为0或者为N/A。以避免空字段的产生。
二是若一张表中，允许为空的列比较多，接近表全部列数的三分之一。而且，这些列在大部分情况下，都是可有可无的。若数据库管理员遇到这种情况，笔者建议另外建立一张副表，以保存这些列。然后通过关键字把主表跟这张副表关联起来。将数据存储在两个独立的表中使得主表的设计更为简单，同时也能够满足存储空值信息的需要。
要求二：表不应该有重复的值或者列。
如有一个进销存管理系统，这个系统中有一张产品基本信息表。这个产品开发有时候可以是一个人完成，而有时候又需要多个人合作才能够完成。所以，在产品基本信息表产品开发者这个字段中，有时候可能需要填入多个开发者的名字。
如进销存管理中，还需要对客户的联系人进行管理。有时候，企业可能只知道客户一个采购员的姓名。但是在必要的情况下，企业需要对客户的采购代表、仓库人员、财务人员共同进行管理。因为在订单上，可能需要填入采购代表的名字;可是在出货单上，则需要填入仓库管理人员的名字等等。
为了解决这个问题，有多种实现方式。但是，若设计不合理的话在，则会导致重复的值或者列。如我们也可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。
可是这么设计的话，会产生一系列的问题。如客户的采购员流动性比较大，在一年内换了六个采购员。此时，在系统中该如何管理呢?难道就建立六个联系人字段?这不但会导致空字段的增加，还需要频繁的更改数据库表结构。明显，这么做是不合理的。也有人说，可以直接修改采购员的名字。可是这么处理的话，会把原先采购订单上采购员的名字也改变了。因为采购单上客户采购员信息在数据库中存储的不是采购员的名字，而只是采购员对应的一个编号。在编号不改而名字改变的情况下，采购订单上显示的就是更改后的名字。这不利于事后的追踪。
所以，在数据库设计的时候要尽量避免这种重复的值或者列的产生。建议，若数据库管理员遇到这种情况，可以改变一下策略。如把客户联系人另外设置一张表。然后通过客户ID把供应商信息表跟客户联系人信息表连接起来。也就是说，尽量将重复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。
要求三：表中记录应该有一个唯一的标识符。
在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个ID列，任何两个记录都不可以共享同一个ID值。另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。否则的话，很容易产生ID值不统一的情况。
另外，在数据库设计的时候，最好还能够加入行号。如在销售订单管理中，ID号是用户不能够维护的。但是，行号用户就可以维护。如在销售订单的行中，用户可以通过调整行号的大小来对订单行进行排序。通常情况下，ID列是以1为单位递进的。但是，行号就要以10为单位累进。如此，正常情况下，行号就以10、20、30依次扩展下去。若此时用户需要把行号为30的纪录调到第一行显示。此时，用户在不能够更改ID列的情况下，可以更改行号来实现。如可以把行号改为1，在排序时就可以按行号来进行排序。如此的话，原来行号为30的纪录现在行号变为了1，就可以在第一行中显示。这是在实际应用程序设计中对ID列的一个有效补充。
要求四：数据库对象要有统一的前缀名。
一个比较复杂的应用系统，其对应的数据库表往往以千计。若让数据库管理员看到对象名就了解这个数据库对象所起的作用，恐怕会比较困难。而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。
为此，建议在开发数据库之前，最好能够花一定的时间，去制定一个数据库对象的前缀命名规范。在数据库设计时，可以与前台应用程序协商，确定合理的命名规范。根据前台应用程序的模块来定义后台数据库对象前缀名。如跟物料管理模块相关的表可以用M为前缀;而以订单管理相关的，则可以利用C作为前缀。具体采用什么前缀可以根据用户的爱好而定义。但是，需要注意的是，这个命名规范应该在数据库管理员与前台应用程序开发者之间达成共识，并且严格按照这个命名规范来定义对象名。
其次，表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀，而函数则可以利用F为前缀。如此数据库管理员无论是在日常管理还是对象引用的时候，都能够在最短的时间内找到自己所需要的对象。
要求五：尽量只存储单一实体类型的数据。
这里将的实体类型跟数据类型不是一回事，要注意区分。这里讲的实体类型是指所需要描述对象的本身。以图书管理系统为例，有图书基本信息、作者信息两个实体对象。若设计人员把这两个实体对象信息放在同一张表中，如可以把表设计成图书名字、图书作者等等。可是如此设计的话，会给后续的维护带来不少的麻烦。
如当后续有图书出版时，则需要为每次出版的图书增加作者信息，这无疑会增加额外的存储空间，也会增加记录的长度。而且若作者的情况有所改变，如住址改变了以后，则还需要去更改每本书的记录。同时，若这个作者的图书从数据库中全部删除之后，这个作者的信息也就荡然无存了。很明显，这不符合数据库设计规范化的需求。
遇到这种情况时，建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、作者基本信息表、图书与作者对应表等等。如此设计以后，以上遇到的所有问题就都引刃而解了。
以上五条是在数据库设计时达到规范化水平的基本要求。除了这些另外还有很多细节方面的要求，如数据类型、存储过程等等。而且，数据库规范往往没有技术方面的严格限制，主要依靠数据库管理员日常工作经验的累积。
3. 数据库增删改查常用SQL语句
结构化查询语言（Structural Query Language, SQL)是数据库增删改查操作中最常用的技能。下面以 MySQL 数据库的增删改查操作为背景，说明常用指令及应用示例。
创建库，删除库，使用库
- 创建数据库：create database 库名;
- 删除数据库：drop database 库名;
- 使用数据库：use 库名;
创建数据表
- 创建表语句：create table 表名（字段名1 字段类型 字段约束，字段2 字段类型 字段约束…);
- 创建与现有表一样字段的新表：createtable 表名 like 已有表名;
- 将查询结果创建新表：create table 表名 select * from 现有表 where…(查询语句);
查看表结构，查看建表语句，删除表
- 查看表结构：desc 表名;
- 查看建表语句：show create table表名;
- 删除表：drop table 表名;
修改表结构
- 对数据表重命名：alter table 表名 rename 新表名;
- 增加字段：alter table 表名 add 字段名 字段类型 字段约束; （PS：可用first/after函数调整字段位置）
- 删除字段：alter table 表名 drop 字段名；
- 修改字段类型及约束：alter table 表名 modify 字段名 新类型 新约束;（PS：如不加新约束，会将建表时的约束清空，主键、外键、唯一约束除外）
- 修改字段名称：alter table 表名 change 字段名 新字段名 新字段类型 新约束条件;
- 修改数据库引擎：alter table 表名 engine=;（PS：主要有InnoDB和MyISAM，InnoDB对经常修改表数据友好，MyISAM对经常查询表友好）
- 增加主键：alter table 表名 add primary key(字段名);
- 删除主键：alter table 表名 drop primary key;
- 增加外键：alter table 表名 add constraint 外键名 foreign kek(字段名) references 主表(主键);
- 删除外键：alter table 表名 drop foreign key 外键名;
- 删除唯一约束：alter table 表名 drop index 字段名;
- 设置自动增长的初始位置：alter table 表名 auto_increment=n;
向表中插入数据
- 向表指定字段插入多条数据：insert into表名（字段1,字段2…） values(数据1,数据2…),(数据1,数据2…),(数据1,数据2…),(数据1,数据2…);
- 将查询结果插入表：insert into 表名 select 字段名 from 表名（查询语句）；
- 加载外部数据到表：Load data localinfile ‘数据路径’Into table 表名Fields terminated by ‘分隔符’Ignored 1 lines；
更新表数据、删除表数据
- 更改满足条件的字段数据：update 表名 set 字段计算1,字段计算2…where 条件；
- 删除满足条件的数据：delele from 表名 where 条件;
- 删除所有数据：方式一：delete from 表名；方式二：truncate table 表名； 方式一会逐条进行删除，速度较慢，方式二直接删除，速度快；另外对自增字段，方式一不能重置自增字段的初始位置，方式二可以重置自增字段的其实位置；
查找数据
- Select列名 From 数据表名 Where 查询条件 Group by 分组字段 Having 分组后的约束条件 Order by 排序字段 Limit 限制输出行数。
关于SQL语句的进一步学习与练习，可以访问：http://www.w3school.com.cn/sql/sql_quiz.asp
5.2.5 软件用户界面及I/O设计
软件用户界面（Software User Interface）是指软件用于和用户交流的外观、部件和程序等等。如果你经常上网的话，会看到很多软件设计很朴素，看起来给人一种很舒服的感觉；有点软件很有创意，能给人带来意外的惊喜和视觉的冲击；而相当多的软件页面上充斥着怪异的字体，花哨的色彩和图片，制作粗劣。软件界面的设计，既要从外观上进行创意以到达吸引眼球的目的，还要结合图形和版面设计的相关原理，从而使得软件设计变成了一门独特的艺术。
输出是系统产生的结果或提供的信息。对于大多数用户来说，输出是系统开发的目的和评价系统开发成功与否的标准。用户都要应用系统输出的信息，输出设计的目的正是为了正确及时地反映和组成用于生产和服务部门的有用信息。从系统开发的角度看，输出决定输入，即输入信息只有根据输出要求才能确定。
输出设计内容包括①确定输出内容： 信息的使用者、使用目的、报告量、使用周期、有效期、保管方法和复写份数等；②选择输出设备与介质：输出到磁盘还是磁带上，输出用纸是专用纸还是普通白纸等；③确定输出格式（报表、用户界面等）。设计输出报告的时候要方便使用者，考虑系统的硬件性能，并且尽量利用原系统的输出格式，确需修改，应与有关部门协商，征得用户同意；输出表格要考虑系统发展的需要，例如是否必要在输出表中留出备用项目，以满足将来新增项目的需要。输出的格式和大小要根据硬件能力，认真设计，并试制输出样品，经用户同意后才能正式使用。 输入设计内容包括①输入原始表格设计；②输入信息内容设计；③数据输入设备的选择：终端、键盘/磁盘、光电阅读器、多媒体输入等；④输入检验设计（输入错误种类；数据出错的校验方法；出错改正方法）。输入设计要注意以下几点：
提示功能：屏幕上的代码信息(如客户代码等)要有提示操作，使用户不必记忆很多的代码。
操作确认：对于不可恢复的操作(如记录删除等)应有操作确认，避免误操作。
错误恢复：用户无意中进行了错误操作，应能有相应的处理程序挽回错误。
数据校验：对于一些有限制条件的输入信息,可自动校验其正确性，避免错误数据进入系统。
缺省赋值：对一些常用信息可以设置缺省值,使用户不必每次都输入这些信息。
记录复制：用户可复制一条或多条已存在的记录,并可修改复制结果，形成新的记录。