Мова опису даних

Створення таблиць

До цих пір ми обговорювали частину SQL, іменовану DML - Data Manipulation Language. Цей параграф коротко описує основи іншу скалдову SQL - DDL - Data Definition Language.

Загальний синтаксис команди створення таблиці наступний.

Синтаксис:

CREATE TABLE <ім'я_таблиці>

(<Ім'я_стовпця> <тип_ даних> [(<розмір>)] [<обмеження стовпця>] {, [<ім'я_стовпця> <тип_даних> [(<розмір>)] [<обмеження стовпця>]] ...} [<обмеження таблиці>]);

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

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

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

Підтримка цілісності РБД

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

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

До структурної цілісності можна віднести і проблему невизначених значень NULL. Для порівняння з невизначеним значенням необхідно використовувати спеціальний оператор IS [NOT].

Мовна цілісність полягає в тому, що РСУБД повинна забезпечувати мови опису та маніпулювання даними не нижче стандарту SQL. Не повинні бути доступні інші низькорівневі засоби маніпулювання даними.

Посилальна цілісність позначає підтримку зовнішніх ключів з можливістю вибору одного з наступних принципів видалення пов'язаних кортежів:

• ON DELETE CASCADE - кортежі підлеглого відношення знищуються при видаленні пов'язаних з ними кортежів основного відношення.

• ON DELETE SET NULL - кортежі підлеглого відношення модифікуються в NULL при видаленні пов'язаних з ними кортежів основного відношення.

• ON DELETE RESTRICT - заборона на видалення кортежу основного відношення при наявності кортежів підлеглого відношення, пов'язаних з ним.

Посилальна цілісність забезпечує підтримку несуперечливого стану БД при модифікації даних.

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

Виділяють наступні види обмежень семантичної цілісності.

• Обмеження цілісності на рівні стовпця (вказуються при описі таблиці в розділі <обмеження стовпця>).

Значення за замовчуванням: [DEFAULT {<значення> | USER | NULL}]

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

Обмеження унікальності стовпця: [UNIQUE]

Умова перевірки на допустимість значення:

CHECK (<булевий вираз>)

Тут <булевий вираз> допускає тільки посилання на даний стовпець.

Заборона невизначених значень: [NOT NULL]

Породжує умова перевірки на допустимість значення: CHECK (<ім'я_стовпця> IS NOT NULL)

Первинний ключ: [PRIMARY KEY]

Якщо в таблиці одне поле є первинним ключем, то його оголошення еквівалентно зв'язці обмежень [NOT NULL] [UNIQUE]

Обмеження стовпця за посиланням: оголошення поля зовнішнім ключем.

FOREING KEY REFERENCES

<ім'я основної_таблиці> (<ім’я_первинного ключа основної_таблиці>) [ON DELETE {CASCADE | SET NULL | RESTRICT}]

Основна таблиця повинна бути описана до опису підлеглої.

Багато СУБД донедавна не підтримували поняття зовнішнього ключа. Однак на сучасному етапі всі провідні СУБД надають таку можливість.

• Іноді семантичне обмеження цілісності пов'язує декілька стовпців, тоді воно є обмеженням цілісності на рівні таблиці.

Первинний ключ з декількох стовпців:

[PRIMARY KEY (<ім'я_стовпця> {[, <ім'я_стовпця>] ...})] Умова перевірки на допустимість значення:

CHECK (<булевий вираз>)

Тут <булевий вираз> допускає посилання на декілька стовпців таблиці.

• Якщо в різних стовпцях або таблицях зустрічаються однакові обмеження, то зручно ввести пойменовані правила, які називаються обмеженнями на рівні доменів. Ці правила аналогічні поняттю домена на в теорії РБД і близькі до поняття «користувальницький тип даних» у мовах програмування. Синтаксис визначення іменованого обмеження наступний.

CONSTRAINT <ім’я_обмеження> <тип_обмеження> <вираз>

Тип обмеження може бути може бути одним з NOT NULL,

UNIQUE, DEFAULT, PRIMARY KEY, FOREING KEY, CHECK.

Наприкінці наведемо опис структури таблиць БД Успішність.

CREATE SCHEMA Успішність_Студентів (CONSTRAINT ID_TYPE CHARACTER (3)

CHECK (VALUE IS NOT NULL) CONSTRAINT MARK_TYPE INT (2) DEFAULT 2

CHECK (@ MARK_TYPE> 1 AND @ MARK_TYPE <= 5)

CREATE TABLE СТУДЕНТ (ID_Stud ID_TYPE PRIMARY KEY,

СПрізв CHARACTER (25) DEFAULT 'Іваненко І.І.',

САдреса CHARACTER (30),

Консультант CHARACTER (3) DEFAULT IS NULL

)

CREATE TABLE КУРС (

ID_Subj ID_TYPE PRIMARY KEY,

Найменування CHARACTER (20) DEFAULT 'Бази даних' CHECK (Найменування IN ('Вища математика', 'Бази даних', 'Фізика'),

)

CREATE TABLE Успішіність (ID_Stud ID_TYPE,

ID_Subj ID_TYPE,

Семестр INT (2) DEFAULT 1

CHECK (@ Семестр> = 1 AND Семестр <= 11),

Оцінка MARK_TYPE,

PRIMARY KEY (ID_Stud, ID_Subj, Семестр) FORIENG KEY ID_Stud REFERENCES СТУДЕНТ

ON DELETE CASCADE

FORIENG KEY ID_Subj REFERENCES КУРС

ON DELETE CASCADE

))

У таблиці СТУДЕНТ для поля Консультант не описано обмеження рекурсивного зовнішнього ключа, оскільки на момент створення таблиці СТУДЕНТ ця таблиця ще не існує. Оголосити це обмеження можна пізніше за допомогою оператора ALTER TABLE.

Зміна структури таблиць

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

Синтаксис:

ALTER TABLE <ім'я_таблиці>

{ADD <визначення_стовпця> |

ALTER <ім'я_стовпця> {SET DEFAULT <значення> |

DROP DEFAULT} | DROP <ім'я_стовпця> {CASCADE | RESTRICT} |

ADD {<визначення первинного ключа>} |

<визначення зовнішнього ключа> |

<умова унікальності даних> |

<умова перевірки>} | DROP CONSRAINT ім’я_умови {CASCADE | RESTRICT}}

В якості прикладу додамо рекурсивний зовнішній ключ в таблицю СТУДЕНТ.

ALTER TABLE СТУДЕНТ

ADD CONSTRAINT FK_Kons FOREING KEY (Консультант) REFERENCES СТУДЕНТ (ID_Stud) ON DELETE SET NULL