Загальні поняття реляційного підходу до організації БД. Основні концепції та терміни Семантичні моделі даних

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

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

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

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

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

Далі ми коротко розглянемо деякі риси однієї з найбільш популярних семантичних моделей даних - модель "Сутність-Зв'язок" (часто її називають коротко ER-моделлю).

На використанні різновидів ER-моделі засновано більшість сучасних підходів до проектування баз даних (головним чином, реляційних). Модель була запропонована Ченом (Chen) в 1976 р. Моделювання предметної області базується на використанні графічних діаграм, що включають невелику кількість різнорідних компонентів. У зв'язку з наочністю подання концептуальних схем баз даних ER-моделі одержали широке поширення в системах CASE, підтримують автоматизоване проектування реляційних баз даних. Серед безлічі різновидів ER-моделей одна з найбільш розвинених застосовується в системі CASE фірми ORACLE. Її ми і розглянемо. Більш точно, ми зосередимося на структурній частині цієї моделі.

Основними поняттями ER-моделі є сутність, зв'язок і атрибут.

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

Нижче зображено сутність АЕРОПОРТ з зразковими об'єктами Шереметьєво і Хітроу:

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

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

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

Реляційна база даних - це набір відносин, імена яких збігаються з іменами схем відносин в схемі БД.

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

Зупинимося тепер на деяких важливих властивості відносин, які випливають з наведених раніше визначень: 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.1. Загальна характеристика

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

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

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

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

Друга вимога називається вимогою цілісності за посиланнями і є трохи більш складним. Очевидно, що при дотриманні нормалізованності відносин складні сутності реального світу представляються в реляційної БД в вигляді декількох кортежів декількох відносин. Наприклад, уявімо, що нам потрібно представити в реляційної бази даних сутність ВІДДІЛ з атрибутами ОТД_НОМЕР (номер відділу), ОТД_КОЛ (кількість працівників) і ОТД_СОТР (набір співробітників відділу). Для кожного співробітника потрібно зберігати СОТР_НОМЕР (номер співробітника), СОТР_ІМЯ (ім'я співробітника) і СОТР_ЗАРП (заробітна плата працівника). Як ми незабаром побачимо, при правильному проектуванні відповідної БД в ній з'являться два відносини: ВІДДІЛИ (ОТД_НОМЕР, ОТД_КОЛ) (первинний ключ - ОТД_НОМЕР) і СПІВРОБІТНИКИ (СОТР_НОМЕР, СОТР_ІМЯ, СОТР_ЗАРП, СОТР_ОТД_НОМ) (первинний ключ - СОТР_НОМЕР).

Як видно, атрибут СОТР_ОТД_НОМ з'являється відносно СПІВРОБІТНИКИ не тому, що номер відділу є власним властивістю співробітника, а лише для того, щоб мати можливість відновити за необхідності повну сутність ВІДДІЛ. Значення атрибуту СОТР_ОТД_НОМ в будь-якому кортежі відносини СПІВРОБІТНИКИ повинно відповідати значенню атрибута ОТД_НОМ в деякому кортежі відносини ВІДДІЛИ. Атрибут такого роду називається зовнішнім ключем, оскільки його значення однозначно характеризують суті, представлені кортежами деякого іншого відносини (тобто описують їх первинного ключа). Кажуть, що ставлення, в якому визначено зовнішній ключ, посилається на відповідне відношення, в якому такий же атрибут є первинним ключем.

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

Обмеження цілісності суті і за посиланнями повинні підтримуватися СУБД. Для дотримання цілісності суті досить гарантувати відсутність в будь-якому відношенні кортежів з одним і тим же значенням первинного ключа. З цілісністю по посиланнях усе трохи складніше.

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

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

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