制定数据验证规则

以下为员工编号（Employee_ID）的数据验证规则。规则分为强制规则与可选增强规则，并提供标准化的验证方法与实施建议。请根据组织具体编号方案对参数进行配置。

一、适用范围
- 适用于所有人力资源主数据、薪酬、考勤、身份与访问管理（IAM）、财务及其他使用员工编号作为主键或外键的系统。
- 适用于生产数据、历史数据、批量导入、接口接入及数据仓库落地。

二、数据元素定义
- 名称：员工编号（Employee_ID）
- 数据类型：字符串（String）
- 角色：企业范围内的唯一主标识（Golden ID），不承载业务语义，不嵌入个人信息。
- 大小写规范：统一存储为大写；客户端输入与展示不区分大小写。

三、强制验证规则（Mandatory）
R1. 非空约束
- 规则：Employee_ID 必填，禁止 NULL、空字符串或仅空白字符。
- 验证方法：Trim 后长度 > 0；禁止不可见字符（如零宽字符）。
- 严重性：阻断（Blocker）。

R2. 唯一性与不可重用
- 规则：企业全域唯一；历史离职或合并记录的编号不得重用。
- 验证方法：主数据层唯一索引；导入时增量比对；保留已使用编号黑名单。
- 严重性：阻断。

R3. 格式与字符集
- 规则：仅允许大写字母 A–Z 与数字 0–9；禁止特殊字符（如空格、连字符、下划线、斜线、点）。
- 验证方法：正则表达式 ^[A-Z0-9]+$（存储前统一转大写）。
- 严重性：阻断。

R4. 长度边界
- 规则：长度在 8–12 字符之间（建议固定长度，便于校验与索引；如组织已有标准，按标准配置）。
- 验证方法：len(Employee_ID) ∈ [8, 12]。
- 严重性：阻断。

R5. 前后空白与前导零处理
- 规则：存储前必须去除前后空白；允许保留业务定义内的前导零（如固定宽度序列），禁止因转换丢失前导零。
- 验证方法：Trim；对输入与输出进行等值校验（"00123456" 不得变为 "123456"）。
- 严重性：阻断。

R6. 黑名单值
- 规则：禁止使用通用占位或测试值，如 "TEST"、"EMPLOYEE"、"UNKNOWN"、"NULL"、全零或全同字符（如 "00000000"、"AAAAAAAA"）。
- 验证方法：设定黑名单集合并在校验时比对。
- 严重性：阻断。

R7. 稳定性与不可变更
- 规则：一旦分配，Employee_ID 不得变更；人员属性变更不得触发编号变更。
- 验证方法：更新接口拒绝对主键字段的修改；仅允许状态位变更。
- 严重性：阻断。

R8. 去语义化与合规
- 规则：编号不得嵌入个人信息或敏感属性（如身份证号、生日、部门/岗位编码、地区代码等），以降低隐私与重识别风险。
- 验证方法：模式扫描与关键字/模式排查（日期样式、身份证样式）；抽样审计。
- 严重性：阻断。

R9. 参照完整性（外键约束）
- 规则：所有引用 Employee_ID 的外键值必须在主数据员工表中存在且处于有效状态（或符合历史关联规则）。
- 验证方法：落地/加载前 FK 检查；对失效员工限制新交易（按业务定义）。
- 严重性：阻断或高优先级告警（按业务场景配置）。

R10. 单一数据源与映射
- 规则：Employee_ID 的权威来源为 HR 主数据域；其他系统如使用本地别名，必须维护一对一映射，不得替代主键使用。
- 验证方法：主键映射表唯一性与完备性校验；接口层强制返回主键。
- 严重性：阻断。

R11. 审计与可追溯
- 规则：所有编号分配、引用与拒绝事件必须记录时间戳、来源系统、操作人/服务、请求负载哈希。
- 验证方法：审计日志不可变存储；抽检与对账。
- 严重性：高优。

R12. 错误处理与反馈
- 规则：对违反规则的记录应返回标准化错误码与可操作信息（如 EID_FORMAT_INVALID、EID_DUPLICATE），禁止仅返回通用失败。
- 验证方法：接口契约与批处理校验报告。
- 严重性：高优。

四、可选增强规则（Recommended）
R13. 前缀策略（如适用）
- 规则：可使用固定前缀以标识实体类型（如 "E" 或 "EMP"），但不得泄露组织结构或状态语义。
- 验证方法：正则 ^EMP[0-9A-Z]+$ 或 ^E[0-9A-Z]+$。
- 严重性：建议。

R14. 校验位（提高输入质量）
- 规则：引入一位数字校验位，用于检测输入错误。若编号含数字序列，可采用 Luhn（Mod10）对数字部分计算校验位。
- 计算方法（Luhn，对不含校验位的数字序列 S）：
  1) 从最右侧起（不含校验位），奇偶位交替对每第二位数字做加倍；
  2) 加倍结果若大于 9，减去 9；
  3) 将所有处理后的数字求和，取 sum % 10；
  4) 校验位 = (10 - (sum % 10)) % 10；
- 验证方法：对输入编号的校验位重算并比对。
- 严重性：建议（可设为阻断）。

R15. 固定长度与模式示例（模板）
- 示例模式：EMP + 7 位数字序列 + 1 位 Luhn 校验位，总长度 11。
- 正则：^EMP\d{8}$（其中最后一位为校验位，需通过 R14 校验）。
- 说明：仅为模板，需与组织编号方案对齐。

R16. 连续性与跳号策略
- 规则：允许跳号以避免被枚举；禁止回填历史废弃号段。
- 验证方法：号段分配策略与审计。
- 严重性：建议。

R17. 大量导入阈值与速率限制
- 规则：批量生成或导入时应设定速率限制与并发唯一性检查，防止竞态导致重复。
- 验证方法：事务锁/幂等键；导入报告重复率 < 阈值（如 0.01%）。
- 严重性：建议。

五、实施与管控要求
- 验证点：源系统输入层、API 网关、ETL/ELT 作业、数据仓库落地、主数据对账。
- 主数据治理：由数据管理员（Data Steward, HR 域）负责规则维护与例外审批；变更需走治理变更流程（版本化、影响评估、回归测试）。
- 指标监控（DQKPI）：唯一性违规率、格式违规率、黑名单命中率、FK 失配率、校验位失败率、异常处理 SLA。

六、示例正则集合（按基线规则）
- 仅限大写和数字：^[A-Z0-9]{8,12}$。
- 模板（含前缀）：^EMP[0-9A-Z]{5,9}$（按需要调整具体长度）。
- 禁止空白：^\S+$（辅助校验，存储前 Trim）。

以上规则为组织级数据治理基线。请在落地前确认实际编号方案（长度、是否前缀、是否校验位），并将参数固化到数据字典与接口契约中，同时在主数据平台启用相应的校验与审计。

Data element: Transaction Amount

Definition
- Purpose: Monetary value associated with a financial transaction.
- Data type: Fixed-point decimal or integer in minor units (recommended).
- Currency dependency: Precision and allowed decimal places depend on the transaction currency per ISO 4217 minor unit (exponent).
- Sign convention: Configurable by transaction_type (e.g., debit, credit, refund) and account/ledger rules.

Validation rules

Syntactic and type integrity
- R1. Not-null
  - Rule: amount must be present for any posted or authorized monetary transaction.
  - Severity: Reject.
- R2. Numeric and finite
  - Rule: amount must be a numeric value; NaN, Infinity, and string formats are not allowed in stored data fields.
  - Severity: Reject.
- R3. Fixed-point representation
  - Rule: amount must be stored using fixed-point decimal with defined precision/scale or as integer in minor units (e.g., cents).
  - Severity: Reject.

Currency-scale and precision
- R4. Decimal places match currency minor unit
  - Rule: decimal scale must equal the currency’s minor unit (ISO 4217). For example, USD=2, JPY=0, KWD=3.
  - Severity: Reject.
- R5. Rounding mode
  - Rule: when calculations produce more precision than allowed, round to the currency minor unit using a defined rounding mode (e.g., round half up or bankers rounding). The rounding mode must be consistent across all services and documented.
  - Severity: Reject if not conformant; Flag if internal intermediate breach before normalization.

Value range and sign
- R6. Non-zero (default)
  - Rule: amount must be > 0 for standard purchase, transfer-out, or deposit transactions.
  - Exception: amount may be < 0 for refunds/chargebacks or = 0 for authorization reversals; exceptions must be explicitly whitelisted by transaction_type.
  - Severity: Reject if outside allowed ranges for the given transaction_type.
- R7. Sign aligned with transaction_type
  - Rule: sign must match the transaction_type-to-sign mapping (e.g., debit=positive, credit=negative) defined in policy.
  - Severity: Reject.
- R8. Maximum per transaction
  - Rule: amount must not exceed Policy.MaxPerTransaction[currency] for the customer/segment/risk tier.
  - Severity: Reject.
- R9. Minimum per transaction
  - Rule: amount must be >= Policy.MinPerTransaction[currency], respecting currency minor units.
  - Severity: Reject.

Contextual and business consistency
- R10. Currency consistency
  - Rule: amount’s precision and rounding must be validated against the transaction currency. If conversion is performed, store original_amount, original_currency, conversion_rate, and converted_amount; validate converted_amount scale to the target currency.
  - Severity: Reject if inconsistent.
- R11. Payment method constraints
  - Rule: enforce method-specific rules (e.g., cash transactions cannot be negative; prepaid cards cannot create negative balances).
  - Severity: Reject.
- R12. Balance protection (if applicable)
  - Rule: posting the amount must not violate account constraints (e.g., no negative balance for accounts without overdraft).
  - Severity: Reject.
- R13. Total reconciliation (if total present)
  - Rule: subtotal + taxes + fees - discounts must equal total_amount within currency minor unit tolerance.
  - Severity: Reject.

Anomaly and limit monitoring
- R14. Rolling limits
  - Rule: sum of amounts per account/identity within defined windows (e.g., daily, weekly) must not exceed Policy.MaxRollingLimit[currency].
  - Severity: Reject or Flag based on policy.
- R15. Outlier detection
  - Rule: Flag if amount exceeds dynamic threshold (e.g., > P99 of last 90 days for the account or > 3 standard deviations above mean).
  - Severity: Flag.
- R16. Duplicate prevention (amount-level)
  - Rule: Flag potential duplicates when identical amount + currency + merchant + payment method occur within a short time window and same authorization reference.
  - Severity: Flag.

Data quality and formatting at ingestion (for string inputs)
- R17. Canonicalization
  - Rule: strip currency symbols, thousands separators, and locale-specific formatting; convert to canonical numeric before storage.
  - Severity: Reject if canonicalization fails.
- R18. Leading/trailing characters
  - Rule: no leading/trailing spaces; no non-numeric characters except one decimal separator (if using decimal representation).
  - Severity: Reject.

Auditability and lineage
- R19. Provenance
  - Rule: record source_system, capture_method, and transformation steps affecting amount and rounding.
  - Severity: Flag if missing (data quality issue).

Configuration parameters (examples)
- Currency minor units: maintained from ISO 4217; override table for non-ISO assets (e.g., crypto).
- Rounding mode: round_half_up or bankers_rounding; single authoritative setting.
- Max/Min per transaction: per currency, per product, per KYC/risk tier.
- Rolling limits: per account/identity and time window.
- Transaction_type-to-sign map: explicit mapping table.

Example implementation patterns

Preferred storage schema
- Option A (minor units integer):
  - amount_minor_units: BIGINT NOT NULL
  - currency_code: CHAR(3) NOT NULL
  - Constraint: amount_minor_units % 1 = 0 (implicit); scale guaranteed by currency minor unit.
- Option B (decimal fixed-point):
  - amount: DECIMAL(18, s) NOT NULL, where s is determined by currency minor unit; if a single column must store multi-currency, enforce scale on write via application logic and validation triggers.

SQL check constraints (illustrative; adjust for your RDBMS)
- Enforce non-zero for purchase:
  - CHECK (transaction_type <> 'PURCHASE' OR amount_minor_units > 0)
- Enforce sign for refunds:
  - CHECK (transaction_type <> 'REFUND' OR amount_minor_units < 0)
- Per-transaction maximum (example for USD; 2 minor units):
  - CHECK (currency_code <> 'USD' OR ABS(amount_minor_units) <= 10000000) -- e.g., USD 100,000.00

Great Expectations-style rules (illustrative)
- expect_column_values_to_not_be_null: amount
- expect_column_values_to_be_of_type: Decimal/Integer
- expect_column_values_to_be_between: min_value=Policy.MinPerTxn[currency], max_value=Policy.MaxPerTxn[currency], parse dynamically per row
- expect_multicolumn_values_to_satisfy: sign aligned with transaction_type
- custom expectation: decimal_places_equal_currency_minor_unit

Operational notes
- Avoid binary floating-point types; use fixed-point decimal or store minor units as integers.
- Maintain a currency metadata service for minor units and rounding rules; do not hardcode in application code.
- All exceptions must be explicit, logged, and reviewed; default stance is reject on violation.
- Version the policy configuration and capture effective_from dates to ensure reproducible validation across policy changes.

以下为“手机号”数据验证规则，面向数据治理场景，包含字段定义、校验规范、标准化存储、数据质量控制与合规要求。根据业务范围，提供两套规则：仅支持中国大陆手机号（国内场景）与支持全球手机号（国际场景，E.164）。

一、适用范围与标准
- 国内场景（中国大陆手机号）：适用全国移动通信号码（不含座机），采用国家标准号段校验。
- 国际场景（全球手机号）：采用 E.164 编码规则进行结构校验与存储。

二、字段定义与元数据
- 数据名称：mobile_phone_number
- 数据类型：字符串（String）
- 字段长度：
  - 国内存储（本地格式）：11 位
  - 国际存储（E.164）：最多 16 个字符（包含前导“+”，最多 15 位数字）
- 字段敏感级别：个人敏感信息（PII）
- 主键/唯一性：按规范化后（canonical）的 E.164 形式建立唯一约束（防重复）
- 允许值域：按下述校验规则

三、校验规则
A. 通用基础规则（输入层）
- 非空校验：不能为空或仅空白字符。
- 字符集校验：仅允许数字、可选的前导“+”，输入中的空格、连字符、括号等展示性字符必须在标准化阶段移除，不参与存储。
- 长度初筛：去除非数字/格式字符后，数字长度应在 7–15 位之间（国际），或恰为 11 位（国内）。

B. 中国大陆手机号校验规则（国内场景）
- 结构规则：必须为 11 位数字，正则：^1[3-9]\d{9}$
  - 说明：以 1 开头，第二位范围 3–9，后续 9 位为数字。该模式覆盖主流运营商与虚拟运营商号段。
- 禁止包含国内拨号前缀（如 0、(0) 等）、分隔符；输入层允许存在分隔符但标准化时移除。
- 规范化存储：
  - 国内本地格式：存 11 位（例：13800000000）
  - 国际统一格式（推荐）：存 E.164（例：+8613800000000）
- 业务校验（可选强化）：发送一次性验证码（OTP）或语音回拨验证，以确认可达性与活跃性。

C. 全球手机号校验规则（国际场景，E.164）
- 结构规则：国际表示正则：^\+[1-9]\d{1,14}$
  - 说明：前导“+”，其后为国家码（不能以 0 开头），总数字长度最多 15 位；不包含国家内的拨号前缀或分隔符。
- 标准化要求：
  - 移除空格、连字符、括号等展示性字符。
  - 将“00”国际接入码转换为“+”（例如 0044123456789 → +44123456789）。
  - 禁止保留国家内长途/国内前缀（如 0）。
- 可选国家级校验（增强）：在已知国家码下，校验该国的国家重要号码（NSN）长度边界与已知移动号段前缀（需维护国家规则表）；注意该校验需定期维护更新。

四、标准化与存储策略
- 规范化流程（输入→存储）：
  1. Trim 去除首尾空白。
  2. 移除所有非数字字符，保留可选前导“+”；将“00”替换为“+”。
  3. 若为国内场景且无国家码：在通过国内正则校验后，生成 E.164 表示为 +86 + 本地 11 位。
  4. 再次按目标规则校验（国内或国际）。
  5. 以 E.164 形式作为 canonical 存储，并用于唯一性与比对。
- 展示层可按区域格式化，但数据库始终存 canonical（E.164）。
- 索引与去重：对 canonical 字段建立唯一索引；新增或更新前进行去重检查。

五、数据质量管理
- 质量维度与度量：
  - 完整性：手机号非空率 ≥ 指标阈值（如 99%）。
  - 有效性：通过规则校验的比例 ≥ 阈值（如 98%）。
  - 一致性：存储统一为 E.164；不同系统间一致率 ≥ 阈值。
  - 唯一性：重复率 ≤ 阈值（如 ≤ 0.5‰）。
  - 可达性：验证码送达成功率、退回率监控。
- 异常处理：
  - 失败原因分类（空值、非法字符、长度不符、号段不符、E.164 不合规）。
  - 生成标准错误码与友好提示，支持数据修复工作流。
- 变更管理：国家号段、规则库定期审查与更新；版本化规则并记录生效日期。

六、合规与安全要求
- 分类分级：标为 PII，纳入个人信息保护与访问控制策略。
- 存储与传输：使用加密传输（TLS），静态加密或字段级加密（视风险等级）。
- 最小化与目的限制：仅为联系与认证目的收集；超目的使用需评估与授权。
- 脱敏与展示：日志、报表、测试数据中进行部分掩码（如 +86138****0000）。
- 保留与删除：按数据保留政策定期清理未验证或过期手机号；满足数据主体删除请求。
- 审计与合规：记录采集、验证、变更与访问审计；满足适用法律法规（如数据跨境传输合规）。

七、实现示例（规则表达）
- 国内手机号正则（输入层）：^1[3-9]\d{9}$
- 国际 E.164 正则（canonical 层）：^\+[1-9]\d{1,14}$
- 伪代码流程（简化）：
  - 输入 s
  - s = trim(s)
  - 若 s 以 "00" 开头 → s = "+" + s[2:]
  - 移除除数字与前导“+”外的字符
  - 若国内模式：
    - 若 s 匹配 ^1[3-9]\d{9}$ → canonical = "+86" + s
    - 否则失败
  - 若国际模式：
    - 若 s 匹配 ^\+[1-9]\d{1,14}$ → canonical = s
    - 否则失败
  - 写入 canonical；建立唯一索引；必要时触发 OTP 验证

八、测试用例（示例）
- 有效（国内）：13800000000 → +8613800000000
- 有效（国际）：+441234567890 → +441234567890
- 标准化："(+86) 138-0000-0000" → +8613800000000
- 无效：123456、+012345、+86 13800000000（含空格且未规范化时）、1A800000000（含字母）

以上规则可直接纳入数据标准与校验服务，结合数据质量监控与合规控制形成闭环。根据组织业务范围选择国内或国际模式，或并行支持并通过 canonical 存储确保一致性与可用性。