Заключение 113

13 Заключение 113

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

14 Руководство системного администратора 115

Исходный текст программного комплекса: 119

Введение

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

Результатом работы над данным дипломным проектом является анализ существующей технологии проведения аттестации ИТ-специалистов на предприятии ОАО «Троицкая ГРЭС», её модификация и автоматизация.

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

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

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

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

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

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

Оценка для администрации помогает решить, кому следует повысить зарплату, кого — повысить в должности, а кого — уволить.

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

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

И, наконец, результаты оценки могут быть использованы при разработке средств отбора персонала, например, тестов [4].

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

Основным вопросом при этом является: "Что следует оценивать?"

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

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

1 Типовые решения клиент серверных технологий
1.1 Архитектуры "файл-сервер" и "клиент-сервер"

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

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

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

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

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

не оптимально расходуются ресурсы клиентского компьютера и сети: например, если в результате запроса мы должны получить 2 записи из таблицы объемом 10 000 записей, все 10 000 записей будут скопированы с файл-сервера на клиентский компьютер; в результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера. Заметим, что потребности в постоянном увеличении вычислительных мощностей клиентского компьютера обусловливаются не только развитием программного обеспечения как такового, но и возрастанием обрабатываемых объемов информации;

в БД на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения, непосредственно из инструментальных средств (например, из утилиты Database Desktop фирмы Borland для файлов Paradox или dBase); подобная возможность облегчается тем обстоятельством, что, фактически, у локальных СУБД база данных понятие более логическое, чем физическое, поскольку под БД понимается набор отдельных таблиц, сосуществующих в едином каталоге на диске. Все это позволяет говорить о низком уровне безопасности - как с точки зрения хищения и нанесения вреда, так и с точки зрения внесение ошибочных изменений;

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

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

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

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

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

Преимущества архитектуры "клиент-сервер":

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

• снижается сетевой трафик за счет посылки сервером клиенту только тех данных, которые он запрашивал; например, если необходимо сделать из таблицы объемом 10 000 записей выборку, результатом которой будут всего 2 записи, сервер выполнит запрос и перешлет клиенту НД из 2 записей;

• упрощается наращивание вычислительных мощностей в условиях развития программного обеспечения и возрастания объемов обрабатываемых данных: проще и чаще дешевле усилить мощности на сетевом сервере или полностью заменить сервер на более мощный, нежели наращивать мощности или полностью заменять 100-500 клиентских компьютеров;

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

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

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

Для реализации архитектуры применяют так называемые "промышленные” СУБД, такие как Borland InterBase, Oracle, Informix, Sybase, DB2, MS SQL Server.

1.2 Создание приложений для работы с базами данных

Delphi 7.0 представляет собой уникальную систему разработки, в которой технология высокопроизводительной оптимизирующей компиляции сочетается с визуальными средствами разработки и масштабируемым процессором баз данных. Это позволяет создавать эффективные приложения Windows, работающие с базами данных, в том числе и программы для систем клиент/сервер. Для создания таких приложений в Delphi 7.0 используется объектно-ориентированный подход, базирующийся на применении различных компонентов (визуальных и не визуальных), что обеспечивает неограниченную расширяемость и маcштабируемость. Delphi 7.0 позволяет разработчику быстро создавать и свободно распространять приложения с архитектурой клиент/сервер, работающие существенно быстрее и надежнее предыдущего поколения программных продуктов, которые строились при помощи систем разработки, основанных на интерпретируемом коде [9].

Большим преимуществом приложений, разрабатываемых в среде Delphi 7.0,- стала доступность использования как реляционного, так и навигационного прог­раммирования при работе с данными. Такую возможность приложениям Delphi 7.0 предоставляет ядро процессора баз данных Borland Database Engine (BDE). Использование реляционных методов позволяет манипулировать большими вы­борками информации и легко проводить групповые операции. Навигационные методы дают приложению преимущества быстрого доступа к отдельным полям и записям таблиц баз данных.

Структурная схема организации доступа приложения к различным базам дан­ных отражена на рисунке 1.1. В наиболее общем случае работа с данными в Delphi 7.0 осуществляется через BDE, который обеспечивает непосредственную связь с локальными базами дан­ных и используется при организации доступа к удаленным серверам. В основе BDE лежит технология Integrated Database API (IDAPI), уже известная прог­раммистам, которые работают с СУБД фирмы Borland. Через BDE и драйверы Borland SQL Links приложение может связываться с SQL-серверами. В то же время, BDE поддерживает и интерфейс Open DataBase Connectivity (ODBC), что позволяет получить доступ не только к любому удаленному серверу баз данных, для которого имеется драйвер ODBC, но и к любому источнику структурированных данных.

Рис. 1.1. Механизм организации доступа приложения к базам данных

Примечание

ODBC — интерфейс для свободного доступа к данным в гетерогенной среде реляционных и не реляционных баз данных. Основываясь на базовом интерфейсе SQL — Call Level Interface, ODBC обеспечивает открытый до ступ к большинству данных, расположенных на персональном компьютере миникомпьютере и к базам данных больших ЭВМ, позволяя разработчикам иметь одновременный доступ к базам данных. Стандарт ODBC полностью поддерживает технологию клиент/сервер.

В состав стандартной поставки Delphi 7.0 включен локальный сервер Interbase, который позволяет проводить в Delphi 7.0 автономную разработку приложений с поддержкой SQL, готовых к переносу в среду клиент/сервер. Он представляет собой облегченный вариант Interbase Workgroup Server 4.0.

1.3 Ядро Borland Database Engine (BDE)

Как уже отмечалось, использование Delphi 7.0 позволяет разработчику создавать самые разнообразные приложения для работы с базами данных. Среди них могут быть как простейшие программки, открывающие два-три поля, так и мощные приложения, предназначенные для работы в системах клиент/сервер. Такая универсальность достигается за счет использования ядра BDE. В основе BDE лежит технология IDAPI, которая включает IDAPI-инфраструктуру и обработчик запросов [2].

Использование BDE позволяет приложению осуществлять доступ к данным не только локальных (Paradox и dBase), но и удаленных баз данных, располо­женных на SQL-серверах (Interbase, Sybase, Oracle, Informix, MS SQL Server), а также в любых форматах, доступных через драйверы ODBC (см. рис. 1.2). BDE поддерживает многопользовательский доступ к гетерогенным базам дан­ных, связанные запросы к нескольким разнотипным базам данных одновре­менно, прямой перенос данных из одного формата в другой. Программисты могут обращаться к функциям BDE с помощью языков программирования Borland C++, Borland Pascal, Visual C++, а также любых других компиляторов С и C++ для Windows.

Архитектура BDEUDAPI основана на драйверах. Для каждого источника дан­ных существует свой драйвер, который поддерживает не только последнюю версию источника, но и все предыдущие версии. Именно через такие драйверы осуществляется связывание и все обращения к данным. BDE поддерживает два класса драйверов. К первому классу относятся драйверы, обслуживающие SQL-серверы, причем каждый из этих серверов может использовать собственный диалект SQL. Во второй класс входят драйверы для локальных баз данных.

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

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

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

Сортировщик автоматически оптимизирует процесс использования доступной памяти и вызывается через соответствующую функцию BDE. Он использует установленный языковый драйвер для работы с различными наборами сим­волов.

Кэш для данных BLOB позволяет производить чтение/запись произвольного места в бинарном объекте, при переполнении содержимое кэша автоматически записывается в разделяемый файл. Одновременно может быть открыто любое количество BLOB.

Генератор SQL транслирует запрос в формате QBE в эквивалентный запрос SQL, если он предназначен SQL-серверу.

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

Функции пакетной обработки включают копирование данных из одного формата в другой, переименование таблиц и т. д.

Модуль Xlate оптимизирует процесс преобразования форматов данных.

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

Модуль поддержки SQL-драйверов используется при создании любых SQL-драйверов.

Конфигурационный диспетчер участвует в настройке среды BDE при начальной загрузке.

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

Общий обработчик запросов поддерживает и SQL и QBE. Он построен с использованием технологии курсоров BDE и поэтому может работать с любым источником данных. Если запрос может быть выполнен напрямую, то он сразу передается серверу. Запрос QBE предварительно транслируется в SQL.

Технология Idapter является составной частью BDE и предназначена для организации доступа к базам данных, используя стандартный программный интерфейс драйверов Borland SQL Links. Idapter транслирует вызовы функций интерфейса IDAPI в вызовы стандартных методов интерфейса ODBC, что позволяет использовать практически любой драйвер стандарта ODBC в режиме драйвера IDAPI. При этом могут использоваться любые функции интерфейса IDAPI. Технология Idapter существенно увеличивает число доступных

через BDE форматов данных. Поставляется совместно с IDAPI, как отдельная динамическая библиотека.

1.4 Пакет Borland SQL Links for Windows

Пакет Borland SQL Links for Windows предназначен для использования теми приложениями, работающими с BDE, которым необходим доступ и к локаль­ным базам данных и к удаленным SQL-серверам. После инсталляции соответ­ствующего драйвера SQL Links и создания необходимого псевдонима приложение получает доступ к базам данных необходимого SQL-сервера. Место SQL Links в механизме доступа к базам данных из приложений Delphi 7.0 показано на рисунке 4.7.

Установленный драйвер выполняет работу по соединению с нужным SQL-сер­вером, переводу запросов приложения в соответствующий диалект SQL и пере­даче запроса базе данных. Ответ базы данных снова преобразуется им к виду, воспринимаемому приложением.

Для установки параметров процесса связывания приложения с требуемым сер­вером SQL используется утилита конфигурации BDE. Естественно, что перед выполнением такой настройки необходимо иметь инсталлированный SQL Links с установленным драйвером для нужного сервера. Все настраиваемые пара­метры сосредоточены на странице Drivers утилиты конфигурации (см. рисунок 1.2).

SQL Links транслирует

Ответ клиента и посылает его BDE

Сервер SQL проверяет правильность запроса. выполняет его и отправляет приложению-клиенту

Рис. 1.2. Использование драйвера SQL Links приложением

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

Ниже будут рассмотрены общие для всех драйверов SQL Links параметры.

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

BDE и нажав кнопку Help.

DLL — определяет имя динамической библиотеки SQL Links для драйвера.

Driver Flags — внутренний флаг, изменять этот параметр не рекомендуется.

LangDriver — задает языковый драйвер, который применяется для манипулирования данными, полученными при помощи драйвера SQL Links. Поле ввода этого параметра содержит список всех доступных языковых драй­веров. Если выбранный языковый драйвер определен также и в псевдониме приложения, то он используется для управления любыми данными, получен­ными от сервера. Языковый драйвер используется для преобразования данных, если приложение и сервер используют разные кодовые страницы. В противном случае все национальные символы превратятся в абракадабру. Если необ­ходимый языковый драйвер отсутствует, можно использовать параметр SQLQRYMODE для отмены преобразования данных по правилам базы данных.

Open Mode — определяет режим, в котором SQL Links открывает доступ к базе данных. Возможные значения: "Чтение\3апись" и "Только для чтения". Режим "Только для чтения" не работает при использовании прямых запросов.

Schema Cache Size — задает число таблиц базы данных, чья структурная информация кэшируется. Возможные значения: 0—32 (по умолчанию 8).

Schema Cache Time — задает время нахождения структурной информации о таблицах в кэше. Возможные значения: -1 (по умолчанию) — до закрытия базы данных; 0 — информация в кэше не размещается; 1-214748347 — число секунд.

Server Name — содержит имя целевого сервера. Для серверов Interbase обязательно надо задавать маршрут, как это показано в примере:

servername/usr/gds/directoryname/databasename/gdb.

SQLPASSTHRUMODE — определяет режим использования прямых и ло­кальных запросов при соединении через один псевдоним: NOT SHARED запрещает одновременное использование прямых и локальных запросов;

SHARED AUTOCOMMIT разрешает совместное использование, причем прямые запросы ведут себя в соответствии с правилами для локальных запросов, что означает режим автоматической фиксации транзакций, если только не установлено явное управление транзакциями или режим группового выполнения; SHARED NOAUTOCOMMIT разрешает совмест­ное использование, но режим неявной фиксации транзакций не исполь­зуется. Поведение прямых запросов зависит от типа сервера.

Предопределенное значение для серверов Informix — SHARED AUTOCOMMIT, для остальных серверов SQL — NOT SHARED. Режимы SHARED AUTOCOMMIT и SHARED NOAUTOCOMMIT не под­держиваются некоторыми предложениями прямых запросов, в этом слу­чае следует использовать явное управление транзакциями через функции приложения.

SQLQRYMODE — определяет режим выполнения запросов, возможные значения приведены в таблице.

Таблица 1.1 Режимы выполнения запросов.

Значение	Режим	Комментарий
NULL	Сервер-локальный	Запрос направляется сначала на сервер, затем, при невозможности выполнения, выполняется локально
SERVER	Только сервер	Запрос направляется только на сервер, в случае невозможности выполнения, отменяется
LOCAL	Только локальный	Запрос выполняется исключительно локально

Значение по умолчанию — NULL. На получаемый результат запросов может влиять установленный языковый драйвер, если локальные базы данных и базы SQL имеют различные кодовые страницы (см. выше). Для устранения подобных ошибок необходимо установить для параметра значение SERVER, блокируя таким образом, выполнение запросов в ло­кальных базах данных.

Type определяет тип используемого сервера. Значение SERVER определяет использование SQL-сервера. Значение FILE определяет использование обычных серверов, основанных на файловой системе.

User Name — задает имя пользователя для доступа к серверу.

Version — версия драйвера SQL Links.

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

1.5 Использование SQL

В этом разделе будут рассмотрены различные аспекты применения запросов SQL в приложениях, использующих базы данных. Для реализации запросов в Delphi 7.0 существует специальный компонент — TQuery, расположенный на странице Data Access Палитры компонентов. Он имеет много общих свойств с TTable и тоже используется для открытия наборов данных. В то же время TQuery обладает рядом свойств и методов, которые позволяют использовать все преимущества запросов SQL для работы с данными. Так, применение TQuery дает возможность работать с данными нескольких таблиц в одном запросе, отбирать данные сразу по нескольким критериям. Однако следует помнить, что использование SQL ведет к некоторому усложнению програм­много кода приложения. Кроме того, создание эффективного запроса — дело далеко не простое и требует наличия определенного опыта в этой области. Запросы SQL бывают статическими и динамическими. Статические запросы полностью создаются при отладке приложения, а динамические могут изменять свои параметры при выполнении приложения.

Приложения Delphi 7.0 при помощи механизма запросов SQL могут использовать данные:

• таблиц Paradox и dBase, используя синтаксис локального SQL;

• локального сервера Interbase, синтаксис языка поддерживается полностью;

• удаленных серверов SQL через драйверы SQL Links.

1.6 Особенности создания систем клиент/сервер

Возможность создания приложений для работы в составе систем клиент/сервер, бесспорно, стала большим преимуществом Delphi 7.0. Инструментарий для разра­ботки таких приложений интегрирован в составе среды разработчика. Приложения Delphi 7.0, функционирующие на станции-клиенте, используя возмож­ности BDE и драйверов SQL Links и ODBC, могут получать доступ к данным удаленных SQL-серверов. В качестве серверов могут быть использованы Informix, Interbase, Microsoft SQL Server, Oracle, Sybase. Кроме этого, через BDE и установленный драйвер ODBC возможен доступ к таким базам, как DB2, Btrieve, Microsoft Access и другим, для которых существует соответствующий драйвер ODBC.

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

1.7 Совместимость / эффективность

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

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

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

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

В дальнейшем реализация архитектуры "клиент-сервер" будет рассматриваться для сервера Borland Interbase. Объяснить такой выбор нетрудно. Во-первых, Interbase - "родной" сервер для Delphi 7.0 (поэтому для доступа к нему не нужно устанавливать дополнительных драйверов SQL Links, что необходимо при работе из приложений, написанных на Delphi 7.0, с Oracle, Sybase и другими СУБД). Во вторых, в поставку Delphi входит локальный (однопользовательский, на 2 одновременных подключения) сервер Local Borland Interbase. Доступен также и Interbase для Windows 95 на 4 пользователя.

Локальный Interbase может использоваться для отладочных целей. После того, как приложение отлажено на локальной версии SQL-сервера, происходит масштабирование приложения (upsizing). БД переносится на сетевой сервер, а изменения в клиентских приложениях при этом минимальны - необходимо изменить псевдоним БД и, может быть, скорректировать некоторые параметры соединения приложения с сервером.

1.8 Перенос данных

При переносе приложений, ранее разработанных для применения в архитектуре "файл-сервер", требуется не только частично или полностью переписывать приложения клиентов, но и преобразовывать локальную БД в серверную. Для этого под управлением серверной СУБД (например, Interbase) создают БД на сервере, куда затем "перекачивают" данные из локальных СУБД реализованных, например, с помощью Paradox. Основная проблема, встающая в этом случае - несовместимость некоторых форматов данных или их отсутствие. Например, Interbase не поддерживает поля типа Boolean (Logical), и их необходимо реализовывать при помощи столбцов типа CHAR(1); Interbase не поддерживает автоинкрементные поля Paradox - для обеспечения уникальности значений в числовых полях в БД Interbase используют генераторы и т.д. При возникновении подобных проблем следует изучить вопросы совместимости типов данных локальной СУБД и выбранной серверной СУБД.

Преобразование делится на два этапа: •

• модернизация баз данных до уровня сервера;

• преобразование приложений в приложения-клиенты.

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

Преобразование базы данных в сервер содержит ряд этапов.

1. Создание метаданных, основанных на структуре базы данных.

2. Перенос данных на сервер.

3. Разделение данных по типам.

4. Создание паролей и интеграция данных.

5. Контроль транзакций.

6. Управление доступом к данным.

7. Проверка данных.

Delphi обеспечивает два способа преобразования баз данных:

• использование возможностей утилиты Database Desktop для преобразования таблиц в формат SQL;

• использование при создании приложения компонента TBatchMove.

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

Приложения, созданные для работы с локальными базами данных, могут быть приспособлены для систем клиент/сервер только путем внесения ряда исправ­лений в исходный код. В простейшем случае, при полном совпадении структуры преобразованных и исходных данных необходимо лишь изменить параметры свойств DatabaseName используемых компонентов TTable и TQuery и добавить в приложение компонент TDatabase. Однако такое бывает не часто.

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

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

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

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

1.9 Применение локального сервера InterBase

Локальный Interbase Server является версией сервера Borland Interbase 6.0 для

Windows и содержит полный набор функций для локального однопользовательского применения. При разработке приложений клиент/сервер локальный Interbase Server может использоваться в качестве модели сервера или для преобразования баз данных в серверы SQL (см. "Перенос данных"), кроме этого, он может применяться в качестве процессора базы данных в работ локальных приложений. Его использование позволит разработчику повысит надежность разрабатываемого приложения и избежать возможной потери данных при тестировании "сырых" приложений.

Если база данных, для работы с которой предназначено разрабатываемое приложение, уже существует, то Interbase Server может быть использован для

решения ряда других вопросов:

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

2. Для создания приложений, использующих Interbase в качестве сервера;

3. Применение Windows ISQL возможно для создания базы Interbase, предложения SQL которой могут быть использованы в базе сервера приложения

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

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

Если приложение разрабатывается для уже существующей базы функционирующей на сервере Interbase:

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

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

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

1.10 Локальный сервер InterBase

Локальный сервер Interbase представляет собой версию Borland Interbase Workgroup Server 6.0 для одного пользователя, работающую под управлением Windows. Этот сервер содержит в своем составе утилиты Windows ISQL и Server Manager, которые также могут использоваться с полномасштабным сер­вером Interbase. Доступ к базам данных, управляемым локальным сервером Interbase, осущес­твляется через Windows ISQL или само приложение.

Сервер может использоваться в среде разработчика Delphi для решения ряда задач создания приложений и наборов данных:

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

2. Проводится тестирование приложений клиент/сервер, причем Interbase используется в качестве модели реального сервера.

3. При преобразовании локальных СУБД до уровня возможностей сервера SQL, локальный Interbase может использоваться как промежуточная сту­пень (см. раздел "Особенности построения приложений для архитектуры клиент/сервер").

Доступ к данным сервера осуществляется через BDE и SQL Links. Сервер поддерживает стандарт языка ANSI SQL 92, доступ к предложениям которого осуществляется через Windows ISQL или приложение. Некоторые расширения SQL, поддерживаемые сервером, конфликтуют с диалектом SQL3, среди них хранимые процедуры, триггеры и данные типа BLOB.

Используемые локальным сервером Interbase форматы данных представлены в таблице.

Таблица 1.2 Основные форматы данных Interbase.

Формат данных	Типы данных
Числовой	Smallint, Integer, Float, Double Precision, Numeric, Decimal
Символьный	Char, VarChar
Календарный	Data
BLOB	BLOB

Естественно, что локальный Interbase Server уступает полномасштабному варианту. Среди важнейших отличий можно отметить отсутствие следующих возможностей:

• BLOB фильтров;

• массивов данных;

• отслеживания событий;

• функций, определяемых пользователем;

• ограничена поддержка записи через журнал (WAL).

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

Анализ существующей системы. Обзор литературы

Поиск информации о существующих системах аттестации ИТ-специалистов привёл к выводу, что доминирующая часть таких систем работает через Web-интерфейс, вот примеры таких систем:

1. Сертификация Microsoft Office User Specialist (MOUS) - всемирно признанный стандарт для оценки навыков работы с бизнес приложениями Microsoft Office [8]

http://www.specialist.ru/MOUS/

2. Сервера - профессиональной оценки знаний в области информационных технологий

http://tests.specialist.ru/

3. А+ сертификация – программа тестирования, предоставленная компьютерной ассоциацией CompTIA, которая подтверждает компетенцию начинающих специалистов по обслуживанию компьютерной техники с опытом работы 6 месяцев или прошедших подготовку на соответствующих курсах.

Любой, кто хочет получить признанное во всем мире удостоверение компетентного профессионала, может сдать экзамены А+. Программа сертификации поддерживается основными производителями и продавцами аппаратного и программного обеспечения. Тесты, впервые стали доступны в 1993 г., были пересмотрены к 31 июля 1998 г и последний раз обновлены в 2001 году.

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

http://www.specialist.ru/aplus/aplus.asp

4. Фирма Virtual University Enterprises образована 10 апреля 1997 года для проведения электронных сертификационных экзаменов. Главные офисы фирмы расположены в Миннеаполисе, Нидерландах и Сиднее. Фирма имеет центры тестирования по всему миру.

Процесс сдачи экзамена одинаков для всех центров тестирования VUE.

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

По окончании тестирования происходит автоматическая печать отчета с результатами. При успешной сдаче экзамена кандидат получает по почте соответствующий сертификат от вендора (Microsoft и пр.).

Сертификация Microsoft, CompTIA, Novell, PTC, Sybase, LPI, Ericsson, CIW, Informix является объективным критерием оценки компетентности компьютерных специалистов, признаваемым во всем мире.

http://www.specialist.ru/VUE/vue.asp

5. Cертификация ECDL (European Computer Driving Licence). Главная задача обеспечить международный стандарт оценки навыков работы с персональным компьютером.

Фонд ECDL-F, осуществляющий проведение и контроль сертификации по всему миру, был создан в 1997 году при поддержке Европейского компьютерного общества CEPIS. Сертификат (документ, подтверждающий квалификацию), который получает пользователь после успешной сдачи экзаменов, называется ECDL - European Computer Driving Licence (за пределами Европы сертификат называется ICDL - International Computer Driving Licence). Сертификат признан более чем в 50 странах мира, включая Великобританию, Германию, Норвегию, Швецию, Финляндию, Канаду, Австралию, Египет и многие другие. ECDL-F гарантирует качество и соблюдение единых требований к работе центров тестирования.

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

Сертификация считается пройденной, если Вы успешно сдали 1 теоретический и 6 практических модулей:

- Основные положения информатики (Basic Concepts of Information

Technology) (теоретический)

- Применение компьютера и управление файлами (Using the Computer

and Managing Files)

- Обработка текстов (Word Processing)

- Электронные таблицы (spreadsheets)

- Базы данных (Databases/Filing Systems)

- Презентации (Presentation)

- Обмен информацией (Information and Communication)

http://www.specialist.ru/ECDL/

http://www.brainbench.com/xml/bb/homepage.xml

Другой распространённый вариант – это интервью – как метод аттестации с привлечением сторонних экспертов и комиссии по оценке результатов аттестации.[1]

Задачей настоящего дипломного проекта является решение «локальной», для конкретного предприятия проблемы аттестации ИТ-специалистов, как можно более приблизив тематику вопросов к задачам, выполняемым на этом, отдельно – взятом предприятии ОАО «Троицкая ГРЭС».

Архитектура программной системы

Архитектура программной системы представлена на рисунке 3.1 и рисунке 3.1а.

SQL Links транслирует

Ответ клиента и посылает его BDE

Сервер SQL проверяет правильность запроса. выполняет его и отправляет приложению-клиенту

Сервер баз данных

Автоматический контроль ссылочной целостности данных

Встроенная защита данных от несанкционированного доступа

Выполнение хранимых процедур, созданных для обработки данных

Автоматическая генерация уникального ключа

Встроенная возможность резервного копирования данных

ИТА: Аттестация

Начало сессии аттестации

Выбор любого количества категорий, вопросы из которых задавать

Свободное перемещение по базе вопросов, с сохранением уже данных ответов

Возможность выхода из системы с сохранением всех данных ответов

Возможность продолжить сессию аттестации в любое удобное время с сохранением уже данных ответов

Рис.3.1 Архитектура ПС

Приложение включает в себя четыре компонета,составляющие всей системы в

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

администратора в пункте 14 и 10 данного проекта. Как видно архитектура реализует

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

данной программной системы аттестации.

ИТА: Дизайнер-эксперт

Создание категории вопросов

Удаление категории вопросов

Изменение названия категории

Оперативное получение статистической информации по категории (количество вопросов, максимальный балл по категории)

Редактирование вопросов в категории

Встроенный текстовый редактор

Встроенный графический редактор

Возможность передачи текстовой части через буфер обмена

Возможность передачи графической части через буфер обмена

Внесение количества баллов за вариант ответа с автоматическим подсчётом общей суммы баллов за вопрос

Изменение категории вопроса

ИТА: Руководитель

Завершение сессии аттестации

Просмотр результатов аттестации

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

Сравнительный анализ результатов аттестации в каждой группе специалистов по каждой категории вопросов

Сравнительный анализ результатов аттестации по каждой категории по всем специалистам

Сравнительный анализ результатов аттестации по каждому специалисту по каждой категории

Сравнительный анализ результатов аттестации по всем вышеперечисленным пунктам в динамике с накоплением знаний.

Сервер баз данных

Автоматический контроль ссылочной целостности данных

Встроенная защита данных от несанкционированного доступа

Выполнение хранимых процедур, созданных для обработки данных

Автоматическая генерация уникального ключа

Встроенная возможность резервного копирования данных

ИТА: Администратор

Создание типа пользователя (от типа пользователя зависит доступ к каким данным открыт пользователю, связанным с этим типом)

Удаление типа пользователя

Создание пользователя и связь его с типом

Удаление пользователя

Завершение сессии аттестации (с автоматическим подсчётом результатов)

Удаление сессии аттестации (с потерей данных аттестации)

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

Сервер баз данных

Автоматический контроль ссылочной целостности данных

Встроенная защита данных от несанкционированного доступа

Выполнение хранимых процедур, созданных для обработки данных

Автоматическая генерация уникального ключа

Встроенная возможность резервного копирования данных

ИТА: Аттестация

Начало сессии аттестации

Выбор любого количества категорий, вопросы из которых задавать

Свободное перемещение по базе вопросов, с сохранением уже данных ответов

Возможность выхода из системы с сохранением всех данных ответов

Возможность продолжить сессию аттестации в любое удобное время с сохранением уже данных ответов

Рис . 3.1a Архитектура ПС

4 Разработка структуры баз данных i.Общая характеристика реляционной модели данных

Основы реляционной модели данных были впервые изложены в статье Е.Кодда [3] в 1970 г. Эта работа послужила стимулом для большого количества статей и книг, в которых реляционная модель получила дальнейшее развитие. Наиболее распространенная трактовка реляционной модели данных принадлежит К.Дейту[4]. Согласно Дейту [4], реляционная модель состоит из трех частей:

Структурной части.

Целостной части.

Манипуляционной части.

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

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

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

В данной главе рассматривается структурная часть реляционной модели.

Типы данных

Любые данные, используемые в программировании, имеют свои типы данных.

Важно! Реляционная модель требует, чтобы типы используемых данных были простыми.

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

- Простые типы данных.

- Структурированные типы данных.

- Ссылочные типы данных.

Простые типы данных

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

- Логический.

- Строковый.

- Численный.

Различные языки программирования могут расширять и уточнять этот список, добавляя такие типы как:

- Целый.

- Вещественный.

- Дата.

- Время.

- Денежный.

- Перечислимый.

- Интервальный.

- И т.д.…

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

Структурированные типы данных

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

- Массивы

- Записи (Структуры)

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

называемое множеством индексов. Отображение

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

Запись (или структура) представляет собой кортеж из некоторого декартового произведения множеств. Действительно, запись представляет собой именованный упорядоченный набор элементов , каждый из которых принадлежит типу . Таким образом, запись есть элемент множества . Объявляя новые типы записей на основе уже имеющихся типов, пользователь может конструировать сколь угодно сложные типы данных.

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

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

Работая же с простыми типами данных, например с числовыми, мы манипулируем ими как неделимыми целыми объектами. Чтобы "увидеть", что числовой тип данных на самом деле сложен (является набором битов), нужно перейти на более низкий уровень абстракции. На уровне программного кода это будет выглядеть как ассемблерные вставки в код на языке высокого уровня или использование специальных побитных операций.

Ссылочные типы данных

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

Типы данных, используемые в реляционной модели

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

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

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

Домены

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

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

Домен имеет уникальное имя (в пределах базы данных).

Домен определен на некотором простом типе данных или на другом домене.

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

Домен несет определенную смысловую нагрузку.

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

Если тип данных можно считать множеством всех возможных значений данного типа, то домен напоминает подмножество в этом множестве.

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

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

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

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

Отношения, атрибуты, кортежи отношения Определения и примеры

Фундаментальным понятием реляционной модели данных является понятие отношения. В определении понятия отношения будем следовать книге К. Дейта

Определение 1. Атрибут отношения есть пара вида .

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

Определение 2. Отношение , определенное на множестве доменов (не обязательно различных), содержит две части: заголовок и тело.

Заголовок отношения содержит фиксированное количество атрибутов отношения:

Тело отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида :

таких что значение атрибута принадлежит домену

Отношение обычно записывается в виде:

,

или короче

,

или просто

.

Число атрибутов в отношении называют степенью отношения.

Мощность множества кортежей отношения называют мощностью отношения.

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

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

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

Предварительная структура базы данных, нормализация

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

Таблица 4.1 Поля таблицы QUESTIONS

QUESTIONS – список вопросов
ID	Integer	Идентификатор вопроса
Q_TEXT	BLOB	Текст вопроса
QPICTURE	BLOB	Граф. часть к вопросу
CID	INTEGER	Категория вопроса
Q1	SMALLINT	Балл за вариант ответа
Q2	SMALLINT	Балл за вариант ответа
Q3	SMALLINT	Балл за вариант ответа
Q4	SMALLINT	Балл за вариант ответа
Q5	SMALLINT	Балл за вариант ответа
Q6	SMALLINT	Балл за вариант ответа
Q7	SMALLINT	Балл за вариант ответа
Q8	SMALLINT	Балл за вариант ответа
Q9	SMALLINT	Балл за вариант ответа

Таблица 4.2 Поля таблицы USERS

USERS – список специалистов
ID	INTEGER	Идентификатор специалиста
GID	INTEGER	Принадлежность пользователя к группе
TID	INTEGER	Принадлежность пользователя к типу
LOGIN	VARCHAR	Ф.И.О специалиста
PWD	VARCHAR	Пароль специалиста

Таблица 4.3 Поля таблицы STORE

STORE – данные специалиста
ID	INTEGER	Идентификатор специалиста
UID	INTEGER	Отвечавший пользователь
CID	INTEGER	Категория вопросов
DATED	VARCHAR	Дата аттестации
PERCS	SMALLINT	Результат в %

Таблица 4.4 Поля таблицы TYPES

TYPES – Типы пользователя
ID	INTEGER	Идентификатор пользователя
FLAGS	INTEGER	Признак ответа
NAME	VARCHAR	Название типа

Таблица 4.5 Поля таблицы QGROUPS

QGROUPS – Категории вопросов
ID	INTEGER	Идентификатор пользователя
NAME	VARCHAR	Категория вопроса

Таблица 4.6 Поля таблицы GROUPS

QGROUPS – Группы пользователей
ID	INTEGER	Идентификатор пользователя
NAME	VARCHAR	Категория группы

Таблица 4.7 Поля таблицы ASESSIONS

ASESSIONS – Активные сессии
ID	INTEGER	Идентификатор пользователя
UID	INTEGER	Отвечавший пользователь
NAME	VARCHAR	Ф.И.О пользователя
CHOOSENGROUPS	BLOB	Номера выбранной категории
GROUPSRP	BLOB	Формат отвеченных вопросов

Нормализация

Отношение находится в Первой Нормальной Форме (1НФ), если оно содержит только скалярные (атомарные) значения [ ].

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

Замечание. Если потенциальный ключ отношения является простым, то отношение автоматически находится в 2 НФ.

Окончательная структура базы данных

Структура базы данных разработана с использованием Case-средства фирмы Platinum – ErWin 3.5.2. и представлена на рисунке 4.1. Описания таблиц базы данных даны в таблице 4.8.

Рис. 4.1 Структура базы данных

Таблица 4.8 Описание таблиц

Название таблицы	Назначение	Примечание
QGROUPS	Список категорий вопросов	Для этой таблицы создан генератор и триггер для получения уникального идентификатора
QESTIONS	Список вопросов	Для этой таблицы создан генератор и триггер для получения уникального идентификатора
USERS	Список специалистов, имя и пароль	Для этой таблицы создан генератор и триггер для получения уникального идентификатора
GROUPS	Список групп специалистов	Для этой таблицы создан генератор и триггер для получения уникального идентификатора
TYPES	Список типов пользователей.	Для этой таблицы создан генератор и триггер для получения уникального идентификатора
ASESSION	Хранит признак открытой сессии специалистом и дату/время начала сессии

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

5 Технология проведения аттестации с использованием

данной системы.

a.Технология проведения аттестации на ОАО «Троицкая ГРЭС» и ее недостатки.

На данный момент, на ОАО «Троицкая ГРЭС» действует следующий порядок проведения аттестации ИТ-специалистов рисунок 2.1:

Руководитель группы АСУ готовит вопросы для проведения аттестации.

Назначается срок аттестации и формируется состав комиссии

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

Комиссия проверяет ответы на вопросы и делает заключение по каждому специалисту

Заключения передаются руководителю группы АСУ

Рис 5.1 Порядок проведения аттестации

По составленным заключениям и выносятся соответствующие административные решения:

- О служебном продвижении

- Об изменении характера трудовых обязанностей

- Об изменении оплаты труда или иных материальных условий

- О направлении на учебу

- О необходимости повторной аттестации

В ходе анализа процесса аттестации были выявлены следующие недостатки существующего порядка проведения аттестации:

- Сложно выбрать подходящее время для проведения аттестации,не нарушив

при этом рабочий график всех участвующих (комиссия и специалисты).

- Потеря времени на подготовку вопросов руководителем.

- Нет определённого критерия выбора вопросов для проведения аттестации.

- Как правило, не учитываются реальные задачи, выполняемые

специалистами.

- Неоднозначность оценки результатов аттестации, влияние субъективного

мнения.

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

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

b.Технология проведения аттестации с использованием данной системы.

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

Ситуация: Приём на работу специалиста.

Провести аттестацию кандидатов, построить отчёт по специалистам, выбрать кандидата с максимальным баллом во всех категориях.

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

должности

Построить отчёт по группам специалистов , выбрать специалистов с максимальным баллом в группе. Присвоить

соответствующую категорию или разряд прошедшему проверку в полном объеме.

Рис. 5.2 Варианты использования системы

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

-О служебном продвижении

-Степень готовности специалиста к работе на новом рабочем месте, в

новой должности

-Об изменении характера трудовых обязанностей

-Возможности специалистов приспособится к новым условиям работы

-Какие специалисты требуют большей подготовки

-О взаимозаменяемости специалистов

-О направлении на учебу

-О необходимости повторной аттестации

-Оценить результаты программ обучения персонала

-Об изменении оплаты труда или иных материальных условий

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

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

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

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

Тем самым были исключены некоторые недостатки обычного порядка проведения аттестации ИТ-специалистов, однако некоторые ещё остались.

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

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

Такой подход подготовки вопросов даёт ряд преимуществ:

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

- Со временем накапливаются информация о том, что конкретно должен знать специалист, работающий над той или иной задачей

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

- Результаты аттестации могут помочь в составлении графика отпусков

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

Преимущества проведения аттестации с использованием системы аттестации ИТ – специалистов в целом:

-Оперативность – нет необходимости собирать комиссию и становиться

реальным быстрое получение результатов проверки

-Объективность – независимость от частного мнения и отдельных суждений

- Надёжность – свобода от влияния ситуативных факторов

- Достоверность – оценивается реальный уровень владения навыками

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

- Комплексность – оценивается весь круг задач выполняемых на предприятии ИТ-специалистами

Специалист

Руководитель

Результаты

Подготовка вопросов

Аттестация

Подготовка вопросов

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

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

- Со временем накапливаются информация о том, что конкретно должен знать специалист, работающий над той или иной задачей

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

- Результаты аттестации могут помочь в составлении графика отпусков

Специалист

- Объективность – независимость от частного мнения и отдельных суждений

- Надёжность – свобода от влияния ситуативных факторов

- Достоверность – оценивается реальный уровень владения навыками

- Прогнозтичность – данные о том, к каким видам задач специалист способен потенциально

- Комплексность – оценивается весь круг задач выполняемых на предприятии ИТ-специалистами

Рис. 5.3 Процесс аттестации при внедрении программной системы

6 Разработка компонент программной системы в среде Delphi 7.0

В состав системы входят следующие компоненты:

- Сервер баз данных Interbase для платформы Linux-x86

- Рабочее место администратора системы

- Рабочее место дизайнера-эксперта

- Рабочее место проведения аттестации

- Рабочее место руководителя

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

Возможности:

- Создание типа пользователя (от типа пользователя зависит доступ к каким данным открыт пользователю, связанным с этим типом)

- Удаление типа пользователя

- Создание пользователя и связь его с типом

- Удаление пользователя

-Завершение сессии аттестации (с автоматическим подсчётом результатов)

- Удаление сессии аттестации (с потерей данных аттестации)

- Получение оперативной информации о состоянии сервера баз данных

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

Возможности:

- Завершение сессии аттестации

- Просмотр результатов аттестации

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

а) Сравнительный анализ результатов аттестации в каждой группе специалистов по каждой категории вопросов

б) Сравнительный анализ результатов аттестации по каждой категории по всем специалистам

в) Сравнительный анализ результатов аттестации по каждому специалисту по каждой категории

г) Сравнительный анализ результатов аттестации по всем вышеперечисленным пунктам в динамике с накоплением знаний.

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

Возможности:

- Создание категории вопросов

- Удаление категории вопросов

- Изменение названия категории

- Оперативное получение статистической информации по категории (количество вопросов, максимальный балл по категории)

- Редактирование вопросов в категории

а) Встроенный текстовый редактор

б) Встроенный графический редактор

в) Возможность передачи текстовой части через буфер обмена

г) Возможность передачи графической части через буфер обмена

- Внесение количества баллов за вариант ответа с автоматическим подсчётом общей суммы баллов за вопрос

- Изменение категории вопроса

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

Возможности:

- Начало сессии аттестации

- Выбор любого количества категорий, вопросы из которых задавать

- Свободное перемещение по базе вопросов, с сохранением уже данных ответов

- Возможность выхода из системы с сохранением всех данных ответов

- Возможность продолжить сессию аттестации в любое удобное время с сохранением уже данных ответов

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

Возможности (использованные):

- Автоматический контроль ссылочной целостности данных

-Встроенная защита данных от несанкционированного доступа

- Выполнение хранимых процедур, созданных для обработки данных

- Автоматическая генерация уникального ключа

- Встроенная возможность резервного копирования данных

Общие возможности для всех компонент системы:

- Однотипная регистрация в системе личным именем пользователя и паролем

- Автоматическое сжатие данных при передаче на сервер баз данных (текстовая и графическая часть вопроса), с использованием алгоритма адаптивного сжатия Хаффмена

- Автоматическая распаковка сжатых данных при приёме с сервера баз данных (текстовая и графическая часть вопроса)

- Работа всех компонент в корпоративной сетевой среде либо в сети Internet

Обоснование выбора сервера баз данных Interbase:

- Поддерживает архитектуру клиент-сервер

- Поддерживает процедурное расширение языка SQL

- Не сложен в установке и настройке

- Компактен

Обоснование выбора серверной платформы

- С финансовой точки зрения Linux обладает одним весьма существенные, достоинством — она не коммерческая. В отличие от операционной системы Unix, Linux распространяется бесплатно по генеральной открытой лицензии GNU в рамках Фонда бесплатного программного обеспечения (Free Software Foundation), благодаря чему эта ОС доступа всем желающим.

- Система Linux отличается высокой произ­водительностью и гибкостью и предоставляет все средства Unix, включая возможность работы в многозадачном и многопользовательском режимах.

- Высокая надёжность

- Развитая сетевая архитектура

7 Формирование отчетов Отчеты формируются на основе результатов полученных при закрытии сессии . На рисунке 7.1 и 7.2 представлены формы формирования отчетов программной системы.

Рис.7.1 Формирование отчетов из ITA-Руководитель

Рис.7.2 Формирование отчетов с выводом результатов

Решение проблемы защиты информации