ільше, що володіють кращими властивостями при включенні, видаленні і зміну даних. Остаточна мета нормалізації зводиться до отримання такого проекту бази даних, в якому кожен факт з'являється лише в одному місці, тобто виключена надмірність інформації. Виділяють три основні нормальних форми: 1НФ, 2НФ і 3НФ. Таблиця знаходиться в 1НФ тоді і тільки тоді, коли жодна з її рядків не містить в будь-якому своєму полі більше одного значення і жодна з її ключових полів не порожньо. Таблиця знаходиться у 2НФ, якщо вона задовольняє визначенню 1НФ і всі її поля, що не входять в первинний ключ, пов'язані повної функціональної залежністю з первинним ключем. Таблиця знаходиться в 3НФ, якщо вона задовольняє визначенню 2Ф і не одне з її не ключова полів не залежить функціонально від будь-якого іншого не ключового поля.
Перевірена локальна логічна модель даних може застосовуватися в якості основи для розробки прототипів, якщо в цьому є необхідність.
При завершенні цього типу повинна бути отримана правильна, повна і несуперечлива модель представлення. Якщо в додатку застосовується тільки одне подання, то на цьому стадія логічного проектування бази даних, передбачена в методології, закінчується. А якщо є кілька подань, то повинен бути виконаний ще один етап, на якому окремі локальні логічні моделі даних об'єднуються в глобальну логічну модель даних організації.
Далі необхідно визначити відносини виходячи зі структури локальної логічної моделі даних. На даному етапі належить визначити набори відносин, необхідні для подання сутностей, зв'язків і атрибутів, що входять в уявлення окремих користувачів про предметну область додатка.
Зв'язок між двома сутностями відображається з використанням механізму «первинний ключ/зовнішній ключ». При визначенні того, в якому відношенні повинен знаходитися атрибут (атрибути) зовнішнього ключа, необхідно спочатку з'ясувати, яка з сутностей, що беруть участь у зв'язку, є батьківської, а яка дочірньої. Батьківської називається сутність, яка передає копію свого первинного ключа у відношення, що представляє дочірню сутність, для використання в якості зовнішнього ключа [8].
На наступному етапі моделювання необхідно перевірити стосунки за допомогою правил нормалізації. Нормалізація використовується для поліпшення моделі даних, щоб вона задовольняла різним обмеженням, що дозволяє виключити небажане дублювання даних. Нормалізація гарантує, що отримана в результаті її застосування, модель даних буде найкращим чином відображати особливості використання інформації в організації, не містити протиріч, мати мінімальну надмірність і максимальну стійкість.
Стадія, попередня фізичній проектування, називається стадією логічного проектування. Результати її виконання в значній мірі залежні від особливостей фізичної реалізації проекту. При логічному проектуванні не беруться до уваги конкретні функціональні можливості цільової бази даних і прикладних програм, однак враховуються можливості обраної моделі даних.
Результатом логічного проектування є глобальна логічна модель даних, що складається з ER-діаграми і діаграми відносин, а так само реляційної схеми, і комплектопісивающей її супровідної документації, що включає, зокрема, словник даних. У сукупності ці результати є вихідною інформацією для стадії фізичного проектування бази даних і представляє її розробнику все необхідне для прийняття рішень, спрямованих на досягнення максимальної ефективності створюваного проекту. Образно кажучи, при логічному проектуванні розробник в основному розглядає, що повинно бути зроблено, а при фізичному проектуванні він шукає спосіб, як це зробити. У кожному випадку потрібна наявність різних навичок, якими володіють різні фахівці. Так, фахівець з фізичного проектування баз даних повинен ясно уявляти, як функціонує в комп'ютерній системі та чи інша СУБД. Оскільки функціональні можливості різних СУБД досить сильно відрізняються один від одного, фізичне проектування завжди тісно пов'язано з особливостями конкретної обраної системи.
Однак етап фізичного проектування бази даних не є абсолютно ізольованим від інших. Як правило, між фізичним, логічним проектуванням і розробкою додатків завжди є зворотний зв'язок. Наприклад, рішення, прийняте на етапі фізичного проектування з метою підвищення продуктивності системи (зокрема, по об'єднанню відносин), можуть вплинути на структуру логічної моделі даних, а це може відбитися на проектах додатків.
Найпершим завданням на етапі фізичного проектування баз даних є перетворення відносин, створених на основі глобальної логічної моделі даних, в таку форму, яка може бути реалізована в середовищі цільової СУБД. Перша частина цього процесу передбачає перевірку інформації, зібраної на етапі логічного проектування бази даних і вміщеній в словник даних. Друга ч...
