Iphone
shpora.me - незаменимый помощник для студентов и школьников, который позволяет быстро создавать и получать доступ к шпаргалкам или другим заметкам с любых устройств. В любое время. Абсолютно бесплатно. Зарегистрироватся | Войти

* данный блок не отображается зарегистрированым пользователям и на мобильных устройствах

БД - лекції (до 12.10) -martik

Тема 1 Місце та роль баз даних (БД) та баз знань (БЗ) у сучасних комп’ютерних інформаційних технологіях

 

1.1 Роль використання баз даних у інформаційних технологіях

 

Бази даних стали невід'ємною частиною нашого повсякденного життя. Тому обговорення баз даних у цьому розділі ми почнемо з вивчення деяких додатків систем баз даних. У подальших міркуваннях будемо розглядати базу даних як якийсь набір зв'язаних даних, а систему керування базами даних, або СКБД (Database Management System – DBMS), як програмне забезпечення, що керує доступом до цієї бази даних. Більш строгі і точні визначення будуть наведені пізніше.

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

Якщо при покупках використовується кредитна картка, касир повинний перевірити наявність кредитних коштів. Це можна зробити або по телефону, або автоматично, за допомогою спеціального пристрою, що зчитує, зв'язаного з комп'ютером. У будь-якому випадку при цьому використовується якась база даних, що містить відомості про покупки, здійснюваних за допомогою кредитної картки. На основі номера кредитної картки спеціальний додаток звіряє ціну купуються в даний момент і куплених протягом цього місяця товарів із кредитним лімітом. Після підтвердження допустимості такої покупки всі відомості про придбані товари вводяться в базу даних. Однак ще до одержання підтвердження допустимості покупки додаток бази даних повинне переконатися в тім, що дана картка не знаходиться в списку украдених або загублених. Крім того, повинне існувати ще один самостійний додаток баз даних, що буде оплачувати рахунки після одержання суми платежу, а також щомісяця посилати кожному власникові кредитної картки повний звіт.

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

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

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

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

 

1.2 Порівняння файлових систем та БД

 

Традиційні файлові системи

Стало майже традицією те, що будь-яка книга з досить великим описом баз даних починається з огляду їхніх попередниць – файлових систем (file-based system). Ми також підемо цієї традиції. Незважаючи на те що файлові системи давно застаріли, усе-таки є кілька причин, по яких з ними варто познайомитися.

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

-  Знати принципи роботи файлових систем не тільки дуже корисно, але і необхідно при виконанні переходу від файлової системи до системи баз даних.

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

Файлові системи були першою спробою комп’ютеризувати відомі усім ручні картотеки. Подібна картотека (або підшивка документів) у деякій організації могла містити всю зовнішню і внутрішню документацію, зв'язану з яким-небудь проектом, продуктом, задачею, клієнтом або співробітником. Звичайно таких папок буває дуже багато, вони позначаються і зберігаються в одному або декількох шафах. З метою безпеки шафи можуть закриватися на замок або знаходитися в охоронюваних приміщеннях. У кожного з нас будинку є якась подоба такої картотеки, що містить підшивки документів, що представляють собою рахунки, гарантійні талони, рецепти, страхові і банківські документи і т.п. Якщо нам знадобиться якась інформація, буде потрібно переглянути картотеку від початку до кінця, щоб знайти шукані відомості. Більш витончений підхід передбачає використання в такій системі деякого алгоритму індексування, що дозволяє прискорити пошук потрібних відомостей. Наприклад, можна використовувати спеціальні роздільники чи окремі папки для різних логічно зв'язаних типів об'єктів.

Ручні картотеки дозволяють успішно справлятися з поставленими задачами, якщо кількість збережених об'єктів невелика. Вони також цілком годяться для роботи з великою кількістю об'єктів, які потрібно тільки зберігати і витягати. Однак вони зовсім не підходять для тих випадків, коли потрібно установити перехресні зв'язки або виконати обробку відомостей. Наприклад, у типовому агентстві по здачі в оренду об'єктів нерухомості може бути заведений окремий файл для кожного об’єкта, котрий здається в оренду або продається, для кожного потенційного покупця чи орендаря, а також для кожного співробітника компанії. Розглянемо тепер, які дії потрібно виконати, щоб відповісти на приведені нижче питання.

-  Які з виставлених на продаж об'єктів із трьома спальнями мають сад і гараж?

-  Які з квартир, що здаються в оренду, розташовані в межах трьох миль від центра міста?

-  Яка середня ціна будинку?

-  Яка середня орендна плата за квартиру з двома спальнями?

-  Чому дорівнює загальна річна заробітна плата всіх співробітників?

-  Яким був щомісячний оборот від продажів нерухомості торік?

-  Яким був оборот минулого місяця в порівнянні з прогнозованими показниками в цьому місяці?

-  Яким буде очікуваний щомісячний оборот у наступному фінансовому році?

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

Наприклад, співробітники відділу реалізації відповідають за продаж і оренду нерухомості. Наприклад, якщо клієнт звертається у відділ реалізації компанії з пропозицією здати в оренду приналежної йому об'єкт нерухомості, то йому потрібно заповнити форму, подібну представленої на мал. 1.1, а. У ній указуються такі відомості про об'єкт нерухомості, як адреса і кількість кімнат, а також інформація про власника. Крім того, співробітники відділу реалізації обробляють запити від потенційних орендарів, кожний з яких повинен заповнити форму, подібну представленій на мал. 1.1, б. За допомогою співробітників відділу обробки даних (ОД) співробітники відділу реалізації створили інформаційну систему для керування даними про оренду нерухомості. Ця система складається з трьох показаних у табл. 1.1-1.3 файлів з даними про нерухомість (Property_for_Rent), власнику (Owner) і орендарі (Renter). Для простоти викладу опустимо деталі, що відносяться до співробітників компанії, різним її відділенням і власникам нерухомості, що представляє собою юридичні особи.

Обмеження, властиві файловим системам

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

     Поділ і ізоляція даних.

     Дублювання даних.

     Залежність від даних.

     Несумісність файлів.

     Фіксовані запити/швидке збільшення кількості додатків.

Поділ і ізоляція даних

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

Дублювання даних

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

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

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

Залежність від даних

Як уже згадувалося вище, фізична структура і спосіб збереження записів файлів даних жорстко зафіксовані в коді програм додатків. Це значить, що змінити існуючу структуру даних досить складно. Наприклад, збільшення у файлі Property_for_Rent довжини полючи адреси з 40 до 41 символу здається зовсім незначною зміною його структури, але для втілення цієї зміни буде потрібно, як мінімум, створити одноразову програму спеціального призначення (тобто програму, що виконується тільки один раз), що перетворить вже існуючий файл Property_for_Rent у новий формат. Вона повинна виконувати наступні дії:

     відкрити вихідний файл Property_for_Rent для читання;

     відкрити тимчасовий файл із новою структурою запису;

     прочитати запис з вихідного файлу, перетворити дані в новий формат і записати їх у тимчасовий файл. Ці дії варто виконати для всіх записів вихідного файлу;

     видалити вихідний файл Property_for_Rent;

     присвоїти тимчасовому файлові ім'я Property_for_Rent.

Крім цього, всі, хто звертається до файлу Property_for_Rent програми повинні бути змінені з метою відповідності новій структурі файлу. Причому таких програм може бути дуже багато. Отже, програміст повинен насамперед виявити всі такі програми, а потім перевірити ще раз і змінити їх. Зверніть увагу, що багато підлягаючих змін програми можуть звертатися до файлу Property for Rent і при цьому взагалі не використовувати поле адреси. Ясно, що виконання всіх цих дій вимагає великих витрат часу і може стати причиною появи помилок. Дана особливість файлових систем називається залежністю від програм і даних (program-data dependence).

Несумісність форматів файлів

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

Наприклад, припустимо, що співробітникам відділу контрактів потрібно знайти імена й адреси усіх власників, нерухомість яких у даний час здана в оренду. На жаль, у відділі контрактів немає відомостей про власників нерухомості, тому що вони зберігаються тільки у відділі реалізації. Однак у файлах відділу контрактів є поле Property Number з номерами об'єктів нерухомості, які можна використовувати для пошуку відповідних номерів у файлі Property_for_Rent відділу реалізації. Цей файл також містить поле Owner Number з номерами власників, які можна використовувати для пошуку відомостей про власників у файлі Owner. Припустимо, що програма відділу контрактів створена мовою COBOL, а програма відділу реалізації – мовою С. Тоді з метою пошуку відповідних номерів об'єктів нерухомості в поле Property Number у двох файлах Property_for_Rent програмістові буде потрібно створити програмне забезпечення, призначене для перетворення цих полів у деякий загальний формат. Не викликає сумніву, що цей процес часто може виявитися досить тривалим і дорогим.

Фіксовані запити/швидке збільшення кількості додатків

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

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

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

Системи з базами даних

Усі перераховані вище обмеження файлових систем є наслідком двох факторів.

1.      Визначення даних утримується усередині додатків, а не зберігається окремо і незалежно від них.

2.      Крім додатків не передбачено ніяких інших інструментів доступу до даних і їхній обробки.

Для підвищення ефективності роботи необхідно використовувати новий підхід, а саме базу даних (database) ісистему керування базами даних,  або СКБД (Database Management System – DBMS).

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

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

Щоб глибше вникнути в суть цього поняття, розглянемо його визначення більш уважно. База даних – це єдине, велике сховище даних, що однократно визначається, а потім використовується одночасно багатьма користувачами з різних підрозділів. Замість розрізнених файлів з надлишковими даними, тут усі дані зібрані разом з мінімальною часткою надмірності. База даних уже не належить якому-небудь єдиному відділові, а є загальним корпоративним ресурсом. Причому база даних зберігає не тільки робітники дані цієї організації, але і їхнього опису. З цієї причини базу даних ще називають набором інтегрованих записів із самоописом. У сукупності, опис даних називається системним каталогом(system catalog), або словником даних (data dictionary), а самі елементи опису прийняті називати метаданими (meta-data), тобто "даними про дані". Саме наявність самоопису даних у базі даних забезпечує в ній незалежність між програмами і даними (program-data independence).

Підхід, заснований на застосуванні баз даних, де визначення даних відділене від додатків, дуже схожий на підхід, використовуваний при розробці сучасного програмного забезпечення, коли поряд із внутрішнім визначенням об'єктаіснує його зовнішнє визначення. Користувачі об'єкта бачать тільки його зовнішнє визначення і не піклуються про те, як він визначається і як функціонує. Одне з переваг такого підходу, а саме абстрагування даних (data abstraction), полягає в тому, що можна змінити внутрішнє визначення об'єкта без яких-небудь наслідків для його користувачів, за умови, що зовнішнє визначення об'єкта залишається  незмінним. Аналогічним чином, у підході з використанням баз даних, структура даних відділена від додатків і зберігається в базі даних. Додавання нових структур даних або зміну існуючих ніяк не впливає на додатки, за умови, що вони не залежать безпосередньо від змінюваних компонентів. Наприклад, додавання нового поля в запис або створення нового файлу ніяк не вплине на роботу наявних додатків. Однак видалення полючи з використовуваного додатком файлу вплине на цей додаток, а тому його також буде потрібно відповідним чином модифікувати.

І, нарешті, варто пояснити останній термін з визначення бази даних, а саме поняття "логічно зв'язаний". При аналізі інформаційних потреб організації варто виділити сутності, атрибути і зв'язки. Сутністю (entity) називається окремий тип об'єкта організації (людина, місце або річ, поняття або подія), якому потрібно представити в базі даних. Атрибутом (attribute) називається властивість, що описує деяку характеристику описуваного об'єкта; зв'язок (relationship) – це те, що поєднує кілька сутностей.

Система керування базами даних – СКБД

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

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

1.     Дозволяє визначати базу даних, що звичайно здійснюється за допомогою мови визначення даних (DDL – Data Definition Language). Мова DDL надає користувачам засобу вказівки типу даних і їхньої структури, а також засобу завдання обмежень для інформації, збереженої в базі даних.

2.     Дозволяє вставляти, обновляти, видаляти і витягати інформацію з бази даних,   що   звичайно  здійснюється   за   допомогою   мови   керування  даними (DML – Data Manipulation Language). Наявність централізованого сховища всіх даних і їхніх описів дозволяє використовувати мову DML як загальний інструмент організації запитів, що іноді називають мовою запитів (query language). Наявність мови запитів дозволяє усунути властивим файловим системам обмеження, при яких користувачам доводиться мати справа тільки з фіксованим набором запитів або постійно зростаючою кількістю програм, що породжує інші, більш складні проблеми керування програмним забезпеченням.

Існує два різновиди мов DML – процедурні (procedural) і непроцедурні (non-procedural) мови, – які відрізняються між собою способом витягу даних. Основна відмінність між ними полягає в тому, що процедурні мови звичайно обробляють інформацію в базі даних послідовно, запис за записом, а непроцедурні оперують відразу цілими наборами записів. Тому за допомогою процедурних мов DML звичайно вказується, як можна одержати бажаний результат, тоді як непроцедурні мови DML використовуються для опису того, що варто одержати. Найбільш розповсюдженим типом непроцедурної мови є мова структурованих запитів (Structured Query Language – SQL), що у даний час визначається спеціальним стандартом і фактично є обов'язковою мовою для будь-яких реляційних СКБД.

3.     Надає контрольований доступ до бази даних за допомогою перерахованих нижче засобів:

-       системи забезпечення безпеки, що  запобігає несанкціонований доступ до бази даних з боку користувачів;

-       системи підтримки цілісності даних, що забезпечує несуперечливий стан збережених даних;

-       системи керування рівнобіжною роботою додатків, що контролює процеси їхнього спільного доступу до бази даних;

-       системи  відновлення, що   дозволяє  відновити  базу  даних  до попереднього несуперечливого стану, порушеного в результаті збою апаратного або програмного забезпечення;

-       доступного користувачам каталогу, що містить опис збереженої в базі дані інформації.

На рисунку 1.2 показаний приклад реалізації підходу з застосуванням бази даних для розглянутого раніше варіанта з використанням файлової системи (див. рис. 1.1). У новому варіанті відділ реалізації і відділ контрактів використовують власні додатки для доступу до загальної бази даних, організованої за допомогою СКБД. Набір додатків кожного відділу забезпечує введення і коректування даних, а також генерацію необхідних звітів. Однак, на відміну від варіанта з файловою системою, фізична структура і спосіб збереження даних у цьому випадку контролюються за допомогою СКБД.

олодіння зазначеними вище функціональними можливостями перетворює СКБД у надзвичайно корисний інструмент.  Однак, оскільки для кінцевих користувачів неважливо, наскільки проста або складна внутрішня організація системи, можна почути заперечення, що СКБД ускладнює роботу, надаючи користувачам набагато більшу кількість даних, чим їм дійсно потрібно. Як видно з рис. 1.2, у підході, заснованому на використанні баз даних, необхідні співробітникам відділу контрактів докладні зведення про об'єкти нерухомості організовані трохи інакше, чим у варіанті з файловою системою, представленому на рис. 1.1. Тепер у базі даних також утримуються відомості про тип нерухомості, число кімнат і про власника об'єкта. Для рішення цієї проблеми в СКБД пропонується інший механізм – створення представлень (view), – який дозволяє будь-якому користувачеві мати свій власний погляд на базу даних. Мова DDL включає засобу визначення представлень, кожне з яких є деякою підмножиною бази даних. Наприклад, можна організувати представлення, у якому співробітникам відділу контрактів будуть доступні тільки ті дані, що необхідні для оформлення договорів оренди.

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

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

-       Надають механізм настроювання зовнішнього інтерфейсу бази даних. Наприклад, співробітники відділу контрактів можуть працювати з полем Monthly Rent (Щомісячна орендна плата), використовуючи для нього більш коротке і просте ім'я – Rent.

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

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

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

 

Компоненти середовища СКБД

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

 

Рисунок 1.3 – Середовище СКБД

 

Апаратне забезпечення

Для роботи СКБД і додатків необхідно мати деяке апаратне забезпечення. Воно може варіювати в дуже широких межах – від єдиного персонального комп'ютера або одного мейнфрейма до мережі з багатьох комп'ютерів.Використовуване апаратне забезпечення залежить від вимог даної організації і використовуваної СКБД. Одні СКБДпризначені для роботи тільки з конкретними типами операційних систем або устаткування, інші можуть працювати із широким колом апаратного забезпечення і різних операційних систем. Для роботи СКБД звичайно потрібно деякий мінімум оперативної і дискової пам'яті, але такої мінімальної конфігурації може виявитися зовсім недостатньо для досягнення прийнятної продуктивності системи. Типова корпоративна інформаційна система з базою даних складається з мережі  персональних комп'ютерів та центрального комп'ютера. На центральному комп'ютері працює серверна частинаСКБД (backend), що обслуговує і контролює доступ до бази даних. На решті комп’ютерів працюють клієнтські частиниСКБД (frontend), що здійснюють взаємодію з користувачами. Подібна архітектура зветься клієнт/сервер (client-server), де сервером є комп'ютер із серверною частиною СКБД, а клієнтами – комп'ютери з клієнтськими частинами СКБД.

Програмне забезпечення

Цей компонент охоплює програмне забезпечення самої СКБД і прикладних програм, разом з операційною системою, включаючи і мережеве програмне забезпечення, якщо СКБД використовується в мережі. Звичайно додатки створюються на мовах третього покоління, таких як С, COBOL, Fortran, Ada або Pascal, або на мовах четвертого покоління, таких як SQL, оператори яких впроваджуються в програми на мовах третього покоління. Утім, СКБД може мати свої власні інструменти четвертого покоління, призначені для швидкої розробки додатків з використанням вбудованих непроцедурних мов запитів, генераторів звітів, форм, графічних зображень і навіть повномасштабних додатків. Використання інструментів четвертого покоління може істотно підвищити продуктивність системи і сприяти створенню більш зручних для обслуговування програм.

Дані

Імовірно, найважливішим компонентом середовища СКБД (з погляду кінцевих користувачів) є дані. На рис. 1.3 показано, що дані відіграють роль моста між комп'ютером і людиною. база даних містить як робочі дані, так і метадані, тобто "дані про дані". Структура бази даних називається схемою (schema).

У системному каталозі утримуються наступні зведення:

-       імена, типи і розміри елементів даних;

-       імена зв'язків;

-       обмеження цілісності даних;

-       імена зареєстрованих користувачів, яким надані певні права доступу до даних;

-       використовувані індекси і структури збереження – наприклад, інвертовані файли або дерева.

Процедури

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

-       Реєстрація в СКБД.

-       Використання окремого інструмента СКБД або додатка.

-       Запуск і зупинка СКБД.

-       Створення резервних копій СКБД.

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

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

Користувачі

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

1.2 Життєвий цикл інформаційних систем

 

Інформаційна система – Ресурси, що дозволяють виконувати збір, коректування і розповсюдження інформації всередині організації.

Починаючи з 70-х років системи баз даних стали поступово заміняти файлові системи, що використовувалися як частина інфраструктури інформаційних систем (Information System — IS) організацій. Паралельно з цим росло визнання того факту, що дані є важливим корпоративним ресурсом, до якого потрібно відноситися так само шанобливо, як і до інших ресурсів організації. Це привело до того, що в багатьох організаціях з'явилися цілі відділи або функціональні підрозділи, що займалися адмініструванням даних (АД) і адмініструванням баз даних (АБД). Вони відповідали за обробку і керування корпоративними даними і корпоративними базами даних відповідно.

Типова комп'ютеризована інформаційна система включає такі компоненти, як:

-       база даних;

-       програмне забезпечення бази даних;

-       прикладне програмне забезпечення;

-       апаратне забезпечення, у тому числі пристрою збереження;

-       персонал, що використовує і розробляє цю систему.

База даних є фундаментальним компонентом інформаційної системи, а її розробку і використання варто розглядати з погляду самих широких вимог організації. Отже, життєвий цикл інформаційної системи організації невід'ємно зв'язаний з життєвим циклом системи бази даних, підтримуючої його. Життєвий цикл інформаційної системи звичайно складається з декількох етапів: планування, збір і аналіз вимог, проектування (включаючи проектування бази даних), створення прототипу, реалізація, тестування, перетворення даних і супровід. Слід зазначити, що розробку будь-якого додатка бази даних завжди корисно розглядати, як розробку визначеного компонента всієї інформаційної системи організації в цілому.

Терміни "функціональна сфера" і "область застосування додатку" відносяться до окремих напрямків ділової активності всередині організації — наприклад, до маркетингу, роботи з персоналом або до управління товарними запасами.

Як уже згадувалося вище, система бази даних є фундаментальним компонентом більш широкого поняття — інформаційної системи організації. Отже, життєвий цикл додатків баз даних нерозривно зв'язаний з життєвим циклом інформаційної системи. Варто визнати, що етапи життєвого циклу не є строго послідовними, а включають деяку кількість повторів попередніх кроків у вигляді циклів зворотного зв'язку (feedback loop). Наприклад, при проектуванні бази даних можуть виникнути проблеми, для вирішення яких буде потрібно повернутися до етапу збору й аналізу вимог. Цикли зворотного зв'язку можуть виникати майже між всіма етапами.

Нижче перераховані основні дії, виконувані на кожнім етапі життєвого циклу бази даних.

-       Планування розробки бази даних. Планування найефективнішого способу реалізації етапів життєвого циклу системи.

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

-       Збір і аналіз вимог користувачів. На цьому етапі виконується збір і аналіз вимог користувачів із усіх можливих областей застосування.

-       Проектування бази даних. Повний цикл розробки включає концептуальне, логічне і фізичне проектування бази даних.

-       Вибір цільової СУБД (необов'язково). На цьому етапі виконується вибір найбільш підходящої СУБД для додатка бази даних.

-       Розробка додатків. Визначення користувальницького інтерфейсу і прикладних програм, що використовують і обробляють базу даних.

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

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

-       Конвертування і завантаження даних. На цьому етапі виконується перетворення і завантаження даних (і прикладних програм) зі старої системи в нову.

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

-       Експлуатація і супровід. На цьому етапі додаток бази даних вважається цілком розробленим і реалізованим. Надалі вся система буде знаходитися під постійним спостереженням і відповідним чином підтримуватися. У разі потреби у функціонуючий додаток можуть вноситися зміни, що відповідають новим вимогам. Реалізація цих змін проводиться за допомогою повторного виконання деяких з перерахованих вище етапів життєвого циклу.

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

 

Рисунок 1.4 – Графічне зображення життєвого циклу інформаційної системи

 

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

 

1.3 Модель інформаційної системи та місце бази даних в цій моделі

 

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

 

Рисунок 1.5 – Схема інформаційної системи з точки створення додатку

 

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

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

1.4 Бізнес-процеси – основа для проектування бази даних

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

Можливий різний ступінь деталізації бізнес-процесів. Наприклад, можна виділити такий процес, як бухгалтерія, а можна розбити його на окремі складові (каса, зарплата, основні фонди тощо).

Кожен бізнес-процес протікає згідно певних бізнес-правил.

Бізнес-правило – це опис даних з точки зору організації. Наприклад, кожен працівник не може вести більше 10 клієнтів, або максимальна сума кредиту для клієнта в банку становить не більше 10000 грн. і т.п. Зрозуміло, що в іншій організації такі обмеження можуть бути інші або й зовсім відсутні.

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

 

Рисунок 1.6 – Схематичне зображення бізнес-процесу

 

З рисунка видно, що модуль для моделювання обраного бізнес-процесу потрібно мати вхідну інформацію у вигляді набору форм (документів). Алгоритм роботи модуля визначається через зображені на рисунку 1.6 функції керування. [?]Бізнес-правила[/?] показані у вигляді обмежень. В результаті на виході модуля отримується вихідний документ, як правило, у вигляді форми.

Зображення бізнес-процесів має не лише естетичне чи наглядне значення. Для проектування баз даних на сьогодні застосовуються CASE-засоби автоматизованого проектування. Для їх роботи вхідні дані мають бути стандартизовані. Саме таке зображення бізнес-процесу може бути використане при використанні засобів автоматизованого проектування БД. Набір вхідних і вихідних даних становлять базу даних обраного бізнес-процесу.

Усі бізнес-процеси для кожної предметної області, природно, пов’язані. Такий пов’язаний набір моделей бізнес-процесів становить концептуальну модель бази даних (рисунок 1.7).

 

Рисунок 1.7 – Концептуальна модель предметної області на основі моделей бізнес-процесів (БП) та їх баз даних (БД)

 

На основі такої моделі можна в першому наближенні описати архітектуру майбутньої інформаційної сиатеми.

Природним є те, що в рамках однієї предметної області для багатьох бізнес-процесів використовуються спільні дані (наприклад, відділ кадрів і бухгалтерія). Тому природним є також перехід від багатьох баз даних кожного бізнес-процесу до однієї централізованої бази даних для обраної предметної області (рисунок 1.8).

 

Рисунок 1.8 – Концептуальна модель предметної області з використанням централізованої бази даних (ЦБД) та користувачами (К)

 

На рисунку 1.8 можна виділити два рівні моделі: бізнес процеси і користувачі – І рівень, ЦБД – ІІ рівень.

Якщо перенести таку модель на комп’ютерну мережу, то отримаємо архітектуру "клієнт-сервер" (рисунок 1.9).

 

Рисунок 1.9 – Архітектура інформаційної системи типу "клієнт-сервер"

 

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

 

Рисунок 1.10 – Трирівнева архітектура інформаційної системи

 

Тому використовують також багаторівневу архітектуру (як правило – трирівневу), в котрій реалізація бізнес-правил винесена на окремий рівень – на сервер застосувань або інша його назва – сервер додатків (application server). Така архітектура зоражена на рисунку 1.10.

Для такої архітектури характерним є те, що на стороні клієнта реалізовано лише інтерфейс користувача, а вся бізнс-логіка знаходиться на сервері застосувань. Таку систему називають також системою з тонким клієнтом.

Проектування трирівневої інформаційної системи полягає у розробці центрпалізованої бази даних та написанні програм реалізації бізнес-процесів. Оскільки всі бізнес-процеси є типовими, то для їх реалізації можна використовувати готові типові модулі, адаптувавши їх до потреб конкретної предметної області. Сукупність таких типізованих модулів називається ERP(Enterprise Resource Planning) – планування ресурсів підприємства – наприклад, відома система 1С викорисстовує саме такий підхі.

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

 

ЛЕКЦІЯ 2 Загальний огляд процедур проектування баз даних

 

Тема 2 Загальний огляд процедур проектування баз даних

 

При розгляді попередньої теми було обговорено основні етапи життєвого циклу прикладної програми, бази даних. Одним з них є проектування бази даних. Воно починається по завершенні процедури аналізу усіх вимог до проекту, висунутих з боку підприємства-замовника.

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

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

-       Логічне проектування – перетворення концептуального представлення в логічну структуру бази даних, включаючи проектування відношень.

-       Фізичне проектування – ухвалення рішення про те, як логічна модель буде фізично реалізована у базі даних, створюваної за допомогою обраної СКБД.

 

3.1 Введення в методологію проектування баз даних

 

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

Методологія проектування – структурований підхід, що передбачає використання спеціалізованих процедур, технічних прийомів, інструментів, документації і націлений на підтримку і спрощення процесу проектування.

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

 

3.2 Концептуальне, логічне і фізичне проектування бази даних

 

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

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

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

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

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

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

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

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

Концептуальне проектування бази даних

Етап 1. Створення локальної концептуальної моделі даних виходячи з представлень про предметну область кожного з типів користувачів.

Етап 1.1.   Визначення типів сутностей.

Етап 1.2.   Визначення типів зв'язків.

Етап 1.3.   Визначення атрибутів і зв'язування їх з типами сутностей і зв'язків.

Етап 1.4.   Визначення доменів атрибутів.

Етап 1.5.   Визначення атрибутів, що є потенційними і первинними ключами.

Етап 1.6.   Спеціалізація або генералізація типів сутностей (необов'язковий етап).

Етап 1.7.   Створення діаграми "сутність-зв'язок".

Етап 1.8.   Обговорення локальних концептуальних моделей даних з кінцевими користувачами.

Логічне проектування бази даних (для реляційної моделі)

Етап 2. Побудова і перевірка локальної логічної моделі даних на основі уявлення про предметну область кожного з типів користувачів.

Етап 2.1.   Перетворення локальної концептуальної моделі даних у локальну логічну модель.

Етап 2.2.   Визначення набору відношень виходячи зі структури локальної логічної моделі даних.

Етап 2.3.   Перевірка моделі за допомогою правил нормалізації.

Етап 2.4.   Перевірка моделі у відношенні транзакцій користувачів.

Етап 2.5.   Створення діаграм "сутність-відношення".

Етап 2.6.   Визначення вимог підтримки цілісності даних.

Етап 2.7.   Обговорення розроблених локальних логічних моделей даних з кінцевими користувачами.

Етап 3. Створення і перевірка глобальної логічної моделі даних.

Етап 3.1.   Злиття локальних логічних моделей даних у єдину глобальну модель даних.

Етап 3.2.   Перевірка глобальної логічної моделі даних.

Етап 3.3.   Перевірка можливостей розширення моделі в майбутньому.

Етап 3.4.   Створення остаточного варіанта діаграми "сутність-відношення".

Етап 3.5.   Обговорення глобальної логічної моделі даних з користувачами.

Фізичне проектування бази даних (з використанням реляційної СКБД)

Етап 4. Перенос глобальної логічної моделі даних у середовище цільової СКБД.

Етап 4.1.   Проектування основних таблиць у середовищі цільової СКБД.

Етап 4.2.   Реалізація бізнес-правил підприємства в середовищі цільової СКБД.

Етап 5. Проектування фізичного представлення бази даних.

Етап 5.1.   Аналіз транзакцій.

Етап 5.2.   Вибір файлової структури.

Етап 5.3.   Визначення вторинних індексів.

Етап 5.4.   Аналіз необхідності введення контрольованої надмірності даних.

Етап 5.5.   Визначення вимог до дискової пам'яті.

Етап 6. Розробка механізмів захисту.

Етап 6.1.   Розробка представлень користувача (переглядів).

Етап 6.2.   Визначення прав доступу.

Етап 7. Організація моніторингу і настроювання функціонування системи.

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

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

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

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

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



ЛЕКЦІЯ 3

3 Логічне проектування бази даних та модель "сутність-відношення"

 

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

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

3.1. Перетворення локальної концептуальної моделі даних в локальну логічну модель.

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

Даний етап включає:

-  видалення зв’язків з кардинальністю "багато до багатьох";

-  видалення складених зв’язків (котрі з’єднують більше двох типів сутностей;

-  видалення рекурсивних зв’язків;

-  видалення зв’язків з атрибутами;

-  видалення множинних атрибутів;

-  перепровірка зв’язків з кардинальністю "1:1";

-  видалення надлишкових зв’язків.

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

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

Видалення складених типів зв’язків відбувається аналогічно до процесу заміни зв’язків з кардинальністю "багато до багатьох" – шляхом введення додаткового типу сутності. Наприклад, якщо типи сутностей "Орендар", "Працівник агенції" та "Об’єкт" пов’язані одним потрійним зв’язком, то шляхом введення нового типу сутності "Угода оренди" даний зв'язок перетвориться на три парних з кардинальністю "один до багатьох": працівник організовує укладання угоди, об’єкт є предметом угоди, орендар володіє угодою.

Рекурсивні зв’язки виникають, коли певний тип сутності взаємодіє сам з собою. Наприклад, для відображення ситуації, коли один з працівників керує групою інших (зв’язок "один до багатьох"), в моделі даних виникає рекурсивний зв’язок. Адже кожен керівник теж є працівником (зв’язок "багато до багатьох"). Для усунення такого зв’язку вводять додатковий слабкий тип сутності. Для даного прикладу можна ввести тип сутності "Окремі працівники", який буде зв’язаний з сутністю "Працівник" зв’язком "1:1" для відображення того, що керівник є працівником, та зв’язком "1:М" для відображення того, що керівник керує декількома працівниками.

Наявність зв’язків з атрибутами означає, що предметна область проаналізована недостатньо. Коли зв’язок має атрибути, то теж потрібно виділити додатковий тип сутності і атрибути зв’язку стануть атрибутами цього типу сутності. Наприклад, коли між типами сутностей "Погодинний працівник" та "Відділення компанії" встановлено зв’язок, для якого встановлено атрибут, який відповідає за кількість відроблених працівником годин, то після введення додаткового слабкого типу сутності "Належність до відділення" атрибут про кількість відроблених годин увійде до складу цього типу сутності. Він, в свою чергу, буде пов’язаний з двома типами сутностей зв’язками з кардинальностями "1:М".

Нагадаємо, що множинні атрибути, це ті, які для одного екземпляру типу сутності можуть мати декілька значень. Наприклад, декілька номерів телефонів для однієї людини. Усунення такого множинного атрибуту відбувається теж введенням додаткового типу сутності, пов’язаного з основним зв’язком "1:М". Для нашого прикладу виділяється сутність "Телефон" з атрибутом "Номер телефону".

Наявність в моделі декількох зв’язків між двома типами сутностей може означати, що деякі з цих зв’язків надлишкові (зайві). Але при їх усуненні варто бути обережним, щоби не видалити деякі залежності, важливі в розроблюваній предметній області.

3.2. Визначення набору відношень.

Тут виконується визначення набору відношень (таблиць) для бази даних на основі визначених типів сутностей.

На даному етапі визначають і описують (документують):

–       сильні типи сутностей;

–       слабкі типи сутностей з вказанням зовнішніх ключів для зв’язку з сильними типами сутностей, які є визначальними для даного слабкого типу;

–       аналіз зв’язків "1:1" з метою можливого об’єднання цих типів сутностей в один і представлення його у вигляді одного відношення;

–       аналіз зв’язків "1:М" для встановлення зовнішніх ключів у типах сутностей зі ступінню участі в зв’язку М. Це виконується з метою встановлення зв’язку між відношеннями БД. Зовнішні ключі можна створити шляхом перенесення копії первинного ключа відношення зі сторони 1 в інше відношення зі сторони М;

–       зв’язки типу "суперклас/підклас", які утворюються внаслідок виконання спеціалізації чи генералізації можуть відображатись в логічній моделі зв’язками з кардинальністю "1:1".

3.3. Перевірка моделі з допомогою правил нормалізації.

Ціллю даного кроку є усунення зайвої надлишковості даних з метою усунення різного роду аномалій поновлення даних.

Процес нормалізації буде окремо обговорений в подальших заняттях.

3.4. Перевірка моделі стосовно можливості виконання всіх транзакцій користувача.

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

3.5. Створення ER-діаграми (діаграми "сутність-відношення").

Для забезпечення можливості автоматизації створення БД за допомогою CASE-засобів створюється ER-діаграма.

Про використання автоматизованої методики розробки баз даних буде сказано в наступних заняттях, присвячених цій тематиці. А зараз розглянемо деякі основні питання побудови ER-діаграм.

Модель "сутність-відношення" (Entity-Relationship model або ER-модель) розроблена для полегшення проектування баз даних (БД). Основними концепціями моделі "сутність-зв’язок" є типи сутностей, типи зв’язків та атрибути.

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

Тип сутності (entity type) представляє множину об’єктів з однаковими властивостями. Це можуть бути як об’єкти з фізичним існуванням, так і об’єкти з концептуальним (абстрактним) існуванням. Приклади наведені в таблиці 3.1.

 

Таблиця 3.1 – Приклади сутностей з фізичним та концептуальним існуванням

Фізичне існування

Концептуальне існування

Робітник

Огляд об’єкту нерухомості

Об’єкт нерухомості

Інспекція об’єкту нерухомості

Клієнт

Продаж об’єкту нерухомості

Деталь

Робочий стаж

Постачальник

 

Виріб

 

 

Сутність – екземпляр типу сутності. Котрий може бути ідентифікований унікальним чином. Тобто це об’єкт типу сутності.

Провівши аналогію з об’єктно-орієнтованим підходом до програмування, тип сутностей є класом, а сутність – об’єктом цього класу.

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

Отже, кожен тип сутності має свій унікальний набір атрибутів, а кожна сутність – має свої власні значення для кожного атрибуту.

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

Слабкий тип сутності – тип сутності, існування якого залежить від якогось типу сутності.

Сильний тип сутності – тип сутності, існування якого не залежить від якогось іншого типу сутності.

Наприклад, якщо в БД є типи сутностей "Клієнт" та "Контактна особа", то клієнт – це сильний тип сутності, а "Контактна особа" – слабкий, оскільки наявність у БД цього типу сутності без першого не має змісту. На ER-діаграмі сильний тип сутностей позначають прямокутником з одиночною рамкою, а слабкий – з подвійною. Назву сутності пишуть всередині прямокутника.

Слабкі сутності інколи називають дочірніми (child), залежними (dependent) або підлеглими (subordinate), а сильні – батьківськими (parent), сутностями-власниками (owner) або домінантними (dominant).

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

Атрибути діляться на:

–            прості – атрибут, що складається з одного компонента з незалежним існуванням. Прості атрибути не можуть бути розділені на дрібніші компоненти;

–            складені – атрибути, що складаються з декількох компонентів, кожен з яких характеризується незалежним існуванням. Наприклад, атрибут "адреса" складений, оскільки його можна розбити на окремі частини: назва вулиці номер дому, номер квартири;

–            однозначні – атрибут має для кожної сутності тільки одне значення. Більшість атрибутів саме однозначні;

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

–            похідні – атрибути, значення яких є похідними від значень зв’язаного з ним атрибуту чи якоїсь множини атрибутів, що належать деякому, не обов’язково даному, типу сутності. Наприклад, вік людини – похідний атрибут від року народження. Є також похідні атрибути, пов’язані з багатьма сутностями даного типу сутностей. Це, як правило, агрегатні характеристики: кількість, сума, мінімальне значення, максимальне, середнє.

На ER-діаграмі атрибути зображуються у вигляді еліпсів, приєднаних до прямокутника, що означає тип сутності. Якщо атрибут є складеним, то його складові частини зображуються приєднаними до даного складеного атрибуту. Для позначення похідних атрибутів еліпс позначають пунктиром, а для позначення багатозначних атрибутів використовують подвійний контур еліпса. Ім’я атрибуту, який є первинним ключем, підкреслюється. Для спрощення зображення часто тип сутності зображають прямокутником з написом назви типу сутності, а атрибути теж вписують у цей прямокутник. Приклади можливих зображень зображено на рисунку 3.1.

 

Description: ER-diagramm

Рисунок 3.1 - Приклади зображення типів сутностей на ER-діаграмі.

а) – повне зображення типу сутності "Штат працівників (Staff)";

б) спрощене зображення типу сутності "Штат працівників".

 

На діаграмах атрибути зображуються у вигляді еліпсів, приєднаних лінією до відповідної сутності і позначених ім'ям атрибута.

Еліпс оточений пунктирним контуром, якщо атрибут є похідним, і подвійним контуром, якщо атрибут є багатозначним.

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

Кожен зв'язок зображується у виді ромбика з зазначеним на ньому іменем зв'язку. Ромбик має подвійний контур, якщо зв'язок з'єднує слабку сутність із сильною сутністю, від якої ця слабка сутність залежить.

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

Ступінь зв'язку – кількість сутностей, що охоплені даним зв'язком.

Охоплені деяким зв'язком сутності називаються учасниками цього зв'язку. Кількість учасників деякого зв'язку називається ступенем (degree) цього зв'язку. Отже, ступінь зв'язку вказує на кількість типів сутностей, охоплених даним зв'язком. Зв'язок зі ступенем два називається бінарної (binary). Прикладом бінарного зв'язку є зв'язок Owns(володіє) із двома учасниками: Owner і Property_for_Rent.

Зв'язок зі ступенем три називається тернарним (ternary). Прикладом такого зв'язку є зв'язок SetsUp(Організовує) із трьома учасниками: Client, Staff і Interview. Призначення цього зв'язку складається в представленні ситуації, коли співробітник відповідає за організацію інтерв'ю з клієнтом.

Зв'язок зі ступенем чотири називається кватернарним (quaternary). Прикладом кватернарной зв'язку є зв'язокArranges (влаштовує, впорядковує) з чотирма сутностями-учасниками: Buyer (Покупець), Solicitor (Довірена особа), Financial_Institution (Фінансовий орган) і Bid (Пропозиція). Цей зв'язок представляє ситуацію, коли покупець за допомогою довіреної особи і за підтримкою фінансового органу виражає свій намір придбати об'єкт нерухомості.

Рекурсивний зв'язок – зв'язок, у якому ті самі сутності беруть участь кілька разів і в різних ролях.

Розглянемо рекурсивний зв'язок Supervises, що представляє взаємозв'язок персоналу з керуючим, що також входить до складу персоналу. Інакше кажучи, сутність Staff двічі бере участь у зв'язку Supervises: перший раз – у якості керуючого, а другий – як співробітника, яким керують. Рекурсивні зв'язки іноді називаються унарними (unary).

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

Рольові імена можуть також використовуватися, коли дві сутності зв'язані декількома зв'язками. Наприклад, сутності Staff і Branch зв'язані двома різними зв'язками – Manages і IsAllocated. Використання рольових імен істотно проясняє призначення кожного зв'язку. Наприклад, у випадку, коли сутність Staff зв'язана із сутністю Branch зв'язком Manages,співробітник (сутність Staff) з рольовим іменем Керівник (Manager) керує (зв'язок Manages) відділенням компанії з рольовим іменем Відділення компанії (Branch Office). Аналогічно, коли сутність Branch зв'язана із сутністю Staff зв'язкомIsAllocated, то співробітник з рольовим іменем Працівник (Member of Staff) є приписаним до відділення компанії з рольовим іменем Відділення компанії (Branch Office).

Рольові імена звичайно не потрібні, якщо функції сутностей – учасниць даного зв'язку визначені недвозначно.

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

Показник кардинальності – описує кількість можливих зв'язків для кожної із сутностей-учасниць.

Найбільш розповсюдженими є бінарні зв'язки з показниками кардинальності "один до одного" (1:1), "один до багатьох" (1:М) і "багато до багатьох" (M:N).

Ступінь участі – визначає, чи залежить існування деякої сутності від участі в зв'язку деякої іншої сутності.

Існує два варіанти участі сутності в зв'язку: повна (total) і часткова (partial). Ступінь участі є повною, якщо для існування деякої сутності потрібне існування іншої сутності, зв'язаної з нею визначеним зв'язком. У противному випадку ступінь участі є частковою. Наприклад, у випадку зв'язку IsAllocated між сутностями Branch і Staff участь сутності Branch у цьому зв'язку є повним, оскільки кожне відділення компанії має деякий персонал. Однак, оскільки деякі працівники (наприклад, торговці агенти) не відносяться ні до якого конкретного відділення компанії, то участь сутності Staff у зв'язкуIsAllocated є частковим.

Учасники зв'язку з повною участю з'єднується зі значком зв'язку подвійною лінією, а учасники зв'язку з частковою участю – одинарною лінією.

EER-модель.

EER-модель включає всі концепції ER-моделі плюс додаткові концепції спеціалізації/генералізації і категоризації. Концепції спеціалізації/генералізації і категоризації зв'язані з близькими ним поняттями типів сутностей, називаних суперкласами і підкласами, а також із процесом спадкування атрибутів.

Як вже обговорювалося в попередньому розділі, тип сутності – це множина сутностей одного типу, наприклад Staff, Branch або Property for Rent.

Суперклас – тип сутності, що включає різні підкласи, які необхідно представити в моделі даних.

Підклас – підклас є типом сутності, що виконує окрему роль, а також є членом суперкласу.

У деяких випадках тип сутності може мати кілька різних підкласів. Наприклад, для типу сутності Staff окремі екземпляри цієї сутності можна класифікувати як підтипи Manager, Secretary і Sales_Personnel. Інакше кажучи, сутність Staff можна розглядати як суперклас для підкласів Manager, Secretary і Sales Personnel. Зв'язок між суперкласом і будь-яким його підкласом називається зв'язком "суперклас/підклас". Наприклад, зв'язок Staff/Manager є зв'язком типу "суперклас/підклас".

Кожен член підкласу є членом суперкласу. Іншими словами, член підкласу є сутністю суперкласу й у той же час грає власну окрему роль. Зв'язок між суперкласом і підкласом відноситься до типу "один до одного" (1:1). Деякі суперкласи можуть містити підкласи, що перекриваються. Наприклад, співробітник може бути одночасно менеджером (Manager) і торговим агентом (Sales_Personnel). У цьому прикладі підкласи Manager і Sales_Personnel є підкласами суперкласу, що перекриваються, Staff. Однак не кожен член суперкласу обов'язково повинен бути членом якого-небудь підкласу – наприклад, це можуть бути рядові співробітники, що не грають якою-небудь особою ролі в організації.

Суперкласи і підкласи можуть використовуватися з метою виключення опису різних типів персоналу з (можливо) різними атрибутами усередині однієї сутності.

Існує дві причини введення понять суперкласів і підкласів у ER-модель. По-перше, це дозволяє уникнути повторного опису подібних понять, що заощадить час проектувальника і підвищить читабельність ER-діаграм. По-друге, при проектуванні в бази даних включається більше семантичної інформації у формі, більш звичної для багатьох людей. Наприклад, у твердженнях "менеджер Є співробітником" і "квартира Є типом власності" у дуже короткій формі міститься значна семантична інформація.

Як згадувалося вище, сутність у підкласі представляє той же об'єкт реального світу, що і її суперклас, і може мати атрибути, як зв'язані із суперкласом, так і специфічні для даного підкласу. Наприклад, підклас Sales_Personnel має всі атрибути суперкласу Staff (тобто атрибутами Staff_No, Name, Address і DOB), а також специфічними атрибутами підкласу Sales_Personnel (тобто атрибутами Car Allowance і Sales Area).

Підклас також є сутністю, а тому може мати свої власні підкласи. Сутність, її підкласи, підкласи даних підкласів і так далі – усе це називається ієрархією типу (type hierarchy). Ієрархії типів можуть мати різні назви: ієрархія спеціалізації (specialization hierarchy) – наприклад, підклас Manager є спеціалізацією суперкласу Staff; ієрархія генералізації (generalization hierarchy) – наприклад, суперклас Staff є генералізацією підкласу Manager; ієрархія належності (IS-A hierarchy) – наприклад, менеджер (підклас Manager) є співробітником (належить суперкласові Staff). У наступних розділах процеси спеціалізації і генералізації описуються більш докладно.

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

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

Специфічні для кожного підкласу атрибути безпосередньо з'єднуються лініями з прямокутником, що позначає цей підклас. На ERR-діаграмі можуть бути зазначені зв'язки, що застосовні тільки до окремих підкласів. Наприклад, підклас Manager зв'язаний із сутністю Branch за допомогою зв'язку Manages, у той час як сутність Staff зв'язана із сутністю Branch за допомогою зв'язку IsAllocated.

Генералізація – процес зведення розходжень між сутностями до мінімуму шляхом виділення їхніх загальних характеристик.

Генералізація являє собою висхідний підхід, що дозволяє створити узагальнений суперклас на основі різних вихідних підкласів. Процес генералізації можна розглядати як протилежний процесові спеціалізації. Давайте, розглянемо модель, у якій Manager, Secretary і Sales Personnel представлені як окремі типи сутностей. Застосування методу генералізації до цих сутностей полягає в пошуку будь-яких подібностей між ними, тобто виділенні їхніх загальних атрибутів і зв'язків. Як згадувалося вище, ці сутності спільно використовують атрибути, загальні для всіх співробітників компанії. Тому сутності Manager, Secretary і Sales_Personnel можна розглядати як підкласи узагальненого суперкласу Staff.

Обмеження, що накладаються на процедури спеціалізації і генералізації.

Перше обмеження називається обмеженням неперетинання (disjoint constraint). Воно говорить, що якщо підкласи деякої спеціалізації не перетинаються, те кожна окрема сутність може бути членом тільки одного з підкласів даної спеціалізації. Для представлення спеціалізації без перетинів (disjoint) використовується символ "d", що розташовується в центрі кружка, що з'єднує підкласи даного суперкласу. Наприклад, підкласи видів прийнятих угод про наймання (Full_Time_Permanent і Part_Time_Temporary)  не перетинаються. Звідси виходить, що співробітник може установити з компанією або угоду про повну постійну зайнятість, або угоду про часткову тимчасову зайнятість.

Якщо підкласи спеціалізації перетинаються, у такому випадку сутність може бути членом відразу декількох підкласів спеціалізації. Для представлення  спеціалізації з перетином (nondisjoint) використовується символ "о", що розташовується в центрі кружка, що з'єднує підкласи даного суперкласу. Наприклад, підкласи спеціалізації службових ролей (Manager, Secretary, Sales_Personnel) перетинаються. У даному прикладі це значить, що співробітник може бути одночасно і менеджером (тобто членом підкласу Manager), і торговим агентом (тобто членом підкласу Sales_Personnel).

Друге обмеження спеціалізації називається обмеженням участі (partisipation constraint), воно може бути повним або частковим. Спеціалізація з повною участю означає, що кожна сутність суперкласу повинна бути членом підкласу цієї спеціалізації. Для позначення повної участі між суперкласом і кружком спеціалізації проводять подвійну лінію. Наприклад, спеціалізація типів угод про наймання характеризується повною участю, при якому кожен співробітник компанії повинний установити з нею угоду про повну постійну або часткову тимчасову зайнятість.

Спеціалізація з частковою участю означає, що сутність не обов'язково повинна бути членом будь-якого підкласу цієї спеціалізації. Для позначення часткової участі між суперкласом і кружком спеціалізації проводять одинарну лінію. Наприклад, спеціалізація службових ролей характеризується частковою участю, при якому співробітник не обов'язково повинен виконувати одну з додаткових службових ролей – менеджера (тобто бути членом підкласу Manager), секретаря (тобто бути членом підкласу Secretary) або торгового агента (тобто бути членом підкласу Sales Personnel).

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

Категоризація – моделювання одного підкласу зі зв'язком, що охоплює кілька різних суперкласів.

Кожен зв'язок "суперклас/підклас" (включаючи спільно використовувані підкласи) в ієрархії спеціалізації/генералізації володіє єдиним і відмінним від інших суперкласом. Однак у деяких ситуаціях може знадобитися змоделювати зв'язок "суперклас/підклас", що включає відразу кілька різних суперкласів. У цьому випадку створюваний підклас буде називатися категорією (category).

Підклас категорії має вибіркове наслідування (selective inheritance). Це означає, що кожен екземпляр сутності категорії успадковує атрибути тільки одного суперкласу.

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

3.6. Визначення вимог підтримки цілісності даних.

Ціль даного  етапу – накладення обмежень на атрибути та зв’язки між типами сутностей з метою коректного відображення бізнес-процесів у даній предметній області.

На даному етапі визначають:

–       обов’язкові дані – атрибути, значення котрих не можуть бути порожніми для кожного екземпляру типу сутності;

–       обмеження для доменів атрибутів – переносяться обмеження з етапу 1.4 з врахуванням змін, виконаних на етапі логічного проектування моделі даних;

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

–       цілісність посилань – встановлення правил зміни значень зовнішнього ключа при редагуванні первинного ключа у типах сутностей із зв’язком "1:М".

–       вимоги даного підприємства – накладення додаткових обмежень на значення атрибутів згідно особливостей діяльності даного підприємства та встановлених на ньому правил.

Про цілісність посилань потрібно сказати докладніше. Коли між типами сутностей є зв’язок "1:М" то в логічній моделі цей зв’язок забезпечується наступним чином: Зі сторони 1 зв’язку в ньому бере участь первинний або альтернативний ключ. В даній парі типів сутностей цей тип називається головним. Інший – підлеглим. Зі сторони підлеглого типу сутності для утворення зв’язку потрібно мати зовнішній ключ – це атрибут чи їх множина, типи даних котрого та розмірність відповідають первинному (альтернативному) ключу головного типу та значення якого беруться з множини значень первинного (альтернативного) ключа головного типу сутності. Кожен тип сутностей в логічній моделі представлений відношенням. Отже, якщо міняється значення первинного (альтернативного) ключа, то повинно змінюватись певним чином і значення зовнішнього ключа. Правила цілісності посилань визначають способи зміни зовнішнього ключа при:

–       добавленні стрічки в головне відношення;

–       видаленні стрічки з головного відношення;

–       редагування первинного ключа головного відношення.

На кожен з цих випадків в підлеглому відношенні можливі наступні варіанти дій:

–       NO ACTION. В підлеглому відношенні не виконуються жодні зміни;

–       CASCADE. Каскадна зміна зовнішнього ключа відповідно до зміни первинного. Сюди ж включається витирання всіх рядків підлеглого відношення, в яких значення зовнішнього ключа відповідають значенню первинного ключа в рядку головного відношення, який витирається;

–       SET NULL. При витиранні стрічки головного відношення в пов’язаних з нею стрічках підлеглого відношення в атрибутах зовнішнього ключа встановлюються порожні значення;

–       SET DEFAULT. При витиранні стрічки головного відношення в пов’язаних з нею стрічках підлеглого відношення в атрибутах зовнішнього ключа встановлюються значення за замовчуванням (при умові, що такі значення встановлені в домені атрибуту, який є зовнішнім ключем);

–       RESTRICT. Заборона будь-яких змін значень первинного ключа (в т.ч. і витирання рядка) головного відношення, допоки даний рядок має пов’язані з ним у підлеглому відношенні (у підлеглому відношенні є рядки із значеннями зовнішнього ключа, рівними значення первинного ключа, котре підлягає зміні).

3.7. Обговорення отриманих локальних моделей даних з кінцевими користувачами.

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

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

3.1. Об’єднання локальних логічних моделей даних.

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

3.2. Перевірка глобальної логічної моделі даних. Тут виконуються кроки, аналогічні крокам 2.3 та 2.4 стосовно локальних моделей даних (нормалізація та можливість виконання транзакцій).

3.3. Перевірка можливості розширення моделі в майбутньому.

3.4. Створення остаточного варіанту ER-діаграми.

3.5. Обговорення глобальної логічної моделі даних з користувачами.

 

3 Порівняння етапів логічного і фізичного проектування баз даних

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

Стадія, що передує фізичному проектуванню, називається стадією логічного проектування. Результати її виконання в значній мірі незалежні від особливостей фізичної реалізації проекту. При логічному проектуванні не приймаються в увагу конкретні функціональні можливості цільової бази даних і прикладних програм, однак ураховуються особливості обраної моделі даних. Результатом логічного проектування є глобальна логічна модель даних, що складається з ER-діаграми або діаграми відношень, а також реляційної схеми, і комплект її супровідної документації, що описує, зокрема, словник даних. У сукупності ці результати є вихідною інформацією для стадії фізичного проектування бази даних і дають її розроблювачеві все необхідне для прийняття рішень, спрямованих на досягнення максимальної ефективності створюваного проекту.

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

 

Загальний огляд методології фізичного проектування баз даних

 

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

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

1.Перенос глобальної логічної моделі даних у середовище цільової СКБД.

2.Проектування основних відношень.

3.Розробка способів одержання похідних даних.

4.Реалізація обмежень предметної області.

5.Проектування фізичного представлення бази даних.

6.Аналіз транзакцій.

7.Вибір файлової структури.

8.Визначення індексів.

9.Визначення вимог до дискової пам'яті.

10.Проектування користувальницьких представлень.

11.Розробка механізмів захисту.

12.Обґрунтування необхідності введення контрольованої надлишковості.

13.Поточний контроль і настроювання операційної системи.

 

Методологія фізичного проектування баз даних реляційного типу

 

Етап 4. Перенос глобальної логічної моделі даних у середовище цільової СКБД

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

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

-  способи створення основних відношень;

-  чи підтримує система визначення первинних, зовнішніх й альтернативних ключів;

-  чи підтримує система визначення обов'язкових даних (тобто чи допускає система вказувати у визначенні атрибута, що для нього заборонене використання значення NULL);

-  чи підтримує система визначення доменів;

-  чи підтримує система реляційні обмеження цілісності;

-  чи підтримує система визначення обмежень предметної області.

На цьому  етапі процедури розробки баз даних виконуються наступні дії.

1.Проектування основних відношень.

2.Розробка способів одержання похідних даних.

3.Реалізація обмежень предметної області.

Етап 4.1      Проектування основних відношень

Ціль  Визначення способу подання в цільовій СКБД         відношеньвизначених у глобальній логічній моделі даних.

Приступаючи до фізичного проектування, насамперед необхідно проаналізувати й добре засвоїти інформацію про відношення, зібрану на етапі побудови логічної моделі бази даних. Ця інформація може міститися в словнику даних й у визначеннях відношень, записаних мовою DBDL. Визначення кожного виділеного в глобальній логічній моделі даних відношення включає наступні елементи:

-  ім'я відношення;

-  список простих атрибутів, взятий у круглі дужки;

-  визначення первинного ключа й (якщо такі існують) альтернативних (АК) і зовнішніх (FK) ключів;

-  список похідних атрибутів й опис способів їхнього обчислення;

-  визначення вимог цілісності посилань для будь-яких зовнішніх ключів.

Для кожного атрибута в словнику даних повинна бути наступна інформація;

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

-  прийняте за замовчуванням значення атрибута (необов'язково);

-  допустимість значення NULL для даного атрибута.

Реалізація основних відношень

Тепер необхідно прийняти рішення про спосіб реалізації основних відношень. Це рішення залежить від типу обраної цільової СКБД – при визначенні основних відношень деякі системи надають більше можливостей, ніж інші. Наприклад існує три способи реалізації основних відношень: з використанням стандарту ISO SQL, Microsoft Access і Oracle.

Документальне оформлення проекту основних відношень

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

Етап 4.2. Розробка способів одержання похідних даних

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

Похідними, або розрахунковими називаються атрибути, значення яких можна визначити з використанням значень інших атрибутів. Наприклад, похідними є всі перераховані нижче атрибути:

-  кількість співробітників, що працюють у конкретному відділенні;

-  загальна сума щомісячної зарплати всіх співробітників;

Іноді похідні атрибути не включають у логічну модель даних, а описують у словнику даних. На етапі фізичного проектування бази даних необхідно визначити, чи належний похідний атрибут зберігатися в базі даних або обчислюватися щораз, коли в ньому виникає необхідність. Проектувальник повинен розрахувати наступне:

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

-  витрати на обчислення похідних даних, якщо їхнє обчислення виконується в міру необхідності.

Із цих двох варіантів вибирається найменш дорогий з урахуванням вимог до продуктивності.

Етап 4.3. Реалізація обмежень предметної області

Ціль       Розробка обмежень предметної області для цільової СКБД.

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

Етап 5. Проектування фізичного представлення бази даних

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

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

-  Час відповіді. Характеризує часовий проміжок, необхідний для виконання однієї транзакції. З погляду користувача бажано зробити час відповіді системи мінімальним. Однак існують деякі фактори, які впливають на швидкодію системи, але не можуть контролюватися розроблювачами, наприклад, рівні завантаження системи або час, затрачуваний на передачу даних.

-  Дискова пам'ять. Цей показник являє собою обсяг дискового простору, необхідного для розміщення файлів бази даних. Розроблювач повинен прагнути мінімізувати обсяг використовуваної дискової пам'яті.

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

Взявши до уваги все вищесказане, приступимо до обговорення тих дій, які повинні бути виконані на п'ятому етапі розробки бази даних.

1.Аналіз транзакцій.

2.Вибір файлової структури.

3.Визначення індексів.

4.Визначення вимог до дискової пам'яті.

Етап 5.1. Аналіз транзакцій

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

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

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

-  транзакції, найбільш важливі для роботи організації;

-  періоди часу протягом доби/тижнів, у які навантаження бази даних зростає до максимуму (називані періодами пікового навантаження).

Етап 5.2 Вибір файлової структури

Ціль  Визначення найбільш ефективного файлового подання для кожного з основних відношень.

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

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

Послідовні файли.

-  Хешовані файли.

-  Індексно-послідовні файли (ISAM - Indexed Sequential Access Method).

-  Удосконалені збалансовані дерева (В+-Tree).

-  Кластери.

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

Етап 5.3. Визначення індексів

Ціль  Визначення того, чи буде додавання індексів сприяти підвищенню продуктивності системи.

Один з варіантів вибору підходящої файлової структури для відношення полягає в тому, що рядки залишаються неупорядкованими й створюється будь-яка необхідна кількість додаткових індексів. Для вибору атрибута, по якому виконується впорядкування або рядків, застосовуються наступні критерії:

-  вибирається атрибут, найбільше часто застосовуваний в операціях з'єднання, оскільки саме він дозволяє підвищити ефективність таких операцій;

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

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

Вибір додаткових індексів

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

Супровід і застосування додаткових індексів приводить до збільшення витрат, тому необхідно визначити, чи виправдують вони підвищення продуктивності при вибірці даних, досягнуте завдяки їхньому використанню. Основні витрати, пов'язані із застосуванням додаткових індексів, перераховані нижче.

-  Ввід індексного запису в кожен додатковий індекс при вставці рядка у відношення.

-  Оновлення додаткового індексу при оновленні відповідного рядка у відношенні.

-  Збільшення потреби в дисковому просторі у зв'язку з необхідністю зберігання додаткового індексу.

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

Етап 5.4. Оцінка потреби в дисковому просторі

Ціль. Визначити обсяг дискового простору, що потрібно для бази даних.

Етап 6. Проектування представлень користувача (переглядів, поданнів).

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

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

Етап 7. Проектування засобів захисту

Ціль  Проектування засобів захисту для бази даних у відповідності до вимог користувачів.

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

-  захист системи;

-  захист даних.

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

 

 

ЛЕКЦІЯ 5

5 Структура даних у файлах з різною організацією

 

•      Відмінності між первинними і вторинними пристроями зберігання даних.

•      Поняття організації файлу і методу доступу

•      Невпорядковані файли.

•      Впорядковані файли.

•      Хешовані файли.

•      Викорстання індексів для прискорення операцій отртимання інформації (вибірки) з бази даних.

•      Відмінність між основним і допоміжним індексами.

•      Файли з індексно-послідовною організацією.

•      Структура багаторівневих індексів.

•      Файли з вдосконаленою збалансованою деревовидною структурою.

•      Відмінності між кластеризованими і некластеризованими таблицями.

 

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

 

5.1 Основні поняття

 

База даних у вторинному пристрої зберігання організована у вигляді одного або декількох файлів, кожен з яких складається з однієї або декількох записів, а кожен запис – з одного або декількох полів. Як правило, запис відповідає деякому єству, а поле – атрибуту. Розглянемо скорочений варіант відношення Staff з учбового проекту DreamHome, приведений в таблицю. В1.

 

Таблиця 5.1 –Відношення Staff з відомостями про працівників

staffNo

IName

position

branchNo

SL21

White

Manager

B005

SG37

Beech

Assistant

B003

SG14

Ford

Supervisor

B003

SA9

Howe

Assistant

B007

SG5

Brand

Manager

B003

SL41

Lee

Assistant

B005

 

Можна припустити, що кожен кортеж в цьому відношенні відображається на деякий запис у файлі операційної системи, що містить відношення Staff. Кожне поле запису зберігає значення одного атрибуту відношення Staff. Коли користувач вводить запит для отримання кортежу з СКБД (наприклад, кортежу SG37 з відношення Staff), СКБД відображує логічний запис на фізичний, а потім поміщає цей фізичний запис в буфер СКБД в первинному пристрої зберігання за допомогою процедур доступу до файлів операційної системи.

Фізичний запис є одиницею обміну даними між вторинним і первинним пристроями зберігання. Зазвичай фізичний запис складається з декількох
логічних записів, хоча інколи, залежно від розміру, один логічний запис
може відповідати одному фізичному запису. Більш того, один логічний запис
може навіть відповідати декільком фізичним записам. Інколи замість поняття  "фізичний запис" використовуються терміни "блок" і "сторінка". Далі ми використовуватимемо термін "сторінка". Наприклад, представлені в таблиці 5.2 кортежі відношення Staff можуть зберігатися на двох сторінках вторинної пам'яті, як показано в таблиці 5.2.

 

Таблиця 5.2 – Приклад зберігання відношення Staff на двох сторінках вторинної пам'яті

staffNo

IName

position

branch No

Сторінка

SL21

White

Manager

B005

1

SG37

Beech

Assistant

B003

1

SG14

Ford

Supervisor

B003

1

SA9

Howe

Assistant

B007

2

SG5

Brand

Manager

B003

2

SU1

Lee

Assistant

B005

2

Порядок зберігання записів у файлі і доступу до них залежить від структури (або організації) файлу.

 

5.2 Організація файлу та фізичний розподіл даних файлу по записах і сторінках на вторинному пристрої зберігання

 

Існують наступні основні типи організації файлів.

•  Невпорядкована  організація  файлу  передбачає довільне невпорядковане розміщення записів на диску.

•  Впорядкована (послідовна) організація передбачає розміщення записів відповідно до значення вказаного поля.

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

Для кожного типа організації файлів використовується відповідний набір методів доступу.

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

 

5.2.1 Невпорядковані файли

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

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

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

 

5.2.2 Впорядковані файли

Запису у файлі можна відсортувати по значеннях одного або декількох полів і таким чином утворити набір даних, впорядкований по деякому ключу. Поле (або набір полів), по якому сортується файл, називається по­лем впорядкування. Якщо поле впорядкування є також ключем доступу до файлу і тому гарантується наявність в кожному записі унікального значення цього поля, воно називається ключем впорядкування для даного файлу. Розглянемо, наприклад, приведений нижче запит SQL.

SELECT   *

FROM  Staff

ORDER  BY  staffNo;

Якщо кортежі відношення Staff вже впорядковані по полю staffNo, час виконання запиту скорочується, оскільки не потрібно виконувати сортування. (Хоча в розділі 3.2 вказано, що кортежі стосунків не впорядковані, при цьому малася на увазі їх зовнішня (логічне), а не внутрішня (фізичне) вистава. Річ у тому, що з точки зору фізичної організації серед записів завжди перша, друга і так далі) Якщо кортежі впорядковані по полю staffNo, то за певних умов при обробці запитів можна застосовувати бінарний пошук – в тих випадках, коли запит містить умову пошуку з використанням значення поля staffNo. Як приклад розглянемо запит SQL, приведений нижче.

SELECT  *

FROM   Staff

WHERE   staffNo  =   'SG37';

Для прикладу розглянемо файл з кортежами, представленими в таблиці. В.1, при- чим для простоти передбачимо, що на кожній сторінці знаходиться по одній запи- сі. Тоді впорядкований файл виглядатиме, як показано на мал. В.1. При цьому процедура бінарного пошуку включатиме наступні етапи.

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

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

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

В даному випадку середньою є сторінка 3, але запис на цій сторінці (SG14) не є шуканим (SG37). Значення ключового поля запису на страни це 3 менше необхідного значення, тому вся ліва половина файлу виключається з області пошуку. Тепер слід витягувати середню сторінку з частини файлу (його правої половини), що залишилася, тобто сторінку 5. Цього разу значення ключового поля (SL21) більше шуканого значення (SG37), що дозволяє виключити з поточної зони пошуку її праву половину. Після витягання середньої сторінки з частини файлу (тобто сторінки 4), що залишилася на даний момент, можна переконатися в тому, що саме вона і є шуканою.

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

Операції вставки і видалення записів у відсортованому файлі ускладнюються у зв'язку з необхідністю підтримувати встановлений порядок записів. Для вставки нового запису потрібно визначити її розташування у вказаному порядку, а потім знайти вільне місце для вставки. Якщо на потрібній сторінці досить місця для розміщення нового запису, то потрібно буде переупорядкувати записи лише на цій сторінці, після чого вивести її на диск. Якщо ж вільного місця недостатньо, то потрібно буде перемістити одну або декілька записів на наступну сторінку. На наступній сторінці також може не виявитися доста- точно вільного місця, і з неї потрібно буде перемістити деякі записи на наступну сторінку і так далі

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

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

 

5.2.3 Хешовані файли

У хешрованому файлі записи не обов'язково повинні вводитися у файл послідовно. Замість цього для обчислення адреси сторінки, на якій повинен знаходитися запис, використовується хеш-функція (hash function), параметрами якої є значення одного або декількох полів цього запису. Подібне поле називається полем хешування (hash field), а якщо поле є також ключовим полем файлу, то воно називається хеш-ключем (hash key). Записи в хешуванням файлі розподілені довільним чином по всьому доступному для файлу просторові. З цієї причини хешовані файли інколи називають файлами з довільним або прямим доступом (random file або direct file).

Хеш-функція вибирається так, щоб записи усередині файлу були розподілені найбільш рівномірно. Один з методів створення хеш-функції називають згорткою (folding) і заснований на виконанні деяких арифметичних дій над різними частинами поля хешування. При цьому символьні рядки перетворяться в цілі числа з використанням деякого кодування (на основі розташування букв в алфавіті або код символів ASCII). Наприклад, можна перетворити в ціле число перші два символи поля табельного номера співробітника (атрибут staffNo), а потім скласти набутого значення з останніми цифрами цього номера. Обчислена сума використовується як адреса дискової сторінки, на якій зберігатиметься даний запис. Популярніший альтернативний метод заснований на хешуванні із застосуванням залишку від ділення. У цьому методі використовується функція MOD, якою передається значення поля. Функція ділить набутого значення на деяке заздалегідь задане ціле число, після чого залишок від ділення використовується як адреса на диску.

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

Для вирішення конфліктів можна використовувати наступні методи:

‒         відкрита адресація;

‒         незв'язана область переповнення;

‒         зв'язана область переповнення;

‒         багатократне хешування.

 

Відкрита адресація

 

При виникненні конфлікту система виконує лінійний пошук першого доступного слота для вставки в нього нового запису. Після невдалого пошуку порожнього слота в останньому сегменті пошук продовжується з першого сегменту. При вибірці запису використовується той же метод, який застосовувався при збереженні запису, за винятком того, що запис в даному випадку розглядається як неіснуючий, якщо до виявлення шуканого запису буде виявлений порожній слот. Наприклад, розглянемо просту хеш-функцію на основі залишку від ділення цифр табельного номера співробітника по модулю 3 (MOD 3).

 

Незв'язана область переповнення

 

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

 

Зв'язана область переповнення

 

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

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

 

Багатократне хешування

 

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

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

 

5.2.4 Динамічне хешування

 

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

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

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

 

5.2.5 Обмеження, властиві методу хешування

 

Використання методу хешування для витягання записів засноване на повністю відомому значенні хеш-поля. Тому, як правило, хешування не підходить для операцій витягання даних по заданому зразку або діапазону значень. Наприклад, для пошуку значень хеш-поля в заданому діапазоні потрібно буде використовувати хеш-функцію, що зберігає впорядкування, іншими словами,  якщо rmin і rmax є мінімальною і максимальною межами діапазону, то має бути і така хеш-функція h для якої дотримується нерівність h(rmin) < h(rmax). Більше того, хешування не підходить для пошуку і витягання даних по будь-якому іншому полю, відмінному від поля хешування. Наприклад, якщо таблиця Staff зберігається як хешована по полю staffNo, то такий хешований файл не може бути використаний для пошуку запису за значенням поля lName. В цьому випадку потрібно буде виконати лінійний пошук для пошуку потрібного запису або використовувати поле lName як вторинний індекс.

 

5.3 Індекси

 

У цьому розділі розглядаються ефективніші методи пошуку і витягання даних на основі використання індексів

Індекс – Структура даних, яка допомагає СКБД виявити окремі записи файлу і скоротити час виконання запитів.

Індекс в базі даних аналогічний предметному покажчику в книзі. Це – допоміжна структура, пов'язана з файлом і призначена для пошуку інформації за тим же принципом, що і в книзі з предметним покажчиком. Індекс дозволяє уникнути проведення послідовного або покрокового перегляду файлу у пошуках потрібних даних. При використанні індексів в базі даних шуканим об'єктом може бути один або декілька записів файлу. Як і предметний покажчик книги, індекс бази даних впорядкований, і кожен елемент індексу містить назву шуканого об'єкту, а також один або декілька покажчиків (ідентифікаторів записів) на місце його розташування.

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

Структура індексу пов'язана з певним ключем пошуку і містить записи, що складаються з ключового значення і адреси логічного запису у файлі, що містить це ключове значення. Файл, що містить логічні записи, називається файлом даних, а файл, що містить індексні записи, – індексним файлом. Значення в індексному файлі впорядковані по полю індексування, яке зазвичай будується на базі одного атрибуту.

 

5.3.1 Типи індексів

Для прискорення доступу до даних застосовується декілька типів індексів. Основні з них перераховані нижче.

‒         Первинний індекс. Файл даних послідовно впорядковується по полю ключа впорядкування, а на основі поля ключа впорядкування створюється поле індексації, яке гарантовано має унікальне значення в кожному записі.

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

‒         Вторинний індекс. Індекс, який визначений на полі файлу даних, відмінному від поля, по якому виконується впорядкування.

Файл може мати не більше одного первинного індексу або одного індексу кластеризації, але додатково до них може мати декілька вторинних індексів. Індекс може бути розрідженим (sparse) або щільним (dense). Розріджений індекс містить індексні записи лише для деяких значень ключа пошуку в даному файлі, а щільний індекс має індексні записи для всіх значень ключа пошуку в даному файлі.

Ключ пошуку для індексу може складатися з декількох полів.

 

5.3.2 Індексно-послідовні файли

 

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

‒         первинна область зберігання;

‒         окремий індекс або декілька індексів;

‒         область переповнення.

Подібна організація файлів використовується в методі індексно-послідовного доступу (Indexed Sequential Access Method – ISAM), розробленому компанією IBM, який тісно пов'язаний з характеристиками використовуваного устаткування. Для підтримки високої ефективності роботи файлів такого типу їх слід періодично піддавати реорганізації. Пізніше на базі методу доступу ISAM був розроблений метод віртуального послідовного доступу (Virtual Sequential Access Method – VSAM), що володіє повною незалежністю від особливостей апаратного забезпечення. У ньому не передбачено використання спеціальної області переповнення, але в області даних виділений простір, призначений для розширення. У міру зростання або скорочення розміру файлу цей процес управляється динамічно, без необхідності періодичного виконання реорганізації.

Зазвичай велика частина первинного індексу може зберігатися в оперативній пам'яті, що дозволяє обробляти його набагато швидше. Для прискорення пошуку можуть застосовуватися спеціальні методи доступу, наприклад метод бінарного пошуку. Основним недоліком використання первинного індексу (як і при роботі з будь-яким іншим відсортованим файлом) є необхідність дотримання послідовності сортування при вставці і видаленні записів. Ці проблеми ускладнюються тим, що потрібно підтримувати порядок сортування як у файлі даних, так і в індексному файлі. У подібному випадку може використовуватися метод, що полягає у вживанні області переповнення і ланцюжка зв'язаних покажчиків, аналогічно методу, використовуваному для вирішення конфліктів в хешованих файлах.

 

5.3.3 Вторинні індекси

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

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

‒       Створення щільного вторинного індексу, який відповідає всім записам файлу даних, але при цьому в ньому допускається наявність дублікатів.

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

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

Вторинні індекси підвищують продуктивність обробки запитів, в яких для пошуку використовуються атрибути, відмінні від атрибуту первинного ключа. Проте таке підвищення продуктивності запитів вимагає додаткової обробки, пов'язаної з супроводом індексів при оновленні індексу в базі даних. Це завдання вирішується на етапі фізичного проектування бази даних.

 

5.3.4 Багаторівневі індекси

При зростанні розміру індексного файлу і розширенні його вмісту на велику кількість сторінок час пошуку потрібного індексу також значно зростає. Наприклад, при використанні методу бінарного пошуку потрібно виконати приблизно log2(p) операцій доступу до індексу з p сторінками. Звернувшись до багаторівневого індексу, можна спробувати вирішити цю проблему шляхом скорочення діапазону пошуку.

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

Пошук запису по заданому значенню атрибуту staffNo починається з індексу другого рівня, якому відшукується перша сторінка, в якої значення останнього ключа доступу більше або рівне шуканому. Знайдений запис містить адресу сторінки індексу першого рівня, в якій слід продовжити пошук.

Метод ISAM компанії IBM побудований на використанні дворівневої індексної структури. Операції вставки в ньому обробляються за допомогою сторінок переповнення. Як правило, можна використовувати n-рівневу індексну структуру довільної глибини, але на практиці зазвичай обмежуються не більше ніж трьома рівнями, оскільки більша кількість рівнів потрібна лише для виключно великих файлів.

 

5.3.5 Вдосконалені деревовидні індекси

У багатьох СКБД для зберігання даних або індексів використовується структура даних, яка називається деревом. Дерево складається з ієрархії вузлів (node), в якій кожен вузол, за винятком кореня (root), має батьківський (parent) вузол, а також один, декілька або жодного дочірнього (child) вузла. Корінь не має батьківського вузла. Вузол, який не має дочірніх вузлів, називається лтстом (leaf).

Глибиною дерева називається максимальна кількість рівнів між коренем і листом. Глибина дерева може бути різною для різних шляхів доступу до листів. Якщо ж вона однакова для всіх листів, то дерево називається збалансованим, або В-деревом. Мірою (degree) (або порядком) дерева називається максимально допустима кількість дочірніх вузлів для кожного батьківського вузла. Великі міри зазвичай використовуються для створення ширших і менш глибших дерев. Оскільки час доступу в деревовидній структурі залежить від глибини, а не від ширини, зазвичай прийнято використовувати більш "розгалужені" і менш глибокі дерева. Бінарним деревом (binary tree) називається дерево порядку 2, в якому кожен вузол має не більше двох дочірніх вузлів.

Вдосконалені збалансовані деревовидні індекси B+-Tree визначаються за наступними правилами.

‒       Якщо корінь не є листом, то він повинен мати, принаймні, два дочірні вузли.

‒       У дереві порядку n кожен вузол (за винятком кореня і листів) повинен мати від n/2 до n покажчиків і дочірніх вузлів. Якщо число n/2 не є цілим, то воно округляється до найближчого більшого цілого.

‒       У дереві порядку n кількість значень ключа в листі повинна знаходитися в межах від (n-1)/2 до (n-1). Якщо число (n-1)/2 не є цілим, то воно округляється до найближчого більшого цілого.

‒       Кількість значень ключа в нелистовому вузлі на одиницю менше кількості покажчиків.

‒       Дерево завжди має бути збалансованим, тобто  всі шляхи від кореня до кожного листа повинні мати однакову глибину.

‒       Листи дерева зв'язані в порядку зростання значень ключа.

На практиці кожен вузол в дереві є сторінкою, тому в ньому може зберігатися більше трьох покажчиків і двох значень ключа. Якщо передбачити, що сторінка має розмір 4096 байтів, кожен покажчик – довжину 4 байти, розмір поля staffNoтакож дорівнює 4 байтам і кожна сторінка містить 4-байтовий покажчик на наступний вузол того ж рівня, то на одній сторінці може зберігатися (4096-4) / (4 + 4) =511 індексних записів. Таким чином, порядок даного В+-дерева дорівнює 512. Корінь дерева може містити до 511 записів і мати до 512 дочірніх вузлів. Кожен дочірній вузол також може містити до 511 записів, що в цілому дає структуру з 261632 записів. У свою чергу, кожен дочірній вузол також може мати до 512 дочірніх вузлів, що в сумі дає 262144 дочірніх вузли на рівні 2 цього дерева. Кожен із цих вузлів також може містити до 511 записів, що дає дворівневу структуру з 133955584 записів. Теоретичний максимум для кількості індексних записів в дворівневому дереві визначається таким чином.

Корінь

511

Рівень 1

261632

Рівень 2

133 955 5S4

Всього

134 217 727

Таким чином, описана вище структура дозволяє здійснювати довільний доступ до окремого запису файлу staff, що містить до 134217727 записів, з виконанням лише чотирьох операцій доступу до диска (насправді корінь зазвичай знаходиться в оперативній пам'яті, тому кількість операцій доступу на одиницю менша). Але на практиці кількість записів на одній сторінці зазвичай менше, оскільки не всі сторінки бувають повністю заповненими.

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

 

5.4 Кластеризовані і некластеризовані таблиці

 

У деяких СКБД, таких як Oracle, підтримуються кластеризовані (clustered) і некластеризовані таблиці.  Вибір того або іншого методу організації таблиці залежить від попереднього аналізу транзакцій, які повинні виконуватися з використанням цієї таблиці, оскільки від правильного вибору типа таблиці залежить продуктивність. У справжньому розділі коротко розглядаються структури обох типів.

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

На рисунку нижче показано, як може бути організоване зберігання таблиць Branch і Staff, кластеризованих за значенням стовпця branchNo. Після включення цих двох таблиць в один кластер кожне унікальне значення branchNo зберігається лише в одному екземплярі – в ключі кластера. А з кожним значенням branchNo пов'язані стовпці з обох таблиць.

 

Таблиці Branch і Staff, кластеризовані за значенням branchNo

 

СКБД Oracle підтримує кластери двох типів (індексовані і хешовані), які розглядаються нижчим.

 

5.4.1 Індексовані кластери

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

‒       у використовуваних запитах передбачається вибірка записів в діапазоні значень ключа кластера;

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

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

 

5.4.2. Хешовані кластери

Хешовані кластери також застосовуються для кластеризації даних таблиць за принципом, аналогічним індексованим кластерам. Але в хешований кластер запис вноситься з врахуванням застосування хеш-функції до значення ключа кластера цього запису. Всі записи з однаковим значенням ключа кластера зберігаються на диску поруч один з одним. Корпорація Oracle рекомендує використовувати хешовані кластери за наступних умов:

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

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

 

12.6 Нормалізація

6.1 Мета нормалізації

 

Нормалізація – метод створення набору відношень із заданими властивостями на основі вимог до даних, встановлених в деякій організації.

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

Услід за НФБК з'явилися визначення четвертої (4НФ) і п'ятої (5НФ) нормальних форм. Проте на практиці ці нормальні форми вищих порядків використовуються украй рідко.

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

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

 

6.2 Надлишковість даних і аномалії оновлення БД

 

Основна мета проектування реляційної бази даних полягає в групуванні атрибутів в відношення таким чином, щоби мінімізувати надлишковість даних і, як наслідок, скоротити об'єм пам'яті, необхідний для фізичного зберігання відношень, представлених у вигляді таблиць. Проблеми, пов'язані з надлишковістю даних, можна проілюструвати, порівнявши відношення Staff і Branch, показані в таблицях 6.1 і 6.2, з відношенням Staff_Branch, показаним в таблиці 6.3. Відношення Staff_Branch є альтернативною формою представлення відношень Staff і Branch. Згадані відношення описуються таким чином:

Staff  (StaffNo, SName, SAddress, Position, Salary, Branch_No)

Branch (BranchNo, BAddress, Tel_No)

Staff_Branch    (Staff_No, SName, SAddress, Position, Salary, Branch_No, BAddress, Tel_No)

У Staff_Branch містяться надлишкові дані, оскільки відомості про відділення компанії повторюються в записах, які відносяться до кожного співробітника даного відділення. В протилежність цьому, відносно Branch відомості про відділення містяться лише в одному рядку, а відносно Staff повторюється лише номер відділення компанії (Branch_No), який є місцем роботи кожного співробітника. При роботі із відношеннями, що містять надлишкові дані, можуть виникати проблеми, які називаються аномаліями оновлення і підрозділяються на аномалії вставки, видалення і модифікації.

 

Таблиця 6.1 – Відношення Staff

Staff_No

SName

SAddress

Position

Salary

BranchNo

SL21

John White

19 Taylor St, London

Manager

30000

B5

SG37

AnnBeech

81 George St, Glasgow

Snr Asst

12000

B3

SG14

David Ford

63 Ashby St, Glasgow

Deputy

18000

B3

SA9

Mary Howe

2 Elm PI, Aberdeen

Assistant

9000

B7

SG5

Susan Brand

5 Gt Western Rd, Glasgow

Manager

24000

B3

SL41

Julie Lee

28 Malvern St, Kilburn

Assistant

9000

B5

 

Таблиця 6.2 – Відношення Branch

BranchNo

BAddress

Tel_No

B5

22 Deer Rd, London

0171-886-1212

B7

16 Argyll St, Aberdeen

01224-67125

ВЗ

163 Main St, Glasgow

0141-339-2178

 

Таблиця 6.3 – Відношення Staff_Branch

Staff_No

SName

SAddress

Position

Salary

Branch_No

BAddress

Tel_No

SL21

John White

19 Taylor St, London

Manager

30000

B5

22 Deer Rd, London

0171-886-1212

SG37

AnnBeech

81 George St, Glasgow

Snr Asst

12000

B3

163 Main St, Glasgow

0141-339-2178

SG14

David Ford

63 Ashby St, Glasgow

Deputy

18000

B3

163 Main St, Glasgow

0141-339-2178

SA9

Mary Howe

2 Elm PI, Aberdeen

Assistant

9000

B7

16 Argyll St, Aberdeen

0122-633-7125

SG5

Susan Brand

5 Gt Western Rd, Glasgow

Manager

24000

B3

163 Main St, Glasgow

0141-339-2178

SL41

Julie Lee

28 Malvern St, Kilburn

Assistant

9000

B5

22 Deer Rd, London

0171-886-1212

 

6.2.1 Аномалії вставки

Існує два основні типи аномалій вставки, які ілюструються за допомогою відношення Staff_Branch, показаного в таблиці 6.3.

При вставці відомостей про нових співробітників у відношення Staff_Branch необхідно вказати і відомості про відділення компанії, в якому ці співробітники працюють. Наприклад, при вставці відомостей про нового співробітника відділення 'В7' потрібно буде ввести відомості про саме відділення 'В7', які повинні відповідати відомостям про це ж відділення в інших рядках відношення Staff_Branch.

Для вставки відомостей про нове відділення компанії, яке ще не має власних співробітників, потрібно буде присвоїти значення NULL всім атрибутам опису персоналу відношення Staff_Branch, включаючи і особистий номер співробітника Staff_No. Проте, оскільки атрибут Staff_No є первинним ключем відношення Staff_Branch, то спроба ввести значення NULL в атрибут Stuff_No викличе порушення цілісності сутностей і тому буде відхилена. Отже, у відношення Staff_Branch неможливо ввести рядок про нове відділення компанії, що містить визначник NULL в атрибуті Staff_No. Структура відношень, представлених в таблицях 6.1 і 6.2, дозволяє уникнути виникнення цієї проблеми, оскільки інформація про відділення компанії вводяться у відношення Branch незалежно від вводу відомостей про співробітників. Відомості про співробітників, які працюватимуть в новому відділенні компанії, можуть бути введені у відношення Staff пізніше.

 

6.2.2 Аномалії видалення

При видаленні з відношення Staff_Branch рядка з інформацією про останнього співробітника деякого відділення компанії, відомості про це відділення будуть повністю видалені з бази даних. Наприклад, після видалення з відношення Staff_Branch рядка для співробітника 'Mary Howe' з особистим номером 'SA9' з бази даних неявно будуть видалені всі відомості про відділення з номером 'В7'. Проте структура відношень, показаних в таблиці. 6.1 і 6.2, дозволяє уникнути виникнення цієї проблеми, оскільки рядки з відомостями про відділення компанії зберігаються окремо від рядків з відомостями про співробітників. Зв'язує цих два відношення лише загальний атрибут Branch_No. При видаленні з відношення Staff рядка з номером співробітника 'SA9' інформація про відділення 'В7' відносно Branch залишаться на місці.

 

6.2.3 Аномалії оновлення

При спробі зміни значення одного з атрибутів для деякого відділення компанії відносно Staff_Branch (наприклад, номер телефону відділення 'В3') необхідно поновити відповідні значення в рядках для всіх співробітників цього відділення. Якщо такій модифікації будуть піддані не всі необхідні рядки відношення Staff_Branch, то в цьому випадку база даних міститиме суперечливі відомості. Зокрема, в нашому прикладі для відділення компанії з номером 'В3' в рядках, що відносяться до різних співробітників, помилково можуть бути вказані різні значення номера телефону цього відділення.

Всі наведені вище приклади ілюструють те, що представлені в таблицях 6.1 і 6.2 відношення Staff і Branch володіють прийнятнішими властивостями, ніж відношення Staff_Branch, представлене в таблиці 6.3. Далі в цій лекції розглядаються способи використання процесу нормалізації для отримання правильно спроектованих відношень. Проте спочатку слід познайомитися з концепцією функціональної залежності, яка покладена в основу всього процесу нормалізації.

 

6.2.4 Властивості з'єднання без втрат і збереження залежності

Вище було продемонстровано, що відношення Staff_Branch схильне до аномалій оновлення і, щоб уникнути цих аномалій, краще всього виконати його декомпозицію на окремі відношення Staff і Branch. Проте процес декомпозиції має дві важливі властивості, які слід враховувати. Перше з них – це властивість з'єднання без втрат (lossless-join), яке дозволяє відновити будь-який кортеж вихідного відношення, використовуючи відповідні кортежі менших відношень, отриманих в результаті декомпозиції. Друге – властивість збереження залежності (dependency preservation), яке дозволяє зберегти обмеження, накладені на вихідне відношення, за допомогою накладення деяких обмежень на кожне з менших відношень, отриманих після декомпозиції. Інакше кажучи, в результаті відпадає необхідність виконання з'єднання результуючих відношень з метою перевірки того, чи не порушується обмеження, накладене на вихідне відношення.

 

6.3 Функціональні залежності

 

Функціональна залежність (functional dependency) описує зв'язок між атрибутами і є одним з основних понять нормалізації.

Функціональна залежність – описує  зв'язок  між  атрибутами  відношення. 

Наприклад, якщо відносно відношення R, яке містить атрибути А і В, атрибут В функціонально залежить від атрибутуА (що позначається як А-->В), то кожне значення атрибуту А пов'язано лише з одним значенням атрибуту (В) (Причому кожен з атрибутів А і В може складатися з одного або декількох атрибутів.)

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

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

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

За наявності функціональної залежності атрибут або група атрибутів, розташована на її діаграмі зліва від символу стрілки, називається детермінантом (determinant). Наприклад, атрибут A є детермінантом атрибуту B.

Далі ми ігноруватимемо тривіальні (trivial) функціональні залежності, тобто залежності типу A-->B, де атрибут Bзалежить від деякої підмножини атрибуту A.

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

Приклади тривіальних залежностей для відношення Staff наведені нижче.

staffNo, sName --> sName

staffNo, sName --> staffNo

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

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

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

На рисунку 6.1 показана схема процесу нормалізації і продемонстрований взаємозв'язок між різними нормальними формами. Видно, що одні 1НФ-відношення можуть знаходитися в 2НФ, інші 2НФ-відношення – в 3НФ і так далі.

 

Рисунок 6.1 – Схема взаємозв'язків між окремими нормальними формами

 

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

 

12.6.1 1 нормальна форма

6.4 Перша нормальна форма (1НФ)

 

Перед обговоренням першої нормальної форми доцільно заздалегідь дати визначення того стану, який передує їй.

Ненормалізована форма (ННФ) – таблиця, що містить одну або декілька груп даних, які повторюються.

Перша нормальна форма (1НФ) – відношення, в якому на перетині кожного рядка і кожного стовпця міститься лише одне значення.

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

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

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

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

Хоча обидва цих підходи однаково коректні, слід зазначити, що при використанні другого підходу отримані відношення знаходяться як мінімум в 1НФ і володіють меншою надлишковістю даних. При виборі першого підходу вирівняне 1НФ-відношення буде розкладене в ході подальшої нормалізації на ті ж відношення, які могли б бути отримані за допомогою другого підходу. Проілюструємо використання обидвох цих підходів.

Приклад першої нормальної форми (1НФ).

Показана на рисунку 6.2 форма "Customer Rental Details" з бази даних нерухомості, яка здається в оренду, містить відомості про об'єкти нерухомості, орендовані клієнтом на ім'я 'John Kay'. Для спрощення цього прикладу передбачимо, що клієнт орендує деякий об'єкт лише один раз і не може орендувати одночасно відразу декілька об'єктів.

Дані про об'єкти, орендовані двома клієнтами, 'John Kay' і 'Aline Stewart', перетворяться з форми "Customer Rental Details" в таблицю з рядками і стовпцями, формат якої представлений в таблиці 6.4. Ця вихідна таблиця даних є прикладом ненормалізованої таблиці (ННФ).

 

Page 7

 

Customer Rental Details

 

Date 7-Oct-98

Customer Name John Kay

Customer Number

CR-76

Property Number

Property Address

Rent Start

Rent Finish

Rent

Owner Number

Owner Name

PG4

PG16

6 Lawrence St, Glasgow

5 Novar Dr, Glasgow

01-Jul-94

01-Sep-96

31-Aug-96

01-Sep-98

350

450

CO40

CO93

Tina Murphy

Tony Shaw

                     

Рисунок 6.2 – Форма "Customer Rental Details" з бази даних агенції нерухомості для здачі житла в оренду

 

Таблиця 6.4 – Ненормалізована таблиця Customer_Rental

Customer_No

CName

Property_No

PAddress

RentStart

RentFinish

Rent

Owner_No

OName

CR76

John Kay

PG4

6 Lawrence St, Glasgow

01 -Jul-94

31-Aug-96

350

CO40

Tina Murphy

PG16

5 Novar Dr, Glasgow

01-Sep-96

01-Sep-98

450

CO93

Tony Shaw

CR56

Aline Stewart

PG4

6 Lawrence St, Glasgow

01-Sep-92

30-Jun-94

350

CO40

Tina Murphy

PG36

2 Manor Rd, Glasgow

10-Oct-94

01-Dec-95

375

CO93

Tony Shaw

PG16

5 Novar Dr, Glasgow

01-Jan-96

10-Aug-96

450

CO93

Tony Shaw

 

Як ключовий атрибут ненормалізованої таблиці Customer_Rental (Клієнти-орендарі) виберемо атрибут Customer_No(Номер клієнта). Далі знайдемо в ній групи відомостей про об'єкти, які можуть повторюватися у різних клієнтів. Структура групи, що повторюється, має наступний вигляд: (Property_No, PAddress, RentStart, RentFinish, Rent, Owner_No, OName)

Через наявність цієї групи, що повторюється, на перетині деяких рядків і стовпців таблиці знаходиться відразу декілька значень. Наприклад, два значення, PG4 і PG16, номера об'єкта (атрибут Property_No) присутні в рядку клієнта John Kay. Аби перетворити ненормалізовану таблицю в першу нормальну форму необхідно добитися того, аби на перетині кожного рядка і кожного стовпця знаходилося єдине значення. Ця мета досягається шляхом усунення груп, що повторюються.

При використанні першого підходу група (відомості про об'єкт нерухомості), що повторюється, усувається за допомогою введення в кожен рядок з описом об'єкту нерухомості відповідних відомостей про клієнта. Отримане в результаті цих дій відношення Customer_Rental, що знаходиться в першій нормальній формі, представлене в таблиці 6.5. Потенційні ключі цього відношення є складеними і включають наступні групи атрибутів: (Customer_No, Property_No), (Customer_No, RentStart), (Property_No, RentStart). Як первинний ключ цього відношення виберемо групу (Customer_No, Property_No) і для більшої ясності розмістимо атрибути даного первинного ключа поруч, з лівого боку відношення. (У нашому прикладі передбачається, що атрибут RentFinish не може бути використаний як компонент потенційного ключа.)

 

Таблиця 6.5 – Перша нормальна форма (1 НФ) відношення Customer_Rental

Customer_No

Property_No

CName

PAddress

RentStart

RentFinish

Rent

Owner_No

OName

CR76

PG4

John Kay

6 Lawrence St, Glasgow

01-Jul-94

31-Aug-96

350

CO40

Tina Murphy

CR76

PG16

John Kay

5 Novar Dr, Glasgow

01-Sep-96

01-Sep-98

450

CO93

Tony Shaw

CR56

PG4

Aline Stewart

6 Lawrence St, Glasgow

01-Sep-92

10-Jun-94

350

CO40

Tina Murphy

CR56

PG36

Aline Stewart

2 Manor Rd, Glasgow

10-Oct-94

01-Dec-95

375

CO93

Tony Shaw

CR56

PG16

Aline Stewart

5 Novar Dr, Glasgow

01-Jan-96

10-Aug-96

450

CO93

Tony Shaw

 

Відношення Customer_Rental визначається таким чином:

Customer_Rental (Customer_No, Property_No, CName, PAddress, RentStart, RentFinish, Rent, Owner_No, OName)

Відношення Customer_Rental знаходиться в першій нормальній формі, оскільки на перетині кожного рядка і кожного стовпця є єдине значення. Це відношення містить дані про клієнтів, орендовані об'єкти нерухомості і їх власників, які кілька разів повторюються. Відношення Customer_Rental характеризується значною надлишковістю даних. При фізичній реалізації це 1НФ-відношення буде схильне до аномалій оновлення. Щоб уникнути цього, його потрібно перетворити в другу нормальну форму.

При використанні другого підходу група (відомості про орендовані об'єкти нерухомості), що повторюється, видаляються з даного відношення і поміщається в інше разом з копією вихідного ключового атрибуту (Customer_No), як показано в таблиці 6.7. (Залишок вихідного відношення представлений в таблиці 6.6.) Потім для нового відношення вибирається власний первинний ключ. Формат двох створених 1НФ-відношень буде наступним:

Customer    (Customer_No, CName)

Prop_Rental_Owner (Customer_No, Property_No, PAddress, RentStart, RentFinish, Rent, Owner_No, OName)

 

Таблиця 6.6 – Альтернативне представлення першої нормальної форми (1НФ) – відношення Customer

Customer_No

CName

CR76

John Kay

CR56

Aline Stewart

 

Таблиця 6.7 – Альтернативне представлення першої нормальної форми (1НФ) – відношення Prop_Rental_Owner

Customer_No

Property_No

PAddress

RentStart

RentFinish

Rent

Owner_No

OName

CR76

PG4

6 Lawrence St, Glasgow

01-Jul-94

31-Aug-96

350

CO40

Tina Murphy

CR76

PG16

5 Novar Dr, Glasgow

01-Sep-96

01-Sep-98

450

CO93

Tony Shaw

CR56

PG4

6 Lawrence St, Glasgow

01-Sep-92

10-Jun-94

350

CO40

Tina Murphy

CR56

PG36

2 Manor Rd, Glasgow

10-Oct-94

01-Dec-95

375

CO93

Tony Shaw

CR56

PG16

5 Novar Dr, Glasgow

01-Jan-96

10-Aug-96

450

CO93

Tony Shaw

 

Обидва відношення – і Customer, і Prop_Rental_Owner – знаходяться в першій нормальній формі, оскільки на перетинікожного рядка і кожного стовпця знаходиться єдине значення. Відношення Customer містить дані про клієнтів, авідношення Prop_Rental_Owner – про орендовані об'єкти нерухомості і їх власників. Проте, як видно з таблиці 6.7, останнє відношення також володіє деякою надлишковістю даних, а тому може постраждати від аномалій оновлення.

Для демонстрації подальшого процесу нормалізації відношень з переходом від 1НФ до 2НФ використовуватиметься лише відношення Customer_Rental, представлене в таблиці 6.5. Проте слід ще раз нагадати, що два наведені підходи коректні і зрештою – при продовженні процесу нормалізації аж до НФБК – приведуть до створення однакових відношень.

 

12.6.2 2 Нормальна форма

6.5 Друга нормальна форма (2НФ)

 

Друга нормальна форма (2НФ) заснована на понятті повної функціональної залежності, яка описується нижчим.

 

6.5.1 Повна функціональна залежність

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

Функціональна залежність А-->В є повною функціональною залежністю, якщо видалення якого-небудь атрибуту з Анаводить до втрати цієї залежності. Частковою функціональною залежністю називається така залежність А-->В, якщо в А є деякий атрибут, при видаленні якого ця залежність зберігається.

Наприклад, розглянемо наступну функціональну залежність:

Staff_No, SName --> Branch_No

Тут кожна пара значень (Staff_No, SName) пов'язана з єдиним значенням Branch_No. Проте ця функціональна залежність не є повною, оскільки Branch_No також функціонально залежить від підмножини (Staff_No, SName), тобто від атрибуту Staff_No. Інші приклади повною і частковою функціональною залежностей описуються в наступних розділах.

 

6.5.2. Визначення другої нормальної форми

Друга нормальна форма застосовується до відношень із складеними ключами, тобто до таких відношень, первинний ключ яких складається з двох або більше атрибутів. Річ у тому, що відношення з первинним ключем на основі єдиного атрибуту завжди знаходиться, принаймні, в 2НФ. Відношення, яке не знаходиться в 2НФ, може страждати від аномалій оновлення. Наприклад, передбачимо, що необхідно змінити орендну плату для об'єкта нерухомості з номером 'PG4'. Для цього потрібно буде поновити два рядки відношення Customer_Rental. Якщо значення орендної плати буде змінено лише в одному рядку, то в результаті база даних буде приведена в суперечливий стан.

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

Нормалізація 1НФ-відношень з утворенням 2НФ-відношень включає усунення часткових залежностей, що демонструється на прикладі відношення Customer_Removal, представленого в таблиці 6.5. Якщо у відношенні між атрибутами існує часткова залежність, то функціонально-залежні атрибути видаляються з нього і поміщаються в нове відношення разом з копією їх детермінанта.

Приклад другої нормальної форми (2НФ).

На риснку 6.3 показані функціональні залежності (від fdl до fd6) для відношення Customer_Rental з парою атрибутів (Customer_No, Property_No) як первинний ключ. Відношення Customer_Rental володіє наступними функціональними залежностями:

fdl

Customer_No, Property_No --> RentStart, RentFinish

Первинний ключ

fd2

Customer_No --> Cname

Часткова залежність

fd3

Property_No --> PAddress, Rent, Owner_No, OName

Часткова залежність

fd4

Owner_No --> OName

Транзитивна залежність

fd5

Customer_No, RentStart --> Property_No, PAddress, Rent-Finish, Rent, Owner_No, OName

Потенційний ключ

fd6

Property_No, RentStart --> Customer_No, CName, RentFinish

Потенційний ключ

 

Рисунок 6.3 – Функціональні залежності відношення Property_Rental

 

Після виявлення функціональних залежностей процес нормалізації відношення Customer_Rental продовжується перевіркою його належності до другої нормальної форми. Для цього потрібно знайти хоч би один випадок часткової залежності від первинного ключа. Неважко відмітити, що атрибут імені клієнта CName частково залежить від первинного ключа, інакше кажучи, він залежить лише від атрибуту Customer_No (ця залежність представлена як fd2). Крім того, атрибути об'єкту нерухомості (PAddress, Rent, Owner_No, OName) також частково залежать від первинного ключа, але цього разу лише від атрибуту Property_No (ця залежність представлена вище як fd3). У свою чергу, атрибути орендованих об'єктів нерухомості (RentStart і RentFinish) повністю функціонально залежать від первинного ключа в цілому, тобто від атрибутів Customer_No і Property_No (ця залежність представлена як fd1).

Зверніть увагу на те, що на рисунку 6.3 показана наявність транзитивної залежності (transitive dependence) від первинного ключа (ця залежність представлена як fd4). Хоча транзитивна залежність також може послужити причиною аномалій оновлення, проте її присутність у відношенні не порушує обмежень для 2НФ. Такі залежності будуть усунені при переході до 3НФ.

Виявлення часткових залежностей усередині відношення Customer_Rental означає, що дане відношення не знаходиться в другій нормальній формі. Для перетворення відношення Customer_Rental в 2НФ необхідно створити нові відношення, причому так, щоб атрибути, які не входять в первинний ключ, були переміщені в них разом з копією частини первинного ключа, від якої вони функціонально залежать. Використання цього правила в нашому випадку приведе до створення трьох нових відношень – Customer, Rental і Property_Owner, які представлені в таблицях 6.8, 6.9 і 6.10 відповідно. Тепер ці відношення знаходяться в другій нормальній формі, оскільки кожен атрибут, що не входить в первинний ключ, повністю функціонально залежить від первинного ключа відношення. Ці відношення мають наступний вигляд:

Customer (Customer_No, CName)

Rental (Customer No. Property Nof RentStart, RentFinish)

Property_Owner (Property_No, PAddress, Rent, Owner_No, OName)

 

Таблиця 6.8 – Відношення Customer

Customer_No

CName

CR76

John Kay

CR56

Aline Stewart

 

Таблиця 6.9 – Відношення Rental

CustomerNo

PropertyNo

RentStart

RentFinish

CR76

PG4

1-Jul-94

31-Aug-96

CR76

PG16

1-Sep-96

1-Sep-98

CR56

PG4

1-Sep-92

10-Jun-94

CR56

PG36

10-Oct-94

1-Dec-95

CR56

PG16

1-Jan-96

10-Aug-96

 

Таблиця 6.10 – Відношення Property_Owner

Property_No

PAddress

Rent

Owner_No

OName

PG4

6 Lawrence St, Glasgow

350

CO40

Tina Murphy

PG16

5 Novar Dr, Glasgow

450

CO93

Tony Shaw

PG36

2 Manor Rd, Glasgow

375

CO93

Tony Shaw

 

12.6.3 3 нормальна форма

6.6 Третя нормальна форма (3НФ)

 

Хоча 2НФ-відношення у меншій мірі володіють надлишковістю даних, ніж 1НФ, вони все ще можуть страждати від аномалій оновлення. Так, при спробі оновлення імені власника нерухомості (наприклад, Tony Shaw з номером СО93 (атрибут Owner_No)) потрібно буде відновити два рядки відношення Property_Owner, представленого в таблиці 6.10. Якщо змінити лише один з цих двох рядків, база даних перейде в неузгоджений стан. Ця аномалія оновлення спиричинена транзитивною залежністю, присутньою в даному відношенні. Вона може бути усунена шляхом приведення даного відношення до третьої нормальної форми. У цьому розділі транзитивні залежності розглядаються разом з третьою нормальною формою.

 

6.6.1 Транзитивна залежність

Транзитивна – якщо для атрибутів AB і С деякого відношення існують залежності вигляду A --> B і В-->С, то говорять, що атрибут C транзитивно залежить від атрибута А через атрибут B (за умови, що атрибут А функціонально не залежить ні від атрибуту B, ні від атрибуту C).

Транзитивна залежність є описом такого типу функціональної залежності, яка виникає за наявності наступних функціональних залежностей між атрибутами АВ і СА-->B і B-->C.

Розглянемо наступні функціональні залежності всередині відношення Staff_Branch, представленого в таблиці. 6.3.

Staff_No --> Branch_No   і   Branch_No --> BAddress

В цьому випадку транзитивна залежність Staff_No --> BAddress здійснюється через атрибут Branch_No. Дане твердження справедливе, оскільки атрибут Staff_No не залежить функціонально від атрибутів Branch_No і BAddress.

 

6.6.2 Визначення третьої нормальної форми

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

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

Приклад третьої нормальної форми (3НФ).

Спочатку розглянемо функціональні залежності, що існують у відношеннях Customer, Rental і Property_Owner.

Відношення Customer:

fd2       Customer_No --> CName

Відношення Rental:

fdl        Customer_No, Property_No --> RentStart, RentFinish

fd5*     Custoroer_No, RentStart --> Property_No, RentFinish

fd6*     Property_No, RentStart --> Customer_No, RentFinish

Відношення Property_Owner:

fd3       Property_No --> PAddress, Rent, Owner_No, OName

fd4       Owner_No --> OName

Всі атрибути відношень Customer і Rental, котрі не входять в первинний ключ, функціонально залежні лише від їх первинних ключів. Отже, відношення Customer і Rental не мають транзитивних залежностей, а тому вони вже знаходяться в третій нормальній формі (3НФ). (Зверніть увагу на те, деякі функціональні залежності (fd) помічені зірочкою (*), що означає зміну цієї залежності (в порівнянні з вихідною функціональною залежністю).)

Всі атрибути відношення Property_Owner, які не входять в первинний ключ, функціонально залежать від нього, за винятком атрибуту OName, який також залежить і від атрибуту Owner_No (залежність fd4). Дана транзитивна залежність схематично показана на рисунку 6.3.

Для перетворення відношення Property_Owner в третю нормальну форму необхідно перш за все видалити згадану вище транзитивну залежність шляхом створення двох нових відношень Property_for_Rent і Owner, які представлені в таблицях 6.11 і 6.12 відповідно. Нові відношення мають наступний вигляд:

Property_for_Rent (Property_No, PAddress, Rent, Owner_No)

Owner (Owner_No, OName)

 

Таблиця 6.11 – Відношення Property_for_Rent в третій нормальній формі

Property_No

PAddress

Rent

OwnerNo

PG4

6 Lawrence St, Glasgow

350

CO40

PG16

5 Novar Dr, Glasgow

450

CO93

PG36

2 Manor Rd, Glasgow

375

CO93

 

Таблиця 6.12 – Відношення Owner в третій нормальній формі

OwnerNo

OName

CO40

Tina Murphy

CO93

Tony Shaw

 

Відношення Property_for_Rent і Owner знаходяться в третій нормальній формі, оскільки в них немає жодних транзитивних залежностей від первинного ключа.

В результаті виконання нормалізації представлене в таблиці 6.5 вихідне відношення Customer_Rental було перетворене в чотири окремі відношення, кожне з яких знаходиться в третій нормальній формі. На рисунку 6.4 приведена схема даного процесу, яка пояснює, як 1НФ-відношення було перетворене в чотири 3НФ-відношення, що мають наступний вигляд:

Customer    (Customer_No, CName)

Rental     (Customer_No, Property__No, RentStart, RentFinish)

Property_for_Rent         (Property_No, PAddress, Rent, Owner_No)

Owner     (Owner_No, OName)

Вихідне відношення Customer_Rental, представлене в таблиці 6.5, може бути відновлене шляхом з'єднання відношеньCustomer, Rental, Property_for_Rent і Owner. Дана ціль досягається за рахунок використання первинних і зовнішніх ключів. Наприклад, атрибут Owner_No є первинним ключем відношення Owner і, крім того, присутній у Property_for_Rent як його зовнішній ключ. Атрибут Owner_No, використаний для створення пари з первинного і зовнішнього ключів, дозволяє зв'язати відношення Property_for_Rent і Owner з метою визначення імен власників орендованих об'єктів нерухомості.

 

Рисунок 6.4 – Схема декомпозиції 1НФ-отношения Customer_Rental на чотири відношення в третій нормальній формі

 

Атрибут Customer_No є первинним ключем відношення Customer і, додатково, зовнішнім ключем відношення Rental. Відносно Rental атрибут Customer_No виконує функцію як зовнішнього, так і частини первинного ключа. Аналогічним чином, атрибут Property_No є первинним ключем відношення Property_for_Rent і, додатково, відносно Rental виконує функції як зовнішнього ключа, так і частини первинного ключа.

Інакше кажучи, процес нормалізації полягає в декомпозиції вихідного відношення Customer_Rental за допомогою послідовного виконання декількох операцій проекції реляційної алгебри (див. лекцію 5). Отримані в результаті декомпозиції відношення забезпечують виконання їх з'єднання без втрат, тому дану процедуру інакше називають безпрограшною (nonloss) (або неадитивною (nonadditive)) декомпозицією. Результати декомпозиції можна обернути за допомогою операції природного з'єднання.

Остаточний вигляд відношень Customer, Rental, Property_for_Rent і Owner, отриманих в результаті декомпозиції, представлений в таблицях 6.13, 6.14, 6.15 і 6.16 відповідно.

 

Таблиця 6.13 – Відношення Customer

CustomerNo

CName

CR76

John Kay

CR56

Aline Stewart

 

Таблиця 6.14 – Відношення Rental

CustomerNo

PropertyNo

RentStart

RentFinish

CR76

PG4

1-Jul-94

31-Aug-96

CR76

PG16

1-Sep-96

1-Sep-98

CR56

PG4

1-Sep-92

10-Jun-94

CR56

PG36

10-Oct-94

1-Dec-95

CR56

PG16

1-Jan-96

10-Aug-96

 

Таблиця 6.15 – Відношення Property_for_Rent

Property_No

PAddress

Rent

OwnerNo

PG4

6 Lawrence St, Glasgow

350

CO40

PG16

5 Novar Dr, Glasgow

450

CO93

PG36

2 Manor Rd, Glasgow

375

CO93

 

Таблиця 6.16 – Відношення Owner

OwnerNo

OName

CO40

Tina Murphy

CO93

Tony Shaw

 

12.6.4 Нормальна форма Бойса-Кодда

6.7 Нормальна форма Бойса-Кодда (НФБК)

 

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

 

6.7.1 Визначення нормальної форми Бойса-Кодда

Нормальна форма Бойса-Кодда (НФБК) враховує функціональні залежності, в яких беруть участь всі потенційні ключі відношення, а не лише його первинний ключ. Для відношення з єдиним потенційним ключем його 3НФ і НФБК є еквівалентними.

Нормальна форма Бойса Кодда (НФБК) – відношення знаходиться в НФБК тоді і лише тоді, коли кожен його детермінант є потенційним ключем.

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

Відмінність між 3НФ і НФБК полягає в тому, що функціональна залежність А-->В допускається в 3НФ-відношенні, якщо атрибут В не є первинним ключем, а атрибут А не обов'язково є потенційним ключем. Тоді як в НФБК-відношенні ця залежність допускається лише тоді, коли атрибут А є потенційним ключем. Отже нормальна форма Бойса-Кодда є жорсткою версією форми 3НФ, оскільки кожне НФБК-відношення є 3НФ-відношенням, але не кожне 3НФ-відношення є НФБК-відношенням.

Перш ніж звернутися до чергового прикладу, ще раз розглянемо відношення Customer, Rental, Property_for_Rent і Owner, представлені в таблицях 6.13-6.16. Відношення Customer, Property_for_Rent і Owner є НФБК-відношеннями, оскільки кожне з них має лише один детермінант, який в той же час є потенційним ключем цього відношення. Тут слід нагадати, що відношення Rental містить три детерминанти – (Customer_No, Property_No), (Customer_No, RentStart) і (Property_No, RentStart), – які мають вигляд, показаний нижче.

fdl

Customer_No, Property_No-->RentStart, RentFinish

fd5

Customer_No, RentStart-->Property_No, RentFinish

fd6

Property_No, RentStart-->Customer_No, RentFinish

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

-       є два (або більше) складені потенційні ключі;

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

У наступному прикладі описується ситуація, коли відношення порушує вимоги НФБК, і представлений метод перетворення цього відношення в НФБК.

В даному прикладі ми розглянемо відношення Client_Interview, яке містить відомості про співбесіди клієнтів із співробітниками компанії, яка надає послуги оренди житла. Для проведення співбесіди того дня, на який призначена зустріч з клієнтом, в розпорядження співробітника надається окрема кімната. Проте протягом робочого дня ця кімната може використовуватися декількома різними співробітниками. З клієнтом проводиться лише одне співбесіда в день, але він може брати участь в декількох співбесідах в різні дні. Обговорюване відношення має три потенційні ключі: (Client_No, Interview_Date), (Staff_No, Interview_Date, Interview_Time) і (Room_No, Interview_Date, Interview_Time). Отже, відношенняClient_Interview володіє трьома складеними потенційними ключами, які перекриваються, тобто ними спільно використовується один загальний атрибут – Interview_Date. Як первинний ключ даного відношення вибрана комбінація атрибутів (Client_No, Interview_Date). Це відношення представлене в таблиці 6.17 і має наступний вигляд:

Client_Interview (Client_No, Interview_Date, Interview_Time, Staff_No, Room_No)

 

Таблиця 6.17 – Відношення Client Interview

Client_No

lnterview_Date

Interviewtime

Staff_No

Room_No

CR76

13-May-98

10.30

SG5

G101

CR56

13-May-98

12.00

SG5

G101

CR74

13-May-98

12.00

SG37

G102

CR56

01-Jul-98

10.30

SG5

G102

 

Воно містить наступні функціональні залежності:

fdl     client_No, Interview_Date --> Interview_Time, Staff_No, Room_No Первинний ключ

fd2    staff_No, Interview_Date, Interview_Time --> Client_No Потенційний ключ

fd3    Room_No, Interview_Date, Interview_Time --> Staff_No, Client_No Потенційний ключ

fd4    Staff No, Interview_Date --> Room_No

Розглянемо ці функціональні залежності для визначення нормальної форми відношення Client_Interview. Оскільки функціональні залежності fdl, fd2 і fd3 є потенційними ключами цього відношення, то вони не викличуть жодних проблем. Нам потрібно буде розглянути лише функціональну залежність Staff_No, Interview_Date --> Room_No (залежність fd4). Навіть якщо комбінація атрибутів (Staff_No, Interview_Date) не є потенційним ключем відношення Client_Interview, ця функціональна залежність допускається в 3НФ, тому що атрибут Room_No є атрибутом первинного ключа і частиною потенційного ключа (Room_No,   Interview_Date,   Interview_Time). Оскільки в цьому відношенні немає жодних часткових або транзитивних залежностей від первинного ключа (Client_No,   Interview_Date) і допускається наявність функціональної залежності fd4, можна вважати, що відношення Client_Interview знаходиться в 3НФ. Проте це відношення не знаходиться в НФБК (строгіший варіант 3НФ), оскільки в ньому присутній детермінант (Staff_No, Interview_Date), який не є потенційним ключем цього відношення. У НФБК потрібно, аби всі детермінанти відношення були його потенційними ключами. Інакше відношення Client_Interview може страждати від аномалій оновлення. Наприклад, 13 травня 1998 року (значення   '13-Мау-98')  при  зміні  номера кімнати,  виділеної  співробітникові 'SG5', потрібно буде змінити значення в двох рядках. Якщо при цьому буде оновлений лише один рядок, то база даних буде приведена у суперечливий стан. Для перетворення відношення Client_Interview у НФБК необхідно усунути функціональну залежність, яка порушує обмеження НФБК, за допомогою створення двох нових відношень – Interview і Staff_Room, – представлених в таблицях 6.18 і 6.19 відповідно. Відношення Interview і Staff_Room мають наступний вигляд:

Interview     (Client_No, Interview_Date, Interview_Time, Staff_No)

Staff_Room    (Staff_No, Interview_Date, Room_No)

 

Таблиця 6.18 – Відношення Interview в НФБК

Client_No

lnterview_Date

lnterview_Time

Staff_No

CR76

13-May-98

10.30

SG5

CR56

13-May-98

12.00

SG5

CR74

13-May-98

12.00

SG37

CR56

1-Jul-98

10.30

SG5

 

Таблиця 6.19 – Відношення Staff_Room в НФБК

Staff_No

Interview_Date

Room_No

SG5

13-Мау-98

G101

SG37

13-Мау-98

G102

SG5

1-Jul-98

G102

 

Над будь-яким відношення, яке не знаходиться в НФБК, можна виконати декомпозицію з утворенням НФБК-відношень, проте робити це не завжди бажано. Наприклад, декомпозиція буде небажана, якщо в результаті її виконання втрачається деяка функціональна залежність (тобто детермінант і визначувані ним атрибути поміщаються в різні відношення). У цій ситуації буде важко забезпечити вихідну функціональну залежність відношення і важливе обмеження може бути втрачено. Якщо має місце згадана ситуація, то краще закінчити процес нормалізації на етапі утворення 3НФ-відношень, в яких всі необхідні залежності завжди зберігаються. Зверніть увагу на те, що в прикладі при створенні двох нових НФБК-відношень на основі вихідного відношення Client_Interview втрачається наступна функціональна залежність: Room_No, Interview_Date, Interview_Time --> Staff_No, Client_No (залежність fd3), оскільки детермінант цієї залежності більше не знаходитиметься в тому ж відношенні, що і визначувані ним атрибути. Проте слід визнати, що якщо не усунути функціональну залежність Staff_No, Interview_Date --> Room_No (залежність fd4), то відношення Client_Interview володітиме надлишковістю даних.

12.6.5 Нормальні форми вищих порядків

Нормалізацію реляційних баз даних можна проводити і далі – до наступних нормальних форм після нормальної форми Бойса-Кодда (4НФ та 5НФ), які називають нормальними формами вищих порядків. Але на практиці нормалізацію виконують, як правило, не до кінця. Чому так?

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

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

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

Тобто, якщо навіть при нявності зайвої надлишковості даних реалізовані обмеження предметної області (засобами СКБД чи прикладної програми) дозволять уникнути аномалій поновлення, то нормалізацію далі 1НФ виконувати не обов’язково.

Тому на прктиці нормалізацію далі 3НФ чи НФБК не проводять.

Але при подальшому аналізі нормалізованих до НФБК відношень у них теж може бути наявна зайва надлишковість даних, яка може спричинити аномалії поновлення.

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

Перейдемо до розгляду цих нормальних форм.

12.6.5.1 4 нормальна форма

7.1 Четверта нормальна форма (4НФ)

 

Як було сказано вище, НФБК – дозволяє усунути будь-які аномалії, викликані функціональними залежностями. Проте в результаті теоретичних досліджень був виявлений ще один тип залежності – багатозначна залежність (Multi-ValuedDependency – MVD), яка при проектуванні відносин також може викликати проблеми, пов'язані з надмірністю даних. У цьому розділі стисло описуються багатозначна залежність і зв'язок залежності цього типу з четвертою нормальною формою (4НФ).

 

7.1.1 Багатозначна залежність

Можливість існування у відношенні багатозначних залежностей виникає внаслідок приведення початкових таблиць до форми 1НФ, для якої не допускається наявність деякого набору значень на перетині одного рядка і одного стовпця. Наприклад, за наявності у відношенні двох багатозначних атрибутів для досягнення неузгодженого стану рядків необхідно повторити в них кожне значення одного з атрибутів у поєднанні з кожним значенням іншого атрибуту. Подібний тип обмеження породжує багатозначну залежність і приводить до надлишковості даних. Розглянемо представлене в таблиці 7.1 відношення Branch_Staff_Owner, в якому містяться імена співробітників (sName) і власників нерухомості (oName) певного відділення компанії (branchNo). В цьому випадку припустимо, що ім'я співробітника (sName) однозначно ідентифікує кожного члена персоналу компанії, а ім'я власника (oName) однозначно ідентифікує кожного власника.

 

Таблиця 7.1 – Відношення Branch_Staff_Owner

branch No

sName

oName

B003

Ann Beech

Carol Farrel

B003

David Ford

Carol Farrel

B003

Ann Beech

Tina Murphy

B003

David Ford

Tina Murphy

 

В даному прикладі у відділенні компанії з номером 'В003’ працюють співробітники з іменами 'Ann Beech' і 'David Ford'. Крім того, у ньому зареєстровані власники нерухомості з іменами 'Carol Farrel і 'Tina Murphy'. Проте якщо в даному відділенні компанії між співробітниками і власниками нерухомості немає ніякого прямого зв'язку, то необхідно створити рядок для кожного поєднання даних про співробітника і власника для забезпечення гарантії, що відношення знаходиться в несуперечливому стані. Цю вимогу відображає наявність у відношенні BranchStaffOwner багатозначної залежності. Інакше кажучи, в даному відношенні існує багатозначна залежність, оскільки в ньому містяться два незалежні зв'язки типу 1:М.

Багатозначна залежність – представляє таку залежність між атрибутами відношення (наприклад, А, B і C, що для кожного значення атрибуту A є набір значень атрибуту B і набір значень атрибуту C, проте вхідні в ці набори атрибути B і Cне залежать один від одного.

Багатозначна залежність між атрибутами А, В і C деякого відношення далі позначатиметься таким чином:

А --> B

А --> C

Наприклад, визначимо багатозначну залежність, що має місце у відношенні Branch_Staff_Owner, представленому в таблиці 7.1, таким чином:

branchNo --> sName

branchNo --> oName

Багатозначна залежність може бути додатково визначена як тривіальна або нетривіальна. Наприклад, багатозначна залежність A-->B деякого відношення R визначається як тривіальна, якщо атрибут B є підмножиною атрибуту A або AB = R. І навпаки, багатозначна залежність визначається як нетривіальна, якщо ні та, ні інша умова не виконується. Тривіальна багатозначна залежність (БЗЗ) не накладає ніяких обмежень на дане відношення, а нетривіальна – накладає.

Багатозначна залежність в представленому в табл. 7.1 відношенні Branch_Staff_Owner є нетривіальною, оскільки в цьому відношенні ні та ні інша умова не задовольняється. Отже, на відношення Branch_Staff_Owner внаслідок наявності нетривіальної БЗЗ накладається обмеження, яке приводить до появи рядків, що повторюються, необхідних для того, щоб гарантувати несуперечність зв'язку між атрибутами sName і oName. Наприклад, якби потрібно було зареєструвати нового власника нерухомості у відділенні В003, то довелося б створити два нові рядки, по одному для кожного співробітника компанії, щоб забезпечити збереження неузгодженого стану вказаного відношення. Це – приклад аномалії оновлення, викликаній наявністю нетривіальній багатозначної залежності.

Хоча відношення Branch_Staff_Owner знаходиться у формі НФБК, воно все ще залишається погано структурованим через надлишковість даних, викликану наявністю нетривіальної БЗЗ. Очевидно, що доцільніше було б визначити строгішу форму НФБК, яка виключила б створення таких реляційних структур, як відношення Branch_Staff_Owner.

 

7.1.2 Визначення четвертої нормальної форми

Четверта нормальна форма – відношення в нормальній формі Бойса-Кодда, яке не містить нетривіальних багатозначних залежностей.

Четверта нормальна форма (4НФ) є строгішим різновидом нормальної форми Бойса-Кодда, оскільки у відносинах4НФ немає нетривіальних БЗЗ і тому немає і налишковості даних. Нормалізація відношення НФБК з отриманням відношень 4НФ полягає в усуненні БЗЗ з відношення НФБК шляхом виділення в нове відношення одного або декількох атрибутів, що беруть участь в БЗЗ, разом з копією одного або декількох детермінантів.

Наприклад, відношення Branch_Staff_Owner (див. табл. 7.1) не знаходиться у формі 4НФ, оскільки в ньому присутня нетривіальна БЗЗ. Це відношення слід перетворити у відносини BranchStaff і BranchOwner, показані в таблицях 7.2 і 7.3. Обидва нові відношення знаходяться у формі 4НФ, оскільки відношення BranchStaff містить тривіальну БЗЗ branchNo -->sName, а відношення BranchOwner – тривіальну БЗЗ branchNo --> oName. Ці відношення у формі 4НФ не характеризуються надлишковістю даних, а можливість появи аномалій оновлення виключена. Наприклад, щоб зареєструвати у відділенні В003 нового власника об'єкту нерухомості, досить ввести єдиний рядок у відношення BranchOwner.

 

Таблиця 7.2 – Відношення BranchStaff у формі 4НФ

branchNo

sName

В003

Ann Beech

В003

David Ford

 

Таблиця 7.3 – Відношення BranchOwner у формі 4НФ

branchNo

oName

В003

Carol Farrel

В003

Tina Murphy

 

 

12.6.5.2 5 нормальна форма

7.3 П'ята нормальна форма (5НФ)

 

При будь-якій декомпозиції відношення на два інших отримані відношення володіють властивістю з'єднання без втрат. Це означає, що отримані відношення можна знову з'єднати і отримати колишнє відношення в початковому вигляді. Проте бувають випадки, коли потрібно виконати декомпозицію відношення більш ніж на два відношення. У таких (достатньо рідкісних) випадках виникає необхідність враховувати залежність з'єднання без втрат, яка усувається за допомогою п'ятої нормальної форми (5НФ). Тому коротко розглянемо суть залежності з'єднання без втрат і її зв'язок з п'ятою нормальною формою (5НФ).

 

7.3.1 Залежність з'єднання без втрат

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

При розбитті відношень за допомогою операції проекції використовуваний метод декомпозиції визначається абсолютно точно. Зокрема, слід потурбуватися про те, щоб при зворотному з'єднанні отриманих відношень можна було відновити початкове. Така декомпозиція називається декомпозицією із з'єднанням без втрат (а також безпрограшним абонеадитивним з'єднанням), оскільки при її виконанні зберігаються всі дані початкового відношення, а також виключається створення додаткових фіктивних рядків. Наприклад, відношень BranchStaff і BranchOwner (табл. 7.2 і 7.3), які отримані шляхом декомпозиції відношення Branch_Staff_Owner (див. табл. 7.1), володіють властивістю з'єднання без втрат. Інакше кажучи, початкове відношення Branch_Staff_Owner може бути реконструйоване шляхом застосування операції природного з'єднання до відношень BranchStaff і BranchOwner. В даному прикладі виконана декомпозиція початкового відношення на два відношення, проте бувають випадки, коли потрібно виконати декомпозицію втрат з утворенням більше двох відношень. Саме у таких випадках застосовні поняття залежності з'єднання без втрат і п'ятої нормальної форми (5НФ).

 

7.3.2 Визначення п'ятої нормальної форми (5НФ)

П’ята нормальна форма – відношення без залежностей з'єднання.

П'ята нормальна форма (5НФ), яка також називається проекційно-з’єднувальною нормальною формою, або ПЗНФ(Project-Join Normal Form – PJNF), означає, що відношення в такій формі не має залежностей з'єднання. Розглянемо показане на рисунку 7.1 відношення PropertyItemSupplier. Це відношення описує об'єкти нерухомості (propertyNo), для яких потрібні певні предмети обстановки (ItemDescription), що поставляються постачальниками (supplierNo) на ці об'єкти нерухомості (propertyNo). Крім того, якщо для якогось об'єкту нерухомості (p) потрібний деякий предмет обстановки (i), якийсь постачальник (s) займається постачанням таких предметів (i), і постачальник (s) вже виконав постачання, щонайменше, одного предмету обстановки на цей об'єкт нерухомості (p), то цьому ж постачальникові (s) знову буде доручено поставити необхідний предмет обстановки (i) на об'єкт нерухомості (p).

Щоб визначити, якого роду обмеження розповсюджується на відношення PropertyItemSupplier (рис. 7.1, а), розглянемо наступне твердження.

Якщо для об'єкту нерухомості PG4 потрібний предмет обстановки 'Bed' (згідно даним в рядка 1), постачаннями на об'єкт нерухомості PG4 займається постачальник S2 (згідно даними в рядку 2), постачальник S2 займається постачаннями предметів обстановки 'Bed' (згідно даним в рядку 3), то постачальник S2 повинен виконати постачання предмету обстановки 'Bed' на об'єкт нерухомості PG4.

Цей приклад наочно ілюструє циклічний характер обмеження, яке розповсюджується на відношенняPropertyItemSupplier. Якщо це обмеження дотримується, то рядок (PG4, Bed, S2) повинен існувати у всіх допустимих станах відношення PropertyItemSupplier (рис. 7.1, б). Це – приклад однієї з аномалій оновлення, і таке відношення називається таким, що містить залежність з'єднання (Join Dependency – JD).

Залежність з'єднання є одним з різновидів залежності. Наприклад, якщо розглядається відношення R з підмножиною атрибутів, позначеними як A, B, ..., Z, то відношення R задовольняє залежності з'єднання, якщо і тільки якщо кожне допустиме значення R рівне з'єднанню його проекцій на атрибути А, B, ..., Z.

Отже, відношення PropertyItemSupplier містить залежність з'єднання і тому не знаходиться в п'ятій нормальній формі (5НФ): для видалення цієї залежності з'єднання необхідно виконати декомпозицію відношення PropertyltemSupplier на три відношення 5НФ, а саме PropertyItem (R1), ItemSupplier (R2) і PropertySupplier (R3), як показано в табл. 7.4 – 7.6. У такому разі можна стверджувати, що відношення PropertyItemSupplier у формі (A, B, C) задовольняє залежності з'єднання JD R (A,B), R2 (B, C), R3(A, C)).

 

Таблиця 7.4 – Відношення PropertyItem у формі 5НФ

propertyNo

ItemDescription

PG4

Bed

PG4

Chair

PG16

Bed

 

Таблиця 7.5 – Відношення ItemSupplier у формі 5НФ

ItemDescription

supplierNo

Bed

S1

Chair

S2

Bed

S2

 

Таблиця 7.6 – Відношення PropertySupplier у формі 5НФ

propertyNo

suppllerNo

PG4

S1

PG4

S2

PG16

S2

 

Слід зазначити, що природне з'єднання будь-яких двох з цих трьох відношень приведе до появи фіктивних рядків, але природне з'єднання всіх трьох відношень приведе до відновлення відношення PropertyItemSupplier в початковий стан.

 

Рисунок 7.1 – Приклад залежності з'єднання: 
а) неприпустимий стан відношення PropertyItemSupplier; 
б) припустимий стан відношення PropertyItemSupplier

 

В якості альтернативи пояснення 5НФ

 

12.7.1 Знайомство з реляційною моделлю

Тема 4 Знайомство з реляційною моделлю БД

 

4.1 Коротка історії реляційної моделі

 

Реляційна модель вперше була запропонована Э.Ф.Коддом (E.F.Codd) у 1970 році в його основній статті "Реляційнамодель даних для великих спільно використовуваних банків даних". В даний час публікацію цієї статті прийнято вважатиповоротним пунктом в історії розвитку систем баз даних, хоча варто відмітити, що ще раніше була запропонована модель, заснована на множинах (Childs, 1968). Цілі створення реляційної моделі формулювалися в такий спосіб.

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

-          Створення міцного фундаменту для рішення семантичних питань, а також проблем несуперечності і надлишковості даних. Зокрема, у статті Кодда вводиться поняття нормалізованих відношень, тобто відношень без повторюваних груп.

-          Розширення мов керування даними за рахунок включення операцій над можинами.

Хоча інтерес до реляційної моделі обумовлений декількома різними причинами, усе-таки найбільш значнідослідження були проведені в рамках трьох проектів. Перший з них розроблявся наприкінці 70-х років у дослідницькійлабораторії корпорації IBM у місті Хосе, штат Каліфорнія, під керівництвом Астрахана (Astrahan), результатом якого сталостворення системи "System R", що була прототипом справжньої реляційної СКБД. Цей проект був задуманий з метоюодержати реальні докази практичності використання реляційної моделі за допомогою реалізації структур даних, щопередбачаються нею, і операцій. Цей проект також зарекомендував себе як найважливіше джерело інформації про такі проблеми реалізації, як керування паралельністю, оптимізація запитів, керування транзакціями, забезпечення безпеки і цілісності даних, технологія відновлення, врахування людського фактора і розробка інтерфейсу користувача. Виконанняпроекту стимулювало публікацію багатьох науково-дослідних статей і створення інших прототипів реляційних СКБД. Зокрема, робота над проектом System R дала поштовх проведенню таких найважливіших розробок, як:

-          створення мови структурованих запитів SQL (цю назву вимовляють або по буквах "S-Q-L", або (іноді) за допомогою мнемонічного імені "See-Quel"), що з тих пір придбав статус формального стандарту ISO (International Organization for Standardization) і в даний час є фактичним галузевим стандартом мови реляційних СКБД;

-          створення різних комерційних реляційних СКБД, що вперше з'явилися на ринку на початку 80-х років, таких як DB2 і SQL/DS корпо­рації IBM, а також ORACLE корпорації ORACLE Corporation.

Другим проектом, що зіграв помітну роль у розробці реляційної моделі даних, був проект INGRES (INteractiveGRaphics REtrieval System), робота над яким проводилася в Каліфорнійському університеті (місто Берклі) майже в той жесамий час, що і над проектом System R. Проект INGRES включав розробку прототипу РСКБД із концентрацією основноїуваги на тих же загальних цілях, що і проект System R. Ці дослідження привели до появи академічної версії INGRES, щовнесла істотний вклад у загальне визнання реляційної моделі даних. Пізніше від даного проекту виділилися комерційні продукти INGRES фірми Relational Technology Inc. (тепер CA-OpenIngres фірми Computer Associates) і Intelligent Database Machine фірми Britton Lee Inc.

Третім проектом була система Peterlee Relational Test Vehicle наукового центру корпорації IBM, розташованого в містіПетерлі, Великобританія (Todd, 1976). Цей проект буd більш теоретичним порівняно з проектами System R і INGRES. Його результати мали дуже велике і навіть принципове значення, особливо в таких областях, як обробка запитів і оптимізація, а також функціональні розширення системи.

Комерційні системи на основі реляційної моделі даних почали з'являтися наприкінці 70-х – початку 80-х років. Вданий час існує кілька сотень типів різних реляційних СКБД як для мейнфреймів, так і для мікрокомп'ютерів, хоча багато зних не цілком задовольняють точному визначенню реляційної моделі даних. Прикладами реляційних СКБД длямікрокомп'ютерів є СКБД Access і FoxPro фірми Microsoft, Paradox і Visual dBase фірми Borland та інші.

Завдяки популярності реляційної моделі багато хто нереляційні системи тепер забезпечує реляційним інтерфейсом користувача, незалежно від використовуваної базової моделі. Основна сіткова СКБД, система IDMS фірми ComputerAssociates, тепер називається IDMS/R (або IDMS/SQL) і підтримує реляційне представлення даних.

Крім того, пізніше були запропоновані деякі розширення реляційної моделі даних, призначені для найбільш повного і точного вираження змісту даних (Codd, 1979), для підтримки об’єктно-орієнтованих понять (Stonebraker and Rowe, 1986), а також для підтримки дедуктивних можливостей (Gardarin and Valduriez, 1989).

 

4.2 Термінологія

 

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

Структура реляційних даних

Відношення – це плоска таблиця, що складається зі стовпців і рядків.

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

Атрибут – це поіменований стовпець відношення.

У реляційній моделі відношення використовуються для збереження інформації про об'єкти, представлені у базі даних.Відношення має вигляд двовимірної таблиці, у якій рядки відповідають окремим записам, а стовпці – атрибутам. При цьому атрибути можуть розташовуватися в будь-якому порядку – незалежно від їх перевпорядкування відношення будезалишатися тим самим, а тому мати той же зміст.

Наприклад, інформація про відділення компанії може бути представлена відношенням Branch, що включає стовпці затрибутами Bno (Номер відділення), Street (Вулиця), Area (Район), City (Місто), Pcode (Поштовий індекс), Tel_No (Номер телефону) і Fax_No (Номер факсу). Аналогічно, інформація про працівників компанії може бути представлена відношеннямStaff (Персонал), що включає стовпці з атрибутами Sno (Особистий номер співробітника), FName (Ім'я), LName (Прізвище), Address (Адреса), Tel_No (Номер телефону), Position (Посада), Sex (Стать), DOB (Дата народження), Salary (Зарплата), NIN (Особистий номер соціального страхування) і Bno (Номер відділення, у якому даний співробітник працює).

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

Домени являють собою надзвичайно могутній компонент реляційної моделі. Кожен атрибут реляційної бази данихвизначається на деякому домені. Домени можуть відрізнятися для кожного з атрибутів, але два і більш атрибути можутьвизначатися на тому самому домені. У таблиці 4.1 представлені домени для деяких атрибутів відношень Branch і Staff. Хочау відношенні Branch є сім атрибутів, тут показані тільки шість, тому що два атрибути, Tel_No і Fax_No, визначені на томусамому домені. Зверніть увагу, що в будь-який момент часу в доменах можуть існувати значення, що не будуть реальнопредставлені значеннями відповідного атрибута.

 

Таблиця 4.1 – Домени деяких атрибутів відношень Branch і Staff

Атрибут

Ім'я домену

Вміст домену

Визначення домену

Bno

BRANCH NUMBERS

Множина усіх припустимих номерів відділень компанії

Символьний: розмір 3, діапазон 'В1'-'В99'

Street

STREET NAMES

Множина усіх назв вулиць

Символьний: розмір 25

Area

AREA_NAMES

Множина усіх найменувань районів/областей

Символьний: розмір 20

City

CITY_CODES

Множина усіх назв міст

Символьний: розмір 15

Pcode

POST_CODES

Множина усіх поштових кодів

Символьний: розмір 8

Tel_No

TELFAX_NUMBERS

Множина усіх номерів телефонів і факсів

Символьний: розмір 13

Fax_No

TELFAX_NUMBERS

Множина усіх номерів телефонів і факсів

Символьний: розмір 13

Sex

SEX

Позначення статі людини

Символьний: розмір 1, значення 'М' або 'F'

DOB

DATES_OF_BIRTH

Усі можливі значення дати народження працівника компанії

Дата, діапазон від 1-Jan-20, формат dd-mоnth-yy

Salary

SALARIES

Усі можливі значення річної заробітної плати працівника компанії

Грошовий; 7 цифр, діапазон 6000,00-40000,00 грн.

 

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

Кортеж – це рядок відношення.

Елементами відношень є кортежі, або рядки, таблиці. Кортежі можуть розташовуватися в будь-якому порядку, при цьому відношення буде залишатися тим же самим, а отже, і мати той же зміст.

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

Ступінь – визначається кількістю атрибутів, які воно містить.

Відношення тільки з одним атрибутом має ступінь 1 і називається унарним (unary) відношенням (або 1-арнымкортежем). Відношення з двома атрибутами називається бінарним (binary), відношення з трьома атрибутами – тернарним(ternary), а для відношень з великою кількістю атрибутів використовується термін n-арний (n-ary). Визначення ступеня відношення є частиною заголовка відношення.

Кардинальність – це кількість кортежів, які містить відношення.

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

Реляційна база даних – набір нормалізованих відношень.

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

Альтернативна термінологія.

Термінологія, використовувана в реляційній моделі, часом може привести до плутанини, оскільки крімзапропонованих двох наборів термінів існує ще один – третій. Відношення в ньому називається файлом (file), кортежі –записами (records), а атрибути – полями (fields). Ця термінологія заснована на тому факті, що фізично реляційна СКБДможе зберігати кожне відношення в окремому файлі. У таблиці 4.2 показані відповідності, що існують між трьома згаданими вище групами термінів.

 

Таблиця 4.2 – Альтернативні варіанти термінів у реляційній моделі

Офіційні терміни

Альтернативний варіант 1

Альтернативний варіант 2

Відношення

Таблиця

Файл

Кортеж

Рядок

Запис

Атрибут

Стовпець

Поле

 

4.3 Структура реляційних даних

 

4.3.1 Математичні відношення

Для розуміння щирого змісту терміну відношення розглянемо кілька математичних понять. Допустимо, у нас є двімножини, D1 і D2 , де D1={2,4} і D2={1,3,5}. Декартовим добутком цих двох множин (позначається як D1xD2) називаєтьсянабір із усіх можливих пар, у яких першим йде елемент множини D1, а другим – елемент множини D2. Альтернативний спосіб вираження цього добутку полягає в пошуку всіх комбінацій елементів, у яких першим йде елемент множини D1, адругим – елемент множини D2. У даному прикладі одержимо наступний результат: D1xD2 = {(2,l),(2,3),(2,5),(4,l),(4,3),(4,5)}

Будь-яка підмножина цього декартового добутку є відношенням. Наприклад, у ньому можна виділити відношення R,де R = {(2,1), (4,1)}.

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

 

                              (4.1)

 

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

 

                                (4.2)

 

У даному прикладі тільки одна можлива пара даного декартового добутку відповідає цій умові: S = {(2,1)}

Поняття відношення можна легко поширити і на три множини. Нехай маємо три множини: D1D2 і D3. Декартівдобуток D1х D2х D3 цих трьох множин є набором, що складається з усіх можливих трійок елементів, у яких першим йдеелемент множини Dl, другим – елемент множини D2, а третім – елемент множини D3. Будь-яка підмножина цьогодекартового добутку є відношенням. Розглянемо наступний приклад трьох множин і обчислимо їхній декартів добуток:

D1 = {(1,3)};         D2 = {(2,4)};         D3 = {(5,6)};

D1xD2xD3 = {(1,2,5),(1,2,6),(1,4,5),(1,4,6),(3,2,5),(3,2,6), (3,4,5), (3,4,6)}.

Будь-яка підмножина з приведених вище трійок елементів є відношенням. Збільшуючи кількість множин, можна датиузагальнене визначення відношення на п доменах. Нехай є п множин Dl, D2, ..., Dn. Декартів добуток для цих п множинможна визначити в такий спосіб:

D1xD2x...xDn =  Звичайно цей вираз записують у такому символічному виді:

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

 

4.3.2 Відношення в базі даних

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

Реляційна схема – ім'я відношення, за яким іде множина пар імен атрибутів і доменів.

Наприклад, для атрибутів А1А2, ..., Аn з доменами D1D2, ..., Dn реляційною схемою буде множина{A1:d1,A2:d2,...,An:dn}. Відношення R, задане реляційною схемою S, є множиною відображень імен атрибутів на відповідні їмдомени. Таким чином, відношення R є множиною таких n-арних кортежів {A1:d1,A2:d2,...,An:dn}, де .

Кожен елемент n-арного кортежу складається з атрибута і значення цього атрибута. Звичайно при записі відношення увиді таблиці імена атрибутів перераховуються в заголовках стовпців, а кортежі утворять рядки формату (dl,d2,... ,dn), декожне значення береться з відповідного домену. Таким чином, у реляційній моделі відношення можна представити якдовільну підмножину декартового добутку доменів атрибутів, тоді як таблиця - це усього лише фізичне представленнятакого відношення.

Наприклад, відношення Branch (відділення компанії) має атрибути Bno (номер), Street (вулиця), Area (район), City (місто), Pcode (поштовий код), Tel_No (номер телефону) і Fax_No (номер факсу) з відповідними їм доменами. ВідношенняBranch являє собою довільну підмножину декартового добутку доменів або довільну множину 7-арних кортежів, у якихпершим йде елемент із домену BRANCH_NUMBER, другим – елемент із домену STREET_NAME і т.д. Наприклад, один з 7-арних кортежів може мати такий вид:

{(В5,22 Deer Rd, Sidcup, London, SW1 4EH, 0171-886-1212, 0171-886-1214)}.

Цей же кортеж можна записати в більш коректній формі:

{(Bno:  'B5', Street:  '22 Deer Rd', Area:  'Sidcup', City:  'London', Pcode:   'SW1 4EH', Tel_No:   '0171-886-1212', Fax_No:   '0171-886-1214')}.

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

 

4.3.3 Властивості відношень

Відношення має наступні характеристики.

-       Відношення має ім'я, що відрізняється від імен всіх інших відношень.

-       Кожна клітинка відношення містить тільки атомарне (неподільне) значення.

-       Кожен атрибут має унікальне ім'я.

-       Значення атрибута беруться з того самого домену.

-       Порядок проходження атрибутів не має ніякого значення.

-       Кожен кортеж є унікальним, тобто дублікатів кортежів бути не може.

-       Теоретично порядок проходження кортежів у відношенні не має ніякого значення. (Однак, практично цей порядок може істотно вплинути на ефективність доступу до них.)

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

Імена стовпців, зазначені в їхньому верхньому рядку, відповідають іменам атрибутів відношення. Значення атрибутаBno беруться з домену BRANCH_NUMBERS – не допускається розміщення в цьому стовпці інших значень, наприкладпоштового індексу. Стовпці можна міняти місцями за умови, що ім'я атрибута переміщається разом з його значеннями. Таблиця усе ще буде представляти те ж відношення, якщо атрибут Tel_No розташувати в ній перед атрибутом Pcode, хоча для кращої читабельності розумніше було б розташовувати окремі частини адреси поблизу.

Відношення не може містити кортежів-дублікатів. Наприклад, рядок ('В5', '22 Deer Rd', 'Sidcup', 'London', 'SW14EH', '0171-886-1212', '0171-886-1214') може бути представлений у відношенні тільки один раз. При необхідності рядки можна змінювати місцями довільним чином (наприклад, перемістити рядок відділення 'В5' на місце рядка відділення 'В4'), самевідношення при цьому залишиться незмінним.

Велика частина властивостей відношень походить від властивостей математичних відношень.

-       Оскільки відношення є множиною, то порядок елементів не має значення. Отже, порядок кортежів у відношенні несуттєвий.

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

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

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

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

 

4.3.4 Реляційні ключі

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

Суперключ – атрибут або множина атрибутівів, що єдиним чином (superkey) ідентифікує кортеж даного відношення.

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

Потенційний ключ – суперключ,  що  не  містить  підмножини, яка також  є суперключем даного відношення.

Потенційний ключ К для даного відношення R володіє двома властивостями.

-       Унікальність. У кожному кортежі відношення R значення ключа К єдиним чином ідентифікують цей кортеж.

-       Неприводимість. Ніяка припустима підмножина ключа К не володіє властивістю унікальності.

Відношення може мати кілька потенційних ключів. Якщо ключ складається з декількох атрибутів, то він називаєтьсяскладеним ключем. Розглянемо відношення Branch. Конкретне значення атрибута City може визначати відразу кілька відділень компанії (наприклад, у Лондоні знаходяться два відділення). Тому даний атрибут не може бути обраний як потенційний ключ. З іншого боку, оскільки для кожного відділення компанії задається його унікальний номер, кожне значення цього номера (атрибут Bno) може визначати не більше одного кортежуа тому Bno є потенційним ключем. Аналогічно, атрибути Tel_No і Fax_No також є потенційними ключами цього відношення.

Тепер розглянемо відношення Viewing (Огляд), що містить інформацію про ознайомлювальні огляди об'єктів нерухомості потенційними орендарями. Це відношення включає атрибути номера орендаря (Rno), номера об'єкта нерухомості (Pno), дати перегляду (Date) і, можливо, коментарі (Comments). По заданому номеру орендаря Rno можна вибрати дані про декілька оглядів різних об'єктів нерухомості. Аналогічно, по заданому номеру об'єкта нерухомості Pnoможна вибрати дані про декілька орендарів, що оглядали цей об'єкт нерухомості. Отже, сам по собі номер орендаря Rno абономер об'єкту нерухомості Pno не може бути використаний як потенційний ключ. Однак комбінація атрибутів Rno і Pnoідентифікує не більш одного кортежу. Якщо допустити можливість того, що орендар може оглядати той самий об'єкт кількаразів, то до даного складеного ключа буде потрібно додати дату (Date). Однак у даному прикладі передбачається, що цього не потрібно.

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

Первинний ключ – це потенційний ключ, що обраний для унікальної ідентифікації кортежів всередині відношення.

Оскільки відношення не містить кортежів-дублікатів, завжди можна унікальним чином ідентифікувати кожен його рядок. Це значить, що відношення завжди має первинний ключ. У гіршому випадку вся множина атрибутів може використовуватися як первинний ключ, але звичайно, щоб розрізнити кортежі, варто використовувати трохи меншупідмножину атрибутів. Потенційні ключі, що не обрані як первинний ключ, називаються альтернативними ключами. Якщо у відношенні Branch вибрати як первинний ключ атрибут Bno, то альтернативними ключами цього відношення будуть атрибути Tel_No і Fax_No. У відношенні Viewing є тільки один потенційний ключ, що складається з атрибутів Rno і Pno, тому дане сполучення атрибутів автоматично утворить його первинний ключ.

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

Якщо якийсь атрибут присутній у декількох відношеннях, то його наявність звичайно відображає визначений зв'язок між кортежами цих відношень. Наприклад, атрибут Bno навмисно включений у відношення Branch і Staff для встановлення зв'язку між відомостями про відділення компанії і відомостями про співробітників, що працюють у кожному з відділень. Увідношенні Branch атрибут Bno є первинним ключем, а у відношенні Staff він введений для встановлення відповідності міжданими про співробітників і відомостями про ті відділення компанії, у яких вони працюють. У відношенні Staff атрибут Bnoє зовнішнім ключем. У такому випадку говорять, що атрибут Bno у відношенні Staff посилається на первинний ключ, тобто на атрибут Bno, у базовому відношенні Branch. Ці загальні атрибути відіграють важливу роль у маніпулюванні даними.

 

4.3.5 Представлення схем у реляційній базі даних

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

Branch

(Bno, Street, Area, City, Pcode, Tel_No, Fax_No)

Staff

(Sno, FName, LName, Address, Tel_No, Position, Sex, DOB, Salary, NIN, Bno)

Property_ for_Rent

(Pno, Street, Area, City, Pcode, Type, Rooms, Rent, Ono, Sno, Bno)

Renter

(Rno, FName, LName, Address, Tel_No, PrefJType, Max_Rent, Bno)

Owner

(Ono, FName, LName, Address, Tel_No)

Viewing

(Rno, Pno, Date, Comment)

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

Концептуальною моделлюабо концептуальною схемоюназивається множина всіх реляційних схем бази даних. У табл. 3.3-3.8 показано деякий можливий стан бази даних про оренду нерухомості.

 

Таблиця 4.3 – Приклад деякого поточного стану бази даних про оренду нерухомості. Таблиця Branch

Bno

Street

Area

City

Pcode

Tel_No

Fax_No

B5

22 Deer Rd

Sidcup

London

SW1 4EH

0171-886-1212

0171-886-1214

B7

16 Argyll St

Dyce

Aberdeen

AB2 3SU

01224-67125

01224-67111

ВЗ

163 Main St

Partick

Glasgow

G11 9QX

0141-339-2178

0141-339-4439

B4

32 Manse Rd

Leigh

Bristol

BS99 1NZ

0117-916-1170

0117-776-1114

B2

56 Clover Dr

 

London

NW10 6EU

0181-963-1030

0181-453-7992

 

Таблиця 4.4 – Приклад деякого поточного стану бази даних про оренду нерухомості. Таблиця Staff

Sno

FName

LName

Address

Tel_No

Position

Sex

DOB

Salary

NIN

Bno

SL21

John

White

19 Taylor st,

Cranford, London

0171-884-5112

Manager

M

1-Oct-45

30000

WK4 4201 1B

B5

SG37

Ann

Beech

81 George st,

7Glasgow PA1 2JR

0141-848-3345

Snr Asst

F

10-Nov-60

12000

WL43 2514 С

B3

SG14

David

Ford

63 Ashby St, Partick, Glasgow G11

0141-339-2177

Deputy

M

24-Mar-58

18000

WL22 0658 D

B3

SA9

Mary

Howe

2 Elm PI, Aberdeen AB2 3SU

 

Assistant

F

19-Feb-70

9000

WM5 3218 7D

B7

SG5

Susan

Brand

5 Gt Western Rd Glasgow G12

0141-334-2001

Manager

F

3-Jun-40

24000

WK5 8893 2E

B3

SL41

Julie

Lee

28 Malvern St, Kilburn NW2

0181-554-3541

Assistant

F

13-Jun-65

9000

WA29 0573 ДО

B5

 

Таблиця 4.5 – Приклад деякого поточного стану бази даних про оренду нерухомості. Таблиця PropertyforRent

Pno

Sreet

Area

City

Pcode

Type

Rooms

Rent

Ono

Sno

Bno

PA14

16 Holhead

Dee

Aberdeen

AB7 5SU

House

6

650

CO46

SA9

B7

PL94

6 Argyll St

Kilburn

London

NW2

Flat

4

400

CO87

SL41

B5

PG4

6 Lawrence St

Partick

Glasgow

G11 9QX

Flat

3

350

CO40

SG14

B3

PG36

2 Manor Rd

 

Glasgow

G32 4QX

Rat

3

375

CO93

SG37

B3

PG21

18 Dale Rd

Hyn-dland

Glasgow

G12

House

5

600

CO87

SG37

B3

PG16

5 Novar Dr

Hyn-dland

Glasgow

G12 9AX

Flat

4

450

CO93

SG14

B3

 

Таблиця 4.6 – Приклад деякого поточного стану бази даних про оренду нерухомості. Таблиця Renter

Rno

FName

LName

Address

Tel_No

Preptype

Max_Rent

Bno

CR76

John

Kay

56 Hight St, Putney, London SW1 4EH

0171-774-5632

Flat

425

B5

CR56

Aline

Stewart

64 Fern Dr, Pollock, Glasgow G42 OBL

0141-848-1825

Flat

350

B3

CR74

Mike

Ritchie

18 Tain St, Gourock PA1G 1YQ

01475-392178

House

750

B3

CR62

Mary

Tregear

5 Tarbot Rd, Kildary, Aberdeen AB9 3ST

01224-196720

Rat

600

B7

 

Таблиця 4.7 – Приклад деякого поточного стану бази даних про оренду нерухомості. Таблиця Owner

Ono

FName

LName

Address

Tel_No

З46

Joe

Keogh

2 Fergus Dr, Banchory, Aberdeen AB2 &SX

01224-861212

З87

Carol

Farrel

6 Achray St, Glasgow G32 9DX

0141-357-7419

З040

Tina

Murphy

63 Well St, Shawlands, Glasgow G42

0141-943-1728

З93

Tony

Shaw

12 Park PI, Hillhead, Glasgow G4 OQR

0141-225-7025

 

Таблиця 4.8 – Приклад деякого поточного стану бази даних про оренду нерухомості. Таблиця Viewing

Rno

Pno

Date

Comment

CR56

PA14

24-May-98

Too small (Занадто мала)

CR76

PG4

20-Apr-98

Too remote (Занадто далеко)

CR56

PG4

26-May-98

 

CR62

PA14

14-May-98

No Dining room (Немає окремої їдальні)

CR56

PG36

28-Apr-98

 

 

4.4 Реляційна цілісність

 

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

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

Значення NULL – вказує, що значення атрибута в даний момент невідоме або неприйнятне для цього кортежу.

Значення NULL варто сприймати як логічну величину "невідомо". Іншими словами, або це значення не входить вобласть визначення деякого кортежу, або ніяке значення ще не задане. Ключове слово NULL являє собою спосіб обробки неповних або незвичайних даних. Однак визначник NULL не слід розуміти як нульове числове значення або заповненийпробілами текстовий рядок. Нулі і пробіли являють собою деякі значення, тоді як ключове слово NULL покликане позначати відсутність якого-небудь значення. Отже, визначник NULL варто розглядати інакше, не так, як інші значення. Деякі автори використовують термін "значення NULL", але насправді визначник NULL не є значенням, а лише позначає його відсутність, а тому термін "значення NULL" використовувати не рекомендується.

Наприклад, у представленому в таблиці 4.8 відношенні Viewing атрибут Comment може не мати визначеного значення доти, поки потенційний орендар не відвідає даний об'єкт нерухомості і не повідомить свою думку агентству. У протилежному випадку для представлення цього стану без використання ключового слова NULL буде потрібно або ввестиякісь помилкові дані, або створити додаткові атрибути, що можуть бути безглуздими для користувачів. У даному прикладі можна спробувати представити відсутній коментар за допомогою значення -1. Крім того, можна додати у відношенняViewing ще один атрибут – " чи є коментар?" – зі значенням Y (Yes), якщо коментар є, і N (No) – у протилежному випадку. Однак ці обидва підходи можуть заплутати користувача.

Застосування значення NULL може викликати проблеми на етапі реалізації. Труднощі виникають через те, щореляційна модель базується на обчисленні предикатів першого порядку, які володіють двозначною, або булевою, логікою,тобто припустимими є тільки два значення: істина і фальш. Застосування визначника NULL означає, що доведеться вестироботу з логікою більш високого порядку, наприклад тризначною або навіть чотиризначною (Codd, 1986, 1987, 1990).

Використання поняття NULL у реляційній моделі є спірним питанням. Кодд (1990) розглядає поняття NULL якскладову частину цієї моделі, а інші фахівці вважають цей підхід неправильним, вважаючи, що проблема відсутньоїінформації ще не до кінця зрозуміла, задовільне її рішення не знайдене, а тому включення визначника NULL у реляційнумодель є передчасним (Date, 1995). Слід зазначити, що не у всіх реляційних системах підтримується робота з визначникомNULL.

Тепер можна приступати до вивчення реляційних обмежень цілісності.

Цілісність сутностей.

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

Цілісність сутностей – у базовому відношенні жоден атрибут первинного ключа не може містити відсутніх значень,що позначаються визначником NULL.

За визначенням, первинний ключ – це мінімальний ідентифікатор, що використовується для унікальної ідентифікації кортежів. Це значить, що ніяка підмножина первинного ключа не може бути достатньою для унікальної ідентифікації кортежів. Якщо допустити присутність визначника NULL у будь-якій частині первинного ключа, це рівноціннотвердженню, що не всі його атрибути необхідні для унікальної ідентифікації кортежів, що суперечить визначенню первинного ключа. Наприклад, оскільки Bno є первинним ключем відношення Branch, те не можна допустити вставку увідношення Branch кортежу з визначником NULL в атрибуті Bno.

Якщо розглянути це правило більш уважно, то можна помітити його незвичайні властивості. По-перше, чому воно застосовується до первинних ключів, але не використовується стосовно альтернативних ключів? По-друге, чому воно обмежується тільки базовими відношеннями? Наприклад, використовуючи дані відношення Staff (див. табл. 4.4),розглянемо виконання наступного запиту: "Створити список номерів телефонів усіх співробітників організації".Результатом цього запиту є унарне відношення з єдиного атрибута Tel_No. За визначенням, цей атрибут повинен бути первинним ключем, але серед його значень міститься визначник NULL (відповідний номерові телефону співробітника зособистим номером 'SA9'). Оскільки це відношення не є базовим, реляційна модель допускає присутність визначника NULLу його первинному ключі.

Цілісність посилань.

Друге обмеження цілісності стосується зовнішніх ключів.

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

Наприклад, атрибут Bno у відношенні Staff є зовнішнім ключем, що посилається на атрибут Bno базового відношенняBranch. Система повинна запобігати будь-якій спробі створити запис з інформацією про співробітника відділення з номером 'В25'' доти, поки у відношенні Branch не буде створений запис, що містять відомості про відділення компанії з номером 'В25'. Однак вважається припустимим створення запису з інформацією про нового співробітника з вказанням визначника NULL замість номера відділення, у якому цей співробітник працює. Така ситуація може мати місце в тому випадку, колиспівробітник зарахований у штат компанії, але ще не приписаний до якогось конкретного відділення.

Корпоративні обмеження цілісності.

Корпоративні обмеження цілісності – додаткові правила підтримки цілісності даних, обумовлені користувачами абоадміністраторами бази даних.

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

 

12.7.2 Реляційна алгебра

Тема 5 Реляційні оператори

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

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

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

 

5.1 Реляційна алгебра

 

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

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

Існує декілька варіантів вибору операцій, які включаються в реляційну алгебру. Спочатку Кодд запропонував вісім операцій, але згодом до них були додані і деякі інші. П'ять основних операцій реляційної алгебри, а саме вибірка (selection), проекція (projection), декартовий добуток (cartesian product), об'єднання (union) і різниця множин (set difference), виконують більшість дій з вибірки даних, які можуть представляти для нас інтерес. На підставі п'яти основних операцій можна також вивести додаткові операції, такі як операції з'єднання (join), перетину (intersection) і ділення (division), які можуть бути виражені в термінах п'яти основних операцій.

Операції вибірки і проекції є унарними, оскільки вони працюють з одним відношенням. Інші операції працюють з парами відношень, і тому їх називають бінарними операціями. У приведених нижче визначеннях R і S – це два відношення, визначені на атрибутах A={a1,a2,…,an} і  відповідно.

 

5.1.1 Унарні операції реляційної алгебри

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

Вибірка . Операція вибірки застосовується до одного відношення R і визначає результуюче відношення, яке містить лише ті кортежі (рядки) з відношення R, які задовольняють заданій умові (предикату) (рисунок 5.1).

 

Рисунок 5.1 – Графічне зображення операції вибірки

 

Приклад операції вибірки: скласти список всіх співробітників із зарплатою, що перевищує 10000 гривень (5.1).

 

.                                                        (5.1)

 

Тут вихідним відношенням є відношення staff[1], а предикатом – вираз salary>10000. Операція вибірки визначає новевідношення, що містить лише ті кортежі відношення staff, в яких значення атрибуту salary перевищує 10000 гривень. Результат виконання цієї операції показаний в таблиці 5.1. Складніші предикати можуть бути створені за допомогою логічних операцій І (AND), АБО (OR) та НІ (NOT).

 

Таблиця 5.1 – Результат виконання операції вибірки з відношення Staff кортежів з атрибутом salary > 10000

staffNo

fName

IName

position

sex

DOB

salary

branchNo

SL21

John

White

Manager

M

01-Oct-45

30000

B005

SG37

Ann

Beech

Assistant

F

10-Nov-60

12000

B003

SG14

David

Ford

Supervisor

M

24-Mar-58

18000

B003

SG5

Susan

Brand

Manager

F

03-Jun-40

24000

B003

 

Проекція . Операція проекції застосовується до одного відношення R і визначає нове відношення, що містить вертикальну підмножину відношення, створеного за допомогою вибірки значень вказаних атрибутів і виключення з результату рядків-дублікатів (рисунок 5.2).

 

Рисунок 5.2 – Графічне зображення операції проекції

 

Приклад операції проекції: створити відомість зарплати всіх співробітників компанії з вказанням лише атрибутівstaffNo, fName, lName і salary (5.2).

 

.                                        (5.2)

 

В даному прикладі операція проекції визначає нове відношення, яке міститиме лише атрибути staffNo, fName, lName іsalary відношення Staff, розміщені у вказаному порядку. Результат виконання цієї операції показаний в таблиці 5.2.

 

Таблиця 5.2 – Проекція відношення Staff по атрибутах staffNo, fName, lName і salary

staffNo

fName

lName

salary

SL21

John

White

30000

SG37

Ann

Beech

12000

SG14

David

Ford

18000

SA9

Mary

Howe

9000

SG5

Susan

Brand

24000

SL41

Julie

Lee

9000

 

5.1.2 Операції з множинами

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

Об'єднання . Об'єднання двох відношень R і S визначає нове відношення, яке: включає всі кортежі, що містяться лише в R, лише в S, одночасно в R і S, причому всі дублікати кортежів виключені (рисунок 5.3 а). При цьому відношення R іS мають бути сумісними по об'єднанню.

Якщо R і S включають, відповідно, I та J кортежів, то об'єднання цих відношень можна отримати, зібравши всі кортежі в одне відношення, яке може містити не більше за (I + J) кортежів. Об'єднання можливе лише якщо схеми двох відношень збігаються, тобто складаються з однакової кількості атрибутів, причому кожна пара відповідних атрибутів має однаковий домен. Інакше кажучи, відношення мають бути сумісними по об'єднанню. Відзначимо, що у визначенні сумісності по об'єднанню не вказано, що атрибути повинні мати однакові імена. В деяких випадках для здобуття двох сумісних по об'єднанню відношень може бути використана операція проекції.

 

Рисунок 5.3 – Операції над множинами:

а – об’єднання; б – перетин; в – різниця.

 

Приклад операція об'єднання: створити список всіх міст, в яких є відділення компанії або об'єкт нерухомості (5.3).

 

.                            (5.3)

 

Для створення сумісних по об'єднанню відношень спочатку слід застосувати операцію проекції, аби виділити із відношень Branch і PropertyForRent стовпці з атрибутами city, виключаючи у разі потреби дублікати. Потім для комбінування отриманих проміжних відношень слід використовувати операцію об'єднання. Результат виконання всіх цих дій приведений в таблиці 5.3.

 

Таблиця 5.3 – Об'єднання, засноване на атрибуті city відношень Branch і PropertyForRent

city

London

Aberdeen

Glasgow

Bristol

 

Перетин . Операція перетину визначає відношення, яке містить кортежі, присутні як у відношенні R, так і у відношенні S (рисунок 5.3 б). Відношення R і S повинні бути сумісними по об'єднанню.

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

 

.                            (5.4)

 

Як і в попередньому прикладі, слід створити сумісні по об'єднанню відношення Branch і PropertyForRent, виконавши їх проекцію по атрибуту city. Потім для комбінування отриманих нових відношень слід використовувати операцію перетину. Результат виконання цих операцій показаний в таблиці 5.4.

 

Таблиця 5.4 – Перетин, створений на атрибуті city відношень Branch і PropertyForRent

city

Aberdeen

London

Glasgow

 

Перетин можна сформулювати і на основі операції різниці множин: . Розглянемо цю операцію – різницю.

Різниця двох відношень R і S складається з кортежів, які є у R, але відсутні у відношенні S (рисунок 5.3 в). Причому відношення R і S повинні бути сумісними по об'єднанню.

Приклад операції різниці: створити список всіх міст, в яких є відділення компанії, але немає об'єктів нерухомості, що здаються в оренду (5.5).

 

.                   (5.5)

 

В даному випадку аналогічно попередньому прикладу слід створити сумісні по об'єднанню відношення Branch іPropertyForRent, виконавши їх проекцію по атрибуту city. Потім для комбінування отриманих нових відношень слід використовувати операцію різниці. Результат виконання цих операцій показаний в таблиці 5.5.

 

Таблиця 5.5 – Різниця, заснована на атрибуті city відношень Branch і PropertyForRent

city

Bristol

 

5.1.3 Декартів добуток та опреації з’єднання

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

 

Рисунок 5.4 – Декартовий добуток відношень

 

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

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

Імена орендарів зберігаються і відношенні Client, а відомості про виконані ними огляди – у Viewing. Аби отримати список орендарів і коментарі про оглянуту ними нерухомість, необхідно об'єднати ці два відношення (5.6):

 

.      (5.6)

 

Результати виконання цієї операції показані в таблиці 5.6. У такому вигляді це відношення містить більше інформації, ніж потрібно. Наприклад, перший кортеж цього відношення містить різні значення атрибуту clientNo. Для отримання шуканого списку необхідно для цього відношення провести операцію вибірки з отриманням тих кортежів, для яких виконується рівність Client.clientNo=Viewing.clientNo. Повністю ця операція виглядає так, як показано нижче (5.7).

 

     (5.7)

 

Результат виконання цієї операції показаний в таблиці 5.7. Як ми незабаром побачимо, комбінація декартовогодобутку і вибірки може бути зведена до однієї операції з'єднання.

 

Таблиця 5.6 – Декартовий добуток скороченого варіанту відношень Client і Viewing (використані лише деякі атрибути)

Client.

clientNo

fName

lName

Viewing.clientNo

propertyNo

comment

CR76

John

Kay

CR56

PA14

Too small (Дуже мала)

CR76

John

Kay

CR76

PG4

Too remote (Дуже далеко)

CR76

John

Kay

CR56

PG4

 

CR76

John

Kay

CR62

PA14

No Dining room (Немає окремої їдальні)

CR76

John

Kay

CR56

PG36

 

CR56

Aline

Stewart

CR56

PA14

Too small (Дуже мала)

CR56

Aline

Stewart

CR76

PG4

Too remote (Дуже далеко)

CR56

Aline

Stewart

CR56

PG4

 

CR56

Aline

Stewart

CR62

PA14

No Dining room (Немає окремої їдальні)

CR56

Aline

Stewart

CR56

PG36

 

CR74

Mike

Ritchie

CR56

PA14

Too small (Дуже мала)

CR74

Mike

Ritchie

CR76

PG4

Too remote (Дуже далеко)

CR74

Mike

Ritchie

CR56

PG4

 

CR74

Mike

Ritchie

CR62

PA14

No Dining room (Немає окремої їдальні)

CR74

Mike

Ritchie

CR56

PG36

 

CR62

Mary

Tregear

CR56

PA14

Too small (Дуже мала)

CR62

Mary

Tregear

CR76

PG4

Too remote (Слішкомдалеко)

CR62

Mary

Tregear

CR56

PG4

 

CR62

Mary

Tregear

CR62

PA14

No Dining room (Немає окремої їдальні)

CR62

Mary

Tregear

CR56

PG36

 

 

Таблиця 5.7 – Обмежений декартовий добуток скороченого варіанту відношень Client і Viewing (використані лише деякі атрибути)

Client.

clientNo

fName

lName

Viewing.

clientNo

propertyNo

comment

CR76

John

Kay

CR76

PG4

Too remote

CR56

Aline

Stewart

CR56

PA14

Too small (Дуже мала)

CR56

Aline

Stewart

CR56

PG4

 

CR56

Aline

Stewart

CR56

PG36

 

CR62

Mary

Tregear

CR62

PA14

No dining room (Немає окремої їдальні)

 

Декомпозиція складних операцій.

Операції реляційної алгебри можуть зрештою стати надзвичайно складними. Для спрощення такі операції можна розбити на ряд менших операцій реляційної алгебри і присвоїти імена результатам проміжних виразів. Для присвоєння імен результатам операції реляційної алгебри використовується операція присвоєння, позначена стрілкою вліво (ß). В даному випадку результат виразу праворуч від знаку операції ß присвоюється виразу, що знаходиться зліва від знаку операції. Зокрема, в попередньому прикладі виконувані операції можна представити таким чином (5.8):

 

 (5.8)

 

Операції з'єднання.

Як правило, користувачів цікавить лише деяка частина всіх комбінацій кортежів декартового добутку, яка задовольняє заданій умові. Тому замість декартового добутку зазвичай використовується одна з найважливіших операцій реляційної алгебри – операція з'єднання. В результаті її виконання на базі двох вихідних відношень створюється нове. Операція з'єднання є похідною від операції декартового добутку, оскільки вона еквівалентна операції вибірки з декартового добутку двох операндів-відношень тих кортежів, які задовольняють умові, вказаній в предикаті з'єднання як формула вибірки. З точки зору ефективної реалізації в реляційних СКБД ця операція є однією з найскладніших і часто виявляється однією з основних причин, що викликають проблеми з продуктивністю, властиві всім реляційним системам.

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

-       Тета-з’єднання (theta join).

-       З'єднання по еквівалентності (equi join), яке є частковим випадком тета-з’єднання.

-       Природне з'єднання (natural join).

-       Зовнішнє з'єднання (outer join).

-       Напівз'єднання (semijoin).

Тета-з’єднання . Операція тета-з’єднання визначає відношення. яке містить кортежі з декартового добутку відношень R і S, що задовольняють предикату F. Предикат F має вигляд , де замість Θ може бути вказана одна з операцій порівняння (<, <=, >, >=, = чи ~=).

Позначення тета-з’єднання можна переписати на основі базових операцій вибірки і декартового добутку, як показано нижче (5.9).

 

                                              (5.9)

 

Так само як і у випадку з декартовим добутком, ступенем тета-з’єднання називається сума ступенів операндів-відношень R і S. Якщо предикат F містить лише операцію порівняння на рівність (=), то з'єднання називається з'єднанням по еквівалентності (equi join). Ще раз звернемося до запиту, який розглядався вище в прикладі декартового добутку.

Приклад операції з'єднання по еквівалентності: створити список всіх орендарів, які оглядали об'єкт нерухомості, з вказанням їх імен і зроблених ними коментарів.

Раніше для отримання цього списку використовувалися операції декартового добуту і вибірки. Проте той же самий результат можна отримати за допомогою операції з'єднання по еквівалентності (5.10, 5.11).

 

     (5.10)

 

або

 

                  (5.11)

 

Результат цих операцій показаний в таблиці 5.7.

Природне з'єднання . Природним з'єднанням називається з'єднання по еквівалентності двох відношень R і S, виконане по всіх загальних атрибутах х, з результатів якого виключається по одному екземпляру кожного спільного атрибуту.

Ступенем природного з'єднання називається сума ступенів операндів-відношень R і S за вирахуванням кількості атрибутів х.

Приклад операції природного з'єднання: створити список всіх орендарів, які оглядали об'єкти нерухомості, з вказівкою їх імен і зроблених ними коментарів.

У прикладі для ілюстрації з’єднання по еквівалентності для складання цього списку використовувалося з'єднання по еквівалентності, але у ньому були присутні два атрибути clientNo. Для видалення одного з цих атрибутів можна скористатися операцією природного з'єднання.

 

            (5.12)

 

Результат цих операцій показаний в таблиці 5.8.

 

Таблиця 5.8 – Природне з'єднання скороченого варіанту відношень Client і Viewing (використані лише деякі атрибути)

clientNo

fName

IName

propertyNo

comment

CR76

John

Kay

PG4

Too remote (Дуже далеко)

CR56

Aline

Stewart

PA14

Too small (Дуже мала)

CR56

Aline

Stewart

PG4

 

CR56

Aline

Stewart

PG36

 

CR62

Mary

Tregear

PA 14

No dining room (Немає окремої їдальні)

 

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

Лівим зовнішнім з'єднанням називається з'єднання, при якому в результуюче відношення включаються також кортежі відношення R, котрі не мають співпадаючих значень в спільни стовпцях відношення S.

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

Приклад лівого зовнішнього з'єднання: створити звіт про хід проведення оглядів об'єктів нерухомості.

В даному випадку необхідно створити відношення, що складається як з переліку оглянутих клієнтами об'єктів нерухомості (з приведенням їх коментарів із цього приводу), так і переліку об'єктів нерухомості, які ще не оглядалися. Це можна зробити за допомогою наступного зовнішнього з'єднання (5.13).

 

                      (5.13)

 

Результат цієї операції показаний в таблиці 5.9.

 

Таблиця 5.9 – Ліве зовнішнє з'єднання відношень PropertyForRent і Viewing

propertyNo

street

city

clientNo

viewDate

comment

PA14

16 Holhead

Aberdeen

CR56

24-May-01

Too small (Дуже мала)

PA14

16 Holhead

Aberdeen

CR62

14-May-01

No dining room (Немає окремої їдальні)

PL94

6 Argyll St

London

NULL

NULL

NULL

PG4

6 Lawrence St

Glasgow

CR76

20-Apr-01

Too remote (Дуже далеко)

PG4

6 Lawrence St

Glasgow

CR56

26-May-01

 

PG36

2 Manor Rd

Glasgow

CR56

28-Apr-01

 

PG21

18 Dale Rd

Glasgow

NULL

NULL

NULL

PG16

5 Novar Dr

Giasgow

NULL

NULL

NULL

 

В цьому прикладі показано ліве зовнішнє з'єднання, оскільки в результуючому відношенні містяться всі кортежі лівого відношення. Існує також праве зовнішнє з'єднання, назване так тому, що в результуючому відношенні містяться всі кортежі правого відношення. Крім того, існує і повне зовнішнє з'єднання, в результуюче відношення якого поміщаються всі кортежі з обох відношень і в якому для позначення неспівпадаючих значень кортежів використовуються значення NULL.

Напівз'єднання . Операція напівз'єднання визначає відношення, що містить ті кортежі відношення R, які входять в з'єднання відношень R і S.

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

 

                                           (5.14)

 

Тут А – це набір всіх атрибутів відношення R. Насправді це – тета-напівз’єднання, причому слід зазначити, що існують також напівз'єднання по еквівалентності і природні напівз'єднання.

Приклад операції напівз'єднання: створити звіт, що містить повну інформацію про всіх співробітників, що працюють в відділенні компанії, розташованому в місті 'Glasgow'.

Якщо нас цікавлять лише атрибути відношення Staff, то ми можемо використовувати наступну операцію напівз'єднання, яка веде до отримання відношення, приведеного в таблиці 5.10.

 

               (5.15)

 

Таблиця 5.10 – Результат напівз'єднання відношень Staff і Branch

staffNo

fName

lName

position

sex

DOB

salary

branchNo

SG37

Ann

Beech

Assistant

F

10-Nov-60

12000

B003

SG14

David

Ford

Supervisor

M

24-Mar-58

18000

B003

SG5

Susan

Brand

Manager

F

3-Jun-40

24000

B003

 

Ділення. Операція ділення може застосовуватися в разі запитів особливого типу, які досить часто зустрічаються в застосуваннях баз даних. Передбачимо, що відношення R визначене на множині атрибутів А, а відношення S – на множині атрибутів В, причому В Î А (тобто B є підмножиною А). Хай С=А-В, тобто С є множиною атрибутів відношення R, які не є атрибутами відношення S. Тоді означення операції ділення виглядатиме таким чином.

R÷S. Результатом операції ділення є набір кортежів відношення R визначених на множині атрибутів C, які відповідають комбінації всіх кортежів відношення S.

Цю операцію можна представити і за допомогою інших основних операцій (5.16):

 

                                             (5.16)

 

Графічно зміст операції ділення відношень показано на рисунку 5.5.

 

Рисунок 5.5 – Схематичне зображення операції ділення відношень

 

Приклад операції ділення відношень: створити список всіх орендарів, які оглядали об'єкти нерухомості з трьома кімнатами.

Для вирішення поставленого завдання спочатку слід за допомогою операції вибірки виконати пошук всіх трикімнатних об'єктів нерухомості, а потім за допомогою операції проекції отримати відношення, що містить номери лише цих об'єктів нерухомості. Після цього потрібно застосувати приведену нижче операцію ділення (5.17) і отримати нове відношення, як показане в таблицях 5.11–5.13.

 

              (5.17)

 

Таблиця 5.11 – Результат застосування операції проекції  до відношення Viewing

clientNo

propertyNo

CR56

РА14

CR76

PG4

CR56

PG4

CR62

РА14

CR56

PG36

 

Таблиця 5.12 – Результат застосування операції вибірки  до відношенняPropertyForRent

clientNo

PG4

PG36

 

Таблиця 5.13 – Результат застосування операції ділення до результатів двох попередніх операцій

clientNo

CR56

 

5.2 Перегляди в реляційних базах даних

 

У реляційній моделі слово "перегляд" (view) характеризує деяке використовуване ним віртуальне або похідне відношення (virtual relation), тобто відношення, яке насправді не існує, але динамічно відтворюється на підставі одного або декількох базових відношень (відношень, що реально існують в базі даних). Таким чином, зовнішня модель (як її бачить користувач) може складатися одночасно як з базових (на концептуаль­ном рівні) відношень, так і з переглядів, відтворених на основі цих базових відношень. розглянемо саме такі вирту­альні відношення, або перегляди, що є типовим елементом ре­ляційних систем. Пізніше перегляди розглядатимуться детальніше і буде показано способи їх створення в мові SQL.

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

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

Поняття перегляду визначається на основі базових відношень.

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

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

 

5.2.1 Призначення переглядів

Механізм переглядів може використовуватися з кількох причин.

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

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

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

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

-       При роботі із записами відношення Branch користувачам, окрім різноманітних атрибутів із записів цього відношення, може бути потрібно вибирати імена і інші відомості про відповідних менеджерів. Подібний перегляд створюється шляхом з'єднання відношень Branch і Staff з наступною його проекцією за значенням атрибутуManager.

-       Більшість користувачів при роботі із записами відношення Staff не повинна мати доступу до атрибуту salary.

-       Атрибути можуть переіменовуватися, так що користувач, який привик використовувати замість номерів відділень (атрибут branchNo) їх повну назву (Branch Number), зможе використовувати відповідний текст як заголовок стовпця.

-       Кожному співробітникові може бути надане право переглядати записи з характеристиками лише тих об'єктів нерухомості, за які він відповідає.

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

 

5.2.2 Оновлення переглядів

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

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

-       Оновлення не допускаються в будь-яких переглядах, визначених на основі декількох базових відношень.

-       Оновлення не допускаються в будь-яких переглядах, включаючих виконання операцій агрегації або групування.

Перегляди прийнято ділити на наступні класи: теоретично неоновлювані, теоретично оновлювані і частково оновлювані.

 

5.3 Ознаки реляційної бази даних

 

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

Впродовж багатьох років запропоновані Коддом правила викликали масу нарікань в зацікавлених осіб і фахівців. Одні визнали їх не більше ніж чисто теоретичними вправами. Інші заявили, що їх продукти вже задовольняють багатьом цим правилам, якщо не всім. Аби підкреслити особливе значення цих правил, їх розділили на п'ять функціональних груп.

1.  Фундаментальні правила.

2.  Структурні правила.

3.  Правила цілісності.

4.  Правила управління даними.

5.  Правила незалежності від даних.

Фундаментальні правила (правила 0 і 12)

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

Правило 0 – фундаментальне правило.

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

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

Правило 12 – правило заборони обхідних шляхів.

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

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

Структурні правила (правила 1 і 6).

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

Правило 1 – представлення інформації.

Вся інформація в реляційній базі даних представляється в явному вигляді на логічному рівні і лише одним способом – у вигляді значень в таблицях.

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

Правило 6 – оновлення переглядів.

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

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

Правила цілісності (правила 3 і 10).

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

Правило 3 – систематична обробка невизначених значень (NULL).

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

Правило 10 – незалежності обмежень цілісності.

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

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

Правила маніпулювання даними (правила 2, 4, 5 і 7).

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

Правило 2 – гарантований доступ.

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

Правило 4 – динамічний інтерактивний каталог, побудований по правилах реляційної моделі.

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

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

Правило 5 – вичерпна підмова даних.

Реляційна система може підтримувати декілька мов і різні режими роботи з терміналами (наприклад, режим заповнення форми – fill-in-the-blanks). Проте повинна існувати принаймні одна мова, оператори якої дозволяли б виражати всі наступні конструкції: 1) визначення даних; 2) визначення представлень; 3) команди маніпулювання даними (доступні як інтерактивно, так і з програм); 4) обмеження цілісності; 5) авторизація користувачів; 6) організація транзакцій (запуск, фіксація і відкат).

Слід зазначити, що новий стандарт ISO для мови SQL забезпечує виконання всіх цих функцій таким чином, що будь-яка мова, котра задовольняє цьому стандарту, автоматично задовольнятиме і цьому правилу.

Правило 7 – високорівневі операції вставки, оновлення і видалення.

Здатність обробляти базові або похідні відношення (тобто представлення) як єдиний операнд повинна відноситися не лише до процедур вибірки даних, але і до операцій вставки, оновлення і видалення даних.

Правила незалежності від даних (правила 8, 9 і 11).

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

Правило 8 – фізична незалежність від даних.

Прикладні програми і засоби роботи з терміналами повинні залишатися логічно незмінними при внесенні будь-яких змін до способів зберігання даних або методів доступу до них.

Правило 9 – логічна незалежність від даних.

Прикладні програми і засоби роботи з терміналами повинні залишатися логічно незмінними при внесенні до базових таблиць будь-яких змін, що не міняють інформацію, які теоретично не повинні зачіпати прикладне програмне забезпечення.

Правило 11 – незалежність від розподілу даних.

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

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

 

Тема 8 Вступ до мови структурованих запитів 
S
tructured Query Language (SQL).

 

8.1 Призначення SQL та правила запису SQL-операторів, компоненти мови SQL, ідентифікатори і зарезервоані слова

 

SQL – не є мовою програмування. Це мова, призначена для створення та супроводу баз даних. Багато сучасних засобів розробки програмного забезпечення (C++ Builder, Delphi, Kylyx, Visual Studio та ін.), мають можливості длявставки фрагментів програмного коду, написаного на мові SQL, у лістинг програми, написаної на С, С++, Pascal та ін.  тобто за допомогою SQL можна створювати бази даних, маніпулювати даними (вибирати, добавляти, змінювати, витирати), а також керувати даними (захист даних від різноманітних пошкоджень).

У відповідності до названих груп завдань, які вирішуються за допомогою SQL, існує її поділ на три частини:

-       мова означення даних (Data Definition Language, DDL) – частина SQL, котра використовується для створення (повного означення) бази даних, зміни її структури та знищення.  

-       мова маніпуляції даними (Data Manipulation Language, DML) – призначена для підтримки бази даних. З допомогою цього інмструменту можна вказати, що потрібно зробити з даними – ввести, змінити,вибрати потрібні.

-       мова управління даними (Data Control Language, DCL) – інструмент захисту баз даних від різних варіантів пошкодження.

 

Згідно діючого стандарту SQL:1999, як будь яка мова програмування, SQL містить набір зарезервованих слів, а також правила, згідно яких ці слова складаються у операторах. Формат запису стрічки SQL довільний, але більшість реалізацій вимагають, щоби у кінці кожного оператора стояв занк «;». Порядок запису складових оператора змінювати не можна. Більшість компонентів SQL не чутливі до регістру, тобто можна використовувати як малі, так і великі букви. Звичайно, виключення становлять стрічкові літерали, що містяться у базі даних. Наприклад, коли ви шукаєте в базі даних слово ’Україна’, а насправді там міститься слово ’УКРАЇНА’, то результат пошуку буде нульовий. Стрічкові літерали беруться у одинарні лапки. Перелік зарезервованих слів мови SQL тут свідомо не наводиться. З більшістю з них студент ознайомиться за час вивчення матеріалів даного розділу дисципліни "Організація баз даних і знань". Проте варто зауважити, що в рамках лекційних та лабораторних занять приведені лише основи мови SQL, а в повному обсязі з нею можна ознайомитись, опрацювавши матеріал, рекомендований в переліку літератури та посилань, а також – з документацією до конкретних СКБД.

Часто використовують такий стиль запису SQL-операторів, що зарезервовані слова набираються великими літерами, а ідентифікатори – малими, хоче це правило не завжди дотримується. Прикладами дотримання цього правила є СКБД відMicrosoft (Access, MS SQLServer), його недотримання – mySQL.

Почнемо з мови маніпуляції даними – DML і розглянемо наступні оператори:

SELECT – вибірка даних;

INSERT – вставка даних у таблицю;

UPDATE – оновлення (зміна) даних в таблиці;

DELETE – знищення даних у таблиці.

8.2 Прості запити вибірки

Опреатор SELECT – найчастіше використовуєтья у мові SQL. Спрощений його запис має наступний вигляд:

 

SELECT [DISTINCT|ALL] {* | [column_expretion [AS new_name]][,…]}

FROM table_name [alias] [,…]

[WHERE condition]

[GROUP BY column_list] [HAVING condition]

[ORDER BY column_list];

 

Приклад:

Вибір всіх стовбців: SELECT * FROM staff;                   (staff – ім’я існуючої таблиці зі списком працівників фірми).

При вказанні слова       DISTINCT      будуть вибрані лише унікальні стрічки.

AS – нове ім’я стовбця у вибірці.

Приклад з обчислюваним полем:

 

SELECT no, name, salary/12 AS monthly_salary

FROM staff;

 

Результатом виконання даного оператора буде таблиця, у якій з таблиці staff будуть вибрані поля, що означають номер працівника, його ім’я а також дані з стовбця про зарплату під іменем salary будуть поділені на 12 та представлені у стовбці з іменем monthly_salary (місячна зарплата).

Інші допустимі знаки математичних дій у мові SQL: +, -, *, /. Знак || означає конкатенацію стрічкових літералів.

Для вибору лише певних стрічок таблиці використовують слово WHERE з наступним вказанням після нього умови відбору стрічок. Допустимі оператори порівняння: =, < ,> , <=, >=, <> (або != у деяких діалектах). Якщо умов декілька, то їх можна об’єднати з допомогою однієї з логічних операцій: ANDNOTOR.

Замість операторів порівняння можна використовувати задання діапазонів за допомогою слів BETWEEN … AND(входження в діапазон з включенням границь) чи NOT BETWEEN … AND (за межами діапазону).

Приклад:

 

SELECT no, name, salary

FROM staff

WHERE salary BETWEEN 1000 AND 5000 AND city=’Тернопіль’;

 

Результатом будуть стрічки, що містять номер працівника, його ім’я та зарплату. Причому, будуть вибиратися тільки ті працівники, що проживають у Тернополі та мають зарплату від 1000 до 5000.

Для перевірки входження у множину значень використовують слово IN чи NOT IN (очевидно, неналежність до множини).

Наприклад, оператор

 

SELECT no, name, salary

FROM staff

WHERE position IN (‘Manager’, ‘Officer’) AND city=’Тернопіль’;

 

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

Звичайно, використання діапазонів (BETWEEN) та множин (IN) можна замінити відповідно операціями порівняння та логічного АБО (OR) відповідно, але використання цих інструментів дає можливість компактніше записати вираз та вважається, що вони пришвидшують виконання цілого запиту.

У умові відбору записів після слова WHERE можна використовувати також слова LIKE або NOT LIKE  (подібний чи неподібний) для пошуку стрічкових літералів, що входять у текстове поле запису більшої довжини. У мові SQL існує два спеціальних символи шаблону для задання довільної послідовності символів:

%        задає довільну послідовність символів (в т.ч. і нульову);

_        (знак підкреслення) задає один довільний символ.

Наприклад, запит

 

SELECT no, name, address, salary

FROM staff

WHERE address LIKE ‘%піл_’;

 

вибере дані про номер, ім’я, адресу та зарплату працівників, у яких в полі адреси введено стрічку, в котрій перші символи довільні, три передостанніх – це ’піл’ і останній – довільний один символ. Тобто це назви міст типу Тернопіль, Сімферопіль, Спіле і т.п.

В новому стандарті SQL:1999 появився предикат SIMILAR TO, котрий дозволяє знаходити часткове співпадання більш ефективно, ніж за допомогою LIKE. З допомогою SIMILAR TO можна порівнювати символьну стрічку з регулярним виразом. Наприклад, при перегляді таблиці, що містить стовбець з назвою OPERATING_SYSTEM (операційна система), щоби перевірити сумісність з MS Windows, можна скласти таке речення WHERE:

 

WHERE OPERATING_SYSTEM SIMILAR TO

'(Windows (3.1|95|98|Millenium Edition|CE|NT|2000|XP))';

 

В результаті виконання цього предикату будуть повернуті всі стрічки, у котрих у стовбці OPERATING_SYSTEM міститься будь-яка з вказаних операційних систем.

У базі даних (в її записах) можливі поля, значення яких на є обов’язковими для вводу. Коли ці поля порожні, то кажуть, що вони містять значення NULL. Для перевірки таких полів використовують IS NULL або IS NOT NULL.

Наприклад, запит

 

SELECT no, name

FROM staff

WHERE comment IS NULL;

 

вибере з таблиці staff номери та імена працівників, поле примітки яких незаповнене.

Сортування результатів (фраза ORDER BY).

Для сортування вибраних даних з БД використовують фразу ORDER BY оператора SELECT. Ця фраза включає список розділених комами ідентифікаторів стовпців, за котрими потрібно впорядкувати результуючу таблицю. Впорядкування можна здійснити як у порядку зростання ASC так і спадання DESC. Фраза ORDER BY повинна бути останньою в операторі SELECT.

Наприклад, оператор

 

SELECT no, name, address, salary

FROM staff

WHERE address LIKE ‘%піл_’

ORDER BY name,salary DESC;

Використання узагальнюючих функцій мови SQL.

Існує 5 узагальнюючих функцій.

COUNT() – повертає кількість значень у вказаному стовпці.

SUM() – повертає суму значень вказаного стовпця.

AVG() – повертає усереднене значення вказаного стовпця.

MIN() – повертає мінімальне значення вказаного стовпця.

MAX() – повертає максимальне значення вказаного стовпця.

Якщо потрібно при роботі узагальнюючої функції виключити дубльовані значення стовпця, то перед іменем стовпця-аргументу функції ставлять слово DISTINCT.

Наприклад.

 

SELECT MIN(salary) AS min, MAX(salary) AS max, SUM(salary) AS sum, COUNT(DITINCT no)

FROM staff

WHERE position=’Manager’;

 

Якщо в запиті, як у даному прикладі, крім узагальнюючих функцій присутня фраза WHERE, то спочатку виконується вона, а потів за результатами вибірки робляться узагальнюючі підрахунки.

Групування результатів.

Дані, які повертають узагальнюючі функції, як правило розміщуються в кінці звітів. Для формування проміжних підсумків використовують групування за допомогою фрази GROUP BY. Після цієї фрази перераховують через кому імна стовпців, по яких потрібно провести групування. Імена стовпців, вказані в списку для групування, обов’язково повинні бути вказані і у фразі SELECT. Виключення ствановлять імена стовбців, використані в узагальнюючих функціях.

Наприклад,

 

SELECT no, COUNT(*) AS count, SUM(salary) AS sum

FROM staff

WHERE position=’Manager’

GROUP BY no

ORDER BY no DESC;

 

Для відбору певних груп разом з фразою GROUP BY використовують фразу HAVING (фраза WHERE використовується для відбору записів). На практиці умова HAVING найчастіше включає одну з узагальнюючих функцій.

 

Обмеження на виконання групування 
(конструкція 
HAVING).

Конструкція HAVING призначена для використання спільно з конструкцією GROUP BY для завдання обмежень, що указуються з метою відбору тих груп, які будуть поміщені в результуючу таблицю запиту. Хоча конструкції HAVING і WHEREмають схожий синтаксис, їх призначення різне. Конструкція WHERE призначена для відбору окремих рядків, призначених для заповнення результуючої таблиці запиту, а конструкція HAVING використовується для відбору груп, що поміщаються в результуючу таблицю запиту. Стандарт ISO вимагає, щоб імена стовпців, вживані в конструкції HAVING, обов'язково були присутні в списку елементів GROUP BY або застосовувалися в агрегуючих функціях. На практиці умови пошуку в конструкціїHAVING завжди включають, щонайменше, одну агрегуючу функцію; інакше ці умови пошуку повинні бути поміщені в конструкцію WHERE і застосовані для відбору окремих рядків. (Пам'ятаєте, що агрегуючі функції не можуть використовуватися в конструкції WHERE.)

Конструкція HAVING не є необхідною частиню мовиSQL – будь-який запит, написаний з використанням конструкціїHAVING, може бути представлений у іншому виді, без її використання.

 

Приклад використання конструкції HAVING.

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

 

SELECT branchNo, COUNT (staffNo) AS count, SUM (salary) AS sum

FROM Staff

GROUP BY branchNo

HAVING COUNT(staffNo)> 1

ORDER BY branchNo;

 

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

 

12.8.1 Складні запити на вибірку

8.3 Підзапити

 

У цьому розділі ми обговоримо використання закінчених операторів SELECT, впроваджених в тіло іншого оператораSELECT. Зовнішнього (другий) оператора SELECT використовує результат виконання внутрішнього (першого) оператора для визначення змісту остаточного результату всієї операції. Внутрішні запити можуть знаходитися в конструкціях WHERE іHAVING зовнішнього оператора SELECT – в цьому випадку вони отримують назву підзапитів, або вкладених запитів. Крім того, внутрішні оператори SELECT можуть використовуватися в операторах INSERTUPDATE і DELETE. Існують три типи підзапитів.

-      Скалярний підзапит повертає значення, вибране з перетину одного стовпця з одним рядком, тобто єдине значення. В принципі скалярний підзапит може використовуватися скрізь, де потрібно вказати єдине значення.

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

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

 

Приклад використання підзапиту з перевіркою на рівність.

Складіть список персоналу, що працює у відділенні компанії, розташованому за адресою '163 Main St'.

 

SELECT staffNo, fName, lName, position

FROM Staff

WHERE branchNo = (SELECT branchNo

FROM Branch

WHERE street = '163 Main St') ;

 

Внутрішній оператор SELECT (SELECT branchNo FROM Branch ...) призначений для визначення номера відділення компанії, розташованого за адресою '163 Main st'. (Існує тільки одне таке відділення компанії, тому даний приклад є прикладом скалярного підзапиту.) Після отримання номера необхідного відділення виконується зовнішній підзапит, призначений для вибірки докладних відомостей про працівників цього відділення. Інакше кажучи, внутрішній операторSELECT повертає таблицю, що складається з єдиного значення 'В003'. Воно є номером того відділення компанії, яке знаходиться за адресою '163 Main St'. В результаті зовнішній оператор SELECT набуває наступний вигляд:

 

SELECT staffNo, fName, lName, position

FROM Staff

WHERE branchNo = 'B003';

 

Підзапитом є інструмент створення тимчасової таблиці, вміст якої витягується і обробляється зовнішнім оператором. Підзапит. можна указувати безпосередньо після операторів порівняння (тобто операторів =, <, >, <=, >=, <>) в конструкціїWHERE або HAVING. Текст підзапиту повинен бути поміщений в круглі дужки.

Приклад використання підзапитів з агрегуючими функціями

Складіть список всіх співробітників, що мають зарплату вище середньою, вказавши, наскільки їх зарплата перевищує середню зарплату по підприємству.

 

SELECT BtaffNo, fName, lName, position, salary -     (SELECT AVG (salary)

FROM Staff) AS salDiff

FROM Staff

WHERE salary > (SELECT AVG(salary) FROM Staff);

 

Необхідно відзначити, що не можна безпосередньо включити в запит вираз 'WHERE salary > AVG (salary)', оскільки застосовувати агрегуючі функції в конструкції WHERE заборонено. Для досягнення бажаного результату слід створити підзапит, що обчислює середнє значення річної заробітної плати, а потім використовувати його в зовнішньому операторовіSELECTпризначеному для вибірки відомостей про тих працівників компанії, чия зарплата перевищує це среднее-значение. Інакше кажучи, підзапит повертає значення середньої зарплати по компанії в рік, рівне 17000 грн. Результат виконання цього скалярного підзапиту використовується в зовнішньому операторові SELECT як для обчислення відхилення зарплати від середнього рівня, так і для відбору відомостей про працівників. Тому зовнішнього оператора SELECT набуває наступний вигляд:

 

SELECT staffNo, fName, lName, position, salary - 17000 As salDiff

FROM Staff

WHERE salary > 17000;

 

До підзапитів застосовуються наступні правила і обмеження.

1.       У підзапитах не повинна використовуватися конструкція ORDER BY, хоча вона може бути присутньою в зовнішньому операторові SELECT.

2.       Список вибірки SELECT підзапиту повинен складатися з імен окремих стовпців або складених з них виразів (не можна використовувати *), за винятком випадку, коли в підзапиті використовується ключове слово EXISTS.

3.       За замовчуванням імена стовпців в підзапиті відносяться до таблиці, ім'я якої вказане в конструкції FROMпідзапиту. Проте дозволяється посилатися і на стовпці таблиці, вказаної в конструкції FROM зовнішнього запиту, для чого використовуються уточнені імена стовпців (як описано нижче).

4.       Якщо підзапит є одним з двох операндів, що беруть участь в операції порівняння, то підзапит повинен вказуватися в правій частині цієї операції. Наприклад, приведений нижче варіант запису запиту з попереднього прикладу є некоректним, оскільки підзапит розміщений в лівій частині операції порівняння із значенням стовпця salary.

 

SELECT staffNo, fName, lName, position, salary

FROM Staff

WHERE (SELECT AVG (salary) FROM Staff) < salary;

 

Приклад вкладених підзапитів і використання предиката IN.

Складіть перелік об'єктів, що здаються в оренду, за які відповідають працівники відділення компанії, розташованого за адресою '163 Main St'.

 

SELECT propertyNo, street, city, postcode, type, rooms, rent

FROM PropertyForRent

WHERE staffNo IN (SELECT staffNo

FROM Staff

WHERE branchNo = (SELECT branchNo

FROM Branch

WHERE street = '163 Main St'));

 

Перший, самий внутрішній, запит призначений для визначення номера відділення компанії, розташованого за адресою'163 Main St'. Другий, проміжний, запит здійснює вибірку відомостей про персонал, що працює в цьому відділенні. В даному випадку вибирається більше одного рядка даних і тому в зовнішньому запиті не можна використовувати оператора порівняння =. Замість нього необхідно використовувати ключове слово IN. Зовнішній запит здійснює вибірку відомостей про об'єкти, що здаються в оренду, за які відповідають ті працівники компанії, дані про яких були отримані в результаті виконання проміжного запиту.

 

Ключові слова ANY і ALL.

Ключові слова ANY і ALL можуть використовуватися з підзапитами, що повертають один стовпець чисел. Якщо підзапиту передуватиме ключове слово ALL, умова порівняння вважається виконаною тільки в тому випадку, якщо воно виконується для всіх значень в результуючому стовпці підзапиту. Якщо тексту підзапиту передує ключове слово ANY, то умова порівняння вважатиметься виконаною, якщо воно задовольняється хоч би для якого-небудь (одного або декількох) значення в результуючому стовпці підзапиту. Якщо в результаті виконання підзапиту буде набуто порожнього значення, то для ключового слова ALL умова порівняння вважатиметься виконаною, а для ключового слова ANY – невиконаною. Згідно стандарту ISO додатково можна використовувати ключове слово SOME, що є синонімом ключового слова ANY.

 

Приклад використання ключових слів ANY і SOME.

Знайдіть всіх працівників, чия зарплата перевищує зарплату хоч би одного працівника відділення компанії під номером 'B003'.

 

SELECT staffNo, fName, lName, position, salary

FROM Staff

WHERE salary > SOME    (SELECT salary

FROM Staff WHERE branchNo = 'B003');

 

Хоча цей запит може бути записаний з використанням підзапиту, що визначає мінімальну зарплату персоналу відділення під номером 'В003', після чого зовнішній підзапит зможе вибрати відомості про весь персонал компанії, чия зарплата перевершує це значення, можливий і інший підхід, що полягає у використанні ключових слів SOME/ANY. В цьому випадку внутрішній підзапит створює множину значень {12000, 18000, 24000}, а зовнішній запит вибирає відомості про тих працівників, чия зарплата більше будь-якого із значень в цій множині (фактично більше мінімального значення – 12000). Подібний альтернативний метод можна вважати природнішим, ніж визначення в підзапиті мінімальної зарплати. Але і в тому і в іншому випадку отримуються однакові результати виконання запиту.

Приклад використання ключового слова ALL.

Знайдіть всіх працівників, чия заробітна плата більше заробітної плати будь-якого працівника відділення компанії під номером 'В003'.

 

SELECT staffNo, fName, lName, position, salary FROM Staff

WHERE salary > ALL(SELECT salary FROM Staff WHERE branchNo = 'B003');

 

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

 

8.4 Багатотабличні запити.

 

Всі розглянуті вище приклади мають одне і те ж важливе обмеження: стовпці, що поміщаються в результуючу таблицю, завжди вибираються з єдиної таблиці. Проте у багатьох випадках цього виявляється недостатньо. Для того, щоб об'єднати в результуючій таблиці стовпці з декількох початкових таблиць, необхідно виконати операцію з'єднання. У мовіSQL операція з'єднання використовується для з'єднання інформації з двох таблиць за допомогою утворення пар зв'язаних рядків, вибраних з кожної таблиці. Пари рядків, що поміщаються в з'єднану таблицю, складаються по рівності вхідних в них значень вказаних стовпців.

Якщо необхідно отримати інформацію з декількох таблиць, то можна або застосувати підзапит, або виконати з'єднання таблиць. Якщо результуюча таблиця запиту повинна містити стовпці з різних початкових таблиць, то доцільно використовувати механізм з'єднання таблиць. Для виконання з'єднання досить в конструкції FROM вказати імена двох і більше таблиць, розділивши їх комами, після чого включити в запит конструкцію WHERE з визначенням стовпців, використовуваних для з'єднання вказаних таблиць. Крім цього, замість імен таблиць можна використовувати псевдоніми, призначені їм в конструкції FROM. В цьому випадку імена таблиць і псевдоніми, що призначаються ним, повинні розділятися пропусками. Псевдоніми можуть використовуватися з метою уточнення імен стовпців у всіх тих випадках, коли можлива неоднозначність відносно того, до якої таблиці відноситься той або інший стовпець. Крім того, псевдоніми можуть використовуватися для скороченого позначення імен таблиць. Якщо для таблиці визначений псевдонім, він може застосовуватися в будь-якому місці, де потрібно вказати ім’я цієї таблиці.

 

Приклад простого з'єднання.

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

 

SELECT c.clientNo, fName, lName, propertyNo, comment

FROM Client c, Viewing v

WHERE c.clientNo = v.clientNo;

 

У цьому звіті потрібно представити відомості як з таблиці Client, так і з таблиці Viewing, тому при побудові запиту ми скористаємося механізмом з'єднання таблиць. У конструкції SELECT перераховуються всі стовпці, які повинні бути поміщені в результуючу таблицю запиту. Зверніть увагу, що для стовпця з номером клієнта (clientNo) необхідне уточнення, оскільки такий стовпець може бути присутнім і в іншій таблиці, що бере участь в з'єднанні. Тому необхідно явно вказати, значення якої таблиці нас цікавлять. (У даному прикладі з тим же успіхом можна було вибрати значення стовпця clientNo з таблиціViewing.) Уточнення імені здійснюється шляхом вказівки як префікса перед іменем стовпця імені відповідної таблиці (або її псевдоніма). У нашому прикладі використовується значення 'c', задане як псевдонім таблиці Client. Для формування результуючих рядків використовуються ті рядки початкових таблиць, які мають ідентичне значення в стовпці clientNo. Ця умова визначається за допомогою завдання услония пошуку c.clientNo=v.clientNo. Подібні стовпці початкових таблиць називають поєднуваними стовпцями. Описана операція еквівалентна операції з'єднання по рівності реляційної алгебри.

Найчастіше багатотабличні запити виконуються для двох таблиць, сполучених зв'язком типу "один до багатьох" або батьківсько-дочірнім зв'язком. У приведеному вище прикладі, що включає звернення до таблиць Client і Viewing, останні сполучені саме таким зв'язком. Кожен рядок таблиці Viewing (дочірньої, підлеглої) пов'язаний лише з одним рядком таблиціClient (батьківською, головною), тоді як один і той же рядок таблиці Client (батьківська) може бути пов'язана з багатьма рядками таблиці Viewing (дочірньої). Пари рядків, які генеруються при виконанні запиту, є результатом всіх допустимих комбінацій рядків дочірньої і батьківської таблиць. Раніше було детально описано, як в реляційній базі даних первинний і зовнішній ключі таблиць створюють "батьківсько-дочірній" зв'язок. Таблиця, що містить зовнішній ключ, зазвичай є дочірньою, тоді як таблиця, що містить первинний ключ, завжди буде батьківською. Для використання батьківсько-дочірнього зв'язку в запиті SQL необхідно вказати умову пошуку, в якому порівнюватимуться зовнішній і первинний ключі. У прикладі 9.6 первинний ключ таблиці Client (с.clientNo) порівнюється із зовнішнім ключем таблиці Viewing (v.clientNo).

Стандарт SQL додатково надає наступні способи визначення даного з'єднання:

 

FROM Client c JOIN Viewing v ON c.clientNo = v.clientNo

FROM Client JOIN Viewing USING clientNo

FROM Client NATURAL JOIN Viewing

 

В кожному випадку конструкція FROM заміщає початкові конструкції FROM і WHERE. Проте в першому варіанті створюється таблиця з двома ідентичними стовпцями clientNo, тоді як в решті двох випадків результуюча таблиця міститиме тільки один стовпець clientNo.

 

Приклад сортування результатів з'єднання таблиць.

Для кожного відділення компанії перерахуєте табельні номери і імена працівників, що відповідають за які-небудь об'єкти, що здаються в оренду, а також вкажіть об'єкти, за які вони відповідають.

 

SELECT S.branchNo, s.staffNo, fName, lName, propertyNo

FROM Staff s, PropertyForRent p

WHERE s.staffNo = р. staffNo

ORDER BY s.branchNo, s.staffNo, propertyNo;

 

Для того, щоб результати стали зручнішими для читання, отриманий вивід відсортований з використанням номера відділення як старший ключ сортування, а табельного номера і номера власності – як молодші ключі.

Приклад з'єднання трьох таблиць.

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

 

SELECT b.branchNo, b.city, s.staffNo, fName, lName, propertyNo

FROM Branch b, Staff s, PropertyForRent p

WHERE b.branchNo = s.branchNo AND s.staffNo = p.staffNo

ORDER BY b.branchNo, s.staffNo, propertyNo;

 

У результуючу таблицю необхідно помістити стовпці з трьох початкових таблиць – Branch, Staff і Property For Rent, тому в запиті слід виконати з'єднання цих таблиць. Таблиці Branch і staff можуть бути сполучені за допомогою умовиb.branchNo=s.branchNo, внаслідок чого відділення компанії будуть пов'язані з персоналом, що працює в них. Таблиці staff іPropertyForRent можуть бути сполучені за допомогою умови s.staffNo=p.staffNo. В результаті кожен працівник буде пов'язаний з тими об'єктами, що здаються в оренду, за які він відповідає.

Відмітимо, що стандарт SQL дозволяє використовувати альтернативний варіант формулювання конструкцій FROM іWHERE:

 

FROM (Branch b JOIN Staff s USING branchNo) AS bs

JOIN PropertyForRent p USING staffNo

 

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

Визначите кількість об'єктів, що здаються в оренду, за які відповідає кожен з працівників компанії.

 

SELECT s.branchNo, S.staffNo, COUNT(*) AS count FROM Staff s, PropertyForRent p WHERE S.staffNo = р. staffNo GROUP BYs . branchNo, s.staffNo ORDER BY s.branchNo, s.staffNo;

 

Щоб скласти необхідний звіт, перш за все необхідно з'ясувати, хто з працівників компанії відповідає за об'єкти, що здаються в оренду. Цю задачу можна вирішити за допомогою з'єднання таблиць Staff і PropertyForRent по стовпцю staffNo в конструкціях FROM/WHERE. Потім необхідно сформувати групи, що складаються з номера відділення і табельних номерів його працівників, для чого слід застосувати конструкцію GROUP BY. Нарешті, результуюча таблиця повинна бути відсортована за допомогою завдання конструкції ORDER BY.

 

Виконання з'єднань.

З'єднання є підмножиною більш загальної комбінації даних двох таблиць, що називається декартовим добутком. Декартовий добуток двох таблиць є іншою таблицею, що складається зі всіх можливих пар рядків, що входять до складу обох таблиць. Набір стовпців результуючої таблиці є всіма стовпцями першої таблиці, за якими слідують всі стовпці другої таблиці. Якщо ввести запит до двох таблиць без завдання конструкції WHERE, результат виконання запиту в середовищі SQLбуде декартовий добуток цих таблиць. Крім того, стандарт ISO передбачає спеціальний формат оператора SELECT, що дозволяє обчислити декартовий доьуток двох таблиць:

 

SELECT [DISTINCT | ALL] {* | columnList}

FROM tableName1 CROSS JOIN tableNeme2

 

Ще раз розглянемо приклад 9.6, в якому з'єднання таблиць client і Viewing виконується з використанням загального стовпця clientNo. Це еквівалентно видачі використовуваного в прикладі 9.6 запиту, але без застосування конструкції WHERE.

Процедура генерації таблиці, що містить результати з'єднання двох таблиць за допомогою оператора SELECT, полягає в наступному.

1.       Формується декартовий добуток таблиць, вказаних в конструкції FROM.

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

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

4.       Якщо в початковому запиті присутня конструкція SELECT DISTINCT, з результуючої таблиці віддаляються всі рядки-дублікати. У реляційній алгебрі дії, що виконуються на 3 і 4 етапах, еквівалентні операції проекції по стовпцях, заданих в списку вибірки SELECT.

9.   Якщо виконуваний запит містить конструкцію ORDER BY, здійснюється переупорядковування рядків результуючої таблиці.

 

Зовнішні з'єднання.

При виконанні операції з'єднання дані з двох таблиць комбінуються з утворенням пар зв'язаних рядків, в яких значення стовпців, що зіставляються, є однаковими. Якщо одне із значень в стовпці однієї таблиці, що зіставляється, не співпадає ні з одним із значень в стовпці іншої таблиці, що зіставляється, то відповідний рядок віддаляється з результуючої таблиці. Саме це правило застосовувалося у всіх розглянутих вище прикладах з'єднання таблиць. Стандартом ISOпередбачений і інший набір операторів з'єднань, званих зовнішніми з'єднаннями. У зовнішньому з'єднанні в результуючу таблицю поміщаються також рядки, що не задовольняють умові з'єднання. Щоб зрозуміти особливості виконання операцій зовнішнього з'єднання, скористаємося спрощеними таблицями Branch і PropertyForRent, вміст яких представлений в табл. 8.1 і 8.2.

 

Таблиця 8.1 – Таблиця Branch1

branch No

bCity

В003

Glasgow

В004

Bristol

В002

London

 

Таблиця 8.2 – Таблиця PropertyForRent1

propertyNo

pCity

PA14

Aberdeen

PL94

London

PG4

Glasgow

 

Звичайне (внутрішнє) з'єднання цих таблиць виконується за допомогою наступного оператора SQL:

 

SELECT b.*, p.*

FROM Branch1 b, PropertyForRent1 p

WHERE b.bCity = p.pCity;

 

Результати виконання цього запиту представлені в табл. 8.3.

 

Таблиця 8.3 – Результат внутрішнього з'єднання спрощених таблиць Branch1 і PropertyForRent1

branchNo

bCity

propertyNo

pCity

В003

Glasgow

PG4

Glasgow

В002

London

PL94

London

 

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

 

Приклад лівого зовнішнього з'єднання.

Перерахуєте відділення компанії і об'єкти, що здаються в оренду, які розташовані в одному і тому ж місті, а також інші відділення компанії, що не задовольняють умові запиту.

Використовуємо ліве зовнішнє з'єднання цих двох таблиць, яке виглядає таким чином:

 

SELECT b.*, р.*

FROM Branch1 b LEFT JOIN PropertyForRent1 p ON b.bCity = p.pCity;

 

Результати виконання цього запиту представлені в табл. 8.4. В даному прикладі за рахунок застосування лівого зовнішнього з'єднання в результуючу таблицю потрапили не тільки два рядки, в яких є відповідність між назвами міст, але також той рядок першої з таблиць (лівою), що сполучаються, яка не знайшла собі відповідності в другій таблиці (правою). У цьому рядку всі поля другої таблиці заповнені значеннями NULL.

 

Таблиця 8.4 – Результат виконання запиту лівого зовнішнього з'єднання

branch No

bCity

propertyNo

pCity

B003

Glasgow

PG4

Glasgow

В004

Bristol

NULL

NULL

В002

London

PL94

London

 

Приклад правого зовнішнього з'єднання.

Перерахуєте відділення компанії і об'єкти, що здаються в оренду, які розташовані в одному і тому ж місті, а також решту всіх об'єктів власності, що не задовольняють умові запиту.

Використовуємо праве зовнішнє з'єднання цих двох таблиць, яке виглядає таким чином:

 

SELECT b.*, р.*

FROM Branch1 b RIGHT JOIN PropertyForRent1 p ON b.bCity = p.pCity;

 

Результати виконання цього запиту представлені в табл. 8.5. В даному прикладі при виконанні правого зовнішнього з'єднання в результуючу таблицю були включені не тільки ті два рядки, які мають однакові значення в стовпцях, що зіставляються, з назвою міста, але також і ті рядки з другої (правою) таблиці, які не знайшли відповідності з рядками в першій (лівою) таблиці. У цьому рядку всі поля з першої таблиці отримали значення NULL.

 

Таблиця 8.5 – Результат виконання запиту правого зовнішнього з'єднання

branchNo

hCity

propertyNo

pCity

NULL

NULL

PA14

Aberdeen

В003

Glasgow

PG4

Glasgow

В002

London

PL94

London

 

Приклад повного зовнішнього з'єднання.

Перерахуєте відділення компанії і об'єкти, що здаються в оренду, розташовані в одному і тому ж місті, а також решта всіх відділень і об'єктів власності, що не задовольняють умові запиту.

Використовуємо повне зовнішнє з'єднання цих таблиць, яке виглядає таким чином:

 

SELECT b.*, р.*

FROM Eranch1 b FULL JOIN PropertyForRent p ON b.bCity = p.pCity;

 

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

 

Таблиця 8.6 – Результат виконання запиту повного зовнішнього з'єднання

branchNo

bCity

propertyNo

pCity

NULL

NULL

PA14

Aberdeen

вооз

Glasgow

PG4

Glasgow

В004

Bristol

NULL

NULL

В002

London

PL94

London

 

Ключові слова EXISTS і NOT EXIST.

Ключові слова EXISTS і NOT EXISTS призначені для використання тільки спільно з підзапитами. Результатом їх обробки є логічне значення TRUE або FALSE. Для ключового слова EXISTS результат рівний TRUE в тому і лише в тому випадку, якщо в повертаній підзапитом результуючій таблиці присутній хоч би один рядок. Якщо результуюча таблиця підзапиту порожня, результатом обробки ключового слова EXISTS буде значення FALSE. Для ключового слова NOT EXISTS використовуються правила обробки, зворотні по відношенню до ключового слова EXISTS. Оскільки за ключовими словами EXISTS і NOT EXISTSперевіряється лише наявність рядків в результуючій таблиці підзапиту, то ця таблиця може містити довільну кількість стовпців. Як правило, з метою спрощення у всіх наступних за обговорюваними ключовими словами підзапитах застосовується така форма запису:

(SELECT * FROM . . . )

 

Приклад запиту з використанням ключового слова EXISTS.

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

 

SELECT staffNo, fName, lName, position

FROM Staff s

WHERE EXISTS(SELECT *

FROM Branch b

WHERE s.branchNo = b.branchNo AND city = 'London') ;

 

Цей запит можна перефразовувати таким чином: "Вибрати відомості про всіх працівників, для яких в таблиці Branchіснує запис, що містить той же номер відділення branchNo, який вказаний для даного працівника, і в якій значення стовпцяCity рівне 'London'". Перевірка необхідності включення відомостей про працівника в результуючу таблицю полягає в аналізі існування подібного запису. Якщо вона існує, результат обробки ключового слова EXISTS буде рівний TRUE. Результати виконання запиту представлені в табл. 8.7.

 

Таблиця 8.7 – Результат виконання запиту з використанням ключового слова EXISTS

No

fName

lName

position

SL21

John

White

Manager

3L41

Julie

Lee

Assistant

 

Зверніть увагу, що перша частина умови пошуку, s.branchNo=b.branchNo, необхідна для отримання гарантій того, що для кожного працівника аналізуватиметься коректний рядок даних про відділення компанії. Якщо опустити цю умову, то в результуючу таблицю запиту будуть поміщені зведення про всіх працівників компанії, оскільки підзапит SELECT * FROMBranch WHERE city = 'London' завжди повертатиме не менше одного рядка і перевірка існування в кожному випадку даватиме значення TRUE. В результаті запит матиме наступний вигляд:

 

SELECT staffNo, fName, lName, position

FROM Staff WHERE true;

 

Цей оператор еквівалентний наступному:

 

SELECT staffNo, fName, lName, position FROM Staff;

 

Крім того, даний запит можна записати, використовуючи методи з'єднання:

 

SELECT staffNo, fName, lName, position

FROM Staff s, Branch b

WHERE s.branchNo = b.branchNo AND city = 'London';

 

Комбінування результуючих таблиць (операції UNIONINTERSECT і EXCEPT).

У мові SQL можна використовувати звичайні операції над множинами – об'єднання (union), перетин (intersection) і різниця (difference), – що дозволяють комбінувати результати виконання два і більш за запити в єдину результуючу таблицю.

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

-      Перетином, двох таблиць називається таблиця, що містить всі рядки, присутні в обох початкових таблицях одночасно.

-      Різницею двох таблиць А і В називається таблиця, що містить всі рядки, які присутні в таблиці А, але відсутні в таблиці В.

Всі ці операції над множинами графічно представлені на рис. 8.1. На таблиці, які можуть комбінуватися за допомогою операцій над множинами, накладаються певні обмеження. Найважливіше з них полягає в тому, що таблиці повинні бути сумістиш по з'єднанню – тобто вони повинні мати одну і ту ж структуру. Це означає, що таблиці повинні мати однакову кількість стовпців, причому у відповідних стовпцях повинні розміщуватися дані одного і того ж типу і довжини. Обов'язок переконатися в тому, що значення даних відповідних стовпців належать одному і тому ж домену, покладається на користувача. Наприклад, мало сенсу в тому, щоб об'єднувати стовпець даними про вік працівників з інформацією про кількість кімнат в об'єктах, що здаються в оренду, хоча обидва стовпці матимуть один і той же тип даних – SMALL INT.

 

Рисунок  8.1 – Графічне представлення операцій над множинами (об'єднання, перетин і різниця)

 

Три операції над множинами, передбачені стандартом ISO, носять назву UNIONINTERSECT і EXCEPT. В кожному випадку формат конструкції з операцією над множинами повинен бути наступним:

 

operator [ALL] [CORRESPONDING [BY {column1 [, ...]}]]

 

При вказівці конструкції CORRESPONDING BY операція над множинами виконується для вказаних стовпців. Якщо задано тільки ключове слово CORRESPONDING, а конструкція BY відсутня, операція над множинами виконується для стовпців, які є загальними для обох таблиць. Якщо вказано ключове слово ALL, результуюча таблиця може містити рядки, що повторюються.

Одні діалекти мови SQL не підтримують операцій INTERSECT і EXCEPT, а в інших замість ключового слова EXCEPTвикористовується ключове слово MINUS.

 

Приклад використання операції UNION.

Створіть список всіх регіонів, в яких або знаходиться відділення компанії, або розташовуються об'єкти, що здаються в оренду.

 

(SELECT city            або         (SELECT *

FROM Branch                         FROM Branch

WHERE city IS NOT NULL)             WHERE city IS NOT NULL)

UNION                              UNION CORRESPONDING BY city

(SELECT city                        (SELECT *

FROM PropertyForRent               FROM PropertyForRent

WHERE city IS NOT NULL) ;           WHERE city IS NOT NULL) ;

 

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

Приклад використання операції INTERSECT.

Створіть список всіх міст, в яких розташовуються і відділення компанії, і об'єкти, що здаються в оренду:

 

(SELECT city            або               (SELECT *

FROM Branch)                              FROM Branch)

INTERSECT                                 INTERSECT CORRESPONDING BY city

(SELECT city                              (SELECT *

FROM PropertyForRent)                    FROM PropertyForRent) ;

 

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

Цей запит можна записати і без використання операції INTERSECT:

 

SELECT b.city                       або         SELECT DISTINCT city

FROM Branch b, PropertyForRent p               FROM Branch b

WHERE b.city = p.city;                         WHERE EXISTS{SELECT *

FROM PropertyForRent p                         WHERE p.city = b.city) ;

 

Одним з найістотніших недоліків мови SQL є те, що він дозволяє створювати запити в декількох еквівалентних формах.

 

Приклад використання операції EXCEPT.

Створіть список всіх міст, в яких є відділення компанії, але немає об'єктів, що здаються в оренду:

 

(SELECT city            або         (SELECT *

FROM Branch)                        FROM Branch)

EXCEPT                              EXCEPT CORRESPONDING BY city

(SELECT city                        (SELECT *

FROM PropertyForRent);             FROM PropertyForRent);

 

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

Цей запит можна записати і без використання операції EXCEPT:

 

SELECT DISTINCT city         або         SELECT DISTINCT city

FROM Branch                               FROM Branch b

WHERE city NOT IN                         WHERE NOT EXISTS

(SELECT city                              (SELECT *

FROM PropertyForRent};                   FROM PropertyForRent p

WHERE p.city = b.city);

Зміна вмістимого бази даних.

Для зміни вмістимого бази даних в мові SQL є три інструкції:

–       INSERT – добавлення нових записів;

–       UPDATE – модифікація існуючих даних;

–       DELETE – видалення записів з таблиці.

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

Даний оператор має дві форми запису. Перша форма дозволяє вказати значення для добавлення в конкретні поля нового запису.

INSERT INTO table_name [(column_list)]

VALUES (data_values_list);

Тут column_list – список полів таблиці, а data_values_list – список значень цих полів. На ці списки накладаються такі обмеження:

–       кількість елементів в обох списках має бути однаковим;

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

–       типи даних елементів в обох списках повинні бути сумісними;

–       якщо список полів не вказано, то список даних повинен містити значення всіх полів в тому порядку, в якому вони слідують в таблиці.

Інша форма запису інструкції INSERT дозволяє скопіювати множину стрічок однієї таблиці в іншу (таблиці мають бути сумісні по об'єднанню).

INSERT INTO table_name [(column_list)]

SELECT ... ;

Інструкція SELECT може бути будь-яким допустимим оператором SELECT. Рядки, отримані в результаті роботи підзапиту SELECT, повинні точно співпадати зі списком полів інструкції INSERT.

Модифікація існуючих даних здійснюється за допомогою оператора UPDATE. Синтаксис цього оператора наступний:

UPDATE table_name

SET column_name=data_value1 [, column_name2=data_value2…]

[WHERE search_condition];

Тут параметр table_name означає ім’я таблиці, column_name – ім’я стовпця таблиці, data_value1 – значення, котре потрібно записати у цей стовпець. Якщо фраза WHERE не вказана, то нові значення будуть записані у вказані стовпці ВСІЄЇ таблиці, в протилежному випадку – тільки у тих рядках, які задовольняють вказаній умові (search_condition).

Видалення запису з таблиці бази даних здійснює оператор DELETE. Синтаксис його запису наступний:

DELETE FROM table_name

[WHERE search_condition];

Зміст параметрів цього запиту такий же, що і в попередньому запиту UPDATE. Якщо умова відбору записів не вказана, то буде витерте вмістиме ВСІЄЇ таблиці. В іншому випадку витираються тільки ті записи, які задовольняють вказаній умові. Слід зауважити, що коли з таблиці витерти всі записи, то це не означає витирання всієї таблиці. Таблиця, навіть порожня, все одно залишається в базі даних. Для знищення таблиці призначені інші інструкції означення даних мови SQL, про які йдеться у лекціях, що стосуються DDL (data definition language – мова означення даних).

 

Тема 9 Створення бази даних та її елементів засобами SQL

 

Створення бази даних в різних СУБД може мати свої особливості. Як правило, це фрази

 

CREATE SCHEMA [name | AUTHORIZATION creator_identifier];

 

або

 

CREATE DATABASE database_name;

 

Для знищення бази даних використовують фразу

 

DROP SCHEMA name [RESTRICT | CASCADE];

 

або

 

DROP DATABASE name;

 

Ім’я бази даних – це ім’я файлу або ім’я каталогу, де вона розміщена. Наприклад, для MS Access, Interbase – це файл, для Paradox – це каталог.

 

9.1 Створення таблиць

 

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

Створення таблиці:

 

CREATE TABLE table_name (column_name data_type [NULL | NOT NULL][,…]);

 

В результаті виконання створиться таблиця, що складається з полів, вказаних у списку column_name. Тип поля вказується параметром data_type. Це може бути CHAR, VARCHAR, BIT, BIT VARYING, NUMERIC, DECIMAL, INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION, DATA, TIME, TIMESTAMP, INTERVAL. Розмір поля вказується у дужках після вказання типу значень. Вказання NOT NULL означає. що значення поля є обов’язковим для вводу. NULL означає допустимість невведеного значення поля і прийнято за замовчуванням.

 

9.1.1 Забезпечення цілісності даних

Забезпечення цілісності даних включає наступні пункти:

-       обов’язкові дані;

-       обмеження для доменів атрибутів;

-       цілісність сутностей;

-       цілісність посилань;

-       вимоги конкретного підприємства.

Більша частина цих обмежень задається у операторах створення таблиці CREATE TABLE та зміни структури існуючої таблиці ALTER TABLE.

Обов’язкові дані задаються вказанням фрази NOT NULL описі поля при створенні таблиці.

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

Наприклад, для задання вводу в поле, що означає стать, лише двох значень "М" або "Ж", при створенні таблиці можна записати

 

sex CHAR NOT NULL CHECK (sex IN ('M','Ж'));

 

Другий спосіб – створення домену:

 

CREATE DOMAIN domain_name [AS] data_type

[DEFAULT default_option]

[CHECK (search_condition)]

 

Кожному створюваному домену присвоюється ім’я domain_name, тип даних data_type, значення за замовчуваннямdefault_option, та набір допустимих значень search_condition. Те саме задання обмежень, наведене в попередньому прикладі, можна записати так:

 

CREATE DOMAIN sex_type AS CHAR

DEFAULT 'M'

CHECK (VALUE IN('М','Ж'));

 

Тоді при описі поля в таблиці вказується вже створений домен:

 

sex SEX_TYPE NOT NULL;

 

Фраза search_condition може бути запитом SELECT до іншої таблиці, яка містить поле із допустимим набором значень.

Витирання домену виконує запит

 

DROP DOMAIN domain_name [RESTRICT | CASCADE]

 

Цілісність сутностей означає задання первинного ключа для таблиці. Задання первинного ключа виконує фразаPRIMARY KEY (field_name) при створенні таблиці. Зрозуміло, що задання первинного ключа в таблиці робиться тільки один раз. Для гарантування унікальності значень альтернативних ключів таблиці використовується фраза UNIQUE(column_name_list). Рекомендується використовувати для полів з унікальними значеннями фразу NOT NULL. Наприклад,

 

rno VAR CHAR(5) NOT NULL,

pno VAR CHAR(5) NOT NULL,

UNIQUE (rno,pno)

 

Цілісність посилань означає створення зв’язків між таблицями по полю. В одній з таблиць це поле є зовнішнім ключем, а в другій – альтернативним. Друга таблиця буде головною по відношенню до першої. Задання цілісності посилань означає вказання у таблиці зовнішнього ключа за допомогою фрази

FOREING KEY (field_name) REFERENCES main_table_name

Тепер система відхилить спроби добавити до підлеглої таблиці записи, у яких значення зовнішнього ключа не мають своїх відповідників у головній таблиці. Дії системи при витиранні записів DELETE чи зміні UPDATE залежать від правил, заданих у фразах ON DELETE і ON UPDATE речення FOREING KEY. Можливі варіанти:

CASCADE – витирання/поновлення каскадним способом;

SET NULL – встановлення при витиранні/поновленні значення NULL;

SET DEFAULT – встановлення значення за замовчуванням при витиранні/поновленні;

NO ACTION – ніяких дій.

Отже повна фраза задання зовнішнього ключа виглядає так:

 

FOREING KEY (field_name) REFERENCES main_table_name ON UPDATE action ON DELETE action

 

Обмеження даних у таблицях можуть диктуватись ще і вимогами даного підприємства, для якого ведеться база даних. Ці обмеження можна задати фразами CHECK та UNIQUE. Є ще один спосіб – фраза

 

CREATE ASSERTION assertion_name CHECK (search_condition)

 

9.1.2 Вказання цілісності даних при створенні таблиці

Отже, повний формат оператора створення таблиці:

 

CREATE TABLE table_name

{(column_name data_type [NOT NULL][UNIQUE]

[DEFAULT default_option][CHECK(search_option)][,…]}

[PRIMARY KEY (list_of_columns),]

{UNIQUE (list_of_columns),][,…]}

{[FOREING KEY (list_of_foreing_key_columns)

REFERENCES parent_table_name [(list_of_candidate_key_columns)],

[MATCH {PARTIAL | FULL}

[ON UPDATE referential_action]

[ON DELETE referential_action ]][,…]}

{[CHECK (search_condition)][,…]})

 

Якщо list_of_candidate_key_columns не вказано, то вважається, що береться первинний ключ.

Обмеження для таблиці (фразу CHECK) можна проіменувати з метою звертання до нього по імені за допомогою фразиCONSTRAINT constraint_name.

Знищення таблиці виконується за допомогою запиту

 

DROP TABLE table_name [RESTRICT | CASCADE];

 

Вказання слова RESTRICT означає заборону знищення таблиці поки існують залежні від неї об’єкти (прийнято за замовчуванням). Слово CASCADE означає каскадне витирання всіх залежних об’єктів перед витиранням таблиці. Запит на знищення таблиці застосовується, як правило, при виправленні помилок неправильно створеної таблиці. Тоді просто таблицю неправильної структури витирають, а потім створюють нову з таким же іменем.

 

9.2 Створення індексів

 

Створення індексу

 

CREATE [UNIQUE] INDEX index_name ON table_name (column [ASC | DESC][,…]);

 

У таблиці table_name буде створено індекс з іменем index_name, що складається з полів column, сортування здійснюватиметься у зростаючому ASC (прийнято за замовчуванням) чи у спадаючому DESC порядку. Якщо вказаноUNIQUE, то значення у індексному полі мають бути унікальними у кожному записі таблиці.

Знищення індексу

 

DROP INDEX index_name;

 

 

9.3 Зміна структури бази даних та її лементів

 

Зміна таблиці допускає наступні дії:

-       добавлення стовпця;

-       видалення стовпця;

-       добавлення до таблиці нового обмеження;

-       видалення існуючого обмеження;

-       задання для стовпця значення за замовчуванням;

-       відміна значення за замовчуванням для стовпця.

 

ALTER TABLE table_name

[ADD [COLUMN] column_name data_type [NOT NULL] [UNIQUE]

   [DEFAULT default_option] [CHECK (search_condition)]]

[DROP [COLUMN] column_name [RESTRICT | CASCADE]]

[ADD [CONSTARINT [constraint_name]] table_constraint_definition]

[DROP CONSTRAINT constraint_name [RESTRICT | CASCADE]]

[ALTER [COLUMN] SET DEFAULT default_option]

[ALTER [COLUMN] DROP DEFAULT]

 

Тут параметри мають те ж саме значення, що і в операторі створення таблиці. Фраза table_constraint_definition може бути однією із фраз PRIMARY KEYUNIQUEFOREING KEYCHECK. Фраза ADD [COLUMN] має такий же формат, що і опис стовпця у операторі створення таблиці. Витирання стовпця може супроводжуватись вказанням, чи робити каскадне витирання залежних стовпців інших таблиць від даного чи заборонити таке витирання, поки є залежні стовпці.

Деякі діалекти SQL не підтримують фрази ALTER TABLE. Тоді потрібно скористатись тимчасовим файлом для зберігання таблиці для зміни, витерти цю таблицю, створити нову потрібної структури з тим же іменем, переписати за допомогою інструкцій INSERT та SELECT дані з тимчасового файлу.

 

9.4 Створення та використання переглядів

 

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

Перегляд (VIEW) (інша назва "перегляд" чи "подання") це об'єкт даних, який не містить ніяких даних його власника. Це тип таблиці, чий зміст вибирається з інших таблиць за допомогою виконання запиту. У міру зміни значень в таблицях, ці зміни автоматично відбиваються у представленні.

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

Таблиці, з якими ви мали справу до цих пір, називалися базовими таблицями. Це таблиці, які містять дані. Проте є інший вид таблиць – представлення. Представлення – це таблиці, чий зміст вибирається або виходить з інших таблиць. Вони працюють в запитах і операторах DML точно так само, як і базові таблиці, але не містять ніяких власних даних.

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

 

9.4.1 Команда CREATE VIEW

Ви створюєте представлення командою CREATE VIEW. Вона складається із слів CREATE VIEW (СТВОРИТИ ПРЕДСТАВЛЕННЯ), імені представлення, яке потрібно створити, слова AS (ЯК) і запиту, як в наступному прикладі:

 

       CREATE VIEW Londonstaff

          AS SELECT *

          FROM Salespeople

          WHERE city = 'London';

 

Тепер у вас є представлення Londonstaff. Ви можете використовувати це представлення точно так, як і будь-яку іншу таблицю. Може бути виконаний запит, модифікація, вставка в, видалення з і з'єднання з іншими таблицями і представленнями.

Давайте зробимо запит представлення (вивід показаний нижче запиту):

 

            SELECT *

               FROM Londonstaff;

 

 

         ===============  SQL Execution Log ============

        |                                               |

        | SELECT *                                      |

        | FROM  Londonstaff;                            |

        |                                               |

        | ==============================================|

        |   snum      sname         city         comm   |

        | ------    ----------   -----------   -------  |

        |   1001      Peel         London       0.1200  |

        |   1004      Motika       London       0.1100  |

        |                                               |

         ===============================================

 

Коли ви наказуєте SQL вибрати (SELECT) всі рядки (*) з представлення, він виконує запит, що містить у визначенні Londonstaff,  і повертає все з його виводу. Маючи предикат в запиті представлення, можна вивести тільки ті рядки представлення, які задовольнятимуть цьому предикату. Ви можете пригадати, що в розділі 15 ви мали таблицю Londonstaff, в яку ви вставляли цей же самий вміст (звичайно, ми розуміємо, що таблиця не дуже велика. Якщо це так, ви повинні будетевибрати інше ім'я для вашого представлення).

Перевага використання представлення, в порівнянні з основною таблицею, в тому, що представлення буде модифіковано автоматично всякий раз, коли зміниться таблиця, лежача в його основі.

Зміст представлення не фіксований і перепризначувався кожного разу, коли ви посилаєтеся на представлення в команді. Якщо ви додасте завтра іншого продавця, що живе в Лондоні, він автоматично з'явиться в представленні.

Представлення значно розширюють управління вашими даними. Це чудовий спосіб дати публічний доступ до деякої, але не всій, інформації в таблиці. Якщо ви хочете, щоб ваш продавець був показаний в таблиці Продавців, але при цьому не були показані комісійні інших продавців, ви могли б створити представлення з використанням наступного оператора (вивід показаний нижче запиту):

 

       CREATE VIEW Salesown

          AS SELECT snum, sname, city

          FROM Salespeople:

 

             ===============  SQL Execution Log ============

            |                                               |

            | SELECT *                                      |

            | FROM  Salesown;                               |

            |                                               |

            | ==============================================|

            |   snum      sname         city                |

            | ------    ----------   -----------            |

            |   1001      Peel         London               |

            |   1002      Serres       San Jose             |

            |   1004      Motika       London               |

            |   1007      Rifkin       Barcelona            |

            |   1003      Axelrod      New York             |

             ===============================================

 

Іншими словами, це представлення - таке ж, як для таблиці Продавців, за винятком того що поле comm не згадувалося в запиті і, отже, не було включено в представлення.

 

9.4.2 Модифікація представлень

Представлення може тепер змінюватися командами модифікації DML, але модифікація не впливатиме на само представлення. Команди будуть насправді перенаправлені в базову таблицю:

 

         UPDATE Salesown

            SET city = 'Palo Alto'

            WHERE snum = 1004;

 

Його дія ідентична виконанню тієї ж команди в таблиці Продавців. Проте, якщо значення комісійних продавця буде оброблено командою UPDATE

 

         UPDATE Salesown

            SET comm = .20

            WHERE snum = 1004;

 

вона буде знехтувана, оскільки поле comm відсутнє в представленні Salesown. Це важливе зауваження, що показує, що не всі представлення можуть бути модифіковані. Проблеми модифікації (оновлення) переглядів розглянуто у темі про реляційні операції.

У нашому прикладі поля наших представлень мають свої імена, отримані прямо з імен полів основної таблиці. Це зручно. Проте вам потрібно забезпечити ваші стовпці новими іменами:

  • коли деякі стовпці є такими, що виводяться, і тому що не мають імен.
  • коли два або більш за стовпці в об'єднанні мають ті ж імена, що в їх базовій таблиці.

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

 

9.4.3 Комбінування предикатів представлень і основних запитів в представленнях

Коли ви робите запит представлення, ви, власне, виконуєте запит. Основний спосіб для SQL обійти це - об'єднати предикати двох запитів в один. Давайте подивимося ще раз на наше представлення Londonstaff:

 

         CREATE VIEW Londonstaff

            AS SELECT *

            FROM Salespeople

            WHERE city = 'London';

 

Якщо ми виконуємо наступний запит в цьому представленні

 

         SELECT *

           FROM Londonstaff

           WHERE comm > .12;

 

він буде таким же, неначебто ми виконали наступне в таблиці Продавців:

 

       SELECT *

          FROM Salespeople

          WHERE city = 'London'

          AND comm > .12;

 

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

 

       CREATE VIEW Ratingcount (rating, number)

          AS SELECT rating, COUNT (*)

          FROM Customers

          GROUP BY rating;

 

Це дає нам число замовників, яке ми маємо для кожного рівня оцінки (rating). Ви можете потім зробити запит цього представлення, щоб з'ясувати, чи є яка-небудь оцінка в даний час, призначена для трьох замовників:

 

       SELECT *

          FROM Ratingcount

          WHERE number = 3;

 

Подивимося, що трапиться якщо ми скомбінуємо два предикати:

 

       SELECT rating, COUNT (*)

          FROM Customers

          WHERE COUNT (*) = 3

          GROUP BY rating;

 

Це неприпустимий запит. Агрегатні функції, такі як COUNT (РАХУНОК), не можуть використовуватися в предикаті. Правильним способом при формуванні вищезазначеного запиту, звичайно ж, буде наступний:

 

        SELECT rating, COUNT (*)

           FROM Customers

           GROUP BY rating;

           HAVING COUNT (*) = 3;

 

Але SQL може не виконати перетворення. Чи може рівноцінний запит замість запиту Ratingcount потерпіти невдачу? Та може! Це неоднозначна область SQL, де методика використання представлень може дати добрі результати. Найкраще, що можна зробити у разі, коли про це нічого не сказано у вашій системній документації, це спробувати розібратися.

Якщо команда допустима, ви можете використовувати представлення, щоб встановити деякі обмеження SQL в синтаксисі запиту.

 

9.4.4 Групові представлення

Групові представлення це представлення, на зразок запиту Ratingcount в попередньому прикладі, які містять пропозицію GROUP BY або які грунтуються на інших групових представленнях.

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

Чим конструювати кожного разу складний запит, ви можете просто створити наступне представлення:

 

   CREATE VIEW Totalforday

        AS SELECT odate, COUNT (DISTINCT cnum), COUNT

                (DISTINCT snum)COUNT (onum), AVG

                (amt)SUM (amt)

                FROM Orders

        GROUP BY odate;

 

Тепер ви зможете побачити всю цю інформацію за допомогою простого запиту:

 

         SELECT *

            FROM Totalforday;

 

Як ми бачили, SQL-запросы можуть дати вам повний комплекс можливостей, так що представлення забезпечують вас надзвичайно гнучким і могутнім інструментом щоб визначити точно, як ваші дані можуть бути використані.

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

 

9.4.5 Представлення і об'єднання

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

 

       CREATE VIEW Nameorders

          AS SELECT onum, amt, а.snum, sname, cname

             FROM Orders а, Customers b, Salespeople з

             WHERE а.cnum = b.cnum

               AND а.snum = з.snum;

 

Тепер ви можете вибрати (SELECT) всі замовлення замовника або продавця (*), або можете побачити цю інформацію для будь-якого замовлення.

 

Наприклад, щоб побачити всі замовлення продавця Rifkin, ви повинні ввести наступний запит (вивід показано нижче запиту):

 

          SELECT *

             FROM Nameorders

             WHERE sname = 'Rifkin';

 

            ===============  SQL Execution Log ==============

           |                                                 |

           | SELECT *                                        |

           | FROM  Nameorders                                |

           | WHERE sname = 'Rifkin';                         |

           | =============================================== |

           |   onum       amt       snum   sname     cname   |

           |  ------   --------    -----  -------   -------  |

           |   3001       18.69     1007  Rifkin    Cisneros |

           |   3006     1098.16     1007  Rifkin    Cisneros |

           |                                                 |

             ================================================

 

Ви можете також об'єднувати представлення з іншими таблицями, базовими таблицями або представленнями, тому ви можете побачити всі замовлення продавця Axelrod і значення його комісійних в кожному порядку:

 

           SELECT а.sname, cname, amt  comm

              FROM Nameorders а, Salespeople b

              WHERE а.sname = 'Axelrod'

                AND b.snum = а.snum;

 

Вивід для цього запиту показаний нижче. У предикаті ми могли б написати: "WHERE а.sname = 'Axelrod' AND b.sname = 'Axelrod'", але предикат, який ми використовували тут, більш загальновживаний. Крім того, поле snum це первинний ключ таблиці Продавців, і, отже, повинно, за визначенням, бути унікальним.

            ===============  SQL Execution Log ==============

           |                                                 |

           | SELECT а.sname, cname, amt * comm               |

           | FROM  Nameorders а, Salespeople b               |

           | WHERE а.sname = 'Axelrod'                       |

           | AND b.snum = а.snum;                            |

           | =============================================== |

           |   onum       amt       snum   sname     cname   |

           |  ------   --------    -----  -------   -------  |

           |   3001       18.69     1007  Rifkin    Cisneros |

           |   3006     1098.16     1007  Rifkin    Cisneros |

           |                                                 |

             ================================================

 

Якби там, наприклад, було два Axelrod, варіант з ім'ям об'єднуватиме разом їх дані. Переважніший варіант – використовувати поле snum, щоб зберігати його окремо.

 

9.4.6 Представлення і підзапити

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

 

           CREATE VIEW Elitesalesforce

              AS SELECT b.odate, а.snum, а.sname,

                 FROM Salespeople а, Orders b

                 WHERE а.snum = b.snum

                   AND b.amt =

                     (SELECT MAX (amt)

                         FROM Orders с

                         WHERE с.odate = b.odate);

 

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

 

            CREATE VIEW Bonus

               AS SELECT DISTINCT snum, sname

                  FROM Elitesalesforce а

                  WHERE 10 < =

                     (SELECT COUNT (*)

                         FROM Elitesalestorce b

                         WHERE а.snum = b.snum);

 

Витягання з цієї таблиці продавця, який отримуватиме премію, виконується простим запитом:

 

               SELECT *

                  FROM Bonus;

 

Тепер ми бачимо дійсну потужність SQL. Витягання тієї ж отриманої інформації програмами RPG або COBOL буде тривалішою процедурою. У SQL це - тільки питання з двох комплексних команд, збережених як представлення сумісне з простим запитом. При самостійному запиті ми винні піклується про це щодня, тому що інформація яку витягує запит, безперервно міняється, щоб відображати поточний стан бази даних.

 

9.4.7 Що не можуть робити представлення?

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

Одиночне представлення повинне грунтуватися на одиночному запиті.

Об'єднання (UNION) не дозволяється.

Впорядкування (ORDER BY) ніколи не використовується у визначенні представлень.

Вивід запиту формує зміст представлення, яке нагадує базову таблицю і є, – за визначенням – невпорядкованим.

 

9.4.8 Видалення представлень

Синтаксис видалення представлення з бази даних подібний до синтаксису видалення базових таблиць:

 

DROP VIEW <ім'я представлення>

 

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

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

Є один головний висновок щодо представлень: це здатність до модифікації.

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

Тема 11 Поняття про транзакції та їх підтримка

 

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

 

11.1 Поняття про транзакції

 

Транзакція – дія чи послідовність дій, котрі виконуються одним користувачем чи прикладною програмою, що виконують доступ та/або зміну вмістимого БД.

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

Кожна транзакція переводить БД з одного узгодженого стану у інший, хоча під час виконання самої транзакції ця узгодженість може порушуватись. Будь-яка тарнзакція може завершитись одним із двох можливих результатів. В разі успішного виконання всіх операцій транзакції її результати фіксуються (commit) у БД і вона (база даних) переходить у новий узгоджений стан. Коли транзакція повністю не виконується, то всі її дії відміняються. У цьому випадку в БД має бути відновлено той узгоджений стан, в якому вона перебувала до початку транзакції. Цей процес називається відкатом (rollback) транзакції (рисунок 11.1). Зафіксована транзакція не може бути відмінена. Якщо потрібно все ж таки зробити відміну зафіксованої транзакції, то має бути запущена інша транзакція, яка виконує таку дію і називається компенсуючою.

Рисунок 11.1 – Схема виконання транзакцій

 

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

Властивості транзакцій:

-          атомарність: це властивість типу „все чи нічого”. Кожна транзакція є неподільною частиною роботи, котра може бути або виконана повністю, або не виконана зовсім;

-          узгодженість: кожна транзакція переводить БД з одного узгодженого стану у інший;

-          ізольованість: всі транзакції виконуються незалежно одна від одної. Тобто проміжні результати однієї транзакції не повинні бути доступні для іншої;

-          тривалість: результати кожної зафіксованої транзакції не повинні бути втрачені під час наступних збоїв.

Наведений перелік властивостей транзакцій в англомовній літературі носить назву ACID (Atomicity, Consistency, Isolation, Durability).

 

11.2  Керування паралельністю

 

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

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

Дана проблема притаманна багатьом задачам, що стоять при організації роботи кожної багатокористувацької системи. Існує три види проблем при паралельному виконанні транзакцій:

1 – проблема втраченого поновлення,

2 – проблема залежності від незафіксованих результатів і

3 – проблема неузгодженої обробки.

Проблема втраченого поновлення полягає в тому, що результати роботи однієї транзакції можуть бути перекриті результатами іншої, котра почалась паралельно з першою.Наприклад, перша транзакція виконує зменшення суми рахунку, на якому було 100 грн.,  на 10 грн., а друга збільшує рахунок цей же рахунок на 100 грн. Коли ці транзакції виконуються окремо в часі, то незалежно від порядку їх виконання кінцева сума має становити 190 грн. Коли ж друга транзакція почнеться одночасно з першою, то обидві вони зчитають початкову суму (100 грн.) і існує можливість, коли друга транзакція завершиться швидше, тобто збільшить суму до 200 грн. і помістить результат у БД. Перша транзакція виконає зменшення суми на 10 грн. і потім помістить суму 90 грн. у це ж поле того ж запису БД (в котре вже записано значення 200). Тобто перша транзакція перекриє роботу другої. Усунення проблеми полягає у забороні початку виконання однієї транзакції до завершення (фіксації чи відкату) другої (рисунок 11.2).

 

Рисунок 11.2 – Проблема втраченого поновлення

 

Проблема залежності від незафіксованих результатів полягає в тому, що одна транзакція може отримати доступ до проміжних даних другої. Наприклад, в ситуації з тим же рахунком з сумою у 100 грн. перша транзакція (зменшення суми на 10 грн.) завершилась відкатом (причини відкату зараз значення не мають), але друга (збільшення суми на 100 грн.) вже встигла прочитати значення у 90 грн., хоча після відкату першої в полі БД має бути значення 100. Тому в результаті виконання другої транзакції в БД міститиметься значення 190 грн. замість правильного 200. Шлях усунення проблеми – заборона початку однієї транзакції до завершення другої.

 

Рисунок 11.3 – Проблема залежності від незафіксованих результатів

 

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

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

Існує два види графіків.

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

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

1.      Якщо транзакції тільки зчитують елемент даних, то можливе їхнє паралельне виконання.

2.      Якщо транзакції змінюють незалежні елементи даних, то допустиме їхнє паралельне виконання.

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

 

Рисунок 11.4 – Послідовний та непослідовний графіки виконання транзакцій

 

Виходячи з наведених міркувань, існують дві групи методів керування паралельністю – консервативні (песимістичні) та оптимістичні.

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

Блокування – це процедура, що використовується для паралельного доступу до даних. Коли якась транзакція отримує доступ до БД, механізм блокування дозволяє відхилити спроби інших транзакцій отримати доступ до тих самих елементів (рисунок 11.5).

 

Рисунок 11.5 – Взаємоблокування транзакцій

 

Розрізняють блокування для запису та блокування для читання.

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

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

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

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

Наприклад, коли транзакція Т1 з часовою відміткою ts1 намагається прочитати значення х, яке вже змінене (перезаписане) іншою транзакцією Т2 з часовою відміткою ts2, при чому ts1<ts2, то транзакція Т1 буде відмінена.

Інший випадок. Транзакція Т1 з часовою відміткою ts1 намагається записати значення х, яке вже прочитано (або змінено) іншою транзакцією Т2 з часовою відміткою ts2, при чому ts1<ts2. Тоді виходить, що транзакція Т1 змінить значення, використане в Т2 (помістить в х застаріле значення – порушить принцип тривалості тразакцій). Зрозуміло, що транзакція Т1 має бути відмінена та перезапущена з новою часовою відміткою.

Якщо транзакції відмовлено у доступі до даних, то вона відміняється і перезапускається з новою часовою відміткою (рисунок 11.6).

 

Рисунок 11.6 – Перезапуск транзакції з новою часовою відміткою

 

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

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

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

3.      Фаза запису. Ця фаза виконується тільки для транзакцій, що містять операції поновлення.

При проектуванні транзакцій важливе значення має також вибір рівня деталізації. Тобто мінімальний розмір даних, який вибирається для виконання транзакції. Цей вибір має значний вплив на продуктивність всієї системи БД. В якості одиниці даних може бути вибрана вся база даних, окрема таблиця, окрема сторінка БД (інколи називається окремий блок БД – сектор на диску), окремий запис, окреме поле запису.

 

11.3 Відновлення баз даних

 

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

Транзакції є основною одиницею відновлення у системах з базами даних. Транзакція повинна бути відмінена, якщо вона не була закінчена до настання збою. Повторне виконання транзакції виникає для тих з них, котрі завершились  до настання збою, але котрі ще не були записані з оперативної пам’яті (буферу) на диски.

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

Резервне копіювання може виконуватись для всієї бази даних, а також для її окремих частин. Як правило, резервні копії створюються на автономних носіях.

Ведення файлу журналу здійснюється для фіксації виконаних транзакцій. А саме: ідентифікатор транзакції, тип транзакції (читання, вставка, поновлення), ідентифікатор елементу даних – об’єкту транзакції, копія елементу даних до транзакції, копія елементу даних після транзакції, записи контрольних точок. Рекомендується також вести файл журналу на окремому від самої БД диску з метою уникнення одночасного пошкодження і бази даних, і файлу журналу.

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

Який із способів відновлення БД вибрати – відновлення з резервної копії чи відновлення на основі файлу журналу – залежить від характеру пошкодження БД.

 

11.4 Керування транзакціями засобами мови SQL

 

В мові SQL введено автоматичну підтримку транзакцій кожна з яких починається автоматично при виконанні запитівSELECTINSERTUPDATE. Зміни заносяться в базу даних при успішному виконанні цих запитів. Для "ручного" керування транзакціями мова SQL містить такі службові слова:

COMMIT – фіксація результатів роботи транзакції.

ROLLBACK – відкат транзакції.

Використання вкладених транзакцій не підтримується всіма діалектами мови SQL. З допомогою оператора SET TRANSACTION можна налаштувати певні аспекти процедури виконання транзакції. Цей оператор повинен бути один на транзакцію, тобто після слів COMMIT чи ROLLBACK, що завершали попередню транзакцію, до наступного слова COMMIT чиROLLBACK, які завершують дану транзакцію. Формат цього оператора:

SET TRANSACTION

[READ ONLY | READ WRITE]

[ISOLATION LEVEL READ UNCOMMITTED | READ COMMITTED |

REPEATABLE READ | SERIALIZABLE]

Кваліфікатори READ ONLY та READ WRITE означають допустимість у транзакції операцій тільки читання або читання і запису відповідно. Далі можна вказати один з чотирьох рівнів ізоляції.

READ UNCOMMITTED – немає ізоляції транзакцій; дозволяється читання даних незавершених транзакцій іншими транзакціями. Використовуєься, коли потрібні лише приблизні дані.

READ COMMITTED – "чорнове" читання. Зміни, внесені однією транзакцією, залишаються невидимими для інших транзакцій, поки перша не буде завершена оператором COMMIT. Існує небезпека повторного читання – тобто читання даних, які вже змінені, недостовірні.

REPEATABLE READ – повторне читання усувається, але можуть виникати так звані "фантомні значення" – коли при різних доступах в межах однієї транзакції до одного і того ж набору даних інша транзакція може змінити цей набір.

SERIALIZABLE – найвищий рівень ізоляції, коли кожна транзакція виконується послідовно одна за одною. Тут найнижча продуктивність системи.

Деколи виникають ситуації, коли не потрібно робити відкат всієї транзакції, а тільки ї частини. В новому стандарті SQL:1999 для цієї мети введені оператори

SAVEPOIN name_of_save_point

та

ROLLBACK TO SAVEPOINT name_of_save_point

Перший з них дозволяює встановити проміжну точку відкату, до котрої можна повернутися за допомогою другого оператора. Цю можливість на даний час підтримують не всі діалекти SQL.

Перевірка цілісності даних виконується після виконання кожного запиту SQL. Інколи таку провірку треба виконувати тільки в кінці всієї транзакції. Для цього існує оператор

SET CONSTRAINTS

{ALL | constraint_name [,…]}{DEFFERED | IMMEDIATE}

Якщо вказано слово DEFFERED, то перевірка цілісності даних виконується в кінці транзакції. Інакше – негайно, тобто під час виконання транзакції (цей режим включено за замовчуванням).

 

2.9 Розподілені БД

 

13.1 Вступ

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

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

 

13.1.1. Основні концепції

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

 

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

З цього витікає наступне визначення.

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

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

Користувачі взаємодіють з розподіленою базою даних через програми (застосування). Застосування можуть бути класифіковані як ті, які не вимагають доступу до даних на інших сайтах (локальні застосування), і ті, які вимагають подібного доступу (глобальні застосування). У розподіленій СКБД повинно існувати хоча б одне глобальне застосування, тому будь-яка СКРБД повинна мати наступні особливості.

·          Набір логічно пов'язаних розподіоених даних.

·          Дані, що зберігаються, розбиті на деяку кількість фрагментів.

·          Між фрагментами може бути організована реплікація даних. Фрагменти і їх репліки розподілені по різних сайтах.

·          Сайти пов'язані між собою мережевими з'єднаннями.

·          Робота з даними на кожному сайті управляється СКБД.

·          СКБД на кожному сайті здатна підтримувати автономну роботу локальних застосувань.

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

 

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

19_1

Рисунок 13.1 – Топологія   системи   управління розподіленою базою даних

 

Приклад розподіленої обробки даних.

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

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

Розподілена обробка

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

Розподілена обробка – Обробка з використанням централізованої бази даних, доступ до якої може здійснюватися з різних компьютерів мережі.

Паралельні СКБД

Крім того, слід чітко розуміти відмінності, існуючі між розподіленими і паралельними СКБД.

Паралельна СКБД – Система управління базою даних, що функціонує з використанням декількох процесорів і пристроїв жорстких дисків, що дозволяє їй (якщо це можливо) розпаралелювати виконання деяких операцій з метою підвищення загальної производи-тельности обробки.

 

13.1.2. Переваги і недоліки, властиві розподіленим СКБД

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

Переваги

Віддзеркалення структури організації

Подільність і локальна автономність

Підвищення доступності даних

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

Підвищення надійності

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

Підвищення продуктивності

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

Економічні вигоди

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

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

Модульність системи

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

Недоліки

Підвищення складності

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

Збільшення вартості

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

Проблеми захисту

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

Ускладнення контролю за цілісністю даних

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

Відсутність стандартів

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

Недолік досвіду

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

Ускладнення процедури розробки бази даних

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

Усі переваги і недоліки, властиві розподіленим СКБД, перераховані в таблиці. 13.1.

 

Таблиця 13.1 – Переваги і недоліки розподілених СКБД

Переваги

Недоліки

Відображення структури організації

Підвищення складності

Разделяемость і локальна автономність

Збільшення вартості

Підвищення доступності даних

Проблеми захисту

Підвищення надійності

Ускладнення контролю за цілісністю даних

Підвищення продуктивності

Відсутність стандартів

Економічні вигоди

Недолік досвіду

Модульність системи

Ускладнення процедури розробки бази даних

 

13.1.3. Гомогенні і гетерогенні розподілені СКБД

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

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

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

·          інший тип використовуваного устаткування;

·          інший тип використовуваної СКБД;

·          інший тип використовуваного устаткування і СКБД.

                    Якщо використовується інший тип устаткування, проте на сайті встановлений той же самий тип СКБД, методи виконання трансляції цілком очевидні і включають заміну кодів і зміну довжини слова. Якщо типи використовуваних на сайтах СКБД різні, процедура трансляції ускладнюється тим, що необхідно відображувати структури даних однієї моделі у відповідні структури даних іншої моделі. Наприклад, відношення в реляційній моделі даних мають бути перетворені в записи і набори, типові для мережевої моделі даних. Крім того, потрібно буде транслювати текст запитів з однієї використовуваної мови на іншій (наприклад, запити SQL-оператор SELECT потрібно буде перетворити в запити з операторами FIND і GET мови маніпулювання даними сіткової СКБД). Якщо відрізняються і тип використовуваного устаткування, і тип програмного забезпечення, потрібно буде виконувати обидва види трансляції. Усе викладене вищеназвичайно ускладнює обробку даних в гетерогенних СКБД.

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

13.4. Розробка розподілених реляційних баз даних

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

·          Фрагментація. Будь-яке відношення може бути розділене на деяку кількість частин, які називаютьсяфрагментами, які потім розподіляються по різних сайтах. Існують два основні типи фрагментів: горизонтальні і вертикальні. Горизонтальні фрагменти є підмножинами кортежів, а вертикальні – підмножини атрибутів.

·          Розподіл. Кожен фрагмент зберігається на сайті, вибраному з врахуванням "оптимальної" схеми їх розміщення.

·          Реплікація. СКРБД може підтримувати актуальну копію деякого фрагмента на декількох різних сайтах.

13.4.1. Розподіл даних

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

Централізоване розміщення

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

Роздільне (фрагментоване) розміщення

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

Розміщення з повною реплікацією

Ця стратегія передбачає розміщення повної копії усієї бази даних на кожному з сайтів системи.

Розміщення з вибірковою реплікацією

Ця стратегія є комбінацією методів фрагментації, реплікації і централізації.

 

Таблиця 13.3 – Порівняльні характеристики різних стратегій розподілу даних

Розміщення даних

Локальність посилань

Надійність і доступність

Продуктивність

Вартість пристроїв зберігання

Витрати на передачу даних

Централізоване

Найнижча

Найнижча

Незадовільна

Найнижча

Найвищі

Фрагментованое

Висока1

Низька для от-дельных элемен-тов; висока для системи в цілому

Задовільна1

Найнижча

Низькі

Повна реплікація

Найвища

Найвища

Хороша для операцій читання

Найвища

Високі для  операцій обновлення, низькі для операцій читання

Вибіркова реплікація

Висока1

Низька дляокремих елемен-тів, висока для системи

Задовільна 1

Середня

Низькі

  1 За умови якісного проектування.

 

13.4.2. Фрагментація. Призначення фрагментації

Коректність фрагментації

Фрагментація даних не повинна виконуватися непродумано, навмання. Існують три правила, яких слід обов'язково дотримуватися при проведенні фрагментації.

1.       Повнота. Якщо екземпляр відношення R розбивається на фрагменти, наприклад R1,  R2,.., Rn, то кожен елемент даних, присутній відносно R, має бути присутнім, принаймні, в одному із створених фрагментів.

Виконання цього правила гарантує, що які-небудь дані не будуть втрачені в результаті виконання фрагментації.

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

3. Неперетинання. Якщо елемент даних di присутній у фрагменті Ri, то він не має бути одночасно присутнім в якому-небудь іншому фрагменті. Винятком з цього правила являється операція вертикальної фрагментації, оскільки в цьому випадку в кожному фрагменті мають бути присутніми атрибути первинного ключа, необхідні для відновлення початкового відношення. Це правило гарантує мінімальну надлишковість даних у фрагментах.

У разі горизонтальної фрагментації елементом даних являється кортеж, а у разі вертикальної фрагментації – атрибут.

Типи фрагментації

Існують два основні типи фрагментації: горизонтальна і вертикальна. Горизонтальні фрагменти є підмножинами кортежів відношення, а вертикальні – підмножини атрибутів відношення, як показано на рисунку 13.7.

 

Рисунок 13.7 – Різні   типи   фрагментації : а) горизонтальна; б) вертикальна

 

Крім того, існують ще два типи фрагментації: змішана (рисунок 13.8) і похідна (що є варіантом горизонтальної фрагментації).

 

Рисунок 13.8 – Змішана фрагментація: а) горизонтально розділені вертикальні фрагменти; б) вертикально розділені горизонтальні фрагменти

 

Відмова від фрагментації

Останній варіант можливої стратегії полягає у відмові від фрагментації відношень. Наприклад, відношення Branch(відідлення компанії) містить невелику кількість кортежів, котрі відносно рідко оновлюються. Замість того, щоб спробувати виконати горизонтальну фрагментацію цього відношення (наприклад, по номеру відділення компанії), має сенс залишити це відношення нефрагментованим і просто розмістити на кожному з сайтів його репліковані копії. Це перший етап типової процедури визначення схеми фрагментації (пошук відношень, які не вимагають фрагментації). Потім слід проаналізувативідношення, розташовані на одиничній стороні зв'язків типу "один до багатьох", і підібрати для них оптимальні схеми фрагментації. На останньому етапі аналізуються відношення, розміщені на множинній стороні тих же зв'язків. Саме вони найчастіше є кандидатами для застосування похідної фрагментації.

13.5. Забезпечення прозорості в РСКБД

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

·          Прозорість розподіленості.

·          Прозорість транзакцій.

·          Прозорість виконання.

·          Прозорість використання СКБД.

13.5.1. Прозорість розподіленості

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

13.5.2. Прозорість транзакцій

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

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

13.5.3. Прозорість виконання

Прозорість виконання вимагає, щоб робота в середовищі СКРБД виконувалася точно так, як і в середовищі централізованої СКБД.

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

·          час доступу, що включає фізичний доступ до даних на диску;

·          час роботи центрального процесора, що витрачається на обробку даних в первинній пам'яті;

·          час, необхідний для передачі даних по мережевих з'єднаннях.

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

Property (Еш, City)         10 000 записів, що зберігаються в Лондоні.

Renter(Їм, Max_Price)     100 000 записів, що зберігаються в Глазго.

Viewing(Ешг, Rno)         1 000 000 записів, що зберігаються в Лондоні.

Щоб отримати список об'єктів нерухомості в Абердине, які були оглянуті потенційними покупцями, згідними придбати об'єкти нерухомості  дорожче  200000,   можна  скористатися  наступним SQL -запитом:

SELECT p.pno FROM property p INNER JOIN

((renter r INNER JOIN viewing v ON r.rno = v.rno)

ON p.pno = v.pno

WHERE p.city = 'Aberdeen' AND r.max price > 200000;

Для простоти припустимо, що кожен кортеж у відношеннях має довжину, рівну 100 символам, що існує тільки 10покупців, згідних придбати нерухомість за ціною більше 200000, і що в місті Абердин було проведено 100000 оглядівоб'єктів нерухомості. Вважатимемо також, що час виконання обчислень несуттєвий в порівнянні з часом передачі даних, ашвидкість передачі даних по каналах зв'язку складає 10000 символів в секунду, причому на кожне повідомлення, щовідправляється між двома сайтами, припадає затримка доступу, рівна 1 секунді.

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

 

Стратегія 1.

Переслати відношення Renter в Лондон і виконати там обробку запиту :

Час = 1+(100 000 * 100/10 000) = 16,7 хв.

Стратегія 2.

Переслати стосунки Property і Viewing в Глазго і виконати там обробку запиту :

Час = 2+[(1 000 000 + 10 000) * 100/10 000] = 28 год.

Стратегія 3.

З'єднати стосунки Property і Viewing в Лондоні, вибрати кор-тежи для об'єктів нерухомості, розташованих в Абердине, а потім для кожного з відібраних кортежів перевірити в Глазго, чи встановив цей клієнт значення стелі допустимої стои-мости нерухомості Max Price > 200 000 фунтів стерлінгів. Про-верка кожного кортежу припускає відправку двох повідомлень : запиту і відповіді.

Час = 100 000 * (1+100/10 000) + 100 000 * 1 = 2,3 дня.

Стратегія 4.

Вибрати   в   Глазго   кортежі   клієнтів,   що встановили   значення Max Price > 200 000 фунтів стерлінгів, після чого для кожного з j їх перевірити в Лондоні, чи оглядав цей клієнт об'єкти не-движимости в Абердине. І в цьому випадку кожна перевірка вклю-чает відправку двох повідомлень.

Час = 10*(1+100/10 000) + 10* 1 ≈20 с.                                       

Стратегія 5.

З'єднати стосунки Property і Viewing в Лондоні, вибрати сведе-ния про огляди об'єктів в Абердине, виконати проекцію ре-зультирующей таблиці по атрибутах Рпо і Rno, після чого пере-слать отриманий результат в Глазго для відбору кортежів по ус-ловию Max Price >  200 000 фунтів стерлінгів.  Для спрощення припустимо, що довжина кортежу після операції проекції також дорівнює 100 символам.

Час = 1 + (100 000 * 100/10 000) = 16,7 хв.

Стратегія 6.

Вибрати клієнтів зі значенням атрибуту Max_Price > 200 000 фун-тов стерлінгів в Глазго і переслати результуючу таблицю в Лондон для відбору відомостей про огляди об'єктів нерухомості в р. Абердин:

Час = 1 + (10 * 100/10 000) ≈1с.

 

Таблиця 13.16 – Порівняння результатів застосування різних стратегій для обробки одного і того ж розподіленого запиту

Стратегія

Час

1.

Переслати відношення Renter в Лондон і виконати там обробку запиту

16,7 хв.

2

Переслати стосунки Property і Viewing в Глазго і виконати там обробку запиту

28 ч.

3

З'єднати стосунки Property і Viewing в Лондоні, вибрати кортежі для об’єктів нерухомості в Абердині, а потім для кожного з відібраних кортежів провірити в Глазго, чи встановив цей клієнт максимальне значення допустимої вартості нерухомості Max Price > 200000

2,3 дні

4

Вибрати в місті Глазго кортежі клієнтів, що встановили значення Max Price > 200000, після чого для кожного з них перевірити в Лондоні, чи оглядав цей клієнт об'єкти нерухомості в Абердині

20 с.

5

З'єднати стосунки Property і Viewing в Лондоні, вибрати відомості осмот-рах об'єктів в Абердине, виконати проекцію результуючої таблиці по атрибутах Рпо і Rno, після чого переслати отриманий результат в Глазго для відбору кортежів по умові Max Price > 200 000

16,7 хв.

6

Вибрати клієнтів зі значенням атрибуту Max Price > 200000 в Глазго і переслати результуючу таблицю в Лондон для відбору відомостей про огляди об'єктів нерухомості в Абердині

1с.

 

13.5.4.        Прозорість використання СКБД

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

13.5.5.        Декілька слів на закінчення

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

13.6. Дванадцять правив Дейта для РСКБД

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

Правило 0. Основний принцип

З точки зору кінцевого користувача розподілена система повинна виглядати в точності так, як і звичайна, нерозподілена система.

Правило 1. Локальна автономність

Сайти в розподіленій системі мають бути автономними. У даному контексті автономність означає наступне:

·          локальні дані належать локальним власникам і супроводжуються локально;

·          усі локальні процеси залишаються чисто локальними;

·          усі процеси на заданому сайті контролюються тільки цим сайтом.

Правило 2. Відсутність опори на центральний сайт

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

Правило 3. Безперервне функціонування

В ідеалі, в системі ніколи не повинна виникати потреба в плановій зупинці її функціонування для виконання таких операцій, як:

·          додавання або видалення сайту з системи;

·          динамічне створення або видалення фрагментів з одного або декількох сайтів.

Правило 4. Незалежність від розташування.

Незалежність від розташування еквівалентна прозорості розташування. Користувач повинен діставати доступ до бази даних з будь-якого з сайтів. Більше того, користувач повинен діставати доступ до будь-яких даних так, як якби вонизберігались на його сайті, незалежно від того, де вони фізично зберігаються.

Правило 5. Незалежність від фрагментації

Користувач повинен діставати доступ до даних незалежно від способу їх фрагментації.

Правило 6. Незалежність від реплікації

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

Правило 7. Обробка розподілених запитів

Система повинна підтримувати обробку запитів, що посилаються до даних, розташованих на більш, ніж одному сайті.

Правило 8. Обробка розподілених транзакцій

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

Правило 9. Незалежність від типу устаткування

СКРБД має бути здатна функціонувати на устаткуванні з різними обчислювальними платформами.

Правило 10. Незалежність від операційної системи

Прямим наслідком попереднього правила є вимога, згідно з яким СКРБД має бути здатна функціонувати під управлінням різних операційних систем.

Правило 11. Незалежність від мережевої архітектури

СКРБД має бути здатна функціонувати в мережах з різною архітектурою і типами носія.

Правило 12. Незалежність від типу СКБД

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

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

 

Резюме

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

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

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

·     Усі взаємодії виконуються за допомогою мережевих з'єднань,  які можуть бути як локальними, так і глобальними. Локальні мережеві з'єднання  встановлюються  на  невеликі  відстані,   але  забезпечують  велику пропускну спроможність, чим глобальні.

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

·     Кожне відношення може бути розділене на деяку кількість частин, званих фрагментами. Фрагменти можуть бути горизонтальними, вертикальними, змішаними і похідними. Фрагменти розподіляються на одному або декількох сайтах. З метою поліпшення доступності даних і підвищення продуктивності системи для окремих фрагментів може бути організована реплікація.

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

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

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

 

Керування розподіленою паралельністю.

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

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

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

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

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

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

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

·      Модель X/Open DTP являє собою один з варіантів архітектури обробки  розподілених  транзакцій,   побудованої   на  застосуванні  протоколу OSI - TP і двофазного протоколу фіксації транзакцій. У цій моделі визначаються прикладні програмні інтерфейси й методи взаємодії між додатками, що запускають транзакції, менеджерами транзакцій, менеджерами ресурсів і менеджерами передачі даних.

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

 

12.9.2 Керування розподіленою паралельністю

14 Керування розподіленою паралельністю

 

14.1 Управління розподіленими транзакціями

 

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

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

Процедура виконання глобальної транзакції, запущеної на вузлі здійснюється таким чином.

1.   Координатор транзакцій (ТС1) на вузлі S1, ділить транзакцію на декілька субтранзакцій, виходячи з інформації, що зберігається в глобальному каталозі системи.

2.   Компонент передачі даних на вузлі – відправляє опис відповідних субтранзакцій на вузли S2 і S3.

3.   Координатори транзакцій на вузлах S2 і S3 організовують виконання субтранзакцій, що поступили. Результати їх виконання передаються координаторові TC1 за допомогою компонентів передачі даних. Увесь описаний процес схематично представлений на рисунку 14.1.

 

Рисунок 14.1 – Схема координації виконання розподілених транзакцій

 

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

 

14.2 Управління паралельним виконанням в розподіленому середовищі

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

 

14.2.1 Цілі управління паралельним виконанням в розподіленому середовищі

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

-       стійкість до відмов на вузлі і в лініях зв'язку;

-       високий рівень паралельності, що задовольняє існуючим вимогам продуктивності;

-       невисокий додатковий рівень споживання процесорного  часу і інших системних ресурсів;

-       задовільні показники роботи з мережевими з'єднаннями, що мають велику тривалість часу затримки з'єднання;

-       відсутність додаткових обмежень на структуру елементарних операцій.

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

14.2.2 Проблема впордкування субтранзакцій в розподіленому середовищі

Концепція впорядкування, описана раніше, може бути розширена з урахуванням особливостей зберігання даних в розподіленому середовищі. Якщо графік виконання транзакцій на кожному з вузлів є упорядковуваним, то глобальний графік (є об'єднанням усіх локальних графіків) також буде впорядковуваним, за умови, що послідовності локального впорядкування є ідентичними. Для цього необхідно, щоб усі субтранзакції розташовувалися в одному і тому ж порядку в еквівалентному послідовному графіку на усіх вузлах. Тому, якщо субтранзакцію Ti на вузлі S1 позначити як , необхідно забезпечити, що якщо < то < для усіх вузлів Sx, на яких транзакції < мають субтранзакції.

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

-       Механізм блокування забезпечує, що графік паралельного виконання транзакцій буде еквівалентний деякому (непередбачуваному) варіанту послідовного виконання цих транзакцій.

-       Механізм обробки часових відміток гарантує, що графік паралельного виконання транзакцій буде еквівалентний конкретному варіанту послідовного виконання цих транзакцій відповідно до їх часових відміток.

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

14.2.3. Протоколи блокування

Розглянемо наступні протоколи, засновані на двофазному блокуванні (2PL), які можуть застосовуватися для забезпечення впорядкування графіків в розподілених СКБД. До них відносяться централізований протокол двофазного блокування, двофазне блокування з первинними копіями, розподілений протокол двофазного блокування і блокування більшості копій.

Централізований протокол двофазного блокування

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

1.       Координатор транзакцій на вузлі S1 розділяє глобальну транзакцію на декілька субтранзакцій, використовуючи інформацію, що зберігається в глобальному системному каталозі. Координатор відповідає за дотримання узгодженості бази даних. Якщо транзакція передбачає оновлення копійованого елементу даних, координатор повинен забезпечити оновлення усіх існуючих копій цього елементу даних. Тому координатор повинен зажадати встановити виняткові блокування на усіх копіях оновлюваного елементу даних, а потім звільнити ці блокування. Для читання оновлюваного елементу даних координатор може вибрати будь-яку з існуючих копій. Зазвичай прочитується локальна копія, якщо така існує.

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

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

Варіантом цієї схеми є випадок, коли координатор транзакцій виконує усі запити на блокування від імені локальних диспетчерів транзакцій. В цьому випадку диспетчер блокувань взаємодіє тільки з координатором транзакції, а не з окремими локальними диспетчерами транзакцій.

Перевага централізованого протоколу двофазного блокування полягає в тому, що його можна відносно просто реалізувати. Виявлення взаимоблокировок може виконуватися тими ж методами, що і в централізованих СКБД, оскільки уся інформація про блокування елементів знаходиться у розпорядженні єдиного диспетчера блокувань. Основний недолік цієї схеми пов'язаний з тим, що будь-яка централізація в розподіленій СКБД автоматично призводить до появи вузьких місць в системі і різко знижує рівень її надійності і стійкості. Оскільки усі запити на блокування елементів даних прямують на єдиний центральний вузол, його швидкодія обмежує можливості усієї системи. Крім того, відмова цього вузла викликає порушення роботи усієї розподіленої системи, тому вона стає менш надійною. Проте цій схемі властивий відносно невисокий рівень витрат на передачу даних. Наприклад, глобальна операція оновлення за участю агентів (субтранзакцій) на вузлах за наявності центрального диспетчера блокувань може потребувати відправки йому не менше 2n + 3 повідомлень, у тому числі:

-       один запит на блокування;

-       одне повідомлення про надання  блокування;

-       n сполучень з вимогою оновлення;

-       n підтверджень про виконане оновлення;

  •        один запит на зняття блокування.

Двофазне блокування з первинними копіями

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

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

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

Розподілений протокол двофазного блокування

У цьому протоколі також робиться спроба подолати недоліки, властиві централізованому протоколу двофазного блокування, але вже за рахунок розміщення диспетчерів блокувань на кожному вузлі системи. В даному випадку кожен диспетчер блокувань відповідає за управління блокуванням даних, таких, що знаходяться на його вузлі. Якщо дані не піддаються реплікації, цей протокол функціонує аналогічно протоколу двофазного блокування з первинними копіями. Інакше розподілений протокол двофазного блокування використовує особливий протокол управління реплікацією, що дістав назву "Читання однієї копії і оновлення усіх копій" (Read - One - Write - All - ROWA). В цьому випадку для операцій читання може використовуватися будь-яка копія копійованого елементу, але перш ніж можна буде відновити значення елементу, мають бути встановлені виняткові блокування на усіх копіях. У такій схемі управління блокуваннями здійснюється децентралізованим способом, що дозволить позбавитися від недоліків, властивих централізованому управлінню. Проте цьому підходу властиві свої недоліки, пов'язані з істотним ускладненням методів виявлення взаємоблокувань (через наявності багатьох диспетчерів блокувань) і зростанням витрат на передачу даних (в порівнянні з протоколом двофазного блокування з первинними копіями), які викликані необхідністю блокувати усі копії кожного оновлюваного елементу. У цьому протоколі виконання глобальної операції оновлення, що має агентів на n вузлах, зажадає передачі не менше 5n повідомлень, у тому числі:

-       n сполучень із запитами на блокування;

-       n сполучень з наданням блокування;

-       п сполучень з вимогою оновлення елементу;

-       n сполучень з підтвердженням виконаного оновлення;

-       n сполучень із запитами на зняття блокування.

Це кількість повідомлень може бути скорочена до 4n, якщо не передавати запити на зняття блокування, яке в цьому випадку виконуватиметься при обробці операції остаточної фіксації розподіленої транзакції.

Блокування більшості копій

Цей протокол можна вважати розширенням розподіленого протоколу двофазного блокування, в якому усувається необхідність блокування усіх копій реплікованого елементу даних перед його оновленням. В цьому випадку диспетчер блокувань також є на кожному з вузлів системи, де він управляє блокуваннями усіх даних, що розміщуються на цьому вузлі. Коли транзакції вимагається прочитати або записати елемент даних, копії якого є на n вузлах системи, вона повинна відправити запит на блокування цього елементу більше, ніж на половину з усіх тих n вузлів, де є його копії. Транзакція не має права продовжувати своє виконання, поки не встановить блокування на більшості копій елементу даних. Якщо їй не вдасться це зробити за деякий встановлений проміжок часу, вона відміняє свої запити і інформує усі вузли про відміну її виконання. Якщо більшість підтверджень будуть отримані, усі вузли інформуються про те, що необхідний рівень блокування досягнутий. Блокування, що розділяється, на більшості копій може бути встановлене одночасно для будь-якої кількості транзакцій, а виняткове блокування на більшості копій може бути встановлене тільки для однієї транзакції.

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

14.2.4.  Протоколи з часовими відмітками

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

Загальним підходом в розподілених СКБД є конкатенація локальної часової відмітки з унікальним ідентифікатором вузла у форматі <локалъная_відмітка, ідентифікатор_вузла>. Значення ідентифікатора вузла має менший ваговий коефіцієнт, що гарантує впорядкування подій відповідно до моменту їх виникнення і лише потім відповідно до місця їх появи. Щоб запобігти виробленню більш завантаженими вузлами великих значень часових відміток в порівнянні з недовантаженими вузлами, необхідно використовувати певний механізм синхронізації значень часових відміток між вузлами. Кожен вузол поміщає свою поточну часову відмітку в повідомлення, що передаються на інші вузли. При отриманні повідомлення вузол-одержувач порівнює поточне значення його часової відмітки з отриманим і, якщо його поточна часова відмітка виявляється менше, міняє її значення на деяке інше, що перевищує те значення часової відмітки, яке було отримано ним в повідомленні. Наприклад, якщо вузол 1 з поточною часовою відміткою <10, 1> передає повідомлення на вузол 2 з поточною часовою відміткою <15,2>, то вузол 2 не змінює свою часову відмітку. І навпаки, якщо поточна часова відмітка на вузлі 2 рівна <5, 2>, то вузол 2 повинен змінити свою часову відмітку на <11, 2>.

 

12.9.3 Технології ActiveX та CORBA для побудови розподілених систем

ActiveX/DCOM – це корпоративна технологія з фірмовим знаком Microsoft. Головне її призначення – полегшення написання мережевих розподілених об'єктно-орієнтованих застосувань. По суті, ActiveX – це ні що інше, як звичайний набір бібліотек, що значно полегшують процес кодування. Іноді запитують, в чому різниця між OLE і його складеними механізмами (OLE Automation, OLE Documents, OLE Controls) і елементами ActiveX? Відповідь дуже проста. OLE-механізми засновані на компонентній об'єктній моделі (COM, Component Object Model), яка дозволяє створювати об'єктно-орієнтовані застосування на одній машині у рамках операційної системи Windows, що функціонує на ній, a ActiveX використовує DCOM (Distributed Component Object Model) – розподілену компонентну об'єктну модель, яку реалізують бібліотеки ActiveX, що являються за об'ємом значно менше, чим бібліотеки OLE, а за швидкістю – швидше. Іншими словами, бібліотеки OLE переписані так, щоб забезпечувати функціональність, достатню для написання мережевих застосувань. Збереглася і сумісність – будь-який програмний компонент OLE працюватиме з бібліотеками ActiveX. Моделі СОМ і DCOM спираються на базові мережеві протоколи, такі як TCP/IP, і входять до складу операційної системи.

Що таке СОМ і DCOM

COM (Component Object Model) розшифровується просто – компонентна об'єктна модель. DCOM (Distributed Component Object Model) – це, відповідно, розподілена компонентна об'єктна модель.

Microsoft розробляє і підтримує DCOM виключно для створення серверів застосувань і управління розподіленими програмними об'єктами. На противагу Microsoft, два інших комп'ютерних гіганта – Sun і IBM – спираються на міжнародний стандарт CORBA. За бажання можна спільно використати обидві ці технології.

DCOM просто розширює можливості СОМ в частині реєстрації віддалених об'єктів, тому його іноді називають "СОМ з подовженим дротом".

Прикладні інтерфейси COM API – це усе ті ж, усім відомі OLE-інтерфейси, що ведуть своє походження від DDE (Dynamic Data Exchange), – динамічного обміну даними, що дозволяє єдиним способом в Windows здійснювати обмін інформацією між процесами.

По суті своїй СОМ є простим об'єктним розширенням OLE-технології, коли в локальній моделі засобів автоматизації OLE команди від клієнта проходять через модуль-ініціалізатор (proxy), а повідомлення – в модуль-перехідник (stub), де воно розбирається, аналізується і звідки посилається команда на сервер, як показано на рис 1.1.

 

Description: ActiveX1.jpg

Рис. 1.1 – Схема роботи OLE Automation

 

Наочніше ця ж схема, але вже в специфікації СОМ, представлена на рис. 1.2.

Модель СОМ значно простіша з точки зору програмістів і її набагато зручніше використати в невеликих локальних мережах.

У дистанційній моделі, яка тепер замість СОМ дістала назву DCOM, ініціалізатор і перехідник стали абсолютно іншими, тепер в них використовуються процедури дистанційного виклику (RPC) для передачі запитів клієнта по мережі до модуля Remote Server Process, що функціонує на сервері. Клієнтська частина DCOM, аналогічна колишньому механізму Automation Manager, передає дані клієнта вказаному OLE-серверу і дані у відповідь по мережі до програми-клієнта, як показано на рис. 1.3.

 

Description: ActiveX2.jpg

 

Description: ActiveX3.jpg

Рис. 1.3 – Схема взаємодії для локального і віддаленого варіантів

 

Як можна бачити з приведених рисунків, чудовою властивістю DCOM є його прозорість як для користувача, так і для програміста. Можна створити і запустити на своїй машині сервер OLE, а потім пристосувати його для роботи в дистанційному режимі простим перенесенням OLE-сервера на віддалений ПК, на якому працює модуль адміністратор автоматизованого управління DCOM. Потім треба просто зареєструвати нове місце розташування OLE-сервера за допомогою звичайної утиліти (наприклад, з арсеналу засобів Visual Basic). Програмістові не доводиться міняти жодного рядка тексту програми, щоб використати розроблений OLE-сервер віддалено. Зараз майже у будь-якій RAD-системі є шаблони для створення OLE -серверів, методи і об'єкти яких доступні при роботі в дистанційному режимі. І, оскільки реєстрацію віддаленого сервера легко включити в процедуру установки програми-клієнта, не доводиться робити яких-небудь додаткових дій, щоб скористатися новими можливостями.

Робота серверів OLE в дистанційному режимі має ряд істотних переваг, у тому числі спрощене адміністрування і обслуговування, можливість його багатократного використання будь-хто програмою-клієнтом OLE, багаторівнева система захисту доступу і достовірності даних. Але найголовніше перевага – це здатність віддалених OLE-серверів виконувати роль серверів застосувань, тобто своєрідних виконавців алгоритмів (у новій термінології – бізнес-правил) для доступу до даних в розподілених прикладних системах.

Реалізація цієї можливості є ключовим моментом в створенні трирівневої архітектури ділових застосувань Microsoft, в якій частина призначеного для користувача інтерфейсу розміщена на робочій станції клієнта, бізнес-логіка – на сервері середнього рівня, а надпотужні засоби обробки даних – на SQL-сервері бази даних (рис. 1.4).

Наприклад, трирівнева модель абсолютно не потрібна (і не обов'язково намагатися ділити програму на частини), якщо вона не вирішує загальну проблему ефективності.

 

Description: ActiveX4.jpg

Рис. 1.4. Трирівнева архітектура бізнес-застосувань

 

Проте у фірмовій документації Microsoft, присвяченій OLE-об’єктам, стверджується: "Найчастіше розміщення сервер-об’єктів доступу до даних на тій машині, де знаходиться база даних, може істотно скоротити завантаження мережі і збільшити загальну швидкість передачі даних". Є приклади реалізації трирівневих клієнт-серверних застосувань, де результати перевершують усі очікування. Продуктивність мережі практично перестає впливати на час обробки транзакцій, і своєрідне розпилювання монолітних програмних блоків на мобільні OLE-сегменти приводить до значного підвищення ефективності роботи застосування в цілому. Більше того, трафік в мережі істотно зменшується і стає більше передбачуваним.

Найприйнятніший, і найбільш простий, ефективний підхід на думку більшості творців територіально-розподілених застосувань – це створення трирівневої архітектури. У цій моделі є користувач-клієнт і сервер бази даних, а також середній рівень, який діє як "діловий" або інтелектуальний сервер застосувань. Можна потім спростити програму користувача, переміщаючи ділову логіку системи на сервер застосувань, який міг би знаходитися на тому ж самому комп'ютері, що і сервер бази даних (чи на іншому комп'ютері). Часто це дає ефект прискорення розробки і пониження дистрибутивних витрат для обслуговування "товстих" клієнтів. Сервер застосувань здійснює запити до сервера бази даних за вимогами клієнтів і реалізує бізнес-логіку, що не лише спрощує розробку і супровід клієнтів, але також означає, що слід модифікувати тільки одну програму при зміні ділової логіки реалізації бізнес-процесів.

Щоб краще зрозуміти можливості розподіленої архітектури, розглянемо приклад з реального життя. Припустимо, є велика транспортна компанія M-Trans, яка забезпечує своїх клієнтів спеціальною програмою для відстежування шляху проходження вантажу. Коли ви відправляєте вантаж з Москви в Делі, вам дається спеціальний транспортний номер. Потім, якщо ви захочете дізнатися, що сталося з вашим вантажем на шляху слідування, ви просто завантажуєте програму (назвемо її MTrack) і вводите свій транспортний номер. Діалоговий модуль зв'язується з центральною універсальною ЕОМ компанії і відшукує інформацію відносно поточного місця розташування і стану вашого вантажу. Наприклад, ви могли б дізнатися, що вантаж знаходиться нині у вузловому аеропорту відвантаження або що він був вже отриманий замовником. Електронний підпис замовника, природно, повинен свідчити про цей відрадний факт.

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

Витонченіше рішення в даному випадку могло б бути в створенні сервера застосувань на базі Windows в центрі даних компанії. Цей сервер застосувань міг би реалізувати усю ділову логіку, щоб розпізнавати різні типи транспортних номерів. Програма клієнта просто б зв'язувалася з сервером застосувань, а він вже інтерпретував би номер клієнта і здійснював відповідний запит на центральну ЕОМ. Це дійсно усунуло б проблему модифікації, тому що тільки сервер застосувань повинен був би модифікуватися, якби типи пропонованих послуг змінилися.

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

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

 

Що мається на увазі під технологіями ActiveX

ActiveX служить одній єдиній меті: забезпечувати функціонування програмних компонентів усередині складених програмних контейнерів. Ці контейнери включають Web-браузери і інші засоби перегляду документів. ActiveX – технологія Microsoft, призначена для написання мережевих застосувань. Оскільки самим напрямом, що динамічно розвивається, в комп'ютерній індустрії є Інтернет, саме тут найприродніше можуть знайти своє місце програми, написані з використанням технології ActiveX. He випадково останнім часом поняття ActiveX і Інтернету часто зустрічаються поруч. В той же час технологія ActiveX має значно більше універсальну сферу застосування.

Стандарт ActiveX дозволяє програмним компонентам взаємодіяти один з одним по мережі незалежно від мови програмування, на якій вони написані. За допомогою ActiveX можна "оживити" Web-сторінки ефектами мультимедіа, інтерактивними об'єктами або складними застосуваннями. ActiveX забезпечує деякі зв'язні засоби, за допомогою яких окремі програмні компоненти на різних комп'ютерах "склеюються" в єдину розподілену систему.

ActiveX включає в себе клієнтску і серверну частини, а також бібліотеки для разробника.

 

Керуючі елементи ActiveX (ActiveX Controls)

Що ж це таке насправді? Найбільш проста відповідь – ця нова назва для керуючих  елементів OCX, або навіть для ще раніше них існуючих VBX. Будь-який готовий або створений вами управляючий елемент OLE – це вже ActiveX-елемент, який може використовуватися в програмах. Проте подібні OLE-елементи в усьому їх незліченному різноманітті навряд чи влаштують розробників для Web.

Типовий недолік існуючих OLE-елементів – їх значні розміри. Це обумовлено складністю структури OLE-інтерфейсів, а також тим фактом, що при підготовці в Microsoft бібліотек, використовуваних для генерації управляючих елементів, розміри їх не оптимізувалися. Якщо в системі користувача якийсь з цих елементів відсутній, доводиться завантажувати його через інтернет, отже, розмір управляючих елементів, Web-сторінок має бути якомога менше. З технічної точки зору ActiveX-елемент – це деякий COM-об'єкт, через основний OLE-інтерфейс якого, IUnknown, організовується доступ до інших інтерфейсів цього об'єкту.

По суті за допомогою ActiveX-елементів програміст створює високорівневий, придатний для багатократного використання об'єкт з деякою корисною функцією. Потім цей елемент може бути переданий (чи проданий) іншому програмістові, якому згодиться як деякий "будівельний блок". Більшість програмних інструментальних систем, таких якDelphi, Visual Basic, Visual C++ підтримують засоби взаємодії з ActiveX-елементами. В ролі ActiveX-елементів може бути усе що завгодно - від звичайної кнопки до повнофункціональної електронної таблиці. У продажі є тисячі таких елементів від різних постачальників. Їх богаті функціональні можливості і різноманіття – окреме, найбільш важливе достоїнство платформи ActiveX.

Можна запитати, а яке відношення це має до Інтернету і баз даних? Відповідь i інтерпретації Microsoft звучатиме так: найпряміше і безпосереднє. За своєю суттю платформа ActiveX – це адаптація існуючих технологій Microsoft стосовно Web. По заявах Microsoft керуючі елементи ActiveX працюють швидше, ніж Java-аплети. Складні функції можна додавати клацанням миші. Головне, проте, не в тому, що ActiveX, як і Java-аплети, здатні оживити Web-сторінки. Куди важливіше той факт, що управляючі елементи ActiveX, дозволяють відвідувачам Web-вузла виконувати складні операції, отримувати потрібну інформацію від баз даних і від застосувань, працюючих на інших серверах або навіть на других Web-вузлах.

Оскільки ActiveX-файл є родичем VBX, він може використовуватися і в звичайному Visual Basic, і в мові сценаріїв VBScript. У таблиці 1.1 перераховані основні бібліотечні типи, що використовуються у Windows.

 

Таблиця 1.1 – Бібліотечні типи, використовувані в Windows

Управляючий елемент

Розши-рення

Функція

Бібліотеки (Dynamic link library), що динамічно підключається

.dll

Дозволяє користувачам діставати доступ до функцій, підпрограм і ресурсів з інших застосувань

Visual Basic

.vbx

Забезпечує той же призначений для користувача сервіс, що і DLL. Може застосовуватися в інтегрованих середовищах розробки, таких як Visual Basic 3.0, MSVC++ 1.52 і Delphi 1.0

ActiveX

.OCX

Забезпечує призначений для користувача сервіс, такий же, як DLL, і той же, що і VBX. На додаток, OCX є більш функціональними і краще використовує усі доступні йому ресурси. Підтримується практично усіма відомими RAD-системами

 

Охарактеризуємо коротко базові поняття і ключові об'єкти, з яких будуються керуючі елементи ActiveX.

Контейнер і взаємодія з ним

Управляючий елемент ActiveX не може існувати сам по собі, він завжди "живе" усередині свого контейнера і тісно взаємодіє з ним. Через властивості оточення (ambient properties) об'єкт має доступ до інформації про поточний стан свого "власника". Контейнер підтримує додаткові методи, властивості і події, які для розробника виглядають як частину інтерфейсу елементів управління ActiveX.

Властивості оточення

Інформація про стан контейнера доступна ActiveX-елементу через об'єкт AmbientProperties, посилання на який може бути отримане через властивість Ambient об'єкту UserControl.

Наприклад, властивість UserControl.Ambient.BackCoior відображає поточне значення кольору фону контейнера і зазвичай використовується при відображенні ActiveX-елемента. Грамотно написаний ActiveX-елемент повинен поводитися відповідно до поточного стану контейнера. Повідомлення userControl_Ambientchanged сповіщає управляючий елемент ActiveX про зміну значення якої-небудь властивості оточення контейнера.

Додаткові властивості

Додаткові властивості (extender properties) надаються контейнером, але зовні виглядають як частину інтерфейсу елементів управління ActiveX. Розробник ActiveX-елемента має доступ до додаткових властивостей через властивість Extender об'єкту userControl. Специфікація елементів управління ActiveX вимагає, щоб усі контейнери підтримували  Наступні  Додаткові  властивості:   Name,    Visible,    Parent,    Cancel Default. Для доступу до додаткових властивостей завжди використовується механізм пізнього зв'язування (late - bound), оскільки на момент компіляції невідомо, з яким контейнером належить працювати ActiveX-елементу.

Коли користувач звертається до властивості (методу) ActiveX control, то першим управління отримує об'єкт Extender. Якщо він не підтримує цю властивість (метод), то викликається обробник ActiveX Controls.

Об’єкт UserControl

ActiveX-елемент, створений на Visual Basic, завжди містить (агрегує) об'єкт userControl. Розміщення і налаштування властивостей складових (constituent) ActiveX-елемента проводиться за допомогою редактора властивостей.

Об'єкт userControl має стандартний інтерфейс. Ви можете написати свої обробники для подій, генерованих цим об'єктом, надати для використання або перевизначити стандартні властивості. Так само ваш ActiveX-елемент може експортувати методи, властивості і події складових компонентів.

Ключові події

В процесі свого існування ActiveX-елемент отримує сповіщення про ряд подій, генерованих об'єктом UserControl. Найбільш важливими є:

·        initialize.   Найперша  подія,  завжди  відбувається  при  створенні ActiveX-елемента. У цей момент об'єкт ще не має зв'язку зі своїм контейнером.

·        initProperties. Ця подія сповіщає про розміщення нового ActiveX-елемента у формі. У момент його приходу вбудований об'єкт вже має зв'язок зі своїм контейнером. Як правило, обробник події виконує початкову ініціалізацію властивостей ActiveX-елемента.

·        ReadProperties. При завантаженні форми (як у DesignMode, так і в RunMode) вбудовані в неї елементи створюються наново і їх властивості ініціалізувалися значеннями, збереженими у файлі з розширенням .frm. Подія ReadProperties  сповіщає ActiveX-елемент про  необхідність  виконати ініціалізацію. У цей момент об'єкт має зв'язок зі своїм контейнером.

 

CORBA и Enterprise JavaBeans – лідери найновіших технологій

Навіщо потрібна CORBA

Відразу обмовимося, що під CORBA ми розумітимемо CORBA/IIOP, тому що сама специфікація CORBA не стандартизує мережевий протокол передачі даних між клієнтом і сервером. Кожен виробник брокера об'єктних запитів, який, по суті і є CORBA, може запропонувати власний протокол транспортної служби передачі даних. Проте для забезпечення інтероперабельності брокерів запитів від різних виробників OMG (Object Management Group – міжнародна некомерційна організація, в яку входять промислові компанії і компанії, що займаються створенням програмного забезпечення) розробив загальний протокол GIOP. Його відображення в TCP/IP дістало назву протоколу Internet Inter ORB Protocol (IIOР). Завдяки цьому, будь-яке застосування CORBA/IIOP повинне працювати і взаємодіяти з іншими CORBA/IIOP-додатками незалежно від платформ, виробників програмного забезпечення і операційних систем.

CORBA (Common Object Request Broker Architecture) – це технологія для світу розподілених інформаційних об'єктів, що тісно взаємодіють між собою у рамках програми, що управляє ними, яка віртуально з цих об'єктів і складається. Так от, CORBA – це архітектура, яка з максимальними зручностями забезпечує створення і функціонування програм, званихCORBA -додатками. Останнім часом багато RAD-системи: Delphi, включають у свій арсенал підтримку CORBA.

Втім, традиційні RAD-системи, подібні Visual Basic, не потребують CORBA, тому що орієнтуються на наявний в Microsoft власний брокер об'єктних запитів, існуючий під іменем DCOM. Надалі виробникам програмних продуктів для програмістів стане все важче і важче підтримувати обидві технології. Delphi-програмісти можуть заспокоювати себе тим, що є можливість працювати і з CORBA, і з DCOM.

Звичайно ж, CORBA – більше масштабований, відкритіший і грандіозніший проект, ніж DCOM. CORBA розглядає вже існуючі застосування, як деякі метафори, які легко можна адаптувати і використати, правильно і одного разу описавши їх інтерфейси за допомогою спеціальної мови описів IDL (Interface Definition Language – мова опису запитів), для якого існують компілятори у більшість сучасних мов програмування. CORBA є прообразом нашого об'єктного майбутнього. У комп'ютерному світі абсолютно нормальним вважається факт, що програмісти усіх країн по мільйону разів переписують наново один і той же алгоритм, якщо він вимагає внесення деяких невеликих змін. Навіщо?

Адже у будь-якому випадку, безумовно, існує кращий варіант того фрагмента програмного коду, який переписується із самого початку людьми, ніби вони не знають про це. Чому, в порівнянні з програмістами, так далеко уперед пішли інженери комп'ютерних систем? Та тому, що вони вже дуже давно використовують об'єктну технологію у вигляді незмінних конструкторських елементів ("чіпів"). А програмісти по-старому розпочинають з пісочку: спочатку просіємо пісочок, потім додамо в нього глину, після цього виготовимо цеглу, а вже потім з тієї цегли побудуємо конструкцію. Кустарне виробництво.

Що означають об'єктні технології в програмуванні, і не лише в програмуванні, а ширше, – в усій комп'ютерній творчості в епоху безроздільного панування Мережі? Ми вимушені визнати, що сучасне виробництво начисто позбавлене індивідуалізму і визнає тільки те, що може бути розмножене. Найкращим варіантом вважається той, який ви не створюєте, а лише настроюєте, компонуючи його з різного набору об'єктів, описуючи їх властивості і задаючи різні методи, що виконують той або інший вид роботи. Виграш продуктивності виходить колосальний. У всьому панує єдиний принцип – повторне використання компонентів. Ваша праця, якщо ви є творцем нових інформаційних об'єктів і одночасно клієнтом системи об'єктної реалізації, легко може перетворитися на об'єкт: процес або програму, які можуть використати інші клієнти і об'єкти з метою використання ваших методів, якщо вони містять в собі щось нове, незалежно від ваших бажань, місцезнаходження і часу.

Звичайно, було б ідеально, якби повторно використовувані об'єкти самі б не були об'єктами, а їх творець мав права на плоди своєї творчості. Але ж неможливо уявити собі, що б творець якого-небудь об'єкту творив у вакуумі, він усього лише наслідує структуру якого-небудь опису, якого-небудь шаблону, класу або групи класів – пакетів. Те що зараз відбувається з програмними модулями, що оформляються на універсальній мові програмування в JavaBeans або в ActiveX, те ж, по суті, відбувається і з авторськими текстами, що перетворюються не на індивідуальні плоди творчості, а в один нескінченний і універсальний коментар. Який сенс наново описувати те, що вже одного разу описано? Проте це робиться, і текст, проходячи через безліч об'єктів, що інтерпретують його, постійно шліфується, до тих пір, поки не набуває абсолютної форми. Якщо раніше Мережа ще носила на собі яскравий відбиток індивідуалізму її творців, то тепер вона все більш і більш перетворюється на деякий Універсум, який за визначенням не терпить нічого, що виходить за його межі. Усе або майже усе в Мережі придбаває статус анонімності. Використовуються вже не повноцінні імена, а усього лише ідентифікатори, не індивідуальні паролі, а сертифікати. Творців не може бути надто багато. Врешті-решт єдиним творцем усього стає сама Мережа.

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

Приклади абсолютно прості: ви включаєте свій телевізор таким самим способом, як праску, електропіч або настільну лампу. Усі предмети, що відносяться до класу "Прилад", містять метод "включити", але в процесі включення, залежно від типу приладу (підкласу), єдиний метод "включити" поводиться поліморфно, тобто викликає абсолютно різні електричні і блокові функції: для праски – одні, для телевізора – інші. Можна так перевизначити класи і методи в телевізорі новітньої конструкції, що він поводитиметься абсолютно по-різному, залежно від того, ХТО його включив, тобто телевізор поведеться поліморфно. Більше того, існують програмні засоби (Java+XML), які здатні динамічно модифікувати контент. Попри те, що Java і XML самі по собі досить складні, інструменти, засновані на них, для звичайного користувача надзвичайно прості і приємні, бо вони відводять його від необхідності знати внутрішні механізми інформаційного джерела і призводять до дистанційного пульта управління ними.

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

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

Сила CORBA в тому, що це система, що самоописується і самодокументується. Вона була розроблена для того, щоб дозволити створювати інтелектуальні компоненти, які можуть запросити інформацію один про одного і потім її ефективно використати. Число взаємодіючих об'єктів при цьому не обмежене, способи існування і місцезнаходження об'єктів жорстко не визначені. Будь-який об'єкт може бути затребуваний іншим об'єктом або програмою в довільній точці Мережі, і це дуже сильно нагадує телепортацію.

Архітектура CORBA.

Чотири головні елементи CORBA архітектури показані на рис. 3.1.

·        Брокер об'єктних запитів (ORB – Object Request Broker) визначає механізми взаємодії об'єктів в різнорідній мережі. Посередник об'єктних запитів, ORB, або просто брокер, – це логічне ядро системи. Саме він дозволяє об'єктам посилати запити і отримувати відповіді від інших об'єктів в мережі. ORB – це проміжне програмне забезпечення, яке встановлює відношення між об'єктами в розподіленому середовищі. Брокер по посиланню знаходить на сервер, що містить об'єкт-адресат (object implementation – реалізація об'єкту); активізує його, доставляє до нього запит; передає параметри і викликає відповідний метод, після чого повертає результат клієнтові. Ролі клієнта і сервера при цьому можуть мінятися. Взаємодія може бути встановлена між безліччю об'єктів. OMG розробив спеціальну мову верхнього рівня для опису ORB і інших компонентів CORBA – так званий IDL (Interface Definition Language – мова опису інтерфейсів). У ній немає присвоєнь,    звичайних    мовних    конструкцій,    типу    if    чи    while, функцій і логічних переходів і т. д. IDL – це мова декларацій, вона описує батьківські класи, події і методи. Кожен інтерфейс визначає операції, які можуть бути викликані клієнтами, але не те – яким чином ці операції виконуються зовні IDL і CORBA. У цьому і привабливість – можна змусити працювати старі програми, якщо правильно описати їх інтерфейси і використати компілятор з IDL, який має відображення в конкретну мову програмування. Важливо зрозуміти, що є два типи інтерфейсів:динамічні і статичні. Перші визначаються на стадії розробки застосування і компілюються разом з ним, другі конструюються у момент виконання, на працюючому застосуванні.

·        Сервіси  об'єктів  (Object  Services)  є  основними  системними сервісами, які розробники використовують для створення застосувань.

·        Універсальні засоби (Common Facilities) є також системними сервісами, але більш високого рівня, орієнтованими на підтримку призначених для користувача застосувань, таких як електронна пошта, засоби друку і т. д.

·        Прикладні об'єкти  (Application  Objects)  використовуються  в конкретних прикладних завданнях.

Так, все-таки, навіщо потрібна CORBA?

 

Description: ActiveX5.jpg

Рис. 3.1 – Головні елементи CORBA

 

Розподілені застосування

CORBA-архітектура забезпечує каркас для розробки і виконання розподілених застосувань. Але виникає нове питання – а навіщо взагалі потрібний цей розподіл? Як тільки ви зіткнетеся з ним, то побачите перед собою величезну купу нових проблем. Проте іноді немає іншого вибору: деякі застосування просто вимагають бути розподіленими з наступних причин:

·        дані, використовувані застосуванням, – розподілені;

·        обчислення – розподілені;

·        користувачі застосування – розподілені.

Розподілені дані

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

Розподілені обчислення

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

Розподілені користувачі

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

Як вже говорилося, CORBA є ідеальною архітектурою для створення таких застосувань. Актуальність її в наші дні активно затребувана розвитком Інтернету і систем електронної комерції, де багато функцій має бути розподілені по мережі і де є удосталь безліч вже працюючих об'єктних модулів, існуючих у вигляді ActiveX, або JavaBean-компонентів.

Брокер об'єктних запитів, ORB, ставить запит об'єкту і повертає будь-який результат клієнтові (рис. 3.3).

 

Description: ActiveX6.jpg

Рис. 3.2 – Розподілені користувачі

 

Description: ActiveX7.jpg

Рис. 3.3 – Механізм взаємодії: клієнт запитує об'єкт через посередника ORB

 

Від клієнта до сервера

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

Можна чітко сформулювати ключові особливості CORBA-стандарту:

·                   CORBA-об’єкти можуть знаходитись в будь-якому месці мережі;

·                   CORBA-об’єкти можуть взаємодіяти з іншими CORBA -объектами на будь-яких платформах;

·                   CORBA-об’єкти можуть бути написані на будь-якій мові програмування, для якого є інтерфейс, що реалізовується IDL-компілятором (такі є для Java, C++, C, SmallTalk, COBOL і Ada).

Використовуючи CORBA,можна створювати розподілені системи, де різні компоненти (інтерфейси користувачів, бізнес-алгоритми, доступ до баз даних і т. д.) упаковуватимуться в окремих програмах, що виконуються на різних машинах. Кожен компонент зв'язуватиметься з іншим тільки через оголошений інтерфейс. При цьому можна відлагоджувати і підтримувати частини програм окремо.

 

Description: ActiveX8.jpg

Рис. 3.4. Архітектура CORBA-сумісного застосування, що викликає безліч об'єктів з безлічі комп'ютерів

 

Клієнтська частина CORBA

Коли CORBA-сумістний об'єкт використовує метод, що знаходиться в іншому об'єкті, він викликає стаб (stub), тобто деяку порожню оболонку необхідного об'єкту, його інтерфейсну частину, що знаходиться в спеціальному stub-файлі. Цей стаб використовує локальний ORB, посилає запит і отримує відповідь. Об'єкту немає ніякої необхідності знати подробиці відносно ORB або дійсного місцезнаходження сервера. Усі CORBA-клієнти і сервери з'єднуються через брокерів ORB, використовуючи їх як посередників.

JDK містить ORB, який дозволяє створювати CORBA-сумісні програми на Java.

Клієнтський стаб створюється при першому визначенні серверного інтерфейсу в клієнтові за допомогою мови визначення інтерфейсів IDL. CORBA IDL визначає тип об'єкту, його методи, властивості і т. д. CORBA IDL – це абсолютно нейтральна і чисто декларативна мова.

Стаб потім використовує локальний ORB, посилає запит і отримує відповідь. ORB надає своєрідну шину для проходження обміну структурованими даними. Ця шина використовує IIOP як транспортний протокол між брокерами ORB.

 

Серверна частина CORBA

При витяганні запиту IIOP сервер ORB використовує так званий Basic Object Adapter (BOA) в комбінації здепозитарієм виконання (Implementation Repository – набором конкретних класів і бібліотек, наявних на сервері) для передачі параметрів запиту до необхідного серверного об'єкту через серверний стаб. Іноді запитують – навіщо так складно? Відповідь проста, щоб легше було програмувати незалежні частини коду, зосереджуючись тільки на суті коду, а не на вирішенні системних питань, пов'язаних з мережевою специфікою і міжпрограмній взаємодії. Про них користувач взагалі не повинен замислюватися, в точності так само, як він не замислюється про внутрішній устрій телефонної трубки і телефонної станції, через які проходить голосовий сигнал.

·        Basic Object Adapter BOA – це набір системних сервісів ORB для встановлення з'єднання з серверними об'єктами по їх ідентифікаторах (об'єктні посилання).

·        Server IDL Stub Служить для забезпечення інтерфейсу до кожного сервісу. На серверній стороні такої стаб, щоб відрізнити його від клієнтського стаба, називається скелетон.

·        Implementation Repository Це набір класів на стороні сервера, доступний усім розподіленим клієнтам через систему об'єктних посилань.

 

Сервіси CORBA

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

 

Description: ActiveX9.jpg

Рис. 3.5. Об'єктні сервіси

 

Є безліч CORBA-сервісів. Найпопулярніші з них наведені в таблиці 3.1.

 

Таблиця 3.1 – Найбільш популярні сервіси CORBA

Сервіс

Опис

Життєвий цикл об’єкта (Object life cycle)

Визначає, яким чином CORBA-об’єкти будуть створені, видалені, переміщені або скопійовані

Іменування (Naming)

Визначає спосіб символічного позначення CORBA -объектов

Події (Events)

Обробка подій

Відношення (Relationships)

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

Перетворення об'єктів з однієї форми в іншу (Externalization)

Координує перетворення об'єктів із зовнішніх форм у внутрішні і навпаки

Транзакції (Transactions)

Координують доступ до CORBA-об’єктів

Контроль доступу (Concurrency Control)

Забезпечує обслуговування блокування об'єктів CORBA

Властивість (Property)

Підтримує   асоціацію   пари :   ім'я-значення для об'єктів CORBA

Продавець (Trader)

Підтримує  пошук  CORBA-об’єктів,   заснований на афішованих властивостях об'єкту

Запрос (Query)

Підтримка запитів до об'єктів

 

CORBA-продукти

Не забувайте, що CORBA – це усього лише специфікація. Що стосується програмних виробів, що реалізовують архітектуру CORBA, то їх є множина. Окремі продавці забезпечують свої брокери CORBA і IDL для відображення в різні мови програмування. Усі вони зобов'язані підтримувати Java. У таблиці. 3.2 приведені найбільш відомі реалізації CORBA.

 

Таблиця 3.2 – Найбільш відомі реалізації CORBA

ORB

Опис

Java ORB

Java 2 ORB поставляється у складі   Sun's Java SDK. Там відсутні деякі особливості повної специфікації

VisiBroker for Java

Популярний Java ORB з Inprise Corporation. VisiBroker вбудований у багато інших продуктів. Приміром, саме він був вбудований у браузер Netscape Communicator.

OrbixWeb

Добротний Java ORB з lona Technologies (для Unix)

WebSphere

Потужний сервер застосувань зі вбудованим ORB від IBM

Free or shareware ORBs

CORBA-реалізації для різних мов програмування доступні для завантаження по мережі Інтернет з різних джерел

Тема 14 Інтерфейс ODBC (Open Database Connectivity)

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

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

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

Щоб упорядкувати цей підхід, Microsoft розробила інтерфейс, що дістав назву Open Database Connectivity (ODBC). Технологія ODBC передбачає використання єдиного інтерфейсу для доступу до різнорідних баз даних SQL, причому мова SQL розглядається як стандартний засіб доступу до даних. Цей інтерфейс (який реалізований безпосередньо на мові С) забезпечує високу міру функціональної сумісності, внаслідок чого одне і те ж застосування може діставати доступ до даних, що зберігаються у базах різних цільових СКБД, без необхідності внесення змін до його програмного тексту. Таким чином, розробники отримали інструмент, що дозволяє створювати і поширювати застосування архітектури "клієнт/сервер", здатні працювати з широким спектром різних цільових СКБД. Для зв'язку застосування з будь-якою вибраною користувачем цільовою СКБД досить лише мати відповідний драйвер бази даних.

Нині технологія ODBC фактично визнана як загальнопромисловий стандарт. Головною причиною популярності цієї технології є її гнучкість, що надає розробникам наступні переваги:

-     Застосування більше не пов'язані з прикладним API-інтерфейсом конкретної СКБД.

-     Оператори SQL можуть явно включатися в початковий текст застосування або динамічно створюватися безпосередньо під час виконання програми.

-     У застосуванні можна не враховувати особливості використовуваних протоколів передачі даних.

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

-     Засоби підтримки ODBC розроблені з урахуванням вимог стандартів X/Open і стандартів ISO CLI (Call-Level Interface).

-     Нині драйвери ODBC існують для великої кількості найчастіше використовуваних СКБД.

Пізніше ми розглянемо JDBC – найбільш успішний і зрілий підхід до організації доступу до реляційних СКБД з програм на мові Java, яка розроблена на основі специфікації ODBC.

 

14.1 Архітектура ODBC

 

У інтерфейс ODBC включені перераховані нижче елементи.

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

-     Стандартний метод підключення і реєстрації в СКБД.

-     Стандартні засоби представлення цих різних типів.

-     Стандартний набір кодів помилок.

-     Типовий синтаксис операторів SQL, заснований на використанні специфікацій Х/Open і ISO CLI.

Архітектура ODBC складається з чотирьох компонентів.

1.   Застосування. Виконує обробку даних і виклик функцій бібліотеки ODBC для відправки операторів SQL в СКБД і вибірки інформації з СКБД.

2.   Диспетчер драйверів. Виконує завантаження і вивантаження драйверів на вимогу застосування. Цей програмний компонент може сам обробляти виклики функцій ODBC або передавати їх драйверу. Диспетчер драйверів був розроблений компанією Microsoft і є DLL (Dynamic Link Library – динамічно зв'язувана бібліотека).

3.   Драйвери і агенти баз даних. Обробляють виклики функцій ODBC, направляють запити SQL в конкретні джерела даних і повертають отримані результати застосуванню. З потреби драйвери модифікують початковий запит застосування, щоб привести його у відповідність синтаксичним вимогам цільової СКБД. Драйвери можуть надавати тільки ті можливості, які забезпечуються цільовій СКБД. Від них не потрібно власну реалізацію можливостей, які не підтримує ця СКБД. Наприклад, якщо цільова СКБД не підтримує операції зовнішнього з'єднання, то ця функція не підтримуватиметься і драйвером ODBC. Єдиним важливим виключенням з цього правила є драйвери для СКБД, що не мають власних машин баз даних, наприклад XBase. В цьому випадку драйвер реалізує машину бази даних, яка підтримує хоч би мінімальний набір операторів SQL.

У варіанті архітектури ODBC з використанням декількох драйверів (рис. 14.1, а) всі згадані задачі повинні виконуватись самим драйвером ODBC, оскільки агент бази даних не існує. У випадку використання єдиного драйвера ODBC (рис. 14.1, б) для кожного з типів СКБД знадобиться застосування агентів бази даних, що розміщуються в серверній частині застосування. При обробці запитів на доступ до бази даних ці агенти тісно взаємодіють з драйвером ODBC, розташованим в клієнтській частині застосування.

 

         Description: D:\My docs Igor\DataBases\Lections\ODBC.jpg

 

а – використання декількох драйверів

 

б – використання єдиного драйвера

         Рисунок 14.1 ­– Архітектура ODBC

 

У середовищі Windows драйвер ODBC реалізований у вигляді бібліотеки DLL. Агенти баз даних реалізуються як фонові процеси (демони), які функціонують на сервері зі встановленою цільовою СКБД.

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

 

14.2 Рівні відповідності ODBC

 

Архітектура ODBC визначає для драйверів два різні рівні відповідності – рівень ODBC API і рівень граматики ODBC SQL. Зараз ми обмежимося розглядом рівня граматики ODBC SQL. Ознайомлення з рівнем ODBC API, відкладемо на другу частину заняття. Вона будуватиметься за матеріалами Microsoft ODBC Reference Guide.

 

14.2.1 Рівень граматики ODBC SQL

У стандарті ODBC визначається граматичне ядро, що відповідає специфікаціям Х/Open CAE та ISO CLI. Більше ранні версії ODBC були засновані на попередніх версіях цих специфікацій, але не включали їх повної реалізації.

У версії ODBC 3 (на 2011 рік сайт Microsoft описує веерсію 3.8) повністю реалізовані обидві ці специфікації і додатково введені функції, зазвичай використовувані розробниками в інтерактивних застосуваннях баз даних, наприклад курсори з підтримкою прокрутки.

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

Мінімальний рівень підтримки граматики мови SQL:

-     Оператори мови визначення даних (Data Definition Language DDE) – CREATE TABLE і DROP TABLE.

-     Оператори мови маніпулювання даними (Data Manipulation Language – DML) – прості оператори SELECT, INSERT, UPDATE, SEARCHED І DELETE SEARCHED.

-     Вирази – прості (наприклад, А > В + С).

-     Типи даних – CHAR, VARCHAR АБО LONG VARCHAR.

Базовий рівень підтримки граматики мови SQL:

-     Мінімальний рівень підтримки граматики мови SQL і типів даних.

-     Мова DDL: оператори ALTER TABLE, CREATE INDEX, DROP INDEX, CREATE VIEW, DROP VIEW, GRANT иREVOKE.

-     Мова DML: усі можливості оператора SELECT.

-     Вирази: підзапити, що агрегують функції, наприклад SUM і MIN.

-     Типи даних: DECIMAL, NUMERIC, SMALLINT, INTEGER, REAL, FLOAT, DOUBLE PRECISION

Розширений рівень підтримки граматики мови SQL:

-     Мінімальний і основний рівні підтримки граматики мови SQL і типів даних.

-     Мова DML: зовнішні з'єднання, оператори UPDATE і DELETE, оператор SELECT FOR UPDATE і підтримка об'єднань.

-     Вирази: скалярні функції (наприклад, SUBSTRING і ABS), літеральні значення дати, часу і часової мітки.

-     Типи даних: BIT, TINYINT, BIGINT, BINARY, VARBINARY, LONG VARBINARY, DATE, TIME, TIMESTAMP.

-     Оператори SQL для пакетної обробки даних.

-     Виклики процедур.

Технологія ODBC (Open DataBase Connectivity) компанії Microsoft пропонує єдиний інтерфейс доступу до різноманітних баз даних SQL. У технології ODBC мова SQL використовується як основний стандарт доступу до даних. Інтерфейс ODBC (реалізований на мові С) забезпечує високу міру функціональної сумісності, внаслідок чого одне і те ж застосування дістає можливість доступу до баз цих різних СКБД, що підтримують мову SQL. Подібні функціональні можливості технології ODBC дозволяють розробникам створювати і випускати на ринок застосування з архітектурою "клієнт/сервер", що не вимагають застосування СКБД якогось конкретного типу. Для зв'язку застосувань з СКБД різних типів використовуються відповідні драйвери ODBC. Нині технологія ODBC вже фактично прийнята як промисловий стандарт.

 

14.2.2 Рівень ODBC API

Перед детальнішим аналізом API-функцій ODBC інтерфейсу, варто зазначити, що їх повний перелік досить великий і доступний у відповідній документації від Microsoft, або ж за адресами і мережі Інтернет:

http://msdn.microsoft.com/ru-ru/library/s9ds2ktb.aspx

http://msdn.microsoft.com/ru-ru/library/w2c4cthk.aspx

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

Через те, що програмно ODBC реалізований мовою C, то використання цих біліотек описано стосовно роботи з VisualC++ для бібліотеки MFC.

В загальному процес роботи з базою даних через ODBC – стандартний і перебачає наступні кроки:

1.Встановити з’єднання з базою даних.

2.Виконати запит.

3.Отримати дані

Познайомимось коротко з основними функціями, котрі дозволяють виконувати ці опреації.

Класи MFC CDatabse та CRecordset інкапсулюють всі необхідні засоби роботи з базами даних. В рамках цього заняття не будемо вдаватись до детальних програмних реалізацій кожної з дій, щоби за деталями не втратити хід викладу матеріалу.

Отже, для встановлення з’єднання з базою даних потрібно оголосити змінну типу CDatabse та скористатись методом цього класу Open() або OpenEx().

Завкриття цього з’єднання відбувається шляхом виклику методу Close().

Для маніпулювання даними, тобто постановки запитів та обробки результатів їх виконання, потрібно користуватись методами класу CRecordset. Їхній перелік охоплює весь набір задач, а саме фільтрацію, навігацію, сортування, робота з закладками, редагування даних тощо. Детальний описаний всіх цих можливостей може бути знайдений початковою за адресою http://msdn.microsoft.com/ru-ru/library/5sbfs6f1.aspx.

 

14.3 Використання драйверів ODBC

 

Після установки Visual C++ чи цілого пакету Visual Studio 2010 в системі користувачеві будуть доступними для використання ряд драйверів ODBC. Їх список:

-     SQL Server;

-     Microsoft Access;

-     Microsoft Excel;

-     dBASE;

-     Paradox;

-     Microsoft Oracle ODBC;

-     Текстові файли.

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

Наприклад, для СКБД mySQL дистрибутив драйвера ODBC для ОС Windows доступний на сторінці, розміщеній за посиланням http://dev.mysql.com/downloads/connector/odbc/3.51.html. Вибравши і скачавши потрібний дистрибутив драйвера, встановлюємо його та через панель керування налаштовуємо з’єдання з СКБД. Для Windows XP, Vista та 7 налаштуванняODBC доступні через елемент Administrative tools (Адміністрування) à Data Sources (ODBC) (Джерела даних (ODBC)).

Після активації цього список встановлених драйверів для доступу до різноманітних СКБД наведено на закладціDrivers (Драйвери) та показано на рисунку 14.3.

Після утсановки нового драйвера (наприклад, mySQL), він має бути присутнім у списку. Для встановлення параметрів з’єднання з СКБД на першій закладці цього діалогового вікна – User DSN (DSN користувача) та, натиснувши кнопку Add(Добавити) – рисунок 14.4, відкрити діалогове вікно вибору драйвера (рисунок 14.5).

Після цього у вікні конфігурування потрібно вказати правильні параметри. Варто зазначити, що для кожної СКБД вигляд цього вікна буде відрізнятись, але набір елементів залишатиметься типовим і включатиме назву з’єднання, а при потребі – ім’я користувача бази даних, пароль, розміщення СКБД тощо. Для СКБД mySQL це діалогове вікно зображено на рисунку 14.6.

 

Рисунок 14.3 – Діалогове вікно управління джерелами даних ODBC ОС Windows на закладці списку драйверів

 

Рисунок 14.4 – Диспетчер підключень ODBC

 

Рисунок 14.5 – Вибір драйвера для конфігурації підключення до СКБД

 

Рисунок 14.6 ­–  Діалогове вікно налаштування з’єднання ODBC з СКБД mySQL

 

Зазначимо також, що в диспетчері підключень ODBC можливо для певниих СКБД (наприклад, Microsof Access) створити підключення не до системи керування базами даних в цілому, а до файлу.

Незалежно від типу з’єднання, воно може надалі використовуватись як у прикладних програмах, створних користувачем, так і у іншому програмному забезпеченні, що за своїм призначенням виконує обробку баз даних. Наприклда, з середовища Microsof Access можливо отримати доступ до таблиць СКБД mySQL саме завдяки інтерфейсу ODBC.

Запити QBE в MS Access – побудова та використання

 

Наведений матеріал дозволяє познайомитися з основними особливостями мови QBE (Query-by-Example – мова запитів за зразком) на прикладі відповідних функціональних можливостей СКБД Microsoft Access.

Мова QBE використовує візуальний підхід для організації доступу до інформації в базі даних, побудована на застосуванні шаблонів запитів, запропонованих Злуфом (Zloof) в 1977 р. Робота в QBE здійснюється за допомогою задання зразків значень у шаблоні запиту, що передбачає той тип доступу до бази даних, який потрібен в даний момент, – наприклад, одержання відповіді на деяке питання.

Мова QBE була розроблений компанією IBM в 70-і роки й призначалася для користувачів, зацікавлених у вибірці інформації з баз даних. Ця мова одержала в користувачів настільки широке визнання, що в цей час тією чи іншою мірою вона реалізований практично у всіх популярних СКБД, включаючи й Microsoft Access. Засоби підтримки мови QBE у СКБД Microsoft Access досить прості в експлуатації й у той же час надають користувачам досить широкий спектр можливостей роботи з даними.

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

При створенні запиту з використанням засобів QBE, СКБД Microsoft Access неявно конструює еквівалентний оператор мови SQL, призначений для виконання зазначених дій. Мова SQL широко використається для виконання запитів, відновлення й обслуговування реляційних баз даних.

 

1 Знайомство із засобами генерації запитів СКБД Microsoft Access

При створенні або відкритті бази даних у середовищі СКБД Microsoft Access у вікні Database відображаються всі об'єкти цієї бази даних – таблиці, форми, запити й звіти. Так, при відкритті бази даних DreamHome у цьому вікні буде представлений набір таблиць, що входять у згадану базу даних – як показано на рисунку 1.

 

Рисунок 1 – Вікно Database СКБД Microsoft Access з об'єктами бази даних

 

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

При виконанні запиту на вибірку СКБД Microsoft Access поміщає обрані дані в динамічний набір даних (dynaset). Динамічний набір являє собою динамічно створюване представлення (вид), що містить дані, які отримуються з однієї або більше таблиць. Дані вибираються й сортуються відповідно до зазначених в запиті вимог. Інакше кажучи, динамічний набір являє собою обновлюваний (не завжди) набір записів, визначений таблицею або запитом, який можна розглядати як окремий об'єкт.

Крім запитів на вибірку, у середовищі СКБД Microsoft Access може бути створено і ряд інших типів запитів. У таблиці 1 наведений короткий огляд різних типів запитів, підтримуваних СКБД Access. Всі ці варіанти запитів докладно обговорюються нижче. Виключенням є лише запити, що використають специфічні можливості мови SQL, відсутні в мові QBE.

На початку процедури створення нового запиту СКБД Microsoft Access виводить діалогове вікно New Query, показане на рисунку 2.

Представлений у цьому вікні перелік доступних варіантів подальших дій дозволяє або приступити до створення нового запиту з нуля й виконати всі необхідні дії власними силами (варіант Design View), або скористатися для створення запиту допомогою одного з майстрів СКБД Access, назви яких становлять частину списку, що залишилася.

 

Таблиця 1 – Типи запитів, підтримувані в СКБД Microsoft Access

Тип запиту

Опис

Запити на вибірку

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

Запити з узагальненням

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

Параметричні запити

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

Запити на вибірку дублікатів

Виконують пошук записів, що дублюються, у межах єдиної таблиці

Запити на вибірку записів, що не має відповідності

Працюють зі зв'язаними таблицями й виконують пошук записів однієї таблиці, що не мають відповідників у інший

Перехресні запити

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

Запити з автопідстановкою

При виконанні запиту виконується автоматична підстановка певних значень у знову створювані записи

Активні запити (включають запити на видалення, додавання, поновлення (редагування) й створення таблиць)

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

Специфічні SQL-запити (включають функції з'єднання, передачі, визначення даних, а також підзапити)

Цей тип запитів використовується для модифікації запитів, описаних вище типів і для визначення властивостей форм і звітів. У цих запитах допускається застосовувати специфічні засоби мови SQL – наприклад, операції з'єднання, оператори визначення даних і підзапити, а також передані запити. Переданими запитами називаються запити, що містять SQL-оператори, що пересилаються у бази даних СКБД SQL Server компаній Microsoft або Sybase

Рисунок 2 –  Діалогове    вікно    New   Query   СКБД Microsoft Access

 

Майстри являють собою один з варіантів допоміжних програм СКБД. Вони задають користувачеві ряд питань про створюваний запит, після чого генерують його текст на підставі отриманих відповідей. Як видно з рисунка 2, можна скористатися відповідним майстром для створення простого запиту на вибірку, перехресного запиту й запитів на пошук дублікатів або записів, що не мають відповідників в деякій таблиці. На жаль, цим список доступних майстрів вичерпується, тому при створенні більш складних запитів на вибірку або інших типів запитів (параметричних, активних або з автопідстановкою) доведеться використовувати режим конструктора.

 

2 Використання QBE для створення запитів на вибірку даних

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

Як уже вказувалося вище, простий оператор вибірки може бути створений за допомогою майстра простих запитів, що може бути викликаний з діалогового вікна, показаного на рисунку 2. Однак ми розглянемо приклад побудови простого запиту в режимі Design View – тобто починаючи з нуля, без допомоги яких-небудь майстрів.

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

Вікно Select Query являє собою графічний інструмент мови QBE. Для формування зразка записів, що нас цікавлять, у графічному середовищі цього вікна для вибірки, перетягування або маніпулювання об'єктами, що містяться в ньому, можна використати мишу. Визначення полів і записів, які повинні бути включені в результати запиту, виконується в сітці мови QBE.

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

 

2.1 Задання критеріїв відбору

Критерієм відбору називають обмеження, які накладаються на результати виконання запиту з метою вибірки тільки тих полів або записів даних, які становлять інтерес для користувача. Наприклад, для добування з таблиці Property_for_Rent (Власність для оренди) тільки стовпців номера об'єкта (Pno), міста (City), типу об'єкта (Type) і суми орендної плати (Rent) у сітці QBE може бути підготовлений запит, показаний на рисунку 3, а. Після виконання цього запиту отримані результати будуть відображені в сітці даних, містячи тільки зазначені стовпці таблиці Property_for_Rent – як показано на рисунку 3, б. Текст еквівалентного SQL-оператора для даного запиту показаний на рисунку 3, в.

Зверніть увагу, що на рисунку 3,а показане заповнене вікно Select Query зі списком полів цільової таблиці (у цьому випадку – Property_for_Rent), відображеною над сіткою QBE. У деяких з наведених нижче прикладах буде показана тільки сітка QBE, оскільки склад полів цільової таблиці можна легко визначити по набору полів, поміщених в сітку.

Припустимо, що в запит, показаний на рисунку 3,а, необхідно додати новий критерій, що дозволить нам вибирати відомості тільки про об'єкти нерухомості, розташовані у місті 'Glasgow', тобто варто обумовити критерій, що обмежить результуючий набір даних тільки тими записами, у яких поле City має значення 'Glasgow'. Для цього досить ввести в сітці QBE вказане значення в комірку Criteria стовпця City.

 

Рисунок 3 – Запит на вибірку: а) сітка QBE із запитом на вибірку полів Pno, City, Type й Rent з таблиці Property_for_Rent; б) результуюча сітка з даними цього запиту; 
в) еквівалентний SQL-оператор запиту

 

Можна продовжити ускладнення умов відбору, вводячи додаткові критерії для того ж самого поля або для інших полів. Якщо помістити деякі вирази в більш ніж одну комірку рядка Criteria, СКБД Access з'єднає їх, використовуючи логічний оператор AND (І) чи OR (АБО). Якщо вирази в різних комірках будуть введені в той самий рядок сітки QBE, СКБД Access використає для їхнього з'єднання оператор AND. Це означає, що в результуючий набір будуть поміщені тільки ті записи, які відповідають одночасно всім зазначеним критеріям відбору. Якщо вирази будуть поміщені в різні рядки сітки QBE, СКБД Microsoft Access використає для їхнього з'єднання логічний оператор OR. У цьому випадку в результуючий набір потраплять будь-які записи, що відповідають хоча б одній із зазначених умов відбору.

Наприклад, для виводу відомостей про розташовані в місті Глазго об'єкти нерухомості, у яких щомісячна орендна плата перебуває в діапазоні від 350 до 450 грн, досить помістити значення 'Glasgow' в комірку Criteria стовпця City й ввести вираз 'Between 350 And 450' в комірку Criteria стовпця Rent. Приклад відповідним чином заповненої сітки QBE наведений на рисунку 4, а. Після виконання даного запиту буде виведена сітка даних, яка містить тільки ті записи, які відповідають зазначеному критерію – як показано на рисунку 4, б. Еквівалентний SQL-оператор для даного запиту представлений на рисунку 4, в.

 

Рисунок 4 – Запит на вибірку з критеріями відбору рядків: а) сітка QBE із запитом на вибірку даних про розташовані в місті Глазго об'єкти нерухомості, для яких орендна плата встановлена в діапазоні від 350 до 450 грн.; б) результуюча сітка з даними цього запиту; в) еквівалентний SQL-оператор запиту

 

Припустимо, що тепер потрібно так змінити даний запит, щоб одночасно вибиралися і відомості про всі об'єкти нерухомості, розташовані у місті 'Aberdeen', причому встановлений для них розмір орендної плати не має значення. Для цього досить помістити значення 'Aberdeen' в комірку рядка or під коміркою зі значенням 'Glasgow' стовпця City. Вид сітки QBE з даним розширеним варіантом запиту представлений на рисунку 5,а. Після виконання цього запиту буде виведена сітка даних, що містить записи, які відповідають зазначеному критерію, – вона показана на рисунку 5,б. Еквівалентний SQL-оператор для даного запиту представлений на рисунку 5, в. Зверніть увагу, що в цьому випадку вважаються такими, що задовільняють встановленому критерію, всі записи, у яких поле City містить значення 'Glasgow' та (оператор And) значення в полі Rent розташоване в діапазоні від 350 до 450 грн., або (оператор Or) записи, у яких значення в полі City дорівнює 'Aberdeen'.

При визначенні значень, які варто вибирати, можуть використовуватися символи підстановки або оператор LIKE. У цьому випадку відбір буде вестися по заданій початковій частині значення або у відповідності зазначеному більш складному шаблону. Наприклад, припустимо, що необхідно вибрати відомості про об'єкти нерухомості, розташовані у місті 'Glasgow', однак написання назви цього міста англійською мовою викликає у вас сумнів. У цьому випадку можна скористатися конструкцією з оператором LIKE і помістити в клітинку Criteria стовпця City вираз 'LIKE Glasgo'. В альтернативному варіанті для досягнення того ж самого результату можна використати символи підстановки й помістити в ту ж комірку значення 'Glasg*', якщо точна кількість букв у назві міста нам невідома. Символ підстановки (*) вказує місце розташування довільної кількості символів. Якщо ми точно знаємо довжину необхідного значення, можна ввести як критерій значення 'Glasg??'. Символ підстановки (?) вказує місце розташування єдиного невідомого символу.

 

Рисунок 5 – використання складних критерії відбору рядків: а) сітка QBE із запитом на вибірку даних про розташовані в місті Глазго об'єкти нерухомості, для яких орендна плата встановлена в діапазоні від 350 до 450 грн., і про всі об'єкти в місті Абердин, незалежно від розміру орендної плати; б) результуюча сітка з даними запиту; в) еквівалентний SQL-оператор запиту

 

2.2 Створення багатотабличних запитів

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

Для того, щоби вибрати необхідні дані відразу з декількох таблиць, варто підготувати запит на вибірку даних; у вікні запиту будуть представлені всі необхідні таблиці, а критерій відбору буде визначений у сітці QBE. Наприклад, для вибірки імені й прізвища власників об'єктів нерухомості із вказанням облікових номерів належних їм об'єктів, а також назв міст, у яких ці об'єкти розташовані, варто створити запит, показаний на рисунку 6,а. Списки полів цільових таблиць запиту (а саме таблиць Owner й Property_for_Rent) розміщені у вікні запиту над сіткою QBE. У результуючу таблицю запиту з таблиці Owner вибираються стовпці FName та LName, а з таблиці Property_for_Rent – стовпці Pno й City. Після виконання даного запиту буде виведена сітка даних, що містить записи, які відповідають зазначеному критерію, – вона показана на рисунку 6,б. Еквівалентний SQL-оператор для даного запиту представлений на рисунку 6, в.

Рисунок 6 – запит на вибірку до двох таблиць: а) сітка QBE із багатотабличним запитом, призначеним для вибірки імен і прізвищ власників об'єктів нерухомості із зазначенням облікових номерів належних їм об'єктів і назв міст, у яких ці об'єкти розташовані; б) результуюча сітка з даними запиту; в) еквівалентний SQL-оператор запиту

 

Багатотабличний запит, показаний на рисунку 6, являє приклад запиту із внутрішнім (природним) з'єднанням, яке докладно обговорювалося у відповідній лекції з матеріалом про реляційну алгебру.

Якщо у вікно запиту поміщається більше однієї цільової таблиці, варто переконатися, що списки їхніх полів зв'язані між собою лініями з'єднання – тобто СКБД Microsoft Access знає, як з'єднати таблиці одну з одною. Зверніть увагу, що на рисунку 6,а СКБД Access помістила над верхньою частиною лінії з'єднання символ 1, що вказує на одиничну сторону зв'язку типу "один до багатьох". Над нижньою частиною лінії з'єднання поміщений символ ∞, що відзначає множинній стороні цього ж зв'язку. Це означає, що в нашому прикладі один власник може володіти багатьма об'єктами нерухомості, які здаються в оренду.

Якщо СКБД Access не виконала з'єднання таблиць автоматично або якщо між даними таблицями ще не був описаний який-небудь зв'язок, то таблиці у вікні запиту не будуть зв'язані лінією з'єднання. Можливість вибірки зв'язаних даних із двох таблиць зберігається, але буде потрібно вказати спосіб з'єднання цих таблиць безпосередньо при створенні запиту у вікні сітки QBE. Однак, для того, щоби дві таблиці можна було з'єднати безпосередньо в запиті, в обох таблицях повинні існувати зв'язані поля. У прикладі, показаному на рисунку 6, поле Ono (Особистий номер власника) є загальним для обох таблиць – Owner й Property_for_Rent. Для того щоб з'єднання працювало коректно, обидва стовпці повинні містити однакові значення у зв'язаних записах даних.

 

2.3 Запити з узагальненням

Досить часто з'являється необхідність узагальнення тієї або іншої групи даних. Наприклад, скільки здаваних в оренду об'єктів є в кожному з місті? Чому дорівнює середня заробітна плата працівників компанії? Скільки разів оглядався кожен зі здаваних в оренду об'єктів з початку поточного року?

Операцію узагальнюючих обчислень над групою записів можна виконати за допомогою запитів з підведенням підсумків (іноді їх називають узагальнюючими запитами). СКБД Microsoft Access дозволяє робити різні типи підсумкових обчислень, включаючи функції підсумовування (Sum), обчислення середнього значення (Avg), пошуку мінімального (Min) або максимального (Max) значення, а також підрахунку екземплярів (Count). Щоб одержати доступ до цих функцій, варто змінити тип запиту на Totals, у результаті чого в сітці QBE буде відображений додатковий рядок з назвою Total. Після виконання узагальнюючого запиту відображається таблиця, що містить моментальний знімок стану даних – набір рядків, який не допускає внесення змін.

Як й у випадку запитів інших типів, у запиті з підведенням підсумків може бути зазначений деякий критерій відбору записів. Наприклад, припустимо, що потрібно визначити загальну кількість об'єктів нерухомості, здаваних в оренду в кожному з міст. Для цього необхідно спочатку згрупувати дані про об'єкти за значенням поля City, для чого використовується функція Group By, після чого виконати для кожної групи обчислення підсумкового значення за допомогою функції Count. Загальний вид сітки QBE з подібним запитом показаний на рисунку 7,а, а результуюча сітка даних представлена на рисунку 7,б. На цьому ж рисунку показаний еквівалентний SQL-оператор даного запиту.

 

Рисунок 15.7 – Запит з узагалненнями: а) сітка QBE з узагальнюючим запитом, призначеним для визначення кількості об'єктів нерухомості, які здаються в оренду в кожному з міст; б) результуюча сітка даних цього запиту; в) еквівалентний SQL-оператор запиту

 

Для виконання деяких обчислень може знадобитися підготувати власний вираз. Наприклад, припустимо, що потрібно обчислити суму річної орендної плати для кожного з об'єктів нерухомості, відомості про який є в таблиці Property_for_Rent, із зазначенням значень номера об'єкта (Pno), міста (City) і типу об'єкта (Type). Сума річної орендної плати для кожного з об'єктів обчислюється за допомогою множення суми місячної орендної плати на кількість місяців у році. Для проведення цих обчислень в окремий стовпець сітки QBE варто помістити вираз 'Yearly Rent: [Rent]*12', як показано на рисунку 8,а. У цьому виразі частина 'Yearly Rent:' являє собою ім'я нового стовпця, а частина, що залишилася, – '[Rent]*12' – задає формулу обчислення значень, що поміщають у нього, як добуток значення поля Rent кожного запису на число 12. Результуюча сітка даних запиту показана на рисунку 8,б. На рисунку 8,в представлений еквівалентний SQL-оператор цього запиту.

 

Рисунок 8 – Запит з обчисленнями: а) сітка QBE із запитом на вибірку, що передбачає обчислення суми річної орендної плати для кожного здаваного в оренду об'єкта нерухомості; б) результуюча сітка даних цього запиту; в) еквівалентний SQL-оператор запиту

 

3 Більш складні типи QBE-запитів

 

3.1. Параметричні запити

Параметричні запити дозволяють вивести одне або більш заздалегідь визначених діалогових вікон, призначених для вводу користувачем конкретних значень параметрів запиту (критеріїв). Параметричні запити створюються за допомогою вводу в комірку Criteria тексту звертання до користувача, поміщеного в квадратні дужки. Ці дії виконуються для кожного стовпця, значення якого повинне вказуватися як параметр. Наприклад, припустимо, що потрібно так доробити запит, показаний на рисунку 6,а, щоб користувач міг ввести ім'я й прізвище власника об'єктів нерухомості, для якого необхідно вибрати відомості про приналежні йому об'єкти. Сітка QBE з подібним параметричним запитом представлена на рисунку 9,а. Для вибірки відомостей про об'єкти нерухомості, що належать власникові з іменем 'Carol Farrel', необхідно ввести відповідні значення імені й прізвища власника в перші й друге діалогові вікна, показані на рисунку 9,б. Вміст отриманої в результаті виконання даного запиту сітки даних представлено на рисунку 9, в, а еквівалентний SQL-оператор запиту – на рисунку 9, г.

 

Рисунок 9 – Параметричний запит: а) сітка QBE з визначенням параметричного запиту; б) діалогові вікна для уведення значень імені й прізвища власника об'єктів нерухомості; в) сітка з даними, вибраними в результаті виконання запиту; г) еквівалентний SQL-оператор запиту

 

3.2 Перехресні запити

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

Для створення перехресних запитів можна скористатися майстром CrossTab Query Wizard або ж визначити його власними силами в сітці QBE. Створення перехресного запиту нагадує створення запитів з підведенням підсумків, однак тепер додатково буде потрібно вказати поля, які будуть використатися як заголовки стовпців і рядків, а також поля, що містять вихідні значення даних.

Наприклад, припустимо, що для кожного працівника компанії необхідно визначити кількість об'єктів нерухомості, розташованих у кожному з районів міста Глазго, за які він відповідає. Для підвищення наочності результатів виконання даного запиту ми помістили в таблицю Property_for_Rent кілька нових записів про об'єкти нерухомості. При підготовці даного запиту насамперед варто створити запит з підведенням підсумків, показаний на рисунку 10,а. У результаті його виконання буде отримана сітка даних, представлена на рисунку 10,б; еквівалентний SQL-оператор цього запиту показаний на рисунку 10,в. Однак формат подання результатів запиту незручний для проведення порівняльного аналізу даних по кожному із працівників. Зверніть увагу,  що на рисунку 10,а відмітка опції в комірці Show стовпця City не встановлена, тому даний стовпець відсутній у сітці з результатами запиту, представленій на рисунку 10,б.

 

Рисунок 10 – Узагальнюючий запит як перша стадія підготовки перехресного запиту: а) сітка QBE, що містить   приклад запиту з підведенням підсумків; б) результуюча сітка даних запиту; в) еквівалентний SQL-оператор запиту

 

Для перетворення запиту на вибірку даних у перехресний запит варто змінити тип запиту на Crosstab, у результаті чого в сітку QBE буде поміщений додатковий рядок Crosstab. Тепер у нас з'явилася можливість вказати поля, значення яких будуть використовуватися як заголовки стовпців і рядків або ж як вихідні дані для підсумовування. Модифікований варіант вихідного запиту показаний на рисунку 11,а. Після виконання нової версії запиту сітка з результатами буде більш компактною – як показано на рисунку 11,б. Її формат дозволяє легко проводити порівняльний аналіз показників окремих співробітників компанії. Текст еквівалентного SQL-оператора запиту показаний на рисунку 11, в.

Рисунок 11 – Перехресний запит: а) сітка QBE із прикладом перехресного запиту; б) результуюча сітка даних запиту; в) еквівалентний SQL-оператор запиту

 

3.3 Запити на вибірку дублікатів

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

Припустимо, що в якийсь момент ненавмисно був повторно створений запис про власника об'єктів нерухомості з іменем 'Carol Farrel', причому цьому запису був присвоєний власний унікальний номер власника. У результаті в базі даних з'явилося два записи з різними унікальними номерами власника, що описують  ту  саму  людину.   Для  виявлення  подібної  ситуації  можна скористатися запитом на вибірку дублікатів, створеним за допомогою майстра Find Duplicates Query Wizard, доступ до якого можна одержати в діалоговому вікні, показаному на рисунку 2. У цьому запиті відбір записів буде вестися за співпадаючим значенням у зазначених полях (у нашому прикладі ми для простоти обмежимося полями FName й LName). Як уже згадувалося вище, майстер створює запит на основі відповідей, наданих користувачем на задані цим майстром питання. Перш ніж запустити знову створений запит, має сенс подивитися на сітку QBE з даним запитом на вибірку продубльованих значень, показану на рисунку 12,а. Результуюча сітка даних запиту, що містить два рядки про власника по імені 'Carol Farrel', представлена на рисунку 12,б, а текст еквівалентного SQL-оператора – на рисунку 12,в. Зверніть увагу, що в останньому випадку SQL-оператор відображено повністю, включаючи й вкладений SQL-запит SELECT, який у рядку Criteria стовпця FName сітки QBE показаний лише частково.

 

Рисунок 12 – Запит на знаходження дублікатів: а) сітка QBE із прикладом запиту на вибірку дублікатів; б) результуюча сітка даних запиту; в) еквівалентний SQL-оператор запиту

 

3.4 Запити на вибірку записів, що не мають відповідників

За допомогою майстра Find Unmatched Query Wizard, доступ до якого здійснюється з діалогового вікна, показаного на рисунку 2, можна відшукати всі записи зазначеної таблиці, які не мають зв'язаних записів в іншій таблиці. Наприклад, можна вибрати відомості про тих орендарів, які ще не оглядали які-небудь здавані в оренду об'єкти нерухомості – за допомогою порівняння записів таблиць Renter й Viewing. Майстер створить запит на основі наданих йому відповідей. Перш ніж аналізувати результати виконання запиту на вибірку невідповідних рядків, подивіться на його сітку QBE, загальний вид якої показаний на рисунку 13,а. Результуюча сітка даних запиту представлена на рисунку 13,б. Її вміст показує, що в таблиці Renter існує тільки один запис, для якого в таблиці Viewing немає ніодного зв'язаного запису. Він відноситься до орендаря з іменем 'Mike Ritchie'. Еквівалентний SQL-оператор запиту представлений на рисунку 13,в.

 

Рисунок 13 – Запит на пошук рядків без відповідників у зв’язаній таблиці: а) сітка QBE із прикладом запиту на вибірку записів, що не має відповідності; б) результуюча сітка даних запиту; в) еквівалентний SQL-оператор запиту

 

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

 

3.5 Запити з автопідстановкою

Запити з автопідстановкою можуть використовуватися для автоматичного поміщення значень у певні поля знову створюваних записів. При введенні у вікні запиту або у вікні створеної на базі цього запиту форми деякого значення в поле, використовуване для з'єднання двох таблиць, СКБД Microsoft Access автоматично відшукає й помістить у зазначене місце інформацію, що відповідає введеному користувачем значенню. Якщо нам відоме значення, яке повинно бути поміщене в поле, використовуване для з'єднання таблиць, – наприклад, поле особистого номера працівника (Sno), використовуване для з'єднання таблиць Property_for_Rent та Staff, – то після вводу необхідного особистого номера працівника СКБД автоматично заповнить поля, що залишилися, інформацією про даного працівника. Якщо для введеного значення не буде знайдено відповідного запису, СКБД виведе повідомлення про помилку.

Для створення запиту з автопідстановкою варто помістити в сітку QBE дві таблиці, між якими існує зв'язок типу "один до багатьох", після чого вказати поля, які повинні бути поміщені в результуючу сітку запиту. Поле з'єднання повинне бути обране з таблиці, що відповідає множинній стороні зв'язку. Наприклад, у запиті, що містить поля таблиць Property_for_Rent й Staff, поле Sno (зовнішній ключ) варто вибрати з таблиці Property_for_Rent. Вид сітки QBE з подібним запитом показаний на рисунку 14,а.

 

Рисунок 14 – Запит з автопідстановкою: а) сітка QBE із прикладом запиту з автоподстановкой; б) результуюча сітка даних запиту; в) еквівалентний SQL-оператор запиту

 

Ще раз зверніть увагу на те, що поле з'єднання таблиць Sno обрано з таблиці, що представляє множинну частину зв'язку. На рисунку 14,б показана результуюча сітка даних цього запиту, що дозволяє вводити номер об'єкта нерухомості, який добавляється, назву вулиці й місто, у якому він розташований. Далі можна буде ввести особистий номер працівника (наприклад, 'SG37'), що призначається відповідальним за цей об'єкт. Як тільки це поле буде заповнено, СКБД Microsoft Access автоматично виконає пошук у таблиці Staff і помістить ім'я й прізвище зазначеного працівника у відповідні поля форми. На рисунку 14,в показаний еквівалентний SQL-оператор даного запиту з автопідстановкою.

 

4 Зміна вмісту таблиць за допомогою активних запитів

 

При створенні запиту СКБД Microsoft Access звичайно створює запит на вибірку даних, якщо тільки в меню Query не буде обраний який-небудь інший тип запиту. Після виконання запиту на вибірку СКБД відображає його результуючу сітку даних. Якщо ця сітка допускає відновлення даних, що містяться в ній, то необхідні зміни можна вносити безпосередньо в результати виконання запиту, однак у цьому випадку записи можна буде модифікувати тільки поодинці, послідовно, один за одним.

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

 

4.1 Активні запити створення таблиць

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

Припустимо, що потрібно створити нову таблицю StaffCut, що повинна містити стовпці Sno, FName, LName, Position й Salary, заповнені даними з існуючої таблиці Staff. Насамперед необхідно підготувати запит, призначений для вибору зазначених полів з таблиці Staff. Потім у режимі Design View варто змінити тип створеного запиту на Make-Table, у результаті чого на екран буде виведене діалогове вікно, показане на рисунку 15,а.

 

Рисунок 15 – Запит на створення таблиці: а) діалогове вікно Make Table; б) сітка QBE із прикладом запиту створення таблиці; в) вид вікна попереджуючого повідомлення; г) результуюча сітка даних запиту; д) еквівалентний SQL-оператор запиту

 

Це діалогове вікно містить пропозицію вказати ім'я й місце розташування нової таблиці. На рисунку 15,б показана сітка QBE з підготовленим активним запитом створення таблиці. Після запуску запиту на виконання СКБД виведе попереджуюче повідомлення із пропозицією вказати, чи варто продовжити операцію створення нової таблиці. Вид цього повідомлення представлений на рисунку 15,в. Якщо створення таблиці буде продовжено, СКБД створить нову таблицю з іменем StaffCut, вміст якої показано на рисунку 15,г. Еквівалентний SQL-оператор запиту представлений на рисунку 15,д.

 

4.2 Активні запити видалення

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

Наприклад, припустимо, що потрібно видалити всі відомості про об'єкти нерухомості, розташовані у місті Глазго, а також всі пов'язані з ними записи про огляди об’єктів нерухомості. Для виконання цієї операції насамперед варто створити запит, призначений для вибірки відповідних відомостей з таблиці Property_for_Rent. Потім у режимі Design View тип запиту повинен бути змінений на Delete. Сітка QBE зі створеним активним запитом видалення показана на рисунку 16,а. Оскільки між таблицями Property for_Rent й Viewing існує зв'язок типу "один до багатьох", причому для неї встановлене правило підтримки цілісності посилань Cascade Delete Related records, будуть вилучені всі рядки таблиці Viewing, що містять відомості про огляди об'єктів, розташовані у місті Глазго. При запуску запиту на виконання система виведе попереджуюче повідомлення, яке пропонує підтвердити необхідність продовження операції видалення. Загальний вид вікна цього повідомлення показаний на рисунку 16,б. Якщо виконання операції видалення буде продовжено, система видалить всі записи таблиці Property_for_Rent, що відповідають заданій умові, а також всі пов'язані з ними записи таблиці Viewing – як показано на рисунку 16,в і г. Еквівалентний SQL-оператор запиту представлений на рисунку 16, д.

 

Рисунок 16 – Запит на видалення рядків: а) сітка QBE із прикладом активного запиту видалення; б) вид попереджуючого повідомлення; в) вміст таблиці Property_for_Rent після видалення записів; г) вміст таблиці Viewing після видалення записів; д) еквівалентний SQL-оператор запиту

 

4.3 Активні запити оновлення

Активні запити оновлення виконують глобальні оновлення в групах записів однієї або більше таблиць. Наприклад, припустимо, що орендну плату за всі здавані в оренду об'єкти необхідно збільшити на 10%. Для виконання подібного оновлення насамперед треба створити запит на вибірку даних з таблиці Property_for_Rent. Потім у режимі Design View варто змінити тип запиту на Update. В комірку Update To стовпця Rent необхідно помістити вираз '[Rent]* 1.1' – як показано на рисунку 17,а. Після запуску запиту на виконання система виведе попереджуюче повідомлення, показане на рисунку 17,б, що містить пропозицію підтвердити необхідність виконання операції оновлення. Якщо виконання операції буде продовжено, система обновить значення в стовпці Rent таблиці Property_for_Rent, як показано на рисунку 17,в. Еквівалентний SQL-оператор запиту представлений на рисунку 17,г.

 

Рисунок 17 – Запит на оновлення даних: а) сітка QBE із прикладом активного запиту відновлення; б) вид вікна попереджуючого повідомлення; в) результуюча сітка даних запиту; г) еквівалентний SQL-оператор запиту

 

4.4 Активні запити додавання записів

Активні запити додавання записів призначені для вставки записів з однієї або більше вихідних таблиць у єдину цільову таблицю. Записи можуть бути додані в кінець таблиці, що належить тій же самій або іншій базі даних. Запити додавання записів можуть бути корисні при додаванні рядків (виходячи із заданого критерію) або навіть у тих випадках, коли деяких полів в іншій таблиці не існує. Наприклад, припустимо, що необхідно помістити в таблицю Owner докладні відомості про нових власників об'єктів нерухомості, які здаються в оренду. Припустимо також, що відомості про цих нових власників перебувають у таблиці з іменем NewOwner, що містить тільки стовпці Ono, FName, LName й Address. Більше того, у таблицю Owner потрібно помістити відомості тільки про тих нових власників, які проживають у місті Глазго. У цьому прикладі таблиця Owner є цільовою таблицею запиту, а таблиця NewOwner – вихідною.

Створення активного запиту додавання записів варто почати з підготовки звичайного запиту, призначеного для добування необхідної інформації з вихідних таблиць – у нашому випадку це таблиця NewOwner. Потім тип знову створеного запиту варто змінити на Append, у результаті чого на екран буде виведене діалогове вікно, показане на рисунку 18,а.

 

Рис. 15.18: а) діалогове вікно Append; б) сітка QBE із прикладом активного запиту додавання записів; в) вид вікна з попереджуючим повідомленням; г) уміст таблиць NewOwner й Owner після виконання запиту; д) еквівалентний SQL-оператор запиту

 

Це діалогове вікно призначене для вказівки імені й розташування цільової таблиці створюваного запиту додавання. Сітка QBE з підготовленим активним запитом додавання записів показана нарисунку 18,б.  Після запуску запиту на виконання  система виведе попереджуюче повідомлення, вид якого показано на рисунку 18,в. У цьому повідомленні користувачеві пропонується підтвердити необхідність виконання операції додавання записів. Якщо виконання запиту буде продовжено, у таблицю Owner будуть додані два нові записи з даними про власників об'єктів нерухомості з міста Глазго, вибрані з таблиці NewOwner, як показано на рисунку 18,г. Еквівалентний SQL-оператор запиту представлений на рисунку 18,д.


Русский язык и культура речи

перейти к оглавлению

1. ЭЛЕМЕНТЫ И УРОВНИ ЯЗЫКА

Характеризуя язык как систему, необходимо определить, из каких элементов он состоит. В большинстве языков мира выделяются следующие единицы: фонема (звук), морфема, слово, словосочетание и предложение. Единицы языка неоднородны по своему строению: простые (фонемы) и сложные (словосочетания, предложения). При этом более сложные единицы всегда состоят из более простых.

Самая простая единица языка – это фонема, неделимая и сама по себе...

законы диалектики

Основные законы диалектики.

1)Закон единства и борьбы противоположностей.

Этот закон является «ядром» диалектики, т.к. определяет источник развития, отвечает на вопрос, почему оно происходит.

Содержание закона: источник движения и развития мира находится в нем самом, в порождаемых им противоречиях.

Противоречие – это взаимодействие противоположных сторон, свойств и тенденций в составе той или иной системы или между системами. Диалектическое противоречие есть только там, где...

Математические формулы. Шпаргалка для ЕГЭ с математики

Формулы сокращенного умножения

(а+b)2 = a2 + 2ab + b2

(а-b)2 = a2 – 2ab + b2

a2 – b2 = (a-b)(a+b)

a3 – b3 = (a-b)( a2 + ab + b2)

a3 + b3 = (a+b)( a2 – ab + b2)

(a + b)3 = a3 + 3a2b+ 3ab2+ b3

(a – b)3 = a3 – 3a2b+ 3ab2- b3

Свойства степеней

a0 = 1 (a≠0)

am/n = (a≥0, n ε N, m ε N)

a- r = 1/ a r (a>0, r ε Q)

m...

Идеология

1.Идеология как социальный феномен, её сущность. Содержание идеологииСоциально-исторической системой представлений о мире стала идеология как система рационально- логического обоснования поведения людей, их ценностей, норм взаимоотношений, целей и т.д. Идеология как явление во многом сходна с религией и с наукой. От науки она восприняла доказательность и логичность своих постулатов, но, в отличие от науки, идеология призвана давать оценку явлениям действительности (что хорошо, что...