ТЕХНОЛОГІЯ ПРОЕКТУВАННЯ ТА АДМІНІСТРУВАННЯ БАЗ ДАНИХ І СХОВИЩ ДАНИХ

 

УНІВЕРСИТЕТ БАНКІВСЬКОЇ СПРАВИ

НАЦІОНАЛЬНОГО БАНКУ УКРАЇНИ (м. КИЇВ)

ЛЬВІВСЬКИЙ ІНСТИТУТ БАНКІВСЬКОЇ СПРАВИ

ОПОРНИЙ КОНСПЕКТ ЛЕКЦІЙ

Ч.2

З дисципліни

ТЕХНОЛОГІЯ ПРОЕКТУВАННЯ ТА АДМІНІСТРУВАННЯ

БАЗ ДАНИХ І СХОВИЩ ДАНИХ

для бакалаврів усіх форм навчання спеціальності

6.050100 "Економічна кібернетика"

Укладач:

Доц. каф. ЕК

Вєніков Д.П.

Львів - 2011

ТЕХНОЛОГІЯ ПРОЕКТУВАННЯ БД

ІНФОЛОГІЧНА МОДЕЛЬ ДАНИХ. ОСНОВНІ ПОНЯТТЯ.

  Рисунок 71 - Рівні моделей даних

Архітектура бази даних. Фізична і логічна незалежність.

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

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

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

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

На мал. 7.2 представлена класифікація моделей даних.

 

Рис. 7.2. Класифікація моделей даних

Найбільший інтерес викликають моделі даних, використовувані на концептуальному

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

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

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

Документарні моделі даних відповідають уявленню про слабо структуровану інформацію, орієнтовану в основному на вільні формати документів, текстів природною мовою.

Моделі, засновані на мовах розмітки документів, зв'язані, насамперед , зі стандартною загальною мовою розмітки - SGML (Standard Generalіzed Markup

Language), що був затверджений ІSO як стандарт ще в 80-х роках. Ця мова призначена для створення інших мов розмітки, він визначає припустимий набір тегів (посилань), їхні атрибути і внутрішню структуру документа. Контроль за правильністю використання тегів здійснюється за допомогою спеціального набору правил, називаних DTD-описами (Documents Type Definitions), які використовуються програмою клієнта при розборі документа. Для кожного класу документів визначається свій набір правил, що описують граматику відповідної мови розмітки. За допомогою SGML можна описувати структуровані дані, організовувати інформацію, що утримується в документах, представляти цю інформацію в деякому стандартизованому форматі. Але через деяку свою складність SGML використовувався в основному для опису синтаксису інших мов (найбільш відомим з яких є HTML), і деякі додатки працювали з SGML-документами прямо.

Набагато більш проста і зручний, чим SGML, є мова HTML (от HyperText Markup Language — «язык разметки гипертекста») дозволяє визначати оформлення елементів документа і має якийсь обмежений набір інструкцій - тегів, за допомогою яких здійснюється процес розмітки. Інструкції HTML у першу чергу призначені для керування процесом виводу вмісту документа на екрані програми-клієнта і визначають цим самим спосіб представлення документа, але не його структуру. HTML является компьютерным языком программирования, предназначенным для разработки web-страниц (документов HTML).

Як елемент гіпертекстової бази даних, описуваної HTML, використовується текстовий файл,що може легко передаватися по мережі з використанням протоколу HTTP. Ця особливість, а також те, що HTML є відкритим стандартом, і величезна кількість користувачів має можливість застосовувати можливості цієї мови для оформлення своїх документів, безумовно, уплинули на ріст популярності HTML і зробили його сьогодні головним механізмом представлення інформації в Іnternet.

Однак HTML сьогодні вже не задовольняє повною мірою вимогам, пропонованим сучасними розроблювачами до мов подібного роду. І йому на зміну була запропонована нова мова гіпертекстової розмітки, могутня, гнучка і, одночасно з цим, зручна мова XML(Extensіble Markup Language).

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

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

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

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

Аналіз предметної області

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

1. аналіз концептуальних вимог та iнформацiйних потреб;

2. виявлення iнформацiйних об’єктів та зв’язків між ними;

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

На етапі аналізу концептуальних вимог та iнформацiйних потреб необхідно вирішити такі задачі:

1) аналiз вимог користувача до бази даних (концептуальних вимог);

2) виявлення задач, що мають мiсце, при обробцi iнформацiї, яка повинна бути представлена у базi даних (аналiз додаткiв);

3) виявлення перспективних задач (перспективних додаткiв);

4) документування результатiв аналiзу.

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

Основні моменти аналізу предметної області

Основні задачі (додатки) які при цьому виникають: Так, виходячи із специфіки діяльності читального залу, необхідно 1) забезпечити облік книг, що є в наявності, 2) виконувати швидкий пошук творів, що входять до складу тих чи інших книг.

Вимоги й підходи до інфологічного проектування

При проектуванні на інфологічному рівні створюється інформаційно-логічна модель (ИЛМ), що повинна відповідати таким вимогам: - забезпечення найбільш природних для людини способів збору й подання тієї… - коректність схеми БД, тобто адекватне відображення модельованої ПО;

Контрольні запитання.

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

2. Три фази аналізу предметної області.

3. Перелічіть задачі етапу аналiзу концептуальних вимог та iнформацiйних потреб.

4. Назвіть задачі етапу виявлення iнформацiйних об'єктiв та зв'язкiв мiж ними.

 

 

МОДЕЛЬ «СУТНІСТЬ – ЗВ’ЯЗОК» або

ER-МОДЕЛЬ ПРЕДМЕТНОЇ ОБЛАСТІ

Основні елементи моделі «сутність-зв'язок»

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

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

Основними конструктивними елементами інфологічних моделей є сутності, зв'язки між ними та їхні властивості (атрибути).

Слід розрізняти такі поняття, як тип сутності і екземпляр сутності. Поняття типу сутності відноситься до набору однорідних особистостей, предметів,… Атрибут - пойменована характеристика сутності. Його найменування повинно бути… Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про сутність ( в рамках певної…

Основні риси моделі "сутність-зв'язок" (ER-моделі).

В звичайних випадках для побудови концептуальної схеми використовують традицiйнi методи агрегації та узагальнення. При агрегації декілька… Моделювання предметної області базується на використанні графічних діаграм, що… На використанні різновидів ER-моделі реалізується більшість сучасних підходів до проектування баз даних. ER -модель…

Пр.24

КНИГА --> Cod_book (шифр книги);

ТВІР --> Cod_book (шифр книги), Name_tvir (назва твору);

РОЗДІЛ --> Cod_rozdil (код предметної області).

 

Необхідність введення складеного ключа для сутності ТВІР обумовлено тим, що в читальному залі може бути кілька однакових творів, написаних одним автором, але входять вони до складу різних книг.

Тепер виявимо залежностi, що iснують мiж визначеними нами сутностями, а також визначимо характеристики кожного зв'язку. Зв’язок КНИГА – ТВІР :

Пр.25

Книга має Твір

Книга 1 *--------------------------------------------------------------- Твір2

Книга 2 *--------------------------------------------------------------- Твір 3

Книга 3 *-------------------------------------------------------------- Твір 4

. . . . . .

Книга n *-------------------------------------------------------------- Твір n

КП: ОБОВ'ЯЗКОВИЙ ТИП ЗВ'ЯЗКУ Б:Б КП: ОБОВ'ЯЗКОВИЙ

Рисунок 2.11 – Зображення зв’язку КНИГА – ТВІР

 

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

Тип зв'язку – Б:Б : декілька творів можуть входити до складу однієї книги, та один і той самий твір може знаходитись в декількох книгах.

Зв’язок КНИГА – РОЗДІЛ приведено на рис.2.12.

Пр.26

Книга належить Розділ

Книга 1 *-------------------------------------------------Розділ 1

Книга 2 *-------------------------------------------------Розділ 2

Книга 3 *-------------------------------------------------Розділ 3

. . . . . .

Книга n *-------------------------------------------------Розділ n

КП: ОБОВ'ЯЗКОВИЙ ТИП ЗВ'ЯЗКУ Б:1 КП: ОБОВ'ЯЗКОВИЙ

 

Рисунок 2.12 - Зображення зв’язку КНИГА – РОЗДІЛ

 

З рис.2.12 видно, що клас належності обох сутностей є обов'язковим, оскільки книги, яких немає в читальному залі не повинні заноситись в базу даних, та розділи з предметних областей, що не мають книг, не заносять до бази даних. Хоча це спірно…

Тут тип зв'язку – Б:1 : декілька творів можуть входити до складу одного предметного розділу, але одна книга не може міститися в більше ніж одному розділі.

Розмірковуючи аналогічним чином побудуємо ER-модель предметної області "Читальний зал". В якості сутностей оберемо такі об'єкти предметної області (з перерахуванням ключових атрибутів кожної сутності):

 

Пр.28

КНИГА <Cod_book (шифр книги) >, Cod_client, Publisher, Year_publish, Page.

ТВІР <Cod_book (шифр книги), Name_tvir (назва твору) >, Author, Data_write.

РОЗДІЛ <Cod_rozdil (код предметної області) , Name_rozdil.

КОРИСТУВАЧ < Cod_client (шифр користувача) > , FIO, Address, Telephone,

Pasp, Culture, Profession.

 

Характеристики зв'язків виділених сутностей приведені в табл.2.2,

Пр.29

Таблиця 2.2 - Характеристики зв'язкiв предметної областi "Читальний зал"

 

Ім'я Сутностi 1	Ім'я сутностi 2	Ім'я зв’язку	Тип зв'язку	Клас належностi
Книга	Розділ	Належить	N : 1	Обов'язк., Обов'язк.
Книга	Твір	Має	N : M	Обов'язк., Обов'язк.
Книга	Користувач	Читає	N : 1	Необов'язк., Необов'язк.

 

До числа більш складних елементів моделі відносяться такі:

1. Підтипи і супертипи сутностей. Як у мовах програмування з розвинутими типовими системами (наприклад, у мовах об'єктно-орієнтованого програмування), вводиться можливість спадкування типу сутності, виходячи з одного або декількох супертипів.

2. Зв'язки "many-to-many". Іноді буває необхідно зв'язувати сутності таким чином, що з обох кінців зв'язку можуть бути присутніми декілька екземплярів сутності (наприклад, усі члени кооперативу спільно володіють майном кооперативу). Для цього вводиться різновид зв'язку БАГАТО-З-БАГАТЬМА.

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

4. Каскадні видалення екземплярів сутностей. Деякі зв'язки бувають настільки сильними (звичайно, у випадку зв'язку "ОДИН-ДО-БАГАТЬОХ"), що при видаленні опорного екземпляра сутності (відповідає кінцю зв'язку "ОДИН") потрібно видалити і всі екземпляри сутності, що відповідають кінцю зв'язку "БАГАТО". Відповідну вимогу "каскадного видалення" можна сформулювати при визначенні сутності. Наприклад:

Країна СРСР-- міністр палива СРСР.

5. Домени. Буває корисна можливість визначення потенційно припустимої множини значень атрибута сутності (домену).

 

Ці й інші більш складні елементи моделі даних "сутність-зв'язок" роблять її більш потужною, але одночасно в певній мірі ускладнюють її використання. Звичайно, при реальному використанні ER-діаграм для проектування баз даних необхідно використовувати усі можливості.

Контрольні запитання.

1. Як використовують мову ER-діаграм при побудові інфологічних моделей?

2. Як використовують ER-діаграми при моделюванні предметної області?

3. Визначте головні поняття ER-моделі (сутність, зв'язок, атрибут).

4. Наведіть приклад рекурсивного зв'язку сутності.

5. Як Ви розумієте поняття "атрибут сутності"?

6. Назвіть основні етапи розробки ER-моделі.

7. Які Вам відомі складні елементи моделі?

8. Що Ви розумієте під інфологічною моделлю даних?

9. Що таке даталогічна модель даних?

10. Що Ви розумієте під фізичною моделлю даних?

11. Що є метою інфологічного моделювання?

12. Дайте визначення основних конструктивних елементів інфологічної моделі даних (сутність, екземпляр сутності, атрибут, ключ, зв'язок).

 

 

КЛАСИФІКАЦІЯ СУТНОСТЕЙ

К.Дейт визначає три основні класи сутностей: стрижневі, асоціативні і характеристичні, а також підклас асоціативних сутностей - позначення. Стрижнева сутність (стрижень) - це незалежна сутність. Асоціативна сутність (асоціація) - це зв'язок типу Б:Б між двома або більше сутностями або екземплярами сутності.…

Контрольні запитання.

1. Дайте визначення стрижневої сутності.

2. Що таке асоціативна сутність?

3. Що Ви розумієте під характеристичною сутністю?

4. Як використовують МІМ для опису характеристичної сутності?

5. Дайте визначення позначення.

 

ХАРАКТЕРИСТИКА ЗВ'ЯЗКІВ

Частина схеми отримала назву підсхеми. По суті, підсхема - це деяка організація файлів прикладного програміста. В функції СКБД входить побудова… Схеми і підсхеми представляють в вигляді діаграм, на яких зображують типи… 1) необов'язковий зв'язок: існування об'єктів не залежить від зв'язку;

МОВА ІНФОЛОГІЧНОГО МОДЕЛЮВАННЯ

Для підвищення ілюстративності аналізованих зв'язків застосовується мова інфологічного моделювання (МІМ), у якій сутності й асоціації подають пропозиціями виду:

СУТНІСТЬ (атрибут 1, атрибут 2, ... , атрибут n)

АСОЦІАЦІЯ [СУТНІСТЬ S1, СУТНІСТЬ S2, ...] (атрибут 1, атрибут2, ... , атрибут n)

 

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

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

 

Мовні засоби банку даних

   

Контрольні запитання.

1. Що Ви розумієте під схемою бази даних?

2. Що таке підсхема бази даних?

3. Перелічіть основні типи зв'язків між елементами даних.

4. Які види зв'язків між сутностями Вам відомі?

5. Визначте основні типи асоціацій.

 

ОСНОВИ РЕЛЯЦІЙНОЇ АЛГЕБРИ

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

Селекція.

Нехай задано два відношення , представлені таблицями 4.5, 4.6. Виконаємо над ними операцію об'єднання.   ∩כU

Контрольні запитання.

1. Скільки основних операції використовується в реляційній алгебрі?

2. Чи може відношення мати два однакових кортежі після виконання операцій проекції чи об'єднання?

3. Які основні операції використовуються при знаходженні частки?

4. Як змінюється потужність відношень при виконанні операцій реляційної алгебри?

 

НОРМАЛІЗАЦІЯ СХЕМ БАЗ ДАНИХ

ПОНЯТТЯ КЛЮЧА. ОСНОВНІ ТИПИ КЛЮЧІВ

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

 

(ШИФР ГРУПИ, КІЛЬКІСТЬ СТУДЕНТІВ, ФАКУЛЬТЕТ, СТАРОСТА, КУРАТОР)

 

назвемо ГРУПА, то схема заміщення буде мати атрибути:

ШИФР ГРУПИ, КІЛЬКІСТЬ СТУДЕНТІВ, ФАКУЛЬТЕТ, СТАРОСТА, КУРАТОР.

Формально схема відношення описується таким чином:

 

ІМ'Я_ВІДНОШЕННЯ (A1 , A2 , A3 , ..., AK ), де A1 , A2 , ..., AK - імена атрибутів.

 

Стовпець чи ряд стовпців, значення яких однозначно ідентифікують кожний рядок таблиці, називають ключем. Так, в розглянутому прикладі можливими ключами можуть бути атрибути: ШИФР ГРУПИ, СТАРОСТА. А такі атрибути, як КІЛЬКІСТЬ СТУДЕНТІВ, ФАКУЛЬТЕТ, не можуть бути ключами, оскільки різні студентські групи можуть мати однакову кількість студентів і на одному факультеті вчиться декілька груп.

Якщо відношення має більше одного можливого ключа, тоді має сенс виділити один ключ, який називають первинним (ШИФР ГРУПИ). І навпаки, якщо відношення не має жодного атрибута, який би повністю визначив об'єкт (рядок, кортеж), тоді приходиться мати справу зі складеним ключем, який схематично відображають подвійною горизонтальною рискою.

Наприклад, в відношенні СТУДЕНТ-УСПІШНІСТЬ (табл.4.1) відсутній атрибут, який би однозначно ідентифікував кортеж, оскільки екзамени з одного навчального курсу (фізика) можуть здаватися в декількох семестрах.

 

Таблиця 4.1 - Відношення СТУДЕНТ-УСПІШІСТЬ зі складеним ключем

 

Позначимо атрибути відношення СТУДЕНТ-УСПІШНІСТЬ відповідно:

 

ПІБ СТУДЕНТА - F;

НАЗВА ДИСЦИПЛІНИ - N;

ДАТА ЗДАЧІ ЕКЗАМЕНУ - D;

ОЦІНКА - C;

ЗАЛІК - Z.

 

 

Тоді відношення СТУДЕНТ-УСПІШНІСТЬ, що містить атрибути F, N, D, C, Z, можна представити у вигляді схеми (рис.4.1).

 

 

СТУДЕНТ - УСПІШНІСТЬ

Рис. 4.1- Схематичне представлення відношення СТУДЕНТ-УСПІШНІСТЬ

 

Щоб виділити вказаним способом складений ключ відношення СТУДЕНТ-УСПІШНІСТЬ, потрібно представити домени відношення таким чином, щоб мінімальна кількість атрибутів, які однозначно визначають кортеж, були розміщені на початку схеми. Відношення СТУДЕНТ-УСПІШНІСТЬ прийме вигляд (рис.4.2):

 

СТУДЕНТ -УСПІШНІСТЬ

Рис. 4.2 - Складений ключ

 

Атрибути F і D визначають кожний рядок даної таблиці. Якщо припустити, що можлива здача двох і більше екзаменів одним студентом в один день, тоді атрибути F, D вже не будуть однозначно ідентифікувати кортеж, оскільки даним екземплярам атрибутів F, D може відповідати в таких випадках два і більше кортежі. При цих умовах складений ключ буде містити три атрибути, що схематично зображено на рис 4.3.

 

СТУДЕНТ -УСПІШНІСТЬ

Рис. 4.3 - Складений ключ, який включає три атрибути

 

Можливі випадки, коли складений ключ включає всі атрибути відношення.

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

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

Атомарним є ключ, значення якого сприймається програмою (СКБД) як неподільний елемент даних, навіть якщо він створений з декількох об'єктів. Наприклад, атомарність атрибута ДАТА ЗДАЧІ ЕКЗАМЕНА в відношенні означає неможливість виділення з дати окремо числа, місяця та року.

Повністю складеним називається ключ, що містить декілька атрибутів, причому між цими атрибутами існує відображення (залежність) БАГАТО-ДО-БАГАТЬОХ. Атрибути, що складають такий ключ, не залежать один від одного. Приклад повністю складеного ключа в відношенні СТУДЕНТ-ВИКЛАДАЧ приведено в табл.4.2.

 

Таблиця 4.2 - Приклад відношення з повністю складеним ключем

СТУДЕНТ-ВИКЛАДАЧ

 

Напівскладеним називається ключ, що містить декілька атрибутів, між якими на відміну від повністю складеного ключа існує залежність Б:1(БАГАТО-ДО-ОДНОГО). Тут атрибути в ключі впорядковуються за принципом: кожний наступний уточнює попередній. У відношенні СТУДЕНТ-УСПІШНІСТЬ використовувався напівскладений ключ F, D.

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

Розглянемо приклад, у якому база даних зберігає інформацію про рядових співробітників (таблиця Співробітник) і керівниках (таблиця Керівник) у деякій організації (рис.4.4).

 

Рис. 4.4 - Схематичне представлення зовнішнього ключа

 

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

 

Контрольні запитання.

1. Які основні вимоги висуваються до ключів?

2. Які типи відношень між атрибутами характерні для різних типів ключів?

3. В яких випадках застосовуються зовнішні ключі?

4. Коли ключ включає всі атрибути відношення?

РОЗРОБКА УНІВЕРСАЛЬНОГО ВІДНОШЕННЯ

Основна (друга) фаза аналiзу предметної областi складається з:

Пр.17-А

1. Вибору iнформацiйних об'єктiв;

2. Завдання необхiдних властивостей для кожного об'єкта;

3. Виявлення зв'язкiв мiж об'єктами;

4. Виявлення обмежень, що накладаються на iнформацiйнi об'єкти;

5. Визначення типів зв'язкiв мiж ними;

Визначення характеристик iнформацiйних об'єктiв.

 

При виборi iнформацiйних об'єктiв бажано намагатися вiдповiсти на такi питання:

Пр.17

На якi класи можна розбити данi, що пiдлягають збереженню у базi даних?

Яке iм'я можна присвоїти кожному класу даних?

Якi найбiльш цiкавi характеристики (з точки зору користувача) кожного класу даних можна видiлити?

Якi iмена можна присвоїти вибраним наборам характеристик?

 

Видiлення iнформацiйних об'єктiв - процес iтеративний. Вiн здiйснюється на основi аналiзу iнформацiйних потокiв та iнтерв'ювання споживачiв.

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

 

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

R - є вiдношення над множинами D₁, D₂, ... ,D_s, якщо воно є множиною упорядкованих n-кортежiв вигляду :

 

D1n, d2n, d3n, … , dsn } .

D₁,D₂, ..., D_s - називаються доменами вiдношення R.

 

Вiдношення може бути подане у виглядi файлу або таблицi, стовпцями яких є елементи доменiв, а рядками - кортежi.

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

Кожен атрибут вiдображає вiдповiдну характеристику iнформацiйного об'єкту.

 

Пр.19A

	D1	D2	D3	…	…
R1	{ d11	d21	d31	…	ds1 }
R2	{ d12	d22	d32	…	ds2 }
R3	{ d13	d23	d33	…	ds3}
…	…	…	…	…	…
…	…	…	…	…	…
Rn	{ d1n	d2n	d3n	…	dsn }

 

 

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

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

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

Атрибути, що представляють копiї ключiв iнших вiдношень, називаються зовнішніми ключами.

Атрибут, або набiр атрибутів, що використовуються для бiльш швидкого пошуку називається другорядним iндексом.

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

 

Розглянемо порядок роботи унiверсального відношення при створеннi бази даних для читального залу.

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

 

КНИГА, ТВІР, КОРИСТУВАЧ, РОЗДІЛ.

 

Складемо перелік найбільш суттєвих характеристик кожного інформаційного об'єкта.

Пр.19

КНИГА (шифр книги, рік видання; видавництво, що надрукувало книгу; кількість сторінок, що включає книга ).

ТВІР (назва твору, що входить до складу книги; автор твору; дата створення).

КОРИСТУВАЧ (код користувача, що служить для його швидкої ідентифікації; прізвище, ім'я та по батькові користувача; домашня адреса; номер телефону, домашнього або службового; паспортні дані; освіта; професія).

РОЗДІЛ (код предметної області, назва предметної області).

 

 

Пр.19Б

КНИГА

Шифр

Рік видання

Вид-во

Стор.

…

…

 

 

ТВІР

Назва

Автор

Дата

…

…

 

 

КОРИСТУВАЧ

Код кн.

ПІБ

Адр.

Тел.№

Паспорт

Освіт.

Проф.

…

…

 

РОЗДІЛ

Код п.о.

Назва п.о.

…

…

 

Перерахунок (перелік) вибраних для універсального відношення атрибутів приведено в таблиці 2.1.

Пр.20

Таблиця 2.1 - Початковий перелік атрибутів для формування

Універсального відношення бази даних читального залу.

Шифр книги	Cod_book	Кожна книга має унікальний шифр.
Код розділу	Cod_rozdil	Кожен предметний розділ має унікальний шифр
Назва розділу	Name_rozdil	Назва предметного розділу
Назва твору	Name	Кожен твір має назву
Автор	Author	Письменник, що написав твір.
Дата створення	Data_write	Дата, коли письменник закінчив писати твір.
Дата видання	Year_publish	Дата, коли книгу надрукували.
Видавництво	Publisher	Видавництво, що надрукувало книгу.
Кількість сторінок	Page	Кількість сторінок, що займає книга.
Код користувача	Cod_client	Код користувача книги.
Користувач	FIO	Прізвище, ім'я та по батькові.
Адреса	Address	Адреса користувача.
Телефон	Telephone	Номер телефону користувача.
<Паспорт	№_pasp<	Паспортні дані користувача.
Освіта	Culture	Освіта, яку має користувач.
Професія	Profession	Професія користувача.

 

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

Пр.21

R (Cod_book, Name, Author, Cod_rozdil, Name_rozdil, Data_write, Publisher, Year_publish, Page, Cod_client, FIO, Address, Telephone, №_pasp, Culture, Profession).

Контрольні запитання.

1. Визначте принципи вибору інформаційних об'єктів.

2. Дайте визначення понять: домен, елемент домену, кортеж відношення.

3. У чому полягає різниця між ступенем відношення та його потужністю?

4. Що таке універсальне відношення?

5. Наведіть приклад роботи універсального відношення при створенні бази

даних.

НОРМАЛІЗАЦІЯ

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

При переході до наступної нормальної форми властивості попередніх нормальних властивостей зберігаються.

Визначення 1. Функціональна залежність. У відношенні R атрибут Y функціонально залежить від атрибута X (X і Y можуть… Визначення 2. Повна функціональна залежність.

ФАКУЛЬТЕТ (НАЙМЕНУВАННЯ, ПІБ ДЕКАНА, ТЕЛЕФОН).

 

Відношення ФАКУЛЬТЕТ задано в другій нормальній формі, тому що: { ? }

у відношенні ФАКУЛЬТЕТ атрибут ТЕЛЕФОН, який не є основним, повністю залежить від будь-якого можливого ключа: НАЙМЕНУВАННЯ, ПІБ ДЕКАНА.

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

Розглянемо відношення:

 

СТУДЕНТ - КУРС_ПРОЕКТ (НОМЕР_ЗАЛІКОВОЇ_КНИЖКИ, КОД_ПРЕДМЕТУ, ПРІЗВИЩЕ_СТУДЕНТА, НОМЕР_ГРУПИ, ВИКЛАДАЧ, ПРОЦЕНТ_ВИКОНАННЯ).

Припустимо, що в одній групі можуть навчаються однофамільці. Тоді для цього відношення можливий тільки один ключ: НОМЕР_ЗАЛІКОВОЇ_КНИЖКИ, КОД_ПРЕДМЕТУ. Виходячи з прийнятого припущення, атрибут ПРІЗВИЩЕ_СТУДЕНТА не входить у ключ. Тоді атрибут НОМЕР_ЗАЛІКОВОЇ_КНИЖКИ не визначається значенням атрибута ПРІЗВИЩЕ_СТУДЕНТА, тобто атрибути ПРІЗВИЩЕ_СТУДЕНТА і НОМЕР_ГРУПИ не є основними, але функціонально залежать від основного атрибута НОМЕР_ЗАЛІКОВОЇ_КНИЖКИ, що входить у складовий ключ. Функціональні залежності між атрибутами цього відношення показані на рис.4.7.

 

Рисунок 4.7 - Функціональна залежність

 

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

 

 

Розглянемо приклад схеми відношення:

 

СПІВРОБІТНИКИ - ВІДДІЛИ - ПРОЕКТИ

(СПІВРОБ_НОМЕР, СПІВРОБ_ЗАРП, ВІДДІЛ_НОМЕР, ПРО_НОМЕР, СПІВРОБ_ЗАВДАННЯ)

 

У відношенні використані скорочення : СПІВРОБ - співробітник, ЗАРП - зарплата, ПРО - проект.

Первинний ключ:

СПІВРОБ_НОМЕР, ПРО_НОМЕР.

 

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

СПІВРОБ_НОМЕР -> СПІВРОБ_ЗАРП

СПІВРОБ_НОМЕР -> ВІДДІЛ_НОМЕР

ВІДДІЛ_НОМЕР -> СПІВРОБ_ЗАРП

СПІВРОБ_НОМЕР, ПРО_НОМЕР -> СПІВРОБ_ЗАВДАННЯ.

Хоча первинним ключем є складовий атрибут СПІВРОБ_НОМЕР, ПРО_НОМЕР, атрибути СПІВРОБ_ЗАРП і ВІДДІЛ_НОМЕР функціонально залежать від частини… В результаті, неможливо вставити у відношення СПІВРОБІТНИКИ - ВІДДІЛИ -… Виконаємо декомпозицію відношення СПІВРОБІТНИКИ - ВІДДІЛИ в два відношення СПІВРОБІТНИКИ - ВІДДІЛИ і СПІВРОБІТНИКИ -…

СПІВРОБ_НОМЕР

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

СПІВРОБ_НОМЕР -> СПІВРОБ_ЗАРП

СПІВРОБ_НОМЕР -> ВІДДІЛ_НОМЕР

ВІДДІЛ_НОМЕР -> СПІВРОБ_ЗАРП

 

СПІВРОБІТНИКИ - ПРОЕКТИ (СПІВРОБ_НОМЕР, ПРО_НОМЕР, СПІВРОБ_ЗАВДАННЯ)

 

Первинний ключ:

СПІВРОБ_НОМЕР, ПРО_НОМЕР

Функціональна залежність: СПІВРОБ_НОМЕР, ПРО_НОМЕР -> СПІВРОБ_ЗАВДАННЯ

Відношення R знаходиться в третій нормальній формі (3НФ) у тому і тільки в тому випадку, якщо знаходиться в 2НФ і кожний неключовий атрибут… Наприклад, відношення: ГУРТОЖИТОК (ПІБ_СТУДЕНТА, НОМЕР_ГРУПИ, НОМЕР_КІМНАТИ, СТАРОСТА_КІМНАТИ)

ЗБЕРІГАННЯ (ФІРМА, СКЛАД) та

ОБ'ЄМ (СКЛАД, ОБ'ЄМ).

 

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

Розглянемо наступний приклад схеми відношення:

 

СПІВРОБІТНИКИ - ПРОЕКТИ (СПІВРОБІТНИКА_НОМЕР, СПІВРОБІТНИКА_ПРИЗВІЩЕ, ПРОЕКТУ_НОМЕР, СПІВРОБІТНИКА_ЗАВДАННЯ)

 

Можливі ключі (важливо, що на цій стадії нормалізації до уваги приймається існування можливих ключів):

 

СПІВРОБІТНИКА_НОМЕР, ПРОЕКТУ_НОМЕР

СПІВРОБІТНИКА_ПРИЗВІЩЕ, ПРОЕКТУ_НОМЕР.

 

 

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

 

СПІВРОБІТНИКА_НОМЕР -> СПІВРОБІТНИКА_ПРИЗВІЩЕ;

СПІВРОБІТНИКА_НОМЕР -> ПРОЕКТУ_НОМЕР;

СПІВРОБІТНИКА_ПРИЗВІЩЕ -> СПІВРОБІТНИКА_НОМЕР;

СПІВРОБІТНИКА_ПРИЗВІЩЕ -> ПРОЕКТУ_НОМЕР;

СПІВРОБІТНИКА_НОМЕР, ПРОЕКТУ_НОМЕР -> СПІВРОБІТНИКА_ЗАВДАННЯ;

СПІВРОБІТНИКА_ПРИЗВІЩЕ, ПРОЕКТУ_НОМЕР -> СПІВРОБІТНИКА_ЗАВДАННЯ.

 

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

 

ОСНОВНІ НОРМАЛЬНІ ФОРМИ ВІДНОШЕНЬ

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

СПІВРОБІТНИКИ (СПІВРОБІТНИКА_НОМЕР, СПІВРОБІТНИКА_ПРИЗВІЩЕ).

 

Можливі ключі:

 

СПІВРОБІТНИКА_НОМЕР;

СПІВРОБІТНИКА_ПРИЗВІЩЕ.

 

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

 

СПІВРОБІТНИКА_НОМЕР -> СПІВРОБІТНИКА_ПРИЗВІЩЕ;

СПІВРОБІТНИКА_ПРИЗВІЩЕ -> СПІВРОБІТНИКА_НОМЕР.

СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВРОБІТНИКА_НОМЕР, ПРОЕКТУ_НОМЕР, СПІВРОБІТНИКА_ЗАВДАННЯ).

 

Можливий ключ:

 

СПІВРОБІТНИКА_НОМЕР, ПРОЕКТУ_НОМЕР.

 

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

 

СПІВРОБІТНИКА_НОМЕР, ПРОЕКТУ_НОМЕР -> СПІВРОБІТНИКА_ЗАВДАННЯ.

 

Можлива альтернативна декомпозиція, якщо вибрати за основу СПІВРОБІТНИКА_ПРИЗВІЩЕ. В обох випадках отримані відношення СПІВРОБІТНИКИ і СПІВРОБІТНИКИ - ПРОЕКТИ знаходяться в БКНФ, і їм не властиві відзначені аномалії.

Розглянемо відношення

 

R (МІСТО, АДРЕСА, ІНДЕКС).

 

Атрибут ІНДЕКС визначає індекс відділення зв'язку, яке обслуговує адресатів деякої вулиці міста, АДРЕСА - назву вулиці і номеру будинку. При цьому будемо припускати, що кортеж (С, S, Z) належить деякому відношенню зі схемою відношення R, якщо тільки в місті С є будинок за адресою S і Z є відповідним поштовим індексом. У цьому випадку мають місце такі функціональні залежності:

 

МІСТО, АДРЕСА -> ІНДЕКС;

ІНДЕКС -> МІСТО.

 

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

 

МІСТО, АДРЕСА і AДРЕСА, ІНДЕКС .

 

Схема відношення R (МІСТО, АДРЕСА, ІНДЕКС) не знаходиться в нормальній формі Бойса-Кода, так як має місце залежність ІНДЕКС -> МІСТО. Декомпозицією відношення його можна привести до нормальної форми Бойса-Кода.

Розглянемо приклад схеми відношення:

 

ПРОЕКТИ ( ПРОЕКТУ_НОМЕР, ПРОЕКТУ_СПІВРОБ, ПРОЕКТУ_ЗАВДАННЯ).

 

Відношення ПРОЕКТИ містить номера проектів, кожний проект - список співробітників, які можуть виконувати проект, і список завдань, які передбачаються проектом. Співробітники можуть брати участь у декількох проектах, і різні проекти можуть включати однакові завдання.

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

 

ПРОЕКТ_НОМЕР, ПРОЕКТ_СПІВРОБ, ПРОЕКТ_ЗАВДАННЯ

 

і немає ніяких інших детермінантів. Отже, відношення ПРОЕКТИ знаходиться в БКНФ. Але при цьому воно має аномалії: якщо, наприклад, деякий співробітник приєднується до даного проекту, необхідно вставити у відношення ПРОЕКТИ стільки кортежів, скільки завдань у ньому передбачено.

У відношенні R (A, B, C) існує багатозначна залежність (multi-valued dependence - MVD) (R.A ->-> R.B) в тому і тільки в тому випадку, якщо множина значень B, що відповідає парі значень A і C, залежить тільки від A і не залежить від С.

У відношенні ПРОЕКТИ існують наступні дві багатозначні залежності:

 

ПРОЕКТ_НОМЕР ->-> ПРОЕКТ_СПІВРОБ;

ПРОЕКТ_НОМЕР ->-> ПРОЕКТУ_ЗАВДАННЯ.

 

Неважко показати, що в загальному випадку у відношенні R (A, B, C) існує багатозначна залежність A ->-> B у тому і тільки в тому випадку, коли існує багатозначна залежність A ->-> C.

Відношення R знаходиться в четвертій нормальній формі (4НФ) у тому і тільки в тому випадку, якщо у випадку існування багатозначної залежності A ->-> B всі інші атрибути R функціонально залежать від A.

У нашому прикладі можна виконати декомпозицію відношення ПРОЕКТИ на два відношення ПРОЕКТИ-СПІВРОБІТ і ПРОЕКТИ-ЗАВДАННЯ:

 

ПРОЕКТИ-СПІВРОБІТ (ПРОЕКТ_НОМЕР, ПРОЕКТ_СПІВРОБІТ);

ПРОЕКТИ-ЗАВДАННЯ (ПРОЕКТ_НОМЕР, ПРОЕКТ_ЗАВДАННЯ).

 

Обидва ці відношення знаходяться в 4НФ.

Розглянемо ще один приклад. Нехай задано відношення

 

R (СТУДЕНТ, ТОВАРИСТВО, СУСПІЛЬНА_РОБОТА, РІК).

 

Атрибут ТОВАРИСТВО визначає назву товариств, членом яких є студент; атрибути СУСПІЛЬНА_РОБОТА І РІК - найменування суспільних доручень, виконуваних студентом, і рік їх призначення. Передбачається, що те саме суспільне навантаження не може бути призначена двічі протягом одного року тому ж самому студенту, але заміна одного навантаження на інше протягом року допускаються. У табл.4.16 приведений фрагмент відношення.

 

Таблиця 4.16. - Приклад відношення з нетривіальними залежностями

 

Виділимо нетривіальні багатозначні залежності:

 

СТУДЕНТ ->-> ТОВАРИСТВО;

СТУДЕНТ ->-> (СУСПІЛЬНА_РОБОТА, РІК).

 

Вважаємо, що атрибут ТОВАРИСТВО не залежить від того, яку суспільну роботу веде студент. Атрибути СУСПІЛЬНА_РОБОТА і РІК взаємозалежні.

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

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

 

Таблиця 4.17 - Приклад відношення в четвертій нормальній формі

 

Таблиця 4.18 - Приклад відношення четвертій нормальній формі

 

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

Розглянемо відношення

 

СПІВРОБІТНИКИ - ВІДДІЛИ - ПРОЕКТИ (СПІВРОБ_НОМЕР, ВІДДІЛУ_НОМЕР, ПРОЕКТУ_НОМЕР).

 

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

Відношення R (X, Y, ..., Z) задовольняє залежності з'єднання * (X, Y, ..., Z) у тому і тільки в тому випадку, коли R відновлюється без втрат шляхом з'єднання своїх проекцій на X, Y, ..., Z.

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

Введемо наступні імена складових атрибутів:

З = {СПІВРОБ_НОМЕР, ВІДДІЛУ_НОМЕР};

СП = {СПІВРОБ_НОМЕР, ПРОЕКТУ_НОМЕР};

ВП = {ВІДДІЛУ_НОМЕР, ПРОЕКТУ_НОМЕР}.

Припустимо, що у відношенні СПІВРОБІТНИКИ - ВІДДІЛИ - ПРОЕКТИ існує залежність з'єднання: * (З, СП, ОП).

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

 

СПІВРОБІТНИКИ - ВІДДІЛИ (СПІВРОБ_НОМЕР, ВІДДІЛУ_НОМЕР),

СПІВРОБІТНИКИ - ПРОЕКТИ (СПІВРОБ_НОМЕР, ПРОЕКТУ_НОМЕР),

ВІДДІЛИ - ПРОЕКТИ (ВІДДІЛУ_НОМЕР, ПРОЕКТУ_НОМЕР).

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

 

На закінчення приведемо послідовність етапів нормалізації:

1. Перехід від структурної моделі даних до плоских двовимірних відношень (таблиць).

2. Усунення всіх неповних залежностей атрибутів, які не є основними, від усіх ймовірних ключів.

3. Усунення всіх транзитивних залежностей атрибутів, які не є основними, від усіх ймовірних ключів.

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

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

Контрольні запитання.

1. Для чого виконується нормалізація відношень?

2. Які залежності між атрибутами називають транзитивними та функціонально повними?

3. Приведіть приклади відношень в різних нормальних формах.

4. Приведіть послідовність етапів нормалізації.

 

 

 

АДМІНІСТРУВАННЯ ДАНИХ

Завдання адміністрування даних.

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

Користувачі банків даних

існує в часі й у просторі. Він має визначені стадії свого розвитку: 1. Проектування.

Основні функції групи адміністратора БД

2. Проектування структури БД: визначення складу і структури файлів БД і зв'язків між ними, вибір методів упорядкування даних і методів доступу до… 3. Завдання обмежень цілісності при описі структури БД і процедур обробки… - завдання декларативних обмежень цілісності, властивих предметної області;