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

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

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

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

Целью
использования СМО как модели является анализ качества функционирования
указанных систем-оригиналов.

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

2)
Предложение SELECT языка SQL. Объединение UNION. Квантор существования EXIST и
NOT EXIST.

SELECT columns FROM tablesWHERE EXISTS
(subquery);

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

SELECT Название
FROM Товар                WHERE EXISTS (SELECT КодТовара FROM Склад
             

WHERE Товар.КодТовара=Склад.Код>Товара)

Ключевые слова EXISTS
и NOT EXISTS предназначены для использования только совместно с подзапросами.
Результат их обработки представляет собой логическое значение TRUE или FALSE.
Для ключевого слова EXISTS результат равен TRUE в том и только в том
случае, если в возвращаемой подзапросом результирующей таблице
присутствует хотя бы одна строка. Если результирующая таблица подзапроса
пуста, результатом обработки операции EXISTS будет значение FALSE. Для
ключевого слова NOT EXISTS используются правила обработки, обратные по
отношению к ключевому слову EXISTS. Поскольку по ключевым словам EXISTS
и NOT EXISTS проверяется лишь наличие строк в результирующей таблице подзапроса,
то эта таблица может содержать произвольное количество столбцов.

Определить список
отсутствующих на складе товаров

SELECT Название FROM Товар WHERE NOT EXISTS      (SELECT КодТовара FROM Склад                 

WHERE
Товар.КодТовара=Склад.Код>Товара)

ОБЪЕДИНЕНИЕ
ЗАПРОСОВ UNION [SQL Statement 1]                        UNION    [SQL Statement 2]

SELECT Date FROM Store_Information      UNION             SELECT
Date FROM Internet_Sales;

Получаем: Date Jan-05-1999 Jan-07-1999 Jan-08-1999
Jan-10-1999 Jan-11-1999 Jan-12-1999

SELECT Date FROM Store_Information

                  UNION ALL

SELECT Date FROM Internet_Sales

3)Изолированность пользователей,
уровни изолированности.

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

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

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

·     Первый уровень - отсутствие потерянных
изменений. Рассмотрим следующий сценарий совместного выполнения двух
транзакций. Транзакция 1 изменяет объект базы данных A. До завершения
транзакции 1 транзакция 2 также изменяет объект A. Транзакция 2 завершается
оператором ROLLBACK (например, по причине нарушения ограничений целостности).
Тогда при повторном чтении объекта A транзакция 1 не видит изменений этого объекта,
произведенных ранее. Такая ситуация называется ситуацией потерянных изменений.
Естественно, она противоречит требованию изолированности пользователей. Чтобы
избежать такой ситуации в транзакции 1 требуется, чтобы до завершения
транзакции 1 никакая другая транзакция не могла изменять объект A. Отсутствие
потерянных изменений является минимальным требованием к СУБД по части
синхронизации параллельно выполняемых транзакций.

·     Второй уровень - отсутствие чтения "грязных
данных". Рассмотрим следующий сценарий совместного выполнения транзакций 1
и 2. Транзакция 1 изменяет объект базы данных A. Параллельно с этим транзакция
2 читает объект A. Поскольку операция изменения еще не завершена, транзакция 2
видит несогласованные "грязные" данные (в частности, операция
транзакции 1 может быть отвернута при проверке немедленно проверяемого
ограничения целостности). Это тоже не соответствует требованию изолированности
пользователей (каждый пользователь начинает свою транзакцию при согласованном
состоянии базы данных и в праве ожидать видеть согласованные данные). Чтобы
избежать ситуации чтения "грязных" данных, до завершения транзакции
1, изменившей объект A, никакая другая транзакция не должна читать объект A
(минимальным требованием является блокировка чтения объекта A до завершения
операции его изменения в транзакции 1).

·     Третий уровень - отсутствие неповторяющихся
чтений. Рассмотрим следующий сценарий. Транзакция 1 читает объект базы данных
A. До завершения транзакции 1 транзакция 2 изменяет объект A и успешно
завершается оператором COMMIT. Транзакция 1 повторно читает объект A и видит
его измененное состояние. Чтобы избежать неповторяющихся чтений, до завершения
транзакции 1 никакая другая транзакция не должна изменять объект A. В
большинстве систем это является максимальным требованием к синхронизации
транзакций, хотя, как мы увидим немного позже, отсутствие неповторяющихся
чтений еще не гарантирует реальной изолированности пользователей.

Заметим, что существует возможность обеспечения разных
уровней изолированности для разных транзакций, выполняющихся в одной системе
баз данных (в частности, соответствующие операторы предусмотрены в стандарте
SQL 2). Как уже отмечали, для поддержания целостности достаточен первый
уровень. Существует ряд приложений, для которых первого уровня достаточно
(например, прикладные или системные статистические утилиты, для которых
некорректность индивидуальных данных несущественна). При этом удается
существенно сократить накладные расходы СУБД и повысить общую эффективность.

Уровни
изоляции в MS SQL Server 2000:

По умолчанию, устанавливается изоляция Read Committed, и эта установка действует в
рамках сеанса. Основной принцип состоит в том, что пишущая транзакция всегда
блокирует читающие транзакции, если они имеют уровни изоляции выше её, исключая
Read Uncommited.

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

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

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

Уровень
Serializable идёт на шаг дальше по
отношению Repeatable Read и защищает
все другие блоки данных от вставок. Это называется предотвращением фантомных
чтений.