рвинний ключ);
КодДеталі (зовнішній ключ);
Найменування;
ЧістийВес;
Норма;
Ширина
Висота;
Довжина.
) ГотоваяПродукція - відомості про рух готової продукції по складу:
Код (первинний ключ);
КодДеталі;
Значення;
Дата;
ТіпОпераціі.
) ТМЦ - відомості про рух ТМЦ по складу:
Код (первинний ключ);
КодМатеріала;
КодПодразделенія;
Дата;
Наявність;
Прихід;
Витрата.
) ГрафікРабот - дані про графік роботи:
ID (первинний ключ);
КодПодразделенія;
КодДеталі;
Значення;
Дата
Проведемо послідовну нормалізацію схем відносин на прикладі користувачів системи.
Перевіримо об'єкт Користувачі на відповідність першій нормальній формі (1NF). Відносини відповідають першій нормальній формі, якщо на перетині кожного стовпця і рядка знаходяться тільки елементарні значення атрибуту, і відсутня повторюваність атрибутів і груп атрибутів.
Розглянемо відношення R (id, login, pass, role).
Дане відносини знаходяться в 1NF.
Перевіримо його на відповідність другій нормальній формі (2NF). Відносини відповідають другій нормальній формі, якщо вони знаходяться в 1NF і не містять неповних функціональних залежностей, що не первинних атрибутів від атрибутів первинного ключа. Дане відношення знаходиться в 2NF.
Встановлюємо відносини між цими таблицями і перевіряємо таблиці на відповідність їх третій нормальній формі (3NF). Відносини відповідають третій нормальній формі, якщо вони знаходяться під 2NF і не містять транзитивних залежностей. Тобто жоден неключових атрибут не залежить від іншого неключевого атрибута.
Дані відносини знаходиться в 3NF. Перевірку на відповідність формі Бойса-Кодда проводити не потрібно, тому ключі не мають спільних атрибутів. Видалення, зміна або додавання будь-якого рядка таблиці не веде до змін інших рядків - багатозначні залежності відсутні. Тому таблиця знаходиться в четвертій НФ.
На рис. 4.3 представлена ??отримана в ході прямого проектування схема даних інформаційної системи бібліотеки.
Після закінчення процесу побудови інформаційної моделі системи за допомогою прямого проектування була проведена генерація бази даних MSSQLServer.
Малюнок 4.3 - Схема даних системи
. Керівництво користувача і тестування системи
. 1 Тестування системи
Для оцінки працездатності системи було проведено ручне тестування.
Ручне тестування - це процес пошуку дефектів у роботі програми, коли тестувальник перевіряє працездатність всіх компонентів програми, як якщо б він був користувачем.
Системний підхід до тестування включав в себе кілька етапів:
. Вибір методології тестування. Тестування системи проводилося по низхідному принципом. Це означає, що послідовно виконувалася перевірка коректності роботи сайту, починаючи від найбільш загальних функцій (вибрати пункт меню, створити запис, відредагувати запис тощо), до вузькоспеціалізованих (у разі виникнення помилки на більш високому рівні);
. Складання тестів з описом виконання і очікуваним результатом. Був розроблений набір функціональних тест-кейсів, згрупованих у сценарії відповідно до ролей користувачів системи. Для тестування окремих функцій системи була застосована стратегія «білого ящика». Це тестування логіки управління програми. Стратегія заснована на аналізі внутрішньої структури програми. Стратегія «білого ящика» включає перевірку операторів, рішень, умов, покриття рішень і умов, комбіноване покриття.
. Тестування;
. Аналіз результатів.
Для тестування були використані статичний і динамічний підходи.
Динамічні підхід включав в себе запуск програмного забезпечення.
Статистичне тестування включало в себе перевірку синтаксису і коду програми.
Перевірка на коректність посилань сайту здійснювалася з використанням програмного засобу WebLinkValidator. Результат тест...
