Проектування та розвиток баз даних

Забезпечення колективного доступу до даних.

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

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

3. Архітектура інформаційної системи

3.1. Користувачі інформаційної системи

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

Рис. 3.1 Користувачі БД

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

• Адміністратор функціональних підсистем спільно з адміністратором БД визначає алгоритми обробки даних.

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

• Завдання прикладних програмістів - розробка програмного середовища, тобто прикладних програм.

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

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

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

3.2. Рівні подання інформаційної системи.

З інформаційною системою працюють користувачі різних категорій.

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

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

Початковий рівень

Відповідає уявленням про предметну області (ПО) кінцевих користувачів. Він називається рівнем локальних користувацьких подань.

Інфологічний рівень

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

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

Концептуальний рівень

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

Внутрішній рівень

Даний рівень розглядає подання даних у пам'яті ЕОМ, а також способи доступу і зберігання даних.

Рис 3.2 Рівні подання інформаційної системи

4. Мережеві бази даних

На розробку цього стандарту великий вплив зробив американський учений Ч.Бахман. Основні принципи мережевої моделі даних були розроблені в середині 60-х років, еталонний варіант мережевої моделі даних описаний у звітах робочої групи з мов баз даних (Conference on DAta SYstem Languages) COD ASYL (1971 р.).

4.1. Структура даних мережевої моделі

Основні поняття мережевих баз даних - елемент, агрегат, запис (група), групове відношення, база даних.

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

Агрегат даних - це сукупність елементів чи інших агрегатів.

При описі БД кожному агрегату приписується унікальне ім'я, по якому до агрегату можна звернутися, як до єдиного цілого при обробці даних. Приклад: Адреса [індекс, місто, вулиця, будинок, квартира]

Запис - це агрегат, який не входить ні в який інший агрегат. Це основна одиниця обробки БД.

Слід розрізняти тип запису і екземпляр запису: Тип запису визначає склад її елементів і агрегатів.

Екземпляр запису - конкретна сукупність значень елементів, складових запис. Якщо запис містить кілька значень одного типу, то говорять, що в записі визначений вектор (рис.4.2)

Якщо в кожному екземплярі запису довжина вектора однакова, то це вектор фіксованої довжини (рис. 4.2), інакше - вектор змінної довжини (наприклад відомості про роботи в запису жителя рис. 4.1).

Рис 4.1 Приклад запису-вектора змінної довжини

Рис 4.2 Приклад запису-вектора фіксованої довжини

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

Групове відношення - це ієрархічне (підпорядковане) відношення між записами двох типів. Записи першого типу є власниками відношення, записи другого типу - членами відношення або підлеглими записами.

Групове відношення графічно зображується орієнтованого, де дугами будуть відношення, а вершинами типи записів. Таке зображення структури БД називається діаграмою Бахмана. Також необхідно розрізняти тип відношення і екземпляр відношення (рис.4.3) і (рис.4.4).

Рис 4.3 Тип відношення зображений за допомогою діаграми Бахмана

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

Екземпляр відношення - це екземпляр запису-власника відношення і множина(можливо порожня) підлеглих екземплярів записів-членів стосунки.

Замалюємо приклад по відношенню до "диспансеризація" (рис. 4.4):

Рис 4.4 Екземпляр відношення „Диспансеризація”

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

Рис 4.5 Один тип запису є учасником декількох відношень

Мережева модель даних дозволяє встановлювати кілька однаково спрямованих групових відношень між двома типами записів (рис. 4.6)

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

Рис 4.6 Декілька групових відношень в мережевій моделі даних

Кожен тип групового відношення характеризується наступними ознаками.

1. Способи впорядкування підлеглих записів;

2. Режим включення підлеглих записів;

3. Режим виключення підлеглих записів.

4.2. Способи впорядкування підлеглих записів

Кожен екземпляр групового відношення можна розглядати як сукупність запису власника і списку відповідних записів-членів. Записи-члени в списку можуть бути впорядковані по-різному. Розрізняють такі способи:

1. довільний;

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

3. зворотно-хронологічний - новий запис розміщується на початку списку (стек, магазин);

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

4.3. Режим включення підлеглих записів

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

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

• Ручний режим - дозволяє занести підпорядкований запис в БД і не включати його негайно в екземпляр групового відношення.

4.4. Режим виключення підлеглих записів.

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

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

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

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

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

4.5. Операції над даними в мережевій моделі.

• Заповнити - дозволяє занести в БД новий запис і автоматично включити цей запис в групове відношення, де він оголошена підлеглим з автоматичним режимом включення.

• Включити в групове відношення - дозволяє існуючий запис зв'язати із записом-власником.

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

• Оновити - дозволяє змінити значення елементів існуючого запису. Перед оновленням існуючий запис повинен бути вилучений з БД.

• Зняти - ця операція має декілька модифікацій:

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

2. витяг по ключу - який би запис не був витягнутий, команда витягує запис із заданим ключем;

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

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

• Виключити з групового відношення - дозволяє розірвати зв'язок між записом власником і підпорядкованим записом, зберігаючи обидві в БД.

4.6. Обмеження цілісності в мережевій моделі.

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

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

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

5. Ієрархічні бази даних

Типовим представником (найбільш відомим і поширеним) є Information Management System (IMS) фірми IBM. Перша версія з'явилася в 1968 р. До цих пір підтримується багато таких баз даних, що створює суттєві проблеми з переходом, як на нову технологію БД, так і на нову техніку.

5.1. Структура даних ієрархічної моделі

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

Ієрархічна БД складається з упорядкованого набору дерев; точніше, з упорядкованого набору декількох екземплярів одного типу дерева. Для графічного зображення також зручно використовувати діаграми Бахмана. Відмінна риса для ієрархічних баз даних-її діаграма Бахмана буде деревом (рис. 5.1).

Рис 5.1 Діаграма Бахмана ієрархічної бази даних

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

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

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

Мережева модель

Ієрархічна модель

Рис 5.2 Перетворення мережевої моделі в ієрархічну

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

5.2. Операції над даними в ієрархічній моделі

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

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

• Видалити - операція служить для виключення з БД деякого запису і всіх підпорядкованих йому.

• Зняти - ця операція має декілька модифікацій:

1. витягти кореневий запис по ключу;

2. витягти кореневий запис послідовно.

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

Рис 5.3 Лівосторонній обхід дерева

Для руху по структурі служить операція витяга наступного, тобто розуміється в сенсі лівостороннього обходу дерева. Приклад: для дерева зображеного на малюнку 5.3, лівобічний обхід вершин наступний: А, В, С, D, Е, F. Операція витягти допускає завдання умов вибірки.

Приклад: вибрати тільки чоловіків в картотеці поліклініки.

5.3. Обмеження цілісності в ієрархічній моделі.

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

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

6. Реляційні бази даних

Реляційна модель запропонована співробітником компанії IBM Е.Ф.Коддом в 1970 р. В даний час ця модель є фактичним стандартом, на який орієнтуються практично всі сучасні комерційні СУБД.

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

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

• Домен має унікальне ім'я (в межах бази даних).

• Домен визначений на деякому простому типі даних або на іншому домені.

• Домен може мати деяку логічну умову, що дозволяє описати підмножину даних, допустимих для даного домену.

• Домен несе певне смислове навантаження.

Наприклад, домен D, що має значення "вік співробітника" можна описати як наступну підмножину множини натуральних чисел: D = {neN: n> 18 and n <60}

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

Кортежі - це упорядкована сукупність елементів доменів.

Математичний опис відношень:

Нехай дано множини Di, D2,..., Dn - домени і існує ряд кортежів виду <di, d2,...,dn>; d; c: D, тоді декартовим множенням D = Di»D2» D3»..»Dn називається множина всіх можливих кортежів.

Приклад:

D₁ = {червоний, синій}

D₂ = {олівець, фломастер, ручка}

D₃ = {+ -}

D = D₁•D₂•D₃ = {<червоний, олівець, +> <.........> <синій, ручка, ->}

Відношенням R на доменах D₁, D₂, D₃ називається підмножина декартового добутку R. З точки зору організації даних відношення зручно зображати у вигляді таблиць (таблиця 6.1):

Таблиця 6.1

Колір	Предмет	Наявність
Червоний	Олівець	+
Червоний	Олівець	-
…	…	…
Синій	Ручка	-

Терміни, якими оперує реляційна модель даних, мають відповідні "табличні" синоніми:

Таблиця 6.2

Реляційний термін	Відповідний табличний термін
База даних	Набір таблиць
Відношення	Таблиця (файл)
Атрибут відношення	Найменування стовпця таблиці (поле)
Кортеж відношення	Строчка таблиці (запис)
Ступінь відношення	Кількість стовпців таблиці
Потужність відношення	Кількість строчок таблиці

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

Ступінь відношення - це кількість доменів (стовпців), які утворюють дане відношення, як правило, ступінь відношення в процесі життєвого циклу не міняється.

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

Зауваження.

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

Роздивимось просту реляційну базу даних, яка складається з трьох таблиць (Таблиця 6.3-6.5).

Таблиця 6.3 "Постачальник"

№ постачальника	Назва постачальника	Місто
	Нормаль	Н.Новмісто
	Червона Этна	Н.Новмісто
	Уралмаш	Київ
	Нормаль	Москва
Таблиця 6.4 "Деталь".
№ деталі	Назва деталі
	Болт 17
	Шпильки
	Гайка 22
	Гайка 10
Таблиця 6.5 "Поставщик - Деталь".
№ постачальника	№ деталі	Кількість

БД містить три типи інформації.

• Інформація про постачальників деталей на підприємство (таблиця 6.3):

номер постачальника;

найменування деталі;

назва міста.

• Інформація про деталі, які використовуються на підприємстві (таблиця 6.4):

номер деталі;

найменування деталі.

• Інформація про номер і кількість надходження деталей від кожного постачальника (таблиця 6.5)

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

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

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

Таблиця 6.6 Типи Атрибутів.

Назва атрибута	Тип атрибута
Пном	Числовий(3)
Пназ	Символьний(16)
Гор	Символьний(15)
Дназ	Символьний(10)
Штук	Числовий (5)
Дном	Числовий(5)

Відношення з зазначеними первинними ключами для даної БД:

Постачальник (Дном, Пназ, Гор)

Деталь (Дном, Дназ)

Постачальник-Деталь (Пном, Дном, Штук)

Результатом проектування є концептуальна модель БД.

6.1. Цілі проектування баз даних

Найбільш важливими цілями проектування є:

• Зберігання всіх необхідних даних в БД, тобто централізація даних;

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

• Зменшення кількості відношень в БД;

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

Першим кроком в процесі проектування є визначення переліку атрибутів (стовпців), які повинні зберігатися в БД.

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

Необхідно розрізняти дублювання даних і дублювання з надмірністю:

Таблиця 6.7 Приклад дублювання даних

Табельний номер	Номер лабораторії	В таблиці 6.7 Числа 12 и 17 дублюються, але не надлишкові.
Таблиця 6.8 Приклад надлишкового дублювання даних.
Табельний номер	Номер лабораторії	Телефон лабораторії	В таблиці 6.8 телефон лабораторії, як видно, дублюється, і це вже надлишкове дублювання.
		2-17
		4-41

Третій крок - усунення надмірності. Отриманий файл після усунення надмірності слід вважати незадовільним. По-перше, порожніх полів у файлі слід уникати, в такій структурі зберігання для записів необхідно мати процедуру пошуку. По-друге, можуть виникнути серйозні проблеми з видаленням інформації. Якщо видалити працівника 287, то зникне і відповідний номер лабораторії. Кращий спосіб усунення - розбиття Відношення "Службовець - лабораторія - телефон" (таблиця 6.8) на два: "Лабораторія - телефон" (таблиця 6.9) "Службовець - лабораторія" (таблиця 6.10)

Таблиця 6.9 "Лабораторія-телефон"

Номер лабораторії	Телефон лабораторії
	2-17
	4-41

6.10 " Таблиця 6.10 "Службовець-Лабораторія"

Табельний номер	Номер лабораторії

Розбиття Відношень на два або декілька - робоча процедура проектування.

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

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

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

Для невеликих БД універсальне відношення може використовуватися в якості основного пункту при проектуванні БД.

Припустимо, що потрібно розробити БД для начальника відділу.

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

Сном - номер співробітника (ціле значення, унікальне),

Спрізв - прізвище співробітника (строкове значення),

Лном - номер лабораторії, у якій трудиться даний співробітник,

Тном - робочий телефон співробітника,

Проект - номер проекту, в розробці якого бере участь співробітник,

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

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

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

Таблиця 6.11 Інформація обрана для зберігання в базі даних

Сном	Спрізв	Тном	Лном	Проект	Квартал	Внесок
	Іваненко	5-17	25 АП	РКТ14	1990.3
				Зенит	1990.3
				ВКТ14	1990.4
				ВТА2	1990.4
	Ніколаєв	8-29	4КТ	ВКТ14	1990.3
				ВТА8	1990.4
				ВКТ14	1990.4
	Андрієнко	5-17	25АМ	Зеніт	1990.3
				ОТР6	1990.4
				ВКТ14	1990.4
	Зайців	4-85	14ММ	ОВ77	1990.3

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

Таблиця 6.12 Універсальне відношення бази даних "Начальник відділу"

Сном	Спрізв	Тном	Лном	Проект	Квартал	Внесок
	Іваненко	5-17	25 АП	РКТ14	1990.3
	Іваненко	5-17	25 АП	Зеніт	1990.3
	Іваненко	5-17	25 АП	ВКТ14	1990.4
	Іваненко	5-17	25 АП	ВТА2	1990.4
	Ніколаєв	8-29	4КТ	ВКТ14	1990.3
	Ніколаєв	8-29	4КТ	ВТА8	1990.4
	Ніколаєв	8-29	4КТ	ВКТ14	1990.4
	Андрієнко	5-17	25 АП	Зеніт	1990.3
	Андрієнко	5-17	25 АП	ОТР6	1990.4
	Андрієнко	5-17	25 АП	ВКТ14	1990.4
	Зайців	4-85	14ММ	ОВ77	1990.3

У таблиці 6.12 первинним ключем є значення трьох полів Сном-Проект-Квартал. Отримана таблиця - екземпляр правильного відношення.

6.3. Проблеми, пов'язані з використанням єдиного відношення

На перший погляд, отримане універсальне відношення можна використовувати в якості єдиного відношення проектованої БД. Існує декілька причин, по яким не слід дане відношення використовувати в якості єдиного.

Розрізняють три проблеми, пов'язані з використанням відношень і з виконанням певних операцій.

• проблема вставки;

• проблема оновлення;

• проблема видалення.

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

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

Сорокін

5-17

25АР

-

-

Як зазначалося раніше, порожніх значень слід всіляко уникати. Припустимо, що у відношення включений нова запис про співробітника Сорокіна з порожніми полями і робиться наступний запит: "Надрукувати список номерів та прізвищ співробітників, вклад яких не більше 2". У результаті ми отримаємо так званий «чорний список», в який потрапив і тільки що прийнятий на роботу Сорокін.

	Іваненко
	Андрієнко
	Сорокін

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

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

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

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

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

Припустимо виникає наступна ситуація: Начальник відділу зустрічає Іваненка і питає його - "Ви були вчора на вашому робочому місці? Я весь день вам дзвонив і ніхто не брав трубку". А Іваненко йому відповідає "Відділ зв'язку змінив вчора номер на 9-17". Начальник відділу приходить до себе в кабінет і змінює в усіх записах телефон Іваненка на 9-17. Через деякий час йому необхідно зателефонувати в лабораторію 25-АР, а телефон він не пам'ятає, він складає запит вивести всі не повторювані записи зі значенням поля Лном рівним 25-АР. Відповідь: 9-17 та 5-17. За яким телефоном дзвонити якщо заздалегідь відомо, що в кожній лабораторії тільки один телефон.

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

Припустимо, що фінансування проекту 0В77 припинилося і начальник видаляє всі відповідні записи. Так як в розглянутому відношенні є тільки один кортеж з номером співробітника 559 (це співробітник Зайців), який виконував роботу тільки за проектом 0В77, то відбудеться видалення запису про співробітника Зайців. Фактично ми втрачаємо всю інформацію про даному співробітнику. Розглянута проблема також є аномалією.

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

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

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

зображення: А →В або

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

• Номер співробітника є унікальним. З номером у відношенні може з'явитися тільки певне прізвище. Звідси отримуємо функціональну залежність: Сном → Спрізв

• Якщо в кожній лабораторії тільки один телефон то отримаємо залежність Тном →Лном.

• Так як кожен телефон обслуговує тільки одну лабораторію Лном →Тном.

• Кожен співробітник є працівником тільки однієї лабораторії. Тоді якщо стосовно з'являється комбінація 315-4КТ, то разом з 315 ніякого іншого значення Лном з'явитися не може отже отримуємо залежність Сном → Лном. А так як в кожній лабораторії тільки один телефон можна також стверджувати що, Сном →Тном.

• Оскільки значення атрибуту Внесок однозначно може бути визначене, якщо задані атрибути Сном, Проект і Квартал, то отримуємо залежність:

Сном, Проект, Квартал → Внесок

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

Рис 6.1 Діаграма функціональних залежностей

6.5. Нормальні форми відношень

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

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

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

Повна функціональна залежність. Нехай А - це деякий атрибут, X - це набір атрибутів. Кажуть, що А функціонально повно залежить від X, якщо X→А, У≠А, де У будь підмножина X. Набір атрибутів X називають детермінантою відношення. Відношення знаходиться в другій нормальній формі, якщо воно знаходиться в першій нормальній формі, і кожен неключовий атрибут функціонально повно залежить від можливого ключа. Так, відношення з залежністю Сном, Лном, Тном → Сном не знаходиться у другій нормальній формі.

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

Транзитивна залежність. Нехай X, У, Z- набори атрибутів деякого відношення. Якщо X→У, Х →Z але Y≠Х то X→Z, тоді говорять що Z транзитивнj залежить від X.

Приклад: транзитивної залежності Сном →Тном, Тном →Лном => Сном→Лном.

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

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

Третя посилена форма або нормальна форма Бойса-Кодда (НФБК)

Відношення знаходиться в НФБК тоді і тільки тоді, коли відношення знаходиться в третій нормальній формі і кожен детермінант відношення є можливим ключем. Відношення, створюване для начальника відділу має чотири детермінанта:Сном Лном Тном Спрізв, Проект, Квартал.

Кодд довів, що відношення в НФБК практично не містить аномалій, тому на практиці дотримуються приведення відношення в НФБК.

6.6. Декомпозиція відношень

Декомпозиція виходить приведенням до отримання двох відношень з одного. Наприклад, було R (Х, У, Z), а в результаті декомпозиції отримали два R₁(X,У), R₂(У,Z). Декомпозиція аномального відношення виконується наступним чином.

Нехай R - відношення, яке не знаходиться в НФБК. Нехай а_j залежить від а_i (а_i→а_j). Ця залежність перешкоджає знаходженню відношення в НФБК. Нехай а_i - деякий атрибут, детермінант, але не є можливим ключем. Відношення R (а₁,..., а_i,..., а_j­) розбивають на два R₁(а₁,..., а_i,..., а_j-1) і R₂(а_i, а_j)

Відношення R₂ називається проекцією відношення R.

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

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

Якщо природне з'єднання R₁ та Я₂ в підсумку дає більше кортежів, ніж в R - то це декомпозиція з втратами.

Відсутність втрат при декомпозиції відношення R (Х, У, Z) в R₁ (Х, У), R₂(Y,Z) гарантується за умови, що від загального атрибуту (У) функціонально залежить хоча б один атрибут з двох, що залишилися.

Приклад 1:

Приклад 2:

Якщо Y→Z, то розбиваючи відношення R, отримаємо, що R=R_3.

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

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

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

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

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

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

Правило 1. транзитивні залежності

Транзитивна залежність є надлишковою (рис. 6.6).

Рис. 6.6 Правило 1

Транзитивні залежності можна видаляти тільки по одній.

Рис. 6.7 Видалення транзитивних записів

Початкові функціональні залежності: А→В, А→С, А→D, С→D, В→С, В→D. Знаходимо транзитивну залежність, наприклад: А→D, і видаляємо її. Потім знову аналізуємо ситуацію, і знаходимо наступну надлишкову функціональну залежність (наприклад: А→С), видаляємо її і так далі до тих пір, поки всі транзитивні залежності не будуть видалені. У підсумку отримаємо:

Рис. 6.8 Відношення з видаленими транзитивними залежностями

Правило 2. Коректні, але надлишкові залежності

а) Якщо існує А→В, то залежність А, Z → В - коректна, але надмірна.

б) Якщо існує А→В, то залежність А, Z → В,Z - коректна, але надмірна.

Рис. 6.9 Правило 2

Правило 3. Об'єднання функціональних залежностей

Об'єднання функціональних залежностей. Якщо А→В і А→С, то А →В, С

Рис 6.10 Правило3: об’єднання функціональних залежностей

Правило 4. Декомпозиція функціональних залежностей

Декомпозиція функціональних залежностей. Якщо А → В, С, то А → В і А→С

Рис 6.11 Правило 4: декомпозиція функціональних залежностей

Правило 5. Псевдотранзитивність

Якщо X→У і У,W→Z то залежність Х,W→Z - називається псевдотранзитивною і є надлишкової функціональною залежністю.

Рис. 6.12 Правило 5: Псевдотранзитивна залежність.

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

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

Приклад видалення надлишкових залежностей за допомогою правил виводу

Для побудови відношень бази даних проведемо наступні дії:

1. З атрибутів предметної області сформуємо універсальне відношення.

2. З універсального відношення виділимо ряд функціональних залежностей.

3. Намалюємо діаграму функціональних залежностей.

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

5. Видалимо всі надлишкові залежності по одній.

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

Рис 6.13 Діаграма функціональних залежностей універсального відношення

Крок перший:

Роздивимось фрагмент діаграми універсального відношення.

Рис 6.14 Фрагмент діаграми B,C→D, B→D

По правилу 2 залежність B,C→D є коректною, але надлишковою. Виконаємо її видалення.

Рис 6.15 Видалення надлишкової залежності B,C→D

В результаті наших дій отримуємо наступну діаграму:

Рис 6.16 Діаграма після видалення надлишкової залежності B,C→D

Крок другий:

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

Рис. 6.17 Фрагмент діаграми А→В,С

По правилу 4 виконаємо декомпозицію залежності А→В,С на А→В, А→С

Рис. 6.18 Декомпозиція А→В,С на А→В, А→С

В результаті другого кроку отримаємо наступну діаграму

Рис. 6.19 Діаграма після декомпозиції залежності А→В,С на А→В, А→С

Крок третій.

Роздивимось фрагмент діаграми, отриманої на другому кроці

Рис 6.20 Фрагмент діаграми А→С, А→К, К→С

По правилу 1 залежність А→С є транзитивною і підлягає видаленню

Рис. 6.21 Видалення транзитивної залежності А→С

В результаті третього кроку отримаємо наступну діаграму:

Рис. 6.22 Діаграма після видалення транзитивної залежності А→С

Крок четвертий:

Роздивимось фрагмент діаграми, отриманої на третьому кроці:

Рис. 6.23 Фрагмент діаграми А→В, А→D, B→D

По правилу 1 залежність А→D транзитивна і підлягає видаленню

Рис. 6.24 Видалення транзитивної залежності А→D

В результаті наших дій отримаємо наступну діаграму:

Рис. 6.25 Діаграма після видалення транзитивної залежності A→D

Після того, як з діаграми були видалені всі надлишкові залежності, формуємо наступні відношення:

R1(B,D)

R2(K,C)

R3(A,B,K)

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

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

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

Крок 3. Видалення всіх надлишкових функціональних залежностей.

Крок 4. Визначаємо, чи знаходиться відношення в НФБК, якщо так - проектування закінчити,якщо ні - відношення розбивається на два.

Крок 5. Кроки 4 і 5 повторюються для всіх відношень, отриманих в результаті декомпозиції, до тих пір поки всі відношення не будуть перебувати в НФБК.

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

Повернемось знову до прикладу бази даних "Начальник відділу".

Рис. 6.26 Універсальне відношення R (Сном, Спрізв, Тном, Лном, Проект, Квартал, Внесок)

Детермінанти, які не є можливими ключами: Сном, Лном, Тном

Можливим ключем є Спрізв, Проект, Квартал.

Універсальне відношення R (Сном, Сghspd, Тном, Лном, Проект, Квартал, Вклад) і не перебуває в НФБК і потребує декомпозиції.

Виявлення функціональних залежностей

У даному відношення міститися такі ланцюжки функціональних залежностей:

Сном→Лном→Тном

Сном→Тном→Лном

Сном, Проект, Квартал→Внесо к

Декомпозиція універсального відношення

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

Виробляємо декомпозицію відношення R (Сном, Спрізв, Тном, Лном, Проект, Квартал, Вклад) на R₁(Лном, Тном) і R₂ (Сном, Спрізв, Лном, Проект, Квартал, Вклад).

Можливі ключі: Лном, Тном

Детермінанти: Лном, Тном

Відношення знаходиться в НФБК

Рис. 6.27 Відношення R₁ (Лном, Тном)

Можливі ключі: <Проект, Квартал, Внесок>

Детермінанти: <Проект, Квартал, Внесок> Сном

Відношення не знаходиться в НФБК.

Рис. 6.28 Відношення R₂ (Сном, Спрізв, Лном, Проект, Квартал, Внесок)

Проведемо декомпозицію відношення R₂ (Сном, Спрізв, Лном, Проект, Квартал, Внесок) на R₃ (Сном, Спрізв, Лном) і R₄ (Сном, Проект, Квартал, Вклад).

У відношенні R₃ (Сном, Спрізв, Лном) об'єднаємо залежності Сном→Спрізв і Сном→Лном в залежність Сном→Спрізв, Лном.

Можливі ключі: Сном

Детермінанти: Сном

Відношення знаходиться в НФБК

Рис. 6.29 Відношення R₃ (Сном, Спрізв, Лном).

Можливі ключі: <Проект, Квартал, Вклад>

Детермінанти: <Проект, Квартал, Внесок>

Відношення знаходиться в НФБК

Рис. 6.30 Відношення R₄(Сном, Проект, Квартал, Внесок)

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

R₂ (Лном, Тном) - знаходиться в НФБК

R₃ (Сном, Сфам, Лном) - знаходиться в НФБК

R₄ (Сном, Проект, Квартал, Вклад) - знаходиться в НФБК

Таблиці 6.21-6.23 демонструють відношення R₂, R₃, R₄ отримані в результаті декомпозиції універсального відношення R.

Таблиця 6.21 R₂

Лном	Тном
25 АП	5-17
4КТ	8-29
14ММ	4-85

Таблиця 6.22 R₃

Сном	Спрізв	Лном
	Іваненко	25 АП
	Ніколаєв	4КТ
	Андрієнко	25АМ
	Зайців	14ММ

Таблиця 6.23 R₄

Сном	Проект	Квартал	Вклад
	РКТ14	1990,3
	Зенит	1990,3
	ВКТ14	1990,4
	ВТА2	1990,4
	ВКТ14	1990,3
	ВТА8	1990,4
	ВКТ14	1990,4
	Зенит	1990,3
	ОТР6	1990,4
	ВКТ14	1990,4
	ОВ77	1990,3

Перевірка на наявність аномалій у відношеннях бази даних "Начальник відділу"

Присутні в цій базі даних аномалії вставки, видалення або оновлення? Перевіряємо базу даних запитами взявши їх з теми 6.3.

Вставка. На роботу в лабораторію 25АР взяли Сорокіна, його номер 687. Ця інформація міститься в відношенні R3 <687, Сорокін, 25АР>. Якщо тепер зробити запит на складення список співробітників, внесок яких дорівнює або менше 2. Так як запит буде звернений до відношення R4 будуть вибрані співробітники з табельними номерами 429, 289. Після з'єднання таблиць ми отримаємо відповідь: Іваненко і Андрієнко мали вклади в проекти менше або рівні трьом. Сорокіна тут немає, таким чином аномалія вставки, присутня у вихідному відношенні, влаштована в результаті декомпозиції.

Оновлення. У вихідному відношенні виникла проблема при зміні телефону в Іваненко на 9-17. Тепер при зміні телефону будуть проводиться наступні дії: якщо ми згенеруємо запит: з відношення R₃ по табельному номеру Іваненко буде визначений номер лабораторії в якій він працює, далі в відношенні R₂ змінимо телефон лабораторії на 9-17. Тепер при запиті надрукувати телефон лабораторії 25АР, ми отримаємо відповідь: 9-17. Аномалія поновлення, присутня у вихідному відношенні усунена в результаті декомпозиції.

Видалення. Фінансування проекту ОВ77 припинено. Інформація про проект повинна бути вилучена з БД. У відношенні R₃ потрібно видалити всі записи зі значенням Проект = ОВ77У вихідному відношенні це правило до видалення з бази інформації про співробітника 559 Зайцiв.

У нашому випадку інформація про співробітників зберігатися в R₂ і не буде втрачена при видаленні кортежів із значенням Проект = ОВ77 з відношення R₃. Таким чином, в результаті декомпозиції усунена аномалія видалення.

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

7. Семантичне моделювання або проектування баз даних методом "Сутність-зв'язок"

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

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

7.1. Сутності та зв'язки

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

Рис. 7.1 Сутності і зв’язки

Зв'язок ЧИТАЄ, існуючий між двома сутностями ВИКЛАДАЧ і КУРС може бути графічно представлений ​​кількома способами:

Діаграма ЕР-екземплярів:

Рис. 7.2 Діаграма ER-екземпляра

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

Діаграма ЕР-типу:

Рис. 7.3 Діаграма ER-типу

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

Термінологія методу "Сутність-зв'язок"

Терміни, що використовуються в ЕR-методі, не можуть бути визначені строго, тим не менше, їх необхідно визначити.

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

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

Атрибут - це властивість сутності. Наприклад атрибутами суті викладача можуть бути: номер викладача, прізвище, телефон, посада, адреса і т.п.

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

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

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

7.2. Ступінь зв'язку

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

Приклад 1: Кожен викладач читає не більше одного курсу, і кожен курс читається не більше ніж одним викладачем (тобто можуть бути викладачі які нічого не читають і курси, які не ким не читаються).

Рис. 7.4 Діаграма ER-екземпляра для прикладу 1

Приклад 2: Кожен викладач читає тільки один курс, кожен курс читається не більше ніж одним викладачем.

Рис. 7.5 Діаграма ER-екземпляра для прикладу 2

Приклад 3: Кожен викладач читає не більше одного курсу, кожен курс читається тільки одним викладачем.

Рис. 7.6 Діаграма ER-екземпляра для прикладу 3

Приклад 4: Кожен викладач читає тільки один курс, кожен курс читається тільки одним викладачем.

Рис. 7.7 Діаграма ER-екземпляра для прикладу 4

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

Дата добавления: 2014-01-11