Типы определяемых пользователем функций:
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, которая есть возвращаемым функцией значением.
Совокупность безопасности 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.
Учетные записи.
Аут-я 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 делают различные люди.
Роли сервера.
В SS имеются 2 группы ролей:
1) роли сервера; 2) роли БД.
Комплект ролей сервера строго ограничен. Никто, включая администратора БД, не имеет возможности создать новую либо удалить существующую роль БД. Исходя из этого они именуются фиксированными ролями.
Пользователь БД – это единица СБ, через которую осуществляется доступ УЗ к объектам БД.
СБ SS выстроена так, что пользователь обязан лишь в один раз себя идентифицировать при подключении к серверу.