Помимо стандартного отклонения, инвестиционные кампании рассчитывают такой показатель риска как VaR (Value at Risk). Этот показатель характеризует величину возможного убытка с выбранной вероятностью за определенный промежуток времени. Value-at-Risk рассчитывается 3-мя методами:

1. Вариация/ ковариация (или корреляция или параметрический метод)
2. Историческое моделирование (дельта нормальный метод, «ручной рассчет»)
3. Расчет при помощи метода Монте -Карло

Для расчета параметра риска Value at Risk с помощью дельта нормального метода , необходимо сформировать выборку фактора риска, необходимо, что бы количество значений выборки было больше 250 (рекомендация Bank of International Settlements), для обеспечения репрезентативности. Возьмем данные котировок акции Газпрома за период с 9 января 2007 года по 31 июля 2008 года.

Для котировок акции Газпрома рассчитаем дневную доходность по формуле:

Где: Д – дневная доходность;
Рi- текущая стоимость акции;
Рi-1 – вчерашняя доходность акции.

Правильность использования метода Value at Risk при дельта нормальном способе расчета, достигается при использовании только факторов риска подчиненным нормальному (Гауссовому) закону распределения. Для проверки нормальности распределения доходностей акции можно воспользоваться критериями Пирсона или Колмогорова -Смирнова.
Формула в Excel будет выглядеть следующим образом:

LN((C3)/C2)
В итоге получилась следующая таблица.

После этого необходимо рассчитать математическое ожидание доходности и стандартное отклонение доходности за весь период. Воспользуемся формулами Excel.
Математическое ожидание =СРЗНАЧ(D2:D391)
Стандартное отклонение =СТАНДОТКЛОН(D2:D391)

На следующем этапе необходимо рассчитать квантиль нормальной функции распределения. Квантиль – это значения функции распределения (Гауссовой функции) при заданных значениях, при которых значения функции распределения не превышают это значение с определенной вероятностью. Квантиль сообщает то, что убытки по акции Газпром не превысят с вероятностью 99%.

Квантиль рассчитывается по формуле:
=НОРМОБР(1%;F2;G2)

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


Xt+1 –значение доходности в следующий момент времени.

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

Где: Q- значение квантиля для нормального распределения акции Газпрома;
Xt- значение доходности акции в текущий момент времени;
Xt+1 –значение отклонения доходности в следующий момент времени;
n - количество дней вперед.

Формулы расчета VAR на один день VAR(1) и на пять VAR(5) дней вперед производится по формулам:
X(1) =(F5+1)*C391
X(5) =(КОРЕНЬ(5)*F5+1)*C391

Расчет значения цены акции с вероятностью 99% при убытках показан на рисунке ниже.

Полученные значения Х(1) = 266.06 говорит о том, что в течение следующего дня, курса акции Газпрома не превысят значения в 226.06 руб. с вероятностью 99%. И Х(5) говорит о том, что в течение следующих пяти дней с вероятностью 99% курс акции Газпрома не опустится ниже 251.43 руб.

Для расчета самого Var (величина возможных убытков), рассчитаем абсолютное значение убытков и относительное. Формулы в Excel будут следующими:
=C392-G7 =G11/C392
=C392-G8 =G12/C392

Эти цифры говорят следующее: убыток по акции Газпрома с вероятностью 99% не превысит 7.16 руб. на следующий день и убыток по акции Газпрома с вероятностью 99% не превысит 21.79 руб. за следующие пять дней.

Расчет показателя Value at Risk «ручным способом»
Создадим новый рабочий лист в Excel. Для того что бы определить значения Value at Risk «ручным способом», необходимо найти:

1. Максимум доходностей за весь временной диапазон =МАКС(Лист1!D3:D392)
2. Минимум доходностей за весь временной диапазон =МИН(Лист1!D3:D392)
3. Количество интервалов (N) = 100
4. Интервал группировки (Int) =(B1-B2)/B3

Ниже показан расчет этих параметров.

После построим гистограмму накопительной вероятности. Для этого выберем Сервис ->Анализ Данных -> Гистограмма.

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

В таблице накопительной вероятности найдем значения вероятности 1% (Это соответствует колонке «Интегральный %») и определим значения квантиля. Первая колонка это значения квантилей для распределения доходности акций Газпрома, вторая колонка частота появления таких значений на исторической выборке и третья колонка это вероятность появления таких убытков.

Значения квантиля будут равняться -0,0473, при подсчете первым методом значение квантиля равнялось 0,0425. Далее расчет делается аналогично дельта нормальному методу.
В таблице ниже представлен расчет VaR. Возможные убытки с вероятностью 99% не превысят на следующий день 8,47 руб. и в течение пяти дней не превысят 24,72 руб.

Выводы
Мера риска Value at Risk позволяет оценить величину возможных убытков в количественных показателях, что является эффективным методом управления финансовыми рисками.

7. Ограничения целостности

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

7.1 Что такое ограничения целостности

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

Вначале - немного теории.

Все ограничения целостности можно разделить на три большие категории:

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

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

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

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

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

«A table or view can have only one unique key .»
Oracle9i SQL Reference об ограничении использования Ограничений уникальности

Утверждение, представленное в качестве эпиграфа, взято из документации Oracle, но вся практика до прочтения документации указывала на противоположное. Проверка путём создания пары Unique Constraint -ов подтвердила это. Налицо ошибка в документации.

А что ещё (с надеждой на безошибочность описания) можно почерпнуть из документации об Ограничениях целостности в Oracle? Я постарался выписать различные терминологические и функциональные особенности Ограничений целостности как отдельных типов объектов БД Oracle без углубления в синтаксис и подробности их использования. Многое для меня оказалось новым, не буду скрывать.

Начнёмссамогоначала - Oracle9i Database Concepts Release 2 (9.2) . В документации выделяется понятие «Целостность данных» (Data Integrity ), которое связывается с выполнением бизнес-правил, сопряжённых с БД. Data Integrity делится на пять типов правил, часть из которых обеспечивается «Ограничениями целостности» (Integrity Constraints ) СУБД Oracle :

1. NULL -правило - NOT NULL ограничение;

2. уникальные значения - ограничения уникального ключа;

3. значения первичного ключа - ограничения первичного ключа;

4. правила ссылочной целостности - ограничения внешнего ключа (или «ограничения ссылочной целостности» - в документации Oracle встречаются оба названия);

5. проверка комплексного ограничения - Check -ограничения.

(Здесь слева от тире представлено правило «Целостности данных», а справа - тип «Ограничений целостности», реализующий это правило)

Четвёртый тип правил «Целостности данных» является составным, и обеспечивается «Ограничениями целостности» лишь частично:

1. выставление в NULL зависимых данных при удалении справочных данных;

2. каскадное удаление зависимых данных при удалении справочных данных;

3. а также отсутствие какого либо действия над зависимыми данными при изменении или удалении справочных данных. (Здесь для меня осталась неясность в плане отличия Restrict от No Action . Может, кто из читателей поможет обнаружить различие…)

Оставшиеся существующие подтипы четвёртого пункта «Целостности данных»:

o выставление в NULL зависимых данных при изменении справочных данных;

o каскадное изменении зависимых данных при изменении справочных данных;

o выставление в значение по умолчанию зависимых данных при изменении или удалении справочных данных;

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

Далее для краткости и в силу привычки буду использовать названия «Ограничений целостности» в английском варианте (соотнесение с вышеупомянутыми русскими названиями, на мой взгляд, очевидно), а вместо «Ограничения целостности» писать просто Ограничения.

Итак, UNIQUE Key Constraint . Это Ограничение требует, чтобы каждое значение в поле ключа было уникальным. Под понятием «значение» здесь подразумевается определённая величина, а NULL-значение под данное определение не подпадает, так что одно, два, да даже все поля в ключе UNIQUE Key Constraint могут быть равны NULL. В отличие от ключа PRIMARY Key Constraint , в котором NULL-значение не допускается вовсе.

При создании UNIQUE Key Constraints или PRIMARY Key Constraints неявно создаётся уникальный индекс по тем полям таблицы, на которые накладывается данное Ограничение. Однако, если некий (неважно - уникальный или неуникальный) индекс по полям ключа уже используется, то будет использоваться именно он вместо неявного создания нового. При удалении этих Ограничений будут удаляться и индексы. Уникальные Ограничения, созданные с атрибутом DEFERRABLE (см. ниже) всегда используют неуникальные индексы. При удалении таких Ограничений неуникальные индексы остаются.

Referential Integrity Constraint требуетсуществованиявродительской (справочной) таблице UNIQUE Key Constraint или PRIMARY Key Constraint. При отсутствии Ограничения NOT NULL на каком либо поле, входящем в Referential Integrity Constraint , в этом поле

допускается NULL -значение, и такой Referential Integrity Constraint будет считаться правильным.

• Если на внешнем ключе отсутствует индекс. Тогда при удалении или изменении первичного ключа родительской таблицы, Oracle будет выставлять блокировку дочерней таблицы на уровне таблицы, освобождая эту блокировку сразу после её получения. Если внешний ключ определён как ON DELETE CASCADE , то удаление записей из родительской таблицы будет приводить к share-subexclusive блокировкам на дочерней таблице. Разделяемая блокировка всей дочерней таблицы также потребуется при изменении тех полей в родительской таблице, на которые ссылаются поля дочерней таблицы. Разделяемая блокировка позволяет только чтение данных, так что ни вставка, ни удаление, ни изменение данных в дочерней таблице не будут доступны до тех пор, пока не завершится транзакция на родительской таблице.
• Если на внешнем ключе присутствует индекс, то никаких блокировок на уровне таблицы уже не будет, и при любом удалении или изменении данных в родительской таблице, в дочерней таблице будут блокированы до завершения транзакции только отдельные соответствующие записи (эксклюзивная блокировка на уровне строк).

CHECK Integrity Constraints . Допускаются на одном или нескольких полях таблицы и требует в качестве результата выполнения определённого условия TRUE или UNKNOWN для каждой строки таблицы. Примечательно, что под UNKNOWN подразумевается… NULL! Иными словами, если везде (во всяком случае, следуя той же документации Oracle) NULL -значение не равно ничему, в том числе и самому себе, то здесь оно «работает» как TRUE . Забавно, не так ли?

Особенности:

• может использоваться только Булево выражение;
• нельзя использовать подзапросы, SQL-функции или последовательности (интересно, почему?);
• нельзя использовать SYSDATE , UID , USE R, USERENV , LEVEL , ROWNUM .

Количество CHECK Integrity Constraints неограниченно, но порядок их срабатывания непредсказуем. Ну, и при использовании строчных литералов или таких SQL -функций, как TO_CHAR, TO_DATE, TO_NUMBER с параметрами поддержки глобализации в качестве аргументов, Oracle использует значения этих параметров по умолчанию на уровне базы. Эти значения можно переписать в создаваемом CHECK Integrity Constraint .

Все перечисленные Ограничения, реализованные в Orac le, допускают их нарушение на уровне оператора, то есть сначала оператор будет полностью выполнен (пускай он коснётся хоть миллиона строк), а потом начнётся проверка Ограничений. Хотя, возможна отложенная проверка Ограничений- до завершения транзакции (о чём речь далее).

Режим SET CONSTRAINTS.

Оператор SET CONSTRAINTS делает Ограничения или DEFERRED , или IMMEDIATE (DEFERRED и IMMEDIATE относятся к атрибутам Ограничений, о чём речь далее) для части транзакции. Данный оператор можно использовать для установки режима либо для списка Ограничений, либо для всех (ALL ) Ограничений. Действие данного оператора заканчивается вместе с завершением текущей транзакции, либо с началом действия ещё одного такого же оператора. Данный оператор недоступен в триггерах.

SET CONSTRAINTS … IMMEDIATE вначале вызывает проверку наличия отложенных ранее срабатываний Ограничений, а потом уже срабатывают Ограничения, вызванные выполняющимися операторами в текущей транзакции. Любое нарушение Ограничения при таком процессе будет просигнализировано ошибкой, а при достижении COMMIT’а будет вызван полный откат текущей транзакции. Оператор ALTER SESSION также может иметь выражение SET CONSTRAINTS , но только для всех Ограничений (нельзя их перечислить списком). Это эквивалентно выполнению оператора SET CONSTRAINTS в самом начале каждой транзакции.

Выполнение оператора SET CONSTRAINTS … IMMEDIATE перед самым завершением транзакции позволяет определить успешность предстоящего COMMIT’а и избежать лишних откатов.

Состояния Ограничений.

С помощью операторов CREATE TABLE или ALTER TABLE можно задавать состояние каждого Ограничения на уровне таблицы, используя следующие выражения:

• ENABLE гарантирует удовлетворение всех входных данных Ограничению;
• DISABLE позволяет входным данным не соответствовать Ограничению;
• VALIDATE гарантирует, что все уже имеющиеся в таблице данные соответствуют Ограничению;
• NOVALIDATE позволяет уже имеющимся в таблице данным не соответствовать Ограничению;

…и их комбинации:

• ENABLE VALIDATE аналогично ENABLE и гарантирует, что абсолютно все (и уже вставленные, и вставляемые) записи удовлетворяют Ограничению;
• ENABLE NOVALIDATE гарантирует удовлетворение Ограничению всех входных данных, однако уже имеющиеся в таблице данные могут не соответствовать Ограничению;
• DISABLE NOVALIDATE аналогично DISABLE . Не гарантируется удовлетворение Ограничению как входных данных, так и уже имеющихся в таблице;
• DISABLE VALIDATE отключает Ограничение, удаляет индекс, на котором оно строилось, и запрещает любые изменения на полях, входящих в Ограничение.

… и немного об особенностях применения:

· выражение ENABLE подразумевает ENABLE VALIDATE ;

· выражение DISABLE подразумевает DISABLE NOVALIDATE ;

· VALIDATE и NOVALIDATE ничего не подразумевают в отношении ENABLE и DISABLE (скажем так, они являются зависимой частью выражения при ENABLE и DISABLE );

· про создание и удаление индексов уже упоминалось;

· при изменении состояния из NOVALIDATE в VALIDATE выполняется проверка всех имеющихся в таблице данных, что может занять очень много времени. Наоборот, при приведении состояния Ограничения из VALIDATE в NOVALIDATE просто «забывается», что имеющиеся данные когда-то соответствовали Ограничению;

· перевод одиночного ограничения из состояния ENABLE NOVALIDATE в состояние ENABLE VALIDATE не блокирует чтения, записи или другие DDL операции, они могут быть выполнены параллельно.

И последние важные замечания.

• При создании Ограничения можно указать в качестве атрибута, возможно ли в дальнейшем в ходе транзакции установить оператором SET CONSTRAINTS (см. выше) отложенную (DEFERRED ) проверку данного Ограничения. По умолчанию выставляется NOT DEFERRABLE (что оно означает, думаю, понятно). После создания Ограничения изменить значение выставленного атрибута нельзя, кроме как пересоздав Ограничение, так что «семь раз подумай»!
• INIT IALLY является дополнительным атрибутом к DEFERRABLE, который может быть переписан оператором SET CONSTRAINT (опять см. выше), и который определяет поведение по умолчанию при срабатывании Ограничения с установленным атрибутом DEFERRABLE. При создании Ограничения по умолчанию выставляется INIT IALLY IMMEDIATE , тогда срабатывание Ограничения будет происходить каждый раз при выполнении отдельного оператора, при выставлении INIT IALLY DEFERRED срабатывание Ограничения будет отложено до окончания каждой транзакции. Для NOT DEFERRABLE такого дополнительного атрибута не требуется, так как он является INIT IALLY IMMEDIATE по определению.
• Выражение RELY. По умолчанию при изменении Ограничения (с помощью ALTER TABLE или MODIFY constraint ) выставляется NORELY . А означает оно следующее: стоит ли Oracle"у принимать в расчёт Ограничение, находящеесяв состоянии NOVALIDATE, для перезаписи запроса? RELY активирует существующее Ограничение в режиме (здесь в документации SQL Reference используется слово «mode », хотя я уже привык к слову «state» из Concepts , - по-видимому, писали разные люди, позабыв договориться о терминах) NOVALIDATE, что позволит переписать запрос, который иначе мог быть переписанным только с Ограничением в режиме VALIDATE. Примерно так. Подробнее - в следующий раз.
• EXCEPTIONS INTO определяет схему и таблицу, в которую будут внесены ROWID, нарушающие Ограничение при изменении его (Ограничения) состояния. Если имя схемы и таблицы не указать, то будет предполагаться, что нужно использовать таблицу с именем EXCEPTIONS в текущей схеме.

Вот и всё. На сегодня.