Не кожна таблиця є реляційної, реляційні таблиці мають певні властивості.
Властивості реляційної таблиці:
1. кожен елемент таблиці - це один елемент даних
2. всі стовпці однорідні
3. кожне поле таблиці має унікальне ім'я
4. відсутні однакові записи
5. порядок рядків і стовпців може бути довільним
Перше властивість вимагає, щоб на перетині рядка і стовпця знаходилося атомарному (неподільне, що не має внутрішньої структури) значення.
Приклад У поле Альбом таблиці порушено властивість атомарности значення атрибута.
Для забезпечення зв'язку між таблицями використовуються зовнішні ключі. Значення зовнішнього ключа формуються на основі значень відповідного йому первинного ключа. На малюнку 1 в поле Код Групи є зовнішнім ключем для первинного ключа Код Групи таблиці Група
Типи зв'язків між таблицями
Зв'язки між таблицями дуже важливі, оскільки вони вказують, як знаходити, розміщувати та використовувати інформацію з полів двох або більше таблиць. Крім того, зв'язки відображають правила відносини між об'єктами, представленими в різних таблицях.
Існує три типи зв'язків: один-до-одного, один-ко-многим, багато-до-багатьох.
Групи 1 - М Альбоми
Цей тип зв'язку відповідає відношенню між таблицями Група та Альбом. У кожної групи може бути кілька альбомів, але будь-який альбом може бути випущений однією певною групою. Таблиця з боку відносини 1 називається головною. таблиця ж з боку багато - підлеглої.
With The Beatles
Ці таблиці пов'язані між собою через загальні атрибути (номер групи).
Економічність розміщення даних у вигляді пов'язаних таблиць (а не у вигляді однієї) стає більш відчутною при збільшенні числа записів в таблицях.
група М - М музикант
Наприклад, в групі може грати кілька музикантів, а будь-який музикант може грати в декількох музичних групах.
Таблиця 3 показує відповідність з цим багато-до-багатьох.
Зв'язок один-до-одного (1 - 1): Кожного запису однієї таблиці може відповідати тільки один запис з іншої таблиці. Цей зв'язок рідко використовується в базах даних. По суті справи вона застосовується тоді, коли з якихось причин необхідно зберігати інформацію про один об'єкт в різних таблицях. При необхідності вся інформація з цих таблиць може бути зібрана в одну.
Частина реляційної моделі пов'язана з цілісністю даних, піддавалася і піддається найбільшому зміни. У деяких її деталях провідні фахівці до цих пір не мають спільної точки зору. У цьому розділі будуть коротко викладені загальні положення, пов'язані з цілісністю даних.
Коли говорять про цілісність даних, мається на увазі наявність деяких правил покликаних забезпечити несуперечливість (достовірність) інформації, що зберігається в БД.
Існують загальні правила, які відносяться до всіх реляційних БД і приватні правила, які стосуються конкретно взятої БД. Забезпечення виконання цих правил бере на себе СУБД.
Як уже зазначалося, для кожної БД може вимагатися виконання своїх приватних правил.
Приклад Список приватних правил для БД «студент» міг би включати такі правила:
- Рік закінчення навчання> = рік надходження +5
- Номери груп повинні вибиратися зі списку 10,11, 20, 21, 30, 31, 40, 50
- № студентського квитка повинен бути представлений у вигляді nnnnnn, де n-це цифра
Загальні правила цілісності, пов'язані з поняттями первинних і зовнішніх ключів.
Правило цілісності об'єкта. Жоден елемент первинного ключа не може містити порожнього значення.
В якості первинного ключа потрібно вибирати поля, які обов'язково будуть містити однозначно інтерпретуються значення.
Приклад Первинний ключ № банківського рахунку містить порожні значення. Така ситуація є неприпустимою, для реляційних БД. Тут пусте значення може інтерпретуватися по різному: 1) у співробітника є № банківського рахунку, але він, з якоїсь причини не вказано; 2) у співробітника немає № банківського рахунку 3) не відомо чи є у співробітника № банківського рахунку чи ні.