Теоретичний матеріал та презентація до Теми №4

1. Основи проектування баз даних

Проектування баз даних - це системний процес прийняття послідовних інженерно-технічних та методологічних рішень щодо створення структури бази даних, її концептуального узгодження з вимогами предметної області, забезпечення цілісності, оптимізації зберігання та швидкого доступу до інформації [8; 14].

У контексті геоінформаційних систем (ГІС) та земельно-інформаційних систем (ЗІС) проектування додатково враховує подвійну природу геоданих: поєднання складних векторно-просторових об'єктів (з їхніми топологічними та просторовими прив'язками) і якісно-кількісних атрибутивних характеристик [7; 12].

Основні кроки планування бази даних такі:

1. Збір інформації

2. Визначення ключових об'єктів або сутностей

3. Моделювання ключових об'єктів

4. Визначення типів інформації для кожного об'єкта або сутності

5. Визначення зв'язків між об'єктами або сутностями

Проєктування бази даних — це процес створення детальної моделі даних бази даних. Ця логічна модель даних містить усі необхідні рішення щодо логічного та фізичного проєктування, а також параметри фізичного зберігання, потрібні для формування опису мовою визначення даних (DDL), яку згодом можна використати для створення самої бази даних. Повноцінна модель даних містить детальні атрибути для кожної сутності.

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

Процес проєктування бази даних зазвичай складається з низки етапів, які виконує проєктувальник бази даних. Як правило, проєктувальник повинен:

•         Визначити зв'язки між різними елементами даних.

•         Сформувати логічну структуру даних на основі цих зв'язків.

Етапи проєктування бази даних

Процес проєктування бази даних поділяється на окремі частини та складається з низки етапів, а саме:

·         Аналіз вимог

·         Концептуальне проєктування бази даних (ER-діаграма)

·         Логічне проєктування бази даних (таблиці, нормалізація тощо)

·         Фізичне проєктування бази даних (індексування таблиць, кластеризація тощо)

Аналіз вимог. На цьому етапі проводиться детальний аналіз вимог. Мета етапу — сформувати чітке розуміння вимог. Для цього використовуються різні методи збору інформації, зокрема:

·         Інтерв’ю

·         Аналіз документів

·         Опитування

·         Відвідування об’єкта (робочого місця)

·         Спільне проєктування застосунків (JAD) та спільний аналіз вимог (JRA)

·         Прототипування.

Концептуальне проєктування бази даних. Результати аналізу вимог відображаються в концептуальній моделі. На цьому етапі використовується модель «сутність-зв’язок» (ER-модель). Для візуалізації концептуального проєкту застосовується ER-діаграма, що складається із сутностей, атрибутів і зв’язків.

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

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

2. Концептуальне та логічне моделювання

Моделювання баз даних є серцевиною процесу проектування, яка забезпечує перехід від реальних об'єктів та явищ навколишнього середовища до їхнього систематизованого цифрового представлення [14; 12].

У базах геоданих цей процес ускладнюється необхідністю моделювання як семантичних (атрибутивних) характеристик, так і складних тополого-просторових відношень між геопросторовими об'єктами [7].

Концептуальне моделювання даних – це один із трьох типів моделювання даних, також відомих як етапи моделювання даних. Цей процес включає створення концептуальних моделей даних, які допомагають організаціям візуалізувати бази даних, що призводить до більш ефективного та комплексного побудови баз даних [22].

Перехід від концептуальних до логічних та фізичних моделей даних

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

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

Платформно-незалежний характер концептуальних моделей даних дозволяє організаціям мислити за межами своїх поточних технологічних можливостей. Цей етап надає можливість розробити ідеальну базу даних, яка відповідає потребам бізнесу, виявляючи будь-які прогалини в існуючих інструментах або можливостях. Це також може допомогти виправдати інвестиції в нові технології [22].

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

Концептуальні моделі даних є важливими для визначення ключових сутностей, їхніх атрибутів та зв'язків між ними, що є критично важливим для прийняття рішень та стратегічного планування [22]:

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

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

Концептуальна модель даних є найбільш абстрактним типом моделі даних. Одним із поширених підходів до моделювання даних є метод «сутність/зв'язок» (ER), який формує основу для моделей даних.

3. Нормалізація баз даних

Нормалізація – це формалізований математично обґрунтований процес декомпозиції відношень (таблиць) бази даних на основі функціональних залежностей їхніх атрибутів. Головною метою нормалізації є усунення надмірності (дублювання) даних, забезпечення цілісності та запобігання аномаліям модифікації [11; 8].

Простіше кажучи, нормалізація – це формальний процес визначення того, які поля мають належати до яких таблиць у реляційній базі даних. Нормалізація ґрунтується на наборі правил, розроблених ще на етапі появи реляційних баз даних. Нормалізована реляційна база даних має низку переваг [14]:

•         Усунення надлишкового зберігання даних.

•         Точне моделювання об'єктів реального світу, процесів та взаємозв'язків між ними.

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

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

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

2. Первинний ключ

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

Первинний ключ повинен бути унікальним, обов'язковим і незмінним. Класична помилка, якої припускаються під час навчання створенню реляційних баз даних, - використання мінливого поля як первинного ключа [14].

Правильний підхід до створення первинного ключа передбачає використання унікального та незмінного значення.

З поняттям ключа тісно пов’язана особлива концепція нормалізації – функціональна залежність. Друга та третя нормальні форми дозволяють перевірити правильність функціональних залежностей. То що ж таке «функціональна залежність»? Вона описує, як одне поле (або комбінація полів) визначає інше поле [14].

Принципи нормалізації описуються через низку «нормальних форм», вимоги до яких стають дедалі суворішими. Першу нормальну форму (1НФ) найлегше забезпечити, другу (2НФ) — складніше, і так далі. Існує 5 або 6 нормальних форм, залежно від того, чиїх поглядів дотримуватися. Зручно говорити про нормальні форми, використовуючи їхні традиційні назви, оскільки ця термінологія є загальноприйнятою в галузі реляційних баз даних. Утім, до нормалізації можна підійти й без використання цієї термінології [14].

Перша нормальна форма (1НФ)

Першу нормальну форму легко зрозуміти й застосувати: Таблиця перебуває в першій нормальній формі, тоді і лише тоді, коли всі аотрибути атомарні і ключ не має пустих значень [14].

Друга нормальна форма (2НФ)

Друга нормальна форма допомагає виявити випадки, коли дві таблиці було об’єднано в одну. Визначення другої нормальної форми ґрунтується на поняттях первинного ключа та функціональної залежності. Друга нормальна форма визначається так:

Відношення перебуває в другій нормальній формі (2НФ) тоді й тільки тоді, коли воно перебуває в 1НФ і кожен неключовий атрибут повністю залежить від первинного ключа.

Іншими словами, таблиця перебуває у 2НФ, якщо:

1. Вона не містить груп, що повторюються. 2. Кожне поле, що не входить до складу ключа, функціонально залежить від усього ключа.

Якщо використовується ключ, що складається з одного поля, то таблиця, яка вже перебуває в першій нормальній формі (1НФ), автоматично відповідає вимогам другої нормальної форми (2НФ).

Третя нормальна форма (3НФ)

Третя нормальна форма забезпечує додатковий рівень перевірки того, що таблиці не були об’єднані. Таблиця повинна мати поле, яке однозначно ідентифікує кожен її запис, а кожне поле в таблиці має описувати об’єкт, який ця таблиця представляє. Щоб перевірити, чи відповідає таблиця, яка вже перебуває у другій нормальній формі (2NF), також і третій нормальній формі (3NF), слід поставити запитання: «Чи залежать будь-які неключові стовпці від інших неключових стовпців?» [14].

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

Вищі нормальні форми

Існують й інші, вищі нормальні форми, зокрема 4NF, 5NF, BCNF та PJ/NF. Ми обмежимося розглядом 3NF, оскільки її достатньо для більшості практичних потреб.

4. Фізичне проектування та оптимізація

1. Визначення структури таблиць, ключів, індексів та обмежень Фізичне проектування бази даних передбачає перехід від логічної моделі до конкретної реалізації у вибраній системі управління базами даних (СУБД). На цьому етапі визначаються таблиці, їхні атрибути, первинні та зовнішні ключі, а також обмеження цілісності. Первинні ключі гарантують унікальність записів, тоді як зовнішні ключі забезпечують зв’язки між таблицями. Обмеження (constraints) відіграють важливу роль у підтриманні коректності даних: наприклад, NOT NULL запобігає відсутності значень, а CHECK дозволяє контролювати діапазон допустимих значень. У ГІС це особливо важливо, адже дані про ґрунти, їхні властивості та просторові координати повинні бути узгодженими й непротирічними. Таким чином, правильно визначена структура таблиць є основою для стабільної роботи всієї системи [14].

2. Оптимізація запитів та продуктивності Оптимізація запитів полягає у створенні ефективних алгоритмів вибірки та обробки даних. У великих масивах просторової інформації навіть невелика неефективність може призвести до значних затримок. СУБД надають інструменти для аналізу виконання запитів (query execution plan), що дозволяє виявляти «вузькі місця» та оптимізувати їх. Оптимізація може включати переписування запитів, використання індексів, розбиття таблиць на партиції та застосування кешування. У сфері ГІС це критично, адже запити часто включають складні просторові операції — перетини, буферизацію, накладання шарів [14].

3. Використання індексів для швидкого пошуку Індекси — це спеціальні структури даних, які прискорюють пошук і вибірку інформації. У класичних базах даних застосовуються B‑tree індекси, але для просторових даних використовуються спеціалізовані індекси, наприклад R‑tree. R‑tree індекси дозволяють швидко знаходити об’єкти у просторі, визначати їхні перетини та близькість. Це значно зменшує час виконання запитів у ГІС. Індекси також можуть бути комбінованими — наприклад, одночасно враховувати геометрію та атрибутивні характеристики. Таким чином, використання індексів є ключовим фактором продуктивності при роботі з великими геопросторовими базами даних [14].

4. Особливості роботи з великими масивами просторових даних У ГІС обсяги даних можуть бути величезними — від сотень тисяч до мільйонів об’єктів, кожен із яких має геометрію та атрибутивну інформацію. Обробка таких масивів вимагає не лише оптимізації запитів, а й правильного проектування архітектури бази даних: розподілу даних на шари, використання партицій, налаштування кластеризації. Важливим є також застосування технологій паралельної обробки та розподілених систем зберігання даних. У ґрунтозахисних дослідженнях це дозволяє працювати з великими наборами даних моніторингу, супутникових знімків та результатів лабораторних аналізів без втрати продуктивності [14].

5. Значення для ГІС та охорони ґрунтів Фізичне проектування та оптимізація баз даних у ГІС забезпечують не лише швидкість роботи, а й точність результатів аналізу. Правильна структура таблиць, використання ключів та індексів гарантують узгодженість даних, що є критично важливим для екологічних досліджень. Оптимізація запитів дозволяє ефективно виконувати складні просторові операції, необхідні для моделювання процесів деградації ґрунтів. Таким чином, цей етап проектування є фундаментом для створення надійних інформаційних систем у сфері охорони земельних ресурсів [14].

5. Проектування баз даних для охорони ґрунтів

Проектування баз даних для охорони ґрунтів є спеціалізованим напрямом розробки геоінформаційних систем (ГІС) та земельно-інформаційних систем (ЗІС), який поєднує методики реляційного та об'єктно-орієнтованого моделювання з вимогами ґрунтознавства, агрохімії, землевпорядкування та екологічного моніторингу [1; 7].

Головна мета створення таких баз геоданих – забезпечення системного збору, збереження, просторового аналізу та оперативного надання інформації про стан ґрунтового покриву для запобігання деградаційним процесам, проведення контурно-меліоративного впорядкування та обґрунтування заходів із відновлення родючості [1; 2].

Опис основних таблиць та їхніх атрибутів:

LandParcels (Земельні ділянки / поля): містить кадастровий номер, площу, цільове призначення, орендаря та векторні межі (MultiPolygon).

SoilPolygons (Контури ґрунтових відмінностей): векторний шар ґрунтової карти з шифром ґрунту, генетичною назвою, гранулометричним складом та класом придатності.

SoilSamples (Точки пробовідбору / моніторингові станції): точкова геометрія (Point), дата та час відбору, висотна відмітка ( Z ), метод відбору.

LabSoilAnalyses (Результати лабораторних аналізів): таблиця семантичних даних ( 1:N  до проб), що включає вміст органічного вуглецю/гумусу (%),  pH  водної та сольової витяжок, вміст рухомого фосфору та калію, щільність складення, вміст важких металів та залишків пестицидів.

SoilDegradationEvents (Записи про деградаційні процеси): класифікація еродованості (водна, вітрова), ступень дегуміфікації, деструкції, підтоплення чи замивання.

ProtectionMeasures (Ґрунтоохоронні та меліоративні заходи): перелік запланованих та виконаних заходів (консервація, заліснення, вапнування, створення протиерозійних лісосмуг, диференційоване внесення добрив).

6. Контрольні запитання

• Що таке проектування баз даних і які його основні етапи?

• У чому полягає різниця між концептуальним та логічним моделюванням?

• Які елементи відображаються на ER‑діаграмі?

• Що таке нормалізація баз даних і яка її мета?

• Які проблеми виникають у базі даних без нормалізації?

• Що означає перша нормальна форма (1НФ) і які вимоги вона встановлює?

• У чому полягає друга нормальна форма (2НФ) та як вона усуває надлишковість?

• Які особливості третьої нормальної форми (3НФ) і чому вона важлива?

• Як нормалізація сприяє ефективності роботи з даними у ґрунтозахисних дослідженнях?

7. Презентація

Презентація (завантажити тут)

Список джерел

1.             Добряк Д. С., Канаш О. П., Бабміндра Д. І., Розумний В. М. Класифікація та типізація земель як наукова основа їх раціонального використання й охорони. Київ: Урожай, 2019. 208 с.

2.             ДСТУ ISO 19101:2009. Географічна інформація. Еталонна модель. Київ: Держспоживстандарт України, 2012. 44 с.

3.             Зацерковний В. І., Бурачек В. Г., Железняк О. О., Терещенко А. О. Геоінформаційні системи і бази даних: монографія. Ніжин: НДУ ім. М. Гоголя, 2014. 492 с.

4.             Карпінський Ю. О. та ін. Основи створення інтероперабельних геопросторових даних. Київ: КНУБА, 2023. 302 с.

5.  Кузьменко І. С., Москаленко А. А., Заячківська Б. Б. Проєктування бази геопросторових даних для інформаційного забезпечення систем органічного землеробства. Агроекологічний журнал. 2026. № 1. DOI: https://doi.org/10.33730/2077-4893.1.2026.354126

6.  Основи геоінформаційних систем і бази даних : підручник /  О. Є. Поморцева ; Харків. нац. ун-т міськ. гос-ва ім. О. М. Бекетова. – Харків : ХНУМГ ім. О. М . Бекетова, 2022. – 346 с.

7.  Світличний О.О. Основи геоінформатики: Навчальний посібник /О.О.Світличний, С.В. Плотницький /За заг. ред. О.О. Світличного. Суми: ВТД«Університетська книга», 2006. 295 с.

8.  Четверіков Б. В. Геоінформаційні системи і бази даних в агроінженерії: навч. посібник. Львів: Видавництво Львівської політехніки, 2024. 196 с.

9.  Advanced Navigation. (n.d.). Vector data. Advanced Navigation. Retrieved September 20, 2026, from https://www.advancednavigation.com/glossary/vector-data/

10.         Awati, R., Zola, A., & Fontecchio, M. (2025, June 12). What is spatial data? TechTarget. https://www.techtarget.com/data-technologies/definition/spatial-data

11.         Codd E. F. A Relational Model of Data for Large Shared Data Banks. Communications of the ACM. 1970. Vol. 13, No. 6. P. 377–387.

12.         DeMers M. N. Fundamentals of Geographic Information Systems. 4th ed. Wiley, 2009. 480 p.

13.         Desmet, P.J.J. and Govers, G. (1996) A GIS Procedure for Automatically Calculating the USLE LS Factor on Topographically Complex Landscape Units. Journal of Soil and Water Conservation, 51, 427-433.

14.         Elmasri R., Navathe S. B. Fundamentals of Database Systems. 7th ed. Pearson, 2015. 1280 p.

15.         ESRI. What is GIS? URL: https://www.esri.com/en-us/what-is-gis/overview

16.         European Commission. EU Soil Strategy for 2030: Reaping the benefits of healthy soils for people, food, nature and climate. Brussels: EC, 2021. 26 p. URL: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:52021DC0699

17.         FAO. Global Soil Partnership: GloSIS Data Exchange Specifications. Rome: FAO, 2022. 88 p.

18.         FAO. Soil Data and Information Systems for Sustainable Soil Management. Rome: FAO, 2021. 96 p.

19.         FAO. State of the Art Report on Global Soil Spatial Information. Rome: 19. 142 p.

20.         Forrest, M. (2021, December 20). What is spatial SQL? Matt Forrest. https://forrest.nyc/what-is-spatial-sql/

21.         Getis A., Ord J. K. The Analysis of Spatial Association by Use of Distance Statistics. Geographical Analysis. 2010. Vol. 24 (3). P. 189–206. DOI:10.1111/j.1538-4632.1992.tb00261.x

22.         IDERA. (2025, June 5). What is conceptual data modeling? ER/Studio. https://erstudio.com/blog/conceptual-data-modeling/

23.         IDERA. (2024, June 3). What is logical data modeling? ER/Studio. https://erstudio.com/blog/logical-data-modeling/

24.         Kaldate, S. (2024, May 23). Evolution of Database Management System (DBMS). LinkedIn. https://ua.linkedin.com/pulse/evolution-database-management-system-dbms-soham-kaldate-k2kic

25.         Moskalenko A. GIS support of forming spatial decisions on land use. Mechanization in Agriculture & Conserving of the Resources. 2021. Vol. 67, No. 3. P. 79–81.

26.         Moskalenko A., Andriianov V. Development of a geospatial database for planning land protection measures against wind erosion. Zemleustriy, kadastr i monitorynh zemelʹ. 2024. No. 4. P. 107–113. DOI: https://doi.org/10.31548/zemleustriy2024.04.010

27.         Open Geospatial Consortium (OGC). OpenGIS Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture. OGC 06-103r4, 2011.

28.          Polytechnic. (2025). Chapter 5: Databases and queries. In An introduction to GIS. Saskatchewan Open Education Resources (SaskOER). https://www.saskoer.ca/slicegis/part/chapter-5-databases-and-queries/

29.         PostGIS Documentation Team. PostGIS Manual (Versions 3.4 / 3.5). OSGeo. URL: https://postgis.net/documentation/

30.         Saskatchewan Polytechnic. (2025). Chapter 4: Spatial data models. In An Introduction to GIS. https://www.saskoer.ca/slicegis/part/chapter-4-spatial-data-models

31.         Spatial Eye. (n.d.). What is attribute data in GIS? https://spatial-eye.com/blog/spatial-analysis/what-is-attribute-data-in-gis/

32.         Tool reference (n.d.) ArcGIS https://desktop.arcgis.com/en/arcmap/latest/tools/main/a-quick-tour-of-geoprocessing-tool-references.htm

USGS (n.d.) 3D Elevation Program https://www.usgs.gov/3d-elevation-program?