Языки запросов. Языки описания данных. Языки манипулирования данными. Особенности языковых средств управления и обеспечения безопасности данных в реляционных СУБД.

 

Внутренний язык СУБД для работы с данными состоит из двух частей:

- язык определения (описания) данных (Data Definition Language – DDL) – используется для определения схемы базы данных;

- язык управления данными (Data Manipulation Language – DML) – используется для чтения и обновления данных.

 

Язык DDL – это декларативный язык, который позволяет описать и поименовать сущности, необходимые для работы некоторого приложения, а также связи между различными сущностями. Язык нельзя использовать для управления данными.

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

Теоретически для каждой схемы в трехуровневой архитектуре можно было бы выделить несколько различных языков DDL:

- язык DDL внешних схем;

- язык DDL концептуальной схемы;

- язык DDL внутренней схемы.

На практике существует один общий язык DDL, который позволяет задавать спецификации, как минимум, для внешней и внутренней схем.

 

Язык DML – это язык, содержащий набор операторов для поддержки основных операций манипулирования содержащимися в базе данными.

К операциям управления данными относятся следующие:

- вставка в базу данных новых сведений;

- модификация сведений, хранимых в базе данных;

- извлечение сведений, содержащихся в базе данных;

- удаление сведений из базы данных.

Понятие манипулирования данными применимо как к внешнему и концептуальному уровням, так и к внутреннему уровню.

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

Следует различать два типа языков DML:

- процедурный;

- непроцедурный.

 

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

С помощью процедурного языка DML программист указывает:

- какие данные ему необходимы

- как их можно получить.

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

Языки DML сетевых и иерархических СУБД обычно являются процедурными.

 

Непроцедурный язык DML – это язык, который позволяет указать лишь то, какие данные требуются, но не то, как их следует извлекать.

Непроцедурные языки DML позволяют определить весь набор требуемых данных с помощью одного оператора извлечения или обновления. С помощью непроцедурных языков DML пользователь указывает, какие данные ему нужны, не определяя способ их получения. СУБД транслирует выражение на языке DML в процедуру (набор процедур), которая обеспечивает манипулирование набором данных.

Непроцедурные языки часто также называют декларативнымиязыками.

Непроцедурные языки обычно проще в понимании и использовании, т. к. большая часть работы при этом выполняется СУБД, а не пользователем.

 

Запрос представляет собой специальным образом описанное требование, определяющее состав производимых над БД операций по выборке, удалению или модификации хранимых данных.

Для подготовки запросов с помощью различных СУБД чаще всего используются два основных языка описания запросов:

- язык QBE (Query By Example) — язык запросов по образцу;

- SQL (Structured Query Language) — структурированный язык запросов.

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

- язык QBE предполагает ручное или визуальное формирование запроса,

- SQL предполагает программирование запроса.

Теоретической основой языка QBE является реляционное исчисление с переменными доменами. Структурированный язык запросов SQL основан на реляционном исчислении с переменными кортежами.

Языки безопасности баз даных

Администратору СУБД необходим специальный инструментарий:

- определения конкретных назначений или установления правил;

- ограничения доступа;

- управления системой разграничения доступа;

- управления системой коллективной обработки данных.

Такой инструментарий должен основываться на определенном языке, позволяющем описывать и устанавливать необходимые установки политики безопасности в конкретной АИС.

В реляционных СУБД такой язык должен являться соответственно составной частью языка SQL.

 

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

GRANT <список привилегий> ON <Имя Объекта> ТО <Имена Пользователей> [WITH GRANT OPTION];

REVOKE <список привилегий> ON <Имя Объекта> FROM <Имена Пользователей>;

 

Список привилегий составляют разрешенные инструкции (операции) над объектом:

- SELECT - чтение данных;

- INSERT - создание новых строк;

- UPDATE - изменение существующих данных;

- DELETE - удаление строк;

- REFERENCES - ссылка на первичный ключ из внешнего ключа. Это всегда необходимо делать при предоставлении привилегий к таблицам, содержащим внешние ключи;

- ALL - выборка, добавление, изменение, удаление и ссылка на первичный ключ из внешнего ключа;

- EXECUTE - выполнение хранимой процедуры или вызов ее с использованием SELECT. Эта привилегия никогда не предоставляется как часть привилегии ALL чтение данных;

- ROLE - предоставляет все привилегии, назначенные роли. Если роль существует и имеет назначенные ей привилегии, она становится привилегией, которая может явно назначаться пользователям. Роль никогда не предоставляется как часть привилегии ALL.

 

Объектом может быть таблица, просмотр, хранимая процедура или роль, хотя не все привилегии применимы ко всем типам объектов. Например, привилегия UPDATE неприменима к процедуре, а привилегия EXECUTE - к таблице или просмотру.

Пользователи:

1. Роли. Когда роли назначены привилегии, она становится пользователем. Основная идея использования ролей заключается в том, чтобы упаковать и управлять дискретными наборами привилегий, которые могут назначаться и отменяться как одно целое.

2. Просмотры. Просмотрам нужны полномочия для доступа к таблицам, другим просмотрам и к хранимым процедурам.

3. Процедуры и триггеры. Хранимой процедуре, которая обращается к таблицам и просмотрам и выполняет другие процедуры, нужны полномочия к этим объектам. Триггеру, который выполняет процедуры, нужны к ним полномочия, а также к любым таблицам и просмотрам, к которым он обращается, отличным от той таблицы, которой он принадлежит.

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

 

Директива WITH GRANT OPTION наделяет перечисленных пользователей дополнительными особыми полномочиями по предоставлению указанных в списке привилегий-полномочий другим пользователям. Необязательное предложение.

Директива WITH ADMIN OPTION позволяет получающему роль предоставлять эту роль другим пользователям, а также отменять ее. Она работает таким же образом, что и WITH GRANT OPTION для обычных полномочий.

 

Оператор REVOKE требуется для удаления полномочий, назначенных операторами GRANT. Согласно стандарту, REVOKE должен каскадом отменить все привилегии, полученные всеми пользователями как результат WITH GRANT OPTION от данного пользователя.

Только пользователь SYSDBA или пользователь, предоставивший привилегию, могут отменить ее - те же самые или другие привилегии, предоставленные другими пользователями, не отменяются.

Полномочия, предоставленные "в куче", не могут отменяться индивидуально. Это означает:

- привилегия, которую пользователь получил в результате назначения ALL или в качестве роли, может быть отменена только предоставившим эту привилегию, путем отмены ALL или роли соответственно;

- привилегии, предоставленные для PUBLIC, могут быть отменены только FROM PUBLIC.