提交表单数据到数据库_普通表单不仅适用于数据库

提交表单数据到数据库

您也可以将类似的规则应用于数据对象类型。 (You can apply similar rules to data object types, too.)

You probably learned the term Normal Form in the context of defining schemas for relational databases. Database normalization strives to reduce data redundancy in table rows and columns. Consequently, data anomalies are less likely to occur.

您可能在为关系数据库定义架构的上下文中学到了“ 正规形式 ”一词。 数据库规范化致力于减少表行和列中的数据冗余。 因此，不太可能发生数据异常。

什么是数据异常？ (What’s a data anomaly?)

Suppose we had this situation:

假设我们有这种情况：

Table A contains values for properties X, Y, Z for a row identified by the id of x; these are assertions about x. Let’s say Y in row x is asserted to be the value 3.

表A包含ID为x的行的属性X，Y，Z的值； 这些是关于x的 断言 。 假设x行中的Y被声明为值3。

Table A contains values for properties X, Y, Z for a row identified by the id of x; these are assertions about x. Let’s say Y in row x is asserted to be the value 3.

表A包含ID为x的行的属性X，Y，Z的值； 这些是关于x的 断言 。 假设x行中的Y被声明为值3。

Table B also contains the same assertions about why Y for x

表B也包含关于为什么Y代表x的相同断言

Table B also contains the same assertions about why Y for x

表B也包含关于为什么Y代表x的相同断言

Table A is told later, “Facts have changed. Y is now 4”

稍后告诉表A，“事实已经改变。 Y现在是4”

Table A is told later, “Facts have changed. Y is now 4”

稍后告诉表A，“事实已经改变。 Y现在是4”

Table B is later queried, and says Y is still 3.

稍后查询表B，并说Y仍为3。

Table B is later queried, and says Y is still 3.

稍后查询表B，并说Y仍为3。

That’s a data anomaly: two different assertions about a fact. And facts do matter in computer systems.

那是一个数据异常：关于一个事实的两个不同的断言。 事实在计算机系统中确实很重要。

范式的形式和原因 (The what and whyfors of Normal Forms)

I’ll use the term type to denote the meta data of an object. This could be implemented by a class definition, mixin, trait, stamp, or whatever mechanism your preference and language of choice supports. I’ll also be focusing on data objects, such as POJOs, PODOs, JSON and similar simple objects.

我将使用术语类型来表示对象的元数据。 这可以通过类定义， mixin ， trait ， stamp或您的偏好和选择语言支持的任何机制来实现。 我还将重点研究数据对象 ，例如POJO ， PODO ，JSON和类似的简单对象。

Stated informally, the first three normal forms are described as follows:

非正式地说，前三种普通形式描述如下 ：

First Normal Form (1NF): No repeating elements or groups of elements

第一范式(1NF)：无重复元素或元素组

First Normal Form (1NF): No repeating elements or groups of elements

第一范式(1NF)：无重复元素或元素组

Second Normal Form (2NF): All Non-key Attributes are Dependent on All of Key

第二范式(2NF)：所有非关键属性均取决于所有关键

Second Normal Form (2NF): All Non-key Attributes are Dependent on All of Key

第二范式(2NF)：所有非关键属性均取决于所有关键

That’s pretty dry reading. But applying these principles to object type definitions is actually pretty intuitive. Once you’ve internalized these rules, you won’t even think about them consciously again.

那真是枯燥的阅读。 但是将这些原理应用于对象类型定义实际上是非常直观的。 内化这些规则后，您甚至不会再有意识地考虑它们。

对象也是关系的 (Objects are relational, too)

Relational databases support associations by way of Primary and Foreign Key constraints. Hierarchies are implicit, if they exist at all. Associations are looser than hierarchies and taxonomies, but also harder to think about.

关系数据库通过主键和外键约束支持关联 。 如果层次结构完全存在，则它们是隐式的。 关联比层次结构和分类法宽松，但也很难考虑。

In a hierarchy, you have parent-child relationships. There is often a hierarchy of data types as well (class-subclass) which is also modeled. Relationships in a object containment hierarchy are more constrained, generally one-way (parent to child), but also easier to grasp than a more general (and flexible) association.

在层次结构中，您具有父子关系。 通常也有一个数据类型的层次结构(类-子类)也可以建模。 对象包含层次结构中的关系更受约束，通常是单向的(父母与孩子)，但比更一般的(且灵活的)关联更容易掌握。

1NF：无重复元素或元素组 (1NF: No repeating elements or groups of elements)

Say we have the following contact information:

说我们有以下联系信息：

Where are the repeating elements?

重复元素在哪里？

1. Name attributes: this could be considered a one-to-many relationship, where the number of names is indeterminate (such as British royalty). In practice, though, first, last, and possibly middle name are sufficient for most application domains, so there’s no real need to normalize these fields.
   名称属性：名称的数量不确定(例如英国皇室使用)时，可以认为是一对多关系。 但是，实际上，对于大多数应用程序域来说，名字，姓氏和可能的中间名就足够了，因此并不需要真正地标准化这些字段。
2. phones: The repetition of phone attributes does look like a potential problem: is two phones enough? And what if further information is later associated with the phone number, like time available?
   电话：电话属性的重复确实看起来像一个潜在的问题：两个电话够了吗？ 而且，如果以后有更多信息与电话号码关联，例如可用时间，该怎么办？
3. address lines: again, are two enough? In some countries, street addresses can be four lines long, but that’s the limit. Since they are simple strings, it’s no tragedy if one or two more address lines are added later.
   地址行：再说两个就够了吗？ 在某些国家/地区，街道地址可以是四行，但这是限制。 由于它们是简单的字符串，因此以后再添加一或两个地址线就不会造成什么悲剧。

Here’s a possible model, with Contact and Phone types:

这是一个可能的模型，具有“联系人”和“电话”类型：

2NF：所有非关键属性均取决于所有关键 (2NF: All Non-key Attributes are Dependent on All of Key)

What does this mean in plain English? In a database, it means that all columns in a row should be directly dependent on any candidate keys of that row.

普通英语是什么意思？ 在数据库中，这意味着一行中的所有列都应直接依赖于该行的任何候选键 。

So let’s take a look at Contact again:

因此，让我们再次看一下Contact：

Here the key is a generated id value, sometimes referred to as a surrogate key. Are the address attributes dependent on Contact ID? Well…

这里的密钥是生成的id值，有时也称为代理密钥。 地址属性是否取决于联系人ID？ 好…

It all depends on the domain.

这一切都取决于领域。

The six address properties are surely not attributes of the Contact, but are rather means of identifying a physical location. It is possible a contact could have many addresses, and perhaps an address has many contacts.

这六个地址属性当然不是联系人的属性，而是标识物理位置的手段。 一个联系人可能有很多地址，也许一个地址有很多联系人。

Should this be modeled as a many-to-many relationship, with some ContactAddress object type that has a Contact ID and an Address ID? It is going to depend on what is important to your application domain. Some application may treat Contacts as strong entities, independent of Address, but Addresses as weak entities, dependent on a Contact for existence. In that case, one contact can have many addresses, and each address refers to a contact, like this:

是否应该将其建模为具有联系人ID和地址ID的某些ContactAddress对象类型的多对多关系？ 这将取决于对您的应用程序域重要的内容。 某些应用程序可能会将联系人视为独立于地址的强实体，但会将地址视为弱实体，这取决于联系人的存在。 在这种情况下，一个联系人可以有多个地址，每个地址都指向一个联系人，如下所示：

There is a potential data anomaly: if you change the address for one contact, you don’t change that same address for all contacts. If Contact is your primary source of reference, then that may be the desired behavior: your contact moves (to another organization, say) and the remaining Contacts stay in place.

存在潜在的数据异常：如果更改一个联系人的地址，则不会为所有联系人更改相同的地址。 如果“联系”是您的主要参考来源，那么这可能是您想要的行为：您的联系移至(例如，移至另一个组织)，而其余“联系”保持不变。

3NF：不依赖于非关键属性 (3NF: No dependencies on non-key attributes)

Looking at Address again, you might spot the two dependent fields, region and country. A country may or may not have regions, but a region does have a country: you don’t want to mix them up.

再次查看地址，您可能会发现两个相关的字段， 地区和国家。 一个国家可能有也可能没有区域，但是一个区域确实有一个国家：您不想将它们混淆。

One way of ensuring that the region belongs to the correct country is to create an identifier for each (country, region) pair, then have the address refer to the identifier rather than to region and country independently:

确保该区域属于正确的国家/地区的一种方法是为每个(国家/地区)对创建一个标识符，然后使地址引用该标识符，而不是独立地引用区域和国家：

关于生成的标识符 (A word about generated identifiers)

In my opinion, generated identifiers are an implementation detail, and are really only needed by client code when modifying or deleting a back-end record (such as a row in a database), but never as part of a read-only query. They should also never be seen by the user of the system, because they are meaningless.

在我看来，生成的标识符是一种实现细节，实际上，只有在修改或删除后端记录(例如数据库中的一行)时，客户端代码才需要生成标识符，但绝不会将其作为只读查询的一部分。 他们也永远不会被系统的用户看到，因为它们毫无意义。

每个类型的表，每个类型的层次结构的表 (Table per Type, Table per Type Hierarchy)

The neat thing about normalized object types is that they map easily to relational database tables. For a relational database implementation, tables mirror the object types (Table per Type) or at least contain information for multiple types derived from a base type (Table per Type Hierarchy). This may sound like I’m advocating Object-Relational Mapping, but no… I am merely saying that it is beneficial to have your Logical Model share the same characteristics of the Physical Model at a conceptual level. Implementation is another subject entirely.

关于规范化对象类型的整洁之处在于它们可以轻松映射到关系数据库表。 对于关系数据库实现，表镜像对象类型( 每个类型的表 )，或者至少包含有关从基本类型派生的多个类型的信息( 每个类型层级的表 )。 听起来好像我在倡导对象关系映射 ，但是不……我只是说让您的逻辑 模型在概念上共享物理模型的相同特征是有益的 水平。 实施完全是另一个主题。

参考文献 (References)

There are ample resources about normalization of relation database schemas:

有关关系数据库模式的规范化，有很多资源：

Database Normalization: First, Second, and Third Normal Forms - Andrew RollinsI read a great explanation of first, second, and third normal form a few weeks ago. For those that know what database…www.andrewrollins.com

数据库规范化：第一，第二 和第三范式 -安德鲁·罗林斯(Andrew Rollins) 几周前，我对第一，第二和第三范式进行了很好的解释。 对于那些知道什么数据库的人…… www.andrewrollins.com

Database Second Normal Form Explained in Simple EnglishThe second post focused on the first normal form , its definition, and examples to hammer it home. Now it is time to…www.essentialsql.com

数据库第二范式用简单的英语解释 第二篇文章重点介绍了第一个范式，其定义和示例。 现在是时候... www.essentialsql.com

What is Second Normal Form (2NF)? - Definition from TechopediaSecond Normal Form 2NF Definition - Second normal form (2NF) is the second step in normalizing a database. 2NF builds…www.techopedia.com

什么是第二范式(2NF)？ -来自Techopedia的定义 第二范式2NF定义-第二范式(2NF)是规范化数据库的第二步。 2NF正在建立…… www.techopedia.com

Database Third Normal Form Explained in Simple EnglishThe third post focused on the second normal form, its definition, and examples to hammer it home. Once a table is in…www.essentialsql.com

用简单的英语解释数据库的第三范式 第三篇文章重点介绍了第二范式，其定义和示例。 表格一旦进入… www.essentialsql.com

Also, when researching this post, I came across a somewhat different take on how to apply normalization rules to object types.

此外，在研究本文时，我遇到了关于如何将规范化规则应用于对象类型的另一种看法。

Introduction to Class Normalizationwww.agiledata.org

类规范化简介 www.agiledata.org

翻译自: https://www.freecodecamp.org/news/normal-forms-arent-just-for-databases-2443741bd627/

提交表单数据到数据库