Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Разработка базы данных для санатория

Разработка базы данных для санатория

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 08.01.2014
Размер файла 1,9 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

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

Содержание

  • Введение
  • 1. Аналитический обзор
  • 1.1 Разработка клиентского приложения для работы с базой данных некоторого санатория
  • 1.2 Классификации БД и приложений для работы с ними
  • 1.3 Краткий обзор аналогов
  • 1.4 Постановка задачи
  • 1.5 Выводы
  • 2. Алгоритмическое конструирование
  • 2.1 Внешняя модель предметной области
  • 2.1.1 Описание объектов предметной области, их атрибутов и связей между объектами
  • 2.1.2 Описание функциональных зависимостей
  • 2.1.3 Описание способов, форм обработки и представления сведений о хранимой в базе данных информации
  • 2.1.4 Дополнительные требования
  • 2.1.5 Модель предметной области в виде схемы "объекты связи"
  • 2.2 Логическая модель предметной области с использованием реляционной модели
  • 2.2.1 Схемы базовых отношений
  • 2.2.2 Домены атрибутов всех отношений
  • 2.2.3 Множество функциональных зависимостей
  • 2.2.4 Построение множества суперключей
  • 2.2.5 Построение множества потенциальных ключей
  • 2.2.6 Выбор первичных ключей
  • 2.2.7 Нормализация отношений до 3НФ
  • 2.2.8 Предикат для проверки целостности базы данных
  • 2.2.9Реляционные выражения для запросов
  • 3. Программное конструирование
  • Заключение
  • Список использованной литературы
  • Приложения

Введение

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

Реляционная база данных представляет собой множество взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определенного типа. Каждая строка таблицы содержит данные об одном объекте (например, клиенте, автомобиле, документе), а столбцы таблицы содержат различные характеристики этих объектов - атрибуты (например, наименования и адреса клиентов, марки и цены автомобилей). Строки таблицы называются записями, все записи имеют одинаковую структуру - они состоят из полей, в которых хранятся атрибуты объекта. Каждое поле в записи содержит одну характеристику объекта и имеет строго определенный тип данных (например, текстовая строка, число, дата). Все записи имеют одни и те же поля, только в них содержатся разные значения атрибутов [1].

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

Любая СУБД позволяет выполнять четыре простейшие операции с данными:

· добавить в таблицу одну или несколько записей;

· удалить из таблицы одну или несколько записей;

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

· найти одну или несколько записей, удовлетворяющих заданному условию.

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

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

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

1. Аналитический обзор

В этом разделе будут рассмотрены классификации БД и аналоги разрабатываемого программного средства.

1.1 Разработка клиентского приложения для работы с базой данных некоторого санатория

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

Информационная система требует создания в памяти ЭВМ динамически обновляемой модели внешнего мира с использованием единого хранилища - базы данных.

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

Подобные базы данных способны хранить самую различную информацию, например:

· информацию о клиентах/заказчиках;

· каталог товаров/услуг;

· отчеты персонала;

· статистическую информацию;

Объектом работы является некоторый курортный санаторий.

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

Объектом внедрения данного ПО является курортный санаторий.

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

Для достижения поставленной цели необходимо:

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

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

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

· сделать разграничения доступа и предусмотреть меры по защите от обхода уровня доступа;

1.2 Классификации БД и приложений для работы с ними

Классификация по характеру организации данных:

· неструктурированные;

· частично структурированные;

· структурированные;

К неструктурированным могут быть отнесены БД, организованные в виде семантических сетей. Частично структурированными можно считать БД в виде обычного текста или гипертекстовые системы. Структурированные БД требуют предварительного проектирования и описания структуры [2].

Классификация по структуре организации данных:

· реляционные (табличные);

· иерархические;

· сетевые;

Реляционная модель основывается на понятии "отношения" (relation). Простейшим примером отношения служит двумерная таблица. Достоинствами реляционной модели представления данных (по сравнению с иерархической и сетевой моделями) являются ее понятность, простота и удобство практической реализации реляционных баз данных на ЭВМ.

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

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

Классификация по степени распределенности:

· централизованная, или сосредоточенная - БД, полностью поддерживаемая на одном компьютере;

· распределенная - БД, составные части которой размещаются в различных узлах компьютерной сети в соответствии с каким-либо критерием [4];

Классификация по типу хранимой информации:

· документальные;

· фактографические;

· лексикографические;

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

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

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

1.3 Краткий обзор аналогов

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

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

1.4 Постановка задачи

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

база приложение алгоритмический программный

1.5 Выводы

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

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

2. Алгоритмическое конструирование

2.1 Внешняя модель предметной области

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

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

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

· для каких отдыхающих наступил день планового осмотра;

· список отдыхающих за определенный период;

· число отдыхающих по каждому заболеванию за определенный период;

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

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

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

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

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

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

· Число пройденных отдыхающим процедур какой-либо разновидности не может превышать число назначенных процедур этой разновидности.

· Дата следующего осмотра не может превышать дату убытия отдыхающего из санатория.

· Одно и то же размещение в санатории не могут иметь два отдыхающих в одно время

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

· Диагноз отдыхающего не может быть пуст (тогда бы его не направили в санаторий)

· Каждая разновидность процедур назначается только один раз

· Отдыхающему назначается один ведущий курортолог

· Совокупность кода санаторно-курортной карты и серии и номера путевки не повторяется

· Номер процедуры уникален

· Номер сотрудника уникален

· Номер профессии уникален.

· Номер заболевания уникален.

2.1.1 Описание объектов предметной области, их атрибутов и связей между объектами

В предметной области были выделены следующие типы хранимых полей и объектов (с учетом требований, предъявляемых всеми пользователями всех пользователей): отдых-й, санкарта.

· отдыхающий:

o Фамилия, Имя, Отчество;

o Год рождения;

o Город проживания;

o Профессия;

o ИН санаторно-курортной карты;

· санаторно-курортная карта:

o ИН санаторно-курортной карты;

o Дата прибытия в санаторий;

o Дата убытия из санатория;

o Дата следующего осмотра;

o ИН заболевания;

o ИН разновидности процедуры;

o Назначенное число процедур данной разновидности;

o Пройденное число процедур данной разновидности;

· заболевание:

o ИН заболевания;

o Название заболевания;

o ИН рекомендуемой разновидности процедур;

· процедура:

o ИН разновидности;

o Название процедуры;

Связи между объектами:

· санаторно-курортную карту получает отдыхающий;

· диагноз содержится в санаторно-курортной карте;

· заболевания определяются диагнозом;

· процедуры назначаются по заболеванию;

2.1.2 Описание функциональных зависимостей

· опишем функциональные зависимости, имеющие место в предметной области;

· отдыхающий имеет уникальное сочетание кода санаторно-курортной карты и серии и номера путевки;

· сочетание кода санаторно-курортной карты и серии и номера путевки однозначно определяет размещение отдыхающего.

· размещения могут совпадать только у отдыхающих в разные периоды времени;

· номер процедуры однозначно определяет ее название;

· номер заболевания однозначно определяет его название;

· одному отдыхающему соответствует один диагноз, однозначно определяемый кодом санаторно-курортной карты и серией и номером путевки;

· для каждого заболевания существуют рекомендованные процедуры;

· для каждой профессии существуют профессиональные заболевания;

2.1.3 Описание способов, форм обработки и представления сведений о хранимой в базе данных информации

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

· Курортолог:

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

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

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

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

o просмотр среднего количества процедур, пройденных каждым отдыхающим за определенный период;

· работник процедурного кабинета:

o поиск среди отдыхающих пришедшего на процедуры, просмотр назначенных для него процедур, просмотр комментария ведущего врача к данной процедуре, увеличение числа пройденных сеансов для данного отдыхающего;

· администратор программы:;

o просмотр списка пользователей программы, не являющихся администраторами;

o изменение логина и пароля для пользователей, не администраторов (кроме своего логина и пароля);

o создание новых пользователей;

o удаление пользователей;

2.1.4 Дополнительные требования

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

2.1.5 Модель предметной области в виде схемы "объекты связи"

Приведем схемы типа "объекты связи" для следующих пользователей: врач-курортолог (рисунок 1), работник процедурного кабинета (рисунок 2), администратор (рисунок 3).

Рисунок 1 - Объекты связи врач-курортолог.

Рисунок 2 - Объекты связи работник процедурного кабинета.

Рисунок 3 - Объекты связи администратор.

2.2 Логическая модель предметной области с использованием реляционной модели

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

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

2.2.1 Схемы базовых отношений

Существуют следующие базовые отношения:

· отдыхающий;

· диагноз;

· назначенные процедуры;

· профессиональные заболевания;

· названия профессий;

· названия заболеваний;

· названия процедур;

· процедуры для заболеваний;

· пользователи;

· виды пользователей;

2.2.2 Домены атрибутов всех отношений

Опишем домены атрибутов спроектированных отношений.

· Отдыхающий:

o Фамилия Имя Отчество - строка до 50 символов.

o Дата рождения - дата.

o Город проживания - строка до 30 символов.

o ИН профессии - целое число (4 байта)

o Код СКК - целое число 4 байта

o ИН ведущего врача - целое число 4 байта

o Серия и номер путевки - строка до 10 символов

o Дата путевки - дата

o Дата прибытия - дата

o Дата убытия - дата

o Дата осмотра - дата

o Корпус - строка до 10 символов

o Комната - строка до 5 символов

o Место - строка до 3 символов

· Диагноз:

o Серия и номер путевки - строка до 10 символов

o Код СКК - целое число 4 байта

o ИН заболевания - целое число 4 байта

· Назначенные процедуры:

o Серия и номер путевки - строка до 10 символов

o Код СКК - целое число 4 байта

o ИН процедуры - целое число 4 байта

o Назначено - целое число 1 байт

o Пройдено - целое число 1 байт

o Комментарий врача - строка до 50 символов

· Профессиональные заболевания:

o ИН профессии - целое число 4 байта

o ИН заболевания - целое число 4 байта

· Названия профессий:

o ИН профессии - целое число 4 байта

o Название профессии - строка до 20 символов

· Названия заболеваний:

o ИН заболевания - целое число 4 байта

o Название заболевания - строка до 25 символов

· Названия процедур:

o ИН процедуры - целое число 4 байта

o Название процедуры - строка до 20 символов

· Процедуры для заболеваний:

o ИН заболевания - целое число 4 байта

o ИН процедуры - целое число 4 байта

· Пользователи:

o ИН пользователя - целое число 4 байта

o ФИО - строка до 50 символов

o Вид сотрудника - 1 символ

o Логин - строка до 8 символов

o Пароль - строка до 8 символов

· Виды пользователей:

o ИН вида - 1 символ

o Название вида - строка до 50 символов

2.2.3 Множество функциональных зависимостей

Построим множества функциональных зависимостей (ФЗ) для базовых отношений предметной области.

Для отношения Отдыхающий:

1) {A, B}->{C, D, E, F, G, H, I, J, K, L, M, N};

2) {I, K, L, M, N}->{A, B, C, D, E, F, G, H, J};

Для отношения Диагноз:

1) {A, B}->{C};

Для отношения Назначенные процедуры:

1) {A, B}->{C,D,E,F};

Для отношения Профессиональные заболевания:

1) {A, B}->{A, B};

Для отношения Названия профессий:

1) {A}->{B};

Для отношения Названия Заболеваний:

1) {A}->{B};

Для отношения Названия процедур:

1) {A}->{B};

Для отношения Процедуры для заболеваний:

1) {A, B}->{A, B};

Для отношения Пользователи:

1) {A}->{B, C, D, E};

2) {B, C, D, E}->{A};

Для отношения Виды пользователей:

1) {A}->{B};

3.2.4 Неприводимое множество функциональных зависимостей

Cледует перезаписать заданные ФЗ таким образом, чтобы каждая из них имела правую одноэлементную часть, исключая при этом одинаковые ФЗ. Следовательно неприводимое множество для отношения "Отдыхающий" будет следующим:

1) {A, B}->{C};

2) {A, B}->{D};

3) {A, B}->{E};

4) {A, B}->{F};

5) {A, B}->{G};

6) {A, B}->{H};

7) {A, B}->{I};

8) {A, B}->{J};

9) {A, B}->{K};

10) {A, B}->{L};

11) {A, B}->{M};

12) {A, B}->{N};

13) {I, K, L, M, N}->{A};

14) {I, K, L, M, N}->{B};

15) {I, K, L, M, N}->{C};

16) {I, K, L, M, N}->{D};

17) {I, K, L, M, N}->{E};

18) {I, K, L, M, N}->{F};

19) {I, K, L, M, N}->{G};

20) {I, K, L, M, N}->{H};

21) {I, K, L, M, N}->{J};

Для отношения Диагноз:

1) {A, B}->{C};

Для отношения Назначенные процедуры:

1) {A, B}->{C };

2) {A, B}->{D};

3) {A, B}->{E};

4) {A, B}->{F};

Для отношения Профессиональные заболевания:

1) {A, B}->{A};

2) {A, B}->{B};

Для отношения Названия профессий:

1) {A}->{B};

Для отношения Названия Заболеваний:

1) {A}->{B};

Для отношения Названия процедур:

1) {A}->{B};

Для отношения Процедуры для заболеваний:

1) {A, B}->{A};

2) {A, B}->{B};

Для отношения Пользователи:

1) {A}->{B};

2) {A}->{C};

3) {A}->{D};

4) {A}->{E};

5) {B, C, D, E}->{A};

Для отношения Виды пользователей:

1) {A}->{B};

2.2.4 Построение множества суперключей

Построим множество суперключей для выделенных отношений.

Для отношения "Отдыхающий" на основании функциональных зависимостей {A, B}->{C, D, E, F, G, H, I, J, K, L, M, N}, {I, K, L, M, N}->{A, B, C, D, E, F, G, H, J} построим подмножества атрибутов отношения.

{A, B};

{A, B, C};

{A, B, D};

{A, B, D};

…………

{I, K, L, M, N};

{I, K, L, M, N, A};

{I, K, L, M, N, B};

....

{A, B, C, D, E, F, G, H, I, J, K, L, M, N};

Суперключи для данного отношения - любые подмножества множества атрибутов отношения Отдыхающий, включающие в себя атрибуты {A, B} или {I, K, L, M, N}

Для отношения "Диагноз" на основании функциональной зависимости {A, B}->{C} построим подмножества атрибутов отношения.

{A, B}->{C};

{A, B};

{A, B, C};

Суперключи для данного отношения - любые подмножества множества атрибутов отношения Диагноз, включающие в себя атрибуты {A, B}

Для отношения "Назначенные процедуры" на основании функциональной зависимости {A, B}->{C,D,E,F} построим подмножества атрибутов отношения.

{A, B};

{A, B, C};

{A, B, D};

...

{A, B, C, D, E, F};

Суперключи для данного отношения - любые подмножества множества атрибутов отношения "Назначенные процедуры", включающие в себя атрибуты {A, B}.

· Для отношения "Профессиональные заболевания" на основании функциональной зависимости {A, B}->{A, B} построим подмножества атрибутов отношения.

o {A, B};

· Для отношения "Названия профессий" на основании функциональной зависимости {A}->{B} построим подмножества атрибутов отношения.

o {A};

o {A, B};

· Для отношения "Названия Заболеваний" на основании функциональной зависимости {A}->{B} построим подмножества атрибутов отношения.

o {A};

o {A, B};

· Для отношения "Названия процедур" на основании функциональной зависимости {A}->{B} построим подмножества атрибутов отношения.

o {A};

o {A, B};

· Для отношения "Процедуры для заболеваний" на основании функциональной зависимости {A, B}->{A, B} построим подмножества атрибутов отношения.

o {A, B};

· Для отношения "Пользователи" на основании функциональной зависимости {A}->{B, C, D, E} построим подмножества атрибутов отношения.

o {A};

o {A, B};

o {A, C};

o ....

o {B, C, D, E};

o {A, B, C, D, E};

· Для отношения "Виды пользователей" на основании функциональной зависимости {A}->{B} построим подмножества атрибутов отношения.

o {A}

o {A, B}

2.2.5 Построение множества потенциальных ключей

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

Для отношения "Отдыхающий": {A, B},{I, K, L, M, N}

Для отношения "Диагноз": {A, B}

Для отношения "Назначенные процедуры": {A, B}

Для отношения "Профессиональные заболевания": {A, B}

Для отношения "Названия профессий": {A}

Для отношения "Названия заболеваний": {A}

Для отношения "Названия процедур": {A}

Для отношения "Процедуры для заболеваний": {A, B}

Для отношения "Пользователи": {A}, {B, C, D, E}

Для отношения "Виды пользователей": {A}

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

Для отношения "Отдыхающий" (R-множество атрибутов отношения, S - множество функциональных зависимостей, {}+ - щзамукание множества атрибутов):

R={A, B, C, D, E, F, G, H, I, J, K, L, M, N};

S={{A, B}->{C, D, E, F, G, H, I, J, K, L, M, N},{I, K, L, M, N}->{A, B, C, D, E, F, G, H, J}};

{A, B}+={A, B, C, D, E, F, G, H, I, J, K, L, M, N};

{I, K, L, M, N}+={A, B, C, D, E, F, G, H, I, J, K, L, M, N};

Для отношения "Диагноз":

R={A, B, C};

S={{A, B}->{C}};

{A, B}+={A, B, C};

Для отношения "Назначенные процедуры":

R={A, B, C, D, E, F};

S={{A, B}->{C,D,E,F}};

{A, B}+={A, B, C, D, E, F};

Для отношения "Профессиональные заболевания":

R={A, B};

S={{A, B}->{A, B}};

{A, B}+={A, B};

Для отношения "Названия профессий":

R={A, B};

S={{A}->{B}};

{A}+={A, B};

Для отношения "Названия заболеваний":

R={A, B};

S={{A}->{B}};

{A}+={A, B};

Для отношения "Названия процедур":

R={A, B};

S={{A}->{B}};

{A}+={A, B};

Для отношения "Процедуры для заболеваний":

R={A, B};

S={{A, B}->{A, B}};

{A, B}+={A, B};

Для отношения "Пользователи":

R={A, B, C, D, E};

S={{A}->{B, C, D, E},{B, C, D, E}->{A}};

{A}+={A, B, C, D, E};

{B, C, D, E}+={A, B, C, D, E};

Для отношения "Виды пользователей":

R={A, B};

S={{A}->{B}};

{A}+={A, B};

2.2.6 Выбор первичных ключей

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

Для отношения Отдыхающий: первичным ключом выбран потенциальный ключ {A, B}, так как он меньший по размеру.

Для отношения Диагноз: первичным ключом выбран потенциальный ключ {A, B}, так как он единственный потенциальный ключ в данном отношении.

Для отношения Назначенные процедуры: первичным ключом выбран потенциальный ключ {A, B}, так как он единственный потенциальный ключ в данном отношении.

Для отношения Профессиональные заболевания: первичным ключом выбран потенциальный ключ {A, B}, так как он единственный потенциальный ключ в данном отношении.

Для отношения Названия профессий: первичным ключом выбран потенциальный ключ {A}, так как он единственный потенциальный ключ в данном отношении.

Для отношения Названия заболеваний: первичным ключом выбран потенциальный ключ {A}, так как он единственный потенциальный ключ в данном отношении.

Для отношения Названия процедур: первичным ключом выбран потенциальный ключ {A}, так как он единственный потенциальный ключ в данном отношении.

Для отношения Процедуры для заболеваний: первичным ключом выбран потенциальный ключ {A, B}, так как он единственный потенциальный ключ в данном отношении.

Для отношения Пользователи: первичным ключом выбран потенциальный ключ {A}, так как он меньший по размеру и числовой, что способствует большей производительности.

Для отношения Виды пользователей: первичным ключом выбран потенциальный ключ {A}, так как он единственный потенциальный ключ в данном отношении.

2.2.7 Нормализация отношений до 3НФ

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

Основное ограничение, задаваемое 1НФ - атомарность всех атрибутов отношения.

Отдыхающий0:: = {Серия и номер путевки, Код СКК, Фамилия Имя Отчество, Дата рождения, Город проживания, ИН профессии, Код СКК, ИН ведущего врача, Дата путевки, Дата прибытия, Дата убытия, Дата осмотра, Корпус, Комната, Место}

Диагноз0:: = {Серия и номер путевки, Код СКК, ИН заболевания}

Назначенные процедуры0:: ={Серия и номер путевки, Код СКК, ИН процедуры, Назначено, Пройдено, Комментарий врача}

Профессиональные заболевания0:: ={ИН профессии, ИН заболевания}

Названия профессий0:: ={ИН профессии, Название профессии}

Названия заболеваний0:: ={ИН заболевания, Название заболевания}

Названия процедур0:: ={ИН процедуры, Название процедуры}

Процедуры для заболеваний0:: ={ИН заболевания, ИН процедуры}

Пользователи0:: ={ИН пользователя, ФИО, Вид сотрудника, Логин, Пароль}

Виды пользователей0:: ={ИН вида, Название вида}

Как видно, все атрибуты отношения являются атомарными, т.е. данные отношения автоматически в 1НФ.

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

Отдыхающий1:: = {Серия и номер путевки, Код СКК, Фамилия Имя Отчество, Дата рождения, Город проживания, ИН профессии, Код СКК, ИН ведущего врача, Дата путевки, Дата прибытия, Дата убытия, Дата осмотра, Корпус, Комната, Место}

Диагноз1:: = {Серия и номер путевки, Код СКК, ИН заболевания}

Назначенные процедуры1:: ={Серия и номер путевки, Код СКК, ИН процедуры, Назначено, Пройдено, Комментарий врача}

Профессиональные заболевания1:: ={ИН профессии, ИН заболевания}

Названия профессий1:: ={ИН профессии, Название профессии}

Названия заболеваний1:: ={ИН заболевания, Название заболевания}

Названия процедур1:: ={ИН процедуры, Название процедуры}

Процедуры для заболеваний1:: ={ИН заболевания, ИН процедуры}

Пользователи1:: ={ИН пользователя, ФИО, Вид сотрудника, Логин, Пароль}

Виды пользователей1:: ={ИН вида, Название вида}

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

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

Отдыхающий2:: = {Серия и номер путевки, Код СКК, Фамилия Имя Отчество, Дата рождения, Город проживания, ИН профессии, Код СКК, ИН ведущего врача, Дата путевки, Дата прибытия, Дата убытия, Дата осмотра, Корпус, Комната, Место}

Диагноз2:: = {Серия и номер путевки, Код СКК, ИН заболевания}

Назначенные процедуры2:: ={Серия и номер путевки, Код СКК, ИН процедуры, Назначено, Пройдено, Комментарий врача}

Профессиональные заболевания2:: ={ИН профессии, ИН заболевания}

Названия профессий2:: ={ИН профессии, Название профессии}

Названия заболеваний2:: ={ИН заболевания, Название заболевания}

Названия процедур2:: ={ИН процедуры, Название процедуры}

Процедуры для заболеваний2:: ={ИН заболевания, ИН процедуры}

Пользователи2:: ={ИН пользователя, ФИО, Вид сотрудника, Логин, Пароль}

Виды пользователей2:: ={ИН вида, Название вида}

Видно, что отношения находятся в 3НФ.

2.2.8 Предикат для проверки целостности базы данных

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

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

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

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

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

· В этот предикат входят условия совпадения множества кортежей соответствующих внешним ключам, а также условия включения атрибутов в домены.

Диагноз. Серия и номер путевки = Отдыхающий. Серия и номер путевки

AND

Диагноз. Код СКК = Отдыхающий. Код СКК

AND

Диагноз. ИН заболевания = Названия заболеваний. ИН заболевания

AND

Назначенные процедуры. Серия и номер путевки = Отдыхающий. Серия и номер путевки

AND

Назначенные процедуры. Код СКК = Отдыхающий. Код СКК

AND

Назначенные процедуры. ИН процедуры = Названия процедур. ИН процедуры

AND

Назначенные процедуры. Назначено <= Назначенные процедуры. Пройдено

AND

Отдыхающий. Серия и номер путевки <>NULL

AND

Отдыхающий. Код СКК <>NULL

AND

Отдыхающий. Фамилия Имя Отчество<>NULL

AND

Отдыхающий. Дата рождения <>NULL

AND

Отдыхающий. Город проживания <>NULL

AND

Отдыхающий. ИН профессии = Названия профессий. ИН профессии

AND

(Отдыхающий. ИН ведущего врача = Пользователи. ИН пользователя OR Отдыхающий. Дата убытия < Текущая дата)

AND

Отдыхающий. Дата путевки < Отдыхающий. Дата прибытия

AND

Отдыхающий. Дата убытия > Отдыхающий. Дата прибытия

AND

Отдыхающий. Дата осмотра > Отдыхающий. Дата прибытия

AND

Отдыхающий. Дата осмотра < Отдыхающий. Дата убытия

AND

( (Отдыхающий i. Корпус= Отдыхающий j. Корпус AND Отдыхающий i. Комната = Отдыхающий j. Комната AND Отдыхающий i. Место = Отдыхающий j. Место) ~

(Отдыхающий i. Дата убытия< Отдыхающий j. Дата прибытия))

AND

Процедуры для заболеваний. ИН заболевания = Названия заболеваний. ИН заболевания

AND

Процедуры для заболеваний. ИН процедуры = Названия процедур. ИН процедуры

AND

Профессиональные заболевания. ИН заболевания = Названия заболеваний. ИН заболевания

AND

Профессиональные заболевания. ИН профессии = Названия профессий. ИН профессии

AND

Пользователи. Вид сотрудника = Виды пользователей. ИН вида

2.2.9Реляционные выражения для запросов

Приведем реляционные выражения, на основе котрых строятся запросы.

Найти отдыхающего с серией и номером путевки X и кодом санаторно-курортной карты Y:

Gсерия и номер путевки=Х&& код СКК=Y (ОТДЫХАЮЩИЙ),

где X - строка, Y - целое число, G-запрос.

Узнать диагноз для отдыхающего с серией и номером путевки X и кодом санаторно-курортной карты Y:

Пназвание (GИН заболевания=П ИН заболевания (G серия и номер путевки=Х&& код СКК=Y (Диагноз)) (Названия заболеваний)),

где П - проекция отношения.

Узнать диагноз для отдыхающего с серией и номером путевки X и кодом санаторно-курортной карты Y

Пназвание (GИН процедуры=П ИН процедуры (G серия и номер путевки=Х&& код СКК=Y (Назначенные процедуры)) (Названия заболеваний))

3. Программное конструирование

В качестве инструментального средства разработки базы данных использовалась СУБД - MicrosoftAccess, сами приложения написаны при помощи интегрированной среды разработки BorlandC++ Builder версии 6. Используя возможности, предоставляемые данной средой разработки, был разработан комплекс программ по управлению спроектированной базой данных. При этом особое внимание было уделено выполнению основных правил Кодда: физическая независимость данных: заключается в независимости разрабатываемых прикладных программ от используемых способов хранения информации на носителях и от способов доступа к этим носителям данных. Данный вид независимости данных в данной разработке достигается тем, что любые действия по манипуляции с данными осуществляются посредством высокоуровневых команд манипулирования данными (реализуемых языком). Т.е. сведения об организации данных и способе доступа к ним не привязываются к логике и коду приложений. Низкоуровневые механизмы доступа осуществляются операционной системойWindows (под управлением которой работает сама СУБД), "прозрачным" для пользователя способом. Таким образом обеспечивается независимость хранения данных и независимость способа доступа к ним как для различных файловых систем, так и для различных физических носителей информации; логическая независимость данных, согласно которой прикладные программы не должны зависеть от реализации конкретного из используемых представлений. Т.е. логическая независимость данных обеспечивается отображением внешней схемы на концептуальную. Это реализуется драйвером базы данных MicrosoftAccess, приложения не потребуют модификации при изменении реализации представлений; дистрибутивная независимость, согласно которой: разработанная информационная система должна быть распространяема и переносима. Данный вид независимости выполняется лишь частично - информационная система сохраняет работоспособность в ОС, совместимых с Windows, при выполнении на базе различных аппаратных платформ. Инсталляция программы производится с использованием программы - инсталлятора, имеющей интуитивно понятный интерфейс. После проектирования получены следующие таблицы (в скобках указаны названия таблиц и полей, которые были им присвоены на этапе реализации базы данных в MicrosoftAccess и тип данных в MicrosoftAccess).

Отдыхающий (RECREANTS):

o Серия и номер путевки (WAYPAPER_SNN, Текстовый)

o Код СКК (SKK_CODE)

o Фамилия Имя Отчество (FIO, Текстовый)

o Дата рождения (D_BORN, Дата-короткий формат)

o Город проживания (LIVESITY, Текстовый)

o ИН профессии (C_PROFESSION, Длинное целое)

o ИН ведущего врача (DOCTOR, Длинное целое)

o Дата путевки (WAYPAPER_DATE, Дата-короткий формат)

o Дата прибытия (D_ARRIVAL, Дата-короткий формат)

o Дата убытия (D_LEAVE, Дата-короткий формат)

o Дата осмотра (D_REVISION, Дата-короткий формат)

o Корпус (CORPUS)

o Комната (ROOM)

o Место (PLACE)

Диагноз (RECREANTS_AEGERS):

o Серия и номер путевки (WAYPAPER_SNN, Текстовый)

o Код СКК (SKK_CODE, Длинное целое)

o ИН заболевания (C_AEGER, Длинное целое)

Назначенные процедуры (PROCEDURES_ASSIGNED):

o Серия и номер путевки (WAYPAPER_SNN, Текстовый)

o Код СКК (SKK_CODE, Длинное целое)

o ИН процедуры (С_PROC, Длинное целое)

o Назначено (N_ASSIGNED, Длинное целое)

o Пройдено (N_PASSED, Длинное целое)

o Комментарий врача (COMMENT, Текстовый)

Профессиональные заболевания (PROF_AEGERS):

o ИН профессии (C_PROF, Длинное целое)

o ИН заболевания (C_AEGER, Длинное целое)

Названия профессий (PROF_CAPTIONS):

o ИН профессии (C_PROF, Длинное целое)

o Название профессии (CAPTION, Текстовый)

Названия заболеваний (AEGER_ CAPTIONS):

o ИН заболевания (C_AEGER)

o Название заболевания (CAPTION, Текстовый)

Названия процедур (PROCED_ CAPTIONS):

o ИН процедуры (C_PROC, Длинное целое)

o Название процедуры (CAPTION, Текстовый)

Процедуры для заболеваний (PROC_FOR_AEGERS):

o ИН заболевания (C_AEGER, Длинное целое)

o ИН процедуры (C_PROCED, Длинное целое)

Пользователи (PERSONS):

o ИН пользователя (ID, Длинное целое)

o ФИО (FIO, Текстовый)

o Вид сотрудника (C_PROF, Длинное целое)

o Логин (LOGIN, Текстовый)

o Пароль (PASSWD, Текстовый)

Виды пользователей (PERSONS_PROF):

o ИН вида (C_MENU)

o Название вида (NAME_REC, Текстовый)

Структура таблиц и связей в реализации базы данных на MicrosoftAccess представлена на рисунке 4.

Рисунок 4 - Структура таблиц и связей

Спроектирован набор пользовательских экранных форм. Далее будут приведены наиболее важные из них. Для авторизованного входа в программу используется начальная форма (рисунок 5)

Рисунок 5 - Начальная форма авторизации

Врач-курортолог работает с формой, на которой представлен список отдыхающих (рисунок 6)

Рисунок 6 - Форма работы врача-курортолога.

Для работника процедурного кабинета также создана специализированная форма (рисунок 7)

Рисунок 7 - форма работника процедурного кабинета.

Администратор работает с формой управления списком пользователей (рисунок 8)

Рисунок 8 - форма работы администратора.

При занесении в список нового отдыхающего врач - курортолог заполняет взаимосвязанный набор форм (рисунки 9-12):

Рисунок 9 - форма добавления нового отдыхающего.

Рисунок 10 - форма заполнения новой санаторной карты.

Рисунок 11 - форма установки диагноза отдыхающего.

Рисунок 12 - форма назначения процедур отдыхающему.

Форма одного из статистических запросов представлена на рисунке 13.

Рисунок 13 - форма статических запросов.

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

Рисунок 14 - написанный инсталлятор программного средства.

В процессе инсталляции может быть выбрана директория установки (рисунок 15)

Рисунок 15 - выбор директории установки программного средства.

Заключение

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

Список использованной литературы

1. Ульман Г. Основы систем баз данных. Ростов: Феникс, 2002 г.

2. Реферат по базе данных [электронный ресурс] - URL: http://works. doklad.ru/view/4cPvTzD0nKY.html

3. Классификация баз данных [электронный ресурс] - URL: http://denizzone.com/baset1r5part1.html

4. Модели представления данных [электронный ресурс] - URL: http://www.e-reading-lib.org/chapter. php/97791/122/Kozlova_-_Informatika__konspekt_lekciii.html

5. База данных [электронный ресурс] - URL: http://ru. wikipedia.org/wiki/База_данных

6. MicrosoftAccess [электронный ресурс] - URL: http://ru. wikipedia.org/wiki/Microsoft_Access

7. VisualStudio [электронный ресурс] - URL: http://ru. wikipedia.org/wiki/Visual_Studio

8. Создаем формы на C# [электронный ресурс] - URL: http://blog. nguen.net/post287-windows_form. htm

Приложения

Приложение А. Санаторно-курортная карта

Данный документ представлен на рисунке 16.

Рисунок 16 - Санаторно-курортная карта

Приложение Б. Техническое задание на программное средство

"СОГЛАСОВАНО"

Руководитель:

____________ Гнедина О. А.

"____" ____________ 2013 г.

"УТВЕРЖДЕНО"

зав. кафедрой "ПОВТ и АС"

_____________ Нейдорф Р. А.

"____" ____________ 2013 г.

П. А.1 Введение

П. A 1.1 Наименование программы

Наименование программы - "Санаторий".

П. A 1.2 Область применения

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

П. A 1.3 Объект внедрения

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

П. А.2 Основания для разработки

Разработка ведется на основании документа "Учебный план для студентов ВУЗа", факультета "Информатика и вычислительная техника", обучающихся по специальности 010503 "Математическое обеспечение и администрирование информационных систем", в соответствии с которым студенты, должны предоставить к защите курсовую работу. Предметным основанием является задание на курсовую работу.

П. А.3 Назначение разработки

П. А.3.1 Функциональное назначение

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

П. А.3.1 Эксплуатационное назначение

Эксплуатационное назначение заключается в использовании программного средства в качестве информационного ресурса санатория.

П. А.4 Требования к программе

П. А.4.1 Требования к программе в целом

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

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

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

· главная форма должна быть выполнена таким образом, чтобы:

§ администратору:

° обеспечить возможность добавления пользователей;

° обеспечить возможность отнесения пользователя в группы пользователей;

§ врачу - курортологу:

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

° обеспечить просмотр числа отдыхающих, за определенный период принимавших процедуры по поводу определенного заболевания;

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

§ работнику процедурного кабинета:

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

§ Предусмотреть возможность вывода всех возможных процедур, заболевания.

П. А.4.1.1 Требования к структуре и функционированию

Структурно ПС должно состоять из следующих компонент (подсистем):

· подсистемы хранения данных;

· интерфейс взаимодействия с ресурсом.

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

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

П. А.4.1.2 Требования к дизайну

Дизайн должен удовлетворять следующим требованиям:

· интуитивно понятный пользовательский интерфейс;

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

П. А.4.2 Требования к функциональным характеристикам

П. А.4.2.1 Навигация

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

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

Меню должно представлять собой текстовый блок в левой и верхней частях страницы.

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

П. А.4.2.2 Разделение доступа

В программе используется разделение доступа пользователей. Существуют пользователи со следующими правами:

· Администратор

· Работник процедурного кабинета

· Врач-курортолог

П. А.4.2.3 Главная страница программы

Главная страница ресурса состоит из:

· графической части, которая представляется в виде таблицы - базы данных;

· поле поиска;

· Меню с функциями расширенного поиска, печати отчетов, просмотра информации об отдыхающих;

П. А.4.2.4 Требования к функциональным характеристикам

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

Выполняемая функциональность разработанным программным средством:

· Просмотр, редактирование, удаление информации о сотрудниках, клиентах, пользователях;

· Поиск по заданным параметрам;

· Печать отчетов;

· Разделение прав доступа;

· Фильтрация данных;

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены