- •1.Основні поняття. Бази даних, банк даних, інформаційна система. Традиційні файлові системи. Бази даних. Системи управління базами даних (субд). Компоненти банку даних.
- •2.Розподіл обов'язків в системах з базами даних. Історія розвитку субд. Класифікація банків даних. Переваги та недоліки субд.
- •3.Середовище бази даних. Трьохрівнева архітектура ansi-spark. Зовнішній рівень. Концептуальний рівень.
- •4.Внутрішній рівень. Мови баз даних. Моделі даних і концептуальне моделювання. Функції субд. Компоненти субд.
- •5.Етап концептуального проектування. Основні поняття концептуального проектування. Концептуальне проектування. Об'єкти і їх властивості. Взаємовідношення об'єктів.
- •6.Слабкі та складні сутності. Проведення етапу концептуального проектування субд.
- •8. Реляційна модель бази даних. Історія розвитку реляційної моделі. Структура реляційних даних. Відношення в базі та їх властивості. Типи даних.
- •9. Нормалізація відношень баз даних. Нормальні форми. Цілі нормалізації. Надлишковість даних і аномалії оновлення.
- •Шоста нормальна форма.Таблиця знаходиться у 6nf, якщо вона знаходиться у 5nf та задовольняє вимозі відсутності нетривіальних залежностей. Зазвичай 6nf ототожнюють з dknf.
- •10. Аномалії вставки. Аномалії вилучення.
- •11. Функціональні залежності. Процес нормалізації. Перша нормальна форма (1нф)
- •12. Друга нормальна форма (2нф).
- •14. Нормальна форма Бойса — Кодда
- •Null-значення
- •19 Мова sql. Формат sql-операторів. Маніпулювання даними
- •1. Формат sql-операторів
- •2. Маніпулювання даними
- •2.1. Вибірка всіх рядків
- •20. Вибірка всіх рядків. Вибірка рядків (речення where). Сортування результату (фраза order by).
- •2.2. Вибірка рядків (речення where)
- •2.3. Сортування результату (фраза order by)
- •21. Використання узагальнюючих функцій мови sql
- •22. Групування результатів (фраза Group), Обмеження на виконання групування (фраза having)
- •2.6. Обмеження на виконання групування (фраза having)
- •23. Підзапити
- •25. Особливості і синтаксис речень модифікації. Речення delete. Видалення одиничного запису. Видалення множини записів. Видалення з вкладеним підзапитом.
- •26 .Речення insert.
- •1. Вставка єдиною записи в таблицю
- •2. Вставка безлічі записів
- •1. Оновлення єдиною записи
- •2. Оновлення безлічі записів
- •3. Оновлення з підзапитом
- •28.Етап фізичного проектування. Основні структури зберігання та методи доступу до даних. Основні поняття. Невпорядковані послідовні файли.
- •29. Впорядковані послідовні файли. Хешовані файли. Індексно-послідовні файли.
- •31. Розподілені бази даних. Концепція розподілених баз даних. Розподілені транзакції. Реплікація даних. Розподілена оптимізація запитів.
- •32. Експертні системи та бази знань. Призначення експертних систем. Структура експертних систем. Представлення знань в експертних системах. Поняття експертної системи. Властивості знань.
26 .Речення insert.
1. Вставка єдиною записи в таблицю
Додати в таблицю Страви блюдо:
Шашлик (БЛ - 34, Блюдо - Шашлик, В - Г, Основа - М'ясо, Вихід - 150)
при невідомої поки трудомісткості приготування цієї страви.
INSERT
INTO Страви (БЛ, Блюдо, В, Основа, Вихід)
VALUES (34, 'Шашлик', 'Г', 'М'ясо', 150);
Створюється новий запис для страви з номером 34, з невизначеним значенням в стовпці Праця.
Порядок полів у INSERT не обов'язково повинен збігатися з порядком полів, в якому вони визначалися при створенні таблиці. Цілком припустима і така версія попереднього речення:
INSERT
INTO Страви (Основа, В, Страва, БЛ, Вихід)
VALUES ('М'ясо', 'Г', 'Шашлик', 34, 150);
При відомої трудомісткості приготування шашлику (наприклад, 5 коп) відомості про нього можна ввести за допомогою укороченого пропозиції:
INSERT
INTO Страви
VALUES (34, 'Шашлик', 'Г', 'М'ясо', 150, 5);
в якому повинен дотримуватися строгий порядок перерахування вводятьсязначень, оскільки, не маючи переліку завантажуються стовп-цов, СУБД може використовувати лише перелік, який визначений при створенні модифікується таблиці.
У попередніх прикладах проводилася модифікація стрижневий сутності, тобто таблиці з первинним ключем БЛ (см.п.2.4 в літературі [2]). Майже всі СУБД мають механізми для запобігання вводити не унікального первинного ключа, наприклад, введення "Шашлика" під номером, меншим 34. А як бути з асоціаціями або іншими таблицями, що містять зовнішні ключі?
Нехай, наприклад, знадобилося додати в рецепт страви Салат літній (БЛ = 1) небагато (15 г) лука (ПР = 10), і ми скористалися пропозицією
INSERT
INTO Склад (БЛ, ПР, Вага)
VALUES (1, 10, 15);
Подібно операції DELETE операція INSERT може порушити несуперечливість бази даних. Якщо не вжити спеціальних заходів, то СУБД не перевіряє, чи є в таблиці Страви блюдо з первинним ключем БЛ = 1 і в таблиці Продукти - продукт з первинним ключем ПР = 10. Відсутність будь-якого з цих значень породить протиріччя: в базі з'явиться посилання на неіснуючу запис. Проблеми, що виникають при використанні зовнішніх ключів, детально розглянуті в літературі, а тут отме-тім, що всі "пристойні" СУБД мають механізми для запобігання утворення-рощення введення записів зі значеннями зовнішніх ключів, отсутст-чих серед значень відповідних первинних ключів.
2. Вставка безлічі записів
Створити тимчасову таблицю К_меню, що містить калорійність і вартість усіх страв, які можна приготувати з наявних продуктів. (Ця таблиця буде використовуватися шеф-кухарем для складання меню на наступний день.)
Для створення опису тимчасової таблиці можна, наприклад, скористатися пропозицією CREATE TABLE (см.п.5.2)
CREATE TABLE К_меню
(Вид CHAR (10),
Блюдо CHAR (60),
Калор_блюда INTEGER,
Стоім_блюда REAL);
а для її завантаження даними - пропозиція INSERT з вкладеним підзапитах:
INSERT
INTO К_меню
SELECT Вид, Страва,
INT (SUM (((Білки + Углєв) * 4.1 + Жири * 9.3) * Вага / 1000)),
(SUM (Вартість / К_во * Вага / 1000) + MIN (Праця / 100))
FROM Блюда, Від_блюд, Склад, Продукти, Наявність
WHERE Блюда.БЛ = Состав.БЛ
AND Состав.ПР = Продукти.ПР
AND Состав.ПР = Налічіе.ПР
AND Блюда.В = Від_блюд.В
AND БЛ NOT IN
(SELECT БЛ
FROM Склад
WHERE ПР IN
(SELECT ПР
FROM Наявність
WHERE К_во = 0))
GROUP BY Вид, Блюдо
ORDER BY Вид, 3;
У цьому запиті пропозицію SELECT виконується так само, як звичайно (див. Опис запиту в п.3.6), але результат не виводиться на екран, а копіюється в таблицю К_меню. Тепер з цією копією можна працювати як зі звичайною базової таблицею (Страви, Про-дукти, ...), тобто вибирати з неї Данн на екран або принтер, оновлювати в ній дані і т.п. Ніяка з цих операцій не буде робити впливу на вихідні дані (наприклад, зміна в ній назви страви Салат літній на Салат весняний не приведе до подібного зміни в таблиці Страви, де збережеться стара назва). Так як це може привести до протиріч, то подібні тимчасові таблиці знищують після їх використання. Тому програма, яка обслуговує шеф-кухаря, повинна виконувати пропозицію DROP TABLE К_меню після того, як буде закінчено складання меню.
27. Речення UPDATE. Оновлення одного запису. Оновлення множини записів. Оновлення з підзапитом.