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

Реферат

Объект исследования — работа приемной комиссии факультетов ХАИ Цель работы — разработка системы автоматизации работы приемной комиссии.

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

Разработана база данных для хранения информации, необходимой приемной комиссии. Для разработанной базы данных написано приложение клиент для осуществления обработки информации приемной комиссии. Приложение ориентировано на работу с СУБД Oracle 9i в операционной системе Ms Windows 9x/NT/2000/XP с поддержкой сохранения составленных документов в файле в формате rtf или печати на бумажный носитель.

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

Список сокращений

БД — база данных

ИС — информационная система

ЛВС — локальная вычислительная сеть

ОС — операционная система

ПП — программный продукт

ПК — программный комплекс

СУБД — система управления базами данных

GUI — Graphical User Interface (графический интерфейс пользователя)

IDE — Integrated Development Environment (интегрированная среда разработки)

• Введение
• 1. Постановка задачи
• 2. Разработка структуры программного комплекса
• 2.1 Выбор СУБД
• 2.2 Выбор среды разработки клиентской части программного обеспечения
• 3. Разработка базы данных
• 3.1 Выбор CASE-средства проектирования БД
• 3.2 Разработка информационной модели базы данных
• 3.3 Ограничение доступа пользователей к БД
• 3.2.1 Доступ к общим данным
• 3.2.2 Разграничение доступа к записям таблиц
• 3.3 Таблицы базы данных
• 3.3.1 Таблица SecureUser
• 3.3.2 Таблица Faculty
• 3.3.3 Таблица Special
• 3.3.4 Таблица Bases
• 3.3.5 Таблица Exam
• 3.3.6 Таблица ExamResult
• 3.3.7 Таблица DPUser
• 3.3.8 Таблица Abiturient
• 3.3.9 Таблица AbiturientSpec
• 3.4 Триггеры и функции БД
• 4. Разработка программного обеспечения
• 4.1 Доступ к СУБД
• 4.1.1 Интерфейс ODBC
• 4.1.2 Интерфейс OLE DB
• 4.1.3 Интерфейс ADO
• 4.1.4 Выбор интерфейса программирования
• 4.2 Разработка классов и структур данных
• 4.2.1 Выбор макета программирования
• 4.2.2 Разработка подсистем
• 4.3 Разработка общего алгоритма функционирования системы
• 4.3.1 Алгоритм обработки сообщения OnSelchangeTab
• 4.3.2 Алгоритм обработки сообщения OnAdd
• 4.3.3 Алгоритм обработки сообщения OnDel
• 4.3.4 Алгоритм обработки сообщения OnChange
• 5. Тестирование
• 5.1 Выбор методики тестирования
• 5.2 Тестирование программы
• Заключение
• Список источников
• Приложение
• Введение

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

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

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

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

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

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

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

В данной дипломной работе необходимо разработать программный комплекс для автоматизации работы приёмной комиссии Национального аэрокосмического университета «ХАИ».

Университет проводит прием абитуриентов на 8 факультетов по результатам собеседований, тестирования, олимпиад, выпускных экзаменов физико-математической школы ХАИ, вступительных экзаменов.

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

1. На подготовительном этапе работы приёмной комиссии заносить в базу данных результаты олимпиад и выпускных экзаменов ФМШ. На диаграмме вариантов решений (рис. 1.1) это взаимодействие описывается актором «Оператор ПК» и «Поступающий» и вариантом решений «Добавь результат экзамена». Один поступающий может участвовать в нескольких олимпиадах (связь один ко многим). Информация, которая на этом этапе заносится в Базу Данных:

· Ф.И.О. поступающего;

· Кто проводил олимпиаду (номер факультета, или ЦПК, или лицей ХАИ, или ФМШ ХАИ);

· База, на которой олимпиада проводилась;

· Факультет, на который предполагает поступать участник олимптады;

· Количество баллов, полученных поступающим.

На основе этой информации Оператор ПК может генерировать различные отчёты.

2. На этапе приёма документов заносить в Базу Данных информацию об абитуриентах. На диаграмме вариантов решений (рис. 1.1) это взаимодействие описывается алгоритм Оператор ПК и Абитуриент и вариантом решения «Ведение дела абитуриента». Актор «Абитуриент» является расширением актора «Поступающий», так как Абитуриент должен принимать участие во вступительных экзаменах ХАИ или олимпиадах, проведенных на базе ХАИ. Абитуриент может подать только одно заявление на поступление (связь один к одному). При подаче документов может появиться необходимость внести в Базу Данных результаты экзаменов (расширенная связь между вариантами «Ведение дела абитуриента» и «Добавить результат экзамена»). Информация, которая на этом этапе заносится в Базу Данных:

· специальность, на которую желает поступить абитуриент;

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

· гражданство;

Рис 1.1. Диаграмма выбора вариантов решения

· пол (женский, мужской);

· дата рождения;

· какой иностранный язык изучался в школе;

· адрес абитуриента;

· информация о родителях (Ф.И.О., дата рождения, адрес проживания);

· паспортные данные;

· номер аттестата и год окончания школы (ВУЗа);

· подан оригинал аттестата или его копия;

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

· форма обучения (контрактная или бюджетная);

· номер контракта (при контрактной форме обучения);

· дата подписания контракта;

· сумма оплаты;

· отказ от участия в конкурсе (при контрактной форме обучения);

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

· участие абитуриента в тестировании;

· досрочное зачисление абитуриента до конкурса.

3. На этапе проведения экзаменов в Базу Данных заносятся результаты тестирования и результаты экзаменов, информация о зачислении на специальность по результатам тестирования и по конкурсу. На основе этой информации Оператор ПК может генерировать различные отчёты. На рис. 1.2 представлена расширенная диаграмма вариантов решений, на которой расписаны действия варианта «Ведение дела абитуриента». Эти действия включают в себя:

· Подача заявления абитуриентом.

· Согласование зачётных результатов олимпиад.

· Подача всех необходимых документов.

· Изъятие документов абитуриентов.

Рис 1.2. Расширенная диаграмма выбора вариантов решения На любом этапе работы приёмной комиссии Оператор ПК может генерировать различные отчёты. На рис. 1.3 представлена расширенная диаграмма вариантов решений, на которой расписаны действия варианта «Генерация отчётов». В качестве акторов выступают Операторы ПК, который генерирует отчёты, деканат, II отдел, канцелярия, медпункт, кафедра иностранного языка (акторы, которым направляются отчёты).

Рис 2.3. Расширенная диаграмма выбора вариантов решения

4. Ограничение доступа пользователей к информации в Базе Данных. Всех пользователей можно разделить на следующие категории:

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

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

· Пользователь центральной приемной комиссии — человек, который имеет право просматривать данные об абитуриентах, поступающих в институт. Он может выполнять часть обязанностей актора «Оператор ПК» (разрешено реализовать вариант состояния системы «Генерация отчетов», рис. 1.1)

· Администратор приемной комиссии факультета — человек, который имеет право просматривать, добавлять, изменять данные об абитуриентах, поступающих на данный факультет. Он выполняет роль актора «Оператор ПК» на втором этапе работы приемной комиссии (прием документов) и третьем этапе (проведение экзаменов).

· Пользователь приемной комиссии факультета — человек, который имеет право просматривать данные об абитуриентах, поступающих на данный факультет. Он может выполнять часть обязанностей актора «Оператор ПК» на втором и третьем этапах работы приемной комиссии (разрешено реализовать вариант состояния системы «Генерация отчетов», рис. 1.1).

2. Разработка структуры программного комплекса

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

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

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

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

· сокращение избыточности;

· возможность общего доступа к данным с использованием ЛВС;

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

· обеспечение целостности данных;

· возможность балансирования противоречивых требований;

· возможность обеспечения независимости данных.

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

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

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

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

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

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

Исходя из технического задания и выше сказанного, программный комплекс будет состоять из 2-х основных частей (реализован по двухзвенной архитектуре) (см. рис. 2.1).

1. База Данных.

2. Клиентское приложение.

Рис. 2.1. Структура программного комплекса

2.1 Выбор СУБД

программирование интерфейс автоматизация триггер

Информационные системы типа клиент-сервер можно строить двумя способами:

· с использованием несетевых СУБД, предназначенных для применения на отдельной машине;

· с использованием сетевых СУБД, разрабатываемых для применения в ЛВС.

Под сетевой СУБД здесь понимается система с произвольной моделью данных (не обязательно сетевой), ориентированная на использование в сети.

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

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

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

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

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

При выборе сетевой СУБД были рассмотрены следующие варианты:

· Microsoft SQL Server

· Oracle

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

Поэтому в качестве СУБД будет использоваться реляционная СУБД Oracle 9i.

2.2 Выбор среды разработки клиентской части программного обеспечения

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

В настоящее время среди программных продуктов существует огромное количество универсальных (в смысле пригодности работы с различными серверами БД) средств разработки систем типа клиент-сервер, к числу которых относятся: Delphi, CBuilder (Borland), ERwin (LogicWorks), Visual Studio (Microsoft), SQL Windows и другие. Кроме того, существуют средства разработки в рамках определенных СУБД (например, для Oracle — DesignerS/xxxx).

В качестве языка программирования для написания клиентского приложения будет использоваться язык С++. Основным критерием выбора данного языка по сравнению с Object Pascal было то, что я в основном использую язык C++ в разработках. Язык Java не рассматривался вообще, так как он используется в основном для написания WEB-приложения, которые строятся по трехзвенной архитектуре (БД — серверная программа — Internet browser). Мною было принято решение (раздел 2) о том, что данный программный комплекс будет функционировать по двухзвенной архитектуре.

При выборе сред разработки были рассмотрены две:

· CBuilder (Borland)

· Visual Studio.NET (Microsoft)

Основное качество, присущее всем рассмотренным IDE — это средства автоматизации, которые существенно сокращают объем ручного кодирования, создавая заготовку — программный макет. Макет создается на основе библиотек, предоставляемых IDE. Для CBuilder — это Object Windows Library (OWL), для Visual Studio.Net — это Microsoft Foundation Classes (MFC). В дальнейшем при написании кода программы используются классы из данных библиотек. Основной недостаток — это требование строго следовать правилам написания программы для данного типа макета (диалоговое приложение, одноили много-оконное приложение).

Следующее качество IDE — это средства управления проектом. В состав Visual C++ входит навигатор кода и менеджера проектов — Project Workspace, который позволяет сконцентрироваться на структуре классов и связях между ними, не заботясь о том, где они хранятся. При помощи всплывающего меню легко добавить к определению класса новую переменную или функцию. Есть средства для обхода мест определения и использования компонента класса. В состав Borland C++ также входит навигатор кода и средство управления проектами — ClassExpert, который менее мощный, чем Project Workspace.

Оба IDE имеют удобные средства отладки.

Что касается совместимости с OC Windows и качества генерируемого кода, то API библиотеки MFC лучше работает, чем API OWL (собственно разработкой MFC занимались разработчики ОС Windows).

Набор инструментов для проектирования у Borland C++ более полный, что позволяет быстрее производить разработку программного обеспечения.

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

Таблице 2.1 содержит сводные критерии оценки IDE

В результате анализа было принято решение об использовании ++, в качестве среды разработки — Microsoft Visual Studio.NET.

3. Разработка базы данных

3.1 Выбор CASE-средства проектирования БД

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

При выборе CASE-средств были рассмотрены следующие:

· Designer/2000 2.0 фирмы ORACLE — является интегрированным CASE-средством для использования совместно с СУБД Oracle.

· ERwin — средство концептуального моделирования. Реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (включая и Oracle) и реинжинеринг существующей БД.

Основными критериями при выборе средства были:

Основным критерием была доступность. Поэтому для проектирования использую Designer/2000.

3.2 Разработка информационной модели базы данных

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

Таблица 3.1. Ресурсы, хранимые в базе данных:

Для данных ресурсов справедливы следующие бизнес-правила:

1. Максимальная длина имени факультета — 64 символа.

2. Номер факультета — целое число (1, 2, …).

3. Максимальная длина названия специальности — 64 символа.

4. Номер специальности — целое число (1, 2, …).

5. Максимальная длина названия базы — 64 символа.

6. Оценка результатов экзаменов по 60-ти бальной системе.

7. Максимальная длина имени, фамилии, отчества — по 64 символа.

8. Для обозначения вида довузовской подготовки используются следующие константы:

0- другая;

1- лицей ХАИ;

2- ФМШ ХАИ.

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

0- средняя школа;

1- школа-интернат;

2- ПТУ;

3- высшее учебное заведение 1−2 уровня аккредитации;

4- высшее учебное заведение 3−4 уровня аккредитации.

10. Для обозначения пола используются следующие константы:

0- мужской;

1- женский.

11. Для обозначения льгот используются следующие константы:

0- нет льгот;

1- золотая медаль;

2- серебряная медаль;

4 — красный диплом;

8 — красный диплом ФМШ;

16 — чернобылец;

32 — инвалид;

64 — Сирота.

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

1 — Харьков;

2 — город Харьковской области;

3 — село Харьковской области;

4 — город не Харьковской области;

5 — село не Харьковской области;

6 — СНГ;

7 — приграничные области Российской Федерации.

13. Для обозначения иностранного языка используются следующие константы:

1 — английский;

2 — немецкий;

3 — французский.

14. При поступлении абитуриент может указать несколько специальностей по приоритету (до шести), на которые он желал бы поступить.

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

На рис. 3.2 представлена структура базы данных системы, находящейся во второй нормальной форме.

Развязав отношения многие-ко-многим, которые возникли между таблицами «Special» и «Abiturient», «DPUser» и «Exam» получили структуру базы данных системы, находящуюся в третьей нормальной форме (рис. 3.3).

Рис 3.1. Структура БД во 2 нормальной форме

Рис 3.2. Структура БД в 3 нормальной форме

Рис 3.3. Информационная модель базы данных

Рис 3.4. Окончательная информационная модель базы данных

3.3 Ограничение доступа пользователей к БД

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

· Администратор СУБД — отвечает за создание базы данных;

· Администратор центральной приемной комиссии (АЦПК) — имеет право просматривать, добавлять, изменять любые данные в базе данных;

· Пользователь центральной приемной комиссии (ПЦПК) — имеет право просматривать данные об абитуриентах;

· Администратор приемной комиссии факультета (АПКФ) — имеет право просматривать, добавлять, изменять данные об абитуриентах, поступающих на данный факультет;

· Пользователь приемной комиссии факультета (ППКФ) — имеет право просматривать данные об абитуриентах, поступающих на данный факультет;

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

· К таблицам Faculty, Bases, Exam по чтению имеют право доступа все пользователи. По записи, обновлению или удалению — только АЦПК.

· К таблицам Special по чтению имеют право доступа все пользователи. Пользователи АЦПК и ПЦПК имеют право читать все записи. Пользователи АПКФ и ППКФ — только те записи, которые относятся к их факультету. По записи, обновлению или удалению — только АЦПК.

· К таблицам ExamResult и DPUser по чтению имеют право доступа все пользователи. Пользователи АЦПК и ПЦПК имеют право читать все записи. Пользователи АПКФ и ППКФ — только те записи, которые относятся к их факультету. По записи, обновлению или удалению — АЦПК имеет доступ к всем записям, АПКФ имеет доступ только к тем записям, которые относятся к факультету.

· К таблицам Abiturient и AbiturientSpec по чтению имеют право доступа все пользователи. Пользователи АЦПК и ПЦПК имеют право читать все записи. Пользователи АПКФ и ППКФ — только те записи, которые относятся к их факультету. По записи, обновлению или удалению — только АПКФ.

3.2.1 Доступ к общим данным

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

Доступ разных пользователей к одному набору данных по чтению не несет никаких негативных последствий. Необходимо разграничить доступ по записи, обновлению и удалению. В моем случае необходимо разграничить доступ к таблицам ExamResult и DPUser со стороны пользователей АЦПК и АПКФ. Эти пользователи имеют право изменять содержимое данных таблиц.

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

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

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

Исходя из правил разграничения доступа, определяем, что необходимо разграничить доступ к различным записям таблиц на select, update, delete и insert для всех пользователей БД (кроме Администратора). Критерием доступа будут:

· Принадлежность пользователя к категории пользователей.

· Принадлежность пользователя к факультету.

Для хранения этих критериев внесем в базу данных еще одну таблицу — SecureUser, которая будет содержать в себе имя пользователя (соответствует логину пользователя, под которым он будет регистрироваться в системе), его категория и факультет, которому он принадлежит (только для АПКФ и ППКФ). Окончательная информационная модель базы данных системы, находящаяся в третьей нормальной форме, представлена на рис. 3.4.

Обеспечивать разграничение доступа будем двумя способами:

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

· Введение Row Level Security (RLS) — механизм, который использует условие отбора (предикат) при выполнении запросов к таблицам базы данных. Этот механизм состоит из двух частей — создание функции, которая по имени пользователя генерирует предикат отбора, и связь это функции с целевой таблицей, перечислив действия, для которых эта функция должна выполняться.

3.3 Таблицы базы данных

3.3.1 Таблица SecureUser

Таблица включает информацию о пользователях БД.

Поля:

Кодовые обозначения для поля adm:

0 — Администратор БД, Администратор СУБД

1 — Администратор центральной приемной комиссии (АЦПК)

2 — Пользователь центральной приемной комиссии (ПЦПК)

3 — Администратор приемной комиссии факультета (АПКФ)

4 — Пользователь приемной комиссии факультета (АПКФ)

Ограничения, накладываемые ролями:

· Для АЦПК, ПЦПК, АПКФ, ППКФ — только чтение.

Предикаты доступа к полям для пользователей:

· Для АЦПК, ПЦПК, АПКФ, ППКФ — «логин пользователя == user_name».

3.3.2 Таблица Faculty

Таблица включает информацию о факультетах университета.

Поля:

Ограничения, накладываемые ролями:

· Для ПЦПК, АПКФ, ППКФ — только чтение.

3.3.3 Таблица Special

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

Поля:

Ограничения, накладываемые ролями:

· Для ПЦПК, АПКФ, ППКФ — только чтение.

Предикаты доступа к полям для пользователей:

· Для АПКФ, ППКФ — «UserTable[логин = user_name]. fac_id = id_fac».

3.3.4 Таблица Bases

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

Поля:

Ограничения, накладываемые ролями:

· Для ПЦПК, АПКФ, ППКФ — только чтение.

3.3.5 Таблица Exam

Таблица включает информацию об олимпиадах, выпускных экзаменах ФМШ, вступительных экзаменах в институт.

Поля:

Ограничения, накладываемые ролями:

· Для ПЦПК, АПКФ, ППКФ — только чтение.

3.3.6 Таблица ExamResult

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

Поля:

Ограничения, накладываемые ролями:

· Для ПЦПК, ППКФ — только чтение.

Предикаты доступа к полям для пользователей:

· Для АПКФ, ППКФ — «(UserTable[логин = user_name]. fac_id = id_fac) | (UserTable[логин = user_name]. fac_id = Base[Exam[id_exam]. id_base].id_fac)» (факультет, на который пишется экзамен, или факультета, которому принадлежит база, на котором писался экзамен, совпадает с искомым).

3.3.7 Таблица DPUser

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

Поля:

Ограничения, накладываемые ролями:

· Для ПЦПК, ППКФ — только чтение.

Предикаты доступа к полям для пользователей:

· Для АПКФ, ППКФ — «факультет, на который писался хоть один экзамен данного факультета, или абитуриент подал заявление на данный факультет, но у него еще нет результатов экзаменов (определяется через таблицы AbitSpec и Spec), совпадает с искомым».

3.3.8 Таблица Abiturient

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

Поля:

Ограничения, накладываемые ролями:

· Для АЦПК, ПЦПК, ППКФ — только чтение.

Предикаты доступа к полям для пользователей:

· Для ППКФ — «абитуриент подал заявление на данный факультет, (определяется через таблицы AbitSpec и Spec)».

3.3.9 Таблица AbiturientSpec

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

Поля:

Ограничения, накладываемые ролями:

· Для АЦПК, ПЦПК, ППКФ — только чтение.

Предикаты доступа к полям для пользователей:

· Для ППКФ — «Специальность принадлежит искомому факультету (определяется через таблицу Spec».

3.4 Триггеры и функции БД

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

Для каждой таблицы создан триггер (BEFORE INSERT), который получает из последовательности новый ключ и использует его при вставке новых значений в таблицу.

Создан триггер AFTER USER LOGON, который вызывается при подключении пользователя к БД. В нем определяются предикаты доступа к полям таблиц на основе имени пользователя.

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

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

4.1 Доступ к СУБД

Для осуществления доступа к БД существует множество программных интерфейсов. Три наиболее распространенных интерфейса — ODBC, OLE DB, ADO.

4.1.1 Интерфейс ODBC

Открытое соединение с базой данных (Open Database Connectivity или ODBC) — стратегия Microsoft, предоставляющая разработчикам приложений единый API для разных ядер баз данных, систем управления реляционными и нереляционными базами данных (database management system — DBMS). ODBC API предназначен для предоставления прикладным разработчикам аналогичных функциональных возможностей независимо от типа данных, к которым выполняется доступ, — базам данных ISAM, текстовым данным (Excel) или базам данных SQL. Эта цель достигается путем закрепления каждого драйвера ODBC за одним из предопределенных уровней соответствия.

ODBC API абстрактно удален от реального источника данных, как это показано на рис 4.1.

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

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

Рис 4.1. Доступ к СУБД с помощью ODBC

4.1.2 Интерфейс OLE DB

OLE DB позволяет разрабатывать приложения, работающие с различными источниками данных. OLE DB облегчает приложениям доступ к данным, хранящимся в разных СУБД и в источниках информации, отличных от СУБД. В качестве источников для СУБД могут выступать базы данных мэйнфреймов, такие как IMS™ и DB2®, серверные базы данных, например Oracle® и Microsoft SQL Server, а также базы данных персональных компьютеров, такие как Microsoft Access, Paradox и Microsoft FoxPro®. К не-СУБД источникам относятся файловые системы, такие как Windows NT® и UNIX®, индексно-последовательные файлы, электронная почта, электронные таблицы, средства управления проектами и многое другое.

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

OLE DB использует инфраструктуру модели OLE СОМ (Component Object Model), что сокращает ненужное дублирование сервисов и расширяет возможности взаимодействия не только для разных источников информации, но и для разных программных сред и инструментов. OLE DB — это способ доступа к данным в среде СОМ.

4.1.3 Интерфейс ADO

ADO — это объектно-ориентированный интерфейс фирмы Мicrosoft для работы с базами данных и другими аналогичными источниками данных — объектам данных АctiveХ (АctiveХ Data Оbject — АDО). АDО содержит описание объектов, которые можно использовать для работы с данными многих различных типов приложений. АDО опирается на интерфейс Соmmоn Оbjесt Моdel (СОМ), содержащий объекты, доступные для широкого спектра языков программирования, включая Visual С++, Visual Basic, Visual Basic for Applications (VВА), VBScript и JavaScript. АDО также можно использовать в серверных или приложениях промежуточного типа, особенно при работе с Active Server Page компании Мicrosoft.

АDО содержит только описание различных используемых объектов и не обеспечивает их специальной реализации. Компания Мicrosoft включила реализацию АDО для доступа к любым имеющимся источникам данных ОLЕ DB, включая новый провайдер Аctive Directory, который реализует интерфейс ОLЕ DВ для работы с файловыми системами. Эта реализация АDО для ОLЕ DВ получила название АDОDВ.

АDОDВ также может использоваться для доступа к провайдеру Мicrosoft ОLЕ DВ (MSDASQL), обеспечивающего, в свою очередь, доступ к любым имеющимся источникам данных ОDВС. Архитектура ADO представлена на рис 4.2.

Рис 4.2. Доступ к СУБД м помощью ADO

4.1.4 Выбор интерфейса программирования

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

Таблица 4.1. Сравнение интерфейсов доступа к СУБД

ODBC поддерживается практически всеми СУБД. Он прост в использовании. Интерфейс OLE DB довольно сложно использовать в прикладном программировании. К тому же в нашем проекте мы не используем нереляционные базы данных и доступ к базе данных через WWW. Поэтому для нашего проекта наиболее подходящим является интерфейс ODBC, который и будем использовать.

В качестве драйвера ODBC будем использовать поставляемый с Oracle драйвер.

4.2 Разработка классов и структур данных

4.2.1 Выбор макета программирования

При создании проекта с использованием Microsoft Visual Studio.NET необходимо выбрать макет (архитектуру), в соответствии с которым будет создано приложение. В качестве макета можно использовать следующие.

· Приложение на основе диалогового окна. Наиболее простой тип приложений. В качестве каркаса используется экземпляр класса CDialog, с которым связан ресурс — форма диалогового окна, на котором я могу размещать элементы управления. Для добавления компонентов на форму используется визуальное проектирование — перетаскивание различных элементов с панели инструментов на форму.

· MDI/SDI/STI — одномного-документное и многооконное приложение. В качестве каркаса используется модель документ/вид, которая реализуется экземплярами классов CDocument, CView, CMainFrame.

В качестве макета выбираю приложение на основе диалогового окна. Основной критерий выбора — при работе с информацией из БД будет использоваться много управляющих элементов (таблиц, списков, других элементов), которыми проще управлять с использованием диалогового окна, нежели чем с CMainFrame или CView. Кроме того, основную идею макетов SDI/MDI/STI — модель документ-вид — можно реализовать без использования библиотеки MFC.

4.2.2 Разработка подсистем

Исходя из технического задания, программное обеспечение можно разделить на две части:

· работа с БД (выборка по определенным критериям, вставка, изменение, удаление записей);

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

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

Общая структура пакетов системы представлена на рис. 4.3.

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

Графический интерфейс реализован в пакетах Dialogs и Common Control.

Пакет Dialogs включает классы диалогов для обеспечения пользовательского интерфейса. Состав этого пакета приведен на рисунке 4.4.

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

Пакет Local Classes включаю общие классы, такие как класс для доступа к реестру и класс приложения. Структура пакета представлена на рисунке 4.7.

Пакет MFC 6.0 представляет собой стандартные классы библиотеки MFC, которые используются при написании программы.

Распишем более подробно составы пакетов.

Рис 4.3. Структура системы

Пакет Database

Состав пакета приведен на рисунке 4.5. Он состоит из классов CDb, CDBBase, CFaculty, CSpecial, CBases, CExam, CDPUser, CAbiturient, CExamResut, CAbitSpec.