Структура локальной БД | MegaDOCs

Структура локальной БД

Структура локальной БД

Одной из первоочередных задач при проектировании системы для работы с точечными объектам картографии (исследовательский прототип Security Map-Point Cluster) и ее клиентской части была разработка структуры баз данных. В конечном виде структура локальной БД, размещающейся на клиентском узле, имеет следующий вид (рис. 1).

Рис. 1

Здесь таблица ReadyData используется для хранения вводимых пользователем запросов. При записи запроса в таблицу определяется индивидуальный идентификационный номер запроса (поле id_query), а также устанавливается поле ready_flag, которое определяет готовность запроса. Изначально в поле записывается ноль.

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

Назначение этих связанных таблиц:

  •  Таблица Themes привязывает к кодам тематических слоев уникальные идентификаторы.
  •  Таблица Frames хранит информацию о расположении фрагментов относительно глобальной координатной сетки тематического слоя. Атрибуты coord_x и coord_y таблицы Frames предназначены для указания расположения левого нижнего угла фрагментов относительно глобальной координатной сетки слоя.
  •  Таблица Objects хранит информацию о расположении точечных объектов относительно локальной координатной сетки фрагментов.

Все три таблицы (Themes, Frames, Objects) связаны с таблицей ReadyData ключевым полем id_query. Данное поле уникально идентифицирует каждый запрос.

Группа таблиц Theme_000… Theme_999 используется для хранения результатов в незащищенном виде после раскрытия на клиентской машине, а также для синтаксического анализа вводимых запросов. Каждая КБД для пользователя представляется именно в таком виде.

Пара таблиц db_info и semantics_object необходима для формирования результатов. Данные о картографических объектах после их раскрытия на машине пользователя записываются в файлы форматов mid/mif, которые очень удобны для последующей визуализации в ГИС MapInfo. Таблицы db_info и semantics_object содержат следующую информацию: имя КБД, код тематического слоя, шаг локальной и глобальной сетки для этого слоя, заголовок для файла *.mif  [таблица db_info], информация о каждом точечном объекте и способе его отображения [таблица semantics_object].

Кроме локальной БД программа пользователя во время работы также взаимодействует с таблицами queries и db_access БД удаленного сервера.  !!!!!!!!!!! Без рисунка, а ссылку давать некуда. Таблица db_access необходима для определения наличия прав пользователей при первичной обработке вводимых запросов. Она определяет, имеет ли конкретный пользователь доступ к конкретным слоям каждой картографической базы данных. Отсутствие соответствующей записи в таблице есть отсутствие доступа. Таблица заполняется администратором системы, пользователи имеют доступ только для селекции данных. В таблицу queries программа пользователя заносит первично обработанные запросы.  

Программа пользователя

Программа пользователя (клиентская программа) является одной из важных частей системы Security Map-Point Cluster, выполняя большую часть ее клиент-серверных функций. Данная программа располагается на каждом клиентском узле и предоставляет пользователю системы тривиальные возможности по вводу запросов и получению обработанной информации.

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

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

Связь клиентских узлов и сервера происходит с использованием ЛВС на основе технологии Ethernet. Запросы и результаты запросов передаются при помощи удаленных соединений от СУБД клиента к СУБД сервера и наоборот. Необходимо отметить, что для успешной работы программы и всего клиент-сервера пользователю необходимо иметь индивидуальные имя пользователя и пароль для доступа к серверу MySQL как на клиентской машине, так и на управляющем узле кластера. Кроме того, пользователь должен иметь верный стегоключ для работы с сокрытыми данными. Ключ в целях обеспечения безопасности предпочтительно носить на переносных устройствах хранения (флеш-накопители, оптические диски, дискеты). Стегоключ используется при маскировании конфиденциальных параметров и при формировании результирующих данных. [Ссылка на основную работу по защите картограф.данных] Вся работа клиентского приложения проходит в фоновом режиме для самого пользователя, кроме ввода запросов.

Исполнительный модуль программы реализован с использованием среды разработки Microsoft Visual Studio 2008 на языках программирования С++/C# (интерфейс программы после ее загрузки представлен на рис. 2). 

Рис. 2

Меню программы состоит из 3х пунктов:

  1.  Главная
    1.  Начало работы
    2.  Выход
  2.  Работа
    1.  Добавить запрос
    2.  Получить результат
  3.  MapInfo

Для взаимодействия исполнительного модуля с базами данных используется мощный программный интерфейс MySQL C API, а также технология MPI (библиотека MPICH) для обработки запросов путем параллельного маскирования его секретных параметров.  

Пользователь в программе может вводить только запросы селективного типа. Причем устанавливается ограничение на количество запрашиваемых тематических слоев одной картографической базы данных равное 1. Например, в качестве результатов на следующий запрос пользователь получит все точечные объекты с кодами объектов меньше 5 (code_obj<5) и с координатами больше 1000 по оси Х (coord_x > 1000), принадлежащие первому тематическому слою (theme_001) картографической базы данных kbd.

SELECT * FROM kbd.theme_001 coord_x > 1000 and code_obj<5;

Пользователю не нужно писать сложные запросы с вложенными подзапросами с учетом структуры БД, представленной таблицами Themes, Frames, Objects. Все преобразования происходят «прозрачно» для пользователя, что является важным аспектом обеспечения безопасности и надежности системы.

Запросы по изменению или удалению записей из таблиц КБД в данной версии программы недоступны для пользователей. 

Алгоритм работы программы

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

  1.  Добавление запроса.
  2.  Получение результатов.

Кроме этого есть третья ветвь - ветвь выхода из программы. Также пользователь может выбирать запуск программы визуализации ГИС MapInfo. Данная ветвь не отображена на блок-схеме.

Рис. 3

Процесс добавления запросов

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

  1.  Первое, что делает пользователь - определяет фрагмент тематического слоя (либо весь слой) какой-либо КБД, который понадобится ему для работы. Пользователь вводит свой запрос в формате MySQL в окне программы. При  этом пользователю не нужно вводить весь запрос целиком, а нужно лишь определить имя КБД и номер тематического слоя и параметры условий, если потребуется. Это упрощает работу пользователя и снижает риск появления синтаксических ошибок в запросе. Например, SELECT * FROM kbd.theme_001 WHERE coord_x>=1000.
  2.  Запрос считывается и передается на синтаксический анализ. Для этого сам запрос выполняется к одной из таблиц Theme_000… Theme_999, входящих в состав локальной БД.  Если в запросе имелись ошибки, то пользователь получит об этом уведомление и процесс обработки запроса остановится.
  3.  Если же ошибок не выявлено, то начинается процесс проверки прав доступа пользователя на выполнение данного запроса с предварительным тестированием соединения. Если соединение разорвано, то программа автоматически пытается его восстановить. При неудаче работа над запросом завершается с выдачей уведомления. Данная проверка выполняется при помощи операции селекции из таблицы db_access сервера. Таблица проверяется на наличие записи, где поле user равно имени данного пользователя, а поля db_name и code_theme совпадают с введенными в форме именем базы данных и номером слоя. Если такой записи нет, то выдается сообщение пользователю, а обработка запроса прекращается.
  4.  При наличии прав доступа на следующем этапе подготовки запрос заносится в таблицу ReadyData локальной БД. Таблица имеет несколько полей: id_query (запросу присваивается минимальное свободное десятичное число), поле-флаг ready_flag (изначально равен 0), поле query (куда непосредственно записывается сам запрос в открытом виде) и поле message. Эта таблица будет использоваться для анализа готовности данных.
  5.  Только после этих действий программа приступает к извлечению секретных параметров запроса, таких как координаты объектов, фрагментов, коды объектов. Такие параметры заменяются стегоконтейнерами модулем маскирования с использованием алгоритма маскирования Stegomask  и принципов параллельной обработки [ссылка на основную работу по защите картограф.данных].
  6.  После этого запрос добавляется в таблицу входящих запросов Queries на сервере (снова с предварительной проверкой соединения) со следующими полями:
  •  st: номер записи в таблице,
  •  user: имя пользователя.
  •  ip_address: сетевой адрес машины, с которой был получен запрос.
  •  query_id: номер запроса от данного пользователя (ID запроса).
  •  query: сам запрос с маскированными параметрами.

Если все операции прошли успешно, то пользователю выдастся сообщение. Также пользователю сообщается уникальный идентификатор запроса.

Все справочная информация о текущих состояниях, а также ошибках или окончившихся процессах выдается в текстовом окне информационного лога.

Процесс получения результатов

Проверка результатов запросов происходит следующим образом.

  1.  Чтобы получить информацию в открытом виде по какому-либо запросу, пользователь должен выбрать из перечня соответсвующий запрос, отметив его галочкой. Одновременно можно выбирать сразу несколько запросов.
  2.  После выбора запросов начинается процесс формирования результатов. Одновременно с этим сначала программа проводит проверку запросов, все еще числящихся в таблице Queries БД сервера. Выполняется запрос вида SELECT id_query FROM queries WHERE id_client=(идентификатор данного пользователя). Программа получает список запросов, находящихся в очереди на выполнение или выполняющихся. Данный список необходимо сравнить со списком запросов в таблице ReadyData и все удаленные запросы с сервера должны быть помечены флагом ready_flag=2.
  3.  На следующем шаге из локальной таблицы Readydata удаляются все запросы с флагом ready_flag=2. Это могут быть как записи, отредактированные на предыдущем шаге программой пользователя, так и записи, помеченные флагом = 2 программой сервера в ответ на неудачную обработку. Информация о каждом таком удаленном запросе выводится в окно лога программы пользователя.
  4.  Выводится информация обо всех запросах с флагом ready_flag=0. Такое состояние флага говорит о том, что запрос еще стоит на очереди сервера для обработки.
  5.  Выполняется непосредственно формирование конечных результатов по выбранным готовым запросам. Принятые от сервера данные хранятся в таблицах Themes, Frames, Objects БД клиента в сокрытом виде. Программа начинает ряд действий по формированию конечных данных:
  •  считывание информации из таблиц Themes, Frames, Objects по каждому запросу (по полю id_query);
  •  раскрытие маскированных данных;
  •  отбрасывание пустых объектов;
  •  преобразование координат в глобальную систему;
  •  формирование файлов .mid/.mif. Для этого используются соответствующие поля из локальных таблиц db_info и semantics_object.
  1.  Как только конечные файлы будут сформированы и заполнены, пользователь получит уведомление о готовности результата по каждому выбранному им запросу. Информация о запросе удаляется из таблиц ReadyData и Themes, Frames, Objects.
Импорт данных в ГИС. Файлы MID/MIF

Как уже говорилось ранее, программа пользователя преобразует результаты запросов в файлы форматов mid/mif. Данные файлы являются инструментом для хранения данных о картографических объектах и применяются во многих современных геоинформационных системах, в том числе и MapInfo.

Этот   универсальный   формат  позволяет  сопоставлять   различным графическим   элементам  настраиваемые  данные.  MIF-файл является текстовым   (ASCII),   поэтому   файлы   в   таком   формате   можно редактировать,  достаточно  легко  генерировать,  причем  они  будут работать   в   любых  системах,  где  работает  Mapinfo.  Данные  Mapinfo  хранятся  в  двух  файлах.  Графическая  информация содержится  в  файлах  с расширением .MIF, а текстовая  в  файлах  с расширением  .MID.  Каждая  строка текстовых  данных  отделяется  от следующей  строки либо символом возврата каретки, либо  возврата  каретки  вместе с новой строкой, либо только  символом  новой  строки.  [какую-нибудь ссылку?]

MIF-файл состоит  из  двух  частей: заголовка  и  секции данных.

Заголовок файла содержит  информацию  о том,  как  создавать  таблицы  Mapinfo,  а  секция  данных  содержит определения графических объектов.

Заголовок файла формата MIF

Заголовок файла формата MIF имеет следующий вид (в квадратные скобки взята информация, которая может отсутствовать).

VERSION n

[ DELIMITER "<с>" ]

[ UNIQUE n,n.. ]

[ INDEX  n, n.. ]

[ COORDSYS...]

[ TRANSFORM...]

COLUMNS n

<имя> <тип>

<имя> <тип>

DATA

…..

  •  VERSION (Версия).

После этого определителя необходимо указать число, которое указывает к какой  версии  MIF-формата относится файл: VERSION 1 или VERSION 2 и т.д. В версии Version  2 могут присутствовать предложения COORDSYS и TRANSFORM.

  •  DATA

Секция  данных  в  файлах формата MIF следует  после  заголовка  и должна начинаться со слова DATA на отдельной строке. Секция  данных  MIF-файла может содержать любое число  графических примитивов,  по  одному  для каждого графического  объекта.  Mapinfo сравнивает  разделы  файлов формата MIF и MID,  сопоставляя  первому объекту  в  MIF-файле первую строку MID-файла, второму объекту  MIF-файла вторую строку MID-файла и так далее.

Если    для   строки   MID-файла   не   найдено   соответствующего графического  объекта,  то  создается  "пустой"  объект   (NONE)   в соответствующей позиции MIF-файла.

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

Описание типов объектов.

  •  Объект  типа ТОЧКА имеет два параметра: координату Х и  координату Y. Может также быть указан вид символа, которым обозначается данная точка. Для  символа указывается номер. Если не  задан  символ,  для обозначения точки используется текущий символ.

  POINT  X У [ symbol (вид, цвет, размер)]

  •  Объект  типа  ЛИНИЯ  должен иметь четыре  обязательных  параметра; координаты  Х и Y для двух концевых точек. Может также  быть  указан тип  линии.  Если  тип линии не задан, то используется  текущий  тип линий.

LINE   х1 у1 х2 у2 [ PEN (ширина, тип, цвет) ]

  •  Для  объекта типа ЛОМАНАЯ должны быть заданы координаты Х и Y  для всех вершин ломаной. Число вершин (numpts) ломаной указывается после ключевого  слова PLINE. Может также быть указан тип линии и  наличие сглаживания. Если явно не указано, что ломаная сглажена (SMOOTH), то предполагается, что она не сглажена.

PLINE numpts x1 y1 x2 y2:

[ PEN (ширина, тип, цвет) ] [ SMOOTH ]

  •  Объект  типа  ОБЛАСТЬ  может состоять  из  одного  или  нескольких многоугольников.  Для  каждого многоугольника  должны  быть  указаны координаты Х и Y всех вершин.
  •  Для ПРЯМОУГОЛЬНИКА задаются координаты его противоположных углов. Может также быть указан тип линий и штриховки. Для скругленного прямоугольника может дополнительно указываться степень сглаживания A.

RECT х1 у1 х2 у2 [a]

[ PEN (ширина, тип, цвет) ]

[ BRUSH (шаблон, основной_цвет, цвет_фона)]

  •  Для  ЭЛЛИПСА задаются координаты противоположных углов  описанного прямоугольника.  Может также быть указан тип линий и штриховки.

ELLIPSE х1 у1 х2 у2

[ PEN (ширина, тип, цвет}]

[ BRUSH (.шаблон, основной_цвет, цвет_фона}]

Файл формата MID содержит записи, между которыми стоят разделители, заданные в предложении   Delimiter. Стандартный разделитель - символ  табуляции. Каждая  строка в MID-файле соответствует объекту в  MIF-файле: первая строка соответствует первому объекту, вторая строка – второму объекту и так далее. Если  символ-разделитель является частью записи,  то  такую запись необходимо заключить в двойные кавычки. Файл  формата  MID  может отсутствовать. В этом  случае  создаются пустые поля.

Визуализация участка карты

Для тестирования системы управления КБД Security Map-Point Cluster применялся участок реальной карты местности. Данная карта была предоставлена ООО «Зенит» для проведения испытаний экспериментального образца системы. Вид карты представлен на рис. 4 . На карте представлено множество объектов. Как точечных, так линейных и площадных.

Для работы системы из данной карты был выделен тематический слой, содержащий все точечные картографические объекты. Из множества выделенных объектов была сформирована защищенная картографическая база данных Zenit и распределена по узлам тестового вычислительного кластера. База данных содержит один тематический слой с номером 1. На слое располагается 1035 точечных объектов 4 типов.

Рис. 4

Для получения всех картографических объектов с вычислительного кластера пользователю необходимо ввести селективный запрос к базе данных Zenit. Запрос должен иметь следующий вид:

SELECT * FROM zenit.theme_1;

После выполнения операции добавления запроса и его обработки на сервере, останется сформировать результаты. В итоге операции получения результатов пользователь получит пару файлов  zenit.theme_1.mif  и  zenit.theme_1.mid. Они будут содержать необходимо-достаточную информацию обо всех точечных объектах исходной карты. Далее представлена небольшая часть содержимого результирующего файла zenit.theme_1.mif.

Version 300

Charset "WindowsCyrillic"

Delimiter ","

CoordSys NonEarth Units "m" Bounds (1100000, 200000) (1400000, 500000)

Columns 2

Код_объекта Char(8)

Наименование Char(50)

Data

Point 1293789.182 373933.2126

Symbol (33,0,14,"MapInfo Symbols",0,0)

Point 1293839.182 373933.2126

Symbol (33,0,14,"MapInfo Symbols",0,0)

Point 1293789.182 373943.2127

Symbol (33,0,14,"MapInfo Symbols",0,0)

Point 1293799.182 373943.2127

Symbol (33,0,14,"MapInfo Symbols",0,0)

Point 1293835.385 373899.3212

Symbol (33,0,14,"MapInfo Symbols",0,0)

В данном файле о каждом точечном объекте содержится информация о его типе, координатах на плоскости, способе отображения и прочее. Получив данные файлы, можно начать работать с ними в ГИС MapInfo. Для этого вызываем программу визуализации из окна программы пользователя. После выполнения ряда тривиальных действий по импорту файлов MIF/MID и открытию импортированных данных получаем окно с визуализированными объектами.

Рис. 5

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

Результаты визуализации на верном стегоключе показаны на рис. 5. На рис. 6 представлена та же карта, раскрытая на ложном стегоключе. В данном случае речь идет о том, что ключ использовавшийся при раскрытии данных, отличен от ключа, применявшегося при сокрытии.

Рис.5

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