这样的数据库是规范化的吗？

Question

考虑这样一个数据库

显影剂表

+--------------+------+---------+
| developer_id | name | revenue |
+--------------+------+---------+
| 1            | John | 154,01  |
+--------------+------+---------+

申请表

+--------------+------------------+-------+-------------+
| developer_id | application_name | price | sold_copies |
+--------------+------------------+-------+-------------+
| 1            | photo_app_1      | 0,79  | 123         |
+--------------+------------------+-------+-------------+
| 2            | photo_app_2      | 1,99  | 34          |
+--------------+------------------+-------+-------------+

所以数据库：

• 有一个开发人员与许多应用程序的关系
• 开发商的收入来自price * sold_copies所有应用程序的总和

这个数据库是规范化的吗？如果不是，它违反了哪种范式？

Answer 1

在我看来，它违反了第二个 NF：

如果更新售出的副本数量，则必须更新所有相关开发人员的收入。现在想象你在哪里更新价格..

让我们保持Developer桌子原样。

减少 Application

id | application_name 
---+------------------
 1 | photo_app_1       

为应用程序开发人员创建参考表

 application_id  |  developer_id
-----------------+---------------
              1  |           1
              1  |           2

这就是多个开发人员参与开发同一个应用程序的方式。现在是价格：通常，您会为每个售出的副本持有收据（这对会计很有趣，但在价格发生变化时也很有趣），并且您需要一个应用程序价格本身的表格。

 application_id  | price  | date
-----------------+--------+-----------
              1  |   0.79 | 2020-05-12
              1  |   0.55 | 2020-05-13

收据表：

 id |   date     | application | copies
----+------------+-------------+-------
 1  | 2020-05-12 |           1 |      1
 2  | 2020-05-13 |           1 |      1  

使用这些表，您可以计算应用程序 1 的总收入： 查找应用程序 1 的所有销售额，检查特定日期每个已售副本的价格，并计算该应用程序的每个开发人员的收入。

最后，您可以计算开发人员的所有应用程序总共赚了多少钱。

第二个NF：

“如果一个关系在 1NF 中并且每个非键属性在功能上完全依赖于主键，那么它就是第二范式。” ( --> 在这里阅读更多) 意思是，数据库中的任何“功能”值都应该有它自己的 id（它自己的表）。

这就是为什么我们为每个应用程序的价格（在特定日期）创建一个表，为任何应用程序的每次销售创建一个表，并为参与应用程序开发的每个开发人员创建一个表。

对不起，如果我不能更好地解释它。我了解 NF 的确切规格已经有一段时间了；)