загрузка...
загрузка...
На головну

Тема 4 Бази даних ГіЗІС

  1. OLAP: оперативна аналітична обробка даних.
  2. Trading Techniques Inc. надає місячні, тижневі, денні і погодинні (60 хвилин) дані по всіх ф'ючерсах за допомогою сервісу завантаження даних.
  3. Trading Techniques Inc. надає погодинні (60-хвилинні) дані по всіх ф'ючерсах за допомогою сервісу завантаження даних.
  4. V. УПРАВЛІННЯ ПОТОКАМИ ДАНИХ
  5. Автором програми для ЕОМ або бази даних визнається фізична особа, в результаті творчої діяльності якої вони створені.
  6. Аналіз і узагальнення досвіду передової практики і літературних даних
  7. Аналіз і оцінка даних аргументації

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

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

База даних ГІС включає графічні і атрибутивні дані, які можуть зберігатися разом або окремо.

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

Основна ідея організації структури бази даних полягає в тому, щоб максимально нормалізувати їх, т. Е. Розбити на смислові і функціональні групи.

концептуальне проектування

- Визначення кінцевої мети використання ГІС

- Рівень і детальність бази даних (масштаб, класифікації)

- Просторові елементи

- Непространственние елементи

- Визначення джерел просторових і непросторових даних

- Вік і інші тимчасові характеристики даних

- Територія, яку повинні покрити дані

- Інформаційна вивченість території

- Стандартні точки (тики) для просторового поєднання даних

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

логічне проектування

- Координатна система, яка визначає спосіб геокодування та суміщення даних

- Проект просторової "нарізки" листів карт

- Складання словника непросторових даних

- Просторова Топологизация даних

- Редагування просторових і непросторових даних, їх стикування через ідентифікатори

фізичне проектування

- Розміщення даних і програмних засобів ГІС на диску

- Фізичний обсягу бази даних

- Потреби дискового простору

- Швидкість доступу до файлових структурам

Бази даних ділять на ієрархічні, мережеві і реляційні.

Ієрархічні бази даних встановлюють сувору підпорядкованість між записами і складаються з упорядкованого набору дерев (з упорядкованого набору декількох екземплярів одного типу дерева). Тип дерева складається з одного «кореневого» типу записи і впорядкованого набору з нуля або більше типів піддерев (кожне з яких є певним типом дерева). Тип дерева в цілому являє собою ієрархічно організований набір типів записи (рис. 3.5).

Тут Квартал є предком для Земельного ділянки, а Земельна ділянка - нащадком для Кварталу. Земельна ділянка є предком для Частини ділянки, а частина ділянки - нащадком для Земельного ділянки. Між типами записи підтримуються зв'язки. Автоматично підтримується цілісність посилань між предками і нащадками.

Типовий представник ієрархічних систем - Information Management System (IMS) фірми IBM. Перша версія з'явилася в

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

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

Типовий представник мережевих систем - Integrated Database Management System (IDMS) компанії Cullinet Software, Inc., призначена для використання на машинах основного класу фірми IBM під управлінням більшості операційних систем. Архітектура системи заснована на пропозиціях Data Base Task Group (DBTG) Комітету з мов програмування Conference on Data Systems Languages ??(CODASYL).

Мережевий підхід до організації даних є розширенням ієрархічного. В ієрархічних структурах запис-нащадок повинна мати в точності одного предка; в мережевій структурі даних нащадок може мати будь-яке число предків. Мережева БД складається з набору записів і набору зв'язків між цими записами. Тип зв'язку визначається для двох типів запису: предка і нащадка (рис. 3.6).

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

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

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

Всі значення, що містяться в одному і тому ж стовпці, є даними одного типу. Наприклад, в стовпці «Районний центр» містяться тільки слова, в стовпці «Площа» містяться десяткові числа, а в стовпці «ID» - цілі числа, що представляють коди об'єктів, встановлені користувачем. Зв'язок між таблицями здійснюється по полях.

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

Поняття «тип даних» в реляційної моделі даних повністю адекватно поняттю «тип даних» в мовах програмування Зазвичай в сучасних реляційних БД допускається зберігання символьних, числових даних, бітових рядків, спеціалізованих числових даних (таких, як «гроші»), а також спеціальних « темпоральних »даних (дата, час, часовий інтервал) Досить активно розвивається підхід до розширення можливостей реляційних систем абстрактними типами даних (відповідними можливостями володіють, наприклад системи сімейства Ingres / Postgres). У нашому прикладі ми маємо справу з даними трьох типів: рядки символів, цілі числа і «гроші».

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

Схема відносини - це іменоване безліч пар [ім'я атрибута ім'я домену (або типу, якщо поняття «домен" не поддержіваетсян Ступінь, або «арность», схеми відносини - потужність цієї множини. Ступінь відносини СПІВРОБІТНИКИ дорівнює чотирьом т е воно є 4-арним. Якщо всі атрибути одного відносини визначені на різних доменах, слід використовувати для іменування атрибутів імена відповідних доменів (не забуваючи звісно, ??про те, що це є всього лише зручним способом іменування і не усуває відмінності між поняттями «домен» і «атрибут»).

Схема бази даних (В структурному сенсі) - це набір іменованих схем відносин.

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

відносини. Попросту кажучи, кортеж - це набір іменованих значень заданого типу.

ставлення - Це безліч кортежів, які відповідають одній схемі відносини. Іноді, щоб не плутатися, говорять «ставлення-схема» і «ставлення-екземпляр", іноді схему відносини називають заголовком відносини, а відношення як набір кортежів - тілом відносини. Насправді поняття «схема відносини» ближче до поняття «структурний тип даних» в мовах програмування. Було б цілком логічно дозволяти окремо визначати схему відносини, а потім одне або кілька відносин з даною схемою.

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

Звичайною виставою відносини є таблиця, заголовком якої служить схема відносини, а рядками - кортежі відносини-екземпляри; в цьому випадку імена атрибутів іменують стовпці цієї таблиці. Тому іноді говорять «стовпець таблиці», маючи на увазі «атрибут відносини». Реляційна база даних - це набір відносин, імена яких збігаються з іменами схем відносин в схемі БД.

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

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

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

При цьому:

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

фізичну впорядкованість рядків всіх таблиць можна визначати і для всієї БД (так роблять, наприклад, в Datacom / DB);

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

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

Для ефективного виконання завдань створення методів введення, оновлення, забезпечення файлового зберігання і контролю за доступом користувача до файлів виводу даних потрібно створити гнучку і добре організовану ГІС.

Зміст і класифікація системи управління базою даних

Ефективне використання цифрових даних передбачає наявність програмних засобів, що забезпечують функції їх зберігання, опису, поновлення і т. Д. В залежності від типів і форматів їх подання, від рівня програмних засобів ГІС та деяких характеристик середовища та умов їх використання можливі різні варіанти організації зберігання і доступу до просторових даних, причому способи організації розрізняються для позиційної (графічної) і семантичної їх частини.

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

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

Сучасні СУБД можна класифікувати відповідно до використовуваної моделлю даних [ієрархічна, мережева, реляційна, об'єктна, гібридна (елементи об'єктної з реляційної)];

Широке застосування при розробці програмного забезпечення ГІС отримали реляційні СУБД.

Системи, засновані на інвертованих списках, ієрархічні і мережні системи управління базами даних були попередниками СУБД.

До загальних характеристик ранніх систем можна віднести наступні:

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

2. Системи були засновані на будь-яких абстрактних моделях. Абстрактні уявлення ранніх систем з'явилися пізніше на основі аналізу та виявлення загальних ознак у різних систем разом з реляційним підходом.

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

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

До числа найбільш відомих систем, заснованих на інвертованих списках, відносяться Datacom / DB компанії Applied Data Research, Inc. (ADR), орієнтована на використання комп'ютерів основного класу фірми IBM, і Adabas компанії Software AG.

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

Недоліки цих СУБД: складність користування; необхідність інформації про фізичну організації, від якої залежать прикладні програми; перевантаженість логіки системи деталями організації доступу до БД.

До переваг реляційного підходу організації СУБД можна віднести:

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

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

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

Реляційні системи не відразу отримали широке поширення.

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

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

В даний час основними недоліками реляційних СУБД є:

деяка обмеженість (прямий наслідок простоти) при використанні в так званих нетрадиційних областях (найбільш поширеними прикладами є системи автоматизації проектування), в яких потрібні гранично складні структури даних;

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

в залежності від обсягу підтримуваних БД і числа користувачів [вищий рівень, середній рівень, нижній рівень, настільні СУБД (рис. 3.8)].

Вищий рівень СУБД підтримують великі БД (сотні і тисячі Гбайт і більше), які обслуговують тисячі користувачів, наприклад ORACLE7, ADABAS 5.3.2, SQL SERVER11.

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

SQL Server 10, співр. Sybase - Продукт, що підтримує обробку в реальному часі і процеси рішень. Він є СУБД одного рівня з Огас1е7, але має деякі обмеження в плані масштабованості і використовує обмежену кількість апаратних і програмних платформ.

Середній рівень СУБД підтримують БД до декількох сот Гбайт, обслуговують сотні користувачів. Представники: InterBase 3.3, Informix-OnLine7.0, Microsoft SQL Server 6.0.

Серед реляційних СУБД Informix-OnLine 7.0, співр. Software підтримує такі сучасні технології, як тиражування даних, синхронізуючий розподілені БД, і великі двійкові об'єкти. Його можна застосовувати для запуску OLTP-додатку-жень (високошвидкісний обробки транзакцій), але швидкість обробки в цьому випадку менше, ніж у продуктів верхній частині ринку. Установка можлива на обмеженому числі платформ. Має великі можливості для розширення.

Microsoft SQL Server 6.0, corp. Microsoft - Хороша СУБД, яка інтегрована з Windows NT, доповнюючи її. Недоліки: недостатня масштабованість, мале число підтримуваних програмних платформ.

Нижній рівень СУБД складають системи, які підтримують БД до 1 Гб і мають менше 100 користувачів. Використовують їх, як правило, в невеликих підрозділах. Представники: NetWare SQL 3.0, Gupta SQL-Base Server.

Настільні СУБДпризначені для одного користувача, використовуються для ведення настільною БД або як клієнт для підключення до сервера БД. Мають дуже обмежені можливості по обробці даних, а також характеризуються відсутністю можливості установки в мережі. Представники: FoxPro 2.6, corp. Microsoft, Paradox 5.0, співр. Borland

При використанні конкретної СУБД необхідно враховувати три ключові чинники:

· Архітектуру взаємодії клієнт / сервер;

· Спосіб або метод реалізації основних функцій;

· Рівень підтримки розподілених БД.

Одне з головних умов, що визначають необхідність використання технології баз даних при створенні ГІС, - підтримка сучасними СУБД мережевих можливостей зберігання і використання технологій локальних мереж (LAN) і віддалених мереж в так званих розподілених БД. Тим самим досягаються оптимальне використання обчислювальних ресурсів і можливість колективного доступу користувачів до запитуваною БД.

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

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

1. Дії по переструктуризацію даних.

2. Трансформація проекцій і зміна систем координат.

3. Операції обчислювальної геометрії.

4. Оверлейні операції (накладення різнойменних і різнотипних шарів даних).

5. Загальні аналітичні, графоаналитические і моделюють функції.

Результати обробки даних повинні трансформуватися в «человекочітаемий» документ. Програмні засоби ГІС включають досить широкий набір засобів генерації вихідних даних.

Документи, що генеруються на виході: табличні, графічні,

картографічні.

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

До числа функцій СУБД прийнято відносити:

1. управління даними у зовнішній пам'яті;

2. управління буферами оперативної пам'яті;

3. управління транзакціями;

4. ведення журналу змін даних;

5. підтримка мов бази даних (рис. 3.9).

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

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

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

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

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

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

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

підходу.

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

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

Для роботи з базами даних використовуються спеціальні мови, в цілому звані мовами баз даних. У ранніх СУБД підтримувалося кілька спеціалізованих за своїми функціями мов. Найчастіше виділялися дві мови: мова визначення схеми БД (SDL - Schema Definition Language) і мова маніпулювання даними (DML - Data Manipulation Language). SDL служив головним чином для визначення логічної структури БД, тобто тієї структури БД, який вона надається користувачам. DML містив набір операторів маніпулювання даними, т. Е. Операторів, що дозволяють заносити дані в БД, видаляти, модифікувати або вибирати існуючі дані.

В сучасних СУБД зазвичай використовується єдиний інтегрований мову, що містить всі необхідні засоби для роботи з БД, починаючи від її створення, і забезпечує базовий призначений для користувача інтерфейс з базами даних. Стандартною мовою найбільш поширених реляційних СУБД є мова SQL (Structured Query Language), який має такі основні характеристики:

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

· Містить спеціальні засоби визначення обмежень цілісності БД. При компіляції операторів модифікації БД компілятор SQL на підставі наявних у БД обмежень цілісності генерує відповідний програмний код;

· Визначення уявлень БД, які фактично є збереженими в БД запитами (результатом будь-якого запиту до реляційної БД є таблиця), з іменованими стовпцями за допомогою спеціальних операторів мови SQL;

· Авторизація доступу до об'єктів БД на основі спеціального набору операторів SQL. Повноваження користувачів описуються в спеціальних таблицях-каталогах, контроль повноважень підтримується на мовному рівні.

У реляційної СУБД можна виділити:

· Ядро СУБД (часто його називають Data Base Engine);

· Компілятор мови БД (зазвичай SQL);

· Командний мову;

o набір утиліт

ядро СУБД відповідає за управління даними у зовнішній пам'яті, буферами оперативної пам'яті, транзакціями і журнализацию.

Можна виділити такі компоненти ядра, як

· Менеджер даних,

· Менеджер буферів,

· Менеджер транзакцій і

· Менеджер журналу.

Функції цих компонентів між собою, і для забезпечення коректної роботи СУБД вони повинні взаємодіяти з ретельно перевіреним протоколах. Ядро СУБД має власний інтерфейс, який недоступний користувачам безпосередньо і використовуються в програмах, вироблених компілятором SQL (Або в підсистемі підтримки виконання таких програм), і утиліти БД. При використанні архітектури "клієнт-сервер» ядро ??є основною складовою серверної частини системи.

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

Така мова має такі засобами і характеристиками:

· Засобами опису як збережених даних, так і операцій над ними (пошук і модифікація);

· Засобами роботи з текстовими, графічними і числовими даними в різних уявленнях;

· Засобами захисту бази даних;

· Можливістю визначення нестандартних форматів і структур;

· Обчислювальними функціями;

· Засобами форматування екрану терміналу і генераторами відліків.

Крім того, він забезпечує високу продуктивність праці програміста.

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

створює таблиці;

вибирає і / або змінює дані в таблицях;

здійснює пошук даних відповідно до заданих критеріїв.

Маніпулюючи системними командами, можна читати повідомлення, що посилаються з терміналу, вибирати правила, що описують структуру необхідної частини даних, відшукувати і отримувати потрібні дані, застосовувати правила обробки, оновлювати знаходяться в базі елементи. За допомогою команд можливо також складати запити і повідомлення. Типове меню може включати в себе наступні варіанти вибору: посилку або вiдтворення повідомлення, завершення сеансу роботи, вибір запиту і т. П.

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

Таким чином, мова БД надає в розпорядження користувача такі можливості:

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

· Користуватися власними критеріями вибору і автоматично призначаються ключами вибірки;

· Користуватися вбудованими генераторами масок для форматування екранів терміналу із завданням індивідуальних заголовків;

· Застосовувати генератор звітів, який працює за схемою, складеної користувачем в діалоговому режимі;

· Викликати заздалегідь складені послідовності команд за допомогою меню.

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

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

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

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

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

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

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

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

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

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

При виборі СУБД керуються такими вимогами:

можливість оперувати даними різного типу;

наявність мови запитів високого рівня;

зберігання даних в одному із стандартних форматів або наявність конвектора для відповідних перетворень;

наявність можливостей роботи в мережах;

наявність можливості обробки великих обсягів інформації;

наявність системи розмежування доступу до інформації; наявність системи розмежувань за функціями обробки інформації;

наявність системи захисту даних від втрат через технічні збої.



Попередня   1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   Наступна

загальне поняття | Цілі і завдання ГІС і ЗІС | Тема 2 Організація інформації в ГіЗІС | Об'єктно-орієнтоване уявлення даних. | Цифрові просторові дані | Адміністративне управління та політика | Екологія і природокористування | Теоретична база створення ПГІС | Структура інформаційного простору | тематична навантаження |

загрузка...
© um.co.ua - учбові матеріали та реферати