当前位置：文江博客话题详情

database database-normalization

第一范式和时间数据

发布于 2024-07-13 07:58:30 字数 197 浏览 7 评论 0 原文

第一个范式表示行顺序不重要。这是否意味着以日期作为键一部分的表不是 1NF？例如考虑一个股票价格表，其中日期/时间是 PK 的一部分。在这种情况下，您可以通过按日期对数据排序并选择顶部的 1 行来获取最后的价格。这是否意味着为了满足 1NF，您需要将表拆分为： 1) TickerCurrentPrice（每个股票行情 1 行） 2) 股票历史价格谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

黑白记忆 2024-07-20 07:58:31

意思是，如果要记录数据的某些顺序（例如按日期），则应该明确记录它，例如在日期列中。错误的地方是仅按照磁盘上行的物理顺序隐式进行排序（假设您无论如何都可以控制它）。换句话说，您必须对某些列进行 ORDER BY 才能按该顺序获取数据。

回复收藏 0 原文

还不是爱你 2024-07-20 07:58:31

不，“选择...排序依据...”并不违反 1NF。违反 1NF 的行（和列）排序更多的是关于“从 XYZ 选择 *；然后选择顶部第三行和左侧第四列”的情况。是的，我见过这样的数据库设计。

回复收藏 0 原文

他夏了夏天 2024-07-20 07:58:31

不，这意味着没有内在的秩序。如果您想要最后价格的日期，则必须从表格中选择 max(date)。

回复收藏 0 原文

逆夏时光 2024-07-20 07:58:30

1NF 是表示关系的表的一个方面，而不是表本身的一个方面。

如果您的关系显示门票有价格，则这是1NF违规，因为您无法确定门票是否HAS或者通过查看单个记录没有价格。您需要获取此门票上的所有价格并选择最后一个，这违反了 1NF 的非排序规则。

如果您的关系说ticket HAD BEGUN TO COST Price ON date，那么它就在 1NF 中，因为每条记录都说明了它的内容：这个 机票的费用为此价格，从此日期开始。

因此，我们说该表在表示第一个关系时不符合1NF，但在表示第二个关系时符合1NF。

当然，桌子本身保持不变。

但这并不一定意味着您需要拆分表格。

关系数据库的全部要点是您可以使用关系运算符将一种关系转换为另一种关系。

在RDBMS 中，什么是关系？这是一个表格，显示了所有可能值之间存在这种关系的所有组合。

例如，如果我们需要对从 1 到 5 的自然数构建等式关系，我们有这样的表：

出现在该表中的所有对都是等式关系；所有没有出现的对都没有出现。我们在这里看不到 (2, 3) 或 (4, 5)，因为它们不相等。

但您不需要将整个对保留在数据库中。您保留单个值并编写一个查询：

SELECT n1.number, n2.number
FROM number n1, number n2
WHERE n1.number = n2.number

，这会给出相同的结果。

实际上，范式可以让您在数据库中保存尽可能简单的关系表，并使用SQL查询从它们构建更复杂的关系。

在您的情况下，如果您按以下方式编写查询（或定义视图）：

SELECT ticket, price
FROM mytable
WHERE (ticket, date) IN (
  SELECT ticket, MAX(date)
  FROM mytable
  GROUP BY
    ticket
  )

，您可以从 (ticket HAD BEGUN TO COST Price ON date< /code>) 就像将整个表保存在数据库中一样。

1NF is aspect of a table representing a relation, not of a table as such.

If your relation says ticket HAS price, that it's a 1NF violation, as you cannot determine if a ticket HAS or HAS NOT the price by looking on a single record. You'll need to fetch all prices on this ticket and select last of them, which violates the non-ordering rule of the 1NF.

If your relation says ticket HAD BEGUN TO COST price ON date, then it's in the 1NF all right, because each record says what it says: this ticket costs this price from this date.

Thus, we say that this table does not comply with the 1NF when representing the first relation, but does comply when representing the second one.

The table itself remains the same, of course.

It doesn't necessary mean though that you need to split your tables.

The whole point of relational databases is that you can use relational operators to convert one relation to another.

What is a relation in terms of the RDBMS? It's a table showing all combinations of all possible values that are in this relation between theirselves.

For instance, if we need to construct equality relation on natural numbers from 1 to 5, we have this table:

All pairs that appear in this table are in equality relation; all pairs that don't appear, are not. We don't see (2, 3) here, or (4, 5), as they are not equal.

But you don't need to keep the whole pair in the database. You keep single values instead and write a query:

SELECT n1.number, n2.number
FROM number n1, number n2
WHERE n1.number = n2.number

, which gives you the same result.

Actually, normal forms let you keep simplest possible relation tables in the database and construct more complex relations from them using SQL queries.

In your case, if you write a query (or define a view) in the following way:

SELECT ticket, price
FROM mytable
WHERE (ticket, date) IN (
  SELECT ticket, MAX(date)
  FROM mytable
  GROUP BY
    ticket
  )

, you get relation (ticket HAS price) from (ticket HAD BEGUN TO COST price ON date) exactly as if you were keeping the whole table in the database.