Преподаватель который помогает студентам и школьникам в учёбе.

Разработка проекта информационной системы для Ж/Д вокзала

Содержание:

ВВЕДЕНИЕ

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

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

Задачи:

- проанализировать возможности баз данных и основные принципы построения таблиц;

- создать базу данных. Занести в нее данные;

- организовать постоянные связи между таблицами для обеспечения целостности базы данных;

- на основе объединенных таблиц создать запросы в режиме конструктора;

- организовать к базе данных запросы на выборку информации.

Объектом исследования является организация продажи билетов на поезда через железнодорожные кассы согласно расписания пассажирских перевозок.

1 ВЫБОР СРЕДСТВ И МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ ЖЕЛЕЗНОДОРОЖНОГО ВОКЗАЛА

1.1 Методология проектирования базы данных

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

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

Методология проектирования БД предусматривает разбиение всего процесса проектирования на несколько фаз, каждая из которых состоит из нескольких этапов.

Общепринятая методология проектирования БД разделяется на 3 основные фазы:

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

- логическое проектирование – это процесс конструирования информационной модели на основе существующих моделей данных, не зависимо от используемой СУБД и других условий физической реализации;

- физическое проектирование – это процедура создания описания конкретной реализации БД с описанием структуры хранения данных, методов доступа к данным.

В целом методология проектирования БД включает следующие этапы:

1. Создание концептуальной модели данных, исходя из представлений о предметной области, каждого из пользователей. Шаги:

1.1 определение типов сущности;

1.2 определение типов связей;

1.3 определение атрибутов и связывание их с типами сущностей и связей;

1.4 определение доменов атрибутов;

1.5 определение атрибутов, являющихся потенциальными и первичными ключами;

1.6 создание диаграмм “сущность ¬– связь”;

1.7 обсуждение локальной концептуальной модели с конечным пользователем.

2. Построение и проверка локальной логической модели данных на основе представления. Шаги:

2.1 преобразование локальной концептуальной модели в локальную логическую модель;

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

2.3 проверка модели с помощью правил нормализации;

2.4 проверка модели в отношении транзакции пользователя;

2.5 создание диаграмм “сущность – связь”;

2.6 определение требований поддержки целостности данных;

2.7 обсуждение локальной логической модели с конечным пользователем;

3. Создание и проверка глобальной логической модели данных. Шаги:

3.1 слияние локальных и логических моделей в единую модель;

3.2 проверка глобальной логической модели;

3.3 проверка возможности расширения проблемы в будущем;

3.4 создание окончательного варианта диаграммы “сущность – связь”;

3.5 обсуждение глобальной логической модели с конечным пользователем;

4. перенос глобальной логической модели данных в среду целевой СУБД – это физическое проектирование данных и ориентировано на реляционные СУБД. Шаги:

4.1 создание основных таблиц в среде СУБД;

4.2 реализация бизнес-правил предприятия среди СУБД.

5. Проектирование физического представления БД. Шаги:

5.1 анализ транзакций;

5.2 выбор файловой структуры;

5.3 определение вторичных индексов;

5.4 контроль за избыточностью данных;

5.5 определение требований дисковой памяти.

6. Разработка механизмов защиты. Шаги:

6.1 разработка пользовательских представлений;

6.2 определение прав доступа к данным;

1.2 Выбор средств проектирования базы данных

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

Наиболее простой в обращении и дружественной к пользователю является СУБД MS Аccess. Microsoft Access - это самая популярная сегодня настольная система управления базами данных. Ее успех можно связывать с великолепной рекламной кампанией, организованной Microsoft, или включением его в богатое окружение продуктов семейства Microsoft Office. СУБД Access имеет русифицированный интерфейс и переведенный на русский язык файл контекстной помощи.

Access для работы с данными использует процессор баз данных Microsoft Jet, объекты доступа к данным и средство быстрого построения интерфейса - Конструктор форм. Для получения распечаток используются Конструкторы отчетов. Автоматизация рутинных операций может быть выполнена с помощью макрокоманд. На тот случай, когда не хватает функциональности визуальных средств, пользователи Access могут обратиться к созданию процедур и функций. При этом как в макрокомандах можно использовать вызовы функций, так и из кода процедур и функций можно выполнять макрокоманды.

Несмотря на свою ориентированность на конечного пользователя, в Access присутствует язык программирования Visual Basic for Application, который позволяет создавать массивы, свои типы данных, вызывать DLL-функции, с помощью OLE Automation контролировать работу приложений, которые могут функционировать как OLE-серверы. Также Access поддерживает работу с языком программирования БД – SQL.

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

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

2 РАЗРАБОТКА БАЗЫ ДАННЫХ Ж/Д КАССЫ

2.1 Исследование предметной области для разработки базы данных

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

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

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

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

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

В рамках данной предметной области имеются следующие сущности (в скобках указаны атрибуты):

- «Поезда» (№п/п, Код поезда, Наименование поезда, Количество мест);

- «Города» (№п/п, Наименование города);

- «Маршруты» (№п/п, Код маршрута, Название начального города, Название конечного города);

- «Рейсы» (№ записи, Код рейса);

- «Расписание перевозок» (№ записи, Код перевозки, Дата, Код поезда, Код рейса);

- «Билет» (№ записи, № билета, Поезд, Код перевозки, Дата, Верхняя полка, Цена билета).

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

2.2 Разработка инфологической модели данных

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

При инфологическом моделировании баз данных в научной литературе используется модель Чена «сущность—связь», или «Entity Relationship».

Анализ объектов и атрибутов предметной области позволяет выделить сущности проектируемой базы данных и, приняв решение о создании реляционной базы данных, построить ее инфологическую модель в категориях «Таблицы-связи». Инфологическая модель данных для предметной области имеет несколько таблиц и связи между ними.

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

Составляют

Маршруты

№ билета

Рейсы

Код рейса

Расписание перевозок

Код перевозки

Города

Наименование города

Поезда

Код поезда

Реализуется

Составляют

Движутся по

Журнал продажи билетов

№ билета

Ответственные лица

ФИО кассира

Указаны

Рисунок 1. Модель данных ж/д кассы

2.3 Разработка даталогической модели и ER модели данных

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

Таблица 1 – Даталогическая модель

Наименование сущности	Имя поля	Тип данных
1	2	3
«Поезда» (справочник)
	№ п/п	Счетчик
	Код поезда	Текстовый
	Наименование поезда	Текстовый
	Количество мест	Числовой
«Города» (справочник)
	№ п/п	Счетчик
	Наименование города	Текстовый
«Маршруты» (справочник)
	№ записи	Счетчик
	Код маршрута	Текстовый
	Название начального города	Текстовый
	Название конечного города	Текстовый
	Стоимость проезда	Денежный
	Код рейса	Текстовый
«Рейсы» (справочник)
	№ записи	Счетчик

Продолжение таблицы 1

1	2	3
	Код рейса	Текстовый
«Расписание перевозок» (справочник)
	№ записи	Счетчик
	Код перевозки	Текстовый
	Дата	Дата/Время
	Код поезда	Текстовый
	Код рейса	Текстовый
«Журнал продажи билетов» (рабочий Журнал)
	№ записи	Счетчик
	№ билета	Текстовый
	Поезд	Текстовый
	Код перевозки	Текстовый
	Дата	Дата/Время
	Верхняя полка	Логический
	Цена билета	Денежный
«Ответственные лица» (Справочник)
	№ п/п	Счетчик
	ФИО кассира	Текстовый
	Табельный номер	Текстовый

На основе анализа научной литературы можно сделать вывод, что четкого различия между понятиями «инфологическая модель», «даталогическая модель» и «ER-модель» практически не существует, так как применения современных средств визуального проектирования моделей БД (так называемых CASE-средств) предполагает формирование единого изображения модели базы данных.

ER-модель представляет собой графическое описание предметной области в терминах «объект – свойство – связь». Использование ER-моделирования дает упор на качество связей между сущностями через их атрибуты.

Модель «сущность-связь» предметной области курсового проекта представлена на рисунке 2.

Связь (relationship) - это ассоциация, установленная между несколькими сущностями.

Существует несколько видов связей в БД в зависимости от их «мерности» (т.е. сколько экземпляров одной сущности можно сопоставить экземплярам другой сущности). Выделяют следующие виды связей в реляционных БД:

Рисунок 2. Модель предметной области в виде ER-диаграммы

Выделяют три типа связей:

- «один-к-одному» - любому экземпляру сущности А соответствует только один экземпляр сущности В, и наоборот;

- «один-ко-многим» (и его обратный вариант «многие-к-одному») - любому экземпляру сущности А соответствует несколько экземпляров сущности В, но любому экземпляру сущности В соответствует только один экземпляр сущности А (и наоборот).

- «многие-ко-многим» - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, и любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.

В реляционных СУБД тип связи «многие-ко-многим» недопустим, так как отношения межу сущностями становятся хаотичными и пропадает возможность однозначной идентификации отношений. по ключевым атрибутам. Поэтому для «разбиения» такой связи на «один-ко-многим» используется дополнительная сущность.

Таким образом, ER-модель, отражающая рабочий процесс по продаже билетов на ж/д поезд, имеет древовидную сложную структуру. Таблицы справочных данных представлены шестью сущностями, седьмая – формирует рабочую таблицу «Журнал продажи билетов», на основе которой строятся запросы, отражающие деятельность железнодорожной кассы.

2.4 Разработка физической модели

Для реализации базы данных в определённой программно-технической среде СУБД необходимо описание структур хранимых данных в терминах этой среды — физическая схема (модель) данных.

Физические модели баз данных определяют способы размещения данных в среде хранения и способы доступа к этим данным, которые поддерживаются на физическом уровне. Исторически первыми системами хранения и доступа были файловые структуры и системы управления файлами.

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

С ростом объемов хранимых данных они стали неэффективными для использования СУБД. Произошел переход от базовых файловых структур к непосредственному управлению размещением данных на внешних носителях самой СУБД. При этом таблицы атрибутов сущностей, запросы, модули отчетов могут храниться в отдельных файлах, либо в одном файле БД при так называемой без файловой организации.

Таким образом, физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т. п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т. д (рисунок 3).

Рисунок 3. Физическая модель базы данных

3 СОЗДАНИЕ БАЗЫ ДАННЫХ ЖЕЛЕЗНОДОРОЖНОГО ВОКЗАЛА

3.1 Создание структуры базы данных железнодорожной кассы

Наиболее часто используемым способом создания файла базы данных является выбор из соответствующего меню позиции «создать новый файл базы данных».

Создание структуры базы данных начинается с создания таблиц, в которых и хранится информация о предметной области. Создать таблицу можно в разных режимах: режиме таблицы, конструктора, мастера таблиц, импорта таблиц и связи с таблицами. Для создания новой таблицы в окне Базы данных нужно выбрать вкладку Таблица и перейти к режиму конструктора как наиболее часто используемому (Рисунок 4).

Рисунок 4. Создание таблиц базы данных в режиме конструктора

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

Таблица 2. Свойства полей

Наименование свойства/поля	№ п/п (№ записи)	Код ...	Наименование города/ поезда	Стоимость/Цена	Дата	Верхняя полка	Место/ Кол-во мест
Тип поля	Счетчик	Текстовый		Денежный	Дата/ Время	Логический	Числовой
Размер поля	Длинное целое	255			-	-	Длинное целое
Число десятичных знаков	-	-	-	2	-	-	0
Новые значения	Последовательные	-	-	-	-	-	-
Формат поля	-	-	-	-	-	Да/Нет	-
Маска ввода	-	-	-	-	ДД.ММ.ГГ.	-	-
Значение по умолчанию	-	-	-	0	Date() Текущ. дата	Нет	-
Обязатеьное поле	Да	Да	Да	Да	Да	Да	Да
Пустые строки	Да	Нет	Да	Да	Да	Да	Да
Индексированное поле	Нет	Да	Нет	Нет	Нет	Нет	Нет

Для полей, значения которых берутся из связанных таблиц заполняем в свойствах закладку «Подстановка» (Таблица 3).

Таблица 3. Подставноки для связанных таблиц

Наименование	Тип элемента управления	Тип источника строк	Источник строк
Наименование начального/конечного города	Поле со списком	Таблица или запрос	SELECT Города.[№ п/п] FROM Города;
Код рейса	Поле со списком	Таблица или запрос	SELECT Рейсы.[Код рейса] FROM Рейсы;
Поезд	Поле со списком	Таблица или запрос	SELECT Поезда.[Код поезда], Поезда.[Наименование поезда] FROM Поезда;
Код перевозки	Поле со списком	Таблица или запрос	SELECT [Расписание перевозок].[Код перевозки] FROM [Расписание перевозок];
Кассир	Поле со списком	Таблица или запрос	SELECT [Ответственные лица].[ФИО кассира] FROM [Ответственные лица];

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

Рисунок 5. Пример таблиц базы данных ж/д кассы

Структуру базы данных хорошо отражает схема данных, которая создается щелчком по соответствующему пункту на закладке меню «Работа с базами данных» (рисунок 6).

При работе со схемой данных в Access появляется закладка меню «Конструктор». С его помощью можно:

- изменять связи между таблицами;

Рисунок 6. Создание схемы данных и связей между таблицами

- составить отчет по схеме данных;

- отобразить или скрыть таблицу;

- отобразить или скрыть прямые связи или все связи.

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

Рисунок 7. Создание схемы данных и связей между таблицами

3.2 Создание пользовательского интерфейса базы данных железнодорожной кассы

Пользовательский интерфейс в Access реализуется с помощью Главной кнопочной формы. Кнопочная форма – это форма, открывающая другие формы или отчеты базы данных. Для того чтобы запустить эту программу, в меню «Работа с базами данных» выберем «Диспетчер кнопочных форм».

Создавая многоуровневый интерфейс, каждая группа кнопок будет размещаться на отдельной странице кнопочной формы, создадим новые страницы с помощью кнопки «Создать». Элементы для каждой из страниц кнопочной формы создадим, щелкнув по кнопке «Изменить» (рисунок 8).

Рисунок 8. Диспетчер кнопочных форм

В главной форме предусмотрим основную страницу из которой можно зайти на страницы формы. (рисунок).

Рисунок 9. Кнопочные формы БД продажи ж/д кассы

Если запустить кнопочную форму в режиме макета, то можно изменить оформление и добавить эмблему.

Для заполнения таблиц используем формы (выделить таблицу, которую будем заполнять – закладка «Создание» – «Форма»):

- простая форма – отражает только заполняемые поля таблицы,

- разделенная форма – отображает саму форму для заполнения полей таблицы и содержание таблице в нижней половине окна.

Будем использовать простые формы для справочников и разделенную форму для журнала продаж билетов.

Рисунок 10. Формы для заполнения таблиц БД ж/д кассы

3.3 Создание запросов к базе данных железнодорожной кассы

Для создания запроса на закладке «Создание» выбираем «Конструктор запросов». Затем выполняем щелчок правой копкой мыши и добавляем нужные таблицы. В нижней части окна конструктора (карточке запроса) выбираем поля, которые будут участвовать в запросе, флажком отмечаем те поля, которые выводятся на экран и прописываем условия отбора или групповые операции (по необходимости.

Для реализации билетов необходимы такие запросы:

1) калькулятор стоимости проезда. Запрос с условием, в качестве условия отбора клиента используется приглашение [Введите название начального города], [Введите название конечного города], также выводится стоимость маршрута. Конструктор запроса приведен на рисунке 11.

Рисунок 11. Запрос стоимости проезда

2) запрос количества свободных мест на ближайший рейс (рисунок 12). используется приглашение [Введите пункт назначения]. В качестве условий отбора установлена ближайшая дата, а также что номер последнего проданного места меньше общего количества мест в поезде. Конструктор запроса приведен на рисунке 12.

Рисунок 12. Запрос количества свободных мест

3) запрос на номера свободных мест – возвращает номер последнего проданного места. Начиная со следующего номера, места являются свободными. Отбор производится по дате и количеству ранее проданных мест. Если все места в поезде проданы, запрос выдаст нулевой результат. Конструктор запроса приведен на рисунке 13.

Рисунок 13. Запрос номеров занятых мест

Структура SQL приведена в таблице 4.

Таблица 4. Структура SQL-запросов

Наименование запроса	Структура SQL
Стоимость проезда	SELECT Маршруты.[Название начального города], Маршруты.[Название конечного города], Маршруты.[Стоимость проезда] FROM Маршруты GROUP BY Маршруты.[Название начального города], Маршруты.[Название конечного города], Маршруты.[Стоимость проезда] HAVING (((Маршруты.[Название начального города])=[Введите название начального города]) AND ((Маршруты.[Название конечного города])=[Введите название конечного города]));
Количество свободных мест	SELECT [Количество мест]-[Место] AS [Свободные места] FROM (Поезда INNER JOIN (Рейсы INNER JOIN [Расписание перевозок] ON Рейсы.[Код рейса] = [Расписание перевозок].[Код рейса]) ON Поезда.[Код поезда] = [Расписание перевозок].[Код поезда]) INNER JOIN [Журнал продажи билетов] ON ([Расписание перевозок].[Код перевозки] = [Журнал продажи билетов].[Код перевозки]) AND (Поезда.[Код поезда] = [Журнал продажи билетов].Поезд) WHERE ((([Расписание перевозок].Дата)=Date() Or ([Расписание перевозок].Дата)>Date()) AND (([Журнал продажи билетов].[Пункт назначения])=[Введите пункт назначения])) GROUP BY [Количество мест]-[Место], [Расписание перевозок].Дата, Поезда.[Количество мест] HAVING (((Count([Журнал продажи билетов].Место))<[Количество мест]));
Номера незанятых мест	SELECT [Журнал продажи билетов].Место, [Расписание перевозок].Дата FROM (Поезда INNER JOIN (Рейсы INNER JOIN [Расписание перевозок] ON Рейсы.[Код рейса] = [Расписание перевозок].[Код рейса]) ON Поезда.[Код поезда] = [Расписание перевозок].[Код поезда]) INNER JOIN [Журнал продажи билетов] ON (Поезда.[Код поезда] = [Журнал продажи билетов].Поезд) AND ([Расписание перевозок].[Код перевозки] = [Журнал продажи билетов].[Код перевозки]) WHERE ((([Расписание перевозок].Дата)=Date()) AND (([Журнал продажи билетов].Поезд)=[Введите № Поезд])) GROUP BY [Журнал продажи билетов].Место, [Расписание перевозок].Дата, [Количество мест]-[Место], Поезда.[Количество мест], [Расписание перевозок].Дата HAVING ((([Журнал продажи билетов].Место)<[Количество мест]));

3.4 Создание отчетов к базе данных железнодорожной кассы

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

Наиболее простой способ создания отчета:

- выделить базовый для отчета запрос,

- на закладке «Создание» выбрать и щелкнуть «Отчет»,

- отчет сформируется автоматически.

Также можно использовать Мастер отчетов:

- на закладке «Создание» выбрать и щелкнуть «Мастер отчетов»,

- на первом шаге выбрать поля запроса, которые отобразятся в отчете,

- на втором шаге задать уровни группировки,

- на третьем шаге установить сортировку и расчет промежуточных итогов,

- на четвертом шаге выбрать маке для отчета,

- на пятом шаге применяем стиль отчета,

- на шестом шаге завершаем создание отчета.

Готовые отчеты через закладку «Внешние данные» можно экспортировать в документ VS Word в формате *.rtf – файл для печати.

Результаты выполнения отчетов по базе данных представлены в Приложении А.

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

3.5 Создание руководства пользователя базы данных ж/д кассы

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

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

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

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

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

В четвертой главе, которая носит справочный характер, приводится описание модели данных БД.

ЗАКЛЮЧЕНИЕ

В процессе выполнения курсовой работы была достигнута цель – разработка базы данных, а также решены все поставленные задачи:

- рассмотрена методология проектирования базы данных;

- проведен выбор средств проектирования базы данных;

- исследована предметная область продажи железнодорожных перевозок;

- разработана инфологическая модель данных;

- разработана даталогическая модель и ER модели данных;

- разработана физическая модели данных железнодорожной кассы;

- создана структура базы данных;

- создан пользовательский интерфейс базы данных железнодорожной кассы;

- созданы запросы к базе данных для получения информации о свободных местах и стоимости проезда;

- созданы отчеты по всем запросам для размещения в Главной форме;

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ГОСТ Р50922-96. Государственный стандарт РФ «Защита информации». Общие положение от 2000-01-01
ГОСТ 19.001-77. ЕСПД. Общие положения.
ГОСТ 19.401-78. ЕСПД. Текст программы. Требования к содержанию и оформлению.
ГОСТ 19.701-90 (ИСО 5807-85). ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
ГОСТ 6.30-97 «Унифицированные системы документации. Система организационно-распорядительной документации. Требования к оформлению документов»
Анин, Б.Ю. Зашита компьютерной информации [Текст] / Б.Ю. Анин. – Спб.: BHV-Петербург, 2000.
Архангельский, А.Я. Программирование в Delphi 7 [Текст] / А.Я. Архангельскийю - М.:Бином, 2009.
Бойко, В.В. Проектирование баз данных информационных систем [Текст] / В.В. Бойко, В.М. Савинков. – М.: Финансы и статистика, 1989.
Вендров, А.М. CASEтехнологии. Современные методы и средства проектирования информационных систем [Текст]/ А.М. Вендров.  М.: Финансы и статистика, 2000
Гаскаров, Д.В. Интеллектуальные информационные системы [Текст] / Д.В. Гаскаров. – М.: Высшая школа, 2003.
Грофф, Дж. SQL: Полное руководство. Пер. с англ. — 2-е изд. перераб. и доп. [Текст] / Дж. Грофф, П. Вайнберг. — Киев: Издательская группа BHV, 2010. — 816 c.
Гребенюк Е.И., Гребенюк Н.А. Технические средства информатизации [Текст]/ и. – М.:Издательский центр "Академия", 2004.
Дейт, К. Введение в системы баз данных [Текст] / К. Дейт, пер. с англ. - М.:Наука, 2010. 463 с.
Дейв, Энсор Access. Проектирование баз данных. Пер. с англ. [Текст] / Энсор Дейв, Йен Стивенсон.— Киев: Издательская группа BHV, 2010. — 560 c.
Дейт, К. Дж. Введение в системы баз данных. Пер. с англ. — 8-е изд. [Текст] / — М.: Издательский дом «Вильямс», 2012. — 1328 с.
Драхведидзе, М.Г. «DELPHI 7.0 среда визуального программирования [Текст] / М.Г. Драхведидзе, Е.П. Марков - СП8:BHV –Санкт – Петербург, 2009г.,352с.
Диев, С.И. Организация и современные методы защиты информации [Текст] / С.И. Диев, А.Г. Шаваев. – М.: Концерн «Банковский Деловой Центр», 2008.
Демидова, Ю.Ю. Внедрение системы автоматизации кадрового учета своими силами // Справочник по управлению персоналом, 2010.
Душин, В. К. Теоретические основы информационных процессов и систем – М.: Издательство: Дашков и Ко , 2012.
Елманова, Н. Delphi и технология COM. [Текст] / Н.Елманова, С.Трепалин, А.Тенцер.— СПб.: Питер, 2012. — 704 с.
Епанешников, А.М., Епанешников В.А. «Delphi 7.0 Среда разработки». Учебное пособие [Текст] / А.М. Епанешников - М: Диалог – Мифи, 2009г.- 304с.
Зиндер, Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие [Текст] / Е.З. Зиндер. - М.: Центр Информационных Технологий, 2006
Ирвин, М. Access 2010. Библия пользователя [Текст] / М. Ирвин, К. Праг. – М.: «Диалектика», 2000. – 1040 с.
Калянов, Г.Н. CASE. Структурный системный анализ (автоматизация и применение) [Текст] / Г.Н. Калянов. - М., «Лори», 2006.
Каконин, В.И. Автоматизация службы персонала в общей системе управления предприятием // Справочник по управлению персоналом. – 2010, №9.
Клайн, К. SQL. Справочник. Пер. с англ. — 2-е изд. [Текст] / — М.: КУДИЦ-ОБРАЗ, 2012. — 832 с.
Коннолли, Томас Базы данных: проектирование, реализация и сопровождение. Теория и практика. Пер. с англ. [Текст] / Томас Коннолли, Каролин Бегг, Анна Страчан. — 2-е изд. — М.:Издательский дом "Вильямс", 2010. — 1120 с.
Кириллов, В.В. Основы проектирования реляционных баз данных учеб. пособие [Текст] / В.В. Кириллов. – СПб.: ИТМО, 2009.
Когаловский, М.Р. Перспективные технологии информационных систем [Текст]/ М.Р. Когаловский. – М.: ДМК–Пресс, Компания АТ, 2010.
Компьютерные программы для службы кадров // Справочник кадровика, 2003. №1-2.
Липаев, В.В Управление разработкой программных средств. Методы, стандарты, технология [Текст] / В.В. Липаев. – М.: Финансы и статистика, 2011.
Литеев, В.В. Системное проектирование сложных программных средств для информационных систем [Текст] / В.В. Литеев. – М.: Синтег, 2002.
Литеев, В.В. Программирование в Delphi 7 [Текст]/ В.В. Литеев. – М.: ООО «Бином–Пресс», 2013.
Мишенин, А.И. Теория экономических информационных систем: учеб. для вузов [Текст]/ А.И. Мишенин.- 4-е изд., доп. и перераб.-М.:Финансы и статистика, 2001.-240 с.:ил.
Нильсен, Пол. Microsoft SQL. Библия пользователя. Пер. с англ. [Текст] / Пол. Нильсен. — М.: Издательский дом «Вильямс», 2008. — 1232 с.
Новоженов, Ю.В. Объектно-ориентированные технологии разработки сложных программных систем [Текст] / Ю.В. Новоженов. - М.: Центр Информационных Технологий 2009.
Молинаро, Э. SQL. Сборник рецептов. Пер. с англ. [Текст] / Молинаро Э. — СПб.: Символ-Плюс, 2009. — 672 с.
Оскерко, В.С. Практикум по технологиям баз данных [Текст] / В.С. Оскерко, З.В. Пунчик. – Мн.: “БГЭУ”, 2010. – 170 с.
Осипов, Д. Delphi. Профессиональное программирование. [Текст] / Д. Осипов. — СПб.: Символ-Плюс, 2006. — 1056 с.
Осипов, Д. Графика в проектах Delphi. [Текст] / Д. Осипов. — СПб.: Символ-Плюс, 2008. — 648 с.
Паронжанов С. Объектно-ориентированные средства анализа, проектирования и реинжениринга информационных систем [Текст]/. – М.: учебные материалы конференции «Индустрия программирования 96». 1999 г. с.117-123.
Райордан, Р. Основы реляционных баз данных. Пер. с англ. [Текст] / Р. Райордан. — М.: Издательско-торговый дом «Русская редакция», 2011. — 384 с.
Роб, П. Системы баз данных: проектирование, реализация и управление. Пер с англ. — 5-е изд., перераб. и доп. [Текст] / П. Роб, К. Коронел. — СПб.: БХВ-Петербург, 2009. — 1040 с.
Сворт, Боб. Delphi 2010 DataSnap: новые возможности в управлении и доступе к данным. — www.drbob42.com, 2012.
Седжвик, Р. Фундаментальные алгоритмы на C++. Анализ/Структуры данных/Сортировка/Поиск: Пер. с англ./Роберт Седжвик. [Текст] / Р. Седжвик.— К.: Издательство «ДиаСофт», 2010. — 688 с.
Скляр, А.Я. Введение в InterBase. [Текст] / А.Я. Скляр. — М.: Горячая линия — Телеком, 2012. —517 с.
Тамре, Л. Введение в тестирование программного обеспечения: Пер. с англ. [Текст] / Л. Тамре. — М.: Издательский дом «Вильямс», 2009. — 368 с.
Титоренко, Г.А. Автоматизированные информационные технологии в экономике [Текст]/ под ред. Г.А. Титоренко – М.: ЮНИТИ, 1999.
Фуфаев, Д.Э. Базы данных [Текст] / Д.Э. Фуфаев, Э.В. Фуфаев. – М.: Академия, 2005. – 320 с.
ФЗ РФ от 20 февраля 1995 года № 24-ФЗ "Об информации, информатизации и защите информации". В ред. от 10.01.2003 № 15-ФЗ.
Федеральный закон «Об информации, информатизации и защите информации» /Собрание законодательства Российской Федерации 20.02.1995 г.: Официальное издание. – М.: Юридическая литература: Администрация Президента Российской Федерации, 1995. – с. 1213 – 1225.
Фаронов, В.В. «DELPHI Руководство разработки баз данных [Текст] / В.В. Фаронов, П.В. Шумаков. - М: Нолидж, 2009г., 560с.
Фаронов, В.В. Delphi. Учебный курс [Текст] / В.В. Фаронов. – М.:Москва, 2006
Фаронов, В.В. Профессиональная работа в Delphi 7.0 [Текст] / В.В. Фаронов. – М.:Москва, 2009
Хомоненко, А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений [Текст] / Под. ред. проф. А. Д. Хомоненко. — 4-е изд., перераб. и доп. — СПб.: КОРОНА принт, 2013 — 736 с.
Шаньгин, В. Ф. Защита компьютерной информации. Эффективные методы и средства [Текст] / В. Ф. Шаньгин. — М.: ДМК Пресс, 2008. — 544 с.
Шумаков, П.В. DELPHI и разработка приложений баз данных [Текст] / П.В. Шумаков. - М: Нолидж, 2008г., 704с
Щеглов А. Ю. Защита компьютерной информации от несанкционированного доступа [Текст] / А. Ю. Щеглов. — СПб.: Наука и техника, 2006. — 384 с.

ПРИЛОЖЕНИЕ А

(обязательное)

РЕЗУЛЬТАТЫ ОТЧЕТОВ