- •Введение
- •Глава 1. Проектирование баз данных
- •1.1. История развития баз данных и субд
- •1.2. Введение в субд
- •1.2.1. Основные термины, понятия и определения
- •1.2.2. Классификация субд
- •1) Сетевые, корпоративные, распределенные, клиент-серверные, полнофункциональные, масштабируемые, “большие” субд.
- •2) Локальные, персональные, настольные, файл-серверные, “малые” субд.
- •1.3. Модели данных
- •1.3.1. Типы связей между объектами
- •1.3.2. Формы записи инфологической (концептуальной) модели
- •1.3.3. Уровни представления и независимости данных
- •1.3.4. Порядок взаимодействия пользователя, субд и ос
- •1.3.5. Поддержка целостности базы данных
- •1.3.6. Иерархическая модель
- •1.3.7. Сетевая модель
- •1.3.8. Реляционная модель
- •1.3.8.1. Отношения
- •1.3.8.2. Теоретико-множественные операции с отношениями
- •1.3.8.3. Правила Кодда
- •1.3.8.4. Индексирование таблиц
- •1.3.8.5. Связывание таблиц
- •1.3.9. Постреляционная модель
- •1.3.10. Многомерная модель
- •1.3.11. Объектно‑ориентированная модель
- •1.4. Модели использования баз данных в сети
- •1.4.1. Сеть
- •1.4.2. Модели использования баз данных
- •1.4.2.1. Локальная однопользовательская модель
- •1.4.2.2. Файл-серверная модель
- •1.4.2.3. Клиент-серверная модель
- •В моделях «клиент–сервер»
- •1.4.2.4. Модель удаленного доступа (rda)
- •1.4.2.5. Модель сервера данных
- •1.4.2.6. Трехзвенная распределенная модель
- •1.4.2.7. Модели серверов баз данных
- •1.4.2.8. Клиент-Интернет
- •1.4.2.9. ИнтерфейсOdbc
- •1.4.3. Мониторы обработки транзакций (tpm)
- •1.4.4. Децентрализованное управление базами данных
- •1.4.5. Таблицы в локальных сетях
- •1.5. Проектирование баз данных
- •1.5.1. Принципы и этапы проектирования и создания баз данных
- •1.4.Определение доменов атрибутов.
- •1.5. Определение первичных и вторичных ключей.
- •1.6. Определение суперклассов и подклассов для типов сущностей.
- •1.7. Создание er‑диаграмм для отдельных пользователей.
- •2.6. Создание er‑диаграмм для отдельных пользователей.
- •3.4. Создание er‑диаграммы глобальной логической модели.
- •4. Создание глобальной логической модели в среде целевой субд.
- •6. Разработка механизма защиты.
- •1.5.3. Правила формирования взаимосвязанных таблиц
- •1.5.4. Модели жизненного цикла и проектирование баз данных
- •1.5.4.1. Модели жизненного цикла
- •1.5.4.2. Обследование, системный анализ и постановка задачи
- •1.5.4.3. Инфологическое проектирование
- •1.5.4.4. Датологическое проектирование
- •1.5.4.5. Проектирование физической модели
- •1.5.4.6. Реализация, интеграция и внедрение
- •1.5.5. Выбор субд
- •1.5.5.1. Сравнение Visual FoxPro, Access, sql Server, Oracle и Excel
- •1.5.5.2. Методика балловой оценки программных средств
- •1.5.6. Case‑средства автоматизации проектирования
- •1. Ориентация на этапы жизненного цикла
- •2. Функциональная полнота
- •Пользователя в ms sql Server 7.0
- •1.6.2. Резервирование информации
- •1.6.3. Варианты разработки приложений
- •1.7. Стандартизация баз данных
- •1.8. ЯзыкSql
- •1.8.1. Введение вSql
- •1.8.2. Типы данныхSql
- •1.8.3. Оператор выбора данныхSelect
- •1.8.3.1. Назначение и синтаксис оператора
- •1.8.3.2. Объединение таблиц
- •1.8.3.3. Вложенные и коррелированные запросы
- •1.8.3.4. Запросы, использующиеExist, any, all
- •1.8.3.5. Стандартные функции
- •1.8.3.6. Запрос с группировкой
- •1.8.4. Операторы обновления базы
- •1.8.4.1. Оператор корректировки данныхUpdate
- •1.8.4.2. Оператор удаления записейDelete
- •1.8.4.3. Оператор включения записей insert
- •1.8.5. Представления
- •1.9. Транзакции
- •1.9.1. Определение транзакций
- •1.9.2. Организация транзакций
- •1.9.3. Журнал транзакций
- •1.9.4. Журнализация и буферизация
- •1.9.5. Индивидуальный откат транзакций
- •1.9.6. Восстановление после мягкого сбоя
- •1.9.7. Физическая согласованность базы данных
- •1.9.8. Восстановление после жесткого сбоя
- •1.9.9. Параллельное выполнение транзакций
- •1.9.10. Уровни изолированности пользователей
- •1.9.11. Гранулированные синхронизационные захваты
- •1.9.12. Предикатные синхронизационные захваты
- •1.9.13. Метод временных меток
- •1.10. ВстроенныйSql
- •1.10.1. Особенности встроенногоSql
- •1.10.2. Определение курсора
- •1.10.3. Открытие курсора
- •1.10.4. Чтение очередной строки курсора
- •1.10.5. Закрытие курсора
- •1.10.6. Удаление и обновление данных
- •1.10.7. Хранимые процедуры
- •Хранимой процедуры на сервере
- •1.10.8. Триггеры
- •1.10.9. ДинамическийSql
- •1.11. Архитектура субд и оптимизация запросов
- •1.12. Перспективы развития субд
- •Вопросы для самопроверки и контроля
- •1Оглавление
1.8.5. Представления
Представление – это виртуальная таблица,которая сама по себе не существует, но для пользователя выглядит таким образом, как будто она существует. В отличие от запросовSELECT, можно корректировать поля, входящие в представление и использовать их во фразеFROM.
Общий синтаксис предложения CREATE VIEW (создать представление): CREATE VIEW имя–представления [(имя–столбца[ , имя–столбца] . . .)]AS подзапрос [WITH CHECK OPTION];
Подзапрос не может включать ни оператора UNION, ни фразы ORDER BY.
Пример.CREATE VIEW КРАСНЫЕ_ДЕТАЛИ (НОМЕР_ДЕТАЛИ, НАЗВАНИЕ, ВЕС, ГОРОД) AS SELECT НОМЕР_ДЕТАЛИ, НАЗВАНИЕ, ВЕС, ГОРОД FROM P WHERE ЦВЕТ = 'Красный';
Пример. CREATE VIEW PQ (НОМЕР_ДЕТАЛИ, ОБЩЕЕ_КОЛИЧЕСТВО) AS SELECT НОМЕР_ДЕТАЛИ, SUM (КОЛИЧЕСТВО) FROM SP GROUP BY НОМЕР_ДЕТАЛИ;
Пример.
CREATE VIEW ПАРЫ_ГОРОДОВ (ГОРОД_ПОСТАВЩИКА, ГОРОД_ДЕТАЛИ) AS SELECT S.ГОРОД, Р.ГОРОД FROM S, SP, P WHERE S.НОМЕР_ПОСТАВЩИКА =SP.НОМЕР_ПОСТАВЩИКА AND SP.HOMEP_ДЕТАЛИ = Р.НОМЕР_ДЕТАЛИ;
Пример.
CREATE VIEW ЛОНДОНСКИЕ_КРАСНЫЕ_ДЕТАЛИ AS SELECT НОМЕР_ДЕТАЛИ, ВЕС FROM КРАСНЫЕ_ДЕТАЛИ WHERE ГОРОД = 'Лондон';
Пример.
CREATE VIEW ХОРОШИЕ_ПОСТАВЩИКИ AS SELECT НОМЕР_ПОСТАВЩИКА, СОСТОЯНИЕ, ГОРОД FROM S WHERE СОСТОЯНИЕ > 15 WITH CHECK OPTION;
Фраза «WITH CHECK OPTION» (с проверкой) указывает, что для операций UPDATE и INSERT над этим представлением должна осуществляться проверка, которая обеспечивает удовлетворение определяющего представление предиката обновленной или вставляемой строкой (СОСТОЯНИЕ>15).
Предложение DROP VIEW имеет следующий синтаксис:
DROP VIEW имя_представления;
В результате исполнения этого предложения уничтожается специфицированное представление,
Пример. DROP VIEW КРАСНЫЕ_ДЕТАЛИ;
Если уничтожается базовая таблица, то все определенные над нею представления также автоматически уничтожаются.
Сгруппированные представлениясодержат запросы, которые имеют группировку. Сгруппированные представления всегда должны содержать список столбцов. Они могут использовать агрегированные функции в качестве результирующих столбцов, а в дальнейшем это представление может использоваться как виртуальная таблица, например, в других запросах.
Пример. Создадим представление, которое определяет суммарный фон заработной платы и надбавок по каждому подразделению с указанием количества сотрудников, минимальной, максимальной и средней зарплаты и надбавки по подразделению. Такой запрос позволяет сравнить заработную плату и надбавки прямо по всем подразделениям, и он может быть очень эффективно использован администрацией при проведении сравнительного анализа подразделений фирмы.
CREATE VIEW RATE
DEPARTMENT. COUNT(*), SUM(SALARY), SUM(PREMIUM), MAX(SALARY), MIN(SALARY),AVERAGE (SALARY), MAX(PREMIUM), MIN(PREMIUM), AVERAGE (PREMIUM) AS SELECT DEPARTMENT, COUNT(*), SUM(SALARY). SUM(PREMIUM). MAX(SALARY),
MIN(SALARY), AVERAGE (SALARY), MAX(PREMIUM), MIN(PREMIUM),
AVERAGE (PREMIUM) FROM EMPLOYEE GROUP BY DEPARTMENT;
Объеденные представления. Часто представления базируются на многотабличных запросах. Такое использование позволяет упростить разработку пользовательского интерфейса, сохранив при этом корректность схемы базы данных.
Пример. Создать представление, которое содержит список читателей-должников с указанием книг, которые у них на руках, и указанных в базе сроков сдачи этих книг.
CREATE VIEW DEBTORS ISBN, TITLE, NUM_READER, NAME, ADRES, HOME_PHON, WORK_PHON, DATA_OUT AS
SELECT ISBN, TITLE, NUM_READER, NAME, ADRES, HOME_PHON, WORK_PHON, DATA_OUT
FROM BOOKS, EXEMPLAR, READERS
WHERE BOOKS.ISBN = EXEMPLAR.ISBN AND
EXEMPLAR.NUM_READER = READERS.NUM_READER AND
EXEMPLAR.PRESENT = FALSE AND
EXEMPLAR.DATA OUT < GetDate();
Существует ряд ограничений на операции модификации данных, связанные с представлениями.
СУБД может обновлять данные через представления только в том случае, если она может однозначно сопоставить каждой строке представления строку из реальной таблицы базы данных, а для каждого обновляемого столбца представления однозначно определить исходный столбец исходной таблицы базы данных.
Согласно стандарту, представление можно обновлять только в том случае, когда его запрос соответствует следующим требованиям.
В запросе должен отсутствовать предикат DISTINCT.
В предложении FROM должна быть задана только одна таблица, которую можно обновлять, то есть у представления должна быть только одна исходная таблица, а пользователь должен иметь соответствующие права доступа к ней. Если таблица сама является представлением, то она тоже должна удовлетворять данным условиям.
Каждое имя в списке возвращаемых столбцов должно быть ссылкой на простой столбец: в списке не должны содержаться выражения, вычисляемые столбцы или агрегатные функции.
В предложении WHERE не должен стоять вложенный запрос; в нем могут присутствовать только простые условия поиска.
В запросе не должно присутствовать выражение группировки GROUP BY или HAVING.
Однако в ряде коммерческих СУБД эти требования смягчены и операции модификации разрешены для более широкого класса представлений.
Рассмотрим преимущества представлений.
Они обеспечивают определенную степень логической независимости данных, несмотря на реструктуризацию базы данных, как было пояснено в предыдущем разделе.
Они дают возможность различным пользователям по-разному видеть одни и те же данные, возможно, даже в одно и то же время.
Упрощается пользовательское восприятие. Очевидно, что механизм представлений дает возможность пользователям сосредоточить внимание именно на тех данных, которые представляют для них интерес, и игнорировать остальные данные.
Представление может также значительно упростить пользовательские операции манипулирования данными. В частности, поскольку для пользователя может быть предусмотрено представление, в котором все лежащие в его основе таблицы соединены вместе, необходимость явных операций для перехода от одной таблицы к другой может быть значительно уменьшена.
Для скрытых данных автоматически обеспечивается секретность. «Скрытые данные» обозначает здесь данные, невидимые через некоторое заданное представление. Ясно, что такие данные защищены от доступа через это конкретное представление.
Таким образом, принуждение пользователя осуществлять доступ к базе данных через представления является простым, но эффективным механизмом для управления санкционированием доступа.