Главная | Обратная связь

Методы распределенной обработки (примеры, если он спросит)

В разных СУБД применяются различные способы распределенной обработки. В Oracle и SQL Server поддержка распределенной обработки осуществляется сходным образом, но одни и те же вещи называются по-разному, и наоборот – разные вещи имеют одинаковые названия. У других производителей также имеется своя терминология. Здесь мы сосредоточимся на основных идеях.
Простейшим способом обработки распределенной базы данных является загрузка данных только для чтения. В этом случае обновлением всех данных в базе занимается только один компьютер, но копии данных только для чтения могут посылаться на множество (возможно, тысячи) компьютеров. В Oracle такие копии, предназначенные только для чтения, называются материализованными представлениями. В SQL Serverэти копии называются моментальными снимками.
При более сложном способе распределенной обработки запросы на обновление данных могут приходить со множества компьютеров, но на обработку они передаются одному специализированному компьютеру. Например, компьютер А может быть определен как единственный компьютер, который может обновлять таблицу СОТРУДНИК (и основанные на ней представления), а компьютер Б может быть определен как единственный компьютер, которому разрешено обновлять таблицу КЛИЕНТ (и ее представления). Время от времени обновления должны передаваться обратно на все компьютеры в распределенной сети, и базы данных должны синхронизироваться.
Наиболее сложный способ заключается в том, чтобы разрешить множественное обновление одних и тех же данных в различных местах. В этом случае могут возникнуть три вида конфликтов распределенных обновлений). Во-первых, может быть нарушена уникальность. В базе данных галереи View Ridge два разных компьютера могут создать в таблице ROW строку с одинаковыми значениями столбцов Copy, Title и ArtistlD. Другая возможность напоминает проблему потерянного обновления: на двух компьютерах может обновляться одна и та же строка. Третий конфликт возникает в ситуации, когда на одном компьютере обновляется строка, удаленная на другом компьютере.
Для разрешения конфликтов обновлений выделяется специальный компьютер. Он следит за всеми обновлениями, и возникающие конфликты разрешаются либо собственными средствами СУБД, либо приложениями, подобно тому, как это делается в триггерах. В самых крайних случаях делается запись о конфликте в журнале, и он разрешается вручную. Последний способ не рекомендуется, поскольку до устранения конфликта множество строк в работающих базах данных могут зависнуть в неопределенном положении, что приведет к неприемлемому снижению пропускной способности информационной системы предприятия.
Ни один из этих способов не решает проблемы обеспечения атомарности транзакций в распределенной базе данных. Эта проблема становится особенно важной, если имеется вероятность конфликтов обновлений. В какой момент работу с базой данных можно считать выполненной? Если во время разрешения конфликта распределенных обновлений должен произойти откат обновлений, то потенциально возможно, что распределенная транзакция не будет выполнена в течение нескольких часов или даже суток. Ясно, что такая задержка неприемлема.
Если оставить в стороне конфликты распределенных обновлений, остается еще один сложный вопрос — координация распределенных транзакций. Чтобы транзакция была атомарной, ни одно обновление в распределенной транзакции не должно быть сохранено, пока не будут сохранены все действия транзакции. Это означает, что каждый компьютер должен записать свои обновления условно и ожидать от диспетчера распределенных транзакций уведомления о том, что действия всех остальных компьютеров также записаны. Для этой цели используется алгоритм, называемый двухфазной фиксацией.

 

Билет №4

1. Графическое оформление выходных отчетов. Использование генераторов форм.

Создание таблиц, диаграмм, графиков, презентаций

2. Методы нормализации обобщенной внешней модели.

Обобщенная внешняя модель содержит данные о территориальном размещении информации. Топология РБД представляет географическое распределение локальных БД и отражает возможность обмена информацией между ними.

Структураобобщенной внешней модели, как и структура внешних моделей предметных областей пользователей, является инвариантной по отношению к структурам, реализуемым конкретным СУБД.

Характеристикиобобщенной внешней модели РБД должны поддерживаться и контролироваться системой управления РБД и локальной СУБД и учитываться в процессе проектирования РБД для получения заданных характеристик функционирования корпоративных АИУС.

На основании характеристикобобщенной внешней модели определяются характеристики канонической структуры РБД.

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

Этап нормализации информацииобобщенной внешней модели РБД заканчивается формированием структурированной матрицы смежности А и соответствующего ей орграфа GC ( DC, Яс), который не содержит дублируемых групповых элементов и избыточных взаимосвязей между ними. Граф GC ( DC, Яс) представляет собой каноническую структуру РБД.

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

Для обеспечения возможности использования информацииобобщенной внешней модели на последующих уровнях представления ( логическом и физическом) и для упрощения процесса синтеза логической структуры РБД информационные элементы и их взаимосвязи в обобщенной внешней модели упорядочиваются по уровням иерархии. Упорядочение элементов d G DT осуществляется на основе рассмотренной в разделе 2.8.2 процедуры упорядочения групп данных по уровням иерархии.

БИЛЕТ №5.

1. Организация репликаций и транзакций

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

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

Репликация может быть синхронной или асинхронной.

Синхронная репликация

В случае синхронной репликации, если данная реплика обновляется, все другие реплики того же фрагмента данных также должны быть обновлены в одной и той же транзакции. (Транзакция – одиночное или групповое изменение БД, которое выполняется полностью или не выполняется вообще (метод поддержания БД в целостном состоянии). Пример, банковской проводки. Или последовательность операций изменения базы данных и/или выборки из базы данных, воспринимаемая СУБД как атомарное действие.) Логически это означает, что существует лишь одна версия данных.

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

Асинхронная репликация

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

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

 

1. Проблемы организации и размещения информационных массивов. Интегрированные информационные системы

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

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

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

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

ERP-система (англ. Enterprise Resource Planning System — Система планирования ресурсов предприятия) — это интегрированная система на базе ИТ для управления внутренними и внешними ресурсами предприятия (значимые физические активы, финансовые, материально-технические и человеческие ресурсы).

Кроме того можно говорить о EAM (Enterprise Asset Management) -системе — информационная система управления основными фондами предприятия. Её применение позволяет не снижая уровня надёжности сократить затраты на техобслуживание и ремонт и материально-техническое снабжение.

WMS (Warehouse Management System) управление складом — система управления, обеспечивающая автоматизацию и оптимизацию всех процессов складской работы профильного предприятия. Система позволяет управлять складской логистикой в рамках различных технологических процессов (приём и отгрузка товара, внутренние перемещения) в реальном времени. Посредством автоматизации склада достигается высокая оборачиваемость склада, осуществляется быстрая комплектация партий товара, отгрузка их потребителям.

CMMS (Computerized Maintenance Management System (CMMS)) Компьютеризированная система управления техническим обслуживанием— комплекс программного обеспечения, включающий базу данных оборудования предприятия, модули планирования проведения технического обслуживания и планово-предупредительногоремонта, оформления заявок на проведение ремонта, модули складского учёта и заявок на покупку материалов,финансового учёта.

 

Билет №6