Как разрешить несколько значений в одном столбце в таблице? - PullRequest
Новая
       26

Как разрешить несколько значений в одном столбце в таблице?

0 голосов
/ 05 февраля 2019

Мне было поручено создать базу данных по сценарию.Однако при разработке своего решения я обнаружил, что в одной ячейке будет несколько значений.Нам сказали, что это повторяющаяся группа, и ее следует избегать в базе данных.

Я получаю повторяющиеся группы, когда хочу связать песни из альбома с альбомом, в котором они находятся.Например, в альбоме может быть одна или несколько песен.Однако песня может быть в одном или нескольких альбомах (Дин Мартин - Silver Bells может быть в альбоме Christmas Hits и альбоме Дина Мартина).

Если я буду ссылаться на каждую песню в ее альбоме, я буду использовать AlbumIdв качестве внешнего ключа.Однако, если бы это было в нескольких альбомах, то у меня было бы несколько AlbumId в качестве внешнего ключа.Это дает мне повторяющуюся группу, поскольку в одной и той же ячейке будет несколько идентификаторов.

Если бы это было отменено путем сохранения всех песен альбома в сущности альбома, у меня возникла бы та же проблема, что и SongId был бы чужими каждый альбом будет иметь несколько SongId в одной и той же ячейке.

У меня есть следующие объекты:

song

и

album

Сущность песни будет содержать следующие типы атрибутов:

  • SongId (PK)
  • SongDuration
  • AlbumId (FK)
  • AudioFileSize
  • AudioFile
  • SongTitle
  • SongLyrics
  • SongNotes

Сущность альбома будет содержать следующие типы атрибутов:

  • AlbumId (PK)
  • AlbumTitle
  • NumOfTracks
  • ReleaseDate
  • ProductionLabel (FK) // Переход к другой таблице без проблем.
  • AlbumCoverImage
  • CoverImageStory
  • AmountOfCDs

Я довольно новичок в дизайне базы данных и чувствую, что хорошо его понял.Тем не менее, я озадачен, как решить эту проблему.

Если потребуется дополнительная информация о базе данных, я с радостью ее предоставлю.

Любая помощь будет принята с благодарностью.

С уважением,

Стив.

Ответы [ 2 ]

0 голосов
/ 06 февраля 2019

Нам сказали, что это повторяющаяся группа, и ее следует избегать в базе данных.

Не "избегается", но моделируется, решается.Каждый столбец должен быть атомарным:

  • 1NF: без кратных или составных значений
  • 2NF: без повторяющихся групп

Простое решение состоит в моделировании несколькихзначения в подчиненной таблице.В этом случае с двумя идентификаторами Song и Album, ассоциативной таблицей.

RecordID

Это первая и самая главная ошибка.Он наносит вред как моделированию, так и получающейся в результате «базе данных».

Для реляционной модели требуется:

  1. Ключ должен составлять ".из данных "
    (т. е. не изготовленный идентификатор; GUID; UUID; и т. д., ни один из которых не является данными)
  2. каждая строка (в отличие от записи с RecordId)в каждой таблице должны быть уникальные
    Уникальность данных не может быть получена из идентификатора;GUID;UUID;и т.д. Кроме того, глупой вещью всегда является дополнительный столбец и индекс .

Это необходимо исправить.

В-третьих, у вас есть несколько столбцов внеправильные таблицы.

Модель данных альбома

Моделирование существенно дешевле, чем использование SQL.Посмотрите, соответствует ли это требованию.Album Data Model Вместо того, чтобы идти вперед и назад, повышая скорость работы с реляционными базами данных, я решил все проблемы.Например.у вас есть несколько CD на альбом, но это не было обработано или запрошено, оно должно быть разрешено.

Также доступно в PDF .

Itотображается в IDEF1X, стандарте моделирования реляционной базы данных.Вы можете найти краткий Введение в IDEF1X полезным.

0 голосов
/ 05 февраля 2019

У вас есть отношения многие ко многим.Таким образом, вы можете использовать таблицу соединений / связей: 

create table songAlbums (
    . . .,
    songId int references songs(songId),
    albumId int references albums(albumId),
    . . .
)

Возможно, вы захотите включить другую информацию, например, положение в альбоме.Такая таблица может иметь составной первичный ключ (songId, albumId) или синтетический первичный ключ (generated always as identity).

...