Lecture is dedicated to amazing part of SQL called DDL

1. Мова визначення даних
DDL (Data Definition Language)
SQL

2. За допомогою DDL-запитів можна:
1) визначити структуру нового домену і
створити його;
2) визначити структуру нової таблиці та
створити її;
3) змінити визначення існуючої таблиці;
4)визначити віртуальну таблицю
(представлення, курсор);
5) створити індекси для прискорення доступу
до таблиць.

3. Ядро визначення:
CREATE – створення об’єкту
ALTER – зміна структури об’єкту.
DROP – знищення об’єкту
RECREATE – створити новий об’єкт під старим
іменем

4. Створення БД
1. Створити порожній файл БД і виконати
команду з'єднання з базою.
2. Створити необхідні домени.
3. Створити користувальницькі таблиці.
4. Заповнити даними створені таблиці
користувача.

5. Домен
поіменована множина скалярних значень одного
типу
Мета - забезпечити можливість один раз визначити
елементарну специфікацію типу даних, а потім
використовувати її одночасно для декількох
стовпців в декількох базових таблицях.
Наприклад:
TMonth (місяць) - множина всіх можливих номерів
місяців (від 1 до 12)

6. Домени

7. Обмеження домену

8. Приклади оголошення доменів

9. Зміна визначення домену

10. Знищення домену
Домен не буде знищений, якщо на нього є посилання,
тобто існують таблиці зі стовпцями, визначеними на
цьому домені.
Наприклад
… column BOOLEAN is used in table REQUEST (local name EXECUTED) and cannot be
dropped …

11. Створення таблиць
Приклад конструкції

12. Приклад створення таблиць

13. Визначення обмежень стовпця
Приклад

14. Умови перевірки вмісту стовпця
де

15. де
Умови перевірки вмісту стовпця

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

17. Приклади обмежень
при визначенні таблиць
якщо значення, що додаються в таблицю NachislSumma, не
будуть задовольняти зазначеним умовам перевірки, то
виникне помилка з SQLCODE = -297

18. Приклади обмежень
при визначенні таблиць

19. Визначення обмежень на таблицю
Існує три види обмежень базової таблиці:
• обмеження первинного ключа;
• посилальне обмеження (обмеження зовнішнього ключа);
• обмеження «умови перевірки».

20. Визначення первинного складеного
ключа

21. Визначення первинного ключа

22. Обмеження на таблицю

23. Знищення таблиці
Не можна знищити таблицю :
• Якщо на її стовпці посилаються зовнішні ключі інших таблиць;
• Якщо вона використовується іншими об'єктами БД (наприклад, поданням);
• Якщо вона визначена в поточній транзакції, і на момент знищення ще не є
завершеною.
При спробі видалити таблицю, яка використовується, виводиться
повідомлення про помилку SQLCODE = -607 і коментарем, що видаляється
об'єкт, який перебуває у використанні.

24. Зміна визначення таблиці
Створену запитом CREATE TABLE базову таблицю можна змінити
запитом ALTER TABLE. Він підтримує такі зміни:
• Додавання нових стовпців;
• Задання нового обмеження цілісності для базової таблиці;
• Визначення нового імені для існуючого стовпця;
• Зміна типу даних для існуючого стовпця;
• Зміни порядкового номера стовпця в таблиці;
• Визначення для існуючого стовпця нового значення за
замовчуванням (замінює попереднє значення, якщо воно було);
• Знищення для стовпця існуючого значення за замовчуванням;
• Знищення існуючого стовпця;
• Знищення існуючого обмеження цілісності для базової таблиці.

25. Зміна визначення таблиці
де

26. Зміна визначення таблиці
де

27. Приклади зміни визначення таблиці
або

28. Зміна імені та типу стовпця
але
Але …New size specified for column PHONE must be at least 15 characters

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

30. Приклад зміни значення за замовчуванням
Після запиту додається новий запис
До (всі поля, крім number за замовчуванням)

31. Знищення стовпця та обмеження
Знищення стовпця запитом ALTER TABLE може завершитися невдало,
якщо:
• Знищується стовпець, який є частиною обмежень UNIQUE, PRIMARY
• KEY або FOREIGN KEY;
• Знищується стовпець, що використовується в реченні CHECK;
• Знищується стовпець, що є частиною виразу, наприклад, в конструкції
COMPUTED [BY] (<вираз>) (при створенні таблиці);
• На стовпець, що знищується посилається інший об'єкт БД, наприклад
представлення.

32. Індекси

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

34. Індекси. Проблеми.
• Read – Write
• Пам’ять
• Binary field index
• Забагато індексів

35. Створення індексів

36. Створення індексів. Використання
конструкцій та обмежень

37. Деактивація/активація
та знищення індексу

38. Магія зовнішніх ключів
- Для чого?
- Чи повинен бути завжди
індексом?

39. Магія запитів.
-SELECT *
- LIKE “%ЩОСЬ%”
- <>
- Алгоритмічні операції в WHERE

40. Стиль SQL. Імена та елементи даних
• Слідкуйте за
довжиною
• Не
використовуйте
спецсимволи
• Відпрацюйте
суворі правила
використання
великих
(прописних) літер
— Когда я был маленьким, у нас было три
кошки.
— И как их звали?
— Кошка, кошка и кошка.
— Ерунда какая-то. Как же вы их различали?
— А какая разница? Кошки все равно на имена
не откликаются!

41. Стиль SQL. Імена та елементи даних
• Створюйте імена згідно стандарту ISO-11179
(http://pueblo.lbl.gov/~olken/X3L8/drafts/draft.docs.html
http://lists.oasis-open.org/archives/ubl-ndrsc/200111/msg00005.html )
Скалярний елемент даних повинен відповідати наступним вимогам:
1. Він унікальний (у межах свого словника даних).
2. Він названий з використанням однини.
3. В імені пояснюється, чим є елемент, а не чим він не є.
4. Ім'я читається, як описова фраза.
5. Ім'я містить тільки загальноприйняті скорочення.
6. Ім'я не містить вкладених визначень інших елементів даних або
понять.
7. Таблиці, набори та інші збірні елементи іменуються
узагальнюючими поняттями у множині.
8. В імені процедури міститься дієслово.
9. В ім'я копії (псевдоніму) таблиці включено ім'я базової таблиці і
причина створення копії.

42. Стиль SQL. Імена та елементи даних
• Рівні абстрагування (ISO-3166 “Codes for the
Representation of Names of Countries”)
trading_partner_country_name
• Уникайте описових префіксів
tbl- або vw - … Orders.ID=OrderlD … <тип>+назва=forder_nbr … РК_ або FK_
• Розробіть стандартну систему суфіксів
_id – унікальний в межах схеми (але не <ім’я таблиці>_id)
_dt … _nbr … _ nm … _cd … _size … _tot … _seq … _tally … _cat … _class … _type
міра_висоти_дерева
класвластивість
спосіб
представлення

43. Стиль SQL. Імена та елементи даних
• Імена таблиць і представлення повинні підлягати
стандартам і подані у вигляді іменників множини.
• Імена кореляцій (псевдонімів) підпорядковані тим же
правилам, що й інші імена:
salary + commission AS total_pay
SELECT ... FROM Personnel AS Management, Personnel AS Workers
• Імена таблиць-відносин повинні бути
загальноприйнятими, зрозумілими термінами:
family = MaleFemale, але виключення – конкатенація
• В імена об'єктів доступу до метаданих схеми можна
включати структурну інформацію.

44. Стиль SQL. Помилки в іменах
• Уникайте невиразних імен:
date … name …або протиріччя - type_code_id
• Уникайте імен, які змінюються від місця до місця
(один і той самий атрибут має різне ім’я в різних таблицях)
• Не використовуйте нестандартні фізичні покажчики
IDENTITY, GUID, ROWID

45. Стиль SQL. DDL
• Правильно розміщуйте значення за замовчуванням
(тип даних … конструкція DEFAULT значення за замовчуванням
… конструкція NOT NULL) .
• Тип значення за замовчуванням повинен збігатися з
типом даних стовпця.
• Виділяйте відступами посилальні обмеження і дії
ON DELETE ON UPDATE
• Давайте імена обмеженням (CONSTRAINT award_point_range)
• Розміщуйте перевірки СНЕСК () поруч з елементом,
який перевіряється.
• Використовуйте обмеження діапазону числових
значень (>=0).

46. Стиль SQL. DDL
• Використовуйте для рядкових значень обмеження LIKE.
• Пам'ятайте, що параметрам часу притаманна тривалість
(DEFAULT CURRENT_TIMESTAMP)
• Намагайтеся не використовувати типи даних REAL і FLOAT
(NUMERIC і DECIMAL)
• Обмеження, що охоплюють кілька стовпців, розміщуйте
максимально близько до цих стовпців
CREATE TABLE Prizes
(...
birth_date DATE NOT NULL,
prize_date DATE NOT NULL,
CONSTRAINT over_18_to_win
CHECK (birth_date + INTERVAL 18 YEARS >= prize_date),
...);

47. Стиль SQL. DDL
• Розміщуйте обмеження СНЕСК () табличного рівня в кінці
оголошення таблиці
CREATE TABLE Prizes
(...
CONSTRAINT only_5_prizes_each_winner
CHECK (NOT EXISTS (SELECT *
FROM Prizes AS P1
GROUP BY P1.contestant_id HAVING COUNT(*) > 5
)
),
CONSTRAINT nojnissing_ticket_nbrs
CHECK ((SELECT MAX(ticket_nbr) - MIN(ticket_nbr) + 1
FROM Prizes AS P1)
= (SELECT COUNT(ticketjibr)
FROM Prizes AS P1)
);

48. Стиль SQL. DDL
• Використовуйте для багатотабличних обмежень вираз
CREATE ASSERTION
CREATE ASSERTION enough_money_to_pay_prizes
AS
CHECK ((SELECT SUM(pnze_money)
FROM Prizes AS P1)
<= (SELECT SUM(cash_on_hand)
FROM Bank));
• Використовуйте для кожної перевірки власне
обмеження СНЕСК ().

49. Стиль SQL. DDL
• Якщо у таблиці немає ключа, це не таблиця
1. Природний ключ - набір атрибутів з таблиці і діє як унікальний ідентифікатор. Він
видимий користувачу.
2. Штучний ключ - додатковий атрибут, спеціально введений в таблицю для
використання в якості ключа. Він видний користувачеві, не пов'язаний безпосередньо з
реальною моделлю даних, але може бути перевірений сам по собі - по синтаксису, по
контрольному розряду.
3. Явний фізичний покажчик не заснований на моделі даних і доступний
користувачу. Передбачити або перевірити його значення не можна. Система обчислює
його, грунтуючись на фізичному збереженні даних. Приклад: поля IDENTITY в сімействі
T-SQL, інші нестандартні нереляційні засоби автонумерації, покажчики, засновані на
номерах циліндра і доріжках жорсткого диска в Oracle.
4. Системний сурогатний ключ генерується системою для заміщення реального
ключа на основі атрибутів з таблиці; користувачеві недоступний. Приклад: алгоритми
хешування. Сурогатні ключі підтримуються системою.

50. Стиль SQL. DDL

51. Стиль SQL. DDL
• Автонумерація не може використовуватися в
якості реляційного ключа
CREATE Drivers
(driver_id AUTONUMBER NOT NULL PRIMARY KEY,
ssn CHAR(9) NOT NULL REFERENCES Personnel(ssn),
vin CHAR(17) NOT NULL REFERENCES Motorpool(vin));
CREATE Drivers
(ssn CHAR(9) NOT NULL REFERENCES Personnel(ssn),
vin CHAR(17) NOT NULL REFERENCES Motorpool(vin),
PRIMARY KEY (ssn, vin));

52. Стиль SQL. DDL
• Розділення атрибутів за стовпцями
CREATE TABLE Player_Stats
(league_id INTEGER NOT NULL,
player_id INTEGER NOT NULL, -- внутрішня нумерація гравців
game_id INTEGER NOT NULL,
stat_field_id CHAR(20) NOT NULL, -- домен для стовпця number_value
number_value INTEGER NULL…
CREATE TABLE Player_Stats
(league_id INTEGER NOT NULL,
player_nbr INTEGER NOT NULL,
FOREIGN KEY (league_id, player_nbr) REFERENCES Players (league_id, player_nbr) ON
UPDATE CASCADE,
game_id INTEGER NOT NULL REFERENCES Games(game_id) ON UPDATE CASCADE,
completions INTEGER DEFAULT 0 NOT NULL CHECK (completions >= 0),
yards INTEGER DEFAULT 0 NOT NULL CHECK (yards >= 0),
PRIMARY KEY (league_id, player_nbr, game_id));

53. Стиль SQL. DDL
• Розділення атрибутів за рядками
CREATE TABLE Events
(event_name CHAR(15) NOT NULL,
event.time TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
...);
CREATE TABLE Events
(event_name CHAR(15) NOT NULL,
event_start_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
event_finish_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
CHECK (event_start_time < event_finish_time),
..);
INSERT INTO Events
VALUES ('running', '2005-10-01 12:00:00', '2005-10-01 12:15:13');

54. Дякую за увагу