Адміністрування бази даних

План

Введення

1.Адміністратор бази даних - основні поняття

1.1 Поняття, класифікація та функції адміністратора бази даних

1.2 Обов'язки, зв'язку та засоби адміністратора сучасних систем управління базами даних

2.Адміністрірованіе бази даних

2.1 Управління даними в базах даних

2.3 Управління безпекою в СУБД

Висновок

Глосарій

Бібліографічний список

Додаток 1

Додаток 2

Додаток 3

Введення

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

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

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

Проблема дослідження «Адміністрування бази даних» полягає в можливості дати вичерпні відповіді на поставлені питання: що являє собою адміністрування бази даних, в чому полягають його основні функції і завдання, його значення для стабільної та ефективної роботи бази даних.

Актуальність дослідження «Адміністрування бази даних» безсумнівна. Можна провести аналогію між адміністратором баз даних і ревізором підприємства. Ревізор захищає ресурси підприємства, які називаються грошима, а адміністратор - ресурси, які називаються даними. Не можна розглядати адміністратора баз даних тільки як кваліфікованого технічного спеціаліста, так як це не відповідає цілям адміністрування. Рівень адміністратора баз даних в ієрархії організації досить високий: щоб визначати структуру даних і право доступу до них, адміністратор повинен знати, як працює підприємство і як використовуються відповідні дані.

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

Мета дослідження полягає у вивченні адміністрування бази даних

Завдання дослідження формуються виходячи з його мети і полягають у наступному: 1. Розглянути поняття, класифікацію та функції адміністратора бази даних. 2.Рассмотреть обов'язки, зв'язку та засоби адміністратора сучасних систем управління базами даних. 3.Ізучіть основні напрямки та принципи адміністрування бази даних.

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

Практична значимість дослідження полягає в його можливе використання при вивченні інформаційних технологій у вищих навчальних закладах.

1.Адміністратор бази даних - основні поняття

1.1 Поняття, класифікація та функції адміністратора бази даних

Функціонування бази даних (БД) неможливо без участі фахівців, які забезпечують створення, функціонування і розвиток бази даних. Така група фахівців називається адміністратором бази даних (АБД). Ця група фахівців вважається складовою частиною бази даних.

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

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

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

Адміністратори бази даних виконують велике коло різноманітних функцій:

1. Аналіз предметної області: опис предметної області, виявлення обмежень цілісності, визначення статусу інформації, визначення потреб користувачів, визначення статусу користувачів, визначення відповідності «дані - користувач», визначення об'ємно-часових характеристик обробки даних.

2. Проектування структури бази даних: визначення складу і структури інформаційних одиниць, що складають базу даних, завдання зв'язків між ними, вибір методів впорядкування даних і методів доступу до інформації, опис структури БД мовою обробки даних (ЯОД).

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

4. Первісна завантаження та ведення бази даних: розробка технології первинного завантаження та проведення (зміни, доповнення, видалення записів) БД, проектування форм введення, створення програмних модулів, підготовка вихідних даних, введення та контроль введення.

5. Захист даних від несанкціонованого доступу:

- Забезпечення парольного входу в систему: реєстрація користувачів, призначення і зміна паролів;

- Забезпечення захисту конкретних даних: визначення прав доступу груп користувачів і окремих користувачів, визначення допустимих операцій над даними для окремих користувачів, вибір / створення програмно-технологічних засобів захисту даних; шифрування інформації з метою захисту даних від несанкціонованого використання;

- Тестування засобів захисту даних;

- Фіксація спроб несанкціонованого доступу до інформації;

- Дослідження виникають випадків порушення захисту даних і проведення заходів щодо їх запобігання.

6. Захист даних від руйнувань. Одним із способів захисту від втрати даних є резервування. Використовується як при фізичному псування файлу, так і у випадку, якщо в БД внесені небажані незворотні зміни.

7. Забезпечення відновлення БД: розробка програмно-технологічних засобів відновлення БД, організація ведення системних журналів.

8. Аналіз звернень користувачів до БД: збір статистики звернень користувачів до БД, її збереження та аналіз (хто з користувачів, до якої інформації, як часто звертався, які виконував операції, час виконання запитів, аналіз причин безуспішних (в т.ч. і аварійних) звернень до БД.

9. Аналіз ефективності функціонування бази даних і розвиток системи: аналіз показників функціонування системи (час обробки, обсяг пам'яті, вартісні показники), реорганізація та реструктуризація баз даних, зміна складу баз даних, розвиток програмних і технічних засобів.

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

11. Підготовка і підтримка системних програмних засобів: збір і аналіз інформації про СУБД і інших прикладних програм, придбання програмних засобів, їх установка, перевірка працездатності, підтримка системних бібліотек, розвиток програмних засобів.

12. Організаційно-методична робота: вибір чи створення методики проектування БД, визначення цілей і напрямів розвитку системи, планування етапів розвитку бази даних, розробка і випуск організаційно-методичних матеріалів.

Класифікація АБД

Існує кілька видів адміністраторів БД, а їх обов'язки цілком можуть відрізнятися від компанії до компанії. Ось характеристики деяких типів АБД і займаних ними положень:

Оперативні (operational) АБД:

маніпулюють дисковим простором

спостерігають за поточною продуктивністю системи

реагують на виникаючі несправності БД

оновлюють системне ПЗ та ПЗ бази даних

контролюють структурні зміни БД

запускають процедури резервного копіювання даних

виконують відновлення даних

створюють і керують тестовими конфігураціями БД

Тактичні (tactical) АБД:

реалізують схеми розміщення інформації

затверджують процедури резервного копіювання і відновлення даних;

розробляють і впроваджують структурні елементи БД: таблиці, стовпці, розміри об'єктів, індексацію і т.п.;

сценарії (scripts) зміни схеми БД;

конфігураційні параметри БД

затверджують план дій у випадку аварійної ситуації

Стратегічні (strategic) АБД:

вибирають постачальника БД

встановлюють корпоративні стандарти даних

впроваджують методи обміну даних в рамках підприємства

визначають корпоративну стратегію резервування та відновлення даних

встановлюють корпоративний підхід до ліквідації наслідків аварії та забезпечення доступності даних

Старші (senior) АБД:

досконально знають свій персонал

користуються високим попитом

можуть написати скрипт, що звільнить їх із замкненого скрині, кинутого в океан, і надзвичайно пишаються своїми творами

витрачають багато часу на підготовку молодших АБД

дуже цінуються керівництвом і отримують шалені гроші

Молодші (junior) АБД:

мріють стати старшим АБД

не дуже сильні в написанні скриптів

мають велику схильність до використання засобів управління БД

теж непогано отримують

Прикладні (application) АБД:

в курсі інформаційних потреб компанії

допомагають в розробці прикладних завдань

відповідають за розробку схеми та її зміни

разом з системним АБД забезпечують належний рівень резервування / відновлення даних

займаються побудовою тестових БД

Системні (system) АБД:

відповідають за все необхідне для резервування та відновлення даних

контролюють продуктивність системи в цілому

здійснюють пошук і усунення несправностей

в курсі нинішніх та майбутніх потреб БД в плані ємності

в курсі поточного стану та потреб БД

Наймані (contract) АБД:

запрошуються під конкретну задачу або в якості консультантів

передають персоналу необхідні знання

фіксують свої дії!

повинні добре розбиратися у відповідній області

гарні в якості тимчасового персоналу, для оцінки проекту або системи

Адміністратори-керівники:

проводять щотижневі наради

визначають перелік першочергових завдань

встановлюють і оголошують офіційний курс і стратегію

затверджують і коректують посадові інструкції і список обов'язків

стежать за наявністю відповідної документації

1.2 Обов'язки, зв'язку та засоби адміністратора сучасних систем управління базами даних

Оскільки система баз даних може бути дуже великий і може мати багато користувачів, повинно існувати особа або група осіб, які керують цією системою. Така особа називається адміністратором бази даних (АБД).

У будь-якій базі даних повинен бути хоча б одна людина, що виконує адміністративні обов'язки; якщо база даних велика, ці обов'язки можуть бути розподілені між кількома адміністраторами.

До обов'язків адміністратора можуть входити:

інсталяція і оновлення версій сервера і прикладних інструментів

розподіл дискової пам'яті і планування майбутніх вимог системи до пам'яті

створення первинних структур пам'яті в базі даних (табличних просторів) у міру проектування додатків розробниками додатків

створення первинних об'єктів (таблиць, уявлень, індексів) в міру проектування додатків розробниками

модифікація структури бази даних відповідно до потреб додатків

зарахування користувачів і підтримка захисту системи

дотримання ліцензійної угоди

управління і відстеження доступу користувачів до бази даних

відстеження та оптимізація продуктивності бази даних

планування резервного копіювання і відновлення

підтримання архівних даних на пристроях зберігання інформації

здійснення резервного копіювання і відновлення

звернення до корпорації за технічним супроводом

У деяких випадках база даних повинна також мати одного або кількох співробітників служби безпеки. Співробітник служби безпеки головним чином відповідає за реєстрацію нових користувачів, управління і відстеження доступу користувачів до бази даних, і захист бази даних.

Розробники додатків

В обов'язки розробника додатків входить:

проектування і розробка додатків бази даних

проектування структури бази даних відповідно до вимог додатків

оцінка вимог пам'яті для програми

формулювання модифікацій структури бази даних для програми

передача вищезгаданої інформації адміністратора бази даних

настройка програми в процесі його розробки

установка заходів по захисту додатки в процесі його розробки

У процесі своєї діяльності адміністратор бази даних взаємодіє з іншими категоріями користувачів банку даних, а також і з «зовнішніми» фахівцями, які не є користувачами бази даних.

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

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

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

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

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

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

Адміністратори бази даних взаємодіють і з зовнішніми по відношенню до нього групами фахівців і, перш за все, постачальниками СУБД і ППП, адміністраторами інших баз даних.

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

На ефективність роботи бази даних впливають безліч зовнішніх і внутрішніх факторів. Зростання складності і масштабів бази даних, висока «ціна» неправильних або запізнілих рішень з адміністрування БД, високі вимоги до кваліфікації фахівців роблять актуальною завдання використання розвинених засобах автоматизованого (або навіть автоматичного) адміністрування бази даних.

Засоби адміністрування включені до складу всіх СУБД. Особливо розвинені ці кошти в корпоративних СУБД. Крім того, з'явився цілий клас спеціалізованого програмного забезпечення: кошти DBA (DataBase Administration - адміністрування бази даних).

Типові функції засобів DBA представлені в Додатку (див. Додаток 1).

2.Адміністрірованіе бази даних

2.1 Управління даними в базах даних

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

Існує безліч різних способів організації зовнішньої пам'яті баз даних. Як і всі рішення, прийняті при організації баз даних, конкретні методи організації зовнішньої пам'яті необхідно вибирати в тісному зв'язку з усіма іншими рішеннями.

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

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

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

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

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

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

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

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

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

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

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

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

2.3 Управління безпекою в СУБД

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

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

Захисту підлягають не тільки дані; в базі даних порушення в захисті можуть вплинути на інші частини системи, що спричинить за собою руйнування і бази даних. Тому захист баз даних охоплює і обладнання, і програмне забезпечення, і персонал, і, власне, дані.

Таким чином, захист баз даних передбачає запобігання будь-яких навмисних і ненавмисних загроз з використанням комп'ютерних та некомп'ютерних засобів контролю. Слід також захищати: сучасні інформаційні системи; глобальну зв'язаність (вихід в Internet); різнорідність (різні платформи); технологію «клієнт-сервер». (Див. Додаток 3).

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

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

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

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

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

Привілеї в СУБД можуть бути розділені на дві категорії: привілеї безпеки і привілеї доступу. Привілеї безпеки дозволяють виконувати адміністративні дії, привілеї доступу визначають права доступу суб'єктів до певних об'єктів.

До виконання процедури присвоєння привілеїв їх необхідно створити.

Привілеї можна підрозділити відповідно до видів об'єктів, до яких вони відносяться: таблиці і подання, процедури, бази даних сервер бази даних. Стосовно до таблиць можуть бути визначені такі права доступу: право на вибірку, видалення, оновлення, додавання, право на використання зовнішніх ключів, які посилаються на цю таблицю. За замовчуванням користувач не має жодних прав доступу ні таблиць, ні до вистав. По відношенню до процедур можна надати право на їх виконання, однак при цьому не вказуються привілеї на право доступу до об'єктів, оброблюваним процедурами. Це дозволяє виділяти неконтрольований доступ для виконання суворо певних операцій над даними. По відношенню до бази даних виділяються права насправді є заборонними: обмеження на число операцій введення / виводу рядків, кількість рядків, що повертається одним запитом.

Оператор дозволяє реалізувати наступні види обмежень доступу:

операційні обмеження (за рахунок прав доступу операторів вибірки, вставки, видалення і оновлення, які застосовуються до всіх або окремих стовпцях таблиці);

обмеження за значеннями (за рахунок механізму уявлень);

обмеження на ресурси (за рахунок привілеїв до баз даних).

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

Управління доступом базується на реалізації наступного мінімального набору дій: довільне керування доступом; забезпечення безпеки повторного використання об'єктів; використання міток безпеки; примусове управління доступом.

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

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

Головне достоїнство застосування довільного керування доступом - гнучкість, однак такі супутні характеристики як рассредоточенность управління і складність централізованого контролю створюють чимало проблем для забезпечення безпеки даних.

Як доповнення до засобів управління доступу можна віднести безпеку повторного використання об'єктів, яка має гарантуватися для областей оперативної пам'яті, зокрема, для буферів з образами екрану, розшифрованими паролем, для магнітних носіїв. Слід звернути увагу і на забезпечення безпеки повторного використання суб'єктів. Це означає позбавлення прав для входу в інформаційну систему всіх користувачів, які залишили організацію.

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

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

Мітка безпеки складається з двох частин: рівня секретності і списку категорій. Перша складова залежить від програми і в стандартному варіанті може виглядати як спектр значень від «цілком таємно» до «несекретні». Друга складова дозволяє описати предметну область, розділяючи інформацію «по відсіках», що сприяє кращій захищеності. Мітки безпеки рядків таблиця неявно додаються до кожного рядка реляційного відносини.

Кожен користувач також отримує і власну мітку безпеки, яка визначає ступінь його благонадійності. Користувач отримує доступ до даних, якщо ступінь його благонадійності відповідає вимогам відповідної мітки безпеки, а саме: рівень секретності користувача повинен бути не нижче рівня секретності даних; набір категорій, заданих в мітці безпеки даних, повинен цілком знаходитися в мітці безпеки користувача.

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

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

Підтримка цілісності. Забезпечення цілісності даних не менш важливе завдання, ніж управління доступом. Головними ворогами баз даних є помилки обладнання, адміністраторів, прикладних програм і користувачів, а не зловмисників. З точки зору користувачів СУБД, основними засобами підтримки цілісності даних є: обмеження; правила.

Обмеження можуть підтримуватися безпосередньо в рамках реляційної моделі даних, а можуть задаватися в процесі створення таблиці. Табличні обмеження можуть ставитися до групи стовпців, окремим атрибутам. Посилальні обмеження відповідають за підтримання цілісності зв'язків між таблицями. Обмеження накладаються власником таблиці і впливають на результат наступних операцій з даними. Обмеження є статичним елементом підтримання цілісності, тому що вони або дозволяють виконувати дія чи ні.

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

Протоколювання і аудит. Аудит - перевірка того, чи всі передбачені кошти управління задіяні і відповідають рівню захищеності встановленим вимогам. Такий захід як протоколювання й аудит полягає в наступному: виявлення незвичайних і підозрілих дій користувачів та ідентифікація осіб, які вчинили ці дії, оцінка можливих наслідків відбувся порушення, надання допомоги; організація пасивного захисту інформації від нелегальних дій користувача: підтримка точності даних, що вводяться; підтримка документації в активному вигляді; коректне тестування користувачів.

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

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

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

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

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

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

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

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

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

Висновок

На підставі проведеного дослідження «Адміністрування баз даних» можна зробити наступні висновки.

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

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

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

Адміністратор БД повинен вміти визначати вузькі місця системи, що обмежують її продуктивність, налаштовувати SQL і програмне забезпечення СУБД і володіти знаннями, необхідними для вирішення питань оптимізації швидкодії БД.

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

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

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

Таким чином, можна зробити певні узагальнення.

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

Надійність і достовірність - це ключові поняття в діяльності адміністратора бази даних. Він повинен уміти вести ретельне документування всіх дій з управління базою даних.

Глосарій

Бібліографічний список

1.Веретеннікова Є.Г., Патрушіна С.М., Савельєва Н.Г. Інформатика: Навчальний посібник. Серія «Навчальний курс»,-М., 2002.

2.Гуде С.В., Ревін С.Б. Інформаційні системи. Навчальний посібник. -М., 2002.

3.Дунаев С. Доступ до баз даних і техніка роботи в мережі. Практичні прийоми сучасного програмування. - М., 2005.

4.Інформатіка: Підручник / Каймін В.А., 2-е вид. перераб. і доп. - М: Инфра-М., 2002.

5.Інформатіка: Підручник / За ред. Н. В. Макарової, 3-е изд., Перераб. і доп. - М.: Фінанси і статистика, 2001.

6.Інформатіка: Підручник для вузів / Острейковскій В.А., М: Вища школа, 2001.

7.Інформатіка: Підручник для вузів / Козирєв А.А. - СПб., 2002.

8.Мейер Д. Теорія реляційних баз даних: пров. з англ. - М., 2005.

9.Ревунков Г.І., Самохвалов Е.Н., Чистов В.В. Бази і банки даних і знань. Підручник для вузів / / Під ред. В. Н. Четверікова. - М., 2003.

10.Фаронов В.В., Шумаков П.В. Керівництво розроблювача баз даних. - М.: Нолидж, 2000.

11.Фундаментальние основи інформатики: соціальна інформатика.: Навчальний посібник для вузів / Колін К.К. - М.: Академ.проект: Ділова книга Єкатеринбург, 2000.

Додаток 1

Таблиця 1. - Типові функції засобів DBA

Додаток 2

Рис.1 - Узагальнена структура системи управління базою даних

Додаток 3

Рис.1 - Архітектура «клієнт-сервер»