Доц. каф. ЕК

7. Методические указания к лабораторным занятиям по курсу общей геологии (для студентов горных специальностей). /Л.П.Нестеренко, В.И.Таранец, Е.П.Бахтарова, В.А.Привалов. -Донецк: ДПИ, 1990.- 64 с.

Ч.2

з дисципліни

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

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

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

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

Укладач:

доц. каф. ЕК

Вєніков Д.П.

Львів - 2011

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

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

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

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

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

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

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

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

Такий опис, утворений по інфологічній моделі даних, називають даталогічною моделлю даних.

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

Термінологія в СУБД, та й самі терміни "база даних" і "банк даних" частково

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

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

улаштована СУБД, пропонувалися різні способи реалізації. Самим життєздатним з них виявилася запропонована американським комітетом зі стандартизації ANSІ (Amerіcan Natіonal Standards Іnstіtute) трьох-рівнева система організації БД, зображена на мал. 2.1.

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

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

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

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

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

Рис. 2.1. Трирівнева модель системи керування базою даних

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

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

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

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

Петров Микола Степанович, $30 і т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) забезпечити облік книг, що є в наявності,

2) виконувати швидкий пошук творів, що входять до складу тих чи інших книг.

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

4) Для виявлення користувачів, які порушили строки повернення книги, також повинна бути картотека творів, що є в наявності в читальному залі.

Відповідно, інформація що необхідна для вирішення цих задач:

1) в базу даних доцільно включити інформацію про: книги, що є в читальному залі;

2) твори, що входять до складу тих чи інших книг;

3) користувачів, що користуються послугами читального залу.

При цьому, розроблювана база даних повинна забезпечити такі функції:

1. Ведення картотеки користувачів.

В інформацію про користувачів доцільно включити такі дані:

Þ прізвище, ім'я та по батькові;

Þ адреса;

Þ номер телефону;

Þ паспортні дані;

Þ освіта;

Þ професія.

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

Þ назва книги;

Þ автор книги;

Þ рік видання;

Þ видавництво;

Þ кількість сторінок;

Þ предметна область.

3. Ведення картотеки творів, які містяться в даній книзі, включає таку інформацію:

Þ назва;

Þ автор;

Þ дата написання.

4. Виявлення боржників, що не повернули книгу протягом дня.

5. Формування даних про повернення книги.

На цьому можна умовно вважати завершеною 1-у фазу аналізу предметної області.

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

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

При проектуванні на інфологічному рівні створюється інформаційно-логічна модель (ИЛМ), що повинна відповідати таким вимогам:

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

- коректність схеми БД, тобто адекватне відображення модельованої ПО;

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

- ІЛМ повинна бути описана мовою, зрозумілим проектувальникам БД, програмістам, адміністраторові й майбутнім користувачам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Слід розрізняти такі поняття, як тип сутності і екземпляр сутності. Поняття типу сутності відноситься до набору однорідних особистостей, предметів, подій або ідей. Екземпляр сутності відноситься до конкретної речі в наборі. Наприклад, типом сутності може бути МІСТО, а екземпляром - Москва, Київ і т.д. Таким чином, одному типу сутності може відповідати множина конкретних сутностей – його екземплярів. Аналог – тип запису і екземпляри запису.

Атрибут - пойменована характеристика сутності. Його найменування повинно бути унікальним для конкретного типу сутності, але може бути однаковим для різноманітного типу сутностей (наприклад, КОЛІР може бути визначений для багатьох сутностей: СОБАКА, АВТОМОБІЛЬ, ДІМ і т.д.).

Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про сутність (в рамках певної предметної галузі та певних задач). Прикладами атрибутів для сутності АВТОМОБІЛЬ є ТИП, МАРКА, НОМЕРНИЙ ЗНАК, КОЛІР і т.д. Тут також існує розходження між типом і екземпляром. Тип атрибута КОЛІР має багато екземплярів або значень: Червоний, Синій, Банановий, Біла ніч і т.д.. Проте кожному екземпляру сутності присвоюється тільки одне значення атрибута.

Абсолютне розходження між типами сутностей і атрибутами відсутнє. Атрибут є таким тільки в зв'язку з типом сутності. У іншому контексті атрибут може виступати як самостійна сутність. Наприклад, для автомобільного заводу КОЛІР - це тільки атрибут продукту виробництва, а для лакофарбової фабрики КОЛІР - тип сутності.

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

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

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

Атр n.1

Атр n.2

Атр n.2

…

Атр n. z

Атр1.1

Атр1.2

Атр1.2

…

Атр1.n

Атр2.1

Атр2.2

Атр2.2

…

Атр2. m

Атр3.1

Атр3.2

Атр3.2

…

Атр3. k

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

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

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

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

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

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

На використанні різновидів ER -моделі реалізується більшість сучасних підходів до проектування баз даних. ER -модель була запропонована Ченом (Chen) у 1976 р.

При побудові інфологічних моделей можна використовувати мову ER -діаграм (від англ. Entity-Relationship, "сутність-зв'язок"). В них сутності зображуються позначеними прямокутниками, асоціації - позначеними ромбами або шестикутниками, атрибути - позначеними овалами, а зв'язки між ними - ненаправленими ребрами, над якими може проставлятися ступінь зв'язку (1 або буква, що заміняє слово "БАГАТО") і необхідне пояснення.

У зв'язку з наочністю уявлення концептуальних схем баз даних ER -моделі знайшли широке застосування в системах CASE, що підтримують автоматизоване проектування реляційних баз даних.

Головні поняття ER -моделі: є сутність, зв'язок і атрибут. У діаграмах ER -моделі сутність подається у вигляді прямокутника, що містить ім'я сутності. При цьому ім'я сутності - це ім'я типу, а не деякого конкретного екземпляра цього типу. Для кращого розуміння ім'я сутності може супроводжуватися прикладами конкретних об'єктів цього типу. Сутність АЕРОПОРТ із об'єктами Шереметьєво і Хітроу зображена на рис.2.8.

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

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

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

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

Обов'язковий кінець зв'язку зображується суцільною лінією, а необов'язковий - переривчастою лінією.

Розглянемо приклад зв'язку між сутностями КВИТОК і ПАСАЖИР (рис.2.9).

Рис. 2.9. Зображення зв’язку між сутностями КВИТОК та ПАСАЖИР

При цьому кінець зв'язку з ім'ям " Для " дозволяє зв'язувати з одним пасажиром більше одного квитка, причому кожний квиток повинен бути пов'язаний із яким-небудь пасажиром. Кінець зв'язку з ім'ям " Має " означає, що кожний квиток може належати тільки одному пасажиру, причому пасажир зобов'язаний мати не менше одного квитка. Трактування зображеної діаграми (рис.2.9) таке: {? }

Þ Кожний КВИТОК призначений для одного і тільки одного ПАСАЖИРА;

Þ Кожний ПАСАЖИР може мати один або більше КВИТКІВ.

На рис.2.10 приведено приклад зображення рекурсивного зв'язку, що зв'язує сутність ЛЮДИНА з нею ж самою.

Рис. 2.10 - Зображення рекурсивного зв'язку

Кінець зв'язку з ім'ям СИН визначає той факт, що в одного батька може бути більше ніж один син. Кінець зв'язку з ім'ям БАТЬКО означає, що не в кожної людини можуть бути СИНИ.

Трактування зображеної діаграми (рис.2.10) таке:

Þ Кожна ЛЮДИНА є сином одного і тільки одного ЧОЛОВІКА;

Þ Кожна ЛЮДИНА може бути батьком для одного або більше ЛЮДЕЙ.

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

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

Таким чином, зв'язки можуть представлятися рiзними способами, з яких ми будемо використовувати тiльки два: дiаграма ER -екземплярiв i дiаграма ER -типiв. Дiаграми ER -екземплярiв вiдображають зв'язки мiж екземплярами сутностей. Дiаграми ER -типiв вiдображають зв'язки мiж типами сутностей.

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

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

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

Пр.24

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

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

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

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

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

Пр.25

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

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

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

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

......

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

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

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

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

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

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

Пр.26

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

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

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

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

......

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

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

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

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

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

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

Пр.28

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

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

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

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

№_pasp, Culture, Profession.

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

Пр.29

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стрижнева сутність (стрижень) - це незалежна сутність.

Асоціативна сутність (асоціація) - це зв'язок типу Б:Б між двома або більше сутностями або екземплярами сутності. Асоціації розглядаються як повноправні сутності:

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

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

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

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

ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2,...) {СПИСОК СУТНОСТЕЙ, ЩО ХАРАКТЕРИЗУЮТЬСЯ}.

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

Розглянемо приклад, пов'язаний із зарахуванням співробітників у різні відділи організації. При відсутності жорстких правил (співробітник може одночасно зараховуватися в декілька відділів або не зараховуватися ні в один відділ) необхідно створити опис з асоціацією ЗАРАХУВАННЯ:

Відділи (Номер відділу, Назва відділу,...)

Службовці (Табельний номер, Прізвище,...)

Зарахування [Відділи M, Службовці N](Номер відділу, Табельний номер, Дата зарахування).

Проте, за умови, що кожний із співробітників повинний бути обов'язково зарахований в один із відділів, можна створити опис із позначенням СЛУЖБОВЦІ:

Відділи (Номер відділу, Назва відділу,...)

Службовці (Табельний номер, Прізвище,..., Номер відділу, Дата зарахування) [Відділи]

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

ПОЗНАЧЕННЯ (атрибут 1, атрибут 2,...)[СПИСОК СУТНОСТЕЙ, ЩО ПОЗНАЧАЮТЬСЯ].

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

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

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

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

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

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

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

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

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

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

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

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

1) необов'язковий зв'язок: існування об'єктів не залежить від зв'язку;

2) можливий зв'язок: існування одного з об'єктів залежить від зв'язку;

3) умовний зв'язок: частковий вид можливого зв'язку, коли задається умова існування (наприклад, зв'язок між об'єктами СТУДЕНТ, СТИПЕНДІЯ можлива при умові відповідної успішності);

4) обов'язковий зв'язок: існування обох об'єктів залежить від зв'язку.

Односторонні зв'язки між парами елементів називаються асоціаціями, а двосторонні - відображеннями.

Між двома сутностями А й В можливі чотири типи зв'язків:

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

2)

Рисунок 2.2 - Приклад відображення ОДИН-ДО-ОДНОГО

3) другий тип - зв'язок ОДИН-ДО-БАГАТЬОХ (1:Б): якщо екземпляр елемента даних, від якого направлений зв'язок, ідентифікує деяке число екземплярів елементів даних, до яких направлений зв'язок, причому ідентифікація в даному напрямку не обов'язково є унікальною, то таке відображення називається ОДИН-ДО-БАГАТЬОХ (1:Б). Прикладом такого відношення (рис.2.3) може бути НОМЕР ВІДДІЛУ - ТАБЕЛЬНІ НОМЕРИ ПРАЦІВНИКІВ. У відділі працює багато службовців, але кожний працівник відноситься тільки до одного відділу.

Рисунок 2.3 - Приклад відображення ОДИН-ДО-БАГАТЬОХ

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

4) БАГАТО-ДО-ОДНОГО (Б:1) і

5) БАГАТО-ДО-БАГАТЬОХ (Б:Б). Відображення Б:1 є аналогічним відображенням 1:Б.

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

Прикладом такого відношення (рис.2.4) є відношення ВИКЛАДАЧІ-СТУДЕНТИ. Кожний студент "пов'язаний" з багатьма викладачами і кожний викладач читає лекції різним групам студентів.

Характер зв'язків між сутностями не обмежується переліченими. Існують і більш складні зв'язки:

1). множина зв'язків між одними й тими ж сутностями;

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

2). тренарні зв'язки;

Наприклад, лікар може призначити декільком пацієнтам декілька аналізів, аналіз може бути призначений декількома лікарями декільком пацієнтам, й пацієнту може бути призначено декілька аналізів декількома лікарями;

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

Існує три типа асоціацій:

- асоціація типу 1 (проста);

- асоціація типу М (складна);

- асоціація типу С (умовна).

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

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

Рисунок 2.6 - Приклад складної асоціації типу М

В умовній асоціації типу С (рис.2.7) для даного екземпляра елемента даних, від якого спрямований зв'язок, може не існувати відповідного екземпляра елемента даних, до якого спрямований зв'язок. Якщо він існує, то відноситься до єдиного екземпляра елемента даних. Наприклад, ПІБ РОБІТНИКА і ДАТА ЗВІЛЬНЕННЯ (див. рис.2.7)..

У реальних базах даних існує велика кількість типів елементів даних.

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

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

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

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

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

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

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

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

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

Рис.2.2. Схема класифікації мовних засобів БнД

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

Мова опису даних (DDL - Data Defіnіtіon Language), призначена для опису даних на різних рівнях абстракції: зовнішньому, логічному й внутрішньому.

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

У відомих й широко використовуваних на практиці СУБД родини dBASE застосовується єдина мова опису даних. Вона призначена для подання даних на логічному й фізичному рівнях. Ця мова має свій синтаксис: наприклад, ім'я файлу не повинне перевищувати восьми символів, а ім'я поля – десяти. При цьому кожне ім'я може починатися з букви, поля календарної дати позначаються символом D (DATA), символьні поля - С (CHARACTER), числові - N (NUMERІ), логічні - L (LOGІCAL), приміток - М (MEMO).

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

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

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

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

8.2. Мова маніпулювання даними (DML - Data Manіpulatіon Language) використається для обробки даних, їхніх перетворень і написання програм. DML може бути базовою або автономною.

Базова мова DML - це один із традиційних мов програмування (BASІC, FORTRAN й ін.). Системи, які використають базову мову, називають відкритими. Використання базових мов як мов опису даних звужує коло осіб, які можуть безпосередньо звертатися до БД, оскільки для цього потрібно знать мова програмування. У таких випадках для спрощення спілкування кінцевих користувачів із БД передбачається мова ведення діалогу, що

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

Автономна мова DML - це власна мова СУБД, що дає можливість виконувати різні операції з даними. Системи із власною мовою називають закритими.

У сучасних СУБД для спрощення процедур пошуку даних у БД передбачена мова запитів. Найпоширенішими мовами запитів є SQL й QBE.

Мова запитів SQL (Structured Query Language - структурована мова запитів) був створений фірмою ІBM у рамках роботи над проектом побудови системи керування реляційними базами даних на початку 70-х років. Американський національний інститут стандартів (ANSІ) поклав цю мову в основу стандарту мов реляційних баз даних, прийнятого Міжнародною організацією стандартів (ІSO). Ядром існуючого стандарту SQL-86, які часто називають SQL-2 або SQL-92, є функції, реалізовані практично у всіх відомих комерційних реалізаціях мови, а повний стандарт уміщає такі вдосконалення, які деякі розроблювачі будуть повинні ще реалізувати.

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

Був розроблений стандартний інтерфейс мови CLІ (Common Language Іnterface)

для всіх основних варіантів мови SQL. Цей інтерфейс, формалізований фірмою Mіcrosoft, одержав назву ODBC (Open DataBase Connectіvіty – відкритий доступ до даних). ODBC - це інтерфейс доступу до даних, які зберігаються під керуванням різних СУБД. ODBC має цілий набір драйверів, за допомогою яких одна СУБД може працювати з даними інших систем. Архітектура ODBC зображена на рис 8.3.

Рис. 2.3. Архітектура ODBC

Мова запитів QBE (Query By Example) - це реалізація запитів за зразком

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

надану системою таблицю QBE і визначити в ній критерії пошуку й вибору даних.

Розроблені мови маніпулювання даними, що дозволяють реалізувати всі операції реляційної алгебри і практично будь-які їх сполучення. Серед них найбільше поширені SQL (Structured Query Language - структуризована мова запитів) і QBE (Query-By-Example - запити за зразком).

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

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

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

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

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

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

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

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

Операції з даними в реляційній моделі

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

Операції, що виконуються на рівні кортежів:

- вставка (додається новий рядок),

- вилучення (знищується рядок),

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

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

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

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

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

В реляційній алгебрі використовують п'ять основних операцій:

1. об'єднання,

2. різниця (віднімання),