Средства программы А ccess позволяют составить архив с полной документацией базы данных, в которую входят описание структуры таблиц, свойств их полей, характеристик форм и отчетов, инструкций SQL для запросов и другие сведения.
1. Выполните команды меню Сервис – Анализ _ Архивариус.
2. В открывшемся диалоговом окне перейдите на вкладку Текущая база данных и затем установите флажки для пунктов Свойства и Связи.
3. Нажмите кнопку ОК. Откроется окно отчета Описание объектов, на первой странице которого описаны объекты, а на второй странице - отношение объектов.
Закройте окно описание объектов.
4. Продемонстрируйте результаты работы преподавателю и закройте окно базы данных.
Самостоятельная работа
Продолжительность
Минут
· Создайте базу данных с таблицами соответственно выбранному варианту.
· Проведите оптимизацию быстродействия созданной базы данных, проведите анализ и, если требуется, внесите корректировки в созданную базу данных.
· Создайте MDE-файл созданной базы данных.
· Проведите документирование созданной и откорректированной базы данных.
Вариант 1. База данных Личная с двумя таблицами:
Дети
Сотрудники
Вариант 2. База данных Кадры с двумя таблицами:
Работники
Личная
IV. Организация баз данных в корпоративных сетях
Продолжительность: 160 мин.
Дисциплина:
Базы данных.
Цель:
Знакомство с организацией базы данных в корпоративных сетях.
Результат обучения:
После успешного завершения занятия пользователь должен:
· Научиться основным приемам организации базы данных в корпоративных сетях.
Используемые программы:
Access 2000.
План занятия:
1. Работа под руководством преподавателя 120 минут
Организация баз данных в корпоративных сетях
2. Самостоятельная работа 60 минут
Запуск программы:
Предполагается, что требуемые программы уже инсталлированы на диске.
(См. «Инструкцию по установке программы на ПК»)
Создайте на рабочем столе папку под своим именем. Дальнейшие вычисления проводите только в своей папке.
Организация баз данных в корпоративных сетях.
Рекомендуемое время
Минут
Организацию базы данных рассмотрим на примере создания информационной системы (ИС) для автоматизации работы отдела кадров, например издательства «ДУМЫ и МЫСЛИ».
На первом этапе проекта необходимо составить набор требований, предъявляемых к конечному продукту. Для этого разработчику требуется получить от заказчика как можно больше информации. Для нашего примера ограничимся рассмотрением следующих требований:
ИС Отдел кадров должна обеспечить
· ввод, хранение и обработку информации о сотрудниках, штатном расписании, движении кадров.
· выполнение всех действий, связанных с движением кадров (кадровыми операциями)
· проведение операций над штатным расписанием (штатными операциями).
· формирование документов, соответствующих произведенным операциям: приказы, распоряжения, служебные записки и т.д.
· и многое другое.
На основе этих требований и ограничений, определяются классы пользователей системы с точки зрения пользователя. Используя язык моделирования UML, можно построить диаграмму использования информационной системы Отдел кадров.
Пользователь
ИС Отдел кадров выделено три категории пользователей:
· Зав. кадрами – отвечает за управление данными о персонале организации
· Зав. штатным расписанием – отвечает за управление данными о штатном расписании
· Администратор – имеет право полного управления системой, в частности может вручную корректировать данные в таблицах.
На диаграмме показано, что все пользователи могут получать отчеты, просматривать таблицы, архивировать и обновлять данные.
Таким образом Функциональные возможности системы можно разделить на два частично пересекающихся множества и в соответствии с этим делением организовать две подсистемы:
· Управление персоналом (УП)
· Управление данными о Штатном расписание (ШР).
Подсистема Управление персоналом предназначена для работы с информацией о сотрудниках и управления движением персонала. С этой подсистемой взаимодействует внешний субъект Зав. кадрами. Подсистема Штатное расписание находится под управлением внешнего субъекта Зав. штатным расписанием. Управлять обеими подсистемами разрешено внешнему субъекту Администратору.
В соответствии с таким делением можно построить диаграммы использования подсистем.
Диаграмма использования подсистемы Управление персоналом.
 |
Диаграмма использования подсистемы Штатное расписание.
Подсистемы связаны между собой: изменение данных в одной подсистеме может повлечь изменения данных в другой. Например, сокращение штатной единицы в подсистеме Штатное расписание сопровождается увольнением сотрудника в подсистеме Управление персоналом. Для этого пользователь приложения Отдел кадров, исполняющий роль субъекта использования Зав штатным расписанием, должен потребовать выполнения соответствующей операции у пользователя, исполняющего роль субъекта использования Зав кадрами, например, отправив ему соответствующее сообщение по электронной почте.
Следующим этапом проектирования ИС является создание логической модели, которая будет состоять из трех частей:
· модель данных – описание организации данных в системе
· модель представления данных – визуальное представление данных (запросы, формы, отчеты)
· модель управления данными – проектирование интерфейса.
Следующим этапом проектирования ИС является создание физической модели. На этапе создания физической модели необходимо:
· выбрать СУБД (в данном случае будет использована MS Access 2000)
· продумать структуру создаваемых таблиц
· назначить типы полей для хранения атрибутов.
Для реализации многопользовательского доступа к данным создается сетевое распределенное приложение. При проектировании сетевого приложения необходимо учитывать специфику многопользовательского доступа и распределенной архитектуры приложения. Это означает, что необходимо продумать из каких компонентов будет состоять готовое приложение, каким образом компоненты приложения будут распределены по узлам в сети (компьютерам пользователей и серверами), как будут распределены права доступа к общим данным и какие клиентские приложения будут обслуживать пользователей.
Будем считать, что выделен сервер данных, на котором хранятся данные, и некоторое количество рабочих станций для работы пользователей, которые связаны сетью.
Для проектирования физической архитектуры приложения в UML используются диаграммы компонентов и диаграммы размещения. Исходя из того, что размещение компонентов в сети не должно привести к возникновению чрезмерной нагрузки на сеть из-за большого объема передаваемых данных, построим следующие диаграммы.
 |  | ||||
 | |||||
* 1 1 *
Диаграмма размещения приложения Отдел кадров
Приложение Отдел кадров разделено на следующие компоненты объектов данных Отдел кадров (данные) .MDB и компоненты объектов приложений Управление персоналом. MDB и Штатное расписание. MDB.
 |
Диаграмма компонентов приложения Отдел кадров.
При такой архитектуре предусматривается, что компонент объекта данных Отдел кадров(данные) хранится на сервере баз данных или просто на файл-сервере (Сервер данных). Компоненты объектов приложений Управление персоналом и Штатное расписание на соответствующих рабочих станциях, предназначенных для управления подсистемой Управление персоналом (Рабочая станция зав. кадрами) или подсистемой Штатное расписание (рабочая станция зав. штатным расписанием).
Для сохранения целостности данных при многопользовательском доступе необходимо использовать встроенные средства СУБД поддержки целостности связанных таблиц, а также выделить группы пользователей, обладающие определенными правами доступа к данным. Для примера рассмотрим права доступа к данным таблицы Личные данные.
| Название таблицы | Зав. кадрами | Зав. штатным расписанием | Администратор | Подсистема |
| Личные дела | Обновление, вставка и удаление данных | Чтение данных | Права администратора | Управление персоналом |
| Штатное расписание | Чтение данных | Обновление, вставка и удаление данных | Права администратора | Штатное расписание |
Следующий этап после проектирования – это создание прототипа приложения. Прототип позволяет продемонстрировать заказчику, как будет работать создаваемая система.
Дата: 2019-05-28, просмотров: 193.
