Как посмотреть код представления ms sql

Просмотр определения хранимой процедуры

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

Безопасность

Разрешения

Системная хранимая процедура: sp_helptext
Необходимо быть членом роли public. Определения системных объектов видимы для всех. Определения пользовательских объектов видимы владельцу объекта и получателям любого из следующих разрешений: ALTER, CONTROL, TAKE OWNERSHIP и VIEW DEFINITION.

Системная функция: OBJECT_DEFINITION()
Определения системных объектов видимы для всех. Определения пользовательских объектов видимы владельцу объекта и получателям любого из следующих разрешений: ALTER, CONTROL, TAKE OWNERSHIP и VIEW DEFINITION. Эти разрешения неявно предоставляются членам предопределенных ролей базы данных db_owner, db_ddladminи db_securityadmin .

Представление каталога объектов: sys.sql_modules
Видимость метаданных в представлениях каталогов ограничивается защищаемыми объектами, которыми пользователь владеет или на которые ему были предоставлены разрешения. Дополнительные сведения см. в разделе Metadata Visibility Configuration.

Azure Synapse Analytics не поддерживает системную хранимую процедуру sp_helptext . Вместо нее используйте представление каталога объектов sys.sql_modules . Примеры приведены далее в этой статье.

Просмотр определения хранимой процедуры

Можно использовать один из следующих способов:

• Среда SQL Server Management Studio
• Transact-SQL

Использование среды SQL Server Management Studio

Чтобы просмотреть определение процедуры в обозреватель объектов, выполните следующие действия.

1. В обозреватель объектов подключитесь к экземпляру ядро СУБД, а затем разверните этот экземпляр.
2. Последовательно разверните узел Базы данных, базу данных, которой принадлежит процедура, и узел Программирование.
3. Разверните раздел Хранимые процедуры, щелкните процедуру правой кнопкой мыши, нажмите Создать скрипт для хранимой процедуры, а затем выберите один из следующих пунктов: Используя CREATE, Используя ALTER или Используя DROP и CREATE.
4. Выберите New Query Editor Window (Окно редактирования нового запроса). При этом отобразится определение процедуры.

Использование Transact-SQL

Просмотр определения процедуры в редакторе запросов

Системная хранимая процедура: sp_helptext

1. В обозреватель объектов подключитесь к экземпляру ядро СУБД.
2. На панели инструментов нажмите Создать запрос.
3. В окне запроса введите следующую инструкцию, которая использует системную хранимую процедуру sp_helptext . Измените имя базы данных и имя хранимой процедуры для ссылки на нужную базу данных и хранимую процедуру.

USE AdventureWorks2022; GO EXEC sp_helptext N'AdventureWorks2022.dbo.uspLogError'; 

Системная функция: OBJECT_DEFINITION()

1. В обозреватель объектов подключитесь к экземпляру ядро СУБД.
2. На панели инструментов нажмите Создать запрос.
3. В окне запроса введите следующие инструкции, которые используют системную функцию OBJECT_DEFINITION . Измените имя базы данных и имя хранимой процедуры для ссылки на нужную базу данных и хранимую процедуру.

USE AdventureWorks2022; GO SELECT OBJECT_DEFINITION (OBJECT_ID(N'AdventureWorks2022.dbo.uspLogError')); 

Представление каталога объектов: sys.sql_modules

1. В обозреватель объектов подключитесь к экземпляру ядро СУБД.
2. На панели инструментов нажмите Создать запрос.
3. В окне запроса введите следующие инструкции, которые используют представление каталогов sys.sql_modules . Измените имя базы данных и имя хранимой процедуры для ссылки на нужную базу данных и хранимую процедуру.

USE AdventureWorks2022; GO SELECT [definition] FROM sys.sql_modules WHERE object_id = (OBJECT_ID(N'dbo.uspLogError')); 

См. также

• Создание хранимой процедуры
• Изменение хранимой процедуры
• Удаление хранимой процедуры
• Изменение имени хранимой процедуры
• OBJECT_DEFINITION (Transact-SQL)
• sys.sql_modules (Transact-SQL)
• sp_helptext (Transact-SQL)
• OBJECT_ID (Transact-SQL)

Представление (VIEW) в T-SQL – описание и примеры использования

Приветствую всех посетителей сайта Info-Comp.ru! Сегодня мы с Вами поговорим о таких объектах Microsoft SQL Server, как «Представления», Вы узнаете, что это за объекты, для чего они нужны, а также как создавать, изменять и удалять представления на языке T-SQL.

Представление (VIEW) в Microsoft SQL Server

Представление (VIEW) – это объект базы данных Microsoft SQL Server, который хранит в себе запрос SELECT и в случае обращения к данному объекту будет возвращен результирующий набор данных, который формирует запрос, указанный в определении представления.

Иными словами, это виртуальная (логическая) таблица, она не содержит в себе данных, но к ней можно обращаться как к обычной таблице, и она будет возвращать Вам данные. Обычно такой объект называют «Вьюха».

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

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

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

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

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

Какие бывают представления

• Пользовательские – это те, которые мы сами создаем;
• Системные – это представления, которые уже есть в SQL сервере. Они возвращают нам системную информацию.

Работа с представлениями на T-SQL

Исходные данные

Сначала нам необходимо создать тестовые данные для наших примеров.

Допустим, у нас будет таблица Goods, которая хранит некую информацию о товарах, и таблица Categories, которая хранит данные о категориях товара.

--Создание таблицы CREATE TABLE Goods ( ProductId INT IDENTITY(1,1) NOT NULL, Category INT NOT NULL, ProductName VARCHAR(100) NOT NULL, Price MONEY NULL, ); --Добавление данных в таблицу INSERT INTO Goods(Category, ProductName, Price) VALUES (1, 'Клавиатура', 30), (1, 'Монитор', 100), (2, 'Смартфон', 200); --Создание таблицы с категориями CREATE TABLE Categories ( CategoryId INT IDENTITY(1,1) NOT NULL, CategoryName VARCHAR(100) NOT NULL ); --Добавление данных в таблицу с категориями INSERT INTO Categories VALUES ('Комплектующие компьютера'), ('Мобильные устройства'); SELECT * FROM Goods; SELECT * FROM Categories;

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

Создание представлений

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

Создается представление с помощью инструкции CREATE VIEW.

Для решения нашей задачи мы можем создать следующее представление.

CREATE VIEW CountProducts AS SELECT C.CategoryName AS CategoryName, COUNT(*) AS CntProducts FROM Goods G INNER JOIN Categories C ON Category = C.CategoryId GROUP BY C.CategoryName;

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

Примечание! В представлении нельзя использовать секцию ORDER BY, т.е. сортировку, в случае необходимости, отсортировать данные Вы можете, когда будете обращаться к этому представлению. Использование ORDER BY возможно, только если указан оператор TOP.

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

SELECT * FROM CountProducts;

Изменение представлений

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

ALTER VIEW CountProducts AS SELECT C.CategoryId, C.CategoryName AS CategoryName, COUNT(*) AS CntProducts FROM Goods G INNER JOIN Categories C ON Category = C.CategoryId GROUP BY C.CategoryId, C.CategoryName; GO SELECT * FROM CountProducts;

В данном случае мы написали инструкцию ALTER VIEW, которая говорит SQL серверу, что мы хотим изменить существующий объект, затем указали название представления, чтобы сервер мог определить, какое именно представление мы хотим изменить, после ключевого слова AS мы указали новое определение представления, т.е. измененный запрос SELECT.

Чтобы отделить инструкцию изменения представления от SQL запроса на выборку, мы написали команду GO.

Удаление представлений

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

DROP VIEW CountProducts;

Теперь данного представления больше нет, и к нему Вы больше обратиться не сможете.

Обновляемые представления в Microsoft SQL Server

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

• Любое изменение (UPDATE, INSERT или DELETE) должно касаться столбцов только одной базовой таблицы;
• Столбцы, данные которых Вы хотите изменить, должны напрямую ссылаться на столбцы базовой таблицы, иными словами, нельзя внести изменения в столбцы, которые были сформированы в представлении, например, агрегатной функцией или другими вычислениями.

Допустим, у нас есть представление, которое возвращает список товаров. Для примера мы его назвали GoodsUpdate.

CREATE VIEW GoodsUpdate AS SELECT ProductId, Category, ProductName, Price FROM Goods; GO

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

SELECT * FROM GoodsUpdate; GO UPDATE GoodsUpdate SET Price = Price + 10 WHERE Category = 2; GO SELECT * FROM GoodsUpdate;

Мы видим, что данные успешно изменены.

Заметка! Для комплексного изучения языка SQL и T-SQL рекомендую пройти онлайн-курсы по T-SQL, на которых используется последовательная методика обучения и рассматриваются все объекты SQL Server и конструкции языка T-SQL.

На сегодня это все, надеюсь, материал был Вам интересен и полезен, до новых встреч!

Представления в SQL

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

Общее понятие

Итак, представления в SQL являются особым объектом, который содержит данные, полученные запросом SELECT из обычных таблиц. Это виртуальная таблица, к которой можно обратиться как к обычным таблицам и получить хранимые данные. Представление в SQL может содержать в себе как данные из одной единственной таблицы, так и из нескольких таблиц. Представления нужны для того, чтобы упростить работу с базой данных и ускорить время ответа сервера. Так как представление — это уже результат некой выборки данных с помощью SELECT, то, очевидно, в следующий раз вместо запроса к нескольким таблицам достаточно просто обратиться к уже созданному представлению. Работу этого объекта характеризует следующее изображение:
На изображении — простой вариант использования представления, когда объединяются данные по идентификатору. Но, помимо этого, в представлениях могут быть разные виды условий и ограничений, также вложенные запросы и группировки по каким либо полям. Об этом будет сказано чуть позже.

Создание представления в SQL

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

CREATE VIEW name_view as 

Где name_view — имя, которое задает пользователь при создании. После ключевого слова as идет код запроса SELECT, данные которого и поместятся в представление. Чтобы легче понять разберем простой пример, иллюстрация которого была представлена выше.

CREATE VIEW info_order AS SELECT onum, amt, cname FROM orders, customers WHERE orders.cnum = customers.cnum

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

Обращение к представлениям в SQL

Чтобы посмотреть данные из представления следует воспользоваться теми командами, которые были изучены в предыдущих уроках — например по оператору SELECT в SQL.

SELECT * FROM info_order

Помимо простого SELECT, в SQL к представлениям можно обращаться с различными условиями WHERE, как к обычным таблицам. Также можно использовать данные из этого представления, чтобы сформировать новое представление — хотя это и редко используется, тем не менее, в SQL есть такая возможность.

Примеры представлений

Рассмотрим такую задачу:

Создайте представление Cust_Rating_Max, которое бы показывало всех покупателей и их город, которые имеют самые высокие рейтинги.

Хорошей практикой является решение задачи запроса SELECT, а затем уже создание самого представления. То есть сначала лучше написать запрос, который вернет на экран то, что нужно. Затем создать представление. Вот итоговый код решения этой задачи:

CREATE VIEW Cust_Rating_Max as SELECT cname, city, rating FROM customers WHERE rating = (SELECT Max(rating) FROM customers)

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

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

Нужно сделать группировку по имени продавца и следующий код нам в этом поможет:

CREATE VIEW Sale_Amt_Avg as SELECT sname, AVG(amt) FROM salespeople, orders WHERE salespeople.snum = orders.snum GROUP BY sname

По сути для каждого продавца рассчитывается среднее значение сумм его продаж и заносится в представление.

Это выделено в отдельный пункт, так как не все СУБД SQL поддерживают представления с сортировкой, но мы рассмотрим такую задачу:

Создайте представление Orders_All, которое бы показывало данные о заказах: сумму, дату, фамилию покупателя и продавца. Отсортировать по сумме заказа.

CREATE VIEW Orders_All as SELECT amt, odate, customers.cname, salespeople.sname FROM orders, customers, salespeople WHERE orders.cnum = customers.cnum and orders.snum = salespeople.snum ORDER BY amt

В этом запросе по сути создается представление, которое дублирует таблицу orders, и заменяет в ней идентификаторы на фамилии. Также происходит сортировка по сумме заказа.

На этом с практикой мы закончим и еще немного поговорим о теории представлений.

Понятие модифицируемого представления в SQL

Итак, в SQL есть такое понятие как модифицируемого представление — это означает, что при изменении данных в самом представлении, эти данные изменятся и в таблицах, которые эти данные хранят. То есть при использовании оператора UPDATE/INSERT/DELETE к представлению, данные обновятся и в таблицах.

Очевидно, что не все представления являются такими и на самом деле большая часть является немодифицируемыми. По причине неоднозначности: например в представлении хранятся данные из двух таблиц. Пользователь удаляет одну строку в представлении, и тут возникает вопрос — удалять ли исходные данные в таблицах, а если и удалять, то сразу из двух или только одной… В этом и состоит неоднозначность.

Поэтому выделили специальные критерии по которым можно определенно сказать — является ли представление SQL модифицируемым. Эти критерии вы можете найти по этой ссылке — тут статья на очень полезном ресурсе по SQL языку.

Заключение

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

Поделиться ссылкой:

3.1. Представления View

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

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

Для чего создаются вьюшки? Можно выделить следующие назначения:

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

3.1.1. Создание вьюшки

Для создания вью используется оператор CREATE VIEW, который в общем виде выглядит следующим образом:

CREATE VIEW [ < database_name >. ] [ < owner >. ] view_name [ ( column [ . n ] ) ] [ WITH < view_attribute >[ . n ] ] AS select_statement [ WITH CHECK OPTION ] < view_attribute >::=

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

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

CREATE VIEW PhoneView AS SELECT pl.vcFamil, pl.vcName, pl.vcSurName, dDateBirthDay, vcPhoneNumber FROM tbPeoples pl, tbPhoneNumbers pn WHERE pn.idPeoples=*pl.idPeoples

Как теперь можно использовать эту вьюшку? Точно так же, как и таблицу, то есть выполнять запрос SELECT:

SELECT * FROM PhoneView

Результат выполнения запроса:

vcFamil vcName vcSurName dDateBirthDay vcPhoneNumber ------------------------------------------------------------------- mr.ИВАНОВ ИВАН ИВАНЫЧ 2004-01-31 (925) 102-51-01 mr.ИВАНОВ ИВАН ИВАНЫЧ 2004-01-31 (925) 163-31-52 mr.ПЕТРОВ ИВАН ПАЛЫЧ 1971-04-03 (923) 112-02-46 mr.СИДОРОВ ИВАН ПАЛЫЧ 1967-12-13 (923) 152-52-04 mr.СИДОРОВ ИВАН ПАЛЫЧ 1967-12-13 (095) 125-16-63 mr.КОНОНОВ ШВАРЦ ПЕТРОВИЧ 1981-12-13 (905) 100-10-10 . (33 row(s) affected)

Вью предоставляет несколько преимуществ:

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

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

Вьюшки позволяют вам хранить результат комплексного запроса. Другие запросы могут использовать этот суммирующий результат.

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

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

CREATE VIEW Зарплата AS SELECT разрешенные для налоговой поля FROM Работники, Доходы WHERE навести связи

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

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

Когда мы ограничиваем доступ к определенным полям, то такая защита называется вертикальной. Объекты просмотра позволяют создавать и горизонтальную защиту. Например, в таблице есть определенные пользователи, которые должны быть видны только привилегированным пользователям. У таких пользователей в поле «Категория» стоит значение 1. Если запретить прямой доступ к таблице, а для всех пользователей создать вьюшку, то можно скрыть записи. Вьюшка может выглядеть следующим образом:

CREATE VIEW Зарплата AS SELECT Список полей FROM Работники, Доходы WHERE навести связи AND Категория=1

В этом примере мы ограничиваем доступ к определенным записям, а не полям и такая защита называется горизонтальной.

Конечно же, вы можете создать и горизонтальную защиту и вертикальную в одном объекте просмотра. Этого нам никто запретить не может.

С помощью разных вьюшек к одним и тем же таблицам экономисты могут видеть одни данные, бухгалтерия другие, а отдел кадров третьи. Если нужно показать какую-то дополнительную колонку, то просто добавляем в запрос вьюшки и все. Никаких прав изменять уже не надо будет.

В каждой базе данных могут быть системные вьюшки, которые создаются сервером автоматически. Не советую разрешать к ним доступ, потому что они могут показать что-нибудь лишнее, что поможет хакеру поднять свои права или просто испортить данные. Системные вьюшки начинаются с префикса sys и в колонке Type списка светиться надпись System (если просматривать хранимые на сервере вью с помощью программы Enterprise Manager).

Когда вы создаете вью, SQL Server проверяет существование объектов, на которые ссылаются в объявлении вью. Ваше имя вью должно соответствовать правилам именования объектов базы данных. Вы должны именовать вьюшки так, чтобы их имена отличались от имен таблиц, и их можно было выделить среди других объектов. Это значит, что имя вью не должно конфликтовать не только с существующими объектами просмотра (View), но и с именами таблиц базы данных. Если бы можно было создать просмотр с именем tbPeoples, то следующим запрос не смог бы определить, откуда выбирать данные – из вью или из таблицы с таким именем:

SELECT FROM tbPeoples

Для выполнения оператора CREATE VIEW, вы должны иметь соответствующие права, например, быть владельцем базы данных. Вы также должны иметь права на выполнение оператора SELECT всех таблиц, используемых в вью. Чтобы избежать ситуации, когда владельцем вью является один человек, а владельцем таблиц другой, всеми объектами должен владеть dbo. Всегда указывайте имя dbo при создании объектов. Например, в следующем примере показано, как PhoneView, который мы рассматривали ранее в этой главе, с явным указанием владельца (dbo):

CREATE VIEW dbo.PhoneView AS SELECT pl.vcFamil, pl.vcName, pl.vcSurName, dDateBirthDay, vcPhoneNumber FROM tbPeoples pl, tbPhoneNumbers pn WHERE pn.idPeoples=*pl.idPeoples

Все поля вью должны иметь имена, и они должны быть уникальными. Поэтому, необходимо во время выполнения оператора CREATE VIEW учитывать следующие особенности:

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

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

CREATE VIEW NamesView AS SELECT pl.vcName, count(*) FROM tbPeoples pl GROUP BY vcName

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

CREATE VIEW NamesView AS SELECT pl.vcName, count(*) AS Количество FROM tbPeoples pl GROUP BY vcName

Есть еще один способ задания полей для View – в скобках после имени вьюшки:

CREATE VIEW NamesView1(Имя, Количество) AS SELECT pl.vcName, count(*) FROM tbPeoples pl GROUP BY vcName

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

Имя Количество ------------------------------------ АНДРЕЙ 5 БОЛИК 1 ВАСЯ 1 ВИКТОР 1 ВИТЯ 1 .

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

SELECT pl.vcFamil, pl.vcName, pl.vcSurName, dDateBirthDay, vcPhoneNumber, pl.idPeoples, pn.idPeoples FROM tbPeoples pl, tbPhoneNumbers pn WHERE pn.idPeoples=*pl.idPeoples

В секции SELECT поле «idPeoples» выбирается из таблицы работников и из таблицы телефонов. Если смотреть на этот код как запрос, то ошибки нет, и он выполнится. Но если попытаться создать вью:

CREATE VIEW ConflictView AS SELECT pl.vcFamil, pl.vcName, pl.vcSurName, dDateBirthDay, vcPhoneNumber, pl.idPeoples, pn.idPeoples FROM tbPeoples pl, tbPhoneNumbers pn WHERE pn.idPeoples=*pl.idPeoples

В ответ на это мы тут же увидим ошибку. Сервер сообщит нам о том, что поля вьюшки должны быть уникальными. Проблема опять же решается с помощью задания одному из конфликтующих полей псевдонима с уникальным именем. Например, в следующем запросе полю «idPeoples» из таблицы tbPhoneNumbers задается псевдоним PhoneNumbersID:

CREATE VIEW ConflictView AS SELECT pl.vcFamil, pl.vcName, pl.vcSurName, dDateBirthDay, vcPhoneNumber, pl.idPeoples, pn.idPeoples AS PhoneNumbersID FROM tbPeoples pl, tbPhoneNumbers pn WHERE pn.idPeoples=*pl.idPeoples

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

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

• нельзя использовать ключевое слово INTO;
• нельзя использовать опции COMPUTE или COMPUTE BY;
• можно использовать оператор ORDER BY только если используется ключевое слово TOP;
• вью не может ссылаться на временные таблицы;
• вью, как и таблица не может содержать более чем 1024 колонки.

3.1.2. Редактирование вью

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

Оператор ALTER VIEW изменяет объявление вью. Это позволяет вам сохранить разрешения. В общем виде команда выглядит следующим образом:

ALTER VIEW [ < database_name >. ] [ < owner >. ] view_name [ ( column [ . n ] ) ] [ WITH < view_attribute >[ . n ] ] AS select_statement [ WITH CHECK OPTION ]

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

ALTER VIEW PhoneView AS SELECT vcFamil, vcName, vcSurname, vcPositionName, vcPhoneNumber, pn.idPeoples FROM tbPeoples pl, tbPosition ps, tbPhoneNumbers pn WHERE pl.idPosition=ps.idPosition AND pl.idPeoples=pn.idPeoples

Как видите, изменение происходит также, как и создание объекта просмотра.

3.1.3. Удаление вью

Если вам больше не нужен объект просмотра, то его следует удалить. Ничего лишнего в базе данных не должно быть, ведь не используемые объекты отрицательно влияют на безопасность. Для удаления используется оператор DROP VIEW.

DROP VIEW < view >[ . n ]

Можно удалять сразу несколько объектов просмотра. Следующий пример удаляет сразу три объекта:

DROP VIEW NamesView, NamesView1, ConflictView

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

3.1.4. Изменение содержимого вью

Я уже говорил о том, что с объектом просмотра можно работать также как и с простой таблицей. Это значит, что возвращаемый результат можно воспринимать как таблице и редактировать. Давайте попробуем изменить в вьюшке PhoneView фамилию работника с идентификатором 1 на Печкина:

UPDATE PhoneView SET vcFamil='ПОЧЕЧКИН' WHERE idPeoples=1

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

UPDATE PhoneView SET vcPositionName='Самый генеральный директор' WHERE vcPositionName='Генеральный директор'

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

Объект просмотра PhoneView выводит результат из трех таблиц сразу. А что, если мы хотим изменить поля из нескольких таблиц одновременно? Давайте попробуем выполнить следующий запрос:

UPDATE PhoneView SET vcFamil='ПОЧЕЧКИН', vcPositionName='Самый генеральный директор' WHERE idPeoples=1

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

3.1.5. Удаление строк из вью

Попробуем удалить запись из вьюшки PhoneView:

DELETE FROM PhoneView WHERE idPeoples=1

Результатом снова будет ошибка, потому что во время удаления, будет производиться попытка удалить полученные записи из связанных таблиц. Получается, что нельзя удалять строки из объектов просмотра, если выбираются строки из нескольких таблиц. А если выбрать из нескольких?

Давайте создадим вьюшку, которая будет выбирать записи только из одной таблицы:

CREATE VIEW PhoneView1 AS SELECT pl.vcFamil, pl.vcName, pl.vcSurName FROM tbPeoples pl

Теперь попробуем удалить запись:

DELETE FROM PhoneView1 WHERE vcFamil='КОТИКОВ'

На этот раз все пройдет успешно, и запись будет удалена, потому что объект просмотра использует поля только одной таблицы.

3.1.6. Опции объекта просмотра

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

Давайте создадим объект просмотра, данные которого (исходный код) будут зашифрованными в системной таблице:

CREATE VIEW PhoneView1 WITH ENCRYPTION AS SELECT pl.vcFamil, pl.vcName, pl.vcSurName FROM tbPeoples pl

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