0

当前设计：

  • Gamestable : Gameid, dmy, starttime, dayplayed, weeknumber, Hometeamdivisionid, Hometeamid, Awayteamdivisionid, Awayteamid, Hometeampointsscored, Awayteampointsscored, win-loss

  • Hometeamdivisiontable : Hometeamdivisionid

  • Hometeamtable : Hometeamid

  • Awayteamdivisiontable : Awayteamdivisionid

  • Awayteamtable : Awayteamid

我需要更多的桌子，还是只需要不同的桌子？

4

1 回答 1

1

初步观察

“主队”和“客队”不需要单独的表格。想一想：你有团队；这些被组织成部门；他们玩游戏。在任何给定的比赛中，一支球队是主队，一支球队是客队，但对于不同的比赛，一支球队可以是主队或客队。给定的团队一次属于一个部门。所以你需要一个有点像这样的设计：

  • 部门：部门 ID、名称 (...)

  • Team : Team ID, Division ID, Name (...)

  • 游戏：游戏 ID、比赛日期、开始时间、主队 ID、客队 ID、主队得分、客队得分 (...)

显然，Game 表中的值存在限制，例如“Home Team ID”不等于“Away Team ID”。也可能有更复杂的限制：两支球队必须在同一个分区（如果没有跨分区比赛）。您有两个从 Game 到 Team 的外键约束。

从这些，可以计算出其他一切。您可能需要一个“日历”表来定义“周数”；这可能是确定给定比赛在赛季的哪一周进行的最简单方法：

  • 日历：日期、季节 ID、周数 (...)

如果您必须处理“A 队”在 2012 年春季在西区，但在 2012 年秋季在东区等，那么您需要更多的复杂性，但是您一次只需要记录一个赛季，所以一支球队是总是在同一个部门，那你就很好了。

现在有更多信息可用

总体目标是记录一个联赛中多个赛季的比赛。组成联赛的球队很稳定，只有两个分区，但球队可以在不同赛季（但不能在一个赛季）之间移动。

第一个必要的更改是 Team 表；现在Division ID是特定赛季球队的属性，而不是永久属性。历法问题也更为重要。

  • 季节：季节 ID (PK)、名称、开始日期、结束日期 (...)

  • 部门：部门 ID (PK)、名称 (...)

  • Team : Team ID (PK), Name (...) (这里没有Division ID)

  • SeasonDivisionTeam : Season ID, Division ID, Team ID（PK都是三个属性）

  • 游戏：游戏 ID (PK)、比赛日期、开始时间、主队 ID、客队 ID、主队得分、客队得分、场地 ID、(...)

  • 日历：日期 (PK)、季节 ID、周数 (...)

SeasonDivisionTeam这个名字不好；不过，我在一个更好的名字上画了一个空白。它基本上定义了每个赛季每个分区的球队。这是一个“全键”表，具有三个单独的外键。季节表（及其开始和结束日期）和日历表之间存在约束。日历表中为特定季节指定的日期不得超出季节表中为同一季节指定的日期范围。或者，您可以从季节表中删除季节日期，并让日历表定义有效的日期范围。

您最终可能会得到一些汇总主要操作表中数据的统计表。例如，计算特定日期的部门排名是可行的，但计算成本适中。您可能有一个用于记录“赛季末”排名的汇总表。如果你愿意，你可以在每个周末都有条目。

我不确定季后赛最好做什么。游戏桌能够记录原始数据。您可能想要添加一个 Venue 列来记录游戏在哪里进行。由于这是一个初级赛区，我可以想象你会在赛季结束的一两天内举办一场淘汰赛——或者可能是一场分循环赛和淘汰赛阶段的分级赛。在这种情况下，您可能在短时间内玩了一系列游戏。或者您可能会更频繁地间隔游戏。Games 表的结构可以记录任何这些变化。但是，您可能会发现设计一个表格来定义季后赛的结构是明智的。最有效的方法可能取决于季后赛组织的稳定性。为此，需要更多信息。但是，对于录制游戏的简单问题，概述的游戏桌没有问题。问题是人类如何赋予季后赛意义。

于 2013-03-24T14:59:48.740 回答