Проектирование автоматизированных информационных систем (стр. 3 из 4)

Сущность «Клиенты»:

· код клиента (ключевое поле);

· организация;

· адрес;

· индекс;

· телефон;

· город;

· регион;

· страна;

· описание счета;

· факс.

Сущность «Объекты недвижимости»:

· код объекта недвижимости (ключевое поле);

· наименование;

· категория;

· физический адрес;

· страна;

· код владельца;

· описание;

· стоимость.

Сущность «Заказы»:

· код заказа (ключевое поле);

· код клиента;

· наименование;

· код сотрудника;

· сумма заказа;

· дата размещения;

· дата оплаты.

Сущность «Владельцы»:

· код владельца (ключевое поле);

· организация;

· адрес;

· индекс;

· телефон;

· город;

· регион;

· страна;

· описание счета;

· факс.

Сущность «Сотрудники»:

· код сотрудника (ключевое поле);

· фамилия;

· имя;

· отчество;

· домашний адрес;

· рабочий телефон.

2.4 Нормализация модели

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

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

Данные, представленные в виде двумерной таблицы, являются первой нормальной формой реляционной модели данных.

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

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

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

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

Транзитивная зависимость выявляет дублирование данных в одном отношении. Если А, В и С – три атрибута одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А. Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два.

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

Рисунок 8 – Схема взаимосвязей сущностей после нормализации модели

2.5 Физическое описание модели

Модель реализована в СУБД Microsoft Access 2002. В соответствии с изложенным выше, физическая модель состоит из семи таблиц, описание полей которых приведены в таблице 2.

Таблица 2 – Перечень объектов и их атрибутов

Наименование поля	Примечание	Тип поля	Ограничение
Таблица «Объекты недвижимости»
Ключ объекта недвижимости	Первичный ключ, индексированное	Счётчик
Наименование	Текстовое	50
Ключ категории	Индексированное, для связи с таблицей «Категории»	Числовое	Целое положительное
Физический адрес	Текстовое	200
Ключ страны	Индексированное, для связи с таблицей «Страны»	Числовое	Целое положительное
Ключ владельца	Индексированное, для связи с таблицей «Владельцы»	Числовое	Целое положительное
Описание	Поле примечания	Memo
Стоимость	Денежный	Положительное

Продолжение таблицы 2

Наименование поля	Примечание	Тип поля	Ограничение
Таблица «Владельцы»
Ключ владельца	Первичный ключ, индексированное	Счётчик
Организация	Текстовое	50
Адрес	Текстовое	200
Индекс	Числовое	Целое положительное
Телефон	Текстовое	15
Город	Текстовое	50
Регион	Текстовое	50
Ключ страны	Индексированное, для связи с таблицей «Страны»	Числовое	Целое положительное
Описание счёта	Поле примечания	Memo
Факс	Текстовое	15
Таблица «Клиенты»
Ключ клиента	Первичный ключ, индексированное	Счётчик
Организация	Текстовое	50
Адрес	Текстовое	200
Индекс	Числовое	Целое положительное
Телефон	Текстовое	15
Город	Текстовое	50
Регион	Текстовое	50
Ключ страны	Индексированное, для связи с таблицей «Страны»	Числовое	Целое положительное
Описание счёта	Поле примечания	Memo
Факс	Текстовое	15

Продолжение таблицы 2

Наименование поля	Примечание	Тип поля	Ограничение
Таблица «Заказы»
Ключ заказа	Первичный ключ, индексированное	Счётчик
Ключ клиента	Индексированное, для связи с таблицей «Клиенты»	Числовое	Целое положительное
Ключ объекта	Индексированное, для связи с таблицей «Объекты»	Числовое	Целое положительное
Ключ сотрудника	Индексированное, для связи с таблицей «Сотрудники»	Числовое	Целое положительное
Сумма заказа	Вычисляемое программно	Денежное	Положительное
Дата размещения	Дата
Дата оплаты	Дата
Таблица «Сотрудники»
Ключ сотрудника	Первичный ключ, индексированное	Счётчик
Фамилия	Текстовый	20
Имя	Текстовый	20
Отчество	Текстовый	20
Домашний адрес	Текстовое	50
Рабочий телефон	Числовое	7
Таблица «Категории»
Ключ категории	Первичный ключ, индексированное	Счётчик
Категория	Текстовое	50
Таблица «Страны»
Ключ страны	Первичный ключ, индексированное	Счётчик
Страна	Текстовое	50

2.6 Обоснование выбора СУБД

Microsoft Access – это самая популярная сегодня настольная система управления базами данных. Ее успех можно связывать с великолепной рекламной кампанией, организованной Microsoft, или включением ее в богатое окружение продуктов семейства Microsoft Office. Вполне возможно, что это так. Но корень успеха, скорее всего, заключается в прекрасной реализации продукта, рассчитанного как на начинающего, так и квалифицированного пользователя. Не будем сейчас вдаваться в подробности сравнения отдельных характеристик Access и его основных конкурентов, например Paradox for Windows или Lotus Approach. Эта тема прекрасно освещена в периодической компьютерной печати.

СУБД Access 2002 для работы с данными использует процессор баз данных Microsoft Jet 4.0, объекты доступа к данным и средство быстрого построения интерфейса — Конструктор форм. Для получения распечаток используются Конструкторы отчетов. Автоматизация рутинных операций может быть выполнена с помощью макрокоманд. На тот случай, когда не хватает функциональности визуальных средств, пользователи Access могут обратиться к созданию процедур и функций. При этом как в макрокомандах можно использовать вызовы функций, так и из кода процедур и функций можно выполнять макрокоманды.