3.3 信息系统的数据输入
知识点
1.数据输入为什么重要
一句话：输入是系统的第一道关口，脏数据一旦进来，后面所有处理都是错的。
"垃圾进、垃圾出"（GIGO） 在信息系统里体现得极其充分：
| 输入问题 | 后续后果 |
|---|---|
| 学号输错一位 | 成绩记到别人头上 |
| 日期格式混乱（2024/1/5、2024.1.5、24-1-5） | 无法按时间统计 |
| 手机号少一位 | 通知发不出去 |
| 同一本书录了两个书名 | 库存统计翻倍 |
| 金额录成文本 | 无法求和 |
数据输入环节的两大目标：
- 进得来——方式便捷、效率高，别让用户填到崩溃；
- 进得对——校验严格、格式统一，别让脏数据混进来。
这两个目标常常冲突：校验越多越安全，但填起来越烦。好的设计是在"少打断用户"的前提下把错误拦住。
2.数据的四种来源
| 来源 | 说明 | 举例 |
|---|---|---|
| 人工作业 | 由人直接录入 | 新生报到登记、教师录入成绩 |
| 业务发生 | 业务动作自动产生 | 刷卡、下单、扫码支付 |
| 设备感知 | 传感器、摄像头自动采集 | 温湿度、车牌识别 |
| 外部系统 | 从其他系统导入或接口获取 | 学籍库同步、气象数据接口 |
判断用哪种方式的三问：数据量大不大？是否实时？能不能自动获取？
- 量大＋可自动 → 设备或接口；
- 量小＋需判断 → 人工，但要设计好表单；
- 实时＋业务驱动 → 业务发生时自动采集。
3.五种常用采集方式对比
| 方式 | 效率 | 准确性 | 成本 | 适用场景 |
|---|---|---|---|---|
| 键盘录入 | 低 | 依赖人，易错 | 低 | 小批量、需人工判断 |
| 扫码／刷卡 | 高 | 很高 | 中 | 借还书、考勤、收银 |
| 传感器采集 | 高（自动） | 高（需校准） | 中高 | 环境监测、工业现场 |
| 文件批量导入 | 很高 | 取决于源文件 | 低 | 名单导入、历史数据迁移 |
| 接口对接 | 高（自动） | 高（取决于对方） | 中 | 跨系统同步 |
选型口诀：能量产别手输，能扫码别打字，能对接别导表。
（1）键盘录入的设计要点
- 少打字——能用下拉、单选就不让手输；
- 有默认值——常用选项预填（如"班级"默认当前班）；
- 有提示——输入框旁写清格式要求（如"学号：8 位数字"）；
- 有联想——输入前几位自动匹配。
（2）扫码与刷卡
- 优势：快、准、几乎不出错；
- 前提：每个对象都有唯一编码（条码、二维码、
RFID标签）； - 注意：编码规则要统一，否则扫出来的是"乱码"。
（3）传感器采集
- 关键在校准与采样频率；
- 必须记录采集时间，否则数据无法解释；
- 异常值要标记（如传感器离线记为"缺测"，而不是记 0）。
（4）文件批量导入
- 需要固定模板（表头、列顺序、编码格式）；
- 导入前预校验：必填是否齐全、类型是否正确、有无重复；
- 导入结果要给出报告（成功多少条、失败多少条、失败原因）。
（5）接口对接
- 通过
API自动获取数据，避免人工搬运； - 需确认数据格式（
JSON／XML）、调用频率限制、授权方式； - 要处理对方系统不可用的情况（重试、告警、缓存）。
4.表单设计：输入界面的核心
表单是用户与系统交换数据最主要的界面。
（1）控件怎么选（必考对应关系）
| 数据特征 | 应选控件 | 举例 |
|---|---|---|
| 自由文本、长度不定 | 文本框 | 姓名、备注 |
| 固定长度数字／编码 | 文本框（限长度） | 学号、身份证号 |
| 从少量选项中选一个 | 单选按钮 | 性别、是否住校 |
| 从较多选项中选一个 | 下拉列表 | 班级、学院、省份 |
| 可选多个 | 复选框 | 兴趣特长、选修课 |
| 日期／时间 | 日期选择器 | 出生日期、借书日期 |
| 数值有范围 | 数字框＋步进 | 数量、年龄 |
| 上传附件 | 文件上传 | 照片、证明材料 |
| 长文本 | 多行文本框 | 报修描述 |
选控件的原则：能选就别让人打（减少输入＝减少错误），但选项太多（超过 15 个）时下拉不如搜索。
（2）表单布局的六条规则
| 规则 | 说明 |
|---|---|
| 标签在左、输入在右（或上标签下输入） | 对齐一致，视线流畅 |
| 必填项明确标记 | 用星号并说明"带星号为必填" |
| 相关字段分组 | "基本信息""联系方式""附件"分块 |
| 一屏完成主要任务 | 避免长表单翻页丢失 |
| 主按钮突出 | "提交"醒目，"重置"次之 |
| 错误提示就近显示 | 错在哪个框，提示写在哪个框下面 |
（3）一个好表单与一个坏表单的差别
| 坏做法 | 好做法 |
|---|---|
| 性别用文本框让人手打 | 用单选：男／女 |
| 日期让人输"2024.1.5" | 用日期选择器，自动规范格式 |
| 提交后才知道填错了 | 输入时就即时校验，边填边提示 |
| 提交按钮在页面最底部，要滚三屏 | 固定底部或吸顶，随时可提交 |
| 出错只提示"输入有误" | 提示"手机号应为 11 位数字，当前为 9 位" |
核心结论：好的表单设计，能让错误"根本发生不了"——这才是最高级的校验。
5.数据校验：把错误拦在门外
四类校验（必背，常考"属于哪类校验"）：
| 类型 | 检查什么 | 举例 |
|---|---|---|
| 格式校验 | 是否符合规定的形式 | 手机号必须是 11 位数字；邮箱必须含 @ |
| 范围校验 | 是否在合理区间 | 年龄在 6 |
| 必填校验 | 关键字段是否为空 | 姓名、学号不能为空 |
| 逻辑校验 | 字段之间是否自相矛盾 | 归还日期不能早于借出日期；出生日期不能晚于今天 |
校验的三个层次（都要有）：
| 层次 | 在哪做 | 优点 | 缺点 |
|---|---|---|---|
| 前端校验 | 浏览器／客户端 | 即时反馈，体验好 | 可被绕过（改页面、直接调接口） |
| 后端校验 | 服务器 | 可靠，绕不过 | 反馈慢一步 |
| 数据库约束 | 数据库 | 最底层兜底 | 提示不友好 |
结论：三层都要做，不能只靠前端。只做前端校验的系统，等于没有校验——这是安全测试的常见突破口。
校验提示的写法（要具体、可行动）：
- 差："输入错误"——用户不知道错在哪；
- 好："手机号应为 11 位数字，您输入了 9 位"——直接告诉怎么改。
软校验与硬校验：
- 硬校验——不合法就不让提交（必填、格式错）；
- 软校验——可以提交但给出提醒（如"该学号已存在，是否继续？"），用于确实存在的特殊情况。
6.数据编码与规范化
编码是给对象一个唯一、稳定、可读的标识。
| 编码对象 | 编码示例 | 设计要点 |
|---|---|---|
| 学生 | 2024 + 01 + 08（年级＋班级＋序号） | 含含义、定长、不重复 |
| 图书 | B + 6 位序号 | 前缀区分类型 |
| 报修单 | BX + 20241107 + 001 | 含日期，便于按时间归档 |
| 商品 | 条形码（EAN-13） | 国际通用标准 |
编码设计四原则：
- 唯一——绝不重复；
- 稳定——定了就不改（改编码会牵动所有关联表）；
- 可读——尽量能看出含义（年级、类别）；
- 定长——便于校验与排序。
编码之外还要"规范化"：
| 字段 | 不规范 | 规范做法 |
|---|---|---|
| 姓名 | 张 明、张明、张明（全角空格） | 去空格，统一编码 |
| 性别 | 男、M、1、male | 统一为"男／女" |
| 电话 | 138-1234-5678、13812345678 | 只存数字，显示时格式化 |
| 地址 | 河北省石家庄市…／河北石家庄… | 分级存储（省／市／区／详细） |
| 日期 | 各种格式 | 统一为 YYYY-MM-DD |
为什么较真：同一件事用两种写法记录，统计时就是两条数据。规范化是数据质量的第一道工序。
7.批量导入：大数据量输入的正确姿势
标准流程（五步）：
| 步骤 | 做什么 |
|---|---|
| 1. 提供模板 | 给固定表头的 Excel／CSV 模板，写明每列格式 |
| 2. 用户填表 | 按模板填写，不增删列、不改表头 |
| 3. 预校验 | 系统检查必填、类型、重复、外键是否存在 |
| 4. 确认导入 | 展示"共 200 条、可导入 195 条、异常 5 条"，让用户确认 |
| 5. 输出报告 | 列出失败行的行号与原因，供用户修正后重传 |
四个常见坑：
- 编码问题——
CSV用UTF-8还是GBK，中文容易变乱码； - 数字变文本——学号
20240101被 Excel 当成数字，前导 0 丢失； - 日期格式不一致——导入时解析失败；
- 重复导入——同一批数据导两次，产生重复记录（要去重或加唯一约束）。
最实用的建议：导入一定要"先预览、后提交"，绝不能点一下就全量写入。
8.输入效率与用户体验
| 手段 | 效果 |
|---|---|
| 扫码替代手输 | 效率提升十倍以上，错误率接近零 |
| 默认值与继承 | 连续录入同类数据时自动带出 |
| 键盘友好 | 支持 Tab 切换、Enter 提交、快捷键 |
| 批量操作 | 一次选中多条统一处理 |
| 草稿保存 | 长表单可暂存，防意外丢失 |
| 复制上一行 | 批量录入相似记录时省一半时间 |
真实场景对比：1000 名新生信息，纯手输约需 20 小时且错误率高；用"身份证读取＋扫码＋模板导入"，约 2 小时即可完成。输入方式的选择，直接决定项目的人力成本。
9.输入环节的合规要求
采集数据必须守住三条线：
| 要求 | 说明 |
|---|---|
| 最小必要 | 只采集业务必需的信息，不"顺便多收" |
| 告知同意 | 明确告知采集什么、做什么用，取得同意 |
| 安全保护 | 传输加密、存储加密、权限控制、脱敏展示 |
典型违规：报名表要求填写"家庭成员收入""病史"等与业务无关的信息；把采集到的手机号转卖给第三方。这些都属于《个人信息保护法》规范的范围（第5单元详讲）。
脱敏展示：列表中手机号显示为 138****5678，身份证显示为 1101**********1234——该看的人看全，不该看的人看遮。
10.速查表
| 序号 | 考点 | 结论 |
|---|---|---|
| 1 | 输入环节的地位 | 第一道关口，脏数据进则全错 |
| 2 | GIGO | 垃圾进、垃圾出 |
| 3 | 输入两大目标 | 进得来（效率）、进得对（质量） |
| 4 | 数据四种来源 | 人工作业、业务发生、设备感知、外部系统 |
| 5 | 五种采集方式 | 键盘、扫码刷卡、传感器、文件导入、接口 |
| 6 | 选型口诀 | 能量产别手输，能扫码别打字 |
| 7 | 少量选项单选 | 单选按钮 |
| 8 | 较多选项选一 | 下拉列表 |
| 9 | 可选多个 | 复选框 |
| 10 | 日期输入 | 日期选择器 |
| 11 | 四类校验 | 格式、范围、必填、逻辑 |
| 12 | 逻辑校验举例 | 归还日期不早于借出日期 |
| 13 | 校验三层次 | 前端、后端、数据库 |
| 14 | 只做前端校验的问题 | 可被绕过，等于没有校验 |
| 15 | 校验提示要求 | 具体、可行动（说清错在哪、怎么改） |
| 16 | 编码四原则 | 唯一、稳定、可读、定长 |
| 17 | 规范化的意义 | 防止同一事实两种写法 |
| 18 | 批量导入关键 | 先预览、后提交 |
| 19 | 导入常见坑 | 编码、数字变文本、日期格式、重复导入 |
| 20 | 合规三线 | 最小必要、告知同意、安全保护 |
| 21 | 脱敏展示 | 138****5678 |
11.课堂提示（讲课参考）
- 做一个"填表体验"对比实验：课前发两张纸质表——A 表全是空白横线（姓名、性别、出生日期、班级、电话都要手写），B 表全是勾选项。让学生各填 5 份并计时，速度快慢立现。讲"控件选择"时就有共同体验了。
- 脏数据后果要"可视化"：准备一份故意做脏的名单（性别写"男／M／1"、日期三种格式、名字带空格），让学生用 Excel 统计各班人数，会发现结果对不上。再讲规范化，学生自然认同。
- 校验一定要演示"绕过前端"：在浏览器里把必填属性删掉再提交，数据居然进去了——这个演示能让学生真正理解"为什么后端必须再校验一次"，也是安全意识的启蒙。
- 批量导入让学生自己踩坑：给一个学号为
20240101的CSV，用 Excel 打开再另存，前导 0 就丢了。学生看到"0101"才知道"数字变文本"是什么意思。 - 作业建议：为"社团报名"设计一张表单——列出字段、选控件、写校验规则、给出错误提示文案。要求每条提示"必须说清怎么改"，这是最能体现设计功力的细节。