Проектирование БД «Садово-огородные культуры»

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

Такая база данных должна предоставить:

• информацию о фактическом составе и характеристиках садово-огородных культур;

• количественную информацию об урожайности (продуктивности) культур;

• информацию для своевременного сбора урожая (сроки созревания);

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

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

В данном варианте базы данных мы не приводим эти поля (используем только поле «Единицы измерения»).

БД и средства ее эксплуатации должны обеспечить решение следующих задач.

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

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

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

4. Обеспечить вывод на печать полного списка культур, размещенных на участке, с подсчетом их количества или площади, занимаемой отдельными группами культур.

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

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

Допустим, что после обсуждения с пользователем состава и характеристик БД мы определили два массива: массив «Группы», содержащий общие характеристики групп и массив «Культуры», содержащий характеристики культур. После исключения одинаковых полей и объединения всех полей из обоих массивов мы получили исходную реляционную информационную модель, которую можно представить в виде таблицы 4.1 «Культуры участка». Из методических соображений мы не стали включать набор общих характеристик групп (например, общее количество единиц представителей группы на участке, общие технологические параметры возделывания культур группы и др.), которые пользователь сможет добавить в процессе эксплуатации базы данных.

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

Для устранения недостатков используем процесс нормализации.

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

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

Такие модели называются нормальными формами.

Первый этап нормализации заключается в образовании таблицы, содержащей все необходимые поля информационной модели и ключевых полей. При этом необходимо исключить повторяющиеся столбцы и столбцы-массивы (содержащие значения типа списка). Фрагмент таблицы 4.1 представляет ИМ в первой нормальной форме. Однозначно определять записи будут поля «Название культуры» (далее – «Культуры») и «Группа» (т.е. мы имеем составной ключ). Все остальные поля будут функционально зависеть от этих двух.

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

В нашем случае мы имеем частичную зависимость от составного первичного ключа полей: «Сроки созревания», «Почвы», «Количество культур», «Урожай» и «Урожайность». Значения этих полей зависят от поля «Культуры» и не зависят непосредственно от поля «Группы». А поле «Ед. измерения» зависит от поля «Группы».

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

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

Для связывания таблиц добавим в таблицу специальное числовое поле «Код_Гр», что позволит (без ущерба удобству эксплуатации) значительно быстрее выполнять запросы, экономить память (особенно во второй таблице) и упростит ввод данных.

Структура таблицы «Группы» и некоторые данные приводятся в таблице 4.2. Ключевым столбцом в этой таблице будет «Код_Гр».

Замечание

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

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

Для связи таблиц будем использовать числовое поле «Код_Гр». Это поле будет использоваться и для группировки культур при выполнении запросов и в отчетах БД.

Таблица 4.1