Фундаментальні властивості відношень

Інтуїтивна інтерпретація реляційних понять

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

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

Зупинимося тепер на деяких важливих властивостях відношень:

1) Відсутність кортежів-дублікатів, первинний і можливі ключі відношень

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

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

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

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

Нарешті, повернемося до властивості мінімальності первинного і можливих ключів. Як наголошувалося вище, ця властивість є критично важливою, і важливість виявляється саме при трактуванні первинного і можливих ключів як обмежень цілісності. У нашому прикладі з відношенням СЛУЖБОВЦІ властивістю унікальності володітиме не тільки безліч атрибутів { СЛУ_НОМЕР}, але і, наприклад, множина { СЛУ_НОМЕР, СЛУ_ОТД_НОМЕР}. Але якби ми виставили як обмеження цілісності вимогу унікальності { СЛУ_НОМЕР, СЛУ_ОТД_НОМЕР}, то СУБД гарантувала б відсутність кортежів з однаковим значенням атрибуту СЛУ_НОМЕР не у всьому значенні відношення СЛУЖБОВЦІ, а тільки в групах кортежів з одним і тим же значенням атрибуту СЛУ_ОТД_НОМЕР. Зрозуміло, що це не відповідає сенсу модельованої наочної області.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Тип даних	\|	Відсутність впорядкованості кортежів

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.005 сек.