Файл: Тема концепция управления данными в современных информационных системах Цель лекции.docx

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

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

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

Еще одним типом хранимых процедур являются так называемые расширенные хранимые процедуры (extended stored procedures). Они пишутся на языке программирования, таком как С. Расширенные хранимые процедуры оформляются как функции в составе библиотек динамических связей - DLL (Dinamic Link Library), что повышает скорость их выполнения. Имена расширенных хранимых процедур начинаются с символов хр.

Создание и использование хранимых процедур.

Для создания хранимых процедур используется инструкция CREATE PROCEDURE. Хранимые процедуры могут создаваться только в текущей базе данных, кроме временных хранимых процедур, которые всегда создаются в базе данных tempdb. Создание хранимой процедуры очень похоже на создание представления. Сначала напишите и протестируйте инструкции Transact-SQL, которые будут включены в хранимую процедуру. Затем, если будут получены ожидаемые результаты, создайте хранимую процедуру.

Инструкция CREATE PROCEDURE содержит много возможных параметров, как можно видеть из примера части синтаксиса..
CREATE {PROC | PROCEDURE} [schema_name.] procedure_name [{@parameter [type_schema_name.] data_type}

[VARYING] [= default] [[OUT [PUT]] [,...n]

[WITH
[,...n] AS sql_statement [;][ ...n]

::= [ENCRYPTION] [RECOMPILE]

[EXECUTE_AS_Clause]
Следующий пример иллюстрирует создание простой хранимой процедуры, которая возвращает набор строк для всех продуктов, для производства которых требуется больше одного дня.

CREATE PROC Production.LongLeadProducts AS

SELECT Name, ProductNumber FROM Production.Product WHERE DaysToManufacture >= 1

GO

В этом примере создается процедура с именем LongLeadProducts в схеме Production. Команда GO включена для того, чтобы подчеркнуть тот факт, что инструкции REATE PROCEDURE должны быть объявлены в одном пакете.

В примере показано, как вызывать хранимую процедуру LongLeadProducts.

---

EXEC Production.LongLeadProducts

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

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

- Разрабатывать каждую хранимую процедуру для выполнения одной задачи.

- Создать, протестировать и устранить неполадки процедуры на сервере, затем протестировать ее со стороны клиента.

- Избегать использования префикса sp_ в именах локальных хранимых процедур, чтобы можно было легко отличать системные хранимые процедуры. Другая причина, по которой следует избегать использования префикса sp_ для хранимых процедур в локальной базе данных — это исключение ненужного поиска в главной базе данных. Когда вызывается хранимая процедура с именем, которое начинается с sp_, SQL Server, прежде чем начать поиск в локальной базе данных, выполняет поиск в главной базе данных.

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

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

---

Изменение и удаление хранимых процедур

Часто бывает необходимо изменить хранимые процедуры в ответ на запросы пользователей или изменения в определениях основных таблиц. Чтобы изменить существующую хранимую процедуру и сохранить назначение разрешений, используйте инструкцию ALTER PROCEDURE. SQL Server заменяет предыдущее определение хранимой процедуры, когда она изменяется с использованием инструкции ALTER PROCEDURE .

При использовании инструкции ALTER PROCEDURE следует учитывать:

- Для изменения хранимой процедуры, созданной с параметром, например WITH ENCRYPTION, необходимо включить этот параметр в инструкцию ALTER PROCEDURE, чтобы сохранить предоставляемые им функциональные возможности.

- Инструкция ALTER PROCEDURE изменяет только одну процедуру. Если процедура вызывает другие хранимые процедуры, вложенные хранимые процедуры остаются неизменными.

В следующем примере хранимая процедура LongLeadProducts изменяется для выбора дополнительного столбца и сортировки набора результатов с использованием предложения ORDER BY.

ALTER PROC Production.LongLeadProducts AS

SELECT Name, ProductNumber, DaysToManufacture FROMProduction.Product

WHERE DaysToManufacture >= 1

ORDER BY DaysToManufacture DESC, Name GO

Для удаления пользовательских хранимых процедур из текущей базы данных используется инструкция DROP PROCEDURE.

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

EXEC sp_depends @objname = N'Production.LongLeadProducts'

Следующий пример иллюстрирует удаление хранимой процедуры LongLeadProducts.

DROP PROC Production.LongLeadProducts

Созданиетриггеров

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

---

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

Триггер и вызвавший его оператор Transact-SQL рассматриваются как единая тран­закция, отменяемая (откатываемая) из триггера. Обычно в состав триггера входит набор команд выполнения некоторых действий над данными или проверки опреде­ленных условий. При невозможности обработки данных или невыполнимости усло­вий происходит откат транзакции.

Создание триггера возможно владельцем базы данных. Это ограничение позволя­ет избежать случайного изменения структуры таблиц, способов связи с ними других объектов и т. п.

Для создания триггеров используется оператор CREATE следующего формата:

CREATE TRIGGER [владелец]имя_триггера

ON [владелец] имя_ таблицы

FOR {INSERT, UPDATE, DELETE}

[WITH ENCRYPTION]

AS



Здесь ключевые слова INSERT (Вставить), UPDATE (Обновить) и DELETE (Удалить) определяют операции, которые иницируют выполнение триггера. Параметр WITH ENCRYPTION (с шифрованием) служит для предотвращения возможности прочтения текста триггера после помещения его на сервер. SQL Server сохраняет текст триггера в таблице системного каталога syscomments.

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

Триггеры представляют собой весьма полезное и в то же время опасное средство. Так, при неправильной логике работы триггера можно легко уничтожить целую базу данных. Поэтому требуется очень тщательно отслеживать триггеры и проверять логику их работы.
4. Транзакция — это элементарная единица работы, выполняемая в базе данных. Характеристики транзакций часто описывают аббревиатурой ACID: Atomicity, Consistency, Isolation и Durability, которая применяется для описания основных требований по организации транзакций, предъявляемых к надежным серверам баз данных .

- Атомарность (Atomicity) — транзакция должна быть атомарной для исполняемого блока команд. Или все её изменения данных будут исполнены, или не будет исполнено ни одно из них.

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

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

- Неизменность или живучесть (Durability) — после того, как транзакция завершена, результаты её работы в системе не должны изменяться. Изменения должны сохраняться даже в случае отказа системы.

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

1   2   3   4   5   6   7   8   9   10   11

---

Журнал транзакций

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

Процесс ведения журнала транзакций состоит из нижеперечисленных таких этапов:

1. 
   Приложение отправляет запрос на изменение данных.
   
2. 
   При выполнении изменения затрагиваемые страницы данных загружаются с диска в буферный кэш, если они не были уже помещены туда при обработке предыдущего запроса.
   
3. 
   В журнал записывается каждая инструкция изменения данных, как только это изменение производится. Изменение всегда заносится в журнал и записывается на диск до того, как оно будет отражено в базе данных. Журнал такого типа называется журналом с упреждающей записью.
   
4. 
   Периодически инициируемый процесс установки контрольной точки записывает все завершенные транзакции в базу данных на диск.
   

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

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

Транзакция считается завершенной, если для маркера BEGIN TRANSACTION существует соответствующий ему маркер COMMIT TRANSACTION. При достижении контрольной точки страницы данных записываются на диск.

ТЕМА 11. Современные и перспективные технологии в области баз данных
Цель лекции: ознакомиться с новыми технологиями в области баз данных.

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

---