如何解析 table 中一列中的多个值？
How to resolve multiple values in one column in a table?
我的任务是根据场景设计数据库。然而，在设计我的解决方案时，我发现我会在一个单元格中有多个值。我们被告知这是一个重复组，应避免在数据库中使用。
当我想 link 专辑中的歌曲到它们所在的专辑时，我得到了重复组。例如，专辑中可以有一首或多首歌曲。但是，一首歌可能出现在一张或多张专辑中（Dean Martin - Silver Bells 可能出现在一张 Christmas Hits 专辑和一张 Dean Martin 专辑中）。
如果我将每首歌曲引用到它的专辑，我会使用 AlbumId 作为外键。但是，如果它在多个专辑中，那么我将有多个 AlbumId 作为外键。这给了我一个重复组，因为在同一个单元格中会有多个 ID。
如果通过将专辑的所有歌曲存储在 Album 实体中来扭转这种情况，我会遇到同样的问题，因为 SongId 将是一个外键，并且每个专辑将在同一个单元格中有多个 SongId。
我的设计包括以下实体：
song
和
album
歌曲实体将包含以下属性类型：
- SongId (PK)
- SongDuration
- AlbumId (FK)
- AudioFileSize
- AudioFile
- SongTitle
- SongLyrics
- SongNotes
相册实体将包含以下属性类型：
- AlbumId (PK)
- AlbumTitle
- NumOfTracks
- ReleaseDate
- ProductionLabel (FK) //Goes to another table that has no issues.
- AlbumCoverImage
- CoverImageStory
- AmountOfCDs
我是数据库设计的新手，感觉自己掌握得很好。但是，我很困惑如何解决这个问题。
如果需要有关数据库的更多信息，我很乐意提供。
非常感谢任何帮助。
此致，
史蒂夫
你有一个多对多的关系。所以，你可以使用 junction/association table:
create table songAlbums (
. . .,
songId int references songs(songId),
albumId int references albums(albumId),
. . .
)
您可能想要包含其他信息，例如在相册中的位置。这样的 table 可能具有复合主键 (songId, albumId) 或合成主键 (generated always as identity)。
We were told this is a repeating group and should be avoided in a database.
不是“避免”，而是建模、解决。每列必须是原子的：
- 1NF: 没有多重或复合值
- 2NF：无重复组
简单的解决方案是在下属 table 中对多个值进行建模。在这种情况下，有两个标识符 Song 和 Album，一个关联 table.
RecordID
这是首要的错误。它削弱了建模练习和由此产生的“数据库”。
关系模型需要：
- 密钥必须“由数据组成”
（即不是制造的 ID；GUID；UUID 等，none 其中是数据）
- 每个 table 中的每一行（与带有
RecordId 的记录不同）必须是唯一的
无法从 ID 获得数据唯一性；图形标识符；唯一标识符；等等。此外，愚蠢的事情总是附加列和索引。
需要更正。
第三，你有一些列在错误的 tables.
专辑数据模型
建模比尝试 SQL 便宜得多。看看这是否满足要求。
我已经解决了所有问题，而不是来回让您加快使用关系数据库的速度。例如。您每个专辑有多个 CD，但没有处理或请求，必须解决。
也可用于 PDF。
它在 IDEF1X 中呈现，IDEF1X 是关系数据库建模的标准。您可能会发现简短的 Introduction to IDEF1X 很有帮助。
我的任务是根据场景设计数据库。然而，在设计我的解决方案时，我发现我会在一个单元格中有多个值。我们被告知这是一个重复组，应避免在数据库中使用。
当我想 link 专辑中的歌曲到它们所在的专辑时，我得到了重复组。例如，专辑中可以有一首或多首歌曲。但是，一首歌可能出现在一张或多张专辑中（Dean Martin - Silver Bells 可能出现在一张 Christmas Hits 专辑和一张 Dean Martin 专辑中）。
如果我将每首歌曲引用到它的专辑，我会使用 AlbumId 作为外键。但是，如果它在多个专辑中，那么我将有多个 AlbumId 作为外键。这给了我一个重复组，因为在同一个单元格中会有多个 ID。
如果通过将专辑的所有歌曲存储在 Album 实体中来扭转这种情况，我会遇到同样的问题，因为 SongId 将是一个外键，并且每个专辑将在同一个单元格中有多个 SongId。
我的设计包括以下实体：
song
和
album
歌曲实体将包含以下属性类型：
- SongId (PK)
- SongDuration
- AlbumId (FK)
- AudioFileSize
- AudioFile
- SongTitle
- SongLyrics
- SongNotes
相册实体将包含以下属性类型：
- AlbumId (PK)
- AlbumTitle
- NumOfTracks
- ReleaseDate
- ProductionLabel (FK) //Goes to another table that has no issues.
- AlbumCoverImage
- CoverImageStory
- AmountOfCDs
我是数据库设计的新手，感觉自己掌握得很好。但是，我很困惑如何解决这个问题。
如果需要有关数据库的更多信息，我很乐意提供。
非常感谢任何帮助。
此致，
史蒂夫
你有一个多对多的关系。所以，你可以使用 junction/association table:
create table songAlbums (
. . .,
songId int references songs(songId),
albumId int references albums(albumId),
. . .
)
您可能想要包含其他信息，例如在相册中的位置。这样的 table 可能具有复合主键 (songId, albumId) 或合成主键 (generated always as identity)。
We were told this is a repeating group and should be avoided in a database.
不是“避免”，而是建模、解决。每列必须是原子的：
- 1NF: 没有多重或复合值
- 2NF：无重复组
简单的解决方案是在下属 table 中对多个值进行建模。在这种情况下，有两个标识符 Song 和 Album，一个关联 table.
RecordID
这是首要的错误。它削弱了建模练习和由此产生的“数据库”。
关系模型需要：
- 密钥必须“由数据组成”
（即不是制造的 ID；GUID；UUID 等，none 其中是数据） - 每个 table 中的每一行（与带有
RecordId的记录不同）必须是唯一的
无法从 ID 获得数据唯一性；图形标识符；唯一标识符；等等。此外，愚蠢的事情总是附加列和索引。
需要更正。
第三，你有一些列在错误的 tables.
专辑数据模型
建模比尝试 SQL 便宜得多。看看这是否满足要求。
也可用于 PDF。
它在 IDEF1X 中呈现，IDEF1X 是关系数据库建模的标准。您可能会发现简短的 Introduction to IDEF1X 很有帮助。