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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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