- •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. Експертні системи та бази знань. Призначення експертних систем. Структура експертних систем. Представлення знань в експертних системах. Поняття експертної системи. Властивості знань.
12. Друга нормальна форма (2нф).
Друга нормальна форма (2НФ, 2NF) — нормальна форма використовна нормалізації баз даних. 2НФ первісно була визначена Едгаром Коддом в 1971.[1] Щоб бути в другій нормальній формі, таблиця, що знаходиться в першій нормальній формі, має відповідати додатковим критеріям. А саме: 1НФ таблиця знаходиться в 2НФ тоді і тільки тоді, коли для будь-якого потенційного ключа K і будь-якого атрибута A, який не є частиною потенційного ключа, A залежить саме від цілого потенційного ключа, а не від його частини.
Трошки більш формально: 1NF таблиця знаходиться в 2НФ тоді і тільки тоді, коли всі її неключові атрибути функціонально залежні від цілих потенційних ключів.
Зауважимо, що коли 1НФ таблиця не має складних потенційних ключів (таких, що складаються більш ніж з одного атрибута), тоді таблиця автоматично знаходиться в 2НФ.
Друга нормальна форма (2НФ, 2NF) вимагає, аби дані, що зберігаються в таблицях із композитним ключем не залежали лише від частини ключа:
Схема бази даних повинна відповідати вимогам першої нормальної форми.
Дані, що повторно з'являються в декількох рядках виносяться в окремі таблиці.
Наступний важливий крок в процесі нормалізації полягає у знищенні всіх неключових атрибуті, які залежать лише від частини первинного ключа. Такі атрибути називаються частково залежними. Неключові атрибути містять в собі інформацію про дану сутність предметної області, але не ідентифікують її унікальним чином.
На цьому етапі досягається повна функціональна залежність усіх атрибутів від ключа за рахунок розбиття даних на кілька таблиць. До основних аномалій відноситься аномалія дублювання даних. Можливе дублювання даних виявляється шляхом встановлення тих атрибутів, які однозначно залежать від інших атрибутів , що не є ключовими (транзитивний зв”язок). Для усунення вказаного недоліку модель приводиться до третьої нормальної форми.
13.Третя нормальна форма (3НФ) — нормальна форма використовна в нормалізації баз даних. 3НФ первісно була визначенаЕдгаром Коддомв 1971.[1]Визначення: Кодд каже, що таблиця знаходиться в 3НФ тоді і тільки тоді, коли виконуються наступні умови:
ВідношенняR (таблиця) знаходиться в2НФ
Кожен неключовий атрибут відношення R нетранзитивно залежить (тобто залежить безпосередньо) від кожного потенційного ключав R.
Неключовий атрибут R — атрибут, що не є частиною будь-якого потенційного ключа.[2] Транзитивною називають таку функціональну залежність, в якійX→ Z (X визначає Z) непрямо, а через X → Y і Y → Z (і невірно, що Y → X).[3]
Інше визначення 3НФ тотожне до визначення Кодда, дав Карло Заніоло в 1982. Це визначення стверджує, що таблиця в 3НФ тоді і тільки тоді, коли для кожної її функціональної залежностіX → A, вірна хочаб одна з наступних умов:
X містить A (тоді X → A це тривіальна функціональна залежність), або
X це суперключ, або
A-X, різниця множин A і X це ключовий атрибут (тобто, A-X міститься в потенційному ключі)
Третя нормальна форма(3НФ, 3NF) вимагає, аби дані в таблиці залежали винятково від основного ключа:
Схема бази данихповинна відповідати всім вимогам другої нормальної форми.
Будь-яке поле, що залежить від основного ключа та від будь-якого іншого поля, має виноситись в окрему таблицю.
Щоб привести базу до третьої нормальної форми, треба:
1. Визначити, в яких полях яких таблиць мається взаємозалежність. Як щойно йшлося, поля, які залежать більше один від одного (як місто від штату), ніж від ряду в цілому. У базі форуму такої проблеми немає. Поглянувши на таблицю повідомлень, побачите, що кожен заголовок, кожне тіло повідомлення ставиться до свого message ID.
2. Створіть відповідні таблиці. Якщо є проблемний стовпець в кроці 1, створюйте роздільні таблиці для нього. Як міста та штати, в прикладі з клієнтами.
3. Створіть або виділіть первинні ключі. Кожна таблиця повинна мати первинний ключ. Для прикладу з клієнтами це будуть city ID і state ID.
4. Створіть необхідні зовнішні ключі, які утворюють будь-яке з відносин. У нашому прикладі потрібно додати state ID в таблицю міст і city ID в таблицю клієнтів. Це зв'яже кожного клієнта з містом та штатом, де вони живуть.