3.1. Ключі та нормалізація даних: основні нормальні форми (1nf, 2nf, 3nf, bcnf)
Ключ – це стовпець (може бути декілька стовпців), що додається до таблиці і дозволяє встановити зв’язок із записами в іншій таблиці.
Існують ключі двох типів: первинні і вторинні (зовнішні).
Первинний ключ – це одне або кілька полів (стовпців), комбінація значень яких однозначно визначає кожний запис у таблиці. Первинний ключ не допускає значень Null і завжди повинен мати унікальний індекс. Первинний ключ використовується для зв’язування таблиці з зовнішніми ключами в інших таблицях.
Зовнішній (вторинний) ключ – це одне або кілька полів (стовпців) у таблиці, що містять посилання на поле або поля первинного ключа в іншій таблиці. Зовнішній ключ визначає спосіб об’єднання таблиць.
З двох логічно пов’язаних таблиць одну називають таблицею первинного ключа або головною таблицею, а іншу таблицею вторинного (зовнішнього) ключа або підпорядкованою таблицею. СУБД дозволяють зіставити споріднені записи з обох таблиць і спільно вивести їх у формі, звіті або запиті.
Існує три типи первинних ключів: ключові поля лічильника (лічильник), простий ключ і складовий ключ.
Поле лічильника (Тип даних «Счетчик»). Для кожного запису цього поля таблиці автоматично заноситься унікальне числове значення.
Простий ключ. Якщо поле містить унікальні значення, такі як коди чи інвентарні номери, то це поле можна визначити як первинний ключ. В якості ключа можна визначити всі поля, що містить дані, якщо це поле не містить повторювані значення або значення Null.
Складові ключі. У випадках, коли неможливо гарантувати унікальність значень кожного поля, існує можливість створити ключ, що складається з декількох полів. Найчастіше така ситуація виникає для таблиці, використовуваної для зв’язування двох таблиць відношенням “багато – до – багатьох”.
Необхідно ще раз відзначити, що в полі первинного ключа повинні бути тільки унікальні значення в кожному рядку таблиці, тобто збіг не допускається, а в полі вторинного або зовнішнього ключа збіг значень у рядках таблиці допускається.
Якщо виникають труднощі з вибором потрібного типу первинного ключа, то в якості ключа доцільно вибрати поле лічильника.
Програми, які призначені для структурування інформації, розміщення її в таблицях і маніпулювання даними, називаються системами управління базами даних (СУБД). Іншими словами СУБД призначені як для створення та ведення бази даних, так і для доступу до даних. Налічується більше 50 типів СУБД для персональних комп’ютерів. До найбільш поширених відносяться: MS SQL Server, Oracle, Informix, Sybase, DB2, MS Access і т. д.
Нормалізація схеми бази даних — покроковий процес розбиття одного відношення (на практиці: таблиці) відповідно до алгоритму нормалізації на декілька відношень на базі функціональних залежностей.
Нормальна форма — властивість відношення в реляційній моделі даних, що характеризує його з точки зору надмірності, яка потенційно може призвести до логічно помилкових результатів вибірки або зміни даних. Нормальна форма визначається як сукупність вимог, яким має задовольняти відношення.
Таким чином, схема реляційної бази даних переходить у першу, другу, третю і так далі нормальні форми. Якщо відношення відповідає критеріям нормальної форми n та всіх попередніх нормальних форм, тоді вважається, що це відношення знаходиться у нормальній формі рівня n.
Принципи нормалізації
в кожній таблиці БД не повинно бути повторюваних полів;
в кожній таблиці повинен бути унікальний ідентифікатор (первинний ключ);
кожному значенню первинного ключа повинна відповідати достатня інформація про тип суті або про об’єкт таблиці (наприклад, інформація про успішність, про групу або студентах);
зміна значень в полях таблиці не повинна впливати на інформацію в інших полях (крім змін у полях ключа).
Нормальні форми. Перша нормальна форма
Перша нормальна форма (1НФ, 1NF) утворює ґрунт для структурованої схеми бази даних:
Кожна таблиця повинна мати основний ключ: мінімальний набір колонок, які ідентифікують запис.
Уникнення повторень груп (категорії даних, що можуть зустрічатись різну кількість разів в різних записах) правильно визначаючи неключові атрибути.
Атомарність: кожен атрибут повинен мати лише одне значення, а не множину значень.
Друга нормальна форма (2НФ, 2NF) вимагає, аби дані, що зберігаються в таблицях із композитним ключем, не залежали лише від частини ключа:
Схема бази даних повинна відповідати вимогам першої нормальної форми.
Дані, що повторно з'являються в декількох рядках, виносяться в окремі таблиці.
Третя нормальна форма (3НФ, 3NF) вимагає, аби дані в таблиці залежали винятково від основного ключа:
Схема бази даних повинна відповідати всім вимогам другої нормальної форми.
Будь-яке поле, що залежить від основного ключа та від будь-якого іншого поля, має виноситись в окрему таблицю.
Відношення знаходиться в НФБК (нормальна форма Бойса-Кодда) тоді і лише тоді, коли детермінант кожної функціональної залежності є потенційним ключем. Якщо це правило не виконується, то, щоб привести вказане відношення до НФБК, його слід розділити на два відношення шляхом двох операцій проєкції на кожну функціональну залежність, детермінант якої не є потенційним ключем:
Проєкція без атрибутів залежної частини такої функціональної залежності;
Проєкція на всі атрибути цієї функціональної залежності.
Визначення НФБК не потребує жодних умов попередніх нормальних форм. Якщо проводити нормалізацію послідовно, то в переважній більшості випадків при досягненні 3НФ автоматично будуть задовольнятися вимоги НФБК. 3НФ не збігається з НФБК лише тоді, коли одночасно виконуються такі 3 умови:
Відношення має 2 або більше потенційних ключів.
Ці потенційні ключі складені (містять більш ніж один атрибут)
Ці потенційні ключі перекриваються, тобто мають щонайменше один спільний атрибут.
Четверта нормальна форма (4НФ, 4NF) потребує, аби в схемі баз даних не було нетривіальних багатозначних залежностей множин атрибутів від будь чого, окрім надмножини ключа-кандидата. Вважається, що таблиця знаходиться у 4НФ тоді і лише тоді, коли вона знаходиться в НФБК та багатозначні залежності є функціональними залежностями. Четверта нормальна форма усуває небажані структури даних — багатозначні залежності.
П'ята нормальна форма (5НФ, 5NF, PJ/NF) вимагає, аби не було нетривіальних залежностей об'єднання, котрі б не витікали із обмежень ключів. Вважається, що таблиця в п'ятій нормальній формі тоді і лише тоді, коли вона знаходиться в 4НФ та кожна залежність об'єднання зумовлена її ключами-кандидатами.
Нормальна форма домен/ключ. Ця нормальна форма вимагає, аби в схемі не було інших обмежень окрім ключів та доменів.
Шоста нормальна форма
Таблиця знаходиться у 6NF, якщо вона знаходиться у 5NF та задовольняє вимогу відсутності нетривіальних залежностей. Зазвичай 6NF ототожнюють з DKNF.
Нормальна форма Бойса-Кодда (або НФБК, або БКННФ, або 3.5НФ, або BCNF) — нормальна форма використовна в нормалізації баз даних. Це трошки сильніша версія третьої нормальної форми (3НФ). Таблиця знаходиться в НФБК тоді і тільки тоді, коли для кожної її нетривіальної функціональної залежності X → Y, X це суперключ — тобто, X або потенційний ключ, або його надмножина.
НФБК була віднайдена в 1974 Реймондом Бойсом і Едгаром Коддом через деякі типи аномалій з якими не спрацьовувала 3НФ як було заявлено.
Крістофер Дейт вказав, що визначення того, що ми знаємо як НФБК, в 1971 опублікував Ян Хіт.[2] Дейт писав: «Через те, що це визначення випередило визначення Бойса і Кодда на три роки, мені здається, що НФБК по праву має називатись нормальна форма Хіта. Але це не так.»
Лише зрідка таблиця в 3НФ не відповідає вимогам НФБК. Таблиця в 3НФ, яка не має кількох потенційних ключів, що перетинаються, гарантовано в НФБК.[4] Залежно від своїх функціональних залежностей, таблиця в 3НФ з двома або більше потенційними ключами, що перетинаються може бути або не бути в НФБК. Приклад таблиці в 3НФ, яка не є в НФБК:
Кожен рядок в таблиці представляє замовлення корту в тенісному клубі, який має один корт з твердим покриттям (Корт 1) і один з ґрунтовим (Корт 2)
Замовлення визначається замовленим кортом і проміжком часу, на який корт замовлено
Додатково, кожне замовлення має «Тип оплати» асоційований з ним. Існує чотири різних типи оплати:
БЕРЕЖЛИВИЙ, для замовлень корту 1 членами клубу
СТАНДАРТНИЙ, для замовлень корту 1 не членами клубу
ПРЕМІАЛЬНИЙ-A, для замовлень корту 2 членами клубу
ПРЕМІАЛЬНИЙ-Б, для замовлень корту 2 не членами клубу
Потенційні ключі таблиці:
{Корт, Час початку}
{Корт, Час завершення}
{Тип оплати, Час початку}
{Тип оплати, Час завершення}
Згадаймо, що 2НФ забороняє часткові функціональні залежності неключових атрибутів від потенційних ключів, і що 3НФ забороняє транзитивні функціональні залежності неключових атрибутів від потенційних ключів. В таблиці «Замовлення кортів на сьогодні» немає неключових атрибутів: тобто, всі атрибути належать потенційним ключам.
Таблиця не знаходиться в НФБК через залежність «Тип оплати» → «Корт», де визначальний атрибут («Тип оплати») ані потенційний ключ, ані його надмножина.
Залежність «Тип оплати» → «Корт» відображає, що певний тип оплати застосовується саме для одного корту.
Дизайн можна виправити так, щоб він відповідав НФБК:
Потенційними ключами для таблиці «Тип оплати» є {Тип оплати} і {Корт, Членство}; потенційними ключами для таблиці «Сьогоднішнє замовлення» є {Тип оплати, Час початку} і {Тип оплати, Час завершення}. Обидві таблиці знаходяться в НФБК. Тепер мати один тип оплати асоційований з двома різними кортами неможливо, тож можливі аномалії первісної таблиці виключені.
3.2. Основні концепції систем баз даних: модель даних; мова запитів; транзакція; ACID-властивості транзакції, індексування; резервне копіювання та відновлення; розподіленість та реплікація даних; безпека даних
Основою бази даних є модель даних — фіксована система понять і правил для представлення даних структури, стану і динаміки проблемної області в базі даних. У різний час послідовне застосування одержували ієрархічна, мережева і реляційна моделі даних. У наш час усе більшого поширення набуває об'єктно-орієнтований підхід до організації баз даних ГІС.
Ієрархічна структура (модель) будується у вигляді ієрархічної деревоподібної структури, у якій для кожного головного об'єкта існує кілька підлеглих, а для кожного підлеглого об'єкта може бути тільки один головний. На найвищому рівні ієрархії перебуває кореневий об'єкт. Прикладом ієрархічної структури даних може бути організація каталогів на диску, різного роду класифікації, структура державної влади тощо.
Концептуальна схема ієрархічної моделі являє собою сукупність типів записів, пов'язаних типами зв'язків в одним чи кількома деревами. Усі типи зв'язків цієї моделі належать до виду «один до декількох» і зображуються у вигляді стрілок.
Таким чином, взаємозв'язки між об'єктами нагадують взаємозв'язки в генеалогічному дереві, за єдиним винятком: для кожного породженого (підлеглого) типу об'єкта може бути тільки один вхідний (головний) тип об'єкта. Тобто ієрархічна модель даних допускає тільки два типи зв'язків між об'єктами: «один до одного» і «один до декількох». Ієрархічні бази даних є навігаційними, тобто доступ можливий тільки за допомогою заздалегідь визначених зв'язків.
При моделюванні подій, як правило, необхідні зв'язки типу «багато до декількох». Як одне з можливих рішень зняття цього обмеження можна запропонувати дублювання об'єктів. Однак дублювання об'єктів створює можливості неузгодженості даних.
Перевага ієрархічної бази даних полягає в тому, що її навігаційна природа забезпечує швидкий доступ при проходженні вздовж заздалегідь визначених зв'язків. Однак негнучкість моделі даних і, зокрема, неможливість наявності в об'єкта декількох батьків, а також відсутність прямого доступу до даних роблять її непридатною в умовах частого виконання запитів, не запланованих заздалегідь. Ще одним недоліком ієрархічної моделі даних є те, що інформаційний пошук з нижніх рівнів ієрархії не можна спрямувати по вище розміщених вузлах.
У мережевій моделі один і той же об'єкт може одночасно виступати як у ролі головного, так і підлеглого елемента. Це означає, що кожний об'єкт може брати участь у довільній кількості зв'язків. Зв'язок у цьому випадку може встановлюватися явно, коли значення деяких полів є посилання на дані, що містяться в іншому файлі. Прикладом мережевої структури БД може бути структура автобусних маршрутів (із будь-якого населеного пункту існують маршрути в інші).
Подібно до ієрархічної, мережеву модель також можна подати у вигляді орієнтованого графу. Але в цьому випадку граф може містити цикли, тобто вершина може мати кілька батьківських вершин.
Така структура набагато гнучкіша і виразніша від попередньої і придатна для моделювання ширшого класу завдань.
Ієрархічні і мережеві бази даних часто називають базами даних з навігацією. Ця назва відбиває технологію доступу до даних, використовувану при написанні програм обробки мовою маніпулювання даними. При цьому доступ до даних по шляхах, не передбачених при створенні бази даних, може потребувати нерозумно тривалого часу.
Підвищуючи ефективність доступу до даних і скорочуючи таким чином час відповіді на запит, принцип навігації разом з цим підвищує і ступінь залежності програм і даних. Програми обробки даних виявляються жорстко прив'язаними до поточного стану структури бази даних і повинні бути переписані при її змінах. Операції модифікації і видалення даних вимагають перевстановлення покажчиків, а маніпулювання даними залишається записоорієнтованим. Крім того, принцип навігації не дозволяє істотно підвищувати рівень мови маніпулювання даними, щоб зробити його доступним користувачу-непрограмісту чи навіть програмісту-непрофесіоналу. Для пошуку запису-мети в ієрархічній або мережевій структурі програміст повинен спочатку визначити шлях доступу, а потім — крок за кроком переглянути всі записи, що трапляються на цьому шляху.
Наскільки складними є схеми представлення ієрархічних і мережевих баз даних, настільки і трудомістким є проєктування конкретних прикладних систем на їхній основі. Як показує досвід, тривалі терміни розроблення прикладних систем нерідко призводять до того, що вони постійно перебувають на стадії розроблення і доопрацювання. Складність практичної реалізації баз даних на основі ієрархічної і мережевої моделей визначила створення реляційної моделі даних.
У реляційній моделі дані й взаємозв'язки між ними подаються за допомогою прямокутних таблиць. Рядки в реляційній базі даних називають записами, а стовпці — полями. Модель реляційної бази даних була вперше розроблена доктором Е. Ф. Коддом на початку 70-х років XX ст. як більш зручний засіб збереження, вибірки й маніпулювання даними, ніж ієрархічні й мережі бази даних. Модель двовимірної таблиці дозволяє звертатися до даних як по рядках, так і по стовпцях, що є значною перевагою.
Назва «реляційна» (relational) пов'язана з тим, що кожен запис у таблиці даних містить інформацію, яка стосується (related) якогось конкретного об'єкта. Крім того, зв'язані між собою (тобто такі, що знаходяться в певних відношеннях — relations) дані навіть різних типів в моделі можуть розглядатися як одне ціле.
Таблиця має такі властивості:
кожний елемент таблиці являє собою один елемент даних;
повторювані групи відсутні;
усі стовпці в таблиці однорідні; це означає, що елементи стовпця мають однакову природу;
стовпцям присвоєні унікальні імена;
у таблиці немає двох однакових рядків
Порядок розміщення рядків і стовпців у таблиці довільний; таблиця такого типу називається відношенням. У сучасній практиці для рядка використовується термін «запис», а для стовпця термін «поле».
Основною відмінністю пошуку даних в ієрархічних, мережевих і реляційних базах даних є те, що ієрархічні і мережеві моделі даних здійснюють зв'язок і пошук між різними об'єктами за структурою, а реляційні — за значенням ключових атрибутів (наприклад, можна знайти всі записи, значення яких у полі «номер будинку» дорівнює 3, але не можна знайти 3-й рядок).
Оскільки реляційна структура концептуально проста, вона дозволяє реалізовувати невеликі і прості (і тому легкі для створення) бази даних, навіть персональні, сама можливість реалізації яких ніколи навіть і не розглядалася в системах з ієрархічною чи мережевою моделлю.
Недоліком реляційної моделі даних є надмірність по полях (для створення зв'язків між різними об'єктами бази даних).
Майже всі наявні на сьогодні комерційні бази даних і програмні продукти для їх створення використовують реляційну модель даних.
Мови запитів (англ. query languages) — комп'ютерні мови, що використовуються для написання запитів до баз даних та інформаційних систем.
Взагалі мови запитів може бути класифіковано відповідно до того, чи є вони мовами запитів до баз даних, чи інформаційно-пошуковими мовами. Різниця полягає в тому, що мови запитів до баз даних намагаються дати фактичні відповіді на фактичні запитання, а інформаційно-пошукові — знайти документи, що містять інформацію, яка відповідає області запиту.
Прикладами мов запитів є:
.QL[en] — власницька об'єктно-орієнтована мова запитів до реляційних баз даних; наступниця Datalog;
Common Query Language (CQL) — формальна мова для подання запитів до систем інформаційного пошуку, таких як вебіндекси та бібліографічні каталоги.
CQLF (CODASYL Query Language, Flat) — мова запитів до CODASYL-подібних баз даних;
Concept-Oriented Query Language (COQL) — використовується у концептно-орієнтованій моделі. Заснована на новій конструкції та концепті моделювання даних і використовує такі операції, як проєкція та депроєкція для багатовимірного аналізу, аналітичних операцій і висновків;
Cypher[en] — мова запитів до графових баз даних Neo4j;
DMX[en] — мова запитів до моделей добування даних;
Datalog — мова запитів до дедуктивних баз даних;
F-logic[en] — декларативна об'єктно-орієнтована мова для дедуктивних баз даних і подання знань.
FQL[en] дозволяє використовувати SQL-подібний інтерфейс для запиту даних за допомогою Graph API. Це надає додаткові можливості, не доступні у звичайному Graph API[1].
Gellish[en] — мова, що може бути використана для запитів до баз даних Gellish, діалогів (запитів і відповідей), а також інформаційного моделювання та моделювання знань;[2]
Gremlin[en] — мова обходу графів Apache Software Foundation для графових систем OLTP та OLAP.
HTSQL[en] — мова запитів, яка перекладає HTTP-запити мовою SQL;
ISBL — мова запитів для PRTV[en], однієї з перших реляційних систем керування базами даних;
LINQ запити-вирази — спосіб запиту різних джерел даних у мовах .NET
LDAP — прикладний протокол запиту та зміни служб каталогів, які працюють над TCP/IP;
LogiQL — різновид Datalog і мова запитів системи LogicBlox.
MQL[en] — хемоінформатична мова запитів для пошуку підструктур, що дозволяє крім номінальних властивостей чисельні;
MDX[en] — мова запитів для баз даних OLAP;
N1QL — мова запитів Couchbase[en] для пошуку даних на Couchbase Server;
OQL[en] — об'єктна мова запитів;
OCL[en] (мова об'єктних обмежень). Попри свою назву, OCL також є об'єктною мовою запитів і стандартом OMG;
OPath, призначена для використання у запитах до WinFS Stores;
OttoQL, призначена для запиту до таблиць, XML і баз даних;
Poliqarp Query Language — особлива мова запитів, спроєктована для аналізу анотованого тексту. Використовується у пошуковому рушії Poliqarp[en];
PQL[en] — мова програмування спеціального призначення для керування моделями процесів, заснованих на інформації про сценарії, що описуються цими моделями;
QUEL — мова доступу до реляційних баз даних, багато в чому подібна до SQL;
RDQL[en] — мова запитів Resource Description Framework;
ReQL — мова запитів, яка використовується у RethinkDB;[3]
SMARTS[en] — хемоінформатичний стандарт пошуку підструктур;
SPARQL — мова запитів до RDF-графів;
SPL — пошукова мова для згенерованих машиною великих даних, заснована на Unix Piping та SQL.
SCL — Software Control Language для запитів і маніпулювання об'єктами Endevor
SQL — загальновідома мова запитів і мова маніпулювання даними реляційних баз даних;
SuprTool — власницька мова запитів SuprTool, програми доступу до баз даних, що використовується для доступу до даних Image/SQL (колишній TurboIMAGE[en]) та Oracle Database;
TMQL (Topic Map Query Language) — мова запитів Topic Maps[en];
TQL — мова, що використовується для запитів топології продуктів HP[4]
XQuery — мова запитів джерел даних XML;
XPath — декларативна мова для навігації XML-документами;
XSPARQL — інтегрована мова запитів, яка комбінує XQuery зі SPARQL для запитів до джерел даних XML і RDF одночасно;
YQL[en] — SQL-подібна мова запитів, створена Yahoo!
Мови запитів пошукових рушіїв, наприклад, які використовуються Google[5] або Bing[6]
Транза́кція (англ. transaction) — група послідовних операцій з базою даних, яка є логічною одиницею роботи з даними. Транзакція може бути виконана або цілком і успішно, дотримуючись цілісності даних і незалежно від інших транзакцій, що йдуть паралельно, або не виконана зовсім, і тоді вона не може справити ніякого ефекту. Транзакції оброблюються транзакційними системами, в процесі роботи яких створюється історія транзакцій. Транзакції з базою даних використовуються для досягнення наступних цілей:
Забезпечення надійних робочих елементів, які дозволяють правильно відновити роботу у випадку збоїв та зберігати цілісність бази даних у випадку системних відмов, коли виконання операцій зупиняється (повністю або частково) і більшість операцій над базою даних залишаються незавершеними з нез'ясованим статусом.
Для забезпечення роздільного доступу для процесів, що одночасно звертаються до бази даних. При відсутності ізоляції операцій результати, отримані процесами, можуть бути помилковими.
Розрізняють послідовні (звичайні), паралельні і розподілені транзакції. Розподілені транзакції вбачають використання більш ніж однієї транзакційної системи і потребують набагато більш складної логіки (наприклад, two-phase commit — двофазний протокол фіксації транзакції). Також, в деяких системах реалізовані автономні транзакції, або під-транзакції, які є автономною частиною батьківської транзакції.
Приклад: необхідно переказати з банківського рахунку номер 5 на рахунок номер 7 суму в 10 грошових одиниць. Цього можна досягти, наприклад, наведеною послідовністю дій:
Почати транзакцію: прочитати баланс на рахунку номер 5
зменшити баланс на 10 грошових одиниць: зберегти новий баланс рахунку номер 5
прочитати баланс на рахунку номер 7
збільшити баланс на 10 грошових одиниць: зберегти новий баланс рахунку номер 7
Закінчити транзакцію
Ці дії являють собою логічну одиницю роботи «переказ суми між рахунками», і, таким чином, є транзакцією. Якщо перервати дану транзакцію, наприклад, в середині, і не анулювати всі зміни, легко залишити власника рахунку номер 5 без 10 одиниць, тоді як власник рахунку номер 7 їх не отримає.
Властивості транзакцій
Одним з найбільш розповсюджених наборів вимог до транзакцій і транзакційних систем є набір ACID (англ. Atomicity, Consistency, Isolation, Durability). Вимоги ACID були в головному сформульовані наприкінці 70-х років Джимом Ґреєм[1]. Разом з тим, існують спеціалізовані системи з ослабленими транзакційними властивостями[2].
Atomicity — Атомарність. Атомарність гарантує, що ніяка транзакція не буде зафіксована в системі частково. Будуть або виконані всі її складові операції, або не виконано жодної. Оскільки на практиці неможливо одночасно і атомарно виконати всю послідовність операцій усередині транзакції, вводиться поняття «відкат» (англ. rollback): якщо транзакцію не вдається повністю завершити, результати всіх її до сих пір виконаних дій будуть відмінені, і система повернеться до стану на початок транзакції.
Consistency — Узгодженість. Одна з найскладніших і неоднозначних властивостей з четвірки ACID. У відповідності до цієї вимоги, система знаходиться в узгодженому стані до початку транзакції і повинна залишитись в узгодженому стані після завершення транзакції. Не можна плутати вимогу узгодженості з вимогами цілісності (англ. integrity). Останні правила є більш вузькими і, багато в чому, специфічні для реляційних СКБД: є вимоги цілісності типів (англ. domain integrity), цілісності посилань (англ. referential integrity), цілісності сутностей (англ. entity integrity), які не можуть бути порушені фізично в силу особливостей реалізації системи.
Узгодженість є більш широким поняттям. Наприклад, в банківській системі може існувати вимога рівності суми, що списується з одного рахунку, сумі, що зачислюється на інший. Це бізнес-правило і воно не може бути гарантовано тільки перевірками цілісності, його повинні дотриматись програмісти при написанні коду транзакцій. Якщо будь-яка транзакція виконає списання, але не виконає зачислення, то система залишиться в некоректному стані і властивість узгодженості буде порушена.
Нарешті, ще одне зауваження стосується того, що під час виконання транзакції узгодженість не потребується. В нашому прикладі, списання і зачислення будуть, скоріш за все, двома різними підопераціями і між їх виконанням всередині транзакції буде видно неузгоджений стан системи. Однак не треба забувати, що при виконанні вимоги ізоляції, жодним іншим транзакціям ця неузгодженість не буде видна. А атомарність гарантує, що транзакція або буде повністю завершена, або жодна з операцій транзакції не буде виконана. Тим самим ця проміжна неузгодженість є прихованою.
Isolation — Ізольованість. Під час виконання певної транзакції, транзакції, які відбуваються паралельно, не повинні впливати на її результат. Ця властивість не дотримується на рівні ізольованості Repeatable Read та нижче.
Durability — Надійність. Незалежно від проблем на нижніх рівнях (наприклад, при знеструмленні системи чи збоях в обладнанні), зміни, зроблені транзакцією, яка успішно завершена, повинні залишитись збереженими після повернення системи до роботи. Іншими словами, якщо користувач отримав підтвердження від системи, що транзакція виконана, він може бути впевнений, що зміни, які він зробив, не будуть відмінені через будь-який збій.
Індексація – це метод структури даних, який дозволяє швидко отримувати записи з файлу бази даних. Індекс — це невелика таблиця, що складається лише з двох стовпців. Перший стовпець містить копію первинного або потенційного ключа таблиці. Його другий стовпець містить набір pointers для зберігання адреси блоку диска, де зберігається це конкретне значення ключа.
Індекс –
Приймає ключ пошуку як вхідні дані
Ефективно повертає колекцію відповідних записів.
Важливими недоліками/мінусами індексування є:
Щоб виконати індексацію системи управління базою даних, вам потрібен первинний ключ таблиці з унікальним значенням.
Ви не можете виконувати будь-які інші індекси в базі даних щодо індексованих даних.
Вам не дозволено розділяти таблицю, організовану за індексом.
Індексування SQL Зниження продуктивності в запитах INSERT, DELETE та UPDATE.
Підсумки
Індексація - це невелика таблиця, яка складається з двох стовпців.
Два основних типи методів індексування: 1) Первинне індексування 2) Вторинне індексування.
Первинний індекс — це впорядкований файл фіксованої довжини з двома полями.
Первинне індексування також поділяється на два типи: 1) Щільний індекс 2) Розріджений індекс.
У щільному індексі запис створюється для кожного ключа пошуку, який має значення в базі даних.
Метод розрідженого індексування допомагає вирішити проблеми щільного індексування.
Вторинний індекс у СУБД — це метод індексування, ключ пошуку якого визначає порядок, відмінний від послідовного порядку файлу.
Clustering index визначається як файл даних замовлення.
Багаторівневе індексування створюється, коли первинний індекс не поміщається в пам’яті.
Найбільша перевага індексування полягає в тому, що воно допомагає вам зменшити загальну кількість вводу-виводу operaнеобхідні для отримання цих даних.
Найбільшим недоліком у роботі системи керування базами даних індексування є необхідність первинного ключа в таблиці з унікальним значенням.
Резервне копіювання або бекап (англ. backup) — процес створення копії даних з носія (жорсткого диска, дискети тощо), призначений для відновлення цих даних у разі їх пошкодження або видалення.
Відновлення бази даних – це процес повернення бази даних в прийнятний стан, втрачений в результаті збою чи відмови.
Типова СКБД повинна надавати такі функції відновлення:
1. Механізм резервного копіювання, призначений для періодичного створення резервних копій бази даних.
2. Засоби ведення журналу транзакцій, в якому фіксується поточний стан транзакцій і зміни, які вони вносять у базу даних.
3. Функція створення контрольних точок, яка забезпечує перенесення виконуваних в базі даних змін у вторинну пам’ять з метою зробити їх постійними.
4. Диспетчер відновлення, що забезпечує відновлення узгодженого стану бази даних, порушеного в результаті відмови.
Резервна копія бази даних використовується у випадку пошкодження або руйнування файлів бази даних у вторинній пам’яті. Резервне копіювання може виконуватись для всієї бази даних в цілому або для зміненої її частини (тобто інкрементно). В останньому випадку в копію поміщаються відомості лише про зміни, що накопичились з моменту створення попередньої повної або інкрементної резервної копії системи.
Після того, як буде відновлена остання резервна копія, необхідно виконати накат всіх зафіксованих транзакцій, відомості про які містяться в журналі транзакцій. Безумовно, припускається, що сам журнал транзакцій не був пошкодженим. Тому рекомендується, щоб у всіх випадках, коли це можливо, файл журналу транзакцій створювався на дискових накопичувачах, відмінних від тих, де розміщені основні файли бази даних.
Якщо ж база даних не отримала фізичних пошкоджень, а лише втратила узгодженість розміщених у ній даних (наприклад, в результаті аварійної зупинки системи в процесі обробки транзакцій), то достатньо виконати відкат тих змін, які спричинили перехід бази даних в неузгоджений стан. Крім того, може виникнути необхідність виконати накат деяких транзакцій, щоб внесені в них зміни були дійсно зафіксовані у вторинній памяті. В даному випадку немає необхідності звертатись до резервної копії бази даних, оскільки повернути базу даних в узгоджений стан можна за допомогою інформації з журналу транзакцій.
Для повернення бази даних в узгоджений стан використовуються такі методи: метод відкладеного оновлення, метод негайного оновлення та альтернативний метод тіньового сторінкового обміну.
Розподілена база даних (англ. distributed database, DDB) — сукупність логічно взаємопов'язаних баз даних, розподілених у комп'ютерній мережі. Логічний зв'язок баз даних в розподіленій базі даних забезпечує система управління розподіленою базою даних, яка дозволяє управляти розподіленою базою даних таким чином, щоб створювати у користувачів ілюзію цілісної бази даних.
Система управління розподіленою базою даних складається з (можливо, порожнього) набору вузлів прийому запитів і набору вузлів збереження даних. Вузли прийому запитів реалізують прозорий інтерфейс доступу до даних, що зберігаються в вузлах збереження даних, та приховують фрагментацію даних між вузлами. Кожен з вузлів може бути представлений незалежним комп'ютером в комп'ютерній мережі з власною (можливо відмінною від інших вузлів) операційною системою.
Система управління розподіленою базою даних є однорідною (гомогенною), якщо на кожному з вузлів збереження даних застосовуються однакові СКБД, в іншому випадку система управління розподіленою базою даних є неоднорідною (гетерогенною). Внаслідок застосування стандартизованих механізмів доступу до баз даних відмінності між однорідними та неоднорідними системами нівелюються і не є критичними.
Реплікація (бази даних) — це механізм розподілу даних за вузлами, що дозволяє зберігати копії тих самих даних на різних вузлах мережі з метою прискорення пошуку і підвищення стійкості до відмов. Відношення чи фрагмент є реплікованим, якщо його копії зберігаються на двох або більше вузлах (копії ще називають репліками).
Можливі три варіанти реплікації бази даних:
повністю реплікована БД: зберігає копії одного й того ж фрагмента БД на всіх вузлах мережі. В даному випадку всі фрагменти БД репліковані. Така БД може виявитися не зручною у використанні через великі витрати.
частково реплікована БД: зберігає копії одного й того ж фрагмента БД на декількох вузлах мережі. Більшість СКБД допускають роботу саме з частково реплікованою БД.
нереплікована БД: зберігає кожний фрагмент БД на окремому вузлі. В цьому випадку дубльовані фрагменти БД відсутні.
Для реалізації реплікації використовуються три сервери: видавець, дистриб’ютор і передплатник.
Видавець — сервер, що надає розміщені на ньому дані для копіювання на інші сервери. Окрім створення копії даних, видавець відстежує внесені до його бази даних зміни і готує нову копію.
Дистриб’ютор (посередник) — сервер, що підтримує розподілену базу даних. Він виконує роль посередника, копіює всі публікації, підготовлені видавцем, і пересилає їх передплатникам. Дистриб’ютором може бути виділений сервер або сервер, сконфігурований як видавець чи передплатник. Конкретні функції, що їх виконує дистриб’ютор, залежать від методів реплікації.
Передплатник — сервер, що отримує копії даних, надані видавцем. Механізми зміни даних передплатником відрізняються від механізмів зміни даних видавцем.
Відновлення даних передплатників
Залежно від методу реплікації, передплатники можуть чи не можуть вносити зміни в репліковані дані. У найпростішому випадку змінювати дані може тільки видавець, у складніших моделях реплікації - передплатники і видавці. Змінені дані, отримані від усіх передплатників, синхронізуються і поєднуються з даними видавця, а потім розсилаються передплатникам.
Реплікація за запитом. Передплатник періодично звертається до дистриб’ютора із запитом про зміни, що відбулися з моменту останнього з’єднання. Реплікація за запитом виконується за розкладом.
Примусова реплікація
Дистриб’ютор сам встановлює з’єднання з передплатником і пересилає йому необхідні дані. Примусова реплікація виконується у відповідь на подію.
Моделі реплікації. Реплікація моментальних знімків
Реплікація моментальних знімків є найпростішою моделлю реплікації. Моментальний знімок це повна копія даних, обраних для реплікації; вона розсилається передплатникам.
Реплікація транзакцій. Під час реплікації транзакцій використовується журнал транзакцій бази даних. Обрані транзакції копіюються в базу даних дистриб’ютора зі збереженням інформації про послідовність їхнього виконання, потім розсилаються серверам- передплатникам і виконуються на них у тому ж порядку, в якому виконувалися на сервері-видавці. Цей механізм зменшує завантаження мережі, його рекомендується використовувати у великих базах даних з невеликою кількістю змін.
Топологія реплікацій
реплікація «один-до-багатьох» передбачає наявність одного видавця і кількох передплатників;
реплікація «багато-до-одного» має місце, коли дані від кількох видавців пересилаються одному передплатнику;
реплікація «багато-до-багатьох» означає, що дані від кількох видавців пересилаються кільком передплатникам.
Переваги
доступність (у разі перебою в роботі вузла, що містить відношення Н, його доступність на інших вузлах зберігається);
паралелізм (виконання запитів до відношення R може бути розпаралелено за всіма репліками відношення);
зниження вартості передавання даних (відношення R доступне локально в усіх вузлах, де є його репліки).
Недоліки
підвищується вартість зберігання, створення і відновлення даних; підвищуються вимоги до ресурсів;
ускладнюється підтримання цілісності даних, наприклад одночасне відновлення різних реплік одного й того ж відношення
Безпека баз даних – це комплекс заходів, які використовуються для захисту систем управління базами даних від кібератак та незаконного використання, а також для створення та збереження їхньої конфіденційності, цілісності та доступності. Програми безпеки БД передбачають захист від неправомірного використання, пошкодження та вторгнення самих даних у БД, всієї системи управління даними та кожного додатка тощо.
Захист безпеки БД включає:
дані у базі даних;
система управління базами даних;
всі пов’язані додатки;
фізичний та/або віртуальний сервер бази даних та базове обладнання;
обчислювальна та/або мережна інфраструктура, яка використовується для доступу до БД.
Безпека баз даних є складним і ємним проєктом, який включає всі аспекти технологій і практик інформаційної безпеки. Доступність та корисність бази даних додають уразливості перед кібератаками.
Витік даних – це ніщо інше, як нездатність забезпечити конфіденційність даних у БД. Ступінь збитків для підприємства залежить від наступних факторів:
Скомпрометована інтелектуальна власність. Інтелектуальна власність організації – це комерційна таємниця, різного роду винаходи, право власності. Все це має вирішальне значення для здатності володіти бізнесом та підтримувати конкурентну перевагу на ринку. Крадіжка інтелектуальної власності може призвести до важкого або ж неможливого відновлення.
Збитки репутації. Довіра клієнтів та партнерів дуже цінна. Вони повинні знати та відчувати рівень захисту їхніх даних. Інакше це загрожує відмовою від придбання товарів чи послуг, відмовою від співпраці.
Стійкість бізнесу. Деякі компанії не можуть продовжувати свою діяльність доти, доки проблема не буде повністю вирішена.
Штрафні санкції за невідповідність. Фінансові штрафи можуть бути руйнівними для бізнесу. У деяких випадках суми штрафів перевищують кілька мільйонів доларів.
Витрати на усунення порушень та повідомлення клієнтів. Крім витрат на комунікацію з клієнтом, постраждала компанія повинна організувати та сплатити судові та слідчі заходи, заходи з антикризового менеджменту, відновлення тощо.
Неправильні установки, вразливість та неправильне використання програмного забезпечення можуть призвести до серйозних порушень. До найбільш поширених причин та загроз безпеки БД відносять:
Внутрішні загрози – це загроза безпеці від джерел з привілейованим доступом до бази даних. До них відносяться: зловмисник, який навмисно намагається завдати шкоди; недбалий бізнес-користувач, що робить помилки і тим самим робить базу даних вразливою; стороння особа, яка отримує облікові дані за допомогою фішингової схеми тощо. Внутрішні загрози є найпоширенішими причинами порушень безпеки БД, оскільки велика кількість користувачів мають доступ привілейованого користувача.
Людська помилка – випадковість, слабкі паролі, спільне використання паролів та інші безвідповідальні дії користувачів.
Уразливість програмного забезпечення бази даних – одне з основних завдань, за яку хакери отримують гроші, є виявлення та усунення вразливості у всіх видах ПЗ, зокрема ПЗ для управління базами даних. Основні постачальники комерційного програмного забезпечення для баз даних та платформи управління базами даних з відкритим вихідним кодом регулярно випускають оновлення безпеки для усунення вразливостей. Несвоєчасне застосування оновлень може збільшити ризик загрози.
SQL/NoSQL атаки – загроза для конкретної бази даних, яка включає вставку довільних рядків атаки SQL та NoSQL у запити до бази даних. Використання безпечних методів кодування веб-застосунків та тестування на вразливість зменшує ризики стати жертвою атак.
Переповнення буфера – це відбувається при спробі запису в блок пам’яті фіксованої довжини більше даних, ніж дозволяється зберігати. Кіберзлочинці використовують надмірні дані як основу для запуску атак.
DDoS атаки (відмова в обслуговуванні) – кіберзлочинець завалює цільовий сервер, після чого він немає можливості виконувати легальні запити від реальних користувачів. В основному, сервер стає недоступним або дає збій.