Побудова схеми реляційної бази даних в 3-ій нормальній формі - Інформаційна система "Планово-попереджувальний ремонт технологічного обладнання ТЕЦ. Програмна реалізація підсистеми формування графіка планово-попереджувального ремонту"

Нормалізація таблиць бази даних - перший крок на шляху проектування структури реляційної бази даних.

Нормалізація - це процес організації даних в базі даних, що включає створення таблиць і встановлення відносин між ними відповідно до правил, які забезпечують захист даних і роблять базу даних гнучкішою, усуваючи надмірність і неузгоджені залежності. В ідеалі при нормалізації треба добитися, щоб будь-яке значення зберігалося в базі в одному екземплярі, причому значення його не повинне бути набуте розрахунковим шляхом з інших даних, що зберігаються в базі[5].

Існує декілька правил нормалізації баз даних. Кожне правило називається "Нор-мальною формою". Якщо виконується перше правило, говорять, що база даних представлена в "першій нормальній формі". Якщо виконуються три перших правила, вважається, що база даних представлена в "третій нормальній формі". Є і інші рівні нормалізації, проте для більшості додатків досить нормалізувати бази даних до третьої нормальної форми.

База даних вважається нормалізованою, якщо її таблиці (принаймні, більшість таблиць) представлені як мінімум в третій нормальній формі.

Щоб таблиця знаходилася в третій нормальній формі, необхідно, щоб неключові стовпці в ній не залежали від інших неключових стовпців, а залежали тільки від первинного ключа. Найпоширеніша ситуація в даному контексті - це розрахункові стовпці, значень яких можна набути шляхом яких-небудь маніпуляцій з іншими стовпцями таблиці. Для приведення таблиці в третю нормальну форму такі стовпці з таблиць треба видалити.

Побудуємо схему реляційної бази даних і перевіримо, чи знаходитися вона в 3-ій нормальній формі (див. рис 3.5).

Отримана схема полегшить нормалізацію бази даних.

Розглянемо функціональні залежності таблиці "Силові трансформатори".

Залежності:

    - Id_тран - первинний ключ (PK); - Id_тран > Тип, Потужність, Напруга, Струм, Ек, Схема з'єднання, Вага масла Заводський номер, Стаціонарний номер; - Id_цех - зовнішній ключ (FK) з таблицею Завод.

Поля Тип, Потужність, Напруга, Струм, Ек, Схема з'єднання, Вага масла, Заводський номер, Стаціонарний номер - неключові і не залежать один від одного і повністю функціонально залежать від первинного ключа Id_тран. Надмірних даних також не існує, оскільки поле Id_цех зв'язано зовнішнім ключем (FK) з відповідною таблицею. Дана таблиця не має транзитивних залежностей, отже, таблиця "Силові трансформатори " знаходиться в 3-ій нормальній формі.

Рисунок 3.5 - Схема бази даних "ГППР "

Таблиця "Двигуни" з функціональною залежністю:

    - Id_двиг - первинний ключ (PK); - Id_двиг > Найменування агрегата, Тип_дв, Рік виготовлення, Заводський номер_дв, Стаціонарний номер_дв; - Id_цех - зовнішній ключ (FK) з таблицею Цех.

Поля Тип Найменування агрегата, Тип, Рік виготовлення, Заводський номер, Стаціонарний номер - не ключові і не залежать один від одного і повністю функціонально залежать від первинного ключа Id_двиг. Надмірних даних також не існує, оскільки поле Id_цех зв'язано зовнішнім ключем (FK) з відповідною таблицею. Дана таблиця не має транзитивних залежностей, отже, таблиця "Двигуни " знаходиться в 3-ій нормальній формі.

Розглянемо таблицю "Цех". Залежності:

    - Id_цех - первинний ключ (PK); - Id_цех > Назва цеху, Адреса, Телефон.

Поля Назва цеху, Адреса, Телефон - неключові і не залежать один від одного і повністю функціонально залежать від первинного ключа Id_цех. Дана таблиця не має транзитивних залежностей, тобто таблиця "Цех" знаходиться в 3-ій нормальній формі.

Похожие статьи




Побудова схеми реляційної бази даних в 3-ій нормальній формі - Інформаційна система "Планово-попереджувальний ремонт технологічного обладнання ТЕЦ. Програмна реалізація підсистеми формування графіка планово-попереджувального ремонту"

Предыдущая | Следующая