Теория и практика построения баз данных (1088289), страница 39
Текст из файла (страница 39)
СТУДЕНТ (НомерСтудвнтв, Специальность, Секция) Ключ: (НомврС>удвнтв, Специальность, Секция) Номврстудвнтв Специальность Секция Рис. В.10. Отношение СТУДЕНТ с аномалиями вставки: а — вставка одной строки; б — вставка нескольких строк Чтобы устранить эти аномалии, мы должны избавиться от многозначной зависимости. Мы сделаем зто, создав два отношен»и, в каждом из которых будут храниться данные только по одному многозначному атрибуту. Результирующие отношения не будут иметь аномалий. Это отношенця СТУДЕНТ-СПЕЦИАЛЬНОСТЬ (НоиерСтудента, Специальность) и СТУДЕНТ-СЕКЦИЯ (НомерСтудента, Секция), приведенные на рис.
5.11. Доменно-ключевая нормальная форма (ДКНФ), 183 Рис. 5.11. Устранение многозначной зависимости Исходя из сделанных нами наблюдений, мы определим четвертую чорлтльиую форму (сонг()> поппа! >от>п, 4КЕ) следующим образок>: отпосиеиив находится в четвертой норлсальной форме, воли оно находи>пол в ОФБК и нв имеет много.псач>сьсх зависимостей.
После обсуждения домениа-ключевой нормальной формы (далее в этой главе) мы вернемся к о>шсанию многозначных зависимостей, >ю уже в другом, более интуитивном ключе. Пятая нормальная форма (5НФ) Пятая норчилышя форма (с!>т)> п отша! 1огш, 5)ч г ) связана с зависимостями, которые имеют несколько неопределенный характер. Речь здесь идет об отношениях, которые можно разлелить на несколько более мелких отношений, как мы зто делали выше, но затем невозможно восстановить. углов>ся, при которых возникает .>та ситуация, не имеют ясной, интуитивной интерпретации. Нам неизвестно, каковы следствия таких зависимостей; мы не знаем даже, есть ли у них какие-либо практические следствия. За более подробной информацией о пятой нормаль> ей форме обращайтесь к работе Дэйта, которая цитировалась ранее в этой главе. Доменно-ключевая нормальная форма (ДКНФ) Нсе описанные выше нормальные формы были выделены исследователями, выявившими аномалии у некоторых отношений, которые находились в нормальной форме более низко~о порядка: обнаружение аномалий модификации у отношений вс> второй нормальной форме привело к определению третьей нормальной формы и т.
д. Хотя каждая нормальная форма решала часть проблем, найденных у предыдущей нормальной формы, никто не мог сказать, какие проблемы еще не пыявлены. Каждый такой >наг являлся прогрессом на пути к представлению об с>птнлсальной структуре базы данных, однако никто не мог гарантировать, что не будет обнаружено еще каких-либо аномалий. В этом разделе мы рассмотрим »ормадьную форму, которая будет свободна от аномалий любого типа. Когда мы приводим от>сошенсия к этой форме, мы знаем, что в этом случае даже скрытые аномалии, связанные с пятой нормальной формой, возникнуть не могут.
184 Глава 5. Реляционная модель и нормализация Доменно-кпючевая нормальная форма 1ДКНФ] 185 В 1981 г. Фагин опубликовал важну1о статью, в которой он определил домен- но-ключевую нормальную форл1у (с1оша)в,Лаву погша! (огш, ЭКИЕ)'. Он показал, что отношение в ДКНФ не имеет аномалий модификации и, более того, любое отношение, не имеющее аномалий модификации, должно находиться в ДКНФ, Это открытие положило конец введеншо нормальных форм, и теперь в нормальных формах более высокого порядка нет необходимости — по крайней мере, для устранения аномалий модификации.
Столь же важно и то, что определение доменно-ключевой нормальной формы затрагивает только понятия домена и ключа — понятия фундаментальные и близкие сердцу специалистов в области баз данных. Они непосредственно поддерживаются существу1ощими СУБД (или, по крайней мере, могут поддерживаться).
В каком-то смысле, работа Фагина формализовала и обосновала то, во что многие специалисты верили интуитивно, но были не в состоянии точно описать. Определение Понятие ДКНФ весьма просто: отношение находится в доменно-ключевой нормальной форме, если каждое ограничение, накладываемое на это отношение, является логическим следствием определения доменов и ключей. Рассмотрим важные термины, фигурирующие в этом определении: ограничение, ключ и домен.
Термин ограничение (сопзгга1пт) имеет в данном определении намеренно широкое толкование. Фагин определяет ограничение как любое правило, регулирующее возможные статические значения атрибутов и достаточно точное для того, чтобы можно было установить, выполняется оно или нет. Правила редактирования, ограничения взаимоотношений и структуры отношений, функциональные зависимости и многозначные зависимости являются примерами таких ограничений. Фагин явным образом исключает отсюда ограничения, относящиеся к изменениям значений данных, пли ограничения, зависящие от времени.
Например, правило «Зарплата продавца за текущий период не может быть меньше, чем за предыдущий период» не подпадает под определение ограничения, которое дал Фагин. За исключени м ограничений, зависящих от времени, определение Фагина является широким и охватывает много случаев. Ключ (Кеу) — это уникальный идентификатор кортежа, как мы его уже определили.
Третий важный термин в определении ДКНФ вЂ” домен (с)ота1п). В главе 4 говорилось, что домен — это описание допустимых значений атрибута. Он состоит из двух частей: физического описания и семантического, или логического, описания. Физическое описание — это множество значений, которые может принимать атрибут, а логическое описание — это смысл данного атрибута. Доказательство Фагина относится к обеим частям. Говоря неформально, отношение находится в ДКНФ, если выполнение ограничений на домены и ключи приводит к выполнению всех ограничений. Более того, поскольку отношения в ДКНФ не могут иметь аномалий модификации, П.
Рвя1 и, «Л Хоппв1 Еопв 1ог Кс!ас епя ОаЫжп Тьвг 1в НввЫ Ов Гкипв~пв апй Ксуви, Л СМ 7гавваггговв оп Рамьые Яувмтк сентябрь 1981, с. 387-415. СУБД может предотвратить возникновение этих аномалий, реализуя выполнение ограничений на домены и ключи. К сожалению, пока не известен ни один алгоритм преобразования отношения к доменно-ключевой нормальной форме; неизвестно даже, какие отношения могут быть приведены к ДКНФ.
Нахождение и создание отношений в ДКНФ является более искусством, чем наукой. Несмотря на все это, при практическом проектировании баз данных ДКНФ служит в высшей степени полезным ориентиром. Если мы сможем вводить отношения таким образом, что все налагаемые на них ограничения являются логическими следствиями доменов и ключей, то в таких отношениях не будет аномалий модификации. Во многих случаях этот критерий может быть соблюден. Если же выполнять его не представляется возможным, необходимые ограничения должны быть встроены в логику прикладных программ, которые обрабатывают базу данных. Более подробно мы узнаем об этом далее в этой главе и в главе 10, Следую1цие три примера иллюстриругот доыенно-ключевую нормальную форму.
Первый пример доменно-ключевой нормальной формы Рассмотрим отношение СТУДЕНТ на рис 5.12, имеющее атрибуты НомерСтудента, Курс, Общежитие и Плата. Здесь Плата — это сумма, которую студент платит за проживание в общежитии. Рио. 5.12. Первый пример ДКНФ НомерСтудента функционально определяет остальные три атрибута, поэтому НомерСтудеита является ключом. Допустим, мы также знаем, что, согласно требованиям пользователей, Общежитие и Плата и НомерСтудеита не должен начинатьгя с 1. Если нам удастся представить эти требования а качестве логических следствий определения доменов и ключей, то мы сможем быть уверены, в соответствии с теоремой Фагипа, что аномалий модификации не возникнет. В данном ~~римере это будет легко сделать. Чтобы реализовать ограничение, указывающее, что номера студентов не должпь1 начинаться с 1, мы просто включим это требование в определение домена атрибута НомерСтудеита (рис 5.13).
Соблюдение ограничения домена гарантиру< т, что данное требование будет выполнено. Далее нам требуется сделать функциональную зависимость Общежитие ы Плата логическим следствием ключей. Если бы атрибут Общежитие был ключевым. зависимость Общежитие ы Плата была бы логическим следствием ключа. Поэтому 186 Глава 5. Реляционная модель и нормализация Доменно-ключевая нормальная форма (ДКНФ) 187 НомерСтудента С000, где С десятичная цифра, не равная 1; 0 десятичная цифра ('С1', 'С2', 'СЗ', 'С4', 'АС') СНАП (4) 0ЕС (4) Курс Общежитие Плата СТУДЕНТ (НомерСтудента, Курс, Общежитие) Ключ.