1. Архітектура БД.Фізична і логічна незалежгість.

2. Процес проходження користувацького запиту.

Термінологія в СКБД, та й самі терміни "база даних" і "банк даних" частково запозичені з фінансової діяльності. Це запозичення - не випадково і пояснюється тим, що робота з інформацією і робота з грошовими масами в чому схожі, оскільки і там і там відсутня персоніфікація об'єкта обробки: дві банкноти номіналом в сто рублів настільки ж відрізняються і взаємозамінні, як два однакових байта (природно , за винятком серійних номерів). Ви можете покласти гроші на деякий рахунок і надати можливість вашим родичам або колегам використовувати їх для інших цілей. Ви можете доручити банку оплачувати ваші витрати з вашого рахунку або отримати їх готівкою в іншому банку, і це будуть вже інші грошові купюри, але їх цінність буде еквівалентна тій, яку ви мали, коли клали їх на ваш рахунок.
У процесі наукових досліджень, присвячених тому, як саме повинна бути влаштована
СКБД пропонувалися різні способи реалізації. Самим життєздатним з них виявилася запропонована американським комітетом по стандартизації ANSI (American National
Standards Institute) трирівнева система організації БД, зображена на рис.2.1
Зовнішня
модель даних

Зовнішня модель даних

Зовнішня модель даних

Концептуальний рівень

БД
Рис. 2.1. Трирівнева модель системи управління базою даних, запропонована ANSI
1. Рівень зовнішніх моделей - самий верхній рівень, де кожна модель має своє "бачення" даних. Цей рівень визначає точку зору на БД окремих додатків. Кожна програма бачить і обробляє тільки ті дані, які необхідні саме цьому додатком. Наприклад, система розподілу робіт використовує відомості про кваліфікацію співробітника, але її не цікавлять відомості про оклад, домашню адресу і телефон співробітника, і навпаки, саме ці відомості використовуються в підсистемі відділу кадрів.
2. Концептуальний рівень - центральний управляючий ланка, тут база даних представлена в найбільш загальному вигляді, який об'єднує дані, які використовуються усіма додатками, що працюють з даною базою даних. Фактично концептуальний рівень відображає узагальнену модель предметної області (об'єктів реального світу), для якої створювалася база даних. Як будь-яка модель, концептуальна модель відображає тільки істотні, з точки зору обробки, особливості об'єктів реального світу.
3. Фізичний рівень - власне дані, розташовані в файлах або в сторінкових структурах, розташованих на зовнішніх носіях інформації.

3. Основні стадії розвитку СКБД та групи користувачів СКБД.

Схема проходження запиту до БД
1. Користувач посилає СКБД запит на отримання даних з БД.
2. Аналіз прав користувача і зовнішньої моделі даних, відповідної даному користувачеві, підтверджує або забороняє доступ даного користувача до запитаних даних.
3. У разі заборони на доступ до даних СКБД повідомляє користувачеві про це і припиняє подальший процес обробки даних, в іншому випадку СУБД визначає частину концептуальної моделі, яка зачіпається запитом користувача.
4. СКБД запитують інформацію про цю частину концептуальної моделі.
5. СКБД отримує інформацію з запитаної частини концептуальної моделі.
6. СКБД запитує інформацію про місцезнаходження даних на фізичному рівні
(файли або фізичні адреси).
7. У СКБД повертається інформація про місцезнаходження даних в термінах операційної системи.
8. СКБД просить операційну систему надати необхідні дані, використовуючи засоби операційної системи.
9. Операційна система здійснює перекачку інформації з пристроїв зберігання і пересилає її в системний буфер.
10. Операційна система оповіщає СКБД про закінчення пересилки.
11. СКБД вибирає з доставленої інформації, що знаходиться в системному буфері, тільки те, що потрібно користувачеві, і пересилає ці дані в робочу область користувача.
БМД - це База Метаданих, саме тут і зберігається вся інформація про використовувані структури даних, логічну організацію даних, права доступу користувачів і, нарешті, фізичне розташування даних. Для управління БМД існує спеціальне програмне забезпечення адміністрування баз даних, яке призначене для коректного використання єдиного інформаційного простору багатьма користувачами. Зрозуміло, механізм проходження запиту в реальних СКБД набагато складніше, але і ця спрощена схема показує, наскільки серйозними і складними повинні бути механізми обробки запитів, підтримувані реальними СУБД.

Як будь програмно-організаційно-технічеcкій комплекс, банк даних існує в часі і в просторі.
Він має певні стадії свого розвитку:
1. Проектування.
2. Реалізація.
3. Експлуатація.
4. Модернізація та розвиток.
5. Повна реорганізація.
На кожному етапі свого існування з банком даних пов'язані різні категорії користувачів.
Визначимо основні категорії користувачів і їх роль у функціонуванні банку даних:
• Кінцеві користувачі. Це основна категорія користувачів, в інтересах яких і створюється банк даних. Це можуть бути випадкові користувачі, які звертаються до БД час від часу за отриманням деякою інформацією, а можуть бути регулярні користувачі (наприклад, можливі клієнти фірми), регулярні користувачі (співробітники, що працюють зі спеціально розробленими для них програмами), Головний принцип полягає в тому, що від кінцевих користувачів не повинно вимагатися будь-яких спеціальних знань в області обчислювальної техніки і мовних засобів.
• Адміністратори банку даних. Це група користувачів, яка на початковій стадії розробки банку даних відповідає за його оптимальну організацію з точки зору одночасної роботи безлічі кінцевих користувачів, на стадії експлуатації відповідає за коректність роботи даного банку інформації в многопользовательском режимі. На стадії розвитку і реорганізації ця група користувачів відповідає за можливість коректної реорганізації банку без зміни або припинення його поточної експлуатації.
• Розробники та адміністратори додатків. Це група користувачів, яка функціонує під час проектування, створення та реорганізації банку даних. Адміністратори додатків координують роботу розробників при розробці конкретного програму або комплект програм, об'єднаних у функціональну підсистему. Розробники конкретних програм працюють з тією частиною інформації з бази даних, яка потрібна для конкретного додатка.
Найбільш складні обов'язки покладені на групу адміністратора БД.
У складі групи адміністратора БД повинні бути:



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

4. Основні поняття моделей даних СКБД.Типи моделей.
Модель даних - це деяка абстракція, яка, будучи застосовна до конкретних даних, дозволяє користувачам і розробникам трактувати уже як інформацію, тобто відомості, що містять не тільки дані, але й взаємозв'язок між ними.
Моделі даних діляться на (відповідно до етапів проектування БД





5. Функції адміністратора БД.

6.

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

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






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

4. Первісна завантаження і ведення БД:




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

5. Захист даних:




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

6. Забезпечення відновлення БД:



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

системні аналітики; проектувальники структур даних і зовнішнього по відношенню до банку даних інформаційного забезпечення; проектувальники технологічних процесів обробки даних; системні та прикладні програмісти; оператори та фахівці з технічного обслуговування.Если речь идет о коммерческом банке данных, то важную роль здесь играют специалисты по маркетингу. Проектування БД ПО засобами СКБД.Етапи проектування, завдання кожного етапу Методологія проектування. Структурований підхід, який передбачає використання спеціалізорованих процедур, технічних прийомів, інструментів, документації для спрощення процесу проектування.
Розбиває весь процес проектування на наступні стадії
Концептуальне проектування бази даних.
Конструювання інформаційної моделі підприємства не залежно від подальших умов її реалізації ( наприклад вираний тип СКБД, мови програмування застосувань, апаратної платформи) Задачі
1. Створення локальної концептуальної моделі для зовнішних представлень кожної групи користувачів 2. Визначення типів сутностей
3. Визначення типів зв’язків.
4. Визначення атрибутів і зв’язування їх с типами сущностей и связей.
5. Визначення доменів атрибутів.
6. Визначення атрибутів, що являються потенційними і первинними ключами.
7. Перевірка відповідності локальної концептуальної моделі конкретним користувацьким транзакціям. Логічне проектування бази даних.
Конструювання інформаційної моделі підприємства на основі концептуальних моделей користувацьких представлень з урахуванням типу СКБД (наприклад реляційної СКБД).
Логічна модель даних являється джерелом для этапу фізичного проектуровання.
Задачі
1. Створення логічної моделі даних для кожної локальної концептуальної моделі.
2. Видалення особливостей, несумісних з реляційною моделлю
3. Визначення набору відношень і перевірка їх з допомогю правил нормалізації
4. Перевірка відровідності відношень вимогам користувацьких транзакцій
5. Визначення вимог підтримки цілісності дани
6. Злиття локальних логічних моделей в єдину глобальну логічну модель і її перевірка. Глобальна логічна модель складається з ER-діаграми, реляційної схеми і супроводжуючої документації
Фізичне проектування бази даних. Описує.базові відношення, визначає організацію файлів і склад індексов, регламентує всі обмеження цілісності і міри захисту. Обов’яково проводиться з урахуванням конкретної СКБД

7. Підготовка і підтримка системних засобів:



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

8. Організаційно-методична робота з проектування БД:






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

безлічі додатків,

Задачі для реляційної СКБД.
1. Перенос глобальної логічної моделі даних в середовище цільовоїСКБД.
2. Проектування таблиць, базових відношень, похідних відношень в цільовій
СКБД.
3. Реалізація обмежень предметної області.
4. Аналіз транзакцій.
5. Вібір файлової структури та визначення індексів
6. Розробка механізмів захисту
7. Організація моніторингу та настройка функціонування операційної системи.

7. Побудова концептуальної (інфологічної) моделі .Сутності,зв»язки, ключі, обмеження цілісності
Ціль. Створення локальних концептуальних моделей підприємтсва на основі зовнішніх представлень про предметну область кожного окремого типу користувачів
Кожна локальна концептуальна модель даних складається з наступних компонент:
 типи сутностей;
 типы зв’язків;
 атрибути і домени атрибутів;
 первинні ключі;
 альтернативні ключі;
 обмеження цілісності.
Концептуальная модель даних доповнюється документацією, яка включає словник даних.
Після виділення кожної сутності їй присвоюється ім’я, яке обов’язково повинне бути зрозумілим користувачам. Вибране ім’я і опис сутності розміщується в словник даних.
Після виділення сутностей встановлюються всі зв’зки між ними. Для виявлення сутностей в описі предметної області можна скласти перелік іменників – основних нонять цієї області, а для виявлення зв’язків потрібно переглянути дієслова, що вживаються до сутностей.Зв’язки можуть бути двохсторонніми ( між двома сутностями), багатосторонніми
(декілька сутностей різних типів – це так звані складні зв’язки) та рекурсивними.
Встановивши зв’язки, необхіно визначити кратність кожного з них .
Після встановлення зв’язків перевіряється вимога участі кожної сутності хоча б в одному зв’язку. Ізольованя сутності можуть бути задубльовані під іншим іменем або для неї пропущено зв’язок. Кожному типу зв’язків присвоюється змістовне ім’я і включається в словник бази даних з змістовним описом цього зв’язку та його кратності.

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

8. Об"єднання локальних моделей користувацьких представлень в єдину глобальну даталогічну модель.
До даного моменту для кожної локальної логічної моделі даних мають бути підготовлені ERдіаграмма, словник даних і супровідна документація з описом обмежень, які поширюються на цю модель.
У невеликих системах, які налічують два-три користувальницьких представлення з незначною кількістю типів сутностей і зв'язків, завдання порівняння локальних моделей є відносно нескладною. Проте в крупних системах необхідно використовувати більш системний підхід.
Пропонований підхід передбачає виконання таких дій.
1. Аналіз імен та змісту сутностей (відношень) та їх потенційних ключів.
2. Аналіз імен та змісту зв'язків (зовнішніх ключів).
3. Злиття однакових сутностей ( відношень) різних локальним моделям даних.
4. Включення (без злиття) сутностей ( відношень), характерних тільки для окремих локальних моделей даних.
5. Злиття зв'язків ( зовнішніх ключів) з окремих локальних моделей даних.
6. Включення (без злиття) зв'язків ( зовнішніх ключів), характерних тільки для окремих локальних моделей даних.
7. Перевірка того, чи немає пропущених сутностей ( відношень) і зв'язків ( зовнішніх ключів). 8. Перевірка зовнішніх ключів.
9. Перевірка обмежень цілісності.
10. Формування глобальної ER-діаграми ( схеми відношень).
11. Оновлення документації,
Як правило, виконання перевірки на основі вивчення композиції відносин простіше ніж перевірка за ER- діаграмою
Розглянемо деякі пункти детальніше.
3.Злиття однакових сутностей ( відношень), відповідних локальним моделям даних
Перевірка імені та змісту кожної сутності в моделях, призначених для об'єднання, для визначення того, чи відповідають сутності одним і тим же "реальним об'єктам" і чи можуть бути об'єднані. Як правило, на цьому етапі виконуються наступні завдання:
• об'єднання сутностей з однаковими іменами та первинними ключами;
• об'єднання сутностей з однаковими іменами, але різними первинними ключами;
• об'єднання сутностей з різними іменами з використанням однакових або різних первинних ключів. Об'єднання сутностей і з однаковими іменами та первинними ключами
Як правило, сутності з однаковими первинними ключами відповідають одному і тому ж об'єкту "реального світу" і повинні бути об'єднані. Об'єднана сутність включає всі атрибути з первинних сутностей . Проводиться порівняння і уніфікація форматів даних
Об'єднання сутностей з однаковими іменами, але різними первинними ключами
У деяких ситуаціях можуть виявитися дві сутності з однаковими іменами та аналогічними потенційними ключами, але з різними первинними ключами. У таких випадках необхідно вибрати для використання в якості первинного ключа тільки один ключ, а інший первинний ключ перетворити в альтернативний.
Об'єднання сутностей з різними іменами з використанням однакових або різних первинних ключів
У деяких випадках можуть виявитися сутності , що мають різні імена, але виконують аналогічну роль. Подібні сутності можуть бути виявлені наступним чином:
• за їхніми іменами, які вказують на аналогічне призначення;
• по їх змісту і особливо за їх первинним ключем;
• на підставі того, що вони беруть участь у певних зв'язках.

11. Технологія клієнт-сервер БД-х.
Основний принцип технології "клієнт-сервер" стосовно до технології баз даних полягає в поділі функцій стандартного інтерактивного додатку на 5 груп:






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

функції введення і відображення даних (Presentation Logic); прикладні функції, що визначають основні алгоритми вирішення завдань додатку
(Business Logic); функції обробки даних всередині програми (Database Logic); функції управління інформаційними ресурсами (Database Manager System); службові функції, які відіграють роль зв'язок між функціями перших чотирьох груп.

9. Побудова логічної моделі (даталогічної) даних СКБД. Основні кроки.
Початково логічне проектування баз даних для реляційної моделі ділиться на 2 етапи.
1. Створення та перевірка локальної логічної моделі даних для окремих користувацьких представлень. 2. Створення та перевірка глобальної логічної моделі даних.
На стадії локального логічного проектування виконуються наступні етапи.
1. Виключення особливостей, що не сумісні з реляційною моделлю(необов'язковий етап).
2. Формування відношень на основі локальної логічної моделі даних.
3. Перевірка відношень з використанням засобів нормалізації.
4. Перевірка відношень для виконання користувацьких транзакцій.
5.Формування обмежень цілісності.
На етапі концептуального проектування було створено 2 локальні концептуальні моделі користувацьких представлень Branch(Відділення агентства) та Staff(Рієлтер):

12. Модель файлового сервера для віддаленого керування даними.
Модель віддаленого управління даними також називається моделлю файлового серверу (File
Server, FS). У цій моделі презентаційна логіка і бізнес-логіка розташовуються на клієнті. На сервері розташовуються файли з даними і підтримується доступ до файлів. Функції управління інформаційними ресурсами в цій моделі знаходяться на клієнті.
Розподіл функцій в цій моделі представлено на рис. 10.4.
У цій моделі файли бази даних зберігаються на сервері, клієнт звертається до сервера з файловими командами, а механізм управління всіма інформаційними ресурсами, власне база мета-даних, знаходиться на клієнті.

Структура типового додатку, що працює з базою даних наведена на рис. 10.2.

ТЕРМІНОЛОГІЯ
Користувач БД - програма або людина, яка звертається до БД на мові маніпулювання даними.
Запит - процес звернення користувача до БД з метою введення, отримання або зміни інформації в БД.

Рис. 10.2. Структура типового інтерактивного додатку, що працює з базою даних

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

Тому основними завданнями презентаційної логіки є:





формування екранних зображень; читання і запис інформаці в екранні форми ; управління екраном; обробка рухів миші і натиснень клавіш клавіатури.

Бізнес-логіка, або логіка власне додатків (Business processing Logic), - це частина коду програми, яка визначає алгоритми вирішення конкретних завдань програми.

Рис. 10.4. Модель файлового сервера
Достоинства этой модели в том, что мы уже имеем разделение монопольного приложения на два взаимодействующих процесса. При этом сервер (серверный процесс) может обслуживать множество клиентов, которые обращаются к нему с запросами. Собственно СУБД должна находиться в этой модели на клиенте.
Який алгоритм виконання запиту клієнта?

Логіка обробки даних (Data manipulation Logic) - це частина коду програми, яка пов'язана з обробкою даних всередині програми. Даними управляє власне СКБД (DBMS). Для забезпечення доступу до даних використовуються мова запитів і засоби маніпулювання даними стандартної мови SQL.
Процесор управління даними (Database Manager System Processing) - це власне СКБД, яка забезпечує зберігання і управління базами даних. В ідеалі функції СКБД повинні бути приховані від бізнес-логіки додатку, однак для розгляду архітектури додатку нам треба їх виділити в окрему частину програми.
У децентралізованій архітектурі ці завдання можуть бути по-різному розподілені між серверним і клієнтським процесами. Залежно від характеру розподілу можна виділити наступні моделі розподілів (див. Рис. 10.3):






розподілена презентація (Distribution presentation, DP); віддалена презентація (Remote Presentation, RP); розподілена бізнес-логіка (Remote business logic, RBL); розподілене управління даними (Distributed data management, DDM); віддалене управління даними (Remote data management, RDA).

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

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

13. Модель віддаленого доступу до даних.

15. Моделі серверів БД-х.Архітектура.Типи паралелізму.

У моделі віддаленого доступу (Remote Data Access, RDA) база даних зберігається на сервері.
На сервері також знаходиться ядро СУБД. На клієнті розташовується презентаційна логіка і бізнес-логіка програми. Клієнт звертається до сервера із запитами на мові SQL. Структура моделі віддаленого доступу наведена на рис. 10.5.

Рис. 10.5. Модель вілдаленого доступу (RDA)
Переваги даної моделі:
• перенесення компонента представлення та прикладного компонента на клієнтський комп'ютер істотно розвантажив сервер БД
• сервер БД звільняється від невластивих йому функцій; процесор або процесори сервера цілком завантажуються операціями обробки даних, запитів і транзакцій
• різко зменшується завантаження мережі, оскільки по ній від клієнтів до сервера передаються не запити на ввід-вивід в файловій термінології, а запити на SQL, і їх обсяг істотно менше. У відповідь на запити клієнт отримує тільки дані, релевантні запиту, а не блоки файлів, як в FS-моделі. недоліки: • все-таки запити на мові SQL при інтенсивній роботі клієнтських додатків можуть істотно завантажити мережу;
• так як в цій моделі на клієнті розташовується і презентаційна логіка, і бізнес-логіка додатку, то при повторенні аналогічних функцій у різних додатках код відповідної бізнеслогіки повинен бути повторений для кожного клієнтського додатку. Це викликає зайве дублювання коду додатків;
• сервер в цій моделі грає пасивну роль, тому функції управління інформаційними ресурсами повинні виконуватися на клієнті. Дійсно, наприклад, якщо нам необхідно виконувати контроль страхових запасів товарів на складі, то кожен додаток, який пов'язаний зі зміною стану складу, після виконання операцій модифікації даних, що імітують продаж або видалення товару зі складу, повинна виконувати перевірку на обсяг залишку

16. Моделі транзакцій транзакцій. .Поняття

транзакції.Властивості.Способи

завершення

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

14. Модель сервера БДх.
Дану модель підтримують більшість сучасних СКБД: Informix, Ingres, Sybase, Oracle, MS SQL
Server. Основу даної моделі становить механізм збережених процедур як засіб програмування
SQL-сервера, механізм тригерів як механізм відстежування поточного стану інформаційного сховища і механізм обмежень на користувача типи даних, який іноді називається механізмом підтримки доменної структури. Модель сервера баз даних представлена на рис.

У цій моделі бізнес-логіка розділена між клієнтом і сервером. На сервері бізнес-логіка реалізована у вигляді збережених. Клієнтський додаток звертається до сервера з командою запуску збереженої процедури, а сервер виконує цю процедуру і реєструє всі зміни в БД, які в ній передбачені. Сервер повертає клієнту дані, релевантні його запиту, які потрібні клієнтові або для виводу на екран, або для виконання частини бізнес-логіки, яка розташована на клієнті.
Трафік обміну інформацією між клієнтом і сервером різко зменшується.
Централізований контроль в моделі серверу баз даних виконується з використанням механізму тригерів. Тригери також є частиною БД
У даній моделі сервер є активним, тому що не тільки клієнт, але і сам сервер, використовуючи механізм тригерів, може бути ініціатором обробки даних в БД.
І збережені процедури, і тригери зберігаються в словнику БД, вони можуть бути використані декількома клієнтами, що істотно зменшує дублювання алгоритмів обробки даних у різних клієнтських додатках.
Недоліком даної моделі є дуже велике завантаження сервера.
Для розвантаження сервера була запропонована трирівнева модель Моделі сервера застосувань. Ця модель є розширенням дворівневої моделі і в ній вводиться додатковий проміжний рівень між клієнтом і сервером. Архітектура трирівневої моделі наведена на рис. 10.7. Цей проміжний рівень містить один або кілька серверів додатків.
У цій моделі компоненти програми діляться між трьома виконавцями: Клієнт забезпечує логіку уявлення, включаючи графічний користувальницький інтерфейс, локальні редактори;
Сервери додатків складають новий проміжний рівень архітектури. Вони спроектовані як виконання загальних незагружаемую функцій для клієнтів. Сервери додатків підтримують функції клієнтів як частин взаємодіючих робочих груп, зберігають і виконують найбільш загальні правила бізнес-логіки, підтримують каталоги з даними. Сервери баз даних у цій моделі займаються виключно функціями СКБД: забезпечують функції створення та ведення
БД, підтримують цілісність реляційної БД, Крім того, на них покладаються функції створення резервних копій БД і відновлення БД після збоїв, управління виконанням транзакцій і підтримки застарілих (успадкованих) додатків (legacy application). Відзначимо, що ця модель має більшу гнучкість, ніж дворівневі моделі. Найбільш помітні переваги моделі сервера додатків в тих випадках, коли клієнти виконують складні аналітичні розрахунки над базою даних, які відносяться до області OLAP-додатків. (On-line analytical processing.) У цій моделі велика частина бізнес-логіки клієнта ізольована від можливостей вбудованого SQL, реалізованого в конкретній СКБД, і може бути виконана на стандартних мовах програмування, таких як C, C ++, SmallTalk, Cobol. Це підвищує переносимість системи, її масштабованість.

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

Властивості транзакцій. Способи завершення транзакцій
На даний момент виділяють такі типи транзакцій: плоскі або класичні транзакції, ланцюгові транзакції і вкладені транзакції.
Можливі два варіанти завершення транзакції. Якщо всі оператори виконані транзакція фіксується. Фіксація транзакції - це дія, що забезпечує запис на диск змін в базі даних, які були зроблені в процесі виконання транзакції.
До тих пір поки транзакція не зафіксована, допустимо анулювання цих змін, відновлення бази даних у той стан, в якому вона була на момент початку транзакції. Фіксація транзакції означає, що всі результати виконання транзакції стають постійними.
Якщо в процесі виконання транзакції сталося щось таке, що робить неможливим її нормальне завершення, база даних повинна повернутись в початковий стан. Відкат транзакції - це дія, що забезпечує анулювання всіх змін даних, які були зроблені операторами SQL в тілі поточної незавершеної транзакції.
У стандарті ANSI / ISO SQL визначено модель транзакцій і функції операторів COMMIT і
ROLLBACK. Транзакція завершується одним з чотирьох можливих шляхів
1.
2.

оператор COMMIT означає успішне завершення транзакції оператор ROLLBACK перериває транзакцію, скасовуючи зміни, зроблені в базі даних в рамках цієї
3. успішне завершення програми, в якій була ініційована поточна транзакція, означає успішне завершення транзакції (начебто використали оператор COMMIT)
4. помилкове завершення програми перериває транзакцію (начебто використали оператор ROLLBACK).
У цій моделі кожен оператор, який змінює стан БД, розглядається як транзакція, тому при успішному завершенні цього оператора БД переходить в новий стійкий стан.
Надалі в СКБД SYBASE була реалізована розширена модель транзакцій, яка включає ще ряд додаткових операцій. У моделі SYBASE використовуються наступні чотири оператори:
1. Оператор BEGIN TRANSACTION повідомляє про початок транзакції. в моделі SYBASE початок транзакції задається явно за допомогою оператора початку транзакції.
2. Оператор COMMIT TRANSACTION повідомляє про успішне завершення транзакції. Цей оператор, як і оператор COMMIT, фіксує всі зміни, які вироблялися в БД у процесі виконання транзакції. 3. Оператор SAVE TRANSACTION створює усередині транзакції точку збереження, яка відповідає проміжному станом БД, збереженому на момент виконання цього оператора.
4.Оператор ROLLBACK має дві модифікації. Якщо цей оператор використовується без додаткового параметра, то він інтерпретується як оператор відкату всієї транзакції. Якщо ж оператор відкату має параметр і записаний у вигляді ROLLBACK B, то він інтерпретується як оператор часткового відкату транзакції в точку збереження B.
Звичайно, розширена модель транзакції, запропонована фірмою SYBASE, підтримує набагато більш гнучкий механізм виконання транзакцій. Однак це обумовлює додаткові витрати ресурсів системи - оператор виконує роботу, а зміни потім скасовуються зазвичай удосконалення в логіці обробки можуть виявитися більш оптимальним рішенням.

А ця вимога передбачає, зокрема, можливість відновлення узгодженого стану бази даних після будь-якого роду апаратних і програмних збоїв. Очевидно, що для виконання відновлень необхідна деяка додаткова інформація. У переважній більшості сучасних реляційних СКБД така надмірна додаткова інформація підтримується у вигляді журналу змін бази даних, що зветься Журналом транзакцій.
Отже, загальною метою журналізації змін баз даних є забезпечення можливості відновлення узгодженого стану бази даних після будь-якого збою. Загальними принципами відновлення є наступні: Розглянемо еволюцію типів організації подібних механізмів. В основному цей механізм визначається структурою реалізації серверних процесів, і часто він називається архітектурою сервера баз даних.
Спочатку, як ми вже відзначали, існувала модель, коли управління даними (функція сервера) і взаємодія з користувачем були поєднані в одній програмі. Це можна назвати нульовим етапом розвитку серверів БД.
Потім функції управління даними були виділені в самостійну групу - сервер, проте модель взаємодії користувача з сервером відповідала парадигмі "один-до-одного" , тобто сервер обслуговував запити тільки одного користувача (клієнта), і для обслуговування декількох клієнтів потрібно було запустити еквівалентну число серверів.
Для обслуговування великої кількості клієнтів на сервері повинно бути запущено велику кількість одночасно працюючих серверних процесів, а це різко підвищувало вимоги до ресурсів ЕОМ, на якій запускалися всі серверні процеси. У такій моделі вельми складно забезпечити взаємодію серверних процесів. Ця модель найпростіша, і історично вона з'явилася першою. Проблеми, що виникають в моделі "один-до-одного", вирішуються в архітектурі "систем з виділеним сервером", який здатний обробляти запити від багатьох клієнтів. Сервер єдиний володіє монополією на керування даними і взаємодіє одночасно з багатьма клієнтами (рис.
Логічно кожен клієнт пов'язаний з сервером окремої ниткою ("thread"), або потоком, за яким пересилаються запити. Така архітектура отримала назву многопотоковой односерверних
("multi-threaded").
Вона дозволяє значно зменшити навантаження на операційну систему, що виникає при роботі великої кількості користувачів ("trashing").

Так як сервер може виконуватися тільки на одному процесорі, виникає природне обмеження на застосування СКБД для мультипроцесорних платформ. У деяких системах ця проблема вирішується введенням проміжного диспетчера. Подібна архітектура називається архітектурою віртуального сервера ("vir-tual server")
В цій архітектурі клієнти підключаються не до реального сервера, а до проміжної ланки, названої диспетчером, який виконує тільки функції диспетчеризації запитів до актуальних серверів. Кількість актуальних серверів може бути узгоджене з кількістю процесорів в системі.
Сучасне рішення проблеми СКБД для мультипроцесорних платформ полягає в можливості запуску кількох серверів бази даних, в тому числі і на різних процесорах. При цьому кожен із серверів повинен бути багатопотоковим. Якщо ці дві умови виконані, то є підстави говорити про многопотокову архітектуру з декількома серверами, поданій на рис.
Вона також може бути названа багатонитковою мультисерверною архітектурою.Існує кілька можливостей розпаралелювання виконання запиту
Горизонтальний паралелізм – розбиває запит на декілька під запитів за рахунок розбиття множини записів запиту на окремі групи, кожна з яких обробляється під запитом. Ефективний при великому об»ємі записів в процесі виконання запиту
Вертикальний паралелізм - розбиття на підзапити шляхом виділення груп певних полів ( стовпців таблиць) і формування для кожної групи під запиту, що буде виконуватись паралельно до інших
Гібридний – комбінація двох попередніх паралелізмів.

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

• результати зафіксованих транзакцій повинні бути збережені у відновленому стані бази даних
• результати незафіксованих транзакцій повинні бути відсутніми у відновленому стані бази даних. Це, власне, і означає, що відновлюється останній за часом узгоджений стан бази даних.
Можливі два основні варіанти ведення журнальної інформації. У першому варіанті для кожної транзакції підтримується окремий локальний журнал змін бази даних цієї транзакцією. Такі журнали називаються локальними журналами. Вони використовуються для індивідуальних відкатів транзакцій і можуть підтримуватися в оперативній пам'яті. Крім того, підтримується загальний журнал змін бази даних, використовуваний для відновлення стану бази даних після м'яких і жорстких збоїв. Частіше використовується другий варіант - підтримка тільки загального журналу змін бази даних, який використовується і при виконанні індивідуальних відкатів. Далі ми розглядаємо саме цей варіант.
Усі транзакції мають свої внутрішні номери, тому в єдиному журналі транзакцій фіксуються всі зміни, що проводяться всіма транзакціями.Кожен запис в журналі транзакцій позначається номером транзакції, до якої вона належить, і значеннями атрибутів, які вона міняє. Крім того, для кожної транзакції в журналі фіксується команда початку і завершення транзакції (див. Рис.
Для більшої надійності журнал транзакцій часто дублюється системними засобами комерційних СКБД, саме тому обсяг зовнішньої пам'яті у багато разів перевищує реальний обсяг даних, які зберігаються в сховищі.
Є два альтернативних варіанти ведення журналу транзакцій: протокол з відкладеними оновленнями і протокол з негайними оновленнями.
При відкаті транзакції виконується системна процедура UNDO (), яка повертає всі старі значення скасованої транзакції, послідовно проходячи по протоколу починаючи з команди
BEGIN TRANSACTION.

Основним принципом узгодженої політики виштовхування буфера журналу і буферів сторінок бази даних є те, що запис про зміну об'єкта бази даних повинен потрапляти в зовнішню пам'ять журналу раніше, ніж змінений об'єкт виявляється в зовнішній пам'яті бази даних. Відповідний протокол журналізації (і управління буферизацією) називається Write Ahead Log (WAL) "пиши спочатку у журнал" і полягає в тому, що якщо потрібно записати в зовнішню пам'ять змінений об'єкт бази даних, то перед цим потрібно гарантувати запис у зовнішню пам'ять журналу транзакцій запису про його зміну.
Іншими словами, якщо у зовнішній пам'яті бази даних знаходиться деякий об'єкт бази даних, по відношенню до якого виконана операція модифікації, то в зовнішній пам'яті журналу обов'язково знаходиться запис, відповідний цій операції. Зворотне невірно, тобто якщо у зовнішній пам'яті журналі міститься запис про деяку операції зміни об'єкта бази даних, то сам змінений об'єкт може бути відсутнім у зовнішній пам'яті бази даних.
Додаткова умова на виштовхування буферів накладається тим вимогою, що кожна успішно завершилася транзакція повинна бути реально зафіксована у зовнішній пам'яті. Який би збій не сталося, система повинна бути _ змозі відновити стан бази даних, що містить результати всіх зафіксованих до моменту збою транзакцій.
Простим рішенням було б виштовхування буфера журналу, за яким слідує масове виштовхування буферів сторінок бази даних, змінювалися даної транзакцією. Досить часто так і роблять, але це викликає суттєві накладні витрати при виконанні операції фіксації транзакції. Виявляється, що мінімальною вимогою, що гарантує можливість відновлення останнього узгодженого стану бази даних, є виштовхування при фіксації транзакції в зовнішню пам'ять журналу всіх записів про зміну бази даних цієї транзакцією. При цьому останнім записом _ журнал, виробленої від імені даної транзакції, є спеціальний запис про кінець транзакції.

18. Особливості вбудованого SQL.
При об'єднанні операторів SQL c базовою мовою програмування повинні дотримуватися такі принципи:1. Оператори SQL включаються безпосередньо в текст програми на вихідній мові програмування. Вихідна програма надходить на вхід препроцесора SQL, який компілює оператори SQL. 2.Вбудовані оператори SQL можуть посилатися на змінні базової мови програмування. 3.Вбудовані оператори SQL отримують результати SQL-запитів за допомогою змінних базової мови програмування. 4.Для присвоєння невизначених значень (NULL) атрибутам відношень БД використовуються спеціальні функції. 4.Для забезпечення пострічної обробки результатів запитів у вбудований SQL додаються кілька нових операторів, які відсутні в інтерактивному SQL.
Оператори маніпулювання даними не вимагають зміни для їх вбудовування в програмний
SQL. Однак оператор пошуку (SELECT) зазнав змін.
Стандартний оператор SELECT повертає набір даних, релевантний сформованим умовам запиту. В інтерактивному SQL цей отриманий набір даних просто виводиться на консоль користувача і він може переглянути отримані результати. Вбудований оператор SELECT повинен створювати структури даних, які узгоджуються з базовими мовами програмування. У вбудованому SQL запити діляться на 2 типи:



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

Перший тип запиту - однорядковий запит у вбудованому SQL викликав модифікацію оператора SQL, яка виглядає наступним чином:
SELECT [{ALL | DISTINCT}]
INTO
FROM
[WHERE