
- •254 Понимание sql
- •256 Понимание sql
- •258 Понимание sql
- •260 Понимание sql
- •262 Понимание sql
- •266 Понимание sql
- •268 Понимание sql
- •270 Понимание sql
- •272 Понимание sql
- •274 Понимание sql
- •276 Понимание sql
- •278 Понимание sql
- •280 Понимание sql
- •282 Понимание sql
- •284 Понимание sql
- •286 Понимание sql
- •288 Понимание sql
- •290 Понимание sql
- •292 Понимание sql
- •294 Понимание sql
- •Глава 23 продолжит обсуждение о выводах в sql, таких как сохранение
290 Понимание sql
______________________________________________________________________
ГЛ. 22
способа. Вы можете создавать представление которое дает счет, среднее,
и общее количество для порядков на каждый день порядка:
CREATE VIEW Datetotals
AS SELECT odate, COUNT (*), SUM (amt), AVG (amt)
FROM Orders
GROUP BY odate;
Теперь вы передаете пользователю Diane - привелегию SELECT в предс-
тавлении Datetotals:
GRANT SELECT ON Datetotals TO Diane;
ИСПОЛЬЗОВАНИЕ ПРЕДСТАВЛЕНИЙ В КАЧЕСТВЕ
АЛЬТЕРНАТИВЫ К ОГРАНИЧЕНИЯМ
Одной из последних прикладных программ из серии, описанной в Главе 18,
является использование представлений с WITH CHECK OPTION как альтер-
нативы к ограничениям. Предположим что вы хотели удостовериться, что
все значения поля city в таблице Продавцов находятся в одном из городов
где ваша компания в настоящее время имеет ведомство. Вы можете устано-
вить ограничение CHECK непосредственно на столбец city, но позже мо-
жет стать трудно его изменить, если ваша компания например откроет там
другие ведомства. В качестве альтернативы, можно создать представление,
которое исключает неправильные значения city:
CREATE VIEW Curcities
AS SELECT *
FROM Salespeople
WHERE city IN ('London', 'Rome', 'San Jose', 'Berlin')
WITH CHECK OPTION;
Теперь, вместо того, чтобы предоставить пользователям привилегии мо-
дифицирования в таблице Продавцов, вы можете предоставить их в
представлении Curcities. Преимущество такого подхода - в том, что если
вам нужно сделать изменение, вы можете удалить это представление,
создать новое, и предоставить в этом новом представлении привилегии
пользователям, что проще чем изменять ограничения. Недостатком явля-
ется то, что владелец таблицы Продавцов также должен использовать
это представление если он не хочет чтобы его собственные команды бы-
ли отклонены.
С другой стороны, этот подход позволяет владельцу таблицы и любым
другим получить привилегии модификации в самой таблице, а не в пре-
дставлении, чтобы делать исключения для ограничений.
ОПРЕДЕЛЕНИЕ: КТО ЧТО МОЖЕТ ДЕЛАТЬ 291
______________________________________________________________________
Это часто бывает желательно, но не выполнимо, если вы используете ог-
раничения в базовой таблице. К сожалению, эти исключения нельзя бу-
дет увидеть в представлении. Если вы выберите этот подход, вам захочет-
ся создать второе представление, содержащее только исключения:
CREATE VIEW Othercities
AS SELECT *
FROM Salespeople
WHERE city NOT IN ('London', 'Rome', 'San Jose',
'Berlin')
WITH CHECK OPTION;
Вы должны выбрать для передачи пользователям только привилегию SELECT
в этом представлении, чтобы они могли видеть исключенные строки, но не
могли помещать недопустимые значения city в базовую таблицу. Фактически,
пользователи могли бы сделать запрос обоих представлений в объединении и
увидеть все строки сразу.
========= ДРУГИЕ ТИПЫ ПРИВИЛЕГИЙ ===========
Вы разумеется хотите знать, кто же имеет право первым создать таблицу.
Эта область привилегии не относится к ANSI, но не может игнорировать-
ся. Все стандартные привилегии ANSI вытекают из этой привилегии; при-
вилегии создателей таблиц которые могут передавать привилегии объекта.
Если все ваши пользователи будут создавать в системе базовые таблицы
с разными размерами это приведет к избыточности в них и к неэффетив-
ности системы. Притягивают к себе и другие вопросы:
- Кто имеет право изменять, удалять, или ограничивать таблицы?
- Должны ли права создания базовых таблиц отличаться от прав
создания представлений?
- Должен ли быть суперпользователь - пользователь который отвечает
за поддержание базы данных и следовательно имеющий наибольшие,
или все привилегии, которые не предоставляются индивидуально?
Пока ANSI не принимает в этом участие, а SQL используется в различных
средах, мы не можем дать окончательный ответ на эти вопросы. Мы пред-
лагаем рассмотреть здесь кусок наиболее общих выводов.
Привилегии которые не определяются в терминах специальных объектов
данных называются - привилегиями системы, или правами базы данных.
На базисном уровне, они будут вероятно включать в себя право создавать