- •Введение
- •Глава 1. Основные понятия баз данных
- •1.1. История возникновения баз данных
- •1.2. Модели данных
- •1.2.1. Иерархическая модель данных
- •1.2.2. Сетевая модель базы данных
- •1.2.3. Реляционная модель базы данных
- •1.2.4. Другие модели баз данных (ООСУБД)
- •2.1. История появления и развития SQL
- •Глава 2. SQL
- •2.2. Стандарты SQL
- •2.2.1. Стандарты ANSI/ISO
- •2.2.2. ODBC и консорциум SQL Access Group
- •2.2.3. JDBC и серверы приложений
- •2.3. SQL и переносимость
- •2.4. SQL и сети
- •2.4.1. Централизованная архитектура
- •2.4.2. Архитектура файлового сервера
- •2.4.3. Архитектура “клиент/сервер”
- •2.4.4. Многоуровневая архитектура
- •2.4.5. SQL и мэйнфреймы
- •2.4.7. SQL и UNIX
- •2.4.8. SQL и персональные компьютеры
- •2.4.9. SQL, хранилища данных и интеллектуальные ресурсы предприятия
- •2.4.10. SQL и интернет-приложения
- •2.5. Основы SQL
- •2.5.1. Использование SQL для извлечения информации из таблиц
- •2.5.2. Команда SELECT
- •2.5.3. Создание более сложных предикатов в предложении SELECT
- •2.5.4. Формирование вывода запросов
- •2.5.5. Агрегатные группы
- •2.6. Запросы к нескольким таблицам
- •2.6.1. Подзапросы
- •2.6.2. Использование операторов ANY, ALL и SOME
- •2.6.3. Использование предложения UNION
- •2.6.4. Ввод, удаление и изменение значения поля
- •2.7. DDL (Язык описания данных)
- •2.7.1. Создание таблиц
- •2.7.2. Индексы
- •2.7.3. Изменение структуры таблицы после ее создания
- •2.8. Ограничение данных
- •2.8.1. Ограничение таблиц
- •2.8.2. Установка значений по умолчанию
- •2.9. Поддержка целостности данных
- •2.9.1. Первичные ключи
- •2.9.2. Пользовательские представления
- •2.10. Модификация данных с помощью представлений
- •2.11. Разграничение доступа в базе данных
- •Глава 3. Математические основы реляционных баз данных
- •3.1. Отношения и их схемы
- •3.2. Реляционные операторы
- •3.2.1. Булевы операции
- •3.2.2. Оператор выбора
- •3.2.3. Оператор проекции
- •3.2.4. Оператор соединения
- •3.2.5. Другие операции на отношениях
- •3.2.6. Оператор деления
- •3.2.7. Оператор переименования атрибутов
- •3.2.8. Оператор эквисоединения
- •3.2.9. Расширения для сравнения на доменах
- •3.2.9.1. Расширение выбора
- •3.3. Реляционная алгебра
- •3.3.1. Дополнительные операторы
- •3.3.1.1. Оператор расщепления
- •3.3.1.2. Оператор FACTOR
- •3.4. Функциональные зависимости
- •3.4.1. Определение
- •3.4.2. Аксиомы вывода
- •3.4.3. Применение аксиом вывода
- •3.4.4. Выводы на основе аксиом вывода
- •3.4.6. Направленные ациклические графы вывода
- •3.4.7. Проверка принадлежности к замыканию множества функциональных зависимостей
- •3.5. Покрытия функциональных зависимостей
- •3.5.1. Покрытия и эквивалентность
- •3.5.2. Неизбыточные покрытия
- •3.5.3. Редуцированные покрытия
- •3.5.3.1. Посторонние атрибуты
- •3.5.3.3. Алгоритм построения редуцированного покрытия
- •3.5.3.4. Канонические покрытия
- •3.5.3.5. Структура неизбыточных покрытий
- •3.5.4. Минимальные покрытия
- •3.5.4.1. Прямая определяемость
- •3.5.4.2. Вычисление минимальных покрытий
- •3.5.4.3. Оптимальные покрытия
- •3.5.5. Составные функциональные зависимости
- •3.5.6. Кольцевые покрытия
- •3.6. Многозначные зависимости и зависимости соединения
- •3.6.1. Многозначные зависимости
- •3.6.2. Многозначные и функциональные зависимости
- •3.6.3. Аксиомы вывода для многозначных зависимостей
- •3.6.4. Только многозначные зависимости
- •3.6.5. Функциональные и многозначные зависимости
- •3.6.6. Зависимости соединения
- •3.7. Синтез схем реляционных баз данных
- •3.7.1. Базы данных и их схемы
- •3.7.2. Нормальные формы баз данных
- •3.7.2.1. Первая нормальная форма
- •3.7.2.2. Вторая нормальная форма
- •3.7.2.4. Нормальная форма Бойса - Кодда (НФБК)
- •3.7.2.5. Четвертая нормальная форма
- •3.7.2.3. Третья нормальная форма
- •3.8. Алгоритмы синтеза схем баз данных
- •3.8.1. Нормализация через декомпозицию
- •3.8.2. Недостатки нормализации через декомпозицию
- •3.8.3. Нормализация посредством синтеза
- •Глава 4. Система управления базами данных PostgreSQL
- •4.1. Установка
- •4.2. Запуск и останов сервера PostgreSQL
- •4.2.1. Утилита psql
- •4.2.2. Создание базы данных
- •4.3. Объекты базы данных
- •4.4. Функции и операторы
- •4.4.1. Логические операторы
- •4.4.2. Операторы сравнения
- •4.5. Клиентские приложения PostgreSQL
- •4.5.1. clusterdb
- •4.5.2. createdb
- •4.5.3. createuser
- •4.5.4. dropdb
- •4.5.5. dropuser
- •4.5.6. ecpg
- •4.5.7. pg_basebackup
- •4.5.8. pgbench
- •4.5.9. pg_config
- •4.5.10. pg_dump
- •4.5.11. pg_dumpall
- •4.5.12. pg_isready
- •4.5.13. pg_receivewal
- •4.5.14. pg_restore
- •4.5.15. psql
- •4.5.16. reindexdb
- •4.5.17. vacuumdb
- •4.6. Серверные приложения PostgreSQL
- •4.6.1. initdb
- •4.6.2. pg_archivecleanup
- •4.6.3. pg_checksums
- •4.6.4. pg_controldata
- •4.6.6. pg_resetwal
- •4.6.7. pg_rewind
- •4.6.8. pg_test_fsync
- •4.6.9. pg_test_timing
- •4.6.10. pg_upgrade
- •4.6.11. pg_waldump
- •4.6.12. postgres
- •4.6.13. postmaster
- •4.7. Серверное программирование
- •4.7.1. Расширение SQL
- •4.7.2. Триггеры
- •Заключение
- •Библиографический список
- 54 -
Если не указывать к какой таблице относится столбец, по которому таблицы связаны предложением WHERE, то будет выдана ошибка.
CREATE VIEW v_group AS |
|
|
|
|
|
|
SELECT family, name, gpa ,stgroup, |
|
|||||
v.department, faculty |
|
|
|
|
|
|
FROM v_students v, departments d |
|
|||||
WHERE v.department = d.department; |
|
|||||
CREATE VIEW |
|
|
|
|
|
|
SELECT family,name,stgroup,department |
as dep,faculty |
|||||
FROM v_group ; |
|
|
|
|
|
|
family |
| name |
| |
stgroup | |
dep |
| faculty |
|
--------------+--------+---------+---------+--------- |
||||||
Колычева |
| Лия |
| |
342 |
| |
ЭВМ |
| ФВТ |
Фахрудинова |
| Тамара | |
342 |
| |
ЭВМ |
| ФВТ |
|
Никулкин |
| Сергей | |
342 |
| |
ЭВМ |
| ФВТ |
|
Катеринченко |
| Андрей | |
342 |
| |
ЭВМ |
| ФВТ |
|
Балашов |
| Андрей | |
342 |
| |
ЭВМ |
| ФВТ |
|
Чертков |
| Максим | |
344 |
| |
САПР |
| ФВТ |
|
Малин |
| Сергей | |
345 |
| |
ВПМ |
| ФВТ |
|
(7 rows) |
|
|
|
|
|
|
Следует заметить, что представления могут включать и подзапросы.
Многие представления могут быть доступны только для чтения, т. е. их можно запрашивать, но нельзя модифицировать через них данные в физических таблицах.
Как и любой другой объект базы данных, удалить представление можно с помощью команды DROP:
DROP VIEW v_group ; DROP VIEW
2.10. Модификация данных с помощью представлений
Рассмотрим, как можно применять команды модификации данных (команды языка DML) ВСТАВИТЬ (INSERT), ИЗМЕНИТЬ (UPDATE) и УДАЛИТЬ (DELETE) для представлений.
Следует заметить, что не все представления можно модифицировать.
Поскольку само представление является результатом запроса, то мы пытаемся изменять результат запроса, но модификация реально воздействует на значение в таблице, к которой и был сделан запрос.
Для того чтобы представление было модифицируемым, оно:
•должно выводиться из одной, и только из одной, базовой таблицы;
-55 -
•должно содержать первичный ключ этой таблицы;
•не должно иметь никаких полей, которые являлись бы агрегатными функциями;
•не должно содержать DISTINCT в своем определении;
•не должно использовать GROUP BY или HAVING в своем определении;
•не должно использовать подзапросы;
•может быть использовано в другом представлении, но это представление должно также быть модифицируемым;
•не должно использовать константы, строки или выражения для значений среди выбранных полей вывода;
•для INSERT должно содержать любые поля основной таблицы, которые имеют ограничение NOT NULL, если другое ограничение по умолчанию не определено.
Модифицируемые представления фактически подобны окнам в базовых таблицах. Они показывают кое-что, но не обязательно всё, из содержимого таблицы. Они могут ограничивать определенные строки (использованием предикатов) или специально именованные столбцы (с исключениями), но они представляют значения непосредственно и не выводят информацию с использованием составных функций и выражений.
Модифицируемые представления в основном используются точно так же, как и базовые таблицы. Фактически пользователи не могут даже осознать, является ли объект, который они запрашивают, базовой таблицей или представлением.
Представления только_чтение позволяют получать и переформатировать данные более рационально.
Представления только_чтение могут также использоваться для защиты данных. Например, вы можете захотеть, чтобы некоторые пользователи видели агрегатные данные, а не представление индивидуальных значений.
Следующее представление, содержащее часть информации о студентах определенной группы, является модифицируемым:
CREATE VIEW stud2
AS SELECT family, name, gpa, sex FROM students WHERE stgroup='342';
CREATE VIEW
В данном представлении сделана только выборка части столбцов (все кроме номера группы) и строк, относящихся к группе 342.
SELECT * FROM stud2;
|
|
|
- 56 - |
|
family |
| name |
| |
gpa |
| sex |
-------------- |
+-------- |
+ |
------ |
+----- |
Балашов |
| Андрей | |
5.00 |
| м |
|
Катеринченко |
| Андрей | |
4.59 |
| м |
|
Никулкин |
| Сергей | |
4.79 |
| м |
|
Фахрудинова |
| Тамара | |
4.12 |
| ж |
|
Колычева |
| Лия |
| |
4.38 |
| ж |
(5 rows) |
|
|
|
|
Мы вполне можем изменить данные в этом представлении, например средний балл определенного студента.
UPDATE stud2 SET gpa = |
3.25 WHERE family='Колычева'; |
||
UPDATE 1 |
|
|
|
SELECT * FROM stud2; |
|
|
|
family |
| name |
| gpa |
| sex |
-------------- |
+-------- |
+------ |
+----- |
Балашов |
| Андрей |
| 5.00 | м |
|
Катеринченко |
| Андрей |
| 4.59 | м |
|
Никулкин |
| Сергей |
| 4.79 | м |
|
Фахрудинова |
| Тамара |
| 4.12 | ж |
|
Колычева |
| Лия |
| 3.25 | ж |
|
(5 rows) |
|
|
|
Следующее представление содержит агрегатную функцию, позволяющую получать информацию о среднем балле по группе:
CREATE VIEW avg_group
AS SELECT stgroup, AVG(gpa) AS agpa FROM students
GROUP BY |
stgroup; |
||
CREATE |
VIEW |
|
|
SELECT |
* |
FROM avg_group ; |
|
stgroup |
| |
agpa |
|
--------- |
|
+-------------------- |
|
345| 4.8700000000000000
346| 4.0400000000000000
347| 4.3900000000000000
342| 4.3500000000000000
344| 4.3100000000000000
(5 rows)
Попытка его модификации приведет к следующему результату:
UPDATE avg_group SET agpa=4.25 WHERE stgroup = '344'; ERROR: cannot update view "avg_group"
DETAIL: Views containing GROUP BY are not automatically updatable.
-57 -
Всообщении об ошибке указывается на то, что нельзя изменять представление, содержащее агрегатные функции (в нашем случае это функция для получения среднего балла AVG).
Следует обратить внимание на одну особенность при работе с представлениями, когда результат запроса, например на изменение данных, не оказывает воздействия на базовую таблицу, если касается строк, которые не представлены в представлении. В представлении stud2 выбрана информация, которая относится исключительно к студентам из группы 342, поэтому запросы на изменение данных, которые относятся к студентам других групп, будут игнорироваться.
UPDATE stud2 SET gpa = 4.15
WHERE family='Малин';
UPDATE |
0 |
|
|
SELECT |
* FROM students ; |
|
|
family |
| name |
| stgroup | gpa | sex |
|
--------------+----------+---------+------+-----
Балашов |
| Андрей |
| 342 |
| 5.00 | м |
|
Катеринченко |
| Андрей |
| 342 |
| 4.59 | м |
|
Малин |
| Сергей |
| 345 |
| 4.87 | м |
|
Никулкин |
| Сергей |
| 342 |
| 4.79 | м |
|
Фахрудинова |
| Тамара |
| 342 |
| 4.12 | ж |
|
Чертков |
| Максим |
| 344 |
| 4.31 |
| м |
Нефедов |
| Максим |
| 347 |
| 4.39 |
| м |
Косымскова |
| Светлана |
| 346 |
| 4.04 |
| ж |
Колычева |
| Лия |
| 342 |
| 3.25 |
| ж |
(9 rows) |
|
|
|
|
По результатам запроса мы видим, что изменения затронули 0 строк и средний балл у студента группы 345 Малина не изменился.
2.11. Разграничение доступа в базе данных
Во-первых, администраторы баз данных сами создают пользователей и дают им привилегии.
Во-вторых, пользователи, которые создают таблицы, сами имеют права на управление этими таблицами.
Привилегии определяют, может ли указанный пользователь выполнить данную команду.
Имеется несколько типов привилегий, соответствующих нескольким типам операций. Привилегии даются и отменяются двумя командами SQL: GRANT (ДОПУСК) и REVOKE (ОТМЕНА).
Команда, посланная в базе данных, ассоциируется с определённым пользователем, а SQL может использовать специальное
- 58 -
ключевое слово USER, которое ссылается на Идентификатор доступа, связанный с текущей командой. Команда интерпретируется и разрешается (или запрещается) на основе информации, связанной с Идентификатором доступа пользователя, подавшего команду.
Каждый пользователь БД SQL имеет набор привилегий, который определяет, что пользователю разрешается делать.
SQL-привилегии - это привилегии на объекты, то есть пользователь имеет привилегию для выполнения данной команды только на определенном объекте в БД. Очевидно, что привилегии должны различать эти объекты, но система привилегий, основанная исключительно на привилегиях объекта, не может адресовать всё, что нужно SQL.
Пользователь имеет все привилегии на созданные им объекты и может передавать привилегии другим пользователям.
Вот основные привилегии, которые можно назначить
пользователю: |
|
SELECT |
Пользователь может выполнять запросы в таблице. |
INSERT Пользователь может выполнять команду INSERT в таблице. |
|
UPDATE |
Пользователь может выполнять команду UPDATE в |
таблице, при этом можно ограничить эту привилегию для определенных столбцов таблицы.
DELETE |
Пользователь с этой привилегией может выполнять |
команду DELETE в таблице. |
|
REFERENCES Пользователь может определить внешний ключ, который использует один или более столбцов этой таблицы, как родительский ключ, можно ограничить эту привилегию для определённых столбцов.
Здесь были перечислены только основные привилегии на объекты, которые требуются для повседневной работы пользователя.
CREATE USER petrov; CREATE ROLE
SELECT table_catalog, table_schema, table_name, privilege_type
FROM information_schema.table_privileges WHERE grantee = 'petrov';
table_catalog|table_schema | |
table_name | privilege_type |
|
-------------+------------- |
+ |
------------+--------------- |
(0 rows) |
|
|
Из приведенного выше примера видно, что вновь созданный пользователь petrov не имеет ни одной привилегии ни на одну таблицу в базе данных.
- 59 -
Теперь дадим этому пользователю привилегии на чтение и запись в одну таблицу и только на чтение в другую таблицу.
GRANT SELECT, UPDATE ON students TO petrov ; GRANT
GRANT SELECT ON stgroups TO petrov ; GRANT
SELECT table_catalog, table_schema, table_name, privilege_type
FROM information_schema.table_privileges WHERE grantee = 'petrov';
table_catalog|table_schema |
|table_name |
| privilege_type |
|
-------------- |
+------------- |
+----------- |
+-------------- |
university |
| public |
| students |
| SELECT |
university |
| public |
| students |
| UPDATE |
university |
| public |
| stgroups |
| SELECT |
(3 rows) |
|
|
|
Теперь мы видим, что заданные привилегии зафиксированы в словаре данных.
Предположим, что новому пользователю надо дать привилегии только на один из столбцов в таблице, например позволить ему изменять только средний балл студентов, тогда это следует реализовать следующим образом:
CREATE USER sidorov;
CREATE ROLE
GRANT UPDATE (gpa) ON students TO sidorov;
GRANT
Удаление привилегии выполняется командой REVOKE. Синтаксис команды REVOKE похож на GRANT, но имеет обратный смысл.
REVOKE UPDATE ON students FROM petrov; REVOKE
SELECT table_catalog, table_schema, table_name, privilege_type
FROM information_schema.table_privileges WHERE grantee = 'petrov';
table_catalog |table_schema |
|table_name |
| privilege_type |
|
-------------- |
+------------- |
+----------- |
+------------ |
university |
| public |
| stgroups |
| SELECT |
university |
| public |
| students |
| SELECT |
(2 rows) |
|
|
|
