Продажа авиабилетов в кассе (средствами MS Excel, Delphi)

Размещено на http://www.allbest.ru/

Федеральное государственное бюджетное

Образовательное учреждение

Высшего профессионального образования

«Горно-алтайский государственный университет»

Экономический факультет

Кафедра бухгалтерского учета и информационных систем в экономике

Курсовая работа

По курсу «Информатика и программирование»

Продажа авиабилетов в кассе (средствами MS Excel, Delphi)

Работу выполнил:

студент 2-го курса ЭФ

Черных Евгений Владимирович

Научный руководитель:

Кыров Виктор Николаевич

Горно-Алтайск 2012

Содержание.

• Введение
• Глава 1. Обзор программ баз данных
• 1.1 Что такое база данных
• 1.2 Механизм СУБД
• 1.3 Средства для разработки клиенской части приложения
• 1.4 Реаляционная модель
• 1.5 Атрибуты
• 1.6 Роль пользовательского интерфейса в системе
• 1.7 Компиляция и выполнение проекта
• 1.8 Разработка приложения
• 1.9 Среда интегральной среды разработки
• 1.10 Структура программы
• 1.11 Процедуры
• 1.12 Использование надписей
• Глава 2. Работа в программной среде Delphi и Excel
• 2.1 Разработка программы
• 2.2 Знакомство с интерфейсом программы
• 2.3 Разработка базы данных
• 2.4 Разработка программы в Delphi
• 2.5 Актуальность моей представленой программы
• Заключение
• Список литературы

Введение

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

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

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

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

Работа представлена в виде программы, которая содержит в себе:

1. Таблицы: воздушные судна, места, стоимость билетов, свободные места.

2. Запросы: на удаление, дополнение, обновление, на создание таблицы.

Глава 1. Обзор программ баз данных

автоматизация авиабилет delphi excel

1.1 Что такое база данных

Терминология, используемая в области баз данных, включает множество нюансов, столь же тонких, как например, употребление термина «объектно-ориентированное программирование». Само понятие «база данных» может обозначать как отдельный набор данных (например, список телефонов), так и гораздо более сложную систему (например, SQL Server). Можно привести еще множество примеров, не столь простых, как адресная книга, и не столь сложных, как SQL Server и, тем не менее, объединенных одним общим названием «база данных». Такая нечеткость определений отнюдь не является недостатком -- это просто свойство языка. Попытаемся внести ясность в этот вопрос (Рис 1.) показана взаимосвязь между терминами. Предметная область имеет сложную структуру и неупорядочена -- и это естественно, ведь если бы она была простой и упорядоченной, нам не понадобилась бы ее реляционная модель. Но для успешной реализации проекта необходимо ограничить проектируемую систему определенными рамками, в которые будет входить отдельная, четко определенная совокупность объектов и связей между ними. Только после этого вы сможете правильно оценить масштабы проектируемой системы. Под термином модель данных договоримся понимать концептуальное описание предметной области. Она включает определения сущностей и их атрибутов: например, сущность Customer (Покупатель) может иметь атрибуты Name (Имя) и Address (Адрес). Сюда входят также определяемые для сущностей ограничения: например, Customer-Name не может допускать «пустых» значений. Кроме того, модель данных включает в себя описание взаимоотношений между сущностями и ограничения, определенные для этих взаимоотношений: например, ограничение, декларирующее, что для каждого менеджера число отчитывающихся перед ним сотрудников не должно быть более пяти. Модель данных не содержит ссылок и указаний на физическую модель самой системы.

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

Определение физической модели -- создаваемых таблиц и представлений, называется схемой базы данных или просто схемой. Схема -- это перевод концептуальной модели в физическое представление, осуществляемое, как правило, средствами системы управления базами данных. Схема -- это понятие, относящееся к концептуальному, а не к физическому уровню. Это все та же модель данных, описываемая в терминах, используемых механизмом СУБД (database engine) -- таблицы, триггеры и т. п. Механизм СУБД хороши тем, что при его использовании не приходится иметь дело с физической реализацией модели; до известного предела вы можете игнорировать такие сущности, как бы деревья и листовые узлы.

1.2 Механизм СУБД

На самом нижнем уровне находится механизм СУБД. Его часто называют «серверной частью», однако это неточно, поскольку данный термин подразумевает существование определенной физической архитектуры. Механизм базы данных -- это специальные средства, предназначенные для физического манипулирования данными: хранением их на диске и извлечением по запросу. Механизмов СУБД множество, но мы подробно рассмотрим только один из них -- Microsoft Jet. Access использует механизм баз данных Microsoft Jet для манипулирования данными, хранимыми в файлах.mdb, а также может подключаться к любому источнику данных ODBC и манипулировать данными, хранимыми в таком источнике данных, в том числе и в SQL Server. Механизм Microsoft Jet всегда использовался Access, хотя Microsoft и не выделяла механизм баз данных как отдельную сущность до появления Microsoft Visual Basic 3. После того как Access 97 стал поддерживать ODBCDirect, a Microsoft разделила клиентскую часть Access и механизм баз данных Microsoft Jet. Я полагаю, что в будущих версиях эта тенденция сохранится; однако это лишь мое личное мнение. Microsoft Jet -- это «настольный» сервер баз данных, ориентированный на малые и средние системы. Он прекрасно масштабируется и может поддерживать несколько тысяч пользователей, работающих с важными приложениями (Microsoft Jet пригоден только для создания самых простейших систем.)

1.3 Средства для разработки клиентской части приложений

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

1.4 Реляционная модель

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

вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 60-х гг. доктором Е.Ф. Коддом, в то время работавшим в IBM, а впервые опубликованы -- в 1970 г.

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

* Все данные на концептуальном уровне представляются в виде упорядоченной организации, определенной в виде строк и столбцов

и называемой отношением.

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

одно значение.

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

Этот принцип называется замыканием. Если у вас имеется опыт работы с базами данных Microsoft Access, вы, конечно, догадались, что в данном случае представляет собой отношение -- это набор записей, в терминах SQL Server, набор результатов. Формулируя принципы реляционной модели, доктор Кодд выбрал термин «отношение» (relation), потому что он однозначен (в то время как, например, термин «таблица» имеет множество дополнительных значений). Весьма распространено следующее заблуждение: реляционная модель названа так потому, что она определяет отношения между таблицами. На самом деле название этой модели происходит от отношений, лежащих в ее основе. В рамках реляционной модели данные представлены в виде отношения на концептуальном уровне; однако при этом совсем не дается никаких указаний, каким образом данные будут реализованы на физическом уровне. Разделение концептуального и логического уровней давно стало привычным для нас; но всего лишь 30 лет назад этот метод произвел настоящий переворот в области программирования баз данных. Ранее программирование баз данных сводилось в основном к написанию программного кода для физического управления устройствами, предназначенными для хранения данных. В действительности отношения не нуждаются в физическом представлении. Некий набор записей может соответствовать некоей физической таблице, размещенной на диске, а может быть и сформирован из столбцов нескольких десятков таблиц с вычисляемыми полями, значения которых вообще нигде не хранятся. Такой набор записей является отношением, поскольку организован в виде строк и столбцов, и его значения -- скаляры. Его существование абсолютно никак не зависит от физической реализации.

1.5 Атрибуты

В разрабатываемой системе будут храниться записи об определенных параметрах каждой из сущностей. Эти параметры называются атрибутами сущностей. Например, если в вашей системе присутствует такая сущность, как Customer (Покупатель), вам, скорее всего, потребуется хранить имена и фамилии, и возможно, род деятельности клиентов. При моделировании такого события, как звонок в службу технической поддержки потребуется знать, кто звонил, время звонка, и удалось ли успешно разрешить проблему, с которой обратился клиент. Определение атрибутов, которые нужно включить в разрабатываемую модель -- это семантический процесс. Решая эту задачу, нужно основываться на том, что реально означают хранимые данные и как они будут использоваться. Возьмем простейший пример -- адрес. Определите ли вы адрес как одну сущность (Address) или как несколько сущностей (HouseNumber - номер дома, Street - улица, City - город, ZipCode - почтовый индекс)? Большинство разработчиков баз данных (в том числе и я) автоматически разобьют адрес на несколько атрибутов -- ведь структурированными данными обычно легче манипулировать. Но порой это не так, а значит, данное правило отнюдь нельзя считать непреложным. Предположим, мы создаем базу данных адресов для местного клуба любителей рок-музыки. В ней должны храниться адреса членов луба, чтобы их можно было распечатать на конвертах или наклейках при отправке корреспонденции. Поскольку все члены клуба живут в одном городе, имеет смысл хранить их адреса в формате больших двоичных объектов, представляющих собой отдельные фрагменты текста, которые могут содержать несколько строк. Эти несколько строк выводятся целиком в ответ на запрос. Ну а если клиент - американская компания, предлагающая покупателям свои товары через Интернет? Чтобы определить размер налога с продаж, нужно знать, в каком штате живет покупатель, заказавший товар. Если использовать тот же подход, что и в случае с базой данных для местного клуба любителей рок-музыки, то конечно, мы столкнемся с непростой задачей: как извлечь информацию о штате из иного фрагмента текста. Поэтому вполне естественно моделировать одну из составных частей адреса (штат) как отдельную сущность. Но следует ли дробить оставшуюся часть адреса на более мелкие фрагменты, и если да, то на какие? В Соединенных Штатах код штата имеет четко определенный формат, и моделировать этот код как отдельную сущность не составляет труда. Но моделирование составных частей адреса клиента может оказаться не таким уж простым делом. На первый взгляд кажется, что простого набора атрибутов: House-Number (номер дома), Street (название улицы), City (город), State (штат), ZipCode (почтовый индекс), -- вполне достаточно. Но ведь существуют еще номера квартир многоэтажных жилых домов и номера почтовых ящиков, на которые приходит корреспонденция для частных лиц или небольших фирм. А как учесть возможность заявки на приобретение товара на чужое имя? И конечно же, нужно подумать о Потенциальных возможностях расширения бизнеса, Что если клиентом компании станет человек, проживающий за пределами США, или иностранная компания? В последнем случае недостаточно знать только название страны и почтовый код клиента -- форматы почтового кода в США и в других странах могут существенно различаться. Не исключено, что потребуется существенно изменить уже имеющиеся сущности. Например, в большинстве стран Европы при написании адреса номер дома указывается после названия улицы. Подобную проблему легко решить при вводе данных, но есть головоломки и посложнее. Например, многие ли пользователи вашей системы знают, что в австралийском адресе «4/32 Griffen Avenue, Bondi Beach, Australia» цифры 4/32 означают номер квартиры (4) и номер дома (32)? Все эти примеры я привела здесь не затем, чтобы показать, насколько сложно смоделировать обычный почтовый адрес, а для наглядной иллюстрации следующего тезиса: невозможно сделать общие предположения о том, как следует моделировать конкретный вид данных. Сложная схема, которую разрабатывают для обработки заказов поступающих от клиентов из разных стран, будет совершенно непригодна для базы данных адресов местного рок клуба. Говорят, что Матисс считал картину полностью завершенной, когда в ней ничего нельзя было ни добавить, ни убрать. При моделировании сущностей применяется похожий принцип. Но где следует поставить точку? Когда моделирование сущностей можно признать законченным? К сожалению, достоверных способов узнать это не существует. Современный уровень технологии не позволяет создать модель базы данных, которую можно было бы назвать абсолютно правильной, опираясь на неопровержимые доказательства. В каждом конкретном случае вы можете доказать, что в данной реализации допущены такие-то и такие ошибки, однако невозможно доказать, что шибки в реализации отсутствуют.

Проектирование базы данных:

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

Проектирование рабочих процессов:

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

Проектирование пользовательского интерфейса:

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

1.6 Роль пользовательского интерфейса в системе

Множество пользователей отождествляют пользовательский интерфейс и саму систему. Это неудивительно, поскольку большинство из них взаимодействует с системой только через интерфейс, все остальные компоненты от конечного пользователя скрыты. Поэтому от разработки пользовательского интерфейса в значительной степени зависит успех всего проекта. Правильно спроектированный интерфейс обеспечит положительное отношение пользователей к системе, возможно, они даже простят вам некоторые промахи в реализации, без которых не обходится ни один проект. Если же интерфейс спроектирован плохо, то ни мастерство разработчиков, ни оптимизация программного кода с целью повышения производительности не принесут проекту успеха. Увы, если интерфейс спроектирован хорошо, этого, как правило, никто не замечает. Изящные решения в области пользовательского интерфейса естественны и потому не бросаются в глаза. Но и если вы допустите ошибку, весьма вероятно, что она так и останется незамеченной. Интерфейс большинства компьютерных систем, с которыми мне приходилось сталкиваться (в особенности, использующих базы данных), настолько не удобен, что вряд ли тот, что создан вами, окажется самым плохим. Но если никто не заметит ни ваших успехов, ни ваших промахов, стоит ли вообще уделять этой проблеме внимание? Разумеется, стоит. В конце концов, в этом заключается ваша работа, и ее нужно сделать как можно лучше. Спроектировать рациональный пользовательский интерфейс несравненно сложнее, чем просто предоставить пользователю более-менее пригодные средства доступа к данным. Часто реализация удобного пользовательского интерфейса отнимает у разработчиков достаточно много времени и сил. И все же в конце концов затраченные усилия окупаются, приносят не только моральное удовлетворение, но и весьма ощутимую реальную выгоду. Хорошо спроектированный интерфейс позволяет существенно снизить время, необходимое пользователям, чтобы научиться работать с системой, а следовательно, существенно облегчает процесс ее внедрения. Кроме того, рациональный пользовательский интерфейс способствует повышению производительности, поскольку работать с ним удобно и легко. Тщательно продуманный интерфейс, отвечающий требованиям пользователей и разработанный с учетом специфики рабочих процессов, снижает затраты на создание сопроводительной документации. И даже если пользователи не дадут созданному вами интерфейсу столь высокой оценки, какой он, безусловно, заслуживает, может быть, они все же скажут, что ваша система гораздо более эффективна, чем та, что разработана компанией «Тяп-ляп-системз, инкорпорейтед». А лучшей реклама для разработчика -- выполненные им проекты.

Итак, каковы же основные критерии, позволяющие отличить хорошо спроектированный интерфейс от плохо спроектированного? Я считаю, что хороший интерфейс прежде всего эффективно помогает пользователям решать стоящие перед ними задачи, не создавая дополнительных трудностей в работе. Такой интерфейс не навязывает пользователям свои собственные «правила игры», совсем напротив -- он настолько органично вписывается в рабочий процесс, что почти не заметен. Он прост и удобен; пользователям не нужно держать в голове множество запутанных правил. И, конечно, хорошо спроектированный интерфейс никогда не преподносит пользователю «сюрпризов» -- система всегда работает стабильно и предсказуемо. Обо всех этих критериях оценки полезности и удобства пользовательского интерфейса мы еще поговорим. Но прежде рассмотрим три модели, которые помогут вам создать концепцию разработки пользовательского интерфейса.

Итоги: В данной главе я ознакомил с обновами Access, основами баз данных, механизмами СУБД. А так же процесс проектирования и создание дружественного интерфейса.

1.7 Компиляция и выполнение проекта

В процессе компиляции проекта создается готовый к использованию файл, которым может быть приложение (ЕХЕ) или динамически загружаемая библиотека (DLL). Далее будем рассматривать только файл-приложение. Имя приложения, получаемого в результате компиляции, совпадает с именем файла проекта, а само приложение является автономным и не требует для своей работы дополнительных файлов Delphi.

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

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

* если в модуль были внесены изменения, то перекомпилируется не только этот модуль, но и использующие его с помощью директивы use s МОДУЛИ;

* перекомпиляция модуля происходит также при изменениях объектного файла (OBJ) или подключаемого файла (INC), используемых данным модулем;

* после компиляции всех модулей проекта компилируется файл проекта и создается исполняемый файл приложения с именем файла проекта.

1.8 Разработка приложения

Delphi относится к системам визуального программирования, которые называются также системами RAD (Rapid Application Development, быстрая разработка приложений). Разработка приложения в Delphi включает два взаимосвязанных этапа:

* создание интерфейса приложения;

* определение функциональности приложения.

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

1.9 Среда интегрированной среды разработки

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

Встроенный отладчик. Интегрированная среда разработки включает встроенный отладчик приложений, в значительной степени облегчающий поиск и устранение ошибок в приложениях. Средства отладчика доступны через команды пункта меню Run (Выполнение) и подменю View | Debug Windows (Просмотр | Окна отладки) и позволяют выполнять такие действия, как:

* выполнение до указанного оператора (строки кода);

* пошаговое выполнение приложения;

* выполнение до точки останова (Breakpoint);

* включение и выключение точек останова;

* просмотр значений объектов, например переменных, в окне просмотра;

* установка значений объектов при выполнении приложения.

Установка параметров отладчика выполняется в диалоговом окне Debugger Options (Параметры отладчика), вызываемом одноименной командой пункта меню Tools (Средства). Включением/выключением отладчика управляет переключатель Integrated debugging (Интегрированная отладка), который по умолчанию включен, и отладчик автоматически подключается к каждому приложению. В ряде случаев, например, при отладке обработчиков исключительных ситуаций и проверке собственных средств обработки ошибок, этот переключатель отключают.

1.10 Структура программы

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

Program <Имя программы>;

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

* подключения модулей;

* объявления меток;

*объявления констант;

* описания типов данных;

* объявления переменных;

* описания процедур и функций.

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

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

1.11 Процедуры

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

Procedure <Имя> [ (формальные параметры) ];

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

Предварительное описание пользовательской процедуры changestr выполнено непосредственно в обработчике события нажатия кнопки Buttoni. Это описание можно вынести за пределы обработчика, в этом случае процедуру Changestr можно будет вызывать не только из данного обработчика.

1.12 Использование надписей

Надпись представляет собой нередактируемыи текст и часто используется в качестве заголовков для других управляющих элементов, которые не имеют своего свойства caption. Для отображения надписей, в первую очередь, используется компонент Label, называемый также меткой. Он представляет собой простой текст, который не может быть отредактирован пользователем при выполнении программы. Для управления автоматической коррекцией размеров компонента Label в зависимости от текста надписи служит свойство Autosize типа Boolean. Если свойство имеет значение True (по умолчанию), то компонент Label изменяет свои размеры соответственно содержащемуся в нем тексту, заданному В СВОЙСТВ е Caption. Способ выравнивания текста внутри компонента Label задает свойство Alignment типа TAiignment, которое может принимать одно следующих значений:

* taLeftJustify -- выравнивание по левому краю;

* tacenter -- центрирование;

* taRightJustify -- выравнивание по правому краю.

Глава 2. Работа в программной среде Delphi и Excel

В данной главе я приведу описание и использование. Создание программы продажи авиабилетов. Руководство использования.

2.1 Разработка программы

Данная программа разработана с помощью MS Excel и Delphi. В Delphi выполненная основная част всей работы. Это создание интерфейса пользователя. Так как у нас содержится основная часть работы с программой в таблицах. Необходимо создать так программу чтобы можно было работать с базой данных (т.е. таблицей) непосредственно напрямую в программе, вносит всевозможные данные о рейсах, времени отправки, вносить данные о свободных и занятых местах. В MS Excel я создал базу данных для необходимой работы. Для базы данных мне понадобилось информация о рейсах, стоимости билетов и т.д.

2.2 Знакомство с интерфейсом программы

Важным фактором интерфейса служит то что пользователь должен легко сотрудничать с программой. Пользователь не должен запоминать кучу всевозможных данных программа должна делать все это за него.

Ниже приведена моя программа по работе с базой данных. Данная программа состоит из двух окон.

Первое окно предназначено чтобы указать путь к базе данных так как пользователь может предложить свою базу данных, не желе пользоваться чужой. (Рис.2.)



Рис. 2 Диалоговое окно для начала работы с базой данных

Второе окно предназначено для работы с базами данных. (Рис.3)

Рис. 3 Диалоговое окно для работы с данными

Данное диалоговое окно состоит из табличного редактора. (Рис4.) которое в данный момент не открыто.

Рис. 4 Табличный редактор

Чуть выше табличного редактора кнопки исполняющие функции. (Рис.5.)

Рис. 5 Функциональные кнопки

Чтобы начать работу с базой данных необходимо выбрать лист с данными в базе данных как это показано на рис.6 и рис.7.



Рис. 6 С указанием для нажатия

Рис. 7 Раскрывшийся список листов

Для продолжения работы выбираем лист и используем кнопку «открыть» чтобы вывести таблицу. (Рис.8.)

Рис. 8 Открытие базы

В данном диалоговом окне раскрылась база данных которую можно редактировать и изменять. (Рис.9)

Рис. 9 Таблица данных

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



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

(Рис.10) Данная панель выполняет такие функции как:

1.1 Приход по ячейкам с первой к последней в выбранной графе.

1.2 Функции добавления новой строки

1.3 Применение изменений удаление изменений

1.4 Обновление базы данных при ее изменении (недоработано).

2.3 Разработка базы данных

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

Рис. 11 База данных в MS Excel

Мало создать базу данных ее надо оформить так как она в исходном виде будет приносить неудобство пользователю.

2.4 Разработка программы в Delphi

В разработке программной среды Delphi 7 я разработал работал рабочий интерфейс.

Рис.12 Рабочая среда Delphi

В разработке первого окна для того что бы он открывал файлы добавил процедуру Open Dialog в опциях процедуры поставил True только в функциях ofHideReadOnly и ofEnableSizing для того чтобы программа не пыталась открыть файлы других форматов и ADOConnection для раскрытия списка в файлах пользователя. Во втором окне добавил ADOQuery для раскрытия базы данных и визуального контакта и DataSource для работы непосредственно в самой таблице.

2.5 Актуальность моей представленной программы

Приведу пример в табличном виде в сравнении с другой программой.

Критерии	Бесплатность	Наличие базы данных в программе	Протестирована	Обучение в часах
Организационная программа	-	+	+	Месяц
Моя программа	+	+ и добавление своей базы	-	Сутки

Таблица сравнения в эффективности программы.

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

Заключение

В процессе выполнения курсового проекта были разработаны структура и алгоритм работы приложения «Программа продажи авиабилетов.exe» При этом были учтены особенности реализации других компонентов информационной системы. Результатом работы стало создание программного обеспечения, обслуживающего администратора агентства. Программное обеспечение написано на языке Object Pascal с использованием среды разработки Delphi 7.0.

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

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

1.Введение в Delphi. Центр информационных технологий. www.citforum.ru.

2. Информационные системы в экономике. Титоренко Москва 2007 год.

3. Delphi быстрый старт. Владимир Гофман Санкт- Петербург 2003 год.

4.С.А. Орлов. Технологии разработки программного обеспечения. Санкт-Петербург. «Питер»,2002

5.Эрик Дж. Брауде. Технология разработки программного обеспечения. Санкт-Петербург. «Питер», 2004

6. Гофман В.Э., Хомоненко А.Д. Работа с базами данных в Delphi. - СПб.: БХВ - Петербург, 2002г.

7. Базы данных: модели, разработка, реализация/ Т.С. Карпова. - СПб.: Питер, 2001г.

8. Роберт Виейра - Программирование баз данных MS SQL Server 2005. Базовый курс.2007

9. Положение о курсовом проектировании [Текст]. - Горно-Алтайск: ГАГУ, 2012г.

Размещено на Allbest.ru