Реляционная модель данных

Нормальная форма Бойса-Кодда. При нормализации таблиц с учетом требований 2НФ и 3НФ рассматриваются только функциональные зависимости от первичного ключа. Следовательно, в отношениях 3НФ может присутствовать избыточность, обусловленная зависимостями от потенциальных ключей. С учетом этого недостатка формы 3НФ была разработана более строгая НФ, получившая название нормальной формы Бойса-Кодда (НФБК).
Форма НФБК основана на рассмотрении всех функциональных зависимостей, в которых участвуют потенциальные ключи. Требования НФБК заключаются в следующем: каждый детерминант таблицы должен быть потенциальным ключом. Следовательно, для проверки принадлежности таблицы к НФБК необходимо найти все ее детерминанты и убедиться, что они являются потенциальными ключами.
Нарушения требований НФБК происходят крайне редко, поскольку это может случиться только при следующих условиях:

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

Следует иметь в виду, что преобразование отношений в форму НФБК не всегда приводит к желаемым результатам. Например, иногда после такой декомпозиции не сохраняется важная функциональная зависимость, поскольку детерминант и определяемые им атрибуты помещаются в разные таблицы. Если из-за этого утрачивается важное ограничение, то лучше закончить процесс нормализации на этапе образования отношений 3НФ, в которых все требуемые зависимости всегда сохраняются.
Решение о том, следует ли в процесс нормализации остановиться на форме 3НФ или перейти к форме НФБК, зависит от сопоставления следующих факторов:

• 
  относительная избыточность данных, возникающая в случае 3НФ;
  
• 
  важность утрачиваемой зависимости при переходе к НФБК.
  

Физическое проектирование реляционной БД
Физическое проектирование БД представляет собой процесс, цель которого состоит в подготовке описания способа физической реализации таблиц БД на вторичных (внешних) запоминающих устройствах с учетом требований к целостности данных. На этом же этапе выбирается организация файлов для хранения данных и индексных файлов, обеспечивающих эффективный доступ к данным, а также принимаются решения по защите данных.
Во время предыдущего этапа была определена логическая структура БД, т.е. описаны реляционные таблицы, связи между ними и ограничения, обусловленные конкретной прикладной областью. Эта структура не зависит от конкретной СУБД и учитывает только то, что для представления данных выбрана реляционная модель.
Теперь, приступая к физическому проектированию БД, необходимо, прежде всего, выбрать конкретную целевую СУБД (target DBMS). Здесь важно понимать, что многие этапы физического проектирования БД в значительной степени зависят от выбранной целевой СУБД. Следовательно, может существовать несколько различных способов реализации одной и той же схемы БД. Поэтому разработчик физической БД должен разбираться в функциональных возможностях существующих СУБД, понимать достоинства и недостатки каждого возможного варианта реализации. Разработчик физической БД должен уметь выбрать наилучшую стратегию хранения данных с учетом всех существующих особенностей их использования.
Если концептуальное и логическое проектирование БД отвечало на вопрос «что?», то физическое проектирование дает ответ на вопрос «как?». Несмотря на эту принципиальную разницу, между логическим и физическим проектированием существует постоянная обратная связь, т.к. решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных (имеется в виду денормализация). Выражением этой зависимости является итерационный процесс проектирования БД, который может состоять из большого числа уточнений, направленных на корректировку принятых ранее решений.