Экзаменационный билет № 15

1. Назначение серверных ролей и ролей баз данных

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

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

• db_owner – включает в себя права все других ролей базы данных. Пользователь получает права владельца базы.

• db_accessadmin – похожа на серверную роль securityadmin, за исключением того, что ограничена одной базой данных. Она не позволяет создавать новые логины MS SQL Server, но разрешает добавлять новых пользователей в базу данных.

• db_datareader – разрешает выполнение оператора SELECT для всех таблиц базы данных.

• db_datawriter – разрешает выполнять INSERT, UPDATE и DELETE для всех таблиц базы данных.

• db_ddladmin – позволяет добавлять, удалять и изменять объекты в базе данных.

• db_securityadmin – еще одна роль похожая на серверную роль securityadmin. В отличие от db_accessadmin, она не разрешает создавать новых пользователей в базе, но позволяет управлять ролями и членством в ролях, а также правами на доступ к объектам базы данных.

• db_backupoperator – позволяет создавать резервные копии базы данных.

• db_denydatareader – запрещает выполнение SELECT для всех таблиц базы данных.

• db_denydatawriter – запрещает выполнение INSERT, UPDATE и DELETE для всех таблиц базы данных.

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

Для отображения списка ролей сервера необходимо выбрать группу Server Roles в папке Security сервера. Просмотр пользователей, входящих в эту роль и разрешений, присвоенный ей, осуществляется выполнением команды Действие – Свойства.

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

2. СУБД в архитектуре "клиент-сервер"

Рис. 1. Архитектура «клиент-сервер»

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

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

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

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

функции ввода и отображения данных;

прикладные функции, характерные для предметной области;

фундаментальные функции хранения и управления ресурсами (базами данных);

служебные функции.

Исходя из этого деления любое приложение может состоять из следующих компонентов:

компонент представления (функции 1-й группы);

прикладной компонент (функции 2-й группы);

компонент доступа к информационным ресурсам (функции 3-ей группы и протокол их взаимодействия).

Различия определяются четырьмя факторами:

какие виды программного обеспечения в логических компонентах;

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

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

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

Исходя из этого, рассмотрим четыре подхода, реализованные в моделях технологии «клиент-сервер».

FS-модель

Базовая для локальных сетей персональных компьютеров. Применялась для разработки информационных систем на базе FoxPRO, Clipper, Paradox.

Основные свойства:

выделяется файл-сервер для реализации услуг по обработке файлов других узлов сети; работает под управлением сетевых ОС;

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

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

протокол обмена - набор низкоуровневых вызовов.

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

Недостатки:

высокий сетевой трафик;

небольшое число операций манипулирования;

недостаточные требования к безопасности

3. Процедуры концептуального проектирования

Цель этапа концептуального проектирования - создание концептуальной модели данных исходя из представлений пользователей о предметной области. Для ее достижения выполняется ряд последовательных процедур.  Определение сущностей и их документирование. Для идентификации сущностей определяются объекты, которые существуют независимо от других. Такие объекты являются сущностями. Каждой сущности присваивается осмыс­ленное имя, понятное пользователям. Имена и описания сущностей заносятся в словарь данных. Если возможно, то устанавливается ожидаемое количество эк­земпляров каждой сущности.  Определение связей между сущностями и их документирование. Определяются только те связи между сущностями, которые необходимы для удовлетворения требований к проекту базы данных. Устанавливается тип каж­дой из них. Выявляется класс принадлежности сущностей. Связям присваива­ются осмысленные имена, выраженные глаголами. Развернутое описание каж­дой связи с указанием ее типа и класса принадлежности сущностей, участвую­щих в связи, заносится в словарь данных.  Создание ER-модели предметной области. Для представления сущ­ностей и связей между ними используются ER-диаграммы. На их основе созда­ется единый наглядный образ моделируемой предметной области - ER-модель предметной области.  Определение атрибутов и их документирование. Выявляются все ат­рибуты, описывающие сущности созданной ER-модели. Каждому атрибуту присваивается осмысленное имя, понятное пользователям. О каждом атрибуте в словарь данных помещаются следующие сведения: имя атрибута и его описание; тип и размерность значений; значение, принимаемое для атрибута по умолчанию (если такое имеется); может ли атрибут иметь Null-значения; является ли атрибут составным, и если это так, то из каких простых атрибу­тов он состоит. Например, атрибут "Ф.И.О. клиента" может состоять из про­стых атрибутов "Фамилия", "Имя", "Отчество", а может быть простым, содер­жащим единые значения, как-то "Сидорский Евгений Михайлович". Если поль­зователь не нуждается в доступе к отдельным элементам "Ф.И.О.", то атрибут представляется как простой; • является ли атрибут расчетным, и если это так, то как вычисляются его зна­чения.  Определение значений атрибутов и их документирование. Для каж­дого атрибута сущности, участвующей в ER-модели, определяется набор до­пустимых значений и ему присваивается имя. Например, атрибут "Тип счета" может иметь только значения "депозитный", "текущий", "до востребования", "карт-счет". Обновляются записи словаря данных, относящиеся к атрибутам, -в них заносятся имена наборов значений атрибутов.  Определение первичных ключей для сущностей и их документиро­вание. На этом шаге руководствуются определением первичного ключа - как атрибута или набора атрибутов сущности, позволяющего уникальным образом идентифицировать ее экземпляры. Сведения о первичных ключах помещаются в словарь данных.  Обсуждение концептуальной модели данных с конечными пользо­вателями. Концептуальная модель данных представляется ER-моделью с со­проводительной документацией, содержащей описание разработанной модели данных. Если будут обнаружены несоответствия предметной области, то в мо­дель вносятся изменения до тех пор, пока пользователи не подтвердят, что предложенная им модель адекватно отображает их личные представления.