Нормалізація таблиць в реляційної моделі бази даних [ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати. скачати МІНІСТЕРСТВО ОСВІТИ Державна освітня установа Вищої професійної освіти РОСІЙСЬКИЙ ДЕРЖАВНИЙ ТОРГОВЕЛЬНО-ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ Кемеровський ІНСТИТУТ (ФІЛІЯ) Факультет заочного навчання Кафедра обчислювальної техніки та інформаційних технологій Контрольна робота з дисципліни "Бази даних" за темою: "Нормалізація таблиць в реляційної моделі бази даних" Виконав: студент групи Піс-061 (Скорочена форма навчання) Жилковом Ольга Анатоліївна м. Кемерово 2007 Зміст 1 Нормалізація таблиць в реляційної моделі БД 1.1 Поняття "Нормалізація" 1.2 Перша нормальна форма 1.3 Друга нормальна форма 1.4 Третя нормальна форма 1.5 Четверта нормальна форма 1.6 П'ята нормальна форма. 2. Реляційна алгебра над навчальною базою 3. База даних для предметної області "Навчальні посібники" Література 1 Нормалізація таблиць в реляційної моделі БД 1.1 Поняття "Нормалізація" Нормалізація - це формалізована процедура, в процесі виконання якої атрибути даних (поля) групуються в таблиці, а таблиці, у свою чергу, - в бази даних. Цілі нормалізації наступні: Виключити дублювання інформації в таблицях. Забезпечити можливість змін у структурі таблиць. Зменшити вплив структурних змін бази даних на роботу додатків, які забезпечують користувачам доступ до даних. Процес нормалізації складається з декількох етапів. Перші три з них, виконуваних частіше за все, були описані в 1972 році доктором Коддом. 1.2 Перша нормальна форма Кожне поле таблиці має представляти унікальний тип інформації. Це правило означає, що необхідно позбавитися від повторюваних полів і розділити складові поля на окремі елементи даних. Правила побудови першої нормальної форми вимагають, щоб всі таблиці даних були плоскими і не містили повторюваних даних в різних рядках. Під плоскою розуміється таблиця, яка має тільки два виміри: довжина (кількість записів або рядків) та ширина (кількість полів або стовпців). Її осередки не можуть містити більше одного значення. Якщо хоча б одна клітинка таблиці містить більше одного значення, для представлення її вмісту вже потрібне третій вимір - глибина. Плоскі таблиці і плоскі файли баз даних дуже схожі тим, що мають тільки два виміри. Проте в плоскому файлі міститься лише одна таблиця і не накладаються обмеження на вміст її осередків. Прикладом ненормалізованих даних можуть виступати дані, представлені в таблиці 1.1 Таким способом зазвичай складається розклад руху транспорту. Таблиця 1.1 - ненормалізоване дані Судно Назва Рейс Навантаження Прибуття з Прибуття Порт Відправлення Прибуття Порт Відправлення 526 Japan Bear 9203W 5/31/92 SFO 6/6/92 HNL 6/8/92 7/15/92 OSA 7/18/92 603 Korea Bear 9203W 5/05/92 OAK 6/19/92 OSA 6/21/92 6/25/92 INC 6/28/92 531 China Bear 9204W 6/20/92 LAX 7/10/92 PAP 7/11/92 8/28/92 SYD 9/2/92 528 Japan Bear 9204W 8/20/92 SFO 8/27/92 HNL 8/29/92 9/30/92 OSA 10/2/92 Оскільки суду зупиняються у багатьох портах, стовпці Прибуття, Порт і Відправлення повторюються для кожної зупинки. Така структура запису даних не підходить для реляційної бази даних. запис наведеної інформації не відповідає вимогам першої нормальної форми, оскільки містить повторювану групу стовпців. Цю таблицю необхідно розділити на дві: Порти і рейси судів, що не містять повторюваних груп, як показано в таблицях 1.2 та 1.3 Таблиця 1.2 - Таблиця "Рейси судів" Судно Назва Рейс Навантаження Прибуття з 528 Japan Bear 9203W 5/31/92 SFO 603 Korea Bear 9203W 6/5/92 OAK 531 China bear 9204W	6/20/92	LAX
528	Japan bear	9204W	8/20/92	SFO

Таблиця 1.3 - Таблиця "Порти"

Тепер необхідно встановити зв'язок між таблицями Порти і Рейси судів. У стовпці рейс вказується поточний рік, номер рейсу за цей рік, а також напрямок рейсу (наприклад, 9204 W - це четвертий рейс за 1992 рік у західному напрямку). Таким чином, для зв'язку між таблицями слід застосовувати поля Судно і Рейс. Використовувати який-небудь один з цих способів недостатньо, оскільки одне судно може робити кілька рейсів протягом року, а в одному напрямку можуть відправлятися відразу кілька судів. Оскільки для задоволення вимог першої нормальної форми доведеться створити нову таблицю Порти, необхідно відсортувати її стовпці в порядку значимості. Першими, як правило, розміщуються стовпці, що використовуються для встановлення зв'язку. При цьому вони розташовуються в тій послідовності, в якій вони входять у складений первинний ключ. Дані показані в таблиці 1.4

Таблиця 1.4 - Таблиця "Порти"

Тепер необхідно визначити ключові поля таблиці Порти, що дає можливість точно ідентифікувати її записи. Обов'язково необхідно створити первинний ключ, оскільки від цієї таблиці можуть залежати багато інших. Необхідно додати стовпці Судно і рейс, так як вони забезпечують зв'язок з даними таблиці Рейси судів, також додати полі Порт для створення довершеного унікального ключа (стовпи Судно і Рейс можуть містити повторювані значення). Комбінації Судно + Рейс + Порт представляє собою складовою первинний ключ, значення якого однозначно ідентифікує запис. Значення цього ключа не повторюються, оскільки врахована можливість двічі робити зупинку в одному порту (придвижении туди і назад). Так, якщо судно повертається зі сходу, рейс позначається суфіксом "Е".

1.3 Друга нормальна форма

Для приведення таблиць до другої нормальної форми необхідно забезпечити повну залежність стовпців, які не є ключовими, від первинного ключа, а якщо цей ключ складовою, то від кожного його елемента. Під повною залежністю розуміється можливість однозначного визначення значення кожного неключові поля за допомогою значення первинного ключа. Якщо для однозначного визначення використовується складений первинний ключ, то це правило застосовується до кожного значення з полів, що входять у складений ключ. Завжди, коли це можливо, в якості первинного ключа слід використовувати найпростіші дані, що мають "природні" унікальні значення. Перед переходом до другої нормальної форми необхідно навести дані до першої нормально формі. У процесі створення другої нормальної форми велика частина повторюваних даних, що залишилися в таблиці після приведення її до першої нормальної форми, буде видалена.

Для створення в таблиці Рейси судів однозначного ключа доведеться використовувати складовою ключ (Судно + Рейс). Оскільки номер і назва судна можуть повторюватися. Поля Судно і Назва не залежать від первинного ключа, оскільки полем Рейс нічого не визначається. Назва судна зазначається у кожному рейсі. Так, наприклад, назва Japan Bear з'являється двічі. Всі ці недоліки порушують правила другої нормальної форми. Виникає необхідність розбиття таблиці Рейси судів ще на дві: Рейси та Суду. Кожен корабель описується одним рядком у таблиці суду, а один рядок таблиці Рейси описує рейс одного судна (з метою спрощення побудови бази даних східні і західні напрями розглядаються як окремі рейси). Як і в таблиці Порти, для встановлення відповідності між рейсами і судами необхідно створити ключ, тому необхідно додати поле номерів суден у таблицю Рейси. Таблиці Суду і Рейси показані в таблицях 1.5 та 1.6

Таблиця 1.5 - Таблиця "Суду"

Таблиця 1.6 - Таблиця "Рейси"

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

1.4 Третя нормальна форма

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

Таблиці суду і Рейси вже представлені в третій нормальній формі, оскільки вони містять повторюваних груп стовпців і існує залежність неключових стовпців цих таблиць від ключових. У таблиці Порти немає повторюваних груп полів, а неключові поля Прибуття і Відправлення залежать від складеного ключа (Судно + Рейс + Порт) і не залежать один від одного. (Дата прибуття ніяк не впливає на дату відправлення, оскільки інтервал між ними визначається часом навантаження товарів на судно, доступністю стоянок, навантажувальних кранів, а також погодними умовами) Таким чином, таблиця Порти задовольняє вимогам першої, другої і третьої нормальних форм.

Наприклад, необхідно ввести в базу даних ще і службовців, членів команд кораблів (капітанів, інженерів тощо). Для цього необхідно додати в таблицю Суду коди службовців, які є первинними ключами таблиці Службовці, показані в таблиці 1.7

Таблиця 1.7 - Таблиця з транзитивним відношенням між судами та представниками команди.

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

Можна спробувати додати стовпець з номерами службовців в таблицю Рейси. Але і це не вирішить всіх проблем, оскільки судно може прибути в порт з одним командним складом, а відбути з абсолютно іншим. Крім цього, виникає необхідність визначити членів команди, які залишаються на судні під час його стоянки в порту.

Всі ці питання вирішуються за допомогою таблиці Команди, наведеної в таблиці 1.8 повторювані значення полів Порт (порт відправлення) і Відправлення в (порт прибуття) створюють запису для тих членів команди, які несуть відповідальність за судно під час його перебування в порту. Таблиця Команди відноситься до категорії сполучних таблиць, оскільки всі поля пов'язані з первинними ключами основних таблиць (Суда, Рейси, Порти і Службовці) або є частиною цих таблиць.

Таблиця 1.8 - Таблиця "Команди"

Тепер всі таблиці є плоскими, не містять повторюється інформації, за винятком даних, використовуваних в ключах. Всі ці таблиці задовольняють вимогам першої, другої і третьої нормальної форм.

1.5 Четверта нормальна форма

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

Багато розроблювачів додатків баз даних ігнорують четверту і п'яту нормальні форми у своїх програмних продуктах, оскільки вважають їх дуже специфічними. Результатом цього часто є створення бази даних неправильної структури, хоча це зовсім не означає, що вона не буде функціонувати.

1.6 П'ята нормальна форма

П'ята нормальна форма вимагає забезпечення можливості точного відновлення вихідної таблиці з таблиць, на яких вона заснована. Побудова п'ятого нормальної форми вимагає задоволення вимог третьої нормальної форми і, за наявності зв'язків багато-до-багатьох, відповідності правилам четвертою.

Таблиця Рейси дуже схожа на таблицю Порти. Стовпець прибуття з аналогічний стовпцю Порт, а стовпець Навантаження - стовпцю Відправлення. саме з цієї причини можна перемістити дані таблиці Рейси в таблицю порти і видалити таблицю Рейси. нова таблиця порти показана в таблиці 1.9 Значення стовпця Прибуття для записів, внесених до таблиці Порти з таблиці рейси, не визначені (не існують), так як у таблиці Рейси були вказані тільки дати отруєння.

Таблиця 1.9 - Таблиця "Порти"

Неможливо відновити вихідну таблицю з об'єднаних таблиць Рейси та Порти, оскільки не зможете відрізнити рядок відправлення від інших рядків за значеннями її полів у таблиці. Щоб відрізнити рядка відправлень, можна було б використовувати значення Null у полі Прибуття, проте значення Null повинно бути зарезервованим для умови "дані недоступні". Необхідно усунути будь-які двозначності, які можуть призвести до появи значень Null, і перетворити таблицю у п'яту нормальну форму, додавши Односимвольний полі Тип, що визначає прибуття або відправлення. У показаної таблиці 1.10 Порти коди Е і S представляють відповідно навантаження (Embarkation) та очікуване прибуття (Scheduled). Можуть також використовуватися коди M для заправки (Maintenance) і R - для зворотного рейсу (Return voyage ).

Таблиця 1.10 - Таблиця "Порти"

2. Реляційна алгебра над навчальною базою

R 1 - список абітурієнтів, які здавали репетиційні вступні іспити;

R 2 - список абітурієнтів, які здавали вступні іспити на загальних підставах;

R 3 - список абітурієнтів, прийнятих в інститут.

Необхідно написати відповідь на запит у вигляді формули реляційної алгебри. Запит: "Список абітурієнтів, які надходили два рази і надійшли до вузу".

Таблиця 2.1 - Відношення R1

Таблиця 2.2 - Відношення R2

Таблиця 2.3 - Відношення R3

Операція реляційної алгебри - "перетин".

R1 (a, b, c, d, e, f, g, h, l) R2 (a, b, d, h, m, n, o, p) = R3 (a, b, d, h)

3. База даних для предметної області "Навчальні посібники"

Ненормалізоване подання інформації у вигляді схеми.

Приведення до третьої нормальній формі.

перша нормальна форма - кожне поле таблиці представляє унікальний тип інформації;

Таблиця "Дисципліни" - номер дисципліни, найменування дисципліни, кількість годин;

Таблиця "Посібники" - номер посібники, ПІБ автора, Номер дисципліни;

Таблиця "Спеціальності" - номер спеціальності, найменування спеціальності;

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

Таблиця "Дисципліни" - номер дисципліни;

Таблиця "Посібники" - номер допомоги;

Таблиця "Спеціальності" - номер спеціальності.

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

Таблиця "Дисципліни-Спеціальності" - номер дисципліни, номер спеціальності.

Дані таблиць.

Таблиця 3.1 - Таблиця "Дисципліни"

Таблиця 3.2 - Таблиця "Посібники"