Реляційна модель даних: три складові 
";


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Реляційна модель даних: три складові



Модель даних описує деякий набір родових понять і ознак, якими повинні володіти всі конкретні СУБД і керовані ними бази даних, якщо вони ґрунтуються на цій моделі. Наявність моделі даних дозволяє порівнювати конкретні реалізації, використовуючи один спільну мову.

Термін «модель даних» був введений в ужиток стосовно до реляційних систем і найбільш ефективно використовується саме в цьому контексті, хоча можна говорити про ієрархічної, мережевої, і навіть концептуальної моделях даних.

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

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

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

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

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

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

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

Обмеження цілісності сутності і по посиланнях повинні підтримуватися СУБД.

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

З цілісністю по посиланнях справи йдуть декілька складніше.

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

Тут існують три підходи, кожен з яких підтримує цілісність по посиланням.

1. Забороняється проводити видалення кортежу з основного відношення, якщо на нього існують посилання.

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

3. Каскадне видалення полягає в тому, що при видаленні кортежу з основного відношення, автоматично видаляються всі кортежі, що посилаються, з підлеглого відношення.

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

 



Поделиться:


Последнее изменение этой страницы: 2017-01-26; просмотров: 306; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 35.172.193.238 (0.005 с.)