Мартин Грубер - Понимание SQL
- Название:Понимание SQL
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Мартин Грубер - Понимание SQL краткое содержание
Данная книга является очень хорошим введением в теорию реляционных БД для пользователей-новичков, а также хорошим началом в освоении SQL, грамотном построение запросов, понимании того как эти запросы работают. Безусловно рекомендуется к прочтению для начинающих пользователей.
Понимание SQL - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
SELECT *
FROM Nameorders
WHERE sname='Rifkin';
SELECT * FROM Nameorders WHERE sname='Rifkin';
onum |
amt |
snum |
sname |
cname |
3001 |
18.69 |
1007 |
Rifkin |
Cisneros |
3006 |
1098.16 |
1007 |
Rifkin |
Cisneros |
Таблица 20.3: Порядки Rifkin показаные в Nameorders
Вы можете также объединять представления с другими таблицами, или базовыми таблицами или представлениями, поэтому вы можете увидеть все порядки Axelrodа и значения его комиссиионных в каждом порядке:
SELECT a.sname, cname, amt comm
FROM Nameorders a, Salespeople b
WHERE a.sname='Axelrod'
AND b.snum=a.snum;
Вывод для этого запроса показывается в Таблице 20.4.
В предикате, мы могли бы написать - " WHERE a.sname=|Axelrod' AND b.sname=|Axelrod| ", но предикат который мы использовали здесь более общеупотребительный. Кроме того поле snum - это первичный ключ таблицы Продавцов, и следовательно должен по определению быть уникальным.
SELECT a.sname, cname, amt * comm FROM Nameorders a, Salespeople b
WHERE a.sname='Axelrod' AND b.snum=a.snum;
onum |
amt |
snum |
sname |
cname |
3001 |
18.69 |
1007 |
Rifkin |
Cisneros |
3006 |
1098.16 |
1007 |
Rifkin |
Cisneros |
Таблица 20. 4: Обьединение основной таблицы с представлением
Если бы там например было два Axelrodf, вариант с именем, будет обединять вместе их данные. Более предпочтительный вариант - использовать поле snum чтобы хранить его отдельно.
Представления могут также использовать и подзапросы, включая соотнесенные подзапросы. Предположим ваша компания предусматривает премию для тех продавцов которые имеют заказчика с самым высоким порядком для любой указанной даты. Вы можете проследить эту информацию с помощью представления:
CREATE VIEW Elitesalesforce
AS SELECT b.odate, a.snum, a.sname,
FROM Salespeople a, Orders b
WHERE a.snum=b.snum
AND b.amt=
(SELECT MAX (amt)
FROM Orders c
WHERE c.odate=b.odate);
Если, с другой стороны, премия будет назначаться только продавцу который имел самый высокий порядок за последние десять лет, вам необходимо будет проследить их в другом представлении основанном на первом:
CREATE VIEW Bonus
AS SELECT DISTINCT snum, sname
FROM Elitesalesforce a
WHERE 10 <=
(SELECT COUNT (*)
FROM Elitesalestorce b
WHERE a.snum=b.snum);
Извлечение из этой таблицы продавца, который будет получать премию - выпоняется простым вопросом:
SELECT *
FROM Bonus;
Теперь мы видим истинную мощность SQL. Извлечение той же полученной информации программами RPG или COBOL будет более длительной процедурой. В SQL, это - только вопрос из двух комплексных команд, сохраненных, как представление совместно с простым запросом. При самостоятельном запросе - мы должны заботится об этом каждый день, потому что информация которую извлекает запрос, непрерывно меняется чтобы отражать текущее состояние базы данных.
Имеются большое количество типов представлений (включая многие из наших примеров в этой главе ) которые являются доступными только для чтения. Это означает, что их можно запрашивать, но они не могут подвергаться действиям команд модификации. (Мы будем рассматривать эту тему в Главе 21.)
Имеются также некоторые виды запросов, которые не допустимы в определениях представлений. Одиночное представление должно основываться на одиночном запросе; ОБЪЕДИНЕНИЕ (UNION) и ОБЪЕДИНЕНИЕ ВСЕГО (UNIOM ALL) не разрешаются. УПОРЯДОЧЕНИЕ ПО(ORDER BY) никогда не используется в определении представлений. Вывод запроса формирует содержание представления, которое напоминает базовую таблицу и является - по определению - неупорядоченным.
Синтаксис удаления представления из базы данных подобен синтаксису удаления базовых таблиц:
DROP VIEW < view name >
В этом нет необходимости, однако, сначала надо удалить все содержание как это делается с базовой таблицей, потому что содержание представления не является созданым и сохраняется в течении определеной команды. Базовая таблица из которой представление выводится, не эффективна когда представление удалено. Помните, вы должны являться владельцем представления чтобы иметь возможность удалить его.
Теперь, когда вы можете использовать представления, ваша способность отслеживать и обрабатывать содержание вашей базы данных, значительно расширилась. Любые вещи которые вы можете создать с запросом, вы всегда сможете определить как представление. Запросы этих представлений, фактически, запрос запроса. Использование представлений и для удобства и для защиты, также удобно как и многие возможности представлений для форматирования и получения значений из постоянно меняющегося содержания вашей базы данных. Имеется один главный вывод относительно представлений, это способность к модификации, которую мы выбрали в отличии от Главы 21. Как показано, вы можете модифицировать представления также как и базовую таблицу, с помощью изменений применяемых к таблице из которой получается представление, но это не всегда возможно.
* Создайте представление которое бы показывало всех заказчиков которые имеют самые высокие оценки.
* Создайте представление которое бы показывало номер продавца в каждом городе.
* Создайте представление которое бы показывало усредненый и общий порядки для каждого продавца после его имени. Предполагается, что все имена - уникальны.
* Создайте представление которое бы показывало каждого продавца с многочислеными заказчиками.
Глава 21. ИЗМЕНЕНИЕ ЗНАЧЕНИЙ С ПОМОЩЬЮ ПРЕДСТАВЛЕНИЙ
ЭТА ГЛАВА РАССКАЗЫВАЕТ О КОМАНДАХ МОДИФИКАЦИИ ЯЗЫКА DML - ВСТАВИТЬ(INSERT), ИЗМЕНИТЬ(UPDATE), и УДАЛИТЬ(DELETE) - когда они применя ются для представлений. Как упомянуто в предыдущей главе, использование команд модификации в представлениях - это косвенный способ использования их в ссылочных таблицах с помощью запросов представлений. Однако, не все представления могут модифицироваться.
В этой главе, мы будем обсуждать правила определяющие, является ли представление модифицируемым. Кроме того, вы обучитесь использованию предложения WITH CHECK OPTION, которое управляет указанными значениями, которые можно вводить в таблицу с помощью представления.
Как упомянуто в Главе 18, это, в некоторых случаях, может быть желательным вариантом непосредственного ограничения таблицы.
Один из наиболее трудных и неоднозначных аспектов представлений - непосредственное их использование с командами модификации DML. Как упомянуто в предыдущей главе, эти команды фактически воздействуют на значения в базовой таблице представления. Это является некоторым противоречием. Представление состоит из результатов запроса, и когда вы модифицируете представление, вы модифицируете набор результатов запроса. Но модификация не должна воздействовать на запрос ; она должна воздействовать на значения в таблице к которой был сделан запрос, и таким образом изменять вывод запроса. Это не простой вопрос. Следующий оператор будет создавать представление показанное в Таблице 21.1:
Читать дальшеИнтервал:
Закладка: