Реляційна модель даних у системах управління базами даних

Кафедра «Прикладна математика та обчислювальна техніка»

Реферат прийнятий

з оцінкою ____________

Преподаватель__________Т.К.Ивашковская

15.05.2007

Реляційна МОДЕЛЬ ДАНИХ У СИСТЕМАХ УПРАВЛІННЯ БАЗАМИ ДАНИХ

Реферат з дисципліни

"Основи розробки бізнес-додатків"

ЯГТУ 080502.65-004 Р

Реферат виконала

студентка гр. ЗЕУС-38

__________О.Х.Давлетшіна

15.05.2007

2007

ЗМІСТ

Введення

1 Основні поняття реляційних баз даних

2 Обмежувальні умови, що підтримують цілісність

2.1 Цілісність категорії (сутності) і посилань

3 Операції над реляційними даними

3.1 Традиційні операції

3.2 Спеціальні операції

4 Нормалізація

4.1 Перша нормальна форма

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

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

4.4 Інші нормальні форми

Висновок

Список використаних джерел

ВСТУП

Часто, кажучи про базу даних, мають на увазі просто деякий автоматизоване сховище даних. Таке уявлення не цілком коректно.

Дійсно, у вузькому сенсі слова, база даних - це деякий набір даних, необхідних для роботи (актуальні дані). Однак дані - це абстракція; ніхто ніколи не бачив "просто дані", вони не виникають і не існують самі по собі. Дані суть відображення об'єктів реального світу. Нехай, наприклад, потрібно зберігати відомості про деталі, що надійшли на склад. Як об'єкт реального світу - деталь - буде відображено в базі даних? Для того, щоб відповісти на це питання, необхідно знати, які ознаки або сторони деталі будуть актуальні, необхідні для роботи. Серед них можуть бути назва деталі, її вага, розміри, колір, дата виготовлення, матеріал, з якого вона зроблена і т.д. У традиційній термінології об'єкти реального світу, відомості про які зберігаються в базі даних, називаються сутностями - entities, а їх актуальні ознаки - атрибутами (attributes).

Кожна ознака конкретного об'єкта є значення атрибута. Так, деталь "двигун" має значення атрибуту "вага", рівне "50", що відображає той факт, що даний двигун важить 50 кілограмів.

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

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

Відзначимо, що в базі даних потрібно зберігати тільки актуальні, значущі зв'язку.

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

Прийнято вважати, що реляційний підхід до організації баз даних був закладений в кінці 1960-х рр.. Едгаром Коддом. В останні десятиліття цей підхід є найбільш поширеним (з застереженням, що в званих в побуті реляційними системах баз даних, заснованих на мові SQL, в дійсності порушуються деякі важливі принципи класичного реляційного підходу). Достоїнствами реляційного підходу прийнято вважати такі властивості: реляційний підхід грунтується на невеликому числі інтуїтивно зрозумілих абстракцій, на основі яких можливо просте моделювання найбільш поширених предметних областей; ці абстракції можуть бути точно і формально визначені; теоретичним базисом реляційного підходу до організації баз даних служить простий і потужний математичний апарат теорії множин та математичної логіки; реляційний підхід забезпечує можливість ненавігаційній маніпулювання даними без необхідності знання конкретної фізичної організації баз даних у зовнішній пам'яті. Комп'ютерний світ далеко не відразу визнав реляційні системи. У 70-і роки минулого століття, коли вже були отримані майже всі основні теоретичні результати і навіть існували перші прототипи реляційних СУБД, чимало авторитетних фахівців заперечували можливість домогтися ефективної реалізації таких систем. Однак переваги реляційного підходу та розвиток методів і алгоритмів організації і управління реляційними базами даних призвели до того, що до кінця 80-х років реляційні системи зайняли на світовому ринку СУБД домінуюче становище.

1 ОСНОВНІ поняття реляційних баз даних

Отже, ми отримали уявлення про те, що зберігається в базі даних. Тепер необхідно зрозуміти, як сутності, атрибути та зв'язки відображаються на структури даних. Це визначається моделлю даних.

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

За поширеністю і популярності реляційні СУБД сьогодні - поза конкуренцією. Вони стали фактичним промисловим стандартом, вона була розроблена Коддом ще в 1969-70 роках на основі математичної теорії відносин і спирається на систему понять, найважливішими з яких є таблиця, ставлення, рядок, стовпець, первинний ключ, зовнішній ключ.

Реляційної вважається така база даних, в якій всі дані представлені для користувача у вигляді прямокутних таблиць значень даних, і всі операції над базою даних зводяться до маніпуляцій з таблицями. Таблиця складається з рядків і стовпців і має ім'я, унікальне всередині бази даних. Таблиця відображає тип об'єкта реального світу (сутність), а кожна її рядок - конкретний об'єкт. Так, таблиця Деталь містить відомості про всі деталі, що зберігаються на складі, а її рядки є наборами значень атрибутів конкретних деталей. Кожен стовпець таблиці - це сукупність значень конкретного атрибута об'єкта. Так, стовпець Матеріал являє собою безліч значень "Сталь", "Олово", "Цинк", "Нікель" і т.д. У стовпці Кількість містяться цілі невід'ємні числа. Значення у стовпці Вага - дійсні числа, рівні вазі деталі в кілограмах.

Ці значення не з'являються з повітря. Вони вибираються з множини всіх можливих значень атрибута об'єкта, яке називається доменом (domain). Так, значення в стовпці матеріал вибираються з безлічі імен всіх можливих матеріалів - пластмас, деревини, металів і т.д. Отже, у стовпці Матеріал принципово неможлива поява значення, якого немає у відповідному домені, наприклад, "вода" або "пісок".

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

Малюнок 1. Основні поняття бази даних.

Так як рядки в таблиці не впорядковані, не можна вибрати рядок за її позиції - серед них не існує "першої", "другий", "останньою". Будь-яка таблиця має один або декілька стовпців, значення в яких однозначно ідентифікують кожну її рядок. Такий стовпець (або комбінація стовпців) називається первинним ключем (primary key). У таблиці Деталь первинний ключ - це стовпець Номер деталі. У нашому прикладі кожна деталь на складі має єдиний номер, за яким з таблиці Деталь витягується необхідна інформація. Отже, в цій таблиці первинний ключ - це стовпець Номер деталі. У цьому стовпці значення не можуть дублюватися - у таблиці Деталь не повинно бути рядків, які мають одне і те ж значення в стовпці Номер деталі. Якщо таблиця задовольняє цій вимозі, вона називається відношенням (relation).

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

Малюнок 2. Взаємозв'язок таблиць бази даних.

Таблиці неможливо зберігати і обробляти, якщо в базі даних відсутні "дані про дані", наприклад, описатели таблиць, стовпців і т.д. Їх називають зазвичай метаданими. Метадані також представлені в табличній формі і зберігаються в словнику даних (data dictionary).

Крім таблиць, в базi даних можуть зберігатися та інші об'єкти, такі як екранні форми, звіти (reports), уявлення (views) і навіть прикладні програми, що працюють з базою даних.

Для користувачів інформаційної системи недостатньо, щоб база даних просто відображала об'єкти реального світу. Важливо, щоб таке відображення було однозначним і несуперечливим. У цьому випадку говорять, що база даних задовольняє умові цілісності (integrity).

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

2 Обмежувальні умови, підтримувати цілісність

У реляційній моделі Кодда є кілька обмежувальних умов, що використовуються для перевірки даних у базі даних, а також для додання осмисленості структурі даних. Прийнято виділяти такі обмеження:

• Категорна цілісність;

• Цілісність на рівні посилань;

• Функціональні залежності.

2.1 ЦІЛІСНІСТЬ КАТЕГОРІЇ (СУТНОСТІ) І ПОСИЛАНЬ

У цілісній частині реляційної моделі даних фіксуються два базових вимоги цілісності, які повинні підтримуватися в будь-якої реляційної СУБД. Перша вимога називається вимогою цілісності сутності (entity integrity). Об'єкту або сутності реального світу в реляційних БД відповідають кортежі відносин. Конкретно вимога полягає в тому, що будь-який кортеж будь-якого значення-відносини будь-якої змінної стосунки має бути відрізнити від будь-якого іншого кортежу цього значення відносини по складових значенням заздалегідь певної множини атрибутів змінної відносини, тобто, іншими словами, будь-яка змінна відносини повинна володіти первинним ключем. Насправді, вимога цілісності суті повністю звучить наступним чином: у будь-якої змінної стосунки має існувати первинний ключ, і ніяке значення первинного ключа в кортежах значення-відносини змінної відношення не має містити невизначених значень (NULL).

Звичайно, теоретично будь-який кортеж, що занесені до сохраняемое ставлення, повинен містити всі характеристики модельованої їм сутності реального світу, які ми хочемо зберегти в базі даних. Однак на практиці не всі ці характеристики можуть бути відомі до того моменту, коли потрібно зафіксувати сутність в базі даних. Простим прикладом може бути процедура прийняття на роботу людину, розмір заробітної плати якого ще не визначений. У цьому випадку співробітник відділу кадрів, який заносить у відношення СЛУЖБОВЦІ кортеж, що описує нового службовця, просто не може забезпечити значення атрибуту СЛУ_ЗАРП (будь-яке значення домену РАЗМЕРИ_ВИПЛАТ буде невірно характеризувати зарплату нового співробітника).

Едгар Кодд запропонував використовувати в таких випадках невизначені значення. Невизначене значення не належить ніякому типу даних і може бути присутнім серед значень будь-якого атрибуту, визначеного на будь-якому типі даних (якщо це явно не заборонено при визначенні атрибута). Якщо a - це значення деякого типу даних або NULL, op - будь-яка двомісна «арифметична» операція цього типу даних (наприклад, +), а lop - операція порівняння значень цього типу (наприклад, =), то за визначенням:

a op NULL = NULL

NULL op a = NULL

a lop NULL = unknown

NULL lop a = unknown

Тут unknown - це третє значення логічного, або булевского, типу, що володіє наступними властивостями:

NOT unknown = unknown

true AND unknown = unknown

true OR unknown = true

false AND unknown = false

false OR unknown = unknown

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

Друга вимога, яка називається вимогою цілісності по посиланнях (referential integrity), є більш складним. Очевидно, що при дотриманні нормалізованності відносин складні сутності реального світу представляються в реляційної БД у вигляді декількох кортежів декількох відносин. Наприклад, уявімо, що потрібно представити в реляційній базі даних сутність ВІДДІЛ з атрибутами ВІД_НОМЕР (номер відділу), ОТД_РАЗМ (кількість службовців) і ОТД_СЛУ (безліч співробітників відділу). Для кожного службовця потрібно зберігати СЛУ_НОМЕР (номер співробітника), СЛУ_ІМЯ (ім'я співробітника) і СЛУ_ЗАРП (заробітна плата працівника). Як ми побачимо при правильному проектуванні відповідної БД в ній з'являться два відношення: ВІДДІЛИ {ВІД_НОМЕР, ОТД_РАЗМ} (первинний ключ - {ВІД_НОМЕР}) і СПІВРОБІТНИКИ {СЛУ_НОМЕР, СЛУ_ІМЯ, СЛУ_ЗАРП, СЛУ_ОТД_НОМ} (первинний ключ - {СЛУ_НОМЕР}).

Як видно, атрибут СЛУ_ОТД_НОМ вводиться у відношення СЛУЖБОВЦІ не тому, що номер відділу є власним властивістю співробітника, а лише для того, щоб мати можливість при необхідності відновити повну сутність ВІДДІЛ. Значення атрибуту СЛУ_ОТД_НОМ в будь-якому кортежі відносини СЛУЖБОВЦІ повинно відповідати значенню атрибута ОТД_НОМ в деякому кортежі відносини ВІДДІЛИ. Атрибут такого роду (можливо, складовою) називається зовнішнім ключем (foreign key), оскільки його значення однозначно характеризують сутності, представлені кортежами деякого іншого відношення (тобто задають значення їх первинного ключа). Звичайно, зовнішній ключ може бути складовим, тобто складатися з кількох атрибутів. Кажуть, що ставлення, в якому визначено зовнішній ключ, посилається на відповідне ставлення, в якому такий же атрибут є первинним ключем.

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

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

Обмеження цілісності сутності та по посиланнях повинні підтримуватися СУБД. Для дотримання цілісності сутності досить гарантувати відсутність у будь-якої змінної відношення значень-відносин, містять кортежі з одним і тим же значенням первинного ключа (і забороняти входження в значення первинного ключа невизначених значень). З цілісністю по посиланнях справа дещо складніша.

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

Тут існують три підходи, кожен з яких підтримує цілісність за посиланнями:

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

• При другому підході при видаленні кортежу, на який є посилання, у всіх посилань кортежах значення зовнішнього ключа автоматично стає повністю невизначеним.

• Нарешті, третій підхід (каскадне видалення) полягає в тому, що при видаленні кортежу з відношення, на яке веде посилання, з посилається відносини автоматично видаляються всі посилаються кортежі.

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

3 ОПЕРАЦІЇ НАД реляційними даними

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

3.1 ТРАДИЦІЙНІ ОПЕРАЦІЇ

1. Об'єднання двох відносин (С1 = А U В) передбачає, що на вході задано два односхемних відносини А і В. Результат об'єднання є побудоване за тією ж схемою відношення С, що містить всі кортежі Та всі кортежі відносини В.

2. Перетин двох відносин (С2 = А U В) передбачає на вході два односхемних відносини А і В. На виході створюється ставлення за тією ж схемою, що містить тільки ті кортежі відносини А, які є у відношенні В.

3. Віднімання двох відносин (С3 = А-В). Всі три відносини будуються за однією схемою. У результуюче відношення С3 включаються тільки ті кортежі з А, яких немає щодо В.

4. Декартово твір (С4 = А X В). Її важлива відмінність від попередніх полягає в тому, що відносини А і В можуть бути побудовані за різними схемами, а схема відносини С4 включає всі атрибути відносно А та В.

3. 2 Спеціальні ОПЕРАЦІЇ

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

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

3. Операція з'єднання природне. На вході операції використовується два відносини; позначимо їх А і В. У кожному з відносин виділено атрибут, за яким буде здійснюватися з'єднання; припустимо, це атрибути А1 і Б2). Обидва атрибуту повинні бути визначені на одному і тому ж домені. Схема результуючого відносини включає всі атрибути Та всі атрибути відносини В. Допускається, щоб у схемі результуючого відносини замість двох атрибутів, за якими виконується з'єднання, був представлений тільки один. Операція з'єднання схожа на декартовій твір. Відмінність полягає в тому, що декартово твір передбачає зчеплення, кожного кортежу з А з кожним кортежем з В, а в операції з'єднання кортеж із відносини А зчіплюється тільки з тими кортежами з В, для яких виконана умова: В1 = А1.

4. Операція ділення. На вході операції використовується два відношення А і В. Нехай ставлення А, зване діленим, містить атрибути (А1, А2, ..., Аn). Ставлення В - дільник-містить підмножина атрибутів А; покладемо, (А1, А2, ..., Аk), де (k <n). Результуюче відношення С визначено на атрибутах відносини А, яких немає і В, тобто Аk +1, Аk +2, ..., Аn. Кортеж включається до результуючого відношення тільки, якщо його декартово твір з відношенням В міститься в подільному-відношенні А.

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

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

4 НОРМАЛИЗАЦИЯ ВІДНОСИН

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

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

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

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

4.1 Перша нормальна форма

Відношення називається нормалізованим або приведеним до першої нормальної формі (1НФ), якщо всі його атрибути прості.

Ненормалізоване ставлення легко зробити нормалізованим. Таке перетворення може призвести до збільшення потужності відносини і зміни ключа.

Функціональна залежність. Нехай Х та Y - два атрибути деякого відносини, Кажуть, що Y функціонально залежить від X, якщо в будь-який момент часу кожному значенню Х відповідає не більше ніж одне значення атрибута Y. Функціональну залежність можна позначити так: Х> Y.

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

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

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

Щоб ставлення призвести до другої нормальної форми, необхідно:

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

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

Транзитивне залежність. Нехай X, Y, Z - три атрибути деякого відносини. При цьому Х> Y і Y> Z, але зворотне відповідність відсутня, тобто Z не> або Y не> Х. Тоді кажуть, що Z транзитивній залежить від X.

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

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

4.4 ІНШІ НОРМАЛЬНІ ФОРМИ

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

Таблиця має четверту нормальну форму (4НФ), якщо вона має 3НФ і не містить багатозначних залежностей.

Для позбавлення від деяких інших аномалій були запропоновані ще декілька нормальних форм: п'ята нормальна форма (5НФ), нормальна форма область / ключ (НФОК) і т.д. Однак вони мають дуже обмежене практичне використання.

ВИСНОВОК

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

1. Вибрати концептуальну модель, за допомогою якої буде побудована концептуальна схема;

2. Побудувати точний опис семантичних обмежень, підтримуваних обраної СУБД;

3. Побудувати відображення вибраної концептуальної моделі в модель даних, яка підтримується СУБД.

4. Визначити, що таке хороша схема і описати методику її побудови.

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Інтернет-ресурс

http://osp.aanet.ru/dbms/1996/03/index.htm

2. Інтернет-ресурс

http://www.intuit.ru/goto/course/rdbintro

3. Інтернет-ресурс

http://www.jetinfo.ru/1995/3-5/1/servbd.html

4. Нікітіна Т.П., Рубцов С.А. Бази даних та знань / Під ред.д-ра техн.наук, проф. Д. О. Битева. Вид-во ЯГТУ.-108с., 2003.