Проектирование базы данных "Автовокзал"

Содержание

Введение

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

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

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

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

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

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

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

Заключение

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реквизиты:

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

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

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

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

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

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

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

Начальник смены __________________

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

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

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

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

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

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

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

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) реквизит А функционально определяет реквизит В, если в любой момент времени каждому значению А соответствует единственное значение В.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В проектируемой базе данных должно быть 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

Цена

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

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

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

Так как в базе данных поле 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 содержит следующие кнопки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для фильтрации записей в наборах данных используются методы 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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