Створення та обробка баз даних на ПЕОМ (стр. 7 )

Операція з'єднання має кілька різновидів. Загальна схема операції з'єднання відношень R1 і R2 за умовою f наступна. На початку будується декартовий добуток множин R1 і R2. Потім до отриманого результату застосовується операція вибірки за заданою умовою f. Для пояснення сутності операції з'єднання розглянемо такий простий приклад. Нехай задані наступні відношення R1 і R2:

R1
Прізвище	Адреса
Іванов	Київ
Петров	Бровари

R2
Прізвище	Предмет	Оцінка
Іванов	Фізика	5
Іванов	Математика	3
Петров	Фізика	4
Петров	Математика	4

Потрібно одержати прізвища й адреси студентів, що мають оцінки “4”. Дана задача може бути вирішена шляхом виконання операції з'єднання відношень R1 і R2 за умовою:

f = (R1.Прізвище = R2.Прізвище) and (R2.Оцінка = 4).

Операція реалізується в такий спосіб. На початку формується декартовий добуток:

R1ÄR2
Прізвище	Адреса	Прізвище	Предмет	Оцінка
Іванов	Київ	Іванов	Фізика	5
Іванов	Київ	Іванов	Математика	3
Іванов	Київ	Петров	Фізика	4
Іванов	Київ	Петров	Математика	4
Петров	Бровари	Іванов	Фізика	5
Петров	Бровари	Іванов	Математика	3
Петров	Бровари	Петров	Фізика	4
Петров	Бровари	Петров	Математика	4

Потім до отриманого відношення застосовується операція вибірки за умовою f. Після цього одержимо:

R = R1ÄR2 WHERE f
Прізвище	Адреса	Предмет	Оцінка
Петров	Бровари	Фізика	4
Петров	Бровари	Математика	4

У результуюче відношення включається тільки один атрибут Прізвище, тому що він є загальним для відношень, що з'єднуються. По заданій умові потрібно одержати тільки прізвища й адреси. Тому до останнього відношення (назвемо його R) застосуємо операцію проекція на атрибути Прізвище й Адреса:

R [Прізвище, Адреса]
Прізвище	Адреса
Петров	Бровари

Кортежі, що повторюються, з результуючого відношення виключаються.

Контрольні запитання:

1.  Поняття відношення, кортеж, домен. Надати визначення, навести приклади.

2.  Поняття реляційної таблиці.

3.  Первинні та зовнішні ключі відношення.

4.  Що таке реляційна алгебра? Особливості операцій реляційної алгебри.

5.  Операції об’єднання, перетинання і різниці відношень. Навести приклади.

3. Проектування баз даних

3.1. Проблеми і етапи проектування баз даних

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

Системний аналіз предметної області і словесний опис інформаційних об'єктів і зв’язків між ними.

Інфологічне проектування – побудова інформаційно-логічної (інфологічної) моделі предметної області.

Вибір СУБД.

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

Фізичне проектування – вибір ефективного способу розміщення БД на зовнішніх носіях для забезпечення найбільш ефективної роботи прикладних програм.

Етапи проектування БД наочно зобразити можна у виді схеми на Рис. 3.1. Далі розглянемо коротко сутність кожного з цих етапів.

 

Рис. 3.1. Етапи проектування БД

3.1.1. Системний аналіз предметної області

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

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

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

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

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

3.1.2. Інфологічне проектування

Метою інфологічного (інформаційно-логічного) проектування є побудова інформаційно-логічної моделі предметної області. Ця модель повинна в напівформалізованому вигляді представляти схему проекту майбутньої БД. При цьому ступінь деталізації її повинна бути достатньої для наступного її “перекладу на мову” конкретної реляційної СУБД, і, одночасно, вона повинна легко читатися неспеціалістом, яким завжди є замовник – майбутній користувач БД. Це завжди дуже важливо, тому що на цьому етапі можуть вирішуватися питання про фінансування створення БД.

В даний час найбільш розповсюдженим є підхід до інформаційно-логічного проектування, заснований на застосуванні моделі “сутність-зв'язок” (ER-моделі). Уже розроблені і застосовуються на практиці інструментальні засоби, які використовують модель “сутність-зв'язок” (CASE-системи), за допомогою яких автоматизується процес розробки інформаційно-логічної моделі. Нижче ми більш докладно познайомимося з основними положеннями моделі “сутність-зв'язок”.

3.1.3. Вибір СУБД

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

3.1.4. Даталогічне проектування

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

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

На цьому ж етапі визначаються правила і процедури забезпечення цілісності БД.

3.1.5. Фізичне проектування

Етап фізичного проектування містить у собі реальне створення необхідних об'єктів БД (таблиць, індексів, обмежень і т. д.) відповідно до розробленої схеми БД. Це велика кропітка робота програмістів з використанням інструментальних засобів, що маються в конкретної СУБД.