Переваги централізованого підходу в управлінні даними

 

• Можливість скорочення надмірності.

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

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

· Можливість усунення (певною мірою) суперечливості.

У дійсності цей наслідок попереднього пункту. Візьмемо приклад з життя — нехай викладач ЕЗ, що працює на кафедрі ГІС-технологій представлений двома різними записами в базі даних. Припустимо, що в СУБД не враховане це роздвоєння (тобто надмірність не контролюється). Тоді рано або пізно обов'язково виникне ситуація, при якій ці два записи перестануть погоджуватися а саме: одна з них буде змінена, а друга —ні. У цьому випадку база даних стане суперечлива. Ясно, що суперечлива база даних може видавати користувачеві неправильну, суперечливу інформацію.

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

· Можливість загального доступу до даних.

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

· Можливість дотримання стандартів.

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

· Можливість введення обмежень для забезпечення безпеки.

Завдяки повному контролю над базою даних АБД може забезпечити доступ до бази даних через певні канали, а отже, може визначити правила безпеки, які будуть перевірятися при спробі доступу до уразливих даних (знову ж під керівництвом адміністратора даних). Для різних типів доступу (вибірки, вставки, видалення й т.д.) і різних частин бази даних можна встановити різні правила.

· Можливість забезпечення цілісності даних.

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

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

• Можливість збалансувати суперечливі вимоги.

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

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

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

ім'я, наприклад. Прізвище, Ім'я, По батькові, Дата народження;

тип, наприклад, символьний, числовий, календарний;

довжина, наприклад, 15 байт, причому буде визначатися максимально можливою кількістю символів;

точність для числових даних, наприклад два десяткових знаки для відображення дробової частини числа.

Запис — сукупність логічно зв'язаних полів. Екземпляр запису - окрема реалізація запису, що містить конкретні значення її полів.

Файл (таблиця) — сукупність екземплярів записів однієї структури.

У структурі запису файлу вказуються поля, значення яких є ключами первинними (ПК), які ідентифікують екземпляр запису, і вторинними (ВК), які виконують роль пошукових або групованих ознак (за значенням вторинного ключа можна знайти кілька записів) [10].

 

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

 

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

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

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

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

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

 

Моделі даних

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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