Простые представления

Синтаксичес1сая структура оператора создания представления (в его наиболее простой форме) может рассматриваться как комбинация тех конструкций, которые уже были описаны в этой книге, - простого оператора CREATE, описанного в главе 4, а также оператора SELECT, неоднократно использовавшегося в данной книге:

CREATE VIEW <view name> AS

<SELECT statement>

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

CREATE VIEW [<schema name>].<view name> [(<column name list>)] [WITH [ENCRYPTION] [, SCHEMABINDING] [, VIEW METADATA]] AS

<SELECT statement> WITH CHECK OPTION

В частности, оператор создания чрезвычайно простого представления на основе таблицы базы данньгх Accounting, которая рассматривалась в главе 5, может выглядеть примерно так:

USE Accounting GO

CREATE VIEW CustomerPhoneList vw AS

SELECT CustomerName, Contact, Phone FROM Customers

Выборка данньгх с помощью этого представления может быть выполнена следующим образом:

SELECT * FROM CustomerPhoneList vw

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

SELECT CustomerName, Contact, Phone FROM Customers

Запрос, лежащий в основе представления, по существу является указанием для СУБД SQL Server выполнить выборку всех данных из результирующего набора, полученного после выполнения оператора SELECT CustomerName, Contact, Phone FROM Customers. Таким образом, с помощью представления осуществляется своего рода промежуточная обработка.

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

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

Перейдем к изучению более сложной темы.

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

Более сложные представления

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

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

USE AdventureWorks GO

CREATE VIEW CustomerOrders vw AS

SELECT о.SalesOrderlD, o.OrderDate, od.ProductID, p.Name, od.OrderQty, od.UnitPrice, od.LineTotal

FROM Sales.SalesOrderHeader AS о JOIN Sales.SalesOrderDetail AS od

ON o.SalesOrderlD = od.SalesOrderlD JOIN Production.Product AS p

ON od.ProductID = p.ProductID

Теперь выполним следующий простой оператор SELECT:

SELECT *

FROM CustomerOrders vw

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

SELECT ProductID, OrderQty, LineTotal

FROM CustomerOrders vw

WHERE OrderDate = 5/15/2003

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

791 1 2443.350000

781 1 2071.419600

794 1 2181.562500

798 1 1000.437500

783 1 2049.098200 801 1 1000.437500

784 1 2049.098200 779 1 2071.419600 797 1 1000.437500

(9 row(s) affected)

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

USE AdventureWorks GO

CREATE VIEW YesterdaysCustomerOrders vw AS

SELECT o.SalesOrderlD,

o.OrderDate,

od.ProductID,

p.Name,

od.OrderQty,

od.UnitPrice,

od.LineTotal FROM Sales.SalesOrderHeader AS о JOIN Sales.SalesOrderDetail AS od

ON o.SalesOrderlD = od.SalesOrderlD JOIN Production.Product AS p