Принципи концептуального проектування баз даних

Принципи концептуального проектування баз даних

Архітектури системи баз даних

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

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

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

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

Зовнішній рівень

(представлення

окремих користувачів)

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

(узагальнене представлення

користувачів)

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

(представлення фізичного

зберігання)

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

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

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

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

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

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

Концептуальна модель даних

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

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

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

Ім'я об'єктної

множини об'єктна множина

Об'єкт-елемент

Об'єктна множина може бути лексичною та абстрактною.

Елементи лексичної множини можна надрукувати

(ІМ'Я, ДАТА, КІЛЬКІСТЬ, НОМЕР ПАСПОРТУ).

Елемент абстрактної множини надрукувати не можна. Приклад - ЛЮДИНА.

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

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

Наприклад в БД множини ЛЮДИНА кожен елемент має свій ідентифікаційний код (12875469), який є беззмістовним поза БД.

Конкретизація і узагальнення

Деякі об'єктні множини містяться всередині різних об'єктних множин

Дві точки,

що

представляють

один і той самий

предмет

Конкретизація - об'єктна множина, що є підмножиною іншої об'єктної множини. Узагальнення - об'єктна множина, що є надмножиною іншої об'єктної множини.

Розглянувши це можна ввести поняття сутності

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

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

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

При описі предметної області «Учбовий процес», можна виділити декілька сутностей: студент, викладач, предмет.

Сутність Студент можна охарактеризувати наступними атрибутами:

ПІБ, Дата_НАродЖеНня, АдресА, Дата_ВСТУПУ, Номер_заЛІКОВОЇ_ книжки, НОМЕР_ГРУПи.

Сутність Викладач характеризується наступними атрибутами:

ПІБ, АдресА, ПоСАДА, Кафедра, ВЧЕНЕ_Звання, Телефон_ робочий, Телефон_ домашній.

Сутність Предмет характеризується наступними атрибутами:

Назва, Кафедра, Лекції, Практичні_заняття, Лабораторні_роботи, Курсові_роботи, Семестр.

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

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

Або між сутностями Студент, Викладач і Предмет існує зв'язок Екзамен.

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

ОЦІНКА і ДАТА_ПРОВЕДЕННЯ.

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

При описі тієї чи іншої ПрО бажано притримуватися наступних вимог:

- повнота охоплення об'єктів (сутностей) розглядуваної області;

- однозначність атрибутів;

- можливість залучення нових об'єктів (сутностей).

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

Інформацію про проект підсумовують з використанням графічних діаграм. Для них використовують наступні позначення:

Сутності зображають прямокутниками.

Атрибути позначають овалами.

3. Зв'язки зображають ромбами.

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

ОДРУЖЕНИЙ ЧОЛОВІК = {Петро, Іван, Василь} ({множ. ОДРУЖЧОЛОВ })

І

ЗАМІЖНЯ ЖІНКА = {Оксана, Наталка, Ольга} {ОДРУЖ_ЖІНКА}

Тоді

ПЕРЕБУВАЄ-ВШЛЮБІ-З={(Петро, Оксана), (Іван, Наталка), (Василь, Ольга)}.

Відношення ПЕРЕБУВАЄ-В-ШЛЮБІ-З є множиною, елементами якої будуть сімейні пари. Воно і буде складною об'єктною множиною.

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

Перебуває в шлюбі

_{СІМЕЙНА ПАРА}

МЕШКАЮТЬ-В

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

Потужність відношень показує максимальну кількість елементів однієї об'єктної множини, пов'язаних з одним елементом іншої об'єктної множини.

Структурні зв'язки можуть бути трьох основних типів:

1 : 1 - одному екземпляру об'єкта А відповідає строго один екземпляр об'єкта В.

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

 № паспорту Дата народження

ключ не ключ

.

№ паспорту ім'я Адреса

Наслідування відношень

Працює в

Іван Петренко Фірма “Тетріс”

Іван Петренко

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

· у відношеннях немає однакових кортежів;

· кортежі відношення не мають впорядкованості у напрямку знизу вверх;

· атрибути в кортежах не впорядковані зліва направо;

· кожен кортеж містить одне значення для кожного атрибуту.

Властивість 1. відсутність однакових кортежів.

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

Властивість 2. відсутність впорядкованих кортежів (зверху вниз).

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

Властивість 3. відсутність впорядкування атрибутів (зліва направо).

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

Властивість 4 кожен кортеж містить рівно одне значення для кожного атрибуту.

Остання властивість випливає безпосередньо з визначення кортежу: кортеж є множиною n впорядкованих пар виду a_i:_i (i=1,2,…n). Відношення, що задовольняє цій властивості називається нормалізованим або представленим у першій нормальній формі (1нф).

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

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

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

ПОСТАЧАЛЬНИК#, ІМ'Я, СТАТУС, МІСТО

Для кожної деталі потрібно зберігати

№ДЕТАЛІ, НАЗВУ, КОЛІР, ВАГУ, тощо. ПОСТАВКИ: №Постач, №Деталі, КІлькість.

При правильному проектуванні відповідної БД в ній з'являться відношення:

S (ПОСТАЧАЛЬНИКИ) (S#, SNAME, STATUS, CITY) (первинний ключ - S#), P(ДЕТАЛІ) (P#, РNAME, COLOR, WEIGHT, CITY) (первинний ключ - P#), SP(S#, P#, QTY) (S#, P# - складовий первинний ключ).

Значення атрибутів S#, P# в будь-якому кортежі відношення SP повинно відповідати значенню атрибута S# в деякому кортежі відношення S, і значенню атрибута P# у відношенні P. Атрибут такого роду називають зовнішнім ключем, оскільки його значення однозначно характеризують сутності, представлені кортежами деякого іншого відношення (тобто задають значення їх первинного ключа). Кажуть, що відношення, в якому визначений зовнішній ключ, посилається на відповідне відношення, в якому такий самий атрибут є первинним ключем. Вимога цілісності за посиланнями, або вимога зовнішнього ключа, полягає в тому, що для кожного значення зовнішнього ключа, що з'являється у відношенні, що посилається на нього, у відношенні, до якого веде посилання, повинен знаходитися кортеж с таким самим значенням первинного ключа, або значення зовнішнього ключа повинно бути повністю невизначеним (тобто ні на що не вказувати). Для нашого прикладу це означає, що якщо для поставки вказано номер постачальника, то такий постачальник повинен існувати. Обмеження цілісності сутності і за посиланнями повинні підтримуватися СКБД. Для забезпечення цілісності сутності достатньо гарантувати відсутність у будь-якому відношенні кортежів з одним і тем самим значенням первинного ключа. З цілісністю за посиланнями справа дещо складніша. Зрозуміло, що при обновленні відношення, що посилається (вставці нових кортів або модифікації значень зовнішнього ключа в існуючих кортежах) достатньо слідкувати за тим, щоб не з'явилися некоректні значення зовнішнього ключа. Але як бути при видаленні кортежу з відношення, до якого веде посилання? Тут існують три підходи, кожен з яких підтримує цілісність за посиланнями. Перший підхід полягає в тому, що забороняється видаляти кортеж, на який існують посилання (тобто спочатку потрібно або видалити кортежі, що посилаються, або відповідним чином змінити значення їх зовнішнього ключа). При другому підході при видаленні кортежу, на який є посилання, у всіх кортежах, що посилаються, значення зовнішнього ключа автоматично стає невизначеним. Нарешті, третій підхід (каскадне видалення) полягає в тому, що при видаленні кортежу з відношення, на яке вказує посилання, з відношення, що посилається, автоматично видаляються всі кортежі, що посилаються. В розвинутих реляційних СКБД звичайно можна вибрати спосіб підтримки цілісності за посиланнями для кожної окремої ситуації визначення зовнішнього ключа.

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