Розробка програми запитів

Курсова робота

Одеса 2010

Зміст

Введення

1 Аналіз існуючих рішень

1.1 Операції реляційної алгебри

1.2 Оптимізація запитів

1.3 Діаграма запиту

1.4 Створення діаграми запиту

1.5 Програми побудови плану виконання запиту

1.6 Висновки

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

2.1 Підстава для розробки

2.2 Призначення розробки

2.3 Вимоги до програми

2.4 Вимоги до програмної документації

2.5 Стадії та етапи розробки

2.6 Порядок контролю та приймання

3 Проектування програми навчання реляційної алгебри

3.1 Аналіз предметної області

3.2 Структура даних

Список літератури

Введення

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

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

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

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

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

Іноді при аналізі проблеми настроювання SQL виявляються симптоми, які вказують на невеликі функціональні помилки, супутні помилок продуктивності.

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

Налаштування SQL складається з трьох основних етапів:

1) зрозуміти, який план виконання (шлях до даних, запитуваною вашим оператором) є;

2) змінити SQL чи базу даних, щоб отримати обраний план виконання;

3) вибрати оптимальний план виконання.

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

У першому розділі наведено опис операцій реляційної алгебри. Представлено принципи оптимізації запитів. Описано подання запиту у вигляді діаграми. А також наведений опис графічних середовищ для перегляду плану виконання запиту.

У другому розділі описано призначення розробленої програми, представлені її основні функції.

1 Аналіз існуючих рішень

На початку 70-х років двадцятого століття Кодд опублікував дві статті, в яких ввів реляційну модель даних (РМД) і реляційні мови обробки даних.

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

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

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

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

1.1 Операції реляційної алгебри

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

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

Реляційні оператори об'єднання, перетину і взяття різниці вимагають, щоб відносини мали однакові заголовки. Справді, відносини складаються із заголовка і тіла. Операція об'єднання двох відносин є просто об'єднання двох множин кортежів, взятих з тіл відповідних відносин [1].

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

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

Оператор присвоювання (: =) дозволяє зберегти результат обчислення реляційного вираження в існуючому відношенні.

Відношення з тим же заголовком, що і у сумісних по типу відносин A і B, і тілом, що складається з кортежів, що належать або A, або B, або обом відносин, називається об'єднанням відносин A і B.

Синтаксис:

AUB

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

Синтаксис:

A ∩ B

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

Синтаксис:

A - B

Відношення (A1, A2, ..., Am, B1, B2, ..., Bm), заголовок якого є зчепленням заголовків відносин A (A1, A2, ..., Am) і B (B1, B2, ..., Bm), а тіло складається з кортежів, які є зчепленням кортежів відношень A і B:

(A1, a2, ..., am, b1, b2, ..., bm)

таких, що (a1, a2, ..., am) Î A, (b1, b2, ..., bm) Î B,

називається декартовим твором відносин А і В.

Синтаксис:

A 'B

Відношення з тим же заголовком, що і у відносини A, і тілом, що складається з кортежів, значення атрибутів яких при підстановці в умову C дають значення ІСТИНА, називається вибіркою. С являє собою логічне вираження, у яку можуть входити атрибути відношення A і / або скалярні вирази.

Синтаксис:

s (A, C)

Відношення з заголовком (X, Y, ..., Z) і тілом, що містить безліч кортежів виду (x, y, ..., z), таких, для яких щодо A знайдуться кортежі із значенням атрибута X рівним x, значенням атрибута Y рівним y , ..., значенням атрибута Z рівним z, називається проекцій відносини А. При виконанні проекції виділяється «вертикальна» вирізка відносини-операнда з природним знищенням потенційно виникаючих кортежів-дублікатів.

Синтаксис:

A [X, Y, ..., Z]

або

p _A {x, y, ..., z}

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

Синтаксис:

s ((A 'B), C)

Важливими з практичної точки зору окремими випадками сполуки є еквісоедіненіе і природне з'єднання.

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

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

Результатом операції природного з'єднання є відношення R, яке являє собою проекцію еквісоедіненія відносин R1 і R2 по загальному атрибуту на об'єднану сукупність атрибутів обох відносин.

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

Відношення з заголовком (X1, X2, ..., Xn) і тілом, що містить безліч кортежів (x1, x2, ..., xn), таких, що для всіх кортежів (y1, y2, ..., ym) Î B відносно A (X1 , X2, ..., Xn, Y1, Y2, ..., Ym) знайдеться кортеж (x1, x2, ..., xn, y1, y2, ..., ym), називається поділом відносин.

Синтаксис:

A / B

1.2 Оптимізація запитів

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

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

Оптимізатор за правилами (rule-based) - оптимізатор, заснований на аналізі жорстко заданих правил. Цей оптимізатор вибирає методи доступу на основі припущення про статичності бази даних і, відповідно до вказаної системою правил вибору методів доступу.

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

Під методом доступу (access path) мається на увазі варіант алгоритму доступу, а під планом виконання (execution plan) - послідовність виконуваних дій, які забезпечують обрані методи доступу. Існує два основних види оптимізаторів:

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

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

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

По-перше, при необхідності доступу до значної частини рядків будь-якої таблиці повне сканування (full scan) є більш ефективним, ніж використання індексів. Кордон застосування даних методів доступу в загальному випадку становить 5-10% записів таблиці, до яких звертається запит. Справа в тому, що для сканування індексу і вилучення рядка потрібні, принаймні, дві операції читання для кожного рядка (одна - для читання індексу, інша для читання даних з таблиці). А при повному скануванні таблиці для вилучення рядка потрібно тільки одна операція читання. При доступі до великої кількості рядків стає очевидною неефективність використання індексу в порівнянні з повним скануванням таблиці, при якому рядки зчитуються безпосередньо з таблиці. Для невеликих таблиць повне сканування практично завжди виявляється ефективніше використання індексу.

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

По-третє, при використанні різних видів підзапитів на основі знань про дані слід враховувати особливості обчислення спеціальних предикатів та застосування операторів теоретико-множинних операцій. Наприклад, оператор MINUS може виконуватися набагато швидше, ніж запити з WHERE NOT IN (SELECT) або WHERE NOT EXISTS.

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

1.3 Діаграма запиту

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

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

SELECT D. DepartmentJIame. E. LastJIame. E. Firstjlame FROM Employees E. Departments 0 WHERE E. Department_Id = D. Departmentjd

AND E. Exempt_Flag = 'Y'

AND D. US_Based_Flag = 'Y';

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

Вузли

Вузли представляють таблиці або псевдоніми таблиць в розділі FROM - у прикладі це псевдоніми Е і D. Для зручності можна скорочувати назви таблиць або псевдонімів, якщо це не викликає двозначності чи непорозуміння.

Зв'язки

Зв'язки представляють з'єднання між таблицями, а спрямована зв'язок позначає, що з'єднання гарантовано отримає унікальні значення в тій таблиці, на яку вказує зв'язок. У даному випадку DepartmentId - первинний (унікальний) ключ в таблиці Departments, тому у зв'язку є стрілка на кінці, що вказує на вузол D. Так як Departments не унікальний в таблиці Employees, на іншому кінці зв'язку стрілки немає. Хоча ви можете здогадатися, що DepartmentId - це первинний ключ для Departments, SQL не оголошує явно, яка сторона сполуки є первинним ключем, а яка - зовнішнім. Необхідно перевірити індекси або оголошені ключі, щоб упевнитися, що Departments гарантовано унікальним в таблиці Departments.

Підкреслені числа

Підкреслені числа поруч з вузлами позначають частку рядків кожної таблиці, які відповідають умовам фільтрації для цієї таблиці. Тут під умовами розуміються не умови з'єднання, а умови, що відносяться тільки до конкретної таблиці на діаграмі SQL. На рис. 1.X 10% рядків таблиці Employees задовольняють умові Exempt_Flag = 'Y', і 50% рядків таблиці Departments задовольняють умові US_Based_Flag = 'Y'. Ці частки називаються коефіцієнтами фільтрації.

Часто для однієї або декількох таблиць взагалі не вказані умови фільтрації. У цьому випадку для коефіцієнта фільтрації (К) використовується значення 1,0, так як 100% рядків задовольняють (неіснуючим) умовам фільтрації для цієї таблиці. У подібних випадках зазвичай взагалі не вказуються коефіцієнти фільтрації на діаграмі. Відсутність цього числа позначає К = 1,0 для даної таблиці. Коефіцієнт фільтрації не може бути більше 1,0. Найчастіше можна приблизно вгадати значення коефіцієнтів фільтрації, знаючи, що представляють таблиці і стовпчики. Якщо доступні розподілу реальних даних, можна знайти точні значення коефіцієнтів фільтрації, просто отримавши та проаналізувавши ці дані. Необхідно розглядати кожну фільтровану таблицю з операторами фільтрації, що належать лише до цієї таблиці, як однотаблічний запит, і шукати селективність умов фільтрів.

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

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

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

Детальні коефіцієнти сполуки можуть бути рівні будь-якого невід'ємного числа. Вони можуть бути менше 1,0, так як деякі відносини головною і детальної таблиць дозволяють існування нуля, однієї або багатьох детальних рядків, причому найчастіше зустрічається випадок «один до нуля». У прикладі для середньої рядка Employees є відповідний рядок (з якою вона пов'язана) в Departments в 98% випадків, тоді як середня рядок Departments відповідає (зв'язується з) 20 рядках Employees. Потрібно по можливості отримувати ці значення з повних, реальних розподілів даних. Так само, як і з коефіцієнтами фільтрації, може знадобитися обчислення коефіцієнтів з'єднання під час фази розробки програми.

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

У діаграмі відсутні будь-які вказівки на сортування (ORDER BY), угруповання (GROUP BY) і фільтрацію після угруповання (HAVING). Ці операції практично ніколи не мають великого значення для продуктивності запиту. Крок сортування, який вони зазвичай мають, може впливати на швидкість виконання, але для зміни його вартості мало що можна зробити, і ця вартість зазвичай не така велика в порівнянні з продуктивністю погано виконується запиту.

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

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

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

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

1.4 Створення діаграми запиту

Нижче перераховані правила створення повної діаграми запиту.

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

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

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

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

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

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

Приклад.

Є запит

SELECT C. Phone_Number, C. Honorific, C. First_Name, C. Last_Name,

C. Suffix, C. AddressJD, A. AddressJD, A. Street_Address_Linel,

A.Street_Address_Line2, A. City_Name, A. State_Abbreviation, A. ZIP_Code,

DD.Deferred_Shipment_Date, OD.Item_Count. DOT.Text, OT.Text,

P. Product_Description, S. Shipment_Date

FROM Orders O, Orderjtetails OD, Products P, Customers C, Shipments S,

Addresses A, Code_Translations DOT, Code_Translations OT

WHERE UPPER (C. Last_Name) LIKE: Last_Name ||'%'

AND UPPER (C. First_Name) LIKE: First_Name ||'%'

AND OD.OrderID = O. Order_ID

AND O. CustomerID = C. Customer_ID

AND OD.Product_ID = P. Product_ID (+)

AND OD.Shipment_ID = S. Shipment_ID (+)

AND S. Address_ID = A. Address_ID (+)

AND O. Status_Code = OT.Code

AND DT.CodeJype = 'ORDER_STATUS'

AND OD.Status_Code = ODT.Code

AND CDT.CodeJype = 'ORDERJIETAILJTATUS

AND O. Order_Date>: Now - 366

ORDER BY C. CustomerID, O. Drder_ID DESC, S. ShipmentID, DD.Order_Detail_ID;

Побудована за перерахованим вище правилам для даного запиту діаграма показана на рис.1.2.

Безліч подробиць, присутніх на повних діаграмах запитів, не обов'язкові, тільки для самих рідкісних проблем. Для концентрації на необхідних елементах потрібен тільки скелет діаграми і приблизні коефіцієнти фільтрації. Зрідка потрібні коефіцієнти сполук, але зазвичай лише коли кожен із детальних коефіцієнтів з'єднання менше 1,5 або головний коефіцієнт з'єднання менше 0,9. Це, у свою чергу, означає, що менша кількість даних вимагає створення більш простих діаграм з'єднання. Немає необхідності дізнаватися кількість рядків для таблиць без фільтрів. На практиці в багатосторонніх з'єднаннях зазвичай є фільтри тільки для 3-5 таблиць, тому навіть самий складний запит легко зобразити на діаграмі, не використовуючи безліч запитів для збору статистики.

Відкинувши перераховані деталі, можна спростити рис. 1.1 до рис.1.3.

1.5 Програми побудови плану виконання запиту

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

План виконання запиту для MS SQL Server найпростіше проглянути з SQL Server Management Studio [2] /

Для того щоб отримати інформацію про очікуване плані виконання запиту, можна в меню Query (Запит) вибрати команду Display Estimated Execution Plan (Відобразити очікуваний план виконання). Якщо потрібно дізнатися реальний план виконання запиту, можна перед його виконанням встановити в тому ж меню параметр Include Actual Execution Plan (Активізувати реальний план виконання). У цьому випадку після виконання запиту у вікні результатів у SQL Server Management Studio з'явиться ще одна вкладка Execution Plan (План виконання), на якій буде представлений реальний план виконання запиту. При наведенні покажчика миші на будь-який з етапів можна отримати про нього додаткову інформацію (рис. 1.4).

Ще одне інтерактивне графічне засіб, який дозволяє адміністратору бази даних або розробнику писати запити, виконувати різні запити одночасно, переглядати результати, аналізувати план запитів та отримувати підтримку для покращення плану виконання - SQL Query Analyzer. Опція перегляду плану виконання графічно показує методи отримання даних, що використовуються оптимізатором запиту Microsoft SQL Server. У графічному виконанні плану використовуються іконки для представлення специфічних дій і запитів у SQL Server, а не зображення у вигляді таблиць, створених інструкціями SET SNOWPLAN_ALL або SET SNOWPLAN_TEXT. Це дуже корисно для розуміння швидкісних показників запиту. Крім того, SQL Query Analyzer показує поради з додатковим індексам і статистичними даними в неіндексіруемих колонках, що поліпшить можливості оптимізатора запиту раціонально обробити запит. Зокрема, SQL Query Analyzer показує які статистичні дані пропущені, тим самим, змушуючи оптимізатор запиту давати оцінку по селективності, а потім дає можливість створити пропущені статистичні дані.

Іконки, зображені в графічному плані виконання, представляють фізичні оператори, які використовуються MS SQL Server для виконання запиту.

Приклад

Запит

SELECT DISTINCT t.date AS c0,

c.prefijoext AS c1,

c.numeroext AS c2,

c.checkbook AS c3

FROM Transac t (nolock)

JOIN cmpasociados c (nolock)

ON t.nrotrans = c.nrotrans

JOIN tiposcmp you (nolock)

ON c.codcmp = you.codcmp

JOIN checkbooks so (nolock)

ON c.checkbook = so.checkbook

AND t.codemp = so.codemp

WHERE T. Nrotranselim is null

AND

(

CASE

WHEN T. Codcmp

IN (

'CA', 'CC', 'CB', 'CE'

, 'LR', 'LO', 'LP', 'CZ'

, 'VA', 'VB', 'VC', 'YOU'

, 'VZ'

)

THEN T. Nrotransaut

WHEN T. Codcmp

IN ('I', 'E', 'RD')

THEN T. Nrotransctrl

ELSE T. Nrotrans END

)

IS NOT NULL

AND (t.CodEmp IS NULL OR t.codemp = 1)

AND c.checkbook = 25

AND t.codsuc = 1

ORDER BY C2 DESC

мав такий план виконання в Query Analyzer (див. рис.1.5).

Після застосування індексів, вийшов план виконання, показаний на рис.1.6.

1.6 Висновки

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

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

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

• вивчити особливості роботи всіх реляційних операцій;

• розробити структуру даних для зберігання необхідної інформації;

• розробити алгоритми перетворення послідовності реляційних операцій в запит до СУБД для представлення результату виконання процедурного плану;

• розробити зручний інтерфейс для формування процедурного плану запиту;

• розробити навчальний і контролюючий компоненти програми.

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

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

2.1 Підстава для розробки

Підставою для розробки програми «Навчальна програма побудови запитів у процедурному вигляді» є завдання на дипломне проектування.

2.2 Призначення розробки

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

2.3 Вимоги до програми

Програма «Навчальна програма побудови запитів у процедурному вигляді» повинна забезпечувати автоматизацію наступних функцій:

1) формування питань для учнів;

а) зв'язок з внутрішньої БД програми;

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

в) запис тексту запиту;

г) доступ до метаданих навчальної БД;

д) підключення схеми даних навчальної БД у вигляді графічного файлу;

е) формування безлічі операцій відповіді на запит;

ж) формування різних вірних послідовностей операцій;

2) прийом відповіді від учня;

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

б) формування списку таблиць навчальної БД;

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

г) визначення списку стовпців заданої таблиці;

д) підключення операндів обраної операції;

е) зміна послідовності введених операцій;

ж) порівняння введеного відповіді з еталонним безліччю послідовностей операцій;

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

3) навчальна частина;

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

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

в) перегляд правильної відповіді;

4) контролює частину;

а) формування опитувальника з наявних у внутрішній БД запитів;

б) виставлення балів за відповідь;

в) формування підсумкової оцінки;

г) збереження результатів тесту;

д) збереження введених відповідей.

5) робота зі звітами;

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

б) друк списку запитань і списку відповідей.

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

Вхідними даними повинні бути:

інформація для з'єднання з навчальної БД;

структура таблиць навчальної БД;

з'єднання з внутрішньої БД.

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

Вихідними даними є:

а) безліч питань у вигляді тексту запиту до навчальної БД;

б) безліч послідовностей операцій для реалізації запитів;

в) послідовності операцій для реалізації запитів до навчальної БД, введені користувачем;

7) оцінки за введені відповіді при використанні програми у контролюючому режимі.

Вихідні дані повинні роздруковуватися на принтері, зберігатися у вигляді файлу та / або записів БД програми і відображатися на екрані монітора.

Надійність і стійкість функціонування програми повинні забезпечуватися:

- Продуманою технологією обробки інформації;

- Контролем правильності введення вхідної інформації;

- Системою діагностичних повідомлень;

- Мінімізацією операцій, здійснюваних користувачем;

- Дотриманням вимог експлуатаційної документації.

При функціонуванні програми «Навчальна програма побудови запитів у процедурному вигляді» повинно забезпечуватися:

- Вирішення задачі за прийнятний час;

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

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

Програма «Навчальна програма побудови запитів у процедурному вигляді» вимагає для свого функціонування комп'ютер типу IBM PC під управлінням операційної системи Windows 2000 і вище.

Мінімальний склад технічних засобів:

• процесор з оперативним запам'ятовуючим пристроєм ємністю не менше 512 Мб;

• накопичувач на магнітних дисках типу «вінчестер» місткістю не менше 30 Гб;

• CD-ROM для читання інформації з компакт-диска;

• монітор;

• принтер.

Програма «Навчальна програма побудови запитів у процедурному вигляді» реалізована у вигляді файлу, і безлічі БД (внутрішня і навчальні).

Мова програмування - Visual Basic 6.0.

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

Контрольний приклад повинен забезпечувати перевірку правильності і працездатності функцій програми «Навчальна програма побудови запитів у процедурному вигляді», забезпечувати перевірку працездатності програми в різних ситуаціях.

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

2.4 Вимоги до програмної документації

Склад програмної документації програми «Навчальна програма побудови запитів у процедурному вигляді» повинен бути наступним:

• опис програми;

• керівництво користувача;

• функціональний опис.

Склад документів може уточнюватися в процесі розробки.

2.5 Стадії та етапи розробки

Стадії та етапи розробки, зміст робіт та терміни виконання наведені в таблиці 2.1.

2.6 Порядок контролю та приймання

У процесі розробки програми «Навчальна програма побудови запитів у процедурному вигляді» повинні проводитися: 1) проектування та налагодження програми; 2) попередні випробування, 3) досвідчена експлуатація; 4) введення в дію.

Попередні випробування повинні проводитися розробником в лабораторіях кафедри системного програмного забезпечення Одеського національного політехнічного університету.

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

Тривалість дослідної експлуатації становить 2 тижні.

Таблиця 2.1 Стадії та етапи розробки

3 Проектування програми навчання реляційної алгебри

3.1 Аналіз предметної області

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

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

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

Об'єднанням двох сумісних таблиць R1 і R2 називається таблиця R, що складається з усіх рядків, що належать хоча б одній з таблиць R1, R2.

Перетином двох сумісних таблиць R1 і R2 називається таблиця R, що складається з усіх рядків, які є загальними для таблиць R1, R2.

Різницею двох сумісних таблиць R1 і R2 називається таблиця R, що складається тільки з тих рядків таблиці R1, які відсутні в таблиці R2.

Декартовим твором двох таблиць R1 і R2 (необов'язково сумісних) називається таблиця R, що складається з усіх таких рядків, кожна з яких є конкатенація двох рядків, по одній з таблиць R1 і R2, причому на першому місці має бути рядок з R1.

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

Вибірка - це операція реляційної алгебри, що виробляє відбір рядків з таблиці на підставі деякої умови.

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

Проекція - реляційна таблиця, отримана в результаті створення проекцій.

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

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

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

JOIN (A, B: X d Y), де d позначає операцію порівняння.

Якщо використовується операція «=», то з'єднання також називається еквісоедіненіем.

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

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

Програма може працювати в двох режимах: навчальні та контролюючі.

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

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

Відповідь на питання має вводитись у вигляді послідовності операцій реляційної алгебри.

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

Наприклад, нехай БД складається з таблиць Товар (Ідентифікатор, Назва) та Продаж (Дата, Ідентифікатор товару, Кількість, Ціна).

Необхідно отримати результат запиту «Який товар продавали в кількості більше 100». Відповідь можна представити у вигляді наступних послідовностей.

Перша послідовність:

R1 = JOIN (Товар, Продаж, Ідентифікатор товару = Товар)

R2 = s (R1, Кількість> 100)

R3 = p (R2, Назва)

Друга послідовність:

R1 = s (Продаж, Кількість> 100)

R2 = JOIN (Товар, R1, Ідентифікатор товару = Товар)

R3 = p (R2, Назва)

Необхідно отримати результат запиту «Який товар ні разу не продавали». Відповідь можна представити у вигляді наступних послідовностей.

Перша послідовність:

R1 = LEFT JOIN (Товар, Продаж, Ідентифікатор товару = Товар)

R2 = s (R1, Ідентифікатор товару = NULL)

R3 = p (R2, Назва)

Друга послідовність:

R1 = p (Продаж, Ідентифікатор товару)

R2 = p (Товар, Ідентифікатор)

R3 = R2-R1

R4 = JOIN (Товар, R3, Товар.Ідентіфікатор = R3.Ідентіфікатор)

R5 = p (R4, Назва)

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

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

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

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

Таким чином, адміністратор програми повинен забезпечити таке.

Повинна бути навчальна БД із заповненими таблицями. Таблиці повинні бути заповнені такими даними, щоб можна було перевірити правильність виконання запиту в будь-якому випадку.

Для виконання запиту до БД повинна бути можливість з'єднання з навчальної БД.

Навчальних БД може бути декілька.

До кожної БД може бути складено безліч запитів, на кожний запит може бути безліч відповідей.

Користувач повинен мати зручний інтерфейс для введення послідовності операцій.

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

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

При введенні умов необхідно надати можливість вибору операції порівняння і безлічі стандартних констант типу TRUE, FALSE, NULL.

При перевірці правильності відповіді необхідно врахувати залежність і незалежність порядку операндів.

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

R 1 = LEFT JOIN (A, B, умова з'єднання)

і

R 1 = RIGHT JOIN (B, A, умова з'єднання).

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

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

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

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

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

Для цього програма повинна вміти перетворювати операцію (послідовність операцій) у запит до БД.

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

Введені відповіді повинні зберігатися у внутрішній БД із зазначенням отриманого за них бали.

Користувач повинен мати можливість переглянути отримані ним питання, введені відповіді та отримані результати. Ця інформація повинна друкуватися на принтері.

3.2 Структура даних

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

Дана інформація повинна зберігатися в так званої внутрішньої БД.

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

Сутність Користувач володіє атрибутами Ідентифікатор. Ім'я, Пароль.

Сутність Навчальна БД має атрибутами Ім'я, Інформація для з'єднання, Схема даних.

Сутність Питання володіє атрибутом Текст запиту, Максимальний бал.

Сутність Реляційна операція має атрибутами Назва, Позначення, операнд1, операнд2, Додаткова інформація.

Сутність Еталонний відповідь включає безліч операцій.

Сутність Послідовність операцій визначає можливий порядок операцій в еталонному відповіді.

Сутність Тест характеризується атрибутами Дата, Контролюючий або навчальний, Підсумкова оцінка.

Сутність Відповідь включає послідовність операцій.

Між сутностями можна визначити наступні взаємозв'язки.

Сутність Навчальна БД і Питання пов'язані відношенням «один до багатьох», питання відноситься тільки до однієї БД, але до однієї БД може бути побудовано безліч запитів.

Між сутностями Користувач і Тест існує зв'язок «один до багатьох», один користувач може проходити безліч тестів, але кожен тест відноситься до одного користувача.

Сутність Питання та Тест пов'язані відношенням «багато до багатьох», одне питання може входити в різні тести, і в тест можуть входити багато питань. Дана взаємозв'язок володіє власним атрибутом Оцінка.

Сутності Питання і Відповідь пов'язані відношенням «Один до багатьох», одне питання може мати безліч відповідей, але відповідь відноситься до одного питання.

Між сутностями Відповідь і Послідовність визначено зв'язок «Один до багатьох», відповідь може мати безліч послідовностей, але кожна послідовність відноситься до одній відповіді.

Сутності Операція і Відповідь пов'язані відношенням «багато до багатьох», у відповіді може бути безліч операцій, і операція бере участь у багатьох відповідях. Даний зв'язок має власні атрибути операнд1, операнд2 (необов'язковий), Додаткова інформація (необов'язкова).

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

Таким чином, виходить концептуальна модель даних, показана на рис.3.1.

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

У таблицю Таблиці додано атрибут Ідентифікатор БД. У таблицю Поля додано атрибут Ідентифікатор таблиці. У таблицю Тест додано атрибут Ідентифікатор користувача. У таблицю Питання додано атрибут Ідентифікатор БД.

Для реалізації зв'язків «багато до багатьох» створені додаткові таблиці Операція еталонного відповіді, Операція відповіді користувача, Питання тесту.

У таблицю Відповідь додано атрибут Ідентифікатор питання тесту. У таблицю Послідовність доданий Атрибут Ідентифікатор операції еталонного відповіді.

У результаті отримана наступна структура внутрішньої БД (див. табл.3.1)

Таблиця 3.1 Структура внутрішньої БД

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

Список літератури

1.План виконання запиту. Вільна енциклопедія Вікіпедія: [електронний ресурс] - Режим доступу: ru. Wikipedia. Org

2.Оптімізація запитів в SQL Server 2005: [електронний ресурс] - Режим доступу: http: / / www. Askit. Ru / custom / sql 2005_ admin / m 11/11_05_08_ query _ optimization. Htm

3.Гарсіа-Моліна Г. Системи баз даних. Повний курс / Гарсіа-Моліна Г., Ульман Дж., Уідом Дж. .. - М.: Видавничий дім «Вільямс», 2003. - 1088 с.

4.Хансен Г. Бази даних: розробка і управління / Хансен Г., Хансен Дж..: Пер. з англ. - М.: ЗАТ «Видавництво БІНОМ», 1999. - 704 с.

5.Роджер Дж. Керівництво розробника баз даних на Visual Basic 6 / Роджер Дж.: Пер. з англ. - К.; М.; СПб.: Видавничий дім «Вільямс», 2001. - 976 с.: Іл.

6.Теорія і практика побудови баз даних. 8-е вид. / Д. Кренке. - СПб.: Пітер, 2003. - 800 с.: Іл.

7.Конноллі Т. Бази даних: Проектування, реалізація, супровід. Теорія і практика / Конноллі Т.. - М.: Видавничий дім «Вільямс», 2002. - 1120 с.: Іл.

8. VB 6.0: доступ до даних за допомогою технології ADO. Частина 1. ADO йде на зміну DAO і RDO. - Www. Microsoft. Com / Rus / Msdn / Activ / MSVB / Archive / VBInHistory / VB 60_ ADO -1. Mspx

9. Visual Basic 6.0: пров. з англ. - СПб.: БХВ - Санкт-Петербург, 1999. - 992 с.,

10.Сбор і аналіз вимог: [електронний ресурс] - Режим доступу: http: / / progresoft. Ru /

11.Мюллер Р.Дж. Бази даних та UML / Мюллер Р.Дж.. - М.: ЛОРІ, 2002, - 420 с.

12.Мацяшек Л.А. Аналіз та проектування інформаційних систем за допомогою UML 2.0. / Мацяшек Л.А. Третє видання. - М.: Видавничий дім «Вільямс», 2008. - 816 с.

13.Кузнецов С.Д. Основи сучасних баз даних / С.Д. Кузнецов / / Інформаційно-аналітичні матеріали Центру інформаційних технологій: [електронний ресурс] - Режим доступу: http: / / www. Citforum. Ru / database / osbd / contents. Shtml

14.Грофф Дж. SQL: Повне керівництво / Грофф Дж., Вайнберг П.; пер. з англ. - К.: Видавнича група BHV, 1998. - 608 с.

15.Кіріллов В.В. Основи проектування реляційних баз даних. Навчальний посібник / В.В. Кирилов - СПб. : ІТМО, 1994. - 90 с.

16.Карпова І.П. Введення в бази даних: [електронний ресурс] навчальний посібник / І.П. Карпова - Московський державний інститут електроніки і математики (Технічний університет). - Режим доступу: http: / / rema .44. Ru / resurs / study / dblectio / dblectio. Html.

18.Оптімізація запитів СУБД: [електронний ресурс] - Режим доступу: http: / / dic. Academic. Ru / dic. Nsf / ruwiki / 356734

19.Кузнецов С. Методи оптимізації виконання запитів в реляційних СУБД / Кузнєцов С.: [електронний ресурс] - Режим доступу: http: / / www. Citforum. Ru /

20.Методи підвищення продуктивності: [електронний ресурс] - Режим доступу: http: / / wworacle. Narod. Ru / glava 7. Html

21.Проізводітельность mysql, завдання query plan: [електронний ресурс] - Режим доступу: http: / / baron. Pp. Ru / archives / 194 - Proizvoditelnost _ mysql, _ zadanie _ _ query plan. Html