5 УРОВНИ ДОСТУПА К СУБД
Описание групп пользователей
В разработанной СУБД выполнены три уровня доступа: для медсестры ВУЗа, для медсестры больницы и для врача, аналогичные типам: гость, пользователь и администратор.
Медсестра ВУЗа может заходить в базу без пароля. Данный уровень доступа не позволяет вносить или редактировать какую-либо информацию. Доступными являются лишь просмотр информации и ее распечатывание.
Медсестра больницы может зайти в базу лишь под паролем. Данный доступ отличается от предыдущего доступа. Этому типу пользователя позволяется вносить и корректировать изменения в базе, но «Архив» студентов остается закрытым.
Врач (аналог администратор).Вход в базу осуществляется под паролем администратора. Имеет полный доступ ко всей базе. Права врача неограниченны. Он может редактировать структуры таблиц, изменять и удалять любые данные. Далее – более подробно о правах пользователей.
Медсестра ВУЗа
Как сказано ранее, этот пользователь заходит в базу без пароля и не имеет в ней никаких прав на изменение данных – лишь их просмотр и печать на принтере. На всех формах кнопки «Добавить запись», «Сохранить запись» и «Удалить запись» недоступны. Кнопки «Добавить Студента» и «Архив» в форме «Вход» так же недоступны. Область действий – просмотр данных из базы и распечатка их на принтере.
Медсестра больницы
Для входа в базу под правами медсестры больницы необходимо знать пароль. Права Пользователя отличаются от прав предыдущего пользователя лишь тем, что медсестра больницы имеет доступ к кнопке «Добавить студента», «Архив», «Диагностика студента», так как медсестры в больнице работают со студентами, то могут добавлять новых студентов в базу.
Врач
Для входа в базу под правами врача необходимо знать пароль администратора. Врач не имеет никаких ограничений в базе. Он может изменять, добавлять и удалять любые данные в базе, изменять структуру таблиц и форм.
ВЫВОДЫ
За время создания курсового проекта и написания пояснительной записки была досконально изучена предметная область проекта; разработана концептуальная модель БД: объект-отношение; выбрана реляционная модель для создания эффективной БД; разработаны основные модели запросов для работы с данными БД.
В БД была организована целостность данных посредством ввода каскадного удаления между некоторыми объектами. Была обеспечена защита данных посредством ввода различных групп пользователей и запроса пароля.
Также была организована архивация данных.
В результате создания данной системы, требования, изложенные в постановке задачи, выполнены.
Разработка имеет дружественный интуитивно понятный графический интерфейс, позволяющий даже с минимальным знанием компьютера провести автоматизацию учета студентов в больнице. Таким образом, система готова к эксплуатации. Она может обеспечить пользователю поступление необходимой информации, а также облегчить получение статистических наблюдений.
Разрабатываемая база позволяет получить всю необходимую информацию о студентах больницы, принимающих врачах , отчеты: по заболеваемости студентов, по временному периоду и по приму врачей; при необходимости позволяет получить информацию о проектировщике базы.
Приложение А
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
А 1 Общие сведения
А.2 Этапы разработки и сроки выполнения
Сроки выполнения приведены в таблице А.1.
А 3 Назначение и цели создания проекта
БД разрабатывается для систематизации обработки данных о больных студентах, обучающихся в ВУЗах.
Целью создания базы данных является обеспечение целостности и компактности хранимых данных, увеличение скорости получения информации об интересующих студентах, понижение трудозатрат по обработке данных.
А 3 Характеристика объекта автоматизации
А 3.1 Сведения об объекте автоматизации
Объектом автоматизации данного курсового проекта является процесс анализа, обработки, поиска, удаления и учета информации о больных студентах.
А 3.2 Сведения об условиях эксплуатации КП
Данная БД разрабатывается с использованием СУБД Access, которая оснащена инстинктивно понятным интерфейсом и может использоваться широким кругом пользователей нуждающихся в учете информации о студентах. Данной БД может пользоваться любой пользователь, умеющий пользоваться компьютером.
А 4 Требования к проекту
А 4.1 Требования к КП в целом
КП в целом должен :
-иметь обширную систему помощи, включающую сведения о КП в целом, руководство по использованию отдельных частей, корректные сообщения об ошибках пользователя, если таковые имеются; осуществлять добавление, изменение, удаление и поиск информации из имеющейся БД;
- обеспечить не избыточность, компактность, целостность хранимых данных.
А 4.2 Требования к задачам и функциям КП
Проектируемый программный продукт должен реализовывать следующие задачи:
- иметь систему помощи, т.е. выдавать корректные сообщения при ошибках, возникающих в процессе работы;
- позволять получать информацию по определённым запросам пользователя. (запросы на выборку, на добавление и удаление записей в архиве, запросы для создания пользовательских форм и отчетов. Отчетов: «Заявка о начале учета в больнице», «Прием врачей», форм: больных студентов определенного врача, заболевания определенного студента), а так же:
- хранить информацию о больных студентах;
- хранить информацию о ВУЗах;
- хранить информацию о группе;
- хранить информацию о заболевании;
- хранить информацию о лечащем враче;
- хранить информацию о диагностике;
- корректный выбор информации по какой-либо характеристике;
- поиск по ключевым словам.
А 4.3 Требования к видам обеспечения
А 4.3.1 Требования к программному обеспечению
К программному обеспечению (ПО) предъявляются следующие требования:
-монитор типа SVGA;
-операционная система- MicrosoftWindows 98 и выше;
- установленная прикладная программа Access 2003 из программного пакета Microsoft Office.
А 4.3.2 Требования к техническому обеспечению
Техническое обеспечение должно удовлетворять следующим требованиям:
-тип компьютера- INTEL 5x 86;
-объем памяти RAM 16Мб;
А 4.3.3 Требования к организационному обеспечению
К программной документации предъявляются следующие требования:
-наличие технического задания;
-пояснительной записки, включающей приложения.
Приложение Б
ЗАПОЛНЕННЫЕ ТАБЛИЦЫ
Приложение В