Постановка задачи
.
2. Анализ информационных потоков, выбор модели.
В рамках выполнения курсовой работы требуется разработать базу данных «Автостанция».
А. Входные документы.
Аl. Расписание рейса
А2. Сведения о покупателях
В. Выходные документы.
B1. Сведения о свободных местах на рейс
B2. Сведения о продаже билетов
Реквизиты:
Номер рейса, Пункт отправления, Пункт назначения, Дата отправления, Номер автобуса, Основной водитель, Сменный водитель, Количество мест, Проданные места на момент отправления, ФИО водителя, Номер водителя, Дата, Время в пути, Регистрационный номер проданного билета, Номер рейса, Дата отправления, Пункт назначения, Стоимость билета.
Необходима реализация следующих запросов:
- выдать информацию о наличии свободного билета на рейс;
- вывести список рейсов в один и тот же город с указанием времени пути и стоимости билета.
На данном этапе требуется логически построить информационную систему, призванную автоматизировать процесс учета данных какой-либо области человеческой деятельности; анализируя информационные потоки, необходимо выбрать модель базы данных.
В данной курсовой работе требуется разработать приложение для работы с базой данных «Автостанция», система управления которой предназначена для автоматизации работы автостанций. Автостанция является промежуточным звеном между другими автостанциями и пассажирами. Наличия этого звена выгодно и тем и другим: автостанции объединены в единую сеть с возможностью взаимной реализации билетов и передачи справочной информации; пассажиры, с другой стороны, не имеют проблем с покупкой билетов на тот или другой авторейс. На рис.1 отображены взаимосвязи между автостанцией и ее партнерами
 |
Рис.1. Пример взаимосвязи информационных потоков
Основная задача проектирования базы данных — определение количества отношений и их реквизитного состава. Совокупность реквизитов, объединенных в более крупную единицу данных, называется составной единицей информации. На основе последних можно составить входные и выходные документы базы данных «Автостанция».
Рассмотрим входной документ «Расписание рейса»
1. В общей заголовочной части расположены такие реквизиты, как наименование организации, эмблема организации, главный диспетчер, так как эти реквизиты относятся ко всему документу.
2. К предметным строкам документа относятся в данном случае реквизиты номер рейса, дата отправления, пункт отправления, пункт назначения, время в пути.
3. К заверительной части документа относится реквизит — начальник смены.
4. К реквизиту, предназначенному для улучшения читабельности документа, относится реквизит Расписание рейса, но этот реквизит не подлежит вводу в базу данных.
|
|
УТВЕРЖДАЮ Главный диспетчер _____________ Петров А. В. |
|||||
| РАСПИСАНИЕ РЕЙСА | ||||||
| № | Номер рейса | Дата отправления | Пункт отправления | Пункт назначения | Время в пути | |
| 1 | 153 | 25.09.2009 | Павлодар | Экибастуз | 2ч. 20мин | |
| 2 | 149 | 25.09.2009 | Павлодар | Омск | 12ч | |
| 3 | 241 | 25.09.2009 | Павлодар | Аксу | 1ч 30 мин | |
| 4 | 111 | 25.09.2009 | Павлодар | Томск | 14ч. 20мин | |
| 5 | 100 | 25.09.2009 | Павлодар | Семей | 6ч. | |
| Начальник смены __________________ | ||||||
Аналогично следует разработать второй входной документ, который будет выглядеть следующим образом:
|
|
УТВЕРЖДАЮ Главный диспетчер _____________ Петров А. В. |
|||||
| СВЕДЕНИЯ О ПОКУПАТЕЛЯХ | ||||||
| № | ФИО покупателя | № удостоверения/паспорта | Гражданство | № рейса | Место | |
| 1 | Кренько Олеся Сергеевна | 012459213 | RUS | 153 | 23 | |
| 2 | Петров Иван Васильевич | 012345879 | KZ | 149 | 12 | |
| 3 | Ахметов Нурлан Каиргалиевич | 034546851 | KZ | 241 | 4 | |
| 4 | Пашко Светлана Константиновна | 01654745 | KZ | 111 | 7 | |
| 5 | Скворцов Сергей Петрович | 01245863 | RUS | 100 | 10 | |
| Начальник смены __________________ | ||||||
Рассмотрим выходной документ «Сведения о свободных местах на рейс»
1. В общей заголовочной части расположены такие реквизиты, как наименование организации, эмблема организации, главный диспетчер, так как эти реквизиты относятся ко всему документу.
2. К предметным строкам документа относятся в данном случае реквизиты номер рейса, дата отправления, пункт назначения, номер автобуса, количество мест, свободные места.
3. К заверительной части документа относится реквизит — начальник смены.
4. К реквизитам, предназначенным для улучшения читабельности документа, относится реквизит Сведения о свободных местах на рейс на 25.09.2009 год 14: 00 часов и Итого, но эти реквизиты не подлежит вводу в базу данных.
|
|
УТВЕРЖДАЮ Главный диспетчер _____________ Петров А. В. |
||||||
|
СВЕДЕНИЯ О СВОБОДНЫХ МЕСТАХ НА РЕЙС НА 25.09.2009, 14: 00 |
|||||||
| № | Номер рейса | Дата отправления | Пункт назначения | Номер автобуса | Количество мест | Свободные места | |
| 1 | 153 | 25.09.2009 | Экибастуз | 011 | 32 | 2 | |
| 2 | 149 | 25.09.2009 | Омск | 142 | 52 | 4 | |
| 3 | 241 | 25.09.2009 | Аксу | 101 | 48 | 3 | |
| 4 | 111 | 25.09.2009 | Томск | 098 | 20 | 0 | |
| 5 | 100 | 25.09.2009 | Семей | 055 | 34 | 1 | |
|
ИТОГО: количество мест 186 продано мест 176 свободно мест 10 |
|||||||
| Начальник смены __________________ | |||||||
Аналогично следует разработать второй выходной документ, который будет выглядеть следующим образом:
|
|
УТВЕРЖДАЮ Главный диспетчер _____________ Петров А. В. |
||||
|
СВЕДЕНИЯ О ПРОДАЖЕ БИЛЕТОВ НА 25.09.2009, 14: 00 |
|||||
| № | Номер рейса | Количество мест | Проданные места | Стоимость билета | |
| 1 | 153 | 32 | 30 | 400 | |
| 2 | 149 | 52 | 48 | 3600 | |
| 3 | 241 | 48 | 45 | 350 | |
| 4 | 111 | 20 | 20 | 4500 | |
| 5 | 100 | 34 | 33 | 700 | |
|
ИТОГО: количество мест 186 продано мест 176 свободно мест 10 |
|||||
| Начальник смены __________________ | |||||
На следующем этапе следует продумать структуру экономических показателей путем расчленения всех сведений на показатели, а потом объединить реквизиты родственных показателей по принципу «В одно отношение включается группа экономических показателей с одинаковым составом реквизитов-признаков». Такой подход позволяет создать структуру базы данных с минимальной избыточностью.
Основная задача проектирования базы данных — это определение количества файлов и их реквизитного состава.
Реквизит — это совокупность значений некоторого фиксированного набора переменных. Различают реквизиты-признаки и реквизиты-основания.
Реквизит-признак — это информационное отображение качественного свойства некоторого объекта.
Реквизит-основание — это информационное отображение количественного свойства некоторого объекта.
В состав экономического показателя должны входить один реквизит-основание и несколько реквизитов-признаков, однозначно характеризующих условие существования основания.
Для определения признаков и оснований я пользовалась следующими правилами:
основание
2. Если реквизит текстовый, то это признак;
3. Если реквизит обозначает предмет или время — это признак;
4. Если реквизит в некотором показателе является признаком (основанием), то он будет играть эту же роль в других показателях;
5. Если показатели описывают сходные процессы, то их призначные части совпадают;
6. Если основание показателя вычисляется по значениям других оснований, то набор признаков такого показателя — это объединение признаков, связанных с этими основаниями.
К реквизитам основаниям относятся: стоимость билета, количество мест, проданные места.
К реквизитам признакам относятся: время в пути, пункт отправления, пункт назначения, дата отправления, ФИО водителя, сменный водитель, основной водитель, номер автобуса, номер водителя, номер билета, номер рейса.
Можно сделать вывод, что в документах приложения базы данных «Автостанция» будет 3 показателя. Подберем реквизиты-признаки для каждого основания и получим показатели.
Стоимость билета
В результате структура показателя П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. Вывести список рейсов в один и тот же город с указанием времени пути и стоимости билета.
Этот запрос относится к
Запрос будет выглядеть так:
Вход запроса:
Выход запроса:
Оболочка запроса:
В проектной части необходимо выполнить следующие этапы:
1. Проектирование базы данных (определение состава полей её таблиц и связей между ними).
2. Создание базы данных.
3. Программирование выполнения операций над данными.
После анализа особенностей автоматизируемой области деятельности следует приступить к, возможно, самому важному этапу — проектированию будущей БД, которое заключается в определении состава полей её таблиц и связей между ними. От того, насколько тщательно проведен анализ и насколько грамотно спроектирована БД, в существеннейшей мере зависит эффективность будущего приложения БД и его полезность для пользователя.
В проектируемой базе данных должно быть 4 таблицы (исходя из полученных четырех отношений в 3НФ).
В таблице Avtobysразместим полные сведения о каждом автобусе. Таблица Voditelпредназначена для хранения сведений о водителях — то есть: номер водителя, ФИО водителя и его смена. В таблице Bilet содержится информация о билетах с указанием номера рейса и стоимости. В таблице Reis — будут храниться все необходимые сведения о рейсе — с указанием номера, даты отправления, пункта отправления и назначения, номера автобуса, номера водителя, времени в пути.
Таким образом, таблица Reisдолжна иметь уникальное поле, которое будет определять каждый рейс, можно в качестве уникального взять поле номер рейса. Позже следует создать ключ по этому полю, чтобы база данных могла быстро найти этот рейс.
Таблица Reis:
| Имя поля | Назначение |
| Nomer_reisa | Уникальный идентификатор рейса |
| Nomer_voditelya | Уникальный идентификатор водителя |
| Nomer_avtobysa | Уникальный идентификатор водителя |
| Pynkt_otpravleniya | Пункт отправления |
| Pynkt_naznacheniya | Пункт назначения |
| Data_otpravleniya | Дата отправления |
| Prodannie_mesta | Количество проданных мест |
| Vremya_v_pyti | Время в пути (первичный ключ) |
Таблица Avtobys:
| Имя поля | Назначение |
| Nomer_avtobysa | Уникальный идентификатор автобуса |
| Pynkt_otpravleniya | Пункт отправления |
| Pynkt_naznacheniya | Пункт назначения |
| Kolichestvo_mest | Количество мест в данном автобусе |
Таблица Voditel:
| Имя поля | Назначение |
| Nomer_voditelya | Уникальный идентификатор водителя |
| FIO_voditelya | ФИО водителя |
| Smena | Логическое поле (True/False) |
Таблица Bilet:
| Имя поля | Назначение |
| Nomer_bileta | Уникальный идентификатор билета |
| Nomer_reisa | Уникальный идентификатор рейса |
| Stoimost | Цена |
Под созданием базы данных подразумевается создание таблиц будущей БД, проектирование связей между ними, а также задание свойств таблиц. При необходимости следует ввести контроль за содержимым полей, проверку правильности введенного в поле значения; добавить вычисляемые и просматриваемые поля. Перед созданием БД необходимо создать каталог, в котором будут размещаться таблицы, и настроить рабочий каталог утилиты DataBaseDesktop (File/WorkingDirectory).
После определения структуры таблиц создадим все таблицы базы данных «Автостанция».
Так как в базе данных поле Nomer_reisaдолжно содержать ссылку на купленный билет в таблице Bilet, то требуется установить однозначную связь между этими полями.
Поле Nomer_voditelya в таблице Voditel должно содержать ссылку на рейс в таблице Reis. Поэтому устанавливаем однозначную связь между этими полями.
Поле Nomer_avtobysaв таблице Avtobysдолжно содержать ссылку на рейс в таблице Reis. Для этого устанавливаем однозначную связь между этими полями.
Важным шагом, конечно же, является конструирование главной и вспомогательных (при необходимости) форм. Delphiпредоставляет разработчику широкие возможности быстрого и качественного проектирования графического интерфейса пользователя. Но следует учесть, что разработанное приложение будет являться одним из приложений Windows, и от графического интерфейса, оптимально удобного расположения компонентов — зависит производительность работы пользователя с вашим программным продуктом. Каждое окно, которое вы вводите в свое приложение должно быть тщательно продумано и скомпоновано, неудачная компоновка может рассеивать внимание, отвлекать на поиск нужной кнопки и т.д. При проектировании приложения важно правильно определить последовательность фокусировки элементов.
В данной работе были использованы следующие компоненты Delphi:
1. Button — является простейшей и, пожалуй, наиболее часто используемой кнопкой, которая располагается на странице библиотеки Standard. Основное событие любой кнопки — OnClick , возникающее при щелчке на ней. Именно в обработчике этого события записываются операторы, которые должны выполняться при щелчке пользователя на кнопке. Из методов, присущих кнопкам, имеет смысл отметить один — Click . Выполнение этого метода эквивалентно щелчку на кнопке, т.е. вызывает событие кнопки OnClick . Этим можно воспользоваться, чтобы продублировать какими-то другими действиями пользователя щелчок на кнопке.
RadioGroup — э
3 . Label — используется для отображения различных надписей на форме. Тексты, отображаемые в перечисленных компонентах, определяются значением их свойства Caption. Его можно устанавливать в процессе проектирования или задавать и изменять программно во время выполнения приложения. Для метки Label цвет и шрифт — единственно доступные элементы оформления надписи. Размер метки Label определяется также свойством AutoSize . Если это свойство установлено в true , то вертикальный и горизонтальный размеры компонента определяются размером надписи. Если же AutoSize равно false , то выравнивание текста внутри компонента определяется свойством Alignment , которое позволяет выравнивать текст по левому краю, правому краю или центру клиентской области метки.
4 . В компоненте Edit вводимый и выводимый текст содержится в свойстве Text . Это свойство можно устанавливать в процессе проектирования или задавать программно. Выравнивание текста, как это имело место в метках и панелях, невозможно. Перенос строк тоже невозможен. Текст, не помещающийся по длине в окно, просто сдвигается и пользователь может перемещаться по нему с помощью курсора. Окна редактирования можно использовать и просто как компоненты отображения текста. Для этого надо установить в true свойство ReadOnly. При использовании окон редактирования для вывода, ввода и редактирования чисел необходимо использовать функции взаимного преобразования строк и чисел. Для вывода это описанные при рассмотрении меток функции FloatToStr и IntToStr . При вводе это функции StrToFloat — преобразование строки в значение с плавающей запятой, и StrToInt — преобразование строки в целое значение. Свойство MaxLength определяет максимальную длину вводимого текста. Если MaxLength = 0 , то длина текста не ограничена. В противном случае значение MaxLength указывает максимальное число символов, которое может ввести пользователь.
5.com boBox — отображает списки строк. Этот компонент позволяет отображать список как в развернутом виде, так и в виде выпадающего списка, что обычно удобнее, так как экономит площадь окна приложения. Основное свойство этого компонента, содержащее список строк, — 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.
DataSource
Еще одна функция компонента DataSourceзаключается в синхронизации поведения компонентов отображения данных с состоянием набора данных. Если набор данных работает в режиме «только для чтения», то компонент DataSourceобязан передать в компоненты отображения данных запрещение на изменение данных.
Компонент DataSourceорганизует передачу в компоненты отображения данных значений необходимых полей из текущей записи. При перемещении по записям набора данных текущие значения полей в компонентах отображения данных автоматически обновляются.
TDBNavigator
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с.: ил. (ч/з ПаУ)
