Коллектив Авторов - Базы данных: конспект лекций
Определение. Базовое отношение находится в нормальной форме Бойса – Кодда тогда и только тогда, когда она находится в третьей нормальной форме, и при этом не только любой неключевой атрибут полностью функционально зависит от любого ключа, но и любой ключевой атрибут должен полностью функционально зависеть от любого ключа.
Таким образом, требование о фактической зависимости неключевых атрибутов от всего ключа целиком и ни от чего другого, кроме как от ключа, распространяется и на ключевые атрибуты.
В отношении, находящемся в нормальной форме Бойса – Кодда, все функциональные зависимости в пределах отношения навязаны объявлением ключей. Однако при приведении отношений баз данных к форме Бойса – Кодда, возможны ситуации, при которых не навязанными функциональными зависимостями оказываются зависимости между атрибутами различных отношений. Поддержка таких функциональных зависимостей при помощи триггеров, оперирующих кортежами различных отношений, сложнее, чем в случае третьей нормальной формы, когда триггеры оперируют кортежами единственного отношения.
Кроме всего прочего, практика проектирования систем управления базами данных показала, что не всегда удается привести базовое отношение к нормальной форме Бойса – Кодда.
Причиной отмеченных аномалий является то, что в требованиях второй нормальной формы и третьей нормальной формы не требовалась минимальная функциональная зависимость от первичного ключа атрибутов, являющихся компонентами других возможных ключей. Эту проблему и решает нормальная форма, которую исторически принято называть нормальной формой Бойса – Кодда и которая является уточнением третьей нормальной формы в случае наличия нескольких перекрывающихся возможных ключей.
Вообще нормализация схемы базы данных способствует более эффективному выполнению системой управления базами данных операций обновления базы данных, поскольку сокращается число проверок и вспомогательных действий, поддерживающих целостность базы данных. При проектировании реляционной базы данных почти всегда добиваются второй нормальной формы всех входящих в базу данных отношений. В часто обновляемых базах данных обычно стараются обеспечить третью нормальную форму отношений. На нормальную форму Бойса – Кодда внимание обращают гораздо реже, поскольку на практике ситуации, в которых у отношения имеется несколько составных перекрывающихся возможных ключей, встречаются нечасто.
Все вышеназванное делает нормальную форму Бойса – Кодда не слишком удобной в использовании при разработке программного кода, поэтому, как уже было сказано ранее, на практике разработчики обычно ограничиваются приведением своих баз данных к третьей нормальной форме. Однако здесь тоже есть своя довольно любопытная особенность. Дело в том, что ситуации, когда отношение находится в третьей нормальной форме, но не находится в нормальной форме Бойса – Кодда крайне редки на практике, т. е. после приведения к третьей нормальной форме обычно все функциональные зависимости оказываются навязанными объявлениями первичных, кандидатных и внешних ключей, так что необходимость в триггерах для поддержки функциональных зависимостей отпадает.
Однако необходимость в триггерах остается для поддержки ограничения целостности, не связанных функциональными зависимостями.
6. Вложенность нормальных форм
Что означает вложенность нормальных форм друг в друга?
Вложенность нормальных форм – это отношение понятий ослабленной и усиленной формы по отношению друг к другу.
Вложенность нормальных форм полностью следует из их соответствующих определений. Представим диаграмму, иллюстрирующую отношение вложенности известных нам нормальных форм:
Поясним понятия ослабленной и усиленной нормальной формы по отношению друг к другу на конкретных примерах.
Первая нормальная форма является ослабленной по отношению ко второй нормальной форме (да и по отношению ко всем остальным нормальным формам тоже). Действительно, вспоминая определения всех пройденных нами нормальных форм, можно заметить, что требования каждой нормальной формы включали в себя требование принадлежности именно к первой нормальной форме (ведь она входила в каждое последующее определение).
Вторая нормальная форма является усиленной по отношению к первой нормальной форме, но ослабленной по отношению к третьей нормальной форме и нормальной форме Бойса – Кодда. На самом деле принадлежность второй нормальной форме включается в определение третьей, а сама вторая форма, в свою очередь, включает в себя первую нормальную форму.
Нормальная форма Бойса – Кодда является усиленной не только по отношению к третьей нормальной форме, но также и по отношению ко всем остальным, предшествующим ей.
А третья нормальная форма, в свою очередь, является ослабленной только по отношению к нормальной форме Бойса – Кодда.
Лекция № 11. Проектирование схем баз данных
Наиболее распространенным средством абстрактного представления схем баз данных при проектировании на логическом уровне является так называемая модель «сущность – связь». Ее еще иногда называют ER-модель, где ER – аббревиатура английского словосочетания Entity – Relationship, что буквально и переводится как «сущность – связь».
Элементами таких моделей являются классы сущностей, их атрибуты и связи.
Дадим объяснения и определения каждого из этих элементов.
Класс сущностей – это как бы лишенный методов класс объектов в смысле объектно-ориентированного программирования. При переходе к физическому уровню классы сущностей преобразовываются в базовые отношения реляционных баз данных для конкретных систем управления базами данных. У них, как и у собственно базовых отношений, существуют собственные атрибуты.
Дадим более точное и строгое определение только что приведенных объектов.
Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой. Графически обычно класс изображается в виде прямоугольника. У каждого класса должно быть имя (текстовая строка), уникально отличающее его от всех других классов.
Атрибутом класса называется именованное свойство класса, описывающее множество значений, которые могут принимать экземпляры этого свойства. Класс может иметь любое число атрибутов (в частности, не иметь ни одного атрибута). Свойство, выражаемое атрибутом, является свойством моделируемой сущности, общим для всех объектов данного класса. Так что атрибут является абстракцией состояния объекта. Любой атрибут любого объекта класса должен иметь некоторое значение.
Так называемые связи реализуются с помощью объявления внешних ключей (подобные явления нам уже встречались раньше), т. е. в отношении объявляются внешние ключи, ссылающиеся на первичные или кандидатные ключи каких-то других отношений. И посредством этого и происходит «связывание» нескольких различных самостоятельных базовых отношений в единую систему, называемую базой данных.
Далее диаграмма, составляющая графическую основу модели «сущность – связь», изображается при помощи унифицированного языка моделирования UML.
Языку объектно-ориентированного моделирования UML (или Unified Modeling Language) посвящено великое множество книг, многие из которых переведены на русский язык (а некоторые и написаны российскими авторами).
Вообще, UML позволяет моделировать разные виды систем: чисто программные, чисто аппаратные, программно-аппаратные, смешанные, явно включающие деятельность людей и т. д.
Но, помимо прочего, как мы уже упоминали, язык UML активно применяется для проектирования реляционных баз данных. Для этого используется небольшая часть языка (диаграммы классов), да и то не в полном объеме. С точки зрения проектирования реляционных баз данных, модельные возможности не слишком отличаются от возможностей ER-диаграмм.
Мы также хотели показать, что в контексте проектирования реляционных баз данных структурные методы проектирования, основанные на использовании ER-диаграмм, и объектно-ориентированные методы, основанные на использовании языка UML, различаются главным образом, лишь терминологией. ER-модель концептуально проще UML, в ней меньше понятий, терминов, вариантов применения. И это понятно, поскольку разные варианты ER-моделей разрабатывались именно для поддержки проектирования реляционных баз данных, и ER-модели почти не содержат возможностей, выходящих за пределы реальных потребностей проектировщика реляционной базы данных.
Язык UML принадлежит объектному миру. Этот мир гораздо сложнее (если угодно, непонятнее, запутаннее) реляционного мира. Поскольку UML может использоваться для унифицированного объектно-ориентированного моделирования всего чего угодно, в этом языке содержится масса различных понятий, терминов и вариантов использования, избыточных с точки зрения проектирования реляционных баз данных. Если вычленить из общего механизма диаграмм классов то, что действительно требуется для проектирования реляционных баз данных, то мы получим в точности ER-диаграммы с другой нотацией и терминологией.
