Почему спецификации для этой базы данных используют агрегацию вместо атрибутов на объекте?
Я пытаюсь лучше понять разработку схемы базы данных. Изучив решение проблемы, над которой я работаю, я не понимаю, почему решение решает использовать агрегирование для атрибутов "адрес" и "номер телефона" для данного "музыканта". Вот спецификации, меня интересует только пункт 1:
- Each musician that records at Notown has an SSN, a name, an address, and a phone
number. Poorly paid musicians often share the same address, and no address has more
than one phone.
- Each instrument used in songs recorded at Notown has a name (e.g., guitar, synthesizer,
flute) and a musical key (e.g., C, B-flat, E-flat).
- Each album recorded on the Notown label has a title, a copyright date, a format (e.g.,
CD or MC), and an album identifier.
- Each song recorded at Notown has a title and an author.
- Each musician may play several instruments, and a given instrument may be played by
several musicians.
- Each album has a number of songs on it, but no song may appear on more than one
album.
- Each song is performed by one or more musicians, and a musician may perform a number
of songs.
- Each album has exactly one musician who acts as its producer. A musician may produce
several albums, of course.
Вот решение, которое я нашел: http://oi67.tinypic.com/nfmovk.jpg
Диаграмма ER, которую я создал, выглядит почти точно так же, за исключением того факта, что я присвоил атрибуты "адрес" и "номер телефона" слова "музыкант" вместо того, чтобы дать каждому из них собственный набор сущностей, создавая отношения и поворачивая это в совокупность. Я не понимаю, почему это будет сделано в этой ситуации. Кто-нибудь может объяснить?? Спасибо!
2 ответа
Я не могу видеть изображение, с которым вы связаны, но в любом случае...
ни один адрес не имеет более одного телефона
Это означает, что мы должны сделать номер телефона атрибутом адреса - если только мы не хотим разрешить использование нескольких телефонов на один адрес в будущем.
Так что было бы не совсем неправильно делать телефоны за столом. Но тогда мы мало знаем о будущем. Будет ли несколько музыкантов, имеющих один и тот же адрес и один и тот же телефон? (Т.е. номер телефона будет связан с адресом.) Или будет несколько музыкантов, имеющих один и тот же адрес, но у каждого будет свой телефон? (Т.е. номер телефона будет связан с музыкантом. Однако использовать телефонный стол и связывать телефоны с музыкантами необходимо только в том случае, если у музыканта может быть несколько телефонных номеров. В противном случае мы все равно не создали бы телефонный стол, а лучше сделать телефон атрибутом музыканта.)
плохо оплачиваемые музыканты часто имеют один и тот же адрес
Это означает, что мы делаем адрес собственной таблицей. Таким образом, в случае изменения номера телефона или какого-либо другого атрибута можно изменить только одну строку. Если бы вместо этого мы сделали адресный номер атрибутом музыканта, мы бы сохранили адрес избыточно и могли получать противоречивые данные (например, один и тот же адрес, но разные телефонные номера).
Возможная модель данных:
- адрес (address_id, улица, город, телефон, ...)
- музыкант (musician_id, ssn, name, address_id, ...)
Это отношение 1:n. У музыканта есть один адрес; адрес может принадлежать нескольким музыкантам.
Основная цель нормализации базы данных состоит в том, чтобы затруднить попадание аномальных данных в базу данных. Читая первый пункт, мы видим, что каждый адрес может иметь ноль или один номер телефона, связанный с ним. Другими словами, номер телефона является атрибутом / идентифицированным по адресу. Какой уровень нормализации это нарушает?
Чтобы проиллюстрировать, как ненормировка полей адреса (включая номер телефона) увеличивает вероятность аномальных данных, предположим, что по этому адресу у вас осталось четыре ученика. Это означает, что у вас есть четыре строки, в которых существуют адресные данные. Предположим, номер телефона изменится. Вы должны убедиться, что вы изменили все четыре версии данных. Я сказал, что было четыре ученика, но предположим, что на самом деле их пять, и я просто пропустил одного? Или предположим, что вы нашли только три, когда пошли вносить изменения? Адрес может содержать не более одного номера телефона, однако теперь у вас есть несколько копий одного и того же адреса, но с разными номерами телефонов. Это аномальные данные.
Если эти данные нормализуются, у вас будет только одна копия для изменения. Поскольку на эти данные ссылаются все студенты, которые там живут, независимо от того, сколько их, это изменение "распространяется" на всех них. Целостность данных сохраняется.