Питання для самоперевірки

1. Предметна область і бази даних.

2. Роль баз даних в процесі формування інформаційних ресурсів, в тому числі для цілей управління територіями.

3. Класифікація інформаційних систем.

4. Використання ГІС в гідромеліорації.

5. Експертні системи для обробки даних.

2. Моделі даних

2.1 Види моделей даних

На великих ЕОМ сімдесятих років програмісти прагнули з максимальною ефективністю використовувати машинний час і пам'ять. Тому широке поширення одержав ієрархічний підхід до організації баз даних. Ієрархічні бази даних організовуються у вигляді дерев, що припускає нерівноправність між даними – одні дані виявляються жорстко підлеглі іншим. Така організація даних нагадує деякі схеми побудови баз знань в експертних системах і забезпечує високоефективний пошук інформації. Але ієрархічний підхід до організації баз даних має й очевидні недоліки, наприклад, необхідність жорстко визначати зв'язок між даними, що істотно ускладнює організацію інформації. Щоб перебороти подібні недоліки була запропонована мережна модель даних, у якій крім вертикальних зв'язків між даними, передбачалися й горизонтальні. Прикладом реалізації такої моделі може служити система директорій (фолдерів), що дозволяє організувати інформацію на жорсткому диску персонального комп'ютера. Але й ця модель вимагає досить більших зусиль при організації інформації.

Дані в базі даних називають "постійними" (хоча насправді вони можуть недовго залишатися такими!). Під словом "постійні" маються на увазі дані, які відрізняються від інших, більше мінливих даних, таких як проміжні результати, вхідні й вихідні дані, оператори управління робочі черги, програмні блоки управління й взагалі всі транзитні дані.

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

Така людино-орієнтована модель повністю незалежна від фізичних параметрів середовища зберігання даних. Зрештою цим середовищем може бути пам'ять людини, а не ЕОМ. Тому інфологічна модель не повинна змінюватися доти, поки якісь зміни в реальному світі не зажадають зміни в ній деякого визначення, щоб ця модель продовжувала відбивати предметну область.

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

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

Трьохрівнева архітектура (інфологічний, даталогічний і фізичний рівні) дозволяє забезпечити незалежність збережених даних від їхніх програм, що використовують. АБД може при необхідності переписати збережені дані на інші носії інформації й (або) реорганізувати їхню фізичну структуру, змінивши лише фізичну модель даних. АБД може підключити до системи будь-яке число нових користувачів (нових додатків), доповнивши, якщо треба, даталогічну модель. Зазначені зміни фізичної й даталогіної моделей не будуть замічені існуючими користувачами системи (виявляться "прозорими" для них), так само як не будуть замічені й нові користувачі. Отже, незалежність даних забезпечує можливість розвитку системи баз даних без руйнування існуючих додатків.

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

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

Спочатку стали використовувати ієрархічні даталогічні моделі. Простота організації, наявність заздалегідь заданих зв'язків між сутностями, подібність із фізичними моделями даних дозволяли домагатися прийнятної продуктивності ієрархічних СУБД на повільних ЕОМ з досить обмеженими обсягами пам'яті. Але, якщо дані не мали деревоподібної структури, то виникала маса складностей при побудові ієрархічної моделі й бажанні домогтися потрібної продуктивності.

Мережні моделі також створювалися для мало ресурсних ЕОМ. Це досить складні структури, що складаються з "наборів" - пойменованих дворівневих дерев. "Набори" з'єднуються за допомогою " записів-зв'язувань", створюючи ланцюжки й т.д. При розробці мережних моделей було вигадане безліч "маленьких хитростей", що дозволяють збільшити продуктивність СУБД, але істотно ускладнили останні. Прикладний програміст повинен знати масу термінів, вивчити кілька внутрішніх мов СУБД, детально представляти логічну структуру бази даних для здійснення навігації серед різних екземплярів, наборів, записів і т.п. Один з розроблювачів операційної системи UNIX сказав "Мережна база - це самий вірний спосіб втратити дані".

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

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