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