Теория и практика построения баз данных (1088289), страница 36
Текст из файла (страница 36)
Тогда комбинация (НомерСтудента, Секция) может уникальным образом определить строку отношения и, следовательно, эта комбинация является ключом данного отношения. Если бы пользователи указали, что должны также храниться записи о секциях, которые посещались в прошлом, то отношение на рис. 5.3 имело бы дублируюшиеся строки, Поскольку это недопустимо по определению отношения, нам пришлось бы добавить другие атрибуты, например атрибут Дата. Это приводит нас к важному заключению. Каждое отношение имеет минимум один ключ.
Это утверждение должно быть верным, поскольку ни одна отношение не может иметь одинаковых строк, и, следовательно, в крайнем случае ключ будет состоять из всех атрибутов отношения. Функциональные зависимости, ключи и уникальность У многих студентов возникает путаница с понятиями функиональной зависимости, ключа и уникальности. Чтобы избежать атой путаницы, уясните себе следуюшее: детерминант функциональной зависимости может в отношении быть уникальным или неуникальным. Если нам известно, что А определяет В и что А и В находятся в одном и том же отношении, мы все равно не знаем, является ли А уникальным в этом отношении.
Мы знаем только то, что А определяет В. Например, в отношении СЕКЦИИ атрибут Секция функционально определяет атрибут Плата, но название конкретной секции может, тем не менее, фигурировать в нескольких строках отношения. Функциональная зависимость говорит 172 Глава 5. Реляционная модель и нормализация Нормализацця 173 только о том, что везде, где атрибуту Секция сопутствует атрибут Плата, конкретному значению атрибута Секция всегда соответствует одно и то же значение атрибута Плата. То есть абонемент в секцию лыж всегда стоит $200, независимо от того, сколько раз секция лыж фигурирует в таблице.
В отличие от летерминантав, ключи всегда являкктся уникальными. Клккч функционально определяет целую строку. Если бы значения ключей дублировались, дублировался бы п весь кортеж. Но это недопустимо, поскольку по определению строки в отношении должны быть уникальными. Таким образом, когда мы говорим, что атрибут (или комбинация атрибутов) является ключом, мы знаем, что этот атрибут или комбинация будут уникальными. Например, если сочетание (НоиерСтудента, Секция) является ключом, то сочетание (100, Лыжи) может появиться в таблице только одни раз.
Чтобы проверить, как вы усвоили эти понятия, попытайтесь объяснить, почему в отношении СЕКЦИЯ (см. рпс. 5.3) НомерСтудента янляется и детерминантам, и ключом, а Секция является только детерминантам, но не ключом. (Имейте в виду, что отношение на рис. 5.3 отражает политику, когда студентам не разрешается одновременно посещать более одной секции.) Нормализация К сожалению, не все отношения одинаково желательны. Таблица, отвечающая минимальному определению отношения, может иметь неэффекптвную пли неподходящую структуру. Для некоторых отношений изменение данных может привести к нежелательным последствиям, называемым аномалиями модификации (шаг(!Бса(1оп апоша!!ев). Аномалии могут быть устранены путем разбиения исходного отношения на два или более новых отношения.
В большинстве случаев переопределенные, или нормализованные, о~ношения являются более предпочтительными. Аномалии модификации Рассмотрим опять отношение СЕКЦИЯ на рис. 5.3. Если мы удалим строку, где записаны данные о студенте с номером 100, мы потеряем не только инфармацию о том, что студент с номером 100 является лыжником, но и тот факт, что абонемент в секцию лыж стоит $200. Это называется аномалией удаления (с(е!ет!оп апота1у)— то есть, удаляя факты, относящиеся к одной сущности (студент с номером 100 является лыжником), мы непроизвольно удаляем факты, относящиеся к другой сущности (плата за абонемент в секцию лыж составляет $200).
Выполнив одну операцию удаления, мы теряем информацию о двух сущностях. На примере того же самого отношения можно продемонстрировать аномалию вставки (шзегБоп апота1у). Предположим, мы хотим записать в базу данных тот факт, что абонемент в секцию подводного плавания стоит $175, однако мы не можем ввести эти данные в отношение СЕКЦИЯ, пока хотя бы один студент не запишется в секцию подводного плавания. Это ограничение выглядит глупо, Почему для того, чтобы указать стоимость абонемента, требуется ждать, когда кто-нибудь запишется н секцикт? Это ограничение называется аномалией вставки. Суть его в том, что мы не можем записать в таблицу некоторый факт об одной сущности, не указав дополнительно некоторый факт о другой сущности.
Отношение в табл. 5.3 может быть использовано в некоторых приложениях, но оно имеет явные проблемы. Мы можем устранить как аномалию удаления, так и аномалию вставки, разделив отношение СЕКЦИЯ на дна отношения, каждое из которых будет содержать информацию на определенную тему. Например, в одно отношение мы поместим атрибуты НоиерСтудента и Секция (назовем это отношение СТУДЕНТ-СЕКЦИЯ), а в другое — атрибуты Секция и Плата (назовем это отношение СЕКЦИЯ-ПЛАТА). Эти два отношения с данными пз нашею примера изображены на рис, 5.5, СЕКЦИЯ-ПЛАТА (Секция, Плата) Ключ: Секция Секция Плата СЕКЦИЯ (НомерСтудента, Секция, Платэ) Ключ: НомерСтудента НомерСтудента Секция Лыжи 200 бо бо Плавание Сквош рио. б.в.
Разбиение отношения СЕКЦИЯ на два отношения Теперь, если мы удалим запись о студенте с номером 100 из таблицы СТУДЕНТ- СЕКЦИЯ, мы уже не потеряем тот факт, что абонемент в секцию лыж стоит $200. Более того, мы можем добавить в таблицу СЕКЦИЯ-ПЛАТА секцию подводного плавания с указанием стоимости абонемента, не дожидаясь, пока кто-либо запишется в эту секцию. Таким образом, аномалии удаления и вставки устранены.
Разбиение одного отношения на два имеет, однако, один недостаток. Предположим, что студент хочет записаться н несугнествуюшую секцию. Например, студент с номером 250 хочет записаться в секцию ракетбола. Мы можем вставить соответствуюгцую строку в отношение СТУДЕНТ-СЕКЦИЯ (строка будет содержать запись (250, Ракетбол)), но следует ли это делать? Стоит ли разрешать студенту записываться н секцию, которая отсутствует в отношении СЕКЦИЯ-ПЛАТА? Другими словами, должна ли система каким-либо образом препятствовать добавлению строк а таблицу СТУДЕНТ-СЕКЦИЯ, если название соответствующей секции отсутствует в таблице СЕКЦИЯ-ПЛАТА? Ответ на этот вопрос содержится в требованиях пользователей. Если такое действие должна быть запрещено, данное ограничение (а это пе что иное, как статья делового регламента) необходимо внести в схему базы данных.
Позже, на стадии реализации, выполнение этого ограничения будет возложено на СУБД, если используемая СУБД предоставляет такую возможность. Если нет, то соблюдение ограничения должно обеспечиваться прикладными программами. Допустим, пользователи указывают, что секции могут существовать и до того, как кто-либо в них запишется, однако студент не может записаться в секцикх для которой не указан размер платы за абонемент (то есть в секцию, данные 174 Глава 5.
Реляционная модель и нормализация Нормализация 175 о которой отсутствуют в таблице СЕКЦИЯ-ПЛАТА). При проектировании базы данных мы можем задокументировать это ограничение любым из следующих способов: «множество значений атрибута Секция в таблице СТУДЕНТ-СЕКЦИЯ является подмножеством множества значений атрибута Секция в таблипе СЕКЦИЯ-ПЛАТА», «СТУДЕНТ-СЕКЦИЯ [Секция] является подмножеством СЕКЦИЯ-ПЛАТА [Секция]» либо «СТУДЕНТ-СЕКЦИЯ [Секция] ~ СЕКЦИЯ-ПЛАТА [Секция]». Квадратные скобки в этой записи обозначают столбец данных, извлекаемый иэ отношения.
Смысл этих выражений в том, что атрибут Секция в отношении СТУДЕНТ-СЕКЦИЯ может принимать только те значения, которые имеет атрибут Секция в отношении СЕКЦИЯ-ПЛАТА. Это означает также, что прежде чем ввести название какой-то секции в отношение СТУДЕНТ-СЕКЦИЯ, мы должны проверить, что такое название уже сушествует в отношении СЕКЦИЯ-ПЛАТА. Ограничения, падобньге этому, называются ограничениями ссылочной целостности (ге(егепт!а! нттейпту сопзтга)птз), или огриннчениями целостности ло внешнему ключу ()птетге]аарон сопзтга1птз). Суть нормализации Анолиалии, присутствующие в отношении на рис.
5,3, можно внтуитивно описать следующим образом; проблемы возникают из-за того, что отношение СЕКЦИЯ содержит факты, относящиеся к двум различным темам. 1. Кто из студентов какую секцию посещает, 2. Какова плата за абонемент в каждой из секций, Когда мы добавляем новую строку, нам приходится добавлять информацию, затрагивающую две различные темы; точно так же, когда мы удаляем строку, мы вынуждены удалять данные, относящиеся сразу к двум темам. Помните, что учительница родного языка и литературы говорила вам, что абзац должен иметь только одну тему? Если абзац содержал более одной темы, вас учили разбивать его на два пли более абзаца таким образом, чтобы каждый из получившихся абзацев содержал ровно одну тему. Аналогичные высказывания справедливы и для отношений.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
