Введення в реляційні бази даних

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

■&nbsp&nbsp&nbsp&nbsp Структурний аспект Дані в базі сприймаються користувачем, як таблиці

(І ніяк інакше)

■ Аспект цілісності Ці таблиці відповідають певним умовам цілісності

(Які розглядатимуться в кінці розділу)

■&nbsp&nbsp&nbsp&nbsp Аспект обробки У розпорядженні користувача є оператори манипулиро вання таблицями (наприклад, призначені для пошуку даних), які гені ріруют нові таблиці на підставі вже наявних і серед яких є, принаймні, оператори скорочення (restrict), проекції (project) і обєднання (join)

На рис 31 показаний простий приклад реляційної бази даних відділів (таблиця DEPT) і службовців (таблиця ОМР) Очевидно, що ця база даних дійсно сприймається як набір таблиць (Мабуть, сенс цих таблиць не вимагає пояснень) На рис 32 показані деякі приклади операцій скорочення, проекції і зєднання для цієї бази даних Нижче наведені (дуже несуворі) Визначення цих операцій

Рис 31 База даних відділів і службовців (наведені в ній дані часто використовуються як приклад)

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

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

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

З трьох прикладів, наведених на рис 32, в коментарях, мабуть, потребує тільки операція зєднання Насамперед, заслуговує на увагу те, що в таблицях DEPT і ОМР є спільний стовпець DEPT #, а отже, для цих таблиць можна виконати операцію зєднання на основі загальних значень в цьому стовпці При виконанні даної операції рядок таблиці DEPT зєднується з рядком таблиці ОМР і утворюється більш довга рядок, але подібне відбувається тоді й тільки тоді, коли ці дві

рядки мають однакове значення поля DEPT # Наприклад, можна зєднати в результуючу рядок (табл 31) такі рядки таблиць DEPT і ОМР (назви стовпців наведені для наочності) Це можливо, так як в загальному стовпці розглянутих рядків є одне і те ж значення D1 Строка результату приведена в табл 32 Загальний результат складається з безлічі всіх таких зєднаних рядків Зверніть увагу, що стовпець DEPT # в кожній результуючої рядку зустрічається один раз, а не два Слід також зазначити, що в полі DEPT # таблиці ОМР відсутня значення D3 (тобто немає службовців, які працюють в відділі D3), тому в даному полі немає і результуючих рядків із значенням D3, хоча рядок зі значенням D3 в таблиці DEPT присутня

Рис 32 Приклади застосування операцій скорочення, проекції і зєднання

Таблиця 31 Рядки таблиць ОМР і DEPT перед зєднанням

Таблиця 32 Результат зєднання

Необхідно відзначити одну важливу особливість, очевидну з рис 32: результат виконання кожної з трьох представлених операцій це ще одна таблиця (Іншими словами, ці оператори фактично породжують таблиці з таблиць, що і було зазначено раніше) Це-приклад прояву реляційного властивості замкнутості Воно має дуже велике значення, головним чином тому, що результатом виконання операції є обєкт того ж роду, що й обєкт, над яким проводилася операція, а саме – таблиця Але це значить, що до результатами операцій можна знову застосувати

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

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

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

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

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

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

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

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

У даному випадку термін логічна структура в термінології ANSI / SPARC відноситься як до концептуального, так і до зовнішнього рівням Справа в тому, що (як описано в розділі 2) і концептуальний, і зовнішній рівні в реляційної системі є однаково реляційними, і лише внутрішній або фізичний рівень не є таким Насправді реляційна теорія взагалі не може визначити внутрішній рівень Вона, як уже зазначалося, визначає лише те, як база даних представленапользователю2Повторюємо, що єдина вимога полягає в наступному: яка б фізична структура не була обрана, вона повинна повністю реалізовувати існуючу логічну структуру

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

ня бази даних представлено одним і тільки одним способом, а саме явним за данием значень, поміщених в позиції стовпців у рядках таблиці Цей метод подання – єдино можливий для реляційних баз даних (естест венно, на логічному рівні) Зокрема, немає ніяких покажчиків, звязують одну таблицю з іншого Наприклад, на рис 31 існує певний звязок між ду рядком D1 в таблиці DEPT і рядком Е1 в таблиці ОМР, яка вказує, що слу жащій з номером Е1 працює у відділі з номером D1, але ця інформація пред ставлена ​​не за допомогою покажчика, а за допомогою значення D1 в стовпці DEPT # рядки Е1 таблиці ОМР У нереляційних системах (наприклад в IMS і 1DMS), навпаки, така інформація зазвичай позначається якимсь покажчиком, який явно видно користувачеві (про що йшла мова в розділі 1)

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

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

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

бази даних потрібно було б визначити кілька обмежень підтримки цілісності бази Наприклад, припустимо, що зарплата службовців не повинна виходити за межі від 25 до 95 тис дол на рік, а бюджет відділу повинен знаходитися в межах від 1 до 15 млн дол і тд Деякі з таких правил мають настільки важливе практичне значення, що отримали спеціальні назви Розглянемо їх більш докладно

1 Кожен рядок у таблиці DEPT повинна включати унікальне значення стовпця DEPT # аналогічно, кожен рядок в таблиці ОМР повинна включати унікальне значення стовпця ОМР # Кажуть, що стовпці DEPT # У таблиці DEPT І ОМР # В таб особі ОМР є первинними ключами для своїх таблиць (Нагадаємо, що у главі 1 ми умовилися відзначати стовпці первинних ключів подвійним підкресленням)

2 Кожне значення стовпця DEPT # в таблиці ОМР ПОВИННО бути представлене і у вигляді значення стовпця DEPT # в таблиці DEPT відповідно з тим фактом, що кожен службовець повинен бути приписаний до існуючого відділу Кажуть, що стовпець DEPT # в таблиці ОМР є зовнішнім ключем, посилаються на первинний ключ таблиці DEPT

Більш формальне визначення

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

1 Необмежений набір скалярних типів (Включаючи, зокрема, логічний тип

або істиннісне значення)

2 Генератор типів відносин і відповідна інтерпретація для згенерований них типів відносин

3 Можливість визначення змінних відносини для зазначених згенерованих типів відносин

4 Операція реляційного присвоювання для присвоювання реляційних значень зазначеним змінним відносини

5 Необмежений набір загальних реляційних операторів {Реляційна алгебра) для отримання значень відносин з інших значень відносин

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

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

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*