数据库设计

Question

我正在建立一个音乐流媒体网站，在那里用户将能够购买和流媒体MP3的。我有一个子集实体图，可以描述如下：

​

​

我想将数据归一化为3NF。我需要多少张桌子？显然，我希望避免包含部分依赖项，这将需要更多的表，而不仅仅是专辑、艺术家、歌曲-但我不确定还需要添加什么？从经验中有什么想法？

Answer 1

您将需要4个表:艺术家、歌曲、专辑和AlbumSongs。

最后一个是必需的，因为完全相同的歌曲(=相同的编辑/版本...)可以包含在几张专辑中，所以你有一个m-to-m的关系。

Answer 2

好吧，你已经完成了ER级别的测试。您需要先确定键和属性，然后才能计算出函数依赖。在达到3NF之前，还有大量的工作要做。例如：歌曲名称是重复的。

此外，还有一些问题：

• 是卖专辑，卖歌，还是两者都卖？(我两者都建模了)
• 如果两者都有，你如何跟踪销售或下载？
• 你关心不同艺术家录制的同一首歌吗?

无论如何，这里是一个解析的，至少对于提供的信息是这样的。它比3NF更接近5NF，但我不能这样说，因为它还不完整。

不熟悉关系数据库建模标准的读者可能会发现很有用。

它使用了一个简单的超类型-子类型结构，正交设计的原理。卖出的东西(专辑或歌曲).

请随时提出澄清的问题。

Answer 3

我同意iDevelop的观点，但需要多加一张桌子。以下是我将如何对其建模。

表格:艺术家，歌曲，专辑，AlbumSongMap，SingleInfo

如果这首歌是在不同的日期作为单曲发行的，你可以从SingleInfo上获得。这首单曲可能已经发布了一些与专辑艺术不同的封面艺术。您可以将单曲艺术存储在SingleInfo中。也许一首歌可以作为一首单曲发行多次，加上新的封面或其他东西，所以它可能是一对多的关系。否则是1-1。

如果你能用SingleInfo加入歌曲，那就意味着它是以单曲的形式发布的。如果你可以加入歌曲和专辑(使用地图)，那么你会找到所有的专辑下它的发行。

一首老歌的数字增强是一首新歌。(或者至少是一个不同的二进制文件)。您可能想要进一步标准化歌曲，以允许存储数字增强而不复制songName等。