даних, встановленим у деякій организации.
Перша нормальна форма (1НФ) - відношення, у якому на перетінанні шкірного рядка и шкірного стовпця містіться только Одне значення.
Проаналізувавші програму «Автотранспортне підприємство» можна сделать Висновок, что вона знаходиться в 1НФ.
Друга нормальна форма (2НФ) - відношення, что находится в першій нормальній форме и КОЖЕН атрибут которого, что не входить до складу первинного ключа, характерізується ПОВНЕ функціональною залежністю від цього первинного ключа.
Повна Функціональна залежність: У деякім відношенні атрибут Б назівається Цілком функціонально залежних від атрибуту А, если атрибут Б функціонально покладів від полного значення атрибуту А і не залежиться ні від якої підмножіні полного значення атрибута А.
Оскількі логічна модель бази даних НЕ має Складення Первін ключів то вона знаходиться у 2НФ.
Третя нормальна форма (ЗНФ) - відношення, что находится в інший нормальний формах и не має НЕ вхідніх у первинний ключ атрібутів, что знаходиься б у транзітівній функціональній залежності від цього первинного ключа.
транзитивного залежність: Если для атрібутів А, В і С Деяк відношення існують залежності увазі А - gt; В і В - gt; С, ті говорять, что атрибут С транзитивній покладів від атрибуту А через атрибут Б (за умови, что атрибут А функціонально НЕ поклади ні від атрибуту В, ні від атрибуту С).
У логічній моделі бази даних курсового проекту відсутні НЕ вхідні у первинний ключ атрибути, что знаходяться у транзітівній залежності ві цього ключа, отже, вона знаходиться у 3НФ.
Нормальна форма Бойса-Кодда (НФБК) . Відношення знаходиться в НФБК тоді и только тоді, коли КОЖЕН его детермінант є потенційнім ключем.
Оскількі у логічній моделі БД відсутні детермінанті, Які НЕ є потенційнімі ключами можна вважаті, что вона знаходиться в НФБК.
.4 Перевірка моделі у відношенні транзакцій Користувачів
Перевіряємо локальних логічну модель даних представлених у відношенні возможности виконан всех транзакцій, передбачення спеціфікаціямі, для цього вікорістаємо ER-діаграму. Если, Спроба віконаті шкірних з транзакцій вручну буде вдалину, то можна вважаті, что дана логічна модель успішно перевірена. Если ж ні то у даній моделі присутности помилка, якові Варто усунуті.
Розглянемо можливий ПІДХІД до перевіркі логічної моделі даних у відношенні возможности виконан всех транзакцій, зазначену у спеціфікаціях. ПІДХІД Полягає в тому, щоб перевіріті, чі вся необхідна для виконан кожної транзакції інформація (сутності, зв'язки й атрибути) может буті ОТРИМАНО в даній моделі. Перевірка здійснюється за помощью Опису процедури виконан транзакції.
Створення і коректування запісів, що містять докладні зведення про роботу Автотранспортного підприємства , Пожалуйста Обслуговує КЛІЄНТІВ різного типу:
· Для коректування даних про Вже існуючіх працівніків Із вже призначеня унікальнім номером, самперед, необходимо віконаті поиск цього номера среди значень відповідного атрибута. Если завдань користувачем номер знайденій НЕ буде, фіксується помилка, оскількі віконаті коректування віявляється Неможливо. У ІНШОМУ випадка необходимо переконатіся, что Кожний з елементів даних, значення якіх необходимо відкорігуваті, є прісутнім у відношенні як атрибут.
· Для відалення відомостей про Деяк бригаду, завданні ее особіст номером, Варто віконаті поиск необхідного номера бригади среди значень відповідного атрибуту зовнішнього ключа.
.5 Визначення вимог ПІДТРИМКИ цілісності даних
На цьом етапі візначаємо ті вимоги ПІДТРИМКИ цілісності даних, Які необходимо реалізуваті в локальній логічній моделі даних користувача. Їхнє призначення складається в підтрімці постійної внутрішньої погодженості информации, організованої у віді бази даних. На даного етапі наше Завдання Полягає в тому, щоб Установити, Які самє вимоги ПІДТРИМКИ цілісності даних необхідні. Мі розглянемо п'ять тіпів вимог ПІДТРИМКИ цілісності:
· обов'язкові дані;
· обмеження для доменів атрібутів;
· цілісність сутности;
· посілальна цілісність;
· вимоги підприємства.
Обов'язкові дані:
