Объектная модель данных.

КУРСОВАЯ РАБОТА

по дисциплине: “Информационные системы”

1. Тема: “Программные средства реализации фактографических информационных систем.”

Выполнил:

студент гр. ПИ-ХХХ

Иванов Иван Иванович

Проверил:

Доц.каф ИТ

Лобова Ольга Ефимовна.

Сочи

20__ г.

ФГБОУ ВПО «Сочинский государственный университет»

Факультет “Информационных технологий и математики”

Кафедра “Информационных технологий”

Специальность:

_________________________________________________________

ЗАДАНИЕ

на курсовую работу по дисциплине

“Информационные системы”

Студенту________________________________________________________

Группа ____________________

Тема курсовой работы_____________________________________________

________________________________________________________________

СОДЕРЖАНИЕ ЗАДАНИЯ

_Введение

1. Теоретическая часть

1.1. Постановка задачи

1.2. Цель и назначение выполняемой работы

1.3. Общая характеристика исследуемой проблемы

1.4. Обоснование решений по видам обеспечения

2. Практическая часть

2.1. Алгоритм решения задачи

2.2. Выбор метода решения предложенного алгоритма

2.3. Реализация алгоритма

Руководитель курсовой работы ______________________ / ХХ Х.Х./

Студент ______________________ / ХХХХХ Х.Х./

Дата выдачи: “ ____ “ __________ 200_ г.

Объектная модель данных.

Объектно-ориентированные СУБД стали разрабатываться с середины 80-х годов в основном для поддержки приложений систем автоматизированного проектирования (САПР). Сложные структуры данных САПР оказалось очень удобно представлять в видеобъектах. Если связи типичные для реляционной базы данных имеют глубину в два уровня, то информация чертежей САПР обычно включает порядка десяти уровней, что требует достаточно сложных операций для “сборки” результата. Основные отличия объектных баз данных от всех прочих связаны с характеристиками, присущих собственно объектно-ориентированному программированию:
• понятие сложных объектов,
• идентификация объектов,
• классы и типы
• инкапсуляция,
• наследование.
Понятие сложных объектов. Когда сложный объект заносится в реляционную базу, то его данные обязательно раскладываются для их размещения в таблице. При чтении объекта из реляционной базы он собирается из отдельных элементов и только затем пригоден для использования. В объектных СУБД все иначе. Данные объекта, а также его методы помещаются в хранилище как единое целое.
Идентификация объектов. Метод идентификации объектов должен отвечать на вопрос, как отличить один объект от другого, т.е., если существует два объекта, то как определить,что эти объекты разные. Для того чтобы сравнивать объекты на тождество, необходимо, чтобы у любого объекта существовала некоторая уникальная характеристика. Многие объектные модели предлагают встроенные методы идентификации объектов. При создании любого нового объекта ему присваивается уникальный идентификатор, отличающийся от идентификаторов всех остальных имеющихся в системе объектов.
Классы и типы. Система управления объектной базой данных включает механизм структурирования данных, базирующейся на классах. Класс — это некоторый шаблон для построения объектов, обладающих одинаковым состоянием и поведением. Классы обладают свойствами и методами. Объект — это экземпляр класса. Объект имеет тип соответствующего класса и обладает индивидуальностью. Объекты одного и того же класса могут отличаться друг от друга свойствами, но не методами.
Инкапсуляция. Распространение понятие инкапсуляции на СУБД состоит в том, что объект инкапсулирует не только данные, но и программный код. Таким образом, предполагается единая модель, включающая не только структуру данных, но и методы ихобработки. При этом сами данные могут быть скрыты, а доступ к ним осуществляться через функции.
Наследование. О наследовании говорят, когда класс объектов порождается из другого класса. Порожденный класс находится со своим родительским классом в отношении «класс— есть подкласс родительского класса» и наследует все свойства и методы родительского класса.
Область применения. Системы автоматизированного проектирования и мультимедиа традиционно являются основными областями применения объектных СУБД, так как именно потребности этих отраслей спровоцировали появление объектных баз данных. Объектные базы данных становятся незаменимым средством хранения информации, когда быстродействие СУБД становится критическим параметром. Например, если требуется постоянное слежение за состоянием рынка. В качестве примера успешного решения проблемы быстрого и адекватного ответа на запросы, можно привести базу ObjectStore, функционирующей в крупной финансовой компании. Она в режиме реального времени снабжает оператора информацией о состоянии рынка инвестиций одновременно для большого числа клиентов системы (около 3000). Та же СУБД ObjectStore накапливает данные торговой сессии на Нью-Йоркской фондовой бирже. Система, которая используется на бирже, обслуживает одновременно до 1000 запросов, адресованных к базе данных, причем, клиенты сети не ощущают временных задержек. Объектные базы находят широкое применение в телекоммуникациях и глобальной сети Интернет, представляющей совокупность разнородных объектов. Это текст, рисунок, видео, звук, которые могут храниться в объектной СУБД как набор объектов, подготовленный к передаче пользователю за счет чего и достигается быстрая реакция сервера на запрос. Несмотря на свои несомненные преимущества объектных баз данных объемы их продажнамного меньше объема продаж реляционных баз. Это связано с тем, что:
• организации не уверены, что затраты, связанные с переходом на объектные базыданных, окупятся
• сопровождение реляционных баз данных не требует от администраторов БД знания языков программирования, а только языка SQL. Сегодня процесс распространения ООД носит эволюционный характер.
Компромиссными решениями, позволяющими соблюсти баланс между объектами и реляционными таблицами, являются:
• объектно-реляционный адаптер
• объектно-реляционный шлюз
• гибридные объектно-реляционные СУБД. Объектно-реляционный адаптер автоматизирует выделение и сохранение объектов в реляционных базах данных. Такой подход приводит к некоторому снижению производительности, но за то объектно-ориентированные приложение работают в обычном режиме с СУБД, а программист целиком сосредотачивается на объектно-ориентированной разработке. При этом, все имеющиеся на предприятии приложения по-прежнему могут обращаться к данным, хранящимся в реляционной форме. Объектно-реляционные шлюзы используются для обеспечения взаимодействия с реляционной базой данных при помощи языка объектной СУБД. Шлюз заменяет все объектно-ориентированные элементы языка их реляционными компонентами. Производительность при этом снова снижается. И, наконец, гибридных объектно-реляционных СУБД, являются еще одним решением, которое позволяет хранить данные как в виде реляционных таблиц, так и в виде объектов.
4.7. Техническая реализация баз данных.

По способу организации СУБД делят на
• СУБД для настольных компьютеров;
• СУБД с архитектурой файл-сервер;
• СУБД с архитектурой клиент-сервер;
• СУБД с архитектурой «тонкий клиент» – сервер приложений — сервер базы данных.
Базы данных для настольных компьютеров. 20-30 лет назад данные обрабатывались централизованно с помощью мейнфреймов. СУБД и БД размещались и функционировали на центральном компьютере, а пользователи получают доступ к базе данных при помощи обычных терминалов. Такой способ обработкиданных имеет некоторые преимущества.
1. Совместное использование ресурсов и устройств (центральный процессор,оперативная память, периферийное оборудование)
2. Централизация хранения данных. Недостатком централизованного способа обработки данных является то, что пользователи не могут устанавливать необходимое им программное обеспечение. Излишняя централизация стала одной из причин быстрого роста индустрии персональных компьютеров. ПК привлекали простотой технического обслуживания, доступной ценой и возможностью устанавливать свое ПО. Многих пользователей привлекала возможность "персонализации" рабочего пространства. Теперь каждый пользователь мог приобрести необходимое программное обеспечение. Базы данных для настольных компьютеров были очень популярными (включая dBase, FoxBASE, Paradox и ряд других) 10—15 лет назад. Эти СУБД не содержали специальных механизмов доступа к данным. Они манипулировали хранением данных, используя службы доступа к файлам операционной системы.
Базы данных с архитектурой файл-сервер. Следующим шагом в разработке баз данных настольных компьютеров стало создание их сетевых версий (они также стали называться файл-серверными базами данных). Файл-
серверные СУБД дали возможность совместно обрабатывать данные пользователям вычислительной сети. Недостатки таких СУБД не столь очевидны, поскольку они начинают проявляться лишь с ростом базы данных и числа ее пользователей. Причина заключается в том, что данные обрабатываются в пользовательских приложениях. Рассмотрим простой пример. Представим, что у вас есть 10 000 записей в таблице и из них необходимо выбрать пять (например, заказы, сделанные за последний час). Если эта таблица проиндексирована по одному определенному полю, приложение сначала получит полный индекс, найдет позицию с необходимой записью в файле базы данных, а затем получит соответствующие части этого файла. Если таблица не проиндексирована по данному полю, то приложение должно будет получить все 10 000 записей и просмотреть их, для того, чтобы найти необходимые пять записей. Следовательно, с ростом объема данных и числа пользователей также растет загрузка сети, что существенно снижает производительность приложений. Другая проблема использования файл-серверных баз данных заключается в нарушении целостности ссылок, которая обеспечивается с помощью клиентских приложений. Таким образом, во всех клиентских приложениях должен присутствовать программный код, необходимый для обеспечения целостности, и любой доступ к файлам базы данных, осуществляемый в обход данных приложений запрещен.
Базы данных с архитектурой клиент-сервер. Архитектура клиент-сервер — в некотором смысле, возврат к старой модели централизованной обработки данных, применяемой на главных компьютерах. Ядром таких систем управления базами данных является сервер базы данных, который может представлять собой приложение или службу операционной системы. Сервер базы данных отвечает за сохранение данных в файлах, создание резервных копий, поддержание целостности ссылок, представление доступа пользователю, а также за безопасность данных, ведение журнала базы данных, и, конечно же, за выполнение пользовательских запросов на изменение, создание и удаление данных. Архитектура клиент-сервер имеет следующие преимущества.
1. Нагрузка сети при выполнении запросов к базе данных не возрастает. При использовании серверов баз данных выбор последних пяти заказов из 10000 приводит к отправке этих пяти записей по сети. Все операции по их выбору выполняются сервером базы данных. Время выполнения такого запроса, конечно, зависит от того, есть ли соответствующий индекс, но во всех случаях клиентскому приложению посылается в итоге только пять записей.
2. Бизнес-правила и правила обеспечения целостности на уровне ссылок могут храниться на сервере. Они реализованы в различных объектах базы данных, содержащихся в базе данных, и специально разработанных для этих целей. Это позволяет избежать дублирования программного кода в различных клиентских приложениях.
3. Любой сервер СУБД обеспечивает безопасность данных, применяя список пользователей и предоставляя им различные привилегии при использовании объектов базы данных.
Базы данных с трехуровневой архитектурой: «тонкий клиент» –сервер приложений — сервер базы данных. Архитектура клиент-сервер не лишена недостатков. Если деловая логика взаимодействия с базой данных изменяется, то приходится заново переписывать клиентские программы. Если изменения происходят слишком часто, а количество рабочих мест велико, то постоянная переустановка программного обеспечения становится серьезной проблемой. В таких случаях следует перейти к трех-уровневой архитектуре «тонкий клиент» –сервер приложений — сервер базы данных. При такой архитектуре клиентская часть обеспечивает только взаимодействие с пользователем. А вся деловая логика вынесена на сервер приложений, который формирует запросы к базе данных и передачу их навыполнение серверу базы данных. «Тонкий клиент» находится на компьютере пользователя и чаще всего представляет WEB-браузер. Сервер приложений находится на сервере и может являться обычным WEB-
сервером. Преимущества трехуровневой архитектуры: изменения в деловой логике вносятся только один раз — на сервере приложений. Изменять клиентские программы нет никакой необходимости.
4.9. Сравнение двухуровневой и трехуровневой архитектуры клиент сервер.

В трехуровневой архитектуре уровень бизнес-сервисов соединен с уровнем сервисовданных СУБД. В четырехуровневой архитектуре абстрактное подключение к базе данных часто представляется в виде отдельного уровня, который называется уровнем сервиса доступа к данным. Другие компоненты бизнес-сервисов могут подключаться к компоненту сервисов общего доступа к данным, а сложные крупно-
зернистые бизнес-сервисы могут разбиваться на отдельные мелко-зернистые компоненты, каждый из которых ответственен за выполнение отдельной функции. Разделение компонентов сложных сервисов на такие упрощенные компоненты называется повышением зернистости. Как распределенные, так и параллельные БД — это совокупность баз данных, распределенных по компьютерной сети и способных выступать как интегрированное целое, прозрачное для пользователей. Прозрачность означает невидимость для пользователей фрагментации данных, т.е. язык запросов для распределенных или параллельных БД не отличается от языка запросов обычной (последовательной) БД. В распределенных и параллельных СУБД выделяются следующие виды параллелизма:
• межзапросный, при котором выполняется множество запросов разных транзакций;
• внутризапросный, выполняющий несколько операций, относящихся к одному запросу;
• внутриоперационный, при котором выполняются параллельно части одной операции.
Между СУБД распределенными и параллельными много общего при наличии существенного различия: В параллельной БД применяются все три вида параллелизма, а в распределенной толькопервые два.
4.9.1. Системы OLTP и OLAP.

Среди фактографических систем важное место занимают два класса:
• системы операционной обработки данных
• системы, ориентированные на анализ данных и поддержку принятия решений.
Системы операционной обработки данных рассчитаны на быстрое обслуживание относительно простых запросов большого числа пользователей. Системы операционной обработки работают с данными, которые требуют защиты от несанкционированного доступа, от нарушений целостности, от аппаратных и программных сбоев. Время ожидания выполнения типичных запросов в таких системах не должно превышать нескольких секунд. Сфера применения подобных систем - это системы платежей, резервирования мест в поездах, самолетах, гостиницах, банковские и биржевые системы. Логическая единица функционирования систем операционной обработки данных — транзакция. Транзакция - это некоторое законченное с точки зрения пользователя действие над базой данных. Для обозначения систем операционной обработки часто используют термин OLTP (On-
Line Transaction Processing - оперативная обработка транзакций или выполнение транзакций в режиме реального времени). Другой класс информационных систем — системы поддержки принятия решений (аналитические системы). Системы поддержки принятия решений ориентированы на выполнение сложных запросов, требующих статистической обработки исторических (накопленных за некоторый промежуток времени) данных, моделирования процессов предметной области, прогнозирования развития тех или иных явлений. Аналитические системы часто включают средства обработки информации на основе методов искусственного интеллекта и средства графического представления данных. Такие системы работают с большими объемами исторических данных, позволяя выделить из них содержательную информацию - получить знания из данных. Современные требования к скорости и качеству анализа привели к появлению систем оперативной аналитической обработки (OLAP - On-Line Analysis Processing). Оперативность обработки больших объемов данных в этих системах достигается за счет применения мощной, в том числе многопроцессорной, вычислительной техники, сложных методов анализа, а также специальных хранилищ данных, накапливающих информацию из различных источников за большой период времени и обеспечивающих быстрый доступ к ней. Оба класса систем основаны на СУБД, но типы выполняемых ими запросов сильно различаются. Например, в операционной системе продажи железнодорожных билетов допустим такой запрос: "Есть ли свободные места в купе поезда Москва-Сочи, отправляющегося 20 августа в 23.15?". В аналитической системе запрос может быть таким: "Каким будет объем продажи железнодорожных билетов в денежном выражении в следующих трех месяцах с учетом сезонных колебаний?". Принципиально отличаются иструктуры баз данных для высокопроизводительных операционных и аналитических систем.
Обработка транзакций в OLTP-системах. Транзакцией называют неделимую с позиции воздействия на БД последовательность операций манипулирования данными. Транзакция может состоять из операций чтения, удаления, вставки или модификации данных. В OLTP-системах транзакция реализует некоторое осмысленное с точки зрения пользователя действие, например, перевод денег со счета на счет в платежной системе банка или резервирование места в поезде системой оформления железнодорожных билетов. Традиционно понятие "обработка транзакций" использовалось применительно к крупномасштабным системам обработки данных - системам, осуществлявшим международные банковские операции и др. Теперь ситуация меняется. Информационные системы в различных областях человеческой деятельности становятся все более распределенными и неоднородными, в них остро стоят проблемы сохранения целостности данных и разграничения доступа. Одно из направлений решения этих проблем -использование средств обслуживания транзакций в информационных системах. Результатом выполнения транзакции может быть ее фиксация или откат. Фиксация транзакции - это действие, обеспечивающее запись в БД всех изменений, которые были произведены в процессе ее выполнения. До того как транзакция зафиксирована, возможна отмена всех сделанных изменений и возврат базы данных в то состояние, в котором она была до начала выполнения транзакции. Фиксация транзакции означает, что все результаты ее выполнения становятся видимыми другим транзакциям. Для фиксации транзакции необходимо успешное выполнение всех ее операторов. Если нормальное завершение транзакции невозможно, например, нарушены ограничения целостности БД или пользователь выдал специальную команду, происходит откат транзакции. База данных возвращается в исходное состояние, все изменения аннулируются. Механизм корректного отката и фиксации транзакций основан на использовании журнала транзакций. Для того чтобы иметь возможность сделать откат, СУБД должна сохранять все изменения, которые транзакция внесла в БД. Однако необходимости каждый раз сохранять всю информацию базы данных нет. Реляционные операции изменяют строки отношений БД, поэтому, чтобы обеспечить возможность отката, СУБД должна хранить те строки, которые были модифицированы. При выполнении любой операции, изменяющей базу данных, СУБД автоматически сохраняет в журнале транзакций состояние модифицируемых строк до операции и после нее. Только после этого изменения вносятся в БД. Если по окончании обработки транзакция фиксируется, то в журнале делается соответствующая отметка. Если же производится откат транзакции, то СУБД по журналу восстанавливает те строки отношений, которые были модифицированы, отменяя, таким образом, все изменения. Для того чтобы оперировать транзакцией как единой логической единицей, СУБД должна уметь определять ее границы, то есть первую и последнюю входящую в нее операции. Стандарт языка SQL предусматривает следующий принцип выделения транзакции как некоторой законченной последовательности действий. Предполагается, что транзакция начинается с первого SQL-оператора, вводимого пользователем или содержащегося в прикладной программе. Все следующие далее операторы составляют тело транзакции. Тело транзакции завершается SQL-операторами COMMIT WORK или ROLLBACK WORK. Выполнение транзакции заканчивается также при завершении программы, которая сгенерировала транзакцию. Транзакция фиксируется, если ее тело оканчивается оператором COMMIT WORK либо при успешном завершении программы, сформировавшей транзакцию. Откат транзакции производится при достижении оператора ROLLBACK WORK либо в случае, когда приложение, сгенерировавшее транзакцию, завершилось с ошибкой. Вот пример транзакции, модифицирующей телефон (атрибут Phone) сотрудника с фамилией (атрибут Name) "Петров" в отношении Отдел (Department). Транзакция завершается фиксацией по достижении оператора COMMIT WORK. UPDATE Department SET Phone = "5388" WHERE Name = "Петров" COMMIT WORK. Некоторые диалекты языка SQL, например, диалект, принятый в СУБД Sybase,включают специальные операторы, позволяющие производить промежуточную фиксацию транзакции. В теле транзакции могут быть определены точки, в которых сохраняется состояние базы данных. Откат в этом случае может производиться как к одной из точек промежуточной фиксации, так и к состоянию до начала выполнения транзакции. Точки промежуточной фиксации применяются в "длинных" транзакциях. Они позволяют разделитьих на несколько отдельных фрагментов.
Сериализация данных. Применение транзакций - эффективный механизм организации многопользовательского доступа к БД. Однако при реализации этого механизма в СУБД приходится сталкиваться с целым рядом проблем. Во-первых, необходимо избежать потери изменений БД в ситуации,когда несколько программ читают одни и те же данные, изменяют их и пытаются записать результат на прежнее место. В БД могут быть сохранены изменения, выполненные только одной программой, результаты работы всех остальных программ будут потеряны. Во-
вторых, требуется исключить возможность чтение незафиксированных изменений. Это может произойти в случае, когда одна транзакция вносит изменения в БД, и они тут же считываются в другой транзакции, но затем другая транзакция прерывается оператором ROLLBACK WORK. Чтобы решить подобные проблемы должна быть использована специальная технология совместной обработки (сериализации) транзакций. В ее основе лежат следующие принципы:
1. Транзакция не может получить доступ к незафиксированным данным, то есть к данным, в которых произведены изменения, но эти изменения еще не зафиксированы.
2. Результат совместного выполнения транзакций должен быть эквивалентен результатуих последовательного выполнения. То есть если две транзакции выполняются параллельно, то предполагается, что результат будет такой же, как если бы сначала выполнялась первая, а затем вторая транзакция, или сначала вторая, а потом первая.
В современных СУБД сериализация транзакций реализуется через механизм блокировок. На время выполнения транзакции СУБД блокирует часть БД (отношение, строку или группу строк), к которой транзакция обращается. Блокировка сохраняется до момента фиксации транзакции. Если в процессе параллельной обработки другой транзакции делается попытка обратиться к блокированным данным, обработка транзакции приостанавливается и возобновляется только после завершения транзакции, заблокировавшей данные, и снятия блокировки. При выполнении транзакции современные СУБД могут блокировать всю БД, отношение, группу строк или отдельную строку. Очевидно, что чем больше блокируемый элементданных, тем медленнее СУБД обрабатывает транзакции, поскольку велико время ожидания снятия блокировок. При работе в режиме оперативного доступа к БД, как правило, реализуется блокировка на уровне отдельных строк. В этом случае можно добиться максимальной производительности за счет того, что блокируемый объект – это минимальная структурная единица БД. Транзакции могут попасть в ситуацию взаимоблокировки. Проиллюстрируем это примером. Пусть транзакция T1 обновляет отношение О1 блокируя некоторые его строки. Далее эта транзакция пытается модифицировать данные отношения О2, которые уже заблокированы транзакцией Т2. Транзакция Т1 переводится в состояния ожидания снятия блокировки с отношения О:2. В этот же момент транзакция Т2 пытается изменить данные отношения О:1 заблокированные транзакцией Т1. СУБД вынуждена перевести в состояние ожидания и транзакцию Т2. Налицо ситуация взаимоблокировки транзакций, которая может не разрешиться, если СУБД не предпримет специальные меры. Для предотвращения таких ситуаций СУБД периодически проверяет блокировки, установленные выполняющимися транзакциями. Если обнаруживается ситуация взаимоблокировки, то одна из транзакций, вызвавших эту ситуацию, прерывается. Это позволяет выйти из тупиковых вариантов. Программа, которая сгенерировала прерванную транзакцию, получает сообщение об ошибке. Для того чтобы избежать взаимоблокировки, в каждой транзакции обновление отношений необходимо делать в одной и той же последовательности. Так, в приведенном примере следовало бы сначала изменить отношение О:1, а потом О:2. Современные информационные системы работают с распределенными БД, поэтому в одной транзакции могут модифицироваться отношения, физически хранящиеся на удаленных вычислительных системах. Транзакция, обновляющая данные на нескольких узлах сети, называется распределенной. Если транзакция работает с БД, расположенной на одном узле, то ее называют локальной. Таким образом, логически распределенная транзакция состоит из нескольких локальных. С точки зрения пользователя, локальные и распределенные транзакции должны обрабатываться одинаково, то есть СУБД должна организовать процесс выполнения распределенной транзакции так, чтобы все локальные транзакции, входящие в нее, синхронно фиксировались на затрагиваемых ими узлах распределенной системы. Однако распределенная транзакция должна фиксироваться только в случае, когда зафиксированы все локальные транзакции ее составляющие. Если прерывается хотя бы одна из локальных транзакций, должна быть прервана и распределенная транзакция. Для практической реализации этих требований в СУБД используют механизм двухстадийной фиксации транзакций (two phase commit). При этом фиксация распределенных транзакций осуществляется в два этапа (стадии).На первой стадии сервер БД, фиксирующий распределенную транзакцию, посылает команду "приготовиться к фиксации" всем узлам сети (серверам БД), задействованным для выполнения локальных транзакций, инициированных распределенной транзакцией. Все серверы локальных БД должны в ответ сообщить, что они готовы к фиксации. Если хотя бы от одного из серверов ответ не получен, например, если имела место программная или аппаратная ошибка при выполнении локальной транзакции, то сервер распределенной БД производит откат локальных транзакций на всех узлах, включая те, которые прислали оповещение о готовности к фиксации. Вторая стадия начинается, когда все локальные СУБД готовы к фиксации. Сервер, обрабатывающий распределенную транзакцию, заканчивает ее фиксацию, посылая команду "зафиксировать транзакцию" всем локальным серверам. Описанный механизм фиксации гарантирует синхронную фиксацию распределенной транзакции на всех узлах сети.
Тиражирование данных. Описанный подход выполнения транзакций в распределенных системах - не единственный возможный. Альтернатива ему - технология тиражирования данных. Эта технология предполагает отказ от распределенности данных - во всех узлах вычислительной системы должна находиться своя копия БД. Средства тиражирования автоматически поддерживают согласованное состояние информации в нескольких БД посредством копирования изменений, вносимых в любую из них. Любая транзакция в такой системе выполняется локально, поэтому нет необходимости в сложной процедуре фиксации. Узкое место такого подхода - обеспечение тождественности данных в узлах сети. Процесс переноса изменений исходной БД в базы, принадлежащие различным узлам распределенной системы, принято называть тиражированием данных. Функции тиражирования данных выполняет специальный модуль СУБД - сервер тиражирования данных (репликатор). При любых изменениях в тиражируемых данных репликатор копируетих на все остальные узлы системы. Схема тиражирования может быть построена на полном обновлении содержимого таблицы на удаленных серверах (схема с полным обновлением)или же на обновлении только изменившихся записей (быстрое обновление). Если в системе нет необходимости поддерживать постоянную идентичность данных и БД узлов должны согласовываться лишь периодически, репликатор накапливает изменения и в нужные моменты времени копирует их на другие узлы. Процесс тиражирования данных скрыт от прикладных программ пользователей, репликатор автоматически поддерживает БД в согласованном состоянии и использовании технологии тиражирования уменьшается трафик, так как все запросы обрабатываются локальной СУБД, а на другие узлы передаются только изменения в данных, увеличивается скорость доступа к данным. Кроме того, обрыв связи между узлами не останавливает обработку данных. Однако эта технология не лишена недостатков. Так, невозможно полностью исключить конфликты, возникающие при изменении одних и тех же данных на разных узлах. При вносе этих изменений в узлах вычислительной системы могут оказаться несогласованные копии БД, в результате чего пользователи различных узлов распределенной БД "будут получать разные ответы на одни ите же запросы.
Средства восстановления после сбоев. Одно из основных требований к современным OLTP-системам - надежность хранения данных. СУБД должна уметь восстанавливать согласованное состояние базы данных после любых аппаратных и программных сбоев. Для восстановления после сбоев СУБД используетжурнал транзакций, который содержит последовательность записей, описывающих изменения в БД. Общий принцип восстановления после сбоя таков - результаты выполнения транзакций, зафиксированных до сбоя, должны присутствовать в восстановленной БД, результаты незафиксированных транзакций в ней должны отсутствовать. То есть восстанавливается последнее до сбоя согласованное состояние базы данных. Процесс восстановления основан на механизме отката незавершенных транзакций, который был описан ранее. Конечно, журнал транзакций не поможет, если содержимое внешней памяти системы физически уничтожено, то есть утеряна вся информация БД. Для того чтобы избежать подобных ситуаций, реализуют дублированное хранение данных, например, зеркалирование дискового пространства - запись данных одновременно на несколько устройств. После сбоя копируется содержимое БД, а затем, как и в первом случае, на основе журнала откатываются все незавершенные транзакции. Мониторы транзакций. С ростом сложности распределенных вычислительных систем возникают проблемы эффективного использования их ресурсов. Для решения этих проблем в состав распределенных OLTP-систем вводят дополнительный компонент - монитор транзакций (ТРМ - transaction processing monitor). Мониторы транзакций выполняют две основные функции: динамическое распределение запросов в системе (выравнивание нагрузки) и оптимизацию числа выполняющихся серверных приложений. Рассмотрим эти функции. Если в системе функционирует несколько серверов, предоставляющих одинаковый сервис, например, доступ к БД, то для оптимизации пропускной способности системы (числа обрабатываемых запросов в единицу времени) необходимо добиться сбалансированной их загрузки. То есть нужно обеспечить, чтобы на каждый из них поступало примерно равное число пользовательских запросов. При распределении запросов может учитываться также удаленность сервисов, их готовность, содержимое запроса. Реализуется функция выравнивания нагрузки следующим образом: запрос клиентского приложения поступает на монитор транзакций, действуя от имени клиентского приложения, и определяет получателя этого запроса. Для этого он обращается к динамической маршрутной таблице, по которой определяет систему, предоставляющую соответствующий сервис. Если нужный сервис предлагают несколько систем, то в зависимости от используемого алгоритма маршрутизации выбирается одна из них, послe чего ей перенаправляется запрос клиентского приложения. Маршрутизация может быть произвольной, когда система выбирается случайным образом, циклической, когда запросы посылаются системам по очереди, либо определяться содержимым запроса, если, например, серверы БД обслуживают разные подмножества данных. Результат выполнения запроса через монитор транзакций перенаправляется приложению, пославшему запрос. Клиентские приложения не знают о том, какой системе будут направлены их запросы, предлагается ли нужный им сервис одним или несколькими серверами, расположен ли сервер локально, удаленно или одновременно локально и удаленно - в любом случае их запрос будет обработан оптимальным образом. Подобную схему обработки запросов называют "прозрачностью местонахождения сервисов" (service location transparency). Скорость обработки транзакций напрямую зависит от числа запущенных серверных приложений. Чем больше приложений одновременно обслуживает запросы, тем выше пропускная способность вычислительной системы. Это увеличение наиболее заметно на многопроцессорных системах, где каждое приложение может работать на отдельном процессоре. В идеале для эффективного использования системных ресурсов нужно по мере необходимости увеличивать или уменьшать число серверных приложений в зависимости от числа обрабатываемых запросов. Для решения этой задачи мониторы транзакций периодически измеряют отношение числа запросов в очереди к числу работающих серверных приложений. Если это отношение превышает некоторое максимальное пороговое значение, то запускается дополнительная копия серверного приложения. Если это отношение падает ниже минимального порогового значения (minimum watermark), то одна из копий завершается. На рынке мониторов транзакций доступно довольно много продуктов. В числе наиболее известных: TUXEDO фирмы USL, TOP END фирмы NCR, CICS фирмы IBM, ENCINA фирмы Transarc, ACMS фирмы DEC. Ключевые слова Фактографическ системы: предметная область(ПО), концептуальные средства описания, модель сущность-связь. Модели данных. Представление данных в памяти ЭВМ. Программные средства реализации фактографических ИС.
Вопросы для проверки:
1. Что называется Предметной областью?
2. Что определяет Информационно-логическая модель предметной области?
3. Что называется Информационным объектом?
4. Укажите три основных компоненты информационного объекта?
5. Что отображают Связи между информационными объектами типа 1:1 (Один- к -одному)?
6. Что отображают Связи между информационными объектами типа 1:М (Один- ко-многим)?
7. Что отображают Связи между информационными объектами типа М:М (Многие - ко -многим)?
8. Что такое Модель данных?
9. Назовите три основные компонентами модели данных?
10. При использовании иерархической модели данных какую гипотезу принимают вкачестве допущения?
11. Что представляет Иерархическая модель данных?
12. Назовите три условия, которым должна удовлетворять иерархическая структураданных
13. Достоинства иерархической модели данных?
14. Три основных недостатка иерархической модели данных?
15. Как представляется предметная область при использовании Сетевой модели данных?
16. Назовите три основные типы структур данных сетевой модели (стандарт КОДАСИЛ)?
17. Назовите основное достоинство сетевой модели данных?
18. Назовите Два основных недостатка сетевой модели данных
19. Какая структура используется в реляционных модели данных?
20. Какие два фундаментальных механизма манипулирования реляционной базой данных утверждаются в манипуляционной части модели
21. Реляционная модель данных представляется в виде?
22. Что называется доменом, кортежем, степенью отношений 40?
23. Таблица реляционной модели данных находится в первой нормальной форме?
24. Таблица реляционной модели данных находится во второй нормальной форме?
25. Что означает в реляционной модели данных полная функциональная зависимость?
26. Таблица реляционной модели данных находится в третьей нормальной форме?
27. Язык манипулирования реляционными БД называется реляционно-полным?
28. Какие группы правил целостности выделяют в реляционной модели данных?
29. Что такое объект?
30. Что такое атрибут (свойство) объекта?
31. Что такое первичный ключ, внешний ключ? Требования к первичному ключу?Суррогатный ключ?
32. Какие операции нужно выполнить, чтобы преобразовать таблицу из первой нормальной формы во вторую?
33. Какие операции нужно выполнить, чтобы преобразовать таблицу из второй нормальной формы во третью?
34. В чем заключается требование целостности по сущностей? В чем заключается требование целостности по ссылкам? Какие виды правил ссылочной целостности вы знаете?
35. Что называют индексом в реляционных базах данных? Что такое сопровождаемые индексы? Какие поля в БД не могут быть проиндексированы?
36. Что представляют из себя такие компоненты БД как представление и курсор?
37. Что такое хранимая процедура и триггер?
38. Для чего предназначены в БД такие компоненты как пользователи и роли?
39. Что такое транзакция? Требования к транзакции?
40. Почему SQL относят к непроцедурным языкам?
41. Основные отличия объектных БД от всех других?
42. Что такое распределенные и параллельные базы данных?
43. Базы данных с архитектурой клиент-сервер?
44. Преимущества архитектуры клиент/сервер?
45. Базы данных с архитектурой тонкий клиент- сервер приложений – сервер базыданных?
46. Недостатки двух-уровневой архитектуры клиент-сервер?
47. Трехуровневая архитектуре «тонкий клиент» – сервер приложений — сервер базыданных? Преимущества перед двухуровневой?
48. Четырехуровневая архитектура клиент/сервер. Преимущества?
49. Назначение и область применения систем операционной обработки данных OLTP(On-Line Transaction Processing)?
50. Системы оперативной аналитической обработки (OLAP - On-Line AnalysisProcessing)? Основные отличия от OLTP систем?
51. Что такое транзакция?
52. Основные свойства транзакций?
53. Основные проблемы, возникающие при реализации механизма транзакций в СУБД?
54. Основные принципы сериализации как технологии совместной обработкитранзакций?
55. Как в современных СУБД реализуется технология сериализация транзакций?
56. Какие транзакции называются локальными, какие — распределенными?
57. Как организуется процесс выполнения распределенной транзакции в СУБД прииспользовании технологии сериализации?
58. В чем суть технологии тиражирования данных как технологии совместной обработки транзакций?
59. Достоинства технологии тиражирования данных?
60. Недостатки технологии тиражирования данных?
61. Репликатором является?
62. Каков общий принцип восстановления данных после сбоя?
63. Основные функции монитор транзакций?

Дата добавления: 2015-10-29