Отношение Staff Room в НФБК

 

Любое отношение, которое не находится в НФБК, можно декомпозировать с образованием НФБК-отношений, однако делать это не всегда желательно. Например, декомпозиция будет нежелательна, если в результате ее выполнения утрачивается некоторая функциональная зависимость (т.е. детерминант и определяемые им атрибу­ты помещаются в разные отношения). В этой ситуации будет трудно обеспечить исходную функциональную зависимость отношения и важное ограничение может быть утрачено. Если имеет место упомянутая ситуация, то лучше закончить процесс нормализации на этапе образования ЗНФ-отношений, в которых все требуемые зави­симости всегда сохраняются. Обратите внимание на то, что в примере при созда­нии двух новых НФБК-отношений на основе исходного отношения Client Interview утрачивается следующая функциональная зависимость: Room No, Interview Date, In­terview Time –> Staff No, Client No (зависимость fd3), поскольку детерминант этой зависимости больше не будет находиться в том же отношении, что и определяемые им атрибуты. Однако следует признать, что если не устранить функциональную за­висимость Staff No, Interview Date –> Room_No (зависимость fd4), то отношение Client_Interview будет обладать избыточностью данных.

Более высокие степени нормализации не будут рассмотрены в данной юните. Подробно ознакомиться с ними Вы можете в литературе, данной в начале юниты. Приведем только определения.

Четвертая нормальная форма (4НФ). В ходе исследований был выявлен еще один тип зависимости – многозначная зависимость, которая может вызвать проблеммы, связанные с избыточностью данных.

В случае многозадачной зависимости, существующей между атрибутами А, В и С некоторого отношения, для каждого значения А имеется набор значений атрибута B и набор значений атрибута C. Однако входящие в эти наборы значения атрибутов B и С не зависят друг от друга.

4НФ – это отношение в нормальной форме Бойса–Кодда, которое не содержит нетривиальных многозадачных зависимостей.

Пятая нормальная форма (5НФ). При любой декомпозиции отношения на два других отношения полученные отношения имеют свойство соединения без потерь. Это значит, что полученные отношения можно снова соединить и получить прежнее отношение в исходном виде. Однако бывают случаи, когда требуется декомпозировать отношение на более чем два отношения. В таких (достаточно редких) случаях возникает необходимость учитывать зависимость соединения, которая устраняется с помощью пятой нормальной формы.

Зависимость соединения – это свойство декомпозиции, которое вызывает генерацию ложных строк при обратном соединении декомпозированных отношений с помощью операции естественного соединения.

5НФ – это отношение без зависимостей соединения.

Реляционные системы управления

Базами данных

 

Как уже упоминалось, существует несколько сотен реляционных СУБД для мейнфреймов и персональных компьютеров. К сожалению, некоторые из них, строго говоря, не соответствуют определению реляционной модели. В частности, некоторые поставщики традиционных вариантов СУБД, основанных на сетевой и ие­рархической моделях данных, реализуют в своих продуктах только некоторые черты реляционных систем, чтобы иметь основания заявить об их принадлежности к реляционным системам. Озабоченный тем, что потенциальные возможности и смысл ре­ляционного подхода искажаются, Кодд предложил 12 правил определе­ния реляционных систем (а точнее 13, если учитывать фундаментальное правило 0). Эти правила образуют своего рода эталон, по которому можно определить принад­лежность СУБД к разряду действительно реляционных систем.

На протяжении многих лет предложенные Коддом правила вызывали массу наре­каний у заинтересованных лиц и специалистов. Одни сочли их не более чем чисто теоретическими упражнениями. Другие заявили, что их продукты уже удовлетворя­ют многим этим правилам, если не всем. Эта дискуссия способствовала росту пони­мания пользователями и сообществом разработчиков СУБД важнейших свойств дей­ствительно реляционных СУБД. Чтобы подчеркнуть особое значение этих правил, они были разделены на пять функциональных групп.

1. Фундаментальные правила.

2. Структурные правила.

3. Правила целостности.

4. Правила управления данными.

5. Правила независимости от данных.

 

Фундаментальные правила (правила 0 и 12). Образно выражаясь, правила 0 и 12 являются “лакмусовой бумажкой”, которая позволяет определить принадлежность системы к реляционным СУБД. Если система на удовлетворяет этим правилам, то ее не следует считать реляционной.

Правило 0 – фундаментальное правило. Любая система, которая рекламируется или представляется как реляционная СУБД, должна управлять базами данных исключительно с помощью ее реляционных функций.

Это правило означает, что СУБД не должна прибегать к любым не реляционным операциям для выполнения таких видов работ, как определение данных и манипу­лирование ими.

Правило 12 – правило запрета обходных путей. Если реляционная система имеет низкоуровневый язык (с последовательной построчной обработкой), он не может быть использован для отмены или обхода пра­вил и ограничений целостности, составленных на реляционном языке более высо­кого уровня (с обработкой сразу нескольких строк).

Это правило гарантирует, что все попытки доступа к базе данных контролируются СУБД таким образом, что целостность базы данных не может быть нарушена без ведома пользователя или администратора базы данных. Это, однако, не исключает возможностей использования языка низкого уровня с интерфейсом последовательной построчной обработки.

Структурные правила (правила 1 и 6). Фундаментальным структурным понятием реляционной модели является отноше­ние. Кодд утверждает, что РСУБД должна поддерживать работу с несколькими структурными элементами, включая отношения, домены, первичные и внешние ключи. Для каждого отношения (таблицы) базы данных должен быть определен пер­вичный ключ.

Правило 1 – представление информации. Вся информация в реляционной базе данных представляется в явном виде на логическом уровне и только одним способом – в виде значений в таблицах.

Согласно этому правилу вся информация, даже метаданные в системном катало­ге, должна храниться в виде отношений и управляться с помощью тех же функций, которые используются для работы с данными. Упоминание в этом правиле “логического уровня” означает, что такие физические конструкции, как индексы, не должны быть представлены в модели и пользователь не должен явно ссылаться на них в операциях извлечения данных, даже в тех случаях, когда они существуют.

Правило 6 – обновление представления. Все представления, которые являются теоретически обновляемыми, должны быть обновляемы и в данной системе.

Это правило касается исключительно представлений. Данное прави­ло гласит, что если представление является теоретически обновляемым, то СУБД должна уметь выполнять подобные обновления. На самом деле ни одна существую­щая система не поддерживает это требование, поскольку все еще не определены ус­ловия идентификации всех теоретически обновляемых представлений.

Правила целостности (правила 3 и 10). Кодд предложил два правила поддержки целостности данных. Поддержка целостно­сти данных является важным критерием оценки пригодности системы для практиче­ских нужд. Чем больше ограничений целостности может поддерживаться самой СУБД, а не отдельными ее приложениями, тем выше гарантии качественности данных.

Правило 3 – систематическая обработка неопределенных значений (NULL). Неопределенные значения (задаваемые с помощью определителя NULL), т.е. значе­ния, отличные от пустой строки или строки пустых символов, а также от нуля или любого другого конкретного значения, поддерживаются для систематического представления отсутствующей или неприемлемой информации, причем независимо от типа данных.

Правило 10 – независимость ограничений целостности. Специфические для данной РСУБД ограничения целостности должны определять­ся на языке реляционных данных и храниться в системном каталоге, а не в прикладных программах.

Код особо подчеркивает, что сведения об установленных ограничениях целостно­сти данных должны храниться в системном каталоге, а не инкапсулироваться в от­дельных прикладных программах или пользовательских интерфейсах. Хранение ог­раничений целостности в системном каталоге предоставляет важное преимущество централизованного управления и приведения их в действие.

Правила манипулирования данными (правила 2, 4, 5 и 7). Идеальная РСУБД должна поддерживать 18 функций управления данными (будут рассматриваться в юните 2). Они определяют полноту языка запросов (здесь термин “запрос” включает и операции вставки, обновления и удаления). Правила манипулирования данными определяют способ применения функций управления данными. Строгое следование этим правилам позволяет изолировать пользователя и прикладные программы от физического и логического механизмов реализации средств манипулирования данными.

Правило 2 – гарантированный доступ. Для всех и каждого элемента данных (т.е. его атомарного значения) реляционной базы данных должен быть гарантирован логический доступ на основе комбинации имени таблицы, значения первичного ключа и значения имени столбца.

Правило 4 – динамический интерактивный каталог, построенный по правилам реляционной модели. Описание базы данных должно представляться на логическом уровне таким же об­разом, как и обычные данные, что позволит санкционированным пользователям использовать для обращений к этому описанию тот же реляционный язык, что и при обращении к данным.

Это правило указывает на то, что должен существовать только один язык, пред­назначенный для манипулирования как метаданными, так и обычными данными, причем в СУБД для организации хранения системной информации должна использо­ваться только одна логическая структура – отношения.

Правило 5 – исчерпывающий язык данных. Реляционная система может поддерживать несколько языков и различные режимы работы с терминалами (например, режим заполнения формы – fill-in-the-blanks). Однако должен существовать, по крайней мере, один язык, операторы которого позво­ляли бы выражать все следующие конструкции: 1) определение данных; 2) опреде­ление представлений; 3) команды манипулирования данными (доступные как инте­рактивно, так и из программ); 4) ограничения целостности; 5) авторизация пользова­телей; 6) организация транзакций (запуск, фиксация и откат).

Следует отметить, что новый стандарт ISO для языка SQL обеспечивает выполне­ние всех этих функций таким образом, что любой удовлетворяющий этому стандарту язык автоматически будет удовлетворять и этому правилу.

Правило 7– высокоуровневые операции вставки, обновления и удаления. Способность обрабатывать базовые или производные отношения (т.е. представле­ния) как единый операнд должна относиться не только к процедурам извлечения данных, но и к операциям вставки, обновления и удаления данных.

Правила независимости от данных (правила 8, 9 и 11). Кодд определяет три правила независимости данных от приложений, которые эти данные используют. Строгое соблюдение этих правил гарантирует, что пользователи и разработчики будут защищены от необходимости вносить тотальные изменения в приложения при каждой реорганизации базы данных на низком уровне.

Правило 8 – физическая независимость от данных. Прикладные программы и средства работы с терминалами должны оставаться ло­гически незатронутыми при внесении любых изменений в способы хранения дан­ных или методы доступа к ним.

Правило 9 – логическая независимость от данных. Прикладные программы и средства работы с терминалами должны оставаться ло­гически незатронутыми при внесении в базовые таблицы любых не меняющих ин­формацию изменений, которые теоретически не должны затрагивать прикладное программное обеспечение.

Правило 11 – независимость от распределения данных. Язык манипулирования данными в реляционной СУБД должен позволять прикладным программам и запросам оставаться логически неизменными, незави­симо от того, как хранятся данные – физически централизованно или в распреде­ленном виде.

Независимость от распределения данных означает, что прикладная программа, осуществляющая доступ к СУБД на отдельном компьютере, должна без каких-либо мо­дификаций продолжать работать и в том случае, когда данные в сети будут перенесены с одного компьютера на другой. Другими словами, для конечного пользователя должна быть создана иллюзия того, что данные централизованно хранятся на единственном компьютере, а ответственность за перемещение и поиск данных среди (возможно) не­скольких мест их хранения должна возлагаться исключительно на систему. Обратите внимание, что здесь не сказано о том, что реляционная СУБД должна непременно под­держивать работу с распределенной базой данных. Здесь просто имеется в виду, что язык запросов должен оставаться неизменным и в том случае, когда возможность рабо­ты с распределенными данными реализуется в некоторой СУБД.