Зацерковний В.І. та ін. ГІС та бази даних. І бази даних
 Скачать 31.1 Mb.
|
|
Архітектура БД – концепція взаємозв’язку логічних, фізичних і програмних компонентів системи. 10.2. Трирівнева архітектура баз даних У процесі досліджень, присвячених тому, як саме повинна бути влаштована СКБД, пропонувались різні способи реалізації. Найбільш життєздатною виявилась реалізація, запропонована ANSI 36 Перша спроба створення стандартної термінології та загальної архі- тектури СКБД була зроблена в 1971 р. групою DBTG (DataBase Task Group), яка прийшла до висновку про необхідність використання дворів- невого підходу: схема (рівень адміністратора) і підсхеми (рівень користувацьких представлень). У 1975 р. ANSI/X3/SPARC 37 визнав необхідним використання три- рівневого підходу для задоволення потреб колективного використання структур даних при їх індивідуальному представленні. Хоча модель, що запропонована групою ANSI/SPARC, не стала стандартом, проте архітек- тура вважається класичною і є актуальною й донині. Мета створення трирівневої архітектури СКБД є відділення ко- ристувацького представлення бази даних від її фізичного представлення: кожен користувач повинен мати можливість звертатися до даних, використовуючи власне уявлення про них (незалежно від уявлень інших користувачів); взаємодія користувачів БД не повинна залежати від особливостей збереження даних у ній (наприклад, індексування, хешування 38 ); 36 Американський національний інститут стандартів (англ. American National Standards Institute, ANSI) – об’єднання американських промислових і ділових груп, що розробляє торгові і комунікаційні стандарти, член ISO. 37 X3 – комітет обчислювальної техніки й обробки інформації ANSI, SPARC – Standards Planning and Requirements Committee (Комітет планування стандартів і норм). 38 Хешування (іноді гешування, англ. hashing) – перетворення вхідного масиву даних довільної довжини на вихідний бітовий рядок фіксованої довжини. Такі перетворення також 347 адміністратор БД повинен мати можливість змінювати структуру збереження даних у базі, не впливаючи на користувацькі уявлення; внутрішня структура БД не повинна залежати від змін фізичних аспектів збереження інформації (наприклад, використання нового при- строю збереження). Архітектура ANSI-SPARC передбачає три різні рівні представлення даних: зовнішній, концептуальний та внутрішній (рис. 10.2). Трирівневе представлення БД передбачає відповідний опис даних на кожному рівні й узгодження одних і тих самих даних на різних рівнях. Рівень зовнішніх моделей(external level) – представлення БД з точки зору користувачів. Зовнішній рівень представлення даних не стосується фізичної організації (розміщення) даних у зовнішній пам’яті, тому його називають іноді логічним рівнем. Відповідно внутрішній рівень називають фізичним рівнем. Оскільки БД є загальним ресурсом, то кожному користувачу може знадобитися своє, відмінне від інших уявлення про характеристики інформації, що зберігається в БД (користувач має справу з представлен- ням предметної сфери, виражену в найбільш зручній для нього формі). Зовнішнє подання містить тільки ті сутності, атрибути та зв’язки пред- метної сфери БД, які цікаві користувачу (додатку). Рис. 10.2. Трирівнева модель системи керування базою даних, що запропонована ANSI називаються хеш-функціями або функціями згортки, а їх результати називають хешем, хеш- кодом або дайджестом повідомлення (англ. message digest). Зовнішній … … … … Зовнішня модель даних 1 Зовнішня модель даних 2 Зовнішня модель даних n Концептуальний Внутрішній База даних Представлення 1 Представлення 2 Представлення n Р ів н і п р е д с т ав л е н н я м од е л е й Рів н і м од ел ей д ан и х Інфо- логічний Дато- логічний Фізичний Фізична організація даних 348 Інші сутності, атрибути та зв’язки, які йому не потрібні, теж можуть бути представлені в БД, але користувач може навіть не підозрювати про їх існування. Тому на зовнішньому рівні може бути декілька різних зовнішніх представлень БД (кожний користувач має своє уявлення "реального світу" і не бачить зайве (з його точки зору)). Крім того, різні подання можуть різним чином відображати одні й ті ж дані. Наприклад, один користувач може переглядати дати в форматі (день, місяць, рік), а інший – у форматі (рік, місяць, день). Деякі подання можуть включати похідні або обчислю- вані дані, що не зберігаються в БД як такі, а створюються в міру потреби (вік співробітників, термін експлуатації споруди тощо), що не вимагає зайвих оновлень БД і дозволяє зменшити об’єм БД. Уявлення можуть також включати комбіновані або похідні дані з декількох об’єктів. Зовнішній рівень являє собою, як правило, словесний опис даних та їх взаємозв’язків і відбиває інформаційні потреби користувачів та прик- ладних програм (рис. 10.3). Вимоги користувачів до зовнішнього подання охоплюють сукуп- ність даних, які потрібні для виконання запитів користувачів. Вимоги з боку прикладних програм до зовнішнього рівня подання даних – це перелік даних з описом їх взаємозв’язків, які необхідні для реалізації певних функціональних завдань. Рис. 10.3. Зовнішній рівень представлення моделей Опис зовнішнього рівня не виключає наявності дублювання, над- лишковості, неузгодженості тощо. Метою проектування на зовнішньому рівні є розробка позамашин- ного інформаційного забезпечення, яке вміщує систему вхідної (первин- ної) документації і характеризує певну предметну сферу (ПС), систему класифікації та кодування інформації, а також перелік відповідних вихідних повідомлень. Під предметною сферою розуміють один або кілька об’єктів реального світу, інформація про які моделюється за допомогою БД і використовується для розв’язку різних функціональних завдань. Існує два підходи до проектування баз даних на зовнішньому рівні: від предметної сфери; від запиту. Вимоги користувачів Вимоги прикладних програм Зовнішній рівень представлення моделей 349 Підхід "від предметної сфери" полягає в тому, що формується зов- нішнє інформаційне забезпечення всієї предметної сфери без урахування потреб користувачів і прикладних програм. Іноді цей підхід називають ще об’єктним, або непроцесним. При підході "від запиту" основним джерелом інформації про пред- метну сферу є вивчення запитів користувачів і потреб прикладних про- грам. Цей підхід також називається процесним, або функціональним. При такому підході БД проектується для виконання поточних завдань керування без урахування можливості розширення системи і виникнення нових завдань управління. Перевагами підходу "від предметної області" є його об’єктивність, системність при відображенні ПС і стійкість інформаційної моделі, можли- вість реалізації великої кількості прикладних програм і запитів, у тому числі незапланованих при створенні БД. Недолік цього підходу – значний обсяг робіт, що його потрібно виконати при визначенні інформації, яка підлягає фіксації в БД, що відповідно ускладнює і збільшує термін розробки проекту. 2. Концептуальний рівень(conceptual level) – це узагальнене, проміжне представлення БД. Він містить логічну структуру всієї БД, а саме: всі сутності, їх атрибути і зв’язки; обмеження, семантичну інфор- мацію про дані; інформацію про заходи безпеки і підтримки цілісності даних, що використовуються усіма додатками, які працюють з даною БД. Усі зовнішні представлення утворюються з даних цього рівня, але цей рівень не містить відомостей про методи збереження даних (тобто може мати інформацію про довжину полів, їх тип, назву, але не містить інфор- мації про об’єми в байтах тощо). Фактично концептуальний рівень відбиває узагальнену модель предметної сфери, для якої створювалася БД (рис. 10.4). Рис. 10.4. Логічний рівень представлення моделей Як і будь-яка модель, концептуальна модель відображає тільки істотні з точки зору обробки особливості об’єктів реального світу. Концептуальний рівень підтримує кожне зовнішнє представлення. Даний рівень об’єднує дані, які використовуються усіма прикладни- ми програмами, що працюють з БД. Однак концептуальний рівень не містить жодних відомостей про методи збереження даних. Вимоги та обмеження СКБД Логічний рівень представлення моделей 350 Виділення концептуального рівня дозволило розробити апарат централізованого керування БД. 3. Внутрішній рівень (internal level) описує фізичну реалізацію бази даних. Його ще називають фізичним рівнем. Це власне дані, що зберіга- ються в файлах або в сторінкових структурах, що розташовані на зовніш- ніх носіях інформації. На внутрішньому рівні міститься така інформація: розподіл дискового простору для збереження даних та індексів; відомості про розміщення записів; відомості про стиснення даних та методи їх шифрування. Виділяють декілька проблем фізичного подання даних, які необхід- но вирішити, щоб забезпечити максимальну ефективність роботи бази даних. По-перше, необхідно вирішити, як здійснювати пошук потрібного запису. Для цього потрібно встановити відповідність між логічним записом і адресою фізичного запису. По-друге, необхідно вирішити, як організувати дані, щоб їх пошук був ефективним. По-третє, як додавати нові записи до даних, видаляти старі записи і при цьому не порушувати систему адресації і пошуку. Відмінності між рівнями представлення даних показані на рис. 10.5. Рис. 10.5. Відмінності між рівнями представлення даних 351 10.3. Забезпечення незалежності СКБД від даних Незалежність від даних – основоположний принцип побудови СКБД. Відповідно до цього принципу в системі повинні підтримуватися роздільні представлення даних для користувача ("логічна незалежність") і для сис- темних механізмів середовища зберігання БД ("фізична незалежність"). Та- кий поділ позбавляє користувача від необхідності знання прийнятого спосо- бу зберігання БД і дозволяє динамічно оптимізувати спосіб зберігання БД у процесі експлуатації системи для забезпечення більш високої продуктив- ності системи і (або) більш раціонального використання ресурсів пам’яті. Логічна незалежність від даних означає цілковиту захищеність зовнішніх схем від змін, що вносяться в концептуальну схему, тобто припускає можливість зміни однієї прикладної програми без коригування інших додатків, що працюють з цією ж БД, додавання і видалення нових сутностей, атрибутів і зв’язків. Фізична незалежність від даних означає захищеність концеп- туальної схеми від змін, що вносяться у внутрішню схему, тобто припус- кає можливість перенесення інформації, що зберігається з одних носіїв на інші, при збереженні працездатності всіх додатків, що працюють з даною базою даних, модифікацію індексів тощо. Користувачі можуть помітити зміни, що відбулись у внутрішній схемі, тільки за зміною продуктивності. Це саме те, чого не вистачало при використанні файлових систем. 10.4. Відображення рівнів моделей Архітектура СКБД, крім безпосереднього представлення трьох рівнів моделей, включає певні відображення: – відображення концептуального рівня на внутрішній; – декілька відображень зовнішніх рівнів на концептуальний. Відображення "концептуальний – внутрішній" встановлює відповід- ність між концептуальним представленням і БД, що зберігається, тобто описує, як концептуальні записи і поля представлені на внутрішньому рівні. Відображення "зовнішній – концептуальний" визначає відповідність між певним зовнішнім представленням і концептуальнім представленням. Відображення "концептуальний – внутрішній" слугує основою фізичної незалежності від даних, а відображення "зовнішній – концепту- альний" є ключем до логічної незалежності від даних. Опис БД – схема БД, яка створюється в процесі її проектування, причому передбачається, що вона змінюється доволі рідко. Стан БД – сукупність інформації, що зберігається в БД у певний момент часу. Схема БД іноді називається змістом БД, а її стан – деталізацією. 352 10.5. Організація процесу проходження користувацького запиту На рис. 10.6 представлено взаємодію користувача, СКБД і операцій- ної системи (ОС) при обробці запиту на отримання даних. Цифрами помічено послідовність взаємодій. 1. Користувач посилає СКБД запит на отримання даних з БД. 2. Аналіз прав користувача і зовнішньої моделі даних, що відпові- дає даному користувачу, підтверджує або забороняє доступ даного корис- тувача до запитуваних даних. Рис. 10.6. Схема проходження запиту до БД 3. У разі заборони на доступ до даних СКБД повідомляє корис- тувачу про це (стрілка 12) і завершує подальший процес обробки даних, в іншому випадку СКБД визначає частину концептуальної моделі, яка виділяється запитом користувача. 4. СКБД отримує інформацію про запитувану частину концеп- туальної моделі. 5. СКБД запитує інформацію про місце розташування даних на фізичному рівні (файли або фізичні адреси). 6. В СКБД повертається інформація про місце розташування даних у термінах операційної системи. 7. СКБД ввічливо просить ОС надати необхідні дані, використо- вуючи засоби ОС. 8. ОС здійснює перекачування інформації з пристроїв збереження і пересилає її в системний буфер. 353 9. ОС сповіщає СКБД про закінчення пересилки. 10. СКБД обирає з доставленої інформації, що знаходиться в системному буфері, тільки те, що потрібно користувачеві, і пересилає ці дані в робочу сферу користувача. База метаданих (БМД) – місце збереження всієї інформації про використовувані структури даних, логічну організацію даних, права доступу користувачів і фізичне розташування даних. Для керування БМД існує спеціальне програмне забезпечення адміністрування баз даних, яке призначено для коректного використання єдиного інформаційного простору багатьма користувачами. А чи завжди запит проходить повний цикл? Звичайно ж, ні. СКБД має доволі розвинений інтелект, який дозволяє їй не повторювати безглуздих дій. І тому, наприклад, якщо цей же користувач повторно звернеться до СКБД з новим запитом, то для нього вже не будуть перевірятися зовнішня модель і права доступу, а якщо подальший аналіз запиту покаже, що дані можуть знаходитися в системному буфері, то СКБД здійснить тільки 11 і 12 кроки в обробці запиту. Зрозуміло, що механізм проходження запиту в реальних СКБД на- багато складніший, але й ця спрощена схема показує, наскільки серйозними і складними повинні бути механізми обробки запитів, що підтримуються реальними СКБД. 10.6. Користувачі СКБД Як і будь-який програмно-організаційно-технічний комплекс, СКБД існує в часі й в просторі. Вона має певні стадії свого розвитку: 1) проектування; 2) реалізація; 3) експлуатація; 4) модернізація і розвиток; 5) повна реорганізація. На кожному етапі свого існування із СКБД пов’язані різні категорії користувачів (рис. 10.7). Групу внутрішніх користувачів складають: адміністратор даних, адміністратор БД (АБД), адміністратори додатків (функціональних підсистем), системні і прикладні програмісти. Примітка. Функції адміністратора БД на стадії розробки і на стадії експлуатації різні і тому виконуються різними особами. Адміністратори даних – це група користувачів, яка на почат- ковій стадії розробки БД відповідає за його оптимальну організацію з точки зору одночасної роботи кінцевих користувачів. 354 Адміністратор даних: – визначає потреби зовнішніх користувачів при проектуванні БД; – ставить завдання адміністратору БД. Рис. 10.7. Користувачі систем керування базами даних В ІС, що створюються на основі СКБД, способи організації даних і методи доступу до них перестали відігравати істотну роль, оскільки ста- ли схованими всередині СКБД. Масовий (кінцевий користувач), зазвичай, має справу тільки із зовнішнім інтерфейсом, що підтримується СКБД. Ці переваги не можуть бути реалізовані шляхом механічного об’єднання даних у БД. У системі обов’язково повинна існувати спеціальна посадова особа (група осіб) – адміністратор бази даних (АБД), який несе відпо- відальність за проектування і загальне керування БД. АБД визначає інформаційний зміст БД. З цією метою він ідентифікує об’єкти БД і моделює базу, використовуючи мову опису даних. Отримувана модель слугує в подальшому довідковим документом для адміністраторів додатків і користувачів. АБД вирішує також усі питання, пов’язані з розмі- щенням БД в пам’яті, вибором стратегії і обмежень доступу до даних. До функції АБД входять також організація завантаження, ведення і відновлен- ня БД та багато інших дій, які не можуть бути повністю формалізовані й автоматизовані. АБДвідповідає за коректність роботи даної БД у багатокористува- цькому режимі. На стадії розвитку та реорганізації він відповідає за мож- ливість коректної реорганізації БД без зміни або припинення її поточної експлуатації. |