- •1. Короткі відомості про моделі даних
- •1.1. Реляційна алгебра
- •1.2. Основні поняття та нормалізація відношень реляційної бази даних
- •Сутність та особливості мови запитів sql
- •2.1. Структурована мова запитів
- •2.2. Особливості використання мовиSql
- •Оператори та синтаксис мови sql
- •Синтаксис sql
- •3.2.Ключові слова.
- •3.3. Створення sql-інструкцій (на стадії ознайомлення)
- •3.4. Групи sql – інструкцій
- •3.5. Методи виконання sql-операторів
- •4. Принципи застосування мови sql в системі управління базами данних Access
- •4.1. Використання інструкцій sql у об’єктах Access
- •4.1.2. Створення запитів sql
- •5. Використання sql для розробки запитів в Access
- •5.1. Звичайні вибірки sql та вибірки з умовою для однотабличних запитів
- •Багатотабличні запити
- •5.2.2. Запити з операціями з’єднання Таблиць
- •5.3. Додатові відомості про зв’язування таблиць
- •Вибранні питання роботи з операторами sql, що змінюють структуру бази даних
- •6.1. Створення таблиці
- •Типи даних
- •6.2. Спеціальні запити sql об’єднання
- •6.3. Короткі відомости про використання Ассеss як сервераDde
- •7. Лабораторні роботи
- •7.1.Лабораторна робота №1 Тема «Використання інструкцій sql при розробці об’єктів в системах управління базами данних ассess
- •Лабораторне завдання:
- •7.2. Лабораторна робота № 2
- •Лабораторне завдання №2
- •Хід виконання роботи:
- •7.3. Лабораторна робота № 3 Тема: Використання мови sql для розробки параметричних запитів та різних варіантів простих вибірок з фільтрацією і сортуванням.
- •Лабораторне завдання №3
- •7.4. Лабораторна робота № 4 Тема: Використання мови sql для розробки запитів на пошук відсутніх даних про об’єкти предметної області та вибірки за зразком
- •Лабораторне завдання №4
- •7.5. Лабораторна робота № 5 Тема: Запити з агрегованими функціями
- •Лабораторне завдання №5
- •Індивідуальні завдання
- •7.6. Лабораторна робота № 6 Тема: Використання мови sql для розробки багатотабличних запитів
- •Лабораторне завдання №6
- •7.7. Лабораторна робота № 7 Тема: Використання мови sql для створення структури нової таблицї бази даних
- •Лабораторне завдання №7
- •8. Питання до контролю
- •Додаток а. Приклад реляційної моделі даних
- •Додаток б. Послідовні нормальні форми та вимоги до них
- •Додаток в.Приклади використання інструкцій sql для організаціїDde із інших додатків
- •Контрольні питання
- •Література
Додаток б. Послідовні нормальні форми та вимоги до них
Мета нормалізації відношень – якісне проектування бази даних, що включає, перш за все, відсутність збиткових неключових даних.
Якщо для підвищення якості проектування бази даних потрібно здійснити нормалізацію на більш високому рівні, то провадиться декомпозиція невідповідної таблиці (Таблиця розбивається на дві чи три таблиці). На кожному наступному щабелі нормалізації таблиці відповідають усім вимогам попередніх щабелів.
Щабелі нормалізації приведемо у вигляді наступної таблиці:
Таблиця Б.1.
Нормалізація відношень реляційних баз даних
Щабелі нормалізації |
Обмеження |
Примітка |
Таблиця приведена до 1-ї нормалізованої форми (1NF) |
Усі атрибути таблиці –прості (атомарні, неподільні) |
Поле ПІБ можна розглядати як подільне або як атомарне залежно від вимог задачі до даних про співробітників. |
Таблиця приведена до 2-ї нормалізованої форми (2NF) |
|
Якщо неключовий елемент залежить від складного ключа, який не вказано в таблиці, то така Таблиця не відповідає умовам 2NF |
Таблиця приведена до 3-ї нормалізованої форми (1NF) |
|
Якщо у відношенні є атрибути А, В, С, такі, що: атрибут С залежить від атрибута В, і атрибут В залежить від атрибута А, то атрибут С транзитивно залежить від атрибута А |
Таблиця приведена до нормалізованої форми Бойса-Кодда (NFБК) |
|
|
Таблиця приведена до 4-ї нормалізованої форми (1NF) |
|
Якщо немає функціональних залежностей, то усі поля – ключові. |
Таблиця приведена до 5-ї нормалізованої форми (5NF) |
Будь-яка залежність по з’єднанню визначається ключами |
Залежність по з’єднанню дозволяє розбити відношення на три і більше Таблиць. |
Охарактеризуємо якість проектування бази дани, що відповідає прикладу , див. Додаток А.
Зауважимо, що завжди потрібно виважено відноситись до структури бази даних, зваживши на задачі, для вирішення яких, дані зберігаються у базі даних.
ФактичноТаблиця 2 (Несправності) не відповідає 1NF Атрибут Контролер може бути подільним, але можна вважати, що ініціали не відділяються і не вибираються із інших атрибутів, окрім поля Контролер. Тому можна вважати, що усі таблиці приведені до першої нориальної форми (1NF).
Структурабази даних представлено схемою 1, див Рис Б.1.
Рис Б.1. Початкова база даних прикладу додатка А.
Нехай за умовою задачі поле Довідка повинно зберігати дату тестування. Тоді у структурі таблиці Результати тестування потрібно вказати тип даних Дата/время. Деталізуючи умови проведення тестувань авто (згідно даних Таблиць), слід зазначити, що тестування організовані таким чином, що кожна несправність тестується певним контролером і оплата за тестування залежить від рівня кваліфікації спеціаліста - контролера. Допускається, що один контролер може проводити тестування різних несправностей за різною оплатою.
Виходячи з такого аналізу та розглядаючи таблицю Довідник несправностей зазначаємо:
Для вказаної таблиці ключовим полем є поле Код_несправності, усі інші поля - неключові. Поля Назва несправності та Контролер функціонально залежать від ключа. Але поле Ціна тестування залежить не тільки від ключа але і від умов контракту того чи іншого контролера. Зазначимо, що головним недоліками вказаної структури бази даних, є те, що:
потрібно повторювати прізвище контролера;
у разі зміни штатного розкладу потрібно вносити зміни у таблицю Довідник несправностей.
Отже якість проектування бази даних низька, хоча для ряду найпростіших задач така структура може бути умовно прийнятною, але небажаною, бо “термін життя” такої бази дуже малий. Аналізуючи структуру бази даних, зазначимо, для того, щоб зробити зміни у структурі бази даних та введення даних у таблиці більш зручними (підвищити якість проектування) можна виконати декомпозицію таблиціДовідник несправностей, замінивши її на дві, див. Рис. Б.2.
Рис. Б.2. Декомпозиція таблиці Довідник даних
Більш зручна робота при зміні та введені даних досягається лише тоді, коли поле Контролер є полем зі списком.
Технологія створення поля зі списком нескладна і сприяє забезпеченню умов цілосності даних, та до деякої міри автоматизує процес створення структури бази даних. Якщо записів у Таблицях бази даних мало і їх обсяги не впливають на швидкодію роботи з даними, то схему, представлену на Рис. Б.2. можна прийняти, знаючи обмеження і недосконалість розробленої схеми даних . Така недосконалість проектування бази даних полягає у тому, що таблиця Довідник несправностей має неключове поле Ціна тестування, значення якого залежить не тільки від коду несправності але і від поля Контролер. Це означає, що якщо ми контролера можемо обирати зі списку, то поле Ціна тестування повністю корегується вручну. Хоча його теж можна вводити як поле зі списком, причому список цін зберігається у окремому стовпчику, а не в таблиці.
Вкажемо спосіб, коли із поля зі списком, який зберігається у таблиці Контролер можна обирати код, а в таблиці фіксуємо відповідні прізвище та ініціали із поля Пр. У таких випадках зв’язування Таблиць відбувається за полем Код контролера, але першим у стовпчиках підстановки обирається поле Пр, для якого значення властивості Подпись є Контролер.
Щоб якість проектування була більш високою, потрібно підвищити щабель нормалізації. Для цього вводимо у розгляд ще один об’єкт предметної області – Контракт. Цей об’єкт інформаційно може бути представлений таблицею, яка має у своєму складі поля
Код контракта
Код контролера
Код несправності
Тоді у таблиці Довідник несправностей проводяться наступні декомпозиційні дії: таблицю Довідник несправностей замінюємо наступними трьома Таблицями:
Таблиця |
Структура таблиці |
Властивості атрибутів |
Довідник несправностей |
Код несправності |
Первинний ключ |
Назва несправності |
Текстове поле, неключовий атрибут | |
Код контракта |
Первинний ключ | |
Контракти |
Код контракта |
Первинний ключ |
Код несправності |
Зовнішній ключ | |
Код контролера |
Зовнішній ключ | |
Ціна тестування |
Числове поле. Неключовий атрибут | |
Контролер |
Код контролера |
Первинний ключ |
Пр (Прізвище та ініціали контролера) |
Текстове поле, Неключовий атрибут |
Таким чином, при умові, що для тестування кожної несправності заключається новий контракт (виконавець підписує контракт на кожен вид тестування окремо) структура бази даних складається із 5-ти Таблиць.
Але такий проект не є досконалим, незручно працювати з контрактами. Проводимо аналіз далі. Якщо в одному контракті фіксувати усі несправності, які проводить контролер, то таблицю Контракт потрібно декомпозувати на дві- Контракти та Умови контракту. В таблицю Контракти включити атрибути- код контракта, Код контролера, дата контракта. У таблицю Умови контракта включити поля- Код контрака, Код несправності, Ціна. Встановлюємо ключі та властивості полів. Записуємо концептуальну модель та будуємо наступний варіант схеми даних. Доводимо таблиці до найбільш високого із можливих рівнів нормалізації.
Увага!!! Проектуючи базу даних, необхідно відразу продумувати структуру бази даних з найбільш високим рівнем нормалізації відношень. Мета даного додатку проілюструвати як підвищується якість проектування бази даних на стадії розробки логічної моделі даних та можливості мови для створення та, у разі необхідност, модифікаціїіснуючої структури бази даних.