Теоретичні основи
Теоретичні основи
Ми приступаємо до вивчення реляційних баз даних і систем управління реляційними базами даних. Цей підхід є найбільш поширеним в цей час, хоч нарівні із загальновизнаними достоїнствами володіє і рядом недоліків. До числа достоїнств реляційного підходу можна віднести:
наявність невеликого набору абстракцій, які дозволяють порівняно просто моделювати велику частину поширених предметних областей і допускають точні формальні визначення, залишаючись інтуїтивно зрозумілими;
наявність простою і в той же час могутнього математичного апарату, що спирається головним чином на теорію множин і математичну логіку і забезпечуючий теоретичний базис реляційного підходу до організації баз даних;
можливість ненавігаційного маніпулювання даними без необхідності знання конкретної фізичної організації баз даних у зовнішній пам'яті.
Реляційні системи далеко не відразу набули широкого поширення. У той час, як основні теоретичні результати в цій області були отримані ще в 70-х, і тоді ж з'явилися перші прототипи реляційних СУБД, довгий час вважався неможливим добитися ефективної реалізації таких систем. Однак відмічені вище переваги і поступове накопичення методів і алгоритмів організації реляційних баз даних і управління ними привели до того, що вже в середині 80-х років реляційні системи практично витіснили з світового ринку ранню СУБД.
У цей час основним предметом критики реляційних СУБД є не їх недостатня ефективність, а властива цим системам деяка обмеженість (пряме слідство простоти) при використання в так званих нетрадиційних областях (найбільш поширеними прикладами є системи автоматизації проектування), в яких потрібні гранично складні структури даних. Ще одним що часто відмічається недоліком реляційних баз даних є неможливість адекватного відображення семантики предметної області. Іншими словами, можливості уявлення знань про семантичну специфіку предметної області в реляційних системах дуже обмежені. Сучасні дослідження в області післяреляційних систем головним чином присвячені саме усуненню цих недоліків.
Лекція 4. Загальні поняття реляційного підходу до організації БД. Основні концепції і терміни
На цій лекції ми введемо на порівняно неформальному рівні основні поняття реляційних баз даних, а також визначимо істоту реляційної моделі даних. Основною метою лекції є демонстрація простоти і можливості інтуїтивної інтерпретації цих понять. У подальших лекціях будуть приводитися більш формальні визначення, на яких засновується математична теорія реляційних баз даних.
4.1. Базові поняття реляційних баз даних
Основними поняттями реляційних баз даних є тип даних, домен, атрибут, кортеж, первинний ключ і відношення.
Для початку покажемо значення цих понять на прикладі відношення СПІВРОБІТНИКИ, що містить інформацію про співробітників деякої організації:
4.1.1. Тип даних
Поняття тип даних в реляційної моделі даних повністю адекватно поняттю типу даних в мовах програмування. Звичайно в сучасної реляційних БД допускається зберігання символьних, числових даних, бітових рядків, спеціалізованих числових даних (таких як "гроші"), а також спеціальних "темпоральних" даних (дата, час, тимчасової інтервал). Досить активно розвивається підхід до розширення можливостей реляційних систем абстрактними типами даних (відповідними можливостями володіють, наприклад, системи сімейства Ingres/Postgres). У нашому прикладі ми маємо справу з даними трьох типів: рядки символів, цілі числа і "гроші".
4.1.2. Домен
Поняття домену більш специфічне для баз даних, хоч і має деякі аналогії з підтипами в деяких мовах програмування. У самому загальному вигляді домен визначається завданням деякого базового типу даних, до якого відносяться елементи домен, і довільного логічного вираження, що застосовується до елемента типу даних. Якщо обчислення цього логічного вираження дає результат "істина", то елемент даних є елементом домену.
Найбільш правильним інтуїтивним трактуванням поняття домену є розуміння домену як допустимої потенційної безлічі значень даного типу. Наприклад, домен "Імена" в нашому прикладі визначений на базовому типі рядків символів, але в число його значень можуть входити тільки ті рядки, які можуть зображати ім'я (зокрема, такі рядки не можуть починатися з м'якого знаку).
Потрібно відмітити також семантичне навантаження поняття домену: дані вважаються порівнянними тільки в тому випадку, коли вони відносяться до одного домену. У нашому прикладі значення доменів "Номера пропусків" і "Номера груп" відносяться до типу цілих чисел, але не є порівнянними. Помітимо, що в більшості реляційних СУБД поняття домену не використовується, хоч в Oracle V.7 воно вже підтримується.
4.1.3. Схема відношення, схема бази даних
Схема відношення - це іменована безліч пар {ім'я атрибута, ім'я домену (або типу, якщо поняття домену не підтримується)}. Ступінь або "арність" схеми відношення - потужність цієї безлічі. Ступінь відношення СПІВРОБІТНИКИ рівна чотирьом, тобто воно є 4-арным. Якщо всі атрибути одного відношення визначені на різних доменах, осмислено використати для іменування атрибутів імена відповідних доменів (не забуваючи, звичайно, про те, що це є усього лише зручним способом іменування і не усуває відмінності між поняттями домену і атрибута).
Схема БД (в структурному значенні) - це набір іменованих схем відносин.
4.1.4. Кортеж, відношення
Кортеж, відповідний даній схемі відношення, - це безліч пар {ім'я атрибута, значення}, яке містить одне входження кожного імені атрибута, що належить схемі відношення. "Значення" є допустимим значенням домену даного атрибута (або типу даних, якщо поняття домену не підтримується). Тим самим, ступінь або "арність" кортежу, тобто число елементів в ньому, співпадає з "арністю" відповідної схеми відношення. Просто кажучи, кортеж - це набір іменованих значень заданого типу.
Відношення - це безліч кортежів, відповідних одній схемі відношення. Іноді, щоб не плутатися, кажуть "відношення-схема" і "відношення-примірник", іноді схему відношення називають заголовком відношення, а відношення як набір кортежів - тілом відношення. Насправді, поняття схеми відношення ближче усього до поняття структурного типу даних в мовах програмування. Було б цілком логічно дозволяти