Ноу Інти, лекція, введення в mysql

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

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

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

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

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

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

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

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

Об'єктно-орієнтовані бази даних

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

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

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

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

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

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

Об'єктно-реляційні бази даних

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

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

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