Архітектура системи баз даних

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

групою ANSI / SPARC (Study Group on Data Management Systems), – так званої архітектурою ANSI / SPARC [21], [22] Однак тут ми не будемо дотримуватися термінології ANSI / SPARC у всіх деталях

Слід зазначити, що матеріал цієї глави подібний матеріалу попередньої в тому

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

21 ТРИ РІВНЯ АРХІТЕКТУРИ

Архітектура ANSI / SPARC включає три рівні: внутрішній, зовнішній і концептуальний (рис 21) У загальних рисах вони являють собою наступне

Рис 21 Три рівня архітектури ANSI / SPARC

■&nbsp&nbsp&nbsp&nbsp Внутрішній рівень (Званий також фізичним) найбільш близький до физиче ському сховищу інформації, тобто повязаний зі способами збереження інформації на фізичних пристроях

■&nbsp&nbsp&nbsp&nbsp Зовнішній рівень (Званий також призначеним для користувача логічним) найбільш бли зок до користувачів, тобто повязаний зі способами подання даних для окремих них користувачів

■&nbsp&nbsp&nbsp&nbsp Концептуальний рівень (Званий також загальним логічним або просто логічні ським, без додаткового визначення) є проміжним рівнем ме чекаю двома першими

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

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

– в термінах машинно-орієнтованих конструкцій на зразок бітів і байтів

Для кращого розуміння цих ідей розглянемо приклад, представлений на рис 22

Тут відображено концептуальне уявлення простий бази даних про персонал, а також відповідні йому внутрішнє і два зовнішніх подання (одне – для користувача, що застосовує мову PL / I, а інше – Для користувача, що застосовує мову COBOL) 1 Звичайно, цей приклад повністю гіпотетічен і мало схожий на реальні системи, оскільки в ньому зумисне виключені багато хто не стосуються справи деталі

Рис 22 Приклад трьох рівнів подання бази даних Розглянутий тут приклад потребує пояснень

1 На концептуальному рівні база даних містить інформацію про тип сутності з

імям EMPLOYEE (службовець) Кожен екземпляр сутності EMPLOYEE включає атрибути номера службовця EMPLOYEE_NUMBER (шість символів), номери відділу DEPARTMENT_NUMBER (чотири символи) і зарплати службовця SALARY (пять де сятічних цифр)

На внутрішньому рівні службовці представлені типом збереженої записи STORED_EMP, довжина якої становить 20 байтів Запис STORED_EMP містить чотири храни екпортувати поля: шестібайтовий префікс (можливо, що містить керуючу ін формацію, таку як прапорці або вказівники) і три поля даних, відповідаю щие трьом властивостям сутності, яка представляє службовця Крім того, записи STORED_EMP індексовані по полю ОМР # за допомогою індексу ЕМРХ, оп

1 Традиційні мови програмування PL / I і COBOL, що послужили основою для даного прикладу, все ще широко використовуються в програмному забезпеченні, встановленому на багатьох підприємствах

2 Користувач, що застосовує мову PL / I, має справу з відповідним зовнішнім поданням бази даних У ньому кожен співробітник представлений записом мовою PL / I, що містить два поля (номери відділів даному користувачеві не тре буют, тому в поданні вони опущені) Тип запису визначений за допомогою на щью звичайної структури, відповідної правилами мови PL / I

3 Аналогічно, користувач, що застосовує мову COBOL, має справу з влас ним зовнішнім поданням бази даних, в якому кожен співробітник пред ставлен записом на мові COBOL, що містить, знову ж, два поля (в даному слу чаї опущений розмір окладу) Тип запису визначений за допомогою звичайного опису на мові COBOL відповідно до прийнятих в ньому стандартними правилами

Зверніть увагу, що в кожному випадку відповідні елементи даних можуть мати різні імена Наприклад, до номера співробітника звертаються як до полю ОМР # в поданні для мови PL / I і як до полю EMPNO У поданні для мови COBOL Цей же атрибут в концептуальному уявленні має імя EMPLOYEE_NUMBER, а у внутрішньому уявленні – імя ОМР # Звичайно, в системі повинні бути відомі всі ці відповідності Наприклад, відомо, що поле EMPNO У поданні для мови COBOL утворене з концептуального поля EMPLOYEE_NUMBER, яке, в свою чергу, відповідає що зберігається полю ОМР # ВО внутрішньому поданні Такі відповідності, або відображення (mapping), на рис 22 явно не показані (подальше обговорення цих питань буде продовжено в розділі 26)

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

■ По-перше, концептуальний рівень в такій системі безперечно буде реляції онним в тому сенсі, що видимі на цьому рівні обєкти є реляційна вими таблицями, а використовувані оператори – реляційними операторами (включаючи оператори вибірки рядків і стовпців, коротко розглянуті в розділі 1)

■ По-друге, кожне зовнішнє подання, як правило, також буде Реляційних вим або достатньо близьким до нього Наприклад, оголошення записів в PL / I і COBOL, представлені на рис 22, спрощено можна вважати аналогами ого лений таблиць в реляційної системі

Примітка Слід мати на увазі, що термін зовнішнє подання (Часто – просто подання) в реляційному контексті має, на жаль, досить специфічний сенс, який НЕ повністю збігається зі змістом, приписаним йому в цьому розділі Зясуванню реляційного сенсу даного терміну і його обговорення присвячені глави 3 і (особливо) 10

■ По-третє, внутрішній рівень НЕ буде реляційних, оскільки обєкти на цьому рівні не будуть реляційними (збереженими) таблицями навпаки, вони будуть обєктами такого ж типу, як і що знаходяться на внутрішньому рівні обєк екти будь-який інший системи (збережені записи, покажчики, індекси, хешірованние значення тощо) Насправді реляційна модель як така не дозволяє дізнатися нічого суттєвого про внутрішній рівні Вона, як уже отме чалось у розділі 1, має відношення лише до того, як сприймає базу даних користувач

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

Рис 23 Детальна схема архітектури системи баз даних

22 ЗОВНІШНІЙ РІВЕНЬ

Зовнішній рівень – це індивідуальний рівень користувача Як було сказано в розділі 1, користувач може бути прикладним програмістом або кінцевим користувачем з будь-яким рівнем професійної підготовки Особливе місце серед користувачів займає адміністратор бази даних (АБД) На відміну від інших користувачів, АБД цікавлять також концептуальний і внутрішній рівні Про це ще буде сказано в наступних двох розділах

У кожного користувача є свій мову для роботи з СУБД

■ Для прикладного програміста це або один з поширених мов програмування (наприклад, PL / I, C + + або Java), або спеціальна мова розглянутої системи Такі оригінальні мови називають мовами четвертого

покоління на тому (не цілком формальному) підставі, що машинний код, мова асемблера і такі мови, як PL / I, можна вважати мовами трьох перших поколінь, а оригінальні мови модернізовані в порівнянні з мовами третього покоління в такій же мірі, як мови третього покоління поліпшені в порівнянні з мовою асемблера

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

Для нашого обговорення важливо, що всі ці мови включають подязик даних, тобто підмножина операторів лише мови, повязане тільки з обєктами баз даних і операціями з ними Інакше кажучи, подязик даних вбудований в базовий мова, яка додатково надає різні не звязані з базами даних засоби, такі як локальні (тимчасові) змінні, обчислювальні операції, логічні операції і тд Система може підтримувати будь-яку кількість базових мов і будь-яку кількість подязиков даних Однак існує одна мова, який підтримується практично всіма сьогоднішніми системами Це мова SQL, який коротко був представлений у розділі 1 Більшість систем дозволяє використовувати мову SQL і інтерактивно, як самостійна мова запитів, і у формівпровадженняйого операторів в інші мови програмування, такі як PL / I і Java (подробиці приведені в розділі 4)

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

В принципі, будь подязик даних є насправді комбінацією принаймні двох підлеглих мов – мови визначення даних (Data Definition Language – DDL), який дозволяє формулювати визначення або оголошення обєктів бази даних, і мови маніпулірованія3 даними (Data Manipulation Language – DML), який підтримує операції з такими обєктами або їх обробку Наприклад, розглянемо користувача мови PL / I (див рис 22) Подязик даних цього користувача

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

3 Термін маніпулювання (Буквально – виконання дій вручну), не дуже вдалий, але

отримав широке поширення і тому затверджений офіційно

включає певні засоби мови PL / I, застосовувані для організації взаємодії з СУБД

■ Мова визначення даних включає деякі описові структури мови PL / I, необхідні для оголошення обєктів бази даних Це сам оператор DECLARE (або DCL), певні типи даних мови PL / I, а також можливі спеціальні доповнення для мови PL/I, призначені для підтримки нових обєктів, які не передбачені в існуючій версії мови PL / I

■ Мова обробки даних складається з тих виконуваних операторів мови PL / I, вича передають інформацію в базу даних і з неї знову ж, можливо, вклю чаю нові спеціальні оператори

Примітка В якості уточнення слід зазначити, що сучасна мова PL / I насправді взагалі не включає ніяких особливих засобів для роботи з базами даних Оператор мови обробки даних (Оператор CALL), зокрема, зазвичай просто звертається до СУБД (хоча такі звернення можуть бути синтаксично спрощені, щоб вони стали більш дружніми по відношенню до користувача) Розмова про впровадження операторів мови SQL буде продовжений в розділі 4

Повернемося до архітектури Як вже зазначалося, окремого користувача цікавить лише деяка частина всієї бази даних Крім того, уявлення користувача про цю частину буде, безумовно, більш абстрактним в порівнянні з обраним способом фізичного зберігання даних Відповідно до термінології ANSI / SPARC, уявлення окремого користувача називається зовнішнім поданням Таким чином, зовнішнє подання – Це вміст бази даних, яким його бачить певний користувач (тобто для кожного користувача зовнішнє подання і є та база даних, з якою він працює) Наприклад, користувач з відділу кадрів може розглядати базу даних як набір записів з інформацією про відділи плюс набір записів з інформацією про службовців, і нічого не знати про записи з інформацією про матеріали та їх постачальниках, з якими працюють користувачі у відділі постачання

У загальному випадку зовнішнє подання складається з деякого безлічі екземплярів кожного з багатьох типів зовнішніх записів (Які зовсім НЕ обовязково повинні збігатися з збереженими записами) 4 Наданий у розпорядження користувача подязик даних завжди визначається в термінах зовнішніх записів Наприклад, операція вибірки мови обробки даних здійснює вибірку примірників зовнішніх, а не збережених записів (Тепер стає очевидно, що термін логічна запис, вживався у розділі 1, насправді ставиться до зовнішніх записів Тому надалі ми будемо уникати його використання)

Кожне зовнішнє подання визначається за допомогою зовнішньої схеми, яка в основному складається з визначень записів кожного з типів, присутніх в цьому зовнішньому поданні (див рис 22) Зовнішня схема записується за допомогою мови

4 У даному випадку передбачається, що вся інформація на зовнішньому рівні представлена ​​у формі записів Але деякі системи дозволяють представляти інформацію інакше: або замість записів, або спільно з ними Для використовують такі альтернативні методи систем всі визначення і пояснення цього розділу вимагають відповідних змін Це зауваження стосується також концептуального і внутрішнього рівнів Детальне обговорення подібних питань у цій частині книги було б передчасним, тому ми повернемося до них пізніше, в розділах 14 (особливо – в розділі Список літератури) і 25 Див також додаток А (де наведена докладна інформація про внутрішньому рівні)

визначення даних,що є підмножиною подязика даних користувача (Тому мова визначення даних іноді називають зовнішніммовою визначення даних) Наприклад, тип зовнішньої записи про працівника можна визначити як шестісімвольное поле з номером працівника, як поле з пяти десяткових цифр, призначене для зберігання даних про його зарплату, і тд Крім того, може знадобитися визначити відображення між зовнішньою та вихідної концептуальними схемами (подробиці – в наступному розділі) Це відображення розглядається в розділі 26

23 КОНЦЕПТУАЛЬНИЙ РІВЕНЬ

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

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

Концептуальне уявлення визначається за допомогою концептуальноїсхеми, що включає визначення для кожного існуючого типу концептуальних записів (див рис 22) Концептуальна схема використовує інший мова визначення даних – концептуальний Щоб домогтися незалежності від даних, не можна включати в визначення концептуального мови небудь вказівки про структури зберігання або методах доступу Визначення концептуального мови повинні ставитися  тількидо змісту інформації Це означає, що в концептуальній схемі не повинно бути жодної згадки про представлення зберігається файлу, впорядкованості збережених записів, індексуванні, хеш-адресації, покажчиках або інші подробиці зберігання даних або доступу до них Якщо концептуальна схема дійсно забезпечує незалежність від даних в цьому сенсі, то зовнішні схеми, визначені на основі концептуальної (розділ 26), завідомо забезпечуватимуть незалежність від даних

Концептуальне подання – це подання всього вмісту бази даних, а концептуальна схема – це визначення такого подання Однак було б помилкою вважати, що концептуальна схема являє собою не більше ніж набір визначень, дуже нагадують прості визначення записів у програмі на мові COBOL (або якому-небудь іншому мовою) Визначення в концептуальній схемі можуть характеризувати велика кількість різних додаткових аспектів обробки

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

опис всього підприємства – не тільки самих його даних, а й того, як ці дані використовуються, як вони переміщуються всередині підприємства, для чого використовуються в кожному конкретному місці, яка перевірка та інші типи контролю застосовуються до них у кожному окремому випадку і тд [23] Однак необхідно підкреслити, що жодна сьогоднішня система реально не підтримує такого концептуального рівня, який хоча б трохи наблизився до вказаної вище ступеня развітія5 У більшості існуючих систем концептуальна схема насправді являє собою щось, що лише трохи більше простого обєднання всіх незалежних зовнішніх схем із залученням додаткових засобів захисту і підтримкою правил забезпечення цілісності Ймовірно, з часом системи стануть набагато інтеллектуальнєє з точки зору підтримки концептуального рівня

24 ВНУТРІШНІЙ РІВЕНЬ

Третім рівнем архітектури є внутрішній рівень Внутрішнє подання – Це низкоуровневое подання всієї бази даних як бази, що складається з деякого безлічі екземплярів кожного з існуючих типів внутрішніх записів Термін внутрішня запис відноситься до термінології ANSI / SPARC і означає конструкцію, інакше звану збереженої записом (надалі ми будемо використовувати саме цей термін) Внутрішнє подання, так само як зовнішнє і концептуальне, відокремлене від фізичного рівня, оскільки в ньому не розглядаються фізичні записи, зазвичай звані блоками або сторінками, та фізичні області пристрої зберігання, такі як циліндри і доріжки Іншими словами, внутрішнє подання передбачає наявність нескінченного лінійного адресного простору Особливості методів відображення цього адресного простору на фізичні пристрої зберігання в значній мірі залежать від операційної системи і з цієї причини не включені в загальну архітектуру Слід зазначити, що блоки (або сторінки) пристрої введення-виведення – Це кількість даних, що передаються з вторинної памяті (памяті накопичувача) в основну (оперативну) память за одну операцію введення-виведення Зазвичай, сторінки мають розмір від 1 Кбайт і вище, але не більше 64 Кбайт (1 Кбайт = 1024 байт)

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

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

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

5 Многіесчітают, чтокэтойцелиближеподошлитак звані системи, засновані навикористанні ділового регламенту, або бізнес-правил (смглави9і14)

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

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*