Отношение staff room в нфбк

Любое отношение, которое не находится в НФБК, можно декомпозировать с образованием НФБК-отношений, однако делать это не всегда желательно. Например, декомпозиция будет нежелательна, если в результате ее выполнения утрачивается некоторая функциональная зависимость (т.е. детерминант и определяемые им атрибуты помещаются в разные отношения). В этой ситуации будет трудно обеспечить исходную функциональную зависимость отношения и важное ограничение может быть утрачено. Если имеет место упомянутая ситуация, то лучше закончить процесс нормализации на этапе образования ЗНФ-отношений, в которых все требуемые зависимости всегда сохраняются. Обратите внимание на то, что в примере при создании двух новых НФБК-отношений на основе исходного отношения Client Interview утрачивается следующая функциональная зависимость: Room No, Interview Date, Interview 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 – независимость от распределения данных. Язык манипулирования данными в реляционной СУБД должен позволять прикладным программам и запросам оставаться логически неизменными, независимо от того, как хранятся данные – физически централизованно или в распределенном виде.

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

Статьи к прочтению:

JANUSZ PRZECHODZI DO LaLiga i.. GRA O 2 PUCHARY! | FIFA 18 KARIERA Janusza Wpiergola

Похожие статьи: