42. Адміністратор бд і його функції.

9.5. Адміністратор бд і його функції

Керує БнД адміністратор бази даних (АБД).

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

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

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

Функції АБД:

• вирішувати питання організації даних про об'єкти ПО та встановлення зв'язків між цими даними з метою об'єднання інформації про різні об'єкти; погоджувати подання користувачів;

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

• питання розширення БД у зв'язку зі зміною кордонів ПО;

• захист даних від некомпетентного використання, від збоїв технічного забезпечення, визначення ступеня секретності частини інформації та розмежування доступу до даних;

• ведення довіднику даних, контроль надмірності й суперечливості, достовірність;

• методи зберігання даних, шляхи доступу до них, зв'язків між даними, форматів даних, визначати ступінь впливу змін даних на всю БД;

• координація питань технічного забезпечення системи;

• координація роботи системних програмістів, які розробляють додатки ПО для поліпшення експлуатаційних характеристик системи;

• координація роботи прикладних програмістів, які розробляють нові прикладні програми в рамках складу ПО системи.

43. Довідник даних.

9.6. Довідник даних

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

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

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

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

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

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

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

44. 2-х та 3-х рівневі архітектури БнД.

9.7. 2-х та 3-х рівневі архітектури БНД

ІС може мати ахітектуру:

• 2-х рівнева;

• 3-х рівнева.

В 2-х рівневій архітектурі локальних моделей немає. І прикладний програміст, і користувач можуть працювати зі всією МД. Це погано, тому що повинно бути повне розділення даних між користувачами.

Ми створюємо системи з 3-х рівневою архітектурою, тому що МД орієнтована на кінцевих користувачів (є локальні моделі, які орієнтовані на конкретного користувача). Така архітектура дає можливість виділити локальну модель для кожної категорії користувачів. У користувача зазвичай кількість таблиць менше за 20, а сама ІС може містити сотні таблиць (наприклад, в ERP SAP R/3 більше за 15 тисяч таблиць). І якщо потрібно щось змінити для заданого користувача, тоді при 2-х рівневій структурі це зробити складно.