5.5. Зв’язок вигляду м:м
Загальний вигляд зв’язку М:М виникає у випадках, коли декільком записам основної таблиці відповідає декілька записів додаткової таблиці.
Приклад : Нехай в таблиці О4 міститься інформація про те, на яких верстатах можуть працювати робітники деякої бригади. Таблиця Д4 містить відомості про те, хто з бригади ремонтників які таблиці обслуговує.
Першому та третьому запису таблиці О4 відповідає перший запис таблиці Д4 (у всіх цих записів значення другого поля –“верстат1”). Четвертому запису таблиці О4 відповідає другий та четвертий запис таблиці Д4 (у другому полі цих записів міститься “верстат3”). Виходячи з визначення полів зв’язку цих таблиць можна скласти нову таблицю “О4+Д4”, записами якої будуть псевдозаписи. Записам отриманої таблиці можна надати зміст можливих змін, які складають при плануванні роботи. Для зручності, поля нової таблиці перейменовано (до речі таку операцію пропонують багато із сучасних СКБД).
Наведену таблицю можна використовувати, наприклад, для отримання відповіді на питання: “Хто обслуговує верстати, на яких працює Петров Н.Г?”.
Аналогічно зв’язку 1:1, зв’язок М:М не встановлює підлеглості таблиць. Для перевірки цього можна основну та додаткову таблицю поміняти місцями та виконати об’єднання інформації шляхом зв’язування. Результуючі таблиці «О4+Д4» та «Д4+О4» будуть відрізнятися тільки порядком розташування першого та третього полів, а також порядком розташування записів.
На практиці, зв’язок звичайно встановлюється зразу між кількома таблицями. При цьому одна з таблиць може мати різноманітні зв’язки з іншими таблицями. У випадках, коли зв’язані таблиці, в свою чергу, мають зв’язки з іншими таблицями, утворюється ієрархія та дерево зв’язків.
Поняття універсального відношення
Припустимо, що проектування бази даних починається з виявлення атрибутів і підбору даних.
При використанні універсального відношення виникає декілька проблем:
Надмірність. Дані практично всіх стовпців багато разів повторюються. Повторюються і деякі набори даних. І вже зовсім погано, якщо всі дані про запис повторюються кожного разу, коли запис включається до іншої таблиці.
Потенційна суперечність (аномалії оновлення). Унаслідок надмірності можна відновити адресу постачальника в одному рядку, залишаючи його незмінним в інших. Отже, при оновленнях необхідно проглядати всю таблицю для знаходження і зміни всіх відповідних рядків.
Аномалії включення. У БД не може бути записаний новий рядок, якщо його відношення не зустрічалось раніше. Але якщо такий, в якому використовується цей запис, чи не забудемо ми видалити рядок з невизначеними значеннями?
Аномалії видалення. Зворотна проблема виникає при необхідності видалення всіх записів, що використовуються іншими таблицями. При таких видаленнях будуть втрачені відомості про запис.
Нормалізація
Нормалізація - це розбиття таблиці на дві або більш, що володіють кращими властивостями при включенні, зміні і видаленні даних. Остаточна мета нормалізації зводиться до отримання такого проекту бази даних, в якому кожен факт з'являється лише в одному місці, тобто виключена надмірність інформації. Це робиться не стільки з метою економії пам'яті, скільки для виключення можливої суперечності даних, що зберігаються.
Існують наступні нормальні форми:
Таблиця знаходиться в першій нормальній формі (1нф) тоді і тільки тоді, коли жодна з її рядків не містить в будь-якому своєму полі більш за одне значення і жодне з її ключових полів не порожньо.
Таблиця знаходиться в другій нормальній формі (2нф), якщо вона задовольняє визначенню 1нф і всі її поля, що не входять в первинний ключ, зв'язані повною функціональною залежністю з первинним ключем.
Таблиця знаходиться в третій нормальній формі (3нф), якщо вона задовольняє визначенню 2нф і не одне з її не ключових полів не залежить функціонально від будь-якого іншого не ключового поля.
Процедура проектування
Процес проектування інформаційних систем є достатньо складним завданням. Він починається з побудови інфологічної моделі даних, тобто ідентифікації суті. Потім необхідно виконати наступні кроки процедури проектування:
Представити кожен стрижень (незалежну суть) таблицею бази даних (базовою таблицею) і специфікувати первинний ключ цієї базової таблиці.
Представити кожну асоціацію (зв'язок виду "многие-ко-многим" або "многие-ко-многим-ко-многим" і так далі між суттю) як базову таблицю. Використовувати в цій таблиці зовнішні ключі для ідентифікації учасників асоціації і специфікувати обмеження, пов'язані з кожним з цих зовнішніх ключів.
Представити кожну характеристику як базову таблицю із зовнішнім ключем, що ідентифікує суть, що описується цією характеристикою. Специфікувати обмеження на зовнішній ключ цієї таблиці і її первинний ключ - ймовірно, комбінації цього зовнішнього ключа і властивості, яка гарантує "унікальність в рамках описуваної суті".
Представити кожне позначення, яке не розглядалося в попередньому пункті, як базову таблицю із зовнішнім ключем, що ідентифікує суть, що позначається. Специфікувати пов'язані з кожним таким зовнішнім ключем обмеження.
Представити кожну властивість як поле в базовій таблиці, що представляє суть, яка безпосередньо описується цією властивістю.
Для того, щоб виключити в проекті ненавмисні порушення яких-небудь принципів нормалізації, виконати процедуру нормалізації.
Якщо в процесі нормалізації було проведено розділення яких-небудь таблиць, то слід модифікувати інфологічну модель бази даних і повторити перераховані кроки.
Вказати обмеження цілісності проектованої бази даних і дати (якщо це необхідно) короткий опис отриманих таблиць і їх полів.
Засоби розробки та виконання додатків
Існуючі СКБД підтримують наступні технології розробки додатків:
• Ручне кодування програм (Clipper, FoxPro, Paradox) – програмісти вручну складають тексти програм-додатків та відлагоджують їх;
• Створювання текстів додатків за допомогою генераторів ( FoxApp в FoxPro, Personal Programmer в Paradox);
• Автоматична генерація готового додатку методами візуального програмування (Delphi, Access, Paradox for Windows).
При ручному кодуванні програмісти вручну набирають текст програми додатків, після чого виконують їх налагодження.
Використання генераторів спрощує розробку додатків, оскільки при цьому можна отримати програмний код без ручного набору. Генератори додатків полегшують розробку основних елементів додатків (меню, екранних форм, запитів і т.д.), але найчастіше не можуть повністю виключити ручне кодування.
Засоби візуального програмування додатків являються подальшим розвитком ідей використання генераторів додатків. Додаток при цьому складається з готових “будівних блоків” за допомогою зручного інтегрованого середовища. При необхідності розробник легко може вставити в додаток свій код. Інтегроване середовище, як правило, представляє потужні засоби створення, наладки і модифікації додатків. Використання засобів візуального програмування дозволяє у найкоротші строки створювати більш надійні, привабливі и ефективні додатки у порівнянні з додатками, отриманими першими двома способами.
Розроблений додаток звичайно складається з одного чи декількох файлів операційної системи.
Якщо основним файлом додатку є виконуємий файл (наприклад, exe-файл), то цей додаток, скоріш за все, є незалежним додатком, котрий виконується автономно від середи СКБД. Отримання незалежного додатку на практиці здійснюється шляхом компіляції вихідних текстів програм, отриманих різними способами: шляхом набору тексту вручну, а також отриманих за допомогою генератора додатка чи середовища візуального програмування.
Незалежні додатки дозволяють отримувати, наприклад, СКБД FoxPro і система візуального програмування Delphi.
В багатьох випадках додаток не може виконуватися без середовища СКБД. Виконання додатка складається з того, що СКБД аналізує вміст файлів додатка (в приватному випадку – це текст вихідної програми) і автоматично будує необхідні здійснювані машинні команди. Іншими словами, додаток виконується методом інтерпретації.
Режим інтерпретації реалізується в багатьох сучасних СКБД, наприклад Access, Visual FoxPro та Paradox, а також у СКБД недавнього минулого, як приклад FoxBase і FoxPro.
Крім того, існують системи, що використовують проміжний варіант між компіляцією та інтерпретацією – так звану псевдокомпіляцію. У таких системах вихідна програма шляхом компіляції перетворюється у проміжний код (псевдокод) і записується на диск. В цьому вигляді її в деяких системах дозволяється навіть редагувати, але головна мета псевдокомпіляції – перетворити програму до виду, що прискорює процес її інтерпретації. Такий прийом широко застосовувався у СКБД, працюючих під управлінням DOS, наприклад Foxbase+ та Paradox 4.0/4.5 for DOS.
У СКБД, працюючих під керуванням Windows, псевдокод частіше використовують для того, щоб заборонити модифікувати додаток. Це корисно для захисту від випадкового чи навмисного псування працюючої програми. Наприклад, такий прийом застосовано у СКБД Paradox for Windows, де допускаються розроблені екранні форми і звіти перетворювати у відповідні об’єкти, що не піддаються редагуванню.
Деякі СКБД надають користувачу можливість вибору варіанта розробки додатка: як інтерпретуємого СКБД програмного коду чи як незалежної програми.
Перевагою застосування незалежних додатків є те, що час виконання машинної програми, зазвичай, менший, ніж при інтерпретації. Такі додатки доцільно використовувати на слабких машинах і у випадку установки систем “під ключ”, коли необхідно закрити додаток від доробок зі сторони користувача.
Важливою перевагою застосування інтерпретуємих додатків є легкість їх модифікації. Якщо готова програма піддається частим змінам, то для їх внесення потрібна інструментальна система, тобто СКБД чи аналогічне середовище. Для інтерпретуємих додатків такий інструмент завжди під рукою, що дуже зручно.
Іншою серйозною перевагою систем з інтерпретацією є те, що прогресивні СКБД, зазвичай, мають потужні засоби контролю цілісності даних та захисту від несанкціонованого доступу, чого не скажеш про системи компілюючого типу, в яких ці функції доводиться програмувати вручну або залишати на совісті адміністраторів.
При виборі засобів для розробки додатка потрібно враховувати три основних фактори: ресурси комп’ютера, особливості додатка (потреба у модифікації функцій програми, час на розробку, необхідність контролю доступу і підтримання цілісності інформації) і мета розробки (відчужуваний програмний продукт або система автоматизації своєї повсякденної діяльності).
Для користувача, що має сучасний комп’ютер і плануючого створити нескладний додаток, скоріш за все, більш підійде СКБД інтерпретуючого типу.
При використані комп’ютера зі слабкими характеристиками краще зупинити свій вибір на системі зі засобами розробки незалежних додатків. При цьому треба мати на увазі, що найменша зміна у додатку тягне за собою циклічне повторення етапів програмування, компіляції і наладки програми. Різниця у виконані незалежного додатку і виконані додатка у режимі інтерпретації коливається в межах мілісекунд на користь незалежного додатка. У той же час різниця у часі підготовки додатка до його використання звичайно складає величини порядку хвилини – години на користь систем з інтерпретацією.
Схема обміну даними при роботі з БД
Користувачу будь-якої категорії (адміністратору БД, розробнику додатків, звичайному користувачу), для грамотного вирішення задач корисно уявляти обчислювальний процес, який проходить в ОС при роботі з БД.
При роботі користувача з БД над її вмістом виконуються такі основні операції: вибір, додавання, модифікація (заміна) та видалення даних. Розглянемо як відбувається обмін даними між окремим користувачем та персональною СКБД при виконанні операції вибірки даних.
Цикл взаємодії користувача з БД за допомогою додатку можна розділити на такі основні етапи:
Користувач термінала (1) в процесі діалогу з додатком формулює запит (2) на деякі дані з БД.
Додаток (3) на програмному рівні засобами мови маніпулювання даними формулює запит (4), з яким звертається до СКБД.
Використовуючи свої системні керуючі блоки, СКБД за допомогою словника даних, визначає місцезнаходження вимагаємих даних та звертається за ними к ОС.
Програми методів доступу файлової системи ОС зчитують (6) із зовнішньої пам’яті шукані дані та вміщають їх в системні буфери СКБД.
Перетворюючі отримані дані в необхідний формат, СКБД пересилає їх (7) у відповідну область програми і сигналізує (8) про завершення операції якимсь чином, наприклад кодом повернення.
Результати вибору даних з бази додаток (3) відображає (9) на терміналі користувача (1).
У випадку роботи користувача в діалоговому режимі із СКБД (без додатку) цикл взаємодії користувача з БД спрощується.
Користувач термінала (10) формулює на мові запитів СКБД по зв’язку (11) запит на вибір деяких даних з бази.
СКБД визначає місцезнаходження потрібних даних і звертається (5) за ними до ОС, яка зчитує (6) їх із зовнішньої пам’яті шукані дані та вміщує їх в системні буфери СКБД.
Інформація із системних буферів перетворюється (12) у потрібний формат після чого відображується (13) на терміналі користувача (10).
Рисунок 19.1 – Схема обміну даних при роботі БД
Якщо комп’ютер та ОС підтримують багатокористувацький режим роботи, то в такій системі може функціонувати багатокористувацька СКБД, яка в загальному випадку дозволяє одночасно обслуговувати кількох користувачів, працюючих безпосередньо із СКБД або з додатками.
Іноді до обчислювальної системи підключається так званий “віддалений користувач”, що знаходиться на деякій відстані від ЕОМ та з’єднаний з нею за допомогою якого-небудь передаючого середовища (телефонний канал, радіоканал та ін). Найчастіше такий користувач емулюється під звичайного локального користувача. Як правило, СКБД “не помічає” підміни та обслуговує запити як звичайно.
При обслуговуванні кількох паралельних джерел запитів (від користувачів та додатків) СКБД планує використання своїх ресурсів ЕОМ таким чином, щоб забезпечити незалежне або майже незалежне виконання операцій, породжуваних запитами. Багатокористувацькі СКБД часто використовуються на великих та середніх ЕОМ, де основним режимом використання ресурсів є колективний доступ. На ПЕОМ користувач звичайно працює один, але з різними програмами, в тому числі поперемінно. Іноді такими програмами виявляються СКБД, різні програми або різні копії однієї й тієї ж СКБД.
Технологію одночасної роботи користувача з декількома програмами непогано реалізовано в Windows. При роботі в Windows СКБД не має необхідності підтримувати декілька сеансів роботи з користувачами.
Контроль цілісності зв’язків
З усіх видів зв’язку найбільш широко використовується зв’язок виду 1:М. Зв’язок виду 1:1 можна вважати окремим випадком зв’язку 1:М, коли одному запису основної таблиці відповідає один запис допоміжної таблиці. Зв’язок М:1 по сутності є «дзеркальним відображенням зв’язку 1:М. Виз зв’язку М:М характеризується як слабкий вид зв’язку або навіть як відсутність зв’язку, тому далі не розглядатиметься.
Контроль цілісності зв’язків звичайно означає аналіз вмісту таблиць на дотримання таких правил:
Кожному запису основної таблиці відповідає нуль або більше записів допоміжної таблиці;
В допоміжній таблиці немає записів, в яких немає батьківських записів в основній таблиці;
Кожний запис допоміжної таблиці має тільки один батьківський запис основної таблиці;
Опишемо дію контролю цілісності при маніпулюванні даними в таблицях. Розглянемо три основних операції над даними двох таблиць:
Введення нових записів;
Модифікацію записів;
Видалення записів.
При введенні нових записів виникає питання визначення послідовності введення записів в таблицю, такої, щоб не допустити порушень цілісності. Виходячи з наведених правил, логічною є ситуація, при якій дані спочатку вводяться в основну таблицю, а потім – в допоміжну. Черговість введення може бути встановлено на рівні цілих таблиць, а потім – в додаткову. Черговість вводу може бути встановлено на рівні таблиць та окремих записів ( випадок одночасного введення у декілька відкритих таблиць).
В процесі заповнення основної таблиці контроль значень полів зв’язку ведеться як контроль звичайного ключа (на співпадання із значеннями тих же полів інших записів). Заповнення полів зв’язку допоміжної таблиці контролюється на предмет співпадання із значеннями полів зв’язку основної таблиці. Якщо введене значення в полі зв’язку допоміжної таблиці не співпадає ні з одним відповідним значенням в записах основної таблиці, то такий запис повинен блокуватися.
Модифікація записів. Зміна змісту полів зв’язаних записів, що не відносяться до полів зв’язку, очевидно, повинно відбуватись звичайним чином. При редагуванні полів зв’язку допоміжної таблиці очевидною вимогою є те, щоб нове значення поля зв’язку співпадало із відповідним значенням якого-небудь запису основної таблиці, тобто допоміжний запис може змінити батька, але не повинен залишитись без нього.
Редагування полів зв’язку основної таблиці треба проводити користуючись правилами:
Редагувати записи, які не мають підлеглих записів. Якщо є підлеглі записи, то блокувати модифікацію полів зв’язку.
Зміни в полях зв’язку основного запису миттєво передавати у всі поля зв’язку всіх записів допоміжної таблиці (каскадне відновлення).
В операціях видалення записів зв’язаних таблиць безсумнівно більшу свободу, мають записи допоміжної таблиці. Видалення їх може провадитись практично безконтрольно.
Видалення записів основної таблиці логічно підчинити одному з наступних правил:
Видаляти можна запис, який не має підлеглих записів;
Блокувати видалення записів при наявності підлеглих записів, або видаляти її разом із всіма підлеглими записами (каскадне видалення).