Почему спецификации для этой базы данных используют агрегацию вместо атрибутов на объекте?

Question

Я пытаюсь лучше понять проектирование схемы базы данных.Изучив решение проблемы, над которой я работаю, я не понимаю, почему решение решает использовать агрегирование для атрибутов «адрес» и «номер телефона» для данного «музыканта».Вот спецификации, меня интересует только пункт 1:

• У каждого музыканта, который записывается в Notown, есть SSN, имя, адрес и номер телефона.Плохо оплачиваемые музыканты часто используют один и тот же адрес, и ни один адрес не имеет более одного телефона.

• У каждого инструмента, используемого в песнях, записанных в Notown, есть имя (например, гитара, синтезатор, флейта)и музыкальный ключ (например, C, B-flat, E-flat).

• Каждый альбом, записанный на лейбле Notown, имеет название, дату авторского права, формат (например,CD или MC) и идентификатор альбома.

• Каждая песня, записанная в Notown, имеет название и автора.

• Каждый музыкант может игратьнесколько инструментов, и на данном инструменте могут играть несколько музыкантов.

• В каждом альбоме есть несколько песен, но ни одна песня не может появиться более чем на одном альбоме.

• Каждая песня исполняется одним или несколькими музыкантами, и музыкант может исполнить несколько песен.

• В каждом альбоме есть ровно один музыкант, который действует какего производитель.Конечно, музыкант может создать несколько альбомов.

Вот решение, которое я нашел:

Диаграмма ER, которую я создал, выглядит почти точно так же, за исключением того факта, что я присвоил атрибуты "адрес" и "номер телефона" слова "музыкант" вместо того, чтобы дать каждому из них собственный набор сущностей, создав отношения ипревращая его в совокупность.Я не понимаю, почему это будет сделано в этой ситуации.Кто-нибудь может объяснить ??Спасибо!

Answer 1

Основная цель нормализации базы данных состоит в том, чтобы затруднить попадание аномальных данных в базу данных.Читая первый пункт, мы видим, что каждый адрес может иметь ноль или один номер телефона, связанный с ним.Другими словами, номер телефона является атрибутом / идентифицированным по адресу.Какой уровень нормализации это нарушает?

Чтобы проиллюстрировать, как не нормализация полей адреса (включая номер телефона) увеличивает вероятность аномальных данных, скажем, у вас по этому адресу остаются четыре студента.Это означает, что у вас есть четыре строки, в которых существуют адресные данные.Предположим, номер телефона изменится.Вы должны убедиться, что вы изменили все четыре версии данных.Я сказал, что было четыре ученика, но предположим, что на самом деле их пять, и я просто пропустил одного?Или предположим, что вы нашли только три, когда пошли вносить изменения?Адрес может содержать не более одного номера телефона, однако теперь у вас есть несколько копий одного и того же адреса, но с разными номерами телефонов.Это аномальные данные.

Если эти данные нормализованы, вам нужно будет изменить только одну копию.Поскольку на эти данные ссылаются все студенты, которые там живут, независимо от того, сколько их, это изменение «распространяется» на всех них.Целостность данных сохраняется.

Answer 2

Я не могу видеть изображение, на которое вы ссылаетесь, но в любом случае ...

ни один адрес не имеет более одного телефона

Это означает, что мы должны сделать номер телефона атрибутомадреса - если мы не хотим разрешить использование нескольких телефонов на один адрес в будущем.

Так что было бы не совсем неправильно составлять телефоны за столом.Но тогда мы мало знаем о будущем.Будет ли несколько музыкантов с одним и тем же адресом и одинаковыми телефонами?(Т.е. номер телефона будет связан с адресом.) Или будет несколько музыкантов, имеющих один и тот же адрес, но у каждого будет свой телефон?(Т.е. номер телефона будет связан с музыкантом. Однако использовать телефонный стол и связывать телефоны с музыкантами необходимо только в том случае, если у музыканта может быть несколько телефонных номеров. В противном случае мы все равно не создали бы телефонный стол,но лучше сделать телефон атрибутом музыканта.)

плохо оплачиваемые музыканты часто используют один и тот же адрес

Это означает, что мы делаем адрес своей собственной таблицей.Таким образом, в случае изменения номера телефона или какого-либо другого атрибута можно изменить только одну строку.Если бы мы вместо этого сделали адресный номер атрибутом музыканта, мы бы сохранили адрес избыточно и могли получить противоречивые данные (например, тот же адрес, но разные телефонные номера).

Возможная модель данных:

• адрес (address_id, улица, город, телефон, ...)
• музыкант (musician_id, ssn, имя, address_id, ...)

ЭтоОтношение 1: n.У музыканта есть один адрес;адрес может принадлежать нескольким музыкантам.