Разработка программного обеспечения для формирования базы данных для государственной итоговой аттестации 9 классов

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ

РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО профессионального образования

ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Институт математики, естественных наук

и информационных технологий

Кафедра программного обеспечения


РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ ФОРМИРОВАНИЯ БАЗЫ ДАННЫХ ДЛЯ ГОСУДАРСТВЕННОЙ ИТОГОВОЙ АТТЕСТАЦИИ 9 КЛАССОВ


Выпускная квалификационная работа


Научный руководитель

старший преподаватель кафедры

программного обеспечения

Зайцева С.С.

Автор работы

Петренко А.А.


Тюмень - 2012г.


Введение


Государственный институт развития регионального образования Тюменской области (ТОГИРРО) - государственное образовательное учреждение дополнительного профессионального образования (повышения квалификации) специалистов. Учредитель - Департамент образования и науки Тюменской области.

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

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


Раздел I. Описание предметной области и постановка задачи


1.1Общие сведения об организации


Государственный институт развития регионального образования Тюменской области (ТОГИРРО) - государственное образовательное учреждение дополнительного профессионального образования (повышения квалификации) специалистов. Учредитель - Департамент образования и науки Тюменской области.

Цель ТОГИРРО: определение стратегии развития образовательной системы области и ее научно-методическое обеспечение на основе мониторинговых исследований.

Основные задачи института:

Информационно-аналитическая деятельность.

Проектно-прогностическая деятельность, обеспечение стратегического развития отрасли.

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

Организационно-педагогическая деятельность.

13 января 1945 года по просьбе Тюменского исполкома областного Совета депутатов трудящихся был открыт Институт усовершенствования учителей при Тюменском ОблОНО.

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

В начале 90-х годов в области насчитывалось 37 тыс. учителей, более 27 тыс. дошкольных работников. В сентябре 1991 года по решению исполкома Тюменского областного совета народных депутатов на базе областного института усовершенствования учителей открылся институт повышения квалификации педагогических кадров, получивший статус высшего учебного заведения.

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

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

В 2006 году произошло слияние ТОГИРРО и Государственного учреждения Тюменской области «Центр мониторинга качества образования Тюменской области» (ГУ ТО «ЦМКО ТО»), которое занималось проведением стандартизированных процедур оценки достижения учащихся и единого государственного экзамена (ЕГЭ). В связи с этим в структуре ТОГИРРО были созданы отделы организационного и технического обеспечения стандартизированных процедур оценки достижения учащихся (СПОДУ), которым были переданы функции «ЦМКО ТО».


1.2Отдел технического обеспечения СПОДУ


Отдел технического обеспечения СПОДУ «ТОГИРРО» выполняет следующие функции:

создание проектов на основе машиночитаемых форм;

информационно-технологическое сопровождение проведения ЕГЭ;

создание и ведение региональных баз данных образовательных учреждений;

создание и ведение баз данных участников ЕГЭ;

организация обработки данных с бланков ЕГЭ;

создание и ведение баз данных результатов ЕГЭ по субъекту Федерации;

обеспечение бесперебойного функционирования локальных вычислительных сетей отделов;

ведение деловой переписки посредством электронной почты;

обеспечение безопасности и комплексной защиты информации.

Одной из основных функций отдела является техническое сопровождение процедур проведения репетиционного тестирования в форме ЕГЭ, проведение срезовых контрольных работ (СКР) проводимых Департаментом образования и науки Тюменской области, проведение ЕГЭ.

Эти функции подразумевают выполнение следующих видов работ:

1.Проведение СКР и репетиционного тестирования:

разработка бланков;

создание машинопечатных форм для репетиционного тестирования и СКР;

сканирование и верификация бланков репетиционного тестирования и СКР;

формирование отчетов о результатах репетиционного тестирования и СКР;

формирование статистической отчетности репетиционного тестирования и СКР;

2.Проведение ЕГЭ:

формирование региональной базы участников ЕГЭ;

распределение участников ЕГЭ по пунктам проведения экзамена;

обработка бланков ЕГЭ (сканирование, верификация);

отправка результатов обработки бланков в Федеральный Центр тестирования;

получение и расшифровка результатов тестирования;

подведение итогов экзамена и формирование статистической отчетности.

Информация, поступающая в технический отдел СПОДУ:

Приказы, распоряжения и инструктивные материалы направляются из Департамента образования и Федерального центра тестирования в технический отдел СПОДУ;

Списки учащихся, учителей, учебной литературы направляются из Муниципального образовательного учреждения (МОУ СОШ) в технический отдел СПОДУ;

Схемы итоговой аттестации учащихся направляется из Муниципальных органов управления образования (МОУО) в технический отдел СПОДУ;

Результаты Единого государственного экзамена и Централизованного тестирования из Федерального Центра тестирования направляются в технический отдел СПОДУ.

Информация, выходящая из технического отдела СПОДУ:

Электронные версии бланков из технического отдела СПОДУ направляются по электронной почте в Федеральный Центр тестирования для последующей обработки и проверки;

Результаты Единого государственного экзамена и Централизованного тестирования из технического отдела СПОДУ направляются в Муниципальные органы управления образованием и в Муниципальные образовательные учреждения;

Статистическая отчетность по результатам итоговой аттестации из технического отдела СПОДУ направляется в Федеральное агентство по образованию, Департамент образования и науки Тюменской области и Муниципальные органы управления образования.

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

Схемы итоговой аттестации учащихся направляются начальнику отдела и администраторам для формирования федеральной базы данных по проведению ЕГЭ (в части организации ППЭ);

Перед проведением экзаменов административная группа по схеме проведения итоговой аттестации формирует списки учащихся, организаторов в ППЭ;

После проведения экзамена электронные версии бланков шифруются и автоматически отсылаются в Федеральный Центр тестирования для последующей обработки и проверки;

После получения результатов ЕГЭ, ЦТ из Федерального Центра тестирования административная группа подготавливает их для рассылки в МОУО и МОУ.

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


1.3Постановка задачи


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

Программное обеспечение должно включать:

Приложение для РЦОИ - «Приложение Регион». Программа предназначена для создания и сопровождения региональной базы данных учащихся 9-ых классов. Также программа должна формировать файлы базы данных для последующей передачи на нижестоящие уровни (АТЕ, ОУ). Должны быть реализованы следующие функции:

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

·для работы с данными об участниках ГИА, просмотр и редактирование информации, а также для внесения данных о годовых оценках;

·для репликации данных при передаче между приложениями разных уровней: Регион и АТЕ; Регион и ОУ; АТЕ и ОУ;

·для передачи данных в зашифрованном виде;

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

·для просмотра и редактирования информации об административно-территориальной единице;

·формирование отчетных документов в формате xlsx о выбранных экзаменах участниками по АТЕ или ОУ;

·для экспортирования и импортирования данных об административно-территориальной единице в РЦОИ;

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

·для просмотра и редактирования информации об образовательном учреждении;

·формирование отчетных документов в формате xlsx о выбранных экзаменах участниками по ОУ;

·для экспортирования и импортирования данных об образовательном учреждении в РЦОИ.


Раздел IIМатематическое обеспечение


2.1Правила разрешения конфликта версий. Общие положения.


Введем следующие обозначения состояний записей:

·nil - с записью ничего не произошло;

·ins - запись добавлена;

·upd - запись модифицирована;

·del - запись помечена на удаление.

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

Пусть имеется две БД, одну из которых обозначим DB1, вторую - DB2. Предположим, что некоторая запись была создана в DB1, а затем реплицирована в DB2. После этого предположим, что в DB1 запись была изменена, а в DB2 - удалена, при этом действие в DB2 произведено позже, чем в DB1. В этом случае общее (учитывающее все БД) состояние записи будем обозначать как

1<t2 & upd1 & del2,


где нижний индекс указывает индекс БД, в которой произошло относящееся к ней изменение состояние записи.

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

·nil - ничего не делать;

·ins - добавить запись;

·upd - обновить запись;

·del - пометить запись на удаление.

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

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


t1<t2 & upd1 & del2 del1 & nil2.


Запись следует читать следующим образом: «если изменение в DB1 произошло раньше, чем в DB2 и запись была изменена в DB1 и удалена в DB2, то необходимо ее пометить на удаление в DB1 и ничего не предпринимать в DB2». Левая часть этого выражения состоит из трех предикатов (соотношение моментов времени - это один предикат), объединенных оператором логической конъюнкции. Приведенное правило может сработать только в случае, если все три предиката в левой части выражения истинны.

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


t1 i1 t2 i2 … iN-1 tN & s1 & s2 & … & sN a1 & a2 & … & aN,


где ti, i = 1.N - момент времени, в который произошло изменение в БД i;j = {<, >, =} или (), j=1…N-1 - соотношение моментов времени tj и tj+1;i, i = 1.N - состояние записи в БД i;i, i = 1.N - действие, которое следует предпринять для разрешения конфликта версий записей в БД i.

Левая часть этой импликации состоит из N+1 предикатов, правая - ровно из N действий. Полностью процесс разрешения конфликта версий записей состоит из набора таких правил. Для того, чтобы левые части импликаций были полными по смыслу и непротиворечивыми, необходимо чтобы они содержали все возможные сочетания предикатов только один раз. В противном случае возможно возникновение ситуации, при которой либо невозможно будет разрешить конфликт версий записи (отсутствует соответствующий набор предикатов), либо этот конфликт будет разрешаться неоднозначно (сочетание предикатов встречается более одного раза). Во - первых, в наборе правил левые части должны иметься для любого случая, который может возникнуть при эксплуатации БД. Во - вторых, эти части в одном наборе не могут повторяться.

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

С точки зрения практики решение задачи видится несколько по-иному. Каково бы не было количество баз, количество вариантов этого предиката не превышает 3N-1, если использовать три вида соотношения времен (<, >, =) и 2N-1 - если использовать два вида соотношения (). Таким образом, можно закодировать все соотношения моментов времени изменения записи не более чем 3N-1 значениями, для чего использовать соответствующую функцию. Типы изменения состояний также возможно закодировать, ведь каждая запись может находиться только в одном из состояний. После осуществления этих операций требуется найти такое правило, левая часть которого будет в точности совпадать с полученными кодами.

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


2.2Схема «Звезда»


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

При рассмотрении схемы синхронизации БД типа «звезда» будем говорить об одновременной синхронизации двух и более баз данных. Например, на рис. 1 синхронизируется состояние трех БД за один сеанс репликации.


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

1.Запись может быть создана только в одной БД. Поэтому предикат ins может присутствовать в левых частях только в единственном экземпляре и сочетаться только с предикатами nil. Максимальное количество таких сочетаний равно количеству БД, состояние которых одновременно синхронизируются.

2.Остальные варианты правых частей формируются путем перебора всех вариантов сочетания предикатов nil, upd и del. Среди них будет ровно один вариант, такой что: nih1 & nih2 & . & nilN . Этот вариант следует отклонить, как не существующий.

.Для каждого сгенерированной левой части подсчитаем количество предикатов, которые зависят от времени (upd, del). Если таких предикатов более одного, то такую левую часть следует повторить 3K-1 раз, если использовать три вида соотношения времен (<, >, =) и 2K-1 - если использовать два вида соотношения (), где К - количество предикатов, зависящих от времени, сочетая их с полученными вариантами состояний.

Количество левых частей растет пропорционально степенной функции. Если для двух БД количество левых частей импликаций равно 16, то для трех БД уже 114. Случай 2-х БД есть вырожденный случай звезды.


2.3Схема «Сеть»


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


В этой структуре возможна ситуация, которая изображена на рис. 3. После того, как была выполнена синхронизация БД1 и БД3 (Р1) в БД1 добавляется новая запись (ins1). При следующей репликации Р2 эта запись переносится в БД2 (ins2). Затем, при синхронизации состояний БД2 и БД3 (Р3) запись вносится в БД3. После этого запись модифицируется в БД1 (upd1). При разрешении конфликта версий записей при репликации Р4 получается ситуация, при которой для базы БД1 запись имеет статус upd, а для БД3 - ins. Таким образом, для успешного разрешения конфликтов версии в левых частях правил следует предусмотреть ситуацию, в которой символ ins сочетается не только с символом nil, но и с символами upd и del.

Правила образования левых частей для этой схемы аналогичны правилам, применяемым для схемы звезда с учетом приведенной выше особенности.


2.4Практическая реализация


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


RTable1(PK, Data, DBID, RID, ChType, TransTime)


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

Для ChType примем следующую кодировку:

·0 - с записью ничего не произошло

·1 - запись внесена;

·2 - запись изменена;

·3 - запись помечена на удаление.- момент времени, в который произошло изменение записи. Также допустим, что база данных DB2 также содержит таблицу RTable1 идентичной схематичной структуры с теми же наименованиями атрибутов. Несложно заметить, что этот вариант схематичного представления структуры таблицы эквивалентен Table1. При этом


RK = {DBID, RID}; Ver_Stamp = {ChType, TransTime}


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

_Table(time_relation,state1,state2,action1,action2),


где time_relation имеет целочисленный тип и следующую кодировку:

·1 - t1 > t2;

·2 - t1 = t2;

·3 - t1 < t2,

где t1 и t2 - моменты изменения состояния записи соответственно в DB1 и DB2.и state2 - состояния, в которых находятся записи в соответствующих базах. Их кодировка совпадает с кодировкой ChType.и action2 - действия, которые следует предпринять для разрешения конфликта версий записей. Тип данных этих полей, а также их кодировка могут выбираться разработчиком по обстоятельствам. Заполним поля time_relation, state1 и state2 таблицы Res_Table в соответствии с правилами образования левых частей схемы «звезда», а поля action1 и action2 в соответствии с тем, как требуется разрешать конфликт версий записей в том или ином случае. Для распознавания соотношения моментов времени будем использовать следующую функцию:

CREATE FUNCTION time_moment_relation

(time1 datetime,datetime)intres as inttime1>time2res=1time1=time2res=2time1<time2 select res=3

end

RETURN res

END


Для того, чтобы обнаружить актуальные изменения в таблице требуется еще одна точка на временной шкале. Это момент завершения последней успешной репликации между этими БД. Обозначим его как SRT. С каждой записью что-то когда-то происходило, и если не установить некоторого порогового значения момента времени, то сравнивать версии придется для всех записей, находящихся в RTable1.

Используя указанное ограничение, запрос


Select

DBID,

RID,,.RTable1

(TransTime > SRT)


вернет значения RK и Ver_Stamp всех записей, которые были внесены в таблицу, либо были модифицированы, либо были помечены на удаление с момента SRT. Результат работы этого запроса обозначим через DB1_Change. Для DB2 выполним аналогичный запрос, заменяя DB1 на DB2. Результат работы этого запроса обозначим через DB2_Change.

Для того чтобы найти состояние записи во всех базах сразу следует исполнить запрос вида:


Select_moment_relation(DB1_Change.TransTime,DB2_Change.TransTime) as moment_relation(DB1_Change.ChType, 0) as St_DB1,(DB2_Change.ChType, 0) as St_DB2,_Change.DBID as DBID,_Change.RID as RID_Change full outer join DB2_Change

On ((DB1_Change.DBID = DB2_Change.DBID) and (DB1_Change.RID = DB2_Change.RID))


Результат этого запроса обозначим через General_State. Следующий запрос выдаст необходимые действия для разрешения конфликта записей:


Select_Table.action1,_Table.action2_State.DBID as DBID,_State.RID as RID

General_State inner join Res_Table on ((General_State.moment_relation = Res_Table.time_relation) and (General_State.St_DB1 = Res_Table.state1) and (General_State.St_DB2 = Res_Table.state2))


Основываясь на результатах этой выборки, следует предпринять конкретные действия по устранению конфликтов версий записей. Если разрешение конфликтов версий завершилось удачей, то вычисляется новое значение для последней успешной репликации SRT1. Далее следует выполнить запрос для DB1 вида:


Update

DB1.RTable1

Set

ChType = 0,= SRT1

(TransTime > SRT)


Для DB2 выполним аналогичный запрос, заменяя DB1 на DB2.


2.5Стандарт AES


Стандарт AES(Advanced Encryption Standard) является стандартом шифрования США, принятым в 2000-ом году. Он специфицирует алгоритм Rijndael. Этот алгоритм представляет собой симметричный блочный шифр, который работает с блоками данных длиной 128 бит и использует ключи длиной 128, 192 и 256 бит (версии AES-128; AES-192 и AES-256). Сам алгоритм может работать и с другими длинами блоков данных и ключей, но эта возможность в стандарт не вошла. При использовании 128-битного ключа для взлома шифрования по заявлению правительства США потребуется 149 триллионов лет. Биты данных нумеруются с нуля, начиная со старших. В AES основным является полиномиальное представлением кодов. Так байт {01100011} следует представлять как: x6 + x5 + x + 1. Алгоритм AES производит операции над двумерными массивами байт, называемыми структурами (state). Структура состоит из 4 рядов по Nb байт. Nb равно длине блока, деленной на 32 (в данном стандарте Nb=4). Это позволяет обозначать структуру как sr,c или s[r,c], где 0?r<4 и 0?с<4.

Входной код (in), который является последовательностью 16 байт можно представить как:

[r,c] = in[r +4c]


При реализации алгоритма AES используются операции сложения байт (по модулю 2 = XOR) и умножения. В алгоритме AES при умножении байтов используется неприводимый многочлен


m(x) = x8 + x4 + x3 + x + 1[1]


Вычисление произведения М байтов {b1} на {b2} здесь выполняется согласно следующему алгоритму


M=[{b1}?{b2}] mod m(x).[2]


В этом случае обратная величина байта равна


{b}-1 ={b} mod m(x)[3]


для умножения полубайтов (коды длиной 4 бита) используется неприводимый полином

(x) = x4 + 1


Вычисление произведения М полубайтов {a} на {b} здесь выполняется следующим образом


M=[{a}?{b}] mod m2(x).[2a]


M представляет собой полубайт d. Операцию умножения полубайтов {a} на {b} можно записать в матричном виде:


[4]


Как было сказано выше длины ключей Nk (длина, измеренная в 32 битных словах) могут принимать значения 4, 6 или 8 (для AES-128, -192 и -256, соответственно). Число итераций Nr (round), реализуемых в алгоритме AES, составляет соответственно 10, 12 и 14.

2.6Шифрование AES


При запуске алгоритма шифрования входной блок данных копируется в массив state. После первоначального добавления к state ключа массив state преобразуется с помощью функции циклической обработки Nr раз (последний цикл несколько отличается от предыдущих). Результат преобразования заносится в выходной массив. Описание алгоритма в С-подобном представлении отображено на рис. 1. Преобразования SubByte(), ShiftRows(), MixColumns() и AddRoundKey() осуществляют обработку массива state. Массив w[i] описан ниже.

(byte in[4*Nb], byte out[4*Nb], word w[Nb*(Nr+1)])state[4,Nb]= in(state, w[0, Nb-1])round = 1 step 1 to Nr-1(state)(state)(state)(state, w[round*Nb, (round+1)*Nb-1])for(state)(state)(state, w[Nr*Nb, (Nr+1)*Nb-1]) = state

end

Рис. 1. Псевдокод, реализующий процедуру шифрования


2.6.1Преобразование SubByte()

Преобразование SubByte() является нелинейной подстановкой байтов, которое работает независимо для каждого байта State и использует таблицу подстановок S. Эта замена включает в себя две операции:

1.Каждый байт заменяется на обратный мультипликативный (см. формулу 3). Байт {00} преобразуется сам в себя.

2.Для каждого байта осуществляется аффинное преобразование в поле GF(2), задаваемое формулой


[1.1]


2.6.2Преобразование ShiftRows()

В преобразованиях ShiftRows() байты в последних трех рядах State циклически сдвигаются на разное число байт. Первый ряд (r=0) не сдвигается. Преобразование ShiftRows() осуществляется следующим образом


для 0<r<4 и 0?c<Nb[1.3]


где величина сдвига shift(r,Nb) зависит от номера ряда r следующим образом:


shift(1,4)=1; shift(2,4)=2; shift(3,4)=3


2.6.3Преобразование MixColumns()

Преобразование MixColumns() обрабатывает State колонка за колонкой, каждая из колонок представляет собой 4-битный код. Колонки рассматриваются как полиномы над полем GF(28). Колонка умножается на фиксированный полином {a}={03}x3+{01}x2+{01}x+ {02} по модулю x4+1 (см. формулу 2а).


2.6.4Преобразование AddRoundKey()

В преобразовании AddRoundKey() к State добавляется ключ итерации (Round Key; побитовая операция XOR). Операция производится для каждого байта State.


2.6.5Процедура расширения ключа

Ключи итерации вычисляются на основе ключа шифрования с помощью процедуры преобразования ключа (Key expansion). Эта процедура формирует Nb(Nr+1) слов. Алгоритм требует Nb слов и каждая из Nr итераций требует Nb слов. В результате получается линейный массив 4-байтовых слов, который обозначается [wi], где i лежит в пределах 0?i<=Nk.

Функция SubWord() работает с входными байтами, преобразуя их с помощью S-таблиц. Операция выполняется для каждого из 4 входных байт.

Функция RotWord() использует в качестве входного слова [a0,a1,a2,a3] и возвращает слово [a1,a2,a3,a0].


KeyExpansion(byte key[4*Nk], word w[Nb*(Nr+1)], Nk)temp= 0(i < Nk)[i] = word(key[4*i], key[4*i+1], key[4*i+2], key[4*i+3])= i+1while= Nk(i < Nb * (Nr+1)]= w[i-1](i mod Nk = 0)= SubWord(RotWord(temp)) xor Rcon[i/Nk]if (Nk > 6 and i mod Nk = 4)= SubWord(temp)if[i] = w[i-Nk] xor temp= i + 1while

Рис. 2. Псевдокод реализации процедуры преобразования ключа


2.7Расшифрование AES


Все процедуры, описанные в предыдущем разделе, являются обратимыми. Целью дешифровки является обработка зашифрованного массива данных с целью получения исходного блока данных. Процедуры дешифровки включают в себя функции InvShiftRows(), InvSubBytes(), InvMixColumns() и AddRoundKey(). Псевдокод для процедуры дешифровки представлен на рис. 3.


InvCipher(byte in[4*Nb], byte out[4*Nb], word w[Nb*(Nr+1)])

begin

byte state[4,Nb]= in(state, w[Nr*Nb, (Nr+1)*Nb-1])round = Nr-1 step -1 downto 1(state)(state)(state, w[round*Nb, (round+1)*Nb-1])(state)

end for(state)(state)(state, w[0, Nb-1]) = state

end

Рис. 3. Псевдокод процедуры дешифровки


2.7.1Преобразование InvShiftRows()

Процедура InvShiftRows() является обратной по отношению ShiftRows(). Байты в последних трех рядах State циклически сдвигаются на разное число байт. Первый ряд (r=0) не сдвигается.


2.7.2Преобразование InvSubBytes()

Преобразование InvSubBytes() является обратной подстановкой байт, в которой S-таблица последовательно применяется для каждого из байтов State. Это достигается за счет обратного аффинного преобразования.


2.7.3Преобразование InvMixColumns()

Процедура InvMixColumns() является обратной по отношению MixColumns(). Колонки рассматриваются как полиномы над полем GF(28).


2.7.4Обратное преобразование AddRoundKey()

Преобразование AddRoundKey(), описанное в разделе 1.4 является обратимым, так как содержит только операции XOR.

2.7.5Эквивалентный код дешифровки

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


EqInvCipher(byte in[4*Nb], byte out[4*Nb], word dw[Nb*(Nr+1)])state[4,Nb]= in(state, dw[Nr*Nb, (Nr+1)*Nb-1])round = Nr-1 step -1 downto 1(state)(state)(state)(state, dw[round*Nb, (round+1)*Nb-1])for(state)(state)(state, dw[0, Nb-1])= state


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


for i = 0 step 1 to (Nr+1)*Nb-1[i] = w[i]forround = 1 step 1 to Nr-1(dw[round*Nb, (round+1)*Nb-1])

Рис. 4. Псевдокод для эквивалентного обратного преобразования


Существует новая версия AES-NI (New Instructions), которая позволяет оптимизировать работу алгоритма (понизить загрузку процессора на 50%). Эта версия может использоваться и совместно с SSL. Компания Intel разработала микросхему, реализующую этот алгоритм (серия X5600). Количество клиентов при работе с версией AES-NI может быть увеличено на 13%.


2.7.6Криптостойкость алгоритма AES

Первичная оценка криптостойкости алгоритма Rijndael была приведена авторами алгоритма в его спецификации, представленной на конкурс AES. Согласно оценкам авторов, Rijndael не подвержен следующим видам криптоаналитических атак:

·У алгоритма отсутствуют слабые ключи, а также возможности его вскрытия с помощью атак на связанных ключах.

·К алгоритму не применим дифференциальный криптоанализ.

·Алгоритм не атакуем с помощью линейного криптоанализа и усеченных дифференциалов.

·Square-атака (специфичная атака на алгоритмы со структурой «квадрат», к которым относится и AES) также не применима к алгоритму Rijndael.

·Алгоритм не вскрывается методом интерполяции.- в настоящее время самый широко распространенный алгоритм шифрования. Более 10 лет является официальным стандартом США для шифрования данных и применяется в различных сферах деятельности по всему миру. Обладает большим запасом криптостойкости.

Преимущества алгоритма:

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

·Высокая криптостойкость. Алгоритм известен около 15 лет, в течение 10 из которых он является стандартом шифрования в США. За это время, AES был хорошо исследован криптоаналитиками всего мира, и работа по поиску уязвимостей не прекращается до сих пор. На настоящий момент, не найдено серьезных уязвимостей, которые представляют практической опасности для криптостойкости алгоритма.

Недостатки алгоритма:

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

Алгоритм AES при использовании сложных ключей и корректно реализованный, обеспечивает высокий уровень безопасности информации. При использовании алгоритма с ключами длиной 128 бит, достигается достаточный уровень защиты, при котором невозможно взломать алгоритм при помощи современных технологий за разумное время. Применение 192, 256-битных ключей сейчас обеспечивает избыточную защиту, которая имеет хороших запас криптостойкости даже в случае развития в ближайшие годы технологии и науки.

база данные аттестация государственный


Раздел IIIИнструментальные средства и технологии


3.1Задание на разработку


Необходимо реализовать программное обеспечение для формирования базы данных для государственной итоговой аттестации 9 классов. Создать механизм репликации данных при передаче между регионом и АТЕ; регионом и ОУ; АТЕ и ОУ. Отправлять в зашифрованном виде данные с помощью существующих алгоритмов шифрования (AES). Предоставить функции создания отчетов в формате xlsx о выбранных экзаменах участниками по АТЕ или ОУ.


3.2Используемые технологии


3.2.1СУБД Microsoft SQL Server и Firebird

Microsoft SQL Server - система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов - Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка.

Firebird (FirebirdSQL) - компактная, кроссплатформенная, свободная система управления базами данных (СУБД), работающая на Linux, Microsoft Windows и разнообразных Unix платформах.

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

Firebird используется в различных промышленных системах (складские и хозяйственные, финансовый и государственный сектора) с 2001 г. Это коммерчески независимый проект C и C++ программистов, технических советников и разработчиков мультиплатформенных систем управления базами данных, основанный на исходном коде, выпущенном корпорацией Borland 25 июля 2000 года в виде свободной версии Interbase 6.0.


3.2.2Среда разработки Qt Creator

Qt Creator (ранее известная под кодовым названием Greenhouse) - кроссплатформенная свободная IDE для работы с фреймворком Qt, разработанная Trolltech (Nokia). Анонс проекта состоялся на Qt Developer Days в октябре 2008 года. Публичная бета-версия проекта была опубликована 30 октября 2008 года. Финальный релиз состоялся 3 марта 2009 года (вместе с выходом Qt 4.5), а исходный код доступен под лицензией LGPL.

Особенности:

·Сделана специально для разработки на Qt.

·Встроенный редактор форм (Qt Designer) и справочная система (Qt Assistant).

·Контекстно-зависимая система помощи.

·Расширяема плагинами.

·Имеется графический фронтенд для GDB.

·Поддержка отладки с помощью CDB.

·Для создания проектов используется qmake.

·Обобщённая подсветка синтаксиса, поддерживается большое количество языков программирования и разметки. Есть возможность создания своих стилей подсветки.

·Возможность редактировать этапы сборки проекта.

·Поддержка разработки на языках C/C++/QML.

·QML-дизайнер.

·Возможность разработки под Symbian и Maemo с отладкой в эмуляторе или на устройстве.


3.2.3Qt Framework

Qt - кросс-платформенный инструментарий разработки ПО на языке программирования C++. Есть также «привязки» ко многим другим языкам программирования

- PyQt, PySide; Ruby - QtRuby; Java - Qt Jambi; PHP - PHP-Qt и другие.


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

Существуют версии библиотеки для Microsoft Windows, систем класса UNIX с графической подсистемой X11, iOS, Android, Mac OS X, Microsoft Windows CE, QNX, встраиваемых Linux-систем и платформы S60. В данный момент рассматривается возможность внедрения поддержки Qt в Windows Phone.

До недавнего времени библиотека Qt также распространялась ещё в одной версии: Qt/Embedded. Теперь эта платформа переименована в Qtopia Core и распространяется как отдельный продукт. Qtopia Core обеспечивает базовую функциональность для всей линейки платформ, предназначенных для разработки приложений для встраиваемых и мобильных устройств (КПК, смартфонов и т. п.).

Начиная с версии 4.5 Qt распространяется по 3 лицензиям (независимо от лицензии, исходный код Qt один и тот же):Commercial - для разработки ПО с собственнической лицензией, допускающая модификацию самой Qt без раскрытия изменений;GPL - для разработки ПО с открытыми исходниками распространяемыми на условиях GNU GPL;LGPL - для разработки ПО с собственнической лицензией, но без внесения изменений в Qt.

Со времени своего появления в 1996 году библиотека Qt легла в основу тысяч успешных проектов во всём мире. Кроме того, Qt является фундаментом популярной рабочей среды KDE, входящей в состав многих дистрибутивов Linux.

Отличительная особенность Qt от других библиотек - использование Meta Object Compiler (MOC) - предварительной системы обработки исходного кода. MOC позволяет во много раз увеличить мощь библиотек, вводя такие понятия, как слоты и сигналы. Кроме того, это позволяет сделать код более лаконичным.позволяет создавать собственные плагины и размещать их непосредственно в панели визуального редактора. Также существует возможность расширения привычной функциональности виджетов, связанной с размещением их на экране, отображением, перерисовкой при изменении размеров окна.комплектуется визуальной средой разработки графического интерфейса «Qt Designer», позволяющей создавать диалоги и формы «мышью» (в режиме WYSIWYG). В поставке Qt есть «Qt Linguist» - графическая утилита, позволяющая упростить локализацию и перевод программы на многие языки; и «Qt Assistant» - справочная система Qt, упрощающая работу с документацией по библиотеке, а также позволяющая создавать кросс-платформенную справку для разрабатываемого на основе Qt ПО. Начиная с версии 4.5.0 в комплект Qt включена среда разработки «Qt Creator», которая включает в себя редактор кода, справку, графические средства «Qt Designer» и возможность отладки приложений. «Qt Creator» может использовать GCC или Microsoft VC++ в качестве компилятора и GDB в качестве отладчика. Для Windows версий библиотека комплектуется компилятором, заголовочными и объектными файлами MinGW.


3.2.4Qt Cryptographic Architecture (QCA)

QCA призван обеспечить обычный и кросс-платформенный Crypto API, используя типы данных и соглашения Qt. QCA разделяет API от реализации, с помощью плагинов. Преимуществом данной модели является возможность приложения избегать явных ссылок на библиотеки шифрования. Это позволяет легко менять или модернизировать крипто реализации даже без необходимости перекомпилировать приложение. QCA реализован для Windows/Unix/MacOS.


3.2.5Обзор методов репликации и синхронизации баз данных

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

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

Репликация (синхронизация) - процесс приведения данных электронных таблиц двух БД в идентичное состояние.

Репликацию можно классифицировать по-разному:

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

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

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

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

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

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


Table1(PK, Data, Ver_Stamp)


где PK - первичный ключ таблицы, простой или составной. В некоторых базах данных можно использовать такой тип данных, как UNIQUEIDENTIFIER. Data - данные, которые хранит таблица. Ver_Stamp - структура ее должна быть такова, чтобы были решены две проблемы: когда произошло событие с записью; какого рода событие произошло с записью.

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

Вторая проблема «Какого рода событие произошло с записью?» является значением некоторого перечислимого множества, и, следовательно, кодируется с помощью поля целочисленного типа, которое также обслуживает триггер. В дальнейшем обозначим его как ChType. Таким образом, можно сказать, что Ver_Stamp = {TransTime, ChType}, то есть штамп версии является объединением момента возникновения изменения и характеристики самого изменения.

Записи могут быть в следующих состояниях: с записью ничего не произошло; запись добавлена; запись модифицирована; запись помечена на удаление.


3.2.6Стандарт AES. Шифрование данных

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

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

В конце 1996 г. Национальным институтом стандартов США (NIST) был объявлен конкурс на создание нового общенационального стандарта шифрования, который должен прийти на замену DES. Разрабатываемому стандарту было присвоено рабочее наименование AES (Advanced Encryption Standard).

октября 2000 г. в качестве предлагаемого стандарта был выбран алгоритм Rijndael ("Рейндал"), который разработан Винсентом Райманом (Vincent Rijman) и Йоан Дамен (Joan Daemen) и представляет собой алгоритм, не использующий сети Фейстеля.

Алгоритм Rijndael представляет собой блочный шифр с переменной длиной блока и переменной длиной ключа. Длины блока и ключа могут быть выбраны независимо равными 128, 192 или 256 бит. Шифр является последовательностью итераций, выполняемых над некоторой промежуточной структурой, называемой состоянием.

Состояние может быть представлено в виде прямоугольного массива байтов. В массиве 4 строки, а число столбцов, обозначаемое как Nb, равно длине блока, деленной на 32. Ключ шифрования аналогичным образом представляется в виде прямоугольного байтового массива с 4 строками. Количество столбцов, обозначаемое Nk, равно длине ключа, деленной на 32. Входные и выходные значения алгоритма представляются в виде одномерных байтовых массивов соответствующей длины. Состояние и ключевой массив заполняются из этих массивов вначале по столбцам, а затем по строкам.


3.2.7Преимущества алгоритма шифрования Rijndael (AES)

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

Rijndael - это итерационный блочный симметричный шифр с архитектурой "Квадрат". Шифр имеет различную длину блоков и различные длины ключей. Длина ключа и длина блока могут быть равны: 128, 192 или 256 битам независимо друг от друга.

Преимущества алгоритма:

·Рассеивание (diffusion) - т.е. изменение любого знака открытого текста или ключа влияет на большое число знаков шифротекста, что скрывает статистические свойства открытого текста;

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

·Не подвержен многим видам криптоаналитических атак, таких как дифференциальный и линейный криптоанализ, Square-атака, метод интерполяции и др. Исследования, проведённые различными сторонами, показали высокое быстродействие Rijndael на различных платформах. Ценным свойством этого шифра является его байт-ориентированная структура, что обещает хорошие перспективы при его реализации в будущих процессорах и специальных схемах.


Раздел MMMMMMMMMMMMMMMMMMMMMMMMMMMCMXCVРаздел IVРазработка информационного обеспечения


4.1.1Схема базы

Схема базы представлена на рисунке 1:


Рисунок 1 Схема базы данных


4.1.2Описание таблиц и полей


Таблица REGION_TABLE хранит информацию о регионе

NameData typeNot nullDescriptionIDVARCHAR(36)TИдентификатор (уникальный ключ)REGIONINTEGERTНомер регионаNAMEVARCHAR(255)TНазваниеLAW_ADDRESSVARCHAR(255)TФактический адресADDRESSVARCHAR(255)TЮридический адресFIOVARCHAR(255)TФИОPHONESVARCHAR(255)TТелефонFAXVARCHAR(255)TФаксMAILSVARCHAR(255)Te-mail

Таблица ATE_TABLE содержит информацию об АТЕ (административно-территориальная единица)

NameData typeNot nullDescriptionIDVARCHAR(36)TИдентификатор (уникальный ключ)CODEINTEGERTКод АТЕNAMEVARCHAR(255)TНазваниеLAW_ADDRESSVARCHAR(255)TФактический адресADDRESSVARCHAR(255)Юридический адресCHARGE_FIOVARCHAR(150)TФИО председателяPHONESVARCHAR(80)TТелефонMAILSVARCHAR(255)e-mailWWWVARCHAR(255)Адрес сайтаISDELETEDINTEGERTПризнак удаления записи (по умолчанию 0)F_RVARCHAR(36)TРегион (внешний ключ)


Таблица GOVERNMENTS_TABLE содержит информацию об МОУО (муниципальный орган управления образованием)

NameData typeNot nullDescriptionIDVARCHAR(36)TИдентификатор (уникальный ключ)F_ATEVARCHAR(36)TАТЕ, которому принадлежит МОУО (внешний ключ)CODEINTEGERTКод МОУОNAMEVARCHAR(255)TНазваниеLAW_ADDRESSVARCHAR(255)TФактический адресADDRESSVARCHAR(255)Юридический адресCHARGE_FIOVARCHAR(150)TФИО руководителя МОУОPHONESVARCHAR(80)TТелефонMAILSVARCHAR(80)Te-mailWWWVARCHAR(255)Адрес сайтаCHARGE_POSITIONVARCHAR(150)TДолжность руководителя МОУОFAXESVARCHAR(80)TФаксSPECIALIST_FIOVARCHAR(150)TФИО специалиста ответственного за проведение ГИА в МОУОSPECIALIST_MAILSVARCHAR(80)e-mail специалиста ответственного за проведение ГИА в МОУОSPECIALIST_PHONESVARCHAR(255)TТелефон специалиста ответственного за проведение ГИА в МОУОDELETE_TYPEINTEGERTПризнак удаления записиCREATE_DATETIMESTAMPTДата создания записиUPDATE_DATETIMESTAMPTДата обновления записиIMPORT_CREATE_DATETIMESTAMPДата создания импортированияIMPORT_UPDATE_DATETIMESTAMPДата обновления импортирования


Таблица OU_TABLE содержит информацию об ОУ (образовательное учреждение)

NameData typeNot nullDescriptionIDVARCHAR(36)TИдентификатор (уникальный ключ)GOVERNMENT_IDVARCHAR(36)TМОУО, которому принадлежит ОУ (внешний ключ)CODEINTEGERTКод ОУNAMEVARCHAR(255)TНазваниеFK_SOUINTEGERTВид ОУ (внешний ключ)FK_LFINTEGERTТип собственности(внешний ключ)FK_TLINTEGERTТип населенного пункта (внешний ключ)LAW_ADDRESVARCHAR(255)TФактический адресADDRESSVARCHAR(255)Юридический адресDPOSITIONVARCHAR(150)TДолжность руководителяFIOVARCHAR(150)TФИОPHONESVARCHAR(80)TТелефонFAXSVARCHAR(80)ФаксMAILSVARCHAR(255)Te-mailCHARGEFIOVARCHAR(150)TФамилия руководителяWWWVARCHAR(255)Адрес сайтаDELETE_TYPEINTEGERTПризнак удаления записиSHORT_NAMEVARCHAR(255)TКраткое наименованиеFK_LINTEGERTГород/Район (внешний ключ)CREATE_DATETIMESTAMPTДата создания записиUPDATE_DATETIMESTAMPTДата обновления записиIMPORT_CREATE_DATETIMESTAMPДата создания импортированияIMPORT_UPDATE_DATETIMESTAMPДата обновления импортирования

Таблица CLASS_TABLE содержит информацию о классах.

NameData typeNot nullDescriptionIDVARCHAR(36)TИдентификатор (уникальный ключ)NUMBERVARCHAR(2)TКлассLITERAVARCHAR(10)Литера классаFK_OUVARCHAR(36)TОУ, которому принадлежит класс (внешний ключ)CREATE_DATETIMESTAMPTДата создания записиUPDATE_DATETIMESTAMPTДата обновления записиIMPORT_CREATE_DATETIMESTAMPДата создания импортированияIMPORT_UPDATE_DATETIMESTAMPДата обновления импортированияDELETE_TYPEINTEGERTПризнак удаления записи

Таблица STUDENT_TABLE содержит информацию об участниках ГИА

NameData typeNot ullDescriptionIDVARCHAR(36)TИдентификатор (уникальный ключ)CODEVARCHAR(16)TКод участникаSURNAMEVARCHAR(80)TФамилияNAMEVARCHAR(80)TИмяSECONDNAMEVARCHAR(80)ОтчествоDOCUMENT_SERIESVARCHAR(9)Серия документаDOCUMENT_NUMBERVARCHAR(10)Номер документаFK_DTINTEGERTТип документа (внешний ключ)SEXINTEGERTПол участникаPCLASSVARCHAR(50)TКлассBIRTH_DAYTIMESTAMPTДата рожденияDELETE_TYPEINTEGERTПризнак удаления записиFK_SCINTEGERTКатегория участника (внешний ключ)FK_OUVARCHAR(36)TОУ, которому принадлежит участник (внешний ключ)FK_FTINTEGERTФорма обучения (внешний ключ)CREATE_DATETIMESTAMPTДата создания записиUPDATE_DATETIMESTAMPTДата обновления записиIMPORT_CREATE_DATETIMESTAMPДата создания импортированияIMPORT_UPDATE_DATETIMESTAMPДата обновления импортированияFK_CLASSVARCHAR(36)TКласс, которому принадлежит участник (внешний ключ)FK_CITIZENSHIPINTEGERTГражданство (внешний ключ)

Таблица CITIZENSHIP_TABLE содержит справочную информацию о гражданстве участника

NameData typeNot nullDescriptionIDINTEGERTИдентификатор (первичный ключ)NAMEVARCHAR(20)TНазвание

Таблица DAYSEXAMS_TABLE содержит данные о днях проведения экзаменов

NameData typeNot nullDescriptionIDINTEGERTИдентификатор (первичный ключ)DATE_DAYDATETДата проведения экзаменаFK_SUBJECTINTEGERTИдентификатор (уникальный ключ)IS_FINAL_EXAMSMALLINTIS_CANCEL_EXAMSMALLINTPATH_TO_FOLDERVARCHAR(300)PATTERN_ABVARCHAR(50)PATTERN_CVARCHAR(50)

Таблица DOCUMENTSTYPE_TABLE содержит справочную информацию о типах документов

NameData typeNot nullDescriptionIDINTEGERTИдентификатор (первичный ключ)NAMEVARCHAR(255)TНазвание

Таблица FORMTRAININGTABLE содержит справочную информацию о формах обучения

NameData typeNot nullDescriptionFTIDINTEGERTИдентификатор (первичный ключ)NAMEFTVARCHAR(50)TНазвание

Таблица LEGALFORM_TABLE содержит справочную информацию о типах собственности

NameData typeNot nullDescriptionIDINTEGERTИдентификатор (первичный ключ)CODEINTEGERTКодNAMEVARCHAR(75)TНазвание


Таблица LEVEL_TABLE содержит справочную информацию об уровне доступа к БД.

NameData typeNot nullDefaultDescriptionLEVELDBINTEGERT-1Уровень доступа к БД (Регион, АТЕ, ОУ)

Таблица LOCALITY_TABLE содержит справочную информацию о местоположении ОУ (город или район)

NameData typeNot nullDescriptionLOCALITYIDINTEGERTИдентификатор (первичный ключ)REGIONINTEGERTНомер регионаNAMEVARCHAR(255)TНазваниеOCATOVARCHAR(50)OCATO

Таблица STATEOU_TABLE содержит справочную информацию о видах ОУ

NameData typeNot nullDescriptionIDINTEGERTИдентификатор (первичный ключ)FK_TOUINTEGERTТип ОУ (внешний ключ)CODEINTEGERTКодNAMEVARCHAR(150)TНазвание

Таблица STUDENTCATEGORIES_TABLE содержит справочную информацию о категориях участников.

NameData typeNot nullDescriptionIDINTEGERTИдентификатор (первичный ключ)CODEINTEGERTКодNAMEVARCHAR(255)TНазвание

Таблица STUDEXAM_TABLE содержит данные об экзаменах, которые выбрали участники

NameData typeNot nullDescriptionIDINTEGERTИдентификатор (первичный ключ)FK_DEINTEGERTДата экзамена (внешний ключ)FK_STUDENTVARCHAR(36)TУчастник (внешний ключ)MARKINTEGERОценка участникаТаблица SUBJECT_TABLE содержит справочную информацию о предметах ГИА

NameData typeNot nullDescriptionIDINTEGERTИдентификатор (первичный ключ)CODEINTEGERTКодSUBJECTVARCHAR(100)TНазвание предметаMASK_AVARCHAR(100)MAX_AINTEGERMASK_BVARCHAR(100)MAX_BINTEGERMASK_CVARCHAR(100)MAX_CINTEGERMASK_DVARCHAR(100)MAX_DINTEGERMAX_CRITERIONSMALLINTMAX_SUMSMALLINT

Таблица TYPELOCALITY_TABLE содержит справочную информацию о типах населенных пунктов

NameData typeNot nullDescriptionIDINTEGERTИдентификатор (первичный ключ)CODEINTEGERTКодNAMEVARCHAR(50)Название

Таблица TYPEOU_TABLE содержит справочную информацию о типах ОУ

NameData typeNot nullDescriptionIDINTEGERTИдентификатор (первичный ключ)CODEINTEGERTКодNAMEVARCHAR(255)TНазвание


4.2Разработка программного обеспечения


Описаны основные классы и методы в них.


4.2.1Класс «Регион» (RegionWidget)

Класс предназначен для представления и редактирования информации о регионе.


void saveChanges();//сохранение изменений

bool getChangedData()//были ли изменены данные

void setBackRequiredFields();//установка обязательных для заполнения полей

void setRegularExp();//установка условий проверки вводимых данных


4.2.2Класс «административно-территориальная единица» (AteTabWidget)

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


void setCurrentAte(QTreeWidgetItem * item, int type);//отображает текущий выбранный АТЕ

void saveChanges();//сохранение изменений

void deleteAte(QTreeWidgetItem *pItem, QTreeWidgetItem *item);//удаление АТЕ

bool getChangedData();//были ли изменены данные

void setBackRequiredFields();//установка обязательных для заполнения полей

void setRegularExp();//установка условий проверки вводимых данных

void createAte();//создание АТЕ


4.2.3Класс «образовательное учреждение» (OUtabWidget)

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


void setCurrentOu(QTreeWidgetItem * item, int type);//отображает текущий выбранный ОУ

void saveChanges();//сохранение изменений

void deleteOu(QTreeWidgetItem *pItem, QTreeWidgetItem *item);//удаление ОУ

bool getChangedData();//были ли изменены данные

void setBackRequiredFields();//установка обязательных для заполнения полей

void setRegularExp();//установка условий проверки вводимых данных

void createOu();//создание ОУ


4.2.4Редактирование класса (ClassWidget)

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


void saveChanges();//сохранение изменений

void setCurrentClass(QTreeWidgetItem * item, int type); //отображает текущий выбранный класс

void deleteClass(QTreeWidgetItem *pItem, QTreeWidgetItem *item); getChangedData();//были ли изменены данные

void setBackRequiredFields();//установка обязательных для заполнения полей

void setRegularExp();//установка условий проверки вводимых данных

void changeStudent(QModelIndex index);//при изменении текущего участника отображаются экзамены, которые им выбраны


4.2.5Класс «участник» (StudentDialog)

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


void setCurrentStudent(QTreeWidgetItem *item, int type); //отображает текущего выбранного участника

void deleteStudent(QTreeWidgetItem *pItem, QTreeWidgetItem *item); saveChanges();//сохранение изменений

bool getChangedData();//были ли изменены данные

void setBackRequiredFields();//установка обязательных для заполнения полей

void setRegularExp();//установка условий проверки вводимых данных

void updateRecord();//сохранение изменений

void cancelUpdate();//отменяет изменения в данных об участнике

void createStudent();//создание записи об участнике

void dataChangedStudent(const QModelIndex &topLeft, const QModelIndex &bottomRight); checkDateExam(int index); //проверка совпадения дат экзаменов


4.2.6Класс «создание отчетов» (createReports)

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


void setBorders(QAxObject *sheet, const QString &range);

//установка границ для диапазона ячеекsetStyle(QAxObject *sheet, const QString &range, QString text, bool isBold = false,fontSize = 10, int hAlignment = 3, int vAlignment = 2, bool wrapText = false,Orientation = 0, bool isBordered = false);

//установка стиля для диапазона ячеекcreateReportAte(const QString &idATE, const QString fileName);

//создание отчета для АТЕ и сохранение в excel файл с именем fileName

void createReportOu(const QString &idOU, const QString &fileName);

//создание отчета для ОУ и сохранение в excel файл с именем fileName

void createReportClasses(QAxObject *sheet, QSqlQueryModel *modelStudents, QSqlQueryModel *modelSubjects, const QString &idClass, const QString &nameOU, const QString &codeOU, const QString &nameClass, const QString &chargefio, const QString &dposition);

//создание отчета для класса и сохранение в excel файл с именем filename


4.2.7Класс «загрузка данных» (loadDialog)

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

void readFromXML(const QString &fileName); //чтение информации об АТЕ, ОУ, классах, участниках и выбранных экзаменах из зашифрованного файла


4.2.8Класс «выгрузка данных» (unloadDialog)

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


void searchIdRecords(QString id, int tUnit);//поиск АТЕ или ОУ по idwriteToXML(const QString &fileName, QString id); //запись данных в зашифрованный XML файл exportData();//экспортирование данных из текущей базы в зашифрованный XML файл, либо в новый файл базы данных


4.2.9Класс шифрования данных (myCrypto)

Класс, реализующий шифрование и дешифрование информации.


QString encrypt(const QString & strToEncrypt); //шифрование информации по алгоритму AES

QString decrypt(const QString & strToDecrypt); //дешифрование данных по алгоритму AES


Раздел VРуководство пользователя


Руководство пользователя по работе приложением ГИА для уровня «Регион»


5.1Системные требования


-Операционная система Microsoft® Windows® 2000/XP/Vista/7

мб оперативной памяти;

,04 МБ свободного места на жестком диске;

наличие ODBC драйвера для подключения к SQL Server.


5.2Установка


Запустите инсталлятор GIA-1.5.0.6Region.exe и выберите путь для установки приложения (рис.1).


Рисунок 2 Выбор места установки приложения


5.3Запуск приложения


В меню Пуск-Все программы-ГИА запустите программу, после подключения к локальной БД будет показано главное окно приложения (рис. 2).


Рисунок 3 Главное окно приложения


5.4Работа с программой


5.4.1Описание меню

Для уровня «Регион» доступно 3 меню: Файл, Справочные таблицы, Поиск.

В меню «Файл» доступны следующие подменю (рис. 3)


Рисунок 4 Меню Файл


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

2.«Экспорт» также позволяет сделать выгрузку данных по АТЕ или ОУ в зашифрованном файле с расширением *.xmlEnc. Экспортирование данных позволяет обмен данными между учреждениями для обновления информации по АТЕ, ОУ, классам, участникам ГИА, а также выбранным экзаменам участниками.

.«Импорт». Нужен для загрузки данных из файла с расширением *.xmlEnc и добавления/удаления/обновления данных.

.«Загрузить CSV-файлы». Загрузка в файл БД записей.

.«Загрузить таблицы из Sql Server». Подключение к базе данных SQL Server и выгрузка данных в таблицы локальной БД.

В меню «Справочные таблицы» доступные все вспомогательные таблицы БД, которые можно редактировать (добавление удаление обновление).

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


Рисунок 5 Справочные таблицы


В меню «Поиск» только один пункт, который позволяет выполнить простейшие способы поиска записей в таблицах.

На панель инструментов для удобства добавлены кнопки «Поиск», «Сохранить» и «Создание отчетов»(рис. 5).


Рисунок 6 панель инструментов


5.4.2Доступные операции при работе с ПО

Главное окно программы разделено на две части. В левой половине показана иерархия АТЕ, ОУ, классов и участников в виде дерева. В правой отображается информация по выбранному элементу дерева.

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


Рисунок 7 Запрос на сохранение изменений


Доступны функции добавления/удаления АТЕ, ОУ, класса или участника ГИА. Чтобы воспользоваться какой-либо из доступных действий, необходимо выбрать элемент в дереве и сделать клик правой кнопкой после чего будет доступно одно из нескольких видов контекстного меню (зависит от уровня выбранного элемента). Все виды доступных контекстных меню показаны на рисунке ниже


Рисунок 8 Пункты меню для разных уровней (Регион-АТЕ-ОУ-Класс Участник)


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


Рисунок 9 Назначение экзаменов участнику


Заключение


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

Основные возможности:

·Работа с данными административно-территориальных единиц, муниципальных органов управления образованием, образовательных учреждений и участников ГИА;

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

·Репликация данных при передаче между приложениями разных уровней: Регион и АТЕ; Регион и ОУ; АТЕ и ОУ;

·Передача данных в зашифрованном виде;

·Формирование отчетных документов в формате xlsx о выбранных экзаменах участниками по АТЕ или ОУ;

·Экспортирование и импортирование данных об административно-территориальной единице в РЦОИ


Список литературы


1.Trolltech. Databases with Qt.Англ., 2001г - 137 с.

2.Федеральные Стандарты Обработки Информации (FIPS). FIPS 197. Англ., 2001г - 47с.

.Хелен Борри. Firebird: Руководство разработчика баз данных. Пер. с англ, 2-е издание - М.: Издательство БХВ-Петербург, 2007 г.

.Бланшет Ж., Саммерфилд М. Qt 4: программирование GUI на C++. Пер. с англ. 2-е изд., доп. - М.: КУДИЦ-ПРЕСС, 2008 г. - 736 с.

.Рябков Н.С. Аналитический обзор методов репликации и синхронизации баз данных - Качество. Инновации. Образование: Издательство Европейский центр по качеству, 2006 г.- 56-63 с.

.Под ред. Гладченко А., Щербинина В. Репликация SQL Server 2005/2008. Сборник статей от сообщества - М.: ЭКОМ Паблншерз, 2008 г. - 288 с.

7.Форум разработчиков Qt <#"justify">Приложение


Код класса myCrypto для шифрования/дешифрования данных


myCrypto::myCrypto(QObject *parent) :(parent)

{

sizeBlock = 15;//размер блока данных

sKey = "*************************";//секретный ключ

}

//метод класса для шифрования блока данных

//в качестве результата метод возвращает зашифрованную строку

QString myCrypto::encrypt(const QString &strToEncrypt)

{

//инициализация

QCA::Initializer init;

//переводим строку в массив байт для шифрования

QCA::SecureArray arg = QVariant(strToEncrypt).toByteArray();

QString res;

// проверяем наличие поддержки алгоритма шифрования AES128

if (QCA::isSupported("aes128-cbc-pkcs7"))

{

//преобразования над ключом

//для того, чтобы затруднить взлом ключа

QStringList lst = sKey.split("-");= lst.replaceInStrings("c", "s");.removeAt(0);.removeAt(5);

//создаем ключ::SymmetricKey key(QVariant(lst.join(".")).toByteArray());

//Создаем случайный инициализирующий вектор::InitializationVector iv(QVariant(lst.join(">")).toByteArray());::Cipher cipher(QString("aes128"), QCA::Cipher::CBC, QCA::Cipher::DefaultPadding,::Encode, key, iv);::SecureArray u = cipher.update(arg);(!cipher.ok())

{(QString("строка: 43; модуль: mycrypto.cpp; Ошибка при вызове объекта cipher; ").toAscii());res;

}::SecureArray f = cipher.final();(!cipher.ok())

{(QString("строка: 50; модуль: mycrypto.cpp; Ошибка при вызове объекта cipher; ").toAscii());res;

}= QString(QCA::arrayToHex(f.toByteArray()));//QString(f.data());

} else {(QString("строка: 55; модуль: mycrypto.cpp; Ошибка при вызове объекта cipher; ").toAscii());

QMessageBox::critical(0, "", "Не поддерживается шифрование. Сообщите разработчику об этой ошибке", QMessageBox::Ok);

}res;

}myCrypto::decrypt(const QString &strToDecrypt)

{

//инициализация::Initializer init;

//переводим строку в массив байт для шифрования

QCA::SecureArray arg = QCA::hexToArray(strToDecrypt);

QString res;

// проверяем наличие поддержки алгоритма шифрования AES128

if (QCA::isSupported("aes128-cbc-pkcs7"))

{

//преобразования над ключом

//для того, чтобы затруднить взлом

QStringList lst = sKey.split("-");= lst.replaceInStrings("c", "s");.removeAt(0);.removeAt(5);

//создаем ключ::SymmetricKey key(QVariant(lst.join(".")).toByteArray());

//Создаем случайный инициализирующий вектор::InitializationVector iv(QVariant(lst.join(">")).toByteArray());::Cipher cipher(QString("aes128"), QCA::Cipher::CBC, QCA::Cipher::DefaultPadding,::Decode, key, iv);::SecureArray u = cipher.update(arg);(!cipher.ok())

{(QString("строка: 92; модуль: mycrypto.cpp; Ошибка при вызове объекта cipher; ").toAscii());res;

}::SecureArray f = cipher.final();(!cipher.ok())

{(QString("строка: 99; модуль: mycrypto.cpp; Ошибка при вызове объекта cipher; ").toAscii());res;

}= QString(f.data());

} else {(QString("строка: 104; модуль: mycrypto.cpp; Ошибка при вызове объекта cipher; ").toAscii());

QMessageBox::critical(0, "", "Не поддерживается шифрование. Сообщите разработчику об этой ошибке", QMessageBox::Ok);

}res;

}



Похожие материалы:

Развитие репродуктивной системы у детей

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

Атомистическое учение в античной философии

Тема Атомистическое учение в античной философии Романенко С. В. наук Кисельман Е.Д. Уже Эмпедокл основой вещей считал корни стихии а их сочетание или разъединение причиной возникновения или гибели вещей. Реферат

Смысл человеческого бытия. Проблема жизни, смерти и бессмертия

Введение. Смысл смерти. Проблема бессмертия Смысл должен быть найден но не может быть создан. Создать можно лишь субъективный смысл простое ощущение смысла либо бессмыслицу. Смысл не только должен но и. ХХХХХХХХХХ

Маркетинговый анализ среды и разработка маркетинговых стратегий

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

Электрооборудование и электроснабжение механической мастерской котельной № 2

Общая нагрузка освещения Мощность аварийного освещения Р ав Вт где Рсм сумма всех активных среднесменных мощностей электропри мников РП Р Вт