W Cat - SQL за 24 часа

• Название: SQL за 24 часа
• Автор: W Cat
• Жанр: Базы данных

---

Каждая реализация языка предлагает свои средства проверки оптимальности операторов SQL. Для проверки на оптимальность операторов этой книги использовались средства Oracle?. В Oracle для этого предусмотрен ряд возможностей. Среди них средства EXPLAIN PLAN, TKPROF и команды SET. Поищите информацию о подобных средствах в документации по той реализации языка, которую вы используете.

Практикум

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

Тесты

1. Нужно ли использовать уникальный индекс в случае маленькой таблицы?

2. Что происходит, когда оптимизатор принимает решение не использовать индекс таблицы при выполнении запроса?

3. Где в выражении ключевого слова WHERE следует разместить наиболее ограничительные условия - до или после условий связывания таблиц?

Упражнения

Перепишите приведенные ниже операторы SQL в виде, который позволит увеличить скорость их выполнения по сравнению с исходным видом. Используйте таблицы EMPLOYEE_TBL И EMPLOYEE_PAY_TBL следующей Структуры.

EMPLOYEE_TBL_____

EMP_ID VARCHAR2(9) NOT NULL Ключевое поле

LAST_NAME VARCHAR2U5) NOT NULL

FIRST_NAME VARCHAR2(15) NOT NULL

MIDDLE_NAME VARCHAR2(15)

ADDRESS VARCHAR2(30) NOT NULL

CITY VARCHAR2(15) NOT NULL

STATE CHAR (2) NOT NULL

ZIP NUMBER(5) NOT NULL

PHONE CHAR(10)

PAGER CHAR(10)

CONSTRAINT EMP_PK PRIMARY KEY (EMP_ID)

EMPLOYEE__PAY_ TBL

EMP_ID VARCHAR2(9) NOT NULL Ключевое поле

POSITION VARCHAR2(15) NOT NULL

DATE_HIRE DATE

PAY_RATE NUMBER(4,2) NOT NULL

DATE_LAST-RAISE DATE

CONSTRAINT EMP_FK FOREIGN KEY (EMP_ID) REFERENCED

EMPLOYEE_TBL (EMP_ID)

a. SELECT EMP_ID, LAST_NAME, FIRST_NAME, PHONE

FROM EMPLOYEE_TBL

WHERE SUBSTR(PHONE,1,3) = '317' OR

SUBSTR(PHONE,1,3) = '812' OR

SUBSTR(PHONE,1,3) = '765';

б. SELECT LAST_NAME, FIRST_NAME

FROM EMPLOYEE_TBL

WHERE LAST_NAME LIKE '%ALL%';

в. SELECT E.EMP_ID, E.LAST_NAME, E.FIRST_NAME, EP.SALARY

FROM EMPLOYEE_TBL E,

EMPLOYEE_PAY_TBL EP

WHERE LAST_NAME LIKE 'S%'

AND E.EMP_ID EP.EMP_ID;

18-й час Управление доступом к базе данных

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

Основными на этом уроке будут следующие темы.

• Типы пользователей

• Управление пользователями

• Место пользователя в базе данных

• Имена пользователей и имена схем

• Сеансы доступа пользователей к базе данных

• Изменение атрибутов пользователя

• Пользовательские профили

• Удаление учетной записи пользователя из базы данных

• Средства, доступные пользователю

Стандарт SQL предлагает идентифицировать пользователей базы данных с помощью идентификаторов разрешения доступа (Authorization Identifier - authio). В большинстве реализаций языка идентификаторы разрешения доступа называются просто пользователями. В этой книге для обозначения идентификаторов разрешения доступа мы применяем слова "пользователь", "пользователь базы данных", "имя пользователя", а также "учетная запись пользователя". В соответствии со стандартом SQL, идентификатор разрешения доступа является именем, по которому система распознает пользователя базы данных.

Пользователь превыше всего

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

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

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

Типы пользователей

Различают следующие типы пользователей базы данных.

• Клерки, осуществляющие ввод данных

• Программисты

• Системные инженеры

• Администраторы баз данных

• Системные аналитики

• Разработчики

• Специалисты по тестированию

• Управляющий персонал

• Конечные пользователи

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

Кто управляет пользователями?

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

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

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

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

Место пользователя в базе данных

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

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

О пользователях и схемах

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

Процесс управления

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