Проектирование базы данных

+ база
Введение
1. Таблицы и формы, используемые в базе
2. Запросы, используемые в базе
3. Отчеты, используемые в базе
4. Администрирование базы данных
4.1 Создание и управление базы данных
4.2 Модификация базы данных
4.3 Настройка параметров базы данных
4.4 Восстановление данных
4.5 Резервное копирование
4.6 Обеспечение безопасности
Список используемой литературы

Действия, выполняемые в БД, отслеживаются с помощью аудита SQL Server. Механизм аудита SQL Server, в отличие от службы Event Log в Windows NT и Windows 2000, создан специально для аудита объектов БД. Некоторые объекты БД, например хранимые процедуры, разрешается зашифровать, чтобы защитить их содержимое.
SQL Server 2000 поддерживает два режима аутентификации: средствами Windows и средствами SQL Server. Первая позволяет локальным или доменным учетным записям Windows (Windows NT или Windows 2000) подключаться к SQL Server. Вторая дает пользователям возможность подключаться к SQL Server с помощью идентификатора SQL Server. Допустимо сконфигурировать метод аутентификации на сервере во время установки SQL Server или позже с помощью диалогового окна SQL Server Properties (Configure) в Enterprise Manager (рис. 13-2).
Параметры режима аутентификации позволяют использовать аутентификацию средствами Windows и SQL Server одновременно или только аутентификацию средствами Windows. Режим, в котором применяются оба метода аутентификации, называется смешанный режим (Mixed Mode).
Использование аутентификации средствами Windows позволяет создать интегрированную систему регистрации пользователя, поскольку SQL Server использует ОС локального компьютера или контролера домена для проверки и сопровождения учетной записи пользователя. Например, если UserOl — локальная пользовательская учетная запись, созданная на автономном сервере SQL с именем ServerOl, можно предоставить учетной записи SERVER01 \User01 право на подключение к SQL Server или отобрать у нее это право. Если User02 — доменная учетная запись, созданная на контроллере домена DomainOl, можно дать или отобрать право на подключение к SQL Server у записи DOMAIN01\User02.
Также разрешено наделять привилегиями и лишать их группы Windows NT и Windows 2000. Привилегии, предоставленные группе или отобранные у нее, наследуют все ее члены. Явный отказ в предоставлении доступа (deny) заменяет все другие привилегии, назначенные пользователю или любым группам, членом которых он может быть. В Windows NT и Windows 2000 предусмотрены два типа групп, которым могут быть предоставлены права на подключение к серверу: группы на локальном компьютере и доменные группы. Первые хранятся в ОС компьютера, на котором работает SQL Server, и подразделяются на два типа: встроенные и пользовательские. Доменные группы хранятся на контроллерах домена Windows, они бывают трех типов: локальные для домена, глобальные и универсальные.
Аутентификация выполняется успешно, если учетной записи пользователя или его группе предоставлено право на подключение к SQL Server. При аутентификации средствами Windows пользователь может регистрироваться как на локальном компьютере SQL Server, так и на любом компьютере домена, при этом отдельная регистрация в SQL Server не требуется. Если настроена смешанная аутентификация, то методом по умолчанию для подключения к SQL Server является аутентификация средствами Windows.
Случаи, когда аутентификация средствами SQL Server является единственным способом подключения к SQL Server, перечислены ниже:
когда клиент и сервер относятся к разным пространствам имен идентификаторов.Если компьютер с SQL Server является автономным сервером, то клиент, зарегистрированный в домене, должен использовать аутентификацию средствами SQL Server. Клиент может использовать аутентификацию средствами Windows, если он зарегистрировался локально, SQL Server сконфигурирован как автономный сервер, а также на клиенте и сервере существуют одинаковые комбинации «учетная запись — пароль»;
когда SQL Server работает в Windows 98 или Windows ME.
SQL Server, установленный в Windows 98 или Windows ME, поддерживает только аутентификацию средствами SQL Server;
• если приложение написано специально для использования аутентификации средствами SQL Server.
Некоторые учетные имена SQL Server (SQL Server account objects) создаются во время установки SQL Server, например системный администратор SQL Server (sa). Это учетное имя приписывается фиксированной роли на уровне сервера (серверной роли) Sys-Admin, и его нельзя удалить или модифицировать. Идентификатору sa соответствует особое пользовательское учетное имя: владелец базы данных (dbo), которое создается в каждой БД. Помимо прочего, это соответствие делает dbo членом группы SysAdmin. О серверных ролях рассказано в следующем разделе этого занятия. Другое специальное учетное имя — guest — открывает доступ к БД любому пользователю, проверенному SQL Server.
Чтобы пользовательское учетное имя получило доступ к БД, одной аутентификации недостаточно. Кроме этого, у учетного имени, группы или роли, прошедшей аутентификацию, должно быть разрешение на исполнение SQL-выражений или на работу с объектами. Как правило, авторизация осуществляется в контексте БД. Таким образом ограничивается область видимости пользовательского доступа. Например, разрешение на доступ к таблице из БД Pubs не дает пользователю права на доступ к объектам БД Master. Однако есть особые административные разрешения, область видимости которых распространяется на весь SQL Server.
Назначение разрешений каждому пользователю в отдельности занимает много времени при сопровождении БД со средним и большим числом пользователей; Для облегчения рутинных административных операций по назначению разрешений пользователям SQL Server 2000 поддерживает группы Windows и роли SQL Server. Все группы, прошедшие аутентификацию, также подлежат авторизации. Например, глобальной доменной группе GlobalGroupO 1 в домене DomainOl назначен ряд привилегий для подключения к SQL Server (аутентификации) и исполнения оператора SELECT для некоторой таблицы или представления в этой БД. В этом случае любые пользователи из домена — члены группы GlobalGroupO 1 — смогут исполнить оператор SELECT (если где-либо еще для этого разрешения не задано состояние Deny, о котором мы расскажем чуть позже).
Роли похожи на группы, но создаются и сопровождаются в рамках SQL Server. Существует два типа ролей: стандартные и прикладные. Стандартным ролям (standard roles) назначаются привилегии, которые могут наследоваться пользователями, получающими членство в роли. Членами групп могут быть пользователи Windows и (в зависимости от типа группы) группы Windows. В отличие от групп стандартные роли могут содержать все типы учетных имен: учетные записи пользователей и групп Windows, идентификаторы SQL Server и другие стандартные роли.
Поскольку привилегии являются кумулятивными, то с помощью вложенных групп и стандартных ролей (групп, содержащих другие группы и роли, которые тоже содержат группы и роли) можно построить иерархию привилегий. Например, если пользователю UserOl назначена роль Role02, а сама она входит в RoleOI, то роль Role02 является вложенной для RoleOl. Если назначить ролям RoleOI и Role02 разные привилегии, то пользователь UserOl будет обладать всеми привилегиями, назначенными для обеих ролей.
Для упрощения администрирования БД и самого сервера в SQL Server предусмотрен ряд стандартных предопределенных ролей. В основном их можно разделить на две категории: фиксированные роли на уровне сервера, или серверные роли (fixed server role), и фиксированные роли на уровне БД (fixed database role). Членство в фиксированных ролях на уровне сервера дает возможность администрирования сервера. Например, если сделать пользователя членом фиксированной серверной роли ServerAdmin, то он сможет настраивать общесерверные параметры. Программа SQL Server Setup приписывает группу администраторов Windows (BUILTIN\Administrators) к фиксированной серверной роли SysAdmin. Члены фиксированных ролей на уровне БД могут администрировать некоторые БД. Например, если сделать пользователя членом фиксированной роли на уровне БД db_BackupOperator, он сможет создавать резервные копии этой БД. Чтобы просмотреть привилегии, назначенные для каждой фиксированной серверной роли, исполните команду sp_srvrolepermission имя_фиксированной_серверной_роли, где sp_srvrolepermission — имя системной хранимой процедуры.
Все пользователи, группы и роли автоматически являются членами роли Public. Эта специальная роль похожа на специальную группу Everyone в Windows NT и Windows 2000. Добавлять или удалять членов этой роли, как и саму роль, нельзя. Роль Public есть в каждой БД, где по умолчанию для нее назначен ряд разрешений. Для защиты БД можно отобрать эти разрешения у роли Public. Если группы Windows не соответствуют административным потребностям, можно создать стандартные роли на уровне базы данных.
Иногда приложению и пользователю требуются разные разрешения. В этом случае непрактично конфигурировать безопасность приложения с помощью разрешений SQL Server. В SQL Server предусмотрены прикладные роли (application roles), обеспечивающие поддержку разрешений только для приложения. Прикладные роли не содержат членов и должны передавать пароль. Эти особые роли разработаны для управления привилегиями пользователей, обращающихся к БД через некоторое приложение. Прикладным ролям назначаются разрешения на уровне базы данных. После проверки пользователя прикладная роль активируется с помощью системной хранимой процедуры sp_setapprole, которая позволяет зашифровать пароль прикладной роли перед передачей его на сервер. Когда активна прикладная роль, пользователь теряет все свои разрешения до конца сеанса или работы приложения. Если приложение должно обратиться к другой БД в период активности прикладной роли, оно сможет получить для этой БД лишь те разрешения, которые назначены учетному имени guest.
Разрешение может быть предоставлено (Grant), снято (Revoke) или в нем может быть отказано (Deny). При предоставлении разрешения пользователю, группе или роли (любому учетному имени) командой Grant разрешение назначается явно. При снятии разрешения с учетного имени (командой Revoke) последнее теряет соответствующее разрешение. Наконец, при отказе в предоставлении разрешения (с помощью команды Deny) на получение этого разрешения налагается явный запрет. Пользовательские разрешения представляют собой сумму всех разрешений, назначенных непосредственно этому пользователю или его группе. Сначала SQL Server обрабатывает состояние Deny, которое отнимает разрешение — независимо от способа его получения. Поэтому, если пользователь наследует это состояние или получает его явно, оно исключает все другие разрешения. Допустим, пользователю UserOl дано разрешение на исполнение оператора SELECT для таблицы TableOl. Этот пользователь является членом группы GroupO 1, обладающей разрешением на исполнение оператора INSERT для той же самой таблицы. В результате учетное имя этого пользователя получает права на исполнение операторов SELECT и INSERT для таблицы TableOl. Однако если группа GroupO 1 является членом роли RoIeOl, у которой разрешения SELECT и INSERT находятся в состоянии Deny, пользователь не сможет ни извлечь данные из таблицы TableOl, ни добавить в нее данные.
В SQL Server предусмотрены разрешения трех типов: разрешения на работу с объектами (object permissions), разрешения на выполнение SQL-операторов (statement permissions) и предполагаемые разрешения (implied permissions). Разрешения на работу с объектами относятся к объектам БД и могут различаться для разных объектов. Например, для хранимой процедуры допустимо назначить разрешение EXECUTE, а для таблицы — SELECT. Разрешения на выполнение SQL-операторов применяются к операторам Transact-SQL CREATE и BACKUP, исполняемым в БД. Например, разрешение CREATE TABLE дает пользователю возможность создавать таблицы в БД. Далее перечислены разрешения на работу с объектами и выполнение SQL-операторов для различных объектов БД.
Табл. 4.5
Разрешения на работу с объектами и выполнение SQL - операторов
Разрешение Разрешаемое действие CREATE (разрешение на выполнение SQL-оператора)
Создание БД, таблиц, представлений, хранимых процедур, определений умолчания, правил и функций
BACKUP (разрешение на выполнение SQL-оператора)
Резервное копирование БД и файла журнала
SELECT и UPDATE (разрешение на работу с объектом)
Запросы и модификация таблиц, представлений и их столбцов
INSERT и DELETE (разрешение на работу с объектом)
Добавление и удаление таблиц, представлений и их записей EXECUTE (разрешение на работу с объектом)
Выполнение хранимых процедур
Предполагаемые разрешения назначаются владельцам объектов, фиксированным ролям на уровне сервера и баз данных; их нельзя отобрать. Некоторые предполагаемые разрешения на выполнение SQL-операторов можно получить только через членство в фиксированной серверной роли. Например, чтобы иметь право на исполнение оператора SHUTDOWN, пользователь должен быть членом фиксированной серверной роли ServerAdmin.
Служба Event Log обеспечивает общий аудит ОС Windows NT и Windows 2000. SQL Server поддерживает аудит идентификаторов и событий системы безопасности. Успех или неудача аутентификации того или иного пользователя — это серверный параметр, который разрешается сконфигурировать на вкладке Security диалогового окна SQL Server Properties.
Чтобы задействовать аудит, следует настроить его с помощью SQL Profiler. События системы безопасности регистрируются в файле или в таблице БД. Необходимо указать подлежащие аудиту события, столбцы для трассировки и свойства для хранения трассировочного файла или таблицы. После выполнения трассировки событий системы безопасности с помощью SQL Profiler, файл трассировки открывают в нем же или выполняют запрос к трассировочной таблице.
Шифрование объектов
Шифрование данных ограничивает доступ к информации путем хранения ее в формате, трудно поддающемся расшифровке. Программы расшифровывают данные с помощью дешифрующего алгоритма и ключа. В SQL Server 2000 имеется алгоритм для расшифровки и анализа зашифрованных объектов БД. Пароли и зашифрованные объекты в SQL Server не разрешено просматривать ни одному пользователю БД (в том числе членам фиксированной серверной роли SysAdmin). SQL Server 2000 автоматически шифрует пароли, ассоциированные с идентификаторами. При желании можно зашифровать текст хранимых процедур, пользовательских функций, представлений и триггеров, воспользовавшись при создании этих объектов БД конструкцией WITH ENCRYPTION.
Обращающееся к БД приложение вызывает системную хранимую процедуру sp_setapprole, чтобы активировать прикладную роль. Кроме того, в приложении иногда реализована собственная система безопасности, неподконтрольная БД. Для изоляции приложений от деталей механизма доступа к данным применяются API доступа к данным, поддерживаемые SQL Server, например ADO, OLE DB и ODBC. Приложения должны обеспечивать безопасность при обращении к данным SQL Server. Например, в Internet Explorer предусмотрена защита от действий опасных сценариев.

Список используемой литературы
Карпов Борис «Microsoft Access 2000: справочник», С-Пб, «Питер», 2001г.
Робинсон С. «Microsoft Access 2000: Учебный курс»,С-Пб, «Питер», 2001 г.
Стив Силва «Администрирование веб-серверов», Москва, «Кудиц-образ», 2004 г.
Эйткен Питер «Разработка приложений на VBA в среде Office XP», С-Пб, «Вильямс», 2003г.