Разработка системы спутникового мониторинга передвижения поездов

Рис.3.4- Окно программы мобильного приложения



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

После совершения (от станции до станции) рейса машинист должен нажать на кнопку «Остановить». Для проезда на следующую станцию необходимо машинисту нажать на кнопку «Запустить» и т.д.

Рис.3.5- Метод On Status Change

Разработка инструкции программиста мобильного узла. Для отображения информациина эмуляторе 5554:AVD_11, расположены двенадцать компонентов (TextView), которые отображают GPS (данные со спутника), значение Enabledtrue или false, долгота и широта coordinates, время проезда time, дату проезда data, и скорость проезда speed, Network (мобильный интернет) его значение Enabledtrue или false, долгота и широта coordinates, время проезда time, дату проезда data, и скорость проезда speed. Так же на эмуляторе используются две копки (Button), которые включают и отключают считывание данных со спутника или мобильного интернета.

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

Button2Click - отключения приложения.

Алгоритмы программных методов «On Create», «On Resume», «On Pause», «Show Location», «Check Enabled», «On Provider Enabled», «Метод On Provider Enabled», «On Provider Enabled», «On Status Change», «Show Location», «Check Enabled» и «Sent Location» мобильного узла перечислены соответственно на рисунках 3.5, 3.6.

Метод Show Location представлен на рисунке 3.6.

Рис. 3.6- Метод Show Location

В методе On Create определяем компоненты Text View, через которые будем работать (отображение данных);

В методе On Resume на provider или Network provider;

В методе On Pause отключаем слушателя;

В методе Show Location определяем вид провайдера и отображаем координаты;

В методе Check Enabled определяем включен или выключен провайдер;

В методе On Provider Enabled отображаем информацию на экране;

В методе On Status Change ожидаем получение координат;

В методе On Click Location Settings настраиваем сеть;

В методе Sent Location отправляем данные на сервер.

Разработка алгоритма для для программного средства сервера. Алгоритм работы Web-сервера представлен на рисунке 3.7

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

На блоке 2 машинист поезда включает мобильный терминал, который определяет своё текущее местоположение с помощью GPS, по каналу GPRS передает в серверную часть приложения:

текущее местоположение (координаты);

скорость движения поезда;

время.

На блоке 3 вывод происходит преобразование географических координат в пиксельные.

На блоке 4 Отображение точек на карте в соответствии с ее координатой.

Разработка инструкции пользователя для программного средства сервера. Для запуска приложения на своем автоматизированном рабочем месте диспетчеров или технолог, должен открыть Web браузер ввести адрес страницы: http://..... После ввода адреса откроется страница, на ней необходимо ввести логин и пароль и нажатием на кнопку «Войти» перейти на основную страницу. Страница входа, представлена на рисунке 3.8



Рис. 3.7- Алгоритм работы Web-сервера

Рис. 3.8- Страница входа

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

Рис. 3.9 - Основная страница

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

Разработка инструкции программиста для программного средства сервера.

Для отображения информации на Web страницы, расположены компонентов (Text Box) поля для ввода данных.Для отображения таблицы базы данных используется компонент (GridView). Так же на Web - интерфейсе используются семь кнопок (Button), которые вставляют данные, удаляют, обновляют, отменяют ввод данных, поиск данных, и прорисовывают маршрут от точки до точки, указывают путь прохождения транспортным средством.

Button1Click - вставка данных;

Button2Click - удаление данных;

Button3Click - обновление данных;

Button4Click - отмена ввода данных;

Button5Click - поиск данных;

Button6Click - прорисовка маршрута по данным координатам;

Button7Click - указывает путь пройденный транспортным средством.

Для того чтобы отобразить карту API Яндекс Карт на Web - страницы необходимо подключить библиотеку JavaScript, которая предназначена для создания интерактивных карт.

Для подключения APIнеобходимо загрузить внешний файл, находящийся на серверах Яндекса:

<script src="http://api-maps.yandex.ru/2.0/?load=package.full&lang=ru-RU " type="text/javascript"></script>

Подключить пакеты package.controlsи package.geoObjectsбиблиотеки, необходимо использовать следующий код:

<scriptsrc="http://api-maps.yandex.ru/2.0/?lang=ru RU&load=package.controls,package.geoObjects" type="text/javascript"></script>

Загрузка стандартного набора компонентов для работы с API происходит по требованию с помощью функции load: ymaps.load(['controls']);

Отображение карты определяется HTML - объектом, в котором она размещается. Для отображения карты необходимо использовать следующийкод:

<scripttype="text/javascript">

ymaps.ready(init);

functioninit () {

varmap = newymaps.Map('WebMap', {

center: [56.327455, 36.726968],

zoom: 10

});

}

</script>

<div id="WebMap1"style="width: 400px; height: 400px; "></div>

Размещение стандартных элементов на карте: стандартный набор кнопок, кнопка изменения масштаба, список типов карт.

<script type="text/javascript">

ymaps.ready(init);

function init () {

var map = new ymaps.Map('WebMap2', {

center: [56.327455, 36.726968],

zoom: 10

});

map.controls

.add('mapTools') //стандартныекнопки

.add('zoomControl') //изменениемасштаба

.add('typeSelector'); // типыкарт

}

</script>

<div id="WebMap2" style="width: 504px; height: 300px; "></div>

Исходя из кода, добавление элементов управления используется с помощью поля controls, которое ссылается на коллекцию элементов управления картой, а для добавления элемента в коллекцию используется метод add.

3.3 Разработка базы данных для хранения данных о движении поездов

Выбор СУБД. Система управления базами данных (СУБД) -совокуп ность программных и лингвистических средств общего и специального назначения, обеспечивающий управление созданием и использованием баз данных[15].

База данных - представленная в объектной форме совокупность самостоятельных материалов, систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины[16].

Базы данных можно классифицировать по модели данных:

иерархическая;

сетевая;

реляционная;

объектно-реляционная;

объектная и объектно-ориентированная.

Иерархическая - представление базы данных в виде иерархической (древовидной структуре), состоящей из объектов данных различных уровней.

Между объектами в иерархической модели существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка к потомку, при этом не исключена ситуация, когда предок не имеет потомков[8].

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

Разница между иерархической и сетевой моделью данных состоит в том, что в иерархической модели запись потомков должна иметь только одного предка, а сетевая может иметь несколько предков[8].

Реляционная - совокупность отношений, содержащая всю информацию, которая должна храниться в базе данных. В этой модели каждый вид объектов описывается при помощи таблицы (отношения). Каждая строка таблицы соответствует одному экземпляру объектов данного вида. Строки в таблице называют кортежами (записями). Столбцы -- это атрибуты объектов. Реляционная модель состоит из ряда таблиц[10].

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

Рис. 3.10 - Классификация баз данных

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

Достоинством объектно-реляционной модели является хранение произвольного количества простых типов и других объектов. Поэтому можно организовать модель данных, как большой класс содержащий подмножество других классов[6].

Недостаток модели. Изменение схемы класса означает, что изменение должно быть сделано и в других классах приложения, которые в свою очередь взаимодействуют с экземплярами данного класса. Это ведет к необходимости перекомпиляции всей системы[6].

Объектная и объектно-ориентированная - расширяет понятие объект, включает в него не только атрибуты, но и связанные с ним действия.

Недостаток модели. Снижение производительности функционирования ПО.

Классификация баз данных представлена на рисунке 3.10

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

К СУБД поддерживающих реляционную модель относятся, MySQL, Microsoft SQL Server, Oracle.

MySQL - свободная реляционная система управления базами данных с открытым кодом разработанная компанией MySQL АВ. Данная СУБД имеет клиент -серверную архитектуру[6].

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

MySQL имеет множество программных интерфейсов, благодаря которым к БД могут подключаться приложения, созданные с помощью языков программирования: Delphi, C, C++,Java, PHP, а также обеспечивает поддержку для ODBC посредством ODBC - драйвера MyODBC[6].

MySQL работает на платформах таких как Windows XP, Windows Vista, Windows XP, Windows Vista, Windows 7, Windows server 2003, Windows server 2008 и др.[6].

Microsoft SQL Server - система управления реляционными базами данных, разработанная компанией Microsoft. Основной используемый язык запросов - Transact -SQL, создан совместно Microsoftи Sybase.Используется для работы с базами данных размером от персональных до крупных баз данных.

Microsoft SQL Server имеет множество программных интерфейсов, благодаря которым к БД могут подключаться приложения, созданные с помощью языков программирования: С, С++, Java, PHP, Perl, Visual Studio 2010 и др.

Microsoft SQL Server работает

На платформах таких как Windows XP, Windows Vista, Windows XP, Windows Vista, Windows 7, Windows server 2003, Windows server 2008, Linux и др.[4].

Oracle -объектно-реляционная система управления базами данных Oracle.

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

Oracle имеет множество программных интерфейсов, благодаря которым к БД могут подключаться приложения, созданные с помощью языков программирования: Delphi, С, С++, С#, Java, PHP, Perl, Pythonи др..

Oracle функционирует практически на всех платформах (например Unix, Windows и др.).

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

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

1. Аутентификация пользователей.

2. Ведение справочной информации о (местоположение, поезде, станции, организации, машинистах).

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

Вторая задача включает хранение информации о следующих объектах: необходимая информация о машинисте (фамилия, имя, отчество, паспортные данные, адрес и т.п.), поезд, в котором работает машинист, то есть необходимо ввести объект - поезд. За каждым машинистом закрепляется поезд, которое может оснащаться стационарным телефоном с внутренним (локальным номером), для хранения этих данных необходим объект - рабочее место.

Таким образом, в предметной области можно выделить следующие объекты:

- местоположение;

- поезд;

- машинист;

- станция;

- маршрут.

Выявленные классы объектов, присущие предметной области, их свойства, характеристики свойств необходимо представить в табличной форме. Формализованное описание предметной области представлено в таблице 3.4

В таблице 3.4 использованы сокращения: д.б. - связь обязательная; м.б. - связь необязательная; дд.мм.гггг - день месяц год; чч.мм - часы минуты.



Таблица 3.4. Формализованное описание предметной области

Класс объектов/ свойство	Физические характеристики (тип, длина)	Обязатель ность значения (м.б., д.б.)	Логические ограничения (диапазон значений, прописные, строчные буквы для символьных свойств и т.п.)	Процессы (генерация, ввод, значений, возможность обновления, просмотра)
1	2	3	4	5
Машинист
Код	Число, 11	д.б.	>0	Г
Фамилия, имя, отчество	Строка, 50	д.б.	Буквы	В, П,О
Паспортные данные	Строка, 50	д.б.	Цифры, символы	В, П,О
Адрес	Строка, 50	д.б.	цифры, символы, буквы	В, П,О
Поезд
Код	Число, 11	д.б.	>0	Г
Название	Строка, 50	д.б.	цифры, символы, буквы	В, П,с О
Местоположение
Код	Число, 11	д.б.	>0	Г
Время	Время	д.б	цифры, символы	В, П,О
Скорость	Строка, 20	д.б.	цифры, символы, буквы	В, П,О
Координаты	Строка, 50	д.б.	цифры, символы	В, П,О
Дата	Дата	д.б	цифры, символы, буквы	В, П,О
Станция
Код	Число, 11	д.б.	>0	Г
Название	Строка, 50	д.б.	цифры, символы, буквы	В, П,О
Маршрут
Код	Число, 11	д.б.	>0	Г
Время	Время	д.б	цифры, символы	В, П,О
Скорость	Строка, 20	д.б.	цифры, символы, буквы	В, П,О
Координаты	Строка, 50	д.б.	цифры, символы	В, П,О
Дата	Дата	д.б	цифры, символы, буквы	В, П,О

Связи между классами объектов, присущие заданной предметной области, с отображением связей между ними представлены в таблице 3.4.

В таблице 3.5 использованы сокращения: 1 - мощность связи «один», М - мощность связи «много», д.б. - связь обязательная, м.б. - связь необязательная.

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

Таблица 3.5. Связи между классами объектов

Связь классов объектов	Наименование связи со стороны классов объектов	Тип связи со стороны класса объекта	Опциональность связи класса объекта
Глав.	Подч.	Глав.	Подч.	Глав.	Подч.	Глав.	Подч.
1	2	3	4	5	6	7	8
Местополо-жение	Поезд	Соответствует	Имеет место	1	1	д.б.	м.б.
Местополо-жение	Станция	Соответствует	Имеет место	M	1	д.б.	м.б.
Поезд	Машинист	Прикреплён	Соответствует	1	1	д.б.	д.б.
Поезд	Маршрут	Прикреплён	Соответствует	1	1	д.б.	д.б.

В результате формализованного описания предметной области, определения всех функций для каждой задачи подсистемы была построена ER-модель в нотации Ричарда Баркера (рисунок 3.11)

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

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



Рис. 3.11- ER-модель

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

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

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

Наиболее распространенной моделью данных, используемой в современных СУБД, является реляционная модель. Каждая реализация имеет свои особенности, свою собственную интерпретацию данной модели. Однако общие правила реляционной модели поддерживаются всеми СУБД.

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

1) правила перевода в схемы отношений сущностей и атрибутов;

2) правила перевода связей между сущностями в схемы отношений.

Рассмотрим последовательно эти правила.

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

Первая группа правил, правило второе. Уникальный идентификатор сущности становится первичным ключом соответствующего отношения.

Таким образом, получаем следующие схемы отношений:

Poezd (id_P, Nazvaniye)

Stancia (id_S, Nazvaniye)

Mashinist (id_M, Familiya, Ima, Otchestvo, Pasport, Adres)

Mestopologenie (id_Mest, Koordinata, Ckorost, Vremia, Data)

Marshryt (id_Mest, Koordinata, Ckorost, Vremia, Data)

Поскольку реляционная модель способна поддерживать связи только 1:1, 1:М (М:1) и не поддерживает тип М:М, то существует два правила перевода связей между сущностями.

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

В соответствии с таблицей 3.6 реализуем связи между объектами предметной области по правилам II.1 и II.2:

Для реализации связи M:1 в отношение «Станция» (Stancia) необходимо добавить внешний ключ (копию первичного ключа отношения «Местоположение» (Mestopologenie):

Mestopologenie (id_Mest, Koordinata, Vremia, Skorost, Data, fid_S)

Для реализации связи M:1 в отношение «Организация» (Organizacia) необходимо добавить внешний ключ (копию первичного ключа отношения «Местоположение» (Mestopologenie):

Mestopologenie (id_Mest, Koordinata, Vremia, Skorost, Data, fid_О)

Для реализации связи 1:1 в отношение «Поезд» (Poezd) необходимо добавить внешний ключ (копию первичного ключа «Местоположение» Mestopologenie):

Mestopologenie (id_Mes,tKoordinata, Vremia, Skorost, Data, fid_P)

Для реализации связи 1:1 в отношение «Поезд» (Poezd) необходимо добавить внешний ключ (копию первичного ключа «Машинист» (Mashinist)):

Poezd (id_P, Nazvanie, fid_M)

Для реализации связи 1:1 в отношение «Поезд» (Poezd) необходимо добавить внешний ключ (копию первичного ключа «Маршрут» (Marshryt)):

Poezd (id_P, Nazvanie, fid_Mar)

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

В настоящее время приемлемым считается нормализовать отношения до 3 НФ, включая её усиленную форму - НФ Бойса-Кодда.

Для приведения отношений к 1 НФ необходимо, чтобы все атрибуты были простыми. В отношении машинист есть атрибут паспорт, который состоит из серии (4 цифры) и номера (6 цифр), таким образом можно вести соответствующие атрибуты:

Mashinist (id_M, Familiya, Ima, Otchestvo, Pasport_seria, Pasport_nomer, Kem_vidan, data_vidachi, Adres, fid_P).

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

Рис. 3.12- Графическое представление схемы реляционной БД

Для приведения к 3НФ необходимо, чтобы в отношениях не было транзитивных зависимостей. Все приведенные отношения соответствуют 3НФ.

Таким образом в рассматриваемой предметной области в даталогической модели данных можно выделить следующие отношения:

Poezd (id_P, Nazvaniye,f id_M)

Mashinist (id_M, Familiya, Ima, Otchestvo, Pasport_seria, Pasport_nomer, Kem_vidan, data_vidachi, Adres).

Stancia (id_S, Nazvaniye)

Mestopologenie (id_Mes,tKoordinata, Vremia, Skorost, Data, fid_P, fid_S, fid_O,)

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

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

- имя отношения (таблицы);

- имена атрибутов (полей);

- определение первичных ключей;

- определение уникальных (потенциальных) ключей;

- определение физических характеристик атрибута (тип и длину);

- определение обязательности значения атрибута;

- определение логических ограничений на значение атрибута.

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

Техническое описание реляционной таблицы «Поезд» на языке определения данных представлено в таблице 3.6.

Таблица 3.6. Реляционная таблица «Poezd»

Имя поля	Ключ	Тип и длина	Опциональность	Логическое ограничение
id_P	Primarykey	int	notnull	check(value>0)
Nazvaniye		char 30	not null
fid_M	Foreign key	int	not null

Техническое описание реляционной таблицы «Станция» на языке определения данных представлено в таблице 3.7.

Таблица 3.7. Реляционная таблица «Stancia»

Имя поля	Ключ	Тип и длина	Опциональность	Логическое ограничение
id_S	Primary key	int	not null	check(value>0)
Nazvaniye		char 30	not null

Техническое описание реляционной таблицы «Машинист» на языке определения данных представлено в таблице 3.8.

Таблица 3.8. Реляционная таблица «Mashinist»

Имя поля	Ключ	Тип и длина	Опциональность	Логическое ограничение
id_M	Primarykey	int	notnull	check(value>0)
Familiya		char 30	not null
Ima		char 30	not null
Otshestvo		char 30	not null
Pasport_seria		int (4)	not null
Pasport_nomer		int (6)	not null
Data_vidachi		DATETIME	not null
Kem_vidan		char 100	not null
Adres		char 300	not null

Техническое описание реляционной таблицы «Местоположение» на языке определения данных представлено в таблице 3.9.

Таблица 3.9. Реляционная таблица «Mestopologenie»

Имя поля	Ключ	Тип и длина	Опциональность	Логическое ограничение
1	2	3	4	5
id_Mest	Primary key	int	not null	check(value>0)
Koordinata		char 30	not null
Vremia		DATETIME	not null
Skorost		real	not null
Pasport_seria		int (4)	not null
Pasport_nomer		int (6)	not null
Data_otpravki		DATETIME	not null
Data_pribitia		DATETIME	not null
fid_S	Foreign key	int	not null	check(value>0)
fid_P	Foreign key	int	not null	check(value>0)
fid_O	Foreign key	int	not null	check(value>0)

При построении таблиц использовались следующие конструкции языка SQL:

- primary key - первичный ключ;

- foreign key, FK - внешний ключ;

- not null - запрет на пустое поле;

-check -условие ограничения.

Разграничение прав доступа. Согласно проведённому в первой главе анализу системы мониторинга передвижения поездов на предприятии ОАО «РЖД «Челябинского ИВЦ»» выделяют следующих пользователей:

- с правами оператора (диспетчер);

- с правами оператора (технолог);

- с правами администратора безопасности.

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

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

Пользователь с правами администратора безопасности, имеет доступ на:

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

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

- осуществлять откат базы данных к ранее созданному образу, сохранённому на момент установления подлинности БД.

При этом данный пользователь имеет доступ на чтение:

- персональных данных машинистов предприятия;

- поездов;

- станций;

- местоположений.

Таблица 3.10. Уровни доступа

Субъекты доступа (пользователи)	Метки субъектов доступа	Операторы
		RID	INSERT	UPDATE	DELETE
Администратор безопасности	3	+	+	+	+
Диспетчер	2	+	-	-	-
Технолог	1	+	+	+	-

Таблица 3.11. Объекты доступа

Объекты доступа

Субъекты доступа

Администратор безопасности

Оператор персональных данных сотрудников (технолог)

Оператор персональных данных сотрудников (диспетчер)

Метка субъекта

RID

INSERT

UPDATE

DELETE

RID

INSERT

UPDATE

DELETE

RID

INSERT

UPDATE

DELETE

1

2

3

4

Машинист Код Фамилия Имя Отчество Паспорт - серия Паспорт - номер Дата выдачи Кем выдан Адрес

+

+

+

+

+

+

+

-

+

-

-

-

Станция Код Название

+

+

+

+

+

+

+

-

+

-

-

-

Местоположение Код Координата Скорость Дата отправки Дата прибытия Время

+

+

+

+

+

-

-

-

+

-

-

-

Поезд Код Название

+

+

+

+

+

+

+

-

+

-

-

-

В предметной области выделен ряд пользователей, наделённых правами:

- администратор безопасности базы данных - является специалистом в области информационных технологий, его работа заключается в установке и настройке среды БД, создания БД и её администрирование;

- конечный пользователь 1 - диспетчер;

- конечный пользователь 2 - технолог.

Для реализации управления доступом введём следующие уровни (таблица 3.10) и установим их на объекты БД (таблица 3.11).

Создать пользователя с произвольными уровнями может только администратор системы. Остальные администраторы (DBA) могут создавать пользователей (или изменять уровень пользователям) лишь в пределах отведенных им уровней. Пользователь может принудительно пометить вводимые данные, указав в списке атрибутов уровни доступа для соответствующих записей и полей (при выполнении операторов INSERT или UPDATE). По умолчанию вносимые данные наследуют уровни пользователя, вносящего или изменяющего данные. Защищаемые объекты: пользователи, таблицы, столбцы, записи (вносится при выполнении INSERT), поля записей (изменяются при выполнении UPDATE). Уровни, как и группы, нельзя использовать в случае, если они не созданы специальными запросами.



Заключение

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

В первой главе работы были выполнены следующие задачи.

1 Проведён анализ базовой системы мониторинга передвижения поездов. Приведена существующая структурная схема мониторинга передвижения поездов РЖД.

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

Во второй главе работы были выполнены следующие задачи.

1 построена модель источников внештатного движения поезда. Проведен выбор и обоснование канала передачи данных для системы спутникового мониторинга.

2 разработан алгоритм работы автоматизированной системы.

В третьей главе работы были выполнены следующие задачи.

1 определены категории субъектов (пользователей базы данных) и их уровни полномочий к объектам базы данных.

2 выбраны технические средства, для реализации системы.

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

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



Список использованных источников

1. Delphi [Электронный ресурс] : сайт / разраб. «Copyright»,2003 - 2009. - Режим доступа http://hask.com/, свободный. - Загл. с экрана.

2. Eclipse 4.3.1[Электронный ресурс] : сайт / разраб. «freeSoft», 1998 - 2014. - Режим доступа http://freesoft.net/, свободный. - Загл. с экрана.

3. GPRS [Электронный ресурс] : сайт / разраб. «GPRS -GSM»,2003 - 2014. - Режим доступа http://gprs -gsm.ru/, свободный. - Загл. с экрана.

4. Microsoft SQL Server [Электронный ресурс] : сайт / разраб. «Microsoft», 2014. - Режим доступаhttp://microsoft.com /, свободный. - Загл. с экрана.

5. Oracle [Электронный ресурс] : сайт / разраб. «Mkadr», 2007 - 2012. - Режим доступа http://mkadr.ru/, свободный. - Загл. с экрана.

6. Visual Studio [Электронный ресурс] : сайт / разраб. «Microsoft»,2014. - Режим доступа http://microsoft.com/, свободный. - Загл. с экрана.

7. Авария в Испании 25.07.13г [Электронный ресурс] : сайт / разраб. «Copyright», 2005 - 2013. - Режим доступа: http://dk.ru/, свободный. - Загл. с экрана.

8. Иерархическая модель [Электронный ресурс] : сайт / разраб. «Xreferat», 2014. - Режим доступаhttp://xreferat.ru /, свободный. - Загл. с экрана.

9. По назначению [Электронный ресурс] : сайт / разраб. «Copyright»,2005 - 2014. - Режим доступа http://uroki.net/, свободный. - Загл. с экрана.

10. По способу исполнения программ [Электронный ресурс] : сайт / разраб. «Allbest», 2000 - 2013. - Режим доступа http://allbastr.ru/, свободный. - Загл. с экрана.

11. По степени переносимости [Электронный ресурс] : сайт / разраб. «Academc», 2000 - 2013. - Режим доступа http://academic.ru/, свободный. - Загл. с экрана.

12. Принцип работы GPS [Электронный ресурс] : сайт / разраб. «Radiopole», 2006 - 2013. - Режим доступа: http://radiopole.ru /, свободный. - Загл. с экрана.

13. Принцип работы GPS [Электронный ресурс] : сайт / разраб. «Radiopole», 2006 - 2013. - Режим доступа: http://radiopole.ru /, свободный. - Загл. с экрана.

14. Принцип работы Гид Урал Вижжит [Электронный ресурс] : сайт / разраб. «Copyright», 2006 -2007. - Режим доступа: http:// http://scbist.com/, свободный. - Загл. с экрана.

15. Принцип работы сотовой связи [Электронный ресурс] : сайт / разраб. «TechnoPlus»,2000 - 2014. - Режим доступа: http://technoplus.ru /, свободный. - Загл. с экрана.

16. Радиодоступ [Электронный ресурс] : сайт / разраб. «Finestreet»,2011 - 2014. - Режим доступа http://orskportal.ru/, свободный. - Загл. с экрана.

17. Реляционная модель [Электронный ресурс] : сайт / разраб. «Albest», 2003 - 2014. - Режим доступа http://allbest.ru/, свободный. - Загл. с экрана.

18. Сетевая модель [Электронный ресурс] : сайт / разраб. «Allbest»,2003 - 2014. - Режим доступа http://allbest.ru/, свободный. - Загл. с экрана.

19. Сотовый телефон [Электронный ресурс] : сайт / разраб. «Copyright»,1999 - 2014. - Режим доступа http://ixbt.com/, свободный. - Загл. с экрана.

20. Спутниковый интернет [Электронный ресурс] : сайт / разраб. «Altegro Sky», 2009 - 2014. - Режим доступа http://altegrosky.ru/, свободный. - Загл. с экрана.

21. Территориальные признаки спутникового мониторинга [Электронный ресурс] : сайт / разраб. «Monsta», 2013. - Режим доступа: http://nav-store.ru/, свободный. - Загл. с экрана.

22. Челябинский ИВЦ//сайт предприятия «ОАО «РЖД» [Электронный ресурс] : / разраб. «Runetmedia». - Челябинск,2007 - 2014. - Режим доступа: http://bpages.ru/, свободный. - Загл. с экрана.

Размещено на Allbest.ru