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

ВВЕДЕНИЕ

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

Необходимо спроектировать информационную систему, включающую сведения, представленные в виде набора атрибутов, которые будут определены в разделе 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 – Даталогическая модель