Дипломная работа: Інформаційна система "Облік мобільних терміналів"

СУБД звичайно працюють із БД значного розміру; принаймні цей розмір звичайно істотно більше доступного обсягу оперативної пам'яті. Зрозуміло, що якщо при звертанні до будь-якого елемента даних буде вироблятися обмін із зовнішньою пам'яттю, те вся система буде працювати зі швидкістю пристрою зовнішньої пам'яті. Практично єдиним способом реального збільшення цієї швидкості є буферiзація даних в оперативній пам'яті. При цьому, навіть якщо операційна система робить загальносистемну буферiзацію (як у випадку ОС UNIX), цього недостатньо для цілей СУБД, що має у своєму розпорядженні набагато більшу інформацію про корисність буферiзації тієї чи іншої частини БД. Тому в розвитих СУБД підтримується власний набір буферів оперативної пам'яті з власною дисципліною заміни буферів.

Транзакція – це послідовність операцій над БД, розглянутих СУБД як єдине ціле. Або транзакція успішно виконується, і СУБД фіксує зміни БД, зроблені цієї транзакцією, у зовнішній пам'яті, або жодне з цих змін ніяк не відбивається на стані БД. Поняття транзакції необхідно для підтримки логічної цілісності БД. Таким чином, підтримка механізму транзакцій є обов'язковою умовою навіть одно користувальницьких СУБД (якщо, звичайно, така система заслуговує назви СУБД). Але поняття транзакції набагато більш важливо в багатокористувачевих СУБД.

Та властивість, що кожна транзакція починається при цілісному стані БД і залишає цей стан цілісним після свого завершення, робить дуже зручним використання поняття транзакції як одиниці активності користувача стосовно БД. При відповідному керуванні паралельно виконуються транзакціями з боку СУБД кожний з користувачів може в принципі відчувати себе єдиним користувачем СУБД (насправді, це трохи ідеалізоване представлення, оскільки в деяких випадках користувачі багатокористувачевих СУБД можуть відчути присутність своїх колег). З керуванням транзакціями у багатокористувачевій СУБД зв'язані важливі поняття сериалізації транзакцій і серіального плану виконання суміші транзакцій. Під сериализації паралельно виконуються транзакції, розуміється такий порядок планування їхньої роботи, при якому сумарний ефект суміші транзакцій еквівалентний ефекту їх деякого послідовного виконання. Сериальний план виконання суміші транзакцій – це такий план, що приводить до сериализації транзакцій. Зрозуміло, що якщо вдається домогтися дійсно сериального виконання суміші транзакцій, те для кожного користувача, з ініціативи якого утворена транзакція, присутність інших транзакцій буде непомітно (якщо не вважати деякого уповільнення роботи з порівняння з однокористувачевим режимом).

У централізованих СУБД найбільш поширені алгоритми, засновані на синхронізаційних захопленнях об'єктів БД. При використанні будь-якого алгоритму сериализації можливі ситуації конфліктів між двома чи більш транзакціями по доступі до об'єктів БД. У цьому випадку для підтримки сериализації необхідно виконати відкіт (ліквідувати всі зміни, зроблені в БД) одній чи більш транзакцій. Це один з випадків, коли користувач багатокористувачевої СУБД може реально (і досить неприємно) відчути присутність у системі транзакцій інших користувачів.

Одним з основних вимог до СУБД є надійність збереження даних у зовнішній пам'яті. Під надійністю збереження розуміється те, що СУБД повинна могти відновити останній погоджений стан БД після будь-якого апаратного чи програмного збою. Звичайно розглядаються два можливих види апаратних збоїв: так називані м'які збої, які можна трактувати як раптову зупинку роботи комп'ютера (наприклад, аварійне вимикання електоструму), і тверді збої, характеризуючі втратою інформації на носіях зовнішньої пам'яті. Прикладами програмних збоїв можуть бути: аварійне завершення роботи СУБД (через помилку в чи програмі в результаті деякого апаратного збою) чи аварійне завершення користувальницької програми, у результаті чого деяка транзакція залишається незавершеної. Першу ситуацію можна розглядати як особливий вид м'якого апаратного збою; при виникненні останньої потрібно ліквідувати наслідку тільки однієї транзакції.

Зрозуміло, що в будь-якому випадку для відновлення БД потрібно мати деяку додаткову інформацію. Іншими словами, підтримка надійності збереження даних у БД вимагає надмірності збереження даних, причому та частина даних, що використовується для відновлення, повинна зберігатися особливо надійно. Найбільш розповсюдженим методом підтримки такої надлишкової інформації є ведення журналу змін БД.

Журнал – це особлива частина БД, недоступна користувачам СУБД і підтримувана з особливою старанністю (іноді підтримуються дві копії журналу, розташовувані на різних фізичних дисках), у яку надходять записи про всі зміни основної частини БД. У різних СУБД зміни БД журналізуються на різних рівнях: іноді запис у журналі відповідає деякої логічної операції зміни БД (наприклад, операції видалення рядка з таблиці реляційної випереджаєймої БД), іноді – мінімальної внутрішньої операції модифікації сторінки зовнішньої пам'яті; у деяких системах одночасно використовуються обидва підходи.

В усіх випадках дотримують стратегії запису, що випереджає, у журнал (так називаного протоколу Write Ahead Log – WAL). Грубо говорячи, ця стратегія полягає в тім, що запис про зміну будь-якого об'єкта БД повинна потрапити в зовнішню пам'ять журналу раніш, ніж змінений об'єкт потрапить у зовнішню пам'ять основної частини БД. Відомо, що якщо в СУБД коректно дотримується протокол WAL, те за допомогою журналу можна вирішити всі проблеми відновлення БД після будь-якого збою.

Найпростіша ситуація відновлення – індивідуальний відкіт транзакції. Строго говорячи, для цього не потрібно загальносистемний журнал змін БД. Досить для кожної транзакції підтримувати локальний журнал операцій модифікації БД, виконаних у цієї транзакції, і робити відкіт транзакції шляхом виконання зворотних операцій, випливаючи від кінця локального журналу. У деяких СУБД так і роблять, але в більшості систем локальні журнали не підтримують, а індивідуальний відкіт транзакції виконують по загальносистемному журналі, для чого всі записи від однієї транзакції зв'язують зворотним списком (від кінця до початку).

При м'якому збої в зовнішній пам'яті основної частини БД можуть знаходитися об'єкти, модифіковані транзакціями, що не закінчилися до моменту збою, і можуть бути відсутні об'єкти, модифіковані транзакціями, що до моменту збою успішно завершилися (через використання буферів оперативної пам'яті, уміст яких при м'якому збої пропадає). При дотриманні протоколу WAL у зовнішній пам'яті журналу повинні гарантовано знаходитися запису, що відносяться до операцій модифікації обох видів об'єктів. Метою процесу відновлення після м'якого збою є стан зовнішньої пам'яті основної частини БД, що виникло б при фіксації в зовнішній пам'яті змін усіх що завершилися транзакції і яке не містило б ніяких слідів незакінчених транзакцій. Для того, щоб цього домогтися, спочатку роблять відкіт незавершених транзакцій (undo), а потім повторно відтворюють (redo) ті операції завершених транзакцій, результати яких не відображені в зовнішній пам'яті.

Для відновлення БД після твердого збою використовують журнал і архівну копію БД. Грубо говорячи, архівна копія – це повна копія БД до моменту початку заповнення журналу (мається багато варіантів більш гнучкого трактування змісту архівної копії). Звичайно, для нормального відновлення БД після твердого збою необхідно, щоб журнал не пропав. Як уже відзначалося, до схоронності журналу в зовнішній пам'яті в СУБД пред'являються особливо підвищені вимоги. Тоді відновлення БД полягає в тому, що виходячи з архівної копії по журналі відтворюється робота всіх транзакцій, що закінчилися до моменту збою. У принципі, можна навіть відтворити роботу незавершених транзакцій і продовжити їхню роботу після завершення відновлення. Однак у реальних системах це звичайно не робиться, оскільки процес відновлення після твердого збою є досить тривалим.

Важливе значення для організації ефективного керування неструктурованими документами мають методи зберігання інформації, навігації, пошуку й фільтрації документів.

Документи можуть зберігатися просто у файловій системі, і при цьому система каталогів служить засобом групування й навігації в сховище документів. У сучасних ОС типу Wіndows 95 є можливість завдання довгих імен каталогів і файлів як назви папок і документів, а також є відповідні засоби пошуку файлів по їхніх параметрах.

Ряд систем, заснованих на електронній пошті, зберігають документи в поштових скриньках у вигляді поштових повідомлень із приєднаними файлами. Навігація в сховищі спрощується за допомогою вкладених папок особистого й колективного користування. Однак у таких системах пошук і фільтрація обмежені лише відбором і сортуванням документів по атрибутах і тексту поштового повідомлення.

Специфічний метод зберігання реалізований у пакеті Lotus Notes у вигляді так називаної бази документів. База документів може зберігати як однотипну так і різнотипну інформацію у вигляді одного файлу. Документи допускають внутрішню структуризацію на основі формулярів шляхом виділення й додавання полів у документі. Навігацію в базі документів спрощує наявність сторінок баз документів і категорій документів. Поштові повідомлення також зберігаються у вигляді бази документів, файли довільного виду допускається приєднувати до текстових документів.

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

Пошук і фільтрація документів виробляється по запитах на основі контекстного пошуку: по атрибутах, по ключових словах і по повному змісті тексту на основі індексу. При використанні механізму чіткого пошуку (наприклад, DOCS OPEN) у запиті не повинне бути орфографічних помилок, а в тексті документа – помилок розпізнавання. При цьому може морфологічний розбір дозволяє спростити.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8