Этап 3. Проектирование реализации

· Преобразование инфологической схемы в концептуальную.

· Установка (формулировка) ограничений целостности.

· Обеспечение средств защиты.

· Разработка (проектирование) приложений.

Несколько комментариев к схеме.

К обследованию ПО:

1. Ясно, что инфологическое описание ориентировано на некоторую идеальную среду реализации, то есть отражает, что заказчик хочет отразить в информационной системе, но не как эти желания будут отражены.

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

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

· номер_зачетной_книжки типа записи СТУДЕНТ (пример простого первичного ключа, состоящего из одного атрибута),

· номер_рейса + дата_вылета типа записи СВЕДЕНИЯ_О_РЕЙСАХ (пример составного первичного ключа, образованного несколькими атрибутами); знак “+” здесь означает операцию конкатенации.

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

К выбору СУБД:

1. Каждая конкретная среда реализации имеет внешние ограничения, из которых можно выделить:

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

· программные, определяемые операционной системой и языками программирования,

· организационные, определяемые сроками разработки, имеющимися кадровыми ресурсами, возможностями переподготовки специалистов и т.д.

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

3. Сравнительный анализ моделей БД производится путем оценки целого ряда факторов, из которых упомянем следующие:

· требуемые объемы основной и дисковой памяти,

· трудоемкость разработки программных средств окружения СУБД,

· трудоемкость реализации приложений,

· затраты на обучение персонала,

· стоимость эксплуатации системы,

· возможность совмещения разработки БД с ранее выполненными программными продуктами, прогнозируемые сроки реализации.

К проектированию реализаций:

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

2. Уточнение (детализация) концептуальной схемы на основе выявленных дополнительных требований прикладных программ.

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

· определение типа данных,

· создание полей, опирающихся на домены,

· установка значений по умолчанию,

· определение ограничений целостности,

· определение проверочных условий.

4. Обеспечение защиты предполагает решение вопросов надежности данных и, при необходимости, сохранения секретности информации. Для этого необходимо определить:

· кто будет иметь права (и какие) на использование базы данных,

· кто будет иметь права на модификацию, вставку и удаление данных,

· нужно ли делать различие в правах доступа,

· каким образом обеспечить общий режим защиты информации,

· и т.п.

5. Разработка (проектирование) приложений.

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

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

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

КОНТРОЛЬНЫЕ ВОПРОСЫ ПО ЧЕТВЕРТОМУ РАЗДЕЛУ

1. Перечислите и охарактеризуйте основные этапы жизненного цикла информационной системы.

2. Приведите схему организации централизованного планирования.

3. Перечислите функции администратора базы данных в реализации процессов планирования и проектирования.

4. Приведите общую схему инфологического проектирования. Дайте понятие ПО- и ПП-информации и поясните смысл их использовании для процесса проектирования.

5. Приведите общую схему концептуального проектирования.

6. Опишите этапы концептуального проектирования.

7. Приведите общую схему процесса проектирования.

8. В чем состоит процесс идентификации ключевых атрибутов.

9. Какие виды внешних ограничений вам известны.

10. Свяжите системные свойства модели данных с каждым из этапов проектирования. На каком этапе какие свойства реализуются.

МОДЕЛИ ДАННЫХ

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

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

 

 

Рис.12. Основные этапы проектирования БД

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

Базовые понятия

Реляционная модель данных была предложена Э.Коддом в 1970 г.; первые промышленные реляционные СУБД начали появляться в конце 1970-х – начале 1980-х гг.

В основе реляционной модели данных лежит математическое понятие теоретико-множественного отношения. Тем самым, в основе данной модели – строго обоснованная математическая теория.

Основными понятиями реляционных баз данных являются:

· тип данных,

· домен,

· кортеж,

· отношение,

· атрибут,

· схема отношения,

· первичный ключ.

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

Домен. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и способа определения принадлежности произвольного элемента типа данных домену. Например, домен Имена очевидным образом определяется на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака). Обычно такой способ определения принадлежности элемента типа данных домену сводится к заданию некоторого логического выражения, применяемого к элементам данных. Если вычисление этого логического выражения дает результат True, то элемент данных является элементом домена. Таким образом, правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений элементов данных определенного типа.

Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену.

Декартовым произведением k доменов (D₁, D₂, …, D_k), которое обозначается

(D₁ x D₂ x … x D_k),

называется множество всех кортежей вида (v₁, v₂, …, v_k) длины k таких, что

v₁ Є D₁, v₂ Є D₂, …, v_k Є D_k.

Пример. Пусть D₁ = {1, 2, 3}, D₂ = {a, b, c, d}.

 

Тогда

D₁ x D₂ = { (1,a), (1,b), (1,c) (1,d), (2,a), (2,b), (2,c), (2,d), (3,a), (3,b), (3,c), (3,d) }.

 

Или в матричном виде

 

 

Отношением называется произвольное конечное подмножество декартова произведения одного или нескольких доменов.

Примеры математических отношений:

1). { (1,a), (2,b), (3,c), (1,d) }

2). {0} – пустое подмножество

Кортежи (1,a), (2,b), (3,c), (1,d) являются элементами отношения (1).

В практике реляционных баз данных отношение представляется в виде двумерной таблицы, в которой строки соответствуют кортежам, а столбцы – доменам. Для примера 1) реляционный эквивалент математического отношения выглядит следующим образом:

 

	a
	b
	c
	d

 

Учитывая, что реляционное отношение – это элемент модели данных, определим смысл для строк и столбцов двумерной таблицы:

a) строка – это совокупность значений элементов данных, характеризующих конкретный объект (набор требуемых сведений об объекте), то есть строка представляет кортеж отношения (более точное определение понятия кортежа дано ниже);

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

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

Схема отношения представляется:

1. перечнем имен отношения и атрибутов в виде R(A₁, A₂, …, A_k), где R – имя отношения; A₁, A₂, …, A_k – имена атрибутов;

2. описанием доменов для каждого атрибута; заметим, что различные атрибуты могут быть определены на одном домене, например, дата рождения и дата поступления на работу;

3. условиями ограничения целостности, задаваемыми на доменах; например, дата рождения не должна определять возраст более 200 лет, а дата поступления на работу – меньше минимального, установленного трудовым законодательством.

В общем случае схема отношения - это именованное множество пар (имя атрибута, имя домена). Степень, или " арность " схемы отношения, - мощность этого множества. Если все атрибуты одного отношения определены на разных доменах, резонно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута).

Кортеж, соответствующий данной схеме отношения, - это множество пар (имя атрибута, значение), которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. Значение является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень, или " арность " кортежа, то есть число элементов в нем, совпадает с "арностью" соответствующей схемы отношения.

Таким образом, можно сказать, что отношение - это множество кортежей, соответствующих экземпляру схемы отношения (его телу).

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

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

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

Домен же представляется неким обобщенным типом, который может быть источником для типов полей в записи. Таким образом, следующие тройки терминов являются эквивалентными:

• отношение, таблица, файл (для локальных баз данных)
• кортеж, строка, запись
• атрибут, столбец, поле.

Соотношения между базовыми понятиями реляционной представлены на рис.13.

Атрибут (или набор атрибутов), который может быть использован для однозначной идентификации конкретного кортежа (строки, записи), является первичным ключом (см.. п.4.2.4.) Для каждого отношения, по крайней мере, полный набор его атрибутов обладает этим свойством. Однако при формальном определении первичного ключа требуется обеспечение его "минимальности", то есть, в набор атрибутов первичного ключа не должны входить такие атрибуты, которые можно отбросить без ущерба для основного свойства - однозначного определения кортежей. Это значит, что если из первичного ключа исключить произвольный атрибут, оставшихся атрибутов будет недостаточно для однозначной идентификации отдельных кортежей. Понятие первичного ключаявляется исключительно важным в связи с понятием целостности базы данных (см. п. 5.1.3.).

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

Фундаментальные свойства отношений (таблиц). Определенные таким образом таблицы обладают следующими свойствами:

1. Однородность столбцов. Для всех столбцов таблицы выполняется следующее требование: элементы столбца принимают значения на одном домене.
2. Отсутствие кортежей-дубликатов. В таблице нет двух одинаковых строк. Это свойство следует из определения отношения как множества кортежей. В классической теории множеств, по определению, каждое множество состоит из различных элементов. Именно из этого свойства вытекает необходимость наличия у каждого отношения первичного ключа.

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

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

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

Принципы нормализации

Для простоты будем считать, что проблема проектирования реляционной базы данных состоит в обоснованном принятии решений о том, из каких отношений должна состоять БД и какие атрибуты должны быть у этих отношений, опустив обсуждение вопросов, связанных с условиями ограничения целостности и защиты, то есть проектирование реляционных БД включает следующие основныешаги:

1) определение информационных потребностей базы данных,

2) анализ объектов реального мира, которые необходимо смоделировать в базе данных; формирование из этих объектов сущностей и списков характеристик этих сущностей,

3) установка в соответствие сущностям и характеристикам отношений (таблиц) и атрибутов (столбцов),

4) определение первичных ключей - атрибутов, которые уникальным образом идентифицируют каждый объект,

5) установка связей между объектами (таблицами и столбцами).

Рис.13. Базовые понятия реляционной модели и соотношения между ними

После определения отношений, атрибутов и связей между отношениями следует посмотреть на проектируемую базу данных в целом и проанализировать ее, используя правила нормализации, с целью устранения логических ошибок. Важность нормализации состоит в том, что она позволяет разбить большие отношения, как правило, содержащие большую избыточность информации, на более мелкие логические единицы, группирующие только данные, объединенные "по природе". После применения правил нормализации логически единые группы данных располагаются не более чем в одной таблице. Это дает следующие преимущества:

• данные легко обновлять или удалять,
• исключается возможность рассогласования копий данных,
• уменьшается возможность введения некорректных данных.

Рассмотрим классический подход, при котором весь процесс проектирования производится в терминах реляционной модели данных методом последовательных приближений к удовлетворительному набору схем отношений. Исходной точкой является представление предметной области в виде одного или нескольких отношений, а на каждом шаге проектирования строится некоторый набор схем отношений, обладающих лучшими свойствами. Таким образом, процесс проектирования включает процесс нормализации схем отношений.

В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:

· первая нормальная форма (1NF);

· вторая нормальная форма (2NF);

· третья нормальная форма (3NF);

· нормальная форма Бойса-Кодда (BCNF) (правильнее было бы считать эту нормальную форму третьей, однако по историческим причинам третья ступень оказалась занятой к моменту изобретения BCNF, из-за чего она и получила нестандартное название);

· четвертая нормальная форма (4NF);

· пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).

Важно отметить, что нормальные формы обладают следующими важными свойствами:

· при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются,

· каждая следующая нормальная форма в некотором смысле улучшает свойства предыдущей.

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

Замечание. Нормализованные отношения обладают некоторыми ограничениями (не любую информацию удобно представлять в виде плоских таблиц), но существенно упрощают манипулирование данными.

Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости.

Пусть R(A₁, A₂, …,A_n) схема отношения R, а X и Y – подмножества множества {A₁, A₂, …, A_n}. Говорят, что “X функционально определяет Y” или “Y функционально зависит от X” и обозначают это как X Y, если в любом отношении R’, являющимся текущим значением R, не могут содержаться два кортежа, компоненты которых совпадают по всем атрибутам, принадлежащим множеству X, и не совпадают по одному и более атрибутам, принадлежащим множеству Y.

Таким образом, термин функциональная зависимость означает, что атрибут A_j отношения R функционально зависит от атрибута A_i того же отношения, если в каждый момент времени каждому значению атрибута A_i соответствует не более чем одно значение атрибута A_j, связанного с A_i в отношении R. Или еще проще: функциональная зависимость A_j от A_i означает, что если в любой момент времени известно значение A_i, то можно однозначно получить и значение A_j.

Очевидно, что атрибут может функционально зависеть не от какого-либо одного атрибута, а от целой группы атрибутов.

Два или более атрибута называются взаимно независимыми, если ни один из этих атрибутов не является функционально зависимым от других атрибутов.

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

Наличие тех или иных зависимостей между атрибутами в схеме определяет степень ее нормализации.

С практической точки зрения, достаточно трех первых форм - следует учитывать время, необходимое системе для "соединения" таблиц при отображении их на экране. Поэтому мы ограничимся изучением процесса приведения отношений к первым трем формам.

Этот процесс включает:

• устранение повторяющихся групп (приведение к 1НФ)
• удаление частично зависимых атрибутов (приведение к 2НФ)
• удаление транзитивно зависимых атрибутов (приведение к 3НФ).

 

Первая нормальная форма

Назовем простым атрибут, значения которого неделимы.

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

Пример. Пусть задано следующее отношение R1:

R1

 

Очевидно, что в схеме R1 все атрибуты, кроме атрибута Дети, простые.

Замечание. Здесь и далее жирным шрифтом в примерах схем отношений выделяются первичные ключи.

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

R2

Таб_номер	Имя_ребенка	Возраст_ребенка	Фио	Оклад	Комната	Телефон
	Саша Женя Лена		Иванов Л.А Иванов Л.А Иванов Л.А

 

Очевидно, что в нормализованном отношении R2 все неключевые атрибуты функционально зависят от ключа.

Замечание. При определении первичного ключа в отношении R2 предполагается, что в семье нет детей с одинаковым именем, в противном случае в состав ключа необходимо было бы включить атрибут Возраст_ребенка ( вероятность одинакового имени у близнецов при нормальных родителях равна нулю).

Вторая нормальная форма

Говорят, что неключевой атрибут функционально полно зависит от составного ключа, если он функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа. Очевидно, что в отношении R2 атрибуты ФИО, Оклад, Комната, Телефон не находятся в полной функциональной зависимости от ключа отношения, поскольку они функционально зависят от части ключа Таб_номер. Наличие неполной функциональной зависимости приводит к высокой степени дублирования информации в отношении, а следовательно, к необходимости при изменении значения атрибута, (например, Оклад) вносить изменения в большое количество записей. Более того, данные о сотрудниках, не имеющих детей, естественным образом в отношение включены быть не могут. Таким образом, для отношения, находящегося в 1НФ, могут потребоваться дальнейшие преобразования.

Говорят, что отношение находится во второй нормальной форме (2НФ), если оно находится в 1НФ и все неключевые атрибуты функционально полно зависят от составного ключа.

Замечание. Проблема функциональной полноты рассматривается только в контексте составного ключа. Если первичный ключ включает только один атрибут, очевидно, эта проблема снимается.

Для искомого приведения 1НФ во 2НФ необходимо:

1) построить проекцию 1НФ, исключив атрибуты, которые не находятся в полной функциональной зависимости от составного ключа;

2) построить дополнительно одну или несколько проекций на часть составного ключа и атрибуты, функционально зависящие от этой части ключа.

Для нашего примераотношение R2 должно быть преобразовано в два отношения R3 и R4, оба находящиеся во 2НФ:

R3

Таб_номер	Имя_ребенка	Возраст_ребенка
	Саша Женя Лена

 

R4

Таб_номер	Фио	Оклад	Комната	Телефон
	Иванов Л.А.

 

Третья нормальная форма

Пусть X, Y, и Z – три атрибута некоторого отношения. При этом

Y X.

Z Y

X → Y и Y → Z,

но обратное соответствие отсутствует, то есть или Тогда говорят, что Z транзитивно зависит от X. Например, в отношении R4 транзитивной является зависимость

Таб_номер →Комната → Телефон

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

Говорят, что отношение находится в третьей нормальной форме (3НФ), если оно находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от ключевого атрибута.

Для преобразования 2НФ в 3НФ необходимо построить несколько проекций. Для нашего примера отношение R4 должно быть приведено к двум отношениям R5 и R6:

 

R5

Таб_номер	Фио	Оклад	Комната
	Иванов Л.А.

 

R6

Комната	Телефон

 

Очевидно, что в процессе приведения отношений в 2НФ и 3НФ число отношений в схеме БД увеличивается. Однако, всегда сохраняется возможность получить исходные отношения, используя операции соединения. С другой стороны, появление новых отношений порождает проблемы поддержания семантической целостности.

Выше было отмечено, что на практике третья нормальная форма схем отношений является достаточной в большинстве случаев и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается. Однако иногда полезно продолжить процесс нормализации. Нормальные формы более высоких порядков подробно рассмотрены в [3].

Замечание. Необходимо четко понимать, что разбиение информации на более мелкие единицы с одной стороны, способствует повышению надежности и непротиворечивости базы данных, а с другой стороны, снижает ее производительность, так как требуются дополнительные затраты процессорного времени (серверного или машины пользователя) на обратное "соединение" таблиц, например, при представлении информации на экране. Иногда для достижения требуемой производительности нужно сделать отход от канонической нормализации, ясно осознавая, что необходимо обеспечить меры по предотвращению противоречивости данных. Поэтому всякое решение о необходимости того или иного действия по нормализации можно принимать, только тщательно проанализировав предметную область и класс поставленной задачи. Может потребоваться несколько итераций для достижения состояния, которое будет желаемым компромиссом.

Таким образом, в целом можно отметить, что хорошо спроектированная БД:

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

· обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к базе более "прозрачными" и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы,

· удовлетворяет требованиям пользователей к производительности базы данных. При больших объемах информации вопросы сохранения производительности начинают играть главную роль, сразу "высвечивая" все недочеты этапа проектирования.