 |
|
Расширение возможностей базы данных
17. Восстановление баз данных
Восстановление базы данных — это функция СУБД, которая в случае логических и физических сбоев приводит базу данных в актуальное и консистентное состояние.
В случае логического отказа или сигнала отката одной транзакции журнал изменений сканируется в обратном направлении, и все записи отменяемой транзакции извлекаются из журнала вплоть до отметки начала транзакции. Согласно извлеченной информации выполняются действия, отменяющие действия транзакции. Этот процесс называется откат (rollback).
В случае физического отказа, если ни журнал изменений, ни сама база данных не повреждены, то выполняется процесс прогонки (rollforward). Журнал сканируется в прямом направлении, начиная от предыдущей контрольной точки. Все записи извлекаются из журнала вплоть до конца журнала. Извлеченная из журнала информация вносится в блоки данных внешней памяти, у которых отметка номера изменений меньше, чем записанная в журнале. Если в процессе прогонки снова возникает сбой, то сканирование журнала вновь начнется сначала, но восстановление фактически продолжится с той точки, где оно прервалось.
В случае физического отказа, если журнал изменений доступен, но сама база данных повреждена, то должен быть выполнен процесс восстановления базы из резервной копии. После восстановления база будет находиться в состоянии на момент выполнения резервной копии. Для восстановления базы данных на момент отказа необходимо выполнить прогонку всех изменений, используя журнал изменений.
В случае физического отказа, если журнал изменений недоступен, но сама база данных не повреждена, восстановление возможно только на момент предыдущей контрольной точки.
В случае физического отказа, если повреждены как журнал изменений, так и сама база данных, то восстановление возможно только на момент выполнения резервной копии.
18. Аутентификация и авторизация пользователей
Аутентифика́ция (англ. authentication от греческого : αὐθεντικός authentikos, "реальный, подлинный," от αὐθέντης authentes, "автор") — процедура проверки подлинности, например:
проверка подлинности пользователя путём сравнения введённого им пароля с паролем, сохранённым в базе данныхпользователей;
подтверждение подлинности электронного письма путём проверки цифровой подписи письма по открытому ключу отправителя;
проверка контрольной суммы файла на соответствие сумме, заявленной автором этого файла.
В русском языке термин применяется, в основном, в области информационных технологий.
Учитывая степень доверия и политику безопасности систем, проводимая проверка подлинности может быть односторонней или взаимной. Обычно она проводится с помощью криптографических способов.
Аутентификацию не следует путать с авторизацией (процедурой предоставления субъекту определённых прав) и идентификацией (процедурой распознавания субъекта по его идентификатору).
Аутентификация пользователя – это процесс, при котором пользователь в зависимости от указанного имени пользователя и пароля допускается или нет к установлению соединения с MS SQL Server.
MS SQL Server может работать в двух режимах аутентификации пользователей, используя либо режим аутентификации Windows (Windows Authentication), либо режим аутентификации средствами MS SQL Server (SQL Server Authentication).
Эти режимы аутентификации используют различные учетные записи пользователей. При аутентификации средствами MS SQL Server учетную запись и пароль создает администратор баз данных MS SQL Server, при аутентификации средствами Windows – системный администратор сети (в этом случае для подключения к MS SQL Server пользователю не нужна учетная запись MS SQL Server).
Аутентификация MS SQL Server позволяет определить имя пользователя для входа (login)и пароль для установления соединения с сервером. При установке MS SQL Server создается лишь одна учетная запись пользователя для входа – sa.
Авториза́ция (от англ. authorization — разрешение, уполномочивание) — предоставление определённому лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.[1][2][3] Часто можно услышать выражение, что какой-то человек «авторизован» для выполнения данной операции — это значит, что он имеет на неё право.
Авторизацию не следует путать с аутентификацией: аутентификация — это лишь процедура проверки подлинности данных, например, проверки соответствия введённого пользователем пароля к учётной записи паролю в базе данных, или проверка цифровой подписи письма по ключу шифрования, или проверка контрольной суммы файла на соответствие заявленной автором этого файла.
Авторизация необходима для работы некоторых сервисов сайта и/или для работы с данными, предназначенными только для конкретного аутентифицированного пользователя.
19. Назначение серверных ролей и ролей баз данных
Другим фундаментом системы безопасности сервера являются роли. Под ролью понимаются определенные права на выполнение операторов и работу с объектами базы данных. Роли объединяют нескольких пользователей в группу, наделенную определенными правами, причем одному пользователю может быть назначено несколько ролей.
Роли баз данных предоставляют наборы административных привилегий на уровне базы данных. При использовании ролей базы данных каждая учетная запись сервера будет иметь разные полномочия в зависимости от того, с какой базой данных осуществляется работа. Существует 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 сервера. Просмотр пользователей, входящих в эту роль и разрешений, присвоенный ей, осуществляется выполнением команды Действие – Свойства.
Встроенные роли сервера не могут быть удалены из системы, и нельзя изменить определенные для них разрешения. Также запрещено создавать и собственные серверные роли.
20. СУБД в архитектуре "клиент-сервер"
Рис. 1. Архитектура «клиент-сервер»
Сервер базы данных представляет собой мультипользовательскую версию СУБД, параллельно обрабатывающую запросы, поступившие со всех рабочих станций. В его задачу входит реализация логики обработки транзакций с применением необходимой техники синхронизации - поддержки протоколов блокирования ресурсов, обеспечение, предотвращение и/или устранения тупиковых ситуаций.
В ответ на пользовательский запрос рабочая станция получит не «сырье» для последующей обработки, а готовые результаты. Программное обеспечение рабочей станции при такой архитектуре играет роль только внешнего интерфейса (Front - end) централизованной системы управления данными. Это позволяет существенно уменьшить сетевой трафик, сократить время на ожидание блокированных ресурсов данных в мультипользовательском режиме, разгрузить рабочие станции и при достаточно мощной центральной машине использовать для них более дешевое оборудование.
Как правило, клиент и сервер территориально отделены друг от друга, и в этом случае они входят в состав или образуют систему распределенной обработки данных.
Для современных СУБД архитектура «клиент-сервер» стала фактически стандартом. Если предполагается, что проектируемая информация будет иметь архитектуру «клиент-сервер», то это означает, что прикладные программы, реализованные в ее рамках, будут иметь распределенный характер, т. е. часть функций приложений будет реализована в программе-клиенте, другая - в программе-сервере. Основной принцип технологии «клиент-сервер» заключается в разделении функций стандартного интерактивного приложения на четыре группы:
функции ввода и отображения данных;
прикладные функции, характерные для предметной области;
фундаментальные функции хранения и управления ресурсами (базами данных);
служебные функции.
Исходя из этого деления любое приложение может состоять из следующих компонентов:
компонент представления (функции 1-й группы);
прикладной компонент (функции 2-й группы);
компонент доступа к информационным ресурсам (функции 3-ей группы и протокол их взаимодействия).
Различия определяются четырьмя факторами:
какие виды программного обеспечения в логических компонентах;
какие механизмы программного обеспечения используются для реализации функций трех групп;
как логические компоненты распределяются компьютерами в сети;
какие механизмы используются для связи компонент между собой.
Исходя из этого, рассмотрим четыре подхода, реализованные в моделях технологии «клиент-сервер».
FS-модель
Базовая для локальных сетей персональных компьютеров. Применялась для разработки информационных систем на базе FoxPRO, Clipper, Paradox.
Основные свойства:
выделяется файл-сервер для реализации услуг по обработке файлов других узлов сети; работает под управлением сетевых ОС;
играет роль компонент доступа к информационным ресурсам;
в остальных узлах функционирует приложение, в кодах которого совмещены компоненты представления и прикладной;
протокол обмена - набор низкоуровневых вызовов.
Технология: запрос направляется на файловый сервер, который передает СУБД, размещенной на компьютере-клиенте, требуемый блок данных. Вся обработка осуществляется на компьютере-клиенте.
Недостатки:
высокий сетевой трафик;
небольшое число операций манипулирования;
недостаточные требования к безопасности
21. Архитектура базы данных
В этом разделе мы опишем три модели - или (как их часто называют) архитектуры - с помощью которых система управления базами данных (СУБД - DBMS) структурирует и манипулирует перманентными данными. При изучении каждой архитектуры важно понять, что мы не ставим перед собой цель показать, как работает определенная DBMS или как она построена. Мы хотим показать вам с помощью архитектуры, что лежит в основе работы DBMS. Так вы лучше поймете функции определения данных и манипулирования данными DBMS. Мы начнем с архитектуры способа, с помощью которого DBMS структурирует данные.
До сих пор мы обсуждали функцию обработки данных в терминах DBMS, имея одну единственную схему для описания постоянных данных системы базы данных. Это полезное упрощение, но в действительности дела обстоят немного сложнее. Архитектура схемы12, которую мы сейчас описываем, позволяет анализировать эту сложность и связать ее с преимуществами, которые можно получить благодаря подходу, основанному на использовании базы данных. Архитектура обсуждаемой нами схемы показана на рис. 2.10.
Прежде всего, заметьте, что различные сплошные линии на рис. 2.10 показывают, что определенные компоненты в данной архитектуре связаны друг с другом способом, который будет вкратце рассмотрен далее. В частности, обратите внимание, что эти линии не предназначены для того, чтобы указывать поток обработки данных. Как можно видеть, наше упрощение одной схемы заменено тремя видами схем: логической схемой, схемой хранения и схемой пользователей (userschema). Позже мы объясним, чем вызвана эта замена. В верхнюю часть диаграммы мы также включили различные пользовательские процессы. Термин "пользовательский процесс" (user process) вводится для того, чтобы разрешить доступ к системе базы данных с помощью любого вида программного обеспечения от имени пользователя. А теперь мы более подробно исследуем эти концепции.
Логическая схема (logical schema)- это одиночное, центральное описание логических свойств данных в конкретной базе данных. Логическая схема больше описывает какими являются данные, чем то, как их можно хранить и как получить к ним доступ. Для любой данной системы баз данных имеется одна логическая схема. Она является описанием свойств типов данных, которые затем определяют свойства экземпляров данных в базе данных. Она описывается формальным языком, который может быть обработан компьютером. Этот язык иногда называют языком описания данных логической схемы (logical schema data definition language или logical schema DDL).
На этом этапе естественно возникает вопрос: как должна выглядеть реляционная логическая схема. Подробный ответ на этот вопрос приведен в Книгах 2 и 4, где вы узнаете о языках описания данных логической схемы для реляционной базы данных. Проще говоря, эффект создания реляционной схемы заключается в создании различных заголовков таблиц, которые включают частную систему реляционной базы данных. Так, реляционная схема университета будет состоять из определенийзаголовков таблиц, которые составляют реляционную базу данных университета, например, заголовки двух таблиц на рис. 2.8. Важно отметить, что определение этих заголовков будет включать ограничения в отношении экземпляров данных, которые могут появиться под этими заголовками. В качестве иллюстрации заметим, что определение колонки СтудентИд (StudentId) в таблице Студент (Student) гарантирует, что только достоверные однозначные идентификационные номера студентов могут появиться как экземпляры в данной колонке (в отличие от, скажем, имен студентов). Заголовки колонок таблицы Студент (Student) являются "свойствами типов данных", в то время как индивидуальные строки являются экземплярами данных, которые согласуются со свойствами данных.
Схема пользователей (userschema) - это определение логических свойств данных, которые пользовательский процесс должен отсылать тому пользователю, которому необходимы эти данные. Как и логическая схема, схема пользователей представляет собой определения свойств типов данных и они определяются в форме, которая может быть обработана компьютером. Так как, обычно, база данных необходима нескольким пользователям, то существует много схем пользователей, каждая из которых основана на одной и той же единственной логической схеме. Только через пользовательскую схему пользователь может получить доступ к базе данных. Пользовательский процесс может использовать только одну схему пользователя. Обычно, несколько пользовательских процессов могут потребовать одну и ту же схему пользователей - просмотр данных - и поэтому могут совместно использовать одну и ту же схему пользователей.
Схема хранения- это определение того, как хранить и получать доступ к данным, определенным в логической схеме. Определение происходит с помощью языка, который иногда называютязыком описания данных схемы хранения(storage schema data definition language (или storage schema DDL). Для наших целей существует одна схема хранения для данной системы базы данных, точно так же как существует одна логическая схема. Подробное рассмотрение структур, определенных в схеме хранения, не входит в задачи данного курса15, но вы должны представлять себе хранение файлов, структуры файлов и методы доступа. Данные в каждой таблице, описанные в логической схеме, необходимо как-то физически хранить. Это осуществляется путем размещения данных каждой таблицы взапоминающем файле (stored file), который управляется операционной системой компьютера. Каждый хранимый файл хранится в соответствии со структурой (организацией) файла (file organization) (упорядоченной, индексной или хэшированной), поддерживающей метод доступа (access method), с помощью которого хранимые записи (stored records), составляющие данных файл, могут быть сохранены и извлечены. Таким образом, схема хранения применяет методы из технологии массовой памяти (запоминающего устройства большой емкости), используемой в вычислительных системах.
22. Нормализация базы данных
Нормализация — это процесс организации данных в базе данных, включающий создание таблиц и установление отношений между ними в соответствии с правилами, которые обеспечивают защиту данных и делают базу данных более гибкой, устраняя избыточность и несогласованные зависимости.
Избыточность данных приводит к непродуктивному расходованию свободного места на диске и затрудняет обслуживание баз данных. Например, если данные, хранящиеся в нескольких местах, потребуется изменить, в них придется внести одни и те же изменения во всех этих местах. Изменение адреса клиента гораздо легче реализовать, если в базе данных эти сведения хранятся только в таблице Customers и нигде больше.
Что такое «несогласованные зависимости»? Пользователь, которому нужно узнать, например, адрес определенного клиента, вполне обоснованно будет искать его в таблице Customers (клиенты), но искать в ней сведения о зарплате сотрудника, который работает с этим клиентом, не имеет смысла. Зарплата сотрудника связана с сотрудником (зависит от него), поэтому эти сведения следует хранить в таблице Employees (сотрудники). Несогласованные зависимости могут затруднять доступ к данным, так как путь к данным при этом может отсутствовать или быть неправильным.
Существует несколько правил нормализации баз данных. Каждое правило называется «нормальной формой». Если выполняется первое правило, говорят, что база данных представлена в «первой нормальной форме». Если выполняются три первых правила, считается, что база данных представлена в «третьей нормальной форме». Есть и другие уровни нормализации, однако для большинства приложений достаточно нормализовать базы данных до третьей нормальной формы.
Как и в случае со многими другими формальными правилами и спецификациями, обеспечить полное соответствие реальным ситуациям не всегда возможно. Как правило, для выполнения нормализации приходится создавать дополнительные таблицы, и некоторые клиенты считают это нежелательным. Собираясь нарушить одно из первых трех правил нормализации, убедитесь в том, что в приложении учтены все связанные с этим проблемы, такие как избыточность данных и несогласованные зависимости.
Вот некоторые из основных пунктов, которые связаны с нормализацией баз данных:
Упорядочивание данных в логические группы или наборы.
Нахождение связей между наборами данных. Вы уже видели примеры связей один-ко-многим и многие-ко-многим.
Минимизация избыточности данных.
23. Преобразование концептуальной модели в реляционную
Преобразование концептуальной модели в реляционную состоит в следующем: Построить набор предварительных таблиц и указать первичные ключи. Провести процесс нормализации. Первый пункт мы рассматривали в третьем уроке, со вторым мы пока не знакомы, но ознакомимся на практике. Итак, нам надо построить набор таблиц. Сделать это несложно, т.к. таблицы - это наши объекты, а поля таблиц - атрибуты объектов. Набор предварительных таблиц, исходя из нашей концептуальной модели, выглядит так: Таким образом, у нас определены таблицы, поля, первичные ключи (РК) и связи (FK). Обратите внимание, в таблицах Журнал поставок и Журнал покупок первичные ключи - составные, т.е. состоят из двух полей. Теоретически бывают таблицы, в которых все поля являются одним составным ключом. Переходим ко второму пункту, а именно к нормализации отношений (таблиц). Нормализация - это пошаговый, обратимый процесс замены исходной схемы другой схемой, в которой таблицы имеют более простую и логичную структуру.
24. Инфологическая модель базы данных
Цель инфологического моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.
Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений:
Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.
Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности.
Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание (п. 1.2) ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).
Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.
25. Иерархические структуры данных и манипулирование ими
Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.
Тип дерева состоит из одного "корневого" типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждое из которых является некоторым типом дерева). Тип дерева в целом представляет собой иерархически организованный набор типов записи.
Пример типа дерева (схемы иерархической БД):
ЗдесьОтдел является предком для Начальник и Сотрудники, а Начальник и Сотрудники - потомки Отдел. Между типами записи поддерживаются связи.
База данных с такой схемой могла бы выглядеть следующим образом (мы показываем один экземпляр дерева):
Все экземпляры данного типа потомка с общим экземпляром типа предка называются близнецами. Для БД определен полный порядок обхода - сверху-вниз, слева-направо.
В IMS использовалась оригинальная и нестандартная терминология: "сегмент" вместо "запись", а под "записью БД" понималось все дерево сегментов.
Манипулирование данными
Примерами типичных операторов манипулирования иерархически организованными данными могут быть следующие:
Найти указанное дерево БД (например, отдел 310);
Перейти от одного дерева к другому;
Перейти от одной записи к другой внутри дерева (например, от отдела - к первому сотруднику);
Перейти от одной записи к другой в порядке обхода иерархии;
Вставить новую запись в указанную позицию;
Удалить текущую запись.
26. Манипулирование и ограничение целостности данных
Как известно, двумя фундаментальными языками запросов к реляционным БД являются языки реляционной алгебры и реляционного исчисления. При всей своей строгости и теоретической обоснованности эти языки редко используются в современных реляционных СУБД в качестве средств пользовательского интерфейса. Запросы на этих языках трудно формулировать и понимать. SQL представляет собой некоторую комбинацию реляционного исчисления кортежей и реляционной алгебры, причем до сих пор нет общего согласия, к какому из классических языков он ближе. При этом возможности SQL шире, чем у этих базовых реляционных языков, в частности, в общем случае невозможна трансляция запроса, сформулированного на SQL, в выражение реляционной алгебры, требуется некоторое ее расширение.
Существенными свойствами подъязыка запросов SQL являются возможность простого формулирования запросов с соединениями нескольких отношений и использование вложенных подзапросов в предикатах выборки. Вообще говоря, одновременное наличие обоих средств избыточно, но это дает пользователю при формулировании запроса возможность выбора более понятного ему варианта.
В предикатах со вложенными подзапросами в SQL System R можно употреблять теретико-множественные операторы сравнения, что позволяет формулировать квантифицированные запросы (эти возможности обычно труднее всего понимаются пользователями и поэтому в дальнейшем в SQL появились явно квантифицируемые предикаты).
Существенной особенностью SQL является возможность указания в запросе потребности группирования отношения-результата по указанным полям с поддержкой условий выборки на всю группу целиком. Такие условия выборки могут содержать агрегатные функции, вычисляемые на группе. Эта возможность SQL главным образом отличает этот язык от языков реляционной алгебры и реляционного исчисления, не содержащих аналогичных средств.
Еще одним отличием SQL является необязательное удаление кортежей-дубликатов в окончательном или промежуточных отношениях-результатах. Строго говоря, результатом оператора выборки в языке SQL является не отношение, а мультимножество кортежей. В тех случаях, когда семантика запроса требует наличия отношения, уничтожение дубликатов производится неявно.
Самый общий вид запроса на языке SQL представляет теоретико-множественное алгебраическое выражение, составленное из элементарных запросов. В SQL System R допускались все базовые теретико-множественные операции (UNION, INTERSECT и MINUS).
Работа с неопределенными значениями в SQL System R до конца продумана не была, хотя неявно предполагалось использование трехзначной логики при вычислении логических выражений.
Операторы манипулирования данными UPDATE и DELETE построены на тех же принципах, что и оператор выборки данных SELECT. Набор кортежей указанного отношения, подлежащих модификации или удалению, определяется входящим в соответствующий оператор логическим выражением, которое может включать сложные предикаты, в том числе и с вложенными подзапросами.
В операторе вставки кортежа(ей) в указанное отношение заносимый кортеж может задаваться как в литеральной форме, так и с помощью внутреннего подоператора выборки.
Язык SQL System R включал очень мощные средства контроля и поддержания целостности БД. Средства контроля базировались на аппарате ограничений целостности (ASSERTIONS). Фактически, ограничение целостности - это логическое выражение, вычисляемое над текущим состоянием БД, ложность которого соответствует нецелостному состоянию БД. Логическое выражение ограничения целостности могло содержать любой допустимый в языке предикат.
Более точно, ограничения целостности делились на два класса: проверяемые после выполнения оператора манипулирования данными и проверяемые при завершении транзакции или при выполнении специального оператора INFORCE INTEGRITY. Типы предикатов, которые можно использовать в операторах определения ограничений целостности разных классов, различаются. В операторах первого класса проверяется, фактически, текущий кортеж, с которым производится манипулирование. Во втором случае проверяются указанные в ограничении целостности отношения, т.е. все их кортежи. Различается и определяемая в языке реакция системы на нарушения ограничений целостности разных классов. В первом случае нарушение ограничения целостности приводит к откату транзакции в точку, непосредственно предшествующую операции манипулирования данными, выполнение которого вызвало нарушение ограничения целостности. Во втором случае ограничение приводит к полному откату транзакции к ее началу.
Очень важным механизмом, определенным в языке SQL System R, является механизм триггеров. В контексте System R этот механизм рассматривался главным образом как средство автоматического поддержания целостности БД. При определении триггера указывалось условие проверки его применимости (имя отношения и тип операции манипулирования данными), условие применимости триггера (логическое выражение, построенное по правилам, близким к правилам для ограничений целостности первого класса) и действие, которое должно быть выполнено над БД в случае истинности условия применимости. Такое действие могло быть выражено с помощью произвольного оператора манипулирования данными. Во время выполнения действия могли срабатывать другие триггеры и т.д.
Механизмы ограничений целостности и триггеров System R являлись очень мощными и общими, но реализация их очень трудна и накладна (как уже отмечалось, триггеры так и не были реализованы в System R). Дополнительную сложность в реализации создавал тот факт, что допускалось (по крайней мере не запрещалось языком) определение ограничений целостности и триггеров в пределах той же транзакции, в которой выполняются операторы манипулирования данными. При наиболее полной реализации требовалось бы большое число дополнительных действий во время выполнения транзакции. Кроме того, в ряде случаев отсутствие зафиксированной семантики соответствующих конструкций языка приводило к неоднозначному пониманию выполнения транзакций.
27. Учётные записи (формуляры) пользователей БД
Учетные записи пользователей
Учетные записи пользователей – это уникальные имена и пароли, которые используются для определения пользователя или клиентского приложения, подключившегося к базе данных. В ArcGIS учетные записи определяют,кто какими данными владеет. Учетные записи пользователя также являются способом управления типом доступа(если имеется) пользователя или клиентского приложения к базе данных или базе геоданных и их наборам данных.
В SQL Server вы можете создавать учетные записи пользователей базы данных или создать учетные записи базы данных на основе сетевых учетных записей или учетных записей операционной системы.
Помните, что вы можете создавать имена пользователей, содержащие специальные символы, и за пределами ArcGIS, однако такие имена должны использовать разделители для корректной работы с ними. ArcGIS добавляет разделитель автоматически при передаче на SQL Server; вам не нужно вводить их при входе. Например, если вы используете имяmap.user, введите map.user, а не "map.user" при подключении к SQL Server из ArcGIS. Для получения более подробной информации об обычных и сложных идентификаторах обратитесь к документации к SQL Server.
Владение данными
В ArcGIS пользователь, создающий таблицы, классы объектов и представления базы геоданных или базы данных, является владельцем этих наборов данных. Например, если администратор базы геоданных создает базу геоданных, то он является владельцем системных таблиц базы геоданных, которые создаются в СУБД в это время. Поэтому пользователь, который создает класс объектов, является его владельцем.
Пользователь, чье имя используется для создания подключения к базе геоданных во время создания наборов данных, является владельцем этих данных.
Пользователи, являющиеся владельцами данных, должны также иметь в базе данных схемы, названия которых совпадают с именем пользователя.
Например, сотрудники с частичной занятостью Борис и Базиль имеют право создавать наборы данных в базе геоданных. Борис и Базиль используют один и тот же компьютер. Если они оба используют учетную запись Базиля для подключения к базе геоданных в ArcCatalog, все созданные ими наборы данных будут принадлежать ему и будут сохранены в его схеме.
Если Борис хочет, чтобы созданные им данные сохранялись в его схеме, он должен изменить свойства подключения к базе данных и перед созданием данных подключаться к базе данных под своим именем пользователя.
Важно знать, кто является владельцем данных, так как удаление учетной записи пользователя из базы данных в том случае, если пользователь является владельцем данных, невозможно. Кроме того, важно помнить, что пользователь, создавший набор данных, контролирует уровень доступа других пользователей к этому набору данных.
Доступ пользователей
У вашей базы данных должна быть возможность проверить учетные записи пользователей, которые пытаются к ней подключиться. Это означает, что администратор базы данных должен добавить пользователей в базу данных. База данных осуществляет проверку списка пользователей, чтобы убедиться, что пользователю разрешено создавать подключение. Этот процесс называется аутентификацией.
При работе с базами данных SQL Server используются два типа аутентификации: аутентификация средствами операционной системы и аутентификация в базе данных.
Аутентификация средствами операционной системы (ОС) указывает на то, что пользователь вошел в систему на компьютере с помощью своей учетной записи. Учетные данные для авторизации предоставляются базе данных операционной системой компьютера пользователя. Для подключающегося пользователя это означает, что он должен только войти в систему на своем компьютере. В этом случае отдельного подключения к базе данных не требуется. Для администратора базы данных это означает, что существующая учетная запись должна быть добавлена в базу данных, и база данных должна быть настроена так, чтобы распознавать существующие учетные записи пользователей.
При использовании аутентификации в базе данных пользователи подключаются к серверу, а затем отдельно к базе данных.
После добавления пользователей администратор базы данных должен также предоставить им специальные права доступа, чтобы определить их уровень доступа при работе с базой данных. Права доступа проверяются в базе данных, когда пользователь, прошедший аутентификацию, пытается получить доступ к базе данных или изменить ее объекты. Этот процесс называется авторизацией. В ArcGIS владельцы данных могут также выдавать права доступа к своим данным другим пользователям и группам.