ЛЕКЦІЯ 1. РЕЛЯЦІЙНА БАЗА ДАНИХ – ПРАВИЛА КОДДА. ІДЕОЛОГІЯ І КОНЦЕПЦІЯ СХОВИЩА ДАНИХ У ПОРІВНЯННІ З РЕЛЯЦІЙНОЮ БАЗОЮ ДАНИХ
1. ПРАВИЛА КОДДА ДЛЯ РЕЛЯЦІЙНИХ БАЗ ДАНИХ
0. Фундаментальне правило (Foundation Rule)
Реляційна СУБД повинна бути здатна повністю керувати базою даних, використовуючи зв'язки між даними.
1. Інформаційне правило (Information Rule)
Інформація повинна бути представлена у вигляді даних, що зберігаються в осередках. Дані, що зберігаються в комірках, повинні бути атомарним. Порядок рядків в реляційній таблиці не повинен впливати на зміст даних.
Правило інформації. Вся інформація в базі даних повинна бути представлена виключно на логічному рівні і лише одним способом - у вигляді значень, що містяться в таблицях. Фактично це неформальне визначення реляційної бази даних.
2. Правило гарантованого доступу (Guaranteed Access Rule)
Доступ до даних повинен бути вільним від двозначності. До кожного елементу даних повинен бути гарантований доступ за допомогою комбінації імені таблиці, первинного ключа рядку й імені стовпця.
Правило 2 вказує на роль первинного ключа при пошуку інформації в базі даних. Ім'я таблиці дозволяє знайти необхідну таблицю, ім'я стовпця дозволяє знайти потрібний стовпець, а первинний ключ дозволяє знайти рядок, що містить шуканий елемент даних.
3. Систематична обробка Null-значень (Systematic Treatment of Null Values)
Невідомі значення NULL, відмінні від будь-якого відомого значення, повинні підтримуватися для всіх типів даних при виконанні будь-яких операцій. Наприклад, для числових даних невідомі значення не повинні розглядатися як нулі, а для символьних даних - як порожні рядки.
Правило 3 вимагає, щоб відсутні дані можна було уявити за допомогою недійсних значень (NULL).
4. Правило доступу до системного каталогу на основі реляційної моделі (Dynamic On-line Catalog Based on the Relational Model)
Словник даних повинен зберігатися у формі реляційних таблиць, і СУБД повинна підтримувати доступ до нього за допомогою стандартних мовних засобів, тих самих, які використовуються для роботи з реляційними таблицями, що містять дані користувача.
Правило 4 свідчить, що реляційна база даних повинна сама себе описувати. Іншими словами, база даних повинна містити набір системних таблиць, що описують структуру самої бази даних.
5. Правило повноти підмови маніпулювання даними (Comprehensive Data Sublanguage Rule)
Система управління реляційними базами даних повинна підтримувати хоча б одну реляційну мову, яка
а) має лінійний синтаксис,
б) може використовуватися як інтерактивною, так і в прикладних програмах,
в) підтримує операції визначення даних, визначення уявлень, маніпулювання даними (інтерактивні та програмні), обмежувачі цілісності, управління доступом та операції управління транзакціями (begin, commit і rollback).
Правило 5 вимагає, щоб СУБД використовувала мову реляційної бази даних. Така мова повинна підтримувати всі основні функції СУБД - створення бази даних, читання і введення даних, реалізацію захисту бази даних і т.д.
6. Правило модифікації представлень (View Updating Rule)
Кожне подання має підтримувати всі операції маніпулювання даними, які підтримують реляційні таблиці: операції вибірки, вставки, модифікації і видалення даних.
Правило 6 стосується уявлень, які є віртуальними таблицями, які дозволяють показувати різним користувачам різні фрагменти структури бази даних.
7. Правило високорівневих операцій модифікації даних (High-level Insert, Update, and Delete)
Операції вставки, модифікації і видалення даних повинні підтримуватися не тільки по відношенню до одного рядку реляційної таблиці, але по відношенню до будь-якої безлічі рядків.
Правило 7 акцентує увагу на тому, що бази даних за своєю природою орієнтовані на множини. Воно вимагає, щоб операції додавання, видалення і оновлення можна було виконувати над множинами рядків.
8. Правило фізичної незалежності даних (Physical Data Independence)
Додатки не повинні залежати від використовуваних способів зберігання даних на носіях, від апаратного забезпечення комп'ютерів, на яких знаходиться реляційна база даних.
Прикладні програми і утиліти для роботи з даними повинні на логічному рівні залишатися недоторканими за будь-яких змінах способів зберігання даних або методів доступу до них.
9. Правило логічної незалежності даних (Logical Data Independence)
Представлення даних в додатку не повинно залежати від структури реляційних таблиць. Якщо в процесі нормалізації одна реляційна таблиця розділяється на дві, подання повинне забезпечити об'єднання цих даних, щоб зміна структури реляційних таблиць не позначалося на роботі додатків.
Правила 8 і 9 означають відділення користувача та прикладної програми від низькорівневої реалізації бази даних.
10. Правило незалежності контролю цілісності (Integrity Independence)
Вся інформація, необхідна для підтримки цілісності, повинна бути в словнику даних. Мова для роботи з даними повинна виконувати перевірку вхідних даних і автоматично підтримувати цілісність даних.
Правило 10 говорить, що мова бази даних повинен підтримувати обмежувальні умови, що накладаються на дані, що вводяться і дії, які можуть бути виконані над даними.
11. Правило незалежності від розміщення (Distribution Independence)
База даних може бути розподіленої, може перебувати на декількох комп'ютерах, і це не повинно впливати на додатки. Перенесення бази даних на інший комп'ютер не повинен впливати на додатки.
Правило 11 говорить, що мова бази даних повинна забезпечувати можливість роботи з розподіленими даними, розташованими на інших комп'ютерних системах.
12. Правило узгодженості мовних рівнів (The Nonsubversion Rule)
Якщо використовується низькорівнева мова доступу до даних, він не повинен ігнорувати правила безпеки і правила цілісності, які підтримуються мовою більш високого рівня.
Правило 12 запобігає використанню інших можливостей для роботи з базою даних крім мови бази даних, оскільки це може порушити її цілісність.
Шрифти
Розмір шрифта
Колір тексту
Колір тла
Кернінг шрифтів
Видимість картинок
Інтервал між літерами
Висота рядка
Виділити посилання