З апитання для самоконтролю:

1. Що являє собою зовнішній рівень?

2. Що розуміють під інфологічною моделлю даних?

3. В чому сутність інфологічного проектування?

4. Що розуміють під датологічною моделлю даних?

5. Що являє собою внутрішній рівень?

Форми контролю:

Поточний -перевірка конспектів, усне опитування на лекції.

Підсумковий - підсумкова контрольна робота, екзамен.

Самостійна робота № 9 Тема: Методи створення оптимальної моделі баз даних

Мета: самостійно вивчити матеріал, що не розгядався на лекції. Познайомитись із теорією нормалізації відношень та послідовністю проектування баз даних

Література: Ситник В.Ф., Писаревська Т.А., Єрьоміна Н.В., Краєва О.С. Основи інформаційних систем: Навч. посібник / За ред. В.Ф. Ситника. — К.: КНЕУ, 1997. — 252 с.

Завдання:

вивчити теоретичні питання, оскільки з метою перевірки вони будуть внесені до підсумкової контрольної роботи та іспиту; в письмовій формі виконати два завдання:

1. Скласти опорний конспект;

2. Описати послідовність проектування бази даних

Матеріал для вивчення:

Під оптимальною логічною моделлю баз даних розуміють модель, яка не має аномалій, пов’язаних з модифікацією БД, тобто проблем, що можуть виникнути у зв’язку із замінами, вставками і вилученнями даних із БД.

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

В основу реляційних моделей покладено поняття відношення, яке подають у вигляді двовимірної таблиці.

Реляційна БД — це набір взаємопов’язаних відношень. Кожне відношення (таблиця) в ЕОМ подається як файл. Відношення мож­на поділити на два класи: об’єктні і зв’язкові.

Об’єктні відношення зберігають дані про інформаційні об’єк­ти предметної області. Наприклад: КЛІЄНТ (код клієнта, назва клієнта, адреса, телефон) є об’єктним відношенням.

В об’єктному відношенні один з атрибутів однозначно ідентифікує окремий об’єкт. Такий атрибут називається первинним ключем відношення. У наведеному відношенні роль ключа виконує атрибут «код клієнта».

Ключ може вміщувати кілька атрибутів, тобто бути складеним. В об’єктному відношенні не повинно бути рядків з однаковим ключем, тобто не допускається дублювання об’єктів. Це основне обмеження реляційної моделі для забезпечення цілісності даних.

Зв’язкове відношення зберігає первинні ключі двох або більше об’єктних відношень. Ключі зв’язкового відношення мають на меті встановлення зв’язків між об’єктними відношеннями.

Розглянемо, наприклад, ще одне об’єктне відношення БАНК (код банку, назва банку, адреса банку).

Тоді зв’язкове відношення БАНК-КЛІЄНТ (код банку, код клієнта) буде сполучним між двома об’єктними відношеннями БАНК іКЛІЄНТ. У зв’язковому відношенні можуть дублюватися ключові атрибути. Крім ключів, за якими встановлюють зв’язок у зв’язковому відношенні, можуть бути ще й інші атрибути, які функціонально залежать від цього складового ключа.

Ключі в зв’язкових відношеннях називаються вторинними або зовнішніми ключами, оскільки вони є первинними ключами об’єк­тів інших відношень. Реляційна модель накладає на зовнішні ключі обмеження, яке називають посилковою цілісністю. Воно необхідне для забезпечення цілісності даних.

Посилкова цілісність — це відповідність між об’єктними та зв’язковими відношеннями, яка полягає в тому, що кожному зовнішньому ключеві зв’язкового відношення має відповідати рядок якогось об’єктного відношення. Без такого обмеження може статися так, що зовнішній ключ посилається на об’єкт, про який нічого не відомо.

У реляційній БД накладається ще одне обмеження — відношення мають бути нормалізовані.

Проектування реляційної бази даних. Взаємозв'язки в моделі даних

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

Перед початком роботи над створенням моделі даних потрібно дослідити предметну область: опитати всіх майбутніх користувачів бази даних; визначити в результаті опитування призначення бази даних, характер інформації, яка має у ній зберігатися, визначити сутності бази даних та їхні атрибути, визначити взаємозв’язки між сутностями.

Створення інфологічної моделі

Поєднуючи уявлення про вміст бази даних, одержані в результаті опитування майбутніх користувачів, і свої уявлення  про дані, що можуть бути потрібними в майбутніх додатках, спочатку створюється інфологічна модель даних.

Логічне проектування полягає:

• у визначенні числа і структури таблиць;

• формуванні запитів до бази даних;

• визначенні типів звітних документів;

• розробці алгоритмів обробки інформації;

• розробці форм для введення і редагування даних у базі;

• рішенні низки аналогічних задач.

Виконання завдань логічного проектування бази даних в основному визначається специфікою задач предметної області. Найбільш важливою тут є проблема структуризації даних. Наприклад, припустимо, що проектування бази даних "Класний журнал" починається з виявлення атрибутів і відбору даних, зразок яких показаний в таблиці 1.

Таблиця 1. "Класний журнал"

Прізвище	Ім’я	По батькові	Дата народження	Предмет	Години	Оцінка
Іваненко	Іван	Іванович	1.08.91	Хімія	70	10
				Фізика	230	8
				математика	250	9
Симоненко	Семен	Семенович	15.04.91	Хімія	70	11
				Фізика	230	10
				математика	250	10

Цей варіант таблиці "Журнал успішності" не є відношенням, тому що не всі її рядки атомарні. Атомарними є лише значення полів Прізвище, Ім’я, По батькові, Дата народження. Поля Предмет, Години та Оцінка таблиці 2 – множинні.

Для надання таким даним форми відношення необхідно реконструювати таблицю. Найпростіше це зробити за допомогою процесу вставки. Результатом такої вставки буде універсальне відношення.

Таблиця 2. Універсальне відношення

Прізвище	Ім’я	По батькові	Дата народження	Предмет	Години	Оцінка
Іваненко	Іван	Іванович	1.08.91	Хімія	70	10
Іваненко	Іван	Іванович	1.08.91	Фізика	230	8
Іваненко	Іван	Іванович	1.08.91	математика	250	9
Симоненко	Семен	Семенович	15.04.91	Хімія	70	11
Симоненко	Семен	Семенович	16.04.91	Фізика	230	10
Симоненко	Семен	Семенович	17.04.91	математика	250	10

Універсальне відношення для невеликих баз даних (до 15 атрибутів) можна використовувати як основу для початку проектування.

Однак, таке перетворення приводить до виникнення значного обсягу надлишкових даних.

Використання універсального відношення може привести до виникнення таких проблем:

1. Надмірність. Дані практично всіх стовпців багаторазово повторюються. Повторюються і деякі набори даних.

2. Потенційна суперечливість (аномалії відновлення). Внаслідок надмірності можна поновити  дату народження в одному рядку, залишаючи його незмінним в інших (Зверніть увагу, дата народження Симоненка у всіх трьох рядках різна. Виникає потреба у відновленні даних.)

3. Аномалії включення. В базу даних не може бути записаний новий предмет, якщо жодний учень не одержав з нього оцінки.

4. Аномалії вилучення. Зворотна проблема виникає у разі необхідності вилучення всіх оцінок з будь-якого предмету. Під час таких вилучень будуть втрачені відомості про цей предмет.

Багато проблем цього прикладу зникнуть, якщо виділити в окремі таблиці відомості про учнів та відомості про предмети, а також створити сполучну таблицю "Успішність учнів". 

Таблиця 3. Відомості про учнів

Код учня	Прізвище	Ім’я	По батькові	Дата народження
1	Іваненко	Іван	Іванович	1.08.91
2	Симоненко	Семен	Семенович	15.04.91

Таблиця 4. Успішність учнів                     Таблиця 5. Відомості про предмети

Код учня	Код предмету	Оцінка		Код предмету	Предмет	Години
1	1	10		1	хімія	70
1	2	8		2	фізика	230
1	3	9		3	математика	250
2	1	11
2	2	10
2	3	10

 Нормалізація відношень - це розбиття всієї інформації на дві або більше таблиць, що мають кращі властивості щодо включення, зміни та вилучення даних

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

Проект,  у якому кожний факт з'являється лише в одному місці, називається “чистим”

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

Взаємозв'язки в моделі даних

Відношення між таблицями встановлюють зв'язок між даними, що знаходяться у різних таблицях бази даних.

 Зв’язки між таблицями встановлюються шляхом об’єднання співпадаючих значень ключових полів

Відношення між таблицями визначаються відношенням між групами об'єктів відповідного типу. Наприклад, один автор може написати кілька книг і видати їх у різних видавництвах, або видавництво може опублікувати кілька книг різних авторів. Отож, між авторами і назвами книг є відношення один-до-багатьох, а між видавництвами і авторами є відношення багато-до-багатьох.

Відношення один-до-одного

Якщо між двома таблицями є відношення один-до-одного, то це означає, що кожний запис в одній таблиці відповідає лише одному запису в іншій таблиці.

Прикладом такого відношення може служити відношення між таблицями Автори, що  містить коротку інформацію про авторів (прізвище, ім’я по батькові, рік народження) і Особа, що містить персональну інформацію про авторів (домашня адреса, телефон, освіта тощо).

Між таблицями Автори і Особа є відношення один-до-одного, оскільки один запис, що ідентифікує автора, однозначно відповідає лише одному запису в таблиці Особа, що містить персональні дані про автора.

Зв'язок між таблицями визначається за допомогою співпадаючих значень полів: Код автора в таблиці Автори і в таблиці Особа.

Відношення один-до-багатьох

Гарним прикладом відношення між таблицями один-до-багатьох є відношення між авторами і назвами книг (таблиці Автори і Публікації), оскільки кожний автор може мати відношення до створення кількох книг.

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

Відношення багато-до-одного

Відношення багато-до-одного повністю аналогічне розглянутому вище відношенню один-до-багатьох.

Відношення багато-до-багатьох

У відношенні між двома таблицями багато-до-багатьох кожний запис в одній таблиці пов'язаний з кількома записами в іншій таблиці і навпаки.

Ілюстрацією такого відношення може служити відношення між таблицями Видавництва і Автори. З одного боку, кожне видавництво може публікувати книги різних авторів, а з іншого боку, кожен автор може публікуватися в різних видавництвах.

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