Дослідження баз даних в гнучких інтегрованих системах

Размещено на http://www.allbest.ru/

Дослідження баз даних в гнучких інтегрованих системах

1. Призначення і область застосування баз даних

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

2. Технології доступу до баз даних

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

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

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

На сьогодні існує безліч технологій доступу до даних, таких як BDE, OLE, ODBC, ADO, і дотепер розробляються нові, надійніші, зручніші в роботі і більш швидкодіючі технології.

2.1 Технологія BDE

Borland Database Engine (BDE) є набором інтерфейсів для доступу до різних баз даних. З погляду користувачів - BDE це всього лише проста конфігураційна утиліта, в якій задаються драйвери і описуються інтерфейси для доступу до баз даних. Тим самим досягається незалежність табличних форматів.

Можливості BDE:

- підтримка багатьох форматів. У BDE вбудована підтримка багатьох форматів. До того ж BDE автоматично підтримує все ODBC-драйвера (Open Database Connectivity - ще один інтерфейс до баз даних), встановлені в операційній системі.

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

Головний недолік BDE полягає в необхідності розповсюдження BDE разом із створеним застосуванням, що «обважнює» інсталяцію програми.

2.2 Технологія ADO

Технологія Microsoft ActiveX Data Objects забезпечує універсальний доступ до джерел даних із програм, які використовують БД. Таку можливість надають функції набору інтерфейсів, створені на основі загальної моделі об'єктів СОМ і описані в специфікації OLE DB.

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

За сервери БД турбуватися не варто, обробка запитів SQL - це їх основний обов'язок. Але як бути з файловими послідовностями, електронними таблицями, файлами електронної пошти і т.д.? Тут на допомогу приходять механізми ADO і інтерфейси OLE DB.

OLE DB є набором спеціалізованих об'єктів СОМ, що інкапсулюють стандартні функції обробки даних, і спеціалізовані функції конкретних джерел даних і інтерфейсів, що забезпечують передачу даних між об'єктами.

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

Об'єкти OLE DB створюються і функціонують так само, як і інші об'єкти СОМ. Кожному об'єкту відповідає ідентифікатор класу CLSID, що зберігається в системному реєстрі. Для створення об'єкту використовується метод CoCreateinstance і відповідна фабрика класу. Об'єкту відповідає набір інтерфейсів, до методів яких можна звертатися після створення об'єкту.

В результаті система звертається не прямо до джерела даних, а до об'єкту OLE DB, який «уміє» представити дані (наприклад, з файлу електронної пошти) у вигляді таблиці БД або результату виконання запиту SQL.

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

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

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

Нижченаведений опис специфікації OLE DB представлений відповідно до офіційної термінології Microsoft для даної наочної області.

Специфікація OLE DB розрізняє наступні типи об'єктів, які будуть розглянуті нижче.

· Нумератор (Enumerator) виконує пошук джерел даних або інших нумераторів. Використовується для забезпечення функціонування провайдерів ADO.

· Об'єкт-джерело даних (Data Source Object) представляє сховище даних.

· Сесія (Session) об'єднує сукупність об'єктів, що звертаються до одного сховища даних.

· Транзакція (Trasaction) інкапсулює механізм виконання транзакції.

· Команда (Command) містить текст команди і забезпечує її виконання. Командою може бути запит SQL, звернення до таблиці БД і т.д.

· Набір рядів (Rowset) є сукупністю рядків даних, що є результатом виконання команди ADO.

· Об'єкт-помилка (Error) містить інформацію про виняткову ситуацію.

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

3. Схема обміну даними при роботі з БД

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

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

Цикл взаємодії користувача з БД за допомогою додатку можна розділити на такі основні етапи:

1. Користувач термінала (1) в процесі діалогу з додатком формулює запит (2) на деякі дані з БД.

2. Додаток (3) на програмному рівні засобами мови маніпулювання даними формулює запит (4), з яким звертається до СКБД.

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

4. Програми методів доступу файлової системи ОС зчитують (6) із зовнішньої пам'яті шукані дані та вміщають їх в системні буфери СКБД.

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

6. Результати вибору даних з бази додаток (3) відображає (9) на терміналі користувача (1).

У випадку роботи користувача в діалоговому режимі із СКБД (без додатку) цикл взаємодії користувача з БД спрощується.

1. Користувач термінала (10) формулює на мові запитів СКБД по зв'язку (11) запит на вибір деяких даних з бази.

2. СКБД визначає місцезнаходження потрібних даних і звертається (5) за ними до ОС, яка зчитує (6) їх із зовнішньої пам'яті шукані дані та вміщує їх в системні буфери СКБД.

3. Інформація із системних буферів перетворюється (12) у потрібний формат після чого відображується (13) на терміналі користувача (10).

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

Іноді до обчислювальної системи підключається так званий «віддалений користувач», що знаходиться на деякій відстані від ЕОМ та з'єднаний з нею за допомогою якого-небудь передаючого середовища (телефонний канал, радіоканал та ін.). Найчастіше такий користувач емулюється під звичайного локального користувача. Як правило, СКБД «не помічає» підміни та обслуговує запити як звичайно.

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

Багатокористувальницькі СКБД часто використовуються на великих та середніх ЕОМ, але основним режимом використання ресурсів є колективний доступ.

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

Технологію одночасної роботи користувача з декількома програмами непогано реалізовано в Windows. При роботі у Windows СКБД не має необхідності підтримувати декілька сеансів роботи з користувачами.

4. Архітектури баз даних

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

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

Перевагою організації ІС за архітектурою клієнт-сервер допускає різні варіанти реалізації.

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

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

Для створення та керування персональними БД та додатків, які з ними працюють, використовуються СКБД, такі як Access, Visual FoxPro фірми Microsoft, Paradox фірми Borland.

Корпоративна БД створюється, підтримується та функціонує під керуванням сервера БД, наприклад Microsoft SQL Server, Oracle Server.

В залежності від розмірів організації та особливостей розв'язуваних задач ІС може мати одну з наступних конфігурацій:

· Комп'ютер-сервер, який містить корпоративну та персональні БД.

· Комп'ютер-сервер та персональні комп'ютери з ПБД.

· Декілька комп'ютерів - серверів та персональних комп'ютерів з ПБД.

Використання архітектури клієнт-сервер дає можливість поступового нарощування ІС підприємства, по-перше по мірі розвитку підприємства, по-друге по мірі розвитку самої ІС.

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

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

Така незалежність досягається підтримуваним СКБД багаторівневим представленням даних на логічному (користувальницькому) та фізичному рівні.

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

Для розгляду методів організації БД визначимо такі поняття.

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

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

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

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

Місцезнаходження Ядра БД і бази даних залежить від архітектури, яка використовується. Розрізняють чотири різновиди архітектури баз даних:

· локальні бази даних, архітектура «файл-сервер»;

· архітектура «клієнт-сервер»;

· багатоланкова (три-ланкова N-tier або multi-tier) архітектура.

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

5. Моделі представлення даних

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

· ієрархічну;

· мережну;

· реляційну;

· обє'ктно-орієнтовану.

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

У мережній моделі дані організуються у вигляді довільного графа. Недоліком мережної моделі є висока складність її організації.

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

Реляційна модель одержала свою назву від англійського терміна relation (відношення) і була запропонована в 70-х роках співробітником фірми IBM Эдгаром Коддом. Реляційна БД являє собою сукупність таблиць, зв'язаних відносинами. Достоїнствами реляційної моделі даних є простота, гнучкість структури, зручність реалізації на комп'ютері, наявність теоретичного опису. Дана розробка заснована на реляційних базах даних.

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

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

Щоб таблицю можна було вважати відношенням, вона повинна задовольняти певним вимогам:

· Значення в комірках повинні бути одиночними.

· Всі записи в стовпці повинні бути одного типа.

· Кожен стовпець повинен мати унікальне ім'я.

· У відношенні не може бути двох однакових рядків.

· Порядок рядків не має значення.

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

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

Реляційний спосіб доступу до даних ґрунтується на операціях із групами записів. Для завдання операцій використовуються засоби мови структурованих запитів - SQL (Structured Query Language), тому реляційний спосіб доступу називають також SQL-орієнтованим. Для його реалізації в програмних продуктах Delphi як набір даних повинні застосовуватися такі компоненти, як Query чи storedProc, що дозволяють виконати SQL-запит.

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

Стосовно до локальних БД використання реляційного способу доступу не дає істотної переваги, але й у цьому випадку за допомогою SQL-запиту можна:

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

· сортувати набір даних по будь-якому полю, у тому числі неіндексованому;

· здійснювати пошук даних по частковому збігу зі значеннями полів.

6.1 Таблиці

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

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

Структура таблиці включає наступну інформацію:

· Ім'я таблиці - Ім'я, по якому до таблиці можна звернутися у властивостях, методах і операторах SQL.

· Стовпці таблиці - Категорії інформації, збереженої в таблиці. Кожен стовпець має ім'я і тип даних. Табличні і стовпцеві обмеження - Обмеження цілісності, визначені на рівні таблиці чи на рівні стовпця.

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

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

Стовпці таблиці упорядковані ліворуч праворуч, і їхній порядок визначається при створенні таблиці. У будь-якій таблиці завжди є як мінімум один стовпець. У стандарті ANSI/ISO не вказується максимально припустиме число стовпців у таблиці, однак майже у всіх комерційних СКБД ця межа існує і звичайно складає приблизно 255 стовпців.

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

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

6.2 Ключові поля

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

Оскільки рядки в реляційній таблиці не упорядковані, не можна вибрати рядок по його номеру в таблиці. У таблиці немає «першого», «останнього» чи «тринадцятого» рядка. Тоді яким чином можна вказати в таблиці конкретний рядок, наприклад рядок для студента з прізвищем Іванов?

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

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

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

Хоча первинні ключі є важливою частиною реляційної моделі даних, у перших реляційних СУБД (System/R, DB2, Oracle і інших) не була забезпечена явно їхня підтримка. Як правило, проектувальники бази даних самі стежили за тим, щоб у всіх таблиць були первинні ключі, однак у самих СУБД не було можливості визначити для таблиці первинний ключ. І тільки в СУБД DB2 Version 2, що з'явилася в квітні 1988 року, компанія IBM реалізувала підтримку первинних ключів. Після цього подібна підтримка була додана в стандарт ANSI/ISO.

6.3 Індекси

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

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

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

6.4 Зовнішні ключі

база реляційний запит таблиця

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

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

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

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

6.5 Реляційні відношення між таблицями

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

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

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

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

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

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

· відношення «один-до-одного» або 1:1;

· відношення «один-до-багатьох» або 1:М;

· відношення «багатьох-до-одного» або М:1;

· відношення «багатьох-до-багатьох» або М:М.

Характеристика видів зв'язку таблиць

Характеристика полів зв'язку за видами	1:1	1:М	М:1	М:М
Поле зв'язку основної таблиці	являються ключем	являються ключем	не являються ключем	не являються ключем
Поле зв'язку додаткової таблиці	являються ключем	не являються ключем	являються ключем	не являються ключем

Зв'язок виду 1:1 утворюється у випадку, коли всі поля зв'язку основної та додаткової таблиці є ключовими. Оскільки значення в ключових полях обох таблиць не повторюються, забезпечується взаємнооднозначна відповідність записів з цих таблиць, тобто таблиці є рівноправними.

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

Зв'язок 1:М має місце, коли одному запису основної таблиці відповідає декілька записів допоміжної таблиці. Розрізняють два різновиди зв'язку 1:М. У першому випадку для кожного запису головної таблиці повинні існувати запис у підлеглій. У другому - наявність записів у підлеглій таблиці необов'язкова.

Зв'язок М:1 має місце у випадку, коли одній чи декільком записам основної таблиці ставиться у відповідності один запис додаткової таблиці.

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

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

6.6 Контроль цілісності зв'язків

З перерахованих видів зв'язку найбільш широко використовується зв'язок виду 1:М. Зв'язок виду 1:1 можна вважати окремим випадком зв'язку 1:М, коли одному запису основної таблиці відповідає один запис допоміжної таблиці. Зв'язок М:1 по сутності є «дзеркальним відображенням зв'язку 1:М. Вид зв'язку М:М характеризується як слабкий вид зв'язку або навіть як відсутність зв'язку, тому далі не розглядатиметься.

Контроль цілісності зв'язків звичайно означає аналіз вмісту таблиць на дотримання таких правил:

· кожному запису основної таблиці відповідає нуль або більше записів допоміжної таблиці;

· в допоміжній таблиці немає записів, в яких немає батьківських записів в основній таблиці;

· кожний запис допоміжної таблиці має тільки один батьківський запис основної таблиці;

Опишемо дію контролю цілісності при маніпулюванні даними в таблицях. Розглянемо три основних операції над даними двох таблиць:

· введення нових записів;

· модифікацію записів;

· видалення записів.

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

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

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

Редагування полів зв'язку основної таблиці треба проводити користуючись правилами:

· Редагувати записи, які не мають підлеглих записів. Якщо є підлеглі записи, то блокувати модифікацію полів зв'язку.

· Зміни в полях зв'язку основного запису миттєво передавати у всі поля зв'язку всіх записів допоміжної таблиці (каскадне відновлення).

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

Видалення записів основної таблиці логічно підчинити одному з наступних правил:

· видаляти можна запис, який не має підлеглих записів;

· блокувати видалення записів при наявності підлеглих записів, або видаляти її разом із всіма підлеглими записами (каскадне видалення).

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

· При зміні значення поля зв'язку у головній таблиці повинен бути синхронно змінений ключ, тобто його значення.

· При знищенні записи у головній таблиці обов'язково необхідно видалити усі зв'язані записи.

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

Размещено на Allbest.ru