1Nf. Отношение находится в первой нормальной форме тогда и только тогда, когда значения всех его атрибутов атомарны.

Это определение является синонимом определения отношения в теории реляционных баз данных. Пример отношения, которое НЕ находится в 1NF: расписание занятий.

Для перевода отношения в 1NF необходимо разделить с дублированием содержания общие ячейки на отдельные записи.

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

Функциональная зависимость R.A  R.B называется полной, если набор атрибутов В функционально зависит от А, но не зависит функционально от любого подмножества А, то есть если  А1  А  R.A –/ R.B. В противном случае функциональная зависимость называется неполной.

Пример отношен., кот. НЕ находится во 2NF: результаты сессии.

Рассмотрим отношение R ( ФИО, номер зачетки, группа, дисциплина, оценка ). Первичный ключ подчеркнут. Однако при этом атрибуты (ФИО, группа) зависят только от части первичного ключа – от атрибута (номер зачетки).

При этом возможны следующие аномалии:

- в результате ошибки оператора студенту по результатам одного или нескольких экзаменов приписали не ту группу.

- если студент не сдал ни одного экзамена, то он не существует.

Для приведения отношения во 2NF следует провести декомпозицию (разбить на проекции), например так:

1. R1 ( ФИО, номер зачетки, группа).

2. R2 (номер зачетки, дисциплина, оценка ).

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

3Nf. Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей.

Функциональная зависимость R.A  R.B является транзитивной, если существует набор атрибутов C такой, что:

1. С не является подмножеством А.

2. С не включает в себя В. (В  С)

3. Существует функциональная зависимость R.A  R.С.

4. Не существует функциональной зависимости R.С  R.А.

5. Существует функциональная зависимость R.С  R.B.

Иными словами, требование 3NF сводится к тому, чтобы все неключевые поля зависели только от первичного ключа и не зависели друг от друга.

Пример отношения, которое находится во 2NF, но НЕ находится в 3NF: связь студента с группой, факультетом, специализацией.

Дано отношение: R(№зачетки, ФИО, группа, факульт, кафедра).

Первичный ключ подчеркнут. Так как он состоит из одного атрибута, то критерий 2NF выполнен. В отношении имеются транзитивные зависимости, в числе которых:

1) номер зачётки  группа (обратное неоднозначно), группа  факультет, номер зачётки  факультет.

2) номер зачётки  кафедра, кафедра  факультет, номер зачётки  факультет.

Для приведения отношения в 3NF требуется декомпозиция

следующего вида:

1. R1 ( номер зачетки, ФИО, группа ).

2. R2 ( группа, факультет).

3. R3 ( кафедра, факультет ).

BCNF. Отношение находится в нормальной форме Бойса-Кодда, если оно находится в третьей нормальной форме и каждый детерминант отношения является возможным ключом этого отношения.

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

детерминантом отношения. Иными словами, отношение находится в BCNF, если любая функциональная зависимость между его атрибутами сводится к полной функциональной зависимости от возможного ключа. Пример отношения, которое находится в 3NF, но НЕ находится в BCNF: таблица результатов приемных экзаменов:

Дано отношение: R(идентифик, №паспорта, предмет, оценка).

Ответ на вопрос: зачем? Например, один абитуриент потерял свою карточку и ему выдали другую с другим номером. Второй абитуриент – гениальный ребенок, и у него пока нет паспорта.

Имеются следующие функциональные зависимости:

1. Идентификатор, предмет  оценка;

2. Номер паспорта, предмет  оценка; (зависимость полная)

3. Идентификатор  номер паспорта; (зависимым не является непервичный атрибут)

4. Номер паспорта  идентификатор.

Транзитивных зависимостей нет, так как зависимость 3 имеет обратную 4. Таким образом, отношение находится в 3NF. Но функциональные зависимости между атрибутами идентификатор и номер паспорта не являются зависимостями от возможного ключа этого отношения. Для приведения отношения в BCNF возможна декомпозиция следующего вида:

1. R1 ( идентификатор, предмет, оценка).

2. R2 ( идентификатор, номер паспорта).

Ответ на вопрос: зачем? (Тоже самое что и выше).

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

4NF. Отношение находится в четвёртой нормальной форме в том и только в том случае, если существует многозначная зависимость А –>> B и все остальные атрибуты R функционально зависят от А.

Определение: В отношении R(A,B,C) существует многозначная зависимость R.A –>> R.B в том и только в том случае, если множество значений В, соответствующее паре значений атрибутов А и С, зависит только от А и не зависит от С.

Иными словами, отношение находится в четвёртой нормальной форме, если оно находится в BCNF, и все его многозначные зависимости являются функциональными

зависимостями от потенциальных ключей.

Пример (1) отношения, котор. НЕ находится в 4NF: список дисциплин, которые предстоит прослушать студенту 1 курса:

Дано отношение: R( номер зачетки, группа, дисциплина ). Перечень дисциплин, которые должен слушать студент на первом курсе, определяется исключительно номером группы,

а не номером зачетки. То есть, в данном отношении существуют две многозначные зависимости:

1. группа –>> дисциплина.

2. группа –>> номер зачетки.

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

При этом возможны следующие аномалии:

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

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

Для приведения отношения в 4NF возможна декомпозиция следующего вида:

1. R1 ( номер зачетки, группа).2. R2 (группа, дисциплина ).

Пример (2): меню:

Исходное отношение: R( блюдо, повар, рецепт ). Повар умеет готовить разные блюда, одинаково названные блюда могут отличаться рецептом приготовления.

Декомпозиция:

3. R1 ( повар, блюдо). 4. R2 (блюдо, рецепт).

5NF (PJ/NF). Отношение R находится в пятой нормальной форме (норм. форме проекции-соединения) в том и только в том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R.

Определение: Отношение R (A, B, … Z) удовлетворяет зависимости соединения (А, B, … Z) в том и только в том случае, когда R восстанавливается без потерь путём соединения своих проекций на A, B, … Z (наборы атрибутов отношения R). Полной декомпозицией отношения называют такую совокупность произвольного числа его проекций, соединение которых полностью совпадает с содержимым исходного отношения.

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

Пример отношения, которое находится в 4NF, но НЕ находится в 5NF: почасовики.

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

этом случае ключом отношения является полный набор из трёх атрибутов. В отношении отсутствуют многозначные зависимости, и поэтому оно находится в 4NF. Однако в нём

нет наборов атрибутов, которые составляют возможные ключи отношения, и потому это отношение не в PJ/NF. При этом провести полную декомпозицию на два отношения нельзя.

Возможна декомпозиция следующего вида:

1. R1 ( преподаватель, кафедра).

2. R2 (преподаватель, дисциплина ).

3. R3 (кафедра, дисциплина).

Отношение, не имеющее ни одной полной декомпозиции, также находится в пятой нормальной форме.

2.1. БД в архитектуре «клиент-сервер». Требования к многопользовательским сетевым реляционным базам данных. Основные характеристики, возможности и сравнительный анализ современных сетевых реляционных баз данных.

Технология «Клиент – Сервер» подразумевает, что помимо хранения базы данных центральный компьютер (сервер базы данных) должен ещё и обеспечивать выполнение основного объёма обработки этих данных. Запрос клиента (программы-клиента) на выполнение какой-либо операции с данными провоцирует на сервере поиск и извлечение данных. Клиентская часть (Front - End) обеспечивает графический интерфейс и находится на компьютере пользователя; серверная часть (Back - End) обеспечивает управление данными, разделение информации, администрирование и безопасность. Примерами СУБД, работающих по технологии клиент-сервер, являются MS SQL Server, Oracle, IBM DB 2, SyBase.

Основной принцип технологии «клиент-сервер» применительно к технологии БД заключается в разделении функций стандартного интерактивного приложения на 5 групп, имеющих различную природу:

1.функции ввода и отображения информации (Presentation Logic);

2.прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);

3.функции отображения данных внутри приложения (Database Logic);

4.функции управления информационными ресурсами (Database Manager System);

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

Требования. Структура сервера БД. Включает следующие компоненты:

1.подсистема взаимодействия с клиентским приложением– поддержание связи с клиентом. Механизм его работы выглядит следующим образом. Подсистема взаимодействия «прослушивает» сеть в ожидании клиентских запросов на установление соединения. Когда такой запрос обнаруживается, порождается новый процесс, который будет обеспечивать связь с данным клиентом. Клиенту сообщается идентификатор данного процесса, в дальнейшем клиент передает свои запросы и получает данные, взаимодействуя с этим интерфейсным процессом. После того, как клиент закрывает соединение, обслуживающий его процесс прекращается. Характеристики интерфейсных процессов зависят от ОС, под которой исполняется сервер БД.

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

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

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

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

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

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

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

Основными достоинствами иерархической модели данных являются:

1) эффективное использование памяти ЭВМ;

2) высокая скорость выполнения основных операций над данными;

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

К недостаткам иерархической модели представления данных относятся:

1) громоздкость такой модели для обработки информации с достаточно сложными логическими связями;

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

Незначительное число СУБД построено на иерархической модели данных.

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

Достоинствами сетевой модели представления данных являются:

1) эффективность в использовании памяти компьютера;

2) высокая скорость выполнения основных операций над данными;

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

К недостаткам сетевой модели представления данных относятся:

1) высокая сложность и жесткость схемы базы данных, которая построена на ее основе;

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

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

Реляционная модель представления данных была разработана сотрудником фирмы 1ВМЭ. Коддом. Его модель основывается на понятии «отношения» (relation). Простейшим примером отношения служит двумерная таблица.

Достоинствами реляционной модели представления данных (по сравнению с иерархической и сетевой моделями) являются ее понятность, простота и удобство практической реализации реляционных баз данных на ЭВМ.

К недостаткам реляционной модели представления данных относятся:

1) отсутствие стандартных средств идентификации отдельных записей;

2) сложность описания иерархических и сетевых связей.

Большинство СУБД, применяемых как профессиональными, так и непрофессиональными пользователями, построены на основе реляционной модели данных (Visual FoxPro и Access фирмыMicrosoft, Oracle фирмы Oracle и др.).