Разработка приложения «Турфирма»

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ  УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО  ОБРАЗОВАНИЯ

БАШКИРСКИЙ ГОСУДАРСТВЕННЫЙ  УНИВЕРСИТЕТ

БИРСКИЙ ФИЛИАЛ

 

 

 

Курсовая работа на тему:

 

 

 

 

Выполнил: студент 4 курса  ОЗО физико-математического факультета Дмитриева К.А.

Научный руководитель: к.п.н., доцент Волкова Т.И.

 

 

 

 

Бирск 2013 

Содержание

Введение 3

Глава I. Базы данных и Delphi. 4

1.1 Понятие  «базы данных» 4

1.2 Структурные  элементы базы данных 5

1.3 Нормализация  отношений и типы связей 6

1.4 Этапы создания  базы данных 8

1.5 Язык программирования  Delphi 10

1.6 Основные  компоненты Delphi 12

1.7 Компоненты  Delphi для работы с базой данных 13

Глава II. Разработка приложения «Турфирма» 15

2.1 Разработка  базы данных «Турфирма» 15

2.1.1 Инфологическая  модель 15

2.1.2. Логическое  проектирование базы данных 15

2.1.3 Создание  базы данных в Access 16

2.2 Разработка  приложения СУБД «Турфирма» 18

2.2.1 Структура  программы 18

2.2.2 Модуль  данных 19

2.2.3. Главная  форма программы 22

2.2.4. Создание  форм для просмотра и редактирования  списков данных 23

2.2.5. Создание  форм для редактирования туров  и путевок 25

2.2.6. Создание формы для оформления заказов 27

2.3 Тестирование  программы 29

Заключение 30

Литература 31

Приложение 32

 

 

Введение

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

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

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

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

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

 

Глава I. Базы данных и Delphi.

1.1 Понятие «базы данных»

База данных — совокупность взаимосвязанных данных, совместно  хранимых в одном или нескольких компьютерных файлах.

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

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

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

Принято выделять три типа баз данных: иерархические, сетевые  и реляционные.

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

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

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

Microsoft Access, Oracle, MS SQL Server, MySQL, InterBase, FoxPro, PostgreSQL и Paradox – все эти программы построены на базе реляционной модели данных.

1.2 Структурные элементы базы данных

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

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

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

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

Файл (таблица) — совокупность экземпляров записей одной структуры.

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

1.3 Нормализация отношений и типы связей

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

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

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

Выделены три нормальные формы отношений и предложен  механизм, позволяющий любое отношение  преобразовать к третьей (самой  совершенной) нормальной форме.

Первая нормальная форма.

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

Вторая нормальная форма.

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

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

Функциональная зависимость  реквизитов — зависимость, при которой  экземпляре информационного объекта  определенному значению ключевого реквизита соответствует только одно значение описательного реквизита.

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

В случае составного ключа  вводится понятие функционально  полной зависимости.

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

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

Третья нормальная форма.

Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости.

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

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

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

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

один к одному (1:1);

один ко многим (1 : М);

многие ко многим (М : М).

Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот.

При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А.

Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного  объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот.

1.4 Этапы создания базы данных

С точки зрения конечного  пользователя процесс создания базы данных можно представить в виде трех этапов:

- инфологическое (концептуальное) описание баз данных;

- логическое проектирование  баз данных;

- физическое проектирование  баз данных.

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

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

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

При проектировании баз данных решаются две основных проблемы:

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

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