одну сутність з назвою "досвід роботи" і винести туди всі вищеописані атрибути, встановивши визначають атрибути ключовими і створивши залежну зв'язок з сутністю "працівник". p align="justify"> Дані розподілені по таблицях і структура моделі стала більш логічно впорядкованої і менш завантаженою. Але при уважному розгляді сутності "Освіта" можна помітити ще одну транзитивною залежність атрибутів DegreeYes і Degree від зовнішнього ключа моделі. Позбутися від неї можна створенням ще однієї сутності "Наукові досягнення" і винесенням туди атрибутів Degree, Rank і DegreeYes в якості ключа. Але на цьому зупинятися поки рано, оскільки варіантів запису вченого звання і наукового ступеня може бути кілька, а це неприпустимо за правилами першої нормальної форми. Для того щоб уникнути конфліктів і повторень, я створив ще дві таблиці-довідника під назвою "вчений ступінь" і "вчене звання". Вони міститимуть всього по 2 поля - номер звання або ступеня і сама їх назва. Відмінність цих сутностей від інших у тому, що вони пов'язані тільки з сутністю "Наукові досягнення" неідентіфіцірующей зв'язком (об'єкт non-identifying relationship на панелі toolbox). Це означає, що ці сутності самі є батьківськими та їх ключові атрибути мігрують в дочірню в якості зовнішніх ключів. У таблиці "Наукові досягнення" ці поля будуть містити просто посилання на номер вченого звання або наукового ступеня, назва яких зберігається в однойменних таблицях, що дозволить уникнути неприпустимих значень в цих полях. p align="justify"> Залишилася тільки одна невідповідність правилам нормалізації - по суті "попереднє місце роботи" атрибут WorkPhone може приймати кілька значень, адже в організації, в якій раніше працював співробітник, може бути кілька робочих телефонів, а це суперечить навіть правилам першої нормальної форми. Необхідно створити окрему сутність "робочий телефон" і пов'язати її з сутністю "попереднє місце роботи" ідентифікуючої зв'язком, що має на увазі міграцію ключів батьківського суті в дочірню. Після визначення ключових атрибутів у решти сутностей можна сказати, що модель бази даних повністю задовольняє вимогам третього нормальної форми і знаходиться в ній (мал. 5). br/>В
Рис.5 третя нормальна форма
3.7 Перевірка адекватності логічної моделі
Якщо взаємозв'язку між сутностями були правильно встановлені, то можна скласти пропозиції, їх описують. Наприклад, за моєю моделі, показаної на рис.6 можна скласти наступні пропозиції:
В· Працівник працює на місці роботи.
В· Працівник має досвід роботи.
В· Працівник має наукові досягнення.
В· Вчене звання присвоєно за наукові досягнення.
В·
