5. Определение связей между таблицами

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

6. Усовершенствование структуры базы данных

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

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

7. Ввод данных и создание других объектов базы данных

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

8. Использование средств анализа Microsoft Access

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

Рассмотрим базовые принципы проектирования базы данных.

Моделирование реальных объектов

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

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

В примере с книжным магазином "Book-O-Rama" потребуются данные о клиентах, о продаваемых книгах и об особенностях их заказов. Книги обладают соответствующими атрибутами: ISBN, автор, название и цена. Значит, в базе данных необходимы, как минимум, три таблицы: Клиенты, Заказы и Книги.

Таблица КЛИЕНТЫ

КлиентID	Имя	Адрес	Город
1	Julie Smith	25 Oak Street	Airport West
2	Alan Wong	1/47 Haines Avenue	Box Hill
3	Michelle Arthur	357 North Road	Yarraville

Таблица ЗАКАЗЫ

ЗаказID	КлиентID	Сумма	Дата
1	3	27.50	02-Apr-2000
2	1	12.99	15-Apr-2000
3	2	74.00	19-Apr-2000
4	1	6.99	01-May-2000

Таблица КНИГИ

ISBN	Автор	Название	Цена
0-672-31697-8	Michael Morgan	Java 2 for Professional Developer	34.99
0-672-31745-1	Tomas Down	Installing Debian GNU/Linux	24.99
0-672-31509-2	Pruitt, et al.	Teach Yourself GIMP in 24 Hours	24.99

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

Избегайте хранения избыточной информации

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

ЗаказID	Сумма	Дата	КлиентID	Имя	Адрес	Город
12	199.50	25-Apr-2000	1	Julie Smith	28 Oak Street	Airport West
13	43.00	29-Apr-2000	1	Julie Smith	28 Oak Street	Airport West
14	15.99	30-Apr-2000	1	Julie Smith	28 Oak Street	Airport West
15	23.75	01-May-2000	1	Julie Smith	28 Oak Street	Airport West

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

Две основные проблемы:

1. Имеет место расточительная трата пространства на жестком диске.

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

Надо избегать трех типов аномалий обновлений: аномалию модификации, ввода и удаления.

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

2. При таком проекте потребуется вводить данные о клиенте Julie каждый раз, принимая заказ. Причем, постоянно надо проверять соответствуют ли существующие данные записанным в таблице. Если этого не делать, то вскоре в таблице могут появиться две строки с противоречащей друг другу информацией о клиенте Julie. Например, одна строка сообщает, что Julie живет в Airport West, а другая – что в Airport. Такая проблема называется аномалией ввода, т.к. появляется при вводе данных.

3. Этот тип аномалий называется аномалией удаления, т.к. появляется при удалении строк из базы данных. Если после выполнения заказ удаляется из базы данных, то, как только все текущие заказы Julie выполнены, их все удаляют из таблицы Заказы. Тогда у нас не будет записей об адресе Julie, мы не сможем присылать ей какие-то специальные предложения, и в следующий раз при новом заказе Julie придется опять собирать все данные о ней.

Использование атомарных значений столбцов

В каждом атрибуте каждой строки надо сохранять только один элемент.

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

1. В таблицу Заказы можно добавить столбец, в котором будет размещен список всех заказанных книг.

Таблица ЗАКАЗЫ

ЗаказID	КлиентID	Сумма	Дата	Заказанные книги
1	3	27.50	02-Apr-2000	0-672-31697-8
2	1	12.99	15-Apr-2000	0-672-31745-1, 0-672-31509-2
3	2	74.00	19-Apr-2000	0-672-31697-8
4	1	6.99	01-May-2000	0-672-31745-1, 0-672-31509-2, 0-672-31697-8

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

2. Вместо создания таблицы в таблице надо просто создать новую таблицу Заказанные Экземпляры, обеспечивающую связь между таблицами Заказы и Книги.

Таблица ЗАКАЗАННЫЕ_ЭКЗЕМПЛЯРЫ

ЗаказID	ISBN	Количество
1	0-672-31697-8	1
2	0-672-31745-1	2
2	0-672-31509-2	1
3	0-672-31697-8	1
4	0-672-31745-1	1
4	0-672-31509-2	2
4	0-672-31697-8	1

Эта таблица типична для случаев, когда между двумя объектами существует отношение типа "многие ко многим" – т.е. один заказ может включать в себя несколько книг, а какую-либо книгу могут заказать несколько человек.

Подбор подходящих ключей

Выбранные ключи должны быть уникальны.

Для клиентов (КлиентID) и для заказов (ЗаказID) мы создали специальные ключи, т.к. у этих реальных объектов может не оказаться идентификатора, претендующего на звание уникального. Книгам создавать такой идентификатор не надо, он у них уже есть – это ISBN. Для таблицы Заказанные Экземпляры можно добавить один ключ, но комбинация таких полей как ЗаказID и ISBN будет уникальной до тех пор, пока заказ двух или более экземпляров одной книги рассматривается как одна строка. Поэтому в таблице Заказанные Экземпляры присутствует столбец Количество.

Продумывание вопросов, которые потребуется задать базе данных

Подумайте, на какие вопросы вы хотите получить ответ от базы данных. Например, какие книги магазина "Book-O-Rama" продаются лучше других? Прежде чем ожидать точного ответа, надо убедиться, что база данных содержит всю необходимую информацию, и что между таблицами имеются надлежащие связи.

Проекты с большим количеством пустых атрибутов

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

1) Добавить столбец Рецензия в таблицу Книги. Тогда каждую книгу будет сопровождать поле с рецензией.

Таблица КНИГИ

ISBN	Автор	Название	Цена	Рецензия
0-672-31697-8	Michael Morgan	Java 2 for Professional Developer	34.99
0-672-31745-1	Tomas Down	Installing Debian GNU/Linux	24.99
0-672-31509-2	Pruitt, et al.	Teach Yourself GIMP in 24 Hours	24.99

Если в базе данных много книг и рецензент не собирается делать обзор их всех, во многих строках этот атрибут не будет иметь значения (или, как говорят, будет иметь нулевое значение).

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

2) Альтернативный вариант проекта позволяет избежать большинства проблем с нулями. Для этого создадим специальную таблицу для рецензий Рецензии книг, в которой размещаются только книги с рецензиями (рецензии прилагаются).

Таблица РЕЦЕНЦИИ КНИГ

ISBN	Рецензия

Этот проект основан на идее использования единого внутреннего рецензента. Также легко можно обеспечить клиентов рецензиями авторов, добавив в таблицу Рецензии книг столбец КлиентID.

Типы таблиц

В принципе, можно прийти к выводу, что проект базы данных состоит, как правило, из двух типов таблиц:

• Простые таблицы, описывающие реальные объекты. Они могут иметь ключи к другим простым объектам, поддерживающим отношения типа "один к одному" или "один ко многим". Например, один клиент может сделать несколько заказов, но в то же время один заказ приходит от одного клиента. Так в заказе создается ссылка на клиента.

• Связывающие таблицы, описывающие отношения типа "многие ко многим" между двумя реальными объектами. Например, между Заказы и Книги. Такие таблицы зачастую ассоциируются с некоторой реальной транзакцией.