Теория и практика построения баз данных (1088289), страница 42
Текст из файла (страница 42)
5.1. Если С и О имеют связь Х:1, они могут находиться вместе в отношении 5. С будет определять О, но 0 не будет определять С. Ключом отношения 5 будет атрибут С. Другой атрибут, Е, может быть добавлен в отношение 5, только если С определяет Е. Атрибутивная связь «многие ко многим» Если А не определяет В, а В не определяет А, то между значениями этих атрибутов имеется связь «многие ко многим» (п1апу-то-тану ге1ат1опзЫр). В примере )Ч«2 атрибуты ИмяСотрудниха и Предмет имеют связь «многие ко иногим».
Один преподаватель ведет много предметов, а один н тот же предмет ведется многими преподавателями. В связи «многие ко многим» оба атрибута должны быть ключами отношения. Например, ключом отношения ПОДГОТОВКА из примера )Чя 2 является комбинация (ИмяСотрудника, Предмет), При построении отношений, у которых ключами являются несколько атрибутов, можно добавлять новые атрибуты, которые функционально зависят от всего ключа. Атрибут КояичествоЧасов функционально зависит от каждого нз атрибутов в сочетании (ИмяСотруднина, Предмет) и поэтому может быть добавлен в отношение.
Атрибут Должность в данное отношение добавить нельзя, потому что он зависит только от атрибута ИмяСотрудника, но не от атрибута Предмет. Если требуется хранить атрибут Должность в базе данных, его следует добавить в отношение, содержащее информацию о профессорско-преподавательском составе, а не о подготовке. Эти высказывания приведены в правом столбце табл. 5.1. Если атрибуты Е и Г имеют связь М:Х, то Е пе определяет Г, а Г нс определяет Е. Оба зти атрибута можно поместить в отношение Т, и в этом случае ключом отношения Т будет комбинация (Е, Г). Новый атрибут 6 может быть добавлен в отношение Т, если он определяется обоими атрибутаии из сочетания (Е, Г). Атрибут В нельзя добавить в отношение Т, если он определяется только одним из атрибутов в комбинации (Е, Г).
Рассмотрим аналогичный пример. Предположим, мы хотим добавить в отношение ПОДГОТОВКА атрибут НомерАудитории. Определяется ли НомерАудитории ключом отношения ПОДГОТОВКА комбинацией (ИмяСотрудника, Предмет)? Скорее всего нет, поскольку преподаватель может вести один и тот же предмет в различных аудиториях. Сочетание (ИмяСотрудника, Предмет) и атрибут НомерАудитории имеют связь М:Х.
Раз это так, можно применить правила приведенные в табл. 5.1, но здесь роль Е будет играть сочетание (ИмяСотрудника, Предмет), а роль à — атрибут Номер- Аудитории. Теперь мы можем построить новое отношение Т с атрибутами ИмяСотрудникз, Предмет и НомерАудитории. Ключом этого отношения будет комбинация (ИмяСотрудника, Предмет, НомерАудитории). В этой ситуации получается, что мы создали новое отношение с новой темой.
Рассмотрим отношение Т, содержащее сведения об именах преподавателей, предметах и номерах аудиторий. Темой этого отношения больше не является ПОДГОТОВКА; скорее эту тему можно было бы сформулировать так; КТО-ЧТО-И-ГДЕ-ПРЕПОДАЕТ. Изменение темы может быть как уместным, так и неуместным.
Если НомерАУ- дитории является значимым атрибутом, тема действительно должна быть изменена. В этом случае отношение ПОДГОТОВКА не подходит, и более уместной является тема КТО-ЧТО-И-ГДЕ-ПРЕПОДАЕТ. С другой стороны, в зависимости от требований пользователей, отношение ПОДГОТОВКА может быть пригодным в том виде, в каком оно есть. В таком случае, если атрибут НомерАудитории все же должен храниться в базе данных, его следует поместить в другое отношение — например, СЕКЦИЯ-НОМЕР, ПРЕДМЕТ-СЕКЦИЯ или что-нибудь наподобие этого. Многозначные зависимости: часть вторая Изложенные выше соображения, касающиеся атрибутпвной связи «многие ко многим», могут сделать концепцию многозначных зависимостей более простой для понимания. Проблема с отношением СТУДЕНТ (НомерСтудента, Специальность, Секция) на рис.
5.9 состоит в том, что в нем имеется две различных связи вида «многие ко мпогимси одна между атрибутами НомерСтудента и Специальность, а другая — между атрибутами НомерСтудента и Секция. Ясно, что специализации студента не имеют никакого отношения к секциям, в которых он занимается. Однако сели обе связи присутству|от в одном отношении, возникает впечатление, что между этими атрибутами существует какая-то взаимосвязь. Атрибуты Специальность и Секция независимы, и никакой проблемы не возникло бы, если бы студент мог специализироваться только в одной области и занима1ься только в одной секции. Тогда НомерСтудента функционально определял бы атрибуты Специальность и Секция, и отношение находилось бы в ДКНФ.
В этом случае связь каждого из этих атрибутов с атрибутом НомерСтудента имела бы вид «многие к одному>. Другой способ представить себе возникающее затруднение состоит в исследовании ключа (НомерСтудента, Специальность, Секция). Поскольку в отношении СТУДЕНТ имеются связи вида «многие ко многим>, ключ должен содержать в себе каждый из атрибутов. Теперь спросим себя: а какую тему представляет данный ключ? Мы можем сказать, что это комбинация специальности студента и по<ещаемых им секций.
Но такая комбинация не одна, их множество. Одна строка этого отношения описывает только часть комбинации, и чтобы получить 196 Глава 5, Реляционная модель и нормализация Оптимизация 197 всю картину, нам нужны все строки, содержащие информацию о конкретном студен~с. Вообгцв говоря, строка отношения долж>са содержать всв данные, описываюгиив отдельный экземпляр тььны данного от~юшеиия Например, строка Покупатель должна содержать все нужные нам данные о конкретном покупателе. Рассмотрим отношение ПОДГОТОВКА из примера гэ 2 в разделе, посвященном доменно-ключевой нормальной форме. Ключом этого отношения является комбинация (ИмяСотрудника, Предмет). Тема состоит в том, что конкретный преподаватель имеет подготовку, достаточную для ведения определенного предмета.
Нам нужна только одна строка этого отношения, чтобы получить всю требуемую информацию о комбинации данного профессора и данного предмета (в отношение могут входить такие атрибуты, как КопнчествоЧасов, СредняяОценкаКурса и т. д,). Глядя на другие строки, мы не получим никакой дополнительной информации на эту тему. Как вы знаете, решение проблемы многозначных зависимостей заключается в том, чтобы разбить исходное отношение на два новых, каждое из которых будет иметь только одну тему.
В отношении СТУДЕНТ-СПЕЦИАЛЬНОСТЬ представлены комбинации студентов и специальностей. Все, что мы знаем о каждой из таких комбинаций, содержится в одной строке, и мы не получим какой-либо дополнительной информации о данной комбинапии, исследуя другие строки. Оптимизация В этой главе мы исследовали концепцию нормализации и продемонстрировали, как создавать таблицы в домснно-ключевой нормальной форме. Использовавшийся нами метод припзден для большинства случаев, однако иногда результат нормализации не стоит затраченных усилий. В последнем разделе главы мы рассмотрим две ситуации, в которых это может случиться.
Де нормализация Как уже говорилось, нормализованные отношения свободны от аномалий модификации, и по этой причине они являются более предпочтительными, чем ненормализованные отношения. Но если судить с других позиций, иногда нормализация не стоит того, чтобы ее проводить. Расс мотрим отношение КЛИЕНТ (НомерКпиента, ИмяКпнента, Город, Штат, Индекс), где ключом является НомерКпкента. Это отношение не находится в ДКНФ, поскольку в нем имеется функциональная зависимость Индекс» (Город, Штат), которая не следует из ключа — атрибута НомерКпнента. Следовательно, мы имеем ограничение, не являющееся следствием определения ключей. Данное отношение может быть преобразовано в два отношения следующего вида: КЛИЕНТ (НомерКпиента, ИмяКпнента, Индекс), где ключом является НомерКпиента, и ИНДЕКСЫ (Индекс, Город, Штат), где ключом является Индекс. Эти два отно- щения находятся в доменно-ключевой нормальной форме, но они, скорее всего, пе представляют собой более удачного решения по сравнению с исходной таблицей.
Возможно, что ненормализованная таблица лучше, поскольку ее будет легче обрабатывать, а неудобства, связанные с дублированием данных о городе и штатс, не столь существенны. В качестве второго примера рассмотрим отношение КОЛЛЕДЖ (НазваниеКоппеджа, Декан, ЗаместитепьДекана). Эта таблица не находится в доменно-ключевой нормальной форме, так как ограничение НазваннеКоппеджа» Декан не является логическим следствием ключа таблицы. Отношение КОЛЛЕДЖ можно нормализовать, разбив его на два отношения: ДЕКАН (НазваниеКоппеджа, Декан) и ЗАМДЕКАНА (НазваниеКоппеджа, ЗаместитепьДекана).
Однако теперь, когда приложению базы данных нужно будет получить данные о колледже, ему придется прочитать минимум две, а возможно, и все четыре < троки данных. В качестве альтернативы можно поместить всех трех заместителей декана в таблицу КОЛЛЕДЖ, выделив для каждого индивидуальный атрибут. Нолучившаяся таблица имела бы следующий вкд: КОЛЛЕДЖ1 (НазваниеКоппеджа, Декан, ЗаместнтепьДекана1, ЗаместнтепьДекана2, ЗаместитепьДеканаЗ).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
