Міністерство освіти і науки України

Львівський національний університет імені Івана Франка

Факультет електроніки

та комп’ютерних технологій

КУРСОВА РОБОТА

Синхронізація нереляційних баз даних

Виконав студент 2 курсу

групи ФеС-23

___________ Дуда С.-М. Я.

Науковий керівник

________ доц. Франів В. А.

Львів 2022
 ЗМІСТ

АНОТАЦІЯ……………………………………………………………………..3
ВСТУП………………………………………………………………………….4
РОЗДІЛ 1. РЕЛЯЦІЙНА ТА НЕРЕЛЯЦІЙНА СЕРЕДА БАЗИ ДАНИХ…..5
1.1 Бази даних…………………………………………………………...5
1.1.1 Дані…………………………………………………………5
1.1.2 Визначення баз даних……………………………………..5
1.2 Реляційна база даних………………………………………………..5
1.2.1 Принцип нормалізації……………………………………..6
1.2.2 Типи логічних зв’язків…………………………………….6
1.2.3 Ключі……………………………………………………….7
1.3 Нереляційна база даних…………………………………………….8
1.3.1 Поява бази даних NoSQL…………………………………9
1.3.2 Типи нереляційних баз даних………………………….....9
1.3.3 Плюси і мінуси NoSQL………………………….……….10
1.3.4 Відсутність SQL………………………………………….10
1.3.5 Простота NoSQL…………………………………………11
1.3.6 Соціальні дані………………………………………….…12
1.3.7 Аналіз даних……………………………………………...13
РОЗДІЛ 2. COUCHDB, POUCHDB, JAVASCRIPT, HTTP ПРОТОКОЛ
ТА АРХІТЕКТУРА КЛІЄНТ-СЕРВЕРА……………………………………14
2.1 CouchDB……………………………………………………………14
2.1.1 Особливості………………………………………………..14
2.2 PouchDb…………………………………………………………….16
2.3 JavaScript……………………………………………………………16
2.3.1 Можливості JavaScript…………………………………….17
2.3.2 API………………………………………………………….17
2.4 HTTP протокол………………………………………….…..18
2.4.1 Структура протоколу…………………...…………………18
2.5 Архітектура клієнт-сервера……………………………………….19
РОЗДІЛ 3. ПРОГРАМНА РЕАЛІЗАЦІЯ ЗАВДАНЬ……………………….20
ВИСНОВКИ…………………………………………………………………..22
ЛІТЕРАТУРА…………………………………………………………………23
ДОДАТОК………………………………………………………………….…24

2
 АНОТАЦІЯ

Курсова робота присвячена розробці синхронізації нереляційних баз

даних. Це дає можливість зберігати дані без чіткого зв'язку між собою або
чіткою структурою. Замість структурованих таблиць бази даних містять
безліч різних документів (зображення, відео, повідомлення в соціальних
мережах і т.д.). Для цієї роботи були використані середовища як CouchDb,
PouchDB, Intellij IDEA, а також мова програмування JavaScript та
веббраузера Google Chrome і Microsoft Edge.

SUMMARY

The course work is devoted to the development of synchronization of

non-relational databases. This makes it possible to store data without a clear
connection between each other or a clear structure. Instead of structured tables,
databases contain many different documents (images, videos, social media
posts, etc.). For this work, we used such environments as CouchDb, PouchDB,
Intellij IDEA, as well as the JavaScript programming language and web
browsers Google Chrome and Microsoft Edge.

3
 ВСТУП

Діставати для себе любу інформацію в «один клік» стало для людей
чимось буденним. Але мало хто догадується що відбувається «по той бік
екрану» і які виконуються складні махінації з величезною кількістю даних.
У наш час без збирання і сортування інформації ніяк не обійтися.
Тому для виконання такого важливого завдання люди створили бази
даних, щоб облегшити собі роботу. Але баз даних на сьогоднішній день є
дуже багато, наприклад: бази даних часових рядів, стовбчикові бази даних,
ієрархічні, прості структурні і т.д. Усі вони мають різний функціонал та
свої плюси і мінуси.
У цій курсовій роботі ми розглянемо лише два типи баз даних:
реляційні, які вважаються одними з домінуючими на ринку, та
нереляційні, одне з недооцінених, на мою думку, баз даних. Ми детально
ознайомимося з їхніми можливостями, для чого їх використовують та з
якими недоліками зустрічається людина, яка взялася працювати з ними.
Але найбільший акцент ми поставимо на нереляційні бази даних і
дізнаємося чи заслужено ним користуються, чи можливо ніхто насправді
не замічає справжніх його можливостей? Чи приречене воно бути не
популярною базою даних, чи можливо NoSQL є революцією у наший час?
Ця курсова робота розрахована на перевідкриття цієї бази даних для
людей, які не можуть вирішити чи працювати у цьому середовищі та
роботи у ній.

4
РОЗДІЛ 1. РЕЛЯЦІЙНА ТА НЕРЕЛЯЦІЙНА СЕРЕДА БАЗИ ДАНИХ

1.1 Бази даних

Кожен проєкт потребує правильного вибору технології для його
реалізації. І одне з найскладніших рішень – правильний вибір типу бази
даних.

1.1.1 Дані
Це інформація, яку має зберігати наша система й з якою буде
працювати. Дані можуть бути фактами, пов’язаними з будь-яким
предметом. Як от, ваше ім’я, вік, зріст, вага. Зображення, файл теж можна
вважати даними.

1.1.2 Визначення баз даних

База даних ─ це інтегрована сукупність структурованих і
взаємозалежних даних, організована за певними правилами, які
передбачають загальні принципи опису, зберігання і обробки даних.
Це велике електронне сховище, де зібрані файли і занесені в
комп’ютер. Так постачальник використовує базу даних для управління
рахунками, проблемами, пов’язаними з клієнтами, для обробки даних про
несправності.

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

Реляційна база даних — це тип бази даних, яка зберігає інформацію
в електронній таблиці та шукає дані в одній таблиці на основі ключових
полів, визначених в іншій таблиці.
Модель бази даних визначає логічний дизайн і структуру бази даних.
Крім того, він визначає, як дані зберігаються та доступні за допомогою
СУБД. Тут реляційні бази даних базуються на реляційній моделі.
Реляційні бази даних зберігають дані в таблицях.
Наприклад, розглянемо базу даних продажів. Таблиця клієнтів
містить стовпці або атрибути, такі як customer_id, name, address,
contact_no. Кожен рядок у таблиці представляє клієнта, а первинним

5
ключем таблиці клієнтів є customer_id. Це допомагає ідентифікувати
кожен запис окремо. Припустимо також, що в базі даних продажів є ще
одна таблиця під назвою orders. Містить order_id, order_name, date,
customer_id. customer_id у таблиці клієнтів є зовнішнім ключем у таблиці
замовлень. Тому ці дві таблиці пов’язані одна з одною. У реляційних базах
даних таблиці пов’язані одна з одною.
Ми можемо нормалізувати дані в таблицях реляційної бази даних,
щоб мінімізувати надмірність даних. Крім того, мова структурованих
запитів (SQL) допомагає запитувати дані в реляційних базах даних.

1.2.1 Принцип нормалізації

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

1.2.2 Типи логічних зв'язків

Встановлюється зв'язок між двома загальними полями
(стовпцями) у двох таблицях. Існують зв’язки «один до одного»,
«один до багатьох» і «багато до багатьох».
Зв’язки, які можуть існувати між записами у двох таблицях:
1. Один до одного – кожен запис в одній таблиці відповідає
одному запису в іншій таблиці.
2. Один до багатьох – кожен запис в одній таблиці відповідає
декільком записам в іншій таблиці..
3. Багато-до-багатьох – багато записів в одній таблиці
відповідають кільком записам в іншій таблиці.
Зв’язок «один-до-багатьох» створюється, коли лише одне з
полів є первинним ключем або полем унікального індексу.
Відношення «один-до-одного» створюється, коли обидва поля
є ключами або мають унікальні індекси.
6
 Відношення «багато-до-багатьох» насправді є двома
відношеннями «один-до-багатьох» із третьою таблицею, первинний
ключ якої складається з полів зовнішнього ключа двох інших
таблиць.

1.2.3 Ключі
Ключ — це стовпець (може бути кілька стовпців), який
додається до таблиці, щоб можна було встановити зв’язок із
записами в іншій таблиці.
Існує два типи ключів: первинний і вторинний (чужий).
Первинний ключ — це одне або кілька полів (стовпців),
комбінація значень яких однозначно ідентифікує кожен запис у
таблиці. Первинний ключ не може бути нульовим і завжди повинен
мати унікальний індекс. Первинні ключі використовуються для
зв’язку між таблицями та зовнішніми ключами в інших таблицях.
Вторинний (чужий) ключ — це одне або кілька полів
(стовпців) у таблиці, які містять посилання на поле первинного
ключа іншої таблиці. Вторинний ключ визначає спосіб об’єднання
таблиць.
З двох логічно пов’язаних таблиць одна називається таблицею
первинного ключа або головною таблицею, а інша — таблицею
вторинного (чужого) ключа або дочірньою таблицею. СУБД
дозволяє зіставляти пов’язані записи з обох таблиць і відображати їх
разом у формі, звіті чи запиті.
Існує три типи первинних ключів: ключові поля лічильника,
прості ключі та складені ключі.
1. Поле лічильника (тип даних «Лічильник»). Кожен запис у
цьому полі таблиці автоматично заповнюється унікальним
числовим значенням.
2. Простий ключ. Якщо поле містить унікальні значення, такі
як коди або інвентарні номери, ми можемо визначити це
поле як первинний ключ. Будь-яке поле, що містить дані,
можна визначити як ключ, якщо поле не містить
повторюваних або нульових значень.
3. Складений ключ. Якщо ми не можемо гарантувати
унікальність кожного значення поля, ми можемо створити
7
 ключ, що складається з кількох полів. Найчастіше така
ситуація виникає з таблицями, які використовуються для
з’єднання двох таблиць у зв’язку «багато-до-багатьох».
Поле первинного ключа має містити лише унікальні значення
для кожного рядка в таблиці. Тобто зіставлення не дозволено, а
зіставлення значень дозволено для рядків таблиці в полях
вторинного або зовнішнього ключа. Якщо вибрати правильний тип
первинного ключа складно, потрібно вибрати поле лічильника як
ключ.
Програми, призначені для структурування інформації,
упорядкування її в таблицях і обробки даних, називаються
системами керування базами даних (СУБД). Іншими словами, СУБД
призначена як для створення та підтримки баз даних, так і для
доступу до даних. Існує більше 50 видів СУБД для персональних
комп'ютерів. Деякі з найпоширеніших включають MS SQL Server,
Oracle, Informix, Sybase, DB2 і MS Access.

1.3 Нереляційна база даних

Багато джерел надають дуже розпливчасте визначення бази даних
NoSQL, що призводить до неточного або неповного уявлення про те, що
таке база даних цього типу. Крім того, природа терміну база даних NoSQL
викликає плутанину. Тому що визначення «неживий об’єкт» могло б
включати і каміння, і лампочки, і автомобілі. Так само концепція NoSQL є
абсолютно іншою.
Логічно, що в цьому контексті концепція NoSQL включає не-NoSQL
бази даних, дореляційні бази даних, які були розроблені без попереднього
досвіду роботи з системами SQL і не призначені для створення сучасних
рішень NoSQL на той час. Їхня мета була більш експериментальною.
Нереляційні бази даних – зберігають дані без чіткого зв’язку або
структури один з одним. Замість структурованих таблиць бази даних
містять багато різних документів, таких як зображення, відео та навіть
публікації в соціальних мережах. На відміну від реляційних баз даних,
бази даних NoSQL не підтримують запити SQL.

8
1.3.1 Поява бази даних NoSQL
Основним фактором, який змусив світову ІТ-спільноту думати
про нові стратегії зберігання та доступу до інформації, є
систематичне зростання обсягу даних в Інтернеті. У цьому контексті
з’явилися великі дані. Великі дані – це стратегія ефективної обробки
величезних і постійно зростаючих масивів даних.
Крім того, концепція великих даних чітко показала потребу в
моделі бази даних, яка фокусується на швидкості доступу та
масштабованості. Потрібне було рішення, яке було б простіше, ніж
існуючі реляційні бази даних, але не менш ефективне для вирішення
конкретних завдань. В першу чергу це завдання побудови хмарного
сховища, і кінцевих користувачів в першу чергу хвилює швидкість
доступу та обсяг інформації, який там може зберігатися.
Реляційні бази даних неефективні для зберігання великих
обсягів даних, таких як BigData. Рішенням цієї проблеми є
нереляційні бази даних. Ці бази даних можуть зберігати великі
обсяги даних. Ми також можемо згрупувати свої дані на кількох
машинах, щоб зменшити витрати на обслуговування.
Більшість нереляційних баз даних можна знайти на таких веб-
сайтах, як Google, Yahoo, Amazon і Facebook. Ці веб-сайти мають
мільйони користувачів, які щодня впроваджують тисячі нових
програм, і існуючі рішення RDBMS не можуть встигати за різким
скороченням трафіку. РСУБД не може вирішити цю проблему, тому
люди перейшли на новий тип СУБД, який може обробляти дані веб-
масштабу нереляційним способом.

1.3.2 Типи нереляційних баз даних

Існує чотири основних типи баз даних NoSQL. Завдяки різним
моделям даних і підходам до розповсюдження та реплікації вони
різною мірою можуть підходити для конкретних типів конкретних
завдань.
1. База даних «ключ-значення» — найпростіший тип бази даних.
Фактично це асоціативний масив, де кожне значення відповідає
власному унікальному ключу. Найпопулярнішими прикладами
цього типу СУБД є Amazon DynamoDB, Berkeley DB,
MemcacheDB, Redis і Riak.

9
2. Документно-орієнтована база даних — це система для зберігання
ієрархічних структур даних (документів) із структурою дерева
або лісу. Приклади такого типу СУБД: CouchDB, Couchbase,
MarkLogic, MongoDB, eXist.
3. Графова модель бази даних є узагальненням моделі мережевих
даних і характеризується міцними зв’язками між вузлами.
Найвідомішими графовими СУБД є ArangoDB, FlockDB, Giraph,
HyperGraphDB, Neo4j і OrientDB.
4. База даних, як-от Bigtable або сховище сімейства стовпців,
містить дані, упорядковані у формі розрідженої матриці, рядки та
стовпці якої використовуються як ключі. Прикладами такого
типу СУБД є HBase, Cassandra, Hypertable, SimpleDB.

1.3.3 Плюси і мінуси NoSQL

Щоб зрозуміти головні причини популярності рішень NoSQL і
продемонструвати їх обґрунтований масштаб, варто розглянути всі
запропоновані варіанти з кількох сторін: усі системи NoSQL і
реляційні бази даних.

1.3.4 Відсутність SQL

1. Першою і найбільш очевидною особливістю є відсутність
SQL (Structured Query Language), універсальної мови запитів, яка
використовується всіма реляційними системами. Кожна система
NoSQL має власний API або вбудовану мову запитів взаємодії. У
цьому рішенні є і позитивна сторона.
2. Легкість роботи. Багато баз даних NoSQL мають дуже
обмежені можливості порівняно з реляційними базами даних, яким
не потрібно виконувати завдання. При цьому від оператора бази
даних не вимагається глибоких знань досить потужного і гнучкого
механізму маніпулювання SQL-запитами. Це значно знижує поріг
входу для запуску NoSQL-сховища.
3. Простіший синтаксис запиту означає менше помилок. Для
спрощення роботи з базами даних деякі розробники використовують
ORM (Object Relational Mapping). Це технологія, яка може
автоматично переводити маніпуляції з об’єктами в запити до бази
даних. Найчастіше такі рішення працюють неефективно і

10
породжують багато непотрібних або відверто помилкових запитів.
Незважаючи на те, що мова SQL є універсальною, вона має дуже
великі можливості, і для її серйозного використання потрібні певні
знання. У той же час рідна мова запитів сучасних репозиторіїв
NoSQL краще підходить для виконання простих операцій з базами
даних.
Це рішення також має свої недоліки, але в довгостроковій
перспективі воно цілком може переважити всі його переваги.
4. Додатки сильно прив'язані до конкретної СУБД. Мова SQL є
спільною для всіх реляційних баз даних, і користувачам не потрібно
повністю переписувати весь код, якщо СУБД зміниться. Навіть якщо
дві системи NoSQL концептуально практично не відрізняються,
існує кілька спільних стандартів для API і специфікацій запитів.
5. Вбудована мова запитів має обмежені можливості. SQL має
дуже багату історію та багато стандартів. Це дуже потужний і
складний інструмент для обробки даних і звітності. Практично всі
API зберігання даних NoSQL і мови запитів побудовані на основі
деяких функцій SQL. Результатом є набагато менша
функціональність.
6. Низька цінність знань і вузький профіль — набагато легше
знайти фахівця з хорошими знаннями SQL, але мало хто всерйоз
цікавиться подробицями операцій API для деяких рішень NoSQL —
це означає, що оператори баз даних повинні вивчити багато
специфічних операцій.

1.3.5 Простота NoSQL

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

1.3.6 Соціальні дані

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

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

1.3.7 Аналіз даних

Хмарне сховище та розроблені для нього рішення NoSQL
часто використовують принцип мультиоренда. Вона полягає в тому,
що багато користувачів використовують одну і ту ж систему
одночасно. Політики обмеження запитів застосовуються, щоб
запобігти перевантаженню рішень, розроблених для високої
масштабованості. Наприклад, SimpleDB не дозволяє запитам
виконуватися довше 5 секунд, а Google AppEngine Datastore не
дозволяє одному запиту до бази даних отримувати більше 1000
записів.
Ці обмеження підходять для простої роботи з програмою, але
вони сильно впливають на її здатність аналізувати дані. Компанії
часто отримують вигоду від великої кількості даних користувачів.
На основі аналізу вони можуть вибрати найпопулярніші продукти та
скласти список рекомендацій для певних груп користувачів «на
льоту» на основі особистих даних або історії. У багатьох рішеннях
NoSQL таку функціональність важко або просто неможливо
реалізувати.

13
РОЗДІЛ 2. COUCHDB, POUCHDB, JAVASCRIPT, HTTP ПРОТОКОЛ
ТА АРХІТЕКТУРА КЛІЄНТ-СЕРВЕРА

2.1 CouchDB
Apache CouchDB — це розподілена документно-орієнтована система
керування базами даних системного класу NoSQL, яка не потребує опису
схеми даних. До CouchDB можна надсилати запити та індексувати дані
відповідно до парадигми MapReduce, яка використовує JavaScript для
формування логіки вибірки даних.
CouchDB можна розглядати як сервер веб-додатків. Щоб втілити цю
ідею в життя, у CouchDB вбудовано продуктивний веб-сервер, а не
оброблений код (як і дані) зберігається в тій же базі даних.
Запит CouchDB та індексування даних можна виконувати відповідно
до парадигми MapReduce, яка використовує JavaScript для формування
логіки пошуку даних. Доступ до бази даних здійснюється за протоколом
HTTP з RESTful JSON API. Документ з унікальним ідентифікатором і
версією, що містить довільний набір іменованих полів у форматі
ключ/значення, діє як одиниця зберігання даних. Організація псевдо
структурованих наборів даних із довільних документів використовує
концепцію формування уявлень, визначення якої використовує мову
JavaScript. У JavaScript ми також можемо визначити функції, які
перевіряють правильність даних під час додавання нового документа в
певному поданні.
CouchDB зберігає дані у формі впорядкованого списку та дозволяє
часткову реплікацію даних у кількох базах даних у режимі «головний-
головний», який одночасно виявляє та вирішує конфліктні ситуації. Кожен
сервер підтримує власний локальний набір даних, синхронізованих з
іншими серверами, і їх можна перевести в автономний режим для
регулярного повторення змін. Зокрема, така можливість робить CouchDB
привабливим рішенням для організації синхронізації програмних
налаштувань між різними комп’ютерами.

2.1.1 Особливості
На відміну від реляційних СУБД, як і інших документно
орієнтованих СУБД (Mnesia, Lotus Notes, MongoDB), CouchDB

14
розроблена для роботи з напівструктурованою інформацією та має
наступні особливості:
1. Дані зберігаються у формі JSON-подібних документів, а не рядків
чи стовпців, де моделює дерево, а не таблиця.
2. Цілісність бази даних гарантується лише на рівні окремих
записів.
3. Операції об’єднання (JOIN) між таблицями не визначені, оскільки
в’язки між таблицями або записами принципово не
підтримуються.
4. Функції перегляду використовуються для створення індексів і
виконання запитів.
5. Функції-валідатори, функції-типи та функції-фільтри
зберігаються в текстовій формі в самій базі даних.
6. Ці функції зазвичай написані на JavaScript або Erlang, викликають
окремий сервер запитів для їх виконання та взаємодіють за
допомогою сокетів і текстових протоколів JSON.
7. Кожна база даних у системі CouchDB відповідає одному
B-дереву.
8. Кожне B-дерево зберігається на диску як окремий файл.
9. Ми можемо запускати кілька потоків одночасно для читання бази
даних і лише один потік для запису.
10.Цілісність бази даних гарантується лише тоді, коли дані
записуються на диск.
11.Початкові дані та їхні індекси, що зберігаються в базі даних,
постійно оновлюються, але все В-дерево оновлюється кожного
разу, коли оновлюється початкова функція або відображення.
12.Для обробки даних використовується спрощена модель технології
MapReduce за допомогою функціонального стилю, який допускає
паралельні обчислення, в тому числі на багатоядерних
процесорах.
13.Розподіл обчислень між кількома вузлами не підтримується.
Замість цього використовується механізм реплікації.
14.Обробка даних за допомогою ланцюжка послідовних функцій
MapReduce не підтримується.
15.Підтримується вертикальна масштабованість. Це означає, що
підтримуються портативні пристрої, а також величезні кластери.
16.Зовнішній інтерфейс (API) до цієї СУБД побудований на основі
архітектури REST. Іншими словами, сама база даних, окремі
записи, перегляди та запити є сутністю ресурсів, які мають

15
 унікальні адреси (URL) і підтримують GET, PUT, POST,
DELETE. Тому було створено багато клієнтських бібліотек для
взаємодії з базами даних, включаючи такі мови, як JavaScript,
PHP, Ruby, Python і Erlang.
17.Взаємодія між окремими компонентами СУБД, тобто взаємодія з
початковим сервером, знову ж таки виконується за допомогою
текстового протоколу, дані надсилаються у форматі JSON. Це
дозволяє створювати ці компоненти за допомогою різних мов
програмування, таких як Java, Python і JavaScript.

2.2 PouchDb
PouchDB – документно-орієнтована система управління базами
даних та розширена версія СУБД Apache CouchDB, написана на JavaScript.
PouchDB може працювати у вашому браузері.
Модель зберігання копіює CouchDB та надає засоби вирішення
конфліктів. PouchDB сумісний з CouchDB на рівні API для зберігання та
отримання даних. Код розповсюджується під ліцензією Apache 2.0.
PouchDB дозволяє створювати повнофункціональні веб-застосунки в
автономному режимі і може реплікувати дані з фіксованої бази даних на
основі CouchDB. Іншими словами, коли веб-програма не підключена до
мережі, вона може накопичувати зміни на основі PouchDB в локальному
сховищі, а коли вона підключена до мережі, вона може синхронізувати
зміни із зовнішнім сервером, що підтримує CouchDB API, або
забезпечувати синхронізацію даних та перейти між клієнтами.
PouchDB працює у всіх сучасних браузерах, а також у серверних
рішеннях на базі Node.js та окремих клієнтських програмах на базі
Cordova/PhoneGap, NW.js та Electron. PouchDB не прив'язаний до жодного
веб-фреймворку, але окремо надає прив'язки для різних фреймворків,
включаючи Angular, React, Ember і Backbone.

2.3 JavaScript
JavaScript – це мова програмування, яка дозволяє веб-документам
реалізовувати безліч складних рішень. Він допомагає зробити сторінки
сайту більш інтерактивними та обробляє дії користувачів сайту. Це
об'єктно-орієнтована клієнтська мова, що підтримується програмами, що
керують дизайном сайту. JavaScript став ще популярнішим серед

16
розробників, коли з'явилася технологія AJAX, що призвело до нового
етапу розробки сайтів.
Нижче наведено деякі конкретні приклади застосування технологій:
1. Відображення контенту, що регулярно оновлюється.
2. Створення якісної анімації та графічних об'єктів у форматах
2D/3D.
3. Можливість прокручувати відео в медіа плеєрі.
Поряд із HTML та CSS, JavaScript є третім важливим будівельним
блоком, з якого побудовано більшість стандартних веб-інтерфейсів.

2.3.1 Можливості JavaScript

Ядро JavaScript містить безліч функцій, що забезпечують такі
можливості:
1. Зберігає дані у змінних.
2. Шматок коду активується за певним сценарієм, який виконується
на сторінці сайту.
3. Створює контент, який автоматично оновлюється.
4. Керування мультимедійними функціями.
2.3.2 API
Тепер ми поговоримо про інтерфейси прикладного
програмування (API), які значно розширюють набір інструментів
розробника.
API це готові модулі коду, які допомагають програмістам
виконувати складні завдання. Така «підготовка» зазвичай ділиться
між браузерами та сторонніми API.
API-інтерфейси браузера включають:
1. API DOM (об'єктна модель документа).
2. Модуль геолокації.
3. Полотно та WebGL API.
4. Аудіо та відео API.
Коли ви завантажуєте сторінку у браузері, спочатку
обробляються HTML та CSS, а потім скрипти.
Однак у мові відсутні деякі корисні інструменти. Тут немає:

17
 1. Стандартна бібліотека.
2. Стандартний інтерфейс для роботи з серверами та базами даних.
3. Система керування пакетами.

2.4 HTTP протокол

HTTP – це протокол передачі даних, який використовується у
комп'ютерних мережах. Назва скорочено від HyperText Transfer Protocol,
протоколу передачі гіпертекстових документів.
Основне призначення HTTP — передача веб-сторінок (текстових
файлів з HTML-розміткою), але можуть бути й інші файли, що стосуються
веб-сторінок (зображення та додатки), та інші файли, що не належать до
них.
HTTP передбачає, що клієнтські програми (веб-браузери) можуть
відображати гіпертекстові веб-сторінки та інші типи файлів у зручному
для користувача форматі. Для правильного відображення HTTP дозволяє
клієнтам дізнатися мову та кодування символів веб-сторінки або
запросити версію сторінки потрібною мовою/кодуванням за допомогою
стандартної нотації MIME.

2.4.1 Структура протоколу

HTTP – це протокол прикладного рівня, аналогічний FTP та
SMTP. Обмін повідомленнями відбувається за звичайним шаблоном
«запит-відповідь». HTTP використовує глобальні URI для
визначення ресурсів. На відміну від інших протоколів HTTP не
зберігає свій стан. Це означає, що між парами запит-відповідь не
підтримується проміжний стан. Компоненти, які використовують
HTTP, можуть незалежно зберігати інформацію про стан, пов'язаний
з останніми запитами та відповідями. Браузер, який надсилає запит,
може відстежувати затримку відповіді. Сервер може зберігати
останні IP-адреси клієнтів та заголовки запитів. Проте протокол не
вимагає, щоб клієнт і сервер знали про попередні запити та
відповіді, протокол не підтримує внутрішній стан і не висуває таких
вимог до клієнта та сервера.
Кожен запит/відповідь складається з трьох частин:
1. Стартова лінія;

18
 2. Заголовок;
3. Тіло повідомлення, яке містить дані запиту, запитаний ресурс або
опис проблеми, якщо запит не виконано.
Мінімально необхідний запит – це стартовий рядок.
Починаючи з HTTP/1.1, заголовок Host: тепер потрібний (щоб
розрізняти кілька доменів з однією і тією ж IP-адресою).

2.5 Архітектура клієнт-сервера

Архітектура клієнт/сервер — це модель архітектури програмного
забезпечення та ключова концепція створення розподілених мережних
додатків, що включає взаємодію та обмін даними між додатками. Він
містить такі основні компоненти:
1. Набір серверів, які надають інформацію або інші послуги додатків,
що викликають.
2. Набір клієнтів, які використовують служби сервера.
3. Мережа, що забезпечує зв'язок між клієнтами та серверами.
Сервери незалежні один від одного. Також клієнти працюють
незалежно один від одного та паралельно. Жорсткої прив'язки клієнта до
сервера немає. Один сервер рідко опрацьовує запити від різних клієнтів
одночасно. З іншого боку, клієнти можуть підключатися до будь-якого
сервера. Клієнти повинні знати про доступні сервери, але можуть не знати
про існування інших клієнтів.

19
 РОЗДІЛ 3. ПРОГРАМНА РЕАЛІЗАЦІЯ ЗАВДАНЬ

Процес реалізації завдання починається з створення бази даних під назвою

my_database_couch в CouchDB(рис. 1):

Рис 1. Створена база даних my_database_couch в CouchDB

Наступним кроком у нас є написання коду на мові програмування

JavaScript у середовищі Intellij IDEA для створення кнопки та «начинки» у
файлі під назвою index.html (рис. 2 та 3):

Рис 2. Вміст файла index.html

20
 Рис 3. Вміст файла index.html

Після написання коду ми запускаємо наш файл у браузері, де нас зустріне

наша кнопка «replicate» (рис. 4):

Рис. 4 Кнопка «replicate»

Натискаємо праву кнопку мишки та вибираємо «Перевірити», після чого у

нас появиться допоміжне вікно, де у вкладках Application ->
document_store ми можемо знайти наші три документа: «av38k»,
«dave@gmail.com», «rom» (рис. 5).

Рис 5. Відображення створених документів у браузері

21
 ВИСНОВКИ

У цій курсовій роботі ми дізналися, що база даних NoSQL має багато

недоліків та не зручностей.
Однак не варто повністю вірити надмірно критичним відгукам про
NoSQL. Поява нереляційних баз даних породило безліч цікавих та
комерційно успішних ідей для різних потреб підприємства. Існує безліч
проектів, яким було б вигідно використовувати NoSQL-системи, але їх
творцям слід тверезо оцінювати довгострокові перспективи
запровадження нереляційних баз даних. Так, всі ці рішення дуже молоді, і
багато компаній ухвалили невірні рішення на модній хвилі і з тріском
провалилися. Але чийсь невдалий досвід перестав бути фактичним
дефектом продукту.
Здебільшого, у міру еволюції зберігання та обробки даних, ми
будемо бачити у світі все більше і більше комбінованих рішень, які
використовують системи NoSQL для «прикриття» слабких місць SQL.
Також ми вивчили теоретичні відомості про дві бази даних:
реляційні та нереляційні. Дізналися про їхні можливості та
функціональність.
Розглянули роботу бази даних при відсутності мережі та отримали
практичний досвід у середовищах CouchDB, PouchDB ы Intellij IDEA та
попрацювали з такою мовою програмування як JavaScript.
А також ми провели дослідження із синхронізацією нереляційної
бази даних та зробили висновки щодо полученого матеріалу.

22
 ЛІТЕРАТУРА

1. Організація баз даних: практичний курс: Навч. посіб. для студ. /

А. Ю. Берко, О. М. Верес; Нац. ун-т «Львів. політехніка». — Л.,
2003. — 149 c.
2. Резніченко, В.А. (2021). 60 років базам даних. Проблеми
програмування (№ 3). doi:10.15407/pp2021.03.040.
Архів оригіналу за 3 лютого 2022. Процитовано 3 лютого 2022.
3. «An Introduction to Database Systems» C. J. Date. ISBN 0-321-19784-
4 (англ.)
4. NoSQL Databases Explained [Архівовано 2 грудня 2015 у Wayback
Machine.]
5. Oracle NoSQL Database [Архівовано 8 лютого 2016 у Wayback
Machine.]
6. Strauch, Christoph. NoSQL whitepaper. Stuttgart: Hochschule der
Medien. Архів оригіналу за 17 травня 2018. Процитовано 24 травня
2018.
7. Edlich, Stefan. NoSQL database List. Архів оригіналу за 26 грудня
2018. Процитовано 4 лютого 2016.
8. Neubauer, Peter (2010). Graph Databases, NOSQL and Neo4j.
Архів оригіналу за 26 грудня 2018. Процитовано 24 травня 2018.
9. Bushik, Sergey (2012). A vendor-independent comparison of NoSQL
databases: Cassandra, HBase, MongoDB, Riak. NetworkWorld.
Архів оригіналу за 26 грудня 2018. Процитовано 24 травня 2018.
10.Zicari, Roberto V. (2014). NoSQL Data Stores – Articles, Papers,
Presentations. odbms.org. Архів оригіналу за 26 грудня 2018.
Процитовано 24 травня 2018.
11.Anderson, J. Chris; Slater, Noah; Lehnardt, Jan (15 листопада
2009). CouchDB: The Definitive Guide (вид. 1st). O'Reilly Media.
с. 300. ISBN 0596158165. Архів оригіналу за 14 липня 2011.
Процитовано 4 квітня 2012.
12.Lennon, Joe (15 грудня 2009). Beginning CouchDB (вид. 1st). Apress.
с. 300. ISBN 1430272376. Архів оригіналу за 5 грудня 2010.
Процитовано 4 квітня 2012.
13.JavaScript домашня сторінка, JavaScript довідник [Архівовано 20
липня 2012 у Wayback Machine.] на mozilla.org. (англ.)
14.JScript [Архівовано 31 серпня 2010 у Wayback Machine.] та JScript
.NET [Архівовано 13 серпня 2010 у Wayback Machine.] довідники на
сайті MSDN Library [Архівовано 11 червня 2010 у Wayback
Machine.] (англ.)

23
 ДОДАТОК
Код файлу index.html:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Some title</title>
<script src=
"//cdn.jsdelivr.net/npm/pouchdb@7.3.0/dist/pouchdb.min.js"></script>
<script>

var db = new PouchDB('my_database');

db.put({
_id: 'dave@gmail.com',
name: 'David',
age: 69
});
db.put({
_id: 'av38k',
name: 'huh'
});
db.put({
_id: 'rom',
name: 'cat',
age: 2,
the_look_of_a_cat: [
'black',
'big',
'wide',
'cute'
]
});

function syncDb() {

db.replicate.to('http://admin:admin@127.0.0.1:5984/my_database_couch',
[

24
 {mode: "no-cors"}
]);
}

</script>
</head>
<body>
<button onclick="syncDb()">replicate</button>

</body>
</html>

25