Зв’язок вигляду М:М

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

Приклад: Нехай в таблиці О4 міститься інформація про те, на яких верстатах можуть працювати робітники деякої бригади. Таблиця Д4 містить відомості про те, хто з бригади ремонтників які таблиці обслуговує.

Першому та третьому запису таблиці О4 відповідає перший запис таблиці Д4 (у всіх цих записів значення другого поля –“верстат1”). Четвертому запису таблиці О4 відповідає другий та четвертий запис таблиці Д4 (у другому полі цих записів міститься “верстат3”). Виходячи з визначення полів зв’язку цих таблиць можна скласти нову таблицю “О4+Д4”, записами якої будуть псевдозаписи. Записам отриманої таблиці можна надати зміст можливих змін, які складають при плануванні роботи. Для зручності, поля нової таблиці перейменовано (до речі таку операцію пропонують багато із сучасних СКБД).

Наведену таблицю можна використовувати, наприклад, для отримання відповіді на питання: “Хто обслуговує верстати, на яких працює Петров Н.Г?”.

Аналогічно зв’язку 1:1, зв’язок М:М не встановлює підлеглості таблиць. Для перевірки цього можна основну та додаткову таблицю поміняти місцями та виконати об’єднання інформації шляхом зв’язування. Результуючі таблиці «О4+Д4» та «Д4+О4» будуть відрізнятися тільки порядком розташування першого та третього полів, а також порядком розташування записів.

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

6. Поняття універсального відношення

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

При використанні універсального відношення виникає декілька проблем:

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

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

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

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

7. Нормалізація

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

Існують наступні нормальні форми:

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

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

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

8. Процедура проектування

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

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

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

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

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

5. Представити кожну властивість як поле в базовій таблиці, що представляє суть, яка безпосередньо описується цією властивістю.

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

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

8. Вказати обмеження цілісності проектованої бази даних і дати (якщо це необхідно) короткий опис отриманих таблиць і їх полів.

9. Засоби розробки та виконання додатків

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

• Ручне кодування програм (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, де допускаються розроблені екранні форми і звіти перетворювати у відповідні об’єкти, що не піддаються редагуванню.

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

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

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

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

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

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

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

Дата добавления: 2014-12-25