3.1.1.6. Acid - властивості транзакцій

ACID (англ. Atomicity, Consistency, Isolation, Durability) - це набір властивостей, що гарантують надійну роботу транзакцій бази даних: атомарність, узгодженість, ізольованість, довговічність. Ці вимоги були сформульовані у 1970-х роках науковцем Джимом Греєм.

Вимоги ACID:

• A є „atomicity” (атомарність) – транзакція виконується за принципом „усе або нічого”, тобто має бути або виконана вся або не виконана зовсім.

• C є „consistency” (узгодженість). Усі БД вводять ті чи інші обмеження (constraints), обумовлені змістом даних: особливостями елементів даних та їхньою узгодженістю (як-от: бухгалтерська проводка виконується і по рахунку дебету, і по рахунку кредиту). Транзакції мають зберігати узгодженість даних.

• I є „isolation” (ізольованість) – процес іде так, немовби інших транзакцій у цей час не існує.

• D є „durability” (стійкість) – результат виконання транзакції не повинен бути втрачений за жодних умов.

3.2. Субд навігаційного типу. Ієрархічні. Сітьові.

3.2.1. Навігаційні бази даних

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

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

Приклад: щоб отримати напрямок до будинку, в навігаційному підході це буде нагадувати щось на зразок "проїдьте на шосе 25,8 км, поверніть на вулиці Смаковій наліво біля червоного будинку та зупиніться біля 3-го будинку по дорозі", в той час як при декларативному підході це буде нагадувати "Візит в зелений будинок (та) в наступних координатах ....".

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

Node6.Node4.Node5.Node1

Node6/Node4/Node5/Node1

Рис.3.7. – Приклад вузлів бази даних в графі на 6 вершин і 7 ребер. (Числа використовуються тільки для ілюстрації. На практиці частіше використовуються більш осмислені імена. Інші потенційні атрибути не показані.)

Якщо не існує ніякого зв'язку між деякими вузлами, то зазвичай спрацьовує стандартна помилка з повідомленням, таких як "неіснуючий шлях". Шлях "Node6.Node2.Node1" буде неіснуючим в наведеному прикладі, тому що немає прямого зв'язку між вузлом 6 і Node 2.

Використання терміну «навігаційних» нібито походить від твердження Чарльз Бахмана, в якому він описує в "програміста як навігатора" при доступі до своїх улюблених даних. [1].

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

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

Сучасні приклади навігаційного структурування:

• Document Object Model (DOM), що використовується, наприклад, у веб-браузерах і тісно пов'язана з JavaScript. DOM "двигун" являє собою легкий навігаційний тип баз даних.

• World Wide Web в цілому та Wikipedia потенційно можуть вважатися формами навігаційних баз даних, хоча вони і зроблені на зрозумілих для людини текстах, а не на інших даних (у великих масштабах, Web являє собою мережеву модель, а на меншому масштабі, на місцевому масштабі, такому, як домен та розмітка URL, вона використовує ієрархії).

• останнім часом широкого розвитку набули ряд нових навігаційних баз даних - графові бази даних. Ця категорія баз даних часто включається і в якості одного з чотирьох типів баз даних NoSQL.

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

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

Приклади навігаційних СУБД: AllegroGraph, Bigdata, CloudGraph, Cytoscape, DEX, Filament, GiraffeDB, GraphBase, Horton, HyperGraphDB, InfiniteGraph, Neo4j, InfoGrid, OpenLink Virtuoso, OrientDB, OQGRAPH , R2DF, sones GraphDB, VertexDB