Организация баз данных в корпоративных сетях

1. Организация баз данных в корпоративных сетях.

Рекомендуемое время

120 минут

Организацию базы данных рассмотрим на примере создания информационной системы (ИС) для автоматизации работы отдела кадров, например издательства «ДУМЫ и МЫСЛИ».

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

 ИС Отдел кадров должна обеспечить

·          ввод, хранение и обработку информации о сотрудниках, штатном расписании, движении кадров.

·          выполнение всех действий, связанных с движением кадров (кадровыми операциями)

·          проведение операций над штатным расписанием (штатными операциями).

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

·          и многое другое.

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

Пользователь

ИС Отдел кадров выделено три категории пользователей:

·        Зав. кадрами – отвечает за управление данными о персонале организации

·        Зав. штатным расписанием – отвечает за управление данными о штатном расписании

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

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

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

·        Управление персоналом (УП)

·        Управление данными о Штатном расписание (ШР).

Подсистема Управление персоналом предназначена для работы с информацией о сотрудниках и управления движением персонала. С этой подсистемой взаимодействует внешний субъект Зав. кадрами. Подсистема Штатное расписание находится под управлением внешнего субъекта Зав. штатным расписанием. Управлять обеими подсистемами разрешено внешнему субъекту Администратору.

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

Диаграмма использования подсистемы Управление персоналом.

Диаграмма использования подсистемы Штатное расписание.

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

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

·        модель данных – описание организации данных в системе

·        модель представления данных – визуальное представление данных (запросы, формы, отчеты)

·        модель управления данными – проектирование интерфейса.

Следующим этапом проектирования ИС является создание физической модели. На этапе создания физической модели необходимо:

·        выбрать СУБД (в данном случае будет использована MS Access 2000)

·        продумать структуру создаваемых таблиц

·        назначить типы полей для хранения атрибутов.

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

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

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

 * 1 1 *

Диаграмма размещения приложения Отдел кадров

Приложение Отдел кадров разделено на следующие компоненты объектов данных Отдел кадров (данные) .MDB и компоненты объектов приложений Управление персоналом. MDB и Штатное расписание. MDB.

Диаграмма компонентов приложения Отдел кадров.

При такой архитектуре предусматривается, что компонент объекта данных Отдел кадров(данные) хранится на сервере баз данных или просто на файл-сервере (Сервер данных). Компоненты объектов приложений Управление персоналом и Штатное расписание на соответствующих рабочих станциях, предназначенных для управления подсистемой Управление персоналом (Рабочая станция зав. кадрами) или подсистемой Штатное расписание (рабочая станция зав. штатным расписанием).

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

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