Міністерство освіти і науки України

Національний технічний університет України

“Київський політехнічний інститут”

Інститут телекомунікаційних систем

Л.С. Глоба, М.Ю. Терновой, Р.Л. Новогрудська,

О.С. Штогрина

СТВОРЕННЯ ТА ОБРОБКА БАЗ ДАНИХ

навчальний посібник для студентів технічних спеціальностей

вищих навчальних закладів

Київ 2013

2

ЗМІСТ

ТЕМА 1: Введення в БД………………………………………………………...3

ТЕМА 2: Реляційна модель. Реляційна алгебра. Реляційне числення….30

ТЕМА 3: Моделювання даних………………………………………………..58

ТЕМА 4: Нормалізація……………………………………………………….121

ТЕМА 5: Методологія проектування баз даних…………………………..163

ТЕМА 6: Архітектура систем БД. СУБД…………………………………..228

ТЕМА 7: Мова SQL…………………………………………………………...271

ТЕМА 8: Керування транзакціями…………………………………………378

ТЕМА 9: Оптимізація запитів……………………………………………….433

ТЕМА 10: Захист баз даних………………………………………………….464

3

ТЕМА 1

Введення в БД Історія досліджень систем баз даних - це, по суті, історія розвитку

прикладних програм або інформаційних систем, які досягли виняткової

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

Якщо ще 20 років тому ця сфера була всього лише областю

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

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

США становить 10 мільярдів доларів. Досягнення в дослідженнях баз даних

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

і логістики, фінансового менеджменту, систем з базами знань, методів доступу

до наукової літератури, а також великої кількості цивільних і військових

програм. Вони також послужили фундаментом значного прогресу в провідних

галузях науки - від інформатики до біології, - Зільбершац (Silberschatzetal.,

1991).

Можна стверджувати, що поява баз даних стала найважливішим

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

інформаційних систем, і це докорінно змінило характер роботи багатьох

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

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

Додатки, якими доведеться користуватися в майбутньому, виявляться

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

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

доступу до них.

Історія розвитку СУБД

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

Однак поява СУБД не призвела до повного зникнення файлових систем. Для

виконання деяких спеціалізованих завдань подібні файлові системи

використовуються досі. Вважається, що розвиток СУБД почався ще в 60-ті

роки, коли розроблявся проект польоту корабля Apollo на Місяць. Цей проект

був розпочатий з ініціативи президента США Дж. Ф. Кеннеді, що поставив

завдання висадити людину на Місяць до кінця десятиліття. У той час не

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

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

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

(тепер ця фірма називається Rockwell International) - розробили програмне

забезпечення під назвою GUAM (Generalized Update Access Method). Основна

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

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

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

ієрархічною структурою (hierarchical structure).

У середині 60-х років корпорація IBM приєдналася до фірми NAA для

спільної роботи над GUAM, в результаті чого була створена система IMS

(Information Management System). Причина, по якій корпорація IBM обмежила

4

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

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

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

типом носія в той час. Через деякий час це обмеження вдалося подолати.

Незважаючи на те, що IMS є найпершою з усіх комерційних СУБД, вона до цих

пір залишається основною ієрархічною СУБД, використовуваної на

більшості великих мейнфреймів.

Іншим помітним досягненням середини 60-х років була поява системи IDS

(Integrated Data Store) фірми General Electric. Роботу над нею очолював один з

піонерів досліджень в галузі систем управління базами даних - Чарльз Бачман.

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

базами даних - мережевих (network) СУБД, - це істотно вплинуло на

інформаційні системи того покоління. Мережева СУБД створювалася для

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

моделювати за допомогою ієрархічних структур, а також для формування

стандарту баз даних. Для створення таких стандартів в 1965 році на

конференції організації CODASYL (Conference on Data System Languages), що

проходила за участю представників уряду США і бізнесменів, була сформована

робоча група List Processing Task Force, перейменована в 1967 році в групу Data

Base Task Group (DBTG) . У компетенцію групи DBTG входило визначення

специфікацій середовища, яка допускала б розробку баз даних і керування

даними. Попередній варіант звіту цієї групи був опублікований в 1969 році, а

перший повний варіант - у 1971 році. Пропозиції групи DBTG містили три

компоненти:

• Мережева схема - це логічна організація всієї бази даних в цілому (з

точки зору АДБ), яка включає визначення імені бази даних, типу кожного

запису і компонентів записів кожного типу.

• Підсхема - це частина бази даних, як вона виглядає для користувача або

додатка.

• Мова керування даними - інструмент для визначення характеристик і

структури даних, а також для керування ними.

Група DBTG також запропонувала стандартизувати три різних мови:

• Мова визначення даних (Data Definition Language) для схеми, яка

дозволить АБД описати її.

• Мова визначення даних (також DDL) для підсхеми, яка дозволить

визначати в додатках ті частини бази даних, доступ до яких буде необхідний.

• Мова маніпулювання даними (Data manipulation Language - DML),

призначена для управління даними.

Незважаючи на те, що цей звіт офіційно не був схвалений Національним

Інститутом Стандартизації США (American National Standards Institute - ANSI),

велика кількість систем була розроблена в повній відповідності з цими

пропозиціями групи DBTG. Тепер вони називаються СОDАSУL-системами, або

DBTG-системами. СОDАSУL-системи та системи на основі ієрархічних

підходів являють собою СУБД першого покоління.

5

Однак цим двом моделям притаманні наведені нижче недоліки:

• навіть для виконання простих запитів з використанням переходів і

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

програми;

• незалежність від даних існує лише в мінімальному ступені;

• відсутність загальновизнаних теоретичних основ.

У 1970 році Е. Ф. Кодд, що працював у дослідницькій лабораторії

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

реляційну модель даних, що дозволяла усунути недоліки минулих моделей.

Слідом за цим з'явилося багато експериментальних реляційних СУБД, а перші

комерційні продукти з'явилися наприкінці 70-х - початку 80-х років. Особливо

слід відзначити проект System R, розроблений в дослідницькій лабораторії

корпорації IВМ, розташованої в місті Сан-Хосе, штат Каліфорнія, створений

наприкінці 70-х років (Astrakhan et al., 1976). Цей проект був задуманий з

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

реалізації передбачених нею структур даних і необхідних функціональних

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

• Був розроблена структурована мова запитів SQL, яка з тих пір стала

стандартною мовою будь-яких реляційних СУБД.

• У 80-х роках були створені різні комерційні реляційні СУБД - наприклад,

dв2 або SQL / DS корпорації IBM або Oracle корпорації Oracle Corporation.

В даний час існує декілька сотень різних реляційних СУБД для

мейнфреймів і мікрокомп'ютерів, хоча для багатьох з них визначення

реляційної моделі носить дещо перебільшений характер. Як приклад

багатокористувальних СУБД може служити система СА-ОреnIngress фірми

Computers Associates і систему Informix фірми Informix Software Inc.

Прикладами реляційних СУБД для персональних комп'ютерів є Access і

FохРrо фірми Microsoft, Paradox і Visual dBase фірми Borland.

Реляційні СУБД відносяться до СУБД другого покоління.

Однак реляційна модель також володіє деякими недоліками - зокрема,

обмеженими можливостями моделювання. Для вирішення цієї проблеми був

виконаний великий обсяг дослідницької роботи. У 1976 році Чен запропонував

модель "сутність-зв'язок" (Entity-relationship model - ER-модель), яка в даний

час стала найпоширенішою технологією проектування баз даних і є основою

методології.

У 1979 році Кодд зробив спробу усунути недоліки власної роботи і

опублікував розширену версію реляційної моделі - RM / Т (1979), потім ще

одну версію - RМ/V2 (1990). Спроби створення моделі даних, що дозволяє

більш точно описувати реальний світ, нестрого називають семантичним

моделюванням даних (semantic data modeling).

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

нові системи: об'єктно-орієнтовані СУБД, або OO СУБД (Object-Oriented

DBMS-OODBMS), і об'єктно-реляційні СУБД, або ОР СУБД (Object-Relational

DBMS-ORDBMS). Однак, на відміну від попередніх моделей, дійсна структура

цих, моделей не зовсім зрозуміла.

6

Система баз даних - це комп'ютеризована система зберігання записів,

тобто комп'ютеризована система, основне призначення якої - зберігати

інформацію, надаючи користувачам засоби її вилучення та модифікації. До

інформації може відноситися все, що заслуговує уваги окремого користувача

або організації.

База даних - це єдине, велике сховище даних, яке одноразово

визначається, а потім використовується одночасно багатьма користувачами

через різні прикладні програми, завдяки чому база даних є загальним

корпоративним ресурсом.

Система управління базами даних, або СУБД (Database Management

System - DBMS) - програмне забезпечення, яке управляє доступом до цієї бази

даних.

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

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

даних всіх товарів. Потім програма відніме кількість всіх щойно проданих товарів з товарних

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

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

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

покупки по телефону, касир може перевірити наявність того чи іншого товару на складі,

також запустивши деякий додаток баз даних.

Якщо при покупках використовується кредитна картка, касир повинен перевірити

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

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

випадку при цьому використовується якась база даних, яка містить відомості про покупки,

здійснювані за допомогою кредитної картки. На основі номера кредитної картки

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

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

всі відомості про придбані товари вводяться в базу даних. Однак ще до отримання

підтвердження допустимості купівлі додаток бази даних повинен переконатися в тому, що

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

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

платежу, а також щомісяця посилати кожному власнику кредитної картки повний звіт.

Можна розглядати й інші прикладні програми, що працюють з БД.

Файлові системи Зберігання даних як інформаційного ресурсу раніше здійснювалося

безпосередньо в тілі програми, що було вкрай неефективно. Наступним кроком

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

(file-based system).

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

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

свої власні дані і керує ними.

Файлові системи були розроблені у відповідь на потребу в отриманні

більш ефективних способів доступу до даних.

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

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

7

використовуються прикладними програмами, був використаний

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

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

Файловим системам властиві такі обмеження:

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

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

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

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

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

Поділ та ізоляція даних: дані ізольовані в окремих файлах, доступ до них

дуже ускладнений, виконувати подібну обробку даних у файлових системах

досить складно. Для вилучення відповідної поставленим умовам інформації

програміст повинен організувати відповідну обробку всіх необхідних файлів

даних.

Дублювання даних: через децентралізовану роботу з даними в файловій

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

Безконтрольне дублювання даних небажано через наступні причини:

1. Дублювання даних супроводжується неекономним витрачанням

ресурсів, оскільки на введення надлишкових даних потрібно затрачати

додаткові час і гроші. Більше того, для їх зберігання необхідно додаткове місце

у зовнішній пам'яті, що пов'язано з додатковими накладними витратами. У

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

використання файлів.

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

до порушення їх цілісності.

Наприклад, розглянемо випадок дублювання даних в розрахунковому

секторі бухгалтерії та відділі кадрів. Якщо співробітник переїде в інший

будинок і зміна адреси буде зафіксована тільки у відділі кадрів, то

повідомлення про зарплату буде послано йому за старою, тобто помилковою,

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

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

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

залишившись не проведеною у файлах розрахункового сектора, то даний

співробітник помилково буде отримувати колишню заробітну плату. При

виявленні подібної помилки для її виправлення буде потрібно затратити

додатковий час і кошти.

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

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

поновлення даних одночасно і у файлах відділу кадрів, і у файлах

розрахункового сектора, неважко передбачити, що подібні протиріччя час від

часу обов'язково будуть виникати. Навіть якщо співробітники розрахункового

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

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

8

Залежність від даних: фізична структура і спосіб зберігання записів

файлів даних жорстко зафіксовані в коді програм додатків. Це означає, що

змінити існуючу структуру даних досить складно.

Наприклад, збільшення у файлі довжини поля адреси будь-якого даного з

40 до 41 символу здається зовсім незначною зміною його структури, але для

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

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

перетворюючу вже існуючий файл у новий формат. Вона повинна виконувати

наступні дії:

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

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

• зчитати запис з вихідного файлу, перетворити дані в новий формат і

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

вихідного файлу;

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

• присвоїти тимчасовому файлу необхідне ім'я.

Таким чином, виконання всіх цих дій вимагає велику витрату часу і може

бути причиною появи помилок.

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

даних (program-data dependence).

Несумісність форматів файлів: структура файлів визначається кодом

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

програми.

Наприклад, структура файлу, створеного програмою на мові СОВОL,

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

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

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

програм: З точки зору користувача постійно зростають вимоги до реалізації

нових або модифікованих запитів. Однак файлові системи багато в чому

залежать від програміста, тому що всі необхідні запити і звіти повинні бути

створені саме ним.

У результаті події зазвичай розвивалися по одному з наступних двох

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

фіксовану форму, і не було ніяких інструментів створення незапланованих або

довільних (ad hос) запитів, як до самих даних, так і до відомостей про те, які

типи даних доступні.

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

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

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

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

момент, коли програмне забезпечення було нездатне адекватно відповідати

запитам користувачів, ефективність його падала, а недостатність

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

При цьому часто ігнорувалися питання підтримки функціональності системи:

не передбачалися заходи щодо забезпечення безпеки або цілісності даних;

9

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

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

одним користувачем.

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

факторів:

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

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

2. Крім прикладних програм не передбачено жодних інших інструментів

доступу до даних і їх обробки.

Для підвищення ефективності роботи необхідно використовувати новий

підхід, а саме базу даних (database) і систему управління базами даних, або

СУБД (Database management System-DBMS).

База даних зберігає не тільки робочі дані, але і їх опис. З цієї причини базу

даних ще називають набором інтегрованих записів з самоописом.

У сукупності, опис даних називається системним каталогом (system

catalog), або словником даних (data dictionary), а самі елементи опису прийнято

називати метаданими (meta-data), тобто "Даними про дані".

Саме наявність самоопису даних в базі даних забезпечує в ній

незалежність між програмами і даними (program-data independence).

Підхід, заснований на застосуванні баз даних, де визначення даних

відокремлено від прикладних програм, дуже схожий на підхід, який

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

поряд із внутрішнім визначенням об'єкта існує його зовнішнє визначення.

Користувачі об'єкта бачать тільки його зовнішнє визначення і не піклуються

про те, як він визначається і як функціонує.

Одна з переваг такого підходу, а саме абстрагування даних (data

abstraction), полягає в тому, що можна змінити внутрішнє визначення об'єкта

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

визначення об'єкта залишається незмінним.

Аналогічним чином, у підході з використанням баз даних, структура даних

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

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

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

Наприклад, додавання нового поля в запис або створення нового файлу

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

використовуваного додатком файлу вплине на цю прикладну програму, а тому

його також буде потрібно відповідним чином модифікувати.

У базах даних використовуються логічно пов'язані дані. Термін "логічно

пов'язаний" використовується, коли при аналізі інформаційних потреб

організації слід виділити сутності, атрибути та зв'язки.

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

поняття або поді), який потрібно представити в базі даних.

10

Атрибутом (attribute) називається властивість, яка описує деяку

характеристику описуваного об'єкта;

Зв'язок (relationship) - це те, що об'єднує кілька сутностей.

Діаграму "сутність-зв'язок", або ER-діаграму (Entity relationship - ER)

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

таких компонентів:

• Сутностей (позначені прямокутниками): група, студент, викладач,

кафедра, предмет, навчальний процес, успішність.

• Зв'язків (позначені ромбиками), що об'єднують основні сутності. Наприклад,

ГС (скорочення Група / Студент): кожен студент перебуває в певній групі, і

кожна група містить певного студента. Аналогічно, кожна група належить

до певної кафедрі, а кафедра складається з певних груп (зв'язок ГК - скорочення

від Група / Кафедра); викладач відноситься до кафедри, а кафедра має певних

викладачів (зв'язок КВ - скорочення Кафедра / Викладач) і т.д.

Рис. 1.1. Приклад діаграми «сутність-зв'язок».

Подібна база даних ілюструє сутності, атрибути та логічні зв'язки між

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

Зазвичай дані в базі даних називають перманентними або постійно

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

словом перманентні (persistent) маються на увазі дані, які відрізняються від

інших, більш мінливих даних, таких як проміжні результати, вхідні і вихідні

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

дані, тимчасові (transient) за своєю суттю. Можна стверджувати, що дані в

базі є перманентними, оскільки після того як вони були прийняті засобами

СУБД для приміщення в базу, їх подальше видалення можливо лише при

використанні відповідного явного запиту до бази даних, але не в результаті

Успішність Навчальний

процес

ПУ ВН

НУ

Предмет Викладач

Кафедра

ВК

ВП

ГК КС СП

ГКС

Студент Група ГС

11

будь-якого побічного ефекту від виконання деякої програми. Подібний

погляд на поняття перманентності дозволяє точніше визначити термін база

даних.

База даних - це деякий набір перманентних (постійно збережених)

даних, що використовуються прикладними програмними системами якого-

небудь підприємства.

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

термін операційні дані. Старий термін акцентував увагу на особливому

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

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

оперативна обробка транзакцій (On-Line Transaction Processing - OLTP).

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

прийняття рішень (decision support), і термін операційні дані для них вже не

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

даних - з операційними даними і з даними для підтримки прийняття рішень;

останню зазвичай називають сховищем даних (data warehouse). У сховищах

даних часто міститься агрегована інформація, яка, у свою чергу, періодично

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

Типи інформації в базі даних:

1. Дані користувачів. Сьогодні більшість БД представляють дані

користувачів у вигляді відношень (relations). Відношення - це таблиця даних.

Стовпці таблиці містять поля, або атрибути, а рядки містять записи про

конкретні об'єкти ділового світу.

2. Метадані. Як відомо база даних є самодокументованой, тобто однією

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

Так як СУБД призначені для зберігання таблиць і маніпуляції ними,

більшість з них зберігають метадані у формі таблиць, іноді званих

системними таблицями. Зберігання метаданих в таблицях не лише ефективно

для СУБД, але і зручно для розробників, оскільки для запиту метаданих вони

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

3. Індекси. Наступний тип даних, який зберігається в базі даних,

покликаний поліпшити її продуктивність і доступність. Ці дані, звані іноді

надлишковими даними, складаються головним чином з індексів, хоча в ряді

випадків використовуються й інші структури даних, такі як зв'язані списки.

Індекси використовуються не тільки для сортування, але і для швидкого

доступу до даних.

4. Метадані додатків. Останній тип інформації в базі даних - це

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

запитів і інших компонентів додатків. Не всі СУБД підтримують компоненти

додатків, а з тих СУБД, де така можливість передбачена, не всі зберігають

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

12

більшість сучасних СУБД зберігають цю інформацію в базі даних. Взагалі

кажучи, ні розробники баз даних, ні користувачі не звертаються до

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

які надає СУБД.

Система управління базами даних - СУБД

СУБД - це програмне забезпечення, за допомогою якого користувачі

можуть визначати, створювати і підтримувати базу даних, а також

здійснювати до неї контрольований доступ.

СУБД можна також визначати, як програмне забезпечення, яке

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

наведеними нижче можливостями:

1. Дозволяє визначати базу даних, що зазвичай здійснюється за

допомогою мови визначення даних (DDL - Data Definition Language). DDL

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

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

зберігається в базі даних.

2. Дозволяє вставляти, оновлювати, видаляти і витягувати інформацію

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

даними (Data Manipulation Language). Наявність централізованого сховища

всіх даних та їх описів дозволяє використовувати мову DML як загальний

інструмент організації запитів, який іноді називають мовою запитів (query

language). Мова запитів дозволяє усунути властиві файловим системам

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

фіксованим набором запитів або постійно зростаючою кількістю програм, що

породжує інші, більш складні проблеми управління програмним

забезпеченням.

Існує два різновиди мов DML - процедурні (procedural) і

непроцедурні (non-procedural) мови, - які відрізняються між собою способом

вилучення даних. Процедурні мови звичайно обробляють інформацію в базі

даних послідовно, запис за записом, а непроцедурні оперують відразу цілими

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

як можна отримати бажаний результат, тоді як непроцедурні мови DML

використовуються для опису того, що слід отримати.

Найбільш поширеним типом непроцедурного мови є мова

структурованих запитів (Structured Query Language - SQL), яка в даний час

визначається спеціальним стандартом і фактично є обов'язковою мовою для

будь-яких реляційних СУБД.

3. СУБД надає контрольований доступ до бази даних за допомогою

перерахованих нижче засобів:

13

• системи забезпечення безпеки, яка запобігає несанкціонованому

доступу до бази даних з боку користувачів;

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

стан збережених даних;

• системи управління паралельною роботою прикладних програм, яка

контролює процеси їх спільного доступу до бази даних;

• системи відновлення, що дозволяє відновити базу даних до

попереднього несуперечливого стану, порушеного в результаті збою

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

• доступного користувачам каталогу, що містить опис інформації, що

зберігається в базі даних.

Моделі даних

Модель даних - це інтегрований набір понять для опису даних, зв'язків

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

Модель є представленням "реального світу" об'єктів і подій, а також

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

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

другорядні властивості ігноруються. Модель повинна відображати основні

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

користувачам бази даних обмінюватися конкретними і недвозначними

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

Модель даних розглядається як поєднання трьох компонентів:

• Структурна частина - набір правил, за якими може бути побудована

база даних.

• Керуюча частина, що визначає типи допустимих операцій з даними

(сюди відносяться операції оновлення та вилучення даних, а також операції

зміни структури бази даних).

• Набір обмежень підтримки цілісності даних (необов'язково), що

гарантують коректність використовуваних даних.

Мета побудови моделі даних полягає в поданні даних в зрозумілому

вигляді. Якщо таке подання можливо, то модель даних можна буде легко

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

Всі моделі даних поділяються на три категорії:

• об'єктні (object-based) моделі даних;

• моделі даних на основі записів (record-based);

14

• фізичні моделі даних.

Об'єктні моделі даних

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

вище, поняття сутність, атрибути та зв'язки. Найбільш загальні типи

об'єктних моделей даних:

• Модель типу "сутність-зв'язок" або ER-модель (Entity-Relationship

model).

• Семантична модель.

• Функціональна модель.

• Об'єктно-орієнтована модель.

В даний час ER-модель стала одним з основних методів

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

Об'єктно-орієнтована модель розширює визначення сутності з метою

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

які з ним пов'язані, тобто його поведінку. У такому випадку говорять, що

об'єкт інкапсулює стан і поведінку.

Моделі даних на основі записів

У моделі на основі записів база даних складається з декількох записів

фіксованого формату, які можуть мати різні типи. Кожен тип запису визначає

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

основних типи логічних моделей даних на основі записів:

• реляційна модель даних (relational data model);

• мережева модель даних (network data model);

• ієрархічна модель даних (hierarchical data model).

Ієрархічна і мережева моделі даних були створені майже на десять років

раніше реляційної моделі даних, а тому їх зв'язок з концепціями традиційної

обробки файлів більш очевидний.

Реляційна модель даних

Короткий огляд історії реляційної моделі

Реляційна модель вперше була запропонована Е.Ф.Коддом в 1970 році в

його статті "Реляційна модель даних для великих спільно використовуваних

банків даних". В даний час публікацію цієї статті прийнято вважати

поворотним пунктом в історії розвитку систем баз даних, хоча слід

зауважити, що ще раніше була запропонована модель, заснована на

15

множинах (Chils, 1968). Цілі створення реляційної моделі формулювалися

наступним чином:

• Забезпечення більш високого ступеня незалежності від даних.

Прикладні програми не повинні залежати від змін внутрішнього подання

даних, зокрема від змін організації файлів, перевпорядкування записів і шляхів

доступу.

• Створення міцного фундаменту для вирішення семантичних питань, а

також проблем несуперечності і надмірності даних. Зокрема, у статті

Кодда вводиться поняття нормалізованих відношень, тобто відношень без

повторюваних груп.

• Розширення мов управління даними за рахунок включення операцій над

множинами.

Хоча інтерес до реляційної моделі обумовлений декількома різними

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

трьох проектів з дуже різною долею.

Перший з них розроблявся в кінці 70-х років у дослідницькій

лабораторії корпорації IBM в місті Сан-Хосе, штат Каліфорнія, під

керівництвом Астрахана, результатом якого стало створення системи під

назвою "System R", що була прототипом істинної реляційної СУБД. Цей

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

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

структур даних і операцій. Цей проект також зарекомендував себе як

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

управління паралельністю, оптимізація запитів, управління транзакціями,

забезпечення безпеки і цілісності даних, технологія відновлення, вплив

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

стимулювало публікацію багатьох науково-дослідницьких статей та

створення інших прототипів реляційних СУБД. Зокрема, робота над

проектом System R дала поштовх проведенню таких найважливіших

розробок, як:

• створення мови структурованих запитів SQL (це назва вимовляють або

по буквах "SQL", або (іноді) за допомогою мнемонічного імені "See-Quel",

який з тих пір придбав статус формального стандарту ISO (International

Organization for Standardization) і в даний час є фактичним галузевим

стандартом мови реляційних СУБД;

• створення різних комерційних реляційних СУБД, які вперше з'явилися

на ринку на початку 80-х років, таких як dв2 і SQL / DS корпорації IBM, а

також ORACLE корпорації ORACLE Corporation.

Другим проектом, який зіграв помітну роль у розробці реляційної

моделі даних, був проект INGRES (Interactive Graphics Retrieval System),

16

робота над яким проводилася в Каліфорнійському університеті (місто Берклі)

майже в той же самий час, що й над проектом System R. Проект INGRES

включав розробку прототипу РСУБД з концентрацією основної уваги на тих

же загальних цілях, що і проект System R. Ці дослідження привели до появи

академічної версії INGRES, яка зробила істотний внесок у загальне визнання

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

комерційні продукти INGRES фірми Relational Technology Inc. (Тепер СА-

OpenIgress фірми Computers Associates) і Intelligent Database Machine фірми

Britton Lee Inc.

Третім проектом була система Peterlee Relational Test Vehicle наукового

центру корпорації IВМ, розташованого в місті Потерлі, Великобританія. Цей

проект був більш теоретичним, ніж проекти System R і INGRES. Його

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

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

розширення системи.

Комерційні системи на основі реляційної моделі даних почали

з'являтися в кінці 70-х - початку 80-х років. В даний час існує декілька сотень

типів різних реляційних СУБД як для мейнфреймів, так і для

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

визначенню реляційної моделі даних. Прикладами реляційних СУБД для

мікрокомп'ютерів є СУБД Access і FохРrо фірми Microsoft, Раrаdох і Visual

dBase фірми Borland, а також R: ВАSЕ фірми Microrim.

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

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

використовуваної базової моделі. Основна мережева СУБД, система IDMS.

тепер називається IDMS / R (або IDMS / SQL) підтримує реляційне

представлення даних. Іншими СУБД для мейнфреймів, в яких підтримуються

деякі реляційні компоненти, є Model 204 фірми Computer Corporation of

America і АDАВА8 D фірми Software AG.

Крім того, пізніше були запропоновані деякі розширення реляційної

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

даних (Codd, 1979) об'єктно-орієнтованих понять (Stonebraker and Row,

1986), а також для підтримки дедуктивних можливостей (Gardarin and

Valduries, 1989).

17

Рис. 1.2. Структура обробки інформації в реляційній БД

Використовувана термінологія

Реляційна модель заснована на математичному понятті відношення,

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

досвідченим математиком, широко використовував математичну

термінологію, особливо з теорії множин і логіки предикатів.

Рис. 1.3. Структура реляційних даних

Номер

Прізвище

Оцінка

6

Лисенко

5

17

Мельник

4

19

Ткачук

4.5

В

І

Д

Н

О

Ш

Е

Н

Н

Я

С Т Е П І Н Ь

АТРИБУТИ

КОРТЕЖ

Реляційна

алгебра Дані Реляційна

модель даних

Реляційна БД

SQL-

стандартна

мова запитів

18

Відношення - це плоска таблиця, що складається із стовпців і рядків.

У будь-якій реляційній СУБД передбачається, що користувач

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

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

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

допомогою різних структур зберігання.

Атрибут - це поіменований стовпець відношення.

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

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

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

стовпці - атрибутам. При цьому атрибути можуть розташовуватися в будь-

якому порядку, незалежно від їх перевпорядкувания відношення буде

залишатися одним і тим же, а тому мати той же зміст.

Наприклад, інформація про студентів може бути представлена

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

Номер групи, Прізвище, Середній бал. Аналогічно, інформація про

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

стовпці з атрибутами Табельний номер, Прізвище, Роб. телефон, Факс. На

рис. 1.4. показані приклади відношень Студент та Викладач.

Студент

Номер заліковки Номер

групи

Прізвище Середній

бал

ТІ1102 ТІ11 Бадяк 5

ТЗ1107 ТЗ11 Клименко 4

ТІ1103 ТІ11 Батієв 3,5

ТІ1119 ТІ11 Таран 4,5

Викладач

Табельний

номер

Прізвище Роб.

телефон

Факс

4587 Якорнов 456-37-85 456-86-27

19

2136 Карнаух 474-96-35 474-85-12

5496 Терновой 468-05-38 468-28-01

Рис. 1.4. Приклади відносин Студент та Викладач.

Домен - це набір допустимих значень для одного або декількох

атрибутів.

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

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

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

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

У табл. 1.1 представлені домени для атрибутів відношень Студент та

Викладач. Хоча у відношенні Викладач є чотири атрибути, тут показані

тільки три, тому що два атрибути, Раб. телефон і Факс, визначені на одному і

тому ж домені.

У будь-який момент часу в доменах можуть існувати значення, які не

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

Таблиця 1.1. Домени атрибутів відносин Студент та Викладач

Атрибут Ім’я домена Вміст домена Визначення

домена

Номер

заліковки

НОМЕР_ЗАЛІК

ОВКИ

Множина усіх

допустимих номерів

заліковок студентів

Символьний:

розмір 6,

діапазон

‘ТЗ1101’-

‘ТІ1125’

Номер групи НОМЕР_ГРУПИ Множина усіх наявних

груп

Символьний:

розмір 4,

діапазон

‘ТЗ11’-‘ТІ11’

Прізвище ПРІЗВИЩЕ_

СТУДЕНТА

Множина усіх прізвищ

студентів

Символьний:

розмір 15

Прізвище ПРІЗВИЩЕ _

ВИКЛАДАЧА

Множина усіх прізвищ

викладачів

Символьний:

розмір 15

20

Середній бал СЕРЕДНІЙ_БА

Л

Множина усіх

допустимих середніх балів

студентів

Символьний:

розмір 3

Табельний

номер

ТАБЕЛЬНИЙ_

НОМЕР

Множина усіх

табельних номерів

викладачів

Символьний:

розмір 4

Роб. телефон РОБОЧИЙ_

ТЕЛЕФОН_ФА

КС

Множина усіх номерів

телефонів і факсів

викладачів

Символьний:

розмір 7

Факс РОБОЧИЙ_

ТЕЛЕФОН_ФА

КС

Множина усіх номерів

телефонів і факсів

викладачів

Символьний:

розмір 7

Поняття домену має велике значення, оскільки завдяки йому користувач

може централізовано визначати зміст і джерело значень, які можуть

отримувати атрибути.

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

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

Наприклад, безглуздо порівнювати назву вулиці з номером телефону,

навіть якщо для обох цих атрибутів визначеннями доменів є символьні

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

Як випливає з цих двох прикладів, забезпечити повну реалізацію

поняття домену зовсім непросто, а тому в багатьох РСУБД вони

підтримуються не повністю, а лише частково.

Кортеж - це рядок відносини.

Елементами в є кортежі, або рядки, таблиці. Кортежі можуть

розташовуватися в будь-якому порядку, при цьому відношення буде

залишатися тим же самим, а значить, і мати той же зміст.

Опис структури відношення разом зі специфікацією доменів і будь-

якими іншими обмеженнями можливих значень атрибутів іноді називають

його заголовком (або змістом (intension)). Зазвичай воно є фіксованим до

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

додаткових атрибутів.

Кортежі називаються розширенням (extension), станом (state) або тілом

відношення, яке постійно змінюється.

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

21

Відношення Студент, показане на рис. 1.4, має чотири атрибути і, отже,

його степінь дорівнює чотирьом.

Відношення тільки з одним атрибутом має степінь 1 і називається

унарним відношенням (або 1-арним кортежем). Відношення з двома

атрибутами називається бінарним, відношення з трьома атрибутами -

тернарним, а для відносин з великою кількістю атрибутів використовується

термін п-арний.

Визначення степеня відношення є частиною заголовка відношення.

Кардинальність - це кількість кортежів, яке містить відношення.

Ця характеристика змінюється при кожному додаванні або видаленні

кортежів. Кардинальність є властивістю тіла відношення і визначається

поточним станом відношення в довільно взятий момент.

Реляційна база даних - це набір нормалізованих відношень.

Реляційна база даних складається з відношень, структура яких

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

Альтернативна термінологія

Термінологія, використовувана в реляційної моделі, часом може

призвести до плутанини, оскільки крім запропонованих двох наборів

термінів існує ще один - третій.

Відношення в ньому називається файлом, кортежі - записами, а

атрибути - полями.

Ця термінологія заснована на тому факті, що фізично реляційна СУБД

може зберігати кожне відношення в окремому файлі. У табл. 1.2 показані

відповідності, що існує між трьома згаданими вище групами термінів.

Таблиця 1.2. Альтернативні варіанти термінів у реляційної моделі

Офиційні терміни Альтернативний

варіант 1

Альтернативний

варіант 2

Відношення Таблиця Файл

Кортеж Рядок Запис

Атрибут Стовпець Поле

Відношення та його властивості в базі даних

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

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

22

Наприклад, для атрибутів А1, А2, .... Аn з доменами D1, D2 .... Dn

реляційної схемою буде множина {А1: D1 ... An: Dn}.

Відношення R, задане реляційною схемою S, є множиною відображень

імен атрибутів на відповідні їм домени, тобто відношення R є множиною

таких n-арних кортежів.

Кожен елемент n-арного кортежу складається з атрибуту і значення

цього атрибута.

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

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

(d1, d2, ... dn), де кожне значення береться з відповідного домену.

Таким чином, в реляційної моделі відношення можна представити як

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

фізичне уявлення такого відношення.

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

Номер заліковки, Номер групи, Прізвище, Середній бал з відповідними їм

доменами. Відношення Студент являє собою довільну підмножину

декартового добутку доменів або довільну множину 4-арних кортежів, в яких

першим йде елемент з домену НОМЕР_ЗАЛІКОВКИ, другим - елемент з

домену НОМЕР_ГРУПИ і т.д. Наприклад, один з 4-арних кортежів може

мати такий вигляд:

{(ТІ1102, ТІ11, Бадяк, 5)}

Цей же кортеж можна записати в більш коректній формі:

{(Номер заліковки: 'ТІ1102', Номер групи: ' ТІ11', Прізвище: ' Бадяк ',

Середній бал: '5 ')}

Таблиця Студент представляє собою зручний спосіб запису всіх 4-арних

кортежів, що утворюють відношення в деякий заданий момент часу.

Відношення має такі характеристики:

• Відношення має ім'я, яке відрізняється від імен всіх інших відношень.

• Кожна комірка відношення містить тільки атомарне (неподільне)

значення.

• Кожен атрибут має унікальне ім'я.

• Значення атрибуту беруться з одного і того ж домена.

• Порядок слідування атрибутів не має ніякого значення.

• Кожен кортеж є унікальним, тобто дублікатів кортежів бути не може.

23

• Теоретично порядок слідування кортежів у відношенні не має ніякого

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

ефективність доступу до них).

Відношення не можуть містити повторюваних груп.

Розглянемо відношення Студент (рис. 1.4.). Імена стовпців, зазначені в

його верхньому рядку, відповідають іменам атрибутів відношення. Значення

атрибута Номер заліковки беруться з домену НОМЕР_ЗАЛІКОВКИ, не

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

середнього балу.

Стовпці можна міняти місцями за умови, що ім'я атрибута

переміщується разом з його значеннями.

Відношення не може містити кортежів-дублікатів.

Наприклад, рядок (ТІ1102, ТІ11, Бадяк, 5) може бути представлений у

відношенні тільки один раз.

При необхідності рядки можна міняти місцями довільним чином

(наприклад, перемістити весь рядок, який відноситься до студента 'Таран' на

місце рядка студента 'Клименко'), саме відношення при цьому залишиться

колишнім.

Велика частина властивостей відношень випливає з властивостей

математичних відношень:

• Оскільки відношення є множиною, то порядок елементів не має

значення. Отже, порядок кортежів у відношенні неістотний.

• У множині немає повторюваних елементів. Аналогічно, відношення не

може містити кортежів-дублікатів.

• При обчисленні декартового добутку множин з простими

однозначними елементами (наприклад, цілочисельними значеннями), кожен

елемент в кожному кортежі має єдине значення. Аналогічно кожна клітинка

відношення містить тільки одне значення. Однак математичне відношення

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

повторюваних груп з метою спрощення реляційної моделі даних.

• Набір можливих значень для даної позиції відношення визначається

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

значення в кожному стовпці повинні вибиратися із одного і того ж домена,

визначеного для даного атрибуту. Однак у математичному відношенні

порядок слідування елементів не має значення, в кортежі має значення.

Наприклад, допустима пара значень (1,2) абсолютно відмінна від допустимої пари

(2,1). Це твердження невірно для відношення в реляційної моделі, де спеціально

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

24

однозначно визначають, до якого саме атр�