Теоретичні основи

Ми приступаємо до вивчення реляційних баз даних і систем управління реляційними базами даних. Цей підхід є найбільш поширеним в цей час, хоч нарівні із загальновизнаними достоїнствами володіє і рядом недоліків. До числа достоїнств реляційного підходу можна віднести:
наявність невеликого набору абстракцій, які дозволяють порівняно просто моделювати велику частину поширених предметних областей і допускають точні формальні визначення, залишаючись інтуїтивно зрозумілими;
наявність простою і в той же час могутнього математичного апарату, що спирається головним чином на теорію множин і математичну логіку і забезпечуючий теоретичний базис реляційного підходу до організації баз даних;
можливість ненавігаційного маніпулювання даними без необхідності знання конкретної фізичної організації баз даних у зовнішній пам'яті.
Реляційні системи далеко не відразу набули широкого поширення. У той час, як основні теоретичні результати в цій області були отримані ще в 70-х, і тоді ж з'явилися перші прототипи реляційних СУБД, довгий час вважався неможливим добитися ефективної реалізації таких систем. Однак відмічені вище переваги і поступове накопичення методів і алгоритмів організації реляційних баз даних і управління ними привели до того, що вже в середині 80-х років реляційні системи практично витіснили з світового ринку ранню СУБД.
У цей час основним предметом критики реляційних СУБД є не їх недостатня ефективність, а властива цим системам деяка обмеженість (пряме слідство простоти) при використання в так званих нетрадиційних областях (найбільш поширеними прикладами є системи автоматизації проектування), в яких потрібні гранично складні структури даних. Ще одним що часто відмічається недоліком реляційних баз даних є неможливість адекватного відображення семантики предметної області. Іншими словами, можливості уявлення знань про семантичну специфіку предметної області в реляційних системах дуже обмежені. Сучасні дослідження в області післяреляційних систем головним чином присвячені саме усуненню цих недоліків.
Лекція 4. Загальні поняття реляційного підходу до організації БД. Основні концепції і терміни
На цій лекції ми введемо на порівняно неформальному рівні основні поняття реляційних баз даних, а також визначимо істоту реляційної моделі даних. Основною метою лекції є демонстрація простоти і можливості інтуїтивної інтерпретації цих понять. У подальших лекціях будуть приводитися більш формальні визначення, на яких засновується математична теорія реляційних баз даних.
4.1. Базові поняття реляційних баз даних
Основними поняттями реляційних баз даних є тип даних, домен, атрибут, кортеж, первинний ключ і відношення.
Для початку покажемо значення цих понять на прикладі відношення СПІВРОБІТНИКИ, що містить інформацію про співробітників деякої організації:
4.1.1. Тип даних
Поняття тип даних в реляційної моделі даних повністю адекватно поняттю типу даних в мовах програмування. Звичайно в сучасної реляційних БД допускається зберігання символьних, числових даних, бітових рядків, спеціалізованих числових даних (таких як "гроші"), а також спеціальних "темпоральних" даних (дата, час, тимчасової інтервал). Досить активно розвивається підхід до розширення можливостей реляційних систем абстрактними типами даних (відповідними можливостями володіють, наприклад, системи сімейства Ingres/Postgres). У нашому прикладі ми маємо справу з даними трьох типів: рядки символів, цілі числа і "гроші".
4.1.2. Домен
Поняття домену більш специфічне для баз даних, хоч і має деякі аналогії з підтипами в деяких мовах програмування. У самому загальному вигляді домен визначається завданням деякого базового типу даних, до якого відносяться елементи домен, і довільного логічного вираження, що застосовується до елемента типу даних. Якщо обчислення цього логічного вираження дає результат "істина", то елемент даних є елементом домену.
Найбільш правильним інтуїтивним трактуванням поняття домену є розуміння домену як допустимої потенційної безлічі значень даного типу. Наприклад, домен "Імена" в нашому прикладі визначений на базовому типі рядків символів, але в число його значень можуть входити тільки ті рядки, які можуть зображати ім'я (зокрема, такі рядки не можуть починатися з м'якого знаку).
Потрібно відмітити також семантичне навантаження поняття домену: дані вважаються порівнянними тільки в тому випадку, коли вони відносяться до одного домену. У нашому прикладі значення доменів "Номера пропусків" і "Номера груп" відносяться до типу цілих чисел, але не є порівнянними. Помітимо, що в більшості реляційних СУБД поняття домену не використовується, хоч в Oracle V.7 воно вже підтримується.
4.1.3. Схема відношення, схема бази даних
Схема відношення - це іменована безліч пар {ім'я атрибута, ім'я домену (або типу, якщо поняття домену не підтримується)}. Ступінь або "арність" схеми відношення - потужність цієї безлічі. Ступінь відношення СПІВРОБІТНИКИ рівна чотирьом, тобто воно є 4-арным. Якщо всі атрибути одного відношення визначені на різних доменах, осмислено використати для іменування атрибутів імена відповідних доменів (не забуваючи, звичайно, про те, що це є усього лише зручним способом іменування і не усуває відмінності між поняттями домену і атрибута).
Схема БД (в структурному значенні) - це набір іменованих схем відносин.
4.1.4. Кортеж, відношення
Кортеж, відповідний даній схемі відношення, - це безліч пар {ім'я атрибута, значення}, яке містить одне входження кожного імені атрибута, що належить схемі відношення. "Значення" є допустимим значенням домену даного атрибута (або типу даних, якщо поняття домену не підтримується). Тим самим, ступінь або "арність" кортежу, тобто число елементів в ньому, співпадає з "арністю" відповідної схеми відношення. Просто кажучи, кортеж - це набір іменованих значень заданого типу.
Відношення - це безліч кортежів, відповідних одній схемі відношення. Іноді, щоб не плутатися, кажуть "відношення-схема" і "відношення-примірник", іноді схему відношення називають заголовком відношення, а відношення як набір кортежів - тілом відношення. Насправді, поняття схеми відношення ближче усього до поняття структурного типу даних в мовах програмування. Було б цілком логічно дозволяти окремо визначати схему відношення, а потім одне або декілька відносин з даною схемою.
Однак в реляційних базах даних це не прийняте. Ім'я схеми відношення в таких базах даних завжди співпадає з ім'ям відповідного відношення-примірника. У класичних реляційних базах даних після визначення схеми бази даних змінюються тільки відносини-примірники. У них можуть з'являтися нові і віддалятися або модифікуватися існуючі кортежі. Однак в багатьох реалізаціях допускається і зміна схеми бази даних: визначення нових і зміна існуючих схем відношення. Це прийнято називати еволюцією схеми бази даних.
Звичайним життєвим представленням відношення є таблиця, заголовком якої є схема відношення, а рядками - кортежі відношення-примірника; в цьому випадку імена атрибутів іменують стовпці цієї таблиці. Тому іноді кажуть "стовпець таблиці", маючи на увазі "атрибут відношення". Коли ми перейдемо до розгляду практичних питань організації реляційних баз даних і коштів управління, ми будемо використати цю життєву термінологію. Цієї термінології дотримуються в більшості комерційній реляційних СУБД.
Реляційна база даних - це набір відносин, імена яких співпадають з іменами схем відносин в схемі БД.
Як видно, основні структурні поняття реляційної моделі даних (якщо не вважати поняття домену) мають дуже просту інтуїтивну інтерпретацію, хоч в теорії реляційних БД всі вони визначаються абсолютно формально і точно.
4.2. Фундаментальні властивості відносин
Зупинимося тепер на деяких важливих властивостях відносин, які виходять з приведених раніше визначень:
4.2.1. Відсутність кортежів-дублікатів
Та властивість, що відносини не містять кортежів-дублікатів, виходить з визначення відношення як безлічі кортежів. У класичній теорії множин по визначенню кожна безліч складається з різних елементів.
З цієї властивості витікає наявність у кожного відношення так званого первинного ключа - набору атрибутів, значення яких однозначно визначають кортеж відношення. Для кожного відношення принаймні повний набір його атрибутів володіє цією властивістю. Однак при формальному визначенні первинного ключа потрібне забезпечення його "мінімальності", тобто в набір атрибутів первинного ключа не повинні входити такі атрибути, які можна відкинути без збитку для основної властивості - однозначно визначати кортеж. Поняття первинного ключа є виключно важливим в зв'язку з поняттям цілісності баз даних.
Забігаючи уперед, помітимо, що в багатьох практичних реалізаціях РСУБД допускається порушення властивості унікальності кортежів для проміжних відносин, що породжуються неявно при виконанні запитів. Такі відносини є не множинами, а мультимножинами, що в ряді випадків дозволяє добитися певних переваг, але іноді приводить до серйозних проблем.
4.2.2. Відсутність впорядкованості кортежів
Властивість відсутності впорядкованості кортежів відношення також є слідством визначення відношення-примірника як безлічі кортежів. Відсутність вимоги до підтримки порядку на безлічі кортежів відношення дає додаткову гнучкість СУБД при зберіганні баз даних у зовнішній пам'яті і при виконанні запитів до бази даних. Це не суперечить тому, що при формулюванні запиту до БД, наприклад, на мові SQL можна зажадати сортування результуючої таблиці у відповідності зі значеннями деяких стовпців. Такий результат, взагалі кажучи, не відношення, а деякий впорядкований список кортежів.
4.2.3. Відсутність впорядкованості атрибутів
Атрибути відносин не впорядковані, оскільки по визначенню схема відношення є безліч пар {ім'я атрибута, ім'я домену}. Для посилання на значення атрибута в кортежі відношення завжди використовується ім'я атрибута. Ця властивість теоретично дозволяє, наприклад, модифікувати схеми існуючих відносин не тільки шляхом додання нових атрибутів, але і шляхом видалення існуючих атрибутів. Однак в більшості існуючих систем така можливість не допускається, і хоч впорядкованість набору атрибутів відношення явно не потрібно, часто як неявний порядок атрибутів використовується їх порядок в лінійній формі визначення схеми відношення.
4.2.4. Атомарність значень атрибутів
Значення всіх атрибутів є атомарними. Це виходить з визначення домену як потенційної безлічі значень простого типу даних, тобто серед значень домену не можуть міститися множини значень (відносини). Прийнято говорити, що в реляційних базах даних допускаються тільки нормалізовані відносини або відносини, представлені в першій нормальній формі. Потенційним прикладом ненормалізованого відношення є наступне:
Можна сказати, що тут ми маємо бінарне відношення, значеннями атрибута ВІДДІЛИ якого є відносини. Помітимо, що початкове відношення СПІВРОБІТНИКИ є нормалізованим варіантом відношення ВІДДІЛИ:
СОТР_НОМЕР | СОТР_ІМЯ | СОТР_ЗАРП | СОТР_ОТД_НОМЕР
2934 | Іванов | 112,000 | 310
2935 | Петров | 144,000 | 310
2936 | Сидоренко | 92,000 | 313
2937 | Федоров | 110,000 | 310
2938 | Іванова | 112,000 | 315
Нормалізовані відносини складають основу класичного реляційного підходу до організації баз даних. Вони володіють деякими обмеженнями (не будь-яку інформацію зручно представляти у вигляді плоских таблиць), але істотно спрощують маніпулювання даними. Розглянемо, наприклад, два ідентичних оператори занесення кортежу:
Зарахувати співробітника Кузнєцова (пропуск номер 3000, зарплата 115,000) у відділ номер 320 і
Зарахувати співробітника Кузнєцова (пропуск номер 3000, зарплата 115,000) у відділ номер 310.
Якщо інформація про співробітників представлена у вигляді відношення СПІВРОБІТНИКИ, обидва оператори будуть виконуватися однаково (вставити кортеж у відношення СПІВРОБІТНИКИ). Якщо ж працювати з ненормалізованим відношенням ВІДДІЛИ, то перший оператор виразиться в занесення кортежу, а другий - в додання інформації про Кузнєцова в множинне значення атрибута ВІДДІЛ кортежу з первинним ключем 310.
4.3. Реляційна модель даних
Коли в попередніх розділах ми говорили про основні поняття реляційних баз даних, ми не спиралися на яку-небудь конкретну реалізацію. Ці міркування в рівній мірі відносилися до будь-якої системи, при побудові якої використовувався реляційний підхід.
Іншими словами, ми використали поняття так званої реляційної моделі даних. Модель даних описує деякий набір родових понять і ознак, якими повинні володіти вся конкретна СУБД і керовані ними бази даних, якщо вони засновуються на цій моделі. Наявність моделі даних дозволяє порівнювати конкретні реалізації, використовуючи одну спільну мову.
Хоч поняття моделі даних є загальним, і можна говорити про ієрархічну, мережну, деяку семантичну і т.д. моделях даних, треба зазначити, що це поняття було введене в побут стосовно до реляційним систем і найбільш ефективно використовується саме в цьому контексті. Спроби прямолінійного застосування аналогічних моделей до дореляційних організацій показують, що реляційна модель дуже "велика" для них, а для післяреляційних організацій вона виявляється "мала".
4.3.1. Загальна характеристика
Найбільш поширене трактування реляційної моделі даних, мабуть, належить Дейту, який відтворює її (з різними уточненнями) практично у всіх своїх книгах. Згідно Дейту реляційна модель складається з трьох частин, що описують різні аспекти реляційного підходу: структурної частини, маніпуляційної частини і цілісної частини.
В структурній частині моделі фіксується, що єдиною структурою даних, що використовується в реляційних БД, є нормалізоване n-арне відношення. По суті справи, в попередніх двох розділах цієї лекції ми розглядали саме поняття і властивості структурної складової реляційної моделі.
В маніпуляційній частині моделі затверджуються два фундаментальних механізми маніпулювання реляційними БД - реляційна алгебра і реляційне числення. Перший механізм базується в основному на класичній теорії множин (з деякими уточненнями), а другий - на класичному логічному апараті числення предикатів першого порядку. Ми розглянемо ці механізми більш детально на наступній лекції, а поки лише помітимо, що основною функцією маніпуляційної частини реляційної моделі є забезпечення міри реляційності будь-якої конкретної мови реляційних БД: мова називається реляційним, якщо він володіє не меншою виразністю і потужністю, чим реляційна алгебра або реляційне числення.
4.3.2. Цілісність суті і посилань
Нарешті, в цілісній частині реляційної моделі даних фіксуються дві базових вимоги цілісності, які повинні підтримуватися в будь-якій реляційної СУБД. Перша вимога називається вимогою цілісності сутностей. Об'єкту або суті реального світу в реляційних БД відповідають кортежі відносин. Конкретно вимога полягає в тому, що будь-який кортеж будь-якого відношення відрізнимо від будь-якого іншого кортежу цього відношення, тобто іншими словами, будь-яке відношення повинно володіти первинним ключем. Як ми бачили в попередньому розділі, ця вимога автоматично задовольняється, якщо в системі не порушуються базові властивості відносин.
Друга вимога називається вимогою цілісності по посиланнях і є трохи більш складним. Очевидно, що при дотриманні нормалізованості відносин складні сутності реального світу представляються в реляційної БД у вигляді декількох кортежів декількох відносин. Наприклад, представимо, що нам потрібно представити в реляційної базі даних суть ВІДДІЛ з атрибутами ВІД_НОМЕР (номер відділу), ВІД_КІЛ (кількість співробітників) і ВІД_СПІВР (набір співробітників відділу). Для кожного співробітника треба зберігати СПІВР_НОМЕР (номер співробітника), СПІВР_ІМ'Я (ім'я співробітника) і СПІВР_ЗАРП (заробітна плата співробітника). Як ми незабаром побачимо, при правильному проектуванні відповідної БД в ній з'являться два відношення: ВІДДІЛИ (ВІД_НОМЕР, ВІД_КІЛ) (первинний ключ - ВІД_НОМЕР) і СПІВРОБІТНИКИ (СПІВР_НОМЕР, СПІВР_ІМ'Я, СПІВР_ЗАРП, СПІВР_ВІД_НОМ) (первинний ключ - СПІВР_НОМЕР).
Як видно, атрибут СПІВР_ВІД_НОМ з'являється у відношенні СПІВРОБІТНИКИ не тому, що номер відділу є власною властивістю співробітника, а лише для того, щоб мати можливість відновити при необхідності повну суть ВІДДІЛ. Значення атрибута СПІВР_ВІД_НОМ в будь-якому кортежі відношення СПІВРОБІТНИКИ повинно відповідати значенню атрибута ВІД_НОМ в деякому кортежі відношення ВІДДІЛИ. Атрибут такого роду називається зовнішнім ключем, оскільки його значення однозначно характеризують сутності, представлені кортежами деякого іншого відношення (тобто задають значення їх первинного ключа). Кажуть, що відношення, в якому визначений зовнішній ключ, посилається на відповідне відношення, в якому такий же атрибут є первинним ключем.
Вимога цілісності по посиланнях, або вимога зовнішнього ключа полягає в тому, що для кожного значення зовнішнього ключа, що з'являється у відношенні, що посилається, у відношенні, на яке веде посилання, повинен знайтися кортеж з таким же значенням первинного ключа, або значення зовнішнього ключа повинне бути невизначеним (тобто ні на що не вказувати). Для нашого прикладу це означає, що якщо для співробітника вказаний номер відділу, то цей відділ повинен існувати.
Обмеження цілісності суті і по посиланнях повинні підтримуватися СУБД. Для дотримання цілісності суті досить гарантувати відсутність відносно будь-якому кортежів з одним і тим же значенням первинного ключа. З цілісністю по посиланнях справи йдуть трохи більш складно.
Зрозуміло, що при оновленні відношення (вставці нових кортежів або модифікації значення зовнішнього ключа в існуючих кортежах), що посилається досить стежити за тим, щоб не з'являлися некоректні значення зовнішнього ключа. Але як бути при видаленні кортежу з відношення, на яке веде посилання?
Тут існують три підходи, кожний з яких підтримує цілісність по посиланнях. Перший підхід полягає в тому, що забороняється проводити видалення кортежу, на який існують посилання (тобто спочатку треба або видалити кортежі, що посилаються, або відповідним образом змінити значення їх зовнішнього ключа). При другому підході при видаленні кортежу, на який є посилання, у всіх кортежах, що посилаються значення зовнішнього ключа автоматично стає невизначеним. Нарешті, третій підхід (каскадне видалення) полягає в тому, що при видаленні кортежу з відношення, на яке веде посилання, з відношення, що посилається автоматично віддаляються кортежі, що все посилаються.
У розвиненій реляційних СУБД звичайно можна вибрати спосіб підтримки цілісності по посиланнях для кожної окремої ситуації визначення зовнішнього ключа. Звичайно, для прийняття такого рішення необхідно аналізувати вимоги конкретної прикладної області.

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать