Shpory_po_SUBD
.pdf29.Создание, удаление, изменение хранимой процедуры.
Создание хранимой процедуры:
CREATE PROCEDURE] procedure_name [;number]
[ {@parameter data_type} [VARYING] [= default] [OUTPUT] ] [,..n] [WITH { RECOMPILE | ENCRYPTION | RECOMPILE,
ENCRYPTION } ]
[FOR REPLICATION]
AS sql_statement [...n]
procedure_name С помощью этого параметра указывается имя, которое будет иметь хранимая процедура
number Этот параметр предназначен для создания группы одноименных процедур. При этом дополнительно к имени хранимой процедуры можно указать через точку с запятой целое число, которое будет являться номером процедуры.
@parameter С помощью этого аргумента для хранимой процедуры указываются входные параметры. При вызове хранимой процедуры пользователь должен будет указать значения для этих параметров, если не определено значение по умолчанию.
data_type Этот параметр определяет тип данных, который будет иметь соответствующий параметр ХП.
VARYING Это ключевое слово используется только для параметров хранимой процедуры, имеющих тип данных cursor. Использование VARYING необходимо, когда в хранимой процедуре происходит создание динамического курсора и полученные данные нужно возвратить из процедуры для дальнейшего использования.
Default С помощью этого аргумента указывается значение по умолчанию, которое будет автоматически присваиваться соответствующему параметру хранимой процедуры, если при ее вызове пользователь не задал явного значения параметра.
OUTPUT Это ключевое слово приводится, когда необх. возвратить измененное значение параметра ХП.
WITH После этого ключевого слова приводятся дополнительные опции хранимой процедуры.
1)RECOMPILE. Использование этого параметра предписывает не выполнять кэширование плана выполнения хранимой процедуры. То есть всякий раз при вызове процедуры будет происходить генерирование плана обработки запроса.
2)ENCRYPTION. При указании данного параметра происходит шифрование кода процедуры в таблице syscomments, где хранится исходный текст процедуры.
3)FOR REPLICATION. Этот параметр применяется только при выполнении репликации хранимых процедур. Указанный тип репликации позволяет передавать от издателя к подписчикам не весь набор выполненных изменений, и лишь вызов хранимой процедуры со значениями всех входных параметров. Таким образом можно резко снизить объем сетевого трафика. Хранимая процедура, созданная на подписчике с использованием FOR REPLICATION, не может быть вызвана пользователем. Ее запуск разрешен только подсистеме репликации.
AS После этого ключевого слова начинается тело хранимой процедуры, которое содержит набор команд Transact-SQL.
sql_statement [...n]
Этот параметр подразумевает указание собственно команд Transact-SQL, из которых и формируется тело хранимой процедуры.
Изменение процедуры: ALTER PROCEDURE. Удаление процедуры: DROP PROCEDURE.
30.Функции: типы функций.
Пользовательские и встроенные Встроенные функции:
1)функции просмотра конфигурации (@@VERSION, @@OPTIONS, @@LANGUAGE, @@MAX_CONNECTIONS, @@SERVERNAME);
2)функции для работы с курсорами (@@CURSOR_ROWS,
@@FETCH_STATUS, @@CURSOR_STATUS);
3)функции работы с датой и временем(SYSDATETIME , GETDATE, DAY, MONTH, YEAR );
4)математические функции (ABS, SIN,SQRT);
5)функции метаданных (TYPE_NAME, FILE_NAME, KEY_NAME, DATABASEPROPERTY);
6)функции подсистемы безопасности (@@ERROR, HOST_ID, @@IDENTITY);
7)строковые функции (STR, UPPER, LOWER, REPLACE);
8)системные функции(@@ERROR, HOST_ID, @@IDENTITY);
9)статистические функции (@@CONNECTIONS, @@PACK_RECEIVED);
10)функции для работы с типами данных image, text и ntext (PATINDEX, TEXTPTR, TEXTVALID).
Все встроенные функции, как правило, имеют имена, начинающиеся с @@.
31.Пользовательские функции.
Типы определяемых пользователем функций:
Scalar. Функция Scalar может содержать множество команд, объединяемых конструкцией BEGIN…END в одно целое, и возвращает скалярное значение любого из типов данных, поддерживаемого SQL Server, за исключением timestamp, text, ntext, image, table и cursor.
Inline. Функции этого типа всегда возвращают значения типа данных table, представляющие собой сложный набор данных. Кроме того, функция Inline может состоять всего из одной команды SELECT. Их особенностью является то, что код функции при выполнении программы вставляется непосредственно в исполняемый набор команд, т.е. происходит не вызов функции, а встраивание.
Multi-Scalar. Как и функции предыдущего типа, функции Multi-Scalar возвращают значение типа данных table. Однако в отличие от первых, функции рассматриваемого типа могут состоять более чем из одной команды, что дает возможность использовать в теле функции транзакции, курсоры, вызывать хранимые процедуры и т. д. Как и при работе с функциями Scalar, при использовании более одной команды следует применять конструкцию BEGIN...END.
Функции, возвращающие значения типа данных table (Inline и Multi-Scalar), могут вызываться непосредственно в разделе from при работе с запросами SELECT, INSERT, DELETE и UPDATE.
Недопустимые типы входных параметров: image, text, ntext, cursor и table. Нельзя применять для возврата значений ключевое слово OUTPUT. Тем не менее, можно определять значения по умолчанию.
При программировании функций не разрешается использование команд, которые могут вернуть значения непосредственно в соединение(PRINT, FETCH). Однако применение команды FETCH для помещения данных из курсора в локальные переменные допускается.
В функции не разрешается изменений данных в таблицах базы данных, создание, модификация и удаление объектов базы данных. Тем не менее, разрешается использование команд UPDATE, INSERT и DELETE, изменяющих данные в переменной table, которая является возвращаемым функцией значением.
32.Система безопасности SQL SERVER.
Условно СБ можно разделить на 2 уровня: 1) уровень сервера; 2) уровень БД.
На уровне сервера разрешается или отклоняется доступ пользователей к самому серверу.
На уровне БД пользователи, имеющие доступ на уровне сервера, получают доступ к объектам БД. На уровне сервера система оперирует такими понятиями:
1) аутентификация; 2) учѐтная запись; 3) встроенные роли сервера.
На уровне БД: 1) пользователь БД; 2) фиксированные роли БД; 3) пользовательская роль БД; 4) роль приложения;
SS поддерживает 2 метода аутентификации:
1) Windows Authentication; 2) SS Authentication.
В связи с этим СБ SS может работать в 2х режимах: 1) режим смешанной аутентификации (Mixed Mode); 2) аутентификация Windows (Windows Authentication Mode).
Задаѐтся режим аутент. с помощью менеджера в свойствах сервера на вкладке security. Переключатели группы (Audit Level) позволяют отслеживать попытки регистрации пользователя. Здесь можно задать следующие режимы:
1)попытки доступа пользователей к серверу не протоколируются – None;
2)сервер записывает в журнал только те попытки регистрации, которые заверш.
успешно -- Success;
3)Failure – отслеживаются только неудачные попытки получить доступ;
4)All – включает все предыдущие случаи.
При аутентификации Windows подлинность проверяется ОС, и пользователь автоматически получает соответствующие права на доступ к данным SS после регистрации в домене. Такой метод предоставления доступа называется установлением доверительного соединения.
Аут-я SS реализуется на самом SS и вся информация о пользователях хранится в системной базе Master. Например, при подключении к SS через Internet регистрация в домене не выполняется, поэтому необходимо использовать ASS. При ASS возможна такая ситуация, когда различные пользователи будут работать под одной учѐтной записью SS.
33.Учетные записи.
Аут-я Windows NT предусматривает хранение учѐтной записи пользователя в БД системы безопасности доменов.
Если пользователь успешно прошѐл регистрацию в сети Windows, он получает набор идентификаторов, включающих идент-р самой УЗ и идент-ры всех групп, в которые включена УЗ.
На основе этих идентификаторов УЗ м.б. предоставлен доступ к SS.
Информация об УЗ-ях SS, как и Windows, хранится в таблице SysLogin системной базы Master. Каждая строка этой таблицы соответствует 1 УЗ.
Для более удобной работы с локальными УЗ-ми можно использовать представления SysLogins. Изменения в таблице SysLogins может осуществляться с помощью INSET, UPDATE, DELETE и системных ХП. С помощью менеджера можно получить список всех зарегистрированных на сервере УЗ-ей. Они хранятся в папке
«\Security\Logins».
Информация об УЗ-ях представляется следующими столбцами: Name – имя УЗ (max длина 128 символов).
Type – тип УЗ.
Server Access – доступ к SS разрешѐн или запрещѐн.
Default Database – БД по умолчанию.
User – имя пользователя БД.
Default Language – язык по умолчанию, установленный для УЗ.
В процессе установки SS создаѐт 2 специальные УЗ: 1) sa – системный администратор.
Эта УЗ оставлена для сохранения совместимости с предыдущими версиями SS. 2) BUILTIN\administrators
С помощью этой УЗ члены группы администратора домена, в котором установлен SS, получают доступ к SS. По умолчанию эта УЗ включена в фиксированную роль сервера. Это означает, что администраторы сети по умолчанию имеют права на управление сервером.
Эту УЗ лучше исключить из роли SysAdmin в случае, если обязанности администратора сети и администратора SS выполняют разные люди.
34.Роли сервера.
В SS имеются 2 группы ролей: 1) роли сервера; 2) роли БД.
Набор ролей сервера строго ограничен. Никто, включая администратора БД, не может создать новую или удалить существующую роль БД. Поэтому они называются фиксированными ролями.
Пользователь БД – это единица СБ, через которую осуществляется доступ УЗ к объектам БД.
СБ SS построена таким образом, что пользователь должен только однажды себя идентифицировать при подключении к серверу.
35.Система безопасности базы данных: пользователи и роли.
В SS имеются 2 группы ролей: 1) роли сервера; 2) роли БД.
Набор ролей сервера строго ограничен. Никто, включая администратора БД, не может создать новую или удалить существующую роль БД. Поэтому они называются фиксированными ролями.
Пользователь БД – это единица СБ, через которую осуществляется доступ УЗ к объектам БД.
СБ SS построена таким образом, что пользователь должен только однажды себя идентифицировать при подключении к серверу.
В БД SS имеются следующие три типа ролей:
1) фиксированные роли БД; 2) пользовательские роли БД; 3) роли приложений. Фиксированные и пользовательские роли предназначены для группировки
пользователей и предоставления им прав доступа. Роли приложений – для предоставления прав доступа приложениям.
Количество и назначение фиксированных ролей стандартно и не может быть изменено.
SS позволяет включить пользователей БД, УЗ-и, фиксированные роли сервера и группы Windows в фиксированные роли БД.
Роли приложения в SS позволяют выдавать права не конкретному пользователю или их группе, а приложению в целом. С точки зрения сервера роль приложения рассматривается как обычный пользователь и может являться владельцем объектов БД.
36.Определение прав доступа к данным.
Все существующие в БД права доступа можно разбить на 3 класса:
1) права доступа к данным; 2) права на выполнение ХП; 3) права на выполнение команд Transact-SQL.
Помимо перечисленных ПД, которые предоставляются явно, существует класс неявных прав доступа. Эти неявные права доступа задаются пользователю через членство в фиксированной роли сервера или БД.
Права доступа к данным можно разделить на следующие категории:
1) insert; 2) update; 3) delete; 4) select; 5) references – возможность создавать внешние ключи.
Право на выполнение ХП. Пользователь может просматривать и выполнять код
ХП.
Право на выполнение команд T-SQL позволяет пользователю выполнять команды создания БД (CREATE, BACKUP).
37.Транзакции. Основные требования.
Транзакция – набор из 1 или более команд, которые обрабатываются как единое целое, то есть выполняется либо весь набор команд, либо ни 1 из них.
По умолчанию каждая команда T-SQL рассматривается как отдельная транзакция. Требований к выполнению транзакций(ACID)
atomicity – атомарность, consistency – согласованность, isolation –
изолированность, durability – долговечность.
Атомарность.
Все изменения данных, выполненные в транзакции, рассматриваются как единый минимальный блок. Зафиксированными могут быть либо все изменения, выполненные
втранзакции, либо данные будут восстановлены в состоянии, в котором были до начала транзакции.
Согласованность.
При завершении выполнения транзакции все данные должны удовлетворять ограничениям целостности, определѐнным в БД. Кроме того, все индексы должны быть
вкорректном состоянии. Проверка этого требования может выполняться на уровне SS либо на процедурном уровне.
Изолированность.
Означает, что изменения данных, выполняемые в различных транзакциях, должны быть независимыми друг от друга. Для обеспечения изолированности транзакций используются блокировки.
Устойчивость (долговечность).
После того, как транзакция выполнит все изменения, и еѐ работа будет завершена, система уже не может вернуться в то состояние, в котором она была до начала транзакции.
38.Использование транзакций.
Начинается любая транзакция командой:
BEGIN TRAN [SACTION] [tran_name | @tran_var [WITH [‘description’]]] Переменная должна быть типом char, varchar, nvarchar, nchar.
Опция WITH<…> задаѐт метку в transact.log.
При создании транзакции изменяется значение системной переменной @@TRANCCOUNT, которая содержит номер активной транзакции для текущего соединения.
Если необходимо создать распределѐнную транзакцию, добавляется опция
DESTRIBUTED.
Можно создать точки сохранения: SAVE TRAN [tran_point | @tranp]
Команда, которая выполняет откат транзакции: ROLLBACK TRAN. C помощью еѐ можно выполнить восстановление точки сохранения. ROLLBACK WORK – в этом случае будет отменена последняя начатая транзакция.
Команда выполняет фиксирование транзакций: COMMIT TRAN [tran_name | @tran_var]
Если имя не указано, то будет зафиксирована последняя выполняемая транзакция. Допускается использование вложенных транзакций, то есть когда они создаются
друг из друга.