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

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

БД -mike

Тема 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). Для простоти викладу опустимо деталі, що відносяться до співробітників компанії, різним її відділенням і власникам нерухомості, що представляє собою юридичні особи.

 

Pucунок 1.1 – Схема обробки даних у файловій системі

 

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

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

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

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

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

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

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

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

Коли дані ізольовані в окремих файлах, доступ до них досить утруднений. Наприклад, для створення списку всіх будинків, що відповідають вимогам потенційних орендарів, попередньо потрібно створити тимчасовий файл зі списком орендарів, що бажають орендувати нерухомість типу "будинок". Потім у файлі 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.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 Загальний огляд процедур проектування баз даних

 

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

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

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

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

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

 

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.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. Обговорення глобальної логічної моделі даних з користувачами.

12.4 Фізичне проектування баз даних

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.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 Динамічне хешування

 

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

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

Основний принцип динамічного хешування полягає в обробці числа, виробленого хеш-функцією у вигляді послідовності бітів, і розподілі записів по сегментах на основі так званого прогресуючого оцифровування (progressive digitization) цієї послідовності. Динамічна хеш-функція виробляє значення в широкому діапазоні, а саме В-бітові двійкові цілі числа, де В зазвичай рівне 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 рекомендує використовувати хешовані кластери за наступних умов:

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

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

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

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-моделювання не використовується, а вивчення даних в обговорюваній формі відбувається безпосередньо в процесі нормалізації.

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. Проте слід ще раз нагадати, що два наведені підходи коректні і зрештою – при продовженні процесу нормалізації аж до НФБК – приведуть до створення однакових відношень.

Друга нормальна форма (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

 

 

Третя нормальна форма (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.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 володітиме надлишковістю даних.

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

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

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

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

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

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

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

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

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

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

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

 

Як було сказано вище, НФБК – дозволяє усунути будь-які аномалії, викликані функціональними залежностями. Проте в результаті теоретичних досліджень був виявлений ще один тип залежності – багатозначна залежність (Multi-Valued Dependency – 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.

 П'ята нормальна форма (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

Тема 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 (INteractive GRaphicsREtrieval 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 фірми Computer Associates, тепер називається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 показані відповідності, що існують між трьома згаданими вище групами термінів.

Реляційні оператори

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

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

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

 

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 – незалежність від розподілу даних.

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

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

CASE-засоби проектування баз даних

 

7.1 Основи методології проектування ІС і класифікація CASE-засобів

 

Метою даного заняття ставиться подання основ особливо сучасних методів і засобів проектування інформаційних систем, заснованих на використанні CASE-технології (CASE – Computer Aided System Engineering). Студент повинен отримати базу для забезпечення можливості ухвалення обгрунтованого, а не вольового рішення щодо використання цих технологій. Рекомендації, що приводяться, можуть сприяти успішному впровадженню CASE-засобів і зменшити ризик неправильних інвестицій.

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

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

Структура ЖЦ ПЗ за стандартом ISO/IEC 12207 базується на трьох групах процесів:

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

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

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

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

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

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

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

Інтегрований CASE-засіб (або комплекс засобів, що підтримують повний ЖЦ ПЗ) містить наступні компоненти;

  • репозиторій, що є основою CASE-засобу. Він повинен забезпечувати зберігання версій проекту і його окремих компонентів, синхронізацію надходження інформації від різних розробників при груповій розробці, контроль метаданих на повноту і несуперечність;
  • графічні засоби аналізу і проектування, забезпечуючи створення і редагування ієрархічно зв'язаних діаграм (DFD, ERD і ін.), створюючих моделі ІС;
  • засоби розробки застосувань, включаючи мови 4GL і генератори коду;
  • засоби конфігураційного управління;
  • засоби документування;
  • засоби тестування;
  • засоби управління проектом;
  • засоби реінжинірингу.

Всі сучасні CASE-засоби можуть бути класифіковані в основному за типами і категоріями. Класифікація за типами відображає функціональну орієнтацію CASE-засобів на ті або інші процеси ЖЦ. Класифікація за категоріями визначає ступінь інтегрованості за виконуваними функціями і включає окремі локальні засоби, що вирішують невеликі автономні завдання (tools), набір частково інтегрованих засобів, що охоплюють більшість етапів життєвого циклу ІС (toolkit) і повністю інтегровані засоби, що підтримують весь ЖЦ ІС і зв'язані загальним репозиторієм. Крім цього, CASE-засоби можна класифікувати за наступними ознаками:

  • вживаними методологіями і моделями систем і БД;
  • ступені інтегрованості з СКБД;
  • доступними платформами.

Класифікація за типами в основному співпадає з компонентним складом CASE-засобів і включає наступні основні типи:

  • засоби аналізу (Upper CASE), призначені для побудови і аналізу моделей наочної області (Design/IDEF (Meta Software), BPwin (Logic Works));
  • засоби аналізу і проектування (Middle CASE), підтримуючі найбільш поширені методології проектування і котрі використовуються для створення проектних специфікацій (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (Макропроджект)). Виходом таких засобів є специфікації компонентів і інтерфейсів системи, архітектура системи, алгоритмів і структур даних;
  • засоби проектування баз даних, що забезпечують моделювання даних і генерацію схем баз даних (як правило, на мові SQL) для найбільш поширених СКБД. До них відносяться ERwin (Logic Works), S-Designor (SDP) і DataBase Designer (ORACLE). Засоби проектування баз даних є також у складі CASE-засобів Vantage Team Builder, Designer/2000, Silverrun і PRO-IV;
  • засоби розробки застосувань. До них відносяться засоби 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) і ін.) і генератори коду, що входять до складу Vantage Team Builder, PRO-IV і частково – в Silverrun;
  • засоби реінжинірингу, що забезпечують аналіз програмного коду і схем баз даних і формування на їх основі різних моделей і проектних специфікацій. Засоби аналізу схем БД і формування ER-діаграм входять до складу Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin і S-Designor. В області аналізу програмного коду найбільшого поширення набувають об'єктно-орієнтовані CASE-засоби, що забезпечують реінжиніринг програм на мові С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Допоміжні типи включають:

  • засоби планування і управління проектом (SE Companion, Microsoft Project і ін.);
  • засоби конфігураційного управління (PVCS (Intersolv));
  • засоби тестування (Quality Works (Segue Software));
  • засоби документування (SODA (Rational Software)).

На сьогоднішній день ринок програмного забезпечення має в своєму розпорядженні наступні найбільш розвинені CASE-засоби:

  • Vantage Team Builder (Westmount I-CASE);
  • Designer/2000;
  • Silverrun;
  • ERwin+BPwin;
  • S-Designor;
  • CASE.Аналитик.

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

Технологія впровадження CASE-засобів базується в основному на стандартах IEEE (IEEE – Institute of Electrical and Electronics Engineers – Інститут інженерів по електротехніці і електроніці). Термін "впровадження" використовується в широкому сенсі і включає всі дії від оцінки первинних потреб до повномасштабного використання CASE-засобів в різних підрозділах організації-користувача. Процес впровадження CASE-засобівскладається з наступних етапів:

  • визначення потреб в CASE-засобих;
  • оцінка і вибір CASE-засобів;
  • виконання пілотного проекту;
  • практичне впровадження CASE-засобів.

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

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

 

7.2 Методологія IDEF1

 

Метод IDEF1, розроблений Т.Рэмейєм (T.Ramey), також заснований на підході П.Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі в третій нормальній формі. У цей час на основі вдосконалювання методології IDEF1 створена її нова версія – методологія IDEF1X. IDEF1X розроблена з урахуванням таких вимог, як простота вивчення й можливість автоматизації. IDEF1X-діаграми використаються рядом розповсюджених CASE-засобів (зокрема, ERwin, Design/IDEF).

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

 

Рисунок 7.1 – Зображення сутностей згідно методології IDEF1

 

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

Зв'язок може додатково визначатися за допомогою зазначення ступеня або потужності (кількості екземплярів сутності-нащадка, яка може існувати для кожного екземпляра сутності-батька). В IDEF1X можуть бути виражені наступні ступені зв'язків:

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

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

Зв'язок зображується лінією, проведеною між сутністю-батьком і сутністю-нащадком із точкою на кінці лінії в сутності-нащадку. Потужність зв'язку позначається як показано на рисунку 7.2 (потужність за замовчуванням – N).

 

Рисунок 7.2 – Позначення потужностей зв'язку

 

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

 

Рисунок 7.3 – Ідентифікуючий зв'язок

 

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

 

Рисунок 7.4 – Неідентифікуючий зв'язок

 

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

 

Рисунок 7.5 – Атрибути й первинні ключі

 

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

 

Рисунок 7.6 – Приклади зовнішніх ключів

 

7.3 Опис деяких локальних CASE-засобів

 

ERwin – засіб концептуального моделювання БД, що використає методологію IDEF1X. ERwin реалізує проектування схеми БД, генерацію її опису мовою цільовоъ СКБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server та ін.) і реінжиніринг існуючої БД. ERwin випускається в декількох різних конфігураціях, орієнтованих на найпоширеніші засоби розробки додатків 4GL. Версія ERwin/OPEN повністю сумісна із засобами розробки додатків PowerBuilder та SQLWindows і дозволяє експортувати опис спроектованої БД безпосередньо в репозиторії даних засобів.

Для ряду засобів розробки додатків (PowerBuilder, SQLWindows, Delphi, Visual Basic) виконується генерація форм і прототипів додатків.

Мережева версія Erwin ModelMart забезпечує погоджене проектування БД і додатків у рамках робочої групи.

BPwin – засіб функціонального моделювання, що реалізує методологію IDEF0.

S-Designer являє собою CASE-засіб для проектування реляційних баз даних. За своїми функціональними можливостями і вартості він близький до CASE-засобу ERwin, відрізняючись зовні використовуваною на діаграмах нотацією. S-Designer реалізує стандартну методологію моделювання даних і генерує опис БД для таких СКБД, як ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server й ін. Для існуючих систем виконується реінжиніринг БД.

S-Designer сполучимо з рядом засобів розробки додатків (PowerBuilder, Uniface, TeamWindows й ін.) і дозволяє експортувати опис БД у репозиторії даних засобів. Для PowerBuilder виконується також пряма генерація шаблонів додатків.

CASE.Аналітик є практично єдиним у цей час конкурентноздатним вітчизняним CASE-засобом функціонального моделювання й реалізує побудову діаграм потоків даних (методологія потоків даних описує ще один спосіб проектування базданих). Його основні функції:

  • побудова й редагування DFD (Data Flow Diagramm);
  • аналіз діаграм і проектних специфікацій на предмет повноти й несуперечності;
  • одержання різноманітних звітів по проекту;
  • генерація макетів документів відповідно до вимог ГОСТ 19.ХХХ та 34.ХХХ.

База даних проекту реалізована у форматі СКБД Paradox й є відкритою для доступу.

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

Вступ до мови структурованих запитів 
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.

Складні запити на вибірку

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 BY s . branchNo, s.staffNo ORDERBY 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 * FROM Branch 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 WHERE p.city = b.city);

Таблиця 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 співробітників. На жаль, рівень підтримки реляційної цілісностів різних системах істотно відмінний.

Зміна вмістимого бази даних.

Для зміни вмістимого бази даних в мові 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 – мова означення даних).

Створення бази даних та її елементів засобами 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) у БД і вона (база даних) переходить у новий узгоджений стан. Коли транзакція повністю не виконується, то всі її дії відміняються. У цьому випадку в БД має бути відновлено той узгоджений стан, в якому вона перебувала до початку транзакції. Цей процес називається відкатом (roll back) транзакції (рисунок 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, то перевірка цілісності даних виконується в кінці транзакції. Інакше – негайно, тобто під час виконання транзакції (цей режим включено за замовчуванням).

1 Теоретичні відомості

 

За допомогою Microsoft Excel можна створювати і обробляти бази даних. База даних в Microsoft Excel – таблиця, що складається з однотипних записів (рядків). Стовпці таблиці є полями запису в базі даних. Під імена полів вииділяється перший рядок у таблиці. Наприклад, якщо базою даних вважати телефонний довідник, то полями запису будуть: прізвища, номери телефонів і адреси абонентів.

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

 

Рисунок 1.1 – Таблиця Microsoft Excel

 

1.1 Сортування даних

 

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

У полі прихованого переліку Сортировать по (рисунок1.2.) вибирається поле, по якому будуть відсортовані дані, і тип сортування:

"по возростанию"  – числа сортуються по зростанню, текст – за абеткою, логічні вирази – ЛОЖЬ передує ИСТИНА.

"по убыванию" – сортування в зворотному порядку.

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

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

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

 

Рисунок 1.2 –  Діалогове вікно сортування стовпців таблиці

 

1.2 Форми даних

 

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

При перегляді, зміні, додаванні і видаленні запису в базі даних, а також при пошуку конкретних записів за визначеним критерієм зручно використовувати форми даних. При звертанні до команди Форма меню Данные Microsoft Excel читає дані й створює діалогове вікно форми даних (рисунок 1.3.).

 

Рисунок 1.3 – Форма для роботи з таблицею Microsoft Excel як з таблицею БД

 

У формі даних на екран виводиться один запис. При уведенні або зміні даних у полях цього вікна змінюється уміст відповідних вічок у базі даних.Для використання форм даних таблиця повинна мати імена стовпців. Імена стовпців стають іменами полів у формі даних. Поле відповідає кожному стовпцю в таблиці. Форма даних автоматично розгортається так, щоб вивести на екран відразу усі поля в даній таблиці, до 32 полів за один раз. За допомогою смуги прокручування можна прокручувати записи в базі даних. Позиція виведеного запису вказується у верхньому правом куті. Пересуватись по полях форми можна за допомогою миші та клавіш Tab (униз),Shift+Tab (угору). Праворуч розташовані такі кнопки.

"Добавить" – очищує поля для уведення нового запису бази даних. Якщо знову натиснути кнопку Добавить, то уведені дані будуть додані як новий запис у кінець бази даних.

"Удалить" – видаляє виведений запис, інші записи бази даних зсуваються. Видалені записи не можуть бути відновлені.

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

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

"Далее" – виводить наступний запис у базі даних.

"Критерии" – очищає поля для уведення критеріїв порівняння з операторами порівняння для пошуку необхідної підмножини записів.

"Правка" – слугує для виходу з режиму уведення критеріїв. Доступна тільки тоді, коли натиснута кнопка Критерии.

"Очистить" – видаляє існуючий критерій із вікна діалогу. Доступна тільки тоді, коли натиснута кнопка Критерии.

"Закрыть" – закриває форму даних.

Для додавання запису до бази даних необхідно:

–   виділити вічко в таблиці, до котрого слід додати запис;

–   у меню "Данные" вибрати команду "Форма";

–   натиснути кнопку "Добавить";

–   заповнити поля нового запису;

–   для переміщення до наступного поля натиснути клавішу Тab;

–   після уведення даних натиснути клавішу Enter для додавання запису;

–   після додавання усіх необхідних записів, натиснути кнопку "Закрыть".

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

 

1.3 Встановлення інтервалу критеріїв

 

Критерії бувають двох типів.

1. Критерії обчислення – це критерії, що є результатом обчислення формули. Наприклад, інтервал критеріїв =F7>СРЗНАЧ($F$7:$F$21) виводить на екран рядки, що мають у стовпці F значення більше, ніж середнє значення розмірів у клітинках F7:F21. Формула повинна повертати логічне значення ЛОЖЬ або ИСТИНА. При фільтрації будуть доступні тільки ті рядки, значення яких будуть надавати формулі значення ИСТИНА.

2. Критерії порівняння – це набір умов для пошуку, використовуваний для вибору даних при запитах за прикладом. Критерій порівняння може бути послідовністю символів (константою) або виразом (наприклад, Ціна > 700).

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

–   виділити клітинку в таблиці;

–   в меню "Данные" вибрати команду "Форма";

–   натиснути кнопку "Критерии";

–   у полях редагування ввести критерії для пошуку даних;

–   для виводу на екран першого запису, що відповідає критерію, натиснути кнопку "Далее";

–   для виводу на екран попереднього запису, що відповідає  критерію, натиснути кнопку "Назад";

–   для пошуку записів у переліку по іншому критерію натиснути кнопку "Критерии" і ввести новий критерій;

–   по закінченні натиснути кнопку "Закрыть".

Щоб знову одержати доступ до усіх записів переліку, необхідно натиснути кнопку "Критерии", а потім натиснути кнопку "Правка".

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

 

1.4 Автофільтр

 

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

 

Рисунок 1.4 – Вигляд таблиці, підготовленої до відбору рядків з застосуванням автофільтру

 

Якщо у прихованому переліку вибрати пункт "Условие …" , то з’явиться вікно "Пользовательский автофильтр" (рисунок 1.5). У верхньому правому списку слід вибрати один з операторів (равнобольшеменьше та ін.), а у полі праворуч –  вибрати одне із значень. У нижньому правому списку можна вибрати іншій оператор, і у полі ліворуч – значення. Коли ввімкнений перемикач И, то будуть виводитися тільки записи, які задовільняють обидвом умовам. При увімкненому перемикачу ИЛИбудуть виводитися записи, які задовільняють одній з умов. Наприклад, у вікні на рисунку 1.5 введені умови для виведення записів з ціною більше 99 грн. і менше 187 грн.

 

Рисунок 1.5 – Діалогове вікно побудови умови відбору рядків таблиці через автофільтр

 

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

Щоб вивести усі дані переліку, необхідно викликати команду "Отобразить все" або скасувати команду "Автофильтр" меню "Данные", підміню "Фильтр".

 

1.5 Команда “Расширенный фильтр”

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

 

Рисунок 1.6 – Діалогове вікно побудови розширеного фільтру

 

"фильтровать список на месте" – перемикач, що приховує рядки, які не задовольняють зазначеному критерію;

"скопировать результат в другое место" – копіює відфільтровані дані на інший робочий лист, або на інше місце на тому ж робочому листі;

"Исходный диапазон" – поле, що визначає інтервал, якій містить перелік, що підлягає фільтрації;

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

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

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

Для встановлення складних критеріїв необхідно:

1.     Вставити декілька рядків у верхній частині робочого листа;

2.     В одному із вставлених порожніх рядків ввести імена стовпців, по яких слід відфільтрувати перелік;

3.     При використанні критеріїв порівняння, імена критеріїв повинні бути ідентичні іменам стовпців, що перевіряються;

4.     У рядках, розташованих під рядком із іменами стовпців, що перевіряються, ввести критерії, яким повинні відповідати клітинки стовпців, що перевіряються;

5.     Вибрати в меню "Данные" підменю "Фильтр", а потім команду "Расширенный фильтр", і в діалоговому вікні ввести умови фільтрації.

Для об'єднання критеріїв за допомогою умовного оператора И потрібно зазначити критерії в одному і тому ж рядку, а для об'єднання критеріїв за допомогою умовного оператора ИЛИ слід подати критерії в різних рядках. Наприклад, інтервал критеріїв на рисунку 1.7 виводить на екран усі записи, що мають у стовпці Цена значення більше 50 і менше 100.

 

Рисунок 1.7 – Приклад використання розширеного фільтру

 

 

Після використання команд "Автофильтр" або "Расширенный фильтр", таблиця переходить у режим фільтрації. У цьому режимі багато команд Microsoft Excel впливають тільки на зримі вічка. Після застосування фільтру для виводу тільки потрібних рядків, можна скопіювати отриману підмножину даних в інше місце для подальшого аналізу.

Щоб знову вивести усі записи слід у меню "Данные" вибрати пункт "Фильтр" і потім пункт "Отобразить все".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Решту етапів виконуються при логічному та фізичному проектуванні БД.

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

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

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

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

–            типи сутностей;

–            типи зв'язків;

–            атрибути;

–            домени атрибутів;

–            потенційні ключі;

–            первинні ключі.

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

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

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

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

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

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

–            підрозділ має персонал.

–            персонал займається об'єктами нерухомості.

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

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

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

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

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

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

Найпростіший метод виділення атрибутів – після ідентифікації чергової сутності або зв'язку в деякій специфікації задати собі наступне питання: "Яку інформацію потрібно зберігати про...".

Атрибути прості і складені

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

Похідні атрибути

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

–            кількість працівників даного відділення підприємства;

–            вік працівника;

–            загальна сума зарплати всього персоналу даного відділення підприємства.

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

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

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

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

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

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

–            набір припустимих значень для атрибута;

–            дані про розмір і формат кожного з полів атрибутів.

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

Визначення потенційних ключів і вибір первинного ключа

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

–            Використовуйте потенційний ключ з мінімальним набором атрибутів.

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

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

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

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

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

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

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

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

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

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

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

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

Створення моделі "сутність-відношення".

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

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

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

 

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

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

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

Робітник

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

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

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

Клієнт

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

Деталь

Робочий стаж

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

 

Виріб

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Description: D:\My docs Igor\DataBases\Labs\new_print\Lab_rob_5_files\image001.jpg

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

а) – повне зображення типу сутності "Штат працівників (Staff)" (атрибут "Name" ("Ім’я") – складений і утворений атрибутами "Ім’я" ("FName"), "Прізвище" ("LName");

б) спрощене зображення типу сутності "Штат працівників (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). Це означає, що кожен екземпляр сутності категорії успадковує атрибути тільки одного суперкласу.

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

 

Створення БД засобами Microsoft Access

 Після запуску Microsoft Access почати роботу можна зі створення нової бази даних, відкрити існуючу чи створити нову базу даних при допомозі елементів інтерфейсу, зображених на рисунку 3.1.

 

image001.jpg 

a)                                                              б)

Рисунок 3.1 – Створення бази даних  в Microsoft Access:

а) MS Office 2003;         б) MS Office 2010

 

Якщо вибрати пункт "Blank database/Новая база данных", то спочатку потрібно задати її назву та місцезнаходження (папку). Згодом відкриється головне вікно роботи з базами даних в Microsoft Access (рисунок 3.2)[1].

 

3.1 Створення таблиць

Для створення таблиці слід вибрати один з елементів на закладці "Таблицы/Tables" головного вікна бази даних: режим конструктора (Design view), режим майстра (using wizard), режим вводу даних (entering data).

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

 

image002.jpg

а)

б)

Рисунок 3.2 – Головне вікно Microsoft Access:

а) MS Office 2003;         б) MS Office 2010

 

В режимі конструктора користувач послідовно задає імена полів (пропуски в іменах та кирилицю використовувати можна, але не рекомендується з практичних міркувань)[2].Для кожного поля слід вказати його тип. Також у структурі таблиці можна дати опис певних полів (це необов'язково). В нижній частині вікна конструктора таблиці можна встановити додаткові властивості кожного з полів, виходячи з його типу (рисунок 3.3).

 

image003.jpg

а)

 

б)

Рисунок 3.3 –  Вікно конструктора таблиць:

а) MS Office 2003;         б) MS Office 2010

 

Типи даних доступні такі:

-         Text – стрічка;

-         Number – числовий;

-         Memo – багатострічковий текст;

-         Autonumber – автоінкрементне поле;

-         Date/Time – дата/час;

-         Currency – грошовий тип (точність – 2 знаки після коми);

-         Yes/No – логічний тип;

-         OLE object – об’єкт типу OLE (будь-які двійкові дані);

-         Lookup wizard – майстер підстановки (для підстановки даних зі списку).

Набір властивостей кожного поля залежить від типу даних. Для більшості типів доступні такі властивості:

-         довжина – розмір (для різних типів розмір має різний зміст);

-         підпис – напис на заголовку стовпця (по замовчуванню напис такий же, що і ім’я стовпця);

-         значення за замовчуванням;

-         умова на значення – обмежує множину допустимих значень;

-         повідомлення про помилку – з’являється при вводі неправильного значення. За замовчуванням виводиться стандартне повідомлення;

-         обов’язкове поле – чи можна залишати порожні значення;

-         індексоване поле – чи індексувати поле, і якщо так, то чи допустимі співпадання значень чи ні.

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

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

Для сортування даних в таблиці слід користуватись відповідними кнопками панелі інструментів або головного чи контекстного меню (рисунок 3.4).

 

image004.jpg  

а)                                   б)

Рисунок 3.4 – Пукти контекстного меню для сортування і фільтрації

(зверху вниз):

а) MS Office 2003: фільтрація за вибраним значенням; фільтрація за виключенням вибраного значення; фільтрація за вказаним значенням; усунути фільтр//сортування; сортування в порядку зростання; сортування в порядку спадання;

б) MS Office 2010: ортування в порядку зростання; сортування в порядку спадання; усунути фільтр//сортування; фільтр, залежний від типу даних; фільтри на значення поля (останні 4 пункти: рівний, не рівний, містить, не містить)

 

3.2 Створення екранних форм

 

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

 

 

image005.jpg 

а)

б)

Рисунок 3.5 – Вікно вибору варіанту створення нової форми:

а) MS Office 2003;         б) MS Office 2010

 

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

 

image006.jpg  

а)                                                      б)

Рисунок 3.6 – Вікно створення нової форми:

а) MS Office 2003;         б) MS Office 2010

 

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

 

image007.jpg

а)

б)

Рисунок 3.7 – Панель елементів для екранних форм та форм звітів:

а) MS Office 2003;         б) MS Office 2010

 

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

 

image008.jpg

Рисунок 3.8 – Вікно для побудови виразів

 

3.3 Створення звітних форм

 

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

 

image009.jpg

а)

б)

Рисунок 3.9 – Вікно початку створення звітної форми в Microsoft Access:

а) MS Office 2003;         б) MS Office 2010

 

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

 

image010.jpg

Рисунок 3.10 – Вікно вибору сортування та групування при створенні звітних форм

 

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

 

image011.jpg

а)

 

б)

Рисунок 3.11 – Вікно конструктора звітних форм:

а) MS Office 2003;         б) MS Office 2010

 

В область даних форми, використовуючи піктограму "Список полів", переносять відповідні поля (супроводжуючий текст можна витерти). Їх розміщення може бути довільним, але, як правило, це є стрічка звіту. Заголовок звіту виводиться на першій сторінці (це може бути ціла сторінка). У верхньому колонтитулі задають заголовки стовпців звіту, а в нижньому додаткову інформацію для кожної сторінки (нумерація сторінок, дата/час, додаткові написи тощо). Якщо передбачене групування, то в заголовку групи можна задати деякий пояснюючий текст, а в примітці групи – проміжні результати. В примітці звіту можна задати вивід підсумкових результатів. Примітка звіту виводиться на останній сторінці, причому нижній колонтитул там виведеться в кінці звіту.

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

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

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

 

3.4 Використання макросів та організація роботи з модулями в Microsoft Access.

 

 Макроси в Microsoft Access призначені для автоматичного виконання певних дій чи їх сукупності. Будь яка команда, що виконується при роботі з базами даних, називається макрокомандою. Основні з них перераховані в списку макрокоманд, які можна використовувати в макросах. Для існуючих таблиць макроси можна створювати в діалоговому режимі при  допомозі конструктора. Для створення нового макроса слід вибрати вкладку "Макрос", а далі кнопку "Создать". Відкриється вікно конструктора створення нового макроса (рисунок 3.12).

 

Description: D:\My docs Igor\DataBases\Labs\new_print\Lab_rob_7_files\image001.jpg

а)

б)

Рисунок 3.12 – Вікно конструктора макросів в Microsoft Access:

а) MS Office 2003;         б) MS Office 2010

 

Макрокоманди вибираються з випадаючого підменю. В примітках можна дати пояснення призначення та порядок застосування кожної із макрокоманд. Більшість макрокоманд має певний набір аргументів. Їх слід вказувати внизу зліва в розділі аргументи макрокоманди. Внизу справа дається коротке пояснення роботи макрокоманди (більш детально можна взнати, натиснувши клавішу F1).

Макрокоманди можна також створювати методом “перетягнути та відпустити” (рисунок 3.13).

Description: D:\My docs Igor\DataBases\Labs\new_print\Lab_rob_7_files\image002.gif

Рисунок 3.13 – Створення макросів методом “перетягнути та відпустити”

 

Після відкриття конструктора макросів слід в пункті головного меню “Окно” задати “Слева направо” і у вікні, що відкриється справа, вибрати потрібну вкладку, з якої перетягнути в поле макрокоманд певний елемент (наприклад екранну форму). Access автоматично встановить відповідну назву макрокоманди та задасть потрібні аргументи.

Створений макрос слід зберегти, задавши йому ім’я. Далі його можна редагувати, копіювати, перейменовувати.

Запускати макрос можна:

-       з вікна макросів;

-       з головного вікна бази даних;

-       у відповідь на подію (наприклад натискання кнопки на формі);

-       з інших макросів;

-       з вікон інших об’єктів.

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

Макроси можна об’єднувати в групи. Для цього після відкриття конструктора макросів в пункті меню “Вид” слід задати “Имена макросов”. У вікні конструктора зліва появиться колонка “Имя макроса”. В ній слід задати вибране ім’я, а праворуч набір макрокоманд. Новий макрос слід починати із зміни імені.

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

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

Зауваження – якщо в стовпці "Условие" буде порожня клітинка, то макрокоманда даної стрічки буде виконуватись безумовно.

Модуль – це набір описів і процедур мовою Visual Basic, зібраних в одну програмну одиницю.

Існує два основних типи модулів: модулі класу і стандартні модулі. Кожна процедура в модулі може бути або процедурою-функцією Function, або процедуроюSub.

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

У процедурах модулів форм і звітів можуть міститися виклики процедур, доданих у стандартні модулі.

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

Процедура-функція Function

Синтаксис:

[Public | Private] [Static] Function ім'я [(список аргументів)] [As тип]

            [інструкції]

            [ім'я = вираз]

            [Exit Function]

            [інструкції]

            [ім'я = вираз]

End Function

Процедура Sub.

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

Синтаксис:

[Private | Public] [Static] Sub ім'я [(список аргументів)]

            [інструкції]

            [Exit Sub]

            [інструкції]

End Sub

Для створення нового модуля в головному вікні Access слід на вкладці "Модули" вибрати кнопку "Создать" (рисунок 3.14).

Description: D:\My docs Igor\DataBases\Labs\new_print\Lab_rob_7_files\image003.jpg

Рисунок 3.14 – Вікно створення модуля

 

Якщо неявні описи небажані, інструкція Option Explicit повинна передувати в модулі всім процедурам.

Інструкція Option Compare застосовується на рівні модуля для завдання використовуваного за замовчуванням способу порівняння стрічкових даних.

Синтаксис:

Option Compare {Binary | Text | Database}

При організації доступу до записів баз даних найчастіше використовуються об'єкти DoCmd та Recordset.

Методи, визначені для об'єкта DoCmd (команда), дозволяють запускати макрокоманди Microsoft Access із програм Visual Basic. За допомогою макрокоманд виконують такі дії як закриття вікон, відкриття форм і завдання значень елементів керування.

Синтаксис:

[додаток.]DoCmd.метод [арг1, арг2, ...]

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

Об'єкти Recordset використовуються для обробки даних у базі даних на рівні запису.  При роботі з об'єктами доступу до данних (Data Access Object) майже всі операції виконуються за допомогою об'єктів Recordset. Кожен об'єкт Recordset складається з записів (рядків) і полів (стовпців). 

Властивості BOF, EOF

BOF повертає значення, що показує чи розташований покажчик біжучого запису в позиції перед першим записом об'єкта Recordset.

EOF повертає значення, що показує чи розташований покажчик поточного запису в позиції після останнього запису об'єкта Recordset.

 Значення властивостей, що повертаються, BOF і EOF мають тип Boolean.

Як правило, при роботі з усіма записами з об'єкта Recordset у програмі задають переміщення в циклі по записах за допомогою методу MoveNext доти, поки властивістьEOF не одержить значення True.

Властивість RecordCount

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

Метод OpenRecordset

Створює новий об'єкт Recordset і додає його в сімейство Recordsets.

Синтаксис:

Set набірЗаписів = об'єкт.OpenRecordset (джерело)

Метод AddNew

Створює новий запис в оновлюваному об'єкті Recordset.

Синтаксис:

набірЗаписів.AddNew

Прототип набірЗаписів представляє об'єктну змінну, що задає оновлюваний об'єкт Recordset, у який потрібно додати новий запис.

Метод AddNew створює і додає новий запис в об'єкт Recordset з іменем набірЗаписів.  Даний метод надає всім полям запису значення Null (порожні значення, що надаються полям об'єкта Recordset табличного типу за замовчуванням) чи значення за замовчуванням, визначені користувачем.

Метод Delete

Метод видаляє біжучий запис в обновлюваному об'єкті Recordset

Синтаксис:

набірЗаписів.Delete

Метод Edit

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

Синтаксис:

набірЗаписів.Edit

Прототип набірЗаписів представляє відкритий оновлюваний об'єкт Recordset, що містить підлягаючий зміні запис.

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

Метод Update

Зберігає вміст буфера копіювання в обновлюваному об'єкті Recordset.

Синтаксис:

набірЗаписів.Update

Методи MoveFirst, MoveLast, MoveNext, MovePrevious

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

Синтаксис:

набірЗаписів.{MoveFirst | MoveLast | MoveNext | MovePrevious}

Прототип набірЗаписів представляє об'єктну змінну, що задає відкритий об'єкт Recordset.

Методи FindFirst, FindLast, FindNext, FindPrevious

Знаходять в об'єктах Recordset типу динамічних і статичних наборів записів перший, останній, наступний чи попередній запис, що задовольняє заданим умовам, і роблять цей запис поточним (таблиця 7.1).

Синтаксис:

набірЗаписів.{FindFirst | FindLast | FindNext | FindPrevious} умови

   

Таблиця 7.1 – Методи FindFirst, FindLast, FindNext, FindPrevious

Методи Find

Початок пошуку

Напрямок

FindFirst

Початок набору записів

Кінець набору записів

FindLast

Кінець набору записів

Начало набору записів

FindNext

Біжучий запис

Кінець набору записів

FindPrevious

Біжучий запис

Начало набору записів

 

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

Метод Close

Закриває відкритий об'єкт доступу до даннх.

Синтаксис:

об'єкт.Close

 

Для існуючих таблиць Microsoft Access запити можна створювати в діалоговому режимі при допомозі відповідного майстра чи при допомозі конструктора. Для створення нового запиту слід вибрати вкладку "Запрос", а далі кнопку "Создать". Відкриється вікно вибору варіанту створення нового запиту (рисунок 4.1).

 

 

Рисунок 4.1 – Вікно початку створення запиту в Microsoft Access

 

В даному діалозі доступні для вибору наступні пункти, перераховані в таблиці 4.1.

 

Таблиця 4.1 – Способи створення запиту в MS Access

Конструктор

– Самостійне створення нового запиту;

Простий запит

– Створення запиту на вибір із окремих полів;

Перехресний запит

– Створення запиту для виводу даних в формі, що нагадує електронну таблицю;

Записи, що повторюються

– Створення запиту на вивід записів, що повторюються в таблиці чи в іншому запиті;

Записи без підпорядкованих

– Створення запиту на пошук записів, яким не відповідає ні один запис в підпорядкованій таблиці.

 

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

 

Таблиця 4.2 – Типи запитів, підтримувані в СКБД Microsoft Access

Тип запиту

Опис

Запити на вибірку

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

Запити з узагальненням

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

Параметричні запити

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

Запити на вибірку дублікатів

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

Запити на вибірку записів, що не мають відповідників

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

Перехресні запити

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

Запити з автопідстановкою

При виконанні запиту виконується автоматична підстановка певних значень у знову створювані записи

Активні запити (включають запити на видалення, додавання, відновлення й створення таблиць)

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

Специфічні SQL-запити (включають функції з'єднання, передачі, визначення даних, а також підзапити)

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

 

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

 

Рисунок 4.2 – Вікно вибору таблиць чи(і) запитів для створення запиту

 

Рисунок 4.3 – Вікно конструктора запитів

 

Якщо при створенні запиту треба об'єднати декілька таблиць чи запитів, то після їх вибору у верхній частині конструктора таблиць необхідно встановити зв'язки між ними при допомозі пункту меню "Вид" "Параметры объединения" (рисунок 4.4).

Рисунок 4.4 – Вікно вибору параметрів об'єднання  при створенні запитів

В ході нормалізації[1] відношень реляційної бази даних кількість відношень не зменшується, а, як правило, збільшується. І ці відношення (таблиці) попарно зв’язані. Ці зв’язки забезпечують цілісність даних на рівні посилань і встановлюються через механізм зовнішніх ключів.

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

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

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

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

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

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

Типи значень зовнішнього ключа підлеглої таблиці та потенційного головної таблиці повинні співпадати!

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

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

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

Case-засіб ERWin підтримує методологію IDEF1X і стандарт IE (Information engineering). Методологія IDEF1X підрозділяється на рівні, що відповідають проектованій моделі даних системи. Кожен такий рівень відповідає визначеній фазі проекту. Такий підхід корисний при створенні систем за принципом "зверху вниз".

Верхній рівень складається з Entity Relation Diagram (Діаграма сутність-зв'язок) і Key-Based model (Модель даних, заснована на ключах). Діаграма сутність-зв'язок визначає сутності і їхні відносини. Модель даних, заснована на ключах, дає більш докладне представлення даних. Вона включає опис усіх сутностей і первинних ключів, що відповідають предметній області.

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

 

1.1 Логічні моделі

 

Три рівні моделей, що поєднують у собі логічні моделі, складаються з Entity Relationship Diagram (Діаграма сутність-зв'язок), the Key-Based Model (Модель даних, заснована на ключах) і the Fully Attributed model (Повна атрибутивна модель) (рисунок 6.1).

 

Рисунок 6.1 – Рівні методології IDEF1X

 

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

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

Повна атрибутивна модель. Ця модель містить у собі всі сутності, атрибути і є найбільш детальним представленням структури даних. Повна атрибутивна модель представляє дані в третій нормальній формі.

 

1.2 Фізичні моделі

 

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

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

Перед початком проектування БД необхідно переконатися в забезпеченні наступних вимог:

–       фізична модель даних повинна відповідати вимогам, що поставлені до проектованої системи;

–       вибір визначеної фізичної моделі повинен бути аргументований;

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

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

 

1.3 Переваги від використання CASE-засобів

 

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

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

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

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

 

1.4 Інструментарій ERWin

 

При запуску ERWin з'являється основна панель інструментів і палітра інструментів:

 

Таблиця 6.1 – Основна панель інструментів ERWin

Кнопки

Призначення кнопок

Створення, відкриття і друк моделі

Виклик діалогового вікна Report Browser для генерації звітів

Зміна рівня перегляду моделі: рівень сутностей, рівень атрибутів і рівень визначень

Зміна масштабу перегляду моделі

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

Виклик додаткової панелі інструментів для роботи з репозитарієм Model Mart

Переключення між областями моделі

 

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

На логічному рівні панель інструментів виглядає так (рисунок 6.2):

 

Рисунок 6.2 – Палітра інструментів на логічному рівні

 

На цьому рисунку зображено:

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

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

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

–       Кнопка створення зв'язків: ідентифікуюча, "багато-до-багатьох" і неідентифікуюча. Ідентифікуючий зв’язок встановлюється між сутностями, які можуть бути об’єднані в одну таблицю, тобто зв’язані зв’язком з кардинальністю "один до одного".  Тому для встановлення зв’язків між сильними типами сутностей на ER-моделі потрібно використовувати неідентифікуючий зв’язок.

На фізичному рівні палітра інструментів виглядає, як на рисунку 6.3.

 

Рисунок 6.3 – Палітра інструментів на фізичному рівні

 

Першим кроком при створенні логічної моделі БД є побудова діаграми ER (Entity Relationship Diagram). ER-діаграми складаються з трьох частин: сутностей, атрибутів і взаємозв'язків. Сутностями є іменники, атрибути – прикметниками чи модифікаторами, взаємозв'язки – дієсловами.

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

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

 

1.5 ER-діаграми

 

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

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

 

Рисунок 6.4 – Приклад ER-діаграми

 

1.5.1 Визначення сутностей і атрибутів

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

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

 

Рисунок 6.5 – ER-діаграма з атрибутами

 

1.5.2 Логічні взаємозв'язки

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

Деякі приклади взаємозв'язків:

–       команда включає багато гравців;

–       літак перевозить багато пасажирів;

–       продавець продає багато продуктів.

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

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

 

1.5.3 Перевірка адекватності логічної моделі

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

–       літак перевозить пасажирів.

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

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

 

Рисунок 6.6 – Приклад логічної моделі з взаємозв'язком

 

1.6 Модель даних, заснована на ключах

 

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

 

1.6.1 Вибір первинного ключа

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

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

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

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

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

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

Потенційний ключ, що не став первинним, називається альтернативним ключем (Alternate Key). ERWin дозволяє виділити атрибути альтернативних ключів, і за замовчуванням надалі при генерації схеми БД по цих атрибутах буде генеруватися унікальний індекс. При створенні альтернативного ключа на діаграмі поруч з атрибутом з'являються символи (АК).

Атрибути, що беруть участь у неунікальних індексах, називаються інверсійними входами (Inversion Entries). Інверсійні входи – це  атрибут чи група атрибутів, що не визначають екземпляр унікальним чином, але часто використовуються для звертання до екземплярів сутності. ERWin генерує неунікальний індекс для кожного інверсійного входу.

При проведенні зв'язку між двома сутностями в дочірній сутності автоматично утворяться зовнішні ключі (foreign key). Зв'язок утворить посилання на атрибути первинного ключа в головному типу сутності, і ці атрибути утворять зовнішній ключ у дочірньому типові сутності. Атрибути зовнішнього ключа позначаються символами (FK) після свого імені.

Розглянемо процес побудови логічної моделі БД. Першим етапом є визначення типів сутностей і атрибутів.

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

Складається ER-діаграма, визначаючи типи атрибутів і проставляючи зв'язки між сутностями.

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

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

Перед тим як приступити до створення фізичної моделі, необхідно вибрати цільовий сервер СКБД. Вигляд панелі діалогу, що дозволяє це зробити, наведений на рисунку 6.7. Дане вікно доступне з пункту меню ServeràTarget server… для старіших версій програми. Починаючи з версії 3.5.3 дане вікно доступне з меню DatabaseàChoose database…

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

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

 

Рисунок 6.7 – Панель вибору сервера СКБД

 

Рсунок 6.8 – Вибір створення лоігчної і фізичної моделі БД та 
вказання цільової СКБД

 

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

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

Діалогове вікно редактора стовпців таблиці представлено на рсиунку 6.9.

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

Рисунок 6.9 – Панель діалогу редактора колонок

 

Рисунок 6.10 – Фізична модель

 

Останнім кроком є генерація схеми БД. Всі необхідні параметри можна задати на призначеній для цього панелі діалогу (див. рисунок 6.11). Натискання кнопки Preview дозволяє переглянути код, що буде автоматично створений ERwin. Генерація схеми БД запускається натисканням кнопки Generate.

 

Рисунок 6.11 – Панель генерації схеми БД

1.1 Маніпулювання даними з використанням мови SQL

Згідно діючого стандарту SQL:2003, як будь яка мова програмування, SQL містить набір зарезервованих слів, а також правила, згідно яких ці слова складаються у операторах. Формат запису стрічки SQL довільний, але більшість реалізацій вимагають, щоби у кінці кожного оператора стояв знак ";". Порядок запису складових оператора змінювати не можна. Більшість компонентів SQL не чутливі до регістру, тобто можна використовувати як малі, так і великі букви. Звичайно, виключення становлять стрічкові літерали, що містяться у базі даних. Наприклад, коли ви шукаєте в базі даних слово ’Україна’, а насправді там міститься слово ’УКРАЇНА’, то результат пошуку буде нульовий. Стрічкові літерали беруться у одинарні лапки.

Почнемо з мови маніпуляції даними – DML і розглянемо такі оператори:

SELECT – вибірка даних;

INSERT – вставка даних у таблицю;

UPDATE – оновлення (зміна) даних в таблиці;

DELETE – знищення даних у таблиці.

Оператор 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 з наступним вказанням після нього умови відбору стрічок. Допустимі оператори порівняння: =, < ,> , <=, >=, <> (або != у деяких діалектах). Якщо умов декілька, то їх можна об’єднати з допомогою однієї з логічних операцій: AND, NOT, OR.

Замість операторів порівняння можна використовувати задання діапазонів за допомогою слів BETWEEN … AND (входження в діапазон з включенням границь) чи NOT BETWEEN … AND (за межами діапазону).

Приклад:

 

SELECT no, name, salary

FROM staff

WHERE salary BETWEEN 1000 AND 5000 AND city='Тернопіль';

 

Для перевірки входження у множину значень використовують слово IN чи NOT IN (очевидно, неналежність до множини).

Наприклад, оператор

 

SELECT no, name, salary

FROM staff

WHERE position IN ('Manager', 'Officer') AND city='Тернопіль';

 

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

У умові відбору записів після слова WHERE можна використовувати також слова LIKE або NOT LIKE  (подібний чи неподібний) для пошуку стрічкових літералів, що входять у текстове поле запису більшої довжини. У мові SQL існує два спеціальних символи шаблону для задання довільної послідовності символів:

%        задає довільну послідовність символів (в т.ч. і нульову);

_        (знак підкреслення) задає один довільний символ.

Наприклад, запит

SELECT no, name, address, salary

FROM staff

WHERE address LIKE '%піл_';

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

В новому стандарті SQL:2003 з’явився предикат 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 номери та імена працівників, поле примітки яких незаповнене.

1.1.1 Сортування результатів (фраза 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;

1.1.2 Використання узагальнюючих функцій мови 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, то спочатку виконується вона, а потів за результатами вибірки робляться узагальнюючі підрахунки.

1.1.3 Групування результатів

Для формування проміжних підсумків використовують групування за допомогою фрази 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 іде запис виразу для відбору груп подібно до фрази WHERE.

1.1.4 Підзапити

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

Приклад 1. Список персоналу, котрий працює у відділенні компанії, розміщеному на вулиці SomeStreet.

SELECT no, name, salary

FROM staff

WHERE branch_no=(SELSCT branch_no

FROM branch

WHERE street=’SomeStreet’);

Приклад 2. Список працівників з зарплатою, більшою за середню з вкзанням цієї різниці.

SELECT no, name, salary-(SELECT avg(salary) FROM staff) AS sal_diff

FROM staff

WHERE salary > (SELECT avg(salary)

FROM staff);

Правила складання підзапитів:

1. В підзапитах не можна застосовувати впорядкування (крім самого зовнішнього запиту);

2. Якщо підзапит є одним з операндів операції порівняння, то цей підзапит повинен бути правим операндом.

1.1.5 Підзапити зі словами ALL, ANY, SOME

Вказані ключові слова використовуються з підзапитами, що повертають один стовпець чисел. Якщо підзапиту передує слово ALL, то умова порівняння поверне істину в випадку, коли вона справдиться для всіх значень врезультуючому стовпці запиту. Використання слова ANY має протилежне значення: умова вважається виконаною, якщо вона виконується для будь-якого значення результуючого стовпця. Стандарт SQL:2003 передбачає використання слова SOME, яке є синонімом слова ANY.

Наприклад, запит

SELECT no, name, salary

FROM staff

WHERE salary > SOME

            (SELECT salary

            FROM staff

            WHERE branch='B1');

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

1.1.6 Багатотабличні запити

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

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

 

Приклад 8.1 – Просте з'єднання

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

 

SELECT c.clientNo, fName, lName, propertyNo, comment

FROM Client c, Viewing v

WHERE c.clientNo = v.clientNo;

 

У цьому звіті вимагається представити відомості як з таблиці Client, так і з таблиці Viewing, тому при побудові запиту ми скористаємося механізмом з'єднання таблиць. У конструкції SELECT перераховуються усі стовпці, які мають бути поміщені в результуючу таблицю запиту. Зверніть увагу, що для стовпця з номером клієнта (clientNo) потрібне уточнення, оскільки такий стовпець може бути присутнім і в іншій таблиці, що бере участь в з'єднанні. Тому необхідно явно вказати, значення якої таблиці нас цікавлять. (У цьому прикладі з тим же успіхом можна було вибрати значення стовпця clientNo з таблиці Viewing.) Уточнення імені здійснюється шляхом вказівки як префікс перед ім'ям стовпця імені відповідної таблиці (чи її псевдоніма). У нашому прикладі використовується значення 'с', задане як псевдонім таблиці Client. Для формування результуючих рядків використовуються ті рядки початкових таблиць, які мають ідентичне значення в стовпці clientNo. Ця умова визначається за допомогою завдання умови пошуку с.clientNo=v.clientNo. Подібні стовпці початкових таблиць називають поєднуваними стовпцями. Описана операція еквівалентна операції з'єднання по рівності реляційної алгебри. Результати виконання запиту представлені в таблиці 8.1.

 

Таблиця 8.1 – Результат виконання запиту з прикладу 8.1

clientNo

fName

lName

propertyNo

comment

CR56

Aline

Stewart

PG36

 

CR56

Aline

Stewart

PA14

too small

CR56

Aline

Stewart

PG4

 

CR62

IMary

Tregear

PA14

no dining room

CR76

John

Kay

PG4

too remote

 

Найчастіше багатотабличні запити виконуються для двох таблиць, сполучених зв'язком типу "один до багато чим" або батьківсько-дочірнім зв'язком. У наведеному вище прикладі, що включає звернення до таблиць 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.

 

Приклад 8.2. Сортування результатів з'єднання таблиць

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

 

SELECT S.branchNo, s.staffNo, fName, lName, propertyNo

FROM Staff s, PropertyForRent p

WHERE s.staffNo = p.staffNo

ORDER BY s.branchNo, s.staffNo, propertyNo;

 

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

 

Таблиця 8.2 – Результат виконання запиту з прикладу 8.2

branchNo

staffNo

fName

lName

propertyNo

В003

SG14

David

Ford

PG16

В003

SG37

Ann

Beech

PG21

В003

SG37

Ann

Beech

PG36

В005

SL41

Julie

Lee

PL94

В007

SA9

Mary

Howe

PA14

 

Приклад 8.3 – З'єднання трьох таблиць

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

 

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.staff No

ORDER BY b.branchNo, s.staffNo, propertyNo;

 

У результуючу таблицю необхідно помістити стовпці з трьох початкових таблиць – BranchStaff і PropertyForRent, тому в запиті слід виконати з'єднання цих таблиць. Таблиці Branch і staff можуть бути сполучені за допомогою умови b.branchNo=s.branchNo, внаслідок чого відділення компанії будуть пов'язані з персоналом, що працює в них. Таблиці staff і PropertyForRent можуть бути сполучені за допомогою умови s.staffNo=p.staffNo. В результаті кожен працівник буде пов'язаний з тими об'єктами, що здаються в оренду, за які він відповідає.Результати виконання запиту представлені в таблиці 8.3.

 

Таблиця 8.3 – Результати виконання запиту з прикладу 8.3

branchNo

city

staff Mo

fName

lName

propertyNo

В003

Glasgow

SG14

David

Ford

PG16

В003

Glasgow

SG37

Ann

Beech

PG21

В003

Glasgow

SG37

Ann

Beech

PG36

В005

London

SL41

Julie

Lee

PL94

В007

Aberdeen

SA9

Mary

Howe

PA14

 

Відмітимо, що стандарт SQL дозволяє використовувати альтернативний варіант формулювання конструкцій FROM і WHERE :

 

FROM (Branch b JOIN Staff s USING branchNo)

AS bs JOIN PropertyForRent p USING staffNo

 

Приклад 8.4 – Групування по декількох стовпцях

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

 

SELECT s.branchNo, S.staffNo, COUNT(*) AS count

FROM Staff s, PropertyForRent p

WHERE S.staffNo = p.staffNo

GROUP BY s.branchNo, s.staffNo

ORDER BY s.branchNo, s.staffNo;

 

Щоб скласти необхідний звіт, передусім необхідно з'ясувати, хто з працівників компанії відповідає за об'єкти, що здаються в оренду. Це завдання можна вирішити за допомогою з'єднання таблиць Staff і PropertyForRent по стовпцю staffNo в конструкціях FROM/WHERE. Потім необхідно сформувати групи, що складаються з номера відділення і табельних номерів його працівників, для чого слід застосувати конструкціюGROUP BY. Нарешті, результуюча таблиця має бути відсортована за допомогою завдання конструкції ORDER BY. Результати виконання запиту представлені в таблиці 8.4.

 

Таблиця 8.4 – Результат виконання запиту з прикладу 8.4

branchNo

staffNo

count

В003

SG14

1

В003

SG37

2

B005

SL41

1

В007

SA9

1

 

Виконання з'єднань.

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

 

SELECT [DISTINCT | ALL] {* | columnList}

FROM tableNamel CROSS JOIN tableNeme2

 

Ще раз розглянемо приклад 8.1, в якому з'єднання таблиць client і Viewing виконується з використанням загального стовпця clientNo.Це еквівалентно виконанню використовуваного в прикладі 8.1 запиту, але без застосування конструкції WHERE.

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

1.       Формується декартовий добуток таблиць, вказаних в конструкції FROM.

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

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

4.       Якщо в початковому запиті присутня конструкція SELECT DISTINCT, з результуючої таблиці віддаляються усі рядки-дублікати. У реляційній алгебрі дії, що виконуються на 3 і 4 етапах, еквівалентні операції проекції по стовпцях, заданих в списку вибірки SELECT.

9.   Якщо виконуваний запит містить конструкцію ORDER BY, здійснюється переупорядковування рядків результуючої таблиці.

Зовнішні з'єднання.

При виконанні операції з'єднання дані з двох таблиць комбінуються з утворенням пар пов'язаних рядків, в яких значення стовпців, що зіставляються, є однаковими. Якщо одне зі значень в стовпці однієї таблиці, що зіставляється, не співпадає ні з одним зі значень в стовпці іншої таблиці, що зіставляється, то відповідний рядок віддаляється з результуючої таблиці. Саме це правило застосовувалося в усіх розглянутих вище прикладах з'єднання таблиць. Стандартом ISO передбачений і інший набір операторів з'єднань, званих зовнішніми з'єднаннями. У зовнішньому з'єднанні в результуючу таблицю поміщаються також рядки, що не задовольняють умові з'єднання. Щоб зрозуміти особливості виконання операцій зовнішнього з'єднання, скористаємося спрощеними таблицями Branch і PropertyForRent, вміст яких представлений в таблиці 8.5 і 8.6.

 

Таблиця 8.5 – Таблиця Branch1

branch No

bCity

В00З

Glasgow

В004

Bristol

В002

London

 

Таблиця 8.6 – Таблиця PropertyForRent1

propertyNo

pCity

PA14

Aberdeen

PL94

London

PG4

Glasgow

 

Звичайне (внутрішнє) з'єднання цих таблиць виконується за допомогою наступного оператора SQL :

 

SELECT b.*, p.*

FROM Branch1 b, PropertyForRent1 p

WHERE b.bCity = p.pCity;

 

Результати виконання цього запиту представлені в таблиці 8.7.

 

Таблиця 8.7 – Результат внутрішнього з'єднання спрощених таблиць Branch1 і PropertyForRent1

branchNo

bCity

propertyNo

pCity

В003

Glasgow

PG4

Glasgow

В002

London

PL94

London

 

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

 

Приклад 8.5 – Ліве зовнішнє з'єднання

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

Використовуємо ліве зовнішнє з'єднання цих двох таблиць, яке виглядає таким чином:

 

SELECT b.*, р.*

FROM Branch1 b LEFT JOIN PropertyForRent1 p ON b.bCity = p.pCity;

 

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

 

Таблиця 8.8 – Результат виконання запиту з прикладу 8.5

branch No

bCity

propertyNo

pCity

B003

Glasgow

PG4

Glasgow

В004

Bristol

NULL

NULL

В002

London

PL94

London

 

Приклад 8.6 – Праве зовнішнє з'єднання

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

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

 

SELECT b.*, р.*

FROM Branch1 b RIGHT JOIN PropertyForRent1 p ON b.bCity = p.pCity;

 

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

 

Таблиця 8.9 – Результат виконання запиту з прикладу 8.6

branchNo

hCity

propertyNo

pCity

NULL

NULL

PA14

Aberdeen

В003

Glasgow

PG4

Glasgow

В002

London

PL94

London

 

Приклад 8.7. Повне зовнішнє з'єднання

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

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

 

SELECT b.*, р.*

FROM Eranch1 b FULL JOIN PropertyForRent p ON b.bCity = p.pCity;

 

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

 

Таблиця 8.10 – Результат виконання запиту з прикладу 8.7

branchNo

bCity

propertyNo

pCity

NULL

NULL

PA14

Aberdeen

вооз

Glasgow

PG4

Glasgow

В004

Bristol

NULL

NULL

В002

London

PL94

London

 

1.1.7 Ключові слова EXISTS і NOT EXISTS

Ці слова використовуються для перевірки того, чи повертає або не повертає (відповідно EXISTS і NOT EXISTS) підзапит хоча б одну стрічку.

1.1.8 Операції з записами

Вставка нового запису до таблиці:

INSERT INTO <ім’я таблиці> (<список полів>)

VALUES (<список значень>);

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

Інша форма оператора INSERT дозволяє копіювати записи однієї таблиці в іншу (таблиці мають бути сумісні по об'єднанню).

INSERT INTO <ім’я таблиці> <оператор SELECT>

Наприклад, запит

INSERT INTO old_staff SELECT * FROM staff WHERE Year_b<1940;

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

Редагування записів:

UPDATE <ім’я таблиці> SET <список виду <поле>=<вираз>> WHERE <умова>

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

Витирання запису:

DELETE FROM <ім’я таблиці> WHERE <умова>

 Створення бази

 

Створення бази даних в різних СКБД може мати свої особливості. Як правило, це фрази

CREATE SCHEMA [name | AUTHORIZATION creator_identifier];

або частіше

CREATE DATABASE database_name;

Для знищення бази даних використовують фразу

DROP SCHEMA name [RESTRICT | CASCADE];

або

DROP DATABASE name;

Ім’я бази даних – це ім’я файлу або ім’я каталогу, де вона розміщена. Наприклад, для MS Access, Interbase – це файл, для Paradox – це каталог, для MS SQL Server – це ім’я буде представлено щонайменше двома файлами з цим же іменем але різними розширеннями (*.mdf – для даних та *.ldf – для файлу журналу).

В цій лабораторній роботі рекомендується використовувапти одну із наступних СКБД: MS SQL Server 2008, Interbase (Firebird), MySQL 5. Для кожної з цих СКБД є певні особливості запитів на створення самої БД та її складових, котрі будуть обумовлені окремо.

Детально із запитами на створення БД для вказакних СКБД можна ознайомитись за наступними адресами:

 

MS SQL Server 2008: http://msdn.microsoft.com/ru-ru/library/ms176061.aspx;

 

Interbase (Firebird): тут або для найновішої версії тут (вся документація по InterBase: http://docs.embarcadero.com/products/interbase/ );

 

mySQL: російськомовна документація: http://www.mysql.ru/docs/; англомовна документація по мові SQL – http://dev.mysql.com/doc/refman/5.6/en/sql-syntax.html ; по створенню БД – http://dev.mysql.com/doc/refman/5.6/en/create-database.html  

 

Після створення бази даних створюють її таблиці та інші складові.

 

9.2 Створення таблиці:

 

Створення таблиці:

 

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 означає допустимість невведеного значення поля і прийнято за замовчуванням.

Знищення таблиці виконується за допомогою запиту

 

DROP TABLE table_name [RESTRICT | CASCADE];

 

Вказання слова RESTRICT означає заборону знищення таблиці поки існують залежні від неї об’єкти (прийнято за замовчуванням). Слово CASCADE означає каскадне витирання всіх залежних об’єктів перед витиранням таблиці. Запит на знищення таблиці застосовується, як правило, при виправленні помилок неправильно створеної таблиці. Тоді просто таблицю неправильної структури витирають, а потім створюють нову з таким же іменем.

 

9.3 Створення індексу

 

CREATE [UNIQUE] INDEX index_name ON table_name (column [ASC | DESC][,…]);

 

У таблиці table_name буде створено індекс з іменем index_name, що складається з полів column, сортування здійснюватиметься у зростаючому ASC (прийнято за замовчуванням) чи у спадаючому DESC порядку. Якщо вказано UNIQUE, то значення у індексному полі мають бути унікальними у кожному записі таблиці.

Знищення індексу

 

DROP INDEX index_name;

 

9.4 Забезпечення цілісності даних

 

Забезпечення цілісності даних включає наступні пункти:

-       обов’язкові дані;

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

-       цілісність сутностей;

-       цілісність посилань;

-       вимоги конкретного підприємства.

Більша частина цих обмежень задається у операторах створення таблиці CREATE TABLE та зміни структури існуючої таблиці ALTER TABLE.

Обов’язкові дані задаються вказанням фрази NOT NULL описі поля при створенні таблиці.

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

Наприклад, для задання вводу в поле, що означає стать, лише двох значень "М" або "Ж", при створенні таблиці можна записати:

 

sex CHAR(1) NOT NULL CHECK (sex IN ('M','Ж'));

 

Другий спосіб – створення домену (не підтримується для Microsoft SQL Server):

 

CREATE DOMAIN domain_name [AS] data_type

[DEFAULT default_option]

[CHECK (search_condition)]

 

Для Microsoft SQL Server можна скористатись конструкцією CREATE TYPE:

 

CREATE TYPE new_type_name

FROM base_data_type;

 

Наприклад:

 

CREATE TYPE SSN

FROM varchar(11) NOT NULL ;

 

З повним синтаксисом цієї інструкції можна ознайомитись за адресою: http://msdn.microsoft.com/uk-ua/library/ms175007.aspx. Основне зауваження – інструкція не підтримує задання обмежень предметної області (фраза CHECK), тому це потрібно робити при означенні стовпців.

Кожному створюваному домену присвоюється ім’я 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.Вказання цілісності даних при створенні таблиці

 

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

 

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.

 

9.6 Зміна опису таблиці

 

Зміна таблиці допускає наступні дії:

-       добавлення стовпця;

-       видалення стовпця;

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

-       видалення існуючого обмеження;

-       задання для стовпця значення за замовчуванням;

-       відміна значення за замовчуванням для стовпця.

 

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.7 Створення та використання переглядів

 

Розглянемо засоби мови SQL для роботи з переглядами. Інші назви переглядів, які можна зустріти – це представлення чи подання. Вони є абсолютно взаємозамінними і базуються на англійському слові view.

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

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

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

Переваги використання переглядів.

1.     Незалежність від даних.

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

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

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

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

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

6.     Можливість налаштувань – залежно від специфіки роботи одні і ті ж дані через використання переглядів можуть бути по різному представлені різним користувачам.

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

Недоліки використання переглядів.

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

2.      Структурні обмеження – при використанні символу ’*’ в запиті на вибірку для створення перегляду, то при зміні структури таблиці нові стовпці відображатимуться в перегляді, що може бути небажаним.

3.     Зниження продуктивності – при постановці запиту до перегляду СУБД здійснюється перетворення цього запиту у багато табличний запит з виконанням необхідних операцій об’єднання таблиць. Зрозуміло, що такі операції ставлять підвищені вимоги до обчислювальних ресурсів ЕОМ і завжди виконуватимуться повільніше, ніж прості однотабличні запити.

Створення переглядів.

Для створення переглядів використовують оператор CREATE VIEW  наступного формату:

 

CREATE VIEW view_name [(column_name [,…])]

AS subselect [WITH[CASCADE|LOCAL] CHECK OPTION]

 

Список стовпців column_name вказувати не обов’язково. При наведенні цього списку кількість елементів в ньому має бути рівна кількості стовпців, які утворяться в результаті виконання підзапиту subselect. Якщо імена стовпців не вказуються, то в перегляді користувач бачить назви стовпців, які потрапили в перегляд з таблиць підзапиту.

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

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

Приклади створення переглядів:

 

CREATE VIEW manager_staff

AS SELECT *

FROM staff

WHERE bno='B3';

 

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

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

При створенні переглядів допускається виконання операцій групування. Наприклад,

 

CREATE VIEW staff_prop_cnt (branch_no, staff_no, cnt)

AS SELECT s.bno, s.sno, COUNT(*)

FROM staff s, property_for_rent p

WHERE s.sno=p.pno

GROUP BY s.bno, s.sno;

 

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

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

Для знищення перегляду використовують наступний запит:

 

DROP VIEW view_name [RESTRICT|CASCADE]

 

Якщо в БД є залежні певним чином від даного перегляду інші об’єкти (інші перегляди, збережувані процедури тощо), то при вказанні ключового слова CASCADE всі залежні об’єкти будуть знищені. В іншому випадку знищення перегляду блокується.

Обмеження на використання переглядів:

–         якщо в один із стовпців перегляду утворений за допомогою узагальнюючої функції, то в запитах, котрі ставляться до даного перегляду до цього стовпця можна звертатися тільки у фразах SELECT та ORDER BY. Не можна звертатись до такого стовпця у фразах WHERE та не можна використовувати такий стовпець в якості аргументу узагальнюючої функції;

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


Математические формулы. Шпаргалка для ЕГЭ с математики

Формулы сокращенного умножения

(а+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. Место политологии среди гуманитарных наук

Политология развивается в тесном взаимодействии с другими гуманитарными науками. Их всех объединяет общий объект исследования — жизнь общества во всем многообразии ее конкретных проявлений.

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

1) Политология тесно связана с экономикой. Экономика дает соответствующее обоснование реализации экономических...

законы диалектики

Основные законы диалектики.

1)Закон единства и борьбы противоположностей.

Этот закон является «ядром» диалектики, т.к. определяет источник развития, отвечает на вопрос, почему оно происходит.

Содержание закона: источник движения и развития мира находится в нем самом, в порождаемых им противоречиях.

Противоречие – это взаимодействие противоположных сторон, свойств и тенденций в составе той или иной системы или между системами. Диалектическое противоречие есть только там, где...

Идеология

1.Идеология как социальный феномен, её сущность. Содержание идеологииСоциально-исторической системой представлений о мире стала идеология как система рационально- логического обоснования поведения людей, их ценностей, норм взаимоотношений, целей и т.д. Идеология как явление во многом сходна с религией и с наукой. От науки она восприняла доказательность и логичность своих постулатов, но, в отличие от науки, идеология призвана давать оценку явлениям действительности (что хорошо, что...