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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

Также можно охарактеризовать как набор сведений, хранящихся некоторым упорядоченным способом. Можно сравнить базу данных со шкафом, в котором хранятся документы. Иными словами, база данных — это хранилище данных. Сами по себе базы данных не представляли бы интереса, если бы не было систем управления базами данных (СУБД).

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

Позволяет определять базу данных, что осуществляется с помощью языка определения данных DDL (Data Definition Language). Язык представляет пользователям средства указания типа данных и их структуры, а также средства задания ограничений для информации, хранимой в базе данных [3].

Также важной частью является DML (Data Manipulation Language — язык управления (манипулирования) данными) — это семейство компьютерных языков, используемых в компьютерных программах или пользователями баз данных для получения, вставки, удаления или изменения данных в базах данных.

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

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

Инфологическая модель. ПрО представляет собой описание структуры и динамики. ПрО, характера информационных потребностей пользователей в терминах, понятных пользователю и не зависимых от реализации БД. Это описание выражается в терминах не отдельных объектов. ПрО и связей между ними, а их типов, связанных с ними ограничений целостности и тех процессов, которые приводят к переходу. ПрО из одного состояния в другое [5].

Основными подходами к созданию инфологической модели предметной области являются [1]:

Мы будем использовать метод "сущность–связь" как наиболее распространённый. Приведём основные термины, которыми мы будем пользоваться:

Сущность – это объект, о котором в системе будут накапливаться данные. Для сущности указывается название и тип (сильная или слабая). Сильные сущности существуют сами по себе, а существование слабых сущностей зависит от существования сильных [2].

Атрибут – свойство сущности. Различают:

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

Связь – это осмысленная ассоциация между сущностями. Для связи указывается название, тип (факультативная или обязательная), степень (1:1, 1: n или m:n) и кардинальность (унарная, бинарная, тернарная или n-арная) [4].

На рис. 1 приведены обозначения, которые мы будем использовать в ER-диаграммах.

<Object: word/embeddings/oleObject1.bin>

Рис.1 – Обозначения, используемые в ER-диаграммах

1.2.1. Требования к операционной обстановке

На этом этапе производится оценка требований к вычислительным ресурсам, необходимым для функционирования системы, определение типа и конфигурации конкретной ЭВМ, выбор типа и версии операционной системы. Объём вычислительных ресурсов зависит от предполагаемого объёма проектируемой базы данных и от интенсивности их использования. Если БД будет работать в многопользовательском режиме, то требуется подключение её к сети и наличие соответствующей многозадачной операционной системы, к таким относят семейство систем Windows, OC UNIX, MAC OS.

В моём случае база данных будет использовать исключительно локальный источник, что сразу снижает требование к уровню конфигурации ЭВМ, достаточно использовать семейство систем архитектуры win32, а также порт USB 2.0 или более поздней версии [3].

Выбор СУБД осуществляется на основании таких критериев, как тип модели данных и её адекватность потребностям рассматриваемой ПрО; характеристики производительности; набор функциональных возможностей; удобство и надежность СУБД в эксплуатации; стоимость СУБД и дополнительного программного обеспечения.

В условиях ограниченности выбора под некоторые индивидуальные особенности, я решил выбрать приложение Microsoft Access 2013 – оно является мощной и высокопроизводительной 32-разрядной системой управления реляционной базой данных (далее СУБД).

Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет одновременно использовать несколько таблиц базы данных. Можно использовать таблицы, созданные в среде Paradox или dBase. Работая в среде Microsoft Office, пользователь получает в своё распоряжение полностью совместимые с Access текстовые документы (Word), электронные таблицы (Excel), презентации (PowerPoint). С помощью новых расширений для Internet можно напрямую взаимодействовать с данными из WWW (World Wide Web) и транслировать представление данных на языке HTML (HyperText Markup Language — «язык гипертекстовой разметки»), обеспечивая работу с такими приложениями как Internet Explorer и Netscape Navigator.

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

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

Этап физического проектирования заключается в определении схемы хранения, т.е. физической структуры БД. Схема хранения зависит от той физической структуры, которую поддерживает выбранная СУБД. Физическая структура БД, с одной стороны, должна адекватно отражать логическую структуру БД, а с другой стороны, должна обеспечивать эффективное размещение данных и быстрый доступ к ним. Результаты этого этапа документируются в форме схемы хранения на языке определения данных (DDL, Data Definition Language) выбранной СУБД. Принятые на этом этапе решения оказывают огромное влияние на производительность системы [5].

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

Проектирование реляционной базы данных проходит в том же порядке, что и проектирование БД других моделей данных, но имеет свои особенности. Проектирование схемы БД должно решать задачи минимизации дублирования данных и упрощения процедур их обработки и обновления. При неправильно спроектированной схеме БД могут возникнуть аномалии модификации данных. Они обусловлены отсутствием средств явного представления типов множественных связей между объектами ПрО и неразвитостью средств описания ограничений целостности на уровне модели данных. Для решения подобных проблем проводится нормализация отношений. Механизм нормализации реляционных отношений разработал Э.Ф. Кодд (E.F. Codd) [7]. Этот механизм позволяет по формальным признакам любое отношение преобразовать к третьей нормальной форме. Нормализация схемы отношения выполняется путём декомпозиции схемы. Декомпозицией схемы отношения R называется замена её совокупностью схем отношений Аi таких, что i R Ai , и не требуется, чтобы отношения Аi были непересекающимися. Первая нормальная форма относится к понятию простого и сложного (составного или многозначного) атрибута (см. п.1.2.1). Первая нормальная форма (1НФ). Отношение приведено к 1НФ, если все его атрибуты простые. Для того чтобы привести к 1НФ отношение, содержащее сложные атрибуты, нужно:

1) разбить составные атрибуты на простые;

2) построить декартово произведение всех многозначных атрибутов с кортежами, к которым они относятся.

Для идентификации кортежа в этом случае понадобится составной ключ, включающий первичный ключ исходного отношения и все многозначные атрибуты. Вторая нормальная форма основана на понятии функциональной зависимости. Пусть X и Y – атрибуты некоторого отношения. Если в любой момент времени каждому значению X соответствует единственное значение Y, то говорят, что Y функционально зависит от X (XY). Атрибут X в функциональной зависимости XY называется детерминантом отношения. В нормализованном отношении все неключевые атрибуты функционально зависят от ключа отношения. Неключевой атрибут функционально полно зависит от составного ключа, если он функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа. Вторая нормальная форма (2НФ). Отношение находится во 2НФ, если оно приведено к 1НФ и каждый неключевой атрибут функционально полно зависит от составного первичного ключа. (Таким образом, если отношение в 1НФ имеет простой первичный ключ, оно сразу находится во второй нормальной форме). Для того чтобы привести отношение ко 2НФ, нужно:

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

построить дополнительно одну или несколько проекций на часть составного ключа и атрибуты, функционально зависящие от этой части ключа. Третья нормальная форма основана на понятии транзитивной зависимости. Пусть X, Y, Z – атрибуты некоторого отношения. При этом XY и YZ, но обратное соответствие отсутствует, т.е. Z не зависит от Y или Y не зависит от X. Тогда говорят, что Z транзитивно зависит от X (XZ). – 10 – Третья нормальная форма (3НФ). Отношение находится в 3НФ, если оно находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Для того чтобы привести отношение к 3НФ, нужно:

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

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

Исключение составляют случаи, когда для транзитивной зависимости XZ (XY и YZ) либо Z зависит от Y, либо Y зависит от X, т.е. между атрибутами X и Y, например, существует связь 1:1. В такой ситуации декомпозиция отношения не производится. Четвертая нормальная форма основана на понятии многозначной зависимости. Многозначная зависимость существует, если заданным значениям атрибута X соответствует множество, состоящее из нуля (или более) значений атрибута Y (X–»Y). Различают тривиальные и нетривиальные многозначные зависимости. Тривиальной называется такая многозначная зависимость X–»Y, для которой Y X или X U Y = R, где R – рассматриваемое отношение. Тривиальная многозначная зависимость не нарушает 4НФ. Если хотя бы одно из двух этих условий не выполняется, то такая зависимость называется нетривиальной. Четвертая нормальная форма (4НФ). Отношение находится в 4НФ, если оно находится в 3НФ и в нём отсутствуют нетривиальные многозначные зависимости. Для того чтобы привести отношение к 4НФ, нужно построить две или более проекции исходного отношения, каждая из которых содержит ключ и одну из многозначных зависимостей.

Первая нормальная форма (1НФ).

Отношение приведено к 1НФ, если все его атрибуты простые.

Для того чтобы привести к 1НФ отношение, содержащее сложные атрибуты, нужно:

1) разбить составные атрибуты на простые,

2) построить декартово произведение всех многозначных атрибутов с кортежами, к которым они относятся.

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

Вторая нормальная форма основана на понятии функциональной зависимости. Пусть X и Y – атрибуты некоторого отношения. Если в любой момент времени каждому значению X соответствует единственное значение Y, то говорят, что Y функционально зависит от X (XY). Атрибут X в функциональной зависимости XY называется детерминантом отношения.

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

Вторая нормальная форма (2НФ).

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

(Таким образом, если отношение в 1НФ имеет простой первичный ключ, оно сразу находится во второй нормальной форме).

Для того чтобы привести отношение ко 2НФ, нужно:

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

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

Третья нормальная форма (3НФ).

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

Для того чтобы привести отношение к 3НФ, нужно:

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

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

Четвертая нормальная форма основана на понятии многозначной зависимости. Многозначная зависимость существует, если заданным значениям атрибута X соответствует множество, состоящее из нуля (или более) значений атрибута Y (X–»Y).

Различают тривиальные и нетривиальные многозначные зависимости. Тривиальной называется такая многозначная зависимость X–»Y, для которой Y U X или X U Y = R, где R – рассматриваемое отношение. Тривиальная многозначная зависимость не нарушает 4НФ. Если хотя бы одно из двух этих условий не выполняется, то такая зависимость называется нетривиальной [3].

Четвертая нормальная форма (4НФ).

Отношение находится в 4НФ, если оно находится в 3НФ и в нём отсут-ствуют нетривиальные многозначные зависимости.

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

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

2.1. Инфологическое проектирование

2.2.1. Анализ предметной области

База данных «Оздоровительного комплекса» создаётся для выполнения услуг, ведения количества клиентов, предоставления отдыхающим возможности развивать и улучшать свои физические данные. Многие оздоровительные комплексы, которые работают на территории нашей страны, сегодня имеют свои официальные представительства и информационные порталы в сети Internet. На своих сайтах данные комплексы расписывают все предоставляемые услуги и график работы. Также многие оздоровительные комплексы содержат персонал подготовки спортсменов и обычных отдыхающих к участию в различных спортивных мероприятиях в самых разных видах спорта, от индивидуальных до командных.

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

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

Что относится к основной деятельности оздоровительного комплекса?

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

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

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

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

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

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

Для создания ER-модели необходимо выделить сущности предметной области:

Исходя из выявленных сущностей, построим ER-диаграмму (рис. 2). Пометки у линии означают степень связи: 1:1, 1:N и N:M.

Рис. 2 – ER-диаграмма предметной области

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

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

Все упражнения составляются на основе потребностей отдыхающих и советов специалистов.

База данных оздоровительного комплекса решает такие задачи, как:

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

Пользователи базы данных:

2.2. Определение требований к операционной обстановке

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

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

Объём внешней памяти, необходимый для функционирования системы, складывается из двух составляющих: память, занимаемая модулями СУБД (ядро, утилиты, вспомогательные программы), и память, отводимая под данные (МД). Наиболее существенным обычно является МД. Объём памяти МД, требуемый для хранения данных, можно приблизительно оценить по формуле где li – длина записи в i-й таблице (в байтах), Ni – примерное (максимально возможное) количество записей в i-й таблице, Na – количество записей в архиве i-й таблицы.

Минимальные требования к ПК:

Проектирование проводилось в СУБД Microsoft Access 2013, на ПК с характеристиками Intel Core i5 6400, 8 гигабайт оперативной памяти, SSD на 128 гигабайт, а также жёсткий диск размером 1024 гигабайта или же 1 терабайт.

2.3. Выбор СУБД и других программных средств

Анализ информационных задач показывает, что для реализации требуемых функций подходят почти все СУБД для ПЭВМ (MS Access, Firebird, MySQL и др.). Все они поддерживают реляционную модель данных и предоставляют разнообразные возможности для работы с данными. Объём внешней и оперативной памяти, требующийся для функционирования СУБД, обычно указывается в сопроводительной документации.

2.4. Логическое проектирование реляционной БД

2.4.1. Преобразование ER–диаграммы в схему базы данных

База данных создаётся на основании схемы базы данных. Для преобразования ER–диаграммы в схему БД приведём уточнённую ER–диаграмму, содержащую атрибуты сущностей (рис. 3).

Рис. 3 – Уточнённая ER–диаграмма предметной области

Преобразование ER–диаграммы в схему БД выполняется путем сопоставления каждой сущности и каждой связи, имеющей атрибуты, отношения (таблицы) БД. Связь типа 1: n (один-ко-многим) между отношениями реализуется через внешний ключ. Ключ вводится для того отношения, к которому осуществляется множественная связь. Внешнему ключу должен соответствовать первичный или уникальный ключ основного (родительского) отношения [6, с. 102].

Связь входить между УПРАЖНЕНИЯ и УКАЗАНИЕ УСЛУГ принадлежит к типу n:m (многие-ко-многим). Этот тип связи реализуется через вспомогательное отношение входить, которое содержит комбинации первичных ключей соответствующих исходных отношений.

Более подробно о принципах преобразования ER-диаграммы в схему БД рассказано в [1].

Для схемы БД будем использовать обозначения, представленные на рис. 4.

<Object: word/embeddings/oleObject2.bin>

Рис. 4 – Обозначения, используемые на схеме базы данных

Полученная схема реляционной базы данных (РБД) приведена на рис. 5.

Рис. 5 – Схема РБД, полученная из ER–диаграммы проектной организации

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

Схема на рис. 5 содержит два цикла: "упражнения-входить-оказание услуг" и "отдыхающие-упражнения-входить-оказание услуг". Цикл допустим только в том случае, если связи, входящие в него, независимы друг от друга. Например, для нашей ПрО справедливо такое правило: сотрудник любого отдела может быть участником (исполнителем или консультантом) проекта любого отдела. Эти связи независимы, поэтому цикл не будет приводить к нарушению логической целостности данных.

2.4.2. Составление реляционных отношений

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

Отношения приведены в табл. 1-5. Для каждого отношения указаны атрибуты с их внутренним названием, типом и длиной. Типы данных обозначаются так: N – числовой, C – символьный тип фиксированной длины, V – символьный тип переменной длины, D – дата (этот тип имеет стандартную длину, зависящую от СУБД, поэтому она не указывается). О правилах выбора типов данных подробно рассказано в [2, с. 89].

Потенциальными ключами отношения ОТДЫХАЮЩИЕ являются атрибуты

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

Для схемы отношения (таб. 1) ОТДЫХАЮЩИЕ после анализа выбранным первичным ключом становится поле Код.

Таблица 1. Схема отношения ОТДЫХАЮЩИЕ (Guests)

Для схемы отношения (таб. 2) УСЛУГИ после анализа выбранным первичным ключом становится поле Код.

Таблица 2. Схема отношения УСЛУГИ(Services)

Для схемы отношения (таб. 3) УПРАЖНЕНИЯ после анализа выбранным первичным ключом становится поле Код упражнения.

Таблица 3. Схема отношения УПРАЖНЕНИЯ(Exercises)

Для схемы отношения (таб. 4) ОКАЗАНИЕ УСЛУГИ после анализа выбранным первичным ключом становится поле Код оплаты.

Таблица 4. Схема отношения ОКАЗАНИЕ УСЛУГИ (Doing Services)

2.4.3. Нормализация полученных отношений (до 4НФ)

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

1НФ. Для приведения таблиц к 1НФ требуется составить прямоугольные таблицы (одно значение атрибута – одна ячейка таблицы) и разбить сложные атрибуты на простые.

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

2НФ. В нашем случае все отношения находятся во второй нормальной форме. Так как ни в одном отношении нет составных ключей.

3НФ. Все отношения удовлетворяют условиям третьей нормальный формы.

4НФ. Также все отношения находятся в третьей нормальной форме.

Нормализованные отношения представлены в таблицах 5-8.

Таблица 5. Схема отношения ОТДЫХАЮЩИЕ (Guests)

Таблица 6. Схема отношения УСЛУГИ(Services)

Таблица 7. Схема отношения УПРАЖНЕНИЯ(Exercises)

Таблица 8. Схема отношения ОКАЗАНИЕ УСЛУГИ (Doing Services)

Перечислим ограничения целостности, которые не указаны в табл. 1-4.

2.4.4. Описание групп пользователей и прав доступа

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

s – чтение данных (select);

i – добавление данных (insert);

u – модификация данных (update);

d – удаление данных(delete).

Таблица 9. Права доступа к таблицам для групп пользователей

2.5. Реализация проекта базы данных

2.5.1. Создание таблиц

Мы условились не привязываться к конкретной СУБД и выполнять описание логической схемы БД на SQL-92. Приведём описание схемы БД.

1. Отношение ОТДЫХАЮЩИЕ (Guests):

Create table guests (

g_id numeric(4) primary key,

g_date date not null,

g_sname varchar(50) not null,

g_name varchar(50) not null,

g_fname varchar(50) not null,

g_days varchar(365) not null,

g_sex varchar(1) check(g_sex in ('ж','м')),

g_age varchar(30) not null uniqie,

g_phonenumber varchar(20) not null unique

)

2. Отношение УСЛУГИ (Services):

Create table services (

s_id numeric(4) primary key,

s_serv varchar(25) not null,

s_time varchar(20) not null,

s_intime varchar(10) not null,

s_cost varchar(10) no nutll

)

3. Отношение УПРАЖНЕНИЯ (Exercises):

Create table exercises (

e_id numeric(4) primary key,

e_idofguest numeric(4) secondary key,

e_datet date not null,

e_exercise varchar(25) not null,

e_dest numeric(50) not null,

e_air varchard(1) check(e_air in ('+','-')),

e_pulse varchar(5) not null,

e_callories varchar(10) not null

)

4. Отношение ОКАЗАНИЕ УСЛУГИ (Doing Services):

Create table doing services (

d_id numeric(6) primary key,

d_service varchar(100) not null,

d_idofguest varchar(10) not null uniqie,

d_time varchar(10) not null

)

2.5.2. Создание представлений (готовых запросов)

Приведу примеры нескольких готовых запросов (представлений):

Месяц: Month(Отдыхающие!Дата_приезда)

Год: Year([Дата_приезда])

СтоимостьУслуг: Sum-СтоимостьУслуги

Общая стоимость: [Стоимость проживания].СтоимостьПроживания+[Общая стоимость услуг по отдыхающим].[Sum-СтоимостьУслуги]

Стоимость услуг

СтоимостьПроживания: [Месяц-Год].Количество_суток*[Стоимость 1 дня].[Стоимость 1 дня]

СтоимостьУслуги: Услуги.[Стоимость 1 сеанса]*[Оказание услуг].Время/Услуги.[Продолжительность 1 сеанса]

Для того чтобы можно было работать с этими представлениями, соответствующим пользователям нужно назначить права доступа к представлениям. Эти права перечислены в табл. 10.

Таблица 10. Права доступа к представлениям

2.5.3. Назначение прав доступа

Права доступа пользователей предоставляются с помощью команды GRANT. Рассмотрим для примера права сотрудника компании ok_user, который является сотрудником отдела кадров. Права доступа к отношениям Departs и Rooms могут быть описаны следующим образом:

grant select, insert, update, delete on departs to ok_user;

grant select, insert, update, delete on rooms to ok_user;

Права доступа руководителей проектов (сотрудников, staff) к представлению my_projects могут быть описаны следующим образом:

grant select, insert, update, delete on my_projects to staff;

Если сотрудник не является руководителем проекта, он не получит данных через этот запрос и не сможет воспользоваться правами доступа к нему.

Права доступа участников проекта (сотрудников, staff) к представлению my_emps могут быть описаны следующим образом:

grant select on my_emps to staff;

Если сотрудник не является участником проекта, он не получит данных через этот запрос и не сможет воспользоваться правами доступа к нему [8, с. 163].

2.6. Разработка интерфейса пользователя

2.6.1. Построение форм

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

Главная форма. В ней предусмотрены следующие возможности: Получение общих сведений о сотруднике; Количество сотрудников в отделе; Заработная плата сотрудников; Фонда заработной платы в каждом отделе.

Главная форма объединяет все второстепенные формы (рис. 6). Такие как: Заработная плата; Количество сотрудников в отделе и т.д. Также она содержит кнопки «Услуги», «Отдыхающие», «Стоимость 1 дня», «Поиск» и «Выйти из приложения».

Рис. 6 – «Главная» форма

Форма для получения информации об отдыхающих (рис. 7). Содержит в себе формы для ввода «Код Отдыхающего», «Дата приезда», «Фамилия», «Имя», «Отчество», «Количество суток», «Возраст», «Телефон», а также кнопки «Упражнения» и «Оказание услуг».

Рис. 7 – форма «Отдыхающие»

Форма для того, чтобы узнать стоимость 1 дня в определенный месяц года (рис. 8). Содержит в себе столбы «Месяц», «Год», «Стоимость 1 дня» и данные в них.

Рис. 8 – форма «Стоимость 1 дня»

Форма для того, чтобы узнать все виды услуг и время работы (рис. 9). Содержит в себе столбцы «Код Услуги», «Вид Услуги», «Время работы», «Продолжительность 1 сеанса», «Стоимость 1 сеанса», а также данные, которые были внесены в них.

Рис. 9 – форма «Услуги»

Форма, чтобы узнать упражнения, которые предоставляет оздоровительный комплекс (рис. 10). Содержит в себе формы для ввода «Код Упражнения», «Код отдыхающего», «Дата тренировки», «Упражнение», «Расстояние (км)», «На открытом воздухе», «Обычная частота пульса», «Сожжено калорий».

Рис. 10 – форма «Упражнения»

2.6.2. Отчёты

Приведем примеры отчетов. Здесь мы можем увидеть отчёт по представленным услугам (рис. 11).

Рис. 11 – отчёт по предоставленным услугам

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

Рис. 12 – отчёт «Общая стоимость»

ЗАКЛЮЧЕНИЕ

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ