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

е) GRANT SELECT, UPDATE ( SALARY, TAX ) ON UST TO Ward ;

В этом решении используется то же представление, что и в предыдущем.

ж) CREATE VIEW PREACHERS AS

SELECT STATS.* FROM STATS

WHERE STATS.OCCUPATION = Preacher ; GRANT ALL PRIVILEGES ON PREACHERS TO Pope ;

Обратите внимание на использование в данном примере сокращения ALL PRIVILEGES (все привилегии). (Директива ALL PRIVILEGES означает буквально не все привилегии, а лищь привилегии для данного объекта, которые один пользователь может делегировать другому с помощью директивы GRANT.)

з) CREATE VIEW NONSPECIALIST AS

SELECT STX.*

FROM STATS AS STX

WHERE ( SELECT COUNT(*)

FROM STATS AS STY

WHERE STY.OCCUPATION = STX.OCCUPATION ) > 10;

GRANT DELETE ON NONSPECIALIST TO Jones ;

и) CREATE VIEW JOBMAXMIN AS

SELECT STATS.OCCUPATION,

MAX ( STATS.SALARY ) AS MAXSAL,

MIN ( STATS.SALARY ) AS MINSAL FROM STATS

GROUP BY STATS.OCCUPATION ;

16.9.

GRANT SELECT ON JOBMAXMIN TO King ;

а) REVOKE SELECT ON STATS FROM Ford RESTRICT ;

б) REVOKE INSERT, DELETE ON STATS FROM Smith RESTRICT ;

в) REVOKE SELECT ON MINE FROM PUBLIC RESTRICT ;

r) REVOKE SELECT, UPDATE ( SALARY, TAX )

ON STATS FROM Nash RESTRICT ;

Д) REVOKE SELECT ON UST FROM Todd RESTRICT ;

е) REVOKE SELECT, UPDATE ( SALARY, TAX )

ON UST FROM Ward RESTRICT ;

ж) REVOKE ALL PRIVILEGES ON PREACHERS FROM Pope RESTRICT

з) REVOKE DELETE ON NONSPECIALIST FROM Jones RESTRICT ;

и) REVOKE SELECT ON JOBMAXMIN FROM King RESTRICT ;

Глава 17

Оптимизация

17.1. Введение

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

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

1. Хороший оптимизатор- обратите внимание на слово хороший !- обладает большим объемом полезной информации, которая пользователю обычно недоступна. Говоря конкретнее, оптимизатор владеет определенными статистическими данными, в частности перечисленными ниже:

количество значений в каждом домене;

текушее количество значений в каждой базовой переменной-отношении;

текушее количество различающихся значений для каждого атрибута в базовой переменной-отношении;

количество вхождений каждого значения в каждом из атрибутов и т.п.

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

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

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

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

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

Общее назначение оптимизатора состоит в выборе наиболее эффективной стратегии вычисления реляционного выражения. В этой главе описаны некоторые фундаментальные принципы и методы, применяемые в процессе оптимизации. После обсуждения вступительного примера, приведенного в разделе 17.2, в разделе 17.3 предложен обзор принципов работы оптимизатора. Затем, в разделе 17.4, обсуждается один из важнейших аспектов процедуры оптимизации - преобразование выражений (или переписывание запроса). Далее, в разделе 17.5, кратко излагается вопрос о статистических показателях базы данных. В разделе 17.6 дается более подробное описание одного из конкретных методов оптимизации, известного как декомпозиция запросов. Затем, в разделе 17.7, обсуждается вопрос о том, как в действительности реализуются некоторые реляционные операторы (например, оператор JOIN), и кратко описывается использование рассматривавшихся в разделе 17.5 статистических показателей для вычисления стоимостных оценок. И наконец в разделе 17.8 приводится краткое резюме по всему материалу данной главы.

Еще одно вводное замечание. Достаточно часто на данную тему ссылаются, как на оптимизацию запросов. Однако подобный термин несколько неточен, поскольку выражение, которое нужно оптимизировать ( запрос ), на самом деле может формироваться в контексте, отличном от интерактивного опроса базы данных. В частности, оно может быть частью операции обновления, а не операции выборки, понимаемой под запросом. Более того, сам по себе термин оптимизация является несколько преувеличенным, так как не существует гарантий, что выбранная стратегия реализации действительно оптимальна в любом понимании. На практике под оптимизированной стратегией реализации обычно понимается несколько улучшенный вариант исходного не оптимизированного выражения. (Тем не менее в некоторых немногочисленных случаях можно вполне обоснованно утверждать, что выбранная стратегия реализации будет действительно оптимальной в определенном смысле [17.31].)