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

6.3. Стратегия разработки приложения

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

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

Данные и информация

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

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

Отбор необходимых данных

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

Элемент данных является входным, если для выполнения задачи его необходимо прочитать в базе данных (без изменения). Например, имя и адрес клиента являются входными данными для заполнения заказа.

Подобным образом данные являются выходными для задачи, если в этой задаче они вводятся или вычисляются на основе входных данных, а затем сохраняются. Например,

адрес и телефон нового студента являются выходными для задачи ввода данных о студентах.

Данные в задаче изменяются, если они читаются в базе данных, а затем изменяются и записываются обратно. Например, задача обновления адреса студента получает старый адрес студента, изменяет его и сохраняет в базе данных новый.

Соответственно, задача удаляет данные, когда они убираются из базы данных.

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

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

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

Правило 1. Уникальность полей

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

Правило 1: Каждое поле любой таблицы должно быть уникальным.

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

Правило 2. Первичные ключи

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

первичным ключом (или просто ключом).

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

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

Правило 3. Функциональная зависимость