Инфологическая модель базы данных "Защита доступа" (стр. 1 из 4)

СОДЕРЖАНИЕ

Введение. 2

1. Системный анализ предметной области. 4

1.1. Краткая характеристика предметной области. 4

1.2. Описание предметной области. 13

2. Инфологическое моделирование. 18

2.1.Модель «сущность-связь». 18

2.2. Связи между сущностями инфологической модели. 20

Заключение. 23

Список литературы.. 24

Введение

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

Основными задачами, поставленными в ходе работы, являлись:

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

- отбор необходимых документов для создания базы данных;

- выявление сущностей инфологической модели и моделирование связей между ними.

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

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

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

Для проектирования БД одной из концепционных является модель «сущность-связь». С помощью сущности моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов – характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности.

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

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

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

1. Системный анализ предметной области

1.1. Краткая характеристика предметной области

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

Суть модели файлового сервера состоит в том, что один из компьютеров в сети считается файловым сервером и предоставляет услуги по обработке файлов другим компьютерам. Файл-сервер работает под управлением сетевой операционной системы и играет роль компонента доступа к информационным ресурсам. На других компьютерах в сети функционирует приложение, в котором функции представления информации и логика прикладной обработки совмещены. Обращение за сервисом управления данными происходит через среду передачи с помощью операторов языка SQL или вызовом функций библиотеки API (ApplicationProgrammingInterface – интерфейс прикладного программирования). Основное достоинство такой модели состоит в большом обилии готовых СУБД, имеющих SQL-интерфейсы, и существующих инструментальных сердств, обеспечивающих быстрое создание программ клиентской части. Средства разработки чаще всего поддерживают графический интерфейс пользователя в MSWindows, стандарт интерфейса ODBC и средства автоматической генерации кода.

Недостатки модели файл-сервер:

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

во время работы приложений обычно по сети передаются целые БД);

узкий спектр операций манипуляции с данными;

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

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

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

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

Так как обработка запросов осуществляется на сервере базы данных, а не на рабочей станции, рабочая станция называется клиентом сервера базы данных. При работе в режиме клиент-сервер серверная часть системы управления базами данных устанавливается на файл-сервере, а клиентская часть — на рабочей станции. В ряде случаев клиентская и серверная части являются отдельными компонентами одной СУБД (например, Oracle или SQLbase). В других случаях в качестве клиентской части используются настольные СУБД или специальные системы разработки приложений клиент/сервер (например, PowerBuilderили SQLWindows), а в качестве сервера базы данных — мощная СУБД типа Oracle или SQL Server.

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

первый – это сведение количества таких конфликтов к минимуму и

второй – разработка четкого алгоритма их разрешения.

Таблица 1

Низкая конкуренция (случай 1)	Высокая конкуренция (случай 2)
Блокировка записи	Запись данных в переменные
Чтение записи	Чтение переменных
Полноэкранное редактирование
Запрос на сохранение данных
Сохранение данных	Блокировка записи
--	Запись данных из переменных в БД
Снятие блокировки с записи

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

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

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