Konspekt_lektsiy_BD_amp_amp_SD

Рис. 14. Масиви (таблиці), що містять лінійні списки, які описують топологію графу з рис. 12.

Кафедра економічної кібернетики та інформаційних технологій. Одеський національний політехнічний університет

Однак ця схема не торкається реального фізичного боку збереження даних — дисків, доріжок, секторів тощо. Це турбота ОС (наприклад, єдиний диск або RAID-масив).

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

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

Тут необхідно ще раз згадати про мову даних. Точніше, про підмову. Справа в тім, що частина зовнішньої схеми, що відповідає користувальницькому інтерфейсу, реалізується за допомогою універсальної мови, а та, котра відповідає за взаємодію з БД, точніше з концептуальною схемою, — за допомогою підмови даних. Звичайно, можна скористатися і мовою запитів, однак це значно звузить можливості організації користувальницького інтерфейсу. Очевидно, що при такому підході до зовнішньої схеми переважніше, щоб підмова даних і універсальна мова були формально нерозрізнювані. Такі нерозрізнювані або важкорозрізнювані мови називаються сильнозв’язаними. Прикладами можуть служити dBase-подібні мови і, відповідно, СУБД Clipper, Paradox, dBase тощо. Однак вони або дістали розвитку для ОС MS-DOS, або орієнтовані на роботу з локальними БД (максимум — на обчислювальну мережу в режимі файлу-сервера), або і те, й інше.

Інші універсальні мови (C, Pascal, Basic тощо) і вбудовані в них підмови даних є слабкозв’язаними, що не є перешкодою для створення якісних додатків.

Зокрема, існує мова даних, що може використовуватися і як мова запитів, і як вбудована практично в усі перераховані універсальні мови. Це мова SQL — Structured Query Language, що дозволяє працювати із системами клієнт/сервер, розподіленими і локальними БД. До неї ми повернемося пізніше.

На закінчення даного розділу відзначимо ще один аспект архітектури БД, а саме: фай-

лову архітектуру і архітектуру клієнт/сервер. Причому і та й інша можуть бути реалізова-

ні як на локальній машині, так і на мережі ЕОМ.

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

Кафедра економічної кібернетики та інформаційних технологій. Одеський національний політехнічний університет

безпечення захисту і цілісності даних, що згадувалися раніше.

При реалізації архітектури клієнт/сервер систему баз даних поділяють на 2 частини: один або кілька серверів (машин) БД і множину клієнтів (множина може бути одиничною).

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

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

Сьогодні для створення цих додатків розроблено багато різних CASE-систем (Computer Aided Software Engineering) типу Delphi, Microsoft Visual Suite, C++ Builder, СAVO тощо, які включають у себе як підмову даних SQL.

І сервер, і клієнт можуть бути організовані на одному комп’ютері. У цьому випадку ми говоримо про локальну систему.

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

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

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

Моделювання предметної області

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

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

сутність — це множина об’єктів, що володіють однаковим набором атрибутів, а форма-

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

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

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

Кафедра економічної кібернетики та інформаційних технологій. Одеський національний політехнічний університет

значенням ключа.

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

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

У цьому випадку для ідентифікації екземпляра один з них вибирається як первинний ключ або привілейований ідентифікатор (ID). Інші будуть альтернативними ключами.

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

відсортувати студентів факультету за значенням сумарного рейтингу сесії.

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

браження однієї множини екземплярів (однієї сутності) на інше або інші. Така відповід-

ність називається зв’язком. На практиці кожен зв’язок несе деяке змістове навантаження, що задається користувачем.

Зв’язки можуть бути бінарними — між двома елементами, тернарними — між трьома елементами, …, n-арними, коли в зв’язку беруть участь n сутностей. Нас, у першу чергу, будуть цікавити бінарні зв’язки. Крім того, розрізняють рефлексивні зв’язки між екземплярами однієї і тієї ж сутності, транзитивні (опосередковані) зв’язки та ін.

За типом зв’язки поділяють таким чином (представимо всі можливі типи бінарних зв’язків у вигляді таблиці — вони нам будуть потрібні при проектуванні БД):

Сутності, що беруть участь у зв’язку, відповідно 1-, N- і M-зв’язкові.

R1. Зв’язок 1:1 (або відображення 1 до 1) — кожному екземпляру сутності А відповідає в точності 1 екземпляр сутності В (рис. 16):

А В

Рис. 16. Теоретико-множинне представлення зв’язку 1:1

Наприклад: „кафедра — завідувач кафедри“.

Для графічного представлення зв’язків між конкретними сутностями використовують-

ся 2 підходи: діаграми „сутність — зв’язок“ (або ER-діаграми) та інформаційні моделі (ІМ). ER-діаграма виглядає так (рис. 17):

Кафедра економічної кібернетики та інформаційних технологій. Одеський національний політехнічний університет

БУ зв'язок

Рис. 17. ER-діаграма прикладу зв’язку 1:1

На ІМ сутності представляються у вигляді прямокутників, що містять і назву сутності й атрибути (рис. 18):

Рис. 18. Інформаційна модель прикладу зв’язку 1:1

Де-факто існує ще одна вельми поширена нотація для представлення зв’язків між сутностями — це інформаційна модель, яка запропонована фірмою Microsoft і використовується в СУБД Access цієї фірми (рис. 19):

Рис. 19. Інформаційна модель MS Access прикладу зв’язку 1:1

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

R2. Зв’язок 1:N — кожному екземпляру сутності А відповідає 1÷N екземплярів сутності В (рис. 20):

Рис. 20. Теоретико-множинне представлення зв’язку 1:N

Наприклад: „порт — корабель“ (рис. 21)

Кафедра економічної кібернетики та інформаційних технологій. Одеський національний політехнічний університет

Рис. 21. Інформаційна модель прикладу зв’язку 1:N

R3. Зв’язок M:N — кожному екземпляру сутності А відповідає 1÷N екземплярів сутності В і навпаки, кожен екземпляр сутності В відповідає 1÷М екземплярам сутності А (рис. 22).

Рис. 22. Теоретико-множинне представлення зв’язку M:N

Наприклад: „викладач — дисципліна“ (рис. 23).

Рис. 23. Інформаційна модель прикладу зв’язку M:N

Умовність у зв’язках виникає тоді, коли деякі екземпляри однієї або обох сутностей не беруть участь у зв’язку. Наприклад (рис. 24):

А В

Рис. 24. Теоретико-множинне представлення зв’язку 1у:1 R4. Зв’язок 1:1у: „студент — дипломний проект“ (рис. 25).

Рис. 25. ER-діаграма прикладу зв’язку 1у:1 R8. Зв’язок 1у:1у: „Дисплей — ЕЛТ“ (рис. 26)

Рис. 26. Теоретико-множинне представлення й інформаційна модель прикладу зв’язку 1у:1у

R9. Зв’язок 1у:Nу: „кафедра — лабораторія“ (рис. 27).

Кафедра економічної кібернетики та інформаційних технологій. Одеський національний політехнічний університет

Рис. 27. Теоретико-множинне представлення й інформаційна модель прикладу зв’язку 1у:Nу

Необхідно відзначити, що існує ще один особливий тип зв’язку: зв’язок супертиппідтип. Прикладами такого зв’язку можуть служити такі, що представлені на рис. 28, рис. 29:

Співробітник

* № посвідч.

•ПІП

•стаж

…

є R15

Рис. 28. Інформаційна модель прикладу зв’язку супертип-підтип

Рис. 29. ER-діаграма прикладу зв’язку супертип-підтип

Моделі даних

Модель даних включає 3 складових:

1. Структуру даних для представлення точки зору користувача на БД.

2.Список операцій, припустимих над даною структурою. Ці два пункти — основа мови даних конкретної моделі.

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

а) кожне піддерево ієрархічної структури даних повинне мати кореневий (початковий) вузол, і не можна зберігати породжені вузли без батьківського;

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

1.Мережеві.

2.Ієрархічні.

3.Реляційні.

Перші дві називають ще дореляційними за часом їхньої появи, хоча вони тією чи іншою

Кафедра економічної кібернетики та інформаційних технологій. Одеський національний політехнічний університет

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

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

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

Мережева модель даних

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

Термінологія, використовувана при обробці даних у такій моделі, була введена робочою групою по базах даних асоціації CODASYL (асоціація з мов обробки даних).

Цією групою були введені такі терміни (рис. 30):

схема, що описує структуру БД;

елемент даних — найменша пойменована одиниця даних;

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

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

Студент

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

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

1.Він визначає відображення 1:N між типами записів набору.

2.Кожен екземпляр набору містить 1 екземпляр запису-власника і довільне число записів членів.

БД — пойменована сукупність різних типів наборів, яка містить зв’язок між записами, що представлені екземплярами наборів.

Рис. 30. Діаграма залежності між елементами моделі CODASYL

Мережева модель даних може бути описана у вигляді графу з n-арними зв’язками. Наприклад (рис. 31):

Рис. 31. Приклад зв’язку M:N у мережевій моделі

Кафедра економічної кібернетики та інформаційних технологій. Одеський національний політехнічний університет

Цей граф описує зв’язок M:N: множина студентів — множина дисциплін. Проте набір в мережевій моделі CODASYL допускає тільки зв’язки 1:N. Перетворення до цієї моделі виконується шляхом введення додаткового запису „спеціальність“ (рис. 32).

Спеціальність

Назва спец., …

Рис. 32. Приведення зв’язку M:N у відповідність до вимог мережевої моделі CODASYL

Інший варіант представлення моделі даних — опис її мовою даних CODASYL. Так МВД CODASYL для мережевої моделі містить 4 пункти (статті):

1. Стаття схеми:

SCHEMA NAME IS ім’я_БД

2.Одна або кілька статей областей пам’яті: AREA NAME IS ім’я_області

3.Стаття запису:

SET NAME IS ім’я_запису (наприклад, „студент“)

ПІП TYPE IS CHARACTER 30

№гр. TYPE IS FIXED 3

4.Стаття набору:

SET NAME IS ім’я_набору (навчання) OWNER IS ім’я_власника (спеціальність) MEMBER IS ім’я_члена (студент)

SET NAME IS ім’я_набору (викладання)

OWNER IS ім’я_власника (спеціальність)

MEMBER IS ім’я_члена (дисципліна)

ММД містить оператори операцій над описаними елементами. Наприклад: FIND ім’я_запису RECORD USING ключ.

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

Ієрархічна модель також ґрунтується на графовій формі представлення даних. Однак тут припустима тільки деревоподібна структура зв’язків.

Графічна діаграма схеми БД в ієрархічній моделі називається деревом визначення.

На внутрішньому рівні така БД представляється файлом, що поєднує екземпляри запи-

сів.

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

(рис. 33):

курс група студент

Факультет

кафедра дисципліна викладач

Рис. 33. Приклад ієрархії сутностей

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

Прикладом реалізації цієї моделі може служити СУБД IMS, створена фірмою IBM у

Кафедра економічної кібернетики та інформаційних технологій. Одеський національний політехнічний університет