Рефераты. Информационная система автосервиса

Таблица 4 - Описание полей таблицы Состав Ремонта

Имя поля

Тип данных

Свойства поля

Ремонт

Текстовый

длина 50 символов, ключевое

Ремонтируемый узел

Текстовый

длина 50 символов, обязательное

Работник

Текстовый

длина 50 символов, обязательное

Таблица 5 - Описание полей таблицы Простой Ремонт

Имя поля

Тип данных

Свойства поля

Заявка

Текстовый

длина 50 символов, обязательное

Ремонт

Текстовый

длина 50 символов, ключевое

Работник

Текстовый

длина 50 символов, обязательное

Таблица 6 - Описание полей таблицы Контрагенты

Имя поля

Тип данных

Свойства поля

Фамилия

Текстовый

длина 50 символов, обязательное

Скидка

числовой

Длинное целое

Таблица 7 - Описание полей таблицы Работники

Имя поля

Тип данных

Свойства поля

Ремонт

Текстовый

длина 50 символов, ключевое

Отдел

Текстовый

длина 50 символов, обязательное

Работник

Текстовый

длина 50 символов, обязательное

Таблица 8 - Описание полей таблицы Ремонт Узла

Имя поля

Тип данных

Свойства поля

Ремонт

Текстовый

длина 50 символов, ключевое

Узел

Текстовый

длина 50 символов, обязательное

Цена

Числовой

Длинное целое

Срок

Числовой

Длинное целое

Схема данных

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

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

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

- первая нормальная форма (1NF);

- вторая нормальная форма (2NF);

- третья нормальная форма (3NF);

- нормальная форма Бойса - Кодда (BCNF);

- четвертая нормальная форма (4NF);

- пятая нормальная форма, или форма проекции-соединения (5NF или PJNF).

Была проведена нормализация базы данных до 3 НФ.

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

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

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

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

Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей.

2. Разработка клиентской программы на Delphi для взаимодействия с базой данных Access

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

2.1. Разработка структуры программного обеспечения

Согласно поставленного задания, наша программа должна:

Подключаться к базе данных Access (с возможностью выбора файла данных);

Предоставлять возможность просмотра таблиц (включая возможность сортировки);

Обеспечивать возможность редактирования информации в таблицах;

Показывать информацию о программе.

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

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

13

Рисунок 1.1. - Структура программы.

Как видно из приведенного рисунка, самым “функционально нагруженным” у нас является модуль даны. Основная форма ничего не знает о базе данных и о реализации форм просмотра/редактирования таблиц. Все что должна знать Основная форма программы, так это какие действия предусмотрены для реализации необходимой нам функциональности. Мы это обеспечиваем с помощью класса TActionList. Именно в экземпляре этого класса мы храним весь список действий со всеми необходимыми атрибутами (подпись, пиктограмма, строка-подсказка и, собственно, метод реализующий это действие). Такой подход предоставляет нам возможность реализовать несколько разных вариантов основной формы, не затрагивая архитектуру и функциональность всей программы (см. рис.1.2. и рис 1.3).

Рисунок 1.2. - Основная форма программы при использовании ToolBar и MainMenu

Рисунок 1.3. - Основная форма программы при использовании BitBtn и MainMenu

2.2. Организация доступа к базе данных

1.2.1. Разработка и реализация информационных потоков

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

13

Рисунок 1.4. - Схематическое изображение информационных потоков.

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

1.2.2. Подключение к базе данных по технологии ADO

Для доступа к базе данных мы используем ADOConnection. В отличие от других способов доступа к БД в нашем случае для подключения нет возможности использовать привычные свойства DataBaseName и AliasName. При использовании технологии ADO вместо этих свойств используются строки соединения (connection string) и все параметры соединения отображаются и настраиваются именно в них. Существует два основных способа настройки строки соединения - вручную и в специальном диалоговом окне. При собственноручной настройке легко ошибиться в параметрах. И поэтому, большинство разработчиков идет по пути использования редактора строки соединения. Единственный, на наш взгляд, недостаток такого подхода - это привязка к конкретному пути к файлу базы данных. Чтобы избежать недостатков обоих подходов мы пошли по среднему варианту - для первого подключения к базе данных при разработке программы в инспекторе объектов мы использовали редактор строки соединения. И получили правильную строку. Затем, проанализировав ее содержимое, мы увидели в какой части строки хранится информация об имени и пути к файлу базы данных. Теперь, используя элементарные операции для работы со строковым типом данных в Delphi мы можем заменять эту часть строки соединения на любой другой нужный нам файл данных. Это выполняется у нас двумя способами. Первый - автоматически при запуске программы определяется текущий каталог и первое подключение осуществляется к файлу базы данных, который находится в том же каталоге, где и наша программа. Имя файла базы данных (за исключением его расширения) должно совпадать с именем программы. Реализация этого приведена на листинге 1.1. А второй способ - это возможность пользователя нашей программы подключиться к необходимому ему файлу (разумеется, структура базы данных должна совпадать) путем использования диалога выбора файла в форме настройки параметров. (см. рис.1.5, 1.6)

Листинг 1.1. - Фрагмент программы, реализующий автоподключение к БД

procedure TForm5. BitBtn1Click(Sender: TObject);

begin

// Переподключение к БД с заданной строкой подключения

dm. ADOConnection1. Close;

dm. ADOConnection1. ConnectionString: =edit1. Text+edit2. Text+ edit3. Text;

end;

procedure TForm5. FormActivate(Sender: TObject);

begin

// Автоматическое определение имени файла БД и пути к нему

Edit2. Text: = ChangeFileExt(application. ExeName,'. mdb');

BitBtn1Click(Sender);

end;

Рисунок 1.5. - Форма ввода параметров

Рисунок 1.6. - Диалог выбора файла базы данных

1.2.3. Разработка универсальной формы для просмотра/редактирования таблиц базы данных

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

Не создавать полей в компоненте ADOTable на этой форме.

Не создавать столбцов в компоненте DBGrid, который подключен через DataSource к ADOTable на этой форме.

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

Записывать название таблицы в заголовке формы при ее открытии.

Для обеспечения возможности работы в режиме просмотра мы должны только установить свойство ReadOnly компонента ADOTable в состояние True. С учетом всего вышесказанного, вызов универсальной формы должен осуществляться так, как на Листинге 1.2:

Листинг 1.2. - Фрагмент модуля данных, осуществляющий вызов формы для просмотра/редактирования таблиц базы данных.

procedure Tdm. ShowSlovar (aname: string; RO: boolean=true);

var

f: TForm4;

begin

// Метод реализующий вызов формы просмотра/редактирования таблиц

// aname - имя таблицы

// RO - режим доступа

f: =TForm4. Create(self);

f. ADOT. TableName: =aname;

f. Caption: =aname;

if RO then

begin

f. ADOT. ReadOnly: =RO;

f. Caption: =f. Caption+' (только чтение) ';

end;

f. ShowModal;

f. Free;

end;

Для реализации возможности сортировки мы используем локальные индексы. Это продемонстрировано на Листинге 1.3.

Листинг 1.3. - Фрагмент программы для сортировки таблиц

procedure TForm3. DBGrid1TitleClick(Column: TColumn);

var i: integer;

begin // Сортировка

// Убираем расскраску стобцов

for i: =0 to DBGrid1. Columns. Count-1 do

begin

DBGrid1. Columns. Items [i]. Color: =clwhite;

end;

Column. Color: =clLime;

if ADOT. IndexFieldNames=Column. Field. FieldName

then

begin

// Если была прямая сортировка, устанавливаем обратную

Column. Color: =clLime;

ADOT. IndexFieldNames: =Column. Field. FieldName+' DESC'

end

else

begin

// Если не было сортировки по этому полю (или обратная)

// устанавливаем прямую сортировку

Column. Color: =clAqua;

ADOT. IndexFieldNames: =Column. Field. FieldName;

end;

end;

В результате мы получили форму, пример использования которой приведен на рис.1.7.

Рисунок 1.7. - Внешний вид универсальной формы при работе с таблицей РемонтУзлов в режиме просмотра.

Заключение

В данной работе была спроектирована и реализована информационная - справочная система "Автосервис", обеспечивающая:

ввод, редактирование и просмотр данных;

ответы на запросы пользователя;

поиск необходимой информации;

формирование отчетов.

Освоены навыки проектирования баз данных методом ER-диаграмм.

Реализация системы проводилась с использованием инструментального средства разработки приложения Microsoft Access2003/XP и языка программирования Object Pascal.

При написании программы основное внимание было уделено удобству работы пользователя с программой и построению дружественного интерфейса.

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

Список литературы

1. Хохлачев Е.Н. "Теоретические основы создания и применения АСУ", Москва, Министерство обороны, 1987г.

2. Абчук В.А., Лифшиц А.Л., Федулов А.А., Куштина Э.И. "Автоматизация управления", Москва "Радио и связь", 1984г.

3. Мамиконов А. Г. "Проектирование АСУ" (учебник для вузов), Москва "Высшая школа".

4. Ахаян Р., Горев А., Макашарипов С. "Эффективная работа с СУБД", Санкт-Петербург, 1997г.

5. Гончаров A. "Access 2000 в примерах" Санкт-Петербург, 1997г.

6. Фленов М.Е. Библия Delphi. -2-e изд., БВХ-Петербург, 2008 г.

Страницы: 1, 2, 3



2012 © Все права защищены
При использовании материалов активная ссылка на источник обязательна.