Базы данных расписаний маршрутов движения транспорта

Отличная работа!!! Была выполнена на заказ, защищена на 5! Содержит рисунки, таблицы, практические материалы исследования, а также приложения. Очень выгодное предложение, остается только поменять название города или год. ...

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ…………………………………………………………….……3
1. РАЗРАБОТКА ТРЕБОВАНИЯ К БАЗЕ ДАННЫХ……………..….5
1.1 Постановка задачи………………………………………………..….….5
1.2 Анализ информационных потоков, выбор модели …………..…...…5
2. ПРОЕКТНАЯ ЧАСТЬ………………………………………………... 17
2.1 Проектирование базы данных………………………………………..17
2.2 Создание базы данных……...……………………………………...…18
2.3 Программирование……………………………………………………19
ЗАКЛЮЧЕНИЕ…………………………………………………...............27
СПИСОК ЛИТЕРАТУРЫ……………………………............................28

ВВЕДЕНИЕ

В современных условиях возрастает значение информационных систем, позволяющих обеспечить информационную поддержку процессов принятия решений. Базы данных являются одним из основных элементов большинства информационных систем. Базой данных является представленная в объективной форме совокупность самостоятельных материалов, систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины. Рассматривая такую предметную область как расписание маршрутов движения транспорта, несомненно, невозможно обойтись без структурирования информации в базу данных. База данных обладает, по меньшей мере, тремя важными свойствами (признаками):
1. База данных хранится и обрабатывается в вычислительной системе. Таким образом, любые внек омпьютерные хранилища информации (архивы, библиотеки и т.п.) базами данных не являются.
2. Данные в базе данных хорошо структурированы (систематизированы). Под структурированностью в данном случае понимается явное выделение составных частей (элементов) и связей между ними.
3. Структура базы данных обеспечивает эффективный поиск и обработку данных. Эффективность здесь главным образом определяется тем, как соотносятся гибкость и мощность возможностей (поиска и обработки) с затратами усилий и ресурсов.
Актуальность создания приложения базы данных, как части информационной системы, очевидна - хранение в удобном виде, возможность совместного использования базы данных несколькими пользователями, средства поддержания данных в актуальном состоянии, возможность построения отчетов по запросу пользователя.
При написании курсовой работы использованы учебные пособия по программированию в Delphi, учебные материалы, а также статейный материал, в котором рассматриваются актуальные вопросы необходимости создания базы данных программирования в Delphi.
Структура работы в соответствии с задачами исследования включает в себя введение, две главы, заключение, а также список используемой литературы.

СВЕДЕНИЯ О ПРОДАЖЕ БИЛЕТОВ
НА 25.09.2013, 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
Начальник смены __________________
На следующем этапе следует продумать структуру экономических показателей путем расчленения всех сведений на показатели, а потом объединить реквизиты родственных показателей по принципу «В одно отношение включается группа экономических показателей с одинаковым составом реквизитов-признаков». Такой подход позволяет создать структуру базы данных с минимальной избыточностью.
Основная задача проектирования базы данных - это определение количества файлов и их реквизитногосостава.
Реквизит - это совокупность значений некоторого фиксированного набора переменных. Различают реквизиты-признаки и реквизиты-основания.
Реквизит-признак - это информационное отображение качественного свойства некоторого объекта.
Реквизит-основание - это информационное отображение количественного свойства некоторого объекта [4, c. 271].
В состав экономического показателя должны входить один реквизит-основание и несколько реквизитов-признаков, однозначно характеризующих условие существования основания.
Для определения признаков и оснований я пользовалась следующими правилами:
1. Если значение реквизита является исходным данным или результатом арифметической операции, то это основание;
2. Если реквизит текстовый, то это признак;
3. Если реквизит обозначает предмет или время - это признак;
4. Если реквизит в некотором показателе является признаком (основанием), то он будет играть эту же роль в других показателях;
5. Если показатели описывают сходные процессы, то их призначные части совпадают;
6. Если основание показателя вычисляется по значениям других оснований, то набор признаков такого показателя - это объединение признаков, связанных с этими основаниями.
К реквизитам основаниям относятся: стоимость билета, количество мест, проданные места.
К реквизитам признакам относятся: время в пути, пункт отправления, пункт назначения, дата отправления, ФИО водителя, сменный водитель, основной водитель, номер автобуса, номер водителя, номер билета, номер рейса.
Можно сделать вывод, что в документах приложения базы данных «Автостанция» будет 3 показателя. Подберем реквизиты-признаки для каждого основания и получим показатели.
У основания Стоимость билета необходимыми признаками будут номер билета (для определения рейса), номер рейса, время в пути (для определения пункта назначения).
В результате структура показателя П1 примет вид:
П1 (номер билета, номер рейса, время в пути, стоимость билета).
У основания Количество мест необходимыми признаками будут номер рейса, номер автобуса, пункт отправления, пункт назначения, дата отправления.
В результате структура показателя П2 примет вид:
П2 (номер рейса, номер автобуса, пункт отправления, пункт назначения, дата отправления, количество мест).
У основания Проданные места необходимыми признаками будут номер рейса, номер автобуса, номер водителя, ФИО водителя, сменный водитель, основной водитель.
В результате структура показателя П3 примет вид:
П3 (номер рейса, номер автобуса, номер водителя, ФИО водителя, сменный водитель, основной водитель, проданные места).
Показатель является минимальной группой реквизитов, сохраняющей информативность (осмысленность), и поэтому достаточной для образования документа. Но с другой стороны представление экономической информации в форме показателей не является универсальным, так как имеются значительные массивы осмысленной информации, не содержащие реквизитов оснований.
Методом, решающим этот недостаток является построение модели данных.
Модель данных - это совокупность трех составляющих:
множество информационных конструкций, допускаемых этой моделью;
множество допустимых операций над данными;
множество ограничений, наложенных на информационные конструкции.
Иными словами модель данных - это инструмент для представления данных в базе данных.
В целях обеспечения наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных построим модель, называемую "сущность-связь". Эту модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами таких моделей являются сущности, связи между ними и их свойства (атрибуты) [8, c. 162].
Сущность - любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных.
В проектируемой базе данных сущностями будут являться: РЕЙС, БИЛЕТ, АВТОБУС, ВОДИТЕЛЬ.
Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ВОДИТЕЛЬ, а экземпляром - Иванов, Петров и т.д.
Атрибут - поименованная характеристика сущности. Примерами атрибутов для сущности БИЛЕТ будут номер билета, стоимость и т.д.
Ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. К примеру в сущности РЕЙС исключение из атрибутов такого как ID рейса не позволит однозначно определить рейс, поэтому ключом сущности РЕЙС является атрибут - ID рейса.
Связь - ассоциирование двух или более сущностей. Для выявления связей между сущностями необходимо, как минимум, определить сами сущности и их атрибутный состав. Построим модель "сущность-связь":

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:
Имя поля
Назначение
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