Понятие представления операции создания представлений

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

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

Оператор определения представления имеет следующий вид:

<создание представлениям:= CREATE VIEW <имя представления> [ (<список столбцов>)] AS <SQL-3anpoc>

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

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

Рассмотрим типичные виды представлений и их назначение.

Горизонтальное представление

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

Например, у нас есть таблица «Сотрудник» (EMPLOYEE) с полями «Табельный номер» (T_NUM), «ФИО» (NAME), «должность»(POSITION), «оклад»(SALARY), «надбав-Ka»(PREMIUM), «отдел» (DEPARTMENT).

Для приложения, с которым работает начальник отдела продаж, будет создано представление

CREATE VIEW SAL_DEPT AS

SELECT * FROM EMPLOYEE WHERE DEPARTMENT= "Отдел продаж"

Вертикальное представление

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

Например, для работника табельной службы, который учитывает присутствие сотрудников на работе, информация об окладе и надбавке должна быть закрыта. Для него можно создать следующее вертикальное представление:

CREATE VIEW TABEL AS

SELECT T_NUM.NAME. POSITION. DEPARTMENT FROM EMPLOYEE

Сгруппированные представления

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

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

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()

Ограничение стандарта SQL1 на обновление представлений

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

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

Согласно стандарту, представление можно обновлять только в том случае, когда его запрос соответствует следующим требованиям:

· В запросе должен отсутствовать предикат DISTINCT, то есть повторяющиеся строки не должны исключаться из таблицы результатов запроса.

· В предложении FROM должна быть задана только одна таблица, которую можно обновлять, то есть у представления должна быть только одна исходная таблица (это горизонтальное или вертикальное представление), а пользователь должен иметь соответствующие права доступа к ней. Если таблица сама является представлением, то она тоже должна удовлетворять данным условиям.

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

· В предложении WHERE не должен стоять вложенный запрос; в нем могут присутствовать только простые условия поиска.

· В запросе не должно присутствовать выражение группировки GROUP BY или HAVING.

· Однако в ряде коммерческих СУБД эти требования смягчены и операции модификации разрешены для более широкого класса представлений.

· Глава 9. Физические модели баз данных

Файловые структуры, используемые для хранения информации в базах данных

Стратегия разрешения коллизий с областью переполнения

Организация стратегии свободного замещения

Вопросы для самостоятельной работы

Индексные файлы

Файлы с плотным индексом, или индексно-прямые файлы

Файлы с неплотным индексом, или индексно-последовательные файлы

Организация индексов в виде B-tree (В-деревьев)

Моделирование отношений «один-ко-многим» на файловых структурах

Инвертированные списки

Модели физической организации данных при бесфайловой организации

Структура хранения данных для MS SQL 6.5

Структуры хранения данных в SQL Server 7.0

Архитектура разделяемой памяти

ГЛАВА 9.

Физические модели баз данных

Физические модели баз данных определяют способы размещения данных в среде хранения и способы доступа к этим данным, которые поддерживаются на физическом уровне. Исторически первыми системами хранения и доступа были файловые структуры и системы управления файлами (СУФ), которые фактически являлись частью операционных систем. СУБД создавала над этими файловыми моделями спою надстройку, которая позволяла организовать всю совокупность файлов таким образом, чтобы она работала как единое целое и получала централизованное управление от СУБД. Однако непосредственный доступ осуществлялся на уровне файловых команд, которые СУБД использовала при манипулировании всеми файлами, составляющими хранимые данные одной или нескольких баз данных.

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