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

метки: Данные, Разработка, Санаторный, Курортный, Комплекс, Пользователь, Профессия, Название

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

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

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

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

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

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

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

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

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

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

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

База данных туристической фирмы

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

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

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

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

• информацию о клиентах/заказчиках;
• каталог товаров/услуг;
• отчеты персонала;
• статистическую информацию;
• Объектом работы является некоторый курортный санаторий.

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

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

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

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

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

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

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

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

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

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

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

• реляционные (табличные);
• иерархические;
• сетевые;

— Реляционная модель основывается на понятии «отношения» (relation).

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

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

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

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

• централизованная, или сосредоточенная — БД, полностью поддерживаемая на одном компьютере;
• распределенная <#»701396.files/image001.gif»>
• Рисунок 1 — Объекты связи врач-курортолог.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

o Серия и номер путевки —

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

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

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

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

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

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

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

• Диагноз:

o Серия и номер путевки —

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

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

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

o Серия и номер путевки —

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

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

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

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

o Комментарий врача —

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

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

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

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

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

o Название профессии —

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отношение потенциальных и реальных туристов к страхованию в туризме ...

... Предметом дипломной работы страхование как фактор безопасности в туризме. Цель работы – осуществить анализ страхования как фактора безопасности в туризме. Ее реализация требует ряда взаимосвязанных задач: 1. Рассмотреть безопасность в туризме как социальную проблему. 2. Проанализировать страхование в туризме ...

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

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

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

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

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

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

• {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}->{C};

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

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

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

• {A, B}->{A, B};

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

• {A}->{B};

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

• {A}->{B};

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

• {A}->{B};

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

• {A, B}->{A, B};

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

• {A}->{B, C, D, E};
• {B, C, D, E}->{A};

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

• {A}->{B};

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

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

{A, B}->{C};

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

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

• {A, B}->{C};

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

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

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

• {A, B}->{A};
• {A, B}->{B};

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

• {A}->{B};

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

• {A}->{B};

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

• {A}->{B};

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

• {A, B}->{A};
• {A, B}->{B};

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

• {A}->{B};
• {A}->{C};
• {A}->{D};
• {A}->{E};
• {B, C, D, E}->{A};

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

• {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, 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}

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

Для отношения «Отдыхающий»: {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};={{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};
• Для отношения «Диагноз»:={A, B, C};={{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};

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AND

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

AND

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

AND

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

AND

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

AND

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

AND

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

AND

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

AND

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

Отдыхающий. Фамилия Имя Отчество<>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

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

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

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

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

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

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

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

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

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

В качестве инструментального средства разработки базы данных использовалась СУБД — 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)

,

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

2. Реферат по базе данных [электронный ресурс] — URL: #»701396.files/image016.gif»>

Рисунок 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 Требования к функциональным характеристикам

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

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

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

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

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

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

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

П. А.4.3 Требования к надежности

Многопользовательский режим с различными правами на доступ к информации.

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

• организацией правильного ввода параметров инициализирующих структур;

• регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов.

П. А.4.4 Условия эксплуатации

Для функционирования программного средства необходимо выполнение основных правил и требований к безопасной эксплуатации ЭВМ и всех составляющих ее компонентов.

Такими требованиями могут выступать: диапазон температур, запыленность и загазованность помещения и т.д.

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

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

П. А.4.5 Требования к составу и параметрам технических средств

В состав технических средств должен входить IВМ-совместимый персональный компьютер (ПЭВМ), включающий в себя:

• операционную систему семейства Windows;

• VGA-совместимый видеоадаптер и дисплей;

• клавиатура и мышь.

П. А.4.6 Требования к информационной и программной совместимости

Программное средство является функционирует под управлением операционной системой семейства Windows.

Для корректного функционирования программного продукта необходима операционная система платформы MicrosoftWindows XP, MicrosoftWindowsVista или Windows 7.

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

Программное средство должно сопровождаться руководством пользователя. Требования к маркировке отсутствуют.

П. А.4.8 Требования к транспортированию и хранению

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

П. A.5 Требования к программной документации

Предварительный состав необходимой программной документации, выполненной на русском языке в соответствии с требованиями ЕСПД согласно ГОСТ 19.201-78, 19.503-79, 19.504-79, 19.505-79:

Техническое задание по ГОСТ 19.201-78 ЕСПД. «Техническое задание. Требования к содержанию и оформлению».

П. A.6 Стадии и этапы разработки

Системный анализ (с 9.04.2013 по 5.05.2013):

• определение функционала;

• определение области применения и целей использования разрабатываемого программного средства;

• поиск вариантов решения поставленных задач;

• подготовка технического задания;

• выбор и подготовка инструментальных средств и средств отладки.

Общесистемное проектирование (с 5.04.2013 по 31.04.2013):

• определение структуры программного комплекса;

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

Программная реализация, рабочий проект (с 4.05.2013 по 4.06.2013):

• разработка алгоритмической части;

• разработка текстов программных модулей;

• проектирование пользовательского интерфейса.

Отладка программного средства в статике (с 4.05.2013 по 15.06.2013):

• тестирование программных модулей;

• локализация ошибок, корректировка исходных текстов;

• комплексирование модулей, поэтапное сведение в единый комплекс.

Разработка технической документации и выпуск машинных носителей (с 15.05.20132 по 30.05.2013):

• изготовление исследовательской документации (отчетов);

• изготовление эксплуатационной документации (инструкции, руководства, методические указания).

Тестовые испытания программного комплекса (с 15.06.2013 по 20.06.2013):

• испытание на информационную полноту;

• испытание на полноту функционирования;

• протоколы и акты испытаний.

П. А.7 Порядок контроля и приемки

Порядок и контроль приемки определяются заведующим кафедрой «ПОВТ и АС» и основаны на демонстрации знаний технологии и умении создавать программные средства для различных предметных областей. Главным требованием к приемке является наличие правильно работающей программы иллюстрируемой тестовым примером и отчета, представленного в печатном виде. «____» _____________ 2013г.