Лекція 4 Основи реляційного підходу до організації БД. Основи реляційної моделі даних – 4 год Основні переваги та недоліки реляційного підходу Базові поняття реляційного моделювання даних Тип даних Домен Відношення Фундаментальні властивості відношень Бінарні відношення та їх властивості Способи задання відношень N-арні відношення (відношення степеня n) Транзитивне замикання відношень Відношення у реляційних БД Відношення, кортежі та атрибути Схема відношення, схема БД Структура відношення Основні (фундаментальні) властивості відношень у реляційних БД Відсутність кортежів-дублікатів Відсутність впорядкованості кортежів Відсутність впорядкованості атрибутів Атомарність значень атрибутів Реляційна модель (організація бази) даних Реляційна модель та БД. Загальна характеристика Перша нормальна форма Цілісність сутностей та посилань Основні переваги та недоліки реляційного підходу Цей підхід є найбільш розповсюдженим у даний час, хоча поряд із загальновизнаними перевагами має і багато недоліків. До переваг реляційного підходу можна віднести: наявність невеликого набору абстракцій, що дозволяють порівняно просто моделювати велику частину розповсюджених предметних областей і допускають точні формальні визначення, залишаючись інтуїтивно зрозумілими; наявність простого й у той же час могутнього математичного апарату, що спирається головним чином на теорію множин і математичну логіку та забезпечує теоретичний базис реляційного підходу до організації баз даних; можливість ненавігаційного маніпулювання даними без необхідності знання конкретної фізичної організації баз даних у зовнішній пам'яті. В даний час основним предметом критики реляційних СУБД є не їхня недостатня ефективність, а властива їм деяка обмеженість (прямий наслідок простоти) при використання в галузях, у яких вимагаються гранично складні структури даних (наприклад, САПР). Ще одним часто відмічуваним недоліком реляційних баз даних є неможливість адекватного відображення семантики предметної області. Іншими словами, можливості представлення знань про семантичну специфіку предметної області в реляційних системах дуже обмежені. Сучасні дослідження в області постреляційних систем головним чином присвячені саме усуненню цих недоліків. Загальна характеристика реляційної моделі даних Наприкінці 60-х років з'явилися роботи, у яких обговорювалися можливості застосування різних табличних логічних моделей даних, тобто можливості використання звичних і природних способів представлення даних. Найбільш значною з них була стаття співробітника фірми IBM д-ра Е.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13:6, June 1970), де, імовірно, уперше був застосований термін "реляційна модель даних". Е.Кодд запропонував використовувати для обробки даних апарат теорії множин (об'єднання, перетинання, різниця, декартів добуток). Він показав, що будь-яке представлення даних зводиться до сукупності двовимірних таблиць особливого виду, відомого в математику як відношення – relation (англ.) Робота Е.Кодда послужила стимулом для великої кількості статей і книг, у яких реляційна модель отримала подальший розвиток. Найбільш розповсюджене трактування реляційной моделі даних належить К.Дейту. Згідно Дейту, реляційна модель складається з трьох частин: Структурної частини. Цілісної частини. Маніпуляціної частини. Структурна частина описує, які об'єкти розглядаються реляційною моделлю. Постулюється, що єдиною структурою даних, використовуваною в реляційній моделі, є нормалізовані n-арні відносини. Цілісна частина описує обмеження спеціального виду, що повинні виконуватися для будь-яких відносин у будь-яких реляційних базах даних. Це цілісність сутностей і цілісність зовнішніх ключів (посилань). Маніпуляційна частина описує два еквівалентних способи маніпулювання реляційними даними - реляційну алгебру і реляційне числення. Базові поняття реляційного моделювання даних Основними поняттями реляційних баз даних є тип даних, домен, атрибут, кортеж, первинний ключ і відношення. Тип даних Поняття тип даних у реляційній моделі даних цілком адекватно поняттю типу даних у мовах програмування. Будь-які дані, використовувані в програмуванні, мають свої типи даних. Детально типи даних розглядалися нами в першій лекції. Реляційна модель вимагає, щоб типи використовуваних даних були простими. Нагадаємо, що прості, чи атомарні, типи даних не мають внутрішньої структури. Дані такого типу називають скалярами. До простих типів даних відносяться наступні типи: Логічний. Рядковий. Чисельний. Власне, для реляційної моделі даних тип використовуваних даних не важливий. Вимогу того, щоб тип даних був простим, потрібно розуміти так, що в реляційних операціях не повинна враховуватися внутрішня структура даних. Звичайно, повинні бути описані дії, які можна робити з даними як з єдиним цілим, наприклад, дані числового типу можна складати, для рядків можлива операція конкатенації і т.д. Звичайно в сучасних реляційних БД допускається збереження символьних, числових даних, бітових рядків, спеціалізованих числових даних (таких як "гроші"), а також спеціальних "темпоральних" даних (дата, час, часовий інтервал). Досить активно розвивається підхід до розширення можливостей реляційних систем абстрактними типами даних (відповідні можливості мають, наприклад, системи сімейства Ingres/Postgres). Домен У реляційній моделі даних з поняттям "тип даних" тісно пов'язане поняття домену, яке можна вважати уточненням типу даних. Домен - це семантичне поняття. Домен можна розглядати як підмножину значень деякого типу даних, що мають певний зміст. У самому загальному виді домен визначається завданням деякого базового типу даних, до якого відносяться елементи домену, і довільного логічного виразу, застосовуваного до елемента типу даних. Якщо обчислення цього логічного виразу дає результат "істина", то елемент даних є елементом домену. Найбільш правильним інтуїтивним трактуванням поняття домену є розуміння домену як допустимої потенційної множини значень даного типу. Наприклад, домен "Імена" у сутності СПІВРОБІТНИКИ визначений на базовому типі рядків символів, але в число його значень можуть входити тільки ті рядки, що можуть зображувати ім'я (зокрема, такі рядки не можуть починатися з м'якого знака). Найменша одиниця даних реляційної моделі – це окреме атомарне (нерозкладне) для даної моделі значення даних. Так, в одній предметній галузі прізвище, ім'я і по батькові можуть розглядатися як єдине значення, а в іншій – як три різних значення. Доменом називається множина атомарних значень того самого типу. Так, у схемі БД «Аеропорт» домен пунктів відправлення (призначення) – множина назв населених пунктів, а домен номерів рейсу – множина цілих додатних чисел. Домен характеризується наступними властивостями: Домен має унікальне ім'я (у межах бази даних). Домен визначений на деякому простому типі даних чи на іншому домені. Домен може мати деяку логічну умову, що дозволяє описати підмножину даних, допустимих для даного домену. Домен несе певне значеннєве навантаження. Наприклад, домен D, що має зміст "вік співробітника" можна описати як наступну підмножину множини натуральних чисел:
Якщо тип даних можна вважати множиною всіх можливих значень даного типу, то домен нагадує підмножину в цій множині. Відмінність домену від поняття підмножини полягає саме в тому, що домен відбиває семантику, визначену предметною галуззю. Можуть бути домени, що збігаються як підмножини, але несуть різний зміст. Наприклад, домени "Вага деталі" і "Наявна кількість" можна однакова описати як множину ненегативних цілих чисел, але зміст цих доменів буде різним, і це будуть різні домени. В більшості реляційних СУБД понять домену не використовується, хоча в Oracle V.7 воно вже підтримується. Зміст доменів полягає в наступному. Якщо значення двох атрибутів беруться з того самого домену, то, імовірно, мають сенс порівняння, що використовують ці два атрибути (наприклад, для організації транзитного рейсу можна дати запит "Видати рейси, у яких час вильоту з Москви в Сочі більше часу прибуття з Архангельська в Москву"). Якщо ж значення двох атрибутів беруться з різних доменів, то їхнє порівняння, скоріш за все, позбавлено змісту: чи варто порівнювати номер рейса з вартістю квитка? Таким чином, основне значення доменів полягає в тому, що домени обмежують порівняння. Некоректно, з логічної точки зору, порівнювати значення з різних доменів, навіть якщо вони мають однаковий тип. У цьому виявляється значеннєве обмеження доменів. Синтаксично правильний запит "видати список усіх деталей, у яких вага деталі більше наявної кількості" не відповідає змісту понять "кількість" і "вага". Поняття домену допомагає правильно моделювати предметну галузь. При роботі з реальною системою в принципі можлива ситуація коли потрібно відповісти на запит, наведений вище. Система дасть відповідь, але, імовірно, вона буде безглуздою. Тобто поняття домену несе семантичне навантаження: дані вважаються порівнянними тільки в тому випадку, коли вони відносяться до одного домену. У нашому прикладі значення доменів "Номера пропусків" і "Номера груп" відносяться до типу цілих чисел, але не є порівнянними. Не всі домени мають логічну умову, що обмежує можливі значення домену. У такому випадку множина можливих значень домену збігається з множиною можливих значень типу даних. Не завжди також очевидно, як задати логічну умову, що обмежує можливі значення домену. Наприклад, якою є умова на строковий тип даних, що задає домен "Прізвище співробітника". Ясно, що рядки, що є прізвищами, не повинні починатися з цифр, службових символів, з м'якого знака і т.д. Але от чи є припустимим прізвище "Ггггггииииии"? Труднощ такого роду виникають тому, що зміст реальних явищ далеко не завжди можна формально описати. Люди інтуїтивно розуміють, що таке прізвище, але ніхто не може дати таке формальне визначення, що відрізняло б прізвища від рядків,які прізвищами не є. Вихід з цієї ситуації простий - покластися на розум співробітника, що вводить прізвища в комп'ютер. Відношення Відношення- це підмножина декартового добутку множин. Множина - це невизначуване поняття, що представляє деяку сукупність даних. Множина не має внутрішньої структури. Множину можна уявити собі як сукупність елементів, що мають деяку спільну властивість. Для того щоб деяку сукупність елементів можна було назвати множиною, необхідно, щоб виконувалися наступні умови: Повинне існувати правило, що дозволяє визначити, чи належить зазначений елемент до даної сукупності. Повинне існувати правило, що дозволяє відрізняти елементи друг від друга. (Це, зокрема, означає, що множина не може містити двох однакових елементів). Множини звичайно позначаються заголовними латинськими літерами. Якщо елемент х належить множині А, то це позначається: . Якщо кожний елемент множини В є також і елементом множини А, то говорять, що множина В є підмножиною множини А: . Підмножина множини називається власною підмножиною, якщо В ( А. Над множинами можна виконувати операції об'єднання, перетинання, різниці і доповнення. Одним зі способів подудови нових множин є використвння як основи поняття декартового добутку. Декартовим (прямим) добутком множин A1,A2,…An називається множина упорядкованих наборів елементів (аi1,aj2,…amn) вигляду: ,. з яким перший належить множині A1, другий – множині A2, п-ий – множині A2. Для цих упорядкованих сукупностей елементів уживається назва: кортежі, послідовності, n-ки, набори. Порядок проходження наборів може бути будь-яким, але розташування елементів у кожній парі визначається порядком проходження множин, що перемножуються. Тому А ( В ( В ( А, якщо В ( А. Іншими словами, декартів добуток декількох множин - це множина кортежів, побудована з елементів цих множин. Якщо всі множини Аi однакові, то використовують позначення
Степенем декартового добутку A1*A2*…An називається кількість множин n, що входять у це декартів добуток. Підмножина R декартового добутку множин A1*A2*…An називається відношенням степеня n (n-арним відношенням). Відношення складаються з однотипних кортежів. За винятком крайнього випадку, коли відношенням є сам декартів добуток, відношення містить у собі не всі можливі кортежі з декартового добутку. Це означає, що для кожного відношення є критерій, що дозволяє визначити, які кортежі входять у відношення, а які - ні. Цей критерій, власне кажучи, визначає для нас зміст (семантику) відношення. Дійсно, кожному відношенню можна поставити у відповідність деякий логічний вираз, залежний від n параметрів (n-місний предикат), якмй визначає, чи буде кортеж належати відношенню R. Цей логічний вираз називають предикатом відношення R. Точніше, кортеж належить відношенню R тоді і тільки тоді, коли предикат цього відношення приймає значення "істина". У свою чергу, кожен n-місний предикат задає деяке n-арне відношення. Таким чином, існує взаємно однозначна відповідність між n-арними відношеннями і n-місними предикатами. Кожне відношення має предикат відношення і кожен n-місний предикат задає n-арне відношення. Якщо це не викликає плутанини, зручно і відношення, і його предикат позначати однієї і тією же літерою. Наприклад, відношення R має предикат . Відношення мають степень і потужністю. Степень відношення - це кількість елементів у кожнім кортежі відношення (аналог кількості стовпців у таблиці). Потужність відношення - це потужність множини кортежів відношення (аналог кількості рядків у таблиці). Потужність множини кортежів, що входять у відношення R , називають потужністю відношення R. Поняття відношення є дуже важливим не тільки з математичної точки зору. Поняття відношення фактично лежить в основі всієї реляційной теорії баз даних. Відношення є математичним аналогом таблиць. Сам термін "реляційне представлення даних", уперше введений Коддом, походить від терміна relation, що перекладається "відношення, відносини". Всі елементи відношення - однотипні кортежі. Однотипність кортежів дозволяє вважати їх аналогами рядків у простій таблиці, тобто в такій таблиці, у якій усі рядки складаються з однакового числа комірок і у відповідних комірках містяться однакові типи даних. Наприклад, відношення, що складається з трьох наступних кортежів {(1, "Іванов", 1000), (2, "Петров", 2000), (3, "Сидоров", 3000)} можна вважати таблицею, що містить дані про співробітників і їхні зарплати. Така таблиця буде мати три рядки і три стовпчики, причому в кожнім стовпчику містяться дані одного типу. На противагу цьому розглянемо множину {(1), (1, 2), (1, 2, 3)}, що складається з різнотипних числових кортежів. Це множина не є відношенням ні в R, ні в R2, ні в R3. З кортежів, що входять у цю множину не можна скласти просту таблицю. У математиці найбільшу роль відіграють бінарні відносини, тобто відношення, задані на декартовому добутку двох множин A1x2 (відношення степеня 2). У теорії баз даних основними є відношення степеня п.. У математиці, як правило, відношення задані на нескінченних множинах і мають нескінченну потужність. У базах даних навпроти, потужності відношень кінцеве (число збережених рядків у таблицях завжди звичайно). Фундаментальні властивості відношень Бінарні відношення та їх властивості У математиці значну роль відіграють бінарні відношення (відношення степеня 2), тобто. відношення, задані на декартовому добутку двох множин . Фундаментальними властивостями бінарних відношень є рефлексивність, транзитивність і симетричність. Відношення еквівалентності Визначення. Відношення R на множині A2 називається відношенням еквівалентності, якщо воно має наступні властивості: для усіх (рефлексивність) ; якщо , то (симетричність); якщо и , то (транзитивність). Звичайне відношення еквівалентності позначають знаком = чи ( і говорять, що воно (відношення) задано на множині А, а не А2. Умови 1-3 у таких позначеннях виглядають більш природно: х ( х для усіх (рефлексивність) ; якщо х ( у, то в ( х (симетричність); якщо х ( у та у ( z, то х ( z (транзитивність). Легко доводиться, що якщо на множині А задане відношення еквівалентності, то множина А розбивається на взаємно непересічні підмножини, що складаються з еквівалентних один одному елементів (класи еквівалентності). Приклад. Розглянемо на множині речовинних чисел R відношення, задане просто рівністю чисел. Предикат такого відношення: Умови 1-3 напевно виконуються, тому дане відношення є відношенням еквівалентності. Кожен клас еквівалентності цього відношення складається з одного числа. Відношення порядку Визначення. Відношення R на множині A2 називається відношенням порядку, якщо воно має наступні властивості: для усіх (рефлексивність) ; якщо та , то (антисиметричність) ; якщо та , то (транзитивність). Звичайне відношення порядку позначають знаком (. Якщо для двох елементів х та у виконується х ( у те говорять, що х "передує" у. Як і для відношення еквівалентності, умови 1-3 у таких позначеннях виглядають більш природно: х ( х для всех (рефлексивність) ; якщо х ( у і у ( х , то х = у (антисиметричність) ; якщо х ( у та у ( z, то х( ( z (транзитивність). Приклад . Розглянемо на множині А всіх співробітниках деякого підприємства відношення, що задається в такий спосіб: співробітник передує співробітнику тоді і тільки тоді, коли виконується одна з умов: х=у х є начальником (не обов'язково безпосереднім) у. Назвемо таке відношення "бути начальником". Легко перевірити, що відношення "бути начальником" є відношенням порядку. Помітимо, що існують такі пари співробітників х и у, для яких не виконується ні х ( у, ні у ( х (наприклад, якщо вони є просто колегами ). Такі відношення, у яких є непорівнянні між собою елементи, називають відношеннями часткового порядку Функціональне відношення Визначення. Відношення R на декартовому добутку двох множин А1(А2 називається функціональним відношенням, якщо воно має наступну властивість: якщо і , то (однозначність функції). Звичайно, функціональне відношення позначають у вигляді функціональної залежності тоді і тільки тоді, коли . Функціональні відношення (підмножини декартового добутку!) називають інакше графіком функції чи графіком функціональної залежності. Предикат функціонального відношення є простий вираз функціональної залежності . 1.4.2. Способы задания відношень Нехай множина А є наступною множиною молодих людей: {Вовочка, Перо, Маша, Лєна}, причому відомі наступні факти: Вовочка любить Вовочку (егоїст). Петро любить Машу (взаємно). Маша любить Петра (взаємно). Маша любить Машу (себе не забуває). Лєна любить Петра (нещаслива любов). Інформацію про взаимовідносини цих молодих людей можна описати бінарним відношенням "любити", заданому на множині А2. Це відношення можна описати кількома способами. Спосіб 1. Перерахування фактів у вигляді довільного тексту (як це зроблено вище). Спосіб 2. У вигляді графа взаимовідносин:
Спосіб 3. За допомогою матриці взаимовідносин: Кого Хто Вовочка Петро Маша Лєна
Вовочка Любить
Петро
Любить
Маша
Любить Любить
Лєна
Любить
Таблиця 1. Матриця взаимовідносин Спосіб 4. За допомогою таблиці фактів: Хто любить Кого люблять
Вовочка Вовочка
Петро Маша
Маша Петро
Маша Маша
Лєна Петро
Таблиця 2 Таблиця фактів З погляду реляційних баз даних найкращим є четвертий спосіб, тому що він допускає найбільш зручний спосіб збереження і маніпулювання інформацією. Дійсно, перерахування фактів як текстова форма збереження інформації доречна для літературного твору, але складно піддається алгоритмічній обробці. Зображення у вигляді графа наочно, і його зручно використовувати як кінцеву форму представлення інформації для користувача, але зберігати дані в графічному вигляді незручно. Матриця взаимовідношень уже більше відповідає вимогам інформаційної системи. Матриця зручна в обробці і компактно зберігається. Але одна невелика зміна, наприклад, з'явився ще Вася і закохався в нещасливу Лену, вимагає перебудови всієї матриці, а саме, додавання і колонок, і стовпців. Таблиця фактів вільна від усіх цих недоліків - при додаванні нових дійових осіб просто додаються нові рядки. Що стосується предиката даного відношення, те він має наступний вигляд (диз'юнктивна нормальна форма): R(x,y) = {(x = "Вовочка" AND y = "Вовочка") OR (x = "Петро" AND y = "Маша") OR (x = "Маша" AND y = "Петро") OR (x = "Маша" AND y = "Маша") OR (x = "Лєна" AND y = "Петро")} Наведене відношення не є ані транзитивним, ані симетричним чи антисиметричної, ані рефлексивним, тому воно не є ні відношенням еквівалентності, ні відношенням порядку, ні яким-небудь іншим розумним відношенням. 1.4.3. N-арні відношення (відношення степеню n) У математиці n-арні відношення розглядаються відносно рідко, на відміну від баз даних, де найбільш важливими є саме відношення, задані на декартовому добутку більш ніж двох множин. Приклад. У деякому університеті на математичному факультеті вчаться студенти Іванов, Петров і Сидорчук. Лекції їм читають викладачі Пушняк, Цапанюк і Шарипов, причому відомі наступні факти: Пушняк читає лекції з алгебри і баз даних, відповідно, 40 і 80 годин у семестр. Цапанюк читає лекції з геометрії, 50 годин у семестр. Шарипов читає лекції з алгебри і геометрії, відповідно, 40 і 50 годин у семестр. Студент Іванов відвідує лекції з алгебри у Шарипова і з баз даних у Пушняка. Студент Петров відвідує лекції з алгебри у Пушняка і з геометрії в Цапанюка. Студент Сидорчук відвідує лекції з геометрії в Цапанюка і з баз даних у Пушняка. Для того, щоб формально описати дану ситуацію (наприклад, з метою розробки інформаційної системи, що враховує дані про хід навчального процесу), уведемо три множини: множина викладачів А = {Пушняк, Цапанюк, Шарипов}. множина предметів В = {Алгебра, Геометрія, Бази даних}. множина студентів С = {Іванов, Петров, Сидорчук}. Наявні факти можна розділити на дві групи: 1 група (факти 1-3) - факти про викладачів, 2 група (факти 4-6) - факти про студентів. Для того щоб відбити факти 1-3 (що характеризують викладачів і лекції, що читаються ними,), уведемо відношення R1 на декартовому добутку A(B(Q, де Q - множина раціональних чисел. А саме, упорядкована трійка існуватиме тоді і тільки тоді, коли викладач х читає лекції з предмету у в кількості п годин у семестр. Назвемо таке відношення "Читає лекції по…"... Множину кортежів, що утворять відношення R1, зручно представити у вигляді таблиці: A (Викладач) B (Предмет) Q (Кількість годин)
Пушняк Алгебра 40
Пушняк Бази даних 80
Цапанюк Геометрія 50
Шарипов Алгебра 40
Шарипов Геометрия 50
Таблиця 3 Відношення "Читає лекції з..." Для того, щоб відбити факти 4-6 (що характеризують відвідування студентами лекцій), уведемо відношення R2 на декартовому добутку С(A(B. Упорядкована трійка існує тоді і тільки тоді, коли студент z відвідує лекції з предмету у у викладача х. Назвемо це відношення "Відвідувати лекції". Його також представимо у вигляді таблиці: C (студент) B (предмет) A (Викладач)
Іванов Алгебра Шарипов
Іванов Бази даних Пушняк
Петров Алгебра Пушняк
Петров Геометрія Цапанюк
Сидорчук Геометрія Цапанюк
Сидорчук Бази даних Пушняк
Таблиця 4 Відношення "Відвідувати лекції" Розглянемо відношення R2 докладніше. Воно задане на декартовому добутку Q=С(A(B. Цей добуток, що містить 3(3(3=27 кортежів, можна назвати "Студенти-Лекції-Викладачі". Множина R1 являє собою сукупність усіх можливих варіантів відвідування студентами лекцій. Відношення ж R2 показує поточний стан навчального процесу. Очевидно, що відношення R2 є змінним у часі відношенням. Отже, факти про хід навчального процесу удалося відбити у вигляді двох відношень третього степеня (3-арних), а самі відношення зобразити у вигляді таблиць із трьома колонками. Зручність використання табличної форми для завдання відношення визначається в даному випадку наступними факторами: Усі використовувані множини кінцеві. При додаванні чи видаленні студентів, предметів, викладачів просто додаються чи видаляються відповідні рядки в таблиці. Нас зараз не цікавить питання, чи хороші отримані відношення. Помітимо поки тільки, що, як показують наступні зауваження, не будь-який рядок можна додати в таблицю "Відвідувати лекції". Зауваження. У таблицю "Відвідувати лекції" не можна додати два однакові рядки, тому що таблиця зображує відношення R2 , а у відношенні (як і в будь-якій множині) не може бути двох однакових елементів. Це приклад синтаксичного обмеження - таке обмеження задане у визначенні поняття відношення (однакових рядків не може бути в жодній таблиці, що задає відношення). Зауваження. У таблицю "Відвідувати лекції" не можна додати кортеж (Іванов, Геометрія, Пушняк). Дійсно, з таблиці "Читає лекції по…",представляющей відношення R1, випливає, що Пушняк не читає предмет "Геометрія". Виявилося, що таблиці зв'язані одна з одною, і істотно! Це приклад семантичного обмеження - таке обмеження є наслідком нашого трактування даних, що зберігаються у відношенні (наслідком розуміння змісту даних). 1.4.4. Транзитивне замикання відношень Уведемо поняття транзитивного замикання відношення. Це поняття пов'язане з поняттями бінарних відношеннь, що знадобляться далі. Визначення. Нехай відношення R задане на декартовому добутку (квадраті) А2 деякоі множини А. Транзитивним замиканням відношення R називається нове відношення , що складається з кортежів (х,у), для яких виконується: або кортеж , або знайдеться кінцева послідовність елементів така, що всі кортежі належать відношенню R. Очевидно, що . Приклад. Нехай множина А являє собою наступну множину деталей і конструкцій: А = {Болт, Гайка, Двигун, Автомобіль, Колесо, Вісь}, причому деякі з деталей і конструкцій можуть використовуватися при складанні інших конструкцій. Взаємозв'язок деталей описується відношенням R ("безпосередньо використовується в") і складається з наступних кортежів: Конструкція Де використовується
Болт Двигун
Болт Колесо
Гайка Двигун
Гайка Колесо
Двигун Автомобіль
Колесо Автомобіль
Вісь Колесо
Таблиця 5 Відношення R Транзитивне замиканняскладається з кортежів (додані кортежі позначені сірим кольором): Конструкція Де використовується
Болт Двигун
Болт Колесо
Гайка Двигун
Гайка Колесо
Двигун Автомобіль
Колесо Автомобіль
Вісь Колесо
Болт Автомобіль
Гайка Автомобіль
Ось Автомобіль
Таблиця 6 Транзитивне замикання відношення R Очевидний зміст замикання складається в описі включення деталей друг у друга не тільки безпосередньо, а через використання їх у проміжних деталях, наприклад, болт використовується в автомобілі, тому що він використовується в двигуні, а двигун використовується в автомобілі. Відношення у реляційних БД 1.4.2.1. Віджношення, кортежі та атрибути У реляційной моделі досягається набагато більш високий рівень абстракції даних, ніж в ієрархічній чи мережевій. У згаданій статті Е.Ф.Кодда стверджується, що "реляційна модель надає засоби опису даних на основі тільки їхньої природної структури, тобто без потреби введення якої-небудь додаткової структури для цілей машинного представлення". Іншими словами, представлення даних не залежить від способу їхньої фізичної організації. Це забезпечується за рахунок використання математичної теорії відношень (сама назва "реляційна" походить від англійського relation - "відношення"). Перейдемо до розгляду структурної частини реляційної моделі даних. Насамперед необхідно нагадати кілька визначень. Визначення: Декартів добуток: Для заданих кінцевих множин (не обов'язково різних) декартовим добутком называється множина добутків вигляду: , де Приклад: якщо дані дві множини A (a1,a2,a3) та B (b1,b2), їх декартів добуток буде мати вигляд С=A*B (a1*b1, a2*b1, a3*b1, a1*b2, a2*b2, a3*b2) Відношення: Відношенням R, визначеним на множинах називаеться підмножина декартова добутку . При цьому: множини називаються доменами відношення елементи декартова добутку називаються кортежами число n визначає степень відношення ( n=1 - унарне, n=2 - бінарне, ..., n-арне) кількість кортежів називається потужністю відношення. Приклад: на множині С з попереднього приклада можуть бути визначені відношення R1 (a1*b1, a3*b2) чи R2 (a1*b1, a2*b1, a1*b2) Відношення зручно представляти у вигляді таблиць. На малюнку представлена таблиця (відношення ступеня 5), що містить деякі відомості про працівників гіпотетичного підприємства. Рядки таблиці відповідають кортежам. Кожен рядок фактично являє собою опис одного об'єкта реального світу (у даному випадку працівника), характеристики якого містяться в стовпцях. Можна провести аналогію між елементами реляційної моделі даних і елементами моделі "сутність-зв'язок". Реляційні відношення відповідають наборам сутностей, а кортежі - сутностям. Тому, так як і в моделі "сутність-зв'язок" стовпці в таблиці, що відбиває реляційне відношення, називають атрибутами. Відношення є фундаментальним поняттям реляційної моделі даних. У визначенні поняття і структури відношення використовуємо визначення, дані К. Дейтом. Визначення. Атрибути відношення - це пари вигляду <Ім'я_атрибута : Ім'я_домену>. Імена атрибутів повинні бути унікальні в межах відношення. Часто імена атрибутів відношення збігаються з іменами відповідних доменів. Кортеж, що відповідає даній схемі відношення, - це множина пар {ім'я атрибута, значення}, що містить одне входження кожного імені атрибута, що належить схемі відношення. "Значення" є припустимим значенням домену даного атрибута (чи типу даних, якщо поняття домену не підтримується). Тим самим, ступінь чи "арність" кортежу, тобто число елементів у ньому, збігається з "арністью" відповідної схеми відношення. Попросту говорячи, кортеж - це набір іменованих значень заданого типу.
Кожен атрибут визначений на домені, тому домен можна розглядати як множину припустимих значень даного атрибута. Кілька атрибутів одного відношення і навіть атрибути різних відношень можуть бути визначені на тому самому домені. У прикладі, показаному на малюнку, атрибути "Оклад" і "Премія" визначені на домене "Гроші". Тому, поняття домену має семантичне навантаження: дані можна вважати порівнянними тільки тоді, коли вони відносяться до одного домену. Таким чином, у розглянутому нами прикладі порівняння атрибутів "Табельний номер" і "Оклад" є семантично некоректним, хоча вони і містять дані одного типу. Іменована множина пар "ім'я атрибута - ім'я домена" називається схемою відношення. Потужність цієї множини називають ступенем чи "арністью" відношення. Набір іменованих схем відношень представляє із себе схему бази даних. Атрибут, значення якого однозначно ідентифікує кортежі, називається ключовим (чи просто ключем). У нашому випадку ключем є атрибут "Табельний номер", оскільки його значення унікальне для кожного працівника підприємства. Якщо кортежі ідентифікуються тільки зчепленням значень кількох атрибутів, то говорять, що відношення має складений ключ. Відношення може містити кілька ключів. Завжди один із ключів являються первинним, його значення не можуть обновлятися. Всі інші ключі відношення називаються можливими (потенційними) ключами. На відміну від ієрархічної і мережної моделей даних у реляційної відсутнє поняття групового відношення. Для відображення асоціацій між кортежами різних відношень використовується дублювання їхніх ключів. Розглянутий приклад БД «Підприємство» (минула лекція), що містить відомості про підрозділи підприємства і працюючих у них співробітниках, стосовно до реляційної моделі буде мати вигляд:
База даних про підрозділи і співробітників підприємства Наприклад, зв'язок між відношеннями ВІДДІЛ і СПІВРОБІТНИК створюється шляхом копіювання первинного ключа "Номер_відділу" з першого відношення в друге. У такий спосіб: для того, щоб одержати список працівників даного підрозділу, необхідно з таблиці ВІДДІЛ установити значення атрибута "Номер_відділу", що відповідає даному "Найменуванню_відділу" вибрати з таблиці СПІВРОБІТНИК усі записи, значення атрибута "Номер_відділу" яким дорівнює отриманому на предыдушем кроці. для того, щоб довідатися в якому відділі працює співробітник, потрібно виконати зворотну операцію: визначаємо "Номер_відділу" з таблиці СПІВРОБІТНИК за отриманим значенням знаходимо запис у таблиці ВІДДІЛ. Атрибути, що представляють собою копії ключів інших відношень, називаються зовнішніми ключами. Схема відношення, схема БД Схема відношення - це іменована множина пар {ім'я атрибута, ім'я домену (чи типу, якщо поняття домену не підтримується)}. Степень чи "арність" схеми відношення - потужність цієї множини. Степень відношення СПІВРОБІТНИКИ (Спів_Номер, Спів_ПРІЗВИЩЕ, Спів_Зарп, Спів_НомВід) дорівнює чотирьом, тобто воно є 4-арним. Якщо всі атрибути одного відношення визначені на різних доменах, раціонально використовувати для іменування атрибутів імена відповідних доменів (не забуваючи, звичайно, про те, що це є усього лише зручним способом іменування і не усуває різниці між поняттями домену й атрибута). Схема БД (у структурному сенсі) - це набір іменованих схем відношень. Відношення - це множина кортежів, що відповідають одній схемі відношення. Іноді, щоб не плутатися, говорять "відношення-схема" і "відношення-екземпляр", іноді схему відношення називають заголовком відношення, а відношення як набір кортежів - тілом відношення. Насправді, поняття схеми відношення ближче усього до поняття структурного типу даних у мовах програмування. Було б цілком логічно дозволяти окремо визначати схему відношення, а потім одне чи кілька відношень з даною схемою. Однак у реляційних базах даних це не прийнято. Ім'я схеми відношення в таких базах даних завжди збігається з ім'ям відповідного відношення-екземпляру. У класичних реляційних базах даних після визначення схеми бази даних змінюються тільки відношення-екземпляри. У них можуть з'являтися нові і видалятися чи модифікуватися існуючі кортежі. Однак у багатьох реалізаціях допускається і зміна схеми бази даних: визначення нових і зміна існуючих схем відношення. Це прийнято називати еволюцією схеми бази даних. Звичайним життєвим представленням відношення є таблиця, заголовком якої є схема відношення, а рядками - кортежі відношення-екземпляра; у цьому випадку імена атрибутів іменують стовпці цієї таблиці. Тому іноді говорять "стовпець таблиці", маючи на увазі "атрибут відношення". Коли ми перейдемо до розгляду практичних питань організації реляційних баз даних і засобів керування, ми будемо використовувати цю термінологію. Цієї термінології дотримуються у більшості комерційних реляційних СУБД. Реляційна база даних - це набір відношень, імена яких збігаються з іменами схем відношень у схемі БД. Як видно, основні структурні поняття реляційної моделі даних (якщо не брати до уваги поняття домену) мають дуже просту інтуїтивну інтерпретацію, хоча в теорії реляційних БД усі вони визначаються абсолютно формально і точно. Структура відношення Визначення. Відношення R, визначене на множині доменів D1, D2…Dn (не обов'язково різних), містить дві частини: заголовок і тіло. Заголовок відношення містить фіксовану кількість атрибутів відношення: . Заголовок складається з такої фіксованої множини атрибутів A1, A2, ..., An, що існує взаємно однозначна відповідність між цими атрибутами Ai і доменами Di (i=1,2,...,n), що їх визначають. Тіло відношення містить множину кортежів відношення. Кожен кортеж відношення являє собою множину пар вигляду <Ім'я_атрибута : Значення_атрибута>:
таких, що значення Vali атрибуту Ai належить домену Di Тіло складається з мінливої в часі множини кортежів, де кожен кортеж складається у свою чергу з множини пар атрибут-значення (Ai:Vali), (i=1,2,...,n), по одній такій парі для кожного атрибута Ai у заголовку. Для будь-якої заданої пари атрибут-значення (Ai:Vali) Vali є значенням з єдиного домену Di, що зв'язаний з атрибутом Ai. Відношення звичайно записується у вигляді: , чи коротше , чи просто R. Кількість атрибутів у відношенні називають степенем (чи -арністю) відношення. Відношення степеня один називають унарним, степеня два – бінарним, ступеня три – тернарним, ..., а степеня n – n-арним. Потужність множини кортежів (кількість кортежів відношення) відношення називають потужністю відношення чи його кардинальним числом. Кардинальне число відношення змінюється в часі на відміну від його степеня. Повертаючись до математичного поняття відношення, уведеного раніше, можна зробити наступні висновки: Висновок 1. Заголовок відношення описує декартів добуток доменів, на якому задане відношення. Заголовок статичний, він не змінюється під час роботи з базою даних. Якщо у відношенні змінені, додані чи вилучені атрибути, то в результаті одержимо вже інше відношення (нехай навіть з колишнім ім'ям). Висновок 2. Тіло відношення являє собою набір кортежів, тобто підмножину декартового добутку доменів. Таким чином, тіло відношення власне і є відношенням у математичному сенсі слова. Тіло відношення може змінюватися під час роботи з базою даних - кортежі можуть змінюватися, додаватися і видалятися. Оскільки відношення – це множина, а множини за визначенням не містять співпадаючих елементів, те ніякі два кортежі відношення не можуть бути дублікатами один одного в будь-який довільно заданий момент часу. Нехай R – відношення з атрибутами A1, A2, ..., An. Говорять, що множина атрибутів K=(Ai, Aj, ..., Ak) відношення R є можливим ключем R тоді і тільки тоді, коли задовольняються дві незалежних від часу умови: Унікальність: у довільний заданий момент часу: ніякі два різних кортежі R не мають того самого значення для Ai, Aj, ..., Ak. Мінімальність: жоден з атрибутів Ai, Aj, ..., Ak не може бути виключений з K без порушення унікальності. Кожне відношення має хоча б один можливий ключ, оскільки щонайменше комбінація всіх його атрибутів задовольняє умові унікальності. Один з можливих ключів (обраний довільним чином) приймається за його первинний ключ. Інші можливі ключі, якщо вони є, називаються альтернативними ключами. Приклад 1. Розглянемо відношення "Співробітники" задане на доменах "Номер_співробітника", "Прізвище", "Зарплата", "Номер_відділу". Оскільки усі домени різні, то імена атрибутів відношення зручно назвати так само, як і відповідні домени. Заголовок відношення має вигляд: Співробітники (Номер_співробітника, Прізвище, Зарплата, Номер_відділу) Нехай у даний момент відношення містить три кортежі: (1,Іванов, 1000, 1) (2, Петров, 2000, 2) (3, Сидорчук, 3000, 1) Таке відношення природно представляється у вигляді таблиці: Номер_співробітника Прізвище Зарплата Номер_відділу
1 Іванов 1000 1
2 Петров 2000 2
3 Сидорчук 3000 1
Таблиця 1 Відношення "Співробітники" Визначення 3. Реляційною базою даних називається набір відношень. Визначення 4. Схемою реляційної бази даних називається набір заголовків відношень, що входять у базу даних. Хоча будь-яке відношення можна зобразити у вигляді таблиці, потрібно чітко розуміти, що відношення не є таблицями. Це близькі, але не співпадаючі поняття. Відмінності між відношеннями і таблицями будуть розглянуті нижче. Терміни, якими оперує реляційна модель даних, мають відповідні "табличні" синоніми: Реляційный термин Відповідний "табличний" термін
База даних Набір таблиць
Схема бази даних Набір заголовків таблиць
Відношення Таблиця
Заголовок відношення Заголовок таблиці
Тело відношення Тіло таблиці
Атрибут відношення Найменування стовпця таблиці
Кортеж відношення Рядок таблиці
Степень (-арність) відношення Кількість стовпців таблиці
Потужність відношення Кількість рядків таблиці
Домени та типи даних Типи дані в комірках таблиці
Для масового користувача реляційних СУБД можна, проте, з успіхом використовувати неформальні еквіваленти цих понять: Відношення – Таблиця (іноді Файл), Кортеж – Рядок (іноді Запис), Атрибут – Стовпець, Поле. При цьому приймається, що "запис" означає "екземпляр запису", а "поле" означає "ім'я і тип поля". Основні (фундаментальні) властивості відношень у реляційних БД Властивості відношень безпосередньо випливають з наведеного вище визначення відношення. У цих властивостях в основному і складаються відмінності між відношеннями і таблицями. Відсутність кортежів-дублікатів: у відношенні немає однакових кортежів. Дійсно, тіло відношення є множина кортежів і, як усяка множина, не може містити нерозрізнені елементи (див. поняття множини). Таблиці на відміну від відношень можуть містити однакові рядки. З цієї властивості випливає наявність у кожного кортежу первинного ключа. Для кожного відношення, принаймні, повний набір його атрибутів є первинним ключем. Однак, при визначенні первинного ключа повинна дотримуватися вимога "мінімальності", тобто в нього не повинні входити ті атрибути, які можна відкинути без збитку для основної властивості первинного ключа - однозначно визначати кортеж. Відсутність упорядкованості кортежів: кортежі не упорядковані (зверху вниз). Дійсно, незважаючи на те, що ми зобразили відношення "Співробітники" у вигляді таблиці, не можна сказати, що співробітник Іванов "передує" співробітнику Петрову. Причина та ж - тіло відношення є множиною, а множина не упорядкована. Це друга причина, по якій не можна ототожнити відношення і таблиці - рядки в таблицях упорядковані. Те саме відношення може бути зображено різними таблицями, у яких рядка йдуть у різному порядку. Відсутність упорядкованості атрибутів: атрибути не упорядковані (зліва направо). Для посилання на значення атрибута завжди використовується ім'я атрибута. Оскільки кожен атрибут має унікальне ім'я в межах відношення, те порядок атрибутів не має значення. Це властивість трохи відрізняє відношення від математичного визначення відношення. Це також третя причина, по якій не можна ототожнити відношення і таблиці - стовпці в таблиці упорядковані. Те саме відношення може бути зображено різними таблицями, у яких стовпці йдуть у різному порядку. Атомарність значень атрибутів, тобто серед значень домену не можуть міститися множини значень (відношення), усі значення атрибутів атомарні. Це випливає з того, що лежачі в їхній основі атрибути мають атомарні значення. Це четверта відмінність відношень від таблиць - у комірки таблиць можна помістити що завгодно - масиви, структури, і навіть інші таблиці. Зауваження. З властивостей відношення випливає, що не кожна таблиця може задавати відношення. Для того, щоб деяка таблиця задавала відношення, необхідно, щоб таблиця мала просту структуру (містила б тільки рядки і стовпці, причому, у кожнім рядку була б однакова кількість полів), у таблиці не повинне бути однакових рядків, будь-який стовпець таблиці повинний містити дані тільки одного типу, усі використовувані типи даних повинні бути простими. Зауваження. Кожне відношення можна вважати класом еквівалентності таблиць, для яких виконуються наступні умови: Таблиці мають однакову кількість стовпців. Таблиці містять стовпці з однаковими найменуваннями. Стовпці з однаковими найменуваннями містять дані з тих самих доменов. Таблиці мають однакові рядки з урахуванням того, що порядок стовпців може розрізнятися. Усі такі таблиці є різні зображення того самого відношення. Реляційна модель (організація бази) даних Модель даних можна інтерпретувати як сукупність правил породження структур даних у БД, операції над ними, а також обмеження цілісності, що визначає допустимі зв'язки і значення даних, а також послідовність їхньої зміни. Бувають: ієрархічна, мережна, реляційная. Модель даних описує деякий набір родових понять і ознак, які повинні мати всі конкретні СУБД і керовані ними бази даних, якщо вони ґрунтуються на цій моделі. Наявність моделі даних дозволяє порівнювати конкретні реалізації, використовуючи одну спільну мову. Хоча поняття моделі даних є загальним, і можна говорити про ієрархічної, мережний, деякий семантичну і т.д. моделі даних, потрібно відзначити, що це поняття було введено в ужиток стосовно до реляційным систем і найбільше ефективно використовується саме в цьому контексті. Спроби прямолінійного застосування аналогічних моделей до дореляційным організацій показують, що реляційная модель занадто "велика" для них, а для постреляційних організацій вона виявляється "мала". Коли в попередніх розділах ми говорили про основні поняття баз даних, ми використовували поняття так називаної реляційної моделі даних. Реляційна модель та БД. Загальна характеристика Найбільш розповсюджене трактування реляційной моделі даних, очевидно, належить Дейту, що відтворює її (з різними уточненнями) практично у всіх своїх книгах. Згідно Дейту реляційна модель складається з трьох частин, що описують різні аспекти реляційного підходу: з структурної частини, манипуляційної частині і цілісній частині. У структурній частині моделі фіксується, що єдиною структурою даних, використовуваною в реляційних БД, є нормалізоване n-арне відношення. У лекції ми досі розглядали саме поняття і властивості структурної складовий реляційної моделі. У манипуляційній частині моделі стверджуються два фундаментальних механізми маніпулювання реляційними БД - реляційна алгебра і реляційне числення. Перший механізм базується в основному на класичній теорії множин (з деякими уточненнями), а другий - на класичному логічному апараті числення предикатів першого порядку. Ми розглянемо ці механізми більш докладно на наступній лекції, а поки лише помітимо, що основною функцією манипуляційної частини реляційної моделі є забезпечення міри реляційності будь-якої конкретної мови реляційних БД: мова називається реляційною, якщо він має не меншу виразність і потужність, ніж реляційна алгебра чи реляційне числення. Реляційна база даних – це сукупність відношень, що містять всю інформацію, що повинна зберігатися в БД. Однак користувачі можуть сприймати таку базу даних як сукупність таблиць. Ці таблиці мають певні властивості: 1. Кожна таблиця складається з однотипних рядків і має унікальне ім'я. 2. Рядки мають фіксоване число полів (стовпців) і значень (множинні поля і повторювані групи неприпустимі). Інакше кажучи, у кожній позиції таблиці на перетинанні рядка і стовпця завжди є в точності одне значення чи нічого. 3. Рядки таблиці обов'язково відрізняються друг від друга хоча б єдиним значенням, що дозволяє однозначно ідентифікувати будь-який рядок такої таблиці. 4. Стовпцям таблиці однозначно надаються імена, і в кожнім з них розміщаються однорідні значення даних (дати, прізвища, цілі числа чи грошові суми). 5. Повний інформаційний зміст бази даних представляється у вигляді явних значень даних і такий метод представлення є єдиним. Зокрема, не існує яких-небудь спеціальних "зв'язків" чи покажчиків, що з'єднують одну таблицю з іншою . 6. При виконанні операцій з таблицею її рядка і стовпці можна обробляти в будь-якому порядку безвідносно до їхнього інформаційного змісту. Цьому сприяє наявність імен таблиць і їхніх стовпців, а також можливість виділення будь-якого їхнього рядка чи будь-якого набору рядків із зазначеними ознаками (наприклад, рейсів з пунктом призначення "Париж" і часом прибуття до 12 годин). 1.5.2. Перша нормальна форма Складніше за все дати визначення речей, що усім зрозумілі. Якщо давати не строге, описове визначення, то завжди залишається можливість неправильного його трактування. Якщо дати строге формальне визначення, то воно, як правило, чи тривіальне, чи занадто громіздке. Саме така ситуація з визначенням відношення в Першій Нормальній Формі (1НФ). Зовсім не говорити про цьому не можна, тому що на основі 1НФ будуються більш високі нормальні форми. Дати визначення 1НФ складне через його тривіальність. Тому, дамо просто кілька пояснень. Пояснення 1. Говорять, що відношення R находится в 1НФ, якщо воно задовольняє визначенню відношення. Це, власне, тавтологія, адже з визначення відношення випливає, що інших відношень не буває. Дійсно, визначення відношення описує, що є відношенням, а що - ні, отже, відношень у непершій нормальній формі просто немає. Пояснення 2. Говорять, що відношення R знаходиться в 1НФ, якщо його атрибути містять тільки скалярні (атомарні) значення. Знову ж, визначення відношення спирається на поняття домену, а домени визначені на простих типах даних. Непершу нормальну форму можна одержати, якщо допустити, що атрибути відношення можуть бути визначені на складних типах даних - масивах, структурах, чи навіть на інших відношеннях. Легко собі представити таблицю, у якої в деяких комірках містяться масиви, в інших комірках - визначені користувачами складні структури, а в третіх комірках - цілі реляційні таблиці, що у свою чергу можуть містити такі ж складні об'єкти. Саме такі можливості надаються деякими сучасними постреляційними й об'єктними СУБД. Вимога, що відношення повинно містити тільки дані простих типів, пояснює, чому відношення іноді називають плоскими таблицями (plain table). Дійсно, таблиці, що задають відношення двумерны. Один вимір задається списком стовпців, другий вимір задається списком рядків. Пара координат (Номер рядка, Номер стовпця) однозначно ідентифікує комірку таблиці і значення, що міститься в ній. Якщо ж допустити, що в комірці таблиці можуть міститися дані складних типів (масиви, структури, інші таблиці), то така таблиця буде вже не плоскої. Наприклад, якщо в комірці таблиці міститься масив, то для звертання до елемента масиву потрібно знати три параметри (Номер рядка, Номер стовпця, номер елемента в масиві). У такий спосіб з'являється третє пояснення Першої Нормальної Форми: Пояснення 3. Відношення R знаходиться в 1НФ, якщо воно є плоскою таблицею. Ми свідомо обмежуємося розглядом тільки класичної реляційної теорії, у якій усі відношення мають тільки атомарні атрибути і свідомо знаходяться в 1НФ. 1.5.3. Цілісність сутностей та посилань Цілісність даних - це механізм підтримки відповідності бази даних предметної області. У реляційній моделі даних визначені дві базових вимоги забезпечення цілісності: цілісність посилань цілісність сутностей. Дві базових вимоги цілісності, що повинні підтримуватися в будь-який реляційной СУБД, фіксуються в цілісній частині реляційної моделі даних Перша вимога називається вимогою цілісності сутностей. Цілісність сутностей Об'єкт реального світу представляється в реляційній базі даних як кортеж деякого відношення. Вимога цілісності сутностей полягає в наступному: будь-який кортеж будь-якого відношення відрізнимий від будь-якого іншого кортежу цього відношення, тобто іншими словами, будь-яке відношення повинне мати первинний ключ. Як ми бачили, ця вимога автоматично задовольняється, якщо в системі не порушуються базові властивості відношень. Цілком очевидно, що якщо дана вимога не дотримується (тобто кортежі в рамках одного відношення не унікальні), те в базі даних може зберігається суперечлива інформація про один й той самий об'єкт. Підтримка цілісності сутностей забезпечується засобами системи управління базою даних (СУБД). Це здійснюється за допомогою двох обмежень: при додаванні записів у таблицю перевіряється унікальність їхніх первинних ключів не дозволяється зміна значень атрибутів, що входять у первинний ключ. Друга вимога називається вимогою цілісності за посиланнями і є трохи більш складною. Цілісність посилань Складні об'єкти реального світу представляються в реляційній базі даних у вигляді кортежів кількох нормалізованих відношень, зв'язаних між собою. При цьому: Зв'язки між даними відношеннями описуються в термінах функціональних залежностей. Для відображення функціональних залежностей між кортежами різних відношень використовується дублювання первинного ключа одного відношення (батьківського) в інше (дочірнє). Атрибути, що представляють собою копії ключів батьківських відношень, називаються зовнішніми ключами. Вимога цілісності за посиланнями полягає в наступному: для кожного значення зовнішнього ключа, що з'являється в дочірнім відношенні, у батьківському відношенні повинний знайтися кортеж з таким же значенням первинного ключа. Нехай, наприклад, дані відношення ВІДДІЛ (N_ВІДДІЛУ, ІМ'Я_ВІДДІЛУ) і СПІВРОБІТНИК (N_СПІВРОБІТНИКА, N_ВІДДІЛУ, ІМ'Я_СПІВРОБІТНИКА), у яких зберігаються відомості про працівників підприємства і підрозділи, де вони працюють. Відношення ВІДДІЛ у даній парі є батьківським, тому його первинний ключ "N_відділу" є присутнім у дочірнім відношенні СПІВРОБІТНИК. Вимога цілісності по посиланнях означає тут, що в таблиці СПІВРОБІТНИК не може бути присутнім кортеж зі значенням атрибута "N_відділу", що не зустрічається в таблиці ВІДДІЛ. Якщо таке значення у відношенні ВІДДІЛ відсутнє, значення зовнішнього ключа у відношенні СПІВРОБІТНИК вважається невизначеним. Дійсно, при дотриманні нормалізованості відношень складні сутності реального світу представляються в реляційній БД у вигляді кількох кортежів кількох відношень. Наприклад, представимо, що нам потрібно представити в реляційніій базі даних сутність ВІДДІЛ з атрибутами ВІД_НОМЕР (номер відділу), ВІД_КІЛ (кількість співробітників) і ВІД_СПІВР (набір співробітників відділу). Для кожного співробітника потрібно зберігати СПІВР_НОМЕР (номер співробітника), СПІВР_ІМ'Я (ім'я співробітника) і СПІВР_ЗАРП (заробітна плата співробітника). Як ми незабаром побачимо, при правильному проектуванні відповідної БД у ній з'являться два відношення: ВІДДІЛИ ( ВІД_НОМЕР, ВІД_КІЛ ) (первинний ключ - ВІД_НОМЕР) і СПІВРОБІТНИКИ (СПІВР_НОМЕР, СПІВР_ІМ'Я, СПІВР_ЗАРП, СПІВР_ВІД_НОМ ) (первинний ключ - СПІВР_НОМЕР). Як видно, атрибут СПІВР_ВІД_НОМ з'являється у відношенні СПІВРОБІТНИКИ не тому, що номер відділу є власною властивістю співробітника, а лише для того, щоб мати можливість відновити при необхідності повну сутність ВІДДІЛ. Значення атрибута СПІВР_ВІД_НОМ у будь-якому кортежі відношення СПІВРОБІТНИКИ повинний відповідати значенню атрибута ВІД_НОМ у деякому кортежі відношення ВІДДІЛИ. Атрибут такого роду називається зовнішнім ключем, оскільки його значення однозначно характеризують сутності, представлені кортежами деякого іншого відношення (тобто задають значення їхнього первинного ключа). Говорять, що відношення, у якому визначений зовнішній ключ, посилається на відповідне відношення, у якому такий же атрибут є первинним ключем. Вимога цілісності по посиланнях, чи вимога зовнішнього ключа полягає в тому, що для кожного значення зовнішнього ключа, що з'являється у відношенні, що посилається, у відношенні, на якому йде посилання, повинний знайтися кортеж з таким же значенням первинного ключа, або значення зовнішнього ключа повинне бути невизначеним (тобто ні на що не вказувати). Для нашого приклада це означає, що якщо для співробітника зазначений номер відділу, те цей відділ повинен існувати. Як правило, підтримка цілісності посилань також покладається на систему управління базою даних. Наприклад, вона може не дозволити користувачу додати запис, що містить зовнішній ключ з неіснуючим (невизначеним) значенням. На закінчення відзначимо, що часто замість вираження "цілісність по посиланнях" уживають його синоніми "посилальна цілісність", "цілісність зв'язків" чи "вимога зовнішнього ключа". Обмеження цілісності по сутностях і по посиланнях повинні підтримуватися СУБД. Для дотримання цілісності сутності досить гарантувати відсутність у будь-якім відношенні кортежів з тим самим значенням первинного ключа. З цілісністю по посиланнях справи йдуть трохи більш складно. Зрозуміло, що при відновленні що посилається відношення (уставці нових чи кортежів модифікації значення зовнішнього ключа в існуючих кортежах) досить стежити за тим, щоб не з'являлися некоректні значення зовнішнього ключа. Але як бути при видаленні кортежу з відношення, на яке веде посилання? Тут існують три підходи, кожний з який підтримує цілісність по посиланнях. Перший підхід полягає в тім, що забороняється робити видалення кортежу, на который існують посилання (тобто спочатку потрібно або видалити кортежі, що посилаються, або відповідним чином змінити значення їхнього зовнішнього ключа). При другому підході при видаленні кортежу, на який є посилання, у всіх кортежах, що посилаються, значення зовнішнього ключа автоматично стає невизначеним. Нарешті, третій підхід (каскадне видалення) полягає в тому, що при видаленні кортежу з відношення, на яке йде посилання, з відношення, яке на нього посилається, автоматично вилучаються відповідні кортежі з видаленим значенням., У розвинених реляційних СУБД звичайно можна вибрати спосіб підтримки цілісності по посиланнях для кожної окремої ситуації визначення зовнішнього ключа. Звичайно, для прийняття такого рішення необхідно аналізувати вимоги конкретної прикладної області. Висновки Реляційная модель даних складається з трьох частин: Структурної частини. Цілісної частини. Манипуляційної частини. У класичної реляційной моделі використовуються тільки прості (атомарні) типи даних. Прості типи даних не мають внутрішню структуру. Домени - це типи даних, що мають деякий зміст (семантику). Домени обмежують порівняння - некоректно, хоча і можливо, порівнювати значення з різних доменівв. Відношення складається з двох частин - заголовка відношення і тіла відношення. Заголовок відношення - це аналог заголовка таблиці. Заголовок відношення складається з атрибутів. Кількість атрибутів називається степенем відношення. Тіло відношення - це аналог тіла таблиці. Тіло відношення складається з кортежів. Кортеж відношення є аналогом рядка таблиці. Кількість кортежів відношення називається потужністю відношення. Відношення має наступні властивості: У відношенні немає однакових кортежів. Кортежі не упорядковані (зверху вниз). Атрибути не упорядковані (ліворуч праворуч). Усі значення атрибутів атомарні. Реляційной базою даних називається набір відношень. Схемою реляційной бази даних називається набір заголовків відношень, що входять у базу даних.
