Пример дипломной работы по менеджменту: Формирование базы данных по проектам компании

Содержание

Содержание

Введение4

Раздел 1. Теоретические основы формирования баз данных проектов компаний…10

1.1.Причины возникновения и этапы формирования баз данных проектов компаний…10

1.2.Основные принципы и критерии формирования баз данных компании…27

1.3.Уровень изученности формирования баз данных проектов компании на основе зарубежной и отечественной литературы36

1.4.Выводы по разделу 148

Раздел 2. Практическое исследование формирования баз данных проектов компании на примере группы компаний «Астром»..51

2.1. Анализ и оценка формирования баз данных проектов в компаниях группы компаний «Астром»..51

2.2. Разработка и обоснование формирования баз данных проектов компаний и необходимость управления этим процессом.56

2.3. Решение задачи проведения автоматизации формирования баз данных и их внедрения как общую базу данных проектов группы компаний «Астром»..68

2.4. Выводы по разделу 272

Заключение.74

Список использованной литературы.77

Введение

Когда речь идет о маркетинге важно знать несколько правил:

1. Невозможно управлять тем, что не знаешь.

2. Невозможно улучшить то, что не можешь измерить или просчитать .

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

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

Таким образом, при создании таких баз данных проекторов компании всегда существует и ряд преимуществ и недостатков такого внедрения. Преимуществами следует отметить такие явления:

1.Возможность автоматизированного подхода к управлению решениями по проектам компании;

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

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

4.Способность автоматизированного управления проектом на любом его уровне создания, внесения корректив и доработок .

Недостатками таких маркетинговых баз данных можно назвать только два:

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

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

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

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

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

Предметом дипломной работы являются теоретические и практические исследования в данной области маркетинга с использованием для примера группы компаний «Астром».

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

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

1.проследить основные этапы развития маркетинга баз данных, как в мире, так и в России непосредственно;

2.выяснить степень влияния использования маркетинга баз данных на эффективность той или иной компании, в общем, и на конкретный проект, непосредственно;

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

4.проанализировать собранные теоретические и практические данные;

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

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

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

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

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

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

Кроме того, высветляются также вопросы специфики формирования баз данных проектов компании и приводятся аргументы «за» и «против» такого нововведения в компаниях. Приводятся примеры применения маркетинга баз данных и результаты работы компании после внедрения. Также рассматриваются и основные принципы, этапы формирования баз данных проектов компании, указываются основные аспекты, на которые стоит обратить внимание и использовать с максимальными возможностями.

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

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

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

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

Выдержка из текста работы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

t₁<t₂ & upd₁ & del₂,

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

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

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

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

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

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

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

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

t₁<t₂ & upd₁ & del₂  del₁ & nil₂.

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

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

t₁ i₁ t₂ i₂ … i_N-1 t_N & s₁ & s₂ & … & s_N  a₁ & a₂ & … & a_N,

где t_i, i = 1…N — момент времени, в который произошло изменение в БД i;

i_j = {<, >, =} или (), j=1…N-1 — соотношение моментов времени t_j и t_j+1;

s_i, i = 1…N — состояние записи в БД i;

a_i, i = 1…N — действие, которое следует предпринять для разрешения конфликта версий записей в БД i.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этой структуре возможна ситуация, которая изображена на рис. 3. После того, как была выполнена синхронизация БД₁ и БД₃ (Р₁) в БД₁ добавляется новая запись (ins₁). При следующей репликации Р₂ эта запись переносится в БД₂ (ins₂). Затем, при синхронизации состояний БД₂ и БД₃ (Р₃) запись вносится в БД₃. После этого запись модифицируется в БД₁ (upd₁). При разрешении конфликта версий записей при репликации Р₄ получается ситуация, при которой для базы БД₁ запись имеет статус upd, а для БД₃ — ins. Таким образом, для успешного разрешения конфликтов версии в левых частях правил следует предусмотреть ситуацию, в которой символ ins сочетается не только с символом nil, но и с символами upd и del.

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

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

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

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

где PK — первичный ключ;

Data — данные хранимые таблицей;

DBID — идентификатор БД, в которой была создана запись;

RID — идентификатор записи для репликации, который был присвоен при создании записи;

ChType — код типа изменения, произошедшего с записью, целочисленный тип данных;

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

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

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

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

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

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

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

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

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

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

· 1 — t₁ > t₂;

· 2 — t₁ = t₂;

· 3 — t₁ < t₂,

где t₁ и t₂ — моменты изменения состояния записи соответственно в DB₁ и DB₂.

state1 и state2 — состояния, в которых находятся записи в соответствующих базах. Их кодировка совпадает с кодировкой ChType.

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

CREATE FUNCTION time_moment_relation

(time1 datetime,

time2 datetime)

RETURNS int

BEGIN

declare res as int

if time1>time2

begin

select res=1

else

begin

if time1=time2

begin

select res=2

else

begin

if time1<time2 select res=3

RETURN res

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

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

Select

DBID,

RID,

ChType,

TransTime

From

DB1.RTable1

Where

(TransTime > SRT)

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

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

Select

time_moment_relation(DB1_Change.TransTime,DB2_Change.TransTime) as moment_relation

ISNULL(DB1_Change.ChType, 0) as St_DB1,

ISNULL(DB2_Change.ChType, 0) as St_DB2,

DB1_Change.DBID as DBID,

DB2_Change.RID as RID

From

DB1_Change full outer join DB2_Change

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

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

Select

Res_Table.action1,

Res_Table.action2

General_State.DBID as DBID,

General_State.RID as RID

From

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

ChType = 0,

TransTime = SRT1

Where

(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} следует представлять как: x⁶ + x⁵ + x + 1. Алгоритм AES производит операции над двумерными массивами байт, называемыми структурами (state). Структура состоит из 4 рядов по Nb байт. Nb равно длине блока, деленной на 32 (в данном стандарте Nb=4). Это позволяет обозначать структуру как sr,c или s[r,c], где 0?r<4 и 0?с<4.

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

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

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

m(x) = x⁸ + x⁴ + x³ + x + 1 [1]

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

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

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

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

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

m2(x) = x⁴ + 1

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

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

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

Как было сказано выше длины ключей 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] описан ниже.

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

Begin

byte state[4,Nb]

state = in

AddRoundKey(state, w[0, Nb-1])

for round = 1 step 1 to Nr-1

SubBytes(state)

ShiftRows(state)

MixColumns(state)

AddRoundKey(state, w[round*Nb, (round+1)*Nb-1])

end for

SubBytes(state)

ShiftRows(state)

AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1])

out = state

Рис. 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(2⁸). Колонка умножается на фиксированный полином {a}={03}x³+{01}x²+{01}x+ {02} по модулю x⁴+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)

Begin

word temp

i = 0

while (i < Nk)

w[i] = word(key[4*i], key[4*i+1], key[4*i+2], key[4*i+3])

i = i+1

end while

i = Nk

while (i < Nb * (Nr+1)]

temp = w[i-1]

if (i mod Nk = 0)

temp = SubWord(RotWord(temp)) xor Rcon[i/Nk]

else if (Nk > 6 and i mod Nk = 4)

temp = SubWord(temp)

end if

w[i] = w[i-Nk] xor temp

i = i + 1

end while

Рис. 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]

state = in

AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1])

for round = Nr-1 step -1 downto 1

InvShiftRows(state)

InvSubBytes(state)

AddRoundKey(state, w[round*Nb, (round+1)*Nb-1])

InvMixColumns(state)

end for

InvShiftRows(state)

InvSubBytes(state)

AddRoundKey(state, w[0, Nb-1])

out = state

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

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

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

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

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

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

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

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)])

Begin

byte state[4,Nb]

state = in

AddRoundKey(state, dw[Nr*Nb, (Nr+1)*Nb-1])

for round = Nr-1 step -1 downto 1

InvSubBytes(state)

InvShiftRows(state)

InvMixColumns(state)

AddRoundKey(state, dw[round*Nb, (round+1)*Nb-1])

end for

InvSubBytes(state)

InvShiftRows(state)

AddRoundKey(state, dw[0, Nb-1])

out = state

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

for i = 0 step 1 to (Nr+1)*Nb-1

dw[i] = w[i]

end for

for round = 1 step 1 to Nr-1

InvMixColumns(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.

· Алгоритм не вскрывается методом интерполяции.

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

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

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

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

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

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

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

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

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.3 Qt Framework

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

Python — 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 один и тот же):

Qt Commercial — для разработки ПО с собственнической лицензией, допускающая модификацию самой Qt без раскрытия изменений;

GNU GPL — для разработки ПО с открытыми исходниками распространяемыми на условиях GNU GPL;

GNU LGPL — для разработки ПО с собственнической лицензией, но без внесения изменений в Qt.

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

Отличительная особенность Qt от других библиотек — использование Meta Object Compiler (MOC) — предварительной системы обработки исходного кода. MOC позволяет во много раз увеличить мощь библиотек, вводя такие понятия, как слоты и сигналы. Кроме того, это позволяет сделать код более лаконичным.

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

Qt комплектуется визуальной средой разработки графического интерфейса «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.4 Qt 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).

2 октября 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 на различных платформах. Ценным свойством этого шифра является его байт-ориентированная структура, что обещает хорошие перспективы при его реализации в будущих процессорах и специальных схемах.

4.1.1 Схема базы

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

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

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

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

Name	Data type	Not null	Description
ID	VARCHAR(36)	T	Идентификатор (уникальный ключ)
REGION	INTEGER	T	Номер региона
NAME	VARCHAR(255)	T	Название
LAW_ADDRESS	VARCHAR(255)	T	Фактический адрес
ADDRESS	VARCHAR(255)	T	Юридический адрес
FIO	VARCHAR(255)	T	ФИО
PHONES	VARCHAR(255)	T	Телефон
FAX	VARCHAR(255)	T	Факс
MAILS	VARCHAR(255)	T	e-mail

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

Name	Data type	Not null	Description
ID	VARCHAR(36)	T	Идентификатор (уникальный ключ)
CODE	INTEGER	T	Код АТЕ
NAME	VARCHAR(255)	T	Название
LAW_ADDRESS	VARCHAR(255)	T	Фактический адрес
ADDRESS	VARCHAR(255)		Юридический адрес
CHARGE_FIO	VARCHAR(150)	T	ФИО председателя
PHONES	VARCHAR(80)	T	Телефон
MAILS	VARCHAR(255)		e-mail
WWW	VARCHAR(255)		Адрес сайта
ISDELETED	INTEGER	T	Признак удаления записи (по умолчанию 0)
F_R	VARCHAR(36)	T	Регион (внешний ключ)

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

Name	Data type	Not null	Description
ID	VARCHAR(36)	T	Идентификатор (уникальный ключ)
F_ATE	VARCHAR(36)	T	АТЕ, которому принадлежит МОУО (внешний ключ)
CODE	INTEGER	T	Код МОУО
NAME	VARCHAR(255)	T	Название
LAW_ADDRESS	VARCHAR(255)	T	Фактический адрес
ADDRESS	VARCHAR(255)		Юридический адрес
CHARGE_FIO	VARCHAR(150)	T	ФИО руководителя МОУО
PHONES	VARCHAR(80)	T	Телефон
MAILS	VARCHAR(80)	T	e-mail
WWW	VARCHAR(255)		Адрес сайта
CHARGE_POSITION	VARCHAR(150)	T	Должность руководителя МОУО
FAXES	VARCHAR(80)	T	Факс
SPECIALIST_FIO	VARCHAR(150)	T	ФИО специалиста ответственного за проведение ГИА в МОУО
SPECIALIST_MAILS	VARCHAR(80)		e-mail специалиста ответственного за проведение ГИА в МОУО
SPECIALIST_PHONES	VARCHAR(255)	T	Телефон специалиста ответственного за проведение ГИА в МОУО
DELETE_TYPE	INTEGER	T	Признак удаления записи
CREATE_DATE	TIMESTAMP	T	Дата создания записи
UPDATE_DATE	TIMESTAMP	T	Дата обновления записи
IMPORT_CREATE_DATE	TIMESTAMP		Дата создания импортирования
IMPORT_UPDATE_DATE	TIMESTAMP		Дата обновления импортирования

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

Name	Data type	Not null	Description
ID	VARCHAR(36)	T	Идентификатор (уникальный ключ)
GOVERNMENT_ID	VARCHAR(36)	T	МОУО, которому принадлежит ОУ (внешний ключ)
CODE	INTEGER	T	Код ОУ
NAME	VARCHAR(255)	T	Название
FK_SOU	INTEGER	T	Вид ОУ (внешний ключ)
FK_LF	INTEGER	T	Тип собственности(внешний ключ)
FK_TL	INTEGER	T	Тип населенного пункта (внешний ключ)
LAW_ADDRES	VARCHAR(255)	T	Фактический адрес
ADDRESS	VARCHAR(255)		Юридический адрес
DPOSITION	VARCHAR(150)	T	Должность руководителя
FIO	VARCHAR(150)	T	ФИО
PHONES	VARCHAR(80)	T	Телефон
FAXS	VARCHAR(80)		Факс
MAILS	VARCHAR(255)	T	e-mail
CHARGEFIO	VARCHAR(150)	T	Фамилия руководителя
WWW	VARCHAR(255)		Адрес сайта
DELETE_TYPE	INTEGER	T	Признак удаления записи
SHORT_NAME	VARCHAR(255)	T	Краткое наименование
FK_L	INTEGER	T	Город/Район (внешний ключ)
CREATE_DATE	TIMESTAMP	T	Дата создания записи
UPDATE_DATE	TIMESTAMP	T	Дата обновления записи
IMPORT_CREATE_DATE	TIMESTAMP		Дата создания импортирования
IMPORT_UPDATE_DATE	TIMESTAMP		Дата обновления импортирования

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

Name	Data type	Not null	Description
ID	VARCHAR(36)	T	Идентификатор (уникальный ключ)
NUMBER	VARCHAR(2)	T	Класс
LITERA	VARCHAR(10)		Литера класса
FK_OU	VARCHAR(36)	T	ОУ, которому принадлежит класс (внешний ключ)
CREATE_DATE	TIMESTAMP	T	Дата создания записи
UPDATE_DATE	TIMESTAMP	T	Дата обновления записи
IMPORT_CREATE_DATE	TIMESTAMP		Дата создания импортирования
IMPORT_UPDATE_DATE	TIMESTAMP		Дата обновления импортирования
DELETE_TYPE	INTEGER	T	Признак удаления записи

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

Name	Data type	Not ull	Description
ID	VARCHAR(36)	T	Идентификатор (уникальный ключ)
CODE	VARCHAR(16)	T	Код участника
SURNAME	VARCHAR(80)	T	Фамилия
NAME	VARCHAR(80)	T	Имя
SECONDNAME	VARCHAR(80)		Отчество
DOCUMENT_SERIES	VARCHAR(9)		Серия документа
DOCUMENT_NUMBER	VARCHAR(10)		Номер документа
FK_DT	INTEGER	T	Тип документа (внешний ключ)
SEX	INTEGER	T	Пол участника
PCLASS	VARCHAR(50)	T	Класс
BIRTH_DAY	TIMESTAMP	T	Дата рождения
DELETE_TYPE	INTEGER	T	Признак удаления записи
FK_SC	INTEGER	T	Категория участника (внешний ключ)
FK_OU	VARCHAR(36)	T	ОУ, которому принадлежит участник (внешний ключ)
FK_FT	INTEGER	T	Форма обучения (внешний ключ)
CREATE_DATE	TIMESTAMP	T	Дата создания записи
UPDATE_DATE	TIMESTAMP	T	Дата обновления записи
IMPORT_CREATE_DATE	TIMESTAMP		Дата создания импортирования
IMPORT_UPDATE_DATE	TIMESTAMP		Дата обновления импортирования
FK_CLASS	VARCHAR(36)	T	Класс, которому принадлежит участник (внешний ключ)
FK_CITIZENSHIP	INTEGER	T	Гражданство (внешний ключ)

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

Name	Data type	Not null	Description
ID	INTEGER	T	Идентификатор (первичный ключ)
NAME	VARCHAR(20)	T	Название

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

Name	Data type	Not null	Description
ID	INTEGER	T	Идентификатор (первичный ключ)
DATE_DAY	DATE	T	Дата проведения экзамена
FK_SUBJECT	INTEGER	T	Идентификатор (уникальный ключ)
IS_FINAL_EXAM	SMALLINT
IS_CANCEL_EXAM	SMALLINT
PATH_TO_FOLDER	VARCHAR(300)
PATTERN_AB	VARCHAR(50)
PATTERN_C	VARCHAR(50)

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

Name	Data type	Not null	Description
ID	INTEGER	T	Идентификатор (первичный ключ)
NAME	VARCHAR(255)	T	Название

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

Name	Data type	Not null	Description
FTID	INTEGER	T	Идентификатор (первичный ключ)
NAMEFT	VARCHAR(50)	T	Название

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

Name	Data type	Not null	Description
ID	INTEGER	T	Идентификатор (первичный ключ)
CODE	INTEGER	T	Код
NAME	VARCHAR(75)	T	Название

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

Name	Data type	Not null	Default	Description
LEVELDB	INTEGER	T	-1	Уровень доступа к БД (Регион, АТЕ, ОУ)

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

Name	Data type	Not null	Description
LOCALITYID	INTEGER	T	Идентификатор (первичный ключ)
REGION	INTEGER	T	Номер региона
NAME	VARCHAR(255)	T	Название
OCATO	VARCHAR(50)		OCATO

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

Name	Data type	Not null	Description
ID	INTEGER	T	Идентификатор (первичный ключ)
FK_TOU	INTEGER	T	Тип ОУ (внешний ключ)
CODE	INTEGER	T	Код
NAME	VARCHAR(150)	T	Название

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

Name	Data type	Not null	Description
ID	INTEGER	T	Идентификатор (первичный ключ)
CODE	INTEGER	T	Код
NAME	VARCHAR(255)	T	Название

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

Name	Data type	Not null	Description
ID	INTEGER	T	Идентификатор (первичный ключ)
FK_DE	INTEGER	T	Дата экзамена (внешний ключ)
FK_STUDENT	VARCHAR(36)	T	Участник (внешний ключ)
MARK	INTEGER		Оценка участника

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

Name	Data type	Not null	Description
ID	INTEGER	T	Идентификатор (первичный ключ)
CODE	INTEGER	T	Код
SUBJECT	VARCHAR(100)	T	Название предмета
MASK_A	VARCHAR(100)
MAX_A	INTEGER
MASK_B	VARCHAR(100)
MAX_B	INTEGER
MASK_C	VARCHAR(100)
MAX_C	INTEGER
MASK_D	VARCHAR(100)
MAX_D	INTEGER
MAX_CRITERION	SMALLINT
MAX_SUM	SMALLINT

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

Name	Data type	Not null	Description
ID	INTEGER	T	Идентификатор (первичный ключ)
CODE	INTEGER	T	Код
NAME	VARCHAR(50)		Название

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

Name	Data type	Not null	Description
ID	INTEGER	T	Идентификатор (первичный ключ)
CODE	INTEGER	T	Код
NAME	VARCHAR(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);

bool 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);

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

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

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

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

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

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

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

void dataChangedStudent(const QModelIndex &topLeft, const QModelIndex &bottomRight);

bool checkDateExam(int index); //проверка совпадения дат экзаменов

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

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

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

//установка границ для диапазона ячеек

void setStyle(QAxObject *sheet, const QString &range, QString text, bool isBold = false,

int fontSize = 10, int hAlignment = 3, int vAlignment = 2, bool wrapText = false,

int Orientation = 0, bool isBordered = false);

//установка стиля для диапазона ячеек

void 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);//поиск АТЕ или ОУ по id

void writeToXML(const QString &fileName, QString id); //запись данных в зашифрованный XML файл

void exportData();//экспортирование данных из текущей базы в зашифрованный XML файл, либо в новый файл базы данных

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

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

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

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

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

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

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

-34,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. Экспортирование данных позволяет обмен данными между учреждениями для обновления информации по АТЕ, ОУ, классам, участникам ГИА, а также выбранным экзаменам участниками.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Форум разработчиков Qt http://www.qtcentre.org/forum/

8. Html документация по работе с QCA QPI http://delta.affinix.com/qca/

Размещено на