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

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

Реляційна база даних

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

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

Таблиця PRODUCTS

ID	NAME	COMPANY	PRICE
123	Печінки	ТОВ ”Темна сторона”	190
156	Чай	ТОВ ”Темна сторона”	60
235	Ананаси	ВАТ ”Фрукти”	100
623	Томати	ТОВ ”Овочі”	130

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

Для ясності тепер введемо суворе визначення відносини.

Нехай дані N множин D1, D2, …. Dn (домени), ставленням R над цими множинами називається безліч упорядкованих N-кортежів виду де d1 належить D1 і тд. Безліч D1,D2,..Dn називаються доменами відношення R.
Кожен елемент кортежу є значенням одного з атрибутів, відповідного одному з доменів.

Ключі у відносинах

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

Таблиця DRIVERS

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

У реляційної БД таблиці взаємопов'язані і співвідносяться один з одним як основні та підлеглі. Зв'язок головної та підлеглої таблиці здійснюється через первинний ключ (primary key) головної таблиці та зовнішній ключ (foreign key) підлеглої таблиці.
Зовнішній ключ - це атрибут або набір атрибутів, який у головній таблиці є первинним ключем.

Цієї підготовчої теорії буде достатньо для знайомства з основними операціями реляційної алгебри.

Операції реляційної алгебри

Основні вісім операцій реляційної алгебри були запропоновані Е. Коддом.

• Об'єднання
• Перетин
• Віднімання
• Декартове твір
• Вибірка
• Проекція
• З'єднання
• Поділ

Перша половина операцій аналогічна таким операціям над множинами. Частину операцій можна виразити через інші операції. Розглянемо більшу частину операцій із прикладами.

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

Таблиця SELLERS

ID	SELLER
123	ТОВ "Дарт"
156	ВАТ ”Відро”
235	ЗАТ "Овоче База"
623	ВАТ ”Фірма”

Умовимося, що у таблиці ID це зовнішній ключ, пов'язані з первинним ключем таблиці PRODUCTS.

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

Проекція

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

Синтаксис операції:
π (ID, PRICE) PRODUCTS

За умови вибірки ми можемо використовувати будь-який логічний вираз. Зробимо ще одну вибірку з ціною більше 90 та ID товару менше 300:

σ (PRICE>90 ^ ID<300) PRODUCTS

Розмноження

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

Отримаємо декартові твори таблиць PRODUCTS та SELLERS.
Синтаксис операції:

PRODUCTS × SELLERS
Можна помітити, що дві ці таблиці мають однаковий домен ID. У подібній ситуації домени з однаковими назвами одержують префікс у вигляді назви відповідного відношення, як показано нижче.
Для стислості перемножимо не повні стосунки, а вибірки з умовою ID<235

(кольором виділені одні й самі кортежі)

PRODUCTS.ID	NAME	COMPANY	PRICE	SELLERS.ID	SELLER
123	Печінки	ТОВ ”Темна сторона”	190	123	ТОВ "Дарт"
156	Чай	ТОВ ”Темна сторона”	60	156	ВАТ ”Відро”
123	Печінки	ТОВ ”Темна сторона”	190	156	ВАТ ”Відро”
156	Чай	ТОВ ”Темна сторона”	60	123	ТОВ "Дарт"

Для використання цієї операції уявімо необхідність вибрати продавців з цінами менше 90. Без твору необхідно було б спочатку отримати ID продуктів з першої таблиці, потім за цим ID з другої таблиці отримати потрібні імена SELLER, а з використанням твору буде такий запит:

π (SELLER) σ (RODUCTS.ID=SELLERS.ID ^ PRICE<90) PRODUCTS × SELLERS

В результаті цієї операції отримаємо відношення:

SELLER

ВАТ ”Відро”

З'єднання та природне з'єднання

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

Також для зрозумілості можна уявити з'єднання як результат двох операцій. Спочатку береться твір вихідних таблиць, та був з отриманого відношення ми вибираємо з умовою рівності атрибутів з однакових доменів. У разі умовою є рівність PRODUCTS.ID і SELLERS.ID.

Спробуємо поєднати відносини PRODUCTS та SELLERS та отримаємо відношення.

PRODUCTS.ID	NAME	COMPANY	PRICE	SELLERS.ID	SELLER
123	Печінки	ТОВ ”Темна сторона”	190	123	ТОВ "Дарт"
156	Чай	ТОВ ”Темна сторона”	60	156	ВАТ ”Відро”
235	Ананаси	ВАТ ”Фрукти”	100	235	ЗАТ "Овоче База"
623	Томати	ТОВ ”Овочі”	130	623	ВАТ ”Фірма”

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

Синтаксис операції:
PRODUCTS ⋈ SELLERS;

Вийде таке ставлення:

PRODUCTS.ID	NAME	COMPANY	PRICE	SELLER
123	Печінки	ТОВ ”Темна сторона”	190	ТОВ "Дарт"
156	Чай	ТОВ ”Темна сторона”	60	ВАТ ”Відро”
235	Ананаси	ВАТ ”Фрукти”	100	ЗАТ "Овоче База"
623	Томати	ТОВ ”Овочі”	130	ВАТ ”Фірма”

Перетин та віднімання.

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

Джерела інформації

• Основи використання та проектування баз даних - В. М. Ілюшечкін
• курс лекцій Introduction to Databases - Jennifer Widom, Stanford University

Буду вдячний за аргументовані зауваження

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

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

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

Як приклади СУБД можна назвати такі широко відомі пакети, як

• MySQL
• PostgreSQL
• Microsoft SQL Server
• Oracle
• IBM DB2
• Microsoft Access
• SQLite

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

СУБД часто класифікуються за підтримуваною ними моделлю даних. З 1980-х років практично всі популярні СУБД підтримують реляційну модель даних, представлену стандартом мови запитів SQL (хоча останні роки набирає популярність NoSQL).

Отже, основні завдання, що виконуються СУБД, включають

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

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

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

Моделі БД

Як говорилося раніше, найпоширенішою моделлю даних є реляційна модель. Однак появі реляційної моделі передували інші, зокрема

• Ієрархічна, чи навігаційна модель
• Мережева модель

Ієрархічна модель широко використовувалася в СУБД, що поставляються компанією IBM у 1960-х. Основна ідея полягає в тому, що запис у такій БД може мати кілька "дочірніх" та одну "батьківську". Загалом це підозріло схоже на ієрархічну файлову систему. Щоб отримати запис у такий БД, часто потрібний прохід по всьому дереву.

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

У 1970-х Едгаром Коддом (співробітник IBM) була запропонована реляційна модель, яка значно полегшила завдання пошуку інформації в БД. Про реляційної моделі можна як про “таблицях”, у яких “рядки” – це записи в БД. Записи в реляційної БД також називаються кортежами (tuples), а групи записів (“таблиці”) – відносинами (relations). Реляційна модель здатна виразити зв'язки ієрархічної та мережевої моделей, і додавала власні зв'язки, що відповідають табличній моделі.

На основі пропозицій Кодда до середини 1970-х була розроблена СУБД System R, а до кінця в ній з'явилася підтримка стандартизованої мови запитів SQL.

У 1980-х, з появою об'єктно-орієнтованого програмування, все частіше виникали складнощі у трансляції об'єктів на реляційну модель. Зрештою, це призвело до появи підходів NoSQL і NewSQL, які на даний момент тільки розвиваються. Прикладами реалізації NoSQL підходу може бути т.зв. документоорієнтовані БД, побудовані на основі XML. Основне перевагу NoSQL – висока горизонтальна масштабованість, тобто. можливість збільшувати продуктивність з допомогою додавання серверів. З появою хмарних технологій, NoSQL став особливо популярним.

Тим не менш, реляційна модель поки залишається найпоширенішою, тому докладніше зупинимося саме на ній.

Реляційна модель

Реляційна модель оперує поняттями записів, атрибутів та відносин. Відношення можна уявити як двомірної таблиці, тоді атрибути – це стовпці таблиці (точніше, назви стовпців), а записи – рядки таблиці.

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

Введемо деякі визначення.

Домен Безліч, що містить повний набір всіх можливих значень певної змінної. Домени часто називають типом даних. Атрибут Упорядкована пара назви атрибутута домену \(D_j\) . Кортеж Кінцеве впорядковане безліч ((d_1, d_2, \ldots, d_n)\) Заголовок (схема) відносини Кортеж \((A_1, A_2, \ldots, A_n)\) , де \(A_j\) - атрибути. Значення атрибута Конкретне значення домену атрибута. Тіло відношення Безліч кортежів , де \(d^i_j \in D_j\) , \(D_j\) - домени. Запис Кортеж \((d^i_1, d^i_2, \ldots, d^i_n)\)при фіксованому \(i\) . Відношення Сукупність заголовка відношення та тіла відношення. Схема бази даних Безліч схем всіх відносин, що входять до БД.

Можна уявити ставлення як таблиці. Тоді тіло відношення – це тіло таблиці, заголовок відношення – заголовок таблиці, атрибути – назви стовпців, записи – рядки, а значення атрибутів перебувають у осередках:

\(A_1\)	\(A_2\)	\(\ldots\)	\(A_n\)	← Заголовок
\(d^1_1\)	\(d^1_2\)	\(\ldots\)	\(d^1_n\)	← Запис
\(d^2_1\)	\(d^2_2\)	\(\ldots\)	\(d^2_n\)	← Запис
\(\ldots\)	\(\ldots\)	\(\ldots\)	\(\ldots\)	← Запис
\(d^m_1\)	\(d^m_2\)	\(\ldots\)	\(d^m_n\)	← Запис

Реляційна модель накладає такі додаткові вимоги щодо відносин:

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

Функціональна залежність безліч атрибутів \(B\) функціонально залежить від безлічі атрибутів \(A\) (записується \(A\rightarrow B\) ), якщо для будь-яких двох записів, що мають однакові значення \(A\) , їх значення \( B) збігаються. Інакше, кожному значенню (A) відповідає єдине значення (B) (не обов'язково унікальне, саме єдине).

Іншими словами, якщо деякий набір атрибутів (A) однозначно визначає (в рамках даного відношення) значення атрибутів (B), то (B) функціонально залежить від (A).

Як більш звичний приклад функціональної залежності, можна навести математичне визначення функції. Для функції, кожному значенню аргументів відповідає єдине значення функції. Зворотне в загальному випадку невірно, наприклад, для функції \(y = sin(x)\) будь-якому значенню \(y\) з області визначення \(1\geq y \geq -1\) відповідає безліч значень \(x\ ) , але кожного значення \(x\) є рівно одне значення \(y\) , т.ч. \(x \to y\) . Зауважимо, що поняття функціональної залежності так само можна застосувати і до функцій багатьох змінних. Для них значення функції функціонально залежить від всіх аргументів одночасно. Скажімо, для функції \(z = f(x,y)\) виконується ФЗ \((x,y)\to z\) , або скорочено, \(xy\to z\) .

Відносини у цьому контексті можна як деякі табличнічи дискретні функції.

Робота з ФЗ

Існують певні формальні правила роботи із ФЗ відносини.

Формальні правила тісно пов'язані з поняттями замиканняі ненаведеною ФЗ.

Аксіоми Армстронга

Існують правила виведення нових ФЗ з існуючих аксіомами Армстронга.

Аксіоми Армстронга

1. Правило рефлексивності: якщо \(B\subset A\), то \(A\rightarrow B\)
2. Правило доповнення: якщо \(A\rightarrow B\) , то \(AC\rightarrow BC\)
3. Правило транзитивності: якщо \(A\rightarrow B\) і \(B\rightarrow C\) , то \(A\rightarrow C\)

З цих аксіом також можуть бути виведені такі додаткові правила:

1. Правило самовизначення: (Arightarrow A)
2. Правило декомпозиції: Якщо \(A\rightarrow BC\) , то \(A\rightarrow B\) і \(A\rightarrow C\)
3. Правило об'єднання: Якщо \(A\rightarrow B\) і \(A\rightarrow C\) , то \(A\rightarrow BC\)
4. Правило композиції: Якщо \(A\rightarrow B\) і \(C\rightarrow D\) , то \(AC\rightarrow BD\)

Можна помітити, що, внаслідок правила рефлексивності, будь-яка безліч атрибутів (A) передбачає ФЗ виду (A to A). Такі ФЗ, а як і наступні їх, не становлять інтересу, і називаються тривіальними.

Тривіальна функціональна залежність ФЗ \(A \to B\) , така, що \(B \subset A\) .

У принципі, цих правил достатньо для того, щоб знайти всі ФЗ, що йдуть з даних. У зв'язку з цим вводиться поняття замикання множини ФЗ.

Замикання множини ФЗ Замиканням множини ФЗ називається така множина ФЗ, яка включає всі ФЗ вихідної множини, а так само всі ними. Іншими словами, для відношення \(R\), що володіє функціональними залежностями \(S\), замиканням \(S^+\) називається безліч всіх ФЗ, можливих для \(R\), виходячи з \(S\).

Як правило, потрібно встановити, чи буде якась ФЗ \ (X \ rightarrow Y \) слідувати з даної множини ФЗ \ (S \) . Виявляється, це можливо тоді і тільки тоді, коли безліч атрибутів \(Y\) є підмножиною замикання атрибутів \(X^+\) в \(S\).

Замикання атрибутів Замиканням \(X^+\) атрибутів \(X\) по множині ФЗ \(S\) називається безліч всіх атрибутів, які функціонально залежать від будь-якого підмножини \(X\) .

Для обчислення замикання безлічі атрибутів \(X^+\) по безлічі ФЗ \(S\) існує таке правило: для кожної ФЗ \(A\rightarrow B\) в \(S\) , якщо \(A \subset X^ +\) , то й \(B \subset X^+\) , причому досить почати з припущення, що \(X^+ = X\) .

Слід зауважити, що для будь-якого замикання \(X^+\) , існують ФЗ виду \(X \to B\) , де \(B \subset X^+\) , таким чином, замикання всіх атрибутів відношення за його ФЗ описують замикання ФЗ цього відношення.

Це правило використовується для обчислення ненаведеної множини ФЗ, еквівалентної даному (в сенсі еквівалентності їх замикань). Зменшення кількості ФЗ за збереження замикання (і, отже, внутрішньої логіки, що описується ФЗ) є важливим кроком у проектуванні БД.

Безліч ФЗ називається ненаведеною, якщо:

1. Права частина кожної ФЗ містить лише один елемент
2. Жоден атрибут жодної лівої частини ФЗ множини не може бути видалений без зміни замикання
3. Жодна ФЗ множини не може бути видалена без зміни замикання.

Для будь-якої множини ФЗ існує хоча б одна еквівалентна неприведена множина. Така множина називається мінімальним покриттям.

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

Вступ

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

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

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

Функціональні залежності

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

Загальні визначення

Нехай задана змінна стосунки r і X і Y є довільними підмножинами заголовка r ("складовими" атрибутами).

У значенні змінної відносини r атрибут Y функціонально залежить від атрибуту Xу тому й лише тому випадку, якщо кожному значенню X відповідає точно одне значення Y . У цьому випадку також говорять, що атрибут X функціонально визначаєатрибут Y (X є детермінантом ( визначником) для Y, а Y є залежним від X). Будемо позначати це як r.X->r.Y.

Для прикладу використовуватимемо ставлення СЛУЖБІ_ПРОЕКТИ (СЛУ_НОМ, СЛУ_ІМ'Я, СЛУ_ЗАРП, ПРО_НОМ, ПРОЕКТ_РУК)(Рис. 6.1). Очевидно, що якщо СЛУ_НОМ є первинним ключем відносиниСЛУЖАЧІ, то для цього відносини справедливі функціональна залежність (Functional Dependency – FD)СЛУ_НОМ->СЛУ_ІМ'Я .

Насправді, для тіла стосунки СЛУЖБІ_ПРОЕКТИу тому вигляді, в якому воно показано на рис. 6.1 виконуються ще й наступні FD (1):

Мал. 6.1.

СЛУ_НОМ-> СЛУ_ІМЯ СЛУ_НОМ-> СЛУ_ЗАРП СЛУ_НОМ-> ПРО_НОМ СЛУ_НОМ-> ПРОЕКТ_РУК (СЛУ_НОМ, СЛУ_ІМЯ) -> СЛУ_ЗАРП (СЛУ_НОМ, СЛУ_ІМЯ) -> ПРО_НОМ (СЛУ_НОМ, СЛУ_ІМЯ) -> (СЛУ_ЗАРП, ПРО_НОМ) ... ПРО_НОМ-> ПРОЕКТ_РУК і і т.д.

Оскільки імена всіх службовців різні, то виконуються такі FD (2):

СЛУ_ІМ'Я->СЛУ_НОМ СЛУ_ІМ'Я->СЛУ_ЗАРП СЛУ_ІМ'Я->ПРО_НОМ і т.д.

Понад те, наприклад на рис. 6.1 виконується та FD (3):

СЛУ_ЗАРП->ПРО_НОМ

Однак зауважимо, що природа FD групи (1) відрізняється від природи FD груп (2) та (3). Логічно припустити, що ідентифікаційні номери службовців мають бути завжди різні, а кожен проект має лише один керівник. Тому FD групи (1) повинні бути вірними для будь-якого допустимого значення змінної відносини СЛУЖБІ_ПРОЕКТИі можуть розглядатися як інваріанти, або обмеження цілісностіцією змінної відносини.

FD групи (2) базуються на менш природному припущенні, що імена всіх службовців різні. Це відповідає дійсності для прикладу з рис. 6.1 але можливо, що з часом FD групи (2) не будуть виконуватися для будь-якого значення змінної відносини СЛУЖБІ_ПРОЕКТИ.

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

Надалі нас цікавитимуть лише ті функціональні залежності, які мають виконуватися для всіх можливих значень змінних відносин.

Зауважимо, що якщо атрибут A відношення r є можливим ключем, то для будь-якого атрибуту B цього відношення завжди виконується

Життєвий цикл інформаційних систем

Аналіз ситуації (складність розробки ІВ, неефективне використання ІВ), проведений вченими, показав, що таке становище було викликано тим, що при розробці програмного забезпечення не дотримувалися дуже важливих вимог:

· Відсутність повної специфікації всіх вимог;

· Відсутність прийнятної методології (системи методів) розробки ІВ;

· Відсутність поділу загального глобального проекту на окремі компоненти, що піддаються ефективному контролю та управлінню.

Життєвий цикл інформаційних систем – це структурний підхід до розробки програмного забезпечення.

(якась схема) за 26.09.12

1. Планування розробки ІВ. Підготовчі дії, що дозволяють максимально ефективно реалізовувати етапи ЖЦ ІС. Три основні компоненти: оцінка обсягу робіт; оцінка необхідних ресурсів; оцінка загальної вартості проекту

2. Визначення вимог до системи. Визначення діапазону дій та меж програми бази даних, функцій, складу його користувачів та областей застосування.

3. Збір та аналіз вимог користувачів. Збір та аналіз інформації про ту частину організації, робота якої підтримуватиметься за допомогою створюваної ІС, визначення вимог користувачів до системи. Джерела: опитування та анкетування; спостереження; вивчення документів; попередній досвід.

4. Проектування бази даних. Створення проекту бази даних. Два основні підходи до проектування систем баз даних: низхідний» та « висхідний».

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

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

7. Створення прототипу. Створення робочої моделі програми баз даних.

8. Реалізація. Фізична реалізація бази даних та розроблених додатків.

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

10. Тестування. Процес виконання прикладних програм із метою пошуку помилок. Стратегії тестування: низхідне тестування; висхідне тестування; тестування потоків; інтенсивне тестування

11. Експлуатація та супровід. Спостереження за системою та підтримка її нормального функціонування: контроль продуктивності; супровід та модернізація додатків.

Реляційна теорія баз даних

Термінологія

У 1970 р. реляційну модель вперше було запропоновано Е.Ф. Коддім.

У реляційній СУБД передбачається, що користувач сприймає БД як набір таблиць (і не інакше).

Математичні стосунки.

Теорія реляційних БД заснована на математичній теорії відносин.

Нехай D1, D2, … Dn деякі множини.

Декартовим добуток D1 D2 … Dn = ((X1, X2, …, Xn) | X1 D1, X2 D2, … Xn Dn)

Відношення - підмножина R D1 * D2 * ... * Dn

Наприклад, n=2, D1=(2,4) та D2=(1,3,5), D1 * D2 = ((2,1),(2,3),(2,5),(4, 1),(4,3),(4,5)), R=((2,1),(4,1))

Підмножина м. б. задано умовою, наприклад:

R=((x1,x2) |x1 D1, x2 D2, X2=1), A1, A2, … An – імена атрибутів з доменами D1, D2, … Втб тоді ставлення записуватимемо як:

R(A1: D1, A2: D2, ... An: Dn)

Властивості відносин:

· Відношення має унікальне ім'я;

· Кожен атрибут має унікальне ім'я (щодо);

· Кожен осередок відносини містить тільки атомарне значення і немає повторюваних груп (ставлення нормалізоване);

D1 – студенти
D2 – дисципліни: Математика, Інформатика

· Порядок проходження атрибутів не має жодного значення;

· Порядок прямування кортежів довільний;

· Кожен кортеж є унікальним.

Реляційні ключі

Реляційні ключі є унікальною ідентифікацією кортежу опису зв'язків між відносинами.

Реляційна цілісність.

Реляційна алгебра

Результат операції може використовуватися як операнда для іншої операції, що дозволяє створювати вкладені вирази (замкнутість РА).

Реляційна алгебра є мовою, де всі кортежі обробляються однією командою.

П'ять основних операцій:

· Вибірка,

· Проекція,

· Декартове твір,

· Об'єднання,

· Різниця.

На основі цих операцій можуть бути отримані інші:

· З'єднання,

· Перетину,

· Поділу.

У предикаті можна використовувати знаки логічних операцій ^(And), v(Or), ~(not).

приклад. Отримати список усіх співробітників із окладом понад 300.

Проекція.

Визначає відношення, атрибутами якого є атр1, …, атр і містить тільки унікальні кортежі.

Декартове твір

Декартове твір використовується рідко, до результату застосовують вибірку.

Об'єднання

Різниця

Операції з'єднання.

Тета-з'єднання

Природне поєднання

Зовнішнє з'єднання

При лівому зовнішньому з'єднанні зберігається вся вихідна інформація з відношення R. Аналогічно також можна визначити праве зовнішнє з'єднання.

Напівз'єднання

Операцію напівз'єднання можна визначити за допомогою операторів проекції та з'єднання.

Перетин

Уявлення

Призначення уявлень:

· Надає гнучкий механізм захисту БД за рахунок приховування деякої її частини від певних користувачів;

· Дозволяє організувати доступ користувачів до даних найбільш зручним для них способом;

· Дозволяє спрощувати складні операції з базовими відносинами.

Правила, які мають задовольнити
реляційні СУБД

Для визначення того, чи є СУБО реляційною Кодд (1985) запропонував 13 правил, яким вони повинні задовольняти.

№		Правило
		Фундаментальне правило. Реляційна СУБД має бути здатна керувати базами даних виключно за допомогою її реляційних функцій
		Подання інформації. Вся інформація у реляційної БД представляється у явному вигляді на логічному рівні лише одним способом – у вигляді значень у таблицях. У тому числі метадані.
		Гарантований доступ. Для кожного елемента даних реляційної БД має бути гарантований логічний доступ на основі комбінації імені таблиці, значення первинного ключа та стовпця.
		Підтримка невизначених значень. СУБД підтримує невизначені значення (Null).
		Реляційний системний каталог Опис БД має надаватися на логічному рівні таким чином, як і звичайні дані, що дозволяє користувачам використовувати для звернення до них ту саму реляційну мову.
		Вичерпна підмова даних. реляційна СУБД може підтримувати кілька мов. Однак має існувати принаймні одна мова, оператори якої дозволяли б виконати такі функції: 1. Визначення даних; 2. Визначення уявлень; 3. Команди маніпулювання даними; 4. Обмеження цілісності; 5. Авторизації користувачів; 6. Організації транзакцій
		Високорівневі операції вилучення, вставки, видалення, оновлення. Здатність СУБД виконувати операції вилучення даних команд вставки, видалення та оновлення як єдиної операції.
		Фізична незалежність від даних. Від способу зберігання
		Логічна незалежність даних. Незалежність програм від зміни базових таблиць.
		Незалежність обмежень цілісності. Обмеження цілісності повинні визначатися підмовою реляційних даних і зберігатися в системному каталозі, а не в прикладних програмах.
		Незалежність від розподілу даних.
		Правило заборони обхідних шляхів. Якщо СУБД має низькорівневу мову (з послідовною рядковою обробкою), вона не повинна дозволяти обходити правила та обмеження цілісності, описаних реляційною мовою високого рівня.

Моделювання даних на основі процесу нормалізації

Ціль нормалізації.

Процес нормалізації був запропонований в 1972 Е. Ф. Коддом - три нормальні форми (НФ): перша (1НФ), друга (2НФ) і третя (3НФ).

Суворіше визначення третьої НФ (Р. Бойс та Е. Ф. Кодд, 1974) - нормальна форма Бойса-Кодда (НФБК).

Надмірність даних та аномалії обробки.

Відсутність нормалізації наводить:

· Надмірність даних

· Аномалії вставки (неможливо додавати записи)

· Аномалії видалення (при видаленні інформації втрачається інша інформація)

· Аномалії оновлення (потрібне оновлення багатьох записів)

· Властивості збереження без втрат та збереження залежності.

Функціональні залежності