10. База даних ас дзк

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

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

10.1. Класифікація сучасних субд.

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

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

• ієрархічна.

• мережна.

• реляційна.

• об'єктна.

• гібридна (елементи об'єктної з реляційною).

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

Залежно від об'єму підтримуваних БД і кількості користувачів РСКБД можна класифікувати:

Вищий рівень. Ці продукти підтримують крупні БД (сотні і тисячі Гбайт і більш), тисячі користувачів. В крупних корпораціях. Представники: ORACLE7, ADABAS 5.3.2, SQL SERVER11. Продукт цього класу володіє широким діапазоном функціональних можливостей, включаючи підтримку двофазної фіксації, тиражування даних, бережених процедур, трігерів, оперативно резервного копіювання. Він призначений для організації оптимального використовування системних ресурсів, що гарантує максимальну розширюваність. Підтримує БД, займаючі декілька фізичних дисків, зберігання нових типів даних. Підтримує майже всі апаратні і програмні платформи існуючі на сьогоднішній день, а також протоколи передачі даних. Як правило СКБД цього класу мають добру підтримка з боку виробника.

Середній рівень. Ці продукти підтримують БД до декількох сотень Гбайт, сотні користувачів. В невеликих корпораціях і підрозділах крупних фірм. Представники: InterBase 3.3, Informix-OnLine7.0, Microsoft SQL Server6.0. Як правило, це добри СКБД. Продукти даного сегменту підтримують такі сучасні технології, як тиражування даних, які синхронізують розподілені БД. Установка можлива на обмежених кількостей платформ. Недоліки: недостатня масштабованість, мала кількість підтримуваних програмних платформ.

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

Настільні СУБД. Для одного користувача, використовується для ведення настільної БД або як клієнт для підключення до серверу БД.

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

Вимоги до БД АС ДЗК.

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

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

2. Моделі баз даних та формати представлення даних повинні бути придатними для їх інтеграції в ГІС-середовища. Необхідно забезпечити можливість обміну даними та їх конвертації між підсистеми АСДЗК.

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

4. Інформаційна сумісність баз даних АСДЗК повинна базуватись на використанні єдиної системи кадастрових номерів земельних ділянок та об'єктів нерухомості. Це дасть можливість уникнення випадків неоднозначної ідентифікації земельних ділянок та уніфікації представлення інформації в базах даних.

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

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

7. Необхідно забезпечити надійний захист баз даних від несанкціонованого доступу на різних рівнях функціонування АСДЗК. Необхідна чітка регламентація доступу до баз даних. Доступ повинен бути різним для різних груп користувачів та розробників системи.

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

Розділ VII. СУБД ORACLE7 : загальні положення.

Структура бази даних ORACLE7.

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

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

Таблиці: стандартні логічні одиниці зберігання

ORACLE7 береже і представляє всі дані в таблицях. Таблиця - це масив зв'язаної інформації, тобто записів даних, що мають однакові атрибути. Атрибутами таблиці є її стовпці, а записи даних утворюють рядки таблиці. Кожний стовпець таблиці або атрибут містить конкретний тип даних. Коли користувач створює таблицю. він задає для кожного стовпця мітку і тип даних. ORACLE7 підтримує безліч різних типів даних наприклад: char, number date, long і інші.

Табличні області і файли даних: стандартні фізичні одиниці зберігання ORACLE7.

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

Ланцюжок таблиця - табличная_область - файл даних - це то що забезпечує для ORACLE7 характеристики реляційної бази даних незалежність від даних. Після створення таблиці користувачем інші користувачі можуть вставляти видалити або обновляти рядки в таблиці, указуючи її ім'я в операторі SQL . ORACLE7 бере на себе турботи по відображенню запиту SQL в коректні фізичні дані диска.

Область SYSTEM: таблична область для всіх таблиць

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

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

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

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

Розглянемо деякі компоненти системи бази даних ORACLE7.

Уявлення: способи проглядання даних

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

Уявлення можна розглядати як бережений запит (воно визначається за допомогою запиту). Наприклад:

CREATE VIEW reorder AS

SELECT id, onhand, reorder FROM stock

WHERE onhand<reorder

Уявлення REORDER визначає оператор CREATE VIEW. Цей запит відповідає тільки тим рядкам в таблиці STOCK, у яких поточна наявна кількість менше тієї крапки, коли потрібно замовляти нову партію товару.

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

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

Забезпечення цілісності даних.

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

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

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

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

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

Цілісність всієї таблиці: забезпечення унікальності кожного рядка.

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

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

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

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

CREATE TABLE customer

(id NUMBER(5,0) PRIMARY KEY

lastname CHAR(50) NOT NULL

firstname CHAR(50) NOT NULL

phone CHAR(20)

UNIQUE (lastname,firstname)

CHECK (state IN

('AL','AK','AZ','OH','SC','WV'))) --скорочені назви штатів

CREATE TABLE orders

(customerid NUMBER(5,0) NOT NULL

orderdate DATE NOT NULL

shipdate DATE

status CHAR(1)

CHECK (status IN ('F','B')) --F—оплачено, В—долг

FOREIGN KEY (customerid) REFERENCES customer)

В даному прикладі обмеження NOT NULL, CHECK дозволяють задати в таблиці обмеження домена. Для визначення первинного ключа і завдання обмежень цілісності таблиці розробник повинен описати цілісність таблиці за допомогою PRIMARY KEY. Для таблиці customer описується також обмеження UNIQUE, яке забезпечує унікальність імен/прізвищ покупців.

Посилальна цілісність: забезпечення синхронізації зв'язаних таблиць.

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

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

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

В приведеному вище прикладі за допомогою обмеження цілісності FOREIGN KEY задається обмеження посилальної цілісності, визначаючого для таблиці зовнішній ключ. За допомогою цього ми сполучаємо таблицю orders з батьківською таблицею customer.

Ділові правила: спеціальні правила цілісності даних.

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

Для завдання спеціальних правил ORACLE7 пропонує використовувати бережені процедури або трігери. Для повного уявлення про завдання спеціальних правил треба звернутися до довідкових матеріалів.