Пятая нормальная форма· форма, в которой устранены зависимости соединения. Таблицу, находящуюся в четвертой нормальной форме и, казалось бы, уже нормализованную до предела, в некоторых случаях еще можно бывает разбить на три или более (но не на две!) таблиц, соединив которые, мы получим исходную таблицу. Получившиеся в результате такой, как правило, весьма искусственной, декомпозиции таблицы и называют находящимися в пятой нормальная форме. В большинстве случаев практической пользы от нормализации таблиц до пятой нормальной формы не наблюдается. Зачастую, чтобы извлечь информацию из нормализованной базы данных, приходится конструировать очень сложные запросы, которые к тому же, бывает, работают довольно медленно - из-за, главным образом, большого количества соединений таблиц. Поэтому, чтобы увеличить скорость выборки данных и упростить программирование запросов, нередко приходится идти на выборочную денормализацию базы. Задание для самостоятельной работы На примере базы данных, которая содержит следующую информацию: Номер накладной, Дата, Имя заказчика, Адрес заказчика, телефон заказчика, Расчетный счет заказчика (20 цифр), Товар, кол-во, цена за ед., единицы измерения, сумма за товар рассмотреть варианты приведения БД к первой, второй и третьей нормальным формам. Нормализация таблиц позволяет устранить из них избыточную информацию, что приводит к уменьшению размера базы данных. В тоже время чрезмерное увлечение нормализацией может привести к тому, что поиск по БД будет идти очень медленно, поскольку СУБД должна будет считывать данные из нескольких таблиц, тратя время на их открытие, просмотр и закрытие. Поэтому необходимо определить, что является наиболее важным: размер базы или скорость поиска. При грамотном использовании нормализации разработчиком, пользователь получает логически выстроенную, удобную в использовании и компактную базу данных. Пример 8: База Данных (БД) содержит следующую информацию: Наименование клиента, Адрес клиента, Номер счета Клиента, ФИО обслуживающего агента, Номер офиса обслуживающего агента, Адрес офиса, Телефон офиса, Сумма всех договоров агента, Номер договора, Дата заключения договора, Сумма по контракту. Привести БД к первой, второй и третьей нормальным формам. Приведем базу данных к первой нормальной форме. В базе данных есть поля, которые можно разделить на несколько неделимых. Это поля Адрес, ФИО. Разобьем поля Адрес, считая, что все клиенты и офисы находятся в России. Адрес клиента (Город Клиента, Индекс клиента, Улица клиента, Номер дома клиента, Номер комнаты). Адрес Офиса(Город офиса, Индекс офиса, Улица офиса, Номер дома офиса, Номер комнаты). Поле ФИО обслуживающего агента, делим на три поля: Фамилия агента, Имя агента, Отчество агента. В базе нет полей, которые можно было бы рассматривать как однотипные. Таким образом, приведение к первой нормальной форме можно считать законченным и набор полей базы данных:
Приведем базу данных ко второй нормальной форме. Для этого необходимо определить первичный ключ. Если внимательно посмотреть на приведенный список полей, то станет ясно, что это база данных, хранящая перечень договоров некой фирмы. Любое из приведенных полей может иметь повторяющиеся значения, поэтому первичный ключ будет состоять как минимум из двух полей. В качестве первичного ключа таблицы Договор можно выбрать Дату и Номер договора, поскольку в один и тот же день нельзя подписать договор с одинаковым номером. Поле Наименование клиента зависит от первичного ключа, а вся остальная информация о клиенте от первичного ключа не зависит, но зависит от поля Наименование клиента. В связи с этим выделим эти поля в отдельную таблицу Клиенты. Далее Фамилия обслуживающего агента зависит от первичного ключа, а вся остальная информация об агенте от первичного ключа не зависит, поэтому выделим эти поля в отдельную таблицу Агенты. Будем считать, что в фирме нет однофамильцев, поэтому в новой таблице в качестве первичного ключа выбираем Фамилию агента. Остальные поля таблицы Договор зависят от первичного ключа. В таблице Агенты от ключа (поле Фамилия агента) не зависят поля, хранящие адрес офиса и телефон офиса, поэтому выделим их в отдельную таблицу Офисы. Таким образом, структура базы данных примет вид:
Приведем базу данных к третьей нормальной форме. В таблице Агенты есть поле Сумма всех договоров Агента. Значение этого поля зависит от значений поля Сумма по договору и может быть вычислена на этапе создания отчета или запроса. Таким образом, это поле убираем из базы данных. Других таких полей нет. Связи между таблицами: После создания таблиц, содержащих данные, относящиеся к различным аспектам базы данных, необходимо продумать, каким образом Microsoft Access будет объединять эти данные при их извлечении из базы данных. Первым шагом при этом является определение связей между таблицами. Только после этого становится возможным создание запросов, форм и отчетов, в которых выводятся данные из нескольких таблиц сразу. Связь между таблицами устанавливает отношения между совпадающими значениями в ключевых полях, обычно между полями разных таблиц, имеющими одинаковые имена. Различают три вида связей: один-к-одному, один-ко-многим, многие-ко-многим. Связь с отношением один-к-одному создается в том случае, когда оба связываемых поля являются ключевыми или имеют уникальные индексы При связи один-к-одному запись в таблице A может иметь не более одной связанной записи в таблице B и наоборот. Связь с отношением один-к-одному используют для разделения очень широких таблиц, для отделения части таблицы по соображениям защиты, а также для сохранения сведений, относящихся к подмножеству записей в главной таблице. Связь один-ко-многим создается в том случае, когда только одно из полей является ключевым или имеет уникальный индекс. В такой связи каждой записи в таблице A могут соответствовать несколько записей в таблице B, а запись в таблице B не может иметь более одной соответствующей ей записи в таблице A. Связь с отношением многие-ко-многим фактически является двумя связями с отношением один-ко-многим через третью таблицу, ключ которой состоит из по крайней мере двух полей, которые являются полями внешнего ключа в двух других таблицах. При отношении многие-ко-многим одной записи в таблице A могут соответствовать несколько записей в таблице B, а одной записи в таблице B несколько записей в таблице A. Такая схема реализуется только с помощью третьей (связующей) таблицы, ключ которой состоит из, по крайней мере, двух полей, которые являются полями внешнего ключа в таблицах A и B. В рассматриваемом примере с вязь один-ко-многим. Для установки связи между таблицами Клиенты и Договор в таблицу Договор добавим поле Наименование клиента. Для установки связи между таблицами Агенты и Договор в таблицу Договор добавим поле Фамилия обсл. Агента. Для установки связи между таблицами Офисы и Агенты в таблицу Агенты добавим поле Номер офиса обсл. Агента. В результате получим следующие связи между таблицами: Клиенты (Наименование клиента) – Договор (Наименование клиента); Агенты (Фамилия обсл. Агента) – Договор (Фамилия обсл. Агента); Офисы (Номер офиса) – Агенты (Номер офиса обсл. Агента). Окончательный вид структуры базы данных:
Итак, разработка структуры базы данных завершена. Переходим к непосредственной работе с СУБД Access. Задание для самостоятельной работы База Данных (назовем базу данных Товар-Накладная) содержит следующую информацию: Номер накладной, Дата, Имя заказчика, Адрес заказчика, телефон заказчика, Расчетный счет заказчика (20 цифр), Товар, кол-во, цена за ед., единицы измерения, сумма за товар. Привести БД к первой, второй и третьей нормальным формам, установить связи между таблицами.
|
Номер договора
Дата заключения договора
Наименование клиента
Фамилия обсл. Агента
Сумма по договору
