建模：名称字段 - Dan

建模：名称字段 - Dan

在本文中，我们关注记录名称字段。这些字段旨在包含一个用户可识别的值，通过该值可以了解、寻址或引用一个人或事物。与业务标识符字段不同，名称字段的值可能会随着时间而改变。此外，对于可以存在有效重复值的事物（例如人、城市），存在“真实世界”名称。

名称字段值唯一性
一些信息系统记录代表组织“拥有”的东西。例如：

组织有权分配名称值，并期望该记录字段的值是唯一的。
其他信息系统记录代表组织外部的事物。例如：

• 区域（例如城市、国家）

信息系统需要确保给定外部记录名称字段的值来源正确，并尽可能与组织外部发生的任何值更改保持同步。依赖外部记录字段值的唯一性取决于组织“信任”负责维护和提供值的外部来源的能力。例如国际标准组织。

全名、缩写名和编码名
当记录表示具有命名实例的事物时，很有可能需要多个名称字段。无论名称由几个完整的单词组成，组织很可能会使用其在业务流程中使用的名称的较短版本。并且在频繁使用名称并且要尽量减少击键的情况下，可能会有名称的超短代码版本。

全名--如果一个名字是为了描述性的，那么它的价值就包含了完整的单词。例如："Tee Hinge 200mm Zinc Plated", "Human Resources Department", "California"。全名字段通常有术语名称或标签作为其字段名的一部分。

缩写名称 - 缩写名称是供组织 "日常使用 "的。构成全名的单词可以被缩写，减少为首字母，或变成缩写。初来乍到的人可能不会立即认出一个缩写的名字，但这是该事物在组织内通常被称为的名字。例如，"T-hng 200mm Zn Plt"，"HR"，"Cal"。

编码名称 - 编码名称旨在占用最少的屏幕或报告空间。这种节省空间的代价是信息系统的新用户的学习曲线。组织中的 "老前辈 "对编码值了如指掌，他们很难理解这些编码值对每个人来说并不明显。

编码名称字段通常将术语代码或缩写cd作为其字段名的一部分。值可以短到一个字符，但更典型的是利用两到六个字符。长于六个字符的代码则是进入了缩写的领域。

如果一个东西在多个组织中是通用的，如COUNTRY或CURRENCY，则可以使用标准化的代码值。国际标准组织（ISO）为国家、国家内部的地区（州或省）、语言和货币制定了代码。其他组织为更多的行业特定代码提供标准。一个例子是国际航空运输协会（IATA），它维护用于识别机场的三个字符的代码（例如，"LAX "代表洛杉矶国际机场）。

非文字名称
并非所有的名字都由单词或缩写组成。街道名称就是一个很好的例子。大多数街道的名称确实涉及到像 "Main "或 "Maple "这样的词，或者是以人或地方命名的。但也有一些街道名称仅仅是基于数字或字母，例如 "第一大道"、"第二大道"、"A街"、"B街"。

另一个非文字名称的例子是多层建筑中的楼层。楼层会有完整的名称，如'地面层'、'第五层'、'第一层停车场'或'顶楼'。但该组织可能只想拥有编码版本的楼层名称（如'G'、'5'、'P1''PH'）。

人名
对于代表个人的记录，如工作人员或客户，有四种基本的名字类型，可能需要支持一个组织的业务流程信息需求。

• 法人名--需要支持涉及监管组织的业务流程，如税务机关，这些组织需要通过他们的全名来识别个人（和公司）。例如："Thomas Albert Jones"。
• 联系人姓名 - 个人希望在其接触点上被识别的姓名，例如在收到蜗牛邮件或通过电话联系时。希望（但不是必须）包括一个或多个 "名字 "和一个姓氏。例如："Tom Jones"。
• 偏爱的名字 - 一个人在组织内部和/或客户那里喜欢用的名字。例如，'Tommy'--显示在员工的ID胸牌上。对于客户来说，这是一个人更愿意看到的名字，作为他们在线用户体验的一部分。例如：'欢迎回来，汤姆'。
• 用户ID - 由信息系统的在线用户选择或分配的名字。一般来说，它是这个人的名字的某个版本。这些名字可以被要求在系统的范围内是唯一的（但如果需要的话，可能允许随时间变化）。例如，"TJones "代表一个内部用户，"[email protected] "代表一个组织外部的用户。
  当信息系统被期望把人名的 "部分 "作为单独管理的字段（如名、姓、中间名）时，PERSON NAME应该被认为是它自己的记录类型，包含一个单独的字段，用于姓名的每个有意义的部分。这允许这些字段被定义一次，并重复使用（与）任何数量的涉及人名的记录相关。

注意：有些组织选择在人名前加上一个头衔，如 "先生 "或 "夫人"。同样地，一个组织可能希望在一个人的名字后面加上一个或多个公认的资格，如 "MD"、"PhD "或 "QC"。如果这样的前缀和后缀打算从预先建立的值集中选择，它们可以被视为关于名字的信息，但应该被视为分类字段。

名称字段属性
一个名称字段应该在一个记录的范围内，其值是用来识别的，例如：POSITION、GL ACCOUNT、STAFF MEMBER、CUSTOMER。对于实例只有一个名字的记录，该字段可以简单地称为Name。理想情况下，字段的定义应该包括一个或多个例子，明确说明对实例值的期望。

源自组织内部的名称值可以在组织规定的任何长度限制范围内进行调整。来自外部的名称字段需要允许有足够的字符来容纳最长的 "现实世界 "的值。如果没有，那么获取名字值的过程需要允许它被缩写或截断以适应系统规定的限制。

每个名字字段都应该有一个最大长度的规定（测试人员将对此进行测试）。主题专家应该能够给出多少个字符就够了的指示。在代码的情况下，组织可能还想指定一个最小的字符数。

在限制名称中允许的字符方面，如果有业务上的理由，可以限制内部创建的名称（例如，只有字母字符和空格）。除非有业务理由限制允许的字符，否则外部来源的名称最好不受限制。问题是，"如果收到的有效外部名称包含一个或多个限制字符，系统应该怎么做？" 让它们不受限制就可以解决这个问题。

名称值--底线
大多数内部来源的名称来自于组织的决策者。如果有技术上的原因，一个名字中不允许有一个或多个特殊字符，那么验证以避免它们是一件合理的事情。外部来源的名称，如果它们是来自有效的来源，那么它们就是这样的。一个需要在信息系统中支持它们的组织不应该被系统告知（在一个错误信息中）它不能接受一个给定的值。

一个信息系统只能做这么多来验证名称输入。一个名字的值有可能被错误地输入，但仍然符合所有定义的验证标准。例如，输入的是 "Tom Bones "而不是实际正确的名字 "Tom Jones"。应该有一种系统功能，支持改变错误输入的姓名值。