 |
Пример физической модели данных.
|
|
|
|
| Подразделения | Личные данные | Образование | ||||
| Код | Код | КодОбразования | ||||
| Название | Фамилия | Название | ||||
| Сокращение | Имя | |||||
| Родитель | Отчество | |||||
| Кадры | Пол | Специальность | ||||
| Табельный номер | ДатаРождения | КодСпециальности | ||||
| ШР | КодСотрудника | СемейноеПоложение | Название | |||
| Код | КатегорияСотрудника | Образование | ||||
| КодДолжности | КодШР | Специальность | ||||
| КодПодразделения | ДатаС | УченаяСтепень | УченаяСтепень | |||
| Единиц | ДатаПо | ИнЯЗ | КодСтепени | |||
| ДатаС | ПроцентОклада | Серия | Название | |||
| ДатаПО | НомерПриказа | Номер | ||||
| КемВыдан | ||||||
| ДатаВыдачи | Язык | |||||
| Должности | Адрес | КодЯзыка | ||||
| Код | Телефон | Название | ||||
| Название | КатегорииСотрудников | ЭлПочта | ||||
| Сокращение | Код | Комната | ||||
| Оклад | Название | МестныйТелефон | ||||
| Резюме | ||||||
| Фото |
Для реализации многопользовательского доступа к данным создается сетевое распределенное приложение. При проектировании сетевого приложения необходимо учитывать специфику многопользовательского доступа и распределенной архитектуры приложения. Это означает, что необходимо продумать из каких компонентов будет состоять готовое приложение, каким образом компоненты приложения будут распределены по узлам в сети (компьютерам пользователей и серверами), как будут распределены права доступа к общим данным и какие клиентские приложения будут обслуживать пользователей.
|
|
|
Будем считать, что выделен сервер данных, на котором хранятся данные, и некоторое количество рабочих станций для работы пользователей, которые связаны сетью.
Для проектирования физической архитектуры приложения в UML используются диаграммы компонентов и диаграммы размещения. Исходя из того, что размещение компонентов в сети не должно привести к возникновению чрезмерной нагрузки на сеть из-за большого объема передаваемых данных, построим следующие диаграммы.
 |  | ||||
 | |||||
* 1 1 *
Диаграмма размещения приложения Отдел кадров
Приложение Отдел кадров разделено на следующие компоненты объектов данных Отдел кадров (данные).MDB и компоненты объектов приложений Управление персоналом. MDB и Штатное расписание. MDB.
 |
Диаграмма компонентов приложения Отдел кадров.
При такой архитектуре предусматривается, что компонент объекта данных Отдел кадров (данные) хранится на сервере баз данных или просто на файл-сервере (Сервер данных). Компоненты объектов приложений Управление персоналом и Штатное расписание на соответствующих рабочих станциях, предназначенных для управления подсистемой Управление персоналом (Рабочая станция зав. кадрами) или подсистемой Штатное расписание (рабочая станция зав. штатным расписанием).
Для сохранения целостности данных при многопользовательском доступе необходимо использовать встроенные средства СУБД поддержки целостности связанных таблиц, а также выделить группы пользователей, обладающие определенными правами доступа к данным. Для примера рассмотрим права доступа к данным таблицы Личные данные.
| Название таблицы | Зав. кадрами | Зав. штатным расписанием | Администратор | Подсистема |
| Личные дела | Обновление, вставка и удаление данных | Чтение данных | Права администратора | Управление персоналом |
| Штатное расписание | Чтение данных | Обновление, вставка и удаление данных | Права администратора | Штатное расписание |
|
|
|
Следующий этап после проектирования – это создание прототипа приложения. Прототип позволяет продемонстрировать заказчику, как будет работать создаваемая система.
|
|
|
