Аксиоматика Колмогорова
Аксиома́тика Колмого́рова — общепринятая аксиоматика для математического описания теории вероятностей. Первоначальный вариант предложен Андреем Николаевичем КолмогоровымHYPERLINK \l "cite_note-1"[1]HYPERLINK \l "cite_note-2"[2] в 1929 году, окончательная версия — в 1933 году. Аксиоматика Колмогорова позволила придать теории вероятностей стиль, принятый в современной математике.
Колмогоровские аксиомы элементарной теории вероятностей
Элементарная теория вероятностей — та часть теории вероятностей, в которой приходится иметь дело с вероятностями лишь конечного числа событий. Теория вероятностей, как математическая дисциплина, может и должна быть аксиоматизирована совершенно в том же смысле, как геометрия или алгебра. Это означает, что, после того как даны названия изучаемым объектам и их основным отношениям, а также аксиомы, которым эти отношения должны подчиняться, всё дальнейшее изложение должно основываться исключительно лишь на этих аксиомах, не опираясь на обычное конкретное значение этих объектов и их отношений. Аксиоматизация теории вероятностей может быть проведена различными способами как в отношении выбора аксиом, так и выбора основных понятий и основных соотношений. Если преследовать цель возможной простоты как самой системы аксиом, так и построения на ней дальнейшей теории, то представляется наиболее целесообразным аксиоматизирование понятии случайного события и его вероятности.
Алгебра Буля. СДНФ, СКНФ булевой функции.
Алгебра Жегалкина. Полином Жегалкина.
Алгоритм унификации и принцип резолюции Робинсона
Алгоритм шифрования ГОСТ 28147-89.
Алгоритмы внутренней сортировки и их сравнительный анализ.
Алгоритмы поиска и их сравнительный анализ.
Анализ свойств сущностей БД для распределения данных.
Шесть свойств сущностей, необходимых для распределения данных
Перед тем как изучать, какие проблемы проектирования возникают при использовании каждого из перечисленных выше средств Oracle, нужно определить, какие результаты анализа могут оказать нам помощь в определении того, как распределять данные внутри приложения. Конечно, в документации, подготовленной на этапе анализа, описаны сущности, а не таблицы. Однако необходимо определить для каждой сущности следующие свойства, имеющие отношение к планированию распределения данных:
- готовность - в течении какого времени должна быть доступна информация;
- достоверность - насколько важно иметь доступ к актуальному значению;
- видимость - насколько широкие полномочия предоставляются при запросе;
- доступность - как часто необходимо запрашивать информацию;
- мутируемость - насколько широкие полномочия предоставляются при изменении;
- изменчивость - как часто требуется изменять информацию.
Если сущность можно разбить на несколько частей, то анализ также должен дать схему фрагментации, в которой описаны:
- все соответствия, которые могут использоваться для разбиения сущности на части;
- порядок определения частей;
- точка, из которой будет запрашиваться и обновляться каждая часть, т.е. видимость, готовность, мутируемость и изменчивость части сущности. Если ни одно из этих свойств от части к части не изменяется, то необходимость разбиения становится сомнительной.
При наличии для каждой сущности всех шести свойств и схем фрагментации, некоторые решения о распределении данных принять оказывается очень просто. При этом необходимо обеспечить контроль избыточности, минимизировать влияние выхода из строя системы и сети, а также обеспечить поддержку точности данных, оптимальное время реакции и простоту администрирования всей распределенной среды.
Рассмотрим данные нескольких типов и разберем, каковы их свойства.
Пример: справочные таблицы.
Как мы упоминали ранее, приложение часто содержит ссылочные, или справочные, таблицы. У этих таблиц есть несколько важных характеристик:
- они постоянно используются всеми пользователями;
- они вряд ли когда-либо изменяются;
- если они изменяются, то только одним человеком, занимающим соответствующую должность;
- не обязательно иметь самую последнюю версию таких таблиц.
Сущности, на которых построены эти таблицы, описываются как имеющие следующие свойства:
- максимальную готовность;
- низкую достоверность;
- высокую видимость;
- высокую доступность;
- минимальную мутируемость;
- очень низкую изменчивость.
Следовательно, экземпляры справочных данных могут располагаться на каждом сервере в сети при условии, что существуют надежные средства распространения изменений. В этом случае можно также считать все копии этих данных, кроме одной, неизменяемыми - за исключением ситуации, когда изменения копируются из обновляемой копии в другие.
То, что распределение возможно, вовсе не означает, что мы должны его использовать. Если это поможет сократить число обращений по глобальной сети, то такое решение выглядит привлекательно. Изменение распределенных данных можно реализовать при помощи механизма снимков СУБД Oracle. Снимки можно сконфигурировать так, чтобы при регенерации снимка распространялись только изменения.
Рассмотрим другой случай, когда нам нужно иметь данные о служащих, при запросах к которым должны возвращаться только актуальные значения. Эти данные используются только при расчете месячной заработной платы и руководителями подразделений в нерегламентированных запросах. Руководители подразделений могут получать доступ к записям только о своих подчиненных, а изменять эти данные могут только бухгалтеры подразделений. Сущности, на основе которых строятся такие данные, имеют следующие свойства:
- средняя готовность;
- максимальная достоверность;
- минимальная видимость (потому что доступ ограничен конкретным подразделением);
- средняя доступность;
- низкая мутируемость;
- низкую изменчивость.
Следовательно, эти данные должны находиться только на том сервере, на котором ведется учет заработной платы по подразделениям. Таким образом, за исключением резервного копирования, никаких требований о наличии копий на других серверах нет. Эти данные горизонтально секционированы, и особой поддержки со стороны БД не требуется. Секционирование обеспечивает также некоторые требования к доступу и безопасности, так как руководители подразделений должны видеть только данные о заработной плате, находящиеся на сервере, к которому они подключены. В этом примере предполагается, что каждый региональный сервер имеет собственное локальное приложение для расчета заработной платы. В противном случае возникают требования к поддержке приложений.
Часто в одном приложении встречаются оба рассмотренных нами типа данных. Например, можно ожидать, что в системе расчета заработной платы, помимо записей о служащих (сопровождение которых обеспечивает узел, отвечающий за эти данные), используется ряд кодовых наборов (с централизованным сопровождением). Возможно, нам потребуется передавать данные-сводки на центральный сервер или сервер штаб-квартиры.
В настоящее время средства распределенных баз данных Oracle не обеспечивают непосредственную поддержку такой централизации итоговых данных, хотя и можно настроить структуры данных таким образом, чтобы механизм обновляемых снимков Oracle мог передавать итоговые данные в "центр". Однако в этом случае главную систему необходимо защитить от обновления.
Рассмотрим систему обработки выплат страхового возмещения, в которой требования о выплате создаются одним из семи региональных офисов и принадлежат ему. Сам головной офис требования не создает, но выполняет аудиторские и ИУС-запросы по всем требованиям.
Наиболее целесообразно эту схему реализовать с помощью обновляемых снимков, причем главная таблица должна находиться в системе головного офиса, а в каждом из регионов будет свой горизонтальный срез. Все вставки и обновления в такой схеме выполняются над снимками, а главная таблица используется только для запросов. Одно из удобств этой системы состоит в том, что в случае (редком), если требование пересылается из одного региона в другой, простое обновление снимка (изменение данных в столбце региона, определяющем сегментацию) приводит к удалению требования из одной горизонтальной секции и быстрому появлению его в другой. Единственная проблема здесь в том, что в промежутке между исчезновением и повторным появлением требование не принадлежит ни одному региону и может быть найдено только с помощью непосредственного запроса к главной таблице.
В данном случае предпочтительнее использовать локально реализованную структуру, в которой может использоваться, а может и не использоваться двухфазная фиксация, т.е. в данном случае разумнее реализовать специализированное решение.
В качестве еще одного примера рассмотрим систему бронирования авиабилетов, в которой для обновления текущих данных необходим доступ по глобальной сети. Самый простой и эффективный выход в данном случае — вообще не распределять данные, а пересылать все запросы доступа на центральный сервер, который обладает достаточной мощностью и способен справиться с глобальной нагрузкой. На текущий момент все еще крайне сложно при помощи одной базы данных Oracle обслуживать свыше 2000 одновременно работающих пользователей.
Почти так же сложно поддерживать 100000 одновременно работающих пользователей на одном мэйнфрейме, но этот уровень сервиса необходим ряду предприятий, и они изо дня в день его обеспечивают, причем время работы в таком режиме превышает 99%.
Вариант с мэйнфреймом по ряду понятных причин может не удовлетворять:
- высокая стоимость аппаратных средств;
- большой сетевой трафик;
- высокая стоимость разработки;
- большие сроки разработки.
Если вариант с мэйнфреймом отпадает, то речь может идти о симметричной репликации. При этом создается несколько копий (главных), в которые можно вносить изменения. Затем эти изменения (асинхронно или синхронно) будут распространяться в другие главные копии. Однако если не подходить к таким проектам с большой осторожностью, то экономия затрат на разработку и сокращение сроков разработки может быть гораздо меньше ожидаемых. Попытка реализовать открытую систему реляционными методами может обойтись дороже, чем проект на базе мэйнфрейма, если при этом используются средства ускоренной разработки приложений (УСП), которые ранее применялись лишь к небольшим приложениям масштаба подразделения.
В некоторых случаях распределение данных навязывается давней тенденцией к использованию серверов подразделений. Если новое приложение, работающее на новом сервере, нуждается в доступе к старым данным, хранящимся на существующем сервере, то некоторая форма распределения данных неизбежна. Способ реализации этого распределения может подсказать анализ шести свойств. В некоторых случаях новая система может работать со своей собственной копией ''разделяемых" данных, обновление которых производится не очень часто, например раз в месяц. В таком режиме обычно работают хранилища данных и ИСР, где вообще не выполняется обновление. Иногда степень трансформации данных при пересылке настолько высока, что результат уже нельзя классифицировать как распределенную базу данных. Его можно рассматривать, скорее, как данные, которые переданы из одного приложения в другое с использованием традиционного способа 60-х годов, предполагающего обработку данных на лентах. Если каждому из двух приложений нужно вносить изменения в данные, которые доступны другому приложению в оперативном режиме, то при принятии решения о числе копий данных — одна или две — необходимо учитывать объемы запросов и обновлений с каждого сервера.