Вход

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

Рекомендуемая категория для самостоятельной подготовки:
Курсовая работа*
Код 289517
Дата создания 05 сентября 2014
Страниц 28
Мы сможем обработать ваш заказ 10 октября в 12:00 [мск]
Файлы будут доступны для скачивания только после обработки заказа.
650руб.
КУПИТЬ

Описание

Отличная работа!!! Была выполнена на заказ, защищена на 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

Список литературы

СПИСОК ЛИТЕРАТУРЫ

1. Архангельский А.Я. Программирование в Delphi 7. - М.: ЗАО “Издательство БИНОМ”, 2010. - 1070с.: ил. (ч/з ПаУ)
2. Фаронов В.В. Программирование баз данных в Delphi 6. Учебный курс. - СПб.: Питер, 2008. - 352с.: ил.
3. Дарахвелидзе П.Г., Марков Е.П. Delphi - среда визуального программирования: - СПб.: BHV - Санкт-Петербург, 1996. - 352с.
4. Гофман В.Э., Хомоненко А.Д. Delphi. Быстрый старт. - СПб.: БХВ - Санкт-Петербург, 2002. - 208с.: ил. (ч/з ПаУ)
5. Фаронов В.В. Delphi 4. Учебный курс. - М.: "Нолидж", 2009. - 464с.: ил. (ч/з ПаУ)
6. Фаронов В.В. Delphi 5 Учебный курс. - М.: "Нолидж", 2000. - 606с.: ил. (ч/з ПаУ)
7. Фаронов В.В. Delphi 6. Учебный курс. - М.: Издатель Молгачева С.В., 2009. - 672с. (ч/з ПаУ)
8. Фаронов В.В. Шумаков П.В. Delphi 4. Руководство разработчика баз данных. - М.: “Нолидж”, 1999. - 560с.: ил.
9. Фаронов В.В. Шумаков П.В. Delphi 5. Руководство разработчика баз данных. - М.: “Нолидж”, 2012. - 640с.: ил. (ч/з ПаУ)
10. Хендерсон К. Руководство разработчика баз данных в Delphi 2/Пер. с англ. - К.: "Диалектика", 2007. - 544с.
11. Культин Н.Б. Delphi 6. Программирование на Object Pascal. Самоучитель. - СПб.: БХВ-Петербург, 2001. - 528с.: ил. (ч/з ПаУ)
12. Базы данных: интеллектуальная обработка информации В.В. Корнеев, А.Ф. Гареев, С.В. Васютин. - М.: Нолидж, 2011. - 352с.: ил. (ч/з ПаУ)
Размещено на Allbest.ru
Пожалуйста, внимательно изучайте содержание и фрагменты работы. Деньги за приобретённые готовые работы по причине несоответствия данной работы вашим требованиям или её уникальности не возвращаются.
* Категория работы носит оценочный характер в соответствии с качественными и количественными параметрами предоставляемого материала. Данный материал ни целиком, ни любая из его частей не является готовым научным трудом, выпускной квалификационной работой, научным докладом или иной работой, предусмотренной государственной системой научной аттестации или необходимой для прохождения промежуточной или итоговой аттестации. Данный материал представляет собой субъективный результат обработки, структурирования и форматирования собранной его автором информации и предназначен, прежде всего, для использования в качестве источника для самостоятельной подготовки работы указанной тематики.
© Рефератбанк, 2002 - 2022