Бази даних як подання об'єктів реального світу

База даних є інформаційною моделлю реального світу в певній предметній галузі. Згідно з тлумачним словником з геоінформатики (Баранов и др., 1999) база даних (БД, data base, database, DB) — це сукупність даних, організованих за певними правилами, що встановлюють загальні принципи опису, збереження і маніпулювання даними.
У базах даних залежно від призначення (база даних підприємства, муніципальна база даних, база даних адміністративного району чи області) може зберігатися й оброблятися різна інформація: списки співробітників підприємств з їх обліковими даними, списки будинків і їх технічні характеристики, юридичні або статистичні описи земельних ділянок, об'єктів адміністративного керування та ін. Так само залежно від призначення бази даних може змінюватися перелік об'єктів, описуваних у базі даних; склад атрибутів, що описують ці об'єкти; спосіб і ступінь формалізації атрибутів; організація зв'язку між різними об'єктами бази даних та ін.
Об'єкти бази даних можуть бути описані різними способами: у вигляді текстових описів, цифрових кодів, комбінованих цифро-буквених класифікаторів, числових значень різного типу, календарних дат та ін. Кожен однотипний об'єкт бази даних описується однаковим набором атрибутів, таким чином, база даних складається з окремих записів, що характеризують кожний об'єкт і покажчики зв'язків між ними.
У більшості випадків бази даних проектуються таким чином, щоб один або кілька атрибутів однозначно ідентифікували запис. Сукупність значень цих атрибутів називається ключем запису, а самі атрибути — ключовими атрибутами. Ключ запису можна розглядати як унікальне ім'я запису, за яким користувач завжди може знайти цей запис.
У реальному світі часто можна спостерігати однорідні об'єкти (будинки, водойми, населені пункти та ін.). Відповідно в базі даних такі об'єкти природно представляти у вигляді декількох екземплярів таких записів, тобто записів з однаковими атрибутами. Аналогічна ситуація має місце і зі зв'язками — у базі даних є багато однотипних зв'язків, що з'єднують однотипні об'єкти.
У концептуальній схемі вся безліч однотипних записів подається одним абстрактним записом, що називають типом запису. Кожному типу записів відповідають ім'я і список атрибутів. Аналогічно безлічі наявних у базі даних однотипних зв'язків у концептуальній схемі відповідає один тип зв'язку.
У базі даних виділяють: постійні дані, що відрізняються від інших, більш мінливих, таких, як проміжні результати обробки даних; вхідні і вихідні дані; керуючі оператори; робочі черги — і взагалі всі службові дані, використовувані в процесі роботи. Природно, у процесі роботи постійні дані так само можуть зазнавати змін: створюються або видаляються об'єкти, змінюються значення параметрів, змінюється набір або порядок проходження параметрів у записі та ін.
Більш детально концепцію баз даних можна показати на прикладі муніципальної бази даних. Звичайним набором муніципальної бази даних є вулиці, будинки і споруди, інженерні комунікації, міські технічні служби, суб'єкти адміністративного розподілу (міські райони) та ін. Як об'єкт може використовуватися сукупність усіх будинків і споруд на території міста; цей об'єкт описується набором параметрів, що містять: адресні дані; належність якійсь організації; реквізити організацій-власників; технічні характеристики будинків (поверховість, площа, конструкційні матеріали); експлуатаційні характеристики (поточний стан, дати ремонту). Таким чином, будь-який тип об'єктів бази даних може мати зв'язок з одним або декількома типами об'єктів. Такі зв'язки називаються відношеннями. Відношення між об'єктами можуть бути різних типів: один до одного, один до декількох, односторонні і двосторонні.

Рис. 3.1. Приклад концептуальної схеми муніципальної бази даних (доступно при скачуванні повної версії підручника)

На рис. 3.1 наведено блок-схему муніципальної бази даних, що показує основні об'єкти і відносини між ними. Як приклади завдань, які можна розв'язати за допомогою такої бази даних, можна навести такі:
- задано обліковий номер спорудження, необхідно знайти вуличну адресу, і навпаки;
- задано адресу спорудження, знайти його власника;
- задано власника (землекористувача), знайти всі належні йому спорудження;
- знайти всі спорудження, термін останнього ремонту яких перевищує 20 років.

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

Моделі даних

Основою бази даних є модель даних — фіксована система понять і правил для представлення даних структури, стану і динаміки проблемної області в базі даних. У різний час послідовне застосування одержували ієрархічна, мережна і реляційна моделі даних. У наш час усе більшого поширення набуває об'єктно-орієнтований підхід до організації баз даних ГІС.

Ієрархічна модель даних

Часто об'єкти перебувають у відношеннях, що називають ієрархічними: відношення «частина — ціле» (наприклад, адміністративна область складається з районів, сільських і міських рад, населених пунктів та ін.); видове відношення (наприклад, будинки бувають житлові, виробничі та ін.); відношення підпорядкованості (наприклад, губернатор — мер міста).

Рис. 3.2. Схема відношень між об'єктами в ієрархічній базі даних (доступно при скачуванні повної версії підручника)

Об'єкти, що перебувають в ієрархічних відношеннях, утворюють дерево «орієнтований граф», у якого є тільки одна вершина, не підлегла жодній іншій вершині (цю вершину називають коренем дерева); будь-яка інша вершина графа підлегла лише одній іншій вершині (рис. 3.2).
Концептуальна схема ієрархічної моделі являє собою сукупність типів записів, пов'язаних типами зв'язків в одне чи кілька дерев. Усі типи зв'язків цієї моделі належать до виду «один до декількох» і зображуються у вигляді стрілок.
Таким чином, взаємозв'язки між об'єктами нагадують взаємозв'язки в генеалогічному дереві, за єдиним винятком: для кожного породженого (підлеглого) типу об'єкта може бути тільки один вхідний (головний) тип об'єкта. Тобто ієрархічна модель даних допускає тільки два типи зв'язків між об'єктами: «один до одного» і «один до декількох». Ієрархічні бази даних є навігаційними, тобто доступ можливий тільки за допомогою заздалегідь визначених зв'язків.
При моделюванні подій, як правило, необхідні зв'язки типу «багато до декількох». Як одне з можливих рішень зняття цього обмеження можна запропонувати дублювання об'єктів. Однак дублювання об'єктів створює можливості неузгодженості даних.
Достоїнство ієрархічної бази даних полягає в тому, що її навігаційна природа забезпечує швидкий доступ при проходженні вздовж заздалегідь визначених зв'язків. Однак негнучкість моделі даних і, зокрема, неможливість наявності в об'єкта декількох батьків, а також відсутність прямого доступу до даних роблять її непридатною в умовах частого виконання запитів, не запланованих заздалегідь. Ще одним недоліком ієрархічної моделі даних є те, що інформаційний пошук з нижніх рівнів ієрархії не можна спрямувати по вище розміщених вузлах.

Мережна модель даних

У мережній моделі даних поняття головних і підлеглих об'єктів дещо розширені. Будь який об'єкт може бути і головним, і підлеглим (у мережній моделі головний об'єкт позначається терміном «власник набору», а підлеглий — терміном «член набору»). Той самий об'єкт може одночасно виконувати і роль власника, і роль члена набору. Це означає, що кожний об'єкт може брати участь у будь-якій кількості взаємозв'язків.
Подібно до ієрархічної, мережну модель також можна подати у вигляді орієнтованого графа. Але в цьому випадку граф може містити цикли, тобто вершина може мати кілька батьківських вершин.
Така структура набагато гнучкіша і виразніша від попередньої і придатна для моделювання більш ширшого класу завдань. У цій моделі вершини є сутностями, а ребра, що їх з'єднують, — відношеннями між ними (рис. 3.3).

Рис. 3.3. Схема відношень між об'єктами в мережній базі даних (доступно при скачуванні повної версії підручника)

Ієрархічні і мережні бази даних часто називають базами даних з навігацією. Ця назва відбиває технологію доступу до даних, використовувану при написанні програм обробки мовою маніпулювання даними. При цьому доступ до даних по шляхах, не передбачених при створенні бази даних, може потребувати нерозумно тривалого часу.
Підвищуючи ефективність доступу до даних і скорочуючи таким чином час відповіді на запит, принцип навігації разом з цим підвищує і ступінь залежності програм і даних. Програми обробки даних виявляються жорстко прив'язаними до поточного стану структури бази даних і повинні бути переписані при її змінах. Операції модифікації і видалення даних вимагають переустановлення покажчиків, а маніпулювання даними залишається записоорієнтованим. Крім того, принцип навігації не дозволяє істотно підвищувати рівень мови маніпулювання даними, щоб зробити його доступним користувачу-непрограмісту чи навіть програмісту-непрофесіоналу. Для пошуку запису-мети в ієрархічній або мережній структурі програміст повинен спочатку визначити шлях доступу, а потім — крок за кроком переглянути всі записи, що трапляються на цьому шляху.
Наскільки складними є схеми представлення ієрархічних і мережних баз даних, настільки і трудомістким є проектування конкретних прикладних систем на їхній основі. Як показує досвід, тривалі терміни розроблення прикладних систем нерідко призводять до того, що вони постійно перебувають на стадії розроблення і доопрацювання. Складність практичної реалізації баз даних на основі ієрархічної і мережної моделей визначила створення реляційної моделі даних.

Реляційна модель даних

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

Рис. 3.4. Схема відношень між об'єктами в реляційній базі даних (доступно при скачуванні повної версії підручника)

Назва «реляційна» (relational) пов'язана з тим, що кожен запис у таблиці даних містить інформацію, яка стосується (related) якогось конкретного об'єкта. Крім того, зв'язані між собою (тобто такі, що знаходяться в певних відношеннях — relations) дані навіть різних типів в моделі можуть розглядатися як одне ціле.

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

Порядок розміщення рядків і стовпців у таблиці довільний; таблиця такого типу називається відношенням. У сучасній практиці для рядка використовується термін «запис», а для стовпця термін «поле».
Основною відмінністю пошуку даних в ієрархічних, мережних і реляційних базах даних є те, що ієрархічні і мережні моделі даних здійснюють зв'язок і пошук між різними об'єктами за структурою, а реляційні — за значенням ключових атрибутів (наприклад, можна знайти всі записи, значення яких у полі «номер будинку» дорівнює 3, але не можна знайти 3-й рядок).
Оскільки реляційна структура концептуально проста, вона дозволяє реалізовувати невеликі і прості (і тому легкі для створення) бази даних, навіть персональні, сама можливість реалізації яких ніколи навіть і не розглядалася в системах з ієрархічною чи мережною моделлю.
Недоліком реляційної моделі даних є надмірність по полях (для створення зв'язків між різними об'єктами бази даних).
Практично всі існуючі на сьогоднішній день комерційні бази даних і програмні продукти для їх створення використовують реляційну модель даних.