Управляем пользователями базы данных. Схемы базы данных по умолчанию

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

Права для пользователей MySQL

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

CREATE - позволяет создавать новые базы данных и таблицы

DROP - позволяет удалять базы данных или таблицы

INSERT - позволяет добавлять строки к таблице.

UPDATE - позволяет изменять содержание строк таблиц. Не путать с ALTER, которая позволяет изменять саму структуру таблиц (количество строк/столбцов, типы столбцов).

DELETE - противоположна INSERT - позволяет удалять строки из таблицы.

ALTER - позволяет изменять структуру таблиц. Требует CREATE и INSERT привилегии.

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

LOCK TABLES - блокирует таблицу на время искусственного внесения в нее изменений (администрирование), чтобы данные внутри нее не могли измениться своим естественным путем (во время рабочего процесса).

REFERENCES - позволяет создавать связь между таблицами по внешнему ключу.

EVENT - дает право на создание/изменение/удаление заданий для планировщика

TRIGGER - позволяет создавать/изменять/удалять триггеры (привязываемые к определенным таблицам), которые при выполнении операций DELETE, UPDATE или INSERT совершают дополнительные действия.

INDEX - привилегия даёт право добавлять/удалять индексы к (из) таблицам. Сами индексы назначаются вручную, и дают возможность сэкономить время на поиске строк.

CREATE TEMPORARY TABLES - позволяет создавать временные таблицы на время сессии.

CREATE VIEW - позволяет создать некоторое представление в виде таблицы, которая фактически не существует как единая и содержит лишь данные других таблиц. К примеру, в этом представлении можно собрать определенные сгруппированные данные из трёх таблиц (оператором SELECT) и по факту собранные данные будут лишь ссылаться на данные этих 3-х таблиц и также будут объединением, не нуждающимся в собственной таблице.

SHOW VIEW - позволяет проверить каким запросом (из каких данных состоит) создано определенное представление, заданное с помощью CREATE VIEW

CREATE ROUTINE - позволяет создать процедуру, которая является набором заготовленным набором SQL-команд.

ALTER ROUTINE - позволяет изменить процедуру, созданную посредством CREATE ROUTINE .

EXECUTE - позволяет вызывать готовые процедуры.

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

CREATE TABLESPACE (admin) - позволяет создавать/изменять/удалять пространства таблиц. Само это пространство является логическим и не связано со структурой БД или схемой. Оно декларирует расположение объектов БД на физических носителях и используется для оптимизации системы БД.

CREATE USER (admin) - позволяет создавать/изменять/переименовывать/удалять пользователей баз данных.

PROCESS (admin) - разрешает доступ к информации о потоках (процессах) исполняющихся на сервере.

PROXY (admin) - позволяет войти пользователем под видом другого пользователя. Используется администратором для проверки/отладки прав доступа у необходимого пользователя.

RELOAD (admin) - разрешает использование оператора FLUSH, который чистит кеш MySQL

REPLICATION CLIENT (admin) - позволяет выполнять операции SHOW MASTER STATUS, SHOW SLAVE STATUS и SHOW BINARY LOG.

REPLICATION SLAVE (admin) - данная привилегия необходима пользователям ведомого сервера БД, чтобы этот сервер мог подключаться к ведущему серверу в роли ведомого. Без этой привилегии ведомые сервера не смогут запрашивать обновления баз данных и таблиц у ведущего сервера.

SHOW DATABASES (admin) - позволяет выполнять оператор SHOW DATABASES. Пользователи, не имеющие подобной привилегии, при выполнении данного оператора смогут лишь увидеть базы данных к которым у них есть какие-либо права.

SHUTDOWN (admin) - привилегия позволяет выполнить оператор SHUTDOWN, выключающий MySQL сервер.

SUPER (admin) - привилегия, дающая право на множество операций:

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

ALL (admin) - пользователю, получившему данную привилегию, автоматически назначаются все права в рамках уровня привилегий (возможных привилегий в принципе, согласно контексту выдачи привилегий). Не назначается только привилегия GRANT OPTION в данном случае.

Назначение прав для пользователей MySQL в панелях управления хостингом

DirectAdmin
cPanel
ISPmanager
Webuzo

DirectAdmin

На главной странице DirectAdmin из под уровня пользователя в меню Your Account переходим в раздел MySQL Management :

Тут мы можем как создать нового пользователя для данной базы путем перехода по Create New Database User , так и привязать к ней существующего,. Следует отметить, что нет специально отведенного интерфейса для управления пользователями. Он доступен только посредством перехода через какую-либо базу данных. Чтобы дать пользователю права - переходим по ссылке modify privileges :

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

После этого произойдет переход на страницу подтверждения сохранения. Всё, права выданы.

cPanel

На главной странице cPanel нам необходимо найти раздел Базы данных в нем перейти по Базы данных MySQL :

Все манипуляции с базами данных MySQL, пользователями БД и их правами производятся именно в этом меню.

Если у нас нет ни базы, ни пользователя, то создаем их в соответствующих разделах страницы:

Раздел Текущие базы данных обновится:

Создаем пользователя:

Раздел Текущие пользователи обновится:

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

После добавления пользователя к базе данных откроется диалоговое окно для назначения привилегий:

Кнопка «Все права» эквивалентна привилегии ALL, описанной в начале руководства, и назначит все возможные права пользователю в контексте принадлежности пользователя определенной группе пользователей на уровне всего MySQL сервера.

После подтверждения внесенных изменений будет переадресация на страницу, подтверждающую что указанные права были выданы и на странице управления базами и пользователями MySQL повторно обновится раздел Текущие базы данных :

Готово. Пользователь назначен базе данных.

ISPmanager Lite 5

При входе в ISPmanager в роли какого-либо пользователя необходимо перейти в Инструменты -> Базы данных из левого меню.

Далее на открывшемся интерфейсе управления базами данных необходимо выбрать необходимую базу и перейти в меню Users для перехода к интерфейсу управления пользователями БД. Если же баз данных нет, то создать новую можно перейдя по кнопке Add .

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

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

После этого мы увидим все права, которые можно назначить этому пользователю:

По-умолчанию при создании пользователя и БД назначаются все права. Изменяем те, которые нам необходимо и сохраняем результаты. После этого Вас вернет на страницу управления пользователями баз данных.

Webuzo

Webuzo состоит из 2-х панелей: администраторская и пользовательская. Переходим в пользовательскую панель и на главной странице выбираем Manage Databases

На открывшейся странице мы можем:

увидеть список существующих баз данных [Database(s) ];
создать новую базу данных [Create Database ];
увидеть список существующих пользователей баз данных [Database User(s) ];
создать пользователя баз данных и назначить его определенной базе данных [Add User To Database ]

Если целевой базы данных пока что не существует, то переходим в Create Database и создаем новую базу данных:

Если все же целевая база данных уже существует, то в управлении базами данных нам необходимо перейти в Add User To Database и создать нового пользователя БД или указать какого-либо существующего для его привязки к базе данных:

При добавлении пользователя к базе данных откроется новое окно с запросом назначения прав этому пользователю. Выбираем необходимые нам права и подтверждаем изменения кнопкой Submit Changes .

При успешном изменении прав в текущем окне появится надпись Database Privileges Updated . Задача выполнена.

Похожих статей достаточно много, но эту я в первую очередь писал для себя, останавливаясь на примечаниях, в которых описаны возможные проблемы. Надеюсь статья будет полезна и другим.
1. Устанавливаем 1С платформу
2. Устанавливаем MS SQL server 2008. При установке задаем пользователя баз данных. (Который SA).

После установки открываем панель администрирования серверов 1С предприятия и видим что она пуста.
Нужно создать сервер: Открываем console root->Central 1C: Enterprise 8.2 servers. Кликаем по нему правой кнопкой мыши и выбираем пункт new. В выпадающем меню выбираем Центральный сервер 1С Предприятия 8.2. Перед нами откроется окошко с 4-мя полями:
Протокол - протокол по которомы будут передаваться данные
Имя - имя компьютера в сети на котором располагается сервер
IP порт- порт по которому доступен сервер
Описание -описание. не обязательно.

Примечание:
Если платформа 1С была установлена на компьютер, и потом компьютер был переименован, то достучаться до него вы не сможете, потому что платформа 1С шибко умная платфома и записывает в определенные файлики при установке имя компьютера, но потом, когда имя компьютера менятся платформа их уже не перепишет. Эти файлики нужны для работы сервиса RAGENT 1С (его можно найти в запущеных службах, через панель администрирования сервера windows). Это все говорит о том, что чтобы переименовать эти файлы-необходимо остановить службу RAGENT. Сами файлы находятся в следующих местах:
C:\Program Files (x86)\1cv82\srvinfo\srvribrg
C:\Program Files (x86)\1cv82\srvinfo\reg_1541\1CV8Reg
Открываем эти файлии блокнотом и правим прошлое имя машины на настоящее ручками. Сохраняем и запускаем RAGENT.

Возвращаемся к настройке:
После того как заполнено окно с полями нажимаем кнопку OK и если все сделано верно то у нас появляется сервер по имени машины, на которй он стоит.

И так. Сервер запущен и теперь нам нужно создать базу на MYSQL server и связать ее с севером 1C. Есть несколько способов-здесь я опишу самый простой:
На сервере 1С предприятия открываем наш новый созданный сервер кликом по + рядом с названием сервера и на пункте «ИНФОРМАЦИОННЫЕ БАЗЫ» кликаем правой кнопочкой мыши, выбираем New->Информационная база
Перед нами откроется окно в котором будут следующие поля:

Имя -имя нашей базы данных на сервере 1С (Как правило многие его пишут таким же как как и в поле база данных, чтобы не путаться)
Описание -описание
Защищенное соединение -по умолчанию выключено. можно включить но тогда нагрузка на сервер возрастет
Сервер баз данных -если сервер на этом же сервере то указываем (local) именно так в скобочках, если не на этом сервере то указываем ip сервера
Тип СУБД -Выбираем тип MS SQL
База данных -имя базы данных на сервере MS SQL. Если базы нет то в одном из чекбоксов можно поставить галочку и она создастся
Пользоватлель сервера БД -Указываем либо того пользователя которого создаваи при установке, либо создаем отдельного пользователя в MS SQL, задаем ему права и прописываем его здесь.
Пароль пользователя сервера БД -пароль
Разрешить выдачу лицензий сервером 1С предприятие -выбираем да
Страна -Выбираем страну
Смещение дат -ставим в 0
Чекбокс «Создать базу в случае отсутсвия» -тот самый чекбокс для создания базы, если ее нет
Чекбокс «Установить блокировку регламентных заданий» -не ставим галочку

Нажимаем ОК и видим что серверы настроены и у нас в закладке «Информационные базы» появилась информационная база под именем которое мы ей дали.

Чтобы нстроить Backup нам нужно открыть Microsoft SQL MANAGEMENT STUDIO.
Вводим логин и подключаемся к серверу.
Перед нами административная консоль. В Object explorer открываем вкладку Management и в ней видим Maintance plans. Здесь будем создавать нужный нам BackUP. Как обычно правый клик по Maintance plans->new maintance plan . В главном окне появится вкладка subplan, а под Object Explorer появится еще одно окошечко ToolBox в котором вложен Maintance Plans Tasks . В ней мы выберем Back Up DataBase Task кликнув по нему 2 раза. Он перенесется на главное окно. На нем кликаем 2 раза и перед нами появляется окно опять же с полями, где мы можем выбрать какой Back Up делать, какую базу BackUp-ить, и куда это сохранять. По окончании настроек нужно нажать Ok.

Примечание:
Сохраняя Back Up в какую либо сетевую папку (путь кстати придется прописать ручками, потому, что оконко выбора директории видит только локальные рессурсы) проследите за правами доступа, и заодно проследите какая у вас аутентификация на сервере MySql потому что если аутентификация выставлена не по учетным записям Windows, а по внутреннему пользователю СУБД и если при этом у вас поднят сервер AD то BackUp будет выдавать ошибку при попытке исполнения, поскольку будет это делать от имени внутреннего пользователя СУБД и AD его не пропустит никуда кроме локального компьютера.

После того как вы настроили путь, базу и тип BackUp нужно настроить расписание. Для этого в главном окошке над созданным вами Task есть табличка SubPlan . В конце таблички (справа) есть иконка календаря. Кликнув на нее вы попадете в настройку расписания. Отмечая чекбоксы дней и выставляя время вы настроите расписание. Кликнув 2 раза на поле под названием SubPlan вы сможете изменить название Task-a. Настроив все пройдите в File->Save All . После сохранения в Maintance plans появится Task c вашим названием который вы дали BackUp-у.

По окончании настройки нужно обязательно проверить Работу. Для этого Правой клавишей мыши кликните на созданном Task и выполние Exicute.

Примечание:
Если Exicute выполняется с ошибкой читайте ошибки которые вам выдаст Studio, и первым делом проверьте запуще ли у вас SQL server agent . Это он занимается выполнением заданий и функция Exicute обращается именно к нему за выполнением заданий. Если он не запущен попытка выполнения потерпит неудачу. Дял того чтобы посмотреть работатет ди агент или нет в Studio в Object Explorer пройдите во вкладку SQL Server Agent . Если на иконке булет красный кружок с крестиком- значит агент остановлен. ЗАпустить его можно кликнув на нем правой кнопкой мыши и выбрав к контекстном меню опцию START.

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

Предварительно настроенные роли и возможные права доступа перечислены ниже:

Нет (None) – Никакого доступа к базе геоданных или к набору данных базы геоданных не было предоставлено.
Только чтение (Read Only) – Пользователь может просматривать и выбирать данные.
Чтение/Запись (Read/Write) – Пользователь может выполнять чтение, запись и создание новых наборов данных в базе геоданных или может выполнять чтение и запись в существующих наборах данных.
Администратор (Admin) – Пользователь может выполнять административные задачи в определенной базе геоданных.
Администратор сервера (Server administrator) – Пользователь, который управляет сервером баз данных.

Разрешения являются кумулятивными. Если вы администратор на уровне сервера базы данных, вы являетесь также и администратором базы геоданных. Если вы администратор базы геоданных, вы автоматически получаете разрешения на чтение/запись (read/write) для всех наборов данных в этой базе геоданных.

Ниже описан каждый уровень, на котором разрешения могут быть назначены.

Права доступа на уровне сервера баз данных

Права доступа на уровне сервера базы данных могут быть настроены только для администратора сервера; пользователь или является администратором сервера, или нет.

В процессе постинсталляции, которая настраивает экземпляр SQL Server Express для хранения баз геоданных, на сервер баз данных добавляется учетная запись Windows. В этот момент учетной записи назначается роль администратора сервера. После этого права доступа к серверу баз данных могут быть доступны из контекстного меню сервера баз данных в ArcGIS for Desktop .

Администратор сервера может выполнять следующие задачи:

Добавлять и удалять пользователей сервера баз данных.
Управлять базами геоданных и настройками безопасности.
Создавать и удалять базы геоданных.
Прикреплять и откреплять базы геоданных.
Делать резервные копии и восстанавливать базы геоданных.
Обновлять базы геоданных.
Выполнять сжатие баз геоданных (Compress).
Обновлять статистику и индексы в базе геоданных.
Уменьшать базу геоданных (Shrink).
Запускать, останавливать и приостанавливать сервер баз данных.

Обычно у вас имеется один администратор сервера баз данных.

Ниже приведен пример диалогового окна Права доступа для серверов баз данных. Учетной записи ROCKETJAY\har была назначена роль администратора сервера (Server administrator).

Права доступа на уровне базы геоданных

Права доступа на уровне баз геоданных назначаются с помощью контекстного меню баз геоданных при доступе к ним через папку Серверы баз данных (Database Servers) в дереве Каталога.

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

Только Чтение (Read Only) – Это разрешения позволяет пользователю выбирать данные из любой таблицы в базе геоданных.
Чтение/Запись (Read/Write) – Пользователи с назначенным разрешением Чтение/Запись могут выбирать и редактировать все существующие в базе геоданных данные и могут создавать новые элементы базы геоданных, такие как классы объектов. Если пользователь получил разрешение на чтение/запись на уровне базы геоданных, вы не сможете изменить его права доступа на уровне наборов данных, они автоматически будут настроены как Чтение/Запись.
Администратор (Admin) – Пользователи с назначенной ролью Администратора (Admin) являются администраторами только этой базы геоданных. Это означает, что пользователь имеет разрешения на чтение/запись на все наборы данных и базе геоданных, и эти права не могут быть отозваны на уровне наборов данных. Например, вы не сможете открыть закладку Права доступа на уровне наборов данных и выбрать права Только чтение (Read Only) для набора классов для этого пользователя.
Помимо доступа к наборам данных на чтение/запись администраторы баз геоданных могут выполнять административные операции над этими базами геоданных, в том числе создание резервных копий, сжатие баз геоданных, обновление баз геоданных и администрирование прав пользователей базы геоданных. (Пользователи должны существовать на сервере баз данных; администраторы базы геоданных не могут добавлять новых пользователей на сервере баз данных.)
Еще одной опцией для роли пользователя является Нет (None) . В таком случае пользователь не будет иметь прав на доступ к данным на уровне базы геоданных; однако при этом пользователю могут быть предоставлены права Только чтение или Чтение/Запись на определенные наборы данных, как описано в разделе "Разрешения на уровне наборов данных". Нет (None) – это уровень прав доступа, по умолчанию устанавливаемый для пользователей, которые добавляются на сервер баз данных.

В следующем примере диалогового окна Права доступа базы геоданных учетная запись ROCKETAY\pllama добавлена к роли Чтение/Запись (Read/Write) для базы геоданных historical.

Для получения дополнительной информации об администраторах сервера и баз геоданных см. раздел Администраторы серверов баз данных .

Права доступа на уровне набора данных

Разрешения для набора данных доступны через команду Права доступа (Privileges) в контекстном меню набора данных, которая открывает диалоговое окно Разрешения . Возможными разрешениями для набора данных, которые доступны через диалоговое окно Разрешения на уровне набора данных, являются Только чтение (Read Only), Чтение/Запись (Read/Write) и Нет (None).

Пользователь может не иметь разрешений на уровне базы геоданных (его разрешения будут установлены как Нет (None)), но ему могут быть выданы права на чтение/запись или только чтение для определенных наборов данных в базе геоданных. Например, вы можете назначить пользователям-аналитикам права только на чтение данных в базе геоданных, но предоставить им права на запись/чтение одного класса объектов в базе геоданных.

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

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

Ниже приведен пример диалогового окна Права доступа для набора данных firestations:

Чтобы узнать больше о процессе назначения ролей пользователям и выдачи и отзыва разрешений, см. раздел

Аннотация: Данная лекция содержит материалы по управлению доступом к базам данных SQL Server, в частности рассматривается управление пользователями базы данных, включение пользователя guest, создание ролей базы данных, предоставление разрешений на базу данных и добавление пользователя базы данных

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

Примечание . В предыдущих версиях SQL Server можно было использовать для сопоставления нескольких имен входа одному пользователю базы данных системную хранимую процедуру sp_addalias . Так можно поступить и в SQL Server 2005. Однако эту функцию использовать не рекомендуется, поскольку она считается устаревшей и, возможно, будет удалена из следующих версий программы.

Предоставление доступа к базам данных

Пользователи базы данных - это участники уровня базы данных. Все имена входа, за исключением серверной роли sysadmin , должны быть сопоставлены пользователям, которые, в свою очередь, сопоставлены базе данных, к которой им нужен доступ. Члены роли sysadmin сопоставлены пользователю dbo во всех базах данных сервера.

Добавляем пользователя базы данных

Добавить пользователя базы данных можно при помощи инструкции CREATE USER . Следующий пример кода Transact-SQL создает имя входа Peter и сопоставленного с ним пользователя в базе данных Adventure Works :

Создаем имя входа Peter
CREATE LOGIN Peter WITH PASSWORD="Tyu87IOR0";
USE AdventureWorks; GO
Добавляем пользователя базы данных Peter , который сопоставлен имени входа Peter в БД AdventureWorks .
CREATE USER Peter FOR LOGIN Peter;

Управляем пользователями базы данных

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

SELECT HAS_DBACCESS("AdventureWorks");

Чтобы получить информацию о пользователях базы данных, можно воспользоваться представлением каталога sys.database_principals .

Если нужно временно отключить доступ пользователя к базе данных, можно отозвать разрешение CONNECT для этого пользователя. Следующий пример отзывает разрешение CONNECT для пользователя Peter:

Изменяем контекст соединения на базу данных AdventureWorks .
USE AdventureWorks; GO
Отзываем разрешение connect для Peter в AdventureWorks .
REVOKE CONNECT TO Peter;

Удалить пользователя в базы данных можно при помощи инструкции DROP USER .

Предупреждение . В SQL Server 2005 не допускается удаление пользователя, который является владельцем схемы базы данных. О схемах рассказывается далее в этой лекции.

Управляем пользователями, утратившими связь с именами входа

Пользователями, утратившими связь с именами входа, называются пользователи базы данных, которые не сопоставлены имени входа в текущем экземпляре SQL Server. В SQL Server 2005 пользователь может утратить связь с именем входа, если сопоставленное ему имя входа будет удалено. Чтобы получить информацию о таких пользователях, можно выполнить следующий код:

Изменяем контекст соединения на базу данных AdventureWorks .
USE AdventureWorks; GO
Составляем отчет обо всех пользователях базы данных, утративших связь с именем входа
EXECUTE sp_change_users_login @Action="Report";

В SQL Server 2005 допускается создание пользователя, не сопоставленного имени входа, с помощью фразы WITHOUT LOGIN . Пользователи, созданные с помощью фразы WITHOUT LOGIN , не считаются пользователями, утратившими связь с именем входа. Эта возможность может быть очень полезна в ситуации, когда необходимо изменить контекст выполнения какого-либо модуля. О контексте выполнения рассказывается далее в этой лекции. Следующий пример создает пользователя, не сопоставленного имени входа.

Изменяем контекст соединения на базу данных AdventureWorks .
USE AdventureWorks; GO
Создаем пользователя базы данных Paul в базе данных AdventureWorks
не сопоставляя с ним имени входа в данном экземпляре SQL Server instance
CREATE USER Paul WITHOUT LOGIN;

Включаем пользователя guest

Когда имя входа, которое не имеет сопоставленного пользователя, пытается соединиться с базой данных, SQL Server предпринимает попытку подключения с использованием пользователя Guest . Пользователь Guest создается по умолчанию без предоставления разрешений. Можно включить пользователя guest , предоставив ему разрешение CONNECT , как показано ниже.

Изменяем контекст соединения на базу данных AdventureWorks .
USE AdventureWorks; GO
Предоставляем пользователю Guest доступ к базе данных AdventureWorks .
GRANT CONNECT TO Guest;

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

Предоставление разрешений на базу данных

Создав пользователей базы данных, необходимо управлять разрешениями для этих пользователей. Это можно осуществить, добавляя пользователей в роли базы данных или предоставляя самим пользователям гранулярные разрешения.

Создаем роли базы данных

Роли базы данных - это участники уровня базы данных. Роли базы данных можно использовать для назначения разрешений базы данных группе пользователей. В SQL Server 2005 по умолчанию создается набор ролей базы данных. Эти роли по умолчанию перечислены в табл. 3.1 .

Таблица 3.1. Роли базы данных по умолчанию

Роль базы данных	"Описание
db_accessadmin	Может управлять доступом к базе данных
db_backupoperator	Может выполнять резервное копирование базы данных
db_datareader	Может читать данные из таблиц всех пользователей
db_datawriter	Может добавлять, удалять и обновлять данные в таблицах всех пользователей
db_ddladmin	Может выполнять любые команды DDL в базе данных
db_denydatareader	Не может читать какие-либо данные в таблицах пользователей
db_denydatawriter	Не может добавлять, удалять и обновлять какие-либо данные в таблицах пользователей
db_owner	Может выполнять все действия по настройке конфигурации и обслуживанию
db_securityadmin	Может изменять членство в ролях базы данных и управлять разрешениями
public	Особая роль базы данных. Все пользователи принадлежат к роли public . Пользователей из группы public нельзя удалить.

Можно добавлять роли базы данных, если нужно сгруппировать пользователей в соответствии с требованиями определенных разрешений. Следующий пример кода создает роль базы данных с именем Auditors и добавляет пользователя Peter в эту новую роль.

Изменяем контекст соединения на базу данных AdventureWorks .
USE AdventureWorks; GO
Создаем роль Auditors в базе данных AdventureWorks .
CREATE ROLE Auditors; GO
Добавляем пользователя Peter к роли Auditors
EXECUTE sp_addrolemember "Auditors", "Peter";

Управляем ролями базы данных

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

Изменяем контекст соединения на базу данных AdventureWorks .
USE AdventureWorks; GO
Проверяем, принадлежит ли текущий пользователь к роли db_owner
Термин «сервер БД» используется для обозначения всей СУБД, основанной на архитектуре клиент-сервер, включая серверную и клиентскую часть. Такие системы предназначены для хранения и обеспечения доступа к БД. Обычно одна БД целиком хранится в одном узле сети и поддерживается сервером в сервере БД, представляющим собой простое и дешевое приближение к распределенным БД, так как общая БД доступна для всех пользователей локальной сети. Доступ к базам данных из прикладной программы или пользователя осуществляется с использованием клиентской части системы. В качестве основного интерфейса между клиентскими и серверными частями выступает язык SQL.
Язык SQL представляет собой текущий стандарт интерфейса СУБД в открытых системах. Соблюдая предосторожности при программировании, можно создать прикладные информационные системы мобильные в классе SQL-серверов.
Серверы БД, интерфейс которых основан на языке SQL, обладают своими преимуществами и недостатками.
Преимущества: стандартный открытый интерфейс, т. е. клиентская часть любой ориентированной СУБД может работать с любым SQL-сервером независимо от того, когда компания его разработала.
Недостатки. При высоком уровне интерфейса между клиентской и серверной частями системы со стороны клиента работает слишком мало программ СУБД. Это нормально, если на стороне клиента используется маломощная работающая станция. Но если клиентский компонент обладает достаточной мощностью, то часто возникает необходимость возложить на него большие функции управления БД. Разгрузить сервер, который в этом случае является узким местом этой системы. Одним из корректных направлений СУБД является гибкая конфигурированная система, при которой распределяются функции между клиентской и пользовательской системами.
Преимущества протоколов удаленного вызова процедур
Типичные распределения функций между клиентами и серверами
Типичным на сегодняшний день на стороне СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к БД, а обращается для этого к серверу с использование языка SQL.
В некоторых случаях необходимо включить в состав клиентской части системы некоторых функций для работы с локальной КЭШ БД, т.е. с той ее частью, которая интенсивно используется клиентской прикладной программой. Используя современные технологии, это можно сделать только путем формального создания на стороне клиента локальной копии серверов БД и рассмотрения всей системы как набор взаимодействующих серверов. С другой стороны иногда хотелось бы перенести большую часть прикладной системы на стороны сервера, если разница в мощностях клиентских рабочих станций и сервера велика, то это можно сделать, используя удаленный вызов процедур при условии, что программное обеспечение сервера это позволяет.
Требования к аппаратуре и программному обеспечению клиентских и сервисных компьютеров различают в зависимости от вида использованной системы.
Если разделение между клиентской и сервисной частью достаточно жесткое, как в большинстве современных СУБД, то пользователям, работающим на станциях, все равно какая аппаратура и операционная система работает на сервере при условии, что он сравнивается с возникающим потоком запросов.
Если могут возникнуть потребности перераспределения функций между клиентом и сервером, то не все равно какие операции системы используются.
Распределенные базы данных
Основной задачей системы управления распределенной БД состоит в обеспечении средств интеграции локальных баз данных, располагающихся в некоторых узлах вычислительной сети для того, чтобы пользователи, работающие на любом узле сети, имели доступ ко всем базам данных как к единой БД. При этом должны обеспечиваться:
1) простота использования системы;
2) возможности автономного функционирования, при нарушении связанности сети;
Разновидности распределенных систем
Существуют однородные и неоднородные БД. В однородной БД каждая локальная БД управляется одной и той же СУБД. В неоднородной системе локальные БД могут относиться даже к разным моделям данных.
Наиболее успешно в настоящее время решается задача интеграции неоднородных SQL ориентированных систем. Этому способствует стандартизация языка SQL и общее следование.
Основная цель проекта создания распределенной системы управления базами данных может быть сформулирована следующим образом: необходимо обеспечить средства интеграции локальных баз данных, располагающихся в узлах вычислительной сети, с тем, чтобы пользователь, работающий в любом узле сети, имел доступ ко всем этим базам данных, так, как если бы они были централизованными, при этом должны обеспечиваться:
1) легкость использования системы;
2) возможность автономного функционирования при нарушении связности сети;
3) высокая степень эффективности.
Для решения этих проблем был принят ряд необходимых проектных решений, касающихся декомпозиции исходного запроса, оптимального выбора способа выполнения запроса, согласованного выполнения транзакций, обеспечение синхронизации, обнаружение и разрешение распределенных тупиков, восстановление состояния баз данных после разного рода сбоев в узлах сети. Легкость использования системы достигается за счет того, что пользователи остаются в среде языка SQL. Возможность использования SQL обеспечивает прозрачность местоположения данных. Система автоматически обнаруживает текущее местоположение упоминаемых в пользовательском запросе объектов данных. Одна и та же прикладная программа, включающая приложение SQL, может быть выполнена в разных узлах сети. При этом в каждом узле сети на этапе компиляции запроса выбирается наиболее оптимальный план выполнения запросов в соответствии с расположением данных в распределенной системе. Обеспечение автономности узлов сети может быть обеспечено следующим образом: каждая локальная БД администрируется независимо от других, возможно автономное подключение новых пользователей, смена версии автономной части системы и т.д. Система спроектирована таким образом, что в ней не требуются централизованных службы именования объектов или обнаружения тупиков.
В индивидуальных узлах не требуется наличия глобального знания об операциях, выполняющихся в других узлах сети. Работа с доступными базами данных может продолжаться при выходе из строя отдельных узлов сети и линий связи. Для достижения высокой степени эффективности системы используется два основных приема. Во-первых, выполнению запроса предшествует его компиляция. В ходе этого процесса производится поиск употребляемых в запросе имен объектов баз данных в распределенном каталоге и замена имен на внутренние идентификаторы; проверка прав доступа пользователя, от которого производится компиляция, на выполнение соответствующей операции над базами данных и выбор наиболее оптимального глобального плана выполнения запроса, который затем подвергается декомпозиции и про частям рассылается в соответствующие узлы сети, где производится выбор оптимальных локальных планов выполнения компонентов запроса и производится генерация модулей доступа в машинных кодах. В результате на стадии компиляции производится множество действий до реального выполнения запросов. Обработанная таким образом прикладная программа, включающая предложения SQL, может в дальнейшем выполняться много раз без дополнительных накладных расходов.
Во-вторых, средством повышения эффективности системы является возможность перемещения удаленных отношений в локальные базы данных.
Распределенная компиляция запросов
Запросы на языке SQL до своего реального выполнения могут подвергаться компиляции. Компиляция запросов может производиться на стадии предкомпиляции прикладной программы, написанной на обычном традиционном языке программирования с включением предложений SQL, или в процессе выполнения транзакций с использованием инструкции языка SQL. С точки зрения пользователя процесс компиляции приводит к следующим результатам: для каждого предложения на SQL образуется программа в машинных кодах, вызовы которой помещаются в текст исходной прикладной программы, однако в действительности процесс компиляции запроса намного более сложен из-за наличия сложных сетевых взаимодействий, которые требуются при реальном выполнении транзакции. Будем называть главным узлом сети тот узел, в котором инициирован процесс компиляции предложений SQL, и дополнительными узлами (те узлы, которые вовлекаются в этот процесс в ходе его выполнения). На самом грубом уровне процесс компиляции можно разбить на следующие стадии:
В каждом узле, участвующем в глобальном плане выполнения запроса, в главном или дополнительном, выполняется завершающая стадия компиляции. Эта стадия включает по существу две последние фазы процесса компиляции запроса: оптимизацию и генерацию машинных кодов, производится проверка прав пользователя, от имени которого выполняется компиляция, на выполнение соответствующих действий. Происходит обработка представлений БД, осуществляется локальная оптимизация обрабатываемой части запроса в соответствии с имеющимися индексами и производится генерация кода.