13230

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

Лабораторная работа

Информатика, кибернетика и программирование

МЕТОДИКА ПРОЕКТУВАННЯ ПРОСТИХ РЕЛЯЦІЙНИХ БАЗ ДАНИХ За матеріалами книги Glenn A. Jackson Relational Database Design With Microcomputer Applications У 1965 р. зявилися перші результати в області управління базами даних роботи Чарльза Бахмана. З тієї пори технології баз даних пройшли ве

Украинкский

2013-05-11

1018 KB

4 чел.

МЕТОДИКА ПРОЕКТУВАННЯ

ПРОСТИХ РЕЛЯЦІЙНИХ БАЗ ДАНИХ

За матеріалами книги  Glenn A. Jackson  

"Relational Database Design With Microcomputer Applications"

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

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

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

                                                                                                                                                                                                                                                                                                                                                                                                                                          

ПЕРЕДМОВА

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

Початківцю реляційна БД представляється як набір таблиць (насправді відношень, як буде показано пізніше). Якщо ці таблиці спроектовані некоректно, дані в БД можуть бути помилково змінені або видалені при використанні СУБД. Тут можуть виникнути наступні типові проблеми:

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

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

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

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

Представлений в досить стислому об'ємі матеріал буде корисний будь-якому початкуючому проектувальнику БД. Книга може послужити довідником для керівного персоналу, який відповідає за створення конкретних прикладних СУБД.


1. БАЗИ ДАНИХ, ВІДНОШЕННЯ І РЕЛЯЦІЙНІ БАЗИ ДАНИХ

1.1. Базові концепції

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

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

Рис. 1.1. Основні компоненти архітектури СУБД.

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


1.2. Визначення відношення

Математично відношення означається наступним чином:

Нехай дано "N" множин Dl, D2 ...,DN, тоді R є відношення над цими множинами, якщо R є множина впорядкованих n-кортежей виду <d1, d2, ..., dn>, де d1 - елемент з D1, d2 - елемент з D2... і dn - елемент з DN. Dl, D2 ..., DN називаються доменами відношення R.

Рис. 1.2. Відношення з математичної точки зору.

Значення даного визначення найбільш просто пояснити графічно (Рис. 1.2). Тут показано 4 домени. Домен D1 - це множина цілих чисел; D2 - символьних рядків, що є назвами предметів; D3 - символьних рядків, що є назвами кольорів; D4 - ще одна множина цілих чисел. Відношення R складається з 6-ти кортежів. Кожний кортеж - з 4 елементів, які вибираються кожний з свого домена. Зверніть увагу на порядок елементів в кортежі: перший елемент кожного кортежу вибраний з домена D1, другий елемент - з домена D2 і т.д.

Рис. 1.3. Відношення з погляду обробки даних

Погляд на відношення з погляду обробки даних характеризує Рис. 1.3. Чотири домени, представлені на Рис. 1.2, співвідносяться з чотирма елементами реального світу: номером деталі, її назвою, кольором і вагою. Відношення приймає вид таблиці або файлу, де кортежі - рядки таблиці або записи у файлі.

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

Наступні набори термінів використовуватимуться по черзі:

1) відношення, таблиця і файл;

2) кортеж, рядок і запис;

3) атрибут, стовпець і поле;

так само як і в більшій частині документації по мікрокомп'ютерних БД.

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

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

1.3. Визначення реляційної БД

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

Ця база містить три типи інформації про будівельну компанію:

1. Інформація про постачальників, що поставляють деталі підприємству. Сюди відносяться номер постачальника (передбачається унікальним), а також його прізвище, статус і місце проживання (не є унікальними). Ця інформація міститься у відношенні ПОСТАЧАЛЬНИК.

Деталь

Дном

Дназв

Колір

Вага

101

болт

чорний

3

102

муфта

синій

9

103

гвинт

червоний

11

104

гайка

зелений

4

105

муфта

червоний

13

106

болт

оранжевий

21

Постачальник

Пном

Пфам

Статус

Місто

П1

Сміт

20

Лондон

П2

Джонс

15

Детройт

ПЗ

Еддер

10

Чікаго

П4

Хаус

30

Париж

П5

Блейк

20

Париж

ПД

Пном

Дном

шт

П1

101

9

П1

102

4

П1

103

2

П1

106

3

П2

101

3

П2

102

8

П2

105

11

П2

106

9

ПЗ

101

7

ПЗ

102

13

ПЗ

103

6

ПЗ

104

1

ПЗ

105

2

ПЗ

106

5

П4

103

7

П4

106

13

П5

103

8

П5

104

9

Рис. 1.4. База даних Постачальник-Деталі.

2.  Інформація про деталі, що використовуються на підприємстві. Сюди відносяться номер деталі, що є унікальним, назва, колір і вага, що не є унікальними. Ця інформація міститься у відношенні ДЕТАЛЬ.

3. Інформація про номери і кількість деталей від кожного постачальника. Ця інформація міститься у відношенні ПД.

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

Набір атрибутів, що використовується як індекс, називається первинним ключем відношення. Первинний ключ визначається як такий атрибут, або набір атрибутів, який може бути використаний для однозначної ідентифікації конкретного кортежу. Первинний ключ не повинен мати додаткових атрибутів. Це значить, що якщо одиничний довільний атрибут виключити з первинного ключа, атрибутів, що залишилися, буде недостатньо для однозначної ідентифікації окремих кортежів. В БД Постачальник-Деталі первинними ключами є <Пном> для відношення ПОСТАЧАЛЬНИК, <Дном> для відношення ДЕТАЛЬ і пара атрибутів <Пном, Дном> для відношення ПД.

Можна переконатися, що кожний первинний ключ є достатнім для однозначної ідентифікації кожного кортежу у відношенні. Наприклад, відносно ПД, якщо Пном - П1 і Дном - 101, можна знайти не більше одного кортежу з вказаними значеннями атрибутів. На Рис. 1.4 дані значення містить кортеж <П1, 101, 9>. Спроба зберегти інший кортеж з тим же первинним ключем, скажімо, <П1, 101, 11>, приводить до виникнення конфліктної ситуації, оскільки стає незрозумілим скільки деталей з номером 101 поставляє П1 - 9 або 11 (а може 9+11=20?). В повністю розробленій СУБД при спробі користувача записати кортеж, що має первинний ключ, співпадаючий з первинним ключем іншого кортежу, вже включеного у відношення, генерується повідомлення про помилку. В багатьох реалізаціях СУБД, призначених для мікрокомп'ютерів, кортежі із співпадаючими первинними ключами і навіть повністю ідентичні кортежі можна занести у відношення, і це не приводить до виникнення помилки СУБД. У зв'язку з цим можуть виникнути деякі проблеми.

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

Постачальник (індексний файл)                        Постачальник (файл даних)

Номер запису

Файл "Постачальник"

Номер
эапису

Пном

Номер
эапису

Дном

Пфам

Статус

Місто

0001

П1

0006

0001

П4

Вітер

30

Тернопіль

0002

П2

0004

0002

П5

Бурак

20

Тернопіль

0003

ПЗ

0003

0003

ПЗ

Едер

10

Дрогобич

0004

П4

0001

0004

П2

Дідух

15

Стрий

0005

П5

0002

0005

Цей запис було видалено

0006

П1

Шульга

20

Варшава

Рис. 1.5. Простий приклад індексного файлу

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

  Назва БД: Постачальник_Деталі 

 Атрибути і тип:

Пном  симв(3),

Пфам   симв(6),

статус   цілий,

місто   симв(10),

Дном     цілий,

Дназ    симв(6),

колір    симв(6),

вага    цілий,

шт     цілий.

Відношення і <Первинні ключі>:

Постачальник(Пном, пфан, статус, місто)   

<Пном>,

ПД(Пном, Дном, шт)   

<Пном, Дном>,

Деталь(Дном, Дназв, колір, вага)   

<Дном>.

Рис. 1.6. Концептуальна модель БД Постачальник-Деталі.

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

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

Первинний ключ, визначений для відношення, настільки важливий, що атрибути або набір атрибутів, що формують первинний ключ, як правило певним чином позначаються при математичній формі запису відношень. В даному випадку атрибути, що формують первинний ключ, підкреслюються. Наприклад, визначене на Рис. 1.6 відношення ПД буде записане, у вигляді ПД(Пном, Дном, шт). Це означає, що пара атрибутів <Пном, Дном> є первинним ключем для даного відношення.                                                                                                                                                                                                                                                


НЕОБХІДНІСТЬ ПРОЕКТУВАННЯ БАЗ ДАНИХ

2.1. Цілі проектування

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

1. Можливість   зберігання   всіх   необхідних даних в БД.

2. Виключення надмірності даних.

3. Зведення числа збережених в БД відношень до мінімуму.

4. Нормалізація відношень для спрощення рішення проблем, пов'язаних з оновленням і видаленням даних.

Мета 1: Можливість зберігання всіх необхідних даних в БД

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

Мета 2: Виключення надлишковості даних

Сутність цієї мети зовсім не очевидна для початкуючого проектувальника БД. Ключ до її розуміння полягає у з'ясуванні чіткої відмінності між дублюванням даних і надмірним дублюванням даних. Наприклад, звернемося до відношення С-Н, приведеного на Рис. 2.1 (а). Відношення має два атрибути - Слжб# (табельний номер службовця) і Начк (начальник). У відношенні містяться дані, які вказують на безпосереднього начальника кожного службовця підприємства. Прізвища начальників можуть неодноразово з'являтися у відношенні. Насправді прізвище начальника з'являється один раз для кожного підлеглого йому службовця. Зверніть увагу, на те, що хоча "Мельник" і "Гірняк" з'являються двічі в екземплярі С-Н, наведеному в на Рис. 2.1 (а), жодне з дубльованих прізвищ не є надмірним. Причина відсутності надмірності полягає в тому, що при видаленні одного з прізвищ з відношення буде загублена інформація. Наприклад, на Рис. 2.1(6) показано вигляд екземпляра відношення С-Н при видаленні дубльованих прізвищ. В цьому випадку немає можливості довідатися про прізвища начальників службовців з номерами #195 і #200.

С-Н       С-Н

Слжб#

Начк

Слжб#

Начк

125

Мельник

125

Мельник

138

Гірняк

138

Гірняк

195

Гірняк

195

200

Мельник

200

Рис. 2.1. Дубльовані дані, що не є надмірними

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

  

 

   С-Н-Т    С-Н-Т

Слжб#

Начк

Нтел

Cлжб#-

Начк

Нтел

125

Мельник

3051

125

Мельник

3051

138

Гірняк

2222

138

Гірняк

2222

195

Гірняк

2222

195

Гірняк

200

Мельник

3051

(а)      (б)

200

Мельник

С-Н

Слжб#

Начк

125

Мельник

138

Гірняк

195

Гірняк

200

Мельник

Н-Т

Начк

Нтел

Мельник

3051

Гірняк

2222

 (в)

Рис. 2.2. Виключення надлишкових даних.

Зрозуміло, що телефонні номери Мельника і Гірняка не загублені, оскільки кожний з них виявляється в одному з кортежів відношення. Даний метод управління надмірністю незадовільний з двох причин. По-перше, порожніх полів в БД слід уникати, оскільки необхідні додаткові зусилля при програмуванні, направлені на визначення реальних значень "нулів". В даному випадку читання третього кортежу <195,Гірняк,-> відношення не дозволяє встановити телефонний номер Гірняка. Користувач повинен уміти знаходити у відношенні інший кортеж, для якого значенням атрибута Начк є Гірняк, а значення атрибута Нтел не є нульовим. По-друге, що більш важливо, відношення, представлене на Рис. 2.2(6), має структуру, що загрожує виникненням серйозних проблем при видаленні інформації. Якщо службовець з номером Слжб# = 125 звільняється з підприємства і кортеж <125, Мельник, 3051> буде видалений з відношення при належній реєстрації факту звільнення, відбудеться втрата телефонного номера Мельника, оскільки ніде більше у відношенні він не представлений.

Рис. 2.2 (в) показує кращий спосіб виключення надмірності телефонних номерів. Тут відношення С-Н-Т замінюється двома відношеннями, одне з яких містить інформацію про табельні номери службовців і прізвища керівників, а інше - інформацію про телефонні номери начальників. В наступному розділі буде показано, що розбиття відношень є стандартною процедурою проектування, яка повинна здійснюватися при дотриманні певних обмежень. Як випливає з Рис. 2.2 (в), службовець з номером #125 тепер може бути видалений з відношення С-Н без втрати номера телефону колишнього начальника цього службовця, що зберігається у відношенні Н-Т.

Мета 3: Зведення числа відношень, які зберігаються в БД до мінімуму

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

Мета 4: Нормалізація відношень

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

Цілі 3 і 4 суперечать одна одній, тому тут потрібен взаємний компроміс. Це буде частиною завершального етапу проектування.

2.2. Універсальне відношення

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

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

Сном: Номер студента. Ціле значення, унікальне для кожного студента університету.

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

Кном: Номер кімнати в гуртожитку містечка. Кожний студент живе на території містечка і має кімнату. В одній кімнаті може проживати більше одного студента.

Тном: Номер телефона студента. Кожна кімната гуртожитку має один телефон і ним користуються всі студенти, що проживають у цій кімнаті.

Курс: Номер курсу. Це ідентифікаційний номер курсу, відвідуваного студентом. Прикладом може служити номер МТН122. Консультант зберігатиме дані тільки про курси, завершені студентом.

Семестр: Університетський семестр. Є семестром, в якому даний курс був завершений студентом. Можливо, що студент вивчав один і той же курс в різних семестрах.

Оцінка: Оцінка за курс. Оцінка, отримана студентом за певний курс в даному семестрі.

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

КОНСУЛЬТАНТ

Сном

Спрізв

Кном

Тном

Курс

Семестр

Оцінка

3215

Дзера Г.

120№5

2136

МАТ122

О84

1.6

ФІЛ120

О84

2.4

ФІЗ230

З85

2.1

МАТ122

З85

2.3

3462

Сушко А.

238№11

2344

МАТ122

З84

2.3

МАТ123

З85

3.5

БДЗ220

З85

3.7

3567

Хомин Д.

120№5

2136

ФІЛ239

З84

3.3

ЗІ171

О84

3.5

ФІЗ141

О84

1.8

4756

Антонюк В.

345№11

3321

КРП389

О83

4.0

Рис. 2.3. Дані, необхідні консультанту.

3215

Дзера Г.

120№5

2136

МАТ122

О84

1.6

ФІЛ120

О84

2.4

ФІЗ230

В85

2.1

МАТ122

З85

2.3

Рис.  2.4.  Один   "рядок"  таблиці,  наведеної  на Рис. 2.3.

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

КОНСУЛЬТАНТ

Сном

Спрізв

Кном

Тном

Курс

Семестр

Оцінка

3215

Дзера Г.

120№5

2136

МАТ122

О84

1.6

3215

Дзера Г.

120№5

2136

ФІЛ120

О84

2.4

3215

Дзера Г.

120№5

2136

ФІЗ230

З85

2.1

3215

Дзера Г.

120№5

2136

МАТ122

З85

2.3

3462

Сушко А.

238№11

2344

МАТ122

З84

2.3

3462

Сушко А.

238№11

2344

МАТ123

В85

3.5

3462

Сушко А.

238№11

2344

БДЗ220

В85

3.7

3567

Хомин Д.

120№5

2136

ФІЛ239

В84

3.3

3567

Хомин Д.

120№5

2136

ЗІ171

О84

3.5

3567

Хомин Д.

120№5

2136

ФІЗ141

О84

1.8

4756

Антонюк В.

345№11

3321

КРП389

О83

4.0

Рис. 2.5. Дані з таблиці, наведеної на Рис. 2.3, поміщені в коректне відношення

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

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

Початкуючий проектувальник, намагатиметься застосовувати відношення КОНСУЛЬТАНТ (Рис. 2.5) як завершену БД. Це виглядає достатньо послідовним. Навіщо розбивати відношення КОНСУЛЬТАНТ на декілька більш дрібних відношень, якщо воно здатне містити в собі усі дані? Існує декілька причин, чому не слід використовувати дане відношення як єдине в БД. Це обумовлено тим, як використовуватиметься БД, і яку дію на дані у відношенні КОНСУЛЬТАНТ матимуть певні операції. Розрізняються три специфічні проблеми:

  •  проблема, пов'язана з оновленням (модифікацією) даних в БД;
  •  проблема, обумовлена необхідністю видалення кортежів;
  •  проблема, обумовлена необхідністю включення нових кортежів.

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

Проблема вставки

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

На Рис. 2.6 (а) показано приклад того, як виглядатиме відношення КОНСУЛЬТАНТ у разі примусового включення в нього інформації про студента, що не завершив жодного курсу. Порожні символьні рядки представляються пробільними полями (Курс і Семестр), тоді як нульове чисельне значення в полі Оцінка інтерпретується СУБД як 0.0. Рис. 2.6(6) ілюструє можливі наслідки появи 0.0 за відсутності інформації. Отримана відповідь на запит "Видати список Сном і Спрізв для всіх студентів, що отримали хоча б одну оцінку нижче 2.0". В число таких студентів потрапив Хміль М., хоча він не закінчив жодного курсу.

. use консультант

. list

00001

3215

Дзера Г.

120№5

2136

МАТ122

О84

1.6

00002

3215

Дзера Г.

120№5

2136

ФІЛ120

О84

2.4

00003

3215

Дзера Г.

120№5

2136

ФІЗ230

З65

2.1

00004

3215

Дзера Г.

120№5

2136

МАТ122

З85

2.3

00005

3462

Сушко А.

238№11

2344

МАТ122

З84

2.3

00006

3462

Сушко А.

238№11

2344

МАТ123

З85

3.5

00007

3462

Сушко А.

238№11

2344

БДЗ220

З85

3.7

00008

3567

Хомин Д.

120№5

2136

ФІЛ239

В84

3.3

00009

3567

Хомин Д.

120№5

2136

ЗІ171

О84

3.5

00010

3567

Хомин Д.

120№5

2136

ФІЗ141

О84

1.8

00011

4756

Антонюк В.

345№11

3321

КРП389

О83

4.0

00012

7890

Хміль М.

121№11

7619

0.0

(а)

. display off Сном, Спрізв for Оцінка < 2.0

3215 Дзера Г.

3567 Хомин Д.

7890 Хміль М.

(б)

Рис. 2.6. а - результат вставки запису з порожніми полями;

б - помилковий результат виконання запиту, викликаний наявністю порожніх полів.

Проблема оновлення

У відношенні КОНСУЛЬТАНТ велике число надлишкових даних. Надлишковість даних завжди свідчить про можливість модифікації тільки частини необхідних даних за допомогою операції оновлення.

Відношення КОНСУЛЬТАНТ характеризується як явною, так і неявною надлишковістю. Явна надлишковість полягає в тому, що прізвище даного студента, номер кімнати і номер телефону можуть з'явитися у відношенні кілька разів. В екземплярі відношення КОНСУЛЬТАНТ, наведеному на Рис. 2.5, номер кімнати Г. Дзери  вказується чотири рази. Якщо вона звернеться до свого консультанта і повідомить його про зміну номера її кімнати, то консультант буде вимушений прослідкувати за зміну цього номера у всіх чотирьох кортежах щоб уникнути суперечності даних.

Неявна надлишковість проявляється у тому, що один і той же номер телефону мають всі студенти, які живуть в одній кімнаті. На Рис. 2.5 телефонний номер для кімнати 120№5 з'являється у поєднанні з іменами Дзера Г. і Хомин Д. Припустимо, Г. Дзера  сповістить свого консультанта про те, що її номер телефону змінений на 7777, забувши при цьому повідомити про подругу по кімнаті. Якщо консультант змінить телефонний номер тільки в тих кортежах, які містять номер телефону Г. Дзери, то правильний номер телефону, розташованого в кімнаті 120№5, буде фактично загублений, оскільки у відношенні будуть присутні два різні телефонні номери для однієї кімнати.

Рис. 2.7 ілюструє останню аномалію оновлення. Телефонний номер для Г. Дзери  змінюється на 7777. На Рис. 2.7 наведено відповідь СУБД на запит "Вивести перелік номерів телефонів для кімнати 120№5". Відповідь на запит містить два номери, що свідчить про помилку, оскільки в кожній кімнаті є лише один телефонний апарат з одним телефонним номером. Зверніть увагу, що СУБД виводить на друк дубльовані відповіді на запит. Кожний з телефонних номерів 2136 і 7777 міститься в трьох різних кортежах екземпляра обговорюваного відношення КОНСУЛЬТАНТ, і всі шість значень було роздруковано СУБД. При програмуванні деяких СУБД в них закладається функція придушення дублювання у відповідях на запити, якщо необхідність дублювання не обмовляється спеціально.

. display off Тном for Кном = '120№5'

7777

7777

7777

7777

2136

2136

2136

Рис. 2.7. Помилковий результат виконання запиту, викликаний зміною номера телефону

Проблеми видалення

В екземплярі відношення КОНСУЛЬТАНТ (Рис. 2.5) присутній тільки один кортеж, в якому Сном = 4756. Цей кортеж відповідає студенту з ім'ям Антонюк В. Припустимо, що консультант дізнається, що цей студент не закінчив курс КРП389, як це відзначено, і видаляє цей кортеж з відношення. Оскільки це єдиний кортеж з інформацією про цього студента, його видалення приведе до вилучення студента з БД. Якщо консультант слідом за даною операцією видалення зробить запит списку імен усіх консультованих, що містяться у відношенні КОНСУЛЬТАНТ, то імені Антонюк В. у цьому списку він не знайде.

3. ФУНКЦІОНАЛЬНА ЗАЛЕЖНІСТЬ

3.1. Перша нормальна форма (1НФ)

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

1. З якого джерела Ви одержуєте відношення перед початком процесу?

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

3. Яким чином Ви здійснюватимете розбиття?

4. Що є ознакою завершення процесу розбиття?

Відповіді на ці питання будуть дані в справжньому розділі і більш поглиблений в розд. 4.

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

3.2 Концепція функціональної залежності

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

Функціональна залежність (ФЗ) визначається таким чином:

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

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

А -> В       (Математична форма запису)

(Діаграма або графічна форма запису)

Рис. 3.1.  Два можливі способи запису того,  що атрибут В функціонально залежить від атрибута А

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

Як приклад, знову звернемося до атрибутів відношення КОНСУЛЬТАНТ (Рис. 2.5) і, зокрема, до докладного пояснення того, як ці атрибути зв'язані між собою (розд. 2.2). Після вивчення описів атрибутів може бути виведені залежність, приведена на Рис. 3.2.

(б)

Рис. 3.2. Різні способи подання ФЗ, що існують між атрибутами відношення КОНСУЛЬТАНТ

Міркування, що привели до цих ФЗ, в деталях обговорюються нижче.

1. Номери студентів є унікальними. Кожному студенту призначається номер Сном» причому всі номери різні. Таким чином, якщо ви знаєте Сном студента» ви знаєте, що з ним може бути зв'язано тільки одне прізвище Спрізв; Сном -> Спрізв, Зворотне не є вірним. Спрізв -> Сном не є правильною ФЗ, оскільки декілька студентів можуть мати одне прізвище.

2. Кожний студент прикріплений до однієї кімнати гуртожитку, але в одній кімнаті може проживати більше  ніж  один  студент.  Таким чином,  Сном -> Кном є вірним, а Кном -> Сном - ні.

3. Оскільки в кожній кімнаті тільки один телефон і кожний телефон, у свою чергу, має унікальний номер, одержуємо Кном -> Тном і Тном -> Кном. Дана ситуація звичайно позначається у вигляді Сном <-> Тном, і говорять, що Сном і Тном взаємозалежні.

4. Оскільки в кожній кімнаті тільки один телефон і цей телефон має унікальний номер, отже тільки один телефонний номер може бути пов'язаний з даним студентом, або інакше Сном -> Тном.

5. Остання ФЗ є прикладом складного набору атрибутів, що входять у ФЗ. Залежність Сном, Курс, Семестр -> Оцінка означає, що оцінка однозначно визначається тільки в тому випадку, якщо відомий Сном студента, що вивчає даний Курс в даному Семестрі. (Необхідно пам'ятати, що студент може повторити проходження учбового курсу і отримати при цьому іншу оцінку).

Читачу слід перевірити відношення КОНСУЛЬТАНТ (Рис. 2.5) і переконатися в тому, що дані в цьому відношенні узгоджуються з функціональною залежністю, поданою на Рис. 3.2. Наприклад, відзначимо, що Кном • 120№5 і Тном • 2136 завжди мається свій в розпорядженні пара (Кном <-> Тном); також Сном-3215 пов'язаний тільки з одним прізвищем, саме "Дзера Г.", як і повинно бути, оскільки Сном -> Спрізв. Інші ФЗ слідує верифікувати аналогічним чином. Читачу слід також відзначити, що в екземплярі відношення КОНСУЛЬТАНТ, показаному на Рис. 2.5, тільки один номер Сном пов'язаний з кожним ім'ям Спрізв; проте це не доводить Спрізв -> Сном, що є помилковим. Це говорить тільки про те, що в даний час немає двох консультованих з одним прізвищем. В майбутньому може трапитися так, що двох студентів з одним прізвищем будуть включено у відношення КОНСУЛЬТАНТ.

3.3. Нормальна форма Бойса-Кодда (НФБК)

Досвідченому   проектувальнику   БД   достатньо   побіжного погляду на діаграму, приведену на Рис. 3.2(6), щоб зробити висновок про те, що відношення КОНСУЛЬТАНТ не можна вважати "хорошим". Проектувальник прийде до такого висновку, дивлячись на ФЗ, отримані для відношення КОНСУЛЬТАНТ, і звертаючи увагу на деякі їх небажані властивості. Перед обговоренням цих властивостей необхідно визначити два терміни, що стосуються ФЗ.

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

2.  Детермінант. Якщо А -> В є ФЗ і В не залежить функціонально від будь-якої підмножини А, то говорять, що А є детермінантом В.

З Рис. 3.2 можна зробити висновок, що відношення КОНСУЛЬТАНТ має тільки один можливий ключ, а саме набір атрибутів <Сном,Курс,Семестр>. Цей висновок отриманий шляхом знаходження мінімального набору значень атрибутів, які, якщо вони відомі, визначають значення всіх інших атрибутів кортежу. За допомогою ФЗ, представлених на Рис. 3.2, легко бачити, що один номер Сном визначає Спрізв, Кном і Тном і для визначення Оцінки повинен бути відомий весь набір Сном, Курс і Семестр. Таким чином, якщо відомі значення атрибутів даного вище можливого ключа, то значення всіх інших атрибутів кортежу, що містить вказаний можливий ключ, будуть однозначно специфіковані.

Детермінанти у відношенні КОНСУЛЬТАНТ визначити легко: ними є ліві частини всіх ФЗ у відношенні. Детермінантами в КОНСУЛЬТАНТ є <Сном,Курс,Семестр>, <Сном>, <Кном> і <Тном>. Детермінанти укладені в кутові дужки для того, щоб в даному випадку виділити чотири різні детермінанти. Слід помітити, що взаємна залежність дає два детермінанти.

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

Відношення знаходиться в НФБК, якщо і тільки якщо кожний детермінант відношення є можливим ключем.

Хоча існують нормальні форми більш високого рівня, які накладають навіть більш сильні обмеження на відношення, що розробляються, на практиці більшість проектувальників прагне отримати відношення в НФБК. Ця мета переслідуватиметься і тут.

Відношення    КОНСУЛЬТАНТ не знаходиться в НФБК. Це легко виявити, якщо розташувати поруч  перелік  всіх детермінантів і перелік всіх можливих ключів і подивитися, чи є кожний детермінант можливим ключем.

Можливі ключі відношення КОНСУЛЬТАНТ  

-        Детермінанти відношення КОНСУЛЬТАНТ

<Сном, Курс, Семестр>

< Сном, Курс, Семестр>

<Сном>

<Тном>

<Кном>

Оскільки не кожний детермінант у відношенні КОНСУЛЬТАНТ є можливим ключем, КОНСУЛЬТАНТ не знаходиться в НФБК і його необхідно піддати декомпозиції.

3.4. Загальний підхід до декомпозиції

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

1. Розробка універсального відношення для БД.

2. Визначення всіх ФЗ між атрибутами відношення.

3. Визначення того, чи знаходиться відношення в НФБК. Якщо так, проектування завершується; якщо ні, відношення повинне бути розкладено на два відношення.

4. Повторення кроків 2 і 3 для кожного нового відношення, отриманого в результаті декомпозиції. Проектування завершується, коли всі відношення знаходитимуться в НФБК.

Запропонований вище метод не визначає, як здійснювати декомпозицію відношення, не приведеного до НФБК, на два відношення. Це здійснюється за допомогою ФЗ таким чином:

Хай відношення R(A,B,C,D,E) не приведено до НФБК. Визначається ФЗ, наприклад С -> D, про яку відомо, що вона є причиною того, що відношення R не знаходиться в НФБК. (С є детермінантом, але не є можливим ключем.) Створюються два нових відношення: R1(A,B,C,E) і R2(C,D), де ФЗ С -> D була виділена з R, пропущена при формуванні відношення R1 і використана повністю при формуванні відношення R2. Тепер необхідно перевірити, чи знаходяться в НФБК відношення R1 і R2. Про відношення R2(C,D) говорять, що воно є проекцією відношення R. Цей тип декомпозиції називається декомпозицією без втрат при природному з'єднанні. Вказаний метод декомпозиції може бути використаний на кроці 3 приведені вище алгоритми проектування.

Як приклад використання методу, виконаємо декомпозицію відношення КОНСУЛЬТАНТ. Звертаючись знову до детермінантів і можливих ключів відношення КОНСУЛЬТАНТ, бачимо, що є три детермінанти, що не є можливими ключами:

<сном>, <Тном> і <Кном>.

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

Рис. 3.3. Відношення R1 і R2, отримані в результаті проекції Кном <-> Тном з відношення КОНСУЛЬТАНТ

КОНСУЛЬТАНТ (Сном, Курс. Семестр. Спрізв, Кном, Тном, Оцінка). Кандидатами серед ФЗ для здійснення проекції є:

Сном -> Кном; Сном -> Тном; Кном -> Тном і Тном -> Кном.

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

Простим правилом вибору ФЗ для проекції може служити пошук "ланцюжка ФЗ" вигляду

А -> В -> С

з подальшим використанням для проекції крайньої правої залежності. В нашому випадку таким "ланцюжком" є Сном -> Кном -> Тном і "кінець ланцюжка" Кном -> Тном породжує першу проекцію. Отримані у результаті відношення R1 і R2 наведені на Рис. 3.3 разом з кожною з пов'язаних з ними ФЗ.

Відношення R2 (Khom,Thom) знаходиться в НФБК, оскільки всі його детермінанти є можливими ключами. Відношення R2 не потребує більш декомпозиції. Проте відношення Rl(Cном,Kypc,Ceместр,Спрізв, Кном, Оцінка) не знаходиться в НФБК, оскільки детермінант <Сном> не є можливим ключем. Отже, відношення R1 необхідне піддати подальшому розкладанню. Детермінант <Сном>, через який виникло утруднення, має два залежних від нього атрибута

Сном -> Спрізв, Сном -> Кном

що можна розглядати як одинична ФЗ з складовою правою частиною

Сном -> Спрізв, Кном.

Проекція відношення R1, породжувана цієї ФЗ, приводить до отримання відношень R3 і R4, показаних на Рис. 3.4. Ці два відношення знаходяться в НФБК і разом з відношенням R2 могли б використовуватися при формуванні БД для консультанта. На Рис. 3.5 представлений остаточний вид відношень для такої БД (названої Конс), а також екземпляри кожного відношення з даними, які співпадають з використаними для початкового відношення КОНСУЛЬТАНТ. Звернемо увагу, зокрема, що в процесі декомпозиції автоматично відбулося розбиття початкового  відношення   КОНСУЛЬТАНТ   на   три  логічні компоненти: R2, в якому міститься інформація про кімнати і телефони; R3, в якому міститься інформація про учбові курси і отримані студентами оцінки; R4, в якому міститься інформація про студентів. Таке логічне розбиття є прямим результатом використовування в процесі декомпозиції закладеної у ФЗ інформації, що деталізує те, як різні атрибути в початковому відношенні співвідносяться один з одним.

R3 (Сном, Курс, Семестр, Оцінка)  Можливі ключі 1. (Сном, Курс, Семестр)   Детермінанти 1. (Сном, Курс, Семестр)

                 

R4 (Сном, Спрізв, Кном)   Можливі ключі: 1. (Сном)  Детермінанти 1. (Сном)

Рис. 3.4. Відношення R3 і R4, отримані в результаті проекції Сном -> Спрізв,Кном з відношення R1

3.5. Огляд вихідних аномалій

Час задатися питанням: чи присутні в БД "Конс" ті ж аномалії, які характеризували відношення КОНСУЛЬТАНТ, або декомпозиція автоматично привела до їх усунення? Для того, щоб підтвердити усунення аномалій, - а саме ця мета ставилася в першу чергу при здійсненні декомпозиції, - розглянемо, спираючись на приведену на Рис. 3.5 БД "Конс", проблеми вставки, видалення і оновлення з розд. 2.2.

R2 (Кном, Тном);

R3 (Сном, Курс, Семестр, Оцінка);

R4 (Сном, Спрізв, Тном).

(а)

R3

Сном

Курс

Семестр

Оцінка

3215

МАТ122

О84

1.6

3215

ФІЛ120

О84

2.4

3215

ФІЗ230

З85

2.1

3215

МАТ122

З85

2.3

3462

МАТ122

З64

2.3

3462

МАТ123

З85

3.5

3462

БДЗ220

ЗS5

3.7

3567

ФІЛ239

З84

3.3

3567

ЗІ171

О84

3.5

3567

ФІЗ141

ОB4

1.8

4756

КРП389

О83

4.0

R2

Кном

Тном

120№5

2136

238№11

2344

345№11

3321

R4

Сном

Спрізв

Кном

3215

Дзера Г.

120№5

3262

Сушко А.

238№11

3567

Хомин Д.

120№5

4756

Антонюк В.

345№11

(б)

Рис. 3.5. а - база даних Конс; б - екземпляр БД, в якому використовуються дані,
приведені на Рис. 2.5

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

Оновлення. При використанні відношення КОНСУЛЬТАНТ проблема виникла на етапі зміни консультантом номера телефону пані Г. Дзери на 7777. Результатом цієї зміни з'явилася поява в БД  двох різних телефонних номерів для телефону, встановленого в кімнаті 120№5. В БД Конс телефонні номери розташовуються відносно R2, і кожна кімната може мати тільки один телефонний номер, призначений розташованому в цій кімнаті телефонному апарату. Слід пям'ятати, що номер Кном є первинним ключем відношення R2, а значення первинного ключа за визначенням повинні бути унікальними. Для модифікації телефонного номера Г. Дзери слідує в кортежі відношення R2, в якому Кном – 120№5, змінити номер Тном на 7777. Зверніть увагу на ту обставину, що ця дія полягає в зміні телефонного номера для кімнати, так що для всіх студентів, що живуть в цій кімнаті, телефонний номер також буде змінений. Таким чином, вихідна аномалія оновлення усувається за допомогою НФБК-проектування.

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

Видалення. Коли відношення КОНСУЛЬТАНТ використовувалося як БД, видалення кортежу, який включає значення Сном-4756 і Kypc-КРП389, привело до зникнення з БД студента з номером 4756.

Цього не може відбутися у разі БД Конс, оскільки інформація про оцінки і інформація про студентів загального характеру рознесена в два різні відношення (R3 і R4). При виключенні факту, що студент з номером 4756 відвідував курс КРП389 в семестрі О83, з відношення R3 буде видалений кортеж <4756, КРП389, О83, 4.0>. Ця дія ніяк не позначиться на загальній інформації про студента, збереженій в R4.

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

. USE КОНСУЛЬТАНТ

. DISPLAY КУРС, ОЦІНКА FOR СНОМ = 3452

МАТ122 2.3

МАТ123 3.5

БДЗ22O 3.7

-

(а)

. USE R3

. DISPLAY КУРС, ОЦІНКА FOR СНОМ = 3462

МАТ122 2.3

МАТ123 3.5

ФІЗ220 3.7

-

(би)

Рис. 3.6. Запити при використанні dBase II на виведення переліку оцінок, отриманих студентом з номером 3462 по всіх курсах: а - для відношення КОНСУЛЬТАНТ; б - для БД Конс.

На Рис. 3.6 і 3.7 наведені приклади типових запитів при використовуванні пакету СУБД - як для випадку відношення КОНСУЛЬТАНТ, так і для випадку БД Конс. Запити на Рис. 3.7 для випадку БД Конс складніші в порівнянні з випадком одиничного відношення).

. USE КОНСУЛЬТАНТ

. DISPLAY THOM FOR СНОМ

2136

2136

2136

.

(а)

. SELECT PRIMARY

. USE R4

. SELECT SECONDARY

. USE R2

. JOIN TO TEMP1 FIELDS S.THOM FOR ;

P.СНОМ = 3567 .AND. P.KHOM = S.KHOM

. USE TEMP1

. LIST

2136

. USE

. DELETE FILE TEMP1

FILE HAS BEEN DELETED

.

(би)

Рис. З.7. Запити при використовуванні dBase II на отримання номера телефону студента з номером 3567: а - для випадку відношення КОНСУЛЬТАНТ; би - для випадку БД Конс.

3.6. Інша декомпозиція відношення КОНСУЛЬТАНТ

В розд. 3.4 декомпозицію відношення КОНСУЛЬТАНТ на три відношення була почато проекцією, породжуваної ФЗ:

Кном -> Тном.

Вказана ФЗ була вибрана тому, що була останньою в ланцюжку ФЗ, виявлених на Рис. 3.2:

Сном -> Кном -> Тном.

Уважне вивчення представлених на Рис. 3.2 ФЗ показує, що на цьому малюнку присутній інший ланцюжок залежності з таким же їх числом

Сном -> Тном -> Кном.

Тут крайньої правої ФЗ є Тном -> Кном. Якщо ця ФЗ виділяється першою з відношення КОНСУЛЬТАНТ, то у результаті буде отримана наступна БД в НФБК:

R2 (Тном, Кном)

R3 (Сном, Курс, Семестр, Оцінка)    

R4(Сном, Спрізв)       

Ця БД така ж коректна, як і БД, приведена на Рис. 3.5. Єдина відмінність полягає в тому, що номер Тном став виконувати роль більш важливу, ніж Кном. Тном в даній ситуації використовується як первинний ключ для відношення R2 (а не Кном) і атрибута, зв'язуючого R4 і R2. Два різні рішення однієї проблеми є прямим результатом взаємної залежності, існуючої між атрибутами Тном і Кном. Яке з двох рішень є "кращим" визначається вибором проектувальника і залежить до деякої міри від того, як консультант планує використовувати БД.

3.7. Деякі коментарі до декомпозиційного алгоритму проектування

В розд. 3.4 було сказано, що в процесі проектування за допомогою проекції декомпозицію слід здійснювати шляхом пошуку ланцюжків ФЗ, а саме:

А -> В, В -> С

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

ПОЧАТКОВІ ДАНІ

Відношення: R(A,B,C)

Ф3:  А -> В

В -> С

(А -> С також повинно бути справедливо)

ОДИН МОЖЛИВИЙ ПРОЕКТ

R1(А, С)    R2(A,B)

А -> С      А -> В

Коректні екземпляри R1 і R2

Rl

А

С

9

8

4

3

R2

А

В

9

8

2

2

З'ЄДНАННЯ (JOIN) R1 і R2

А

В

С

9

8

2

2

4

3

Рис. 3.8. Екземпляри відношень, що задовольняють ФЗ відношень R1 і R2, але ФЗ, що суперечать, представленої в початкових специфікаціях

Якщо у вищенаведеному випадку покласти, що обговорюване відношення має вигляд R(A,B,C) і ФЗ А->В вибрана для проекції в першу чергу, то отримані в результаті відношеньи будуть R1 (А, З) і R2 (А,  В).   Хоча   обидва   ці   відношенння   знаходяться   в НФБК, зі всією виразністю виявляється наступна проблема:

Ні відношення R1(А, С), ні R2(A,B) автономно не містять атрибути, присутні у ФЗ В->С, яка є ФЗ початкового відношення. Ця залежність загублена в процесі проектування. З практичної точки зору це означає, що якщо приведені вище відношеньи R1 і R2 будуть використані для створення БД, то не можна буде затверджувати, що некоректні зв'язки між В і С не будуть привнесені в БД. Рис. 3.8 ілюструє виявлену проблему. При з'єднанні R1 і R2 по атрибуту А два значення З (3 і 4) можуть бути співвіднесені з В, що суперечить ФЗ, загубленої в процесі проектування.

Проблема в даному прикладі виникає через проекцію, породженої ФЗ, залежнісна частина якої сама є детермінантом іншої ФЗ. При використанні правила ланцюжка ця проблема не виникає.

Іншим випадком можливої втрати ФЗ в процесі проектування є ситуація, в якій один атрибут залежить від двох різних детермінантів. Хай для відношення R(A,B,C) визначена залежність, показана на Рис. 3.9.

R(A,B,C)

Рис. 3.9. Два детермінанти з одним і тим же залежним атрибутом

Це відношення не знаходиться в НФБК, оскільки є тільки один можливий ключ <А,С>, тоді як детермінантами є <А> і <С>. Правило ланцюжків тут неприкладено унаслідок їх відсутності. Крім того, якщо одна з ФЗ буде виділена звичайним способом, то інша буде втрачена. Наприклад, при виділенні з R (А,В,С) залежності А -> В будуть отримані відношеньи R1(А, С) і R2(A,B), жодне з яких не міститиме залежності С -> В. Навпаки, при першочерговому виділенні С->В буде загублена залежність А -> В. Виникла ситуація, що зобов'язала проектувальника знайти   спосіб   розбиття   відношення   R (А, В, С)   на R1(A,B) і R2(C,B), що не приводить до втрати жодної ФЗ. Цей шлях не відповідає стандартному методу декомпозиції, але може привести до кращого результату. Єдине, що може зробити проектувальник, зіткнувшися з вказаною ситуацією, це перевірити три можливі набори відношень і оцінити, який з трьох найбільш відповідає потребам підприємства. Зокрема, отримані в останньому випадку відношеньи необхідно перевірити на предмет виникнення проблем у разі з'єднання двох підсумкових відношень при пошуку даних на етапі експлуатації остаточного варіанту бази.

Другий метод розбиття відношення, обговорення якого велося із залученням Рис. 3.9, хоча і заснований на підході до проектування, відмінному від декомпозиції, проте використовується багатьма проектувальниками. В основі підходу, званого деякими методом синтезу, лежить твердження (в своїй найпростішій формі), що необхідне все ФЗ з однаковими детерминантами виділяти в групи і кожній групі відводити своє власне відношення. Одержувані відношення перевіряються на їх відповідність НФБК. В останньому прикладі були дві залежність з різними детермінантами. Згідно методу синтезу кожної ФЗ слідує виділити її власне відношення - R1(A,B) і R2(C,B). Метод синтезу може бути використаний як самостійно, так і в поєднанні з методом декомпозиції. В книзі акцент робиться на метод декомпозиції (також званий методом проекції), а метод синтезу використовується як альтернатива при пошуку виходу з скрутних ситуацій, подібних розібраною вище. Як буде показано в розд. 5, залежність, схожа з тією, яка приведена на Рис. 3.9, може виникнути в життєвих ситуаціях реального світу.

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


4.    ДЕЯКІ   МОДИФІКАЦІЇ   АЛГОРИТМУ ПРОЕКТУВАННЯ

4.1. Надлишкова функціональна залежність

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

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

4.2. Транзитивна залежність

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

Якщо А -> В і В -> З, то А -> З - транзитивна залежність.

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

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

(а) Початковий набір ФЗ

(б) А-> Е видапена, оскільки А-> С і  С->Е

(в) В-> Е видапена, оскільки В-> С і  С->Е

(г) А->С видалена, оскільки А->В   і    В->С   і   в результаті отриманий ненадлишковий набір ФЗ

Рис. 4.1. Видалення транзитивної залежності

1. Діаграма ФЗ при відсутності надлишковості

R(A,B,C,E)

2. Витягання залежності C->E, оскільки вона є останньою в ланцюжку

R1(C,E);

R2(A,B,C)

З. Вилучення В->С  з R2 (А, B, З)

R1(З, E);

R3(B, З);

R4(А, B)

Відношення R1, R3 і R4 знаходяться а НФБК. При невеликому практикуванні НФБК-відношення частини 3 можуть бути безпосередньо отримані з частини 1.

Рис 4.2. Отримання набору НФБК-відношень з відношення, наведеного на Рис. 4.1

4.3. Додавання атрибутів у ФЗ

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

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

Якщо А -> В, то A,Z -> В є коректною, але надлишковою ФЗ. Атрибут Z був доданий до детермінанта А без привнесення якої-небудь нової інформації в процес проектування.

Другий вигляд виникає у разі додавання до обох частин даної ФЗ одного і того ж атрибута з метою формування нової залежності:

Якщо А -> В, то А,Z -> B,Z є коректною, але надлишковою залежністю.

На Рис. 4.3 приведені приклади обох форм додавання.     

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

Додавання ФЗ (надлишкова)

(а)

(би)

Рис 4.3. Приклади додавання

4.4. Правила виведення

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

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

Об'єднання ФЗ: якщо А->В і А->С, то А->В,С

Декомозіция ФЗ: якщо А->В,С то А->В і А->С

На Рис. 4.4 дається графічне представлення кожного твердження, Рис. 4.5 ілюструє способи перетворення початкового набору ФЗ в менш складний набір ненадлишкових ФЗ за допомогою процедур об'єднання, декомпозиції і додавання.

Останнє з обіцяних правил виведення називається псевдотранзитивністю.

Якщо X -> У і Y,W -> Z, то X,W -> Z є надмірною через псевдотранзитивність.

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

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

якщо :

(а)

ЯКЩО:

ТО:

(б)

Рис. 4.4. Приклади на об'єднання і декомпозицію

4.5. Мінімальне покриття

Набір ненадлишкових ФЗ, отриманий шляхом видалення всіх надлишкових ФЗ з початкового набору за допомогою 6 правил виведення, називається  мінімальним покриттям.

 

(а) Початковий набір ФЗ

 

(б) В,С->D  видалена (додавання B->D)

 

(в) A->B,С заміщена А-> В & А->С (декомпозиція)

 

(г) А->С і А -> D замінюється на А ->K & K->C  і А->В & В->D (транзитивність)

Рис 4.5. Спрощення діаграми ФЗ за допомогою правил виведення

На жаль, мінімальне покриття не завжди є унікальним, оскільки порядок, в якому здійснюється процедура видалення надлишкових ФЗ, може зробити вплив на отримане мінімальне покриття. Щоб переконатися в цьому, читачу достатньо звернутися до Рис. 3.2 і перевірити, що в представленому випадку проектування існують два мінімальні покриття. Перше мінімальне покриття виходить при видаленні з початкового набору залежності Сном -> Тном, а друге - при видаленні Сном -> Кном. Використовування цих двох мінімальних покриттів веде до побудови тих же самих двох БД, проектування яких обговорювалося ваше. На закінчення слід підкреслити один важливий момент» пов'язаний з видаленням надлишкових ФЗ з початкового набору: надмірні ФЗ слідує видаляти в одній, кожного разу наново аналізуючи новий набір на предмет присутності в ньому надлишкових ФЗ.

Псевдотранзитивна ФЗ (надлишкова)

(а)

Рис. 4.6. Графічні приклади на псевдотранзитивність

Ця процедура завершується, як тільки не залишиться жодної надмірної ФЗ, набір, що залишився, є мінімальним покриттям.

4.6. Переглянутий алгоритм проектування

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

1. Побудова універсального відношення для БД.

2. Визначення всіх ФЗ, існуючих між атрибутами універсального відношення.

3. Видалення всіх надлишкових ФЗ з початкового набору ФЗ з метою отримання мінімального покриття. Ця процедура проводиться шляхом почергового видалення надлишкових ФЗ з подальшою перевіркою одержуваного на кожному кроці набору ФЗ на наявність хоча б однієї надмірної ФЗ.

4. Використовування ФЗ з мінімального покриття для декомпозиції універсального відношення в набір НФБК-відношень. Далі повинен бути застосований алгоритм декомпозиції, описаний в розд. 3.4.

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

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

 

4.7. Перевірка відношень на завершальній фазі їх проектування

Після завершення розробки НФБК-відношень, що розглядаються вже як остаточний проект, отриманий набір необхідно проконтролювати на предмет наявності невиявлених проблем.

1. Складаються списки ФЗ для кожного відношення. Ці списки перевіряються по двох напрямах: по-перше, одна і та ж ФЗ не повинна з'являтися більш ніж в одному відношенні; і по-друге, набір ФЗ, отриманий в результаті проектування, повинен в точності співпадати з набором, присутнім в мінімальному покритті, отриманому перед початком проектування. Інакше, необхідно показати можливість отримання підсумкового набору ФЗ з мінімального покриття за допомогою правил виведення. Білі хоча б одна з цих перевірок виявиться недостовірною, слід проаналізувати процес проектування для виявлення помилок та/або розглянути інші варіанти проектування.

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

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

R1(A,B)

R2(B,C,Y,Z)

R3(A,B,K)

Відношення R1 є надлишковим, оскільки всі його атрибути присутні відносно R3.

Для ілюстрації надлишковості другого типу покладемо, що пропонований проектний набір має вигляд:

R1(A,C,X)

R3(D,K,F)

R5(D,E,G,H)

R7(A,B,D)

R8(A,B,E,G)

Відношення R8 є надлишковим, оскільки вживання операції JOIN над R5 і R7 (общин атрибутом є D) дає в результаті відношення R9(A,B,D,E,G,H), яке містить всі атрибути, присутні в R8.

3. Розгляд відношень з практичної точки зору. Вивчається характер використовування відношень в конструйованій БД і визначається чи будуть вони підтримувати ті типи запитів і операцій оновлення, які передбачається використовувати.


 

А также другие работы, которые могут Вас заинтересовать

33813. Прокуратура 15.72 KB
  Например прокуратура в Российской Федерации не только поддерживает государственное обвинение в суде но и осуществляет надзор за соблюдением и исполнением законов другими правоохранительными органами: осуществляющими оперативнорозыскную деятельность предварительное расследование дознание и предварительное следствие и исполнение судебных решений судебными приставами. История Впервые прокуратура была создана во Франции в 1302 году именно как орган представляющий интересы монарха. Прокуратура была учреждена тремя петровскими указами:...
33814. Образ богочеловека — Иисуса Христа 19.21 KB
  Ветхий завет священная книга последователей иудаизма и Новый завет излагающий важнейшие этапы жизни создателя христианства Иисуса Христа и основные положения его учения. Два из этих Евангелий от Матфея и от Иоанна приписываются непосредственно ученикам Иисуса Христа а два других от Марка и от Луки ученикам учеников Иисуса Христа. Новая эра и начинает свой отсчет со времени рождения Иисуса Христа.
33815. Харизматические лидеры раннего христианства 16.39 KB
  Именно с Павлом ассоциируется разрыв со свойственной иудаизму национальной ограниченностью религии ему приписывают слова о том что для христианства нет ни эллина ни иудея что Богу угодны все; и иудеи и язычники и обрезанные и необрезанные – достаточно лишь отказаться от старого образа жизни и поверить в Христа т. Трансформация раннего христианства Переосмысление раннего христианства в духе паулинизма явилось началом его трансформации в сторону организованной вселенской церкви. В этом смысле именно Павел может считаться первым...
33816. Первый церковный собор 18.11 KB
  Для выработки единого мнения по важнейшим вопросам по инициативе императора Константина был созван 1 церковный собор который должен был заложить основы единой христианской церкви. 1 Собор прошел в г. Постановления собора были приняты не только от имени святых отцов но и от лица императора Константина что закрепило особую роль императора во взаимоотношениях с церковью.
33817. Монофизитство 14.14 KB
  В настоящее время существует шесть нехалкидонских церквей или семь если Армянский Эчмиадзинский и Киликийский католикосаты рассматривать как две дефакто автокефальных церкви. Древние Восточные церкви можно разделить на три группы: 1 Сирояковиты копты и малабарцы Маланкарская церковь Индии. 3 Эфиопы Эфиопская и Эритрейская церкви. Армянская церкви в прошлом отличалась от остальных нехалкидонских церквей даже сам Севир Антиохийский был анафематствован армянами в IV в.
33818. Несторианство 14.18 KB
  В то же время как и в халкидонских церквах различаются действия во Христе одни действия Христа рождение от Марии страдания смерть на кресте несторианство относит к его человечеству другие творение чудес к Божеству. Несторианство особо подчеркивает важность подвигов Христа как человека. Как оппозиционное византийскому христианству направление Несторианство закрепилось в церкви Персидской империи в результате чего эта церковь обособилась от всего остального христианского мира. Усилиями миссионеров Сироперсидской церкви АЦВ в...
33819. Суфии и суфизм 16.21 KB
  В отличие от рационалистовмутазилитов суфии – мистики ислама. Суфии от слова суф означающего грубую шерстяную накидку в которую они облачались – это своеобразные мусульманские монахи. Подавляя а то и пугая правоверных своим необычным видом и странным поведением суфии особенно нищие дервиши вначале вызывали настороженное к себе отношение подозрение и даже преследование властей. Посвятив себя Аллаху стремясь уйти от мирских дел отказываясь от имущества и от земных привязанностей усмиряя свои чувства и страсти суфии как бы...
33820. Бахаизм 19.62 KB
  Городом в котором сформировалась первая бахаистская община был Багдад сейчас столица Ирака. Бабизм от имени своего основателя Баба став важным идейным источником бахаизма в дальнейшем прекратил своё существование причём именно его последователи и образовали первые общины бахаи. Главная идея бабизма унаследованная бахаизмом состояла в утверждении что Мухаммад был последним пророком Бога не для всей истории человечества а только для определённого исторического этапа что после него новый этап открывают два пророка одним из...
33821. Синтоизм 13.96 KB
  В японской религии синто или синтоизме как называют её европейцы к числу божеств именуемых ками относятся божественные предки японского народа; духи гор рек камней деревьев огня ветра; божествапокровители отдельных местностей и ремёсел; божества олицетворяющие человеческие добродетели; духи умерших. Само название религии синто состоит из двух иероглифов: син и то . Таким образом дословный перевод синто путь богов . Что же стоит за столь необычным названием Строго говоря синто языческая религия.