База даних "Теорія та практика прикладного програмування"
Курсовой проект - Компьютеры, программирование
Другие курсовые по предмету Компьютеры, программирование
?й формі. Часто багато таблиці нормалізуються до четвертої нормальної форми.
Головна мета нормалізації бази даних усунення надмірності та дублювання інформації. В ідеалі при нормалізації треба домогтися, щоб будь-яке значення зберігалося в базі в одному примірнику, причому значення це не повинно бути отримано розрахунковим шляхом з інших даних, що зберігаються в базі.
Перша нормальна форма: [6]
- Забороняє повторювання стовпців, що містять однакову за змістом інформацію;
- Забороняє множинні стовпці (що містять значення типу списку і т.п.);
- Вимагає визначити первинний ключ для таблиці, тобто той стовпець або комбінацію стовпців, які однозначно визначають кожен рядок.
Друга нормальна форма вимагає, щоб неключові стовпці таблиць залежали від первинного ключа в цілому, але не від його частини (якщо таблиця знаходиться в першій нормальній формі і первинний ключ у неї складається з одного стовпця, то вона автоматично знаходиться і в другій нормальній формі).
Щоб таблиця перебувала в третій нормальній формі, необхідно, щоб неключові стовпці в ній не залежали від інших неключових стовпців, а залежали лише від первинного ключа. Найпоширеніша ситуація в даному контексті це розрахункові стовпці, значення яких можна отримати шляхом будь-яких маніпуляцій з іншими стовпцями таблиці. Для приведення таблиці в третю нормальну форму такі стовпці з таблиць треба видалити.
Нормальна форма Бойса-Кодда вимагає, щоб в таблиці був тільки один потенційний первинний ключ. Найчастіше у таблиць, що знаходяться в третій нормальній формі, так і буває, але не завжди. Якщо виявився другий стовпець (комбінація стовпців), що дозволяє однозначно ідентифікувати рядок, то для приведення до нормальної форми Бойса-Кодда такі дані треба винести в окрему таблицю.
Для приведення таблиці, що знаходиться в нормальній формі Бойса-Кодда, до четвертої нормальної форми необхідно усунути наявні в ній багатозначні залежності. Тобто забезпечити, щоб вставка / видалення будь-якого рядка таблиці не вимагала б вставки / видалення / модифікації інших рядків цієї ж таблиці.
Таблицю, що знаходиться в четвертій нормальній формі ще можна розбити на три або більше таблиць, зєднавши які ми отримаємо вихідну таблицю. Отриману в результаті такої, як правило, дуже штучної декомпозиції таблицю і називають таблицею, що знаходяться в пятій нормальній формі. Формальне визначення пятої нормальної форми таке: це форма, в якій усунені залежності зєднання. У більшості випадків практичної користі від нормалізації таблиць до пятої нормальної форми не спостерігається.
Рисунок 2.1.2 Нормалізована ER-діаграма (3НФ)
2.2 Даталогічне проектування баз даних
При переході від інфологічної моделі до даталогічної слід мати на увазі, що інфологічна модель включає в себе всю інформацію про предметну область, необхідну для проектування БД. Це не означає, що всі суті, зафіксовані в ІЛМ, повинні в явному вигляді відображатися в даталогічній моделі. Перш ніж будувати даталогічну модель, необхідно вирішити, яка інформація буде зберігатися в базі даних. Наприклад, у інфологічній моделі мають бути відображені показники, що обчислюються, але зовсім не обовязково, щоб вони зберігалися в базі даних.
Таблиця 2.2.1. Глава
ПолеТип данихРозмір№ п/пЛічильникДовге цілеКод параграфаЧисловийДовге цілеЗатрата времени на изучениеЧисловийДовге цілеКод оператораЧисловийДовге цілеКомпонентыЛогічнийКод таблицыЧисловийДовге цілеКод рисункаЧисловийДовге цілеКод примечанияЧисловийДовге цілеКод листинговЧисловийДовге цілеДата разработки записиДата/час
Таблиця 2.2.2. Листинги
ПолеТип данихРозмірКод листингаЛічильникДовге цілеНазвание листингаТекстовий50Работа с формойЛогічнийЛистингПоле МЕМО
Таблиця 2.2.3. Операторы
ПолеТип данихРозмірКод оператораЛічильникКлючевые словаТекстовий200Синтаксис оператораТекстовий240Семантика оператораТекстовий255Пример использованияЧисловийДовге ціле
Таблиця 2.2.4. Параграфы
ПолеТип данихРозмірКод параграфаЛічильникНазвание параграфаТекстовий50Краткое содержаниеТекстовий250Начальная страницаЧисловийДовге цілеКонечная страницаЧисловийДовге ціле
Таблиця 2.2.5. Примечания
ПолеТип данихРозмірКод примечанияЛічильникСтраницаЧисловийДовге цілеПримечаниеПоле МЕМО
Таблиця 2.2.6. Рисунки
ПолеТип данихРозмірКод рисункаЛічильникНазвание рисункаТекстовий65Страница расположения
рисункаЧисловийДовге цілеРисунокПоле МЕМО
Таблиця 2.2.7. Таблицы
ПолеТип данихРозмірКод таблицыЛічильникНазвание таблицыТекстовий60Страница нахожденияЧисловийДовге цілеТаблицаПоле МЕМОСтруктура таблиць відноситься до 3 НФ:
1) кожен стовпець таблиці неподільний і в рамках однієї таблиці немає стовпців з однаковими за змістом значеннями.
2) первинні ключі таблиць однозначно визначають запис і не надмірні.
3) значення будь-якого поля не входить у первинний ключ, не залежить від значення іншого поля, що також не входить у первинний ключ.
2.3 Фізичне проектування інформаційних систем
Фізичне проектування це безпосереднє проектування програмних модулів, з яких збирається додаток; це точка зору програміста на додаток.
Перехід від логічного до фізичного опису моделі складається з наступних кроків: [7]
1. Всі прості сутності перетворюються у звязки, імя сутності ста