Содержание

Введение

1. Разработка требования к базе данных

1.1 Постановка задачи

1.2 Анализ информационных потоков, выбор модели

2. Проектная часть

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

2.2 Создание базы данных

2.3 Программирование

Заключение

Список использованной литературы

Введение

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

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

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

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

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

1. Разработка требования к базе данных

В процессе разработки требований к базе данных можно выделить следующие этапы:

1. Постановка задачи.

2. Анализ информационных потоков, выбор модели.

1.1 Постановка задачи

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

А. Входные документы.

Аl. Расписание рейса

А2. Сведения о покупателях

В. Выходные документы.

B1. Сведения о свободных местах на рейс

B2. Сведения о продаже билетов

Реквизиты:

Номер рейса, Пункт отправления, Пункт назначения, Дата отправления, Номер автобуса, Основной водитель, Сменный водитель, Количество мест, Проданные места на момент отправления, ФИО водителя, Номер водителя, Дата, Время в пути, Регистрационный номер проданного билета, Номер рейса, Дата отправления, Пункт назначения, Стоимость билета.

Необходима реализация следующих запросов:

выдать информацию о наличии свободного билета на рейс;

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

1.2 Анализ информационных потоков, выбор модели

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

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

Рис.1. Пример взаимосвязи информационных потоков

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

Рассмотрим входной документ "Расписание рейса"

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

2. К предметным строкам документа относятся в данном случае реквизиты номер рейса, дата отправления, пункт отправления, пункт назначения, время в пути.

3. К заверительной части документа относится реквизит - начальник смены.

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

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

Рассмотрим выходной документ "Сведения о свободных местах на рейс"

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

2. К предметным строкам документа относятся в данном случае реквизиты номер рейса, дата отправления, пункт назначения, номер автобуса, количество мест, свободные места.

3. К заверительной части документа относится реквизит - начальник смены.

4. К реквизитам, предназначенным для улучшения читабельности документа, относится реквизит Сведения о свободных местах на рейс на 25.09.2009 год 14: 00 часов и Итого, но эти реквизиты не подлежит вводу в базу данных.

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

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

Основная задача проектирования базы данных - это определение количества файлов и их реквизитного состава.

Реквизит - это совокупность значений некоторого фиксированного набора переменных. Различают реквизиты-признаки и реквизиты-основания.

Реквизит-признак - это информационное отображение качественного свойства некоторого объекта.

Реквизит-основание - это информационное отображение количественного свойства некоторого объекта.

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

Для определения признаков и оснований я пользовалась следующими правилами:

1. Если значение реквизита является исходным данным или результатом арифметической операции, то это основание ;

2. Если реквизит текстовый, то это признак;

3. Если реквизит обозначает предмет или время - это признак;

4. Если реквизит в некотором показателе является признаком (основанием), то он будет играть эту же роль в других показателях;

5. Если показатели описывают сходные процессы, то их призначные части совпадают;

6. Если основание показателя вычисляется по значениям других оснований, то набор признаков такого показателя - это объединение признаков, связанных с этими основаниями.

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

К реквизитам признакам относятся: время в пути, пункт отправления, пункт назначения, дата отправления, ФИО водителя, сменный водитель, основной водитель, номер автобуса, номер водителя, номер билета, номер рейса.

Можно сделать вывод, что в документах приложения базы данных "Автостанция" будет 3 показателя. Подберем реквизиты-признаки для каждого основания и получим показатели.

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

В результате структура показателя П1 примет вид:

П1 (номер билета, номер рейса, время в пути, стоимость билета ).

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

В результате структура показателя П2 примет вид:

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

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

В результате структура показателя П3 примет вид:

П3 (номер рейса, номер автобуса, номер водителя, ФИО водителя, сменный водитель, основной водитель, проданные места ).

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

Методом, решающим этот недостаток является построение модели данных.

Модель данных - это совокупность трех составляющих:

множество информационных конструкций, допускаемых этой моделью;

множество допустимых операций над данными;

множество ограничений, наложенных на информационные конструкции.

Иными словами модель данных - это инструмент для представления данных в базе данных.

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

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

В проектируемой базе данных сущностями будут являться: РЕЙС, БИЛЕТ, АВТОБУС, ВОДИТЕЛЬ.

Необходимо различать такие понятия, как тип сущности и экземпляр сущности . Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ВОДИТЕЛЬ, а экземпляром - Иванов, Петров и т.д.

Атрибут - поименованная характеристика сущности. Примерами атрибутов для сущности БИЛЕТ будут номер билета, стоимость и т.д.

Ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. К примеру в сущности РЕЙС исключение из атрибутов такого как IDрейса не позволит однозначно определить рейс, поэтому ключом сущности РЕЙС является атрибут - IDрейса.

Связь - ассоциирование двух или более сущностей. Для выявления связей между сущностями необходимо, как минимум, определить сами сущности и их атрибутный состав. Построим модель "сущность-связь":

1

1

∞

∞ ∞

∞ ∞

1

1 1

Центральная задача проектирования базы данных - это определение количества отношений и их атрибутного состава.

Задача группировки атрибутов в отношении допускает множество вариантов решения.

Рациональный вариант предполагает:

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

2. корректировка отношений не должна приводить к двусмысленности и потере информации;

3. перестройка набора отношений при добавлении в базу данных новых атрибутов должна быть минимальной.

Переход от модели "Сущность-связь" к реляционной модели данных осуществим через нормализацию.

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

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

По определению, в отношении R (A,B) реквизит А функционально определяет реквизит В, если в любой момент времени каждому значению А соответствует единственное значение В.

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

1. номер рейса - > пункт отправления

2. номер рейса - > пункт назначения

3. номер рейса - > дата отправления

4. номер рейса - > номер автобуса

5. номер автобуса - > пункт отправления

6. номер автобуса - > пункт назначения

7. номер автобуса - > количество мест

8. номер водителя - > ФИО водителя

9. номер водителя - > смена

10. номер билета - > номер рейса

11. номер билета - > стоимость

12. номер рейса, дата отправления - > номер водителя

13. номер рейса, дата отправления - > проданные места

14. номер рейса, номер автобуса - > время в пути.

На шаге 2 воспользуемся двумя теоремами:

1) теорема 2 - реквизит А определяет реквизит В и реквизит А определяет реквизит С только тогда, когда А определяет В и С вместе;

2) теорема 3 - если реквизит А определяет реквизит В и реквизит В определяет реквизит С, то реквизит А определяет реквизит С.

В результате получим 6 функциональных зависимостей:

1. номер рейса - > пункт отправления, пункт назначения, дата отправления, номер автобуса

2. номер рейса, дата отправления - > номер водителя, проданные места

3. номер рейса, номер автобуса - > время в пути

4. номер автобуса - > пункт отправления, пункт назначения, количество мест

5. номер водителя - > ФИО водителя, смена

6. номер билета - > номер рейса, стоимость.

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

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

Для каждой функциональной зависимости создадим проекцию исходного отношения:

1. T=R1 [номер рейса, номер водителя, номер автобуса, пункт отправления, пункт назначения, дата отправления, проданные места, время в пути]

2. T=R2 [номер билета, номер рейса, стоимость]

3. T=R3 [номер автобуса, пункт отправления, пункт назначения, количество мест]

4. T=R4 [номер водителя, ФИО водителя, смена].

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

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

1. Выдать информацию о наличии свободного билета на рейс.

Этот запрос относится к

Запрос будет выглядеть так:

Вход запроса:

Выход запроса:

Оболочка запроса:

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

Этот запрос относится к

Запрос будет выглядеть так:

Вход запроса:

Выход запроса:

Оболочка запроса:

2. Проектная часть

В проектной части необходимо выполнить следующие этапы:

1. Проектирование базы данных (определение состава полей её таблиц и связей между ними).

2. Создание базы данных.

3. Программирование выполнения операций над данными.

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

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

В проектируемой базе данных должно быть 4 таблицы (исходя из полученных четырех отношений в 3НФ). В таблице Avtobysразместим полные сведения о каждом автобусе. Таблица Voditelпредназначена для хранения сведений о водителях - то есть: номер водителя, ФИО водителя и его смена. В таблице Bilet содержится информация о билетах с указанием номера рейса и стоимости. В таблице Reis - будут храниться все необходимые сведения о рейсе - с указанием номера, даты отправления, пункта отправления и назначения, номера автобуса, номера водителя, времени в пути.

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

Таблица Reis:

Таблица Avtobys:

Таблица Voditel:

Таблица Bilet:

2.2 Создание базы данных

Под созданием базы данных подразумевается создание таблиц будущей БД, проектирование связей между ними, а также задание свойств таблиц. При необходимости следует ввести контроль за содержимым полей, проверку правильности введенного в поле значения; добавить вычисляемые и просматриваемые поля. Перед созданием БД необходимо создать каталог, в котором будут размещаться таблицы, и настроить рабочий каталог утилиты DataBaseDesktop (File/WorkingDirectory).

После определения структуры таблиц создадим все таблицы базы данных "Автостанция".

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

Поле Nomer_voditelya в таблице Voditel должно содержать ссылку на рейс в таблице Reis. Поэтому устанавливаем однозначную связь между этими полями.

Поле Nomer_avtobysaв таблице Avtobysдолжно содержать ссылку на рейс в таблице Reis. Для этого устанавливаем однозначную связь между этими полями.

2.3 Программирование

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

В данной работе были использованы следующие компоненты Delphi:

1. Button - является простейшей и, пожалуй, наиболее часто используемой кнопкой, которая располагается на странице библиотеки Standard. Основное событие любой кнопки - OnClick , возникающее при щелчке на ней. Именно в обработчике этого события записываются операторы, которые должны выполняться при щелчке пользователя на кнопке. Из методов, присущих кнопкам, имеет смысл отметить один - Click . Выполнение этого метода эквивалентно щелчку на кнопке, т.е. вызывает событие кнопки OnClick . Этим можно воспользоваться, чтобы продублировать какими-то другими действиями пользователя щелчок на кнопке.

2. RadioGroup - э то панель, которая может содержать регулярно расположенные столбцами и строками радиокнопки. Надпись в левом верхнем углу панели определяется свойством Caption . А надписи кнопок и их количество определяются свойством Items , имеющим тип TStrings . Щелкнув на кнопке с многоточием около этого свойства в окне Инспектора Объектов, вы попадете в редактор списков строк. В нем вы можете занести надписи, которые хотите видеть около кнопок, по одной в строке. Сколько строчек вы запишете - столько и будет кнопок. Кнопки, появившиеся в панели после задания значений Items , можно разместить в несколько столбцов (не более 17), задав свойство Columns . По умолчанию Columns = 1 , т.е. кнопки размещаются друг под другом. Определить, какую из кнопок выбрал пользователь, можно по свойству ItemIndex , которое показывает индекс выбранной кнопки. Индексы, как всегда в Delphi, начинаются с 0. По умолчанию ItemIndex = - 1 , что означает отсутствие выбранной кнопки. Если вы хотите, чтобы в момент начала выполнения приложения какая-то из кнопок была выбрана (это практически всегда необходимо), то надо установить соответствующее значение ItemIndex во время проектирования.

3. Label - используется для отображения различных надписей на форме. Тексты, отображаемые в перечисленных компонентах, определяются значением их свойства Caption. Его можно устанавливать в процессе проектирования или задавать и изменять программно во время выполнения приложения. Для метки Label цвет и шрифт - единственно доступные элементы оформления надписи. Размер метки Label определяется также свойством AutoSize . Если это свойство установлено в true , то вертикальный и горизонтальный размеры компонента определяются размером надписи. Если же AutoSize равно false , то выравнивание текста внутри компонента определяется свойством Alignment , которое позволяет выравнивать текст по левому краю, правому краю или центру клиентской области метки.

4. В компоненте Edit вводимый и выводимый текст содержится в свойстве Text . Это свойство можно устанавливать в процессе проектирования или задавать программно. Выравнивание текста, как это имело место в метках и панелях, невозможно. Перенос строк тоже невозможен. Текст, не помещающийся по длине в окно, просто сдвигается и пользователь может перемещаться по нему с помощью курсора. Окна редактирования можно использовать и просто как компоненты отображения текста. Для этого надо установить в true свойство ReadOnly. При использовании окон редактирования для вывода, ввода и редактирования чисел необходимо использовать функции взаимного преобразования строк и чисел. Для вывода это описанные при рассмотрении меток функции FloatToStr и IntToStr . При вводе это функции StrToFloat - преобразование строки в значение с плавающей запятой, и StrToInt - преобразование строки в целое значение. Свойство MaxLength определяет максимальную длину вводимого текста. Если MaxLength = 0 , то длина текста не ограничена. В противном случае значение MaxLength указывает максимальное число символов, которое может ввести пользователь.

5.comboBox - отображает списки строк. Этот компонент позволяет отображать список как в развернутом виде, так и в виде выпадающего списка, что обычно удобнее, так как экономит площадь окна приложения. Основное свойство этого компонента, содержащее список строк, - Items , имеющее тип TStrings . Заполнить его во время проектирования можно, нажав кнопку с многоточием около этого свойства в окне Инспектора Объектов. Выбор пользователя или введенный им текст можно определить по значению свойства Text . Если же надо определить индекс выбранного пользователем элемента списка, то можно воспользоваться свойством ItemIndex . Если в окне проводилось редактирование данных, то ItemIndex = - 1 . По этому признаку можно определить, что редактирование проводилось.

6. В Delphiдля работы с наборами данных служат такие компоненты, как Table и Query , которые являются производными от класса DBDataSet - потомка класса TDataSet. Они имеют схожие с базовыми классами характеристики и поведение, но каждый из них имеет и свои особенности.

Для компонента Tableиспользование свойства DataBaseNameявляется единственной возможностью задать местонахождение таблиц базы данных. Для компонента Queryдополнительно можно указать в запросе SQLпуть доступа к каждой таблице.

Открытый компонент Table (т.е. Active=True) содержит набор данных, соответствующий данным таблицы, связанной с ним через свойство TableName.

Для открытого компонента Queryданных соответствует результатам выполнения SQL-запроса, содержащегося в свойстве SQLэтого компонента.

Компонент Tableобеспечивает взаимодействие с таблицей базы данных. Для связи с требуемой таблицей нужно установить соответствующее значение свойствам DataBaseName, указывающему путь к базе данных, и TableNameуказывающему имя таблицы. После задания таблицы для открытия набора данных свойству Activeдолжно быть установлено значение True.

7. DataSource обеспечивает взаимодействие набора данных с компонентами отображения данных. Чаще всего одному набору данных соответствует один компонент DataSource, хотя их может быть несколько. Компонент DataSourceдолжен быть связан с набором данных, значения полей которого требуется передать в параметры. Названия параметров должны соответствовать названиям полей этого набора данных, тогда свойство DataSourceначнет работать.

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

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

8. Компонент TDBNavigator при помощи свойства DataSourse связывается с компонентом TDataSourse и через него с набором данных. Такая схема позволяет обеспечить изменение текущих значений полей сразу во всех связанных с TDataSourse компонентах отображения данных. Таким образом TDBNavigatorтолько дает команду на выполнение перемещения по набору данных или другой управляющей операции, а всю реальную работу выполняет компонент набора данных и компонент TDataSourse. Компонентом отображения остается только применить данные от своих полей.

DBNavigatorсодержит следующие кнопки:

1. nbFirst - перемещение на первую запись набора данных

2. nbPrior - перемещение на предыдущую запись набора данных

3. nbNext - перемещение на следующую запись набора данных

4. nbLast - перемещение на последнюю запись набора данных

5. nbInsert - вставка новой записи в текущей позиции набора данных

6. nbDelete - удаление текущей записи, курсор перемещается на следующую запись

7. nbEdit - набор данных переводится в режим редактирования

8. nbPost - в базу данных переносятся все изменения в текущей записи

9. nbCancel - все изменения в текущей записи отменяются

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

9. DBGrid - этот компонент инкапсулирует двумерную таблицу, в которой сроки представляют собой записи, а столбцы поля.

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

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

Новая колонка добавляется при помощи кнопки Add New, после этого ее название появляется в списке колонок. Колонки в списке можно редактировать, удалять, менять местами. При помощи кнопки AddAllFieldsв сетку можно добавлять все поля набора данных.

Программирование работы приложения базы данных приведено в листинге (Приложение А).

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

procedure TForm1. RadioGroup1Click (Sender: TObject);

begin

if RadioGroup1. ItemIndex=0 then Table3. Filtered: =false

else

begin

if RadioGroup1. ItemIndex=2 then

begin

table3. Filtered: =true;

Table3. Filter: ='Nomer_reisa='+ComboBox1. Text; end

else

begin

if RadioGroup1. ItemIndex=3 then

begin

table3. Filtered: =true;

Table3. Filter: ='Nomer_voditelya='+ComboBox2. Text; end

else

begin

if RadioGroup1. ItemIndex=4 then

begin

table3. Filtered: =true;

Table3. Filter: ='Nomer_avtobysa='+ComboBox3. Text; end

else

Table3. Filtered: =False;

end;

end; end;

end;

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

1. Выдать информацию о наличии свободного билета на рейс.

select distinct nomer_reisa, kolichestvo_mest, prodannie_mesta

from reis, avtobys

where (avtobys. nomer_avtobysa=reis. nomer_avtobysa)

and (kolichestvo_mest-prodannie_mesta) >0

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

select distinct nomer_reisa, pynkt_naznacheniya, stoimost, vremya_v_pyti

from reis, bilet

where (bilet. nomer_reisa=reis. nomer_reisa)

and pynkt_naznacheniya='+''''+Edit14. Text+''''

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

Заключение

В данной курсовой работе была разработана база данных "Автостанция".

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

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

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

Данная курсовая работа является актуальной и отвечает предъявленным к ней требованиям. Была разработана и написана на языке программирования высокого уровня Borland Delphi 7.0.

база программирование автовокзал информационный

Список использованной литературы

1. Архангельский А.Я. Программирование в Delphi5. - М.: ЗАО “Издательство БИНОМ”, 2000. - 1070с.: ил. (ч/з ПаУ)

2. Фаронов В.В. Программирование баз данных в Delphi6. Учебный курс. - СПб.: Питер, 2002. - 352с.: ил.

3. Дарахвелидзе П.Г., Марков Е.П. Delphi - среда визуального программирования: - СПб.: BHV - Санкт-Петербург, 1996. - 352с.

4. Гофман В.Э., Хомоненко А.Д. Delphi. Быстрый старт. - СПб.: БХВ - Санкт-Петербург, 2002. - 208с.: ил. (ч/з ПаУ)

5. Фаронов В.В. Delphi4. Учебный курс. - М.: "Нолидж", 1999. - 464с.: ил. (ч/з ПаУ)

6. Фаронов В.В. Delphi 5 Учебный курс. - М.: "Нолидж", 2000. - 606с.: ил. (ч/з ПаУ)

7. Фаронов В.В. Delphi 6. Учебный курс. - М.: Издатель Молгачева С.В., 2002. - 672с. (ч/з ПаУ)

8. Фаронов В.В. Шумаков П.В. Delphi4. Руководство разработчика баз данных. - М.: “Нолидж”, 1999. - 560с.: ил.

9. Фаронов В.В. Шумаков П.В. Delphi5. Руководство разработчика баз данных. - М.: “Нолидж”, 2000. - 640с.: ил. (ч/з ПаУ)

10. Хендерсон К. Руководство разработчика баз данных в Delphi2/Пер. с англ. - К.: "Диалектика", 1996. - 544с.

11. Культин Н.Б. Delphi6. Программирование на ObjectPascal. Самоучитель. - СПб.: БХВ-Петербург, 2001. - 528с.: ил. (ч/з ПаУ)

12. Базы данных: интеллектуальная обработка информации В.В. Корнеев, А.Ф. Гареев, С.В. Васютин. - М.: Нолидж, 200. - 352с.: ил. (ч/з ПаУ)