Матеріал із Національної бібліотеки ім. Н. Е. Баумана
Останнє змінення цієї сторінки: 12:13, 25 березня 2017.
Реляційна база даних- База даних, побудована на основі реляційної моделі. У реляційної базі кожен об'єкт задається записом (рядком) у таблиці. Реляційна база створюється і потім управляється за допомогою реляційної системи управління базами даних. Фактично реляційна база даних це тіло пов'язаної інформації, що зберігається у двовимірних таблицях. Зв'язок між таблицями може знаходити своє відображення у структурі даних, а може лише матися на увазі, тобто бути присутнім на неформалізованому рівні. Кожна таблиця БД представляється як сукупність рядків і шпальт, де рядки відповідають екземпляру об'єкта, конкретної події чи явищу, а стовпці - атрибутам (ознакам, характеристикам, параметрам) об'єкта, події, явища. Реляційні бази даних надають більш простий доступ до звітів, що оперативно складаються (зазвичай через SQL) і забезпечують підвищену надійність і цілісність даних завдяки відсутності надлишкової інформації.
Історія
Реляційні системи беруть свій початок у математичній теорії множин. Едгар Кодд, співробітник дослідницької лабораторії корпорації IBM у Сан-Хосе, по суті, створив і описав концепцію реляційних баз даних у своїй основній роботі «Реляційна модель для великих банків даних, що спільно використовуються» (A Relational Model of Data for Large Shared Data Banks). Communications of the ACM, червень 1970).
Нечіткість багатьох термінів, що використовуються у сфері обробки даних, змусила Кодда відмовитися від них і вигадати нові або дати більш точні визначення існуючим. Так, він не міг використовувати широко поширений термін "запис", який у різних ситуаціях може означати екземпляр запису, або тип записів, запис у стилі Кобола (яка допускає групи, що повторюються) або плоский запис (яка їх не допускає), логічний запис або фізичний запис, запис або віртуальний запис і т.д. Натомість він використовував термін "кортеж довжини n" або просто "кортеж", якому дав точне визначення.
Кодд запропонував модель, яка дозволяє розробникам розділяти свої бази даних на окремі, але взаємопов'язані таблиці, що збільшує продуктивність, але при цьому зовнішнє уявлення залишається тим самим, що й у вихідної бази даних. З того часу Кодд вважається батьком-засновником галузі реляційних баз даних. Кодд сформулював 12 правил для реляційних баз даних, більшість яких стосуються цілісності та оновлення даних, а також доступу до них.
Правила Кодда
Правило 0: Основне правило(Foundation Rule):
Правило 1: Інформаційне правило(The Information Rule):
Вся інформація в реляційній базі даних на логічному рівні повинна бути представлена єдиним способом: значеннями в таблицях.
Правило 2: Гарантований доступ до даних(Guaranteed Access Rule):
У реляційної бази данихкожне окреме (атомарне) значення даних має бути логічно доступним за допомогою комбінації імені таблиці, значення первинного ключа та імені стовпця.
Правило 3: Систематична підтримка відсутніх значень(Systematic Treatment of Null Values):
Невідомі або відсутні значення NULL, відмінні від будь-якого відомого значення, повинні підтримуватись для всіх типів даних при виконанні будь-яких операцій. Наприклад, для числових даних невідомі значення не повинні розглядатися як нулі, а для символьних даних як порожні рядки.
Правило 4: Доступ до словника даних у термінах реляційної моделі(Active On-Line Catalog Базований на Relational Model):
Словник даних повинен зберігатися у формі реляційних таблиць, і СУБД повинна підтримувати доступ до нього за допомогою стандартних мовних засобів, тих самих, які використовуються для роботи з реляційними таблицями, що містять дані користувача.
Правило 5: Повнота підмножини мови(Comprehensive Data Sublanguage Rule):
Система управління реляційними базами даних повинна підтримувати хоча б одну реляційну мову, яка (а) має лінійний синтаксис, (б) може використовуватися як інтерактивно, так і в прикладних програмах, (в) підтримує операції визначення даних, визначення уявлень, маніпулювання даними (інтерактивні та програмні), обмежувачі цілісності, управління доступом та операції управління транзакціями (begin, commit та rollback).
Правило 6: Можливість зміни уявлень(View Updating Rule):
Кожне подання має підтримувати всі операції маніпулювання даними, які підтримують реляційні таблиці: операції вибірки, вставки, зміни та видалення даних.
Правило 7: Наявність високорівневих операцій керування даними(High-Level Insert, Update, and Delete):
Операції вставки, зміни та видалення даних повинні підтримуватись не тільки по відношенню до одного рядка реляційної таблиці, але й по відношенню до будь-якої множини рядків.
Правило 8: Фізична незалежність даних(Physical Data Independence):
Програми не повинні залежати від способів зберігання даних, що використовуються на носіях, від апаратного забезпечення комп'ютерів, на яких знаходиться реляційна база даних.
Правило 9: Логічна незалежність даних(Logical Data Independence):
Подання даних у додатку має залежати від структури реляційних таблиць. Якщо процесі нормалізації одна реляційна таблиця поділяється на дві, подання має забезпечити об'єднання цих даних, щоб зміна структури реляційних таблиць не позначалося на роботі додатків.
Правило 10: Незалежність контролю цілісності(Integrity Independence):
Вся інформація, необхідна підтримки цілісності, має бути у словнику даних. Мова для роботи з даними повинна перевіряти вхідні дані та автоматично підтримувати цілісність даних.
Правило 11: Незалежність від розташування(Distribution Independence):
База даних може бути розподіленою, може перебувати на кількох комп'ютерах, і це не повинно впливати на програми. Перенесення бази даних на інший комп'ютер не повинно впливати на програми.
Правило 12: Узгодження мовних рівнів(The Nonsubversion Rule):
Якщо використовується низькорівнева мова доступу до даних, вона не повинна ігнорувати правила безпеки та правила цілісності, які підтримуються мовою вищого рівня.
Сутність реляційної бази даних
Реляційна база даних є набір таблиць (сутностей). Таблиці складаються з колонок та рядків (кортежів). Усередині таблиць можна визначити обмеження, між таблицями існують відносини. За допомогою SQL можна виконувати запити, які повертають набори даних, що одержуються з однієї чи кількох таблиць. В рамках одного запиту дані виходять з кількох таблиць шляхом їх з'єднання (JOIN), найчастіше для з'єднання використовуються самі колонки, які визначають відносини між таблицями.
Нормалізація - це процес структурування моделі даних, що забезпечує зв'язність і відсутність надмірності даних. Метою нормалізації реляційної бази даних є усунення недоліків структури бази даних, що призводять до надмірності, яка, у свою чергу, потенційно призводить до різних аномалій та порушень цілісності даних. Теоретики реляційних баз даних у процесі розвитку теорії виявили та описали типові приклади надмірності та способи їх усунення . Реляційні сховища забезпечують найкращу суміш простоти, стійкості, гнучкості, продуктивності, масштабованості та сумісності. Що стосується масштабованості, реляційні БД добре масштабуються тільки в тому випадку, якщо розміщуються на єдиному сервері.
Особливістю реляційної бази даних є використання в ній реляційної моделі даних і наслідки, що випливають з цього:
- Модель даних у реляційних БД визначена заздалегідь. Є строго типізованою, містить обмеження та відносини для забезпечення цілісності даних.
- Модель даних заснована на природному поданні даних, що містяться, а не на функціональності програми.
- Модель даних піддається нормалізації, щоб уникнути дублювання даних. Нормалізація породжує відносини між таблицями. Відносини пов'язують дані різних таблиць.
У реляційній базі даних дані створюються, оновлюються, видаляються та запитуються з використанням мови структурованих запитів (SQL). SQL-запити можуть отримувати дані як з одиночної таблиці, так і з декількох таблиць. Такі запити можуть включати агрегації та складні фільтри. Реляційна БД зазвичай містить вбудовану логіку, таку як тригери, процедури, що зберігаються і функції.
Реляційна система управління базою даних (РСУБД)- СУБД, яка управляє реляційними базами даних.
Доступ до реляційних баз даних здійснюється через реляційні системи управління базами даних (РСУБД). Майже всі системи баз даних, які ми використовуємо є реляційними, такі як Oracle, SQL Server, MySQL, Sybase, DB2, TeraData і так далі. Причини такого домінування є неочевидними. Протягом усього існування реляційних БД вони постійно пропонували найкращу суміш простоти, стійкості, гнучкості, продуктивності, масштабованості та сумісності у сфері управління даними.
Наприклад, простий запит SELECT може мати сотні потенційних шляхів виконання, які оптимізатор оцінить безпосередньо під час виконання запиту. Все це приховано від користувачів, проте всередині РСУБД створює план виконання, що ґрунтується на речах на кшталт алгоритмів оцінки вартості та найкраще відповідає запиту. Однак, щоб забезпечити всі ці особливості, реляційні сховища неймовірно складні всередині.
Реляційна система управління базою даних містить:
- командна мова;
- мова програмування з орієнтацією на обробку таблиць;
- інтерпретує та/або компілюючу систему; і
- користувальницьку оболонку.
- Переклад
Примітка перекладача: хоч стаття досить стара (опублікована 2 роки тому) і носить гучну назву, в ній все ж таки дається гарне уявлення про відмінності реляційних БД і NoSQL БД, їх переваги і недоліки, а також наводиться короткий огляд нереляційних сховищ.
Останнім часом з'явилося багато нереляційних баз даних. Це говорить про те, що якщо вам потрібна практично необмежена масштабованість на вимогу, вам потрібна нереляційна база даних.
Якщо це правда, чи це означає, що могутні реляційні БД стали вразливими? Чи означає це, що дні реляційних БД минають і незабаром пройдуть? У цій статті ми розглянемо популярний перебіг нереляційних баз даних стосовно різних ситуацій і подивимося, чи це вплине на майбутнє реляційних БД.
Реляційні бази даних існують близько 30 років. За цей час спалахували кілька революцій, які мали покласти край реляційним сховищам. Звичайно, жодна з цих революцій не відбулася, і одна з них ні на йоту не похитнула позиції реляційних БД.
Почнемо з основ
Реляційна база даних є набір таблиць (сутностей). Таблиці складаються з колонок та рядків (кортежів). Усередині таблиць можна визначити обмеження, між таблицями існують відносини. За допомогою SQL можна виконувати запити, які повертають набори даних, що одержуються з однієї чи кількох таблиць. В рамках одного запиту дані виходять з кількох таблиць шляхом їх з'єднання (JOIN), найчастіше для з'єднання використовуються самі колонки, які визначають відносини між таблицями. Нормалізація - це процес структурування моделі даних, що забезпечує зв'язність і відсутність надмірності даних.
Доступ до реляційних баз даних здійснюється через реляційні системи управління базами даних (РСУБД). Майже всі системи баз даних, які ми використовуємо є реляційними, такі як Oracle, SQL Server, MySQL, Sybase, DB2, TeraData і так далі.
Причини такого домінування є неочевидними. Протягом усього існування реляційних БД вони постійно пропонували найкращу суміш простоти, стійкості, гнучкості, продуктивності, масштабованості та сумісності у сфері управління даними.
Однак, щоб забезпечити всі ці особливості, реляційні сховища неймовірно складні всередині. Наприклад, простий запит SELECT може мати сотні потенційних шляхів виконання, які оптимізатор оцінить безпосередньо під час виконання запиту. Все це приховано від користувачів, проте всередині РСУБД створює план виконання, що ґрунтується на речах на кшталт алгоритмів оцінки вартості та найкраще відповідає запиту.
Проблеми реляційних БД
Хоча реляційні сховища забезпечують найкращу суміш простоти, стійкості, гнучкості, продуктивності, масштабованості та сумісності, їх показники по кожному з цих пунктів не обов'язково вищі, ніж у аналогічних систем, орієнтованих на якусь одну особливість. Не було великою проблемою, оскільки загальне домінування реляційних СУБД переважувало будь-які недоліки. Проте якщо звичайні РБД не відповідали потребам, завжди існували альтернативи.Сьогодні ситуація трохи інша. Різноманітність додатків зростає, а з ним зростає і важливість перерахованих особливостей. І зі зростанням кількості баз даних, одна особливість починає затьмарювати всі інші. Це масштабованість. Оскільки все більше програм працює в умовах високого навантаження, наприклад, таких як веб-сервіси, їх вимоги до масштабованості можуть дуже швидко змінюватись і сильно зростати. Першу проблему може бути дуже складно вирішити, якщо у вас є реляційна база даних, розташована на власному сервері. Припустимо, навантаження на сервер за ніч збільшилося втричі. Як швидко ви зможете проапгрейдити залізо? Вирішення другої проблеми також викликає труднощі у разі використання реляційних БД.
Реляційні БД добре масштабуються лише у разі, якщо розташовуються на єдиному сервері. Коли ресурси цього сервера закінчаться, вам доведеться додати більше машин і розподілити навантаження між ними. І ось тут складність реляційних БД починає грати проти масштабованості. Якщо ви спробуєте збільшити кількість серверів не до декількох штук, а до сотні або тисячі, складність зросте на порядок, і характеристики, які роблять реляційні БД такими привабливими, стрімко знижують шанси використовувати їх як платформу для великих розподілених систем.
Щоб залишатися конкурентоспроможними, вендорам хмарних сервісів доводиться якось боротися з цим обмеженням, бо яка ж це хмарна платформа без сховища даних, що масштабується. Тому у вендорів залишається лише один варіант, якщо вони хочуть надавати користувачам масштабоване місце для зберігання даних. Потрібно застосовувати інші типи баз даних, які мають більш високу здатність до масштабування, нехай і ціною інших можливостей, доступних у реляційних БД.
Ці переваги, а також існуючий попит на них призвели до хвилі нових систем управління базами даних.
Нова хвиля
Такий тип баз даних прийнято називати сховище типу ключ-значення (key-value store). Фактично, жодної офіційної назви не існує, тому ви можете зустріти її в контексті документо-орієнтованих, атрибутно-орієнтованих, розподілених баз даних (хоча вони також можуть бути реляційними), шардованих упорядкованих масивів (sharded sorted arrays), розподілених хеш-таблиць та сховищ типу ключ-значення. І хоча кожна з цих назв вказує на конкретні особливості системи, всі вони є варіаціями на тему, яку ми назватимемо сховище типу ключ-значення.Втім, як би ви його не називали, цей «новий» тип баз даних не такий вже й новий і завжди застосовувався переважно для додатків, для яких використання реляційних БД було б непридатним. Однак без потреби Інтернету та «хмари» в масштабованості ці системи залишалися не дуже затребуваними. Тепер завдання полягає в тому, щоб визначити, який тип сховища більше підходить для конкретної системи.
Реляційні БД та сховища типу ключ-значення відрізняються докорінно і призначені для вирішення різних завдань. Порівняння характеристик дозволить лише зрозуміти різницю між ними, проте почнемо з цього:
Характеристики сховищ
| Реляційна БД | Сховище типу ключ-значення |
|---|---|
| База даних складається з таблиць, таблиці містять колонки та рядки, а рядки складаються із значень колонок. Усі рядки однієї таблиці мають єдину структуру. |
Для доменів можна провести аналогію з таблицями, проте на відміну таблиць для доменів не визначається структура даних. Домен - це така коробка, в яку ви можете складати все, що завгодно. Записи всередині одного домену можуть мати різну структуру. |
| Модель даних 1 визначено заздалегідь. Є строго типізованою, містить обмеження та відносини для забезпечення цілісності даних. |
Записи ідентифікуються за ключом, при цьому кожен запис має динамічний набір атрибутів, пов'язаних із ним. |
| Модель даних заснована на природному поданні даних, що містяться, а не на функціональності програми. |
У деяких реалізація атрибути можуть бути лише рядковими. В інших реалізаціях атрибути мають прості типи даних, які відображають типи, що використовуються у програмуванні: цілі числа, масив рядків і списки. |
| Модель даних піддається нормалізації, щоб уникнути дублювання даних. Нормалізація породжує відносини між таблицями. Відносини пов'язують дані різних таблиць. |
Між доменами, як і всередині одного домену, відносини явно не визначені. |
Жодних join'ів
Сховища типу ключ-значення орієнтовані працювати із записами. Це означає, що вся інформація, що стосується цього запису, зберігається разом з нею. Домен (про який ви можете думати як про таблицю) може містити незліченну кількість різних записів. Наприклад, домен може містити інформацію про клієнтів та замовлення. Це означає, що дані зазвичай дублюються між різними доменами. Це прийнятний підхід, оскільки дисковий простір дешевий. Головне, що він дозволяє всі пов'язані дані зберігати в одному місці, що покращує масштабованість, оскільки зникає необхідність з'єднувати дані з різних таблиць. При використанні реляційної БД, потрібно використовувати сполуки, щоб згрупувати в одному місці потрібну інформацію.
Хоча для зберігання пар ключ-значення потреба у відносинах різко падає, відносини все ж таки потрібні. Такі відносини зазвичай є між основними сутностями. Наприклад, система замовлень мала б записи, які містять дані про покупців, товари та замовлення. При цьому неважливо, ці дані знаходяться в одному домені або в декількох. Суть у тому, що коли покупець розміщує замовлення, вам швидше за все не захочеться зберігати інформацію про покупця та замовлення одного запису.
Натомість, запис про замовлення має містити ключі, які вказують на відповідні записи про покупця та товар. Оскільки в записах можна зберігати будь-яку інформацію, а відносини не визначені у самій моделі даних, система управління базою даних зможе проконтролювати цілісність відносин. Це означає, що ви можете видаляти покупців та товари, які вони замовляли. Забезпечення цілісності даних повністю лягає на додаток.
Доступ до даних
| Реляційна БД | Сховище типу ключ-значення |
|---|---|
| Дані створюються, оновлюються, видаляються та запитуються з використанням мови структурованих запитів (SQL). |
Дані створюються, оновлюються, видаляються та запитуються за допомогою виклику API методів. |
| SQL-запити можуть отримувати дані як з одиночної таблиці, так і з декількох таблиць, використовуючи при цьому з'єднання (join'и). |
Деякі реалізації надають SQL-подібний синтаксис завдання умов фільтрації. |
| SQL-запити можуть містити агрегації та складні фільтри. |
Найчастіше можна використовувати лише базові оператори порівнянь (=, !=,<, >, <= и =>). |
| Реляційна БД зазвичай містить вбудовану логіку, таку як тригери, процедури, що зберігаються і функції. |
Вся бізнес-логіка і логіка підтримки цілісності даних міститься у коді додатків. |
Взаємодія з програмами
Сховища типу ключ-значення: переваги
Є дві чіткі переваги таких систем перед реляційними сховищами.Підходять для хмарних сервісів
Перша перевага сховищ типу ключ-значення полягає в тому, що вони простіші, а значить мають більшу масштабованість, ніж реляційні БД. Якщо ви розміщуєте разом власну систему, і плануєте розмістити дюжину або сотню серверів, яким потрібно справлятися зі зростаючим навантаженням, за вашим сховищем даних, тоді ваш вибір - сховища типу ключ-значення.Завдяки тому, що такі сховища легко і динамічно розширюються, вони також стануть у нагоді вендорам, які надають розраховану на багато користувачів веб-платформу зберігання даних. Така база є відносно дешевим засобом зберігання даних з великим потенціалом до масштабованості. Користувачі зазвичай платять лише за те, що вони використовують, проте їхні потреби можуть зрости. Вендор зможе динамічно та практично без обмежень збільшити розмір платформи, виходячи з навантаження.
Більш природна інтеграція з кодом
Реляційна модель даних та об'єктна модель коду зазвичай будуються по-різному, що веде до деякої несумісності. Розробники вирішують цю проблему за допомогою написання коду, який відображає реляційну модель об'єктну модель. Цей процес не має чіткої та швидко досяжної цінності і може зайняти досить значний час, який міг бути витрачений на розробку самого додатка. Тим часом багато сховищ типу ключ-значення зберігають дані в такій структурі, яка відображається в об'єкти більш природно. Це може значно зменшити час розробки.Інші аргументи на користь використання сховищ типу ключ-значення, на кшталт «Реляційні бази можуть стати незграбними» (до речі, без поняття, що це означає), є менш переконливими. Але перш ніж стати прихильником таких сховищ, ознайомтеся з наступним розділом.
Сховища типу ключ-значення: недоліки
Обмеження в реляційних БД гарантують цілісність даних на найнижчому рівні. Дані, які не задовольняють обмежень, фізично не можуть потрапити до бази. У сховищах типу ключ-значення таких обмежень немає, тому контроль цілісності даних лежить на додатках. Однак у будь-якому коді є помилки. Якщо помилки правильно спроектованої реляційної БД зазвичай не ведуть до проблем цілісності даних, то помилки в сховищах типу ключ-значення зазвичай призводять до таких проблем.Інша перевага реляційних БД у тому, що вони змушують вас пройти через процес розробки моделі даних. Якщо ви добре спроектували модель, то база даних міститиме логічну структуру, яка повністю відображає структуру даних, що зберігаються, проте розходиться зі структурою програми. Таким чином, дані стають незалежними від програми. Це означає, що інший додаток зможе використовувати ті ж дані і логіка програми може бути змінена без будь-яких змін в моделі бази. Щоб зробити те саме зі сховищем типу ключ-значення, спробуйте замінити процес проектування реляційної моделі проектуванням класів, при якому створюються загальні класи, засновані на природній структурі даних.
І не забудьте про сумісність. На відміну від реляційних БД, сховища, орієнтовані використання у «хмарі», мають набагато менше загальних стандартів. Хоча концептуально вони й не відрізняються, вони мають різні API, інтерфейси запитів і свою специфіку. Тому вам краще довіряти вашому вендору, тому що в разі чого ви не зможете легко переключитися на іншого постачальника послуг. А враховуючи той факт, що майже всі сучасні сховища типу ключ-значення знаходяться на стадії бета-версій 2 , довіряти стає ще ризикованішим, ніж у разі використання реляційних БД.
Обмежена аналітика даних
Зазвичай усі хмарні сховища будуються за типом множинної оренди, що означає, що ту саму систему використовує велику кількість користувачів і додатків. Щоб запобігти «захопленню» загальної системи, вендори зазвичай якимось чином обмежують виконання запитів. Наприклад, у SimpleDB запит не може виконуватися довше 5 секунд. У Google AppEngine Datastore за один запит не можна отримати більше 1000 записів 3 .Ці обмеження не страшні для простої логіки (створення, оновлення, видалення та вилучення невеликої кількості записів). Але що якщо ваш додаток стає популярним? Ви отримали багато нових користувачів і багато нових даних, і тепер хочете створити нові можливості для користувачів або якимось чином отримати вигоду з даних. Тут ви можете жорстко обламатися з виконанням навіть найпростіших запитів для аналізу даних. Фічі на кшталт відстеження шаблонів використання програми чи системи рекомендацій, заснованої на історії користувача, у разі можуть бути складні у реалізації. А в гіршому – просто неможливі.
У такому випадку для аналітики краще зробити окрему базу даних, яка заповнюватиметься даними з вашого сховища типу ключ-значення. Продумайте заздалегідь, як це можна буде зробити. Чи будете ви розміщувати сервер у хмарі чи у себе? Чи не буде проблем через затримки сигналу між вами та вашим провайдером? Чи підтримує ваше сховище таке перенесення даних? Якщо у вас 100 мільйонів записів, а за один раз ви можете взяти 1000 записів, скільки потрібно перенести всі дані?
Однак не ставте масштабування понад усе. Вона буде марна, якщо ваші користувачі вирішать користуватися послугами іншого сервісу, тому що той надає більше можливостей та налаштувань.
Хмарні сховища
Безліч постачальників веб-сервісів пропонують розраховані на багато користувачів сховища типу ключ-значення. Більшість із них задовольняють критеріям, переліченим вище, проте кожне має свої відмінні фічі та відрізняється від стандартів, описаних вище. Давайте поглянемо на конкретні приклади сховищ, такі як SimpleDB, Google AppEngine Datastore і SQL Data Services.Amazon: SimpleDB
SimpleDB – це атрибутно-орієнтоване сховище типу ключ-значення, що входить до складу Amazon WebServices. SimpleDB знаходиться у стадії бета-версії; користувачі можуть користуватись їй безкоштовно - доти їх потреби не перевищать певну межу.
SimpleDB має кілька обмежень. Перше - час виконання запиту обмежено 5 секундами. Друге – немає жодних типів даних, крім рядків. Все зберігається, витягується та порівнюється як рядок, тому для того, щоб порівняти дати, вам потрібно буде перетворити їх у формат ISO8601. Третє - максимальний розмір будь-якого рядка становить 1024 байта, що обмежує розмір тексту (наприклад, опис товару), який ви можете зберігати як атрибут. Однак оскільки структура даних є гнучкою, ви можете обійти це обмеження, додаючи атрибути «ОписТовара1», «Опис товару2» і т.д. Але кількість атрибутів також обмежена – максимум 256 атрибутів. Поки SimpleDB знаходиться в стадії бета-версії, розмір домену обмежений 10 гігабайтами, а вся база не може займати більше одного терабайта.
Однією із ключових особливостей SimpleDB є використання моделі кінцевої констистенції (eventual consistency model). Ця модель підходить для багатопотокової роботи, проте слід мати на увазі, що після того, як ви змінили значення атрибута в якомусь записі, при наступних операціях читання ці зміни можуть бути не видно. Імовірність такого розвитку подій досить низька, проте про неї треба пам'ятати. Ви ж не хочете продати останній квиток п'ятьом покупцям тільки тому, що ваші дані були неконсистентні в момент продажу.
Google AppEngine Data Store
Google"s AppEngine Datastore побудований на основі BigTable, внутрішньої системи зберігання структурованих даних від Google. AppEngine Datastore не надає прямий доступ до BigTable, але може сприйматися як спрощений інтерфейс взаємодії з BigTable.
AppEngine Datastore підтримує більше типів даних всередині одного запису, ніж SimpleDB. Наприклад, списки, які можуть містити колекції всередині запису.
Швидше за все, ви будете використовувати саме це сховище даних при розробці за допомогою Google AppEngine. Однак, на відміну від SimpleDB, ви не зможете використовувати AppEngine Datastore (або BigTable) поза веб-сервісами Google.
Microsoft: SQL Data Services
SQL Data Services є частиною платформи Microsoft Azure. SQL Data Services є безкоштовною, перебуває у стадії бета-версії і має обмеження розмір бази. SQL Data Services є окремим додатком - надбудову над безліччю SQL серверів, які зберігають дані. Ці сховища можуть бути реляційними, однак для вас SDS є сховищем типу ключ-значення, як і описані вище продукти.
Нехмарні сховища
Існує також ряд сховищ, якими ви можете скористатися за межами хмари, встановивши їх у себе. Майже всі ці проекти є молодими, знаходяться на стадії альфа- або бета-версії, і мають відкритий код. З відкритими вихідними джерелами ви, можливо, будете більше поінформовані про можливі проблеми та обмеження, ніж у разі використання закритих продуктів.CouchDB
CouchDB - це документо-орієнтована БД, що вільно розповсюджується, з відкритим вихідним кодом. Як формат зберігання даних використовується JSON. CouchDB покликана заповнити пробіл між документоорієнтованими та реляційними базами даних за допомогою «уявлень». Такі уявлення містять дані з документів у вигляді, схожим на табличний, і дозволяють будувати індекси і виконувати запити.В даний час CouchDB не є по-справжньому розподіленою базою даних. У ній є функції реплікації, що дозволяють синхронізувати дані між серверами, проте це не та розподіл, яка потрібна для побудови оточення, що високомасштабується. Однак, розробники CouchDB працюють над цим.
Проект Voldemort
Проект Voldemort - розподілена база даних типу ключ-значення, призначена для горизонтального масштабування на великій кількості серверів. Він народився в процесі розробки LinkedIn і використовувався для декількох систем, що мають високі вимоги до масштабованості. У проекті Voldemort також використовується модель кінцевої консистенції.Mongo
Mongo - це база даних, що розробляється в 10gen Гейром Магнуссоном і Дуайтом Мерріменом (якого ви можете знати по DoubleClick). Як і CouchDB, Mongo - це документоорієнтована база даних, що зберігає дані в JSON форматі. Однак Mongo скоріше є об'єктною базою, ніж чистим сховищем типу ключ-значення.
Drizzle
Drizzle представляє зовсім інший підхід до вирішення проблем, з якими покликані боротися сховища типу ключ-значення. Drizzle починався як одна з гілок MySQL 6.0. Пізніше розробники видалили ряд функцій (включаючи уявлення, тригери, скомпіловані вирази, процедури, що зберігаються, кеш запитів, ACL, і частина типів даних), з метою створення більш простої і швидкої СУБД. Тим не менш, Drizzle все ще можна використовувати для зберігання реляційних даних. Мета розробників - побудувати напівреляційну платформу, призначену для веб-додатків та хмарних додатків, що працюють на системах з 16 і більше ядрами.
Рішення
Зрештою, є чотири причини, з яких ви можете вибрати нереляційне сховище типу ключ-значення для вашого застосування:- Ваші дані дуже документо-орієнтовані, і більше підходять для моделі даних ключ-значення, ніж для реляційної моделі.
- Ваша доменна модель об'єктно-орієнтована, тому використання сховища типу ключ-значення зменшить розмір додаткового коду для перетворення даних.
- Сховище даних дешево та легко інтегрується з веб-сервісами вашого вендора.
- Ваша головна проблема - висока масштабованість на запит.
Для решти вимог краще вибрати старі добрі реляційні СУБД. То чи приречені вони? Звичайно, ні. Принаймні поки що.
1 - на мою думку, тут найбільше підходить термін «структура даних», проте залишив оригінальне data model.
2 - швидше за все, автор мав на увазі, що за своїми можливостями нереляційні БД поступаються реляційним.
3 – можливо, дані вже застаріли, стаття датується лютим 2009 року.
Функції СУБД.
Функції СУБД бувають високого та низького рівня.
Функції високого рівня:
1. Визначення даних – з допомогою цієї функції визначається яка інформація зберігатиметься у БД (тип, властивості даних як вони між собою пов'язані).
2. Обробка даних. Інформація може оброблятися різними способами: вибірка, фільтрація, сортування, поєднання однієї інформації з іншого, обчислення підсумкових значень.
3. Управління даними. За допомогою цієї функції вказується, кому дозволено знайомитися з даними, коригувати їх або додавати нову інформацію, а також визначати правила колективного доступу.
Функції низького рівня:
1. Управління даними у зовнішній пам'яті;
2. Управління буферами оперативної пам'яті;
3. Управління транзакціями;
4. Введення журналу змін до БД;
5. Забезпечення цілісності та безпеки БД.
Транзакцією називається неподільна послідовність операцій, яка відстежується СУБД від початку і до завершення, і в якій за невиконання однієї операції скасовується вся послідовність.
Журнал СУБД – особлива БД або частина основної БД, недоступна користувачеві та використовується для запису інформації про всі зміни бази даних.
Введення журналу СУБД призначено для забезпечення надійності зберігання в базі даних за наявності апаратних збоїв та відмов, а також помилок у програмному забезпеченні.
Цілісність бази даних – це властивість БД, що означає, що вона містить повна, несуперечлива і адекватно відбиває предметну область інформація.
Класифікація СУБД.
СУБД можна класифікувати:
1. За видами програм:
a. Сервери БД (наприклад, MS SQL Server, InterBase (Borland)) – призначені в організацію центрів обробки даних у мережах ЕОМ і реалізують функції управління базами даних, запитані клієнтськими програмами з допомогою операторів SQL (тобто програми, які відповідають запити);
b. Клієнти БД - Програми, які запитують дані. Як клієнтські програми можуть використовуватися ПФСУБД, електронні таблиці, текстові процесори, програми електронної пошти;
c. Повнофункціональні БД (MS Access, MS Fox Pro) – програма, що має розвинений інтерфейс, що дозволяє створювати та модифікувати таблиці, вводити дані, створювати та форматувати запити, розробляти звіти та виводити їх на друк.
2. За моделлю даних СУБД (як і БД):
a. Ієрархічні – засновані на деревоподібній структурі зберігання інформації та нагадують файлову систему комп'ютера; основний недолік - неможливість реалізувати відношення багато - до - багатьом;
b. Мережеві - які прийшли на зміну ієрархічним і проіснували недовго тому, що основний недолік - складність розробки серйозних додатків. Основна відмінність мережевої від ієрархічної у цьому, що у ієрархічної структура «запис – нащадок» має лише предка, а мережевий нащадок може мати будь-яку кількість предків;
c. Реляційні – дані яких розміщені у таблицях, між якими існують певні зв'язки;
d. Об'єктно – орієнтовані – в них дані зберігаються у вигляді об'єктів та основна перевага при роботі з ними у тому, що до них можна застосувати об'єктно – орієнтований підхід;
e. Гібридні, тобто об'єктно – реляційні – поєднують у собі можливості реляційних та об'єктно – орієнтованих баз даних. Прикладом такої бази даних є Oracle (раніше вона була реляційною).
3. Залежно від розташування окремих частин СУБД розрізняють:
a. локальні - всі частини якої розташовуються на одному комп'ютері;
b. мережеві.
До мережевих відносяться:
- з організацією файл – сервер;
За такої організації всі дані перебувають у одному комп'ютері, який називається файл – сервер, і який підключений до мережі. При знайденні необхідної інформації передається весь файл, що містить навіть багато надмірної інформації. І лише за створенні локальної копії перебуває необхідна запис.
- з організацією клієнт – сервер;
Сервер БД приймає запит від клієнта, шукає даних потрібну запис і передає її клієнту. Запит до сервера формується мовою структурованих запитів SQL, тому сервери БД називають SQL – серверами.
- розподілені СУБД містять кілька десятків та сотень серверів, розміщених на значній території.
Основні положення реляційної моделі БД.
Реляційною базою даних називається така база даних, у якій усі дані організовані як таблиць, проте операції над цими даними зводяться до операцій над таблицями.
Особливості реляційних баз даних:
1. Дані зберігаються в таблицях, що складаються зі стовпців та рядків;
2. На перетині кожного стовпця та рядка знаходиться одне значення;
3. У кожного стовпця – поля є своє ім'я, яке служить його назвою – атрибут, і всі значення в одному стовпці мають один тип;
4. Стовпці розташовуються у певному порядку, який задається при створенні таблиці, на відміну від рядків, які розташовуються у довільному порядку. У таблиці може бути жодної рядки, але обов'язково має бути хоча б один стовпець.
Термінологія реляційної бази даних:
| Елемент реляційної БД | Форма уявлення |
| 1. База даних | Набір таблиць |
| 2. Схема бази даних | Набір заголовків таблиць |
| 3. Відношення | Таблиця |
| 4. Схема відношення | Рядок заголовків стовпців таблиці |
| 5. Сутність | Опис властивостей об'єкту |
| 6. Атрибут | Заголовок стовпця |
| 7. Домен | Безліч допустимих значень атрибуту |
| 8. Первинний ключ | Унікальний ідентифікатор, що однозначно визначає кожен запис у таблиці |
| 9. Тип даних | Тип значень елементів у таблиці |
| 10. Кортеж | Рядок (запис) |
| 11. Кардинальність | Кількість рядків у таблиці |
| 12. Ступінь відносини | Кількість полів |
| 13. Тіло відносини | Безліч кортежів відносини |
При проектуванні реляційної БД дані розміщують у кількох таблицях. Між таблицями встановлюють зв'язки з допомогою ключів. При зв'язуванні таблиць виділяють основну та додаткову (підлеглу) таблицю.
Існують такі види зв'язків між таблицями:
1. Зв'язок виду 1:1 (один до одного) означає, що кожному запису в основній таблиці відповідає один запис додаткової таблиці і, навпаки, кожному запису додаткової таблиці відповідає один запис в основній таблиці.
2. Зв'язок виду 1: М (один до багатьох) означає, що кожному запису в основній таблиці відповідає кілька записів у додатковій таблиці і, навпаки, кожному запису додаткової таблиці відповідає тільки один запис в основній таблиці.
3. Зв'язок виду М:1 (багатьом до одного) означає, що одному або декільком записам в основній таблиці відповідає лише один запис додаткової таблиці.
4. Зв'язок виду М: М (багатьом до багатьох) – це, коли кільком записам основної таблиці відповідає кілька додаткових записів і навпаки.
5. Основні компоненти MS Access.
Основними компонентами (об'єктами) MS Access є:
1. Таблиці;
3. Форми;
4. Звіти;
5. Макроси:
Модулі.
Таблиця - Це об'єкт, призначений для зберігання даних у вигляді записів (рядків) і полів (стовпців). Кожне поле містить окрему частину запису, а кожна таблиця використовується для зберігання відомостей з одного конкретного питання.
Запит - питання даних, що зберігаються в таблицях, або інструкція на відбір записів, що підлягають зміні.
Форма – це об'єкт, у якому можна розмістити елементи керування, призначені для введення, зображення та зміни даних у полях таблиці.
Звіт – це об'єкт, який дозволяє подати певну користувачем інформацію у певному вигляді, переглядати та роздруковувати її.
Макрос - Одна або кілька макрокоманд, які можна використовувати для автоматизації конкретного завдання. Макрокоманда – основний будівельний блок макросу; самостійна інструкція, яка може бути поєднана з іншими макрокомандами, щоб автоматизувати виконання завдання.
Модуль - Набір описів, інструкцій та процедур, збережених під одним ім'ям. У MS Access є три види модулів: модуль форми, звіту та загальний модуль. Модулі форми та звітів містять локальну програму для форм та звітів.
6. Таблиці у MS Access.
У MS Access є такі методи створення таблиць:
1. режим таблиці;
2. Конструктор;
3. Майстер таблиць;
4. Імпорт таблиць;
5. Зв'язок із таблицями.
У режимі таблиці дані вводяться у порожню таблицю. Для введення даних надається таблиця із 30 полями. Після збереження MS Access сам вирішує, який тип даних привласнити кожному полю.
Конструктор надає можливість самостійно створювати поля, вибирати типи даних для полів, розміри полів та встановлювати властивості полів.
Для визначення поля в режимі Конструктор задаються:
1. Ім'я поля , яке в кожній таблиці повинно мати унікальне ім'я, що є комбінацією букв, цифр, пробілів та спеціальних символів, за винятком « .!” “ ». Максимальна довжина імені 64 символи.
2. Тип даних визначає вид та діапазон допустимих значень, а також обсяг пам'яті, виділений для цього поля.
Типи даних MS Access
| Тип даних | Опис |
| Текстовий | Текст та числа, наприклад, імена та адреси, номери телефонів, поштові індекси (до 255 символів). |
| Поле Memo | Довгий текст та числа, наприклад коментарі та пояснення (до 64000 символів). |
| Числовий | Загальний тип даних для числових даних, що допускають проведення математичних розрахунків, крім фінансових розрахунків. |
| Дата час | Значення дати та часу. Користувач може вибирати стандартні форми або створювати спеціальний формат. |
| Грошовий | Грошові значення. Для фінансових розрахунків не рекомендується використовувати числові типи даних, т.к. можуть округлятися при розрахунках. Значення типу «грошовий» завжди виводяться із зазначеним числом десяткових знаків після коми. |
| Лічильник | Послідовні номери, що автоматично виставляються. Нумерація починається з 1. Поле лічильника зручне створення ключа. Це поле є сумісним із полем числового типу, для якого у властивості Розмір вказано значення «Довге ціле». |
| Логічний | Значення «Так / Ні», «Істинно / Брехня», «Вкл / Вимк», одне з двох можливих значень. |
| Поле об'єкту OLE | Об'єкти, створені в інших програмах, які підтримують протокол OLE. |
3. Найважливіші властивості полів:
- Розмір полязадає максимальний розмір даних, що зберігаються у полі.
- Формат поляє форматом відображення заданого типу даних і визначає правила подання даних при виведенні їх на екран або друк.
- Підпис полязадає текст, який виводиться у таблицях, формах, звітах.
- Умова значеннядозволяє здійснювати контроль введення, задає обмеження на значення, що вводяться, при порушенні умов забороняє введення і виводить текст, заданий властивістю Повідомлення про помилку;
- Повідомлення про помилкузадає текст повідомлення, що відображається на екрані при порушенні обмежень, заданих Умовою на значення.
Тип елемента керування- Властивість, яка задається на закладці Підстановка у вікні конструктора таблиць. Ця властивість визначає, чи відображатиметься поле в таблиці та в якій формі – у вигляді поля або поля зі списком.
Унікальний (первинний) ключтаблиці може бути простим або складовим, що включає кілька полів.
Для визначення ключа виділяються поля, що становлять ключ, і на панелі інструментів натискається кнопка ключове полеабо виконується команда Виправлення / ключове поле.
©2015-2019 сайт
Усі права належати їх авторам. Цей сайт не претендує на авторства, а надає безкоштовне використання.
Дата створення сторінки: 2016-02-16
Модель даних - сукупність структур даних та операцій з їхньої обробки. За допомогою моделі даних можна наочно уявити структуру об'єктів та встановлені між ними зв'язки. Для термінології моделей даних характерні поняття «елемент даних» та «правила зв'язування». Елемент даних визначає будь-який набір даних, а правила зв'язування визначають алгоритми взаємозв'язку елементів даних. На даний час розроблено безліч різних моделей даних, але на практиці використовується три основні. Виділяють ієрархічну, мережну та реляційну моделі даних. Відповідно говорять про ієрархічні, мережеві та реляційні СУБД.
Ієрархічна модель даних. Ієрархічно організовані дані зустрічаються у повсякденному житті дуже часто. Наприклад, структура вищого навчального закладу – це багаторівнева ієрархічна структура. Ієрархічна (деревоподібна) БД складається із впорядкованого набору елементів. У цій моделі вихідні елементи породжують інші елементи, причому ці елементи, у свою чергу, породжують наступні елементи. Кожен породжений елемент має лише один елемент, що породжує.
Організаційні структури, списки матеріалів, зміст у книгах, плани проектів та багато інших сукупностей даних можуть бути представлені в ієрархічному вигляді. Автоматично підтримується цілісність посилань між предками та нащадками. Основне правило: ніякий нащадок не може існувати без батьків.
Основним недоліком даної моделі є необхідність використання ієрархії, яка була закладена в основу БД при проектуванні. Потреба постійної реорганізації даних (а часто неможливість цієї реорганізації) призвели до створення більш загальної моделі - мережної.
Про Модель даних. Мережевий підхід до організації даних є розширенням ієрархічного підходу. Дана модель відрізняється від ієрахічної тим, що кожен породжений елемент може мати більше одного елемента, що породжує. ■
Оскільки мережева БД може представляти безпосередньо всі види зв'язків, властивих даним відповідної організації, за цими даними можна переміщатися, досліджувати і вимагати їх усілякими способами, тобто мережева модель не пов'язана лише однією ієрархією. Однак для того, щоб скласти запит до мережевої БД, необхідно досить глибоко вникнути в її структуру (мати під рукою схему цієї БД) та виробити механізм навігації по базі даних, що є суттєвим недоліком цієї моделі БД.
Про Реляційна модель даних. Основна ідея реляційної моделі даних у тому, щоб представити будь-який набір даних як двомірної таблиці. У найпростішому випадку реляційна модель описує єдину двовимірну таблицю, але найчастіше ця модель описує структуру та взаємовідносини між кількома таблицями.
Реляційна модель даних
Отже, метою інформаційної системи є обробка данихпро об'єктахреального світу, з урахуванням зв'язківміж об'єктами. Теоретично БД дані часто називають атрибутами, аоб'єкти - сутностями.Об'єкт, атрибут та зв'язок - фундаментальні поняття І.С.
Об'єкт(або сутність) - це щось існуюче та помітне,тобто об'єктом можна назвати те «щось», для якого існують назва та спосіб відрізняти один подібний об'єкт від іншого. Наприклад, кожна школа – це об'єкт. Об'єктами є також людина, клас у шкільництві, фірма, метал, хімічна сполука тощо. буд. Об'єктами може бути як матеріальні предмети, а й абстрактні поняття, відбивають реальний світ. Наприклад, події, регіони, витвори мистецтва; книги (не як поліграфічна продукція, бо як твори), театральні постановки, кінофільми; правові норми, філософські теорії та ін.
Атрибут(або це)- це деякий показник, який характеризує якийсь об'єкт і приймає для конкретного екземпляра об'єкта деяке числове, текстове чи інше значення. Інформаційна система оперує наборами об'єктів, спроектованими стосовно даної предметної області, використовуючи при цьому конкретні значення атрибутів(даних) тих чи інших об'єктах. Наприклад, візьмемо в якості набору об'єктів класи у школі. Число учнів у класі - це дане, яке набуває числового значення (в одного класу 28, в іншого - 32). Назва класу - це, що приймає текстове значення (в одного - 10А, в іншого - 9Б і т.д.).
Розвиток реляційних баз даних розпочалося наприкінці 60-х, коли з'явилися перші роботи, у яких обговорювалися; можливості використання під час проектування баз даних звичних і природних способів представлення даних - про табличних даталогических моделей.
Основоположником теорії реляційних баз даних вважається співробітник фірми IBM доктор Е. Кодд, який опублікував 6 (червень 1970 статтю A Relational Model of Data для Великої Shared Data Banks(Реляційна модель даних великих колективних банків даних). У цій статті вперше використано термін «реляційна модель даних. Теорія реляційних баз даних, розроблена в 70-х роках США доктором Е. Коддом, має під собою потужну математичну основу, що описує правила ефективної організації даних. Розроблена Е. Коддом теоретична база стала основою розробки теорії проектування баз даних.
Е. Кодд, будучи математиком за освітою, запропонував використовувати для обробки даних апарат теорії множин (об'єднання, перетин, різницю, декартове твір). Він довів, що будь-який набір даних можна подати у вигляді двовимірних таблиць особливого виду, відомих у математиці як «відносини».
Реляційноївважається така база даних, де всі дані представлені для користувача у вигляді прямокутних таблиць значень даних, і всі операції над базою даних зводяться до маніпуляцій з таблицями.
Таблиця складається з стовпців (полів)і рядків (записів);має ім'я, унікальне всередині бази даних. Таблицявідображає тип об'єктареального світу (Сутність),а кожна її рядок-конкретний об'єкт.Кожен стовпець таблиці – це сукупність значень конкретного атрибута об'єкта. Значення вибираються з багатьох можливих значень атрибута об'єкта, яке називається доменом (domain).
У найзагальнішому вигляді домен визначається завданням деякого базового типу даних, якого ставляться елементи домену, і довільного логічного висловлювання, застосовуваного до елементів даних. Якщо під час обчислення логічного умови щодо елемента даних у результаті отримано значення «істина», цей елемент належить домену. У найпростішому випадку домен визначається як допустима потенційна множина значень одного типу. Наприклад, сукупність дат народження всіх працівників становить «домен дат народження», а імена всіх працівників становлять «домен імен співробітників». Домен дат народження має тип даних, що дозволяє зберігати інформацію про моменти часу, а домен імен співробітників повинен мати символьний тип даних.
Якщо два значення беруться з одного й того самого домену, можна виконувати порівняння цих двох значень. Наприклад, якщо два значення взяті з домену дат народження, можна порівняти їх і визначити, хто зі співробітників старший. Якщо ж значення беруться з різних доменів, їх порівняння не допускається, оскільки, ймовірно, воно немає сенсу. Наприклад, із порівняння імені та дати народження співробітника нічого певного не вийде.
Кожен стовпець має ім'я, яке зазвичай записується у верхній частині таблиці. При проектуванні таблиць у межах конкретної СУБД є можливість вибрати кожного поля його тип,тобто визначити набір правил щодо його відображення, а також визначити ті операції, які можна виконувати над даними, що зберігаються в цьому полі. Набори типів можуть відрізнятися в різних СУБД.
Ім'я поля має бути унікальним у таблиці, однак різні таблиці можуть мати поля з однаковими іменами. Будь-яка таблиця повинна мати принаймні одне поле; поля розташовані в таблиці відповідно до порядку їх імен при її створенні. На відміну від полів, рядки немає імен; порядок їхнього прямування в таблиці не визначено, а кількість логічно не обмежена.
Так як рядки в таблиці не впорядковані, неможливо вибрати рядок за її позицією - серед них не існує «першого», «другого», «останнього». Будь-яка таблиця має один або кілька стовпців, значення яких однозначно ідентифікують кожен її рядок. Такий стовпець (або комбінація стовпців) називається первинним ключем (primary key). Часто вводять штучне поле, призначене для нумерації записів таблиці. Таким полем, наприклад, може бути його порядковий, який зможе забезпечити унікальність кожного запису таблиці. Ключ повинен мати такі властивості.
Унікальністю.У кожний момент часу жодні два різні кортежі відносини не мають однакового значення для комбінації атрибутів, що входять до ключа. Тобто у таблиці не може бути двох рядків, які мають однаковий ідентифікаційний номер чи номер паспорта.
Мінімальність.Жоден з атрибутів, що входять до ключа, не може бути виключений з ключа без порушення унікальності. Це означає, що не варто створювати ключ, що включає номер паспорта, ідентифікаційний номер. Достатньо використовувати будь-який із цих атрибутів, щоб однозначно ідентифікувати кортеж. Не варто також включати ключ неунікальний атрибут, тобто забороняється використання в якості ключа комбінації ідентифікаційного номера та імені службовця. За винятком імені службовця з ключа все одно можна унікально ідентифікувати кожен рядок.
Кожне відношення має, принаймні, один можливий ключ, оскільки сукупність усіх його атрибутів задовольняє умову унікальності - це випливає із визначення відносини.
Один з можливих ключів довільно вибирається в як первинний ключ.Інші можливі ключі, якщо вони є, приймаються за альтернативні ключі.Наприклад, якщо як первинний ключ вибрати ідентифікаційний номер, то номер паспорта буде альтернативним ключем.
Взаємозв'язок таблиць є найважливішим елементом реляційної моделі даних. Вона підтримується зовнішніми ключами (foreign key).
При описі моделі реляційної бази даних однієї й тієї ж поняття часто використовують різні терміни, що від рівня описи (теорія чи практика) і системи (Access, SQL Server, dBase). У табл. 2.3 наведено зведену інформацію про терміни, що використовуються.
Таблиця 2.3.Термінологія баз даних
Теорія БД____________ Реляційні БД_________ SQL Server __________
Відношення (Relation) Таблиця (Table) Таблиця (Table)
Кортеж (Tuple) Запис (Record) Рядок (Row)
Атрибут (Attribute) Поле (Field) _______________ Стовпець або колонка (Column)
Реляційні бази даних
Реляційна база даних- це сукупність відносин, містять всю інформацію, що має зберігатися у базі даних. Тобто база даних представляє набір таблиць, необхідні зберігання всіх даних. Таблиці реляційної бази даних логічно пов'язані між собою. Вимоги до проектування реляційної бази даних у загальному вигляді можна звести до кількох правил.
Кожна таблиця має унікальне в базі даних ім'я і складається з однотипних рядків.
Кожна таблиця складається з фіксованого числа стовпців і значень. В одному стовпці рядка не може бути збережено більше одного значення. Наприклад, якщо є таблиця з інформацією про автора, дату видання, тираж і т. д., то в стовпці з ім'ям автора не може зберігатися більше одного прізвища. Якщо книга написана двома та більше авторами, доведеться використовувати додаткові таблиці.
В жодному моменті часу в таблиці не знайдеться двох рядків, що дублюють один одного. Рядки мають відрізнятися хоча б одним значенням, щоб була можливість однозначно ідентифікувати будь-який рядок таблиці.
Про Кожен стовпчик присвоюється унікальне в межах таблиці ім'я; йому встановлюється конкретний тип даних, щоб у цьому стовпці розміщувалися однорідні значення (дати, прізвища, телефони, грошові суми тощо. буд.).
Повний інформаційний зміст бази даних представляється у вигляді явних значень самих даних, і такий метод подання є єдиним. Наприклад, зв'язок між таблицями здійснюється на основі даних, що зберігаються у відповідних стовпцях, а не на основі будь-яких покажчиків, штучно визначальних зв'язку.
Про Під час обробки даних можна вільно звертатися до будь-якого рядка або будь-якого стовпця таблиці. Значення, що зберігаються в таблиці, не накладають жодних обмежень на черговість звернення до даних. Опис стовпців,
Рівень 1:Рівень зовнішніх моделей – це найвищий рівень, де кожна модель має своє бачення даних. Цей рівень визначає точку зору бази даних окремих додатків.
Концептуальний рівень:Центральне керуюче ланка, де тут БД представлена найбільш загальному вигляді, який об'єднує дані використовувані всіма додатками. Фактично концептуальний рівень відбиває узагальнену модель предметної область.
Фізичний рівень (База даних):Це самі дані розташовані у файлах або сторінкових структурах, розташованих на зовнішніх носіях інформації.
Моделі даних
Виділяють такі моделі даних:
1. Інфологічні
2. Дата логічні
3. Фізичні
Процес проектування баз даних починається із проектування інфологічної моделі. Інфологічна модель даних - це узагальнений неформальний опис створюваної БД, виконаний з використанням природної мови, математичних формул, таблиць, графіків та ін. засобів зрозумілих усім людям, що працюють над проектуванням БД.
Кортеж доменів
Інфологічна модель відображає реальний світ у певній зрозумілій людині концепції, повністю незалежної від середовища зберігання даних. Тому Інфологічна модель не повинна змінюватися до тих пір, поки якісь зміни в реальному світі не вимагатимуть зміни поза визначенням, щоб ця модель продовжувала відображати предметну область.
Існує безліч підходів до побудови цієї моделі: графові моделі, семантичні мережі, сутність зв'язок та інші.
Даталогічна модель
Інфологічна модель має бути відображена у даталогічній моделі, зрозумілій СУБД. Даталогічна модель - це формальний опис інфологічної моделі мовою СУБД.
Ієрархічна модель
Ця модель є сукупністю пов'язаних елементів, що утворюють ієрархічну структуру. До основних понять ієрархії відносяться рівень, вузол та зв'язок.
зв'язок рівень
Вузлом називається сукупність атрибутів даних, що описують деякий об'єкт. Кожен вузол пов'язаний з одним вузлом вищого рівня та з будь-якою кількістю вузлів нижнього рівня. Винятком є вузол найвищого рівня. Кількість дерев у базі даних визначається кількістю коренів дерев. До кожного запису бази даних існує єдиний шлях від кореневого запису. Простим прикладом може служити система доменних імен в інтернеті адресу. На першому рівні (корінь дерева) лежить наша планета - земля, на другому - Країна, на третьому - Регіон, на четвертому - населений пункт, вулиця, будинок, квартира. Типовим представником є СУБД від IBM – IMS.
Усі екземпляри даного типу нащадка із загальним екземпляром типу предка називається близнюками. Для бази даних визначено повний порядок обходу. Зверху вниз та з права наліво.
Фізична модель
За підсумками даталогической моделі будується фізична модель. Фізична організація даних надає основний вплив на експлуатаційні показники бази даних. Розробники СУБД намагаються створити найбільш продуктивні фізичні моделі даних, пропонуючи користувачам той чи інший інструментарій, для налаштування моделі для конкретної БД.
Приклад: Зокрема, для реляційної БД вона вже враховує:
1. Фізичні аспекти зберігання таблиць у певних файлах.
2. Створення індексів, що оптимізують швидкості операцій над даними за допомогою програми.
3. Виконання різних дій над даними при певних подіях, що визначаються користувачам за допомогою тригерів і процедур, що зберігаються.
Інфологічні моделі ХФізичні моделі
Для всіх рівнів та для будь-якого методу подання предметної області лежить кодування понять відносин між поняттями. Ключовим етапом розробки будь-якої інформаційної системи є проведення системного аналізу:
Формалізація предметної галузі та уявлення системи як сукупності компонентів.
Композиція як основа системного аналізу може бути функціональною (побудова ієрархії).
Однак у більшості систем, якщо говорити про бази даних, типи даних є більш статичним елементом, ніж способи їх обробки. Тому отримали інтенсивний розвиток такі методи системного аналізу, як діаграма потоків data flown diagram. Розвиток реляційних БД. Стимулювала розвиток побудови методик розвитку даних, зокрема ER, діаграм ER. Реляційна модель даних як відображення безпосередньо використовує поняття відносини. Вона найближче перебуває до концептуальної моделі представлення даних. І часто є основою її.
На відміну від теоретика графових моделей, у реляційній моделі зв'язки між відносинами реалізуються не явним способом для чого використовують ключі відносин. Наприклад, відносини ієрархічного типу реалізується механізмом первинних і зовнішніх ключів, коли у підпорядкованому відношенні має бути факт атрибутів.
Такий атрибут відносин переважно відносин називатиметься первинним ключем, а підлеглому вторинним.
Прогрес у галузі розробки мов програмування пов'язаних насамперед із типізацією даних та появою об'єктно-орієнтованих мов дозволило підійти до аналізу складних систем з погляду ієрархічних уявлень, тобто за допомогою класів об'єктів із властивостями поліморфізму, успадкування, інкапсуляція.
СТАВЛЕННЯ ЦЕ ТАБЛИЦЯ.
Видалення те, що створили і
Редагування.
Реляційна модель бази даних
Реляційні моделі даних в даний час набули найбільшої популярності саме за таке подання даних.
Реляційну модель можна як особливий спосіб подання даних, що містить власні дані (як таблиць), і методи роботи і маніпуляції із нею (як зв'язків). Реляційна модель передбачає три концептуальні елементи: Структура, Цілісність та Обробка даних. У цих елементах є свої обов'язкові поняття, які для подальшого викладу необхідно пояснити.
Таблиця сприймається як безпосереднє сховище даних. Традиційно у реляційних системах таблицю називають ставленням.Рядок таблиці називають кортежем, а стовпець атрибутом. При цьому атрибути мають унікальні імена (у межах відношення).
Кількість кортежів у таблиці називають кардинальним числом. Кількість атрибутів ступенем.Для відношення встановлюють унікальний ідентифікатор, тобто один або кілька атрибутів, значення яких одночасно не бувають однаковими – ідентифікатор називають первинним ключем.Доменце безліч допустимих однорідних значень у тому чи іншого атрибута. Таким чином, домен можна розглянути як іменовану множину даних, причому складові цієї множини є логічно не поділеними одиницями (в якості домену можуть виступати наприклад перелік прізвищ співробітників установи, проте не всі прізвища можуть бути присутніми в таблиці).
SUMMСтавлення
атрибути
Поля KOD, NAME, SUMM – це атрибути таблиці, що містяться в заголовку.
Пари KOD 5216, NAME Кірєєва, SUMM 25.50 є елементами тіла відношення.
У Реляційних базах даних на відміну від інших моделей користувач вказує, які дані для нього необхідні, а не те, як це робити. З цієї причини процес переміщення та навігації по базі даних у реляційних системах є автоматичним, а це завдання у СУБД виконує оптимізатор.Його робота полягає в тому, щоб найбільш ефективним способом зробити вибірку даних з бази даних на запит. Таким чином, оптимізатор принаймні повинен визначити з яких таблиць вибираються дані наскільки багато інформації в цих таблицях і який фізичний порядок запису в таблицях і як вони згруповані.
Крім того, реляційна БД виконує і функції каталогу. У каталозі зберігається опис всіх об'єктів у тому числі складається база даних: таблиць, індексів, тригерів тощо. Вочевидь, що життєво необхідно правильної роботи всієї системи, такий компонент як оптимізатор. Оптимізатор використовує інформацію, що зберігається в каталозі. Цікавий той факт, що каталог сам є набором таблиць, тому СУБД може маніпулювати ним традиційними способами, не вдаючись до якихось особливих прийомів та методів.
Домени та відносини
Основні визначення: Домени, види стосунків, предикати.
Відносини має ряд основних властивостей:
1. У загальному випадку у відносинах немає загальних кортежів – це випливає із самого визначення відносин. Однак для деяких СУБД у ряді випадків допускається відступ від цієї властивості. Поскільки у відносин має місце первинний ключ, однакові кортежі – виключені.
2. Кортежі не впорядковані згори донизу – відносно просто немає поняття позиційного номера. У відносинах без втрати інформації можна з успіхом розташувати кортежі в будь-якому порядку.
3. Атрибути не впорядковані зліва направо. Атрибути в заголовку відносин можна розташовуєтесь у будь-якому порядку, при цьому цілісність даних не порушується. Тому поняття позиційного номера щодо атрибуту також немає.
4. Значення атрибутів складаються з логічно не поділених одиниць – це випливає з того, що значення беруться з доменів, інакше можна сказати, що відносини не містять груп повторень. Тобто нормалізовані.
У реляційних системах підтримується кілька видів відносин:
1. Іменовані являють собою змінні відносини, що визначаються в СУБД шляхом операторів створення і як правило необхідні для більш зручного подання інформації для користувача.
2. Базові відносини є безпосередньо важливою частиною БД, тому під час проектування їм дають власну назву.
3. Похідне відношення це те, що було визначено через інші, як правило базові, відносини шляхом використання коштів СУБД.
4. Подання це фактично є іменованим похідним ставленням, при цьому подання виражається виключно через оператори СУБД, застосовані до іменованих відносин, тому їх фізично БД не існує.
5. Результат запитів це іменоване похідне ставлення містить дані (результат конкретного запиту). Результат у БД не зберігається, а існує до тих пір, поки він необхідний користувачеві.
6. Зберігається відношення це те, що фізично підтримуються в пам'яті відносин, до збережених відносин найчастіше відносяться база відносин. Виходячи з вищесказаного, можна визначити реляційну базу даних як набір відносин, пов'язаних між собою.
Зв'язок у разі це асоціювання двох чи більше відносин.
| KOD | ADRES |
∞ Бінарний зв'язок
| Студенти |
| Викладачі |
| Розклад занять |
| ∞ |
| ∞ |
| ∞ |
| Студенти |
Тернарні зв'язки
Цілісність даних
У реляційних моделях питанню цілісності даних відводять особливу увагу. Нагадаємо, що ключ або потенційний ключ це мінімальний набір атрибутів, за значеннями яких можна однозначно знайти необхідний кортеж, мінімальність означає що виняток з набору будь-якого атрибуту не дозволяє ідентифікувати кортеж по атрибутах, що залишилися.
Кожне відношення має хоча б один можливий ключ. Один із них приймається за первинний ключ.
При виборі первинного ключа слід віддавати перевагу не складеним ключам або ключам, що складаються з мінімального набору атрибутів. Небажано також використовувати ключі з довгими текстовими значеннями (Переважно використовувати як ключі цілочисленні атрибути) . Так для ідентифікації працівника можна використовувати або унікальний табельний номер, номер паспорта, або набір з прізвищ імені по батькові та номера відділу. Не допускається що первинний ключ відносини, тобто будь-який атрибут бере участь у первинному ключі приймав невизначені значення. У цьому випадку виникне суперечлива ситуація ( колізія): З'явиться елемент первинного ключа, що не володіє унікальністю. Тому при проектуванні бази даних слід ретельно стежити.
Про зовнішні ключі. Варто відзначити, що відношення З пов'язує відносини B і А, воно повинно включати зовнішні ключі, що відповідає первинним ключам відносинам А і В.
Зовнішній ключ таблиці формується з допомогою кількох первинних ключів інших таблиць.
Таким чином при розгляді проблеми вибору способу зв'язку відносини в базі даних виникає питання про те, які повинні бути зовнішні ключі. При цьому для кожного зовнішнього ключа необхідно вирішити проблему, пов'язану з можливістю (або неможливістю) появи у зовнішніх ключах невизначених значень (NULL – значень-значення атрибуту для відсутньої інформації). Іншими словами, чи може існувати певний кортеж у відносинах, для якого не відомий кортеж у зв'язаних з ним відношенні?
З іншого боку, необхідно заздалегідь обміркувати питання про те, що відбудеться при видаленні кортежів з відношення на який посилається зовнішній ключ. При цьому існують такі можливі можливості:
· Операція каскадується– тобто видалення кортежів у відносинах призводить до видалення кортежів, пов'язаних ставленням. Наприклад, видалення інформації про прізвище імені тощо. співробітника в одному відношенні призводить до видалення його заробітної плати в іншому відношенні;
· Операція обмежується -тобто видаляються лише ті кортежі для яких пов'язаної інформації в іншому відношенні немає. Не вся інформація видаляється (не у всіх відносинах) оскільки вона може бути використана в іншому відношенні, видалення інформації в якому веде до порушення цілісності даних. Якщо така інформація є, то видалення здійснити не можна, наприклад, видалення інформації про ім'я, прізвище і т.п. співробітника можливе лише в тому випадку, якщо інформація у зв'язаному відношенні про його заробітну плату відсутня.
Потрібно передбачити технологію того, що відбуватиметься при спробі оновлення первинного ключа відносини, на які посилається деякий зовнішній ключ. Тут є ті ж можливості, як і при видаленні:
· Операція каскадується тобто при оновленні первинного ключа відбувається оновлення зовнішнього ключа у зв'язаному відношенні. Наприклад, оновлення первинного ключа щодо, де зберігається інформація про співробітника, призводить до оновлення зовнішнього ключа щодо інформації про заробітну плату.
· Операція обмежується тобто оновлюються лише ті первинні ключі для яких пов'язаної інформації в іншому відношенні немає. Якщо така інформація є, то оновлення зробити не можна. Наприклад, оновлення первинного ключа щодо, де зберігається інформація про співробітника, можлива лише в тому випадку, якщо інформація про його заробітну плату у зв'язаному відношенні відсутня.
Реляційна алгебра
Формальною основою бази реляційної моделі БД є реляційна алгебра, заснована на теорії множин і що розглядає спеціальний оператор над відносинами, і реляційне обчислення, що базуються на математичній логіці.
| твір |
| А А А Б В В | Р Г Д |
| Г Д |
| А |
| А Б В | Р Г Д | Ж Ж З |
Слід зазначити що реляційна алгебра має велику потужність - складні запити до базі може бути виражені з допомогою одного висловлювання. Саме тому ці механізми включені в реляційну модель даних. Будь-який запит, що виражається за допомогою одного виразу реляційної алгебри, або однією формулою реляційного обчислення, може бути виражений за допомогою одного оператора цієї мови.
Реляційна алгебра має важливу властивість - вона замкнута щодо поняття відносини. Це означає, що вираз реляційної алгебри виконується над відносинами реляційних баз даних і результати їх обчислення також є відносинами.
Основна ідея реляційної алгебри полягає в тому, що засоби маніпулювання відносинами, що розглядаються як безліч, засновані на традиційних множинних операціях, доповнених деякими специфічними операціями для БД.
Опишемо варіант алгебри, який був запропонований КОДДОМ. Операція складається з 8 основних операторів:
· Вибірка відносини (унарна операція)
· Проекція відносини (унарна операція)
· Об'єднання відносин
· Перетин відносин (бінарна операція)
· Віднімання відносин
· Твір відносин
· З'єднання відносин
· Поділ відносин
Ці операції можна пояснити так:
· Результатом вибірки відносини за деякою умовою є відношення який включає тільки ті кортежі початкового відношення, які задовольняють цій умові.
· При здійсненні проекції відношення на заданий набір його атрибутів буде отримано відношення кортежу якого взято з відповідних кортежів першого відношення.
· При виконанні операції об'єднання двох відносин буде отримано відношення, що включає всі кортежі, що входять в хоча б одне з відносин, що беруть участь в операції.
· При виконанні операції перетину двох відносин буде отримано відношення, що включає всі кортежі, що входять в обидва початкові відносини.
· При виконанні операції віднімання двох відносин буде отримано відношення, що включає всі кортежі, що входять у перше відношення, крім тих, які також входять і в друге відношення.
· При виконанні прямого твору двох відносин виходить відношення кортежу якого є поєднанням кортежів першого та другого відношення.
· При поєднанні двох відносин за деякою умовою утворюється результуюче відношення кортежів якого є поєднанням кортежів першого та другого відносин, що задовольняють цій умові.
· Операція реляційного поділу має два операнда - бінарна тобто (що складається з двох атрибутів) і унарна (що складається з одного атрибуту) відносини. Результат операції є відношення що складається з кортежів, що включають відношення першого атрибуту кортежів першого відношення, причому таких, що безліч значень другого атрибута збігається з безліччю значень другого відношення.
Крім вище перелічених є ряд спеціальних операцій характерних до роботи з базами даних:
· В результаті операції перейменування виходить відношення набір кортежів, якого збігається з тілом первісного відношення, але імена атрибутів змінені.
Звідси випливає, що результатом реляційної операції є деяке відношення, то є можливість утворювати реляційні вирази в яких замість первісного відношення (операнда), буде використовуватися вкладене реляційне вираз. Це відбувається тому факту, що операція реляційної алгебри справді замкнуті щодо поняття відносини. Почнемо з операції об'єднання відносинОднак це однаково стосується і операцій перетину і поєднання, тобто в реляційній алгебри результатом операції об'єднання є відношення. Якщо допустити у реляційній алгебрі можливість об'єднаннядовільних двох відносин з різними наборами атрибутів, то результатом такої операції буде безліч, проте безліч різнотипних кортежів, тобто взагалі не відношення. Якщо виходити з вимоги замкнутості реляційної алгебри щодо поняття відношення, то така операція об'єднанняє безглуздою. Це призводить до появи поняття сумісності відносинпо об'єднанню: два відносини сумісні тільки в тому випадку, коли мають однакові заголовки, тобто має той же набір імен атрибутів, і однойменні атрибути визначені в тому ж домені.
За умови, що два відносини сумісні по об'єднанню, при звичайному виконанні над ними операції об'єднання перетину віднімання результатом операції є відношення з коректно визначеним заголовком, що збігається із заголовком кожного з відносин - операндів. Якщо ж два стосунки не повністю сумісні по об'єднанню, тобто сумісні у всьому крім імен атрибутів, то до виконання операції типу з'єднання ці відносини можна зробити повністю сумісними по об'єднанню шляхом застосування операції перейменування.
Операція прямого добутку двох відносин викликає нові проблеми. У Теорії множин прямий твір може бути отриманий для будь-яких множин. Елементи результуючої множини будуть пари, складені з елементів першої та другої множини. Оскільки відносини є множинами, то для будь-яких двох відносин можливе отримання прямого твору. Однак результат не буде відношенням. Елементами результату будуть не кортежі, а пари кортежів. Тому в реляційній алгебрі використовується спеціальна форма операції взяття прямого твору – розширений прямий твір відносин. При взятті розширеного прямого твору двох відносин елементом результуючого відношення є кортеж, що формується при злитті одного кортежу першого відношення, та одного кортежу другого відношення. Тут же виникає друга проблема, пов'язана з отриманням коректно сформованого заголовка результуючого відношення, це призводить до необхідності введення поняття сумісності відносин щодо взяття розширеного прямого твору.
Два відносини сумісні щодо взяття прямого твору лише тому випадку, якщо безліч імен атрибутів цих відносин не перетинаються. Будь-які два відносини можуть бути перетворені до сумісного виду взяття прямого твору шляхом застосування операції перейменування до одного з цих відносин.
Операція вибірки вимагає наявності двох відносин: початкового відношення – операнда, та простої умови обмеження. В результаті виконання операції вибірки проводиться відношення заголовок якого збігається із заголовком відношення операнда, а в тіло входять ті кортежі відношення операнда, які задовольняють значення умов обмеження.
Введемо низку операторів.
Нехай union означає операцію об'єднання, intersect - операція перетин, minus - операція віднімання. Для позначення операції вибірки використовуватимемо конструкцію A where B , де А - відношення операнд, а В проста умова порівняння. Нехай С1 і С2 дві прості умови вибірки
A where C1 AND C2 ідентично (A where C1) intersect (A where C2)
A where C1 OR C2 ідентично (A where C1) union (A where C2)
A where C1 not C2 ідентичний (A where C1) minus (A where C2)
З використанням цих визначень можна реалізувати операції вибірки, в яких умовою вибірки є довільний логічний вираз, складений з простих умов з використанням логічних зв'язків (and, or, not). Операція взяття проекцій відношення А про список атрибутів а1, а2,…,an буде відношення заголовком якого є безліч атрибутів, а1,а2,…,an. Тіло результату буде складатися з кортежів для яких щодо А є кортеж, атрибут а1 має значення b1 атрибут а2 значення b2< и так далее атрибут an – bn. По сути при выполнении операции проекции определяется «Вертикальная» вырезка отношения - операнда с удалением возникающих кортежей –дубликатов.
Операція з'єднання, звана іноді з'єднанням за умовою вимагає наявності двох операндів - відносин, що з'єднуються, і третього операнда - проста умова. Нехай з'єднується відношення А і В. Як і у випадку операції вибірки, умова сполуки С має вигляд, (а comp –op b) або (а comp –op const) де А та В імена атрибутів відносин А та В, const-літерально задана константи. Comp-op – допустима у цьому контексті операція порівняння. Тоді за визначенням результатом операції з'єднання є відношення, одержуване шляхом виконання операції обмеження, за умовою С прямого твору відношення А і В.
Є важливий окремий випадок з'єднання, природне з'єднання. Операція з'єднання називається операцією природного з'єднання, якщо умови з'єднання має вигляд (а=в) де а і атрибути різних операндів з'єднання. Цей випадок важливий тому що він часто зустрічається на практиці і для нього існують ефективні алгоритми реалізації в СУБД. Операція природного з'єднання застосовується до парі відносин А і В, які мають загальний атрибут Р, тобто атрибут з одним і тим же ім'ям і визначеним на тому самому домені. Нехай ав позначає об'єднання заголовків відносин А і В. Тоді природне з'єднання це спроектований на ав результат з'єднання А і В. Операції природного з'єднання не включається прямо до складу набору операцій реляційної алгебри, але вона має дуже важливе практичне значення.
Операція поділу відносин потребує докладнішому поясненні оскільки важка розуміння. Нехай задані два відношення А (a1,a2,..,an,b1,b2,…,bm)
B (b1,b2,…,bn) Вважатимемо що атрибут b1 відношення A і атрибут b1 відношення B визначені одному й тому домені. Назвемо множину атрибутів (aj) складовим атрибутом а, множину (bj) cскладовим атрибутом b. Після цього говоритимемо про реляційний поділ бінарного відношення А (а, b) на унарне ставлення B (b).
Результатом поділу А на є унарне відношення С (а), що складається з таких кортежів v що щодо А є кортежі
Оскільки поділ найважча операція пояснимо її прикладом. Нехай у БД студентів є два відносини: СТУДЕНТИ (ПІБ, НОМЕР) та ІМЕНА (ПІБ), причому унарне відношення ІМЕНА містить всі прізвища якими володіють студенти інституту. Тоді після виконання операції реляційного поділу відносини СТУДЕНТИ на відносини ІМЕНА, буде отримано унарне ставлення, яке містить номери студентських квитків, що належать студентам з усіма можливими в цьому інституті прізвищами.
Реляційне числення
Допустимо є база даних, що володіє структурою СТУДЕНТИ (номер, ім'я, стипендія, код групи), і відношення ГРУПИ (гр_ном, гр_кіл, гр старий) Припустимо що необхідно дізнатися імена та номери студ. квитків у студентів, які є старостами груп з кількістю осіб більше 25. У реляційній алгебрі потрібно вжити таких дій для такого запиту:
1. Виконати поєднання відносин СТУДЕНТИ та ГРУПИ, за умовою «студ_ номер = гр_стар»;
2. Обмежити отримане ставлення за умовою гр_кіл>25.
3. Cпроектувати результат попередньої операції на атрибут студ_ім'я, студ_номер.
Тут покроково сформульована послідовність виконання запиту базі даних, кожен із яких відповідає однієї реляційної операції. якщо ж сформулювати той самий запит з використання реляційного обчислення Ми отримали б формулу яку можна прочитати: Видати СТУД_ІМ'Я і СТУД_НОМЕР для таких студентів щоб співіснувала така група ГР_СТАР і значенням ГР_КОЛ>25. У другому формулюванні ми вказали лише характеристики результуючого відношення, але нічого не сказали про спосіб його формування. У цьому випадку СУБД повинна сама вирішити, що за операції і в якому порядку потрібно виконати відносини СТУДЕНТИ і ГРУПИ. Обидва розглянутих у прикладі способу насправді є еквівалентами і існує не дуже складні перетворення з одного в інший.
Базовими поняттями реляційного числення є поняття змінної з певною область її значення, і поняття правильно побудованої формули, що спираються на змінні та спец. Опції. Що є областю визначення змінної різняться обчислення кортежів, і обчислення доменів тобто вздовж або впоперек. У обчисленні кортежів областями визначення змінних є відношення баз даних, тобто допустимим значенням кожної змінної є кортеж деякого відношення. У обчисленні доменів областями визначення змінних є домени на яких визначені атрибути відносин баз даних, тобто допустимим значенням кожної змінної є значення кожної змінної.
| Byte | Integer | String | Char | |
| M | ||||
| | N | |||
| K | ||||
Для визначення кортежу використається команда RANGE. Наприклад, щоб визначити змінну СТУДЕНТ областю визначення якої є СТУДЕНТИ потрібно вжити конструкцію RANGE СТУДЕНТ IS СТУДЕНТИ. З цього визначення випливає, що у будь-який момент часу змінна студент представляє деякий кортеж відносини СТУДЕНТИ. При використанні кортежних змінних у формулах можна посилати значення атрибуту змінних. Наприклад, щоб послатися на значення атрибуту СТУД_ІМ'Я змінної СТУДЕНТ потрібно вжити конструкцію СТУДЕНТ.СТУД_ІМ'Я.
Правильно побудовані формули служать висловлювання умов, накладених на кортежні змінні. В основі таких формул лежать прості порівняння, що являють собою операції порівняння значень атрибутів змінних і літерально заданих констант. Наприклад, конструкція СТУДЕНТ.СТУД_НОМ=123456. Є простим порівнянням. Більше складним варіантом складових формул є з допомогою логічних зв'язків AND, OR, NOT, IF…THEN. Нарешті допускається побудова правильно побудованих формул з допомогою кванторов. Якщо F це правильно побудована формула в якій бере участь змінна var, то конструкція EXIST (квантор існування) var (F) і FORALL (для всіх кортежів) var (F) є правильними.
Змінні, що входять у правильно побудовані формули, можуть бути вільними або пов'язаними. Усі змінні які входять до їх складу при побудову яких використовувалися квантори є вільними. Це означає що якщо для якогось набору значень вільних кортежних змінних при обчисленні формул отримано значення «істина», ці значення можуть входити в результуючі відношення. Якщо ж при побудові формул використовується квантор, то змінні є пов'язаними. При обчисленні значення такої правильно побудованої формули використовується жодне значення пов'язаної змінної, а вся її область визначення.
1)EXISTS СТУД2 (CТУД.1СТУД_СТИП> СТУД2.СТУД_СТИП)
2)FORALL СТУД2 (CТУД.1СТУД_СТИП> СТУД2.СТУД_СТИП)
Нехай СТУД1 і СТУД2 дві кортежні змінні визначені на відношення студенти, тоді формула, для поточного кортежу змінної СТУД1 приймає значення істина тільки в тому випадку якщо у всьому відношенні студенти знайдеться такий кортеж пов'язаний зі змінною СТУД2 що значення його атрибуту СТУД_СТИП у. Правильно побудована формула №2 для збудованого кортежу СТУД 1 приймає значення істина якщо для всіх кортежів відношення СТУДЕНТИ пов'язаних із змінною СТУД 2 значення атрибуту СТУД.СТИП задовольняє внутрішній умові.
Таким чином, правильно побудовані формули забезпечують засоби вираження умови вибірки з відношення баз даних. Щоб можна було використовувати реляційне обчислення для реальної роботи з БД, потрібен ще один компонент, який визначає набір та імена стовпців результуючого відношення. Цей компонент називається цільовим списком.
Цільовий списокмає вигляд:
· Var.attr -ім'я вільної змінної, атр ім'я атрибута відношення на якому визначена змінна var.
· Var що еквівалентно відношенню від списку, Var.attr1, Var.attr1… Var.attr№ включає імена всіх атрибутів визначального відношення.
· New_name = var.attr; нове ім'я відповідного атрибуту результуючого відношення.
Останній варіант потрібен у випадках коду у формулі використовується кілька вільних змінних з однаковою областю визначення. У обчисленні доменів областю визначення доменів є стосунки а домени. Що стосується бд СТУДЕНТИ ГРУПИ можна говорити про доменних змінних ІМ'Я (Значення домену - допустимі імена або НОМ СТУД). (Значення домену припустимі номери студентів).
Основною відмінністю обчислення доменів від обчислення кортежів є наявність додаткового набору предикатів, що дозволяють висловлювати звані умови членства. Якщо R це n-арне відношення з атрибутами (a1, a2, ... an) то умова членства має вигляд R(ai1:Vi1,ai2:Vi2,...aim:Vim) де (m<=n). Где в Vij это либо литерально заданная константа либо имя кортежной переменной. Условие членства принимает значение истина, только в том случае если в отношении R существует кортеж, содержащий следующие значения указанных атрибутов. Если от Vij константа то на атрибут aij накладывается жёсткое условие независящее от текущих доменных переменных. Если же Vij имя доменной переменной то условие членства может принимать различные значения при разных значениях этой переменной.
Предикатом називають логічну функцію, яка деякого аргументу повертає значення істина чи брехня. Відношення може бути розглянуте як предикат з аргументами, що є атрибутами даного ставлення. Якщо заданий конкретний набір кортежів є у відношенні, то предикат видасть справжній результат або хибний.
У всіх інших відносинах формули і вираження обчислення доменів виглядає схожими на формули та вирази обчислення кортежів. Реляційне числення доменів покладено основою більшості мовних запитів, заснованих на використанні форм.
Подібна інформація.
