Створення бази даних оптичних лазерів

0. Фундаментальне правило (Foundation Rule)

Реляційна СУБД має бути здатною повністю керувати базою даних, використовуючи зв'язки між даними

1. Інформаційне правило (Information Rule)

Інформація має бути представлена у вигляді даних, що зберігаються в осередках. Дані, що зберігаються у комірках, мають бути атомарними. Порядок рядків у реляційній таблиці не повинен впливати на зміст даних

2. Правило гарантованого доступу (Guaranteed Access Rule)

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

3. Систематична обробка Null-значень (Systematic Treatment of Null Values)

Невідомі значення NULL, відмінні від будь-якого відомого значення, мають підтримуватись для всіх типів даних при виконанні будь-яких операцій. Наприклад, для числових даних невідомі значення не повинні розглядатись як нулі, а для символьних даних – як порожні рядки.

4. Правило доступу до системного каталогу на основі реляційної моделі (Dynamic On-line Catalog Based on the Relational Model)

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

5. Правило повноти підмови маніпулювання даними (Comprehensive Data Sublanguage Rule)

Система управління реляційними базами даних має підтримувати хоча б одну реляційну мову, яка

а) має лінійний синтаксис,

б) може використовуватись інтерактивно і в прикладних програмах,

в) підтримує операції визначення даних, визначення уявлень, маніпулювання даними (інтерактивні та програмні), обмежувачі цілісності, управління доступом та операції управління транзакціями (begin, commit і rollback).

6. Правило модифікації поглядів (View Updating Rule)

Кожне подання має підтримувати усі операції маніпулювання даними, які підтримують реляційні таблиці: операції вибірки, вставки, модифікації і видалення даних.

7. Правило високорівневих операцій модифікації даних (High-level Insert, Update, and Delete)

Операції вставки, модифікації і видалення даних мають підтримуватись не тільки щодо одного рядку реляційної таблиці, але й щодо будь-якої безлічі рядків.

8. Правило фізичної незалежності даних (Physical Data Independence)

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

9. Правило логічної незалежності даних (Logical Data Independence)

Представлення даних в додатку не повинно залежати від структури реляційних таблиць. Якщо в процесі нормалізації одна реляційна таблиця розділяється на дві, подання має забезпечити об'єднання цих даних, щоб зміна структури реляційних таблиць не позначалась на роботі додатків.

10. Правило незалежності контролю цілісності (Integrity Independence)

Вся інформація, необхідна для підтримки цілісності, має бути у словнику даних. Мова для роботи з даними має виконувати перевірку вхідних даних і автоматично підтримувати цілісність даних.

11. Правило незалежності від розміщення (Distribution Independence)

База даних може бути розподіленою, може перебувати на кількох комп'ютерах, і це не повинно впливати на додатки. Перенесення бази даних на інший комп'ютер не повинне впливати на додатки.

12. Правило узгодженості мовних рівнів (The Nonsubversion Rule)

Якщо використовується низькорівнева мова доступу до даних, вона не повинна ігнорувати правила безпеки і правила цілісності, які підтримуються мовою більш високого рівня.

 

 

Нормалізація схеми бази даних – покроковий процес розбиття одного відношення (на практиці: таблиці) відповідно до алгоритму нормалізації на декілька відношень на базі функціональних залежеостей. 

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

Перша нормальна форма (1НФ, 1NF) утворює ґрунт для структурованої схеми баз даних: Кожна таблиця повинна мати основний ключ: мінімальний набір колонок, які ідентифікують запис. Уникнення повторень груп (категорії даних, що можуть зустрічатись різну кількість разів в різних записах) правильно визначаючи не-ключові атрибути. Атомарність: кожен атрибут повинен мати лише одне значення, а не множину значень.

Друга нормальна форма (2НФ, 2NF) вимагає, аби дані, що зберігаються в таблицях із композитним ключем не залежали лише від частини ключа: Схема бази даних повинна відповідати вимогам першої нормальної форми. Дані, що повторно з'являються в декількох рядках виносяться в окремі таблиці.

Третя нормальна форма (3НФ, 3NF) вимагає, аби дані в таблиці залежали винятково від основного ключа: Схема бази даних повинна відповідати всім вимогам другої нормальної форми. Будь-яке поле, що залежить від основного ключа та від будь-якого іншого поля, має виноситись в окрему таблицю.

Нормальна форма Бойса – Кодда. Відношення знаходиться в НФБК, тоді