СКБД - все лк
.pdfЕсли сразу после запуска сервера база данных Tempdb начинает быстро расти, это явный признак того, что необходимо увеличить первоначальный размер, а возможно, и шаг приращения.
Файлы базы данных (Tempdb.mdf) и журнала транзакций (Templog.ldf) хранятся в каталоге \Data.
Системная база данных Model
Создание новых баз данных на сервере выполняется путем копирования системной базы данных Model. Все содержимое этой базы данных и все параметры ее конфигурации полностью переносятся в новую базу независимо от метода создания. Неважно, используется для создания базы данных Enterprise Manager или команда Transact-SQL -- набор и последовательность выполняемых действий будут одинаковы. Это позволяет более эффективно организовать работу администратора баз данных, когда приходится создавать множество похожих баз данных. К тому же, если внутри предприятия необходимо поддерживать стандарт для баз данных, можно реализовать его в виде таблиц, хранимых процедур, пользователей, ролей и других объектов и сохранить их в базе данных Model. В результате все создаваемые базы данных будут иметь одинаковый набор стандартных объектов.
СУБД для специальности СП, III курс
Лекция №4
Представления
Представление (VIEW)- объект данных, который не содержит никаких данных его владельца. Этотип таблицы, чье содержание выбирается из других таблиц с помощью выполнения запроса. Поскольку значения в этих таблицах меняются, то автоматически, их значения могут быть показаны представлением.
Типы таблиц, с которыми имели дело до сих пор, будем называть - базовыми таблицами. Этотаблицы, которые содержат данные. Представления работают в запросах и операторах DML точно также как и основные таблицы. Представлениеэто фактически запрос, который выполняется всякий раз, когда представление становится активным.
Команда CREATE VIEW
Представление создается командой CREATE VIEW. Она состоит из слов CREATE VIEW (Создать представление), имени представления которое нужно создать, слова AS (Как), и далее запроса, как в следующем примере:
иногда вам нужно снабжать ваши столбцы новыми именами:
когда некоторые столбцы являются выводимыми, и поэтому не имеющими имен.
когда два или более столбцов в объединении, имеют те же имена что в их базовой таблице.
Имена, которые могут стать именами полей, даются в круглых скобках ( ), после имени представления.
CREATE VIEW Londonstaff (имена полей) AS SELECT *
FROM Salespeople WHERE city = "London";
Представление может теперь изменяться командами модификации DML, но модификация не будет воздействовать на само представление. Команды будут на самом деле перенаправлены к базовой таблице:
UPDATE Salesown SET city = "Palo Alto" WHERE snum = 1004;
Его действие идентично выполнению той же команды в таблице Продавцов. Однако если значение комиссионных продавца будет обработано командой UPDATE
UPDATE Salesown SET comm = .20 WHERE snum = 1004;
она будет отвергнута, так как поле comm отсутствует в представлении Salesown. Это важное замечание, показывающее, что не все представления могут быть модифицированы.
Виды представлений
Представления могут быть трех видов:
-горизонтальные;
-вертикальные;
-смешанные.
Горизонтальные – это представления, которые ограничивают доступ к некоторым столбцам исходной таблицы и разрешают просматривать все строки.
SELECT city, snum FROM Salespeople;
Вертикальные – это представления, которые ограничивают доступ к некоторым строкам исходной таблицы и разрешают просмотр всех столбцов.
SELECT * FROM Salespeople
WHERE city = "London";
Смешанное – это представление, которое ограничивает доступ, как к некоторым столбцам исходной таблицы, так и к некоторым строкам.
SELECT city, snum FROM Salespeople WHERE city = "London";
Удаление представлений
Синтаксис удаления представления из базы данных подобен синтаксису удаления базовых таблиц:
DROP VIEW <view name>
Определение модифицируемости представления
Если команды модификации могут выполняться в представлении, представление будет модифицируемым; в противном случае оно предназначено только для чтения при запросе. Выражение "модифицируемое представление" (updating a view), означает возможность выполнения в представлении любой из трех команд модификации DML (Вставить, Изменить и Удалить), которые могут изменять значения.
Использование этого принципа на практике, однако, затруднено. Кроме того, некоторые представления, которые являются модифицируемыми в теории, на самом деле не являются модифицируемыми в SQL. Критерии, по которые определяют, является ли представление модифицируемым или нет, в SQL, следующие:
Оно должно выводиться в одну и только в одну базовую таблицу.
Оно должно содержать первичный ключ этой таблицы (это технически не предписывается стандартом ANSI, но было бы неплохо придерживаться этого).
Оно не должно иметь никаких полей, которые бы являлись агрегатными функциями.
Оно не должно содержать DISTINCT в своем определении.
Оно не должно использовать GROUP BY или HAVING в своем определении.
Оно не должно использовать подзапросы (это - ANSI ограничение которое не предписано для некоторых реализаций)
Оно может быть использовано в другом представлении, но это представление должно также быть модифицируемыми.
Оно не должно использовать константы, строки, или выражения значений (например: comm * 100) среди выбранных полей вывода.
Оно на должно содержать операторов Объединения (UNION) и Объединения всего (UNIOM ALL).
Для INSERT, оно должно содержать любые поля основной таблицы, которые имеют ограничение NOT NULL, если другое ограничение по умолчанию, не определено.
Упорядочение по (ORDER BY) никогда не используется в определении представлений.
Проверка значений помещаемых в представление
Другой вывод о модифицируемости представления тот, что вы можете вводить значения которые "проглатываются" (swallowed) в базовой таблице. Рассмотрим такое представление:
CREATE VIEW Highratings AS SELECT cnum, rating FROM Customers
WHERE rating = 300;
Этопредставление модифицируемое. Оно просто ограничивает ваш доступ к определенным строкам и столбцам в таблице. Предположим, что вы вставляете (INSERT) следующую строку:
INSERT INTO Highratings
VALUES (2018, 200);
Это - допустима команда INSERT в этом представлении. Строка будет вставлена, с помощью представления Highratings, в таблицу Заказчиков. Однако когда она появится там, она исчезнет из представления, поскольку значение оценки не равно 300. Это - обычна проблема.
СУБД для специальности СП, III курс
Лекция №5
Определение триггера в стандарте языка SQL
Триггер – это откомпилированная SQL-процедура, исполнение которой обусловлено наступлением определенных событий внутри базы данных.
Триггеры – особый инструмент SQL-сервера, используемый для поддержания целостности данных.
(С помощью ограничений целостности, правил и значений по умолчанию не всегда можно добиться нужного уровня функциональности).
Устно. Часто требуется реализовать сложные алгоритмы проверки данных, гарантирующие их достоверность и реальность. Кроме того, иногда необходимо отслеживать изменения значений таблицы, чтобы нужным образом изменить связанные данные. Триггеры можно рассматривать как своего рода фильтры, вступающие в действие после выполнения всех операций в соответствии с правилами, стандартными значениями и т.д.
Триггер представляет собой специальный тип процедур, запускаемых сервером автоматически при попытке изменения данных в таблицах, с которыми триггеры связаны. Каждый триггер привязывается к конкретной таблице. В случае обнаружения ошибки или нарушения целостности данных происходит отмена всех сделанных изменений.
Спомощью триггеров достигаются следующие цели:
проверка корректности введенных данных и выполнение сложных (дополнительных) ограничений целостности данных (которые трудно, если вообще возможно, поддерживать с помощью ограничений целостности, установленных для таблицы);
выдача предупреждений (напоминающих о необходимости выполнения некоторых действий при обновлении таблицы, реализованном определенным образом);
накопление аудиторской информации (посредством фиксации сведений о внесенных изменениях и тех лицах, которые их выполнили);
поддержка репликации.
Недостатки использования триггеров:
сложность: при перемещении некоторых функций в базу данных усложняются задачи ее проектирования, реализации и администрирования;
скрытая функциональность: перенос части функций в базу данных и сохранение их в виде одного или нескольких триггеров может привести к скрытию от пользователя некоторых функциональных возможностей. (Хотя это в определенной степени упрощает его работу, но может стать причиной незапланированных, потенциально нежелательных побочных эффектов, поскольку в этом случае пользователь не в состоянии контролировать все процессы, происходящие в базе данных);
влияние на производительность: перед выполнением каждой команды по изменению состояния базы данных СУБД должна проверить триггерное условие с целью выяснения необходимости запуска триггера для этой команды. (Выполнение подобных вычислений сказывается на общей производительности СУБД, а в моменты пиковой нагрузки ее снижение может стать особенно заметным. Очевидно, что при возрастании количества триггеров увеличиваются и накладные расходы, связанные с такими операциями.).
Реализация триггеров в среде MS SQL Server
В реализации СУБД MS SQL Server используется следующий оператор создания или изменения триггера:
{CREATE | ALTER} TRIGGER имя_триггера ON {имя_таблицы}
[WITH ENCRYPTION ]
FOR [ DELETE] [,] [ INSERT] [,] [ UPDATE] [ WITH APPEND ]
[ NOT FOR REPLICATION ]
AS операторы
Триггер может быть создан только в текущей базе данных, но допускается обращение внутри триггера к другим базам данных, в том числе и расположенным на удаленном сервере.
Использование инструкций CREATE | ALTER соответственно, определяет создание или изменение триггера. Имя триггера должно быть уникальным в пределах базы данных. Дополнительно можно указать имя владельца.
При указании аргумента WITH ENCRYPTION выполняется шифрование кода триггера, чтобы никто, включая администратора, не мог получить к нему доступ и прочитать его. Восстановление текста триггера невозможно.
Типы триггеров
В SQL Server существует два параметра, определяющих поведение
триггеров:
AFTER. Триггер выполняется после успешного выполнения вызвавших его команд. Если же команды по какой-либо причине не могут быть успешно завершены, триггер не выполняется. Следует отметить, что изменения данных в результате выполнения запроса пользователя и выполнение триггера осуществляется в теле одной транзакции: если произойдет откат триггера, то будут отклонены и пользовательские изменения. Можно определить несколько AFTER-триггеров для каждой операции (INSERT, UPDATE, DELETE). Если для таблицы предусмотрено выполнение нескольких AFTER-триггеров, то с помощью системной хранимой процедуры sp_settriggerorder можно указать, какой из них будет
выполняться первым, а какой последним. По умолчанию в SQL Server все триггеры являются AFTER-триггерами.
INSTEAD OF. Триггер вызывается вместо выполнения команд. В отличие от AFTER-триггера INSTEAD OF-триггер может быть определен как для
таблицы, так и для просмотра. Для каждой операции INSERT, UPDATE, DELETE можно определить только один INSTEAD OF-триггер. Существует три типа триггеров:
INSERT TRIGGER – запускаются при попытке вставки данных с помощью команды INSERT.
UPDATE TRIGGER – запускаются при попытке изменения данных с помощью команды UPDATE.
DELETE TRIGGER – запускаются при попытке удаления данных с помощью команды DELETE.
Конструкции [ DELETE] [,] [ INSERT] [,] [ UPDATE] определяют, на какую команду будет реагировать триггер. При его создании должна быть указана хотя бы одна команда. Допускается создание триггера, реагирующего на две или на все три команды.
Устно: При создании триггера с аргументом NOT FOR REPLICATION запрещается его запуск во время выполнения модификации таблиц механизмами репликации.
Конструкция AS оператор определяет набор SQLоператоров и команд, которые будут выполнены при запуске триггера.
Отметим, что внутри триггера не допускается выполнение ряда операций, таких, например, как:
создание, изменение и удаление базы данных;
восстановление резервной копии базы данных или журнала транзакций. Выполнение этих команд не разрешено, так как они не могут быть
отменены в случае отката транзакции, в которой выполняется триггер.
Программирование триггера
При выполнении команд добавления, изменения и удаления записей сервер создает две специальные таблицы: inserted и deleted. В них содержатся списки строк, которые будут вставлены или удалены по завершении транзакции. Структура таблиц inserted и deleted идентична структуре таблиц, для которой определяется триггер. Для каждого триггера создается свой комплект таблиц inserted и deleted, поэтому никакой другой триггер не сможет получить к ним доступ. В зависимости от типа операции, вызвавшей выполнение триггера, содержимое таблиц inserted и deleted может быть разным:
команда INSERT – в таблице inserted содержатся все строки, которые пользователь пытается вставить в таблицу; в таблице deleted не будет ни одной строки; после завершения триггера все строки из таблицы inserted переместятся в исходную таблицу;
команда DELETE – в таблице deleted будут содержаться все строки, которые пользователь попытается удалить; триггер может проверить
каждую строку и определить, разрешено ли ее удаление; в таблице inserted не окажется ни одной строки;
команда UPDATE – при ее выполнении в таблице deleted находятся старые значения строк, которые будут удалены при успешном завершении триггера. Новые значения строк содержатся в таблице inserted. Эти строки добавятся в исходную таблицу после успешного выполнения
триггера.
Для получения информации о количестве строк, которое будет изменено при успешном завершении триггера, можно использовать функцию @@ROWCOUNT; она возвращает количество строк, обработанных последней командой. Следует подчеркнуть, что триггер запускается не при попытке изменить конкретную строку, а в момент выполнения команды изменения. Одна такая команда воздействует на множество строк, поэтому триггер должен обрабатывать все эти строки.
Если триггер обнаружил, что из 100 вставляемых, изменяемых или удаляемых строк только одна не удовлетворяет тем или иным условиям, то никакая строка не будет вставлена, изменена или удалена. Такое поведение обусловлено требованиями транзакции – должны быть выполнены либо все модификации, либо ни одной.
Триггер выполняется как неявно определенная транзакция, поэтому внутри триггера допускается применение команд управления транзакциями. В частности, при обнаружении нарушения ограничений целостности для прерывания выполнения триггера и отмены всех изменений, которые пытался выполнить пользователь, необходимо использовать команду ROLLBACK TRANSACTION.
Еще в SQL Server 2000 появился новый тип триггеров INSTEAD OF. Данный тип триггеров предназначен в первую очередь для представлений (VIEW). Создадим триггер INSTEAD OF INSERT и внесем изменения в таблицу:
CREATE TRIGGER ins_str_view ON View_Predmet INSTEAD OF INSERT
AS
print 'Триггер INSTEAD OF'
insert INTO View_Predmet values ('Иванов')
При выполнении вставки строки никаких изменений в таблице не происходит. Хотя и выдается сообщение о том, что строка добавлена. В таком типе триггеров необходимо добавлять код на изменение данных в таблице.
Обратите внимание на SET NOCOUNT ON в начале тела триггера. Это нужно для того, чтобы команды из тела триггера не возвращали информацию о количестве обработанных строк, и не перебивали тем самым информацию о количестве измененных строк.
CREATE TRIGGER TriggerInsteadMaster1 ON Predmet INSTEAD OF INSERT
AS
SET NOCOUNT ON
………………………
Для получения списка столбцов, измененных при выполнении команд INSERT или UPDATE, вызвавших выполнение триггера, можно использовать функцию COLUMNS_UPDATED(). Она возвращает двоичное число, каждый бит которого, начиная с младшего, соответствует одному столбцу таблицы (в порядке следования столбцов при создании таблицы). Если бит установлен в значение «1», то соответствующий столбец был изменен. Кроме того, факт изменения столбца определяет и функция UPDATE (имя_столбца). Даже если данные до изменения и после изменения были одни и те же, эти функции покажут, что данные в поле были изменены. Например, функция UPDATE(Field) возвратит True при выполнении запроса:
Для удаления триггера используется команда DROP TRIGGER имя_триггера
Приведем примеры использования триггеров.
1) Ограничить ввод данных определенным количеством, например, ограничить количество пересдач тремя.
CREATE TRIGGER ins_str ON [dbo].[Ekzamen] FOR INSERT, UPDATE
AS declare
IF EXISTS
(SELECT COUNT(a.predmet) FROM ekzamen A, INSERTED B
WHERE A.fio = B.fio and A.predmet = B.predmet GROUP BY a.predmet
HAVING COUNT(a.predmet) >3) begin
SELECT @a = predmet, @b = data FROM INSERTED
DELETE FROM ekzamen WHERE predmet = @a AND data = @b
end
(ЕЩЕ ВАРИАНТ)
ALTER TRIGGER ins_str ON [dbo].[Ekzamen] FOR INSERT, UPDATE
AS
DECLARE @a char(50), @b datetime,
@c int
SELECT @c=COUNT(a.predmet) FROM ekzamen A, INSERTED B
WHERE A.fio = B.fio and A.predmet = B.predmet GROUP BY a.predmet
HAVING COUNT(a.predmet)>3 IF @c>3
BEGIN
SELECT @a = predmet, @b = data FROM INSERTED
DELETE FROM ekzamen WHERE predmet = @a AND data = @b
END
(ЕЩЕ ВАРИАНТ)
вместо
SELECT @b = data, @c = predmet FROM INSERTED
DELETE FROM ekzamen WHERE data = @b AND predmet = @c можно использовать
ROLLBACK TRANSACTION
2) Не добавлять информацию о сданных экзаменах, если средний балл студента выше 4.0.
CREATE TRIGGER [no_ins_4] ON [dbo].[Ekzamen] FOR INSERT, UPDATE
AS
delete from Ekzamen
where fio IN (select a.fio from Ekzamen a inner join INSERTED b on a.fio=b.fio /*можно без соединения – т.к. ср. балл считается в таблице
Ekzamen*/ group by a.fio
having AVG(a.ocenka) > 4)
Пример не работает т.к. проверка осуществляется до заполнения данных из таблицы INSERTED
Не будет работать по тем же причинам также пример вида
CREATE TRIGGER [no_ins_4] ON [dbo].[Ekzamen] FOR INSERT, UPDATE
AS
if exists (select fio from ekzamen group by fio
having avg(ocenka) >4) rollback tranSACTION