10.13. Система управления базами данных ms Access

В последнее время при создании несложных БД особой популярностью пользуется СУБД MS Access, которая является продуктом компании Microsoft, USA и входит в состав ППП, объединенных общим названием Microsoft Office. Во многом своей популярностью Access обязана тому обстоятельству, что комбинация Microsoft Windows + Microsoft Office является стандартным и универсальным ПО офисного делопроизводства.

СУБД Access обеспечивает:

• набор средств для управления данными и обеспечения целостности данных;

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

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

С помощью СУБД Access имеется возможность:

• выбирать информацию, представляющую интерес, например, сведения о покупках определенного клиента;

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

• отображать данные в графическом виде;

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

СУБД Access относится к реляционным СУБД.

Подробно рассмотрим основные понятия реляционных БД.

Этими понятиями являются таблица, отношение, индексы, первичный и внешний ключи.

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

• код потребителя;

• код детали;

• дата поступления;

• количество заявленных деталей;

• дата выполнения;

• количество отпущенных деталей;

• цена отпускная.

Записи о заявках размещаются в книге регистрации в табличном виде в хронологическом порядке (рис.10.5). Каждую строку можно рассматривать как единичную запись.

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

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

Номер заявки	Код потребителя	Код детали	Дата поступления	Заказано	Дата выполнения	Отпущено	Цена отпускная
1	2	3	1.01.02	10	12.01.02	8	1,025.00
2	2	1	2.01.02	2	12.01.02	2	2,600.00
3	2	2	3.01.02	15	17.01.02	15	625.00
4	6	2	5.01.02	20	23.01.02	20	620.00
5	7	8	5.01.02	50	23.01.02	50	27.00

Рис.10.5. Таблица «Книга регистрации заявок»

В рассматриваемой таблице имеются поля «Код потребителя», «Код детали», «Цена отпускная» и др. На рис.5 двойной линией выделены одна запись и одно поле в книге регистрации заказов.

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

Таблица 10.1.

№ пп.	Тип поля	Описание
1	Текстовый	Может содержать буквы, цифры и специальные символы. Длина поля – не более 255 символов
2	Числовой	Может содержать только цифры
3	Денежный	Может содержать только цифры + символ денежного знака (например, 5 $, 700 руб.)
4	Счетчик	Содержит только натуральные неповторяющиеся числа для счета записей таблицы
5	Дата, время	Может содержать цифры и буквы в различных форматах, принятых для отображения даты и времени
6	Логический	Может содержать одно из двух возможных значений «Истина» или «Ложь»
7	Текстовый произвольной длины	Может содержать те же символы, что и поле типа 1. Длина поля до 65535 символов
8	Объектный	Любой объект Windows – рисунок, таблица Excel, документ Word и другие.
9	Гиперссылки	Адрес гиперссылки в Internet

Каждая таблица имеет уникальное имя в БД.

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

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

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

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

• обеспечение быстрого доступа к данным;

• исключение ненужного повторения данных (избыточности);

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

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

В качестве примера рассмотрим таблицу «Продажи», которая содержит следующую информацию:

• сведения о покупателях;

• дату заказа и количество заказанного товара;

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

• характеристику проданного товара.

Структура таблицы «Продажи» приведена на рис.10.6.

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

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

• при изменении адреса или телефона покупателя необходимо корректировать все записи, содержащие все сведения о заказах этого покупателя;

• наличие повторяющейся информации приведет к неоправданному увеличению размеров БД. Отсюда снижение скорости выполнения запросов и неэффективное использование дискового пространства ПК;

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

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

Информация о каждом клиенте фиксируется одной записью в таблице «Клиенты». Каждый клиент имеет свой уникальный код – «Код клиента». Это позволяет обеспечить отсутствие повторяющихся записей в таблице. Здесь повторяющиеся записи – это такие записи, между которыми нет никаких различий ни в одном из полей. Поле «Код клиента» в данной таблице будет уникальным индексом.

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

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

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

Продолжим описание реляционной структуры БД «Продажи».

Поскольку каждый покупатель может сделать несколько заказов, помимо таблицы «Клиенты» следует иметь таблицу «Заказы», которая будет содержать информацию о каждом из заказов.

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

Для исключения повторяющихся записей в таблице «Заказы» строится уникальный составной индекс – первичный ключ, в соответствии с конструкцией «Код клиента» + «Код товара» + «Дата заказа» (рис.1.10). Логично принять эту конструкцию ключа, если считать, что клиент N товар M не будет заказывать более 1-го раза в один день D.

Для полного исключения избыточности данных необходимо иметь еще две таблицы (рис.1.9) – «Товары» и «Менеджер». Так, в таблице «Товары» ведется список всех товаров, а в таблице «Менеджер» размещены данные о руководителях фирм.

Первичным ключом в таблице «Товары» является простой индекс на основе поля «Код товара», а в таблице «Менеджер» – простой индекс на основе поля «Предприятие».

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

Рис.10.6. Структура таблицы «Продажи»

Поле 1	Поле 2	Поле3	…	Поле 12	Поле 13	Поле 14	Поле 15	…
Код клиента	Фамилия	Имя	…	Код товара	Дата заказа	Заказано	Дата продажи
1	Петров	Алексей		10	12.01.02	8	13.01.02
2	Иванов	Иван		2	12.01.02	2	14.01.02
2	Иванов	Иван		15	17.01.02	15	18.01.02
3	Сидоров	Самсон		20	23.01.02	20	27.01.02
1	Петров	Алексей		50	23.01.02	50	23.01.02

Рис.10.7. Таблица «Продажи»

Рис.10.8. Схема отношений реляционной БД «Продажи»

Рис.10.9. Таблицы «Клиенты» и «Заказы»

Отношения между объектами определяют отношения между таблицами, которые эти объекты представляют. Например, предполагается, что один и тот же покупатель может сделать несколько заказов. Таким образом, между покупателями и сделанными ими заказами существует отношение «один-ко-многим». Как уже было сказано, связь таблиц «Клиенты» и «Заказы» осуществляется на основании данных в совпадающих полях «Код клиента».

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

Кроме отношения типа «один-ко-многим» Access поддерживает еще три типа отношений: «один-к-одному», «много-к-одному», «много-ко-многим».

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

Отношение «много-к-одному» аналогично отношению «один-ко-многим». Тип отношения между объектами зависит от точки зрения. Если рассматривать отношение между заказами и клиентами, то будем иметь отношение «много-к-одному» (рис.10.8 и 10.9).

Отношение «много-ко-многим» возникает между двумя таблицами в тех случаях, когда:

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

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

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

Итак, рассмотрены основополагающие понятия реляционных БД применительно к СУБД Access. Знание этих понятий является необходимым для успешного освоения и работы с этим программным продуктом.

16