Database design 行程时刻表数据库设计

我正在研究旅行时间表系统。特定目的地至少有三（3）个出发时间。这些出发时间因日期类型（高峰或非高峰）而异。以下是我当前设计的说明：

离店表

目的地|时间1 |时间2 |时间3 |天|类型 -->所需输出将显示在如下表格中：

routeABC | 6:30 | 6:45 | 6:50 | peak
routeABC | 6:40 | 7:00 | 8:45 | non-peak
routeXYZ | 7:00 | 7:30 | 7:40 | peak

---

请问，它是否通过1NF测试（我怀疑是因为重复的列名）

这可能是一个比你所希望的答案更多的答案

你的产出

routeABC | 6:30 | 6:45 | 6:50 | peak

包含比您想象的更多的信息

运输系统由车站、车辆、出发时间、路线和路线出发时间组成

站 我们先去车站吧。我们将创建一个Station表

Station
-------
Station ID
Station Name
Station Address
...

通常，表名是单数的。Station ID是一个无意义的数字，通常是一个自动递增的整数，用于在内部标识表中的行。这个的另一个名字是盲键。Station ID是Station表的主键

Station
-------
Station ID
Station Name
Station Address
...

Station表中的所有信息都与Station有关。这是第三范式。判断一张桌子是否处于第三范式的简捷方法是问你自己这个问题

数据是否与密钥、整个密钥以及除密钥以外的所有内容相关，请帮助我确定密码

关键是第一范式

整个键是第二范式

只不过关键是第三范式

车辆 接下来，我们将查看车辆表

Vehicle
-------
Vehicle ID
Vehicle Type (Bus, Light Rail, Heavy Rail, etc.)
Vehicle VIN
Vehicle License Plate
...

车辆ID是主键。这是一个自动递增的整数。它可以与我们前面提到的站点ID具有相同的值。但是，这些相同的值表示数据库中的不同行

出发时间 每个车站有一个或多个发车时间。在你的问题中，你提到了3次出发时间。通过规范化数据库，您可以允许3次以上的离开时间

让我们看一下出发时刻表

Departure Time
--------------
Departure Time ID
Departure Time Stamp.
Station ID

主键是出发时间ID，一个自动递增的整数。对于不同的出发时间戳，可以重复相同的车站ID。该表还将有一个索引（站点ID、出发时间戳）

路线 我们已经创建了三个表：车站、车辆和出发时间。这些表称为域表，因为它们描述域中的对象。车站和车辆是实物。出发时间不是物理的，但它仍然是一个对象

让我们看一看路由表

Route
-----
Route ID
Vehicle ID
Route Type (Peak, Non-peak, etc.)

路由ID是主键，是一个自动递增的整数。Vehicle ID是车辆表中的盲钥匙。使用盲键，我们创建了从路由表到车辆表的关系

Vehicle
-------
Vehicle ID
Vehicle Type (Bus, Light Rail, Heavy Rail, etc.)
Vehicle VIN
Vehicle License Plate
...

一条路线只有一辆车。路线有一种类型

航线出发时间 一条路线有一个或多个出发时间

让我们看一下路线出发表

Route Departure Table
---------------------
Route ID
Departure Time ID
Departure Time Sequence

主键是（路线ID、出发时间顺序）。我们需要两列来创建唯一的主键

路由ID是路由表中的盲密钥

出发时间ID是出发时间表中的盲键

出发时间序列是一个整数，排序后按顺序给出出发时间。这是因为一条路线可以超过午夜

结论

---

我希望你不要认为这是一个过于复杂的解决方案。我们规范化数据库的原因是为了不复制数据，我们可以混合和匹配数据以获得不同的输出。公交车司机的日程安排看起来不同，也不同于公交车司机的日程安排。

从我的角度来看，你的目标不是很明确，但我有一个一般性的意见——不要将你的表格设计成与期望的结果完全一样。根据我的经验，这是一个非常糟糕的主意。您有SQL，因此可以随心所欲地传输数据。另外，今天的显示要求是一个，明天可以更改-您不能每次都更改数据库设计。感谢@Bogdanov的快速回复。我的问题是，我当前的表格设计是否合适？。使用当前的设计，我得到了期望的结果，但是时间1，时间2。。专栏似乎是重复的群体内容。如果你认为这不是一个好的建议，我正在寻找一个合适的设计建议。设计取决于“整体”。描述数据库的所有元素。考虑期望的结果-您需要存储什么样的数据，需要什么样的结果并进行设计。我无法判断设计是否正确，因为我没有关于其他数据和应用规则的信息。一般来说，你有很多选择。如果需要速度，您可以对表进行非规范化以显示重复信息，或者可以每次扩展所需的数据以获得更易于管理的数据库。即使你提供了具体的数据，这个问题也有点宽泛。主席先生，数据库和我刚才描述的表格一样简单。我只想存储有关路线和出发时间的信息。没有遗漏任何信息。我制作的程序只是将这些信息拉出来并显示在一张桌子上。这真的不是一个大项目。希望你能理解。对不起。在这种情况下，你从这个表中提取数据的应用程序只有这个表，这听起来对我很好。正如我在本例中告诉您的，您已经取消了表的规格。您将在此表中存储多少条记录？一般来说，这么简单的应用程序设计并不是一个大问题。谢谢您的投入。当我准备大干一场时，我一定会考虑你的建议。现在，我只是在制定一个时间表，而不是一个完整的交通系统。再次感谢你。