Тема 2 архітектура бази даних
Фізична і логічна незалежність
В процесі наукових досліджень, присвячених тому, як саме повинна бути влаштована СУБД, пропонувалися різні способи реалізації. Найжиттєздатнішою з них виявилася запропонована американським комітетом із стандартизації ANSI трирівнева система організації БД, зображена на рис.2.1
Рис. 2.1 - Трирівнева модель СУБД, запропонована ANSI.
Рівень зовнішніх моделей - самий верхній рівень, де кожна моделей має своє бачення даних. Цей рівень визначає точку зору на БД окремих додатків. Кожен додаток бачить і обробляє тільки ті дані, які необхідні саме цьому додатку.
Концептуальний рівень - центральна ланка, що управляє; тут база даних представлена в найбільш загальному вигляді, який об'єднує дані, використовувані всіма додатками, що працюють з даною базою даних. Фактично концептуальний рівень відображає узагальнену модель предметної області (об'єктів реального світу), для якої створювалася база даних. Як будь-яка модель, концептуальна модель відображає тільки істотні, з погляду обробки, особливості об'єктів реального світу.
Фізичний рівень - власне дані розташовані у файлах або в сторінкових структурах, розташованих на зовнішніх носіях інформації.
Ця архітектура дозволяє забезпечити логічну (між рівнями 1 і 2) і фізичну (між рівнями 2 і 3) незалежність при роботі з даними. Логічна незалежність припускає можливість зміни одного додатку без коректування інших додатків, що працюють з цією ж базою даних.
Фізична незалежність припускає можливість перенесення інформації, що зберігається, з одних носіїв на інші при збереженні працездатності всіх додатків, що працюють з даною базою даних. Це саме те, чого не вистачало при використанні файлових систем.
Виділення концептуального рівня дозволило розробити апарат централізованого управління базою даних.
Процес проходження призначеного для користувача запиту
БМД - база метаданих. Тут зберігається вся інформація про використовувані структури даних, логічну організацію, права доступу, фізичне розташування даних.
Рис. 2.2 – Процес проходження запиту користувача
1 - Користувач посилає СУБД запит на отримання даних з БД.
2,3 - Аналіз прав користувача і зовнішньої моделі даних, відповідних даному користувачу; підтвердження або заборона доступу даного користувача до запитаних даних. У разі заборони на доступ до даних СУБД повідомляє користувача про це (стрілка 12) і припиняє подальший процес обробки даних.
4,5 - СУБД визначає частину концептуальної моделі, яка зачіпається запитом користувача і одержує інформацію про запитану частину.
6,7 - СУБД запрошує інформацію про місцеположення даних на фізичному рівні і одержує це місцеположення в термінах ОС.
8 - СУБД просить ОС надати необхідні дані, використовуючи засоби ОС.
9 - ОС здійснює перекачування інформації з пристроїв зберігання і пересилає її в системний буфер.
10 - ОС оповіщає СУБД про закінчення пересилки.
11 - СУБД вибирає з доставленої інформації, що знаходиться в системному буфері, тільки те, що потрібне користувачу, і пересилає ці дані в робочу область користувача.
Чи завжди запит проходит повний цикл? Звичайно, ні. СУБД володіє досить розвиненим інтелектом, який дозволяє їй не повторювати безглуздих дій. І тому, наприклад, якщо цей же користувач повторно звернеться до СУБД з новим запитом, то для нього вже не перевірятимуться зовнішня модель і права доступу, а якщо подальший аналіз запиту покаже, що дані можуть знаходитися в системному буфері, то СУБД здійснить лише 11 і 12 кроки в обробці запиту. Зрозуміло, механізм проходження запиту в реальних СУБД набагато складніший, але і ця спрощена схема показує, наскільки серйозними і складними мають бути механізми обробки запитів, підтримувані реальними СУБД.
Користувачі баз даних
Як будь-який програмно-організаційно-технічний комплекс, база даних існує в часі і в просторі. Вона має певні стадії свого розвитку:
Проектування.
Реалізація.
Експлуатація;
Модернізація і розвиток.
Повна реорганізація.
На кожному етапі свого існування з базою даних пов'язані різні категорії користувачів.
Визначимо основні категорії користувачів і їх роль у функціонуванні баз даних:
Кінцеві користувачі. Це основна категорія користувачів, на користь яких і створюється база даних. Залежно від особливостей створюваної бази даних коло її кінцевих користувачів може істотно розрізнятися. Це можуть бути випадкові користувачі, що звертаються до БД час від часу за здобуттям деякої інформації, а можуть бути регулярні користувачі. Як випадкові користувачі можуть розглядатися, наприклад, можливі клієнти вашої фірми, що переглядають каталог вашої продукції або послуг з узагальненим або детальним описом того і іншого. Регулярними користувачами можуть бути ваші співробітники, що працюють із спеціально розробленими для них програмами, які забезпечують автоматизацію їх діяльності при виконанні своїх посадових обов'язків. Наприклад, менеджер, плануючий роботу сервісного відділу комп'ютерної фірми, має в своєму розпорядженні програму, яка допомагає йому планувати та розподіляти поточні замовлення, контролювати хід їх виконання, замовляти на складі необхідні комплектуючі для нових замовлень. Головний принцип полягає в тому, що від кінцевих користувачів не повинно вимагатися яких-небудь спеціальних знань в області обчислювальної техніки і мовних засобів.
Адміністратори бази даних. Це група користувачів, яка на початковій стадії розробки бази даних відповідає за її оптимальну організацію з точки зору одночасної роботи декількох кінцевих користувачів, на стадії експлуатації відповідає за коректність роботи даної бази інформації в розрахованому на багато користувачів режимі. На стадії розвитку і реорганізації ця група користувачів відповідає за можливість коректної реорганізації бази без зміни або припинення його поточної експлуатації.
Розробники і адміністратори додатків. Це група користувачів, яка функціонує під час проектування, створення і реорганізації бази даних. Адміністратори додатків координують роботу розробників при розробці конкретного застосування або групи додатків, об'єднаних у функціональну підсистему. Розробники конкретних застосувань працюють з тією частиною інформації з бази даних, яка потрібна для конкретного застосування.
Не завжди можуть бути виділені всі типи користувачів. Ми вже знаємо, що при розробці інформаційних систем з використанням настільних СУБД адміністратор бази даних, адміністратор додатків і розробник часто існували в одній особі. Проте при побудові сучасних складних корпоративних баз даних, які використовуються для автоматизації всіх або більшій частині бізнес-процесів в крупній фірмі або корпорації, можуть існувати і групи адміністраторів додатків, і відділи розробників. Найбільш складні обов'язки покладені на групу адміністратора БД.
Розглянемо їх детальніше.
У складі групи адміністратора БД мають бути:
системні аналітики;
проектувальники структур даних і зовнішнього по відношенню до бази даних інформаційного забезпечення;
проектувальники технологічних процесів обробки даних;
системні і прикладні програмісти;
оператори і фахівці з технічного обслуговування.
Якщо йдеться про комерційну базу даних, то важливу роль тут грають фахівці з маркетингу.
Основні функції групи адміністратора БД