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