2. База даних - основа сппр

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

Увага! База даних є моделлю деякої предметної області, яка складається з пов'язаних між собою даних про об'єкти, їх властивості і характеристики.

Інструменти для роботи з базами даних представляють СКБД. Не розв’язуючи безпосередньо ніяких прикладних задач, СКБД є інструментом для розробки прикладних програм, що використовуються БД.

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

Ієрархічна структура передбачала зберігання даних у вигляді дерева. Це значно спрощувало створення і підтримку такої БД. Але неможливість представлення багатьох об’єктів реального світу у виггляді ієрархії призвела до використання таких баз даних у вузькоспеціалізованих сферах. Типовим представником (найбільш відомих і поширеним) ієрархічної СКБД є Information Management System (ІMS) фірми IBM. Перша версія цього продукту з'явився в 1968 році.

Спробою покращити ієрархічну структуру була мережева структура БД, яка передбачає представлення даних у вигляді мережі. Вона заснована на пропозиціях групи Data Base Task Group (DBTG) Комітету по мовах програмування Conference on Data System Languages (CODASYL). Звіт DBTG був опублікований в 1971 році.

Робота з мережевими БД представляє більш складний процес, ніж робота з ієрархічною БД, тому ця структура не знайшла широкого застосування на практиці. Типовим представником мережевих СКБД є Integrated Database Management System (IDMS) компанії Cullinel Software, Inc.

Найбільш поширеними в наш час є реляційні бази даних. Термін "реляційний" походить від латинського слова "relatio" - відношення. Така структура зберігання даних побудована на взаємовідношенні складових її частин. Реляційний підхід став широко відомий завдяки роботам Е.Кодда, які вперше були опубліковані в 1970 році.В них Кодд сформулював наступні 12 правил для реляційної бази даних:

1. Дані представляються у вигляді таблиці. БД представляють собою набір таблиць. Таблиці зберігають дані, згруповані у вигляді рядків та стовпців. Ряд це набір значень, які відносяться лише до одного об'єкту, що зберігається в таблиці, і називається записом. Стовпець представляє собою одну характеристику для всіх об'єктів, які зберігаються в таблиці, і називається полем. Комірка на перетині рядка і стовпця — це значення характеристики відповідного стовпця для обєкта відповідного рядка.

2. Дані доступні логічно. Реляційна модель не дозволяє звертатись до даних фізично, адресуючи комірки по номерах стовпця і рядка (нема можливості отримати значення в комірці (стовпець 2, рядок 3)). Доступ до даних можливий лише через ідентифікатори таблиці, стовпця і рядка. Ідентифікаторами таблиці і стовпця є їх імена. Вони повинні бути унікальними в межах, відповідно, БД і таблиці. Ідентифікатором рядка є первинний ключ — це значення одого чи кілька стовпців, які однозначно ідентифікують рядки. Кожне значення первинного ключа в межах таблиці повинно бути унікальними. Якщо ідентифікація рядка проводиться на основі значень декількох стовпців, то ключ називається складеним.

3. NULL розглядається як невідоме значення. Якщо в комірку таблиці значення не введено, то записується значення NULL. Це не потрібно плутати з порожньою стрічкою чи зі значення 0.

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

5. Повинна використовуватись єдина мова для взаємодії з СКБД. Для керування реляційними базами даних потрібно використовувати спільну мову. В даний час таким інструментом стала мова SQL.

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

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

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

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

10. За цілісність даних відповідає СКБД. Під цілісністю даних в загальному випадку розуміється готовність БД до роботи.

Існують такі типи цілісності:

• фізична цілісність — збереження інформації на носіях і коректність формату зберігання даних;

• логічна цілісність — несуперечність та актуальність даних, що зберігаються в базі даних.

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

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

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

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

На практиці, крім перерахованих правил існує також вимога мінімізації пам'яті, що використовується для бази даних. Це досягається шляхом створення структури бази даних, при якій повторювання (надлишковість) інформація буде зведено до мінімуму. Щоб задовільнити цю вимогу була розроблена теорія нормалізації. Вона включає в себе кілька рівнів нормалізація баз даних, кожен з яких базується на попередньому. Кожному рівню нормалізації відповідає певна нормальна форма (НФ). Залежно від умов, які задовольняє БД, можна сказати, що вона має відповідну нормальну форму. Наприклад:

• БД має першу НФ, якщо кожне значення, що зберігається в ній, нероздільне до більш примітивного (нероздільність значень);

• БД має другу НФ, якщо вона має першу НФ, і при цьому кожне значення цілком і повністю залежить від ключа (функціонально незалежні значення);

• БД має третю НФ, якщо вона має другу НФ, і при цьому жодне значення не надає будь-яку інформацію про інші значення (взаємно незалежні значення), тощо.

На завершення опису реляційної моделі, важливо зазначити, що вона має суттєвий недолік. Справа в тому, що не кожен тип даних може бути представлений у вигляді таблиці, наприклад, зображення, музика, тощо. Однак, в даний час для зберігання такої інформації у реляційних СКБД була спроба використовувати спеціальні типи полів - BLOB (Binary Large OBjects). В них зберігається посилання на відповідну інформацію, яка не включається в БД. Проте, такий підхід не дозволяє оперувати інформацією, яка не розміщена в базі даних, що обмежує можливості по її використанню.

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

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

Увага!

Транзакція – це послідовність операцій, які виконуються над БД, що розглядаються СКБД як єдине ціле. Транзакціz переводить БД з одного цілісного стану в інший.

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

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

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

Історія розвитку СКБД тісно пов'язана з удосконаленням підходів до розв’язку задач збереження даних і управління транзакціями. Розвинутий механізм управління транзакціями в сучасних СКБД зробив їх основним засобом побудови систем OLTP, основним завданням яких є забезпечення виконання операцій з базами даних.

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

До цього класу систем відносяться і перші СППР — інформаційні системи управління (ІСУ, Executive Information System). Такі системи, як правило, засновані на реляційних СКБД, включають в себе підсистеми збору, зберігання та інформаційно-пошукового аналізу інформації, а також містить в собі наперед визначений набір запитів для повсякденної роботи. Кожен новий запит, непередбачений при проектуванні такої системи, повинен спочатку бути формально описаний, закодований програмістом, і лише тоді виконаний. Час очікування в такому випадку може складатись з кількох годин або днів, що неприйнятно для оперативного прийняття рішень.