Разработка автоматизированной подсистемы учета разрабатываемых программных продуктов специалистами ООО "Система" для сторонних организаций на базе Borland Delphi 7

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

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

Одной из вычислительных моделей, изначально связанной с концепцией открытых систем, является модель клиент/сервер. Эта модель широко применяется в технологии БД.

Основной принцип технологии клиент/сервер применительно к технологии БД заключается в разделении функций стандартного интерактивною приложения на 5 групп, имеющих различную природу [11]:

а) функции ввода и отображения данных (Presentation Logic);

б) прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);

в) функции обработки данных внутри приложения (Database Logic);

г) функции управления информационными ресурсами (Database Manager System);

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

Модели клиент/сервер бывают двухуровневые и трехуровневые [12].

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

Рисунок 3.2 - Двухуровневая модель клиент/сервер

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

На рисунке 3.3 показана трехуровневая модель клиент/сервер. Здесь клиент -- это пользовательский интерфейс к данным, а данные находятся на удаленном сервере. Клиентское приложение делает запросы для получения доступа или изменения данных через сервер.

Рисунок 3.3 - Трехуровневая модель клиент сервер

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

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

3.2.3 Постановка задач в составе каждого функционального элемента

Для выявления задач, в составе каждого функционального элемента подсистемы учета разрабатываемых программных продуктов специалистами фирмы ООО «Система», выявим сначала функциональные элементы:

а) ведение справочников;

б) учет разрабатываемых программных продуктов;

в) формирование отчетов;

г) дополнительные функции.

Первым функциональным элементом являются справочники, рассмотрим подробнее виды справочников:

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

б) справочник медицинских полюсов. Этот справочник необходим для хранения информации о полюсах, их типах, а так же учреждений их выдающих;

в) справочник краев и областей. Справочник содержит список субъектов Российской Федерации. Используется для присвоения адресов, как сотрудникам, так и фирмам-заказчикам;

г) справочник городов. Справочник хранит список городов, присвоенных определенному субъекту Российской Федерации. Назначение - аналогично преведущему справочнику;

д) справочник улиц. Справочник хранит список улиц, закрепленных за определенным городом. Назначение - аналогично приведущему справочнику;

е) справочник проектов. Самый объемный справочник автоматизированной подсистемы. Хранит полную информацию о разрабатываемых фирмой ООО «Система» программных продуктах: номер проекта, его короткое название, дата начала работы над проектом, дата сдачи, бюджет, календарный план, словом всю информацию, которая хоть каким-то образом причастна к проекту;

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

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

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

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

а) создание проекта;

б) закрепление за проектом фирмы-заказчика;

в) закрепление за проектом компетентных лиц, со стороны фирмы-заказчика;

г) формирование рабочей группы разработчиков;

д) создание поэтапного календарного плана на реализацию проекта;

е) составление списка документации.

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

а) формирование отчета по сотрудникам фирмы ООО «Система», т.е. список сотрудников с общей информацией (фамилия, имя, телефон, должность);

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

в) формирование отчета о проектах, аналогично с отчетом о сотрудниках - список проектов с краткой информацией;

г) детальный отчет о проекте - полная информация о выбранном проекте;

д) формирование отчета о фирмах заказчиках.

Рисунок 3.4 - Функциональная структура подсистемы «Учет разрабатываемых программных продуктов»

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

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

3.3 Проектирование информационной базы данных

3.3.1 Анализ предметной области и построение инфологической и даталогической моделей базы данных

Одним из способов моделирования баз данных является построение инфологической модели. Концептуальное (инфологическое) проектирование -- построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции [13]. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.

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

Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных [13]. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).

Для построения модели «сущность-связь» (ER-модели) необходимо ввести понятие «связь» и определить типы связи между сущностями в проектируемой базе данных.

Связь - ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой [14]. Однако одно из основных требований к организации базы данных - это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи.

Между двумя сущностям, например, А и В возможны четыре вида связей.

Связь один-к-одному (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или О представителей сущности В.

Связь один-ко-многим (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи: многие-к-одному (М:1) и многие-ко-многим (M:N).

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

В ER-моделях сущности изображаются помеченными прямоугольниками, ассоциации - помеченными ромбами или шестиугольниками, атрибуты - помеченными овалами, а связи между ними -ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово «много») и необходимое пояснение [15].

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

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

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

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

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

В таблице 3.3 отражено описание таблиц, полей и дополнительная информация относительно датологической модели.

Таблица 3.3 - Таблицы, типы полей, описания

Наименование таблицы	Описание
Наименование атрибута	Тип данных	NULL опция	Первичный ключ	Внешний ключ	Описание
1	2	3	4	5	6
portfolio	Портфолио сотрудника
pf_id	integer	NOT NULL	Да	Нет	уникальный номер портфолио
wk_id	integer	NOT NULL	Нет	Да	уникальный номер сотрудника
pf_inc_name	text	NULL	Нет	Нет	название организации
pf_date_s	date	NULL	Нет	Нет	дата поступления на работу
pf_date_po	date	NULL	Нет	Нет	дата увольнения
pf_function	text	NULL	Нет	Нет	должность
pf_xor	text	NULL	Нет	Нет	характеристика
pasports	Паспортные данные сотрудника
wk_id	integer	NOT NULL	Нет	Да	уникальный номер сотрудника
pas_serial	integer	NULL	Да	Нет	серия паспорта
pas_number	integer	NULL	Да	Нет	номер паспорта
pas_date_v	date	NULL	Нет	Нет	дата выдачи
pas_kem	text	NULL	Нет	Нет	кем выдан
wk_birthday	date	NULL	Нет	Нет	день рождения
polis	Типы полюсов
pol_id	integer	NOT NULL	Да	Нет	уникальный номер типа полиса
pol_type	text	NULL	Нет	Нет	тип полиса
pol_inc	text	NULL	Нет	Нет	название организации страховщика
polis_wk	Полис сотрудника
wk_id	integer	NOT NULL	Да	Да	уникальный номер сотрудника
pol_id	integer	NOT NULL	Нет	Нет	уникальный номер типа полиса
pol_number	integer	NULL	Нет	Нет	номер полиса
wk_adress	Адрес сотрудника
wk_id	integer	NOT NULL	Да	Да	уникальный номер сотрудника
strace_id	integer	NOT NULL	Нет	Да	уникальный номер улицы
dom_number	integer	NULL	Нет	Нет	номер дома
dom_korp	text	NULL	Нет	Нет	корпус
kv_number	integer	NULL	Нет	Нет	номер квартиры
worker	Список сотрудников
wk_id	integer	NOT NULL	Да	Нет	уникальный номер сотрудника
wk_first_name	text	NULL	Нет	Нет	фимилия
wk_last_name	text	NULL	Нет	Нет	имя
wk_last_name_2	text	NULL	Нет	Нет	отчество
wk_function	text	NULL	Нет	Нет	должность
wk_phone	text	NULL	Нет	Нет	телефон
type_wk	Права доступа
wk_id	integer	NOT NULL	Да	Да	уникальный номер сотрудника
tu_id	integer	NOT NULL	Нет	Да	уникальный номер типа пользователея
wk_pas	text	NOT NULL	Нет	Нет	пароль
type_user	Тип пользователя
tu_id	integer	NOT NULL	Да	Нет	уникальный номер типа пользователея
tu_name	text	NULL	Нет	Нет	название типа пользователея
plan	Календарный план
pj_id	integer	NOT NULL	Нет	Да	уникальный номер проекта
pl_id	integer	NOT NULL	Да	Нет	уникальный номер работы
pl_name	text	NULL	Нет	Нет	название работы
pl_date_begin	date	NULL	Нет	Нет	дата начала
pl_date_end	date	NULL	Нет	Нет	дата окончания
xod_work	Ход работы
pl_id	integer	NOT NULL	Да	Нет	уникальный номер работы
wk_id	integer	NOT NULL	Нет	Да	уникальный номер сотрудника
xw_date_begin	date	NULL	Нет	Нет	дата начала
xw_date_end	date	NULL	Нет	Нет	дата окончания
workgroup	Рабочая группа
pj_id	integer	NOT NULL	Да	Да	уникальный номер группы
wk_id	integer	NOT NULL	Да	Да	уникальный номер сотрудника
stadt	Субъет РФ
st_id	integer	NOT NULL	Да	Нет	уникальный номер субъекта
st_name	text	NULL	Нет	Нет	название субъекта
city	Город
st_id	integer	NOT NULL	Нет	Да	уникальный номер субъекта
city_id	integer	NOT NULL	Да	Да	уникальный номер города
city_name	text	NULL	Нет	Нет	название города
strace	Улица
city_id	integer	NOT NULL	Нет	Да	уникальный номер города
strace_id	integer	NOT NULL	Да	Да	уникальный номер улицы
strace_name	text	NULL	Нет	Нет	название улицы
projekt	Список проектов
pj_id	integer	NOT NULL	Да	Нет	уникальный номер проекта
inc_id	integer	NOT NULL	Нет	Да	уникальный номер организации
pj_name	text	NULL	Нет	Нет	название проекта
pj_date_create	date	NULL	Нет	Нет	дата поступления
pj_date_end	date	NULL	Нет	Нет	дата сдачи
pj_price	integer	NULL	Нет	Нет	цена
inc_adress	Адрес организации
inc_id	integer	NOT NULL	Да	Да	уникальный номер организации
strace_id	integer	NOT NULL	Нет	Да	уникальный номер улицы
dom_number	integer	NULL	Нет	Нет	номер дома
dom_korp	text	NULL	Нет	Нет	корпус
office_number	integer	NULL	Нет	Нет	номер офиса
docs	Документация
pj_id	integer	NOT NULL	Нет	Да	уникальный номер проекта
doc_id	integer	NOT NULL	Да	Нет	уникальный номер документа
doc_name	text	NULL	Нет	Нет	название документа
doc_msg	text	NULL	Нет	Нет	описание документа
person	Контактные лица
pj_id	integer	NOT NULL	Нет	Да	уникальный номер проекта
ps_id	integer	NOT NULL	Да	Нет	уникальный номер контактного лица
ps_first_name	text	NULL	Нет	Нет	фамилия
ps_last_name	text	NULL	Нет	Нет	имя
ps_last_name2	text	NULL	Нет	Нет	отчество
ps_phone	text	NULL	Нет	Нет	телефон
ps_email	text	NULL	Нет	Нет	электронный адрес
ps_role	text	NULL	Нет	Нет	роль в проекте
incorporation	Организация
inc_id	integer	NOT NULL	Да	Нет	уникальный номер организации
inc_name	text	NULL	Нет	Нет	название организации
inc_phone	text	NULL	Нет	Нет	телефон
inc_ogrn	integer	NULL	Нет	Нет	ОГРН
inc_inn	integer	NULL	Нет	Нет	ИНН

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

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

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

Итак, сформулируем основные требования, к выбору СУБД, для автоматизированной подсистемы учета разрабатываемых программных продуктов:

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

б) работа на платформах Win32, Linux - кросплатформеность важный критерий отбора системы управления базами данных, т.к. в фирме ООО «Система» используются компьютеры под управлением различных операционных систем;

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

г) стоимость - для фирмы ООО «Система» особо важным является цена используемого программного обеспечения и как для любой коммерческой организации, чем ниже эта цена, тем лучше;

д) безопасность - в данном случае подразумевается защита, прежде всего от взломов, с программой будут работать инженеры-программисты, поэтому уровень безопасности должен быть на высоте;

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

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

Таблица 3.5 - Сводная таблица характеристик СУБД

Наименование параметра	PostgreSQL	MySQL	MS SQL Server	Firebird
1	2	3	4	5
Скорость	-	-	+	+
Работа на платформах Win32, Linux	+	+	-	+
Поддержка пользователей	+	+	+	+
Стоимость	+	-	-	+
Безопасность	+	+	+	+
Архитектура клиент-сервер	+	+	+	+
Надёжность	+	-	+	+

Как видно из таблицы 3.5 наиболее подходящей системой управления базами данных, в условия решаемой задачи является - FireBird.

3.3.3 Разработка запросов к базе данных

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

SELECT worker.wk_first_name, worker.wk_last_name, worker.wk_last_name_2, worker.wk_birthday, worker.wk_function, worker.wk_phone, wk_adress.strace_id, wk_adress.dom_number, wk_adress.dom_korp, wk_adress.kv_number, strace.city_id, strace.strace_id, strace.strace_name, city.st_id, city.city_id, city.city_name

from worker

inner join wk_adress on (worker.wk_id = wk_adress.wk_id)

inner join strace on (wk_adress.strace_id = strace.strace_id)

inner join city on (strace.city_id = city.city_id) inner join stadt on (city.st_id = stadt.st_id).

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

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

delete from WK_ADRESS where WK_ID = :OLD_WK_ID.

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

update WORKER set WK_ID = :WK_ID, WK_FIRST_NAME = :WK_FIRST_NAME, WK_LAST_NAME = :WK_LAST_NAME, WK_LAST_NAME_2 = :WK_LAST_NAME_2, WK_FUNCTION = :WK_FUNCTION, WK_PHONE = :WK_PHONE where WK_ID = :OLD_WK_ID

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

insert into WORKER (WK_ID, WK_FIRST_NAME, WK_LAST_NAME, WK_LAST_NAME_2, WK_FUNCTION, WK_PHONE) values (:WK_ID, :WK_FIRST_NAME, :WK_LAST_NAME, :WK_LAST_NAME_2, :WK_FUNCTION, :WK_PHONE).

3.3.4 Разработка системы разграничения доступа к данным

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

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

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

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

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

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

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

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

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

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

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

Таким образом, с точки зрения безопасности самыми опасными являются два типа пользователей: аналитики и администраторы.

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

Таким образом, обеспечение безопасности разрабатываемой автоматизированной подсистемы учета можно решить штатными средствами СУБД FireBird.

3.4 Описание средств обеспечения достоверности и целостности информации

Главная особенность SQL-технологий наличие у сервера СУБД специальных средств контроля целостности данных, не зависящих от клиентских программ и привязанных непосредственно к таблицам [17]. Т.е. принципиально не важно, каким образом осуществляется доступ к базе данных: через SQL-консоль, через ODBC-драйвера из приложения Windows, через WWW-connector из Internet-браузера или через DBI-интерфейс Perl. В любом из этих случаев, за контролем целостности данных следит сервер, и при нарушении правил целостности данных сервер известит клиента об ошибке.

К структурам контроля целостности данных относятся ограничители (constraint), которые привязаны к столбцам и триггеры (trigger), которые могут быть привязаны как к столбцам, так и к строкам в таблице.

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

Firebird содержит следующие ограничители:

а) NOT NULL - проверка на непустое значение. NULL - специальное понятие в СУБД, которое означает "пусто";

б) UNIQUE - проверка на уникальность. Вставляемое значение должно быть уникально для данного столбца по всей таблице. Может содержать пустые значения;

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

SQL-технология позволяет на уровне столбца задавать домены значений, т.е. строго определенные наборы или диапазоны значений, для помещаемых в столбец данных. В частности можно реализовывать ограничения ссылочной целостности (referential integrity constraint) и проверки фиксированного условия. Ограничение ссылочной целостности не позволяет значениям из столбца одной таблицы принимать значения кроме как из присутствующих в столбце другой таблицы. Это делается при помощи ограничителей FOREIGN KEY (внешний ключ) и REFERENCES (указатель ссылки). Таблица, содержащая FOREIGN KEY, считается родительской таблицей. Таблица, содержащая REFERENCES, считается дочерней таблицей. Внешний ключ и указатель ссылки могут находиться в одной таблице, т.е. родительская таблица одновременно является дочерней.

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

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

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

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

CHECK - проверка фиксированного условия. В данном ограничителе явно указывается условие, которое должно выполняться для вставляемого или модифицируемого значения в столбце. Например: check (user in 'ALEX','JUSTAS') - в столбце user могут содержаться только значения 'ALEX' и 'JUSTAS', попытка вставки значения 'SHTIRLITZ' будет интерпретирована как ошибочная , check (user_salary between 1000 and 5000) - столбец user_salary может принимать целочисленные значения в диапазоне от 1000 до 5000 и т.д. При формировании условий с некоторыми ограничениями могут использоваться функции, например check (user = upper(user)), в данном случае имя пользователя должно вводиться только в верхнем регистре. Есть и ограничения, например, CHECK не может содержать подзапросы (SELECT).

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

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

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

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

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

Выводы по главе

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

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

Размещено на http://www.allbest.ru/

4. Описание подсистемы «Учет разрабатываемых программных продуктов»

4.1 Условия применения

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

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

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

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

а) информация о сотрудниках фирмы ООО «Система»;

б) информация о разработанных и находящихся в разработке программных продуктах;

в) информация о фирмах-заказчика и контактных лицах - представителях этих фирм.

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

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

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

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

Третий вид информации хранимый в базе: информация о фирмах-заказчика и контактных лицах - представителях этих фирм, представляет из себя следующие значения: название фирмы-заказчика, телефон, ОГРН, ИНН, юридический адрес (край или область, город, улица, номер дома, корпус, номер офиса), фамилия, имя, отчество контактного лица, телефон, его роль в проекте, e-mail. Автоматизированная подсистема учета разработана таким образом, что для одного проекта можно назначить произвольное число автономных контактных лиц.

Подсистема имеет возможность формировать несколько видов отчетов:

а) список сотрудников;

б) сотрудник детально;

в) список проектов;

г) все о проекте;

д) список фирм-заказчиков.

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

Перейдем к рассмотрению технических сторон автоматизированной подсистемы. Подсистема корректно работает на компьютерах под управлением операционной системы Windows XP, 2000, 2003 Server, 2008 Server, Vista, Seven.

Минимально необходимая конфигурация для корректного функционирования программы-клиента: процессор Pentium I с тактовой частотой 233 МГц, 64 Мб оперативной памяти, разрешение экрана 800х600. Как видно, клиентская часть автоматизированной подсистемы не требовательна к ресурсам. Кроме того, для работы клиента не требуется стороннего программного обеспечения, кроме естественно операционной системы.

Что же касается минимально необходимой конфигурации сервера:

а) процессор: 800 МГц

б) оперативная память: 256 Мб

в) свободное дисковое пространство: 250 Мб и выше

г) операционная система: семейство Microsoft Windows NT (x86 или x64) или Linux.

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

4.2 Руководство программиста

Клиентом в автоматизированной подсистеме выступает прикладное приложение написанное на языке программирования высокого уровня - Borland Delphi 7 Enterprise, в качестве сервера выступает система управления базами данных FireBird 2.5.

Delphi - среда программирования, в которой используется язык программирования Object Pascal. Начиная со среды разработки Delphi 7.0, в официальных документах Borland стала использовать название Delphi для обозначения языка Object Pascal [18].

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

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

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

Очевидно, что для корректной работы автоматизированной подсистемы учета разрабатываемых программных продуктов специалистами фирмы ООО «Система», необходимо:

а) установить необходимой программное обеспечение на сервере;

б) установить клиентское программное обеспечение на клиентских рабочих станциях.

Установка и настройка серверной части:

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

Запускаем установщик FireBird 2.5, во всех диалоговых окнах установки нажимаем кнопку «Далее», в плоть до шага 4, представленного на рисунке 4.1.

Рисунок 4.1 - Четвертый шаг установки СУБД FireBird 2.5

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

Нажимаем кнопку далее, в плоть до окна, изображенного на рисунке 4.2.

Рисунок 4.2 - Дополнительные задачи FireBird 2.5

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

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

Последним шагом, выполняемым в настройке сервера, является запуск службы СУБД. На компьютерах находящихся под управлением операционной системы Windows, для запуска службы можно воспользоваться штатными средствами, а именно: Пуск -> Панель управления -> Администрирование -> Службы, в появившемся списке служб необходимо выбрать Firebird Server и запустить ее.

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

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

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

Рисунок 4.3 - Диалоговое окно авторизации

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

Рисунок 4.4 - Главное окно программы

Рассмотрим основные пункты меню программы:

а) файл;

б) сотрудники:

- список сотрудников;

- личная информация;

- портфолио;

в) проекты:

- список проектов;

- контактные лица;

- календарный план;

- документация;

г) отчетность:

- сотрудники;

- список сотрудников;

- карточка сотрудника;

- проекты;

- список проектов;

- карточка проекта;

а) окно:

- каскадом;

- плиткой;

- закрыть все.

Пункт меню Файл, содержит системные функции для работы с программой.

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

Для работы со списком сотрудников необходимо выбрать пункт меню Сотрудники -> Список сотрудников, в результате чего на экране отобразится форма: «Список сотрудников фирмы ООО «Система», изображенная на рисунке 4.5.

Рисунок 4.5 - Список сотрудников ООО «Система»

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

Для выполнения операций над записями таблицы, используется специальный навигационный элемент, представленный на рисунке 4.6 (обведен в красную рамку).

Рисунок 4.6 - Навигационный элемент таблицы

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

Таблица 4.1 - Кнопки навигационного элемента и их назначение

Кнопка	Назначение
К первой	Указатель текущей записи перемещается к первой записи файла данных
К предыдущей	Указатель текущей записи перемещается к предыдущей записи файла данных
К следующей	Указатель текущей записи перемещается к следующей записи файла данных
К последней	Указатель текущей записи перемещается к последней записи файла данных
Добавить	В файл данных добавляется новая запись
Удалить	Удаляется текущая запись файла данных
Редактирование	Устанавливает режим редактирования текущей записи
Сохранить	Изменения, внесенные в текущую запись, записываются в файл данных
Отменить	Отменяет внесенные в текущую запись изменения
Обновить	Записывает внесенные изменения в файл

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

Данное диалоговое окно содержит две кнопки: OK и Cancel. Удалить и отменить действие соответственно. После нажатия на кнопку ОК произойдет удаление выбранного сотрудника. Кроме удаления данных о сотрудники отображаемых в таблице, удалятся, и все записи, где он участвует.

Аналогично с удалением и процедура вставки нового сотрудника. Для добавления нового сотрудника необходимо, в навигационном элементе нажать на кнопку «плюс». После, чего в таблицу добавится новая строка, в которую необходимо ввести информацию о сотруднике. Номер сотруднику присваивается автоматически.

Рисунок 4.7 - Удаление сотрудника

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

Любой столбец таблицы можно отсортировать как по убыванию, так и по возрастанию, кроме того можно применить быстрые фильтры к столбцу, щелкнув на его шапку, рисунок 4.8.

Как описано выше, кроме основной информации, каждый сотрудник имеет и другую информацию (паспортные данные, адрес проживания, портфолио и т.д.).

Для просмотра этой информации, а так же для ее редактирования необходимо перейти на вкладку: Личная информация или Портфолио, соответственно.

Рисунок 4.8 - Сортировка и фильтрация столбца

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

Рисунок 4.9 - Личная информация сотрудника

На данной вкладке, как видно на рисунке 4.9, представлена такая информация как: адрес проживания (улица, номер дома, номер квартиры и т.д), а так же паспортные данные сотрудника (номер, серия, кем выдан, дата выдачи), а так же данные медицинского страхового полиса.

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

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

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

Рисунок 4.10 Опыт работы выбранного сотрудника

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

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

Рисунок 4.11 - Быстрое переключение между сотрудниками

Пункты меню Сотрудники -> Личная информация и Сотрудники -> Портфолио, являются альтернативным (и более быстрым), способа перехода на одноименные вкладки автоматизированной подсистемы.

При выборе любого из этих пунктов, появляется диалоговое окно выбора сотрудника, изображенное на рисунке 4.12.

Рисунок 4.12 - Диалог выбора сотрудника

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

Рассмотрим процесс работы с информацией о проектах. Вся информация о проектах представлена на 4 вкладках: список проектов, контактные лица, календарный план, документация.

Рассмотрим более подробно первую вкладку - список проектов. Для просмотра, изменения, добавления и удаления основной информации о проекте, необходимо воспользоваться пунктом меню: Проекты -> Список проектов. После выбора этого пункта появится форма, представленная на рисунке 4.13.

Рисунок 4.13 - Список проектов фирмы ООО «Система»

В данной таблице отображаются все проекты, выполненные или выполняемые специалистами фирмы.

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

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

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

Рисунок 4.14 - Вкладка «Календарный план проекта»

Последней вкладкой для проектов является вкладка «Документация». Здесь представлен список документов на текущий проект: заявки на разработку, предложения на разработку, технические задания и так далее. Вкладка «Документация» проиллюстрирована на рисунке 4.15.

Рисунок 4.15 - Вкладка «Документация на проект»

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

Рассмотрим процесс получения отчета, на примере отчета «Список сотрудников». Итак, для получения отчета необходимо в меню программы выбрать пункт Отчетность -> Сотрудники -> Список сотрудников. После чего откроется новое окно, напоминающее интерфейсом Adobe Reader и изображенное на рисунке 4.16.

Рисунок 4.16 - Отчет «Список сотрудников»

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

4.4 Описание контрольного примера

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

Запустим автоматизированную подсистему учета и в первом появившемся окне (окно авторизации), введем учетные данные суперпользователя SYSDBA. Имя пользователя - SYSDBA, пароль - masterkey.

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

Рисунок 4.17 - Добавление нового сотрудника

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

Далее необходимо заполнить все поля: фамилия, имя, отчество, должность, телефон.

Обратим внимание, что поле №, заполнять не надо, это поле является первичным ключом таблицы WORKER и его значение генерируется на стороне сервера с использованием специально созданного генератора и тиггера.

После внесения необходимых данных, нужно нажать на кнопку «Готово» - данные сохранены.

Теперь создадим отчет «Список сотрудников» и проверим, появился ли в нем, только что созданный сотрудник: Иванов Иван Иванович. Для создания отчета воспользуемся пунктом меню: Отчетность -> Сотрудники -> Список сотрудников, на экране отобразится вновь созданный отчет, рисунок 4.18.

Рисунок 4.18 - Отчет «Список сотрудников»

Как видно из рисунка, последним в списке числится только что созданный сотрудник под номером 16, Иванов Иван Иванович.

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