Мастера Access

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

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

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

Для изменения вида формы, отчета или отдельных элементов мо­жет быть использован мастер, вызываемый кнопкой [Автоформат].

Мастер подстановок создает в поле таблицы раскрывающийся список значений из другой таблицы для выбора и ввода нужного значения. Для создания такого поля со списком достаточно в режиме конструктора таблицы выбрать тип данных этого поля — Мастер подстановок. Мастер подстановок можно вызвать в режиме таблицы командой меню Вставка\Столбец подстановок. Создан­ный в данном поле таблицы список наследуется при включении этого поля в форму.

Мастера по импорту/экспорту позволяют просматривать данные при импорте/экспорте текста или электронных таблиц, а также при экспорте данных Microsoft Access в текстовые файлы.

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

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

Работа в СУБД Access подчиняется общим принципам (см. выше) и планируется обычно следующим образом:

• построение информационно-логической модели данных предметной области;

• определение логической структуры реляционной базы данных;

• конструирование таблиц базы данных;

• создание схемы данных;

• ввод данных в таблицы (создание записей);

• разработка необходимых форм, запросов, макросов, модулей, отчетов;

• разработка пользовательского интерфейса.

Нормализация

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

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

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

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

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

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

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

• запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию)

• запрещает множественные столбцы (содержащие значения типа списка и т.п.)

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

Пример 1: поле ФИО можно разделить на три отдельных поля Фамилия, Имя, Отчество.

Пример 2: нельзя использовать поле Адрес, нужно использовать набор полей: Улица, Номер дома, Квартира, Город.

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

Повторяющимися являются поля, содержащие одинаковые по смыслу значения.

Пример 3: Пусть имеется некое предприятие, продающее крупы. Для предприятия была создана база данных содержащая, помимо данных о накладной и клиенте, еще и такие поля как Сахар, Соль, Мука, Гречка, Рис, Пшено, в которых хранится количество отпущенного товара. Каждое поле базы данных вне зависимости от того содержит оно информацию или нет, все равно занимает место в памяти, то есть размер, занимаемый пустой записью и полностью заполненной записью одинаков. Предположим, что дела у компании пошли хорошо и она смогла расшириться и стала продавать еще и молокопродукты. Если оставить структуру не тронутой, то в таблицу необходимо добавить новые поля, причем уже имеющиеся записи будут изменены. А если далее число продуктов, продаваемых фирмой превысит хотя бы сотню, то будет ли удобно ориентироваться в такой таблице? В подобной ситуации следует заметить, что все приведенные поля суть наименование товара и хранят они лишь количество товара, поэтому достаточно использовать всего два поля: Товар, Количество.

Клиент	Накладная	Товар	Количество	Единица измерения
Иванов	1257836	Сахар	100	кг
Петров	6571234	Соль	50	кг

Пример 4: Приведение таблицы к 1НФ.

Неприведенная

ФИО	Тетради	Карандаши	Ручки	Ластики
Иванов Иван Иванович		15
Петров Петр Петрович	10

Приведенная к 1НФ

Фамилия	Имя	Отчество	Канц. тов.	Кол-во
Иванов	Иван	Иванович	Карандаши	15
Петров	Петр	Петрович	Тетради	10

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

• требует, чтобы не ключевые столбцы таблиц зависели от первичного ключа в целом, но не от его части.

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

Можно выделить три типа ключевых полей: счетчик, простой ключ и составной ключ.

Ключевые поля счетчика

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

Простой ключ

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

Составной ключ

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

Если определить подходящий набор полей для составного ключа сложно, просто добавьте поле счетчика и сделайте его ключевым. Например, не рекомендуется определять ключ по полям «Имена» и «Фамилии», поскольку нельзя исключить повторения этой пары значений для разных людей.

Пример 5: Предположим у нас есть таблица для отпуска товара по накладным. Эту таблицу мы должны привести ко второй нормальной форме.

Накладные

Дата

Номер

Покупатель

Счет покупателя

Город покупателя

Телефон покупателя

Товар

Количество

Сумма

Первичным ключом здесь являются поля Дата и Номер. Поля: Счет, Город и Телефон – зависят только от поля Покупатель, но не от первичного ключа, поэтому их можно выделить в отдельную таблицу под названием Клиенты.

Накладные
Дата	1	Покупатель
 Номер		Счет покупателя
Покупатель		Город покупателя
Товар		Телефон покупателя
Количество
Сумма

Таким образом, мы привели БД Накладные ко второй нормальной форме.

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

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

Примечание:

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

Пример 6: Типичным примером может служить связка полей: Цена за единицу, Количество, К оплате. Дело в том, что значение поля К оплате зависит от полей Цена за единицу и Количество. Значение поля К оплате можно вычислять в процессе создания отчета или запроса, но хранить его в Базе данных вовсе не обязательно.

Нормальная форма Бойса-Кодда

• требует, чтобы в таблице был только один потенциальный первичный ключ.

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

Четвертая нормальная форма

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

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

• форма, в которой устранены зависимости соединения.

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

Задание для самостоятельной работы

На примере базы данных, которая содержит следующую информацию: Номер накладной, Дата, Имя заказчика, Адрес заказчика, телефон заказчика, Расчетный счет заказчика (20 цифр), Товар, кол-во, цена за ед., единицы измерения, сумма за товар рассмотреть варианты приведения БД к первой, второй и третьей нормальным формам.

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

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

Задание для самостоятельной работы

База Данных (назовем базу данных Товар-Накладная) содержит следующую информацию: Номер накладной, Дата, Имя заказчика, Адрес заказчика, телефон заказчика, Расчетный счет заказчика (20 цифр), Товар, кол-во, цена за ед., единицы измерения, сумма за товар.

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